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
なんだかんだいってＣでつくっちゃうよな
確かにオブジェクトシステムとガベコレがないのは痛いが
あとインラインアセンブラはＤのほうがいい