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

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

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 の仲間になれるかもよ！

312:デフォルトの名無しさん
08/04/27 01:20:43
>>307-309,>>311
std名前空間使用禁止ﾜﾛﾀｗ

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

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

315:デフォルトの名無しさん
08/04/27 01:55:43
バグの生産性ですね分かります

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

317:デフォルトの名無しさん
08/04/27 10:42:23
肥大化はC++がというより
C#がという方がより適切と思うが
LINQとか

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

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

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

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

321:デフォルトの名無しさん
08/04/27 14:25:09
プロｷﾀー！

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

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

323:デフォルトの名無しさん
08/04/27 14:40:11
>>321
その他の言語ってのそれぞれ教えてくれないか？
C言語以外でｗ

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

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

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

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

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

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

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

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

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

328:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/04/27 16:54:23
>>325
> C, Java, C++, C
完全に予想通りの回答ありがとうｗ

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

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

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

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

332:デフォルトの名無しさん
08/04/27 17:17:25
>>331
現実には多いよ

333:デフォルトの名無しさん
08/04/27 17:19:16
>>330
そうなのか？
327のとこにはこう書いてあるけど。
> ストラウストラップの「ユーザー定義型の」オブジェクト指向
中略
> なお、この文脈の「オブジェクト指向」において、メッセージングはぜんぜん関係ない無用のもの
> and/or 動的性実現のための（仮想関数より効率の悪い）実装のひとつに過ぎない…
> ということを強く意識する必要があります。

334:デフォルトの名無しさん
08/04/27 17:20:58
>>332
そいつらってどういうコンプレックス持ってるんだ？
「ポインタ分からないのでstd::vectorとか使わないと可変配列も作れません」
とかの馬鹿はC++分かってるとは言わないし

335:デフォルトの名無しさん
08/04/27 17:21:36
そうかなあw
ポインタ本の人（前橋）の意見じゃないけど、メッセージ云々こそ「言い方を変えただけ」
に過ぎず本質と何も関係ないと思うけど。

336:デフォルトの名無しさん
08/04/27 17:23:26
>>331
折角苦労して C++ 覚えたのに C で何の問題も無い事を見せつけられたら
僻む気持ちも出てくる事だろうさ。今までの努力が水の泡だからな。
上には Java 下には C で居場所無いもんね。生産性重視なら LL があるし。

337:デフォルトの名無しさん
08/04/27 17:36:51
>>336
＞折角苦労して C++ 覚えたのに
そういう可哀想な連中は先々で躓くから気にしなくていいだろ
おそらくC++開発者としてもあまり役に立たないだろう

というか今日日、JavaやLL系も使えてもらえないと
流石にC++しか出来ませんじゃ困るだろ

338:デフォルトの名無しさん
08/04/27 17:48:28
>>332
>>335
　実装と理論は違うがな。
たまたまC++は実行コストから
関数≒メッセージレシーバの方式を
採っただけで本来メッセージの受信者は
PCの周辺機器やら、ネットワークの
向こう、はたまた操作するユーザーでも
構わないんだから。それらを抽象化して
クラスやプロとタイプと言うアプローチ
も構わないが根底にメッセージ概念が
有る事を意識する事は重要。
(故に単にメソッド&クラス脳の
Java屋はOO世界から馬鹿にされるんだがな)

339:デフォルトの名無しさん
08/04/27 17:57:48
Cを理解していればC++は0からよりは早く使えるようになる。
C++、Java、C#のどれかを理解してたら、
他の２つもすんなり使えるようになる。
JavaScript、Python、PHPなども同様。

宣言型言語に対してはともかく、
他の命令型言語に対してそれらの知識は水の泡にはならないと思う。
水の泡になるくらい応用力無いならＰＧ向いてない。

340:デフォルトの名無しさん
08/04/27 18:01:54
>>338
否定する気は無いけど、とりあえず>>327読んでからレスした方がいい

341:デフォルトの名無しさん
08/04/27 18:05:41
>>327のリンク先のことな

