■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

C++についてどう思われます？

1 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 13:57

プログラム技術＠2ch掲示板において、
C++言語に関するスレッドが殆ど無いのは何故っすか？
単に此処にはC++ユーザーが少ないだけなんでしょうか。

あのようなクレイジーな言語はネタの宝庫だと思うんですが・・
「C++言語なら、オレに聞け！」みたいな方は居ないですかね。

2 名前： やめれ 投稿日： 2000/09/20(水) 14:53

やめれ。

3 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 15:19

見ての通りC++を実際に使ってるやつが居ないからです。
知識バカと読んでやってください。

4 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 16:39

C++は、ほっといても話題の中心になるからです。
多分。

>「C++言語なら、オレに聞け！」みたいな方は居ないですかね。

C++なら、俺に聞け！
1 名前： ピノレ・ヅュプス 投稿日：あぼーん
　　　俺は、C++ばっかり十年以上やってきた。
　　　他の言語のことはよく知らないが、C++の知識だけなら誰にも負けない
　　　C++のことなら、俺に聞け！

‥‥‥ってか？
あのようなクレイジーな言語で？
そんな奴、まずいないでしょ。

5 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 18:07

実際はC++って使っているけど、本気で使ってる人っていないと思う。
Windowsアプリ作るときはそりゃC++なんだが、
真面目に取り組むつもりはないって人が多いんじゃないかな。

6 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 18:11

C++は存在そのものがネタです。

7 名前： C++信者 投稿日： 2000/09/20(水) 21:55

マジでC++イカス！とか思ってる私は
手のつけようのない基地外でしょうか？

8 名前： C++信者 投稿日： 2000/09/20(水) 21:57

っていうか他にまともな言語を知らないんだけど…

9 名前： ＞８ 投稿日： 2000/09/20(水) 22:33

奥が深そうだから取り敢えず教養としてC++弄っているが・・
他の言語やっても途中で止めそうだし・・・

10 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 22:41

C++を本気で使って仕事してますが……。
極めたとは言いませんけど、
だいぶいいところまで逝ったんじゃないかと自負ってます。

>Windowsアプリ作るときはそりゃC++なんだが、
>真面目に取り組むつもりはないって人が多いんじゃないかな。

Windowsアプリを作るときはなぜかC++らしくない組み方になってしまいます。
デザインパターンすらいりません。STLは活用してますけど。
まだまだ未熟ってことなのでしょうか？

11 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/20(水) 23:04

"C++"を使ってると賞する人が多いわりに、
Effective C++すら読んでない(or 理解してない)奴が多いからです。

いろいろ出来て面白いけど、使い方を誤るととんでもないことになるのも事実。

12 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 00:06

C++のコードって、書く人によって極端に表情を変えますよね。
STLなんか、かなりクレイジーなコードじゃないですか？

俺的にはC++はメチャメチャおもろい言語だと思いますよ。
最高で最悪な言語って感じですね。

13 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 00:15

Ｃ＋＋は、Javaなんかと比較すると危険だというだけで、
Ｃ言語やアセンブラなんかとは比較にならないくらい
安全性に配慮してある言語だよ。
そこんとこ、勘違いしないで欲しいな。

14 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 00:20

変だけど面白いのは確か。
初心者には薦められないけど、中級者にはおすすめ。

15 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 00:31

言語として盛りだくさんな気がするのでつまみ食いでもいいような気がします。
でも、下手するとお腹壊すけど。

Effective C++はいいですね。基本です。

16 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 00:49

C++っていけてる言語だと思うけど、
VC++ですらtemplateまわりが弱いのが痛い。
時々パッケージ殴りたくなることがある。7.0に期待。

17 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 03:58

>>16
7.0はC#の方に力はいってそうな気がするんだけど...

18 名前： VC++ 投稿日： 2000/09/21(木) 04:16

またMS固有の仕様が出回るのか・・・・
具合わりーな・・・・・

