なぜＣ＋＋はあんなに難しいのか？

なぜＣ＋＋はあんなに難しいのか？

オブジェクト指向やＵＭＬを理解し
巨大な仕様のＣ＋＋を理解し
モノを作るのは骨が折れます。

Ｃ＋＋ってＣと比べて（あえてこう書かせてもらう）成功したと
言えるのでしょうか？
普及したから良いものか？
普及したのは良いから？

多重継承ってなに？
純粋仮称関数ってなに？
多態性ってなに？
レイトバインディングってなに？
アーリーバインディングってなに？
フラストレーションが溜まってます。

Ｋ＆Ｒとストラウス〜の考え方は違うとおもう今日このごろ。

つうかＯＯＰが理解できない小生のぐちだね。やれやれ。

ストラウストラップ。ストラウス罠と覚えましょう

ストラウストラップの衝撃発言がありましたね。
C++はタチの悪いジョークだと。どこに載ってたかは失念。

COMはC++のものではないですが、COMバイナリ互換と
インターフェイスの分離はたとえ理想的なメカニズムでは
ないにしろ、単なる創意工夫を越えて１歩前進、なのでは
ないですか？ 実際にはC++の果たしている役割は大きいと
思いますが。
実装の継承よりインターフェイスの分離のための純粋仮称関数。
しかもC並の動作効率を望めるということで、逆にこれ以外なにが
あるの？と思いますけど。 環境として。
妥協の産物であるけれどもそれは偉大な妥協、現実からの逃避を
しない仕様、ということで。どうですか？

C++は//コメント〜
って書き方が出来るから使いだした(笑)

文法を理解出来ても、それだけじゃプログラムが組めないところがイタイ
何をどうクラスにして良いかわからんよ。

C好きじゃ〜、お前だけが頼りだ・・・asmにperlも愛してるぜぇ〜

＞３

＞ストラウストラップの衝撃発言がありましたね。
＞C++はタチの悪いジョークだと。どこに載ってたかは失念。

ほんとですか？
Ｃ＋＋の仕様はどう考えても頭に入りきる大きさじゃないしね。
Ｃのバイブルと比べてもＣ＋＋は異常ですね。
ストラウス〜もベルの人ですよね。
抽象的でパワフルなＵＮＩＸやその先のＰＬＡＮ９の研究者との
関わり合いはどうなのでしょうかね？

ベルの産物にしては疑問・・・

>>1
えーとねぇ。
後半の多重継承云々ってところから下のごちゃごちゃしたの
全てを覚えるよりも、オブジェクト指向（用語じゃなくて概念を）
をきっちり理解さえすればそれだけで他の化石プログラマ達を
駆逐することができる分野があることが魅力でしょうか？
逆にオブジェクト指向が理解できない人にとってはゴミ同然の
物であることは確かだと思います。

STLが便利なのだ。。。

>>1
むずかしくねぇよ。おめぇの頭が悪いの。

オブジェクト指向を知りたいなら、GUIを作ることだね。
ありがたみがわかるよ。

＞７

今は言語からはなれてオブジェクト指向＆ＵＭＬをやってます。

Ｃ＋＋とＪＡＶＡを同時に習得しろという上からの命令で
苦しんでいる小生。鬱。
その前にオブジェクト指向を・・・でもわからん。
ＸＭＬ，ＣＯＲＢＡも同時進行。
全部中途半端。
でもうごく。こぇー。
上のひとはそれで満足。
機能追加拡張なんて絶対できん。

>>9
いやぁ、この人（１）言語の仕様を全て覚えようとしてるみたいだぞ。
Ｃ＋＋ってオブジェクト指向を覚えてから何が必要なことか
わかってないと覚えることばっかり多くなっちゃって
役に立たないし、すげー複雑だからハマっちまうと最悪の部類だと思うぞ。
先輩から最短コースで教えてもらった俺は幸福な奴だと思う。

＞９

どうしたら頭よくなりますか？
どうやっておぼえた？？？
おぼえたときＣ＋＋に対する疑問とかあった？

シロートですけど。
人様の作ったクラスを便利＆お気楽に
使うには、これほど極楽なものもないと思うんですが。
ま正しい理解とは違うでしょうが、極楽。

かぶった…
おれ９じゃないです。

＞１２

サンキュー。
とりあえずざっくり覚えることにする。
要領よくやることにするよ。

>>11
まずは何よりこの↓本ですよ奥さん。
http://www.fry.is.sci.toho-u.ac.jp/~takada/twosoft/technic/81.html
もし、もってなかったら、さっそく買ってくることをお勧めします。
なんか紹介にはＣ＋＋の入門書が必要だかなんだかと書いてありますが、
とりあえずこの本を読むことが１番いいと思います。
次にやることはオブジェクト指向関係の本を片っ端から
読み漁る事だと思います。駄目な概念を知るため。
基本的に駄目な本の方が多いから。
Ｃ＋＋の言語それ自体は二の次。

>>17
ありがとう。

Ｃ＋＋の言語それ自体は二の次というのは承知です。
でも仕事でＣ＋＋すぐ使うんでやらざるをえません。
まわりもシロート。おれはバカ。

