【肥大化】C++ を見捨てたヤシ 2人目【複雑化】

1 ：2008/05/17 〜 最終レス ：2012/09/17

前スレ
http://pc11.2ch.net/test/read.cgi/tech/1201567967/

2 ：

前スレの1
1 ：デフォルトの名無しさん [sage] ：2008/01/29(火) 09:52:47
　　文法面での機能拡張しすぎ。
　　C++の構文解析とか、もうワケワカメ。
　　マイクロソフト拡張大杉。
　　gcnew とか使うぐらいなら素直に Java でも C# でもつかえ！！！

3 ：

>>2
それ貼ると混乱するから、前スレの3も貼っとくね
3 名前：デフォルトの名無しさん 投稿日：2008/01/29(火) 09:55:02
標準と非標準の区別もつかない池沼か
確かにC++から離れた方がいいな

4 ：

JavaとC#の事とC++との話だけど、C++は実行効率命で
Javaは理想郷を追い求めている言語なんだと思うが。
ただ、JavaがGenericsを導入したときは美しくないと思ったが。
ああいうのはC++の分野だろうと思った。

5 ：

>>4
誰にとっての理想郷かという観点がすっぽり抜け落ちてる。
雑魚にとってなら同意できる。

6 ：

恐らく、奇麗に整理された言語仕様が欲しい人かな。
Perl に対する Python みたいな感覚だろうね。
Perl 使いが Python 使いを雑魚扱いしていたら失笑するのと一緒。

7 ：

前スレから適当に拾ってきた。客観性は保証出来ない。
・C++複雑過ぎ
・必要な機能だけ使うべき
・それで済まないためEC++が作られた
・better C
・有名な本は全部読んどけ
・Java,C#も複雑化してきた
・初心者に優しくない
・コンパイル遅過ぎ
・Core2Quad速過ぎ
・boostR過ぎ
・デストラクタ, RAIIは優れている
・用途に応じて言語を選択
・オブジェクト指向理解してない奴多過ぎ
・C++はマルチパラダイム
・char *a; char* a; malloc, free 宗教論争のご利用は計画的に

8 ：

編集１０秒
コンパイル１５分

9 ：

そこで pimpl ですよ
って、pimpl も汚いテクニックだよね。

10 ：

pimpl って opaque type みたいな物じゃないの?

11 ：

・「デストラクタなんて要らない」
・「文字列如きでリークさせる奴なんかいない」
・「Windowsがおかしい、Linuxでリークしたことない」
・「むしろWindowsとの互換性のためにデストラクタがある」
・「Windowsがへぼいからデストラクタが必要になるだけ」
・「Windowsを使ってはいけないという結論が出てる。」
・ C++ユーザーは皆、デストラクタが無いと文字列操作も出来ない
・「デストラクタが無いと何も出来ないんだな」
・「Windowsが糞な実装だから必要になってるだけ」
　「Linuxも使えない雑魚が。」
・「結局デストラクタは無くても良いという事で全員の意見が一致したなw」
・「デストラクタが無いとプログラム組めない人が居たのかな？」
・「オブジェクト指向にデストラクタが本当に必要か考えてみるがいい。」
・「Windows使ってると頭おかしくなるのか？」
　「なんでここまで説明してやらないとわからないんだろう？」
・「だからLinuxなら全然問題なく完璧にできるっつってるだろ。」
　「これだからM$信者は駄目なんだよ。」
・「そんなことも知らないのか。M$信者は達者なの口だけだな。」
・「お前らはカーネルのソース読むとこから始めたほうがいい。」

12 ：

デストラクタに異様なこだわりがあるなwww
ガベコレなんて所詮メモリ管理にしか効力を持たないというのに。

13 ：

>>12
デストラクタとガベコレは別のものなんだが。

14 ：

なにをそんな当たり前の事を言ってるのだろうか・・・

15 ：

shared_ptrでいいじゃｎ

16 ：

>>15
つ循環参照

17 ：

