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

1 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 20:11:42 ] どうすればいい？ 101 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 14:53:21 ] それどうやってコンパイルしたんだろ 手か 俺は絶対に嫌だが 102 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 14:55:07 ] つ　bootstrap 103 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:00:24 ] 我々はもう既にオブジェクト指向から拡張した新たなるパラダイムに接している。 ただ気付いていないだけだ。 Extension Method や Generic を見ているとわかる。 継承と多態では表現できない世界に入り込んでしまっている。 皆さん、新たなるパラダイムにようこそ。 104 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:09:09 ] ここだけ 1990 年代のスレですか? 105 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:36:58 ] JavaChip上でJavaOSが動けばCも捨てられるんだろうけどね でも結局、最後はマシン語の世界に降りていかないといけないだろうし そうなったら最後は高級アセンブラであるところのCに頼らざるをえない。 106 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:38:52 ] だからもっとまともな高級アセンブラが欲しいって話じゃないのか 107 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 15:51:51 ] D言語があるじゃまいか！ 108 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 16:08:58 ] 皆に黙殺されるD言語 109 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 18:50:50 ] 真のオブジェクト指向言語はLOGO 110 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:40:39 ] Objective-D++が有れば最強……かも。 111 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 23:01:18 ] >99 最初のC++の実装は、確かCへのトランスレータじゃなかったっけかな。 国内でもPC向けのC++実装はトランスレータの時代があった。MIWA C++とかさ。 112 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 23:15:47 ] C++は生れた時から今までずっと、C with class だろ？ CとC++で、OOなコードを書こうとする時、コード量が増える以外の 違いってあるのかな？ 113 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 00:11:27 ] >>99-101 「最初のC++コンパイラはC with Classesで書かれた」が答えというオチ？ 114 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 12:10:39 ] Zortech C++ のバージョン1使ってたぞ。Cへのトランスレータだった ちなみに作者はWalter Bright Dの作者でもある 115 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 13:35:53 ] Zortech C++は最初からトランスレータじゃなくてnative compilerだったと 思うけど。PC向けに国内で初めて手に入ったnative compilerってことで俺も 買って、そして余りのバギーさに枕を濡らした記憶がある。 116 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:34:49 ] 仮想関数があるとパフォーマンス落ちるから継承がある言語はCの代わりにはなれないな。 117 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:45:17 ] パフォーマンス(笑) 118 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:47:50 ] あんたの笑いのツボはよく分からんな 119 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:50:04 ] エンドユーズに限りなく近いデベロッパならC++/C#/Javaで十分ですよ。 Java7はビデオデコード機能がFlashやSilverlightに追いつくらしくて期待してる。 後はゲーム系インタフェースさえ標準化されればJavaだけでいいのに。 120 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:54:48 ] Java(笑) 121 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:16:42 ] 継承無しのクラスに価値はあるのか？ 122 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:18:04 ] 継承はクズ。これからは委譲。 123 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:19:55 ] オブジェクト指向を根本から否定かよ。 124 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:35:13 ] >>120 C言語（笑） お前のやってる手法は根拠レスでチープな行為だ。 125 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:35:35 ] なぜ継承がクズかkwsk 126 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:40:23 ] >>123 delegationも立派なオブジェクト指向の手法。継承だけがOOPLじゃないのよ。 >>125 オブジェクトの関係を固定してしまうから変化に弱い。 127 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:42:18 ] >>126 初心者の俺でも分かるようにもっとｋｗｓｋ 128 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:52:28 ] 仮想関数は実行時に差し替えることができない。だから継承しまくる デリゲートはそれができる。だから継承いらない 129 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:19:14 ] 処理の委譲とインタフェースの実装はまるで別な機能だろ。 ストリーム関係が継承を必要とする最もたる例だと思うが。 130 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:22:48 ] CとC++/C#/Javaなんて唯の兄弟喧嘩だろ しかも偉大な兄(C)を越えられない Cを駆逐するなら、全く別のアプローチしか無い 131 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:26:02 ] 超えようと機能を追加していったのがC++で、別のアプローチのつもりが 気がついたらナナメ上だったのがJAVAだと。 132 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:28:09 ] C言語なんてハードウェアよりじゃないかぎり使う方が馬鹿だと思うが。 133 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:30:32 ] つまり Apache はハードウェアよりと… 134 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:33:34 ] ハードウェア寄りじゃ無い場面で、Cの幻影を引き摺ってる言語を使ってる 時点でダメだよな。 135 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:35:09 ] 世間はそう思ってないみたいだが、どうなのよ？ 136 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:37:24 ] ちなみに Perl も Python も Ruby も SpiderMonkey も Tcl/Tk も C だよね 137 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:40:26 ] フリーの言語処理系だけ並べられても 138 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:40:42 ] >>134 Java が出なければ SML が主役になる筈だったと言ってる人が居たけど… 139 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:43:22 ] >>137 ハードウェアよりじゃない所で、実装言語を確認出来る良い例だから。 140 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:46:04 ] STLが無いってだけでC言語は糞だろ。 生産性の無い言語は現場から去るべき。 141 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:47:31 ] マルチプラットフォームでパフォーマンスが求められるとどうしてもCになるねえ しかし、それこそC言語のほうこそ、「FORTRANとCOBOLを完全に駆逐するためには」 とか日頃思ってるんじゃないかな。コンピュータの世界ではCはそんなに独占してる わけじゃないから 142 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:47:33 ] C++が糞じゃなかったらとっくに現場から去ってるって 143 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:48:26 ] PerlとTclはちょっと違うな。 Cも含めた闇鍋風バカ言語。もちろん良い意味で。 144 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:58:21 ] STLが無いと生産性の上らない>>140は現場から・・・ 145 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:00:52 ] >>144の苦しい言い訳とか、Cが如何に使えないかよくわかる。 146 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:01:11 ] STLなめんな。 147 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:03:09 ] 未だにテンプレート禁止のところもあるというのに 148 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:03:22 ] ちょ、子供の喧嘩は勘弁な 149 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:13:09 ] >>141 今やCの守備範囲とFortran,COBOLが生き残ってるところは、ほとんど被ってないからなぁ Fortanを駆逐するのは(可能がどうか別にして)Camlでいいと思うが、COBOLは何だろう？ 150 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:13:27 ] つーかこの急激なスレの伸びはなんなのよｗ 151 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:18:03 ] コレクションもなく文字列操作も冗長で正規表現も標準で無いとかふざけすぎ。 エラートラップをするにしてもエラーコードびっしりで冗長極まりない。 例外を使わせろよ。C++みたいにfinallyの無いなんちゃって仕様じゃない奴。 152 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 01:29:53 ] そこで組み込みスクリプト言語ですよ 153 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 02:02:19 ] >>151 finallyも使いやすいとは思えないけどな。 C#のusingとかDのscopeとかみたいな仕組みくらいのほうがいい。 C++デストラクタもまああり。 154 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 05:06:38 ] C++はネイチブ生成の宿命があるのに その場合エラー専用処理がものすごく非効率って問題が 155 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 09:01:09 ] >>153 んなもんケースによるだろ。 ケースによるのにfinallyがないのが糞なんだよ。 156 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 09:42:43 ] finally相当の機能なら、C++/CLIでついたんじゃなかったっけ? 157 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 10:34:32 ] まるでC++/CLIがC++の後継みたいな言い方だな 158 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 13:30:06 ] C++/CLIはC++じゃない 159 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 15:37:48 ] >>150 それだけみんなCに不満もってるってことだ。 総力を挙げて潰さないとこの業界に未来はないよ。 160 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 16:04:13 ] 形式仕様から、最終的にバイナリコード(FPGAベースのチップ向けの)を 生成する研究が実用化されれば、Cだけでなく、現状のほとんどの言語を使わなくなる。 プログラミングは、「問題領域向けのDSLを記述+DSLで動作記述」になるよ。 161 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:24:35 ] 問題領域向けのDSLを記述+DSLで動作記述 ↑ これのコンパイラは結局Cでかかれると。 162 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:27:14 ] 最近は言語処理系は関数型言語か C++ で書くのが流行の様だよ C++ がもう少しまともだったらな 163 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:29:28 ] コンパイラはリッチな環境の上で動かせるから選択肢の数が全然違う 164 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 20:57:24 ] C言語で開発しとけばなんかあったとき安心、見たいのがあるのかね？ 性能をどうしてもあと１０％上げなきゃいけない、なんてときもCなら何とかなるとか。 165 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:02:28 ] Cで書いた所でそれ程ハードルが高くなる訳じゃない 特に拘りがないだけじゃないの 166 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:33:09 ] 俺はCだとハードルかなり高くなる。 それで飛び越えられなくなるわけじゃないとしても、いちいち高めにジャンプしなきゃいけないのがむかつく。 167 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:47:37 ] コンパイラをCで書くとか、嗜虐癖があるとしか思えん 168 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 21:49:54 ] >>164 C で書いておけば色んな言語と混ぜられる。 C のルーチンを LL から呼び出すのは至極楽ちん。 169 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:07:14 ] 前にRubyからCのルーチン呼ぼうとしたらSWIGとかいうの使う羽目になった。 配列とか使ってたから、変換用のコーディングも若干必要になったし。 大変というほどでも無いが至極楽ちんというほど楽ちんでもないような。 170 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:15:07 ] CはLLのインラインアセンブラや〜 171 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 22:35:22 ] >>168 C#とPowerShellその他.NETなLLの親和性は異常 CというかシステムコールをOOなLLでラッピングとかもう面倒でやってらんない 172 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:56:55 ] 何でシステムコールが出てくる？ シスコール生で叩かせるLLなんてあるのか？ 173 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:57:26 ] >>171 そういえば、.NETってなんとなくスルーしてたなぁ。 趣味として使うとしたら学ぶ価値ある？ 普段はRuby使ってます。 174 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:58:22 ] >8 ＞Cのパフォーマンス これほんと？ 175 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:07:41 ] >>174 C だけ使えば C と同じ性能。 C++ でもよく使われる言い回し。 176 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 01:35:36 ] >>174 例えばある変数の値を、1から10000までカウントupみたいなのは、Cは高速。 理由はおおざっぱに言えば、処理時間=計算量*1計算あたりのクロック数　だから。 2次元テーブル(n行n列)の全スキャン計算量は、nの2乗に比例するからo(n^2)とか。 単純なカウントupの計算量は小さい。 一方、ライブラリに必ずしも無いもの(例:クロージャなど)が必要になると、 プログラマーがゼロから実装するのは負担が大きくて、他の方法で回避する。 回避策の計算量、1計算あたりのクロック数によっては、他の言語で記述した方が 早い場合もある。 ↓参考:プログラミング言語ベンチマーク ttp://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all 177 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:38:24 ] >>71 古い話で恐縮だけれども、ICOTの例のプロジェクトでは prolog の進化形で　**カーネルの大部分を** 記述していたとか。 そういう用途のシステムでは、そういう選択もあるようです。 ＃同じ研究を現在のハードウェア技術で行ったらどうなるのかつくづく知りたいものですが、あと 100 年はとりあげられないでしょうか‥‥‥。 178 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 02:43:57 ] >>88 人を変態よばわりしないでください。 R6RS準拠のコンパイラがでたんですって？ 179 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 08:35:10 ] Cに文句言うより86アセンブラをまず駆逐しろよ・・・ Intelでさえできなかったんだぞ 180 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 08:37:36 ] 今時のCPUはアセンブラ（≒機械語）を直接実行せずに 自前の命令に変換するんでしょ。 そんな内部コードを毎度毎度表にさらしてたら大混乱が起こるんじゃね。 AMDの人も命令コードなんて全然大した問題じゃないとか言ってたし。 181 名前：デフォルトの名無しさん mailto:sage [2008/05/15(木) 13:54:39 ] >173 > そういえば、.NETってなんとなくスルーしてたなぁ。 > 趣味として使うとしたら学ぶ価値ある？ プログラミングが趣味か、なんらかの成果物を完成させるのが趣味かで変わってくるんじゃ? ﾄﾞﾄﾈﾄ系はWindowsのアプリを作るということなら、死ぬほど楽なのは確か。 特にC#とC++/CLIの楽さは異常。 182 名前：173 mailto:sage [2008/05/15(木) 18:43:57 ] >>181 レスさんくす。 C#でもかじってみるか。 （そういえばIronRubyはどうなったんだ？とんと話を聞かないが。） 183 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 18:44:40 ] 開発言語をアセンブラからCに変えて解放されることって １．レジスタの管理 ２．メモリの管理 ３．スタックの管理 くらいかな？ こうやってみるとCって意外と面倒な問題を解決してくれてることに気づくｗ 184 名前：デフォルトの名無しさん [2008/05/16(金) 18:54:16 ] とりあえずage 185 名前：デフォルトの名無しさん [2008/05/16(金) 19:23:40 ] CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。 他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。 CにはOOだのGCだの必要なし。それはLLとかに任せればいい。 186 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:30:17 ] namespaceとstructに関数ぶら下げるのとoverloadがあると気分的にだいぶ楽になるな。 IDEとの親和性も爆上がるし。 187 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:42:34 ] >>185 ただ、cppにはもうちょっと賢くなってほしいけどなあ。 あ、でもあんまり賢すぎるとlispみたいになんでもマクロで書いちゃう 人が出てくるからダメかな。 188 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 00:00:28 ] >>183 Cはメモリーもスタックも管理しないだろ 189 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 00:07:03 ] 自動変数の事じゃないの 190 名前：183 mailto:sage [2008/05/17(土) 00:20:31 ] スタックの管理は自動変数、 メモリーの管理はmalloc&free,大域変数のつもりで書いた。 191 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 11:00:14 ] OO言語としてC++は置いといて高級アセンブラとしてCを凌駕する ポストC的な言語がほとんど話題にならない時点で結論が出ているわけだが。 192 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 12:10:51 ] c++を駆逐してほしいんだが 193 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 12:38:39 ] 学習コスト＜＜駆逐コスト 194 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:08:01 ] >>191 高級アセンブラが使われる環境を駆逐したいんじゃない？ 195 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:17:15 ] 入れ子が{}じゃなくて ポインタが*じゃないC言語ください 196 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:35:32 ] なぜ組み込みの世界であんなに C++ が嫌われるのか理解できない。 些細なデメリット避けるために大きなメリットを失っている。 197 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:53:06 ] The C Programming Language 274ページ www.amazon.co.jp/Programming-Language-Version-Prentice-Software/dp/0131103628 The C++ Programming Language 1030ページ www.amazon.co.jp/C-Programming-Language-Bjarne-Stroustrup/dp/0201700735 この厚さの差が問題だと思うけどな。スピードを求めるならCで書けばいいし、そうで ないならJavaとか使えばいいかと思う。C++は何でも屋であるが故に駆逐されつつある。 198 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:53:49 ] >>192 今田舎に別荘を建てて隠遁する準備が進んでいるよ 200x 年には完成する見込みらしい 199 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:01:51 ] >>196 C++ は遅い・複雑・でかいの3重苦だから組み込みには向いていない 特にリンクやロードが遅いのは致命的 MISRA-C++ とか JSF++ って日本語の解説無いのかな 200 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:37:41 ] C+αとして使えば全く速度は変わらないし生産性はかなり上がると思っている。 むしろプログラムを自然に作れば C++ の方が速いと思っているぐらいです。 リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん じゃない? 201 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 14:51:55 ] >>200 >リンクやロードが遅い理由はよく分からないが、それは言語の問題じゃないん >じゃない? 世間の C++ 使いって所詮この程度の認識なんだよね… 自分が使っている道具に対する関心が無さ過ぎ >全く速度は変わらないし だからこんなことを平気で言えてしまうわけだな 202 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 15:39:45 ] そういうのはいいから説明してくれよ 203 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:10:03 ] VC8 で Dhrystone Benchmark, Version 2.1 を C と C++ でコンパイルして比較 C Dhrystones per Second: 10300995.0 C++ Dhrystones per Second: 10299298.0 確かに C の方が速いですね。 204 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:13:25 ] dhrystone で測れるのはループの中の計算時間だけだからね 205 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:27:25 ] ループの中で結構関数呼び出しもしてるよ。 206 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 19:28:51 ] リンクやロードも? 207 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 20:04:19 ] >>200 C+αなんかではなく、ポテンシャル全開でC++を使うときの コンパイル・リンクの遅さの原因の半分は言語仕様だと思う。 残りの半分は実装の問題。 208 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 21:51:56 ] ＋αでない残りのポテンシャルの部分って具体的に何よ？ 例外とか？ 209 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 21:54:58 ] テンプレートじゃね？ 210 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 23:04:00 ] >>206 リンクは C が 0.10257s で C++ が 0.10281s です。 ロードは Windows の場合だと実行と切り離せないのでうまい計測方法が分かりません。 >>208 コンパイルで一番負担がかかるのは圧倒的にテンプレートだと思います。 boost::spirit のように凝ったテンプレートをインクルードしたファイルは 極端に時間がかかります。 遅いだけあってテンプレートの可能性は絶大なのですが。 VCの場合はテンプレートでオブジェクトファイルも大きくなるようです。 ただしリンク後は実行ファイルはそれほど大きくなりません。 211 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 01:34:45 ] >>195 入れ子が begin end, ポインタが ^ でもいい？ 212 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 01:56:07 ] >>203 同じソースコードで C++ にしただけで 10% 遅くなった。 g++ でコンパイルが通る様にしたのと、scanf() も消して ベンチマーク回数は 10000000 回固定にしている。 C++: % otool -L dry2 dry2: /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.35s user 0.00s system 99% cpu 1.352 total C: % otool -L dry2 dry2: /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.22s user 0.00s system 99% cpu 1.227 total あまり例題としては適当じゃないけど、こんなもんかね。 213 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 07:19:22 ] ちなみに ObjC でもやってみた。 ObjC: % otool -L dry2 dry2: /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) % time ./dry2 -- snip -- ./dry2 1.42s user 0.00s system 99% cpu 1.424 total 更に、ベンチマーク回数を 10 倍にすると… C: ./dry2 12.26s user 0.01s system 99% cpu 12.291 total C++: ./dry2 13.47s user 0.01s system 99% cpu 13.490 total ObjC: ./dry2 14.17s user 0.01s system 99% cpu 14.200 total Better C は Slower C でしたw こんなお遊びのマイクロベンチの結果を真に受けちゃ嫌よ。 214 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 11:03:42 ] VC は優秀だな。 215 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:21:33 ] いろんな分野でC++はPythonに置き換わりつつあるな Rubyなんてのを与えられた日本人は世界から置いてけぼり 216 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:30:09 ] 何のスレだここは 217 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 13:43:40 ] cソースはcppソースに変換後にコンパイルされるんだが。 218 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 14:59:17 ] cpp ってCプリプロセッサのこと? 確かに gcc はそういう手順になっていると思います。 219 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:06:49 ] >>214 C コンパイラが C++ 並みに遅いのは優秀とは言えないと思うけど… アセンブラ出力かシンボルダンプが見てみたいね >>218 .cpp の事でしょう 何となく何でこうなってるのかは予想がつくけど… 220 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:52:20 ] Dhrystone Benchmark, Version 2.1 を同じ環境で VC 8.0 と GCC 3.4.4 (cygwin) で比較 VC 8.0 (最適化オプションは /O2) C: 1m37.328s C++: 1m37.437s GCC 3.4.4 (最適化オプションは -O4 -fno-omit-frame-pointer -march="pentium-m") C: 2m2.188s C++: 2m4.297s ちなみに -march を外すとさらに 24s ぐらい時間がのびました。 C コンパイラが C++ 並みに遅くてもこれだけ速ければ十分優秀じゃないかな? というよりこちらでは GCC も C が C++ 並みに遅くなりました。 221 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:32:20 ] >>220 ちゃんと C++ としてコンパイルしてる? 共有ライブラリのリンク情報かシンボルダンプかアセンブラ出力か、 何でも良いけど晒してみて。最適化オプション無しだとどうなる? 222 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 22:24:40 ] >>221 C++ 版は VC では /TP オプションで、GCC では g++ 経由でコンパイルしたので C++ としてコンパイルしているはずです。 C++ でコンパイルするとき class X; をソースに書いてもエラーが出ません。 リストは長くなるのでここでは勘弁してください。 参考までに最適化を禁止して時間を計測しました。 最適化なしだと C++ が遅くなると思っていたのですが意外な結果になりました。 VC 8.0 C: 18m58.547s C++: 18m58.890s GCC 3.4.4 C: 4m46.594s C++: 4m47.765s 223 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:33:34 ] tccを使えば解決、と言ってみる。 ttp://alohakun.blog7.fc2.com/blog-entry-667.html 224 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:46:36 ] >>222 ウィンドウズは知らないけど、うちの環境だとアセンブラ出力も シンボル名もライブラリのリンクもベンチマークのスコアも変わる。 純粋に C だけのコードでこれだから、Better C として C++ の 機能を混ぜた使い方（例えば例外処理や名前空間）をすれば 更に悪化する物と期待出来る。ウィンドウズで組み込みなら C++ でも変わらないかもね。あとは Symbian とか。 まあ Better C って考え方は他にも落とし穴があるから、俺は 好きじゃないな。 225 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 14:40:12 ] >>224 OS というよりもほとんどの場合コンパイラとリンカで決まると思います。 (Windows の場合は実行時の最適化もやりかねないけど) 組込み向けコンパイラの場合は信じられないくらい最適化がダメなものも あるようです。5,6年前にある有名 CPU 向けの純正コンパイラーを使った とき、register 付きローカル変数を使っただけで命令がかなり削減された ことがありました。VC ではとても考えられないし、いまどき register を 使おうと思う人も少ないと思います。 昔の話なので今の組込み環境がどうなっているのかよく分かりませんが。 > Better C って考え方は他にも落とし穴があるから 技術的にはそれほど大きな問題もないと思っているのですが、興味深いので よかったら教えていただけませんか? 226 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 20:31:42 ] その駄目コンパイラ… 気になる… 227 名前：デフォルトの名無しさん [2008/05/20(火) 13:43:51 ] >>201 C++がCと比較してほとんど性能を落とさない理由は以下の本を読むとよく分かります。 またなぜC++をこのような設計にする必要があったのかも詳しく書いてあります。 C++の設計と進化 ttp://www.amazon.co.jp/C-%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A8%E9%80%B2%E5%8C%96-%E3%83%93%E3%83%A7%E3%83%BC%E3%83%B3-%E3%82%B9%E3%83%88%E3%83%A9%E3%82%A6%E3%82%B9%E3%83%88%E3%83%A9%E3%83%83%E3%83%97/dp/4797328541 星の数が胡散臭く感じるかもしれませんが読む価値はあると思います。 228 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 18:25:10 ] あーその本、もってるけど全然読んでないな。 ちゃんと読んでみるかな。 229 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 18:59:36 ] >>227 C++は遅いし、コンパイラの事を知らない人間が作った言語だよ。 230 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:08:21 ] AT&T に居たんだから Aho なりに相談すれば良かったのにな 231 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:08:45 ] 暴言ｷﾀ━━＞▽＜━━━ 232 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:15:22 ] いやだってやたらと信じやすい人が居たから… C++ をマンセーするのも良いけど程々にね 233 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 19:37:24 ] あ、いちいち最後に改行を付け加えてる人の事な。 ストラウストラップが GLS の 1/10 でも言語設計の知識があったら あんなコンパイルが糞遅くなる事も無かっただろうさ。 234 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 20:21:11 ] あ、いちいち最後に改行を付け加えてる人の事な。 ストラウストラップが GLS の 1/10 でも言語設計の知識があったら あんなコンパイルが糞遅くなる事も無かっただろうさ。 235 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 20:23:45 ] >>234 下2行は禿上がる程同意。その言い訳も>>227の本に書いてあるかな？ 236 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 21:42:19 ] GLS がストラウストラップ 1/10 でも現実を見ていれば あんなアプリケーションの起動が糞遅くなる事も無かっただろうさ。 237 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:08:58 ] C のどこが起動が遅いって? 238 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:15:11 ] なんでCが出てくるんだ 239 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:20:34 ] >>238 GLS 知らんのか? 240 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:27:31 ] ぐぐったら、 予備校とサーバとガラステレビ台が出て来た語学センターとガールズラブサーチってのが出て来た とりあえずガールズラブサーチ見てる 241 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:32:21 ] 起動は? 242 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:50:13 ] >>225 >OS というよりもほとんどの場合コンパイラとリンカで決まると思います。 だから環境って書いただろ… ナチュラルに斜め下の指摘をするのは止めてくれ 243 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:29:12 ] >>239 Guy L Steel Jr.の事だと思って読んだけど違うの？ 244 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:36:44 ] なら、そんな疑問は浮かばないだろ 245 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:39:59 ] Guy L Steel Jr.とC言語の関係が分からん 246 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:40:27 ] ガイ・スティールと聞いてJavaを最初に思い出したとか？＞起動が糞遅く まあ言語仕様の著者ではあるが無理感じるな 247 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:41:17 ] >>245 ANSI標準化 248 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:41:51 ] なぜSchemeが出ない 249 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:42:17 ] つか、何で知らないなら調べようとしないかね… 250 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:44:46 ] >>247 すまん、もうちょい詳しく 251 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:47:14 ] ググっても出てこないのはSteelじゃなくてSteeleだからだ 252 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 23:56:40 ] >>235 書いていないな。 そもそもあの本が書かれたのは95年頃で、 テンプレートによるコンパイル速度の低下は まだ問題になっていなかったのではないかと思う。 俺はテンプレートさえなければ、Cと比べて気になるほどなるとは思えない。 253 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 00:02:40 ] テンプレートこそC++の特徴であり価値の一つだと思うんだけど 254 名前：252 mailto:sage [2008/05/21(水) 00:09:26 ] >>253 そりゃそうだ。テンプレートなしでC++使うなんて気にはなれないし、 実際、そんな機会は全然ないから 「Cと比べて気になるほどなるとは思えない」というのは自分の想像でしかない。 すれ違いすまん。 255 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 00:20:09 ] C++ に無理矢理似非クロージャを入れて喜んでるくせに GLS も知らないんだよな… 256 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:45:37 ] そもそもGLSって略称一般的かなあ 257 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:56:54 ] スティールが設計に深く関わった高性能な言語は Fortress ぐらいしかないんじゃない? 258 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 02:13:36 ] >>235 D&E 15.10 あたりで問題は認識しいるようですよ。 最近のコンパイラはプリコンパイルヘッダーや簡易ビルドの技術が発達しているので ずいぶん良くなったと思います。 モジュール分けしてそれぞれの依存度を少なく設計すればそれほどストレスを感じません。 259 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 07:38:05 ] >>258 他の言語だってモジュール分けすればもっと速いよ C++ と違って小細工しなくても常識的な速さだけど 260 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 08:31:09 ] まあビルドの速い言語ほどその後の処理負担が大きいけどな。ユーザーが多いほどコストが増大。 261 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 08:57:38 ] C++が遅いのは文法の問題だから一般的なまともな言語と比較しても意味無い。 262 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 09:10:21 ] >>261 詳しく。 >>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。 263 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 09:20:06 ] C/C++は糞。 Cは必要悪だがC++は必要ですらない。 264 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 14:58:16 ] ベターCとしてのC++は悪くない ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを 使いまくる。 265 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 16:41:10 ] プロファイルを定義して違反したらコンパイル時にエラーか警告出すような 機能を付けてくれないかな。 266 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 17:59:57 ] ほほう、それでC++が晴れてベターCになれると。 267 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 19:36:41 ] >>266 問題点を指摘して、もっといい方法を教えてください。 268 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 20:26:33 ] >>262 >>>261 詳しく。 www.nobugs.org/developer/parsingcpp/ C++ 使いって基本的に自分で調べたり勉強したりしないよな… まあだからこそ未だに C++ をマンセー出来るんだろうけど 269 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:03:43 ] 全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？ 第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き ずっている部分だよ。D&E を読めば構文解析に配慮していることが分 かるよ。 270 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:10:14 ] 配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる けど特に就職活動とかしてない 271 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 03:10:59 ] >C++ の構文解析を複雑にしているのはほとんど C の文法を >引きずっている部分だよ Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。 ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。 272 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 14:36:52 ] 言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから 猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。 273 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 14:54:56 ] デファクトスタンダードと言う言葉を送ろう。 最近の悪例　Windows　　別に利用者がダメとは思わない。 274 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 18:38:08 ] さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。 EC++ の設計を見習うべきです。 275 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 21:04:40 ] つまりCをつかってりゃよかったって話なのか？ 276 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 00:11:25 ] その通り。 ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。 C++のプログラムを作らせるとCを知らないはずがCスタイルになる。 つまりCは人間の直感に合っているのだ。 277 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 00:29:03 ] 言いたいことは分かる気がする。 俺1人でプログラムを書くと、核となる処理は結局、手続き型。 ただ、OOP言語だと、その部分をうまく書くために、 いろんなクラスを書くという感じになる。 278 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 07:31:34 ] 赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を 人間の直感にあってるとか言われてもねぇ 279 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 10:32:00 ] >>276 「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。 「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？ 280 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 17:37:34 ] >>276 そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように なってるはずだが。 それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが 281 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 18:20:57 ] 古い言い伝えを思い出すな。 紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。 そして赤ん坊がある程度大きくなった時、ある質問をした。 「"Hello world"はどう記述する？」 答えて曰く「# include <stdio.h> int main(void) {printf("Hello, world!\n"); return 0;}」 王はC言語が最古のプログラミング言語だと確信したという……。 282 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 18:35:03 ] AとBはどこ行った?w 283 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 19:40:52 ] 勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな 284 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 22:53:10 ] 駆逐できそうにないですね 285 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 23:09:44 ] >281 俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら JAVAやらC#やら諸々へと分裂していったと。 そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。 286 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 23:23:47 ] >>276 素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･ たとえば、システムヘッダの中で、アンダーバーで始まる名前が 多用されているのを見て、そのまま真似したりする。 30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･ 287 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 09:00:15 ] そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。 まさに真理の哲学ですね。 288 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 20:27:43 ] CプログラマがC++を使わない理由を探す理由を知りたい。 289 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 20:47:04 ] その前に>>288がなぜそんなことを聞くのか理由を知りたい 290 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 20:50:18 ] >>288組み込み系では、Cが最適開発環境であることは多い。 291 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 21:49:33 ] CプログラマってCだけしか使ってない人？そんなひといるのかな。 少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。 292 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 22:07:11 ] C言語と日本語と英語が使えます。 293 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 23:42:22 ] その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの 条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。 職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、 ゴメン、俺には無理だわと応募をあきらめた。 294 名前：デフォルトの名無しさん mailto:sage [2008/05/27(火) 23:58:49 ] うちの場合は 「CよりC++のほうがいいのは分かったよ、でも使いません」 のような感じでいつも終わってしまう。 295 名前：デフォルトの名無しさん mailto:sage [2008/05/28(水) 00:17:12 ] 考えるのがめんどくさい 息をするのもめんどくさい 296 名前：デフォルトの名無しさん mailto:sage [2008/05/28(水) 00:20:34 ] ゆうちゃんとめんどくさいさい 297 名前：デフォルトの名無しさん mailto:sage [2008/05/29(木) 20:16:05 ] 組み込みで使うとかいわれても幅が広くてわかりにくいんだが 携帯ゲーム機用ソフトとかもCで組んでたりすんの？ 298 名前：デフォルトの名無しさん mailto:sage [2008/05/29(木) 20:44:31 ] GBAのときはCの方がC++より多かったと思う。今は分からない。 299 名前：デフォルトの名無しさん mailto:sage [2008/05/29(木) 21:27:12 ] なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり 携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん 300 名前：デフォルトの名無しさん mailto:sage [2008/05/29(木) 22:48:42 ] >>299 >携帯電話を組み込み系と言ったら笑われたり そうなの？　カーナビと携帯は組み込みの2大巨頭だと思ってたよ。 301 名前：デフォルトの名無しさん mailto:sage [2008/05/29(木) 23:55:42 ] 「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」 っていう考えの人も居るっていうだけの話だが、 実際組み込みって言葉はピンキリで随分曖昧な気がする 302 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 00:39:26 ] >組み込みで使うとかいわれても幅が広くてわかりにくいんだが 幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？ オレが今取りかかってるシステムはRAMが32Kしかないんだが Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。 処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。 必ずしもプロファイラがあるわけでもないし。 303 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 01:27:45 ] >301 大量に生産するため、リソースを贅沢にすることは即コストに直結する。 開発コストよりも製造コストが重視される。それが量販製品における 組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。 JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを 吸収しなければならない分、余計につらいってことだね。 正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが 豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度 あそこまでデスマにはならない。 304 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 01:42:25 ] アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。 C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。 だからC。 305 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:08:50 ] C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果 になるはずだ。 - 非 static メンバー関数の暗黙の this の存在 - コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し - デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し - 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング - コンストラクタを持つ静的局所変数の暗黙の初期化チェック - 自動変数のデストラクタの呼び出し - 暗黙の型変換の呼び出し - 一時オブジェクトのデストラクタの呼び出し - 仮想関数の呼び出しオーバーヘッド - 実行時型情報の時間コストと空間コスト - 多重継承と仮想基本クラスによるオーバーヘッド - メンバーポインタ操作の時間コスト - 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき) - inline 関数の出力コード (ただし大域最適化したときはCでも同じ) - 複雑なテンプレートの出力コード - 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ) 306 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:09:21 ] C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想 できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか なり難易度が高い。 C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの 天才でないとできないと思う。 自分が考える C++ の欠点は - 複雑なテンプレート使用時のコンパイル時間 - テンプレートと名前空間により中間ファイルのサイズが膨張 - コンパイラのバージョン間で ABI が変わりやすい - 仕様が大きいので学習が大変 307 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:23:52 ] さらに C++ の欠点の追加 - 標準準拠度の高いコンパイラが少ない (特にテンプレート) - テンプレート関連のエラー表示が分かりにくい 308 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:38:24 ] C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を 開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。 309 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:53:45 ] ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？ スレの流れのリソースが厳しい環境での答えにもなってなければ スレの主題への評価にもなっていない。 310 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:56:59 ] >>308 どのレスの話？ 311 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 22:19:31 ] >>308 それは言語の欠点ではなく俺の欠点だ。 >>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。 しかしこれ以外の本よく読んでいる。 コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。 そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。 さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。 C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの 主題から離れていないだろ。 312 名前：デフォルトの名無しさん mailto:sage [2008/05/30(金) 22:30:05 ] >>305 >逆にこれらを使わなければ C でオケ 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 あれ便利っつーか楽っつーか、確かにいいんだけど 言語仕様としては究極の汚さだよなあ。 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の造型が足りないというのは、カッコの数が少なすぎるということかな？ 458 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:19:58 ] >>455 だから、Lisperじゃない普通の人にとってはWorse is Betterには意味がない ってことじゃないの。 こんなの何でも適当できるよ。 Linux使い「Windowsが普及してるのはWorse is Betterだから」 元共産主義者「資本主義が普及しているのはWorse is Betterだから」 チャーチル「民主主義が普及してるのはWorse is Betterだから」 459 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:40:30 ] >>457 あ、造詣か鬱氏　どうやら後者のようだ 460 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:43:13 ] >>458 よく読みな つ grape.mtk.nao.ac.jp/~makino/articles/worse-is-better-ja.html 461 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:49:08 ] つうか、現実の「複雑巨大システム」であるMulticsとPL/Iの失敗への 反省・アンチテーゼとしてUnix/Cが生まれたわけで、そのことさえ抑えておけば十分。 なぜかその論文？ではその有名な事実に触れてもいないけどね。 Unixの「New Jerseyアプローチ」は、理由もなく／何も無いところから 産まれ出てきたものでは無い。 データも何も無い、分析とは言いがたい内容で、単に「Worse is Better」とか 題目だけ唱えてもそれは題目でしかなく、何の意味も無いと思う。 まあ、一種のネタ文書なんだろうな。 462 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:49:30 ] 自分で考える前に質問してしまう人がいるのは何でなんだぜ？ 463 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:50:55 ] >>460 ほら、自分の言葉で説明できないだろ。Worse is Betterってのは 単なるお題目なんだよ。 464 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 21:55:19 ] >>461 >なぜかその論文？ではその有名な事実に触れてもいない それはそういう文脈じゃないからだよ。 当然 MIT の連中が Multics を知らない訳はないでしょ。この文脈では 彼らにとっては Multics より ITS の方が現実的な意味を持っているだけ。 そこら辺の歴史は自分で勉強してチョ。 465 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:01:19 ] >>463 文章を読んで理解出来なかった奴に説明するのは無理だよ。 それは俺の能力ではどうしようもない。諦めてくれ。 466 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:01:30 ] つまりわかりやすく言えばLisperの僻みだろ。 「こんなに素晴らしく美しい言語であるLispが天下を取れないのはなぜか？！ 　それは普及するものがWorse is Betterだからだ！Lispは悪くない！」 っていう発想の転換、悪く言えば現実逃避をしてるだけ。一般人には 共感が得られない。 467 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:03:37 ] >>466 君読んでないのがバレバレだよ。 468 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:07:03 ] つか Worse って言葉に引き摺られて論旨が見えてないでしょ。 別に UNIX/C を馬鹿にしてる文章じゃないんだぜ。とほほ… 469 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:08:13 ] >>465 そういう言い方がカルトくさいんだよ 「文章を読んで大作先生の素晴らしさを理解出来なかった奴に 説明するのは無理だよ。それは俺の能力ではどうしようもない。諦めてくれ。 」 とか、 「君、大白蓮華読んでないのがバレバレだよ。」 って言ってるのと変わらん。そんなの知るかボケ、と言わせてもらおう。 470 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:10:20 ] さて、自転車置き場の議論が始まりそうだから退散するとしますか… 471 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 23:08:12 ] >>448 俺はC++も「悪い」に属すると思う。 そうでなければここまで広まらなかったに違いない。 472 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 12:38:14 ] 広まったのは単にMSのせいかも 473 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 13:55:19 ] SunはMSを潰すためにJavaを出した。MSはJavaとの共倒れを狙ってC#を出した。 474 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 14:07:48 ] 実装が単純ならば移植しやすく広まりやすい。 正しいものを広めるより広まったものを改善するほうが簡単。 完全に正しいものを作ろうとすると最後の20%に努力の80%が費やされる。 つまり「悪い」の定義は単純な実装と最低限の品質で最大限の評価を得ること。 475 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 14:23:55 ] それなんてエロゲ？ 476 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 19:08:09 ] >>472 MFCのせいでC++が浸透しないのかも 477 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 19:13:46 ] MFC以外のもっと使いやすいC++用RADがあったら 普及したかもなぁ・・・ってBCBは？！ 478 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 19:24:27 ] >>477 VC++にVCLが標準装備だったらなあ 479 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 21:57:16 ] VCLそのものがC++で書かれていないのが痛い 480 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 10:21:37 ] くだすれ、落ちてねえ? 481 名前：デフォルトの名無しさん mailto:sage [2008/06/23(月) 08:15:11 ] >>448 これだから日本語しか読まない奴は。 Worse Is Better - Richard P. Gabriel www.dreamsongs.com/WorseIsBetter.html > Decide for yourselves. おっと。日本語訳もあった。 www.kt.rim.or.jp/~hisashim/gabriel/WorseIsBetter.ja.html 482 名前：デフォルトの名無しさん mailto:sage [2008/06/23(月) 08:18:04 ] Jim Waldo の "Worse is worse" も翻訳があった。助かるな。 www.kt.rim.or.jp/~hisashim/waldo/worseisworse.ja.html 483 名前：デフォルトの名無しさん mailto:sage [2008/06/23(月) 09:09:28 ] >>481-482 どっちも既に読んでるよ。ご苦労。 484 名前：デフォルトの名無しさん mailto:sage [2008/06/23(月) 20:56:16 ] しかも前者に至っては既出 485 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:00:14 ] そんなことよりWordsworth読もうぜ！ ttp://www.bartleby.com/145/ww260.html 486 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:25:54 ] Yeats >> Blake >>> (越えられない壁) >> Wordsworthだろ 常識的に考えて・・・ まあ、英国詩人全部合わせてもRimbaud一人に勝てないけどな 487 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:27:15 ] ランボーってベトナム帰りのあいつか？ 488 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:29:07 ] 元ネタだから、yesと言っても間違いじゃない。 489 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:38:16 ] Close To The Edgeは名盤だよな 490 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 20:53:56 ] 俺はHeart Of The Sunriseの方が好き。 491 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 01:01:07 ] C言語のプログラマは、自分たちを一番優等だと思ってるところが問題だ。 492 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 01:54:54 ] つまりプログラマの殆どはそんなこと思っているのか。 493 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 08:28:14 ] 言語の違いなんてバイオリンとピアノの違いでしかない。 道具が違うからって音楽家は人を馬鹿にしたりしないだろ。 それと同じこと。 ただし、ヴィオリストは馬鹿だけど。 494 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 08:40:33 ] ベーシストをDISる厨バンドマンならいくらでも 495 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 11:04:51 ] >>493 >道具が違うからって音楽家は人を馬鹿にしたりしないだろ。 譬えの誤謬だ。 カズー奏者はどう頑張ってもバカにされる対象。 496 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 21:50:27 ] >>493 >ただし、ヴィオリストは馬鹿だけど。 (^^;;;;; なぜ Va は自虐的なんでしょうね、てスレ違いですけど。 497 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 22:21:01 ] 他の言語を貶す言語廚は、自分の推す言語使いこなせななくて自信がないから他の言語を貶すんだろうね。 自分の目的に合致している言語を使いこなしているのなら、他の言語なんて眼中にないだろう普通 498 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 22:27:33 ] >>497 誰しもそこから出発するわけでして、許してあげましょうよ。 499 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 22:30:02 ] このスレの主旨はそういう言語戦争とは違うと思うけど？ そろそろCに変わる言語が欲しいね、という前向きな話だよ。 500 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 02:44:29 ] BCPLとK&Rの頃から愛してる C99になってもっと恋しくなった BSDとEmacsも愛してる Cを知ったその日から 僕のプログラミング地獄に音楽は絶えない 501 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 11:02:04 ] K&Rからなら信じるけど。 BCPLからなんて誰が信じるか。 502 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 23:12:49 ] そこマジレスするところじゃなくね？w 503 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 23:15:28 ] 1億と2千年たってもＣ言語は健在だお。 504 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 23:46:41 ] そんなに人類生きてんのかな 505 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 00:08:34 ] マジレス乙ｗ 506 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 06:25:07 ] そのころには人類は量子コンピュータ上でシュミレーティッド された世界に住んでるんだろな。動作言語はもちろんC-100002000 507 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 07:07:17 ] シュミレーティッド 508 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 23:47:05 ] C++の何がまずいかは語りつくされたようだから、 次はＤのなにがまずいかについて聞かせてくれまいか。 509 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 23:49:19 ] D言語は良く知らない 510 名前：デフォルトの名無しさん mailto:sage [2008/06/28(土) 00:02:19 ] DこそＣを駆逐してやるという目的で生まれた言語だよね？ 511 名前：デフォルトの名無しさん mailto:sage [2008/06/28(土) 02:01:19 ] でもDコンパイラってCと100%互換なんじゃなかった？ むしろ共存したいんじゃないの？ 512 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 16:30:47 ] 互換性は罠だな。 共存すると見せかけてＣプログラマをＤに取り込んでおいて、 Ｃに戻れないほど脳みそを蝕んでおいてからはしごをはずすんだろう。 513 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 12:14:30 ] なんか方向性が逆じゃないか？ スタック変数の自動管理と、一般的な制御構文の使える高級アセンブラがあればいい。 514 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 13:17:54 ] そんなやつはもはや少数派なんだよ 515 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 18:36:13 ] >>513 マクロアセンブラで遊んでてください。 516 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 23:57:30 ] Java とか.netのVMのアセンブラを使えば、幸せになれるんじゃないか？ 517 名前：513 mailto:sage [2008/07/03(木) 02:13:15 ] >>516 JVMとか.netのCLRとかは、それこそJavaやC#使えばいいだろ。 Cの本領発揮は、もはや絶対アドレスやIOポート参照が必要なところか、 CPUレベルの最適化が必要なところだけなんだから、だったらそこだけ 高級アセンブラで書いて、残りは本当の高級言語で書けばいい。 518 名前：デフォルトの名無しさん mailto:sage [2008/07/03(木) 15:18:31 ] >>513 >>517 >高級アセンブラ それがCじゃないのか？ 519 名前：デフォルトの名無しさん mailto:sage [2008/07/03(木) 18:18:37 ] Cはポータビリティのために、効率が悪い点が多いんだよ。 低級言語は、機種依存な部分だけに使えばいい。 520 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:31:29 ] >>519 ここで低級言語といってるのはCのこと？アセンブラのこと？ 521 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 15:47:30 ] >>511 惜しい。コンパイラは互換性無いよ。 互換性があるのはリンカ。 522 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:18:21 ] >>520 低級はローレベル。すなわちステムに近いことを示す。システム記述言語であるアセンブラやC/C++などじゃないか。 523 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 13:42:35 ] ttp://ja.wikipedia.org/wiki/%E4%BD%8E%E7%B4%9A%E8%A8%80%E8%AA%9E 524 名前：デフォルトの名無しさん mailto:sage [2008/07/12(土) 23:15:15 ] >>522 Cと他言語(Java等)を比べて低級な方って意味で言ってるのか、 それともCとアセンブラを比べて低(ry ってことだろじょしこー 525 名前：デフォルトの名無しさん mailto:sage [2008/07/14(月) 11:01:59 ] いや俺はJKよりJCのほうｇ 526 名前：デフォルトの名無しさん [2008/07/14(月) 12:03:02 ] もっとも低級言語に近い高級言語Ｃ。この独特のポジションにいる限りCobolやVBが滅びても Ｃが滅びることはないように思う。 527 名前：デフォルトの名無しさん mailto:sage [2008/07/14(月) 15:32:42 ] >>526 当然だな 528 名前：デフォルトの名無しさん mailto:sage [2008/07/14(月) 23:47:27 ] そもそも、現在生き残っている OS で C を使わないものが、どれだけ存在するのか？ それ等の OS が全て駆逐されないかぎり、C は駆逐されないのは自明 529 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 00:42:27 ] まったくだ。リア工の俺にはCの無かった時代というのが想像できない。 530 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 01:08:16 ] LISPマシンが市場抑えていたらどうなったんだろう、って想像くらいか マシン語が括弧だらけになるんだろうな サンもJavaマシンとか考えてたな　あれは夢想に終わったんだっけか 後者はマシン語がJavaVMのバイトコードに置き換わるだけだな 実現していたところで、結局その上にCコンパイラとか出て来て意味不明な事になってたんだろうな 531 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 05:16:55 ] >>530 ICOT のアレは？ 532 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 19:58:25 ] 34bitアーキテクチャが流行っただろうな 533 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 21:13:20 ] 将来、 GPUにDSP系のプロセッサを乗せて そいつにコードを転送する必要が生じたとき、 そのコードはC言語をはじめ、手続き型言語では記述できない 組み込み系も視野に入れるなら、C言語の立ち入ることのできない領域は今でもあるよ。 FPGAとかあるし。 534 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 21:24:01 ] >手続き型言語では記述できない すまん。 俺にはそんなものがあるとはちょっと想像が付かない。 どういうこと？ 535 名前：デフォルトの名無しさん mailto:sage [2008/07/15(火) 22:16:17 ] >>534 FPGAとかゲートアレイっていう、電子回路をプログラミングできるチップがあって、 そいつをプログラミングするにはSystem-CとかHDLとかいう言語を使うんだ。 基本的には 「○番ポートと○番ポートの入力を足したり割ったりして、○番ポートに出力せよ」 という宣言の羅列になる。 本物のハードよりは遅いけれど、ソフトウェアよりは速い。 ソフトウェアより融通が聞かないけれど、ハードウェアよりは融通がきく。 という建前だった。 今は知らないけど。 536 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 01:48:03 ] それって手続き型言語で記述できないのか？ 537 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 01:55:14 ] できるでしょ 538 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 02:34:18 ] 手続き型言語を procedural language の訳語とするなら無理だろう 逐次実行であることが第一義だから対極にある ただ、C言語を駆逐する方向という意味では、全く逆に取り込まれていく方向にあると思う これは、言語・ソフト的にという意味では無くて、ハード的にという意味だが 539 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 06:06:11 ] SystemCはC++で書けるんだが 540 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 07:06:43 ] >>534 大雑把に書くと 手続き型言語は演算子を順番に評価実行する。 HDLなどの記述言語は、すべての演算子が同時に評価され常に評価結果が反映される。 HDLに適した処理を手続き型言語で書き直すと処理時間が遅くなりすぎる。 手続き型言語に適した処理をHDLで書くと回路規模が大きくなりすぎる。まあこれは、HDLでCPUを書いてしまえば解決できるというのがノイマン型コンピュータというか手続き型言語の原点かな。 541 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 07:17:51 ] 記述できるじゃないか。 542 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 08:12:41 ] まぁ、手頃なスクリプト言語で書くほうが無難ってことだな。 543 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 08:36:05 ] haskellでHDL書きたい 544 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 09:04:28 ] >>543 atomでいいんじゃないか？ funhdl.org/wiki/doku.php/atom 545 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 12:15:23 ] >>541 記述できてもパフォーマンスを満たせない 546 名前：デフォルトの名無しさん mailto:sage [2008/07/16(水) 15:31:49 ] できないじゃなくて現実的じゃないってことか、把握 547 名前：デフォルトの名無しさん [2008/07/23(水) 08:10:10 ] CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。 他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。 CにはOOだのGCだの必要なし。それはLLとかに任せればいい。 548 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 01:45:34 ] CはC++の例外相当の処理を効率よく実行できないので不十分。 C++からCへのトランスレータが使われなくなったのはそのせい。 549 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 07:18:46 ] >>547 同意。C99も失敗だったかもな。 550 名前：デフォルトの名無しさん mailto:sage [2008/07/24(木) 13:44:29 ] 185でｶﾞｲｼｭﾂ 551 名前：デフォルトの名無しさん mailto:sage [2008/07/25(金) 07:09:39 ] ランタイムライブラリを統一できないから、それを必要としないCが生き残る MSがそれを統一したような気がしないこともないが、それは言わない約束だからCが生き残る 552 名前：デフォルトの名無しさん mailto:sage [2008/07/25(金) 10:11:24 ] >>551 libcって知ってる？ 2行目も意味不明 553 名前：デフォルトの名無しさん mailto:sage [2008/07/25(金) 13:18:37 ] libcを他のライブラリと区別する理由はない 554 名前：デフォルトの名無しさん mailto:sage [2008/07/26(土) 20:52:32 ] インタプリタが生き残るよ 555 名前：デフォルトの名無しさん mailto:sage [2008/08/13(水) 17:10:02 ] C99のTechnical corrigenda TC３はどんな内容ですか？ 556 名前：デフォルトの名無しさん mailto:sage [2008/08/31(日) 22:30:01 ] libcって、ANSIレベルに毛が生えた物、って先入観しかないんだが… 557 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 12:48:32 ] Cが駆逐されると思ってるかどうかで考え方がかなり変わるみたいだな Windows使ってるとMSが潰れたら困るよ、みたいな感覚で関数型言語やってる人とか なんかすごくね？ 558 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 22:19:47 ] Windowsを完全に駆逐するためには ってスレがあってもいいかもな。良くないか。 559 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 22:58:47 ] Macしかないな。 560 名前：デフォルトの名無しさん mailto:sage [2008/09/01(月) 23:03:12 ] Macをプログラム言語にたとえるとlispになるのかなぁ。 とMacもlispも使ったことのない俺が言ってみる。 561 名前：デフォルトの名無しさん mailto:sage [2008/09/02(火) 19:34:55 ] Objective-C涙目。しかし、たとえるならRubyかな。 触れ込みの良さ、扱いやすさと、後方互換性の欠如、筋の通らない仕様変更とか。 562 名前：デフォルトの名無しさん mailto:sage [2008/09/02(火) 20:18:58 ] 宗教じみてる点でも似てるな 563 名前：デフォルトの名無しさん mailto:sage [2008/09/03(水) 06:51:40 ] 指導者にカリスマがあるからな、仕方ない。毛はないが。 564 名前：デフォルトの名無しさん mailto:sage [2008/09/03(水) 22:49:49 ] モルモン教だからだろ 565 名前：デフォルトの名無しさん mailto:sage [2008/09/05(金) 00:46:43 ] 神に祝福された存在であるRubyを、ちょっと小洒落てるだけがとりえのMacなんかと同列に扱わないでください＞＜ 566 名前：デフォルトの名無しさん mailto:sage [2008/09/05(金) 10:12:21 ] Ahura Matz 神か。 567 名前：デフォルトの名無しさん [2008/09/16(火) 23:40:56 ] アセンブラが人手によってかかれるべきでない（コンパイラに任せたほうが良い）のと同様に、C言語もまた人手によってかかれるべきではない。 568 名前：デフォルトの名無しさん mailto:sage [2008/09/16(火) 23:56:34 ] なんちゃそれ。 569 名前：73.6.30.125.dy.iij4u.or.jp mailto:sage [2008/09/17(水) 13:53:44 ] >>567 C言語を共通アセンブラと考えるとそうかもしれないね。 570 名前：デフォルトの名無しさん mailto:sage [2008/09/18(木) 00:23:07 ] そこでObjective-Cですね 571 名前：デフォルトの名無しさん mailto:sage [2008/09/18(木) 11:05:43 ] >>567 つまりyaccとかbisonですね 572 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 01:53:00 ] 2chで語る以前に、言語開発者がｘｘｘよりは組みやすく〜とかいいつつ アホみたいに言語増やしたけど、今だにC,C++が生き残ってるってことは 駆逐は無理。以上 573 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 02:58:25 ] >>572 それ、C,C++の部分に大抵の言語があてはまるんじゃね？ いまだにCOBOLが…、いまだにPerlが…他 574 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 00:06:47 ] CPUもコア増やすくらいしかやることないならそろそろプログラム言語に歩み寄っていいんじゃないかい？ VMがこれだけはやってんだから統一VMのモデルでも作ってネイティブでその命令実行してやれ。 そうすりゃCの呪縛も少しは薄れるだろ。 575 名前：574 mailto:sage [2008/09/25(木) 06:30:10 ] 自分で言うのもなんだが、結構いいアイディアな気がしてきた。 VMのコードをネイティブで実行するCPUなんてのは陳腐なアイディアだが、 C言語を駆逐するためにはかなり効果あるんじゃないか？ 昔はハードウェアの値段がソフトウェアの値段より遥かに高かったけど、 今じゃすっかり逆転してるわけだし、VMの技術だってかなり枯れてきているころだろう。 インテルがコア数を増やすのも限界まで来て、それでもトランジスタを増やさなければいけないとなったら、 VMの命令をネイティブでサポートなんていう道に走らないとも限らない。 C言語完全駆逐の可能性はまだ残されているっ 576 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 08:25:57 ] 今のCPUがマイクロコードで実装されていることもご存じないらしい。 Intelが有数のコンパイラベンダーであることもご存じないらしい。 577 名前：デフォルトの名無しさん mailto:sage [2008/09/25(木) 12:37:45 ] >>575 どっちかというと、ＣＰＵの規模より集積可能なトランジスタのほうが上回る様になってきたから、余ったトランジスタ処分用にマルチコアにしたんじゃないの？ 578 名前：デフォルトの名無しさん [2008/10/02(木) 01:33:27 ] 昔の同僚に、真顔でこれを言ったアフォがおった ツール類で何でもできるんだとよ 579 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 08:59:25 ] >>13 VCなくなったらそれこそC++なんか閑古鳥だろ 580 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 09:18:21 ] C++ってなんであんなに肥大化しちゃったの？ pc11.2ch.net/test/read.cgi/tech/1219902495/ 581 名前：デフォルトの名無しさん [2008/10/02(木) 13:26:44 ] ポインタ概念のないVBがこれだけ進化してるんなら逆にＣ駆逐は時間の問題かと。 昭和生まれが現役引退するころにはプログラム歴史記念館に飾られてるよ。。きっと。 582 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 15:31:31 ] >>581 組込みソフトのこともちっとは勉強しろよ坊主 583 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 18:27:36 ] 小娘かもしれん 584 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:36:41 ] お前らはC言語無くなったら何使うん？java？ 585 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:46:39 ] Objective-D++ 586 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:56:05 ] はいはい 他は？ 587 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:58:55 ] lispがはやってほしい 588 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:59:09 ] ポインタの概念は絶対になくならないよ 何もかも値渡しするっていうアホ言語を作るなら別だが 589 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:02:33 ] C並に低レベルな言語は必要 それがCである必要は無いけれども 590 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:11:44 ] BCPLがあまりに低レベル過ぎて使いにくすぎたから C言語が作られたんだよな確か。 だからC言語はなくならないんじゃない？ 591 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:25:23 ] 並にって話してるのにそれより低いものを持ち出してもどうしようもないと思うぞ。 592 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:30:28 ] ロクな返事がねーな 代用できるものも考えずに潰すつもりだったの？君ら 593 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:42:35 ] C# 594 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:54:08 ] >>593 C#のネイティブコンパイラが出来たらな。 ngen.exeは腐っているのでもっとまともなネイティブコード ジェネレータが必要だが。 595 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:33:43 ] PASCAL PL/I 596 名前：デフォルトの名無しさん [2008/10/02(木) 22:38:47 ] CISC アセンブラ 597 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:47:22 ] >>596 ARMケータイはどうするの？ 598 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:02:03 ] 要するに組み込みのハードのパワーがまだまだ貧弱なのがいかんのだろう。 あと１０年もすれば組み込みのハードもパワーが有り余ってC言語が要らなくなるんじゃない？ 599 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:16:40 ] パワー関係ないだろ 今時のマシンだろうがbootstrapのコードはasmじゃないと書けないし kernelのコアのコードがメモリも弄繰り回せないようでは話にならない Cのような機能を持った言語は要るんだよ Cである必要は無いけれども 600 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:20:20 ] ハードの性能とか一切関係ないよ 実用性という点においてCを超える言語が存在しないだけ 過去を考慮せず、これからのハードに的を絞っても Cより先に処理系を用意し続けるのって不可能に近いよ それが出来なきゃ駆逐なんて夢物語 601 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:35:34 ] >>584 Ｃ＋＋ 602 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:36:03 ] Cがアセンブリを駆逐したという伝説がひとり歩きしているね 実際にはCがアセンブリと連携しやすかった所がポイントなのに 603 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:44:28 ] そういや、アセンブリは非常に低水準だけど、それでも大抵のハードでスタックは装備されてるんだよな。 もっといろんな概念がハードに採用されてもよさそうだけど、あんまりそうはならないね。 それだけスタックがプログラムにとって本質的ってことかな。 604 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:48:31 ] と思ったけど、よく考えたらハード的に特別スタックを用意してるわけじゃないんだっけ？ スタックポインタなんてなんて名前のレジスタがあるからてっきり、ハード的にスタックがあるんだと思っちゃったけど。 605 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:56:03 ] でもただのjumpやmoveではない、push/pop/call/retがあるあたり 命令面では特別視されている感じがする。 606 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:18:46 ] RISC ではそういう命令あんまりないんじゃない。 607 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:22:39 ] >>606 まじで？ 具体的なCPUの名前教えて。 608 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:27:41 ] R3000なんかはそうでしたね スタック操作も全部アセンブラでした 609 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:16:05 ] >>605 それマクロよ 610 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 07:58:45 ] いやマクロ違うだろ 611 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:11:43 ] x86 は Pentium Pro 以降ハードウェアで x86 命令をマイクロ命令に変換してる。 612 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:41:48 ] でもx86のIntelではPentium-Mまで、AMDに至ってはPhenomに 至るまでスタックポインタをALUで操作していたから遅かったね。 これらのCPU以降ようやくスタック操作が速くなった。 まあCALL自体は少ないとしてもPUSH/POPはレジスタの少なさ ゆえ避けられないからな。 613 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 19:12:12 ] C言語を駆逐するのにスタックが関係あんのか？ 614 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 19:25:37 ] 大有りだろ 615 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 19:57:34 ] >>614 詳しく 616 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 20:38:17 ] スレの流れを見るに、Ｃはなんだかんだ言っても用途があるのでなくならない。 代替言語が仮にあったとしても、それがＣ言語を上回る訴求力が無い限り無理ぽ。 ただ、新しいハードが市場を埋め、それは既存と全く違う機械語が実装され、 そこで最初に提供された開発環境がＣ＋＋とかだったらＣは駆逐されるかもね。 617 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 21:19:53 ] スタックに次ぐ、ハードウエアに追加するほどプログラミングに必須な機能といえば… ガベコレとか？ 618 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 21:48:54 ] >616 C++がスーパーセットである以上、C++がCを駆逐することは不可能じゃないかな その状況で例えばLispだけだったら可能性はあるかもね 619 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:02:09 ] >>616 拡張子.cppの中身実質Cなコードが溢れるだけ。 って、コンパイラじゃなくて開発環境か。 APIがクラスとか例外とかを平気で使っている状況かな。 620 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:15:19 ] ふと思ったんだが別にCを駆逐する必要なくね？ むしろ共通アセンブラとしてはベストじゃないか 621 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:21:05 ] 共通アセンブラとしてならな。 Cで、でかいアプリ組まされるなんていう無法がまかり通るからいかんのだ。 622 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:21:54 ] >>621 それは言語の問題じゃないだろ 623 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:24:34 ] じゃあ何の問題なんだよ。 624 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:26:40 ] あんたの職場環境の問題 625 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:29:39 ] きつい一言を…（TT） 626 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 22:31:42 ] 「でかい」の基準なんて分野毎に全く違う。 627 名前：デフォルトの名無しさん mailto:sage [2008/10/12(日) 20:46:48 ] Linuxをスクラッチから構成すると導入したい言語はたいていCかC++のコンパイルから始まるからこりゃ駆逐なんてできないやと思った。 628 名前：デフォルトの名無しさん mailto:sage [2008/10/12(日) 21:06:04 ] ＞スクラッチから …… 629 名前：デフォルトの名無しさん mailto:sage [2008/10/12(日) 21:29:51 ] LFSか 630 名前：デフォルトの名無しさん mailto:sage [2008/10/23(木) 04:33:16 ] Hosh 631 名前：デフォルトの名無しさん mailto:sage [2008/11/06(木) 21:20:21 ] self = [[Object alloc] init]; 632 名前：デフォルトの名無しさん [2008/11/08(土) 21:03:50 ] むしろランタイムがないと動かない言語が駆逐されるべき ランタイムのバージョンやベンダーに依存して異常動作するなぞ論外 オブジェクト指向もいらね。 変数定義と関数定義はクラスで一体化するよりむしろ分けた方が 良いと思ってる。 633 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:05:20 ] Cもランタイム無いと動かない環境あるだろ? 634 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:25:02 ] あったとしても他の言語仕様が膨大な言語にくらべれば互換性は 高いはずだと思われ。 635 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:27:12 ] glibcみたいのはランタイムとは言わないのかな? よく知らんけど。 636 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:29:12 ] POSIXのシステムコールなんて、ランタイムもいいところじゃないか。 637 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:30:53 ] つまりLispOSが最強ということか… 638 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:40:20 ] PCが機械語で動くかぎり、もっと言えばPCがメモリとCPUでできている限り、 Cが無くなることはないであろうと予言しておく。 639 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:43:43 ] その予言は>>28で既出 640 名前：デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:47:24 ] ガイシュツですたか。まあそれだけCは偉大な発明だったわけだ。 641 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 01:32:12 ] Cが、特出すべき素晴しい言語だとは思わない 突然変異的なパラダイムは何一つ無いんだから ただ、それを記述する為に生まれたUNIXが純然たる地位を保っていることこそ Cが現在の地位を保持しているのでは無いかと思う Windowsですら、その呪縛からは逃れられてはいない 642 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 07:57:28 ] 全然違う話で悪いんだが UNIXは素晴らしいがCは素晴らしくないと言う人間をどう思う？ 643 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 08:25:15 ] ファシスト。 644 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 12:33:58 ] Cの駄目な点は文字列の扱い。 char型の配列を操作するのはとにかく面倒なので改良型Cが欲しいところ。 645 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 14:06:39 ] Cの改良は何度も失敗してる。 全然関係ないけど、LuaみたいなのをベターCと見なせるなら、もしかするかもね。 646 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 20:53:07 ] ポインタの演算禁止とか、malloc()禁止とか、そういうコーディングルールを使ってるところは Pascalとかでいいじゃんって思うけど、そういうレベルの人たちって、ちょっと違ってると、もう使えなくなるしな。 647 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 21:53:49 ] for文とかwhile文でbreak禁止とかストレスたまって仕方ない。 648 名前：デフォルトの名無しさん mailto:sage [2008/11/09(日) 22:02:05 ] Cは覚えることが少ないから初心者向きだと思っていたが、Schemeを覚えて考えが変わった。 Cなんていらないや。 649 名前：デフォルトの名無しさん mailto:sage [2008/11/10(月) 01:09:03 ] 今のlisperにとってCは闇米のようなものだ 650 名前：デフォルトの名無しさん mailto:sage [2008/11/12(水) 15:06:44 ] >>634 glibcのバージョン変わると起動しなくなるのが高い互換性？ 651 名前：デフォルトの名無しさん mailto:sage [2008/11/13(木) 11:46:34 ] 動的リンクとCの言語仕様は関係無いな 652 名前：デフォルトの名無しさん mailto:sage [2008/11/13(木) 15:17:39 ] >>650 それって窓で言えば kernel32.dllやuser32.dllを別のに差し替えるようなものだぞ 653 名前：デフォルトの名無しさん mailto:sage [2008/11/14(金) 20:47:19 ] Cが嫌いなら無視してればいいのに おバカさん向けのお上品な言語が他にたくさんあるわけだし 654 名前：デフォルトの名無しさん mailto:sage [2008/11/14(金) 21:55:54 ] >>653 >>4 655 名前：デフォルトの名無しさん [2008/11/14(金) 22:17:59 ] 逆にさらにアセンブラよりな「cフラット」をつくるべきだな 656 名前：デフォルトの名無しさん mailto:sage [2008/11/14(金) 22:48:56 ] Cの歴史を考えるとOSを同時に作ることが必須なんじゃないか？ OSｲｲ!→ｲｲOSを作れる言語使う CだけでなくUNIXも同時に駆逐しなければ無理だと思う 657 名前：デフォルトの名無しさん [2008/11/14(金) 22:49:41 ] ていうかさ。 もっと強烈凶悪なプリプロセッサがCに追加されたら、Cを駆逐しようなんて意見はなくなると思うな。 658 名前：デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:06:41 ] テンプレートのことか？ 659 名前：デフォルトの名無しさん [2008/11/14(金) 23:19:13 ] テンプレートも欲しいし、 いくつか追加して欲しい演算子もあるな。 でも、それができたらきっとCで満足してしまいそうな俺が居る。 660 名前：デフォルトの名無しさん mailto:sage [2008/11/15(土) 01:20:50 ] C++の機能を適度に導入するのは賛成 というか実際そういう方向へむかってますね 661 名前：デフォルトの名無しさん mailto:sage [2008/11/15(土) 08:46:32 ] 効率は重要だけどCの低レベルさは嫌いとか、そんな都合いい話あるわけないじゃん それが理解できないやつがC駆逐とかポストC言語に期待とか幻想抱くんだろうな 662 名前：デフォルトの名無しさん mailto:sage [2008/11/15(土) 15:32:56 ] Pascalとか昔の構造化BASICくらいのレベルなら、いまの最適化技術なら、Cと変わらないコードができるよ。 663 名前：デフォルトの名無しさん mailto:sage [2008/11/15(土) 17:20:30 ] >>662 pascal はね、共用体が変だし、; をかく場所も理屈っぽいし、なによりも、おなじことを書くのにc の倍のタイプ量になるのもやだし。 basic? 論外。 664 名前：デフォルトの名無しさん mailto:sage [2008/11/19(水) 21:48:41 ] C言語を使っている組織・人間に対し武力介入を行う 665 名前：デフォルトの名無しさん mailto:sage [2008/11/20(木) 03:23:34 ] >>664 ネット潰すのより難しそうだな 666 名前：デフォルトの名無しさん mailto:sage [2008/11/20(木) 10:48:11 ] 暗黙の型変換などを排除したstrictCが欲しい 667 名前：デフォルトの名無しさん mailto:sage [2008/11/22(土) 23:36:47 ] 色んなハード向けのコンパイラ屋がいる限り、 やっぱり駆逐されることはまず無いだろうね。 言語機能を機械語に置き換える量が最小元。 ・新たなハードが出ても直す所はちょこっと しかも、冗長さが無いのでパースが楽。 ・クラス構文なんか付加されるだけでも割とダルい ランタイムライブラリが殆どない ・ハード構成に合わせGCなんかを作るのは手間 単純でいて、OSが作れるほど実用的。 ・lispなどもっと単純な言語もあるがハードには不向き これを越える言語がないとなぁ。 668 名前：デフォルトの名無しさん mailto:sage [2008/11/25(火) 00:54:20 ] Cって 遅い(実行速度じゃなくて開発の早さ) 高い(スキルのある人を探すと) 低機能(高級でないという意味で) だけど早い安い高機能に負けないのは汎用性が他の追従を許さないからでは 高機能と汎用性って相反してる気がするからCは生き残るんじゃないかな 真っ白なノートと塗り絵のノートの違いみたいな なんて素人なりに考えてみました 669 名前：デフォルトの名無しさん mailto:sage [2008/11/25(火) 15:23:23 ] Cコードを吐く特定の言語の)コンパイラがあればすべて解決だろ？ C++(cfront)が失敗だろうが他の{実装|言語}でトライすればいいだろｊｋ 670 名前：デフォルトの名無しさん mailto:sage [2008/11/25(火) 17:40:29 ] >>669 　最適化の邪魔になる構文と、人間のための構文を仕様から 除去しないと難しいな。そうなると、最早Cでは無いが。 因みに、GCCの中間コードには近い物が有り、実用化されてるけどね。 671 名前：デフォルトの名無しさん [2009/01/25(日) 05:39:19 ] 移植性の問題はコンパイラじゃなくてジェネレータにすればかなり解決するんじゃないか？ というか、昔のC++しかりCのコードを吐くジェネレータは多そうだけど、実際どうなの 672 名前：デフォルトの名無しさん [2009/01/25(日) 08:09:17 ] とりあえずガベコレ搭載したObjective-C 2.0でいいんじゃないか？ 673 名前：デフォルトの名無しさん mailto:sage [2009/01/25(日) 10:42:01 ] おまえらがC言語以外の言語で素晴しいソフトをどんどん作ればいいのさ 674 名前：デフォルトの名無しさん mailto:sage [2009/01/25(日) 10:42:42 ] 色んな思想があるから、色々と（微妙な）亜種が登場して なんだかんだで C が生き残る 675 名前：デフォルトの名無しさん mailto:sage [2009/01/25(日) 12:13:48 ] Dだろ 676 名前：デフォルトの名無しさん mailto:sage [2009/01/25(日) 12:39:49 ] >>675 じゃあDで頑張って駆逐してください 677 名前：デフォルトの名無しさん mailto:sage [2009/01/26(月) 01:47:32 ] Dとか最速消滅候補だろｗｗｗ 678 名前：デフォルトの名無しさん [2009/01/26(月) 09:49:56 ] なんだかんだいってＣでつくっちゃうよな 確かにオブジェクトシステムとガベコレがないのは痛いが あとインラインアセンブラはＤのほうがいい

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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