342:デフォルトの名無しさん
08/04/27 18:08:15
>>340
338ではないが、327 の考え方はゆがんでいると思うので、どうかな？
もっとシンプルにオブジェクト指向をとらえないと訳わからんようなるよ。
具体的にどう挙動するかなんて見たら、全部チューリングマシンになっちまう、そんなの意味無い。
歴史を紐解いたら、紆余曲折して進歩した以上、全部オブジェクト指向になりかねない、そんなの意味無い。

343:デフォルトの名無しさん
08/04/27 18:13:55
> 具体的にどう挙動するかなんて見たら、全部チューリングマシンになっちまう
同じように、342の言う「もっとシンプルにオブジェクト指向をとらえる」を当てはめれば、
全部メッセージになってしまう気がする、Cの関数呼出やアセンブリでのジャンプすらも。

どっちも次元や方向性は違えど、極論すぎるという点では同じと感じた。

344:デフォルトの名無しさん
08/04/27 18:15:20
>>343
言葉の定義なんだから、今主流的に言われている物でいいんだよ、変な事は考える必要はないかと。

345:デフォルトの名無しさん
08/04/27 18:18:26
オブジェクト指向はともかく、
メッセージって言葉は主流だと思えないけど。

346:デフォルトの名無しさん
08/04/27 18:22:48
>>341
アレは読んだが、アレを鵜呑みにする限り
C++＝OOを理解しないタコ
と言うレッテルは消えないだろうな
(まぁ、実際テンプレートにハマってしまえば
そんなレッテルはられようとどうでも
よくなるが…)
だが、Cで掛かれたドライバですら意識して
設計されてるんだ。言語に捕らわれ
設計思想として意識しないのは勿体無い。

347:デフォルトの名無しさん
08/04/27 18:26:51
C++はオブジェクト指向以外にもいろいろ広範囲に可能なことや思想が入っているから
オブジェクト指向ができないから駄目だという事にはならない訳で・・・
奇妙なオブジェクト指向は問題とは思うが、C++を知らないというのはさびしい話だね。

348:デフォルトの名無しさん
08/04/27 18:28:54
逆に、純粋にOOだけやっていたいというのであれば、
C++を使わないのもある意味正解。誘惑や罠が多すぎる。

349:デフォルトの名無しさん
08/04/27 18:40:20
クラスの肥大化防止はどうしたんだよ。

350:デフォルトの名無しさん
08/04/27 18:42:00
>>343
制御構造なんてのはメッセージを
受け取った相手の振る舞い又は
伝達手段の一部。
メッセージは多態であり抽象的な
もので、制御そのものをメッセージと
捉えるのは違うと思う。

351:デフォルトの名無しさん
08/04/27 18:48:09
>>346
340で書いた通り否定する気は無いけど、
327の先にある「このどれに軸足を置くかの違いでしかない」のところは正しいと思う

シンプルに捉えるのは良いけど、あんまり突き詰めると逆に混乱するぞ
オブジェクト指向という言葉が厳密に意味付けされてないからな

352:デフォルトの名無しさん
08/04/27 18:58:26
お前らスレタイ読めよ。
C++の話なんだからそんなもんどうでもいいだろ。

353:デフォルトの名無しさん
08/04/27 18:58:52
全ては関数
全ては入出力
全てはオブジェクト
全てはメッセージ
全てはリスト

354:デフォルトの名無しさん
08/04/27 19:04:18
>>352
まともなOOが出来ない→C++ｲﾗﾈ
→否意識・設定の仕方の問題だ

↑の流れと見ればスレタイの範囲では?

355:354
08/04/27 19:06:06
設定じゃなく設計だったｽﾏﾝ

356:デフォルトの名無しさん
08/04/27 19:09:56
じゃぁ、まともなOOはできないが素直なOOができるってことにしとけ。

357:デフォルトの名無しさん
08/04/27 19:20:35
てかよくよく考えたら別にOOじゃなくたってC++だったらいいんだ。
C++まんせー！

358:デフォルトの名無しさん
08/04/27 19:24:52
そうやってアイデンティティが一つ一つ消えていくんだな…

359:デフォルトの名無しさん
08/04/27 19:48:44
ところで、昨日ブレークポイントで止めてから丸一日が過ぎようとしているのだが…
おれ何やってたんだろ。

360:デフォルトの名無しさん
08/04/27 19:52:10
折角苦労して C++ 覚えたのに C で何の問題も無い事を見せつけられたら...ってそんなわけあるかぼけぇ!!!
こちとら、趣味でC++覚えたが、Cよりも便利で感動しとるわ!!!

少なくとも、Windows用のフレームワークを自作すれば、「Cで何の問題も無い事なんて有り得ない」って気が付くはずだが

361:デフォルトの名無しさん
08/04/27 19:54:50
オブジェクト指向とか言って、気構えているから難しいんだよ
ライブラリの読み書きの仕方程度に思ってりゃ楽勝さ

362:デフォルトの名無しさん
08/04/27 20:00:28
>>360
とはいえ、Windowsには独自のOOがあってCでも困らないという。

363:デフォルトの名無しさん
08/04/27 20:02:11
C++ いろいろな物が限界に達しているからな
コンパイルは遅いし、リンクも遅いし、言語もこれ以上の拡張はヤバすぎるし、ライブラリの混沌ぶりも尋常でないし、まともな開発補助ツールはないし
実用的オブジェクト指向をこの世に出現させ、これは他の言語で開花した。
以後の最大の成果としては template プログラミング、これも他の言語へ移行中。
一通り終わったら、次の世代に託して静かに消え去ってもらうのが良いと思うよ。

364:デフォルトの名無しさん
08/04/27 20:04:41
>>363
まぁまだ先の話だしな。
おれが先かC++が先かってくらい遠い将来の話だろ。
C++が死滅するのは。
今からそんなこと考えたって無駄だな。

365:デフォルトの名無しさん
08/04/27 20:06:41
>コンパイルは遅いし、リンクも遅いし
この二点だけで終わってるよ、マジしゃれならんレベルにまで落ち込んでる。
業務で使っているなら、他の言語にも触ったことがあるなら、深刻さは分かるはず。

366:デフォルトの名無しさん
08/04/27 20:25:11
少なくとも、templateがADAを除き
完全に他に移ることは無いと思うぞ。
他の言語に
class Container<type>
{
　priverte type member;
　public type pop(){…}
　public void push(type x){…}
}
なんて構造があってもtypeは(void*)
と変わらんからな。呼び出し時
Object obje;
Container<Object> list;
list.push(obje);//○
list.push(3);　　//×
のように制約が加えられるだけ。
恐らくこの先もコストがデカすぎて
実行時にクラス内の構造が変わる
コンパイル言語はでてこないだろ。

367:デフォルトの名無しさん
08/04/27 20:25:46
次がないからみんな困ってる

368:デフォルトの名無しさん
08/04/27 20:27:39
>>365
そこで分割コンパイルとプリコンパイルドヘッダを活用するってことだな。

369:デフォルトの名無しさん
08/04/27 20:29:25
>>368
そこまでやっても話にならない現状を一度他の言語をみて思い知っておくといいと思う。

370:デフォルトの名無しさん
08/04/27 20:41:24
>>362
それで困るから、フレームワークを自作するんだけどな
個人で使う分には、MFCやWTLほど大げさじゃなくてもいいし

371:デフォルトの名無しさん
08/04/27 20:44:14
c++の資産って他の言語から使えんの？
.netだとc++/cliでラッパー作って・・・ってするらしいけど
cだと普通に呼び出せたりするのにな

372:デフォルトの名無しさん
08/04/27 20:46:11
>>371
通常はCOMにする、ATL使ったら一発。
VBだろうか、VB.NET だろうか C# だろうが、死滅しかけのその他.NET言語でもイケる。

373:デフォルトの名無しさん
08/04/27 20:46:26
>>371
そりゃ使えるでしょVBからでもC#からでも

374:デフォルトの名無しさん
08/04/27 20:48:53
>>369
上から目線だｗ
C++使いは盲目的でC++しか使ったことがない教団の人ですか？

375:デフォルトの名無しさん
08/04/27 20:52:38
オープンソースのアプリに C++ のコードが混じってると
コンパイルがスローモーションになるから直ぐ分かるw

376:デフォルトの名無しさん
08/04/27 20:53:30
死滅しかけと言えばJ♯はどうなったんだ？

377:デフォルトの名無しさん
08/04/27 20:56:47
>>375
ビルドしかしないからそう見えるのでは？
修正→ビルド→…って繰り返してれば分割コンパイルや
プリコンパイルドヘッダの効果が出るよ。
確かにもうちょっと早くなってくれればいいんだけどねぇ。

378:デフォルトの名無しさん
08/04/27 20:58:44
>>377
そんなの当然やっての話ですよ。
どれほどの差があると思ってるんですか？

379:デフォルトの名無しさん
08/04/27 20:59:20
>>376
死滅がどうとかいうステージにすら立てないだろうその題材じゃｗ

380:デフォルトの名無しさん
08/04/27 20:59:21
>>368
Boost.SpiritとかBoost.LambdaとかP-Stade.Ovenとか
分割コンパイルとプリコンパイルドヘッダではどうにもならないんだが。

LambdaだけはC++0xで用済みになってくれるが。

>>366
Dのテンプレートはそんなんじゃなさそうな雰囲気。
Dを取り巻く環境（ツールやライブラリ）でまだまだ移ろうという気にならないけど。

381:デフォルトの名無しさん
08/04/27 21:00:54
つかC++のビルドって、リンクだけでお話しにならないからな

382:デフォルトの名無しさん
08/04/27 21:01:25
オープンソース戦士登場！
自由のために戦いまっす！！！
ソースダウンロード！まけまけいんすとーる！
おっせ～～～！C++だっせ～～～！
↑
こんなのに言い負かされてしまうｗ

383:デフォルトの名無しさん
08/04/27 21:03:37
>>378
ほ～～。
じゃぁ君はC++のとこだけ遅くなるからすぐわかるってくらい
全面的に修正してからリビルドするのかね。
そりゃぁすごいもんだ。

384:デフォルトの名無しさん
08/04/27 21:05:20
>>383
まぁ、井戸の外出た時にでもカルチャーショク受けてくださいなw

385:デフォルトの名無しさん
08/04/27 21:06:03
>>380
spiritは駄目だな。
あれはやりすぎだ。
変態的だとは思わないけどな。

386:デフォルトの名無しさん
08/04/27 21:08:06
>>384
遅いのは誰でも知ってることなんだよ。
使ってる人間が一番困ってるにきまってるだろうに。

387:デフォルトの名無しさん
08/04/27 21:08:56
>>383
コアな所を修正してたら再ビルドは全体に渡るんじゃないの。

388:デフォルトの名無しさん
08/04/27 21:10:33
>>387
プリコンパイルヘッダを限界まで効かせても、コンパイルが多方面に渡らなくても十分遅いからw

389:デフォルトの名無しさん
08/04/27 21:11:05
>>387
オープンソースのコアなとこを修正してビルド。

390:デフォルトの名無しさん
08/04/27 21:12:48
>>371
D言語の作者は制限無しにリンクするのは無理っていってる
多重継承とか例外周りが難所らしい

391:デフォルトの名無しさん
08/04/27 21:14:09
MFCだけどビルドのみだとチグハグなコトに・・って経験が何回もあると
ちょっとした変更でもリビルドやりたい病にかかる

392:デフォルトの名無しさん
08/04/27 21:16:19
MFCはビルド早いからいいけどな。
テンプレート駆使されると極端に遅くなるよな。

393:デフォルトの名無しさん
08/04/27 21:21:54
C++のビルドで、深刻な点の一つは参照先のobjが増えた時にリンクが加速的に遅くなる点だな。
独立プロジェクトが三個・四個になったら平気で5分となるが、この時間だけで C#やVBなら五回全ビルドできる。
まぁ、小さいプロジェクトを使っているうちは問題ないかもしれんが。
もちろんコンパイルその物の大変深刻ではあるが。

394:デフォルトの名無しさん
08/04/27 21:24:10
C#は恐ろしいほど早いと思ったけどなぁ。
でるひのほうがさらに早いって言われたなぁ。

395:デフォルトの名無しさん
08/04/27 21:25:45
ポーランドの製品はコンパイルが速くて高いオプティマイズが売りだから、そりやそうかと。
それがなかったら買い手がつかない。

396:デフォルトの名無しさん
08/04/27 21:28:22
spiritもだいぶ頑張って使いこなせるようになってきたけど、
結論としては使わないほうがいいな。

