C言語を完全に駆逐するためには

C言語を完全に駆逐す� ..

252:デフォルトの名無しさん
08/05/20 23:56:40
>>235
書いていないな。

そもそもあの本が書かれたのは95年頃で、
テンプレートによるコンパイル速度の低下は
まだ問題になっていなかったのではないかと思う。
俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。

253:デフォルトの名無しさん
08/05/21 00:02:40
テンプレートこそC++の特徴であり価値の一つだと思うんだけど

254:252
08/05/21 00:09:26
>>253
そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、
実際、そんな機会は全然ないから
「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。
すれ違いすまん。

255:デフォルトの名無しさん
08/05/21 00:20:09
C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな…

256:デフォルトの名無しさん
08/05/21 01:45:37
そもそもGLSって略称一般的かなあ

257:デフォルトの名無しさん
08/05/21 01:56:54
スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない?

258:デフォルトの名無しさん
08/05/21 02:13:36
>>235
D&E 15.10 あたりで問題は認識しいるようですよ。
最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので
ずいぶん良くなったと思います。
モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。

259:デフォルトの名無しさん
08/05/21 07:38:05
>>258
他の言語だってモジュール分けすればもっと速いよ
C++ と違って小細工しなくても常識的な速さだけど

260:デフォルトの名無しさん
08/05/21 08:31:09
まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。

261:デフォルトの名無しさん
08/05/21 08:57:38
C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。

262:デフォルトの名無しさん
08/05/21 09:10:21
>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。

263:デフォルトの名無しさん
08/05/21 09:20:06
C/C++は糞。
Cは必要悪だがC++は必要ですらない。

264:デフォルトの名無しさん
08/05/21 14:58:16
ベターCとしてのC++は悪くない

ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。

265:デフォルトの名無しさん
08/05/21 16:41:10
プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。

266:デフォルトの名無しさん
08/05/21 17:59:57
ほほう、それでC++が晴れてベターCになれると。

267:デフォルトの名無しさん
08/05/21 19:36:41
>>266 問題点を指摘して、もっといい方法を教えてください。

268:デフォルトの名無しさん
08/05/21 20:26:33
>>262
>>>261 詳しく。

URLﾘﾝｸ(www.nobugs.org)

C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど

269:デフォルトの名無しさん
08/05/22 03:03:43
全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。

270:デフォルトの名無しさん
08/05/22 03:10:14
配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない

271:デフォルトの名無しさん
08/05/22 03:10:59
>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。

ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。

272:デフォルトの名無しさん
08/05/22 14:36:52
言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。

273:デフォルトの名無しさん
08/05/22 14:54:56
デファクトスタンダードと言う言葉を送ろう。
最近の悪例　Windows　　別に利用者がダメとは思わない。

274:デフォルトの名無しさん
08/05/22 18:38:08
さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。

275:デフォルトの名無しさん
08/05/24 21:04:40
つまりCをつかってりゃよかったって話なのか？

276:デフォルトの名無しさん
08/05/26 00:11:25
その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。

277:デフォルトの名無しさん
08/05/26 00:29:03
言いたいことは分かる気がする。

俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。

278:デフォルトの名無しさん
08/05/26 07:31:34
赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ

279:デフォルトの名無しさん
08/05/26 10:32:00
>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？

280:デフォルトの名無しさん
08/05/26 17:37:34
>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。

それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが

281:デフォルトの名無しさん
08/05/26 18:20:57
古い言い伝えを思い出すな。

紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。

282:デフォルトの名無しさん
08/05/26 18:35:03
AとBはどこ行った?w

283:デフォルトの名無しさん
08/05/26 19:40:52
勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな

284:デフォルトの名無しさん
08/05/26 22:53:10
駆逐できそうにないですね

285:デフォルトの名無しさん
08/05/26 23:09:44
>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。

286:デフォルトの名無しさん
08/05/26 23:23:47
>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･

287:デフォルトの名無しさん
08/05/27 09:00:15
そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。

288:デフォルトの名無しさん
08/05/27 20:27:43
CプログラマがC++を使わない理由を探す理由を知りたい。

289:デフォルトの名無しさん
08/05/27 20:47:04
その前に>>288がなぜそんなことを聞くのか理由を知りたい

290:デフォルトの名無しさん
08/05/27 20:50:18
>>288組み込み系では、Cが最適開発環境であることは多い。

291:デフォルトの名無しさん
08/05/27 21:49:33
CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。

292:デフォルトの名無しさん
08/05/27 22:07:11
C言語と日本語と英語が使えます。