19 名前： >13 投稿日： 2000/09/21(木) 12:49

C++のどこを「安全性に配慮してある」と表現してるの？
型チェックはANSI-Cだよね。例外処理？

20 名前： >19 投稿日： 2000/09/21(木) 12:56

13は使い方によればって言葉が抜けてるだけだ。
どう安全性に配慮してるかわからないなら気にするな

21 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 13:27

そういやC++って確か、"Don't trust programmer"
という考えの下で設計されてたんでしたっけ？

22 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 13:43

C++だとフールプルーフ※の考えをライブラリ作成時に
盛り込むことが出来る。13はそういう意味でしょうね。

フールプルーフ…馬鹿が、想像もつかない方法でシステムに
ダメージを与えるようなドジをすることに対して、ガードを
掛けること。GUIによって入力インタフェイスを絞ることなどが
その代表。OOPの場合、クラスのインタフェイスが公開メソッドに
限られることにより、ある程度のフールプルーフを実現できる。

23 名前： 19 投稿日： 2000/09/21(木) 16:07

>22
まあ、そういう意味ならわからんでもないが、確かにJAVAと比べりゃ
危険だ。
>20
はて、13はたいした発言ではないから無視してよいということか？

24 名前： 19 投稿日： 2000/09/21(木) 16:11

ただカプセル化を説明するのにGUIの話を経由したのは、若干とまどった。
いっしゅん違うレスかと。

25 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/21(木) 21:55

そういえば、ＣマガにＭＳの人のインタビューが載ってて、
「C++の開発者は、みんなC#に移行していくだろう」
的なことが書いてあったけどそうなの？

26 名前： 13 投稿日： 2000/09/21(木) 22:27

>>22の発言は正しいけど、まだ甘い。メソッドの公開・非公開は初歩。
メソッドにconstやthrowを修飾できたり、キャストが拡張されたり、
安全のために付け加えられた機能がたくさんあるでしょう。
テンプレートも安全性の高いマクロなんだよ。
Ｃ＋＋は、Ｃとは比べ物にならないくらいに強固なライブラリを作れます。
それが難しいというのは間違いじゃないけど、Ｃより危険だと考えるのは
明らかに勉強不足だね。
JavaやPascalよりかは危険だけどさ、Ｃよりかはずっと安全なんだよ。

27 名前： 19 投稿日： 2000/09/21(木) 23:01

>13
別にいまさらC++の講義を(特にあんたのような文体で)してくれとは
いってない。言語にとって「安全」というのをどうとらえているのか
を聞いているたのだが。(あんたには高級すぎる質問だったようだが)

28 名前： ぽそっとな 投稿日： 2000/09/21(木) 23:52

ＣとＣ＋＋の関係は8086と80286（のプロテクトモード）の関係を思い出すなぁ…

29 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 10:48

19氏は明らかにC++に対する理解が少ないと見られますが、
protectedが何故あるか考えた事がありますか？
関数や引数にconstを付ける目的を考えた事がありますか？

それ以前に、あなたの人間性に問題がありますね。
自分の自尊心を守る為に他人に情報を与えられる事を極端に嫌い、
挙句に牙を剥く人が居ますが、あなたはその典型っぽいですね。
自分の経験上、そのようなプログラマに碌な人は居ませんでした。

同じ勉強を続ける者として、もう少し謙虚で素直な心を持って
欲しいものです。

30 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 11:00

C++の言語仕様はきっついよなぁ。
どうしてあんなにコンパイラを作るのを難しくするのだろう。
Javaぐらいがちょうどいい。

31 名前： C++信者 投稿日： 2000/09/22(金) 11:50

そーなんです。
More Effective C++
萌えです。
これでC++に目覚めました。
C++駄目な人はこの本読んでみましょうよ。マヂで。

32 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 12:05

C++はオブジェクト指向を勘違いしてるとしか思えん。
クソ言語の筆頭。

33 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 12:46

どういう意味で？
C++が純粋なOOPLだとでも思ってるの？