397:デフォルトの名無しさん
08/04/27 21:33:08
以前この板でcaperっていうのが出てきて期待してたんだけど、
だいぶ叩かれて作者もちべーしょんうしなったみたいだな。
いくつかバグはあるけど動作に問題はないしもう少し作りこんで
ほしかったけどな。
あれなんでたたかれてたんだろな。

398:デフォルトの名無しさん
08/04/27 21:36:17
コンパイルする言語としてはC++とJavaとC#を使ってるけど、
コード量に対するコンパイル速度に大した差は無い。

そんな差より、俺のＰＣと先輩のＰＣ（自腹で強化）との
コンパイル時間の差が有り過ぎ。
Core 2 Quad + メモリ3G でクソ早い。
俺のＰＣで30秒以上掛かるのがマジ5秒くらいで終る。会社ＰＣのスペックじゃない。

399:デフォルトの名無しさん
08/04/27 21:39:00
>>393
毎回フルビルドしてるの？
もし差分でそれならソースやばいんじゃない？

400:デフォルトの名無しさん
08/04/27 21:39:50
>>399
だからリンクだけって一生懸命かいてる、コンパイル0秒としてだ。

401:デフォルトの名無しさん
08/04/27 21:39:55
>>398
C++とJava・C#だとだいぶ開きがあるような。
spiritなんかF5押すたびにお茶が飲める。
かといってJavaでspiritみたいなことできるかっていうと、もっと
面白みのないものになるだろうけど。

402:デフォルトの名無しさん
08/04/27 21:41:28
>>399
一瞬オープンソースの子供が混じってただけで、>>393は普通の人だよ。

403:デフォルトの名無しさん
08/04/27 21:44:23
流石大人は違うなw

404:デフォルトの名無しさん
08/04/27 21:44:37
お前等どんなにボロイPCつかってんねん
もっといいPC買えよ

405:デフォルトの名無しさん
08/04/27 21:45:48
リンクで５分とか掛かり過ぎじゃね？
.dllとか.so無くて単一の実行バイナリ作ってるとかだったら吹くけど

406:デフォルトの名無しさん
08/04/27 21:46:47
>>398
俺もよそのCore 2 Quadでコンパイルしてみたことがあるが、
まるでC#やJavaのコンパイルみたいにC++も早いんだ。
こういう環境ならSpiritも楽しく使える。
こういう環境ならプリプロセッサも要らないと思える。

ちなみにC#だとまるでインタプリタのように一瞬で実行され始める、
コンソールプログラムだからあまり参考にならないかもしれないけど。

407:デフォルトの名無しさん
08/04/27 21:49:31
>>406
そんなに早いのか。
マシン性能って大事なんだな。

408:デフォルトの名無しさん
08/04/27 21:50:37
> こういう環境ならプリプロセッサも要らないと思える。
これどういう意味なんだろ？？
釣りなんかな。

409:デフォルトの名無しさん
08/04/27 21:50:44
まあCore2Quadなら50倍速ぐらい平気ででるかならw

410:デフォルトの名無しさん
08/04/27 21:51:00
>>404
もともとC++はしょぼいコンピュータでも使えるように
仕様作っていたはずなんだけどな。

今や高性能PCでないと使えないなんて何たる皮肉。
個人で手が出せるだけまだましか。

411:デフォルトの名無しさん
08/04/27 21:51:46
>>408
ごめんプリコンパイルドヘッダの間違いだ。
察してくれよ。

412:デフォルトの名無しさん
08/04/27 21:52:53
> こういう環境ならプリプロセッサも要らないと思える。
> まあCore2Quadなら50倍速ぐらい平気ででるかならw

オープンソース厨が嫌われる理由がなんとなく垣間見えた。

413:デフォルトの名無しさん
08/04/27 21:54:05
C++はDLL化しづらいのがきついところだな。
俺の趣味ライブラリはライン数が約7万の
全てスタティックライブラリで、フルビルドに8分ぐらいか。
CPUはセロリン1.4GHz

414:デフォルトの名無しさん
08/04/27 21:55:00
ばかやろう
開発機は昔から高性能だっちゅうの

