[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 02/26 06:21 / Filesize : 219 KB / Number-of Response : 994
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2008/01/29(火) 09:52:47 ]
文法面での機能拡張しすぎ。
C++の構文解析とか、もうワケワカメ。
マイクロソフト拡張大杉。
gcnew とか使うぐらいなら素直に Java でも C# でもつかえ!!!



185 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 10:56:23 ]
>>180
なんだろ・・・すごい話がかみ合ってない希ガス。

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

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

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



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

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

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

188 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:01:03 ]
>現実にはイノシシからブタが発生したりするわけ。
>実行時にクラスが増えていくって感じ?

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

189 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:04:45 ]
>実行時にクラスが増えていくって感じ?

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

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

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

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

おまいOOわかって無いだろう、jk

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

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

で?



194 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:21:45 ]
>>193
やっぱりそういう勘違いをしてるのか・・・

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

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


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

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

強烈に頭が悪い悪寒。

198 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:26:31 ]
どっちにしろ、OOってのは現実世界の投影。

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


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

これ、強烈に頭割る杉。

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

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

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

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

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

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

202 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:34:28 ]
>oopは安全性の向上、再利用性の向上、が目的だろ。

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

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

203 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:40:19 ]
>>201
初めて知ったわ。なんかそれぞれの学術書でもあるん?



204 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 11:43:09 ]
何を分かった風な。

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


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


207 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:21:05 ]
OOの本流に一番近いのはRubyかな

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


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

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


210 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:30:25 ]
>>209
馬鹿は黙ってろ


211 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:31:47 ]
>馬鹿は黙ってろ

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

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


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


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

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



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

213=ヴぁか?



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


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

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

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

217 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 14:58:40 ]
>>214
一例になるから213は物理学者ならって書いてるんじゃね?

218 名前:213 mailto:sage [2008/03/11(火) 15:03:49 ]
>>216
オブジェクト指向=現実世界の投影じゃ〜
って書いた方が良かったかな。

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

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

220 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:05:07 ]
>ドメイン(問題領域)の投影

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

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

>>220
馬鹿は黙ってろ


222 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:15:05 ]
>>219
だからそう言ってんじゃんw
どう読んでんだよw
213はイコールじゃないって言いたいんだろ

223 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:17:42 ]
>>222
あ、自分の読み間違い?

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



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

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

225 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:28:41 ]
では、OOとしてドメインの投影するには、どんな言語が良いのだ?

226 名前:デフォルトの名無しさん mailto:sage [2008/03/11(火) 15:46:33 ]
C++でイナフ

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

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

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

230 名前:デフォルトの名無しさん mailto:sage [2008/03/12(水) 08:51:12 ]
C++ではSTLくらい普通の内です。

231 名前:デフォルトの名無しさん mailto:sage [2008/03/12(水) 13:16:03 ]
現状のSTLは欠陥品って報告が数多くでてるじゃん

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

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



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

235 名前:デフォルトの名無しさん [2008/03/12(水) 19:43:05 ]
www.nicovideo.jp/watch/sm2482689

C++のエラーは黒魔術

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

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

238 名前:デフォルトの名無しさん [2008/03/12(水) 23:12:57 ]
>>231
まだVC6使ってんのか?

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

240 名前:デフォルトの名無しさん mailto:sage [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:13:00 ]
それもそうだが、まずtypedefの構文をもっとまともにすべきだったね。

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

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

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



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

245 名前:デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:25:07 ]
>>244
それは、宣言の書き方であって typedef 関係ない

246 名前:デフォルトの名無しさん mailto:sage [2008/03/13(木) 01:36:55 ]
typedefが記憶クラス指定子ってところがおかしいだろ。

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

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

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

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



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

251 名前:デフォルトの名無しさん [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:03:01 ]
>>251
関数型の世界しか頭になさそうなアホちんですね
組み込み等では大変役に立ったモンですよ

253 名前:デフォルトの名無しさん mailto:sage [2008/03/14(金) 10:14:55 ]
>>250
kwsk
>>251
レス番間違えてない?
>>252
よく読んでない悪寒




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

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

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

257 名前:デフォルトの名無しさん mailto:sage [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/03/14(金) 18:44:16 ]
Cのparserを書こうとすると、Cの宣言の構文が嫌になる。
型名と変数名を区別するのに苦労させられるのがたまらん。

259 名前:デフォルトの名無しさん mailto:sage [2008/03/14(金) 21:35:00 ]
変数の宣言部分なんて、C++の話じゃなくて、Cの話だしな


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

261 名前:デフォルトの名無しさん mailto:sage [2008/03/16(日) 01:54:31 ]
[迷信] 識別子に使える文字は英数字と下線のみ
ttp://www.kijineko.co.jp/tech/superstitions/only-alnums-and-underscore-are-usable-for-identifier.html

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

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

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



264 名前:デフォルトの名無しさん mailto:sage [2008/03/16(日) 15:05:19 ]
もうウニコードベースにすりゃいいのに

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

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

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

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

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

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


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

270 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:12:27 ]
自分を見限ったという事ですか。

271 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:37:32 ]
そうでーす

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

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

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

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




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

275 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:27:56 ]
>オブジェクトの設計そのものに失敗しているってことじゃん

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

【謎飼育】正体不明の謎生物を7年間に渡って飼育している動物園
ttp://karapaia.livedoor.biz/archives/51124187.html

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

276 名前:275 mailto:sage [2008/04/24(木) 16:29:45 ]
「現実は」ってのは、”現実世界は”ってことね。

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

277 名前:275 mailto:sage [2008/04/24(木) 16:32:24 ]
もっというと、生物の進化は、単純化・複雑化の2方向があるが、現実は「複雑化」の一方。

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

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

279 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:40:24 ]
>例えば、

>って性質を持って居るように見えて
>本当は、

>のが本当の姿である可能性もあるじゃん

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


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

ねーよwww

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

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

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

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

>>280
ねーよwww

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




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

回線切ってケーブルで(ry

285 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 17:19:54 ]
>それ俺らが生まれる前の時代にさんざん議論されつくした話題じゃん。

ねーよwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww


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






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<219KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef