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

【肥大化】C++ を見捨 ..

116:デフォルトの名無しさん
08/02/03 23:10:50
お前らみたいなカスにC++は無理。Rubyでもやってろ。

117:デフォルトの名無しさん
08/02/03 23:12:41
>>116=>>50 だろ。C++で優越感に浸ってるのって・・・

118:デフォルトの名無しさん
08/02/03 23:29:32
C++に挑戦しようという気になってきました。なにから始めたらいいでしょうか？

119:デフォルトの名無しさん
08/02/04 00:19:39
C

120:デフォルトの名無しさん
08/02/04 01:00:59
GUI周りが面白いかもね。すぐに効果がわかって。

121:デフォルトの名無しさん
08/02/04 01:33:17
>>120
オブジェクトが形として見えるから良いとは思うけど、
問題はどのライブラリを使うかだよね。

MFCはフリーじゃないしmain隠蔽とかメッセージマップとか独自過ぎ、
wxもメッセージマップだし、Qtはmocとかいう独自プリプロセッサだし、
FOXやFLTKはまともに日本語が使えないし、
Windows Formsは悪くないけどC++/CLIは独自拡張で論外だし、
初心者に優しいライブラリがまったくない。

122:デフォルトの名無しさん
08/02/04 02:07:34
C++の勉強のためのGUIならWin32かな

123:デフォルトの名無しさん
08/02/04 02:23:35
変なラッパーやライブラリより直叩きの方が素直だとは思うけど、
C++というよりC言語の勉強になるような希ガス。

124:デフォルトの名無しさん
08/02/04 08:55:51
Win32ってライブラリがあるんですか？

125:デフォルトの名無しさん
08/02/04 09:25:50
>>121
一応、gtkmmというのもあるけど。

GUIやるならJavaがいいよ。どこでも動くしさ。

126:デフォルトの名無しさん
08/02/04 11:41:28
>>124
ライブラリっていうかWindowsに最初から付いているAPI。
C言語の関数の塊なんで、C++のクラスとかは使っていない。
この辺を見て地道に勉強するしかない。
URLﾘﾝｸ(www.kumei.ne.jp)

はっきり言って初心者向けではないし面白くもないと思う。
最初は意味不明でひたすら写経になる。
理解しようとしても徒労だと思うのでパターンに慣れるしかない。
半年くらいひたすらやっているとパターンがつかめてくる。
仕事で強制でもされなければ大抵は挫折するんだけどさ。。。

まあ、要するにC/C++でGUIは初心者には鬼門だってこと。
GUIでオブジェクト指向を勉強するならC#かJavaの方が良い。

127:デフォルトの名無しさん
08/02/05 10:21:29
GLSってなに？ググってもプログラムと無関係ぽいのばかりでてくるんだけど

128:デフォルトの名無しさん
08/02/05 10:45:15
>>127
オリジナルの Java の仕様策定者の一人だよ。C++ はストラウストラップが
有名だけど、Java はゴスリング、ジョイ、スティール (GLS) の三人で最初の
仕様を作ったんだ。

GLS は ECMAScript, Scheme, Common Lisp, C, Java, Fortran などの
仕様決定にも関わっていて、プログラミング言語の権威中の権威であり、
コンピュータサイエンス界の大巨人。ストラウストラップみたいな素人上がり
とはバックグラウンドが違う。

まあ単に Java を書けるだけのプログラマなら GLS を知らないかもしれんけど、
もう少し上のレベルの人間には常識。

129:デフォルトの名無しさん
08/02/05 12:01:26
>>94 が如何に滑稽なレスだったか理解してもらえたかな?
知識が無いのは仕方が無いが、自分の身の丈を知らないのは恥ずかしいぞ。

130:デフォルトの名無しさん
08/02/05 21:48:11
129の釣られすぎにﾜﾛﾀ

131:デフォルトの名無しさん
08/02/05 22:32:05
127=128にﾌｲﾀ

132:デフォルトの名無しさん
08/02/05 22:38:00
windowsのアプリ作りたいんだが、独自拡張が少ないのはどれか教えてくれエロい人
ちょっと見た感じC++Builderかな？

133:デフォルトの名無しさん
08/02/05 22:49:20
>>130=131
負け惜しみのレスは心の中にしまっておくのが大人の態度だよ

134:デフォルトの名無しさん
08/02/06 04:24:52
なにここ・・粘着キモスレだな

135:デフォルトの名無しさん
08/02/06 09:03:59
スレタイ見れば分かるだろw

136:デフォルトの名無しさん
08/02/06 09:10:20
>>128
ごくろーさん、がんばったね。偉い人の名前いっぱい知ってるんだ。
レポートでいい点取れるといいね。ﾌﾟ

137:デフォルトの名無しさん
08/02/06 09:11:37
>>132
C++ Builderはプロパティとかコールバックとか独自拡張しまくり。
おまけに__fastcallを押し付けられるし。
素直にWin32APIを直叩きすれ。

138:デフォルトの名無しさん
08/02/06 09:30:43
ま、開発スピードではC++ Builder最強。
クロスプラットフォームじゃwx-devcpp最強じゃね？

139:デフォルトの名無しさん
08/02/06 20:38:02
Builderはやめとけ
独自拡張だらけ、バグだらけ、コンパイラはカス
ろくに使ってない俺ですら、ダメだしせずにはいられないぐらいひどい代物だ

140:デフォルトの名無しさん
08/02/06 20:38:32
おまけに参考文献ろくにないし

141:132
08/02/06 22:05:45
そうですか。
やっぱりVC++が無難かな。
JAVAに慣れてしまったおれにはイベントハンドラとかメッセージとか何言ってんのかさっぱり分らないんだがしょうがないな。
それかDLLだけ作ってC#にするか。

アドバイスくれたみなさんありがとう。

142:デフォルトの名無しさん
08/02/06 23:48:21
>>136
そんなに僻む時間があるならもっと勉強した方が良いと思うよ
前向きに

143:デフォルトの名無しさん
08/02/07 08:38:20
＞ろくに使ってない俺ですら、
＞ダメだしせずにはいられないぐらいひどい代物だ

矛盾。

VC++/MFCを一回使ってみ？
これって何言語っていうくらいヘンテコですぐに投げ出すこと請け合い。

