08/05/21 09:10:21
>>261 詳しく。
>>259 モジュール分割や依存度下げは小細工かよ。まあ前方宣言はそうかもしれないが。
263:デフォルトの名無しさん
08/05/21 09:20:06
C/C++は糞。
Cは必要悪だがC++は必要ですらない。
264:デフォルトの名無しさん
08/05/21 14:58:16
ベターCとしてのC++は悪くない
ただたまに勘違いしたやつがいらんところで、継承とかテンプレートを
使いまくる。
265:デフォルトの名無しさん
08/05/21 16:41:10
プロファイルを定義して違反したらコンパイル時にエラーか警告出すような
機能を付けてくれないかな。
266:デフォルトの名無しさん
08/05/21 17:59:57
ほほう、それでC++が晴れてベターCになれると。
267:デフォルトの名無しさん
08/05/21 19:36:41
>>266 問題点を指摘して、もっといい方法を教えてください。
268:デフォルトの名無しさん
08/05/21 20:26:33
>>262
>>>261 詳しく。
URLﾘﾝｸ(www.nobugs.org)
C++ 使いって基本的に自分で調べたり勉強したりしないよな…
まあだからこそ未だに C++ をマンセー出来るんだろうけど
269:デフォルトの名無しさん
08/05/22 03:03:43
全体のビルド時間に占める構文解析の時間はそんなに大きいものかね？
第一 C++ の構文解析を複雑にしているのはほとんど C の文法を引き
ずっている部分だよ。D&E を読めば構文解析に配慮していることが分
かるよ。
270:デフォルトの名無しさん
08/05/22 03:10:14
配慮はしてるけど何もしてないってことだろ。俺も自分がニートなのに配慮してる
けど特に就職活動とかしてない
271:デフォルトの名無しさん
08/05/22 03:10:59
>C++ の構文解析を複雑にしているのはほとんど C の文法を
>引きずっている部分だよ
Cからすれば勝手に引き摺って勝手に泥沼に走り去った後ろ姿しか見えない訳で。
ようも色々余計な物引き摺って、そんな泥沼に邁進してるなと。
272:デフォルトの名無しさん
08/05/22 14:36:52
言語屋からの賛成を得てC文法の良くないところを直そうとしたがユーザーから
猛反発食らってあきらめた。現実ばかりを見て理想を追いかけない駄目な設計者。
273:デフォルトの名無しさん
08/05/22 14:54:56
デファクトスタンダードと言う言葉を送ろう。
最近の悪例 Windows 別に利用者がダメとは思わない。
274:デフォルトの名無しさん
08/05/22 18:38:08
さらに彼の欠点はコンパイラの実装者よりも言語ユーザーを重視した設計をすることだ。
EC++ の設計を見習うべきです。
275:デフォルトの名無しさん
08/05/24 21:04:40
つまりCをつかってりゃよかったって話なのか？
276:デフォルトの名無しさん
08/05/26 00:11:25
その通り。
ためしにCを知らない新人にいきなりC++を勉強させてみるとよい。
C++のプログラムを作らせるとCを知らないはずがCスタイルになる。
つまりCは人間の直感に合っているのだ。
277:デフォルトの名無しさん
08/05/26 00:29:03
言いたいことは分かる気がする。
俺1人でプログラムを書くと、核となる処理は結局、手続き型。
ただ、OOP言語だと、その部分をうまく書くために、
いろんなクラスを書くという感じになる。
278:デフォルトの名無しさん
08/05/26 07:31:34
赤ん坊を無人島に放置して勝手に育ってｾｯｸﾙのやり方もわからない状態を
人間の直感にあってるとか言われてもねぇ
279:デフォルトの名無しさん
08/05/26 10:32:00
>>276
「数学を学ばないと未知数を x と書かずに○と書く」みたいな話だな。
「抽象的なものは勉強すべき」ということは欠点でもなんでもないんじゃないの？
280:デフォルトの名無しさん
08/05/26 17:37:34
>>276
そんなに直感にあった言語だったら今頃大学生は皆Cが書けるように
なってるはずだが。
それどころか現実は日本の技術者激減で国家滅亡の危機なわけだが
281:デフォルトの名無しさん
08/05/26 18:20:57
古い言い伝えを思い出すな。
紀元前七世紀、エジプト王プサメティコス一世は臣下に命じ、生まれたばかりの赤ん坊を一切のプログラミング言語とは無縁に育てさせた。
そして赤ん坊がある程度大きくなった時、ある質問をした。
「"Hello world"はどう記述する？」
答えて曰く「# include <stdio.h>
int main(void) {printf("Hello, world!\n"); return 0;}」
王はC言語が最古のプログラミング言語だと確信したという……。
282:デフォルトの名無しさん
08/05/26 18:35:03
AとBはどこ行った?w
283:デフォルトの名無しさん
08/05/26 19:40:52
勝手に確信する分には別に構わんが、言い伝えるのは勘弁してほしいな
284:デフォルトの名無しさん
08/05/26 22:53:10
駆逐できそうにないですね
285:デフォルトの名無しさん
08/05/26 23:09:44
>281
俺が3丁目の角のタバコ屋の長老から聞いた話だと、その王様がCで
バベルの塔問題を解かせようとプログラミングをしていたら、OOPの神様が
お怒りになり、kill -9の雷を降らせ、以降言語がC++やらObjective Cやら
JAVAやらC#やら諸々へと分裂していったと。
そして、崩れ落ちるcoredumpの中で最後に残っていたのがCshだったそうな。
286:デフォルトの名無しさん
08/05/26 23:23:47
>>276
素人の直感は専門家の正しい知見から180度ずれるという宇宙的な法則があってだな･･･
たとえば、システムヘッダの中で、アンダーバーで始まる名前が
多用されているのを見て、そのまま真似したりする。
30度でも90度でもなく180度だ。これは物理的な必然だ。･･･いや、忘れてくれ･･･
287:デフォルトの名無しさん
08/05/27 09:00:15
そして、C++のOOPを覚えたと思ったら、また180度ずれて、トータル360度ずれて元に戻る。
まさに真理の哲学ですね。
288:デフォルトの名無しさん
08/05/27 20:27:43
CプログラマがC++を使わない理由を探す理由を知りたい。
289:デフォルトの名無しさん
08/05/27 20:47:04
その前に>>288がなぜそんなことを聞くのか理由を知りたい
290:デフォルトの名無しさん
08/05/27 20:50:18
>>288組み込み系では、Cが最適開発環境であることは多い。
291:デフォルトの名無しさん
08/05/27 21:49:33
CプログラマってCだけしか使ってない人？そんなひといるのかな。
少なくともLLの一つや二つは使ってるでしょ。C++は要らないけど。
292:デフォルトの名無しさん
08/05/27 22:07:11
C言語と日本語と英語が使えます。
293:デフォルトの名無しさん
08/05/27 23:42:22
その昔、asahi.comでの求人でプログラマ職若干名ってのがあってね、そのときの
条件ってのが「言語: C言語(日常会話レベル)」だったってのが冗談じゃなくてあった。
職場で同僚とためしに「 printf("hello, world!\n");」「break;」とやってみたが、
ゴメン、俺には無理だわと応募をあきらめた。
294:デフォルトの名無しさん
08/05/27 23:58:49
うちの場合は
「CよりC++のほうがいいのは分かったよ、でも使いません」
のような感じでいつも終わってしまう。
295:デフォルトの名無しさん
08/05/28 00:17:12
考えるのがめんどくさい
息をするのもめんどくさい
296:デフォルトの名無しさん
08/05/28 00:20:34
ゆうちゃんとめんどくさいさい
297:デフォルトの名無しさん
08/05/29 20:16:05
組み込みで使うとかいわれても幅が広くてわかりにくいんだが
携帯ゲーム機用ソフトとかもCで組んでたりすんの？
298:デフォルトの名無しさん
08/05/29 20:44:31
GBAのときはCの方がC++より多かったと思う。今は分からない。
299:デフォルトの名無しさん
08/05/29 21:27:12
なるほど、GBA⇒DSだと性能差は十倍にもなってない感じだし
まだCが多かったりするんだろか。PS3が組み込み系に分類されてたり
携帯電話を組み込み系と言ったら笑われたり、俺にはよくわからん
300:デフォルトの名無しさん
08/05/29 22:48:42
>>299
>携帯電話を組み込み系と言ったら笑われたり
そうなの？ カーナビと携帯は組み込みの2大巨頭だと思ってたよ。
301:デフォルトの名無しさん
08/05/29 23:55:42
「JavaVM乗るような潤沢な環境を組み込みと言うかｗｗ」
っていう考えの人も居るっていうだけの話だが、
実際組み込みって言葉はピンキリで随分曖昧な気がする
302:デフォルトの名無しさん
08/05/30 00:39:26
>組み込みで使うとかいわれても幅が広くてわかりにくいんだが
幅が広いからCでないと厳しい環境もあるっていうんじゃダメかね？
オレが今取りかかってるシステムはRAMが32Kしかないんだが
Cとアセンブラ以外使おうとは思わないよ。とにかくリソースがぎりぎり。
処理時間、セクションやスタックの使用量とかも仕様で出さなきゃならんしな。
必ずしもプロファイラがあるわけでもないし。
303:デフォルトの名無しさん
08/05/30 01:27:45
>301
大量に生産するため、リソースを贅沢にすることは即コストに直結する。
開発コストよりも製造コストが重視される。それが量販製品における
組み込み系の特徴の一つ。携帯電話はこれが極端に当てはまる。
JVMが乗っかるのは潤沢な環境なのではなく、それがために他にくるしわ寄せを
吸収しなければならない分、余計につらいってことだね。
正直、いくら携帯電話の機能が大きくなったといっても、本当にリソースが
豊富に使えるなら、基本が機能追加でコードの流用が効く携帯で、毎度毎度
あそこまでデスマにはならない。
304:デフォルトの名無しさん
08/05/30 01:42:25
アセンブラで組むのが一番だと思うが、極端に可読性が落ちる。
C++だと余計なことをしてくれて自分が望むアセンブラに展開してくれない。
だからC。
305:デフォルトの名無しさん
08/05/30 18:08:50
C++ が C と比較してコンパイル結果を予想しにくくしているものは以下のよう
なものがあると思う。逆にこれらを使わなければほぼ予想通りのコンパイル結果
になるはずだ。
- 非 static メンバー関数の暗黙の this の存在
- コンストラクタからの基本クラスとメンバ変数のコンストラクタ自動呼び出し
- デストラクタからの基本クラスとメンバ変数のデストラクタ自動呼び出し
- 静的変数のコンストラクタとデストラクタの呼び出しとそのタイミング
- コンストラクタを持つ静的局所変数の暗黙の初期化チェック
- 自動変数のデストラクタの呼び出し
- 暗黙の型変換の呼び出し
- 一時オブジェクトのデストラクタの呼び出し
- 仮想関数の呼び出しオーバーヘッド
- 実行時型情報の時間コストと空間コスト
- 多重継承と仮想基本クラスによるオーバーヘッド
- メンバーポインタ操作の時間コスト
- 例外処理の時間コスト (特にデストラクタを持つ自動変数が存在するとき)
- inline 関数の出力コード (ただし大域最適化したときはCでも同じ)
- 複雑なテンプレートの出力コード
- 実体を持たない const 変数がある (ただし大域最適化したときはCでも同じ)
306:デフォルトの名無しさん
08/05/30 18:09:21
C++ に慣れてくれば上のような機能を使っても C 並にコンパイル結果を予想
できるようになってくる。ただし複雑なテンプレートの出力コードの予想はか
なり難易度が高い。
C でもがんばれば上のような機能を実現できるが、結局 C++ の速度と変わら
なくなってしまうはずだ。そのようなソースコードのメンテナンスはよほどの
天才でないとできないと思う。
自分が考える C++ の欠点は
- 複雑なテンプレート使用時のコンパイル時間
- テンプレートと名前空間により中間ファイルのサイズが膨張
- コンパイラのバージョン間で ABI が変わりやすい
- 仕様が大きいので学習が大変
307:デフォルトの名無しさん
08/05/30 21:23:52
さらに C++ の欠点の追加
- 標準準拠度の高いコンパイラが少ない (特にテンプレート)
- テンプレート関連のエラー表示が分かりにくい
308:デフォルトの名無しさん
08/05/30 21:38:24
C++の一番の欠点は、そうやっていちいち他の言語に対する「自分が有利と思う点」を
開陳してまわらないと気がすまない、鬱陶しい奴が多いことだろう。
309:デフォルトの名無しさん
08/05/30 21:53:45
ピアソンやオライリーの本に書いてあることを垂れ流してるだけじゃね？
スレの流れのリソースが厳しい環境での答えにもなってなければ
スレの主題への評価にもなっていない。
310:デフォルトの名無しさん
08/05/30 21:56:59
>>308
どのレスの話？
311:デフォルトの名無しさん
08/05/30 22:19:31
>>308 それは言語の欠点ではなく俺の欠点だ。
>>309 ピアソンやオライリーの本はよく読んでいるから影響を受けているに違いない。
しかしこれ以外の本よく読んでいる。
コンパイル結果を予想できればある程度必要なリソースの見積もりが可能だ。
そしてリソース消費がCとほとんど変わらないプログラムをC++で作れる。
さらにバイト単位でリソース消費を抑えたければ最適化無しのアセンブラで組むしかない。
C++がCの代わりになるかもしれないことを主張しているのだからそれほどスレの
主題から離れていないだろ。
312:デフォルトの名無しさん
08/05/30 22:30:05
>>305
>逆にこれらを使わなければ
C でオケ
313:デフォルトの名無しさん
08/05/30 23:15:52
>>312
だな。>>305をコーディング規約にでも書いた日には
「Cでいいじゃねえか!!」と言われそう。
314:デフォルトの名無しさん
08/05/30 23:57:34
Cがこれだけ普及したのは、あまり抽象化しなかったから。
このCに抽象化の手術を施したのが、C++でありJavaでありC#等々。
基本的に無理筋なんだ。
315:デフォルトの名無しさん
08/05/31 01:04:39
抽象化＝クラスと信じて疑わないのがきもい
316:デフォルトの名無しさん
08/05/31 01:25:34
>>312, >>313
>>305を使わなくてもCより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
さらに iniline 関数と const 変数(最後の項目)を使えば安全かつ効率のいいものを作れる。
後は徐々に使う機能を増やしていけばよい。
特にデストラクタの利用は効果的だ。
317:デフォルトの名無しさん
08/05/31 02:27:19
>>313
実は>>305は最後の項を除くと割りと簡単にルールを説明できる。
- コンストラクタ、デストラクタ、非 static メンバー関数を定義しない
- 多重継承を使わない
- 演算子 .* と ->* を使わない
- try, catch, throw を使わない
- inline 関数を定義しない
- template を使わない
最後の項は基本的にうれしいことなので、あえて使いたくないときは
extern を使うなり、アドレスを取得するなりすればよい。
318:デフォルトの名無しさん
08/05/31 03:05:12
>>316
>Cより遥かに安全で保守が容易なプログラムを作れるようになるのだ。
ﾜﾗﾀw
319:デフォルトの名無しさん
08/05/31 04:46:23
・安全で
・保守が用意
共にどこまで把握したことを活用できるか、という問題じゃん？
煽り地味た笑いは早計かと思ふ。
でもC++を一人で神経質にやってもそうはいかんという経験自体は誰もが持ってるだろうしな
共同作業時の問題とか考えると尚更なあ
OOPの幻想
デザインパターン振り回してテンプレート禁止とか言い出すSmalltalk厨の上司
JavaScriptなんて素人の言語だとか時代遅れな事いいやがって
手前の遅刻を棚に上げて帰るのが早過ぎるとかどの面下げて言う
間違った仕様書いといて実装に逆切れしやがって 徹夜して直すと自己管理ミスとかもうね
原付のブレーキ切ったろか
切るべきか 切るべきだな けけけけけけ
>>316
ﾜﾗ太
320:デフォルトの名無しさん
08/05/31 05:15:39
C++否定側の皮肉なジョークだろ？>>305,>>316
321:デフォルトの名無しさん
08/05/31 14:01:59
すこし見ていないうちに話のレベルが少し上がっているな（笑）。まあ、
「新規の言語はすべて旧来の言語のアンチテーゼ」
ある時点で一気に主流になった言語を駆逐するのもそう簡単ではないだろ。
新たな概念も良いけど「誰でも理解できる」という条件を満たさないと意味がない。
「誰でも理解できる」「簡潔に書ける」「効率」等の条件を満たさないと・・・
考えているうちに「自分が生きている内に駆逐されるなら、是非それを経験したい」と思ったよ。
322:デフォルトの名無しさん
08/05/31 19:51:13
>>321
駆逐されたと言う基準はなんだ?
COBOLやFORTRANは駆逐されたのか?
君の生まれる遥か前に生まれたと思うぞ、FORTRANは51歳で未だに現役だ。
323:デフォルトの名無しさん
08/05/31 20:09:07
>>320 決してジョークではない
今までの流れからCプログラマ(特に組込み系)のC++に対する懸念は以下の2つと考えている。
- 生成されるコードが大きくて遅い(例えベターCとして使っても)
- 暗黙の処理によって生成されるコードやリソースが予想しにくい
コードの大きさと速さに関しては、ゼロオーバーヘッドルールによってCのソースコードを
C++コンパイラでコンパイルしてもほぼ同じになると考えてよい。
(ただし最適化の出来が悪いとそうならないときがある)
しかもC++はCとの(道理にかなった)非互換性を選択したことでCの危険なプログラムを
エラーにすることができる。特にコンパイル時とリンク時の型安全の検査は有名だ。
予想しにくい件に関しては>>317のルールに従い、さらに以下のC++機能を使うとよい。
- うっかりミスの防止する機能
非先頭変数宣言、アクセス指定子、C++キャスト演算子、new演算子、参照
- プログラムを組織化し、大規模化しやすくする機能
継承、staticメンバ(関数と変数)、入れ子構造体、構造体内typedef、名前空間
- あれば便利、見通しをよくする機能
関数と演算子のオーバーロード、デフォルト引数、構造体タグ名が型名
これらの機能は全くオーバヘッドがないか、Cと同じぐらい処理が自明だ。
そしてプログラムを安全にし保守を容易にする。
324:デフォルトの名無しさん
08/05/31 20:21:23
>>323
>決してジョークではない
ジョークじゃないなら、そろそろ終わりにしなよ
見ていて辛いわ
325:デフォルトの名無しさん
08/05/31 20:26:55
なら見るのを止めるのがおすすめ
326:デフォルトの名無しさん
08/05/31 20:30:07
やっぱりネタかよw
327:デフォルトの名無しさん
08/05/31 20:34:48
C++を知らないから使っていないんだという前提が痛過ぎる
328:デフォルトの名無しさん
08/05/31 20:40:41
>>323
所で、VC++の最適化にはすばらしいものを感じているが。
今のC言語にあそこまでに最適化があるのか？
無ければ、VC++でCらしく書いたほうが優秀と思われ。
VCのはいたASM見たこと有る?
329:デフォルトの名無しさん
08/05/31 20:46:37
ここはC++を無理矢理Cとして使うスレだっけ?
330:デフォルトの名無しさん
08/05/31 21:28:23
いくらなんでも、非静的メンバ関数の使用はありだろ。
暗黙の引数thisが予想できないというのが理解できない。
普通の関数で引数1つ増えるのと比べて何もオーバーヘッドは変わらない。
むしろ呼出規約によってはthisだけレジスタ渡しになって、素の状態ではやや有利な場合すらあり得る。
331:デフォルトの名無しさん
08/05/31 21:36:05
時折Objective-Cを思い出しては、絶望するスレ。
332:デフォルトの名無しさん
08/05/31 22:17:11
ObjC はとっても C 的で良いんだけど、C を置き換える為の物ではないよね
333:デフォルトの名無しさん
08/05/31 22:18:00
字面がｷﾓすぎ
334:デフォルトの名無しさん
08/05/31 22:25:31
事実上Apple版DLRになってるObj-Cランタイムに価値がある訳で
CからObj-Cランタイムを扱うための言語拡張に過ぎないとも言える
C++やC#とは狙いが違う感じ
335:デフォルトの名無しさん
08/05/31 22:26:07
ここのC++厨はPC上で動くアプリしか作ったことないんだろ。
秋月のキットでも買って出直してこいよ。
336:デフォルトの名無しさん
08/05/31 22:28:02
どんな言語でも見た目が気になるのは初学者のうちだけだよ
文法がまずいとそうもいかないけど
337:デフォルトの名無しさん
08/05/31 22:30:24
>>335
恐らくウィンドウズ以外の経験が全く無いんだろうさ
338:デフォルトの名無しさん
08/05/31 22:44:40
C を駆逐出来るのは C だけだな。C++ は失敗作。
誰か C 1x の仕様策定プロセスを始めてくれないかな。
339:デフォルトの名無しさん
08/05/31 23:03:54
Cから発生した言語は、みんなそのルートを通る。
いまさら新しいCを作ってどうする?
340:デフォルトの名無しさん
08/05/31 23:05:18
どのルート？
341:デフォルトの名無しさん
08/05/31 23:09:53
Cを継承する、拡張する、駆逐する、いわゆる後継のために。
C++も最初はCにクラスが付いただけの言語だった。
342:デフォルトの名無しさん
08/05/31 23:12:46
C++ はもう良いだろ。C を駆逐するのに失敗した言語はスレ違い。
343:デフォルトの名無しさん
08/06/01 00:06:27
CはC99で失敗したからもう発展しない。
VCはC99未対応、gccは -std=c99 が必要
344:デフォルトの名無しさん
08/06/01 00:08:52
VCは要らん
345:デフォルトの名無しさん
08/06/01 00:42:17
>>328
さすがにCとC++の最適化ルーチンは共通化しているでしょう。
疑いもしていないので調べたことはないけど。
346:321
08/06/01 11:47:24
>>322
曖昧な言葉「駆逐」の定義をまた始めるのか？自分はそれに参加する気はないね。
ここはスレタイに曖昧な言葉を使った雑談スレだと思っていたぞ。
レス内容に対してレスせずに発言者に対してレスする、このようなレスがレベルを下げるのを理解して欲しいね。
#答えよう。自分はFORTRANより年上だ。
347:デフォルトの名無しさん
08/06/01 12:01:43
間違いなくここは雑談スレだけど、それを表立って表明してはいけない約束だぜ。
つか、この板のほとんどのスレが雑談スレだ。初学者には雑談以上の話かもしれんけど。
348:デフォルトの名無しさん
08/06/01 13:00:25
C++がCを駆逐できなかったのはJavaのような誇大広告を怠ったからだよ。
「C++は2年以内にCを完全に殺す」のような宣伝をしていればCにダメージを与えていたのに。
あの会社の立場上難しいだろうけど。
349:デフォルトの名無しさん
08/06/01 14:36:50
Why I No Longer Like or Use C++
URLﾘﾝｸ(www.hyuki.com)
350:デフォルトの名無しさん
08/06/01 14:55:59
>>349
C++ではなくCを使う理由にはなっていないんだよ。
環境によっては Java, C#, Python, Ruby などを使う理由にはなるが。
351:デフォルトの名無しさん
08/06/01 15:00:47
>>350
言語が単純で、枯れていて、速くて、資産が沢山あって、
スクリプト言語との連携が良いからだよ。Cでなければ
いけない理由は無いが、C以外にそんな言語は無いからな。
352:デフォルトの名無しさん
08/06/01 15:03:35
原文のほう見ると
URLﾘﾝｸ(prophipsi.blogspot.com)
このスレで先ほどまで力説してた誰かのようなコメントがいきなりついてますな。
353:デフォルトの名無しさん
08/06/01 15:07:09
うーん、やはり見えない敵と戦うタイプだな。
いっそこのスレに呼べばいいんじゃないか？
Another common theme among the posters was that one can get by just
fine in C++ by ignoring the more complicated aspects of C++ and just
focusing on the basic procedural and object oriented features of C++.
In practice this means never touching templates and focusing on class
and function based abstractions. I guess use of exceptions and MI
would be optional and handled on a case by case basis.
I actually don't have a problem going this route. The problem is that
this is NOT the route that the C++ standards people are going and it
certainly isn't the route the C++ literati/intelligentsia are going.
354:デフォルトの名無しさん
08/06/01 15:50:27
>>351
>言語が単純で、枯れていて、速くて、資産が沢山あって、
>スクリプト言語との連携が良いからだよ。
>>317で残った部分は十分に単純で枯れているぞ。
そして速さはCと同じでCとC++の資産も使えるぞ。
スクリプト言語との連携もインタフェース部分だけ
extern "C" すればいいぞ。
>C以外にそんな言語は無いからな。
さらに>>323の機能を使えば安全で便利だぞ。
C++もそういう言語として使えるんじゃないか?
355:デフォルトの名無しさん
08/06/01 16:11:02
「残った部分」とかんな抽象的な。
言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
毎回チェックするのも大変だし。
>>317で禁止されてる項目はC++がCに比べておいしい所そのものなわけで
これ禁止なら素直にCを使ったほうが早い。
356:デフォルトの名無しさん
08/06/01 16:23:52
>>354
>>>317で残った部分は十分に単純で枯れているぞ。
もう 317 は忘れろ。二度と俺にその話を振るな。
誰も賛同しない物を何でここまで引っ張るかね。
357:デフォルトの名無しさん
08/06/01 16:27:45
もうC++のことは忘れろ。C++はJavaに負けたんだよ。
MSでさえC++は捨ててJavaのパクリを推奨してる。
358:デフォルトの名無しさん
08/06/01 16:32:12
>>355
同意だな
>>317ルールは論外だろ
ちっとも美味しくもなんとも無い"better C"とやらを使うことによって、
少なくともC++のグダグダのABIと、それによるコンパイラ間
非互換性といったおマケはついてくる
それならCのほうがずっといい
無論C99ではなくC89な
359:デフォルトの名無しさん
08/06/01 16:40:41
10 年前ならいざ知らず、今時 C++ をこれだけマンセーするなんて
どれだけ時代が読めないんだろうねえ。しかも中途半端な俺ルールを
ゴリ押ししようだなんて驚くわ。C++ は仕方が無く細々と使うもんだぜ。
360:デフォルトの名無しさん
08/06/01 18:44:34
>>355
>言語仕様にある限り、使うバカは後を立たないし自分も忘れてうっかり使ってしまうこともある。
「言語仕様にある限り使う」と言われればそれまでだが、高々7つ単純な項目ぐらい意識して
開発できるでしょう。しかもinline関数と定数としてのconst変数はいい意味で期待はずれの
結果になるだけで一般的にはルールから外してもいい。さらに暗黙の this を許容できれば
もっと単純になる。
一番簡単なのはプロファイル定義をコンパイラに指定できればいいと思っているが。>>265
>これ禁止なら素直にCを使ったほうが早い。
個人的な経験から>>323の機能があればCと比較して十分開発がやりやすくなると思っている。
本当はデストラクタを使えれば最高だが、見えにくいオーバーヘッドは避けられないので
敬遠されるだろう。
361:デフォルトの名無しさん
08/06/01 18:45:01
>>358
>C++のグダグダのABIと、それによるコンパイラ間非互換性といったおマケはついてくる
まあ>>306でも少し触れたがこれはC++の有名な問題だ。
これを避けるためにboost風のライブラリ命名規則を使ってバイナリを分けたり、
ライブラリのインタフェースのみをCにして実装をC++にするという方法もある。
ABIの問題はC++の利点に比べれば小さいことだと思ってる。
Cでも全くABI問題がないわけではないし。
362:デフォルトの名無しさん
08/06/01 19:35:33
> ABIの問題はC++の利点に比べれば小さいことだと思ってる。
いや、その「C++の利点」を自ら自分ルールで縛りましょうと
言ってるから突っ込まれてるわけだろ。クラスもテンプレートも捨てるのでは
C++の利点の大半をドブに捨てているのと同じだ。そしてABIの欠点は
残る。
ただの自分ルールだから、違反してもコンパイラでチェックも出来ないし
共同開発のチームのメンバに糞ったれなルールを周知し押し付けるための
コストもかかる。
C++のABIの問題は決して小さくは無いだろ。
何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
363:デフォルトの名無しさん
08/06/01 23:48:27
>>362
>>360にも書いたがチームメンバの問題はそれほど深刻ではないと思っている。
組織が大きくても検査ツールの導入ぐらい(Cプログラムの保守に比べれば)
たいしたコストでもないだろうし。
ちなみに>>317ではクラスの禁止は提案していないぞ。もちろん単一継承の禁止も。
これらのルールはあくまで動作が読みにくい機能を最高に削っただけで環境に合わ
せて緩めるべきだ。
>何のためにCOMが出来て、何のために黒歴史化しつつあると思ってるんだ。
COM的なものをC++のABI問題の解決のために利用しているのは少数派でしょ。
個人的にその手のものをC++で使ったのはDirectナントカぐらいしかないよ。
多分COMの人気がなくなったのは.NETの影響じゃないか? .NETじゃCの代わりに
なるとは思えないが。
364:デフォルトの名無しさん
08/06/02 19:50:18
>>363
>チームメンバの問題はそれほど深刻ではないと思っている。
君のチームがどんなプロジェクトで何を作っていて、
どんな人員構成かも分からんのに参考にはならんよ。
ここの人間がどう思っているかは既に分かってるだろ。
君のローカルルールを採用したい人間は誰も居ない。
検討するだけの価値がある様にも思えない。
365:デフォルトの名無しさん
08/06/02 22:13:53
結局Ｃは現役続行てことでおｋ？
366:デフォルトの名無しさん
08/06/02 22:38:52
今Cが使われてるのって、ファーム、ドライバ、OSのカーネルとかか？
それらを駆逐すればいいんじゃね？
367:デフォルトの名無しさん
08/06/02 23:03:35
なんか抽象化の方策でもあるのか？
368:デフォルトの名無しさん
08/06/03 01:41:34
>>364
>君のローカルルールを採用したい人間は誰も居ない。
>検討するだけの価値がある様にも思えない。
何も俺のルールである必要はないんだぞ。あくまでも1つの例として出しただけだから。
強制しているように見えたなら悪かったよ。
Cで生産性上げるためのもっといいアイデアあったら教えて。
369:デフォルトの名無しさん
08/06/03 01:44:25
クソコードをチェックしてくれるデバッガーを大量に雇う
370:デフォルトの名無しさん
08/06/03 01:55:16
そーいえばEC++(embedded C++)ってどーなってるんだ？
あれってリソース要求がシビアな環境向けのC++なんじゃなかったっけ
371:デフォルトの名無しさん
08/06/03 02:08:16
>>370
御大のお言葉をよくお聴きなされ
URLﾘﾝｸ(www.research.att.com)
> "To the best of my knowledge EC++ is dead (2004),
> and if it isn't it ought to be."
try, catch, throw を使わない、template を使わない、
多重継承を使わない C++ のサブセットなんてダメだってさ。
372:デフォルトの名無しさん
08/06/03 12:37:11
>>370
名前空間がないのが信じられない。実行のオーバーヘッドは全くないのに。
しかもそのせいでサブセットですらなくなった。
373:デフォルトの名無しさん
08/06/03 18:00:11
embeddedだからってサブセットにする必要性がない。
ランタイムライブらっりを小さくし、必要に応じたライブラリを使えばいいだけだし。ちょっとテンプレートの使い方を工夫すれば小さくなるもん
374:デフォルトの名無しさん
08/06/03 21:17:58
小さいの概念がデスクトップとは違うんだろう。
例外機構も入れたくないくらい小さくしたいみたいだから。
375:デフォルトの名無しさん
08/06/03 22:33:22
EC++はC++を小さくするというコンセプトはいいのに
小さくするやり方がまったくおかしいので使い物にならん
仕様考えた奴はC++をよくわかってないアホとしか思えん
376:デフォルトの名無しさん
08/06/04 00:53:36
確かEC++は日本人が中心になって考えたんだよ。
電機メーカーはコンパイラ作りになれていないからコンパイラの実装が楽な
仕様を選んだんじゃないか。
377:デフォルトの名無しさん
08/06/04 03:30:33
某h立で集まった人員の中でパーサ経験ある奴が俺しかいなかったな
コンビネーションパーシングの考え方／作り方の講習係で終わった
その後どうなったのやら話も聞かんけど、C++のサブセット作りたがってたのだけは記憶しとる
378:デフォルトの名無しさん
08/06/04 09:21:02
>>376
コンパイラの実装が楽なはずの機能まで外れているし
何考えてるんだか俺には全くわからない
379:デフォルトの名無しさん
08/06/04 20:07:08
>>378
バイナリのサイズを小さくする
コンパイラの実装を平易にする
これら以外の目的で削られた機能って具体的にどれの事を言ってるの？
380:デフォルトの名無しさん
08/06/05 01:26:39
378じゃないけど namespace
削った目的は分からない。
リンクが済んだらバイナリのサイズは変わらない。
実装は2週間以内が目安(D&Eより)、もちろん実装者によって違うが。
381:デフォルトの名無しさん
08/06/05 02:13:47
namespaceを無くすると名前マングリングが単純化できて、C互換のobjが吐けるとか？
382:デフォルトの名無しさん
08/06/05 03:17:22
>>381
名前マングリングはtype-safeリンケージのために名前空間なんぞを
導入するずっと前から行ってることだろ
オーバーロードのようなものがある限り、type-safeリンケージは必須だ
383:デフォルトの名無しさん
08/06/05 20:30:38
必要ならextern "C"を使えば済むとは思う。
どうでもいいかもしれないけど、
extern "C"が名前空間内でも使用可なのには最初驚いた。
384:デフォルトの名無しさん
08/06/06 22:50:16
const_cast, reinterpret_cast, static_cast, mutable も性能に影響を
与えないし実装は比較的簡単だと思う。
dynamic_cast だけ外すと分かりにくい仕様になるかもしれないが。
385:デフォルトの名無しさん
08/06/07 00:21:26
組み込み向けで小さいコードしか書かないから、きっと要らないのだろう。
386:デフォルトの名無しさん
08/06/07 09:42:06
コンパイラを実装する人の都合で削ったように見えるな。
C++からCへ変換するプリプロセッサで実現できそうな機能しか残ってない。
387:デフォルトの名無しさん
08/06/07 14:12:32
>>386
>コンパイラを実装する人の都合
これは実際非常に重要なのだけれど、C++ ではツールを含めた言語環境を
作る人間と、それを使う人間が完全に分離してしまっているのが不思議。
388:デフォルトの名無しさん
08/06/07 14:33:41
C++談義でもりあがってるところ悪いけど、そんなことより
FORTRAN 77をさっさと完全駆逐してほしい。算術IFとかなんだよあれ。
大文字コードはSQLだけで充分だ。
389:デフォルトの名無しさん
08/06/07 14:40:43
>>388
FORTRAN は多分大型コンピュータと共に死滅するんじゃないかな？
390:デフォルトの名無しさん
08/06/07 14:46:31
いやいや、Fortran 90以降は好きだし使ってるけどな。2kからは
オブジェクト指向になるらしいし。Fortran 77がクソ過ぎて困る。
391:デフォルトの名無しさん
08/06/07 18:17:24
高速な数値計算が必要なところは FORTRAN で作って extern "FORTRAN" で
C++ から呼べばいいんじゃないか?
392:デフォルトの名無しさん
08/06/07 18:20:30
それを更に C で wrap して Fortran から呼び出したらいいんじゃない？
393:デフォルトの名無しさん
08/06/08 00:59:14
>388
算術IF文と論理IF文までしかなかったのはFORTRAN 66。
FORTRAN 77ならブロックIF文が使えるはずだが。
算術IFが廃止されたのはFORTRAN 95からだが、過去の資産の使いまわしに困る
ようなFORTRANに存在価値ってあるのかな。
394:デフォルトの名無しさん
08/06/08 01:10:18
>>393
>、過去の資産の使いまわしに困るようなFORTRAN
FORTRANってベクトルマシンと趣味ユース以外で使われてんの？
395:デフォルトの名無しさん
08/06/08 01:42:38
微妙な計算ライブラリとか結構使われている。
自分が関わった某産業分野の制御でも使ってた。
396:デフォルトの名無しさん
08/06/08 02:15:24
そうなのか。
……未だに何故Fortranなのかが判らん分野なんだよなー。
Haskellやmlなんかの関数型も数学向いてるって聞くけど
取って代わられる可能性あんのかな
397:デフォルトの名無しさん
08/06/08 03:58:14
秘伝のソースを一子相伝で守り続けている世界だよ
魔法が息づいているうちは、早々簡単に取って代わられない
398:デフォルトの名無しさん
08/06/08 18:23:42
楽にプログラミングしたい訳では無くて、楽に計算させたいだけだからね。
学術計算用途ではFortranが長いこと使われててライブラリが豊富にあった。
Fortranから他への移行なんて、ここ10年くらいの話じゃないかな？
それもCとかC++だから、数値計算を専門でやってる人以外は、Fortranの
ほうが楽でいいじゃんとか思う人も多いわけよ。別に困ってた訳じゃないから。
399:デフォルトの名無しさん
08/06/08 18:29:53
Cは蓄積だけでなく、実際実際ベクトル／行列計算の分野では
性能的にFortranに勝てんのでしょ
C++は式テンプレートのような遅延評価での高速化テクニックが最近
出てきてるようだけど、どうなんだろう
400:デフォルトの名無しさん
08/06/08 18:52:01
ベクトル／行列計算の性能を追求するなら、Linuxでクラスタ組んで
Cのライブラリを使うのが主流。
スパコンTOP500とかに並んでるのは、ほとんどそういう用途だわな。
401:デフォルトの名無しさん
08/06/08 18:57:26
Cには多次元配列がない、C99まで標準にはrestrictポインタがない、
複素数がないとかいろいろあるからなあ。科学技術計算にC++とかは
お笑いなんで無視していいけど。
402:デフォルトの名無しさん
08/06/08 19:27:12
>>401
>科学技術計算にC++とかは
>お笑いなんで
そうなんか。識者とお見受け
後学のために詳しく聞きたいです。その用途でC++の難点って例えばどんなあたりですか？
403:デフォルトの名無しさん
08/06/08 19:37:58
PGI とか C++ にも対応してるけど、科学技術計算でダメなんか?
まあ C++ なんかどうでも良いけど。
404:デフォルトの名無しさん
08/06/09 22:52:58
スパコン使う分野はともかく現在の数値計算の最前線(新米二等兵とも言う)では
圧倒的にC++が使われているよ。
Fortranの時代と比べてどちらがマシかは判断しかねる。
405:デフォルトの名無しさん
08/06/11 18:53:28
CもC++も、<適度に・中途半端に>なんでもやれる言語だからね、良くも悪くも。
406:デフォルトの名無しさん
08/06/11 19:06:05
C よりも C++ を先に駆逐して欲しいな
既に朽ち始めているから気に病む必要も無いかもしれんが
407:デフォルトの名無しさん
08/06/11 20:31:32
逆に Java や C# に限界を感じて C++ は再評価され始めているんじゃないか?
408:デフォルトの名無しさん
08/06/11 20:41:02
JavaやC#の限界ってなんのこと？
409:デフォルトの名無しさん
08/06/11 21:09:19
VMの外の人と話せないこととか
410:デフォルトの名無しさん
08/06/11 21:49:55
つ JNI
411:デフォルトの名無しさん
08/06/11 21:57:42
むしろＣ＋＋が再評価ってなんのこと？？？
412:デフォルトの名無しさん
08/06/12 09:27:16
C++/CLIのことだろう
413:デフォルトの名無しさん
08/06/12 11:00:04
>>412
あれ便利っつーか楽っつーか、確かにいいんだけど
言語仕様としては究極の汚さだよなあ。
414:デフォルトの名無しさん
08/06/13 18:10:15
Javaのようにオブジェクト指向を強制する言語には限界がある。
C++のように、低水準プログラミング、構造化プログラミング、OOプログラミング、
テンプレートメタプログラミングを混ぜて使えるほうが現場で役立つ。
415:デフォルトの名無しさん
08/06/13 19:05:32
1 行目と 2 行目以降は全く関係無いね
416:デフォルトの名無しさん
08/06/13 21:16:58
役立たないとはっきり書いてほしかったのかな?
417:デフォルトの名無しさん
08/06/13 21:18:29
自己紹介には及ばん
418:デフォルトの名無しさん
08/06/14 17:00:28
アセンブラから見てCってどうなの？
419:デフォルトの名無しさん
08/06/14 17:08:30
ブロックの先頭でしか局所変数を宣言できない C90 の仕様は勘弁してほしい。
あと inline 関数が標準化されていないのも困る。
組込み環境ではそれだけの理由でも C++ の方を使いたいよ。
無理やり C を使わせられたら発狂しそうだ。
420:デフォルトの名無しさん
08/06/14 17:10:57
C99 か GCC でオケ
421:デフォルトの名無しさん
08/06/14 17:14:18
#define INLINE _inline
422:デフォルトの名無しさん
08/06/14 17:26:15
#pragma inline 使うコンパイラがあるので #define だけではすまない。
423:デフォルトの名無しさん
08/06/15 00:49:57
そこで_Pragma演算子よ、って結局C99というオチ。
424:デフォルトの名無しさん
08/06/15 00:55:33
C++
425:デフォルトの名無しさん
08/06/15 13:00:19
C以外の中級言語つくろうって動きはないのかね
426:デフォルトの名無しさん
08/06/15 13:44:05
Dは無視ですか、そうですか
427:デフォルトの名無しさん
08/06/15 15:36:22
C90 はポータビリティを考えたら外部識別子が 6 文字までしか使えないから使いにくい。
C++ は 1024 文字まで保障されている。
428:デフォルトの名無しさん
08/06/15 15:43:45
そういやそんなのあったな・・・全く守ってねーや
429:デフォルトの名無しさん
08/06/15 16:49:15
>>427
もっともC++処理系自体にはポータビリティがないがなw
430:デフォルトの名無しさん
08/06/15 17:03:02
きっと処理系のできは時間が解決してくれるよ。
431:デフォルトの名無しさん
08/06/15 17:05:51
もう時代の審判が下るくらいの時間は経ってると思うが、
今後これ以上何かあるかなあ…
432:デフォルトの名無しさん
08/06/15 18:24:16
今の C++ コンパイラってそんなに標準準拠度が悪いの?
組み込みなら C のように標準ライブラリの一部が削られているかもしれないけど。
VC9 と GCC4.x は問題ない範囲だと思うけど、準拠度の低いのってどんなのある?
433:デフォルトの名無しさん
08/06/18 15:20:55
>>431
B言語でもやってろ
434:デフォルトの名無しさん
08/06/18 15:55:05
C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく
ないですか? 以下の開発方法しか思いつかないのですが。
- 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する
- 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを
生成する関数を用意する
- 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す
インライン関数があれば最初の方法が現実的かな。
435:デフォルトの名無しさん
08/06/18 16:40:50
- 一度定めた構造体の定義に対して互換性がなくなるような変更をしない
436:デフォルトの名無しさん
08/06/18 18:13:08
>>435
それはpointみたいに非常に単純なものでない限りは
現実問題としては無理なので、
opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな
437:デフォルトの名無しさん
08/06/18 19:18:44
何か無理やりOOをやりたいのか？C++じゃないんだが。
438:デフォルトの名無しさん
08/06/18 20:03:38
>>434
拡張子をだなcppに変えて（ｒｙ
439:デフォルトの名無しさん
08/06/18 20:44:55
>>437
OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。
C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを
使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全
でいいかもしれませんね。
コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。
440:デフォルトの名無しさん
08/06/18 23:57:02
>>434
むしろOO的には、一番目と二番目を徹底すべきじゃないのか？
C++であっても。
441:デフォルトの名無しさん
08/06/19 00:38:02
>>439
いや、構造体をクラスに見立ててOOしたいんだろ？
じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。
Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。
というわけでお前の考え方では、複数人での開発は難しくなるだろう。
これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。
無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。
お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか？
ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、
スタックは1Kしか使えないんだがどうするんだい？
オレ流OOルールをもうひとつ追加するのか？RAMも16Kに減らされそうなんだが。
442:デフォルトの名無しさん
08/06/19 00:45:25
RAMが16Kbyteもあるなんて贅沢だw
443:デフォルトの名無しさん
08/06/19 01:07:40
オブジェクト指向は言語と直行した概念だから C で OOP しても何の問題も無い。
構文の助けが無い分、面倒臭いのは我慢する必要があるけど。
URLﾘﾝｸ(www.gnome.gr.jp)
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(www.sage-p.com)
シンプルな C に多少のルールを追加するのと、カオスな C++ から便利機能を
削除するのは別次元の話だと思うよ。
444:デフォルトの名無しさん
08/06/19 02:07:30
C++はいらないけど、C++コンパイラは必要。
CのソースをC++でコンパイルすると型チェックが厳密なんで
バグ出しにたすかる。プロトタイプ宣言の型が省略可能とか
mallocが暗黙的に型変換されるとかありえない。あとNULLも0で
統一してくれ。
445:デフォルトの名無しさん
08/06/19 02:11:53
>>443
COOL 見たけどかなり面倒くさそう。
書くときの面倒くささよりコンパイラの安全性チェックができなくて
変更を間違ったときに気づかなくてバグになりそう。
これなら20年ぐらい前のC++仕様でも楽に安全に作れると思う。
446:デフォルトの名無しさん
08/06/19 02:22:14
CでOOPLならObjective-Cがあるじゃん。あれもあれで変な言語だけど。
447:デフォルトの名無しさん
08/06/19 02:28:21
Objective-C は C Compiler でコンパイル出来ないから、、、
と思ったけど POC を忘れてたわ。
URLﾘﾝｸ(users.pandora.be)
C++ より Objective-C の方が C の発想に近いよね。
448:デフォルトの名無しさん
08/06/19 02:35:35
URLﾘﾝｸ(grape.mtk.nao.ac.jp)
ここに書かれている通り C は「悪い方がよい」原則。ObjC も同じ。
C++ はどちらかというと CL の辿った道に近い気がする。
つまり「正しい」アプローチで作られた「複雑巨大システム」。
449:デフォルトの名無しさん
08/06/19 02:42:51
「悪い方がよい」原則って、意味のある言葉じゃないだろ。
いいものが定着するとなにも言わずに、悪いものが定着すると
「悪い方がよい」って言えばいいんだから。
450:デフォルトの名無しさん
08/06/19 02:46:57
>>441
抽象データ型なんて昔から C で普通にやっていることだよ。
C++ の前の C with Classes でもこれをやりやすくするためにアクセス保護を導入したし。
構造体の定義が可視ならヒープにとる必要もないしスタックにもオブジェクトを置けるよ。
定義が可視ならもちろんアクセス保護があったほうが安心だけど。
451:デフォルトの名無しさん
08/06/19 02:52:50
>>449
リンク先を読めば意図は分かると思うけど、気になるなら
「New Jersey アプローチ」と読み替えても良いよ。
452:デフォルトの名無しさん
08/06/19 02:59:11
Java も「悪い方がよい」原則のような気がする。
453:デフォルトの名無しさん
08/06/19 03:23:24
>>451
>>449をよく読めば意図が分かると思うけど、気になるなら
「悪いものが定着したときは「New Jersey アプローチ」って言えばいいんだから」
と読み替えても伊井よ
454:デフォルトの名無しさん
08/06/19 03:30:42
それ元ネタが凝った角度でモノ書こうとして失敗してる例に感じるな
タイトル先行で書き下されたかのような。
完璧を求めると複雑巨大になり弊害がある
単純さを求めると完全ではなくなり弊害がある
一長一短って話だろ なんでworse is betterやねん
455:デフォルトの名無しさん
08/06/19 08:29:56
>>454
>一長一短って話だろ
違うよ。Lisper が Lisper に向けて何故 Lisp 族が失敗したかを考察した文章で、
Lisp は敗北したという前提だから、一長一短ではなく Worse Is Better なの。
URLﾘﾝｸ(www.kt.rim.or.jp)
456:デフォルトの名無しさん
08/06/19 17:50:52
あ、なるほど。その文書読んでから読み直すと少し納得
少なくともタイトル先行な面白書きではない訳ですな
で、改めて読み直してみたけど、やっぱり俺には誤解が残る
Lispの造型が足りないせいか、頭が足りないせいかな
457:デフォルトの名無しさん
08/06/19 20:59:37
LISPの造型が足りないというのは、カッコの数が少なすぎるということかな？
458:デフォルトの名無しさん
08/06/19 21:19:58
>>455
だから、Lisperじゃない普通の人にとってはWorse is Betterには意味がない
ってことじゃないの。
こんなの何でも適当できるよ。
Linux使い「Windowsが普及してるのはWorse is Betterだから」
元共産主義者「資本主義が普及しているのはWorse is Betterだから」
チャーチル「民主主義が普及してるのはWorse is Betterだから」
459:デフォルトの名無しさん
08/06/19 21:40:30
>>457
あ、造詣か鬱氏 どうやら後者のようだ
460:デフォルトの名無しさん
08/06/19 21:43:13
>>458
よく読みな
つ URLﾘﾝｸ(grape.mtk.nao.ac.jp)
461:デフォルトの名無しさん
08/06/19 21:49:08
つうか、現実の「複雑巨大システム」であるMulticsとPL/Iの失敗への
反省・アンチテーゼとしてUnix/Cが生まれたわけで、そのことさえ抑えておけば十分。
なぜかその論文？ではその有名な事実に触れてもいないけどね。
Unixの「New Jerseyアプローチ」は、理由もなく／何も無いところから
産まれ出てきたものでは無い。
データも何も無い、分析とは言いがたい内容で、単に「Worse is Better」とか
題目だけ唱えてもそれは題目でしかなく、何の意味も無いと思う。
まあ、一種のネタ文書なんだろうな。
462:デフォルトの名無しさん
08/06/19 21:49:30
自分で考える前に質問してしまう人がいるのは何でなんだぜ？
463:デフォルトの名無しさん
08/06/19 21:50:55
>>460
ほら、自分の言葉で説明できないだろ。Worse is Betterってのは
単なるお題目なんだよ。
464:デフォルトの名無しさん
08/06/19 21:55:19
>>461
>なぜかその論文？ではその有名な事実に触れてもいない
それはそういう文脈じゃないからだよ。
当然 MIT の連中が Multics を知らない訳はないでしょ。この文脈では
彼らにとっては Multics より ITS の方が現実的な意味を持っているだけ。
そこら辺の歴史は自分で勉強してチョ。
465:デフォルトの名無しさん
08/06/19 22:01:19
>>463
文章を読んで理解出来なかった奴に説明するのは無理だよ。
それは俺の能力ではどうしようもない。諦めてくれ。
466:デフォルトの名無しさん
08/06/19 22:01:30
つまりわかりやすく言えばLisperの僻みだろ。
「こんなに素晴らしく美しい言語であるLispが天下を取れないのはなぜか？！
それは普及するものがWorse is Betterだからだ！Lispは悪くない！」
っていう発想の転換、悪く言えば現実逃避をしてるだけ。一般人には
共感が得られない。
467:デフォルトの名無しさん
08/06/19 22:03:37
>>466
君読んでないのがバレバレだよ。
468:デフォルトの名無しさん
08/06/19 22:07:03
つか Worse って言葉に引き摺られて論旨が見えてないでしょ。
別に UNIX/C を馬鹿にしてる文章じゃないんだぜ。とほほ…
469:デフォルトの名無しさん
08/06/19 22:08:13
>>465
そういう言い方がカルトくさいんだよ
「文章を読んで大作先生の素晴らしさを理解出来なかった奴に
説明するのは無理だよ。それは俺の能力ではどうしようもない。諦めてくれ。 」
とか、
「君、大白蓮華読んでないのがバレバレだよ。」
って言ってるのと変わらん。そんなの知るかボケ、と言わせてもらおう。
470:デフォルトの名無しさん
08/06/19 22:10:20
さて、自転車置き場の議論が始まりそうだから退散するとしますか…
471:デフォルトの名無しさん
08/06/19 23:08:12
>>448
俺はC++も「悪い」に属すると思う。
そうでなければここまで広まらなかったに違いない。
472:デフォルトの名無しさん
08/06/20 12:38:14
広まったのは単にMSのせいかも
473:デフォルトの名無しさん
08/06/20 13:55:19
SunはMSを潰すためにJavaを出した。MSはJavaとの共倒れを狙ってC#を出した。
474:デフォルトの名無しさん
08/06/20 14:07:48
実装が単純ならば移植しやすく広まりやすい。
正しいものを広めるより広まったものを改善するほうが簡単。
完全に正しいものを作ろうとすると最後の20%に努力の80%が費やされる。
つまり「悪い」の定義は単純な実装と最低限の品質で最大限の評価を得ること。
475:デフォルトの名無しさん
08/06/20 14:23:55
それなんてエロゲ？
476:デフォルトの名無しさん
08/06/20 19:08:09
>>472
MFCのせいでC++が浸透しないのかも
477:デフォルトの名無しさん
08/06/20 19:13:46
MFC以外のもっと使いやすいC++用RADがあったら
普及したかもなぁ・・・ってBCBは？！
478:デフォルトの名無しさん
08/06/20 19:24:27
>>477
VC++にVCLが標準装備だったらなあ
479:デフォルトの名無しさん
08/06/20 21:57:16
VCLそのものがC++で書かれていないのが痛い
480:デフォルトの名無しさん
08/06/21 10:21:37
くだすれ、落ちてねえ?
481:デフォルトの名無しさん
08/06/23 08:15:11
>>448
これだから日本語しか読まない奴は。
Worse Is Better - Richard P. Gabriel
URLﾘﾝｸ(www.dreamsongs.com)
> Decide for yourselves.
おっと。日本語訳もあった。
URLﾘﾝｸ(www.kt.rim.or.jp)
482:デフォルトの名無しさん
08/06/23 08:18:04
Jim Waldo の "Worse is worse" も翻訳があった。助かるな。
URLﾘﾝｸ(www.kt.rim.or.jp)
483:デフォルトの名無しさん
08/06/23 09:09:28
>>481-482
どっちも既に読んでるよ。ご苦労。
484:デフォルトの名無しさん
08/06/23 20:56:16
しかも前者に至っては既出
485:デフォルトの名無しさん
08/06/24 00:00:14
そんなことよりWordsworth読もうぜ！
URLﾘﾝｸ(www.bartleby.com)
486:デフォルトの名無しさん
08/06/24 00:25:54
Yeats >> Blake >>> (越えられない壁) >> Wordsworthだろ
常識的に考えて・・・
まあ、英国詩人全部合わせてもRimbaud一人に勝てないけどな
487:デフォルトの名無しさん
08/06/24 00:27:15
ランボーってベトナム帰りのあいつか？
488:デフォルトの名無しさん
08/06/24 00:29:07
元ネタだから、yesと言っても間違いじゃない。
489:デフォルトの名無しさん
08/06/24 00:38:16
Close To The Edgeは名盤だよな
490:デフォルトの名無しさん
08/06/24 20:53:56
俺はHeart Of The Sunriseの方が好き。
491:デフォルトの名無しさん
08/06/25 01:01:07
C言語のプログラマは、自分たちを一番優等だと思ってるところが問題だ。
492:デフォルトの名無しさん
08/06/25 01:54:54
つまりプログラマの殆どはそんなこと思っているのか。
493:デフォルトの名無しさん
08/06/25 08:28:14
言語の違いなんてバイオリンとピアノの違いでしかない。
道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
それと同じこと。
ただし、ヴィオリストは馬鹿だけど。
494:デフォルトの名無しさん
08/06/25 08:40:33
ベーシストをDISる厨バンドマンならいくらでも
495:デフォルトの名無しさん
08/06/25 11:04:51
>>493
>道具が違うからって音楽家は人を馬鹿にしたりしないだろ。
譬えの誤謬だ。
カズー奏者はどう頑張ってもバカにされる対象。
496:デフォルトの名無しさん
08/06/25 21:50:27
>>493
>ただし、ヴィオリストは馬鹿だけど。
(^^;;;;;
なぜ Va は自虐的なんでしょうね、てスレ違いですけど。
497:デフォルトの名無しさん
08/06/25 22:21:01
他の言語を貶す言語廚は、自分の推す言語使いこなせななくて自信がないから他の言語を貶すんだろうね。
自分の目的に合致している言語を使いこなしているのなら、他の言語なんて眼中にないだろう普通
498:デフォルトの名無しさん
08/06/25 22:27:33
>>497
誰しもそこから出発するわけでして、許してあげましょうよ。
499:デフォルトの名無しさん
08/06/25 22:30:02
このスレの主旨はそういう言語戦争とは違うと思うけど？
そろそろCに変わる言語が欲しいね、という前向きな話だよ。
500:デフォルトの名無しさん
08/06/26 02:44:29
BCPLとK&Rの頃から愛してる
C99になってもっと恋しくなった
BSDとEmacsも愛してる
Cを知ったその日から
僕のプログラミング地獄に音楽は絶えない
501:デフォルトの名無しさん
08/06/26 11:02:04
K&Rからなら信じるけど。
BCPLからなんて誰が信じるか。
502:デフォルトの名無しさん
08/06/26 23:12:49
そこマジレスするところじゃなくね？w
503:デフォルトの名無しさん
08/06/26 23:15:28
1億と2千年たってもＣ言語は健在だお。
504:デフォルトの名無しさん
08/06/26 23:46:41
そんなに人類生きてんのかな
505:デフォルトの名無しさん
08/06/27 00:08:34
マジレス乙ｗ
506:デフォルトの名無しさん
08/06/27 06:25:07
そのころには人類は量子コンピュータ上でシュミレーティッド
された世界に住んでるんだろな。動作言語はもちろんC-100002000
507:デフォルトの名無しさん
08/06/27 07:07:17
シュミレーティッド
508:デフォルトの名無しさん
08/06/27 23:47:05
C++の何がまずいかは語りつくされたようだから、
次はＤのなにがまずいかについて聞かせてくれまいか。
509:デフォルトの名無しさん
08/06/27 23:49:19
D言語は良く知らない
510:デフォルトの名無しさん
08/06/28 00:02:19
DこそＣを駆逐してやるという目的で生まれた言語だよね？
511:デフォルトの名無しさん
08/06/28 02:01:19
でもDコンパイラってCと100%互換なんじゃなかった？
むしろ共存したいんじゃないの？
512:デフォルトの名無しさん
08/06/30 16:30:47
互換性は罠だな。
共存すると見せかけてＣプログラマをＤに取り込んでおいて、
Ｃに戻れないほど脳みそを蝕んでおいてからはしごをはずすんだろう。
513:デフォルトの名無しさん
08/07/02 12:14:30
なんか方向性が逆じゃないか？
スタック変数の自動管理と、一般的な制御構文の使える高級アセンブラがあればいい。
514:デフォルトの名無しさん
08/07/02 13:17:54
そんなやつはもはや少数派なんだよ
515:デフォルトの名無しさん
08/07/02 18:36:13
>>513
マクロアセンブラで遊んでてください。
516:デフォルトの名無しさん
08/07/02 23:57:30
Java とか.netのVMのアセンブラを使えば、幸せになれるんじゃないか？
517:513
08/07/03 02:13:15
>>516
JVMとか.netのCLRとかは、それこそJavaやC#使えばいいだろ。
Cの本領発揮は、もはや絶対アドレスやIOポート参照が必要なところか、
CPUレベルの最適化が必要なところだけなんだから、だったらそこだけ
高級アセンブラで書いて、残りは本当の高級言語で書けばいい。
518:デフォルトの名無しさん
08/07/03 15:18:31
>>513 >>517
>高級アセンブラ
それがCじゃないのか？
519:デフォルトの名無しさん
08/07/03 18:18:37
Cはポータビリティのために、効率が悪い点が多いんだよ。
低級言語は、機種依存な部分だけに使えばいい。
520:デフォルトの名無しさん
08/07/04 18:31:29
>>519
ここで低級言語といってるのはCのこと？アセンブラのこと？
521:デフォルトの名無しさん
08/07/06 15:47:30
>>511
惜しい。コンパイラは互換性無いよ。
互換性があるのはリンカ。
522:デフォルトの名無しさん
08/07/06 16:18:21
>>520
低級はローレベル。すなわちステムに近いことを示す。システム記述言語であるアセンブラやC/C++などじゃないか。
523:デフォルトの名無しさん
08/07/07 13:42:35
URLﾘﾝｸ(ja.wikipedia.org)
524:デフォルトの名無しさん
08/07/12 23:15:15
>>522
Cと他言語(Java等)を比べて低級な方って意味で言ってるのか、
それともCとアセンブラを比べて低(ry
ってことだろじょしこー
525:デフォルトの名無しさん
08/07/14 11:01:59
いや俺はJKよりJCのほうｇ
526:デフォルトの名無しさん
08/07/14 12:03:02
もっとも低級言語に近い高級言語Ｃ。この独特のポジションにいる限りCobolやVBが滅びても
Ｃが滅びることはないように思う。
527:デフォルトの名無しさん
08/07/14 15:32:42
>>526
当然だな
528:デフォルトの名無しさん
08/07/14 23:47:27
そもそも、現在生き残っている OS で C を使わないものが、どれだけ存在するのか？
それ等の OS が全て駆逐されないかぎり、C は駆逐されないのは自明
529:デフォルトの名無しさん
08/07/15 00:42:27
まったくだ。リア工の俺にはCの無かった時代というのが想像できない。
530:デフォルトの名無しさん
08/07/15 01:08:16
LISPマシンが市場抑えていたらどうなったんだろう、って想像くらいか
マシン語が括弧だらけになるんだろうな
サンもJavaマシンとか考えてたな あれは夢想に終わったんだっけか
後者はマシン語がJavaVMのバイトコードに置き換わるだけだな
実現していたところで、結局その上にCコンパイラとか出て来て意味不明な事になってたんだろうな
531:デフォルトの名無しさん
08/07/15 05:16:55
>>530
ICOT のアレは？
532:デフォルトの名無しさん
08/07/15 19:58:25
34bitアーキテクチャが流行っただろうな
533:デフォルトの名無しさん
08/07/15 21:13:20
将来、
GPUにDSP系のプロセッサを乗せて
そいつにコードを転送する必要が生じたとき、
そのコードはC言語をはじめ、手続き型言語では記述できない
組み込み系も視野に入れるなら、C言語の立ち入ることのできない領域は今でもあるよ。
FPGAとかあるし。
534:デフォルトの名無しさん
08/07/15 21:24:01
>手続き型言語では記述できない
すまん。
俺にはそんなものがあるとはちょっと想像が付かない。
どういうこと？
535:デフォルトの名無しさん
08/07/15 22:16:17
>>534
FPGAとかゲートアレイっていう、電子回路をプログラミングできるチップがあって、
そいつをプログラミングするにはSystem-CとかHDLとかいう言語を使うんだ。
基本的には
「○番ポートと○番ポートの入力を足したり割ったりして、○番ポートに出力せよ」
という宣言の羅列になる。
本物のハードよりは遅いけれど、ソフトウェアよりは速い。
ソフトウェアより融通が聞かないけれど、ハードウェアよりは融通がきく。
という建前だった。
今は知らないけど。
536:デフォルトの名無しさん
08/07/16 01:48:03
それって手続き型言語で記述できないのか？
537:デフォルトの名無しさん
08/07/16 01:55:14
できるでしょ
538:デフォルトの名無しさん
08/07/16 02:34:18
手続き型言語を procedural language の訳語とするなら無理だろう
逐次実行であることが第一義だから対極にある
ただ、C言語を駆逐する方向という意味では、全く逆に取り込まれていく方向にあると思う
これは、言語・ソフト的にという意味では無くて、ハード的にという意味だが
539:デフォルトの名無しさん
08/07/16 06:06:11
SystemCはC++で書けるんだが
540:デフォルトの名無しさん
08/07/16 07:06:43
>>534
大雑把に書くと
手続き型言語は演算子を順番に評価実行する。
HDLなどの記述言語は、すべての演算子が同時に評価され常に評価結果が反映される。
HDLに適した処理を手続き型言語で書き直すと処理時間が遅くなりすぎる。
手続き型言語に適した処理をHDLで書くと回路規模が大きくなりすぎる。まあこれは、HDLでCPUを書いてしまえば解決できるというのがノイマン型コンピュータというか手続き型言語の原点かな。
541:デフォルトの名無しさん
08/07/16 07:17:51
記述できるじゃないか。
542:デフォルトの名無しさん
08/07/16 08:12:41
まぁ、手頃なスクリプト言語で書くほうが無難ってことだな。
543:デフォルトの名無しさん
08/07/16 08:36:05
haskellでHDL書きたい
544:デフォルトの名無しさん
08/07/16 09:04:28
>>543
atomでいいんじゃないか？
URLﾘﾝｸ(funhdl.org)
545:デフォルトの名無しさん
08/07/16 12:15:23
>>541
記述できてもパフォーマンスを満たせない
546:デフォルトの名無しさん
08/07/16 15:31:49
できないじゃなくて現実的じゃないってことか、把握
547:デフォルトの名無しさん
08/07/23 08:10:10
CはどんなCPUでも同じ文法で動く、“共通アセンブラ”みたいな位置づけ。
他の言語と比べること自体がナンセンス。 もう機能追加とかしない方がいい。
CにはOOだのGCだの必要なし。それはLLとかに任せればいい。
548:デフォルトの名無しさん
08/07/24 01:45:34
CはC++の例外相当の処理を効率よく実行できないので不十分。
C++からCへのトランスレータが使われなくなったのはそのせい。
549:デフォルトの名無しさん
08/07/24 07:18:46
>>547
同意。C99も失敗だったかもな。
550:デフォルトの名無しさん
08/07/24 13:44:29
185でｶﾞｲｼｭﾂ
551:デフォルトの名無しさん
08/07/25 07:09:39
ランタイムライブラリを統一できないから、それを必要としないCが生き残る
MSがそれを統一したような気がしないこともないが、それは言わない約束だからCが生き残る
552:デフォルトの名無しさん
08/07/25 10:11:24
>>551
libcって知ってる？
2行目も意味不明
553:デフォルトの名無しさん
08/07/25 13:18:37
libcを他のライブラリと区別する理由はない
554:デフォルトの名無しさん
08/07/26 20:52:32
インタプリタが生き残るよ
555:デフォルトの名無しさん
08/08/13 17:10:02
C99のTechnical corrigenda TC３はどんな内容ですか？
556:デフォルトの名無しさん
08/08/31 22:30:01
libcって、ANSIレベルに毛が生えた物、って先入観しかないんだが…
557:デフォルトの名無しさん
08/09/01 12:48:32
Cが駆逐されると思ってるかどうかで考え方がかなり変わるみたいだな
Windows使ってるとMSが潰れたら困るよ、みたいな感覚で関数型言語やってる人とか
なんかすごくね？
558:デフォルトの名無しさん
08/09/01 22:19:47
Windowsを完全に駆逐するためには
ってスレがあってもいいかもな。良くないか。
559:デフォルトの名無しさん
08/09/01 22:58:47
Macしかないな。
560:デフォルトの名無しさん
08/09/01 23:03:12
Macをプログラム言語にたとえるとlispになるのかなぁ。
とMacもlispも使ったことのない俺が言ってみる。
561:デフォルトの名無しさん
08/09/02 19:34:55
Objective-C涙目。しかし、たとえるならRubyかな。
触れ込みの良さ、扱いやすさと、後方互換性の欠如、筋の通らない仕様変更とか。
562:デフォルトの名無しさん
08/09/02 20:18:58
宗教じみてる点でも似てるな
563:デフォルトの名無しさん
08/09/03 06:51:40
指導者にカリスマがあるからな、仕方ない。毛はないが。
564:デフォルトの名無しさん
08/09/03 22:49:49
モルモン教だからだろ
565:デフォルトの名無しさん
08/09/05 00:46:43
神に祝福された存在であるRubyを、ちょっと小洒落てるだけがとりえのMacなんかと同列に扱わないでください＞＜
566:デフォルトの名無しさん
08/09/05 10:12:21
Ahura Matz 神か。
567:デフォルトの名無しさん
08/09/16 23:40:56
アセンブラが人手によってかかれるべきでない（コンパイラに任せたほうが良い）のと同様に、C言語もまた人手によってかかれるべきではない。
568:デフォルトの名無しさん
08/09/16 23:56:34
なんちゃそれ。
569:73.6.30.125.dy.iij4u.or.jp
08/09/17 13:53:44
>>567
C言語を共通アセンブラと考えるとそうかもしれないね。
570:デフォルトの名無しさん
08/09/18 00:23:07
そこでObjective-Cですね
571:デフォルトの名無しさん
08/09/18 11:05:43
>>567
つまりyaccとかbisonですね
572:デフォルトの名無しさん
08/09/21 01:53:00
2chで語る以前に、言語開発者がｘｘｘよりは組みやすく～とかいいつつ
アホみたいに言語増やしたけど、今だにC,C++が生き残ってるってことは
駆逐は無理。以上
573:デフォルトの名無しさん
08/09/21 02:58:25
>>572
それ、C,C++の部分に大抵の言語があてはまるんじゃね？
いまだにCOBOLが…、いまだにPerlが…他
574:デフォルトの名無しさん
08/09/25 00:06:47
CPUもコア増やすくらいしかやることないならそろそろプログラム言語に歩み寄っていいんじゃないかい？
VMがこれだけはやってんだから統一VMのモデルでも作ってネイティブでその命令実行してやれ。
そうすりゃCの呪縛も少しは薄れるだろ。
575:574
08/09/25 06:30:10
自分で言うのもなんだが、結構いいアイディアな気がしてきた。
VMのコードをネイティブで実行するCPUなんてのは陳腐なアイディアだが、
C言語を駆逐するためにはかなり効果あるんじゃないか？
昔はハードウェアの値段がソフトウェアの値段より遥かに高かったけど、
今じゃすっかり逆転してるわけだし、VMの技術だってかなり枯れてきているころだろう。
インテルがコア数を増やすのも限界まで来て、それでもトランジスタを増やさなければいけないとなったら、
VMの命令をネイティブでサポートなんていう道に走らないとも限らない。
C言語完全駆逐の可能性はまだ残されているっ
576:デフォルトの名無しさん
08/09/25 08:25:57
今のCPUがマイクロコードで実装されていることもご存じないらしい。
Intelが有数のコンパイラベンダーであることもご存じないらしい。
577:デフォルトの名無しさん
08/09/25 12:37:45
>>575
どっちかというと、ＣＰＵの規模より集積可能なトランジスタのほうが上回る様になってきたから、余ったトランジスタ処分用にマルチコアにしたんじゃないの？
578:デフォルトの名無しさん
08/10/02 01:33:27
昔の同僚に、真顔でこれを言ったアフォがおった
ツール類で何でもできるんだとよ
579:デフォルトの名無しさん
08/10/02 08:59:25
>>13 VCなくなったらそれこそC++なんか閑古鳥だろ
580:デフォルトの名無しさん
08/10/02 09:18:21
C++ってなんであんなに肥大化しちゃったの？
ｽﾚﾘﾝｸ(tech板)
581:デフォルトの名無しさん
08/10/02 13:26:44
ポインタ概念のないVBがこれだけ進化してるんなら逆にＣ駆逐は時間の問題かと。
昭和生まれが現役引退するころにはプログラム歴史記念館に飾られてるよ。。きっと。
582:デフォルトの名無しさん
08/10/02 15:31:31
>>581
組込みソフトのこともちっとは勉強しろよ坊主
583:デフォルトの名無しさん
08/10/02 18:27:36
小娘かもしれん
584:デフォルトの名無しさん
08/10/02 20:36:41
お前らはC言語無くなったら何使うん？java？
585:デフォルトの名無しさん
08/10/02 20:46:39
Objective-D++
586:デフォルトの名無しさん
08/10/02 20:56:05
はいはい
他は？
587:デフォルトの名無しさん
08/10/02 20:58:55
lispがはやってほしい
588:デフォルトの名無しさん
08/10/02 20:59:09
ポインタの概念は絶対になくならないよ
何もかも値渡しするっていうアホ言語を作るなら別だが
589:デフォルトの名無しさん
08/10/02 21:02:33
C並に低レベルな言語は必要
それがCである必要は無いけれども
590:デフォルトの名無しさん
08/10/02 21:11:44
BCPLがあまりに低レベル過ぎて使いにくすぎたから
C言語が作られたんだよな確か。
だからC言語はなくならないんじゃない？
591:デフォルトの名無しさん
08/10/02 21:25:23
並にって話してるのにそれより低いものを持ち出してもどうしようもないと思うぞ。
592:デフォルトの名無しさん
08/10/02 21:30:28
ロクな返事がねーな
代用できるものも考えずに潰すつもりだったの？君ら
593:デフォルトの名無しさん
08/10/02 21:42:35
C#
594:デフォルトの名無しさん
08/10/02 21:54:08
>>593
C#のネイティブコンパイラが出来たらな。
ngen.exeは腐っているのでもっとまともなネイティブコード
ジェネレータが必要だが。
595:デフォルトの名無しさん
08/10/02 22:33:43
PASCAL
PL/I
596:デフォルトの名無しさん
08/10/02 22:38:47
CISC アセンブラ
597:デフォルトの名無しさん
08/10/02 22:47:22
>>596
ARMケータイはどうするの？
598:デフォルトの名無しさん
08/10/02 23:02:03
要するに組み込みのハードのパワーがまだまだ貧弱なのがいかんのだろう。
あと１０年もすれば組み込みのハードもパワーが有り余ってC言語が要らなくなるんじゃない？
599:デフォルトの名無しさん
08/10/02 23:16:40
パワー関係ないだろ
今時のマシンだろうがbootstrapのコードはasmじゃないと書けないし
kernelのコアのコードがメモリも弄繰り回せないようでは話にならない
Cのような機能を持った言語は要るんだよ
Cである必要は無いけれども
600:デフォルトの名無しさん
08/10/02 23:20:20
ハードの性能とか一切関係ないよ
実用性という点においてCを超える言語が存在しないだけ
過去を考慮せず、これからのハードに的を絞っても
Cより先に処理系を用意し続けるのって不可能に近いよ
それが出来なきゃ駆逐なんて夢物語
601:デフォルトの名無しさん
08/10/02 23:35:34
>>584
Ｃ＋＋
602:デフォルトの名無しさん
08/10/02 23:36:03
Cがアセンブリを駆逐したという伝説がひとり歩きしているね
実際にはCがアセンブリと連携しやすかった所がポイントなのに
603:デフォルトの名無しさん
08/10/02 23:44:28
そういや、アセンブリは非常に低水準だけど、それでも大抵のハードでスタックは装備されてるんだよな。
もっといろんな概念がハードに採用されてもよさそうだけど、あんまりそうはならないね。
それだけスタックがプログラムにとって本質的ってことかな。
604:デフォルトの名無しさん
08/10/02 23:48:31
と思ったけど、よく考えたらハード的に特別スタックを用意してるわけじゃないんだっけ？
スタックポインタなんてなんて名前のレジスタがあるからてっきり、ハード的にスタックがあるんだと思っちゃったけど。
605:デフォルトの名無しさん
08/10/02 23:56:03
でもただのjumpやmoveではない、push/pop/call/retがあるあたり
命令面では特別視されている感じがする。
606:デフォルトの名無しさん
08/10/03 00:18:46
RISC ではそういう命令あんまりないんじゃない。
607:デフォルトの名無しさん
08/10/03 00:22:39
>>606
まじで？
具体的なCPUの名前教えて。
608:デフォルトの名無しさん
08/10/03 00:27:41
R3000なんかはそうでしたね
スタック操作も全部アセンブラでした
609:デフォルトの名無しさん
08/10/03 01:16:05
>>605 それマクロよ
610:デフォルトの名無しさん
08/10/03 07:58:45
いやマクロ違うだろ
611:デフォルトの名無しさん
08/10/03 12:11:43
x86 は Pentium Pro 以降ハードウェアで x86 命令をマイクロ命令に変換してる。
612:デフォルトの名無しさん
08/10/03 12:41:48
でもx86のIntelではPentium-Mまで、AMDに至ってはPhenomに
至るまでスタックポインタをALUで操作していたから遅かったね。
これらのCPU以降ようやくスタック操作が速くなった。
まあCALL自体は少ないとしてもPUSH/POPはレジスタの少なさ
ゆえ避けられないからな。
613:デフォルトの名無しさん
08/10/07 19:12:12
C言語を駆逐するのにスタックが関係あんのか？
614:デフォルトの名無しさん
08/10/07 19:25:37
大有りだろ
615:デフォルトの名無しさん
08/10/07 19:57:34
>>614
詳しく
616:デフォルトの名無しさん
08/10/07 20:38:17
スレの流れを見るに、Ｃはなんだかんだ言っても用途があるのでなくならない。
代替言語が仮にあったとしても、それがＣ言語を上回る訴求力が無い限り無理ぽ。
ただ、新しいハードが市場を埋め、それは既存と全く違う機械語が実装され、
そこで最初に提供された開発環境がＣ＋＋とかだったらＣは駆逐されるかもね。
617:デフォルトの名無しさん
08/10/07 21:19:53
スタックに次ぐ、ハードウエアに追加するほどプログラミングに必須な機能といえば…
ガベコレとか？
618:デフォルトの名無しさん
08/10/07 21:48:54
>616
C++がスーパーセットである以上、C++がCを駆逐することは不可能じゃないかな
その状況で例えばLispだけだったら可能性はあるかもね
619:デフォルトの名無しさん
08/10/07 22:02:09
>>616
拡張子.cppの中身実質Cなコードが溢れるだけ。
って、コンパイラじゃなくて開発環境か。
APIがクラスとか例外とかを平気で使っている状況かな。
620:デフォルトの名無しさん
08/10/07 22:15:19
ふと思ったんだが別にCを駆逐する必要なくね？
むしろ共通アセンブラとしてはベストじゃないか
621:デフォルトの名無しさん
08/10/07 22:21:05
共通アセンブラとしてならな。
Cで、でかいアプリ組まされるなんていう無法がまかり通るからいかんのだ。
622:デフォルトの名無しさん
08/10/07 22:21:54
>>621
それは言語の問題じゃないだろ
623:デフォルトの名無しさん
08/10/07 22:24:34
じゃあ何の問題なんだよ。
624:デフォルトの名無しさん
08/10/07 22:26:40
あんたの職場環境の問題
625:デフォルトの名無しさん
08/10/07 22:29:39
きつい一言を…（TT）
626:デフォルトの名無しさん
08/10/07 22:31:42
「でかい」の基準なんて分野毎に全く違う。
627:デフォルトの名無しさん
08/10/12 20:46:48
Linuxをスクラッチから構成すると導入したい言語はたいていCかC++のコンパイルから始まるからこりゃ駆逐なんてできないやと思った。
628:デフォルトの名無しさん
08/10/12 21:06:04
＞スクラッチから
……
629:デフォルトの名無しさん
08/10/12 21:29:51
LFSか
630:デフォルトの名無しさん
08/10/23 04:33:16
Hosh
631:デフォルトの名無しさん
08/11/06 21:20:21
self = [[Object alloc] init];
632:デフォルトの名無しさん
08/11/08 21:03:50
むしろランタイムがないと動かない言語が駆逐されるべき
ランタイムのバージョンやベンダーに依存して異常動作するなぞ論外
オブジェクト指向もいらね。
変数定義と関数定義はクラスで一体化するよりむしろ分けた方が
良いと思ってる。
633:デフォルトの名無しさん
08/11/08 21:05:20
Cもランタイム無いと動かない環境あるだろ?
634:デフォルトの名無しさん
08/11/08 21:25:02
あったとしても他の言語仕様が膨大な言語にくらべれば互換性は
高いはずだと思われ。
635:デフォルトの名無しさん
08/11/08 21:27:12
glibcみたいのはランタイムとは言わないのかな?
よく知らんけど。
636:デフォルトの名無しさん
08/11/08 21:29:12
POSIXのシステムコールなんて、ランタイムもいいところじゃないか。
637:デフォルトの名無しさん
08/11/08 21:30:53
つまりLispOSが最強ということか…
638:デフォルトの名無しさん
08/11/08 21:40:20
PCが機械語で動くかぎり、もっと言えばPCがメモリとCPUでできている限り、
Cが無くなることはないであろうと予言しておく。
639:デフォルトの名無しさん
08/11/08 21:43:43
その予言は>>28で既出
640:デフォルトの名無しさん
08/11/08 21:47:24
ガイシュツですたか。まあそれだけCは偉大な発明だったわけだ。
641:デフォルトの名無しさん
08/11/09 01:32:12
Cが、特出すべき素晴しい言語だとは思わない
突然変異的なパラダイムは何一つ無いんだから
ただ、それを記述する為に生まれたUNIXが純然たる地位を保っていることこそ
Cが現在の地位を保持しているのでは無いかと思う
Windowsですら、その呪縛からは逃れられてはいない
642:デフォルトの名無しさん
08/11/09 07:57:28
全然違う話で悪いんだが
UNIXは素晴らしいがCは素晴らしくないと言う人間をどう思う？
643:デフォルトの名無しさん
08/11/09 08:25:15
ファシスト。
644:デフォルトの名無しさん
08/11/09 12:33:58
Cの駄目な点は文字列の扱い。
char型の配列を操作するのはとにかく面倒なので改良型Cが欲しいところ。
645:デフォルトの名無しさん
08/11/09 14:06:39
Cの改良は何度も失敗してる。
全然関係ないけど、LuaみたいなのをベターCと見なせるなら、もしかするかもね。
646:デフォルトの名無しさん
08/11/09 20:53:07
ポインタの演算禁止とか、malloc()禁止とか、そういうコーディングルールを使ってるところは
Pascalとかでいいじゃんって思うけど、そういうレベルの人たちって、ちょっと違ってると、もう使えなくなるしな。
647:デフォルトの名無しさん
08/11/09 21:53:49
for文とかwhile文でbreak禁止とかストレスたまって仕方ない。
648:デフォルトの名無しさん
08/11/09 22:02:05
Cは覚えることが少ないから初心者向きだと思っていたが、Schemeを覚えて考えが変わった。
Cなんていらないや。
649:デフォルトの名無しさん
08/11/10 01:09:03
今のlisperにとってCは闇米のようなものだ
650:デフォルトの名無しさん
08/11/12 15:06:44
>>634
glibcのバージョン変わると起動しなくなるのが高い互換性？
651:デフォルトの名無しさん
08/11/13 11:46:34
動的リンクとCの言語仕様は関係無いな
652:デフォルトの名無しさん
08/11/13 15:17:39
>>650
それって窓で言えば
kernel32.dllやuser32.dllを別のに差し替えるようなものだぞ
653:デフォルトの名無しさん
08/11/14 20:47:19
Cが嫌いなら無視してればいいのに
おバカさん向けのお上品な言語が他にたくさんあるわけだし
654:デフォルトの名無しさん
08/11/14 21:55:54
>>653
>>4
655:デフォルトの名無しさん
08/11/14 22:17:59
逆にさらにアセンブラよりな「cフラット」をつくるべきだな
656:デフォルトの名無しさん
08/11/14 22:48:56
Cの歴史を考えるとOSを同時に作ることが必須なんじゃないか？
OSｲｲ!→ｲｲOSを作れる言語使う
CだけでなくUNIXも同時に駆逐しなければ無理だと思う
657:デフォルトの名無しさん
08/11/14 22:49:41
ていうかさ。
もっと強烈凶悪なプリプロセッサがCに追加されたら、Cを駆逐しようなんて意見はなくなると思うな。
658:デフォルトの名無しさん
08/11/14 23:06:41
テンプレートのことか？
659:デフォルトの名無しさん
08/11/14 23:19:13
テンプレートも欲しいし、
いくつか追加して欲しい演算子もあるな。
でも、それができたらきっとCで満足してしまいそうな俺が居る。
660:デフォルトの名無しさん
08/11/15 01:20:50
C++の機能を適度に導入するのは賛成
というか実際そういう方向へむかってますね
661:デフォルトの名無しさん
08/11/15 08:46:32
効率は重要だけどCの低レベルさは嫌いとか、そんな都合いい話あるわけないじゃん
それが理解できないやつがC駆逐とかポストC言語に期待とか幻想抱くんだろうな
662:デフォルトの名無しさん
08/11/15 15:32:56
Pascalとか昔の構造化BASICくらいのレベルなら、いまの最適化技術なら、Cと変わらないコードができるよ。
663:デフォルトの名無しさん
08/11/15 17:20:30
>>662
pascal はね、共用体が変だし、; をかく場所も理屈っぽいし、なによりも、おなじことを書くのにc の倍のタイプ量になるのもやだし。
basic? 論外。
664:デフォルトの名無しさん
08/11/19 21:48:41
C言語を使っている組織・人間に対し武力介入を行う
665:デフォルトの名無しさん
08/11/20 03:23:34
>>664
ネット潰すのより難しそうだな
666:デフォルトの名無しさん
08/11/20 10:48:11
暗黙の型変換などを排除したstrictCが欲しい
667:デフォルトの名無しさん
08/11/22 23:36:47
色んなハード向けのコンパイラ屋がいる限り、
やっぱり駆逐されることはまず無いだろうね。
言語機能を機械語に置き換える量が最小元。
・新たなハードが出ても直す所はちょこっと
しかも、冗長さが無いのでパースが楽。
・クラス構文なんか付加されるだけでも割とダルい
ランタイムライブラリが殆どない
・ハード構成に合わせGCなんかを作るのは手間
単純でいて、OSが作れるほど実用的。
・lispなどもっと単純な言語もあるがハードには不向き
これを越える言語がないとなぁ。
668:デフォルトの名無しさん
08/11/25 00:54:20
Cって
遅い(実行速度じゃなくて開発の早さ)
高い(スキルのある人を探すと)
低機能(高級でないという意味で)
だけど早い安い高機能に負けないのは汎用性が他の追従を許さないからでは
高機能と汎用性って相反してる気がするからCは生き残るんじゃないかな
真っ白なノートと塗り絵のノートの違いみたいな
なんて素人なりに考えてみました
669:デフォルトの名無しさん
08/11/25 15:23:23
Cコードを吐く特定の言語の)コンパイラがあればすべて解決だろ？
C++(cfront)が失敗だろうが他の{実装|言語}でトライすればいいだろｊｋ
670:デフォルトの名無しさん
08/11/25 17:40:29
>>669
最適化の邪魔になる構文と、人間のための構文を仕様から
除去しないと難しいな。そうなると、最早Cでは無いが。
因みに、GCCの中間コードには近い物が有り、実用化されてるけどね。
671:デフォルトの名無しさん
09/01/25 05:39:19
移植性の問題はコンパイラじゃなくてジェネレータにすればかなり解決するんじゃないか？
というか、昔のC++しかりCのコードを吐くジェネレータは多そうだけど、実際どうなの
672:デフォルトの名無しさん
09/01/25 08:09:17
とりあえずガベコレ搭載したObjective-C 2.0でいいんじゃないか？
673:デフォルトの名無しさん
09/01/25 10:42:01
おまえらがC言語以外の言語で素晴しいソフトをどんどん作ればいいのさ
674:デフォルトの名無しさん
09/01/25 10:42:42
色んな思想があるから、色々と（微妙な）亜種が登場して
なんだかんだで C が生き残る
675:デフォルトの名無しさん
09/01/25 12:13:48
Dだろ
676:デフォルトの名無しさん
09/01/25 12:39:49
>>675
じゃあDで頑張って駆逐してください
677:デフォルトの名無しさん
09/01/26 01:47:32
Dとか最速消滅候補だろｗｗｗ
678:デフォルトの名無しさん
09/01/26 09:49:56
なんだかんだいってＣでつくっちゃうよな
確かにオブジェクトシステムとガベコレがないのは痛いが
あとインラインアセンブラはＤのほうがいい