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

1 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 20:11:42 ] どうすればいい？ 151 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:18:03 ] コレクションもなく文字列操作も冗長で正規表現も標準で無いとかふざけすぎ。 エラートラップをするにしてもエラーコードびっしりで冗長極まりない。 例外を使わせろよ。C++みたいにfinallyの無いなんちゃって仕様じゃない奴。 152 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:29:53 ] そこで組み込みスクリプト言語ですよ 153 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 02:02:19 ] >>151 finallyも使いやすいとは思えないけどな。 C#のusingとかDのscopeとかみたいな仕組みくらいのほうがいい。 C++デストラクタもまああり。 154 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 05:06:38 ] C++はネイチブ生成の宿命があるのに その場合エラー専用処理がものすごく非効率って問題が 155 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 09:01:09 ] >>153 んなもんケースによるだろ。 ケースによるのにfinallyがないのが糞なんだよ。 156 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 09:42:43 ] finally相当の機能なら、C++/CLIでついたんじゃなかったっけ? 157 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 10:34:32 ] まるでC++/CLIがC++の後継みたいな言い方だな 158 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 13:30:06 ] C++/CLIはC++じゃない 159 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 15:37:48 ] >>150 それだけみんなCに不満もってるってことだ。 総力を挙げて潰さないとこの業界に未来はないよ。 160 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 16:04:13 ] 形式仕様から、最終的にバイナリコード(FPGAベースのチップ向けの)を 生成する研究が実用化されれば、Cだけでなく、現状のほとんどの言語を使わなくなる。 プログラミングは、「問題領域向けのDSLを記述+DSLで動作記述」になるよ。 161 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:24:35 ] 問題領域向けのDSLを記述+DSLで動作記述 ↑ これのコンパイラは結局Cでかかれると。 162 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:27:14 ] 最近は言語処理系は関数型言語か C++ で書くのが流行の様だよ C++ がもう少しまともだったらな 163 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:29:28 ] コンパイラはリッチな環境の上で動かせるから選択肢の数が全然違う 164 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:57:24 ] C言語で開発しとけばなんかあったとき安心、見たいのがあるのかね？ 性能をどうしてもあと１０％上げなきゃいけない、なんてときもCなら何とかなるとか。 165 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:02:28 ] Cで書いた所でそれ程ハードルが高くなる訳じゃない 特に拘りがないだけじゃないの 166 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:33:09 ] 俺はCだとハードルかなり高くなる。 それで飛び越えられなくなるわけじゃないとしても、いちいち高めにジャンプしなきゃいけないのがむかつく。 167 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:47:37 ] コンパイラをCで書くとか、嗜虐癖があるとしか思えん 168 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:49:54 ] >>164 C で書いておけば色んな言語と混ぜられる。 C のルーチンを LL から呼び出すのは至極楽ちん。 169 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:07:14 ] 前にRubyからCのルーチン呼ぼうとしたらSWIGとかいうの使う羽目になった。 配列とか使ってたから、変換用のコーディングも若干必要になったし。 大変というほどでも無いが至極楽ちんというほど楽ちんでもないような。 170 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:15:07 ] CはLLのインラインアセンブラや〜 171 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:35:22 ] >>168 C#とPowerShellその他.NETなLLの親和性は異常 CというかシステムコールをOOなLLでラッピングとかもう面倒でやってらんない 172 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:56:55 ] 何でシステムコールが出てくる？ シスコール生で叩かせるLLなんてあるのか？ 173 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:57:26 ] >>171 そういえば、.NETってなんとなくスルーしてたなぁ。 趣味として使うとしたら学ぶ価値ある？ 普段はRuby使ってます。 174 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:58:22 ] >8 ＞Cのパフォーマンス これほんと？ 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だからだ

---

---

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

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