[表示 : 全て 最新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# でもつかえ!!!



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は是か非か。

286 名前:デフォルトの名無しさん [2008/04/24(木) 17:25:41 ]
整数型 ねーよ = いいえ。
どうよこれ?
いいだろ?


287 名前:デフォルトの名無しさん [2008/04/24(木) 17:26:23 ]
>制約があるのが正しい状態って結論が出て今があるわけ。


ねーよwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww


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


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

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


289 名前:デフォルトの名無しさん mailto:sage [2008/04/24(木) 17:38:19 ]
288=誤読乙!

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



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

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


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

293 名前:デフォルトの名無しさん [2008/04/24(木) 17:51:36 ]
C++0xに肩書が導入されたらどうするよ?

294 名前:デフォルトの名無しさん [2008/04/24(木) 17:52:57 ]
>>292
いいえになるよ。
だっていいえだろ?

295 名前:デフォルトの名無しさん [2008/04/24(木) 17:53:41 ]
誰だよふぁびょってるのは・・・

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

297 名前:デフォルトの名無しさん [2008/04/24(木) 17:56:47 ]
>>296
いいえになるよ。
折れるいじねんじゃないしw

298 名前:デフォルトの名無しさん [2008/04/24(木) 18:00:15 ]
>>297
デジタルモンキー乙w

299 名前:デフォルトの名無しさん [2008/04/24(木) 18:02:12 ]
略してでじもん乙。



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


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

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

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

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


304 名前:デフォルトの名無しさん mailto:sage [2008/04/25(金) 09:43:35 ]
>芝君

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

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


306 名前:デフォルトの名無しさん mailto:sage [2008/04/26(土) 10:18:40 ]
           _, ._ 
  んもー! ( ・ω・)    .  .
        ○={=}〇, ; .'´ `. ゙ ; `
        |:::::::::\,.'.;´," :´,´' . ゙ .` .
 .,,.,.,,,.,.,,,.,.,,,.,.,,,.,.,し,,.,.,`(.@)wwwwwwwwwwwww 

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

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

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




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

311 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 00:11:31 ]
>>302
テンプレートを使うと >>310 の仲間になれるかもよ!

312 名前:デフォルトの名無しさん [2008/04/27(日) 01:20:43 ]
>>307-309,>>311
std名前空間使用禁止ワロタw

313 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 01:21:04 ]
>>302
クラスが肥大化するのは、設計が悪い場合もあるけど、
提供する機能が多いっていう場合もあるんだよな。
後者の場合、どんなやり方をとったとしても、大きなクラスかたくさんのクラスを作るかせねばならん。

314 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 01:52:27 ]
クラスを使っても肥大化、テンプレートを使っても肥大化。言語仕様も益々肥大化。
むしろ C++ ユーザは肥大化を求めているんじゃないかな。実際どうかは別として、
肥大化すればするほど生産性が上がるという教義だから。

315 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 01:55:43 ]
バグの生産性ですね分かります

316 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 04:35:53 ]
別に肥大化したところで、使いたいと思わない機能は使わなきゃいんじゃね?
Bjarne氏もD&Eでそう言ってたし。「使わない機能はコストを発生させない」っていう
原則もあることだし。肥大化することで初心者が不幸になることもないと思う。
ただまぁ、何から学べばいいかわかりにくくなるor勉強する(べきだと思われる)ことが
多すぎてしょんぼりくる可能性はあるが。

317 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 10:42:23 ]
肥大化はC++がというより
C#がという方がより適切と思うが
LINQとか

318 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 12:54:40 ]
使ってる人間の殆どが肥大化嗜好だから、使いたいと思わない機能は
使わないという当たり前の選択を貫徹するのは不可能に近い。

319 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 13:34:57 ]
>>318
まあな
使わないと選択する為には
少なくともその機能を知っておかなければ
ならない訳で、もうその時点でラーニングコストは
発生している。初めから無理なことを言っている。



320 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 13:50:34 ]
プロの道具なので仕方ない。
プロでない人は自分が使いやすい言語を選ぶと良い。

