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

C言語を完全に駆逐す� ..

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)
Wikipedia項目ﾘﾝｸ
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
Wikipedia項目ﾘﾝｸ

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は闇米のようなものだ

次ページ