34 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 13:01

Stroustrupって電波。

35 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 13:01

29は19のいっていることを少なくとも理解してないな。19の言い方もなんだが。
29は「C++は〜の機能があるから安全なんだ」と一生懸命述べている。内容は
私の見る限り正しいと思う。
19は「安全な言語」と判断する場合、どんな/どの程度の「安全のための機能」が提供され
ているべきなのか、と問い掛けているんだと思う。

>protectedが何故あるか考えた事がありますか？
>関数や引数にconstを付ける目的を考えた事がありますか？
例えば上記が提供している「安全」はいいとして、上記ではどういった
場合に対応できないか、どうすれば対応できないものが減るのか、それが
なぜC++で実装されなかったか(当然妥当な理由があるからだ)、を説明
した方がよいんでは。

36 名前： 19 投稿日： 2000/09/22(金) 13:07

Aという考え(安全を提供している機能)をどうとらえるか、という意見を求め
ている者に対して、Aに関する知識が足りない、と断じる頭がよく分からん。
まあ、いいよ。相手を選ぶべきだった。

37 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 13:31

>32
クソ言語と言い切るだけなら素人にもできるだろう。
よって具体的にどこがどのように糞なのかの説明を求む。

38 名前： お前らってコドモだな。 投稿日： 2000/09/22(金) 13:34

Aはキス。
Bはペッティング。
Cは最後まで。

分かったか？

39 名前： 29 投稿日： 2000/09/22(金) 14:09

すみません。
私の日本語の読解力が足りなかったようです。
ただ他人事ながら、27の言い方にムカッと来て、
つい余計な口出しをしてしまいました。反省します。

40 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 16:12

C++は砂上の楼閣。
楼閣の部分は確かに、そこそこ堅固（フールプルーフ）。
でも、足場は砂場（C言語）・・・

足下に気を付けながら使おうね。

41 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 20:58

このﾊﾞｶﾁﾞﾓ。
君らのOSはCとC++で作られている。評価してどうする。

42 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 21:21

ま、とりあえず代替言語がない限り
イヤでも付き合っていくしかないでしょう。
Windowsみたいな言語だな（ｗ

43 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/22(金) 21:50

技術的に素晴らしいものは世に受け入れられないのはもはや定説です

44 名前： おまえぢぢゐだな 投稿日： 2000/09/22(金) 22:04

＞Bはペッティング。
＞Cは最後まで。
タケノコ見に代々木逝ったろ？

45 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 00:00

C++はtry finallyがない時点で終わってる。ソースが
クソ長くなるし、GUIがあるような、実行時の状態が
予測出来ないアプリケーションでバグが出やすい。

代入が=なのも気持ち悪い。等号が==なのもヘン。
社員教育にカネがかかる。コンパイルが遅い。自動
変数も不気味。

出来れば使いたくない、最悪の言語。

46 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 00:15

>45
ちなみに使いたい言語ってなに？

47 名前： 名無しさん＠会社ではVG自宅はBCB 投稿日： 2000/09/23(土) 00:24

４５，４６＞文から察するにDelphi使いだね。４５さんは。

48 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 00:34

>45
C++はfinallyはいらんだろ。
変にJavaやDelphiの流儀で組もうとするから、そういう発想になる。

代入や等号の書き方なんて慣れの問題なのに、本気で文句言うのは厨房だけ。

49 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 00:48

>>47
delphi "しか" 使えない人

50 名前： 何度同じようなレスしたことか 投稿日： 2000/09/23(土) 00:56

一つの言語にのめり込んで他を糞みそに言うやつって、
自分が理解能力低い低脳だって宣伝してるようなもの
じゃないでしょうか？

51 名前： 名無しさん＠会社ではVC自宅はBCB 投稿日： 2000/09/23(土) 01:02