クリティカルセクションに関しては synchronized でいいとしても、ファイルはどうすんだよって話だな。
ファイル使ってるところは必ず try-finally 使ってファイル閉じるとか面倒くさ過ぎるわ。

18 ：

with-open-file マクロみたいなのがあると良いのにね

19 ：

今後はクロージャでやるんでしょう
Rubyのように
open(fname){|file| do_something(file) }

20 ：

それは変数の有効範囲が分かりやすくなる反面、
ネストが深くなるというデメリットも持っている。
ファイルを複数開くとネスト深すぎて笑えることになる。

21 ：

まあ出来ないよりは出来た方が嬉しいね

22 ：

でも一般的にはリソースの確保系はどーせtry...catchでネストするし、しょうがないんじゃないの？

23 ：

リソースの解放は
Javaは try-finally
C#は using(){}
C++, D言語は RAII
Cは必要な箇所全部に記述

24 ：

>>22
頻繁に失敗する可能性のあるタイプのもので
しかもループ内で行われるものであれば
効率を優先して論理値を返す関数でチェックする可能性もある。

25 ：

そゆのはそもそも>>18with-マクロの対象じゃないと思う。
なんかコネクションはってプリペアードステートメント実行して結果をスキャンみたいなうだうだしたのを想定してた。
Uzeeeeってならね？
r1 = allocate_resource_A();
try {
r2 = r1.allocate_resource_B();
try {
r3 = r2.allocate_resource_C();
try {
....
} else {
r3.close();
}
} finally {
r2.close();
}
} finally {
r1.close();
}

26 ：

しまった。Javaスレかと勘違いしとった。ゴメン。

27 ：

リソースの開放は、
必要なときに、必要なだけしてもらえる方法がありがたい

28 ：

>前スレ1000
html化って今でもされてるの？
エフィリエイターに保管されることを html 化っていってるの？

29 ：

C++ってロストテクノロジー的でいいね

30 ：

再発掘されてるあたりそんな感じだね

31 ：

http://www.bagley.org/~doug/shootout/craps.shtml
As you can see, OCaml is actually faster than C++. OCaml has currying,
garbage collection, anonymous functions etc. built-in -- therefore,
you don't need to resort to extremely high-tech template programming
as you do in C++. OCaml can work as an interpreter, a compiler to a
portable byte-code, or a compiler to the native code. It makes us wonder
if C++ has any reason to exist (It's a very inflammatory remark, I'm
sorry. One can still wonder about that).
見てわかる通り、OCamlは実際C++より速いのです。OCamlはカリー化、
ガーベジコレクション、匿名関数などを有しています。内蔵(built-in)しているので、
それゆえ、あなたがC++でプログラミングするときにやっているような、凄くハイテクな
テンプレートを頼りの綱とする必要も無いのです。OCamlは、インタプリタとしても動きますし、
移植可能な(portable)バイトコードを吐くコンパイラ、そしてネイティブコードを吐く
コンパイラにもなります。このことは、C++なんて存在する価値があるのかという気になります。
（極端な意見でごめんなさい。そう考えている人も居るのです）

32 ：

OCamlでOSを書けてから言いなって感じだな

33 ：

ここで批判的に書かれているのはCではなくC++だよ。
たとえOCamlでOSが書けなくても、OSはCで書きゃいい、って返されて終わり。
C++批判の多くは「Cと○○があればC++なんか要らん」という形態を取っているから、
そこで「じゃあ○○で××（Cで書けばいいようなもの）を書いてみろ」を反論するのは
効果的ではない・・・というか空回り。
「言語なんて○○ひとつあれば十分」みたいな意見に対してはその反論でいいけど、
これはあまり居ないんだ。

34 ：

OCamlよりも俺はF#が良い。

35 ：

OCamlで仕事があったら考える。

36 ：

まぁ、OCaml最強ってことで良いんじゃね？
ただ、最強が何であれ、UNIX系はC、Windows系はC++,C#、
Webサーバー関連はJava,Perl,PHPなどが
今後も主に使われて行くでしょうけどね。

37 ：