415:デフォルトの名無しさん
08/04/27 21:55:30
>>410
原因のうちの一つは、プリプロセッサ
昔はこれにより大幅な高速化と利便性を得ることができたが、影響するものに全部インクルードすると、数が増えると指数関数的に遅くなってしまう。
その２は、objの形式の問題。
オブジェクト指向的なコードに対応する構造ではないから、ひどい有様になっている。
いずれも、昔は軽量であったものの、実は計算オーダーの問題がヤバかったと。

416:デフォルトの名無しさん
08/04/27 21:55:33
まぁ、全員Quad以上にしろってのは、ちょっと酷だけどｗ
開発マシンのスペックを上げるのも必要だろう。

ユーザーからの要求が高度化して、プログラムも複雑化・大量化して
それに応えるために言語も高度化していく。
さらに単価は抑えられてるから、生産性も求められる。
だからマシン強化も必要だろう、と俺は思う。

417:デフォルトの名無しさん
08/04/27 21:57:16
趣味ライブラリで７万ってすごいな。
マングリングってなんで統一しないんだろな。
できないのかな。

418:デフォルトの名無しさん
08/04/27 21:58:16
人のVC++ 2005プロジェクトが
いくつか静的LIBに分けて並列ビルドするようにするのを見て、
頭いいと思った。

サーセン

419:デフォルトの名無しさん
08/04/27 21:58:58
>>418
かえって遅くて笑ったでしょ

420:デフォルトの名無しさん
08/04/27 21:58:59
>>414
俺のPCだって買った当時はそこそこ高性能だった、はず……。

421:デフォルトの名無しさん
08/04/27 22:01:51
今じゃ俺のPen4 2.6Gは雑魚マシン扱いです

422:デフォルトの名無しさん
08/04/27 22:02:31
>>415
プリプロセッサで大幅に高速化ってどうやるの？

423:デフォルトの名無しさん
08/04/27 22:03:10
このスレには、アンチMSが一人、紛れ込んでるようですね

424:デフォルトの名無しさん
08/04/27 22:03:23
これからの言語は計算量のオーダが爆裂しないようになってないと厳しいっすよ
どんどん規模でかくなるし。

425:デフォルトの名無しさん
08/04/27 22:05:49
415がobjの問題を挙げているが、
今から新しいobj形式を作れないのかな？
ついでにexport templateへの対応が容易とかあれこれやっちゃって。
まあ焼け石に水だと思うけど。

426:デフォルトの名無しさん
08/04/27 22:05:57
>>423
確かによく読むとおかしなことをそれらしく書き込んでる子がいるけど、
アンチMSと何の関係があるのかさっぱり。

427:デフォルトの名無しさん
08/04/27 22:06:57
プリプロセッサで大幅に高速化ってなんだろ？

428:デフォルトの名無しさん
08/04/27 22:07:54
>>427
GNUがやってる、全ファイルをあらかじめ一本に結合してからコンパイル。
互換性の問題があって難航している。

429:デフォルトの名無しさん
08/04/27 22:08:49
関数マクロを使えば、インライン展開されるから
普通の関数より実行速度が速いってことではないか？
今はインライン関数があるから要らないな。

430:デフォルトの名無しさん
08/04/27 22:10:55
C++からC言語の悪い部分を取り除いた、ネイティブコード吐ける言語がほしいな

431:デフォルトの名無しさん
08/04/27 22:12:43
>>428
CPPとは別のプリプロセッサがあるのか。
それをやると、objごとにコンパイルするとかできなくなるんじゃないの？
ファイル数が減ると極端に速度が上がるのは検索システム作った時に経験したけど、
なんか逆向き行ってるような気がしないでもない。

432:デフォルトの名無しさん
08/04/27 22:13:13
んなことしたってさしてメリットのない非互換C++が増えるだけだろ。

433:デフォルトの名無しさん
08/04/27 22:14:54
>>431
仕組みでポカすると、それだけ深刻って事
アルゴリズム軽視するべからず。

434:デフォルトの名無しさん
08/04/27 22:15:14
>>429
ほー。

435:デフォルトの名無しさん
08/04/27 22:15:29
>>418
へー面白そう
やってみよっと

436:デフォルトの名無しさん
08/04/27 22:19:25
まぁRuby最高って書いとけばいいみたいだな。

437:デフォルトの名無しさん
08/04/27 22:22:26
>>433
つまりジェネリクスはダイナミズムで桶ってことですか？