５０＞
そんなこともないと思うけど、ある言語や開発環境を批判するのであれば最低でも１−２年ぐらいは商用レベルのアプリケーション作成にそれらを用いて従事したことがあるという程度の経験はほしいですね。
無意味な批判に関しては５０さんのいうとおり。

52 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 01:04

出来るD使いはCも使える。でないとWin32APIの
使い方がわからない。
VBから上がってきたD使いはCがわからない人が多い。
だからあちこちのBBSにマルチポストする。
>48
C++の例外処理機構はまだこなれていない面が多い。
ANSIの決定を各メーカーは気にしすぎ。

53 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 01:09

不毛な議論だねぇ・・・

54 名前： 名無しさん＠お腹いたい 投稿日： 2000/09/23(土) 01:11

５３＞の意見が一番不毛。その次に不毛な意見は俺の意見。
以上。

55 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 01:32

>54
ふふふ、勝ったな。俺の意見が一番不毛だ。意義のあるやつは
言ってこい。

56 名前： 46>47 投稿日： 2000/09/23(土) 01:37

だめだよ。本人に言わせないと。。それが面白いんだから。

57 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 02:16

ん〜、でもオレD使ったときにfinalyは便利だと思ったな。
なにかこれと同等なものがＣ＋＋でマクロとか使って書けないですかね。

あと、breakせずにループを終了したときだけ実行されるブロックとか‥
（これはbreakの代わりにgoto使えばできるけど、ラベル名の重複を避けるのが面倒‥）

58 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 04:33

ハイ、ここで質問です、ここにDelphiしか使えない人、いますかぁ？

いないだろうと思うんだが。

59 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 04:35

>>45
C++批判するのは別にいいけど、もう少しましな理由付けてくれな。
finallyがないくらいでC++がダメだといわれても誰も納得しないぞ。

あと、等号の事だが使用頻度を考えるとPascal方式の方が気持ち悪い。
っていうか、Pascal形式の代入文の方が特殊だろう、多分。

ちなみに、等号の話をすると今まで使った中で最悪だったのがCOBOL。（藁
Delphiは、代入の記述が面倒で、C/C++は比較の記述が面倒。
でも、Delphiで代入の記述をするよりは楽だけど。
それから、PerlはC/C++に輪をかけて面倒。
つまり、１番いいのはBASIC。（藁

もっとも、C/C++の式の途中で代入ができる仕様はわりと便利だったりもするが。

60 名前： 名無しさん 投稿日： 2000/09/23(土) 09:48

finally相当の機能はC++にあるよ
　関数内で構造体作ってデストラクタでOK

61 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 10:17

そろそろC++も配列とポインタを明確に区分するようにした方がいいと思う
char *p;としてp[32]とか出来るのは絶対に変

62 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 10:29

だが貴様らの愛する言語のｺﾝﾊﾟｲﾗたちもC++で作られています。ﾜﾗｲ

63 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 10:40

>60
は？クラスの破棄だけの問題では無いと思うんだが？

>59
いずれも慣れの問題だ。だがCの初心者は比較と代入を
良く間違える。C文化の弊害としてタイプ量をけちって
コードの読みやすさがそこなわれている一例。
C++もその伝統はあいかわらず。

BASICはくそ言語。どうせ初心者用なんだからプロなら
２年以内に見切りをつけるべき。仕事で使いつづけるな。
客が迷惑。

Delphi(ObjectPascal)の言語仕様はシンプルで強い型づけ
により堅牢だが悪い面もある。シンボルの大文字小文字
を区別しないという点がくそBASICと同じだということだ。
BASICよりはましだがそこら辺が初心者用扱いされる原因。

64 名前： > 63 投稿日： 2000/09/23(土) 11:51

>　　　　　　　　　・・・　　　シンボルの大文字小文字
>を区別しないという点がくそBASICと同じだということだ。
>BASICよりはましだがそこら辺が初心者用扱いされる原因。

これはあまり関係ないのでは？
言語仕様・ＯＳのコマンドインターフェース仕様では大文字・小文字
区別しない方が主流で、C言語やUnixは珍しい方と認識しています。