>>35
考えてもらえるかは別として、仕事はあるみたいだよ
http://rikunabi2009.yahoo.co.jp/bin/KDBG00200.cgi?KOKYAKU_ID=2715900001&MAGIC=

38 ：

そして「SMLで」と言われるわけですね

39 ：

>>33
OS には アセンブリ言語/C だけじゃなく C++ も使われている訳だが

40 ：

お前は何を言ってるんだ

41 ：

>>38
面白い事を言ってるつもりかもしれんが、ググってからでも遅くはないじゃろう
http://www.janestcapital.com/ocaml/

42 ：

まあたしかに関数型言語とか面白いとは思う・・けど・・
OS作るなんて大げさな話じゃなくてもさあ、低水準の入出力とかドライバとか
割り込みとかリアルタイム処理とかマルチスレッドとか並列処理とか
骨っぽいところは全部Cに任せて、おいしいロジック部分だけきれいに書いて
あとはOpenGLをラップしたライブラリでも呼んだデモ見せて「どーです、C++なんかと
変わらないスピードでこんなことまでできるんですよ♪」みたいなの多いよね。
（いや、OCamlはその点どうなのかは知らないけどｗ）
そんなんだったら俺はいらないな。全部CかC++で書いたほうがまだまし。
C++に取って代わる言語は、もっと整理された美しいものであるべきだろうけど
同時にCの切れ味も失ってほしくはないなー。

43 ：

>>42
>マルチスレッドとか並列処理とか
>骨っぽいところは全部Cに任せて、
知らないのによくこれだけ騙れるな
さすがC++クオリティ
Erlang とか Haskell STM とか SML
Manticore でググってみよう

44 ：

なんでそんな攻撃的なんだ・・？　少しは肩の力抜けよ。
ML勢はそのあたり手が出せないなんて一言も言ってないんだが。

45 ：

>>38と>>41の意味が分からないんですけど、
誰か教えて・・・。

46 ：

そう言えば前にKYな香具師がC/C++の宿題スレにOCamlの
ソースを回答してフルボッコされていたな
マイナー言語のユーザーってこんなんばっかし

47 ：

まぁKYのK==空気は、勢力の拡大によってしか得られないもので、
今現在弱い勢力が大人しくKを読んでたら、いつまで経っても弱小のままだからな。
ビラ配りとか反政府ゲリラと同じ。弱小勢力は常に「最大勢力から見たKY」にならなきゃ強くなれん。

・・・でも宿題スレはねぇなｗ

48 ：

せっかく訂正してあげて丁寧にポインタまで並べたのに、
仕事から帰ってきたら意味不明な逆切れされてて俺ｶﾜｲｿｽ…
Erlang くらいは常識として知っておいても損はしないんだが…
>>45
「>>37 に ML という言語の経験者の採用が載っている。
Lisp に CL と Scheme があるように、ML は大まかに
言って SML と OCaml がある。>>37 には ML としか
書いてないから >>38 は OCaml じゃなくて SML の
求人なんじゃないのと指摘している。実際の所は >>41
の通り OCaml で有名な会社なので、OCaml の仕事が
ある可能性は高い。」という話だよ。

49 ：

>>47
そうではないと思う
出るのが単に遅すぎただけだよ
後に出せばそりゃ先行言語の欠点を取り除き利点を多く持った言語になるだろう
しかし勢力が弱いという事実が決定的な弱点だ

50 ：

虎の威を借るって奴か

51 ：

まあある意味極論すればC++はCの威を借る狐だ
いや極論しなくてもまんまか
しかしこれだけ主流になってしまえば後発の優れた言語が
その座を引きずり降ろす事は困難だろう

52 ：

C++は速いから好まれてると思う。

53 ：

ていうかソースと機械語との対応が類推できるから、が大きいと思うな。
ノイマン型コンピュータ使ってる限り、どう書けば速くなりそうかが
わかりやすいC/C++が好まれるのは自然な気がする。
で、結果的に速いコードが書けるので職人プログラマに好まれる、と。

54 ：

>>53
あんたは、C++のソースがどういうコードに落ちるか想像つくのか。
そんなわけないだろ。

