1 :
デフォルトの名無しさん:
仕様が大きすぎるくせに、
実用的なライブラリが未整備。
なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。
C++ってなんであんなに肥大化しちゃったの?
名前: 仕様書無しさん
E-mail:
内容:
仕様が大きすぎるくせに、
実用的なライブラリが未整備。
なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。
C++はなんでもできます。でもなんにもできてないので
つくってね。的な。
C++0xに期待っ(決めっ!)
あぁ。なんか変なコピペが入っちゃったw
wikipediaのC++0xのページ読んで
吐き気がしてきたw
最近、実践用の言語と勉強用の言語の違いが
わかってきたな。勉強用言語って言語仕様の説明に
内部実装の説明が頻繁に出てくるんだよ。
C++というPerlといい。
必要とされるものを追加した結果だろ。
未踏叩き厨によればw
読んだことないならC++の設計と進化をぜひ。
そういう仕様になった理由がいろいろ書いてあって、同情できる。
だからと言って、C++が良くなるわけではないけれど。
Unix原典とかねw
役には立たないけど怒りを抑える効果はある
8 :
デフォルトの名無しさん:2008/08/29(金) 06:07:18
MS-DOSのTurbo C++ 3.0のころが
一番素直だった。
あるのはクラスと継承とカプセル化程度。
例外はない。STLはない。当然Boostなんてものもない。
きわめてシンプルなオブジェクト指向言語だった。
C++が無かったら他の言語のコンパイラやインタプリタの作成も不可能になる
>>4 C++は勉強用の言語じゃない。超実務用。職人用の道具みたいなもん。
Stroustrup氏がはっきりそう言い切ってる。
C++が無かったらWindowsも無くなっちゃうな。
巨大なクラスライブラリがくっついてくるJavaとかC#に比べると
むしろ機能が足りなさすぎるんだが。
この程度でどこが肥大化って感じるんだ?
そしてJavaもC#も結局C++で書かれてるんだよね。
まともな C++ の参考書の厚さは異常。
逆に言うと、薄い参考書は当てにならない。
16 :
デフォルトの名無しさん:2008/09/08(月) 06:16:18
コーヒーブレーク
http://www.youtube.com/v/8GaivisdRqo, 01:33,[KORG DS-10]はじめてのシンセサイザー第1日目「PITCH(ピッチ)」
http://www.youtube.com/v/dmmriw96UHU, 03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」
http://www.youtube.com/v/uy--pllBniQ, 03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」(修整版)
http://www.youtube.com/v/3nowLPRgoTI, 02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」
http://www.youtube.com/v/pANHFXO2Ll0, 02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」(修整版)
http://www.youtube.com/v/ldtIbmQvzyU, 03:43,[KORG DS-10]はじめてのシンセサイザー第4日目「EG(エンベロープジェネレータ)」
http://www.youtube.com/v/ofG_DTCp434, 04:27,[KORG DS-10]はじめてのシンセサイザー第5日目「EGエピソード2」
http://www.youtube.com/v/atpRE1xmdS8, 07:09,[KORG DS-10]はじめてのシンセサイザー第6日目「VCA」
http://www.youtube.com/v/Znn0_DyAmt4, 03:58,[KORG DS-10]はじめてじゃないシンセサイザー第1日目「PATCH(パッチ)」
http://www.youtube.com/v/q-Uu8_rU2XE, 04:24,[KORG DS-10]はじめてじゃないシンセサイザー第2日目「PATCH その2」
http://www.youtube.com/v/2bJYmIDWrqY, 05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ, 05:21,[KORG DS-10]はじめてのシーケンサー(修正版)
17 :
デフォルトの名無しさん:2008/09/08(月) 06:19:17
修正コーヒーブレーク
http://www.youtube.com/v/8GaivisdRqo ,01:33,[KORG DS-10]はじめてのシンセサイザー第1日目「PITCH(ピッチ)」
http://www.youtube.com/v/dmmriw96UHU ,03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」
http://www.youtube.com/v/uy--pllBniQ ,03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」(修整版)
http://www.youtube.com/v/3nowLPRgoTI ,02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」
http://www.youtube.com/v/pANHFXO2Ll0 ,02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」(修整版)
http://www.youtube.com/v/ldtIbmQvzyU ,03:43,[KORG DS-10]はじめてのシンセサイザー第4日目「EG(エンベロープジェネレータ)」
http://www.youtube.com/v/ofG_DTCp434 ,04:27,[KORG DS-10]はじめてのシンセサイザー第5日目「EGエピソード2」
http://www.youtube.com/v/atpRE1xmdS8 ,07:09,[KORG DS-10]はじめてのシンセサイザー第6日目「VCA」
http://www.youtube.com/v/Znn0_DyAmt4 ,03:58,[KORG DS-10]はじめてじゃないシンセサイザー第1日目「PATCH(パッチ)」
http://www.youtube.com/v/q-Uu8_rU2XE ,04:24,[KORG DS-10]はじめてじゃないシンセサイザー第2日目「PATCH その2」
http://www.youtube.com/v/2bJYmIDWrqY ,05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ ,05:21,[KORG DS-10]はじめてのシーケンサー(修正版)
>実用的なライブラリが未整備。
独自仕様で90%のパソコンで動くライブラリと、その後から出来た
標準規格で誰も使いたくないクソ設計のライブラリがある。
でも C++ を使うのは面白いよー。
BASIC から C 飛ばしていきなり C++ に行ったけど
こんな面白い言語は他にないよー。ひゃっはー。
boostのmplやマクロを多用して何言語がよくわからない事をするのが楽しそうですね
C++の実用ライブラリなんていくらでもあるじゃん。
たんに知らないだけだろ。
23 :
デフォルトの名無しさん:2008/09/09(火) 11:31:48
javaだのC#みたく標準ライブラリじゃなきゃわかりません><
てことだろ。
javaもGUIは標準じゃないだろ。いや、標準じゃないものを使うのが当たり前になっているのかも知らんが。
AWTって標準じゃないの?
iostreamの気持ち悪さは以上
例えば、どんなライブラリが欲しいのかしら?
メモリリークせず、バッファオーバーランせず、スレッドセーフで、ドキュメントが充実していて
3ステップ以内で大抵のやりたい事ができて、高速で、導入の手間が掛からず
移植性に優れていて、十分に枯れている
そんな実用的なライブラリが欲しいです
スレッドセーフじゃないのはもうあきらめるしか。
C#でどうですか?
しーぷらぷらしーえるあい
>>26 あれでも、昔の仕様よりゃかなりマシになってんだぞw
iostreamはC++の"入門書"で真っ先に出てくるのが
今思い返すとウザかったなぁ・・・・。
<<演算子のオーバーロードとか、「C++自体がそういう文法」だと錯覚させられた。
C#なんかは言語よりもランタイムのリフレクションやコード動的生成の機能に頼る方向だよね
びよ〜んすとらうすとらっぷ
クラスとSTLの相性の悪さが・・・
クラスの中でSTLを使うってだけならいいんだが、
設計そのものに適用しようとするともうぐちゃぐちゃ
んなことねーべ
STLの根幹であるコンセプトってのはオブジェクト指向の根底にもあるもんだし
42 :
デフォルトの名無しさん:2008/09/13(土) 17:59:59
信者がこんなんだから進歩しないのよ
で、C++は難しいからPHPでも使うかって?
>>42 違う
原因は互換性っていう過去の柵が8割以上を占めてると思う
互換性ない俺様言語作るのは簡単だからね
D言語にとって変わられればいいじゃん。
とか思ってたけどD言語迷走しすぎ。
Cと互換性のない言語はかわりにはならんし別物になっちゃうんだよなあ。
48 :
デフォルトの名無しさん:2008/09/13(土) 20:15:26
Objective-Cの方が良かったんだけどね
STLってゆうか、テンプレートなんだけど、
テンプレート化したクラスにおいて、別の種類の柔軟性を持たせたくなって仮想関数を
作りたくなるときってないですか? それって無理ですよね?
そんなこと思う事自体が何か間違ってるんでしょうか。
>>49 クラステンプレートに仮想関数を持たせることはできるよ。
メンバテンプレートで仮想関数は無理だけど。
51 :
デフォルトの名無しさん:2008/09/14(日) 10:42:46
世の中の天才PGみてるとC++なんて使わずC使ってるからなぁ
天才だからCとかアセンブラで十分なんだよ
その人達みたいにCを使いこなすよりはC++をそれなりに使えるようになる方がまだ簡単
53 :
デフォルトの名無しさん:2008/09/14(日) 11:28:46
天才は1人でシステム開発するでしょ。だからCで十分なんだよ。
少人数の開発に向いてるのはLisp
ほとんどの場合、Cでいいよね
C++とかJavaとかって、無駄にクラスを作ったり無駄にソースコードを
増やして、開発量水増しするために使うもんだと思ってる。
本気で言ってるのかマジレスなのか非常に気になるが・・・・
オブジェクト指向の言語の必要性を感じてないんか?
それからC++はマルチパラダイム言語と呼ばれるように
非常に懐の広い言語なんだが
tmpによる静的モデル検証とか使い熟せれば便利だと思う
言語内DSLなんていまじゃ別に奇なものでないしね
あと名前空間とか激しく便利だね、XXX_YYY_ZZZとか書かなくてすむし
でもSTL, boost, TMPとか使わずにC++使うぐらいならC99の方が100倍マシだ
そもそもC++が幅利かせてるのってwindowsくらいだろ。
UNIXの世界じゃたんなる一選択肢的な感じだし。
>>56 単にオブジェクト指向っぽくすることだけが目的になってない?
なんのためのオブジェクト指向か分ってる?
マルチパラダイムと称して
いきあたりばったりに機能拡張した感が否めない
61 :
デフォルトの名無しさん:2008/09/14(日) 18:49:18
>>56 C++は書く人がOOPを意識して書けばOOPになるってだけで
実際には
>>55のような工数の水増しのネタにされているんだろうなぁ
なんにでも使えるものはなんの役にも立たないってやつ?
Javaほど急速じゃないけどCOBOL化が着々と進んでる気がする。
むしろC++がノロノロと次世代の仕様を作成している間にJavaがここまで肥えるとは思わなかった
まぁあんだけ群がればピザりまくるに決まってる
66 :
デフォルトの名無しさん:2008/09/14(日) 21:47:41
塩は料理から凍結防止ガラス作りまでなんにでも使えるよ。
68 :
デフォルトの名無しさん:2008/09/14(日) 22:34:49
Objective-C > C++
まっかさんはどっかいってね
70 :
デフォルトの名無しさん:2008/09/14(日) 22:50:00
オブジェクト指向度マップ
<--- 構造化 オブジェクト指向 --->
C C++ Java C# OC Smalltalk
71 :
デフォルトの名無しさん:2008/09/14(日) 22:59:56
スモールトークに需要あるのー
72 :
デフォルトの名無しさん:2008/09/14(日) 23:39:00
えいふぇるはどの辺に位置するの?
実際に Smalltalk に需要があるかどうかは関係なく、
・実行時にメッセージスロットを検索に行く
言語の代表として、歴史的な経緯から使われているに過ぎないのだろう。
Self とか Lua とか JavaScript でも文脈としては問題ないが、先輩に応分の敬意を払わないと非難を受けることだろう。
表面の文法の問題ではないということね。
>>69 Objective-C >>>>> C++
すごいね
初心者向け度って意味ね
C++0xになったらそろそろ標準の文字列クラスぐらい出てきますよね。
完全なコンパイル言語でオブジェクト指向やろうとするとC++が限度ってこと。
OCなんてC+オブジェクト指向インタプリタだし。
>>77 相変わらずstd::basic_stringです。
>>78 それに加えて C とある程度の互換を持たせるという縛りもきつ過ぎる
そもそもSTL理念に必要最低限って書いてあったけど。
JAVAやドトネト並みの網羅されたクラスライブラリがあるだけでぜんぜん違うのに
でもでかいランタイムが必要だと選択肢から外れちゃうよ
>>83 当然そうだよ
ターゲットの環境や用途等にもよるし
そりゃそのライブラリのために30MBのDLLが必要だったら困るじゃんって話でしょ。
再配布のライセンスとか、インストールが必要なのかとか他のアプリに影響与えないか
とかも重要だし。
巨大なライブラリがあればもっと可能性が広がるのにって言ってる相手に
それは使えない可能性もあるって言ってなんか意味あるの?
boostも便利なんだけどさ、amazonにSOAPで繋げて商品情報をGUIで一覧表示したいんだけど、
とか思うとまったく機能が足りてないんだよなあ。
WTLとか、iostream使ったソケットプログラミングとか、
やろうと思えばいろいろ発展できそうなのにいまいちまとまりがない。
それが++
大きくなると、まとまりがなくなるのは
どんな言語にもある。
>>87 その大きさが可能性を狭めることもあるって言ってるんでしょ
馬鹿はお触り禁止
放置しましょう
>>91の何がおかしいかがわからないので教えてください
>>81からの流れを例えで表すと
>>81 巨大重機(ライブラリ)があればビル建てるときも楽になるのにね
>>82 でもそんな巨大だと民家建てる時に困るじゃん
>>83 そんなの当たり前じゃないの?
>>84 当たり前だよ
>>85 結局
>>82はそんな当たり前の事言いたかったの?
>>86 だから
>>82は巨大重機じゃ民家建てる時に困るって言ってるんだよ
>>87 だからそんな当たり前の事言って何の意味があるの?
>>91 だから大きいと困る可能性もあるって言ってるんでしょ
>>92 馬鹿なの?
ああなるほど
言語と一体化したようなライブラリでなければ
>>95のような話だね
昔のVBや現在のドットネットを選択肢から外す状況を想定してた
>>82はクラスライブラリが欲しいって話から
何時の間にか言語仕様上巨大なランタイムが必須ってとこまで飛躍してたのな。
そんなことしたらC++の存在意義が無くなるだけじゃんw
C/C++だってランタイムは必要だぜ。
ライブラリモジュールを、配布プログラムに必ず含めなければならないとなれば大きいのは困るけど、
基本モジュールは別途インスコしておいて、アプリはそいつ必要に応じてリンクするのがやっぱりベストな気がするな。
OS以外の基本モジュールはNGなんて環境は相当特殊だろうし。
Vista64bit使ってると.NETのありがたみが分かってくる。
一部のプログラム以外、.NETのほうが便利だし、
わざわざ32bit, 64bitとリリースを分けるまでもなく
VMが適当に最適化を行ってくれる。
C:\Program Files (x86)\フォルダに入ることもない。
結局C言語と.NETがあれば十分じゃね?
C++はもう休めばいいよ
携帯とかゲームとか組み込みとか色々あるから
ちっとも十分じゃない
嫌C++厨必死ww
現実を見ろよ
どこのコンパイラメーカもC++無しでは食っていけない
必死さで言うと・・・いやなんでもない
醜いC++がしぶとく生き残る様は丁度アーキテクチャが汚い
x86がしぶとく生き残る様子に似ているかもしれない
D&Eはただのいいわけ本
ページを捲るたびに「ハイハイワロスワロス」って感想しか出てこない
と言語の一つも設計した事のないカスがほざいております
OS選ばないのが前提。
java…
>>104 C++が醜いですか?
たとえば何が綺麗なの?
確かにx86は汚い
モトローラの68K系とかのアーキテクチャの方がすっきりして綺麗だった
でもほとんどの人が機械語やアセンブラに直接触れない今では
ソフトウェアから見たアーキテクチャの一貫性などの重要度が低くなったのでx86は生き残ったんだ
C++とは状況が違うと思うよ
共通点は、捨てるのが怖いほど既に投資してしまったこと
x86の機械語体系は確かにグチャグチャだが、ハードウェア
アーキテクチャに限定して話をすれば80386以降は比較的
まともになったと思うよ。
Alpha最高
AMD64 はすっきりしたんじゃない?
AMD(笑)
C++最大の成功と失敗はCとの互換性だなあ。
あと時代が古いせいでいろんな事情を言語に載せてしまったように思える。
だからDはもうちょっとがんばって安心して使用できるように配慮してほしい。
ああそれなら心配いらない
D言語なんて「絶対に」マイナーなままで終わるから
MSは結構力入れて開発してるみたいだし
C#並にはメジャーになるかもよ
ソースplz
いつの間にDigitalMarsとM$が手を組んだんだ
昨日路地裏でキスしているところを見たよ!
M$とTRONの坂村は手を組んだんだがな
>>120 けしからん。スグにGoogleに削除要請だ!
>>117 そうなのかな?
C++が肥大化しすぎているし、ネイティブ言語でまともなものが欲しいと言う需要もあるのでは?
今のところオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
124 :
訂正:2008/09/20(土) 22:59:13
>>123 今のところネイティブのオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
ま、マイナーが好きな奴には性癖なんだから何も言わんよ
でもC++がこれだけ流通している理由も考えてみてくれ
たまにでいいから
まぁ糞言語である事は揺ぎ無いよね
すでに投資しすぎたとか諸々の事情で選択肢からはずっと外れないんだけどさ
糞言語ではないだろう
テンプレートなんか後発言語は皆ジェネリックで真似してるし
どう糞なのかを説明して欲しい
>>128 部分的に良いところもある壮大な実験言語だったかもね
ただし、どう考えても言語としては糞だと思う
その糞を説明しないと
説明できないんだろ
とにかく 糞 と言いたいだけの厨だよ
>>132 ・肥大化した仕様
・C言語との互換性がなくなってしまった
・静的なオブジェクト指向
・マルチパラダイムを言い訳にしているが、いくらでも醜いコードをかけてしまう
欠点ばっかり挙げてもな
利点も挙げてみろ
なぜ世の中のプログラムの多くがC++で書かれているのか
その理由がわからないのか
C++を糞だと言うひとは
あるコンポーネントを実装する言語を選ぶ際に様々な言語を多角的に評価した結果
CとC++が残ったというシチュエーションならどっちを選ぶの?
という事は
>>133は単にC++をけなしたいだけの香具師か
VC以外日陰だろ
Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
C++とは守備範囲が違うと思う
っていうかあんなとってつけたような違和感バリバリの言語を薦めておいて
C++を糞だと言ってんのか
組み込み系ではCが主流だしw
過剰なC++擁護派はやっぱ馬鹿だなw
C++以外の選択肢が無い状況なんていくらでもあるが、糞言語と言う事実にはなんら影響しない。
Windowsみたいなもんだと言えば理解できるか?
無い頭使って必死に習得した学習コストを考えると盲目にマンセーするしかないんだろ
145 :
デフォルトの名無しさん:2008/09/21(日) 08:28:02
C++/CLIを介さずにC++のネイティブコードを透過的に
C#から使うことができれば、まだ使い道はあると思うけど
146 :
デフォルトの名無しさん:2008/09/21(日) 08:56:47
C++ではソースコードが肥大化しすぎる
言語仕様が弱すぎて、動的エラーを起こす一目でバグと分かるコードでもコンパイラが余裕で通す
C++でGUI作ってるのとか見るとC#やjavaを使った方が100倍速く短く作れる事実を知らんのだろうなあと思う
147 :
デフォルトの名無しさん:2008/09/21(日) 09:35:20
それで10倍実行速度が遅いと。
148 :
デフォルトの名無しさん:2008/09/21(日) 09:39:14
C/C++の弱点って、作られたバイナリの対象となる実行環境が限られるって事だけじゃん
それ以外の弱点っていうのは、ちょっと思いつかないなぁ
C#とかJavaでロジックを組んでるのとか見るとHaskellやprologを使った方が100倍短かく早く作れる事実を知らんのだろうなあと思う
でもHaskellやPrologで作ったOSは知らないなあ
Cのプログラマーが溢れて給料低下だから、
わざとごちゃごちゃしたC++作ったってネタは面白かったw
まぁ、俺はカプセル化だけでもC++の意味はあると思うが。
そもそもプログラムなんて使えるライブラリがあるかどうかで90%は決まる。
>>140 >Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
メッセージ送信だけインタプリタになる。
ただし、ランタイムによってメソッドのアドレスがキャッシュされるのでしばらく動かすと高速になる。
>C++とは守備範囲が違うと思う
組込みとかには向いていないかもね
でもiPhoneだと問題なく動いているし、組込みも高度化するとObjective-Cが使えるってことかと
C++でも仮想関数使えばObjective-Cと同じになるのではないかと
>>147 100nsが1msになったところでGUIアプリにとっては大部分がどうでもいいんです
何言ってるか分かりますか?
ホットスポットだけDLLで外出しすれば100倍早く作れて体感できない程度しか遅くならないんです
何言ってるか分かりますか?
>>153 配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの
>>154 それが問題なんだよ。
プログラムは 8:2 の法則があるのを知ってるだろ。
要するにプログラムの実行時間の大半は2割のコードが
費やしているという事だが、その部分の速度が1/10に
なったらもっさりするだろ。
言葉だけ書いてもアレなんで実アプリで説明してみると、
例えばLimeWireってあるだろ。あれはJavaアプリだが、
実に動作がもっさりしている。
WinnyやShareと比べものにならない位もっさりしている。
>>156 何言ってるのか全く分からなかったんですね
残念です
あ、言っておくと
>>146とは別人で、Javaは論外です
>>158 だからプロファイルを取ってタイムクリティカルな部分だけでも
C/C++で書けって言ってるんだよ。察しが悪いな。
…それって結局、
> ホットスポットだけDLLで外出しすれば
と同じことだよね。
まあそうだな
要するにJavaは動作が遅いって認めてるわけだ
開発は早いけど
WindowsだけならC#使っちゃうな
Linux/UNIXならJava
自分はC++が割りと好きだけど
あのコンパイルの遅さは糞だと感じる
これで開発効率が落ちてる
実行時の効率とのトレードオフなんだけど、でもなぁ
precompiled header使える処理系使えばええやん
パースに時間が掛かってるというよりも
テンプレートによるコンパイル時演算で時間が掛かるのでPCHじゃ解決しない
Boost.Function とか時間掛かるじゃない
Boost.Iterator とかも
もうすべてHaskellで書いて未来の処理系のおまじないにすべてを託したい。
C++使いこなせない奴ってかわいそうってとこまで読んだ
>>155 >配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの
それってユーザー側の影響はないのではないかと?
現実の世界ではCの移植性が最高、次にだいぶ落ちるけどC++、Javaはもっとも移植性が低い
JAVAってマルチプラットフォームじゃなかったの?
Javaも動かないものは動かないしな。
原因がプログラムが悪いにしろなんにしろ、ランエニホエアとかを
売りにしてたから、がっかり度が大きい
>>173 いやいや、Java VMが移植されてない環境では動かないという意味だと思う
それと現実的な実行スピードとサイズもCが一番優れてるよな
>>175 結局のところCを完全に越えた言語がないってことだろ
だから、C++,JAVA,C#,Objective-CなどのようなC言語の派生でうろうろしている
DはCの派生言語の整理かつ集大成にしようとしているようだが、
移行するほどの利点がない
>>173 結局UNIXとWindowsじゃ要求されるものが違いすぎて
そもそも要求の次元からして殆どの分野で同じものじゃ済まされないんだよな
JAVAあほす
Cの移植性ってWIN32APIとかはどげんすると?
Objective-CなんてC++と同等に並べんなよ。原住民の言語じゃねーか。
C#もエスペラント語みたいなもんだろ。綺麗だけど流行っちゃいねえ。
お前の中では8年前で情報が止まってるんだなw
お前は8年間妄想してたんだな。Objective-Cでパンは食べれたかい?
いやあのC#の話なんですが
Objective-Cは神
Objective-Cは神
つまり糞の役にも立たない
例えば C++ のどの機能を削れるの?
マクロを削ろう。
ストローのおじさんもマクロを削りたいみたいだし。
全部の機能を削ればいいと思うよ
そうすれば、移植性が最高、実行速度もトップレベル、バイナリサイズも小さい、しかも習得が容易な言語になる
Cコンパイラの移植性とネイティブの実行効率が欲しいだけなら
Cソースにコンパイルすればいいんですよ
昔のC++、eiffelやsatherのようにね
昔のC++からCへのトランスレータには例外とかRTTIないでしょ
そのへんちゃんとしてるのある?
>>190 eiffelもsatherも例外ぐらい当たり前のようにあるはずだよ
さらに C 言語から switch 文、for 文のように必要ない機能を削れば移植性が高くて
学習しやすい言語になるよ。
>>190 例外もRTTIも自前で実装できない人の発言。
例外なんてジャンプテーブルをスタック状に積み重ねるだけだし、RTTIなんてvtableのアドレスをそのまま使えばいいだけ。
>>194 C言語からswitchとforを削って移植性が高くなるのは、
その仕様の処理系がC言語の処理系より多くの環境にある場合だけだね
>>196 C言語のサブセットだからすでにC言語の処理系と同じ数の処理系があると考えていい。
同じ数の処理系なら移植性は同じっていってるんじゃん
サブセットの方が処理系が多いし、単純な仕様のほうが移植性が高いんじゃないの?
現実にそんな処理系があるなら移植性は高いけど
でもC言語からswitchとforを削った処理系がある?無いよね?
だからそのサブセットは普通のCと比較して実際の移植性は同じだってこと
いま世の中に存在しない夢のコンパイラは比較対象にならない
>195
cfrontと禿はそれが現実的なコストで出来ないって判断したよ
つか、自前で実装って、毎回ターゲットの環境用に書くんだから移植性は最低だよね
>>194 ifやwhileなどで置き換えができるからいらないっていう主張なら、関数定義と?と末尾再帰だけでOKになってしまうぞ
205 :
195:2008/09/24(水) 04:17:19
>>202 もっとわかりやすく。D&Eかなんかのページ数でもいい。
または、移植性最悪だからといってポーティングを諦めた処理系があるなら教えてくれ。
正直、例外は好きじゃない。
Maybeを使うんですか
>205
ここまでの流れをまとめると
>188 C言語最高
>189 ならC++からCへのトランスレータを使えばいいんじゃね?
>190 でも例外とかRTTIとかモダンな仕様を満たすトランスレータは無いよね?
>195 例外とRTTIくらい自前で実装しろ、雑魚
>202 禿もトランスレータでは現実的に無理って判断したよ?
>>195 移植性の話をしてる時に自前で実装すればいいって発言はありえない
>>205 スタック操作がからんだら移植性が失われるのは当たり前。阿呆か。
C++は、C言語がそれほど変わらず存在し続ける為の生け贄。UNIXが存在する限りこの連鎖は断ち切れん。
未来永劫C++はC言語の為に拡張され続ける運命にある、..........................たぶん、
C++信者って195みたいなのばっかりなの?
C++信者なんていませんよ。
ファンタジーじゃあるまいし。
214 :
デフォルトの名無しさん:2008/09/24(水) 23:08:17
195はファンタジーかよ
C++がファンタジーになる時代はいつですか?
C++標準化委員会が「新しい機能はなるべく付け加えるな」と
言い続けてこれだからなあ
PGの欲望っていうのはとどまる所を知らない
C++なんてコンピュータを制御するための設定ファイルですよ。
C++ってそんなにダメか?
スピードとそれなりの汎用性を必要とする信号処理フィルタなんて書こうと思ったら
「C++ と 部分的にアセンブラ化の組み合わせ」が、今の最適解じゃない?
実験程度ならmatlabやjavaでもいいけど、スピード命ならC/C++に適わない
まあC++でなくても、Cで済むんだけど、規模が大きいときや、
フィルタを組み合わせたいとき、C++の方が記述が楽になる
++とか一般人に分からない演算子使うのやめて
C 2.0に名前変えるべき
むしろすべてC++でいいと思う。最近似たような言語が増えて効率悪すぎ。
配列とポインタは明確に区別するべきであった。
何故一つ余計に&付けるのをケチったんだ。
>>218 C++がどうしようもなくダメってわけじゃなくて
CとC++を明確に区別して比較したらC言語の方がより良いってことでしょ
>>221 配列とポインタを同列に扱えるのがC/C++の強み。
嫌なら使うな。
>>222 >C言語の方がより良い
誰にとって、どういう点で「良い」つってんだお前は。
188からの流れ読んだら?
移植性とか実行時の効率とか学習コストの点で「良い」んだろ
まあ個人的には速度に関しては有意な差は無いと判断するけどな
初期コストが低くてもその後ずっと開発コストが高かったら意味ないだろ。
開発コストが低くてもエンドユーザで実行コストが高かったら意味ないだろ。
C++ が最適
1〜2行目と3行目に関連が無い
これがファンタジーってやつかw
>>225 >188からの流れ
そっからかよw
強引な言い訳だな。
ごめんな
言い訳じゃないんだけど
>>208にまとめがあったからつい…
ばかばっか
>>227 いちいち説明を書かないと関連性が分からない
めんどくさいやつだな
いや、関連性は無いぞ。
C++が優れていると主張したいならもっと客観的・論理的な視点を持ってくれ。
226の場合はまず、開発コストという、あいまい且つ広範囲な言葉を使うのをやめて、
もっと定量化可能な別のものさしを定義する必要がある。
次にそれを測定し比較、さらに開発コストとそれ以外のメリットデメリットを比較検討、
その結果C++が最適だと主張するなら構わない。
それを行わず「C++最適」の一点張りでは信者は盲目だと思われても仕方が無いな。
長い。
3文字でまとめてくれ。
無関連
信
者
乙
な
お
ガ
…どうでもいいですが、C++ を More C として使う発想のない人がいますね。
そんな使い方つまらないから
BetterじゃなくてMoreなのかよwwww
さすがC++信者、その発想はなかったわwwww
俺は自分でプログラム書くときは C++
しかし、外部の業者に仕様書出して作ってもらうときは原則C
C++でかかれたひどいプログラムは見るに耐えない
型チェックに厳しいところだけでも C++ の方が良いと思うが、もしかして C99 で同レベルになってたりする?
CINTで開発したら、コンパイル頻度へってええぞー。
少なくともUNIX界では一部のtkが使ってる程度のニッチ言語
UNIXだとやはりCなのかね
GNUとかも大体Cだと思う。
プロジェクト管理ツールのsubversionはCでした。
FireFox3は大体C++でした。
>>240 C99はその辺の仕様は変わってない。
どっちかってーと、便利な方向に拡張されてる印象。
(複合リテラルとか可変引数マクロとか)
247 :
デフォルトの名無しさん:2008/09/26(金) 10:34:37
いま全部読みなおしたけど意外と良スレ
ただもうちょっとまともなC++擁護派の意見が欲しい
Mozillaのドキュメント読むとアレはもはやC++とは呼びたくない代物だ
まあ確かにC++の可搬性は低いと認めざるを得ないな
C99は独自拡張の現状追認(inlineとか)と可搬性向上(int32_tとか)
それとブロック途中で変数宣言が出来るようになった(C++から逆輸入)
あとC99とC++とは互換性がない
(まあ常識的な範囲では大丈夫だし、すぐに仕様を取り込むだろうけど)
結構Cも変化してきてたんだな。
C でプログラム書いている人って忍耐強いね。
C++ を覚えてから C でプログラムを書くなんて考えられなくなった。
Ruby を覚えて凄く便利だと思ったけど C++ とは役割が違うので C++
は捨てられません。
OS の API を COM 風のインタフェースにすればよかったのに。
C++はほかのプロセスにクラスオブジェクトを送ろうとするだけで困難に直面するからなぁ。
それはアラインメントの問題じゃなくて??
だとするとCで構造体送っても同じだと思うけど。
vtable付き構造体を別プロセスに送るのは、そもそも無茶ではなかろうか
一般的な OS だと vtable 付きに関わらず別プロセスに送れないんじゃない?
>>253はマヌケな指摘!
もちろん、COMやマルチスレッドを使うときC++が多少不便なのは分かるけど
それは言語の文法的な問題というよりは、言語がサポートするレンジの問題
ガキの時に遊び場だった小山がたくさんあるとこで
台風が過ぎた後、小山が崩れて穴が開いてたんだよ。
石が崩れててその中に懐中電灯もって仲間と入ってった。
そして通路みたいなとこ奥の方へいったら
人形みたいのが並べてあって今度は横のほうに部屋というか
空間があった。
壁に懐中電灯で照らすとなんか落書きというか
絵が描いてあったぜ。
北斗七星はガキの俺でもわかったが
あとは空を舞う女の絵
テーブルみたいなのがその部屋にあって
天井のほうにも絵があったから
その石テーブルに3人で乗っかったら
そのテーブルの台が割れちまった。
痛いと思ったらなんか石と鉄の棒みたいなので
足挟まってた。石をどけると
何か大きな箱の中に入ったみたいで中には
キラキラ光る数珠の玉みたいのとか、鉄の棒、汚れた布切れ
と小さい円盤みたいなものが何枚かあったよ。
俺は面白えと思ってみんなに内諸にしようと約束
して外にでることにした。
俺たちが外に出ようとして元の出口の方にいったら
ゴゴゴゴーとか地鳴りが聞こえて水が突然津波みたいに
俺たちを流した。
その後俺たちは田んぼまで流れてその場所が
どこかわからなくなっちまった。
後で大きくなった時にそこの場所が改めて確認した。
崩れたまま今は草ボーボーになって残ってる。
MPI使った分散計算とかに使うととたんに困る。
ポリモフィックなことしてたりすると、型情報をつけておくって、
受けた方は型情報に従ってseitch caseなどで羅列した生成ルーチンを選択して・・・てなことになる。
新しい派生型を加える度にcaseを追加しないといけない。
自動的に派生クラスのコンストラクタを実行とかできないからね。
これはなにもプロセス間通信じゃなくても、クラスオブジェクトのデータをいったんファイルにセーブして再度読み込むとかでも同じ問題が起こる。
だからCで同じことやろうとしても同じ問題が起こるっつーの。
オブジェクトをそのままファイルに保存とかアホかと。
あと型情報でswitchとかやるのは単なる設計ミスか、あるいはテンプレートで回避できる。
自分の不勉強を棚に上げて、口数少なく記述できないことを言語のせいにすんな。
switch caseを無くせるのがC++の面白いところなんだけどね
どんな言語でもそりゃswitchの羅列になる。
よその言語だとそうならないようにシリアライズって機構があるだろ。
C++だってBoostとかが作ってはいる。望みどおりのものかどうかは別として。
仮想関数使ってできるだけswitchとかif elseをなくすのが
C++の方向じゃないのか
禿もそう言ってたろ
でも最終的には、マシン語でifになるからEじゃんEじゃんEEjump
x86で大抵のコンパイラは call [eax+table] みたいなコードになるぞ
仮想関数によるswitch排除は美しいと思うけど
現実的には、あとからの機能追加とかで
ちょっとした分岐が入る場合にgdgdになりがち
仮想関数をしっかり使うには、結構設計に悩むが、うまくはまるとかなりいいぞ
オブジェクト指向やデザインパターンのおかげで変更に強く大きなアプリケーションも
作りやすくなったんだよ。GoF のデザインパターンはほとんど仮想関数使ってるよ。
仮想関数である必要はないよ
テンプレートメソッドやステートやストラテジーパターンなんてジェネリックスでもできる
他は忘れちゃった
270 :
デフォルトの名無しさん:2008/09/29(月) 21:39:05
都銀レベルの本当に巨大なシステムは皆COBOLだけどな
でも、COBOL開発には夢がない。楽しくもない。
そう言えば禿はC++の設計時に「楽しくプログラミングできる事を目指す」
ような事を言っていたな
その割りに出来上がったのがこれかよ
プログラマーから拡張につぐ拡張の要求が押し寄せて
C++標準化委員会が断り続けたが押し切られたものもあって
カオスになっている
それもまた一興
一つの言語で何でもやろうとするからこうなる
MultixやPL/Iと同じだな
まーMFCみたいに我が道路線で行けばそれなりに安定してる言語だけどね
今日、インストーラのカスタム動作というのをC#で実装してて
初めてドットネットのライブラリを使った
何だあれは!
ほとんど同じ機能を持つ違う名前のクラスが山ほどあるじゃないか
InstallerCollection って何?ただの配列じゃない
InstallContext って何?辞書を一つ持ってるだけじゃない。つまりただの辞書じゃない
あんなのを使う機会が増えていくのは嫌だな
スレと関係なくなっちゃってスマンな
演算子のオーバーロード
>>281 演算子のオーバーロードって本当は入れたくなかったんだ。
初めて知った。
>>282 あんな糞気持ち悪いもんマトモな神経持ってたら拒否る
タイプ量が劇的に減っていいじゃん
お前のタイプ量が減った分周りの人間が苦労してるだけなんだけど
まぁ、お前はいいんだよね、お前はさ
D&E読んでみたけど、演算子オーバーロードについては
Dr.Bjarne自身は入れたくなかったわけではないらしいよ。
実装の難しさ(勿論コンパイラの。)やユーザにとっての難解さがあるんじゃないかと
ためらってたが検証したらそうでもなかったので取り入れたと言ってる。
「どんな言語を使ってもわかりにくいコードを書く人はいる。
誤用を恐れるよりは、便利さに目を向けた方がいい」とのこと。
実際、行列とかのクラスで mat1.Multiply(mat2.Multiply(mat3))とかイヤすぎる・・・
>>285 それはお前の職場環境が悪いだけ。
バカがバカなコード書くのを言語のせいにするなと。
_,,....,,_ _人人人人人人人人人人人人人人人人人_
-''":::::::::::::`''>便利さに目を向けた結果が今のC++だよ!! <
ヽ::::::::::::::::::::: ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^^Y^YY^Y^Y^Y^Y^ ̄
|::::::;ノ´ ̄\:::::::::::\_,. -‐ァ __ _____ ______
|::::ノ ヽ、ヽr-r'"´ (.__ ,´ _,, '-´ ̄ ̄`-ゝ 、_ イ、
_,.!イ_ _,.ヘーァ'二ハ二ヽ、へ,_7 'r ´ ヽ、ン、
::::::rー''7コ-‐'"´ ; ', `ヽ/`7 ,'==─- -─==', i
r-'ァ'"´/ /! ハ ハ ! iヾ_ノ i イ iゝ、イ人レ/_ルヽイ i |
!イ´ ,' | /__,.!/ V 、!__ハ ,' ,ゝ レリイi (ヒ_] ヒ_ン ).| .|、i .||
`! !/レi' (ヒ_] ヒ_ン レ'i ノ !Y!"" ,___, "" 「 !ノ i |
,' ノ !'" ,___, "' i .レ' L.',. ヽ _ン L」 ノ| .|
( ,ハ ヽ _ン 人! | ||ヽ、 ,イ| ||イ| /
,.ヘ,)、 )>,、 _____, ,.イ ハ レ ル` ー--─ ´ルレ レ´
演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
なんでそんな入社一年目でも普通に使ってる初歩的機能に熱く議論してんだ?
新入社員がlambdaとmplでばかり書いてしまって困ってますとかなら議論できそうだが。
なんでC++擁護派っぽいカキコってこんなヌケてるの?
アンチの工作なの?
C++擁護派って新人もしくは学生でWindows好きそうなイメージがある
>>289 ×演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
○C++ってバカが俺ってSUGEEEEEEするための言語だろ
G++ごときで挫折したマヌケですね
演算子オーバーロードは単なる表記の便利さの問題じゃなくて
ダックタイピングの言語では必然と言っていいと思うがな
ダックタイピングでは、アヒルのように鳴くものはアヒルである
だから、整数のように足せるものは+で足せなければならない
実際RubyやPythonでもそれは採用されているし
基本的な道具になっている
C++もテンプレートの世界は一種の静的ダックタイピングだから
演算子オーバーロードは本質的で、それなしでは
組み込み配列やポインタ、関数を
全く同じように扱えるSTLのようなライブラリは作れないし
生まれなかったよ
文字列の連結が+なのはとても整数のようでは
文字列の + による結合は自然じゃないか?
演算子オーバーロードのない Java ですら文字列は特別に + を使えるようにしている。
operatorが難しいとか感じる奴は死んでいいでしょ
>>298 >operatorが難しいとか感じる奴
誰もそんな話してないんだけど
唐突にどうした?
>>289あたりのことを指してるんだろうが
演算子オーバーロード否定論者ってJava厨あたりじゃないの
今時C#やPythonやRubyにもあるような機能なんだけど
となりのブドウはすっぱいという奴だろう
+は普通可換だけど、文字列の連結は可換じゃないよね。
文字列に+はある意味趣味の問題だろうな
BigNumや複素数、クォータニオン、ベクトル、行列のようなものに
演算子オーバーロードが使えるかどうかはかなり大きな問題だが
303 :
デフォルトの名無しさん:2008/09/30(火) 15:56:59
演算子オーバーロードは複素数計算では必須。だから、C++とC#しかない。
Fortranにもある
DにもDelphiにもある。
参照とポインタ、両方ともC++に実装せずに片方だけ実装すれば、よかったかも、
アクセス修飾子は削れない。
例外処理も削れない。
STLは微妙、自分で作った方が使いやすい(気分がする)
あんま削るとこ無いね。
STLを自作してたら、他人のライブラリと組み合わせるとき悲惨だぜ
自分の作った車輪と他人が作った車輪が乱立しているなんて耐えられない
>>306 参照とポインタはclassとstructぐらい違うぞ
>>306 ターゲット環境が貧弱で、constやカスタムアロケータや配置newを使いまくる人?
そういう人は例外も使わなそうな印象があるが
>>308 > classとstructぐらい
それって大した違いじゃないなw
>>306 >STLは微妙、自分で作った方が使いやすい(気分がする)
これは狂気の沙汰と言わざるを得ない
参照に関してはコンパイラ側で
ポインタを用いた内部実装しろと強制されているわけではないが
実質ほとんどのコンパイラは同じにしているだろう
せいぜい関数のインライン展開の場合に変わるぐらいか?
stlは結局必要なものがない
あと基本設計がクソ過ぎる
とうぞ糞でないものを教えてください
とうぞ糞?
>>314 「ただ1つのベースクラスから継承して作っていないとか、どんだけクソ設計なんですか^^」
とかだったら笑う。
かゆいとこに手が届かない感じだよ。CStringからstringとかにわざわざダウングレード
するのもどうかと思う。
CStringのどのあたりが優れてる?
STLといえば、まずは vector, list, mapじゃないの?
string系はおまけ的なものだから論点が違うよ
そもそも環境依存のアプリ屋は、C++を積極的に使う必要はないだろ
C#やobject Cと、最新ライブラリをを使う方が効率がいいじゃないか
それに対し、C/C++系は組み込みや科学計算も含む広いレンジを考えてるから
たとえば stringに文字コード変換など気軽に組み込むわけにはいかない
ここには、言語の乱立を嫌がる人もいるが違うと思うな モノには適材適所がある
vectorはメモリの連続性が信用できないから素直に配列の方がいい
listもリンクリスト程度なら自分で作った方が安心できる
mapは便利だけどクソ遅い
STLは富豪プログラミングできるときにだけ使えて
mapとsetだけが多少とも役に立つ
メモリが連続している必要があるの?
まあ、連続していないとアクセスは遅くなるけどさ。
気にするほどのものかな
連続してないならないで別にいい(それがdequeだしな)
信用できないというのが大問題
vectorで確保するメモリは連続だったでしょ
stringと勘違いしてない?
std::vector 連続 で検索すれば答えは出てくる
当初の規格書に明言されてなかったのは問題だったけど
言語が効率第一なわりに何でもコピーベースだよな
CVOつっても限界あるし
参照ベース + GCな言語より非効率な面もかなり多いんじゃないか
std::stringは中途半端な存在だと思う
mutableで、しかしバッファの直書き換えはできなくて、
vector<char>に比べて文字列処理において著しく便利というほどでもなく
STL algorithmとの直交性にも欠ける
STLは、C++標準ライブラリの中では一番マシじゃないのか
iostreamだのlocaleだのはどうしようもない
330 :
329:2008/10/01(水) 10:31:04
なんだCVOってw
RVOだ、すまん
331 :
デフォルトの名無しさん:2008/10/01(水) 10:37:52
カスタム・ヴィークル・オペレーション
>>322 広いレンジって言っても文字が文字コード想定してないってだめでしょ。
JavaもC#もStringとかStreamはちゃんと変換できるようになってるからみんな
おとなしく使ってるでしょ。
文字コード変換ってでっかいテーブルが必要だったりするから
組み込みでは難しかったりするんだろう
ライブラリに任せるというのは比較的真っ当なやり方だと思うがね
そもそもC/C++標準ではファイルシステムの存在すら仮定してないし
そういったシステムに依存するような仕様を緩くして
実装可能な範囲を広げようというスタンスなんだろう
標準にlocaleがあるしcodecvtファセットがエンコード変換することになってるよ
まあ糞だけど
間違った所を緩めてどうでもいい所を締めるから
COAP(笑)だのvector<bool>(爆)だのみたいな悲劇が生まれるんだよ
どう考えてもMFCやVCLが実用的
>> 336
組み込みでMFCやVCLは動きません 役割が違うのに批判されても困るわ
何度ループしても糞であるという結論にしか至らないC++(笑)
アホですね(笑)
組み込みでSTLなんてそれこそ使えるか
言語の標準ライブラリが特殊環境を想定する必要はない
いまどきの組み込みはJavaや.NETが普通に動く世界なんだろ
そんなのはハイエンドか産業用だけです
Lispで動く炊飯器を見たい
STLは、単品で使うには粗末だし。
メーカーのライブラリの基盤に採用するには癖が強すぎる。
何より標準ライブラリを名乗っている割に後発なのが痛い。
もはや組み込み専用マイナー言語に落ち果てているのに
仕様的には肥大化しきってる
ぶっちゃけCでいいじゃん
人生をかけてC++を学んだ様な奴は認められないんだろうけど(笑)
>>346 主な需要は組み込み、ゲーム、パッケージソフト
てなとこか
でも組み込みはどっちかっつうとCのがまだメインなんじゃないか?
他ではほとんど死んでるな
パッケージも、本当はC++である必要が無い気がするな
.NETやJavaまでいかんでも、リッチなOSを前提にできるんなら
GCぐらいはあってもいいし、ギチギチのzero overhead ruleなんて必要ない
結論としては、CとC++の中間くらいが一番良さそうだな。
つまり、基本Cみたいな使い方でゴテゴテしたC++の機能は使わなかった俺が正解か。
C++の素晴らしいところは本物のデストラクタを持ってることだ
リソースの完全な管理という点では今でも右に出る言語はないと思っている
>>349 そっすねw
自己管理がんばってくださいww
うんw
実際自己管理を頑張らなきゃならない場合ってのはあって
そういう時だけはC++は本当に役に立つし、なくてはならないんだよ
そういう時だけはな
Pythonみたいに参照カウントとマーク&スイープ併用してる言語もあるよ
C++でshared_ptr使って参照カウントは出来るが、フツーのGCより効率悪いよね
便利機能一切使わない覚悟でないとC++のコードは速くならないっつか
確実にCより遅くなる
スレッドのことは勿論なにも考えてないからマルチコア時代では先が見えてるしな
デストラクタならJAVAのほうがマシな実装だと思うぞ
>>353 廃棄のタイミングを厳密に制御したいんでしょ
Pythonはブロック抜けで参照カウント0になれば廃棄されるし
(当たり前だがデストラクタは定義できるし実行される)
巡回参照でも大丈夫だよ
Dは最初の狙いは悪くなかったと思うけど
開発者の独りよがりな趣味で終わりそうだね
>>353 Javaのはデストラクタじゃなくてファイナライザ
ファイナライザは全然役に立たない
C++/CLI最強説
>>358 割と本気でそう思ってるんだが誰も同意してくれない
C#もデストラクタないんだよな…
IDisposable
それデストラクタじゃなくてdelete
using(Hoge hoge = new Hoge())
{
//なになに
}
確かにマルチスレッドとかマルチプロセスに特化した言語は欲しいな。
うお、そんな書き方出来るのか初めて知った
C#いいな!
でもC#にはローカル変数とかのfinal宣言子がない…
あればいいのに あれば…
>>364 同じキーワードをあっちこっちの用途で流用するところはC++譲りみたいだな
>>364 それ使いたいオブジェクトの数が増えると構文が悲惨よw
もしかしてJavaもできるの?
C++はdeleteし忘れるからGC最高とか言ってる奴らが
結局finally節にdispose()とかclose()とかunlock()とかチマチマ書いてるのが
とっても滑稽だと思って以来いい印象ないんだけど
出来るなら認識改めないと
スマポでええヤン
コンテナに入らないふざけた奴か
スマポが悪いんじゃないんです
auto_ptrがアホの子なだけなんです
COAPとか使いたがる奴らが悪いんです
許してあげて下さい
まさに 「痒い所に手が届かない」
tr1まで標準にリファレンスカウントなスマポ入れなかったってのは、
そもそも標準にスレッドセーフという概念が無いからか?
どっちみちSTLがスレッド?何それ?状態だから関係ねーけどな
ヨボヨボすぎて、もうモダンなOSの主要言語の座はとっくに引退していい仕様だろ
お爺ちゃんをいつまでも無理して使いすぎなんだよ
0xでようやくスレッドの概念が入って
スレッドローカル変数とかが定義できるようになるらしいけどな
マトモになるのはいつになるやら
iostreamとか、仕様練る時に変だろこれと誰一人思わなかったのかな。
え?マトモにする予定なんてあるの?
>>377 sprintfひとつですむことを
だらだら << 繰り返して書くのが楽しい。┐(´∇`)┌
>>370 GCが便利なのはいっちいっちコピー先バッファとか
頭の悪いもの引数に用意しなくて済むからだよ。
shared_ptrとか使って、ただのポインタアクセスをいちいち高価なものに
置き換えたりする必要も無いしな
GCはshared_ptrなんぞよりよっぽど高価ですが
>>377 iostreamの凄いところは、初期の仕様を捨ててわざわざ新しくしたのにそれでも糞であるというとこだね。
iostream絡みの昔のコードはどのみち通らないんだから、それなら思い切って捨ててしまえば良かったのに。
マネージだからメモリリークしないと思っている人。
確かに、プログラムが終了するときにはリークしないでしょう。
けれど例えば、ある操作を繰り返すたびにメモリが解放されずに残ってしまう
ということは有り得ます。Javaでも同様です。
たとえば、ArrayListにStringを追加し続けているようなものです。
GCは普通に使う分には便利だが
ゲームのオブジェクト管理とかやろうと思うとウザくなる
>>384 unmanagedでもプログラム終了したらリークはしないでしょう。
何か特別なことしない限り。
>>358 C++/CLIもコレクションに入れるとデストラクタが無力化する
まあ、そんなに参照されるのがいやならソフトリファレンスでも使えや
>>387 msclr::auto_handleは?
そもそもauto_handle自身のデストラクタが働かないから_
やっぱりmallocが最高だな。
aro
C++0x みたいな継ぎ接ぎはもういいから、新しいプログラミング言語の作成しろ。
STL を組み込みで使えないという意見があったが、
処理系のデフォルトの operator new とか std::allocator
とかを使わないというだけで、<algorithm> も使うし
自前アロケータでコンテナも使うよ。
unixの設計のためにCを作ったように、
新しいOSのために、全く新しい言語が生み出されるであろう。
んなこたぁー、ない。
Be…
並列プログラミングが重要視される時代なのでやっぱり新しい言語が必要。
400 :
デフォルトの名無しさん:2008/10/02(木) 18:33:23
ConcurrentC
Nextだろ
素朴な疑問なんだが
C++がCより開発効率が良いって主張あるよな?
ひとによっては暗黙の了解になってるぽいんだが
それって誰がいつどうやって比べたの?
ソースはあるの?
鉛筆を一本ずつ数えるのとダースで数える程度の違い
ヘッダファイルの仕様化度が高いともいえるけど
所詮はマクロアセンブラを構文化しただけの言語
いくらでも非効率にも効率的にもできる
↑に付いては知らんけど、COBOLの方がJavaよりも開発効率がいいなんて言い出すCOBOL脳には成るなよ。
405 :
404:2008/10/02(木) 23:36:10
>>402 高級言語の中で比較するんならどっちみちC++の生産性は低い
それ以上に再利用のしにくさが致命的
ABIが糞でコンパイル時計算への依存度が高いからな
一応COBOLは開発効率を重視した言語だ
ただし、プログラマー向けじゃないけどね
ソースは?脳内?
個人的には、高級言語の皮を被った低級言語って感じでいいんだけどな。
基本Cでいいんだけど、少しだけ楽したいみたいな。
ソースもなにも両方でプログラム作れば感覚でわかるだろ。
CがC++よりいいって・・どうやってWindow表示すんの?MFCとかATLとか使わんの?クラスも使わんの?
CreateWindow(........)とかばっかしてがんばるの?なんなの?ばかなの?
いい加減、開発の目的や背景を理解できるようになってくれ
適切な設計をすればCよりは保守性も効率も上がると思うんだけど。
なんか極端なアンチが沸いてるが(俺ももちろんC++が楽だとは言わんが)、
必死に叩いてる奴って、クラスやテンプレートの使い方のセンスが無いor
理解できてない馬鹿ばっかりじゃないの?
単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
機能の使い方が悪い以外に考えられん。
> 単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
> 機能の使い方が悪い以外に考えられん。
「キッチンシンク」という言葉は知ってるか?
なぜMultixが失敗してUnixが生まれたかを知っていれば
「大きいことはいいことだ」という単純素朴な発想は出てこないはずだ
C++みたいな半端な言語で何でもやろうとするのではなく、もっと高級で
ずっと生産性の高い言語とCを組み合わせるという選択も普通にあるんだが、
それも見えていないようだね
まぁ、実際を考えると、マルチプラットフォームで使えるちゃんとしたコンパイラがあるかどうかってのもあるなw
>>414 なるほど、C++の標準の策定者は「理解できてない馬鹿」で「機能の使い方が悪い」
からiostreamとか作っちゃうわけだな
実用性は無くても、オブジェクト指向言語の可能性を立派にアピールしたよ
C++をOOの代表であるかのごとくに言ったらOO信者の猛反発喰らうぞw
C++はOOのOOらしさを極限までそぎ落とし、効率に振り向けた言語だからな
オブジェクト指向言語の可能性←大間違い
オブジェクト指向の可能性←ギリギリおk
SimulaとSmalltalkに失礼だな
実用性皆無の実験言語が一般にアピールはないだろ
影響領域が違いすぎで失礼とかないわ
424 :
414:2008/10/03(金) 04:21:43
>もっと高級でずっと生産性の高い言語とCを組み合わせるという
>選択も普通にあるんだが、それも見えていないようだね
なんか偉そうに言ってるけど、C++は実行効率最優先の言語なんですが。
生産効率が良くて、速度やメモリ効率を犠牲にしてでも高級な機能を持つ言語が欲しいのなら
最初からC/C++は選択肢に入らないだろ。見えてないのはお前の方だ。
その低劣な生産効率を補えるほどに速くすらないのが問題なんだろ
vtbl持たなきゃならないのはオブジェクト指向言語の本質的な非効率性だから
C++でも他でも一緒だしな
他の言語は知らないが、GNUとMSのコンパイラは
純仮想関数を使わない限りVTBLは使われないよ
そりゃ使わない物は使わないし、まともなコンパイラなら省くに決まってる
でも継承を有効利用するにはvtblはないわけにはいかない
継承と多態性はオブジェクト指向の根幹だ
だから、継承とプリモにはVTBLは必要ないぞ
COMとか使ったこと無いか?アレだ
インスタンスが自分が何者かを知らずにどうやってポリモやるんだ?
オブジェクト指向がどうこうってより、同じような設計をしようと思ったら
Cでやっても同じようなコード(vtblと同じ、関数アドレスを介した呼び出し)になるわけで。
原理的に無理なものをどうこう言っても仕方無いだろ。
ただ、D&Eに「多重継承をサポートする為に、vtblを”単一継承なら使える最も速い方法”で
実装しなかった(加算1つと代入1つ増えた)。ここだけは唯一ゼロオーバヘッドルールに
違反することになった」って書いてあったけども。
それすら気になるほど速度を重視するのならそもそも仮想関数を使わないor
vtblが必要になるような仮想関数の書き方をしなければいい。
そんな滅茶苦茶ギリギリで設計の自由度も無い状況で仮想関数使うような
多態性を用いる設計を使おうとする方がおかしい。
>>428 あまり詳しくないがCOMはvtbl使ってるはずだよ。
>>430 そうそう
だから効率が重要な場合はあらゆるOO言語は使えないってこと
それはC++だろうとなんだろうと一緒な訳で
勘違いさせたが、手続き型言語においてVTBLが必要となる一つの条件としてCOMを挙げた
手っ取り早くは適当にリバースエンジニアしてもらえればわかるのではないだろうか
あくまで、コンパイラの実装の話だけどね
>>412,413
結局何も説明できずに馬鹿って言うだけなの?。なんなの?バカなんですか?
C++のなにが難しかったんですか?何がわからないのかわからないのですか?
>>433 真性の馬鹿に何かを教える様な物好きに、そんな簡単にめぐり合えるとでも思ってるの?
何か眠気でちゃんと読んでないのかな
C++は手続き型言語
要するに仮想関数程度じゃインスタンスを特定できるから
オーバーヘッドはCの関数を呼び出すのと引数分しか差がない
純仮想関数のようにインスタンスを特定できない場合に限り
VTBLを通して関数が呼び出される
これはルックアップテーブルだからそれなりに高コスト
こんなもんで理解してくれ
あ、ただのバカアンチなんですね。了解しました。テンプレートは難しいですもんね。
VisualBasicという言語をお薦めしておきます。
>要するに仮想関数程度じゃインスタンスを特定できるから
何だものすごいバカか
>>435 仮想関数はvtbl使わなくて純粋仮想関数は使うって言ってるの?
本気で言ってるの?
よく眠って頭冷やせよ
仮想関数批判はC++というかJavaとかC#とかもろもろ全部だしあんまし
意味ないような。
しかもそんな奴はむしろC++でメタテンプレートでも極めればいいし
C++向きだと思うが。
OOの本質的なオーバーヘッドとC++固有の問題を
ごっちゃにして叩く輩が多いからな
MFCはSTLが固まる前に発売されたから勝手に作った独自仕様などと言れれるゆわれはない。
>>436 TMPなんぞを嬉しがってるのはC++信者だけだろ
パターンマッチングやダックタイピング/structural subtyping、
ファーストクラスの関数、lambda式、クロージャ
今時の高級言語がもっとマシな形で備えている機構が無いために
C++信者はあの醜く汚いバッドノウハウを金科玉条のごとくに
有難がってるんだろ
しかもC++からソースレベルでしか再利用できないというデッドな技術だから
C++信者はあくまでもC++にしがみつくしかない
タコツボだな
>>442 お前みたいな流行りの言語機能好きは流行りの言語をそのときどきに勉強して
使ってればいいんじゃねーの?
Haskellでlambda使いまくりのWindowsプログラミングでもやってりゃいーじゃん。
なぜそれが現実的じゃないのか、なぜ誰もやってないのか、なぜ言語機能だけで
ソフトは作れないのかを知るといいと思うよ。
>>444 Javaですらlambda式やクロージャを取り入れようとしてるのに今更何言ってんだ?
>>444 自分に都合の良い解釈ばっかしてると馬鹿に見えるよ
Cより古いLispをガン無視して単なる「流行」とか言ってるのが笑えるな
連投乙
お前らどんだけ馬鹿馬鹿言い合えば気が済むんだよw
>>435 本当にC++を知っているとは思えない発言だな
仮想関数があるなら必ずvtblは作られる
静的に型が確定している場合(参照を通さない場合)には、
vtblルックアップは要らない
ポインタや参照の場合は静的に型が確定しないので、仮想関数の場合は
常にvtblルックアップが発生する
こんなのは常識だろ
つーか、C++でどうやってポリモーフィズムを実現してると思ってるんだ
自分の知っている処理系は全てvtblだが
C++にはvtblを用いて実装しなければいけないという決まりはなかったはずだが
>>453 ああ、確かにちと実装より過ぎる説明だったか
いずれにせよ
>>435が言っていることは明らかな誤り
つっても店頭に並んでるアプリの9割はいまだにC++製だからなあ。
やっぱOSネイティブの言語は機能どうこう以前の強力さがあるんだよな。
まあC++にもlambda/bindが来年付くしまだまだ現役続投かねぇ。
>>455 Windowsと同じだな
シェアそれ自体が最大の強み
言語が糞でもな……
マイナーなもの使って人柱やるのもいやだしな
>>402以降、誰もC++の開発効率に触れないのな
Office や Web ブラウザのような巨大で複雑なアプリをサクサク動かすには
今のところ C++ しか選択肢はないんじゃないか? D はよく分からないが。
>>460 具体的にどのレス?
ちなみに402は↓これだぞ?
>素朴な疑問なんだが
>C++がCより開発効率が良いって主張あるよな?
>ひとによっては暗黙の了解になってるぽいんだが
>それって誰がいつどうやって比べたの?
>ソースはあるの?
MacではC++じゃなくてObjective-Cが母語なんだろ
だから、C++でなければならないというわけでは全くないだろう
少なくともOfficeみたいなリッチなOSの上に乗っかって動くアプリなら、
ネイティブコンパイルさえ出来れば、もっと動的な言語でも十分ってことになるん
じゃないのか
>>462 単品のレスじゃなくて流れで分かるだろ
>>402には「C++がCより開発効率が良いがひとによっては暗黙の了解になってるぽいんだがソースは無い」でこのスレ的にはFA出てる
何かしら覆したいならお前がソース出せ
C++単品の生産効率についてなら腐るほど言い合ってるだろ
465 :
462:2008/10/03(金) 12:59:24
>>464 いや別に覆したいとは思ってないよ、事実関係をはっきりさせたいだけ
じゃあこのスレ的には「C++の開発効率はCより高いとは言えない」でFAだな
>>465 大した根拠も無くC++の方が開発効率が良いと思ってる奴は確実に居るが、本当の所は誰も知らんがFA
C++はCを内包するので比較する意味が無い
また馬鹿が湧いた
C++はCを内包するので比較する意味が無い(キリッ
いくらかマシに見える様に訂正しときました
スーパーセットである事によるオーバーヘッドが有意か否かは
開発者自身や処理系の問題であって言語の問題では無い
カプセル化できるだけでも有難い<C++
まあ「隠匿されたら処理の流れが解らんではないか!」とか
言い出す奴にとっては厄介なんだろうが。
>>470 肥大化した仕様はまさに言語の問題だろう
さらにC++の場合は禿が実用性を謳ってるんだから開発者や処理系の都合も言語とセットで考えるべき
C++ は基本的にサブセット(C部分)に劣らない。
C 部分の性能は普通の処理系なら落ちないから。
>>473 流れ嫁よ
(実行時の)性能を比較してるわけじゃないだろ
じゃあ、何が劣るの?
「C++なんて駄目。Cの方がまし」という事にしたがっている奴の脳。
C++ は C よりもコンパイラの選択肢が少ないところが劣っているかな。
俺はそんなことで困ったことはないけど。
C++が一番ひどいのは学習コストだろう?
罠とバッドノウハウが多すぎる
そしてそこまでして学習したものは、C++を使うとき以外何の役にも立たない
だからこそ「バッドノウハウ」なんだけどな
boostはC++を象徴してる
言語仕様の貧弱さを無理やりカバーするためにマクロとテンプレート使いまくり
お陰で糞みたいにコンパイル時間がかかるわ
解読不能なエラーメッセージを大量に出力するわ
仕方がないからソース読もうにも追う気すら萎えさせるわ
インテリセンスはクラッシュさせるわ
プログラマの時間をドブに捨てさせるにはこれ以上ないいい言語だと思う
標準でソケット通信ライブラリすら無いんだから規模はむしろ小さい方だろう
Cよりは当然覚える事は多いが
C++作った理由の陰謀論みたいな話になってきたなw
ねぇ、C++擁護派ってなんでこんな馬鹿なの?ねぇ、なんでこんな馬鹿なの?
オブジェクト指向だけに、先人の思想を忠実に継承してるからな。
反対派も大概バカだけどな
結局は適材適所
C++はアプリを作るには最低の言語
ドライバやミドルウェアを作る時にはそこそこ役に立つ言語
それでいいじゃないか
お前らプログラムもろくに組めない癖に文句だけは一丁前に言うなw
ツンデレなんだよ
継承も例外もオーバーロードもテンプレートもなくして
クラスがメンバ関数とコンストラクタとデストラクタを使えるだけのちょっと便利な構造体なだけだったらよかったのに
つか否定派と比べて擁護派が非論理的すぎるだろ
特定分野では役に立つこともあるよねってだけで擁護派扱いか
ありとあらゆる局面で絶対に役に立たないクソ言語でないと気が済まないって人たちの方が怖いです
ネイティブコンパイルできて、Cやasmのobjとリンクできるなら
何でもよくね?
組み込みに関しては、Javaみたいにエディション分けちゃえばいいのにと思う。
EC++とかは消えたんだろ?
>>484 基本的に反対派の主張は
>>484に書かれてる通りなんですけど?
馬鹿で非論理的な擁護派が勝手に
>>489みたいに被害妄想炸裂させて
反対派の奴らはこんな極端な事を考えているキチガイだったんだよ!!!11って五月蝿いだけなんです。
だから擁護派はなんか馬鹿が多いって言われてるんです。
わかりますか?
>>441 そうだとしても、STLが策定された時点でSTLベースに作り直すのが筋だろ?
>>492 MFCを作り直す必要はないんじゃないか?
モダンなC++として書けばATL/WTLのようにただの別物が出来上がるだけで
それに「MFC」という名前をつける必要がない
MFCの導入時はWin16からWin32への移行促進という目的があった
(ある意味今の.NETに似てる)
今や単なるレガシー技術の互換性サポートだろ
>>492 どっちでもいいだろ
どうせウィンドウズが亡くなったらC++の使い道なんか殆ど無いんだしw
>>492 準拠するに足る魅力が無かったってだけだろ
MSC7.0だっけか
>>492 そんな筋はないと思うぞ。
過去のMFCと互換性ぶったぎることになるだろうし。
>>490 一応、ホスト環境とフリースタンディングって区分けが標準にある。
誰も意識していないけど……。
499 :
デフォルトの名無しさん:2008/10/03(金) 19:57:41
492 タコ殴りw
未来の言語
C{
ここC文法領域
}
C++{
ここC++文法領域
}
Perl{
ここPerl文法領域
}
もうこんなのでいいよ
むかしXMLでそんなことしてるのがあったな
Союз Советских Социалистических Республик
>>465 いろんな統計を見たことがあるはずだが、手元にある分では、行数に関するものしか見つからなかった。
Code Complete とラピッドデベロップメントに、ファンクションポイントあたりの行数が C の方が C++ に比べて 2.5 倍多いそうな。
>>504 ただの興味なんだが、その「いろんな統計」が是非見てみたい。
個人的には「ファンクションポイントあたりの行数」では開発効率は測れない(根拠として弱すぎる)と思うし。
↑面白い事をやったつもり
>>494 言っておくが家庭用ゲーム機およびPCのゲームは殆どC++だぞ
一昔前はCで開発してるところも多かったが。
携帯ゲームはほとんどがJavaだが。
想像力無さ過ぎ。よくそれでプログラマやってられるな
訂正、携帯電話のゲームは。
どうして開発言語が C から C++ に移行したの?
>>510 ゲーム開発の規模がデカくなり、プラットフォームをまたいで開発することが
増えるに従って、毎回書きなおしするような開発は非効率すぎるということで
業界全体がそういう流れになったんだと思う。
勿論Cでもマルチプラットフォームで使いまわしの利くコードは書けるけど、
それだけのセンスがあるなら、C++でプラットフォームをまたぐクラスライブラリを書けるし、
よっぽど解りやすくて保守しやすいコードになる。
かといって富豪プログラミングが許されるわけではないし(オブジェクトが裏でやっていることの
時間的・空間的コストが想像もつかないようでは話にならない)、アセンブリ叩く場面もあるけども。
中小では未だにCのところもあるみたいだけどね。
>>511 なるほど。
ゲームでは C++ が C より生産性が高いということですね。
一般論としては、OOが非常に適している分野とそうでもない分野があると思う
関数型が向いている分野とそうでない分野があるように
GUI、シミュレーションなんかはモロにOO向きで
ゲームもそれに相当するだろう
CでOOっぽいことも出来るが、デバドラぐらいならともかく
Xのツールキットぐらいの規模になると結構苦しい印象があるな
>>512 待った、いちがいにそうとはいえない
業界最大手クラスのゲームデベロッパでは例外とSTLとBoostとRTTIとほぼ全ての演算子オーバーロードとほぼ全てのテンプレートが禁止だよ
その他の大手も大同小異だ
それってC++なのか?
>>514 例外やBoostやRTTIはわかるが(コンシューマなら特に)、テンプレート禁止ってのはわからんな。
一体どこの会社を指して業界最大手とか大同小異だとか言ってるのか知らないが
クラス使ってりゃ十分C++だと思うけど。
まさかツール作るときもそれら全部禁止なの?
数値演算まわりのクラスにも演算子オーバロード禁止?
C++を使わないと企画が通らないけど
C++を使うと開発が立ち行かない
つーかさ、同じC++でも例外の有無でまったく別の言語だよな
コードの再利用なんて不可能なんだし
>>515 不安定な俺クラスよりも、boostの同様なクラスを使ったほうがコードがすっきりしたりする。
.俺の10年がboostに塗りつぶされていって泣けるorz
本来C++の諸機能と例外は不可分なんだが
なぜか世の中には例外無しのC++という処理系や開発現場がある
ハゲが泥縄式に例外を導入した歴史的経緯なんでもうあきらめるしかないが
処理系提供側も例外使えないならC++を名乗らないで欲しい
別に言語の全ての特徴を実際に使うかどうかは関係ないでしょw
使わないコードでもバイナリレベルにどうしても影響しちゃうとかならしょうがないけどw
>>515 演算子やテンプレートは決められた人間が作ったものだけ使えっていうことじゃないかな。
例外を禁止する理由は良く分からないが処理系によっては例外を投げなくても重くなる
可能性があるからかな。
コンストラクタの失敗とかはは例外以外のまともに捕まえる方法がないからな言語的に
結局errnoみたいなものに頼ることになって何のためのオブジェクト指向なのかという話に
> 演算子やテンプレートは決められた人間が作ったものだけ使え
それって出来の悪い兵隊集めて仕事する三流請負業務系の発想だな
現在そういう系統ではC++は死滅していると認識しているが
524 :
デフォルトの名無しさん:2008/10/04(土) 18:49:49
>>522 class hoge { ... };
hoge a;
if(!a.ok()) goto hell;
でいいんじゃね?
お話になられません。
といいますか、コンストラクタ内で自己完結してない時点でOOとしてはお話になりませぬ。
ANSI C++ 1998
ANSI C++ 2003
ときて、
C++0
が採択される、まだまた拡張中。
>>524 a の初期化に失敗した後は a は存在しないはず。
だから a にはアクセスできない。
529 :
デフォルトの名無しさん:2008/10/04(土) 19:44:30
>>528 >>524は、iostreamのように、失敗しても例外を投げないような設計にしてある
ことが前提なんでしょ
>>530 ああ、確かにそういう初期化に失敗しない設計もできるね。
しばらく RAII な設計をしてきたからそういうのは思いつかなっかた。
例外のない C++ だとクラス設計もかなり変わってくるな。
某有名ゲームエンジンはC++でOOしまくり例外多用だけどね。
言語の文句ばっか言ってモノ作れないボンクラは原因は別のとこにあると思う。
C++→肥大化
Ruby→肥満化
Windows アプリ開発の主力言語が C から C++ になってしまったのは MS のせい?
MS に否定的な OpenOffice や Firefox まで C++ で開発しているみたいだけど。
パソコン屋で売ってるソフトの90%くらいがWindows用
そのほとんどがVCで残りがVBかBCCかDelphi
>>535 なんでもMSに結びつけるのは違うだろ。
てか何年前の話だww
C#に移るのかって時代に
ww
>>533 >モノ作れないボンクラは原因は別のとこにあると思う。
モノ作れないのと言語の文句を言うのは全く別の話だと思う。
結局擁護派って自分で書いたコードしか弄った事無いから擁護できるんだよな
発言から視野の狭さが見て取れる
>>541 俺にはその擁護を否定に入れ替えるとその通りに思える
それともアレか、バカが書いたC++のコードを弄ってるとC++が嫌いになるとかか?
擁護否定に関わらず、バカが書いたC++のコードがクソなのは誰もが知ってると思うが。
バカが書いた世界地図を思い出した
>>541 その文面からは視野の広さが見て取れない
スレタイとどんどん離れてくなw
ただのバカスレだしな
スレの趣旨とは合致してるからまったく無問題
すぐ顔真っ赤になるC++信者を見守るスレです
アンチまっさお、信者まっか
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
C++ のようにマルチパラダイム言語はプログラミングが楽だ。
複数の言語でプログラム断片を作ってつなぎ合わせる方法は結構面倒くさい。
C++のプログラミングが「楽」とか正気とは思えん
LLなら数行で済む仕事に一体何行かける気だ
言語は適材適所で使えよ
ネイティブなobjを吐く言語は要するに高級なアセンブラなんだからよ
末端作業員はPerl永遠にやってな
1つのプログラムは GUI からレイトレの計算までいろいろな部分が混在してる。
これらをそこそこカバーできるメジャーな言語は C++ 以外に何がある?
そのぞれの部分に得意な言語を使うこともできるがリンクが面倒くさくなる。
低所得スクリプターが紛れ込んで奮闘してるんだろ。
厨房はこれだから困る
今時ゲームだってLuaだのPythonだのスクリプトエンジンの一つや二つ
入れ込んでるだろ
gaucheの作者はスクウェアでCGのプロダクションシステムをLispで書いてる
というかLispは昔からCG分野で主流で、今はPythonが取って代わっている
Emacsは実際にはLispインタプリタで、だからこそあれだけ強力なエディタなんだ
馬鹿が書いたコードは言語問わず糞だが
他言語に比べてC++は馬鹿が糞コードを非常に書きやすい
しかもC++では優秀な開発者でもバッドノウハウを身に付けないと危険なコードの罠にはまる
C++&Python最強ということで終了
>>556 それはかなり金をかけて作られるゲームエンジンに統合されているからできること。
普通のアプリでそういうことをやろうとするとデバッグも含めてかなり面倒くさい。
COM や .NET で多言語のリンクをしたほうがまだまし。
C++ は C が得意な部分、OO が得意な部分、テンプレートなどを自然な形で結合できる。
これを作った禿は天才
C++ に慣れちゃったからそれが自然なだけでしょ。
「言語は人間を規定する」という訳だ。
>>559 「普通のアプリ」とやらが何をさしてるんだかわからんが
趣味で作ってるおもちゃのフリーソフトのことなら、好きにすれば?
趣味なんだしな
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
と、相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
>>552 ちゃんとした仕組みを作り上げれば、楽になるのだと思う
でも・・・ ねぇ、、 その時間と楽さのトレードオフがなってないよ
それに気づけない人がC++にのめりこんじゃうと本当に時間無駄にしてる
それが楽しいならいいけど
C++は、根底だけ用意して土台が何も無いから・・・
そういう人が土台を一生懸命作ってる感じ
あと、何年したらまともな土台になるのやら
>>552 Cやアセンブラと比較すれば、相対的にまし程度のことだと思う。
C++のデストラクタのような頑強な後処理をCを使って手作業で書くことを考えるとうんざりしてしまう。
>>563 仕組みというのがライブラリのことを言ってるんなら無駄
簡単な話だ、アセンブラにライブラリやマクロを山ほど乗っけたら幸せになるか?
アセンブラはどこまで行ってもアセンブラだよ
C++も同じことさ
でも、Cと同じようにも書けるから
上手くC言語拡張として使うだけなら、良いと思うんだけどなぁ(俺はそう使ってる
ベターCから抜け出せない? なんとでも言うが良いよ
だから個人レベルでC++使うのはいいけど、大勢でC++使うのは勘弁です....
ベターCとは言うけどどの辺がベターなの?
OOとか例外とかテンプレートとか演算子オーバーロードとか便利(ということにしたがってる)な機能を
全部捨ててなおCよりベターな所って何?
引きもっこりがなにいってんだか
>>567 >大勢でC++使うのは勘弁です....
激同。
何がベターかは人それぞれだから、足並みを揃えるのが大変そう。
C の方が大勢で使うのは勘弁
アクセス制御やデストラクタがないのは危なかしい。
そんな些細な便利機能のためだけに他の爆弾を大量に持ち込む方が馬鹿げている
だから571のところでは、テンプレート禁止とかいろいろ制約かけるんでしょ?
それだけで572の言うところの爆弾を抑えきれるかどうかは知らないけど。
テンプレートやインライン関数の代わりにマクロ使いまくるほうが爆弾
例えば C++ にはどんな爆弾がある?
いまさらC++がむずいとか・・ww・・ゆとりには確かに無理www
C のマクロと C++ のテンプレートの使用頻度が全く異なるのは見ない振りですか?
つーか、実際というか仕事の場合、ライブラリとかでどうせ制限されるんだから、
言語がどうのってのはないだろw
いくら優秀な言語でも誰も知らんかったら、実用性ゼロだw
マクロなんて簡単だろ
所詮文字列の置き換えなんだから挙動も明確だしあとからいくらでも追跡できる
テンプレートはカオスすぎて人間が追いかけるのは不可能
テンプレートもmplまで行くと
チャーチ数とかbrainf*ckとかgrassみたいなのに似たノリを感じる
パズル好きが趣味で遊ぶオモチャとしてはいいんだろうけどな
いつからテンプレートが危険視されるようになったんだ。
テンプレートメタプログラミングなら分からないでもないが
そもそも理解できていないやつがそんなもの作るとも思えないし。
テンプレートはデバッガがデバッグをサポートしているからまだいいよ。
普通マクロはデバッガで追跡できない。
>>582 デバッガで追えなくて困るほどマクロを多用する事は無い
テンプレートとは違う
テンプレートはtypedefの奥底にいつ潜んでるかわからないからな
マジで地雷と変わらん
Cの場合同じような処理を繰り返し書くからマクロなんてそんなに使わないよ。
いい加減、C++使ってるとにコストがペイ出来ない状況になってる事に気付いたら?
ドライバや3Dゲーム、フレームワーク作ってる人らはいいんだけど、それ以外のヌケサク共はさ
Cでメタプロっぽいことをやるときは
他言語でのソース生成/(cppではない)プリプロセッサを使うのが常道だろう
cppは貧弱だから、出来ることもたかが知れている
>>587 なぜそこで「フレームワーク」w
フレームワークビジネスってのは上に乗っかる馬鹿な兵隊がいるから
成り立つもんだろう
弱小の無名詐欺フレームワークは含んで無いよ
Cでマクロなんかほぼ使わないし見ないぞ
マクロが危険て奴の職場はどんだけレベル低いんだ?
そんな奴らはCだろうがC++だろうが変わらんだろう
たまに他のプログラマが作ったマクロと識別子がぶつかって悩まされる。
ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
UNIX のヘッダーでさえ major とか定義していてわけが分からなかった。
そのほかにも引数が複数回評価されたり、型がチェックされなかったりすることがある。
じゃあ名前ぶつかってもオーバーロードで華麗にスルーするC++は最悪ですね
>>591 全部、殆どありえないケアレスミスじゃん…
>>592 型に従うから大丈夫。名前空間使うから他人のものとぶつかる確率は低い。
>>593 他人が作ったものだから避けられない。
いや、避けられないとかじゃなくてさ、そんな状況は現実世界じゃ発生しないのよ。
「たまに」とか「ひどいとき」とかいうレベルじゃない。
何を言っても今後 C++ が良い言語に生まれ変わる訳でもないし、
世間の評価が上がる訳でもないから仕方が無いね。どうしても
必要なら使うけど、そうでなければごめん被りたい。
>>595 594は別世界の人間なんだから、お前はそっとしてやれ。
C++のネイチブコンパイル出来たら西京
MIN(x,y)とかMAX(x,y)を標準のCプリプロで副作用無しで書けるか?
C++擁護派はCのスーパーセットって何度も主張してるけどさ
だったら
>>591の問題は全てC++でも起こることになるよ
当然それにプラスしてC++固有の問題も起こるから、Cより問題点が多いってことになっちゃうよ
>>599 C99にはinlineがある
現在でも(C99対応してなくても)主要なコンパイラはほぼ対応済み
>>600 スーパーセットをマイナス方向にしか考えないのか?
C++はマクロの問題を解決できる機能をいくつか追加している。
inline, template, namespace など。
templatewwwwwwwwwwwwwwwww
マクロの問題の100倍以上大問題な機能ですねwwwwww
東京から品川へ行くのに新幹線を使う様なもんだな
>>602 いや、むしろ逆でしょ
擁護派が都合の良い時だけスーパーセットを主張してるみたいだから
都合の悪い部分もちゃんと継承しろって言ってるだけ
大体さ
>>591が言うような
>ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
↑みたいな奴がC言語の問題点として挙がってるけどさ、
そいつはC++使ったって小文字1文字のマクロを定義するでしょw
むしろC++ならもっと素敵な大惨事になりそうだと思わない?
マクロといえば誰もが知ってるのがmin/max問題だろう
>>600に対して
>>602のレスって・・
C++擁護派は都合の悪い意見はわざと間違った解釈で話題を逸らそうとしてるように見える
それとも本当に理解出来ないほど頭が悪いのか?
>>596 だからお前にとって良くないだけで、お前が使わなきゃいいだけ。
Swingでぐだぐだなアプリでも作ってろって。
C++みたいな技術者としての基本スキルが扱えないワンランク下の技術者と
して生きていけばいいだろ。
他人の書いたコードはどうしようもないし、
605の「そいつはC++使ったって小文字1文字のマクロを定義するでしょw」も絶対に間違いない。
だけど、少なくとも自分の書く部分ではC++の機能でマクロを回避できば、
その分マクロの問題に遭遇する可能性は低くなるはず。
もちろん、使い込むとそっちの機能で問題に出食わす羽目になるが。
小文字1文字のマクロを定義する奴なんかにC++使わせたら
何気なく足し算する時も「もしかしてこのoperator+引き算してんじゃねえだろうな」って
いちいち怯えながら使わなきゃならなくなるじゃねえか
C++アンチは些細な問題を避けるためにどんだけ利便性捨てているんだよ。
マクロ云々はどうでもいいが
ABIの問題などは、本来低レベルの道具作りにはずのC++としてはちっとも
些細な問題じゃない
だからMSはCOMみたいな物を作ったが
COMは結局糞だったので.NETにとってかわりつつある
.NETの提供する相互運用性を横目に、C++は、自分に閉じたテンプレートの
世界だけで生きて行こうとしているわけだな
>>608 C++ への批判を "C++ を使えない" という話に都合良くすり替えるなよw
それに、"C++ は難しい" という前提で話すのもそろそろ止めようぜ
Perl と同じで汚いだけなんだから
一部の狂信者がアンチはC++理解出来ないことにしたがってるのが萎える
このスレを見る限りアンチはC++を理解した上で批判してる
擁護派のひとは的外れでないC++の批判や問題点はきちんと受け止めよう
それで利点欠点を天秤に載せてC++を使う使わないの判断は勝手にすればいい
お互い考え方が違うんだから、お互い論理的な説明をしても話がかみ合わないのは当然。
そもそも嫌いならだまって使わなきゃいいだけなのに、基地外C++アンチが粘着してる
ように見えるけど。
スレタイ読めよ
ここは不可避で理不尽な思いをした職業プログラマの愚痴履き場
自称ワカッテル趣味プログラマの反論は、その面から見るととても低レベルで糞の役にも立たない妄言しかない
ま、経験した事無いんだから想定できなかったとしても馬鹿とまでは言わないよ
ただ、その自己陶酔した妄言と違って「現実に起こっている事」なんだという事くらいは覚えておいて欲しい
>>615 あきらかに擁護派の方が非論理的なレスが多い、
アンチが化けてるのかってぐらい擁護派はおかしい。
何度も指摘されてるし、スレ読み直すと一目瞭然だよ。
lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
C++はCとの互換性とか、ゲームからデスクトップアプリから組み込みから科学技術
計算まで想定してる汎用言語だし、歴史も長いから情報量も膨大だし、自分に必要な
ものだけを上手に取捨選択できる経験値が求められるのは確かだし、そういう意味で
難易度が高いと思うよ。
自分に必要なものの判断なんて別に難しくないし、そんなこと非論理的な擁護派意外誰も論じてない。
難しいのは知りもしない他人が必要としたものの判断。
C++ではこれが壊滅的に終わってる。
なんか頭悪そう
とりあえず、頭悪い奴にC++を扱うのが無理だということだけは分かるw
>>620 ABIの問題とか色々まともな批判も出てるだろ
見たくないものには目をつぶってどうでもいい批判しかないと
片付けたがっているようにしか見えんよ
625 :
デフォルトの名無しさん:2008/10/06(月) 11:30:38
C++の代わりに何を使えばいいというのだろう。
初心者がやたらポインタ使いまくる症状になんか似てね?
今の時代、絵を描くのだって、いくらだって大きな紙は用意できるけど
だからって欲張って全部使おうとする事はないと思う・・・
ハサミというものを用意してちょっとずつ切って使えばいいんだよ!
人が作ったものを人が使いこなせないってことが、今リアルにC++で起こってる
Dに注目が集まったのはC++への不満の裏返しだな
まあDはDで別の理由でポシャったけどな
JavaもC++を否定して注目集めた
とりあえず、自分の意見は論理的って思い込みを捨てるんだ
ここまでで論理的な意見なんて一個も出てないからww
>>628 Javaはサーバーサイドアプリケーションの分野ではC++を追い落としたな
それだけだが
C#ぐらいの言語仕様&開発環境の成熟度で
Delphiのようにネイティブコンパイル&スタティックリンク可能な環境があれば
いいんだがな
632 :
デフォルトの名無しさん:2008/10/06(月) 12:53:12
>>619 本当に何度もそんなことが「指摘されてる」なら、それってつまり、
一方的で自分に都合のいい「指摘」を何度もするのが、このスレの否定派ってことだよね。
「俺よりアイツのほうが明らかに馬鹿」って言う、あまりに幼稚で痛々しい意見を、
擁護派より否定派のほうがたくさんしてるっていう証言だよね、これ。
自爆してない?
しかもそれに対して
>>620ではさらに
>lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
これもありえない
擁護派はこの手のすり替えとかごまかしが多いって言われてるわけだ
C++は言語屋やハッカーからは大抵嫌われている
という印象を持っているんだが、偏見かね
C++は仕方なく我慢して使う言語、だと思っている
言語屋は現実より理想を求めるので C++ が嫌いなのが多いと思う。禿も言語屋の意見は二の次にしている。
ハッカーはいろんなのがいるから分からない。
仕方なく我慢して使うような言語なら自然と消えていくだろう。
OS と違って言語は開発側が選択しやすいんだから。
ハッカーにとってみればメモリの実際の内容が気になるだけだから
いちいちコンパイラに文句言われてreinterpret_castとか書くのが面倒になるんじゃないかな。
ところで否定派は「バカが書いたライブラリや同僚のバカが書いたコードに
煩わされるから&その上、上からC++使えと強制されるから」
とかそういう理由で嫌ってる人が多いような気がするんだが。
C++を嘆くよりその会社を辞めることをお勧めしたい。
そもそもC/C++はプログラマを信用して、誤用よりも利便性を優先してるんだから
バカに書かせたらダメなんだと何回言わせr(ry
>>638 > 仕方なく我慢して使うような言語なら自然と消えていくだろう。
> OS と違って言語は開発側が選択しやすいんだから。
そうでもないだろ
現在の主流OSはLispシステムでもJava OSでもなく
Cをベースにしているのがほとんどだから、それらのOSでは
C系の言語は特権的な地位を占めることになる
Cとの互換性は、C++を広める上では一番の強みであり、
同時に言語の中身だけ考えれば最大のネックにもなっている
擁護派は
>>638みたいな意見を見てもおかしいと思えないの?そんな馬鹿なの?
C++を嘆くよりその会社を辞めることをお勧めしたい。(キリッ
> バカが書いたライブラリや同僚のバカが書いたコードに煩わされるから
実際C++は馬鹿避け仕様多いよな
もっとも、型付けだけ強くても、型推論してくれるわけでもねーし
JavaやC#ほどインテリセンス向きでもねーし
テンプレートを使えばコンパイルエラーはあっさりゲシュタルト崩壊するし
reinterpret_castとか長々とタイプさせたところで
相変わらずC++で自分の足を撃つのはこれ以上ないぐらい簡単なんだけどな
>>641 世界中の言語屋より禿一人が正しいと思ってるんだから仕方が無い
信者というのはそういうものだ
646 :
デフォルトの名無しさん:2008/10/06(月) 19:39:08
gccとテンプレートは分けて使うことにしたらいい。
またはgccを使わない。
あら不思議、C++がとっても素敵な言語に。
逆に言えば、新しい言語を作ったとしてどの言語で実装する?
>>638 逆に、今でもC++は消えていないということは、
仕方なく我慢して使うような言語ではないとも言える。
>>630>>642が挙げたように消えたところもあるし、今現在消えつつある分野もまた。
>>646 GCC以外も同じくらいだめだめだと思う。
>>647 Cじゃね?
VCとか6時代に比べりゃ格段にマシにはなってるんじゃね
Dinkumwareは相変わらずっぽいし
セキュアCRT絡みがなにげにウゼーけどな
C++ が消えていないのは、商用のコンパイラが整備されているとか、
ライブラリが沢山あるとか、ネイティブに落とせてそれなりの速度が
出るとか、機能をつまんで使うならそこそこ便利だとか、C と互換性が
ある程度考慮されているとか、まぁ色々理由があるよね。
C++ に消えてもらいたい理由もごまんとあるけど、代わりの言語を
提示するのは中々難しい。既に Java で置き換えられた分野もあるけど、
D とか ObjC とかはまだまだだよね。C + LL とかが最有力候補かな。
最近は C++ + LL とかもあるから安心出来ない。
うちの会社はみんなうれしそうに C++ 使っているぞ。
顧客から無理やり C 使わせられたときはみんなブーブー文句言っているぞ。
「擁護派」でレス抽出すると粘着がいることがよく分かる。
C++に醜い部分があるのは確かだが、
後発の方がきれいなのは当たり前だろう。
Dでマングリングが統一されているのはイイと思うけど、
マイナーすぎて実用する気にはならないね。
マングリングとか小学校で教えられないだろ
用語選べよな…
655 :
デフォルトの名無しさん:2008/10/06(月) 21:20:42
名前がエロい
そうなんだよなあ。C++ は醜い。出来れば使いたくないもんだ。
演算子のオーバーロードなんて無い方がスッキリする。
VC8SP1はDinkumwareが気に入らないんだが、かと言ってtr1を標準装備
したので今更STLportに戻る気も起きないし・・
VC9の話かな?
Dinkumwareは糞だと分かっててももういいやって感じだな
boost他とのからみもあるし
_SECURE_SCLってみんな切ってるのかね?
>>656 いや、演算子の多重定義は要る。C++のは改良の余地がありまくりだが。
>>658 あ、ごめんなさい
VC9SP1でした。
演算子のオーバーロード嫌がるのってJavaの人くらいかと思ってるんだが違うのかな
オーバーロード可能な言語どころか追加定義できる言語もあるわけで
あとテンプレート悪玉論唱えてる人は簡単なアプリでもいちいち自前で各型向けのlistとか作ってるの?
どうしてる?
>>661後
そういうことを主張する人は、そもそも動的型付けか何かで
テンプレートがなくても問題ない言語を使っているんだろう。
たんなる総称型なら持っている言語は多いとは思うが
C++のテンプレートとは別モンじゃないか?
C#やJavaのGenericsも違うしな
665 :
デフォルトの名無しさん:2008/10/06(月) 23:06:40
コンセプトをインターフェースにすればいいだけだろ。
テンプレートが悪いって言ってる人間はテンプレート全く使ってないと思ってるの?
coutとかstringとか
ありふれた道具の裏にことごとく潜んでるサブプライムローンみたいな存在ですから
>>659 Lisp とか Smalltalk みたいに、関数と演算子の区別が無い言語なら何やっても良いよ。
C++ みたいな言語に入れるのは間違いの元だと思われ。
STL, boost, 自分で作ったテンプレートも特に問題なく便利に使えてるんだから
テンプレートに問題があってもかまわない。演算子も。
&&と||のオーバーロード許可してるのは明らかな設計ミスだろ
遅延評価持ってないくせに
そういう人間とチームで開発すると苦労しそうだから嫌というか不安。
C++ だと最初にルールを決めても破綻しそうだな。
ぶっちゃけるとテンプレートの問題より
>>669みたいな奴が開発に関わる事の方が問題がある
C++は問題があるから使わないってやつはどれほどチーム開発で試してきたんだよ。
C,C++は仕事でそれぞれ20,15年ぐらい使ってきが、ここ5年ぐらいC++特有の問題は
たいして起きていないぞ。けして優秀な人間ばかり揃えているわけではない。
新卒でいきなりC++使わせているけどそれほどひどい使い方はしていないよ。
むしろCで作らせたほうが間違いが多いぞ。
テンプレートやらオーバーロードやらを自由に使わせてそれなら
相当優秀な人間が揃ってるか、問題を認識できないボンクラばかりかのどっちかだな
>>670 Lispで言ったらspecial formとprocedureをごっちゃにしてるようなもんだよな
かなり笑える話だ
678 :
デフォルトの名無しさん:2008/10/07(火) 02:17:43
LispはC++の代わりにならないからな。
>>678 意味分かんないで反応してるだろ
関数呼び出しが引数を全部先に評価しちまう正格評価のくせに
&&や||を関数にしちまうなんてのは、
情報系の学部学生でもやらないレベルの誤りだろ
なんでC++は難しいって事になって
C++を悪く言う奴はC++を使ってない(使えない)って事になってるんだ?
いや、そこまで強烈に決め付けできる幸せな脳みそだからC++使ってて幸せなのか^^;
C++は完璧でこの世で最も優れた言語なんだ!!!!
C++に欠点なんか無い!!
だからC++を悪く言う奴はC++を理解出来ないに違いない!!!!
って考えてるからだよ^^
あんまりレベルが違い過ぎると、合わせるのに疲れ果ててしまうのがC++の厄介なところ。
683 :
デフォルトの名無しさん:2008/10/07(火) 04:32:49
>>679 何を問題にしてるのかさっぱり分からないのは確かだけどな。
operator&&を組み込みの&&演算子と同じ挙動にすることは絶対に出来ないんだぞ
ひどい話だろ
前10レス読んだだけの脊髄反射レスだけど
万全でなければ使えないようにするというのも、またどうかとも思うけどね
論理演算子でトラブッた事はない訳で
コードする側が保障する必要のあるものは、便利にする過程でどうやっても登場するよ。
これらはテストツールの充実で解決して欲しいね。
あ゛ーC++にテストツールとか無茶もいい所か・・・
スレタイ読まずでした
>>684 More Effective C++に書いてあるね
中途半端な使用を放置してる事は問題なのに、どうでもいいとか問題無いとか…
問題を見てない振りしてるくせに、使ってない奴はレベルが低いとか…
使用→仕様、ね。変換ミスした。
>>689 で、問題になったことは?
多重継承のがずっと問題あるのに全く話題にあがらないのが不思議なんだけど
本質を突かない話なんか本当にどうでもいい
そんなの本質じゃないごっこはどうでもいいけど、
問題を上げればきりが無いのが C++ だな。
>>692 素直にこれ豆知識なって書いておけばよかったのに
顔真っ赤かよww
問題があるから使わないのに、俺は問題と認識してないからと
突っ走る奴が居るのが問題なんだよな…
>>693 どう見ても君の顔が真っ赤だし、なんか歯軋りとかも聞こえますよ。
打鍵の音もなんか凄そうですw
突っ走るって何のこと?
誰も使ってない(=使うことではない)のだから…うん?
抽象的な表現に逃げられると途端に意味がわからん
俺はこんな仕様知ってるんだぜ大会ではないんだぜだぜ
>>695 怒った時の君の顔が浮かんだ
普通の人は頭に血がのぼっても歯ぎしりなんかしない
>>695はもうキーボードの前にいるのか
仕事しろw
なんか校則がギッチギチのDQN学校の生徒が、
校則ゆるゆるの進学校に対して、お前のところはルールがゆるすぎるから学校の治安が悪くなるって喚いてるイメージw
>>683 int i=0;
if (i++ || i++) {
printf("%d", i);
}
落とし穴だらけでもはや正格評価で&&や||を関数化することの問題すら
C++信者には見えなくなってるのか
以下のようなif文がある
if (expr) statement
exprを評価して真の場合にだけstatementを評価する
常識だな
これを
if(expr, statement)
という関数にすることを考える
C++は多くの言語と同様正格評価だから、if関数を評価する前に
expr, statementの両方を評価することになるが、
言うまでも無くこの時点で元のif文とは意味が異なっていることになる
&&や||も全く同じだ
これらはショートサーキットだから、本来右オペランドは条件付きでしか
評価されない
C/C++のコーディングではその性質が多用されるが、関数化されていれば
常に評価されてしまう
禿は、無用で、使えば問題を引き起こすと分かっているこの機能を
平然と取り入れ、仕方が無いからC++ユーザはそれを避けることで
問題を回避する
些細に見えるかもしれないが、このようなものが積もりに積もって、
結果としてC++は糞の山になっているんだぞ
誰も見えてなくないじゃん。 使わないからどーでもいい、って言ってる。
んなこと言い出したらCだって過去の負の遺産が大量に残っているが。
>>702 「お前は」どうでもいいかもしれないが「言語としては」どうでもよくないんだよ
実装者にはその無用なものを実装するコストがかかり
教育者にはその無用なものを使ってはいけないと教えるコストがかかり
学習者にはその無用なものを使わないように学ぶコストがかかり
ユーザにはどこかの馬鹿が罠にはまったかどうかをチェックするコストがかかる
> Cだって過去の負の遺産が大量に残っているが
墓穴だな
C++はCとの互換性のために、その負の遺産を全て引き継いだ上で
比較にもならないほど多くの落とし穴を自分で掘っているのだから
まぁ、批判するにも代替手段を提示して欲しいわなw
畢竟どの言語もみんなしょうがなく使ってるわけだしw
細かいところまで見たらウンコな仕様があるのはどの言語もだいたい一緒だと思うぞ
Javaだってウンコだらけだし
問題はC++のうんこは臭すぎることなんだよね
形は整ってるかもしれないけど飛び散りすぎてるし
そもそもCが糞なんだから、C++が糞なのは自明。
>>705 なんで代替手段を提示する必要があるわけ?
言語の批判は批判でいいじゃん
それと他の言語が糞だからってのも関係が無い
C++が糞言語でないと気がすまないらしいな。
711 :
デフォルトの名無しさん:2008/10/07(火) 15:59:52
>>709 結局のところ、みんなC++は糞だと思いつつも、ほかの言語はさらに糞なので
一番まともで最高なC++を使ってるわけだよ。
で、もっといい言語があるなら乗り換えたい。
しかし、そんなものはないので仕方なくC++を使ってるわけさ。
そういう状況下で、「C++は糞」とか主張しても「で、もっといい言語あるの?」
って聞き返されるのは当然でしょ。
関数型言語にはものすごい期待したんだけど、使ってよかったと思える状況って
CGIとか程度じゃない?
CUI全盛の時代だったらいっぱい使い道あったんだろうけどね。
結局、糞だ糞だと思いつつもC++を使うしかないわけ。
だって今ある中では最高の言語だからね。
で、もっといい言語あるの?
ひどい釣りだな
>「で、もっといい言語あるの?」
>って聞き返されるのは当然でしょ。
用途もなにも前提なしで「いい言語あるの?」と聞き返すのは
そりゃ莫迦にとっては当然かも知らんが。
714 :
デフォルトの名無しさん:2008/10/07(火) 16:07:38
>>713 だってC++は用途を問わず最高の言語だからね。
CGIを書くには最適ですっていう言語があったとしても代替にはならないでしょ。
そう思わない?
715 :
デフォルトの名無しさん:2008/10/07(火) 16:12:56
換言すれば、C++で出来ることは全てカバーしていなければ代替にならない。
で、もっといい言語あるの?
釣りもいいけどageないで欲しいな
>>694 突っ走るって、現実に&&や||を定義するやついるのか?Boost.Lambdaくらいしか知らないが。
.や.*と同じようにこれも禁止しなかったのは間違いだと俺も思うが。
>>705 C#のture/false演算子はC++の&& ||よりましだと思う。
禁止するよりも力尽くでも本物と同じ動きに出来るようにするべきだった。
ageている奴は発言が面白すぎるので愉快犯と見た
&&はテンプレートの中で型が確定できない状況で使ったらセマンティクスが
全く不明になってしまうね
それはショートサーキット評価されるのだろうか、されないのだろうか?
>>701 言いたいことは判るけどさ、それで問題が起こるようなケースってのは
コピーやキャストされてしまうような時だけであって、そうなるかもしれないってのが頭にあるなら
できる限り避けましょうと、参照にしたりすればよく、逆に高速化が必要ならオーバーロードしたりテンプレート化したりして個別対応すればいい訳。
実用上の障害は何一つないのに問題視するのは、それ自体問題だ。
>>719 テンプレートはコンパイル時に型が特定されるので、問題はないのでは?
動的なテンプレートを実装したりすると問題が起こると思うけどC++はそうではないし。
>>721 勿論テンプレートを実体化するときには確定するな
が、テンプレートは静的ダックタイピングの手段だから、
関数テンプレートを記述する際には型に関する仮定はおけんだろ?
で、&&はどうすりゃいいんだろうな
&&が腐ってるんなら、仕方なくVBみたいにifのネストを使うか?
C++最大の問題はプリプロセッサと旧態依然のコンパイル・リンクだろうな、あれの存在のお陰で
自動テストは作れない作ってもショボイ、インテリセンスも作れない作ってもバカの極み
自動リファクタリングに至ってはもはや絶望的、しかもコンパイルもリンクも超低速という点。
>>722 それが問題になるような事態に直面した事はないが、仮に直面してどうしても困るなら
type_traits でも使えばよいのではと俺なんかは思ってしまいます。
>>724 議論ずれてきてるな
こんな風にすればカバーできるよ!ってのどんどん突き進めたのが
TMPなりboostなりだろ
いやそれはあんたはそれでいいのかもしれねーけどよ
大したことやってるわけでもねーのに、あの糞ったれなバッドノウハウ集
全部押し付けんのか?プログラマに
&&の問題なんて、禿の設計誤りさえなければそもそもそんなことを
考える必要すらないんだぜ
>>725 それ以前に困った事態ってのはどんな事態なんだよ、俺はそっちの方が気になる。
>>726 俺は困ってねえよ
ユーザ定義&&なんてつかわねえからな
自分では
が、テンプレート関数の中の&&は、一種の時限爆弾のようなもんだろ
誰かがユーザ定義&&を用いたら、それはコンパイルエラーにはならず
不可解な実行時の問題を引き起こす、かもしれない
そして、それはすぐには気づかれない、かもしれないわけだ
それが心配でたまらないなら、ある種病気だよ
実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなw
流石にそれはないよw
ただ、俺はそういう問題を知るためにまたしても*無駄な*コストを払わされたがな
みんな麻痺してんじゃねえのか?
C++の要求するあまりの学習コストの高さとバッドノウハウの多さに
確かにこんなのは氷山の一角ですらねえよ
もともとが糞の山過ぎてな
危険だと分かっているものであれば自然、用心深く取り扱われるので、思ったほど事故は起こらないもの。
面倒臭いだけだから何とかしろとは思うが、それらの問題点に突っ込み入れても問題は出てこないだろうね。
C++逝ってよし派ではあるんですが、重箱の隅をつつくような問題点指摘には賛成できない。
お金もらえるならなんでも書くよ
>>727 まあ、もしそういうことが起こったら、&&を定義したユーザの方が悪いだろということにされるな。
やっぱりなんでこんなの定義できるようにしたんだって話ではあるが。
ヘッダファイルに
static int int_data;
#define x int_data
などと比べれば&&など些細な問題さ
&&と||は避けようと思えば避けられた問題だもん
演算子はとにかく全部オーバーロードできるというわかりやすい規則を優先して
その中には危険な演算子もありますよという話ならまだわかる
でもそうじゃないじゃん
例えば&&と同じく副作用完了点を持つ?:はオーバーロードできない
::は出来ないし.も.*も出来ない、sizeofもtypeidもthrowも出来ない
どれも問題あるからわざと出来ないようにしてるんだ
どうしてこのリストの中に&&と||を加えることが出来なかったんだ?
つーか?:を出来なくした時に気付けよ禿
えんざんしちげーだろ
そんなに気になるなら、&&セーフとか&&FREEのシールでも貼っとけ。
>>729 >実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなw
EffectiveC++等々の存在は十分爆弾発生率の高さを証明してると思うが・・
739 :
デフォルトの名無しさん:2008/10/07(火) 21:00:38
EffectiveJavaもあって、初級者用じゃないけどJavaプログラマの中ではかなりの必読の部類に入るよ。
組み込み系の経験ないんですが、C++使用の場合って
コーディング規約とかで縛ったりするものなんでしょうか?
もう一つ問題がある演算子があって、それはカンマ演算子
&&や||などと同じく、やはり副作用完了点として働く演算子の一つだ
普通は逐次実行されるので、左辺も右辺もどのみち評価されるから気にすることは少ないが
左辺が例外投げるような場合はやはり同じような問題が起こる
さて、なぜoperator,は定義できてしまうのか?偉大なるBjarne大先生の答えはこうだ
>operator,をオーバーロードできるようにしたのは、そうしてはいけない理由がなかったからだ。
(C++信者の聖典、D&Eより引用)
これはひどいwwwwwwwww
742 :
デフォルトの名無しさん:2008/10/07(火) 21:19:58
ある分野では operator , が実用上離せない
>>741 なんつうかおじいちゃんはもっといたわって隠居させるべきだと
思ってしまうな
いけなかったというより、::や.のような制約がなかったからと言うべきのような……。
>>727 核戦争の心配してるほうがお似合い
そっちのほうが被害は甚大だし現実にあり得る
結局、使いこなせない人が「この要素が悪いんだボクが悪いんじゃないやい」
って言い訳しつつ、使いこなせる人をデタラメに煽って射精するスレってことでおk?
operator&&なんて使いこなしちゃいけない機能です
問題点を指摘されて、それがありえる・ありえないって話にすり替えるのは違うんじゃないか
問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい
だけどココで問題を指摘されてるのに、自分にとってありえないから問題じゃないってのはお話にならないよ
>>747 また同じ煽りパターンか
ぼくちんのC++に文句いうやつらは全員C++理解できないに違いない!
C++も禿もぼくちんも天才!欠点なんかあるわけない!
これで満足?
何でもルールのせいにするのはゆとりだろう。
C++ しか知らなければ、C++ を過大評価したくもなるんじゃないかな。
2ch で主張してる分には見掛け上はノーリスクだし。
747みたいに突然流れ無視して
「アンチはC++使いこなせないんだ!」って暴れ出す厨が定期的に出てくるよな
正直、どっちサイドからみても邪魔な基地外なんだがw
テンプレートメタプログラミング禁止とか多重継承禁止とか
実際に実行出来てる例はあるのかな。ベターCとして使う事を
考えるなら当たり前に出来て欲しいんだけど、どうも揉めそうだ。
他にも例外禁止とか名前空間禁止とか演算子のオーバーロード
禁止とか、Boost禁止とか、RTTI禁止とか。
>>754 禁止する理由を納得のいくように説明すれば揉めないんじゃない。
>>749 &&なんてC++使っているほうからしたら、誰も使わないだろjkって話なんだが、
外から見たら、ようするにバッドノウハウなんだよな。
そこに温度差というか埋まらない溝を感じた。
>>754 うちは揉めないけど、やっぱりみんな言語仕様通しの関連が分かってないね
まあ新人はいまどきCなんて嫌だろうし、
ちゃんと理解して使うならC++でもいいよーって許可するんだけどね
ミスらなかった子はひとりもいない、ベテランでもミスる
もちろん仕事だからフォローはするよ
誰も使わないし誰も使っちゃいけない機能が何であるんだよという素朴な疑問があるだけです
まあ設計者が大した考えもなしに使えるようにしちゃってるだけだけど
>>741 カンマの左辺で例外が起きたときの問題ってどんなの?
>>760 ただの関数呼び出しでは評価順序は決まっていないから、
a, bでoperator ,関数が呼び出されるときには、
b, aの順で評価されても構わないということになるはず。
>>749 なら誰にとってありえるの?
使いこなせないくせに演算子オーバーロード機能使って、しかも&&演算子を…
っていう人間を仮定してみるとあちこち矛盾が生じるのだけれど
使いこなせるのに…もまた然り
>>762 え?釣りなの?本当に理解できてないの?
いいかい
問題がある・ないってのは客観なんだ
問題がありうる・ありえないってのは主観なんだ
客観に対して主観で反論したら議論にならないだろう?
これはC++とか関係ない当たり前のことだよ
>>762 釣りじゃないなら一晩おいて、もう一度よく読み返してみな?
大丈夫、C++の問題点よりずっとずっと簡単な話だよ
Javaだと回避不能なウンコ仕様が多くて困るけど
(例えばしょうもないことで例外が飛んでくるとかthrowsとか)
C++のウンコは知ってれば回避可能なウンコが多い気がするな
まあ確かにC++にはウンコ満載な気はするけど
知ってしまえばどうということはないので
慣れればあまりフラストレーションが溜まらない、というのが俺の実感
&& || , のオーバーロードの話だって
More Effective C++ に「やるな」と書いてあって、
簡単に納得できるレベルの話だしねえ
いやいや、中にはそもそもできないようにしろよって主張も上の方にあっただろ。
俺もそう書いた1人だよ。
769 :
デフォルトの名無しさん:2008/10/08(水) 04:35:23
CGIしか作れないようにしたらC++の意味ないよな。
ウケルw
包丁は販売禁止ですね
わかります
いや、別に包丁は売ってもいいし、包丁で人が切れてもいいけど、
包丁を使ったと思ったら菜箸だった(ポルナレフAAry
となるのがC++の凄いところ
>>770 両刃の包丁を買ってきたと思ったら、背側にも刃がある両刃でした
>>766 > Javaだと回避不能なウンコ仕様が多くて困るけど
> (例えばしょうもないことで例外が飛んでくるとかthrowsとか)
これはウケた
以下のコードはf()は何もthrowしない、と例外仕様で言っているが、
f() throw() { throw 1; }
これをあんたのコンパイラがどう扱うか確認してみればいい
C++では文字列も整数もクラスも
ポインタも参照も、何でもthrowできる
例えばMFCとVC++のCOMサポート、C++標準ライブラリのようなものは
当然のように全く異なる流儀で例外を扱っている
それらを全て捕まえたければ catch (...) を使うしかないが、
これでは何が飛んできたか分からないから、事実上何の役にも立たない
勿論スタックトレースの取得などできるわけもない
C++はJavaの例外を馬鹿にできる立場には一切無いよ
>>769 operator &&や||をなくしただけで
CGIしか作れなくなるのか
すげえ言語だな
|| のオーバーロードは昔からあるんだから現実にこの世の中で問題が起きたことを
確認してから批判してくれ。
どうせ || のオーバーロードができなければできないで批判されるだろうから。
まあほんとは仕事なんててきとーにJavaみたいな言語でやってるのが楽なんだがなあ
>>773 例外仕様の話は当然知ってるよ
何が起こるかもよーく知ってるし、
色んな本に「使うな」と書いてあることもだ
使わなければ簡単に問題は回避できるだろ?
>それらを全て捕まえたければ catch (...) を使うしかないが、
それぞれどんな例外が飛んでくるかわかるんだから
個別にcatchすればいい
Java で catch (Exception e) がまずいのと同様に
catch (...) は原則として使っちゃだめ
両方ともまったく同じ問題を抱えている
スタックトレースについては仕方ないんじゃない?
そもそもC++の規格は実行スタックの存在すら仮定してないし
余計なデバッグ情報をバイナリに入れないと取得不能だしね
>>777 ん?Javaの例外がウンコでC++のはそうじゃないんだろ?
一貫性がなく事実上使いものにならない例外仕様
共通のインタフェースの欠如
スタックトレースの欠如
これだけでもJavaの例外より劣ることは明白だが
何をもってC++がウンコでないと言っているんだ?
> Java で catch (Exception e) がまずいのと同様に
> catch (...) は原則として使っちゃだめ
上と下ではまったく意味が違うんだが。
たしかに「製品クオリティの」コードでは上は避けるべきだが
下とは違い、最低限Exceptionクラスを通して得られる情報だけは
得られる。スタックトレースやエラーメッセージなどがな。
下はゼロだ。完全に。
はっきり言って、こんなものを捕まえるぐらいならクラッシュしてくれたほうが
マシだよ。コアダンプをバックトレースしてみればどこで落ちたかわかるからな。
>>778 >>766 をよく読んでくれ
C++の例外がウンコじゃないなんて書いてないぞ
むしろC++にはウンコがいっぱいと書いてある
C++はウンコだらけで臭くて臭くてしょうがないけど、踏まなければ関係ないねって事だよな
そんじゃお前は家の前に毎日ウンコしていく犬が居ても関係無いのかって話だわ
批判してる奴は別にウンコ踏んで怒ってるんじゃなくて
クセエよ片付けろよ、てか初めからウンコしてんじゃねえよって文句言ってるんだよ
横レスだが
C++がウンコ満載なのは納得した
あんたはウンコ全部よけれるんだぜーて言うけどさ
普通はそんなウンコ満載言語には近づきたくないよw
特にこれからプログラムを学ぶ人間ならな
横から悪いけど、Javaのthrowsって何がウンコなの?それって一般的な認識?
>>783 どうせthrowsとかいつも書かされるのが嫌だ、とかいう下らない理由だろう
Javaは例外をインタフェースの一部とみなしているから
はっきり宣言させているのだし、C++よりずっと首尾一貫しているわけだが
C++では関数might_throw()が例外を投げるかどうかを確認するには、
それについているドキュメントを信用するか、それから呼ばれる
コールツリーを全ておっかけるしかない
>>783 比較的どうでもいいことまで例外投げてきやがってウゼエって個人的感想じゃないの?
必ずキャッチしなければならないから回避不可って
○○は糞とか、○○はウンコとか言う奴ってさ
大抵の場合、一つの言語しか使えないような低脳野郎だよね
>>784,785
あぁ、なるほど。スレの流れから考えて、C++に対するウンコは客観的な意味っぽかったから
Javaに対するウンコも同様だろう、と思ったら違ってたのか
要は、流れとは全く関係なく、
Javaは強制される作法が多くて疲れるが、C++はそれがなくていい、って言いたかっただけか。
ここ数百レスのすれ違いまとめ
批判側
C++ウンコだらけで臭すぎ、マジ臭い
擁護側
ウンコを踏む奴はただの馬鹿www
大体そんな道の端にあるウンコ誰が踏むんだよwww
だからC++には全く問題がないwww
ウンコを避けれる俺カコイイwww
批判側
いや、それじゃ臭い事実は変わらないから・・・
大暴落のおかげで腐りかけてたN225のプットワラントが
20倍近くになってうまうまなんだが。
信者:C++の何が問題なのか言ってみろ!
アンチ:&&や||をオーバーロード出来る事に問題がある
信者:そんなの普通は使わない、だから問題無い!
アンチ:新人が絶対それ使わないってあんたが保障してくれるの?
信者:北朝鮮の何が問題なのか言ってみろ!
アンチ:核ミサイルを持ってることに問題がある
信者:そんなの普通は使わない、だから問題無い!
アンチ:正日が絶対それ使わないってあんたが保障してくれるの?
安全かどうかはこの際どうでもいいんだけどね
不愉快で醜いウンコには俺の前から消えて欲しいだけで
C++の例外がヤバイってのは分かるとしても、|| && の批判はバカじゃねえのと思わずにはいられない。
世界恐慌〜WW1
アメリカ->ニューディール政策
ロシア->共産化
その他→植民地補充合戦
もうお分かりですね?
核なら怖いが、破裂しないバクチクに安全保障などしなくて良い
C++ のヤヴァイ所は全部ストラウストラップのチェックを通って世に出されたんだよね?
D&Eを見る限り、興味ない所はろくにチェックしてないようだがな
741のように
そもそも罠で作ったってどこかで言ってたよ
本当にわかってないのかな?
&&のオーバーロードなんてのはあくまでも例であって
問題点を認められない狭量さを揶揄されてるんだよ
「自分は平気だからそれは問題ではない!」
こんな主張がアリなら、どんな糞言語のどんな糞仕様でもなんでもアリになってしまう
坊主憎けりゃ袈裟まで憎いとw
つーかそこは設計者の資質自体が疑われるところだろ
実害の有無以前の問題として、あまりにアホすぎてな
情報系の学生の演習問題レベルのミスだ
禿はラリっていたとしか思えない
スティールやヴィルトみたいなプロの言語設計者が作った言語じゃないからね。
悪態付いても祈っても、最早どうしようもないし、取り返しも付かない。
perlなんてミスの権化だな、使える言語だが。完璧主義など糞くらった方が良い
C++否定派の俺からしても、こういう愚かな批難は同意しかねますね。
いやPerlなんて普通に使わないが。
もっとマシな「Perlのようなもの」があふれているからな。
>>791 ミサイルは取り返しがつかないが、ソフトウェアなら取り返しがつく。
#頼むから新人は取り返しのつくようなところに使ってくれ。
Perl と C++ は似てるよね。汚いから嫌われている。
また話のすり替えかな
今、話のすり替えの話にすり替えた人を見た
C#がネイティブ吐けたら終了
>>810 それ、あんまり意味無いと思うよ
今だってngenでネイティブコンパイルできるが
C++の代用にはならない
MFCってやつに取って代わることは出来るかもな
>>799 なら、どういう書けば問題を認めるってことになる?
実際問題、&&は反論しようのないことだ。
どうせ禿のことだ、今更&&禁止とかやるわけがない。
C++を使う側としては、使わない、つまり運用で回避するしかないという現状を述べただけ。
たしかに顔真っ赤にしているようにしか見えないのがほとんどだったが。
反論しようの無いことだと思ってるんなら
別に黙ってればいいだけじゃね?
だってさ、誰も使っていない(と思っている)ことでそんなに言われるとさ、つい。
逆に、例外では沈黙に傾いていたと思うよ。
使っていて実感しているから、こっちこそ何も言えない。
仕様はともかく、危険なのはコンパイラでデフォルト動作で禁止すればいいだけの気はするがw
operator&&くらいなら簡単に警告出せるだろうけど、危ない機能はまだまだあるからな
継承ハイジャックとか
>>813 言語に問題があることを認めた上で、「黙って」運用で回避する
たったそれだけのことじゃないかな
例えば
>>749はアンチだが最初からこう言っている
>問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい
それなりにC++のノウハウが高い会社にいくとC++の例外は上手に使ってるよ。
ゲーム関係とか。罠を避けつつ、うまく例外クラスライブラリとかスタックトレースとか
組み上げてる。
そういうノウハウをその辺の入門書読んだだけじゃ上手に学べないという罠が
あるけど。
いや何と言っても #define private public が一番危ないw
RTTI はともかく、ゲームや組み込みでは、まだ当面、例外はいらんだろう。
ゲームといってもPCとコンシューマじゃまるで状況が違うよ
環境によって例外はそもそも使用禁止だったりするし
合理的な会社は当然マルチプラットフォーム前提で作るから例外は使わないね
Album Title : 恋、はじめました!(OP)/LoveLoveLoveのせいなのよ!(ED)
PS3とXboxとPCのクロスのUnrealエンジンは例外使ってるけどね
同じゲームでも、もともとPC、というかWindowsメインだと例外も使ってる(こともある)
でもいまコンシューマ業界はDSとWiiが主流だからねえ……。
コンシューマ業界全体からみたら例外を使うのはレアケースになっちゃう
要するに
D言語がVisualStudioで使えれば全ては解決する
VSで使えるのがC++しか無いから使ってるだけだろ。
評価順序や引数展開でごちゃごちゃするのがイヤならAlgol系言語は全部ダメだな。
Lisp最強
Lisp好きもbindやlambdaがC++0xで入るからちっとは楽しめるようになるぞ。
実用的アプリやフリーソフトを泥臭いWin32と美しい関数型プログラミングを組み
合わせて設計できるようになるのは楽しそうだ。
>>826 Dて。どこをどう「要するに」なんだよw
830 :
デフォルトの名無しさん:2008/10/09(木) 11:08:02
>>828 そんなのカオスになるだけだろ。
右結合、左結合、優先順位、左の評価次第で右を評価するかどうか決まる、などの演算子の一目見ただけではわからないルールがさらにオーバーロードされると振る舞いが変わる、などが混乱の元だというのだから、
構文解釈が一目でわからないAlgol系は全部ダメだと言ってるんだよ
>>828 あんな汚い物でも lambda があれば良いというのは非常に C++ 的な発想ですね。
その点 Java のクロージャは分かってるなあと思うよ。シンプルで奇麗に書ける。
ゴスリングは良いバランス感覚を持ってるね。
Lambdaが入ったらC++を本格的に使おうと思う
>>832 lambdaなんて他の言語にフツーに搭載されてる仕様だろ?
今現在既に仕方なくC++を使わざるを得ない・使っている人が、
こんなものでもないよりはマシ、と思うかどうか、という次元の話じゃないの
lambda入ったから使ってみっかってのは正直意味不明な動機だ
いやフリーソフトとかを作れる言語で関数型プログラミングができるのは
魅力的だなと思ったので。。
関数型プログラミングは関数型言語でやるのが一番快適。
いや今ドトネトやってるけど実行環境とかうるさいからやっぱC++にしようと思ってる。
Haskellを勉強して関数型はおもしろいと思ったけど実アプリ開発にはやっぱ難しいと思う。
概念をC++のLambdaで生かせればいいかなと思ってる。
Cは低級。
故に他の言語と混ぜることも困難ではない。
しかし、C++で拡張された部分はどーしようもない。
お前がどう思おうと世の中ではふつーに使われてるからwww
>>819 C++の例外はやめた方がいい、本物の罠だから
例外はガベージコレクタを持たせないと問題が連発してしまう。
特に operater new との組み合わせは、ひどい有様になるので・・・
&& || とは訳が違う、boostあたりでも自在に使えるC++をきわめている人間でも苦しい問題が数多くある。
ゲームの場合 operator new をオーバーロードする事は多いと思う、だからより用心すべき。
>839
kwsk
842 :
デフォルトの名無しさん:2008/10/09(木) 18:10:37
そんなどうでもいいような重箱の隅つつく話よりも、C++の++のほうが問題
大きいんじゃないか?
なんて呼べばいいのかわからんだろ。
ぷ〜らぷら
ようするに
operator && || が本物と同じ動きにすればよかっただけだろ?
C++はC言語に比べてエラーを無視するプログラマが増えた、と思う
意味わかんねぇ
エラーってコンパイルエラーか?
どうやって無視するんだそれ
戻り値無視だろjk
exceptionとerrorの違いがわからないプログラマが増えた、と思う
律儀にstd::bad_allocなんて拾ってられませんよねー
>>849 本物の && ||がしてる方法をそのまま使えばいいんだが
できるわけねーなら本物もできるわけねー
852 :
デフォルトの名無しさん:2008/10/09(木) 22:21:09
>>850 拾えばいいじゃない。
スマートポインタを使わないとメモリリークするからガベコレないと例外使えないと逝ってるんじゃねーの。
俺はそれよりも、try中でスコープ切られてるから、オブジェクトを作ってから死ぬまでtry中に書かねばいかんのがうざいね。
853 :
デフォルトの名無しさん:2008/10/09(木) 22:22:42
>>851 できるわけねーだろ。
オーバーロードするのは&& ||「関数」なんだからな。
メモリが足りないなんていう非常事態で
例外みたいな砲丸を悠長に投げられるほどコンピュータが健康だなんて状況はちょっと考えられない
拾おうが拾うまいがクラッシュするんだから別によくね
main()
{
try
{
//uiui
}
catch(...){}
}
856 :
デフォルトの名無しさん:2008/10/09(木) 22:24:44
C++がlazyとか持ってれば良かったんだけどねー
いらん機能はいっぱいあるくせにこういう肝心な機能がないのがC++
スマポかガベコレないと、例外は使う気起きないわなぁ
>>856 良いシンタクスの考えがあるなら是非標準化委員会に提案して下さい
>>851 > 本物の && ||がしてる方法をそのまま
これはない
C++には実行時に式を評価する手段が無いのだから
やるなら、右オペランドを、bool値を返す関数にくるんでoperator &&に渡す
operator &&の中で右オペランドを評価したい場合はその関数を呼ぶ
そういう形になるな
が、そこまでする必要は無いだろ
.演算子のように、単に&&や||もユーザ定義できないようにすればよかっただけ
bool operator &&(const Hoge &lhs, const Hoge &(*rhs)())
{
return lhs & rhs();
}
解決しました^^
862 :
デフォルトの名無しさん:2008/10/09(木) 22:35:31
<<で文字書いたりするのはどう思う?
>>861 そうそう
つか、「bool値を返す関数」じゃなかったな、スマソ
デフォで遅延評価の機能を持たない言語での一般的なやり口だな
lambda式でくるんでやるのは
vectorなどSTLコンテナにポインタ食わせても、死ぬとき自動で解放してくれないからな。
そのくせauto_ptrはコンテナに食わせられないし。
かといって、コンテナから派生できないから自分でデストラクタ書くわけにもいかんし、
まあ、いろんな機能を入れた割には標準の範囲内では上手く動かんのよね。
>>832 当たり前だけど Lambda が入っただけでは関数型言語にはならないでしょ。
関数型言語が便利なのは、言語仕様や組み込みの関数やライブラリが
宣言的にプログラムを書く事を前提として作られているからであって、
Lambda があれば良いという物ではない。関数が引き数に関数を受けて
関数を戻り値として返す事が自然に出来て、副作用は奇麗に分離出来て、
末尾再帰をジャンプに置き換えてくれるから再帰的な定義も自然に書けて、
みたいなね。
関数と変数をまとめてクラスという名前にしただけではオブジェクト指向
とは言えないのと一緒。多態とか継承とかが無いとね。
866 :
デフォルトの名無しさん:2008/10/09(木) 22:45:29
STLがいろいろと不備でそれカバーするのがboostとか言う変態ライブラリだろ
最悪じゃね?
boostみたいなゲロの塊を
「最先端のライブラリや!」とか勘違いされると非常に困る
つか || && ごとき現実には対応すらするかよっての
普通に作って問題発生せんわ
>>865 中途半端に<algorithm>なんてものがあるからたちが悪い。
>>867 バッドノウハウを作り続けているという意味で最先端ではないか。
>>799 どうでもいい所からつつくから標準化委員会に相手にされない
重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない
> 重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない
些細なバグだろうとバグはバグっしょ
そんなバグどうでもいいよ、とかお前さん
バグレポ出してきた客に言うの?
>872
なんでいまさら終わった話題に、しかも斜め上のレスしてるの?
それは872自身が重要度と優先度と危険性がごちゃまぜになってるマだからだよ
876 :
デフォルトの名無しさん:2008/10/10(金) 00:17:02
&& || の問題など
e = a*b+c*d;
についてオプティマイズでa*bが先に計算されるかc*dが先に計算されるか分からなくて不明だから、問題だといっているような物だ。
ただのアホ
オプティマイズの話よりセマンティクスの話の方が、よりクリティカルだと思うけど。
優先度ってそういう事だろ。
オイオイ、また同じ話を繰り返すのか?
>>799と前後の流れを100回読み直せ
マジで理解できないなら相当頭悪いよ
880 :
デフォルトの名無しさん:2008/10/10(金) 00:22:17
で、例外の話にはつっこまないのな。
i++ && j++
&&の振る舞いが異なるのが最適化の誤差程度ですか、そうですか。
open("hoge") or die;
とかPerlでよく書くけど、orの意味変わったらどうなると思ってるんだよ
>>873 それ前提が間違ってるから
意図的にバグ埋め込むテロリストみたいな奴にコード書かせる奴のほうが悪い
そんな危険な奴相手なら書かせないかけコードレビューをきっちりするか
コード検証ツールで定期的に確認するか
或いはさっさとクビにするか。
意図せずに埋め込むなんざありえんよ
1ステートメントに++が2回出てきてる時点で論外ですわ
++、--、=ファミリーは1行に1個まで、守らないと鼻から悪魔よー
>>883 脆弱性がバグではないと言い張れたら
MSもこんなにセキュリティパッチを連発する必要無いんだけどね
>>882 operatororとかないから
てかC++の話だから、グロスクリプト言語はお引き取り下さい
887 :
デフォルトの名無しさん:2008/10/10(金) 00:29:04
振る舞いが違っていても問題ないようにコード書くよう教育されているだろ、普通。
カッコつけろ、いったん変数に入れろ、こんなの基本。
>>886 C++でもPerlと全く同じことなのだが
理解できていないようですね
アンチは危険性の指摘云々じゃなく自分の好きな話がしたいだけだろ
C++で開発したこと無いんじゃないかってくらい、現実を見てない指摘
もっと危なくて新人ならよくやるポカが沢山あるのに。
890 :
デフォルトの名無しさん:2008/10/10(金) 00:30:53
>>884 副作用のある物を演算子ののオペランドにしたらどうなるという広い課題に対して、
挙げた一例に対する煽りしかできない時点でバカを自白しているようなもんだ。
まさか
check(x) && exit(1);
とか書いてる奴がいるの?
そんな奴はプログラマやめて下さい
892 :
デフォルトの名無しさん:2008/10/10(金) 00:32:01
C++は本当に大問題ありだが、こんな批判がでるとC++が無問題のように見えてしまうから大問題だ。
>>884 881のことならその点は問題ないだろ。
iとjが実体は同じ、例えばint& i = j;とでもしているのでない限り。
>>891 仕事ではやらないので勘弁してください。
>>891 while ((c = getchar()) != EOF && c != '\n')....
とか普通にかけるでしょ
何のために「わざわざ」&&や||が副作用完了点とされ、
評価順序が厳密に仕様で定義されてると思ってるのかしら
897 :
デフォルトの名無しさん:2008/10/10(金) 00:35:06
>>896 ヤメロぼけかす死ね
優先順位で副作用作るな
>>897 優先順位?
馬鹿確定
仕様理解してないだろ
899 :
デフォルトの名無しさん:2008/10/10(金) 00:36:21
>>887 (軽い判定) && (重い判定)
でもいったん代入するんですか。
(副作用のない判定) && (副作用の出る関数の辺値)
もいったん代入するんですね。
900 :
デフォルトの名無しさん:2008/10/10(金) 00:37:57
while (true)
{
c = getchar();
if( c != EOF && c != '\n')....
}
こうかけ、非常識なコード書くな
perlでは短絡を使うが、それ以外では短絡を使わないな。
なるほど、K&Rや禿は非常識なんだな
>>896 そんなふざけたコード書いて悦に入ってる輩のせいで
真似してカオス文書くアホが後を絶たないんだ
やめてくれよ
while(1)
{
c = getchar();
if(c == EOF || c== '\n')
{
break;
}
...
}
テキストの1バイトも無駄に出来なかったK&Rの時代のバッドノウハウを
ギガバイト時代に持ち込まないで下さい
本当にやめて下さい
905 :
デフォルトの名無しさん:2008/10/10(金) 00:41:53
>>904 お前がバットノウハウだ
お前が死ね、今でもこの手の基本は流石に変わらんわボケ
話は逸れるが、個人的にはこういう風に書けるのが好き。
while (get(&c)) //結果はcに入る。EOFなら偽を返す。
907 :
デフォルトの名無しさん:2008/10/10(金) 00:43:28
>>899 そんなに重いんだったらこうだな
if(軽い判定){
if(重い判定){
...
}
}
もしくはこう
if(軽い判定){
return;
}
if(重い判定){
...
}
&&よりよっぽど明確
まぁ異常なコードを書けば些細な問題が表面化するのも仕方がないというか・・・ヤメロあほたれ
C++信者大好きなboostで&&が使われてるかどうか見てみたら?
&&は非常識、なんでしょ
>>905 うるせえよ化石
896の利点は何だ?
読みやすい?お前だけだ
速い?コンパイラの最適化なめんな
いい加減に馬鹿げた短縮構文なんか捨てろよ
何で一行にグチャグチャ押し込めなきゃならないんだよ
>>910 分かっていて使うやつらはちゃんと把握してコードされてるだろ、使う側が適当でも問題でないようになってるから。
getcharとwhileは100歩譲ってまだ分からなくもないとしよう。
だが、ifでやる奴は本当消えてほしい、無論C++に限らない。
hoge_type x;
if ((x = get_hoge()) != xxx)
逆にコンパイラが遅いとか言ってるのは、おまいのマシンが時代遅れなだけじゃないのかとw
C++ のコンパイラは遅いよ。言語仕様がそうさせてるから仕方が無い。
while(*dst++ = *src++);みたいなのを
「大事なテクニックだからしっかり覚えるべき」みたいに書いてるK&Rは
禁書に指定すべき
こんなものがバイブルになってるからCとその子孫はいつまでもダメなんだ
917 :
デフォルトの名無しさん:2008/10/10(金) 00:52:40
boostといえば、スマートポインタの代入等で発生する回避しがたい例外の問題についてswapを使って例外の問題を封じ込める所とか衝撃だったな
普通の人は気付かない問題もこれを使えば表面化しない。
ソースなんて当然人も読み書きするものなのに
計算機ですらあんなにコンパイルに時間がかかる仕様でいいのか、
という当然の疑問は持ってしかるべきだと思うんだけどね
C++ 以外を無視すれば、コンパイルが遅い事なんて気にならない。
C++ が使えないなら幾ら早くなっても意味無いよ。
ダメだこいつ早く何とかしないと
>>919が哀れに思える。
>>917 代入演算子でswap使う話はExceptional C++にも解説されている。
で、この低レベルなグダグダ議論はいつになったら終わるんだ?
脚からバグについてつつかれても
そんなのお前しか使わないよバーカバーカとか言って済むとでも
思っているのだろうか
>>885に関しても完全にスルーだね
C++信者はどうもパラレルワードに生きているらしい
まともにレスすると負けるから荒らしに切り替えたんでしょ
とりあえずsageろよ
924 :
デフォルトの名無しさん:2008/10/10(金) 01:01:17
>>921 逆にこれを見たとき、C++で例外は使っちゃだめなんだと確信したけどね。
ここまでやらないとバグが潜伏するんだと・・・
パッケージソフトでも C++ で書かれているのはそこそこあると思うけど、
例外を使ってるソフトって無いの?
あるだろうけど、だから何?
質の高いソフトは注意深くしっかり使ってるか、使わないことを徹底してるかだろうけど
世の中の大半は中途半端に使ってて、そしてご存じの通り質が低い
使うにしろ排除するにしろ、しっかりやるとなるとコスト半端ないから
俺はthrowしないとかは勝手なんだが、newもキャストもthrowしてくんだからしっかり
対応はしとけよ。
俺は例外使わないとか馬鹿ルール勝手に設けてリークしまくりのコード書くバカは
マジで困るよ。
ガベージコレクタをサポートしない言語で例外を取り扱うのは非現実的だよ、どんなに注意深く作っても漏れがでる。
なぜならキャッチして自分の把握している範囲だけをdeleteすればメモリーリークを回避できるというものではないから。
>>922 上のほうにそういう話あったじゃない。
スルーは図星の証。
もっとそういう息の根を止められるような話が欲しい。
>>929 それだけだと、スマートポインタがどうのとかって言われるぞ。
>>930 例外導入するなら例外安全なスマートポインタの採用は不可避かと
GCをでっかいスマートポインタの塊だと思ってる人たちに何を言っても無駄
>>928 うちのC++大好きな部下(not新人)とかまさにそんな感じ
正味の話、教育コストは高すぎだな
キャストが例外投げるのは知らない奴多いよな
おれは理解すれば理解するほど、教育でなんとかなるような問題ではないと思うよ > 例外
分かっていても、なんだかの自動サポート無しでは無理だ
デストラクタのない言語のほうが例外は面倒じゃないか?
>>936 メモリ以外のリソースの扱いは比較的局所化しやすいけど
メモリはまず無理だよね
だから両方が必要なんだよな
片方ずつしかないC++とJavaは両方ともダメだ
少なくともnew/castなど言語レベルで出してくるもの、STL/boostや利用ライブラリがthrow
してくる例外にはリソース管理(shared_ptr/auto_lockなど)もしくは、catchしてリソース解放など
適切な処理をすることは絶対の義務。これができてないコードは完全なバグ。
その上で、自分の関数を戻り値返しにするかthrowで例外モデルにするかはポリシーの問題。
>>939 みんながそうやってくれないのが最大な問題なんだよorz
そういう話になるとRAIIがよく登場するが
RAIIもうちじゃ使い物にならん、ほぼ却下してる
そんなわけでアホみたいにtry~catch、逆に開発効率悪い罠
new(std::nothrow)とか全員に律儀に書かせろという方が無茶な話なんだよな
現実的に考えて
>>942 それはそれでNULLチェックしないっていうオチなんだよな
聖典D&Eにも、ぼんくらな平均的プログラマは絶対NULLチェックやらないから
そこんとこ対処しないとって話がある。まだnewハンドラの時代のことだけど。
メモリ管理はスレッド化すれば無問題。
RAIIはロックとかソケットとかファイルハンドルとかの管理にはすごく便利だけど
メモリの管理まで任せらせるようなものじゃない
メモリとそれ以外の共有リソースって本質的に違うよな
C++もJavaも(方向は正反対だけど)一緒くたに扱おうとしちゃってるあたりは同じ穴のムジナ
mallocでちゃんとnullチェックする子もなぜかnewは何もしない不思議だがよくある
その子は正しい
>>947 いやいや上層部でのcatchすらしないってことでしょ、おそらく。
例外版newにせっせとNULLチェック付けてやり遂げたような顔してる奴よりはまし
mainの最上位で
catch(bad_alloc){ メモリが足りません。exit }
ってのも男らしくていいと思うぞ。
まぁ、このスレは板にしては何だかんだ言っても盛り上がったなw
やっぱC++が主要な言語である割には、難解すぎたり問題点が多いから、
議論が絶えないんだろうな。
939のレベルで皆が理解してたとしてもまだRAIIとかその例外中立をどう保つのかの
ポリシー決めとか、実際にすべてのコードをそういう状態に保ち続けられるのかとかの
困難さも残るしな。
そういう困難さを解決したはずのJavaは、その代償のガベージコレクションの動作速度で
別の問題を抱えてC++を駆逐したとは言い難いし、それをさらに改良してヒープとスタックを
選んで作れるようにしたC#もまだ主流とは言い難いし、いったいなにが正解なんだろうな。
その辺でDには期待してた
期待してたんだ
悲しいよ
>>885 日本語でおk
全く噛み合ってないわお前のレス
>>954-955 それと、C++0xはさらに肥大化の方向ということも追加。
Committee Draftまだ見ていないけど。
GCマンセーもRAIIマンセーも間違いで、どっちも必要なんだよな
細かい所はGCに任せて安全性を確保するのも大事
肝心な所はプログラマが寿命をしっかり管理できるようにするのも大事
DとかC#とかはどっちも出来るようになってるし
だからC++0xがGC対応しないことには失望した
実にその通りだが、どっちか一つ選べって言われたらGCなんだよな
局所性のあるリソース管理はまだしもフォローしやすいが
メモリだけはどうしようもない
最初に習うHello worldが悪い。これをテンプレにしてあげないと。
#include <cstdlib>
#include <iostream>
int main(int argc, const char *argv[]) try
{
std::cerr << "hello world!" << std::endl;
return EXIT_SUCCESS;
} catch (...) {
std::cerr << "unexpected world!" << std::endl;
return EXIT_FAILURE;
}
組み込みのARMやPPC, DSP好きのオレ様はGCは全く許容できない
hello worldをcerrに送るのはおかしいだろwwww
C++/CLIのハンドル取り込んじゃえばいいのに…
C++が対象にしようとしているドメインが広すぎて結局どっちつかずなんだよ
GCなしなら最初から例外もなしで、Cよりは便利なADTやクラスが使える、ぐらいの
言語のほうがナンボかすっきりする
デフォルト引数なんてのもいらんだろ
もっと高級なものを志向するんなら、それなりの道具立てをそろえなきゃダメだ
>>945 すまないがうちでそれやったら全部直させる
例にあがってるファイルなりソケットなりはクローズでエラーを返す可能性があるからダメ
そもそも昔のドキュメントには終了処理時にエラーの可能性がある場合はRAIIは適用外だってちゃんと書いてあったんだがなあ
いつのまにか戻り値無視する素人が増えてしまった
cerrは凡ミスだな
しかし、言わんとすることは分かるだろ
C++言語の最初のレッスンでは、
「プログラムに書いた指示は意図通り処理されないことがある。
だから必ず失敗を恐れ、EXIT_FAILUREを返しなさい。
決してcatchを省略してはなりません。例外仕様を決めずに
コーディングを開始してはいけません。」と叩きこむ。これでOK。
>>966 どっかで、デストラクタとclose(メンバ関数)の両方用意するのがいいって話を見たことがある。
無視していいときはデストラクタに任せ、戻り値が欲しければメンバ関数を明示的に呼ぶと言う具合。
>>950 そのスレタイだと絶対荒れるw
まあこのスレでもなんでC++が肥大化したかはわからなかったが
信者の頭がおかしいことは分かった
肥大化したのは単に禿が決めたことだから
一介の利用者がワーワー言った所で理解が及ぶべくもない
もう1000ですね
間が空くたびに煽った甲斐がありました
擁護派の人たちは見てて楽しかったです^^
>>969 事実そうなったからこそ、パート4まで続いている。
まぁ、世の中が本当に頭の良い奴ばっかりなら、C++以上の言語が作られそれが世界を席巻していたであろうw
と、馬鹿が不毛な事を言っております
どんなに彼が頑張っても && || が問題などという話はないという結論で
なぜ799はこんなに必死なのか
どっちもどっち
直球なタイトルだなw
え、なに?スレ立てたの?馬鹿なの?
便利そうだと思って拡張したらトラップだった
ってのがC++に多くて(例外なども)、その一例が&&であり、そこをピンポイントで養護しても意味をなさないっつーことでしょ。
言語としての整合性を考えて拡張しろと。
まあ、今更なんだけどね。
一旦なされた拡張が次で消えるとも思えない。
あなたは○×言語の問題点を指摘されました
1)「おまえは○×言語もわからない馬鹿だから問題じゃない!」とレッテルを貼る
2)「その問題は俺は回避できるから問題じゃない!」と論点を摩り替える
3)「△□言語にも同じ問題があるから問題じゃない!」と論点を摩り替える
4)「〜〜という理由でそれは問題とは言えないのではないか?」と論理的に問題無いことを証明する
5)「確かにそこには問題があるね」と素直に認める
普通は4か5を選ぶと思うんだが、何故か123ばっかりだったね
詭弁連レス…
>>984 いやいや、&&は「普通使わないという理由でそれは問題とは言えないのではないか?」だったはず。
ちっとも論理的ではないが。
まぁ信者は問題点に納得した時点で沈黙するからなぁ
結局新規の馬鹿信者が斜め上発言してアンチがフルボッコにするループはいくらでも続く
>>986 それ論点のすり替えに該当してるからw
証明というなら、そう在るべき理由とその重みを挙げるべき
&&批判に反発してた連中は、終わった話を何度も蒸し返して
無駄に傷口広げてる感じだったな
しかも禿の仕様ミスであること自体は認めているから
まともに・論理的には反論できずに
そんなのは些細なことで問題にするほうがおかしいとか
斜め上の話ばかりになる
信者とか擁護派とかアンチとか煽りはフィルターして読むと、自分にとってはなかなか実の
ある内容だった。
非常に気を付けて使う必要があるが、気を付ければ高い性能を得ることができることが
わかった。赤兎馬みたいなもんすね。
ていうか、&& 批判を批判しているのはC++信者ですならないんですがw
>>989 そんなプログラミングの勉強初めて1ヶ月経ちました!見たいな事言わんでもw
仮に読むまで評価しない式の参照型を追加したらもっと凄い事になりそうだ
初心忘るるべからず
子供の発見には、満面の笑みで「へぇ!すごいねぇ!」って言ってあげるべきだったな
>>989 素晴しい着眼点だと思うよ!今後もがんばって研鑽してね!
満面の笑みと言うなら
>>989 素晴しい着眼点だと思うよwwwwwww今後もがんばって研鑽してねwwwwwww
あんま煽ってやるなよw
それと、赤兎馬の比喩に適切なのはどっちかっつうとCだな
いや、つまんないから
つまり、
C++最強。以上。
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。