438:デフォルトの名無しさん
08/04/27 22:30:32
趣味でやるならC++だが、
仕事では、絶対に使いたくないな。

バカが一人居ると、まともなものが完成しなくなる

439:デフォルトの名無しさん
08/04/27 22:36:21
2チャンネルももうだめかもなぁ。
前はたまに賢い人がいたもんだけど、最近は呆れてすぐ帰っちゃうな。
全員で釣竿垂らしてるような状態だな。

440:デフォルトの名無しさん
08/04/27 22:36:41
＞バカが一人居ると
敷居が低い言語程、バカによるダメージが小さいってのはあるな。
バカが居た場合のダメージは
　　C++ ＞＞＞ Java ＞ PHP
個人的な経験からだけどね。

でもまともなメンバーならある程度逆になる。
ライトウェイト系も悪くは無いけど、コンパイラの助けが少ないからね。
Javaも大人数でやれるけど、
パフォーマンスの問題が出たときとか結構大変だった。

441:デフォルトの名無しさん
08/04/27 22:38:14
>>439
まじで。プログラム板すごくレベルが低い。見てられない。

442:デフォルトの名無しさん
08/04/27 22:40:04
昔からこの板のレベルは大したことなかったろ。

443:デフォルトの名無しさん
08/04/27 22:42:06
>>442
いや、そんなことなかった。
まえは、なんだかんだいって煽りあいつつもまともな議論をしてたよ。
それなりのバックグラウンドのある人が煽りあってたっていうかさ。
今は何だか知ってる単語並べてるだけみたいな。
なんだかなぁ。

444:デフォルトの名無しさん
08/04/27 22:48:05
>>443
キミがゆうな

445:デフォルトの名無しさん
08/04/27 22:49:29
2003年の頃 (googleキャッシュ)
URLﾘﾝｸ(72.14.235.104)

446:こうですか? わかりません
08/04/27 22:52:33
キモいんだよね。
みみっちい言い合いばかりで。
がみがみ言うのもなんだけど、
ゆとりを持とうよ。あれこれ言われても
うざいなんて思わずに
なかよくやろうよ。

447:デフォルトの名無しさん
08/04/27 22:52:39
2001年の頃 (文字化けする人はソース表示で)
URLﾘﾝｸ(web.archive.org)

448:デフォルトの名無しさん
08/04/27 22:53:44
>>445
149: 人工ガッツ石松をﾌﾟﾛｸﾞﾗﾐﾝｸﾞするﾇﾚｯﾄﾞ (16)
このスレなんか名スレだったんだろうなぁ。
おれの予想ではたった16レスで人工知能完成させたと思うぜ。
今の造るスレは>>50までいかないで放棄されるからなぁ。

449:デフォルトの名無しさん
08/04/27 22:57:38
モリタポ使って見たけど、確かに16レスで完成してたなｗ

16 ：デフォルトの名無しさん：03/08/18 00:00
main()
{
while(1)
printf("OK牧場\n");
}

450:デフォルトの名無しさん
08/04/27 22:59:06
>>446
いやそうじゃなくてさ。
あおりあいは昔からすごかったぜ。
でも中身はしっかりしてたよな。
今って適当に相槌うったりしてるけど、バックグラウンドが透けて見えるじゃんか。
何書いてんだろこいつ・・なんて思いつつ、ほーそれはすごいねとか書きこんでるわけよ。
言ってみればリア中が多いんだろな。
リア中って昔はHSPスレにいて棲み分けできてたんだけどなぁ。

451:デフォルトの名無しさん
08/04/27 23:00:12
>>449
うけたｗ
ほんとに名スレだったんだなｗ

452:デフォルトの名無しさん
08/04/27 23:01:11
>>450
このスレタイは、そういう人を呼び寄せるタイトルだと思います。

453:デフォルトの名無しさん
08/04/27 23:05:06
しかし、見れば見るほど洗練されたコードだなぁ。
たった数行にガッツ氏のすべてが詰め込まれてるなぁ。

454:デフォルトの名無しさん
08/04/27 23:09:11
まぁ2chの性質上仕方ないかもな。
あとIDが出ないのがそれを加速させてる。