144:デフォルトの名無しさん
08/02/07 22:35:11
ろくに使ってない俺ですら、
コンパイラのだめさ加減（普通なら通る構文が通らない等）や、
IDEのバグを沢山知ってしまってるって話だよ

使い込んだら、一生根に持ちそうだ

145:デフォルトの名無しさん
08/02/08 08:42:17
本当にその通りだねｗｗｗ

VC6 と VC7 の互換性
URLﾘﾝｸ(program.station.ez-net.jp)

□ COM 動かず…
さて、エラーも取り除けたということで動作させてみたのですけど、CreateObject をして、そのあとでメソッドを呼び出してみると…、DLL の読み込みでエラーが発生してしまいました。

どうやらうまく移行できなかったようです。

146:デフォルトの名無しさん
08/02/08 08:49:34
VC++のダメさ加減というのは、COMや、最近ではドトネトを混ぜないと開発できないところ。
C++のソースの中でのCOMの複雑怪奇かつ素直にクラス派生できないわずらわしさは最強。

VC++を捨てればスッキリ。

147:デフォルトの名無しさん
08/02/08 09:10:11
VC++ ← ネイティブとCOMとドトネトの三つ巴でC++を複雑怪奇にしたA級戦犯

148:デフォルトの名無しさん
08/02/08 19:37:55
過渡期ですからしょうがないっすよ・・・

149:デフォルトの名無しさん
08/02/13 02:27:47
つーか全然.netの仕事来ないんだが、、、
.netを使わないでくれってのばっか

150:デフォルトの名無しさん
08/02/13 05:44:13
そりゃお宅が使えばクソ重くなるからな

151:デフォルトの名無しさん
08/02/14 02:37:23
結局のところ、世の中に完璧なものはなく
自分に合うかどうか

152:デフォルトの名無しさん
08/02/16 02:14:03
try{...} catch{...} finally{...} 排除スレ
ｽﾚﾘﾝｸ(tech板)

1 名前: デフォルトの名無しさん Mail: 投稿日: 2008/02/15(金) 14:15:49
重いんじゃボケ

153:デフォルトの名無しさん
08/02/16 13:53:04
>>146
COMはC++から使うもんではないですぜ。
スクリプト言語やVBAからつまむもの。
そうも言っていられないのが現実だけど。

154:デフォルトの名無しさん
08/03/10 00:57:23
まあ、オブジェクト指向が理解できない内は、「Windowsのプログラムは複雑でわかんね」になるねぇ

155:デフォルトの名無しさん
08/03/10 01:01:09
オブジェクト指向ってそんなに難しいのか?
俺はオブジェクト指向言語から入ったから、難しいというのが理解出来ん。

156:デフォルトの名無しさん
08/03/10 09:19:33
プログラミングってのは、言葉。一番はじめにおぼえた言葉を簡単に感じるもの。
次に覚える言葉は外国語。

157:デフォルトの名無しさん
08/03/10 12:02:46
>>155
オブジェクト指向なんて気取った言い方を止めない限り
理解しやすくはならないんじゃないかな?

「型定義指向」みたいな言い方の方が理解しやすいと思うんだけどねぇ

158:デフォルトの名無しさん
08/03/10 12:17:56
＞「型定義指向」

これだと分かんないじゃん。

クラス宣言指向のんが良いんじゃない？

159:デフォルトの名無しさん
08/03/10 12:24:42
>>158
それだとクラスって何って話になるじゃん
クラスは、型の動作定義にしか過ぎないわけだし、クラス宣言指向では意味がわからん

160:デフォルトの名無しさん
08/03/10 13:00:06
そもそもオブジェクトとは何かを理解するのが重要なのに、
オブジェクトって言葉が消えるのは具合が悪い。

161:デフォルトの名無しさん
08/03/10 13:06:36
それは認識間違いです。

完全なオブジェクト指向じゃないのがクラスベース言語。
オブジェクト指向を想定してクラスベース言語を理解しようとするから難関。
素直にクラスの文法を学べば良い。

そうじゃなくて完全なオブジェクト指向を目指すなら、オブジェクトベース言語に逝こう。

162:デフォルトの名無しさん
08/03/10 13:59:17
オブジェクトが何かというのが大切であるなら、英語のオブジェクトをオブジェクトのまま扱っている方が問題
だから、"物"なんていう直訳の極みを説明に出してしまう事になる
オブジェクト指向のオブジェクトは、"物"ではなく"鋳像"と訳すべきであり
概念としては、"鋳像と、その鋳型の関係を考える"ことがオブジェクト指向だろう

163:デフォルトの名無しさん
08/03/10 14:06:40
＞オブジェクト指向のオブジェクトは、"物"ではなく"鋳像"と訳すべきであり

それは違う。

鋳像となってるのはクラスベースＯＯＰの話。

ミスリード激し杉。

164:デフォルトの名無しさん
08/03/10 14:11:26
つかRubyあればあとはイラネ

165:デフォルトの名無しさん
08/03/10 14:24:33
>>163がオブジェクトの説明を素人にも判りやすく説明してくれるというので期待上げ！！！

166:デフォルトの名無しさん
08/03/10 17:25:09
>>163
オブジェクト指向の判りやすい説明はどうしたの
早く教えてくれよ

167:デフォルトの名無しさん
08/03/10 17:28:54
　　 ∩＿＿＿∩
　　 | ノ　　　　　ヽ
　　/　　●　　　● |
　 |　　　　( _●_)　ミ
　彡､　　　|∪|　　､｀＼
/　＿＿　ヽノ　/´>　 )
(＿＿＿）f^f^f^f^f^f^f^f^f^┐
　|　　　　|~ ~ ~ ~ ~ ~ ~ ~ ~ │
　|　　　　|　知ってるが　 │
　|　　／ |　お前の熊度が |
　|　/　　|　　気にクマない |
　∪　　 |______＿＿＿＿＿|
　　　　　　　＼＿)

168:デフォルトの名無しさん
08/03/10 17:33:57
>>167
お前には失望した
嘘吐き小僧の名を進呈しよう

169:デフォルトの名無しさん
08/03/10 19:08:49
URLﾘﾝｸ(codezine.jp)

