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

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

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)
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を書いてしまえば解決できるというのがノイマン型コンピュータというか手続き型言語の原点かな。

次ページ