言語の機能の習得ごときでいっぱいいっぱいなら、
組み込み系、DB、マルチメディア処理、ドライバ開発とかの
言語以外ので学習で鼻血出るだろうな。

321 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 14:25:09 ]
プロキター!

プロならもっと道具を選べよ…
その4つの中で C++ が他の言語より優れているのって
マルチメディア処理だけだな。

322 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 14:30:01 ]
でもすべての言語をその4つの平均点で比べるとC++はかなり有能だろ

323 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 14:40:11 ]
>>321
その他の言語ってのそれぞれ教えてくれないか?
C言語以外でw

324 名前:320 mailto:sage [2008/04/27(日) 15:01:09 ]
>>321
どう読んだのか知らないが、俺の趣旨は
 ・学習用の言語でないので、言語機能を理解力の低い人に合わせる必要は無い。
 ・言語の機能の習得と、専門知識の習得では、後者の方が難しい。
ということなんだが。

その4つは例を挙げたに過ぎないし、
それらにC++が適しているとも言っていない。

特にDBは俺が最近DB周りのチューニングとかしてたので、
たまたま脳裏に出てきただけだ。言語はC++じゃない。

道具を選べ、というのは同意する。
他のメンバーやプラットホームの都合があるので、
好きに選べるわけじゃないけどな。

325 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 16:07:21 ]
>>323
C++ 使いには C にコンプレックス持ってる人間が多いな。
道具は使いようだぜ。

組み込み(つっても色々あるが…) -> C
DB(まあ Oracle だと思いねえ) -> Java
マルチメディア(画像処理とか) -> C++
ドライバ(Win は知らんけど…) -> C

>>324
分野別の知識は言語の習得とは直行した課題だと思うよ。
専門知識の習得は、言語が難しかろうが簡単であろうが必要となる事なんだから、
言語の習得は簡単な方が良いとも言えるんじゃないかな。

326 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 16:14:10 ]
ところで、上の方でOO云々語ってる奴らはJavaやらC++の
対象.メッセージ(値,値);
構文しか知らんのだろうな、例えば
[対象 メッセージ:値 メッセージ:値];
やら
Send(対象,メッセージ,値,値);
とか、
メッセージ(対象,値,値);
(メッセージ 対象 値 値)
なんかを知ってればもっと増しな議論が
出来るだろうに。
せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。

327 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 16:23:54 ]
知っているに越したことはないが、それはまたC++とは別の世界。
C++のOOでメッセージを持ち出してくるのもどうかと思う。
d.hatena.ne.jp/sumim/20040525/p1

328 名前:デフォルトの名無しさん [2008/04/27(日) 16:43:41 ]
>>327
確かにそうだがC++で

template<class T>void F(T &対象)
{
 対象.メッセージ();
}

//対象1と対象2は同じメッセージを持つ
//意外何ら関連性は無い
型1 対象1;
型2 対象2;

//Fは対象が何であれ構造を気にせず
//処理を行える。
F(対象1);
F(対象2);

という文を見ると、静的ではあるが
メッセージを意識せざる得ない。
アラン・ケイがRubyを誉める理由も
これを動的且つ素直に実装できる事が
一因しているように思う。

329 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 16:54:23 ]
>>325
> C, Java, C++, C
完全に予想通りの回答ありがとうw



330 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 16:57:27 ]
>C++のOOでメッセージを持ち出してくるのもどうかと思う。
もともとC++はオブジェクト指向できるようにはできていないんだよ、だからSTLなんだ。
しかしオブジェクト指向を考えるならメッセージを考えないというのは論外。

自分は 326 じゃないが
>せめてクラスや継承は必要悪でありOOの本質でないと気付いて貰いたいものだ。
これはオブジェクト指向においては核心部分だぞ。

331 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 17:16:33 ]
C++使ってる奴がCにコンプレックスってのは考えられないな

C95とは基本的に互換だから、気にするのはC++の構文が使えない程度
C99との差異は理解の上では大したことないし
精々STLが使えなくて面倒ってとこだろ






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

前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