このようなクラス-インスタンスという概念を使用するオブジェクト指向言語のことを、クラスベースオブジェクト指向言語（Class Based Object Oriented Language）と言います。

　それとは異なり、JavaScriptではクラス-インスタンスという考え方をしません。
オブジェクトは別なオブジェクトを元（プロトタイプ）にして独自の特徴を付加することで存在する、という考え方をします。
このようなオブジェクト指向言語のことを、プロトタイプベースオブジェクト指向言語（Prototype Based Object Oriented Language）と言います。

170:デフォルトの名無しさん
08/03/10 21:42:34
>>169
その説明だと、クラスとプロトタイプの違いがさっぱりわからん
もっと優しく説明してくれないか

171:デフォルトの名無しさん
08/03/10 22:19:55
クラスベースはプラモデル
プロトタイプベースはレゴ
ってかんじかね。

172:デフォルトの名無しさん
08/03/10 22:36:34
>>171
その説明だと、>>163の>>162に対するミスリード発言が深い謎になるのだが?

173:デフォルトの名無しさん
08/03/10 23:10:42
プロトタイプベースは鋳像とその鋳型（＝クラス）の関係じゃないことは確か。

174:デフォルトの名無しさん
08/03/11 00:02:58
>>173
実行中に形が変わるから、違うものだと言うのか?
クラスが作れるからオブジェクト指向ではないし、プロトタイプが作れるからオブジェクト指向でもない

鋳像(実像)と鋳型(モデル)の関係があって初めてオブジェクト指向が成立するものだと思うが
同じ物を同じ物として作ることが出来、なおかつ、作り出された一つ一つは個性を失わない
それが出来て初めてオブジェクト指向と言えると思うけどな

175:デフォルトの名無しさん
08/03/11 00:23:14
その昔、Java で interface を知った瞬間にすべてが分かった。
実装方向からの理解だと、シグニチャからのメソッドの検索ね。
同一型のデータの集合をクラスと捉えるよりも、メソッド集合を
クラス、あるいはプロトタイプと捉えた方が理解が簡単かな…

データなんて飾りですってことで。

176:デフォルトの名無しさん
08/03/11 01:02:51
>>172
オブジェクト指向の歴史はしらんが、現在ではある概念の一つでありプログラミングのみで登場する概念ではない。
オブジェクト指向プログラミングとは、一種のプログラム設計の方針であり、クラスの有無とは本質的には無関係である。
しかしながら、現実的にはC++などはクラスを使用することでオブジェクト指向に基づくであろう設計方針を取れる。

オブジェクト指向とは、
１、オブジェクトという単位を基準に考えること。（オブジェクトは部品、と訳すと割といい。）
２、オブジェクトはオブジェクトとやり取りに注目していること。（メンバ関数/イベント等をインスタンスへの命令と考える。）
３、オブジェクトはオブジェクト以上にはなりえないこと。（カプセル化に関連。オブジェクトとして考えていたものがオブジェクトとして認識できなくなる操作はNGという事）
４、オブジェクトはどのオブジェクトとどのような関係があるか、わかること。（has-a、is-aがしっかりとわかること。継承や集約といった関連がどうなっているかわかること）

括弧内はプログラミングから見た場合。
こんなかなぁ･･･怪しいものだ。

177:デフォルトの名無しさん
08/03/11 01:50:32
>>176
それは、"鋳像と、その鋳型の関係を考える"事じゃないのか?

178:デフォルトの名無しさん
08/03/11 03:16:10
>>177
括弧内じゃないほうは鋳像（･･･このスレではじめてみたが）と鋳型という考えは出てないと思うけど。
あとオブジェクト指向の指向は考える、とか定める、とか基準にする、とかに準拠する、という意味合いが強い気がするから、
"～を考える"ことは割りと定義としてはあってると思うんだが

179:デフォルトの名無しさん
08/03/11 09:08:51
>鋳像(実像)と鋳型(モデル)の関係があって初めてオブジェクト指向が成立するものだと思うが

これはまさにクラスだけど、現実世界ってそうじゃないんだおね。

ニューアカの粘菌の説明なんかであったが、
粘菌とはこういうものだと定義しようとするが、
粘菌は場所が変わると色んな風に変化してて、
そのカテゴリーから外れる、みたいな。

動植物の定義でも外れるもの出てくるし、哺乳類の定義でもそう。
結局クラスってのは現実世界とあってない。

180:デフォルトの名無しさん
08/03/11 10:13:25
>>178
馬車の鋳像を作ると仮定して
その鋳像は、馬も車輪も御者も全て一緒に作るのか
馬車であることに拘り、本体、車輪、馬、御者をバラバラに作り後から組み立てるのか
それとも、馬や御者は陶器で作成して、馬車のみを精密に鋳像にするのか(屋根を開くようにして中に乗客を乗せることが出来るようにするとか)
>>176の言ってることってこう言うことだよね?
でも、これは、馬車の鋳像の事を考えているように見えて、馬車の鋳像の鋳型の事を考えているよね

でもって、作り出された鋳像の話にすると
車体と車輪を分けて鋳造された場合、きちんと組み立てて馬車の鋳像あるだろうが
中には、一つの車輪をわざと外し、壊れた馬車の鋳像にしている場合も有るだろう

これは、鋳型(クラス、プロトタイプ)から作られた、鋳像(インスタンス)は、鋳型と同じ姿(機能)を有しているが
鋳像同士の使われかたは、別々だと言うこと

これらが意識できない限り、クラスやプロトタイプは変な使われかたをして、作った奴死ねってなるだけの話さ

181:デフォルトの名無しさん
08/03/11 10:19:43
そうだね、車輪だと分かり難いけど、鋳造から作った部品を変形させて別物にしたりするよね現実では。

182:デフォルトの名無しさん
08/03/11 10:34:01
>>179
それは、クラスとインスタンスの関係を理解していないだけ

183:デフォルトの名無しさん
08/03/11 10:38:14
>>182
そうじゃない。
クラスでは現実世界を記述するには役不足。

184:デフォルトの名無しさん
08/03/11 10:48:48
>>183
三毛猫は、猫だが、黒猫ではない、だから猫は猫を表現するには役不足だ

と言われて、どう思うよ