class,template
この二つを完全に理解すればＣ＋＋は８割理解したも同然。
ね！簡単でしょ(藁＞１

Ｃ＋＋で動けばいいと良しとする上司。
作ったプログラムはユーザ管理の基礎のぶぶん。
でも仕様は変てこ。
ここから発展させるのでこのシステムの行く末は見えてます。

>>19

とりあえずＣ＋＋組めるよ。
とりあえずね。

わからないところはなんとなく組んでる。

お、おれも>>17の本はお勧めだ〜。
実はおれは１以上にC++組めないと思うけど、
この本読んだら元気出たよ。
がんばれ１。

ストラウストラップのインタビューはジョーク記事だよ。
URL忘れたけどさ。

修得困難な仕様にしてプログラマに仕事を与えるためだとか云々

でも、ジョークにならないよなあc++の場合。

俺にとってもＯＯＰは、ものすごい壁だったよ。
COBOLを４年Ｃを３年した後のＣ＋＋。
受け入れるのに３年かかった。

しかし、受け入れる事ができた今、ＯＯＰはやっぱ素晴らしいと思う。
俺の場合は、ポリモーフィズムの現実の利点が理解できたところが
壁を越えたと思ったところでした。

がんばれ１

１です。
元気が出てきたみたい。がんばるよ。
ありがとう。２ＣＨの人は好きだ。
なんかつよくなれるよ。

Windowsで
軽い開発はVBにのっとられ
思い開発はＶＣ＃

マクでも先端開発はObjectiveCだっけ？

CGIにしてもPerl開発が体勢かな。
JAVAが今受けているのもあるね。

すべてC++がむちゃくちゃだから
C++から脱却したいわけです。

生産効率の低いC++は滅びていくだけでしょうね。
アセンブラと同じ運命。

C++ とレイトバインディングって直接関係あったっけ？

>>17
の本は OO の本としては良い本ですが、C++ の本としては微妙です。
ポインタの配列をデフォルトで使われると泣きます。
どっちかつーと Java っぽいコーディングだと思う。

VC#で重い開発はないと思うが…
CLRがネイティブコードより速い事はないはずだ…

C++で生産効率が悪いのは最初のうちだけ。
馬鹿な開発者が再利用性のないコード書き散らしてる間は
「使えない」という判断にならざるをえない。
でも、性能の良いライブラリがそろえば、開発はクラス同士
を結合する作業だけになってくはずっすよ。それがOOPっす。

C++をけなす奴==「自分は馬鹿です」と公表してる奴、だと思うが。
天に向かって唾を吐くって知ってます？

＞26
ふぅ〜。
Perlじゃ機能的に制限ありすぎて掲示板やメール程度が限界。
ＪａｖａはＭＳに見切りをつけられ死亡寸前。
ＶＢはＶＣで作ったＣＯＭオブジェクトがないと何も出来ない。
ＶＣは不滅だよ。
ただ扱えない人間が無理してＶＣ使う必要がなくなるだけ。

Java出来なくなったWinが滅亡寸前ではないのか。
かつてWin3.0（2.0もあったらしいが）が日本に入ってきた頃、
劣悪OSだが数でUNIX/X-Windowを凌ぐだろうと言われていた。
同じように劣悪携帯Javaが数でWinを凌ぐんでわ．．．あ、C++スレだった。
C++は機能は足りなくないんだが、後発のOO言語より記述が多く習得し難い。
でもOO言語習得したら第三世代言語にはもう戻れない．．．

＞30
ｉモードは自滅しました。
無理にＪａｖａ対応にしなくても専用の言語作ればいいのに。
基本的にｉモードＪａｖａってＪａｖａ互換ってだけで
似て非なるものなんだしさ・・・
それにしてもＪａｖａは開発環境が悪い。

>>31
Javaスレではないが…
JavaにIDEは要らん。もし作るならVJ++みたいに
ネイティブで作れ。あほベンダども。

10年後ならかまわんけどね。マシン速いだろうし。

１０年後は量子コンピュータの登場によりＶＢ厨房は死滅します。
と思ったが死滅するのはＶＣか？
量子アルゴリズムでプログラム書ける奴はいるのだろうか？
すこぶる優秀な人間のみネイティブコードプログラムを作り
一般人はスクリプトが限界か？

>>それにしてもＪａｖａは開発環境が悪い。
そうか？
私には、SDKで十分だが（C++スレだって）
C,C++は滅びないと思うが、VC++は無くなってもかまわんな。

>31
Javaが劣悪環境だって？
Winだって昔は、C言語なのにfarとnearとポインタが２種類あったり、
640KByteまでしか線形でメモリとれなかったりスゴかったんだぜ。
それに比べたら、携帯でメール出来た上、アプリ動くなんてスゴイじゃん。

>１０年後は量子コンピュータの登場によりＶＢ厨房は死滅します。

VBスレで叩かれた注坊がC++叩いてる。自分の能力を高めるまで静かにしてなさい。

↑引用文一行足りなかった。

>と思ったが死滅するのはＶＣか？

C++は開発規模が大きくなればなるほど、破綻してる言語仕様のおかげで生産性鈍ってくる。
単体で性能の良いライブラリを複数組み合わせれば、それぞれが自分の世界を主張し合う
ので、ほとんど実現不可能でしょう。28はまともに開発したことないんだな。

クラスを使っていくのは簡単だけど、キチンとしたクラス作るのは
なかなか大変。
Effective C++読んでたらC++が嫌になった、っていうような書き込み
が以前あったけど、それはわかるなあ。
ある程度のモノを作るのはそれほど難しくないし、バグ削減にも
非常に効果あるっていうのは実感してるけど、それを他人様に使って
もらいたいかというと話は別になるけろ。

C++ というよりVCが難しい。何故にあんなに難しいの

私はBCBでＣ++おぼえたよ。VCL激ラブ♥

>C++ というよりVCが難しい。何故にあんなに難しいの
>私はBCBでＣ++おぼえたよ。VCL激ラブ♥

VCはMFCで作られてる（んだよね？）から固定ダイアログ画面が一杯開いて使いにくい。
BCBはVCLで作られてるからGUIの動きが良い。

>>42
>VCはMFCで作られてる
ＶＣ＋＋はＶＣ＋＋で作られました。とは書いてあったけど
ＭＦＣで作ったとは書いてないね。
俺はＭＦＣなんて使ってないと思うな。
あれってでかいプロジェクトには全く向いてね−もん。
ＶＣ＋＋を使い始めると必ずやらんでもええＭＦＣを始める
ノータリンが多いのは何故？挙句の果てにはＶＣ＋＋で作ると
必ずＭＦＣを使って組まなければならないとまで勘違いしてる奴まで
いてかなり鬱。

今時MFC使ってる人はいないでしょ…

>>43
スマソ、かつて俺がそのノータリンだった。
パッケージ同梱の入門書がＭＦＣだからつられて始めちゃった。
で、３日も持たず撃沈。「ＭＦＣのプロフェッショナル」って
すごい人なんだろうなー。

>>43
上に同じ。ノータリンです。

Winアプリは仕事上は社内ツールくらいしか作らないので、最近のトレンドは
知らないデス。
今時は何を使ってWinアプリ組めば良いですか? オススメは何ですか?

http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

C++はドキュソです。

>38
コレクション用のテンプレートライブラリとか、
ホスト間通信のラッピングライブラリとか、
データベースとのコネクション管理のライブラリとか、
共有メモリ領域の管理モジュールライブラリとか、
最近ならXMLパーサとか、暗号化関係とか、

ミドルレベルのモジュールとして扱えるライブラリを
お借りしてプログラム組めば、非常に楽だぞ。

凝集度の低いモジュールを組み合わせようとしている
時点で設計者があほですな。

>>47
そのジョークはもう飽きたよ。
まさか、お前そのジョーク、本気で信じてるわけじゃないよな？

>>49
事実そのまんまじゃん。

>>50
オブジェクト志向は、小さいプロジェクトには
あまり意味は無い。
プロジェクトが大きくなるほど
オブジェクト指向のありがたさがわかるのだよ。

一人ぼっちでプログラムしてる人には
C++の良さは理解できんかもね。プッ（ｗ

CとC++は明らかに設計時のコンセプトが違うような気がする。
Cはシンプルを目指している感じがするが、
C++は何でも詰め込もうとしている感じがする。

うまく使えないからといって言語仕様のせいにするのは恥ずかしいね。
Ｃとの互換性や実行効率を確保しつつ機能拡張していった言語としては
非常によくできてると思うけどなあ。確かにとっつきは悪いけどプロの
道具と感じで使い込むほどに良さがわかるんだよね。

>>53
うまく使えないとも、
それが言語仕様のせいであるとも言ってないのに、
勝手に勘違いするお前の方が恥ずかしいけどな(ﾜﾗ

ダテュラやベッキやエドやエムエヂタ、WWWCは
MFｃでないかな？DonuTはSDKか。

>>54
仕様が破綻してるとか言ってるやついるじゃん

ずいぶん上の>>28にレス

>C++をけなす奴==「自分は馬鹿です」と公表してる奴、だと思うが。
>天に向かって唾を吐くって知ってます？

アセンブラをけなすヤツ==「自分は馬鹿です」と公表している...

とアセンブラ使いは高慢チキに天狗になっていたら
生産性が低かったので滅びていました。

C++使っていても、もっと使いやすいものを知って
認める考えは持っておいたほうがいいよ。

JAVAやC#を批判する時には現状の使用感と言語仕様
というものをわけて考えたまえ。

もともとCだから
以上

組込型とクラスを同じように扱えるようにしようとしたのが
きっと悪夢の始まりだったんだな

こうなったらObjective-Cの復活が望まれます。
http://users.pandora.be/stes/compiler.html

MFCは要領よく使えばいいだけ。
まだ分らん奴が中にまぎれてるな・・。

MSDNから使うものだけFavoritesとかに分けとけば、
超整理法ぽくAPIもMFCも分類ワケできるはずなんだけど。

他のOSに関してはしらないぷー。

プログラム作法って、言語とは独立したものだと思うのね。
だから、C++が難しいというのは、OOPが理解できてないからであって、
言語のせいではないと思いまふ。MFCは必要な部分だけ使えばいいし、
使わなくたっていいわけだし。

関係ないっスけど、JAVAのsuperって表記、C++でも使えると便利だなぁと
思いません? 派生元が変わると書き直すの面倒だし(笑)

>>57
28じゃないけど
28の人はどっちかっていうとＣ＋＋マンセーな意見じゃなくて
オブジェクト指向マンセーの意見でしょう。
それに今オブジェクト指向＋Ｃ＋＋を受け入れることができる
柔軟性があるなら別に問題は無いんじゃないでしょうか？

C++は難しいのでオブジェクト指向まで到達するのにも時間がかかる。

>>63
＞関係ないっスけど、JAVAのsuperって表記、C++でも使えると便利だなぁと
便利だと思うので、たいていのクラスでは
class A : public B
{
  typedef B Super;
としてる。

多重継承があるから文法には組み込みにくいのだろうね。

C++に躍らされてる奴らが多いな。特に >>53 なんか（藁

本気でオブジェクト指向プログラミングというものを考えれば、
C++なんて欠点だらけのじゃじゃ馬だということがわかるはず。
自分がC++に操られてるだけって気付かないなんてかわいそーだぜ。（藁
もうちょっとおべんきょうしたらー？

>>67
多重継承してても、同じ関数名がダブってなければ特定できるわけで。
本当にピンポイントで指定したいなら、今の文法と同じでSuperClass::func()と
呼べばいいかなと思ったわけ。モダンなライブラリでない(笑) MFCは多重継承
ほとんどしないんもんで、ほとんどがsuperで済んじゃう。

そういや、ベースクラスのポインタで引き回したい時、多重継承してると
先に指定した方の型にしかならないんだよね。構造的には理解できるけど、
これもなんか解決する方法ないかなぁ。 > C++
#設計が悪いという話もあるな。

Javaは new するなりその場で? 派生クラスを定義できるのが便利。
わずか1個の関数の挙動を変えたいだけで派生クラスを宣言しなきゃ
ならんC++に比べると便利な点が多い。可読性は下がるけど、妙な
クラスが大量に出来るよりはスマートな気がする。

C#ってこの辺りどうなんでそ。全然知らないんだけど...。

>>69
superが型名だったらsuperクラスの関数呼び出しにしか
使わないわけじゃないでしょ？　

>>68
具体的にどこが欠点だらけなのか指摘してみろよ。(藁

>>63
C++が難しいのは言語仕様のせいではないって？
じゃあ、「Protected Abstract Virtual Base Pure Virtual Private Destructor」
がどんなもので、それを最後に使ったのがいつか説明できるかい？(藁

C++は言語ではない。
Cでイベント駆動型フレームワークを作るための
拡張ライブラリである。

>>72
63じゃないが、そりゃ論理のすりかえというものだろう。
それがわかるかどうかと実用の難しさとなんの関係もなかろう。
どんな言語だって探せば大概微妙なところあるぞ。

アセンブラとＣ++を同じ土俵で語る無かれ。

つーか、プログラムを作るという行為（実装する）で、その言語を
完全に理解する必要はあるまいに。（知ってるといいけどな）
自分にとって使いやすい概念だけ取り入れればいいだけでは？

言語の開発屋が言ってる「C++が難解である」ってのと
それを使う側の「C++が難解である」ってのは違う意味でがしょー

それなりに便利だけどなぁ。＋＋は。
とはいえ、制御屋だから、あんまし出番ないけど・・・^^;;

>>ALL
ではこのスレの命題である
「なぜＣ＋＋はあんなに難しいのか？」
の答えは
「言語仕様の前にオブジェクト指向を理解しないといけないから」
ということでよろしいでしょうか？

いいわけないだろ

Cと互換性を保つ意味が分からん。
++するときにCのソースをそのまま転用することは
そんなにないと思うのだが…。
実行効率もObjectiveCより格段に良い訳でもないし。

>>77
「なぜJavaはあんなに難しいのか」という質問が
あまりきかれないことからその答えは否定できる。

>>79
Cプログラマが少しの勉強でC++プログラマになれることが期待できる。

C++の失敗を踏まえてのJava、Javaの失敗を踏まえてのC#だな。

C++は難しいって言ってるけど C++は簡単だよ
というか、難しく使う方向性が間違っている

Javaは言語仕様で難解にならないように注意しているだけ

>>77
オブジェクト指向は理解してるつもりだけど(Objective-CとRubyは使える)、
C++はさっぱり分からんぞ。

まあ、道具としては使えないことはないがな。

C++とオブジェクト指向を身に付けるまで４年かかりました。
この４年という数字は、本を読んでの４年ではなく、
実際に開発に使用して、プロジェクトの中でもまれた４年です。
Ｃやアセンブラなんて数ヶ月もあればマスターできることと比較すれば、
難しいといえるのでしょう。

C++をプロジェクトで使って、最初の１年は最悪でした。
プログラムはぐちゃぐちゃで、Ｃで作ったのと変わらないばかりか、
C++の動きをよく把握していなかったことによるバグも頻発しました。
しかしそのプロジェクトを通して、オブジェクト指向の正体が、
すこしづつ判るようになってきました。同僚たちも理解が深まり、
オブジェクト指向をふまえてレビューができるようになりました。
それから３年、いまになってようやく、ほぼマスターできたのではないかと
思えるようになったのです。

しかし、時間をかけて身に付けた今、
身について正解だったと断言できます。
その間に覚えたものの価値を考えれば、
４年は決して長い期間じゃなかったと思います。
だからそういう意味では必ずしも難しいとはいえません。

ご存知のようにC++には多くの欠陥があります。
だけど誤解しないで下さい。Ｃ言語のほうがはるかに
欠陥だらけで危険な言語なのですよ。
オブジェクト指向を良く知らない人は、
C++に対する批判の意味を理解できないため、
C++が批判されているという事実だけに目を奪われ、
Ｃ言語のほうが優れているかのような錯覚を引き起こすのです。

車に例えれば、C++という車はドアをロックしておかないとエアバッグが
作動しません。ロックを忘れたら、エアバッグが動かず危険です。
しかしＣ言語という車にはエアバッグそのものがついていないのです。
だからＣ言語のオーナーが、C++のエアバッグについての批判を読んで、
「C++は危険で、Ｃ言語は安全だ」というのは明らかにおかしいのですよ。

Javaは言語的にはC++より優れていますが、活用できる分野が非常に限定的で、
そういう意味ではまだまだC++にとってかわることができません。
JavaがC++にとってかわるには、まだ何年もかかるでしょう。
少なくともウチの開発ターゲットには、環境すら存在しません。

>>82
C++も、もともとは単純な言語だったのだが、
「型付の強いオブジェクト指向言語だったらこういう機能が不可欠だよ〜」
っていう現場の要求が多くて、それに従って大きくなってきたってところが
大きいからな。歴史を知らないと難しく思うのも無理もないかも知れん。
歴史を知ってればあるべきものがあるところにあるだけなんだが。

C#が出たら++はほとんど絶滅すると思う。
あれはjava風のObjectPascalだよ。
CよりPascalのほうが寿命が長かったってことだね。

C#に期待♪
ぜんぜん手つけてないけど・・(笑)

Perlもオブジェクト指向してるけどどうかね？
ネイティブコンパイラが完成して処理速度さえ問題無くなれば
結構良い言語だと思う。
.Netに対応するらしいし俺は結構期待してるよ。

C++は難しいよ。
ルール１とルール２だけ、一つずつ見れば、簡単そうに見える。
でも、ルール１とルール２が組み合ったらどういう動作をするのか？
というのがわかりにくいんだよ。
さらに、ルール３も有効になるとどういう動作になるのか？
とか、無限に組み合わせが出てくるね。
非常に複雑になる。

Ｃ＋＋の難しさが分からない。
Ｃ＋＋(.cpp)でもＣと同じコーディングしてる。
クラスってなんですか？
インヘリタンスって？

>>87
ルール同士の整合性は考えずに、
そのルール単体での必要性から導入されてるからな。
STL大好きさ（笑)

C++は難しいという人に難解なC++ソースの提示をきぼー。
どんなソースが難しいのか知りたいなぁ。

Ｃ＋＋のソースは見た目が汚い、
Ｊａｖａは綺麗で読みやすい。

見た目だけかい（藁）

Ｃ++は「オブジェクト指向も使える」Ｃのスーパーセットだと思っておけば難解とかソースが汚いとか言われるんだと理解してるけど。

Ｃは高級言語だという人もいるし、Ｃなんて言語の皮をかぶったアセンブラだというひともいて、そこから中級言語だと言われるんだけど、
Javaはそんなこと言われないからたぶん高級言語。

高級言語より中級言語の方が難しいのは仕方ないんでは・・・

え？Ｃ#？・・・実際に触ってないから知らないな。マシン一台しかないし。

一行目、日本語変だね。
鬱だ・・・追試の勉強しよ。

>>85
C#は、設計者が設計者だしねぇ（藁
まあ俺は好きだけどね。あの人の言語は。

>91
>Ｃ＋＋のソースは見た目が汚い
ヘボイ人が作ったソースでも見たのだろう。

>Ｊａｖａは綺麗で読みやすい。
センスのある人が作ったソースでも見たのだろう。

>>90

>>72参照

>97
さんきゅー。でもこういう構文はないんじゃない？
syntax error がでるよ。、

「Protected Abstract Virtual Base Pure Virtual Private Destructor」

そーすりすときぼーん。

ちょっと質問なんですが、
私、テンプレートとか全然使わないんだけど駄目でしょうか。
その他、多重継承とか多態性とか使わないです。
クラスを上手く組み合わせて全てできてしまうのですが問題ありでしょうか？
あまり必要性を感じないのですが。

>>72
には
>>74　>>76
で反論されてるじゃろ〜

んー。でも思い出してみればＭＦＣみてれば
いくらでもきたないＣ＋＋そーすはあるねー。

もういらないかも。

>>98
それはただの用語でしょ。
「プロテクテッド抽象仮想基底純粋仮想プライベートデストラクタ」
ソース言ったら答え言ってるのと同じじゃん。

>>96
んだんだ。
なんできれいでなんで汚くなるかも書かないと説得力ゼロだな。

でも、Cと地続きにしたのは汚いソースをあふれさせた原因かもな。

>>100
>>74
「プロテクテッド抽象仮想基底純粋仮想プライベートデストラクタ」
みたいな複雑なのがでてくる言語はさすがに限られてると思うぞ。

＞なぜＣ＋＋はあんなに難しいのか？
>難しいという人はソースきぼーん。
>Ｃ＋＋のソースは見た目が汚い
>ヘボイ人が作ったソースでも見たのだろう。

この考えに一票かも。

悪いけど意味不明。>>102

>>106
意味不明なら、君のとってC++は難しいってこと。
分かってないってことだから。

ありがと。見てみるよー。>>107

はいはい。>>108

>>108に一票
ついでに言えば、ソースで見ればそんな難しいものでも無さそう

文化の差はあると思う。
出力引数なんて Java じゃほとんど使わないけど
C++ ではよく使うよね。

C++ で綺麗に書くことはできるけど、
C をひきずってしまうので綺麗に書いてる人は少ない
というのが経験的な感想。
Microsoft のソースが汚いというのも
そういうイメージの原因かと(

>>104
その辺は結局、型付の強い言語で多重継承を認めるとどうなるか、っていう
失敗例といっていいと思う。でも、Java的なimplement interface の方法論を
導入すれば回避できる、というよりもその辺は俺の感覚だとほとんど記憶から
削除されてるし、削除してしまっても何ら問題ないよね。OOPを同時に勉強し
ないでそっちのほうに迷い込んじゃった人はかわいそうだと思うけども。

誰かも言ってたけど、処理系の実装の難しさと実用の難しさをごっちゃにしちゃ
いかんと思うが。

C++ はシステムレベルでも記述できる、非純粋？オブジェクト指向言語なんで、
普通にアプリを書いている人には必要ない（というか危険な）機能がいっぱい。
ポインタが無ければCじゃないが、ポインタは初級者には危険すぎる。

Java がもっと普及すればいいのに。。。。

ポインタも理解できないような奴を
プログラマとは呼びたくないな

とは言ったものの多重継承も
その他のごっちゃごっちゃも
使いたくないんだったら使わなくたっていいんだぜ
72の奴も普通つかわないし

いっぺんに重箱の隅まで覚えようとするから大変なんだよ

>>114
Javaがネィテェブコード吐けりゃ、俺も乗り換えてたよ…

ネィテェブってなによ

>>72
だから、こんな言葉の説明が出来る事とプログラムの本質は関係ないでしょ(藁
プロとして仕事するなら一番求められるのは結果であって、クライアントの
要求するものを提供できれば、どんな言語を使おうが、どんなアルゴリズムを
使おうが、そんな事はどうでもいいこと。

逆にプログラムの本質はそこにあって、OOPの概念は言語とは独立したものなわけ。
たまたまC++では、72の様な用語(一部予約語)で説明されたり記述したりするって
だけの事。やはりJavaでもほとんど同じ様な用語が用いられるし、他のObject
Orientedな言語でもそうでしょう。

だから一度OOPを理解してしまえば、どんな言語でも、この概念を実践するに
あたって、具体的にターゲット言語上ではどの様な方法で実現されているかを
知れば、慣れの問題を除いて、開発言語は問わないわけ。
特に言語体系に用意されていなくても、例えばアセンブラでさえ、独力で
似た様なことは実現可能だしね。

よって、OOPを理解すればC++もJavaも難しくなく、逆に理解していなければ
同様に難解なはず。よって、他のObjectOrientedな高級言語と比較して、
特にC++が「難解」とは言えないとおいらは思いますけどね。

設計は開発言語とは無関係とかよくいわれるけどね。
実際には開発言語や環境を考慮せずに設計したものは
ロクなもんじゃないぜ。

>>118
だからほかの言語に比べて慣れるのが大変ってことなのよ。
慣れてしまえば生産性はオブジェクト指向言語として
他と変わらないと思うけど。

OOPは当然理解していますが
糞C++は難しくて使うの嫌です。

「猫でも...」のコーナー見てるとわかりますが
OOPと全く関係の無いテクニックが山積ですよ。

テクを知らなければソース読めないし
それでわけわからなくなってたら
k仲川あたりに「プログラマの勉強不足」
なんて酷評されるわけでしょ。

慣れの問題とはいえ、その慣れるまでが
腐れC++を使っていて嫌になるのです。
言語仕様がグチャグチャだから覚える事が多すぎる。

生産性低いから。
滅びてくれて結構ですよ。C++

コンパイル遅いしね（藁
変なキャストしても警告でないしね。

C++の難しい理由・・。
C言語をごちゃ混ぜになるから・・。

C++が難しい→ソースみせろ→C++のソースは汚い
→へぼい人が作ったのだろう→ヘボい人がいるのはC++が難しいから→

（ｗ
ごくろうさん。

> よって、OOPを理解すればC++もJavaも難しくなく、
> 逆に理解していなければ 同様に難解なはず。
OOPを理解すれば楽にはなるがC++の場合、templateとゆーもう一つの山がある

あとC使いの俺の場合、「Cでも作れてしまう」とゆー
誘惑を断ち切る必要がある。

> 生産性はオブジェクト指向言語として他と変わらないと思うけど。
templateがないJavaよりは生産性が高いと信じたい．．．。

>>124
テンプレートってそんなに「使える」んですか。
ちょっと齧っただけの俺にとっては何かマクロ言語みたいでつらくて‥

糞みたいなC++をようやくマトモに使わせたいだけの存在。

ANSIに沿わなくてよければ
特に必要ありません。

どうせ覚えるために工数かかるのなら
他の言語を覚えておいたほうがまし。

Templateはコレクションクラスには非常に便利。
でもコレクションクラス以外では使う場面無いんじゃない？

>>125
C++のテンプレートは、言語仕様で定義しているマクロです。
オブジェクト指向的な考え方の上に考えられたものではありません。
例外処理のようにプログラムのあり方を根本的に変えるものではなく、
熟知していないと使いこなせないわりには、罠が多くプログラマの
ストレスを高めていきます。神経質すぎる人は発狂してしまいます。
そして、強烈なアンチC++野郎として生まれ変わるでしょう。恐いですね。

>>126
>他の言語を覚えておいたほうがまし。
C++以外で普及している言語はVB, Delphi, Java, Cなどがありますが。

VB, Delphiはwin以外の環境では無理だし。
(C#ってwin以外の環境でも使えるの？)
Javaは遅いし、いまさらCに戻りたくありません。

>>118
Procedure-Orientedに関しても同じこといわれてたよ。
と言うことは、そう言われていく中でCが定着したように、
これもC++が定着していく過程なのかな。

>>129
あんたが使うプラットホームにあわせて言語も変えろって事。

どうせプラットホームにあわせてライブラリ変えて
そのライブラリの使い勝手は違うのだから

C++標準で済まそうと思うというバカな考えでいるから
生産性が低いまんまなのだよ。

ねえねえ、>>129

あなた何のプログラム書いてるわけ？

実際プログラムなんてかいてなくて
どれをべんきょうしたらいいのかなー
と考えてる初級ﾄﾞｷｭオタなんじゃない？

自分がこれからC++を勉強するにあたって
マルチプラットホームで動作するC++を
覚えた方がいいとか考えてる？

どうせ挫折するから、止めたほうがいいんじゃない（ｗ

>>124

Templateは必須では無いでしょ。使うライブラリがTemplateの固まりなら
覚えなくてはならないかもしれないが、特に習得せねばならないものではない。
要するにマクロだからね。もちろんOOPともあまり関係がない。
同様に、operatorの存在意義も、記述時の利便性が主な目的だと思う。これも
無理に使う必要ナシ。うまく設計しないと、見えないバグが潜む可能性が大きい。
だから、そういうものは無理に使わないこと。

要するに、沢山用意されている機能のうち、自分の使いやすいものだけを使えば
それでいいんじゃないのかな。
C++文法の生き字引とでも呼ばれたいなら別だが(藁

templateをOOPと関係ないって堂々と言う人が多いなあ。
あれは多態のスタティックなやつだと思ったほうが
わかりやすいんじゃがねー。

まあ別にマクロの延長線上のものだと思ってたっていいけど、
そうするとSTLなんか理解しずらいとおもうんじゃがのう。

そのあげく、「STLはOOPと関係ない」とか言われると萎える。

> あんたが使うプラットホームにあわせて言語も変えろって事。
あるプラットホームで開発した物を別のプラットホームに移植するときに
別の言語で移植しろという事でしょうか？
そんなのいやです。

> C++標準で済まそうと思うというバカな考えでいるから
> 生産性が低いまんまなのだよ。
C++標準で済ませられたらそれに越した事がありませんか？
（まぁ全部標準で済ませられませんが）
また、標準でない部分は最小ですまそうと考える事は生産性が低い事でしょうか？
あなたの生産性の定義を教えて下さい。

一応、いままではCで開発していましたが、
Cぐらい移植性・性能が高く、Javaくらいオブジェクト指向のC++が
現在では再有力と私は考えています。
もちろん、その汎用性の為、かなり覚える事が多く、難しいと感じている
ことも認めますが．．．。

ねえねえ、>>132
あなた何のプログラム書いてるわけ？

実際プログラムなんてかいてなくて
C++のべんきょうに挫折してC++って難しいなー
と考えてる低級ﾄﾞｷｭオタなんじゃない？

自分が低級ﾄﾞｷｭオタだからって他人もそうだと考えない方がいいよ。

標準っていうとさ。

*BSD(せめてFreeBSDだけでも),Linux,Windowsで動く
日本語が表示/入力出来てC言語で書かれたGUIツールキットがほしいですね。
何かないかな。

>>135
モナヂラだよ(藁

OOPを理解したと自認している人に聞きたいのですが、多重継承はOOPにとってな
くてはならないものですか？もしなくてもいいならどのような代替策が優れてい
るのですか？

必死だね。ま、ｶﾞﾑﾊﾞｯﾃﾈ

>>138
インターフェースの継承と機能の継承は分けて考えろなんて
いいますね。前者は多重継承があっても良いと。
COM も Java もそういう方針だと思います。
機能の再利用は継承を使わなくても実現できる場合が多いから
無くてもいいということではないでしょうか

必要/不必要という観点より、使った場合の利点/欠点の
バランスが問題かと。

>>140
インターフェースだけ継承して、他の機能は包含でも実現できるやん。

>>134
テンプレート関数はどう説明する？

>>138
Is a関係ではなくて
Has a 関係にして内包してしまえばよい。

多重継承は無くてもいいのではないでしょうか。

>>142
template関数全体のことを言ってるなら、
staticなgeneric。closみたいなやつ。
STLにおける使い方について言ってるなら、
まさにStrategyデザインパターンそのもの。

前者はちょっと屁理屈くさいけど。

144補足
もちろんマクロ的な使い方もするけど、
そう思った方がtemplateの存在意義とか理解しやすいし、
STLとかの意味もわかるよ、といいたいだけだよ。

ふと思ったが、STLの実装は
汚いC++コード（C++はこんなに汚くなる）の
見本みたいなものではないか。

>Has a 関係にして内包してしまえばよい。
徹底すれば多重継承はしなくていいと思いますが
コードがタブることになりませんか？

Javaのインターフェイスもちょっと凝ると混乱するし。俺だけ？（藁

Rubyのmix-inというのは比較的分かりやすいけど、
モジュールというのがクラスとは別個にあってなんか折衷案っぽい
気がする。

どこから継承したかわからなくなるよりいいかも。

>Has a 関係にして内包してしまえばよい。
この論理はそっくりそのまま継承が要らないという論理にもなる。

「継承」にはコードの再利用とインタフェースの継承という側面があり、
１．インターフェイスの多重継承は認めるが、実装の継承は１個のみ(JAVA)
２．インターフェイスの多重継承は認めるが、実装の継承は許さない(COM)
３．インターフェイスの多重継承も実装の多重継承もＯＫ(C++)
４．多重継承はいかなる理由でも禁止(???)

2は極めて中途半端な立場で実装の継承を1つに限りＯＫするのは経験上これ
が一番便利だと判断したからに違いない。

>2は極めて中途半端な立場で実装の継承を1つに
1の間違い…

1です。

ちょっと見ないうちにいろいろな意見が飛び交って参考になります。

早速「憂鬱なプログラマの〜」を購入し
オブジェクト指向＆ＵＭＬを勉強しています。

>この論理はそっくりそのまま継承が要らないという論理にもなる。

実際、継承のない言語で実装する場合はそうなります。

また、実装継承のないCOM、CORBAオブジェクトの場合も、
実装時には包含するかまったく新規に実装することになりますね。

>>151(1)
おおう。
その選択は最高に正しいよ。

templateは今の仕事に欠かせないなぁ。構造的に。
確かに易しい言語ではないが。

>>146
同意
デバグ死にます。
typedef マクリの半分くらいは STL の仕様のせいだと思うけど。

>>146
どのSTLを見たのかは知らんが、まったくそうだな。
つーか、見んなよ。使うだけにしとき。
そして、STLは見せないようにしろ。

>>146
でも技巧の勉強にはなるわな... テンプレートグルを目指す人には良い参考資料だ。

STLの実装が汚い？　なんで？

VC++のやつはかなり厳しいよ。
C++Bのやつは結構きれい。

>>159
見れるなら見たいにゃー。

あのー・・・STLは、その性格上ヘッダファイルに丸々実装かいて
あるんだにょ｡C++使いが知らないと恥ずかしいかもしれないにょ｡

\Program Files\Microsoft Visual Studio\Vc98\Include
にMAPだのVECTORだのってファイルがあると思うにょ。

いい機会だからちょっと見てみたけど、凄いにょ…
嫌がらせみたいなソースだにょ｡

テンプレートライブラリの公開は、ソースの大公開になるので、
仕事でやるなら気をつけてくれにょ｡

昔、ミカ○系提供のテンプレートライブラリに致命的なバグが
有ったことがあったにょ…

継承をつかわないで包含を使う方が良い場合が多いとか。

テンプレートは STL を利用する場合には使えると思うけど、
自分でテンプレートを使うかと言ったら使わない。

個人的にはすべて Object として収納する Java風のコンテナ の方が
わかりやすいとは思います。

>>163
dynamic_cast を躊躇なく使える立場のヒトはいいけどさ。

>>164
おいら、クライアント側でキャストするなんて事はあんまりしないっす｡

コンテナをあるクラスのプライベートメンバにして、アクセスメソッド
書いてラップして使いましょう。（しまえるのも取り出すのも特定の
オブジェクトだけ）クラス階層1っこ増えちゃうけどね。

・・・つうか常識でしょ｡

>>164-165
微妙に話がずれてるなきみたち

>>165
そのラッパの中では static_cast で済ましてるわけね。
・・・まあ、それでいい気もするけど。

>>165
それをプログラム中の配列すべてに対して行うのか？
JAVAやNON-STLではそれが面倒だからどうしても[]を使ってしまう。

多重継承バリバリのソースを解析するのは疲れるんで嫌いです。
はぁ…

>>169
キチンとspecを出させるべき

Ｃ＋＋はできた方がいい？
ほとんどＣでかいてるけど、
Ｃ＋＋の本読んでもクラスとかの便利さってよく分からなかった。

クラスが勝手にデストラクタで壊れてくれるので、ファイルの閉じ忘れ等を防ぐことが出来ます。
一番簡単にいえるのはこれぐらいか・・・。

あとはＣでも出来ないことはないしね・・・。
（ＯＯＰとか)

1さんじゃないけど

クロージャって何？
リファクタリングって何？
委譲って何？Listener ってどう使うのさ？

他にも最近よくわからん用語が多すぎる・・・
オブジェクト指向はパラダイムが違うって言うけど用語もずいぶんわかんない。

クロージャはOOP用語じゃないぞ、別に。

委譲というのはあるオブジェクトが受けたメッセージを別の
オブジェクトに丸投げしてしまうことです。

ってことはMFCのメッセージルーピングマクロなんかは委譲のいい例だな。

元請けが下請けに設計・実装全てを丸投げして
うわまえだけピンはねしている日本のゼネコン体質は
”異常”といいます。

AGE

>>177
class GeneCon {
private:
　Shitauke * sitauke;
　Money uwamae;
public:
　BOOL GetShigoto( Money yen, Task shigoto) {
　　keihi = yen / 10000;
　　uwamae += yen - keihi;
　　shitauke->Shigoto( keihi, shigoto);
　　return True;
　}
　void GetKujyo( Money support_yen, Kujyo kujyo)
　{
　　shitauke->Kujyo( kujyo);
　　uwamae += support_yen;
　}

>>179
class Dokenya {
private:
　Shitauke * sitauke[];
　Money uwamae;
public:
　BOOL GetShigoto( Money yen, Task shigoto) {
　　keihi = yen / 10000;
　　uwamae += yen - keihi;
　　shitauke->Shigoto( keihi, shigoto);
　　return True;
　}
　void GetKujyo( Money support_yen, Kujyo kujyo)
　{
　　shitauke->Kujyo( kujyo);
　　uwamae += support_yen;
  }
};

class GeneCon : public Dokenya {
private:
  Seijika* seijika[];
}

class Shitauke : public Dokenya {
};

age

い・１万分の１・・
孫請けは更に１万分の１・・・
苦情は無償・・・
あ、でも関連づけがされてないから大丈夫だ。

２ちゃんねるはメガネオタクの集まり！！
どうしょうも出来へんな！！
スキルも無いくせに能書きだけは一人前の奴ばっか！！
ほんまにスキルある奴は軽く遊んだるから、かかってこいや！！
アホが！！2ちゃんねるはメガネオタクの集まり！！
メガネ割りたい！！
文句あるなら、かかってこいや！！
アホが！！
http://www.rju666.com/

こいつアホ？>>183
それとも騙りか？

C, C++って
書き方に自由度がありすぎるせいか
ソースコードに個性が出まくって困る。

ある程度制限されていても
みんなのコードが似かよるPascalの方が好き。
DelphiだとOOPきれいに書けるし。

きれいなOOPにはガベコレが必須な気がする今日この頃。

>185
>Delphi
interface と class の名前の prefix が違うのがいや。(TとI)
GC が無いのはとりあえず良いとしてもね・・・。

>>187
？　嫌なら別に俺様流で全部Cにしたら？

DelphiでBoehm GC使えるかな。

Delphiで無理にGC使わなくても interface使えばいいんじゃないの？

>188
"Delphi" だったら付属ライブラリがそういう規約だから、
自分流でいくとごっちゃになるからイヤ、と思っている。
interface と class をわざわざ分ける必要が無いと思うんだけれどなー。

それよりも、最近 interface がどうしても必要になることが無いことに気が付いた。
(全部 single inheritance で済んでいるんだよなー。< Java)

>189
delphi 用の gc を探していて、今まで確保したメモリを全部クリアする
gc があった。役にたたねー。

>190
一瞬何を言っているのか理解できなかった。
TInterfacedObject を使え、ってことでしょ？
メモリ管理が面倒なだけだったらそれでも良いけれれど、
参照カウンタを利用しているから、
結構オーバーヘッドがあるのでダメです。

ネイティブでガベコレ是非ほしいよ。
C++でもDelphiでも
リファレンスカウンタを持ったクラスと
その使い方、破棄の仕方を教えてほしいな。

>192
参照カウンタの基礎はoperator=のオーバーロードじゃない？

>192
Delphi Tech
http://piza.2ch.net/test/read.cgi?bbs=tech&key=970606624
上のあたりに参照カウンタを利用した複素数クラスがある。

サンクユウ。
Techスレ、先頭から見たことなかったよ。（ｗ、
今後ともよろしゅうに。

・・・DelphiTechスレ、の先頭の方、まじでレヴェル高すぎ。
ｵﾚTechに投稿するの控えるよ。、ウツシ....

>>132の文章に女性の匂いを感じたのは俺だけでしょうか？

>>197
だから何？
お前は女を見たことが無いのか？

俺はC++よりもJavaの方が難しいけどなあ。
テンプレートつかえねーからコレクションクラス使うとキャストの
嵐になるしさ。きたねーったらありゃしねえ。クラスライブラリは
どでかくて把握できねえし。

>>197
男の小説家があーいう文章(?)を書けなければ、
その小説家の小説は男キャラだけになってしまうと思うが？

>>196
俺もはじめて見た。びびった。
というか、ますます燃える(笑)

>>187
interfaceのprefixはマイクロソフトのやり方に従っているのでは？
あとclassとinterfaceでは、意味が全然違うのでprefixを分けた方が
良いと思う。

>>189
どうなのかなあ。できるといいなぁBoehmGC。
ところでガベコレされるときにdestroyを呼んでもらうための
Boehm側の仕掛け(の説明英文(笑))が理解できません(T_T)。
誰か教えてください(T_T)

>>192
ガベコレの方式は参照カウンタだけじゃないよね。
BoehmはMark&Sweapとやらだったっけか。
参照カウンタのほうがヨイという意思表示(^^;でしょうか？
俺も「どっちがよい」と言えるわけじゃないけど、
循環参照こわいんで他の方式のほうが安心…。

>>199
そういやGenericJavaはどうなったんでしょうか？
軽量(笑)テンプレートを搭載するとかいう話。

優れているうんぬんではなくて
普及してるから使うってのが正しい考えでは。
VHSみたいに

C++はフェラーリ。
Javaはインプレッサ。
ＶＢはカローラ。
COBOLは２トントラック
Fortranは初代クラウン
Smalltalkはトヨタ２０００ＧＴ
Perlはファミリア
Rubyはアルテッツァ
アセンブラは徒歩

>201
>あとclassとinterfaceでは、意味が全然違うのでprefixを分けた方が
意味が違うとは、たとえばどのあたり？
僕は、すべて仮想メソッドな class みたいなものとして捕らえているから
同じに見えるのだけれど･･･。

Javaはパフォーマンスをまったく無視して、
ドキュソプログラマにも扱えるようにした言語。
あんなものがネイティブで動いてもパフォーマンスが出るわけがない。
いくら言語仕様が美しくても、できるのがウンコソフトなら意味がない。

だいたいC++やアセンブラすら解らないような奴が、プログラム組むな。

>>206
VBのみ触れたことのある一流VBプログラマですが何か？

>>207
サブッ

>>206
激しく同意。

ガベコレは便利だけど、実行効率を全く無視しているし、
安全性は結構だけど実行のたびにべリファイかけて
全パターンを検証するから起動が異常に遅かったり、
RunAnywareは結構だけど、実際はDebugAnywareだし。
仮想関数は便利だけど、それがメソッドコールの
パフォーマンスにどれだけ影響するか無視してるし。

とにかく糞。ほんとサーブレットぐらいにしか利用価値がない。

ここC++のスレですよね･･･。

まあ、話題が尽きないのはいいことでしょ。

>>209
GC はともかく、関数の仮想化によるペナルティは

1. クラスごとに一つ仮想関数のテーブルを保持
2. 呼び出しに際して、一回余分にデレファレンスが必要

だけですよね。

性能差は空の関数呼び出しでも最大 20% 程度、実際に関数内で
処理を行う場合には誤差に過ぎないと思いますが、それほど性能
に悪影響が出ますか？　もし実測値などあるようでしたら、示し
てもらえると嬉しいです。

彼らはC++に固執しているのです。
怖いんですよ。

>>212
小さいクラスほど問題が大きくなる。
たとえばテーブルのセルクラスとかがいちいち関数テーブルを持って
いて仮想関数呼び出しが発生するのははっきり言ってむかつく。
俺のところでは50カラム2000行のすべてのセルの色を変更しようとす
ると5MBくらい食うのでGCが発生して10秒くらいかかる。

そういう場合ってとりあえず違う形で保持しません？
セルオブジェクトを大量に生成・保持している時点で終わり･･･。

設計が悪いだけな気がするのは気の性でしょうか

>>212
Javaはデフォルトが仮想関数だからねぇ。
private final属性にするとか気をつけて組めば、
それほど深刻ということもないけど、
バイトコードレベルの知識のない大多数の似非Javaプログラマが
使い分けを意識しているとは思えないなぁ。
バイトコードレベルのインライン展開も明示できないし、
ループの内側で仮想関数をコールしている可能性は否定できないかも。

あと通常、仮想関数コールは２回余分にメモリ参照が必要だよ。
仮想関数テーブル->関数ポインタ->コールだからね。
さらにインターフェイスメソッドのコールは
インタフェイステーブル->仮想関数テーブル->関数ポインタ->コールだから
３回余分に参照が必要だよ。

それから、これはJITコンパイラが賢い場合の話で、
さらにコンスタントプール参照が入る可能性も否定できない。

>217
良くも悪くも
Javaでプログラミングをしている時点で仮想関数のコストを気にするのもどうかと。

あ、セルクラスっていってもセルスタイルクラスね。
現実問題としていちいちnewするしかないと思うけど？

同社のC++ライブラリも使用経験あるんだけど､その場合は1Mくらいだった。
もちろんオペレーターnewも書き換えてあった。

C++の参照(&)って必要なのですか?

>220
大量にセルのデータ（スタイル）を保持するなら、
とりあえず配列か何かで保持してメモリを稼ぐ。
で値を返すときに(newのコストがかかるけれど)毎回 newして返すか、
セルへの参照をもらってそいつの値を変えてやるとか。

ところでメモリの使用量ってどーやって調べたの？

>>221
参照なんかなくてもポインタで十分じゃないか、って話？

参照とポインタの最大の違いは、ポインタが NULL を許容するのに対して
参照は必ず実体を指していること。参照を使うと、いちいち NULL かどう
かチェックしなくて良いことが、言語レベルで保証されるのが便利。

逆に NULL (何も指していない）状態を表現する必要があるなら、参照で
はなくポインタを使うべし……と Effective C++ か何かに書いてあった
ような気がする。

>>220
メモリの使用量はオペレーションをする前と直後のJAVA.exeのメモリ使用量から
前半部分はよくわからない。
俺が言いたいのは一個数バイトですむようなクラスの場合､vtbl(ポインタ)を
保持するのは無視できないパフォーマンス低下を招くと言うこと。
まあJAVAの場合問題はvtblだけじゃないと思うけど。

>>221
少なくとも演算子のオーバーロードには必要だわな。
それ以外で使ってるのはほとんど見たことない。

>>215 >>216
言語仕様に気を使ってプログラム組むのなら最初からC++を使ったほうがマシ。
CやC++はマシンアーキテクチャとその動作を想定しながら書く言語だが、
JavaがVMの動作を想定してどうする？
高速なVM用と低速なVM用とか分けて書き出したら、Javaのメリットはなくなる。

つうかJavaは構造体が無いのが痛い。
可読性とパフォーマンスやメモリ効率を両立できない。

>224
セルオブジェクトのフィールドごとに配列を用意してやる、ってこと。
boolean[] isBold;
int[] fontSize;
...
みたいに。するとメモリをかなり稼げると思う。
で、newするとか参照がどうしたってのはこいつの値の返し方のこと。

>224
>メモリの使用量はオペレーションをする前と直後のJAVA.exeのメモリ使用量から
たいていのJVMは一度に大量のメモリをOSから確保するのでそれはあてにならないと思うよ。
どちらにしろJavaはメモリ食いだが。

>223,225
どうもありがとう
演算子のオーバーロードというと、<<
シフトだけど
ほとんどのC++の解説書が　cout << ....
については、何の説明も無しに使ってますね。
良くないとおもう。

>>223
*pを実体で渡して、pがNULLだったらおしまいさ。

>>225
参照渡しするよ。よくしないでＣ＋＋プログラム書けるね〜

>>221

１：コピーコンストラクタを作るのに必要

CFoo::CFoo(CFoo x) というコピーコンストラクタを定義するとする。
コピーコンストラクタを呼び出すときに、さらにコピーが発生するので、
永久にコピーコンストラクタが呼び出され続けて暴走する。
従って CFoo::CFoo(CFoo &x) でなければならない。

なお CFoo::CFoo(CFoo *x) はオブジェクトのコピー時には
呼び出されないのであしからず。

２：代入演算子（operator=）を作るのに必要。

１と同じ理由。
コピーコンストラクタと代入演算子は、基本的に全てのクラスに書いてくれ。
各必要がないときだけ、意図的に省くように。
理由は Effective C++ 参照。

３：例外をcatchするのに必要。

throw をコピーで catch すると、例外オブジェクトのコピーコンストラクタ内で
さらに例外が発生してややこしくなる。
ポインタで catch すると、開放されたゴミメモリをポイントすることになる。
例外ハンドラは参照で catch しないといけない。

>>232
こういう話を聞くたびに、delphiを思い出すんだよね。
C++でいう参照が無いのに、別に困っていない言語。
＃delphi以外の多くの言語でもソウだけど。

delphiとかに言わせれば、

1:コピーコンストラクタなんざ要らない。

2:代入演算子なんざ要らない。

1と2の理由は要するに、変数埋めこみObjectを許していないために
変数の宣言と「同時に」Objectが作られるという抱き合わせ(笑)を
食らわずに済むから、です。

3:newで作った例外Objectをcatch部で受けとって始末すればよい。
たしかC++って未だに(笑)例外専用クラスって無いんでしたよね。
＃つーか大元の基本クラスすらないんだっけか
となると、言語レベルで例外Objectの扱いにお約束を与えることも
できないわけで、それが面倒をもたらしている。

C++って、ある一部に拘ってしまったばっかりに、
他の全ての利便性を獲得できなくなってしまった
という風に思える。

>>229
1000行だとちゃんと2Mくらい増えるから当てになると思う。

>boolean[] isBold
2000行だったら無条件にboolean isBold[2000]ってするのか？
デフォルトではすべてのセルは同じセルスタイルオブジェクトを共有して
いるからそんなにメモリを食わないのだけど､配列になんかしたら常にメ
モリ食いになっちゃうじゃん。
第一isBoldとかはビットフラグだと思う。

>>233
>1と2の理由は要するに、変数埋めこみObjectを許していないために
>変数の宣言と「同時に」Objectが作られるという抱き合わせ(笑)を

デルの事は知らないけど､変数埋め込みがあろうがなかろうが宣言と
ともにnewが呼ばれるなら抱き合わせは発生するんじゃないの？

で、変数の宣言とともにnewが呼ばれることには非常に意味があると思う。
なぜなら変数の文法的スコープとともにデストラクタを呼べるから。

事前に言葉が抜けてるよ。
「独自仕様で勝手に拡張可能なら」代入演算子は要らないだろうな。
「過去の資産が不用なら」コピーコンストラクタは要らないだろうな。

C++は、普及のために多目的・標準化・資産継承・効率を選んだ言語だからね。
独自拡張で安易に組み込み型を増やした方が、特定目的のためなら使いやすいし、
特定環境でなら便利に使えるさ。

String型なんて無いからね。
代入したくもなるさ。

Complex型なんて無いからね。
足したくもなるさ。

え、特定OSで特定目的しか考えてないからComplexなんて要らないって？
そうだろうな。普通はFORTRAN資産の置き換えなんて考えないだろうな。
なら、Variant型なんて無いからね。
COMを呼びたくもなるさ。

てか、オブジェクトの複製をキチンと言語レベルで考慮してるのが
Ｃ＋＋。
ポインタはないとか大々的に宣伝してるクセに、Stringを==で比較
するとポインタの概念無しには説明不可能な挙動をする某Java
みたいなクソ言語とは違う。
なんでStringクラスだけ＋演算子が使えるんだよ。汚ねえ言語だ。
反吐がでるぜ。

StringBufferも使えるぞ。ゴルァ。

どうしてStringとStringBufferが別になってるの？
ださいんだけど。

>239
Stringがimmutableな方が便利だからじゃない？

>デルの事は知らないけど､変数埋め込みがあろうがなかろうが宣言と
>ともにnewが呼ばれるなら抱き合わせは発生するんじゃないの？

デルでは宣言と共にnewは呼ばれないっす。
Javaからガベコレをとったようなもんです。

>「過去の資産が不用なら」コピーコンストラクタは要らないだろうな。

なんのこと？
あぁ。もしかして「C/C++の」過去の資産のこと？

Cの資産ならわざわざ請け負う奴が悪いとしか言いようが無い(笑)し、
＃てゆーか我こそが継承者っていうでかい顔。
＃C似のゲンゴなんか一杯あるのに。
そもそもCとはまた微妙に違うでしょOOPは。
同一性を重んじる必要があるかどうか？で
構造体とObjectは違う…のだけど
そこをわざわざ端折って混同してしまったのがC++。

C++のなら、それは単にC++の自慰だ。
いや、そりゃユーザーはいるのかも知らんが。＃それじゃVBと同じ論法だ。

>特定OSで特定目的しか考えてないからComplexなんて要らないって？

関係ないなあ。
とりあえずデルについて言えば、言語仕様そのものには
別に環境依存な部分なんか無いもん。
＃Kylixも出たし、という話もあるわけで。

>C++は、普及のために多目的・標準化・資産継承・効率を選んだ言語だからね。
>独自拡張で安易に組み込み型を増やした方が

それって矛盾してない？
標準化するならStringクラス(のInterface)を与えてくれても
良さそうなもんでしょ。
効率という旗印と標準化という旗印の間で
おろおろしちゃってる面が、あると思うぞC++には。
そういう意味では、重たくて困るが、Javaの
なんでも与えちゃうアプローチだって
十分認められるものだろうし。

>Stringクラスだけ＋演算子が使えるんだよ。汚ねえ言語

無節操に増やせるゲンゴもどうかと思うが。
演算子なんて手ぇつけないほうが幸せだよ。
なまじさらりと読みやすいんで、勘違いを招きやすい。
関数形式で書いとけ。

>変数の文法的スコープとともにデストラクタを呼べる

そんなに役立つと感じないんだよな、あれ。
まぁたまには役立つと思えるのかも知れないが、
Scopeに従属した寿命をもつObjectがそんなに多いのか？という
根源的疑問が。
＃以前Niftyで「スタック指向」とかいうドキュな考えを
＃ぶちあげていた奴がいたっけな。
＃ObjectをできるだけStackに積むように設計するんだってさ(笑)。

ということで、
Javaはポインタすら理解できないアホ向けに作られた言語ということで
よろしいですか？

C++マンセー

>とりあえずデルについて言えば、言語仕様そのものには
>別に環境依存な部分なんか無いもん。
>＃Kylixも出たし、という話もあるわけで。

おまえ、何にも知らないんだな。
エラそうな口たたく前にちゃんと仕様書読みな。タコ。

>ちゃんと仕様書読みな

は？ナニの？デルの？
C++のじゃないよな？この文脈だと。

>242
ポインタすら理解できないアホを
ポインタの道にはめる罠、じゃなくて？
＃いや、ポインタそのものは勿論良いものなんだが。

>Scopeに従属した寿命をもつObjectがそんなに多いのか？という
>根源的疑問が。
ほとんどの変数はスコープに従属してると思うぞ。

＃以前Niftyで「スタック指向」とかいうドキュな考えを
＃ぶちあげていた奴がいたっけな。
＃ObjectをできるだけStackに積むように設計するんだってさ(笑)。
俺はそうやって組んでる。newなんて一回も使わないことだってある。
Ｃ＋＋の話な

Forth系もスタック指向
こちらは定義そのものもスタックに積まれる。
領域が連続する利点はデカイよ。
気にするのはスタックのオーバーフローのみ。

>>241

>標準化するならStringクラス(のInterface)を与えてくれても
>良さそうなもんでしょ。

C++標準にstringはあるが……。
俺なんか外してる？

>>241
C++ でも class と struct を、それぞれ参照指向・値指向で使い分
けてれば幸せだったかも、と思うことはあるね。

しかし C++ の言語の成長過程を見てると、いきなり string を突っ
込むのは無理だったろうし、class と struct を同じセマンティクス
にしたからこそ、早期に C++ コンパイラの実装が出てきて、普及の目
処がたったというのも確か。

当時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。

おーい、デル厨よー、こんな所で吼えてないで
DelphiでOSを作ろう！
DelphiでCGI向けスクリプト言語を作ろう！
Delphiを組み込み分野に浸透させよう！
DelphiでJVM,CLRを作ろう！
運動でもしたら？

俺、Delphiは好きだけど、ﾃﾞﾙ厨は大嫌い。

>>245
newを一度も使わないことがあるぅ？
それ痛すぎ。オブジェクト指向をちょっと勉強したら？

>251
あなたの方が痛いようなきがする・・・・。

(笑)と#ばかり使う奴、他スレまで出張してうざすぎ(ﾜﾗ

>>252
オブジェクト指向とはnewを使うことと見つけたり

>>251だった。逝ってくる。

age

ここの住人はどこ逝った?age

ここにいるぞ。

>>251
きっとあなたはJAVAしか触ったことがないのでしょう。
そしてオブジェクト指向とデザインパターンを修得した気になって
それを知らない厨房をこき下ろす快感のためにネットを徘徊している
のでしょう。
でもかわいそうに､OOPやデザインパターンを知らないのが厨房の証である時
代はとうの昔に過ぎ去ったのです。いまや誰でもOOPやデザパタを知っていて
不注意にこの言葉を使うとすぐに厨房であることがばれます。

まあ学生ならしょうがない面もありますが､将来この道で食っていこうと思って
るのならもうちっと勉強されたし。

教えてください。
Ｃ＋＋言語の設計コンセプト、設計思想ってどんなものなんですか？

混沌

デザインパターンは小技集だよ。
まずはオブジェクト指向をキッチリ覚える事の方が大事だと思う。
もともとデザパタなんて覚えなくてもいいようにできたものだと思ってたんだけどな。
どうもプログラマってマニュアル化が好きだよね。

>262
>どうもプログラマってマニュアル化が好きだよね。
当然だろ。

>>263
基本的にオブジェクト指向をしっかりと理解できていれば
デザインパターンなんて本なくてもあんなのはすぐに思い浮かぶねん。
逆に設計のレパートリーがあれしかないとかいったらそれは
使えないやつだと思うのだが。また、今後デザインパターンが増えるたびに
アレを敬愛するやつはその都度暗記していくのだろうか？
オブジェクト指向が理解できないやつってなんでもかんでも
覚えようとする傾向があると思う。「デザインパターンって本が
いいよ」いいよって聞いて読んで見たら「？」って感じだった。
あれは今更だよな。

デザインパターンは他のプログラマとの意思疎通に役立つんじゃないのか？

>>264
そんな人っているのかぁ。
でもあなたと仕事するのもつらそうね。
あれはコミュニケーションのための道具と理解してちょーだい。

>>265-266
だからそれじゃＣ言語の時の構造化なんたらのときとまるで
変わらないじゃん。あのときも色々と出たよね（笑）（色々とね）
また色んな流派を作って破綻させるか？
結局他のプログラマが知らなかったらそれでおしまい程度の
トンでも本のような気がするなぁ。
実際、オブジェクト指向で組んでるうちにアレの存在理由も
かすれてくるでしょ。

>>267
PLoPにいって皆説得しておいで。

>>264
今ごろGamma本詠んでてそのせりふはないだろ。

>>269
遅い？（藁
すまん逝ってくる。

>実際、オブジェクト指向で組んでるうちにアレの存在理由も
>かすれてくるでしょ。

あの本の存在理由が薄くなる時代はすぐくるんじゃないかな。
なんか、あたりまえよ、って皆が思うようになるものだし、
Gammaらのねらいもそこらへんにありそうだし。

>>270
にーちゃん、学生とかにはあの本結構いいんだよ。実際USの大学
は結構つかってっぞ。なかなか0から思いつく人間もいないから、
先人の足跡は見せとくのがいいんだ。

>>259
　あー？　なんだ？　主語が欠落しすぎて何いってんだかよくわからん。
かわいそうなのは誰だ？　この言葉とはなんだ？　ちゃんとした日本語
書いてくれ。
　ってか、OOPって言葉、かなり懐かしいぞ（ｗ

>>272
懐かしすぎて憶えてもいないか? (w

>>272
　そら言えるな。オブジェクト指向は分析設計に価値がある
ってことがとっくの昔に一般的になった昨今、OOPなんて
言葉を使うと素人だと思われるからね。ってか、この言葉は
素人判別用語だな。
　OOAとかOODってのすら最近聞かないよな。

>>274
またプログラミングの重要性に気づいて
一周してきた気がするけど。ここ1,2年ってそんな感じしない？

2ちゃんで求めちゃいけないのかもしれないけど、
もちっと建設的にいこうや

>>274
教えてください。
玄人判別用語はなんですか？

今日はエンジェリックレイヤーがやるから後でな。

>>275 一周してきたというのは、最近の XPブームのことを指してますか？
XP: 使うかどうか判らない部分までねちねち設計せずに、
さっさと必要部分「だけ」コード書いて、
まずけりゃ後からちゃちゃっと直そうぜ。

>>277
みさきち萌え〜。

なんかPGにアニオタ多くない？

>ほとんどの変数はスコープに従属してると思うぞ。

おーい。変数じゃなくてObjectっすよ。
ObjectはScopeに従属してるたぁ限らないだろ？
＃そしてObjectは変数だけを束縛してるわけじゃないだろ？
＃配列の要素とかさ。

もし変数とObjectを分けて考えられないとしたら
前述のStack指向(の間違えている部分)に嵌っている人
ということになる。

>Forth系もスタック指向

Forthは知らぬが、PostScriptなら、
Stackと辞書(原始的な変数管理物みたいなものであり、
これでヒープ(?)にとったObject(?)も管理できる)とを
両輪として使い分けるものだな。
Stackだけで頑張るのは不健全でし。
最適化の一環としてStackにおくものを増やすことは有るけど。
ちなみにPSの変数は参照です(^^;。Forthは違うのかな？

>>249
なに言ってんだ？
delphiとまるっきり同じObjectモデルを採る言語が
他にない(俺が知らない)ので名を挙げてるだけだが？
Javaはかなり似ているがGCの有無とかの違いが有るし。

>>253
今更なんだぁ？既にあちこちに出現してるが(笑)

>>259
でもnew(C++で言うところの)をメインに使わないと
結局OOPとしては半端な代物になるぜ。
同一と同値を区別しない世界にどんどん突入するからな。

そういう意味では>>248の意見に賛成。
classとstructをほぼ同じものとしてしまったC++の仕様は無意味に痛いし、
C#(boxingとかいうんだっけ。いざというときに変数埋めこみを使えるっていう)
に良くも悪くも期待するってのは言えてる。
尤もwinでないと使えないのなら困るが。

>>280
>おーい。変数じゃなくてObjectっすよ。
>ObjectはScopeに従属してるたぁ限らないだろ？
もちろんObjectの意味で使った。でもあなたの最初の意見は
>Scopeに従属した寿命をもつObjectがそんなに多いのか?
でしょ？なぜ「従属してるたぁ限らないだろ」になってしまうのだ？
もちろん従属するとは限らないし､必要とあらば(Objectの寿命が不確定なら)new使うよ。

>同一と同値を区別しない世界にどんどん突入するからな。
まったくわからん。
　　CGiko *pG = new CGiko();
　　funcMona(pG);
　　delete pG;
が
　　CGiko g;
　　funcMona(&g);
になるだけなのだが。

４月後半から、この板全体がうざいね。
仕切りたがり、自己主張の押し付け、他方を貶める発言。

このスレに登場したきっかけが、
参照は何故必要か？
→コピーコンストラクタと代入演算子に必要
だけなのに、
わけわかんないこと言い出してかきまわしてるだけだもんな。

コピーコンストラクタはいらない、とか、
Cの後継はC++が勝手に主張しているだけだ、とか、
たった２，３のOSで特定のOSではない、とか。

言語仕様の話に限定しようとしても
クラスライブラリがカバー、とか、
IDEの補完機能が、とか、
言い出すんだろ。

280の言う
>そういう意味では>>248の意見に賛成。
って、
>時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
>あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。
の最後の１４文字だけなのか。
前半部分には賛成してないんだろうな。
そのものずばりの言動をしているんだから。

そもそも言語仕様に限定する意味がわからないなぁ。
クラスライブラリーやIDEも考慮されての仕様だろ。

>>280

>でもnew(C++で言うところの)をメインに使わないと
>結局OOPとしては半端な代物になるぜ。

C++ は純粋なオブジェクト指向プログラミング言語（＝オブジェクト指向
じゃないとプログラムを書けない言語）ではないので、私はそのプログラ
ミングスタイルでも良いと思うよ。

デザパタ本でも言われてる「インターフェースに対してプログラミングすべ
し」という教義で解釈すれば、仮想関数を使いようがない値指向のクラスは
確かにクズな仕様。

しかし C++ の class はオブジェクト指向のクラスだけではなくて、従来
の C 言語で使われてきた実装の隠蔽方法（多態は関係なしに、単に実装を
隠すだけ。fopen(), fclose() みたく、関数へのポインタだけ外に出すよ
うな方法の延長）を効率的に支援することも意図している。

こちらの用途では、クラスは値指向で、その生成と破棄もスコープに縛られ
ていた方が都合が良い。Java みたくオブジェクトの解放タイミングを GC
まかせにすると

CFile file("filename.txt");
..
// ここで file オブジェクトが破棄されるので、自動的にファイル記述子も
// 解放される

とか書けなくなるし。

多様なプログラミングスタイルを効率的にサポートする、言語使用の美しさよ
りも実用性というのが C++ の思想なんだから、それに目を瞑って C++ の言
語仕様を批判しても意味がない。

>>285
誤：fopen(), fclose() みたく、関数へのポインタだけ外に出す
正：fopen(), fclose() みたく、構造体へのポインタだけ外に出す

>>282
　主語が欠落しすぎて何いってんだかわからないなあ。

fj.comp.lang.cみてーなつまんねー突っ込みだな
fjﾆｶｴﾚ

>>285
「みたく」ってなに？おいしいの？

ごたくの入門版

>>281
> >Scopeに従属した寿命をもつObjectがそんなに多いのか?
>でしょ？なぜ「従属してるたぁ限らないだろ」になってしまうのだ？

なぜって？なんか変か？
1行目と2行目はつまり「同じ主張(の繰り返し)」なのだが？

>必要とあらば(Objectの寿命が不確定なら)new使うよ。 │

当然そりゃそうだが、一方で埋め込みなObjectって
存在価値がかなり薄いと思われるわけよ。

というか変数のScopeとObjectの寿命を同期させたいなら
別に埋め込みにする必要があるわけじゃなく、
たとえばauto_ptrみたいなものを最初から言語機能として、
用意すりゃ良かったろうに…と思う。
少なくとも「同期させたいから埋め込みを使う」っていう論は変。

> >同一と同値を区別しない世界にどんどん突入するからな。
>になるだけなのだが。

そりゃそうだが、それは最初の一歩でしょ。

>>282
>このスレに登場したきっかけが、

きっかけだけでゴールまで決めつけないでよね。

>たった２，３のOSで特定のOSではない、とか。

実装がそれしかないってのが、なんか関係あるのか？
同じ仕様の別実装を作ればいいだけだろ？
FreePascalがどれだけやってるんだかは
不勉強なんで知らぬが。

＃javaでRunAnywhereとかいうよりは、負荷が少ないと思うが。

>言語仕様の話に限定しようとしても
>クラスライブラリがカバー、とか、

話題によるね。 C++にルートクラスが無いのは痛い
(=おかげで色んな場面で面倒が生じる)と思うんで。
つまり、ライブラリと言語仕様の線引きは
一意に決まるとは限らない。

つーか>>284みたいに逆の意見もあるようだし(^^;

>>283
> >時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
> >あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。
>の最後の１４文字だけなのか。

その通りだ。それがなにか？なんで意味が無いといえる？
(C++を)使うのは今のおれたちなんだぜ。
ここは骨董マシン＆OSで(骨董言語を(笑))動かす人のスレってわけじゃ
ないんだろ？
ならば今の視点で我慢ならん点を挙げるのがおかしいわけない。

まして「簡単」かどうかはどうでもいいことだ。

>>285
>私はそのプログラミングスタイルでも良いと思うよ。

まぁ最終的にはそうなんですけどね…。

>隠すだけ。fopen(), fclose() みたく、関数へのポインタだけ外に出すよ
>うな方法の延長）を効率的に支援することも意図している。

で、その話をしようとすると、structとclassを
ほぼ同じモノだとしてしまう必然があったのかとか
＃それこそC#か…
いう話になるわけですよね。

>Java みたくオブジェクトの解放タイミングを GC まかせにすると

でですね、参照ベースだけどGCにも頼らないという言語の一例として
delphi辺りを挙げる(のが無難だし単に自分が知ってるし)、という。

C++からdelphiに移行して、なるほどこんな(楽な)手があったんだなと
感心したわけですよ。

で、単に参照ベースにするだけじゃ駄目でして、
たとえばデストラクタ(のInterface)をバイナリレベルで共通化
できていないと、統一されたObject(の消去)の管理なんて出来ないので、
するとルートクラスは結局必要だ、だとか、
芋づる式に色々出てくるわけですよ、C++方式から「どんどん」離れていく理由が。

で、随分違う所に来てしまってふと後ろ(?)を振り返ると、
今までなんであんなところに居る「必要」があったのか？と
首をかしげるばかりなんですよ。

>// ここで file オブジェクトが破棄されるので、自動的にファイル記述子も
>// 解放される
>とか書けなくなるし。

とりあえずはauto_ptrでも書けますよね。

あ。そういや昔のTransTECH(99年12月)を開いたら
operator->*をいじることで楽になろうという話が
載っているなあ。読んでみます。C++を批判する理由が
減るならそれに越したことは無いんで。

まぁ、たこのようにナンデモ有りな言語仕様なんで
自分で好きな形に整形(限定)したうえで使う、
という手は使えます(けど)ね。C++は。

>>291
>Scopeに従属した寿命をもつObjectがそんなに多いのか?
だと「ほとんどのものは従属してない」と読める。
>従属してるたぁ限らないだろ
だと「ほとんどのものは従属してるけどそうじゃないものもある」と読める。
で俺の主張は「ほとんどの(80%位か)Objectの寿命はスコープに従属している」
だけどこれに異論はあるの？
#ほとんどっていうのは実際にインスタンス化される回数ではなくてプログラ
#ムに表れる回数ね。

>たとえばauto_ptrみたいなものを最初から言語機能として、
だからauto変数こそ言語機能が用意してくれたauto_ptrなのだが。

なんか埋め込みと言う言葉を多用しているけどもしかしてメンバオブジェ
クトのことしか考えてないんじゃない？
オブジェクトの多くは関数ローカルなものでしょ。

それともオブジェクト同士が複雑に絡み合ってメッセージを投げ合って
いるようなものを想定してるのか？（シミュレーションとか）
モデル化する対象がそういうものならそう実装するしかないけど、おいら
がやってる仕事はもっと単純なものばっかなんで。
でもそっちのほうがメジャー。

C++ほど強力な武器はないよ(アセにはかなわないが).
C++を一通りやってからほかの環境で作業してみると、
あれがない、この機能がないと不満が出てしまう....

仕事でPHPとかで書いていてもなぜか気が付くと
オブジェクトがたくさんできあがっている.
もう、オブジェクトなしでは生きていけない体になってしまったようだ.

Rubyちゃんにでも手を出してみるか.

>>従属してるたぁ限らないだろ
>だと「ほとんどのものは従属してるけどそうじゃないものもある」と読める。

なぜ？多いとか(少ないとか)は一言も書いてないぞ？
ちなむと、

>「ほとんどの(80%位か)Objectの寿命はスコープに従属している」
(中略)
>オブジェクトの多くは関数ローカルなものでしょ。

異論あり。あなたのソースはそうなんでしょうけどね。

>#ほとんどっていうのは実際にインスタンス化される回数ではなくてプログラ
>#ムに表れる回数ね。

うーん。その数え方がすでに、Objectと変数の混同の
一歩手前ってかんじなんですけど…

>だからauto変数こそ言語機能が用意してくれたauto_ptr

ん？auto_ptrって、所有権を他のauto_ptr変数に
移すことができるでしょ？
一方で生のauto変数には出来ないっしょ？
そこが重大な差なんだけども。こっちのScopeから
Objectを救出(笑)したいと思ったらauto_ptrなら出来る。

>オブジェクト同士が複雑に絡み合ってメッセージを投げ合って

そこまで大げさ(?)に言わずとも、たとえば
ふつーのGUIアプリを作るときなんかも、
窓とコンポーネントがCompositeパターンを成すわけじゃん。
ローカル変数なObjectばっかりだと、それもうまく表現できないよ。
ああ。コンポーネントの数が最初から最後まで変わらないアプリなら
ローカル変数でも済むかも知れないけど、
逆にいえばnewを使うのが当然になると、コンポの数を
動的に変えるようなアプリを作ることの「障壁」が減る
感じがする。

>>296
Objectとそれ以外の有りがたみの「比率」を知る
(答えは人によって色々だろうけど)には、
rubyみたいな純粋っぽいOOP言語も触って
対比してみると良いっすよ。

>>297
>異論あり。あなたのソースはそうなんでしょうけどね。
まあここが決定的な差なんだろう。あなたのソースではそうなんだね。

>ん？auto_ptrって、所有権を他のauto_ptr変数に
>…
>Objectを救出(笑)したいと思ったらauto_ptrなら出来る。
それってスマートポインタ？俺の中では
リファレンスカウント付きポインタ->スマートポインタ
スコープ脱出後自動消滅->auto_ptr
だった。（用語の正確さには確信無し）

>ローカル変数なObjectばっかりだと、それもうまく表現できないよ。
あたりまえだ。最初からいってるように寿命が不確定なものはnewするよ。
おれはnewなしでどんな物でも作るって言ってるわけじゃない。
逆に聞きたいけどあなたは関数ローカルなObjectを一切使わないのか？
もし使うならそれはauto変数の出番だろ。

sageぐらい覚えてほしいよな。

こっちは煽りレス
>#ほとんどっていうのは実際にインスタンス化される回数ではなくてプログラ
>#ムに表れる回数ね。
>うーん。その数え方がすでに、Objectと変数の混同の
>一歩手前ってかんじなんですけど…
アホか？インスタンス化される回数で数えたらループの中で100万回生成される
オブジェクトが一番になっちゃうだろ？
いまは実行時の効率の話をしてるわけじゃなくてコーディング時の話しなんだから
実際にインスタンス化される回数が一回だろうが、100万回だろうが、ソースコード
に現れる回数が重要だろ？違う？

まあ、C++が汚くて他の言語の方が優れてるなんて事は、
(この板にいる)ほとんどの人は知っているのさ。
それを今更声を大にして叫ぶ奴がいるなんて思わなかったな。

美しい言語仕様と華麗な実装が好きなら、
C++などに目を向けないほうがいいだろう。
趣味や研究なら、それでいい。
それに、数年前ならいざ知らず、今なら、
Javaを始めとする、「C++よりはるかに美しい言語」で
仕事をすることも多々ある。

でも、現実にC++が標準となっていて、
難しいC++を理解できれば他の言語の理解も比較的容易であり、
未だにプログラミング入門にC/C++を用いる場所が他数存在し、
現実にC++を理解できなければ話にならない世界が存在する。

C++を理解しようとした努力と時間が、今の自分にも、仕事の上でも
何の役にも立っておらず、全て無駄だったと感じているなら、
そして、(特に仕事として選びたいと考えている)多くの人にとっても
無駄であると断言するつもりならば、
これからもずっとC++の悪口を並べていればいいさ。

残念ながらね、俺のまわりはC++を無視できるほど進歩的ではないし、
理論だけで食べていけるほど恵まれた世界には生きていない。
難しくて、ドロドロして、不合理で、過去のしがらみを捨てきれない、
そんなC++に対して悪口を言うのは簡単だけど、
それでは何も進まない。
正面から向かい合わないとやっていけないのさ。

>リファレンスカウント付きポインタ->スマートポインタ
>スコープ脱出後自動消滅->auto_ptr

というか1と0しか数えられないカウンタを持った
スマートポインタでしょか(笑)、auto_ptrって。
リファレンスカウンタだって自動消滅を支援するだろうし。

排他的所有権を持つっていう考え方は面白い。
まぁ、ポインタを代入される側(=Object)に
なんら支援機能が期待できない状況(だから
ルートクラスくらい用意しようよ…)での、
スマートポインタに対する代案ではあろうけど。

>逆に聞きたいけどあなたは関数ローカルなObjectを一切使わないのか？

そりゃ使わないことはないが、(下に続く

>もし使うならそれはauto変数の出番だろ。

だからといって(生の)auto変数(に埋め込む)Objectの出番だと
言いきれるものでもないよね？という話です。
スマートポインタとかauto_ptrとかを使えば、
ローカルに使いたいObjectを消す面倒の問題と
Objectを他所にやるときの面倒の問題が
いっぺんにおおむね解決するよね。

そういやJavaは遅いわけだけど、VMの遅さとGCの遅さはともかくとして、
参照ベースであることは遅さにどれだけ寄与してるんでしょう？
＃というわけで、参照ベースだけどVMもGCもない言語の例としてdelphi…以下略
＃ただしdelphiにはスマートポインタ(やそれを自作する仕掛け)は無いけど(笑)。

>>300
あんまり煽りには見えないけどね(^^;

>インスタンス化される回数で数えたらループの中で100万回生成される
>オブジェクトが一番になっちゃうだろ？

その数え方でいいじゃん。
100万個生成されてCollectionに所有される
っていうObject(たち)ならどう？

>いまは実行時の効率の話をしてるわけじゃなくてコーディング時の話しなんだから

そうだっけ？
というか、この話を効率の話に直結しちゃうところが
既に微妙に痛いと思うんですけど。

>>301
>それを今更声を大にして叫ぶ奴がいるなんて思わなかったな。

っていうか、それを言うならスレタイトルからして既に
わかりきったことなのでわ…

>でも、現実にC++が標準となっていて、
>未だにプログラミング入門にC/C++を用いる場所が他数存在し、

うーん。多数論になっちゃうわけ？

>難しいC++を理解できれば他の言語の理解も比較的容易であり、

そうか？他の(メジャーな)言語では聞いたことない概念や
自分が言語自作するような日が来ても絶対サポートしないだろうなと
思われるような概念が、C++には色々有る、ということなのだが。
まぁ、反面教師(=装備しないほうが良い機能だなと考える)の
重要な候補を教えてくれたのは助かるが。

>全て無駄だったと感じているなら、

無駄とは思わないよ。でも、もっと良いもの(が有ること)を
知ってしまった以上は、無駄ではないとは言っても
それの在るべき場所は人の心の中および博物館だけでしか
ないんじゃないの？という話。反面教師。

>そして、(特に仕事として選びたいと考えている)多くの人にとっても
>無駄であると断言するつもりならば、

うん。自分で駄目だと思っているものを他人に「おすすめ」する訳無いじゃん。

>そんなC++に対して悪口を言うのは簡単だけど、
>それでは何も進まない。
>正面から向かい合わないとやっていけないのさ。

それを正面と言うか？C++を克服することから逃げてるだけじゃん。

本当の「正面」は、たとえばもっとマシな言語を
作るとか実装するとか持ってくるとか、じゃないの？

もちろん、正面でないのが「あなたの」せいだとは言い切らないけど。
不可避な理不尽は世の中いっぱいあるから。
でもそれはあくまで正面ではないね。

欠点を指摘しあうスレは大抵こうなる。
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=986993653

さげろっての、ボケ。

結局、「オブジェクト指向を」学ぶのにC++は向かないってことでしょ。
世の中にはC++で書かれた資料やサンプルやアルゴリズム等が蔓延している。
CS機・制御系等、事実上C/C++しか選択肢がない環境も多い。
それらを踏まえて「C++を」学ぶ人がいる。
もちろん、選択肢がC++以外にあれば、
いくらでも移行する人はいるだろうけどね。俺を含めて。

「C++を」学ぶ人に対して(タイトルどおり)、C++の欠点を指摘する。
とっても建設的だね。感動しちゃった。

>「C++を」学ぶ人に対して(タイトルどおり)、C++の欠点を指摘する。
>とっても建設的だね。感動しちゃった。

欠点を指摘しないのが建設的なのか？
そんなに1を迷走させたいか？(w

スレタイトル見ろよ。問いは「なぜ難しいか？」なんだぜ。
そう問われて、欠点を指摘しないほうが変だろ？

>>305
好きだね、キミも。

>スマートポインタとかauto_ptrとかを使えば、
>ローカルに使いたいObjectを消す面倒の問題と
>Objectを他所にやるときの面倒の問題が
>いっぺんにおおむね解決するよね。
他所ってのは自分が呼び出す関数のことではないよね。それなら＆で渡せるし、
そういうのを含めてローカルで使用するってことだ。
それ以外の意味で「他所」ならそのオブジェクトは「ローカルに使いたいObject」
という前提じゃないんだからパス。その2つを混同するのは痛くないのか？

まあauto_ptrで書いても別に問題がないのは確かだ。なんでauto変数にすればす
むものをいちいちauto_ptr？ってのは残るが、目的は達成できる。

あとauto_ptrだってスコープと共に自動的にデストラクタを呼んもらう、という
機能を使って実現されてるのだぞ。
まさにauto変数に埋め込むことの良い例ではないか？

もうひとつプリミティブ型はさすがにauto変数にしていると思うが、なぜnewで
作ってauto_ptrでラップしないのか、理由が聞きたい。

　俺はC++の方がJavaよりも美しいと思うけどバカかな(笑)
　Stringクラスだけに演算子が使えたりするのって、美しい？
　多重継承が無くて、実装継承が１つ「だけ」使える、って美しい？
　クラステンプレートみたいなデータ型とアルゴリズムを分離する
方法が無くて、配列とかコレクションクラス使うたびにキャストの
嵐になるって美しい？
　言語仕様とクラスライブラリの境界が曖昧で、ユーザには絶対に
作れないようなクラスがどかどか存在してるって美しい？
　ロジックのみが単体で存在できず、Mathクラスみたいに強引に
クラスにいれないといけないって美しい？
　パッケージをpackage句とディレクトリの二重で管理しないと
いけないって美しい？
　多重継承のアンチテーゼみたいに言われているインターフェースが、
結局多重継承の最大の弱点と言われていたメソッド名のバッティングを
実はまるっきり解決できてないって美しい？

　わからないなあ。Javaってそんなに美しい？

とりあえずプログラム言語にに「美しい」って言葉を使うの止めれば？

scheme言語は美しい

>>313
同意

C++ ってむやみに強力だけど、美しくも汚くもないと思う。
型変換（時にオペレータ）とかが暗黙で呼ばれるというのは
タイプ数を減らすという妙なところにこだわっていて変だけど、
これは C の後継である以上いたしかたないし。

template はひじょーーーによいと思う。Java にも☆い

>>312
　これは>>301さんが

>まあ、C++が汚くて他の言語の方が優れてるなんて事は、
>(この板にいる)ほとんどの人は知っているのさ。
>それを今更声を大にして叫ぶ奴がいるなんて思わなかったな。
>Javaを始めとする、「C++よりはるかに美しい言語」

　っておっしゃるもんだから、「この板のほとんどの人」が僕の疑問に
サクッと答えてくれるかな、と思って書いてみたんですよ。
　僕の意見としては、C++は美しくはないけど、Ｃ言語の素直なオブジェ
クト指向拡張だと思う。
Javaは美しくない。素直でもない。どっちかっていうと、地方出身の
女を専門に食い物にしているナンパ師のような、うさんくさい優しさを
感じるね。ただ、ＧＣやってくれるのは便利だし、クラスライブラリは
強力だから、使える処理系ではあるかな。ただ、ひたすらうさんくさい。

>>312
　なんで？　美しいって言葉使うのやめるとなんか良いことあるの？

>>316
でCはじじい（職人）ですか。

C++はテンプレートが便利ってことに尽きる。

>>318
いいねぇ。じじいＣ。

>それ以外の意味で「他所」ならそのオブジェクトは「ローカルに使いたいObject」
>という前提じゃないんだからパス。その2つを混同するのは痛くないのか？

区別しなくて済むのが有りがたいのだが。
Collectionとかにぶち込むとき、これはStack上のObjectかHeap上のかを
いちいち悩むのは、うっとうしくないっすか？

>あとauto_ptrだってスコープと共に自動的にデストラクタを呼んもらう、という
>機能を使って実現されてるのだぞ。
>まさにauto変数に埋め込むことの良い例ではないか？

そりゃC++のauto変数の特徴(利点?)を使って成り立ってるってのは
確かだが、同時にあれは、auto変数直接埋めの「欠点を克服」
することに使われているわけじゃん。実装手段と目的の話は別。
乱暴に言うならば、
「二度とauto変数を使わないために、auto_ptrはauto変数を使っている」わけ。

>もうひとつプリミティブ型はさすがにauto変数にしていると思うが、なぜnewで
>作ってauto_ptrでラップしないのか、理由が聞きたい。

それはまぁ…効率(笑)。Delphi/Javaも同罪。

ちなむとrubyあたりは、整数はMutableつーか識別可能にする意味が
無いっていう立場らしく、整数はauto変数と同じ扱い(文法に
そう明記されてるわけじゃないが)。

>>316
>Ｃ言語の素直なオブジェクト指向拡張だと思う。

素直じゃないと思うぞ。ObjectiveCあたりのほうがよほど素直でわ？
templeteとかの非OOPな要素が絡んでくるし。

あとメタクラス無いのも「素直じゃない」といえるかも(^^;


>>315
型変換の考え方がヒネリ過ぎってのは言えてる。

Javaにtempleteっすか。GenericJavaっすかねやっぱり。
ただしあれはC++のよりよくも悪くも軽量らしいっすね。

>>311
Javaは決して言うほど美しくない面も多い。が、
C++のほうが美しくない面が多いってのと、
Javaと同じような面(???)をC++と比較してどっちがマダマシ
(ここでいうマシとはあくまで美しさだけの比較)か？という
やらしい面も有るし、ということも言えそう。

>多重継承が無くて、実装継承が１つ「だけ」使える、って美しい？

「C++の無制限な多重継承」よりは、「美しい」かも。
C++ももう少し色んな制限を設けたら良かったのに。
structとclassの話にしても、C#みたいに(笑)両者をはっきり
区別すべきだったろうと思う。

あと、OOP言語としての美しさを言うときに付きまとうのが、
機能を「Objectが」持っているかどうか？だったりもする。
C++はコンパイル時にObjectと関係なく処理が済んじゃう場面が
凄く多いので、OOP至上主義者には不気味に見えるよ(笑)。
たとえばtempleteはOOP畑でいえばTempleteMethodsやStrategy
だったりするわけだけど、C++はほぼ同じ(実行時に交換出来ないので
柔軟性において同等じゃないが)ことをコンパイル時にやってしまう。

>ユーザには絶対に作れないようなクラスがどかどか存在

JNIじゃ駄目か？(笑)

ん？実装の話だけしてる訳じゃないだって？
だって、C++だって「C++のObjectモデル」を破る合法な方法は
存在しないじゃん。同じことだ。メタクラスを俺にくれ。

>パッケージをpackage句とディレクトリの二重で管理しないといけないって美しい？

あれは二重管理じゃないと思うんだけど、間違ってますか？

>結局多重継承の最大の弱点と言われていたメソッド名のバッティングを
>実はまるっきり解決できてないって美しい？

ん？どこが？
Interfaceはバッティング問題を「逃避」してるだけだが、
逃避だけで十分な解決策だと考えてるわけじゃん。
なんか不味いの？
委譲とかのコードをうだうだ書かないとならんのはしんどいが、
それは別の話だし。

>>321
無条件にヒープ上にオブジェクト作られたら、ゲームや組み込みなんか
で C++ を使えなくなってしまう。Win32 みたいに、プロセス毎に広大
で疎な仮想メモリ空間が提供されてない世界も、まだまだ多いですよ。

ヒープは組み込み用用途にはあんまりむいていないからね。
C++まんせー

>区別しなくて済むのが有りがたいのだが。
>Collectionとかにぶち込むとき、これはStack上のObjectかHeap上のかを
>いちいち悩むのは、うっとうしくないっすか？
だからコレクションに(参照で)ぶち込むものは基本的に寿命不確定なんだからnew
するでしょ。その点では全面的に賛成してるんだけど。

>>もうひとつプリミティブ型はさすがにauto変数にしていると思うが、なぜnewで
>>作ってauto_ptrでラップしないのか、理由が聞きたい。
>それはまぁ…効率(笑)。Delphi/Javaも同罪。
じゃあ効率を意識しなくて良いときにはプリミティブもnewで確保するのかい？
C++では、あなたが
・プリミティブを値として保持するか
・プリミティブを参照として保持するか
を選択できるんだよ。

>>324
うーん。するとJava(でEmbedded)については
どう考えると良いでしょうか？
「あんなの全然駄目だよ」で終わり、ってことですか？

Wabaなんていうふざけた処理系も有りますね。
まだZ80に移植した人は居ないのかな？
ラピュータになら居るけど。

>>325
選択できることのありがたみって結局なによ？という
話になると思う。二つモデルが有っても、その
デメリットよりメリットが多いならば、という。

おっと。見落とした。

>・プリミティブを参照として保持する

ってナニ？参照で「保持」はできんでしょ。
C++の参照はマスター(笑)の変数の存在に依存するから、
結局はプリミティブを値として持つ奴が存在する。

それとも古典的ポインタの話？
じゃないよね？

現在のOSが何言語で作られているかを
考えれば、C++言語とその他の言語の比較は甚だ奇妙と
言わざるを得ない。
さらに言えばJava言語はC++言語のサブセットであり、
もちろん実装の多くの部分はC++言語である。

Javaにとって重要なのは、その巨大なライブラリが
無料であるということに他ならない。
皮肉なことは、Java言語が、すでにC++言語よりも
古いプログラミングパラダイムに居るということだ。

>選択できることのありがたみって結局なによ？という
>話になると思う。二つモデルが有っても、その
>デメリットよりメリットが多いならば、という。

？？？
>>もうひとつプリミティブ型はさすがにauto変数にしていると思うが、なぜnewで
>>作ってauto_ptrでラップしないのか、理由が聞きたい。
に対して
>それはまぁ…効率(笑)。Delphi/Javaも同罪。
って答えたわけだ。だから効率が重要でない局面ならauto_ptr使うのか？
#違うだろ？C++はあなたが選択できるんだってことを忘れてはいないかい？
#という意味を込めて
と聞いたんだけど。わかりにくかったなら謝ろう。
結局
「効率が重要でない局面ならプリミティブに対してauto_ptr使うのか？」
答えてくれ。

>それとも古典的ポインタの話？
そうだ。
値を保持する->auto変数
参照を保持する->ポインタをラップしたauto_ptr

>「効率が重要でない局面ならプリミティブに対してauto_ptr使うのか？」

再考したんだが。
プリミティブってintとかだよねえ。
すると「同値性と同一性を区別する意味」が
あんまり無いモノである場合が多いだろうな。
それならば、
かつ、そのサイズの極端な小ささ(笑)により
ポインタを経由することでコストをちっとも削減できないので、
auto_ptr使わなくてもいいっか。

構造体(やソレによくにたObject)は話が別ね。

OSは微妙なところだなあ。
C++だとObjectモデルが二重管理っぽくなっちゃうでしょ。
あるいはマクロとかでC++言語に事実上手を加えるか。

C++ってコンパイルしてナンボなんで、
かつて見たこともないような全く新しい
実装とInterfaceを持った新たなModuleを
「動的リンク」しようとすると、
C++の範囲では手の打ちようがないよね。

リフレクションとかが強い言語のほうが
OSを作り、かつそのモデルをシームレスに
アプリとかの環境にまで展開するには(^^;、
ずっと便利でしょうね。

というわけで、

>現在のOSが何言語で作られているかを
>考えれば、C++言語とその他の言語の比較は甚だ奇妙と

>Java言語はC++言語のサブセットであり、
>もちろん実装の多くの部分はC++言語である。

それって関係有るの？
単に二重管理しているだけ、というか、
C++のObjectモデルとは関係なく
フルスクラッチで新たなObjectモデルを作って
それをOSなりJavaなりに提供してるっていう構図
だと思うが？

単に、超メジャーな言語で、Cよりは便利な面も多い言語、
として使われているだけだと思う。

いや、単にそのことを指摘したい文章だったなら、ごめんな。

>皮肉なことは、Java言語が、すでにC++言語よりも
>古いプログラミングパラダイムに居るということだ。

新旧を言うなら、Smalltalkが一番古いわな(笑)。
進歩と変化は別概念だよ。

新しいパラダイムの部分って、例えば他の言語をC++で実装するときに
どれだけ活用されてるの？
あんまり活用されていないならばそれは「蛇足」なのかも知れないよ。

>プリミティブってintとかだよねえ。
>すると「同値性と同一性を区別する意味」が
>あんまり無いモノである場合が多いだろうな。
なぜだ？
　int *pInt1, *pInt2;
　if (pInt1 == pInt2)// 同一性
　if (*pInt1 == *pInt2)//同値性
はぜんぜん別のものでしょ？

それに多くのオブジェクトは同値性を使わないのだから
それこそ「同値性と同一性を区別する意味」がないんでないの？

>>326
組み込みといっても分野が広くて、ある程度の広さのメモリ領域を
使えて、リアルタイム処理もさほど厳しく要求されないケースもあ
る。たとえば i アプリとかね。こういうケースでは Embedding
Java が活用できる。

ただし次のようなケースでは Java は使えないし、組み込みでは、これ
は珍しくない話。

- メモリリソースやリアルタイム処理の制限が厳しい
- OS の機能が限定されている、もしくは、そもそも OS がない
- OS やデバイスドライバを書く

こういう用途では、アセンブラと C/C++ が活躍する。Java や Delphi
の出番はない。

p.s.

少しは自分で考えなよ……。自分が知らない分野のことは「見ない・
聞かない・言及しない」って態度だと、いつまで経っても Delphi 厨
房を卒業できないよ。

>>331
実際の OS のソースコード読んだ上で言ってる？

>int *pInt1, *pInt2;
>if (pInt1 == pInt2)// 同一性
>if (*pInt1 == *pInt2)//同値性
>はぜんぜん別のものでしょ？

区別する意味あるの？

>それに多くのオブジェクトは同値性を使わないのだから
>それこそ「同値性と同一性を区別する意味」がないんでないの？

いや、正確に言おう。区別するかどうかというよりも、
「同一性が使えないと困る」。
コピーばっかりしまくると困るわけだよね。


>>333

Javaについて。それって参照ベースのObjectの話と
関係あるのは何割までなんでしょうか？
VMが重いとかの話になってませんか？
まぁCPUネイティブのStackを使うと
メモリ管理の手間が最小化できる
というメリットはありますけど。

>少しは自分で考えなよ

逆だよ。自分で考えたからこうなってるんだよ(笑)。

つーわけですまん。OSのコードはあんまり読んでないな。
でも出来るわけないのは「自明」じゃん。
まぁ継承の替わりになんでもかんでも委譲でやれば
ある程度のことは出来るが。

JavaはCで作られたUNIXを既に超えていると思う。
Javaを言語なんて言ってると大事なところをとりこぼしちゃうでしょ。
もちろんOS無しには動かないけどあれだけのライブラリがあると
もうアプリケーションみたいだよね。

そういう意味で.NETも面白そうだとは思うけど、、、
二つもいらないなぁ・・

>>336
UNIXを越えるとアプリケーションか。
つまりOSを越えたものがアプリケーション。
近藤君病院へ逝って良し。

>>336
実現されていない理念を狂信するのはやめたほうがいいよ。

頼むから、簡単だからって安易にスレッド作ったりJDBCコネク
ション切ったり繋いだりを繰り返さないでほしい。
ソース上は簡単でも実行時は半死体状態。「99%以上ちゃんと
動く」ようにするには、スレッドスケジューリングとかいろいろ
難しいことがありすぎて死ぬ。結局、各種リソース確保解放の概念や
同期プログラミングの基本的な手法を知らない馬鹿をJavaで凄い
プログラム出来た気にさせてしまっているのは、VBと同じで長期的には
犯罪だと思うんだがなあ。

あれ？俺なんで336なんて書いたんだろ？スマソ。

>>336
「大事なところ」って何？

>>336
これが結構妄言であることは俺(笑)も賛同するが、
だからといってunixのfork()はやっぱり勘弁だな…

>338&341&その他
いいかげん不毛なんでsage進行でやってくれや。

>>341
はいはい、fork() が云々とか言うくせに、どうせプロセス・スレッドの代表的な
Design and Implementation も知らないんでしょ？　知らないことは、批判せず
に黙っててくれないかな、邪魔だから。

C++ と関係ないんで sage ます。

>>if (pInt1 == pInt2)// 同一性
>>if (*pInt1 == *pInt2)//同値性
>はぜんぜん別のものでしょ？
>区別する意味あるの？
おいおい…
C++においてはintはimmutableじゃないんだから区別しなくちゃさぁ。
「区別する意味あるの？」なんてきっとRubyかなんかの議論を聞きかじって
混同しちゃってるんでないの？

>いや、正確に言おう。区別するかどうかというよりも、
>「同一性が使えないと困る」。
>コピーばっかりしまくると困るわけだよね。
なおさら意味不明。まあ上のが分かってないならこうなるか。

もう一度次のことをヨーク考えてみよう
・C++ではプリミティブとクラスが限りなくシームレスである。
・つまりC++ではどんなものでも(intでさえ)Objectである。
・もちろんintは継承もできないし、メソッドも少ししかない
・さらにポインタもObjectである。

>C++においてはintはimmutableじゃないんだから区別しなくちゃさぁ。

おいおい？ intの「値」がmutalbeだってのか？
変数と値を、やっぱり混同してないか？
ここで変数の話を持ち出してもしょうがないだろ。

>・C++ではプリミティブとクラスが限りなくシームレスである。
>・つまりC++ではどんなものでも(intでさえ)Objectである。

Objectって語の定義を、そもそもOOPでの定義から
離れさせようってのかよ。
そんなことしたらそもそも会話にならないのだが？

intがObjectねえ。OOP以外の畑ではそう呼ぶこともあるが、
C++のint(値も、当然変数も)は、
OOP的にはどう転んでもObjectじゃないだろ。
もしかして多態とoverloadを勘違いしてたりせんか？

というか、C++でプリミティブとクラス(もといObject)が
シームレスに扱える理由は、両者ともObjectであるから、じゃないぞ。
両者ともObject以外のナニか(?)としての性質を持っているから、だ。

>>343
自作言語(C系とは全然似てない)に似非マルチスレッド
の仕掛けを実装しようと思っているところだが、それがなにか？
似非といってもOSネイティブスレッドを使わないというだけの意味。

そりゃそうと実装を知ってどうすんだよ？実装がどうであろうが
Interfaceていうかモデルは、同じ(でないと不味い)だろ？

sageでやれ

>>C++においてはintはimmutableじゃないんだから区別しなくちゃさぁ。
>おいおい？ intの「値」がmutalbeだってのか？
>変数と値を、やっぱり混同してないか？
>ここで変数の話を持ち出してもしょうがないだろ。
変数の話だよ。なんで「変数の話を持ち出してもしょうがない」のだ？
あと「intの値」っていうのが
１・intが（ポインタだとして）指し示している値（オブジェクト）
->intはポインタじゃないんだからX
２・intに代入されている数字
->そんなこといったらCFileの値だってimmutableだが？

>intがObjectねえ。OOP以外の畑ではそう呼ぶこともあるが、
>C++のint(値も、当然変数も)は、
>OOP的にはどう転んでもObjectじゃないだろ。
>もしかして多態とoverloadを勘違いしてたりせんか？
多態がObjectの条件ならJavaのStringはObjectじゃないってことか？
intと普通のクラスの違いはintがfinalであること以外になにがある？
#?が多いなぁ

　ども。久しぶりに来てみたです。

>>325

>>多重継承が無くて、実装継承が１つ「だけ」使える、って美しい？
>
>「C++の無制限な多重継承」よりは、「美しい」かも。
>C++ももう少し色んな制限を設けたら良かったのに。

　よくわからないな〜。美意識の違いか？
　例えばですね、オブジェクト指向的に考えると、基底クラスというのは
派生クラスにとって、ある種の関連があるわけですよね？　まあ言い古された
言葉で表現すると、is-a関係とか。
　それが、基底クラスと派生クラスの関係だったとして、じゃあ、派生クラスに
とって、そのような関係となりうる基底クラスが、果たして常に１つしかないの？
ってのが僕の疑問。
　Threadクラスなんていい例だけど、「あるクラス」がマルチスレッドで動作する
とする。Threadクラスが「スレッド」そのものをクラス化したものではなくて、
「マルチスレッドで動作するクラス」をクラス化したものであるというのは
仕様を見ればわかる。つまり、その「あるクラス」is-a「Threadクラス」な
わけですね。だから、基底クラスにする。
　ところが、その「あるクラス」が既に別の基底クラスを持っていたとする。
そうなると、「あるクラス」is-a「Threadクラス」であるんだけど、それを
実現する継承機構は使えず、Threadクラスは基底クラスになれない。
　理由は一つ。「Javaでは基底クラスは早い者勝ちだから」でしょ？
　どうですかね？　このルール、美しい？　僕はC++の無制限な多重継承
のほうが原理をそのまま表現しているという点で、美しいと思うけど。
（使いやすいかどうかは別の議論として）


>C++はコンパイル時にObjectと関係なく処理が済んじゃう場面が
>凄く多いので、OOP至上主義者には不気味に見えるよ(笑)。
>たとえばtempleteはOOP畑でいえばTempleteMethodsやStrategy
>だったりするわけだけど、C++はほぼ同じ(実行時に交換出来ないので
>柔軟性において同等じゃないが)ことをコンパイル時にやってしまう。

　テンプレート引数になるオブジェクトが多態性を意識した
継承構造を持っていれば、十分いけますよ？　ってか、C++で
パラメタライズドクラスを使うときはそれが基本だと思います。


>>ユーザには絶対に作れないようなクラスがどかどか存在
>
>JNIじゃ駄目か？(笑)

　JNIってJavaの言語仕様の一部なのかな？


>だって、C++だって「C++のObjectモデル」を破る合法な方法は
>存在しないじゃん。同じことだ。メタクラスを俺にくれ。

　これは同意。メタクラスほしい。いろいろ工夫したけど、簡単に
やる方法はみつからなかった……

>
>>パッケージをpackage句とディレクトリの二重で管理しないといけないって美しい？
>
>あれは二重管理じゃないと思うんだけど、間違ってますか？

　僕はどっちかにしてほしいな。クラスモジュールの再利用性が落ちる。


>
>>結局多重継承の最大の弱点と言われていたメソッド名のバッティングを
>>実はまるっきり解決できてないって美しい？
>
>ん？どこが？
>Interfaceはバッティング問題を「逃避」してるだけだが、
>逃避だけで十分な解決策だと考えてるわけじゃん。
>なんか不味いの？
>委譲とかのコードをうだうだ書かないとならんのはしんどいが、
>それは別の話だし。

　いや、解決とか逃避とか、そういう言葉選びはどうでもいいんだけど、
要するに全然ダメじゃん？
　例えば、C++なんかだと、あるクラスが

class Base1
{
void foo () ;
} ;

class Base2
{
int foo () ;
} ;

　だったりすると、この二つを多重継承するともうダメ、ってのが問題点
として言われていたりしますよね？　これがメソッド名バッティング問題。
　で、じゃあこれをJavaがinterfaceで解決（まあ逃避でもいいけど）して
るかというと、なぜか多くの人はinterface使えばオッケーだろ！interface
は多重継承の問題点を解決した美しい仕組みでimplementsし放題！って
思ってるらしいんだな。でも、ちょっと考えればすぐわかる。全然ダメ。
　僕がJavaを「地方出身の女ねらい専門のナンパ師」って言うのは、
ここいら辺が理由ですね。

Javaには総称が無いからな……。
いや、できなくはないけど……。

List<String> lst = new List<String>();
lst.add("TEXT");

のようにクラスを指定できて、<>を省略したらObjectを指定したことになる。
というわけにはいかないのか？？
Eiffelの、制限が付けられる総称みたいな。

>>348
コードでもデータでも実体のあるものを継承すると（カプセル化が弱まって）いろいろ問題が起きて来るわけで、
C++ならすべて純粋仮想関数、javaならinterfaceだけ（継承は使わずに）で、作ればいいんじゃない？
カプセル化とポリモフィズムそのものはバッティングしないが、カプセル化とコードやデータの継承は、
もともと相反するものだし、それはどのOO論者でも一致していると思う。背反するものをC++もjavaも
それぞれ妥当と思う地点でバランスをとっている（つもり）になってるわけだ。どっちが優れてるとは
いえないと思うけど。どちらもベストではないというだけの話。（これはポインタやメモリ管理にも
いえる）

だからあえて言えば、（データやコードの）継承はC++みたいに複数許すのも、javaみたいに1個しか
許さないのも、合理的ではなく、0個が唯一の正解、ってのはダメ？（笑）

もひとつ。smalltalkでさえメタクラスなんて普通は使わない。smalltalkそのものを
実装する時以外は。メタクラスがほしいって、どういうときにほしいの？
（煽りじゃなくて素朴な質問。たとえば〜をやろうとしたときに、〜ができれば
いいなと思った、って回答を希望）

>>350
　こんばんは。348です。
　どうも僕は勉強不足のせいか、継承の問題点って全然わからない
のですよ。自分がハマったことがないので。
　実体のあるものを継承するとカプセル化が弱まる、ってなんで
なんでしょうか。全然イメージ湧かないのですけど。
　例えば、派生クラスから基底クラスの属性を直接いじくるような
コードを書く人がいるってことですか？　C++なら、メンバはprivate
が基本ですよねえ？
　たとえ継承を使わずに委譲で実現したとしても、結局はなんらかの
方法で、その属性を変更しないと処理が実現できないのでは？　だから
いじるのだろうし。
　うーん、良くわかりません。

え？
属性というのはデータってことで、データもコードも基底クラスのものを
利用するから、いろいろややこしいことが起こるわけでは。

メンバ関数のエントリしか継承しなければ、多重継承でもなにも問題は
起きないはず（コードもデータも自分のクラスで自分で実装する）。

要は基底クラスのものは「何も利用しない」。必要なのはポリモフィズム
を成立させるためのエントリだけ、という主張です。

いかが？
「それではコードの再利用ができないではないか」という以外の反論は
ないと予想しますが。

JCP　JSR-014がパブリックレビューが、ついこの間終わったぞ。
もうすぐ、JavaでSTLが使えるようになるよん。

>>349
総称ってなに？
解説 or サイト紹介キボーン

>>354
　っていうか、継承批判のあとには、必ず「委譲でGO」って
ことじゃないですか？　委譲すらしない、ってこと？
　委譲しないってことは、他のクラス使わないってことで、
それはまあありえない。しかし、委譲するなら、メソッドは
使うし、それにともなって属性も（間接的に）外からいじる。
　そうすると「いろいろとややこしいこと」がおこるのでは？

　そもそも、その「いろいろとややこしいこと」ってのが
わからないのですよ。前回もいったけど、継承でハマった
ことがないので。

>>356
総称generic
抽象化されたデータやアルゴリズムの事です。
C++のテンプレートの様なもの。
メタクラスを作れる言語ならあたりまえの様に定義できます。

>>355
Javaでテンプレート？

>>357 ん〜それではあなた自身があげている多重継承の問題を
javaのinterfaceは何も解決していない、という「問題」とは何？

一般にいわれる多重継承の問題というのは、class Aとclass Bが
それぞれ思い思いのfoo()を定義しているとき、AとBを継承した
class Cのfoo()は、どうしたらよいか？というものだと思う。

foo()の中身が2つあるのが問題で、選択肢は、

１）多重継承そのものを禁止する
２）多重継承は許すが、foo()の中身が0個以上あることを禁止する。
　　私が上で述べたこと。両方をinterfaceに。
３）多重継承は許すが、foo()の中身が１つ以上あることを禁止する。
　　一方をinterfaceに。
４）多重継承を許し、両方にfoo()の中身があることも許し、つじつまを
　あわせるために、 class Cのfoo()がA::foo()とB::foo()を駆使してが
　んばる（笑）

となるはず。で、４）は結構つらい、というのが多重継承のややこしい
問題だと思うけど？（はしょっているけど一番大きな問題はこれに
集約されるはず）

書き直し^^；

１）多重継承そのものを禁止する
smalltalkとかね。(多重継承版smalltalkもあるというつっこみはなしね）

２）多重継承は許すが、foo()の中身が１個以上あることを禁止する。
　　私が上で述べたこと。両方をinterface（純粋仮想関数）に。

３）多重継承は許すが、foo()の中身が１つ以上あることを禁止する。
　　継承は一つにして他をinterfaceに。 javaですな。

４）多重継承を許し、両方にfoo()の中身があることも許し、つじつまを
　あわせるために、 class Cのfoo()がA::foo()とB::foo()を駆使してが
　んばる（笑）

C++は４）を含めて１）〜４）のいずれもできるようになっている。
プログラマの責任でね。一方javaは１）〜３）までの自由度しかない。

両者の違いは、プログラマに権利と”責任”を負わせるか、それとも
権利も責任も制限するか、といった設計思想の問題。

鬱だ死のう

３） 1つ以上 ->2つ以上

>>358
ありがとう。
genericの訳だったのね。

　こんばんは、>>357です。

>>360
　>>348に書いてあります。読んでみてください。

>>361
　僕は実をいうと1-4の全てのアプローチに反対、っていうか
賛成しかねる。
　では何かというと、

5)　多重継承を許し、両方にfoo()の中身があることも許す。
　しかし、その二つの基底クラスに優先順位を持たせ、優先
　されるクラスに属するfoo()が優先的に実行される。

　いわゆるMixinですね。MixinはRubyにもあるらしいですが、
歴史は案外古くて、Lisp系のOPLのFraverが初出ではないかと
思います。（歴史については詳しくは知らない）

　で、実はあまり知られていませんが、C++はMixinを実現
できます。クラステンプレートを使うのですが、基底クラスの
指定にテンプレート引数を指定するのです。つまり、基底クラス
を静的に指定するのではなく、インスタンスを生成するときに
キミはこのクラスを基底にしなさい、と与えてあげるのですね。
　これですと、多重継承は使わずに（つまり、多重継承から
発生するいろいろな問題を回避しつつ）、機能的には多重継承
とほとんど変わらない機能を実現できます。パターンでいうと
デコレータにかなり近いです。
　もちろんこれはこれでいろいろと問題が出てくるのですが、
実際のソリューションとしては僕は一番気に入っています。
　それに比べると、Javaのアプローチは全く本質的ではない
ように感じます。あえていえば、「美しくない」ですね、全く。

>>365
テンプレートを使った Mixin のサンプル希望。

>>366
365じゃないけど、こんなかんじのことなんじゃないの？

template <typename DATA>
class Node : public DATA {
public:
　　Node<DATA> *next;
};

Node<Hoge> *pHogeNode = new Node<Hoge>();

こうことのことだったら、よく使われることだと思ふ。
#コンストラクタがめんどいことになることもよくあるけど

>>356 >>366
教えてクン？　教えてクンじゃないか！
いやあ久しぶりだね。
またあいかわず人に教えてもらっているのか？
いつまでもそんなことしてたら嫌われるぞ。
前に教えた検索サイト、使ってるか？
おっと、約束の時間だ、急がないと。
それじゃあこれで失礼するよ。
くれくれクンにもよろしくな。

>>365

>>348は読んでいて、私の解釈が>>361なのだけど（書き方がまずくてスマソ）

で、５）の話なんだけど、多重継承で問題となるのは、主として、共通の基底
クラスから派生した複数のクラスを両方継承する場合だと思うけど（それ以外
であれば大抵何とかなる）、５）だとその問題が存在しないの？なんか
問題は依然として残ると思うんだけど。ただ５）の中身がよく理解できてない
かもしれないから、できればコードで例をあげてくれるとうれしい。

補足。
私の解釈では５）がよいというのであれば、あなたの主張は「javaの欠点はinterfaceが
あること、ではなくて、テンプレートが無いこと、」ということでよい？

基本的に継承についてはC++の方がjavaの持つすべてを包含しているのだから、
まあ、〜の記述がC++ではできるけどjavaではできない、という意味では、javaは
常にC++より劣っていることに異存はないけど。。。

補足の補足（書き直すね）

javaやsmalltalkの場合、すべてのクラスがObjectから派生するので多重継承は
必然的に>>369の状態になる。C++の場合はどういったクラスライブラリをベース
にするかで変わるけれど。この場合に抽象クラス以外を多重継承したが最後、
clone()メソッドさえ、簡単には実装できない。

だから多重継承を使わず、単一継承＋委譲を勧める、というのであれば、まったく
正しく、なんの異論も無い。多重継承を使わなければ書けないプログラムなど
ないので。（多重継承を使ったほうがよりエレガントに書けるという主張はもちろん
ある。）

５）は単一継承＋委譲＋テンプレートであると思うので、javaにテンプレートが
ない分、javaが劣っているというのであれば、それはそのとおりと思う。

>>365
Mixinについて少し勉強したよ。ちょうどRubyの本が手元にあったんで。
おかげで勉強にはなった。まあ自分が述べたことは間違いではないと
思っているが、あなたの言いたいことはよく分かった。ふむ。

ところで…Rubyの作者ご本人？まさかね^^；なんか文体が似てるんだけど。

mix-inって、基本クラスとインスタンスを持たないMix-inクラスに
分類して、基本クラスを使って多重継承するときは必ず一つだけ
基本クラスを使うっていうルールのことじゃないの？

>>366
>テンプレートを使った Mixin のサンプル希望。

ATL がほぼそんなパターンじゃない？

色付ボタンのウィンドウと、カーソルが親指になるウィンドウを

class CColorButton : public virtual CWindow { ... };
class CChangeCursorWindow : public virtual CWindow { ... };

とせずに、

template <class T=CWindow> class CColorButton : public T { ... };
template <class T=CWindow> class CChangeCursorWindow : public T { ... };

としといて、
typedef CColorButton<CChangeCursorWindow> CChangeCursorColorButton;
とかする。

こうして単一継承のチェインを簡単に指定してクラスをでっち上げられる、
template の記述能力の高さはやっぱり言語によらず便利だと思う。

>>374
それだとMix-inクラス同士を組み合わせちゃってるよ。
Mix-inはMix-inクラスとそれ以外のクラスの組み合わせじゃないの？

>>347
>変数の話だよ。なんで「変数の話を持ち出してもしょうがない」のだ？

変数、しかもプリミティブの変数に、mutableもへったくれもないでしょう。
内部構造の要素が1つしかないんだから、
中身の「全部」を書きかえるのと「部分」を書きかえるのとを
区別する意味がない。

>そんなこといったらCFileの値だってimmutableだが？

んな無茶な。CFileなるクラス(かな)の中身は知らぬが。
型とclassが(言語仕様上)同じ意味にはなっていない、
という(だけの)話なんだがな。

>intと普通のクラスの違いはintがfinalであること以外になにがある？

finalはどうでもいいとして、
Object「の中」に構造が有るかどうか？が差じゃないの？

>>365の言ってるのってMix-inと全然違わない？

>>375
こういうやり方だと、mix といっても結局シーケンシャルな継承チェインに
なってしまうので、チェイン可能でかつ継承の順序を指定できるようにどちらも
あらかじめ mix inクラスにしておく、ということだと思うんだけど。

375 のいう純粋mix-inも ATL には良く出てきていて、

template <class T> class foo { ... ((T*)this)->bar(); .. };
template <class T> class hoge { ... ((T*)this)->page(); .. };

みたいなものを使って

class A : public foo<A>, public hoge<A>
{
...
}

なんてのも、超多用されてます。こちらは typedef 一発で
混ぜられないので、decolatorとしてはちょと鬱陶しい。
何かを実装するときには便利。

テンプレートなんか使わなくてもルールを守って多重継承
してればMixinになるが…

多重継承なんか使わなくてもルールを守って単一継承
してれば多重継承の問題は発生しなくなるが…

それじゃ非力じゃん>>379
非力なC++なんかクソの役にもたたん。
と、思う。

>>380-381
ﾊｧ？別にテンプレート使うなとは言ってない。
使わなくてもMixinになると言ってるだけだ。

だから、そんな mixin は非力だろ、って言ってるんじゃん。
C++ は toy language じゃないんだから、非力ながらこれも
できます、なんて話してもしようがないじゃん。

「過剰に豪快な記述能力(だからGCは自作してね)」ってのが
C++では？

つーことはテンプレートの無いC++はカスってことか？>383

>>384
カスだね。でもＣ言語ほどカスじゃない。

テンプレートが無かったら、JavaやObjectPascalに確実に負ける。
しかしそれでもＣ言語には楽勝。

>>383
「過剰に豪快な記述能力」つったら、
ふつーlispやschemeとかのことを指すと思うが。
あえてC++を選ぶ理由はCと同様に効率が良いって点だけだよ。
あと知ってる人が多い、とか(ｗ

>>385
じゃあ、最強はgcの無い(Borlandの)ObjectPascalつーことで、
ファイナルアンサー？

最強?

Cをカスっていうのは違うだろ。
アセンブラをカスって言ってるみたい。
両方とも低級ってだけ。
C++と比べるものじゃないだろ。

>>387
最強はテンプレートのあるＣ＋＋だ。
ObjectPascalなんて兄元にも及ばんな。

>>389
ＣとＣ＋＋を比べるのと、
Ｃとアセンブラを比べるのは、次元が違うよ。

>>386
キリ番(?)おめでと。

>「過剰に豪快な記述能力」つったら、
>ふつーlispやschemeとかのことを指すと思うが。

「なにを」記述するか？が言語によって色々じゃん。
Lispが狙う記述能力とC(++)が狙うソレとは
記述したい対象が結構違う。

Lispはいかに動的構造で何でもかんでも書けるか？に
命かけてる感じで、
かたやC系は御存知のとおり低級部分が主で
構造について言えば静的マンセーな言語。

話の腰を折って悪いんだけど、なんで最近言語関係のスレがたくさん立ってんの？

「おれはカレーが好きだ！」
「いや、おれはラーメンが好きだ！」
っていう議論だよね、コレって・・・。

俺は迷わずカレーだぞ？

札幌だとどっちも旨いぜ。
味噌ラーメンとスープカレーまんせー
いや冗談抜きにお勧め。

違う違う、俺は豚骨ラーメンが好きだ

カレーとラーメンはどちらがオブジェクト指向なのですか？
カレーから福神漬けをとると、ラーメンよりも弱いですか？

カレーはオブジェクト指向です。
カレーライスはカレーを継承しています。
本場インドでは様々な派生がみられます。
ハヤシライスはインターフェイスのみ継承しています。

ラーメンは構造化です。
麺やスープのモジュールを組み合わせてカスタマイズします。
スープのデータフローが店の秘伝です。
麺がゆであがり状態に遷移した瞬間を見極め、
湯切りイベントを発行するタイミングが大切です。

>>383
何が非力なんだ？
別にMixinを実現するのにテンプレート使う必要はないし、
別の部分にテンプレート使えば良い。
どこが強力なのかさっぱりわからんのだが。

>カレーライスはカレーを継承しています

ネタとはいえこれは痛い…
どう見ても継承じゃなく集約だろ、カレーライスは。

まぁ、ライスにするかナンにするか？の部分は、
抽象クラス「主食」を継承するモノならお好み次第
(んーと。ストラテジパターンかな？)
ってことなんだろうから、おかげで我々は
カレーきしめんという一見見慣れない食い物を
すんなり受け入れられるわけだ。CoCoイチまんせー

ラーメンはスパゲティプログラムを更に悪化させたものです。
スレッド(=糸)をスパゲティ以上に複雑怪奇にしてしまったもの。
ちなみにCoCOのカレーきしめんでは汁飛ぶのを防ぐ紙が添付
されていましたが、ロイホの坦々面では紙がありませんでしたので
ロイホはCoCOに負けました。弱いぞロイホ。

>>400
>どう見ても継承じゃなく集約だろ、カレーライスは。

？？
カレーとライスならそうかもしれんけど、
カレーとカレーライスなのだから汎化では？

>>399
具体例出さないと話がすれ違いっぱなしだと思うので、template を使わずに Mixin さ
せるコードの概略を示して欲しい。

もしかしたら、私が知らないだけで >>378 に匹敵する上手い方法があるのかも。

>>401
カレーチャーハンみたいにカレーと飯が不可分に
なっていたら汎化かもだけど、カレーライスは
単に並べただけにしか見えないっす。

ん。どっちが親か知らないけど、Compositeパターンかも。
実行時に動的にコンポ(飯)を付け足した感じ。
あるいは飯というDecoratorを付けたとか。
＃まぁそう解釈すると汎化に近づいては行くけど…

つまり、結論としてはカレーと言えば
ボンカレーゴールドということでよろしいでしょうか？

>>404
ええ。それを内包したボンカレーパンだと尚ヨシです。

＃あれってどれくらいメジャーなんでしょう？＞ボンカレーパン

カレーはうんこを継承しています。

＞４０３
カレーライスのカレーとライスは不可分だぞ。
お前はライスだけ見て「カレーライスの片割れだ」と思うか？

>>407
ん？思わないっすよ。
CompositeにせよDecoratorにせよ、
飯の相方はカレークラスじゃなくて
抽象的な具クラスだと見なす感じかな。
かけるのはカレーでも牛丼の具でも
どれでもいいわけよ。
「飯にかける」というInterfaceはコンパチだから。

松屋の「カレギュウ」まんせー(いや、旨いとは思わないけどね…

class カレギュウ:public カレー,牛丼{
};

カレギュウ cg=new カレギュウ;
cg->Hoge();

しまった、
カレギュウ*だった。
Javaと混じった。鬱だ…。

>>399
C++ は flavor や Smalltalk (の多重継承できるやつ) みたいに、
メソッド呼び出しが動的に解決される言語ではないので、本当に単純な
mix in では、mix する対象とか mix するときに同時に mix する相方
(あいかた)とかとのやりとりを行うときに、interface 抽象を行う必要が
あるでしょう？

そうすると、interface は特化しないので、共通の規定クラスがどうちゃら
の問題が出てきて、finalize するとき以外は mix in しない、とかそういう
方向へ逃げる必要がでてくる。と思う。例はちょっとかんべん。
こうすれば、そんなことはなくいろいろできる、というよい反例でもあれば、
出してくれるとうれしい。

C++ってすっごい簡単なような気がするのは僕だけですか？

>>412
心配するな。思い過ごしだ。

ああ、簡単でしょう。
なんかみんな変な機能つかうから難しく見えてしまうのでしょう。

ではＣ＋＋がまったく使えない私は逝ってよしですか？
あぁcoutとcinは使えました。

なんでさぁ。
そうやって一つの機能が使える使えないっていう視点でしか見れないの？
すっげぇレベル低いよ。

>>414
そう思います。いつのまにか仮想関数くらいしか使わなく
なりました。多重継承になる場合も、設計を少し変えれば
なんとかなることが多いですし。

あ、テンプレートはたまに使います。複雑になりすぎない
程度ですけど。やっぱりあると便利な場合もありますね。

>>402
>>411
次のようなクラスをMixinクラスとする。
・インスタンスを作らない
・Mixinクラス以外のクラスから継承しない

そして、多重継承するときは非Mixinクラスは一つしか使わない。
これでMixinになるはずだ。
これのどこに不満があるんだ？

ん？
template を使わなくてもできる、ということは自明だし同意するけど。

template を利用しない mix in は非力なので不自然だから、
template を使ったレイを出したんだけど、使わなくても強力で
自然なの、と質問してみたんだけど。

不満や満足について話したいなら、心理板にでも逝け。

↑
口汚くてごめん。

>>419
だから、どこが不満なのかってのは、どこが非力で不自然なんだ？って
意味だよ。

僕的には411で書いたことに尽きるんだけど。相互に独立したflavor
同士の mix-in って現実にあまり使わないから。

あえて411に追加するとすれば、flavorどうしの相互作用を実装/定義
するときに、単純な interface 抽象を使うと、interface 毎に利用
者は、その全てのメソッドを実装する必要がある。他のflavorやinner
objectに処理を委譲したり、「実装されていません」なんてエラーを返す
だけの多数のメソッド、とかを。

それはそれで別にかまわない(長くなるだけでできることは一緒)なんだけ
ど、templateという強力な syntax sugar があるのに、それを使わないの
は不自然、というようなこと。

Eiffelの多重継承がC++にほしい

型を確定した関数templateのアドレスをとる方法ってある？

template <class T>
T add(T a, T b) { return a+b; }

namespace tmp {
add(int a, int b);
void a()
{
　void *a = (void*) add;
}
}

こんな感じ？

いやこのほうが賢そうか。
template <class T>
T add(T a, T b) { return a+b; }

namespace tmp {
　int add(int a, int b);
};

void a()
{
　void *a = (void*) tmp::add;
}

思いっきりエラーが出るぞ
リリースモードなら最適化でコードがかき消されるから通ったように見えるが
だいたいテンプレートを作った意味が無くなっている

ネームスペースを止めて、ちゃんとインスタンス化構文に
したらOKだった。名前空間汚しまくり。

template <class T>
T add(T a, T b) { return a+b; }

template int add(int, int);

void a()
{
int (*a)(int, int) = add;
}

>>だいたいテンプレートを作った意味が無くなっている
何がいいたいの？templateのまま(インスタンス化しないで)
関数アドレス取れると思ってるなら中学からやり直したほうが良いよ。

424もちゃんと「型を確定した」って行ってる。

>>428
template int add(int, int);
この行無くても動かない？

IBMのICLUIとかのネタが出てないのはみんな知らないの？
VisualAgeC++とかでも使われてるはずなんだけど。

あのクラスライブラリはコテコテでかなりカッコイイ。
エラーはすべて例外で処理されてるし。
ほとんどのメソッドの戻り値がオブジェクトへの参照ってのがイカす。

現実の事象を中心にとらえ過ぎるのはいかがなものか？
継承は手段としてはすごいと思うが
それをそのまま採用するのは敷居を高めているような気がする。
人間らしさとコンピュータらしさの双方を兼ね備える言語＆方法論出てこないものか？

>>431
時代に追いつけないなんちゃってソフトウェア技術者みたいなこと言うなヨ

こういうスレができる事自体、C++の使いづらさを物語ってるな。

アニメの世界に目を向けてみよう。
アニメの世界は幼稚な絵からどんどん細かくなり
しまいには飛行機の絵にネジを書くまでに至った。（マクロスとか）
これがＣ＋＋だ。
しかし最近のアニメはだんだん絵がシンプルになり
絵の書き込みよりスムーズな動作に比重が移った。
これがJAVAだ。
しかしJAVAはまだ過渡期の言語だ。
C++からJAVAに移行した程度の流れがもう１度あるだろう。

さぁ皆ツッコメ。

>>434
あるんじゃない、でも C 言語の進化系としては嬉しくない。
C は、その驚くべきシンプル（当時）さと、機械語レベルに最も近い構造をもちながら、究極のソフトウエア開発論法（当時）その進化系としての C++ を考えるならば java は違うと感じる。
何かが違う、低級言語 C 進化系として java は認めたくない。 java はやはり高級言語だ。
さりとて C++ には満足できないが・・・

>>431
人間らしさなんてものを、厳密さがメリットである計算機に
期待するところはアホクサイと思うが、
継承どうよ？という意味では色々考えることはあるな。

こんなの発見。「継承じゃなく修飾」だそうだ。
言ってること全部が正しいとは言えまいが、
一部は参考になると思われ。
http://www.yy.cs.keio.ac.jp/~suzuki/docs/mct/modification01.html

>>435
ObjectiveCなんかはどう思う？

構文は(C++に比べれば)恐ろしくシンプルだ。
なぜシンプルに出来たかというと多分
動的な部分が多いから静的な言語仕様を
肥大させずに済んだんだろう。

メソッドの本体はCそのものと大差無い書き方が出来る
(当然コンパイル結果のバイナリも推して知るべし)が、
一方でメソッドディスパッチ(仮想関数の呼び出し)処理が
ruby/smalltalk並の動的処理。

高級アセンブラ度という意味では、
メソッド本体は満たしているが
メソッドディスパッチはそうではない、という感じ。

ただ、C++だってvirtualが(設計上)必要になれば
どうせ内部的に同じような仕掛けにならざるを得ないから、
おんなじようなもんだ。

結局C++の言語仕様って、骨折り損のくたびれ設けにしか見えぬ。

みんな例のジョークは知ってるよね？
あれはジョークにしたって所がジョークなんだよ。

最近まわりがJavaばっかなんで自分もJavaってみたり。
やっぱ Java って C -> C++ -> Java っていう感じで「進化型」なんですかね。
C# は使ったことないんでわからないけど。
GCC の C# フロントエンドがあればなぁ。一度使ってみたい。

Ｃ＋＋とオブジェクティブＣではどっちがお勧めですか？
わかる人はいろいろな点で比較して教えてください。

ヲタなら自分で使ってみな。

いや、自分で試そうとせず外野から好き勝手言ってこそヲタ

そか なるほど 間違ってたわｵﾚ>>442
でも440はお勧め教えてクレとかイってるぞ

ちなみに俺はオブジェクティブCが超オススメです >>440
なぜっておれわ使ったこと無いから

>>440
漏れのオススメはC++です。
理由は初心者が苦しんでくれるからです。
さらにオススメなのは、MASMです。頑張ってください。

ある村に魔法使いの女の子がやってきました。
魔法使いの女の子は村人が魔法を使えないので驚いてしまいました。
魔法使いの女の子の国では魔法なんて当り前です。

それで魔法使いの女の子は村人に魔法を教えてあげることにしました。

「ほら、こうやるんだよー」
魔法使いの女の子がお皿に手をかざすと
そこに美味しそうなケーキが現れました。

それを見た何人かの村人は魔法を使えるようになりました。
魔法を使えるようになった村人は家に帰って家族に魔法の
使い方を教えます。

こうやって魔法が使える人はどんどん増えていきましたが
どんなに頑張っても魔法の使えない人もいます。
魔法の使えない村人の前で何度実演してみせても
どうしても魔法が使えないのです。

そんなC++が大好きです。

プログラミング未経験の新人に「やり方教えて手伝ってもらえ」と言う上司と
「やる気はあるんでどんどん仕事回してください」という幸せな新人。
蓋を空けてみればＣ＋＋おろか
コンピュータに一度も触ったことがない珍人だった。

ふつうじゃん

普通....なのか？

同じオブジェクト指向言語で同じＣ系列言語
オブジェクティブＣとＣ＋＋
どっちが簡単なんですか？同じオブジェクト指向でも
その内容はけっこう違うのですか？

オブジェクト指向と言語は関係ありません。
私はCプログラマですが私の書くプログラムはオブジェクト指向です。
指向とは考え方でありプログラムとは関係が無いということです。

>>445
ﾅﾙﾎﾄﾞ!!

>>450
青果物に対してのオブジェクト指向が出来てません。

>>450
そうですか、わかりました。
ところで>>449の質問に答えてくれる人はいませんか？

>>445
その話泣けるね。
なぜ使える人と、使えない人が出来てしまうんだろうね。

Javaはだれにでもできる。
C++はだれにでも出来るわけじゃない。

おれは誰にでも出来る言語の方がいいな。

>>453
>>449の回答が>>450だ。
意味がわからないならかじめ焼いて寝ろ。

JAVAは誰にでも使えます。
しかし常に最良のプログラムを書くためには
JAVAの動作を正しく理解する必要があります。
C++は正しく理解しなければ使えないでしょう。

C++を理解した人はJAVAの動作を正しく理解することが出来るでしょう。
しかしJAVAから学んだ人はインスタンスや参照を正しく理解できるのでしょうか？

アスカは「ATフィールドの意味が判った」と言いました。
使える事と理解することは別なのです。
より正しく理解する。
それが上級者への一歩なのです。

そういった意味ではC++は素晴らしい言語でしょう。
全てを理解した人には関係無いですが
初心者にとってどちらが良いかはその人が
何を望むかによって決定されるでしょう。

>>445=>>457?

あなたオモロイな、微妙に

>>457
アスカは最終話付近で廃人になりましたが、その辺りの関連性は？

一部（１人？）のレスにより良レスへ変身中。

>>458
全てを理解したからといって過信は禁物です。
時に膨大なマンパワーを投入しなければならない懸案もあるでしょう。
初心→理解→自信→過信。
彼女は典型的な秀才プログラマの失敗例です。
人のフリ見て我フリ直せとは正にこの事でしょう。

>しかしJAVAから学んだ人はインスタンスや参照を正しく理解できるのでしょうか？

C++の問題は、
「だったら、C++から学んだら、インスタンスや参照を
(必ず)正しく理解できるのか？」
というと、全然そんなこたーねぇ、という点だな。

Javaとの比較でいえば、むしろ理解しやすさが弱い…
というか正確にいえば「誤解しやすさが強い」と
言うべきだろう、C++は。

それが証拠に、未だに未だに、Instance変数を
Class変数と呼ぶ馬鹿が、C++界隈には何故か絶えない(わら

Javaより10年も前に骨格が出来ちゃった、
時代遅れ言語だと思うぞ、あれは。

そして、これが一番痛いのだが、それゆえに
「古い教育方法」という過去の資産が多数存在する。
資産といえば聞こえがいいが実際は間違いが多くて
かえってOOP教育を阻害したりする。死産。

ちなむと、参照の理解に一番良いと言えそうな
手近なメジャー(?)言語といえば、今ならrubyだろう。

>>462
ruby信者逝ってよし！
ちなみにオブジェクティブＣとＣ＋＋の違いをだれか教えてください。

MSがボーランドを買収して全部Delphiにすればいい。

>>464
それじゃ逆に全部ＶＢになりそうね。

ObjectiveC はＣ言語にsmalltalkを取ってつけた言語。
C++はＣ言語のstructをclassとして扱えるように拡張してみた言語。
どちらも急造品であることに違いは無いね。
でもObjectiveCは本流から取り残されていて、標準規格すらないよ。

JavaでもC++でもいいけど、オブジェクト指向を取り入れていかないといけない。
C++はスキルさえあれば、しっかりとオブジェクト指向した上で安全なコードを書ける。
Ｃ言語でもオブジェクト指向できるけど、スキルがあっても危険なコードしかかけない。
Javaは誰でも安全なコードを書けるけど、しっかりとオブジェクト指向するには結局スキルが必要。
スキルがある人にとっては、JavaもC++も変わらない。むしろC++のほうが、
ジェネリックプログラミングできるし、実行速度も速くて都合がいい。

こんなところで議論交わしたところでC++好きはC++好きのままだし、C++嫌いはC++嫌いのまま。
ただお互いが自分の意見を主張しあっているだけで何の意味も成していない。時間の無駄。

C++が難しいとは思えないが・・・
個人的にはJavaが好きだな。
>>467
んなこと言ってたら２ちゃんの存在価値は無いと思われ・・・

>>>466
>実行速度も速くて都合がいい。

速いというほど速いのかC++？
そりゃネイティブなんだから少しは速くないと
やってられんけど、逆にいえばimodeなんて糞にまで
Javaが載せられるのは何故だ？という話になる。

JVMを「終了しない」ことが必要なんだろうな。
アプリ(??)を終了するごとにJVMごと終了するってのは
ネイティブアプリで喩えれば、アプリ終了ごとに
OSをシャットダウンしてる(次のアプリを起動するごとに
OSを再起動する)ってのと同じだ。
これじゃ遅くて当然だし、そんなレスポンスの比較の仕方じゃ
不公平すぎて話にならん。

つーわけで、上げっぱなしのVMの上で
(例えばデスクトップなら)shellみたいなものを動かして、
そこから.classをloadするようにでもすべき、だろうな。
これでやっと互角の比較が出来る。

C++は、難しいとかどうとかいうよりも、煩雑だ。

3個の概念があれば出来そうな仕事に
10個の概念を投入して、それら10個を
結局全部理解してないとまともなプログラムを書けない。

そりゃ頭がまともでパズル好きな人間には
10個を間違いなく理解することは可能だ。
だが、面倒、だ。

たとえば、初期化と代入の違いを、意識しすぎてる。
そんなもん代入一本槍でも十分だろうに。
パフォーマンス上の都合が悪いなら
最適化で頑張りやがれ。

あーいうのを自意識過剰っていうんだろう。
10個も機能があって、ボクはなんて世間に貢献してるんだ！などと
ドキュな妄想に浸ってる。3個で十分なんだよ。引退しろロートル。

今は亡きNeXTSTEPでObjectiveCやってたけど、かなりいい感じだった。
Java並に簡単だと思われ。
C++はなんであんなにでかくなっちゃったんだろう・・・そんな俺はC++使い

今は無きPC9821でN88BASICやってたけど、かなりいい感じだった。
ＨＳＰ並に簡単だったと思われ。
ＶＢは何であんなに重くなっちゃったんだろう・・・
そんな漏れはVC++。

このスレ馬鹿ばっかし

>>473
そうでも書かないと、自尊心が維持できないキチガイ（藁

>>469
この種の比較は納得できない。
Ｃ言語は元々ハードウェアを直接叩くような用途も考慮に入れた仕様の代物だ。
ＪＡＶＡはあくまでも高級言語だ、もうすでにＣの後継でもなければＣ＋＋の後継でもない。
Ｃ＋＋は腐っても、Ｃの後継言語であってＪＡＶＡとは違う。
Ｃ言語系のコンパイラは危険なコードはかけて当然の構造を持っていなければならない。
機種依存はしようと思えばすぐにできるし、したくなければしなくても良いようになっているのが正しい姿だ。
Ｃ言語には高度な言語機構というポリシーとともにもう一つ、自己責任原則の元何をしても良いという重要なポリシーがある。
Ｃ言語の後継言語である、Ｃ＋＋にも当然、自己責任で何でもできること、これができないＣ＋＋に意味はない。
極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。
ＪＡＶＡなんぞは、Ｃ＋＋で作られたＶＭの上にでも乗ってれば良いのである。

>>475
俺もC++派だし、キミのいうことは最もだと思うけど、
Javaを卑下する必要は無いでしょう。
独自ハード用のコードや、ゲーム機、ドライバなんかを書きたければC++。
アプリを作りたかったらJavaというふうに、住み分けすればいいのでは。
住み分けというより、Javaを使えないような環境でオブジェクト指向しようと思ったら
C++しか選択の余地が無いんだけどね。

>>475
>Ｃ＋＋は腐っても、Ｃの後継言語であってＪＡＶＡとは違う。

ああ。C++とJavaの血縁なんていう妄想は、俺も信じちゃいない。
たまたま文法の似た言語なんて、作ろうと思えば
(実際Javaはわざとそうしたんだろうし)幾らでも作れる、というだけ。

でなのだが、ならばJavaじゃ駄目な場合には
選択肢はC++しかないのか？ってのを考えないとね。

それこそObjectiveCとかでもいいんじゃないか？という話。
自己責任つー意味では、しょせんC派生言語だから
同じ問題はたとえ嫌でもついて回るし、
まして積極的にやりたければ以下略だ。

>極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。

てゆーか、そこまでやりたいなら「OOP言語」を使わないほうがいいよ。
構造体をどうぞ。

>ＪＡＶＡなんぞは、Ｃ＋＋で作られたＶＭの上にでも乗ってれば良いのである。
お〜ま〜え〜な〜、そういう余計なことは書かんでもえ〜の。

>>極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。

>てゆーか、そこまでやりたいなら「OOP言語」を使わないほうがいいよ。
これは、たまに欲しくなるんですがどう思います。
例えば、デバッグ中でちょいと、とある非公開メンバ関数の反応確かめてみようと
する時、いちいちヘッダファイルまでいって public にしたりとか、めんどくさいです。
最後に残骸が残ってないかワーニング出せるオプション付きで。

Objective-Cはもう時代遅れの感が否めない。使われてるのMac関係だけだし。

>>465
なんでDelphiがVBになるのよ。
DelphiをVBなんかと同列に・・・、いや止めとこ。またこじれる。

C++は言われているほど難しくは無い。
でもVC++でWindowsのプログラムを作るのが難しいから、
難しいと言う印象だけが先走っている気がするんだよね。

>>481
「言われてる」ってのがそもそもどの程度なのか？によるよな。

少なくともC++以外のフツーのまとも(わら)な多数のOOP言語を
見たあとでC++を見ると、結構おなかいっぱい、いや、ゲリするね。
ゲリってのは、「食い物じゃないもの」まで混じっているから。
つまり、OOPと、OOPと馴染まない(わら)他の色んな機能と、が
渾然一体となってるんだもん。

ところで、「super」に相当するキーワードが存在しないのは
あまりにも痛くないかC++？
親クラスのメンバを参照したいときにクラス名を
ベタ書きしないとならんだろ。匿名性(?)が無い。

ベタ書きは多重継承があるから「しかたない」という声は有ろうが、
だからって許されることと許されないことが有るぞ。
あるいはtempleteで誤魔化す(元々存在しない匿名性を
templeteで擬似的にやる)ことができるぞという意見もあろうが、
誤魔化しが必要な時点で既に腐っているだけだし。

なんで匿名親クラス参照キーワード(?)のsuper(のようなもの)を
なにがなんでも実装しよう！と心血注がなかったかな作者は？
力のかける方向が変なんだよ、C++は。

>>479
憎まれっ子世に云々って感じだぞ、少なくともC++について言えば。
C++なんて屋上屋を架してるんで、上が新しい(優れてるのと同義とは
限らず、付け焼刃という単語も存在するが)ようでも、
下の地層には古生代の化石が埋まってるぞ。

逆にSmalltalkみたいに、最初からWellDesignedな言語は
時間が経ったからってそうそう多くの仕様を追加する必要に迫られない。

すまん。482の補完。

最初の部分。別にOOPにあらずんばヒトにあらずと
言いたいわけじゃない。別にそうでなくてもいい。
ただ少なくとも、OOP言語だと大々的に名乗りながら
初心者(わら)に近づくのだけは、やめてくれ。
結構あれでOOPドキュな困った初心者を作ってしまうんで。

化石(わら)の話。
C++みたいなアーキテクチャの言語…つまり
C++を真似た(C++の直系の子孫は除く)言語って、
聞いたことないんだよな。

真似されてないってのは、それだけ、
使えない、あえていえば古い、アーキテクチャ
なんだと思うぞ。

アーキテクチャでいえば、むしろsmalltalk系とかのほうが元気だろ。

>>482
superが必要になる場合ってどんなとき？
静的リンクが前提なら不要なのでは？
例えばGoFパターンの中でそれが必要なのはどれ？
templeteで誤魔化しといわれても、そんな誤魔化しは
したことないから、不必要な批判をしているように見える。
もっと素直に実装できない？

>>484
>superが必要になる場合ってどんなとき？

ちょっと呆然とした。
なんでこんな質問をするんだろうこのヒトは？という意味で。

「必要」を言われたら、言語なんてアセンブラでいいぞ、という
恒例の話になるだけだ。
つまり、「いちいちsuperclassの名前をコピペするのって、
うざくないか？(反語)」と俺は言いたい＊だけ＊なのだが、
まぢでうざいと思ったことがないのか？

>例えばGoFパターンの中でそれが必要なのはどれ？

有るわけないだろ。「そんなC++ですら」記述できるように
最初からチューニングされてるんだからさ、GoFパターンは(笑)

>もっと素直に実装できない？

なんでそこで実装という一番卑近な部分しか思考できんかなあ？
以下、アセンブラ問答は、略。

なんてことはないよ。superclass名なんて
1つのクラスにまつわるソースを書く間に
たった一度書けば十分だと思わないのか、ということだよ？

ちなみに、コンストラクタ(とデストラクタ)がクラス名と同名だ、
という風変わりな考え方は、キャストとコンストラクトを
同一視しようという、C++のぶっ飛んだ(誉めてない)考え方を
反映しているという意味ではパズル的に面白いが、
実利的には却ってうざいだけだな。
コンストラクタ名をある一定の名(やその類似)にする
というほかの多くの言語が採った道のほうが、ずっと楽。
というわけで、最低3回(わら)書くのを1回に減らす方法がコレだ。

あと、ヘッダーにメソッド実装を書かないならば
メソッド実装の頭にクラス名がそれぞれ必要だという奴は、
C流の古典的なソース管理方法を流用した付け
(Javaで克服されてる)に過ぎないんで、
言うもあほくさいんで、さておく。

で、次にsuperclassの名を思い出す作業がしばしば必要になるわけだ。
これはデバッグのときにpublicとかどうとか直すのと
匹敵する手間だと思う(わら
ヘッダーをあっちこっち飛びまわらないとならんから。

>>484
すまん。くどくど長すぎた。
一言で終わる説明を今ヤット思いついたよ。

両親を「おやじ、おふくろ」と呼ぶ必要があるときってどんなとき？
…などと君は問うのか？

毎度毎度本名で呼ぶのか？メリット有るのか？
自分の両親は自分(プログラマじゃなくてそのclass)が
知っている(のでいちいちプログラマが教えなくて済む)
というものじゃないのか？

まぁそういう文化圏でも悪くないとは言えなくはないが、
さすがに迷子のアナウンスでは困るよな。
「みずほ保育園の3歳の高橋よしのり君のお父さん、よしのり君が迷子に
なっております」というアナウンスを出来ないことになるからな(わら


あと、リンク形態は全然関係無い概念だ。
なにも本当に親クラスが実行時まで未知な場合を
サポートしろっていう話を、しているわけじゃない。
#それはそれで欲しい機能だが話は別。つーかC++じゃ絶対無理だろ。
#ん？保育園の喩えは、どっちかってーとそれになっているか。まぁいいや。

>>482
お前みたいなキチガイがいると話こじれるんじゃ氏ね
オレもなー（鬱

>>485
おいおい、呆然とさせられるのはこっちのほうだよ。
アセンブラでいいという話に結び付けないでくれよ。
C++でオブジェクトをconstにできるのは、
オブジェクトを不用意に書き換えまいとする必要性があるだろう？
そういうレベルで話をしようよ。

「superが無いのはあまりにも痛い」とまで言うのだから、
必要性について聞くのは当然だと思うがどうか？
485を読む限り、あまりにも痛いというには無理があると思う。

>>488
だからー、煽りにのんなよ。

superはparentじゃないだろう。

日本人−人間−脊椎動物と継承しておいて、
よしのりくんと、そのお父さんはどちらも日本人で、
親子関係はCompositeパターンあたりで人間のツリーを構築して、
よしのりくんのお父さんを知りたいときはよしのりくんに対して
GetParentするというのが、今時のオブジェクト指向だよ。

さて、よしのりくん自身が、「自分の人種を自問自答する」
ことはあるのか？　そういうケースもあるかもしれないけど、
言語として専用のキーワードを割くだけの価値があるとは思えないな。

C++は常に悪いイメージを持たされているから、
こういうレベルの低い奴も批判的な意見を言い出し、
それがさらにC++のイメージを悪くして、
ネガティブスパイラルに陥っていると思う。

>>470
初期化はスタティックローカル変数に必要だよ。
じゃないと、呼び出す毎に代入されてしまう。

>>3
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
これか？

個人的には、MFCにマンセー。
動きはトロいし、バグはおおいし、EXEバカでかいし。
でもさ、サクっと一見機能満載のかっこいいアプリ作れるから、
上司ウケ最高。
おいらとしては、OOもC++もクソだけど、ＭＦＣマンセーです。

ただひたすらC++を叩くだけの人にろくな奴がいない事実

>>490
>superはparentじゃないだろう。
>よしのりくんのお父さんを知りたいときはよしのりくんに対して

おいおい。継承関係の「親子」と、人間関係の「親子」を混同するなよ。
たとえ話として親子という言い回しをしただけなのだが。
実際の親子関係の話じゃねーよ。
「関連」にはいろんな種類の関連があることくらい、知ってるだろ？
人間親子も(Instanceの)関連だし、継承親子も(Classの：もっともC++じゃ
ClassはFirstClassObjectじゃないんで、あくまで概念上の話だが)関連だ。

>さて、よしのりくん自身が、「自分の人種を自問自答する」
>ことはあるのか？　そういうケースもあるかもしれないけど、
>言語として専用のキーワードを割くだけの価値があるとは思えないな。

1:自問自答(Java風にいえばIntrospection)を不当に低く評価したがるのは
まさかC++人間の性癖なのか？それとも単に君がドキュなだけか？

というかC++だってIntrospectionが最近は有るだろ？
InstanceのClassを知る手段とかが有るじゃんか？

2:superというキーワードは正確にいえばIntrospectionではなく
せいぜいそのサブセットだ。単に親クラス名を匿名化する
というだけのキーワードだ。
自分のクラスの親クラスが何なのかをいったん問い合わせてから
そのクラスへメソッドを投げる、などという二段構えの文法には
ふつーの言語はなっていなくて、単に「thisの代わりにsuperを書く」
ことが出来るようになっているだけだ。

this.hogehoge(); //thisのhogehogeメソッドが呼ばれる
super.hogehoge(); //thisのクラスの親クラスのhogehogeメソッドが呼ばれる

それをいちいち、「ええと、thisのクラスはJapaneseであり
そのsuperclassはHumanだから…」と人間さまが考えて

Human::hogehoge();

とか書くことに、なんの幸せがあるんだ？
Japaneseクラスの親クラスはHumanであることは
既にコンパイラが知ってるというのに？

#多重継承で区別が必要というなら、多重継承してないときくらい
#superで楽させて欲しいと思う。

>>488
>そういうレベルで話をしようよ。

ああ。すまんすまん。それはそのとおりだ。

ただ、ifやforや関数が無くてgotoしか無い言語を使って
今時満足してる人に、「ifなんて必要なのか？」
と問われたときと、同じ衝撃を感じてしまったのだ、と
感想を説明しとくよ。

ちなみになんで汗なんてことを言い出したかというと、

>もっと素直に実装できない？

素直という単語に笑ってしまったからだ。
もしかして、「具体的に」書くことが「素直な」書き方だ、
などと思っていないよな？
もし思っていたら、それは汗云々な思考だ。
計算機言語の言語は抽象化(=不要な具体的記述を捨てる)して
便利にしていくという歴史だろ。

さて。汗の話はこれで済ます。すまん。
本題に戻ろう。

>>488
さて。

じゃあ問うが、javaにもsmalltalkにもrubyにも(わら) superはある
(蛇足だが単語と文法は違うがdelにも有る。inheritedという単語だ)のだが、
それらの言語におけるsuperの必要性と同様の考え方が
C++になんら影響をもたらさないと
あなたが考える(だよな？)論拠を、教えてくれないか？

「super」じゃなくてsuperclass名をいちいち書けなんて言われたら
上記言語のユーザーは火噴くぜ。
なぜかって？楽じゃないからだ。

ついでにもう少し直撃な話。

superと書けば、なにをどう呼べばいいのかの判断を
単に文法の問題として片付ければ済むのだが、
具体的にsuperclass名を書かないとならないとなると、
そこに書かれたclass名が妥当なのかどうか？を考えるという、
意味論の世界に足突っ込んじまうわけだ。

形式文法の範囲内でsuperclassのメソッドも呼べない言語だ、ということ。
他の多くの言語では出来ているにも関わらず、だ。

これでも痛くないのか？

蛇足だがdelのinheritedはさらに凄くて、
呼び元のメソッド名すらプログラマが考えずに済む。

procedure Japanese.hogehoge;
begin
inherited;
end;

と書くと、キーワードinheritedを引数なしで呼ぶことにより
同名のメソッドをsuperclassから探してきて
(といってもC++と同様にVMT方式なので、ディスパッチ処理が遅いわけじゃない)
それを呼ぶ、というところまでやってくれる。
何をどう呼ぶべきかを、文法レベルで確定することが出来るわけな。

これを便利じゃないとでも思うか？

アホか。
基底クラス名が複数回出現するときの常套手段。
class A : public B {
typedef B super;
...
};
またクラス名を書く回数が増えたって？
一回くらい増えたからってどうってことないだろ、いまさら。

多重継承や菱形継承を許しているC++ではsuperみたいなキーワードを
言語仕様で面倒見るわけにいかないもんな。

以上ですね(ワラ

多重継承など親クラスが明確でない場合のときだけ
superキーワード使用不可にすれば良い。

だからsuperキーワード必要無しの理由にはならない。
実際に多重継承と単一継承では使用する頻度は単一継承の方が多いんだし。

>>501
阿呆？

class A {
hoge();
}
class B : public A {
hoge();
}
class C : public A {
hoge();
}
class D : public B, C {
...
}
class E : public D {
...
}

それぞれのクラスでsuper::hoge()がどうなるか静的に管理しろってか。

>それぞれのクラスでsuper::hoge()がどうなるか静的に管理しろってか。

それこそ楽勝だろう？
それを言うならメンバ変数/関数の名前だって
コンパイラは頑張って(わら)どのクラスの奴か
解釈(=静的に管理:virtualも実装はさておきInterfaceは
コンパイラが静的に管理)してるわけだろう。
それとどう違うんだ？

親クラスが複数になってるクラスではコンパイルエラーにし、
そうでなければ一意に確定。
なんの問題がある？どんだけの手間がかかる？

実際、typedefという超簡単な手段で、
手作りで(わら)同じことが実現できてるわけじゃん？
言語仕様に入れるのは、実装の手間があとちょっと有るだけだぞ？
しかも無矛盾性も( >>498がまさにやってくれているが、
typedefで似たようなことが実現できることから判るように)証明済みだ。

そういや、ifやforすら言語仕様じゃなくライブラリで提供する
というおっかない言語も存在するよな。
でもだからって大抵の人(わら)は、ifが言語仕様じゃなくても
イイヤとは、あまり言わないだろう？そういう次元の話よ。

ところで今気づいたが、
>super::hoge()
って、superという単語でclassを指すもんだと思っているのか？
ふつーはinstanceを指すもんだよ。
#dynamic_castかなんかを使ったらsuper.hoge();とかを書けるようになるのかな？

>>499
>多重継承や菱形継承を許しているC++ではsuperみたいなキーワードを
>言語仕様で面倒見るわけにいかないもんな。

ところで質問なんだが、
菱形継承のときの心配を改めてする必要が、あるのか？
多重継承についてだけ心配すれば十分なんじゃないのか？

菱形継承のとき、どのclassを経由して継承したか？というのを
いちいち記述しないとならないor記述することができる
のだったっけC++って？
そんな機能は無かったと思うが？

さもないと、祖父母の代を考慮する(菱形ってことは
結局そういうことになるよな)なんてのは無意味だと思われ。

すげえな・・・モノホンか。
夏だなぁ。

ガムテープの接着麺同士を張り合わせた状態です。

str.replace('麺', '面');

>>503
言い方は気分悪いが、内容は同感。
superがないと継承関係の結びつきが強くなりすぎる。

503は別に当たり前のこと言ってるだけだし、一方の typedef 派も
typedef で別に何も困らないから至極まっとうな主張だと思う。
でも、

>>super::hoge()
>って、superという単語でclassを指すもんだと思っているのか？
>ふつーはinstanceを指すもんだよ。

C++ の文法ならふつー super::hoge() って方向で記述することに
なると思うけど。1から10までSmalltalk の話がしたいんなら、
Smalltalk スレでも立てれば、って気がしないでもない。

たぶん何を言ってもわからないのだろうけれど、
C++はsuperというキーワードを実装できなかったのではなく、排除したんだよ。
そこを履き違えないように。

ANSI規格化のときに、多くの議論が交わされ、多くのキーワードが提案された。
ISO/ANSIで規格化するということは、どこかの企業や個人が身勝手に決めたのではないと言うこと。
それまでに多くの激しい議論が交わされ、大変な時間がかかっている。
結果として、super、inherit、baseというキーワードは排除された。
その是非はともかく、少なくとも何らかの意図があって決められているのであり、
誰かが付け忘れたとか、実装できなかったとかいう話ではないだよ。

C++にsuperが無い場合
「基底クラスを指定するのにクラス名を書かないといけないなんてダサイ」

C++にsuperがある場合
「多重継承するとsuperが使えなくなるなんてダサイ。統一感が無い。C++ってやっぱり複雑。」

>>509
>C++ の文法ならふつー super::hoge() って方向で記述することに
>なると思うけど。1から10までSmalltalk の話がしたいんなら、

おいおい。だから、そんなC++「が」ふつーじゃない、
という話なんだってば。他の言語見まわしてみろよ。
superという単語をそういう意味で使わないことで
ナニを得するか？というと、単にC++内輪の互換性だけ、だ。

単に今、他と同じような意味のキーワードsuperが存在しない、
というだけのことだろ。
新しい(それなりにおかしくない)文法を「考える」脳が君には無いのか？
#採用しろとまで言うのは遥か先の段階だが。

>少なくとも何らかの意図があって決められているのであり、
>誰かが付け忘れたとか、実装できなかったとかいう話ではないだよ。

だれもつけ「忘れた」なんて言ってないよ。
その意図が変だ、と言ってるの。

規格は神様か？そりゃ今存在するその言語を「使う」時には
絶対尊重せんとならんが、そもそもその規格どうよ？という話
をしているときに、「でも規格ですから」じゃ話になるまいよ。

なんであんな美味しいものを排除しちまったんだか…可哀想に…
と言ってるんだよ。

>>511
いや、そこまで鞭打つ気は無いよ俺も(^^;

別に、他の案でもいいんだぜ？
継承するときに最初に書いたクラス名をsuperに割り当てる、とかな。

強く言うつもりは無いが、多重継承にしても
C++と違って新しい(笑)他の言語では、
「差別」をしているよな。
1つのメイン親と任意個のサブ親っていう感じ。
rubyのmoduleとかjavaのinterfaceとか。

全く同じ考えをC++に導入する必要があるとまでは言わないが、
せめて、(親クラスを作るときじゃなく)継承して子クラスを作るとき辺りに
差別を付ける仕掛けとかが有っても良かったんじゃないかな、とは思う。

一言でいえば、
>どこかの企業や個人が身勝手に決めたのではないと言うこと。
>それまでに多くの激しい議論が交わされ、大変な時間がかかっている。

単に、「今更引き返せなかった」というのが答えだと思う。
3年間(わら)の痛みに耐えられないだろうと判断したのだろう。

まぁその判断自体は正しいかも知れないな、
現存するC++勢力というものの存在を認めるからには(笑)

＞おいおい。だから、そんなC++「が」ふつーじゃない、

誰もC++が「ふつー」だなんて主張してねえって。

virtual typedef
が欲しい...

>>512
規格だから尊重しろなんてどこに書いてあるよ。
どうしてそういうふうに読めるのかさっぱりわからない。
大勢の優秀な人間たちが十分な議論の上で検討する場があったと言っているのだよ。

お前は当時交わされたであろう議論と同じモノを、
低いレベルでしているだけなんだよ。

>別に、他の案でもいいんだぜ？
>継承するときに最初に書いたクラス名をsuperに割り当てる、とかな。

マジかよ。superがどっちを指しているのか、ヘッダを見るまでわからないのか？
間違って別のsuperを指していたとしても気づかないことがあるぞ。
場合によってsuperが付けられたり付けられなかったりするのか？
そんな統一性の無い言語があっていいのか？

>>512

>>C++ の文法ならふつー super::hoge() って方向で記述することに
>>なると思うけど。1から10までSmalltalk の話がしたいんなら、
>
>おいおい。だから、そんなC++「が」ふつーじゃない、
>という話なんだってば。

すげー、ここまで堂々と「ふつー」の指している意味をすり替えるか・・・

typedef一行で済んでしまうものなのに、なんで予約語を増やす必要があるんだ。
それとも super.hoge() って書きたいのか？ そういう書き方を許す様にもできる
けどバカバカしいから誰もやらんだろな。

>お前は当時交わされたであろう議論と同じモノを、
>低いレベルでしているだけなんだよ。

一つだけ違う点があるぞ。
必要(わら)以上の過去との互換性は切っちまえ、と
考えた上でのこと、という点だ。

>マジかよ。superがどっちを指しているのか、ヘッダを見るまでわからないのか？

あ。そうか。たしかに辛いか。
だが、差別つき継承の考えを組み合わせれば、そんなに変じゃないぞ。
rubyみたいに「継承は実はあくまで一直線だ」という考え方も出来るし。

少なくとも「統一性無い」ってのは関係ないだろ。
どこを「統一」するかなんてのは考え方次第だ。

>>517
>>>C++ の文法ならふつー super::hoge() って方向で記述することに
>>おいおい。だから、そんなC++「が」ふつーじゃない、
>すげー、ここまで堂々と「ふつー」の指している意味をすり替えるか・・・

どこが摩り替えてるんだ？
C++における普通(の幾つか)なんて捨てちまえ、別の普通を持ってこようぜ、
と言ってるのだが？
ふつーという単語の意味は摩り替えてなんかないぞ。

>>518
>それとも super.hoge() って書きたいのか？そういう書き方を許す様にもできる
>けどバカバカしいから誰もやらんだろな。

うーん。それが馬鹿馬鹿しくないことは、前述のとおり、
他の多くの言語を見れば状況証拠として十分だと思うが？

てゆーか、「誰も」ってのは実は
C++言語に思考を規定された人間のことか？
ならばトートロジーだな。

C++はおもろいよ。

言語仕様が膨大なので、
とりあえず必要不可欠なことだけ覚えて使えばいいと思う。

＞うーん。それが馬鹿馬鹿しくないことは、前述のとおり、

多重継承が許される場合において馬鹿馬鹿しくないと言うのは証明されていませんが？

現実問題としてJavaじゃ実用にならない場面が多いんだから仕方ない。

STL, templateって、いつ頃から出てきたのですか?
私が初めてC++を触ったときは、そのような言葉を聞かなかったのですが。

>>524
少なくともSTLはC++より後です

>>525
そうだっけ？

例外処理、実行時型情報、templateときて、STLでしょ。
もうシンタックス多すぎて嫌。
他の言語に逃げました。

>>524
http://www.geocities.com/nobukichi/Stl/lec001.html
ここにいいこと書いてあるよ。

さらに補足すると、ANSIの標準化委員会は、STLを採用するために、
練りに練ったクラスライブラリをほぼ全部捨てたんだよね。

>>522
なるほど。ちと考えとくわ。反例がないこたぁないはずなんだが。

だが一方で、C++の愚直な(わら)やり方しか手が無いのか？という
問いにもまた、YESと答えるにはちと考えないとならんよな。

そりゃそうと、そこでの瞬間論点は、
superがclassを指すかinstanceを指すか、という話題
だったように記憶しているが、なんか変じゃないか？
まぁいいが。

>>524
templateはTurboC++2のころはまだだったっけ(笑)
するってーと、10年は経った…っけ？

>>526
ナイスすぎる。「Standard」TLという
C++につけるライブラリの仕様は、そりゃC++より後だろう。

>>527
というか、その辺のもの一通りを(しばしば最初から)搭載してて
#あ。templateは無い奴が多いが。
なお大してでかくない言語仕様な言語が多数有るわけで、
C++がちょっと定方向進化説の体現者になっちゃってるのは
間違い無いと思う…

>>523
別にC++ or Javaという白黒どっちかしか無いわけでもあるまいし…

template が使えるメジャーな言語ってだけでも C++ の存在意義があるんだけどなあ…(ﾎﾞｿｯ

実際のところ>>511のような結論にしかならんと思うがな。

悪いけど
>>いや、そこまで鞭打つ気は無いよ俺も(^^;
>>別に、他の案でもいいんだぜ？
これはまったく信用できないな。
多重継承を解決しない限り、どんな仕様にしても直行性はなくなるよ。
もちろん、「superがないと不便」には諸手で賛成なんで、
それを乗り越えて「まあ変だけど、許してちょ」的な仕様を
stroustrapが考えたのなら、俺は許すけど。
どうやってもコンセンサスはとれんと思うからこそ、typedefで適当なんでないの。

javaがテンプレートをサポートするみたいだけど
SUNは自社のみでSTLもどきを実装する気なのか？

C++を完全制覇している人は世界に何人くらい
いるのであろうか

多重継承がある以上、プログラマが継承図を意識するのは避けられないので、
superなんかあっても役に立たないと思うんだけど。

>>533
ANSI C++ 仕様が完全に実装されてるコンパイラって地球上に存在するの?

>>531
要は、継承元の複数のクラスそれぞれに対応した
識別可能なエイリアスがつけば、いいんじゃなく？
super(0) super(1) super(2) とか(わら

あと、前述したように、継承の順序みたいな概念、でもいいな。

ところで直接関係ない話だが、ソース使いまわすのを
最初から予想している場合は、手打ちでtypedefを
入れて回っているわけか、ふつー(笑)のC++erは？
使いまわすってのは、superclassがどれなのかってのを
字面で書きたくなくなる動機の1例としてだけどさ。

----
ところで話は飛ぶが、やっぱりメタクラスは欲しいな。
もどきでもそれなりに役立つから欲しい。

VC++なんかは一見メタクラス的機能のように見えるマクロとかを
提供してるけど、あれってどうやってるんだっけ？
(今手元に処理系がないんで見れないんだが)

>>536
＞あと、前述したように、継承の順序みたいな概念、でもいいな。

よくねえ。
class A;
class B : public A;
class C : public A, B;
みたいな継承をサポートできるかい。

＞使いまわすってのは、superclassがどれなのかってのを
＞字面で書きたくなくなる動機の1例としてだけどさ。

これにより、536はOOPを欠片もわかっていない厨房と言うことが確定しました。

>>533
STLを含めるとほとんどいないだろうけど、
言語としての純粋な部分であれば、
ほぼ完全制覇したというひとは多いだろう。

C++マスター度チェックリスト

□コピー、参照、ポインタの使い分けには自信がある
□デストラクタは必ずvertualだ
□constにできるオブジェクトやメソッドは全部constにしている
□クラスには必ずコピーコンストラクタを書いている
□Ｃ言語形式のキャストは禁じている。
□vectorで２次元配列を組める
□deleteはほとんど使わない
□std::exceptionを継承していない例外は投げないことにしている
□イテレーターの動きに不安を感じることはない
□どのメンバをprotectedにするか考えながらクラスを設計している
□friendを使うとクラスの隠蔽度があがると思う
□例外指定をマメにつけている
□virtual継承は時々使う

他に何かあったらよろしく。

○　コピー、参照、ポインタの使い分けには自信がある
○　デストラクタは必ずvertualだ
○　constにできるオブジェクトやメソッドは全部constにしている
○　クラスには必ずコピーコンストラクタを書いている
△　Ｃ言語形式のキャストは禁じている。
○　vectorで２次元配列を組める
×　deleteはほとんど使わない
×　std::exceptionを継承していない例外は投げないことにしている
○　イテレーターの動きに不安を感じることはない
○　どのメンバをprotectedにするか考えながらクラスを設計している
○　friendを使うとクラスの隠蔽度があがると思う
×　例外指定をマメにつけている
×　virtual継承は時々使う

幸せになれますか？

訂正

×　デストラクタは必ずvertualだ
○　デストラクタは必ずvirtualだ（藁

>>539
あなたかなりスキル高いね。
うちの会社に欲しいよ。
deleteはvectorやauto_ptrを駆使して丹念に消そうね。

>>537
>class B : public A;
>class C : public A, B;

同じクラスを2回継承すること(を許すこと)が
そもそもヤバゲだと考えるほうが健全じゃねーのか？

>536はOOPを欠片もわかっていない厨房

はぁ？superclassはsuperclassだろう？
それが概念として頭んなかで抽象化されてねーのか、あんたの頭では？

>>538
>デストラクタは必ずvirtualだ

てゆーかvirtualでないメソッドは少なければ少ないほうが幸せ。

>>529
たしか、STL の起源はC++では無かったと聞いてます。

>>541
> deleteはvectorやauto_ptrを駆使して丹念に消そうね。

そゆことか。auto_ptr はコンテナに向いてないからほとんど
使わないなあ。誰がdeleteすべきか割とはっきりしてる場合は
気にせずdelete使てる。
それと寿命の短いやつをnewしない構成にするように心がけてまんす。

つーか、『約束事を増やさない』ってことが大事だなっ、て最近思っ
てる。クラス数の爆発を防止するためのデザインパターンとかはいろ
いろあるけど、こっちのほうも何かないかなあ？

やっぱりlispが起源?

class variant_container {
　std::vector<std::auto_ptr<my_variant_class> > m_x;
};
な感じで
m_x = std::auto_ptr<my_variant_class>(new my_variant_class(my_variant_class::data_type_x));


逝ってヨシ？

push_back()だ。
鬱氏

>>544

それは逆で、コンテナに向いてないポインタをauto_ptrにするのです。

>×　deleteはほとんど使わない
>×　std::exceptionを継承していない例外は投げないことにしている
>×　例外指定をマメにつけている

これを見ると、あなたは例外が弱点ですね。
deleteがあると例外が出たときにリークします。
catchの中でthrowしたときにどうなるのか、
コンストラクタ中で例外が発生してデストラクタが呼ばれないときにどうするのか。
しかしすべてが自動変数ならそういう面倒なことは考えなくて済むわけです。
そうなると、今度は例外を気軽に使えるようになってきます。

寿命が短いものは自動変数にするのが一番ですが、
どうしてもnewしなければならないときは、
auto_ptrを使ったり、proxyパターンで実体の寿命をコントロールしたりするのですよ。
deleteが無ければリークなんてしないはずですからね。

STLの起源はALGOLだと言われているよ。
ALGOLを使ったことが無いからわからんけど。
でもSTLの原型を作ったHPの技術者は
ALGOLではなくsmalltalkを参考にしたらしいね。

>>548
auto_ptrってさあ、いわゆるスマートポインタとちょっと違って

std::auto_ptr<int> p(new int(32));
{
std::auto_ptr<int> p1 = p;
}
//ここでは？

なんてやるとスコープを抜けた時点でpは死んじゃってるじゃない。
これにからめてコンテナには向いてないって記事を読んでそのとき
は納得してたんよ。詳しくは覚えてないけど。
参照カウンタ付きのスマートポインタを自前で用意してコンテナに
使うのはやったことあるな。

例外は確かにあまり使わない。使ったとしても狭い範囲でcatchする
ものばかりで大域ものはやったことないな。だから投げるものはなん
でもいいや、ってことになっちった。

Eiffelのsuper (Precursor)

class A feature
　hoge is
　　do ... end
end

class B feature
　hoge is
　　do ... end
end

class C inherit　　　　--継承
　　　　　 A rename hoge as bar　　--名前変更
　　　　　　　redfine bar　　　　　　　 --再定義
　　　　　　　end
　　　　　 B redfine hoge
　　　　　　　end
feature　　　　　　　　--public: みたいなもの
　bar is
　　do
　　　Precursor　　　　--A::hoge
　　end
　hoge is
　　do
　　　Precursor　　　　--B::hoge
　　end
end

多重継承があってもsuperを実装できると思う。
Eiffelも前はPrecursorがなかったので
同じクラスを２つ継承するという変なことをしていた。
C++にもsuperがあったほうが便利だと思う。

>>551
自分で名前変更、再定義しなきゃいけないならtypedefと同じなんじゃねえの？

>>548
>しかしすべてが自動変数ならそういう面倒なことは考えなくて済むわけです。
>そうなると、今度は例外を気軽に使えるようになってきます。

こういう考え方をしないとならない／しがちになっちゃう
というところも、ちょっとC++の苦しいところかな。

ガベコレがない言語でも、
ObjectiveCの(というかOPENSTEPの)NSAutoReleasePoolオブジェクト
のような戦略も有る。

ところでC++って、catch(例外食らったらここに来る)はあっても
finally(例外有っても無くてもここに来る)は無いって、ほんと？
だとすると、それもまた「例外を使いにくくする」要因の一つになる。
例外だろうがそうでなかろうが解放処理が必要、という場合に
それを書くうまい場所がなくなっちゃうから。

>>553
言語仕様ではfinallyをサポートしていない。
が、独自拡張でfinally(または等価な機能)をサポートしている
処理系は多いと聞く。
俺はVC++使いだがVC++にはfinallyあるよ。

class A{public: hoge(){...}};
class B{public: hoge(){...}};

class C:public A,public B
{
public:
　　A::hoge(){super(); ...};
　　B::hoge(){super(); ...};
};
みたいにできたらいいなあと思っただけ。

C obj;
obj.hoge();
どっちが呼ばれるか不安になるぞおい。

C++は、もう破滅寸前。
ここらでSTLに挫折した、全体の９５％相当のプログラマが
不買運動を起こし、消滅します。

ありがとうC言語！そしてC++さようなら！（^_^)また会えるといいね！

http://piza.2ch.net/test/read.cgi?bbs=tech&key=995820118&ls=100

>>555
class C:public A,public B
{
public:
　　hoge() {A::hoge(); B::hoge(); ...}
};
みたいにするんじゃないかなあと思うんだが。

>>554
>が、独自拡張でfinally(または等価な機能)を

「賢い仕様策定者とやらの所業がそれか？」と
思わずにはいられません…

>>555
>class C:public A,public B
>{
>public:
>A::hoge(){super(); ...};
>B::hoge(){super(); ...};
>};

それはC++系(わら)文法な傾向の言語では>>556が指摘するように
無理があると思う。それよりはsuper.hoge()っしょやっぱり。

>>559
＞無理があると思う。それよりはsuper.hoge()っしょやっぱり。

これでも>>556と同じ問題はつきまとうんだけど。

あげ

Ｃ＋＋はオブジェクト指向Ｃ言語。

オブジェクト指向は感覚だから、いくら理論書よんでもクラス作れる
ようになれない。だからＣ＋＋を使えるようにもまれない。

そういう人は多分、ＪＡＶＡでも勉強して、SUNの標準クラスに接して
クラスってどんなもんか肌で最初に感じるべし。

>>553
>finally(例外有っても無くてもここに来る)は無いって、ほんと？
>だとすると、それもまた「例外を使いにくくする」要因の一つになる。
>例外だろうがそうでなかろうが解放処理が必要、という場合に
>それを書くうまい場所がなくなっちゃうから。

「例外だろうがそうでなかろうが解放処理が必要」な場合は
デストラクタでリソースの開放を行うのがＣ＋＋のスタイル。

C++に慣れていると、リソースの解放を自動化できず
finallyで、いちいちコードを書かなければならない
JavaやDelphiのほうが不便に思える。

Ｃ言語って、何に優れている言語なの？

>>564
高級アセンブラという捉え方もある。
その意義がわからない人はJavaでもやっとけばいいと思う。

高級アセンブラとして使わないのならC++なんて簡単だろ。
新しい言語覚えきるのにはそら2､3ヶ月ぐらいの辛抱が必要ってもんだぜ。
VBとかみたいに2，3日で覚えられるものとは違うんだよ。
ちなみにオブジェクト指向が分からないならJavaだろうと何だろうと
無理ってもんだ。それに必要となる知識は言語の知識とは別だからな

>>563

Javaにもfinalizeつーデストラクタあるよ。ただ、実行タイミング
はＧＣが動く時だから、予想不可能だけどね。

C++からVC++へ移行する方がもっと　むずい気がする

>>1

＞オブジェクト指向やＵＭＬを理解し
＞巨大な仕様のＣ＋＋を理解し
＞モノを作るのは骨が折れます。

Ｃ＋＋やJavaやRubyなどのＯＯＰ書くのに、
ＵＭＬやデザインパターンを知ってる必要
なんか全くないぞ。これはよくある誤解。
ＯＯＰはひらめきと感覚の世界。実際オレは
それしか使ってないし。

>>569
クラス設計には経験とセンスが必要なのは確かだけど、だからといってデザイン
パターン不要というのは早計でしょ。デザインパターンというのは成功したクラ
ス設計のカタログ、将棋で言えば定石みたいなもの。よほどの天才は別として、
一般にはまず定石を押さえて、その上で自分の問題に取り組んだ方が結果を出し
やすいよ。

あと UML やデザパタに関しては、他人と意思疎通を図る際の共通言語、という
意味もありますね。長々とクラスの関係について説明したり、ソースコードを読
む代わりに

「これが Abstract Factory」

の一言で済めば、その方が効率が良いわけで。

>>569
>ＯＯＰはひらめきと感覚の世界。実際オレは
>それしか使ってないし。

「私は不勉強な井の中の蛙です」
と要ってるのと同じ。

>>567
>Javaにもfinalizeつーデストラクタあるよ。ただ、実行タイミング

javaのfinalizeはデストラクタの代わりには使えんだろ。
・実行のタイミングが分からない
・実行される保証もない
・もし特定のタイミングで動かそうとするとGCを動かすコードを
　書かなければならないので、結局finallyに頼る羽目になって無意味。
・特定のオブジェクトのデストラクタを動かすためにいちいちGCを動かすのは
　パフォーマンスが悪すぎる。

＞「私は不勉強な井の中の蛙です」
＞と要ってるのと同じ。

そうかな？だれも関数作るのだって、みんな図なんて書かないし、
デザインパターン使わんでしょ。クラスだって結局ある共有した
データを持ったメソッドの集まりなんだから、同じだと思うけど
ね。

ただその代わりといっては何だけど、人が作ったいろんなクラス
読むのは大事だと思うな。ＭＦＣ分析したりＣ＋＋で書いたゲー
ムを分析したりね。実際、関数を感覚的に作れる様になるより、
クラスを作れる様になる方が、ずっと時間かかると思うけどね。
でも、慣れればホントＵＭＬもデザインパターンもいらないと
思う。

ＵＭＬもデザインパターンも人によっては大変有益だと思うし、
役に立つ人もいるんだろうけど、人によってはオレみたいに、
いらない人もいる。

実際、ＳＵＮの標準ＪＡＶＡライブラリー作った連中や、ＳＴＬ
作った連中に聞いてみたいな、どこまでそういうの使ったのか。
多分人それぞれだと思うが。

人が作ったソース読んで参考にしてるならデザパタのいくつかを自然に
あてはめてるかと思われ。ただ、MFCはあまり参考にならんかと。

＞人が作ったソース読んで参考にしてるならデザパタのいくつかを自然に
＞あてはめてるかと思われ。ただ、MFCはあまり参考にならんかと。

ＭＦＣは反面教師として使わせていただきます。ほとんどはＡＰＩの
ただのラッパーだし、メッセージの流れをカプセル化してる
分、非常に応用しにくい設計だと思います。WINDOWSはＡＰＩ直に
使った上、Ｃ＋＋を使って自分でクラスを作りながら開発するのが
自分的にはベスト。

>>573
だからそれが井の中なんだってば。
たとえそれで凄い腕前になれたとしても、他人と意思疎通ができんだろそれじゃ。
それともソースコードだけで語り合うとかってイキがるつもりか？

>だれも関数作るのだって、みんな図なんて書かないし、
>デザインパターン使わんでしょ。

なぜそんなことが言いきれるんだ？それこそ要らぬお世話だ。

それにさ、やはりObjectは「かたち」と相性が良いよ。
「なんだかこんな感じ(のクラス)」とかの「かたち」を思い描いたり、
あまつさえそれを実際に絵に描いたり、ってのをついついやっちゃう人が
むしろ多いんじゃないかと憶測する。
それの統一共通語版を作ろうってのが、デザパタやUMLだ。
#デザパタは統一以外の面も有るが、ここではさておく。

あと、日本人って抽象化が苦手ですねー(ぷぷぷ
抽象思考になると途端に酸っぱい葡萄モードになる奴が多い。
そんなんだからいつまでも根っこの部分で欧米の後塵を拝してるんだな。

>>574
そうそう。デザパタは「新しい」テクニックを示してるわけじゃない。
「既存の」テクニックに、単に、名前をつけただけ。
UMLだって同じ。「既存の」構造を(特定プログラム言語を使わずに、でも自然言語も使わずに)
さくさくっと書き表すためのもん。

>>576

＞それともソースコードだけで語り合うとかってイキがるつもりか？

なんかムキになってるだけで、全然説得力ないんだけど。

オレ、ＳＴＬ、Ｊ２ＳＥ、Ｊ２ＥＥ、使うとき、ＵＭＬもデザイン
パターンも使ったことないぞ。クラスなんてパブリックインター
フェイスとその使い方示せば十分コミュニケートできるよ。JAVADOC
のようなね。

あと、勝手に飛躍してるが、Ｃ＋＋使うのにＵＭＬもデザイン
パターンを知ってる”必要”がない、ってオレは言ったんだけど。
いかなる条件でも不要とは言ってないぞ。一人でＣ＋＋で開発
する目的のヤツもいるし、勝手に集団のプロジェクトで使うって
前提条件作って反論しないように。

うーん。別にデザパタ、肯定否定どちら派でもないけど
肯定に片寄りすぎて無理にデザパタを乱用した汚いソースも結構あると思う。
デザパタって万能じゃないんだよね。実装はかなり汚いから
実の有るところをほどほどにとっていけばすっきりしたソースが
かけるとおもうけども。。

やっぱり，複数人数でやるときにはデザパタとUML（とそれに類する記法）は便利だよ。
だいたい，工業としてのソフトウェア作製を考えた場合，そこは無視できない。

立場によって肯定・否定があってもいいとは思う。

しかし，将来会社に入ってプロジェクトに参加する可能性のある若者には
「最低限の教養だから身につけておいたほうがいい」と言いたい。
言っておくけど，「信奉せよ」ってんじゃないよ。

また，577のように知っていながら批判的な態度を取ることも
結局は「知っているからこそできること」であるわけで，
より高度な概念に到達するためには，基礎知識としてその
批判対象を知ってなきゃいかんわけで。

うーむ。C++にあまり関係ないね。

577てデザパタちゃんと分かってるのか疑問に感じる
576も言ってるが既存のテクニックに名前を付けただけなんで
俺はデザパタ使わねーと言っても違和感がある、普通にプログラム作ってれば
デザパタのいずれかに当てはまるパターンは使ってるはず。

それでも使わねーぞと言うのって昔のスポコンマンガみたいに根性だけで（理論なしで）
プログラム作るぞ(ﾟДﾟ)ｺﾞﾙｧ!!ってふうに聞こえる。今時スポーツでも理論が基礎になってるし
（例えば世界一速いモーリスグリーンとか）それを無視しようとするのは進歩するのを拒んでる
ようにさえ見える。こういう奴ってsexでも腰振って出して終わりーってワンパターン野郎って
感じがする。

パターンは自分で作るとこにロマンがある。

別にそれが結果的に既存のパターンに当てはまったって良いわけ
で。音楽理論と作曲みたいなものだね。曲を作れば音楽理論に
当てはまるが、曲を作るのに必ずしも音楽理論を知ってる必要は
ない。ジョンレノンなど、音楽理論をベースにせず曲を作る連中
は腐るほどいる。ルールに縛られたいってのは、二流の証なんじ
ゅないかな。才能あれば、自由に発想したいって思うはずだし。

>>581
たかが手段でロマンを語る人が現れた。びっくり。
仕事と妄想は区別しようね。納期優先だよ。

人の英知をかっぱらうのが一番手っ取りばやいわけで。
システム開発なんてのは、えらそうに言っても結局のところ
人の英知のかっぱらいの上にちょっと使用毎の差分だけデコ
レーションかけるだけなわけで。

趣味は家でやるべし。

オブジェクト指向は実装よりも分析設計の方にロマンを感じるが。

>パターンは自分で作るとこにロマンがある。
>別にそれが結果的に既存のパターンに当てはまったって良いわけ
>で。音楽理論と作曲みたいなものだね。曲を作れば音楽理論に

車輪の再発明しといて自由に発想ってのがおかしいんじゃない？
既存のものをパターン化して知識として持ってれば
無駄なところで創造力浪費しなくていいわけだし。
パターン化できないところに力を注ぐべきかと。

>>584
>車輪の再発明しといて自由に発想ってのがおかしいんじゃない？

おいらの立場としてはあくまで中立だけど、世の中にあるすべての
ものが車輪の再発明だけではないと思うよ。
581 が言いたいのはデザパタだけでは満たせない部分を指している
ような気がするのだけど、深読みしてるかな。

とりあえず知識として持っておくのは賛成。
全面的に肯定すべてデザパタで統一するにはデザパタ自体に
それほどの能力が備わっていないように感じるので否定。
デザパタはまだ信頼できる完成段階ではないような気がする。

>>582

それじゃ、ロボットだよ。多くの経営者はそんなロボット君
は求めてないと思うぞ。仕事仕事っていうけど、多くのいい
プログラムは仕事の外で書かれてる訳で、それを普遍的に押
しつけるのは、おかしいな。あと日本にはあまりいないが、
技術的なフロンティアな事やってる人たちってそんなロボッ
トみたいな発想で、物作ってないと思うぞ。これってＳＥ、
ＰＧに限らず、どんな物づくりにも言えるんじゃないかな。
外面、クールでドライなビジネスライクな部分も必要だけ
ど、やっぱホットでウェットなホビーライクな部分って重
要だと思うぞ。押しつける気はないけど。

だからここでも何度も言われてるようにデザパタはカタログ化した
ことに意義があるんだって。あれで全て設計しろなんて誰も言ってない。
ここでデザパタという単語である程度の共通認識ができていること自体が
その一番のメリットなんだからさ。
もちろん詳細設計のテンプレートとしても使えるけどさ。

>>580,587
わしも大体そんな思い

Design patternを知ったのに、
設計初段階の思考に影響を受けない人間ってこの世に存在するのか？
ああいったpattern区分がある事を知っている、これがframeworkの強さじゃないか。

何でもdesign patternで、無意味なGoF風class連発する奴も考えものだが。

>>580
そうそう。それそれ。デザパタ使うのと使わないのの差ってのは、
つまりは或るパターンを「その名で」呼ぶかどうかの差でしかない。
だから、それを使わないってことは、他人(人間ね。計算機じゃなく)との
意思疎通はどうよ？という話にしか、ならんわけ。

ただし、
>>582

ロマンは大げさだが、たしかにGoFの23パターンだけで森羅万象が表せるはずもないんで、
新たなパターンを見つけて名前つけるっていう作業をやりまくってる連中も
一方で存在してるのは事実。
将来的にはその彼等の研究成果のごく一部(藁)は、主流派に合流するんじゃないかなあ。

つまり、デザパタっていうもの自体は、まだ「終わった研究」ではない、ということ。
最終(?)的には、パターンの「淘汰」みたいなことが起きるんじゃないかと希望的に観測。
つまり成熟やね。

ところでパターン自体もパターン間に類似性や包含性があったりして、
結構親戚関係があるよね。だから、23個にしても、単に23個の独立したAlphabet
みたいに扱うんじゃなく、意味の関連性が相互に有機的に存在するようなモノなのだろう。
Primitiveはきっともう少し「下」に有る。それを発掘することがどれだけ有意義かは微妙だとしても。

デザパタ…というよりGoF23パターンは有用だよ
広く一般に知れ渡ったからね（ホントか？と、自分でツッコム）
話の中でxxxパターンという言葉を使うだけで
構造を言い表せる共通語になるのが一番の強み
UMLも一般に受け入れられていること自体が意味のあることだし
結局、C++も広く一般的に使われているから自分もつかう

っつーか、僕って長いものに巻かれまくりかも

デザインパターンのプリミティブか。そういや２年ぐらい前のＣマガの
デザインパターン入門って連載の最終回が結構いいこと書いてたよ。
オブジェクト指向のエッセンスを最初にまとめて、それらが
GoFのそれぞれのデザインパターンをどう構成しているとか、
GoFの各パターンがどう関係し合っているかとかまとめてた。
ttp://www.try-net.or.jp/~tatefuku/t_20000605.html
ですすめられてたんで先輩からバックナンバー借りて読んだん
だけど、なかなか良かったよ。

>>591
Cマガのその頃の一部(藁)の記事と、
あと往年のDDJJの一部(藁)の記事とは、
すごくいけてた。あーいう文章がもっと沢山出てきて欲しい。

というわけで、よいwwwサイト有ったら教えてくんm(__)m

俺の考えるクラス作りの方法。

たとえば、ＪＡＶＡでboolean型のフラグを使ってると
して、そいつが誰がいつ状態を変えたのかわかるように
しようと思ったとき、いつものごときクラスを作る。
こんな感じになるだろう。

１。セッターゲッターを作る。
２。変更時に、呼出クラス、メソッドの名前を登録する。
３。標準出力に状態を常に吐き出したい時は、セッター
に標準出力に出力する用にする。
４。常に出力されるのは、使えないから、コンンストラ
クターで指定できるようにする。

こんな感じで作っていく。あといろんなクラスを作って
言って汎用性を持たせる為に、どんどんabstractで
外だしにし、コードのダブりをなくす。

あと関数は出来るだけstatic 作るようにし、(つまり
単発で使え、他に一切影響の与えないようにする為)、
staticなものは、JavaのCollectionsやArraysのように、
staticメソッド集のようなクラスに入れる。

これが、俺の大まかなクラスの作り方だが、デザイン
パターンなんか使ったことないし、必要性も感じない。
設計時だが、どうやって抽象クラスを最初にモデルする
時は、思い浮かぶものを作ればいばいいとしか言いようが
ない。でも最初から抽象と実装のコンボはテストしにくい
ので、大概最小は１クラスで実装し、あとから抽象化する
というステップを意図的にしている。

俺的に、厳密ではないが、単純に言えば、クラスなんて
所詮複数インスタンスを生成出来るＣで言うモジュールを、
複数インスタンス生成できるようにしただけのものなんだから、
デザパタだのＵＭＬの必要性を感じないのである。
それでもそれなりの評価は得ている。

あと関係ないが、オブジェクト指向が理解されない理由は
このコード表現をデザパタ、ＵＭＬなどに特別視されす
ぎる事にあると思う。同じグローバル変数を共有出来る関数群、
つまりモジュールの一種でそれを、複数インスタンス化する
ことができ、時には構造体的に使うことができる、程度に
解釈すれば全然難しいものでもなんでもないと思うぞ。

>解釈すれば全然難しいものでもなんでもないと思うぞ。

オブジェクト指向よりあなたの日本語の方が難しいです。

デザインパターンの内容とその理念を理解した上で使わない使う必要を感じない
というなら、それでも良いと思いますよ。いわゆる天才には、必要ないのかも
しれません。

とはいえ、コードの構造を他人に伝えるプレゼンテーション集としても有用
なので、もし読んでいなければ精読する事をお勧めします。

少なくとも上の発言はわかりにくく、意図を理解するのが相当難しいですよ。

593って相当頭悪そうだね

>>581
和声学を踏まえた上で一流の作曲家なんて、
クラシックの世界にはいくらでもいまする。

>>581
昔から言われるように、最高の書き手は時にレトリックのルールを無視すること
がある。ただしそうした場合には、ルール違反を補ってあまりあるメリットがその
文を通して読者に伝わるのが通例だ。それに確信が持てない限り、おそらく書
き手はできる限りルールにしたがおうとするだろう。
-----William Strunk and E.B. White, The Elements of Style
(『プログラミング作法』からの孫引き)

隊長、>>593の解読に成功しましたっッ！　要約すると、

「プログラムを作る時は原則として一つの巨大なクラスに
全部の関数をつっこむ。例外としてグローバル変数を管理
するためのクラスやユーティリティ関数を集めたクラスを
作ったりもする。あとabstructというのもよく分からない
なりに使ってみた。」

という意味ですっッ！

>>593
実装(具体的表現)とパターンつーのは異なるロジカルタイプに属するんだから、実装で
パターンの何かを語ろうとすることにそもそも無理があると思われ。

>>581
そんな貴方には、芭蕉のことばを贈ろう。
「格に入れば狭く、入らざれば邪路にはしる、出て初めて自在をえべし」

パンピーはまず基本を押える。
だけどそのままでは型にはまりすぎるので、
基本を押えたうえで、もし必要ならば、それを崩してみる。
初めっから、基本を無視するのはよくない。

よほどの天才は別だろうが。

>>601
えべし -> うべし

じゃないのか？

C++プロジェクトの設計段階にかかる時間は、3倍です。
継承すべきもの、すべきでないものを正確に決めるためです。
それでも、判断を間違えます。

>>604
Javaだと5倍なので、まだマシです。

ＯＯＰを学ぶ順番は、
「データ構造、モジュール→クラス構造→デザインパターン」
と書くと、賛成も反対も無いのは何故？

>>604
それって、分析が出来てないからじゃないの？

クラス構造って何？

クラスの使い方と書いた方が良かったかな？

switchﾊﾞｶでｽﾏｿ。
OOPってトップダウンで設計するためにやってきたんでしょ。天の声で。

C++は特殊な構文がやたらと多すぎる

でも多くの場合、「なんでもトップダウンで設計できそう」という
ダメな幻想をあたえただけかも。

トップダウンといや、、
責任駆動設計(responsibility-driven design)てのがあったな。
CRCカードで設計してる人って漏れは見たことないけどな。

実際のところ
C++を効率的に運用できるスタッフが少なすぎる
言語仕様としてのキャパシティはともかく
今のところ企業としての利潤追求の旨みの少ない言語
小さな会社は、C++を使ってC的な組みかたしてる所がほとんどだし
それが正しい

OOPイコール トップダウン、なのか？
漏れはそういう印象はあまり受けないな。

トップダウンだと思いこんでしまう人は、単に以下の経験が少ないだけ
なんじゃないかと憶測＆揶揄したいのだが、どうよ？

1:気楽にソフトを作ったことが無い。OOPつーたらエンプラとかの大規模ソフトを「作らされた」ことしかない。

2:ライブラリを作った事が無い。特に案件専用じゃない汎用寄りのクラスのライブラリを。
これは方法論「Drop」でも言及されてることだが、これをやったことが無いってのはつまり、
そのプログラマは単なる部品ユーザーでしかない、ということを意味する。

むしろボトムアップちゃうの？

クラスライブラリを作る/使うの両方を経験すると、
それからいい仕事ができるようになるのかな。

誰かのを使うときに「何を考えて作ったのか」を想像しやすくなるし、
誰かのために作るときに「どう使われるだろうか」を想像しやすくなる。

これを端的に表す言葉を希望

鏡の向こうは志村けん。

>>612
の言うトップダウンってどういう意味だろうね。
Abstruct→Concreteってこと?

>>618
2点。

スレタイを「なぜ職業プログラマはあんなに気難しいのか？」にすれば良かったね

>>617
同床異夢！
…違うなあ。むしろ逆か。鬱出汁脳…

つーかー！
…それも全然違うなあ…

思いやり！
…どうよ？…

…というわけで、>>618がサイコー！ということで、募金活動は終了。

C++での委譲の実装ってすごく面倒に見えるんだけど、
どんなときに委譲って使うのですか？
オブジェクトが受けたメッセージを別の オブジェクトに丸投げ
するってなんか意味あるのですか？
メッセージの分岐点として使うのですか？
使う場面が、頭悪いので創造できないです。
委譲そのものが分かってないのかも。ﾄﾎﾎ。

>>622
現実問題として継承が使えない場合に逃げとして使うことが多いかな(藁

>>623 レスありがとうございます。継承が使えない場合、、
これも想像できない。鬱氏。

>>624
逃げとしての一例をあげれば、class Fax と class Phone があって
それぞれインターフェースではなく実装付きで定義されている場合に、
多重継承を使わずに FaxPhone を作れと言われたらどっかで委譲することになる。
Java では実装の多重継承はできないし、
C++ でもライブラリの制限でダメということがある(C++BuilderのVCL)。

>>623
漏れはむしろ逆だな。
委譲するのが適当でない、と思われるときに継承を使う。
実装上、そのほうが楽になることが多い気がするから。

>>625
既存の(自作でない)class Faxとclass Phoneがある場合は、そうかも。
FaxPhoneとして使うことを想定していないFaxなりPhoneを基底クラスと
して採用することは不適当と思う。意図せずに(副産物として)作られた
汎用基底クラスなんて信用ならない。将来的に破綻しそうな気がするしな。

>>625-626 レスありがとうございます。
なるほど、アフォな私にもよくわかりました。

継承は最小限に
でもツボにはまった使い方をすればパワー倍増

「オブジェクト指向の goto」とどっかに書いてあった

話の流れを無視する発言ですが、オブジェクト指向の良さが実は解りません。
クラスでカプセル化と関数でカプセル化の区別がつきません。

ウィンドウプログラミングには楽そう、とは理解していますが、
それ以上ではありません。WIndowsプログラミングはしたことありません。

僕はC++は便利なCとして使っています。Javaは食わず嫌いで絶対勉強しないでしょう。
Perlは美しい言語だと思います。Rubyはどうでか？

>話の流れを無視する発言ですが、オブジェクト指向の良さが実は解りません。
よくデキテリャなかなかいいよ。
javaの話で申し訳ないが、「javaのプログラマーがいない」というのは嘘。
いないのは「オブジェクト設計できる人」という話題になった。

機能が動くよーにコード作るだけなら何でもいいんだけど、オブジェクト
の良さをとなると、システム設計のセンスが必要とされるので難しいんだろうね。

ふつう、１０人ぐらいの規模でソフト書いていれば、わかると思うけど、
上流行程や、メンテをやってりゃ良さがそのうちわかると思いますよ。
でも
>Javaは食わず嫌いで絶対勉強しないでしょう。
だったらずーとわからんかな。
好き嫌いで仕事ができるのはうらやましい。というか、サンデープログラマーか。
趣味なら何でもよろしい。

>Perlは美しい言語だと思います。Rubyはどうでか？
この感覚わからない。仕事でソフトを作るなら、使い方にもよるけど、
一定以上の規模をperlでかくなど悪夢です。

手続き型->オブジェクト指向って基本的に制約を強くする方向で進化したわけで、
その制約をメリットと感じない人は確かに存在するね。
傾向としては天才肌なプログラマに多くて、
そういう人はCやperlに汚さなんて感じないし
>630みたいな人間とは意思の疎通が出来ないんだよね（藁

>631
>手続き型->オブジェクト指向って基本的に制約を強くする方向で進化したわけで、
確かにそうなんだが、継承とか、一方的に規制を増やした方向だけとも思わない。
オブジェクトの良いとこかいてくと教科書になっちゃうけど構造体の良さがわか
れば、>629もオブジェクトの良さの一部がわかるかな。

ただ、オブジェクトでひどい書きかたされるとかえってたちは悪いとは思う。

>傾向としては天才肌なプログラマに多くて、

天才の定義によるがそれって独りよがりのひと？ コスト的に妥当な
プログラマーの集団で作成しないといけないソフト製造には、自分の
書いたコードが人が読めることが必須。オブジェクト指向とかはあく
までエンジニアリング（ローコストで良いものを作る）として進化し
てるんだと思う。

>そういう人はCやperlに汚さなんて感じないし

要は書き方なのだが、宣言てきとうな言語など２０年前のbasicの時代に戻ったようで...
美しいというか、ちゃんとした言語とは思わない。何で書いてあっても
人にわかるようにきっちり書いてあれば美しいと思うが、型もわかりにくい
ようでは。ちょっとしたプログラムを書くには大変便利とは思うよ。

>630みたいな人間とは意思の疎通が出来ないんだよね（藁
そういいきられるとちょっと悲しいが、仕事としてソフトに関わるように
なって、純粋さがなくなってきたかなー。だんだん話の方向がずれて申し訳ない。

>>クラスでカプセル化と関数でカプセル化の区別がつきません。
関数でカプセル化ってどういうこと？
あと、perlが美しいってのはperl好きな人でもあまりいないとおもうが。
どんどん肥大化してるし。

http://www.geocities.co.jp/SiliconValley/5634/t82A2_0001.html#1555で
委譲の項目で
・オブジェクト指向な考え方に一番縁遠く、
今日もせっせとデカい声で旗振りをしながら、
手続き型言語のCOBOLを駆使しているアイツが、
何故か使いこなしているもの。
・「委譲」じゃなく、「押し付け」とか「責任転嫁」とか表現した方が
正確なのだけれど・・・。

ってありますけど、本当ですか？

なんちゃって用語辞典じゃん。
洞察力に乏しく悪魔の辞典ほどの毒も無い。
読まんでよし。

>>635
同感。本人おもしろいつもりなんだろうがな。それほどのこともなし。

オブジェクト指向も設計思想の1つだ。プログラムを作るときに
作りたいものをどうイメージして、どの言語でどうやって作るか。
言語の性格もさまざまだし。結局、そこが腕の見せどころだ。
なんとか指向の方に正解があるわけでなくて作るやつの責任で選ぶってこと。
つくりたいものが決まらないうちに、作り方について正解が決まるわけはないから
概念だけを過剰にクローズアップしても得るものはないと思うよ。

Perlに美を感じたことはないけど作者の才能は十分にじみ出てると思う。

C++ の例外って使われてるの？すごく中途半端なイメージがあるんだけど

Java みたいに標準ライブラリとかで大々的に使わないで
例外を使え、って言っても混乱するだけだと思う。

おいらは使ってるよ
コンストラクタでのエラーなんて
例外なかったらキレイに扱えないじゃん
あと標準ライブラリだった例外使ってるじゃん

>>638
C++って、コンストラクタの中で例外だしていいんだっけ？

どこで出してもイイよ

どぴゅ

>>639
デストラクタが呼ばれないけどね。

>>640
デストラクタで例外出すのだけは、やめた方がいい。

>>643
ﾜﾗﾀ

Windowsのアプリケーションやゲームを作る場合、やはり一番適しているのは
Ｃ＋＋ですか？

ゲームに関してならVC++

645に関してならHSP

>>642
> デストラクタが呼ばれないけどね。

まだコンストラクト終ってないだもん、呼んじゃ駄目だよね。

初期化リストの中で初期化の終っているものは、デスタラクタ呼ばれる。
これは嬉しい仕様。http://www.gotw.ca/gotw/066.htm

>>633
>関数でカプセル化ってどういうこと？

関数によってカプセル化され得るものは、たしかにある。
が、関数ではカプセル化できなくてObjectでならできる、というものもある。

関数でカプセル化されるものの筆頭は、処理の「流れ」。
サブルーチンを呼べば、そのサブルーチンの中の処理順序を
気にする必要が無くなる(というか気にすることは出来なくなる)。

思い出深いのが、Cの関数の中のstatic変数。
グローバル変数みたいに外界に野ざらしになるわけでもないのに
前回の値を覚えているなんて、なんて便利なんだ！と最初は思ったが、
ほどなく、関数の実行より変数のほうが寿命が長いくせに、
その関数を使わないとその変数にアクセスできない(=多様なアクセス形態と
やろうと思ったら、その1つの関数が超多機能肥大化する羽目になる)、
ということが致命的に面倒だと気付いた。
そして、解決策はOOPだった。

#憂鬱本では、グローバル変数の正体を暴くという文脈で、これと同じ問題を指摘している。
#あれは名著だ。読め。

今日憂鬱本を注文しました（売上に貢献 :D）。

（クラスで）カプセル化すると大人数での開発に有利になる、
って言われてるんですけど、初期のC++はCのプリプロセッサ（？）
でしかなかったわけで、Cでもちゃんと関数を設計すれば、
カプセル化はできると思うんです。

#もしかしたら、C++ではクラスを使えば誰でもカプセル化できる、
#逆にカプセル化しなければC++のクラスは使えないってこと？
#英語で喋れは論理的になるとか、そういうレベル？

ちょっと具体的なプログラム例を考えます。

「プリプロセッサがなくても同じ事が出来る」というのは、
言語の実行時の振舞いの事を言っているのだと思う。
ところが「カプセル化」は、往々にして字面上の問題だから、同じ論理は通用しない。

文字リテラルの代わりに文字のコードポイント整定数を入力した時の事を考えよ。

// sageてるからsage

プロじゃないんだけれど。
たとえばコンパイラの構文解析なんかswitch文でやるほうがいいとしか
思いつかないんですが、OOPの使いどころが見えません。
オブジェクト扱いにするのは入力と変数管理と
コード出力ぐらいでしょうか｡
ストローストラップの偽インタビューが気になる｡
カプセル化ってガチャポンの中身が何でも同じ規格の殻に入ってるってことですよね。

カプセル戦士

カプセルに入っているので、中に違うものが入っていても
同じ機械で繰り出せるのです。

>>652
Interpreter パターンを知っている上でそう思っているのなら、
別に人それぞれ、どう思おうが構わないのですが。
知らないのなら一度何かの本で見てみるとよいでしょう。

でも、ＯＯＰ使おうが使わまいが、構文解析するときの
switch の使用頻度はそんなに変わらないと思うのですが。
文法を書いて、その要素要素を関数で置き換えるか
クラスで置きかえるかが違うだけで、
どっちもやってることは一緒ですよね？

って、もしかして、トークン解析のこと言ってます？

http://www.inet-lab.org/ted/program/progdetail.html
を見てC++を勉強しよう。

age

C++（と言うかオブジェクト指向言語）の特徴なんざ
再利用可能な部品の寄せ集めでアプリが作れる点だと考えているが
いかがなもんか？
行き着く果ては部品のチューニング屋と組み上げ屋にわかれてくんちゃう？
特に大規模になればなる程ね。

モジュール化レベルに退行するっていいたいわけね？>658

退行って？

>>660
カーレースゲームで言うと、
逆走して対向車に追突するって事。

Ｃ＋＋におけるＯＯＰで最も需要なものがプリオンフィズムです。

ハンドルを操作するのに、車の実装部分までを知る必要がない！という例えに感動すれ。

>>663
それじゃＶＢですがな（ｗ

>６６２
つまりどれだけ実態を隠しとおせるかということですね？