293:デフォルトの名無しさん
08/05/27 23:42:22
その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。

職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。

294:デフォルトの名無しさん
08/05/27 23:58:49
うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。

295:デフォルトの名無しさん
08/05/28 00:17:12
考えるのがめんどくさい
息をするのもめんどくさい

296:デフォルトの名無しさん
08/05/28 00:20:34
ゆうちゃんとめんどくさいさい

297:デフォルトの名無しさん
08/05/29 20:16:05
組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？

298:デフォルトの名無しさん
08/05/29 20:44:31
GBAのときはCの方がC++より多かったと思う。今は分からない。

299:デフォルトの名無しさん
08/05/29 21:27:12
なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん

300:デフォルトの名無しさん
08/05/29 22:48:42
>>299
>携帯電話を組み込み系と言ったら笑われたり

そうなの？　カーナビと携帯は組み込みの2大巨頭だと思ってたよ。

301:デフォルトの名無しさん
08/05/29 23:55:42
「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする

302:デフォルトの名無しさん
08/05/30 00:39:26
>組み込みで使うとかいわれても幅が広くてわかりにくいんだが

幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。

303:デフォルトの名無しさん
08/05/30 01:27:45
>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。

正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。

304:デフォルトの名無しさん
08/05/30 01:42:25
アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。

305:デフォルトの名無しさん
08/05/30 18:08:50
C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。

- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)

306:デフォルトの名無しさん
08/05/30 18:09:21
C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。

自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変

307:デフォルトの名無しさん
08/05/30 21:23:52
さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい

308:デフォルトの名無しさん
08/05/30 21:38:24
C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。

309:デフォルトの名無しさん
08/05/30 21:53:45
ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。

310:デフォルトの名無しさん
08/05/30 21:56:59
>>308
どのレスの話？

311:デフォルトの名無しさん
08/05/30 22:19:31
>>308 それは言語の欠点ではなく俺の欠点だ。

>>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。
しかしこれ以外の本よく読んでいる。

コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。
そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。
さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。

C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。

312:デフォルトの名無しさん
08/05/30 22:30:05
>>305
>逆にこれらを使わなければ

C でオケ

313:デフォルトの名無しさん
08/05/30 23:15:52
>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。

314:デフォルトの名無しさん
08/05/30 23:57:34
Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。

315:デフォルトの名無しさん
08/05/31 01:04:39
抽象化＝クラスと信じて疑わないのがきもい

316:デフォルトの名無しさん
08/05/31 01:25:34
>>312, >>313

>>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。
後は徐々に使う機能を増やしていけばよい。
特にデストラクタの利用は効果的だ。

317:デフォルトの名無しさん
08/05/31 02:27:19
>>313

実は>>305は最後の項を除くと割りと簡単にルールを説明できる。

- コンストラクタ、デストラクタ、非 static メンバー関数を定義しない
- 多重継承を使わない
- 演算子 .* と ->* を使わない
- try, catch, throw を使わない
- inline 関数を定義しない
- template を使わない

最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。

318:デフォルトの名無しさん
08/05/31 03:05:12
>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。

ﾜﾗﾀw

319:デフォルトの名無しさん
08/05/31 04:46:23
・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。

でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな
共同作業時の問題とか考えると尚更なあ
OOPの幻想
デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司
JavaScriptなんて素人の言語だとか時代遅れな事いいやがって
手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う
間違った仕様書いといて実装に逆切れしやがって　徹夜して直すと自己管理ミスとかもうね
原付のブレーキ切ったろか
切るべきか　切るべきだな　けけけけけけ

>>316
ﾜﾗ太

320:デフォルトの名無しさん
08/05/31 05:15:39
C++否定側の皮肉なジョークだろ？>>305,>>316

321:デフォルトの名無しさん
08/05/31 14:01:59
すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。

322:デフォルトの名無しさん
08/05/31 19:51:13
>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。

323:デフォルトの名無しさん
08/05/31 20:09:07
>>320 決してジョークではない

今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。
- 生成されるコードが大きくて遅い(例えベターCとして使っても)
- 暗黙の処理によって生成されるコードやリソースが予想しにくい

コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを
C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。
(ただし最適化の出来が悪いとそうならないときがある)
しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを
エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。

予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。

- うっかりミスの防止する機能
非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照

- プログラムを組織化し、大規模化しやすくする機能
継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間

- あれば便利、見通しをよくする機能
関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名

これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。

324:デフォルトの名無しさん
08/05/31 20:21:23
>>323
>決してジョークではない

ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ

325:デフォルトの名無しさん
08/05/31 20:26:55
なら見るのを止めるのがおすすめ

326:デフォルトの名無しさん
08/05/31 20:30:07
やっぱりネタかよw

327:デフォルトの名無しさん
08/05/31 20:34:48
C++を知らないから使っていないんだという前提が痛過ぎる

328:デフォルトの名無しさん
08/05/31 20:40:41
>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?

329:デフォルトの名無しさん
08/05/31 20:46:37
ここはC++を無理矢理Cとして使うスレだっけ?

330:デフォルトの名無しさん
08/05/31 21:28:23
いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。

普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。

331:デフォルトの名無しさん
08/05/31 21:36:05
時折Objective-Cを思い出しては、絶望するスレ。

332:デフォルトの名無しさん
08/05/31 22:17:11
ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね

333:デフォルトの名無しさん
08/05/31 22:18:00
字面がｷﾓすぎ

334:デフォルトの名無しさん
08/05/31 22:25:31
事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える

C++やC#とは狙いが違う感じ

335:デフォルトの名無しさん
08/05/31 22:26:07
ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。

336:デフォルトの名無しさん
08/05/31 22:28:02
どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど

337:デフォルトの名無しさん
08/05/31 22:30:24
>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ

338:デフォルトの名無しさん
08/05/31 22:44:40
C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。

339:デフォルトの名無しさん
08/05/31 23:03:54
Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?

340:デフォルトの名無しさん
08/05/31 23:05:18
どのルート？

341:デフォルトの名無しさん
08/05/31 23:09:53
Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。

342:デフォルトの名無しさん
08/05/31 23:12:46
C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。

343:デフォルトの名無しさん
08/06/01 00:06:27
CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要

344:デフォルトの名無しさん
08/06/01 00:08:52
VCは要らん

345:デフォルトの名無しさん
08/06/01 00:42:17
>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。

346:321
08/06/01 11:47:24
>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。

347:デフォルトの名無しさん
08/06/01 12:01:43
間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。

348:デフォルトの名無しさん
08/06/01 13:00:25
C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。

349:デフォルトの名無しさん
08/06/01 14:36:50
Why I No Longer Like or Use C++
URLﾘﾝｸ(www.hyuki.com)

350:デフォルトの名無しさん
08/06/01 14:55:59
>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。

351:デフォルトの名無しさん
08/06/01 15:00:47
>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。

352:デフォルトの名無しさん
08/06/01 15:03:35
原文のほう見ると
URLﾘﾝｸ(prophipsi.blogspot.com)
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。

353:デフォルトの名無しさん
08/06/01 15:07:09
うーん、やはり見えない敵と戦うタイプだな。
いっそこのスレに呼べばいいんじゃないか？
Another common theme among the posters was that one can get by just
fine in C++ by ignoring the more complicated aspects of C++ and just
focusing on the basic procedural and object oriented features of C++.
In practice this means never touching templates and focusing on class
and function based abstractions. I guess use of exceptions and MI
would be optional and handled on a case by case basis.

I actually don't have a problem going this route. The problem is that
this is NOT the route that the C++ standards people are going and it
certainly isn't the route the C++ literati/intelligentsia are going.

354:デフォルトの名無しさん
08/06/01 15:50:27
>>351

>言語が単純で、枯れていて、速くて、資産が沢山あって、
>スクリプト言語との連携が良いからだよ。

>>317で残った部分は十分に単純で枯れているぞ。
そして速さはCと同じでCとC++の資産も使えるぞ。
スクリプト言語との連携もインタフェース部分だけ
extern "C" すればいいぞ。

>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?

355:デフォルトの名無しさん
08/06/01 16:11:02
「残った部分」とかんな抽象的な。

言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。

356:デフォルトの名無しさん
08/06/01 16:23:52
>>354
>>>317で残った部分は十分に単純で枯れているぞ。

もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。

357:デフォルトの名無しさん
08/06/01 16:27:45
もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。

358:デフォルトの名無しさん
08/06/01 16:32:12
>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる

それならCのほうがずっといい
無論C99ではなくC89な

359:デフォルトの名無しさん
08/06/01 16:40:41
10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。

360:デフォルトの名無しさん
08/06/01 18:44:34
>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。

「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265

>これ禁止なら素直にCを使ったほうが早い。

個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。

361:デフォルトの名無しさん
08/06/01 18:45:01
>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる

まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。

362:デフォルトの名無しさん
08/06/01 19:35:33
> ABIの問題はC++の利点に比べれば小さいことだと思ってる。

いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。

C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。

363:デフォルトの名無しさん
08/06/01 23:48:27
>>362