185:デフォルトの名無しさん
08/03/11 10:56:23
>>180
なんだろ・・・すごい話がかみ合ってない希ガス。

オブジェクト指向はUMLが最もそれらしく体現してるかな。
鋳型を考える手前までの作業がオブジェクト指向。
そこからクラス＝(鋳型)を作る行為はオブジェクト指向とは無関係だと思う。
というか鋳型という表現が良くない。鋳型ではなくカテゴリーとかそこら辺がそれっぽい。
カテゴリーならオブジェクト指向の範疇。

>>180の例でもそうなんだが、それは鋳型（オブジェクトの設計図）を考えること直結してるとは思えない。
少なくともそんなことをオブジェクト指向を何も知らない人はそんなことは思わない。
そして、その例は間違いなくオブジェクト指向してる様に見えるんだが、その例はオブジェクト指向じゃないの？

あと後半の説明は明らかに誤解を招く。どう考えてもインスタンスとクラスは同じ姿（機能）をしてないだろうと。

186:デフォルトの名無しさん
08/03/11 10:57:48
だめだ、日本語がわけわかめになってるな。そんなことが同じ文の中に2回登場してるorz

187:デフォルトの名無しさん
08/03/11 10:59:41
>>184
現実にはイノシシからブタが発生したりするわけ。
実行時にクラスが増えていくって感じ？
さらにもっと良く見ると、１つ１つのクラス違ってるじゃん、みたいな。

純粋にオブジェクト指向で現実を記述するってのと、
簡単な業務アプリのスタティックなクラスは、
無限の隔たりがあるの。

188:デフォルトの名無しさん
08/03/11 11:01:03
＞現実にはイノシシからブタが発生したりするわけ。
＞実行時にクラスが増えていくって感じ？

もう少し説明すると、記述して計画的にクラスが分岐するんじゃなくて、
実行した結果分岐しちゃった、みたいな。
だから、スタティックなクラスじゃ書けない。

189:デフォルトの名無しさん
08/03/11 11:04:45
＞実行時にクラスが増えていくって感じ？

例えばキケイで足が１本少ないってなったとき、
じゃ、足の本数をメンバ変数にすれば良いじゃん、
って単純な話じゃない。

原生生物に突起が出来て、あるとき足と呼ばれるようになった、みたいな。

190:デフォルトの名無しさん
08/03/11 11:11:15
>>188
別に現実世界とオブジェクト指向の隔たりを否定しているレスは無いだろうと常考
>>189
オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう

191:デフォルトの名無しさん
08/03/11 11:12:39
＞オブジェクト指向プログラミングは現実世界を投影するのが目的じゃないだろう

おまいＯＯわかって無いだろう、ｊｋ

192:デフォルトの名無しさん
08/03/11 11:15:44
>>191
言い方が悪かった
オブジェクト指向プログラミングは現実世界を投影するのが『最終』目的ではないだろう

193:デフォルトの名無しさん
08/03/11 11:18:39
身近から言うと業務アプリは業務を投影するし、
極端なことを言うと地球シミュレーターは地球を投影する。
人工知能で顔を判別するには顔を投影する。

で？

194:デフォルトの名無しさん
08/03/11 11:21:45
>>193
やっぱりそういう勘違いをしてるのか･･･

195:デフォルトの名無しさん
08/03/11 11:21:48
俺は、>>191が判ってないのに1票
>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

クラスから発生したインスタンスは、クラスにはならない
プロトタイプから発生したインスタンスは、プロトタイプになる
そう言いたいので有れば、説明のしかたがおかしい
さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから、口を開くな禿

196:デフォルトの名無しさん
08/03/11 11:24:39
>>194
投影、を勘違いと思うなら、OOを勘違いだといってるのと同じ。
この議論の外の話。

197:デフォルトの名無しさん
08/03/11 11:25:23
＞さらに言うなら、それはオブジェクト指向の話でもなんでも無く、コンパイラとインタプリタの話であり、ややこしくなるだけだから

強烈に頭が悪い悪寒。

198:デフォルトの名無しさん
08/03/11 11:26:31
どっちにしろ、ＯＯってのは現実世界の投影。

それを否定する人は、別の議論に入って良いけど、この議論には入るな！

199:デフォルトの名無しさん
08/03/11 11:30:00
＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

これ、強烈に頭割る杉。

200:デフォルトの名無しさん
08/03/11 11:31:59
>>196
>>193の例で言えば業務アプリのプログラムを組もうとすることはoopと無関係である。
別にoopでなくとも可能かも知れないし、oopの場合現実世界を必ず投影しなければいけないわけではない。

oopは安全性の向上、再利用性の向上、が目的だろ。
現実世界を投影することとoopで使うことを前提としたクラスライブラリを作ることが同じと申すか。

>>195
185だが、自分で言うのもなんだが確かに不毛。

201:デフォルトの名無しさん
08/03/11 11:32:55
＞>>180と>>185は、言葉の違いを言い争ってるのに1票(パンクとメタルの違いみたいなぁ)

こいつが頭悪いと言い切れるのは、
学問的にも、クラスベースＯＯとオブジェクトベースＯＯは別物となってて、
既にクラスを推奨しているboochは異端だとか電波だとか言われている。

クラスベースにしがみつく＝キティ

202:デフォルトの名無しさん
08/03/11 11:34:28
＞oopは安全性の向上、再利用性の向上、が目的だろ。

これは間違い。
手続きプログラミングに対してクラスベースの効果として、安全性、再利用性は言われるもの。

しかし、前述のとおり、ＯＯとしてはクラスベースは異端。

203:デフォルトの名無しさん
08/03/11 11:40:19
>>201
初めて知ったわ。なんかそれぞれの学術書でもあるん？

204:デフォルトの名無しさん
08/03/11 11:43:09
何を分かった風な。

205:デフォルトの名無しさん
08/03/11 11:46:24
>>202
え、oopの目的って（Cににた言語なら）生産性、安全性、再利用性の向上だと思ってたけど。
何が目的なの？･･･というかそもそも設計方針だからルールはあっても目的とか無いのか･･･。

206:デフォルトの名無しさん
08/03/11 11:49:02
一人、強烈にオブジェクト指向を理解してないやつが居ることだけは確実だって事だな
しかも、人の説明は違うと言いつつ、自分では何の説明もしないあたり、相当な...