さまざまな環境（ＰＣから大型機まで）での動作をサポートする
方針が最初から明確だった言語では、小文字や波かっこを必須と
しない仕様となってました。角かっこを避けるものすらありました。

C言語とUnixは以下要因から小文字・大文字を区別する仕様になった
ものと推測しています。

・非常に小さなコミュニティ内で設計された。
・同コミュニティでの利用しか考えられていなかった。
・設計者が大文字より小文字の方が読みやすいかなと感じていた。
・手元にあったハードウェアは小文字と大文字を区別できた。

Adaは区別しなかったはずですが、およそ初心者向け言語ではあり
ません。

ちなみに、区別しない方が優れている、といっているわけではあり
ませんので、よろしく。

65 名前： ＞６３ 投稿日： 2000/09/23(土) 12:18

try{　　　　　=> struct XX{ XX(){
・・・・・本文・・・・
}~finally{　　=> } ~XX(){
} 　　　　　　=>　} }HOGE;
と対応させられぞ

66 名前： <63 投稿日： 2000/09/23(土) 13:06

なんつーか、Ｃ／Ｃ＋＋を使ってるっていう感じがぜんぜんしない
から、面白くないんだろうなぁ。

67 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 13:19

>65
もっと分かりやすく書いてくれ。おちゃらけかと思って読み飛ばそうと
したぢゃないか。

68 名前： >65 投稿日： 2000/09/23(土) 13:22

ずいぶんタイプ量が多いな
C／C++のタイプ量をケチる原則から外れてるぞ（汗；

69 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 13:47

>>65は、「やれば(一応)できる」ってだけでしょ。
class内のconst定数の代わりにenumを用いるのと同じ。

だから、「どうしてもfinallyが使いたければ、面倒だけど代用手段はある」
と言ってるんじゃないの？

70 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 15:51

改訂されたけど、static const の初期化をクラス定義内に書けないのはなにげに痛かった。
C言語の伝統にしたがって#define 定数でもいいだけどねえ。
次のバージョンでMS-Cも対応してくれるだろうか？

Javaの方が言語仕様的には好みなんだけど、もうすこし柔軟でもいいとおもうのと、
仮想マシンの設計がスタックマシンを前提としてるなんてクソだとおもう。
まぁ、もともと組み込み向けだから、コードサイズを小さくという
要求があるからしょうがないとは思うけどさ。

71 名前： >65 投稿日： 2000/09/23(土) 15:54

Delphiはよく知らんが、finallyの中身が呼ばれるタイミングが
違うんじゃないか？
{struct XX { XX() {
本文
} ~XX() {
後始末
}} HOGE;}
としないと。

72 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 19:01

>63
>良く間違える。C文化の弊害としてタイプ量をけちって
>コードの読みやすさがそこなわれている一例。

まったく無意味な「一例」ですね。
もし、{}をbegin,endに変えたり、=を:=に変えたり
しただけで読みやすさが向上すると思ってんの？

73 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 19:22

C++は一応、Cの直系と目されているけどさぁ〜。
古くさいC言語批判を展開するのはやめよーよ。

C++の一番悪い点は、言語仕様の大きさと、"C"の直系ということ
だろうね。このスレッドをみて確信するよ。

74 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 21:33

C#も結局それを受け継ぐんだろうなー。

75 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/23(土) 22:03

>74
C#はC/C++とは関係ないよ。
あれはどう見ても腐れJavaもどき。
ついでに、ネタだからまじレスすんな、という言い逃れはなしね。

76 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 01:20

finallyが必要になるのは、deleteを使うからだね。
特にBCBなんか、VCLをnewでしか確保できないから、この問題は深刻だよ。
ところが auto_ptr<TStringList>(new TStringList); とかやっとけば、
実はBCBでも__finallyをほとんど駆逐できる。
それができない場合でも、クラスの中にポインタを隠蔽しておいて、
デストラクタにdeleteさせればいい。
つまりデストラクタをうまく活用していれば本来は不要なんだよ。