55 ：

つく人多いと思うよ
そんなわけないって言う理由が分からない

56 ：

想像つかなきゃ、アセンブリ出力を眺めるだけだな。
なるほど、職人プログラマに好まれるわけだ。

57 ：

>>55
よしわかった。
そこまで言うなら、boost::spiritを使い四則演算可能な電卓を作成、
これがどのようなコードに落ちるか予測しなさい。
期限は本日09:00まで。

58 ：

お前と違って今から出社なので

59 ：

spiritはC++単体で動いてるんじゃなくてなんかライブラリ呼び出してるんじゃなかったっけ
かなり高水準なことしてる部分だからそんなところのマシンコード誰も気にしないっしょ
仮想関数テーブルなんかが出てこない限りはアセンブリコードとの対応は
C++の場合わりとわかりやすいよ

60 ：

>>59
> なんかライブラリ呼び出してるんじゃなかったっけ
> 仮想関数テーブルなんかが出てこない限りは

61 ：

ん？なんかおかしいかな？
Cでたとえばprintfの中身の実装まで普通はコード気にしないのと同じだと思うけど

62 ：

>>61
いや、マジレスするのもはばかれるくらいなんだが、問題はそういうことじゃないだろ。
釣りのつもりじゃなかったら、とりあえずC++使ってみろ。
釣りなら、知ったか厨認定される前に釣りでしたってレスしとけ。

63 ：

なんで？
おかしいならおかしいとこ教えてくれよ

64 ：

>>63
ということは、釣りではないんだな？

65 ：

うんうん
あと俺、いちおうC++使ってるよ

66 ：

>>57
55じゃないけど、C++ソースから機械語コードを想像って話で、
boostを出すのはおかしくない？
boostって、どうテンプレート展開されて、
どんなC++ソースになるか追い辛いからRとか言われる訳だし。
それと電卓がどうってのも例として変な気がする。
今の文脈での想像って、クラスのメモリイメージ(仮想関数テーブルなども)、関数でのスタックの使用イメージ、
典型的な最適化イメージ、とかのことじゃないの？

67 ：

>>65
では、心置きなく言ってやろう。
知ったか乙！

68 ：

spiritはテンプレートな

69 ：

知ったかはあんたじゃないの？
おかしいならどこがおかしいのかはっきり言ってくれないとわかんないな

70 ：

だからさ、テンプレートの本来の普通の動作としてコンパイラが処理できる範囲じゃなくて
中でライブラリ呼び出してるんだからあんまり適当な例じゃないんじゃねーのって言いたいんだけど
それでも間違ってる？

71 ：

そもそも自分の書いたコードがどういう機械語に落ちるかって話であって
ライブラリ（テンプレートライブラリ含む）が内部で実装してるコードまで
追っていくんじゃきりがないから気にしないでしょ、って話もおかしい？

72 ：

おかしくないと思う。

73 ：

同じニーモニックなら同じマシンコードに落ちるとかも普通に思ってそうだな。

74 ：

めんどくさい人だな。がんばって突っ込みいれてみたよ。
突っ込もうとして途中でやめた >60 の気持ちがわからんでもない。
> spiritはC++単体で動いてるんじゃなくてなんかライブラリ呼び出してるんじゃなかったっけ
いいえ。
> かなり高水準なことしてる部分だからそんなところのマシンコード誰も気にしないっしょ
わざわざ設定された例題について、気にする気にしないを述べる意味がわからない。
例題が適切かどうかは知らないけど。
> 仮想関数テーブルなんかが出てこない限りはアセンブリコードとの対応は
> C++の場合わりとわかりやすいよ
アセンブリコードとの対応が難しくなる線引きは仮想関数テーブルなんかではありえない。
関数アドレスを並べたものが対応するに決まってる。

75 ：