207:デフォルトの名無しさん
08/03/11 12:21:05
ＯＯの本流に一番近いのはＲｕｂｙかな

208:デフォルトの名無しさん
08/03/11 12:25:33
一つの言語でまかなえれば、それは楽で良いだろうが
目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな

209:デフォルトの名無しさん
08/03/11 12:27:26
＞目的に応じて使用する言語を選べる方が、よりオブジェクト指向だと言えるな

おまいのいうオブジェクト指向ってのは、開発のノリのこと？
いわゆる何に対しても、”ロック”、の一言で終わらせるあれ？

210:デフォルトの名無しさん
08/03/11 12:30:25
>>209
馬鹿は黙ってろ

211:デフォルトの名無しさん
08/03/11 12:31:47
＞馬鹿は黙ってろ

やっぱ脳みそツルツルの体育会系じゃねーか。
おま、マに向いてないお。

212:デフォルトの名無しさん
08/03/11 12:36:40
>>211
プロトタイプとインスタンスの関係も理解できてないのに大きな口を叩くな
理解できてるなら、説明して見ろ
話はそこからだ

213:デフォルトの名無しさん
08/03/11 14:35:57
オブジェクト指向は現実世界の投影じゃないよ。
言うなればドメイン(問題領域)の投影だよ。
物理学者ならアレだけど。

プロトタイプは原型だよね(英単語的な意味で)
クラスは変な表現になるけど、興味の対象だよ。
インスタンスとプロトタイプは似てたりもするけどね。

ところで、ここ何のスレ？

214:デフォルトの名無しさん
08/03/11 14:37:31
ドメイン(問題領域)の投影
の一例として
現実世界の投影だろ？

213=ヴぁか？

215:デフォルトの名無しさん
08/03/11 14:41:16
>>214
だから馬鹿は黙ってろ
話題に混じりたいなら、プロトタイプとインスタンスの関係を説明してから混じれ

216:デフォルトの名無しさん
08/03/11 14:57:07
a)オブジェクト指向は現実世界の投影じゃないよ。
b)ドメイン(問題領域)の投影だよ。
c)物理学者ならアレだけど。

aとbを比べたらbの方が巨大。
bはaを含む。
だから、aの「じゃないよ。」は成り立たない。

さらにcで「ならアレだけど」と例外的に書いているのはさらに変。
物理学者だからこそ現実世界以外の問題領域が必要になるわけで、
物理学者じゃないならaで十分ｗ

217:デフォルトの名無しさん
08/03/11 14:58:40
>>214
一例になるから213は物理学者ならって書いてるんじゃね？

218:213
08/03/11 15:03:49
>>216
オブジェクト指向＝現実世界の投影じゃ～
って書いた方が良かったかな。

219:デフォルトの名無しさん
08/03/11 15:04:09
>>217
いや、
現実世界の投影　∈　ドメイン(問題領域)の投影
なの。

「現実世界の投影」の方が小さい。

220:デフォルトの名無しさん
08/03/11 15:05:07
＞ドメイン(問題領域)の投影

ってのは、現実にあるもの無いもの含んで超巨大。
これこそ物理学者にふさわしい。

221:デフォルトの名無しさん
08/03/11 15:08:35
>>219
プロトタイプとインスタンスの区別も付かない奴に何を言っても無駄

>>220
馬鹿は黙ってろ

222:デフォルトの名無しさん
08/03/11 15:15:05
>>219
だからそう言ってんじゃんｗ
どう読んでんだよｗ
213はイコールじゃないって言いたいんだろ

223:デフォルトの名無しさん
08/03/11 15:17:42
>>222
あ、自分の読み間違い？

良く分からないけど、ま、次の話題にすすみますか。

224:213
08/03/11 15:26:51
現実世界の投影はドメインの投影に含まれると思っています。
物理学者なら現実世界（シミュレーション的な意味で）をドメインとすることもあるかもね、
というつもりで書きました。
「アレ」では端折り過ぎでした。すみません。

まぁ、次の話題へどうぞ。

225:デフォルトの名無しさん
08/03/11 15:28:41
では、ＯＯとしてドメインの投影するには、どんな言語が良いのだ？

226:デフォルトの名無しさん
08/03/11 15:46:33
C++でイナフ

227:デフォルトの名無しさん
08/03/11 18:43:05
>>209あたりからのレスの進み方を見て、oopが分からない人が多い理由が分かった

228:デフォルトの名無しさん
08/03/11 22:44:48
別に分かっていなくても、奇抜なプログラムを書かず、
そのとき使っている環境で普通とされるコードを書ければそれでいい。

229:デフォルトの名無しさん
08/03/12 08:36:17
STL、boostが既に奇抜なプログラムな現実について。

230:デフォルトの名無しさん
08/03/12 08:51:12
C++ではSTLくらい普通の内です。

231:デフォルトの名無しさん
08/03/12 13:16:03
現状のSTLは欠陥品って報告が数多くでてるじゃん

232:デフォルトの名無しさん
08/03/12 13:43:10
ふーん、その欠陥品を模造したものがSTLドトネト→STL.CLIでつか。

233:デフォルトの名無しさん
08/03/12 15:21:31
見捨てた奴スレのレベルの低さから、何かが解るような気がする・・・

234:デフォルトの名無しさん
08/03/12 16:10:56
>>231
だからと言って標準ライブラリに代わりがあるわけではないし、
C++を使わない決定的な理由にならない。

235:デフォルトの名無しさん
08/03/12 19:43:05
URLﾘﾝｸ(www.nicovideo.jp)

C++のエラーは黒魔術

236:デフォルトの名無しさん
08/03/12 19:58:38
キャスト演算子のオーバーロードをしたいと言うとき、
C++の場合はポインタが足枷になる
大抵は派生クラスにして終わりなんだが、newできないクラスのラッパを作る時に不便だ
勿論getterも書くが…個人的にはgetterはあまり増やしたくないな

237:デフォルトの名無しさん
08/03/12 21:48:56
10年間変わっていない。
しかもあと10年は変わりそうにない言語を
肥大化というのもおかしくないか。

238:デフォルトの名無しさん
08/03/12 23:12:57
>>231
まだVC6使ってんのか？

