【結構迷う】C vs. C++【どっちで行こうか】

1 ：デフォルトの名無しさん：2008/04/06(日) 03:17:49

一般的には「C/C++」とひとまとめにされることの多い両言語ですが、
どちら一方をどっぷりと使っている人にとっては、かなり大きな
壁を感じると思います。

そこで、「C/C++」な人でも「C派」「C++派」に分かれて、それぞれの
観点からどちらの言語がより良いか、議論してみましょう。
主観的、客観的意見なんでも構いません。ただし建設的な議論に
なるよう、理由も添えてお願いします。

ルール
1．Java、C#などの「C/C++」以外は論外。これらについて言及している
レスは無視してください。

2．速い、遅いなどの議論は極力説得力のある根拠、ソース（情報源）
などを提示してください。

3．特定のOS、開発環境を理由に挙げたり、叩いたりしないでください。
たとえば、「Linuxの人は…」や「VC++ってやつは…」などは禁止。

4．標準、準標準のライブラリに関しては、その言語を使う場合常に
ついてまわるので言及をOKとします。

5．どちらか一方しか使ったことのない人は、その旨を述べた上で
意見をお願いします。

6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。

2 ：1：2008/04/06(日) 03:18:23

関連サイト

C++はなぜ人気がないのか
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050215/156201/

もう C++ なんて好きでもないし使いもしない理由。
ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus

Why not using C++?
ttp://xinehq.de/index.php/hackersguide#AEN405

Boost
http://www.boost.org/

GLib
http://library.gnome.org/devel/glib/2.8/

3 ：デフォルトの名無しさん：2008/04/06(日) 03:30:11

単純にC拡張として好きだ
１つの意味の処理まとめて{ }ブロックで括って内部で変数寿命完結させるところとか美しい。

それとC++はMFCとか面白いじゃあないか　表向きの効率は旧VBや.netに劣るけれども。

4 ：デフォルトの名無しさん：2008/04/06(日) 03:32:17

便利なライブラリがC++でしか用意されていない。

5 ：C++：2008/04/06(日) 04:12:38

単純にC++が好き
newは嫌いだけどな

6 ：デフォルトの名無しさん：2008/04/06(日) 07:42:48

RAII の気持ち良さを知ってしまうと、もう C には戻れない。
string の楽チンさを知ってしまうと、もう C には戻れない。
template の汎用性を知ってしまうと、もう C には戻れない。
抽象プログラミングの威力を知ってしまうと、もう C には戻れない。

C はプログラマを低レベルなバグで悩まさせ、疲れさせる言語だ。
環境的な制約がない限り、迷う必要などない。

7 ：1：2008/04/06(日) 10:38:57

自分は一度、C++に疲れて愛想を尽かそうとしたクチなんですけど、
設計と進化を読んでからC++が大好きになってしまった。

「ポインタがあるのになぜ参照が導入されたか」などの理由を知ると
それがあまりにも必然に思えて、「C++は複雑化しすぎ」とか言われるほど
複雑に見えなくなってきた。C++の各機能の導入経緯を知ってから
自分の思考回路がC++と馴染んだ気がする。

C派の意見としてよく聞くのが、ABI不在による保守の問題とか、
その辺は自分はあまり実感ないです。
それから上記の理由により「複雑すぎて云々」も今や感じません。

あと、Boostにアドビから画像処理ライブラリが追加されるなど、Boostの勢いにも
魅力を感じます。

8 ：デフォルトの名無しさん：2008/04/06(日) 10:40:58

> ポインタがあるのになぜ参照が導入されたか
なんで？

9 ：デフォルトの名無しさん：2008/04/06(日) 10:47:39

ライブラリ作ったり引っぱってきたりするのに公式なABI仕様がないのはつらいよ。
せめて、同一プラットフォーム上だけでも統一してほしい。

10 ：1：2008/04/06(日) 13:14:10

>>8
ビョーンさんは言語内臓型とユーザ定義型を差別したくなかった
↓
例えば、複素数型でも c = a + b; と書けるようにしたかった
↓
演算子オーバーロード（operator+など）を導入
↓
一般的にユーザ定義型はポインタ渡しの方が効率的
↓
complex *operator+( const comple *a, const complex *b) {...} とすると…
↓
c = &a + &b; と書かなくてはならない
↓
誰もそんなの書きたがらないので、参照を導入（元々&a + &bには別の意味があるとも言っていた）

ちなみに記述方法の問題が出たとたん、すぐに参照を思いついた訳では
ないそうです。友人に相談したとき、その人がポロっと発した
「リファレンス」と言う言葉で閃いたそうです。　

11 ：デフォルトの名無しさん：2008/04/06(日) 13:15:16

>>8
演算子多重定義のため。

値渡しじゃ効率悪いし&x + &yとか見れたもんじゃない。
それに&x + 1とか多重定義できないし。

12 ：デフォルトの名無しさん：2008/04/06(日) 13:17:37

確かに、

13 ：デフォルトの名無しさん：2008/04/06(日) 13:56:07

Cの人は「演算子のフルセットを提供しなくちゃいけない」という
脅迫観念に駆られる必要がないので、その辺はうらやましく
思うときがある。

加算関数なんてほとんど
void add(vector *dest, const vector *x, const vector *y)
の1パターンだからな。

方法論がシンプルな分、どうやろうか悩むことがほとんどないし。

14 ：デフォルトの名無しさん：2008/04/06(日) 14:07:15

>>9どうつらいかｋｗｓｋ

15 ：デフォルトの名無しさん：2008/04/06(日) 19:17:26

ポインタ変数そのものをアドレス変更権付きで渡す際に
「ポインタポインタ」という美しくない方法を取ってたのが
「ポインタの参照」でしっくりきた。から参照はなかなか良いと思う

でも内部的にホントは「参照変数」なんて実体はなくて
便宜上そう見せてるだけなんでしょうね、きっと。

16 ：デフォルトの名無しさん：2008/04/06(日) 20:05:11

Cは文字列の扱いがうんこ過ぎる
C++はADLをはじめとする名前空間とオーバーロードの関係がわからなすぎる

17 ：デフォルトの名無しさん：2008/04/06(日) 23:08:58

文字列処理する必要のない環境だって山ほどあるんだ。

18 ：デフォルトの名無しさん：2008/04/07(月) 00:13:40

んなこと言ったら、OS書くときゃdouble、floatはほとんど使うわんだろ。

19 ：デフォルトの名無しさん：2008/04/07(月) 00:15:36

＞んなこと言ったら、OS書くときゃdouble、floatはほとんど使うわんだろ。
ﾌﾟｯ（´,_ゝ｀）

20 ：デフォルトの名無しさん：2008/04/07(月) 00:31:14

GLibがないと生きていけだが、他に誰か同じような人ひる？

21 ：デフォルトの名無しさん：2008/04/07(月) 00:48:22

>>19
OS Xの座標系がfloatなんだがどうすれば良いかな。

22 ：デフォルトの名無しさん：2008/04/07(月) 00:57:40

>>21
それはデバイスドライバの仕事じゃね？

23 ：デフォルトの名無しさん：2008/04/07(月) 01:03:23

いやでも、アプリケーションの高水準なインタフェースと
ドライバの低水準なインタフェースの差を埋めるような部分はOSの仕事としてあるのでは？

24 ：デフォルトの名無しさん：2008/04/07(月) 01:05:39

どこまでをOSと言うかだけど、標準GUIコントロールとか描くのとかもOSの仕事だと思ってるから、使いまくりだと思うな。

25 ：デフォルトの名無しさん：2008/04/07(月) 09:44:55

>>14
ライブラリとアプリでコンパイラが違うとマングリング規則が違って使えないだとか、
下手するとコンパイルオプション違うだけで、動かなかったりだとか。
（2番目はCでもありそうだけど）

26 ：デフォルトの名無しさん：2008/04/07(月) 12:32:08

かつてはC++でバリバリやってたけど、今はC。

stringとかvectorとか便利だとは思うけど、「C++使いの常識」を踏まえて
コードを書かないと、効率が落ちたりするのが気に入らない。

EffectiveC++やEffectiveSTLを読んで初めてC++を使えてるって感じがやだなぁ。他にもいろいろ本読んだけど、
プログラムでやりたい事がなかなか進まずめちゃくちゃフラストレーションがたまった。
STLを勉強したいのか、プログラムを完成させたいのか、自分でも分からなくなるときがあった。

テンプレート使ったときよりコードは美しくないけど、Cの方が変なところに気をつかわず
コードが書けて、作りたいものがはかどる。

27 ：デフォルトの名無しさん：2008/04/07(月) 12:36:19

小物のツールこそC++で作ってしまうなぁ。
客先納品物の場合は何かと面倒なのでCで書くこともままあるけど。
設計から自分で仕切れる場合は問答無用でC++だな。

28 ：デフォルトの名無しさん：2008/04/07(月) 13:27:08

>>26
>かつてはC++でバリバリやってたけど
信憑性に難あり。

つか、C++が使える環境でC++を使わない理由などないんだが。

29 ：1：2008/04/07(月) 13:42:13

>>28
>つか、C++が使える環境でC++を使わない理由などないんだが。

>>25の意見に対してはどう思いますか?
ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus
の記事にも似たような意見がありますが、具体的に何か反対意見があれば
お願いします。

30 ：27≠28：2008/04/07(月) 13:47:33

>>29
私の場合は、ライブラリはextern "C"で作るかソースごと使うか。

31 ：デフォルトの名無しさん：2008/04/07(月) 19:55:37

毎回毎回CでList構造書くのはつかれたよパトラッシュ

再利用しようとしてvoid*使うけど、型安全じゃなくなるよ

32 ：デフォルトの名無しさん：2008/04/07(月) 20:21:32