>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。

ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。

>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。

COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。

364:デフォルトの名無しさん
08/06/02 19:50:18
>>363
>チームメンバの問題はそれほど深刻ではないと思っている。

君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。

365:デフォルトの名無しさん
08/06/02 22:13:53
結局Ｃは現役続行てことでおｋ？

366:デフォルトの名無しさん
08/06/02 22:38:52
今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？

367:デフォルトの名無しさん
08/06/02 23:03:35
なんか抽象化の方策でもあるのか？

368:デフォルトの名無しさん
08/06/03 01:41:34
>>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。

何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。

369:デフォルトの名無しさん
08/06/03 01:44:25
クソコードをチェックしてくれるデバッガーを大量に雇う

370:デフォルトの名無しさん
08/06/03 01:55:16
そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ

371:デフォルトの名無しさん
08/06/03 02:08:16
>>370
御大のお言葉をよくお聴きなされ

URLﾘﾝｸ(www.research.att.com)

> "To the best of my knowledge EC++ is dead (2004),
> and if it isn't it ought to be."

try, catch, throw を使わない、template を使わない、
多重継承を使わない C++ のサブセットなんてダメだってさ。

372:デフォルトの名無しさん
08/06/03 12:37:11
>>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。

373:デフォルトの名無しさん
08/06/03 18:00:11
embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん

374:デフォルトの名無しさん
08/06/03 21:17:58
小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。

375:デフォルトの名無しさん
08/06/03 22:33:22
EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん

376:デフォルトの名無しさん
08/06/04 00:53:36
確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。

377:デフォルトの名無しさん
08/06/04 03:30:33
某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる

378:デフォルトの名無しさん
08/06/04 09:21:02
>>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない

379:デフォルトの名無しさん
08/06/04 20:07:08
>>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする

これら以外の目的で削られた機能って具体的にどれの事を言ってるの？

380:デフォルトの名無しさん
08/06/05 01:26:39
378じゃないけど namespace
削った目的は分からない。

リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。

381:デフォルトの名無しさん
08/06/05 02:13:47
namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？

382:デフォルトの名無しさん
08/06/05 03:17:22
>>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ

383:デフォルトの名無しさん
08/06/05 20:30:38
必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。

384:デフォルトの名無しさん
08/06/06 22:50:16
const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。

385:デフォルトの名無しさん
08/06/07 00:21:26
組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。

386:デフォルトの名無しさん
08/06/07 09:42:06
コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。

387:デフォルトの名無しさん
08/06/07 14:12:32
>>386
>コンパイラを実装する人の都合

これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。

388:デフォルトの名無しさん
08/06/07 14:33:41
C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。

389:デフォルトの名無しさん
08/06/07 14:40:43
>>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？

390:デフォルトの名無しさん
08/06/07 14:46:31
いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。

391:デフォルトの名無しさん
08/06/07 18:17:24
高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?

392:デフォルトの名無しさん
08/06/07 18:20:30
それを更に C で wrap して Fortran から呼び出したらいいんじゃない？

393:デフォルトの名無しさん
08/06/08 00:59:14
>388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。

算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。

394:デフォルトの名無しさん
08/06/08 01:10:18
>>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？

395:デフォルトの名無しさん
08/06/08 01:42:38
微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。

396:デフォルトの名無しさん
08/06/08 02:15:24
そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな

397:デフォルトの名無しさん
08/06/08 03:58:14
秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない

398:デフォルトの名無しさん
08/06/08 18:23:42
楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。

399:デフォルトの名無しさん
08/06/08 18:29:53
Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ

C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう

400:デフォルトの名無しさん
08/06/08 18:52:01
ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。

401:デフォルトの名無しさん
08/06/08 18:57:26
Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。

402:デフォルトの名無しさん
08/06/08 19:27:12
>>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？

403:デフォルトの名無しさん
08/06/08 19:37:58
PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。

404:デフォルトの名無しさん
08/06/09 22:52:58
スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。

405:デフォルトの名無しさん
08/06/11 18:53:28
CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。

406:デフォルトの名無しさん
08/06/11 19:06:05
C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが

407:デフォルトの名無しさん
08/06/11 20:31:32
逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?

408:デフォルトの名無しさん
08/06/11 20:41:02
JavaやC#の限界ってなんのこと？

409:デフォルトの名無しさん
08/06/11 21:09:19
VMの外の人と話せないこととか

410:デフォルトの名無しさん
08/06/11 21:49:55
つ JNI