239:デフォルトの名無しさん
08/03/13 00:44:51
かれこれ20年近くC++を使ってきたが・・・
まぁ、いろいろな意味と理由で負の遺産となりつつある。
場合によってはCOBOLより凶悪な事態を招きかねない、早いうちに廃棄処分方針をとった方が良いだろうとは思う、さすがに。
固執する人もいるが、そういった人には一度離れて別の言語を見て回ってみろと言いたい、
開発環境・コンパイラといった物から、言語使用その他あらゆる点で時代遅れになっているので……
唯一進んでいるのはboostとその周辺だろうが、これらがメインになるのは恐らく難しいだろう。

240:デフォルトの名無しさん
08/03/13 01:02:01
そもそも元になってるCに言語としての一貫性と言うか、仕様の一貫性が無いのが気に入らないんだ。
変数宣言は「型、名前」っていう順番で統一するべきだった。
ポインタを複数宣言する時は
char *a, *b, *c
ではなく
char* a, b, c
のほうが自然だし、そもそも char* を typedef していれば
pchar a, b, c
と書けるという事を考えると。

関数ポインタにしても
void (*hoge)(char*, char*)
ではなく、単に
(void (char*, char*)) *hoge
としてくれた方が素直だったのでは。

241:デフォルトの名無しさん
08/03/13 01:13:00
それもそうだが、まずtypedefの構文をもっとまともにすべきだったね。

242:デフォルトの名無しさん
08/03/13 01:15:23
問題はC++の次が何か？ってことで、Cの上位互換なら
Objective-Cという選択肢も一応あるんですがねえ…。

243:デフォルトの名無しさん
08/03/13 01:16:00
C言語から引き継がれた機能のうち最大の問題はプリプロセッサだと思うけどね。

>>241
typedef については、これ以上どうしろと・・・

244:デフォルトの名無しさん
08/03/13 01:22:27
関数ポインタのことじゃない？
typedef void(FUNCP*)(int);
これは最初戸惑った。
typedef void(*)(int) FUNCP;
せめてこうなるべきなんじゃないか？と。

245:デフォルトの名無しさん
08/03/13 01:25:07
>>244
それは、宣言の書き方であって typedef 関係ない

246:デフォルトの名無しさん
08/03/13 01:36:55
typedefが記憶クラス指定子ってところがおかしいだろ。

247:デフォルトの名無しさん
08/03/13 01:42:10
どこがよwwww
それでも問題ないし、そもそも記憶クラスじゃないし。

248:デフォルトの名無しさん
08/03/13 02:01:56
>>247
そう、記憶クラスじゃないのに記憶クラス指定子にされているのがなんか気になる。
普段は意識しないし、実用上困ったこともないけどさ。

249:デフォルトの名無しさん
08/03/13 10:56:42
>>240
そもそも char* 等は型ではない。
関数プロトタイプに char* と書くようになってから一貫性がなくなってきてるけどね。

>>247
typedef は Storage-Class Specifier ではない。

250:デフォルトの名無しさん
08/03/13 18:50:53
>>240
でもそれって配列と文法をあわせてるからでしょ。
むしろ他の言語で配列の初期化周りが統一感ない文法が多くて気持ち悪いが。

251:デフォルトの名無しさん
08/03/13 22:05:20
>>243
プリミティブ型からポインタ型や配列型を作れる言語では、
Cの構文以外で一貫性のある型表記を決めるとすると、
関数型言語みたいに「型から型を作る」という意識に立って
typedef &char charptr;
static (const int)*5 intarray;
(int, int) -> void func = { ... };
&((int, int) -> void) funcp;
のように表現せざるを得ない。
で、Cにはタプルもカリー化もないのだから、
わざわざ変数の使い方から乖離した型表記を作る必要はない。

252:デフォルトの名無しさん
08/03/14 10:03:01
>>251
関数型の世界しか頭になさそうなアホちんですね
組み込み等では大変役に立ったモンですよ

253:デフォルトの名無しさん
08/03/14 10:14:55
>>250
ｋｗｓｋ
>>251
レス番間違えてない？
>>252
よく読んでない悪寒

254:デフォルトの名無しさん
08/03/14 10:28:57
熟読した上で、まるで理解できず見当違いの煽りに走った、が正解。

255:デフォルトの名無しさん
08/03/14 12:10:49
>>253
いや、確かに前と後ろにつける違いがあるけど、どちらも変数につけるじゃん。宣言する時も使用するときも。
ポインタの文法は型にくっつけるべきだというなら、配列の宣言も[]は型にくっつけるべきだぜ。

256:デフォルトの名無しさん
08/03/14 16:58:18
入れ子状の宣言文上で複数の変数を宣言するから分りにくくなるだけで
とどのつまり、変数は一つづつ宣言させればいいのさ
それはプログラマがそうすればいいだけの話で、一行に一個づつ変数を宣言しろと。
つか、型宣言はC言語の問題の中では一貫性があり重大な欠陥の少ない部類だろ
なんでこんな所にイチャモンつけてんだか
関数ポインタや、配列返し const volatile register の修飾先が分りにくくて初心者がパニックを起こすのはちと考え物だとは思うが。

257:デフォルトの名無しさん
08/03/14 18:04:45
// C, C++
int *x,y; // xはintへのポインタ, yはint型
int x[N],y; // xはintの配列, yはint型

// C++ typedef
typedef int* pint;
pint x,y; // xとyはintへのポインタ

// java
int[] x,y; // xとyは int[]型

// C#
int* x,y; // xとyは intへのポインタ
int[] x,y; // xとyは int[]型

// D
int* x,y; // xとyは intへのポインタ
int[] x,y; // xとyは intの配列
int[3]*[5] x; // xは int の3要素配列へのポインタの5要素配列

いまさらC,C++の宣言の仕様が変わることは有り得ないけど、
新しい言語がCの宣言を否定しているので、
イチャモン？をつける人が出ても、まぁ致し方ないとは思う。

どうせ標準化委員会のメンバーでもないんだし、
気楽に論争(雑談)して良いと思うよ。

258:デフォルトの名無しさん
08/03/14 18:44:16
Cのparserを書こうとすると、Cの宣言の構文が嫌になる。
型名と変数名を区別するのに苦労させられるのがたまらん。

