トップページ > プログラム > 2015年08月30日 > NgQJvyWC

書き込み順位&時間帯一覧

15 位/131 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000000001110000003



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
ふらっと C#,C♯,C#(初心者用) Part116 [転載禁止]©2ch.net

書き込みレス一覧

ふらっと C#,C♯,C#(初心者用) Part116 [転載禁止]©2ch.net
513 :デフォルトの名無しさん[sage]:2015/08/30(日) 15:45:54.83 ID:NgQJvyWC
>>505
ほんと?
Cのプリプロセス自体はかなり高速だと思うけど。
ぶっちゃけ、テキスト置換だから、型チェックやオブジェクト生成が入ってくるコンパイルより全然負荷かからないはず。

コンパイルが遅いのは、プリプロセッサの仕組みのせいじゃなくて、ヘッダファイルのちょっとした変更が、大影響してしまうような構成になりがちだからでは?
ふらっと C#,C♯,C#(初心者用) Part116 [転載禁止]©2ch.net
517 :デフォルトの名無しさん[sage]:2015/08/30(日) 16:30:11.40 ID:NgQJvyWC
>>515
そこに異論は無い。
その通りだと思う。

>>505の
> プリプロセッサは複雑になるとコンパイルが異常に重くなるから入れないんだと思われる

この一文に、引っかかってる。
そんな理由じゃないと思うし、そもそもcのプリプロセスであれば、コンパイルよりはるかに速いし。
繰り返しだけど、コンパイルを遅くする原因があるとすれば、プリプロセッサの負荷じゃなくて、1つのincludeファイルの変更の影響が大きくなるようなソースコードになってるからだと思う。

それは、includeの問題であって、プリプロセッサとは関係なくね?って言う。
ふらっと C#,C♯,C#(初心者用) Part116 [転載禁止]©2ch.net
524 :デフォルトの名無しさん[sage]:2015/08/30(日) 17:19:35.80 ID:NgQJvyWC
>>520
>>522
だから、それはincludeの問題であって、マクロが直接の問題じゃないじゃん。。。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。