C++ってなんであんな� ..

---

[2ch|▼Menu]

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という言語をお薦めしておきます。

---

次ページ

最新レス表示

スレッドの検索

類似スレ一覧

話題のニュース

おまかせリスト

▼オプションを表示

レスジャンプ

mixiチェック！

Twitterに投稿

オプション

しおりを挟む

スレッドに書込

スレッドの一覧

暇つぶし2ch

---

5376日前に更新/163 KB
担当:undef