259:デフォルトの名無しさん
08/03/14 21:35:00
変数の宣言部分なんて、C++の話じゃなくて、Cの話だしな

260:デフォルトの名無しさん
08/03/15 04:12:13
>>258
スキャナで適当に区別してしまえよ、せっかく1 passで解析できるように出来ている構文なんだからさ。
それより、古き良き時代で大変役に立った機能が、今、逆に大きな弊害になっている点に突っ込めよ。
インテリセンス・デザイナ・リファクタリングツール・テストツール
リンクを高速に処理可能な抽象度の高い中間ファイル
モダンな機能が組み込み困難になっている現状こそが問題だろ。

261:デフォルトの名無しさん
08/03/16 01:54:31
[迷信] 識別子に使える文字は英数字と下線のみ
URLﾘﾝｸ(www.kijineko.co.jp)

262:デフォルトの名無しさん
08/03/16 04:22:46
>>261
ヨーロッパのマが書いたコードを見れば結構出現頻度高いんだよ、それ
日本やアメリカではお目にかからないけど

263:デフォルトの名無しさん
08/03/16 08:13:45
まぁ、javaやC#とかでも日本語識別子使えるけど、
文字列以外でASCIIでない文字を使うプログラマはカス

日本語プログラミング言語は別だけど

264:デフォルトの名無しさん
08/03/16 15:05:19
もうウニコードベースにすりゃいいのに

265:デフォルトの名無しさん
08/03/16 17:22:02
>>263
日本語ラベルは便利だぞ、C/C++だとラベルはラベル、実行コードは実行コードと分かれているが
リフレクションを持つJavaやC#では、構造体のラベル名を読み取って、そのまま活用できるから、
例えば表のタイトル文字列と、構造体のメンバの名前で表示するとか、XMLの内容をラベル名で出力するとか。
一箇所修正するだけで、全部修正完了するのは便利だ。

266:デフォルトの名無しさん
08/03/16 20:41:58
まさに、そういう考えの人が多いからこそ嫌いなんだけどな
間違ってるとまでは言わないが

ただ、システムの識別子はリファクタリング以外では変えるべきじゃないし
表示名のような業務要件で変わる外部のものと、内部のものを密結合にされると
逆に面倒なことになることもある

267:デフォルトの名無しさん
08/03/17 05:18:58
リファクタリグツールから名前を変更すれば、関わる "識別子=表示名" を根こそぎ全部置換してくれるから、変更漏れがなくていいと思うんだが。
それに、他人に説明するときに対応関係を説明する手間も省けるし。

268:デフォルトの名無しさん
08/04/23 11:39:07
>>179
粘菌の本質をベースクラスとして定義し
そこから派生クラスで環境依存部分を定義する

後は、派生クラス側で
operator=()をベースクラスのコピーと派生クラスの初期化に定義し直せば、動的に粘菌の性質を変更できるんじゃないのか?

269:デフォルトの名無しさん
08/04/23 11:48:50
俺はC++を見捨てたというより使いこなせるようになるのを諦めた。

270:デフォルトの名無しさん
08/04/24 00:12:27
自分を見限ったという事ですか。

271:デフォルトの名無しさん
08/04/24 00:37:32
そうでーす

272:デフォルトの名無しさん
08/04/24 12:26:49
>>268
いや、そーじゃなくて、プログラミング言語以前に、粘菌とはこれだという定義ができないって話らしいお。

273:デフォルトの名無しさん
08/04/24 16:04:17
>>272
定義できないなら、それが粘菌であるかどうかすらわかんないじゃん

例えば、
「晴れたら、小さな芋虫みたいになって、四方八方に散らばり」
「雨が降ったら、ぬちゃぬちゃで繊維質な物体になる」
って性質を持って居るように見えて
本当は、
「晴れたら、小さな芋虫に捕食され、雨が降ったら、その芋虫を養分に育つ」
のが本当の姿である可能性もあるじゃん

その場合、クラスだの、プロトタイプだの関係なく、オブジェクトの設計そのものに失敗しているってことじゃん

274:デフォルトの名無しさん
08/04/24 16:20:48
名前考えるのめんどくさいよね。
日本語でおkになってほしい。

275:デフォルトの名無しさん
08/04/24 16:27:56
＞オブジェクトの設計そのものに失敗しているってことじゃん

ま、つまり、そういうことだ。
現実は、オブジェクト設計を失敗してるってこと。

【謎飼育】正体不明の謎生物を7年間に渡って飼育している動物園
URLﾘﾝｸ(karapaia.livedoor.biz)

遺伝子組み換えで、生物どころか単なるパーツが作られちゃうかも。

276:275
08/04/24 16:29:45
「現実は」ってのは、”現実世界は”ってことね。

クラス派生で生物が進化してきたわけじゃない。
グラデーション、みたいな。

277:275
08/04/24 16:32:24
もっというと、生物の進化は、単純化・複雑化の２方向があるが、現実は「複雑化」の一方。

今、要素を洗い出しても未来には違う要素が出てくる。
スタティックなクラスじゃ足りないってこと。

278:デフォルトの名無しさん
08/04/24 16:34:28
めたふぁとしてのオブジェクトはもういいよ。
それ最初に本に登場したの1992だよ。
名前は日本語でいいが次のトレンドだよ。

279:デフォルトの名無しさん
08/04/24 16:40:24
＞例えば、
＞
＞って性質を持って居るように見えて
＞本当は、
＞
＞のが本当の姿である可能性もあるじゃん

　↑
これに具体例を入れるだけで、クラスベース言語の限界と問題点が明確になるテンプレ。

280:デフォルトの名無しさん
08/04/24 16:53:29
> 例えば、
> 大きい
> って性質を持って居るように見えて
> 本当は、
> 小さい
> のが本当の姿である可能性もあるじゃん

ねーよｗｗｗ

281:デフォルトの名無しさん
08/04/24 17:02:34
まあ、ヒトクラスとサルクラスを作ったらその分化前の類人猿はどうするよ、と。
類人猿クラスを作ったらそれとヒトの間はどうするよ、と。
ミッシングリンクみたく、中間は無限にあるという問題になる。

