C言語を完全に駆逐するためには

1 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 20:11:42 ] どうすればいい？ 175 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:07:41 ] >>174 C だけ使えば C と同じ性能。 C++ でもよく使われる言い回し。 176 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 01:35:36 ] >>174 例えばある変数の値を、1から10000までカウントupみたいなのは、Cは高速。 理由はおおざっぱに言えば、処理時間=計算量*1計算あたりのクロック数　だから。 2次元テーブル(n行n列)の全スキャン計算量は、nの2乗に比例するからo(n^2)とか。 単純なカウントupの計算量は小さい。 一方、ライブラリに必ずしも無いもの(例:クロージャなど)が必要になると、 プログラマーがゼロから実装するのは負担が大きくて、他の方法で回避する。 回避策の計算量、1計算あたりのクロック数によっては、他の言語で記述した方が 早い場合もある。 ↓参考:プログラミング言語ベンチマーク ttp://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all 177 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:38:24 ] >>71 古い話で恐縮だけれども、ICOTの例のプロジェクトでは prolog の進化形で　**カーネルの大部分を** 記述していたとか。 そういう用途のシステムでは、そういう選択もあるようです。 ＃同じ研究を現在のハードウェア技術で行ったらどうなるのかつくづく知りたいものですが、あと 100 年はとりあげられないでしょうか‥‥‥。 178 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:43:57 ] >>88 人を変態よばわりしないでください。 R6RS準拠のコンパイラがでたんですって？ 179 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 08:35:10 ] Cに文句言うより86アセンブラをまず駆逐しろよ・・・ Intelでさえできなかったんだぞ 180 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 08:37:36 ] 今時のCPUはアセンブラ（≒機械語）を直接実行せずに 自前の命令に変換するんでしょ。 そんな内部コードを毎度毎度表にさらしてたら大混乱が起こるんじゃね。 AMDの人も命令コードなんて全然大した問題じゃないとか言ってたし。 181 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 13:54:39 ] >173 > そういえば、.NETってなんとなくスルーしてたなぁ。 > 趣味として使うとしたら学ぶ価値ある？ プログラミングが趣味か、なんらかの成果物を完成させるのが趣味かで変わってくるんじゃ? ﾄﾞﾄﾈﾄ系はWindowsのアプリを作るということなら、死ぬほど楽なのは確か。 特にC#とC++/CLIの楽さは異常。 182 名前：173 mailto:sage [2008/05/15(木) 18:43:57 ] >>181 レスさんくす。 C#でもかじってみるか。 （そういえばIronRubyはどうなったんだ？とんと話を聞かないが。） 183 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 18:44:40 ] 開発言語をアセンブラからCに変えて解放されることって １．レジスタの管理 ２．メモリの管理 ３．スタックの管理 くらいかな？ こうやってみるとCって意外と面倒な問題を解決してくれてることに気づくｗ 184 名前：デフォルトの名無しさん [2008/05/16(金) 18:54:16 ] とりあえずage 185 名前：デフォルトの名無しさん [2008/05/16(金) 19:23:40 ] CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。 他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。 CにはOOだのGCだの必要なし。それはLLとかに任せればいい。 186 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:30:17 ] namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。 IDEとの親和性も爆上がるし。 187 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:42:34 ] >>185 ただ、cppにはもうちょっと賢くなってほしいけどなあ。 あ、でもあんまり賢すぎるとlispみたいになんでもマクロで書いちゃう 人が出てくるからダメかな。 188 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 00:00:28 ] >>183 Cはメモリーもスタックも管理しないだろ 189 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 00:07:03 ] 自動変数の事じゃないの 190 名前：183 mailto:sage [2008/05/17(土) 00:20:31 ] スタックの管理は自動変数、 メモリーの管理はmalloc&free,大域変数のつもりで書いた。 191 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 11:00:14 ] OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。 192 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 12:10:51 ] c++を駆逐してほしいんだが 193 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 12:38:39 ] 学習コスト＜＜駆逐コスト 194 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:08:01 ] >>191 高級アセンブラが使われる環境を駆逐したいんじゃない？ 195 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:17:15 ] 入れ子が{}じゃなくて ポインタが*じゃないC言語ください 196 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:35:32 ] なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。 些細なデメリット避けるために大きなメリットを失っている。 197 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:53:06 ] The C Programming Language 274ページ www.amazon.co.jp/Programming-Language-Version-Prentice-Software/dp/0131103628 The C++ Programming Language 1030ページ www.amazon.co.jp/C-Programming-Language-Bjarne-Stroustrup/dp/0201700735 この厚さの差が問題だと思うけどな。スピードを求めるならCで書けばいいし、そうで ないならJavaとか使えばいいかと思う。C++は何でも屋であるが故に駆逐されつつある。 198 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:53:49 ] >>192 今田舎に別荘を建てて隠遁する準備が進んでいるよ 200x 年には完成する見込みらしい 199 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:01:51 ] >>196 C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない 特にリンクやロードが遅いのは致命的 MISRA-C++ とか JSF++ って日本語の解説無いのかな 200 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:37:41 ] C+αとして使えば全く速度は変わらないし生産性はかなり上がると思っている。 むしろプログラムを自然に作れば C++ の方が速いと思っているぐらいです。 リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん じゃない? 201 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:51:55 ] >>200 >リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん >じゃない? 世間の C++ 使いって所詮この程度の認識なんだよね… 自分が使っている道具に対する関心が無さ過ぎ >全く速度は変わらないし だからこんなことを平気で言えてしまうわけだな 202 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 15:39:45 ] そういうのはいいから説明してくれよ 203 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:10:03 ] VC8 で Dhrystone Benchmark, Version 2.1 を C と C++ でコンパイルして比較 C Dhrystones per Second: 10300995.0 C++ Dhrystones per Second: 10299298.0 確かに C の方が速いですね。 204 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:13:25 ] dhrystone で測れるのはループの中の計算時間だけだからね 205 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:27:25 ] ループの中で結構関数呼び出しもしてるよ。 206 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:28:51 ] リンクやロードも? 207 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 20:04:19 ] >>200 C+αなんかではなく、ポテンシャル全開でC++を使うときの コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。 残りの半分は実装の問題。 208 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 21:51:56 ] ＋αでない残りのポテンシャルの部分って具体的に何よ？ 例外とか？ 209 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 21:54:58 ] テンプレートじゃね？ 210 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 23:04:00 ] >>206 リンクは C が 0.10257s で C++ が 0.10281s です。 ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。 >>208 コンパイルで一番負担がかかるのは圧倒的にテンプレートだと思います。 boost::spirit のように凝ったテンプレートをインクルードしたファイルは 極端に時間がかかります。 遅いだけあってテンプレートの可能性は絶大なのですが。 VCの場合はテンプレートでオブジェクトファイルも大きくなるようです。 ただしリンク後は実行ファイルはそれほど大きくなりません。 211 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 01:34:45 ] >>195 入れ子が begin end, ポインタが ^ でもいい？ 212 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 01:56:07 ] >>203 同じソースコードで C++ にしただけで 10% 遅くなった。 g++ でコンパイルが通る様にしたのと、scanf() も消して ベンチマーク回数は 10000000 回固定にしている。 C++: % otool -L dry2 dry2: /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.35s user 0.00s system 99% cpu 1.352 total C: % otool -L dry2 dry2: /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.22s user 0.00s system 99% cpu 1.227 total あまり例題としては適当じゃないけど、こんなもんかね。 213 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 07:19:22 ] ちなみに ObjC でもやってみた。 ObjC: % otool -L dry2 dry2: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.42s user 0.00s system 99% cpu 1.424 total 更に、ベンチマーク回数を 10 倍にすると… C: ./dry2 12.26s user 0.01s system 99% cpu 12.291 total C++: ./dry2 13.47s user 0.01s system 99% cpu 13.490 total ObjC: ./dry2 14.17s user 0.01s system 99% cpu 14.200 total Better C は Slower C でしたw こんなお遊びのマイクロベンチの結果を真に受けちゃ嫌よ。 214 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 11:03:42 ] VC は優秀だな。 215 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:21:33 ] いろんな分野でC++はPythonに置き換わりつつあるな Rubyなんてのを与えられた日本人は世界から置いてけぼり 216 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:30:09 ] 何のスレだここは 217 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 13:43:40 ] cソースはcppソースに変換後にコンパイルされるんだが。 218 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 14:59:17 ] cpp ってCプリプロセッサのこと? 確かに gcc はそういう手順になっていると思います。 219 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:06:49 ] >>214 C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど… アセンブラ出力かシンボルダンプが見てみたいね >>218 .cpp の事でしょう 何となく何でこうなってるのかは予想がつくけど… 220 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:52:20 ] Dhrystone Benchmark, Version 2.1 を同じ環境で VC 8.0 と GCC 3.4.4 (cygwin) で比較 VC 8.0 (最適化オプションは /O2) C: 1m37.328s C++: 1m37.437s GCC 3.4.4 (最適化オプションは -O4 -fno-omit-frame-pointer -march="pentium-m") C: 2m2.188s C++: 2m4.297s ちなみに -march を外すとさらに 24s ぐらい時間がのびました。 C コンパイラが C++ 並みに遅くてもこれだけ速ければ十分優秀じゃないかな? というよりこちらでは GCC も C が C++ 並みに遅くなりました。 221 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:32:20 ] >>220 ちゃんと C++ としてコンパイルしてる? 共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、 何でも良いけど晒してみて。最適化オプション無しだとどうなる? 222 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 22:24:40 ] >>221 C++ 版は VC では /TP オプションで、GCC では g++ 経由でコンパイルしたので C++ としてコンパイルしているはずです。 C++ でコンパイルするとき class X; をソースに書いてもエラーが出ません。 リストは長くなるのでここでは勘弁してください。 参考までに最適化を禁止して時間を計測しました。 最適化なしだと C++ が遅くなると思っていたのですが意外な結果になりました。 VC 8.0 C: 18m58.547s C++: 18m58.890s GCC 3.4.4 C: 4m46.594s C++: 4m47.765s 223 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:33:34 ] tccを使えば解決、と言ってみる。 ttp://alohakun.blog7.fc2.com/blog-entry-667.html 224 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:46:36 ] >>222 ウィンドウズは知らないけど、うちの環境だとアセンブラ出力も シンボル名もライブラリのリンクもベンチマークのスコアも変わる。 純粋に C だけのコードでこれだから、Better C として C++ の 機能を混ぜた使い方（例えば例外処理や名前空間）をすれば 更に悪化する物と期待出来る。ウィンドウズで組み込みなら C++ でも変わらないかもね。あとは Symbian とか。 まあ Better C って考え方は他にも落とし穴があるから、俺は 好きじゃないな。 225 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 14:40:12 ] >>224 OS というよりもほとんどの場合コンパイラとリンカで決まると思います。 (Windows の場合は実行時の最適化もやりかねないけど) 組込み向けコンパイラの場合は信じられないくらい最適化がダメなものも あるようです。5,6年前にある有名 CPU 向けの純正コンパイラーを使った とき、register 付きローカル変数を使っただけで命令がかなり削減された ことがありました。VC ではとても考えられないし、いまどき register を 使おうと思う人も少ないと思います。 昔の話なので今の組込み環境がどうなっているのかよく分かりませんが。 > Better C って考え方は他にも落とし穴があるから 技術的にはそれほど大きな問題もないと思っているのですが、興味深いので よかったら教えていただけませんか? 226 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 20:31:42 ] その駄目コンパイラ… 気になる… 227 名前：デフォルトの名無しさん [2008/05/20(火) 13:43:51 ] >>201 C++がCと比較してほとんど性能を落とさない理由は以下の本を読むとよく分かります。 またなぜC++をこのような設計にする必要があったのかも詳しく書いてあります。 C++の設計と進化 ttp://www.amazon.co.jp/C-%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A8%E9%80%B2%E5%8C%96-%E3%83%93%E3%83%A7%E3%83%BC%E3%83%B3-%E3%82%B9%E3%83%88%E3%83%A9%E3%82%A6%E3%82%B9%E3%83%88%E3%83%A9%E3%83%83%E3%83%97/dp/4797328541 星の数が胡散臭く感じるかもしれませんが読む価値はあると思います。 228 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 18:25:10 ] あーその本、もってるけど全然読んでないな。 ちゃんと読んでみるかな。 229 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 18:59:36 ] >>227 C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。 230 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:08:21 ] AT&T に居たんだから Aho なりに相談すれば良かったのにな 231 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:08:45 ] 暴言ｷﾀ━━＞▽＜━━━ 232 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:15:22 ] いやだってやたらと信じやすい人が居たから… C++ をマンセーするのも良いけど程々にね 233 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:37:24 ] あ、いちいち最後に改行を付け加えてる人の事な。 ストラウストラップが GLS の 1/10 でも言語設計の知識があったら あんなコンパイルが糞遅くなる事も無かっただろうさ。 234 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 20:21:11 ] あ、いちいち最後に改行を付け加えてる人の事な。 ストラウストラップが GLS の 1/10 でも言語設計の知識があったら あんなコンパイルが糞遅くなる事も無かっただろうさ。 235 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 20:23:45 ] >>234 下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？ 236 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 21:42:19 ] GLS がストラウストラップ 1/10 でも現実を見ていれば あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。 237 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:08:58 ] C のどこが起動が遅いって? 238 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:15:11 ] なんでCが出てくるんだ 239 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:20:34 ] >>238 GLS 知らんのか? 240 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:27:31 ] ぐぐったら、 予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た とりあえずガールズラブサーチ見てる 241 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:32:21 ] 起動は? 242 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:50:13 ] >>225 >OS というよりもほとんどの場合コンパイラとリンカで決まると思います。 だから環境って書いただろ… ナチュラルに斜め下の指摘をするのは止めてくれ 243 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:29:12 ] >>239 Guy L Steel Jr.の事だと思って読んだけど違うの？ 244 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:36:44 ] なら、そんな疑問は浮かばないだろ 245 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:39:59 ] Guy L Steel Jr.とC言語の関係が分からん 246 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:40:27 ] ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く まあ言語仕様の著者ではあるが無理感じるな 247 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:41:17 ] >>245 ANSI標準化 248 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:41:51 ] なぜSchemeが出ない 249 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:42:17 ] つか、何で知らないなら調べようとしないかね… 250 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:44:46 ] >>247 すまん、もうちょい詳しく 251 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:47:14 ] ググっても出てこないのはSteelじゃなくてSteeleだからだ 252 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:56:40 ] >>235 書いていないな。 そもそもあの本が書かれたのは95年頃で、 テンプレートによるコンパイル速度の低下は まだ問題になっていなかったのではないかと思う。 俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。 253 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 00:02:40 ] テンプレートこそC++の特徴であり価値の一つだと思うんだけど 254 名前：252 mailto:sage [2008/05/21(水) 00:09:26 ] >>253 そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、 実際、そんな機会は全然ないから 「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。 すれ違いすまん。 255 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 00:20:09 ] C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな… 256 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:45:37 ] そもそもGLSって略称一般的かなあ 257 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:56:54 ] スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない? 258 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 02:13:36 ] >>235 D&E 15.10 あたりで問題は認識しいるようですよ。 最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので ずいぶん良くなったと思います。 モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。 259 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 07:38:05 ] >>258 他の言語だってモジュール分けすればもっと速いよ C++ と違って小細工しなくても常識的な速さだけど 260 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 08:31:09 ] まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。 261 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 08:57:38 ] C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。 262 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 09:10:21 ] >>261 詳しく。 >>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。 263 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 09:20:06 ] C/C++は糞。 Cは必要悪だがC++は必要ですらない。 264 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 14:58:16 ] ベターCとしてのC++は悪くない ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを 使いまくる。 265 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 16:41:10 ] プロファイルを定義して違反したらコンパイル時にエラーか警告出すような 機能を付けてくれないかな。 266 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 17:59:57 ] ほほう、それでC++が晴れてベターCになれると。 267 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 19:36:41 ] >>266 問題点を指摘して、もっといい方法を教えてください。 268 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 20:26:33 ] >>262 >>>261 詳しく。 www.nobugs.org/developer/parsingcpp/ C++ 使いって基本的に自分で調べたり勉強したりしないよな… まあだからこそ未だに C++ をマンセー出来るんだろうけど 269 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:03:43 ] 全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？ 第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き ずっている部分だよ。D&E を読めば構文解析に配慮していることが分 かるよ。 270 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:10:14 ] 配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる けど特に就職活動とかしてない 271 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:10:59 ] >C++ の構文解析を複雑にしているのはほとんど C の文法を >引きずっている部分だよ Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。 ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。 272 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 14:36:52 ] 言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから 猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。 273 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 14:54:56 ] デファクトスタンダードと言う言葉を送ろう。 最近の悪例　Windows　　別に利用者がダメとは思わない。 274 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 18:38:08 ] さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。 EC++ の設計を見習うべきです。 275 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 21:04:40 ] つまりCをつかってりゃよかったって話なのか？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef