トップページ⇒tech
1001コメント446KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさんNGNG
なぜＣ＋＋はあんなに難しいのか？

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

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

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

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

つうかＯＯＰが理解できない小生のぐちだね。やれやれ。
0002デフォルトの名無しさんNGNG
ストラウストラップ。ストラウス罠と覚えましょう
0003デフォルトの名無しさんNGNG
ストラウストラップの衝撃発言がありましたね。
C++はタチの悪いジョークだと。どこに載ってたかは失念。

COMはC++のものではないですが、COMバイナリ互換と
インターフェイスの分離はたとえ理想的なメカニズムでは
ないにしろ、単なる創意工夫を越えて１歩前進、なのでは
ないですか？ 実際にはC++の果たしている役割は大きいと
思いますが。
実装の継承よりインターフェイスの分離のための純粋仮称関数。
しかもC並の動作効率を望めるということで、逆にこれ以外なにが
あるの？と思いますけど。 環境として。
妥協の産物であるけれどもそれは偉大な妥協、現実からの逃避を
しない仕様、ということで。どうですか？
0004デフォルトの名無しさんNGNG
C++は//コメント〜
って書き方が出来るから使いだした(笑)
0005デフォルトの名無しさんNGNG
文法を理解出来ても、それだけじゃプログラムが組めないところがイタイ
何をどうクラスにして良いかわからんよ。

C好きじゃ〜、お前だけが頼りだ・・・asmにperlも愛してるぜぇ〜
0006１ですNGNG
＞３

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

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

ベルの産物にしては疑問・・・
0007デフォルトの名無しさんNGNG
>>1
えーとねぇ。
後半の多重継承云々ってところから下のごちゃごちゃしたの
全てを覚えるよりも、オブジェクト指向（用語じゃなくて概念を）
をきっちり理解さえすればそれだけで他の化石プログラマ達を
駆逐することができる分野があることが魅力でしょうか？
逆にオブジェクト指向が理解できない人にとってはゴミ同然の
物であることは確かだと思います。
0008デフォルトの名無しさんNGNG
STLが便利なのだ。。。
0009デフォルトの名無しさんNGNG
>>1
むずかしくねぇよ。おめぇの頭が悪いの。
0010名無しNGNG
オブジェクト指向を知りたいなら、GUIを作ることだね。
ありがたみがわかるよ。
0011１ですNGNG
＞７

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

Ｃ＋＋とＪＡＶＡを同時に習得しろという上からの命令で
苦しんでいる小生。鬱。
その前にオブジェクト指向を・・・でもわからん。
ＸＭＬ，ＣＯＲＢＡも同時進行。
全部中途半端。
でもうごく。こぇー。
上のひとはそれで満足。
機能追加拡張なんて絶対できん。
0012デフォルトの名無しさんNGNG
>>9
いやぁ、この人（１）言語の仕様を全て覚えようとしてるみたいだぞ。
Ｃ＋＋ってオブジェクト指向を覚えてから何が必要なことか
わかってないと覚えることばっかり多くなっちゃって
役に立たないし、すげー複雑だからハマっちまうと最悪の部類だと思うぞ。
先輩から最短コースで教えてもらった俺は幸福な奴だと思う。
0013１ですNGNG
＞９

どうしたら頭よくなりますか？
どうやっておぼえた？？？
おぼえたときＣ＋＋に対する疑問とかあった？
0014デフォルトの名無しさんNGNG
シロートですけど。
人様の作ったクラスを便利＆お気楽に
使うには、これほど極楽なものもないと思うんですが。
ま正しい理解とは違うでしょうが、極楽。
0015デフォルトの名無しさんNGNG
かぶった…
おれ９じゃないです。
0016１ですNGNG
＞１２

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

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

