08/09/13 22:18:14
>>49
クラステンプレートに仮想関数を持たせることはできるよ。
メンバテンプレートで仮想関数は無理だけど。
51:デフォルトの名無しさん
08/09/14 10:42:46
世の中の天才PGみてるとC++なんて使わずC使ってるからなぁ
52:デフォルトの名無しさん
08/09/14 10:46:01
天才だからCとかアセンブラで十分なんだよ
その人達みたいにCを使いこなすよりはC++をそれなりに使えるようになる方がまだ簡単
53:デフォルトの名無しさん
08/09/14 11:28:46
天才は1人でシステム開発するでしょ。だからCで十分なんだよ。
54:デフォルトの名無しさん
08/09/14 11:55:23
少人数の開発に向いてるのはLisp
55:デフォルトの名無しさん
08/09/14 12:13:14
ほとんどの場合、Cでいいよね
C++とかJavaとかって、無駄にクラスを作ったり無駄にソースコードを
増やして、開発量水増しするために使うもんだと思ってる。
56:デフォルトの名無しさん
08/09/14 12:21:26
本気で言ってるのかマジレスなのか非常に気になるが・・・・
オブジェクト指向の言語の必要性を感じてないんか？
それからC++はマルチパラダイム言語と呼ばれるように
非常に懐の広い言語なんだが
57:デフォルトの名無しさん
08/09/14 12:34:59
tmpによる静的モデル検証とか使い熟せれば便利だと思う
言語内DSLなんていまじゃ別に奇なものでないしね
あと名前空間とか激しく便利だね、XXX_YYY_ZZZとか書かなくてすむし
でもSTL, boost, TMPとか使わずにC++使うぐらいならC99の方が100倍マシだ
58:デフォルトの名無しさん
08/09/14 17:29:57
そもそもC++が幅利かせてるのってwindowsくらいだろ。
UNIXの世界じゃたんなる一選択肢的な感じだし。
59:デフォルトの名無しさん
08/09/14 17:37:00
>>56
単にオブジェクト指向っぽくすることだけが目的になってない？
なんのためのオブジェクト指向か分ってる？
60:デフォルトの名無しさん
08/09/14 17:41:46
マルチパラダイムと称して
いきあたりばったりに機能拡張した感が否めない
61:デフォルトの名無しさん
08/09/14 18:49:18
>>56
C++は書く人がOOPを意識して書けばOOPになるってだけで
実際には>>55のような工数の水増しのネタにされているんだろうなぁ
62:デフォルトの名無しさん
08/09/14 19:27:14
なんにでも使えるものはなんの役にも立たないってやつ？
63:デフォルトの名無しさん
08/09/14 19:28:35
Javaほど急速じゃないけどCOBOL化が着々と進んでる気がする。
64:デフォルトの名無しさん
08/09/14 20:17:42
むしろC++がノロノロと次世代の仕様を作成している間にJavaがここまで肥えるとは思わなかった
65:デフォルトの名無しさん
08/09/14 20:43:25
まぁあんだけ群がればピザりまくるに決まってる
66:デフォルトの名無しさん
08/09/14 21:47:41
>>62
その状態になっていると思う
67:デフォルトの名無しさん
08/09/14 22:02:54
塩は料理から凍結防止ガラス作りまでなんにでも使えるよ。
68:デフォルトの名無しさん
08/09/14 22:34:49
Objective-C > C++
69:デフォルトの名無しさん
08/09/14 22:37:32
まっかさんはどっかいってね
70:デフォルトの名無しさん
08/09/14 22:50:00
オブジェクト指向度マップ
<--- 構造化 オブジェクト指向 --->
C C++ Java C# OC Smalltalk
71:デフォルトの名無しさん
08/09/14 22:59:56
スモールトークに需要あるのー
72:デフォルトの名無しさん
08/09/14 23:39:00
えいふぇるはどの辺に位置するの？
73:デフォルトの名無しさん
08/09/15 00:00:54
実際に Smalltalk に需要があるかどうかは関係なく、
・実行時にメッセージスロットを検索に行く
言語の代表として、歴史的な経緯から使われているに過ぎないのだろう。
Self とか Lua とか JavaScript でも文脈としては問題ないが、先輩に応分の敬意を払わないと非難を受けることだろう。
表面の文法の問題ではないということね。
74:デフォルトの名無しさん
08/09/15 00:30:00
>>69
Objective-C >>>>> C++
75:デフォルトの名無しさん
08/09/15 01:05:26
すごいね
76:デフォルトの名無しさん
08/09/15 01:36:54
初心者向け度って意味ね
77:デフォルトの名無しさん
08/09/15 06:21:16
C++0xになったらそろそろ標準の文字列クラスぐらい出てきますよね。
78:デフォルトの名無しさん
08/09/15 07:38:39
完全なコンパイル言語でオブジェクト指向やろうとするとC++が限度ってこと。
OCなんてC+オブジェクト指向インタプリタだし。
79:デフォルトの名無しさん
08/09/15 11:53:25
>>77
相変わらずstd::basic_stringです。
80:デフォルトの名無しさん
08/09/15 13:37:13
>>78
それに加えて C とある程度の互換を持たせるという縛りもきつ過ぎる
81:デフォルトの名無しさん
08/09/15 17:12:29
そもそもSTL理念に必要最低限って書いてあったけど。
JAVAやドトネト並みの網羅されたクラスライブラリがあるだけでぜんぜん違うのに
82:デフォルトの名無しさん
08/09/16 21:41:32
でもでかいランタイムが必要だと選択肢から外れちゃうよ
83:デフォルトの名無しさん
08/09/17 21:43:17
>>82
それは人それぞれなのでは？
84:デフォルトの名無しさん
08/09/17 22:16:09
>>83
当然そうだよ
ターゲットの環境や用途等にもよるし
85:デフォルトの名無しさん
08/09/18 00:18:59
>>82が結局何を言いたいのかが分からない
86:デフォルトの名無しさん
08/09/18 04:11:14
そりゃそのライブラリのために30MBのDLLが必要だったら困るじゃんって話でしょ。
再配布のライセンスとか、インストールが必要なのかとか他のアプリに影響与えないか
とかも重要だし。
87:デフォルトの名無しさん
08/09/18 07:50:55
巨大なライブラリがあればもっと可能性が広がるのにって言ってる相手に
それは使えない可能性もあるって言ってなんか意味あるの？
88:デフォルトの名無しさん
08/09/18 08:07:26
boostも便利なんだけどさ、amazonにSOAPで繋げて商品情報をGUIで一覧表示したいんだけど、
とか思うとまったく機能が足りてないんだよなあ。
89:デフォルトの名無しさん
08/09/18 20:07:10
WTLとか、iostream使ったソケットプログラミングとか、
やろうと思えばいろいろ発展できそうなのにいまいちまとまりがない。
それが++
90:デフォルトの名無しさん
08/09/18 20:11:50
大きくなると、まとまりがなくなるのは
どんな言語にもある。
91:デフォルトの名無しさん
08/09/18 21:37:33
>>87
その大きさが可能性を狭めることもあるって言ってるんでしょ
92:デフォルトの名無しさん
08/09/18 23:30:47
>>91
馬鹿なの？
93:デフォルトの名無しさん
08/09/18 23:38:26
馬鹿はお触り禁止
放置しましょう
94:デフォルトの名無しさん
08/09/18 23:43:34
>>91の何がおかしいかがわからないので教えてください
95:デフォルトの名無しさん
08/09/19 00:02:15
>>81からの流れを例えで表すと
>>81 巨大重機(ライブラリ)があればビル建てるときも楽になるのにね
>>82 でもそんな巨大だと民家建てる時に困るじゃん
>>83 そんなの当たり前じゃないの？
>>84 当たり前だよ
>>85 結局>>82はそんな当たり前の事言いたかったの？
>>86 だから>>82は巨大重機じゃ民家建てる時に困るって言ってるんだよ
>>87 だからそんな当たり前の事言って何の意味があるの？
>>91 だから大きいと困る可能性もあるって言ってるんでしょ
>>92 馬鹿なの？
96:デフォルトの名無しさん
08/09/19 00:13:32
ああなるほど
言語と一体化したようなライブラリでなければ>>95のような話だね
昔のVBや現在のドットネットを選択肢から外す状況を想定してた
97:デフォルトの名無しさん
08/09/19 00:34:44
>>82はクラスライブラリが欲しいって話から
何時の間にか言語仕様上巨大なランタイムが必須ってとこまで飛躍してたのな。
そんなことしたらC++の存在意義が無くなるだけじゃんｗ
98:デフォルトの名無しさん
08/09/19 02:23:31
C/C++だってランタイムは必要だぜ。
ライブラリモジュールを、配布プログラムに必ず含めなければならないとなれば大きいのは困るけど、
基本モジュールは別途インスコしておいて、アプリはそいつ必要に応じてリンクするのがやっぱりベストな気がするな。
OS以外の基本モジュールはNGなんて環境は相当特殊だろうし。
99:デフォルトの名無しさん
08/09/19 03:23:43
Vista64bit使ってると.NETのありがたみが分かってくる。
一部のプログラム以外、.NETのほうが便利だし、
わざわざ32bit, 64bitとリリースを分けるまでもなく
VMが適当に最適化を行ってくれる。
C:\Program Files (x86)\フォルダに入ることもない。
100:デフォルトの名無しさん
08/09/19 11:31:11
結局C言語と.NETがあれば十分じゃね？
C++はもう休めばいいよ
101:デフォルトの名無しさん
08/09/19 11:42:16
携帯とかゲームとか組み込みとか色々あるから
ちっとも十分じゃない
102:デフォルトの名無しさん
08/09/19 11:45:58
嫌C++厨必死ｗｗ
現実を見ろよ
どこのコンパイラメーカもC++無しでは食っていけない
103:デフォルトの名無しさん
08/09/19 14:40:34
必死さで言うと･･･いやなんでもない
104:デフォルトの名無しさん
08/09/19 15:22:13
醜いC++がしぶとく生き残る様は丁度アーキテクチャが汚い
x86がしぶとく生き残る様子に似ているかもしれない
105:デフォルトの名無しさん
08/09/19 18:03:22
>>81
ｽﾚﾘﾝｸ(tech板)
106:デフォルトの名無しさん
08/09/19 18:07:47
>>81
つ[D&E]
107:デフォルトの名無しさん
08/09/19 18:33:01
D&Eはただのいいわけ本
ページを捲るたびに「ハイハイワロスワロス」って感想しか出てこない
108:デフォルトの名無しさん
08/09/19 18:40:48
と言語の一つも設計した事のないカスがほざいております
109:デフォルトの名無しさん
08/09/19 18:45:31
OS選ばないのが前提。
110:デフォルトの名無しさん
08/09/19 19:02:10
java…
111:デフォルトの名無しさん
08/09/19 23:40:26
>>104
C++が醜いですか？
たとえば何が綺麗なの？
確かにx86は汚い
モトローラの68K系とかのアーキテクチャの方がすっきりして綺麗だった
でもほとんどの人が機械語やアセンブラに直接触れない今では
ソフトウェアから見たアーキテクチャの一貫性などの重要度が低くなったのでx86は生き残ったんだ
C++とは状況が違うと思うよ
共通点は、捨てるのが怖いほど既に投資してしまったこと
112:デフォルトの名無しさん
08/09/20 01:14:28
x86の機械語体系は確かにグチャグチャだが、ハードウェア
アーキテクチャに限定して話をすれば80386以降は比較的
まともになったと思うよ。
113:デフォルトの名無しさん
08/09/20 07:20:22
Alpha最高
114:デフォルトの名無しさん
08/09/20 17:39:43
AMD64 はすっきりしたんじゃない？
115:デフォルトの名無しさん
08/09/20 18:49:12
AMD（笑）
116:デフォルトの名無しさん
08/09/20 21:48:29
C++最大の成功と失敗はCとの互換性だなあ。
あと時代が古いせいでいろんな事情を言語に載せてしまったように思える。
だからDはもうちょっとがんばって安心して使用できるように配慮してほしい。
117:デフォルトの名無しさん
08/09/20 21:50:28
ああそれなら心配いらない
D言語なんて「絶対に」マイナーなままで終わるから
118:デフォルトの名無しさん
08/09/20 22:08:50
MSは結構力入れて開発してるみたいだし
C#並にはメジャーになるかもよ
119:デフォルトの名無しさん
08/09/20 22:10:24
ソースplz
いつの間にDigitalMarsとM$が手を組んだんだ
120:デフォルトの名無しさん
08/09/20 22:17:03
昨日路地裏でキスしているところを見たよ！
121:デフォルトの名無しさん
08/09/20 22:20:40
M$とTRONの坂村は手を組んだんだがな
122:デフォルトの名無しさん
08/09/20 22:21:57
>>120
けしからん。スグにGoogleに削除要請だ！
123:デフォルトの名無しさん
08/09/20 22:58:34
>>117
そうなのかな？
C++が肥大化しすぎているし、ネイティブ言語でまともなものが欲しいと言う需要もあるのでは？
今のところオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
124:訂正
08/09/20 22:59:13
>>123
今のところネイティブのオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
125:デフォルトの名無しさん
08/09/20 23:04:10
ま、マイナーが好きな奴には性癖なんだから何も言わんよ
でもC++がこれだけ流通している理由も考えてみてくれ
たまにでいいから
126:デフォルトの名無しさん
08/09/20 23:55:58
>>123
マカー乙
127:デフォルトの名無しさん
08/09/21 00:06:26
まぁ糞言語である事は揺ぎ無いよね
すでに投資しすぎたとか諸々の事情で選択肢からはずっと外れないんだけどさ
128:デフォルトの名無しさん
08/09/21 00:10:43
糞言語ではないだろう
テンプレートなんか後発言語は皆ジェネリックで真似してるし
129:デフォルトの名無しさん
08/09/21 00:24:24
どう糞なのかを説明して欲しい
130:デフォルトの名無しさん
08/09/21 00:24:44
>>128
部分的に良いところもある壮大な実験言語だったかもね
ただし、どう考えても言語としては糞だと思う
131:デフォルトの名無しさん
08/09/21 00:59:49
その糞を説明しないと
132:デフォルトの名無しさん
08/09/21 01:01:23
説明できないんだろ
とにかく 糞 と言いたいだけの厨だよ
133:デフォルトの名無しさん
08/09/21 01:07:02
>>132
・肥大化した仕様
・C言語との互換性がなくなってしまった
・静的なオブジェクト指向
・マルチパラダイムを言い訳にしているが、いくらでも醜いコードをかけてしまう
134:デフォルトの名無しさん
08/09/21 01:12:09
欠点ばっかり挙げてもな
利点も挙げてみろ
なぜ世の中のプログラムの多くがC++で書かれているのか
その理由がわからないのか
135:デフォルトの名無しさん
08/09/21 01:16:54
C++を糞だと言うひとは
あるコンポーネントを実装する言語を選ぶ際に様々な言語を多角的に評価した結果
CとC++が残ったというシチュエーションならどっちを選ぶの？
136:デフォルトの名無しさん
08/09/21 01:19:05
>>134
>133を裏返したら利点になる
137:デフォルトの名無しさん
08/09/21 01:20:52
という事は>>133は単にC++をけなしたいだけの香具師か
138:デフォルトの名無しさん
08/09/21 01:34:36
>>135
そこでObjective-Cですよ
139:デフォルトの名無しさん
08/09/21 01:39:53
VC以外日陰だろ
140:デフォルトの名無しさん
08/09/21 01:55:47
Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
C++とは守備範囲が違うと思う
っていうかあんなとってつけたような違和感バリバリの言語を薦めておいて
C++を糞だと言ってんのか
141:デフォルトの名無しさん
08/09/21 01:56:14
組み込み系ではCが主流だしｗ
142:デフォルトの名無しさん
08/09/21 02:12:51
>>141
コンパイラが少ないからじゃない？
143:デフォルトの名無しさん
08/09/21 02:56:05
過剰なC++擁護派はやっぱ馬鹿だなｗ
C++以外の選択肢が無い状況なんていくらでもあるが、糞言語と言う事実にはなんら影響しない。
Windowsみたいなもんだと言えば理解できるか？
144:デフォルトの名無しさん
08/09/21 03:41:16
無い頭使って必死に習得した学習コストを考えると盲目にマンセーするしかないんだろ
145:デフォルトの名無しさん
08/09/21 08:28:02
C++/CLIを介さずにC++のネイティブコードを透過的に
C#から使うことができれば、まだ使い道はあると思うけど
146:デフォルトの名無しさん
08/09/21 08:56:47
C++ではソースコードが肥大化しすぎる
言語仕様が弱すぎて、動的エラーを起こす一目でバグと分かるコードでもコンパイラが余裕で通す
C++でGUI作ってるのとか見るとC#やjavaを使った方が100倍速く短く作れる事実を知らんのだろうなあと思う
147:デフォルトの名無しさん
08/09/21 09:35:20
それで10倍実行速度が遅いと。
148:デフォルトの名無しさん
08/09/21 09:39:14
C/C++の弱点って、作られたバイナリの対象となる実行環境が限られるって事だけじゃん
それ以外の弱点っていうのは、ちょっと思いつかないなぁ
149:デフォルトの名無しさん
08/09/21 10:13:34
C#とかJavaでロジックを組んでるのとか見るとHaskellやprologを使った方が100倍短かく早く作れる事実を知らんのだろうなあと思う
150:デフォルトの名無しさん
08/09/21 10:23:12
でもHaskellやPrologで作ったOSは知らないなあ
151:デフォルトの名無しさん
08/09/21 10:32:27
Cのプログラマーが溢れて給料低下だから、
わざとごちゃごちゃしたC++作ったってネタは面白かったｗ
まぁ、俺はカプセル化だけでもC++の意味はあると思うが。
そもそもプログラムなんて使えるライブラリがあるかどうかで90%は決まる。
152:デフォルトの名無しさん
08/09/21 11:13:29
>>140
>Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
メッセージ送信だけインタプリタになる。
ただし、ランタイムによってメソッドのアドレスがキャッシュされるのでしばらく動かすと高速になる。
>C++とは守備範囲が違うと思う
組込みとかには向いていないかもね
でもiPhoneだと問題なく動いているし、組込みも高度化するとObjective-Cが使えるってことかと
153:デフォルトの名無しさん
08/09/21 11:22:20
C++でも仮想関数使えばObjective-Cと同じになるのではないかと
154:デフォルトの名無しさん
08/09/21 12:56:21
>>147
100nsが1msになったところでGUIアプリにとっては大部分がどうでもいいんです
何言ってるか分かりますか？
ホットスポットだけDLLで外出しすれば100倍早く作れて体感できない程度しか遅くならないんです
何言ってるか分かりますか？
155:デフォルトの名無しさん
08/09/21 13:29:27
>>153
配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの
156:デフォルトの名無しさん
08/09/21 13:31:40
>>154
それが問題なんだよ。
プログラムは ８：２ の法則があるのを知ってるだろ。
要するにプログラムの実行時間の大半は２割のコードが
費やしているという事だが、その部分の速度が１／１０に
なったらもっさりするだろ。
157:デフォルトの名無しさん
08/09/21 13:33:09
言葉だけ書いてもアレなんで実アプリで説明してみると、
例えばLimeWireってあるだろ。あれはJavaアプリだが、
実に動作がもっさりしている。
WinnyやShareと比べものにならない位もっさりしている。
158:デフォルトの名無しさん
08/09/21 13:34:56
>>156
何言ってるのか全く分からなかったんですね
残念です
159:デフォルトの名無しさん
08/09/21 13:37:14
あ、言っておくと>>146とは別人で、Javaは論外です
160:デフォルトの名無しさん
08/09/21 13:40:31
>>158
だからプロファイルを取ってタイムクリティカルな部分だけでも
C/C++で書けって言ってるんだよ。察しが悪いな。
161:デフォルトの名無しさん
08/09/21 13:49:12
…それって結局、
> ホットスポットだけDLLで外出しすれば
と同じことだよね。
162:デフォルトの名無しさん
08/09/21 13:50:41
まあそうだな
163:デフォルトの名無しさん
08/09/21 13:54:06
要するにJavaは動作が遅いって認めてるわけだ
開発は早いけど
WindowsだけならC#使っちゃうな
Linux/UNIXならJava
164:デフォルトの名無しさん
08/09/21 15:15:34
自分はC++が割りと好きだけど
あのコンパイルの遅さは糞だと感じる
これで開発効率が落ちてる
実行時の効率とのトレードオフなんだけど、でもなぁ
165:デフォルトの名無しさん
08/09/21 15:56:22
precompiled header使える処理系使えばええやん
166:デフォルトの名無しさん
08/09/21 16:04:52
パースに時間が掛かってるというよりも
テンプレートによるコンパイル時演算で時間が掛かるのでPCHじゃ解決しない
Boost.Function とか時間掛かるじゃない
Boost.Iterator とかも
167:デフォルトの名無しさん
08/09/21 16:59:40
もうすべてHaskellで書いて未来の処理系のおまじないにすべてを託したい。
168:デフォルトの名無しさん
08/09/21 17:48:40
C++使いこなせない奴ってかわいそうってとこまで読んだ
169:デフォルトの名無しさん
08/09/21 17:54:23
>>155
>配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの
それってユーザー側の影響はないのではないかと？
170:デフォルトの名無しさん
08/09/21 18:10:41
>>169
実行時の効率が結構違う
171:デフォルトの名無しさん
08/09/21 21:08:41
現実の世界ではCの移植性が最高、次にだいぶ落ちるけどC++、Javaはもっとも移植性が低い
172:デフォルトの名無しさん
08/09/21 21:31:48
JAVAってマルチプラットフォームじゃなかったの？
173:デフォルトの名無しさん
08/09/21 21:43:40
Javaも動かないものは動かないしな。
原因がプログラムが悪いにしろなんにしろ、ランエニホエアとかを
売りにしてたから、がっかり度が大きい
174:デフォルトの名無しさん
08/09/21 21:53:22
>>173
いやいや、Java VMが移植されてない環境では動かないという意味だと思う
175:デフォルトの名無しさん
08/09/21 22:59:16
それと現実的な実行スピードとサイズもCが一番優れてるよな
176:デフォルトの名無しさん
08/09/21 23:04:31
>>175
結局のところCを完全に越えた言語がないってことだろ
だから、C++,JAVA,C#,Objective-CなどのようなC言語の派生でうろうろしている
DはCの派生言語の整理かつ集大成にしようとしているようだが、
移行するほどの利点がない
177:デフォルトの名無しさん
08/09/21 23:58:24
>>173
結局UNIXとWindowsじゃ要求されるものが違いすぎて
そもそも要求の次元からして殆どの分野で同じものじゃ済まされないんだよな
JAVAあほす
178:デフォルトの名無しさん
08/09/22 00:00:24
Cの移植性ってWIN32APIとかはどげんすると？
179:デフォルトの名無しさん
08/09/22 02:55:49
Objective-CなんてC++と同等に並べんなよ。原住民の言語じゃねーか。
C#もエスペラント語みたいなもんだろ。綺麗だけど流行っちゃいねえ。
180:デフォルトの名無しさん
08/09/22 04:53:47
お前の中では8年前で情報が止まってるんだなｗ
181:デフォルトの名無しさん
08/09/22 06:52:46
お前は8年間妄想してたんだな。Objective-Cでパンは食べれたかい？
182:デフォルトの名無しさん
08/09/22 07:22:33
いやあのC#の話なんですが
183:デフォルトの名無しさん
08/09/22 15:10:11
Objective-Cは神
184:デフォルトの名無しさん
08/09/22 21:07:27
一方、ベルギーの音楽ソフトメーカーは日本人を雇った
URLﾘﾝｸ(www.flstudio.com)
185:デフォルトの名無しさん
08/09/23 14:08:51
Objective-Cは神
つまり糞の役にも立たない
186:デフォルトの名無しさん
08/09/23 18:57:40
例えば C++ のどの機能を削れるの？
187:デフォルトの名無しさん
08/09/23 19:30:02
マクロを削ろう。
ストローのおじさんもマクロを削りたいみたいだし。
188:デフォルトの名無しさん
08/09/23 21:41:24
全部の機能を削ればいいと思うよ
そうすれば、移植性が最高、実行速度もトップレベル、バイナリサイズも小さい、しかも習得が容易な言語になる
189:デフォルトの名無しさん
08/09/23 22:01:52
Cコンパイラの移植性とネイティブの実行効率が欲しいだけなら
Cソースにコンパイルすればいいんですよ
昔のC++、eiffelやsatherのようにね
190:デフォルトの名無しさん
08/09/23 22:13:02
昔のC++からCへのトランスレータには例外とかRTTIないでしょ
そのへんちゃんとしてるのある？
191:デフォルトの名無しさん
08/09/23 22:40:00
>>190
>>188
192:デフォルトの名無しさん
08/09/23 22:51:53
>>188
ばーか
193:デフォルトの名無しさん
08/09/23 22:58:18
>>190
eiffelもsatherも例外ぐらい当たり前のようにあるはずだよ
194:デフォルトの名無しさん
08/09/23 23:05:07
さらに C 言語から switch 文、for 文のように必要ない機能を削れば移植性が高くて
学習しやすい言語になるよ。
195:デフォルトの名無しさん
08/09/23 23:10:01
>>190
例外もRTTIも自前で実装できない人の発言。
例外なんてジャンプテーブルをスタック状に積み重ねるだけだし、RTTIなんてvtableのアドレスをそのまま使えばいいだけ。
196:デフォルトの名無しさん
08/09/23 23:12:58
>>194
C言語からswitchとforを削って移植性が高くなるのは、
その仕様の処理系がC言語の処理系より多くの環境にある場合だけだね
197:デフォルトの名無しさん
08/09/23 23:30:53
>>196
C言語のサブセットだからすでにC言語の処理系と同じ数の処理系があると考えていい。
198:デフォルトの名無しさん
08/09/23 23:32:18
同じ数の処理系なら移植性は同じっていってるんじゃん
199:デフォルトの名無しさん
08/09/23 23:46:40
サブセットの方が処理系が多いし、単純な仕様のほうが移植性が高いんじゃないの?
200:デフォルトの名無しさん
08/09/23 23:51:04
>>194
つまんね
201:デフォルトの名無しさん
08/09/23 23:54:05
現実にそんな処理系があるなら移植性は高いけど
でもC言語からswitchとforを削った処理系がある？無いよね？
だからそのサブセットは普通のCと比較して実際の移植性は同じだってこと
いま世の中に存在しない夢のコンパイラは比較対象にならない
202:デフォルトの名無しさん
08/09/24 00:01:14
>195
cfrontと禿はそれが現実的なコストで出来ないって判断したよ
つか、自前で実装って、毎回ターゲットの環境用に書くんだから移植性は最低だよね
203:デフォルトの名無しさん
08/09/24 00:02:27
>>194
ifやwhileなどで置き換えができるからいらないっていう主張なら、関数定義と？と末尾再帰だけでＯＫになってしまうぞ
204:デフォルトの名無しさん
08/09/24 00:09:22
>>194
使いにくくなっちゃうけどね
205:195
08/09/24 04:17:19
>>202
もっとわかりやすく。D&Eかなんかのページ数でもいい。
または、移植性最悪だからといってポーティングを諦めた処理系があるなら教えてくれ。
206:デフォルトの名無しさん
08/09/24 04:51:33
正直、例外は好きじゃない。
207:デフォルトの名無しさん
08/09/24 08:42:09
Maybeを使うんですか
208:デフォルトの名無しさん
08/09/24 09:01:13
>205
ここまでの流れをまとめると
>188 C言語最高
>189 ならC++からCへのトランスレータを使えばいいんじゃね？
>190 でも例外とかRTTIとかモダンな仕様を満たすトランスレータは無いよね？
>195 例外とRTTIくらい自前で実装しろ、雑魚
>202 禿もトランスレータでは現実的に無理って判断したよ？
209:デフォルトの名無しさん
08/09/24 10:15:23
>>195
移植性の話をしてる時に自前で実装すればいいって発言はありえない
210:デフォルトの名無しさん
08/09/24 11:41:49
>>205
スタック操作がからんだら移植性が失われるのは当たり前。阿呆か。
211:デフォルトの名無しさん
08/09/24 20:23:42
C++は、C言語がそれほど変わらず存在し続ける為の生け贄。UNIXが存在する限りこの連鎖は断ち切れん。
未来永劫C++はC言語の為に拡張され続ける運命にある、．．．．．．．．．．．．．．．．．．．．．．．．．．たぶん、
212:デフォルトの名無しさん
08/09/24 22:36:57
C++信者って195みたいなのばっかりなの？
213:デフォルトの名無しさん
08/09/24 22:44:13
C++信者なんていませんよ。
ファンタジーじゃあるまいし。
214:デフォルトの名無しさん
08/09/24 23:08:17
195はファンタジーかよ
215:デフォルトの名無しさん
08/09/24 23:10:55
C++がファンタジーになる時代はいつですか？
216:デフォルトの名無しさん
08/09/24 23:24:31
C++標準化委員会が「新しい機能はなるべく付け加えるな」と
言い続けてこれだからなあ
PGの欲望っていうのはとどまる所を知らない
217:デフォルトの名無しさん
08/09/25 01:13:17
C++なんてコンピュータを制御するための設定ファイルですよ。
218:デフォルトの名無しさん
08/09/25 02:32:04
C++ってそんなにダメか?
スピードとそれなりの汎用性を必要とする信号処理フィルタなんて書こうと思ったら
「C++ と 部分的にアセンブラ化の組み合わせ」が、今の最適解じゃない？
実験程度ならmatlabやjavaでもいいけど、スピード命ならC/C++に適わない
まあC++でなくても、Cで済むんだけど、規模が大きいときや、
フィルタを組み合わせたいとき、C++の方が記述が楽になる
219:デフォルトの名無しさん
08/09/25 04:10:09
++とか一般人に分からない演算子使うのやめて
C 2.0に名前変えるべき
220:デフォルトの名無しさん
08/09/25 06:21:41
むしろすべてC++でいいと思う。最近似たような言語が増えて効率悪すぎ。
221:デフォルトの名無しさん
08/09/25 08:06:11
配列とポインタは明確に区別するべきであった。
何故一つ余計に&付けるのをケチったんだ。
222:デフォルトの名無しさん
08/09/25 09:03:26
>>218
C++がどうしようもなくダメってわけじゃなくて
CとC++を明確に区別して比較したらC言語の方がより良いってことでしょ
223:デフォルトの名無しさん
08/09/25 10:03:46
>>221
配列とポインタを同列に扱えるのがC/C++の強み。
嫌なら使うな。
224:デフォルトの名無しさん
08/09/25 10:25:46
>>222
>C言語の方がより良い
誰にとって、どういう点で「良い」つってんだお前は。
225:デフォルトの名無しさん
08/09/25 10:44:56
188からの流れ読んだら？
移植性とか実行時の効率とか学習コストの点で「良い」んだろ
まあ個人的には速度に関しては有意な差は無いと判断するけどな
226:デフォルトの名無しさん
08/09/25 11:12:26
初期コストが低くてもその後ずっと開発コストが高かったら意味ないだろ。
開発コストが低くてもエンドユーザで実行コストが高かったら意味ないだろ。
C++ が最適
227:デフォルトの名無しさん
08/09/25 11:19:17
１～２行目と３行目に関連が無い
これがファンタジーってやつかｗ
228:デフォルトの名無しさん
08/09/25 11:50:19
>>225
>188からの流れ
そっからかよｗ
強引な言い訳だな。
229:デフォルトの名無しさん
08/09/25 11:57:55
ごめんな
言い訳じゃないんだけど>>208にまとめがあったからつい…
230:デフォルトの名無しさん
08/09/25 12:25:28
ばかばっか
231:デフォルトの名無しさん
08/09/25 12:43:12
>>227
いちいち説明を書かないと関連性が分からない
めんどくさいやつだな
232:デフォルトの名無しさん
08/09/25 18:18:26
いや、関連性は無いぞ。
C++が優れていると主張したいならもっと客観的・論理的な視点を持ってくれ。
226の場合はまず、開発コストという、あいまい且つ広範囲な言葉を使うのをやめて、
もっと定量化可能な別のものさしを定義する必要がある。
次にそれを測定し比較、さらに開発コストとそれ以外のメリットデメリットを比較検討、
その結果C++が最適だと主張するなら構わない。
それを行わず「C++最適」の一点張りでは信者は盲目だと思われても仕方が無いな。
233:デフォルトの名無しさん
08/09/25 18:19:38
長い。
3文字でまとめてくれ。
234:デフォルトの名無しさん
08/09/25 18:23:19
無関連
235:デフォルトの名無しさん
08/09/25 18:23:22
信
者
乙
236:デフォルトの名無しさん
08/09/25 18:44:40
な
お
ガ
…どうでもいいですが、C++ を More C として使う発想のない人がいますね。
237:デフォルトの名無しさん
08/09/25 18:52:53
そんな使い方つまらないから
238:デフォルトの名無しさん
08/09/25 18:57:16
BetterじゃなくてMoreなのかよｗｗｗｗ
さすがC++信者、その発想はなかったわｗｗｗｗ
239:デフォルトの名無しさん
08/09/25 20:18:14
俺は自分でプログラム書くときは C++
しかし、外部の業者に仕様書出して作ってもらうときは原則C
C++でかかれたひどいプログラムは見るに耐えない
240:デフォルトの名無しさん
08/09/25 22:14:12
型チェックに厳しいところだけでも C++ の方が良いと思うが、もしかして C99 で同レベルになってたりする？
241:デフォルトの名無しさん
08/09/25 22:47:28
CINTで開発したら、コンパイル頻度へってええぞー。
242:デフォルトの名無しさん
08/09/26 00:51:49
少なくともUNIX界では一部のtkが使ってる程度のニッチ言語
243:デフォルトの名無しさん
08/09/26 01:00:47
UNIXだとやはりCなのかね
244:デフォルトの名無しさん
08/09/26 02:32:28
GNUとかも大体Cだと思う。
プロジェクト管理ツールのsubversionはCでした。
FireFox3は大体C++でした。
245:デフォルトの名無しさん
08/09/26 07:57:31
>>242 Be…
246:デフォルトの名無しさん
08/09/26 09:54:54
>>240
C99はその辺の仕様は変わってない。
どっちかってーと、便利な方向に拡張されてる印象。
(複合リテラルとか可変引数マクロとか)
247:デフォルトの名無しさん
08/09/26 10:34:37
いま全部読みなおしたけど意外と良スレ
ただもうちょっとまともなC++擁護派の意見が欲しい
248:デフォルトの名無しさん
08/09/26 11:05:10
Mozillaのドキュメント読むとアレはもはやC++とは呼びたくない代物だ
まあ確かにC++の可搬性は低いと認めざるを得ないな
C99は独自拡張の現状追認(inlineとか)と可搬性向上(int32_tとか)
それとブロック途中で変数宣言が出来るようになった(C++から逆輸入)
あとC99とC++とは互換性がない
（まあ常識的な範囲では大丈夫だし、すぐに仕様を取り込むだろうけど）
249:デフォルトの名無しさん
08/09/26 12:16:44
結構Ｃも変化してきてたんだな。
250:デフォルトの名無しさん
08/09/26 13:05:10
C でプログラム書いている人って忍耐強いね。
C++ を覚えてから C でプログラムを書くなんて考えられなくなった。
Ruby を覚えて凄く便利だと思ったけど C++ とは役割が違うので C++
は捨てられません。
251:デフォルトの名無しさん
08/09/26 13:23:03
C++とBeOSといえばfragile base class problemだな
URLﾘﾝｸ(www.st.rim.or.jp)
など
252:デフォルトの名無しさん
08/09/26 15:19:17
OS の API を COM 風のインタフェースにすればよかったのに。
253:デフォルトの名無しさん
08/09/27 22:39:54
C++はほかのプロセスにクラスオブジェクトを送ろうとするだけで困難に直面するからなぁ。
254:デフォルトの名無しさん
08/09/27 22:52:27
それはアラインメントの問題じゃなくて？？
だとするとCで構造体送っても同じだと思うけど。
255:デフォルトの名無しさん
08/09/27 23:01:28
vtable付き構造体を別プロセスに送るのは、そもそも無茶ではなかろうか
256:デフォルトの名無しさん
08/09/27 23:14:43
一般的な OS だと vtable 付きに関わらず別プロセスに送れないんじゃない？
257:デフォルトの名無しさん
08/09/28 02:42:11
>>253はマヌケな指摘！
もちろん、COMやマルチスレッドを使うときC++が多少不便なのは分かるけど
それは言語の文法的な問題というよりは、言語がサポートするレンジの問題
258:デフォルトの名無しさん
08/09/28 08:42:31
ガキの時に遊び場だった小山がたくさんあるとこで
台風が過ぎた後、小山が崩れて穴が開いてたんだよ。
石が崩れててその中に懐中電灯もって仲間と入ってった。
そして通路みたいなとこ奥の方へいったら
人形みたいのが並べてあって今度は横のほうに部屋というか
空間があった。
壁に懐中電灯で照らすとなんか落書きというか
絵が描いてあったぜ。
北斗七星はガキの俺でもわかったが
あとは空を舞う女の絵
テーブルみたいなのがその部屋にあって
天井のほうにも絵があったから
その石テーブルに3人で乗っかったら
そのテーブルの台が割れちまった。
痛いと思ったらなんか石と鉄の棒みたいなので
足挟まってた。石をどけると
何か大きな箱の中に入ったみたいで中には
キラキラ光る数珠の玉みたいのとか、鉄の棒、汚れた布切れ
と小さい円盤みたいなものが何枚かあったよ。
俺は面白えと思ってみんなに内諸にしようと約束
して外にでることにした。
俺たちが外に出ようとして元の出口の方にいったら
ゴゴゴゴーとか地鳴りが聞こえて水が突然津波みたいに
俺たちを流した。
その後俺たちは田んぼまで流れてその場所が
どこかわからなくなっちまった。
後で大きくなった時にそこの場所が改めて確認した。
崩れたまま今は草ボーボーになって残ってる。
259:デフォルトの名無しさん
08/09/28 20:18:20
MPI使った分散計算とかに使うととたんに困る。
ポリモフィックなことしてたりすると、型情報をつけておくって、
受けた方は型情報に従ってseitch caseなどで羅列した生成ルーチンを選択して・・・てなことになる。
新しい派生型を加える度にcaseを追加しないといけない。
自動的に派生クラスのコンストラクタを実行とかできないからね。
これはなにもプロセス間通信じゃなくても、クラスオブジェクトのデータをいったんファイルにセーブして再度読み込むとかでも同じ問題が起こる。
260:デフォルトの名無しさん
08/09/28 21:45:15
だからCで同じことやろうとしても同じ問題が起こるっつーの。
オブジェクトをそのままファイルに保存とかアホかと。
あと型情報でswitchとかやるのは単なる設計ミスか、あるいはテンプレートで回避できる。
自分の不勉強を棚に上げて、口数少なく記述できないことを言語のせいにすんな。
261:デフォルトの名無しさん
08/09/28 22:17:27
switch caseを無くせるのがC++の面白いところなんだけどね
262:デフォルトの名無しさん
08/09/28 22:32:19
どんな言語でもそりゃswitchの羅列になる。
よその言語だとそうならないようにシリアライズって機構があるだろ。
C++だってBoostとかが作ってはいる。望みどおりのものかどうかは別として。
263:デフォルトの名無しさん
08/09/28 23:14:40
仮想関数使ってできるだけswitchとかif elseをなくすのが
C++の方向じゃないのか
禿もそう言ってたろ
264:デフォルトの名無しさん
08/09/29 00:04:27
でも最終的には、マシン語でifになるからＥじゃんＥじゃんＥＥjump
265:デフォルトの名無しさん
08/09/29 00:19:54
x86で大抵のコンパイラは call [eax+table] みたいなコードになるぞ
266:デフォルトの名無しさん
08/09/29 13:01:01
仮想関数によるswitch排除は美しいと思うけど
現実的には、あとからの機能追加とかで
ちょっとした分岐が入る場合にｇｄｇｄになりがち
267:デフォルトの名無しさん
08/09/29 20:23:11
仮想関数をしっかり使うには、結構設計に悩むが、うまくはまるとかなりいいぞ
268:デフォルトの名無しさん
08/09/29 21:27:47
オブジェクト指向やデザインパターンのおかげで変更に強く大きなアプリケーションも
作りやすくなったんだよ。GoF のデザインパターンはほとんど仮想関数使ってるよ。
269:デフォルトの名無しさん
08/09/29 21:34:01
仮想関数である必要はないよ
テンプレートメソッドやステートやストラテジーパターンなんてジェネリックスでもできる
他は忘れちゃった
270:デフォルトの名無しさん
08/09/29 21:39:05
都銀レベルの本当に巨大なシステムは皆COBOLだけどな
271:デフォルトの名無しさん
08/09/29 22:12:43
でも、COBOL開発には夢がない。楽しくもない。
272:デフォルトの名無しさん
08/09/29 22:13:51
そう言えば禿はC++の設計時に「楽しくプログラミングできる事を目指す」
ような事を言っていたな
273:デフォルトの名無しさん
08/09/29 22:15:06
その割りに出来上がったのがこれかよ
274:デフォルトの名無しさん
08/09/29 22:35:51
プログラマーから拡張につぐ拡張の要求が押し寄せて
C++標準化委員会が断り続けたが押し切られたものもあって
カオスになっている
275:デフォルトの名無しさん
08/09/29 22:44:49
それもまた一興
276:デフォルトの名無しさん
08/09/29 22:48:08
一つの言語で何でもやろうとするからこうなる
MultixやPL/Iと同じだな
277:デフォルトの名無しさん
08/09/29 22:56:06
まーMFCみたいに我が道路線で行けばそれなりに安定してる言語だけどね
278:デフォルトの名無しさん
08/09/29 23:02:55
今日、インストーラのカスタム動作というのをC#で実装してて
初めてドットネットのライブラリを使った
何だあれは！
ほとんど同じ機能を持つ違う名前のクラスが山ほどあるじゃないか
InstallerCollection って何？ただの配列じゃない
InstallContext って何？辞書を一つ持ってるだけじゃない。つまりただの辞書じゃない
あんなのを使う機会が増えていくのは嫌だな
スレと関係なくなっちゃってスマンな
279:デフォルトの名無しさん
08/09/29 23:32:41
>>274
それってどの機能のこと？
280:デフォルトの名無しさん
08/09/29 23:48:18
演算子のオーバーロード
281:デフォルトの名無しさん
08/09/30 00:16:28
>>277
STLより古いしね
282:デフォルトの名無しさん
08/09/30 01:31:13
>>281
演算子のオーバーロードって本当は入れたくなかったんだ。
初めて知った。
283:デフォルトの名無しさん
08/09/30 03:41:08
>>282
あんな糞気持ち悪いもんマトモな神経持ってたら拒否る
284:デフォルトの名無しさん
08/09/30 03:44:02
タイプ量が劇的に減っていいじゃん
285:デフォルトの名無しさん
08/09/30 03:57:12
お前のタイプ量が減った分周りの人間が苦労してるだけなんだけど
まぁ、お前はいいんだよね、お前はさ
286:デフォルトの名無しさん
08/09/30 03:59:16
D&E読んでみたけど、演算子オーバーロードについては
Dr.Bjarne自身は入れたくなかったわけではないらしいよ。
実装の難しさ（勿論コンパイラの。）やユーザにとっての難解さがあるんじゃないかと
ためらってたが検証したらそうでもなかったので取り入れたと言ってる。
「どんな言語を使ってもわかりにくいコードを書く人はいる。
誤用を恐れるよりは、便利さに目を向けた方がいい」とのこと。
実際、行列とかのクラスで mat1.Multiply(mat2.Multiply(mat3))とかイヤすぎる・・・
287:デフォルトの名無しさん
08/09/30 04:00:48
>>285
それはお前の職場環境が悪いだけ。
バカがバカなコード書くのを言語のせいにするなと。
288:デフォルトの名無しさん
08/09/30 05:13:46
_,,....,,_ ＿人人人人人人人人人人人人人人人人人＿
-''":::::::::::::｀''＞便利さに目を向けた結果が今のC++だよ！！ ＜
ヽ:::::::::::::::::::::￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^^Ｙ^ＹＹ^Ｙ^Ｙ^Ｙ^Ｙ^￣
|::::::;ノ´￣＼:::::::::::＼_,. -‐ｧ ＿_ _____ ＿_____
|::::ﾉ ヽ､ヽr-r'"´ （.__ ,´ _,, '-´￣￣｀-ゝ 、_ イ、
_,.!イ_ _,.ﾍｰｧ'二ﾊ二ヽ､へ,_7 'r ´ ヽ、ﾝ、
::::::rｰ''7ｺ-‐'"´ ; ', ｀ヽ/｀7 ,'＝=─- -─=＝', i
r-'ｧ'"´/ /! ﾊ ハ ! iヾ_ﾉ i ｲ iゝ、ｲ人レ／_ルヽｲ i |
!イ´ ,' | /__,.!/ V ､!__ﾊ ,' ,ゝ ﾚﾘｲi (ﾋ_] ﾋ_ﾝ ).| .|、i .||
`! !/ﾚi' (ﾋ_] ﾋ_ﾝ ﾚ'i ﾉ !Y!"" ,＿__, "" 「 !ﾉ i |
,' ﾉ !'" ,＿__, "' i .ﾚ' L.',. ヽ _ﾝ L」 ﾉ| .|
（ ,ﾊ ヽ _ﾝ 人! | ||ヽ、 ,ｲ| ||ｲ| /
,.ﾍ,）､ ）＞,､ _____, ,.イ ハ レ ル｀ ー--─ ´ルﾚ ﾚ´
289:デフォルトの名無しさん
08/09/30 05:20:30
演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
290:デフォルトの名無しさん
08/09/30 05:37:01
なんでそんな入社一年目でも普通に使ってる初歩的機能に熱く議論してんだ？
新入社員がlambdaとmplでばかり書いてしまって困ってますとかなら議論できそうだが。
291:デフォルトの名無しさん
08/09/30 05:41:07
なんでC++擁護派っぽいカキコってこんなヌケてるの？
アンチの工作なの？
292:デフォルトの名無しさん
08/09/30 09:22:59
C++擁護派って新人もしくは学生でWindows好きそうなイメージがある
293:デフォルトの名無しさん
08/09/30 10:54:01
>>289
×演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
○C++ってバカが俺ってSUGEEEEEEするための言語だろ
294:デフォルトの名無しさん
08/09/30 11:00:24
G++ごときで挫折したマヌケですね
295:デフォルトの名無しさん
08/09/30 12:25:54
演算子オーバーロードは単なる表記の便利さの問題じゃなくて
ダックタイピングの言語では必然と言っていいと思うがな
ダックタイピングでは、アヒルのように鳴くものはアヒルである
だから、整数のように足せるものは+で足せなければならない
実際RubyやPythonでもそれは採用されているし
基本的な道具になっている
C++もテンプレートの世界は一種の静的ダックタイピングだから
演算子オーバーロードは本質的で、それなしでは
組み込み配列やポインタ、関数を
全く同じように扱えるSTLのようなライブラリは作れないし
生まれなかったよ
296:デフォルトの名無しさん
08/09/30 12:57:24
文字列の連結が＋なのはとても整数のようでは
297:デフォルトの名無しさん
08/09/30 13:16:32
文字列の + による結合は自然じゃないか？
演算子オーバーロードのない Java ですら文字列は特別に + を使えるようにしている。
298:デフォルトの名無しさん
08/09/30 13:16:44
operatorが難しいとか感じる奴は死んでいいでしょ
299:デフォルトの名無しさん
08/09/30 13:53:01
>>298
>operatorが難しいとか感じる奴
誰もそんな話してないんだけど
唐突にどうした？
300:デフォルトの名無しさん
08/09/30 13:59:14
>>289あたりのことを指してるんだろうが
演算子オーバーロード否定論者ってJava厨あたりじゃないの
今時C#やPythonやRubyにもあるような機能なんだけど
となりのブドウはすっぱいという奴だろう
301:デフォルトの名無しさん
08/09/30 14:33:03
+は普通可換だけど、文字列の連結は可換じゃないよね。
302:デフォルトの名無しさん
08/09/30 14:43:12
文字列に+はある意味趣味の問題だろうな
BigNumや複素数、クォータニオン、ベクトル、行列のようなものに
演算子オーバーロードが使えるかどうかはかなり大きな問題だが
303:デフォルトの名無しさん
08/09/30 15:56:59
演算子オーバーロードは複素数計算では必須。だから、C++とC#しかない。
304:デフォルトの名無しさん
08/09/30 17:11:28
Fortranにもある
305:デフォルトの名無しさん
08/09/30 18:20:14
DにもDelphiにもある。
306:デフォルトの名無しさん
08/09/30 21:29:08
参照とポインタ、両方ともC++に実装せずに片方だけ実装すれば、よかったかも、
アクセス修飾子は削れない。
例外処理も削れない。
STLは微妙、自分で作った方が使いやすい（気分がする）
あんま削るとこ無いね。
307:デフォルトの名無しさん
08/09/30 21:48:07
STLを自作してたら、他人のライブラリと組み合わせるとき悲惨だぜ
自分の作った車輪と他人が作った車輪が乱立しているなんて耐えられない
308:デフォルトの名無しさん
08/09/30 21:54:36
>>306
参照とポインタはclassとstructぐらい違うぞ
309:デフォルトの名無しさん
08/09/30 21:54:47
>>306
ターゲット環境が貧弱で、constやカスタムアロケータや配置newを使いまくる人？
そういう人は例外も使わなそうな印象があるが
310:デフォルトの名無しさん
08/09/30 21:55:26
>>308
> classとstructぐらい
それって大した違いじゃないなｗ
311:デフォルトの名無しさん
08/09/30 21:59:00
>>306
>STLは微妙、自分で作った方が使いやすい（気分がする）
これは狂気の沙汰と言わざるを得ない
312:デフォルトの名無しさん
08/09/30 22:00:21
参照に関してはコンパイラ側で
ポインタを用いた内部実装しろと強制されているわけではないが
実質ほとんどのコンパイラは同じにしているだろう
せいぜい関数のインライン展開の場合に変わるぐらいか？
313:デフォルトの名無しさん
08/09/30 22:06:37
>>306
アンチC++工作員乙ｗ
314:デフォルトの名無しさん
08/09/30 22:17:04
stlは結局必要なものがない
あと基本設計がクソ過ぎる
315:デフォルトの名無しさん
08/09/30 22:31:02
とうぞ糞でないものを教えてください
316:デフォルトの名無しさん
08/09/30 22:32:42
とうぞ糞？
317:デフォルトの名無しさん
08/10/01 01:30:27
>>314 「ただ１つのベースクラスから継承して作っていないとか、どんだけクソ設計なんですか＾＾」
とかだったら笑う。
318:デフォルトの名無しさん
08/10/01 01:38:06
>>317
そんな発想できるお前に笑った
319:デフォルトの名無しさん
08/10/01 01:45:42
かゆいとこに手が届かない感じだよ。CStringからstringとかにわざわざダウングレード
するのもどうかと思う。
320:デフォルトの名無しさん
08/10/01 01:51:00
CStringのどのあたりが優れてる？
321:デフォルトの名無しさん
08/10/01 03:55:39
STLといえば、まずは vector, list, mapじゃないの？
string系はおまけ的なものだから論点が違うよ
322:デフォルトの名無しさん
08/10/01 04:03:48
そもそも環境依存のアプリ屋は、C++を積極的に使う必要はないだろ
C#やobject Cと、最新ライブラリをを使う方が効率がいいじゃないか
それに対し、C/C++系は組み込みや科学計算も含む広いレンジを考えてるから
たとえば stringに文字コード変換など気軽に組み込むわけにはいかない
ここには、言語の乱立を嫌がる人もいるが違うと思うな モノには適材適所がある
323:デフォルトの名無しさん
08/10/01 05:25:46
vectorはメモリの連続性が信用できないから素直に配列の方がいい
listもリンクリスト程度なら自分で作った方が安心できる
mapは便利だけどクソ遅い
STLは富豪プログラミングできるときにだけ使えて
mapとsetだけが多少とも役に立つ
324:デフォルトの名無しさん
08/10/01 05:41:09
メモリが連続している必要があるの？
まあ、連続していないとアクセスは遅くなるけどさ。
気にするほどのものかな
325:デフォルトの名無しさん
08/10/01 06:03:04
連続してないならないで別にいい（それがdequeだしな）
信用できないというのが大問題
326:デフォルトの名無しさん
08/10/01 07:57:47
vectorで確保するメモリは連続だったでしょ
stringと勘違いしてない?
327:デフォルトの名無しさん
08/10/01 08:06:31
URLﾘﾝｸ(www.cranehouse.jp)
こんなの発見。
昔のコンパイラだと連続していなくとも標準を名乗れたらしい。
328:デフォルトの名無しさん
08/10/01 09:24:58
std::vector 連続 で検索すれば答えは出てくる
当初の規格書に明言されてなかったのは問題だったけど
329:デフォルトの名無しさん
08/10/01 10:05:05
言語が効率第一なわりに何でもコピーベースだよな
CVOつっても限界あるし
参照ベース + GCな言語より非効率な面もかなり多いんじゃないか
std::stringは中途半端な存在だと思う
mutableで、しかしバッファの直書き換えはできなくて、
vector<char>に比べて文字列処理において著しく便利というほどでもなく
STL algorithmとの直交性にも欠ける
STLは、C++標準ライブラリの中では一番マシじゃないのか
iostreamだのlocaleだのはどうしようもない
330:329
08/10/01 10:31:04
なんだCVOってｗ
RVOだ、すまん
331:デフォルトの名無しさん
08/10/01 10:37:52
カスタム・ヴィークル・オペレーション
332:デフォルトの名無しさん
08/10/01 10:48:31
>>322
広いレンジって言っても文字が文字コード想定してないってだめでしょ。
JavaもC#もStringとかStreamはちゃんと変換できるようになってるからみんな
おとなしく使ってるでしょ。
333:デフォルトの名無しさん
08/10/01 11:39:18
文字コード変換ってでっかいテーブルが必要だったりするから
組み込みでは難しかったりするんだろう
ライブラリに任せるというのは比較的真っ当なやり方だと思うがね
そもそもC/C++標準ではファイルシステムの存在すら仮定してないし
そういったシステムに依存するような仕様を緩くして
実装可能な範囲を広げようというスタンスなんだろう
334:デフォルトの名無しさん
08/10/01 11:47:29
標準にlocaleがあるしcodecvtファセットがエンコード変換することになってるよ
まあ糞だけど
335:デフォルトの名無しさん
08/10/01 17:39:52
間違った所を緩めてどうでもいい所を締めるから
COAP（笑）だのvector<bool>（爆）だのみたいな悲劇が生まれるんだよ
336:デフォルトの名無しさん
08/10/01 17:46:37
どう考えてもMFCやVCLが実用的
337:デフォルトの名無しさん
08/10/01 17:50:15
>> 336
組み込みでMFCやVCLは動きません 役割が違うのに批判されても困るわ
338:デフォルトの名無しさん
08/10/01 17:50:47
何度ループしても糞であるという結論にしか至らないC++(笑)
339:デフォルトの名無しさん
08/10/01 17:57:34
アホですね（笑）
340:デフォルトの名無しさん
08/10/01 17:58:35
組み込みでSTLなんてそれこそ使えるか
341:デフォルトの名無しさん
08/10/01 17:59:14
言語の標準ライブラリが特殊環境を想定する必要はない
342:デフォルトの名無しさん
08/10/01 18:00:08
いまどきの組み込みはJavaや.NETが普通に動く世界なんだろ
343:デフォルトの名無しさん
08/10/01 18:01:08
そんなのはハイエンドか産業用だけです
344:デフォルトの名無しさん
08/10/01 18:08:44
Lispで動く炊飯器を見たい
345:デフォルトの名無しさん
08/10/01 18:12:53
STLは、単品で使うには粗末だし。
メーカーのライブラリの基盤に採用するには癖が強すぎる。
何より標準ライブラリを名乗っている割に後発なのが痛い。
346:デフォルトの名無しさん
08/10/01 18:14:44
もはや組み込み専用マイナー言語に落ち果てているのに
仕様的には肥大化しきってる
ぶっちゃけCでいいじゃん
人生をかけてC++を学んだ様な奴は認められないんだろうけど(笑)
347:デフォルトの名無しさん
08/10/01 18:17:22
>>346
主な需要は組み込み、ゲーム、パッケージソフト
てなとこか
でも組み込みはどっちかっつうとCのがまだメインなんじゃないか？
他ではほとんど死んでるな
パッケージも、本当はC++である必要が無い気がするな
.NETやJavaまでいかんでも、リッチなOSを前提にできるんなら
GCぐらいはあってもいいし、ギチギチのzero overhead ruleなんて必要ない
348:デフォルトの名無しさん
08/10/01 18:30:51
結論としては、CとC++の中間くらいが一番良さそうだな。
つまり、基本Cみたいな使い方でゴテゴテしたC++の機能は使わなかった俺が正解か。
349:デフォルトの名無しさん
08/10/01 18:35:08
C++の素晴らしいところは本物のデストラクタを持ってることだ
リソースの完全な管理という点では今でも右に出る言語はないと思っている
350:デフォルトの名無しさん
08/10/01 18:38:23
>>349
そっすねｗ
自己管理がんばってくださいｗｗ
351:デフォルトの名無しさん
08/10/01 18:42:36
うんｗ
実際自己管理を頑張らなきゃならない場合ってのはあって
そういう時だけはC++は本当に役に立つし、なくてはならないんだよ
そういう時だけはな
352:デフォルトの名無しさん
08/10/01 18:50:23
Pythonみたいに参照カウントとマーク＆スイープ併用してる言語もあるよ
C++でshared_ptr使って参照カウントは出来るが、フツーのGCより効率悪いよね
便利機能一切使わない覚悟でないとC++のコードは速くならないっつか
確実にCより遅くなる
スレッドのことは勿論なにも考えてないからマルチコア時代では先が見えてるしな
353:デフォルトの名無しさん
08/10/01 18:51:00
デストラクタならJAVAのほうがマシな実装だと思うぞ
354:デフォルトの名無しさん
08/10/01 18:54:28
>>353
廃棄のタイミングを厳密に制御したいんでしょ
Pythonはブロック抜けで参照カウント0になれば廃棄されるし
（当たり前だがデストラクタは定義できるし実行される）
巡回参照でも大丈夫だよ
355:デフォルトの名無しさん
08/10/01 18:56:04
>>348
D言語ですね、
でも、現在迷走中。
356:デフォルトの名無しさん
08/10/01 18:57:16
Dは最初の狙いは悪くなかったと思うけど
開発者の独りよがりな趣味で終わりそうだね
357:デフォルトの名無しさん
08/10/01 19:01:03
>>353
Javaのはデストラクタじゃなくてファイナライザ
ファイナライザは全然役に立たない
358:デフォルトの名無しさん
08/10/01 19:07:32
C++/CLI最強説
359:デフォルトの名無しさん
08/10/01 19:24:17
>>358
割と本気でそう思ってるんだが誰も同意してくれない
360:デフォルトの名無しさん
08/10/01 19:39:17
>>358
C#の方が好きだ。
361:デフォルトの名無しさん
08/10/01 19:45:55
C#もデストラクタないんだよな…
362:デフォルトの名無しさん
08/10/01 19:47:53
IDisposable
363:デフォルトの名無しさん
08/10/01 19:50:47
それデストラクタじゃなくてdelete
364:デフォルトの名無しさん
08/10/01 19:52:01
using(Hoge hoge = new Hoge())
{
//なになに
}
365:デフォルトの名無しさん
08/10/01 19:53:40
確かにマルチスレッドとかマルチプロセスに特化した言語は欲しいな。
366:デフォルトの名無しさん
08/10/01 19:54:54
うお、そんな書き方出来るのか初めて知った
C#いいな！
367:デフォルトの名無しさん
08/10/01 19:58:04
でもC#にはローカル変数とかのfinal宣言子がない…
あればいいのに あれば…
368:デフォルトの名無しさん
08/10/01 19:59:38
>>364
同じキーワードをあっちこっちの用途で流用するところはC++譲りみたいだな
369:デフォルトの名無しさん
08/10/01 20:00:52
>>364
それ使いたいオブジェクトの数が増えると構文が悲惨よw
370:デフォルトの名無しさん
08/10/01 20:01:01
もしかしてJavaもできるの？
C++はdeleteし忘れるからGC最高とか言ってる奴らが
結局finally節にdispose()とかclose()とかunlock()とかチマチマ書いてるのが
とっても滑稽だと思って以来いい印象ないんだけど
出来るなら認識改めないと
371:デフォルトの名無しさん
08/10/01 20:05:30
スマポでええヤン
372:デフォルトの名無しさん
08/10/01 20:08:51
コンテナに入らないふざけた奴か
373:デフォルトの名無しさん
08/10/01 20:10:56
スマポが悪いんじゃないんです
auto_ptrがアホの子なだけなんです
COAPとか使いたがる奴らが悪いんです
許してあげて下さい
374:デフォルトの名無しさん
08/10/01 20:17:30
まさに 「痒い所に手が届かない」
375:デフォルトの名無しさん
08/10/01 20:18:10
tr1まで標準にリファレンスカウントなスマポ入れなかったってのは、
そもそも標準にスレッドセーフという概念が無いからか？
どっちみちSTLがスレッド？何それ？状態だから関係ねーけどな
ヨボヨボすぎて、もうモダンなOSの主要言語の座はとっくに引退していい仕様だろ
お爺ちゃんをいつまでも無理して使いすぎなんだよ
376:デフォルトの名無しさん
08/10/01 20:21:27
0xでようやくスレッドの概念が入って
スレッドローカル変数とかが定義できるようになるらしいけどな
マトモになるのはいつになるやら
377:デフォルトの名無しさん
08/10/01 20:26:31
iostreamとか、仕様練る時に変だろこれと誰一人思わなかったのかな。
378:デフォルトの名無しさん
08/10/01 20:26:44
え？マトモにする予定なんてあるの？
379:デフォルトの名無しさん
08/10/01 20:31:52
>>377
sprintfひとつですむことを
だらだら << 繰り返して書くのが楽しい。┐(´∇｀)┌
380:デフォルトの名無しさん
08/10/01 20:33:38
>>370
GCが便利なのはいっちいっちコピー先バッファとか
頭の悪いもの引数に用意しなくて済むからだよ。
381:デフォルトの名無しさん
08/10/01 20:40:32
shared_ptrとか使って、ただのポインタアクセスをいちいち高価なものに
置き換えたりする必要も無いしな
382:デフォルトの名無しさん
08/10/01 20:44:10
GCはshared_ptrなんぞよりよっぽど高価ですが
383:デフォルトの名無しさん
08/10/01 20:49:05
>>377
iostreamの凄いところは、初期の仕様を捨ててわざわざ新しくしたのにそれでも糞であるというとこだね。
iostream絡みの昔のコードはどのみち通らないんだから、それなら思い切って捨ててしまえば良かったのに。
384:デフォルトの名無しさん
08/10/01 20:54:12
マネージだからメモリリークしないと思っている人。
確かに、プログラムが終了するときにはリークしないでしょう。
けれど例えば、ある操作を繰り返すたびにメモリが解放されずに残ってしまう
ということは有り得ます。Javaでも同様です。
たとえば、ArrayListにStringを追加し続けているようなものです。
385:デフォルトの名無しさん
08/10/01 21:01:53
GCは普通に使う分には便利だが
ゲームのオブジェクト管理とかやろうと思うとウザくなる
386:デフォルトの名無しさん
08/10/01 21:02:09
>>384
unmanagedでもプログラム終了したらリークはしないでしょう。
何か特別なことしない限り。
387:デフォルトの名無しさん
08/10/01 21:07:02
>>358
C++/CLIもコレクションに入れるとデストラクタが無力化する
388:デフォルトの名無しさん
08/10/01 21:08:36
まあ、そんなに参照されるのがいやならソフトリファレンスでも使えや
389:デフォルトの名無しさん
08/10/01 21:50:39
>>387
msclr::auto_handleは？
390:デフォルトの名無しさん
08/10/01 21:53:43
そもそもauto_handle自身のデストラクタが働かないから㍉
391:デフォルトの名無しさん
08/10/01 22:35:54
やっぱりmallocが最高だな。
392:デフォルトの名無しさん
08/10/01 23:54:57
aro
393:デフォルトの名無しさん
08/10/02 00:39:29
C++0x みたいな継ぎ接ぎはもういいから、新しいプログラミング言語の作成しろ。
394:デフォルトの名無しさん
08/10/02 01:43:49
STL を組み込みで使えないという意見があったが、
処理系のデフォルトの operator new とか std::allocator
とかを使わないというだけで、<algorithm> も使うし
自前アロケータでコンテナも使うよ。
395:デフォルトの名無しさん
08/10/02 09:16:30
C言語を完全に駆逐するためには
ｽﾚﾘﾝｸ(tech板)
396:デフォルトの名無しさん
08/10/02 10:58:03
unixの設計のためにCを作ったように、
新しいOSのために、全く新しい言語が生み出されるであろう。
397:デフォルトの名無しさん
08/10/02 11:29:35
んなこたぁー、ない。
398:デフォルトの名無しさん
08/10/02 18:09:47
Be…
399:デフォルトの名無しさん
08/10/02 18:30:28
並列プログラミングが重要視される時代なのでやっぱり新しい言語が必要。
400:デフォルトの名無しさん
08/10/02 18:33:23
ConcurrentC
401:デフォルトの名無しさん
08/10/02 18:41:36
Nextだろ
402:デフォルトの名無しさん
08/10/02 23:07:59
素朴な疑問なんだが
C++がCより開発効率が良いって主張あるよな？
ひとによっては暗黙の了解になってるぽいんだが
それって誰がいつどうやって比べたの？
ソースはあるの？
403:デフォルトの名無しさん
08/10/02 23:32:14
鉛筆を一本ずつ数えるのとダースで数える程度の違い
ヘッダファイルの仕様化度が高いともいえるけど
所詮はマクロアセンブラを構文化しただけの言語
いくらでも非効率にも効率的にもできる
404:デフォルトの名無しさん
08/10/02 23:34:08
↑に付いては知らんけど、COBOLの方がJavaよりも開発効率がいいなんて言い出すCOBOL脳には成るなよ。
405:404
08/10/02 23:36:10
>>402
406:デフォルトの名無しさん
08/10/02 23:40:42
>>402
高級言語の中で比較するんならどっちみちC++の生産性は低い
それ以上に再利用のしにくさが致命的
ABIが糞でコンパイル時計算への依存度が高いからな
407:デフォルトの名無しさん
08/10/02 23:41:06
一応COBOLは開発効率を重視した言語だ
ただし、プログラマー向けじゃないけどね
408:デフォルトの名無しさん
08/10/02 23:46:15
ソースは？脳内？
409:デフォルトの名無しさん
08/10/03 00:01:41
個人的には、高級言語の皮を被った低級言語って感じでいいんだけどな。
基本Ｃでいいんだけど、少しだけ楽したいみたいな。
410:デフォルトの名無しさん
08/10/03 00:12:25
ソースもなにも両方でプログラム作れば感覚でわかるだろ。
411:デフォルトの名無しさん
08/10/03 01:42:23
CがC++よりいいって・・どうやってWindow表示すんの？MFCとかATLとか使わんの？クラスも使わんの？
CreateWindow(........)とかばっかしてがんばるの？なんなの？ばかなの？
412:デフォルトの名無しさん
08/10/03 01:50:29
いい加減、開発の目的や背景を理解できるようになってくれ
413:デフォルトの名無しさん
08/10/03 02:06:05
>>411
酷い馬鹿を見た
>>1から1000回読み直せ
414:デフォルトの名無しさん
08/10/03 02:17:32
適切な設計をすればCよりは保守性も効率も上がると思うんだけど。
なんか極端なアンチが沸いてるが（俺ももちろんC++が楽だとは言わんが）、
必死に叩いてる奴って、クラスやテンプレートの使い方のセンスが無いor
理解できてない馬鹿ばっかりじゃないの？
単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
機能の使い方が悪い以外に考えられん。
415:デフォルトの名無しさん
08/10/03 02:28:59
> 単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
> 機能の使い方が悪い以外に考えられん。
「キッチンシンク」という言葉は知ってるか？
なぜMultixが失敗してUnixが生まれたかを知っていれば
「大きいことはいいことだ」という単純素朴な発想は出てこないはずだ
C++みたいな半端な言語で何でもやろうとするのではなく、もっと高級で
ずっと生産性の高い言語とCを組み合わせるという選択も普通にあるんだが、
それも見えていないようだね
416:デフォルトの名無しさん
08/10/03 02:39:29
まぁ、実際を考えると、マルチプラットフォームで使えるちゃんとしたコンパイラがあるかどうかってのもあるなｗ
417:デフォルトの名無しさん
08/10/03 02:49:20
>>414
なるほど、C++の標準の策定者は「理解できてない馬鹿」で「機能の使い方が悪い」
からiostreamとか作っちゃうわけだな
418:デフォルトの名無しさん
08/10/03 02:59:05
実用性は無くても、オブジェクト指向言語の可能性を立派にアピールしたよ
419:デフォルトの名無しさん
08/10/03 03:01:58
C++をOOの代表であるかのごとくに言ったらOO信者の猛反発喰らうぞｗ
420:デフォルトの名無しさん
08/10/03 03:14:54
C++はOOのOOらしさを極限までそぎ落とし、効率に振り向けた言語だからな
421:デフォルトの名無しさん
08/10/03 03:55:47
オブジェクト指向言語の可能性←大間違い
オブジェクト指向の可能性←ギリギリおｋ
422:デフォルトの名無しさん
08/10/03 04:01:16
SimulaとSmalltalkに失礼だな
423:デフォルトの名無しさん
08/10/03 04:07:21
実用性皆無の実験言語が一般にアピールはないだろ
影響領域が違いすぎで失礼とかないわ
424:414
08/10/03 04:21:43
＞もっと高級でずっと生産性の高い言語とCを組み合わせるという
＞選択も普通にあるんだが、それも見えていないようだね
なんか偉そうに言ってるけど、C++は実行効率最優先の言語なんですが。
生産効率が良くて、速度やメモリ効率を犠牲にしてでも高級な機能を持つ言語が欲しいのなら
最初からC/C++は選択肢に入らないだろ。見えてないのはお前の方だ。
425:デフォルトの名無しさん
08/10/03 04:34:31
その低劣な生産効率を補えるほどに速くすらないのが問題なんだろ
vtbl持たなきゃならないのはオブジェクト指向言語の本質的な非効率性だから
C++でも他でも一緒だしな
426:デフォルトの名無しさん
08/10/03 04:39:32
他の言語は知らないが、GNUとMSのコンパイラは
純仮想関数を使わない限りVTBLは使われないよ
427:デフォルトの名無しさん
08/10/03 04:54:09
そりゃ使わない物は使わないし、まともなコンパイラなら省くに決まってる
でも継承を有効利用するにはvtblはないわけにはいかない
継承と多態性はオブジェクト指向の根幹だ
428:デフォルトの名無しさん
08/10/03 05:03:58
だから、継承とプリモにはVTBLは必要ないぞ
COMとか使ったこと無いか?アレだ
429:デフォルトの名無しさん
08/10/03 05:07:31
インスタンスが自分が何者かを知らずにどうやってポリモやるんだ？
430:デフォルトの名無しさん
08/10/03 05:11:22
オブジェクト指向がどうこうってより、同じような設計をしようと思ったら
Cでやっても同じようなコード（vtblと同じ、関数アドレスを介した呼び出し）になるわけで。
原理的に無理なものをどうこう言っても仕方無いだろ。
ただ、D&Eに「多重継承をサポートする為に、vtblを”単一継承なら使える最も速い方法”で
実装しなかった（加算１つと代入１つ増えた）。ここだけは唯一ゼロオーバヘッドルールに
違反することになった」って書いてあったけども。
それすら気になるほど速度を重視するのならそもそも仮想関数を使わないor
vtblが必要になるような仮想関数の書き方をしなければいい。
そんな滅茶苦茶ギリギリで設計の自由度も無い状況で仮想関数使うような
多態性を用いる設計を使おうとする方がおかしい。
>>428
あまり詳しくないがCOMはvtbl使ってるはずだよ。
431:デフォルトの名無しさん
08/10/03 05:14:35
>>430
そうそう
だから効率が重要な場合はあらゆるOO言語は使えないってこと
それはC++だろうとなんだろうと一緒な訳で
432:デフォルトの名無しさん
08/10/03 05:26:13
勘違いさせたが、手続き型言語においてVTBLが必要となる一つの条件としてCOMを挙げた
手っ取り早くは適当にリバースエンジニアしてもらえればわかるのではないだろうか
あくまで、コンパイラの実装の話だけどね
433:デフォルトの名無しさん
08/10/03 05:42:21
>>412,413
結局何も説明できずに馬鹿って言うだけなの？。なんなの？バカなんですか？
C++のなにが難しかったんですか？何がわからないのかわからないのですか？
434:デフォルトの名無しさん
08/10/03 05:47:37
>>433
真性の馬鹿に何かを教える様な物好きに、そんな簡単にめぐり合えるとでも思ってるの？
435:デフォルトの名無しさん
08/10/03 05:54:05
何か眠気でちゃんと読んでないのかな
C++は手続き型言語
要するに仮想関数程度じゃインスタンスを特定できるから
オーバーヘッドはCの関数を呼び出すのと引数分しか差がない
純仮想関数のようにインスタンスを特定できない場合に限り
VTBLを通して関数が呼び出される
これはルックアップテーブルだからそれなりに高コスト
こんなもんで理解してくれ
436:デフォルトの名無しさん
08/10/03 05:54:57
あ、ただのバカアンチなんですね。了解しました。テンプレートは難しいですもんね。
VisualBasicという言語をお薦めしておきます。
437:デフォルトの名無しさん
08/10/03 05:59:09
＞要するに仮想関数程度じゃインスタンスを特定できるから
何だものすごいバカか
438:デフォルトの名無しさん
08/10/03 06:01:23
>>435
仮想関数はvtbl使わなくて純粋仮想関数は使うって言ってるの？
本気で言ってるの？
よく眠って頭冷やせよ
439:デフォルトの名無しさん
08/10/03 06:32:06
仮想関数批判はC++というかJavaとかC#とかもろもろ全部だしあんまし
意味ないような。
しかもそんな奴はむしろC++でメタテンプレートでも極めればいいし
C++向きだと思うが。
440:デフォルトの名無しさん
08/10/03 06:47:47
OOの本質的なオーバーヘッドとC++固有の問題を
ごっちゃにして叩く輩が多いからな
441:デフォルトの名無しさん
08/10/03 09:30:53
MFCはSTLが固まる前に発売されたから勝手に作った独自仕様などと言れれるゆわれはない。
442:デフォルトの名無しさん
08/10/03 10:06:47
>>436
TMPなんぞを嬉しがってるのはC++信者だけだろ
パターンマッチングやダックタイピング／structural subtyping、
ファーストクラスの関数、lambda式、クロージャ
今時の高級言語がもっとマシな形で備えている機構が無いために
C++信者はあの醜く汚いバッドノウハウを金科玉条のごとくに
有難がってるんだろ
しかもC++からソースレベルでしか再利用できないというデッドな技術だから
C++信者はあくまでもC++にしがみつくしかない
タコツボだな
443:デフォルトの名無しさん
08/10/03 10:26:23
>>442
>>436のアイデンティティが崩壊しちゃうからそれ以上言っちゃダメ
444:デフォルトの名無しさん
08/10/03 10:35:40
>>442
お前みたいな流行りの言語機能好きは流行りの言語をそのときどきに勉強して
使ってればいいんじゃねーの？
Haskellでlambda使いまくりのWindowsプログラミングでもやってりゃいーじゃん。
なぜそれが現実的じゃないのか、なぜ誰もやってないのか、なぜ言語機能だけで
ソフトは作れないのかを知るといいと思うよ。
445:デフォルトの名無しさん
08/10/03 10:38:54
>>444
Javaですらlambda式やクロージャを取り入れようとしてるのに今更何言ってんだ？
446:デフォルトの名無しさん
08/10/03 10:45:19
>>444
自分に都合の良い解釈ばっかしてると馬鹿に見えるよ
447:デフォルトの名無しさん
08/10/03 10:45:27
Cより古いLispをガン無視して単なる「流行」とか言ってるのが笑えるな
448:デフォルトの名無しさん
08/10/03 10:46:53
連投乙
449:デフォルトの名無しさん
08/10/03 11:01:49
>>445-447
そんなにむきになるなよ。お前は悪くない。時代が悪いんだ。
450:デフォルトの名無しさん
08/10/03 11:04:37
>>449
いや、単純にお前の頭が悪いんだよ。
451:デフォルトの名無しさん
08/10/03 11:11:46
お前らどんだけ馬鹿馬鹿言い合えば気が済むんだよｗ
452:デフォルトの名無しさん
08/10/03 11:29:44
>>435
本当にC++を知っているとは思えない発言だな
仮想関数があるなら必ずvtblは作られる
静的に型が確定している場合（参照を通さない場合）には、
vtblルックアップは要らない
ポインタや参照の場合は静的に型が確定しないので、仮想関数の場合は
常にvtblルックアップが発生する
こんなのは常識だろ
つーか、C++でどうやってポリモーフィズムを実現してると思ってるんだ
453:デフォルトの名無しさん
08/10/03 11:32:37
自分の知っている処理系は全てvtblだが
C++にはvtblを用いて実装しなければいけないという決まりはなかったはずだが
454:デフォルトの名無しさん
08/10/03 11:34:23
>>453
ああ、確かにちと実装より過ぎる説明だったか
いずれにせよ>>435が言っていることは明らかな誤り
455:デフォルトの名無しさん
08/10/03 11:40:10
つっても店頭に並んでるアプリの9割はいまだにC++製だからなあ。
やっぱOSネイティブの言語は機能どうこう以前の強力さがあるんだよな。
まあC++にもlambda/bindが来年付くしまだまだ現役続投かねぇ。
456:デフォルトの名無しさん
08/10/03 11:43:13
>>455
Windowsと同じだな
シェアそれ自体が最大の強み
言語が糞でもな……
457:デフォルトの名無しさん
08/10/03 12:02:07
マイナーなもの使って人柱やるのもいやだしな
458:デフォルトの名無しさん
08/10/03 12:03:28
>>417
C++ﾏﾝｾｰな俺も、それには同意。
459:デフォルトの名無しさん
08/10/03 12:22:20
>>402以降、誰もC++の開発効率に触れないのな
460:デフォルトの名無しさん
08/10/03 12:27:21
え、>>402以降リロードせず>>459を書き込んじゃったの？
461:デフォルトの名無しさん
08/10/03 12:30:00
Office や Web ブラウザのような巨大で複雑なアプリをサクサク動かすには
今のところ C++ しか選択肢はないんじゃないか？ D はよく分からないが。
462:デフォルトの名無しさん
08/10/03 12:36:04
>>460
具体的にどのレス？
ちなみに402は↓これだぞ？
>素朴な疑問なんだが
>C++がCより開発効率が良いって主張あるよな？
>ひとによっては暗黙の了解になってるぽいんだが
>それって誰がいつどうやって比べたの？
>ソースはあるの？
463:デフォルトの名無しさん
08/10/03 12:36:48
MacではC++じゃなくてObjective-Cが母語なんだろ
だから、C++でなければならないというわけでは全くないだろう
少なくともOfficeみたいなリッチなOSの上に乗っかって動くアプリなら、
ネイティブコンパイルさえ出来れば、もっと動的な言語でも十分ってことになるん
じゃないのか
464:デフォルトの名無しさん
08/10/03 12:44:53
>>462
単品のレスじゃなくて流れで分かるだろ
>>402には「C++がCより開発効率が良いがひとによっては暗黙の了解になってるぽいんだがソースは無い」でこのスレ的にはFA出てる
何かしら覆したいならお前がソース出せ
C++単品の生産効率についてなら腐るほど言い合ってるだろ
465:462
08/10/03 12:59:24
>>464
いや別に覆したいとは思ってないよ、事実関係をはっきりさせたいだけ
じゃあこのスレ的には「C++の開発効率はCより高いとは言えない」でFAだな
466:デフォルトの名無しさん
08/10/03 13:15:19
>>465
大した根拠も無くC++の方が開発効率が良いと思ってる奴は確実に居るが、本当の所は誰も知らんがFA
467:デフォルトの名無しさん
08/10/03 13:15:26
C++はCを内包するので比較する意味が無い
468:デフォルトの名無しさん
08/10/03 13:18:04
また馬鹿が湧いた
C++はCを内包するので比較する意味が無い(ｷﾘｯ
いくらかマシに見える様に訂正しときました
469:デフォルトの名無しさん
08/10/03 13:19:47
>>467
>>415
スーパーセットは時にサブセットに劣る
470:デフォルトの名無しさん
08/10/03 13:25:17
スーパーセットである事によるオーバーヘッドが有意か否かは
開発者自身や処理系の問題であって言語の問題では無い
471:デフォルトの名無しさん
08/10/03 13:26:26
カプセル化できるだけでも有難い＜C++
まあ「隠匿されたら処理の流れが解らんではないか！」とか
言い出す奴にとっては厄介なんだろうが。
472:デフォルトの名無しさん
08/10/03 13:30:42
>>470
肥大化した仕様はまさに言語の問題だろう
さらにC++の場合は禿が実用性を謳ってるんだから開発者や処理系の都合も言語とセットで考えるべき
473:デフォルトの名無しさん
08/10/03 13:34:32
C++ は基本的にサブセット(C部分)に劣らない。
C 部分の性能は普通の処理系なら落ちないから。
474:デフォルトの名無しさん
08/10/03 13:43:43
>>473
流れ嫁よ
（実行時の）性能を比較してるわけじゃないだろ
475:デフォルトの名無しさん
08/10/03 13:48:42
じゃあ、何が劣るの？
476:デフォルトの名無しさん
08/10/03 13:52:41
「C++なんて駄目。Cの方がまし」という事にしたがっている奴の脳。
477:デフォルトの名無しさん
08/10/03 14:06:15
C++ は C よりもコンパイラの選択肢が少ないところが劣っているかな。
俺はそんなことで困ったことはないけど。
478:デフォルトの名無しさん
08/10/03 15:13:33
C++が一番ひどいのは学習コストだろう？
罠とバッドノウハウが多すぎる
そしてそこまでして学習したものは、C++を使うとき以外何の役にも立たない
だからこそ「バッドノウハウ」なんだけどな
479:デフォルトの名無しさん
08/10/03 15:39:00
boostはC++を象徴してる
言語仕様の貧弱さを無理やりカバーするためにマクロとテンプレート使いまくり
お陰で糞みたいにコンパイル時間がかかるわ
解読不能なエラーメッセージを大量に出力するわ
仕方がないからソース読もうにも追う気すら萎えさせるわ
インテリセンスはクラッシュさせるわ
プログラマの時間をドブに捨てさせるにはこれ以上ないいい言語だと思う
480:デフォルトの名無しさん
08/10/03 15:41:44
標準でソケット通信ライブラリすら無いんだから規模はむしろ小さい方だろう
Cよりは当然覚える事は多いが
481:デフォルトの名無しさん
08/10/03 15:56:55
C++作った理由の陰謀論みたいな話になってきたなｗ
482:デフォルトの名無しさん
08/10/03 17:33:26
ねぇ、C++擁護派ってなんでこんな馬鹿なの？ねぇ、なんでこんな馬鹿なの？
483:デフォルトの名無しさん
08/10/03 17:45:55
オブジェクト指向だけに、先人の思想を忠実に継承してるからな。
484:デフォルトの名無しさん
08/10/03 17:48:07
反対派も大概バカだけどな
結局は適材適所
C++はアプリを作るには最低の言語
ドライバやミドルウェアを作る時にはそこそこ役に立つ言語
それでいいじゃないか
485:デフォルトの名無しさん
08/10/03 17:54:49
お前らプログラムもろくに組めない癖に文句だけは一丁前に言うなｗ
486:デフォルトの名無しさん
08/10/03 17:56:53
ツンデレなんだよ
487:デフォルトの名無しさん
08/10/03 18:03:51
継承も例外もオーバーロードもテンプレートもなくして
クラスがメンバ関数とコンストラクタとデストラクタを使えるだけのちょっと便利な構造体なだけだったらよかったのに
488:デフォルトの名無しさん
08/10/03 18:05:35
つか否定派と比べて擁護派が非論理的すぎるだろ
489:デフォルトの名無しさん
08/10/03 18:10:17
特定分野では役に立つこともあるよねってだけで擁護派扱いか
ありとあらゆる局面で絶対に役に立たないクソ言語でないと気が済まないって人たちの方が怖いです
490:デフォルトの名無しさん
08/10/03 18:13:46
ネイティブコンパイルできて、Cやasmのobjとリンクできるなら
何でもよくね？
組み込みに関しては、Javaみたいにエディション分けちゃえばいいのにと思う。
EC++とかは消えたんだろ？
491:デフォルトの名無しさん
08/10/03 18:21:50
>>484
基本的に反対派の主張は>>484に書かれてる通りなんですけど？
馬鹿で非論理的な擁護派が勝手に>>489みたいに被害妄想炸裂させて
反対派の奴らはこんな極端な事を考えているキチガイだったんだよ！！！１１って五月蝿いだけなんです。
だから擁護派はなんか馬鹿が多いって言われてるんです。
わかりますか？
492:デフォルトの名無しさん
08/10/03 18:26:11
>>441
そうだとしても、STLが策定された時点でSTLベースに作り直すのが筋だろ？
493:デフォルトの名無しさん
08/10/03 18:30:23
>>492
MFCを作り直す必要はないんじゃないか？
モダンなC++として書けばATL/WTLのようにただの別物が出来上がるだけで
それに「MFC」という名前をつける必要がない
MFCの導入時はWin16からWin32への移行促進という目的があった
（ある意味今の.NETに似てる）
今や単なるレガシー技術の互換性サポートだろ
494:デフォルトの名無しさん
08/10/03 18:34:06
>>492
どっちでもいいだろ
どうせウィンドウズが亡くなったらC++の使い道なんか殆ど無いんだしw
495:デフォルトの名無しさん
08/10/03 18:36:38
>>492
準拠するに足る魅力が無かったってだけだろ
496:デフォルトの名無しさん
08/10/03 18:47:19
MSC7.0だっけか
497:デフォルトの名無しさん
08/10/03 19:23:44
>>492
そんな筋はないと思うぞ。
過去のMFCと互換性ぶったぎることになるだろうし。
498:デフォルトの名無しさん
08/10/03 19:34:27
>>490
一応、ホスト環境とフリースタンディングって区分けが標準にある。
誰も意識していないけど……。
499:デフォルトの名無しさん
08/10/03 19:57:41
492 タコ殴りw
500:デフォルトの名無しさん
08/10/03 20:07:38
未来の言語
C{
ここC文法領域
}
C++{
ここC++文法領域
}
Perl{
ここPerl文法領域
}
もうこんなのでいいよ
501:デフォルトの名無しさん
08/10/03 20:10:31
むかしXMLでそんなことしてるのがあったな
502:デフォルトの名無しさん
08/10/03 20:32:59
>>500
URLﾘﾝｸ(search.cpan.org)
もっとだいぶ鬱陶しいけど、もう Perl にあるから全部 Perl でいいね。
503:デフォルトの名無しさん
08/10/03 21:43:06
Союз Советских Социалистических Республик
504:デフォルトの名無しさん
08/10/03 22:00:19
>>465
いろんな統計を見たことがあるはずだが、手元にある分では、行数に関するものしか見つからなかった。
Code Complete とラピッドデベロップメントに、ファンクションポイントあたりの行数が C の方が C++ に比べて 2.5 倍多いそうな。
505:デフォルトの名無しさん
08/10/03 22:29:31
>>504
ただの興味なんだが、その「いろんな統計」が是非見てみたい。
個人的には「ファンクションポイントあたりの行数」では開発効率は測れない（根拠として弱すぎる）と思うし。
506:デフォルトの名無しさん
08/10/04 01:23:33
>>492
確かに筋だな。
URLﾘﾝｸ(up2.viploader.net)
507:デフォルトの名無しさん
08/10/04 01:36:10
↑面白い事をやったつもり
508:デフォルトの名無しさん
08/10/04 02:13:47
>>494
言っておくが家庭用ゲーム機およびPCのゲームは殆どC++だぞ
一昔前はCで開発してるところも多かったが。
携帯ゲームはほとんどがJavaだが。
想像力無さ過ぎ。よくそれでプログラマやってられるな
509:デフォルトの名無しさん
08/10/04 02:15:16
訂正、携帯電話のゲームは。
510:デフォルトの名無しさん
08/10/04 08:36:46
どうして開発言語が C から C++ に移行したの？
511:デフォルトの名無しさん
08/10/04 09:01:16
>>510
ゲーム開発の規模がデカくなり、プラットフォームをまたいで開発することが
増えるに従って、毎回書きなおしするような開発は非効率すぎるということで
業界全体がそういう流れになったんだと思う。
勿論Cでもマルチプラットフォームで使いまわしの利くコードは書けるけど、
それだけのセンスがあるなら、C++でプラットフォームをまたぐクラスライブラリを書けるし、
よっぽど解りやすくて保守しやすいコードになる。
かといって富豪プログラミングが許されるわけではないし（オブジェクトが裏でやっていることの
時間的・空間的コストが想像もつかないようでは話にならない）、アセンブリ叩く場面もあるけども。
中小では未だにCのところもあるみたいだけどね。
512:デフォルトの名無しさん
08/10/04 12:41:29
>>511
なるほど。
ゲームでは C++ が C より生産性が高いということですね。
513:デフォルトの名無しさん
08/10/04 12:45:37
一般論としては、OOが非常に適している分野とそうでもない分野があると思う
関数型が向いている分野とそうでない分野があるように
GUI、シミュレーションなんかはモロにOO向きで
ゲームもそれに相当するだろう
CでOOっぽいことも出来るが、デバドラぐらいならともかく
Xのツールキットぐらいの規模になると結構苦しい印象があるな
514:デフォルトの名無しさん
08/10/04 13:56:46
>>512
待った、いちがいにそうとはいえない
業界最大手クラスのゲームデベロッパでは例外とSTLとBoostとRTTIとほぼ全ての演算子オーバーロードとほぼ全てのテンプレートが禁止だよ
その他の大手も大同小異だ
それってC++なのか？
515:デフォルトの名無しさん
08/10/04 14:10:51
>>514
例外やBoostやRTTIはわかるが（コンシューマなら特に）、テンプレート禁止ってのはわからんな。
一体どこの会社を指して業界最大手とか大同小異だとか言ってるのか知らないが
クラス使ってりゃ十分C++だと思うけど。
まさかツール作るときもそれら全部禁止なの？
数値演算まわりのクラスにも演算子オーバロード禁止？
516:デフォルトの名無しさん
08/10/04 14:12:06
C++を使わないと企画が通らないけど
C++を使うと開発が立ち行かない
517:デフォルトの名無しさん
08/10/04 14:24:56
つーかさ、同じC++でも例外の有無でまったく別の言語だよな
コードの再利用なんて不可能なんだし
518:デフォルトの名無しさん
08/10/04 14:29:55
>>515
不安定な俺クラスよりも、boostの同様なクラスを使ったほうがコードがすっきりしたりする。
.俺の10年がboostに塗りつぶされていって泣けるorz
519:デフォルトの名無しさん
08/10/04 14:36:08
本来C++の諸機能と例外は不可分なんだが
なぜか世の中には例外無しのC++という処理系や開発現場がある
ハゲが泥縄式に例外を導入した歴史的経緯なんでもうあきらめるしかないが
処理系提供側も例外使えないならC++を名乗らないで欲しい
520:デフォルトの名無しさん
08/10/04 14:47:27
別に言語の全ての特徴を実際に使うかどうかは関係ないでしょｗ
使わないコードでもバイナリレベルにどうしても影響しちゃうとかならしょうがないけどｗ
521:デフォルトの名無しさん
08/10/04 14:50:55
>>515
演算子やテンプレートは決められた人間が作ったものだけ使えっていうことじゃないかな。
例外を禁止する理由は良く分からないが処理系によっては例外を投げなくても重くなる
可能性があるからかな。
522:デフォルトの名無しさん
08/10/04 14:55:12
コンストラクタの失敗とかはは例外以外のまともに捕まえる方法がないからな言語的に
結局errnoみたいなものに頼ることになって何のためのオブジェクト指向なのかという話に
523:デフォルトの名無しさん
08/10/04 15:10:54
> 演算子やテンプレートは決められた人間が作ったものだけ使え
それって出来の悪い兵隊集めて仕事する三流請負業務系の発想だな
現在そういう系統ではC++は死滅していると認識しているが
524:デフォルトの名無しさん
08/10/04 18:49:49
>>522
class hoge { ... };
hoge a;
if(!a.ok()) goto hell;
でいいんじゃね？
525:デフォルトの名無しさん
08/10/04 18:53:59
お話になられません。
526:デフォルトの名無しさん
08/10/04 19:18:06
といいますか、コンストラクタ内で自己完結してない時点でOOとしてはお話になりませぬ。
527:デフォルトの名無しさん
08/10/04 19:26:18
ANSI C++ 1998
ANSI C++ 2003
ときて、
C++0
が採択される、まだまた拡張中。
528:デフォルトの名無しさん
08/10/04 19:40:30
>>524
a の初期化に失敗した後は a は存在しないはず。
だから a にはアクセスできない。
529:デフォルトの名無しさん
08/10/04 19:44:30
>>528
そこで言う「失敗」て例えば何なん？
530:デフォルトの名無しさん
08/10/04 19:52:05
>>528
>>524は、iostreamのように、失敗しても例外を投げないような設計にしてある
ことが前提なんでしょ
531:デフォルトの名無しさん
08/10/04 20:34:59
>>529
よくあるのがメモリ確保に失敗した時
532:デフォルトの名無しさん
08/10/04 20:36:29
>>530
ああ、確かにそういう初期化に失敗しない設計もできるね。
しばらく RAII な設計をしてきたからそういうのは思いつかなっかた。
例外のない C++ だとクラス設計もかなり変わってくるな。
533:デフォルトの名無しさん
08/10/05 00:00:41
某有名ゲームエンジンはC++でOOしまくり例外多用だけどね。
言語の文句ばっか言ってモノ作れないボンクラは原因は別のとこにあると思う。
534:デフォルトの名無しさん
08/10/05 00:07:19
C++→肥大化
Ruby→肥満化
535:デフォルトの名無しさん
08/10/05 00:12:10
Windows アプリ開発の主力言語が C から C++ になってしまったのは MS のせい？
MS に否定的な OpenOffice や Firefox まで C++ で開発しているみたいだけど。
536:デフォルトの名無しさん
08/10/05 00:27:06
パソコン屋で売ってるソフトの90%くらいがWindows用
そのほとんどがVCで残りがVBかBCCかDelphi
537:デフォルトの名無しさん
08/10/05 02:03:05
>>535
なんでもMSに結びつけるのは違うだろ。
538:デフォルトの名無しさん
08/10/05 03:37:13
てか何年前の話だww
C#に移るのかって時代に
539:デフォルトの名無しさん
08/10/05 03:47:22
ww
540:デフォルトの名無しさん
08/10/05 03:59:28
>>533
>モノ作れないボンクラは原因は別のとこにあると思う。
モノ作れないのと言語の文句を言うのは全く別の話だと思う。
541:デフォルトの名無しさん
08/10/05 04:52:27
結局擁護派って自分で書いたコードしか弄った事無いから擁護できるんだよな
発言から視野の狭さが見て取れる
542:デフォルトの名無しさん
08/10/05 05:16:10
>>541
俺にはその擁護を否定に入れ替えるとその通りに思える
それともアレか、バカが書いたC++のコードを弄ってるとC++が嫌いになるとかか？
擁護否定に関わらず、バカが書いたC++のコードがクソなのは誰もが知ってると思うが。
543:デフォルトの名無しさん
08/10/05 05:30:04
バカが書いた世界地図を思い出した
544:デフォルトの名無しさん
08/10/05 05:44:08
>>542
これはひどい
545:デフォルトの名無しさん
08/10/05 06:36:07
>>541
その文面からは視野の広さが見て取れない
546:デフォルトの名無しさん
08/10/05 10:07:57
スレタイとどんどん離れてくなｗ
547:デフォルトの名無しさん
08/10/05 10:43:15
ただのバカスレだしな
548:デフォルトの名無しさん
08/10/05 10:53:15
スレの趣旨とは合致してるからまったく無問題
すぐ顔真っ赤になるC++信者を見守るスレです
549:デフォルトの名無しさん
08/10/05 11:44:56
アンチまっさお、信者まっか
550:デフォルトの名無しさん
08/10/05 13:08:17
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
551:デフォルトの名無しさん
08/10/05 13:09:17
C++ のようにマルチパラダイム言語はプログラミングが楽だ。
複数の言語でプログラム断片を作ってつなぎ合わせる方法は結構面倒くさい。
552:デフォルトの名無しさん
08/10/05 13:24:05
C++のプログラミングが「楽」とか正気とは思えん
LLなら数行で済む仕事に一体何行かける気だ
言語は適材適所で使えよ
ネイティブなobjを吐く言語は要するに高級なアセンブラなんだからよ
553:デフォルトの名無しさん
08/10/05 13:50:23
末端作業員はPerl永遠にやってな
554:デフォルトの名無しさん
08/10/05 13:51:47
１つのプログラムは GUI からレイトレの計算までいろいろな部分が混在してる。
これらをそこそこカバーできるメジャーな言語は C++ 以外に何がある？
そのぞれの部分に得意な言語を使うこともできるがリンクが面倒くさくなる。
555:デフォルトの名無しさん
08/10/05 13:53:40
低所得スクリプターが紛れ込んで奮闘してるんだろ。
556:デフォルトの名無しさん
08/10/05 14:02:41
厨房はこれだから困る
今時ゲームだってLuaだのPythonだのスクリプトエンジンの一つや二つ
入れ込んでるだろ
gaucheの作者はスクウェアでCGのプロダクションシステムをLispで書いてる
というかLispは昔からCG分野で主流で、今はPythonが取って代わっている
Emacsは実際にはLispインタプリタで、だからこそあれだけ強力なエディタなんだ
557:デフォルトの名無しさん
08/10/05 14:08:44
馬鹿が書いたコードは言語問わず糞だが
他言語に比べてC++は馬鹿が糞コードを非常に書きやすい
しかもC++では優秀な開発者でもバッドノウハウを身に付けないと危険なコードの罠にはまる
558:デフォルトの名無しさん
08/10/05 14:35:18
C++&Python最強ということで終了
559:デフォルトの名無しさん
08/10/05 15:16:54
>>556
それはかなり金をかけて作られるゲームエンジンに統合されているからできること。
普通のアプリでそういうことをやろうとするとデバッグも含めてかなり面倒くさい。
COM や .NET で多言語のリンクをしたほうがまだまし。
C++ は C が得意な部分、OO が得意な部分、テンプレートなどを自然な形で結合できる。
これを作った禿は天才
560:デフォルトの名無しさん
08/10/05 15:28:53
C++ に慣れちゃったからそれが自然なだけでしょ。
「言語は人間を規定する」という訳だ。
561:デフォルトの名無しさん
08/10/05 15:38:13
>>559
「普通のアプリ」とやらが何をさしてるんだかわからんが
趣味で作ってるおもちゃのフリーソフトのことなら、好きにすれば？
趣味なんだしな
562:デフォルトの名無しさん
08/10/05 16:17:12
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
と、相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
563:デフォルトの名無しさん
08/10/05 16:37:54
>>552
ちゃんとした仕組みを作り上げれば、楽になるのだと思う
でも･･･ ねぇ、、 その時間と楽さのトレードオフがなってないよ
それに気づけない人がC++にのめりこんじゃうと本当に時間無駄にしてる
それが楽しいならいいけど
C++は、根底だけ用意して土台が何も無いから･･･
そういう人が土台を一生懸命作ってる感じ
あと、何年したらまともな土台になるのやら