1

他の人のコードを見ていると、ブロックの括弧の配置にばらつきがあることに気付くことがよくあります。

たとえば、次のように使用するものもあります。

int foo(){
    ...
}

他の人が使用するのに対し：

int foo()
{
    ...
}

そしてその間のいくつかの方法。これは、コードのコンパイル速度にまったく影響しますか? たとえば、次のような一連のブロックがあるとします。

int foo() { ... {... {... {... {...} } } } }

int bar()
{
    ...
    {
        ...
        {
            ...
            {
                ...
                {
                    ...
                }
            }
        }
     }
}

foo() と bar() は、空白と括弧の配置を除いて同一です。関数のコンパイルにかかる時間は異なりますか? 一方は他方よりも実行時に高速でしょうか?

これが数百または数千のネストされたブロックに拡張された場合、これは何か違うでしょうか? これは、使用するコンパイラによって異なりますか? C#、PHP、Perl など、さまざまな言語で変更されますか?

これが一般的または自由回答式の質問のように思われる場合は、申し訳ありませんが、常に私が興味を持っていることです。

4

2 に答える 2

1

関数のコンパイルにかかる時間は異なりますか? 一方は他方よりも実行時に高速でしょうか? これが数百または数千のネストされたブロックに拡張された場合、これは何か違うでしょうか? これは、使用するコンパイラによって異なりますか? C#、PHP、Perl など、さまざまな言語で変更されますか?

いいえ、いいえ、いいえ、いいえ、いいえ、事実上すべての正常なコンパイラは、字句解析フェーズでほぼ即座に空白を取り除きます。他のフェーズは、空白があったことさえ知りません。

これが違いを生む唯一の方法は、これまでで最も恐ろしく無能に書かれたコンパイラであり、それでも私は驚かれることでしょう (また、この規模のバグは非常にバグが多く、完全に使用できなくなるでしょう)。

于 2013-06-28T14:07:28.003 に答える
0

コンパイラが最初に行うことは、字句解析を実行して空白やコメントなどを取り除き、入力を一連のトークンに変換することです。

特定の実装に応じて、完全なプロセスは次のようになります。

ここに画像の説明を入力

lexer は一連のトークンをパーサーに渡すため、追加の空白、ブラケット位置などは、lexing フェーズのみを遅くする可能性があります。それでも、1GBの空白やそのようなクレイジーなものなど、極端なケースがない限り、違いは目立ちません.

于 2013-06-28T14:42:30.153 に答える