> > spiritはC++単体で動いてるんじゃなくてなんかライブラリ呼び出してるんじゃなかったっけ
>いいえ。
そうなのか〜
どっかでboost::spiritはなんとかってルーチン呼んで利用してる、って書いてあった気がしたもので・・ごめんね
> わざわざ設定された例題について、気にする気にしないを述べる意味がわからない。
いや、だってさ、単純なものならともかく、一行書けば膨大なコードに展開される部分をもってきて
機械語想像しろ、ってのはちょっと違うとおもうんだけど。
ライブラリの出来を比較してるんじゃないんだからさ、言語本来の命令や構文で書かれた部分が
主体の例題じゃなければ、意味ないんじゃないの？
> アセンブリコードとの対応が難しくなる線引きは仮想関数テーブルなんかではありえない。
> 関数アドレスを並べたものが対応するに決まってる。
そんなの人それぞれじゃないの？トレースしにくくなるから嫌い、って人もいるでしょ

76 ：

>>73
同じニーモニックなら同じマシンコードつーかオペコードに落ちるのが普通だと思うけど？

77 ：

>>75
>> わざわざ設定された例題について、気にする気にしないを述べる意味がわからない。
> いや、だってさ、単純なものならともかく、一行書けば膨大なコードに展開される部分をもってきて
...
> 主体の例題じゃなければ、意味ないんじゃないの？
そう。例題として適切じゃなかったようには思う。
でも、それが言いたかったなら「気にしないっしょ」で伝わるわけないだろ。
>> アセンブリコードとの対応が難しくなる線引きは仮想関数テーブルなんかではありえない。
...
> そんなの人それぞれじゃないの？トレースしにくくなるから嫌い、って人もいるでしょ
59 の書き方では「人それぞれ」という意図は伝わらない。
あと、アセンブリコードとの対応の話と「トレースしにくくなる」とか
「嫌い」とかの話はまるでつながってないぞ。

総じて、読む人にエスパー能力を期待しすぎている。会話がしたいなら気をつけて欲しい。

78 ：

>>71
>テンプレートライブラリ含む
これはおかしいだろ。
明示的に自分で書いたコードだろうがライブラリが暗黙的に
展開しているコードであろうが、少なくともコンパイル時に
生成されるコードは把握出来ないとな。

79 ：

なに言ってるんだか・・
じゃああんたはマクロアセンブラでマクロとして実装されたライブラリを
アセンブル時に中身を全部把握してないとだめだとでも言うのかあ？

80 ：

いいことを教えてやろう。
極めた人間はどの分野でも一握りだ。
つまり数が少ない。
一方、入門者は多い。
言い合いになると極めた人間のほうが打ち負かされるのだ。
少なくともニチャンネルではそうだ。
ここでは数の論理が働く。
つまり、ニチャンネル的にはC++はテンプレート禁止。
ついでに仮想関数も禁止。
これでおｋ。

81 ：

はいはい、自分は極めた人間で相手はバカでないと気に入らない、と。
言い負かされるのは俺様みたいに極めた人間は少ないからだ、と。
おめでたいねえ

82 ：

>>81
いや、>>78と>>79のやり取りを見て書いただけだ。
おれは関係ない。

83 ：

関係ないんならわざわざageてまでくだらないこと書くなよ
すっこんでろ

84 ：

>>81
なにムキになってんの

85 ：

アセンブリコードまで気にしてガリガリにチューナップしたいプログラムにboostは使わないでOK

86 ：

機械語が想像つく派はテンプレートを普段使わないからだな。
しかも、機械語について語りつつも、ニーモニックが同じなら
オペコードも同じなどと述べちゃってるところをみると、
機械語も詳しくなさそうだ。
よって放置推奨。

87 ：

違うのか？
特殊なアーキテクチャのモノならしらんけど、普通のCPUなら
ニーモニックとオペコードは１対１対応でしょ？

88 ：

>>87
その程度の見識しかないならあまり偉そうな物言いは避けたほうがいいと思う。
これ豆知識な。

89 ：

またかよ・・違うならどこが違うのかはっきり言ってくれ
偉そうなのはどう見てもおまえのほうだろ？

90 ：

ニーモニックが同じでも対象 CPU やアセンブラが違えば違うオペコードになるだろう。
きっとそういうことさ。

91 ：

