C言語を完全に駆逐す� ..
175:デフォルトの名無しさん
08/05/15 00:07:41
>>174
C だけ使えば C と同じ性能。
C++ でもよく使われる言い回し。
176:デフォルトの名無しさん
08/05/15 01:35:36
>>174
例えばある変数の値を、1から10000までカウントupみたいなのは、Cは高速。
理由はおおざっぱに言えば、処理時間=計算量*1計算あたりのクロック数 だから。
2次元テーブル(n行n列)の全スキャン計算量は、nの2乗に比例するからo(n^2)とか。
単純なカウントupの計算量は小さい。
一方、ライブラリに必ずしも無いもの(例:クロージャなど)が必要になると、
プログラマーがゼロから実装するのは負担が大きくて、他の方法で回避する。
回避策の計算量、1計算あたりのクロック数によっては、他の言語で記述した方が
早い場合もある。
↓参考:プログラミング言語ベンチマーク
URLﾘﾝｸ(shootout.alioth.debian.org)
177:デフォルトの名無しさん
08/05/15 02:38:24
>>71
古い話で恐縮だけれども、ICOTの例のプロジェクトでは prolog の進化形で **カーネルの大部分を** 記述していたとか。
そういう用途のシステムでは、そういう選択もあるようです。
＃同じ研究を現在のハードウェア技術で行ったらどうなるのかつくづく知りたいものですが、あと 100 年はとりあげられないでしょうか‥‥‥。
178:デフォルトの名無しさん
08/05/15 02:43:57
>>88
人を変態よばわりしないでください。
R6RS準拠のコンパイラがでたんですって？
179:デフォルトの名無しさん
08/05/15 08:35:10
Cに文句言うより86アセンブラをまず駆逐しろよ・・・
Intelでさえできなかったんだぞ
180:デフォルトの名無しさん
08/05/15 08:37:36
今時のCPUはアセンブラ（≒機械語）を直接実行せずに
自前の命令に変換するんでしょ。
そんな内部コードを毎度毎度表にさらしてたら大混乱が起こるんじゃね。
AMDの人も命令コードなんて全然大した問題じゃないとか言ってたし。
181:デフォルトの名無しさん
08/05/15 13:54:39
>173
> そういえば、.NETってなんとなくスルーしてたなぁ。
> 趣味として使うとしたら学ぶ価値ある？
プログラミングが趣味か、なんらかの成果物を完成させるのが趣味かで変わってくるんじゃ?
ﾄﾞﾄﾈﾄ系はWindowsのアプリを作るということなら、死ぬほど楽なのは確か。
特にC#とC++/CLIの楽さは異常。
182:173
08/05/15 18:43:57
>>181
レスさんくす。
C#でもかじってみるか。
（そういえばIronRubyはどうなったんだ？とんと話を聞かないが。）
183:デフォルトの名無しさん
08/05/16 18:44:40
開発言語をアセンブラからCに変えて解放されることって
１．レジスタの管理
２．メモリの管理
３．スタックの管理
くらいかな？
こうやってみるとCって意外と面倒な問題を解決してくれてることに気づくｗ
184:デフォルトの名無しさん
08/05/16 18:54:16
とりあえずage
185:デフォルトの名無しさん
08/05/16 19:23:40
CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。
186:デフォルトの名無しさん
08/05/16 19:30:17
namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。
IDEとの親和性も爆上がるし。
187:デフォルトの名無しさん
08/05/16 19:42:34
>>185
ただ、cppにはもうちょっと賢くなってほしいけどなあ。
あ、でもあんまり賢すぎるとlispみたいになんでもマクロで書いちゃう
人が出てくるからダメかな。
188:デフォルトの名無しさん
08/05/17 00:00:28
>>183
Cはメモリーもスタックも管理しないだろ
189:デフォルトの名無しさん
08/05/17 00:07:03
自動変数の事じゃないの
190:183
08/05/17 00:20:31
スタックの管理は自動変数、
メモリーの管理はmalloc&free,大域変数のつもりで書いた。
191:デフォルトの名無しさん
08/05/17 11:00:14
OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する
ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。
192:デフォルトの名無しさん
08/05/17 12:10:51
c++を駆逐してほしいんだが
193:デフォルトの名無しさん
08/05/17 12:38:39
学習コスト＜＜駆逐コスト
194:デフォルトの名無しさん
08/05/17 13:08:01
>>191
高級アセンブラが使われる環境を駆逐したいんじゃない？
195:デフォルトの名無しさん
08/05/17 13:17:15
入れ子が{}じゃなくて
ポインタが*じゃないC言語ください
196:デフォルトの名無しさん
08/05/17 13:35:32
なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。
些細なデメリット避けるために大きなメリットを失っている。
197:デフォルトの名無しさん
08/05/17 13:53:06
The C Programming Language 274ページ
URLﾘﾝｸ(www.amazon.co.jp)
The C++ Programming Language 1030ページ
URLﾘﾝｸ(www.amazon.co.jp)
この厚さの差が問題だと思うけどな。スピードを求めるならCで書けばいいし、そうで
ないならJavaとか使えばいいかと思う。C++は何でも屋であるが故に駆逐されつつある。
198:デフォルトの名無しさん
08/05/17 13:53:49
>>192
今田舎に別荘を建てて隠遁する準備が進んでいるよ
200x 年には完成する見込みらしい
199:デフォルトの名無しさん
08/05/17 14:01:51
>>196
C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない
特にリンクやロードが遅いのは致命的
MISRA-C++ とか JSF++ って日本語の解説無いのかな
200:デフォルトの名無しさん
08/05/17 14:37:41
C+αとして使えば全く速度は変わらないし生産性はかなり上がると思っている。
むしろプログラムを自然に作れば C++ の方が速いと思っているぐらいです。
リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん
じゃない?
201:デフォルトの名無しさん
08/05/17 14:51:55
>>200
>リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん
>じゃない?
世間の C++ 使いって所詮この程度の認識なんだよね…
自分が使っている道具に対する関心が無さ過ぎ
>全く速度は変わらないし
だからこんなことを平気で言えてしまうわけだな
202:デフォルトの名無しさん
08/05/17 15:39:45
そういうのはいいから説明してくれよ
203:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/05/17 19:13:25
dhrystone で測れるのはループの中の計算時間だけだからね
205:デフォルトの名無しさん
08/05/17 19:27:25
ループの中で結構関数呼び出しもしてるよ。
206:デフォルトの名無しさん
08/05/17 19:28:51
リンクやロードも?
207:デフォルトの名無しさん
08/05/17 20:04:19
>>200
C+αなんかではなく、ポテンシャル全開でC++を使うときの
コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。
残りの半分は実装の問題。
208:デフォルトの名無しさん
08/05/17 21:51:56
＋αでない残りのポテンシャルの部分って具体的に何よ？
例外とか？
209:デフォルトの名無しさん
08/05/17 21:54:58
テンプレートじゃね？
210:デフォルトの名無しさん
08/05/17 23:04:00
>>206
リンクは C が 0.10257s で C++ が 0.10281s です。
ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。
>>208
コンパイルで一番負担がかかるのは圧倒的にテンプレートだと思います。
boost::spirit のように凝ったテンプレートをインクルードしたファイルは
極端に時間がかかります。
遅いだけあってテンプレートの可能性は絶大なのですが。
VCの場合はテンプレートでオブジェクトファイルも大きくなるようです。
ただしリンク後は実行ファイルはそれほど大きくなりません。
211:デフォルトの名無しさん
08/05/18 01:34:45
>>195
入れ子が begin end,
ポインタが ^ でもいい？
212:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/05/18 11:03:42
VC は優秀だな。
215:デフォルトの名無しさん
08/05/18 12:21:33
いろんな分野でC++はPythonに置き換わりつつあるな
Rubyなんてのを与えられた日本人は世界から置いてけぼり
216:デフォルトの名無しさん
08/05/18 12:30:09
何のスレだここは
217:デフォルトの名無しさん
08/05/18 13:43:40
cソースはcppソースに変換後にコンパイルされるんだが。
218:デフォルトの名無しさん
08/05/18 14:59:17
cpp ってCプリプロセッサのこと?
確かに gcc はそういう手順になっていると思います。
219:デフォルトの名無しさん
08/05/18 16:06:49
>>214
C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど…
アセンブラ出力かシンボルダンプが見てみたいね
>>218
.cpp の事でしょう
何となく何でこうなってるのかは予想がつくけど…
220:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/05/18 19:32:20
>>220
ちゃんと C++ としてコンパイルしてる?
共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、
何でも良いけど晒してみて。最適化オプション無しだとどうなる?
222:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/05/19 00:33:34
tccを使えば解決、と言ってみる。
URLﾘﾝｸ(alohakun.blog7.fc2.com)
224:デフォルトの名無しさん
08/05/19 00:46:36
>>222
ウィンドウズは知らないけど、うちの環境だとアセンブラ出力も
シンボル名もライブラリのリンクもベンチマークのスコアも変わる。
純粋に C だけのコードでこれだから、Better C として C++ の
機能を混ぜた使い方（例えば例外処理や名前空間）をすれば
更に悪化する物と期待出来る。ウィンドウズで組み込みなら
C++ でも変わらないかもね。あとは Symbian とか。
まあ Better C って考え方は他にも落とし穴があるから、俺は
好きじゃないな。
225:デフォルトの名無しさん
08/05/19 14:40:12
>>224
OS というよりもほとんどの場合コンパイラとリンカで決まると思います。
(Windows の場合は実行時の最適化もやりかねないけど)
組込み向けコンパイラの場合は信じられないくらい最適化がダメなものも
あるようです。5,6年前にある有名 CPU 向けの純正コンパイラーを使った
とき、register 付きローカル変数を使っただけで命令がかなり削減された
ことがありました。VC ではとても考えられないし、いまどき register を
使おうと思う人も少ないと思います。
昔の話なので今の組込み環境がどうなっているのかよく分かりませんが。
> Better C って考え方は他にも落とし穴があるから
技術的にはそれほど大きな問題もないと思っているのですが、興味深いので
よかったら教えていただけませんか?
226:デフォルトの名無しさん
08/05/19 20:31:42
その駄目コンパイラ…
気になる…
227:デフォルトの名無しさん
08/05/20 13:43:51
>>201
C++がCと比較してほとんど性能を落とさない理由は以下の本を読むとよく分かります。
またなぜC++をこのような設計にする必要があったのかも詳しく書いてあります。
C++の設計と進化
URLﾘﾝｸ(www.amazon.co.jp)
星の数が胡散臭く感じるかもしれませんが読む価値はあると思います。
228:デフォルトの名無しさん
08/05/20 18:25:10
あーその本、もってるけど全然読んでないな。
ちゃんと読んでみるかな。
229:デフォルトの名無しさん
08/05/20 18:59:36
>>227
C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。
230:デフォルトの名無しさん
08/05/20 19:08:21
AT&T に居たんだから Aho なりに相談すれば良かったのにな
231:デフォルトの名無しさん
08/05/20 19:08:45
暴言ｷﾀ━＞▽＜━━
232:デフォルトの名無しさん
08/05/20 19:15:22
いやだってやたらと信じやすい人が居たから…
C++ をマンセーするのも良いけど程々にね
233:デフォルトの名無しさん
08/05/20 19:37:24
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。
234:デフォルトの名無しさん
08/05/20 20:21:11
あ、いちいち最後に改行を付け加えてる人の事な。
ストラウストラップが GLS の 1/10 でも言語設計の知識があったら
あんなコンパイルが糞遅くなる事も無かっただろうさ。
235:デフォルトの名無しさん
08/05/20 20:23:45
>>234
下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？
236:デフォルトの名無しさん
08/05/20 21:42:19
GLS がストラウストラップ 1/10 でも現実を見ていれば
あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。
237:デフォルトの名無しさん
08/05/20 22:08:58
C のどこが起動が遅いって?
238:デフォルトの名無しさん
08/05/20 22:15:11
なんでCが出てくるんだ
239:デフォルトの名無しさん
08/05/20 22:20:34
>>238
GLS 知らんのか?
240:デフォルトの名無しさん
08/05/20 22:27:31
ぐぐったら、
予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た
とりあえずガールズラブサーチ見てる
241:デフォルトの名無しさん
08/05/20 22:32:21
起動は?
242:デフォルトの名無しさん
08/05/20 22:50:13
>>225
>OS というよりもほとんどの場合コンパイラとリンカで決まると思います。
だから環境って書いただろ…
ナチュラルに斜め下の指摘をするのは止めてくれ
243:デフォルトの名無しさん
08/05/20 23:29:12
>>239
Guy L Steel Jr.の事だと思って読んだけど違うの？
244:デフォルトの名無しさん
08/05/20 23:36:44
なら、そんな疑問は浮かばないだろ
245:デフォルトの名無しさん
08/05/20 23:39:59
Guy L Steel Jr.とC言語の関係が分からん
246:デフォルトの名無しさん
08/05/20 23:40:27
ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く
まあ言語仕様の著者ではあるが無理感じるな
247:デフォルトの名無しさん
08/05/20 23:41:17
>>245
ANSI標準化
248:デフォルトの名無しさん
08/05/20 23:41:51
なぜSchemeが出ない
249:デフォルトの名無しさん
08/05/20 23:42:17
つか、何で知らないなら調べようとしないかね…
250:デフォルトの名無しさん
08/05/20 23:44:46
>>247
すまん、もうちょい詳しく
251:デフォルトの名無しさん
08/05/20 23:47:14
ググっても出てこないのはSteelじゃなくてSteeleだからだ
252:デフォルトの名無しさん
08/05/20 23:56:40
>>235
書いていないな。
そもそもあの本が書かれたのは95年頃で、
テンプレートによるコンパイル速度の低下は
まだ問題になっていなかったのではないかと思う。
俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。
253:デフォルトの名無しさん
08/05/21 00:02:40
テンプレートこそC++の特徴であり価値の一つだと思うんだけど
254:252
08/05/21 00:09:26
>>253
そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、
実際、そんな機会は全然ないから
「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。
すれ違いすまん。
255:デフォルトの名無しさん
08/05/21 00:20:09
C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな…
256:デフォルトの名無しさん
08/05/21 01:45:37
そもそもGLSって略称一般的かなあ
257:デフォルトの名無しさん
08/05/21 01:56:54
スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない?
258:デフォルトの名無しさん
08/05/21 02:13:36
>>235
D&E 15.10 あたりで問題は認識しいるようですよ。
最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので
ずいぶん良くなったと思います。
モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。
259:デフォルトの名無しさん
08/05/21 07:38:05
>>258
他の言語だってモジュール分けすればもっと速いよ
C++ と違って小細工しなくても常識的な速さだけど
260:デフォルトの名無しさん
08/05/21 08:31:09
まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。
261:デフォルトの名無しさん
08/05/21 08:57:38
C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。
262:デフォルトの名無しさん
08/05/21 09:10:21
>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。
263:デフォルトの名無しさん
08/05/21 09:20:06
C/C++は糞。
Cは必要悪だがC++は必要ですらない。
264:デフォルトの名無しさん
08/05/21 14:58:16
ベターCとしてのC++は悪くない
ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。
265:デフォルトの名無しさん
08/05/21 16:41:10
プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。
266:デフォルトの名無しさん
08/05/21 17:59:57
ほほう、それでC++が晴れてベターCになれると。
267:デフォルトの名無しさん
08/05/21 19:36:41
>>266 問題点を指摘して、もっといい方法を教えてください。
268:デフォルトの名無しさん
08/05/21 20:26:33
>>262
>>>261 詳しく。
URLﾘﾝｸ(www.nobugs.org)
C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど
269:デフォルトの名無しさん
08/05/22 03:03:43
全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。
270:デフォルトの名無しさん
08/05/22 03:10:14
配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない
271:デフォルトの名無しさん
08/05/22 03:10:59
>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。
ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。
272:デフォルトの名無しさん
08/05/22 14:36:52
言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。
273:デフォルトの名無しさん
08/05/22 14:54:56
デファクトスタンダードと言う言葉を送ろう。
最近の悪例 Windows 別に利用者がダメとは思わない。
274:デフォルトの名無しさん
08/05/22 18:38:08
さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。
275:デフォルトの名無しさん
08/05/24 21:04:40
つまりCをつかってりゃよかったって話なのか？
276:デフォルトの名無しさん
08/05/26 00:11:25
その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。
277:デフォルトの名無しさん
08/05/26 00:29:03
言いたいことは分かる気がする。
俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。
278:デフォルトの名無しさん
08/05/26 07:31:34
赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ
279:デフォルトの名無しさん
08/05/26 10:32:00
>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？
280:デフォルトの名無しさん
08/05/26 17:37:34
>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。
それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが
281:デフォルトの名無しさん
08/05/26 18:20:57
古い言い伝えを思い出すな。
紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。
282:デフォルトの名無しさん
08/05/26 18:35:03
AとBはどこ行った?w
283:デフォルトの名無しさん
08/05/26 19:40:52
勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな
284:デフォルトの名無しさん
08/05/26 22:53:10
駆逐できそうにないですね
285:デフォルトの名無しさん
08/05/26 23:09:44
>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。
286:デフォルトの名無しさん
08/05/26 23:23:47
>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･
287:デフォルトの名無しさん
08/05/27 09:00:15
そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。
288:デフォルトの名無しさん
08/05/27 20:27:43
CプログラマがC++を使わない理由を探す理由を知りたい。
289:デフォルトの名無しさん
08/05/27 20:47:04
その前に>>288がなぜそんなことを聞くのか理由を知りたい
290:デフォルトの名無しさん
08/05/27 20:50:18
>>288組み込み系では、Cが最適開発環境であることは多い。
291:デフォルトの名無しさん
08/05/27 21:49:33
CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。
292:デフォルトの名無しさん
08/05/27 22:07:11
C言語と日本語と英語が使えます。
293:デフォルトの名無しさん
08/05/27 23:42:22
その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。
職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。
294:デフォルトの名無しさん
08/05/27 23:58:49
うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。
295:デフォルトの名無しさん
08/05/28 00:17:12
考えるのがめんどくさい
息をするのもめんどくさい
296:デフォルトの名無しさん
08/05/28 00:20:34
ゆうちゃんとめんどくさいさい
297:デフォルトの名無しさん
08/05/29 20:16:05
組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？
298:デフォルトの名無しさん
08/05/29 20:44:31
GBAのときはCの方がC++より多かったと思う。今は分からない。
299:デフォルトの名無しさん
08/05/29 21:27:12
なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん
300:デフォルトの名無しさん
08/05/29 22:48:42
>>299
>携帯電話を組み込み系と言ったら笑われたり
そうなの？ カーナビと携帯は組み込みの2大巨頭だと思ってたよ。
301:デフォルトの名無しさん
08/05/29 23:55:42
「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする
302:デフォルトの名無しさん
08/05/30 00:39:26
>組み込みで使うとかいわれても幅が広くてわかりにくいんだが
幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。
303:デフォルトの名無しさん
08/05/30 01:27:45
>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。
正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。
304:デフォルトの名無しさん
08/05/30 01:42:25
アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。
305:デフォルトの名無しさん
08/05/30 18:08:50
C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。
- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)
306:デフォルトの名無しさん
08/05/30 18:09:21
C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。
自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変
307:デフォルトの名無しさん
08/05/30 21:23:52
さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい
308:デフォルトの名無しさん
08/05/30 21:38:24
C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。
309:デフォルトの名無しさん
08/05/30 21:53:45
ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。
310:デフォルトの名無しさん
08/05/30 21:56:59
>>308
どのレスの話？
311:デフォルトの名無しさん
08/05/30 22:19:31
>>308 それは言語の欠点ではなく俺の欠点だ。
>>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。
しかしこれ以外の本よく読んでいる。
コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。
そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。
さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。
C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。
312:デフォルトの名無しさん
08/05/30 22:30:05
>>305
>逆にこれらを使わなければ
C でオケ
313:デフォルトの名無しさん
08/05/30 23:15:52
>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。
314:デフォルトの名無しさん
08/05/30 23:57:34
Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。
315:デフォルトの名無しさん
08/05/31 01:04:39
抽象化＝クラスと信じて疑わないのがきもい
316:デフォルトの名無しさん
08/05/31 01:25:34
>>312, >>313
>>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。
後は徐々に使う機能を増やしていけばよい。
特にデストラクタの利用は効果的だ。
317:デフォルトの名無しさん
08/05/31 02:27:19
>>313
実は>>305は最後の項を除くと割りと簡単にルールを説明できる。
- コンストラクタ、デストラクタ、非 static メンバー関数を定義しない
- 多重継承を使わない
- 演算子 .* と ->* を使わない
- try, catch, throw を使わない
- inline 関数を定義しない
- template を使わない
最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。
318:デフォルトの名無しさん
08/05/31 03:05:12
>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
ﾜﾗﾀw
319:デフォルトの名無しさん
08/05/31 04:46:23
・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。
でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな
共同作業時の問題とか考えると尚更なあ
OOPの幻想
デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司
JavaScriptなんて素人の言語だとか時代遅れな事いいやがって
手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う
間違った仕様書いといて実装に逆切れしやがって 徹夜して直すと自己管理ミスとかもうね
原付のブレーキ切ったろか
切るべきか 切るべきだな けけけけけけ
>>316
ﾜﾗ太
320:デフォルトの名無しさん
08/05/31 05:15:39
C++否定側の皮肉なジョークだろ？>>305,>>316
321:デフォルトの名無しさん
08/05/31 14:01:59
すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。
322:デフォルトの名無しさん
08/05/31 19:51:13
>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。
323:デフォルトの名無しさん
08/05/31 20:09:07
>>320 決してジョークではない
今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。
- 生成されるコードが大きくて遅い(例えベターCとして使っても)
- 暗黙の処理によって生成されるコードやリソースが予想しにくい
コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを
C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。
(ただし最適化の出来が悪いとそうならないときがある)
しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを
エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。
予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。
- うっかりミスの防止する機能
非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照
- プログラムを組織化し、大規模化しやすくする機能
継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間
- あれば便利、見通しをよくする機能
関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名
これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。
324:デフォルトの名無しさん
08/05/31 20:21:23
>>323
>決してジョークではない
ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ
325:デフォルトの名無しさん
08/05/31 20:26:55
なら見るのを止めるのがおすすめ
326:デフォルトの名無しさん
08/05/31 20:30:07
やっぱりネタかよw
327:デフォルトの名無しさん
08/05/31 20:34:48
C++を知らないから使っていないんだという前提が痛過ぎる
328:デフォルトの名無しさん
08/05/31 20:40:41
>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?
329:デフォルトの名無しさん
08/05/31 20:46:37
ここはC++を無理矢理Cとして使うスレだっけ?
330:デフォルトの名無しさん
08/05/31 21:28:23
いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。
普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。
331:デフォルトの名無しさん
08/05/31 21:36:05
時折Objective-Cを思い出しては、絶望するスレ。
332:デフォルトの名無しさん
08/05/31 22:17:11
ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね
333:デフォルトの名無しさん
08/05/31 22:18:00
字面がｷﾓすぎ
334:デフォルトの名無しさん
08/05/31 22:25:31
事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える
C++やC#とは狙いが違う感じ
335:デフォルトの名無しさん
08/05/31 22:26:07
ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。
336:デフォルトの名無しさん
08/05/31 22:28:02
どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど
337:デフォルトの名無しさん
08/05/31 22:30:24
>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ
338:デフォルトの名無しさん
08/05/31 22:44:40
C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。
339:デフォルトの名無しさん
08/05/31 23:03:54
Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?
340:デフォルトの名無しさん
08/05/31 23:05:18
どのルート？
341:デフォルトの名無しさん
08/05/31 23:09:53
Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。
342:デフォルトの名無しさん
08/05/31 23:12:46
C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。
343:デフォルトの名無しさん
08/06/01 00:06:27
CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要
344:デフォルトの名無しさん
08/06/01 00:08:52
VCは要らん
345:デフォルトの名無しさん
08/06/01 00:42:17
>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。
346:321
08/06/01 11:47:24
>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。
347:デフォルトの名無しさん
08/06/01 12:01:43
間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。
348:デフォルトの名無しさん
08/06/01 13:00:25
C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。
349:デフォルトの名無しさん
08/06/01 14:36:50
Why I No Longer Like or Use C++
URLﾘﾝｸ(www.hyuki.com)
350:デフォルトの名無しさん
08/06/01 14:55:59
>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。
351:デフォルトの名無しさん
08/06/01 15:00:47
>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。
352:デフォルトの名無しさん
08/06/01 15:03:35
原文のほう見ると
URLﾘﾝｸ(prophipsi.blogspot.com)
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。
353:デフォルトの名無しさん
08/06/01 15:07:09
うーん、やはり見えない敵と戦うタイプだな。
いっそこのスレに呼べばいいんじゃないか？
Another common theme among the posters was that one can get by just
fine in C++ by ignoring the more complicated aspects of C++ and just
focusing on the basic procedural and object oriented features of C++.
In practice this means never touching templates and focusing on class
and function based abstractions. I guess use of exceptions and MI
would be optional and handled on a case by case basis.
I actually don't have a problem going this route. The problem is that
this is NOT the route that the C++ standards people are going and it
certainly isn't the route the C++ literati/intelligentsia are going.
354:デフォルトの名無しさん
08/06/01 15:50:27
>>351
>言語が単純で、枯れていて、速くて、資産が沢山あって、
>スクリプト言語との連携が良いからだよ。
>>317で残った部分は十分に単純で枯れているぞ。
そして速さはCと同じでCとC++の資産も使えるぞ。
スクリプト言語との連携もインタフェース部分だけ
extern "C" すればいいぞ。
>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?
355:デフォルトの名無しさん
08/06/01 16:11:02
「残った部分」とかんな抽象的な。
言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。
356:デフォルトの名無しさん
08/06/01 16:23:52
>>354
>>>317で残った部分は十分に単純で枯れているぞ。
もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。
357:デフォルトの名無しさん
08/06/01 16:27:45
もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。
358:デフォルトの名無しさん
08/06/01 16:32:12
>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる
それならCのほうがずっといい
無論C99ではなくC89な
359:デフォルトの名無しさん
08/06/01 16:40:41
10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。
360:デフォルトの名無しさん
08/06/01 18:44:34
>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265
>これ禁止なら素直にCを使ったほうが早い。
個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。
361:デフォルトの名無しさん
08/06/01 18:45:01
>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる
まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。
362:デフォルトの名無しさん
08/06/01 19:35:33
> ABIの問題はC++の利点に比べれば小さいことだと思ってる。
いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。
C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
363:デフォルトの名無しさん
08/06/01 23:48:27
>>362
>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。
ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。
>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5377日前に更新/141 KB
担当:undef