411:デフォルトの名無しさん
08/06/11 21:57:42
むしろＣ＋＋が再評価ってなんのこと？？？

412:デフォルトの名無しさん
08/06/12 09:27:16
C++/CLIのことだろう

413:デフォルトの名無しさん
08/06/12 11:00:04
>>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。

414:デフォルトの名無しさん
08/06/13 18:10:15
Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。

415:デフォルトの名無しさん
08/06/13 19:05:32
1 行目と 2 行目以降は全く関係無いね

416:デフォルトの名無しさん
08/06/13 21:16:58
役立たないとはっきり書いてほしかったのかな?

417:デフォルトの名無しさん
08/06/13 21:18:29
自己紹介には及ばん

418:デフォルトの名無しさん
08/06/14 17:00:28
アセンブラから見てCってどうなの？

419:デフォルトの名無しさん
08/06/14 17:08:30
ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。

420:デフォルトの名無しさん
08/06/14 17:10:57
C99 か GCC でオケ

421:デフォルトの名無しさん
08/06/14 17:14:18
#define INLINE _inline

422:デフォルトの名無しさん
08/06/14 17:26:15
#pragma inline 使うコンパイラがあるので #define だけではすまない。

423:デフォルトの名無しさん
08/06/15 00:49:57
そこで_Pragma演算子よ、って結局C99というオチ。

424:デフォルトの名無しさん
08/06/15 00:55:33
C++

425:デフォルトの名無しさん
08/06/15 13:00:19
C以外の中級言語つくろうって動きはないのかね

426:デフォルトの名無しさん
08/06/15 13:44:05
Dは無視ですか、そうですか

427:デフォルトの名無しさん
08/06/15 15:36:22
C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。

428:デフォルトの名無しさん
08/06/15 15:43:45
そういやそんなのあったな・・・全く守ってねーや

429:デフォルトの名無しさん
08/06/15 16:49:15
>>427
もっともC++処理系自体にはポータビリティがないがなw

430:デフォルトの名無しさん
08/06/15 17:03:02
きっと処理系のできは時間が解決してくれるよ。

431:デフォルトの名無しさん
08/06/15 17:05:51
もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…

432:デフォルトの名無しさん
08/06/15 18:24:16
今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?

433:デフォルトの名無しさん
08/06/18 15:20:55
>>431
B言語でもやってろ

434:デフォルトの名無しさん
08/06/18 15:55:05
C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。

- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
　生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す

インライン関数があれば最初の方法が現実的かな。

435:デフォルトの名無しさん
08/06/18 16:40:50
- 一度定めた構造体の定義に対して互換性がなくなるような変更をしない

436:デフォルトの名無しさん
08/06/18 18:13:08
>>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな

437:デフォルトの名無しさん
08/06/18 19:18:44
何か無理やりOOをやりたいのか？C++じゃないんだが。

438:デフォルトの名無しさん
08/06/18 20:03:38
>>434
拡張子をだなcppに変えて（ｒｙ

439:デフォルトの名無しさん
08/06/18 20:44:55
>>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。

440:デフォルトの名無しさん
08/06/18 23:57:02
>>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。

441:デフォルトの名無しさん
08/06/19 00:38:02
>>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？

ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。

442:デフォルトの名無しさん
08/06/19 00:45:25
RAMが16Kbyteもあるなんて贅沢だw

443:デフォルトの名無しさん
08/06/19 01:07:40
オブジェクト指向は言語と直行した概念だから C で OOP しても何の問題も無い。
構文の助けが無い分、面倒臭いのは我慢する必要があるけど。

URLﾘﾝｸ(www.gnome.gr.jp)
Wikipedia項目ﾘﾝｸ
URLﾘﾝｸ(www.sage-p.com)

シンプルな C に多少のルールを追加するのと、カオスな C++ から便利機能を
削除するのは別次元の話だと思うよ。

444:デフォルトの名無しさん
08/06/19 02:07:30
C++はいらないけど、C++コンパイラは必要。

CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。

445:デフォルトの名無しさん
08/06/19 02:11:53
>>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。

446:デフォルトの名無しさん
08/06/19 02:22:14
CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。

447:デフォルトの名無しさん
08/06/19 02:28:21
Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。

URLﾘﾝｸ(users.pandora.be)

C++ より Objective-C の方が C の発想に近いよね。

448:デフォルトの名無しさん
08/06/19 02:35:35
URLﾘﾝｸ(grape.mtk.nao.ac.jp)

ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。

449:デフォルトの名無しさん
08/06/19 02:42:51
「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。

450:デフォルトの名無しさん
08/06/19 02:46:57
>>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。

構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。

次ページ