282:デフォルトの名無しさん
08/04/24 17:12:17
>>281
それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。
結局ある種の制約がないとプログラミングできないんだから、その手の
問題がないほうが問題なんだよ。
制約があるのが正しい状態って結論が出て今があるわけ。

というわけで、いま必要なのは日本語でいいじゃんってことなんだよ。

283:デフォルトの名無しさん
08/04/24 17:13:39
>>279
それは、クラスベース言語の問題点じゃなくて、オブジェクト指向の限界だろw

>>280
ねーよｗｗｗ

>>281
それは、オブジェクト指向以前に、デジタル回路ととアナログ回路の違いからやり直した方がいいよ、たぶんw

284:デフォルトの名無しさん
08/04/24 17:18:13
>>283
おまい無知なだけじゃん。
スタティックなOOがクラスベースっていうOOのイロハを知らないんだろ。

回線切ってケーブルで（ｒｙ

285:デフォルトの名無しさん
08/04/24 17:19:54
＞それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。

ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

昔あった議論は、OOじゃなくて構造化は是か非か。
その前は、汗じゃなくてCは是か非か。

286:デフォルトの名無しさん
08/04/24 17:25:41
整数型　ねーよ　＝　いいえ。
どうよこれ？
いいだろ？

287:デフォルトの名無しさん
08/04/24 17:26:23
＞制約があるのが正しい状態って結論が出て今があるわけ。

ねーよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

プログラミング言語はソフトウェアとともに進化して来てんだよ。
そしてソフトがクラスベース言語で表現できないものも扱い始めたんだよ。

おまいは市んだ法が良い。あどヴぁいすｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

288:デフォルトの名無しさん
08/04/24 17:31:46
あれか、人クラスを作ったとき
会社員クラスから学生クラスには出来ず、また学生クラスから会社員クラスにも出来ないから、クラスベースは静的で役に立たないってかw

289:デフォルトの名無しさん
08/04/24 17:38:19
288=誤読乙！

ヴぁかは読解力が無いようでｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

290:デフォルトの名無しさん
08/04/24 17:42:13
>>288
is a関係とhas a関係とかいう奴だな。
そこで、property型を導入するんだよ。
日本語至上主義的には属性ってしたくなるけど、そこは肩書だな。
なんでかっていうと、肩書ってしとけば委譲するとき意味的に
ぴったしっぽいじゃん。
で、よくよく考えると他重軽傷でいいのか？とか思っちゃうんだけど、
そうするとまた最初に戻っちゃうので、肩書を導入すること推奨。

291:デフォルトの名無しさん
08/04/24 17:47:48
芝君の話は難しすぎて判りませんね(棒読

292:デフォルトの名無しさん
08/04/24 17:49:34
会社員や学生に「is-aヒト」問い合わせしたらtrueだろうが、
ヒト・サルに文化する前の類人猿に「is-aヒト」、「is-aサル」を問い合わせたら、true？false？
サルが派生してヒトになったわけじゃない。
類人猿が分化して夫々になったわけだし。

293:デフォルトの名無しさん
08/04/24 17:51:36
C++0xに肩書が導入されたらどうするよ？

294:デフォルトの名無しさん
08/04/24 17:52:57
>>292
いいえになるよ。
だっていいえだろ？

295:デフォルトの名無しさん
08/04/24 17:53:41
誰だよふぁびょってるのは・・・

296:デフォルトの名無しさん
08/04/24 17:55:35
>>292
その認識だと類人猿はヒト、サルの共通の祖先なので、
ヒトでもサルでも無い(false)。
ヒト、サルにis-a類人猿したら両方trueだろ。

297:デフォルトの名無しさん
08/04/24 17:56:47
>>296
いいえになるよ。
折れるいじねんじゃないしｗ

298:デフォルトの名無しさん
08/04/24 18:00:15
>>297
デジタルモンキー乙w

299:デフォルトの名無しさん
08/04/24 18:02:12
略してでじもん乙。

300:デフォルトの名無しさん
08/04/24 18:07:11
取り敢えず、芝君の仲間になりたくないから、俺はC++で頑張るわ

301:デフォルトの名無しさん
08/04/25 00:14:14
芝君にとってのオブジェクト指向は、なんでも解決するスーパーテクニックの様です

傍迷惑でビッグなクラスとか、誰にも読めないプロトタイプの山が見えるな

302:デフォルトの名無しさん
08/04/25 07:29:05
じゃぁ、クラスの肥大化を防ぐテクニックについて語ろうぜ。
クラスっていうのはえさを与えなくても勝手に大きくなっていくものだからな。
テンプレートも一つの解ではあるな。

303:デフォルトの名無しさん
08/04/25 09:28:47
クラスを肥大化させないテクニックは
「馬鹿にクラス設計をさせない」

304:デフォルトの名無しさん
08/04/25 09:43:35
＞芝君

　↑
これって何？
自演クンって意味？

305:デフォルトの名無しさん
08/04/25 10:08:00
芝君の仕事は、2chのスレに芝を生やすことだぉ

306:デフォルトの名無しさん
08/04/26 10:18:40
　　　　　　　　　　　_,　._　
　　んもー！　（　・ω・）　　　　.　　.
　　　　　　　　○=｛=｝〇,　;　.'´　｀.　ﾞ　;　｀
　　　　　　　　|:::::::::＼,.'.;´,"　:´,´'　.　ﾞ　.｀　.
　.,,.,.,,,.,.,,,.,.,,,.,.,,,.,.,し,,.,.,`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗ　

307:デフォルトの名無しさん
08/04/26 11:43:10
>>302
テンプレートを使うとクラスの代わりに実行モジュールが肥大化します。

308:デフォルトの名無しさん
08/04/26 11:53:54
>>302
テンプレートを使うとコンパイル速度も飛躍的に悪化します。

309:デフォルトの名無しさん
08/04/26 13:32:46
>>302
テンプレート使っちゃうと、クラスに対するプロトタイプの利点が無くなるよぉw

310:デフォルトの名無しさん
08/04/27 00:04:47
実行モジュールのサイズを縮小し、コンパイル速度も短縮して
ついでに生産性も縮小するわけですね、わかります。

311:デフォルトの名無しさん
08/04/27 00:11:31
>>302
テンプレートを使うと >>310 の仲間になれるかもよ！

次ページ