ま、finallyがあって害もは無いけどさ。
それに次回の改定では採択されるって聞いたことがあるよ。

77 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 01:40

Java,Eiffel,Pascal「すべてのプログラマーはバカだから、安全策はすべての面で必要である」
C++「バカなプログラマーは多いが、一部のコアとなる人物がしっかりと安全策を施した
ライブラリを十分に検証すればいい。完全な安全策は実務では障害となる。」

しかし、C言語との互換性が言語を不必要に脆弱にしている。
Stroustrupもそれは認めているぞ。
C言語との互換性をいちばん悔やんでいるのは、おそらくStroustrup本人だろう。

78 名前： >76 投稿日： 2000/09/24(日) 01:47

ファイルのクローズやソケットの解放もそれでやるのかい？
そのときエラーが発生した場合、例外のスローとかはデストラクタの中では処理できないと思うが。

79 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 01:49

C++がCと互換性なければ、こんなごちゃごちゃの言語だれも好き好んで
使わないよ。

80 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 01:54

>77
C++がCとの互換性を放棄したら、どのあたりがすばらしい言語になるはずだったのか、
ぜひ説明してくれや
それができんのなら受け売り君と名づけよう。

81 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 02:10

>>80
グローバル変数禁止。
マクロ禁止。
(cast)方式のキャスト禁止。
これだけでもかなりすばらしい言語になるって事、
もう直感的にわかれ。
きみ、ダメすぎ。

82 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 02:21

>>78
>そのときエラーが発生した場合、例外のスローとかはデストラクタの中では処理できないと思うが。

CFoo::CFoo() throw(); ←こうあるべきだ、ということでしょうか？

83 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 03:07

>81
>グローバル変数禁止
主観の問題かもしれないけれど、あまりすばらしく感じないが…
C++でコンストラクトの順序の問題がいやってことかな。でもクラス内の
staticメンバは結局さけられないし。
>マクロ禁止
#define aa()とかの廃止は賛成だ。#ifdefとかは残すんだよね。
>(cast)方式のキャスト禁止
まあ、クラスのポインタに対して(cast)を禁じてもよかったと思うが、そもそもC++の
初期にはdymamic_castとかなかったんで、あながちCのせいともいえない気がするが。

84 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 03:26

なんでデフォルトで仮想関数じゃないんだーって批判を聞くけどさ、
もしそうだったら、もっと批判されちゃうよね。

85 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 03:33

nameof()演算子が欲しい。
type_info でとれるけどさ。返す値が処理系によって違うのがねえ。

86 名前： 59 投稿日： 2000/09/24(日) 03:58

>>63
言語の比較をしたいわけじゃないんだけど。
あくまで、俺が今まで使った言語の等号を比較してるだけだから。
取りあえず、等号に関してだけBASIC方式が１番楽だったというだけの話。

87 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 04:44

if(!c++) goto hell;
else throw stones;

88 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 04:46

>82
すまん。できないというのは語弊が合った。気持ちとしてはまともな処理は
できない、なんだが…。82は多用する？

89 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 04:52

>クラスのポインタに対して(cast)を禁じてもよかったと思うが
同感。C++はせっかくclassという新しい予約語を導入したのに、structと
ほとんど差別化していない(まったくとはいってないので念のため)。
もっと活用してもよかったと思う。

では、なぜそうならなかったのかというと、C++がCとの互換性を配慮した
からではなく、C++がCから段階的に拡張されたからだ。C++でキャストが問題
になった時には、C++自身の過去との互換性を考えると変更できなかった。

90 名前： 82 投稿日： 2000/09/24(日) 05:03

CFoo::CFoo() throw();
は
CFoo::~CFoo() throw();
の間違いでした。

>>88
デストラクタでうまくやるということは、
クラスの中で解決しなければならない事情を、
クラスの外に持ち込まないということでは。