毎回毎回プロジェクト毎に最適なore_string型の実装を考えて
書くのは(ry

33 ：デフォルトの名無しさん：2008/04/07(月) 23:32:33

>>32
標準のstringを内包して、必要な機能を付けるだけでいいんでない?

34 ：デフォルトの名無しさん：2008/04/08(火) 00:58:18

D言語の簡便さとtemplateの記述性の高さと配列の使いやすさを知ってしまうともうC++には(ry

関数ハイジャック軽減法
http://www.kmonos.net/alang/d/2.0/hijack.html
テンプレート再訪
http://www.kmonos.net/alang/d/2.0/templates-revisited.html
配列
http://www.kmonos.net/alang/d/2.0/arrays.html

35 ：デフォルトの名無しさん：2008/04/08(火) 01:02:29

C vs C++スレだけど、
なんだかんだでCもC++もだめな気がする今日この頃

36 ：デフォルトの名無しさん：2008/04/08(火) 01:23:35

C++が非常に実用的で現実的な言語であることを認めた上で個人的な意見としては、
・ここで言われるC++の利点は他の高級言語なら、より良く実装されてる。
逆に言うと、それらの言語から見て、C++の実装は非常に中途半端に見える。
・Cは(一部の例外を除いて)非常にシンプルで明快なシンタックスである。利便性を
元に実装されたC++の拡張はグロテスクだ。
なので、低レベルの処理はCで、高級な処理はC++以外の言語でというのが理想。

37 ：デフォルトの名無しさん：2008/04/08(火) 03:06:25

C++がオブジェクト指向的に中途半端なのは同意だが、
テンプレートがあるので問題ナス

C++0xやTR2が実装されれば、かなり便利になる・・・
が何年先になるか不明

あと最近知ったけど、Cもちゃんと次の標準に向けてがんがってるのね
http://www.open-std.org/JTC1/SC22/WG14/

38 ：28：2008/04/08(火) 13:21:51

>>29
C++を使いたくないが為の言い訳にしか聞こえないな。
マングリングだのABIだのが仕様上規定されている言語なんざ
そうは多くない。

39 ：デフォルトの名無しさん：2008/04/08(火) 15:13:49

>>38同意
だいたい、ライブラリをバイナリで落としてそのまま使える気がしない。
というか、それが問題なく使えることってあんのか？

ビルドに苦労することはよくあるけど、それは何の言語でも同じだろ。っていうか
それは言語とは関係ないし。

40 ：デフォルトの名無しさん：2008/04/08(火) 22:49:51

面白そうなタイトルに惹かれてきますた
C++から C には・・・もう戻れないに一票
>>3, >>5 に共感そのもの

>>9 そうかな？必要と感じるなら立ち上げたら？

>>13 ちょっと理解できない。オブジェクト指向では
object a, b, c;
add (&c, &a, &b) の表現ではなく
c = a + b; と記述できる処だよね。
add はそのまま operator + で同じような内容だし後は operator = だけでしょ。operator - がいるなら当然 sub も書くことになるんだから工数は何も変わらない。

>>16 というか領域・空間のチェックはしてない。そこがマニアックたる処だと思う。C は好きです。
overload は実行時に都度確定する部分だから細かく気にする人は精神的によくないかもね。

>>26 ばりばりに C++ してたら C には戻れんと思うが・・・
struct , class メンバー使い出したらそれだけでも C++ から C には戻れない。

>>36 中途半端なスタンスがいい。厳格なオブジェクト指向な実装が好きな人はそれを使えばいい。だけど C をカジってた人ならきっと窮屈に感じると思う。それにオブジェクト指向から手続き型には戻れんと思う。

41 ：デフォルトの名無しさん：2008/04/09(水) 00:04:29

>>40
オーバーロードの解決はコンパイル時だぞ。
オーバーライドとごっちゃにしていないか？

あと、演算子の件はoperator +=も用意するとか、
2つの型が関わる場合に、
operator +(T1 const&, int const&)と
operator +(int const&, T1 const&)のように
いくつも関数を作らないといけないということを言っているのだと思われる。

42 ：デフォルトの名無しさん：2008/04/09(水) 00:21:39

>>36
>低レベルの処理はCで、高級な処理はC++以外の言語でというのが理想。

俺もこれに一票。
DTrace とか使ってると C++ のマングリングが鬱陶しいし。

43 ：デフォルトの名無しさん：2008/04/09(水) 01:51:05

vectorとclassがあるって理由だけでC++使う。
Cに比べればstringがある分、文字列処理もましだし（それでもきついけどｗ）

44 ：デフォルトの名無しさん：2008/04/09(水) 15:11:53

>>40
> オブジェクト指向では
> object a, b, c;
> add (&c, &a, &b) の表現ではなく
> c = a + b; と記述できる処だよね。

演算子オーバーロードとオブジェクト指向は何の関係もないと思うが。
>>40はいろいろと微妙に分かってない罠。

45 ：デフォルトの名無しさん：2008/04/09(水) 20:50:20

C なんてもう組み込みとかよほど制限された環境じゃないと使う気しないわ。

46 ：デフォルトの名無しさん：2008/04/10(木) 00:42:15

>>41
だけど、それは C でも同じでは？
C なら型が違う毎に add1() add2() とするでしょし operator += が必要なら append() とかを書くことになるのでは？
後、メンバー関数が継承される時 virtual な扱いにいつされるかというところがあるとおもう。operator が別扱いではないですよね。

>>44
そうかな。関係ないのだろうか？
オブジェクトにメッセージを送るという感覚、これまでの add(a, b) ではなく独自の struct あるいは class な物にたとえば c = a + b という記述ができることであって、一例として挙げている演算子再定義にこだわり過ぎてない？

で、指摘の通りきっと微妙に判っていないんだとは思う。厳格なオブジェクト指向は触ったことないし神髄は未知の世界です。

47 ：デフォルトの名無しさん：2008/04/10(木) 00:58:13

>>46
ところが>>13も言っているが、Cだとわざわざappendなんて用意しないし、
複数の型がからむときも、41のoperator +のように
右辺と左辺が入れ替わっただけの関数なんて用意しない。

C++だってBoost.Operatorsでその点はばっちり解決できるんだけどな。

48 ：デフォルトの名無しさん：2008/04/10(木) 13:46:00

>>47Boost.Operatorsってメンバ関数以外もやってくれるんだっけ？　だとすごいす。

でも、Boost.Iterators使おうとしたとき、マニュアルとヘッダ読みながら何とか
コンパイルに成功したが、あの小一時間あれば自分でイテレータに必要なもの
全部書けるなとおもた。

あの手の実装補助は相当使いこなさないと、効果ないかも。

話逸れたけど、ここにはCマンセーの人はいないの？

49 ：デフォルトの名無しさん：2008/04/10(木) 18:46:43

>>48
でも、今から手続き型のスタイルにもどるって時代逆行では？
先輩方が手続き型で痛い目を見て、少しでもミス記述が防げるには？…と考えてきたと思うし・・

>>47
ごめん。どうもよくわからない。必要ない物を用意しないのは同じでは。 append が必要ないなら当然 operator += も必要ない。
そもそも operator += じゃなく C スタイルで append で何も不具合はないわけだし（コード書く人の気持ち一つ）

ところでここで C という人は C++ なメンバー関数であったりそういうのが本当にいらないって事を言ってるのだとしたら・・orz

50 ：デフォルトの名無しさん：2008/04/10(木) 20:40:47

>>49
そりゃそうなんだけど、現実は
Cのライブラリ：add 1つだけ
C++のライブラリ：operator +に+=、++全て勢揃い
となっていうことがなぜか多い。
（もちろんCでappendの実装が困難というわけではない）

51 ：デフォルトの名無しさん：2008/04/11(金) 15:03:09

Cの方がいいに決まってる

52 ：デフォルトの名無しさん：2008/04/11(金) 17:31:20

>>51
ｋｗｓｋ

53 ：デフォルトの名無しさん：2008/04/12(土) 05:19:11

>>48
一度しか使わないなら大抵の小物ライブラリがそうだよね。
何度も使うから効果を発揮するわけで。

54 ：デフォルトの名無しさん：2008/04/13(日) 00:57:09

ベクトルクラスを作ったとき、演算子を定義して
c = a + b とできるようにしたけど、
一時オブジェクトの生成がオーバーヘッドになって使えなかった。
add( vector &c, const vector &a, const vector &b ) にしてから全体の計算が
10秒から2.5秒まで落ちた。　正確なデータ、根拠じゃないけど速く感じたのは
事実だった。

オーバーロード自体はきらいじゃないけど、こういうときは無理にする必要は
ないよね。冷静に考えると自作クラスに演算子を用意するのって実は
限られている希ガス。（代入演算子はとか除いて）

ちなみに自分はC++派。上の関数をインラインにするだけでさらに速度アップするし。
あと、add_assign() とかも用意した。

55 ：デフォルトの名無しさん：2008/04/13(日) 01:16:23

お一人様、「式テンプレート→テンプレートメタプログラミング」コースごあんなーい

56 ：デフォルトの名無しさん：2008/04/13(日) 01:26:57

インライン関数は C でも大抵のコンパイラが対応してるんじゃないかな。

57 ：デフォルトの名無しさん：2008/04/13(日) 01:29:00

>>54
RVO が利用できるよう、演算結果を初期化で受けると
オーバーヘッドは減らせる。
あるいは c += a + b; みたいに使うとか。

58 ：デフォルトの名無しさん：2008/04/13(日) 01:33:47

そしてコンパイルする度にうんざりする…

59 ：デフォルトの名無しさん：2008/04/13(日) 22:13:42

>>54
それって何かが間違ってる。
add() が + () という名前に変わるだけ。
+ という関数名はそのまま使えないから operator でそうしてる。実際の呼び出しに差違が起こるのは・・何かが可笑しい。と思うが。

60 ：デフォルトの名無しさん：2008/04/13(日) 22:36:11

間違ってないよ。
+ 演算子は仕様上結果を戻り値で返す事しか出来ないからね。

61 ：デフォルトの名無しさん：2008/04/14(月) 02:34:50

ええとなんだ。ET使えよこの野郎とか煽ればいいのかな

62 ：デフォルトの名無しさん：2008/04/14(月) 18:09:44

そして>>13へ戻る。Cだとこんなに単純で済むのに、と。

63 ：デフォルトの名無しさん：2008/04/14(月) 20:08:20

ほぼスーパーセットとなってる言語と比べてどうすんだよ
いらないと思ったらその機能を使わなければいいだけ

64 ：デフォルトの名無しさん：2008/04/14(月) 20:37:23

何でも入れれば良いという思想に慣らされてしまっていれば
そう感じてもおかしくはないね

65 ：デフォルトの名無しさん：2008/04/15(火) 09:20:08

基本C言語
まあ組み込みなので

66 ：デフォルトの名無しさん：2008/04/24(木) 20:41:46

>>60
すまん。そのとおりだ。

67 ：デフォルトの名無しさん：2008/05/15(木) 14:02:26

C 言語にブロックの先頭以外で変数を宣言できる機能を追加すれば何とか我慢できる。
inline 関数の機能がなくても最適化できるのが理想だが、現実的にそれができるコン
パイラやリンカは少ないので inline を追加してほしい。
C99 は C++ との互換性に問題があるから使いたくない。

68 ：デフォルトの名無しさん：2008/05/15(木) 14:06:11

gccを機能制限しつつ使えばいいじゃん。

69 ：デフォルトの名無しさん：2008/05/15(木) 14:35:49

C++でそれだけ使って後はCとして書けばいいんじゃないの

70 ：デフォルトの名無しさん：2008/05/15(木) 14:40:24

>68
すみません。コンパイラは自分で選べないケースもあるんです。

71 ：デフォルトの名無しさん：2008/05/15(木) 14:48:19

>69
個人的にはそれを主張しているのですが、お客さんが C++ は絶対ダメって言うんです。

72 ：デフォルトの名無しさん：2008/05/15(木) 15:06:55

>>71
C++でないって言い張ればいいじゃない

73 ：デフォルトの名無しさん：2008/05/15(木) 16:45:44

その手がありますね。
顧客によっては MISRA-C などのソース検査を要求しますが。

74 ：デフォルトの名無しさん：2008/05/15(木) 17:43:36

スコープ内での変数宣言こそ簡潔なプログラムへの助け

75 ：デフォルトの名無しさん：2008/05/15(木) 19:52:28

C 言語用のライブラリを作るとき公開ヘッダー以外を C ではなく C++ で
実装した場合、ライブラリユーザー側のデメリットって何かありますか?

76 ：デフォルトの名無しさん：2008/05/15(木) 22:09:31

ライブラリ本体がC++だと、コンパイラ毎に
ライブラリのコンパイルが必要になるんじゃなかったっけ

77 ：デフォルトの名無しさん：2008/05/15(木) 23:03:40

newや例外など、C++用ライブラリを使う場合は>76の通り。
それらを使わなければ、巧く共存できる。

78 ：デフォルトの名無しさん：2008/05/16(金) 00:52:32

DLL だとスタティックライブラリで実装すれば外のライブラリの
影響を受けないんじゃないかな。.so の仕組みは少し違うのかな。

79 ：デフォルトの名無しさん：2008/05/16(金) 16:21:58

何でほとんどのオープンソースの C インタフェースのライブラリは
C++ で実装しないのかな。
Linux OS 自体の実装も C とアセンブラだけかな。

80 ：デフォルトの名無しさん：2008/05/16(金) 20:31:11

昔々隅々まで C++ で作られた BeOS という OS がありました。
今は Palm が買い取った筈だけど…

C++ だと C や他の言語から呼び出すのが面倒だから止めて欲しい。

81 ：デフォルトの名無しさん：2008/05/16(金) 23:17:45

C++ で実装していてもインタフェースが C のみなら問題ないんじゃない?

82 ：デフォルトの名無しさん：2008/06/19(木) 22:05:06

extern "C" がｳｾﾞｰの

83 ：デフォルトの名無しさん：2008/06/20(金) 13:16:21

C 用のライブラリのヘッダーファイルにも普通 extern "C" が入っているよ。

84 ：デフォルトの名無しさん：2009/01/27(火) 13:04:52

　名前空間、クラススコープ、オーバーロード。
　最低でもこの3つが無いとCに戻る気には慣れんなぁ。
オプソのCのコードやOpenGLのコードなんかを見れば分かるけど
手動名前空間で関数名がクソながかったり、関数名に型名が混在したり
名前が汚すぎる。人が用意したコードならともかく自分のコードであんな命名
規則を守りつづける気がしない。

85 ：デフォルトの名無しさん：2009/01/27(火) 16:16:39

>>84
テンプレート必要だろｊｋ

86 ：デフォルトの名無しさん：2009/01/28(水) 21:00:46

テンプレートよりデストラクタが欲しい。
参照カウントみたいなことを人間の手でやっていたら絶対どこかで間違うはず。

87 ：デフォルトの名無しさん：2009/02/01(日) 14:56:07

逆にC++の要らないところって何だろう

88 ：デフォルトの名無しさん：2009/02/01(日) 15:17:48

例外指定くらいな気がする

89 ：デフォルトの名無しさん：2009/02/01(日) 17:38:32

>>85
あくまで最低ラインだからねー。
テンプレートなら今でも不自由な環境あるじゃん。
そんなかんきょうでも、俺は>>84が満たされていればC++を選ぶ。
でも、>>84すら不自由なら流石に手を引くけどな(例：Embedded C++)

90 ：デフォルトの名無しさん：2009/03/19(木) 10:35:20

ねーよｗ

91 ：デフォルトの名無しさん：2009/06/10(水) 04:58:23

ttp://3f.ohne.co.jp/?p=poss

92 ：デフォルトの名無しさん：2009/10/11(日) 11:14:06

迷うような場面ではC

93 ：デフォルトの名無しさん：2009/10/14(水) 17:46:22

使いこなせるはずなのになんか使いこなせないC++
理由よくわかんないけどCのほうが早く作れる気がする
のろわれてんのか？

94 ：デフォルトの名無しさん：2010/02/25(木) 18:25:46

dll作ろうとするとC++はちょいめんどい

95 ：デフォルトの名無しさん：2010/02/27(土) 14:11:53

C++は機能や技法が多すぎて、ケースに合った最適な方法がすぐ思いつかなかったり、
最適な組み合わせが閃かなかったりする。

96 ：デフォルトの名無しさん：2010/03/09(火) 01:42:51

>>94
自分の場合、結局Cでも使える関数のエクスポートに落ち着いちゃう。

97 ：デフォルトの名無しさん：2010/03/09(火) 07:22:54

クラスのエクスポートも可能だけど
まあこのあたりは言語の話でいいのか微妙だな
所詮拡張機能だし

98 ：デフォルトの名無しさん：2010/05/26(水) 20:29:32

Cでも無理やりクラスっぽいことはできるけどメンドイね
ハンドルと関数を公開してC++用のヘッダにラッパー書くのが一番簡単かな

99 ：デフォルトの名無しさん：2011/01/11(火) 19:02:40

Linus TorvaldsがC++をメッタ斬り。
http://lwn.net/Articles/249460/

100 ：デフォルトの名無しさん：2011/01/11(火) 19:30:00

１００

101 ：デフォルトの名無しさん：2011/02/15(火) 22:47:30

>>99
それに対する反論。
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
http://slashdot.jp/~taro-nishino/journal/501622

102 ：デフォルトの名無しさん：2011/02/16(水) 03:49:28

効率に関しては、その反対が真実な場合（つまり、CよりもC++の方が効率を助長する）があることを私は思い切って主張したい。」以下は平均的Cプログラマによって作成され、人が見る典型的なコードだ。

    for(i = 0; i < strlen(line); i++)
    {
        ...
        doSomethingWith(line);
        ...
    }

そのようなことをするのは非常に非効率だ。ループの外で（特にdoSomethingWith関数がconstでないポインタを取るならば）
コンパイラはstrlenの最適化すら出来ないだろう（コンパイラは、その関数が文字列を変更するかどうか分からないからである）。

確かに、答えは"そのようなことをするな"だ。しかし、Cは初心者プログラマにそのようなコードをするのを助長している。
それが全く自然な考え方であるのだ。

今や、C++での自然な考え方により、同じことをC++ではどのようにするか比べよう。

    for(i = 0; i < line.length(); i++)
    {
        ...
        doSomethingWith(line);
        ...
    }

これはCバージョンと非常によく似ているが、ずっと効率的だ（std::string::length()はただメンバー変数の値を返し、
呼ばれる度に文字列の長さをカウントする必要が無いからである）。たとえ文字列がループ本体の中で変更されても
効率的であることに注意せよ。

103 ：デフォルトの名無しさん：2011/02/16(水) 03:56:27

>>102
> for(i = 0; i < strlen(line); i++)

そもそもこれが自然じゃないだろw
先に筋書きありきで、無理矢理こじつけ様とするからこうなる

104 ：デフォルトの名無しさん：2011/02/16(水) 09:29:22

>>103
そうか？実際けっこう見たことあるよ。
> 確かに、答えは"そのようなことをするな"だ。しかし、Cは初心者プログラマにそのようなコードをするのを助長している。
> それが全く自然な考え方であるのだ。

105 ：デフォルトの名無しさん：2011/02/16(水) 10:30:14

>>104
性能が重要な箇所で、loop の判定式の中で関数を使うなんて素人だろ
平均的 C++ が書く C のコードはこんなもんなのかもしれんが、
平均的 C プログラマはそんなコードは書かない

>>102 の論理はどう考えても無理筋

106 ：デフォルトの名無しさん：2011/02/16(水) 10:34:21

>>105
× 平均的 C++ が書く
○ 平均的 C++ プログラマが書く

失敬した。

107 ：デフォルトの名無しさん：2011/02/16(水) 10:37:59

>>105
だから、素人の話をしてるんだよ。
> しかし、Cは初心者プログラマにそのようなコードをするのを助長している。

108 ：デフォルトの名無しさん：2011/02/16(水) 10:39:32

>>107
> 以下は平均的Cプログラマによって作成され、
> 以下は平均的Cプログラマによって作成され、
> 以下は平均的Cプログラマによって作成され、

109 ：デフォルトの名無しさん：2011/02/16(水) 10:42:46

つか、わざわざプロパティアクセスと関数呼び出しを比較するなんて
>>102 は相当 Linus が嫌いなんだろうなw

普通に考えたら >>102 は無いわ

110 ：デフォルトの名無しさん：2011/02/16(水) 10:48:29

>>108
あ、そこに引っかかってるのか。「平均的」っていうのは個人の経験で揺れちゃうんで、
確かにそこがおかしく見えることもあるだろうな。

>>109 の「普通」も同様。

111 ：デフォルトの名無しさん：2011/02/16(水) 10:51:31

template の魅力。チマチマやると効くからなあ。

112 ：デフォルトの名無しさん：2011/02/16(水) 11:41:12

>>110
> そこに引っかかってるのか
> 個人の経験で振れちゃうんで

ﾜﾗﾀw
今度は「貴方の勘違いです」作戦ですか?
理屈も糞も無いなw

俺は素直さが美徳の世界に戻るわ

113 ：デフォルトの名無しさん：2011/02/16(水) 11:50:19

>>112
いや、勘違いだなんて言ったつもりはないよ。
筆者にとっては正しくて、あんたにとっては正しくない。それだけのこと。

114 ：デフォルトの名無しさん：2011/02/16(水) 17:04:42

テンプレートでソースコードと実装の乖離が激しくなるのは確か。

115 ：デフォルトの名無しさん：2011/02/16(水) 17:16:45

つまり筆者は素人衆のお山の大将だったわけか

116 ：デフォルトの名無しさん：2011/02/16(水) 22:42:30

っていうか、ほかにフォローするところはないのかね？
>>102 はいちばん突っ込みやすそうなところを晒し上げしただけだろ。

117 ：デフォルトの名無しさん：2011/02/17(木) 05:10:15

そうは言っても、そのほかにもCの悪い例としてgetsをあげてたり
(getsがセキュアでないのはCプログラマなら常識で、普通使わないし、使われていない）
仮想しているCプログラマのレベルが低すぎる。

118 ：デフォルトの名無しさん：2011/02/17(木) 07:50:33

いやいや。「 Linus の主張にはほとんど根拠が無く出鱈目である」という点に反論はないのか、と。

119 ：デフォルトの名無しさん：2011/02/17(木) 10:22:53

C++ PG : 「見てみてー、C++ が C より優れているケースを（無理矢理）見つけたよー！」
C PG : 「そんな糞コード書くかよw」

120 ：デフォルトの名無しさん：2011/02/17(木) 11:32:06

醤油うこと

121 ：デフォルトの名無しさん：2011/02/17(木) 13:43:13

>>118 Linusの主張で唯一根拠が無いのが
「C++は多くの平均以下のプログラマが使っている」
って点だが、それすらも >>101 のリンク先の反論の
あまりのヘボさによって例示されてしまっている。

122 ：デフォルトの名無しさん：2011/02/17(木) 14:30:39

計らずも証明されてしまったな

123 ：デフォルトの名無しさん：2011/02/18(金) 00:43:04

>>121
> Linusの主張で唯一根拠が無いのが

リンク先の記事では「まともな根本を持っているのは唯一つである」とされていて、
それは「STLデータコンテナを使えば、一部の古いC++コンパイラがサポートしていない場合がある」という点
だけみたいなんだけど、他の点には根拠があると言えるの？

124 ：デフォルトの名無しさん：2011/02/18(金) 01:11:46

C++ PG : 「C++ には C の仕様も入ってるから、俺ら C のエキスパートでもあるんスよ」
C PG : 「お前、普段バイクに乗ってる人間が、自転車でも速く走れると思ってるのか?」

125 ：デフォルトの名無しさん：2011/02/18(金) 02:21:17

>>123 テンプレート、特にBoostでエラーが発生したときの
デバッグが苦痛なのも（何あのエラーメッセージ？）、
C++で良いとされるプログラミングパラダイムがころころ代わるのも
（昔は継承使うのが良いとか言ってませんでしたっけ？）、
事実だろ？

126 ：デフォルトの名無しさん：2011/02/18(金) 02:52:44

納得しないの荒行に入ってる人を説得するのは至難の業だと思われ
説得出来た所で何の益も無いし

127 ：デフォルトの名無しさん：2011/02/18(金) 03:53:23

グローバル変数はローカル変数より色んな場所から
アクセスできて高機能、だからグローバル変数を使おう
とか言ってたら頭オカシイと思うだろ？

それと同様に、C++はCの仕様を全て含んでいるから
Cより悪いはずが無い、って主張は愚かすぎる。
言語仕様だって適切に制限されているべきなんだよ。

128 ：デフォルトの名無しさん：2011/02/18(金) 08:10:47

Obj-CはCの仕様を全て含んでいるから Cより悪いはずが無いけどな。

129 ：デフォルトの名無しさん：2011/02/18(金) 08:25:56

LinusはLinusでカーネルやデバドラとかそういうの書く場合の経験で
語ってて、突っ込み入れる外野はもっと緩い作業を想定してるのが
モメてる根本だろ？

130 ：デフォルトの名無しさん：2011/02/18(金) 09:18:48

>>129
カーネルやデバイスドライバだと C++ を使わない理由が出てくると思ってるなら、
何か C++ について勘違いしている可能性が高い。

件の反論にも同様の指摘がある。
> 彼はまた、C++コーダーは"低レベル問題を理解"出来ないと主張する。 ...

どんな理由でそれらに C++ が適さないと思ってるの？

131 ：デフォルトの名無しさん：2011/02/18(金) 09:21:53

C++ PG : 「C ってアレっスよね、オブジェクト指向とかする時 GObject ってのを使うんですっけ?」
C PG : 「オブジェクト指向的に書きたい時は素直に Java か ObjC を使うだろ・・・」

132 ：デフォルトの名無しさん：2011/02/18(金) 09:37:17

>>125
それは事実だが、 C で同等のことをより適切なエラーメッセージを得ながら
できるわけじゃないでしょ？（マクロでやればもっとエラーは不可解になる。）

そもそも Linus はそんなこと主張してないし、反論でもそれを否定するような
主張はしていないし、誰もそんな話はしていない。

133 ：132：2011/02/18(金) 09:48:41

あ、ごめん Linus の主張にはあるのか。
> - infinite amounts of pain when they don't work (and anybody who tells me that STL
> and especially Boost are stable and portable is just so full of BS that it's not even funny)
> - inefficient abstracted programming models where two years down the road

忘れて。

134 ：デフォルトの名無しさん：2011/02/18(金) 10:17:48

C++ PG : 「あ、C ってテンプレート無いんでしたっけw」
C PG : 「テンプレートで頑張るとエラーメッセージが理解不能になるし、コンパイルが劇的に遅くなるって君が教えてくれたんじゃん・・・」

135 ：デフォルトの名無しさん：2011/02/18(金) 10:25:11

>> 130 使用するスタックサイズとかにまで
気を使いながらカーネル書いてるCプログラマに、
「デストラクタでRAIIすれば資源管理も楽勝っすよw」
なんてレベルのC++プログラマが話しかけてきたら、
あっち行けって言いたくもなるよ。

136 ：デフォルトの名無しさん：2011/02/18(金) 10:54:32

>>130
レスポンスタイムにシビアな制限のあるデバイスドライバでSTLコンテナ使う場合とか？
コンテナ自体の速度がどうしても間に合ってない→結局自作→なら最初から自作でいいだろ
みたいな流れで。

137 ：デフォルトの名無しさん：2011/02/18(金) 10:59:37

>>135
なんで RAII がスタックサイズに関係すると思ってるの？

138 ：デフォルトの名無しさん：2011/02/18(金) 11:01:33

>>136
標準コンテナの何が速度低下に関係するの？

百歩譲って、コンテナの自作が「どうしても間に合わないとき」に
限定されるんならそれだけでも十分役に立ってるじゃないか。

139 ：デフォルトの名無しさん：2011/02/18(金) 11:28:32

>>138
じゃあLinusは時代遅れの老害だからアホな事ほざいてるだけなの？

140 ：デフォルトの名無しさん：2011/02/18(金) 11:34:03

>>102
これは、単に、Cで普通に使われる文字列はヌル文字の番兵で終端を表しているだけで
自分の長さを知らないデータ構造なので、
文字列長を知るにはいちいちO(n)のstrlen()を利用する必要があり
それ自体が非効率な仕組みだ、と言えばよかったのにな

まともなCプログラマならそれを知っているから、ループの中でstrlen()を呼んで
いちいちO(n)をO(n^2)に悪化するようなことはしない
もっともいずれにせよstrlen()は必要で、その時点で既に非効率なわけだが

勿論Cで文字列長を自分で保持する構造を書くことは勿論できるけど
C++でも標準ライブラリを捨てていくらでも自分で書けるわけで

C++の標準ライブラリやboostを攻撃するのなら、Cのgets()やstrlen()が
攻撃されるのも理解しなきゃな
「使わなければいい」というのなら、C++のSTLだって、使わなきゃいいだけなんだ

141 ：デフォルトの名無しさん：2011/02/18(金) 11:34:18

>>137 そりゃ、オブジェクトをスタックに積んで、
スタックが巻き戻るときに自動的に呼ばれるデストラクタで
資源解放するのがRAIIだからだろ。
それとも資源管理を明示的に書くのをサボるためだけに
スマートポインタを使うのか？スマポだって生ポインタよりは
スタック消費するぞ。

142 ：デフォルトの名無しさん：2011/02/18(金) 11:38:21

>>141
scoped_ptrはきっかり生ポインタと同じだけしか領域を消費しませんよ
もちろん、多機能なshared_ptrならもっとオーバーヘッドがあるけど
やりたいことが単なるRAIIで、スタックに積むかわりなら
scoped_ptrで十分でしょう

143 ：デフォルトの名無しさん：2011/02/18(金) 12:56:01

>>142 書き込んだときは、スマポ自体のサイズと、
スマポのデストラクタ -> オブジェクトのデストラクタ
の二段階呼び出しのスタック消費の両方を念頭に置いてたんだ。

でも、少なくとも前者は scoped_ptr があるし、
後者も最適化で消せるみたいだ。
完全にこっちの見識不足だった。

144 ：デフォルトの名無しさん：2011/02/19(土) 01:57:30

>>139
その言い方はちょっと違うな。老害ってやつじゃない。
C を使ってる分にはすごく優秀なプログラマと見て間違いないはず。

>>101 のリンク先の言葉を借りれば、「Cハッカー症候群」 "C-hacker syndrome" 。
症例はこのスレにたくさん挙がっている。

145 ：デフォルトの名無しさん：2011/02/19(土) 07:13:00

>>140
>自分の長さを知らないデータ構造なので、
>文字列長を知るにはいちいちO(n)のstrlen()を利用する必要があり
>それ自体が非効率な仕組みだ、と言えばよかったのにな

無知でｽﾏｿ。
C++ の文字列も結局は内部でひっそりと文字数をカウントしているんだよね?
それは strlen() を使うのと計算量が大幅に異なる様なデータ構造になってるの?

146 ：デフォルトの名無しさん：2011/02/19(土) 08:06:40

それは strlen() を使うのと計算量が大幅に異なる様なデータ構造になってるの。

147 ：デフォルトの名無しさん：2011/02/19(土) 08:16:43

具体的にはどういうの?

148 ：デフォルトの名無しさん：2011/02/19(土) 08:26:35

_M_length

149 ：デフォルトの名無しさん：2011/02/19(土) 08:37:48

>>145
変数で文字数を保持してる

150 ：デフォルトの名無しさん：2011/02/19(土) 08:37:59

それじゃ分からん

151 ：デフォルトの名無しさん：2011/02/19(土) 08:38:50

oops
>>150 は >>148 だった

>>149
誰が文字数を変数に格納するの?

152 ：デフォルトの名無しさん：2011/02/19(土) 08:50:09

クラスが

153 ：デフォルトの名無しさん：2011/02/19(土) 09:14:26

Cのノリで直接バッファ操作したりしないからな

154 ：デフォルトの名無しさん：2011/02/19(土) 09:20:22

>>152
それって結局内部的に計算してるってことだよね?

155 ：デフォルトの名無しさん：2011/02/19(土) 09:24:39

小学生みたいだな。

156 ：デフォルトの名無しさん：2011/02/19(土) 09:26:17

きちんと答えてくれないから、どんどん質問のレベルを下げて行ってます

157 ：デフォルトの名無しさん：2011/02/19(土) 09:29:06

例えばさ、固定幅のバッファを数珠つなぎにして一つの文字列にしてるから
文字数のカウントが速いんだとか、そういった分かり易いシンプルな説明って無いの?

158 ：デフォルトの名無しさん：2011/02/19(土) 09:41:01

つーか、本気で誰も答えられなくてﾜﾗﾀw
午後の部を待つか・・・

159 ：デフォルトの名無しさん：2011/02/19(土) 09:53:30

単に文字列長用のスロットがあるだけなら Pascal の文字列と一緒だよね

160 ：デフォルトの名無しさん：2011/02/19(土) 11:28:50

>>157
string同士の操作はお互いに文字数が分かってるのでカウントしなおさない。
const char* が含まれる場合は1回だけstrlen相当の処理が使われる。

161 ：デフォルトの名無しさん：2011/02/19(土) 15:41:49

>>160
どうもありがとう。
文字列のコピーや連結の時にショートカットが出来ると言う事かな。
それだけの事であれば、文字列長のカウントがホットスポットになった場合に、
C で同じ様な実装をするのは雑作無い事だよね。

ある文字列の先頭の 5 文字を除いた文字列を関数に渡したいと言った時に、
C ならポインタを 5 文字分だけずらして渡してあげればいいだけだけど、
C++ の文字列では、文字数情報を記憶しないといけないので、わざわざ
substr() みたいな関数呼び出しにしないといけないんだよね?

こっちのオーバーヘッドの方が無駄じゃないの?

162 ：デフォルトの名無しさん：2011/02/19(土) 16:16:54

const char*を返すc_str()というメンバがあるから、読み取りのみでいいなら
string.c_str() + 5 とかで渡せる。(ちゃんとnullストップになってる。)
挿入したい場合は挿入用のメンバ関数がある。

163 ：デフォルトの名無しさん：2011/02/19(土) 16:20:57

自分には良く分からない・知らないものを
単に良く分からないから嫌っているってだけのことが
＊非常に＊多いのがこのスレを見ていても良く分かるね

よく分かっている道具を使うのは間違いじゃないし正しい態度でもあるが、
よく知らないものを知らないくせにdisるのはバカのやることだな

164 ：デフォルトの名無しさん：2011/02/19(土) 16:29:03

>>162
その関数が C の文字列を受け取る関数ならその通りだけど、
C++ string を受け取る関数なら、やはり何らかの事前処理が
必要になるよね

>>163
俺はこれが気になったから質問してるだけだよ

>これは、単に、Cで普通に使われる文字列はヌル文字の番兵で終端を表しているだけで
>自分の長さを知らないデータ構造なので、
>文字列長を知るにはいちいちO(n)のstrlen()を利用する必要があり
>それ自体が非効率な仕組みだ、と言えばよかったのにな

C++ の文字列って C の文字列を dis れる程、効率的な物
なのか知りたくなってね

165 ：デフォルトの名無しさん：2011/02/19(土) 16:33:12

>>164
効率が気になるなら試せよ。

166 ：デフォルトの名無しさん：2011/02/19(土) 16:36:37

＞C の文字列を dis れる程、効率的な物なのか

そんな良い物ではないよｗ
for内でstrlen使っちゃうような、うっかり八兵衛には効率的なのかもしれないが。

167 ：デフォルトの名無しさん：2011/02/19(土) 16:37:09

>>165
>>140 がああまで言う理屈が分からないと、テストパターンも作れないでしょ

168 ：デフォルトの名無しさん：2011/02/19(土) 16:40:28

＞C++ string を受け取る関数なら、やはり何らかの事前処理が

だから挿入用や上書き用のメンバも何種類もある。
何文字目から始める&終わるか引数で渡せる。
Cのポインタみたいなノリで書きたい場合は、イテレータという物もある。

169 ：デフォルトの名無しさん：2011/02/19(土) 16:41:10

まぁ、substr()のコストを払ってでも足し算オペレータで連結できる魅力に勝てない人もいるわけで。
要は、適材適所なんだからどの方式も一概に否定したもんじゃないさ。

170 ：デフォルトの名無しさん：2011/02/19(土) 16:46:30

>>166
ありがとう。やっぱりそうなんですね。
C++ が実行効率に神経を注いでるのは聞いていたので、
何かいい仕組みがあるのかもと期待しちゃいました。

>>168
今していたのは C++ と C の文字列の計算量の話
その何種類もあるメンバも内部的に計算してるわけでしょ
そしたらその分の計算量が発生するでしょ
繰り返しになるから、これ以上は説明しませんので、
お願いします・・・

171 ：デフォルトの名無しさん：2011/02/19(土) 16:47:04

C++ で C っぽく書けるけど、
C で C++ っぽくは書けないお。

C++ だからって string を使わにゃならんわけじゃなし。

172 ：デフォルトの名無しさん：2011/02/19(土) 16:49:15

C++のsubstr()がO(n)なのはその通り
ただし、>>168の言っているように、C++では本当にジェネリックなアルゴリズムとして
記述する場合はSTLのようにテンプレートとiteratorが使われる
この場合は本質的に効率はポインタと同等でありながら、データ構造の内部表現を
問わない
charのストリーム、charのリスト、charの配列、stringを全く同じテンプレート関数に
適用できるということだ
Cならアダプタか、別々の実装を書く必要があるだろうな

また、特にstringで受ける必要が無い関数なら、C++であってもconst char *
もよく使われるよ

173 ：デフォルトの名無しさん：2011/02/19(土) 16:52:07

>>171
文字数のみを考えるなら、こんな感じの構造体と
それを操作する関数を用意してあげれば良いだけ

typedef struct { int len; char str[] } string;

174 ：デフォルトの名無しさん：2011/02/19(土) 16:52:59

>>164
ある std::string から先頭 5 文字を取り除いたものを std::string として渡すんなら、
substr() するか先頭を erase() したものを渡すことになる。そんなに効率的じゃない。

でもこれを以って「やっぱり C のほうがいい」なんてことにはならないでしょ？
先頭 5 文字削るのは直感的で効率のいいコードになるけど、後ろ 5 文字削るとか
途中 5 文字削るとか、ちょっとした違いでコードも効率も全然違ったものになってしまう
のは理不尽だよ。

ちなみに、そういう処理を効率的にするためのものとして、標準じゃないけど
StringPiece ってのがあったりする。
http://d.hatena.ne.jp/shinichiro_h/20100823
> http://src.chromium.org/viewvc/chrome/trunk/src/base/string_piece.h
C で同様の機能のライブラリを作ることもできるだろうけど、これより良いものには
できないでしょ。

175 ：デフォルトの名無しさん：2011/02/19(土) 16:53:29

>>170
ポインタ+位置差分の加算等のことを言ってるのなら、
イテレータでポインタライクに操作できるんだって。
先頭の位置は変数(ポインタ)で保持される。

176 ：デフォルトの名無しさん：2011/02/19(土) 16:55:47

>>173
CではC++と違ってカプセル化によってデータ構造の整合性が常に保たれることを
保障することが難しい
Cでカプセル化したければ、opaqueポインタ経由でユーザにアクセスさせるように
してデータ構造を隠すしかないが、stringクラス的な用途ではそうするのは非効率だ

この辺も、Cでパスカル文字列が採用されなかった理由のひとつだろうと思う
ただの創造だが

177 ：デフォルトの名無しさん：2011/02/19(土) 16:56:29

>>173
うんそういうこと。でもそれを全ての文字列操作関数に対応させたり、
さらには非標準の文字列操作ライブラリにも広く対応させたり
自分の力だけでやるのは大変でしょ？
そういう標準化、規格化として意味があるわけです。

178 ：デフォルトの名無しさん：2011/02/19(土) 16:56:45

>>175
関数に渡す文字列の話だよ?

179 ：デフォルトの名無しさん：2011/02/19(土) 16:58:39

>>178
だから、関数が「stringで受けるように作ってあれば」
部分文字列を渡したければsubstrを使う必要があり、それがO(n)なのはその通り

だが、C++で関数をそう作る必要はどこにもない
iteratorで受けてもポインタで受けてもいい
要求に応じて適した選択が選べるということ

180 ：デフォルトの名無しさん：2011/02/19(土) 17:01:08

>>174
C の方が良いと主張したいわけじゃないです。
C++ の文字列の方が優れているという人がいたので、
それは誤解じゃないの? と聞いてみた次第です。。。

181 ：デフォルトの名無しさん：2011/02/19(土) 17:02:51

>>179
自分で作る関数に付いては、もちろんその場で一番効率が良い実装をするのが
当たり前だと思います

182 ：デフォルトの名無しさん：2011/02/19(土) 17:06:53

>>180
標準の文字列型として、所有権・寿命の管理を気にしなくても使えるようにするのが主目的だから、
効率だけ見てどっちが優れているかを考えるのは不毛なこと。

その中でも、文字列を変更しない間に繰り返し長さを得る場合には std::string のほうが効率的な
「こともある」と挙げているのが元の記事。はじめから、すべての場合で効率的であると主張して
いたわけじゃない。

183 ：デフォルトの名無しさん：2011/02/19(土) 17:08:53

まあぶっちゃけ「平均的な」プログラマが、それぞれの言語で「平均的な」コードを
書けば大抵Cのほうが速いだろうけどな
重要な違いが出るかどうかはともかく

ただまあ、明らかにC++のが速いことが分かってるものもいくつかある
qsort()に対するstd::sort()とか

184 ：デフォルトの名無しさん：2011/02/19(土) 17:17:59

配列には先頭も終端もないし長さを調べる方法もない
と思ったほうが楽なこともある

ないよりはあるほうがいい場合もあるが、すべての場合ではない

185 ：デフォルトの名無しさん：2011/02/19(土) 17:19:30

それは配列ではなくてポインタだろう

186 ：デフォルトの名無しさん：2011/02/19(土) 17:36:30

配列ではないが配列のインタフェースかもしれない

187 ：デフォルトの名無しさん：2011/02/19(土) 17:44:28

速度が必要な内部処理のようなところではcnost char *で、
設定ファイルを読み書きするようなところではstd::stringで、
必要なら外部の正規表現ライブラリでもなんでも使って、
こういう風に選択できるところがC++のいいところなんだってば。

ちょっとしたテキストビューワが必要なときに、テキストエディタで要求されるような
行単位のリスト構造を一一作らないときがすまないようなロートルCプログラマには
理解し難いことなのかもしれないけれど。

188 ：デフォルトの名無しさん：2011/02/19(土) 17:46:49

そういう時は ObjC を使う
GC もあるし GUI も完備

189 ：デフォルトの名無しさん：2011/02/19(土) 20:01:17.96

>>187
Cで書かなきゃならん部分だけCで書いて、
それ意外の部分はshなりPerlなりPythonなりで
書くのがCプログラマなんで、その指摘は的外れかと。
C++プログラマはC++の中だけで機能を選択するが、
Cプログラマは言語の枠を超えて機能を選ぶ。

190 ：デフォルトの名無しさん：2011/02/19(土) 20:08:05.79

>>189
なんで C++ プログラマは「shなりPerlなりPythonなり」を使わないと思ってるの？

191 ：デフォルトの名無しさん：2011/02/19(土) 20:10:24.84

C++ だって Perl なり Python なりでそうすることはできるけど、
C で 187 みたいなことできるの?

192 ：デフォルトの名無しさん：2011/02/19(土) 20:11:15.88

>>190
ロートルだからじゃね?

193 ：デフォルトの名無しさん：2011/02/19(土) 20:15:44.66

まぁC++の方が色々できるし便利だけど、道路が多い街が住み安いとは限らないよな。
慣れるまで大変で。

194 ：デフォルトの名無しさん：2011/02/19(土) 20:38:32.19

言語の枠というか、型の枠をぶち壊す選択をしやすいのはどっちかというとCだな

195 ：デフォルトの名無しさん：2011/02/20(日) 00:38:01.75

要はターミネーターはT-800かT-1000かって話してんの？

196 ：デフォルトの名無しさん：2011/02/20(日) 04:15:04.36

>>164
実装読めよ馬鹿。

197 ：デフォルトの名無しさん：2011/02/20(日) 04:17:12.61

日曜の早朝から無駄な煽りご苦労様です～

198 ：デフォルトの名無しさん：2011/02/20(日) 08:37:19.59

>>190
C++でCに追加された構文的拡張は、
それらの言語ではより良く（より簡潔に、またはより一貫性のある形で）
実装されているので、それらの言語も使える場合
C++を使う理由は実行速度くらいしかない
(Cと併用できるならそれすら無い）

199 ：デフォルトの名無しさん：2011/02/20(日) 08:54:53.51

使用言語が増えれば増えるほどコンパイラの新Ver追ったりライブラリ追ったり
手間は増えると思うんだ。

200 ：デフォルトの名無しさん：2011/02/20(日) 08:56:54.71

一つの言語だけを追い掛けてるプログラマも珍しいでしょ
2、3個の言語を組み合わせる程度なら追加の手間はないと思うよ

201 ：デフォルトの名無しさん：2011/02/20(日) 09:10:11.44

各コンパイラ、version毎のtemplateの対応状況を
把握する手間に比べれば、どってことないよな。

202 ：デフォルトの名無しさん：2011/02/20(日) 09:17:05.83

2、3個がっやっぱ限度なんだな

203 ：デフォルトの名無しさん：2011/02/20(日) 09:19:43.21

5,6個も組み合わせる必要ないからな。

204 ：デフォルトの名無しさん：2011/02/20(日) 09:24:58.92

Linusの場合C+ASMが確定なので、あと1枠か。

205 ：デフォルトの名無しさん：2011/02/20(日) 09:43:01.17

Linusは古参ハッカーなんで、三つ目はPerlじゃないかな。

206 ：デフォルトの名無しさん：2011/02/20(日) 11:45:57.19

>>198
え？
>189 にある「Cで書かなきゃならん部分」ってのも実行速度が欲しいところぐらいじゃないの？
他になんかある？あったとしてもC++では書けない、なんてことあるの？

207 ：デフォルトの名無しさん：2011/02/20(日) 14:50:52.10

C++ PG : 「C ってアレでしょ、まだバッファオーバーフローする関数とか使ってるんでしょ」
C PG : 「gets() の事ならもうずっと誰も使っていないし、2012 年に予定されている次の仕様で削除される予定だぞ」

208 ：デフォルトの名無しさん：2011/02/20(日) 18:24:03.29

>>206
このスレッドを読んできて、それでも「書けるか書けないか」
が争点だと思えるなら理解力が無さすぎる。
CのほぼスーパーセットのC++で書けないなんてことが
あるわけないだろ。

問題点になっているのは、いわば「読みやすさ」。

209 ：デフォルトの名無しさん：2011/02/20(日) 18:42:39.03

>>208
なんで C++ で書くと読みやすさが損なわれると思ってるの？

210 ：デフォルトの名無しさん：2011/02/20(日) 18:48:15.29

「読みやすさ」の定義は
ロートルの人が読めるかどうかです

211 ：デフォルトの名無しさん：2011/02/20(日) 19:03:36.83

そりゃ読めない文字とか知らない言い回しとか使われたら、普通は読みにくいとういうか読めないわな。

212 ：デフォルトの名無しさん：2011/02/20(日) 19:21:18.05

>>209
その時々で流行のパラダイム(OOPとか)をサポートする
構文糖が節操無く追加された結果、言語のデザインに一貫性が無い。

一貫性が無いから、構文糖がどのような暗黙的コードを生成するかは
単純に暗記するしかなく、さらに複数の異なる暗黙的コードの相互作用が
様々な罠を張ってて、簡単に自分の足を打ち抜けるようになってる。
ただ罠を避けるためだけの本（Effective C++とか）が必読本の時点で
何かおかしいと感じるべき。

こんな言語が読みやすいというなら、読みやすさは
プログラミング言語の評価基準にならないよ。

213 ：デフォルトの名無しさん：2011/02/20(日) 19:33:01.14

C だって自分の首を締める方法は残されてる。しかも不様に。

まあ、確かに C++ は罠が多いけど
ヤバい所は使わずに美味しいところだけ使うこともできる。
C は、できないよね。

214 ：デフォルトの名無しさん：2011/02/20(日) 19:37:40.43

無様さでは C++ には勝てないよなあ
純粋仮想関数が = 0 って糞ﾜﾗﾀw

215 ：デフォルトの名無しさん：2011/02/20(日) 19:44:11.93

さらに言えば、Cはコードの一部分を読むだけで
そのコードがどう実行されるかが比較的判りやすい言語だ。
もちろんマクロやグローバル変数等を使ってそうじゃなくすることも可能だけど、
そういうコードは「悪いコード」だとする文化がある。

一方、C++はコードをより広いコンテクストに依存させる構文糖
を積極的に追加する上に、どういうコードが良いコードか
（例えば、ある構文糖をどういう場合に「使わない」かについて）
の文化すら存在しないので、あるコードが何をしているか把握するのに
ずっと多くのコードを読まなきゃいけない。

だからC++は読み難いんだよ。

216 ：デフォルトの名無しさん：2011/02/20(日) 19:45:12.14

コンパイルも糞遅いしな

217 ：デフォルトの名無しさん：2011/02/20(日) 19:48:48.72

>>212
Cだって正しく使おうと思ったら暗記しないといけないことは山ほどある。
未定義動作とか副作用完了点とか。 C FAQ にいろいろ載ってるよね。

> 複数の異なる暗黙的コードの相互作用が様々な罠を張ってて

これは、なんのことだろう？ひとつでも例を挙げてみてもらえないか？

218 ：デフォルトの名無しさん：2011/02/20(日) 19:50:33.20

>>215
> もちろんマクロやグローバル変数等を使ってそうじゃなくすることも可能だけど、
> そういうコードは「悪いコード」だとする文化がある。

なんで C++ だとそんなのが受け入れられると思ってるの？

219 ：デフォルトの名無しさん：2011/02/20(日) 19:51:35.89

何でなんでって、質問ばっかだなw

220 ：デフォルトの名無しさん：2011/02/20(日) 19:53:33.87

議題について根拠も挙げずに断じるような書き込みをすればそうなるだろ。

221 ：デフォルトの名無しさん：2011/02/20(日) 19:54:45.80

相手が嫌になって折れるまで質問を続ける気だろうなあ

222 ：デフォルトの名無しさん：2011/02/20(日) 19:59:12.96

>>217
例えば、コンストラクタの中から例外を出すと
デストラクタが呼ばれないから、
常にデストラクタが呼ばれる、という前提でプログラムを書くと
リークしちゃう、とか。

じゃあコンストラクタでは例外送出しなきゃいいんじゃね？と思うと
コピーコンストラクタでのエラーは例外じゃなきゃ拾えないし、とか
どんだけ落とし穴掘ってれば気が済むんだよ。

223 ：デフォルトの名無しさん：2011/02/20(日) 20:06:42.84

C プログラマは普通で
C++ プログラマは経験の浅いやつって
前提があるみたいだな

224 ：デフォルトの名無しさん：2011/02/20(日) 20:11:25.78

相互作用の原因は三つある
継承と例外とコンストラクタだ

225 ：デフォルトの名無しさん：2011/02/20(日) 20:15:33.58

>>223
C にしろ C++ にしろ、言語のダメな所が認められないプログラマはまずいよな

226 ：デフォルトの名無しさん：2011/02/20(日) 20:21:31.86

それは当然だな

それの説明に妙な前提があるのがおかしいんだよ

227 ：デフォルトの名無しさん：2011/02/20(日) 20:23:05.31

>>222
「コンストラクタの完了でオブジェクトの構築完了」っていうオブジェクトモデルを把握すれば
自然なことなんだけどね。

FAQ にも載ってる。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.10

日本語で充実した FAQ が無いのが悪いんかな？

228 ：デフォルトの名無しさん：2011/02/20(日) 20:24:04.23

>>226
前に挙がっていた例では、C++ を支持している人は C については素人っぽかったよ

229 ：デフォルトの名無しさん：2011/02/20(日) 20:24:06.05

>>224
× 相互作用の原因は三つある
○ 俺の良く知らない機能が三つある

230 ：デフォルトの名無しさん：2011/02/20(日) 20:27:03.07

把握したところで煩雑な処理が解消されるわけじゃないなら言語の問題だわな。
どっちの言語がどうという訳ではないが。

231 ：デフォルトの名無しさん：2011/02/20(日) 21:26:39.59

>>217
Cの副作用完了点について知らないなら、
C++で&&とかの演算子オーバーロードが
何故禁じ手か絶対理解できないな。

しかもショートサーキットの概念は特定の言語に
依存しない一般的なものだけど、&&とかがオーバーロードで
副作用の仕方が変わるのは"たまたま"演算子オーバーロードが
関数に変換されるというC++固有の性質だから。

つーか、流石にその程度なら皆正しく使えてるだろ。

未定義動作、特に整数オーバーフローとかCにも難しい罠が
あるのは否定しない。

232 ：デフォルトの名無しさん：2011/02/20(日) 21:52:40.83

>>229
単純な原因から複雑な結果が生じているのだから
原因を良く知らないから悪いとか、原因を良く知れば解決するという問題ではない。

233 ：デフォルトの名無しさん：2011/02/20(日) 21:57:37.75

>>232 つまり、何が問題なんだってばよ？

234 ：デフォルトの名無しさん：2011/02/20(日) 22:26:05.05

例えばswitchでbreakが書かれていない場合
通常書くものが書かれていない場合はコメントを書く。
そういうパターンを整理すれば良いような気がする。

C++には、何も書かなくても自動的に処理する機能が多いが
その機能を使わないから何も書かなかったのか、
使うから何も書かなかったのか分からない。

235 ：デフォルトの名無しさん：2011/02/20(日) 22:33:36.08

>>234
> C++には、何も書かなくても自動的に処理する機能が多いが

具体的に。

236 ：デフォルトの名無しさん：2011/02/21(月) 08:52:00.83

＞ヤバい所は使わずに美味しいところだけ使うこともできる。

フグかよと

237 ：デフォルトの名無しさん：2011/02/21(月) 09:19:11.05

>>233
例えば、仮想関数もデフォルト引数も、共にどうってことない
判りやすい概念だが、C++で両方同時に使うと
仮想関数自体は動的型で呼び出し先が決まるのに、
デフォルト引数は静的型で解決される、という
悪意を疑いたくなる罠が存在する。

これも個々は単純だが、結果が複雑な例だな。

238 ：デフォルトの名無しさん：2011/02/22(火) 12:40:27.23

>>237
うーん。個人的にはあたりまえに思うんだけど、慣れちゃってるからなんだろうなー。

239 ：デフォルトの名無しさん：2011/02/22(火) 13:45:14.46

もっと酷い罠があるからなあ。

240 ：デフォルトの名無しさん：2011/02/22(火) 15:57:22.02

>>235
デフォルトコピーコンストラクタとデストラクタのコンボとか。
あまりにも有名なトラップなんで、嵌るやつもいないかもしれんが。

241 ：デフォルトの名無しさん：2011/02/22(火) 21:50:46.99

コンストラクタといえば、explicitではない型変換ができるのもおかしい
そもそも継承のおかげでアップキャストは当たり前で
例外を使えば型を変更しなくてもエラーに関する仕様を変更できる
型とは一体なんだったのか

242 ：デフォルトの名無しさん：2011/02/23(水) 00:39:27.54

>>241
> 例外を使えば型を変更しなくてもエラーに関する仕様を変更できる
これどういうこと？

243 ：デフォルトの名無しさん：2011/02/23(水) 14:20:18.88

例外云々は知らんが、explicit無し一引数コンストラクタの邪悪さは異常。
デフォルトがユーザ定義型で暗黙的型変換可能って、誰得だよ。

244 ：デフォルトの名無しさん：2011/02/23(水) 15:13:31.78

このスレ読んでるとC++使いの俺でも
C++使うのやめようかと思うから困る

245 ：デフォルトの名無しさん：2011/02/23(水) 15:15:06.01

>>244
もうC++使ってるんなら手遅れでは
罠が多すぎて習得するのが大変すぎるという話題だからな

246 ：デフォルトの名無しさん：2011/02/23(水) 15:26:08.43

>>245
C++0xの右辺値参照が難しすぎて、
俺には理解できる気がしないのだよ。
C++から足を洗ういい機会な気がしてな……

247 ：デフォルトの名無しさん：2011/02/23(水) 15:31:18.13

ベター C として使うのが一番だよ。
(うっかり基底クラスの配列に継承クラスを入れてしまいながら)

248 ：デフォルトの名無しさん：2011/02/23(水) 15:43:06.24

C++使うなら最低STLは使いたいが、
そうなるとクラスと例外とテンプレートは使うしなー。
実際、C++の機能で取り除けるものが思い浮かばん。

249 ：デフォルトの名無しさん：2011/02/23(水) 16:07:54.96

>>245
"Modern move semantics"とかそんな感じの本が
多分出版されるから、大丈夫だよ！

250 ：デフォルトの名無しさん：2011/02/23(水) 21:39:37.60

真面目な話、better C としてC++を使うっていうのが
一番メリットが無いと思うわ。
Cと比べて特に生産的というわけでもなく、
C++のグロ文法とABI不在の問題点は引き継ぐとか。
どこがbetterなのかと。

251 ：デフォルトの名無しさん：2011/02/23(水) 22:14:39.96

STL便利じゃん。

252 ：デフォルトの名無しさん：2011/02/24(木) 03:05:10.83

C++ PG A : 「C++ は better C として使うと便利じゃん」
C++ PG B : 「STL 便利じゃん」
C++ PG C : 「クラス便利じゃん」
C++ PG D : 「テンプレート便利じゃん」
C++ PG E : 「例外便利じゃん」
C++ PG F : 「名前空間便利じゃん」

C PG : 「それもう "better" C じゃなくて C++ じゃん・・・」

253 ：デフォルトの名無しさん：2011/02/24(木) 03:24:42.21

D&E読んで信者になれば救われるお

254 ：デフォルトの名無しさん：2011/02/24(木) 03:28:05.32

C++ 信者 A : 「私は C++ の全てを理解した本物のプログラマだ！」
C++ 信者 B : 「私は C++ の全てを理解した本物のプログラマだ！」

C++ 信者 C : 「二人のうち少なくとも一人は嘘を付いているな・・・
（C++ の全てを理解出来るのはスッポスッポ先生だけ！）」

255 ：デフォルトの名無しさん：2011/02/24(木) 08:05:34.53

コーディングの快感度が大事。

256 ：デフォルトの名無しさん：2011/02/24(木) 09:59:31.63

better C ならC99でおk。
C++イラン。

257 ：デフォルトの名無しさん：2011/02/24(木) 10:16:57.57

来年には C1x も出るしね

258 ：デフォルトの名無しさん：2011/02/24(木) 18:06:32.69

Cの方がマシと言ってるやつらも、それでやるしかないからしぶしぶ使ってるだけだよな。

259 ：デフォルトの名無しさん：2011/02/24(木) 22:04:07.89

そうやって無理矢理仲間に引きずり込もうとするなよw

260 ：デフォルトの名無しさん：2011/02/24(木) 22:52:35.70

>>254
頭がハゲると全て理解できます

261 ：デフォルトの名無しさん：2011/02/24(木) 23:03:43.89

>>258
C++が酷い言語であることは実例付きで
散々述べられてるけど、Cはそうじゃないだろ？
一緒にされては困る。

262 ：デフォルトの名無しさん：2011/02/25(金) 01:38:02.39

>>261
bool 無いとか酷い。仮想関数無いとか酷い。名前空間無いとか酷い。
デストラクタ無いとか酷い。テンプレート無いとか酷い。例外無いとか酷い。

263 ：デフォルトの名無しさん：2011/02/25(金) 09:15:55.56

そんなものが「C言語のような低レベル言語」に必要だと？
まったく笑えるほど愚かだな。

264 ：デフォルトの名無しさん：2011/02/25(金) 09:16:15.59

>>262
つ <stdbool.h>

265 ：デフォルトの名無しさん：2011/02/25(金) 22:50:33.74

結局、変態構文好きはC++
そうじゃない場合はC
を使えばOKってことかな

266 ：デフォルトの名無しさん：2011/02/26(土) 00:18:21.32

今更 C は苦行でしかないような。

267 ：デフォルトの名無しさん：2011/02/26(土) 00:21:23.50

昔から C++ は苦行でしかないような。

268 ：デフォルトの名無しさん：2011/02/26(土) 00:43:42.85

C++ は苦行だと感じるけど
C は苦行だと感じないのが不思議

269 ：デフォルトの名無しさん：2011/02/26(土) 00:54:46.58

このスレのC++信者は、C++をdisられて
最初はロートルだのなんだのレッテル張って
抵抗していたが、次々と論破されちゃって
涙目って印象だね。

270 ：デフォルトの名無しさん：2011/02/26(土) 01:00:39.79

このスレで議論するまでもなく雌雄は決定しているからな
世間に抗ってもあんまり意味は無いよね

271 ：デフォルトの名無しさん：2011/02/26(土) 01:37:05.10

>>262-263
↑こんなの論破でもなんでもねだろｗ
このロートルどもめ。

272 ：デフォルトの名無しさん：2011/02/26(土) 02:15:23.25

JavaだのLLだのの言語処理系の発展が著しい昨今、
それらの言語を実装/拡張するための
「低級言語としての」Cの重要性は全然下がってない。
alternativeが存在しないからな。

一方、C++のCへ追加した機能については、代替手段がいくらでも存在する。
例えばLLならどれを使ってもC++よりは上手くやれる。
つまり「C + 他言語」でC++の代わりは十分勤まる。
それどころか、C++はABI不在、マングリングが腐ってる、
などの理由でCの「低級言語としての」利点を改悪してる。
文法だって罠だらけで腐ってる。
ゆえに他言語と組み合わせて使うなら、C++はCよりも劣る。

さて、ロートルというのは、たぶん新しい言語を覚えたくない人間、
という程度のニュアンスだと思われるが、
果たして本当に新しいものを覚えたくないのはどちらかね？

273 ：デフォルトの名無しさん：2011/02/26(土) 02:43:13.55

>>272
> 「低級言語としての」Cの重要性は全然下がってない。
> alternativeが存在しないからな。

低級言語としての C++ は良い alternative

> ゆえに他言語と組み合わせて使うなら、C++はCよりも劣る。

extern "C" すればいっしょですう。

274 ：デフォルトの名無しさん：2011/02/26(土) 02:43:56.07

>>272
> 一方、C++のCへ追加した機能については、代替手段がいくらでも存在する。

そりゃそうだが、正直めんどい。

275 ：デフォルトの名無しさん：2011/02/26(土) 02:55:17.85

このくらいがめんどくさいと言ってよく名前空間無しでやっていられるものだ

276 ：デフォルトの名無しさん：2011/02/26(土) 11:10:39.24

クソ長い関数名を書かなくていいだけでもC++使う意味はあるわな

277 ：デフォルトの名無しさん：2011/02/26(土) 11:23:59.38

>>272
ABI界面でextern "C"すりゃいいだけなのに何を言ってるんだか俺にはわからねー
C++使いは他の言語使わないみたいな言い草だけど
boost.pythonとか知らないの？
今流行のV8だの、その上で動くnode.jsだの勿論C++で書かれてるし……

現実的には複数言語を使う場合、インタフェース部分のグルーを書く必要があったり
デバッグやリファクタリングが面倒になったりと面倒もあるから
C++一個で済むならそのほうが楽なこともあるよ
ケースバイケースってやつだね

278 ：デフォルトの名無しさん：2011/02/26(土) 11:43:55.24

C+他の言語が普通なら、C++も他の言語の一つとして扱えば良いだけだと思うんだが、
なんでC使いの人は執拗にC++を叩くんでしょうか？それとも俺が知らないだけで、
C++以外の他の言語も攻撃してるんでしょうか？

279 ：デフォルトの名無しさん：2011/02/26(土) 12:17:43.82

perl は糞

280 ：デフォルトの名無しさん：2011/02/26(土) 12:35:09.70

だれも「文法が罠だらけでクソ」に
反論できてなくてワロスw

281 ：デフォルトの名無しさん：2011/02/26(土) 12:40:08.38

>>280
そこは真実だからしょうがないｗ

282 ：デフォルトの名無しさん：2011/02/26(土) 12:45:46.58

今はあまり言われなくなったけど、C言語でも禁じ手とか落とし穴とかのタイトルで
いかにクソかを書いた記事や本が結構でてたよな。
ttp://web.archive.org/web/20070113222026/http://www.cmagazine.jp/src/kinjite/c/index.html

283 ：デフォルトの名無しさん：2011/02/26(土) 12:50:07.07

>>280
そりゃWindowsとMS-DOSどっちを選ぶかみたいなもんだ
WindowsはMS-DOSにくらべりゃ複雑な糞の山だが
それでもみなWindowsを使ってるんだよ

284 ：デフォルトの名無しさん：2011/02/26(土) 12:55:38.80

その例えは正しくないよ。
シンプルなカーネル（C言語）とユーザランド（他言語）ってOSと
何でもカーネルにぶち込む（C++）OSって感じ。
一時期は後者が流行ってたけど（速度的な問題で）
やっぱり保守しやすいのは前者で、最近はそっちに流れてる感じ。

285 ：デフォルトの名無しさん：2011/02/26(土) 13:04:38.24

C++は糞の山だけど、関数に長い名前付けたくないから使いますよっと

286 ：デフォルトの名無しさん：2011/02/26(土) 13:18:04.26

>>284
>>277

287 ：デフォルトの名無しさん：2011/02/26(土) 14:05:28.36

C PG : 「最近 C++ の影が薄いよなあ・・・」
C PG : 「C++ はスマホの主要開発言語に成れなかったからなあ・・・」
C PG : 「サーバサイドは Java に完敗だし・・・」
C PG : 「ウェブアプリは JavaScript の独壇場だし・・・」
C PG : 「デスクトップアプリは C# や Objective-C の時代だし・・・」
C PG : 「そもそもクライアントアプリはウェブアプリ化が進んで行くだろうし・・・」
C PG : 「Kernel プログラミングも殆どが C と ASM だし・・・」
C PG : 「その内、Pascal みたいになって行くのかな・・・」

C++ PG : 「C++ 0x が完成した暁にはッ！」

C PG : 「（うわ、居たのか）200x 年代は終わっちゃったよ?」

288 ：デフォルトの名無しさん：2011/02/26(土) 14:37:50.87

C 使いの人って、どんなコード書いてるの?

289 ：デフォルトの名無しさん：2011/02/26(土) 14:41:49.06

C のコードが見たかったら、ネットに沢山あるよ

290 ：デフォルトの名無しさん：2011/03/01(火) 17:11:56.75

C++のウンコさを理解できない低能は
http://local.joelonsoftware.com/wiki/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
を1000回読むといいよ

291 ：デフォルトの名無しさん：2011/03/01(火) 20:03:49.19

C++はウンコだが、Cも鼻糞だと思うんだ。

292 ：デフォルトの名無しさん：2011/03/01(火) 20:57:04.56

だから他人を巻き込もうとするなってw

293 ：デフォルトの名無しさん：2011/03/01(火) 21:10:10.35

Joelの記事を読んでシステムハンガリアンは悪だが
アプリケーションハンガリアンは良いもんだと思ってる人は
ttp://www.maroontress.com/Hungarian/
この辺も読んだほうがいいな

294 ：デフォルトの名無しさん：2011/03/02(水) 02:12:34.31

>>290
> 本当に信頼性のあるコードを書く方法は、人の典型的な弱さを考慮に入れるシンプルな
> ツールを使うことであって、副作用のあることや、プログラマの無謬性を前提とする漏れのある
> 抽象化を隠している複雑なツールを使うことではない。

こんなの真面目に考えたら C の最適化コンパイラなんて使えないじゃないんじゃないか？

295 ：デフォルトの名無しさん：2011/03/02(水) 08:39:51.49

最近は知らないけど、昔はリリースする時は最適化オプションを付けないというのはあったね。
普通は各最適化レベルでコードにどんな変更がされるかを把握した上でコンパイラを使うから、
複雑なツールの内には入らないんじゃないの。

296 ：デフォルトの名無しさん：2011/03/02(水) 09:40:12.55

>>293
セマンティクスをシンタックス（型システム等）に写像する行為は
完全には上手くいかない（漏れのある抽象化の例）し、
そのリンク先の主張にはとても同意できない。

297 ：デフォルトの名無しさん：2011/03/02(水) 11:03:06.14

>>295
そんなんで正当化できるなら「C++ プログラマはデストラクタ呼び出しや例外によるコードパスを
把握した上で C++ を使うから複雑なツールの内には入らない」って言えるってことにならない？

298 ：デフォルトの名無しさん：2011/03/02(水) 11:11:56.84

>>297
デストラクタや例外をコンパイラオプションひとつで
付けたり外したりして問題が起こらないというなら、
その主張を認めよう。

299 ：デフォルトの名無しさん：2011/03/02(水) 11:31:08.71

>>298
なんで付けたり外したりできることが関係してくるの？

300 ：デフォルトの名無しさん：2011/03/02(水) 11:45:29.54

最適化オプションをつけずにリリースって、どんだけおめでたいんだろ

301 ：デフォルトの名無しさん：2011/03/02(水) 12:04:32.13

>>299
お前のような信じられないほどの低能には
決して理解できないよ

302 ：デフォルトの名無しさん：2011/03/02(水) 12:07:31.94

裸の王様はじまったな。

303 ：デフォルトの名無しさん：2011/03/02(水) 12:27:27.79

Cはポータブルアセンブラとして、ハードウェアの抽象化を実現している。
すくなくとも、Cの規格の範囲内のことをしている限り、
どんな最適化オプションを付けてもCコンパイラはvalidな
コードを生成する（はず）。

しかし、Cの提供する抽象化にも漏れはあって、
OSカーネルなどのハードウェアに近いプログラムを書くときは、
規格の範囲外のことをする必要が出てくる。
そういうとき、確かに複雑な最適化は思わぬ結果をもたらすことがある
（漏れのある抽象化の例）。

そういうとき、大事なのは漏れのある抽象化にどう対処するか、ということ。
Cコンパイラの場合、単純に最適化レベルを下げる（非常に低コスト）ことで
実現できる。
このように、抽象化が漏れたときに簡単に対処できるかどうかは非常に重要で、
例えば簡単にオンオフできるというのは良いデザインだ。

304 ：デフォルトの名無しさん：2011/03/02(水) 12:35:07.96

>>303
ありがとう。

で、 C++ 使って特定の機能が「漏れのある抽象化」など問題を起こすようなら使わなけりゃ
いいわけですよ。 extern "C" で C のコードと混ぜてもいいしアセンブリのコードと混ぜてもいい。

これができるんなら C++ を目の敵にする理由は無いと思うんだけどね。

え？簡単じゃない？
はじめから C で全部書くのに比べたらずっと簡単でしょ。

305 ：デフォルトの名無しさん：2011/03/02(水) 12:59:13.20

>>304
C++のどの機能は使ってOKで、どの機能は駄目か、という点について
共通となる文化がない。

例えば、俺が自分でC++を使うときに従うルールは、
多分304のそれとは異なっていて、そのため304が俺のコードを読むときは
例えばオペレータオーバーロードを常に疑わなきゃならないし、
任意の関数から例外が飛んでくる可能性を考慮しなければならない。
俺の従うルールなんて判らないんだから。
これは正直しんどいと思うんだが、どうよ。

俺自身は、使い捨てだがLLより速く走る必要のあるコードを
C++で書くことは良くあって、そういう場合はCより楽なのは確か。
でも、この用途はニッチすぎるだろ。

306 ：304：2011/03/02(水) 13:20:57.48

>>305
> これは正直しんどいと思うんだが、どうよ。

C++ ではオペレーターオーバーロードがあって、関数からは例外が飛んでくる。
特に説明の無い限り演算子は組み込み型の定義と類似のものだと読むし、
例外安全を疑うなら変数定義やクラス定義のほうを見て RAII が徹底されているか
確認する。

そういう文化だと認識してるからどうってことない。

> でも、この用途はニッチすぎるだろ。

組み込み機器でLL(?)の類を走らせるのは面倒あるいは不可能。
C++ が最適だよ。

307 ：デフォルトの名無しさん：2011/03/02(水) 13:33:48.43

>>306
おいおい、それじゃJoelの言ってるような
副作用の強いC++の機能を使うってことじゃん。

その場合、コードの一部分だけ見ても動作が判らないだろ？
そりゃ読み難いし、「間違ったコードが間違って見える」にも反するよ。

308 ：デフォルトの名無しさん：2011/03/02(水) 13:44:38.42

言語を混ぜてもいいのか
RAIIを徹底しなければならないのか
それが問題だ

309 ：デフォルトの名無しさん：2011/03/02(水) 13:44:51.10

>>307
> その場合、コードの一部分だけ見ても動作が判らないだろ？
> そりゃ読み難いし、「間違ったコードが間違って見える」にも反するよ。

あなたにとってはそうかもしれませんが、僕にとってはそうではないのです。

C のコードだって、どんな言語で書かれたコードだって、そういうのは無くならないでしょ。

読みやすく、間違ったコードが間違って見えるように書くのは、言語じゃなくてプログラマの
責任によるところのほうが大きいんだよ。

310 ：デフォルトの名無しさん：2011/03/02(水) 14:06:04.15

ただ C++ は理不尽な罠が多いってだけだなw

まあ現実的には、ある程度ルールというか空気みたいなものはあるしなあ。
それは会社ごとだったり、開発の規模や種類だったり、
グーグルのコーディングスタイルガイドだったり。

311 ：デフォルトの名無しさん：2011/03/02(水) 14:24:07.60

>>306
現場はコンパイラはC++でも
ソースはまんまCのとこばっかじゃん。
なのに「組み込みはC++が最適(ｷﾘ」とかwww

312 ：デフォルトの名無しさん：2011/03/02(水) 15:18:04.50

でも C++ の安くてうまいとこは使えるじゃん。

313 ：デフォルトの名無しさん：2011/03/02(水) 16:36:47.53

>>309
C++で間違ったコードが間違って見えるように書く方法は、
Cの機能だけを使って書くということで、
（なにせ、C++の構文ときたら、実際にやっていることを隠蔽するばかりだからね）
さらにCコンパイラを使うことでC++の忌まわしい機能が
使われていないことをチェックすることができる。

Linusがどっかのメーリングリストで似たようなことを書いてたけど、
なるほど納得だね。

314 ：デフォルトの名無しさん：2011/03/03(木) 01:12:28.31

> （なにせ、C++の構文ときたら、実際にやっていることを隠蔽するばかりだからね）
そりゃそうだ。だって隠蔽するためにあるんだから。

間違ったコードすら埋もれてしまうのも必要悪だと思って、
自分はC++を使っている。

315 ：デフォルトの名無しさん：2011/03/03(木) 01:29:08.28

>>311
「現場」といって自分のまわりの状況を紹介してくれるのはいいのですが、
それがどこでも同じだと言える根拠は無いですよね？

316 ：デフォルトの名無しさん：2011/03/03(木) 01:33:08.14

>>313
> C++で間違ったコードが間違って見えるように書く方法は、
> Cの機能だけを使って書くということで、

なんで他に方法が無いと思ってるの？
C++以外の言語ではどうなるの？

> Linusがどっかのメーリングリストで似たようなことを書いてたけど、

>>99-101

317 ：デフォルトの名無しさん：2011/03/03(木) 08:08:25.87

Kernel PG : 「以上、Kernel 開発には C++ は相応しくないという知見が得られた」

C++ PG : 「いやいや。でもそれはお前の個人的な感想、もっと言えば妄想かもしれない
という可能性は完全には排除出来てないんでしょう?」

Kernel PG : 「（また悪魔の証明か）なら、あんたが C++ で書いたら良いんじゃないの、
Linux に匹敵する Kernel をさ。」

318 ：デフォルトの名無しさん：2011/03/03(木) 08:40:24.73

Darwin とか C++ 使ってるけど

319 ：デフォルトの名無しさん：2011/03/03(木) 10:54:29.59

>>314
清濁合わせ飲む感じでC++を選択するなら、それはそれで良いんじゃね？
「C++が使える環境でC++を使わない理由などない」とか言っちゃうアホに
反論したくなるだけで、勝手に使う分には好きにすればいいさ。

俺にとってのC++は、書くのはCより楽な場合があるけど、
読むのはCより常に面倒であり、かつ
プログラムは読む時間の方が書く時間よりずっと多いので
可能なら選択したくない言語だけど。

320 ：デフォルトの名無しさん：2011/03/03(木) 11:32:44.60

>>316
> なんで他に方法が無いと思ってるの？

ある抽象化を実現する(実際にやっていることを隠蔽する)とき、
(1)抽象化が漏れるシチュエーションを減らす
(2)漏れたときの対処が容易
という二点を満たすのが良いデザインだ。

デザインする、という行為を放棄しているC++は、
当然ながら両方とも満たしていない。
なので、C++を使うときは、Cの機能だけ使うほうがマシなのさ。

321 ：デフォルトの名無しさん：2011/03/03(木) 11:49:23.74

>>317
悪魔の証明ってのは言い得て妙だな

バグの存在が客観的に証明されるまではテストもデバッグもしない
自分でバグを探すのは自殺点であり得点にならない思ってる
そういう性格の人もいるんだろうな

322 ：デフォルトの名無しさん：2011/03/03(木) 11:55:39.85

>>317
悪魔の証明なんて要らないだろ。言語の特性から結果が導き出せることを示せば良いんだよ。
それをしないで決め付けだけを主張するから突っ込まれる。

323 ：デフォルトの名無しさん：2011/03/03(木) 11:57:44.71

>>320
> デザインする、という行為を放棄しているC++は、

こういうのが「決め付け」な。
何が「当然ながら」だよ。わらかすな。

で、 C++ 以外の言語はどうなの？
C++ 以上に裏でいろいろやってくれるけど、全部悪い言語なの？

324 ：デフォルトの名無しさん：2011/03/03(木) 12:19:41.39

>>323
裏でいろいろやってる内容をCで表現できれば良い
C++の舞台裏はCで表現できないというか実装依存とされあえて表現していない

325 ：デフォルトの名無しさん：2011/03/03(木) 12:23:22.52

>>324
どういうことなの？
他の言語も裏でやることは全部実装依存だろ。

たとえばPythonの例外処理機構とC++の例外処理機構とで、
「Cで表現」できるかどうかが違うの？

326 ：デフォルトの名無しさん：2011/03/03(木) 12:59:30.63

>>323
C++以外の言語、といっても色々あるだろうが、
C++ほど抽象化が漏れている言語はそうそう無いだろ。

例えば >>237 の罠なんて、C++が歴史的にCの拡張として実装された、
という文脈をみなければ到底理解できん抽象化の仕方だ。
つまりコンパイラの実装とか、過去の互換性とか、そういう背景を
理解しなければいけないという点で「抽象化が漏れている」。

しかも、それに対する対処方法は「両方同時に使用しない」しかなく、
本当に同時に使用されてないかは対応するコードをチェックしてまわるしかない。
なので「漏れたときの対処が容易」でもない。

で、C++以外の言語だが、少なくとも >>320 の(1)については
C++よりマシだ。C++のような理不尽な罠が少ないからな。

327 ：デフォルトの名無しさん：2011/03/03(木) 13:06:15.50

>>325
仕様と実装が分離している言語は嫌われるということ。
その理由の一つは、抽象化が漏れた時に実装が隠蔽されていると困るから。

328 ：デフォルトの名無しさん：2011/03/03(木) 13:07:13.91

あと、スクリプト系の言語においては、例外はそんなに悪くない場合もある。
例外は「間違ったコードが間違って見えるようにする」の規則には反するが、
ちょっとした書き捨てスクリプトなんかは
「逆に考えるんだ。間違ってもいいと考えるんだ」て感じで
適当に書いてもいい場合があるからな。

そういう意味では、C++でも使い捨てスクリプトなら良いんじゃね？
LLと比べて生産性で勝てるかは疑問だが。

329 ：デフォルトの名無しさん：2011/03/03(木) 13:27:45.79

ひょっとして使い捨てスクリプト的なプログラムしか書いてない?

330 ：デフォルトの名無しさん：2011/03/03(木) 13:50:42.70

>>326
なるほど。それは正しい主張だと思うよ。

ただ、Cとの互換性も欲しいし「パフォーマンスを損なわずに実装すればそうなるわな」と
思っちゃう自分にとっては、そこらへんは飲めちゃう話なんだよね。

C++に実装された機能と同等のことをCでするために（既存あるいは自前の）ライブラリ郡を
使うのと比べたら、「抽象化の漏れ」についてたいした違いは無いだろう、と。

331 ：デフォルトの名無しさん：2011/03/03(木) 13:51:49.12

>>328
↓こちらへどうぞ。
例外を正しく使えないプログラマ多いね。その6
http://hibari.2ch.net/test/read.cgi/prog/1298059471/

332 ：デフォルトの名無しさん：2011/03/03(木) 13:54:46.71

>>329
どう読めばそう取れるんだ？
それに、俺がどんなプログラムを書いてるか解らなくても、
同じような主張をしてるLinusやJoelが
書き捨てスクリプトだけ書いてるわけないくらい解るだろ？
まったくもってアホすぎる。なんて低能なレッテル張りだ。

333 ：デフォルトの名無しさん：2011/03/03(木) 14:26:24.25

>>330
抽象化が漏れたときのダメージは、それが（暗黙的な何かを伴うために）
発見しにくいという意味において、はなから抽象化していないよりも深刻だよ。
だからC++と同等のことを（C++のような抽象化を提供しない）Cでしても違いが無い、とは思わん。

ただし、自分が知能に本当に自信があるなら、C++を選んでもいいと思う。
例えば von Neumann が目の前に現れて「C++なんて楽勝www」とか言ったら
「どうぞどうぞ」って言っちゃうよ。

334 ：デフォルトの名無しさん：2011/03/03(木) 14:34:21.92

>>332
君は Linus ではない。

335 ：デフォルトの名無しさん：2011/03/03(木) 14:54:32.80

>>334
確かに俺はLinusでもJoelでもない。
ここの書き込みに彼らが関係していないのは確実だろう。

しかし、彼らと似たような主張をしており、
そしてそれ以外の情報が与えられていない状況で、
「使い捨てスクリプトだけ書いている」と推論する妥当な理由が存在するのか？
相手を貶めるレッテル張り以外の何物でもないだろ。

336 ：デフォルトの名無しさん：2011/03/03(木) 18:17:58.96

CPGはC++のクソさだけを上げてるが、Cのクソさは気にならないのかね？

337 ：デフォルトの名無しさん：2011/03/03(木) 18:58:13.20

寂しいのは分かるが、こっちを巻き込もうとするなってw

338 ：デフォルトの名無しさん：2011/03/03(木) 19:19:15.32

>>318
I/O Kit で例外やテンプレート禁止の C++ のサブセットを使ってるだけでしょ

339 ：デフォルトの名無しさん：2011/03/03(木) 19:23:11.92

いや巻き込むとか引きずり落とすとか飛び火させるとか無関係で、実際
Cもかなりの罠があるだろとｗ

ttp://www.amazon.co.jp/dp/4775302558
ttp://www.bugbearr.jp/?C%E8%A8%80%E8%AA%9E%2F%E7%BD%A0
ttp://web.archive.org/web/20070104051347/www.cmagazine.jp/src/kinjite/c/index.html
ttp://www.geocities.co.jp/bleis_tift/cpp/baddefine.html

程度に違いはあるとはいえ、「罠は踏まなきゃ良いだけ」というなら、結局慣れの差じゃないのかい？

340 ：デフォルトの名無しさん：2011/03/03(木) 19:25:59.98

一緒くたにして巻き込みたい気持ちは分かるけど、阿鼻叫喚度では
C++さんにはとてもとても敵いませんわ。頑張ってもムリポ。

341 ：デフォルトの名無しさん：2011/03/03(木) 19:27:41.44

>>338
思いっきりクラス使ってるけど。http://www.opensource.apple.com/source/xnu/xnu-1228.15.4/iokit/

342 ：デフォルトの名無しさん：2011/03/03(木) 19:28:06.81

隠蔽の多いアセンブラやリンカは捨ててバイナリを直接入力したほうが安全

343 ：デフォルトの名無しさん：2011/03/03(木) 19:33:10.31

>>339
一番下のだけ見たけど、そんなのに引っ掛かる様な奴は
どんだけ安全策が施されていたらまともなコードを
書ける様になるんだよw

というかその結論はマジで書いてるの?

344 ：デフォルトの名無しさん：2011/03/03(木) 19:33:50.62

>>341
>>338

345 ：デフォルトの名無しさん：2011/03/03(木) 19:36:51.22

>>343
逆に聞きたいけどお前の安全の基準はなんなんだよｗ
Cが絶対的な安全基準なのか？

346 ：デフォルトの名無しさん：2011/03/03(木) 19:38:22.87

>>345
質問に質問をw

まずは >>339 の一番下のリンクを読んでくれ。
話はそれからでも遅くないさ。

347 ：デフォルトの名無しさん：2011/03/03(木) 19:46:36.26

しかもよく読んだら >>339 の最後の奴は C の罠じゃなくて C++ の罠じゃん・・・
CPP を知らない C++ プログラマにとってはその結論は正しいんだろうね。
それを書いた人だって C で #define を使うなとは言わないでしょ。

348 ：デフォルトの名無しさん：2011/03/03(木) 20:07:27.51

なんで一番下しかよまないの？

349 ：デフォルトの名無しさん：2011/03/03(木) 20:12:07.78

>>347
そのページだとC++と書いてるが、#defineの危険性や展開時のクセはCでも変わらないだろ。
Cでも複雑にdefineが絡み合ってたら、C++なみにクソなコードになるって。

350 ：デフォルトの名無しさん：2011/03/03(木) 20:13:00.77

>>348
一番上は絶版の書籍で、二番目はウィキのメモ書きみたいなノートで、
三番目はリンク先に飛べないから。

つまり、真面目に検討すべき物が提示されていないという事だね。

今これを読んでるから、気が向いたらコメントしてあげよう。

http://literateprogramming.com/ctraps.pdf

351 ：デフォルトの名無しさん：2011/03/03(木) 20:14:35.80

>>349
きちんと読んであげないと書いた人が可哀相だぞ。

C++並みのコードを書くには何百個 #define すれば良いのやら見当もつかないわ・・・

352 ：デフォルトの名無しさん：2011/03/03(木) 20:23:50.53

自分は質問するばかりで、答えてもらったのに返事も出来ない奴は
生え際が消滅する呪いが掛かるってばっちゃが言ってた。

353 ：デフォルトの名無しさん：2011/03/03(木) 20:34:49.68

一番下のだけに関してでも、

・マクロであることを意識して展開時にどうなるかを考えなければならない(Cのその他の構文から考えると例外的)
・エラー時に分かりにくい

どちらもC++のテンプレートを叩くときの常套句と重なる気がするんだが。

354 ：デフォルトの名無しさん：2011/03/03(木) 20:39:38.83

>>353
言語の中での位置付けを無視すればどんな拡大解釈だって可能さ。
君だって本当に CPP とテンプレートの問題が同レベルだとは思ってないんだろう?

CPP の用途はシンプルな置換が殆どなんだから、テンプレートと一緒にするのは
ちょっと理解出来ない。

355 ：デフォルトの名無しさん：2011/03/03(木) 20:41:43.59

>>354
確かに拡大ぎみだとは思うが、知らなければ落とし穴になりうる物なのは確かだと思うんだろ？

356 ：デフォルトの名無しさん：2011/03/03(木) 20:49:48.38

>>355
拡大気味なんじゃなくて無理筋を攻めてる感じがするね。

357 ：デフォルトの名無しさん：2011/03/03(木) 21:17:41.23

>>353
CでできることをするときにはC++でやった方が罠が小さいのは同意するよね。

358 ：デフォルトの名無しさん：2011/03/03(木) 21:28:00.08

"C++よりは"という枕詞無しで、Cは安全とか言っちゃうPGはセンスを疑う。
結婚はしたくないタイプ。

359 ：デフォルトの名無しさん：2011/03/03(木) 21:30:16.29

誰が何で同意するのか書かないと話にならんわ・・・

360 ：デフォルトの名無しさん：2011/03/03(木) 21:34:27.87

Cプログラマ的にはC++と比較してどうこういう気持ちは無いよなあ
何か色々と残念だなあと思う事はあるけど

361 ：デフォルトの名無しさん：2011/03/03(木) 21:53:37.78

結局コードがなきゃね

362 ：デフォルトの名無しさん：2011/03/03(木) 22:58:22.66

もう一度書かせてくれ。

Linusの主張(>>99)で唯一根拠が無いのが
「C++は多くの平均以下のプログラマが使っている」
って点だが、それすらも >>339 の反論の
あまりのヘボさによって例示されてしまっている。

363 ：デフォルトの名無しさん：2011/03/03(木) 23:13:16.69

とりあえず362と設計はしたくない

364 ：デフォルトの名無しさん：2011/03/03(木) 23:13:57.82

口喧嘩に勝つことがそんなに重要かねえ

365 ：339：2011/03/03(木) 23:30:28.78

>>362
自分はプログラマでは無い。
だから適切なコードの例示すことはできないが、
339で言いたかったのは、そういう本なり記事なりがあるくらい
なんだから、Cにもクソ差は充分盛り込まれてるんだろうということ。

違うというなら俺よりも著者にお便りでも書いてください。

366 ：デフォルトの名無しさん：2011/03/03(木) 23:33:35.39

このスレでは、コード書けない人がプログラミング言語をクソ呼ばわりしちゃう訳か

367 ：デフォルトの名無しさん：2011/03/03(木) 23:35:14.04

コードは書けるよ。
良い例が書けないだけで。

368 ：デフォルトの名無しさん：2011/03/03(木) 23:39:03.71

そんなんじゃ云い訳にもならんだろ
サンプルコードも書けないし、文献も見つけて来れない奴が、
何であれプログラミング言語をクソ呼ばわり出来るんだ?

369 ：デフォルトの名無しさん：2011/03/03(木) 23:39:59.43

失敬

何であれ　→　何で

370 ：デフォルトの名無しさん：2011/03/03(木) 23:40:51.32

>>365
そういうロジックでいうなら、
紹介してくれたCの本が絶版になってる一方、
Effective C++が必読本&ベストセラーとなってる点で
察してくださいよ。

371 ：デフォルトの名無しさん：2011/03/03(木) 23:41:24.15

なんだなんだこのスレは

372 ：デフォルトの名無しさん：2011/03/03(木) 23:42:00.46

373 ：372：2011/03/03(木) 23:44:07.54

連投失礼

374 ：デフォルトの名無しさん：2011/03/03(木) 23:45:47.12

とりあえずC0xはクソ

375 ：デフォルトの名無しさん：2011/03/03(木) 23:46:29.07

C1xだった

376 ：デフォルトの名無しさん：2011/03/03(木) 23:51:15.05

>>339 の内訳
・絶版の書籍
・ウィキのメモ書き
・大半が C 以外の言語にも当て嵌まるコーディング上で避けるべき点のリスト
・C++ の罠

これで彼は何を主張したかったんだろうか・・・

377 ：デフォルトの名無しさん：2011/03/03(木) 23:51:56.02

>>372
そりゃ新規でCだけ覚えるヤツがいないからじゃねーの？

378 ：デフォルトの名無しさん：2011/03/03(木) 23:54:12.41

Cのみ扱った本って339のに限らず殆ど絶版じゃねーの？

379 ：デフォルトの名無しさん：2011/03/03(木) 23:56:11.13

>>377
CのバイブルK&Rを無視すんな。
Cの本＝絶版じゃねーよ。

380 ：デフォルトの名無しさん：2011/03/03(木) 23:57:44.78

>>378 は、単にプログラム関連の書籍を見た事が無いだけじゃねーの?

381 ：デフォルトの名無しさん：2011/03/03(木) 23:59:09.63

C++の罠じゃなくてCの罠に見えるが

382 ：デフォルトの名無しさん：2011/03/03(木) 23:59:44.80

>>381
ちゃんと文章を読んであげなよ

383 ：デフォルトの名無しさん：2011/03/04(金) 00:04:08.74

>>382
MAXマクロが引数を二回評価しうるて話やろ
C++だとそもそもマクロ使わないけど、Cだとねえ

384 ：デフォルトの名無しさん：2011/03/04(金) 00:04:43.93

>>382
3項演算子の?と組み合わせてる例以外はCの罠に見えるが

385 ：デフォルトの名無しさん：2011/03/04(金) 00:07:33.76

>>383
>>339どこをどう読んだらそうなるんだよ・・・

しかも、それだってgets()の話と一緒だろ。
Cプログラマには常識レベルの話で騒いでるだけ。

386 ：デフォルトの名無しさん：2011/03/04(金) 00:08:43.02

>>385
C++の例だってC++PGには常識なんじゃないの？

387 ：デフォルトの名無しさん：2011/03/04(金) 00:09:10.15

>>384
それはCPPを知らない事が前提だろ。筋立てが無理矢理すぎるんだよ。

388 ：デフォルトの名無しさん：2011/03/04(金) 00:10:30.21

>>386
常識の範疇で収まるなら云い訳がましい書籍が何冊も出ないだろうさw

389 ：デフォルトの名無しさん：2011/03/04(金) 00:17:06.53

罠といってもマクロには名前があるから検索しやすい
問題は、名前のない暗黙の罠をどうやって検索するか

390 ：デフォルトの名無しさん：2011/03/04(金) 00:24:12.95

>>344
？

391 ：デフォルトの名無しさん：2011/03/04(金) 00:27:41.10

>>365
>339で言いたかったのは、そういう本なり記事なりがあるくらい

結局の所、選んだリンクがマズかったな。

392 ：デフォルトの名無しさん：2011/03/04(金) 01:20:04.84

>>333
CでもC++で抽象化されているものと同様のことをしようと思ったらライブラリレベルで抽象化を行うでしょ。
そうしたら同じように気をつける以外避けようの無い抽象化の漏れも出てくるでしょ、って話。

393 ：デフォルトの名無しさん：2011/03/04(金) 08:42:32.22

>>392
何か例を挙げてみてくれるか？そうすると話がしやすい。

で、俺が最初に思いついたのは、シグナルとスレッドが両方絡むような
プログラムで、これは確かに罠満載で難しんだけど、
ある意味で「本当に難しいことをしようとしてる」から難しいんであって、
C++の提供する抽象化のように、面倒くさがらずに
明示的に書けば難しくない例（例外の代わりにエラーコードを明示的に書くとか）
と一緒にしたくないな。

394 ：393：2011/03/04(金) 08:49:15.42

>>393 で挙げたのは、
気をつける以外避けようがない罠があるCプログラムの例、のつもり。

395 ：デフォルトの名無しさん：2011/03/04(金) 09:45:29.94

このスレの
C++がdisられる → 脊髄反射で質問 → さらにdisられる → C++だけじゃなくCも糞と言い出す → 一緒にすんな → 最初に戻る
のループはちょっと面白いな

396 ：デフォルトの名無しさん：2011/03/04(金) 10:12:07.48

シグナルはプロセスを制御する。
プロセスとスレッドが両方絡むのは、.NETとC++が両方絡むようなもの。
C++プログラマでもC++/CLIを素直に受け入れる者は少ない。

しかし敵の敵は味方だというし
C++をdisるくらいならC++/CLIをほめちぎるほうが前向きだ。

397 ：デフォルトの名無しさん：2011/03/04(金) 11:48:29.87

>>393
ごめんそれ例外が難しいんじゃなくて393に例外が難しいだけにしか見えない

398 ：デフォルトの名無しさん：2011/03/04(金) 11:50:18.56

>>394
解放忘れとか？

399 ：デフォルトの名無しさん：2011/03/04(金) 13:42:38.31

>>397
確かに俺にとって例外は難しい。
しかしお前にも、例外を使ったマズいコードと、
例外安全な良いコードを簡単に見分けることなどできないはずだ。

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

シグナルとスレッドが（内容を完全に理解していてさえ）難しいのと同様、
複数のコードパスを（暗黙的に）生成してしまうコードが
難しくないわけがない。
これは言語仕様を理解できるか否かの問題じゃなく、
人間の認知機能の問題だからな。

400 ：デフォルトの名無しさん：2011/03/04(金) 14:04:26.27

>>398
例えば、mutexでロックして処理を実行していて（処理が終わればアンロックする）
途中で非同期シグナルで割り込まれた場合とか。
割り込まれた場合、即座に処理を中断することが望まれるけど、
mutexを握ったまま中断されるとデッドロックしてしまう。
（なので、シグナルハンドラから安易にpthread_cond_signalとかを送っちゃヤバい）
かといって、のんびりアンロックするまで処理を中断しないのも困る。みたいな。

401 ：デフォルトの名無しさん：2011/03/04(金) 14:18:36.45

まあ例外はなあ。使わんとこもあるし。適材適所じゃねえの。
C だって goto は使えるけど、無茶な使い方はしないでしょ。
goto と例外を直接比べてるわけじゃないよ。念のため。

402 ：400：2011/03/04(金) 14:21:19.51

あー、pthread_cond_signalについては忘れてくれ。
上の例とはちょっと合ってない。

403 ：デフォルトの名無しさん：2011/03/04(金) 17:26:48.51

>>399
GC頼みのRAII守らんコードなんてC++で例外使うなら即ゴミ箱行きじゃ
PGごと窓から投げ捨ててしまえ

404 ：デフォルトの名無しさん：2011/03/04(金) 18:24:43.35

>>403
例外は書くのが難しいんじゃないんだ。
読むのが（そして、どのコードをゴミ箱に突っ込むべきか）を読み解くのが面倒なんだよ。

なに？例外安全で無いコードを書くやつなんていない？
人間は基本的にミスするものだし、何より >>339 を読んで
「Cにも罠がある！」とか言っちゃうような底なしの低能どもが
Exceptional C++ に書いてあるような内容をミス無く実行できるはずもないだろ？

405 ：デフォルトの名無しさん：2011/03/04(金) 18:43:57.76

メモリ直接いじっちゃう言語が危険じゃないわけないだろ

406 ：デフォルトの名無しさん：2011/03/04(金) 18:46:29.55

C++と危険のレベルが次元違いとはいえ、最悪とだけ比較してCが安全と思ってたらヤバイ。
ヨハネスブルグより安全なら大丈夫ってか？

407 ：デフォルトの名無しさん：2011/03/04(金) 19:05:21.98

はい
スレタイにある通り、最悪とだけ比較します

408 ：デフォルトの名無しさん：2011/03/04(金) 22:55:51.78

>>399
> しかしお前にも、例外を使ったマズいコードと、
> 例外安全な良いコードを簡単に見分けることなどできないはずだ。
>
> http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

リンク先の記事が言っているのは良いコードと悪いコードの見分けではないよ。

Raymond Chen からの最後のコメントにこうある。
> My point is not that it's easier/harder to find mistakes in
> error-based or exception-based code. It's that it's harder to
> **tell the difference** between code where the author thought
> about errors/exceptions and code where the author didn't.
書いた人が処理の失敗をちゃんと意識しているかどうかをコードを見て
判別するのが例外を使った場合はより難しくなる、と言っている。

ただし、これについても疑問の余地が残る。

処理の完了前に副作用を起こしてしまうようなコードを修正するには処理順を
入れ替えるだけだったり、途中の値をローカル変数を使って保留させたり
するんだけど、これは例外を使った場合でも戻り値を使った場合でも同様
だからね。

409 ：デフォルトの名無しさん：2011/03/04(金) 23:06:44.31

>>399
> 複数のコードパスを（暗黙的に）生成してしまうコードが
> 難しくないわけがない。
> これは言語仕様を理解できるか否かの問題じゃなく、
> 人間の認知機能の問題だからな。

人間にとって扱うのが難しいほどの数のコードパスを生み出しているのは
使用する処理が持つ失敗の可能性であって、通知～処理方法として例外を選択
したことでそれが増えるわけではない。

通知～処理方法に戻り値＋明示的なテストを選択した場合、プログラマの手抜き
などによって本来分かれるべきだったコードパスが暗黙のうちに合流してしまう
ことがある。

例外を批判するプログラマは、しばしばこの暗黙の合流に慣れており、
例外安全の文脈で示される本来あるべきコードパスの数を見て、それを例外が
引き起こす問題だと勘違いしている。

例外が暗黙のうちにコードパスを分けるのに比べて、戻り値を使った場合の
暗黙のコードパスの合流は多くの場合に間違いとなる。この点で例外のほうが
優れており、それゆえに C 以外の言語には多く採用されていて、実際に利用
されている。

410 ：デフォルトの名無しさん：2011/03/04(金) 23:10:04.33

>>399
例外にまつわる誤解について、参考リンク。

http://www.boost.org/community/exception_safety.html
> 2 Myths and Superstitions
...
> It's almost as though exceptions are viewed as a mysterious attack on
> otherwise correct code, from which we must protect ourselves.
...
> "Exceptions make it more difficult to reason about a program's behavior." ...
これが書かれたのがもう１０年前のこと。いい加減にこんな迷信は消えて欲しい
ほしいところなんだけど、まだまだみたいだね。

もうひとつおまけ。
http://www.parashift.com/c++-faq/exceptions.html#faq-17.1
[17.1] What are some ways try / catch / throw can improve software quality?
> By eliminating one of the reasons for if statements.
...

411 ：デフォルトの名無しさん：2011/03/05(土) 09:50:54.34

>>408
Raymond Chen はコメント欄で色々突っ込まれたあげく、
最後に「例外はミスを見つけるのが難しいんじゃないんだからね！
コード作者の意図が読みづらいだけなんだからね！」
って意見をちょっと変更しているように見える。

ま、それはいいんだけど。

412 ：デフォルトの名無しさん：2011/03/05(土) 10:04:16.63

何でPGは、自分が使わない言語をdisるのでしょうか

413 ：デフォルトの名無しさん：2011/03/05(土) 10:04:45.22

>>409
ここではずっと、「読むのが難しい」という話をしてたつもりだった。

なぜ読むのが難しいかと言えば、
例外が throw するコードと catch するコードが同じ画面にあることは
滅多に無く（どこか関数の深いところから飛んでくる）、
しかも = やら + といったオペレータからさえ飛んでくる上に、
変数の型をチェックして型を実装したコードを見つける必要があり、
さらに継承が使われてたらクラス階層をたどる必要があり、
ポリモーフィズムが使われてたら実行時における型が何かを知る必要があり、
すなわちどこからどんな例外が飛んでくるか知るのに
コードの様々な部分を読まなきゃならない。

これが、高々（オーバーロードさえない）関数の戻り値を調べてるコードを読むより
読みやすいというなら、あんたは大嘘つきだ。

414 ：デフォルトの名無しさん：2011/03/05(土) 10:09:32.98

>>405 >>406
危険な言語であるCに、さらに罠を大量に追加して
「自分の足を撃つなら、撃つやつが悪い」って突き放してるんだぜ。C++は。

Cの危険さは必要悪だが、C++が容易する便利機能は他の言語で
もっと安全に実装されてるんだから、
そっち使ったほうがいいよ。

415 ：デフォルトの名無しさん：2011/03/05(土) 10:35:05.71

そうそう、>>399 のリンク先を読むのが面倒なひとのために。

次のコードブロックは、例外ベースの正しいコードと間違ったコードを
それぞれ表しています（実際に使われてるコードから抜粋した、らしい）。

(1)
NotifyIcon CreateNotifyIcon()
{
NotifyIcon icon = new NotifyIcon();
icon.Text = "Blah blah blah";
icon.Visible = true;
icon.Icon = new Icon(GetType(), "cool.ico");
return icon;
}

(2)
NotifyIcon CreateNotifyIcon()
{
NotifyIcon icon = new NotifyIcon();
icon.Text = "Blah blah blah";
icon.Icon = new Icon(GetType(), "cool.ico");
icon.Visible = true;
return icon;
}

これはヒドいwww

416 ：デフォルトの名無しさん：2011/03/05(土) 10:43:13.75

>>409

> 例外が暗黙のうちにコードパスを分けるのに比べて、戻り値を使った場合の
> 暗黙のコードパスの合流は多くの場合に間違いとなる。

何か例をあげてみてよ。
多くの場合に間違いとなるなら、簡単でしょ？

417 ：デフォルトの名無しさん：2011/03/05(土) 12:37:37.23

例外をcatchしたとき、どこからthrowしたか知るのは難しい。
これもコードパスがどこからか合流していることを意味する。

おそらく、同じ「型」の例外ならば合流して良いということにしたいんだろうが
例外のコードパスはグローバルすぎてどうしようもない。

「型」のことしか考えないから、スコープの感覚が退化してるんだろう。

418 ：デフォルトの名無しさん：2011/03/05(土) 12:46:50.64

int hoge(){
int ret;
if(( ret = foo() ) != FOO_OK ){
return ret;
}
if(( ret = bar() ) != BAR_OK ){
return ret;
}
if(( ret = baz() ) != BAZ_OK ){
return ret;
}
return HOGE_OK;
}

int caos::Panic::Confusion::Hoge() throw(...){
try{
caos::foo();
caos::bar();
caos::baz();
return caos::Panic::Confusion::hogeReturn_t::HOGE_OK;
}
catch(caos::Foo_Exception &e){ throw caos::Panic::Confusion::hogeException(e); }
catch(caos::Bar_Exception &e){ throw caos::Panic::Confusion::hogeException(e); }
catch(caos::Baz_Exception &e){ throw caos::Panic::Confusion::hogeException(e); }
catch(...){ assert(0);caos::Panic::Confusion::hogeException("UnknownError"); }
}

どっちがわかりやすいかなんて、明らかだろ

419 ：デフォルトの名無しさん：2011/03/05(土) 13:05:18.69

0xスレから飛ばされました。以下コピペですが、ここで議論をしたいと思います。
pure C++ vs C/C++で後者にしたほうがいい例を知りたいです。
過去の投稿（↑）はこれから読みます。

=============
普段からpure C++（およびC++0x）しか使ってなくて、困ったことはないのですが、
C言語のほうが短く簡単に書けるようなことってたぶん結構あるんじゃないかと思うのです。
思いつくのを羅列してみると、
- I/O関係（printf,scanf,...）
- マクロ
- 配列初期化
- ポインタ演算
C++0xでかなり改善されているとはいえ（autoとか）、対応するコンパイラがマシンに入ってない場合も多いので、
ちょっとC言語も勉強してみようと思うのですが、みなさんが普段dirtyテクニックとしてCを混在させているものを教えてください。

420 ：デフォルトの名無しさん：2011/03/05(土) 13:13:31.49

>>419
そんな質問でこのスレに誘導するなんて鬼畜すぎるwww

http://hibari.2ch.net/test/read.cgi/tech/1296387672/
http://hibari.2ch.net/test/read.cgi/tech/1291571263/

この辺で質問した方が良いよ。

421 ：419：2011/03/05(土) 13:18:33.29

>>420
いや、普段0xスレしか見てないので、そこに書き込んだのですが、
たしかに、雑談チックな話をはじめる雰囲気でもなかったので・・・。
気軽に答えてくださればありがたいです。

422 ：デフォルトの名無しさん：2011/03/05(土) 16:59:42.91

C++に危険な部分があるのは確かだけどさ、
だから使わないってのは極論すぎるような。

使い捨てスクリプト的なプログラムみたいに
それで済む仕事ならいいだろうけど。

423 ：デフォルトの名無しさん：2011/03/05(土) 18:40:52.91

>>422
確かに、今すぐ結論を出す必要はない。
Cで書きはじめて途中でC++に変更できる。
逆はできない。

424 ：デフォルトの名無しさん：2011/03/05(土) 18:46:05.22

それってまともな設計しないで書き始めてるってことだよね。
オチは見えてるなぁ。

425 ：デフォルトの名無しさん：2011/03/05(土) 18:57:55.47

>>424
まともに設計されたモジュールは、実装言語すら情報隠蔽できるのだよ

426 ：デフォルトの名無しさん：2011/03/05(土) 18:59:56.20

そういう意味ではC++で書きはじめてもいいけど
C++固有のモジュールシステムは使えない

427 ：デフォルトの名無しさん：2011/03/05(土) 19:16:15.20

>>423
Cで書きはじめるなら、
それはC++に変更する意味ないよ。

428 ：デフォルトの名無しさん：2011/03/05(土) 19:28:27.74

>>413
> 変数の型をチェックして型を実装したコードを見つける必要があり、
> さらに継承が使われてたらクラス階層をたどる必要があり、
> ポリモーフィズムが使われてたら実行時における型が何かを知る必要があり、

なんのためにそんな実装しだいでどうにでも変わる情報を知る必要があるの？
それは戻り値でのエラー通知でもわからないはずなんだけど、何が違うの？

> これが、高々（オーバーロードさえない）関数の戻り値を調べてるコードを読むより
> 読みやすいというなら、あんたは大嘘つきだ。

あんたの言うような読み方しない。しないでいいと思っている。

そこらじゅうに if が散らばったコードより処理の元々の意図が読みやすいぶん
戻り値＋分岐を使ったコードより簡単だと思う。

429 ：デフォルトの名無しさん：2011/03/05(土) 19:30:37.03

>>416
array = realloc(array, size);
こんなのとか。

430 ：デフォルトの名無しさん：2011/03/05(土) 19:33:54.80

>>417
例外が発生した場合のコードパスは、暗黙のうちに一本に合流しようとする。
これは明示的に catch を書くことででいくつかに分けることができる。

> おそらく、同じ「型」の例外ならば合流して良いということにしたいんだろうが
> 例外のコードパスはグローバルすぎてどうしようもない。

ここの２行目がよくわからない。何に困ってるの？

431 ：デフォルトの名無しさん：2011/03/05(土) 19:40:34.13

例外が悪だというなら当然longjumpも悪なんだろ？
そこはどうしてるわけ？

432 ：デフォルトの名無しさん：2011/03/05(土) 19:46:28.82

>>418
その例外型の変換は必要なの？（戻り値のほうでは変換はしてないようだけど・・・）

http://www.google.co.jp/search?q="Organizing+the+exception+classes+around+the+physical+thrower"

433 ：デフォルトの名無しさん：2011/03/05(土) 20:00:14.48

>>429
だれがそんな糞コード書くか

434 ：デフォルトの名無しさん：2011/03/05(土) 20:02:28.10

>>433
http://www.google.com/codesearch?q=lang:c+%22=+realloc%22

435 ：デフォルトの名無しさん：2011/03/05(土) 20:04:04.25

>>431
setjmp/lognjmp はCでも非常に危険なので、それを使わなければ
実現できない場合以外は使われない。
C++では、単純に使うことすら危険すぎる。

436 ：デフォルトの名無しさん：2011/03/05(土) 20:09:39.19

C++ だって例外を使わない選択はできるぞ。
そういうプロジェクトも少なくない。
コンパイラによってはオプションまである。

437 ：デフォルトの名無しさん：2011/03/05(土) 20:09:39.41

>>435
例外だって積極的には使われないという認識なんだけど。
統計でどうかとかは分からない、イメージ論でしかないが。
少なくても自分の場合は復帰不可能な場合でしかまず使わない。

438 ：デフォルトの名無しさん：2011/03/05(土) 20:11:46.26

なんかここで C を擁護してる人の C++ への思い込みが酷すぎる。
C++ が酷いのは同意なんだがw

439 ：デフォルトの名無しさん：2011/03/05(土) 20:12:50.81

つーかわざわざ日本人に用途が分かりやすいように"例外"て名前をつけてくれてるのに、
何でもかんでも例外で返すやつがいるのかよと。

440 ：デフォルトの名無しさん：2011/03/05(土) 20:16:43.51

>>439
「例外は例外的な場面でだけ使う」とかいうやつか。
そんな基準は主観的なものになってしまって役に立たないよ。
http://www.boost.org/community/error_handling.html
> The problem is that one person's ``exceptional'' is another's ``expected'':
> when you really look at the terms carefully, the distinction evaporates and
> you're left with no guideline.

コンストラクタの失敗ならどんな些細な理由でも例外で返す他無い。

441 ：デフォルトの名無しさん：2011/03/05(土) 20:18:41.83

>>440
それはほとんど復帰不可能なケースなんじゃないの？
Cならexitするような。

442 ：デフォルトの名無しさん：2011/03/05(土) 20:20:55.57

>>441 知らんし、そんな分類どうでもいい。

443 ：デフォルトの名無しさん：2011/03/05(土) 20:26:52.46

どうでもいいことは無いだろ。
その手の復帰不可能な例外ならmainで一括して拾うか、処理系によっては
拾う必要すらなかったりすると思うんだけど。

444 ：デフォルトの名無しさん：2011/03/05(土) 20:28:32.39

>>443 議論には関係ないってこと。

445 ：デフォルトの名無しさん：2011/03/05(土) 20:34:20.66

例外の危険性って、どこから飛んでる来るか分からない＝拾いきれるか問題
という前提条件なんじゃないの。
投げられても拾う必要がないなら除外されるだろ。

446 ：デフォルトの名無しさん：2011/03/05(土) 20:36:19.68

例外自体の危険性ははset/longjumpとそれほど変わりなく(むしろ例外の方が安全か)
それが問題になるのは用途だろ。どういう用途で使うか考えずになんで議論できるのか。

447 ：デフォルトの名無しさん：2011/03/05(土) 20:37:34.71

>>445 拾う必要があるかどうかはアプリレベルで決めること。ここで言えることは無い。

448 ：デフォルトの名無しさん：2011/03/05(土) 20:39:21.12

>>445 だれが拾いきれるかどうかなんて問題にしたの？

449 ：デフォルトの名無しさん：2011/03/05(土) 20:41:04.18

そんなの問題にしても catch (...) で終了だよな。

450 ：デフォルトの名無しさん：2011/03/05(土) 20:48:41.34

>>428
例外の場合、その関数を呼び出す側に暗黙的にコードパスを追加できるから、
実装しだいでどうにでも変わるとか言ってられないよ。

っていうか、「僕はいいかげんにコード読んでます」とか自己紹介いらないから。

451 ：デフォルトの名無しさん：2011/03/05(土) 20:54:54.38

>>434
realloc すらまともに扱えないプログラマが、C++ になったら
まともなプログラムを書けるなんてとても思えない。
素直に C/C++ じゃなく python あたり使ってほしい。

452 ：デフォルトの名無しさん：2011/03/05(土) 20:58:57.94

>>450
例外を投げない関数が例外を投げるようになったときの話か？
戻り値にエラーを含まなかった関数が含むようになったときと同じじゃないか？
エラーが無視されないぶん例外のほうがマシじゃないか？

453 ：デフォルトの名無しさん：2011/03/05(土) 20:59:15.11

>>441
mallocに失敗するときは殆ど復帰不可能だから、
エラーチェックなんていらないよなwww

454 ：デフォルトの名無しさん：2011/03/05(土) 21:00:19.29

>>451
誰もそんなこと瑣末な主張はしていない。 >>416 の望んだとおりの例を挙げただけだろ。
ちゃんとアンカーついてるんだからレス辿れよ。

455 ：デフォルトの名無しさん：2011/03/05(土) 21:02:58.44

>>454
勝手に糞コード書いといて、問題起きますよねってアホか。
だいたい、どこが暗黙のコードパスの合流なんだよ。見え見えじゃねーか。

456 ：デフォルトの名無しさん：2011/03/05(土) 21:04:03.02

ム板の例のスレでもそうだけど、例外が難しいという主張をするときには、それが
戻り値＋分岐だとどう違うのかよく考えてからにしろよ。

457 ：デフォルトの名無しさん：2011/03/05(土) 21:05:43.41

>>452
いや、もっと単純に、コードを追跡するのが面倒って主張に対し、
そもそも追跡なんてしないって返されたから、
そりゃやべーでしょって話。

458 ：デフォルトの名無しさん：2011/03/05(土) 21:08:07.15

>>457
だったら何のために実装にもぐって追跡なんてするのか教えてくれ。
戻り値でエラー通知されたときにはそれが不要になる理由がわかるようにな。

459 ：457：2011/03/05(土) 21:10:07.19

あと、戻り値の場合はその関数の return を調べれば
（または、時には関数定義の戻り値の型を調べるだけで）
エラーが追加されたか判るけど、
例外の場合、どこまでも遡る必要がある。

460 ：457：2011/03/05(土) 21:13:19.26

さらに言えば、エラーを戻り値で返す関数が
戻り値を処理してなければ、単純にバグを疑うことができる。
一方、例外の場合、catch していないときでも
もっと上のルートで例外処理しているのかもしれず、
バグかどうかの判定にはずっと多くのコードを読む必要がある。

461 ：デフォルトの名無しさん：2011/03/05(土) 21:13:22.39

>>453
バカか？
exitするかどうかの為にチェックするんだろ

462 ：デフォルトの名無しさん：2011/03/05(土) 21:14:59.39

>>457
お前さんのデバッガには例外時に潜れる機能も付いてないのか？

463 ：デフォルトの名無しさん：2011/03/05(土) 21:15:32.63

>>461
冗談に噛み付かれてちょっとビックリ。
しかし真面目な話、exitさえまともにできないときあるよな。

464 ：デフォルトの名無しさん：2011/03/05(土) 21:17:52.08

>>463
あまりにセンス無い文だったので冗談だと分かんないからな。
どこら辺がどういう意味の冗談になってるの？

465 ：デフォルトの名無しさん：2011/03/05(土) 21:18:07.92

>>459
なんで戻り値の場合は仕様（ドキュメント）が更新されるのが前提なのに
例外だと仕様が更新されないのが前提なの？おかしいだろ？

466 ：デフォルトの名無しさん：2011/03/05(土) 21:18:12.55

>>462
実装に潜って追跡する必要が無い、って主張が無理筋だとわかったから
デバッガ使って読みますよ、に変えたんだよね？

467 ：デフォルトの名無しさん：2011/03/05(土) 21:21:18.08

>>460
catch してなかったらバグで catch してたらバグじゃない、とか思ってるの？
それ違う。（むしろ逆のことのほうが多い）

実際は、例外使えば「戻り値を処理していない」というような、バグを疑うパターンが
減るってことだろ。いいことじゃないか。

468 ：デフォルトの名無しさん：2011/03/05(土) 21:22:46.43

>>464
441が自分で勝手に復帰不可能なエラーか否かを決めてるからさ。
そんなこというなら、malloc失敗はもうOSがクラッシュしてて何しても無駄、とか
なんとでも言えるだろ？
で、お前は例外の痛いところを突かれて、どうでもいいところに噛み付いてるんだよねw

469 ：デフォルトの名無しさん：2011/03/05(土) 21:24:39.74

>>466
デバッガ使いこなせてないからってそれはないだろ

470 ：デフォルトの名無しさん：2011/03/05(土) 21:26:05.80

>>467
> catch してなかったらバグで catch してたらバグじゃない、とか思ってるの？
> それ違う。（むしろ逆のことのほうが多い）

どういうこと？

471 ：デフォルトの名無しさん：2011/03/05(土) 21:27:06.30

>>457
属性throw()もコメント//never throwも使わない人？

472 ：デフォルトの名無しさん：2011/03/05(土) 21:30:13.78

>>470
少なくとも C++ の場合、リソース解放やのために catch しているケースでは
RAII で置き換えたほうがよいことが多い。 catch してリソース解放している箇所が
あれば、似たような別の処理で同じようにする必要があり、漏れる可能性が残る。

473 ：デフォルトの名無しさん：2011/03/05(土) 21:34:50.58

>>471
例外で投げれる型の制限について、コンパイル時に
チェックしてくれたら良かったのに、とは思うよ。

474 ：デフォルトの名無しさん：2011/03/05(土) 21:35:32.26

>>468
それを言うならお前の方が例外なんて使う必要が無いケースで軽々しく例外飛ばしてると
勝手に考えてるんじゃないの？

475 ：デフォルトの名無しさん：2011/03/05(土) 21:36:41.26

>>472
エラー処理 = リソース解放、ならそうかもね。
でもデストラクタで可能なエラー処理なんて、たかが知れてると思うの（例外投げれないからな）

476 ：デフォルトの名無しさん：2011/03/05(土) 21:37:38.99

呼び出し側が例外安全になってない場合
throwしたらバグ
exitしたらバグじゃない
だからthrowするよりexitする方がいい

477 ：デフォルトの名無しさん：2011/03/05(土) 21:39:56.83

>>476
大抵そうだと思うが、可能な限りデストラクタ呼んで欲しい場合はthrowの方がいいんじゃない？

478 ：デフォルトの名無しさん：2011/03/05(土) 21:40:45.65

>>474
例外を必要十分なだけ使ってる良いコードと、
なんでもかんでも例外をとばしてる糞コードとが
コードを詳細に追跡すること無く、容易に判定できたらいいのにね。

479 ：デフォルトの名無しさん：2011/03/05(土) 21:40:54.22

>>475
そうか。分野によっては catch にエラー処理を書くことは多いのかもしれないな。
個人的な経験の話になっちゃうみたいなんで、「逆のことのほうが多い」は無視して。

480 ：デフォルトの名無しさん：2011/03/05(土) 21:42:30.82

>>478 >>456

481 ：デフォルトの名無しさん：2011/03/05(土) 21:46:15.23

C++を攻撃されると、自分が攻撃されてると感じちゃう繊細なお前らへ。
別に、お前らを攻撃してる訳じゃないからね。
C++をちゃんと使いこなしてるなら、それはそれで立派なことだから。

482 ：デフォルトの名無しさん：2011/03/05(土) 21:59:10.52

あと、万一C++標準委員会の人間が読んでるなら、
お前らいいかげんにしてください。
人間、皆がお前らみたいに賢くないんです。マジで。

483 ：デフォルトの名無しさん：2011/03/05(土) 22:03:44.73

>>478
・仕様を読む
・throwで検索して何を投げてるのか見る

これだけでも見分けられるかもしれない。

484 ：デフォルトの名無しさん：2011/03/05(土) 22:11:55.58

>>482
C++委員会の方々も必要な機能を必要な人だけが使ったらえぇ
と、おっしゃってたからなぁ。

485 ：デフォルトの名無しさん：2011/03/05(土) 22:25:50.64

だったら必要ない機能をOFFにする機能を用意しろと
#define NO_TEMPLATE
#define NO_EXCEPTION
#define NO_NAMESPACE
#define NO_INHERITANCE
#define NO_OPERATOR_OVERLOAD

みたいなので全部無効に出来てたらそこそこいい言語になるのになあ

486 ：デフォルトの名無しさん：2011/03/05(土) 22:30:17.36

>>485 それはコンパイラの仕事でいい。

487 ：デフォルトの名無しさん：2011/03/05(土) 22:32:47.51

いやいや、規格上は上手く取り外し出来るようになってないだろ今のところ
委員会はそんなこと言うならちゃんと取り外せるように作れと

488 ：デフォルトの名無しさん：2011/03/05(土) 22:33:18.65

rttiや例外は無効にできるコンパイラが多い

489 ：デフォルトの名無しさん：2011/03/05(土) 22:34:27.91

487はどんだけ無茶言ってんだよw

490 ：デフォルトの名無しさん：2011/03/05(土) 22:50:02.06

例外なしでコンストラクタ書かされるならC++使いたくない。
コンストラクタ使わない書き方が普及したらC++使ってもいい。

491 ：デフォルトの名無しさん：2011/03/05(土) 22:53:07.91

>>490
コンストラクタで例外を何に使ってるの？

492 ：デフォルトの名無しさん：2011/03/05(土) 22:56:11.99

>>490-491 「コンストラクタで例外を投げてはいけない」とか言っちゃう人たちですか？

493 ：デフォルトの名無しさん：2011/03/05(土) 22:57:15.82

>>490-491 http://www.google.co.jp/search?q=%E3%82%B3%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF+%E4%BE%8B%E5%A4%96

494 ：デフォルトの名無しさん：2011/03/05(土) 23:00:59.92

コンストラクタが戻り値戻せないのがそもそもおかしいんだよなぁ
戻り値受け取る自然な構文がないのはわかるけど、もうこんなんでいいから取れるようにしてくれ

Hoge h(42);
int ret = return<Hoge>;

495 ：デフォルトの名無しさん：2011/03/05(土) 23:02:40.17

>>494 失敗の通知なら例外でいいし、副次的な情報なら参照引数でいい。

496 ：デフォルトの名無しさん：2011/03/05(土) 23:03:30.82

>>492
例外をOFFにした場合の話なので、コンストラクタの中でもOFFです

497 ：デフォルトの名無しさん：2011/03/05(土) 23:04:18.22

errnoでいいじゃん
何がご不満？

498 ：デフォルトの名無しさん：2011/03/05(土) 23:06:36.60

>>496 独り言はチラシの裏にでもどうぞ。

499 ：デフォルトの名無しさん：2011/03/05(土) 23:10:56.91

ああそうだよ値戻し用の引数でいいじゃん

Hoge(int n, int *ret){
if(なんかエラー){
*ret=1;
return;
}
*ret=0;
}

int ret;
Hoge h(42, &ret);
if(*ret){
return ERROR;
}

なんで今まで気付かなかったんだろう
というかコンストラクタのエラー対処法の議論ってそこらに議論転がってるけど
今までこれ見たことないな

500 ：デフォルトの名無しさん：2011/03/05(土) 23:25:36.20

なんでそこまでするほど例外使いたくないの？

501 ：デフォルトの名無しさん：2011/03/05(土) 23:37:33.26

if文が好きな前時代の遺物ロートルだろ

502 ：デフォルトの名無しさん：2011/03/05(土) 23:41:43.56

>>499
言語仕様でいうと正当なコードだろうけど
ものすごい挑発的に見えるから、大人しくCを使うのがよさそう

503 ：デフォルトの名無しさん：2011/03/06(日) 01:52:08.99

>>499
コピーコンストラクタ

504 ：デフォルトの名無しさん：2011/03/06(日) 01:54:10.57

>>500 >>501
例外使うのがモダンなコーディングスタイルかというと、
それも疑問。
グーグルのC++コーディング規約は例外を禁止してるだけでなく、
go言語は仕様から例外を外してる（戻り値でのエラー通知を採用）。

505 ：デフォルトの名無しさん：2011/03/06(日) 02:04:50.86

>>504
google のスタイルがモダンじゃない
というだけの話だろ。

506 ：デフォルトの名無しさん：2011/03/06(日) 02:07:34.49

>>465
C++だと、名前空間、オーバーロード、ポリモーフィズムがあるから
あるメソッドが例外送出するように仕様変更になったとして、
じゃあどこを直せば良いのか、簡単には判らなくないか？
特にオペレータが変更されたとき。

一方、Cならgrepで一発。

507 ：デフォルトの名無しさん：2011/03/06(日) 02:09:52.82

>>505
グーグルよりモダンな505さんかっこいーwww

508 ：デフォルトの名無しさん：2011/03/06(日) 02:10:56.02

>>504
Google の C++ コーディング規約は歴史的な事情。添えられている議論をよく読んでみるといい。

go 言語では例外と類似のエラー通知方法として panic, recover 関数がある。
これらは例外と異なり追加の制御構造を必要としないようにデザインされた。
http://golang.org/doc/go_faq.html#exceptions

509 ：デフォルトの名無しさん：2011/03/06(日) 02:17:07.32

>>509
これはGoogleの講演会に行ったときに聞いた話なんで、信じてもらえなくてもいいんだけど、
Googleが例外を使わないのは、歴史的な事情（過去の例外安全でないコードと混ぜるため）
もあるけど、何よりGoogle の規模だとほぼすべてのコードパスが実行されうるため、
例外機構で見た目がすっきりしても処理を追いにくくなるからだってさ。

まさに、このスレで議論されてるような話だね。正しい主張かどうかはともかく。

510 ：509：2011/03/06(日) 02:18:01.33

>>508 でした。すまぬ。

511 ：デフォルトの名無しさん：2011/03/06(日) 02:18:36.41

>>506
確かにコンパイラの支援がないときついかもな。
関数消してコンパイルしてみりゃ一発ではあるんだが。

512 ：デフォルトの名無しさん：2011/03/06(日) 02:29:00.23

>>509
>例外機構で見た目がすっきりしても処理を追いにくくなるからだってさ。

ま、この主張の妥当性はおいておくとして、
それの根拠に

>何よりGoogle の規模だとほぼすべてのコードパスが実行されうるため、

を出すのは愚かだろ？
俺には

「全てのコードパスが実行される ⇒ 処理を追いにくくなる」

は、およそ論理的な主張とは思えない。
あ～やだやだ。google 信者ってこんな奴らばっかなんだよな。

513 ：509：2011/03/06(日) 02:45:44.36

>>512
いや、別にGoogle信者じゃないんだが。
「全てのコードパスが実行される → 暗黙的コードパスも残らず実行される → 暗黙的コードパスは追跡しがたい（が追跡しないわけにいかない）」
こんな感じ。で、メリット（見た目すっきり）とデメリット（追跡しがたい）を秤にかけただけかと。
あんたの推論はステップを飛ばしてる上に、意味の無いレッテル張りをしてる。

514 ：デフォルトの名無しさん：2011/03/06(日) 02:51:13.67

>>509 >>513
失敗する可能性があっても、実際に失敗しないかぎり失敗時の安全性は考えなくていい、
って暗に言ってるように聞こえるんだが、正気か？

515 ：デフォルトの名無しさん：2011/03/06(日) 02:52:57.82

>>513
お、暗黙的コードパスの追跡とか言い出したな。
458 への回答が無くて気になるんだが、かわりにおねがいできないか？

516 ：509：2011/03/06(日) 03:00:56.87

知らねーよwww
こっちは例外使ってるし。
だから
> 正しい主張かどうかはともかく。
って書いたじゃん。

517 ：デフォルトの名無しさん：2011/03/06(日) 03:21:24.54

>>458
>>515
関数fについてエラー処理してるコード辺があったとして。
そしてそのエラー処理が漏れていないかチェックしたいとき。

戻り値：関数fを探して、その関数でリターンしてるところをチェックし、エラー処理のコードと比較
例外：関数fを探して、例外を投げる可能性のある全てをチェックし、エラー処理のコードと比較

になると思う。
どっちが大変かな？
戻り値ベースなら、簡単な検索でかたがつくよ？

518 ：デフォルトの名無しさん：2011/03/06(日) 03:43:48.70

そういえば、393とか416の回答はどうなったんだろう？

519 ：デフォルトの名無しさん：2011/03/06(日) 03:49:18.14

>>517
仕様は無いのが前提なのか。その時点ですでに破綻気味だな・・・。

で、例外を使っていれば変に catch してるところが無い限り
エラー処理が「漏れる」なんて事は無いんじゃないの？

「漏れる」の意味がよくわかってないだけなのかもしれない。
戻り値で言えば if などによる分岐が無い場合を指してるんだよね？

520 ：デフォルトの名無しさん：2011/03/06(日) 04:01:26.60

>>519
例外ベースなら、全ての投げられる型に対して
個別の例外処理を実行する必要がある、というシチュエーションです。
戻り値ベースだと、例えば整数が帰ってきて
それぞれの値に応じてエラー処理を実行します。
少し違うけど >> 418 のような感じでしょうか。

521 ：デフォルトの名無しさん：2011/03/06(日) 04:03:55.88

>>519
それと、仕様があっても仕様とコードが対応しているか
調べるときに同様のレビューが入るのでは？

522 ：デフォルトの名無しさん：2011/03/06(日) 04:12:55.38

>>520
そんなめんどくせー関数を仕様無しで使えってのがそもそも無理だ。

あと、結果が複数あってそれぞれの動作が別々に決まるようなら、
それはもう「エラー処理」とも少し違う気がする。例外の使える言語でも
戻り値とかで状態を返すべきところでしょ。

523 ：デフォルトの名無しさん：2011/03/06(日) 04:23:27.40

>>521
どうも例外を使う場合は具体的な例外の型をすべて仕様として列挙することを想定してる
みたいだけど、そんなことはあんまりしない。（検査例外について言われる問題が関連する）

例外安全性のレベルを示すだけか、例外の型を示すとしても基底クラスをいっこ示す程度。

524 ：523：2011/03/06(日) 04:49:14.94

523 には個人的な願望が混ざってしまった。他のプログラマがこういう認識かどうかはよく知らない。

個人的な願望で言わせてもらえば、例外安全性を示すだけにとどめた上で、例外について何も
書いてなければ強い保証を提供しながら例外を投げるものと解釈するのが楽でいい。

525 ：デフォルトの名無しさん：2011/03/06(日) 11:12:06.46

>>456
マジレスすると
例外を使うと周囲から色々なことを期待される。
自分では戻り値＋分岐と同じような使い方しかしないつもりなのに
RAIIを期待される。
所謂「驚き最小」のために、その期待を裏切らないことを期待される。

そういうことに振り回されたくないなら
最初から例外は使いませんとかC++は使いませんと宣言しておいたほうがいい

526 ：デフォルトの名無しさん：2011/03/06(日) 11:20:04.28

>>503
Hoge(const Hoge &src, int *ret)
を使ってコピーするようにすればいいだけだよな
本来のコピコンは殺しておいて

527 ：デフォルトの名無しさん：2011/03/06(日) 13:13:17.00

>>525
エラー処理の方法は自分個人で決めるんでなく、プロジェクトのコーディング規約に従えよ

528 ：デフォルトの名無しさん：2011/03/06(日) 13:27:26.18

>>525
だから、なんでそれで C++ は使いませんが含まれるんだよw
おまいさんの願望をさりげなく入れんなw

529 ：デフォルトの名無しさん：2011/03/06(日) 13:56:19.82

従え。願望するな。

530 ：デフォルトの名無しさん：2011/03/06(日) 14:50:55.46

>>525
RAII は例外だけじゃなくて return や break などに対しても役に立つぞ。
例外なんぞ使わなくても C++ では当然の手段だ。難しい話でも無いしな。

それに従っておけば例外についても問題なくなるんだからおいしい話だぜ。

531 ：デフォルトの名無しさん：2011/03/06(日) 15:25:45.74

でも解放失敗しうるリソースにRAII使って解放エラー無視するバカが多すぎて困る

532 ：デフォルトの名無しさん：2011/03/06(日) 15:53:36.87

RAIIはGCよりも難しい。
「GCに従えば例外は問題ない」とすればバカでもわかる。

533 ：デフォルトの名無しさん：2011/03/06(日) 16:00:20.78

>>531

> でも解放失敗しうるリソースにRAII使って解放エラー無視するバカが多すぎて困る

何か例をあげてみてよ。
多すぎて困るっていうぐらいなら簡単でしょ。

534 ：デフォルトの名無しさん：2011/03/06(日) 16:03:54.78

>>533
まず、佐藤。
次に、田中だろ、高橋だろ・・・

535 ：デフォルトの名無しさん：2011/03/06(日) 16:10:15.09

>>533
ファイル
ストリーム
データベースコネクション
スレッド
プロセス
ハンドル類
動的ライブラリ

基本的にメモリと一部の排他制御以外の全てだな
RAIIはfreeなりdeleteなりが失敗せず例外も投げないというお約束の上に立脚してることを忘れてはならない
基本はヒープメモリ専用のテクニックであって、万能の処方箋ではない

536 ：デフォルトの名無しさん：2011/03/06(日) 16:31:24.82

>>535
>基本はヒープメモリ専用のテクニックであって

そんなこという奴、初めて見たよ。

なら、どうすれば解決できるっていうの？
もしかして「２フェーズ・デストラクション」とか言い出すの？

537 ：デフォルトの名無しさん：2011/03/06(日) 16:46:31.52

>>535
いや、だから、実際にその点に問題があって困るコードの例を・・・

538 ：デフォルトの名無しさん：2011/03/06(日) 17:29:19.59

>>536
そうだよ
解放に失敗しうるとすれば、それは明示的な解放をせざるを得ない
RAIIに任せっきりなんて使い方は危険極まりない

>>537
たとえばファイル閉じる時にフラッシュしようとしたら失敗したなんて時はエラー放置したらデータ飛ぶだろ？
ロック順とかの関係でロック手放し損なったりしたらデッドロックするだろ？
DB接続切り損なったままほっといたらそのうちDBサーバーのセッション数埋まっちゃうだろ？
それくらいも想像できないからファイルとかにRAII使っちゃうんだな

539 ：デフォルトの名無しさん：2011/03/06(日) 17:54:47.16

>>538
基本は RAII で、問題になるなら明示的な終了処理を加えとけば問題ないよね。

・・・ってレスしようとしてなんかデジャブったので探してみたら、やっぱり似たような話があった。
http://2chnull.info/r/tech/1230341243/226-261

540 ：デフォルトの名無しさん：2011/03/06(日) 20:04:30.53

>>539
逆だろう
基本は明示的な終了処理でちゃんとエラー時の対処をして、
万一解放忘れがあったとき時にエラーは無視してとりあえず解放してもらうためにRAIIがある

リソースリークという最悪を避けるための保険としてはRAIIも有効だと思うよ
だが、その場合デストラクタで解放されるというのは本来はバグだ
頼ってはいけないし、終了処理を自分で呼ぶ義務から逃れることは出来ない

541 ：デフォルトの名無しさん：2011/03/06(日) 20:13:50.90

>>540
ファイル書き込み処理の途中で例外が発生してデストラクタでファイルが閉じられるとき、
ファイル閉じのエラーは無視して（ログに記録して済ませる程度で）元の例外だけ伝われば
いいよね。

これはバグじゃないと思うんだ。バグだというのなら、どうすればいいの？って話になるし。

542 ：デフォルトの名無しさん：2011/03/06(日) 22:32:04.84

RAIIがどうこうじゃなくて、マルチタスクをちゃんと運用できてないという話なんじゃないの。

543 ：デフォルトの名無しさん：2011/03/06(日) 23:12:40.84

どこからそんな話が出てきたんだろう・・・

544 ：デフォルトの名無しさん：2011/03/06(日) 23:19:58.12

書き込みが終わるまで待ってから終了するための待機タスクが必要なんだろ？

545 ：デフォルトの名無しさん：2011/03/06(日) 23:46:52.46

>>541
ちゃんと状況がわかった上で、その局面ではあえてエラーを無視するという選択をして、
実現方法としてデストラクタに任せるというのなら、まあいいと思う

「とにかくRAIIに任せとけばいいよｗｗｗ」って連中がそこまで考えてるかどうかが問題

546 ：デフォルトの名無しさん：2011/03/07(月) 14:28:23.10

だからさ、例外が出たら
てきとーにRAIIでリソース解放（失敗しても無視）して
てきとーにログ吐いて終了するような
使い捨てスクリプトには、C++もいいもんだよ

547 ：デフォルトの名無しさん：2011/03/07(月) 14:35:00.68

豆知識
ロンドン証券取引所（LSE）の証券システムはC++製

548 ：デフォルトの名無しさん：2011/03/07(月) 15:22:30.72

>>485 >>487の案は大変魅力的だと思うの。
C++1xでは是非そうしてもらおう。

549 ：デフォルトの名無しさん：2011/03/07(月) 15:28:15.14

継承以外は単純なサーチで済むんじゃないの？
そういうプリプロセスツール作るとか。
あるいは自分でマクロ書いて置き換えて使えば？

550 ：デフォルトの名無しさん：2011/03/07(月) 16:51:09.41

C信者
・例外を使いこなせない。継承も使いこなせない。if文大好き
・C++に比べたら、Cは安全だと信じてる
・いまだにemacsやvimを使ってる。IDEは使えない
・実はC++について詳しくない（思い込みで嫌ってる）

C++信者
・なんでもRAII。リソース解放の失敗？なにそれ？
・Cを書かせたら strlen をループの中に書いたり、gets使ったり、reallocでメモリリークさせたりする
・コード読まない。コードより仕様書
・C99やC1xは悪い規格である。C++と互換性がないから

551 ：デフォルトの名無しさん：2011/03/07(月) 16:57:21.75

>>550
ホント馬鹿げてるなぁ。

552 ：デフォルトの名無しさん：2011/03/08(火) 00:19:20.63

>>550
編集者
・信者に比べたら、中立な編集は正義だと信じてる
・2chは悪いインターネットである。編集しないから

553 ：デフォルトの名無しさん：2011/03/08(火) 10:23:01.26

>>511
派生型の仮想関数はそれじゃ見つからなくね？

554 ：デフォルトの名無しさん：2011/03/08(火) 10:31:26.71

>>550
両方ともdisってるように見えるが、
C++信者の方がクソプログラムを生産する素養に満ち満ちている件。

555 ：デフォルトの名無しさん：2011/03/08(火) 10:38:30.22

あと、このスレでは
> ・実はC++について詳しくない（思い込みで嫌ってる）
は当てはまって無いかと。

556 ：デフォルトの名無しさん：2011/03/08(火) 14:26:14.30

>>554-555 ということにしたいのですね。

557 ：デフォルトの名無しさん：2011/03/08(火) 17:15:54.38

>>556
C++使い涙目だなwww

558 ：デフォルトの名無しさん：2011/03/09(水) 08:19:17.52

安易に構文を追加したため罠だらけで、
コードの可読性はいたずらに低く、
ご自慢の機能(RAII)は安全なプログラムを書く役にはさっぱり立たず、
コンパイラのバージョンが上がると古いオブジェクトファイルと
リンクできなくなることもあり、なのでシステム全体を再コンパイルする必要があるのに
コンパイルは糞遅く、エラーメッセージはカオス。

そんなC++が大好きです。

559 ：デフォルトの名無しさん：2011/03/09(水) 16:06:17.82

結局CとC++、選べるならどっちがいいの？

560 ：デフォルトの名無しさん：2011/03/09(水) 17:03:36.48

演算子オーバーロードとかテンプレートとか使うかどうかはともかく
今時クラス化できないって辛すぎないか？
そういう意味では文字通りC++（Cのちょっと高機能）として使うのが一番お得

561 ：デフォルトの名無しさん：2011/03/09(水) 17:47:34.42

今時は動的リンクや動的型がないと辛い。
どうしても静的型がいいという保守的な人がC++を使う。

562 ：デフォルトの名無しさん：2011/03/09(水) 17:56:01.73

>>560
クラスっぽいことはCだと構造体と委譲でやることになるが、
確かに委譲は書くのが面倒臭いけど、辛すぎるってほどか？
C++使った方が楽だけどね。

563 ：デフォルトの名無しさん：2011/03/09(水) 18:07:20.93

しかし>>250のような理由により、クラス程度ではC++を使う気にならないという。

564 ：デフォルトの名無しさん：2011/03/09(水) 18:35:56.18

absがdoubleに対応してるC++はCよりマシ。

565 ：デフォルトの名無しさん：2011/03/09(水) 18:45:08.08

だからどんなプログラム書いてんだよｗ

566 ：デフォルトの名無しさん：2011/03/09(水) 18:55:47.38

>>564
ocaml には abs と abs_float があるが
C++ よりはるかにマシだ

567 ：デフォルトの名無しさん：2011/03/09(水) 19:05:28.06

includeしないと使えないabsなんて(ry

568 ：デフォルトの名無しさん：2011/03/09(水) 19:32:02.66

>>564
ありがとう。C++を使います。

569 ：デフォルトの名無しさん：2011/03/09(水) 20:28:17.25

>>566
スレ違いです
巣に(・∀・)ｶｴﾚ!!

570 ：デフォルトの名無しさん：2011/03/09(水) 20:37:26.10

>>569
確かに C vs C++ のスレに OCaml なんて
子供の喧嘩に親が出てくるような大人げなさだが。
abs 云々なんて言語の良さとは無関係ってことさ。

そしてC++はウンコすぎるってことさ。

571 ：デフォルトの名無しさん：2011/03/09(水) 21:04:10.34

>>570
>>569

572 ：デフォルトの名無しさん：2011/03/09(水) 21:08:02.01

>>570
absだけじゃなくてオーバーロードのメリットを言ってるんだろ。そのくらい理解しろ

enumの型チェックが働かないCはクソ。
void *から他のポインタにチェックなしで代入できるCはクソ。
const定数で配列数を指定できないC99はクソ。
名前空間でシンボル名を整理できないCはクソ。
インライン関数が無くて副作用のあるマクロ使いまくりなC99はクソ。

そしてなにより文字列型が無い言語はアプリケーション開発に使えない。

573 ：デフォルトの名無しさん：2011/03/09(水) 21:09:05.70

C++は複雑すぎて僕には使いこなせません
という文章にもいろんな書き方があることがわかって有意義なスレだった
終了

574 ：デフォルトの名無しさん：2011/03/09(水) 21:26:08.78

C を LL で例えたら・・・

「それは Scheme(~R5RS)!」
「厳選された必要最低限の機能に飛び道具を隠し持ったミニマル言語!!」

Java を LL で例えたら・・・

「それは Python!」
「教育目的に適した理解し易さと、お仕事で使えるパワフルさを兼ね備えた言語!!」

ObjC を LL で例えたら・・・

「それは Ruby!」
「柔軟なオブジェクトシステムと美しいクラスライブラリを持った自由な言語!!」

C++ を LL で例えたら・・・

「それは Perl!」
「かつて一時代を築いたため使用者人口はそれなり。奇麗に書く事も可能らしいよ!!」

575 ：デフォルトの名無しさん：2011/03/09(水) 21:27:26.09

>>572
それらの性質が、実際のCプログラミングにおいてどれほどの障害になるのか、
という議論を抜きにただリストアップされても、片手落ちなわけですよ。

それほど強く主張するのだから、いくらでも語れるよね？ぜひ語ってくれ。

576 ：デフォルトの名無しさん：2011/03/09(水) 21:29:48.55

>>572
> そしてなにより文字列型が無い言語はアプリケーション開発に使えない。

こんなもんはLLとかと組み合わせてそっちでやる。
(LL自体は内部でCを使って文字列処理を実装してるだろうけど)

577 ：デフォルトの名無しさん：2011/03/09(水) 21:31:42.95

>>573
議論自体には有効に反論できず、
相手が低能であるということにして勝利宣言ですかwww
さすがC++使いさんは一味違いますね。

578 ：デフォルトの名無しさん：2011/03/09(水) 21:35:13.89

>>572
> const定数で配列数を指定できないC99はクソ。
> インライン関数が無くて副作用のあるマクロ使いまくりなC99はクソ。

どういうこと？

579 ：デフォルトの名無しさん：2011/03/09(水) 21:37:52.67

つまりＣは組み込み専用で、アプリケーション開発には使えないと言うことかな。
それなら納得。

>>575
void f(enum x)にenum yの値を突っ込んでエラーが出なかったり、
g(x++);とか書いたらマクロで副作用があったり、それがどの程度
問題なのか説明されないとわからないほどＣ使いはアフォなの？

>>578
言ってる内容が変なので、C90の間違いじゃないの？

580 ：デフォルトの名無しさん：2011/03/09(水) 21:40:29.33

>>579

>>550
>・Cを書かせたら strlen をループの中に書いたり、gets使ったり、reallocでメモリリークさせたりする

581 ：デフォルトの名無しさん：2011/03/09(水) 22:06:09.29

型チェックがないなら警告すればいい
仕様が不十分なら実装を工夫する
仕様なんて飾り

582 ：デフォルトの名無しさん：2011/03/09(水) 22:26:58.67

C使いの駄目なところは、未だにプログラマは間違えないことを前提に
考えている所。暗黙の宣言とか可変個引数とか、生産性・品質は度外視。
計算機使わず手計算でも間違わなければよいとか言ってるのと変わらん。

583 ：デフォルトの名無しさん：2011/03/09(水) 22:30:25.37

テストとデバッグが苦手なんですね
分かります

584 ：デフォルトの名無しさん：2011/03/09(水) 22:31:06.15

>>579
おやおや、C++使いは副作用があるような危険なマクロに
関数と同じような名前付けちゃうのかい？www

それに、そんな問題は、>>231 で語られてるC++の問題同様、
ハマるとしたらハマったやつが馬鹿なのさ。

585 ：デフォルトの名無しさん：2011/03/09(水) 22:35:19.84

>>582
それ、C++を擁護する台詞のつもりかwww

586 ：デフォルトの名無しさん：2011/03/09(水) 22:40:05.75

C++ プログラマのプロファイル（最新版！）

C のコードを書かせたら、

・性能要求がきつい箇所で strlen() をループの判定部分に入れる
・あれだけ使うなと言われているのに、未だに gets() を使い続ける
・平気で realloc() でメモリをリークさせる
・副作用がある事を意識して使うべきマクロに関数と間違う様な名前を付ける
・厳密な型検査があれば通過しない様なコードを無意識に書く

あぶねー、あぶねーw

587 ：デフォルトの名無しさん：2011/03/09(水) 22:42:25.69

>>582
>>413 で少し書かれてるようなC++の読みにくさは、
例外に限らずC++コードの全てに適用される。
可読性は度外視。コンパイラがパースできるなら良いと
言ってるのと変わらん。

588 ：デフォルトの名無しさん：2011/03/09(水) 22:44:50.98

C++はコンパイラも相当苦労してパースしてるしね

589 ：デフォルトの名無しさん：2011/03/09(水) 22:52:16.02

>例外が throw するコードと catch するコードが同じ画面にあることは
>滅多に無く（どこか関数の深いところから飛んでくる）、

同じ画面に無いところが例外の最大のメリットだろ。

>しかも = やら + といったオペレータからさえ飛んでくる上に、

それは不可能では無いが普通はしない。極端な例を出すなよ。

>変数の型をチェックして型を実装したコードを見つける必要があり、

？　意味わからん。例を出してくれ

>さらに継承が使われてたらクラス階層をたどる必要があり、
>ポリモーフィズムが使われてたら実行時における型が何かを知る必要があり、

継承した意味ねーだろ。頼むから継承の基本を理解してほしい。

>すなわちどこからどんな例外が飛んでくるか知るのに
>コードの様々な部分を読まなきゃならない。

例外はcatchしなきゃいけないという考えがJavaドカタ並に間違っている。

>>584
そうだな。まずCプログラマが書いたnkfとかのソース見ると危険なマクロがあるな。

590 ：デフォルトの名無しさん：2011/03/09(水) 22:52:56.44

OGRE や OpenSceneGraph みたいなグラフィックライブラリを C オンリーで書こうとしたら地獄も地獄に思えるのだが、
Cプログラマは楽にこなせるの？

591 ：デフォルトの名無しさん：2011/03/09(水) 22:57:39.05

>>589
自分で書いたマクロで罠に嵌る奴は居ないだろw
えー、もしかして >>579 ってそういう前提だったの？

592 ：デフォルトの名無しさん：2011/03/09(水) 22:58:55.31

Cプログラマは、子供の喧嘩でもすぐ大人を呼ぶ
子供だけでは危険だと分かってるから

593 ：デフォルトの名無しさん：2011/03/09(水) 23:00:05.00

CppUnitなんてのは軟弱みたいな話だし、CプログラマはCオンリーで書けると答えるんじゃないかなあ

594 ：デフォルトの名無しさん：2011/03/09(水) 23:03:52.21

C に限界を感じたら LL を混ぜたり、ObjC を使ったり、今なら Vala を選んでも良いカモね

595 ：デフォルトの名無しさん：2011/03/09(水) 23:14:26.50

>>582
> 生産性・品質は度外視。

おいおい。笑かすなよ。
このスレにもRAIIがあれば catch なんていらん、なんてやつが
結構いたわけだが（もしかして>>589もそうかな？）
そんなやつらが品質とか何の冗談だよ。

596 ：デフォルトの名無しさん：2011/03/09(水) 23:30:11.74

C++でコーディング規約をガチガチに固めてbetter Cとして使えば良いんじゃね？

597 ：デフォルトの名無しさん：2011/03/09(水) 23:33:09.04

>>596
>>252

598 ：デフォルトの名無しさん：2011/03/09(水) 23:39:10.21

例外と継承の規約は結構有名だが
コンストラクタは最低限の処理だけ、という規約がネックになっていると思う

599 ：デフォルトの名無しさん：2011/03/09(水) 23:39:10.24

>>しかも = やら + といったオペレータからさえ飛んでくる上に、
>それは不可能では無いが普通はしない。極端な例を出すなよ。

あんたのプログラムではコピーコンストラクタで例外は出ないのか？
例えば、エンコーディング情報付き文字列型を定義したとき、
異なるエンコーディング情報を持つ文字列を + で連結した場合に
例外投げるのは極端な例かい？

>>変数の型をチェックして型を実装したコードを見つける必要があり、
>？意味わからん。例を出してくれ

オブジェクトのメソッド全般。関数名だけでは一意に決まらないからな。
これは普通は問題にならんが、メールとかで patch でやりとりしてるときは
個人的にウザイと感じることがある（patchだけ見ても何の関数呼ぶか判らないから）。
が、これはちょっと難癖付け過ぎかと自分も思う。

>>さらに継承が使われてたらクラス階層をたどる必要があり、
>>ポリモーフィズムが使われてたら実行時における型が何かを知る必要があり、
> 継承した意味ねーだろ。頼むから継承の基本を理解してほしい。

継承の基本とやらを教えて？
それを理解したら、プログラムの挙動を理解したり、
テスト／デバッグしてるときに実行時における型が何かを知る必要はないんだね？

> 例外はcatchしなきゃいけないという考えがJavaドカタ並に間違っている。

詳しく。

600 ：デフォルトの名無しさん：2011/03/10(木) 00:30:56.85

>>599
>それは不可能では無いが普通はしない。極端な例を出すなよ。
string同士の + で例外飛ぶよなw。その状態だと末期だが

>>ポリモーフィズムが使われてたら実行時における型が何かを知る必要があり、
>テスト／デバッグしてるときに実行時における型が何かを知る必要はないんだね？
処理を差し替えたくて継承してる奴に対し、呼ばれる関数が
静的に決まらないから読みづらいというのはちょっと噛み合ってない。

でもデバッガでステップインするだけのことがそんなに面倒か?

601 ：デフォルトの名無しさん：2011/03/10(木) 00:41:08.82

面倒だよ
いちいちvtbl探し出してポインタを手繰ってなんて…

仮想関数呼び出しは全部vtblのポインタ経由になるから遅いのも大問題だよな

602 ：デフォルトの名無しさん：2011/03/10(木) 00:59:57.27

#define MYTHROW(e) throw e(__FILE__,__LINE__)
話が見えん。こういうことやらないて話なのか

603 ：デフォルトの名無しさん：2011/03/10(木) 01:08:45.86

Cプログラマって大変なんだな。デバッガでボタンクリックすりゃいいものを、
コンパイラの生成したアセンブリコード追うなんて。
そりゃC++なんて汚くて読めないはずだ。
でもCなら弱いメモリモデルのRISC最適化コードも読めちゃうんだすげー。

>>602
君の話こそ見えないよ。

604 ：599：2011/03/10(木) 02:28:58.26

>>600
オブジェクト指向で興味深いプログラムを書くためには、
異なる型の異なるオブジェクトの相互作用を書く必要が出てくる。

例えば、
x.func(&y)
みたいなコードを考えよう。
ここでポリモーフィズムが使われてる場合、
yに対する副作用のあり方もxの実行時の型によって変化しうる。

継承は、ちゃんと設計できてれば、xの状態遷移については
全ての派生型で問題ないことを保証するだろうが、
yについてはその限りではない。
なので、xがある特定の型のときだけyが例外を投げることはありうるし、
さらに悪い状況では、ある特定の状況で特定の実行型については
x.func(&y) の呼び出し自体がバグ、ということさえありうる。

なので、継承の基本を理解すれば実行時の型を知る必要が無い、
というのは理解できないんだよね。あんたなら解る？

605 ：デフォルトの名無しさん：2011/03/10(木) 02:55:11.76

> でもデバッガでステップインするだけのことがそんなに面倒か?

テストするとき、ステートメントカバレッジより
ブランチカバレッジの方が、100%に近づけるのは遥かに難しいよね？

同様に、デバッガで動かしながら実行時の型を網羅していくのは
単純に読むのより、ずっと大変だよ？

606 ：デフォルトの名無しさん：2011/03/10(木) 03:13:27.90

デメリットはC++としか比較しないくせに、メリットは他の言語持ち出すのなｗ

607 ：デフォルトの名無しさん：2011/03/10(木) 03:33:18.38

>>606
・Cは危険な言語である。ただし、低レベルプログラミングのための必要悪である。
・C++は危険な言語である。理由はCと同様である。
・C/C++は他の言語との連携がとりやすい言語である。
・他言語と簡単に連携がとれるのに、C++のような構文拡張は必要なのか？

というのが議論の発端なので、他言語のメリットが出てくるのはしょうがない。
もともと、C単体でC++と勝負してる訳じゃないのよ。

608 ：デフォルトの名無しさん：2011/03/10(木) 04:34:31.82

毛がない議論だ

609 ：デフォルトの名無しさん：2011/03/10(木) 06:50:13.03

>・他言語と簡単に連携がとれるのに、C++のような構文拡張は必要なのか？

グルーコード書くうえでC++の幾つかの機能は重宝

610 ：デフォルトの名無しさん：2011/03/10(木) 07:26:05.18

Rubyで書こう

611 ：デフォルトの名無しさん：2011/03/10(木) 08:07:26.82

>>604
>x.func(&y) の呼び出し自体がバグ、ということさえありうる。
それはyの単体試験で確認しておけばいいのでは?
そのためにyは外部とのインターフェースをpublic/privateで限定し
そのインターフェースが整合しているかどうかだけ確認できれば問題ない。
xの実体がわからないようなxとyの結合コードはその後で試験でしょ。
この時はfuncはステップオーバーする程度でxの実体なんてどうでもいい。

612 ：デフォルトの名無しさん：2011/03/10(木) 09:09:42.84

>>611
yの単体試験でそれがバグかどうか確認できるためには、
yの任意のpublicメソッドが任意の順番で呼ばれても全て正しい動作、
というくらい強い条件を満たす必要がある。

613 ：612：2011/03/10(木) 09:10:35.56

さらに、任意のタイミングで、も追加。

614 ：デフォルトの名無しさん：2011/03/10(木) 09:14:50.96

>>609
boost::Python は楽だけど、Cython はもっと楽。
結局、グルーコード自体も他言語（この場合はPython）で生成させた方が楽だったり。

615 ：614：2011/03/10(木) 09:30:15.57

でも、その主張の方向性はいいと思う。
Cのマズい点をC++使いが挙げると、どうしても>>586のリストを
更新する感じになっちゃうんで、むしろC++の良いところを
挙げていく方がいい。

616 ：デフォルトの名無しさん：2011/03/10(木) 09:53:34.63

PHPかJacascriptを主流にして、コンパイラの最適化でC/C++なみの速度を出すのがベスト。
いちいち関数の戻り値を受けるのに変数定義するのとか面倒だ。
コンパイル時に判明するだろ。

617 ：デフォルトの名無しさん：2011/03/10(木) 09:57:14.76

やはり時代は OCaml か……

618 ：デフォルトの名無しさん：2011/03/10(木) 10:11:38.75

なんか話がmyframework with C vs. myframework with C++になってるな
C vs. C++のつもりで書き込むと馬鹿と言われそうだ

619 ：デフォルトの名無しさん：2011/03/10(木) 10:18:58.07

いろいろ言語あるのは面倒だ。
C/C++の一つの後継であるPHPかJacascriptに統一して発展させるのがいいよ。
これでGUIや3Dも出来るようにする。
すでに実用されていて過去のソースも沢山あるし。

620 ：デフォルトの名無しさん：2011/03/10(木) 11:27:22.73

>>604
> x.func(&y)

これで C++ の問題点を主張しようとしてるの？
C でも func が関数ポインタだったら同じことじゃないの？
あるいは x_func(&x, &y) とか。

621 ：デフォルトの名無しさん：2011/03/10(木) 11:31:22.81

>>599
>> 例外はcatchしなきゃいけないという考えがJavaドカタ並に間違っている。
> 詳しく。

http://www.parashift.com/c++-faq/exceptions.html#faq-17.6
> Here are some "wrong exception-handling mindsets" in no apparent order:
> * The return-codes mindset: ...

622 ：デフォルトの名無しさん：2011/03/10(木) 12:02:02.31

>>621
>Exception classes cross subsystem boundaries

C++でしか使えない例外投げてるのに、よく言うよな
共通言語なんとかの例外でも投げればいいんじゃねえの

623 ：デフォルトの名無しさん：2011/03/10(木) 12:29:37.98

>>621
例外をcatchしたとき、どこからthrowしたか知るのは難しい。
特に下流で処理しない場合は、上流でパスが合流してしまうのでその傾向は顕著である。
おそらく、同じ「型」の例外ならば合流して良いということにしたいんだろうが、
そんな単純な例外処理ばかりじゃないし、だからといって様々な状況を区別できるよう
型のバリエーションを増やす（そのサイトにある"Using the bits / data ..."の方法)のは
>>517 >>520にあるように可読性が下がる。
可読性という点でいえば、>>460のような問題もある。

あと、そのサイトの"The Java mindset:"の項では、Javaがメモリーリソース以外を
try/finally で処理するのに対し、C++はRAIIで処理するから try/catch ブロックは少なくてすむ
(この辺りが「Javaドカタ」とか>>589がいいだした理由かな？)と書いてあるけど、
メモリーリソース以外をRAIIで処理することについては>>535 >>538に問題が書いてある。

624 ：デフォルトの名無しさん：2011/03/10(木) 12:39:59.23

>>620
>C でも func が関数ポインタだったら同じことじゃないの？

同じことだね。だから、関数ポインタを使わないでも実現可能な処理は
関数ポインタを使わない方が読みやすい。
実際、関数ポインタを乱用するのは悪いコーディングスタイルだ。

>あるいは x_func(&x, &y) とか。

Cではオーバーロードさえないのでx_funcは一意に決まる。

625 ：デフォルトの名無しさん：2011/03/10(木) 12:45:50.75

>>623
> 例外をcatchしたとき、どこからthrowしたか知るのは難しい。
fopen() がヌルを返したとき、どのシステムコールが失敗したか知るのは難しいな。

> >>517 >>520にあるように可読性が下がる。
> 可読性という点でいえば、>>460のような問題もある。

> メモリーリソース以外をRAIIで処理することについては>>535 >>538に問題が書いてある。

すでに全部反論なりなんなりのレスがついてるんだけど、それについてはどう考えてるの？

626 ：デフォルトの名無しさん：2011/03/10(木) 12:48:41.28

>>624
じゃぁなんで C++ の仮想関数は「 virtual を乱用するのは悪いコーディングスタイルだ」で
済ませられないの？

あと、 C++ にはオーバーロードがあるけど x_func() の呼び出しは一意に決まるよ。
違いを言うなら、単純な grep だけじゃ定まらないってところだろうね。

627 ：デフォルトの名無しさん：2011/03/10(木) 12:56:18.19

>>625

>>460についてる反論は、C++にはRAIIがあるから、というもので
これについては>>475 >>535が再反論になる。

>>517についてる反論は、戻り値で処理するとか、投げる例外の基底型は
たかだか一つとか書いてるけど、たかだか基底型ひとつでは処理しきれない場合がある
というのが>>623の主張だし、複数の型を用意すべきというのが>>621の"Using the bits / data ..."の提案。

>>535 >>538についてるレスはとても反論とはいえないね。
C++では安全性の低いプログラムしか書かないというならいいけど。

628 ：デフォルトの名無しさん：2011/03/10(木) 13:02:15.27

>>626
OK. virtualを乱用するのは悪いコーディングスタイルだ。それでいい。
そうなるとvirtualなんて滅多に使用しないから、
C++の継承なんて全然便利じゃない。使用しないから。
だからCの構造体+委譲+必要最小限の関数ポインタでオブジェクト指向を実現するよ。
(または、動的型の言語とCを組み合わせて使うよ)

629 ：デフォルトの名無しさん：2011/03/10(木) 13:09:39.54

>>628
templateで使うときに共通インターフェースがあると便利なんでvirtual無しでも
crass使いますけど。

630 ：デフォルトの名無しさん：2011/03/10(木) 13:14:39.72

Cで委譲とか言ってる人は具体的にどうやって実装してるの？
関数ポインタ使わずにできるのそれ？

631 ：デフォルトの名無しさん：2011/03/10(木) 13:27:37.53

>>627
RAII は役に立つし、デストラクタでのエラー処理が問題になるなら
明示的な破棄処理と組み合わせて正しく処理にもできる。 (>>539-545)

> たかだか基底型ひとつでは処理しきれない場合がある

そういう状況だと戻り値でも同じか、例外のほうがいくらかマシな状況にはなってるんじゃないの？

632 ：デフォルトの名無しさん：2011/03/10(木) 13:29:32.64

>>628
「最小限の virtual 」でやったほうが楽だし間違いも減るんじゃない？

633 ：デフォルトの名無しさん：2011/03/10(木) 13:41:04.31

"For C programmers that hate C++"
http://users.softlab.ece.ntua.gr/~ttsiod/cpp.html
http://www.reddit.com/r/programming/comments/fzwlh/for_c_programmers_that_hate_c/
> 191 ポイント (70% like it)
> 330 up votes 139 down votes
> # 492個のコメント

634 ：デフォルトの名無しさん：2011/03/10(木) 15:27:07.61

>>632
あまり使わない処理が構文でサポート（トラップ込みで）されてるよりも
シンプルな言語でやりくりしたい。
そんな好みが尊重されてもいいと思うの。

635 ：デフォルトの名無しさん：2011/03/10(木) 18:20:18.16

>>629
templateで総称型やりたいってのは、また別の話じゃ？

>>630
vtable相当のことをやりたかったら関数ポインタ必要。
今はそうじゃない（できるだけvirtual減らす）という話なので、
関数ポインタなんて無くてもできる。

>>634
構文サポート欲しいってのも好みだけどね。

636 ：デフォルトの名無しさん：2011/03/10(木) 20:59:06.12

もう少し中身が見える構文にしてくれればいいのにな
仮想関数はhoge.foo()じゃなくてhoge.virtual[foo]()みたいに呼び出すようにすべきだった

637 ：デフォルトの名無しさん：2011/03/10(木) 21:12:04.36

>>631
明示的な破棄処理を書けば正しく処理できるのは否定しないよ。
ただ、明示的に書く必要があり、RAIIは保険として使うというのなら
>>467 >>472や>>621の"The Java mindset:"に書いてあるような
RAIIがあればtry/catchを減らせる、というのは成り立たないよ。

>> たかだか基底型ひとつでは処理しきれない場合がある
> そういう状況だと戻り値でも同じか、例外のほうがいくらかマシな状況にはなってるんじゃないの？

そっちが何を比べてどうマシと言っているのか分からないけど、>>517のような場合
> 戻り値：関数fを探して、その関数でリターンしてるところをチェックし、エラー処理のコードと比較
> 例外：関数fを探して、例外を投げる可能性のある全てをチェックし、エラー処理のコードと比較
の二つなら、前者のほうが圧倒的に楽だと思うよ。

638 ：デフォルトの名無しさん：2011/03/10(木) 21:21:31.84

>>604
どうせ実行時の型を無視できないなら動的型付け言語でいいよね。圧倒的に生産的だし。

639 ：デフォルトの名無しさん：2011/03/10(木) 23:30:03.78

>>604
>継承は、ちゃんと設計できてれば、xの状態遷移については
>全ての派生型で問題ないことを保証するだろうが、

継承だけじゃなくテンプレートとかも、きちんと設計するのは苦痛だよな。

必要最低限だけ確実に実装すれば、プログラマ同士が満面の笑みでがっちりと
握手出来るのが C や LL の良い所。

640 ：デフォルトの名無しさん：2011/03/11(金) 00:32:12.41

ローカルなsubsystemの中で閉じるという感覚がなくなってるな

テンプレートやら何やら発明された瞬間に全世界が変わるのが普通
変化を拒否したら負け
という世界観

641 ：デフォルトの名無しさん：2011/03/11(金) 01:05:26.43

>>637
> ただ、明示的に書く必要があり、RAIIは保険として使うというのなら
> >>467 >>472や>>621の"The Java mindset:"に書いてあるような
> RAIIがあればtry/catchを減らせる、というのは成り立たないよ。

どういうことなの？

たとえば Java で File は finally の中で close() しなければリソース漏れを
起こす可能性があり、 finally を書くために try ブロックが必要になる。

これに対して C++ の std::ofstream は正常フローの最後に close() の
明示的な呼び出しを書いておけば、リソース解放のために例外を catch する
必要は無く、当然 try ブロックも不要になる。これは RAII による恩恵だ。

・・・と思ってるんだけど、何か間違ってる？

642 ：デフォルトの名無しさん：2011/03/11(金) 01:19:34.07

>>637
>>517 の問題は（ >>519 で指摘の入っているとおり）関数の仕様が無い状態で
「すべて漏れなく処理」を望んでいる時点ですでに破綻している。

戻り値なら簡単に可能であるかのように書かれているが、ある時点の実装を見て
実際の戻り値を洗い出しても、仕様が無ければ後で追加・変更される可能性が
あり、そうすれば当然漏れが出る。

問題が破綻しないように事前に仕様があるという前提を置けば、戻り値なら
if (result == FOO_ERROR) ... で、例外なら catch (FooError& e) ... で、
同様のコードを書くことになる。

エラーに対してのリアクションが、もっとも典型的な「リソースを解放しながら
処理を中断する」というものであった場合、例外＋ RAII のほうが間違いを
起こす可能性が少なく、後で例外が増えても問題は起こらず、こういった点で
マシだと考えている。

エラーに対してのリアクションが↑以外の何か固有の処理で、しかも処理方法が
異なるエラーが複数返ってくるというなら、 >>522 の言うとおりだろう。

643 ：デフォルトの名無しさん：2011/03/11(金) 01:23:22.42

>>639
「C や LL」で設計するのと C++ で継承やテンプレートを設計するのと、
何が違って苦痛なの？

「必要最低限だけ確実に実装すれば～」って話も、「C や LL」は
よく知ってるのに C++ はよく知らないプログラマならそうだろうっていう
当然の話じゃないの？
（「よく知ってる」人口の違いを言ってるんなら否定はできない気はする。）

644 ：デフォルトの名無しさん：2011/03/11(金) 01:29:16.33

>>643
>「必要最低限だけ確実に実装すれば～」って話も、「C や LL」は
>よく知ってるのに C++ はよく知らないプログラマならそうだろうっていう
>当然の話じゃないの？

どゆこと？
「C と LL と C++ の全てを知っているプログラマは必要最低限以外の実装も
きっちりこなすはずだ」と言いたいの？

645 ：デフォルトの名無しさん：2011/03/11(金) 01:40:52.06

>>644
いやぜんぜんちがう。

「必要最低限だけ確実に実装すれば～がっちりと握手出来る」なんてのはソフトでも
ハードでも、ほとんど何にでも言える話で、それが C++ ではそうはいかないとなると、
「必要最低限」を示した文書が読めないとかそういう話なのかな、と。

テンプレートライブラリが引数に対して明示する要求（「コンセプト」と呼ばれるもの）は
慣れてないと何が書いてあるのかさっぱりわからない、とか。
↓こんなやつね。
http://www.sgi.com/tech/stl/InputIterator.html

646 ：デフォルトの名無しさん：2011/03/11(金) 01:48:39.22

>>645
C や LL では「必要最低限」は文書で示す物ではないからね。
そこまでしないと使えない言語を使うのは苦痛だな。

647 ：デフォルトの名無しさん：2011/03/11(金) 01:52:18.63

>>646
別にコンセプト使わなきゃ C++ 使えないわけじゃないし、
似たようなことを C でマクロ使ってやろうとすれば同じようなことになるし、
やっぱり >>639 の真意はわからない。

648 ：デフォルトの名無しさん：2011/03/11(金) 02:00:38.70

>>647
C++ はちゃんと設計すれば問題無いと言う人間が居たり、
C++ でも設計しないでプログラムを書けると言う人間が居たり、
話がコロコロ変わって大変ですね。

649 ：デフォルトの名無しさん：2011/03/11(金) 02:10:07.47

>>648 どっちも言語問わず当然成り立つ話なんから、誰もそんなことわざわざ言わないと思うよ。

650 ：デフォルトの名無しさん：2011/03/11(金) 02:11:02.31

そうだな。多分、このスレだけなんだろうな。

651 ：デフォルトの名無しさん：2011/03/11(金) 02:14:24.18

>>650 ほぅ。どのレスのこと言ってるの？

652 ：デフォルトの名無しさん：2011/03/11(金) 02:16:02.04

このスレを上から順に読んで行けば君にも分かると思うよ

653 ：デフォルトの名無しさん：2011/03/11(金) 02:37:01.23

>>648
それは開放閉鎖原則といって
継承を正当化するためのキャッチフレーズのようなものらしい

654 ：デフォルトの名無しさん：2011/03/11(金) 02:39:10.12

>>653
レス番間違えてるよ

655 ：デフォルトの名無しさん：2011/03/11(金) 09:56:08.89

>>641
こういう理解度でもC++が使えるのは、C++の利点といえるのだろうか？

656 ：デフォルトの名無しさん：2011/03/11(金) 09:59:02.50

また裸の王様はじまったな。

657 ：デフォルトの名無しさん：2011/03/11(金) 10:05:42.02

>>655
なんでどこが間違ってるか書けないの？

658 ：デフォルトの名無しさん：2011/03/11(金) 10:18:08.47

>>641
>>657
その例では、例外が投げられたとき呼び出されてるのは正常系のcloseじゃなく
デストラクタだよ。ofstreamはデストラクタでcloseしてくれる。
でも、デストラクタではファイルクローズに失敗したときに出来ることは殆ど無い。例外投げれないし。
実際、ofstreamはデストラクタでは失敗を無視する。

なので、ちゃんとリソース解放の失敗まで含めて安全なプログラムするなら
RAIIじゃ駄目なときがある。駄目な場合の例は>>535

659 ：デフォルトの名無しさん：2011/03/11(金) 10:23:09.78

>>642
RAIIでは十分じゃない場合が多々ある(>>535)ということが書かれているのに、
それでもRAIIのほうが間違いを起こす可能性が少ないというならば、
ちゃんと理由を書いてほしい。

660 ：デフォルトの名無しさん：2011/03/11(金) 10:34:32.72

>>642
>>521でも指摘されてるけど、コードと仕様が対応しているかチェックする必要があるよね。
だから仕様はあるという前提でいいかと。

> 問題が破綻しないように事前に仕様があるという前提を置けば、戻り値なら
> if (result == FOO_ERROR) ... で、例外なら catch (FooError& e) ... で、
> 同様のコードを書くことになる。

ここで話題にされてるのは、書く難しさではなく読む難しさだよ？
仕様に記述されていない例外が本当に投げられない
（例外仕様を使うならstd::unexpected()が呼び出されない）
ということを確信するためにはいったいどれほどのコードを読む必要があるのか。

って書いてから気がついたけど

> エラーに対してのリアクションが↑以外の何か固有の処理で、しかも処理方法が
> 異なるエラーが複数返ってくるというなら、 >>522 の言うとおりだろう。

ってあるから、もしかしたら持ってる見解は同じなのかもしれない。
でも、それってそんなに特殊な例かな？ >>621のリンク先ではそういう処理を
例外で扱う話がFAQで載ってるんだけど。

661 ：デフォルトの名無しさん：2011/03/11(金) 10:41:04.23

>>658
> 正常フローの最後に close() の明示的な呼び出しを書いておけば
って書いてあるのに読み飛ばしてる？

662 ：デフォルトの名無しさん：2011/03/11(金) 10:48:36.26

>>661
詳しく。
こっちは open() ～ close() の間のどこかで例外が投げられたケースを考えてた。

663 ：デフォルトの名無しさん：2011/03/11(金) 10:55:03.76

>>660
> でも、それってそんなに特殊な例かな？ >>621のリンク先ではそういう処理を
> 例外で扱う話がFAQで載ってるんだけど。

どこのこと言ってるの？よくわからない。

「このエラーのときはこうする」ってのがいくつか決まってることはあるだろうと思うけど、
その場合はハナから列挙されてない例外について考慮する必要はないだろう。

「漏れなく」があるとしたら型は関係なくて「ここでは例外などで処理を中断しては
いけない」という話になるんだろうけど、それなら catch (...) すれば（してあれば）いい
わけで。これはいろんな戻り値を返す関数での「その他のエラー」ってやつに対応する
ことになる。

特定の場所で全部の例外を漏れなく catch なんて仕様は稀だと思うけど、こればっかりは
言い切れないからなぁ。やっぱり例を示してもらうのがいいんだろうね。

仮に、投げる例外を列挙した仕様が先に確定してしまっていたのなら、例外仕様を使うか、
あるいは関数の実装全体を catch (...) で囲うかしてあればよくて、そうじゃなければ漏れてる。
（こんなコード書かせる仕様に文句を付けたいところだというのはお忘れなく）

664 ：デフォルトの名無しさん：2011/03/11(金) 11:06:14.42

>>662
もちろんずっとそのケースを想定してるわけなんだけど、
伝わらないようだから具体的なコードを書いてみようと思う。

template<typename T>
void save_to_file(char const* filename, T const& obj)
{
std::ofstream file(filename);
file.exceptions(std::ios::badbit | std::ios::failbit);
file << obj;
file.close();
}

このコードで、 file << obj で何かに失敗して例外が飛ぶと仮定しても
リソース漏れは起こらずその例外は呼び出し元に伝えられる。

逆に file << obj が成功して file.close() が何かに失敗し場合、
file.close() から std::ios::failure （あるいはその派生型）が例外として
伝えられ、それがそのまま呼び出し元に伝えられていく。

665 ：664：2011/03/11(金) 11:21:40.58

念のため先に言っておくけど、 file << obj が失敗したときにさらに file の
デストラクタで close() か何か失敗したときの話は >>541 ね。

666 ：デフォルトの名無しさん：2011/03/11(金) 11:56:41.69

>>663
> どこのこと言ってるの？よくわからない。
"Using the bits / data within ..."の銀行サブシステムの三つの例外の話。

>>665
ファイル自体に問題があって書き込み失敗したのなら>>541だけど、
file << obj が内部で文字列のエンコーディング変換に失敗とかして
データの一部が破損しちゃった場合、
それで例外が投げられたのならファイルクローズの失敗には対処したいよ。

667 ：デフォルトの名無しさん：2011/03/11(金) 12:08:35.66

>>663
> 仮に、投げる例外を列挙した仕様が先に確定してしまっていたのなら、例外仕様を使うか、
列挙した仕様が先にないのなら、仕様があれば例外コードが読みやすいって話はなんなの？
それに例外仕様は投げられる可能性のある型をコンパイル時にチェックしてくれるわけじゃない。
コメントとあんまり変わらん。

あと、catch(...)は万能だけど、そこ通ったら普通はバグじゃない？
もしバグじゃないなら、あんたとは分野が違うってことで納得する。

668 ：デフォルトの名無しさん：2011/03/11(金) 12:13:35.22

>>663
> 「漏れなく」があるとしたら型は関係なくて
どうしてそうなる？詳しく。

669 ：デフォルトの名無しさん：2011/03/11(金) 12:37:59.06

>>658
ファイルcloseのエラーはリソース解放の失敗を意味するわけじゃないよ。
バグで間違ったハンドル渡してるとかのケースは別として。

670 ：デフォルトの名無しさん：2011/03/11(金) 12:40:42.37

>>669
write や fflush の失敗かもしれないって？知ってるって。

671 ：デフォルトの名無しさん：2011/03/11(金) 12:54:47.54

>>636
バカすぎ

672 ：デフォルトの名無しさん：2011/03/11(金) 16:14:37.50

C++プログラマは、ただ単にC++のユーザベース・コードベースを増やしたいから
better C などと甘言を弄してCプログラマをC++へ引き込もうとしてる。
そんな安い態度が見え見えなので、Cプログラマは嫌悪を示している。

673 ：デフォルトの名無しさん：2011/03/11(金) 17:03:40.86

>>663
> 特定の場所で全部の例外を漏れなく catch なんて仕様は稀だと思うけど、こればっかりは
> 言い切れないからなぁ。やっぱり例を示してもらうのがいいんだろうね。

>>621のリンク先の subsystem in a banking app. の例でもいいんだけどさ。
subsystem を呼び出すとき、呼び出した場所の近傍でそいつが投げる例外を
漏れなく処理するのは普通だよ。
そんなのはシステム境界面で処理しないと発散してしまう。

674 ：デフォルトの名無しさん：2011/03/11(金) 17:15:28.13

>>672
このスレの抗争はそれが原因か……

675 ：デフォルトの名無しさん：2011/03/11(金) 19:17:04.99

>>664
おめえ、データベースのセッション中になんかエラーがあったら
セッション切断し損なっても無視するっていってんの？
おめえの方法だとそういうことになるんだけど。

676 ：デフォルトの名無しさん：2011/03/11(金) 21:11:46.28

OSSのCプロジェクトでは、日夜こういう会話が（主にメーリングリストで）繰り広げられているという……

C++ PG「なんでC使ってるんすか？C++理解できないんすか？www」
C PG 「何でってCで十分だからだけど」
C++ PG「C++理解できないんすねwwwロートルwww」
C PG 「（うぜぇ……）で、何の用ですか？」
C++ PG「パッチ書いてあげましたよ。もちろんC++でwww」

しかし平均的C++プログラマは>>586なので、パッチはゴミである。

C PG 「……全然使い物にならないんだけど」
C++ PG「は？C++なのにダメなわけないじゃないすか！C++ですよ！？」
C PG 「そういう問題じゃ……」
C++ PG「やっぱりロートルはダメだなー！C++が理解できないなんて！！」
C PG 「もう帰ってくれ……」

こうやってCプログラマはC++を嫌っていくのである。

677 ：デフォルトの名無しさん：2011/03/11(金) 23:24:19.94

Cマ可哀想！

678 ：デフォルトの名無しさん：2011/03/12(土) 00:00:19.37

>>666
> file << obj が内部で文字列のエンコーディング変換に失敗とかして
> データの一部が破損しちゃった場合、
> それで例外が投げられたのならファイルクローズの失敗には対処したいよ。

「対処」って、具体的にどうしたいの？

「エンコーディング変換に失敗」を捨てて「ファイルクローズの失敗」を通知
するの？それとも両方の情報をどうにかして混ぜたエラー（戻り値のビット和
とか例外オブジェクトの入れ子とか）を通知するの？それ以外？

・・・こういう聞き返しが要らないように念押して >>541 を挙げてたん
だけどなー。残念。

679 ：デフォルトの名無しさん：2011/03/12(土) 00:06:04.33

>>675
「なんかエラー」と「セッション切断し損なった」との２つのエラーについて、
無視しないとしたらどうしたいのか、つまり >>678 と同様のことを聞きたい。

あと、具体的にどのデータベース API を想定しているのか示してもらえると
話がわかりやすいんで、できればおねがい。

680 ：デフォルトの名無しさん：2011/03/12(土) 00:43:50.96

>>666
> "Using the bits / data within ..."の銀行サブシステムの三つの例外の話。

んー？これが「エラーに対してのリアクションが何か固有の処理で、しかも
処理方法が異なるエラーが複数返ってくる」という例なの？

そこで挙げてる三つの種類の例外がひとつの関数から飛んでくるなんて話には
なってないし、それを一箇所で全部 catch しないといけない、なんて話にも
なってないよ？

例外オブジェクトの区別にはオブジェクト内のデータじゃなくて型を使うべし、
っていう話でしょ。

それに、関数呼び出しに対してそこから投げられる例外を逐一 catch する
ようなやり方は "The return-codes mindset" として否定してるし。

まぁ元々の「それってそんなに特殊な例かな？」については、わりとよくある
だろうと思ってるから、深く突っ込む必要はなさそうだけどね。

そういうときは戻り値を使って分岐したほうがいいだろうと思う。で、たぶん
それらは「エラー」とは呼ばない。

681 ：デフォルトの名無しさん：2011/03/12(土) 00:50:14.71

>>667
> 列挙した仕様が先にないのなら、仕様があれば例外コードが読みやすいって話はなんなの？

仕様があるときの話を聞かれてるのか、ないときの話を聞かれてるのか、よく
わかんない。書き込みミスってない？

「～って話」をアンカーで指してもらえるとたぶんわかる。

> それに例外仕様は投げられる可能性のある型をコンパイル時にチェックしてくれるわけじゃない。
> コメントとあんまり変わらん。

そうだね。残念だね。でも動作は明確に変わるよ。それが望ましいことは
少ないんだけど。

例外仕様の動作を受けれるという前提なら、とりあえず仕様に列挙された例外と
コード中の例外仕様に記載された例外を見比べれば対応は明確だ、という話ね。
前提があまり成り立たないだろうとは思ってる。

> あと、catch(...)は万能だけど、そこ通ったら普通はバグじゃない？

C やアセンブリやそのほか例外を想定していない何かの API と C++ との境界
では必要になる。すべての例外を catch するのが正しいので、バグじゃない。

682 ：デフォルトの名無しさん：2011/03/12(土) 00:53:27.13

>>668
「漏れなく」ってところでは catch (...) が必要になるし、それが書いてあれば
仕様どおり漏れなく catch されていることは明確だから。

これで話がつかないなら「漏れなく」の意味が何か違うのかもね。

683 ：デフォルトの名無しさん：2011/03/12(土) 02:42:20.52

>>670
std::fcloseやstd::fstream::~fstreamは確実に解放を成功させるから、POSIXのcloseみたいに
エラーコードを見て適宜繰り返し呼ぶ必要はないのよ

684 ：デフォルトの名無しさん：2011/03/12(土) 08:03:56.83

>>680
>>673

685 ：デフォルトの名無しさん：2011/03/12(土) 08:07:39.68

>>681
> だから仕様はあるという前提でいいかと。
って書いてるよ？
とうか、そっちが勝手に仕様が無い前提の話をしてるだけじゃない？
質問者がそんなこと言い出したことは一回も無いよ？（あったらポインタ示して？）
仕様とコードを一致させるためコードレビューが必要とは言ってたけど。

もしかして、質問者は仕様もろくにないような開発をしているんだ、
という印象操作のつもり？

686 ：デフォルトの名無しさん：2011/03/12(土) 08:14:41.61

>>678
このアホはC++でうまく扱えないケースは扱わなくていい、ということにしたいのか？
もちろん両方通知する。
変換に失敗した文字列に関する情報と、成功した文字列が正確にファイルへ
書き込み完了したかどうかは独立の問題だからだ。

そしてお前はアホだからデータベースはうまく扱えない>>675

687 ：デフォルトの名無しさん：2011/03/12(土) 08:19:21.12

>>682
あんたは>>673のような書き込みを見ても、それでもサブシステムから投げられる
例外を漏れなく処理する、というのをcatch(...)で受け取ることだと思うんだ？
ほんと、分野が違うわ。

688 ：デフォルトの名無しさん：2011/03/12(土) 08:31:52.85

>>683
そうだね。そのファイルストリームに対して出来ることは何も無いね。
でも、誤解する人もいないだろうけど、ストリームが解放されることと
期待した結果が得られる（ファイルクローズ成功）ことは別。
ここでリソース解放の失敗と言ってるのは、明らかに後者のこと。
そしてそのストリームに対してできることが無いことは、
アプリケーションにやることが無いことを意味しない。

689 ：デフォルトの名無しさん：2011/03/12(土) 13:38:23.32

なんか話がズレてるような。
RAIIはリソース解放処理を簡潔にし解放に関するバグを根絶する為の
手法なのであってI/Oエラー対応は全然別の話。

690 ：デフォルトの名無しさん：2011/03/12(土) 14:44:21.47

>>673 (>>684) (>>687)
「発散する」って、何が？それが発散するとどう困るの？

691 ：デフォルトの名無しさん：2011/03/12(土) 14:59:45.85

>>685
んー。聞きたいことがはっきりとはわかってないんだけど、
「投げる例外型を列挙した仕様が無い場合、
　例外ベースの処理は読むのがむずかしいのではないか？」
という話かな？

例外型の列挙が無くても、処理が失敗するかどうか（つまり例外が発生するかどうか）と
失敗した場合の状態（例外安全性のレベル）についての仕様があれば、多くの処理では
あまり問題なかったりする。
（個人的にこう思ってるけど、このことについて強い自信があるわけじゃない。
　問題のあるケースがあれば知りたいと思ってる。）

この考えの元では、新しく書くコードでも例外発生時の動作として問題になるのは、
変に catch して例外を握りつぶしたり意味の違う例外にしてしまわないこと（例外中立の維持）と、
例外発生時の状態を不正にしないこと（例外安全性の維持）の２点になる。

前者は catch してるところを見れば明らかで、後者は RAII の徹底ができているかを
見ればいい。後者について副作用の順序を確認するのは簡単とは言えないけど、
それは例外特有の話ではなく、戻り値でもそれ以外のエラー通知方法でも同じこと。

692 ：デフォルトの名無しさん：2011/03/12(土) 15:10:42.18

>>686
> 変換に失敗した文字列に関する情報と、成功した文字列が正確にファイルへ
> 書き込み完了したかどうかは独立の問題だからだ。

いや、だから、その２つを個別に両方通知するべきなのは当然で、みんなわかってる。

問題にしてるのは、書き込み途中に何か問題が発生して、処理を中断してその問題を
伝えようとしてたら、さらにファイルのクローズに失敗した場合。

この場合はファイルへの書き込みは全部終わってないんだから、クローズの失敗を
大きく扱う必要は無くて、デストラクタを使って（ログの出力程度で済ませて）も問題ないよね、
って話。

データベースの話も同様に考えてる。 >>679

693 ：デフォルトの名無しさん：2011/03/12(土) 16:32:35.99

>>688
もしかしてcatch節で後処理すること知らない人？

694 ：デフォルトの名無しさん：2011/03/12(土) 16:46:06.04

>>686
問題のケースは↓の (1) になると思うんですが、
ここでどうするべきだという話なんでしょうか？

template<typename T>
void save_to_file(char const* filename, T const& obj)
{
std::ofstream file(filename);
file.exceptions(std::ios::badbit | std::ios::failbit);
try
{
file << obj;
file.close();
}
catch (std::exception& e1)
{
if (file.is_open())
{
try { file.close(); }
catch (std::exception& e2)
{
// ... (1)
}
}
throw;
}
}

695 ：デフォルトの名無しさん：2011/03/12(土) 17:17:22.37

>>688
ofstreamが管理している資源はストリームだけであり、確実にファイルに書き込む責任という資源は所有していない
OO的、RAII的に言えばリソース解放というのは所有している資源の解放というのは明らか
>>641がなんて書いていようが関係無い

696 ：デフォルトの名無しさん：2011/03/13(日) 10:49:12.39

>>689
まったくそのとおり。
だから、RAIIを使えばtry/catchブロックを減らせる、というのはナンセンスと主張してる。
リソース解放に伴うエラー（I/Oエラーなど）の対応は別にしなきゃならんのだから。

>>693
なんでそうなる？
そうじゃなくて、catch節で後処理しようぜって主張だよ。
>>641はそうじゃないだろ？

>>695
うん。それならそれでいいんだ。というより、あなたの主張は全面的に正しいと思う。

697 ：デフォルトの名無しさん：2011/03/13(日) 10:55:21.01

>>690
サブシステムの例外をそれを呼び出した関数で処理しない場合、
呼び出した関数を呼び出す関数群、その関数群を呼び出す関数群、
などなどに例外が伝搬してしまうから。

どんな例外を投げるのかはサブシステムの機能の一部なわけで、
それが伝搬してしまうのはモジュール化が壊れてる。
モジュール化を高めるために、上に例外を再送する場合でも、
一度キャッチして自らのシステムの例外として再定義した方が良い。

実際、システム境界面で処理しない場合に、サブシステムが変更になって投げる例外が変更／増減した場合、
変更箇所がグローバルになってすごい困ると思うんだけど、どうだろうか？

698 ：デフォルトの名無しさん：2011/03/13(日) 11:28:10.58

>>680
> そこで挙げてる三つの種類の例外がひとつの関数から飛んでくるなんて話には
> なってないし、それを一箇所で全部 catch しないといけない、なんて話にも
> なってないよ？

リンク先の該当箇所は「エラーを通知される側が、複数種類のエラーから
個々のエラーを区別する方法」を論じてる。
この時点で、一つの関数から複数種類のエラーが通知されるケースを
想定してることは明らかだ。
なぜなら１関数１エラーの場合に「通知される側がエラーを区別できない」なんて状況は、
真面目に論じるに値しないからだ（あんたにはそうじゃないかもしれないが）。

> それに、関数呼び出しに対してそこから投げられる例外を逐一 catch する
> ようなやり方は "The return-codes mindset" として否定してるし。

だれもそんなことは主張してない。
ただ、>>673 >>697 のように、漏れなく例外を catch するケースはあって、
その場合に著しく読み難いと主張してる。

>>691
それは複数の"logically distinct kinds of errors"が単一の関数から投げられるケースは考えないって言ってるんだよね？
それはもういいって。
そんな単純なケースなら確かに例外はうまくいくんだろうが、それは>>621のFAQで挙げられてる銀行の例とは違う。

699 ：デフォルトの名無しさん：2011/03/13(日) 11:42:56.45

>>692
ファイルへの書き込みは（壊れた文字列以外）全部終わってて、それで壊れた文字列と
クローズ失敗をそれぞれどうするかってケースだよ。
しょーもない例で悪いが、webをクロールしてデータを集めて、それをUTF-8変換して
ファイルに保存する場合（壊れた文字列は変換せずにまとめて別ファイルに保存）とか。
まあ、所詮作られた例なんで何とでも言えるけど、両方同時に扱うケースなど無い、なんて
ちょっと強弁しすぎだろう。

>>694
別パーティションのファイルへ書き込んだり、NFS使ってるならローカルのファイルへ書き込んだり。

あとさー、ファイルの例はあんまり深刻さが理解できないかもだけど、
データベースのセッション生殺しはヤバすぎるって（だってプログラムは切断したつもりなんでしょ？）。
それじゃすぐセッション埋まっちゃうよ。

700 ：デフォルトの名無しさん：2011/03/13(日) 16:42:11.88

C++の開発プロジェクトでは、日夜こういう会話が（主に会議室で）繰り広げられているという……

顧客「ファイルを保存する際は、エンコーディングのエラーと書き込み完了の両方を必ずチェックしてください」
C++ PG「できません」
顧客「え、何故ですか？」
C++ PG「RAIIではどちらか片方の例外しかキャッチできませんから。そんなことも分からないんですか？（ため息）」
顧客「（うぜぇ……）じゃあRAII以外でやってください」
C++ PG「は？RAIIで出来ないなら仕様が悪いんですよ。仕様を変えてください」
顧客「何でですか！？それ全然理由になってないですよ」
C++ PG「C++が理解できない無知な顧客は困るなー！わがままばっかりで！」
顧客「……もう帰ります」

こうしてC++の業界シェアはJavaやLLに奪われていくのだった。

701 ：デフォルトの名無しさん：2011/03/14(月) 11:48:21.64

>>699
> >>694
> 別パーティションのファイルへ書き込んだり、NFS使ってるならローカルのファイルへ書き込んだり。

さすがにそれはないだろ。ファイル名ひとつ受け取った関数のやることじゃない。
エラーを受け取ったアプリケーション側がそういう対処をするならわかるけどさ。
どうやって２つのエラーを同時に両方返すのか、って話が聞いてみたいな。
個人的に、そんな状況を報告してくるAPIにはお目にかかったことが無いんで。

702 ：デフォルトの名無しさん：2011/03/14(月) 12:04:07.70

個人的に興味のあるところを抜粋した最近の流れ。

例外使うとコード読むのが難しくなるよ。
↓
catchしすぎだから難しいんだよ。
RAII使えばほとんどcatchしなくていいよ。
↓
RAIIはリソース解放のエラーを扱えないから、やっぱりcatchが要るよ。
↓
RAIIと明示的な解放処理と組み合わせればcatchしなくていいんだよ。
↓
失敗が重なったときに片方しか伝わらないから、やっぱりcatchが要るよ。
↓
いまここ

703 ：デフォルトの名無しさん：2011/03/14(月) 12:34:44.21

>>701
>>700

704 ：デフォルトの名無しさん：2011/03/14(月) 12:37:23.63

>>701
二つの例外型を多重継承した型を投げれば良いじゃん。
いちいち型を定義するのは面倒だけど、エラーというセマンティクスを
型というシンタックスへ写像するってのは、そういうことだからね。

705 ：デフォルトの名無しさん：2011/03/14(月) 12:44:39.16

>>704
それができれば簡単なんだけど、元の例外をstd::exception&で受けてたら無理なんじゃないの？
たとえば >>694 のコードだと file << obj からどんな例外が飛んでくるかわからないわけで。
で、例外だと多重継承できれば呼び出し元の期待にはそのまま答えられそうなんだけど、戻り値のときはどうするもんなの？

706 ：704：2011/03/14(月) 13:16:19.25

もとの>>694のコードで出来ないのは知ってるよ。それはそっちを変更すべき。
っていうか、こっちはC++が嫌いなんだよ。どうやるかなんてこっちに聞くなよ。
こっちは対処する必要があるケースを言ってるだけ。

戻り値のときは、エラーの種別を知りたいだけなら整数型でビットフラグを使う。
もっと情報が必要なときは、情報を保持した構造体を返す。
>>704で書いた多重継承っぽいことがやりたいなら構造体+委譲で。
構造体をそのまま返すか、構造体のポインタを返すか、構造体のポインタを引数で渡すかは状況によりけり。

707 ：デフォルトの名無しさん：2011/03/14(月) 13:36:30.38

>>706
> こっちは対処する必要があるケースを言ってるだけ。

「RAII使えばほとんどcatchしなくていい」に対して、ひとつでも catch が必要な
ケースを挙げれば否定できるような流れになってるのは何なの？

そんなのレアケースでしかなくて、レアケースには専用の処理で対処できるん
だから、「ほとんどcatchしなくていい」を否定する意味ないでしょ。

「RAII使えばほとんどcatchしなくていい」と「RAIIだけでは済まないケースがある」とが
両方成り立つ可能性は無いと思ってるの？

708 ：デフォルトの名無しさん：2011/03/14(月) 13:37:58.01

>>706
ありがとう。
なるほど、ビットフラグに、戻り値用の構造体か。
やっぱり自分では見たことないわ。
業務でやってるとけっこうあるのかね。

709 ：デフォルトの名無しさん：2011/03/14(月) 14:02:40.04

>>708
WinAPIで使ってると思うが

710 ：デフォルトの名無しさん：2011/03/14(月) 14:21:38.37

>>707
>>695の言い方を借りれば、RAIIはそもそも失敗の可能性があるリソースは管理していない。
だから>>641のような方法は、「一度例外が発生したら、それ以後はファイル等のリソースは管理しない」と宣言してるわけよ。
なのに管理できてるみたいな主張しているわけで、そりゃ否定されるだろ。

あと、既に例としてファイルとデータベースと二つあがってるよ？

さらに言えば、安全性度外視の使い捨てスクリプトならRAII大活躍だから。
だからRAIIは役に立つよ。うん。

711 ：デフォルトの名無しさん：2011/03/14(月) 17:45:00.83

らいー

712 ：デフォルトの名無しさん：2011/03/15(火) 01:32:11.99

>>709
そうなの？思い当たらないな。
どれ？

713 ：デフォルトの名無しさん：2011/03/15(火) 03:12:29.59

Java7 の try-with-resource は Throwable.getSuppressed() に close() からの例外が詰められるらしいぞ。
やったね。

http://d.hatena.ne.jp/irof/20110227/p1
> 「もう片方の例外が消えてしまう！ありえない！これだから最近の若いもんは…」なんて方のために、Throwable.getSuppressed() があります。

714 ：デフォルトの名無しさん：2011/03/15(火) 08:16:46.77

やはりC++はウンコすぎることが確定してしまったな

715 ：デフォルトの名無しさん：2011/03/15(火) 22:02:03.09

ttp://n.xxad.net/watch/sm13809685

【どうすればこの欲望の渦巻く堕落した世界に私の名を残せるだろうか】
※名を残したいとは思わないがｗ。
【狂乱のマシンを残せばいい】

【この狂乱の世界に相応しい野獣のようなマシンを】

【狼が来たからやってきた】

【お前の平和な街は今はもう安全ではない】

716 ：デフォルトの名無しさん：2011/03/15(火) 22:32:15.79

一応、C++0xにもnested_exceptionというのがあって、
>>694の(1)のとこでは、書き込みできなかった例外とクローズできなかった例外をまとめてthrowできる。

Throwable.getSuppressedに相当するのがnested_exception::nested_ptrなんだけど、
getSuppressedは配列を返し、nested_ptrは1個のオブジェクトしか返さない点は異なっている。

717 ：デフォルトの名無しさん：2011/03/16(水) 11:12:50.38

>>716
C++0x の nested_exception は Throwable でいう getCause() のほう。 getSuppressed() とは意味が違う。

718 ：デフォルトの名無しさん：2011/03/17(木) 09:33:14.12

>>710
> 管理できてるみたいな主張しているわけで

これ、どのレスのことなの？
正しいとされてる >>695 と否定されてる >>641 の違いがよくわかんない。

719 ：デフォルトの名無しさん：2011/03/17(木) 10:22:52.63

原発の組み込みってCで書いてるんだろ？

720 ：デフォルトの名無しさん：2011/03/17(木) 10:30:10.62

FORTRAN

721 ：デフォルトの名無しさん：2011/03/17(木) 12:00:42.38

>>718
大雑把にいうと、>>641はRAIIでtry/catchを減らせる（置き換えられる）と主張してる。
一方、>>695は単純にRAIIとはどういうものかを説明してる。

722 ：デフォルトの名無しさん：2011/03/18(金) 09:03:33.00

C++は罠だらけな上に、ユーザが安全でないコードを作ることを助長してる。

723 ：デフォルトの名無しさん：2011/03/18(金) 13:11:31.82

Cもな。

724 ：デフォルトの名無しさん：2011/03/18(金) 13:56:11.51

C の方が少ないけどね。
C++ は罠が多いかわりに便利な部分も多い。

725 ：デフォルトの名無しさん：2011/03/19(土) 09:40:08.49

C++使ってる人は、他の言語使ったりせんの？

726 ：デフォルトの名無しさん：2011/03/19(土) 10:51:00.16

んなわけないだろ。

727 ：デフォルトの名無しさん：2011/03/19(土) 10:56:10.07

>>726
何使ってるのん？
どういうときにC++と使い分ける？

728 ：デフォルトの名無しさん：2011/03/19(土) 11:06:35.82

>>727
sh, python, javascript, lua, ...
作るものや環境によって使い分ける。

・・・っていうあたりまえの答えにしかならないに決まってるんだから、
ほんとうは何を聞きたいのかよくわからんのだけど。

729 ：デフォルトの名無しさん：2011/03/19(土) 17:54:19.34

C++の在り様は適材適所という概念とは遠いところにあるので
そういう質問が出るのも無理なかろう。

730 ：デフォルトの名無しさん：2011/03/19(土) 18:36:52.01

意味不明だなぁ。

731 ：デフォルトの名無しさん：2011/03/19(土) 19:07:18.93

Cとの互換性を維持しながら抽象プログラミングも可能にし、
また様々なパラダイムを分け隔てなく構文サポートするという
デザイン上の決定のため、C++は壮絶なまでの糞言語へと成り下がってしまった。

そんなC++を好んで使うような人間が他の言語を使う理由って何だろう？
他の言語と比べるとC++のあまりの糞さに我慢できなくならない？

732 ：デフォルトの名無しさん：2011/03/19(土) 20:13:49.35

>>731
OSのない環境用のプログラミング言語としてはCかC++ぐらいしか選択肢の無いことが多い。
で、Cに比べてのいろいろなメリットがデメリットを上回れば使うことになるだろう。
メリットについてはこのスレの頭からいくつも書かれてるから、拾い読みしていくといい。

733 ：デフォルトの名無しさん：2011/03/19(土) 20:17:13.33

>>731
そりゃC++使ったことのない人間には分からんだろうねぇ。

734 ：デフォルトの名無しさん：2011/03/20(日) 09:08:54.03

C++使ったことあるからこそ、C++が嫌いになるという可能性は考えないのか

735 ：デフォルトの名無しさん：2011/03/20(日) 17:24:00.39

>>734
アマチュアならそれも許されもするが、プロはダメだ

736 ：デフォルトの名無しさん：2011/03/20(日) 19:04:54.18

>>735
そのとおり。
プロたるもの、C++を愛し>>586を満たさねばならぬ。

737 ：デフォルトの名無しさん：2011/03/20(日) 22:30:18.73

>>734
Cの細々とした面倒さを経験していれば、
Cに戻る気にはならない。

C++の危なさは全然飲める。

738 ：デフォルトの名無しさん：2011/03/21(月) 01:32:31.42

>>737
・C++はCよりも読み難い
・プログラムは書くのより読む方が難しく、また読む時間の方が長い

これらの意見についてはどう思う？

739 ：デフォルトの名無しさん：2011/03/21(月) 10:42:54.94

読みやすく簡潔なコードを書けない738がかわいそうだと思う。

740 ：デフォルトの名無しさん：2011/03/21(月) 11:44:22.02

>>738
人の書いたのをいじくる保守奴隷はC
新規のプロジェクト中心なクリエイティブやつはC++

741 ：デフォルトの名無しさん：2011/03/21(月) 12:13:58.11

>>739 >>740
C++の最低さのみならず、C++プログラマの圧倒的な低能さ
までもが余すところ無く示されたこのスレで、
一体何の冗談だよwww

742 ：デフォルトの名無しさん：2011/03/21(月) 13:03:54.79

> 6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。

743 ：デフォルトの名無しさん：2011/03/21(月) 13:28:19.78

プログラマ割合や募集でC/C++と一緒くたになってるのを
みると、お察しくださいだと思うんだがなぁ。

744 ：デフォルトの名無しさん：2011/03/21(月) 18:31:49.77

C++プログラマが低能なのは否定できない（このスレ見れば一目瞭然w）からって
Cプログラマも仲間にしようとするなよ。
低能なのはお前等だけだってwww

745 ：デフォルトの名無しさん：2011/03/21(月) 18:59:36.82

優れたプログラマは、良いシステム／良いデザインといったものに対する洞察と志向を持つものである。
そのため、適度なシンプルさ、適切な抽象化、直交性の高い規則などを好むのは
その人が優れたプログラマである良い兆候である。

一方、C++のような、場当たり的に構文が追加され、つぎはぎだらけの醜悪な文法は
良いデザインといったものから遠く隔てられている。
このようなグロテスクな文法を好む人間は、システムやデザインの良さに対する洞察力が
根本的に欠けているため、優れたプログラマである可能性は限りなく低い。
おそらく、スパゲティプログラムが何故悪いのかさえ、彼らは本当の意味では理解できないだろう。

746 ：デフォルトの名無しさん：2011/03/21(月) 19:10:17.67

CPU論争をちょっと思い出すな。
RISCの方がシンプルで整然としていて直交性が高いと持てはやす人たちが
その昔いたが、どこに消えたのやら。

747 ：デフォルトの名無しさん：2011/03/21(月) 20:05:57.71

>>740
× 人の書いたのをいじくる保守奴隷はC
○ 長く保守される良いプログラムはC

× 新規のプロジェクト中心なクリエイティブやつはC++
○ 書き捨てスクリプトはC++

748 ：745：2011/03/21(月) 20:38:47.08

そうそう、745はC++プログラマをこき下ろすのは主題じゃなかった。

言いたいことは、C++を好んで使う人間は優れたプログラマの可能性は低く、
典型的には>>586のようなプログラマなので、
彼らを自分のプロジェクトから排除するという目的のためだけに
Cを選んだとしても、それは十分に合理的であるということ。

749 ：デフォルトの名無しさん：2011/03/21(月) 21:23:53.85

>>748
恐らくLinusの引用だと思うんですが、C以外も使うプログラマが
Cを好むとは今一思えない。仕方がなく使ってるだけで。
メインフレームをVM言語やLLにしましょうとか言われた場合は受け入れるんですか？

750 ：デフォルトの名無しさん：2011/03/22(火) 07:41:23.10

>>749
え？Cは好きだし、（悪い部分もあるけど）総体としては全然悪くないと思うよ。
システムプログラミング用の言語としても、LLやVM言語を拡張するための
言語としても、適度にシンプルで扱いやすい。

でも、例えばPythonで要求が満たせるならそっち使うよ。だって楽じゃん。

751 ：750：2011/03/22(火) 07:44:28.52

むしろこっちが質問したいよ。
C++以外も使うプログラマがC++を好む理由は何？ってね。

752 ：デフォルトの名無しさん：2011/03/22(火) 07:47:16.95

>>748
http://warp.povusers.org/programming/cplusplus_superior_to_c.html
> First hurdle: Error handling
> Second hurdle: Initialization and destruction baggage
> Third hurdle: Data containers

こういう問題についても C でなんとかしようと思う？

753 ：デフォルトの名無しさん：2011/03/22(火) 08:18:09.61

>>752
エラーの処理については、C++例外を使った方が可読性が低い、とこのスレで議論されてる。

初期化と解放については、そんなものが本当にプログラミングにおいて重要な問題なのか疑問だ。
C++では例外がある上にfinallyが無いから解放はややこしい問題たりえるが、Cでは全然難しくない。

標準で便利なコンテナが提供されていないのはCの欠点だ、というのは認めざるを得ないね。
GLibとかの実装があるし、リストくらいなら自分で簡単に実装できるから不便は感じないけど、標準であるのは便利だ。

最後に、全体的な主張である（と思われる）Cで書くと冗長であるという点については、
その代わりがC++の漏れのある抽象化というならごめん被る。

754 ：デフォルトの名無しさん：2011/03/22(火) 09:36:21.64

C++の「漏れのある抽象化」ってのを問題にしてる人（一人？）は、
そのほか諸々の「漏れのある抽象化」は問題にしないの？

C以下にも利便性を優先して受け入れてる抽象化が山ほど積み重なってると思うんだけど。
CPUキャッシュとかメモリアクセス速度とかタスクとかネットワークとか電源とか。

なんでCとC++との間の違いだけことさらに問題になるの？

755 ：デフォルトの名無しさん：2011/03/22(火) 11:51:19.86

C++が提供する抽象化は、その他の言語ではもっと良い形で提供されてるから。

あと、C++の漏れのある抽象化の弊害については
このスレで議論されてるけど、Cのそれは述べられてない。
何の理由も無く一緒にされても困る。

756 ：デフォルトの名無しさん：2011/03/22(火) 12:41:22.34

>>738
＞・C++はCよりも読み難い
そうは思わない。
同等レベル。

＞・プログラムは書くのより読む方が難しく、また読む時間の方が長い
読みにくいコードは、どっちにしろ
読みにくい。
とくにC++だから読みにくいとは思わない。
テンプレートや例外は、使うべき範囲で
使うので、問題にはならない。

757 ：デフォルトの名無しさん：2011/03/22(火) 12:45:37.23

>>745
C++の全仕様を使い切る必要はない。
自分が正しく使える部分のみを使え。

つぎはぎかもしれないが、うまく
使えば問題にはならない。

758 ：デフォルトの名無しさん：2011/03/22(火) 12:54:56.65

>>751
必要充分だから。
また、ターゲットのリソース的に
他に選択肢がないから。

多少の罠があるくらいは不問。

759 ：デフォルトの名無しさん：2011/03/22(火) 13:01:46.03

>>753
漏れがあって何がダメなの？
潔癖症なの？死ぬの？

760 ：デフォルトの名無しさん：2011/03/22(火) 17:38:20.53

機能が多すぎるからダメって言うのは、スマフォよりガラケー、ガラケーより高齢者ケーが
良いと言っちゃう人なのかな？

761 ：デフォルトの名無しさん：2011/03/22(火) 17:44:01.75

>>756-760
こういう底なしの低能どもが群がるのがC++

762 ：デフォルトの名無しさん：2011/03/22(火) 18:10:58.65

だいたい40代後半ぐらいから上の世代はC++に不慣れなのでJavaとかC++のOOにめっぽう弱い
というか取り組もうとすらしなかった世代
まさか今の20代でC++否定とかないわな

763 ：デフォルトの名無しさん：2011/03/22(火) 18:52:19.58

＞例えばPythonで要求が満たせるならそっち使うよ。だって楽じゃん。

じゃあやっぱり仕方がなくC使ってるだけじゃん。

764 ：デフォルトの名無しさん：2011/03/22(火) 21:02:33.46

>>761
こういう底なしの低能が執着するのがC

765 ：デフォルトの名無しさん：2011/03/22(火) 21:16:32.30

>>762 >>764
だからさ、何かを主張するなら根拠を示そうぜ。
ちなみに、C++とC++プログラマのウンコっぷりはこのスレ参照。

>>763
お前は低能過ぎて適材適所って概念が理解できないのね。

766 ：デフォルトの名無しさん：2011/03/22(火) 22:22:10.00

道具を工夫して上手く使う技術が無いのがCPG

767 ：デフォルトの名無しさん：2011/03/23(水) 00:04:30.62

このスレ参照（ｷﾘｯ

768 ：デフォルトの名無しさん：2011/03/23(水) 00:36:13.02

C++とC++プログラマはウンコ（ソースはこのスレ

769 ：デフォルトの名無しさん：2011/03/23(水) 01:05:40.32

>>755
昔々、アセンブラからCに移行しようとしていた若者たちは、当時の
ベテランプログラマから「Cは遅い」だの「メモリ使用量がわかりにくい」だの
たいそう言われたものさ。

770 ：デフォルトの名無しさん：2011/03/23(水) 07:18:43.03

>>767
>>586

771 ：デフォルトの名無しさん：2011/03/23(水) 07:25:39.02

>>766
別にCと適当なLLなりVM言語なり組み合わせれば良いじゃん？
それも道具を上手く使うって範疇に入るだろ？

>>769
アセンブラと、レジスタやスタックを抽象化したCでは記述できる対象が違う。
Cではアセンブラの代わりにはならないし、その逆もしかり。

772 ：デフォルトの名無しさん：2011/03/23(水) 07:28:26.45

あとさ、>>728 がPython使うって書いてたけど、C++とどうやって使い分けてんの？
そういった言語使っててC++の醜悪さと生産性の低さは気にならないの？
このスレのC++使いは、自分はろくに思考もせずに安易に質問するくせに、
他人の質問はスルーするから困る。

773 ：772：2011/03/23(水) 07:46:22.82

ああ、そうだった。
C++使いは>>745だから、C++が醜くても気にしないんだったね。
忘れて。

774 ：デフォルトの名無しさん：2011/03/23(水) 08:10:49.66

CPGって参照使いたくなったり継承使いたくなったり演算子の関数のオーバーロード使いたくなったりすること、全くないの？
これらすらも使いこなせないから手を出さないの？
それともCオンリーでがりがり書いてるの？

775 ：デフォルトの名無しさん：2011/03/23(水) 08:20:02.23

>>771
Cと、OOやテンプレートを使えるC++では記述できる対象が違う。
C++ではCの代わりにはならないし、その逆もしかり。

776 ：デフォルトの名無しさん：2011/03/23(水) 08:24:33.43

>>772
Cの面倒さと生産性の低さは気にならないの？

777 ：デフォルトの名無しさん：2011/03/23(水) 08:43:54.33

>>774
参照はconst参照のみなら、あってもいい。それ以外の参照は邪魔だ。
継承については>>628。時々使うが構文サポートなんていらん。動的型付け言語でもないのに実行時の型を強く意識する必要がある。
演算子オーバーロードは可読性が下がるからマジでいらん。
最近はPythonを良く使ってる。

>>775
C++は構文糖を追加してるだけ。しかもキモイ。
Cでしか書けないところはCで、それ以外はLLで良い。

778 ：デフォルトの名無しさん：2011/03/23(水) 08:46:16.57

>>776
>>738

あとさ、Pythonなりと簡単に組み合わせられるって言ってるじゃん。
そこ無視して何言ってんの？アホなの？

779 ：デフォルトの名無しさん：2011/03/23(水) 09:19:03.15

Cで無理矢理我流にOOしたソースが読みやすいわけがないバカでもわかるだろそんな事
実務したことない趣味グラマかCでOOとか言ってるのって

780 ：デフォルトの名無しさん：2011/03/23(水) 12:35:05.14

実務レベルで見ると、ここの自称Cプログラマ、C++プログラマ、両方の言うことが胡散臭いからな。

781 ：デフォルトの名無しさん：2011/03/23(水) 15:12:07.92

>>770
ただの妄想じゃねーか。

782 ：デフォルトの名無しさん：2011/03/23(水) 19:46:40.73

>>781
信じられないだろ？C++信者の発言のまとめなんだぜ、それ

783 ：デフォルトの名無しさん：2011/03/23(水) 22:46:14.98

>>782
Juha Nieminen なんていう国際的馬鹿のことなんてどうでも良いわ。
誰が連れてきたんだよこんなカス

784 ：デフォルトの名無しさん：2011/03/24(木) 06:39:45.60

Cやってて例外が欲しい時がある
で、C++にすると、finallyがないことに気付く
Cにも例外が欲しい、C++にもfinallyが欲しい

785 ：デフォルトの名無しさん：2011/03/24(木) 09:04:00.44

Cにもメタプログラミング用の機能が欲しい時がある。
C++のtemplateのように、うっかりチューリング完全でしたみたいなやつじゃなくて
最初からメタプログラミング用にデザインされたやつを。

786 ：デフォルトの名無しさん：2011/03/26(土) 13:16:28.70

メタプログラミングは、通常の変数に入らない第二級オブジェクトをプログラムする。
おれは第二級オブジェクトが欲しいとは思わない。

787 ：デフォルトの名無しさん：2011/03/26(土) 13:51:29.51

第二級オブジェクトって何？
オブジェクトをプログラムするって？

788 ：デフォルトの名無しさん：2011/03/26(土) 16:19:12.17

例外と rtti は要らね。
クラス、スマポとテンプレートは無いと死ぬ。
あと C++0x の細々とした機能がはやく欲しいな。
これができれば C でもいいや。

789 ：デフォルトの名無しさん：2011/03/26(土) 18:16:21.12

>>787
他人のことばかり語って
自分は語られる対象になれない
かわいそうなオブジェクトのことです

790 ：デフォルトの名無しさん：2011/03/27(日) 11:20:21.80

>>777
> 演算子オーバーロードは可読性が下がるからマジでいらん。

それって可読性を下げるだけの使い方しかできない、キミの落ち度でしょ。
使い処を間違えてる自分を責めれば？

791 ：デフォルトの名無しさん：2011/03/27(日) 11:48:28.88

>>790
道具の使い方は、使う人じゃなくて使われる状況で決まるんじゃないか
逆に、状況と無関係に「正しい使い方」が決まるようなものは道具ですらない

792 ：デフォルトの名無しさん：2011/03/27(日) 16:00:56.76

アレなプログラマしか居ないなら、
C を選択してしまうかもしれない。
実際に、そう選択したことはあった。
数年前だけどね。
そんな状況では C でも悲惨だけどな。。。

793 ：デフォルトの名無しさん：2011/03/27(日) 18:55:21.72

>>755
「良い」の基準が違うだけじゃないかなぁ。
オーバーヘッドを抑えるだとかCコンパイラ・リンカとの親和性を保つだとか、
そういうC++のミッションを無視すればそりゃ他の言語より出来が悪く見えるかもしれないけどさ。

「C++の漏れのある抽象化の弊害」ってのが何のことを言ってるのかはっきり
わからないけど、Cのstrlenやreallocの誤用は当てはまらないっていうんでしょ？
結局自分が知ってるかどうか、自然に感じるかどうかっていう基準でしかないんじゃないの？
「Cをマスターした俺をおどろかせるような抽象化の漏れは有害だ」っていう。

794 ：デフォルトの名無しさん：2011/03/27(日) 19:46:19.13

抽象化「詳細を知る必要はない」

漏れのある抽象化「ただちに詳細を知る必要はない」

795 ：デフォルトの名無しさん：2011/03/27(日) 22:08:31.28

>>793
>>326

796 ：デフォルトの名無しさん：2011/03/27(日) 23:11:19.29

Cの、
ライブラリ関数がマクロか関数か決まってないとか、
memsetでポインタや不動小数点数を0埋めしても0にならないとか、
ctype関数にcharの値を渡しちゃダメとか、
コンパイルエラーにならないconstとか、
可変長引数での暗黙の型変換とか、
setjmpのガチガチの利用制限とか、
そういう諸々の（実装や歴史を知らないと納得できないような）罠については
理不尽だと言わないの？何が違うの？

797 ：デフォルトの名無しさん：2011/03/27(日) 23:17:21.06

そういう例を挙げると「C++プログラマがCを使うと危険な例」にされるんだよな。
ほんと、どうかしてるぜ。

798 ：デフォルトの名無しさん：2011/03/28(月) 01:48:21.74

>>791
つまり、悪いのは状況であって、自分ではないとｗ

799 ：デフォルトの名無しさん：2011/03/28(月) 07:37:43.48

>>796
> ctype関数にcharの値を渡しちゃダメとか、
> コンパイルエラーにならないconstとか、

どういうこと?

800 ：デフォルトの名無しさん：2011/03/28(月) 10:20:02.46

> 可変長引数での暗黙の型変換とか、

どういうこと？

801 ：デフォルトの名無しさん：2011/03/28(月) 13:43:59.52

>>799
> ctype関数にcharの値を渡しちゃダメとか、
↑これは↓だろうな。
http://www.kijineko.co.jp/tech/superstitions/parameter-of-isalpha-is-char.html

802 ：デフォルトの名無しさん：2011/03/28(月) 13:48:33.97

>>800
> 可変長引数での暗黙の型変換とか、
↑これも、同じサイトに載ってた↓の話かも。
http://www.kijineko.co.jp/tech/superstitions/printf-format-for-double.html
> 可変個実引数は、既定の実引数拡張によって float 型の値は double 型に暗黙的に型変換されるのです。

803 ：デフォルトの名無しさん：2011/03/28(月) 13:51:07.97

shortもintになるけどlongはintにならない。
sizeof(long) == sizeof(int)の人は要注意。

804 ：デフォルトの名無しさん：2011/03/28(月) 13:52:14.70

803s/の人/に慣れている人/

805 ：デフォルトの名無しさん：2011/03/28(月) 18:14:38.09

>>801 >>802
それが罠と言う人は、それで問題おきるような使い方してるのか。

>>796の
> ライブラリ関数がマクロか関数か決まってないとか、
も含めて、そういうのが問題になる使い方の例を示してほしいな。

806 ：デフォルトの名無しさん：2011/03/28(月) 18:15:35.67

>>796
> memsetでポインタや不動小数点数を0埋めしても0にならないとか、

わざわざmemsetって名前が付いてるのに、メモリのゼロクリアじゃなくて
数値をゼロにすると思っちゃうの？なんで？
罠っていうのはさ、例えばC++でmemsetをうっかりplain old data型以外に
適用すると未定義動作になっちゃうとか、そういうのだと思うよ。

807 ：デフォルトの名無しさん：2011/03/28(月) 18:52:13.58

>>790 >>798
ひとつの記号がコンテクストに応じて色んな振る舞いをするっていうのは、
すごく読み辛いんじゃないかな。
Cでも、staticが状況に応じて色んな意味を持つのはうざいでしょ？
言語仕様で定義されてる振舞いだけでも、記号の多義性はうっとうしいのに
ユーザが勝手に定義できるとか、うざすぎでしょ。

808 ：デフォルトの名無しさん：2011/03/28(月) 20:17:34.73

>>801
関数の定義域が0からUCHAR_MAXまでの正整数とEOFのみってだけだよね？
関数が、ある型の一部の定義域のみで値を持つことって普通にあると思うけど。

809 ：デフォルトの名無しさん：2011/03/28(月) 20:33:40.49

>>796
それらのリストには、確かにCの抽象化の漏れと言えるものも含まれてる。
しかし、ライブラリ関数は「嫌なら使わなくていい」し「使われてるかどうか簡単に調べられる」し
「正しく使うのが難しいなら、使いやすいラッパーを用意する」ことも出来る。
つまり>>320でいうなら「漏れたときの対処が容易」だから、そんなに問題じゃない。

810 ：デフォルトの名無しさん：2011/03/28(月) 20:54:25.95

演算子オーバーロードを問題にするのも言いがかりレベルの話だと思うけどね。
好きに定義できるからといって、可読性が落ちるような使い方をするやつは
いないだろと。
<<と>>だけは変な使われ方することがあるかもしれないが。

811 ：デフォルトの名無しさん：2011/03/28(月) 21:34:59.12

>>810
いるよ
可読性は落ちるが短く書けるとか、リスクはあるが低コストとか
すべてはトレードオフ

812 ：デフォルトの名無しさん：2011/03/28(月) 21:48:10.10

>>811
ソースは？

813 ：デフォルトの名無しさん：2011/03/28(月) 22:22:51.24

確かに、ソースが重要だな。
仕様書のどこにも書かれていない、現場のソースが重要。

仕様書だけをソースに、ctypeが云々というのも言いがかりだろう。

814 ：デフォルトの名無しさん：2011/03/28(月) 23:06:27.67

>>812
あなた、boostを初めてみたときの「なんじゃこりゃ！？」
って驚きを忘れてしまったのよ……

815 ：デフォルトの名無しさん：2011/03/29(火) 00:58:48.01

>>809
> しかし、ライブラリ関数は「嫌なら使わなくていい」し「使われてるかどうか簡単に調べられる」し
> 「正しく使うのが難しいなら、使いやすいラッパーを用意する」ことも出来る。

C++の問題点として挙げられているもののうち、これらにあたらないと思ってるのはどれ？

どれも同じことだと思うんだけど。
・デフォルト引数＋仮想関数
・C++例外
・演算子オーバーロード

816 ：デフォルトの名無しさん：2011/03/29(火) 01:04:13.30

結局は問題の量と得られるメリットとのトレードオフなのに、
「Cを選ぶ理由は無い」とか「C++を好んで使う人間は優れたプログラマの可能性は低い」とか
極端なことを言い切っちゃうから不毛な議論の種になるんでしょ。

いいかげんに学習しなきゃ。

817 ：デフォルトの名無しさん：2011/03/29(火) 01:20:24.16

>>815
それら三つとも、「使われてるかどうか簡単に調べられる」がイマイチかなー。
どれも「定義してる側」を見れば分かるんだけど、「使用してる側」を見ても分からないんだよね。
検索性もイマイチだし。

あとC++例外は「嫌なら使わなくていい」も難しい。
標準ライブラリをごっそり諦める必要があるからね。あとコンストラクタのエラーをどうするかとか。

最後に「使いやすいラッパーを用意する」も何かピンとこない感じ。
だってそれらの機能自体がシンタックスシュガーという「ラッパー」だからね。

でも、結局は>>816でFAだわ。皆好きなの使え。

818 ：デフォルトの名無しさん：2011/03/29(火) 01:39:49.70

>>816
トレードオフは、単純なモデルで行き詰まった場合にのみ許される複雑なモデル。
Cで行き詰まらない限り、C++で複雑なトレードオフを考えるメリットはない。

819 ：デフォルトの名無しさん：2011/03/29(火) 01:47:46.54

>>818
Cを選択することにはトレードオフが無いかのような発言だな。
なんで>>816のすぐ後にそんな書き込みができちゃうのか不思議だわ。

820 ：デフォルトの名無しさん：2011/03/29(火) 09:40:04.47

>>818
トレードオフは、選択肢のあるモデルで行き詰まった場合にのみ許される複雑なモデル。
Cではただ機能が不足しているので、C++からわざわざトレードオフを考えるメリットはない。

821 ：デフォルトの名無しさん：2011/03/29(火) 10:06:55.20

>>820
C++の機能から、トレードオフで必要な機能を選択したらCになった。

822 ：デフォルトの名無しさん：2011/03/29(火) 10:22:14.15

通常は、GCを使うか使わないかの単純な二択。
C++を含めると、数種類のスマポが選択肢に加わる。

823 ：デフォルトの名無しさん：2011/03/29(火) 10:37:58.50

Boehm GC さんを忘れないで。

824 ：デフォルトの名無しさん：2011/03/29(火) 11:17:20.91

>>816が的確なことを言ってしまったから、学習不足な偏見の塊が
騒ぎ始めたよ。

825 ：デフォルトの名無しさん：2011/03/29(火) 11:25:17.83

演算子オーバーロードに関して。一つの記号に複数の意味があるのを否定するなら、
文字列の連結に+を使う言語や&を使う言語はどんなもんかね。
只並べるだけで連結できる言語(awk)もあるが、正直却って読み難いぞ。

826 ：デフォルトの名無しさん：2011/03/29(火) 11:47:48.85

>>825
ユーザーが自由に多重定義するのとは違うから、統制がとれている。
ちなみに、連想配列があればユーザー定義型もいらないってのが動的言語の魅力。

827 ：デフォルトの名無しさん：2011/03/29(火) 11:53:30.87

>>825
文字列の連結に+を使うのは、+記号なのに加法（交換法則）を満たさないから
実はあんまり良い定義じゃないと思う。>>826が言うように統制が取れてるから
そういうものかと受け入れられるけど。

828 ：デフォルトの名無しさん：2011/03/29(火) 12:06:45.04

なるほど。じゃぁ、ドキュメント化とコードレビューとで統制が取れればなんとか許容かな。
まぁでも、統制が取れない馬鹿はCでもFILE*をフラグに転用したりするから同じことって気もするけど。

829 ：デフォルトの名無しさん：2011/03/29(火) 12:44:29.50

>>818,820
「行き詰らない限り」と言っても、 >>752-753 にあるように配列以上の高級なデータ構造を
扱おうとしたら機能の不足によりわりとすぐ行き詰まったりして、あまり稀でもない。

830 ：デフォルトの名無しさん：2011/03/29(火) 12:52:53.54

>>829
その高級なデータ構造に動的な型付けをするなら、C++は使わない。
結局、静的型か動的型かで対立しているのだと思う。

831 ：デフォルトの名無しさん：2011/03/29(火) 13:00:06.96

>>828
仕事なら統制取れるからC++は許容できる。チームの面子にもよるけど。
オープンソースだとC++は辛い。統制とり辛いし、基本patchでのやり取りだし、
それに>>676みたいなの本当に在るんだぜ。

>>829
すぐ行き詰まるから、逆にLL等と組み合わせるときに
どこまでCで書くか悩むことが少ないというメリット(?)もある。

832 ：デフォルトの名無しさん：2011/03/29(火) 13:02:44.68

>>828
> まぁでも、統制が取れない馬鹿はCでもFILE*をフラグに転用したりするから同じことって気もするけど。

いくらなんでも、そりゃねーよwww

833 ：デフォルトの名無しさん：2011/03/29(火) 13:23:05.79

>>831
> それに>>676みたいなの本当に在るんだぜ。

面白そうだな。リンクくれ。

834 ：デフォルトの名無しさん：2011/03/29(火) 13:25:32.76

>>829
型チェックが弱くなる欠点があるけど、それを許容できれば
Cでもリストやハッシュくらいなら問題なく使えるけどね。
別にfor文でリストをイテレートするくらい、書き難くも読み難くもないだろう？

835 ：デフォルトの名無しさん：2011/03/29(火) 13:45:31.79

>>833
一番有名なの>>99
あと同じLinuxだけど http://kerneltrap.org/node/2067

836 ：デフォルトの名無しさん：2011/03/29(火) 13:54:54.28

ああ、>>99はgitでした。

837 ：デフォルトの名無しさん：2011/03/29(火) 14:13:09.74

>>828
FILE*をフラグに転用したりするほどの馬鹿が
C++で演算子オーバーロード使ったらどうなるのっと

838 ：デフォルトの名無しさん：2011/03/29(火) 14:18:00.53

Linux原理主義者の言ってることは
要するに彼らには必然的にマルチプラットフォームであらゆる環境への対応が必要で
道路が整備されていないところで自動車を使うのは危険だ馬車を使うのが最も良い選択だ
馬車でも馬を交換しながら走れば車と同じように走ることはできる
と言ってるようなもん

839 ：デフォルトの名無しさん：2011/03/29(火) 14:32:09.62

C :ナイフ。切れ味は良い。缶切りや栓抜きの代わりもできるが、専用器具の方が使い勝手が良い。
C++ :十得ナイフ。ただし全部の刃が専用ナイフと同等の大きさ。通常の人間の手には大きすぎ使い難い。

840 ：デフォルトの名無しさん：2011/03/29(火) 14:44:02.25

>>837
何も問題ない。C++は神の言語だからどれほどの馬鹿が使っても
問題が起こらないように設計されてる。
実際にC++使いは馬鹿ばかりだが何の問題も起こってない。

841 ：デフォルトの名無しさん：2011/03/29(火) 14:52:32.46

>>832
本当にいたんだってばw
main()が延々と1000行位続く中で、先頭のほうでFILE*を使ってファイル読み込みが終了。その後でフラグとしての余生をw
記憶に間違いなければこんな感じ。
--
#include<stdio.h>
//他、色々使ってなくても色々インクルード
main(int argc, char**argv)
{
FILE*fp;
//その他有象無象の変数群が100行ほど
if(!(fp=fopen(argv[1],"r"))) exit(-1);
//ファイル(確かcsv)読み込み処理が200行ほど
fclose(fp);
if(func()<0)fp=0;//この関数もトンデモだった気がする
//なんかの(演算)処理が400行ほど
if(!fp)
{
//更になんかの処理(出力向けの文字列加工だったか)が200行ほど
}
//結果の出力に100行ほど
}

842 ：デフォルトの名無しさん：2011/03/29(火) 15:59:01.36

>>841
C++使いはウンコ、まで読んだ

843 ：デフォルトの名無しさん：2011/03/29(火) 21:41:56.39

>>821
わらた。

でも個人的には、クラスやテンプレートが
ないと、ウンザリしちゃうんですが。

>>827
気持ちはわからんでもないけど、
合理的な主張ではないと思う。

一般的に受け入れられる表記なら、
統制とやらにかかわらず受け入れる
べき。だいたいわかりやすくなれば
いんじゃね。

844 ：デフォルトの名無しさん：2011/03/29(火) 23:24:02.77

>>843
変数に型のない言語も、一般的に受け入れられているよ
受け入れちゃいなよ

845 ：デフォルトの名無しさん：2011/03/29(火) 23:45:04.55

＞逆にLL等と組み合わせるときにどこまでCで書くか悩むことが少ない

これを読むと、結局Cにも高等アセンブラ以上の価値は無いってことなんだろうか。

846 ：デフォルトの名無しさん：2011/03/30(水) 07:25:31.34

C++には何の価値もないけどね
いや、低能プログラマ判別装置としての役割があるか

847 ：843：2011/03/30(水) 09:32:14.51

>>844
受け入れてる。最近はPerlばっかり。
ただそういうのが使えない環境は
やっぱりあって、そこではC++を
使いたい。オレは。

848 ：デフォルトの名無しさん：2011/03/30(水) 10:29:03.85

>>847
その環境がもっと有名になれば、C++の評価も上がるんじゃね
PerlやC#は、OSの環境を前面に押し出して成功したんだろ

849 ：デフォルトの名無しさん：2011/03/30(水) 13:43:26.52

不便な環境が有名になるのを願うって後ろ向き過ぎるだろ

850 ：デフォルトの名無しさん：2011/03/31(木) 01:06:21.36

なんで動的言語が使えない環境＝不便な環境なんて思っちゃうのかねぇ。

851 ：デフォルトの名無しさん：2011/03/31(木) 01:38:33.37

>>849 じゃないけど、世間では

動的言語　＝　性能が出ない代わりに便利だから普及している

という認識が一般的だと思ってたわ

852 ：デフォルトの名無しさん：2011/03/31(木) 10:59:25.05

>>850
ばーか。
動的言語も使えるけどC++を選ぶってならともかく、
使えないからC++を選ぶっていうんだから、不便だろ。

853 ：デフォルトの名無しさん：2011/03/31(木) 12:25:27.84

C++ PG「CとLLの組み合わせには敵わないから、LLが使えない不便な環境が流行ってくれぇ！」

854 ：デフォルトの名無しさん：2011/03/31(木) 12:42:22.95

ちっちゃい組み込み機器なんかが有名になるのを願うのは後ろ向きとは言わないんじゃないかね？

855 ：デフォルトの名無しさん：2011/03/31(木) 14:18:11.43

スマートフォンとか、もうVM言語が載るくらい十分に高性能になっちゃったからねぇ
もっとしょぼい環境が流行ってくれないとC++使いは困っちゃうね

856 ：デフォルトの名無しさん：2011/03/31(木) 14:19:28.77

いや、別に流行らなくても困らない。

857 ：デフォルトの名無しさん：2011/03/31(木) 15:48:02.83

ほっといてもC++の人気は落ち続けてるんだから
こんなスレで苛めなくても良いのに

858 ：デフォルトの名無しさん：2011/03/31(木) 23:49:00.89

Roomba のソフトウェアは Common Lisp のサブセットで書かれているという話もあるし、
リソースの限られた環境向けのプログラムが C/C++ じゃないといけないという事も
無いんじゃないの。

859 ：デフォルトの名無しさん：2011/04/01(金) 01:14:54.67

たかが掃除機にすらGC付きの言語が載る時代なんだなぁ

860 ：デフォルトの名無しさん：2011/04/01(金) 01:22:14.97

http://www.tiobe.com/index.php/content/paperinfo/tpci/

861 ：デフォルトの名無しさん：2011/04/01(金) 01:29:26.31

C++とVBのシェアがC#に奪われてるって書いてるね。
グラフを見てもC++の人気は下がってるね。
C++ってほんとに落ち目だね。

862 ：デフォルトの名無しさん：2011/04/01(金) 08:49:07.70

新しい言語を覚えることも出来ず、やっと覚えたC++にしがみついてる低能は哀れだねぇ

863 ：デフォルトの名無しさん：2011/04/01(金) 09:13:18.39

C++なんてUnixにおいては所詮one of themに過ぎないし、
Windowsではメイン開発言語の座をC#に奪われてしまい、
OS Xではそもそも相手にされていない。
いまさらC++を選ぶ理由なんてないな。

864 ：デフォルトの名無しさん：2011/04/01(金) 13:36:36.35

> OS Xではそもそも相手にされていない。
意味不明。

865 ：デフォルトの名無しさん：2011/04/01(金) 13:38:17.58

触るなよ
> 6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。

866 ：デフォルトの名無しさん：2011/04/01(金) 13:55:06.60

もしかして>>860はテーブルの矢印だけみて
「C++の人気は上がってる！」って喜んじゃって
嬉々としてリンク張っちゃったのかな？
ちょっとでも英語読めれば、全然逆のこと書いてあるの分かったのにね。

867 ：デフォルトの名無しさん：2011/04/01(金) 13:58:13.75

>>864
MacはObjective-Cがメインでしょ

868 ：デフォルトの名無しさん：2011/04/01(金) 13:58:52.19

そ、そうだね。C#すごいね

869 ：デフォルトの名無しさん：2011/04/01(金) 14:04:37.16

人気で一喜一憂とかｗ
アニオタかよ

870 ：デフォルトの名無しさん：2011/04/01(金) 14:05:47.17

>>867
お前には分からんだろうが、速度が必要な所にはSTLとか使うし。

871 ：デフォルトの名無しさん：2011/04/01(金) 14:42:57.79

Objective-Cで速度稼ぐためにIMPを使うのではなくSTL使っちゃうなんて
本当に低能C++使いは新しいこと覚えるの苦手なんだね。

872 ：デフォルトの名無しさん：2011/04/01(金) 15:01:12.26

ほれ見ろ元気になっちゃったじゃないか。
> 6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。

もういっこ。
> 1．Java、C#などの「C/C++」以外は論外。これらについて言及している
> レスは無視してください。

873 ：デフォルトの名無しさん：2011/04/01(金) 15:04:34.38

>>871
お前には分からんだろうが、NSArray や CFArray は std::vector の代わりにはならないｗw

874 ：デフォルトの名無しさん：2011/04/01(金) 15:06:49.47

>>872
C++に関連した事象を述べてるだけだよ。

875 ：デフォルトの名無しさん：2011/04/01(金) 15:14:45.12

>>873
そりゃそーだ。だからライブラリの受け渡しするときは、
いちいちstd::vectorをNSArrayに変換しなきゃいけないよね。面倒くさいね。
あと、Objective-CとC++はそれぞれ独自の例外処理を持ってるけど、
混ぜて使うと簡単にリソースリーク起こすよね。
だから混ざらないようにtry/catchの嵐になるね。馬鹿だね。

876 ：デフォルトの名無しさん：2011/04/01(金) 15:51:46.33

>>875
> std::vectorをNSArrayに変換

馬鹿丸出し。

877 ：デフォルトの名無しさん：2011/04/01(金) 16:16:26.55

もはやC++使いは理由を述べて反論することも出来ないwww
語れば語るほど低能さを露呈するからwww

878 ：デフォルトの名無しさん：2011/04/01(金) 16:40:51.55

std::vectorをNSArrayに変換www
try/catchの嵐www

879 ：デフォルトの名無しさん：2011/04/01(金) 20:08:43.20

CとC++はどっちから勉強したらいいんですか？
用途はDLL作成とコマンドラインツールが主です

880 ：デフォルトの名無しさん：2011/04/01(金) 20:24:46.92

>>879
その用途ならどっちでもいいんじゃね？
このスレでは論争ごっこして遊んでるけど、CもC++も十分実用的な言語だから。
プログラミング初心者ならC++は少し難しいかもなぁ。

881 ：デフォルトの名無しさん：2011/04/01(金) 20:38:54.98

C++は低能専用言語なんで、それでも良ければ

882 ：デフォルトの名無しさん：2011/04/01(金) 20:53:24.08

C++は低脳には使えません

883 ：デフォルトの名無しさん：2011/04/01(金) 21:10:45.24

何故C++は難しいのですか？

884 ：デフォルトの名無しさん：2011/04/01(金) 21:14:14.56

C++の文法は罠だらけだから。
罠を避ける方法を学ぶためだけに最低でもEffective C++を読む必要があるから。

885 ：デフォルトの名無しさん：2011/04/01(金) 21:20:35.37

>>883
1から作った言語ではなくCの上位互換を強く意識しているために
落とし穴だらけになった

しかも完全上位互換じゃないし

対極的な言語としてはC#があり、JavaをSunに訴えられたM$が
リベンジを誓って1から作ったために言語としてはほぼ完璧な構造を持つ

対してJavaは建て増しに次ぐ建て増しで次第にガタガタに崩れて来ている

886 ：デフォルトの名無しさん：2011/04/01(金) 21:57:28.21

OOP自体が、建て増しに次ぐ建て増しを推奨していた時期があった

887 ：デフォルトの名無しさん：2011/04/01(金) 22:29:07.81

C++は既にPL/Iの規模を超えてるよな

888 ：デフォルトの名無しさん：2011/04/01(金) 23:45:59.75

C++がC#に取って代わられつつあるというのは分かるが
Cはもうファーム用言語だな
俺はC++はよく分からないけど、機会あれば使ってみたいよ

889 ：デフォルトの名無しさん：2011/04/01(金) 23:50:38.76

そっか、俺はファームを書いてたんだ！
で、ファームって何？

890 ：デフォルトの名無しさん：2011/04/01(金) 23:53:52.30

>>883
難しかったら「難しいから採用されないんだ」って言えるでしょ

891 ：デフォルトの名無しさん：2011/04/01(金) 23:54:18.06

C++はあの秀丸エディタの開発で使われてますよ

892 ：デフォルトの名無しさん：2011/04/02(土) 01:05:31.50

C++はあのLLVMの開発で使われてますよ

893 ：デフォルトの名無しさん：2011/04/02(土) 01:36:12.40

C++はあのGCCの開発で使われてますよ

894 ：デフォルトの名無しさん：2011/04/02(土) 01:41:38.92

有名処って LLVM, V8, OpenJDK, Firefox, Inkscape, WebKit と OOo くらいかな
後なんかある?

895 ：デフォルトの名無しさん：2011/04/02(土) 02:46:00.87

コンシューマゲームとか。

896 ：デフォルトの名無しさん：2011/04/02(土) 03:25:58.05

イギリスのオンライントレード？だったかがC++

897 ：デフォルトの名無しさん：2011/04/02(土) 07:26:41.09

Darwin

898 ：デフォルトの名無しさん：2011/04/02(土) 08:56:36.33

ゲームの?

899 ：デフォルトの名無しさん：2011/04/02(土) 21:58:37.89

http://www2.research.att.com/~bs/bs_faq.html#compare

900 ：デフォルトの名無しさん：2011/04/02(土) 23:48:20.79

ゲームと言えば Quake III は C なんだな

901 ：デフォルトの名無しさん：2011/04/02(土) 23:55:43.85

ライブラリを入れると膨大になるので自立して動くプログラムだけ。

Linux, *BSD, Apache, MySQL, Perl, Python, Ruby, Blender, Quake III, etc.

この辺りは全部 C かな。中で一部 C++ を使っている物もあるけど。

>>897
Mac OS X の Kernel 部分の事を言いたいなら、実装言語は C でしょ。

902 ：デフォルトの名無しさん：2011/04/03(日) 02:49:31.40

> Mac OS X の Kernel 部分の事を言いたいなら、実装言語は C でしょ。

やたら C ということにしたいようだが、どの部分のこと言ってんの？

903 ：デフォルトの名無しさん：2011/04/03(日) 03:02:01.53

>>902
どの部分って xnu に決まってるだろ・・・

http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/
http://www.opensource.apple.com/tarballs/xnu/xnu-1504.9.37.tar.gz

904 ：デフォルトの名無しさん：2011/04/03(日) 03:04:59.11

>>894
金融系は OCaml とか何でもアリだからな

905 ：デフォルトの名無しさん：2011/04/03(日) 03:05:29.40

おっとレス番間違えた。
>>904 は >>896 宛ね。

906 ：デフォルトの名無しさん：2011/04/03(日) 10:18:57.24

このスレ読んで分かりました
C++使いは低能じゃなくて無能なんですね

907 ：デフォルトの名無しさん：2011/04/03(日) 10:53:26.43

>>906
そういうお前は無脳な

908 ：デフォルトの名無しさん：2011/04/03(日) 13:04:41.84

>>897
Darwin というか MACH/BSD は C と ASM だぞ

909 ：デフォルトの名無しさん：2011/04/03(日) 23:48:13.42

>>902
何故ろくに知りもしないことに口を挟むのか

910 ：デフォルトの名無しさん：2011/04/04(月) 17:21:38.82

C　　　バケツでウラン
C++　汚染水溜まりに新聞紙

911 ：デフォルトの名無しさん：2011/04/04(月) 20:43:44.37

ワロタw

912 ：デフォルトの名無しさん：2011/04/04(月) 21:20:55.96

残念ながらC++はオワコン

913 ：デフォルトの名無しさん：2011/04/05(火) 12:53:29.93

matzがtwitterでC++をdisっとる

914 ：デフォルトの名無しさん：2011/04/05(火) 13:13:03.07

＞要するに「私は大クラス主義に慣れていて、
＞Java/C++プログラムで細かいクラスがたくさんあると
＞把握しきれない」という自分の能力の限界の暴露に過ぎないのです

歳とったら無理って結論だろ

915 ：デフォルトの名無しさん：2011/04/05(火) 13:23:11.73

>>914
低能には謙遜とか皮肉って理解できないのかな？

916 ：デフォルトの名無しさん：2011/04/07(木) 12:09:12.80

>>894
> WebKit, Firefox
に加え Chromium も C++ か。

917 ：デフォルトの名無しさん：2011/04/07(木) 17:24:26.48

FFmpeg は C（しかもC99）だね

918 ：デフォルトの名無しさん：2011/04/07(木) 18:39:47.83

フーリエ変換や物理挙動のコアライブラリーみたいな数式的なものを書くときはCで十分だし、むしろ巨大関数として一気に書いてしまった方が作りやすいってのもある。
HTMLパーサーのような巨大なシステムとしての構造を書くなら、C＋＋みたいにクラスを使える言語の方が整理しやすくて作りやすいと思う。

ブラウザーがC++で、FFmpegがCなんてのは、まさに象徴的な気がする。

919 ：デフォルトの名無しさん：2011/04/07(木) 20:57:05.18

Gimp も C

920 ：デフォルトの名無しさん：2011/04/07(木) 21:34:21.52

>>916
>Chromium も C++ か。

Chromium は超巨大プロジェクトだから何とも言えない。
C++ が多いのは WebKit や V8 がベースだから当たり前。

% du -sh chromium
3.6G chromium
% find chromium -type f | wc -l
237588
% find . -name '*.cpp' | wc -l
8091
% find . -name '*.cc' | wc -l
7687
% find . -name '*.c' | wc -l
5891
% find . -name '*.py' | wc -l
5174
% find . -name '*.js' | wc -l
4220
% find . -name '*.idl' | wc -l
2427
% find . -name '*.mm' | wc -l
1138
% find . -name '*.m' | wc -l
303

921 ：デフォルトの名無しさん：2011/04/07(木) 21:42:26.75

NaCl は大体 C だね

% du -sh native_client
264M native_client
% find native_client -name '*.c' | wc -l
504
% find native_client -name '*.cc' | wc -l
260
% find native_client -name '*.py' | wc -l
113

922 ：デフォルトの名無しさん：2011/04/07(木) 22:08:39.97

このスレでC++を推してる人はソース読まないから
各プロジェクトで実際にどの程度C++が使われてるかなんて知らないよ

923 ：デフォルトの名無しさん：2011/04/08(金) 00:11:15.88

このスレでCを推してる人はソース読んでるから
各プロジェクトで実際にどの程度Cが使われてるか完全に把握してるよ

924 ：デフォルトの名無しさん：2011/04/08(金) 02:46:06.84

>>918
>フーリエ変換や物理挙動のコアライブラリーみたいな数式的なものを書くときはCで十分だし、むしろ巨大関数として一気に書いてしまった方が作りやすいってのもある。

これもC++で書いた方がいろいろメリットがあると思うが。
巨大関数のすべての変数を冒頭で宣言するのは面倒。

面倒なだけならいいが、最初に宣言して後から初期値を設定しなくてはいけない状況では
意味的に定数でも変数にしなくてはいけないから、バグの温床になる。

const変数をif文やfor文の中で宣言できないのは、正直つらい。

925 ：デフォルトの名無しさん：2011/04/08(金) 07:02:01.03

別に巨大関数なんてCでも滅多に書かないわけだが、そんな理由ならC99で十分なわけですよ。
あと、C99では標準でrestrictがあるのでasm無しで最適化効かせられる。

926 ：デフォルトの名無しさん：2011/04/08(金) 08:33:25.34

>>924
>巨大関数のすべての変数を冒頭で宣言するのは面倒。

規格上も、10年以上前からそんな事をする必要は無いんだが。

927 ：デフォルトの名無しさん：2011/04/08(金) 08:49:15.00

そそ。巨大関数を書く奴に限って関数先頭で宣言したがる。
で、そんな奴はC++で書かせてもやっぱり関数先頭で全部宣言してしまう。
共通処理クラスをわざとそれでは使いにくいように設計してやったら、
そのクラスの宣言だけ途中に書いて、それ以外はやっぱり関数先頭で宣言していた。
存外、>924も実はその口かも知れず。

928 ：デフォルトの名無しさん：2011/04/08(金) 11:04:52.34

C++マの中でも>>924は底辺

929 ：デフォルトの名無しさん：2011/04/08(金) 21:07:44.16

フーリエはともかく、物理挙動みたいに現実の概念を
プログラムで表現する場合はCよりC++の方が遥かに
適していると思うが。

930 ：デフォルトの名無しさん：2011/04/09(土) 00:36:06.42

>>924
>最初に宣言して後から初期値を設定しなくてはいけない状況では

初期値を設定出来る所で宣言すれば良いじゃん
いつの時代の人ですか？

931 ：デフォルトの名無しさん：2011/04/09(土) 07:24:32.15

>>929
Simulaの後継であるC++はオブジェクト指向的な
シミュレーションがCより得意と言いたいのかな？
それはそうかもね。

でもさ、計算速度が必要なときは
きちんと効率よく解ける方程式を導出して解くので
オブジェクト指向とか関係ないんだよね。

計算速度が必要ないならC++である必要も無いしね。

932 ：デフォルトの名無しさん：2011/04/09(土) 08:15:36.66

>>924
こういうレベルの理解度でCの代わりにC++使ってる人多いんだろうなぁ

933 ：デフォルトの名無しさん：2011/04/09(土) 10:33:27.50

restrictや可変長配列などのCのメリットを説明するならまだわかるのだが、
「Cで十分」という説明はCのメリットがありませんと言ってる
ようなものだ。
C++使いからしたら、敢えて機能制限の多いCを選ぶ必要は無い

934 ：デフォルトの名無しさん：2011/04/09(土) 11:05:53.74

不思議な理屈だなあ
言ってるような物だと無理矢理断定しても、言ってない物は言ってないんだぜ

935 ：デフォルトの名無しさん：2011/04/09(土) 11:08:00.13

C++ な人はソースコードを確認しない人とか、規格を確認しない人ばかりなの?
そんなんだと、断定口調で書き込んだ所で説得力は無いよね

936 ：デフォルトの名無しさん：2011/04/09(土) 11:28:06.09

C使いは>>934みたいに人とのコミュニケーションができない
知障ばかりなのね

937 ：デフォルトの名無しさん：2011/04/09(土) 11:31:53.91

俺はむしろ気軽に他人を知障と呼んじゃう人が心配だわ。。。

938 ：デフォルトの名無しさん：2011/04/09(土) 11:32:40.24

>>935
C++はソースの可読性がクソだし、規格をちゃんと把握するのも困難だ。
ソースや規格を確認しないような人だからC++を好むのかもしれん。

939 ：デフォルトの名無しさん：2011/04/09(土) 11:39:35.74

>>933 それは確かに感じた。
C使いが、Cが必要だと理由を言わず、ただ単にC++が不要だと言っている。
これでは、C++を使えない自分に対する言い訳を言っているようにしか聞こえない。
もしくは10年、20年以上前の記憶でしか、C++を見ていないとか。

いつの時代の人ですか？

940 ：デフォルトの名無しさん：2011/04/09(土) 11:42:11.14

>>939
>いつの時代の人ですか？

何だ気にしてたのかw

皮肉は事実に裏付けされていないと意味ないよ。

941 ：デフォルトの名無しさん：2011/04/09(土) 11:44:00.30

どう考えても、大規模なソース書く上で、C++の方が可読性がいい。

942 ：デフォルトの名無しさん：2011/04/09(土) 11:45:23.17

「どう考えても」は理由の説明じゃないよ
どう考えたのかを具体的に書かないとネ

943 ：デフォルトの名無しさん：2011/04/09(土) 11:50:06.22

>>938
Perl と C++ は可読性が低い言語の二大巨頭だな
一時期大きな人気を獲得して、その後、後発に追い抜かれたという点でも似ている

944 ：デフォルトの名無しさん：2011/04/09(土) 11:53:25.00

スパゲッティプログラムってあるだろ。C言語はそれになる。

C++はクラスなどを使うことで各機能を分割して作成できる。

それに標準機能がC言語より多いからコードの短縮にもなる。

945 ：デフォルトの名無しさん：2011/04/09(土) 11:55:07.31

C++ の可読性が低いなら C っぽく書けばいいじゃない
C++ の全ての機能を使う必要はないのよ

946 ：デフォルトの名無しさん：2011/04/09(土) 11:55:25.99

C++ PG が書く C が汚くなるのは、このスレから想像が付くよな
C が悪いんじゃなくて、ただ C を知らないというだけの話だが

947 ：デフォルトの名無しさん：2011/04/09(土) 11:56:55.93

>>945
C++ で C っぽく書くなら C で書いた方がマシ。
C++ の機能を充分に使えず、C とも互換性が無いコードなんて誰も読みたくないわ。

948 ：デフォルトの名無しさん：2011/04/09(土) 12:08:44.25

スパゲッティプログラムとは。
処理の流れや構造を把握しにくく、修正や機能の追加が困難なプログラム。
麺が複雑に絡み合い数本の麺を引っ張り出そうとしても全体がついてくる、スパゲッティに例えたのがこの言葉である。
http://e-words.jp/w/E382B9E38391E382B2E38383E38386E382A3E38397E383ADE382B0E383A9E383A0.html

オブジェクト指向プログラミング - Wikipedia
背景
オブジェクト指向という考え方が生まれた背景には大規模なソフトウェアが書かれるようになってきたということが挙げられる。
コードが複雑化してゆくにつれソフトウェア開発コストが上昇し1960年代にはsoftware crisisといったようなことも危惧されるようになってきた。
そこでソフトウェアの再利用、部品化といったようなことを意識した仕組みの開発や開発工程の体系化などが行われるようになった。
このような流れの中で、プログラムコードについては手続きや関数といった仕組みを基礎に整理され、
その構成単位を部品化を推進する仕組みが提唱され構造化プログラミングとしてまとめあげられた。
しかしデータについては限られた種類の基本データ型の値という低レベルの抽象化から抜け出せなかった。
そこでインスタンスを整理して管理する仕組み（例えばクラスとその継承など）まで
考慮して生まれたのがオブジェクトという概念である。
C++の創始者は論理美の追求よりも現用としての実用性を重視した。
そのためC++の再定義した「オブジェクト指向」はこれらの問題を全てクリアにし、
既存言語の拡張としてオブジェクト指向機能を実装できることでブレイクスルーを迎え急速に普及する。

949 ：デフォルトの名無しさん：2011/04/09(土) 12:11:01.05

大規模なソフトウェア開発のためのC++言語。
可読性、保守性が落ちたらC++を使う意味が無い。
可読性が落ちるっていうやつは、上手く使えてないだけだろ。

950 ：デフォルトの名無しさん：2011/04/09(土) 12:15:17.72

どんな機能を備えた言語だろうと、スパゲッティコードを書くプログラマは
いとも簡単に汚いコードを書いてのける物だぜ。

オブジェクト指向に万能感を抱く時代は90年代で終わりを告げたと思っていたが・・・

951 ：デフォルトの名無しさん：2011/04/09(土) 12:17:53.44

>>949
もっと扱い易くて可読性を損なわない言語があるから
わざわざ C++ を採用する理由も無いんだろう

952 ：デフォルトの名無しさん：2011/04/09(土) 12:20:52.04

>>947
今更、素の C なんかで書きたくないわ。
C との互換性を気にしなきゃならんとか理由があるなら別だけどね。

953 ：デフォルトの名無しさん：2011/04/09(土) 12:30:08.48

>>952
中途半端な C++ で書く方が理解に苦しむわ。
Better C は絵に描いた餅。

954 ：デフォルトの名無しさん：2011/04/09(土) 12:37:16.99

>>952
今更、C++ というのも十分微妙なんだがな・・・

955 ：デフォルトの名無しさん：2011/04/09(土) 12:38:17.95

>>952
C99オススメ。食わず嫌いなら。

Cの構造体やファイルスコープなどのモジュール化機能は原始的だけど、
LinuxやFFmpegくらいの規模のプログラムなら問題なく組めるわけで、
しかもコードスペニットが局所的コンテキストにのみ依存する
シンプルな構文のため（書き手によっては）可読性も高い。

まあ、巨大なプロジェクトだとC単体じゃ辛いけど、
その規模だと他言語と組み合わせたらいいと思うわけよ。

956 ：デフォルトの名無しさん：2011/04/09(土) 12:41:47.18

>>951
CもC++もイマイチだが。CよりかC++はわかりやすいってだけ。
他言語との比較はしてないんだろ。

957 ：デフォルトの名無しさん：2011/04/09(土) 13:24:40.72

C++がCより分かり易いとは到底思えんな

958 ：デフォルトの名無しさん：2011/04/09(土) 13:37:03.95

string a,b,c;でc=a+b;など。
ポインタのポインタ使わずに参照やクラスで置き換えられること。
スパゲッティコード減らせること。

959 ：デフォルトの名無しさん：2011/04/09(土) 14:22:46.32

>>953
Better C 悪くないけどなあ。どこまでが Better C なのかは微妙なとこだけど。

>>954
それは同感。

>>955
プレステの頃は C でも書いたけどねえ。 C はもうやだ。

まあ結局何を作るかによるんだろうなあ。
みんな何作ってるのよ?

おいらはコンシューマゲームとか。
ツール類は Python とかだねー。

960 ：デフォルトの名無しさん：2011/04/09(土) 14:41:08.30

>>958
便利な機能を積み上げて行ったら、全体として汚くなってしまったのが C++ だと思うわ
スパゲッティコードは C++ でも量産可能

961 ：デフォルトの名無しさん：2011/04/09(土) 14:49:53.07

STL開発に必要な機能を付け加えていったのがC++。
STLの構想が先にあり、実現のためにC++が作られた。

962 ：デフォルトの名無しさん：2011/04/09(土) 14:59:38.83

STLのアーキテクチャの多くはアレクサンドル・ステパノフによって作られた。

1979年に彼はジェネリックプログラミングの初期アイデアを練り始めソフトウェア開発に革命をもたらす可能性を探究し始めた。

ジェネリックプログラミングの一部は1971年にデイビッド・マッサーにより開発されて提唱されていたが特定のソフトウェア開発の分野に限定されたものであった。

ステパノフはジェネリックプログラミングの大きな可能性に気づきゼネラル・エレクトリックの仲間たちに、ジェネリックプログラミングがソフトウェア開発の広範囲に渡る基礎として研究されるべきだということを説得した。

当時はジェネリックプログラミングを実際にサポートしているプログラミング言語がまだなかった。
Standard Template Library - Wikipedia

963 ：デフォルトの名無しさん：2011/04/09(土) 15:22:52.66

今頃 STL の歴史のおベンキョですか

964 ：デフォルトの名無しさん：2011/04/09(土) 17:26:37.18

コードも規格も読まないし、
C++の良さも自分じゃ説明できない（理由の無い断定のみ）から
Wikipediaのコピペくらいしか出来ないのさ

965 ：デフォルトの名無しさん：2011/04/09(土) 17:32:37.88

>>958
スパゲティコードを減らせるどころか、
言語仕様がスパゲティになってるだろwww

966 ：デフォルトの名無しさん：2011/04/09(土) 18:11:17.35

> 理由の無い断定のみ

967 ：デフォルトの名無しさん：2011/04/09(土) 23:53:08.93

>>939
> C使いが、Cが必要だと理由を言わず、ただ単にC++が不要だと言っている。

C はシステムプログラミングや他言語の拡張に有用であり、必要。

C++でも同じことは出来るが、コード片が持つ意味に影響を与える範囲が
（比較的限定されてるCに比べ）あまりにも広く、そのコード片の持つ意味を理解するのに
大量のコードに目を通す必要があり、端的に言って可読性が低い。
だからC++は不要。

> これでは、C++を使えない自分に対する言い訳を言っているようにしか聞こえない。

他者が書いてるものを理解しようとしないから、自分が聞きたいようにしか聞こえないんだよ。

968 ：デフォルトの名無しさん：2011/04/10(日) 01:15:12.65

>>967
ネタだと思うけど、なんかもう病的だよな。

969 ：デフォルトの名無しさん：2011/04/10(日) 02:57:30.67

>>959
>Better C 悪くないけどなあ。

貴方はどんな時に Better C を使うの?

一人で書くなら気兼ねせずに C++ の機能を余す所無く使えば良いでしょ。
チームで書くなら C++ 使いにとっても C 使いにとってもストレスフルな
コーディングルールを採用する事は疑問だなあ。
そもそも、どこで線引きをするかで余計な調整作業が発生するし。

嫌がる C 使いに無理矢理 C++ を押し付ける時くらいしか役に立たない
気がする。

970 ：デフォルトの名無しさん：2011/04/10(日) 08:20:41.95

どっちが好みでも構わないけど、どちらでも平均以上のコードが書けると助かるね。
不満を承知でもその条件下で最良のコーディングができるのが、良いプログラマだと思う。

こんだけ、グダグダ言われるようだと、>>967は仕事で使いたくないな。
たとえ、すごいC使いだとしても。

ま、そもそも採用しないけどね。

971 ：デフォルトの名無しさん：2011/04/10(日) 09:38:59.52

>>970
少なくとも、このスレのC++ PGはまともにCは書けないよ。
C++を書かせてもリソースリーク起きまくりのコード書くよ。

972 ：デフォルトの名無しさん：2011/04/10(日) 14:24:46.59

> 理由の無い断定のみ

973 ：デフォルトの名無しさん：2011/04/10(日) 15:15:26.41

>>969
まあ、どこまでが Better C なのかってのが微妙なとこなんだけど。

> 一人で書くなら気兼ねせずに C++ の機能を余す所無く使えば良いでしょ。

そこまではする必要がないというか、そこまでできる環境なら LL に逃げられたりするし、
そこまですると、それこそ C++ 否定派の人が言うように、ややこしい問題が発生しがちだから。

> チームで書くなら C++ 使いにとっても C 使いにとってもストレスフルな

幸いなことに C 使いは切り捨てられるので。
それと、あまり潤沢な環境でなかったりもすると、落とし所が大体見えてたりするから、
そんなに厳密にコーディングルールという形で強制しないで済む場合も多い。
もちろん阿呆が要ると破綻するけど、それはそういう人間が入った時点で負けで、
どんなに決め事をしてもおかしくなるから。
(とはいえ決まりごとが無くていいわけではないけど)

まあ、ちょっと特殊な環境なのかもしれない。

974 ：デフォルトの名無しさん：2011/04/10(日) 17:17:10.56

とりあえず>>973(>>959)がC嫌いなのは分かった。

でも、何で嫌いなのかは良く分からんなー。
多分、Cには無いがC++にある機能の何かを必要としてるんだよね？
あまり厳密なコーディング規約は必要なかったみたいだけど、
C++のこの機能だけは必須、みたいなのってあるの？

ちなみに当方、数値計算を生業にしてるためrestrict修飾子にはお世話になってます。
これで新規にFortranを書くことは無くなったから。
あとC++0xの右辺値参照には注目してる。これがあれば行列演算メインの計算はC++でやるかも。

975 ：デフォルトの名無しさん：2011/04/10(日) 18:27:28.78

>>973
>幸いなことに C 使いは切り捨てられるので。

それは Better C じゃなくて、単に制限を強めた C++ でしょ。
C PG からしたら何にも Better じゃない。

わざわざ C の名前を騙る理由がよく分からんなあ。

976 ：デフォルトの名無しさん：2011/04/10(日) 18:35:35.70

ある程度規模が大きくなると class は欲しくなりますし、
(そりゃ class が無くても書けるけど、それ言ったらアセンブラだっていいわけだし)
template もマクロよりマトモな面は多々あるし。
(酷い面も多々あるけど)

C++ は、機能もありますが、現実的な現場の共通認識として必要なのかも。
だから、このあたりは実際に作ってるものによるんだと思います。

C の資産が膨大に残ってて、 C が主流の現場で C++ 使うんだーなんて
言い張るのは、そりゃ阿呆というか不幸だと思いますし。

右辺値参照はどうなんでしょうかね。ちゃんと調べてないし詳しくないので、あれですが、
STL なんかはパフォーマンス的な底上げにはなるのでしょうけど、
行列演算が速くなったりするんでしょうか。
小さな行列演算が書きやすく速くなるならいいなあ。

977 ：デフォルトの名無しさん：2011/04/10(日) 18:57:08.17

えっと、誰か >>970 と一緒に仕事がしたいってお願いしたの?

978 ：デフォルトの名無しさん：2011/04/10(日) 20:22:16.06

>>976
行列演算 C=A+B を（オペレータオーバーロードで）計算したとき、これまでは
(1)テンポラリ行列Dを確保してA+Bの結果を格納(2)Cの領域解放(3)DをCへコピー(4)Dを解放
って無駄な処理をしてたけど、右辺値参照があればDとCのswapのような処理が書けて
(3)(4)のような無駄が無くなるという話（間違って理解してなければ）。

一度確保したメモリを使い回すような貧乏臭い処理も必要なんで、
これまで関数でやってた計算の全てをオペレータオーバーロードで置き換えられないだろうけど、
ちょっと期待しているわけです。

979 ：デフォルトの名無しさん：2011/04/10(日) 20:49:42.59

Better C 改め C++ の subset が良いという人は Embedded C++ で
アプリを書けと言われたら納得するのかしらん。

980 ：デフォルトの名無しさん：2011/04/11(月) 09:41:42.62

>>976
なんだか主張がふわふわしている。
おそらくCが嫌いなんじゃなくて、C使いが嫌いなんだな。
C使いを排除するための方便としてのC++。

981 ：デフォルトの名無しさん：2011/04/11(月) 22:39:21.26

1. C++ でないと実現が困難な事
2. C があれば C++ は必要無い事
3. C++ でも C でもやり辛い事

1 に該当する分野ってそんなに無いからなあ...
最近は 3 が多い希ガス.

C が無くなれば 2 に該当する分野は C++ で
独占出来るから、Better C とか色々考える罠.
そんなのが上手く行くとは思えんけど...

982 ：デフォルトの名無しさん：2011/04/11(月) 23:14:27.05

>C++ でも C でもやり辛い事
デバイスドライバーとか埋め込み系はC/C++の独壇場だろ。
C/C++はもはや特殊用途限定の言語。
今時アプリケーションをCで書くとか時代錯誤な認識でいるなら
出家した方がいい。

983 ：デフォルトの名無しさん：2011/04/11(月) 23:49:32.51

SQLiteやFFmpegのような、ライブラリとしての用途も兼ねる
アプリケーションは今でもCだよ。
でも、これも一種の埋め込み系かな。

984 ：デフォルトの名無しさん：2011/04/11(月) 23:52:41.12

>>982
君は Haiku OS でも使ってるのかな?
それともユーザモードも入れての話?

カーネルモジュールは C の独壇場だよ。C++ の出番は無し。
頑張っても IOKit の Embedded C++ 止まり。
Embedded だから、テンプレートも名前空間も使えない。

985 ：デフォルトの名無しさん：2011/04/12(火) 00:31:14.45

実現できることは同じだから表現力で差別化を図るC++
どうせ同じなら表現力に無駄な投資をしないC

986 ：デフォルトの名無しさん：2011/04/12(火) 14:55:08.41

C++は文学

987 ：デフォルトの名無しさん：2011/04/12(火) 15:16:13.33

次スレ
【結構迷う】C vs. C++ 2行目【どっちで行こうか】
http://hibari.2ch.net/test/read.cgi/tech/1302588918/