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

1 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 20:11:42 ] どうすればいい？ 313 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 23:15:52 ] >>312 だな。>>305をコーディング規約にでも書いた日には 「Cでいいじゃねえか!!」と言われそう。 314 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 23:57:34 ] Cがこれだけ普及したのは、あまり抽象化しなかったから。 このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。 基本的に無理筋なんだ。 315 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 01:04:39 ] 抽象化＝クラスと信じて疑わないのがきもい 316 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 01:25:34 ] >>312, >>313 >>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。 さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。 後は徐々に使う機能を増やしていけばよい。 特にデストラクタの利用は効果的だ。 317 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 02:27:19 ] >>313 実は>>305は最後の項を除くと割りと簡単にルールを説明できる。 - コンストラクタ、デストラクタ、非 static メンバー関数を定義しない - 多重継承を使わない - 演算子 .* と ->* を使わない - try, catch, throw を使わない - inline 関数を定義しない - template を使わない 最後の項は基本的にうれしいことなので、あえて使いたくないときは extern を使うなり、アドレスを取得するなりすればよい。 318 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 03:05:12 ] >>316 >Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。 ﾜﾗﾀw 319 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 04:46:23 ] ・安全で ・保守が用意 共にどこまで把握したことを活用できるか、という問題じゃん？ 煽り地味た笑いは早計かと思ふ。 でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな 共同作業時の問題とか考えると尚更なあ OOPの幻想 デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司 JavaScriptなんて素人の言語だとか時代遅れな事いいやがって 手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う 間違った仕様書いといて実装に逆切れしやがって　徹夜して直すと自己管理ミスとかもうね 原付のブレーキ切ったろか 切るべきか　切るべきだな　けけけけけけ >>316 ﾜﾗ太 320 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 05:15:39 ] C++否定側の皮肉なジョークだろ？>>305,>>316 321 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 14:01:59 ] すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、 「新規の言語はすべて旧来の言語のアンチテーゼ」 ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。 新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。 「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・ 考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。 322 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:51:13 ] >>321 駆逐されたと言う基準はなんだ? COBOLやFORTRANは駆逐されたのか? 君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。 323 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:09:07 ] >>320 決してジョークではない 今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。 - 生成されるコードが大きくて遅い(例えベターCとして使っても) - 暗黙の処理によって生成されるコードやリソースが予想しにくい コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。 (ただし最適化の出来が悪いとそうならないときがある) しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。 予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。 - うっかりミスの防止する機能 非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照 - プログラムを組織化し、大規模化しやすくする機能 継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間 - あれば便利、見通しをよくする機能 関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名 これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。 そしてプログラムを安全にし保守を容易にする。 324 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:21:23 ] >>323 >決してジョークではない ジョークじゃないなら、そろそろ終わりにしなよ 見ていて辛いわ 325 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:26:55 ] なら見るのを止めるのがおすすめ 326 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:30:07 ] やっぱりネタかよw 327 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:34:48 ] C++を知らないから使っていないんだという前提が痛過ぎる 328 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:40:41 ] >>323 所で、VC++の最適化にはすばらしいものを感じているが。 今のC言語にあそこまでに最適化があるのか？ 無ければ、VC++でCらしく書いたほうが優秀と思われ。 VCのはいたASM見たこと有る? 329 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:46:37 ] ここはC++を無理矢理Cとして使うスレだっけ? 330 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 21:28:23 ] いくらなんでも、非静的メンバ関数の使用はありだろ。 暗黙の引数thisが予想できないというのが理解できない。 普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。 むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。 331 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 21:36:05 ] 時折Objective-Cを思い出しては、絶望するスレ。 332 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:17:11 ] ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね 333 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:18:00 ] 字面がｷﾓすぎ 334 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:25:31 ] 事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える C++やC#とは狙いが違う感じ 335 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:26:07 ] ここのC++厨はPC上で動くアプリしか作ったことないんだろ。 秋月のキットでも買って出直してこいよ。 336 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:28:02 ] どんな言語でも見た目が気になるのは初学者のうちだけだよ 文法がまずいとそうもいかないけど 337 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:30:24 ] >>335 恐らくウィンドウズ以外の経験が全く無いんだろうさ 338 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:44:40 ] C を駆逐出来るのは C だけだな。C++ は失敗作。 誰か C 1x の仕様策定プロセスを始めてくれないかな。 339 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:03:54 ] Cから発生した言語は、みんなそのルートを通る。 いまさら新しいCを作ってどうする? 340 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:05:18 ] どのルート？ 341 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:09:53 ] Cを継承する、拡張する、駆逐する、いわゆる後継のために。 C++も最初はCにクラスが付いただけの言語だった。 342 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:12:46 ] C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。 343 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:06:27 ] CはC99で失敗したからもう発展しない。 VCはC99未対応、gccは -std=c99 が必要 344 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:08:52 ] VCは要らん 345 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:42:17 ] >>328 さすがにCとC++の最適化ルーチンは共通化しているでしょう。 疑いもしていないので調べたことはないけど。 346 名前：321 mailto:sage [2008/06/01(日) 11:47:24 ] >>322 曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。 ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。 レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。 #答えよう。自分はFORTRANより年上だ。 347 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 12:01:43 ] 間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。 つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。 348 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 13:00:25 ] C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。 「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。 あの会社の立場上難しいだろうけど。 349 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 14:36:50 ] Why I No Longer Like or Use C++ ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus 350 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 14:55:59 ] >>349 C++ではなくCを使う理由にはなっていないんだよ。 環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。 351 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 15:00:47 ] >>350 言語が単純で、枯れていて、速くて、資産が沢山あって、 スクリプト言語との連携が良いからだよ。Cでなければ いけない理由は無いが、C以外にそんな言語は無いからな。 352 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 15:03:35 ] 原文のほう見ると prophipsi.blogspot.com/2008/03/why-i-no-longer-like-or-use-c.html このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。 353 名前：デフォルトの名無しさん mailto:sage [2008/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 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 15:50:27 ] >>351 >言語が単純で、枯れていて、速くて、資産が沢山あって、 >スクリプト言語との連携が良いからだよ。 >>317で残った部分は十分に単純で枯れているぞ。 そして速さはCと同じでCとC++の資産も使えるぞ。 スクリプト言語との連携もインタフェース部分だけ extern "C" すればいいぞ。 >C以外にそんな言語は無いからな。 さらに>>323の機能を使えば安全で便利だぞ。 C++もそういう言語として使えるんじゃないか? 355 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 16:11:02 ] 「残った部分」とかんな抽象的な。 言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。 毎回チェックするのも大変だし。 >>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで これ禁止なら素直にCを使ったほうが早い。 356 名前：デフォルトの名無しさん mailto:sage [2008/06/01(日) 16:23:52 ] >>354 >>>317で残った部分は十分に単純で枯れているぞ。 もう 317 は忘れろ。二度と俺にその話を振るな。 誰も賛同しない物を何でここまで引っ張るかね。 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 あれ便利っつーか楽っつーか、確かにいいんだけど 言語仕様としては究極の汚さだよなあ。

---

---

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

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