455:デフォルトの名無しさん
08/04/27 23:17:03
>>454
俺もそう思う。
IDがあった方が良いって言っても
「書き込みが減る」「IDがあっても変えて自演出来る」とか言われるんだよな。

それで減るような書き込みなんて大したレスじゃないだろうし、
ID変えたって
ｽﾚﾘﾝｸ(software板:29-43番)n
みたいなことになるから、IDあっても良いと思うんだけどな。

456:デフォルトの名無しさん
08/04/27 23:57:10
R15指定でおｋ

457:デフォルトの名無しさん
08/04/28 17:53:27
馬鹿っぽい書き込み発見!!!

458:デフォルトの名無しさん
08/04/28 18:50:25
そもそもC#からDirectXを呼ぶ公式な手段は消滅しました。

459:デフォルトの名無しさん
08/04/28 19:25:08
それが肥大化と

460:デフォルトの名無しさん
08/04/28 21:49:37
>>458
だから何？アホ？

461:デフォルトの名無しさん
08/04/28 22:26:37
SlimDX

462:デフォルトの名無しさん
08/04/29 21:03:23
昔と比べて質が下がったとか言ってるけど
一番、質を下げてるのはその発言だってのは、お兄さんと君との「ひ・み・つ」だぞ!!!

463:デフォルトの名無しさん
08/04/29 23:59:32
テンプレートがソースに混ざると
なんか異物っぽいんだよねぇ　なかなか慣れないですC++

464:デフォルトの名無しさん
08/04/30 00:03:34
テンプレートで異物感を感じてるようじゃ、C++0xなんか拒否反応だろうな。

465:デフォルトの名無しさん
08/04/30 00:23:15
テンプレートははまる

466:デフォルトの名無しさん
08/04/30 03:18:16
実際テンプレートだけ扱いや制限がかなり異なるからなぁ

467:デフォルトの名無しさん
08/04/30 13:37:16
CよりC++のほうがわずかに速い。
理由は・・・知らん。
Rubyが意外と善戦してて僅かながらPrologより速いのには恐れ入った。
↑褒めといたから荒らすなよ。

URLﾘﾝｸ(shootout.alioth.debian.org)

468:デフォルトの名無しさん
08/04/30 14:10:12
>>467
コンパイル時解決を多用して
オーバーヘッドを極力減らすコーディングになってるんじゃないかね

469:デフォルトの名無しさん
08/04/30 14:11:03
C++を静的なPerlとして使ってる奴も少なからずいるだろう。
そういう場合はCの方が速い。

470:デフォルトの名無しさん
08/04/30 19:49:39
C++を性的な目的で使ってごめんなさい

471:デフォルトの名無しさん
08/04/30 19:54:51
詳細希望

472:デフォルトの名無しさん
08/04/30 19:58:22
(i)

473:デフォルトの名無しさん
08/04/30 20:25:31
->*

474:デフォルトの名無しさん
08/04/30 22:36:40
エロゲ屋くらいか、そういうの。

475:デフォルトの名無しさん
08/04/30 23:19:36
決して万人受けしない拡張がいくらか入ってるのはそりゃそうだけど、
クラスとあんまり関係ない部分も「便利C」程度にはなってんだから、そこらへん愛せばいいじゃない、とも思う

あとString関連とか。
C文字列の扱いなんて「理屈は分かり切ってるけど、まどろっこしい」人が使うにはちょうどいいだろうし。
（Stringから入ったりしたら怖いけど）

476:デフォルトの名無しさん
08/04/30 23:35:53
えーとStringってどこのnamespaceですか。
stdはstringですよ。

477:デフォルトの名無しさん
08/04/30 23:44:36
知ってるけどCStringその他あるから限定しないように書いた

478:デフォルトの名無しさん
08/05/01 00:27:27
は？

479:デフォルトの名無しさん
08/05/01 00:30:11
ほ

480:デフォルトの名無しさん
08/05/01 02:28:40
何にせよCの方が楽だけどね

481:デフォルトの名無しさん
08/05/01 03:30:47
デストラクタが無いCはまともに使う気しない

482:デフォルトの名無しさん
08/05/01 03:53:53
デストラクタなんて要らない
必要以上に高い所へ上がろうとするから、
落ちやしないかと心配になるんだよ

次ページ