そ、そんなことが言いたかっただけ・・？　マジ？

92 ：

機械語が想像つく派だけど、テンプレートを普段使ってる。
テンプレートの展開と機械語への変換は異なる問題領域だと思う。
大雑把にフェーズを分けると、
　プリプロセス　→　template展開・inline展開　→　コンパイル
という感じで。
ただ、俺の言う「想像つく」と、他の人の言うそれの認識が
一致してないかもしれない。
ニーモニックのこと話してる人達も、
「同じ」ことの意味、前提がズレてるんじゃないの？

93 ：

まぁあれだな
肥大化と言えばJavaの方が酷いだろ
C++は仕様はシンプルだぜ

94 ：

C++ 言語仕様の肥大化大きすぎ、ライブラリーも肥大化しているが表面化していないのでOK。
Java　言語仕様はまあまあ、これから肥大化の可能性あり。
　　　　クラスライブラリーが肥大化、統一場所が少ないので、場合によっては無秩序。

95 ：

C++の場合「機械語が予想つく」ではなく
「機械語を予想できるコードを書ける」と言うべきではないかと
それが必要ないならテンプレートでも仮想関数でも何でも使えばよろし
手段は一つじゃないしそれをマが選べるのがC++の最大の強み
まあ適切に選べるだけの知識が無ければC++なんて複雑なだけのフリーク言語だろうけど

96 ：

機械語を予想できることと、
テンプレートや仮想関数を使うことは
何も対立しないと思うけど。

97 ：

>>87
違うCPUの方が一般的

98 ：

>>97
いくらなんでもそれは無いだろ。
一般的にはアセンブリのニーモニックはオペコードは１対１。
↓の記事が間違ってるとは思わない。
http://e-words.jp/w/E3838BE383BCE383A2E3838BE38383E382AF.html
たとえばどの CPU のどのニーモニックに対して複数のオペコードが対応するの？

99 ：

>>98
ってことは、>>97がその程度の一般常識で勘違いしてる馬鹿または嘘吐きってことか。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

推薦図書/必読書のためのスレッド 69 (201)
SSE AVXのプログラミング (729)
GCCについて part10 (220)
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5 (937)
●●●●TCL/TKなら俺に聞け 2●●●● (918)
***Javaのオススメ入門書***　『創るJava』 3.0 (563)
--log9.info------------------
オ・ウォンビン【OH　WONBIN】★２ (233)
石川秀美 Part4 (225)
有名人死にすぎだよ (581)
まだいたの南野陽子part5　　 (766)
横須賀よしみ　「旧・横須賀昌美」 (238)
工藤静香はもう引退したの？ (254)
一木有海ﾀｿを懐かしむスレぱあと1 (257)
◆内気なキュービッド◆島田奈美３◆ (499)
白鳥百合子△part41 (967)
【もうすぐの予感】−酒井法子 P46−【天使がくれたレインボー】 (367)
【危ない感傷】いとうまい子・伊藤麻衣子 Part4 (405)
【新御三家】西城秀樹、郷ひろみ、野口五郎を語ろう！【アイドル】 (394)
【ホイッスル!風祭将】小向美奈子1【アバレンジャー王女】 (366)
横山やすし (579)
中森明菜！について想いを語ろう (605)
【やる気なし】藤崎奈々子【ギャラ泥棒】 (757)
--log55.com------------------
【テレ朝土23】東京独身男子 part3【高橋一生・斎藤工・滝藤賢一】
【WOWOW】ドラマW(各シリーズ) その25
【フジ木22】ストロベリーナイト・サーガ 苺7個目
【テレ東ドラマ24】きのう何食べた？ part11【西島秀俊・内野聖陽】
【TBS日曜劇場】集団左遷!! part6【福山雅治・香川照之】
【フジ月9】ラジエーションハウス〜放射線科の診断レポート〜 part7【窪田正孝】
【レギュラー0w】糞以下超低視聴率老害落ち目とんねるず(笑)９【たいむとんねる2.8w】
【テレ朝開局60周年】白い巨塔 part11【岡田准一】