- 1 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 20:11:42 ]
- どうすればいい？
- 357 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 16:27:45 ]
- もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。
- 358 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 16:32:12 ]
- >>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる
それならCのほうがずっといい
無論C99ではなくC89な
- 359 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 16:40:41 ]
- 10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。
- 360 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 18:44:34 ]
- >>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265
>これ禁止なら素直にCを使ったほうが早い。
個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。
- 361 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 18:45:01 ]
- >>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる
まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。
- 362 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 19:35:33 ]
- > ABIの問題はC++の利点に比べれば小さいことだと思ってる。
いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。
C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
- 363 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 23:48:27 ]
- >>362
>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。
ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。
>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。
- 364 名前：デフォルトの名無しさん mailto:sage [2008/06/02(月) 19:50:18 ]
- >>363
>チームメンバの問題はそれほど深刻ではないと思っている。
君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。
- 365 名前：デフォルトの名無しさん mailto:sage [2008/06/02(月) 22:13:53 ]
- 結局Ｃは現役続行てことでおｋ？
- 366 名前：デフォルトの名無しさん mailto:sage [2008/06/02(月) 22:38:52 ]
- 今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？
- 367 名前：デフォルトの名無しさん mailto:sage [2008/06/02(月) 23:03:35 ]
- なんか抽象化の方策でもあるのか？
- 368 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 01:41:34 ]
- >>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。
何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。
- 369 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 01:44:25 ]
- クソコードをチェックしてくれるデバッガーを大量に雇う
- 370 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 01:55:16 ]
- そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ
- 371 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 02:08:16 ]
- >>370
御大のお言葉をよくお聴きなされ
www.research.att.com/~bs/bs_faq.html#EC++
> "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 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 12:37:11 ]
- >>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。
- 373 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 18:00:11 ]
- embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん
- 374 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 21:17:58 ]
- 小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。
- 375 名前：デフォルトの名無しさん mailto:sage [2008/06/03(火) 22:33:22 ]
- EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん
- 376 名前：デフォルトの名無しさん mailto:sage [2008/06/04(水) 00:53:36 ]
- 確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。
- 377 名前：デフォルトの名無しさん mailto:sage [2008/06/04(水) 03:30:33 ]
- 某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる
- 378 名前：デフォルトの名無しさん mailto:sage [2008/06/04(水) 09:21:02 ]
- >>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない
- 379 名前：デフォルトの名無しさん mailto:sage [2008/06/04(水) 20:07:08 ]
- >>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする
これら以外の目的で削られた機能って具体的にどれの事を言ってるの？
- 380 名前：デフォルトの名無しさん mailto:sage [2008/06/05(木) 01:26:39 ]
- 378じゃないけど namespace
削った目的は分からない。
リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。
- 381 名前：デフォルトの名無しさん mailto:sage [2008/06/05(木) 02:13:47 ]
- namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？
- 382 名前：デフォルトの名無しさん mailto:sage [2008/06/05(木) 03:17:22 ]
- >>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ
- 383 名前：デフォルトの名無しさん mailto:sage [2008/06/05(木) 20:30:38 ]
- 必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。
- 384 名前：デフォルトの名無しさん mailto:sage [2008/06/06(金) 22:50:16 ]
- const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。
- 385 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 00:21:26 ]
- 組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。
- 386 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 09:42:06 ]
- コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。
- 387 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 14:12:32 ]
- >>386
>コンパイラを実装する人の都合
これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。
- 388 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 14:33:41 ]
- C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。
- 389 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 14:40:43 ]
- >>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？
- 390 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 14:46:31 ]
- いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。
- 391 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 18:17:24 ]
- 高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?
- 392 名前：デフォルトの名無しさん mailto:sage [2008/06/07(土) 18:20:30 ]
- それを更に C で wrap して Fortran から呼び出したらいいんじゃない？
- 393 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 00:59:14 ]
- >388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。
算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。
- 394 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 01:10:18 ]
- >>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？
- 395 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 01:42:38 ]
- 微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。
- 396 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 02:15:24 ]
- そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな
- 397 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 03:58:14 ]
- 秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない
- 398 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 18:23:42 ]
- 楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。
- 399 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 18:29:53 ]
- Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ
C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう
- 400 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 18:52:01 ]
- ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。
- 401 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 18:57:26 ]
- Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。
- 402 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 19:27:12 ]
- >>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？
- 403 名前：デフォルトの名無しさん mailto:sage [2008/06/08(日) 19:37:58 ]
- PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。
- 404 名前：デフォルトの名無しさん mailto:sage [2008/06/09(月) 22:52:58 ]
- スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。
- 405 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 18:53:28 ]
- CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。
- 406 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 19:06:05 ]
- C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが
- 407 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 20:31:32 ]
- 逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?
- 408 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 20:41:02 ]
- JavaやC#の限界ってなんのこと？
- 409 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 21:09:19 ]
- VMの外の人と話せないこととか
- 410 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 21:49:55 ]
- つ JNI
- 411 名前：デフォルトの名無しさん mailto:sage [2008/06/11(水) 21:57:42 ]
- むしろＣ＋＋が再評価ってなんのこと？？？
- 412 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 09:27:16 ]
- C++/CLIのことだろう
- 413 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 11:00:04 ]
- >>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。
- 414 名前：デフォルトの名無しさん mailto:sage [2008/06/13(金) 18:10:15 ]
- Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。
- 415 名前：デフォルトの名無しさん mailto:sage [2008/06/13(金) 19:05:32 ]
- 1 行目と 2 行目以降は全く関係無いね
- 416 名前：デフォルトの名無しさん mailto:sage [2008/06/13(金) 21:16:58 ]
- 役立たないとはっきり書いてほしかったのかな?
- 417 名前：デフォルトの名無しさん mailto:sage [2008/06/13(金) 21:18:29 ]
- 自己紹介には及ばん
- 418 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 17:00:28 ]
- アセンブラから見てCってどうなの？
- 419 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 17:08:30 ]
- ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。
- 420 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 17:10:57 ]
- C99 か GCC でオケ
- 421 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 17:14:18 ]
- #define INLINE _inline
- 422 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 17:26:15 ]
- #pragma inline 使うコンパイラがあるので #define だけではすまない。
- 423 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 00:49:57 ]
- そこで_Pragma演算子よ、って結局C99というオチ。
- 424 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 00:55:33 ]
- C++
- 425 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 13:00:19 ]
- C以外の中級言語つくろうって動きはないのかね
- 426 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 13:44:05 ]
- Dは無視ですか、そうですか
- 427 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 15:36:22 ]
- C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。
- 428 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 15:43:45 ]
- そういやそんなのあったな・・・全く守ってねーや
- 429 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 16:49:15 ]
- >>427
もっともC++処理系自体にはポータビリティがないがなw
- 430 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 17:03:02 ]
- きっと処理系のできは時間が解決してくれるよ。
- 431 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 17:05:51 ]
- もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…
- 432 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 18:24:16 ]
- 今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?
- 433 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 15:20:55 ]
- >>431
B言語でもやってろ
- 434 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 15:55:05 ]
- C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。
- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す
インライン関数があれば最初の方法が現実的かな。
- 435 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 16:40:50 ]
- - 一度定めた構造体の定義に対して互換性がなくなるような変更をしない
- 436 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 18:13:08 ]
- >>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな
- 437 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 19:18:44 ]
- 何か無理やりOOをやりたいのか？C++じゃないんだが。
- 438 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 20:03:38 ]
- >>434
拡張子をだなcppに変えて（ｒｙ
- 439 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 20:44:55 ]
- >>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。
- 440 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 23:57:02 ]
- >>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。
- 441 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 00:38:02 ]
- >>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？
ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。
- 442 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 00:45:25 ]
- RAMが16Kbyteもあるなんて贅沢だw
- 443 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 01:07:40 ]
- オブジェクト指向は言語と直行した概念だから C で OOP しても何の問題も無い。
構文の助けが無い分、面倒臭いのは我慢する必要があるけど。
www.gnome.gr.jp/docs/glib-2.2.x-refs/gobject/pr01.html
ja.wikipedia.org/wiki/Core_Foundation
www.sage-p.com/process/cool.htm
シンプルな C に多少のルールを追加するのと、カオスな C++ から便利機能を
削除するのは別次元の話だと思うよ。
- 444 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:07:30 ]
- C++はいらないけど、C++コンパイラは必要。
CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。
- 445 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:11:53 ]
- >>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。
- 446 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:22:14 ]
- CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。
- 447 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:28:21 ]
- Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。
users.pandora.be/stes/compiler.html
C++ より Objective-C の方が C の発想に近いよね。
- 448 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:35:35 ]
- grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html
ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。
- 449 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:42:51 ]
- 「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。
- 450 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:46:57 ]
- >>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。
構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。
- 451 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:52:50 ]
- >>449
リンク先を読めば意図は分かると思うけど、気になるなら
「New Jersey アプローチ」と読み替えても良いよ。
- 452 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:59:11 ]
- Java も「悪い方がよい」原則のような気がする。
- 453 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 03:23:24 ]
- >>451
>>449をよく読めば意図が分かると思うけど、気になるなら
「悪いものが定着したときは「New Jersey アプローチ」って言えばいいんだから」
と読み替えても伊井よ
- 454 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 03:30:42 ]
- それ元ネタが凝った角度でモノ書こうとして失敗してる例に感じるな
タイトル先行で書き下されたかのような。
完璧を求めると複雑巨大になり弊害がある
単純さを求めると完全ではなくなり弊害がある
一長一短って話だろ なんでworse is betterやねん
- 455 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 08:29:56 ]
- >>454
>一長一短って話だろ
違うよ。Lisper が Lisper に向けて何故 Lisp 族が失敗したかを考察した文章で、
Lisp は敗北したという前提だから、一長一短ではなく Worse Is Better なの。
www.kt.rim.or.jp/~hisashim/gabriel/WorseIsBetter.ja.html
- 456 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 17:50:52 ]
- あ、なるほど。その文書読んでから読み直すと少し納得
少なくともタイトル先行な面白書きではない訳ですな
で、改めて読み直してみたけど、やっぱり俺には誤解が残る
Lispの造型が足りないせいか、頭が足りないせいかな
- 457 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 20:59:37 ]
- LISPの造型が足りないというのは、カッコの数が少なすぎるということかな？
|
 |