91 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 05:08

ある例外が発生してスタックのリワインドが起こるとその間のオブジェクトの
デストラクタが呼ばれると思うが、その時にデストラクタがさらに例外を
発生したら、いやではない？

92 名前： >91 投稿日： 2000/09/24(日) 09:12

それはDelphiのfinallyも同じじゃないかな？　finally節で例外を出してしまって
それをfinally節で処理しきらなければ２つの例外が発生した事になって、元々の例外
を忘れてしまう。
デストラクトでも同じでは？

この話は、C++でスタティクな構造体のデストラクタは巻戻し保護されるって奴だよね。
これを利用してfinally代わりに使うのはC++の今更議論するまでもない基本テクだと思うけど

93 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 12:13

>それはDelphiのfinallyも同じじゃないかな
これはそうかもしれない。
>これを利用してfinally代わりに使うのはC++の今更議論するまでもない基本テクだと思うけど
finallyで例外が発生しないケースでは使える。
私は、基本的にデストラクタで例外が発生するようなコードは極力書かないようにしているが…
91は割とデストラクタでからも例外を投げるんだ。あんまり問題になることってなかった？

94 名前： >93 投稿日： 2000/09/24(日) 13:26

デストラクタから例外を投げるのは設計が変だよね。
デストラクタ内部で例外が発生しても自分で処理して外に投げないのが普通では？

95 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/24(日) 13:41

ふむ。いってることは同じみたいだね。

96 名前： 82=90 投稿日： 2000/09/24(日) 22:16

デストラクタから例外を送出するとどのような問題が発生するのかは、
勉強不足でよくわかりません。
明日会社でEffectiveC++でも読んでみます。

でもfinallyで処理するということは、クラスの外でエラーを処理
するということですから、カプセル化の原則に反しませんか？
デストラクタをきちんと利用した上で、さらにthrowを投げずに済めば
いちばん理想的なのではないかとおもいます。

97 名前： 名無しさん＠お腹いっぱい。 投稿日： 2000/09/25(月) 00:28

デストラクタって、すでに役目を終えたオブジェクトに対して呼び出される
ものだから、デバッグ用のエラーチェックの例外以外は投げられても困るかも。

デストラクタが投げる例外を捉えるtryブロックを書く場所も悩ましいです。

98 名前： 78=88 投稿日： 2000/09/25(月) 02:25

>96
finallyで例外を投げないケースは問題ない。例外を投げるケースが問題、と
述べている。

99 名前： 78=88 投稿日： 2000/09/25(月) 02:32

失礼。手がすべった。
デストラクタで例外を発生するのは基本的に私はやらない。

>でもfinallyで処理するということは、クラスの外でエラーを処理
>するということですから、カプセル化の原則に反しませんか？
finallyの代用にデストラクタが使えるかという話から始まっていると
思うのだけれど、上記の論旨を補足してもらえないだろうか。

100 名前： 756@折角なので一応 投稿日： 2000/10/06(金) 19:25

>767
やや、御指摘の通りです。便利なＣ、確かにそんな節が最近あるかも・・・。

一応情報をひとくくりにしたり隠蔽したりってのは常に心がけているのです
けどね。メンバ変数は絶対privateみたいな。ただ、ときに「このメンバ変数
がpublicなら、いちいち新しい関数作らなくていいのに」って思っちゃうこと
があって・・・。
そんなときは、隠蔽保持のため新しいメソッドを乱立する、みたいな解決方法
しかまだ思い浮かばないんです。で、あんまりつまらないメソッド作りすぎる
の恐いな、ってのもあってあの質問をしたわけなんです。実は汎用（最初から
見通せてる）って感じよりかは、泥縄式に増えていくって感じですね。

いやオブジェクト指向、奥深いっす。has-aだのis-aだの、読んでる分には楽
しいんだけど、いざ使うとなると応用がねぇ・・・。僕も上級者のコードとか
意見聴いて勉強したいです。