10/05/31 00:56:58
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 6
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
10/05/31 01:00:37
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
3:デフォルトの名無しさん
10/05/31 01:01:24
◆新言語の要件 v0.1◆
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件） ＞ 構文の美しさ(読みやすさ、学習の容易さ) ＞ 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
4:デフォルトの名無しさん
10/05/31 01:02:50
◆新言語の名称（仮）◆
Programming Language I
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。
5:デフォルトの名無しさん
10/05/31 01:04:49
>>1
> しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
> 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
概念的には全く同じものになるだろう。
6:デフォルトの名無しさん
10/05/31 01:05:10
>>4
なんでLLが（ハッカーの手により）生まれ、Cみたいなのが生まれないのか
少し考えれば分かるだろ
7:デフォルトの名無しさん
10/05/31 01:16:05
◆新言語を考える上でのキーワード◆
クロージャー
カリー化
型推定
構文を操作できるマクロ
ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント
◆マクロについて◆
「マクロ」に必要な要件って何なんだろう。
・構文を置き換えるルールを定義できる
・シンボルを置き換えるルールを定義できる
Lisp級の構文木を操作可能なマクロを作る要件
・マッチングプログラムが簡単に書ける
・マクロの実行時に構文木を返すプログラムを書ける
また、作るのを容易にするには
・単純な式として構文解析が可能
8:デフォルトの名無しさん
10/05/31 01:20:46
◆低水準に関連するキーワード◆
・ハードウェアを直接操作
・デバドラ
・直接アドレス参照
・OS
・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。
・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。
・０オーバーヘッド
9:デフォルトの名無しさん
10/05/31 05:08:33
>>6
Cを作った人こそ
当時のハッカーというよりWizardだろ
有象無象が越えれる壁じゃないよね
LispがCより速い結果だしたそうな
どうみてもCのがわかりやすい
URLﾘﾝｸ(www.iaeng.org)
所でこのスレforkしたんじゃねえの
また関数言語とgcがわくぜ
10:デフォルトの名無しさん
10/05/31 08:14:00
forkと連呼してる奴ｗ
11:デフォルトの名無しさん
10/05/31 08:56:48
新言語の方は、GC付きオブジェクト指向でいくっぽいし。
低水準な方は、高級マクロアセンブラっぽいし。
>>1
乙
12:デフォルトの名無しさん
10/05/31 14:47:34
俺よくわかってないんだけど
超高速ってC以上に高速なバイナリ吐くってこと？
機械語に落とす時に最適化される部分をプログラマが
指定できるみたいな要件が
ってとこで>>4読んだ
リソース管理でどっちでもいいよって言うのは
結局プログラマがリソース？の状態を気にしてプログラムしないといけないから
後始末必要の方が好み
13:デフォルトの名無しさん
10/05/31 17:38:35
Cと同じ位の低レベルな時点で
RAMリソースなんて0で動かなきゃ
14:デフォルトの名無しさん
10/05/31 17:46:03
0ってスタックも無しかよｗ
15:デフォルトの名無しさん
10/05/31 17:52:27
RISC系のCPUで変数少なかったら
葉っぱの関数ではスタックもいらないのを見越して書く
メモリとかバスユニットの初期化コードとか。
16:デフォルトの名無しさん
10/05/31 17:54:16
正直マジでレジスタとROMしか使えないんなら素直にアセンブラ使ったほうが
良くないか
17:デフォルトの名無しさん
10/05/31 17:55:32
仮に使ってもゴミ読むだけなら
問題ない場合もあるしな
18:デフォルトの名無しさん
10/05/31 17:59:21
>>16
見た目は普通に書けるよ
呼び出し側はアセンブラかもしれんけど
19:デフォルトの名無しさん
10/05/31 18:07:10
アセンブラでよくてもポータビリティのためにCに書き直すことは意味ある。
20:デフォルトの名無しさん
10/05/31 18:13:22
俺は後で自分や他人が読むためかなw
数ヶ月たつと忘れちまうし、若い奴に見せてもアセンブラだと敬遠しやがるし
21:デフォルトの名無しさん
10/05/31 21:30:09
>>12
そもそもこのスレのテンプレは
>>1が重要だろうと思ってるレスを 過去ログから拾って来て、
適当に羅列してるだけだから、何一つ決まってないよ。
22:デフォルトの名無しさん
10/05/31 21:44:46
決めたい人が決めればいいよ
23:デフォルトの名無しさん
10/05/31 22:59:29
他人が決めてくれるのを待つ必要なんて無いんだよ
24:デフォルトの名無しさん
10/05/31 23:54:12
ははぁ勝手にやればいいよってことですね
思いつきで書き込んだんですが、今思えば
コンパイラがやってることをCのレベルに持ってくるのは難しいというか無駄？
上に乗っけるのと違って現状の処理が変わるわけですし優秀なコンパイラあるし。
でもアセンブラいじりましたって状況がなくなるなら面白そうなのかな？
とりあえずC？にもってきたらどんな記法になるかを書いてみたいけど
当方素人なのでGCCが吐いたアセンブラを変更しないといけないシチュエーションが思いつきませんｗ
25:デフォルトの名無しさん
10/05/31 23:57:45
あ？
26:デフォルトの名無しさん
10/06/01 00:12:20
テンプレートメタプログラミングは必須だな
27:デフォルトの名無しさん
10/06/01 04:52:38
手続き型アセンブラ
オブジェクトアセンブラ
関数型アセンブラ
LLアセンブラ
28:デフォルトの名無しさん
10/06/01 15:22:05
アセンブラアセンブラ
29:デフォルトの名無しさん
10/06/01 16:33:48
アスペクト指向アセンブラでダックタイピング
30:デフォルトの名無しさん
10/06/01 19:51:56
どこかに小型のCコンパイラのソースって無い？
ベル研のPCCはテーブル定義が足りない。
TCCはちょいとでかい。
31:デフォルトの名無しさん
10/06/01 22:35:29
なぜC
32:デフォルトの名無しさん
10/06/01 23:51:13
Cにネタを積んで遊んでみようかと。
33:デフォルトの名無しさん
10/06/01 23:53:11
>>31
僕の理由はCの実績。すでにあるプログラムに
手を加えるだけで恩恵が得られるって夢のようだとは思いませんか？
まあCに埋め込むものがどんなものになるかはまだ想像つかないです。
コンパイラ？を拡張するならまったく違う語法？でもいいのかもしれないし
改修してしまうならCがちょっと形を変えたものになるのかもしれない。
ベースになるのはCだろうなとは思ってますが
C++やC++0x、Java、Lisp?、といった言語だけでなく
Struts2やらシンフォニーといったフレームワークだったりとか
も参考にできるところがあるんじゃないかなあと
C++0xについてはいいものを見つけられた気がします。
とりあえず僕は他の言語をつまみ食いしながら
C99をよく見直して吟味するとこからなのでマイルストーンも何も置けない状況
今日は他の事してたので進捗はナシ。
34:デフォルトの名無しさん
10/06/02 00:30:34
schemeから始めればいいのに。
35:デフォルトの名無しさん
10/06/02 00:45:09
プロファイラ作ってみなよ
36:デフォルトの名無しさん
10/06/02 03:26:11
プロファイラもデバッガも仕組みさえわかれば
下の方は簡単だが問題は見せ方だよな
XcodeのInstrumentsとか面白い
37:デフォルトの名無しさん
10/06/02 21:24:24
プロファイラを言語機能に入れてよ
38:デフォルトの名無しさん
10/06/02 22:26:49
え？もしかして僕ですか？
言語機能には入れないけど作ることにはなるんじゃないですかねー
新言語にしか興味ないので見せ方は他の方がどこかの誰かに丸投げ
僕のがモノになるのはずーっと先だろうなあ。
39:デフォルトの名無しさん
10/06/02 23:08:41
アセンブラ言語から先は同じでいいんだからプロファイラ自体は先に作れるのかな？
アセンブラだから評価はステップベースでいいしあとはリソースの扱いを考えて・・・
静的なメソッドごとのステップと消費リソースを吐き出せばおｋだったり
40:デフォルトの名無しさん
10/06/02 23:32:36
アセンブラ言語って呼び方やめてくれ。ムズ痒くなる
41:デフォルトの名無しさん
10/06/02 23:42:53
アセンブラングエッジ
42:デフォルトの名無しさん
10/06/02 23:46:01
アセンブラ言語なんていってごめんねアセンブラ言語なんてもう言わないよ
あーあーアセンブリ言語をアセンブルするアセンブラ。
43:デフォルトの名無しさん
10/06/02 23:50:28
ラ行３段活用？
44:デフォルトの名無しさん
10/06/02 23:52:13
国語の話はやめてくれ。ムズ痒くなる
45:デフォルトの名無しさん
10/06/03 07:20:54
国語の能力とプログラミング能力の相間について
46:デフォルトの名無しさん
10/06/03 09:37:35
国語というより作文能力とは相関がある
47:デフォルトの名無しさん
10/06/03 21:03:20
どうせアセンブラやらないといけないし
プロファイラ先に作ってみる
48:デフォルトの名無しさん
10/06/03 22:40:29
○静的な機能として
・ラムダ式
・名前空間
・テンプレート
・型推論
・マクロ
○動的な機能として
・文字列
・リスト、キュー、スタック、ハッシュテーブル
・正規表現
・並列処理
・多倍長演算
・ベクトル演算
49:デフォルトの名無しさん
10/06/03 23:27:50
文字列とリスト以外いらん
50:デフォルトの名無しさん
10/06/04 02:48:10
これからの時代、ベクトル計算は要るだろ。
51:デフォルトの名無しさん
10/06/05 00:21:49
メニーコアプロセッサが普及するだろうから、並列処理とベクトル計算は必須。
52:デフォルトの名無しさん
10/06/05 02:04:23
結局理想を追求したらGoになったでござるの巻
53:デフォルトの名無しさん
10/06/05 09:21:19
低級言語にベクトル計算とか要らないよ
インラインアセンブラでやってくれ
54:デフォルトの名無しさん
10/06/05 09:34:05
ベクトル計算機のベクトル計算のことだろ。
そういう計算機では機械語がベクトル計算なんだが。
55:デフォルトの名無しさん
10/06/05 09:49:56
ベクトル演算専用言語を作るのは面白いけど
それが目的じゃないならインラインアセンブラでやればいいんじゃないの
56:デフォルトの名無しさん
10/06/05 12:53:14
ベクトル演算は言語標準でまではいらないが
標準クラスライブラリに含まれて然るべきだろう。
その方が演算器にCPUだけでなくGPUも使えていい。
57:デフォルトの名無しさん
10/06/05 15:38:56
ここはあれか、Core2DuoとかCellとかが最低ラインなのか。
58:デフォルトの名無しさん
10/06/05 15:43:43
最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか？
59:デフォルトの名無しさん
10/06/05 16:03:11
C/C++って低級言語じゃないんじゃ？
60:デフォルトの名無しさん
10/06/05 16:55:03
配列はベクトルでは無い
ベクトルは行列、そして積和演算
61:デフォルトの名無しさん
10/06/05 16:57:13
>>58
> 最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか？
ガイドラインを示すくらいなら、言語仕様に組み込んだほうがいいだろう。
特殊な小手先のハンドオプティマイズより、言語仕様に基づく公式なやり方の方がソースのポータビリティーも確保できる。
62:デフォルトの名無しさん
10/06/05 19:34:13
>>581
つfortran
63:デフォルトの名無しさん
10/06/05 20:23:27
Fortran と正しく書かないと
64:デフォルトの名無しさん
10/06/05 21:03:25
えらいロングパスだな
65:デフォルトの名無しさん
10/06/05 21:47:59
581に期待
66:デフォルトの名無しさん
10/06/05 22:37:03
並列処理の構文欲しい
67:デフォルトの名無しさん
10/06/06 03:10:37
ベクトル演算ってどんな感じで作るんですか？
68:デフォルトの名無しさん
10/06/06 03:59:51
int a[5], b[5], c[5];
c = a*b;
int d[3][5], e[2][3], f[5][2];
d = e*f;
こんな感じとか。
69:デフォルトの名無しさん
10/06/06 09:53:07
配列とベクトルは論理的に違うもの。
記述性を考えればdouble2,int4,float3とかのベクトル型は
組み込みで持っていたほうがいい。
70:デフォルトの名無しさん
10/06/06 10:09:47
>>69
>配列とベクトルは論理的に違うもの。
これはどういう事？
71:デフォルトの名無しさん
10/06/06 10:24:49
３次元が特殊なのは分かるけど
その他は特殊な事ってあったっけ
72:デフォルトの名無しさん
10/06/06 10:40:41
>>70
「行列演算」でググれ
73:デフォルトの名無しさん
10/06/06 10:48:50
>>72
ググったってたくさん出てくるから>>69が何を言いたいのかよく分からないよ。
具体的に説明して欲しい。
74:デフォルトの名無しさん
10/06/06 10:56:09
>>69
配列で十分だろう。ベクトルの足し算だってループでまとめて記述できるしコンパイラが自動的にベクトル化してくれる。
75:デフォルトの名無しさん
10/06/06 10:59:44
regster int a[5], b[5], c[5];
c = a*b;
regster int d[3][5], e[2][3], f[5][2];
d = e*f;
こんな感じで、コンパイラに努力目標を伝えられたらいいかもね。
76:デフォルトの名無しさん
10/06/06 11:02:49
行列演算なんて普通lapack/blasだろ
77:デフォルトの名無しさん
10/06/06 12:16:40
>>76
そういう機能をうまく構文に取り込めるといいね。
78:デフォルトの名無しさん
10/06/06 12:24:56
志村！スレタイ、スレタイ
79:デフォルトの名無しさん
10/06/06 12:24:57
だからFortranを勉強しろと
FORTRANじゃないぞ？ Fortranだ
80:デフォルトの名無しさん
10/06/06 12:26:51
Fortranに変わる新言語を作りtai!!のスレになりました。
81:デフォルトの名無しさん
10/06/06 18:12:11
AVXとかLNIとかに対応できる構文があればいいよね。
>>79
「Fortranを」と言うより、「Fortranのどの機能が良いから新言語に取り入れよう」と提案した方が議論が進むと思うよ。
82:デフォルトの名無しさん
10/06/06 18:31:37
みんなロングパス受け取ってくれたみたいだな
83:デフォルトの名無しさん
10/06/06 18:32:52
>>81
この流れでは並列演算に決まってるでしょ
84:デフォルトの名無しさん
10/06/06 18:37:50
>>83
それが決まってるのは結構なことだけど、それがどう良いのかの説明があればもっと議論が深まるのにね。
85:デフォルトの名無しさん
10/06/06 18:41:03
素直にFortran知りませんと言えばいいのに
86:デフォルトの名無しさん
10/06/06 18:46:29
別に知らないことは無理に表明しなくてもいいんだよ。
それぞれが知っていること、成し遂げたいことを語ったほうが前向きだからね。
だから、Fortranの並列演算に価値を見出している人がいるなら、その人がどう良いのかを説明して仲間を増やせばいいと思うよ。
87:デフォルトの名無しさん
10/06/06 18:50:32
Fortranの並列演算なんてライブラリで出来んじゃねえの
どうせならOccamとかの方が面白いだろ
88:デフォルトの名無しさん
10/06/06 18:50:49
行列に関しては、clapakでだめなの？
並列演算(SSE2/VelocityEngineほか)を直接制御したいというのは別だろうか。
89:デフォルトの名無しさん
10/06/06 18:52:21
>>87-88
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
90:デフォルトの名無しさん
10/06/06 18:57:38
マルチコアのプロセッサが今後主流になるだろうから、並列処理の構文はあったほうがいいだろう。
整数の四則演算だってライブラリで提供することは可能だが、多くのプログラミング言語にはしっかり構文があるわけだし。
91:デフォルトの名無しさん
10/06/06 19:02:44
脊髄反射すんなよ
高速演算ライブラリの必要性や配列の演算出来るって話は否定しないが
言語の話するなら並列実行構文の方が面白くねえかっつってんの
92:デフォルトの名無しさん
10/06/06 19:04:17
あ、89に書いたのよ
お前みたいな凡人が寄り集まってんだから既存の言語を参考にすんのは当然だろうがよ
93:デフォルトの名無しさん
10/06/06 19:04:41
並列実行構文の方が面白いと思う。
94:デフォルトの名無しさん
10/06/06 19:07:01
並列に実行して！という構文より
並列化コンパイラが作りやすい構文にした方が
95:デフォルトの名無しさん
10/06/06 19:07:50
並列実行構文 と 並列演算構文 を両方議論を進めよう。
96:デフォルトの名無しさん
10/06/06 19:08:54
>>94
自動で並列化してくれるのはもちろん嬉しいけど、プログラマがある程度制御できるようにもしておきたいかも。低レベルを目指しているので。
97:デフォルトの名無しさん
10/06/06 19:18:13
並列に実行して！
ってだけじゃなく、出来れば並列に実行して！みたいなのが面白そう
98:デフォルトの名無しさん
10/06/06 19:28:00
並列化を考えるなら、OpenMPのforの分担みたいにデータを並列化するんじゃなく、
普通のマルチスレッドアプリみたいな処理を分担するものを自動生成できるといいなあ
思いつかないけど
並列度は、明に指定も出来るし、デフォルトはシステムのプロセッサ数とかから
自動的にチューニングできるといいね。
あと、同期とかスレッド間通信もある程度は検討したい。
goのchannelはシンプルながら面白いよね
99:デフォルトの名無しさん
10/06/06 19:33:22
channel面白いね
でもやはり同期と排他と共有メモリは欲しくなるね
100:デフォルトの名無しさん
10/06/06 19:35:06
channel欲しいかも。
101:デフォルトの名無しさん
10/06/06 19:37:50
粒度が荒い並列はスレッド的な何かでいいが
細かいのは
102:デフォルトの名無しさん
10/06/06 19:47:28
ワッフルワッフル
103:デフォルトの名無しさん
10/06/07 08:12:59
並列化ってのは、そう難しいものじゃないんだけど、
並列時でもACIDを保証する事とパフォーマンスをスケール
させる事が難しくて、この難しさは、ようは、リエントラント性の
確保と、キャッシュ分散に関わってくる所なので、その辺をどう考えてるの
したいとか言う気分述べられても困るんだよね。
ＯＳが無い状況で、言語が資源を持つ事の意味をどう位置付けるのか
その辺を考えないと議論にならない。
104:デフォルトの名無しさん
10/06/07 09:11:33
どうせ低レベルじゃそんなの保証できないししてちゃ性能でないだろ
最低バリアーopとかcasみたいなのでクリティカルなとこだけ保護できれば後はなんとかなるんじゃね
粒度の高いのはコンパイラマターでいけるし
低いのはRTOSのカーネル程度のショぼいディスパッチャとスケジューラをランタイムに入れとく。
分散はライブラリ。
105:デフォルトの名無しさん
10/06/07 09:14:45
単なるディスパッチャとかmutexとかメッセージ含めて数kb程度でおさまるだろ
OS上で動かす時はそいつをpthreadとか使うように置き換えで
106:デフォルトの名無しさん
10/06/07 09:34:08
>>104-105
そのモデル違いがいかに混乱を巻き起こすのかってのは、
Ｌｉｎｕｘの事例で明らかなんだけどね。
君らその辺の難しさも理解しないで暮れ暮れ言い過ぎ。
107:デフォルトの名無しさん
10/06/07 09:57:46
一応OS屋のはしくれだが
どこらへんが明らかか後学のために教えて欲しいね
108:デフォルトの名無しさん
10/06/07 10:10:15
>>107
ふぇ？最近のＯＳ屋はそんなレベルなんだ・・・
109:デフォルトの名無しさん
10/06/07 11:04:46
>>108 結局具体的には説明できないわけだ。
110:デフォルトの名無しさん
10/06/07 11:08:12
>>109
ＯＳ屋なのに>>107を質問する奴（詐欺師）
とは付き合えないよ。
111:デフォルトの名無しさん
10/06/07 11:11:49
具体的な説明は一切できずに人格攻撃か。
112:デフォルトの名無しさん
10/06/07 11:25:29
職業倫理の問題なので､人格攻撃と捉えられても困るし。
詐欺師を叩く事が、人格攻撃というのなら、そうなんだろうが、
俺は詐欺師の存在が、社会へ対する害悪だし、詐欺師へ攻撃する
事の方が正しいと思う。
君が詐欺師好きなのは分かったけども、そんな人間だと公言されても
困るだけだし。
113:デフォルトの名無しさん
10/06/07 12:02:39
ただの質問をしただけの他人を詐欺師と決めつけて攻撃するほうが、
社会へ対する害悪だし、そういう馬鹿に対して馬鹿と言う事の方が正しいと思う。
君が馬鹿なのは分かったけども、馬鹿が馬鹿を晒すのは勝手にすればいいし。
114:デフォルトの名無しさん
10/06/07 12:08:29
全角に期待した俺がアホだったかな
学校でうだうだしてないで社会に出なさいよ
115:デフォルトの名無しさん
10/06/07 12:12:35
あ、113にじゃないよ
116:デフォルトの名無しさん
10/06/07 12:36:38
>>113
ＯＳ屋さんが、ただ質問したいと言って質問する内容じゃないよ。
ＯＳ屋さんであんな質問するのは詐欺師。
117:デフォルトの名無しさん
10/06/07 12:44:48
ランタイムライブラリにリアルタイムOSカーネルを乗っけるのか。
さっぱり分からん。OS-9辺りから学べばいいか？
118:デフォルトの名無しさん
10/06/07 13:29:25
RTOSのカーネルなんてしれてるよ
言語に並列組み込むなら
環境によってOS上ならスレッド、
無しなら小さいディスパッチャと
基本的なmutexとメッセージはいるやろって話
うーむ。詐欺師かねえ
119:デフォルトの名無しさん
10/06/07 13:31:50
で、具体的に Linux の事例、ってどういうこと？
120:デフォルトの名無しさん
10/06/07 15:28:57
>>119
ライブラリスレッディングが、スピンロックするんだけど、
それがＬｉｎｕｘのＬＷＰと競合して、スピンロックのエスカレーションを
発生させて、システムを致命的な状況に落としかねないって話と、
スケールアウトしないって問題を引き起こしていて、ＧＮＵＰＯＳＩＸに
問題があるので、ユーザーランドスピンロックを解消しにくいとか、
じゃあＯＳ側でＬＷＰのスケジューリングをどうしようかってのが、
ここ2年議論されつづけている。
ＬＷＰそれ単独、ユーザーランドスレッディングそれ単独では成り立つ
話でも混ぜると大騒ぎって話で、色々とね、難しいのよ。
排他制御のタイミングも違ってくるし。リソースの待ち方も違ってくるし。
121:デフォルトの名無しさん
10/06/07 16:16:17
で、それをOS屋であれば周知のはずだと思い込むのが犬厨か
122:デフォルトの名無しさん
10/06/07 16:28:39
>>121
Ｌｉｎｕｘに限った話じゃないからね。
123:デフォルトの名無しさん
10/06/07 19:58:07
僕じゃ理解できないかもしれないけど>>120の議論について読んでみたいので
進行形のスレッドか議論の流れがまとまってるサイトが知りたいんですけど
そういうのってどこ見ればいいんですか？
124:デフォルトの名無しさん
10/06/07 21:04:39
もったいぶった割につまらんオチだったな
125:デフォルトの名無しさん
10/06/08 09:25:02
なかなか、有意義な話じゃないすか
126:デフォルトの名無しさん
10/06/08 11:15:18
bsdとかSolarisとかでも相当昔に揉んだ話
どっちにしろ言語の並列機能やるならOSの上に乗っかるから関係ない
俺はまたthread以外の有用な並列化のモデルが出てくるかと思った
127:デフォルトの名無しさん
10/06/08 12:30:01
クライアントサーバモデルに代わる言語を開発したい
128:デフォルトの名無しさん
10/06/08 15:19:05
晩ご飯のおかずに代わる言語を開発したい
129:デフォルトの名無しさん
10/06/08 16:37:48
>>126
また脊髄反射かよ（ｗ
前にリンク張ったからもう張らないけども、
なんでその俺は分かってるんだって文体で
頓珍漢書くかなぁ・・・
議論の流れを追えば、ＯＳがあるからって
発言はありえないだろ。
諦めてＯＳに任せるべき、という発言になるべきだろ。
130:デフォルトの名無しさん
10/06/08 16:49:43
OSに任せると性能が出ないから、ってんでたとえば Erlang なんかは言語が並列化を
まる抱えしてるし、どこをどう読めば「諦めてＯＳに任せるべき、という発言になるべき」
なんだかわけわからんわ。
131:デフォルトの名無しさん
10/06/08 17:04:51
>>130
あぁ、君がスレッドモデルを小学生レベルで理解してない事を
理解し損ねて俺が頓珍漢な発言をしてた。ごめん。
Erlang なんかは、この時点で君がキチガイだと了解したわ。
スレッドモデルを勉強しなおせＷｉｋｉにまとまってるのでＯＫ
132:デフォルトの名無しさん
10/06/08 17:07:41
どんだけアイちゃんスレだよ
133:デフォルトの名無しさん
10/06/08 17:24:18
アイちゃん隔離スレだろ、ここはw
134:デフォルトの名無しさん
10/06/08 18:55:37
アイちゃんって何匹も居るの？
135:デフォルトの名無しさん
10/06/08 19:01:58
しむらすれたい
136:デフォルトの名無しさん
10/06/08 20:41:48
まずはシングルスレッドの動きを規定すべきだろ。
マルチスレッドはシングルスレッドの動きに直交する形で設計すりゃ良い。
だからForthを(ry
137:デフォルトの名無しさん
10/06/08 23:19:46
>>136
シングルスレッドの議論も、マルチスレッドの議論も並行に進めていいよ。
シングルスレッドの動きを規定する案があるなら提案してくれると、議論が進むと思うよ。
138:デフォルトの名無しさん
10/06/09 00:22:36
OSがいない状況、言語がリソース管理、GC?
低級言語にしては大きくなっちゃう、
スレッドをCPU数やリソースに応じたチューニング、アイちゃん
139:デフォルトの名無しさん
10/06/09 02:25:49
>>131
お前ほど自分で人に書いてる罵詈が自分に当てはまる奴も珍しいなw
Erlang出したのは俺じゃないが、今更カビの生えたスレッド実装の問題出した上に結局スレッド使えとかレベルが低すぎる。最近の論文とか読んでないから期待したじゃねえか
もういいからちょっと齧った程度の狭い知見で恥さらすな。お前程度の話ならみんなわかってるよw
140:19
10/06/09 10:43:45
スレッドの実装って通常はC言語で実装されているのですか？
それともアセンブラで実装されているのですか？
インラインアセンブラですか？
141:デフォルトの名無しさん
10/06/09 12:28:29
両方だよ
つ－か分家へ帰れ
142:19
10/06/09 13:15:53
>>140
あまり気になるようなら19はフィルタしてください。
C言語とアセンブラで書くということですね。ありがとうございます。
143:デフォルトの名無しさん
10/06/09 19:16:47
そんなてきとーな回答しなくていいのに
いまや分家の方が本家っぽい
144:デフォルトの名無しさん
10/06/09 19:55:34
新言語でも、新言語とインラインアセンブラを組み合わせて開発ができるといいな。
145:デフォルトの名無しさん
10/06/09 23:54:25
Cにネームスペースが入れば満足
146:デフォルトの名無しさん
10/06/10 09:47:08
ネームスペースは要らない
147:デフォルトの名無しさん
10/06/10 09:58:09
クラスだけでいい。
148:デフォルトの名無しさん
10/06/10 10:13:22
クラスはもっといらない
149:デフォルトの名無しさん
10/06/10 10:14:13
ソフトウェア開発しないならクラスもデザインパターンもいらないわな
150:デフォルトの名無しさん
10/06/10 10:29:09
要る要らないじゃわからんから、理由も付けれ。
151:デフォルトの名無しさん
10/06/10 19:58:23
ネームスペースは必要だよ。
名前に接頭辞を付けると名前が長くなって可読性が低いけど、
ネームスペースならコード中で省略できるから可読性が高い。
152:デフォルトの名無しさん
10/06/10 22:12:37
確かに複数ファイルにまたがるスコープなら、あっても良いような気がする。
153:デフォルトの名無しさん
10/06/10 22:33:43
クラスは要らない。
というかあっても良いと思うんだけど、マルチパラダイムな言語では、
ぐちゃぐちゃなヒドい実装になりがちだからダメ。
OOPLにするならするで、現状C言語を使わざるをえないような
チープな環境はターゲットとしては捨てるべきだよ。
154:デフォルトの名無しさん
10/06/10 22:35:54
糞環境だけにピンポイントかよｗCOBOL並みの糞言語じゃん
155:デフォルトの名無しさん
10/06/10 22:52:28
COBOLは、糞ではない。
幾多の消え去った言語を尻目に、いまだにたくさん使われている。
156:デフォルトの名無しさん
10/06/10 22:53:45
一時期デファクトスタンダードみたいになったからだろ。今から積極的に学ぼうなんて奴はいない
157:デフォルトの名無しさん
10/06/10 23:00:39
OOPって本当はピンポイントだけど、C言語風のOOPは汎用っぽく見えるよな
158:デフォルトの名無しさん
10/06/11 01:31:44
クラスはともかくとしても、デストラクタは欲しいから、結局クラスがあったほうがいいんだろうな。
159:デフォルトの名無しさん
10/06/11 01:58:09
GCに代わるデストラクタをピンポイントしたい
160:デフォルトの名無しさん
10/06/11 09:56:13
今ってコボラーが一番平均年収高いんだぜ？
つまり最高の言語って事じゃん
161:デフォルトの名無しさん
10/06/11 11:19:55
レガシーシステムの管理者が貴重なだけだろ
162:デフォルトの名無しさん
10/06/11 11:33:31
だから、そんだけ払える（価値がある）ってことだろ
社会的に「最高に価値のある言語/技術者」と評価されているわけ
わかった？
163:デフォルトの名無しさん
10/06/11 11:35:25
じゃあなんで大学で必修にしないのかな
なんで「学習する価値がある言語」と評価されてないのかな
164:デフォルトの名無しさん
10/06/11 11:37:10
COBOLが糞か糞でないか、終わってるか終わってないかの議論では
糞だし終わってるというのが一般的な見解だろ
165:デフォルトの名無しさん
10/06/11 11:43:29
>>163
うんまぁそういう事は大学行ってから言おうね
大学で教えるのは、学習に適した言語だよ
166:デフォルトの名無しさん
10/06/11 11:44:44
COBOLは糞だし終わってるが、お前らより遥かに社会的に価値がある。以上。
167:デフォルトの名無しさん
10/06/11 11:46:37
COBOLを有難がってる奴の社会的価値は終わってる。社会的に抹殺した方が良い
168:デフォルトの名無しさん
10/06/11 11:55:48
次スレは 【超年収】COBOLに代わる金融言語を開発したい で
169:デフォルトの名無しさん
10/06/11 12:01:04
都会は下水道完備だが田舎ではまだまだボットン便所が多数派だ。
ボットン便所は確かに糞だが汲み取り業者はお前らより遙かに社会的に価値がある。以上。
170:デフォルトの名無しさん
10/06/11 12:06:55
バキュームカー臭い議論すんな
171:デフォルトの名無しさん
10/06/11 15:14:47
おまいらの給料だってCOBOLがハンドリングしてるんだろ
172:デフォルトの名無しさん
10/06/11 16:47:58
COBOL以後にそれ並みになったのは、C、BASICぐらい。
173:デフォルトの名無しさん
10/06/11 17:21:52
まあ、なんだぁ
おれには「それ並み」って言葉の意味がわからないけどな
日本語なのか？
174:デフォルトの名無しさん
10/06/11 19:58:28
金融系でCOBOLから
他の言語に移行なんてベンダー主導でやらないと無理じゃん
175:デフォルトの名無しさん
10/06/11 20:04:43
ベンダーってなんですか？
社内で科学技術計算する立場なんですがIT業界の用語が良く分からないんですよね
176:デフォルトの名無しさん
10/06/11 20:09:15
すまんが、マ板でやってくれ。
177:デフォルトの名無しさん
10/06/11 20:24:10
>>175
ぐぐってきたぞ。製品を販売する会社なんだって。
汎用機だとIBM,富士通,、NECか金融系の開発受託してるのは違う会社か
>>176
語るならCOBOLは言語的にどう優れているのかって点かなあ
178:デフォルトの名無しさん
10/06/11 20:41:58
>>177
他の言語で金の計算なんてやってらんねえよｗ
179:デフォルトの名無しさん
10/06/11 20:55:40
勘定系は伝統的にcobol、pl/iだったけど
市場系は開発スピードが評価されて20年くらい前からc/c++だけどね
180:デフォルトの名無しさん
10/06/11 21:22:43
二進化十進表現はのいいものかも。贅沢
181:デフォルトの名無しさん
10/06/11 21:29:46
>>177
余計なことができない言語は特定分野で重宝するのは事実。
182:デフォルトの名無しさん
10/06/11 21:32:05
ウメハラのような言語か
183:デフォルトの名無しさん
10/06/11 21:32:40
一山なんぼのバカでも使えるからな
184:デフォルトの名無しさん
10/06/11 22:31:48
ほんとのバカにはCOBOLで書くプログラムはまかせないけどね。
185:デフォルトの名無しさん
10/06/11 23:01:05
バカにプログラムは任せないし、COBOLでプログラムも書かない。
186:デフォルトの名無しさん
10/06/11 23:17:28
ガキのケンカｗ退屈。
クラスについてだけどマルチパラダイムな状況を許容することで
自由な実装ができてるのだと思うけどどうなんですかね
可読性と天秤にかけられるものなんでしょうか。
ガッチリ決めちゃえば実装は楽になるとは思うけど。
あとクラスがあるからスレッドの実装なんかも楽になってるのでは？
187:デフォルトの名無しさん
10/06/11 23:35:53
クラス考えるならインターフェイスどうするか考えないと。
まあ、簡単にはメソッドオンリーだろうけど。
チャネルとかストリームとかトランザクションなんかも魅力的だけど重たいしね。
188:デフォルトの名無しさん
10/06/11 23:52:13
>>187
よくわからない。違う話してる？
189:デフォルトの名無しさん
10/06/11 23:58:52
>>187が最近知ったことの話をしてる
190:デフォルトの名無しさん
10/06/12 09:23:55
あくまで低級言語なんで、
マルチパラダイム万歳で、リッチな言語は違う気がする。
191:デフォルトの名無しさん
10/06/12 14:12:13
新言語の記述レベルは低レベルであっても、記述力はリッチにしたい。
特にビルド時に処理できる構文は積極的に取り入れていい。
192:デフォルトの名無しさん
10/06/12 15:03:36
低級言語って、Cは低級言語ではないのだが
(Cは高級言語です)
低級言語を開発するという意味が
よく、わからない。
最初にスレタイを考えたやつは
アホではないでしょうか？
193:デフォルトの名無しさん
10/06/12 15:05:07
今更何言ってんだ？空気嫁よ
194:デフォルトの名無しさん
10/06/12 15:08:54
そう思うあなたは分割されたスレ行けばいいと思うの
195:デフォルトの名無しさん
10/06/12 15:13:41
>>192
高級アセンブラといいたいんですね。解ります
196:デフォルトの名無しさん
10/06/12 15:24:55
>>192
> 低級言語を開発するという意味が
> よく、わからない。
先ずは、このあたりをどうぞ。
>>1 >>3-4 >>7-8
197:デフォルトの名無しさん
10/06/12 16:54:18
昔はCは高級言語であるとされてきたが、近年はそうとはかぎらない。高い低いはあくまで、比較してどうかだから。
198:デフォルトの名無しさん
10/06/13 09:26:26
>>197
> 昔はCは高級言語であるとされてきたが
いつ頃の話してるのか知らんが、昔から PL/I だの Ada だのの豪華な
言語はあったから、コンパイラ言語としては C は常に末席付近だった
と思うぞ。
199:デフォルトの名無しさん
10/06/13 09:42:29
>>198
初期の lisp に比べても十分低レベル
つか, 非常に良くできた高級アセンブラだわな
# それがいいんだけど…
200:デフォルトの名無しさん
10/06/13 10:59:38
PDP-11 の頃と今の違いといえば並列
それと翻訳環境の怪物化
パイプラインやベクトル演算も簡潔かつ辛辣に抽象化した
移植可能アセンブラができれば C の二番煎じにはなるだろう
# 実はそれっぽいのがもうあったりするが文法的な面白さがいまいち
あと operator くらいあれば浮動小数点あたりは強制から任意に緩和できる
もっと言えば基本型は bool と配列だけでいい
ワード幅 8bit はそろそろぶっ壊してもいいと思う
201:デフォルトの名無しさん
10/06/13 14:21:29
192じゃないが、>>196で見直して気付いた。
「C言語、C言語」言ってるから騙されたけど、
欲しいのはCの代替じゃなくて「綺麗なC++」なのか。
C言語が選択される理由のうち、
記述が機械語に近しいって所はいらんのだな。
コンパイラが作りやすいとか、
コード見てアセンブリが想像出来るとか。
202:デフォルトの名無しさん
10/06/13 14:57:21
>>201
その二つを両立させたいんだろ
Cの代替であり、尚且つC++並みの高機能にしたい
前者を捨てて後者に特化した言語はごまんとあるから、もうこれ以上いらない
203:デフォルトの名無しさん
10/06/13 14:58:32
なら、まずC++の何が不満かを洗い出さないと
204:デフォルトの名無しさん
10/06/13 15:11:25
>>203
C++があるのにCの人気が衰えないことが不満なんだよ
205:デフォルトの名無しさん
10/06/13 15:14:50
C++への不満が絶えないことが不満
206:デフォルトの名無しさん
10/06/13 15:35:25
進化、成長しないことが不満
抽象的なモデルより、具体的なソフトを作る人間の方が勝ってると思われることが不満
207:デフォルトの名無しさん
10/06/13 16:15:41
C++0xは進化でも成長でもないと
208:デフォルトの名無しさん
10/06/13 16:30:39
0xの勉強するより、Cだけでソフト作った方が有意義だろ常識的に
209:デフォルトの名無しさん
10/06/13 16:34:01
常識を覆す言語を開発したい
210:デフォルトの名無しさん
10/06/13 19:58:03
そのためにはまず常識を理解しないと
211:デフォルトの名無しさん
10/06/13 20:18:55
岡目八目ってこともあるが
212:デフォルトの名無しさん
10/06/13 22:09:53
ストラウさんの
「c++の設計と進化」あたりを読むのがいいんじゃないですかね。
いろいろ c と simula の不満を述べてますがな。
213:デフォルトの名無しさん
10/06/13 22:33:49
>>202
そうかぁ。
知識不足ですまんけど、動的メモリ確保無しで書けて、物理メモリアクセスや
チップのクロックに依存するようなタイミング制御が出来るような
高機能な言語ってC++ぐらいしか知らんので、
そういう方向もアリかな、と思ったんだ。
214:デフォルトの名無しさん
10/06/14 19:10:45
Cはシンプルさを目指した言語だし
C++は複雑化する一途だし別物なだけ
215:デフォルトの名無しさん
10/06/14 20:00:19
>>214
そのとおりだとおもう。
でもＣ＋＋はどんなに複雑でも零オーバーヘッドの原則ですべてが許される。
216:デフォルトの名無しさん
10/06/14 20:23:44
C++ の不満。ぱっと思い付いたのだけ。
* C との構文的互換性。文脈自由文法でない → リファクタリング支援系のツールの貧困さ
* モジュールが無い
* 巨大な std 名前空間
* 例外を投げない保証を明示できない → 例外安全なコンテナを作るのが難しい
* 資源管理の責任の明示が困難 ( move である程度改善? )
* 型安全な可変個引数が無い
* 可変長テンプレート引数が無い
217:デフォルトの名無しさん
10/06/14 21:10:30
C++は、０オーバーヘッドじゃないだろ。
218:デフォルトの名無しさん
10/06/14 21:30:06
オーバーヘッドの必然性がない所は
０オーバーヘッドにするように作られている
219:デフォルトの名無しさん
10/06/14 21:37:53
０．０１ぐらいで許せ
220:デフォルトの名無しさん
10/06/16 15:18:44
C++は共用体を安全に使うのが難しそう
Cは安全とか考えないから楽
共用体の配列のかわりにポインタの配列を使うとか
ポインタ配列に何か代入するたびにnewするとか
Java臭いコードになりそう
221:デフォルトの名無しさん
10/06/16 16:39:49
共用体は型フィールドのチェックのオーバーヘッドがある
けど分岐予測が当たりやすい気がする
仮想関数はパイプライン的にどうなるのかよくわからん
222:デフォルトの名無しさん
10/06/16 19:56:51
型安全な共用体なら boost::variant があるから OK
> 共用体は型フィールドのチェックのオーバーヘッドがある
の意味が良く分からないんだけど。
これは C++ 側の話じゃなくてユーザコードでってこと？
223:デフォルトの名無しさん
10/06/16 20:42:01
> 仮想関数はパイプライン的にどうなるのかよくわからん
分岐予測泣かせ
224:デフォルトの名無しさん
10/06/16 20:45:24
分岐予測ってそんなに重要なの？
いや、ループでは重要なんだろうけど、
switchのような類いのものはあまり役に立たないんじゃないかと
225:デフォルトの名無しさん
10/06/16 20:50:25
switchを繰り返すループがよく出てくるんだが
226:デフォルトの名無しさん
10/06/16 21:10:47
switchでは失敗しまくって、
ループでは成功しまくってんじゃないの
227:デフォルトの名無しさん
10/06/16 22:27:38
>>222
そう。型フィールドの値をassertとかswitchするユーザコード。
switchはdefaultとか特定のケースに偏ってないと役に立たないと思う。
assertの類のチェックは、失敗することは滅多にないから役に立つ。
228:デフォルトの名無しさん
10/06/17 13:42:51
分岐予測が当たるかどうかで50%ぐらい性能低下する場合もあるよ
229:デフォルトの名無しさん
10/06/17 13:51:55
レンホー「なぜ低級言語なんですか。Cじゃだめなんですか」
230:デフォルトの名無しさん
10/06/17 13:56:18
リストの各要素の仮想関数を呼び出す場合
交互に別の呼び出し先だったりすると
分岐予測機能一般化後の主流各CPUだとパターン検出すら出来ずに全て予測失敗する
パイプラインが長いCPUだと即死短くても瀕死になる
231:デフォルトの名無しさん
10/06/17 18:19:09
>>230
わかりそうで分からない。
多分、個々の用語が一般的ではないオレ用語・用法だからだろう。
232:デフォルトの名無しさん
10/06/17 18:56:52
>>229
一意じゃないとだめなんです
233:デフォルトの名無しさん
10/06/17 19:16:54
>>230
それはCでどちらを実行するか分岐しても同じなんじゃないの、と
234:デフォルトの名無しさん
10/06/18 08:27:23
>>230は一番たちの悪い部類の馬鹿
235:デフォルトの名無しさん
10/06/18 11:36:29
マルチコアもパイプライン無い時からCは存在してたのかな？
236:デフォルトの名無しさん
10/06/18 11:39:43
卵が先か玉子が先か
237:デフォルトの名無しさん
10/06/18 16:03:22
今のCPUはC的言語に最適化されとる
238:デフォルトの名無しさん
10/06/18 16:29:52
C++で分岐予測が外れた時どれ位のオーバーヘッドが生じるか試してみました
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
struct foo {
__int64 start, end, freq;
HANDLE hprocess;
DWORD oldclass;
foo() : hprocess(GetCurrentProcess()), oldclass(GetPriorityClass(hprocess)) {
Sleep(10);
// SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS);
QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
QueryPerformanceCounter((LARGE_INTEGER*)&start);
}
~foo() {
QueryPerformanceCounter((LARGE_INTEGER*)&end);
// SetPriorityClass(hprocess, oldclass);
printf("%d\n", (int)(end - start));
}
};
void func1() {}
void func2() {}
void func3() {}
void func4() {}
void func5() {}
void func6() {}
void func7() {}
239:デフォルトの名無しさん
10/06/18 16:32:13
void func8() {}
void func9() {}
void func10() {}
#define MAXITER 10000000
int main()
{
void (*func[])() = {func1, func2, func3, func4, func5, func6, func7, func8, func9, func10};
{
printf("Alternative Call : "); // 分岐予測が効きやすい
foo f;
for (int i = 0; i < MAXITER; i++)
func[i % 2]();
}
{
printf("Ranom Call : "); // 分岐予測が効きにくい
foo f;
for (int i = 0; i < MAXITER; i++)
func[(std::rand() >> 4) % 10]();
}
}
自宅の環境(Athlon64 X2 5000+)では乱数CALLの方が10倍強のコストが
生じました
240:デフォルトの名無しさん
10/06/18 16:43:08
上、%2なん？
randのコストは？
241:デフォルトの名無しさん
10/06/18 16:48:16
>>234
何一つ間違った事は書いていないが
242:デフォルトの名無しさん
10/06/18 17:06:09
>>240
てか、そもそもこれ予測分岐のコスト評価になってるか？
243:デフォルトの名無しさん
10/06/18 18:13:54
>>242
分岐予測が外れる以外に10倍近く差が開く理由はないだろ
244:デフォルトの名無しさん
10/06/18 18:19:41
>>240
そんなに気になるなら
func[std::rand(), i % 2]();
とでもしろ
ほとんど結果に影響しないから
245:デフォルトの名無しさん
10/06/18 21:18:33
コード見るとレベルが知れるな
246:デフォルトの名無しさん
10/06/18 21:21:12
同じ計算コスト、コードで分岐頻度だけ異なる場合でないと意味ない
247:デフォルトの名無しさん
10/06/18 21:25:16
そもそも分岐予測で間接ジャンプ？
248:デフォルトの名無しさん
10/06/18 22:10:23
>>245
まだ提示する方がお前さんのような上から目線よりはいいと思うZE
249:デフォルトの名無しさん
10/06/19 10:48:24
細かく突っ込みたいが…釣りだよな
250:デフォルトの名無しさん
10/06/19 12:15:36
------------------------------------------------------------
こ こ ま で 成 果 物 一 切 無 し
------------------------------------------------------------
251:デフォルトの名無しさん
10/06/19 12:51:44
俺が成果だ
252:デフォルトの名無しさん
10/06/19 13:41:38
成果なんか永遠に出ねえよ
253:デフォルトの名無しさん
10/06/19 13:46:25
このまま2chにスレを立て続けてたところで何も出てきやしねぇよ。 >>1
254:デフォルトの名無しさん
10/06/19 13:50:46
何か出るのを期待してる>>250>>253が馬鹿なだけ
さっさと2chブラウザを閉じろｗ
255:19
10/06/19 23:42:33
いちお、このスレ見てやる気が出てきて、色々作ってますよ。
template<T>T add(T a, T b) { return a + b; }
というものをうまいこと型推論などで型付きで
add(a,b){return a+b;}みたいに書けるといいなと思うのですが、
どうでしょう？
256:デフォルトの名無しさん
10/06/20 00:10:22
省略なしの場合
def add(a : int, b : int) : int { return a + b; }
型推論で
def add(a, b) { return a + b; }
単一式returnの場合のreturn省略で
def add(a, b) { a + b; }
何か関数型言語じみてきたが、
最近の言語はおしなべて関数型言語に近づいてる感があるので問題はなかろう
257:デフォルトの名無しさん
10/06/20 00:15:34
型推論はPTしづらい、と思ってんだがどうだろう？
低水準な開発は実機来るまでプログラムが動かないんで
関数レベルの単体テストが結構重要だと思う。
むー・・・既に時代遅れな考え方な気もするんだけどね。
258:デフォルトの名無しさん
10/06/20 00:18:23
関数テンプレートを作る意図がなければ
型を省略しなけりゃいいだけじゃない
259:19
10/06/20 03:19:44
>>256
そんな感じがいいと思います。
省略可能な文法でパースも楽なのがいいなと。
型推論なしでもtemplateの型用トークンを用意するというのはどうでしょう？
def add(a:'T, b:'T):'T = a + b
こんなかんじで、'Tから始まる変数はテンプレート型とするので
template<T>って書かなくてもいいとか。
260:デフォルトの名無しさん
10/06/20 08:13:20
型理論やばいなあ
落とし所が見つからないと廃人になる
261:デフォルトの名無しさん
10/06/22 22:47:01
プログラミング言語 を作ってみたよ
URLﾘﾝｸ(d.hatena.ne.jp)
262:デフォルトの名無しさん
10/06/22 23:28:51
Brainf*ck系はもういいよ！
263:デフォルトの名無しさん
10/06/23 23:53:36
で？成果品ないの？
264:デフォルトの名無しさん
10/06/24 21:43:21
>>252 >>254
265:デフォルトの名無しさん
10/06/24 21:46:43
勉強したはずの>>238に期待
266:デフォルトの名無しさん
10/06/25 23:19:24
シビレを切らした>>1が、とにかく成果物出せとわめくスレになりました
267:デフォルトの名無しさん
10/06/26 00:57:05
1日1スレ消費する勢いだったあの頃
268:デフォルトの名無しさん
10/06/26 22:49:15
いまみたいに規制されてなかったからな
269:デフォルトの名無しさん
10/07/16 21:01:51
tesutesu
270:デフォルトの名無しさん
10/07/17 01:32:04
一気に過疎化したな
271:デフォルトの名無しさん
10/07/17 03:20:16
全部他力本願だもん
そりゃ過疎化するわ
誰かが自分で処理系作って発表しないかぎり机上の空論でしかない
272:デフォルトの名無しさん
10/07/17 03:44:46
お前もそうじゃんw
273:デフォルトの名無しさん
10/07/17 08:21:55
言語なんて空想しているときが一番楽しい
274:デフォルトの名無しさん
10/07/27 17:33:39
>>271
自力で作れる人がアイデアを精査したく、議論を投げても
ループマンや、LISP厨、一行コメンター等が酷すぎて議論にならないって
はっきりしてしまうんだと思うのですよ。
少し高度な話題振ってる人間も、単にC++0ｘの議論を持ち込んでる
だけですし。C++0xがの流れを否定してるこのスレなのに、そのスレ主旨
の違いが分からず、C++0xで議論（本当に酷い人はC++0xのスレのコピペ）
されてることを書き込めば、レスが付く、スレに参加してるとでも勘違い
してるかのように。
どうも2chは勢いのスレに参加してると何かメリットあるとか勘違い
してる、無能な屑がかなり存在してるみたいで、それがこの結果>>270
なんだと思うんですよね。
275:デフォルトの名無しさん
10/07/27 17:56:25
便所の落書きに何を期待しているんだ？
276:デフォルトの名無しさん
10/07/27 22:35:24
>>274
いや、べつにC++0xの議論を持ち込んでもいいんだよ。
ただ、現状のC++0xは従来のC/C++とのある程度の互換性というシバリを引きずっているから、記述が非効率で、美しくなく、学習しにくいといった問題がある。
だから、従来のプログラミング言語にとらわれず、新しい言語がほしい。
ところが、今出てくる新しい言語といえば、LLばかリで、CやC++がカバーしている分野につかえるような言語はなかなか無い。
そこで、「C/C++に代わる低級言語を開発したい」というこのスレッドが立ち上がった。
過去のしがらみで不必要な制約がなければ、結果的に従来のプログラミング言語に似ていても問題ないよ。
277:デフォルトの名無しさん
10/07/28 00:47:22
じゃあGCを入れるべきか議論しようか
278:デフォルトの名無しさん
10/07/28 00:49:39
入れるべき。以上
279:デフォルトの名無しさん
10/07/28 19:08:09
GC の是非はしがらみじゃない
280:デフォルトの名無しさん
10/07/28 20:28:15
言語設計の観点からは、無いのはかなり困る
むしろGCとうまく付き合う方法を考えてくれ
エスケープ解析や明示的な寿命指定で
GCへの負荷をある程度下げることはできるだろうし
もともとスループットだけで言えば、GCは下手な手動管理より高効率
しかし、やはり最悪停止時間が保証できない問題は残る
部分的にGCを停止させるぐらいで妥協できないかなあと考えてるが、
う～ん……
281:デフォルトの名無しさん
10/07/28 20:43:56
スレタイ目指すならＧＣなんてありえんだろ。
別スレでやれｗ
282:デフォルトの名無しさん
10/07/28 21:23:09
>>281
無しで考えてもいいが、
それだとC/C++と大差なくなるんじゃないかなあ
283:デフォルトの名無しさん
10/07/28 23:04:58
>>280
ＧＣって使うのめんどくさいんだな
284:デフォルトの名無しさん
10/07/28 23:43:31
そういやGCな言語って最大使用RAMとか見積もれるのか？
これが無理だと、かなり組み込みで使えるトコが限られるんだけど。
実はまだメモリ解放されてません、とかだと凄く困る。
285:デフォルトの名無しさん
10/07/29 00:22:38
>>284 GC ってのは資源が有り余ってるときに使える手法
GC が発生する頻度とその時に回収出来るメモリー量と回収に必要な時間が
許容範囲内なら使える
つか, 「malloc 実装したとしてメモリー足りなくなったときにブロックするの禁止」
な， 世界ではほぼ使えない
286:デフォルトの名無しさん
10/07/29 03:39:49
引数に渡すものを構造体限定にすれば速くなるんじゃない？
他には、
スタック関連の呼び出しや初期化を極力抑えて、
メモリの割り当てもメモリープール的な考え方で割り当てて、
メモリ解放の概念を取っ払って、
安全性のチェックを全部やらない。
要するに、ハードウェアは弄るけど、全責任を開発者に投げる的な。
最悪、OSごと落ちるかもしれないけど、高速化するんだったらこうなるでしょ。
後は、Pen4以前をサポートしないようにしたり、
SIMDの命令をもうちょっと使いやすいようにしたり。
287:デフォルトの名無しさん
10/07/29 05:18:03
そんなシロモノは
C/C++に代わる低級言語
にはならないと思うなボクは
288:デフォルトの名無しさん
10/07/29 06:58:43
たしかにメモリ開放のタイミングを制御できないＧＣ言語はC/C++の代用にはならんわな
289:デフォルトの名無しさん
10/07/29 12:40:58
GC言語がメモリ解放のタイミングを制御できない？？？？？
290:デフォルトの名無しさん
10/07/29 18:22:29
> 後は、Pen4以前をサポートしないようにしたり、
んなクソでかい CPU を強制される言語はやだな
>>289
仮に制御できたとして、だから何だい？
288 はタイミングとしか言ってないから開始時期のみの話にも聞こえるが
仮にベストなタイミングで開始できても何秒かかってもいいってことではあるまい
291:デフォルトの名無しさん
10/07/29 20:59:48
C/C++って組み込みでしかシビアな組み込みでしか使われてないと思ってるの？
292:デフォルトの名無しさん
10/07/29 21:01:26
日本語が変になった。つまりアンチGCは頭の固いただの老害ってことだよ
293:デフォルトの名無しさん
10/07/29 21:17:13
いわゆる「富豪的」な環境でもかまわんよ
ナノ秒がミリ秒に遅延する仮想記憶でさえ要注意な場面はあるわけで
ナノ秒が秒まで遅延する仕組みが天使の取り分でいつも済むとは限らない
おまえさんの言う老害は年齢ではなくシステムプログラミングに対する知見の違いで
もしかしてブーメランかもね
294:デフォルトの名無しさん
10/07/29 21:19:34
何言ってんだコイツｗ
なんでGC言語ではGCを必ず使わなければいけないって決まってるわけ？ｗｗｗ
295:デフォルトの名無しさん
10/07/29 21:25:38
で、free という GC を選択的に使えばいいわけだw
296:デフォルトの名無しさん
10/07/29 21:31:33
マジで言ってるのなら頭が悪すぎて話にならない
297:デフォルトの名無しさん
10/07/29 21:45:32
おまえに褒められても気持ち悪いだけさ
298:デフォルトの名無しさん
10/07/29 21:59:48
お前もGCされたら？
↓
299:デフォルトの名無しさん
10/07/29 22:08:24
>>294
てか今時GCが使える状況でC/C++を選択する理由が思いつかんのだけど
どういう状況でどういう利点があるの？
300:デフォルトの名無しさん
10/07/29 22:18:06
実際に使われてるんだから仕方ないだろ
301:デフォルトの名無しさん
10/07/29 23:12:26
しょぼ・・・
C++しか使えない奴らが作ってたり、過去資産があるだけのトコに
互換性のない言語突っ込んで何がしたいの？
302:デフォルトの名無しさん
10/07/29 23:13:49
日本語でおk
303:デフォルトの名無しさん
10/07/30 02:01:15
私にとって、本当のオブジェクトのセマンティクスに関する素晴らしいことの１つは、
本当のオブジェクトが「端から端まで本当のコンピュータ (RCATWD)」であることです。
これによって、何でも表せる完全な能力をいつでも保持できます。古いやり方は、
すぐにコンピュータではない2つのこと、データとプロシージャに行き着き、
不意にふるまいに合わせて最適化と特定の決定を任せる能力を失っていました。
言い換えれば、常に本当のオブジェクトを持つことにより、ほしいものを再現し、
惑星の周りに送る能力を保持します。そして、RCATWDはまた、両方向を完璧に保護します。
これはインターネットのハードウェアモデルの中に見られます。(使えるもので、
唯一の本当のオブジェクト指向システムかもしれません) 無料で言語拡張機能を手に入れるには、
メッセージ形式に従うだけです。私が70年代に考えたのは、パーソナルコンピューティングと
同時に取り組んでいるインターネットは、本当に素晴らしいスケーラブルな設計であり、
ハードウェアでキャッシュできる仮想マシンの仮想インターネットを作るべきだというものでした。
これが実現されなかったのは本当に残念です。
304:デフォルトの名無しさん
10/07/30 02:02:05
私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。
Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと考えました。
そして、私の論文の指導教官が言いました。
「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」
彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。
これを信じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いました。
オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、
オブジェクト間で分離し、ポリモーフィズムを持つものです。
305:デフォルトの名無しさん
10/07/30 05:17:44
お年寄りの話は面白くないです
306:デフォルトの名無しさん
10/07/30 05:30:58
元々緩やかな下降線にはあったけど、人が減った事によって
それまでは人混みに隠れていた工作員の存在が目立つようになったのが致命傷だったな
工作員の誘導を嫌って参加者が減り、他所からの工作員を排除しようとして規制をするから
参加機会が奪われて更に参加者が減るという負のスパイラルにおちいってる
307:デフォルトの名無しさん
10/07/30 05:47:45
このスレまだあったのか
308:デフォルトの名無しさん
10/07/30 07:40:46
こんなゴミスレでもスレタイにC++が入ってるだけでパート7まで行くとはな
309:デフォルトの名無しさん
10/07/30 07:58:26
仲間に入れずクラスの後ろでブツブツ言ってるヤツ >>307-308
310:デフォルトの名無しさん
10/07/30 15:41:13
GCを実装していても低級言語と呼べるのか。勉強になる。
だったらGCを実装したアセンブラとかならスレタイを満たすんじゃないのかな。
311:デフォルトの名無しさん
10/07/30 16:24:31
もしかしたらハードウェアレベルでGCの機能を提供できるようになるかもよ
312:デフォルトの名無しさん
10/07/30 16:25:56
アホが１人キレやがったw
313:デフォルトの名無しさん
10/07/30 18:47:38
>>290
＞んなクソでかい CPU を強制される言語はやだな
なぜですか？
>>299
リアルタイム系だと止まるのでGCは使いません。
ゲーム（XNA）だと勝手にGCを発動されるとフレーム描画が止まるので、
ロード中に全て開放して全て読み出しています。
ゲーム中はデータの読み込みやnewを一切行いません。止まるので。
メモリの中にあるものが全てです。
314:デフォルトの名無しさん
10/07/30 18:54:56
C/C++ は元々システムプログラミング用言語で how な部分に深く立ち入ることにミッションがある
what に特化したアプリ用言語と相容れないのは論を待たない
オブジェクトが動的か否かも how の領域であり、問題そのものが本質的に持つ要求ではなく
アプリの土方がここに無気になることには上も下も見えていない滑稽さが漂う
315:デフォルトの名無しさん
10/07/30 19:53:59
>>314
>what に特化したアプリ用言語と相容れないのは論を待たない
そうやって思考停止して満足してるわけだ。
316:デフォルトの名無しさん
10/07/30 20:03:53
昔はそういう止まると困るものは割り込みで処理するようにして、
本体では重い処理をやるようにしてたものだが。
317:デフォルトの名無しさん
10/07/30 23:18:26
>>313
「開放」と「解放」の区別もつかない人に語る資格はないと思うが。
318:デフォルトの名無しさん
10/07/30 23:26:48
人民開放軍ではなく
人民解放軍なんですね
319:デフォルトの名無しさん
10/07/30 23:40:12
>>317
介抱してやれ
320:デフォルトの名無しさん
10/07/31 02:14:48
言語にRTOSを組み込めば解決だな
gcもスレッド毎にon/off
gcより高レベルなタスクは止まらないとか
321:デフォルトの名無しさん
10/07/31 02:39:40
>>320
CPUごとに異なる言語を作るって意味ね。がんばれ。
322:デフォルトの名無しさん
10/07/31 02:42:17
機械語やってろよもう
323:デフォルトの名無しさん
10/07/31 09:10:57
>>320
残念ながら不可能
324:デフォルトの名無しさん
10/07/31 09:54:04
> CPUごとに異なる言語を作るって意味ね。がんばれ。
意味がわからん。
言語がモニタとかの同期機構の面倒を見る、というのはAdaなんかであたりまえにやってるし、
AdaがCPUごとに異なるなんて話は聞いたことがない。
325:デフォルトの名無しさん
10/07/31 09:59:30
なんで伸びてるのかと思えば、>>1が巻き添え規制から解除されてまた暴れてるのか。
326:デフォルトの名無しさん
10/07/31 10:14:06
言語にRTOSを組めば→そのRTOSは何言語で組むの→その言語自身で…
327:デフォルトの名無しさん
10/07/31 10:18:37
>>313
GCで不意に止まっちゃ駄目な環境で最近作ってないんだけど、
昔ながらにプールしてGC極力走らせないとか毎フレ強制GCしたりの他に、
止まらないGCとかそういう手法みたいなのって開発されてないの？
コンシューマ機だと本体はC/C++ばっかりだと思うけど
最近はLuaとか当たり前に使われているよね？
そのへんどうしているのかな、と思って
328:デフォルトの名無しさん
10/07/31 10:35:03
>>324
VESAのような統一規格があるモニタと、全くないCPUを同一と考えてるの？
CPUの型番で周辺機器も異なるし、物理メモリ空間の使い方も異なるし、
割り込み番号の振り方だって違うんだよ？
フリーのOSのソースコード読んだことある？
329:デフォルトの名無しさん
10/07/31 10:54:45
モニタと言われて同期機構のことだとピンとこないような、RTOSのド素人は黙ってたほうが身のためですよ？
330:デフォルトの名無しさん
10/07/31 11:06:45
OSとか組み込みマイコンとかの”チープな環境”の領域まで、
C(/C++)にとって変わらなくていいだろ。
言語にOS乗っけるとか、H/WでGCしろとか、本末転倒な話ばっかりじゃんかよ。
331:デフォルトの名無しさん
10/07/31 11:27:12
ガベコレにはOSやハードウェア支援があったほうがいいし（現状あまり研究とかないけど）、
言語機能とOSの機能が（たとえばスレッドとか）密であっても悪くないだろ。
どこが本末転倒？
332:デフォルトの名無しさん
10/07/31 12:23:44
>>324
モニタって既存RTOSのサポートがあってこそ。
既存CPUすべてサポートしてるRTOSなんて聞いたことないが。
333:デフォルトの名無しさん
10/07/31 13:04:47
そりゃPICからスパコンまで全部サポートしてるシステムなんてないだろ。
>>321 は、CPUが異なったら、同期機構が異なるものになる、と主張してるようにしか読めん。
確かにテストアンドセット系のプリミティブはCPUごとに異なるけど、もしかしてそれを
直接言語にしたら、っていう意味なのかな？
たいていのOSでは、OSで共通化した同期機構を提供していて、CPUのそういったプリミティブは
掩蔽されているものだが。
334:デフォルトの名無しさん
10/07/31 20:40:17
「C/C++に代わる」というのスレタイの解釈が、GC有り派とGC無し派で違うから
話が全くかみ合わない。
335:デフォルトの名無しさん
10/07/31 20:46:08
>>1 としては「超高速」の存在によってGC有りは排除されると考えてるんじゃないだろうか。
336:デフォルトの名無しさん
10/07/31 22:21:41
GC前提のコーティングとGCレスのコーティングって全く違ってくると思う
337:デフォルトの名無しさん
10/07/31 22:25:43
GC有り排除は考えなくていいよ。
言語仕様にはGCを含めて、実装できる環境なら実装すればいい。
はじめから無しとする必要はない。
338:デフォルトの名無しさん
10/07/31 22:28:07
GCがあって高速な言語がいまだかつてあっただろうか？
339:デフォルトの名無しさん
10/07/31 22:39:23
LISPってC並に速いんじゃなかった？
340:デフォルトの名無しさん
10/07/31 22:41:49
瞬間最大じゃなく瞬間最小が問題になるんだが
# 保証という課題に対する思想が深刻にまずいのがいるな
341:デフォルトの名無しさん
10/07/31 22:42:14
実測結果を提示せよ
342:デフォルトの名無しさん
10/07/31 22:46:31
このスレで考えようとしてるのってどう考えてもC++以下のゴミ言語だよね
アセンブラの方がマシってレベルだよ。脳みそ空っぽなんだろうな
343:デフォルトの名無しさん
10/07/31 22:51:34
GC有りでCより速いのはないよな？
つまりGC有りは議論の余地すらないんじゃないか？
ここらでばっさり不要なものは枝刈りしないか？
344:デフォルトの名無しさん
10/07/31 22:53:07
>>339
その主張には前提があって、
Lispのほうが高水準で、マクロとかの道具立てがあるから
アルゴリズムとかの試行錯誤がやりやすい、
だからより良い結果にたどり着きやすい、という意味
URLﾘﾝｸ(blog.practical-scheme.net)
十分に大量のリソースが与えられたのなら、Cのほうが速くなるはず
実際、Lisp処理系を機械語レベルで眺めると、
C処理系ほど高品質なコードは吐かないらしい
＞両者の生成コードの間には、実行効率の点で今だに無視出来ない開きがあるのも事実である。
URLﾘﾝｸ(jp.franz.com)
345:デフォルトの名無しさん
10/07/31 22:55:08
LISPのマクロは星井
346:デフォルトの名無しさん
10/07/31 22:58:24
アセンブラのマクロって意外と便利だよな
俺はああいうのでいいよ
347:デフォルトの名無しさん
10/07/31 23:02:25
>>343
ほんっっっっっとうに、頭悪いな
348:デフォルトの名無しさん
10/07/31 23:02:57
>>343
GCは汎用のアルゴリズムだから、問題領域固有の条件を用いることができない
だから、理屈の上では、プログラマが慎重に手動管理すれば
速くなる可能性はある
……理論的にはね
349:デフォルトの名無しさん
10/07/31 23:05:05
>>348
何その手動管理って。
GCレスより面倒な気がするが？
350:デフォルトの名無しさん
10/07/31 23:15:21
汎用のアルゴリズムと言いつつ、
GC有り無しは完全に言語を2分する存在だよね。
このスレでも「GC有りは遅い」と思い込む人多数。
つまり性能がどうあれ需要がない。
そして需要はコード品質に直結する。
GC有りのJabaやどとねとは業界権力で生き残ってるけど、
使われてるから使うだけで、単なる1技術として見たら
本来は見向きもされない存在。
351:デフォルトの名無しさん
10/07/31 23:19:31
シムラ、後ろ後ろ
352:デフォルトの名無しさん
10/07/31 23:19:49
.NETからしか使えないようにするとか
DirectX10以上じゃないと動かないとか
すべて商売上の都合だな
あ、javaは影響力弱いから無くても困らないけどな
353:デフォルトの名無しさん
10/07/31 23:21:37
GC無しの言語こそ需要ないけど
354:デフォルトの名無しさん
10/07/31 23:23:44
GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
ってわかんないんだよね。これが気持ち悪いって人いると思う。
ライブラリで一応実装できるんだから言語機能に入れることないよ。
355:デフォルトの名無しさん
10/07/31 23:26:09
最近の言語は、言語機能もライブラリで実装されているから、
ライブラリで一応実装できるんだから言語機能に入れることない、なんて必要はない。
356:デフォルトの名無しさん
10/07/31 23:30:32
>>354
まあ失うものは結構あるけども、
それはそれで一つのアプローチだとは思う
357:デフォルトの名無しさん
10/07/31 23:34:46
ところでPerl並に普及してるGCなしのスクリプトってある？
shとか？
358:デフォルトの名無しさん
10/08/01 00:27:48
>>333
「掩蔽」じゃなくて「隠蔽」だな
>>354
「開放」じゃなくて「解放」だな
359:デフォルトの名無しさん
10/08/01 01:32:04
とりあえず、GCありきの文法にならなきゃ、あろうがなかろうがどうでも良い話。
最後の最後に辻褄あわせるようにGC向けの構文入れりゃ満足だろ？
360:デフォルトの名無しさん
10/08/01 01:34:38
構文上、プログラマーが意識しなくても適切にリソース管理が行われるなら、GCは無くてもいいよ。
GCは手段であって、目的ではない。
361:デフォルトの名無しさん
10/08/01 02:44:46
>>327
GCのメリットデメリットは自動的に監視して解放することだから、
仮に自動監視を外したとしてC/C++でメモリをリスト使って管理するのと大差なくなるのでは？
Luaで止まるってことはなかなかないですよ。
どの道、利用しているのはC/C++の関数やクラスなので、
止まるとしたらC/C++側の問題のほうが多いです。
関数の実装に近いような使い方をするので生成とかは通常させません。
362:デフォルトの名無しさん
10/08/01 02:47:44
int *hoge = (int*)GC::alloc(sizeof(int)*10);
これでいいんじゃないか？
363:デフォルトの名無しさん
10/08/01 06:54:00
> GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
> ってわかんないんだよね。
資源を確保するところで起きる可能性がある。
はっきりわかってるじゃないか。
364:デフォルトの名無しさん
10/08/01 06:56:34
「使わない」選択のない realloc か
365:デフォルトの名無しさん
10/08/01 08:03:26
ほらな、みんなPCで動かすことしか考えてない。
366:デフォルトの名無しさん
10/08/01 11:03:52
>>365
どうしてそう思っちゃったの？
367:デフォルトの名無しさん
10/08/01 13:32:20
チープな環境ならGC使わなきゃ良いっつーけど、
ぶっちゃけ言うと、リソース管理を自力で出来ない奴が
その言語経験者としてアサインされることが一番困る。
368:デフォルトの名無しさん
10/08/01 16:47:10
そこは事前に振り分けとけよ。
369:デフォルトの名無しさん
10/08/01 21:17:43
その人事振り分けもやってくれるコンパイラを作ればおｋ
370:デフォルトの名無しさん
10/08/02 02:04:38
>>327
ソフトリアルタイムシステムまでであれば
Erlangっていう実例があるので、決して不可能ではない
----
Erlangをベースとする初期のプロダクトが1993年に開発されていた頃、
（Javaのような）ゴミ集め処理を伴うVM用にコンパイルする言語を、
ソフトリアルタイムシステムに対して使うなどというのは狂気の沙汰だと批判されたものです
（Francesco Cesarini, Simon Thompson著 『Erlangプログラミング』より）
----
371:デフォルトの名無しさん
10/08/08 02:17:49
このスレはまずwintel脳、言語どころかOSやシステムプログラムをロクに知らないヤツらを隔離すべきだな
372:デフォルトの名無しさん
10/09/25 10:12:53
久しぶりに書き込める！！
構造化されたパターンマッチング機能だけなら、GCなしでも入れられるよね。
373:デフォルトの名無しさん
10/11/07 03:36:30
まだこのスレあったのか。
一時期凄い勢いだったのにやっぱり言語仕様まとまらなかったのかね。
374:デフォルトの名無しさん
10/11/07 05:33:14
7スレ使って1つも成果物なし？
URLﾘﾝｸ(studiokingyo.fc2web.com)
375:デフォルトの名無しさん
10/11/07 07:22:10
よくある話だろ。
すでにまとまってる言語仕様にすらあーだこーだ言う連中がうようよ
してるんだから。
376:デフォルトの名無しさん
10/11/07 13:07:19
なんども言っているが、ここは、何かをまとめるスレではなくて、考えるスレなので。
377:デフォルトの名無しさん
10/11/07 13:53:20
何か「成果物」ができてきたら、それ専用のスレをたてるべきだな
378:デフォルトの名無しさん
10/11/07 14:42:36
いいプログラミング言語に必要なのは
複雑なロジックを簡単に書ける事だと思うんだよね
読みやすくて、ロジックが短くなる言語って何があったろ？
379:デフォルトの名無しさん
10/11/07 14:44:07
Python
380:デフォルトの名無しさん
10/11/07 14:58:49
ブロック要素がインデント依存ってのは独特だが、確かに短いな
短いと言ってもブロック定義の関係で短いって感じだけど
381:デフォルトの名無しさん
10/11/07 15:04:19
複雑なロジックを簡単なロジックに分割ってのは
ほとんどの言語が目指すところで特にどれってこともない
一見簡単そうな記述が書いた本人もびっくりのオーバーなことになっている言語ってどうなんだろ
BASIC とか
382:デフォルトの名無しさん
10/11/07 15:36:35
「簡単」というのは表記が短いことも当然あるが、その表記の意味を容易に学習できることも重要。
そのためには、一貫性のある最小限の文法であることが望ましい。
表記を短くするためであっても、「ただし、こういう場合にはこうでなければならない」といった、場合による例外事項は避けるべきだ。
383:デフォルトの名無しさん
10/11/07 20:16:01
>>376
考えるスレですらなかったろ
全員が好き放題妄想を垂れ流してただけ
384:デフォルトの名無しさん
10/11/07 20:30:13
結局誰も考えをまとめようとしなかったから結局言いっぱなしのスレに・・・
385:デフォルトの名無しさん
10/11/07 21:18:21
何か成果を出さなきゃならないとの強迫観念に駆られてるノイローゼ諸君はわざわざ参加しなくていいんだよ。
言語好きが集まって、理想の言語に付いていろいろ語り合って、知識を増やしり、楽しんだり出来ればそれで十分。
そこから派生して何か「成果」を出したいなら出せばいいが、それはこのスレに求めることじゃない。
386:デフォルトの名無しさん
10/11/07 21:28:11
このスレにそんな俺様ルールがあったのか。
387:デフォルトの名無しさん
10/11/07 23:32:09
ルールも何も、何か成果を出すなんてことはこのスレの目的にそもそも無い。
388:デフォルトの名無しさん
10/11/07 23:51:06
言うことは言うけど、参加するって人が少ないなと。
そんな自分はプログラミング言語その物について勉強中だが、
趣味時間だけで言語の作り方把握するのってちょっと大変
389:デフォルトの名無しさん
10/11/08 00:00:04
>>387
そうだったのね。
てっきりスレタイには開発したいとかテンプレ>>3-4みたら成果を求めてるんだと思った。
まぁ意見は言っても参加はしてないから関係ないけど。
390:デフォルトの名無しさん
10/11/08 00:05:17
まあ、勘違いは誰にでもある。そんなに気にしなくてもいいよ。
391:デフォルトの名無しさん
10/11/08 01:03:45
自治厨乙
392:デフォルトの名無しさん
10/11/08 01:54:06
言語仕様まで考えて発言してる人を見たことがないがな。
理想理想と言いながら実現不可能な仕様上で議論しても仕方ないだろう。
実現可能な仕様を考えることも成果と呼ぶのかい？
393:デフォルトの名無しさん
10/11/08 01:55:18
また自治厨が現れた
394:デフォルトの名無しさん
10/11/08 01:57:14
仕方が無いと思うなら議論に参加しなければいい。誰も強制はしない。
395:デフォルトの名無しさん
10/11/12 22:30:22
話を蒸し返すようだが、低級言語を目指すのであれば、GCは最適化の手段として位置づければよい。
文字列や木のノードのような純粋なデータを効率よく扱うためにGCを利用するオプションがあればそれでいい。
ストリームだのウィンドウだのをGCする必要はないし、本当は高級言語でもそうすべきではない。
その点ではよくあるOOPLよりC++の方が理念的に正しい。
396:デフォルトの名無しさん
10/11/13 08:07:01
だれも知らないだろうけどamigaEは>>3のコンセプトにわりと合致するんだ
E is an object-oriented/procedural/unpure functional/whatever language with quite a popular implementation
on the amiga. It's mainly influenced by languages such as C++, Ada, Lisp etc., and features extremely fast
compilation, inline assembler, large set of integrated functions, powerful module concept, flexible type-system,
quoted expressions, immediate and typed lists, parametric and object polymorphism, exception handling,
inheritance, data-hiding, methods, multiple return values, default arguments, register allocation, fast memory
management, unification, LISP-Cells, macro-preprocessing, a very powerful source-level debugger, gui-toolkit,
library linker, and then some.
397:デフォルトの名無しさん
11/01/04 20:41:13
過去ログが大勢の目から隠されてしまう2ch掲示板でこういう理論って不毛じゃね？
398:デフォルトの名無しさん
11/01/29 16:49:41
GCやVMいらないならセキュア、リアルタイム、マルチコア向けC派生言語(というかほとんどC++)として
Sappeur Compiler [ URLﾘﾝｸ(www.sappeur.eu) ]とか既に段階で存在する。BSDライセンスね。
さらに一部の関数型言語ではCソースも吐けるわ、小型の組み込みSchemeインタプリタも
あるわけで。なんか今更Cの派生言語なんか必要かよと思うわけですが...。と釣ってみる。
399:デフォルトの名無しさん
11/01/29 17:18:40
段階？
400:デフォルトの名無しさん
11/01/29 17:58:59
ある言語（またはツール）が吐いた C ソースでは、
できることの範囲がそいつと C の積集合になるのは
わかってる？
401:デフォルトの名無しさん
11/01/29 18:00:23
チューリング完全∩チューリング完全≡チューリング完全
402:デフォルトの名無しさん
11/01/29 18:40:49
Sappeur面白そうだな。勉強してみよう。
403:デフォルトの名無しさん
11/01/29 18:45:10
もしかして万能と混同してる？
404:デフォルトの名無しさん
11/01/29 18:46:26
どういう意味？
405:デフォルトの名無しさん
11/01/29 19:00:41
401 がチューリング完全と万能を混同しているように聞こえた
406:デフォルトの名無しさん
11/01/29 19:09:49
聞こえちゃったならしょうがないな
407:デフォルトの名無しさん
11/01/29 19:20:43
へーえ、違うのかい？
408:デフォルトの名無しさん
11/01/29 19:24:09
まあ、チューリング完全でも、空飛べたり、子供産めたりはしないだろうから、完全とは違うだろうな。
409:デフォルトの名無しさん
11/01/29 19:27:39
そんな空想論を持ち出さなくても
切実な問題がいくらでもあろうが
410:デフォルトの名無しさん
11/01/29 19:28:44
例えば？
411:デフォルトの名無しさん
11/01/29 19:31:06
疑似でない乱数が標準 C だけで作れるか？
412:デフォルトの名無しさん
11/01/29 19:36:26
確かに切実な問題だな
413:デフォルトの名無しさん
11/01/29 19:39:24
ごく単純化したモデルで示すが
int a(b, c, d, e) { return b * c + d * e; }
のような処理に CPU アフィニティをどう指定する？
時間的保証はどうする？
414:デフォルトの名無しさん
11/01/29 19:49:23
俺の就職はどうする？
415:デフォルトの名無しさん
11/01/29 19:50:20
プログラミング言語は神ではない。
416:デフォルトの名無しさん
11/01/29 20:22:28
と、ここまで全部独り言
417:デフォルトの名無しさん
11/01/29 20:28:09
遠吠え乙
418:デフォルトの名無しさん
11/01/30 20:22:23
え？
419:デフォルトの名無しさん
11/01/31 12:45:45
お？
420:デフォルトの名無しさん
11/02/02 22:33:04
ジョブズみたく、C++を再定義します
って言えば、もっと盛り上がったかなぁ
421:デフォルトの名無しさん
11/02/03 00:00:02
要は、CPUやメモリやハードウェアを何の制限もなくいじれて、
マシン語とちゃんぽんにできる言語ってことだろ。
昔の AppleII の BASIC みたいに。
422:デフォルトの名無しさん
11/02/03 00:14:00
Cを完全に置き換え可能で、Cより新しいスタイルでの記述が可能なプログラミング言語
423:デフォルトの名無しさん
11/02/03 04:04:08
D言語？
424:デフォルトの名無しさん
11/02/03 05:58:29
>>421みたいな仕様になってもWindows上で動く限り制限されまくるよな
OSでも作るなら別だけど
425:デフォルトの名無しさん
11/02/03 06:59:44
go go google
426:デフォルトの名無しさん
11/02/03 12:20:34
>>424みたいなバカが居るからこのスレは駄目なんだ
427:デフォルトの名無しさん
11/02/03 13:15:28
一行バカレスが
他のスレにも出没しているみたいなので
スルーよろ
428:デフォルトの名無しさん
11/02/03 13:41:03
むりやり
改行してるだけで
ブーメラン
429:デフォルトの名無しさん
11/02/04 23:55:21
RiteVMがこう言う方向性なのかと一瞬思ったけど、違った。
430:デフォルトの名無しさん
11/02/05 07:59:20
CやC++は高級言語だから前提が間違ってるのに、7まで続けるとは何ぞや。
431:デフォルトの名無しさん
11/02/05 12:56:26
>>430
>>1を1000回読んでから顔洗って出直してこい
432:デフォルトの名無しさん
11/02/05 13:04:45
何度読もうが高級言語なのは事実だ
433:デフォルトの名無しさん
11/02/05 13:11:48
CやC++が高級言語ではないとは言ってないだろ。
434:デフォルトの名無しさん
11/02/05 14:13:28
あー、>>432 の定義する「高級言語」でいいよ別に
名前をどうしたいかじゃないから
435:デフォルトの名無しさん
11/02/06 00:38:52
>>1
C++でいいんじゃねえの
C++ですら手が届かないところはインラインアセンブラでGO
436:デフォルトの名無しさん
11/02/06 01:12:27
スレタイ嫁
437:デフォルトの名無しさん
11/02/08 19:33:35
目指してる 未来が違うｗｗｗｗｗｗｗｗｗ ｂｙシャープ
URLﾘﾝｸ(twitter.com)
438:デフォルトの名無しさん
11/02/16 02:37:09
リアルタイム性を損なわず、かつコードがでかくならずに>>1の仕組みを実行できれば完璧なんだろうけどなぁ
439:デフォルトの名無しさん
11/03/12 20:44:42.91
age
440:デフォルトの名無しさん
11/03/31 22:15:34.68
1日1スレ消化してたあの頃
このスレが何かしてくれるんじゃないかと夢見たなぁ・・・
441:デフォルトの名無しさん
11/03/31 22:39:45.30
C/C++の範囲をカバーするだけの言語なら既に山ほどあるからな。
C/C++だけでしかできないなんてものは最初から無い。それこそC言語の誕生当時から、C言語に存在価値なんて全くなかった。
単に物好きなUNIX屋が使ってて、CとBASIC以外の言語では他ベンダに押されてたMSがWindows APIに採用したというだけで
偶然広まった言語に過ぎない。
問題は「代わる」の部分で、これは要するに既にあるC系言語の資産を全て書き換えた上で、
C言語を使ってる連中を転向させなければならない。こっちのほうが遥かにムズイ。
ってかこれができるなら何十年も前に既にModula-2はCを置き換えてた。
442:デフォルトの名無しさん
11/03/31 23:19:18.86
単にModula-2がその程度の言語だってことだろ。
443:デフォルトの名無しさん
11/03/31 23:34:22.53
餌でか杉
444:デフォルトの名無しさん
11/03/31 23:58:37.99
>>443は>>442へのレスだよな？
実際Modula-2は、まともなモジュール化機能、ポインタ演算、豊富な型、structural typing、例外、オプショナルなGC、
コンパイラによってはgenericやオブジェクト指向の拡張があって、70年代後半としては超先進的な言語だぞ。
しかも開発者本人によるOSのリファレンス実装まであった。
予約語が大文字でキモイことを除けば、言語仕様だけの評価なら十人が十人Modula-2 > Cと言うだろう。
それでもC言語に代われなかった、そういうことだ。
445:デフォルトの名無しさん
11/04/01 00:07:34.28
> 予約語が大文字でキモイことを除けば、
これが結構致命的だったのでは
446:デフォルトの名無しさん
11/04/01 00:12:36.04
だから、Cに対するModula-2のアドバンテージがその程度だってことだ。
447:デフォルトの名無しさん
11/04/01 00:13:32.17
キモさ勝負ならCの文法だって充分キモイし、当時はBASICやらALGOLやらCOBOLやら全部大文字で書く言語も珍しくなかったから
その辺割とどうでも良かったと思うんだけどなあ。
まあ今の感覚で見ると間違いなくキモイんだが。
448:デフォルトの名無しさん
11/04/01 00:15:03.54
>>446
だったらどれぐらい差があればいいと思うんだ？
ぶっちゃけ当時の規格化もされてないCとModula-2の差は、
>>1が作ろうとしてる言語とC++0xの差よりでかかったと思うぞ。
449:デフォルトの名無しさん
11/04/01 00:21:33.19
>>441
Cはアセンブラと混ぜて書くことも簡単にできるから、
「代わる」作業を分割払いできる。
一括がムズイなら分割すればいいだけ。
450:デフォルトの名無しさん
11/04/01 00:22:34.25
>>448
思うのは自由だね。
451:デフォルトの名無しさん
11/04/01 00:24:02.79
>>449
おまえはCを使い続ければいいよ。
452:デフォルトの名無しさん
11/04/01 00:25:17.75
> だったらどれぐらい差があればいいと思うんだ？
頭の悪そうな質問しますね
453:デフォルトの名無しさん
11/04/01 00:25:49.98
分割して「代わる」部分を書くためには、Cと代わる部分の2言語を知る必要があるから、
それなら代わる部分も含めて一つの言語で書ける新言語が欲しいというのが>>1の意図。
454:デフォルトの名無しさん
11/04/01 00:29:58.95
共産主義者とかユートピア思想などと呼ばれるやつですね
455:デフォルトの名無しさん
11/04/01 00:34:40.71
>>449
なんでCがアセンブラと混ぜて使えることが、代わる作業を分割払いできる理由になるんだ？
ぶっちゃけ呼び出し規約に互換性さえあれば、大抵のコンパイラで、Cのコードを
オブジェクトファイル単位で順次置き換えていくことは可能だぞ？
問題は、可能不可能ではなく、回りの人間に置き換え後verを使わせられるかどうかだ。
例えばzlibは多くの言語でリライトされてて中にはC版より高速と主張してるのもあるが、
実際使われてるのはオリジナルのC版なわけで。
456:デフォルトの名無しさん
11/04/01 01:20:54.35
まあCが良い言語かどうかはともかく、Modula-2はねーよ。
予約語大文字は想像以上にキモイからね。
そういうシンプルな理由が人気を左右するんだよ。
Lispが天下取ってないことでも分かるだろうに。
457:デフォルトの名無しさん
11/04/01 01:24:59.15
>>455
おそらく、高速バージョンよりも単純で小さいのを目指すほうが評価は高い。
458:デフォルトの名無しさん
11/04/01 02:30:17.72
>>456
別に今からModula-2を推そうってわけじゃねーよ。単に過去にCに挑んで敗れた言語ってだけだ。
ただまあ、予約語大文字がキモイってのは、現在予約語が小文字の言語ばっかになって慣らされてしまってるからで、
当時はそんな珍しいものではなかったはずなんで、Lispと同列に語るのはねーよ。Lispは当時でもキモかったはずだw
比較演算子==と!=も、初めて見たときは相当にキモかったはずだろう？
459:デフォルトの名無しさん
11/04/01 09:31:46.09
>>458
その当時の人も大文字ばかりの言語はウザイと思ってて、
だから大文字小文字の区別あり／予約語小文字のCが受け入れられた可能性もある。
当時を知らんけど。
460:デフォルトの名無しさん
11/04/01 10:27:23.05
C/C++のスクリプト言語つくってくれ。
インタプリタだが、Cのソースもはけるやつ。
およそPHPみたいなやつ。ライブラリが豊富なやつ。
461:デフォルトの名無しさん
11/04/01 20:43:06.35
Modula-2がキモかったというよりは、言語としてCを置き換える（というか普及する）ほどの魅力がなかったというだけ。
コンパイラやライブラリがショボかったのも問題。
462:デフォルトの名無しさん
11/04/01 20:48:59.00
別にいいんだけど、俺が自分で挙げたこと以上の具体的な話が何も出てこないじゃないか。
それで魅力がないだの良く言えるなあ……。
463:デフォルトの名無しさん
11/04/01 21:55:03.78
無いものは挙げられない。
464:デフォルトの名無しさん
11/04/01 22:03:44.94
けなす方向にしたって何もでてきてないじゃないか。
465:デフォルトの名無しさん
11/04/01 22:08:39.90
言語のシンプルさは、それだけで一つの魅力なんだよ
Modula-2にはそれが欠けていた
466:デフォルトの名無しさん
11/04/01 22:10:28.68
だから具体的にはなんだよ？
文法だけで見ればModula-2のほうが今のC(++じゃなくてC)より遥かにシンプルだぞ
467:デフォルトの名無しさん
11/04/01 22:18:09.80
えーどこがシンプルなの？
ちょっと説明してみ？
468:デフォルトの名無しさん
11/04/01 22:34:56.57
Modula-2なんてPascalに分割コンパイルの機能を付加しただけじゃん
タイプ量も多いしCに比べると明らかに使いにくい
469:デフォルトの名無しさん
11/04/01 22:41:46.78
キーボードが苦手な奴はどの言語選んでも中途半端な事やって終わるだけ
470:デフォルトの名無しさん
11/04/01 22:42:52.41
結局俺に説明させてばっかじゃないか。
どこが複雑と思ってるんだよ？
まあ自分で調べる脳も無いんだろうから俺から書いてやると、
Modula-2は超典型的な構造化言語で、COBOLの書式化やらFortranの行列みたいな
変な機能がない分当時としても今から見てもシンプルな部類。
典型的な構造化言語という点ではCも同じだが、Cのほうには超複雑なマクロの展開規則と、
超複雑な宣言分の意味解析が付いて回る。意味解析の結果をパーサにフィードバックしないと構文解析できないのもコンパイラを複雑にする。
比べてModula-2は何も考えずパースできるLL(1)文法で、教科書通りにコンパイラが書ける。
型は当時のCとModula-2ならModula-2の方が多いが、せいぜい集合と部分範囲型まわりぐらいで
これも動的配列と複素数型が追加されてる今のCのほうが複雑だろ。
471:デフォルトの名無しさん
11/04/01 22:43:44.92
俺が俺がってウザいね
472:デフォルトの名無しさん
11/04/01 22:45:42.61
Modula厨がどんなに頑張っても、Modula-2には世の中に普及するほどの魅力がなかったのは事実なわけで。
473:デフォルトの名無しさん
11/04/01 22:46:42.09
超複雑なマクロの展開規則と超複雑な宣言分の意味解析
が、今や、普通に出来るみたいだけど
474:デフォルトの名無しさん
11/04/01 22:48:03.21
>>472
だからそれを書けって言ってるんだよ。
あと別に俺はModula-2をプッシュしてるわけじゃないぞ。話の流れ読めてるか？
過去にCに挑んで敗れた言語の何が駄目だったかもわからん奴に、Cの代わりなんて作れるはず無いだろうが。
475:デフォルトの名無しさん
11/04/01 22:49:32.54
>>473
一度自分でCのパーサ書いてみるといい。
教科書通りではなくて、実際にその辺に転がってるソースが通るやつ。
甘く見てると死ねるから、マジで。
476:デフォルトの名無しさん
11/04/01 22:51:06.18
一から作るのは、相当時間がかかるよ。
477:デフォルトの名無しさん
11/04/01 22:54:36.88
>>475
自分でやる気なんかないよ。
大変なのはわかってるし、そっち方面はやったことないし、
今やってるのは、自分なりにgccをいじるぐらいだよ。
478:デフォルトの名無しさん
11/04/01 23:07:42.02
今のCと当時のModula-2を比べて何の意味がある訳？
479:デフォルトの名無しさん
11/04/01 23:13:14.14
C でなくても、アセンブラを作ってみるだけでも
「そもそも、問題の本質は何か？」という疑問には自然に遭遇できる
480:デフォルトの名無しさん
11/04/01 23:17:47.49
問題の本質は何だったの？
481:デフォルトの名無しさん
11/04/01 23:20:44.75
>という疑問には自然に遭遇できる
だから、アセンブラを作ってみて、そういう疑問が浮かんだんだろうな。
答えが得られてるかは別にして。
482:デフォルトの名無しさん
11/04/01 23:25:20.65
手間かかる割に、ないものねだりする人が多いからでしょ
483:デフォルトの名無しさん
11/04/01 23:25:59.56
コンパイル可能なC++インタプリタ作ってくれよ。
PHPみたいにライブラリは豊富で。
484:デフォルトの名無しさん
11/04/01 23:28:58.91
>>460
>>483
これもよくわからんな。
C++インタプリタができた時点で既存のC++ライブラリが使えるから、
というかそれを使いたいからC++を指名してるんだろうに、2行目は何の意図があるんだ？
485:デフォルトの名無しさん
11/04/01 23:45:13.56
インタプリタは動的に型を変更できる。型宣言なしで動きかつ純粋C++ソースをはける。
PHPのソースをパクルなりして、PHPの関数も動かせるようにする。
486:デフォルトの名無しさん
11/04/01 23:54:40.09
おそらく、具体的なイメージが固まってないまま言ってるんだろうな……。
そもそもコンパイル可能なインタプリタって時点で？が付くし、
C++で書くのか出力としてC++ソースを吐くのか混乱してそうだし、
型を要求するC++の言語仕様にどうやって矛盾なく型無しを溶けこませるかも漠然としてそうだし。
まあ突き詰めていっても、最終的にC++/CLIができあがるだけの気がするが。
487:デフォルトの名無しさん
11/04/01 23:56:17.19
それがお前の想像力の限界。
488:デフォルトの名無しさん
11/04/02 00:02:45.59
具体的なことを何一つ書けないやつに言われたかないね
489:デフォルトの名無しさん
11/04/02 00:06:45.08
今のコンピュターで何が出来るかわかってない感じ
この程度のド素人が実務やったら怖いな
490:デフォルトの名無しさん
11/04/02 00:10:03.85
実務ｗ
491:デフォルトの名無しさん
11/04/02 00:18:19.76
>>489
ほほう、具体的には何ができるんだい？
492:デフォルトの名無しさん
11/04/02 00:29:40.94
しらんな、自分で考えろ
493:デフォルトの名無しさん
11/04/02 00:37:09.06
知らないことについて語るのは、このスレではともかく世間一般では普通に迷惑だぜ
494:デフォルトの名無しさん
11/04/02 00:38:04.51
常識とか持ち出されても
495:デフォルトの名無しさん
11/04/02 00:42:20.28
C++をスクリプト言語化しつつ、純粋なC++のソースもはけるやつ。
易しいC++から厳格なC++に変換可能。
496:デフォルトの名無しさん
11/04/02 00:43:56.52
楽したいと思うようなことは考えないほうが
497:デフォルトの名無しさん
11/04/02 00:49:15.06
C++のスクリプト言語化(C++ソースはける)のはかなり需要あるはず。
webプログラムも、アプリ開発、ゲーム開発もこれに統一できるだろう。
そして既存C++ソースは読み込めて流用できる。
標準でPHP並の装備付きで。
498:デフォルトの名無しさん
11/04/02 00:50:34.64
素人でもかける言語が欲しいのかいな？
499:デフォルトの名無しさん
11/04/02 00:53:14.77
Cのソースを吐くならValaがあるが、
C++のソースを吐くなんて需要あるのだろうか
500:デフォルトの名無しさん
11/04/02 00:55:54.46
C++に憧れを抱くPHPerってところか
501:デフォルトの名無しさん
11/04/02 01:01:59.53
>>497
良かったな、C++0xで、ローカル変数についてはほとんど型書かなくて良くなるし、
ranged-forみたいな構文糖も入るし、正規表現も入るぞ！
徹底的に型を排除したければboost::anyみたいなものもあるしな！
PHP並のWeb用のライブラリなら腐るほどその辺にあるし、ばっちしだな！
502:デフォルトの名無しさん
11/04/02 01:08:11.69
そんな馬鹿なことやってるんだ
503:デフォルトの名無しさん
11/04/02 01:26:15.44
労力の割には、報われんこと？をやってるんだ、かわいそう
504:デフォルトの名無しさん
11/04/06 22:05:48.31
俺、アセンブラは68000しか経験のない素人だけど。
元々PDP-11のアセンブラを高級言語風に表現したのがC言語なんでしょ？
なら,x64辺りのニーモニックをC風に表現したら、
取り敢えずWindowsプログラミングは多少楽になるんでね？