0019Ｃ＋＋は簡単だよNGNG
class,template
この二つを完全に理解すればＣ＋＋は８割理解したも同然。
ね！簡単でしょ(藁＞１
0020１ですNGNG
Ｃ＋＋で動けばいいと良しとする上司。
作ったプログラムはユーザ管理の基礎のぶぶん。
でも仕様は変てこ。
ここから発展させるのでこのシステムの行く末は見えてます。
0021１ですNGNG
>>19

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

わからないところはなんとなく組んでる。
0022デフォルトの名無しさんNGNG
お、おれも>>17の本はお勧めだ〜。
実はおれは１以上にC++組めないと思うけど、
この本読んだら元気出たよ。
がんばれ１。
0023デフォルトの名無しさんNGNG
ストラウストラップのインタビューはジョーク記事だよ。
URL忘れたけどさ。

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

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

0024デフォルトの名無しさんNGNG
俺にとってもＯＯＰは、ものすごい壁だったよ。
COBOLを４年Ｃを３年した後のＣ＋＋。
受け入れるのに３年かかった。

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

がんばれ１
0025デフォルトの名無しさんNGNG
１です。
元気が出てきたみたい。がんばるよ。
ありがとう。２ＣＨの人は好きだ。
なんかつよくなれるよ。
0026デフォルトの名無しさんNGNG
Windowsで
軽い開発はVBにのっとられ
思い開発はＶＣ＃

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

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

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

生産効率の低いC++は滅びていくだけでしょうね。
アセンブラと同じ運命。
0027デフォルトの名無しさんNGNG
C++ とレイトバインディングって直接関係あったっけ？

>>17
の本は OO の本としては良い本ですが、C++ の本としては微妙です。
ポインタの配列をデフォルトで使われると泣きます。
どっちかつーと Java っぽいコーディングだと思う。
0028デフォルトの名無しさんNGNG
VC#で重い開発はないと思うが…
CLRがネイティブコードより速い事はないはずだ…

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

C++をけなす奴==「自分は馬鹿です」と公表してる奴、だと思うが。
天に向かって唾を吐くって知ってます？
0029デフォルトの名無しさんNGNG
＞26
ふぅ〜。
Perlじゃ機能的に制限ありすぎて掲示板やメール程度が限界。
ＪａｖａはＭＳに見切りをつけられ死亡寸前。
ＶＢはＶＣで作ったＣＯＭオブジェクトがないと何も出来ない。
ＶＣは不滅だよ。
ただ扱えない人間が無理してＶＣ使う必要がなくなるだけ。
0030デフォルトの名無しさんNGNG
Java出来なくなったWinが滅亡寸前ではないのか。
かつてWin3.0（2.0もあったらしいが）が日本に入ってきた頃、
劣悪OSだが数でUNIX/X-Windowを凌ぐだろうと言われていた。
同じように劣悪携帯Javaが数でWinを凌ぐんでわ．．．あ、C++スレだった。
C++は機能は足りなくないんだが、後発のOO言語より記述が多く習得し難い。
でもOO言語習得したら第三世代言語にはもう戻れない．．．
0031デフォルトの名無しさんNGNG
＞30
ｉモードは自滅しました。
無理にＪａｖａ対応にしなくても専用の言語作ればいいのに。
基本的にｉモードＪａｖａってＪａｖａ互換ってだけで
似て非なるものなんだしさ・・・
それにしてもＪａｖａは開発環境が悪い。
0032デフォルトの名無しさんNGNG
>>31
Javaスレではないが…
JavaにIDEは要らん。もし作るならVJ++みたいに
ネイティブで作れ。あほベンダども。

10年後ならかまわんけどね。マシン速いだろうし。
0033デフォルトの名無しさんNGNG
１０年後は量子コンピュータの登場によりＶＢ厨房は死滅します。
と思ったが死滅するのはＶＣか？
量子アルゴリズムでプログラム書ける奴はいるのだろうか？
すこぶる優秀な人間のみネイティブコードプログラムを作り
一般人はスクリプトが限界か？
0034デフォルトの名無しさんNGNG
>>それにしてもＪａｖａは開発環境が悪い。
そうか？
私には、SDKで十分だが（C++スレだって）
C,C++は滅びないと思うが、VC++は無くなってもかまわんな。
0035デフォルトの名無しさんNGNG
>31
Javaが劣悪環境だって？
Winだって昔は、C言語なのにfarとnearとポインタが２種類あったり、
640KByteまでしか線形でメモリとれなかったりスゴかったんだぜ。
それに比べたら、携帯でメール出来た上、アプリ動くなんてスゴイじゃん。
0036デフォルトの名無しさんNGNG
>１０年後は量子コンピュータの登場によりＶＢ厨房は死滅します。

VBスレで叩かれた注坊がC++叩いてる。自分の能力を高めるまで静かにしてなさい。
0037デフォルトの名無しさんNGNG
↑引用文一行足りなかった。

>と思ったが死滅するのはＶＣか？
0038デフォルトの名無しさんNGNG
C++は開発規模が大きくなればなるほど、破綻してる言語仕様のおかげで生産性鈍ってくる。
単体で性能の良いライブラリを複数組み合わせれば、それぞれが自分の世界を主張し合う
ので、ほとんど実現不可能でしょう。28はまともに開発したことないんだな。
0039けろNGNG
クラスを使っていくのは簡単だけど、キチンとしたクラス作るのは
なかなか大変。
Effective C++読んでたらC++が嫌になった、っていうような書き込み
が以前あったけど、それはわかるなあ。
ある程度のモノを作るのはそれほど難しくないし、バグ削減にも
非常に効果あるっていうのは実感してるけど、それを他人様に使って
もらいたいかというと話は別になるけろ。
0040デフォルトの名無しさんNGNG
C++ というよりVCが難しい。何故にあんなに難しいの
0041デフォルトの名無しさんNGNG
私はBCBでＣ++おぼえたよ。VCL激ラブ♥
0042デフォルトの名無しさんNGNG
>C++ というよりVCが難しい。何故にあんなに難しいの
>私はBCBでＣ++おぼえたよ。VCL激ラブ♥

VCはMFCで作られてる（んだよね？）から固定ダイアログ画面が一杯開いて使いにくい。
BCBはVCLで作られてるからGUIの動きが良い。
0043デフォルトの名無しさんNGNG
>>42
>VCはMFCで作られてる
ＶＣ＋＋はＶＣ＋＋で作られました。とは書いてあったけど
ＭＦＣで作ったとは書いてないね。
俺はＭＦＣなんて使ってないと思うな。
あれってでかいプロジェクトには全く向いてね−もん。
ＶＣ＋＋を使い始めると必ずやらんでもええＭＦＣを始める
ノータリンが多いのは何故？挙句の果てにはＶＣ＋＋で作ると
必ずＭＦＣを使って組まなければならないとまで勘違いしてる奴まで
いてかなり鬱。
0044デフォルトの名無しさんNGNG
今時MFC使ってる人はいないでしょ…
0045デフォルトの名無しさんNGNG
>>43
スマソ、かつて俺がそのノータリンだった。
パッケージ同梱の入門書がＭＦＣだからつられて始めちゃった。
で、３日も持たず撃沈。「ＭＦＣのプロフェッショナル」って
すごい人なんだろうなー。
0046厨房NGNG
>>43
上に同じ。ノータリンです。

Winアプリは仕事上は社内ツールくらいしか作らないので、最近のトレンドは
知らないデス。
今時は何を使ってWinアプリ組めば良いですか? オススメは何ですか?
0047デフォルトの名無しさんNGNG
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

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

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

凝集度の低いモジュールを組み合わせようとしている
時点で設計者があほですな。
0049デフォルトの名無しさんNGNG
>>47
そのジョークはもう飽きたよ。
まさか、お前そのジョーク、本気で信じてるわけじゃないよな？
0050デフォルトの名無しさんNGNG
>>49
事実そのまんまじゃん。
0051デフォルトの名無しさんNGNG
>>50
オブジェクト志向は、小さいプロジェクトには
あまり意味は無い。
プロジェクトが大きくなるほど
オブジェクト指向のありがたさがわかるのだよ。

一人ぼっちでプログラムしてる人には
C++の良さは理解できんかもね。プッ（ｗ
0052デフォルトの名無しさんNGNG
CとC++は明らかに設計時のコンセプトが違うような気がする。
Cはシンプルを目指している感じがするが、
C++は何でも詰め込もうとしている感じがする。
0053デフォルトの名無しさんNGNG
うまく使えないからといって言語仕様のせいにするのは恥ずかしいね。
Ｃとの互換性や実行効率を確保しつつ機能拡張していった言語としては
非常によくできてると思うけどなあ。確かにとっつきは悪いけどプロの
道具と感じで使い込むほどに良さがわかるんだよね。
0054デフォルトの名無しさんNGNG
>>53
うまく使えないとも、
それが言語仕様のせいであるとも言ってないのに、
勝手に勘違いするお前の方が恥ずかしいけどな(ﾜﾗ
0055デフォルトの名無しさんNGNG
ダテュラやベッキやエドやエムエヂタ、WWWCは
MFｃでないかな？DonuTはSDKか。
005653NGNG
>>54
仕様が破綻してるとか言ってるやついるじゃん
0057デフォルトの名無しさんNGNG
ずいぶん上の>>28にレス

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

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

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

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

JAVAやC#を批判する時には現状の使用感と言語仕様
というものをわけて考えたまえ。
0058名無しさん＠お腹いっぱい。NGNG
もともとCだから
以上
0059デフォルトの名無しさんNGNG
組込型とクラスを同じように扱えるようにしようとしたのが
きっと悪夢の始まりだったんだな
0060デフォルトの名無しさんNGNG
こうなったらObjective-Cの復活が望まれます。
http://users.pandora.be/stes/compiler.html
0061デフォルトの名無しさんNGNG
MFCは要領よく使えばいいだけ。
まだ分らん奴が中にまぎれてるな・・。
0062デフォルトの名無しさんNGNG
MSDNから使うものだけFavoritesとかに分けとけば、
超整理法ぽくAPIもMFCも分類ワケできるはずなんだけど。

他のOSに関してはしらないぷー。
0063デフォルトの名無しさんNGNG
プログラム作法って、言語とは独立したものだと思うのね。
だから、C++が難しいというのは、OOPが理解できてないからであって、
言語のせいではないと思いまふ。MFCは必要な部分だけ使えばいいし、
使わなくたっていいわけだし。

関係ないっスけど、JAVAのsuperって表記、C++でも使えると便利だなぁと
思いません? 派生元が変わると書き直すの面倒だし(笑)
0064デフォルトの名無しさんNGNG
>>57
28じゃないけど
28の人はどっちかっていうとＣ＋＋マンセーな意見じゃなくて
オブジェクト指向マンセーの意見でしょう。
それに今オブジェクト指向＋Ｃ＋＋を受け入れることができる
柔軟性があるなら別に問題は無いんじゃないでしょうか？
0065Del厨NGNG
C++は難しいのでオブジェクト指向まで到達するのにも時間がかかる。
0066デフォルトの名無しさんNGNG
>>63
＞関係ないっスけど、JAVAのsuperって表記、C++でも使えると便利だなぁと
便利だと思うので、たいていのクラスでは
class A : public B
{
  typedef B Super;
としてる。
0067デフォルトの名無しさんNGNG
多重継承があるから文法には組み込みにくいのだろうね。
006838NGNG
C++に躍らされてる奴らが多いな。特に >>53 なんか（藁

本気でオブジェクト指向プログラミングというものを考えれば、
C++なんて欠点だらけのじゃじゃ馬だということがわかるはず。
自分がC++に操られてるだけって気付かないなんてかわいそーだぜ。（藁
もうちょっとおべんきょうしたらー？
006963NGNG
>>67
多重継承してても、同じ関数名がダブってなければ特定できるわけで。
本当にピンポイントで指定したいなら、今の文法と同じでSuperClass::func()と
呼べばいいかなと思ったわけ。モダンなライブラリでない(笑) MFCは多重継承
ほとんどしないんもんで、ほとんどがsuperで済んじゃう。

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

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

C#ってこの辺りどうなんでそ。全然知らないんだけど...。
0070デフォルトの名無しさんNGNG
>>69
superが型名だったらsuperクラスの関数呼び出しにしか
使わないわけじゃないでしょ？　
0071デフォルトの名無しさんNGNG
>>68
具体的にどこが欠点だらけなのか指摘してみろよ。(藁
0072デフォルトの名無しさんNGNG
>>63
C++が難しいのは言語仕様のせいではないって？
じゃあ、「Protected Abstract Virtual Base Pure Virtual Private Destructor」
がどんなもので、それを最後に使ったのがいつか説明できるかい？(藁
0073デフォルトの名無しさんNGNG
C++は言語ではない。
Cでイベント駆動型フレームワークを作るための
拡張ライブラリである。
0074デフォルトの名無しさんNGNG
>>72
63じゃないが、そりゃ論理のすりかえというものだろう。
それがわかるかどうかと実用の難しさとなんの関係もなかろう。
どんな言語だって探せば大概微妙なところあるぞ。
0075デフォルトの名無しさんNGNG
アセンブラとＣ++を同じ土俵で語る無かれ。
0076デフォルトの名無しさんNGNG
つーか、プログラムを作るという行為（実装する）で、その言語を
完全に理解する必要はあるまいに。（知ってるといいけどな）
自分にとって使いやすい概念だけ取り入れればいいだけでは？

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

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

0077デフォルトの名無しさんNGNG
>>ALL
ではこのスレの命題である
「なぜＣ＋＋はあんなに難しいのか？」
の答えは
「言語仕様の前にオブジェクト指向を理解しないといけないから」
ということでよろしいでしょうか？
0078デフォルトの名無しさんNGNG
いいわけないだろ
0079デフォルトの名無しさんNGNG
Cと互換性を保つ意味が分からん。
++するときにCのソースをそのまま転用することは
そんなにないと思うのだが…。
実行効率もObjectiveCより格段に良い訳でもないし。
0080デフォルトの名無しさんNGNG
>>77
「なぜJavaはあんなに難しいのか」という質問が
あまりきかれないことからその答えは否定できる。

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

C++の失敗を踏まえてのJava、Javaの失敗を踏まえてのC#だな。
0081デフォルトの名無しさんNGNG
C++は難しいって言ってるけど C++は簡単だよ
というか、難しく使う方向性が間違っている

Javaは言語仕様で難解にならないように注意しているだけ
0082デフォルトの名無しさんNGNG
>>77
オブジェクト指向は理解してるつもりだけど(Objective-CとRubyは使える)、
C++はさっぱり分からんぞ。

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

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

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

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

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

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

Javaは言語的にはC++より優れていますが、活用できる分野が非常に限定的で、
そういう意味ではまだまだC++にとってかわることができません。
JavaがC++にとってかわるには、まだ何年もかかるでしょう。
少なくともウチの開発ターゲットには、環境すら存在しません。
0084デフォルトの名無しさんNGNG
>>82
C++も、もともとは単純な言語だったのだが、
「型付の強いオブジェクト指向言語だったらこういう機能が不可欠だよ〜」
っていう現場の要求が多くて、それに従って大きくなってきたってところが
大きいからな。歴史を知らないと難しく思うのも無理もないかも知れん。
歴史を知ってればあるべきものがあるところにあるだけなんだが。
0085デフォルトの名無しさんNGNG
C#が出たら++はほとんど絶滅すると思う。
あれはjava風のObjectPascalだよ。
CよりPascalのほうが寿命が長かったってことだね。
0086デフォルトの名無しさんNGNG
C#に期待♪
ぜんぜん手つけてないけど・・(笑)

Perlもオブジェクト指向してるけどどうかね？
ネイティブコンパイラが完成して処理速度さえ問題無くなれば
結構良い言語だと思う。
.Netに対応するらしいし俺は結構期待してるよ。
0087デフォルトの名無しさんNGNG
C++は難しいよ。
ルール１とルール２だけ、一つずつ見れば、簡単そうに見える。
でも、ルール１とルール２が組み合ったらどういう動作をするのか？
というのがわかりにくいんだよ。
さらに、ルール３も有効になるとどういう動作になるのか？
とか、無限に組み合わせが出てくるね。
非常に複雑になる。
0088デフォルトの名無しさんNGNG
Ｃ＋＋の難しさが分からない。
Ｃ＋＋(.cpp)でもＣと同じコーディングしてる。
クラスってなんですか？
インヘリタンスって？
0089デフォルトの名無しさんNGNG
>>87
ルール同士の整合性は考えずに、
そのルール単体での必要性から導入されてるからな。
STL大好きさ（笑)
0090デフォルトの名無しさんNGNG
C++は難しいという人に難解なC++ソースの提示をきぼー。
どんなソースが難しいのか知りたいなぁ。
0091デフォルトの名無しさんNGNG
Ｃ＋＋のソースは見た目が汚い、
Ｊａｖａは綺麗で読みやすい。
0092デフォルトの名無しさんNGNG
見た目だけかい（藁）
0093デフォルトの名無しさんNGNG
Ｃ++は「オブジェクト指向も使える」Ｃのスーパーセットだと思っておけば難解とかソースが汚いとか言われるんだと理解してるけど。

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

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

え？Ｃ#？・・・実際に触ってないから知らないな。マシン一台しかないし。
009493NGNG
一行目、日本語変だね。
鬱だ・・・追試の勉強しよ。
0095デフォルトの名無しさんNGNG
>>85
C#は、設計者が設計者だしねぇ（藁
まあ俺は好きだけどね。あの人の言語は。
0096デフォルトの名無しさん NGNG
>91
>Ｃ＋＋のソースは見た目が汚い
ヘボイ人が作ったソースでも見たのだろう。

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

0097デフォルトの名無しさんNGNG
>>90

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

「Protected Abstract Virtual Base Pure Virtual Private Destructor」

そーすりすときぼーん。
0099デフォルトの名無しさんNGNG
ちょっと質問なんですが、
私、テンプレートとか全然使わないんだけど駄目でしょうか。
その他、多重継承とか多態性とか使わないです。
クラスを上手く組み合わせて全てできてしまうのですが問題ありでしょうか？
あまり必要性を感じないのですが。
0100デフォルトの名無しさんNGNG
>>72
には
>>74　>>76
で反論されてるじゃろ〜
010198=90NGNG
んー。でも思い出してみればＭＦＣみてれば
いくらでもきたないＣ＋＋そーすはあるねー。

もういらないかも。
0102デフォルトの名無しさんNGNG
>>98
それはただの用語でしょ。
「プロテクテッド抽象仮想基底純粋仮想プライベートデストラクタ」
ソース言ったら答え言ってるのと同じじゃん。
0103デフォルトの名無しさんNGNG
>>96
んだんだ。
なんできれいでなんで汚くなるかも書かないと説得力ゼロだな。

でも、Cと地続きにしたのは汚いソースをあふれさせた原因かもな。
0104デフォルトの名無しさんNGNG
>>100
>>74
「プロテクテッド抽象仮想基底純粋仮想プライベートデストラクタ」
みたいな複雑なのがでてくる言語はさすがに限られてると思うぞ。
0105101NGNG
＞なぜＣ＋＋はあんなに難しいのか？
>難しいという人はソースきぼーん。
>Ｃ＋＋のソースは見た目が汚い
>ヘボイ人が作ったソースでも見たのだろう。

この考えに一票かも。
010698NGNG
悪いけど意味不明。>>102
0107デフォルトの名無しさんNGNG
http://www.google.com/search?q=Protected+Abstract+Virtual+Base+Pure+Virtual+Private+Destructor&hl=ja&safe=off&lr=
0108デフォルトの名無しさんNGNG
>>106
意味不明なら、君のとってC++は難しいってこと。
分かってないってことだから。
010998NGNG
ありがと。見てみるよー。>>107
011098NGNG
はいはい。>>108
0111デフォルトの名無しさんNGNG
>>108に一票
ついでに言えば、ソースで見ればそんな難しいものでも無さそう
0112デフォルトの名無しさんNGNG
文化の差はあると思う。
出力引数なんて Java じゃほとんど使わないけど
C++ ではよく使うよね。

C++ で綺麗に書くことはできるけど、
C をひきずってしまうので綺麗に書いてる人は少ない
というのが経験的な感想。
Microsoft のソースが汚いというのも
そういうイメージの原因かと(
0113デフォルトの名無しさんNGNG
>>104
その辺は結局、型付の強い言語で多重継承を認めるとどうなるか、っていう
失敗例といっていいと思う。でも、Java的なimplement interface の方法論を
導入すれば回避できる、というよりもその辺は俺の感覚だとほとんど記憶から
削除されてるし、削除してしまっても何ら問題ないよね。OOPを同時に勉強し
ないでそっちのほうに迷い込んじゃった人はかわいそうだと思うけども。

誰かも言ってたけど、処理系の実装の難しさと実用の難しさをごっちゃにしちゃ
いかんと思うが。
0114デフォルトの名無しさんNGNG
C++ はシステムレベルでも記述できる、非純粋？オブジェクト指向言語なんで、
普通にアプリを書いている人には必要ない（というか危険な）機能がいっぱい。
ポインタが無ければCじゃないが、ポインタは初級者には危険すぎる。

Java がもっと普及すればいいのに。。。。
0115デフォルトの名無しさんNGNG
ポインタも理解できないような奴を
プログラマとは呼びたくないな

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

いっぺんに重箱の隅まで覚えようとするから大変なんだよ
0116デフォルトの名無しさんNGNG
>>114
Javaがネィテェブコード吐けりゃ、俺も乗り換えてたよ…
0117116NGNG
ネィテェブってなによ
011863NGNG
>>72
だから、こんな言葉の説明が出来る事とプログラムの本質は関係ないでしょ(藁
プロとして仕事するなら一番求められるのは結果であって、クライアントの
要求するものを提供できれば、どんな言語を使おうが、どんなアルゴリズムを
使おうが、そんな事はどうでもいいこと。

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

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

よって、OOPを理解すればC++もJavaも難しくなく、逆に理解していなければ
同様に難解なはず。よって、他のObjectOrientedな高級言語と比較して、
特にC++が「難解」とは言えないとおいらは思いますけどね。
0119デフォルトの名無しさんNGNG
設計は開発言語とは無関係とかよくいわれるけどね。
実際には開発言語や環境を考慮せずに設計したものは
ロクなもんじゃないぜ。
0120デフォルトの名無しさんNGNG
>>118
だからほかの言語に比べて慣れるのが大変ってことなのよ。
慣れてしまえば生産性はオブジェクト指向言語として
他と変わらないと思うけど。
0121Del厨NGNG
OOPは当然理解していますが
糞C++は難しくて使うの嫌です。

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

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

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

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

コンパイル遅いしね（藁
変なキャストしても警告でないしね。
0122デフォルトの名無しさんNGNG
C++の難しい理由・・。
C言語をごちゃ混ぜになるから・・。
0123デフォルトの名無しさんNGNG
C++が難しい→ソースみせろ→C++のソースは汚い
→へぼい人が作ったのだろう→ヘボい人がいるのはC++が難しいから→

（ｗ
ごくろうさん。
0124デフォルトの名無しさんNGNG
> よって、OOPを理解すればC++もJavaも難しくなく、
> 逆に理解していなければ 同様に難解なはず。
OOPを理解すれば楽にはなるがC++の場合、templateとゆーもう一つの山がある

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

> 生産性はオブジェクト指向言語として他と変わらないと思うけど。
templateがないJavaよりは生産性が高いと信じたい．．．。
0125デフォルトの名無しさんNGNG
>>124
テンプレートってそんなに「使える」んですか。
ちょっと齧っただけの俺にとっては何かマクロ言語みたいでつらくて‥
0126デフォルトの名無しさんNGNG
糞みたいなC++をようやくマトモに使わせたいだけの存在。

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

どうせ覚えるために工数かかるのなら
他の言語を覚えておいたほうがまし。
0127デフォルトの名無しさんNGNG
Templateはコレクションクラスには非常に便利。
でもコレクションクラス以外では使う場面無いんじゃない？
0128デフォルトの名無しさんNGNG
>>125
C++のテンプレートは、言語仕様で定義しているマクロです。
オブジェクト指向的な考え方の上に考えられたものではありません。
例外処理のようにプログラムのあり方を根本的に変えるものではなく、
熟知していないと使いこなせないわりには、罠が多くプログラマの
ストレスを高めていきます。神経質すぎる人は発狂してしまいます。
そして、強烈なアンチC++野郎として生まれ変わるでしょう。恐いですね。
0129デフォルトの名無しさんNGNG
>>126
>他の言語を覚えておいたほうがまし。
C++以外で普及している言語はVB, Delphi, Java, Cなどがありますが。

VB, Delphiはwin以外の環境では無理だし。
(C#ってwin以外の環境でも使えるの？)
Javaは遅いし、いまさらCに戻りたくありません。
0130デフォルトの名無しさんNGNG
>>118
Procedure-Orientedに関しても同じこといわれてたよ。
と言うことは、そう言われていく中でCが定着したように、
これもC++が定着していく過程なのかな。
0131デフォルトの名無しさんNGNG
>>129
あんたが使うプラットホームにあわせて言語も変えろって事。

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

C++標準で済まそうと思うというバカな考えでいるから
生産性が低いまんまなのだよ。
0132デフォルトの名無しさんNGNG
ねえねえ、>>129

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

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

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

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

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

要するに、沢山用意されている機能のうち、自分の使いやすいものだけを使えば
それでいいんじゃないのかな。
C++文法の生き字引とでも呼ばれたいなら別だが(藁
0134デフォルトの名無しさんNGNG
templateをOOPと関係ないって堂々と言う人が多いなあ。
あれは多態のスタティックなやつだと思ったほうが
わかりやすいんじゃがねー。

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

そのあげく、「STLはOOPと関係ない」とか言われると萎える。
0135129NGNG
> あんたが使うプラットホームにあわせて言語も変えろって事。
あるプラットホームで開発した物を別のプラットホームに移植するときに
別の言語で移植しろという事でしょうか？
そんなのいやです。

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

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

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

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

自分が低級ﾄﾞｷｭオタだからって他人もそうだと考えない方がいいよ。
0136デフォルトの名無しさんNGNG
標準っていうとさ。

*BSD(せめてFreeBSDだけでも),Linux,Windowsで動く
日本語が表示/入力出来てC言語で書かれたGUIツールキットがほしいですね。
何かないかな。
0137デフォルトの名無しさんNGNG
>>135
モナヂラだよ(藁
0138デフォルトの名無しさんNGNG
OOPを理解したと自認している人に聞きたいのですが、多重継承はOOPにとってな
くてはならないものですか？もしなくてもいいならどのような代替策が優れてい
るのですか？
0139デフォルトの名無しさんNGNG
必死だね。ま、ｶﾞﾑﾊﾞｯﾃﾈ
0140デフォルトの名無しさんNGNG
>>138
インターフェースの継承と機能の継承は分けて考えろなんて
いいますね。前者は多重継承があっても良いと。
COM も Java もそういう方針だと思います。
機能の再利用は継承を使わなくても実現できる場合が多いから
無くてもいいということではないでしょうか

必要/不必要という観点より、使った場合の利点/欠点の
バランスが問題かと。
0141デフォルトの名無しさんNGNG
>>140
インターフェースだけ継承して、他の機能は包含でも実現できるやん。
0142デフォルトの名無しさんNGNG
>>134
テンプレート関数はどう説明する？
0143デフォルトの名無しさんNGNG
>>138
Is a関係ではなくて
Has a 関係にして内包してしまえばよい。

多重継承は無くてもいいのではないでしょうか。
0144デフォルトの名無しさんNGNG
>>142
template関数全体のことを言ってるなら、
staticなgeneric。closみたいなやつ。
STLにおける使い方について言ってるなら、
まさにStrategyデザインパターンそのもの。

前者はちょっと屁理屈くさいけど。
0145144NGNG
144補足
もちろんマクロ的な使い方もするけど、
そう思った方がtemplateの存在意義とか理解しやすいし、
STLとかの意味もわかるよ、といいたいだけだよ。
0146デフォルトの名無しさんNGNG
ふと思ったが、STLの実装は
汚いC++コード（C++はこんなに汚くなる）の
見本みたいなものではないか。
0147138NGNG
>Has a 関係にして内包してしまえばよい。
徹底すれば多重継承はしなくていいと思いますが
コードがタブることになりませんか？

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

Rubyのmix-inというのは比較的分かりやすいけど、
モジュールというのがクラスとは別個にあってなんか折衷案っぽい
気がする。
0148デフォルトの名無しさんNGNG
どこから継承したかわからなくなるよりいいかも。
0149デフォルトの名無しさんNGNG
>Has a 関係にして内包してしまえばよい。
この論理はそっくりそのまま継承が要らないという論理にもなる。

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

2は極めて中途半端な立場で実装の継承を1つに限りＯＫするのは経験上これ
が一番便利だと判断したからに違いない。
0150デフォルトの名無しさんNGNG
>2は極めて中途半端な立場で実装の継承を1つに
1の間違い…
0151デフォルトの名無しさんNGNG
1です。

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

早速「憂鬱なプログラマの〜」を購入し
オブジェクト指向＆ＵＭＬを勉強しています。
0152デフォルトの名無しさんNGNG
>この論理はそっくりそのまま継承が要らないという論理にもなる。

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

また、実装継承のないCOM、CORBAオブジェクトの場合も、
実装時には包含するかまったく新規に実装することになりますね。
0153デフォルトの名無しさんNGNG
>>151(1)
おおう。
その選択は最高に正しいよ。
0154デフォルトの名無しさんNGNG
templateは今の仕事に欠かせないなぁ。構造的に。
確かに易しい言語ではないが。
0155デフォルトの名無しさんNGNG
>>146
同意
デバグ死にます。
typedef マクリの半分くらいは STL の仕様のせいだと思うけど。
0156デフォルトの名無しさんNGNG
>>146
どのSTLを見たのかは知らんが、まったくそうだな。
つーか、見んなよ。使うだけにしとき。
そして、STLは見せないようにしろ。
0157デフォルトの名無しさんNGNG
>>146
でも技巧の勉強にはなるわな... テンプレートグルを目指す人には良い参考資料だ。
0158デフォルトの名無しさんNGNG
STLの実装が汚い？　なんで？
0159デフォルトの名無しさんNGNG
VC++のやつはかなり厳しいよ。
C++Bのやつは結構きれい。
0160デフォルトの名無しさんNGNG
>>159
見れるなら見たいにゃー。
0161デフォルトの名無しさんNGNG
あのー・・・STLは、その性格上ヘッダファイルに丸々実装かいて
あるんだにょ｡C++使いが知らないと恥ずかしいかもしれないにょ｡

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

いい機会だからちょっと見てみたけど、凄いにょ…
嫌がらせみたいなソースだにょ｡
0162161NGNG
テンプレートライブラリの公開は、ソースの大公開になるので、
仕事でやるなら気をつけてくれにょ｡

昔、ミカ○系提供のテンプレートライブラリに致命的なバグが
有ったことがあったにょ…
0163デフォルトの名無しさんNGNG
継承をつかわないで包含を使う方が良い場合が多いとか。

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

個人的にはすべて Object として収納する Java風のコンテナ の方が
わかりやすいとは思います。
0164デフォルトの名無しさんNGNG
>>163
dynamic_cast を躊躇なく使える立場のヒトはいいけどさ。
0165デフォルトの名無しさんNGNG
>>164
おいら、クライアント側でキャストするなんて事はあんまりしないっす｡

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

・・・つうか常識でしょ｡
0166デフォルトの名無しさんNGNG
>>164-165
微妙に話がずれてるなきみたち
0167デフォルトの名無しさんNGNG
>>165
そのラッパの中では static_cast で済ましてるわけね。
・・・まあ、それでいい気もするけど。
0168デフォルトの名無しさんNGNG
>>165
それをプログラム中の配列すべてに対して行うのか？
JAVAやNON-STLではそれが面倒だからどうしても[]を使ってしまう。
0169デフォルトの名無しさんNGNG
多重継承バリバリのソースを解析するのは疲れるんで嫌いです。
はぁ…
0170名無し戦隊ナノレンジャー！NGNG
>>169
キチンとspecを出させるべき
0171デフォルトの名無しさんNGNG
Ｃ＋＋はできた方がいい？
ほとんどＣでかいてるけど、
Ｃ＋＋の本読んでもクラスとかの便利さってよく分からなかった。
017293NGNG
クラスが勝手にデストラクタで壊れてくれるので、ファイルの閉じ忘れ等を防ぐことが出来ます。
一番簡単にいえるのはこれぐらいか・・・。

あとはＣでも出来ないことはないしね・・・。
（ＯＯＰとか)
0173デフォルトの名無しさんNGNG
1さんじゃないけど

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

他にも最近よくわからん用語が多すぎる・・・
オブジェクト指向はパラダイムが違うって言うけど用語もずいぶんわかんない。
0174デフォルトの名無しさんNGNG
クロージャはOOP用語じゃないぞ、別に。
0175デフォルトの名無しさんNGNG
委譲というのはあるオブジェクトが受けたメッセージを別の
オブジェクトに丸投げしてしまうことです。
0176デフォルトの名無しさんNGNG
ってことはMFCのメッセージルーピングマクロなんかは委譲のいい例だな。
0177デフォルトの名無しさんNGNG
元請けが下請けに設計・実装全てを丸投げして
うわまえだけピンはねしている日本のゼネコン体質は
”異常”といいます。
0178デフォルトの名無しさんNGNG
AGE
0179デフォルトの名無しさんNGNG
>>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;
　}
0180デフォルトの名無しさんNGNG
>>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 {
};
0181デフォルトの名無しさんNGNG
age
0182デフォルトの名無しさんNGNG
い・１万分の１・・
孫請けは更に１万分の１・・・
苦情は無償・・・
あ、でも関連づけがされてないから大丈夫だ。
0183名無しさんNGNG
２ちゃんねるはメガネオタクの集まり！！
どうしょうも出来へんな！！
スキルも無いくせに能書きだけは一人前の奴ばっか！！
ほんまにスキルある奴は軽く遊んだるから、かかってこいや！！
アホが！！2ちゃんねるはメガネオタクの集まり！！
メガネ割りたい！！
文句あるなら、かかってこいや！！
アホが！！
http://www.rju666.com/


0184デフォルトの名無しさんNGNG
こいつアホ？>>183
それとも騙りか？
0185デフォルトの名無しさんNGNG
C, C++って
書き方に自由度がありすぎるせいか
ソースコードに個性が出まくって困る。

ある程度制限されていても
みんなのコードが似かよるPascalの方が好き。
DelphiだとOOPきれいに書けるし。
0186デフォルトの名無しさんNGNG
きれいなOOPにはガベコレが必須な気がする今日この頃。
0187デフォルトの名無しさんNGNG
>185
>Delphi
interface と class の名前の prefix が違うのがいや。(TとI)
GC が無いのはとりあえず良いとしてもね・・・。
0188デフォルトの名無しさんNGNG
>>187
？　嫌なら別に俺様流で全部Cにしたら？
0189デフォルトの名無しさんNGNG
DelphiでBoehm GC使えるかな。
0190デフォルトの名無しさんNGNG
Delphiで無理にGC使わなくても interface使えばいいんじゃないの？
0191187NGNG
>188
"Delphi" だったら付属ライブラリがそういう規約だから、
自分流でいくとごっちゃになるからイヤ、と思っている。
interface と class をわざわざ分ける必要が無いと思うんだけれどなー。

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

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

>190
一瞬何を言っているのか理解できなかった。
TInterfacedObject を使え、ってことでしょ？
メモリ管理が面倒なだけだったらそれでも良いけれれど、
参照カウンタを利用しているから、
結構オーバーヘッドがあるのでダメです。
0192turbo type DNGNG
ネイティブでガベコレ是非ほしいよ。
C++でもDelphiでも
リファレンスカウンタを持ったクラスと
その使い方、破棄の仕方を教えてほしいな。
0193デフォルトの名無しさんNGNG
>192
参照カウンタの基礎はoperator=のオーバーロードじゃない？
0194191NGNG
>192
Delphi Tech
http://piza.2ch.net/test/read.cgi?bbs=tech&key=970606624
上のあたりに参照カウンタを利用した複素数クラスがある。
0195turbo type DNGNG
サンクユウ。
Techスレ、先頭から見たことなかったよ。（ｗ、
今後ともよろしゅうに。
0196turbo type DNGNG
・・・DelphiTechスレ、の先頭の方、まじでレヴェル高すぎ。
ｵﾚTechに投稿するの控えるよ。、ウツシ....
0197デフォルトの名無しさんNGNG
>>132の文章に女性の匂いを感じたのは俺だけでしょうか？
0198デフォルトの名無しさんNGNG
>>197
だから何？
お前は女を見たことが無いのか？
0199デフォルトの名無しさんNGNG
俺はC++よりもJavaの方が難しいけどなあ。
テンプレートつかえねーからコレクションクラス使うとキャストの
嵐になるしさ。きたねーったらありゃしねえ。クラスライブラリは
どでかくて把握できねえし。
0200デフォルトの名無しさんNGNG
>>197
男の小説家があーいう文章(?)を書けなければ、
その小説家の小説は男キャラだけになってしまうと思うが？

>>196
俺もはじめて見た。びびった。
というか、ますます燃える(笑)
0201デフォルトの名無しさんNGNG
>>187
interfaceのprefixはマイクロソフトのやり方に従っているのでは？
あとclassとinterfaceでは、意味が全然違うのでprefixを分けた方が
良いと思う。
0202デフォルトの名無しさんNGNG
>>189
どうなのかなあ。できるといいなぁBoehmGC。
ところでガベコレされるときにdestroyを呼んでもらうための
Boehm側の仕掛け(の説明英文(笑))が理解できません(T_T)。
誰か教えてください(T_T)

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

>>199
そういやGenericJavaはどうなったんでしょうか？
軽量(笑)テンプレートを搭載するとかいう話。
0203 NGNG
優れているうんぬんではなくて
普及してるから使うってのが正しい考えでは。
VHSみたいに
0204デフォルトの名無しさんNGNG
C++はフェラーリ。
Javaはインプレッサ。
ＶＢはカローラ。
COBOLは２トントラック
Fortranは初代クラウン
Smalltalkはトヨタ２０００ＧＴ
Perlはファミリア
Rubyはアルテッツァ
アセンブラは徒歩
0205187NGNG
>201
>あとclassとinterfaceでは、意味が全然違うのでprefixを分けた方が
意味が違うとは、たとえばどのあたり？
僕は、すべて仮想メソッドな class みたいなものとして捕らえているから
同じに見えるのだけれど･･･。
0206デフォルトの名無しさんNGNG
Javaはパフォーマンスをまったく無視して、
ドキュソプログラマにも扱えるようにした言語。
あんなものがネイティブで動いてもパフォーマンスが出るわけがない。
いくら言語仕様が美しくても、できるのがウンコソフトなら意味がない。

だいたいC++やアセンブラすら解らないような奴が、プログラム組むな。
0207デフォルトの名無しさんNGNG
>>206
VBのみ触れたことのある一流VBプログラマですが何か？
0208デフォルトの名無しさんNGNG
>>207
サブッ
0209デフォルトの名無しさんNGNG
>>206
激しく同意。

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

とにかく糞。ほんとサーブレットぐらいにしか利用価値がない。
0210デフォルトの名無しさんNGNG
ここC++のスレですよね･･･。
0211デフォルトの名無しさんNGNG
まあ、話題が尽きないのはいいことでしょ。
0212デフォルトの名無しさんNGNG
>>209
GC はともかく、関数の仮想化によるペナルティは

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

だけですよね。

性能差は空の関数呼び出しでも最大 20% 程度、実際に関数内で
処理を行う場合には誤差に過ぎないと思いますが、それほど性能
に悪影響が出ますか？　もし実測値などあるようでしたら、示し
てもらえると嬉しいです。
0213デフォルトの名無しさんNGNG
彼らはC++に固執しているのです。
怖いんですよ。
0214デフォルトの名無しさんNGNG
>>212
小さいクラスほど問題が大きくなる。
たとえばテーブルのセルクラスとかがいちいち関数テーブルを持って
いて仮想関数呼び出しが発生するのははっきり言ってむかつく。
俺のところでは50カラム2000行のすべてのセルの色を変更しようとす
ると5MBくらい食うのでGCが発生して10秒くらいかかる。
0215デフォルトの名無しさんNGNG
そういう場合ってとりあえず違う形で保持しません？
セルオブジェクトを大量に生成・保持している時点で終わり･･･。
0216>214NGNG
設計が悪いだけな気がするのは気の性でしょうか
0217デフォルトの名無しさんNGNG
>>212
Javaはデフォルトが仮想関数だからねぇ。
private final属性にするとか気をつけて組めば、
それほど深刻ということもないけど、
バイトコードレベルの知識のない大多数の似非Javaプログラマが
使い分けを意識しているとは思えないなぁ。
バイトコードレベルのインライン展開も明示できないし、
ループの内側で仮想関数をコールしている可能性は否定できないかも。

あと通常、仮想関数コールは２回余分にメモリ参照が必要だよ。
仮想関数テーブル->関数ポインタ->コールだからね。
さらにインターフェイスメソッドのコールは
インタフェイステーブル->仮想関数テーブル->関数ポインタ->コールだから
３回余分に参照が必要だよ。
0218217NGNG
それから、これはJITコンパイラが賢い場合の話で、
さらにコンスタントプール参照が入る可能性も否定できない。
0219デフォルトの名無しさんNGNG
>217
良くも悪くも
Javaでプログラミングをしている時点で仮想関数のコストを気にするのもどうかと。
0220214NGNG
あ、セルクラスっていってもセルスタイルクラスね。
現実問題としていちいちnewするしかないと思うけど？

同社のC++ライブラリも使用経験あるんだけど､その場合は1Mくらいだった。
もちろんオペレーターnewも書き換えてあった。
0221デフォルトの名無しさんNGNG
C++の参照(&)って必要なのですか?
0222215NGNG
>220
大量にセルのデータ（スタイル）を保持するなら、
とりあえず配列か何かで保持してメモリを稼ぐ。
で値を返すときに(newのコストがかかるけれど)毎回 newして返すか、
セルへの参照をもらってそいつの値を変えてやるとか。

ところでメモリの使用量ってどーやって調べたの？
0223デフォルトの名無しさんNGNG
>>221
参照なんかなくてもポインタで十分じゃないか、って話？

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

逆に NULL (何も指していない）状態を表現する必要があるなら、参照で
はなくポインタを使うべし……と Effective C++ か何かに書いてあった
ような気がする。
0224214NGNG
>>220
メモリの使用量はオペレーションをする前と直後のJAVA.exeのメモリ使用量から
前半部分はよくわからない。
俺が言いたいのは一個数バイトですむようなクラスの場合､vtbl(ポインタ)を
保持するのは無視できないパフォーマンス低下を招くと言うこと。
まあJAVAの場合問題はvtblだけじゃないと思うけど。
0225デフォルトの名無しさんNGNG
>>221
少なくとも演算子のオーバーロードには必要だわな。
それ以外で使ってるのはほとんど見たことない。
0226デフォルトの名無しさんNGNG
>>215 >>216
言語仕様に気を使ってプログラム組むのなら最初からC++を使ったほうがマシ。
CやC++はマシンアーキテクチャとその動作を想定しながら書く言語だが、
JavaがVMの動作を想定してどうする？
高速なVM用と低速なVM用とか分けて書き出したら、Javaのメリットはなくなる。
0227デフォルトの名無しさんNGNG
つうかJavaは構造体が無いのが痛い。
可読性とパフォーマンスやメモリ効率を両立できない。
0228215NGNG
>224
セルオブジェクトのフィールドごとに配列を用意してやる、ってこと。
boolean[] isBold;
int[] fontSize;
...
みたいに。するとメモリをかなり稼げると思う。
で、newするとか参照がどうしたってのはこいつの値の返し方のこと。
0229215NGNG
>224
>メモリの使用量はオペレーションをする前と直後のJAVA.exeのメモリ使用量から
たいていのJVMは一度に大量のメモリをOSから確保するのでそれはあてにならないと思うよ。
どちらにしろJavaはメモリ食いだが。
0230221NGNG
>223,225
どうもありがとう
演算子のオーバーロードというと、<<
シフトだけど
ほとんどのC++の解説書が　cout << ....
については、何の説明も無しに使ってますね。
良くないとおもう。
0231デフォルトの名無しさんNGNG
>>223
*pを実体で渡して、pがNULLだったらおしまいさ。

>>225
参照渡しするよ。よくしないでＣ＋＋プログラム書けるね〜
0232デフォルトの名無しさんNGNG
>>221

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

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

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

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

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

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

throw をコピーで catch すると、例外オブジェクトのコピーコンストラクタ内で
さらに例外が発生してややこしくなる。
ポインタで catch すると、開放されたゴミメモリをポイントすることになる。
例外ハンドラは参照で catch しないといけない。
0233デフォルトの名無しさんNGNG
>>232
こういう話を聞くたびに、delphiを思い出すんだよね。
C++でいう参照が無いのに、別に困っていない言語。
＃delphi以外の多くの言語でもソウだけど。

delphiとかに言わせれば、

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

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

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

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

C++って、ある一部に拘ってしまったばっかりに、
他の全ての利便性を獲得できなくなってしまった
という風に思える。
0234デフォルトの名無しさんNGNG
>>229
1000行だとちゃんと2Mくらい増えるから当てになると思う。

>boolean[] isBold
2000行だったら無条件にboolean isBold[2000]ってするのか？
デフォルトではすべてのセルは同じセルスタイルオブジェクトを共有して
いるからそんなにメモリを食わないのだけど､配列になんかしたら常にメ
モリ食いになっちゃうじゃん。
第一isBoldとかはビットフラグだと思う。
0235デフォルトの名無しさんNGNG
>>233
>1と2の理由は要するに、変数埋めこみObjectを許していないために
>変数の宣言と「同時に」Objectが作られるという抱き合わせ(笑)を

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

で、変数の宣言とともにnewが呼ばれることには非常に意味があると思う。
なぜなら変数の文法的スコープとともにデストラクタを呼べるから。
0236デフォルトの名無しさんNGNG
事前に言葉が抜けてるよ。
「独自仕様で勝手に拡張可能なら」代入演算子は要らないだろうな。
「過去の資産が不用なら」コピーコンストラクタは要らないだろうな。

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

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

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

え、特定OSで特定目的しか考えてないからComplexなんて要らないって？
そうだろうな。普通はFORTRAN資産の置き換えなんて考えないだろうな。
なら、Variant型なんて無いからね。
COMを呼びたくもなるさ。
0237デフォルトの名無しさんNGNG
てか、オブジェクトの複製をキチンと言語レベルで考慮してるのが
Ｃ＋＋。
ポインタはないとか大々的に宣伝してるクセに、Stringを==で比較
するとポインタの概念無しには説明不可能な挙動をする某Java
みたいなクソ言語とは違う。
なんでStringクラスだけ＋演算子が使えるんだよ。汚ねえ言語だ。
反吐がでるぜ。
0238JavaNGNG
StringBufferも使えるぞ。ゴルァ。
0239デフォルトの名無しさんNGNG
どうしてStringとStringBufferが別になってるの？
ださいんだけど。
0240デフォルトの名無しさんNGNG
>239
Stringがimmutableな方が便利だからじゃない？
0241デフォルトの名無しさんNGNG
>デルの事は知らないけど､変数埋め込みがあろうがなかろうが宣言と
>ともに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に積むように設計するんだってさ(笑)。
0242デフォルトの名無しさんNGNG
ということで、
Javaはポインタすら理解できないアホ向けに作られた言語ということで
よろしいですか？

C++マンセー
0243デフォルトの名無しさんNGNG
>とりあえずデルについて言えば、言語仕様そのものには
>別に環境依存な部分なんか無いもん。
>＃Kylixも出たし、という話もあるわけで。

おまえ、何にも知らないんだな。
エラそうな口たたく前にちゃんと仕様書読みな。タコ。
0244デフォルトの名無しさんNGNG
>ちゃんと仕様書読みな

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

>242
ポインタすら理解できないアホを
ポインタの道にはめる罠、じゃなくて？
＃いや、ポインタそのものは勿論良いものなんだが。
0245>241NGNG
>Scopeに従属した寿命をもつObjectがそんなに多いのか？という
>根源的疑問が。
ほとんどの変数はスコープに従属してると思うぞ。

＃以前Niftyで「スタック指向」とかいうドキュな考えを
＃ぶちあげていた奴がいたっけな。
＃ObjectをできるだけStackに積むように設計するんだってさ(笑)。
俺はそうやって組んでる。newなんて一回も使わないことだってある。
Ｃ＋＋の話な
0246デフォルトの名無しさんNGNG
Forth系もスタック指向
こちらは定義そのものもスタックに積まれる。
領域が連続する利点はデカイよ。
気にするのはスタックのオーバーフローのみ。
0247デフォルトの名無しさんNGNG
>>241

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

C++標準にstringはあるが……。
俺なんか外してる？
0248デフォルトの名無しさんNGNG
>>241
C++ でも class と struct を、それぞれ参照指向・値指向で使い分
けてれば幸せだったかも、と思うことはあるね。

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

当時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。
0249デフォルトの名無しさんNGNG
おーい、デル厨よー、こんな所で吼えてないで
DelphiでOSを作ろう！
DelphiでCGI向けスクリプト言語を作ろう！
Delphiを組み込み分野に浸透させよう！
DelphiでJVM,CLRを作ろう！
運動でもしたら？
0250デフォルトの名無しさんNGNG
俺、Delphiは好きだけど、ﾃﾞﾙ厨は大嫌い。
0251デフォルトの名無しさんNGNG
>>245
newを一度も使わないことがあるぅ？
それ痛すぎ。オブジェクト指向をちょっと勉強したら？
0252デフォルトの名無しさんNGNG
>251
あなたの方が痛いようなきがする・・・・。
0253デフォルトの名無しさんNGNG
(笑)と#ばかり使う奴、他スレまで出張してうざすぎ(ﾜﾗ
0254デフォルトの名無しさんNGNG
>>252
オブジェクト指向とはnewを使うことと見つけたり
0255254NGNG
>>251だった。逝ってくる。
0256デフォルトの名無しさんNGNG
age
0257デフォルトの名無しさんNGNG
ここの住人はどこ逝った?age
0258デフォルトの名無しさんNGNG
ここにいるぞ。
0259デフォルトの名無しさんNGNG
>>251
きっとあなたはJAVAしか触ったことがないのでしょう。
そしてオブジェクト指向とデザインパターンを修得した気になって
それを知らない厨房をこき下ろす快感のためにネットを徘徊している
のでしょう。
でもかわいそうに､OOPやデザインパターンを知らないのが厨房の証である時
代はとうの昔に過ぎ去ったのです。いまや誰でもOOPやデザパタを知っていて
不注意にこの言葉を使うとすぐに厨房であることがばれます。

まあ学生ならしょうがない面もありますが､将来この道で食っていこうと思って
るのならもうちっと勉強されたし。
0260教えて訓NGNG
教えてください。
Ｃ＋＋言語の設計コンセプト、設計思想ってどんなものなんですか？
0261デフォルトの名無しさんNGNG
混沌
0262デフォルトの名無しさんNGNG
デザインパターンは小技集だよ。
まずはオブジェクト指向をキッチリ覚える事の方が大事だと思う。
もともとデザパタなんて覚えなくてもいいようにできたものだと思ってたんだけどな。
どうもプログラマってマニュアル化が好きだよね。
0263デフォルトの名無しさんNGNG
>262
>どうもプログラマってマニュアル化が好きだよね。
当然だろ。
0264デフォルトの名無しさんNGNG
>>263
基本的にオブジェクト指向をしっかりと理解できていれば
デザインパターンなんて本なくてもあんなのはすぐに思い浮かぶねん。
逆に設計のレパートリーがあれしかないとかいったらそれは
使えないやつだと思うのだが。また、今後デザインパターンが増えるたびに
アレを敬愛するやつはその都度暗記していくのだろうか？
オブジェクト指向が理解できないやつってなんでもかんでも
覚えようとする傾向があると思う。「デザインパターンって本が
いいよ」いいよって聞いて読んで見たら「？」って感じだった。
あれは今更だよな。
0265デフォルトの名無しさんNGNG
デザインパターンは他のプログラマとの意思疎通に役立つんじゃないのか？
0266デフォルトの名無しさんNGNG
>>264
そんな人っているのかぁ。
でもあなたと仕事するのもつらそうね。
あれはコミュニケーションのための道具と理解してちょーだい。
0267デフォルトの名無しさんNGNG
>>265-266
だからそれじゃＣ言語の時の構造化なんたらのときとまるで
変わらないじゃん。あのときも色々と出たよね（笑）（色々とね）
また色んな流派を作って破綻させるか？
結局他のプログラマが知らなかったらそれでおしまい程度の
トンでも本のような気がするなぁ。
実際、オブジェクト指向で組んでるうちにアレの存在理由も
かすれてくるでしょ。
0268デフォルトの名無しさんNGNG
>>267
PLoPにいって皆説得しておいで。
0269デフォルトの名無しさんNGNG
>>264
今ごろGamma本詠んでてそのせりふはないだろ。
0270デフォルトの名無しさんNGNG
>>269
遅い？（藁
すまん逝ってくる。
0271デフォルトの名無しさんNGNG
>実際、オブジェクト指向で組んでるうちにアレの存在理由も
>かすれてくるでしょ。

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

>>270
にーちゃん、学生とかにはあの本結構いいんだよ。実際USの大学
は結構つかってっぞ。なかなか0から思いつく人間もいないから、
先人の足跡は見せとくのがいいんだ。
0272デフォルトの名無しさんNGNG
>>259
　あー？　なんだ？　主語が欠落しすぎて何いってんだかよくわからん。
かわいそうなのは誰だ？　この言葉とはなんだ？　ちゃんとした日本語
書いてくれ。
　ってか、OOPって言葉、かなり懐かしいぞ（ｗ
0273デフォルトの名無しさんNGNG
>>272
懐かしすぎて憶えてもいないか? (w
0274デフォルトの名無しさんNGNG
>>272
　そら言えるな。オブジェクト指向は分析設計に価値がある
ってことがとっくの昔に一般的になった昨今、OOPなんて
言葉を使うと素人だと思われるからね。ってか、この言葉は
素人判別用語だな。
　OOAとかOODってのすら最近聞かないよな。
0275デフォルトの名無しさんNGNG
>>274
またプログラミングの重要性に気づいて
一周してきた気がするけど。ここ1,2年ってそんな感じしない？

2ちゃんで求めちゃいけないのかもしれないけど、
もちっと建設的にいこうや
0276教えて訓NGNG
>>274
教えてください。
玄人判別用語はなんですか？
0277デフォルトの名無しさんNGNG
今日はエンジェリックレイヤーがやるから後でな。
0278デフォルトの名無しさんNGNG
>>275 一周してきたというのは、最近の XPブームのことを指してますか？
XP: 使うかどうか判らない部分までねちねち設計せずに、
さっさと必要部分「だけ」コード書いて、
まずけりゃ後からちゃちゃっと直そうぜ。
0279デフォルトの名無しさんNGNG
>>277
みさきち萌え〜。

なんかPGにアニオタ多くない？
0280デフォルトの名無しさんNGNG
>ほとんどの変数はスコープに従属してると思うぞ。

おーい。変数じゃなくて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でないと使えないのなら困るが。
0281デフォルトの名無しさんNGNG
>>280
>おーい。変数じゃなくてObjectっすよ。
>ObjectはScopeに従属してるたぁ限らないだろ？
もちろんObjectの意味で使った。でもあなたの最初の意見は
>Scopeに従属した寿命をもつObjectがそんなに多いのか?
でしょ？なぜ「従属してるたぁ限らないだろ」になってしまうのだ？
もちろん従属するとは限らないし､必要とあらば(Objectの寿命が不確定なら)new使うよ。

>同一と同値を区別しない世界にどんどん突入するからな。
まったくわからん。
　　CGiko *pG = new CGiko();
　　funcMona(pG);
　　delete pG;
が
　　CGiko g;
　　funcMona(&g);
になるだけなのだが。
0282デフォルトの名無しさんNGNG
４月後半から、この板全体がうざいね。
仕切りたがり、自己主張の押し付け、他方を貶める発言。

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

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

言語仕様の話に限定しようとしても
クラスライブラリがカバー、とか、
IDEの補完機能が、とか、
言い出すんだろ。
0283デフォルトの名無しさんNGNG
280の言う
>そういう意味では>>248の意見に賛成。
って、
>時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
>あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。
の最後の１４文字だけなのか。
前半部分には賛成してないんだろうな。
そのものずばりの言動をしているんだから。
0284デフォルトの名無しさんNGNG
そもそも言語仕様に限定する意味がわからないなぁ。
クラスライブラリーやIDEも考慮されての仕様だろ。
0285デフォルトの名無しさんNGNG
>>280

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

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

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

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

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

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

とか書けなくなるし。

多様なプログラミングスタイルを効率的にサポートする、言語使用の美しさよ
りも実用性というのが C++ の思想なんだから、それに目を瞑って C++ の言
語仕様を批判しても意味がない。
0286285NGNG
>>285
誤：fopen(), fclose() みたく、関数へのポインタだけ外に出す
正：fopen(), fclose() みたく、構造体へのポインタだけ外に出す
0287デフォルトの名無しさんNGNG
>>282
　主語が欠落しすぎて何いってんだかわからないなあ。
0288ページフォルトの名無しさん NGNG
fj.comp.lang.cみてーなつまんねー突っ込みだな
fjﾆｶｴﾚ
0289.NGNG
>>285
「みたく」ってなに？おいしいの？
0290デフォルトの名無しさんNGNG
ごたくの入門版
0291デフォルトの名無しさんNGNG
>>281
> >Scopeに従属した寿命をもつObjectがそんなに多いのか?
>でしょ？なぜ「従属してるたぁ限らないだろ」になってしまうのだ？

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

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

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

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

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

そりゃそうだが、それは最初の一歩でしょ。
0292デフォルトの名無しさんNGNG
>>282
>このスレに登場したきっかけが、

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

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

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

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

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

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

つーか>>284みたいに逆の意見もあるようだし(^^;
0293デフォルトの名無しさんNGNG
>>283
> >時の事情を一切無視して、現在の視点から批判するのは簡単だけど、
> >あまり意味ないでしょ。とりあえずＣ♯に期待しとけ。
>の最後の１４文字だけなのか。

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

まして「簡単」かどうかはどうでもいいことだ。
0294デフォルトの名無しさんNGNG
>>285
>私はそのプログラミングスタイルでも良いと思うよ。

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

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

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

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

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

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

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

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

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

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

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

まぁ、たこのようにナンデモ有りな言語仕様なんで
自分で好きな形に整形(限定)したうえで使う、
という手は使えます(けど)ね。C++は。
0295デフォルトの名無しさんNGNG
>>291
>Scopeに従属した寿命をもつObjectがそんなに多いのか?
だと「ほとんどのものは従属してない」と読める。
>従属してるたぁ限らないだろ
だと「ほとんどのものは従属してるけどそうじゃないものもある」と読める。
で俺の主張は「ほとんどの(80%位か)Objectの寿命はスコープに従属している」
だけどこれに異論はあるの？
#ほとんどっていうのは実際にインスタンス化される回数ではなくてプログラ
#ムに表れる回数ね。

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

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

それともオブジェクト同士が複雑に絡み合ってメッセージを投げ合って
いるようなものを想定してるのか？（シミュレーションとか）
モデル化する対象がそういうものならそう実装するしかないけど、おいら
がやってる仕事はもっと単純なものばっかなんで。
でもそっちのほうがメジャー。
0296デフォルトの名無しさんNGNG
C++ほど強力な武器はないよ(アセにはかなわないが).
C++を一通りやってからほかの環境で作業してみると、
あれがない、この機能がないと不満が出てしまう....

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

Rubyちゃんにでも手を出してみるか.
0297デフォルトの名無しさんNGNG
>>従属してるたぁ限らないだろ
>だと「ほとんどのものは従属してるけどそうじゃないものもある」と読める。

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

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

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

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

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

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

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

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

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

>>296
Objectとそれ以外の有りがたみの「比率」を知る
(答えは人によって色々だろうけど)には、
rubyみたいな純粋っぽいOOP言語も触って
対比してみると良いっすよ。
0298デフォルトの名無しさんNGNG
>>297
>異論あり。あなたのソースはそうなんでしょうけどね。
まあここが決定的な差なんだろう。あなたのソースではそうなんだね。

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

>ローカル変数なObjectばっかりだと、それもうまく表現できないよ。
あたりまえだ。最初からいってるように寿命が不確定なものはnewするよ。
おれはnewなしでどんな物でも作るって言ってるわけじゃない。
逆に聞きたいけどあなたは関数ローカルなObjectを一切使わないのか？
もし使うならそれはauto変数の出番だろ。
0299デフォルトの名無しさんNGNG
sageぐらい覚えてほしいよな。
0300デフォルトの名無しさんNGNG
こっちは煽りレス
>#ほとんどっていうのは実際にインスタンス化される回数ではなくてプログラ
>#ムに表れる回数ね。
>うーん。その数え方がすでに、Objectと変数の混同の
>一歩手前ってかんじなんですけど…
アホか？インスタンス化される回数で数えたらループの中で100万回生成される
オブジェクトが一番になっちゃうだろ？
いまは実行時の効率の話をしてるわけじゃなくてコーディング時の話しなんだから
実際にインスタンス化される回数が一回だろうが、100万回だろうが、ソースコード
に現れる回数が重要だろ？違う？
0301デフォルトの名無しさんNGNG
まあ、C++が汚くて他の言語の方が優れてるなんて事は、
(この板にいる)ほとんどの人は知っているのさ。
それを今更声を大にして叫ぶ奴がいるなんて思わなかったな。

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

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

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

残念ながらね、俺のまわりはC++を無視できるほど進歩的ではないし、
理論だけで食べていけるほど恵まれた世界には生きていない。
難しくて、ドロドロして、不合理で、過去のしがらみを捨てきれない、
そんなC++に対して悪口を言うのは簡単だけど、
それでは何も進まない。
正面から向かい合わないとやっていけないのさ。
0302デフォルトの名無しさんNGNG
>リファレンスカウント付きポインタ->スマートポインタ
>スコープ脱出後自動消滅->auto_ptr

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

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

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

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

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

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

そういやJavaは遅いわけだけど、VMの遅さとGCの遅さはともかくとして、
参照ベースであることは遅さにどれだけ寄与してるんでしょう？
＃というわけで、参照ベースだけどVMもGCもない言語の例としてdelphi…以下略
＃ただしdelphiにはスマートポインタ(やそれを自作する仕掛け)は無いけど(笑)。
0303デフォルトの名無しさんNGNG
>>300
あんまり煽りには見えないけどね(^^;

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

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

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

そうだっけ？
というか、この話を効率の話に直結しちゃうところが
既に微妙に痛いと思うんですけど。
0304デフォルトの名無しさんNGNG
>>301
>それを今更声を大にして叫ぶ奴がいるなんて思わなかったな。

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

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

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

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

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

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

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

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

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

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

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

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

もちろん、正面でないのが「あなたの」せいだとは言い切らないけど。
不可避な理不尽は世の中いっぱいあるから。
でもそれはあくまで正面ではないね。
0305デフォルトの名無しさんNGNG
欠点を指摘しあうスレは大抵こうなる。
http://piza.2ch.net/tech/kako/970/970151348.html
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=986993653
0306デフォルトの名無しさんNGNG
さげろっての、ボケ。
0307デフォルトの名無しさんNGNG
結局、「オブジェクト指向を」学ぶのにC++は向かないってことでしょ。
世の中にはC++で書かれた資料やサンプルやアルゴリズム等が蔓延している。
CS機・制御系等、事実上C/C++しか選択肢がない環境も多い。
それらを踏まえて「C++を」学ぶ人がいる。
もちろん、選択肢がC++以外にあれば、
いくらでも移行する人はいるだろうけどね。俺を含めて。

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

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

スレタイトル見ろよ。問いは「なぜ難しいか？」なんだぜ。
そう問われて、欠点を指摘しないほうが変だろ？
0309デフォルトの名無しさんNGNG
>>305
好きだね、キミも。
0310>>302NGNG
>スマートポインタとかauto_ptrとかを使えば、
>ローカルに使いたいObjectを消す面倒の問題と
>Objectを他所にやるときの面倒の問題が
>いっぺんにおおむね解決するよね。
他所ってのは自分が呼び出す関数のことではないよね。それなら＆で渡せるし、
そういうのを含めてローカルで使用するってことだ。
それ以外の意味で「他所」ならそのオブジェクトは「ローカルに使いたいObject」
という前提じゃないんだからパス。その2つを混同するのは痛くないのか？

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

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

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

　わからないなあ。Javaってそんなに美しい？
0312デフォルトの名無しさんNGNG
とりあえずプログラム言語にに「美しい」って言葉を使うの止めれば？
0313デフォルトの名無しさんNGNG
scheme言語は美しい
0314デフォルトの名無しさんNGNG
>>313
同意
0315デフォルトの名無しさんNGNG
C++ ってむやみに強力だけど、美しくも汚くもないと思う。
型変換（時にオペレータ）とかが暗黙で呼ばれるというのは
タイプ数を減らすという妙なところにこだわっていて変だけど、
これは C の後継である以上いたしかたないし。

template はひじょーーーによいと思う。Java にも☆い
0316デフォルトの名無しさんNGNG
>>312
　これは>>301さんが

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

　っておっしゃるもんだから、「この板のほとんどの人」が僕の疑問に
サクッと答えてくれるかな、と思って書いてみたんですよ。
　僕の意見としては、C++は美しくはないけど、Ｃ言語の素直なオブジェ
クト指向拡張だと思う。
Javaは美しくない。素直でもない。どっちかっていうと、地方出身の
女を専門に食い物にしているナンパ師のような、うさんくさい優しさを
感じるね。ただ、ＧＣやってくれるのは便利だし、クラスライブラリは
強力だから、使える処理系ではあるかな。ただ、ひたすらうさんくさい。
0317デフォルトの名無しさんNGNG
>>312
　なんで？　美しいって言葉使うのやめるとなんか良いことあるの？
0318デフォルトの名無しさんNGNG
>>316
でCはじじい（職人）ですか。
0319デフォルトの名無しさんNGNG
C++はテンプレートが便利ってことに尽きる。
0320デフォルトの名無しさんNGNG
>>318
いいねぇ。じじいＣ。
0321デフォルトの名無しさんNGNG
>それ以外の意味で「他所」ならそのオブジェクトは「ローカルに使いたい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++のよりよくも悪くも軽量らしいっすね。
0322デフォルトの名無しさんNGNG

>>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はバッティング問題を「逃避」してるだけだが、
逃避だけで十分な解決策だと考えてるわけじゃん。
なんか不味いの？
委譲とかのコードをうだうだ書かないとならんのはしんどいが、
それは別の話だし。
0323デフォルトの名無しさんNGNG
>>321
無条件にヒープ上にオブジェクト作られたら、ゲームや組み込みなんか
で C++ を使えなくなってしまう。Win32 みたいに、プロセス毎に広大
で疎な仮想メモリ空間が提供されてない世界も、まだまだ多いですよ。
0324お仕事中NGNG
ヒープは組み込み用用途にはあんまりむいていないからね。
C++まんせー
0325>231NGNG
>区別しなくて済むのが有りがたいのだが。
>Collectionとかにぶち込むとき、これはStack上のObjectかHeap上のかを
>いちいち悩むのは、うっとうしくないっすか？
だからコレクションに(参照で)ぶち込むものは基本的に寿命不確定なんだからnew
するでしょ。その点では全面的に賛成してるんだけど。

>>もうひとつプリミティブ型はさすがにauto変数にしていると思うが、なぜnewで
>>作ってauto_ptrでラップしないのか、理由が聞きたい。
>それはまぁ…効率(笑)。Delphi/Javaも同罪。
じゃあ効率を意識しなくて良いときにはプリミティブもnewで確保するのかい？
C++では、あなたが
・プリミティブを値として保持するか
・プリミティブを参照として保持するか
を選択できるんだよ。
0326デフォルトの名無しさんNGNG
>>324
うーん。するとJava(でEmbedded)については
どう考えると良いでしょうか？
「あんなの全然駄目だよ」で終わり、ってことですか？

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

>>325
選択できることのありがたみって結局なによ？という
話になると思う。二つモデルが有っても、その
デメリットよりメリットが多いならば、という。
0327デフォルトの名無しさんNGNG
おっと。見落とした。

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

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

それとも古典的ポインタの話？
じゃないよね？
0328デフォルトの名無しさんNGNG
現在のOSが何言語で作られているかを
考えれば、C++言語とその他の言語の比較は甚だ奇妙と
言わざるを得ない。
さらに言えばJava言語はC++言語のサブセットであり、
もちろん実装の多くの部分はC++言語である。

Javaにとって重要なのは、その巨大なライブラリが
無料であるということに他ならない。
皮肉なことは、Java言語が、すでにC++言語よりも
古いプログラミングパラダイムに居るということだ。
0329>NGNG
>選択できることのありがたみって結局なによ？という
>話になると思う。二つモデルが有っても、その
>デメリットよりメリットが多いならば、という。

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

>それとも古典的ポインタの話？
そうだ。
値を保持する->auto変数
参照を保持する->ポインタをラップしたauto_ptr
0330デフォルトの名無しさんNGNG
>「効率が重要でない局面ならプリミティブに対してauto_ptr使うのか？」

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

構造体(やソレによくにたObject)は話が別ね。
0331デフォルトの名無しさんNGNG
OSは微妙なところだなあ。
C++だとObjectモデルが二重管理っぽくなっちゃうでしょ。
あるいはマクロとかでC++言語に事実上手を加えるか。

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

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

というわけで、

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

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

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

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

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

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

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

新しいパラダイムの部分って、例えば他の言語をC++で実装するときに
どれだけ活用されてるの？
あんまり活用されていないならばそれは「蛇足」なのかも知れないよ。
0332>NGNG
>プリミティブってintとかだよねえ。
>すると「同値性と同一性を区別する意味」が
>あんまり無いモノである場合が多いだろうな。
なぜだ？
　int *pInt1, *pInt2;
　if (pInt1 == pInt2)// 同一性
　if (*pInt1 == *pInt2)//同値性
はぜんぜん別のものでしょ？

それに多くのオブジェクトは同値性を使わないのだから
それこそ「同値性と同一性を区別する意味」がないんでないの？
0333デフォルトの名無しさんNGNG
>>326
組み込みといっても分野が広くて、ある程度の広さのメモリ領域を
使えて、リアルタイム処理もさほど厳しく要求されないケースもあ
る。たとえば i アプリとかね。こういうケースでは Embedding
Java が活用できる。

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

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

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

p.s.

少しは自分で考えなよ……。自分が知らない分野のことは「見ない・
聞かない・言及しない」って態度だと、いつまで経っても Delphi 厨
房を卒業できないよ。
0334デフォルトの名無しさんNGNG
>>331
実際の OS のソースコード読んだ上で言ってる？
0335デフォルトの名無しさんNGNG
>int *pInt1, *pInt2;
>if (pInt1 == pInt2)// 同一性
>if (*pInt1 == *pInt2)//同値性
>はぜんぜん別のものでしょ？

区別する意味あるの？

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

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


>>333

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

>少しは自分で考えなよ

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

つーわけですまん。OSのコードはあんまり読んでないな。
でも出来るわけないのは「自明」じゃん。
まぁ継承の替わりになんでもかんでも委譲でやれば
ある程度のことは出来るが。
0336デフォルトの名無しさんNGNG
JavaはCで作られたUNIXを既に超えていると思う。
Javaを言語なんて言ってると大事なところをとりこぼしちゃうでしょ。
もちろんOS無しには動かないけどあれだけのライブラリがあると
もうアプリケーションみたいだよね。

そういう意味で.NETも面白そうだとは思うけど、、、
二つもいらないなぁ・・
0337デフォルトの名無しさんNGNG
>>336
UNIXを越えるとアプリケーションか。
つまりOSを越えたものがアプリケーション。
近藤君病院へ逝って良し。
0338336NGNG
>>336
実現されていない理念を狂信するのはやめたほうがいいよ。

頼むから、簡単だからって安易にスレッド作ったりJDBCコネク
ション切ったり繋いだりを繰り返さないでほしい。
ソース上は簡単でも実行時は半死体状態。「99%以上ちゃんと
動く」ようにするには、スレッドスケジューリングとかいろいろ
難しいことがありすぎて死ぬ。結局、各種リソース確保解放の概念や
同期プログラミングの基本的な手法を知らない馬鹿をJavaで凄い
プログラム出来た気にさせてしまっているのは、VBと同じで長期的には
犯罪だと思うんだがなあ。
0339!336NGNG
あれ？俺なんで336なんて書いたんだろ？スマソ。
0340デフォルトの名無しさんNGNG
>>336
「大事なところ」って何？
0341デフォルトの名無しさんNGNG
>>336
これが結構妄言であることは俺(笑)も賛同するが、
だからといってunixのfork()はやっぱり勘弁だな…
0342デフォルトの名無しさん NGNG
>338&341&その他
いいかげん不毛なんでsage進行でやってくれや。
0343デフォルトの名無しさんNGNG
>>341
はいはい、fork() が云々とか言うくせに、どうせプロセス・スレッドの代表的な
Design and Implementation も知らないんでしょ？　知らないことは、批判せず
に黙っててくれないかな、邪魔だから。

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

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

もう一度次のことをヨーク考えてみよう
・C++ではプリミティブとクラスが限りなくシームレスである。
・つまりC++ではどんなものでも(intでさえ)Objectである。
・もちろんintは継承もできないし、メソッドも少ししかない
・さらにポインタもObjectである。
0345デフォルトの名無しさんNGNG
>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ていうかモデルは、同じ(でないと不味い)だろ？
0346デフォルトの名無しさんNGNG
sageでやれ
0347デフォルトの名無しさんNGNG
>>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であること以外になにがある？
#?が多いなぁ
0348デフォルトの名無しさんNGNG

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

>>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を「地方出身の女ねらい専門のナンパ師」って言うのは、
ここいら辺が理由ですね。
0349デフォルトの名無しさんNGNG
Javaには総称が無いからな……。
いや、できなくはないけど……。

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

のようにクラスを指定できて、<>を省略したらObjectを指定したことになる。
というわけにはいかないのか？？
Eiffelの、制限が付けられる総称みたいな。
0350デフォルトの名無しさんNGNG
>>348
コードでもデータでも実体のあるものを継承すると（カプセル化が弱まって）いろいろ問題が起きて来るわけで、
C++ならすべて純粋仮想関数、javaならinterfaceだけ（継承は使わずに）で、作ればいいんじゃない？
カプセル化とポリモフィズムそのものはバッティングしないが、カプセル化とコードやデータの継承は、
もともと相反するものだし、それはどのOO論者でも一致していると思う。背反するものをC++もjavaも
それぞれ妥当と思う地点でバランスをとっている（つもり）になってるわけだ。どっちが優れてるとは
いえないと思うけど。どちらもベストではないというだけの話。（これはポインタやメモリ管理にも
いえる）
0351デフォルトの名無しさんNGNG
だからあえて言えば、（データやコードの）継承はC++みたいに複数許すのも、javaみたいに1個しか
許さないのも、合理的ではなく、0個が唯一の正解、ってのはダメ？（笑）
0352デフォルトの名無しさんNGNG
もひとつ。smalltalkでさえメタクラスなんて普通は使わない。smalltalkそのものを
実装する時以外は。メタクラスがほしいって、どういうときにほしいの？
（煽りじゃなくて素朴な質問。たとえば〜をやろうとしたときに、〜ができれば
いいなと思った、って回答を希望）
0353デフォルトの名無しさんNGNG
>>350
　こんばんは。348です。
　どうも僕は勉強不足のせいか、継承の問題点って全然わからない
のですよ。自分がハマったことがないので。
　実体のあるものを継承するとカプセル化が弱まる、ってなんで
なんでしょうか。全然イメージ湧かないのですけど。
　例えば、派生クラスから基底クラスの属性を直接いじくるような
コードを書く人がいるってことですか？　C++なら、メンバはprivate
が基本ですよねえ？
　たとえ継承を使わずに委譲で実現したとしても、結局はなんらかの
方法で、その属性を変更しないと処理が実現できないのでは？　だから
いじるのだろうし。
　うーん、良くわかりません。
0354デフォルトの名無しさんNGNG
え？
属性というのはデータってことで、データもコードも基底クラスのものを
利用するから、いろいろややこしいことが起こるわけでは。

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

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

いかが？
「それではコードの再利用ができないではないか」という以外の反論は
ないと予想しますが。
0355爆弾発言？NGNG
JCP　JSR-014がパブリックレビューが、ついこの間終わったぞ。
もうすぐ、JavaでSTLが使えるようになるよん。
0356デフォルトの名無しさんNGNG
>>349
総称ってなに？
解説 or サイト紹介キボーン
0357デフォルトの名無しさんNGNG
>>354
　っていうか、継承批判のあとには、必ず「委譲でGO」って
ことじゃないですか？　委譲すらしない、ってこと？
　委譲しないってことは、他のクラス使わないってことで、
それはまあありえない。しかし、委譲するなら、メソッドは
使うし、それにともなって属性も（間接的に）外からいじる。
　そうすると「いろいろとややこしいこと」がおこるのでは？

　そもそも、その「いろいろとややこしいこと」ってのが
わからないのですよ。前回もいったけど、継承でハマった
ことがないので。
0358349ではないがNGNG
>>356
総称generic
抽象化されたデータやアルゴリズムの事です。
C++のテンプレートの様なもの。
メタクラスを作れる言語ならあたりまえの様に定義できます。
0359デフォルトの名無しさんNGNG
>>355
Javaでテンプレート？
0360デフォルトの名無しさんNGNG
>>357 ん〜それではあなた自身があげている多重継承の問題を
javaのinterfaceは何も解決していない、という「問題」とは何？
0361デフォルトの名無しさんNGNG
一般にいわれる多重継承の問題というのは、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()を駆使してが
　んばる（笑）

となるはず。で、４）は結構つらい、というのが多重継承のややこしい
問題だと思うけど？（はしょっているけど一番大きな問題はこれに
集約されるはず）
0362デフォルトの名無しさんNGNG
書き直し^^；

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

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

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

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

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

両者の違いは、プログラマに権利と”責任”を負わせるか、それとも
権利も責任も制限するか、といった設計思想の問題。
0363デフォルトの名無しさんNGNG
鬱だ死のう

３） 1つ以上 ->2つ以上
0364デフォルトの名無しさんNGNG
>>358
ありがとう。
genericの訳だったのね。
0365デフォルトの名無しさんNGNG
　こんばんは、>>357です。

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

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

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

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

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

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

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

こうことのことだったら、よく使われることだと思ふ。
#コンストラクタがめんどいことになることもよくあるけど
0368デフォルトの名無しさんNGNG
>>356 >>366
教えてクン？　教えてクンじゃないか！
いやあ久しぶりだね。
またあいかわず人に教えてもらっているのか？
いつまでもそんなことしてたら嫌われるぞ。
前に教えた検索サイト、使ってるか？
おっと、約束の時間だ、急がないと。
それじゃあこれで失礼するよ。
くれくれクンにもよろしくな。
0369デフォルトの名無しさんNGNG
>>365

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

で、５）の話なんだけど、多重継承で問題となるのは、主として、共通の基底
クラスから派生した複数のクラスを両方継承する場合だと思うけど（それ以外
であれば大抵何とかなる）、５）だとその問題が存在しないの？なんか
問題は依然として残ると思うんだけど。ただ５）の中身がよく理解できてない
かもしれないから、できればコードで例をあげてくれるとうれしい。
0370369NGNG
補足。
私の解釈では５）がよいというのであれば、あなたの主張は「javaの欠点はinterfaceが
あること、ではなくて、テンプレートが無いこと、」ということでよい？

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

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

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

５）は単一継承＋委譲＋テンプレートであると思うので、javaにテンプレートが
ない分、javaが劣っているというのであれば、それはそのとおりと思う。
0372369NGNG
>>365
Mixinについて少し勉強したよ。ちょうどRubyの本が手元にあったんで。
おかげで勉強にはなった。まあ自分が述べたことは間違いではないと
思っているが、あなたの言いたいことはよく分かった。ふむ。

ところで…Rubyの作者ご本人？まさかね^^；なんか文体が似てるんだけど。
0373デフォルトの名無しさんNGNG
mix-inって、基本クラスとインスタンスを持たないMix-inクラスに
分類して、基本クラスを使って多重継承するときは必ず一つだけ
基本クラスを使うっていうルールのことじゃないの？
0374デフォルトの名無しさんNGNG
>>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 の記述能力の高さはやっぱり言語によらず便利だと思う。
0375デフォルトの名無しさんNGNG
>>374
それだとMix-inクラス同士を組み合わせちゃってるよ。
Mix-inはMix-inクラスとそれ以外のクラスの組み合わせじゃないの？
0376デフォルトの名無しさんNGNG
>>347
>変数の話だよ。なんで「変数の話を持ち出してもしょうがない」のだ？

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

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

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

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

finalはどうでもいいとして、
Object「の中」に構造が有るかどうか？が差じゃないの？
0377デフォルトの名無しさんNGNG
>>365の言ってるのってMix-inと全然違わない？
0378デフォルトの名無しさんNGNG
>>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としてはちょと鬱陶しい。
何かを実装するときには便利。
0379デフォルトの名無しさんNGNG
テンプレートなんか使わなくてもルールを守って多重継承
してればMixinになるが…
0380デフォルトの名無しさんNGNG
多重継承なんか使わなくてもルールを守って単一継承
してれば多重継承の問題は発生しなくなるが…
0381デフォルトの名無しさんNGNG
それじゃ非力じゃん>>379
非力なC++なんかクソの役にもたたん。
と、思う。
0382デフォルトの名無しさんNGNG
>>380-381
ﾊｧ？別にテンプレート使うなとは言ってない。
使わなくてもMixinになると言ってるだけだ。
0383デフォルトの名無しさんNGNG
だから、そんな mixin は非力だろ、って言ってるんじゃん。
C++ は toy language じゃないんだから、非力ながらこれも
できます、なんて話してもしようがないじゃん。

「過剰に豪快な記述能力(だからGCは自作してね)」ってのが
C++では？
0384デフォルトの名無しさんNGNG
つーことはテンプレートの無いC++はカスってことか？>383
0385!383NGNG
>>384
カスだね。でもＣ言語ほどカスじゃない。

テンプレートが無かったら、JavaやObjectPascalに確実に負ける。
しかしそれでもＣ言語には楽勝。
0386デフォルトの名無しさんNGNG
>>383
「過剰に豪快な記述能力」つったら、
ふつーlispやschemeとかのことを指すと思うが。
あえてC++を選ぶ理由はCと同様に効率が良いって点だけだよ。
あと知ってる人が多い、とか(ｗ
0387デフォルトの名無しさんNGNG
>>385
じゃあ、最強はgcの無い(Borlandの)ObjectPascalつーことで、
ファイナルアンサー？
0388デフォルトの名無しさんNGNG
最強?
0389デフォルトの名無しさんNGNG
Cをカスっていうのは違うだろ。
アセンブラをカスって言ってるみたい。
両方とも低級ってだけ。
C++と比べるものじゃないだろ。
0390!383NGNG
>>387
最強はテンプレートのあるＣ＋＋だ。
ObjectPascalなんて兄元にも及ばんな。

>>389
ＣとＣ＋＋を比べるのと、
Ｃとアセンブラを比べるのは、次元が違うよ。
0391デフォルトの名無しさんNGNG
>>386
キリ番(?)おめでと。

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

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

Lispはいかに動的構造で何でもかんでも書けるか？に
命かけてる感じで、
かたやC系は御存知のとおり低級部分が主で
構造について言えば静的マンセーな言語。
0392デフォルトの名無しさんNGNG
話の腰を折って悪いんだけど、なんで最近言語関係のスレがたくさん立ってんの？
0393デフォルトの名無しさんNGNG
「おれはカレーが好きだ！」
「いや、おれはラーメンが好きだ！」
っていう議論だよね、コレって・・・。
0394デフォルトの名無しさんNGNG
俺は迷わずカレーだぞ？
0395デフォルトの名無しさんNGNG
札幌だとどっちも旨いぜ。
味噌ラーメンとスープカレーまんせー
いや冗談抜きにお勧め。
0396デフォルトの名無しさんNGNG
違う違う、俺は豚骨ラーメンが好きだ
0397デフォルトの名無しさんNGNG
カレーとラーメンはどちらがオブジェクト指向なのですか？
カレーから福神漬けをとると、ラーメンよりも弱いですか？
0398デフォルトの名無しさんNGNG
カレーはオブジェクト指向です。
カレーライスはカレーを継承しています。
本場インドでは様々な派生がみられます。
ハヤシライスはインターフェイスのみ継承しています。

ラーメンは構造化です。
麺やスープのモジュールを組み合わせてカスタマイズします。
スープのデータフローが店の秘伝です。
麺がゆであがり状態に遷移した瞬間を見極め、
湯切りイベントを発行するタイミングが大切です。
0399デフォルトの名無しさんNGNG
>>383
何が非力なんだ？
別にMixinを実現するのにテンプレート使う必要はないし、
別の部分にテンプレート使えば良い。
どこが強力なのかさっぱりわからんのだが。
0400デフォルトの名無しさんNGNG
>カレーライスはカレーを継承しています

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

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

ラーメンはスパゲティプログラムを更に悪化させたものです。
スレッド(=糸)をスパゲティ以上に複雑怪奇にしてしまったもの。
ちなみにCoCOのカレーきしめんでは汁飛ぶのを防ぐ紙が添付
されていましたが、ロイホの坦々面では紙がありませんでしたので
ロイホはCoCOに負けました。弱いぞロイホ。
0401デフォルトの名無しさんNGNG
>>400
>どう見ても継承じゃなく集約だろ、カレーライスは。

？？
カレーとライスならそうかもしれんけど、
カレーとカレーライスなのだから汎化では？
0402デフォルトの名無しさんNGNG
>>399
具体例出さないと話がすれ違いっぱなしだと思うので、template を使わずに Mixin さ
せるコードの概略を示して欲しい。

もしかしたら、私が知らないだけで >>378 に匹敵する上手い方法があるのかも。
0403デフォルトの名無しさんNGNG
>>401
カレーチャーハンみたいにカレーと飯が不可分に
なっていたら汎化かもだけど、カレーライスは
単に並べただけにしか見えないっす。

ん。どっちが親か知らないけど、Compositeパターンかも。
実行時に動的にコンポ(飯)を付け足した感じ。
あるいは飯というDecoratorを付けたとか。
＃まぁそう解釈すると汎化に近づいては行くけど…
0404デフォルトの名無しさんNGNG
つまり、結論としてはカレーと言えば
ボンカレーゴールドということでよろしいでしょうか？
0405デフォルトの名無しさんNGNG
>>404
ええ。それを内包したボンカレーパンだと尚ヨシです。

＃あれってどれくらいメジャーなんでしょう？＞ボンカレーパン
0406デフォルトの名無しさんNGNG
カレーはうんこを継承しています。
0407デフォルトの名無しさんNGNG
＞４０３
カレーライスのカレーとライスは不可分だぞ。
お前はライスだけ見て「カレーライスの片割れだ」と思うか？
0408デフォルトの名無しさんNGNG
>>407
ん？思わないっすよ。
CompositeにせよDecoratorにせよ、
飯の相方はカレークラスじゃなくて
抽象的な具クラスだと見なす感じかな。
かけるのはカレーでも牛丼の具でも
どれでもいいわけよ。
「飯にかける」というInterfaceはコンパチだから。

松屋の「カレギュウ」まんせー(いや、旨いとは思わないけどね…
0409デフォルトの名無しさんNGNG
class カレギュウ:public カレー,牛丼{
};

カレギュウ cg=new カレギュウ;
cg->Hoge();
0410デフォルトの名無しさんNGNG
しまった、
カレギュウ*だった。
Javaと混じった。鬱だ…。
0411デフォルトの名無しさんNGNG
>>399
C++ は flavor や Smalltalk (の多重継承できるやつ) みたいに、
メソッド呼び出しが動的に解決される言語ではないので、本当に単純な
mix in では、mix する対象とか mix するときに同時に mix する相方
(あいかた)とかとのやりとりを行うときに、interface 抽象を行う必要が
あるでしょう？

そうすると、interface は特化しないので、共通の規定クラスがどうちゃら
の問題が出てきて、finalize するとき以外は mix in しない、とかそういう
方向へ逃げる必要がでてくる。と思う。例はちょっとかんべん。
こうすれば、そんなことはなくいろいろできる、というよい反例でもあれば、
出してくれるとうれしい。
0412デフォルトの名無しさんNGNG
C++ってすっごい簡単なような気がするのは僕だけですか？
0413デフォルトの名無しさんNGNG
>>412
心配するな。思い過ごしだ。
0414デフォルトの名無しさんNGNG
ああ、簡単でしょう。
なんかみんな変な機能つかうから難しく見えてしまうのでしょう。
0415ドらえもんNGNG
ではＣ＋＋がまったく使えない私は逝ってよしですか？
あぁcoutとcinは使えました。
0416デフォルトの名無しさんNGNG
なんでさぁ。
そうやって一つの機能が使える使えないっていう視点でしか見れないの？
すっげぇレベル低いよ。
0417デフォルトの名無しさんNGNG
>>414
そう思います。いつのまにか仮想関数くらいしか使わなく
なりました。多重継承になる場合も、設計を少し変えれば
なんとかなることが多いですし。

あ、テンプレートはたまに使います。複雑になりすぎない
程度ですけど。やっぱりあると便利な場合もありますね。
0418デフォルトの名無しさんNGNG
>>402
>>411
次のようなクラスをMixinクラスとする。
・インスタンスを作らない
・Mixinクラス以外のクラスから継承しない

そして、多重継承するときは非Mixinクラスは一つしか使わない。
これでMixinになるはずだ。
これのどこに不満があるんだ？
0419デフォルトの名無しさんNGNG
ん？
template を使わなくてもできる、ということは自明だし同意するけど。

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

不満や満足について話したいなら、心理板にでも逝け。
0420デフォルトの名無しさんNGNG
↑
口汚くてごめん。
0421デフォルトの名無しさんNGNG
>>419
だから、どこが不満なのかってのは、どこが非力で不自然なんだ？って
意味だよ。
0422419NGNG
僕的には411で書いたことに尽きるんだけど。相互に独立したflavor
同士の mix-in って現実にあまり使わないから。

あえて411に追加するとすれば、flavorどうしの相互作用を実装/定義
するときに、単純な interface 抽象を使うと、interface 毎に利用
者は、その全てのメソッドを実装する必要がある。他のflavorやinner
objectに処理を委譲したり、「実装されていません」なんてエラーを返す
だけの多数のメソッド、とかを。

それはそれで別にかまわない(長くなるだけでできることは一緒)なんだけ
ど、templateという強力な syntax sugar があるのに、それを使わないの
は不自然、というようなこと。
0423デフォルトの名無しさんNGNG
Eiffelの多重継承がC++にほしい
0424デフォルトの名無しさんNGNG
型を確定した関数templateのアドレスをとる方法ってある？
0425デフォルトの名無しさんNGNG
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;
}
}

こんな感じ？
0426425NGNG
いやこのほうが賢そうか。
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;
}
0427デフォルトの名無しさんNGNG
思いっきりエラーが出るぞ
リリースモードなら最適化でコードがかき消されるから通ったように見えるが
だいたいテンプレートを作った意味が無くなっている
0428デフォルトの名無しさんNGNG
ネームスペースを止めて、ちゃんとインスタンス化構文に
したら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もちゃんと「型を確定した」って行ってる。
0429デフォルトの名無しさんNGNG
>>428
template int add(int, int);
この行無くても動かない？
0430デフォルトの名無しさんNGNG
IBMのICLUIとかのネタが出てないのはみんな知らないの？
VisualAgeC++とかでも使われてるはずなんだけど。

あのクラスライブラリはコテコテでかなりカッコイイ。
エラーはすべて例外で処理されてるし。
ほとんどのメソッドの戻り値がオブジェクトへの参照ってのがイカす。
0431デフォルトの名無しさんNGNG
現実の事象を中心にとらえ過ぎるのはいかがなものか？
継承は手段としてはすごいと思うが
それをそのまま採用するのは敷居を高めているような気がする。
人間らしさとコンピュータらしさの双方を兼ね備える言語＆方法論出てこないものか？
0432デフォルトの名無しさんNGNG
>>431
時代に追いつけないなんちゃってソフトウェア技術者みたいなこと言うなヨ
0433デフォルトの名無しさんNGNG
こういうスレができる事自体、C++の使いづらさを物語ってるな。
0434デフォルトの名無しさんNGNG
アニメの世界に目を向けてみよう。
アニメの世界は幼稚な絵からどんどん細かくなり
しまいには飛行機の絵にネジを書くまでに至った。（マクロスとか）
これがＣ＋＋だ。
しかし最近のアニメはだんだん絵がシンプルになり
絵の書き込みよりスムーズな動作に比重が移った。
これがJAVAだ。
しかしJAVAはまだ過渡期の言語だ。
C++からJAVAに移行した程度の流れがもう１度あるだろう。

さぁ皆ツッコメ。
0435デフォルトの名無しさんNGNG
>>434
あるんじゃない、でも C 言語の進化系としては嬉しくない。
C は、その驚くべきシンプル（当時）さと、機械語レベルに最も近い構造をもちながら、究極のソフトウエア開発論法（当時）その進化系としての C++ を考えるならば java は違うと感じる。
何かが違う、低級言語 C 進化系として java は認めたくない。 java はやはり高級言語だ。
さりとて C++ には満足できないが・・・
0436デフォルトの名無しさんNGNG
>>431
人間らしさなんてものを、厳密さがメリットである計算機に
期待するところはアホクサイと思うが、
継承どうよ？という意味では色々考えることはあるな。

こんなの発見。「継承じゃなく修飾」だそうだ。
言ってること全部が正しいとは言えまいが、
一部は参考になると思われ。
http://www.yy.cs.keio.ac.jp/~suzuki/docs/mct/modification01.html
0437デフォルトの名無しさんNGNG
>>435
ObjectiveCなんかはどう思う？

構文は(C++に比べれば)恐ろしくシンプルだ。
なぜシンプルに出来たかというと多分
動的な部分が多いから静的な言語仕様を
肥大させずに済んだんだろう。

メソッドの本体はCそのものと大差無い書き方が出来る
(当然コンパイル結果のバイナリも推して知るべし)が、
一方でメソッドディスパッチ(仮想関数の呼び出し)処理が
ruby/smalltalk並の動的処理。

高級アセンブラ度という意味では、
メソッド本体は満たしているが
メソッドディスパッチはそうではない、という感じ。

ただ、C++だってvirtualが(設計上)必要になれば
どうせ内部的に同じような仕掛けにならざるを得ないから、
おんなじようなもんだ。

結局C++の言語仕様って、骨折り損のくたびれ設けにしか見えぬ。
0438デフォルトの名無しさんNGNG
みんな例のジョークは知ってるよね？
あれはジョークにしたって所がジョークなんだよ。
0439デフォルトの名無しさんNGNG
最近まわりがJavaばっかなんで自分もJavaってみたり。
やっぱ Java って C -> C++ -> Java っていう感じで「進化型」なんですかね。
C# は使ったことないんでわからないけど。
GCC の C# フロントエンドがあればなぁ。一度使ってみたい。
0440オタクの卵NGNG
Ｃ＋＋とオブジェクティブＣではどっちがお勧めですか？
わかる人はいろいろな点で比較して教えてください。
0441デフォルトの名無しさんNGNG
ヲタなら自分で使ってみな。
0442デフォルトの名無しさんNGNG
いや、自分で試そうとせず外野から好き勝手言ってこそヲタ
0443デフォルトの名無しさんNGNG
そか なるほど 間違ってたわｵﾚ>>442
でも440はお勧め教えてクレとかイってるぞ

ちなみに俺はオブジェクティブCが超オススメです >>440
なぜっておれわ使ったこと無いから
0444デフォルトの名無しさんNGNG
>>440
漏れのオススメはC++です。
理由は初心者が苦しんでくれるからです。
さらにオススメなのは、MASMです。頑張ってください。
0445デフォルトの名無しさんNGNG
ある村に魔法使いの女の子がやってきました。
魔法使いの女の子は村人が魔法を使えないので驚いてしまいました。
魔法使いの女の子の国では魔法なんて当り前です。

それで魔法使いの女の子は村人に魔法を教えてあげることにしました。

「ほら、こうやるんだよー」
魔法使いの女の子がお皿に手をかざすと
そこに美味しそうなケーキが現れました。

それを見た何人かの村人は魔法を使えるようになりました。
魔法を使えるようになった村人は家に帰って家族に魔法の
使い方を教えます。

こうやって魔法が使える人はどんどん増えていきましたが
どんなに頑張っても魔法の使えない人もいます。
魔法の使えない村人の前で何度実演してみせても
どうしても魔法が使えないのです。

そんなC++が大好きです。
0446デフォルトの名無しさんNGNG
プログラミング未経験の新人に「やり方教えて手伝ってもらえ」と言う上司と
「やる気はあるんでどんどん仕事回してください」という幸せな新人。
蓋を空けてみればＣ＋＋おろか
コンピュータに一度も触ったことがない珍人だった。
0447デフォルトの名無しさんNGNG
ふつうじゃん
0448デフォルトの名無しさんNGNG
普通....なのか？
0449Ｇ13（ゴルゴダの丘）NGNG
同じオブジェクト指向言語で同じＣ系列言語
オブジェクティブＣとＣ＋＋
どっちが簡単なんですか？同じオブジェクト指向でも
その内容はけっこう違うのですか？
0450デフォルトの名無しさんNGNG
オブジェクト指向と言語は関係ありません。
私はCプログラマですが私の書くプログラムはオブジェクト指向です。
指向とは考え方でありプログラムとは関係が無いということです。
0451デフォルトの名無しさんNGNG
>>445
ﾅﾙﾎﾄﾞ!!
0452名無しさんNGNG
>>450
青果物に対してのオブジェクト指向が出来てません。
0453Ｇ13（ゴルゴダの丘）NGNG
>>450
そうですか、わかりました。
ところで>>449の質問に答えてくれる人はいませんか？
0454デフォルトの名無しさんNGNG
>>445
その話泣けるね。
なぜ使える人と、使えない人が出来てしまうんだろうね。
0455名無しさんNGNG
Javaはだれにでもできる。
C++はだれにでも出来るわけじゃない。

おれは誰にでも出来る言語の方がいいな。
0456デフォルトの名無しさんNGNG
>>453
>>449の回答が>>450だ。
意味がわからないならかじめ焼いて寝ろ。
0457デフォルトの名無しさんNGNG
JAVAは誰にでも使えます。
しかし常に最良のプログラムを書くためには
JAVAの動作を正しく理解する必要があります。
C++は正しく理解しなければ使えないでしょう。

C++を理解した人はJAVAの動作を正しく理解することが出来るでしょう。
しかしJAVAから学んだ人はインスタンスや参照を正しく理解できるのでしょうか？

アスカは「ATフィールドの意味が判った」と言いました。
使える事と理解することは別なのです。
より正しく理解する。
それが上級者への一歩なのです。

そういった意味ではC++は素晴らしい言語でしょう。
全てを理解した人には関係無いですが
初心者にとってどちらが良いかはその人が
何を望むかによって決定されるでしょう。
0458デフォルトの名無しさんNGNG
>>445=>>457?

あなたオモロイな、微妙に
0459デフォルトの名無しさんNGNG
>>457
アスカは最終話付近で廃人になりましたが、その辺りの関連性は？
0460デフォルトの名無しさんNGNG
一部（１人？）のレスにより良レスへ変身中。
0461デフォルトの名無しさんNGNG
>>458
全てを理解したからといって過信は禁物です。
時に膨大なマンパワーを投入しなければならない懸案もあるでしょう。
初心→理解→自信→過信。
彼女は典型的な秀才プログラマの失敗例です。
人のフリ見て我フリ直せとは正にこの事でしょう。
0462デフォルトの名無しさんNGNG
>しかしJAVAから学んだ人はインスタンスや参照を正しく理解できるのでしょうか？

C++の問題は、
「だったら、C++から学んだら、インスタンスや参照を
(必ず)正しく理解できるのか？」
というと、全然そんなこたーねぇ、という点だな。

Javaとの比較でいえば、むしろ理解しやすさが弱い…
というか正確にいえば「誤解しやすさが強い」と
言うべきだろう、C++は。

それが証拠に、未だに未だに、Instance変数を
Class変数と呼ぶ馬鹿が、C++界隈には何故か絶えない(わら

Javaより10年も前に骨格が出来ちゃった、
時代遅れ言語だと思うぞ、あれは。

そして、これが一番痛いのだが、それゆえに
「古い教育方法」という過去の資産が多数存在する。
資産といえば聞こえがいいが実際は間違いが多くて
かえってOOP教育を阻害したりする。死産。

ちなむと、参照の理解に一番良いと言えそうな
手近なメジャー(?)言語といえば、今ならrubyだろう。
0463デフォルトの名無しさんNGNG
>>462
ruby信者逝ってよし！
ちなみにオブジェクティブＣとＣ＋＋の違いをだれか教えてください。
0464デフォルトの名無しさんNGNG
MSがボーランドを買収して全部Delphiにすればいい。
0465エログラマNGNG
>>464
それじゃ逆に全部ＶＢになりそうね。
0466デフォルトの名無しさんNGNG
ObjectiveC はＣ言語にsmalltalkを取ってつけた言語。
C++はＣ言語のstructをclassとして扱えるように拡張してみた言語。
どちらも急造品であることに違いは無いね。
でもObjectiveCは本流から取り残されていて、標準規格すらないよ。

JavaでもC++でもいいけど、オブジェクト指向を取り入れていかないといけない。
C++はスキルさえあれば、しっかりとオブジェクト指向した上で安全なコードを書ける。
Ｃ言語でもオブジェクト指向できるけど、スキルがあっても危険なコードしかかけない。
Javaは誰でも安全なコードを書けるけど、しっかりとオブジェクト指向するには結局スキルが必要。
スキルがある人にとっては、JavaもC++も変わらない。むしろC++のほうが、
ジェネリックプログラミングできるし、実行速度も速くて都合がいい。
0467デフォルトの名無しさんNGNG
こんなところで議論交わしたところでC++好きはC++好きのままだし、C++嫌いはC++嫌いのまま。
ただお互いが自分の意見を主張しあっているだけで何の意味も成していない。時間の無駄。
0468デフォルトの名無しさんNGNG
C++が難しいとは思えないが・・・
個人的にはJavaが好きだな。
>>467
んなこと言ってたら２ちゃんの存在価値は無いと思われ・・・
0469デフォルトの名無しさんNGNG
>>>466
>実行速度も速くて都合がいい。

速いというほど速いのかC++？
そりゃネイティブなんだから少しは速くないと
やってられんけど、逆にいえばimodeなんて糞にまで
Javaが載せられるのは何故だ？という話になる。

JVMを「終了しない」ことが必要なんだろうな。
アプリ(??)を終了するごとにJVMごと終了するってのは
ネイティブアプリで喩えれば、アプリ終了ごとに
OSをシャットダウンしてる(次のアプリを起動するごとに
OSを再起動する)ってのと同じだ。
これじゃ遅くて当然だし、そんなレスポンスの比較の仕方じゃ
不公平すぎて話にならん。

つーわけで、上げっぱなしのVMの上で
(例えばデスクトップなら)shellみたいなものを動かして、
そこから.classをloadするようにでもすべき、だろうな。
これでやっと互角の比較が出来る。
0470デフォルトの名無しさんNGNG
C++は、難しいとかどうとかいうよりも、煩雑だ。

3個の概念があれば出来そうな仕事に
10個の概念を投入して、それら10個を
結局全部理解してないとまともなプログラムを書けない。

そりゃ頭がまともでパズル好きな人間には
10個を間違いなく理解することは可能だ。
だが、面倒、だ。

たとえば、初期化と代入の違いを、意識しすぎてる。
そんなもん代入一本槍でも十分だろうに。
パフォーマンス上の都合が悪いなら
最適化で頑張りやがれ。

あーいうのを自意識過剰っていうんだろう。
10個も機能があって、ボクはなんて世間に貢献してるんだ！などと
ドキュな妄想に浸ってる。3個で十分なんだよ。引退しろロートル。
0471デフォルトの名無しさんNGNG
今は亡きNeXTSTEPでObjectiveCやってたけど、かなりいい感じだった。
Java並に簡単だと思われ。
C++はなんであんなにでかくなっちゃったんだろう・・・そんな俺はC++使い
0472デフォルトの名無しさんNGNG
今は無きPC9821でN88BASICやってたけど、かなりいい感じだった。
ＨＳＰ並に簡単だったと思われ。
ＶＢは何であんなに重くなっちゃったんだろう・・・
そんな漏れはVC++。
0473デフォルトの名無しさんNGNG
このスレ馬鹿ばっかし
0474デフォルトの名無しさんNGNG
>>473
そうでも書かないと、自尊心が維持できないキチガイ（藁
0475デフォルトの名無しさんNGNG
>>469
この種の比較は納得できない。
Ｃ言語は元々ハードウェアを直接叩くような用途も考慮に入れた仕様の代物だ。
ＪＡＶＡはあくまでも高級言語だ、もうすでにＣの後継でもなければＣ＋＋の後継でもない。
Ｃ＋＋は腐っても、Ｃの後継言語であってＪＡＶＡとは違う。
Ｃ言語系のコンパイラは危険なコードはかけて当然の構造を持っていなければならない。
機種依存はしようと思えばすぐにできるし、したくなければしなくても良いようになっているのが正しい姿だ。
Ｃ言語には高度な言語機構というポリシーとともにもう一つ、自己責任原則の元何をしても良いという重要なポリシーがある。
Ｃ言語の後継言語である、Ｃ＋＋にも当然、自己責任で何でもできること、これができないＣ＋＋に意味はない。
極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。
ＪＡＶＡなんぞは、Ｃ＋＋で作られたＶＭの上にでも乗ってれば良いのである。
0476デフォルトの名無しさんNGNG
>>475
俺もC++派だし、キミのいうことは最もだと思うけど、
Javaを卑下する必要は無いでしょう。
独自ハード用のコードや、ゲーム機、ドライバなんかを書きたければC++。
アプリを作りたかったらJavaというふうに、住み分けすればいいのでは。
住み分けというより、Javaを使えないような環境でオブジェクト指向しようと思ったら
C++しか選択の余地が無いんだけどね。
0477デフォルトの名無しさんNGNG
>>475
>Ｃ＋＋は腐っても、Ｃの後継言語であってＪＡＶＡとは違う。

ああ。C++とJavaの血縁なんていう妄想は、俺も信じちゃいない。
たまたま文法の似た言語なんて、作ろうと思えば
(実際Javaはわざとそうしたんだろうし)幾らでも作れる、というだけ。

でなのだが、ならばJavaじゃ駄目な場合には
選択肢はC++しかないのか？ってのを考えないとね。

それこそObjectiveCとかでもいいんじゃないか？という話。
自己責任つー意味では、しょせんC派生言語だから
同じ問題はたとえ嫌でもついて回るし、
まして積極的にやりたければ以下略だ。

>極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。

てゆーか、そこまでやりたいなら「OOP言語」を使わないほうがいいよ。
構造体をどうぞ。
0478デフォルトの名無しさんNGNG
>ＪＡＶＡなんぞは、Ｃ＋＋で作られたＶＭの上にでも乗ってれば良いのである。
お〜ま〜え〜な〜、そういう余計なことは書かんでもえ〜の。

>>極端な話ｐｒｉｖａｔｅメンバであっても、属性キャストなりでアクセスできて良いと思っているくらいだ。

>てゆーか、そこまでやりたいなら「OOP言語」を使わないほうがいいよ。
これは、たまに欲しくなるんですがどう思います。
例えば、デバッグ中でちょいと、とある非公開メンバ関数の反応確かめてみようと
する時、いちいちヘッダファイルまでいって public にしたりとか、めんどくさいです。
最後に残骸が残ってないかワーニング出せるオプション付きで。
0479デフォルトの名無しさんNGNG
Objective-Cはもう時代遅れの感が否めない。使われてるのMac関係だけだし。
0480デフォルトの名無しさんNGNG
>>465
なんでDelphiがVBになるのよ。
DelphiをVBなんかと同列に・・・、いや止めとこ。またこじれる。
0481デフォルトの名無しさんNGNG
C++は言われているほど難しくは無い。
でもVC++でWindowsのプログラムを作るのが難しいから、
難しいと言う印象だけが先走っている気がするんだよね。
0482デフォルトの名無しさんNGNG
>>481
「言われてる」ってのがそもそもどの程度なのか？によるよな。

少なくともC++以外のフツーのまとも(わら)な多数のOOP言語を
見たあとでC++を見ると、結構おなかいっぱい、いや、ゲリするね。
ゲリってのは、「食い物じゃないもの」まで混じっているから。
つまり、OOPと、OOPと馴染まない(わら)他の色んな機能と、が
渾然一体となってるんだもん。

ところで、「super」に相当するキーワードが存在しないのは
あまりにも痛くないかC++？
親クラスのメンバを参照したいときにクラス名を
ベタ書きしないとならんだろ。匿名性(?)が無い。

ベタ書きは多重継承があるから「しかたない」という声は有ろうが、
だからって許されることと許されないことが有るぞ。
あるいはtempleteで誤魔化す(元々存在しない匿名性を
templeteで擬似的にやる)ことができるぞという意見もあろうが、
誤魔化しが必要な時点で既に腐っているだけだし。

なんで匿名親クラス参照キーワード(?)のsuper(のようなもの)を
なにがなんでも実装しよう！と心血注がなかったかな作者は？
力のかける方向が変なんだよ、C++は。

>>479
憎まれっ子世に云々って感じだぞ、少なくともC++について言えば。
C++なんて屋上屋を架してるんで、上が新しい(優れてるのと同義とは
限らず、付け焼刃という単語も存在するが)ようでも、
下の地層には古生代の化石が埋まってるぞ。

逆にSmalltalkみたいに、最初からWellDesignedな言語は
時間が経ったからってそうそう多くの仕様を追加する必要に迫られない。
0483482NGNG
すまん。482の補完。

最初の部分。別にOOPにあらずんばヒトにあらずと
言いたいわけじゃない。別にそうでなくてもいい。
ただ少なくとも、OOP言語だと大々的に名乗りながら
初心者(わら)に近づくのだけは、やめてくれ。
結構あれでOOPドキュな困った初心者を作ってしまうんで。

化石(わら)の話。
C++みたいなアーキテクチャの言語…つまり
C++を真似た(C++の直系の子孫は除く)言語って、
聞いたことないんだよな。

真似されてないってのは、それだけ、
使えない、あえていえば古い、アーキテクチャ
なんだと思うぞ。

アーキテクチャでいえば、むしろsmalltalk系とかのほうが元気だろ。
0484デフォルトの名無しさんNGNG
>>482
superが必要になる場合ってどんなとき？
静的リンクが前提なら不要なのでは？
例えばGoFパターンの中でそれが必要なのはどれ？
templeteで誤魔化しといわれても、そんな誤魔化しは
したことないから、不必要な批判をしているように見える。
もっと素直に実装できない？
0485デフォルトの名無しさんNGNG
>>484
>superが必要になる場合ってどんなとき？

ちょっと呆然とした。
なんでこんな質問をするんだろうこのヒトは？という意味で。

「必要」を言われたら、言語なんてアセンブラでいいぞ、という
恒例の話になるだけだ。
つまり、「いちいちsuperclassの名前をコピペするのって、
うざくないか？(反語)」と俺は言いたい＊だけ＊なのだが、
まぢでうざいと思ったことがないのか？

>例えばGoFパターンの中でそれが必要なのはどれ？

有るわけないだろ。「そんなC++ですら」記述できるように
最初からチューニングされてるんだからさ、GoFパターンは(笑)

>もっと素直に実装できない？

なんでそこで実装という一番卑近な部分しか思考できんかなあ？
以下、アセンブラ問答は、略。

なんてことはないよ。superclass名なんて
1つのクラスにまつわるソースを書く間に
たった一度書けば十分だと思わないのか、ということだよ？

ちなみに、コンストラクタ(とデストラクタ)がクラス名と同名だ、
という風変わりな考え方は、キャストとコンストラクトを
同一視しようという、C++のぶっ飛んだ(誉めてない)考え方を
反映しているという意味ではパズル的に面白いが、
実利的には却ってうざいだけだな。
コンストラクタ名をある一定の名(やその類似)にする
というほかの多くの言語が採った道のほうが、ずっと楽。
というわけで、最低3回(わら)書くのを1回に減らす方法がコレだ。

あと、ヘッダーにメソッド実装を書かないならば
メソッド実装の頭にクラス名がそれぞれ必要だという奴は、
C流の古典的なソース管理方法を流用した付け
(Javaで克服されてる)に過ぎないんで、
言うもあほくさいんで、さておく。

で、次にsuperclassの名を思い出す作業がしばしば必要になるわけだ。
これはデバッグのときにpublicとかどうとか直すのと
匹敵する手間だと思う(わら
ヘッダーをあっちこっち飛びまわらないとならんから。
0486デフォルトの名無しさんNGNG
>>484
すまん。くどくど長すぎた。
一言で終わる説明を今ヤット思いついたよ。

両親を「おやじ、おふくろ」と呼ぶ必要があるときってどんなとき？
…などと君は問うのか？

毎度毎度本名で呼ぶのか？メリット有るのか？
自分の両親は自分(プログラマじゃなくてそのclass)が
知っている(のでいちいちプログラマが教えなくて済む)
というものじゃないのか？

まぁそういう文化圏でも悪くないとは言えなくはないが、
さすがに迷子のアナウンスでは困るよな。
「みずほ保育園の3歳の高橋よしのり君のお父さん、よしのり君が迷子に
なっております」というアナウンスを出来ないことになるからな(わら


あと、リンク形態は全然関係無い概念だ。
なにも本当に親クラスが実行時まで未知な場合を
サポートしろっていう話を、しているわけじゃない。
#それはそれで欲しい機能だが話は別。つーかC++じゃ絶対無理だろ。
#ん？保育園の喩えは、どっちかってーとそれになっているか。まぁいいや。
0487デフォルトの名無しさんNGNG
>>482
お前みたいなキチガイがいると話こじれるんじゃ氏ね
オレもなー（鬱
0488デフォルトの名無しさんNGNG
>>485
おいおい、呆然とさせられるのはこっちのほうだよ。
アセンブラでいいという話に結び付けないでくれよ。
C++でオブジェクトをconstにできるのは、
オブジェクトを不用意に書き換えまいとする必要性があるだろう？
そういうレベルで話をしようよ。

「superが無いのはあまりにも痛い」とまで言うのだから、
必要性について聞くのは当然だと思うがどうか？
485を読む限り、あまりにも痛いというには無理があると思う。
0489デフォルトの名無しさんNGNG
>>488
だからー、煽りにのんなよ。
0490デフォルトの名無しさんNGNG
superはparentじゃないだろう。

日本人−人間−脊椎動物と継承しておいて、
よしのりくんと、そのお父さんはどちらも日本人で、
親子関係はCompositeパターンあたりで人間のツリーを構築して、
よしのりくんのお父さんを知りたいときはよしのりくんに対して
GetParentするというのが、今時のオブジェクト指向だよ。

さて、よしのりくん自身が、「自分の人種を自問自答する」
ことはあるのか？　そういうケースもあるかもしれないけど、
言語として専用のキーワードを割くだけの価値があるとは思えないな。

C++は常に悪いイメージを持たされているから、
こういうレベルの低い奴も批判的な意見を言い出し、
それがさらにC++のイメージを悪くして、
ネガティブスパイラルに陥っていると思う。
0491デフォルトの名無しさんNGNG
>>470
初期化はスタティックローカル変数に必要だよ。
じゃないと、呼び出す毎に代入されてしまう。
0492デフォルトの名無しさんNGNG
>>3
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
これか？
0493デフォルトの名無しさんNGNG
個人的には、MFCにマンセー。
動きはトロいし、バグはおおいし、EXEバカでかいし。
でもさ、サクっと一見機能満載のかっこいいアプリ作れるから、
上司ウケ最高。
おいらとしては、OOもC++もクソだけど、ＭＦＣマンセーです。
0494デフォルトの名無しさんNGNG
ただひたすらC++を叩くだけの人にろくな奴がいない事実
0495デフォルトの名無しさんNGNG
>>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で楽させて欲しいと思う。
0496デフォルトの名無しさんNGNG
>>488
>そういうレベルで話をしようよ。

ああ。すまんすまん。それはそのとおりだ。

ただ、ifやforや関数が無くてgotoしか無い言語を使って
今時満足してる人に、「ifなんて必要なのか？」
と問われたときと、同じ衝撃を感じてしまったのだ、と
感想を説明しとくよ。

ちなみになんで汗なんてことを言い出したかというと、

>もっと素直に実装できない？

素直という単語に笑ってしまったからだ。
もしかして、「具体的に」書くことが「素直な」書き方だ、
などと思っていないよな？
もし思っていたら、それは汗云々な思考だ。
計算機言語の言語は抽象化(=不要な具体的記述を捨てる)して
便利にしていくという歴史だろ。

さて。汗の話はこれで済ます。すまん。
本題に戻ろう。
0497デフォルトの名無しさんNGNG
>>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方式なので、ディスパッチ処理が遅いわけじゃない)
それを呼ぶ、というところまでやってくれる。
何をどう呼ぶべきかを、文法レベルで確定することが出来るわけな。

これを便利じゃないとでも思うか？
0498デフォルトの名無しさんNGNG
アホか。
基底クラス名が複数回出現するときの常套手段。
class A : public B {
typedef B super;
...
};
またクラス名を書く回数が増えたって？
一回くらい増えたからってどうってことないだろ、いまさら。
0499デフォルトの名無しさんNGNG
多重継承や菱形継承を許しているC++ではsuperみたいなキーワードを
言語仕様で面倒見るわけにいかないもんな。
0500デフォルトの名無しさんNGNG
以上ですね(ワラ
0501デフォルトの名無しさんNGNG
多重継承など親クラスが明確でない場合のときだけ
superキーワード使用不可にすれば良い。

だからsuperキーワード必要無しの理由にはならない。
実際に多重継承と単一継承では使用する頻度は単一継承の方が多いんだし。
0502デフォルトの名無しさんNGNG
>>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()がどうなるか静的に管理しろってか。
0503デフォルトの名無しさんNGNG
>それぞれのクラスでsuper::hoge()がどうなるか静的に管理しろってか。

それこそ楽勝だろう？
それを言うならメンバ変数/関数の名前だって
コンパイラは頑張って(わら)どのクラスの奴か
解釈(=静的に管理:virtualも実装はさておきInterfaceは
コンパイラが静的に管理)してるわけだろう。
それとどう違うんだ？

親クラスが複数になってるクラスではコンパイルエラーにし、
そうでなければ一意に確定。
なんの問題がある？どんだけの手間がかかる？

実際、typedefという超簡単な手段で、
手作りで(わら)同じことが実現できてるわけじゃん？
言語仕様に入れるのは、実装の手間があとちょっと有るだけだぞ？
しかも無矛盾性も( >>498がまさにやってくれているが、
typedefで似たようなことが実現できることから判るように)証明済みだ。

そういや、ifやforすら言語仕様じゃなくライブラリで提供する
というおっかない言語も存在するよな。
でもだからって大抵の人(わら)は、ifが言語仕様じゃなくても
イイヤとは、あまり言わないだろう？そういう次元の話よ。

ところで今気づいたが、
>super::hoge()
って、superという単語でclassを指すもんだと思っているのか？
ふつーはinstanceを指すもんだよ。
#dynamic_castかなんかを使ったらsuper.hoge();とかを書けるようになるのかな？
0504デフォルトの名無しさんNGNG
>>499
>多重継承や菱形継承を許しているC++ではsuperみたいなキーワードを
>言語仕様で面倒見るわけにいかないもんな。

ところで質問なんだが、
菱形継承のときの心配を改めてする必要が、あるのか？
多重継承についてだけ心配すれば十分なんじゃないのか？

菱形継承のとき、どのclassを経由して継承したか？というのを
いちいち記述しないとならないor記述することができる
のだったっけC++って？
そんな機能は無かったと思うが？

さもないと、祖父母の代を考慮する(菱形ってことは
結局そういうことになるよな)なんてのは無意味だと思われ。
0505デフォルトの名無しさんNGNG
すげえな・・・モノホンか。
夏だなぁ。
0506デフォルトの名無しさんNGNG
ガムテープの接着麺同士を張り合わせた状態です。
0507デフォルトの名無しさんNGNG
str.replace('麺', '面');
0508デフォルトの名無しさんNGNG
>>503
言い方は気分悪いが、内容は同感。
superがないと継承関係の結びつきが強くなりすぎる。
0509デフォルトの名無しさんNGNG
503は別に当たり前のこと言ってるだけだし、一方の typedef 派も
typedef で別に何も困らないから至極まっとうな主張だと思う。
でも、

>>super::hoge()
>って、superという単語でclassを指すもんだと思っているのか？
>ふつーはinstanceを指すもんだよ。

C++ の文法ならふつー super::hoge() って方向で記述することに
なると思うけど。1から10までSmalltalk の話がしたいんなら、
Smalltalk スレでも立てれば、って気がしないでもない。
0510デフォルトの名無しさんNGNG
たぶん何を言ってもわからないのだろうけれど、
C++はsuperというキーワードを実装できなかったのではなく、排除したんだよ。
そこを履き違えないように。

ANSI規格化のときに、多くの議論が交わされ、多くのキーワードが提案された。
ISO/ANSIで規格化するということは、どこかの企業や個人が身勝手に決めたのではないと言うこと。
それまでに多くの激しい議論が交わされ、大変な時間がかかっている。
結果として、super、inherit、baseというキーワードは排除された。
その是非はともかく、少なくとも何らかの意図があって決められているのであり、
誰かが付け忘れたとか、実装できなかったとかいう話ではないだよ。
0511デフォルトの名無しさんNGNG
C++にsuperが無い場合
「基底クラスを指定するのにクラス名を書かないといけないなんてダサイ」

C++にsuperがある場合
「多重継承するとsuperが使えなくなるなんてダサイ。統一感が無い。C++ってやっぱり複雑。」
0512デフォルトの名無しさんNGNG
>>509
>C++ の文法ならふつー super::hoge() って方向で記述することに
>なると思うけど。1から10までSmalltalk の話がしたいんなら、

おいおい。だから、そんなC++「が」ふつーじゃない、
という話なんだってば。他の言語見まわしてみろよ。
superという単語をそういう意味で使わないことで
ナニを得するか？というと、単にC++内輪の互換性だけ、だ。

単に今、他と同じような意味のキーワードsuperが存在しない、
というだけのことだろ。
新しい(それなりにおかしくない)文法を「考える」脳が君には無いのか？
#採用しろとまで言うのは遥か先の段階だが。

>少なくとも何らかの意図があって決められているのであり、
>誰かが付け忘れたとか、実装できなかったとかいう話ではないだよ。

だれもつけ「忘れた」なんて言ってないよ。
その意図が変だ、と言ってるの。

規格は神様か？そりゃ今存在するその言語を「使う」時には
絶対尊重せんとならんが、そもそもその規格どうよ？という話
をしているときに、「でも規格ですから」じゃ話になるまいよ。

なんであんな美味しいものを排除しちまったんだか…可哀想に…
と言ってるんだよ。

>>511
いや、そこまで鞭打つ気は無いよ俺も(^^;

別に、他の案でもいいんだぜ？
継承するときに最初に書いたクラス名をsuperに割り当てる、とかな。

強く言うつもりは無いが、多重継承にしても
C++と違って新しい(笑)他の言語では、
「差別」をしているよな。
1つのメイン親と任意個のサブ親っていう感じ。
rubyのmoduleとかjavaのinterfaceとか。

全く同じ考えをC++に導入する必要があるとまでは言わないが、
せめて、(親クラスを作るときじゃなく)継承して子クラスを作るとき辺りに
差別を付ける仕掛けとかが有っても良かったんじゃないかな、とは思う。
0513デフォルトの名無しさんNGNG
一言でいえば、
>どこかの企業や個人が身勝手に決めたのではないと言うこと。
>それまでに多くの激しい議論が交わされ、大変な時間がかかっている。

単に、「今更引き返せなかった」というのが答えだと思う。
3年間(わら)の痛みに耐えられないだろうと判断したのだろう。

まぁその判断自体は正しいかも知れないな、
現存するC++勢力というものの存在を認めるからには(笑)
0514デフォルトの名無しさんNGNG
＞おいおい。だから、そんなC++「が」ふつーじゃない、

誰もC++が「ふつー」だなんて主張してねえって。
0515デフォルトの名無しさんNGNG
virtual typedef
が欲しい...
0516デフォルトの名無しさんNGNG
>>512
規格だから尊重しろなんてどこに書いてあるよ。
どうしてそういうふうに読めるのかさっぱりわからない。
大勢の優秀な人間たちが十分な議論の上で検討する場があったと言っているのだよ。

お前は当時交わされたであろう議論と同じモノを、
低いレベルでしているだけなんだよ。

>別に、他の案でもいいんだぜ？
>継承するときに最初に書いたクラス名をsuperに割り当てる、とかな。

マジかよ。superがどっちを指しているのか、ヘッダを見るまでわからないのか？
間違って別のsuperを指していたとしても気づかないことがあるぞ。
場合によってsuperが付けられたり付けられなかったりするのか？
そんな統一性の無い言語があっていいのか？
0517デフォルトの名無しさんNGNG
>>512

>>C++ の文法ならふつー super::hoge() って方向で記述することに
>>なると思うけど。1から10までSmalltalk の話がしたいんなら、
>
>おいおい。だから、そんなC++「が」ふつーじゃない、
>という話なんだってば。

すげー、ここまで堂々と「ふつー」の指している意味をすり替えるか・・・
0518デフォルトの名無しさんNGNG
typedef一行で済んでしまうものなのに、なんで予約語を増やす必要があるんだ。
それとも super.hoge() って書きたいのか？ そういう書き方を許す様にもできる
けどバカバカしいから誰もやらんだろな。
0519デフォルトの名無しさんNGNG
>お前は当時交わされたであろう議論と同じモノを、
>低いレベルでしているだけなんだよ。

一つだけ違う点があるぞ。
必要(わら)以上の過去との互換性は切っちまえ、と
考えた上でのこと、という点だ。

>マジかよ。superがどっちを指しているのか、ヘッダを見るまでわからないのか？

あ。そうか。たしかに辛いか。
だが、差別つき継承の考えを組み合わせれば、そんなに変じゃないぞ。
rubyみたいに「継承は実はあくまで一直線だ」という考え方も出来るし。

少なくとも「統一性無い」ってのは関係ないだろ。
どこを「統一」するかなんてのは考え方次第だ。

>>517
>>>C++ の文法ならふつー super::hoge() って方向で記述することに
>>おいおい。だから、そんなC++「が」ふつーじゃない、
>すげー、ここまで堂々と「ふつー」の指している意味をすり替えるか・・・

どこが摩り替えてるんだ？
C++における普通(の幾つか)なんて捨てちまえ、別の普通を持ってこようぜ、
と言ってるのだが？
ふつーという単語の意味は摩り替えてなんかないぞ。

>>518
>それとも super.hoge() って書きたいのか？そういう書き方を許す様にもできる
>けどバカバカしいから誰もやらんだろな。

うーん。それが馬鹿馬鹿しくないことは、前述のとおり、
他の多くの言語を見れば状況証拠として十分だと思うが？

てゆーか、「誰も」ってのは実は
C++言語に思考を規定された人間のことか？
ならばトートロジーだな。
0520デフォルトの名無しさんNGNG
C++はおもろいよ。
0521デフォルトの名無しさんNGNG
言語仕様が膨大なので、
とりあえず必要不可欠なことだけ覚えて使えばいいと思う。
0522デフォルトの名無しさんNGNG
＞うーん。それが馬鹿馬鹿しくないことは、前述のとおり、

多重継承が許される場合において馬鹿馬鹿しくないと言うのは証明されていませんが？
0523デフォルトの名無しさんNGNG
現実問題としてJavaじゃ実用にならない場面が多いんだから仕方ない。
0524デフォルトの名無しさんNGNG
STL, templateって、いつ頃から出てきたのですか?
私が初めてC++を触ったときは、そのような言葉を聞かなかったのですが。
0525デフォルトの名無しさんNGNG
>>524
少なくともSTLはC++より後です
0526デフォルトの名無しさんNGNG
>>525
そうだっけ？
0527デフォルトの名無しさんNGNG
例外処理、実行時型情報、templateときて、STLでしょ。
もうシンタックス多すぎて嫌。
他の言語に逃げました。
0528デフォルトの名無しさんNGNG
>>524
http://www.geocities.com/nobukichi/Stl/lec001.html
ここにいいこと書いてあるよ。

さらに補足すると、ANSIの標準化委員会は、STLを採用するために、
練りに練ったクラスライブラリをほぼ全部捨てたんだよね。
0529デフォルトの名無しさんNGNG
>>522
なるほど。ちと考えとくわ。反例がないこたぁないはずなんだが。

だが一方で、C++の愚直な(わら)やり方しか手が無いのか？という
問いにもまた、YESと答えるにはちと考えないとならんよな。

そりゃそうと、そこでの瞬間論点は、
superがclassを指すかinstanceを指すか、という話題
だったように記憶しているが、なんか変じゃないか？
まぁいいが。

>>524
templateはTurboC++2のころはまだだったっけ(笑)
するってーと、10年は経った…っけ？

>>526
ナイスすぎる。「Standard」TLという
C++につけるライブラリの仕様は、そりゃC++より後だろう。

>>527
というか、その辺のもの一通りを(しばしば最初から)搭載してて
#あ。templateは無い奴が多いが。
なお大してでかくない言語仕様な言語が多数有るわけで、
C++がちょっと定方向進化説の体現者になっちゃってるのは
間違い無いと思う…

>>523
別にC++ or Javaという白黒どっちかしか無いわけでもあるまいし…
0530デフォルトの名無しさんNGNG
template が使えるメジャーな言語ってだけでも C++ の存在意義があるんだけどなあ…(ﾎﾞｿｯ
0531デフォルトの名無しさんNGNG
実際のところ>>511のような結論にしかならんと思うがな。

悪いけど
>>いや、そこまで鞭打つ気は無いよ俺も(^^;
>>別に、他の案でもいいんだぜ？
これはまったく信用できないな。
多重継承を解決しない限り、どんな仕様にしても直行性はなくなるよ。
もちろん、「superがないと不便」には諸手で賛成なんで、
それを乗り越えて「まあ変だけど、許してちょ」的な仕様を
stroustrapが考えたのなら、俺は許すけど。
どうやってもコンセンサスはとれんと思うからこそ、typedefで適当なんでないの。
0532デフォルトの名無しさんNGNG
javaがテンプレートをサポートするみたいだけど
SUNは自社のみでSTLもどきを実装する気なのか？
0533aaNGNG
C++を完全制覇している人は世界に何人くらい
いるのであろうか
0534デフォルトの名無しさんNGNG
多重継承がある以上、プログラマが継承図を意識するのは避けられないので、
superなんかあっても役に立たないと思うんだけど。
0535デフォルトの名無しさんNGNG
>>533
ANSI C++ 仕様が完全に実装されてるコンパイラって地球上に存在するの?
0536デフォルトの名無しさんNGNG
>>531
要は、継承元の複数のクラスそれぞれに対応した
識別可能なエイリアスがつけば、いいんじゃなく？
super(0) super(1) super(2) とか(わら

あと、前述したように、継承の順序みたいな概念、でもいいな。

ところで直接関係ない話だが、ソース使いまわすのを
最初から予想している場合は、手打ちでtypedefを
入れて回っているわけか、ふつー(笑)のC++erは？
使いまわすってのは、superclassがどれなのかってのを
字面で書きたくなくなる動機の1例としてだけどさ。

----
ところで話は飛ぶが、やっぱりメタクラスは欲しいな。
もどきでもそれなりに役立つから欲しい。

VC++なんかは一見メタクラス的機能のように見えるマクロとかを
提供してるけど、あれってどうやってるんだっけ？
(今手元に処理系がないんで見れないんだが)
0537デフォルトの名無しさんNGNG
>>536
＞あと、前述したように、継承の順序みたいな概念、でもいいな。

よくねえ。
class A;
class B : public A;
class C : public A, B;
みたいな継承をサポートできるかい。

＞使いまわすってのは、superclassがどれなのかってのを
＞字面で書きたくなくなる動機の1例としてだけどさ。

これにより、536はOOPを欠片もわかっていない厨房と言うことが確定しました。
0538デフォルトの名無しさんNGNG
>>533
STLを含めるとほとんどいないだろうけど、
言語としての純粋な部分であれば、
ほぼ完全制覇したというひとは多いだろう。

C++マスター度チェックリスト

□コピー、参照、ポインタの使い分けには自信がある
□デストラクタは必ずvertualだ
□constにできるオブジェクトやメソッドは全部constにしている
□クラスには必ずコピーコンストラクタを書いている
□Ｃ言語形式のキャストは禁じている。
□vectorで２次元配列を組める
□deleteはほとんど使わない
□std::exceptionを継承していない例外は投げないことにしている
□イテレーターの動きに不安を感じることはない
□どのメンバをprotectedにするか考えながらクラスを設計している
□friendを使うとクラスの隠蔽度があがると思う
□例外指定をマメにつけている
□virtual継承は時々使う

他に何かあったらよろしく。
0539デフォルトの名無しさんNGNG
○　コピー、参照、ポインタの使い分けには自信がある
○　デストラクタは必ずvertualだ
○　constにできるオブジェクトやメソッドは全部constにしている
○　クラスには必ずコピーコンストラクタを書いている
△　Ｃ言語形式のキャストは禁じている。
○　vectorで２次元配列を組める
×　deleteはほとんど使わない
×　std::exceptionを継承していない例外は投げないことにしている
○　イテレーターの動きに不安を感じることはない
○　どのメンバをprotectedにするか考えながらクラスを設計している
○　friendを使うとクラスの隠蔽度があがると思う
×　例外指定をマメにつけている
×　virtual継承は時々使う

幸せになれますか？
0540デフォルトの名無しさんNGNG
訂正

×　デストラクタは必ずvertualだ
○　デストラクタは必ずvirtualだ（藁
0541デフォルトの名無しさんNGNG
>>539
あなたかなりスキル高いね。
うちの会社に欲しいよ。
deleteはvectorやauto_ptrを駆使して丹念に消そうね。
0542デフォルトの名無しさんNGNG
>>537
>class B : public A;
>class C : public A, B;

同じクラスを2回継承すること(を許すこと)が
そもそもヤバゲだと考えるほうが健全じゃねーのか？

>536はOOPを欠片もわかっていない厨房

はぁ？superclassはsuperclassだろう？
それが概念として頭んなかで抽象化されてねーのか、あんたの頭では？

>>538
>デストラクタは必ずvirtualだ

てゆーかvirtualでないメソッドは少なければ少ないほうが幸せ。
0543デフォルトの名無しさんNGNG
>>529
たしか、STL の起源はC++では無かったと聞いてます。
0544539NGNG
>>541
> deleteはvectorやauto_ptrを駆使して丹念に消そうね。

そゆことか。auto_ptr はコンテナに向いてないからほとんど
使わないなあ。誰がdeleteすべきか割とはっきりしてる場合は
気にせずdelete使てる。
それと寿命の短いやつをnewしない構成にするように心がけてまんす。

つーか、『約束事を増やさない』ってことが大事だなっ、て最近思っ
てる。クラス数の爆発を防止するためのデザインパターンとかはいろ
いろあるけど、こっちのほうも何かないかなあ？
0545デフォルトの名無しさんNGNG
やっぱりlispが起源?
0546デフォルトの名無しさんNGNG
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));


逝ってヨシ？
0547↑NGNG
push_back()だ。
鬱氏
0548デフォルトの名無しさんNGNG
>>544

それは逆で、コンテナに向いてないポインタをauto_ptrにするのです。

>×　deleteはほとんど使わない
>×　std::exceptionを継承していない例外は投げないことにしている
>×　例外指定をマメにつけている

これを見ると、あなたは例外が弱点ですね。
deleteがあると例外が出たときにリークします。
catchの中でthrowしたときにどうなるのか、
コンストラクタ中で例外が発生してデストラクタが呼ばれないときにどうするのか。
しかしすべてが自動変数ならそういう面倒なことは考えなくて済むわけです。
そうなると、今度は例外を気軽に使えるようになってきます。

寿命が短いものは自動変数にするのが一番ですが、
どうしてもnewしなければならないときは、
auto_ptrを使ったり、proxyパターンで実体の寿命をコントロールしたりするのですよ。
deleteが無ければリークなんてしないはずですからね。
0549デフォルトの名無しさんNGNG
STLの起源はALGOLだと言われているよ。
ALGOLを使ったことが無いからわからんけど。
でもSTLの原型を作ったHPの技術者は
ALGOLではなくsmalltalkを参考にしたらしいね。
0550544=539NGNG
>>548
auto_ptrってさあ、いわゆるスマートポインタとちょっと違って

std::auto_ptr<int> p(new int(32));
{
std::auto_ptr<int> p1 = p;
}
//ここでは？

なんてやるとスコープを抜けた時点でpは死んじゃってるじゃない。
これにからめてコンテナには向いてないって記事を読んでそのとき
は納得してたんよ。詳しくは覚えてないけど。
参照カウンタ付きのスマートポインタを自前で用意してコンテナに
使うのはやったことあるな。

例外は確かにあまり使わない。使ったとしても狭い範囲でcatchする
ものばかりで大域ものはやったことないな。だから投げるものはなん
でもいいや、ってことになっちった。
0551名無しの厨房NGNG
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があったほうが便利だと思う。
0552デフォルトの名無しさんNGNG
>>551
自分で名前変更、再定義しなきゃいけないならtypedefと同じなんじゃねえの？
0553デフォルトの名無しさんNGNG
>>548
>しかしすべてが自動変数ならそういう面倒なことは考えなくて済むわけです。
>そうなると、今度は例外を気軽に使えるようになってきます。

こういう考え方をしないとならない／しがちになっちゃう
というところも、ちょっとC++の苦しいところかな。

ガベコレがない言語でも、
ObjectiveCの(というかOPENSTEPの)NSAutoReleasePoolオブジェクト
のような戦略も有る。

ところでC++って、catch(例外食らったらここに来る)はあっても
finally(例外有っても無くてもここに来る)は無いって、ほんと？
だとすると、それもまた「例外を使いにくくする」要因の一つになる。
例外だろうがそうでなかろうが解放処理が必要、という場合に
それを書くうまい場所がなくなっちゃうから。
0554デフォルトの名無しさんNGNG
>>553
言語仕様ではfinallyをサポートしていない。
が、独自拡張でfinally(または等価な機能)をサポートしている
処理系は多いと聞く。
俺はVC++使いだがVC++にはfinallyあるよ。
0555名無しの厨房NGNG
class A{public: hoge(){...}};
class B{public: hoge(){...}};

class C:public A,public B
{
public:
　　A::hoge(){super(); ...};
　　B::hoge(){super(); ...};
};
みたいにできたらいいなあと思っただけ。
0556デフォルトの名無しさんNGNG
C obj;
obj.hoge();
どっちが呼ばれるか不安になるぞおい。
0557デフォルトの名無しさんNGNG
C++は、もう破滅寸前。
ここらでSTLに挫折した、全体の９５％相当のプログラマが
不買運動を起こし、消滅します。

ありがとうC言語！そしてC++さようなら！（^_^)また会えるといいね！

http://piza.2ch.net/test/read.cgi?bbs=tech&key=995820118&ls=100
0558デフォルトの名無しさんNGNG
>>555
class C:public A,public B
{
public:
　　hoge() {A::hoge(); B::hoge(); ...}
};
みたいにするんじゃないかなあと思うんだが。
0559デフォルトの名無しさんNGNG
>>554
>が、独自拡張でfinally(または等価な機能)を

「賢い仕様策定者とやらの所業がそれか？」と
思わずにはいられません…

>>555
>class C:public A,public B
>{
>public:
>A::hoge(){super(); ...};
>B::hoge(){super(); ...};
>};

それはC++系(わら)文法な傾向の言語では>>556が指摘するように
無理があると思う。それよりはsuper.hoge()っしょやっぱり。
0560デフォルトの名無しさんNGNG
>>559
＞無理があると思う。それよりはsuper.hoge()っしょやっぱり。

これでも>>556と同じ問題はつきまとうんだけど。
0561デフォルトの名無しさんNGNG
あげ
0562デフォルトの名無しさんNGNG
Ｃ＋＋はオブジェクト指向Ｃ言語。

オブジェクト指向は感覚だから、いくら理論書よんでもクラス作れる
ようになれない。だからＣ＋＋を使えるようにもまれない。

そういう人は多分、ＪＡＶＡでも勉強して、SUNの標準クラスに接して
クラスってどんなもんか肌で最初に感じるべし。
0563デフォルトの名無しさんNGNG
>>553
>finally(例外有っても無くてもここに来る)は無いって、ほんと？
>だとすると、それもまた「例外を使いにくくする」要因の一つになる。
>例外だろうがそうでなかろうが解放処理が必要、という場合に
>それを書くうまい場所がなくなっちゃうから。

「例外だろうがそうでなかろうが解放処理が必要」な場合は
デストラクタでリソースの開放を行うのがＣ＋＋のスタイル。

C++に慣れていると、リソースの解放を自動化できず
finallyで、いちいちコードを書かなければならない
JavaやDelphiのほうが不便に思える。
0564デフォルトの名無しさんNGNG
Ｃ言語って、何に優れている言語なの？
0565デフォルトの名無しさんNGNG
>>564
高級アセンブラという捉え方もある。
その意義がわからない人はJavaでもやっとけばいいと思う。
0566デフォルトの名無しさんNGNG
高級アセンブラとして使わないのならC++なんて簡単だろ。
新しい言語覚えきるのにはそら2､3ヶ月ぐらいの辛抱が必要ってもんだぜ。
VBとかみたいに2，3日で覚えられるものとは違うんだよ。
ちなみにオブジェクト指向が分からないならJavaだろうと何だろうと
無理ってもんだ。それに必要となる知識は言語の知識とは別だからな
0567デフォルトの名無しさん01/08/26 19:04ID:rJqDH1N6
>>563

Javaにもfinalizeつーデストラクタあるよ。ただ、実行タイミング
はＧＣが動く時だから、予想不可能だけどね。
0568まーたり01/08/26 19:07ID:qJ3dRCRc
C++からVC++へ移行する方がもっと　むずい気がする
0569デフォルトの名無しさん01/08/26 19:08ID:ri9ZAT8k
>>1

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

Ｃ＋＋やJavaやRubyなどのＯＯＰ書くのに、
ＵＭＬやデザインパターンを知ってる必要
なんか全くないぞ。これはよくある誤解。
ＯＯＰはひらめきと感覚の世界。実際オレは
それしか使ってないし。
0570デフォルトの名無しさん01/08/26 19:59ID:qOGvKvts
>>569
クラス設計には経験とセンスが必要なのは確かだけど、だからといってデザイン
パターン不要というのは早計でしょ。デザインパターンというのは成功したクラ
ス設計のカタログ、将棋で言えば定石みたいなもの。よほどの天才は別として、
一般にはまず定石を押さえて、その上で自分の問題に取り組んだ方が結果を出し
やすいよ。

あと UML やデザパタに関しては、他人と意思疎通を図る際の共通言語、という
意味もありますね。長々とクラスの関係について説明したり、ソースコードを読
む代わりに

「これが Abstract Factory」

の一言で済めば、その方が効率が良いわけで。
0571デフォルトの名無しさん01/08/26 20:53ID:TeHBTESQ
>>569
>ＯＯＰはひらめきと感覚の世界。実際オレは
>それしか使ってないし。

「私は不勉強な井の中の蛙です」
と要ってるのと同じ。
0572デフォルトの名無しさん01/08/26 21:56ID:ckmvcpUo
>>567
>Javaにもfinalizeつーデストラクタあるよ。ただ、実行タイミング

javaのfinalizeはデストラクタの代わりには使えんだろ。
・実行のタイミングが分からない
・実行される保証もない
・もし特定のタイミングで動かそうとするとGCを動かすコードを
　書かなければならないので、結局finallyに頼る羽目になって無意味。
・特定のオブジェクトのデストラクタを動かすためにいちいちGCを動かすのは
　パフォーマンスが悪すぎる。
0573デフォルトの名無しさん01/08/26 22:31ID:ri9ZAT8k
＞「私は不勉強な井の中の蛙です」
＞と要ってるのと同じ。

そうかな？だれも関数作るのだって、みんな図なんて書かないし、
デザインパターン使わんでしょ。クラスだって結局ある共有した
データを持ったメソッドの集まりなんだから、同じだと思うけど
ね。

ただその代わりといっては何だけど、人が作ったいろんなクラス
読むのは大事だと思うな。ＭＦＣ分析したりＣ＋＋で書いたゲー
ムを分析したりね。実際、関数を感覚的に作れる様になるより、
クラスを作れる様になる方が、ずっと時間かかると思うけどね。
でも、慣れればホントＵＭＬもデザインパターンもいらないと
思う。

ＵＭＬもデザインパターンも人によっては大変有益だと思うし、
役に立つ人もいるんだろうけど、人によってはオレみたいに、
いらない人もいる。

実際、ＳＵＮの標準ＪＡＶＡライブラリー作った連中や、ＳＴＬ
作った連中に聞いてみたいな、どこまでそういうの使ったのか。
多分人それぞれだと思うが。
0574デフォルトの名無しさん01/08/27 00:46ID:6cGRsEso
人が作ったソース読んで参考にしてるならデザパタのいくつかを自然に
あてはめてるかと思われ。ただ、MFCはあまり参考にならんかと。
057557301/08/27 00:55ID:r5Re7QYg
＞人が作ったソース読んで参考にしてるならデザパタのいくつかを自然に
＞あてはめてるかと思われ。ただ、MFCはあまり参考にならんかと。

ＭＦＣは反面教師として使わせていただきます。ほとんどはＡＰＩの
ただのラッパーだし、メッセージの流れをカプセル化してる
分、非常に応用しにくい設計だと思います。WINDOWSはＡＰＩ直に
使った上、Ｃ＋＋を使って自分でクラスを作りながら開発するのが
自分的にはベスト。
0576デフォルトの名無しさん01/08/27 00:59ID:euvssxN.
>>573
だからそれが井の中なんだってば。
たとえそれで凄い腕前になれたとしても、他人と意思疎通ができんだろそれじゃ。
それともソースコードだけで語り合うとかってイキがるつもりか？

>だれも関数作るのだって、みんな図なんて書かないし、
>デザインパターン使わんでしょ。

なぜそんなことが言いきれるんだ？それこそ要らぬお世話だ。

それにさ、やはりObjectは「かたち」と相性が良いよ。
「なんだかこんな感じ(のクラス)」とかの「かたち」を思い描いたり、
あまつさえそれを実際に絵に描いたり、ってのをついついやっちゃう人が
むしろ多いんじゃないかと憶測する。
それの統一共通語版を作ろうってのが、デザパタやUMLだ。
#デザパタは統一以外の面も有るが、ここではさておく。

あと、日本人って抽象化が苦手ですねー(ぷぷぷ
抽象思考になると途端に酸っぱい葡萄モードになる奴が多い。
そんなんだからいつまでも根っこの部分で欧米の後塵を拝してるんだな。

>>574
そうそう。デザパタは「新しい」テクニックを示してるわけじゃない。
「既存の」テクニックに、単に、名前をつけただけ。
UMLだって同じ。「既存の」構造を(特定プログラム言語を使わずに、でも自然言語も使わずに)
さくさくっと書き表すためのもん。
0577デフォルトの名無しさん01/08/27 01:12ID:r5Re7QYg
>>576

＞それともソースコードだけで語り合うとかってイキがるつもりか？

なんかムキになってるだけで、全然説得力ないんだけど。

オレ、ＳＴＬ、Ｊ２ＳＥ、Ｊ２ＥＥ、使うとき、ＵＭＬもデザイン
パターンも使ったことないぞ。クラスなんてパブリックインター
フェイスとその使い方示せば十分コミュニケートできるよ。JAVADOC
のようなね。

あと、勝手に飛躍してるが、Ｃ＋＋使うのにＵＭＬもデザイン
パターンを知ってる”必要”がない、ってオレは言ったんだけど。
いかなる条件でも不要とは言ってないぞ。一人でＣ＋＋で開発
する目的のヤツもいるし、勝手に集団のプロジェクトで使うって
前提条件作って反論しないように。
0578デフォルトの名無しさん01/08/27 02:52ID:iVLWrpEM
うーん。別にデザパタ、肯定否定どちら派でもないけど
肯定に片寄りすぎて無理にデザパタを乱用した汚いソースも結構あると思う。
デザパタって万能じゃないんだよね。実装はかなり汚いから
実の有るところをほどほどにとっていけばすっきりしたソースが
かけるとおもうけども。。
0579デフォルトの名無しさん01/08/27 04:00ID:/EQqP.tM
やっぱり，複数人数でやるときにはデザパタとUML（とそれに類する記法）は便利だよ。
だいたい，工業としてのソフトウェア作製を考えた場合，そこは無視できない。

立場によって肯定・否定があってもいいとは思う。

しかし，将来会社に入ってプロジェクトに参加する可能性のある若者には
「最低限の教養だから身につけておいたほうがいい」と言いたい。
言っておくけど，「信奉せよ」ってんじゃないよ。

また，577のように知っていながら批判的な態度を取ることも
結局は「知っているからこそできること」であるわけで，
より高度な概念に到達するためには，基礎知識としてその
批判対象を知ってなきゃいかんわけで。

うーむ。C++にあまり関係ないね。
0580デフォルトの名無しさん01/08/27 05:12ID:6cGRsEso
577てデザパタちゃんと分かってるのか疑問に感じる
576も言ってるが既存のテクニックに名前を付けただけなんで
俺はデザパタ使わねーと言っても違和感がある、普通にプログラム作ってれば
デザパタのいずれかに当てはまるパターンは使ってるはず。

それでも使わねーぞと言うのって昔のスポコンマンガみたいに根性だけで（理論なしで）
プログラム作るぞ(ﾟДﾟ)ｺﾞﾙｧ!!ってふうに聞こえる。今時スポーツでも理論が基礎になってるし
（例えば世界一速いモーリスグリーンとか）それを無視しようとするのは進歩するのを拒んでる
ようにさえ見える。こういう奴ってsexでも腰振って出して終わりーってワンパターン野郎って
感じがする。
0581デフォルトの名無しさん 01/08/27 05:30ID:r5Re7QYg
パターンは自分で作るとこにロマンがある。

別にそれが結果的に既存のパターンに当てはまったって良いわけ
で。音楽理論と作曲みたいなものだね。曲を作れば音楽理論に
当てはまるが、曲を作るのに必ずしも音楽理論を知ってる必要は
ない。ジョンレノンなど、音楽理論をベースにせず曲を作る連中
は腐るほどいる。ルールに縛られたいってのは、二流の証なんじ
ゅないかな。才能あれば、自由に発想したいって思うはずだし。
0582デフォルトの名無しさん01/08/27 05:35ID:8jNUMhPQ
>>581
たかが手段でロマンを語る人が現れた。びっくり。
仕事と妄想は区別しようね。納期優先だよ。

人の英知をかっぱらうのが一番手っ取りばやいわけで。
システム開発なんてのは、えらそうに言っても結局のところ
人の英知のかっぱらいの上にちょっと使用毎の差分だけデコ
レーションかけるだけなわけで。

趣味は家でやるべし。
0583デフォルトの名無しさん01/08/27 05:51ID:IiQ03hCY
オブジェクト指向は実装よりも分析設計の方にロマンを感じるが。
0584バイト君01/08/27 06:01ID:tYSEFlt.
>パターンは自分で作るとこにロマンがある。
>別にそれが結果的に既存のパターンに当てはまったって良いわけ
>で。音楽理論と作曲みたいなものだね。曲を作れば音楽理論に

車輪の再発明しといて自由に発想ってのがおかしいんじゃない？
既存のものをパターン化して知識として持ってれば
無駄なところで創造力浪費しなくていいわけだし。
パターン化できないところに力を注ぐべきかと。
0585デフォルトの名無しさん01/08/27 06:14ID:iVLWrpEM
>>584
>車輪の再発明しといて自由に発想ってのがおかしいんじゃない？

おいらの立場としてはあくまで中立だけど、世の中にあるすべての
ものが車輪の再発明だけではないと思うよ。
581 が言いたいのはデザパタだけでは満たせない部分を指している
ような気がするのだけど、深読みしてるかな。

とりあえず知識として持っておくのは賛成。
全面的に肯定すべてデザパタで統一するにはデザパタ自体に
それほどの能力が備わっていないように感じるので否定。
デザパタはまだ信頼できる完成段階ではないような気がする。
0586デフォルトの名無しさん01/08/27 06:37ID:r5Re7QYg
>>582

それじゃ、ロボットだよ。多くの経営者はそんなロボット君
は求めてないと思うぞ。仕事仕事っていうけど、多くのいい
プログラムは仕事の外で書かれてる訳で、それを普遍的に押
しつけるのは、おかしいな。あと日本にはあまりいないが、
技術的なフロンティアな事やってる人たちってそんなロボッ
トみたいな発想で、物作ってないと思うぞ。これってＳＥ、
ＰＧに限らず、どんな物づくりにも言えるんじゃないかな。
外面、クールでドライなビジネスライクな部分も必要だけ
ど、やっぱホットでウェットなホビーライクな部分って重
要だと思うぞ。押しつける気はないけど。
0587デフォルトの名無しさん01/08/27 11:11ID:IiQ03hCY
だからここでも何度も言われてるようにデザパタはカタログ化した
ことに意義があるんだって。あれで全て設計しろなんて誰も言ってない。
ここでデザパタという単語である程度の共通認識ができていること自体が
その一番のメリットなんだからさ。
もちろん詳細設計のテンプレートとしても使えるけどさ。
0588食いだおれさん01/08/27 12:24ID:wi3879hI
>>580,587
わしも大体そんな思い

Design patternを知ったのに、
設計初段階の思考に影響を受けない人間ってこの世に存在するのか？
ああいったpattern区分がある事を知っている、これがframeworkの強さじゃないか。

何でもdesign patternで、無意味なGoF風class連発する奴も考えものだが。
058957601/08/28 01:07ID:1P3cxrIo
>>580
そうそう。それそれ。デザパタ使うのと使わないのの差ってのは、
つまりは或るパターンを「その名で」呼ぶかどうかの差でしかない。
だから、それを使わないってことは、他人(人間ね。計算機じゃなく)との
意思疎通はどうよ？という話にしか、ならんわけ。

ただし、
>>582

ロマンは大げさだが、たしかにGoFの23パターンだけで森羅万象が表せるはずもないんで、
新たなパターンを見つけて名前つけるっていう作業をやりまくってる連中も
一方で存在してるのは事実。
将来的にはその彼等の研究成果のごく一部(藁)は、主流派に合流するんじゃないかなあ。

つまり、デザパタっていうもの自体は、まだ「終わった研究」ではない、ということ。
最終(?)的には、パターンの「淘汰」みたいなことが起きるんじゃないかと希望的に観測。
つまり成熟やね。

ところでパターン自体もパターン間に類似性や包含性があったりして、
結構親戚関係があるよね。だから、23個にしても、単に23個の独立したAlphabet
みたいに扱うんじゃなく、意味の関連性が相互に有機的に存在するようなモノなのだろう。
Primitiveはきっともう少し「下」に有る。それを発掘することがどれだけ有意義かは微妙だとしても。
0590所新車01/08/28 05:50ID:TsVgfhCw
デザパタ…というよりGoF23パターンは有用だよ
広く一般に知れ渡ったからね（ホントか？と、自分でツッコム）
話の中でxxxパターンという言葉を使うだけで
構造を言い表せる共通語になるのが一番の強み
UMLも一般に受け入れられていること自体が意味のあることだし
結局、C++も広く一般的に使われているから自分もつかう

っつーか、僕って長いものに巻かれまくりかも
0591デフォルトの名無しさん01/08/28 06:51ID:MRWziuF6
デザインパターンのプリミティブか。そういや２年ぐらい前のＣマガの
デザインパターン入門って連載の最終回が結構いいこと書いてたよ。
オブジェクト指向のエッセンスを最初にまとめて、それらが
GoFのそれぞれのデザインパターンをどう構成しているとか、
GoFの各パターンがどう関係し合っているかとかまとめてた。
ttp://www.try-net.or.jp/~tatefuku/t_20000605.html
ですすめられてたんで先輩からバックナンバー借りて読んだん
だけど、なかなか良かったよ。
0592デフォルトの名無しさん01/08/28 10:13ID:.5mdRdYk
>>591
Cマガのその頃の一部(藁)の記事と、
あと往年のDDJJの一部(藁)の記事とは、
すごくいけてた。あーいう文章がもっと沢山出てきて欲しい。

というわけで、よいwwwサイト有ったら教えてくんm(__)m
0593デフォルトの名無しさん01/08/28 11:46ID:A/WljIC6
俺の考えるクラス作りの方法。

たとえば、ＪＡＶＡでboolean型のフラグを使ってると
して、そいつが誰がいつ状態を変えたのかわかるように
しようと思ったとき、いつものごときクラスを作る。
こんな感じになるだろう。

１。セッターゲッターを作る。
２。変更時に、呼出クラス、メソッドの名前を登録する。
３。標準出力に状態を常に吐き出したい時は、セッター
に標準出力に出力する用にする。
４。常に出力されるのは、使えないから、コンンストラ
クターで指定できるようにする。

こんな感じで作っていく。あといろんなクラスを作って
言って汎用性を持たせる為に、どんどんabstractで
外だしにし、コードのダブりをなくす。

あと関数は出来るだけstatic 作るようにし、(つまり
単発で使え、他に一切影響の与えないようにする為)、
staticなものは、JavaのCollectionsやArraysのように、
staticメソッド集のようなクラスに入れる。

これが、俺の大まかなクラスの作り方だが、デザイン
パターンなんか使ったことないし、必要性も感じない。
設計時だが、どうやって抽象クラスを最初にモデルする
時は、思い浮かぶものを作ればいばいいとしか言いようが
ない。でも最初から抽象と実装のコンボはテストしにくい
ので、大概最小は１クラスで実装し、あとから抽象化する
というステップを意図的にしている。

俺的に、厳密ではないが、単純に言えば、クラスなんて
所詮複数インスタンスを生成出来るＣで言うモジュールを、
複数インスタンス生成できるようにしただけのものなんだから、
デザパタだのＵＭＬの必要性を感じないのである。
それでもそれなりの評価は得ている。

あと関係ないが、オブジェクト指向が理解されない理由は
このコード表現をデザパタ、ＵＭＬなどに特別視されす
ぎる事にあると思う。同じグローバル変数を共有出来る関数群、
つまりモジュールの一種でそれを、複数インスタンス化する
ことができ、時には構造体的に使うことができる、程度に
解釈すれば全然難しいものでもなんでもないと思うぞ。
0594デフォルトの名無しさん01/08/28 11:59ID:eStTOHF6
>解釈すれば全然難しいものでもなんでもないと思うぞ。

オブジェクト指向よりあなたの日本語の方が難しいです。
0595デフォルトの名無しさん01/08/28 12:18ID:ruHY1EHc
デザインパターンの内容とその理念を理解した上で使わない使う必要を感じない
というなら、それでも良いと思いますよ。いわゆる天才には、必要ないのかも
しれません。

とはいえ、コードの構造を他人に伝えるプレゼンテーション集としても有用
なので、もし読んでいなければ精読する事をお勧めします。

少なくとも上の発言はわかりにくく、意図を理解するのが相当難しいですよ。
0596sage01/08/28 14:43ID:tB0WoitY
593って相当頭悪そうだね
0597デフォルトの名無しさん01/08/28 14:50ID:xva9NHHs
>>581
和声学を踏まえた上で一流の作曲家なんて、
クラシックの世界にはいくらでもいまする。
0598デフォルトの名無しさん01/08/28 15:10ID:08uBFxUw
>>581
昔から言われるように、最高の書き手は時にレトリックのルールを無視すること
がある。ただしそうした場合には、ルール違反を補ってあまりあるメリットがその
文を通して読者に伝わるのが通例だ。それに確信が持てない限り、おそらく書
き手はできる限りルールにしたがおうとするだろう。
-----William Strunk and E.B. White, The Elements of Style
(『プログラミング作法』からの孫引き)
0599デフォルトの名無しさん01/08/28 15:47ID:EfXPjBJw
隊長、>>593の解読に成功しましたっッ！　要約すると、

「プログラムを作る時は原則として一つの巨大なクラスに
全部の関数をつっこむ。例外としてグローバル変数を管理
するためのクラスやユーティリティ関数を集めたクラスを
作ったりもする。あとabstructというのもよく分からない
なりに使ってみた。」

という意味ですっッ！
0600デフォルトの名無しさん01/08/28 17:37ID:RwT16pIQ
>>593
実装(具体的表現)とパターンつーのは異なるロジカルタイプに属するんだから、実装で
パターンの何かを語ろうとすることにそもそも無理があると思われ。
0601 ◆winntZag 01/08/30 02:12ID:OJtyVZPM
>>581
そんな貴方には、芭蕉のことばを贈ろう。
「格に入れば狭く、入らざれば邪路にはしる、出て初めて自在をえべし」

パンピーはまず基本を押える。
だけどそのままでは型にはまりすぎるので、
基本を押えたうえで、もし必要ならば、それを崩してみる。
初めっから、基本を無視するのはよくない。

よほどの天才は別だろうが。
0602 NGNG
0603デフォルトの名無しさんNGNG
>>601
えべし -> うべし

じゃないのか？
0604デフォルトの名無しさんNGNG
C++プロジェクトの設計段階にかかる時間は、3倍です。
継承すべきもの、すべきでないものを正確に決めるためです。
それでも、判断を間違えます。
0605デフォルトの名無しさんNGNG
>>604
Javaだと5倍なので、まだマシです。
0606デフォルトの名無しさんNGNG
ＯＯＰを学ぶ順番は、
「データ構造、モジュール→クラス構造→デザインパターン」
と書くと、賛成も反対も無いのは何故？
0607デフォルトの名無しさんNGNG
>>604
それって、分析が出来てないからじゃないの？
0608デフォルトの名無しさんNGNG
クラス構造って何？
0609デフォルトの名無しさんNGNG
クラスの使い方と書いた方が良かったかな？
0610デフォルトの名無しさんNGNG
switchﾊﾞｶでｽﾏｿ。
OOPってトップダウンで設計するためにやってきたんでしょ。天の声で。
0611デフォルトの名無しさんNGNG
C++は特殊な構文がやたらと多すぎる
0612デフォルトの名無しさんNGNG
でも多くの場合、「なんでもトップダウンで設計できそう」という
ダメな幻想をあたえただけかも。
0613デフォルトの名無しさんNGNG
トップダウンといや、、
責任駆動設計(responsibility-driven design)てのがあったな。
CRCカードで設計してる人って漏れは見たことないけどな。
0614デフォルトの名無しさんNGNG
実際のところ
C++を効率的に運用できるスタッフが少なすぎる
言語仕様としてのキャパシティはともかく
今のところ企業としての利潤追求の旨みの少ない言語
小さな会社は、C++を使ってC的な組みかたしてる所がほとんどだし
それが正しい
0615デフォルトの名無しさんNGNG
OOPイコール トップダウン、なのか？
漏れはそういう印象はあまり受けないな。

トップダウンだと思いこんでしまう人は、単に以下の経験が少ないだけ
なんじゃないかと憶測＆揶揄したいのだが、どうよ？

1:気楽にソフトを作ったことが無い。OOPつーたらエンプラとかの大規模ソフトを「作らされた」ことしかない。

2:ライブラリを作った事が無い。特に案件専用じゃない汎用寄りのクラスのライブラリを。
これは方法論「Drop」でも言及されてることだが、これをやったことが無いってのはつまり、
そのプログラマは単なる部品ユーザーでしかない、ということを意味する。
0616デフォルトの名無しさんNGNG
むしろボトムアップちゃうの？
0617デフォルトの名無しさんNGNG
クラスライブラリを作る/使うの両方を経験すると、
それからいい仕事ができるようになるのかな。

誰かのを使うときに「何を考えて作ったのか」を想像しやすくなるし、
誰かのために作るときに「どう使われるだろうか」を想像しやすくなる。

これを端的に表す言葉を希望
0618加藤茶NGNG
鏡の向こうは志村けん。
0619デフォルトの名無しさんNGNG
>>612
の言うトップダウンってどういう意味だろうね。
Abstruct→Concreteってこと?

>>618
2点。
0620デフォルトの名無しさん NGNG
スレタイを「なぜ職業プログラマはあんなに気難しいのか？」にすれば良かったね
0621デフォルトの名無しさんNGNG
>>617
同床異夢！
…違うなあ。むしろ逆か。鬱出汁脳…

つーかー！
…それも全然違うなあ…

思いやり！
…どうよ？…

…というわけで、>>618がサイコー！ということで、募金活動は終了。
0622デフォルトの名無しさんNGNG
C++での委譲の実装ってすごく面倒に見えるんだけど、
どんなときに委譲って使うのですか？
オブジェクトが受けたメッセージを別の オブジェクトに丸投げ
するってなんか意味あるのですか？
メッセージの分岐点として使うのですか？
使う場面が、頭悪いので創造できないです。
委譲そのものが分かってないのかも。ﾄﾎﾎ。
0623デフォルトの名無しさんNGNG
>>622
現実問題として継承が使えない場合に逃げとして使うことが多いかな(藁
0624デフォルトの名無しさんNGNG
>>623 レスありがとうございます。継承が使えない場合、、
これも想像できない。鬱氏。
0625デフォルトの名無しさんNGNG
>>624
逃げとしての一例をあげれば、class Fax と class Phone があって
それぞれインターフェースではなく実装付きで定義されている場合に、
多重継承を使わずに FaxPhone を作れと言われたらどっかで委譲することになる。
Java では実装の多重継承はできないし、
C++ でもライブラリの制限でダメということがある(C++BuilderのVCL)。
0626デフォルトの名無しさんNGNG
>>623
漏れはむしろ逆だな。
委譲するのが適当でない、と思われるときに継承を使う。
実装上、そのほうが楽になることが多い気がするから。

>>625
既存の(自作でない)class Faxとclass Phoneがある場合は、そうかも。
FaxPhoneとして使うことを想定していないFaxなりPhoneを基底クラスと
して採用することは不適当と思う。意図せずに(副産物として)作られた
汎用基底クラスなんて信用ならない。将来的に破綻しそうな気がするしな。
0627デフォルトの名無しさんNGNG
>>625-626 レスありがとうございます。
なるほど、アフォな私にもよくわかりました。
0628デフォルトの名無しさんNGNG
継承は最小限に
でもツボにはまった使い方をすればパワー倍増

「オブジェクト指向の goto」とどっかに書いてあった
0629デフォルトの名無しさんNGNG
話の流れを無視する発言ですが、オブジェクト指向の良さが実は解りません。
クラスでカプセル化と関数でカプセル化の区別がつきません。

ウィンドウプログラミングには楽そう、とは理解していますが、
それ以上ではありません。WIndowsプログラミングはしたことありません。

僕はC++は便利なCとして使っています。Javaは食わず嫌いで絶対勉強しないでしょう。
Perlは美しい言語だと思います。Rubyはどうでか？
0630デフォルトの名無しさんNGNG
>話の流れを無視する発言ですが、オブジェクト指向の良さが実は解りません。
よくデキテリャなかなかいいよ。
javaの話で申し訳ないが、「javaのプログラマーがいない」というのは嘘。
いないのは「オブジェクト設計できる人」という話題になった。

機能が動くよーにコード作るだけなら何でもいいんだけど、オブジェクト
の良さをとなると、システム設計のセンスが必要とされるので難しいんだろうね。

ふつう、１０人ぐらいの規模でソフト書いていれば、わかると思うけど、
上流行程や、メンテをやってりゃ良さがそのうちわかると思いますよ。
でも
>Javaは食わず嫌いで絶対勉強しないでしょう。
だったらずーとわからんかな。
好き嫌いで仕事ができるのはうらやましい。というか、サンデープログラマーか。
趣味なら何でもよろしい。

>Perlは美しい言語だと思います。Rubyはどうでか？
この感覚わからない。仕事でソフトを作るなら、使い方にもよるけど、
一定以上の規模をperlでかくなど悪夢です。
0631デフォルトの名無しさんNGNG
手続き型->オブジェクト指向って基本的に制約を強くする方向で進化したわけで、
その制約をメリットと感じない人は確かに存在するね。
傾向としては天才肌なプログラマに多くて、
そういう人はCやperlに汚さなんて感じないし
>630みたいな人間とは意思の疎通が出来ないんだよね（藁
0632デフォルトの名無しさんNGNG
>631
>手続き型->オブジェクト指向って基本的に制約を強くする方向で進化したわけで、
確かにそうなんだが、継承とか、一方的に規制を増やした方向だけとも思わない。
オブジェクトの良いとこかいてくと教科書になっちゃうけど構造体の良さがわか
れば、>629もオブジェクトの良さの一部がわかるかな。

ただ、オブジェクトでひどい書きかたされるとかえってたちは悪いとは思う。

>傾向としては天才肌なプログラマに多くて、

天才の定義によるがそれって独りよがりのひと？ コスト的に妥当な
プログラマーの集団で作成しないといけないソフト製造には、自分の
書いたコードが人が読めることが必須。オブジェクト指向とかはあく
までエンジニアリング（ローコストで良いものを作る）として進化し
てるんだと思う。

>そういう人はCやperlに汚さなんて感じないし

要は書き方なのだが、宣言てきとうな言語など２０年前のbasicの時代に戻ったようで...
美しいというか、ちゃんとした言語とは思わない。何で書いてあっても
人にわかるようにきっちり書いてあれば美しいと思うが、型もわかりにくい
ようでは。ちょっとしたプログラムを書くには大変便利とは思うよ。

>630みたいな人間とは意思の疎通が出来ないんだよね（藁
そういいきられるとちょっと悲しいが、仕事としてソフトに関わるように
なって、純粋さがなくなってきたかなー。だんだん話の方向がずれて申し訳ない。
0633デフォルトの名無しさんNGNG
>>クラスでカプセル化と関数でカプセル化の区別がつきません。
関数でカプセル化ってどういうこと？
あと、perlが美しいってのはperl好きな人でもあまりいないとおもうが。
どんどん肥大化してるし。
0634デフォルトの名無しさんNGNG
http://www.geocities.co.jp/SiliconValley/5634/t82A2_0001.html#1555で
委譲の項目で
・オブジェクト指向な考え方に一番縁遠く、
今日もせっせとデカい声で旗振りをしながら、
手続き型言語のCOBOLを駆使しているアイツが、
何故か使いこなしているもの。
・「委譲」じゃなく、「押し付け」とか「責任転嫁」とか表現した方が
正確なのだけれど・・・。

ってありますけど、本当ですか？
0635>634NGNG
なんちゃって用語辞典じゃん。
洞察力に乏しく悪魔の辞典ほどの毒も無い。
読まんでよし。
0636デフォルトの名無しさんNGNG
>>635
同感。本人おもしろいつもりなんだろうがな。それほどのこともなし。

オブジェクト指向も設計思想の1つだ。プログラムを作るときに
作りたいものをどうイメージして、どの言語でどうやって作るか。
言語の性格もさまざまだし。結局、そこが腕の見せどころだ。
なんとか指向の方に正解があるわけでなくて作るやつの責任で選ぶってこと。
つくりたいものが決まらないうちに、作り方について正解が決まるわけはないから
概念だけを過剰にクローズアップしても得るものはないと思うよ。

Perlに美を感じたことはないけど作者の才能は十分にじみ出てると思う。
0637デフォルトの名無しさんNGNG
C++ の例外って使われてるの？すごく中途半端なイメージがあるんだけど

Java みたいに標準ライブラリとかで大々的に使わないで
例外を使え、って言っても混乱するだけだと思う。
0638デフォルトの名無しさんNGNG
おいらは使ってるよ
コンストラクタでのエラーなんて
例外なかったらキレイに扱えないじゃん
あと標準ライブラリだった例外使ってるじゃん
0639デフォルトの名無しさんNGNG
>>638
C++って、コンストラクタの中で例外だしていいんだっけ？
0640sageNGNG
どこで出してもイイよ
0641デフォルトの名無しさんNGNG
どぴゅ
0642デフォルトの名無しさんNGNG
>>639
デストラクタが呼ばれないけどね。
0643デフォルトの名無しさんNGNG
>>640
デストラクタで例外出すのだけは、やめた方がいい。
0644デフォルトの名無しさんNGNG
>>643
ﾜﾗﾀ
0645　NGNG
Windowsのアプリケーションやゲームを作る場合、やはり一番適しているのは
Ｃ＋＋ですか？
0646デフォルトの名無しさんNGNG
ゲームに関してならVC++
0647デフォルトの名無しさんNGNG
645に関してならHSP
0648無名λ式NGNG
>>642
> デストラクタが呼ばれないけどね。

まだコンストラクト終ってないだもん、呼んじゃ駄目だよね。

初期化リストの中で初期化の終っているものは、デスタラクタ呼ばれる。
これは嬉しい仕様。http://www.gotw.ca/gotw/066.htm
0649デフォルトの名無しさんNGNG
>>633
>関数でカプセル化ってどういうこと？

関数によってカプセル化され得るものは、たしかにある。
が、関数ではカプセル化できなくてObjectでならできる、というものもある。

関数でカプセル化されるものの筆頭は、処理の「流れ」。
サブルーチンを呼べば、そのサブルーチンの中の処理順序を
気にする必要が無くなる(というか気にすることは出来なくなる)。

思い出深いのが、Cの関数の中のstatic変数。
グローバル変数みたいに外界に野ざらしになるわけでもないのに
前回の値を覚えているなんて、なんて便利なんだ！と最初は思ったが、
ほどなく、関数の実行より変数のほうが寿命が長いくせに、
その関数を使わないとその変数にアクセスできない(=多様なアクセス形態と
やろうと思ったら、その1つの関数が超多機能肥大化する羽目になる)、
ということが致命的に面倒だと気付いた。
そして、解決策はOOPだった。

#憂鬱本では、グローバル変数の正体を暴くという文脈で、これと同じ問題を指摘している。
#あれは名著だ。読め。
0650633NGNG
今日憂鬱本を注文しました（売上に貢献 :D）。

（クラスで）カプセル化すると大人数での開発に有利になる、
って言われてるんですけど、初期のC++はCのプリプロセッサ（？）
でしかなかったわけで、Cでもちゃんと関数を設計すれば、
カプセル化はできると思うんです。

#もしかしたら、C++ではクラスを使えば誰でもカプセル化できる、
#逆にカプセル化しなければC++のクラスは使えないってこと？
#英語で喋れは論理的になるとか、そういうレベル？

ちょっと具体的なプログラム例を考えます。
0651無名λ式NGNG
「プリプロセッサがなくても同じ事が出来る」というのは、
言語の実行時の振舞いの事を言っているのだと思う。
ところが「カプセル化」は、往々にして字面上の問題だから、同じ論理は通用しない。

文字リテラルの代わりに文字のコードポイント整定数を入力した時の事を考えよ。

// sageてるからsage
0652デフォルトの名無しさんNGNG
プロじゃないんだけれど。
たとえばコンパイラの構文解析なんかswitch文でやるほうがいいとしか
思いつかないんですが、OOPの使いどころが見えません。
オブジェクト扱いにするのは入力と変数管理と
コード出力ぐらいでしょうか｡
ストローストラップの偽インタビューが気になる｡
カプセル化ってガチャポンの中身が何でも同じ規格の殻に入ってるってことですよね。
0653デフォルトの名無しさんNGNG
カプセル戦士
0654デフォルトの名無しさんNGNG
カプセルに入っているので、中に違うものが入っていても
同じ機械で繰り出せるのです。
0655デフォルトの名無しさんNGNG
>>652
Interpreter パターンを知っている上でそう思っているのなら、
別に人それぞれ、どう思おうが構わないのですが。
知らないのなら一度何かの本で見てみるとよいでしょう。

でも、ＯＯＰ使おうが使わまいが、構文解析するときの
switch の使用頻度はそんなに変わらないと思うのですが。
文法を書いて、その要素要素を関数で置き換えるか
クラスで置きかえるかが違うだけで、
どっちもやってることは一緒ですよね？

って、もしかして、トークン解析のこと言ってます？
0656 NGNG
http://www.inet-lab.org/ted/program/progdetail.html
を見てC++を勉強しよう。
0657デフォルトの名無しさんNGNG
age
0658sageNGNG
C++（と言うかオブジェクト指向言語）の特徴なんざ
再利用可能な部品の寄せ集めでアプリが作れる点だと考えているが
いかがなもんか？
行き着く果ては部品のチューニング屋と組み上げ屋にわかれてくんちゃう？
特に大規模になればなる程ね。
0659デフォルトの名無しさんNGNG
モジュール化レベルに退行するっていいたいわけね？>658
0660デフォルトの名無しさんNGNG
退行って？
0661デフォルトの名無しさんNGNG
>>660
カーレースゲームで言うと、
逆走して対向車に追突するって事。
0662デフォルトの名無しさんNGNG
Ｃ＋＋におけるＯＯＰで最も需要なものがプリオンフィズムです。
0663デフォルトの名無しさんNGNG
ハンドルを操作するのに、車の実装部分までを知る必要がない！という例えに感動すれ。
0664デフォルトの名無しさんNGNG
>>663
それじゃＶＢですがな（ｗ
0665デフォルトの名無しさんNGNG
>６６２
つまりどれだけ実態を隠しとおせるかということですね？
0666デフォルトの名無しさんNGNG
自分で複素数クラスとか作って
Complex c1(1.0, 2.0), c2(0.2, -1.0);
..
return c1 + c2;
とかやったとき、ちゃんと呼び出し元に足し算の結果が返るんでしょうか？
それともデストラクトされちゃうんでしょうか？
0667デフォルトの名無しさんNGNG
やってみればいいじゃん。
ちなみに値は返ります。
0668デフォルトの名無しさんNGNG
デストラクタはいつ呼ばれるんでしょ？
この辺がいちばん良くわからんのですが。
0669デフォルトの名無しさんNGNG
returnする直前にそのスコープにあったオブジェクトを
宣言の逆順にデストラクタが呼ばれる。
0670デフォルトの名無しさんNGNG
なんで〜 あんなに〜 難しいのか〜♪
Ｃ＋＋と〜 いう名の〜 プログラミング言語〜♪
0671デフォルトの名無しさんNGNG
>>669
リターンの直前ではなくて、スコープを出るときです。
0672デフォルトの名無しさんNGNG
>>670
（言語だけ単純に比べるとして）C++が難しいっていったって
最近ここでよく見かけるSchemeやHaskellに比べればなんてことはない。
おれ、全然分からん。
0673デフォルトの名無しさんNGNG
Haskellはともかく、Schemeは簡単だろ
0674デフォルトの名無しさんNGNG
>>669
>>671
いずれにせよ、
　return c1 + c2;
で作られた無名オブジェクトは、
メソッドから返ったときにはデストラクト去れて
しまっているように思うのですが？

されないとしたら、いつされるのでしょう？
0675デフォルトの名無しさんNGNG
>>674
されないなんて誰が言ったんだ？
過去ログ読めって？
0676デフォルトの名無しさんNGNG
いつされるという疑問は残る・・・
0677デフォルトの名無しさんNGNG
というか無名オブジェクトは上位のものなんだろう
ってことにして今日は寝る
0678デフォルトの名無しさんNGNG
無名オブジェクトのポインタを保持して酷い目にあったことあるヨ
悲しいヨ
0679デフォルトの名無しさんNGNG
たとえばint型の値を返す関数があったとしたら
その返される値は上位の何かに値が代入されて
処理を完了する。
それなら無名オブジェクトも上位の何かのオブジェクトに
値をコピーして処理を完了する。
よってデストラクタはスタック領域が開放されるときという
ことでいいですか？
0680デフォルトの名無しさんNGNG
>>679
んじゃ、intを返す関数の値を受け取らなかったら
関数の処理は完了しないのか？
0681デフォルトの名無しさんNGNG
「上位」というのが良く分からないが、>>679の理解は大体あっている。
スタックが開放されるときではなくて、スコープを出るとき。
まぁ似たようなもんだけど。
いつ何が起こるかしりたければ、コンストラクタとデストラクタ、
コピーコンストラクタにそれぞれ
cout << "CTOR" << endl;
cout << "DTOR" << endl;
cout << "CPCTOR" << endl;
などと入れておいて、関数の呼び出し前後、returnの直前にも
同じようなものを入れておけば分かりやすいと思うよ。
0682681NGNG
デストラクトされるタイミングは嘘かも。
上で言われてるようにreturnの直前かも。
0683デフォルトの名無しさんNGNG
やっぱC++って難しいねい。
さらにComplex&を返すメソッドだと…
とか考え始めると欝だ…Java使おう
0684デフォルトの名無しさんNGNG
この話にはVC++で言うところの、
__stdcallとか__cdelは関係ないのかな？
0685デフォルトの名無しさんNGNG
__cdeclでした。すません
0686デフォルトの名無しさんNGNG
関係ない
0687デフォルトの名無しさんNGNG
それはテンポラリオブジェクトの寿命問題としてしばしばC++ユーザのあいだで話題になるんだな。
結論をいうと「該当する関数呼び出しを含む式」の終わりでデストラクトされることになってる。
ていうか、ちょっと記憶あいまいなんで「テンポラリオブジェクト」検索してみて。
いろんな場合のアセンブリコード吐かせて見てみるといいぞ（経験談
0688デフォルトの名無しさんNGNG
あ、「テンポラリオブジェクト」の寿命か。勘違いしてた。
>>681の説明は間違いで、687さんのが正解。
けれども、>>681の実験は一度やってみるといいよ。

Effective C++にもそのへんのオブジェクトの寿命の説明が
詳しく書かれていたように思う（今手元に無いから確認できないけど）
0689デフォルトの名無しさんNGNG
>>687
ぬおお。
すると、
Complex fact(Complex n) {
return
(n == Complex::zero) ?
Complex(1.0, 0) : n * fact(n - 1);
}
で、n - 1のテンポラリオブジェクトは
再帰呼び出しが全部終わってreturnするまで
destructされない?
0690デフォルトの名無しさんNGNG
>>689
そういうことになるんじゃない？　試してないけど。
ただ、いかなる場合にテンポラリオブジェクトを作るかはコンパイラの実装依存だし、
正直よくわからん。あくまでも、「*もしも* テンポラリオブジェクトを作るとしたら、
その寿命は〜」っつー規定だから。
0691落ちこぼれNGNG
ここの若い人たちに頭を垂れて教えを乞いたいです。

Cに10年以上どっぷり漬かってた、ここで言われてるような
爺化石プログラマです。もう実務から離れて半分管理職なのですが、
知らないと恥だと思いC++を始めてみたのですが、苦戦しています。
言語仕様やものの本の例題やソースは理解できるのですが、どうも
ピンと来ません。

オペレータのオーバーロードとテンプレートは凄い、便利だなと
思ったのですが、こういうところに眼が行ってる所がダメなんじゃ
ないかと思っています。
多分、始めにデータ構造ありきという考え方から頭が切り替え
られないせいなのでしょう。プログラムをなるべくたくさん書いて
習得したいと思ってるのですが、一人の人間ができる範囲で
これがC++で書ければOOPが理解できる、というような例題は
無いでしょうか？
C->C++で落ちこぼれそうな人間は何がダメなんでしょうか。
宜しく御教示願います。
0692デフォルトの名無しさんNGNG
>>691
C++勉強中のものです。
デザインパターンをやってから初めて自分が進歩できた
気がしました。お勧めです。
その程度の知識ですが
あるとないでは大違いというぐらい考えかたが
代わりますよ。
0693デフォルトの名無しさんNGNG
わからんですなぁ。
Ｃを使いこなせればＣ＋＋なんて簡単にマスターできそうなものですが・・・・

>多分、始めにデータ構造ありきという考え方から頭が切り替え
>られないせいなのでしょう。

そうなのかもしれませんな。

>言語仕様やものの本の例題やソースは理解できるのですが、どうも
>ピンと来ません。

とりあえずその程度で十分なのでは？
多分Ｃを極めたような人には満足できないレベルなのでしょうが
言語仕様を全く理解していなコピペ新入社員の造ったソースが平気で市場に出回ってますよ。
それこそあとはコーディングしまくるしか無いのではないでしょうか？
0694デフォルトの名無しさんNGNG
>>691
ずっとやってれば、
そのうちＣを使うのがいやになってきますよ...。

>>692 のいうとおり、
デザインパターンはＯＯＰを理解する
いい道具になってくれると思います。
継承・仮想関数を使いこなすとはどういうことなのか、
それが分かると思います。

>>693 のように、
最初はコンストラクタ、デストラクタ、参照とか、
便利なところだけを使って組んだのでもいいかもしれませんね。
それだけでもＣ＋＋を使う価値はあると思います。
0695デフォルトの名無しさんNGNG
>>691 あとテンプレートもC++にある便利な機能ですよね

>C->C++で落ちこぼれそうな人間は何がダメなんでしょうか。
>宜しく御教示願います。
　もしかして DIY"DoItYour(My)Self " 精神が邪魔してるんじゃないかなと
　的外れ？
0696デフォルトの名無しさんNGNG
参照って皆さん使ってますか？
0697デフォルトの名無しさんNGNG
参照使っていますけど？　何がお知りになりたいのですか？
0698デフォルトの名無しさんNGNG
>　もしかして DIY"DoItYour(My)Self " 精神が邪魔してるんじゃないかなと
>　的外れ？

的外れじゃないと思うよ。そのものズバリかもしれんのぉ
0699デフォルトの名無しさんNGNG
>>697
ソースが読みやすくなる以外に何かいいことがありますか？
0700デフォルトの名無しさんNGNG
>699　参照ですか？　なら自作クラスで演算子処理させたい時どうしますか？
0701デフォルトの名無しさんNGNG
>>691 　とりあえず BCB++で　差分プログラミングというか　イベント駆動的というかに
　　　馴れてみたら？
0702デフォルトの名無しさんNGNG
>>700
それって参照でないと出来ないことなんですか？
煽りとかじゃなくて本当によく分かりません。
0703デフォルトの名無しさんNGNG
私はC++からプログラムに入ったのでベーシックの方が難しいです。
0704デフォルトの名無しさんNGNG
>>702　聞く前に、complexクラスとか眺めてみましょう。operaterの行
0705落ちこぼれNGNG
皆さんありがとうございます。

実は再入門と言ってもいいのかと思いますが、かなり昔、
ViualCが出たばかりの頃、勉強始めて頓挫したときは、
ClassLibraryのソースや、ヘッダファイルを
読んでいるうちに、うう、わからん・・・となって
しまいました。若い人に聞くと最悪の勉強方法
だったらしく（藁　ああいうのは便利なものと
割り切って”信じて”使うもの、printfを疑わないでしょ？
と言われました。確かにそうですが・・・

思うに、Cを漬|使ってたと言っても、ローレベルと
ハイレベルよりに分かれてると思っています。
手前味噌で申し訳ないですが、実務ではデバイスドライバ
をやることが多く（これはこれでやや特殊な世界なので
書ける人間があまり多くないので担当が固定してしまう
傾向にあります）
制御系をやりすぎるといけないとは思いたくありませんが
ここらへんも原因の一端があるかなと考えています。

とはいえ、自分の置かれてた環境の所為にするのは
恥ずべきことだと思いますので頑張ろうと思っています。
新しい技術に追いつけなくなるのは本当に恐怖します。
0706デフォルトの名無しさんNGNG
参照は小粒でピリリとからい。＃はげしくがいしゅつ？
0707デフォルトの名無しさんNGNG
ガイシュツのＣ＋＋を理解するのに役立つデザイン・パターンの本など御教えいただけないでしょうか？
0708デフォルトの名無しさんNGNG
>>707
GoFの本しかないだろう。と言いたいところだが、
あれは難しいんだよなあ。
頭いい奴に勧めるには最高の本なんだが。
0709デフォルトの名無しさんNGNG
>>708
分かるまで読むべき本でしょ。
分からないからって読まずに済むものならそうしても
いいけど、あれは理解するまで粘るべきものだと思う。
0710デフォルトの名無しさんNGNG
EffectiveC++
0711７０７NGNG
>>708、709，710
皆さん、れすThanxです。
Ｇｏｆってなんのことかわからなかったですけど、わかりました。
「オブジェクト指向における再利用のためのデザインパターン 」
ってやつですよね。今度本屋で見て購入も検討してみます。
今はＣ＋＋勉強中で一通りはわかったつもりですが、細かい点やグレーなとこなどは
ＡＲＭとEffectiveC++で確認しております。
0712デフォルトの名無しさんNGNG
まぁ聞いてくれよ....
コンパイルしたら　エラー12、
もうだめだ........................................
0713デフォルトの名無しさんNGNG
できた、、、、できた、、、
エラー0、
なんか欝だった世界が微笑ましくなったよ、、、
0714デフォルトの名無しさんNGNG
.exe - ｴﾗｰ 0、警告 0
0715デフォルトの名無しさんNGNG
>>705
printfを疑わないといってもprintfくらい作れるという調子で中身
まで追いかけてしまうと難しいのは当然です。

　部品として使うのもひとつの技術で、習得が必要です

Cから移るのなら 似たC++より、Delphiを経由した方が頭の切替が出
来て楽な場合もあります。

　実際、制御系のC使いの人で　C->Delphi->BCB++ ->VC++ という順
序でなんとか追いかけられている人も多いですよ。
かくいう私も４０に届きましたが、Delphi->BCB　まではなんとか使
えるようになりました。　 VC++ はActiveXをなんとかツールの助け
を借りながら作れる段階で　MFCはまだ棚上げしてるんで大きな事は
言えないんですが・・・
0716715NGNG
ようするに言いたい事は、 C -> C++ は似てるけど　違う。

そこにあるギャップを埋めるには C をいったん捨てる事が
人によって良い刺激になる場合がある。　という事です。

VBでも良いようですが、VBよりDelphiの方がC++につながり易いようです。
0717デフォルトの名無しさんNGNG
Ｃ＋＋の学習コース

・オライリー等のＣ＋＋入門本で文法を学ぶ
・ＥｆｆｅｃｔｉｖｅＣ＋＋で言語の詳細を学ぶ
・できればＭｏｒｅＥｆｆｅｃｔｉｖｅも読んでみる
・憂鬱なプログラマの為のオブジェクト指向入門を読む
・できればＥｆｆｅｃｔｉｖｅで復習
・できればＳＴＬのソースを眺めてみる
・最低3回はＣ＋＋でなにかしら作り、クラス設計で苦労してみる。
・オブジェクト指向における再利用のためのデザインパターンを読む
・上記本の続編、パターン言語を読む

デザパタ本は一つ二つは使った事のあるパターンが無いと理解できん。
自分の経験を体系化、客観化する為のものと言っても過言ではないので。
あとはマニアック街道を直走ってくれ。
0718717NGNG
補足。
人にもよるが、まともに設計した事ない人は
>>・最低3回はＣ＋＋でなにかしら作り、クラス設計で苦労してみる。
ここが辛いはず。
オブジェクト指向なんてなんの役に立つんだといいだすのはこの辺。
で、次のステップで数少ない成功パターンがデザパタ本に列挙されてて
涙が出る。という寸法。
0719デフォルトの名無しさんNGNG
>>717　それはC初心者向けコースみたいに思う

Cに慣れた人は、文法とか表面を追いかけすぎてしまうんだと思う
似てるから、追加された :: とか virtual さえ理解したらいい筈と錯覚して
しまうんだと思う
0720717NGNG
>>719
構造化を踏まえた上でオブジェクト指向に移行するのは大変難しい。
構造化の土台も無いと次のステップには進めないから。
表面を追いかけて本質を理解し難いとしたら、
それはもともとそういうやり方しかやってこなかったという場合があるから
構造化からやり直したほうが良いかもしれない。
というか設計をまともにやるプログラマは減ったような気がするよ・・
0721719NGNG
いや　C初心者って書き方は悪かった。
　Cなんて２ヶ月もやれば熟練した人以上のコード書く人もいるんだからね

　”Cだけで５年も１０年もやってない人”　て替えてくれ
0722719NGNG
C言語が高級アセンブラって言われているように
　MS/DOSとかでC言語に入って仕事やってた人は、
　ハードを直接叩いていたんだと思う

　表示とかも、線１本を描くのにDDAのルーチン書く所から
やってたんじゃないかな？

　そういうローレベルな所から全部見渡してコードを書く
スタイルだけで熟練してしまうと、 STL/MFCのような高機能
なライブラリが　既にある　って状態が逆に障害になるんじゃ
ないかと思う。
　STLを見ても、マニュアル使い方の部分だけじゃ満足出来ず
に、つい中身を追いかけてしまう。　で、なまじCが読めるもん
だから部分的に理解出来てしまう。　でも職業人だからコスト
意識もあって、こんな事してちゃ新人にも劣るという自戒から
途中で投げてしまう。

　って感じなんじゃないかな？

だから、本とかで勉強すると余計に泥沼に入ってしまう。
　VBやDelphiを経由するってのは、　中身を追いかけない
スタイルを身に付けるって事じゃないかと
0723デフォルトの名無しさんNGNG
722がいいこと言った
0724落ちこぼれNGNG
仰る通りで、ライブラリも何も無い状態でデバッガなどが
追えない領域で、フルスクラッチからソフトなりモジュールを
起こすことは多かったです。
（線一本から...は図星でして（藁Bresenhamのアルゴリズムなんてのにもお世話になりました）

ただ、既にある、という状態は別に障害とは思わずにありがたいとは思えるんです。
VBは昔から時々使ってました。（あれはテストでWinのインターフェースが欲しい！と急に
言われたときに便利です）

文章じゃなかなか表現できないんですが、いくつかC++で書いた自分の
プログラムが自分で眺めて「うーーん？？」なのです。
なんとも表現しにくいのですが、Cを使えるようになったときの明確な
達成感とはなにか異質で、自分が本当にこの言語のいい部分を使って書けてるの
かなと疑念が付きまとっているというか。

デザインパターンの本、読んでみようと思います。紹介して下さったかた有難う御座います。
0725デフォルトの名無しさんNGNG
結論：
ＶＣ＋＋ばっかりやってると馬鹿になる
男は黙ってＣ言語とアセンブリ
0726デフォルトの名無しさんNGNG
>>725
かってにやってろ｡
0727名無しさんNGNG
まあ
いろいろやってみようや。
0728デフォルトの名無しさんNGNG
趣味でならやる
仕事で人生すり潰されるのはﾀﾏﾗﾝ
0729デフォルトの名無しさんNGNG
>>728
すりつぶされて困るようなたいした人生送ってないだろ
0730デフォルトの名無しさんNGNG
>>729
そういうホントのことはいくら2chでも慎むべきです
0731：デフォルトの名無しさん NGNG
>>725
(ショウユ)って漢字で書ける？
0732デフォルトの名無しさんNGNG
>>731

正油（藁
0733デフォルトの名無しさんNGNG
プログラミング言語C++3版　282ページの下の方に書いてある

コンストラクタで初期設定される

ってところがわかりません。
手元にこの本がある善意ある人、是非無知者を啓蒙してください。
0734デフォルトの名無しさんNGNG
>>733
手元にないからわかんないけど、誤植多いからWebで誤植の
訂正一覧を先に見た方がいいぞ。
0735デフォルトの名無しさんNGNG
cache* cの指す実体が省略されてるコンストラクタ内で初期設定されてる、
つーだけの話だと思うが違うの？
0736デフォルトの名無しさんNGNG
OOPやり始めました
↓
間違えました
↓
Oops.
0737デフォルトの名無しさんNGNG
>>736
Chestを開ける前にthiefでチェックするかpriestの魔法で罠を解きましょう。
0738デフォルトの名無しさんNGNG
入門中の者です。>>696 で聞いてる人がいましたが、
私もいまいち参照がピンと来てません。使い方はわかった
つもりですが、引数で非const渡しを出来る様にしてある
メリットがわかりません。これはどういう時に使う物なん
でしょうか？
あまり使われない物だとすると、コーディング規約レベルで
「参照引数は const 限定」とかしないと、混乱の元の様な気が
するんですが、皆さん実務レベルでどの様に扱われているか興味
があります。
0739デフォルトの名無しさんNGNG
そうですねー。
非constオブジェクトへのconstなポインタを渡したい場合、たとえば

void f(int* const ptr) { *ptrを変更... }

は、ポインタじゃなくて参照で書いてます。

void f(int& ref) { refを変更... }
0740デフォルトの名無しさんNGNG
他のオブジェクトに依存しているが、更新するつもりはさらさら無い場合に
constによる参照渡しを使うな。

そういう場合、参照渡しじゃなかったらコピーを作らなきゃいかんだろ。
メモリとCPUの無駄遣いだ。
0741デフォルトの名無しさんNGNG
文字列操作とかのときを除いて全部参照つかってるんだけど、いかんかな？
0742デフォルトの名無しさんNGNG
良いんじゃないの？
メモリリーク対策等を考えれば
最終的にはポインタなんかもスマートポインタ系でラッピングしちゃうから
参照か実値渡しだけになってくるし。
0743デフォルトの名無しさんNGNG
const参照渡しは、文脈から言って適切であると思われるときは
積極的に使うべきと思われ
ってかCでもそうなんじゃない？
memcpy(void* dst, const void* src, size);
みたいな感じで
0744738NGNG
>>739
レス有難うございます。
でも、そういう風に書けるメリットがわからなかったんですね、これが。
なんというか、呼び出し側のコードで挙動がつかみにくくなる感じが・・・

って、書いてて思いました。オーバーロードや仮想関数で抽象化を進める
為の言語なんだから、部分的に取り出してみたら挙動がつかみにくく
（確定的で無くなる）のは当たり前。より自然に扱えるクラス群を定義
する事に注力するべし。

・・・って感じですかね？
0745デフォルトの名無しさんNGNG
みんなわかってると思うが、738は
「非const参照渡しをどんなとき使ってんのか聞かせてくり」
いうとんのやで。
0746738NGNG
>>740 743
あ、あの・・・私が疑問に思ったのは「非」const の参照渡し
です。
0747745NGNG
うがー本人だ。余計なこと書いてｽﾏｿ。消える。
0748738NGNG
>>747
あ、いえ、フォロー有難うございます。
元の書き方が紛らわしかったですね。
「参照渡しの仕様が const に限定されていないけど、
const 以外で使うメリットはあるの？」
っていう事だったんです。すいません＞ａｌｌ
0749デフォルトの名無しさんNGNG
>>746
オブジェクトのコピーではなく、オブジェクトそのものを渡したいとき。C で非 const の
ポインタ渡しを使う場面で、代わりに参照渡しを使うことがある。参照はあくまで実体が
別にあり、その実体への別名であることがポインタとの違い。

- NULL ポインタのように「何も指していない」ことはありえない。
- ポインタ演算が使えない。
- 値は参照作成時に固定され、以後、代入などの操作は行えない。
0750738NGNG
>>749
なるほど、「実体の保証」はメリットになる場合がありますね。
かなり納得です。

また勉強を進めて、わからなかったら質問させて頂きます。
ありがとうございました。
0751無名参照引数NGNG
>>750
- 値は参照作成時に固定され、以後、代入などの操作は行えない。
もうれしいべ？ type見るだけで、code見る必要ないべさ。
0752デフォルトの名無しさんNGNG
実体の保証というけどさー、EffectiveC++にも
「仮引数 T& に、実引数 *(T*)NULL を渡すやつ逝ってよし」
みたいなこと書いてあったでしょ。実体保証はあくまでも紳士協定というか。
そのへんの不正な引数の可能性には普通どう対処するんですか。
特にクラスライブラリ作ってるような人に聞いてみたい。
0753デフォルトの名無しさんNGNG
>>752
OSによる不正終了。
0754752NGNG
>>753
752は今、無上の悟りを得た！
0755デフォルトの名無しさんNGNG
>>752
対処しない
0756752NGNG
>>755
だから753でわかったてばよー。俺が過剰な気にしんぼだったんだよ。
ﾃﾞﾓｱﾘｶﾞﾄﾈ
0757デフォルトの名無しさんNGNG
ねえねえ、C++では
hoge++;
よりも
++hoge;
のほうが速いって知ってました？ もしかして一般常識？ﾋｴｰ
0758デフォルトの名無しさんNGNG
>>757　そんなら++Cを使いましょう。
0759デフォルトの名無しさんNGNG
環境と最適化依存。
君のクソコードじゃどっちで書こうが大差ない。
0760デフォルトの名無しさんNGNG
VC5SP3でポストインクリメントの一時オブジェクトが最適化されないのは
確認してあるが、他の環境はどうなのだ？
0761デフォルトの名無しさんNGNG
-Oxのみでそうなる？
0762760NGNG
C++ FAQに載ってたサンプルコード、
{
　　Number n;
　　cout << "++n: "; ++n; cout << "\n";
　　cout << "n++: "; n++; cout << "\n";
}
で、出力が本と同じように、

++n: increment
n++; copy increment copy dtor dtor
dtor

になる（dtorはデストラクタ実行）。
もちろんReleaseビルドで最適化オプション入れてあるよ。
0763デフォルト名無しさんNGNG
コボルよりかは１００倍楽
0764デフォルトの名無しさんNGNG
プログラミング言語C++11.3.1（p320）で
operator+を非メンバ演算子としている理由はなんですか。
ストラウストラップさんは
出来るだけクラスの中にきれいに収めろとほかの場所で
薦めていたと思うのですが。
0765デフォルトの名無しさんNGNG
試しに非メンバ演算子使わないで
汎用的に+使えるようにしてみ
0766738NGNG
>>752
・言語仕様的に「実体の保証を要求している」
と言う方がより良い感じかもしれないですね。

で、「実体の別名」であるわけですから、
& 演算子使えばポインタは取れるわけで、
ライブラリ等でチェックしようと思えば出来
ますよね？
（constの場合は、ライブラリ側のビルドは
　constを外した定義で行うとか・・・）
0767デフォルトの名無しさんNGNG
>>765
やってみました。
非メンバ演算子関数の方がエレガントに出来る、
というだけのことなのでしょうか?
0768デフォルトの名無しさんNGNG
>>767
違います。非メンバでないと実現できない機能があります。
キーワードは「暗黙変換」「左辺」。考えてみてください。
0769デフォルトの名無しさんNGNG
>>768
左辺がユーザ定義型でないと
処理が出来ないと言うことですか?

1 + class;
見たいな処理が。
0770デフォルトの名無しさんNGNG
このスレ延々と続いてるけど，関数オブジェクトの話って全く出ないね．．．
Ｃの関数ポインタなんて使い物にならんのでＣ＋＋使ってんだけど，
関数オブジェクト使ってる人って少数派？
0771デフォルトの名無しさんNGNG
>関数オブジェクト
なにそれ？
0772デフォルトの名無しさんNGNG
>>771
operator () をオーバーロードしたクラスをテンプレートで使うことかな。
0773新手のＣ＋＋使いNGNG
>>772

使ったことありますよ。
関数ポインタと違って、受け取る側で、別途 void ポインタとかを
引数で受け取らなくていいのが Good !
なんせ、オブジェクト内に仕込めるからね。
0774デフォルトの名無しさんNGNG
結局、みなヌルポインタに0とNULL、どっちを使ってるですか？
0775デフォルトの名無しさんNGNG
0でしょ。
0776デフォルトの名無しさんNGNG
NULLはCの規格だしね。
07771000!NGNG
1000!
0778デフォルトの名無しさんNGNG
関数オブジェクト知らんヤツはCoplienのイディオム本読め。
ファンクターについて研究しろ。
それでも分らんかったら、オレが教えたる。
ただし、ﾃｨﾝﾎﾟ臭くないヤツだけな。
0779デフォルトの名無しさんNGNG
なるほど。0なんですか。
0780デフォルトの名無しさんNGNG
私は NULL。

>>776
別スレでも書いたけど NULL は C++ でも null pointer constant と規定されてます。
0781デフォルトの名無しさんNGNG
>>780
それってCとの互換性という意味しかないですよね?
0782デフォルトの名無しさんNGNG
>>781
意図が良くわかりませんが、私が 0 ではなく NULL を使うのは「null pointer constant を意図して
書いているのだ」とソースコードを見て分かるようにです。もちろん文法的にはどっちでも OK。

class だけでなく struct が使えるとか、NULL と同じ <cstddef> で定義されている size_t 型、ついで
に sizeof, offsetoff なんかも「C との互換性」という意味しかないっちゃあ無いですね。C++ ならメモ
リ確保するのに malloc + sizeof ではなく new で一発なわけだし。
0783781NGNG
>>782
C++ではnull pointer constantって必ず0じゃないですか。
だからポインタ変数に0が代入されてるとnull pointer constantってわかりますよね?
ポインタ変数以外にnull pointer constantを使うこともないですよね?
それで、NULLを使うのはCのコードとの互換性と、Cに慣れてる人がコードを
読み書きしやすいって以外に利点はあるのかなと思って。

NULLって別に定数でもなんでもないただの0ですよね?
数字の1とか2を使う変わりに
#define INT_1 1
#define INT_2 2
ってしたほうがint型の1や2を意図してるとは思わないですし…

size_tとかsizeofのかわりに何を使えばいいのかは良くわかりませんが。
0784デフォルトの名無しさんNGNG
>>783
その1や2がintなのかlongなのかなんてのはどうでもいい話であって、
それが例えば
#define MODE_MASTER 1
#define MODE_SLAVE 2
になっていたら、”モードがマスターである”という意味の1であるという
ことが重要なわけだ。実際にはこのMODE_MASTERは102だろうが8848
だろうがなんでもよくて、ただ一意であることのみが求められる。
同様にNULLも定数0というのは別にどうでもよくて、それがnullポインタ
であるということが重要であり、示されるべき意味なわけ。
0785781NGNG
>>784
なんでどうでもいいのかわからない。
数字を見ただけじゃ型はわからないですよ。

例が悪かったかも知れませんので、
#define INT_0 0
の場合を考えてみて下さい。

このマクロがないと0が出てきた時に数字の0であると判断できませんよ。
0786デフォルトの名無しさんNGNG
NULLを使う利点がCで使ってたという歴史的理由以外にあったら教えて下さい。
(ここでは、歴史的理由とはプログラムの互換性やプログラマがNULLを
nullポインタだと知っているということなどを意味します)

NULLとは何か?
ポインタのコンテキストで使えばnullポインタ。
それ以外の場所で使えば、単なる整数リテラル0。

0とは何か?
ポインタのコンテキストで使えばnullポインタ。
それ以外の場所で使えば、単なる整数リテラル0。
0787デフォルトの名無しさんNGNG
>>786
まさしくその"ポインタのコンテキスト"として使用していることを
明示するためにNULLがある。
0788デフォルトの名無しさんNGNG
明示すること自体が目的なの?
それって意味ある?
正しく使ってるかどうかはプログラマの責任でしょ?
誰に対して明示してるの?
C言語を使いなれたプログラマだったりしない?
intのコンテキストを明示するINT_1はどうでもいいって言えるのはなぜ?
0789デフォルトの名無しさんNGNG
780ではないですが、NULL 賛成派なので、反論を試みる。

> それで、NULLを使うのはCのコードとの互換性と、Cに慣れてる人がコードを
> 読み書きしやすいって以外に利点はあるのかなと思って。

それ以外の利点なるものが必要なのか？
利点が１個、欠点が０個。
だったら使う方がいいに決まってる。
使わない理由は何だ？

> 例が悪かったかも知れませんので、
> #define INT_0 0
> の場合を考えてみて下さい。
>
> このマクロがないと0が出てきた時に数字の0であると判断できませんよ。

それはまったくもってそのとおり。今後気を付けましょう。
int(0) とか書けば良いですね。

> NULLとは何か?
> ポインタのコンテキストで使えばnullポインタ。
> それ以外の場所で使えば、単なる整数リテラル0。

事実としてはそうだけど、混乱の元なので
それ以外の場所で使わないで欲しいです。
貴方も使わないでしょう。

> 0とは何か?
> ポインタのコンテキストで使えばnullポインタ。
> それ以外の場所で使えば、単なる整数リテラル0。

そのとおりですが、
私はポインタのコンテキストでは 0 とは書かず、
必ず NULL と書くようにしています。
0790デフォルトの名無しさんNGNG
続き。

> intのコンテキストを明示するINT_1はどうでもいいって言えるのはなぜ?

1 と書けば間違いなく int です。
long だったら1L だし、
unsigned だったら 1u だし、
char だったら '\x01' です。
1 と書けば間違いなく int です。

しかし 0 は、それだけだと int の 0 か
NULL ポインタ定数か判断できない（可能性がある）。

> 明示すること自体が目的なの?

Yes

> 誰に対して明示してるの?

自分。
チーム開発なら、他のメンバーに対して。
オープンソースにしてるなら、不特定多数に対しても。

> それって意味ある?
> 正しく使ってるかどうかはプログラマの責任でしょ?

意味はある。
正しく使うことはプログラマの責任だが、
後にこれを読む他人（数ヶ月後の自分を含む）の理解を助ける。

読みにくいより読みやすい方がいいに決まってるから使う。
どこか間違ってます？

＃もしかすると貴方には読みやすいソースを書くべきという
＃心掛けがないのかもしれない。だったら議論は無意味。
0791デフォルトの名無しさんNGNG
>>783
細かい突っ込みだが C++ の null pointer constant は 0L の可能性もある。
0792デフォルトの名無しさんNGNG
>>788
> intのコンテキストを明示するINT_1はどうでもいいって言えるのはなぜ?
int の 1 なら 1 で良いから。

そうではなく、別の意味を持つ 1 なら enum なんかで名前を与えるべき。直接マジックナンバーの 1 を
使うのはお勧めできない。
0793デフォルトの名無しさんNGNG
INT_1の例はちょっと失敗だったかなぁ。
Cには1の実体を表す表現は1しかないから1を1として使ってるでしょ?
同様にnullポインタを表す表現は0しかないじゃないですか。

ちなみに僕は欠点は二つあると考えてます。
一つは、文字が長いこと。タイプ量とかソースの複雑さの意味で。
もう一つは、正しく使われてることを検証できないこと。
これはNULLに限らずマクロ一般に言えますが、
プログラムが正しく動作していてもNULLが正しく使われているとは限りません。
これは読みやすさを損なう原因になると思います。

ソースを読む時のことを考えると、
0しか使わなければ、0が出現した時に整数かポインタか考えれば言いですが、
NULLを使っていれば、0が出現した時とNULLが出現した時に考えなくてはいけません。
これはほとんどただしいコンテキストで使われているときに
(つまりできるだけ正しく使おうと努力してる場合に)
もっともソースを読んでいる人を罠にひっかけやすくなります。

ちなみに別の意味を持つ1はここでは考えてません。
NULLも別の意味ではなくて0の本来の意味をあらわすのに使われてますから。

1の整数リテラルとしての型もここでは意味がないと思います。
0もそれ自体がポインタ型ではありませんし。
0794デフォルトの名無しさんNGNG
>>793
> 一つは、文字が長いこと。タイプ量とかソースの複雑さの意味で。
それは、変数名も a, b, c とか一文字にしたほうが良い、ということですか？
0795デフォルトの名無しさんNGNG
>>794
新しく名前を導入する時の話しじゃないですよ?
すでにある二つの名前のうちどちらを選ぶかですので、
もし、
int a;
#define tmp_int_a a
と宣言してあったら、僕はaの方を使います。
0796デフォルトの名無しさんNGNG
>>795
#define F_ERROR 0
#define F_READ 1
#define F_WRITE 2
#define F_EXCLUSIVE 4

File f;
f.open("foo.txt", F_READ | F_EXCLUSIVE);

よりも

f.open("foo.txt", 5);

の方が妥当というわけですね。
0797デフォルトの名無しさんNGNG
NULL 派だけど、ここでこれ以上議論しても得るものは無いと思うので、わたしは引くよ。

>>788
もしコーディングスタイルに関する議論に興味があるなら、Microsoft Press から出ている「コードコンプ
リート」、「ライティングソリッドコード」、それに ASCII から出ている「プログラミング作法」といった書籍を
読んでみることを勧めておきます。
0798デフォルトの名無しさんNGNG
>>797
それはその通りですね。
もっとも、僕はそもそも何かが得られるとは思ってませんでしたが。
ただNULLを(void*)0でなく厳密に0または0Lだと定義しているのは
C++ではNULLを使うことを推奨してないと僕は思ってます。

>>796
以前の書き込みをちゃんと読んでもらえるとわかりますが、
他の意味を持つ場合について議論しているわけではありません。
またconstant foldingを手でやることも主張していません。
0799デフォルトの名無しさんNGNG
>>798
> ただNULLを(void*)0でなく厳密に0または0Lだと定義しているのは
> C++ではNULLを使うことを推奨してないと僕は思ってます。
どうなんだろうね。規格書は手元にあるけど、これには「なぜそうなったのか」ということは書いてないから
分からんね。

経緯に詳しい人がいたら、なぜ C++ で (void *) から (Foo *) への暗黙の型変換を禁止したのか、理由
を聞いてみたい気がする。
0800デフォルトの名無しさんNGNG
C++が難しい理由。
階級制度を確立するため。
C++プログラマ＞＞その他のプログラマ＞＞＞＞＞エンドユーザ
0801デフォルトの名無しさんNGNG
俺はNULL使ってますが、

＞0しか使わなければ、0が出現した時に整数かポインタか考えれば言いですが、
＞NULLを使っていれば、0が出現した時とNULLが出現した時に考えなくてはいけません。

なんか妙な印象を受けました。
0と書かれてた方が、考える手間が発生すると思いますがいかが？

NULLの中身が0だと知ってさえいれば、「値かポインタか」を考える必要はないので、
一体全体、NULLと書くと何を悩むのか疑問です。

ptr = 0;とかかれてたときにこそ悩みます。値を意図したのか、ポインタを意図したのか。

知っていれば悩まないものは知識の問題ですが、
知っていても悩むものは知恵の問題です。

ポインタに0を代入したり、値にNULLを入れていた場合、
それはコーディング規約違反に相当しますね。うちの場合は。
止むに止まれぬ事情でそうしないとならない場合は、コメントつける必要すらあります。
これは使用者のレベルを問うのではなく、ルールだと思うんですが。

0やNULLの使い方に一貫性を持たせられないようなレベルの人は、
もっとしっかり教育したほうがよいと思います。
0802デフォルトの名無しさんNGNG
>NULLの中身が0だと知ってさえいれば
この仮定ができない。
0803801NGNG
そこはルール化すべきだと言ってるのです。
0804デフォルトの名無しさんNGNG
> そこはルール化すべきだと言ってるのです。
だったらcstdioのマクロもってくる必要なんてないだろ。
#define NIL 0
かなんかを定義してソレ使うってコーディング規約にする
とかいう話であれば、801の話はその通りだと思うよ。
0805デフォルトの名無しさんNGNG
ほほぅ
これが噂の宗教戦争ですか
0806デフォルトの名無しさんNGNG
801 じゃないけど、
>>804
何に反論してるのか、自分の立場はどうなのかを明記して欲しいな。名無しさんだと、誰が誰だか分からん。
0807デフォルトの名無しさんNGNG
>>805
Yes. でも、たまに有用な方向に議論が転がることもあるので、敢えて止める必要はなし。
0808デフォルトの名無しさんNGNG
時々見かけますが、
決められてないからといって、そこには「あらゆる可能性がある」なんて
一種杓子定規な考え方をしてる人は、実務上では大変困ります。

決められてないところは、使っているこちら側が一般的な範囲でルール化
して差し支えないと思いますよ。

NULL == 0 が絶対ではないとして、
一般的に NULL != 0 の可能性を論じる意義ってあるんですか？
その職場、その開発環境で
「NULL = 0 もしくは NULL = (void *)0 と決めましょう。」
と話し合って文書化するだけのことではないの？

NULL = 100 にしましょうなんて言いだすやつ、見たことないですよ。僕は。
0809デフォルトの名無しさんNGNG
>>808
話のつながりが見えないのですが、あなたは誰ですか？

> NULL = 100 にしましょうなんて言いだすやつ、見たことないですよ。
確かに、そんな間抜けなことを言ったのは「電子のお針箱」ぐらいですな。
0810デフォルトの名無しさんNGNG
>>809
お針箱たん…ハァハァ
ワラタ
08110を使って玄人気分NGNG
つーか最初から予約語nil入れときゃ良かったんだよ
0812804NGNG
自明とも思えるつまらん主張をわざわざ書くの面倒なんだけど、、
>>804 は

・C++ではヌルポインタの表現は単に 0 とするのが良い。
・cstdioの NULL が全プラットフォームで 0 とdefineされているという仮定はできない
・数値の0とヌルポインタが区別できないとソースコードが読みにくいという意見がある(俺はとくに感じないが..)

以上から、#define NIL 0 して、ヌルポインタの表現にコレつかうのが
妥当な妥協点なんじゃネーノ？という意見なんだけど。

・NULLを使う為だけに #include <cstdio> なんて書きたくない

というのもあるけど宗教なんちゃらになるからやめとく。
0813デフォルトの名無しさんNGNG
おいらは 0 派なんだけど(ソースを grep NULL して出てこなかった)
困りそうなのは Foo( int c); Foo( object * p); かな
後者を呼ぶときは意図的に Foo( (object*)0);
なんてしてる。これって正しいのかな。

NULL は…大文字っていうのと（４つ続けて大文字ってのは打ちづらい）
見た目がなんとなく嫌（ﾜﾗ。あと定義がごちゃごちゃしてて面倒だから。
0 なんてワンキーですから。
0814デフォルトの名無しさんNGNG
NULLは0です。
そうで無いとこれまでに作ったものが動かなくなります。
0815804NGNG
>「NULL = 0 もしくは NULL = (void *)0 と決めましょう。」
>と話し合って文書化するだけのことではないの？
NULLの定義は決めるものでなく与えられるものです。
0816デフォルトの名無しさんNGNG
まあ、動くからいいじゃん。NULLでも0でも。
プログラムなんて工業製品なんだよ。数理ではない。
0817デフォルトの名無しさんNGNG
>>813
C++ だと NULL は 0, 0L が一般的だから、

　Foo(NULL);

は Foo(int) 呼び出しになる。これは NULL 使う場合には要注意な点。

というかポインタと整数型で多重定義するのはやめとけ、というのが Effective C++ のアドバイス。

>>812
細かい点だが NULL だけなら <cstddef> の方が。こいつは size_t なんかも定義してるから、なんだ
かんだで読み込んでることが多いな、俺の場合。
0818デフォルトの名無しさんNGNG
・NULLの内容を仮定できないって言われても、実際0でないNULLに出逢ったことは無いんだが。
・見ただけでポインタと値くらいは区別できたほうがいいと思うんだけどねぇ。（書いた人の意図を知る意味でも）

実務上問題の無い可能性を恐れて、0を書くってのはどーも・・・・。
0819デフォルトの名無しさんNGNG
>>812
> ・C++ではヌルポインタの表現は単に 0 とするのが良い。
これは、今のところ客観的な理由が示されてない気がする。

C++ の規格書では NULL は C++ null pointer constant と明記されてるから、NULL と書いて問題が
発生することはない。逆に 0 と書いて問題が発生することもないけど。
0820デフォルトの名無しさんNGNG
if(!p)はif(p==NULL)にしないと駄目？
0821デフォルトの名無しさんNGNG
>>820
それは別の問題だから、今持ち込むのはやめといた方が。
0822デフォルトの名無しさんNGNG
#define 0 NULL
0823813NGNG
>>817
なるほどです。NULL := 0 では意図したのと違うことになりますね。

>というかポインタと整数型で多重定義するのはやめとけ、というのが
そうですね。NULLな人にはちょっと不味いことになりますね。
(object *)NULL なんてのはちょっと…あれですし。
0824デフォルトの名無しさんNGNG
>>822 ありがと、少しだけ藁たよ。
0825デフォルトの名無しさんNGNG
(object *)NULL これはこれでよいと思う。
(void *)NULL これは面白くないけどね。
0826デフォルトの名無しさんNGNG
下らない事で、良くそれだけ話せますね。
0827デフォルトの名無しさんNGNG
>>820
if( p == 0 ) でもイイと思う
if( p != NULL ) は単に if( p ) と書けます
0828デフォルトの名無しさんNGNG
fjに帰れ
0829デフォルトの名無しさんNGNG
>>826
ま、プログラミング言語なんて、くだらない詳細に満ちた道具だからね ;)　特に C++ は、ある程度
詳細を押さえないと、そこらじゅうに口を広げて待っている落とし穴に飲み込まれる。
0830デフォルトの名無しさんNGNG
数値計算するならC++のほうが便利だよ。
0831デフォルトの名無しさんNGNG
つまり、
NULL を (void *)0 にしなかった誰かが一番悪いということに・・・・。
0832デフォルトの名無しさんNGNG
829 は有意義な議論と見せかけるのに必死だ(藁)
0833820NGNG
>>827
たとえばmallocの戻り値って失敗するとNULLになるけど、
NULLが0じゃないとif(!p)は使えないんだよね？
で、NULLが10とかだと困らない？
0834デフォルトの名無しさんNGNG
こういうくだらない議論でも、見てる初心者の役に立つことはあるから、
あながち無益という訳でもなかろう。>>826
0835デフォルトの名無しさんNGNG
#define NULL ((void*)0)

ならば

char* p = NULL;

って書けないから

char* p = 0;

になるね。
といって

#define NULL 0

だと 817 氏が言うような問題がある。
0836デフォルトの名無しさんNGNG
>>831
いや、C++ だと (void *) から他のポインタ型への暗黙の変換を認めていないから (void *)0 だと
実用上辛すぎ。

>>832
煽りご苦労。
0837デフォルトの名無しさんNGNG
>>825
安全にするには NULL 派でも 0 派でも
(object *) のキャストをつけるべき、ということなんですね。
このほうが意味合いがはっきりしますし。
0838デフォルトの名無しさんNGNG
>>836
ていうか暗黙の型変換を容認できなかったからNULLを(void *)0と
定義できなかったんじゃないかって気もするが。
0839デフォルトの名無しさんNGNG
ってことで、ぼちぼち議論が一周したね。
0840デフォルトの名無しさんNGNG
>>836
ごめん本気で話してたのね(藁)
NULLはNULLって事で困ったことないから。
0841デフォルトの名無しさんNGNG
個人的には NULL を使わず 0 で書いてるなぁ。
キャストをいちいち書くのが面倒だから。
そもそも C++ 形式のキャストは書くのが面倒臭い・・・。
0842デフォルトの名無しさんNGNG
>>841
<reinterpret_cast> とか？
長いですよね。
0843デフォルトの名無しさんNGNG
>>833
規格上 null pointer value を評価したら偽になることが要請されているから、ANSI C++ 準拠の C++ 処理系
なら、ポインタ型の変数 p に対して

if (!p)
if (p == NULL)

は同じ結果になる。

> 4.12 Boolean conversions
> 1 An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue of
> type bool. A zero value, null pointer value, or null member pointer value is converted to false; any
> other value is converted to true.
0844デフォルトの名無しさんNGNG
>>841
NULL を使うとキャスト必須だが、0 ならキャスト不要な処理系ってあるの？
0845デフォルトの名無しさんNGNG
>>841
キャストしてるのが、ソース上わかりやすくなるとか言う馬鹿がいたが、
Ｊａｖａ並に目障りで、かえって見づらいんじゃ。
0846デフォルトの名無しさんNGNG
>>817さんへ

0の場合もNULLの場合も、ポインタであることを明示するにはキャストしないとならないのだから、
結局多重定義のときは型変換噛ませるしかないよね。
void Foo(int);
void Foo(void *);

Foo(NULL)
Foo(0)

で呼ばれるのはFoo(int)だし。
つまり、何がいいたいかというと、

Foo((void *)NULL);
Foo((void *)0);
という渡し方をしたい場合は、必ずキャスト必須というのはC++では当たり前と
考えるべきじゃないかと。
よって、0とNULLの議論にはあまり関係ないと考える次第です。
0847デフォルトの名無しさんNGNG
>>845
どこに、そんなバカがいたんだ？

837 は見やすい／見にくいの話ではなく、そうしないと確実に「まずい」場合だから違うよね。
0848デフォルトの名無しさんNGNG
>>833
ポインタ演算で 0(NULL) が出てくると
null pointer として扱うルールなので
実際のnull pointerの値とは関係無いらしいです。
NULLが10になるとかいうことはないらしい。
0849デフォルトの名無しさんNGNG
まず、ポインタ型変数 p があったときに、
p = 0;
としたあと、p のビットが全部 0 だとは限らないです。
つ
0850デフォルトの名無しさんNGNG
>>844
gcc 使ってるけど 0 なら通るよ。
0851817NGNG
>>846
念のため。私は NULL 使う人です。

> よって、0とNULLの議論にはあまり関係ないと考える次第です。
同意。
0852デフォルトの名無しさんNGNG
>>850
NULL だと通らないの？
0853デフォルトの名無しさんNGNG
>>847
Ｃ＋＋の記述形式についての話に決まってんだろ。
0854デフォルトの名無しさんNGNG
>>852
#define NULL ((void*)0) なら通らない。
0855デフォルトの名無しさんNGNG
>>853
正直、「キャストしてるのが、ソース上わかりやすくなるとか言う馬鹿」が、どの発言を指しているのか
分からないです。そんな怒らんで、マターリ行って欲しいんだが、ダメ？
0856820NGNG
＞規格上 null pointer value を評価したら
＞偽になることが要請されている
なんとっ

＞それは別の問題だから
やっと意味がわかりました。
0857デフォルトの名無しさんNGNG
>>854
それは明確に ANSI C++ の規格に反してる。昔の処理系ならともかく、今時の処理系で

#define NULL ((void*)0)

はないでしょ。
0858デフォルトの名無しさんNGNG
>>857
windows.h とかその辺でそう宣言しちゃってるからなぁ。
0859デフォルトの名無しさんNGNG
>>855
つまりね、841の
>そもそも C++ 形式のキャストは書くのが面倒臭い・・・。
とあるでしょ。それで、Ｃ＋＋のキャストの記述形式を、
>キャストしてるのが、ソース上わかりやすくなる
と肯定してる人がいたわけよ。で、あんな回りくどい記述は、
>Ｊａｖａ並に目障りで、かえって見づらいんじゃ。
と言ったのよ。
0860デフォルトの名無しさんNGNG
宣言じゃないか。
sage
0861デフォルトの名無しさんNGNG
これだな。
> 4.10 Pointer conversions
> A null pointer constant is an integral constant expression rvalue of integer type that evaluates to
> zero. (後略)

だから C++ だと NULL は 0, 0L とマクロ定義されていることはあっても (void*)0 と定義されていることは
ありえない。
0862デフォルトの名無しさんNGNG
>>859
詳しい説明、ありがとう。納得しました。

C++ で static_cast, reinterpret_cast, const_cast を分けたのは英断だと思うけど、文法はもう少し
どうにかして欲しいですね、確かに。
0863デフォルトの名無しさんNGNG
結局のとこ、月並みなお話として、null pointerを

・NULLと書いてポインタを意識していることを明示する
・0と書いて紛れもなく0であることを明示する

なのかな。お互いの反論要素として、
・NULL != 0 でない可能性は論じるだけ無意味。
・NULLは定義がポインタじゃないから、多重定義の関数で解釈が int になるのは気持ち悪いが、
　どっちみちキャストする以外に直値のポインタを渡す手は無いので、問題なし。

ということで、どちらの反論もやっぱり無意味とくらぁ。

>>854じゃないけど
別に
#define NULL ((void*)0)
にすべきだと言ってるわけじゃないと思うよ。>>857
0864デフォルトの名無しさんNGNG
修正
×・NULL != 0 でない可能性は論じるだけ無意味。
○・NULL == 0 でない可能性は論じるだけ無意味。
0865デフォルトの名無しさんNGNG
>>858
うそーん。#ifdef __cplusplus で場合分けしてない？　VC6 の <stdio.h> は、こうなってるよ。

#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
0866デフォルトの名無しさんNGNG
>>865
あら？そうなってる？
今手元に gcc しかないから分からない(笑)
VC2 ぐらいを使ってたときにそれで文句を言われたような記憶があって
それ以来 0 を使うようにしてるだけなんだけどね。
NULL で OK ならそっち使おっと♪
0867デフォルトの名無しさんNGNG
windows.hからincludeされてるwindef.hでは

#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif

ってなってるね。（VC6.0）
0868デフォルトの名無しさんNGNG
reinterpret_castとか書くのが面倒くさいとかいってる連中はStroustrupの
本を読んでいないことがばれて恥ずかしー立場に置かれている。
ってかカット&ペーストの利用できない環境でプログラミングしてるんじゃ
ないだろうな?
0869デフォルトの名無しさんNGNG
>>866
最近の gcc だと __null 使ってるよね。

__null はマクロではなくコンパイラが直に理解する null pointer constant で、

int *p = __null;　　// OK
int n = __null;　　// NG

となる（任意のポインタ型に対する null pointer constant として使える一方で、整数型として評価すると
怒られる）。

個人的には、次の C++ 標準規格に入って欲しい機能の筆頭です。
0870デフォルトの名無しさんNGNG
宣言と定義の違いって何ですか？
0871デフォルトの名無しさんNGNG
>>868
プログラミング言語C++の話？そういうこと書いてあるの？
コピペでどうにかできるもんじゃないと思うけどなぁ。
0872デフォルトの名無しさんNGNG
>>870
ネタ？　本気で質問したいなら、質問スレに行ったほうが良いと思うぞ。

extern int n;　　// 宣言
int n;　　// 定義
0873デフォルトの名無しさんNGNG
>>868
あんまりかまいたくないタイプだが、ソースは読みやすいほうがいいだろ
本読んでるぜとか、読んでないだろとか、機能がどうとかじゃない
C++のキャスト書くと、1行でおさまらなくなる場合が多い
0874デフォルトの名無しさんNGNG
>>869 あ、そんなのあるんだ。知らなかった。
俺も次のC++には入れて欲しいと思う。
boolやtrue,falseもC++標準に入れたんだから、この際徹底的にやって欲しいね。
その場合、単に null がいいなぁ。
0875デフォルトの名無しさんNGNG
>>874
激同。
でも C++ 自体いつまでメインストリームに残り続けるのかちょっと不安。
0876デフォルトの名無しさんNGNG
>>868
C++ で

- キャストの文法を変更して、簡単にキャストと分かる(grep できる)ようにした
- キャストを用途別に分けた

ことに対して文句を言っている人は、このスレでは見かけない。ただ reinterpret_cast<Foo*>(p) という
表記は長すぎて読みにくい、と見た目について文句を言ってる。
0877デフォルトの名無しさんNGNG
>>873 >>876
見た目が汚い風にわざとした、ってStroustrupの本に書いてあるだろがよ(ｗ
なんかムキになられるとこっちが恥ずかしいぞ。
つまり無闇に使うなってこと＞reinterpret_cast
Cスタイル文字列と同じで推奨されてないつーこった
0878デフォルトの名無しさんNGNG
>>877
まぁまぁ、そう煽るなよ。

> つまり無闇に使うなってこと＞reinterpret_cast
Win32 API 使ってプログラミングしてると、どーしても必要になるし。
0879デフォルトの名無しさんNGNG
>>877
dynamic_castだって、たいしてかわらんだろ。
自分で書いてて、目障りじゃないのか？
0880デフォルトの名無しさんNGNG
>>877

実務上はかなり頻繁にキャスト必要だし、
理想と現実のギャップってことで納得しようよ。

「自分のライブラリ内では、限りなくキャストは少なくてすむようにする」
これが精一杯だよね普通。
0881デフォルトの名無しさんNGNG
C++って何て読むの？
0882デフォルトの名無しさんNGNG
Cスタイルキャストで書いてしまう漏れはダメですか。
0883デフォルトの名無しさんNGNG
>>881
しーぷらぷら
しーぷらすぷらす

外人はちゃんと　しーぷらすぷらす　と読んでいるらしい。
0884デフォルトの名無しさんNGNG
>>879
危険でバグの温床になる、っていうわかるのでむしろありが
たいね＞目障り
要するに、Cのキャストと比較するから目障りっていうんだろ。
それともObjectからみんな派生してるJavaか?
プログラマに制約を押し付けるデザインは最近のトレンドだと思うよ。
0885デフォルトの名無しさんNGNG
>>881
#ifdef __cplusplus
0886デフォルトの名無しさんNGNG
>>884
まあいいんじゃない。本に書いてあるとおり、ありがたいなら。
俺はソースがわかりにくくなってやだね。
0887デフォルトの名無しさんNGNG
>>886
じゃあわかりにくくないためにはどうすればいいわけ? ベストな提案をだしてくれよ(ｗ
0888デフォルトの名無しさんNGNG
>>884
後半は、ちょっと意味不明だな。前半は、同意するかどうかは別として、理解可能だけど。

何にせよ双方とも言いたいことは言ったと思うので、このあたりでキャストの見た目に関する話は
終わりにしないか？　これ以上は議論しても得るところはなさそうだし。
0889ﾙﾋﾞ厨NGNG
>>887
Rubyで書き直す！！！！！
0890デフォルトの名無しさんNGNG
>>888
なんだ、自分で祭りを終わらせるのかよ(ｗ
0891デフォルトの名無しさんNGNG
>>887
今の記述形式が良いか悪いかの話。あんたは良いんだから問題ないだろ。
0892デフォルトの名無しさんNGNG
>>890
ん、誰かと勘違いしてる？　俺は NULL 論議で満足したので、キャストの方は不参加だ。
0893デフォルトの名無しさんNGNG
>>890
私もいますが?
0894デフォルトの名無しさんNGNG
C/C++については変数のサイズの方が気に掛かる。
符号付整数のシフトとかも。
ばしっと決めてもらえないものか。
0895デフォルトの名無しさんNGNG
俺もいるが（藁）
って、これじゃ自作自演だ。
0896デフォルトの名無しさんNGNG
ちなみに俺も居るよ。

int のサイズが環境ごとに不定だから、いつまでもキャストと縁が切れないのは、
俺たちの不幸を象徴しているように思うのだった。
0897デフォルトの名無しさんNGNG
>>891
いや問題あるよ。もっと良い代替案があるなら寝る前に是非聞いてみたい。
reinterpret_castが目障り、っていうならなんかいい代わりの形式でも
あるのかと期待しちゃって眠れないよ。

>>892
ﾊｽﾞｶｼｰ仕切屋さんだけどｶﾞﾝﾊﾞﾚ!(・∀・)
0898デフォルトの名無しさんNGNG
>>897
そろそろ煽り厨房ってことで、放置かな。
0899デフォルトの名無しさんNGNG
>>884
C の考え方でいくと、少々危険なことでもプログラマの自由にする
(C language is Free) という考え方があって、しかも簡潔に
書けるので人気があるのですが
C++ の reinterpret は C の簡潔に(Make it Simple)
プログラマーを信頼する(Trust the programmer)という精神から
逸脱しすぎているような気がして少々残念かな。

C++ は C とは似てコトなるものですから、それが C++ の流儀って
いうなら仕方ないですけど。
ブロック転送で reinterpret_cast<const int *>(p++) ?? という
文章が数十個所でてくるのはちと目に痛いというか、キャストの主張が
大きすぎて何をしているのかわからなくなるというか。
0900Kusakabe YouichiNGNG
> int のサイズが環境ごとに不定だから、いつまでもキャストと縁が切れない

サイズの保証された整数型を使えばいいだけでは?
(たとえば「必ず16bit」とか「少なくとも16bit」とか)

> 符号付整数のシフトとかも。 ばしっと決めてもらえないものか。

Javaみたいに「>>>」演算子があるといいっていう話でしょうか?
0901デフォルトの名無しさんNGNG
>>897
君には今のままが最適。安心して寝なさい。
0902煽り厨房NGNG
>>899
インライン関数やテンプレートで軽減できないの? ＞数十個所
0903デフォルトの名無しさんNGNG
>>897
オヤスミン (生薬配合)
0904デフォルトの名無しさんNGNG
>>900-896
C99 あたりに int32 とかそんな予約語なかったですか？
定義しようという動きはあるみたいなんですけど。
0905デフォルトの名無しさんNGNG
>>900
さしあたってはそういうこと。＜>>>演算子
あと演算の未定義が多いのもどうにかして欲しい。
0906煽り厨房NGNG
>>899
どうかな、XPなんていい大人にペアプログラミングさせるくらい
なんだからそれくらいでプログラマーが信頼されてないと感じる
というのはもったいない話だ。
0907デフォルトの名無しさんNGNG
>>902
うーん。少しの作業で名前空間を汚すのがちょっと気がひけるというか。
0908デフォルトの名無しさんNGNG
>>905
１の補数と２の補数問題とかね。＞演算の未定義
最近で１の補数使ってるチップってあるのかな？
0909デフォルトの名無しさんNGNG
>サイズの保証された整数型を使えばいいだけでは?
>(たとえば「必ず16bit」とか「少なくとも16bit」とか)

そんなこと現実に出来るならやってごらんよ。
標準ライブラリがint使ってるってのに。

俺はこの問題が煩わしくて、自分のライブラリ内ではint使ってねぇもの。
0910デフォルトの名無しさんNGNG
>>908
他にも f() + g() * h() と書いてどの関数が最初に呼ばれるか、とか。
i = i ++; がどう評価されるかとか。
0911デフォルトの名無しさんNGNG
>>909
うちだと
VC(Pentium), unix(Pentium) 用に
　typedef unsigned int UINT32;
MS-DOS(i8086)用に
　typedef unsigned long UINT32;
あとは make のお仕事。
これで自分のルーチンには 32ビット整数が使えるけど
標準ライブラリは…キャストがうまくいくかチェックする
必要があって面倒です。
0912デフォルトの名無しさんNGNG
関数の評価順はまだしも
i = i++; みたいなのは書きたいと思ったこともないが…
0913デフォルトの名無しさんNGNG
>>912
i = i ++; は書きたいという話ではないよ。
未定義ならばエラーとしてはねるぐらいのことはしてもいいと思うわけ。
0914デフォルトの名無しさんNGNG
>>911
Win64になったらどうするんだ?
0915Kusakabe YouichiNGNG
> int のサイズが環境ごとに不定だから、いつまでもキャストと縁が切れない

サイズの保証された整数型を使えばいいだけでは?
(たとえば「必ず16bit」とか「少なくとも16bit」とか)

> 符号付整数のシフトとかも。 ばしっと決めてもらえないものか。

Javaみたいに「>>>」演算子があるといいっていう話でしょうか?
0916デフォルトの名無しさんNGNG
>>914
Win64用のファイルが必要になります。
　typedef unsigned short int UINT32;
とか。面倒なので個人的には公式に定義してほしいものです。
int とは別に。
0917デフォルトの名無しさんNGNG
>>916
WindowsのUINT32そのまま使うのでは駄目な理由を教えて下さい。
0918sageNGNG
>>917
最近のVCはUINT32(しかも同名？)があるの。知らなかった(ﾜﾗ
元々プラットホームの依存性を無くす方向で仕方なく取った方法なので
処理系が提供してくれるならそれに越したことは無いです。
ISOで定義してくれればそれで済むことなんですよね…。
0919デフォルトの名無しさんNGNG
uint32_t じゃダメですか？
C99 で stdint.h で定義されます。
0920デフォルトの名無しさんNGNG
ゲームとか組み込みみたく、ハードに近いところで
組んでるわけじゃないからintのサイズを意識することなんて、
ほとんどないね。俺の場合。
(intが16bitの環境は無視ということで)
0921デフォルトの名無しさんNGNG
祭だったのか…。
0922774NGNG
久しぶりに来たらなんか盛り上がってるなあ。
ひょっとして俺のせいですか？
0923デフォルトの名無しさんNGNG
C++はムズイの〜
0924デフォルトの名無しさんNGNG
NULL4文字程度で読みづらいとか言ってたら

何にも出来やしないクソプログラマーという名を頂戴する羽目になるので

恥ずかしくて俺は言えない
0925煽り厨房NGNG
>>918
え、知らなかったの... てっきりクロスプラットフォームを
意識した話か何かと思っていたんだけど...
PSDKのWindows Daya Types見ればDWORDやBYTEに並んでUINT64とかPOINTER_64とかあるよ。
Microsoft C++拡張の方では__int8, __int16, __int32, __int64もあるし
0926デフォルトの名無しさんNGNG
何故Ｃ＋＋をそんなに難しく考えるのか？
0927918NGNG
>>919,925
無知ゆえ恥ずかしながら時代遅れなコトをしていました。
ISO等を見て古いヘッダ類はそろそろ捨てなきゃいけない…。

>uint32_t じゃダメですか？
ご指摘ありがとうございます。そちらにあわせようと思います。
それにしても…定義多いですね。int_fast32_t なんてのも…。
さしあたって処理系が stdint.h を持っていたらそれを使って
なかったら、自前のやつ…。

>てっきりクロスプラットフォームを意識した話か何かと思っていたんだけど...
クロスプラットフォームは意識しています。unix,win,MacOSを対象にした
コードは書いてます。
VC++ですでにUINTがあったのに、再定義しちゃったのは
かなり恥ずかしい(^^;
0928デフォルトの名無しさんNGNG
>>927
とはいえ C99 に準拠した処理系はまだ出回っていないので、当面は自前で typedef する
ことになるかと。(UNIX 系なら autoconf 使うと楽だが)
0929デフォルトの名無しさんNGNG
age
0930デフォルトの名無しさんNGNG
めざせ1000
0931どうでもいいがNGNG
>>oll
引数多すぎ
0932デフォルトの名無しさんNGNG
sage
0933デフォルトの名無しさんNGNG
>>1
本読め。理解できなければ理解するために努力しろ。
それでもダメなら道を変えろ。
スレで愚痴るなんて最低だぞ！！
0934デフォルトの名無しさんNGNG
あげ
0935デフォルトの名無しさんNGNG
age
0936デフォルトの名無しさんNGNG
age
0937デフォルトの名無しさんNGNG
age
0938デフォルトの名無しさんNGNG
sage
0939デフォルトの名無しさんNGNG
魔サ家スレかよ!!
0940デフォルトの名無しさんNGNG
ageてみよ
0941デフォルトの名無しさんNGNG
C言語は仕様が小さい
ストラウス〜の考え方はマイクロソフトに似てて、肥大になってる。
マイクロソフトの考え方とは、ユーザが欲しいというものは腕力で実装。
うまく使うには取捨選択が必要。
0942デフォルトの名無しさんNGNG
ageてみよ
0943(･∀･)ｲｲ! ◆.jyQEJC. NGNG
(･∀･)ｺｺﾀﾞﾖ!
0944(･∀･)ｲｲ! ◆.jyQEJC. NGNG
(･∀･)ﾏｯﾃﾙﾖ!
0945 ◆PZkIiX/M NGNG
めっけ。
0946 ◆PZkIiX/M NGNG
そ の深いところに隠れてみる。
0947 ◆PZkIiX/M NGNG
微妙な間に注意。私は怪獣使いの住処に潜む。
0948 ◆PZkIiX/M NGNG
作る人がいる。使う人がいる。私は使う人といる。
そ れは作られたもの。使われるもの。
0949デフォルトの名無しさんNGNG
ageてみよう。
0950デフォルトの名無しさんNGNG
マ板からきたな。
本当にやってるのか・・・かくれんぼ。
0951デフォルトの名無しさんNGNG
ha?
0952初心者NGNG
http://www.bloodshed.net/images/devcpp_scr.jpg
これってＣ++を勉強するのに使る？
フリーソフトなんですけど
0953>952NGNG
貧乏人のVisualStudioって感じだな
デバッガもついてなさそうだし
金出せるんならVisualStudio買っとけ
0954デフォルトの名無しさんNGNG
スクロールバーが動かないぞ。ばったもんか？
0955デフォルトの名無しさんNGNG
>>951
マ板の厨房が、2Ch内でかくれんぼしてます。
0956デフォルトの名無しさんNGNG
C++は一週間でマスターしたよ。
実は、その前にJAVAをマスターしてたからなんだけどね。
JAVAマスターするのには6ヶ月以上かかったかも。
すでにCは習得してたんだけどね。
その原因はやっぱりOOにあったよ。
もちろんJAVA初めて3日で動くコードはかけてたけど、
あれはJAVAとは程遠かった・・・
インターフェースも抽象クラスも意味がよくわかってなかったからな・・・
0957デフォルトの名無しさんNGNG
いくらなんでも一週間で「マスター」は有り得ないんじゃねーのか
と言ってみるテスト
0958デフォルトの名無しさんNGNG
＞C++は一週間でマスターしたよ
マスターしてない事の証明。
ということにしたい。
0959デフォルトの名無しさんNGNG
マスターとか習得とかって、
何を基準に判断するんだろうね。
資格試験でもあるのかしら？
0960仕様書無しさんNGNG
デザインパターンすべてをC++で具現化したらマスターしたことにしてやるよ。
0961デフォルトの名無しさんNGNG
C++マスターしたっていうのは、
C++に用意された全機能について、解説できるって意味ね。
Cでmalloc,freeが使えて、関数ポインタがわかってて、
JAVAでOOできたら、
C++で新しい事といえば・・・・・
多重継承で起こる不都合だけど、多重継承しないしな。
ヘッダファイルがうざいのと、constがうるさいのと、
あと、コンパイラのエラーがアホなのと、
コンパイルにやけに時間がかかる事かな。
でも、いまだによくわからないのが、
typeidと例外処理
typeidのどこがわからないかの説明はめんどうだから
func(&typeid(class))って使い方でいいのかな？
あと、例外処理では
オブジェクトをthrowしたいんだけど
throw new Exception
で、
catch(*Exception)
みたいにポインタでいいんか？
0962デフォルトの名無しさんNGNG
あ､上のは動くか動かないかじゃなくて
一般的にはどうなのか？って事が知りたいので・・・

デザパタ全部ってさ、
使わないの覚えても仕方ないんじゃない？
仕様さえわかれば、普通は何でもコーディングできると思うけど。
所詮ポインタを使ったデータ構造。
デザパタってそれ以上でもそれ以下でもない。
0963デフォルトの名無しさんNGNG
Ｃ＋＋は任せとけ、ってやつで、肝心なところでコピーコンストラクタ書いてないやつがいたなぁ。
あななつかしや。
0964デフォルトの名無しさんNGNG
>>461
throw new Exception
を
catch(*Exception)
する。
いいよ。
Obj obj;
...
throw obj
なら、
catch(Obj eobj)
だけど。
0965デフォルトの名無しさんNGNG
C++は任せとけって奴で、引数が12個ある関数を兵器で書く馬鹿
がいるなあ、うちに。頃してやりたい。
0966デフォルトの名無しさんNGNG
>>964
あと、>>962
だと、catch()内で、
delete Exception;
せにゃだめだな。
それから、
catch (*Exception)
でなくて、
catch(Exception* pE)
{
...
delete pE;
}
だった。
0967デフォルトの名無しさんNGNG
>>965
Win32 APIのCreateFont()の引数の数は？
0968デフォルトの名無しさんNGNG
明らかに >>961 は C++ の極一部しか理解してないと思われ．
0969デフォルトの名無しさんNGNG
>>963
きっと、その人は速度重視で、関数でのオブジェクト
受け取りをポインタか、参照渡ししかさせまいとおもったんじゃない？
って冗談だけどな。
0970デフォルトの名無しさんNGNG
>>961
> C++で新しい事といえば・・・・・
テンプレートという言葉が何故出て来ないのだろう

と言ってみるテスト
0971デフォルトの名無しさんNGNG
とりあえず >>961=>>956 は
Effective C++
More Effective C++
Exceptional C++
は最低でも読んでおくよーに．
自分の身の程を知っておく必要があるかと．
0972デフォルトの名無しさんNGNG
この板で「マスター」は禁句だよ
厨房がﾜﾗﾜﾗとよってくるから
0973デフォルトの名無しさんNGNG
このスレ、Rev.2 つくるのかいな？
それとも、今年でお終いか？
0974デフォルトの名無しさんNGNG
出来上がった概念を理解するのはやさしい。
むしろ概念というものを説明するのが難しいから、
下手な説明を聞いて教えられた方が悩んでしまう。
そんなもんだ。
0975デフォルトの名無しさんNGNG
ふれんどりぃくらす...とか言っちゃ駄目？
0976デフォルトの名無しさんNGNG
勃起がおさまらねーなー
0977デフォルトの名無しさんNGNG
>>973
今年でおしまい。ということにしたい。
0978デフォルトの名無しさんNGNG
>>971
template 関連で Effective STL, Moden C++ Design, Generic Programming and the STL も追加しとこう。
0979デフォルトの名無しさんNGNG
そろそろまとめに入らないと・・・
0980　　　　NGNG

ＯＯ逝って良し。

＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊
0981デフォルトの名無しさんNGNG
もうちょいよ。
0982まとめNGNG
「難しく作ったから」

これでいいって．
0983デフォルトの名無しさんNGNG
C＋＋氏ね！！
0984デフォルトの名無しさんNGNG
C++、使いこなすは一生ものだと思う今日この頃
0985 NGNG
C++ってそんなに難しいか？
厨な漏れでも林ハルヒコの本で
即効マスターしたぞ。みんな馬鹿？
0986デフォルトの名無しさんNGNG
マスターとかいうなよ・・・
0987デフォルトの名無しさんNGNG
前から疑問に思っていたが継承で生成されたオブジェクトはサイズが
でかくなるんだろうか。
0988デフォルトの名無しさんNGNG
C++はｱﾌｫ、逝ってよし！！！
0989デフォルトの名無しさんNGNG
>>987
メンバ変数は、基底クラスと派生クラスの分を両方持つから、その分サイズが増える。

仮想関数がある場合には仮想関数テーブル (vtbl) へのポインタ (vptr) も持つことになるが、
単一継承なら vptr はインスタンス 1 つにつき 1 つにまとめ、多重継承の場合には、継承した
数だけ vptr を持つのが一般的。多重継承すると、それだけサイズは増える。

実際のコンパイラで sizeof() を使って調べてみるのが良いと思うぞ。
0990デフォルトの名無しさんNGNG
>>987
でかくなる場合もあるし、小さくなる場合もある。
0991デフォルトの名無しさんNGNG
どっちよ？
0992デフォルトの名無しさんNGNG
じゃ、メンバ関数継承するとやっぱサイズ増えるんだな。
0993デフォルトの名無しさんNGNG
993にて結論：Rubyを使え。
0994デフォルトの名無しさんNGNG
一生
Rubyだけ
つかってろ
0995デフォルトの名無しさんNGNG
そんなもん動かねーよ。
PCで使うんじゃねーんだボケ。
0996デフォルトの名無しさんNGNG
1000に驚くべき結論が提示されるらしい。
0997デフォルトの名無しさんNGNG
1000の奴は責任重大
0998996NGNG
ごめんうそ。
0999996NGNG
998は偽物age
1000996NGNG
1000get!
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。