【超高速】C/C++に代わる低級言語を開発したい 7

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/
2デフォルトの名無しさん:2010/05/31(月) 01:00:37
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所
3デフォルトの名無しさん:2010/05/31(月) 01:01:24
◆新言語の要件 v0.1◆

(1)ハードウェアを直接操作する低レベルの記述が可能
(2)プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
(3)最新のオサレ機能が使えてワクワクしながらプログラミング可能


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい!
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性(絶対条件) > 構文の美しさ(読みやすさ、学習の容易さ) > 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
4デフォルトの名無しさん:2010/05/31(月) 01:02:50
◆新言語の名称(仮)◆

Programming Language I

◆新言語の位置づけ◆

Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。

◆新言語でのリソース管理方針◆

・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい

※GCは手段であって上記が満たされていれば必ずしも必須ではない。
5デフォルトの名無しさん:2010/05/31(月) 01:04:49
>>1
> しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
> 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

概念的には全く同じものになるだろう。
6デフォルトの名無しさん:2010/05/31(月) 01:05:10
>>4
なんでLLが(ハッカーの手により)生まれ、Cみたいなのが生まれないのか
少し考えれば分かるだろ
7デフォルトの名無しさん:2010/05/31(月) 01:16:05
◆新言語を考える上でのキーワード◆
クロージャー
カリー化
型推定
構文を操作できるマクロ
ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント

◆マクロについて◆
「マクロ」に必要な要件って何なんだろう。

・構文を置き換えるルールを定義できる
・シンボルを置き換えるルールを定義できる

Lisp級の構文木を操作可能なマクロを作る要件

・マッチングプログラムが簡単に書ける
・マクロの実行時に構文木を返すプログラムを書ける

また、作るのを容易にするには
・単純な式として構文解析が可能
8デフォルトの名無しさん:2010/05/31(月) 01:20:46
◆低水準に関連するキーワード◆

・ハードウェアを直接操作
・デバドラ
・直接アドレス参照
・OS
・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。
・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。
・0オーバーヘッド
9デフォルトの名無しさん:2010/05/31(月) 05:08:33
>>6
Cを作った人こそ
当時のハッカーというよりWizardだろ
有象無象が越えれる壁じゃないよね

LispがCより速い結果だしたそうな
どうみてもCのがわかりやすい
http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf

所でこのスレforkしたんじゃねえの
また関数言語とgcがわくぜ
10デフォルトの名無しさん:2010/05/31(月) 08:14:00
forkと連呼してる奴w
11デフォルトの名無しさん:2010/05/31(月) 08:56:48
新言語の方は、GC付きオブジェクト指向でいくっぽいし。
低水準な方は、高級マクロアセンブラっぽいし。

>>1
12デフォルトの名無しさん:2010/05/31(月) 14:47:34
俺よくわかってないんだけど
超高速ってC以上に高速なバイナリ吐くってこと?
機械語に落とす時に最適化される部分をプログラマが
指定できるみたいな要件が
ってとこで>>4読んだ

リソース管理でどっちでもいいよって言うのは
結局プログラマがリソース?の状態を気にしてプログラムしないといけないから
後始末必要の方が好み
13デフォルトの名無しさん:2010/05/31(月) 17:38:35
Cと同じ位の低レベルな時点で
RAMリソースなんて0で動かなきゃ
14デフォルトの名無しさん:2010/05/31(月) 17:46:03
0ってスタックも無しかよw
15デフォルトの名無しさん:2010/05/31(月) 17:52:27
RISC系のCPUで変数少なかったら
葉っぱの関数ではスタックもいらないのを見越して書く
メモリとかバスユニットの初期化コードとか。
16デフォルトの名無しさん:2010/05/31(月) 17:54:16
正直マジでレジスタとROMしか使えないんなら素直にアセンブラ使ったほうが
良くないか
17デフォルトの名無しさん:2010/05/31(月) 17:55:32
仮に使ってもゴミ読むだけなら
問題ない場合もあるしな
18デフォルトの名無しさん:2010/05/31(月) 17:59:21
>>16
見た目は普通に書けるよ
呼び出し側はアセンブラかもしれんけど
19デフォルトの名無しさん:2010/05/31(月) 18:07:10
アセンブラでよくてもポータビリティのためにCに書き直すことは意味ある。
20デフォルトの名無しさん:2010/05/31(月) 18:13:22
俺は後で自分や他人が読むためかなw
数ヶ月たつと忘れちまうし、若い奴に見せてもアセンブラだと敬遠しやがるし
21デフォルトの名無しさん:2010/05/31(月) 21:30:09
>>12
そもそもこのスレのテンプレは
>>1が重要だろうと思ってるレスを 過去ログから拾って来て、
適当に羅列してるだけだから、何一つ決まってないよ。
22デフォルトの名無しさん:2010/05/31(月) 21:44:46
決めたい人が決めればいいよ
23デフォルトの名無しさん:2010/05/31(月) 22:59:29
他人が決めてくれるのを待つ必要なんて無いんだよ
24デフォルトの名無しさん:2010/05/31(月) 23:54:12
ははぁ勝手にやればいいよってことですね

思いつきで書き込んだんですが、今思えば
コンパイラがやってることをCのレベルに持ってくるのは難しいというか無駄?
上に乗っけるのと違って現状の処理が変わるわけですし優秀なコンパイラあるし。
でもアセンブラいじりましたって状況がなくなるなら面白そうなのかな?

とりあえずC?にもってきたらどんな記法になるかを書いてみたいけど
当方素人なのでGCCが吐いたアセンブラを変更しないといけないシチュエーションが思いつきませんw







25デフォルトの名無しさん:2010/05/31(月) 23:57:45
あ?
26デフォルトの名無しさん:2010/06/01(火) 00:12:20
テンプレートメタプログラミングは必須だな
27デフォルトの名無しさん:2010/06/01(火) 04:52:38
手続き型アセンブラ
オブジェクトアセンブラ
関数型アセンブラ
LLアセンブラ
28デフォルトの名無しさん:2010/06/01(火) 15:22:05
アセンブラアセンブラ
29デフォルトの名無しさん:2010/06/01(火) 16:33:48
アスペクト指向アセンブラでダックタイピング
30デフォルトの名無しさん:2010/06/01(火) 19:51:56
どこかに小型のCコンパイラのソースって無い?
ベル研のPCCはテーブル定義が足りない。
TCCはちょいとでかい。
31デフォルトの名無しさん:2010/06/01(火) 22:35:29
なぜC
32デフォルトの名無しさん:2010/06/01(火) 23:51:13
Cにネタを積んで遊んでみようかと。
33デフォルトの名無しさん:2010/06/01(火) 23:53:11
>>31
僕の理由はCの実績。すでにあるプログラムに
手を加えるだけで恩恵が得られるって夢のようだとは思いませんか?
まあCに埋め込むものがどんなものになるかはまだ想像つかないです。
コンパイラ?を拡張するならまったく違う語法?でもいいのかもしれないし
改修してしまうならCがちょっと形を変えたものになるのかもしれない。

ベースになるのはCだろうなとは思ってますが
C++やC++0x、Java、Lisp?、といった言語だけでなく
Struts2やらシンフォニーといったフレームワークだったりとか
も参考にできるところがあるんじゃないかなあと
C++0xについてはいいものを見つけられた気がします。

とりあえず僕は他の言語をつまみ食いしながら
C99をよく見直して吟味するとこからなのでマイルストーンも何も置けない状況

今日は他の事してたので進捗はナシ。
34デフォルトの名無しさん:2010/06/02(水) 00:30:34
schemeから始めればいいのに。
35デフォルトの名無しさん:2010/06/02(水) 00:45:09
プロファイラ作ってみなよ
36デフォルトの名無しさん:2010/06/02(水) 03:26:11
プロファイラもデバッガも仕組みさえわかれば
下の方は簡単だが問題は見せ方だよな
XcodeのInstrumentsとか面白い
37デフォルトの名無しさん:2010/06/02(水) 21:24:24
プロファイラを言語機能に入れてよ
38デフォルトの名無しさん:2010/06/02(水) 22:26:49
え?もしかして僕ですか?
言語機能には入れないけど作ることにはなるんじゃないですかねー
新言語にしか興味ないので見せ方は他の方がどこかの誰かに丸投げ

僕のがモノになるのはずーっと先だろうなあ。
39デフォルトの名無しさん:2010/06/02(水) 23:08:41
アセンブラ言語から先は同じでいいんだからプロファイラ自体は先に作れるのかな?
アセンブラだから評価はステップベースでいいしあとはリソースの扱いを考えて・・・
静的なメソッドごとのステップと消費リソースを吐き出せばおkだったり



40デフォルトの名無しさん:2010/06/02(水) 23:32:36
アセンブラ言語って呼び方やめてくれ。ムズ痒くなる
41デフォルトの名無しさん:2010/06/02(水) 23:42:53
アセンブラングエッジ
42デフォルトの名無しさん:2010/06/02(水) 23:46:01
アセンブラ言語なんていってごめんねアセンブラ言語なんてもう言わないよ
あーあーアセンブリ言語をアセンブルするアセンブラ。
43デフォルトの名無しさん:2010/06/02(水) 23:50:28
ラ行3段活用?
44デフォルトの名無しさん:2010/06/02(水) 23:52:13
国語の話はやめてくれ。ムズ痒くなる
45デフォルトの名無しさん:2010/06/03(木) 07:20:54
国語の能力とプログラミング能力の相間について
46デフォルトの名無しさん:2010/06/03(木) 09:37:35
国語というより作文能力とは相関がある
47デフォルトの名無しさん:2010/06/03(木) 21:03:20
どうせアセンブラやらないといけないし
プロファイラ先に作ってみる
48デフォルトの名無しさん:2010/06/03(木) 22:40:29
○静的な機能として

・ラムダ式
・名前空間
・テンプレート
・型推論
・マクロ

○動的な機能として

・文字列
・リスト、キュー、スタック、ハッシュテーブル
・正規表現
・並列処理
・多倍長演算
・ベクトル演算
49デフォルトの名無しさん:2010/06/03(木) 23:27:50
文字列とリスト以外いらん
50デフォルトの名無しさん:2010/06/04(金) 02:48:10
これからの時代、ベクトル計算は要るだろ。
51デフォルトの名無しさん:2010/06/05(土) 00:21:49
メニーコアプロセッサが普及するだろうから、並列処理とベクトル計算は必須。
52デフォルトの名無しさん:2010/06/05(土) 02:04:23
結局理想を追求したらGoになったでござるの巻
53デフォルトの名無しさん:2010/06/05(土) 09:21:19
低級言語にベクトル計算とか要らないよ
インラインアセンブラでやってくれ
54デフォルトの名無しさん:2010/06/05(土) 09:34:05
ベクトル計算機のベクトル計算のことだろ。
そういう計算機では機械語がベクトル計算なんだが。
55デフォルトの名無しさん:2010/06/05(土) 09:49:56
ベクトル演算専用言語を作るのは面白いけど
それが目的じゃないならインラインアセンブラでやればいいんじゃないの
56デフォルトの名無しさん:2010/06/05(土) 12:53:14
ベクトル演算は言語標準でまではいらないが
標準クラスライブラリに含まれて然るべきだろう。
その方が演算器にCPUだけでなくGPUも使えていい。
57デフォルトの名無しさん:2010/06/05(土) 15:38:56
ここはあれか、Core2DuoとかCellとかが最低ラインなのか。
58デフォルトの名無しさん:2010/06/05(土) 15:43:43
最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?
59デフォルトの名無しさん:2010/06/05(土) 16:03:11
C/C++って低級言語じゃないんじゃ?
60デフォルトの名無しさん:2010/06/05(土) 16:55:03
配列はベクトルでは無い
ベクトルは行列、そして積和演算
61デフォルトの名無しさん:2010/06/05(土) 16:57:13
>>58
> 最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?

ガイドラインを示すくらいなら、言語仕様に組み込んだほうがいいだろう。

特殊な小手先のハンドオプティマイズより、言語仕様に基づく公式なやり方の方がソースのポータビリティーも確保できる。
62デフォルトの名無しさん:2010/06/05(土) 19:34:13
>>581
つfortran
63デフォルトの名無しさん:2010/06/05(土) 20:23:27
Fortran と正しく書かないと
64デフォルトの名無しさん:2010/06/05(土) 21:03:25
えらいロングパスだな
65デフォルトの名無しさん:2010/06/05(土) 21:47:59
581に期待
66デフォルトの名無しさん:2010/06/05(土) 22:37:03
並列処理の構文欲しい
67デフォルトの名無しさん:2010/06/06(日) 03:10:37
ベクトル演算ってどんな感じで作るんですか?
68デフォルトの名無しさん:2010/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デフォルトの名無しさん:2010/06/06(日) 09:53:07
配列とベクトルは論理的に違うもの。
記述性を考えればdouble2,int4,float3とかのベクトル型は
組み込みで持っていたほうがいい。
70デフォルトの名無しさん:2010/06/06(日) 10:09:47
>>69
>配列とベクトルは論理的に違うもの。

これはどういう事?
71デフォルトの名無しさん:2010/06/06(日) 10:24:49
3次元が特殊なのは分かるけど
その他は特殊な事ってあったっけ
72デフォルトの名無しさん:2010/06/06(日) 10:40:41
>>70
「行列演算」でググれ
73デフォルトの名無しさん:2010/06/06(日) 10:48:50
>>72
ググったってたくさん出てくるから>>69が何を言いたいのかよく分からないよ。
具体的に説明して欲しい。
74デフォルトの名無しさん:2010/06/06(日) 10:56:09
>>69
配列で十分だろう。ベクトルの足し算だってループでまとめて記述できるしコンパイラが自動的にベクトル化してくれる。
75デフォルトの名無しさん:2010/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デフォルトの名無しさん:2010/06/06(日) 11:02:49
行列演算なんて普通lapack/blasだろ
77デフォルトの名無しさん:2010/06/06(日) 12:16:40
>>76
そういう機能をうまく構文に取り込めるといいね。
78デフォルトの名無しさん:2010/06/06(日) 12:24:56
志村!スレタイ、スレタイ
79デフォルトの名無しさん:2010/06/06(日) 12:24:57
だからFortranを勉強しろと
FORTRANじゃないぞ? Fortranだ
80デフォルトの名無しさん:2010/06/06(日) 12:26:51
Fortranに変わる新言語を作りtai!!のスレになりました。
81デフォルトの名無しさん:2010/06/06(日) 18:12:11
AVXとかLNIとかに対応できる構文があればいいよね。

>>79
「Fortranを」と言うより、「Fortranのどの機能が良いから新言語に取り入れよう」と提案した方が議論が進むと思うよ。
82デフォルトの名無しさん:2010/06/06(日) 18:31:37
みんなロングパス受け取ってくれたみたいだな
83デフォルトの名無しさん:2010/06/06(日) 18:32:52
>>81
この流れでは並列演算に決まってるでしょ
84デフォルトの名無しさん:2010/06/06(日) 18:37:50
>>83
それが決まってるのは結構なことだけど、それがどう良いのかの説明があればもっと議論が深まるのにね。
85デフォルトの名無しさん:2010/06/06(日) 18:41:03
素直にFortran知りませんと言えばいいのに
86デフォルトの名無しさん:2010/06/06(日) 18:46:29
別に知らないことは無理に表明しなくてもいいんだよ。
それぞれが知っていること、成し遂げたいことを語ったほうが前向きだからね。

だから、Fortranの並列演算に価値を見出している人がいるなら、その人がどう良いのかを説明して仲間を増やせばいいと思うよ。
87デフォルトの名無しさん:2010/06/06(日) 18:50:32
Fortranの並列演算なんてライブラリで出来んじゃねえの
どうせならOccamとかの方が面白いだろ
88デフォルトの名無しさん:2010/06/06(日) 18:50:49
行列に関しては、clapakでだめなの?

並列演算(SSE2/VelocityEngineほか)を直接制御したいというのは別だろうか。
89デフォルトの名無しさん:2010/06/06(日) 18:52:21
>>87-88

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
90デフォルトの名無しさん:2010/06/06(日) 18:57:38
マルチコアのプロセッサが今後主流になるだろうから、並列処理の構文はあったほうがいいだろう。

整数の四則演算だってライブラリで提供することは可能だが、多くのプログラミング言語にはしっかり構文があるわけだし。
91デフォルトの名無しさん:2010/06/06(日) 19:02:44
脊髄反射すんなよ
高速演算ライブラリの必要性や配列の演算出来るって話は否定しないが
言語の話するなら並列実行構文の方が面白くねえかっつってんの
92デフォルトの名無しさん:2010/06/06(日) 19:04:17
あ、89に書いたのよ
お前みたいな凡人が寄り集まってんだから既存の言語を参考にすんのは当然だろうがよ
93デフォルトの名無しさん:2010/06/06(日) 19:04:41
並列実行構文の方が面白いと思う。
94デフォルトの名無しさん:2010/06/06(日) 19:07:01
並列に実行して!という構文より
並列化コンパイラが作りやすい構文にした方が
95デフォルトの名無しさん:2010/06/06(日) 19:07:50
並列実行構文 と 並列演算構文 を両方議論を進めよう。
96デフォルトの名無しさん:2010/06/06(日) 19:08:54
>>94
自動で並列化してくれるのはもちろん嬉しいけど、プログラマがある程度制御できるようにもしておきたいかも。低レベルを目指しているので。
97デフォルトの名無しさん:2010/06/06(日) 19:18:13
並列に実行して!
ってだけじゃなく、出来れば並列に実行して!みたいなのが面白そう
98デフォルトの名無しさん:2010/06/06(日) 19:28:00
並列化を考えるなら、OpenMPのforの分担みたいにデータを並列化するんじゃなく、
普通のマルチスレッドアプリみたいな処理を分担するものを自動生成できるといいなあ
思いつかないけど

並列度は、明に指定も出来るし、デフォルトはシステムのプロセッサ数とかから
自動的にチューニングできるといいね。

あと、同期とかスレッド間通信もある程度は検討したい。
goのchannelはシンプルながら面白いよね
99デフォルトの名無しさん:2010/06/06(日) 19:33:22
channel面白いね
でもやはり同期と排他と共有メモリは欲しくなるね
100デフォルトの名無しさん:2010/06/06(日) 19:35:06
channel欲しいかも。
101デフォルトの名無しさん:2010/06/06(日) 19:37:50
粒度が荒い並列はスレッド的な何かでいいが
細かいのは
102デフォルトの名無しさん:2010/06/06(日) 19:47:28
ワッフルワッフル
103デフォルトの名無しさん:2010/06/07(月) 08:12:59
並列化ってのは、そう難しいものじゃないんだけど、
並列時でもACIDを保証する事とパフォーマンスをスケール
させる事が難しくて、この難しさは、ようは、リエントラント性の
確保と、キャッシュ分散に関わってくる所なので、その辺をどう考えてるの

したいとか言う気分述べられても困るんだよね。

OSが無い状況で、言語が資源を持つ事の意味をどう位置付けるのか
その辺を考えないと議論にならない。
104デフォルトの名無しさん:2010/06/07(月) 09:11:33
どうせ低レベルじゃそんなの保証できないししてちゃ性能でないだろ
最低バリアーopとかcasみたいなのでクリティカルなとこだけ保護できれば後はなんとかなるんじゃね

粒度の高いのはコンパイラマターでいけるし
低いのはRTOSのカーネル程度のショぼいディスパッチャとスケジューラをランタイムに入れとく。
分散はライブラリ。
105デフォルトの名無しさん:2010/06/07(月) 09:14:45
単なるディスパッチャとかmutexとかメッセージ含めて数kb程度でおさまるだろ
OS上で動かす時はそいつをpthreadとか使うように置き換えで
106デフォルトの名無しさん:2010/06/07(月) 09:34:08
>>104-105
そのモデル違いがいかに混乱を巻き起こすのかってのは、
Linuxの事例で明らかなんだけどね。

君らその辺の難しさも理解しないで暮れ暮れ言い過ぎ。

107デフォルトの名無しさん:2010/06/07(月) 09:57:46
一応OS屋のはしくれだが
どこらへんが明らかか後学のために教えて欲しいね
108デフォルトの名無しさん:2010/06/07(月) 10:10:15
>>107
ふぇ?最近のOS屋はそんなレベルなんだ・・・
109デフォルトの名無しさん:2010/06/07(月) 11:04:46
>>108 結局具体的には説明できないわけだ。
110デフォルトの名無しさん:2010/06/07(月) 11:08:12
>>109
OS屋なのに>>107を質問する奴(詐欺師)
とは付き合えないよ。
111デフォルトの名無しさん:2010/06/07(月) 11:11:49
具体的な説明は一切できずに人格攻撃か。
112デフォルトの名無しさん:2010/06/07(月) 11:25:29
職業倫理の問題なので、人格攻撃と捉えられても困るし。
詐欺師を叩く事が、人格攻撃というのなら、そうなんだろうが、
俺は詐欺師の存在が、社会へ対する害悪だし、詐欺師へ攻撃する
事の方が正しいと思う。

君が詐欺師好きなのは分かったけども、そんな人間だと公言されても
困るだけだし。
113デフォルトの名無しさん:2010/06/07(月) 12:02:39
ただの質問をしただけの他人を詐欺師と決めつけて攻撃するほうが、
社会へ対する害悪だし、そういう馬鹿に対して馬鹿と言う事の方が正しいと思う。

君が馬鹿なのは分かったけども、馬鹿が馬鹿を晒すのは勝手にすればいいし。
114デフォルトの名無しさん:2010/06/07(月) 12:08:29
全角に期待した俺がアホだったかな
学校でうだうだしてないで社会に出なさいよ
115デフォルトの名無しさん:2010/06/07(月) 12:12:35
あ、113にじゃないよ
116デフォルトの名無しさん:2010/06/07(月) 12:36:38
>>113
OS屋さんが、ただ質問したいと言って質問する内容じゃないよ。
OS屋さんであんな質問するのは詐欺師。
117デフォルトの名無しさん:2010/06/07(月) 12:44:48
ランタイムライブラリにリアルタイムOSカーネルを乗っけるのか。
さっぱり分からん。OS-9辺りから学べばいいか?
118デフォルトの名無しさん:2010/06/07(月) 13:29:25
RTOSのカーネルなんてしれてるよ
言語に並列組み込むなら
環境によってOS上ならスレッド、
無しなら小さいディスパッチャと
基本的なmutexとメッセージはいるやろって話
うーむ。詐欺師かねえ
119デフォルトの名無しさん:2010/06/07(月) 13:31:50
で、具体的に Linux の事例、ってどういうこと?
120デフォルトの名無しさん:2010/06/07(月) 15:28:57
>>119
ライブラリスレッディングが、スピンロックするんだけど、
それがLinuxのLWPと競合して、スピンロックのエスカレーションを
発生させて、システムを致命的な状況に落としかねないって話と、
スケールアウトしないって問題を引き起こしていて、GNUPOSIXに
問題があるので、ユーザーランドスピンロックを解消しにくいとか、
じゃあOS側でLWPのスケジューリングをどうしようかってのが、
ここ2年議論されつづけている。

LWPそれ単独、ユーザーランドスレッディングそれ単独では成り立つ
話でも混ぜると大騒ぎって話で、色々とね、難しいのよ。
排他制御のタイミングも違ってくるし。リソースの待ち方も違ってくるし。

121デフォルトの名無しさん:2010/06/07(月) 16:16:17
で、それをOS屋であれば周知のはずだと思い込むのが犬厨か
122デフォルトの名無しさん:2010/06/07(月) 16:28:39
>>121
Linuxに限った話じゃないからね。
123デフォルトの名無しさん:2010/06/07(月) 19:58:07
僕じゃ理解できないかもしれないけど>>120の議論について読んでみたいので
進行形のスレッドか議論の流れがまとまってるサイトが知りたいんですけど
そういうのってどこ見ればいいんですか?
124デフォルトの名無しさん:2010/06/07(月) 21:04:39

もったいぶった割につまらんオチだったな
125デフォルトの名無しさん:2010/06/08(火) 09:25:02
なかなか、有意義な話じゃないすか
126デフォルトの名無しさん:2010/06/08(火) 11:15:18
bsdとかSolarisとかでも相当昔に揉んだ話
どっちにしろ言語の並列機能やるならOSの上に乗っかるから関係ない
俺はまたthread以外の有用な並列化のモデルが出てくるかと思った
127デフォルトの名無しさん:2010/06/08(火) 12:30:01
クライアントサーバモデルに代わる言語を開発したい
128デフォルトの名無しさん:2010/06/08(火) 15:19:05
晩ご飯のおかずに代わる言語を開発したい
129デフォルトの名無しさん:2010/06/08(火) 16:37:48
>>126
また脊髄反射かよ(w

前にリンク張ったからもう張らないけども、
なんでその俺は分かってるんだって文体で
頓珍漢書くかなぁ・・・

議論の流れを追えば、OSがあるからって
発言はありえないだろ。
諦めてOSに任せるべき、という発言になるべきだろ。
130デフォルトの名無しさん:2010/06/08(火) 16:49:43
OSに任せると性能が出ないから、ってんでたとえば Erlang なんかは言語が並列化を
まる抱えしてるし、どこをどう読めば「諦めてOSに任せるべき、という発言になるべき」
なんだかわけわからんわ。
131デフォルトの名無しさん:2010/06/08(火) 17:04:51
>>130
あぁ、君がスレッドモデルを小学生レベルで理解してない事を
理解し損ねて俺が頓珍漢な発言をしてた。ごめん。
Erlang なんかは、この時点で君がキチガイだと了解したわ。

スレッドモデルを勉強しなおせWikiにまとまってるのでOK
132デフォルトの名無しさん:2010/06/08(火) 17:07:41
どんだけアイちゃんスレだよ
133デフォルトの名無しさん:2010/06/08(火) 17:24:18
アイちゃん隔離スレだろ、ここはw
134デフォルトの名無しさん:2010/06/08(火) 18:55:37
アイちゃんって何匹も居るの?
135デフォルトの名無しさん:2010/06/08(火) 19:01:58
しむらすれたい
136デフォルトの名無しさん:2010/06/08(火) 20:41:48
まずはシングルスレッドの動きを規定すべきだろ。
マルチスレッドはシングルスレッドの動きに直交する形で設計すりゃ良い。
だからForthを(ry
137デフォルトの名無しさん:2010/06/08(火) 23:19:46
>>136
シングルスレッドの議論も、マルチスレッドの議論も並行に進めていいよ。

シングルスレッドの動きを規定する案があるなら提案してくれると、議論が進むと思うよ。
138デフォルトの名無しさん:2010/06/09(水) 00:22:36
OSがいない状況、言語がリソース管理、GC?
低級言語にしては大きくなっちゃう、
スレッドをCPU数やリソースに応じたチューニング、アイちゃん
139デフォルトの名無しさん:2010/06/09(水) 02:25:49
>>131
お前ほど自分で人に書いてる罵詈が自分に当てはまる奴も珍しいなw

Erlang出したのは俺じゃないが、今更カビの生えたスレッド実装の問題出した上に結局スレッド使えとかレベルが低すぎる。最近の論文とか読んでないから期待したじゃねえか

もういいからちょっと齧った程度の狭い知見で恥さらすな。お前程度の話ならみんなわかってるよw
14019:2010/06/09(水) 10:43:45
スレッドの実装って通常はC言語で実装されているのですか?
それともアセンブラで実装されているのですか?
インラインアセンブラですか?
141デフォルトの名無しさん:2010/06/09(水) 12:28:29
両方だよ
つ−か分家へ帰れ
14219:2010/06/09(水) 13:15:53
>>140
あまり気になるようなら19はフィルタしてください。
C言語とアセンブラで書くということですね。ありがとうございます。
143デフォルトの名無しさん:2010/06/09(水) 19:16:47
そんなてきとーな回答しなくていいのに
いまや分家の方が本家っぽい
144デフォルトの名無しさん:2010/06/09(水) 19:55:34
新言語でも、新言語とインラインアセンブラを組み合わせて開発ができるといいな。
145デフォルトの名無しさん:2010/06/09(水) 23:54:25
Cにネームスペースが入れば満足
146デフォルトの名無しさん:2010/06/10(木) 09:47:08
ネームスペースは要らない
147デフォルトの名無しさん:2010/06/10(木) 09:58:09
クラスだけでいい。
148デフォルトの名無しさん:2010/06/10(木) 10:13:22
クラスはもっといらない
149デフォルトの名無しさん:2010/06/10(木) 10:14:13
ソフトウェア開発しないならクラスもデザインパターンもいらないわな
150デフォルトの名無しさん:2010/06/10(木) 10:29:09
要る要らないじゃわからんから、理由も付けれ。
151デフォルトの名無しさん:2010/06/10(木) 19:58:23
ネームスペースは必要だよ。

名前に接頭辞を付けると名前が長くなって可読性が低いけど、
ネームスペースならコード中で省略できるから可読性が高い。
152デフォルトの名無しさん:2010/06/10(木) 22:12:37
確かに複数ファイルにまたがるスコープなら、あっても良いような気がする。
153デフォルトの名無しさん:2010/06/10(木) 22:33:43
クラスは要らない。

というかあっても良いと思うんだけど、マルチパラダイムな言語では、
ぐちゃぐちゃなヒドい実装になりがちだからダメ。

OOPLにするならするで、現状C言語を使わざるをえないような
チープな環境はターゲットとしては捨てるべきだよ。
154デフォルトの名無しさん:2010/06/10(木) 22:35:54
糞環境だけにピンポイントかよwCOBOL並みの糞言語じゃん
155デフォルトの名無しさん:2010/06/10(木) 22:52:28
COBOLは、糞ではない。
幾多の消え去った言語を尻目に、いまだにたくさん使われている。
156デフォルトの名無しさん:2010/06/10(木) 22:53:45
一時期デファクトスタンダードみたいになったからだろ。今から積極的に学ぼうなんて奴はいない
157デフォルトの名無しさん:2010/06/10(木) 23:00:39
OOPって本当はピンポイントだけど、C言語風のOOPは汎用っぽく見えるよな
158デフォルトの名無しさん:2010/06/11(金) 01:31:44
クラスはともかくとしても、デストラクタは欲しいから、結局クラスがあったほうがいいんだろうな。
159デフォルトの名無しさん:2010/06/11(金) 01:58:09
GCに代わるデストラクタをピンポイントしたい
160デフォルトの名無しさん:2010/06/11(金) 09:56:13
今ってコボラーが一番平均年収高いんだぜ?
つまり最高の言語って事じゃん
161デフォルトの名無しさん:2010/06/11(金) 11:19:55
レガシーシステムの管理者が貴重なだけだろ
162デフォルトの名無しさん:2010/06/11(金) 11:33:31
だから、そんだけ払える(価値がある)ってことだろ
社会的に「最高に価値のある言語/技術者」と評価されているわけ
わかった?
163デフォルトの名無しさん:2010/06/11(金) 11:35:25
じゃあなんで大学で必修にしないのかな
なんで「学習する価値がある言語」と評価されてないのかな
164デフォルトの名無しさん:2010/06/11(金) 11:37:10
COBOLが糞か糞でないか、終わってるか終わってないかの議論では
糞だし終わってるというのが一般的な見解だろ
165デフォルトの名無しさん:2010/06/11(金) 11:43:29
>>163
うんまぁそういう事は大学行ってから言おうね
大学で教えるのは、学習に適した言語だよ
166デフォルトの名無しさん:2010/06/11(金) 11:44:44
COBOLは糞だし終わってるが、お前らより遥かに社会的に価値がある。以上。
167デフォルトの名無しさん:2010/06/11(金) 11:46:37
COBOLを有難がってる奴の社会的価値は終わってる。社会的に抹殺した方が良い
168デフォルトの名無しさん:2010/06/11(金) 11:55:48
次スレは 【超年収】COBOLに代わる金融言語を開発したい で
169デフォルトの名無しさん:2010/06/11(金) 12:01:04
都会は下水道完備だが田舎ではまだまだボットン便所が多数派だ。
ボットン便所は確かに糞だが汲み取り業者はお前らより遙かに社会的に価値がある。以上。
170デフォルトの名無しさん:2010/06/11(金) 12:06:55
バキュームカー臭い議論すんな
171デフォルトの名無しさん:2010/06/11(金) 15:14:47
おまいらの給料だってCOBOLがハンドリングしてるんだろ
172デフォルトの名無しさん:2010/06/11(金) 16:47:58
COBOL以後にそれ並みになったのは、C、BASICぐらい。
173デフォルトの名無しさん:2010/06/11(金) 17:21:52
まあ、なんだぁ
おれには「それ並み」って言葉の意味がわからないけどな
日本語なのか?
174デフォルトの名無しさん:2010/06/11(金) 19:58:28
金融系でCOBOLから
他の言語に移行なんてベンダー主導でやらないと無理じゃん
175デフォルトの名無しさん:2010/06/11(金) 20:04:43
ベンダーってなんですか?
社内で科学技術計算する立場なんですがIT業界の用語が良く分からないんですよね
176デフォルトの名無しさん:2010/06/11(金) 20:09:15
すまんが、マ板でやってくれ。
177デフォルトの名無しさん:2010/06/11(金) 20:24:10
>>175
ぐぐってきたぞ。製品を販売する会社なんだって。
汎用機だとIBM,富士通,、NECか金融系の開発受託してるのは違う会社か

>>176
語るならCOBOLは言語的にどう優れているのかって点かなあ


178デフォルトの名無しさん:2010/06/11(金) 20:41:58
>>177
他の言語で金の計算なんてやってらんねえよw
179デフォルトの名無しさん:2010/06/11(金) 20:55:40
勘定系は伝統的にcobol、pl/iだったけど
市場系は開発スピードが評価されて20年くらい前からc/c++だけどね
180デフォルトの名無しさん:2010/06/11(金) 21:22:43
二進化十進表現はのいいものかも。贅沢
181デフォルトの名無しさん:2010/06/11(金) 21:29:46
>>177
余計なことができない言語は特定分野で重宝するのは事実。
182デフォルトの名無しさん:2010/06/11(金) 21:32:05
ウメハラのような言語か
183デフォルトの名無しさん:2010/06/11(金) 21:32:40
一山なんぼのバカでも使えるからな
184デフォルトの名無しさん:2010/06/11(金) 22:31:48
ほんとのバカにはCOBOLで書くプログラムはまかせないけどね。
185デフォルトの名無しさん:2010/06/11(金) 23:01:05
バカにプログラムは任せないし、COBOLでプログラムも書かない。
186デフォルトの名無しさん:2010/06/11(金) 23:17:28
ガキのケンカw退屈。

クラスについてだけどマルチパラダイムな状況を許容することで
自由な実装ができてるのだと思うけどどうなんですかね
可読性と天秤にかけられるものなんでしょうか。
ガッチリ決めちゃえば実装は楽になるとは思うけど。
あとクラスがあるからスレッドの実装なんかも楽になってるのでは?


187デフォルトの名無しさん:2010/06/11(金) 23:35:53
クラス考えるならインターフェイスどうするか考えないと。

まあ、簡単にはメソッドオンリーだろうけど。
チャネルとかストリームとかトランザクションなんかも魅力的だけど重たいしね。
188デフォルトの名無しさん:2010/06/11(金) 23:52:13
>>187
よくわからない。違う話してる?
189デフォルトの名無しさん:2010/06/11(金) 23:58:52
>>187が最近知ったことの話をしてる
190デフォルトの名無しさん:2010/06/12(土) 09:23:55
あくまで低級言語なんで、
マルチパラダイム万歳で、リッチな言語は違う気がする。
191デフォルトの名無しさん:2010/06/12(土) 14:12:13
新言語の記述レベルは低レベルであっても、記述力はリッチにしたい。

特にビルド時に処理できる構文は積極的に取り入れていい。
192デフォルトの名無しさん:2010/06/12(土) 15:03:36
低級言語って、Cは低級言語ではないのだが
(Cは高級言語です)
低級言語を開発するという意味が
よく、わからない。

最初にスレタイを考えたやつは
アホではないでしょうか?
193デフォルトの名無しさん:2010/06/12(土) 15:05:07
今更何言ってんだ?空気嫁よ
194デフォルトの名無しさん:2010/06/12(土) 15:08:54
そう思うあなたは分割されたスレ行けばいいと思うの
195デフォルトの名無しさん:2010/06/12(土) 15:13:41
>>192
高級アセンブラといいたいんですね。解ります
196デフォルトの名無しさん:2010/06/12(土) 15:24:55
>>192
> 低級言語を開発するという意味が
> よく、わからない。

先ずは、このあたりをどうぞ。

>>1 >>3-4 >>7-8
197デフォルトの名無しさん:2010/06/12(土) 16:54:18
昔はCは高級言語であるとされてきたが、近年はそうとはかぎらない。高い低いはあくまで、比較してどうかだから。
198デフォルトの名無しさん:2010/06/13(日) 09:26:26
>>197
> 昔はCは高級言語であるとされてきたが

いつ頃の話してるのか知らんが、昔から PL/I だの Ada だのの豪華な
言語はあったから、コンパイラ言語としては C は常に末席付近だった
と思うぞ。
199デフォルトの名無しさん:2010/06/13(日) 09:42:29
>>198
初期の lisp に比べても十分低レベル
つか, 非常に良くできた高級アセンブラだわな
# それがいいんだけど…
200デフォルトの名無しさん:2010/06/13(日) 10:59:38
PDP-11 の頃と今の違いといえば並列
それと翻訳環境の怪物化

パイプラインやベクトル演算も簡潔かつ辛辣に抽象化した
移植可能アセンブラができれば C の二番煎じにはなるだろう

# 実はそれっぽいのがもうあったりするが文法的な面白さがいまいち

あと operator くらいあれば浮動小数点あたりは強制から任意に緩和できる
もっと言えば基本型は bool と配列だけでいい

ワード幅 8bit はそろそろぶっ壊してもいいと思う
201デフォルトの名無しさん:2010/06/13(日) 14:21:29
192じゃないが、>>196で見直して気付いた。

「C言語、C言語」言ってるから騙されたけど、
欲しいのはCの代替じゃなくて「綺麗なC++」なのか。

C言語が選択される理由のうち、
記述が機械語に近しいって所はいらんのだな。
コンパイラが作りやすいとか、
コード見てアセンブリが想像出来るとか。
202デフォルトの名無しさん:2010/06/13(日) 14:57:21
>>201
その二つを両立させたいんだろ
Cの代替であり、尚且つC++並みの高機能にしたい
前者を捨てて後者に特化した言語はごまんとあるから、もうこれ以上いらない
203デフォルトの名無しさん:2010/06/13(日) 14:58:32
なら、まずC++の何が不満かを洗い出さないと
204デフォルトの名無しさん:2010/06/13(日) 15:11:25
>>203
C++があるのにCの人気が衰えないことが不満なんだよ
205デフォルトの名無しさん:2010/06/13(日) 15:14:50
C++への不満が絶えないことが不満
206デフォルトの名無しさん:2010/06/13(日) 15:35:25
進化、成長しないことが不満
抽象的なモデルより、具体的なソフトを作る人間の方が勝ってると思われることが不満
207デフォルトの名無しさん:2010/06/13(日) 16:15:41
C++0xは進化でも成長でもないと
208デフォルトの名無しさん:2010/06/13(日) 16:30:39
0xの勉強するより、Cだけでソフト作った方が有意義だろ常識的に
209デフォルトの名無しさん:2010/06/13(日) 16:34:01
常識を覆す言語を開発したい
210デフォルトの名無しさん:2010/06/13(日) 19:58:03
そのためにはまず常識を理解しないと
211デフォルトの名無しさん:2010/06/13(日) 20:18:55
岡目八目ってこともあるが
212デフォルトの名無しさん:2010/06/13(日) 22:09:53
ストラウさんの
「c++の設計と進化」あたりを読むのがいいんじゃないですかね。
いろいろ c と simula の不満を述べてますがな。
213デフォルトの名無しさん:2010/06/13(日) 22:33:49
>>202
そうかぁ。
知識不足ですまんけど、動的メモリ確保無しで書けて、物理メモリアクセスや
チップのクロックに依存するようなタイミング制御が出来るような
高機能な言語ってC++ぐらいしか知らんので、
そういう方向もアリかな、と思ったんだ。
214デフォルトの名無しさん:2010/06/14(月) 19:10:45
Cはシンプルさを目指した言語だし
C++は複雑化する一途だし別物なだけ
215デフォルトの名無しさん:2010/06/14(月) 20:00:19
>>214
そのとおりだとおもう。
でもC++はどんなに複雑でも零オーバーヘッドの原則ですべてが許される。
216デフォルトの名無しさん:2010/06/14(月) 20:23:44
C++ の不満。ぱっと思い付いたのだけ。

* C との構文的互換性。文脈自由文法でない → リファクタリング支援系のツールの貧困さ
* モジュールが無い
* 巨大な std 名前空間
* 例外を投げない保証を明示できない → 例外安全なコンテナを作るのが難しい
* 資源管理の責任の明示が困難 ( move である程度改善? )
* 型安全な可変個引数が無い
* 可変長テンプレート引数が無い
217デフォルトの名無しさん:2010/06/14(月) 21:10:30
C++は、0オーバーヘッドじゃないだろ。
218デフォルトの名無しさん:2010/06/14(月) 21:30:06
オーバーヘッドの必然性がない所は
0オーバーヘッドにするように作られている
219デフォルトの名無しさん:2010/06/14(月) 21:37:53
0.01ぐらいで許せ
220デフォルトの名無しさん:2010/06/16(水) 15:18:44
C++は共用体を安全に使うのが難しそう
Cは安全とか考えないから楽

共用体の配列のかわりにポインタの配列を使うとか
ポインタ配列に何か代入するたびにnewするとか
Java臭いコードになりそう
221デフォルトの名無しさん:2010/06/16(水) 16:39:49
共用体は型フィールドのチェックのオーバーヘッドがある
けど分岐予測が当たりやすい気がする

仮想関数はパイプライン的にどうなるのかよくわからん
222デフォルトの名無しさん:2010/06/16(水) 19:56:51
型安全な共用体なら boost::variant があるから OK

> 共用体は型フィールドのチェックのオーバーヘッドがある
の意味が良く分からないんだけど。
これは C++ 側の話じゃなくてユーザコードでってこと?
223デフォルトの名無しさん:2010/06/16(水) 20:42:01
> 仮想関数はパイプライン的にどうなるのかよくわからん

分岐予測泣かせ
224デフォルトの名無しさん:2010/06/16(水) 20:45:24
分岐予測ってそんなに重要なの?
いや、ループでは重要なんだろうけど、
switchのような類いのものはあまり役に立たないんじゃないかと
225デフォルトの名無しさん:2010/06/16(水) 20:50:25
switchを繰り返すループがよく出てくるんだが
226デフォルトの名無しさん:2010/06/16(水) 21:10:47
switchでは失敗しまくって、
ループでは成功しまくってんじゃないの
227デフォルトの名無しさん:2010/06/16(水) 22:27:38
>>222
そう。型フィールドの値をassertとかswitchするユーザコード。
switchはdefaultとか特定のケースに偏ってないと役に立たないと思う。
assertの類のチェックは、失敗することは滅多にないから役に立つ。
228デフォルトの名無しさん:2010/06/17(木) 13:42:51
分岐予測が当たるかどうかで50%ぐらい性能低下する場合もあるよ
229デフォルトの名無しさん:2010/06/17(木) 13:51:55
レンホー「なぜ低級言語なんですか。Cじゃだめなんですか」
230デフォルトの名無しさん:2010/06/17(木) 13:56:18
リストの各要素の仮想関数を呼び出す場合
交互に別の呼び出し先だったりすると
分岐予測機能一般化後の主流各CPUだとパターン検出すら出来ずに全て予測失敗する
パイプラインが長いCPUだと即死短くても瀕死になる
231デフォルトの名無しさん:2010/06/17(木) 18:19:09
>>230
わかりそうで分からない。

多分、個々の用語が一般的ではないオレ用語・用法だからだろう。
232デフォルトの名無しさん:2010/06/17(木) 18:56:52
>>229
一意じゃないとだめなんです
233デフォルトの名無しさん:2010/06/17(木) 19:16:54
>>230
それはCでどちらを実行するか分岐しても同じなんじゃないの、と
234デフォルトの名無しさん:2010/06/18(金) 08:27:23
>>230は一番たちの悪い部類の馬鹿
235デフォルトの名無しさん:2010/06/18(金) 11:36:29
マルチコアもパイプライン無い時からCは存在してたのかな?
236デフォルトの名無しさん:2010/06/18(金) 11:39:43
卵が先か玉子が先か
237デフォルトの名無しさん:2010/06/18(金) 16:03:22
今のCPUはC的言語に最適化されとる
238デフォルトの名無しさん:2010/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デフォルトの名無しさん:2010/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デフォルトの名無しさん:2010/06/18(金) 16:43:08
上、%2なん?
randのコストは?
241デフォルトの名無しさん:2010/06/18(金) 16:48:16
>>234
何一つ間違った事は書いていないが
242デフォルトの名無しさん:2010/06/18(金) 17:06:09
>>240
てか、そもそもこれ予測分岐のコスト評価になってるか?
243デフォルトの名無しさん:2010/06/18(金) 18:13:54
>>242
分岐予測が外れる以外に10倍近く差が開く理由はないだろ
244デフォルトの名無しさん:2010/06/18(金) 18:19:41
>>240
そんなに気になるなら

func[std::rand(), i % 2]();

とでもしろ
ほとんど結果に影響しないから
245デフォルトの名無しさん:2010/06/18(金) 21:18:33
コード見るとレベルが知れるな
246デフォルトの名無しさん:2010/06/18(金) 21:21:12
同じ計算コスト、コードで分岐頻度だけ異なる場合でないと意味ない
247デフォルトの名無しさん:2010/06/18(金) 21:25:16
そもそも分岐予測で間接ジャンプ?
248デフォルトの名無しさん:2010/06/18(金) 22:10:23
>>245
まだ提示する方がお前さんのような上から目線よりはいいと思うZE
249デフォルトの名無しさん:2010/06/19(土) 10:48:24
細かく突っ込みたいが…釣りだよな
250デフォルトの名無しさん:2010/06/19(土) 12:15:36

  ------------------------------------------------------------
    こ  こ  ま  で  成  果  物  一  切  無  し
  ------------------------------------------------------------
251デフォルトの名無しさん:2010/06/19(土) 12:51:44
俺が成果だ
252デフォルトの名無しさん:2010/06/19(土) 13:41:38
成果なんか永遠に出ねえよ
253デフォルトの名無しさん:2010/06/19(土) 13:46:25
このまま2chにスレを立て続けてたところで何も出てきやしねぇよ。 >>1
254デフォルトの名無しさん:2010/06/19(土) 13:50:46
何か出るのを期待してる>>250>>253が馬鹿なだけ
さっさと2chブラウザを閉じろw
25519:2010/06/19(土) 23:42:33
いちお、このスレ見てやる気が出てきて、色々作ってますよ。

template<T>T add(T a, T b) { return a + b; }
というものをうまいこと型推論などで型付きで
add(a,b){return a+b;}みたいに書けるといいなと思うのですが、
どうでしょう?
256デフォルトの名無しさん:2010/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デフォルトの名無しさん:2010/06/20(日) 00:15:34
型推論はPTしづらい、と思ってんだがどうだろう?
低水準な開発は実機来るまでプログラムが動かないんで
関数レベルの単体テストが結構重要だと思う。

むー・・・既に時代遅れな考え方な気もするんだけどね。
258デフォルトの名無しさん:2010/06/20(日) 00:18:23
関数テンプレートを作る意図がなければ
型を省略しなけりゃいいだけじゃない
25919:2010/06/20(日) 03:19:44
>>256
そんな感じがいいと思います。
省略可能な文法でパースも楽なのがいいなと。

型推論なしでもtemplateの型用トークンを用意するというのはどうでしょう?

def add(a:'T, b:'T):'T = a + b

こんなかんじで、'Tから始まる変数はテンプレート型とするので
template<T>って書かなくてもいいとか。
260デフォルトの名無しさん:2010/06/20(日) 08:13:20
型理論やばいなあ
落とし所が見つからないと廃人になる
261デフォルトの名無しさん:2010/06/22(火) 22:47:01
プログラミング言語 を作ってみたよ
http://d.hatena.ne.jp/yuroyoro/20100621/1277104092
262デフォルトの名無しさん:2010/06/22(火) 23:28:51
Brainf*ck系はもういいよ!
263デフォルトの名無しさん:2010/06/23(水) 23:53:36
で?成果品ないの?
264デフォルトの名無しさん:2010/06/24(木) 21:43:21
265デフォルトの名無しさん:2010/06/24(木) 21:46:43
勉強したはずの>>238に期待
266デフォルトの名無しさん:2010/06/25(金) 23:19:24
シビレを切らした>>1が、とにかく成果物出せとわめくスレになりました
267デフォルトの名無しさん:2010/06/26(土) 00:57:05
1日1スレ消費する勢いだったあの頃
268デフォルトの名無しさん:2010/06/26(土) 22:49:15
いまみたいに規制されてなかったからな
269デフォルトの名無しさん:2010/07/16(金) 21:01:51
tesutesu
270デフォルトの名無しさん:2010/07/17(土) 01:32:04
一気に過疎化したな
271デフォルトの名無しさん:2010/07/17(土) 03:20:16
全部他力本願だもん
そりゃ過疎化するわ
誰かが自分で処理系作って発表しないかぎり机上の空論でしかない
272デフォルトの名無しさん:2010/07/17(土) 03:44:46
お前もそうじゃんw
273デフォルトの名無しさん:2010/07/17(土) 08:21:55
言語なんて空想しているときが一番楽しい
274デフォルトの名無しさん:2010/07/27(火) 17:33:39
>>271
自力で作れる人がアイデアを精査したく、議論を投げても
ループマンや、LISP厨、一行コメンター等が酷すぎて議論にならないって
はっきりしてしまうんだと思うのですよ。

少し高度な話題振ってる人間も、単にC++0xの議論を持ち込んでる
だけですし。C++0xがの流れを否定してるこのスレなのに、そのスレ主旨
の違いが分からず、C++0xで議論(本当に酷い人はC++0xのスレのコピペ)
されてることを書き込めば、レスが付く、スレに参加してるとでも勘違い
してるかのように。

どうも2chは勢いのスレに参加してると何かメリットあるとか勘違い
してる、無能な屑がかなり存在してるみたいで、それがこの結果>>270
なんだと思うんですよね。
275デフォルトの名無しさん:2010/07/27(火) 17:56:25
便所の落書きに何を期待しているんだ?
276デフォルトの名無しさん:2010/07/27(火) 22:35:24
>>274
いや、べつにC++0xの議論を持ち込んでもいいんだよ。

ただ、現状のC++0xは従来のC/C++とのある程度の互換性というシバリを引きずっているから、記述が非効率で、美しくなく、学習しにくいといった問題がある。
だから、従来のプログラミング言語にとらわれず、新しい言語がほしい。
ところが、今出てくる新しい言語といえば、LLばかリで、CやC++がカバーしている分野につかえるような言語はなかなか無い。

そこで、「C/C++に代わる低級言語を開発したい」というこのスレッドが立ち上がった。

過去のしがらみで不必要な制約がなければ、結果的に従来のプログラミング言語に似ていても問題ないよ。
277デフォルトの名無しさん:2010/07/28(水) 00:47:22
じゃあGCを入れるべきか議論しようか
278デフォルトの名無しさん:2010/07/28(水) 00:49:39
入れるべき。以上
279デフォルトの名無しさん:2010/07/28(水) 19:08:09
GC の是非はしがらみじゃない
280デフォルトの名無しさん:2010/07/28(水) 20:28:15
言語設計の観点からは、無いのはかなり困る
むしろGCとうまく付き合う方法を考えてくれ

エスケープ解析や明示的な寿命指定で
GCへの負荷をある程度下げることはできるだろうし
もともとスループットだけで言えば、GCは下手な手動管理より高効率

しかし、やはり最悪停止時間が保証できない問題は残る
部分的にGCを停止させるぐらいで妥協できないかなあと考えてるが、
う〜ん……
281デフォルトの名無しさん:2010/07/28(水) 20:43:56
スレタイ目指すならGCなんてありえんだろ。
別スレでやれw
282デフォルトの名無しさん:2010/07/28(水) 21:23:09
>>281
無しで考えてもいいが、
それだとC/C++と大差なくなるんじゃないかなあ
283デフォルトの名無しさん:2010/07/28(水) 23:04:58
>>280
GCって使うのめんどくさいんだな
284デフォルトの名無しさん:2010/07/28(水) 23:43:31
そういやGCな言語って最大使用RAMとか見積もれるのか?
これが無理だと、かなり組み込みで使えるトコが限られるんだけど。
実はまだメモリ解放されてません、とかだと凄く困る。
285デフォルトの名無しさん:2010/07/29(木) 00:22:38
>>284 GC ってのは資源が有り余ってるときに使える手法
GC が発生する頻度とその時に回収出来るメモリー量と回収に必要な時間が
許容範囲内なら使える
つか, 「malloc 実装したとしてメモリー足りなくなったときにブロックするの禁止」
な, 世界ではほぼ使えない
286デフォルトの名無しさん:2010/07/29(木) 03:39:49
引数に渡すものを構造体限定にすれば速くなるんじゃない?

他には、
スタック関連の呼び出しや初期化を極力抑えて、
メモリの割り当てもメモリープール的な考え方で割り当てて、
メモリ解放の概念を取っ払って、
安全性のチェックを全部やらない。

要するに、ハードウェアは弄るけど、全責任を開発者に投げる的な。
最悪、OSごと落ちるかもしれないけど、高速化するんだったらこうなるでしょ。
後は、Pen4以前をサポートしないようにしたり、
SIMDの命令をもうちょっと使いやすいようにしたり。
287デフォルトの名無しさん:2010/07/29(木) 05:18:03
そんなシロモノは
C/C++に代わる低級言語
にはならないと思うなボクは
288デフォルトの名無しさん:2010/07/29(木) 06:58:43
たしかにメモリ開放のタイミングを制御できないGC言語はC/C++の代用にはならんわな
289デフォルトの名無しさん:2010/07/29(木) 12:40:58
GC言語がメモリ解放のタイミングを制御できない?????
290デフォルトの名無しさん:2010/07/29(木) 18:22:29
> 後は、Pen4以前をサポートしないようにしたり、

んなクソでかい CPU を強制される言語はやだな

>>289
仮に制御できたとして、だから何だい?
288 はタイミングとしか言ってないから開始時期のみの話にも聞こえるが
仮にベストなタイミングで開始できても何秒かかってもいいってことではあるまい
291デフォルトの名無しさん:2010/07/29(木) 20:59:48
C/C++って組み込みでしかシビアな組み込みでしか使われてないと思ってるの?
292デフォルトの名無しさん:2010/07/29(木) 21:01:26
日本語が変になった。つまりアンチGCは頭の固いただの老害ってことだよ
293デフォルトの名無しさん:2010/07/29(木) 21:17:13
いわゆる「富豪的」な環境でもかまわんよ
ナノ秒がミリ秒に遅延する仮想記憶でさえ要注意な場面はあるわけで
ナノ秒が秒まで遅延する仕組みが天使の取り分でいつも済むとは限らない

おまえさんの言う老害は年齢ではなくシステムプログラミングに対する知見の違いで
もしかしてブーメランかもね
294デフォルトの名無しさん:2010/07/29(木) 21:19:34
何言ってんだコイツw
なんでGC言語ではGCを必ず使わなければいけないって決まってるわけ?www
295デフォルトの名無しさん:2010/07/29(木) 21:25:38
で、free という GC を選択的に使えばいいわけだw
296デフォルトの名無しさん:2010/07/29(木) 21:31:33
マジで言ってるのなら頭が悪すぎて話にならない
297デフォルトの名無しさん:2010/07/29(木) 21:45:32
おまえに褒められても気持ち悪いだけさ
298デフォルトの名無しさん:2010/07/29(木) 21:59:48
お前もGCされたら?
299デフォルトの名無しさん:2010/07/29(木) 22:08:24
>>294
てか今時GCが使える状況でC/C++を選択する理由が思いつかんのだけど
どういう状況でどういう利点があるの?
300デフォルトの名無しさん:2010/07/29(木) 22:18:06
実際に使われてるんだから仕方ないだろ
301デフォルトの名無しさん:2010/07/29(木) 23:12:26
しょぼ・・・
C++しか使えない奴らが作ってたり、過去資産があるだけのトコに
互換性のない言語突っ込んで何がしたいの?
302デフォルトの名無しさん:2010/07/29(木) 23:13:49
日本語でおk
303デフォルトの名無しさん:2010/07/30(金) 02:01:15
私にとって、本当のオブジェクトのセマンティクスに関する素晴らしいことの1つは、
本当のオブジェクトが「端から端まで本当のコンピュータ (RCATWD)」であることです。
これによって、何でも表せる完全な能力をいつでも保持できます。古いやり方は、
すぐにコンピュータではない2つのこと、データとプロシージャに行き着き、
不意にふるまいに合わせて最適化と特定の決定を任せる能力を失っていました。
言い換えれば、常に本当のオブジェクトを持つことにより、ほしいものを再現し、
惑星の周りに送る能力を保持します。そして、RCATWDはまた、両方向を完璧に保護します。
これはインターネットのハードウェアモデルの中に見られます。(使えるもので、
唯一の本当のオブジェクト指向システムかもしれません) 無料で言語拡張機能を手に入れるには、
メッセージ形式に従うだけです。私が70年代に考えたのは、パーソナルコンピューティングと
同時に取り組んでいるインターネットは、本当に素晴らしいスケーラブルな設計であり、
ハードウェアでキャッシュできる仮想マシンの仮想インターネットを作るべきだというものでした。
これが実現されなかったのは本当に残念です。
304デフォルトの名無しさん:2010/07/30(金) 02:02:05
私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。
Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと考えました。
そして、私の論文の指導教官が言いました。
「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」
 彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。
これを信じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いました。
オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、
オブジェクト間で分離し、ポリモーフィズムを持つものです。
305デフォルトの名無しさん:2010/07/30(金) 05:17:44
お年寄りの話は面白くないです
306デフォルトの名無しさん:2010/07/30(金) 05:30:58
元々緩やかな下降線にはあったけど、人が減った事によって
それまでは人混みに隠れていた工作員の存在が目立つようになったのが致命傷だったな
工作員の誘導を嫌って参加者が減り、他所からの工作員を排除しようとして規制をするから
参加機会が奪われて更に参加者が減るという負のスパイラルにおちいってる
307デフォルトの名無しさん:2010/07/30(金) 05:47:45
このスレまだあったのか
308デフォルトの名無しさん:2010/07/30(金) 07:40:46
こんなゴミスレでもスレタイにC++が入ってるだけでパート7まで行くとはな
309デフォルトの名無しさん:2010/07/30(金) 07:58:26
仲間に入れずクラスの後ろでブツブツ言ってるヤツ >>307-308
310デフォルトの名無しさん:2010/07/30(金) 15:41:13
GCを実装していても低級言語と呼べるのか。勉強になる。
だったらGCを実装したアセンブラとかならスレタイを満たすんじゃないのかな。
311デフォルトの名無しさん:2010/07/30(金) 16:24:31
もしかしたらハードウェアレベルでGCの機能を提供できるようになるかもよ
312デフォルトの名無しさん:2010/07/30(金) 16:25:56
アホが1人キレやがったw
313デフォルトの名無しさん:2010/07/30(金) 18:47:38
>>290
>んなクソでかい CPU を強制される言語はやだな
なぜですか?

>>299
リアルタイム系だと止まるのでGCは使いません。
ゲーム(XNA)だと勝手にGCを発動されるとフレーム描画が止まるので、
ロード中に全て開放して全て読み出しています。
ゲーム中はデータの読み込みやnewを一切行いません。止まるので。
メモリの中にあるものが全てです。
314デフォルトの名無しさん:2010/07/30(金) 18:54:56
C/C++ は元々システムプログラミング用言語で how な部分に深く立ち入ることにミッションがある
what に特化したアプリ用言語と相容れないのは論を待たない

オブジェクトが動的か否かも how の領域であり、問題そのものが本質的に持つ要求ではなく
アプリの土方がここに無気になることには上も下も見えていない滑稽さが漂う
315デフォルトの名無しさん:2010/07/30(金) 19:53:59
>>314
>what に特化したアプリ用言語と相容れないのは論を待たない

そうやって思考停止して満足してるわけだ。
316デフォルトの名無しさん:2010/07/30(金) 20:03:53
昔はそういう止まると困るものは割り込みで処理するようにして、
本体では重い処理をやるようにしてたものだが。
317デフォルトの名無しさん:2010/07/30(金) 23:18:26
>>313
「開放」と「解放」の区別もつかない人に語る資格はないと思うが。
318デフォルトの名無しさん:2010/07/30(金) 23:26:48
人民開放軍ではなく
人民解放軍なんですね
319デフォルトの名無しさん:2010/07/30(金) 23:40:12
>>317
介抱してやれ
320デフォルトの名無しさん:2010/07/31(土) 02:14:48
言語にRTOSを組み込めば解決だな
gcもスレッド毎にon/off
gcより高レベルなタスクは止まらないとか
321デフォルトの名無しさん:2010/07/31(土) 02:39:40
>>320
CPUごとに異なる言語を作るって意味ね。がんばれ。
322デフォルトの名無しさん:2010/07/31(土) 02:42:17
機械語やってろよもう
323デフォルトの名無しさん:2010/07/31(土) 09:10:57
>>320
残念ながら不可能
324デフォルトの名無しさん:2010/07/31(土) 09:54:04
> CPUごとに異なる言語を作るって意味ね。がんばれ。

意味がわからん。
言語がモニタとかの同期機構の面倒を見る、というのはAdaなんかであたりまえにやってるし、
AdaがCPUごとに異なるなんて話は聞いたことがない。
325デフォルトの名無しさん:2010/07/31(土) 09:59:30
なんで伸びてるのかと思えば、>>1が巻き添え規制から解除されてまた暴れてるのか。
326デフォルトの名無しさん:2010/07/31(土) 10:14:06
言語にRTOSを組めば→そのRTOSは何言語で組むの→その言語自身で… 
327デフォルトの名無しさん:2010/07/31(土) 10:18:37
>>313
GCで不意に止まっちゃ駄目な環境で最近作ってないんだけど、
昔ながらにプールしてGC極力走らせないとか毎フレ強制GCしたりの他に、
止まらないGCとかそういう手法みたいなのって開発されてないの?

コンシューマ機だと本体はC/C++ばっかりだと思うけど
最近はLuaとか当たり前に使われているよね?
そのへんどうしているのかな、と思って
328デフォルトの名無しさん:2010/07/31(土) 10:35:03
>>324
VESAのような統一規格があるモニタと、全くないCPUを同一と考えてるの?
CPUの型番で周辺機器も異なるし、物理メモリ空間の使い方も異なるし、
割り込み番号の振り方だって違うんだよ?
フリーのOSのソースコード読んだことある?
329デフォルトの名無しさん:2010/07/31(土) 10:54:45
モニタと言われて同期機構のことだとピンとこないような、RTOSのド素人は黙ってたほうが身のためですよ?
330デフォルトの名無しさん:2010/07/31(土) 11:06:45
OSとか組み込みマイコンとかの”チープな環境”の領域まで、
C(/C++)にとって変わらなくていいだろ。

言語にOS乗っけるとか、H/WでGCしろとか、本末転倒な話ばっかりじゃんかよ。
331デフォルトの名無しさん:2010/07/31(土) 11:27:12
ガベコレにはOSやハードウェア支援があったほうがいいし(現状あまり研究とかないけど)、
言語機能とOSの機能が(たとえばスレッドとか)密であっても悪くないだろ。

どこが本末転倒?
332デフォルトの名無しさん:2010/07/31(土) 12:23:44
>>324
モニタって既存RTOSのサポートがあってこそ。
既存CPUすべてサポートしてるRTOSなんて聞いたことないが。
333デフォルトの名無しさん:2010/07/31(土) 13:04:47
そりゃPICからスパコンまで全部サポートしてるシステムなんてないだろ。

>>321 は、CPUが異なったら、同期機構が異なるものになる、と主張してるようにしか読めん。
確かにテストアンドセット系のプリミティブはCPUごとに異なるけど、もしかしてそれを
直接言語にしたら、っていう意味なのかな?

たいていのOSでは、OSで共通化した同期機構を提供していて、CPUのそういったプリミティブは
掩蔽されているものだが。
334デフォルトの名無しさん:2010/07/31(土) 20:40:17
「C/C++に代わる」というのスレタイの解釈が、GC有り派とGC無し派で違うから
話が全くかみ合わない。
335デフォルトの名無しさん:2010/07/31(土) 20:46:08
>>1 としては「超高速」の存在によってGC有りは排除されると考えてるんじゃないだろうか。
336デフォルトの名無しさん:2010/07/31(土) 22:21:41
GC前提のコーティングとGCレスのコーティングって全く違ってくると思う
337デフォルトの名無しさん:2010/07/31(土) 22:25:43
GC有り排除は考えなくていいよ。

言語仕様にはGCを含めて、実装できる環境なら実装すればいい。
はじめから無しとする必要はない。
338デフォルトの名無しさん:2010/07/31(土) 22:28:07
GCがあって高速な言語がいまだかつてあっただろうか?
339デフォルトの名無しさん:2010/07/31(土) 22:39:23
LISPってC並に速いんじゃなかった?
340デフォルトの名無しさん:2010/07/31(土) 22:41:49
瞬間最大じゃなく瞬間最小が問題になるんだが

# 保証という課題に対する思想が深刻にまずいのがいるな
341デフォルトの名無しさん:2010/07/31(土) 22:42:14
実測結果を提示せよ
342デフォルトの名無しさん:2010/07/31(土) 22:46:31
このスレで考えようとしてるのってどう考えてもC++以下のゴミ言語だよね
アセンブラの方がマシってレベルだよ。脳みそ空っぽなんだろうな
343デフォルトの名無しさん:2010/07/31(土) 22:51:34
GC有りでCより速いのはないよな?
つまりGC有りは議論の余地すらないんじゃないか?
ここらでばっさり不要なものは枝刈りしないか?
344デフォルトの名無しさん:2010/07/31(土) 22:53:07
>>339
その主張には前提があって、
Lispのほうが高水準で、マクロとかの道具立てがあるから
アルゴリズムとかの試行錯誤がやりやすい、
だからより良い結果にたどり着きやすい、という意味

http://blog.practical-scheme.net/shiro/20100620a-lisp-speed

十分に大量のリソースが与えられたのなら、Cのほうが速くなるはず
実際、Lisp処理系を機械語レベルで眺めると、
C処理系ほど高品質なコードは吐かないらしい

>両者の生成コードの間には、実行効率の点で今だに無視出来ない開きがあるのも事実である。
http://jp.franz.com/base/seminar/2009-11-20/Seminar-09-AbeCompiler-Eval.pdf
345デフォルトの名無しさん:2010/07/31(土) 22:55:08
LISPのマクロは星井
346デフォルトの名無しさん:2010/07/31(土) 22:58:24
アセンブラのマクロって意外と便利だよな
俺はああいうのでいいよ
347デフォルトの名無しさん:2010/07/31(土) 23:02:25
>>343
ほんっっっっっとうに、頭悪いな
348デフォルトの名無しさん:2010/07/31(土) 23:02:57
>>343
GCは汎用のアルゴリズムだから、問題領域固有の条件を用いることができない
だから、理屈の上では、プログラマが慎重に手動管理すれば
速くなる可能性はある

……理論的にはね
349デフォルトの名無しさん:2010/07/31(土) 23:05:05
>>348
何その手動管理って。
GCレスより面倒な気がするが?
350デフォルトの名無しさん:2010/07/31(土) 23:15:21
汎用のアルゴリズムと言いつつ、
GC有り無しは完全に言語を2分する存在だよね。
このスレでも「GC有りは遅い」と思い込む人多数。
つまり性能がどうあれ需要がない。
そして需要はコード品質に直結する。
GC有りのJabaやどとねとは業界権力で生き残ってるけど、
使われてるから使うだけで、単なる1技術として見たら
本来は見向きもされない存在。
351デフォルトの名無しさん:2010/07/31(土) 23:19:31
シムラ、後ろ後ろ
352デフォルトの名無しさん:2010/07/31(土) 23:19:49
.NETからしか使えないようにするとか
DirectX10以上じゃないと動かないとか
すべて商売上の都合だな
あ、javaは影響力弱いから無くても困らないけどな
353デフォルトの名無しさん:2010/07/31(土) 23:21:37
GC無しの言語こそ需要ないけど
354デフォルトの名無しさん:2010/07/31(土) 23:23:44
GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
ってわかんないんだよね。これが気持ち悪いって人いると思う。
ライブラリで一応実装できるんだから言語機能に入れることないよ。
355デフォルトの名無しさん:2010/07/31(土) 23:26:09
最近の言語は、言語機能もライブラリで実装されているから、
ライブラリで一応実装できるんだから言語機能に入れることない、なんて必要はない。
356デフォルトの名無しさん:2010/07/31(土) 23:30:32
>>354
まあ失うものは結構あるけども、
それはそれで一つのアプローチだとは思う
357デフォルトの名無しさん:2010/07/31(土) 23:34:46
ところでPerl並に普及してるGCなしのスクリプトってある?
shとか?
358デフォルトの名無しさん:2010/08/01(日) 00:27:48
>>333
「掩蔽」じゃなくて「隠蔽」だな
>>354
「開放」じゃなくて「解放」だな
359デフォルトの名無しさん:2010/08/01(日) 01:32:04
とりあえず、GCありきの文法にならなきゃ、あろうがなかろうがどうでも良い話。
最後の最後に辻褄あわせるようにGC向けの構文入れりゃ満足だろ?
360デフォルトの名無しさん:2010/08/01(日) 01:34:38
構文上、プログラマーが意識しなくても適切にリソース管理が行われるなら、GCは無くてもいいよ。
GCは手段であって、目的ではない。
361デフォルトの名無しさん:2010/08/01(日) 02:44:46
>>327
GCのメリットデメリットは自動的に監視して解放することだから、
仮に自動監視を外したとしてC/C++でメモリをリスト使って管理するのと大差なくなるのでは?

Luaで止まるってことはなかなかないですよ。
どの道、利用しているのはC/C++の関数やクラスなので、
止まるとしたらC/C++側の問題のほうが多いです。
関数の実装に近いような使い方をするので生成とかは通常させません。
362デフォルトの名無しさん:2010/08/01(日) 02:47:44
int *hoge = (int*)GC::alloc(sizeof(int)*10);

これでいいんじゃないか?
363デフォルトの名無しさん:2010/08/01(日) 06:54:00
> GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
> ってわかんないんだよね。

資源を確保するところで起きる可能性がある。
はっきりわかってるじゃないか。
364デフォルトの名無しさん:2010/08/01(日) 06:56:34
「使わない」選択のない realloc か
365デフォルトの名無しさん:2010/08/01(日) 08:03:26
ほらな、みんなPCで動かすことしか考えてない。
366デフォルトの名無しさん:2010/08/01(日) 11:03:52
>>365
どうしてそう思っちゃったの?
367デフォルトの名無しさん:2010/08/01(日) 13:32:20
チープな環境ならGC使わなきゃ良いっつーけど、
ぶっちゃけ言うと、リソース管理を自力で出来ない奴が
その言語経験者としてアサインされることが一番困る。
368デフォルトの名無しさん:2010/08/01(日) 16:47:10
そこは事前に振り分けとけよ。
369デフォルトの名無しさん:2010/08/01(日) 21:17:43
その人事振り分けもやってくれるコンパイラを作ればおk
370デフォルトの名無しさん:2010/08/02(月) 02:04:38
>>327
ソフトリアルタイムシステムまでであれば
Erlangっていう実例があるので、決して不可能ではない

----
Erlangをベースとする初期のプロダクトが1993年に開発されていた頃、
(Javaのような)ゴミ集め処理を伴うVM用にコンパイルする言語を、
ソフトリアルタイムシステムに対して使うなどというのは狂気の沙汰だと批判されたものです
(Francesco Cesarini, Simon Thompson著 『Erlangプログラミング』より)
----
371デフォルトの名無しさん:2010/08/08(日) 02:17:49
このスレはまずwintel脳、言語どころかOSやシステムプログラムをロクに知らないヤツらを隔離すべきだな
372デフォルトの名無しさん:2010/09/25(土) 10:12:53
久しぶりに書き込める!!
構造化されたパターンマッチング機能だけなら、GCなしでも入れられるよね。
373デフォルトの名無しさん:2010/11/07(日) 03:36:30
まだこのスレあったのか。
一時期凄い勢いだったのにやっぱり言語仕様まとまらなかったのかね。
374デフォルトの名無しさん:2010/11/07(日) 05:33:14
7スレ使って1つも成果物なし?
http://studiokingyo.fc2web.com/
375デフォルトの名無しさん:2010/11/07(日) 07:22:10
よくある話だろ。

すでにまとまってる言語仕様にすらあーだこーだ言う連中がうようよ
してるんだから。
376デフォルトの名無しさん:2010/11/07(日) 13:07:19
なんども言っているが、ここは、何かをまとめるスレではなくて、考えるスレなので。
377デフォルトの名無しさん:2010/11/07(日) 13:53:20
何か「成果物」ができてきたら、それ専用のスレをたてるべきだな
378デフォルトの名無しさん:2010/11/07(日) 14:42:36
いいプログラミング言語に必要なのは
複雑なロジックを簡単に書ける事だと思うんだよね
読みやすくて、ロジックが短くなる言語って何があったろ?
379デフォルトの名無しさん:2010/11/07(日) 14:44:07
Python
380デフォルトの名無しさん:2010/11/07(日) 14:58:49
ブロック要素がインデント依存ってのは独特だが、確かに短いな
短いと言ってもブロック定義の関係で短いって感じだけど
381デフォルトの名無しさん:2010/11/07(日) 15:04:19
複雑なロジックを簡単なロジックに分割ってのは
ほとんどの言語が目指すところで特にどれってこともない

一見簡単そうな記述が書いた本人もびっくりのオーバーなことになっている言語ってどうなんだろ
BASIC とか
382デフォルトの名無しさん:2010/11/07(日) 15:36:35
「簡単」というのは表記が短いことも当然あるが、その表記の意味を容易に学習できることも重要。

そのためには、一貫性のある最小限の文法であることが望ましい。

表記を短くするためであっても、「ただし、こういう場合にはこうでなければならない」といった、場合による例外事項は避けるべきだ。
383デフォルトの名無しさん:2010/11/07(日) 20:16:01
>>376
考えるスレですらなかったろ
全員が好き放題妄想を垂れ流してただけ
384デフォルトの名無しさん:2010/11/07(日) 20:30:13
結局誰も考えをまとめようとしなかったから結局言いっぱなしのスレに・・・
385デフォルトの名無しさん:2010/11/07(日) 21:18:21
何か成果を出さなきゃならないとの強迫観念に駆られてるノイローゼ諸君はわざわざ参加しなくていいんだよ。

言語好きが集まって、理想の言語に付いていろいろ語り合って、知識を増やしり、楽しんだり出来ればそれで十分。

そこから派生して何か「成果」を出したいなら出せばいいが、それはこのスレに求めることじゃない。
386デフォルトの名無しさん:2010/11/07(日) 21:28:11
このスレにそんな俺様ルールがあったのか。
387デフォルトの名無しさん:2010/11/07(日) 23:32:09
ルールも何も、何か成果を出すなんてことはこのスレの目的にそもそも無い。
388デフォルトの名無しさん:2010/11/07(日) 23:51:06
言うことは言うけど、参加するって人が少ないなと。
そんな自分はプログラミング言語その物について勉強中だが、
趣味時間だけで言語の作り方把握するのってちょっと大変
389デフォルトの名無しさん:2010/11/08(月) 00:00:04
>>387
そうだったのね。
てっきりスレタイには開発したいとかテンプレ>>3-4みたら成果を求めてるんだと思った。
まぁ意見は言っても参加はしてないから関係ないけど。
390デフォルトの名無しさん:2010/11/08(月) 00:05:17
まあ、勘違いは誰にでもある。そんなに気にしなくてもいいよ。
391デフォルトの名無しさん:2010/11/08(月) 01:03:45
自治厨乙
392デフォルトの名無しさん:2010/11/08(月) 01:54:06
言語仕様まで考えて発言してる人を見たことがないがな。
理想理想と言いながら実現不可能な仕様上で議論しても仕方ないだろう。
実現可能な仕様を考えることも成果と呼ぶのかい?
393デフォルトの名無しさん:2010/11/08(月) 01:55:18
また自治厨が現れた
394デフォルトの名無しさん:2010/11/08(月) 01:57:14
仕方が無いと思うなら議論に参加しなければいい。誰も強制はしない。
395デフォルトの名無しさん:2010/11/12(金) 22:30:22
話を蒸し返すようだが、低級言語を目指すのであれば、GCは最適化の手段として位置づければよい。
文字列や木のノードのような純粋なデータを効率よく扱うためにGCを利用するオプションがあればそれでいい。
ストリームだのウィンドウだのをGCする必要はないし、本当は高級言語でもそうすべきではない。
その点ではよくあるOOPLよりC++の方が理念的に正しい。
396デフォルトの名無しさん:2010/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デフォルトの名無しさん:2011/01/04(火) 20:41:13
過去ログが大勢の目から隠されてしまう2ch掲示板でこういう理論って不毛じゃね?
398デフォルトの名無しさん:2011/01/29(土) 16:49:41
GCやVMいらないならセキュア、リアルタイム、マルチコア向けC派生言語(というかほとんどC++)として
Sappeur Compiler [ ttp://www.sappeur.eu/ ]とか既に段階で存在する。BSDライセンスね。

さらに一部の関数型言語ではCソースも吐けるわ、小型の組み込みSchemeインタプリタも
あるわけで。なんか今更Cの派生言語なんか必要かよと思うわけですが...。と釣ってみる。
399デフォルトの名無しさん:2011/01/29(土) 17:18:40
段階?
400デフォルトの名無しさん:2011/01/29(土) 17:58:59
ある言語(またはツール)が吐いた C ソースでは、
できることの範囲がそいつと C の積集合になるのは
わかってる?
401デフォルトの名無しさん:2011/01/29(土) 18:00:23
チューリング完全∩チューリング完全≡チューリング完全
402デフォルトの名無しさん:2011/01/29(土) 18:40:49
Sappeur面白そうだな。勉強してみよう。
403デフォルトの名無しさん:2011/01/29(土) 18:45:10
もしかして万能と混同してる?
404デフォルトの名無しさん:2011/01/29(土) 18:46:26
どういう意味?
405デフォルトの名無しさん:2011/01/29(土) 19:00:41
401 がチューリング完全と万能を混同しているように聞こえた
406デフォルトの名無しさん:2011/01/29(土) 19:09:49
聞こえちゃったならしょうがないな
407デフォルトの名無しさん:2011/01/29(土) 19:20:43
へーえ、違うのかい?
408デフォルトの名無しさん:2011/01/29(土) 19:24:09
まあ、チューリング完全でも、空飛べたり、子供産めたりはしないだろうから、完全とは違うだろうな。
409デフォルトの名無しさん:2011/01/29(土) 19:27:39
そんな空想論を持ち出さなくても
切実な問題がいくらでもあろうが
410デフォルトの名無しさん:2011/01/29(土) 19:28:44
例えば?
411デフォルトの名無しさん:2011/01/29(土) 19:31:06
疑似でない乱数が標準 C だけで作れるか?
412デフォルトの名無しさん:2011/01/29(土) 19:36:26
確かに切実な問題だな
413デフォルトの名無しさん:2011/01/29(土) 19:39:24
ごく単純化したモデルで示すが
int a(b, c, d, e) { return b * c + d * e; }
のような処理に CPU アフィニティをどう指定する?
時間的保証はどうする?
414デフォルトの名無しさん:2011/01/29(土) 19:49:23
俺の就職はどうする?
415デフォルトの名無しさん:2011/01/29(土) 19:50:20
プログラミング言語は神ではない。
416デフォルトの名無しさん:2011/01/29(土) 20:22:28
と、ここまで全部独り言
417デフォルトの名無しさん:2011/01/29(土) 20:28:09
遠吠え乙
418デフォルトの名無しさん:2011/01/30(日) 20:22:23
え?
419デフォルトの名無しさん:2011/01/31(月) 12:45:45
お?
420デフォルトの名無しさん:2011/02/02(水) 22:33:04
ジョブズみたく、C++を再定義します
って言えば、もっと盛り上がったかなぁ
421デフォルトの名無しさん:2011/02/03(木) 00:00:02
要は、CPUやメモリやハードウェアを何の制限もなくいじれて、
マシン語とちゃんぽんにできる言語ってことだろ。
昔の AppleII の BASIC みたいに。
422デフォルトの名無しさん:2011/02/03(木) 00:14:00
Cを完全に置き換え可能で、Cより新しいスタイルでの記述が可能なプログラミング言語
423デフォルトの名無しさん:2011/02/03(木) 04:04:08
D言語?
424デフォルトの名無しさん:2011/02/03(木) 05:58:29
>>421みたいな仕様になってもWindows上で動く限り制限されまくるよな
OSでも作るなら別だけど
425デフォルトの名無しさん:2011/02/03(木) 06:59:44
go go google
426デフォルトの名無しさん:2011/02/03(木) 12:20:34
>>424みたいなバカが居るからこのスレは駄目なんだ
427デフォルトの名無しさん:2011/02/03(木) 13:15:28
一行バカレスが
他のスレにも出没しているみたいなので
スルーよろ
428デフォルトの名無しさん:2011/02/03(木) 13:41:03
むりやり
改行してるだけで
ブーメラン
429デフォルトの名無しさん:2011/02/04(金) 23:55:21
RiteVMがこう言う方向性なのかと一瞬思ったけど、違った。
430デフォルトの名無しさん:2011/02/05(土) 07:59:20
CやC++は高級言語だから前提が間違ってるのに、7まで続けるとは何ぞや。
431デフォルトの名無しさん:2011/02/05(土) 12:56:26
>>430
>>1を1000回読んでから顔洗って出直してこい
432デフォルトの名無しさん:2011/02/05(土) 13:04:45
何度読もうが高級言語なのは事実だ
433デフォルトの名無しさん:2011/02/05(土) 13:11:48
CやC++が高級言語ではないとは言ってないだろ。
434デフォルトの名無しさん:2011/02/05(土) 14:13:28
あー、>>432 の定義する「高級言語」でいいよ別に
名前をどうしたいかじゃないから
435デフォルトの名無しさん:2011/02/06(日) 00:38:52
>>1
C++でいいんじゃねえの
C++ですら手が届かないところはインラインアセンブラでGO
436デフォルトの名無しさん:2011/02/06(日) 01:12:27
スレタイ嫁
437デフォルトの名無しさん:2011/02/08(火) 19:33:35
目指してる 未来が違うwwwwwwwww byシャープ
http://twitter.com/yuki_touzyu/status/34835830736424960  
438デフォルトの名無しさん:2011/02/16(水) 02:37:09
リアルタイム性を損なわず、かつコードがでかくならずに>>1の仕組みを実行できれば完璧なんだろうけどなぁ
439デフォルトの名無しさん:2011/03/12(土) 20:44:42.91
age
440デフォルトの名無しさん:2011/03/31(木) 22:15:34.68
1日1スレ消化してたあの頃
このスレが何かしてくれるんじゃないかと夢見たなぁ・・・
441デフォルトの名無しさん:2011/03/31(木) 22:39:45.30
C/C++の範囲をカバーするだけの言語なら既に山ほどあるからな。
C/C++だけでしかできないなんてものは最初から無い。それこそC言語の誕生当時から、C言語に存在価値なんて全くなかった。
単に物好きなUNIX屋が使ってて、CとBASIC以外の言語では他ベンダに押されてたMSがWindows APIに採用したというだけで
偶然広まった言語に過ぎない。

問題は「代わる」の部分で、これは要するに既にあるC系言語の資産を全て書き換えた上で、
C言語を使ってる連中を転向させなければならない。こっちのほうが遥かにムズイ。
ってかこれができるなら何十年も前に既にModula-2はCを置き換えてた。
442デフォルトの名無しさん:2011/03/31(木) 23:19:18.86
単にModula-2がその程度の言語だってことだろ。
443デフォルトの名無しさん:2011/03/31(木) 23:34:22.53
餌でか杉
444デフォルトの名無しさん:2011/03/31(木) 23:58:37.99
>>443>>442へのレスだよな?

実際Modula-2は、まともなモジュール化機能、ポインタ演算、豊富な型、structural typing、例外、オプショナルなGC、
コンパイラによってはgenericやオブジェクト指向の拡張があって、70年代後半としては超先進的な言語だぞ。
しかも開発者本人によるOSのリファレンス実装まであった。
予約語が大文字でキモイことを除けば、言語仕様だけの評価なら十人が十人Modula-2 > Cと言うだろう。

それでもC言語に代われなかった、そういうことだ。
445デフォルトの名無しさん:2011/04/01(金) 00:07:34.28
> 予約語が大文字でキモイことを除けば、

これが結構致命的だったのでは
446デフォルトの名無しさん:2011/04/01(金) 00:12:36.04
だから、Cに対するModula-2のアドバンテージがその程度だってことだ。
447デフォルトの名無しさん:2011/04/01(金) 00:13:32.17
キモさ勝負ならCの文法だって充分キモイし、当時はBASICやらALGOLやらCOBOLやら全部大文字で書く言語も珍しくなかったから
その辺割とどうでも良かったと思うんだけどなあ。
まあ今の感覚で見ると間違いなくキモイんだが。
448デフォルトの名無しさん:2011/04/01(金) 00:15:03.54
>>446
だったらどれぐらい差があればいいと思うんだ?
ぶっちゃけ当時の規格化もされてないCとModula-2の差は、
>>1が作ろうとしてる言語とC++0xの差よりでかかったと思うぞ。
449デフォルトの名無しさん:2011/04/01(金) 00:21:33.19
>>441
Cはアセンブラと混ぜて書くことも簡単にできるから、
「代わる」作業を分割払いできる。
一括がムズイなら分割すればいいだけ。
450デフォルトの名無しさん:2011/04/01(金) 00:22:34.25
>>448
思うのは自由だね。
451デフォルトの名無しさん:2011/04/01(金) 00:24:02.79
>>449
おまえはCを使い続ければいいよ。
452デフォルトの名無しさん:2011/04/01(金) 00:25:17.75
> だったらどれぐらい差があればいいと思うんだ?
頭の悪そうな質問しますね
453デフォルトの名無しさん:2011/04/01(金) 00:25:49.98
分割して「代わる」部分を書くためには、Cと代わる部分の2言語を知る必要があるから、
それなら代わる部分も含めて一つの言語で書ける新言語が欲しいというのが>>1の意図。
454デフォルトの名無しさん:2011/04/01(金) 00:29:58.95
共産主義者とかユートピア思想などと呼ばれるやつですね

455デフォルトの名無しさん:2011/04/01(金) 00:34:40.71
>>449
なんでCがアセンブラと混ぜて使えることが、代わる作業を分割払いできる理由になるんだ?
ぶっちゃけ呼び出し規約に互換性さえあれば、大抵のコンパイラで、Cのコードを
オブジェクトファイル単位で順次置き換えていくことは可能だぞ?

問題は、可能不可能ではなく、回りの人間に置き換え後verを使わせられるかどうかだ。
例えばzlibは多くの言語でリライトされてて中にはC版より高速と主張してるのもあるが、
実際使われてるのはオリジナルのC版なわけで。
456デフォルトの名無しさん:2011/04/01(金) 01:20:54.35
まあCが良い言語かどうかはともかく、Modula-2はねーよ。
予約語大文字は想像以上にキモイからね。
そういうシンプルな理由が人気を左右するんだよ。
Lispが天下取ってないことでも分かるだろうに。
457デフォルトの名無しさん:2011/04/01(金) 01:24:59.15
>>455
おそらく、高速バージョンよりも単純で小さいのを目指すほうが評価は高い。
458デフォルトの名無しさん:2011/04/01(金) 02:30:17.72
>>456
別に今からModula-2を推そうってわけじゃねーよ。単に過去にCに挑んで敗れた言語ってだけだ。
ただまあ、予約語大文字がキモイってのは、現在予約語が小文字の言語ばっかになって慣らされてしまってるからで、
当時はそんな珍しいものではなかったはずなんで、Lispと同列に語るのはねーよ。Lispは当時でもキモかったはずだw
比較演算子==と!=も、初めて見たときは相当にキモかったはずだろう?
459デフォルトの名無しさん:2011/04/01(金) 09:31:46.09
>>458
その当時の人も大文字ばかりの言語はウザイと思ってて、
だから大文字小文字の区別あり/予約語小文字のCが受け入れられた可能性もある。
当時を知らんけど。
460デフォルトの名無しさん:2011/04/01(金) 10:27:23.05
C/C++のスクリプト言語つくってくれ。
インタプリタだが、Cのソースもはけるやつ。
およそPHPみたいなやつ。ライブラリが豊富なやつ。
461デフォルトの名無しさん:2011/04/01(金) 20:43:06.35
Modula-2がキモかったというよりは、言語としてCを置き換える(というか普及する)ほどの魅力がなかったというだけ。

コンパイラやライブラリがショボかったのも問題。
462デフォルトの名無しさん:2011/04/01(金) 20:48:59.00
別にいいんだけど、俺が自分で挙げたこと以上の具体的な話が何も出てこないじゃないか。
それで魅力がないだの良く言えるなあ……。
463デフォルトの名無しさん:2011/04/01(金) 21:55:03.78
無いものは挙げられない。
464デフォルトの名無しさん:2011/04/01(金) 22:03:44.94
けなす方向にしたって何もでてきてないじゃないか。
465デフォルトの名無しさん:2011/04/01(金) 22:08:39.90
言語のシンプルさは、それだけで一つの魅力なんだよ
Modula-2にはそれが欠けていた
466デフォルトの名無しさん:2011/04/01(金) 22:10:28.68
だから具体的にはなんだよ?
文法だけで見ればModula-2のほうが今のC(++じゃなくてC)より遥かにシンプルだぞ
467デフォルトの名無しさん:2011/04/01(金) 22:18:09.80
えーどこがシンプルなの?
ちょっと説明してみ?
468デフォルトの名無しさん:2011/04/01(金) 22:34:56.57
Modula-2なんてPascalに分割コンパイルの機能を付加しただけじゃん
タイプ量も多いしCに比べると明らかに使いにくい
469デフォルトの名無しさん:2011/04/01(金) 22:41:46.78
キーボードが苦手な奴はどの言語選んでも中途半端な事やって終わるだけ
470デフォルトの名無しさん:2011/04/01(金) 22:42:52.41
結局俺に説明させてばっかじゃないか。
どこが複雑と思ってるんだよ?

まあ自分で調べる脳も無いんだろうから俺から書いてやると、
Modula-2は超典型的な構造化言語で、COBOLの書式化やらFortranの行列みたいな
変な機能がない分当時としても今から見てもシンプルな部類。
典型的な構造化言語という点ではCも同じだが、Cのほうには超複雑なマクロの展開規則と、
超複雑な宣言分の意味解析が付いて回る。意味解析の結果をパーサにフィードバックしないと構文解析できないのもコンパイラを複雑にする。
比べてModula-2は何も考えずパースできるLL(1)文法で、教科書通りにコンパイラが書ける。
型は当時のCとModula-2ならModula-2の方が多いが、せいぜい集合と部分範囲型まわりぐらいで
これも動的配列と複素数型が追加されてる今のCのほうが複雑だろ。
471デフォルトの名無しさん:2011/04/01(金) 22:43:44.92
俺が俺がってウザいね
472デフォルトの名無しさん:2011/04/01(金) 22:45:42.61
Modula厨がどんなに頑張っても、Modula-2には世の中に普及するほどの魅力がなかったのは事実なわけで。
473デフォルトの名無しさん:2011/04/01(金) 22:46:42.09
超複雑なマクロの展開規則と超複雑な宣言分の意味解析
が、今や、普通に出来るみたいだけど
474デフォルトの名無しさん:2011/04/01(金) 22:48:03.21
>>472
だからそれを書けって言ってるんだよ。
あと別に俺はModula-2をプッシュしてるわけじゃないぞ。話の流れ読めてるか?

過去にCに挑んで敗れた言語の何が駄目だったかもわからん奴に、Cの代わりなんて作れるはず無いだろうが。
475デフォルトの名無しさん:2011/04/01(金) 22:49:32.54
>>473
一度自分でCのパーサ書いてみるといい。
教科書通りではなくて、実際にその辺に転がってるソースが通るやつ。

甘く見てると死ねるから、マジで。
476デフォルトの名無しさん:2011/04/01(金) 22:51:06.18
一から作るのは、相当時間がかかるよ。
477デフォルトの名無しさん:2011/04/01(金) 22:54:36.88
>>475
自分でやる気なんかないよ。
大変なのはわかってるし、そっち方面はやったことないし、
今やってるのは、自分なりにgccをいじるぐらいだよ。
478デフォルトの名無しさん:2011/04/01(金) 23:07:42.02
今のCと当時のModula-2を比べて何の意味がある訳?
479デフォルトの名無しさん:2011/04/01(金) 23:13:14.14
C でなくても、アセンブラを作ってみるだけでも
「そもそも、問題の本質は何か?」という疑問には自然に遭遇できる
480デフォルトの名無しさん:2011/04/01(金) 23:17:47.49
問題の本質は何だったの?
481デフォルトの名無しさん:2011/04/01(金) 23:20:44.75
>という疑問には自然に遭遇できる

だから、アセンブラを作ってみて、そういう疑問が浮かんだんだろうな。
答えが得られてるかは別にして。
482デフォルトの名無しさん:2011/04/01(金) 23:25:20.65
手間かかる割に、ないものねだりする人が多いからでしょ
483デフォルトの名無しさん:2011/04/01(金) 23:25:59.56
コンパイル可能なC++インタプリタ作ってくれよ。
PHPみたいにライブラリは豊富で。
484デフォルトの名無しさん:2011/04/01(金) 23:28:58.91
>>460
>>483
これもよくわからんな。
C++インタプリタができた時点で既存のC++ライブラリが使えるから、
というかそれを使いたいからC++を指名してるんだろうに、2行目は何の意図があるんだ?
485デフォルトの名無しさん:2011/04/01(金) 23:45:13.56
インタプリタは動的に型を変更できる。型宣言なしで動きかつ純粋C++ソースをはける。
PHPのソースをパクルなりして、PHPの関数も動かせるようにする。
486デフォルトの名無しさん:2011/04/01(金) 23:54:40.09
おそらく、具体的なイメージが固まってないまま言ってるんだろうな……。
そもそもコンパイル可能なインタプリタって時点で?が付くし、
C++で書くのか出力としてC++ソースを吐くのか混乱してそうだし、
型を要求するC++の言語仕様にどうやって矛盾なく型無しを溶けこませるかも漠然としてそうだし。

まあ突き詰めていっても、最終的にC++/CLIができあがるだけの気がするが。
487デフォルトの名無しさん:2011/04/01(金) 23:56:17.19
それがお前の想像力の限界。
488デフォルトの名無しさん:2011/04/02(土) 00:02:45.59
具体的なことを何一つ書けないやつに言われたかないね
489デフォルトの名無しさん:2011/04/02(土) 00:06:45.08
今のコンピュターで何が出来るかわかってない感じ
この程度のド素人が実務やったら怖いな
490デフォルトの名無しさん:2011/04/02(土) 00:10:03.85
実務w
491デフォルトの名無しさん:2011/04/02(土) 00:18:19.76
>>489
ほほう、具体的には何ができるんだい?
492デフォルトの名無しさん:2011/04/02(土) 00:29:40.94
しらんな、自分で考えろ
493デフォルトの名無しさん:2011/04/02(土) 00:37:09.06
知らないことについて語るのは、このスレではともかく世間一般では普通に迷惑だぜ
494デフォルトの名無しさん:2011/04/02(土) 00:38:04.51
常識とか持ち出されても
495デフォルトの名無しさん:2011/04/02(土) 00:42:20.28
C++をスクリプト言語化しつつ、純粋なC++のソースもはけるやつ。
易しいC++から厳格なC++に変換可能。
496デフォルトの名無しさん:2011/04/02(土) 00:43:56.52
楽したいと思うようなことは考えないほうが
497デフォルトの名無しさん:2011/04/02(土) 00:49:15.06
C++のスクリプト言語化(C++ソースはける)のはかなり需要あるはず。
webプログラムも、アプリ開発、ゲーム開発もこれに統一できるだろう。
そして既存C++ソースは読み込めて流用できる。
標準でPHP並の装備付きで。
498デフォルトの名無しさん:2011/04/02(土) 00:50:34.64
素人でもかける言語が欲しいのかいな?
499デフォルトの名無しさん:2011/04/02(土) 00:53:14.77
Cのソースを吐くならValaがあるが、
C++のソースを吐くなんて需要あるのだろうか
500デフォルトの名無しさん:2011/04/02(土) 00:55:54.46
C++に憧れを抱くPHPerってところか
501デフォルトの名無しさん:2011/04/02(土) 01:01:59.53
>>497
良かったな、C++0xで、ローカル変数についてはほとんど型書かなくて良くなるし、
ranged-forみたいな構文糖も入るし、正規表現も入るぞ!
徹底的に型を排除したければboost::anyみたいなものもあるしな!
PHP並のWeb用のライブラリなら腐るほどその辺にあるし、ばっちしだな!
502デフォルトの名無しさん:2011/04/02(土) 01:08:11.69
そんな馬鹿なことやってるんだ
503デフォルトの名無しさん:2011/04/02(土) 01:26:15.44
労力の割には、報われんこと?をやってるんだ、かわいそう
504デフォルトの名無しさん:2011/04/06(水) 22:05:48.31
俺、アセンブラは68000しか経験のない素人だけど。
元々PDP-11のアセンブラを高級言語風に表現したのがC言語なんでしょ?
なら,x64辺りのニーモニックをC風に表現したら、
取り敢えずWindowsプログラミングは多少楽になるんでね?
505デフォルトの名無しさん:2011/04/06(水) 22:41:18.38
> 元々PDP-11のアセンブラを高級言語風に表現したのがC言語なんでしょ?

その言説は、合ってる部分もあるし、違う部分もある。
たとえばインクリメント・デクリメントが += 1, -= 1 とは別にあるのはPDP-11の機械語の
影響だとされているけど、hoge_t 型を指すポインタに対する演算が sizeof(hoge_t) 倍に
なるなんてのはぜんぜんアセンブラ的じゃない。

> なら,x64辺りのニーモニックをC風に表現したら、
> 取り敢えずWindowsプログラミングは多少楽になるんでね?

意味不明。
506デフォルトの名無しさん:2011/04/06(水) 23:17:48.71
CISCの命令拡張で生き延びてるから、C風にはならないような
レジスタで固定の命令も結構あるし
507デフォルトの名無しさん:2011/04/07(木) 00:05:04.47
bsfなんかが組込み演算子になると、便利ではあるな。
特定用途でのみ。
508デフォルトの名無しさん:2011/04/08(金) 15:48:36.41
特定用途でアセンブラ使ってる人は自分でコンパイラ書けちゃうんじゃないかと思う今日この頃。
509デフォルトの名無しさん:2011/04/08(金) 17:01:03.30
アイディアを思いつくかどうかと
それを実装できるかどうかは別問題

俺がやってみての実感:
構文設計は始めサクサクだんだんgdgd
字句解析の1段目からすでに結構な大仕事で最終段に来る頃にはくたくた
後で思いついたアイディアは素晴らしいがそれは振り出しへ戻ることを意味し
ハンドアセンブルしてた頃のMっけと重なりだす

Ken さんは偉いよやっぱ
510デフォルトの名無しさん:2011/04/08(金) 18:29:35.03
まずは「コンパイラ」か何か読んで理論を押さえるべき。
511デフォルトの名無しさん:2011/04/09(土) 01:12:54.36
May the Forth be with you.
512504:2011/04/09(土) 22:40:16.41
>>505
>その言説は、合ってる部分もあるし、違う部分もある。

アセンブラをアセンブラのまま置き換えても構造化は出来ませんからね、
違う部分もあって当然でしょう。
でも、ポインタ概念自体がアセンブラ的だと私は思うけど。
その辺りの境界は人それぞれですけどね。

>意味不明。

今自分で読み返してみて、通じる訳ないよね、と思った。スイマセン。
ターゲット環境のハードを記述言語の下敷きにすれば、意図した事が
思い通りに書けるし、コンパイラ側の最適化も見通し楽にならないかな、
と思った訳です。
甘いでしょうけど。
513デフォルトの名無しさん:2011/04/10(日) 03:07:10.29
> アセンブラをアセンブラのまま置き換えても構造化は出来ませんからね、

アセンブラのマクロは構造化の最もプリミティブな単位たる「モジュール」の要件を満たす
514デフォルトの名無しさん:2011/04/10(日) 03:07:46.21
追加: ように作れる
515デフォルトの名無しさん:2011/04/10(日) 03:20:13.15
今時のコンパイラは
ソース(中間コード)レベルでの最適化
archレベルでの最適化
みたいなことやってるみたいだよ
516デフォルトの名無しさん:2011/04/10(日) 03:28:31.62
最適化とモジュール構造は別問題
俺が言うのも何だが、早まった最適化はあとで仇なすのを承知ですること
517デフォルトの名無しさん:2011/04/10(日) 03:58:51.61
>>516
お前は覚えたばっかの言葉を使いたいだけだろ
518デフォルトの名無しさん:2011/04/10(日) 04:39:09.04
いーや、おまえが生まれる前におぼえたが何か?
519デフォルトの名無しさん:2011/04/14(木) 06:23:25.97
とりあえず、どんな言語作りたいのか
文法一覧書いてみろ
520デフォルトの名無しさん:2011/04/14(木) 11:31:40.82
ここの人は手続き型言語しかやったことない人達?
521デフォルトの名無しさん:2011/04/14(木) 11:54:57.53
コーディング作業の8〜9割がデータ構造の記述で
最後に補助的に手続きを書く言語とか
ひたすら並列が基本で時系列はメタな存在という言語ならやったが
522デフォルトの名無しさん:2011/04/14(木) 12:14:21.48
種の割れてる手品しかやったことない人達
かっこいいじゃん
523デフォルトの名無しさん:2011/04/14(木) 12:29:09.26
手続き型言語とかいってる時点で...
524デフォルトの名無しさん:2011/04/14(木) 12:37:06.97
論理型はやったこと無いな。
525デフォルトの名無しさん:2011/04/14(木) 21:10:48.02
Basicでいいや♪
526デフォルトの名無しさん:2011/04/15(金) 01:02:33.15
>>521
それって、あれか?


・・・Excel
527デフォルトの名無しさん:2011/04/23(土) 04:21:12.17
ていうか、アセンブリなんて
主な命令は大同小異だし
元にしても意味ないよ
高級言語風アセンブラはいくつも
製品化されてるでしょ
生き残ってないけど。

昔から最適化は今でいうASTのような
式とかソースレベルのものと、
コード直結のピープホールがあるよ
太古のFortranとかかなりのモノ
今から2-30年前には基本的な技術は
完成してる
528デフォルトの名無しさん:2011/04/23(土) 08:06:39.56
>>526
ラダーチャートかと思った
529デフォルトの名無しさん:2011/04/23(土) 08:44:22.19
C/C++言語でいいじゃん。コンパイラの性能上げろ。
530デフォルトの名無しさん:2011/04/23(土) 18:48:04.14
>>527
MASMは現役ですが・・・?
531デフォルトの名無しさん:2011/04/23(土) 19:35:01.48
>>526
それって何て言語?
532デフォルトの名無しさん:2011/05/10(火) 21:39:25.70
>>530
それは単なるマクロアセンブラ
533デフォルトの名無しさん:2011/05/10(火) 22:49:49.34
だからそれを高級言語風アセンブラと言ってるんだろ
534デフォルトの名無しさん:2011/05/10(火) 23:15:14.56
もっといろいろ機能付けたアセンブラがあったわけですよ
535デフォルトの名無しさん:2011/05/10(火) 23:18:58.28
(´ι _` )アッソ
536デフォルトの名無しさん:2011/05/11(水) 02:55:30.94
構造化アセンブラとかいってたけど...
537デフォルトの名無しさん:2011/05/11(水) 11:24:46.17
新低級言語
「X+-」
名前だけ参入
読み方は自由
538デフォルトの名無しさん:2011/05/11(水) 17:55:25.80
ばつ・たす・ひく でバタヒー
539デフォルトの名無しさん:2011/05/11(水) 19:00:39.94
結局いくつかの言語混ぜればいいだけじゃねーの?
540デフォルトの名無しさん:2011/05/12(木) 00:01:23.38
どう混ぜるの?

具をテキトウに混ぜても、おいしいチャーハンにはならないよ。
541デフォルトの名無しさん:2011/05/12(木) 01:02:15.62
カリー化カリー化うるせーやつが出てきてこのスレは終わった
542デフォルトの名無しさん:2011/05/12(木) 01:10:49.68
そんなに悔しかったのかw
543デフォルトの名無しさん:2011/05/12(木) 01:15:30.19
カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化

カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化

カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化
544デフォルトの名無しさん:2011/05/12(木) 04:48:51.15
今日はカレーか
545デフォルトの名無しさん:2011/05/12(木) 08:08:37.30
コンパイラの勉強もかねてCのサブセットでも作りますか。
その名もC--ってもうあr・・・無いね。
546デフォルトの名無しさん:2011/05/12(木) 16:57:44.70
ぐぐれ
547uy:2011/05/14(土) 00:46:55.49
誰も作ろうとしない
548デフォルトの名無しさん:2011/05/14(土) 02:00:15.87
>>547
のではなく出ては消えていくだけ
549デフォルトの名無しさん:2011/05/14(土) 02:01:54.07
ObjC も C++ もそうだけど、初期のうちは C へのトランスレータがあるというのが重要かもね
つうことで、Vala で良いじゃん
550デフォルトの名無しさん:2011/05/14(土) 09:46:44.81
ある程度以上の独自言語らしい機能を搭載したら、変換後のCコードなんて
普通に読めたもんじゃないぞ。

単にバックエンド自分で実装しなくて楽だね、ってだけの理由しかない。
今時LLVMとかあるんだからその重要性はどんどん低くなってる。
551デフォルトの名無しさん:2011/05/14(土) 12:17:10.95
いや、Valaの出力は結構読める
552デフォルトの名無しさん:2011/05/15(日) 00:35:32.97
トランスレータに徹した言語なら昔使った
それ自体が何用なのかが、翻訳後の言語によるという位置づけのやつ
553デフォルトの名無しさん:2011/05/24(火) 02:32:41.45
カリー化
554デフォルトの名無しさん:2011/05/24(火) 18:25:14.46
      _ -、`ヽ、ヽ//:::::::::::::::::::::::::::::::::::::::::::::::::\ー-'′  ,   ___   -l-l-
     ,. -‐ヽ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ  Z三|ヨ‐  /  _亞亞_
   /,ィ:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ノ  X ニ|ニ  /\‘ 夕 ’
    /;::::::::::::::::::/:;ィイヽ//ハ\:::::::::::::::::::::::::::::::-=二    二二′│   「三 |
  //::::::::::::::::://      !ト、ヽ、::::::::::::::::::::::::::::::::::::::`ヽ    (_   |,/  フ亡
  ,ィ:::::::::::::::::::ハ:|     ,:  |l ヽx≧ヽ、__::::::::::::; - 、::::ノ   Z_   ⊥   -{-
 // !::::::::::::::::::トk、  、 ヽ  !ィ〆‐- 、  _ユ イ 广 \`ヽ tz_)  ‘X   ヽ_`
 !{ |::::::::::::::::::レ‐≧kx  ヾィj√云¨ヽ Y´  |::::| r 、 〉 }::く‐/‐ 、  └‐   -|-l-
 ヽ. |::i::::::::::::∧イ t込,`Y¬! ' _二 -′}   レリ j ベ /:::丿 tト      └‐
   !ハ:::ト、::t{ヽ}  ー¨ '_ }  ヾ、" ‐  /    〈   //:∠  {j {j       Z_
    ヽ ';ヽヽ、ヽl   '", イ    ` ̄´      /´ ̄/::::/ \・ ・        tz_)
     ヽ\ ` l` ̄´ /             |-ーヘ:::イ   ヽ /ヽ/⌒\
          l   ヽ=≧           |    レN    ∨     ヽ  /
             l     _,. -‐¬、        |    ヽ               ∨
          ',   { <´ ̄`\     /     \
            ヽ   | ̄ィ´ ̄`ソ     /   :.
            ゙、   Y└-‐/   /.::   :.
             ヽ  `二´ ′/.:.:.:    :.
              ヘ、   _/.:.:.:.:.::      :.
               ` ̄´ \.:.:.:.:.     :.
                   /\.:.:..     :.
                  /   { \: :.    :.
555デフォルトの名無しさん:2011/06/02(木) 04:34:34.44
このAAがこのスレの全てだな
556デフォルトの名無しさん:2011/06/02(木) 11:36:55.35
>>552
興味あるな。なんてやつ?
557デフォルトの名無しさん:2011/06/05(日) 17:56:34.51
transcript
558デフォルトの名無しさん:2011/06/05(日) 20:51:32.88
>>557
それって言語の名前?
ググったけど Revolution とか HyperCard とか出てきた。
トランスレータには見えないんだけど・・・
559デフォルトの名無しさん:2011/06/05(日) 20:56:30.14
初期のC++じゃん
560デフォルトの名無しさん:2011/06/05(日) 21:31:30.27
Colm使っておけ
561デフォルトの名無しさん:2011/06/10(金) 05:29:26.18
とりあえず、最近は、アセンブラレベルで見てみてます。
562デフォルトの名無しさん:2011/06/12(日) 20:50:16.12
とりあえず誰かBisonか
boost::spiritでコード上げろや。
まぁ、んな事書いたら言い出しっぺの法則って言われるからとりあえず一部だけ書いとく
とりあえずココマデ。

template<typename Iterator>
struct Expression
: qi::grammar<Iterator, int(), ascii::space_type>
563デフォルトの名無しさん:2011/06/15(水) 00:31:42.39
浮上
564デフォルトの名無しさん:2011/06/15(水) 22:02:05.94
一部過ぎるwww
565デフォルトの名無しさん:2011/06/18(土) 12:39:37.77
(・∀・)Goとか凄いらしいよ
566デフォルトの名無しさん:2011/06/30(木) 03:00:16.17
GCCでも標準サポートだし、このスレの役目も終わったな。
567デフォルトの名無しさん:2011/07/03(日) 16:21:56.60
以上カリー化って言いたいだけのスレでした
568デフォルトの名無しさん:2011/07/03(日) 22:33:44.39
そんなに悔しかったのかwww
569デフォルトの名無しさん:2011/07/03(日) 22:35:30.06
カリー化 マリー化 弦を弾いて
570デフォルトの名無しさん:2011/07/09(土) 00:59:10.55
      _ -、`ヽ、ヽ//:::::::::::::::::::::::::::::::::::::::::::::::::\ー-'′  ,   ___   -l-l-
     ,. -‐ヽ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ  Z三|ヨ‐  /  _亞亞_
   /,ィ:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ノ  X ニ|ニ  /\‘ 夕 ’
    /;::::::::::::::::::/:;ィイヽ//ハ\:::::::::::::::::::::::::::::::-=二    二二′│   「三 |
  //::::::::::::::::://      !ト、ヽ、::::::::::::::::::::::::::::::::::::::`ヽ    (_   |,/  フ亡
  ,ィ:::::::::::::::::::ハ:|     ,:  |l ヽx≧ヽ、__::::::::::::; - 、::::ノ   Z_   ⊥   -{-
 // !::::::::::::::::::トk、  、 ヽ  !ィ〆‐- 、  _ユ イ 广 \`ヽ tz_)  ‘X   ヽ_`
 !{ |::::::::::::::::::レ‐≧kx  ヾィj√云¨ヽ Y´  |::::| r 、 〉 }::く‐/‐ 、  └‐   -|-l-
 ヽ. |::i::::::::::::∧イ t込,`Y¬! ' _二 -′}   レリ j ベ /:::丿 tト      └‐
   !ハ:::ト、::t{ヽ}  ー¨ '_ }  ヾ、" ‐  /    〈   //:∠  {j {j       Z_
    ヽ ';ヽヽ、ヽl   '", イ    ` ̄´      /´ ̄/::::/ \・ ・        tz_)
     ヽ\ ` l` ̄´ /             |-ーヘ:::イ   ヽ /ヽ/⌒\
          l   ヽ=≧           |    レN    ∨     ヽ  /
             l     _,. -‐¬、        |    ヽ               ∨
          ',   { <´ ̄`\     /     \
            ヽ   | ̄ィ´ ̄`ソ     /   :.
            ゙、   Y└-‐/   /.::   :.
             ヽ  `二´ ′/.:.:.:    :.
              ヘ、   _/.:.:.:.:.::      :.
               ` ̄´ \.:.:.:.:.     :.
                   /\.:.:..     :.
                  /   { \: :.    :.
571デフォルトの名無しさん:2011/07/09(土) 01:39:39.24
Cのマクロを代替して、ネームスペースを解決する言語があればそれでいい。
Go言語が近いけどたぶんそれる。
572デフォルトの名無しさん:2011/07/13(水) 18:51:53.54
カリー化できればなんでもいいよ
573デフォルトの名無しさん:2011/07/20(水) 03:31:52.30
言語仕様覚書

構造化の言語要素として
・ループ
・条件分岐
は必須。

ループ命令は大きく2種類、for文とdo文
for文はループカウンタや集合イテレータのループ。
for(継続条件 on 増分)ループ内容 か
for(変数 in 集合変数)ループ内容 の形式

ループ内容は
init{初期処理}{ループ処理}final{終了処理} の形式。init節とfinal節はそれぞれ省略化。

do文は、do ループ内容 while(継続条件) か
while(継続条件) do ループ内容 のどちらか。

ループ中に以下の命令があればジャンプ
continue (増分処理をして)ループ処理先頭に飛ぶ
break final節に飛ぶ(無ければループ終了)
exit for(またはdo) ループ終了

条件分岐は2種類。if文とswitch文。
if (条件) 真文 else 偽文 endif
ただし、「else 偽文」は再帰的に「elsif (条件) 真文 else 偽文」 に置き換え可能。
switch (式左辺)
 case 比較演算子 式右辺 : 真文
  |
 default : 偽文

真文の中にcontinueと記述すると次のcaseの真文に飛ぶ。真文の末尾にきたら switch文を抜ける。
574デフォルトの名無しさん:2011/07/20(水) 03:38:44.35
何これ?
575デフォルトの名無しさん:2011/07/20(水) 04:03:48.11
言語仕様覚書

並列処理可能な部分を明示するにはsync文

sync(並列可能定数)init{初期処理および共用変数宣言}{並列処理1}{並列処理2}…

全てのsync内文が終わるまで同期を取る。
共用変数へのアクセスは
lock(共用変数1,共用変数2,…){変数使用処理}
の文で排他制御を行う。タイムアウトについては別途仕様を精査する。


並列演算

2次元配列同士の演算は行列演算とみなす。
int a[][]={{1,2},{3,4}}, b[][]={{3,4},{5,6}},c[2][2]
c=a*b

ベクトル演算はpara文。para(変数 mask マスクパターン){処理}
int a[256]={1,2,3,…,256}
byte m1=0x55, m2=0xaa

sync(2)init{int b[256]}{
 para(b mask m1){ b=a*2}
}
{
 para(b mask m2){ b=a*3}
}
576デフォルトの名無しさん:2011/07/20(水) 04:05:51.38
あ、bがsync文の外に持っていけないな。
syncにもfinal節が必要だわ。
577デフォルトの名無しさん:2011/09/09(金) 16:27:07.97
>>576それがひつy
578デフォルトの名無しさん:2011/11/20(日) 01:08:23.69
◆新言語の前提◆

・言語仕様が小さい
・言語仕様に例外事項(但し書き)が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なPCアーキテクチャを直接制御するための記述ができる
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
579デフォルトの名無しさん:2011/11/20(日) 02:45:24.74
Cにかわるとか野望がでかすぎて無理くさい。

アッパーコンパチ以外、想像もつかない。
580デフォルトの名無しさん:2011/11/20(日) 10:57:41.55
無料RPG製作ツール「ロープレジェネレーター」

直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力する
ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます)
他にも仲間預かり機能(100人も)や、仲間の状態/状態異常を細かく設定
できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や
フラッシュなどのエフェクトなんかも簡単に作れる様です。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
戦闘はデフォだとドラクエ系。

・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)
581デフォルトの名無しさん:2011/11/20(日) 13:36:44.63
言語レベルでドキュメント生成とか狂ってる
582デフォルトの名無しさん:2011/11/21(月) 02:30:34.29
> ・標準的なPCアーキテクチャを直接制御するための記述ができる

つまり PC の仕様変更に、PC 絶滅まで振り回されるわけか
583デフォルトの名無しさん:2011/11/21(月) 02:31:47.97
> ・仕様にコーディング規則を含み、それに従うことをある程度強要する

「ある程度」が蟻の一穴ということを、まだ学んでいないな
584デフォルトの名無しさん:2011/11/21(月) 06:21:37.32
で?
585デフォルトの名無しさん:2011/11/21(月) 13:31:12.49
>>578
CがOS作成向けってのはOSの機能を使わない(ライブラリなし状態)でもポインタとかは使えるのが強みだぞ


586デフォルトの名無しさん:2011/11/21(月) 22:31:22.23
つgolang
587デフォルトの名無しさん:2011/11/21(月) 23:08:07.36
>>585>>578に対してどういう意図でレスしているのかよく分からない。

>>585>>578は相反しない。
588デフォルトの名無しさん:2011/11/22(火) 13:44:50.77
なんでPC限定?かわからんが
アドレス直アクセス、
I/Oポートアクセス、
割り込みハンドラが書けるとかかね

Cでは普通は後者二つは出来ない
アドレスの自由なポインタは強力だが
危険過ぎてC直系以外ではほぼ採用されてないね
それにポインタで読み書きしても実際に
アクセスされる保証がないから
むしろライブラリで対処かな
589デフォルトの名無しさん:2011/11/22(火) 19:20:56.60
>>588
> アドレスの自由なポインタは強力だが
> 危険過ぎてC直系以外ではほぼ採用されてないね
つか, ないとカーネルとかデバドラとかかけない
頼むから高級アセンブラを、 その他の高級言語と同じに扱わないでくれ
590デフォルトの名無しさん:2011/11/22(火) 19:55:38.92
自由に指す機能が必要なのは、ヒープ管理とか、ごく限られた
モジュールだけじゃないかという気がするが。

ていうか「高級アセンブラ」とか得意がる奴はたいていハッタリ野郎というのが俺の印象。
591デフォルトの名無しさん:2011/11/22(火) 21:42:12.41
物理が苦手な化学屋みたいなもんで、ありえねえ
592デフォルトの名無しさん:2011/11/23(水) 01:03:02.21
処理系側としては、極力ポインタは制限したい
どこを指してるのか・何が指されてるのか・何を指す可能性があるのか
静的に分からないと最適化できん
593デフォルトの名無しさん:2011/11/23(水) 01:47:55.78
◆新言語の前提 ver0.01◆

・言語仕様が小さい
・言語仕様に例外事項(但し書き)が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
594デフォルトの名無しさん:2011/11/23(水) 03:35:50.63
という言語が欲しいのです、ということですか?
595デフォルトの名無しさん:2011/11/23(水) 10:13:47.58
YES
596デフォルトの名無しさん:2011/11/23(水) 14:14:29.34
言語仕様覚書

式について

{}で囲まれ、「,」で区切られた値の組は集合を表す。
集合は各要素変数への一括演算が可能。
例){a,b,c}={1,2,3}

関数の戻り値に集合を指定して複数の戻り値を返すことも可能。
597デフォルトの名無しさん:2011/11/23(水) 15:26:32.15
Linuxカーネルは元が86てこともあるが
移植性やアドレス空間を考慮して
I/Oのアドレス直なんてあんまり使ってないよ
volatile,aliasing,restrictとかが必要になるが
言語的に結構面倒なんよね
高級アセンブラはc99でかなり完成してるし
goのように少し違う方向性がいんじゃね
598デフォルトの名無しさん:2011/11/23(水) 17:24:48.51
オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて
かつ、その記述が平易、直感的、誤解が少ないことが望ましい。
599デフォルトの名無しさん:2011/11/23(水) 19:40:15.66
文字列はどうするんだ?基本の型に入れるのかな。
入れたとすると多言語とかどうすんの。
600デフォルトの名無しさん:2011/11/23(水) 19:42:02.46
>>598
組み込みとかOSやドライバやったことないだろ
601デフォルトの名無しさん:2011/11/23(水) 19:42:50.48
文字列型入れると問題になるのはメモリ管理だね
602デフォルトの名無しさん:2011/11/23(水) 19:51:56.02
文字列型は必須だが、「組込みとユーザー定義の区別がない」のであれば、基本型である必要はないかな。
603デフォルトの名無しさん:2011/11/23(水) 19:59:43.98
基本型に入れないと結局Cのnull終端のバイト列にしかならんのじゃないか?
604デフォルトの名無しさん:2011/11/23(水) 20:03:13.02
>>598
なんか過去にひどい目にあったかのような要望だなw
605デフォルトの名無しさん:2011/11/23(水) 20:45:47.05
全くランタイムに依存しない言語なんてのは
実際には難しいわな
606デフォルトの名無しさん:2011/11/23(水) 21:18:09.44
CPU のμOP にすら依存しない言語が身近にあるのに・・・
607デフォルトの名無しさん:2011/11/23(水) 22:13:35.77
>>603
何故そう思ったの?
608デフォルトの名無しさん:2011/11/23(水) 22:40:42.41
別にPascal風にレングス+バイト列でもかまわんだろ。
基本型から外すとウザい気もするが。
609デフォルトの名無しさん:2011/11/23(水) 22:41:36.23
別にPascal風にレングス+バイト列でもかまわんだろ。
基本型から外すとウザい気もするが。
610デフォルトの名無しさん:2011/11/23(水) 22:47:50.57
レングスのフィールドは可変長?
611デフォルトの名無しさん:2011/11/23(水) 23:10:29.75
文字列の内部表現はあまり重要な問題では無いので、テキトウに。
NULL終端でいいんじゃないの。
612デフォルトの名無しさん:2011/11/23(水) 23:17:57.40
>>606
マシン語とかCPUアーキテクチャといいたいのか?w
メモリ管理やらブートストラップやら
どのCコンパイラも結構ランタイムとがっぷりだよ
自分でそのへんまで弄れる言語は他にはないけどさ
613デフォルトの名無しさん:2011/11/24(木) 00:36:11.90
>>612
そのランタイムの大部分を自身で書けることが C の存在意義で
どうしてもアセンブラや diagnose が必要なコードが無視しがたい量になるかどうかが境だ
614デフォルトの名無しさん:2011/11/24(木) 00:43:09.03
>>606
CPUのμOPに依存する言語なんてあるの?
615デフォルトの名無しさん:2011/11/24(木) 00:49:06.24
アセンブリ言語はマイクロコードの組み方に影響をうける
つか、インストラクションセット自体が変化するわな
616デフォルトの名無しさん:2011/11/24(木) 00:52:45.95
プロセッサのインストラクションセットが変われば、アセンブリ言語が影響を受けるって話?
まあ、そりゃそうだわな。
617デフォルトの名無しさん:2011/11/24(木) 01:16:40.39
マシン語互換ならマイクロなんちゃらは
関係ねえからw
せいぜい最適化位
armとかriscはほとんどハードワイヤードで
マイクロなんちゃら持たない
618デフォルトの名無しさん:2011/11/24(木) 22:45:59.04
既存のバイナリーオブジェクトをリンクして呼び出せること
619デフォルトの名無しさん:2011/11/26(土) 06:06:34.23
>>614
μOPという以前にマシン語レベルで従来のそれらとはまったく違う価値観な
プロセッサは存在している。例えばスキップ命令(条件分岐命令がない)を実装したものとか
四則演算(整数&浮動小数点両方)が存在しないとか。
メジャーな高級CPUばかりな人は知識にすらないだろうけどね。
620デフォルトの名無しさん:2011/11/26(土) 19:29:29.01
今はロジックが余るし電力無駄だから
マイクロコードなんてx86位だろ
しかし条件実行は知ってるが
四則演算がないCPUは知らんな
そろそろスレ違いか
621デフォルトの名無しさん:2011/11/26(土) 19:30:52.01
そいや昔の8bitなんかは掛け算割り算なかったか
622デフォルトの名無しさん:2011/11/26(土) 19:36:51.17
>>620
除算命令のマイクロコード実装すらサボってるARM
623デフォルトの名無しさん:2011/11/27(日) 01:34:36.56
◆新言語の前提 ver0.02◆

・言語仕様が小さい
・言語仕様に例外事項(但し書き)が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
 (オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい)
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
・既存のバイナリーオブジェクトをリンクして呼び出せる
624デフォルトの名無しさん:2011/11/27(日) 13:08:56.99
7までいってver0.02とかねえ
625デフォルトの名無しさん:2011/11/27(日) 19:17:21.56
え、今まで成果物出てないの?
626デフォルトの名無しさん:2011/11/28(月) 09:05:03.82
ざくっとgoの多値とinterface{}と
後置宣言をなんとかすればok
627デフォルトの名無しさん:2011/11/29(火) 12:02:00.25
goの改良点全否定っすか。
628デフォルトの名無しさん:2011/11/29(火) 21:11:06.02
sliceとか型推論とかgcはいいよね
629デフォルトの名無しさん:2011/12/04(日) 14:22:14.72
>>620
>四則演算がないCPUは知らんな
お前の家にもリモコンぐらいあるだろ?
液晶などが付いてない単純な送信だけの赤外線のTVリモコンの類が
それだ、

そのCPUは非常に単純な機能だが福島原発の原子炉横のような放射線を
浴びても問題なく動く。
駆動の電源が波動するような状況で動くことが前提になっていてデータが
常に化けて誤動作するような状況でも暴走しない設計になっている。
630デフォルトの名無しさん:2011/12/04(日) 14:29:08.09
それを「CPU」と呼べるなら、犬の餌だって「CPU」だ。
631デフォルトの名無しさん:2011/12/04(日) 21:18:23.30
C#がネイティブバイナリを吐けて、CやC++のライブラリをそのまま使用出来たらそれで満足だ。
632デフォルトの名無しさん:2011/12/05(月) 00:55:50.28
>>630
いや、寝ぼけてるんだろ
633デフォルトの名無しさん:2011/12/05(月) 03:34:33.74
除算機が付いてないCPUとかアホほどあるだろ
634デフォルトの名無しさん:2011/12/05(月) 03:56:37.97
バスガス爆発
635デフォルトの名無しさん:2011/12/07(水) 16:04:04.20
javaよりがいいっす
636デフォルトの名無しさん:2011/12/17(土) 21:08:30.07
>>630
乗算が無くシフト演算で実装するしか無いRisc CPUは、
CPUでは無いのか?
637デフォルトの名無しさん:2011/12/17(土) 21:20:15.34
誤爆
638デフォルトの名無しさん:2011/12/22(木) 11:43:11.67
ぶっちゃけ、大抵のプログラムは、C#なりPythonなりHaskellなりGoなりの高級言語を使えばよくて、
わざわざ「Cに代わる低級言語」を持ち出す必要はない

一方で、本当にC言語に取って代わろうとするなら、
高級言語を持ち出せない、プアな環境で使えないといけない

・ポインタ演算は手放せない
・GCは使えない
・ポリモーフィズムも使えない
・テンプレートも容量を食い過ぎる
・正規表現を実行時にコンパイルするのは贅沢すぎる
・標準ライブラリーが充実させても意味が無い
・標準でないアーキテクチャをサポートしなければならない

それなら、C言語で十分じゃない?

文字列型?ハッシュマップ?サードパーティ製のを使えばいい

ドキュメント自動生成なら、言語仕様を変更しなくても、Pythonとかでツールを作ればいい

Cのシンタックスがキモいとか、Lisp風マクロとかが欲しいと言うのなら、
JavaScriptに対するCoffeeScriptみたいな物を作ればいい
639デフォルトの名無しさん:2011/12/22(木) 22:37:18.06
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
640デフォルトの名無しさん:2011/12/22(木) 23:56:30.66
> ・ポリモーフィズムも使えない

関数ポインタが使えないアフォの鳴き声だなw
実行時にコンパイルとか標準でないアーキテクチャとか発狂する気持ちはわかるわ、同意せんが
641デフォルトの名無しさん:2011/12/23(金) 19:38:58.61
ちっちゃいのしかやったこと無いんだろ
組み込みはむしろ千差万別が前提だから
でもまともなのライブラリがある方が楽だしな
h8とかしか知らなかったら不幸
642デフォルトの名無しさん:2011/12/24(土) 15:49:09.77
プアな環境では、ポリモーフィズムは使えないっつーか要らないよな。
643デフォルトの名無しさん:2011/12/24(土) 17:00:27.45
どうせ静的なのしか使わないからあって困らん
使うかどうかは別だけど。
rttiみたいなのがいらんだけ
644デフォルトの名無しさん:2011/12/26(月) 05:24:42.59
rttiの必要性はいまだによくわからない
どう考えてもC++向きじゃなかった
645デフォルトの名無しさん:2011/12/28(水) 00:20:22.38
本来はユーザ定義でよかったんだよ
規格化するにしてもライブラリとして言語とは別枠で
若かった禿さまが耐えきれず出ちゃったんだよ
646デフォルトの名無しさん:2011/12/29(木) 01:22:31.36
ホントにプアな環境だと、mallocなんてありえないし、
バイト単位でコードサイズを削るハメになる。

けど、そこターゲットじゃないだろ。
スレ的には、低水準かどうかの話なんじゃないの?
要は直接レジスタを叩くようなハード制御ができるかどうか。
647デフォルトの名無しさん:2011/12/30(金) 08:54:37.20
まあレジスタ叩くだけなら
ライブラリ用意すればいいだけだからな
しかし組込にはC11が順当に上がってて
とって代わるというのが考えにくいな
648デフォルトの名無しさん:2011/12/30(金) 13:15:28.18
ARMアセンブラでアプリ開発してる人いる?
649デフォルトの名無しさん:2012/01/29(日) 16:39:01.77
Mozilla、安全性にフォーカスしたコンパイル型言語「Rust 0.1」をリリース
ttp://sourceforge.jp/magazine/12/01/25/084226
650デフォルトの名無しさん:2012/01/29(日) 17:54:19.68
このスレッドの成果がようやく現実のものとなったか
651デフォルトの名無しさん:2012/02/01(水) 20:36:10.42
これだけ根の生えた C を枯らす気なら
それこそ化学反応や物理現象まで降りることができて、
且つ少なくとも BASIC よりはユーザ寄りなことができないと無理だろ
652 ◆khwKd8pYFQ :2012/02/10(金) 09:58:44.87
>一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで

うーんそこからは新しい物は何も生まれないんじゃないかと思う。
653デフォルトの名無しさん:2012/02/11(土) 00:05:49.04
思うことは誰にでも許された自由である。
654R2G ◆lMCmV0X/mQ :2012/02/11(土) 16:02:10.60
Cより高級でC#より低級なObjective-Cみたいなのは需要ありそう。
メモリが節約できること、Cを呼び出した時にJavaのような
データ転送コストがないことが満たされれば十分低級なはず。
655デフォルトの名無しさん:2012/02/11(土) 16:19:38.70
おまえは間違ってる。
低級と高級の差は性能じゃない。
JavaやC#のコンパイラがC言語ソースに翻訳したり、ネイティブライブラリとリンクすればC言語なみの性能になる。
オールアセンブラでも無駄な処理をするプログラムは遅い。
656デフォルトの名無しさん:2012/02/11(土) 16:23:03.19
逆にCコンパイラーでJava仮想マシーン上で動くバイナリを生成する物も作れる。
そしたらC言語の性能が良いとは言えないだろ。
人間にとって扱いやすさが高級だ。
657R2G ◆lMCmV0X/mQ :2012/02/11(土) 17:05:38.35
混同しておりました
658デフォルトの名無しさん:2012/02/11(土) 18:06:05.42
へー、objc はメモリが節約できるのかw
659デフォルトの名無しさん:2012/02/11(土) 18:52:14.60
既存言語を採用してもいいんじゃまいか?
そのままでもいいし改善しても良いし。
ゼロから開発するのは手間掛かる。
C#などはいちおう新言語だがC/C++、デルファイ、Javaなどを参考にしてる。
それでもマイクロソフトで大人数が関わって開発しただろ。
新言語で既存の物より使える物は簡単には作れない。
コンパイラかコンバータでいいんじゃまいか。
660デフォルトの名無しさん:2012/02/11(土) 18:52:34.88
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
661デフォルトの名無しさん:2012/02/11(土) 18:55:27.46
たとえば初期のC++はCへの翻訳だった。


C++ - Wikipedia
初期のC++はCへのトランスレータとして実装された(すなわち、C++プログラムを一旦Cプログラムに変換してからコンパイルしていた)。
662デフォルトの名無しさん:2012/02/11(土) 18:59:04.53
>>660
実用上も、実装上も、まともに動作する言語を基盤にした方が良い。
現存するC/C++コンパイラもアセンブラ言語への翻訳機能しかないものもあるだろ。ほとんどかも?
663デフォルトの名無しさん:2012/02/11(土) 19:01:52.22
>「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。

基盤にするのは構わない。
「既存言語を使えばいい。」で話が終わるのがイカンといっている。
664デフォルトの名無しさん:2012/02/11(土) 19:06:25.06
言語仕様の確定している言語のコンパイラ、トランスレータすら作れないなら新言語なんて作れるか。
既製品を模倣する技術は新言語開発にも役立つ。
665デフォルトの名無しさん:2012/02/11(土) 19:10:04.60
ここは言語仕様を考えるスレである。

言語仕様を考える前にコンパイラやトランスレーターを実装したいのなら他スレでやれ。
666デフォルトの名無しさん:2012/02/11(土) 21:21:29.99
実装してみなきゃ空想論でしょ
667デフォルトの名無しさん:2012/02/11(土) 22:07:30.46
意味不明
668デフォルトの名無しさん:2012/02/11(土) 22:16:24.31
言語仕様を決める前に実装をするのは自由だが、先に行われた実装によって言語仕様が何らかの制約を受けることは一切ない。
669デフォルトの名無しさん:2012/02/11(土) 22:29:09.14
実装と仕様は関係し合ってるだろ。GNUカーネルの実装の正式版はできない。
作りながら可能かどうか修正が必要。


GNU Hurd - Wikipedia
GNUプロジェクトにとって、カーネルに相当するHurd(及びMach)の開発は最重要課題とも言えるが、その開発スピードは遅く、
2011年現在でも正式版のリリースには至っていない。また、Hurdを採用したディストリビューションとして、Debianによる開発版が存在するが、
これについても公式版のリリース時期は未定である。
開発の遅れにより、UNIX互換のフリーなカーネルとしては、GNUのプロジェクトによるものではないLinuxがデファクトスタンダードとなっている。
670デフォルトの名無しさん:2012/02/11(土) 22:33:29.06
※このスレッドはGNUカーネルのスレッドではありません
671デフォルトの名無しさん:2012/02/11(土) 23:05:39.42
まずC言語に変わる言語を開発する理由がない
672 ◆khwKd8pYFQ :2012/02/11(土) 23:11:20.92
>>671
ハードの性能も常に向上しているしパフォーマンスは問題にならないからね。
しかし俺にはある。
673デフォルトの名無しさん:2012/02/12(日) 00:37:45.64
理由何なの?俺らを共感させてくれないとアイデアも出せないし
逆に反発もできない
674 ◆khwKd8pYFQ :2012/02/12(日) 00:58:18.31
いや説明するに足る理由は無いかもしれない。個人的事情って奴だ。
675デフォルトの名無しさん:2012/02/12(日) 01:15:09.14
>>671
理由がないならこのスレに書き込むなよw
676デフォルトの名無しさん:2012/02/12(日) 01:22:20.00
コンパイラの最適化視点にたった言語だったら意味あるかもな
最近SSEとかコンパイラが使いづらい命令多いじゃん
でも人間がゴリゴリ書くのめんどいじゃん

数学を駆使して、ある命令セットを使ってできる計算の集合みたいなのをさ
過不足無く表現できる言語


xorとかandとかシフトとか駆使してマジックみたいなコーディングすることあるじゃん
あれを数学的に分析して、どういう計算は速く計算できるのかっていうことが厳密に分かるようになったら面白いなって

ある計算を与えたときに、それを最小クロックで計算する命令列を出力するコンパイラっていうかさ
そういうの考えたら面白いと思う
677デフォルトの名無しさん:2012/02/12(日) 01:25:50.25
具体的に問題にすると、

32bit -> 32bitの任意の写像を与えたときに
それを最短で計算できるx86の命令列を求めよ

っていう。32bit -> 32bitの写像は四則演算とかテーブルとかで与えるのよ
それを式変形していくと命令列になっちゃう。みたいな数学考えたら面白そう

まあ、そのために写像の表現方法
命令セットは数学として使いやすいのに限定することになるだろうけど
678 ◆khwKd8pYFQ :2012/02/12(日) 02:16:32.49
>>677
その問題に数学でどこまで迫れるかな?
ナップザック問題のようなNP困難である臭いがする。
679デフォルトの名無しさん:2012/02/12(日) 04:10:29.13
知ってる単語並べるだけの噛み合わない会話はご遠慮ください。
680デフォルトの名無しさん:2012/02/12(日) 07:00:41.66
東日本大震災以来、天皇、皇后両陛下は幾度も被災地にお見舞いに向かわれた。
今あらためて被災した東北3県を取材し、お見舞いの際に両陛下と被災者の間に生まれた心温まる秘話を再現する。

東北3県のうち最初のお見舞い先は4月27日の宮城県。両陛下が同県で最初に視察された被災地、
南三陸町の町長・佐藤仁氏(60歳)が振り返る。

「両陛下は町立伊里前小学校の校庭に自衛隊ヘリで降りられ、被災した市街地を校庭の隅から視察されました。
学校は高台にあり、校庭の先は崖になっているため、安全を考えて校庭の隅にある花壇の手前に立っていただく予定にしていたのですが、
両陛下は崖のすぐ近くまで歩み寄られ、じっと眼下の市街地を見ておられました」

両陛下は市街地に向かって黙祷を捧げ、佐藤町長から被災状況などについて説明を受けられると、
被災者が待つ町立歌津中学校の体育館を訪ねられた。同行した佐藤町長はそこで両陛下の心遣いの深さを目の当たりにする。

「私が先に体育館に入り、両陛下をお迎えしました。実は当時はまだ物が不足していて、
スリッパも用意できたのは両陛下に履いていただく2足分だけで、私はスリッパを履いていませんでした。

すると、それを見られた皇后陛下が、いったん履かれたスリッパを脱がれたのです。
さらに天皇陛下までがスリッパを脱ごうとなさった。それで皆で慌ててお止め申し上げたのですが、
他の誰も履いていないのに、自分たちだけ履くわけにいかない、というお心遣いだったのでしょう」
http://www.news-postseven.com/archives/20120211_87099.html
681デフォルトの名無しさん:2012/02/12(日) 12:44:10.60
メタプログラミングが好き放題出来るってだけで良ければ、こういうのがある。
SC言語 (論文ネタ)
http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index.html
CiSE (今使う部分だけを実装する方針らしい)
http://ll.jus.or.jp/2009/slide/beforeafter/lltv-beforeafter-shiro/slides/lltv.html
682デフォルトの名無しさん:2012/02/12(日) 12:59:01.63
最低でも、整数の四則演算にビット演算とシフト演算を追加して、式変形みたいのできたら楽しいよな
683デフォルトの名無しさん:2012/02/12(日) 13:13:36.40
それじゃ、四則演算、ビット演算、シフト演算を仕様に含めよう。

演算子は仮に+,-,*,/,>>,<<.>>>.<<<でいいかな。
684デフォルトの名無しさん:2012/02/13(月) 01:32:26.36
アセンブラ→C言語→オブジェクト指向言語→スクリプト言語 or VM用言語→関数型言語
と言語の文化は進んで来ました。現状はスクリプト言語やJava、C#が最新です。
スクリプト言語やJavaやC#はアセンブラとC,C++で作られています。
WindowsをC#で書き直そうとしましたが失敗しました。
結局、OS,言語は古いC言語やC++で書かれています。
C言語やC++を置き換える言語の試みにはGOやD言語がありますがGCがはずせない問題がありました。
Pascal,Adaは逆に完全なGCを含む事ができません。
GCなしで、GCを後付け出来る構文の言語を作りましょう。
新しいC言語風な関数型言語でスキッと作りましょう。
低レベル言語ではマクロは必要なのでLispのマクロを導入しましょう。
オブジェクト指向や関数型、GC等を導入可能な言語構文の低レベル言語を作り
今後の基礎とするのです。
685デフォルトの名無しさん:2012/02/13(月) 01:38:13.37
GC導入ってコピーGCを望むならオーバーヘッドは避けられないし
保守的なBoehmっぽいやつなら、CだろうがPascalだろうが行けるし
言語作るのにあんまり意識する必要も無いな
686デフォルトの名無しさん:2012/02/13(月) 02:32:45.60
>>684
>アセンブラ→C言語→オブジェクト指向言語→スクリプト言語 or VM用言語→関数型言語
Lisp(1958年〜)は関数型言語に分類される。
C言語(1972年〜)はその24年後だ。

アセンブリ→関数型言語野→C言語→シェルスクリプト→オブジェクト指向言語
って順番だろ?
687デフォルトの名無しさん:2012/02/13(月) 02:34:08.11
「野」が余分だったすまん
688デフォルトの名無しさん:2012/02/13(月) 02:35:37.84
>>686
あと算数間違えた24年後じゃなくて14年後だ
689デフォルトの名無しさん:2012/02/13(月) 12:01:27.66
RAIIパターン強制で例外で投げるものとか一部GCっぽいものがあればいいよ
690デフォルトの名無しさん:2012/02/13(月) 12:17:30.61
そういうのとGCはできることの集合が根本的に違うんだよな
クロージャの循環参照とか
691デフォルトの名無しさん:2012/02/13(月) 12:22:08.30
( ´_ゝ`)フーン
692デフォルトの名無しさん:2012/02/13(月) 20:12:22.05
最近は、型推論が最新技術としてもてはやされてるそうだよ
693デフォルトの名無しさん:2012/02/13(月) 20:44:38.47
何十年も前の話をいまさらって感じだよな
694デフォルトの名無しさん:2012/02/13(月) 20:46:55.60
とりあえずGCの恩恵って凄いじゃん。でも遅いじゃん
それを解決する方法を考えれば
695デフォルトの名無しさん:2012/02/13(月) 20:50:43.01
>>690
よそのクロージャへの参照なんてものは、ナマポか弱参照で持つのが正しい。
GCがある言語でも、理想論としてはそうあるべき。
文字列だの連結リストだのを使い捨てするとか、
グラフを繋いだり切ったりするアルゴリズムを実装するとか、
そういう用途ならGCに頼りまくって何の問題もないと思うけどね。
696デフォルトの名無しさん:2012/02/13(月) 20:55:00.56
>>695
クロージャーって上のスコープの変数にアクセスできちゃうじゃん
それによってGCが必要となってくる

グラフはGCあるとメガ楽だよな
697デフォルトの名無しさん:2012/02/14(火) 00:23:43.18
上のスコープにアクセス出来るのは欠点
698デフォルトの名無しさん:2012/02/14(火) 06:30:40.13
C++/CLIはgcnewを後付けしてclassが二種類になり
元々標準だった方のclassが要らなくなってきた

結局、classなしでdllを作ってからC#でdllimportすればいいし
dllを作る言語はCでなくてもいいからCの影響はもうなくなっている
699デフォルトの名無しさん:2012/02/14(火) 09:19:49.28
>>698
Windowsの.net frameworkのネイティブなライブラリはC++/CLI と gcnewでうまく作れて
高速にロード出来てうれしいというかんじなんでしょうか?

newはgcを使って、calloc はスタック使うとか mallocはヒープ使うとかにすればいいのかも。
var gc:A = new A()
var stack:A = calloc A()
var heap:A = malloc A()
Rubyっぽく
var gc:A = A.new()
var stack:A = A.calloc()
var heap:A = A.malloc()
と書くとか。gcはgallocにするとか。
var gc:A = A.galloc()
var stack:A = A.calloc()
var heap:A = A.malloc()
700デフォルトの名無しさん:2012/02/14(火) 12:58:30.02
>>699
プログラミング暦浅いだろwww
糞設計だな

それと、gcをどうやって実装するか知ってるのか?
701デフォルトの名無しさん:2012/02/14(火) 13:17:55.14
>【超高速】C/C++に代わる低級言語を開発したい 7
スレッド趣旨からするとクローじゃとかGCはいらない。
デバイスドライバーとかハードウェア制御と相性が悪い。
702デフォルトの名無しさん:2012/02/14(火) 14:39:44.21
>>699
もちろんGCの実装はもちろん知っててコピーGCとか、LispのGCとか
作った事あるぜ
GCなしは基本だけど、シンタックスを考える上でGCありを考えておき、Rubyのような
言語をエレガントに実装したり、Cのライブラリも奇麗に実装できたらいいだろ。
そういう仕組みを考えようぜと言ってるのよ。
シンタックスだけならバックエンドと切り離して考えられるから考えてみようぜ
くそ設計いうなら、おまいさんのすばらしい設計を見せてくれ
703デフォルトの名無しさん:2012/02/14(火) 14:46:17.58
GCとかは言語と関係ない。
GC付き言語からGC外せばメモリリークするだけ。
GCなし言語にGC付ければメモリリークしないだけ。
704デフォルトの名無しさん:2012/02/14(火) 14:50:29.03
GCの有無がシンタックスにも影響するんだが
Rubyボーイの低脳なこと
705デフォルトの名無しさん:2012/02/14(火) 14:56:44.79
メモリリークを手動(コード)で解放するか自動の違い。
706デフォルトの名無しさん:2012/02/14(火) 15:04:02.02
GCだって、大規模なプログラムだと、外してもいい参照を永遠と
持ち続けて実質的にメモリーリークと同じ状況になる場合だってある
707デフォルトの名無しさん:2012/02/14(火) 15:05:06.07
あおいりぃJapan
708デフォルトの名無しさん:2012/02/14(火) 15:31:13.78
GCは解放のタイミングを遅延させる意味もあるでしょう。
遅延した解放処理が悪いタイミングで重い処理と重なるとまずい。
並列GCでもゲームのような安定性の求められる分野では厳しい。
709デフォルトの名無しさん:2012/02/14(火) 15:34:48.02
えらい低レベルな議論してるのう。
スマートポインタ使えばGCは必要ないし。手動で解放することもない。
ただしスマートポインタでもGCでも同様に循環参照は手動で解放するか弱参照を用いるしかない。
まあGCだと色々面白いアルゴリズムを使う余地ができるというメリットはある。
710デフォルトの名無しさん:2012/02/14(火) 16:15:46.72
>>702
「○○なしは基本だけど○○ありを考えておく」パターンはC++にたくさん出てくる
・多重継承なしは基本だけど多重継承ありを考えておく
・実行時型情報なしは基本だけど実行時型情報ありを考えておく
このイメージを払拭しない限り、糞設計と思われても仕方ない
711デフォルトの名無しさん:2012/02/14(火) 16:53:54.80
さすが低級言語スレ、低級だのう。
712デフォルトの名無しさん:2012/02/14(火) 17:06:18.49
C++/CLIは以下のようになっていて、書式がバラバラで美しくないので奇麗に書きたいのだ
T t; // スタックに
T *t = new T(); // ヒープに
T^ t = gcnew T(); // GC管理領域に
auto_ptr<T> p(new T()); // スマートポインタ
713デフォルトの名無しさん:2012/02/14(火) 17:15:44.02
今は深く考えてないので、考えてみる必要があるんです。
最初から設計が決まってたら議論なんていらない。

多重継承は結局mixiとかtraitとかで行うみたいな流れですよね。
C++は未来を読み違えた感があるけどしょうがない。昔に考えた言語なのだから。
で、考えておく考えをしてたのがC++でメジャーな考え方なので悪い考え方ではないと思いますよ。
今、我々はC++を設計していた時代の未来を知っている。
どういう物を作りたいっていうイメージはある。
でも、構文は決まってない。だから考えようと主張してるのです。
714デフォルトの名無しさん:2012/02/14(火) 17:20:03.89
で、考える最初の段階ではブレーンストーミングが必要なので、
自由に意見を言ったらいいと思うのです。
ただ人の意見にすぐ否定するのはブレーンストーミング的にいまいちです。
ただ、ブレーンストーミングだけでは、具体性に欠ける部分があります。
だから詳細について議論して本当に駄目そうなら議論をやめればいいんです。
715デフォルトの名無しさん:2012/02/14(火) 18:17:29.04
抽象論に終始して虚しくならないかい?
716デフォルトの名無しさん:2012/02/14(火) 18:32:07.22
このスレから成果が現れない理由がわかった気がする。
717デフォルトの名無しさん:2012/02/14(火) 19:32:27.28
今さら多重継承に反対されても聞こえないなあ
718デフォルトの名無しさん:2012/02/14(火) 20:05:21.11
(∩゚д゚)ァー ァー キコエナイ
719デフォルトの名無しさん:2012/02/14(火) 20:55:08.82
多重継承の成果が聞こえない
720デフォルトの名無しさん:2012/02/15(水) 08:00:29.79
多重継承はアホな使い方しなければ問題ない
721デフォルトの名無しさん:2012/02/15(水) 18:27:42.34
>>719

ATL
722デフォルトの名無しさん:2012/02/16(木) 19:56:19.13
>>706
>永遠と 
>持ち続けて
きみはまずこくごをべんきょうしなさい
723デフォルトの名無しさん:2012/02/18(土) 14:45:53.86
ところでパッケージシステムはどうしたらいいでしょうねと。
724デフォルトの名無しさん:2012/02/18(土) 15:05:02.17
パッケージシステムって何?
725デフォルトの名無しさん:2012/02/18(土) 15:30:12.26
var a1:A = alloc A() // ヒープからアロケートする。
var a3:A = auto A() // ローカルスタックからアロケート
var a2:A = new A() // GCで管理
var a4:A = auto_ptr A() // 自前なスマートポインタ
と書くとすれば、型情報をどう管理するかが問題で保守的なGCか
型情報をデータに持たせる動的な型の管理になる。
今までのC言語は静的に型の情報を解決しないと実現出来ないから保守的なGCでしか
上のシンタックスは実現出来なさそう。
726デフォルトの名無しさん:2012/02/18(土) 15:43:01.53
型情報を管理するとなると型に何かしら書かないと行けない。
初期化や型を美しく2つあるいは複数の概念を奇麗に美しくかき分けたい。
var a:Int=1;
var $a:Int=1; // gc管理下の変数とする。
perl,phpから$が付いているとかしたらどうだろう?
動的型というか、変数名にgc管理下にあるかどうかを持たせる。
def add($a:Int,$b:Int):Int = { return $a+$b;}
でも返り値の型が指定出来なさそうで困る。うーん。
727デフォルトの名無しさん:2012/02/18(土) 15:55:02.61
var a:Int = 1 // 値
var a&Int = 1 // 1の参照
var b^Int = a // bのハンドル GC管理
短縮形
var a := 1 // 値
var a &= 1 // 1のポインタ
var a ^= a // bのハンドル
こんな感じで、:以外に変数に演算子を適用するとか。
728デフォルトの名無しさん:2012/02/18(土) 16:10:16.72
>>726
>def add($a:Int,$b:Int):Int = { return $a+$b;}
>でも返り値の型が指定出来なさそうで困る。うーん。

この例では、Intが指定できてるんじゃないの?
729デフォルトの名無しさん:2012/02/18(土) 16:29:34.00
お前らセンス無さすぎだろ

書き分ける -> コンパイラにヒントを与えて最適化の余地 or コンパイル時にエラーチェック or 文法上意味がある

書き分ける意味ってだいたいこのどれかが目的でしょ。
>>726とか俺らが考えないといけないこと増やすだけだし、パフォーマンス上がるわけじゃないし。メリットが一個も無い

そもそも>>712はさ、パフォーマンス気にしないなら全部どれかに統一すればいいじゃん
全部ヒープでいいじゃん

パフォーマンス気にするなら書き分ける必要があって(コンパイラへのヒントってことね)統一なんかできないのよ
統一しちゃったら最適化が利かせづらい
730デフォルトの名無しさん:2012/02/18(土) 16:32:32.88
パフォーマンス気にする必要があるので、書き分ける必要はあるだろうね。
ぜひセンスのある解法を提案してほしい。
731デフォルトの名無しさん:2012/02/18(土) 16:35:35.84
rubyとかで$が必要なのは文法上必要だからな
まあ俺はあれが気に入らないんだけど

globalっていうクラスのをグローバル変数用に使いましょうって言っておくだけで、
グローバル変数なんていう特例作らなくてもいいのにな
せっかくの動的な言語なんだから

そういうの考えたいなら、効率的にアセンブラに落としやすい言語考えようぜ?
クリティカルな関数とかをアセンブラで書くかわりにこの言語を使うのよ

ループの並列化、ベクトル化
とかを主軸にした言語な

出来合いのループ -> 並列化
じゃなくて
並列ループ構文 -> ループを作る

っていう逆転の発想な。fortranとかはそうか
でももう少しインテリジェントにさ、もっと書きやすい

ループに内在する並列性を人間よりもインテリジェントに見つけ出してくれるやつ
732デフォルトの名無しさん:2012/02/18(土) 16:39:38.71
>>730
お前クリティカルなコード書いたこと無いだろ。気にするところが間違ってんだよ
ヒープに取ろうが、スタックに取ろうが、参照渡ししようが値渡ししようが大差ねえから

クロック数と触るメモリのサイズ・・・clock/byteとか
メモリがキャッシュに収まるかどうかとか

そういうほうがはるかに大事だから
ネットワークとかHDDとか絡んだら台無しだしな
733デフォルトの名無しさん:2012/02/18(土) 16:43:05.88
並列ループ構文の案を出してほしい。
OpenMPくらいの機能が構文にうまく組み込まれるといいかもね。
734デフォルトの名無しさん:2012/02/18(土) 16:45:49.31
>>732
ヒープとスタックを区別する必要のないクリティカルなコードを書く用途にも、そうでない用途にも使えるように、
ヒープとスタックは区別できるようにしておきたいね。
735デフォルトの名無しさん:2012/02/18(土) 16:47:14.97
OpenMPくらいじゃ意味ねえだろ。世界中で研究してるでしょ
intelとかはさ、金に直結するわけだし

もっとアルゴリズムまで踏み込んで並列化するようなのが欲しいよな
数学に近いのかな

問題を記述すると、アルゴリズムから考えてくれるような奴

人間が記述しやすくて、コンパイラも理解しやすいようなのが必要だな
736デフォルトの名無しさん:2012/02/18(土) 16:50:23.33
>>735
コンパイラなりオプティマイザなりにそのような処理をさせるために必要な構文をアイディアがあるなら提案してほしい。
737デフォルトの名無しさん:2012/02/18(土) 16:56:17.59
>>736
残念ながらアイデアの手持ちは無い
思いついたら書きこむ

逆に高級言語になるだろうな。メモリにどこからどこまでアクセスするのかとか厳密にコンパイラ側が知ってないといけないから


研究の方向としては
・いろんなアルゴリズムを表現できるコンパクトは構文セット
・さらにその構文セットは変形がしやすい
・同じアルゴリズムを表す別々の二つのコードを、同じ形に変形する方法がある

こんな感じでアルゴリズムを式として表して、その変形で最適化を行えるようになれば
738デフォルトの名無しさん:2012/02/18(土) 17:01:20.56
マージソートとクイックソートとバブルソートが同じアルゴリズムだってコンパイラが認識できたら面白くない?
そしたらコンパイラならではのさ、ハイブリッドソートを作れて。世界最速のアルゴリズムになるかも

そしたら俺が有名になれる。マイクロソフトからさ、そのコンパイラ1億ドルで売らないか?って誘われてさ
739デフォルトの名無しさん:2012/02/18(土) 17:02:54.09
面白いけど、それ言語の話なの?コンパイラの話じゃなくて?
740デフォルトの名無しさん:2012/02/18(土) 17:06:57.06
なんか突然スレが動き出したなw
741デフォルトの名無しさん:2012/02/18(土) 17:24:49.01
多分停止問題に帰着できて不可能って話になりそうな気がするけど
742デフォルトの名無しさん:2012/02/18(土) 17:25:50.68
アセンブラ見せてこれ最適化してよって言ってもアセンブラレベルの最適化しかできないじゃん
C見せて・・・これでもまだアルゴリズムには踏み込めない

でも、整数式はいろいろまとめたりできるわけじゃん
アルゴリズムも数式みたいに扱えるようになったらいいのかなって
そのために言語も変える必要があるなって

数学的には自動証明に近いかも
743デフォルトの名無しさん:2012/02/18(土) 17:26:09.19
>>741
それな。それが心配
744デフォルトの名無しさん:2012/02/18(土) 17:29:53.13
まあ、俺は数学には詳しくないんだけどな
これを機に勉強してみようかなって思ってるんだ
証明論の本買ったし
745デフォルトの名無しさん:2012/02/18(土) 17:41:53.87
>>742
お前はセンスがいいと思うが、数学がダメなのか?

演繹的にプログラムの変形が自由になればプログラムの複雑度を数値化できる。
そうするとステップ数よりもより厳密な工数計算が可能になる。
PGに対する評価も正確になり。
頑張れば報われる世界に近づくと思っている。
746デフォルトの名無しさん:2012/02/18(土) 18:39:00.82
数学数学って、数学ってそんなに怖いものじゃないよw
747デフォルトの名無しさん:2012/02/18(土) 18:49:23.75
数学を使えば何か凄いことができると思うのは高卒プログラマーのよくある妄想
事務職の女子社員が英語で自己実現とか言ってるのと基本的に同じ
748デフォルトの名無しさん:2012/02/18(土) 18:50:23.25
>>747 みたいなのが計算機科学を知らない高卒プログラマーのよくある妄想
749デフォルトの名無しさん:2012/02/18(土) 18:51:40.90
ここで計算機科学に幻想を抱く患者さんの登場
750デフォルトの名無しさん:2012/02/18(土) 18:59:44.26
>>747
言っとくけど俺は高卒じゃねーぞw
俺の格言「些細な夢は必ず実現する」
751デフォルトの名無しさん:2012/02/18(土) 22:10:33.81
夢語りはいいのだが、最低限、「何をしたいのか」を言ってほしい。あとその目的も。

単に「数学を使えば何か凄いことができるぞ」だけなら、全く不毛。続きは数学板でやってください。
752デフォルトの名無しさん:2012/02/19(日) 01:01:29.03
最低限は、Lispのマクロが出来て、ネイティブコンパイラとして複数の型や文字列、
ポインタ操作が一通りできるようにすること。
これは今年中に完成するのが俺の目標。
今年中が無理なら2、3年で完成させたい。
今の作業は、複数の型をコンパイラに入れる事。
作った言語で作りたいのはゲームだったり、言語だったり、ウェブアプリだったりする。
目的はC言語の層をCのような関数型言語(Scala)でパターンマッチを使って
奇麗に実装することだ。
S式の代わりにC式を使ってプログラムをデータとして扱いLisp級マクロも入れる。
この辺の仕組みはすでに出来てる。
式を使う事で構文上の大きな方針が決まる。
新しいC言語はC++のように拡張出来る必要がある。               
だから十分検討した上で構文を決める必要がある。
フロントエンドとバックエンドは別に考える事が出来る。
バックエンドが嫌になったら気晴らしにシンタックスを考えたりしたい。
で、多分どっかの時点で誰かにパクられて、世に広まれば十分だ。
それが俺の手で出来たら大満足だ。
753デフォルトの名無しさん:2012/02/19(日) 02:32:44.40
数学は好きなんだけどさ、大学以降のはちゃんと勉強してなくて
記号ばっかりになって分野も凄い広がるじゃん
記号だけ難しくて実は簡単?って思うと中身も難しいじゃん
ゆっくりしか進まなくてさ。やっぱりガチの数学にはコンプレックスがあるのよ

>>745
それも面白いな

>>752
あんまり魅力を感じないな。言語として新しいのを作るってよりも
自分だけのコンパイラを作ってみよう!っていう日曜プログラマ的な動機?
あと実装の楽さってだけなら関数型言語じゃなくて、PEGでいいんじゃないの?
754デフォルトの名無しさん:2012/02/19(日) 02:46:58.77
>>753
高校卒業レベルまでの数学はただの算術だって中学の先生が言ってたお
755デフォルトの名無しさん:2012/02/19(日) 03:14:25.08
>>745
Cの目的はプログラムの変形ではない
全く逆だ
プログラムの変更なしで移植するのが目的
756デフォルトの名無しさん:2012/02/19(日) 06:28:14.09
>>755
Cを再開発してもしょうがあるまい。
その方向性はCやC++やDに任せておけばいい。
757デフォルトの名無しさん:2012/02/19(日) 09:09:47.65
関係あるか解らんけど、
>2つのラムダ式を入力とし、それらが同値であるかどうかを判定するアルゴリズムは存在しない。これは決定不可能性が示された歴史的に最初の問題である。
ttp://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97
758デフォルトの名無しさん:2012/02/19(日) 15:19:39.25
値が同じかどうかは判定できないから、型が同じかどうかを判定している。
型は「値より弱い」概念だから「強い型付け」などと言っても高が知れている。
これが数学。
759デフォルトの名無しさん:2012/02/19(日) 15:20:59.01
>>753
誰もお前が数学得意だと思っていないし、お前が数学コンプレックスなんだろうことはみんな分かってるから安心しろ。
760デフォルトの名無しさん:2012/02/19(日) 17:18:22.78
lispベースのクズ言語じゃC/C++に代わるはずねぇよw
761デフォルトの名無しさん:2012/02/19(日) 17:27:58.22
まあ、>>752が逃亡しなければ、今年中に完成まで行かなくても、ある程度具体的な仕様は見えるだろうから、
クズと判断するかどうかは、それを見極めてからでもいいだろう。

このスレはこのスレで、>>752とは別に粛々と進めればいい。
762デフォルトの名無しさん:2012/02/19(日) 17:35:23.42
>>758
そういう根拠のない思い込みは全く数学ではないし、科学ですらない。
文学か宗教だ。
763デフォルトの名無しさん:2012/02/19(日) 18:22:59.18
>>762
値が同じならば型も同じ。
型が同じでも値が同じとは限らない。
これが根拠。
764デフォルトの名無しさん:2012/02/19(日) 18:23:46.16
>>753
日曜大工で造れるくらい簡単にすることはとても大変な作業なのですが、
アインシュタインは日曜大工で相対性理論を作ったのです。
Cのマクロを奇麗にすることが1つの目的です。
低レベルな言語にマクロは不可欠です。マクロのないアセンブラは使い物になりません。
マクロ機能ですばらしいのがLispのマクロなのだから、Lispのマクロがあると便利です。
Lispのマクロを実現するにはC言語の言語一族を一般化した式があると非常に便利です。
必要なのはC言語の言語族の良い性質を取り出したS式のような式言語です。
この式言語のパースは正規表現と下降型の演算子順位法が最も短く記述できました。
式を一度構文解析してただの、構文木を作ると演算子で繋がれただけのデータとして扱う事が出来ました。
木を別な木に変換作業がコンパイラの仕事です。
これをどう扱うと奇麗に書けるか調べていくと、関数型言語が良いことが分かりました。
しかし、私が考えているC言語には似ていないのでC言語風な関数型言語を探しました。
結果としてScalaが最もC言語に近い関数型言語であることが分かりました。
パターンマッチは要するにvisitorパターンを言語機能として持っているということでした。
構文解析にとどまらず、コンパイラ全般の記述がきわめて簡単に出来たのです。
今はバックエンドを作っていて動くものが完成したら、シンタックスをいじったり、
GCを追加したり、最適化したりしようと考えてます。
765デフォルトの名無しさん:2012/02/19(日) 18:25:31.47
>>763
     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |
.   /: : : //ヾ ; :|!: イ、||ll|||||::||    ノノ  イ|||||||ヾ、 |: ::|!: : イ: ::|/   な 思 が
   /: : ://: : :ヽソ::ヽl |{ i||ll"ン    ´   i| l|||l"l `|: /|: : /'!/l     ん う
 ∠: : : ~: : : : : : : :丶ゝ-―-      ,  ー=z_ソ   |/ ハメ;, :: ::|.   だ ん
   i|::ハ: : : : : : : : : : : 、ヘヘヘヘ     、  ヘヘヘヘヘ /: : : : : \,|.   ろ な
   |!l |: : : : : : : : :、: ::\    、-―-,      / : : :丶;,,;,:ミヽ   う  ら
     丶: :ハ、lヽ: :ヽ: : ::\__  `~ "      /: : ト; lヽ)   ゝ
       レ `| `、l`、>=ニ´        ,  _´ : :} `   /
         ,,、r"^~´"''''"t-`r、 _  -、 ´ヽノ \ノ   /    お ・
       ,;'~  _r-- 、__     ~f、_>'、_         |  で  前 ・
      f~  ,;"     ~"t___    ミ、 ^'t         |  は  ん ・
      ,"  ,~         ヾ~'-、__ ミ_ξ丶     |  な  中 ・
     ;'  ,イ ..          ヽ_   ヾ、0ヽ丶    l         /
     ( ;":: |: :: ..          .`,   ヾ 丶 !    \____/
     ;;;; :: 入:: :: ::      l`ー-、   )l   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶
766デフォルトの名無しさん:2012/02/19(日) 19:28:58.65
cのコンパイラくらいちょちょっと作れよwww。まっさら状態から一日でできるぞ
関数型言語って何をいまさら。勉強したいわけだな
コード全部晒したらアドバイスするよ
767デフォルトの名無しさん:2012/02/19(日) 19:33:06.35
無意味な煽りは無視していい。
年末までじっくりやれ。

出来たら、出来たでこのスレで評価すればいい。
今はまだ何も無いので評価に値しない。
768デフォルトの名無しさん:2012/02/19(日) 20:03:37.62
>>766
includeをimportに置き換えただけ、みたいな等価な変更なんざ何の価値もないの。
1日でできようが1秒でできようが無意味。
769デフォルトの名無しさん:2012/02/19(日) 20:24:02.76
新言語なんてやる意味ねえよ。
やるならC/C++の上位互換にしとけ。
速度と言語は関係ないし。
C/C++の互換だったら膨大なコードを利用できるし。
関数型やGCが好きだったらC/C++に組み込めばいい。
770デフォルトの名無しさん:2012/02/19(日) 20:26:58.54
速度と言語は関係ないし。
速度と言語は関係ないし。
速度と言語は関係ないし。
速度と言語は関係ないし。
速度と言語は関係ないし。
771デフォルトの名無しさん:2012/02/19(日) 20:31:09.33
PHP互換でも速度は速く出来るし言語は関係ない。
PHPでC++並の速度が出せることは実証されてる。


PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開 2月 3, 2010
http://blog.candycane.jp/archives/275
772デフォルトの名無しさん:2012/02/19(日) 20:34:30.72
言語と、言語に付随するコンパイラは分けて考えろよ。
JavaやC#はC++より遅いっていうのは定説だろうが、
仮想マシーン不要で動作する実行ファイルを生成するコンパイラが出来れば
C++を超える可能性はある。
773デフォルトの名無しさん:2012/02/19(日) 20:38:35.39
IntelがPentiumの回路技術でjavaチップ作れば余裕で超えるでしょ。
774デフォルトの名無しさん:2012/02/19(日) 20:51:13.56
>>771
おいおい、コンパイラに与えられるヒントの量が違うだろ
そこらの普通の言語だと似たりよったりだろうけど
775デフォルトの名無しさん:2012/02/19(日) 21:13:44.59
きっとJVMをハードウェアチップ化すればいい、と言いたいんだろうな。
で「JVMがハード化されること」は「一般論として言語と速度が無関係ではないこと」の反論になるのか?
776デフォルトの名無しさん:2012/02/19(日) 21:33:43.50
>>772 gcjも知らんででかい口を叩かないでもらおうか
777デフォルトの名無しさん:2012/02/19(日) 21:39:09.14
はい、わかりました。
778デフォルトの名無しさん:2012/02/19(日) 21:44:09.51
速度は言語でなくコンパイラの性能、最適化次第。
GCCやVC++やインテルC++では速度差があるだろ。
779デフォルトの名無しさん:2012/02/19(日) 21:46:17.15
言語によって、コンパイラが性能の出しやすさ、最適化のしやすさに違いは当然ある。
780デフォルトの名無しさん:2012/02/19(日) 22:07:58.40
GCとポインタをなくせば速くなると思う。
そのためにはコンパイラを変えるより言語を変えるのが簡単だ。
781デフォルトの名無しさん:2012/02/19(日) 22:12:15.50
>>780 gcもポインタもあることによって速くなるんだけどね。
ポインタでデータコピーのオーバーヘッドを削れる
gcによって逐次解放のオーバーヘッドを減らし、後でまとめて解放する際に
賢いアルゴリズムを用いる事ができる。
782デフォルトの名無しさん:2012/02/19(日) 22:16:10.75
ちいせえレベルで語ってんじゃねえよ

速い言語なら、c++もしくは人力アセンブラより速くないと意味が無い
使いやすい言語なら、C#より使いやすくないと意味が無い
783デフォルトの名無しさん:2012/02/19(日) 22:22:38.82
>>782
レジスタ、一次キャッシュ、二次キャッシュ、HDD、のそれぞれの速度差
パイプラインの隅々までクロックサイクル単位で考慮する
最適化人間の俺様による人力アセンブラより早いのは無理。
784デフォルトの名無しさん:2012/02/19(日) 22:40:01.39
>>781
関数はコピーも解放もしないから、関数ポインタはないほうがいい
Singletonもコピーしない
コピーしないものは結構多い
785デフォルトの名無しさん:2012/02/19(日) 22:44:22.06
だめだこりゃ
Singletonはポインタを各所に持つことで実体を共有してるんだぜ。ポインタが無かったら成り立たない。
関数のポインタも必須。
786デフォルトの名無しさん:2012/02/19(日) 22:49:41.34
>>778
言語仕様の影響がないなんてありえないよ

例えばC言語ではポインタがあるから
別名解析が極めて困難になっている。それに伴って
最適化も限定的にしかできなかったりする
Intel C/C++も解析できない部分はプラグマや拡張構文に頼る

一方でポインタはCの強力な武器であって
むしろポインタを使って手作業で最適化という事もよく行われる
コストはかかるが、それが実現できるというのがCの偉大な所

どちらを取るか、あるいはどうバランスさせるかというのは難しい問題
理想的には、コンパイラの最適化が効きやすいが、
そうでないケースも必要があれば手作業で「なんとかなる」のが良い
787デフォルトの名無しさん:2012/02/19(日) 23:11:54.17
>>785
具体的にどこでポインタが必須なのか分かってるなら、
それ以外の場所で、ポインタがいらない所が結構多いってことも分かるだろ。
788デフォルトの名無しさん:2012/02/19(日) 23:26:04.86
>>786
どうもヴィルト先生が、「最適化の話と言語仕様の話を混同しちゃいかんよ」と言ってるらしいのだが、
それをどうも拡大解釈して、言語仕様は最適化に関与しない、と誤解してる人がいるらしいのだ。
789デフォルトの名無しさん:2012/02/20(月) 00:23:53.91
最適化というのはプログラマーの意図により近づけることだから、
最適化に適した言語仕様とは、プログラマーの意図をより正確に記述できるものである。
790デフォルトの名無しさん:2012/02/20(月) 02:13:36.20
そんなことはないと思うけどね
最適化は単に与えられたアーキテクチャの都合に合わせてプログラムを変形するだけ
レジスタが今何個使えるかとか、Cレベルですらほとんど意識しなくても
悪くない効率のプログラム書けるでしょ

最適化コンパイラはグラフ彩色法とかを使って頑張るわけだが、
そこにプログラマの意思はない
791デフォルトの名無しさん:2012/02/20(月) 04:41:23.25
ポインタ必須厨はもっと勉強したほうがいい
速度重視のためにポインタを使用しない言語を作れないこともないだろ
792デフォルトの名無しさん:2012/02/20(月) 05:00:43.49
>>783
おいおい、お前visual c++の浮動小数点の最適化に勝てるか?
有る程度長いコードな。マジ無理だから
793デフォルトの名無しさん:2012/02/20(月) 05:02:21.39
C++のコンパイラがキャッシュに収まらないから自動的にブロック化とかするか?
fortranならできる。言語による速度の違い
794デフォルトの名無しさん:2012/02/20(月) 08:24:39.10
LLVMがあるからもういいだろ
795デフォルトの名無しさん:2012/02/20(月) 08:34:32.99
コンピュータによる最適化はな、ちゃんとヒントさえ与えてあれば人間よりも賢くやるんだよ
それこそ、パイプラインだのなんだのって最近のCPU人間が把握するには複雑すぎんじゃん
でもなんで人間がコンピュータに勝つかって言えば、アセンブラを見て何をやっているコードが分かるからなんだよな
一歩引いた視点から最適化できる

コンピュータにうまくヒントを与えることさえできれば、人間が勝てなくなるかも
そういうコンテスト開いたらどうかな。最適化コンテスト
チェスみたいにさ

コード食わせて最適化して実行速度で勝負
世界中のハッカーが手書きアセンブラで乱入
人間vsコンピュータっていうさ
796デフォルトの名無しさん:2012/02/20(月) 08:41:39.49
> 最適化というのはプログラマーの意図により近づけることだから、

前提がそもそもおかしい。てかバカか?

プログラマの意図から一切外れてはいけない、というのが処理系における大前提。
そのうえで、可能であれば効率の良いコードを生成する、というのが最適化。
797デフォルトの名無しさん:2012/02/20(月) 08:43:16.54
とらんすぺあれんしーな
798デフォルトの名無しさん:2012/02/20(月) 09:17:06.90
最適化で最適になると勘違いしている奴が多すぎ。何人バカを見たことか。
せいぜい「快適化」が妥当。
799デフォルトの名無しさん:2012/02/20(月) 09:23:42.34
↑C言語を「高級アッセンブラ」とか称して、プログラマはアセンブリ言語を意図して書くべき、
とか思ってるバカ?
800デフォルトの名無しさん:2012/02/20(月) 10:47:42.21
LLVMで実行時のプラットフォームに合わせてコードを変更すべきだ
例えばCPUのプロセッサ数、コア数、NumaなのかSMPなのか、などなど

アセンブラで禁じ手とされてきた自己変更コードが今や管理できる対象に
801デフォルトの名無しさん:2012/02/20(月) 11:04:15.45
コンパイラのコード最適化も、CPUの仕組みとかを利用した
手作業の最適化をする職人さんから見たら大したレベルでは
ないよ
802デフォルトの名無しさん:2012/02/20(月) 11:04:58.23
>>799
でも、ここはそういう趣旨が含まれているスレだろ
スレタイ的に
803デフォルトの名無しさん:2012/02/20(月) 11:36:35.58
>>801
NP完全問題解決職人の朝は早い、っていうギャグですかそれはw

>>802
そういう趣旨ならANSI標準化以後のC、ましてやC++なんて目もくれないはず。
C言語の欠陥として、マシンスタックに触れないとか、関数をまたぐgotoができない、
といったことを把握していて、gcc拡張などでそういう制限を突破する方法を熟知。

まずはそういうレベルに達してから四の五の言えと。
804デフォルトの名無しさん:2012/02/20(月) 11:45:24.31
>>795
チェスは人間対人間のデータがヒントになってるんだろ
まず人間だけでデータを蓄積するべきじゃないか
805デフォルトの名無しさん:2012/02/20(月) 17:51:09.33
>>803
NP完全問題だから何?
人の創造力でコンパイラができない最適化が可能だと考えられないの?
そもそも、保守的なコンパイラの最適化なんて人が直接行った最適化に勝てるとか思ってるの?
806デフォルトの名無しさん:2012/02/20(月) 18:05:12.99
>>805
だからお前はずるしてんだよ。コンパイラはお前よりずっと少ない情報量で頑張ってる
そこでだよ、コンパイラにも同等の情報を与えられないかって考える

openmpとかはさ情報与える手段のひとつよ。でもしょぼいじゃん
アルゴリズムを創造するレベルにはいたらないじゃん
なんか新しいの考えようぜ
807デフォルトの名無しさん:2012/02/20(月) 18:06:27.04
>>804
おう、人間がアルゴリズムを考えるときにやることっていうのを書き連ねてみるのな
そこにヒントがあるかもしれない
808デフォルトの名無しさん:2012/02/20(月) 18:20:57.42
コンパイラのコード生成に乗らないようなすごい命令作りましたー、っていうCISC原理主義者ですかw
809デフォルトの名無しさん:2012/02/20(月) 18:40:06.30
コンパイラよりもアセンブラ手書きの方が速いなんてアタリマエのことだろ
まあ、有名な本とかでも誤解させるような言い回しをしていることも多いけど
アセンブラがコンパイラのコードに負けるなんて、C言語がJavaより遅いという
のと同レベルの議論だぞ
810デフォルトの名無しさん:2012/02/20(月) 19:29:45.32
お前のレベルが30年前
811デフォルトの名無しさん:2012/02/20(月) 19:35:15.72
お前こそ、本とか人の話を鵜呑みにして信じているだけ
いまでもアセンブラが最速
812デフォルトの名無しさん:2012/02/20(月) 19:36:01.51
実行プロファイルを利用した最適化を超えるほど
完璧に最適された手書きアセンブラを想定するなら速くてアタリマエ
813デフォルトの名無しさん:2012/02/20(月) 20:05:38.71
利用できるものは全部利用しないと完璧とはいえないな
814デフォルトの名無しさん:2012/02/21(火) 00:20:20.77
費やす時間が無限なら人間が最強に決まってる
815デフォルトの名無しさん:2012/02/21(火) 13:23:28.33
えー時間は無限でも寿命は有限じゃん・・・とくだらない揚げ足をとってみる
816デフォルトの名無しさん:2012/02/21(火) 13:42:12.33
揚げ足にすらなってないな。会話が通じないやつ
817デフォルトの名無しさん:2012/02/21(火) 15:22:01.08
速度と言語は関係ある。
だから機械と人間は連携している。勝負しているのではない。

ただ、連携を意識させるべきではないという透過性の思想もあって
それを誤解して、連携してないし強い方だけが生き残ると思ってる人がいる。
818デフォルトの名無しさん:2012/02/21(火) 19:14:10.14
連携、というのは対称性があって良い
みんな抽象とか具象とか言うけど非対称で気持ち悪い
819デフォルトの名無しさん:2012/02/21(火) 20:03:23.73
大工が屋根は始めからあるべきというようなもの
そりゃー仕事なくすだろ
820デフォルトの名無しさん:2012/02/21(火) 21:57:27.07
一階の屋根は二階の床
821デフォルトの名無しさん:2012/02/23(木) 11:23:09.17
ドメイン固有型を構築する記法
822デフォルトの名無しさん:2012/02/25(土) 02:22:21.57
超高速BASICインタープリターの復活まだ?
見た目は中間言語方式だが解読などせずに、中間言語バイナリーが
実行CPUの命令語で直接表現されているタイプだ。

つまりアセンブラと同等の速度で動く。
823デフォルトの名無しさん:2012/02/25(土) 04:19:05.11
でかい釣り針だな
824デフォルトの名無しさん:2012/02/25(土) 08:59:36.47
いるんだよ、天然でこういうバカ
825デフォルトの名無しさん:2012/02/25(土) 09:55:36.43
Implicit conversion is difficult now...
826デフォルトの名無しさん:2012/02/25(土) 10:11:46.12
clay, cyclone, decac, rust, bitCといったsystem programming languageを標榜しているものが沢山勃興している件について。
このスレじゃるrust以外は言及もされてないが、需要はあるんだと思うよ。
827デフォルトの名無しさん:2012/02/25(土) 16:20:26.20
以前のスレで言及されてたよ
828デフォルトの名無しさん:2012/02/25(土) 16:24:37.06
つまり動作だけじゃなくて、CPUに与える命令までをも自由にいじくれる言語か

Cで表現できるプログラムと、アセンブラで表現できるプログラムの集合は同じだけど
生成される命令列の集合は一致しない

それを一致させて、しかも書きやすい言語か
829デフォルトの名無しさん:2012/02/25(土) 17:01:33.96
それを抽象的にプラットフォーム依存性なく記述できれば尚いい。
830デフォルトの名無しさん:2012/02/25(土) 17:08:18.07
>>828
同じじゃねえよ全然
反論は UNIX を完全に C だけで書いてからぬかせ
831デフォルトの名無しさん:2012/02/25(土) 17:21:38.31
>>830
それは>>828のレスの大意に影響することか?
832デフォルトの名無しさん:2012/02/25(土) 17:25:02.85
集合とか言いながら定義の曖昧な意味のよくわからない書き込み
833デフォルトの名無しさん:2012/02/25(土) 17:51:04.22
プラットフォーム依存性なく記述出来るのは
その下(処理系)で吸収する手があるけど、それは最大公約数的になってしまう
そして溢れた部分は同階層(ライブラリ)で吸収したりするよね

そんで、ライブラリに出来る幅を広げるため
コンパイル自体に介入して言語を拡張する機能を内包してるといいと思う
例えば「ソース内にインラインアセンブラを書けるようにする」処理を書けるとか

lispとかはそんな感じのこと出来るんだっけ?


//その言語で関数とか書いて
void asmPlugin(Compiler cp){
cp.getParser().addBlockKeyword("_asm", new AsmParse() );
}

//コンパイラに取り込んでもらうと
compile_plugin asmPlugin;

//拡張構文が書けるようになるとか
_asm{
...
}

この場合、asmPlugin関数がコンパイル途中で実行可能になる必要があるから
ブートストラップ問題にならないよう、ファイル分けたりフェーズ分けたりするのが必要だと思うけど
834デフォルトの名無しさん:2012/02/25(土) 18:33:00.25
>>833
ファイルを分けるのは既存のやり方と同じ。
cのファイルとasmのファイルに分けるなら拡張構文は不要だ。
835デフォルトの名無しさん:2012/02/25(土) 18:52:31.28
逆にファイルを分けないとすると、Pascalはそんな感じだっけ
836デフォルトの名無しさん:2012/02/25(土) 18:56:05.00
今はCPUの保護機能のせいで、データと命令が分離されてデータを
命令として実行できないとか聞いたことあるような気がする
837デフォルトの名無しさん:2012/02/25(土) 18:57:22.09
function test(a: Integer): Integer
begin
 Result := 2 * a;
end;

function test(a: Integer): Integer
asm
 add eax, eax;
end;

で終りやで。すばらしいのよ
前後に追加されるのは、retのみ
838デフォルトの名無しさん:2012/02/25(土) 19:47:36.34
分割はカッコ悪いという価値観が、ある程度普及しているのは間違いないと思うが
いつどこから広まったんだろうか
839デフォルトの名無しさん:2012/02/26(日) 00:05:00.75
>>834
ファイルを分けるってのはコンパイラ用プラグイン部分のことね
例えばC言語ならCで、JavaならJavaで記述出来て、
先にコンパイルされてコンパイラにプラグインとして入りこんで
メインのソースのコンパイルする際に動くってことで

別途拡張したコンパイラを用意しなくても
その言語自身で、コンパイル時に言語をある程度拡張出来れば
別途コンパイラを用意する必要もなく、
boostみたいにプリプロセッサを酷使せんでも色々出来そうだし
VC++とgccで独自のインラインアセンブラ機能付けなくても
boost作成メンバーみたいなのが作ったソースとかをincludeするだけで出来るとか
言語仕様を変えることなく、後付けてリフレクション機能を付けたりとか

いや、言語設計とか初心者レベルなんだけどね
そんなこと出来たらいいな的な
840デフォルトの名無しさん:2012/02/26(日) 00:07:01.67
何か2回ほどコンパイラを用意とか言った気がするけど脳内添削してください
841デフォルトの名無しさん:2012/02/26(日) 01:02:07.61
つまり、言語自身で想定した環境の外に別途環境が用意され言語が酷使されるような
ことが起きないようにするのが目標か
842デフォルトの名無しさん:2012/02/26(日) 01:09:27.03
面白いな、コンパイラコンパイラ と コンパイラを一緒にしちゃうのか?
冒頭に言語仕様を書いておくっていう
それをフレキシブルに拡張できるっていう
843デフォルトの名無しさん:2012/02/26(日) 02:16:06.07
それって、lisp系の言語のマクロじゃね
844デフォルトの名無しさん:2012/02/26(日) 05:22:03.59
マクロみたいな制限やデメリットがない
845デフォルトの名無しさん:2012/02/26(日) 06:31:08.63
マクロだって原理的にはチューリング完全だよ
846デフォルトの名無しさん:2012/02/26(日) 08:16:38.55
とおりすがりでごめんなさいね
>4
に書かれている名称は随分昔に
PL/I って言語で存在してますので不都合が生じるかもしれません
847デフォルトの名無しさん:2012/02/26(日) 13:38:05.72
>846
>3-8 のテンプレ自体がネタだからw
848デフォルトの名無しさん:2012/02/26(日) 13:49:29.74
c言語のコンパイラをlispのマクロで書けたりするの?
lispのマクロ使ったことないからわからん
849デフォルトの名無しさん:2012/02/26(日) 13:53:18.31
850デフォルトの名無しさん:2012/02/26(日) 14:03:32.88
コンパイラを書くことが目的ではなく
C言語のソースとLispのソースを一つのファイル内に書くことが目的なのだと思うよ
851デフォルトの名無しさん:2012/02/26(日) 15:49:18.64
>>849
面白い。GJ!
852デフォルトの名無しさん:2012/02/26(日) 16:13:24.31
>>846 こんな頭の悪そうなスレを立てたり、ハシャいでぼくのかんがえたさいきょう言語を
披露しちゃうような奴は、たいてい過去を学んでいないものだ。
853デフォルトの名無しさん:2012/02/26(日) 17:19:20.84
まあいいじゃないか視野と行動力は反比例の関係であるみたいだし。
854デフォルトの名無しさん:2012/02/28(火) 00:18:09.34
>>846
Programming Language I は「あいげんご」あるいは、単に「あい」と呼ばれる。
PL/Iは「ぴーえるわん」と呼ぶから困ることはないよ。
855デフォルトの名無しさん:2012/02/28(火) 04:37:34.64
何その錆びた釣り針
856デフォルトの名無しさん:2012/02/28(火) 18:18:27.40
急増する「女ネット右翼」の背景

昨年8月の「フジテレビデモ」の頃からでしょうか。
 現実のデモだけではなくネット上でも、こうした「ネット右翼」と呼ばれる層に明らかな変化(それも「急変」と言ってよい程の大変化)が起こりました。
具体的に言えば女性、それも特に子供を持つ既婚女性の急増という大変化です。

韓国朝鮮人への敵意や嫌悪感、それも「もうとにかく嫌! 生理的に受け付けない!」とか「韓国人は近付かないで! 気持ち悪い! 吐き気がする!」といった類の、
私のような男性とは明らかに異なる、極めて生理的・感覚的なレベルでの韓国・朝鮮人への嫌悪感を剥き出しにした投稿が急増しているように思えます。

それにしてもなぜ急に、ここまで日本人女性の韓国・朝鮮人に対する嫌悪感が盛り上がってきたのでしょうか。昨年の「高岡蒼佑のツイッター」騒動が
発端になっていることは間違いありませんが、それはあくまでも一つの「きっかけ」に過ぎず、そこに至るまでには長い不満の積み重ねがあったものと思われます。

「人権擁護法案が通ると、日本女性が韓国男達・在日韓国男達からレイプされて明らかに犯人が分かっており警察へ訴えても
『俺が在日韓国人・韓国人だからそんなことを言うのだろう!』
と言われたら、日本の警察も司法も社会も一切韓国男達・在日韓国男達に手出しは出来ず、レイプされても単なる泣き寝入りになると。
要するに日本女性の訴えは完璧にレイプ犯が分かっていても完全無視され、韓国男達・在日韓国男達が徹底的に無罪として日本で守られると。
日本社会は韓国男達・在日韓国男達が日本女性を合法的に好き放題レイプすることが出来てしかもそれが罪に一切問われない社会になる」

迂闊でした。

確かに彼女らの怯えるとおり「人権侵害救済法案(旧名『人権擁護法案』)」が万々一にも成立してしまった場合、
真っ先にその犠牲になるのは彼女たち日本人女性なのです。
そして世界一日本人女性に妄執する韓国男どもは「法律が出来たら、日本女を強姦し放題だぜヒャッハー!!」とばかり、股間を膨らませ、
涎を垂れ流しながら法案成立の時を今か今かと待ち構えているのです。

http://ameblo.jp/issuikai/entry-11170747316.html

857デフォルトの名無しさん:2012/02/28(火) 18:44:52.88
一水会大丈夫か?
もはや沈没しつつある「行動する右翼」たちに巻き込まれて沈んじゃうぞ、気をつけないと。
858デフォルトの名無しさん:2012/03/02(金) 20:59:27.69
>>849
広まって欲しいな
859デフォルトの名無しさん:2012/03/02(金) 21:50:38.32
広まることはない
「C系の言語に慣れたユーザー」にとって変換されたコードは可読性が悪すぎる
860デフォルトの名無しさん:2012/03/02(金) 22:30:15.06
まあC++1xがあればいいか
861デフォルトの名無しさん:2012/03/02(金) 22:31:19.17
次はもっとこの関数型のパラダイムをふんだんに盛り込んで欲しいな
862デフォルトの名無しさん:2012/03/02(金) 23:25:09.77
関数型と手続型は混ぜると可読性が落ちるから
もうお腹いっぱいだわ
863デフォルトの名無しさん:2012/03/03(土) 05:46:21.60
関数言語厨は、関数言語自体は大昔からあるのに
どうして広まっていないのか考えたほうがいいよ
864デフォルトの名無しさん:2012/03/03(土) 05:48:04.39
反原発左翼と一緒だな
865デフォルトの名無しさん:2012/03/03(土) 06:39:56.18
原発右翼の方が頭おかしいだろ
866デフォルトの名無しさん:2012/03/03(土) 07:41:13.89
自然エネルギーは広まってない広まってない、と呪文のように繰り返す、
原発脳と同じですね。
867デフォルトの名無しさん:2012/03/03(土) 08:17:08.85
お好みのスレへどうぞ

原発スレ検索
http://find.2ch.net/?STR=%B8%B6%C8%AF
868デフォルトの名無しさん:2012/03/03(土) 19:24:54.81
関数型言語は、処理を単一の値を媒介しつつ記述しなければならない。
手続型言語は、処理を機能として記述する。

C/C++は処理の記述が目的なんだから
そういう目的ならば、関数型言語が劣るのは自明。

関数型言語はそもそも目的が異なるのだから
無理に混在させたり置き換えたりするものではない。
869デフォルトの名無しさん:2012/03/03(土) 19:43:04.75
HaskellはC++と同じくらい使いにくい
OCamlはC++より使いやすい
870デフォルトの名無しさん:2012/03/05(月) 14:03:21.88
無理に混在させるんじゃなくて、奇麗に統合されていると嬉しい。
マクロ自体は関数型であろうがなかろうがあったら便利だ。
型推論もあったら便利。
パターンマッチングもあったら便利。
immutableな変数もあったら便利。
末尾再帰最適化もしてくれたら嬉しい。
便利な機能がそろっていつつ、作りが簡単で高速に動いたら最高だ。
871デフォルトの名無しさん:2012/03/05(月) 16:57:55.17
末尾じゃない再帰もアンロールしろよ横着しねえで
872デフォルトの名無しさん:2012/03/05(月) 17:39:23.66
PL/Iのスレ?
873デフォルトの名無しさん:2012/03/05(月) 18:22:10.12
もう、Camlと強力なプリプロセッサがあればいいんじゃね。
874デフォルトの名無しさん:2012/03/05(月) 19:32:44.46
全ての再帰はループに置き換えられる。
末尾再帰最適化だけなんて思考停止も甚だしい。
875デフォルトの名無しさん:2012/03/05(月) 20:00:10.13
>>874
中間結果どこに置く気だ?
その場でスタックもどきを作るような変換は「最適化」とは呼ばん。
876デフォルトの名無しさん:2012/03/05(月) 20:17:24.75
874じゃないけど

void f(int n){
  if(n<=0){return;}
  int* p = new int(n);
  f(n-1);
  delete p;
}

 ↓最適化

void f(int n){
  for(; !(n<=0); n--){
    int* p = new int(n);
  }
}

富豪的最適化
メモリは16EiBあって当然
877デフォルトの名無しさん:2012/03/05(月) 20:38:53.57
>>875
まあそんなに顔真っ赤にするなや。
Cやjavaに言えることで他の言語の事は知らないけど
関数呼び出しのオーバーヘッドは10回ループするよりデカイ。
>>876
解放し忘れてるし。
878デフォルトの名無しさん:2012/03/05(月) 21:21:58.28
実際、テンプレートの再帰とかあるわけだし

// スタックがどうたらって、アンロールの本質が見えてねえな
879875:2012/03/05(月) 22:23:04.05
>>876
スワップで死ねるよね…てか、中間結果いらん例やん(´・ω・`)

>>877
>まあそんなに顔真っ赤にするなや。
別に。何? 否定されて悔しかった?
>関数呼び出しのオーバーヘッドは10回ループするよりデカイ。 
気のせい。
880ループ厨:2012/03/05(月) 23:52:29.99
うへ、再帰厨ってのが確かに存在する事がわかった。
881デフォルトの名無しさん:2012/03/06(火) 03:42:08.91
後学のためにクイックソートをループでやってみてくれ。
882デフォルトの名無しさん:2012/03/06(火) 04:31:39.52
再帰はループに置き換えられる。
883デフォルトの名無しさん:2012/03/06(火) 04:53:02.68
夢のような欲張り言語がリリースされたらしいよ。julialangでググると出てくる。
884デフォルトの名無しさん:2012/03/06(火) 06:05:11.28
すべての再帰をループに置き換えるのは難しいだろ
885デフォルトの名無しさん:2012/03/06(火) 06:27:49.49
えっ
886デフォルトの名無しさん:2012/03/06(火) 06:30:20.47
泣きながら実験したら再帰と互角だった。ただしループの方は改良してある。
ループ time=172 (10000個のランダムの数字を100回ソート)
再帰 time=188 (10000個のランダムの数字を100回ソート)
887デフォルトの名無しさん:2012/03/06(火) 06:33:02.77
再帰
public void quickSort(int[] a,int left,int right0){
int pivot=getPivot(a,left,right0);
int right=right0;
right=group(a,left,pivot,right);
if(left+1<right && right!=right0)quickSort(a,left,right);
if(right+1<right0)quickSort(a,right,right0);
}
888デフォルトの名無しさん:2012/03/06(火) 06:33:29.61
ループ
public void loopQuickSort(int[] a,int[] arm){
int left=0;
arm[0]=a.length;
int depth=0;
int pivot;
while(true){
int right=arm[depth];
if(verbose)System.out.println("["+left+","+right+"]"+depth);
if(left+1<right){
pivot=getPivot(a,left,arm[depth]);
right=group(a,left,pivot,arm[depth]);
if(verbose)show(a);
if(verbose)System.out.println("pivot="+pivot);
}
if(left<right && arm[depth]!=right){
depth++;
arm[depth]=right;
}else{
left=arm[depth];
depth--;
if(depth<0)break;
}
}
}
889デフォルトの名無しさん:2012/03/06(火) 06:34:20.08
これらが呼んでいる共通の関数

public int getPivot(int[] a,int start,int end){
int pivot=0;
for(int i=start;i<end;i++){
pivot+=a[i];
}
return pivot/(end-start);
}
public int group(int[] a,int left,int pivot,int right){
for(int i=left;i<right;i++){
if(a[i]>pivot){
if(i==right-1 && a[i]<a[right-1]){
right++;
break;
}
int n=a[--right];
a[right]=a[i];
a[i]=n;
i--;
}
}
return right;
}
890デフォルトの名無しさん:2012/03/06(火) 06:36:49.26
すまん再帰の方がかっこ悪かったのでリファクタリング
public void quickSort(int[] a,int left,int right){
int pivot=getPivot(a,left,right);
int middle=group(a,left,pivot,right);
if(left+1<middle && middle!=right)quickSort(a,left,middle);
if(middle+1<right)quickSort(a,middle,right);
}
891876:2012/03/06(火) 10:03:14.42
>>877
メモリ使い捨てというネ(ry

>>879
中間結果のpは本来必須だろw
892デフォルトの名無しさん:2012/03/06(火) 11:59:00.50
>>886-890を動かしてみたかったけど挫折
呼び方間違えたのかもしれない

再帰
http://ideone.com/Rmnvx
ループ
http://ideone.com/PQuTK
ループ(チェック無し)
http://ideone.com/1Wnk8
標準ライブラリ
http://ideone.com/X89Z3
893デフォルトの名無しさん:2012/03/06(火) 12:54:26.43
動かしてないコードを溜め込むやつは強力な静的型付けを欲しがる
溜まる前に動かすやつは動的型付けで満足できる
894デフォルトの名無しさん:2012/03/06(火) 15:09:27.22
すみませんコードが冗長でした。
public int group(int[] a,int left,int pivot,int right){
for(int i=left;i<right;i++){
if(a[i]>pivot){
int n=a[--right];
a[right]=a[i];
a[i]=n;
i--;
}
}
return right;
}
895デフォルトの名無しさん:2012/03/06(火) 15:31:02.89
動かすコードならideoneに貼れよ
896デフォルトの名無しさん:2012/03/06(火) 16:24:49.22
再帰をループに置き換えただけではアンロールになってない
ループの回数を特定してインライン展開までやらないと中途半端だ
897デフォルトの名無しさん:2012/03/06(火) 16:39:10.19
一番重要なのはスタックを片付けるかどうかだろ
898デフォルトの名無しさん:2012/03/06(火) 17:15:47.81
そんなのプロローグとエピローグに全部まとめるだけ
899デフォルトの名無しさん:2012/03/06(火) 19:53:03.45
組み込みやってると再帰なんて怖くて使えない
900デフォルトの名無しさん:2012/03/07(水) 01:17:49.55
じゃあ使うなよw
901デフォルトの名無しさん:2012/03/07(水) 10:30:16.97
合理的な理由があって使わないのは自由なんだが、グローバル変数を多用する理由付けとか
として「再帰使わないから」とか言い出す奴がいたりするのがこの業界の厄介なところ。
902デフォルトの名無しさん:2012/03/07(水) 11:51:23.08
「コンパイルが通れば安全」と言う奴と
「コンパイラが許しても俺は許さない」と言い出す奴が同居しているのが厄介だな
903デフォルトの名無しさん:2012/03/07(水) 18:52:07.47
コンパイルが通っただけじゃぜんぜん安全じゃない、ということがわからない奴がいるからな。
904デフォルトの名無しさん:2012/03/07(水) 18:56:06.72
通ったか通っていないかの区別もつかないアホ多いしな
905デフォルトの名無しさん:2012/03/07(水) 18:56:20.10
コンパイルが通ることと安全かどうかは全く別の話だからな
906デフォルトの名無しさん:2012/03/07(水) 19:37:56.16
そもそも安全じゃない奴と同居しているのが問題だからな。
907デフォルトの名無しさん:2012/03/07(水) 19:39:58.86
洩れ、Vzのマクロっぽい言語でバイナリ吐く perlスクリプト使っているけど、
ちょっとしたDOS向けCOMファイル作るのには便利〜♪
908デフォルトの名無しさん:2012/03/08(木) 14:13:33.93
言語仕様から書けるっていうメタ言語が欲しいな
そして言語同士をフレキシブルにつなげられるのよ

言語仕様と中身が混在してる。というか本質的に区別がつかないようなエレガントな言語をさ
909デフォルトの名無しさん:2012/03/08(木) 18:59:58.67
悪くは無いと思うけど、
混在している時点でエレガントじゃないだろ。
910デフォルトの名無しさん:2012/03/08(木) 19:05:39.56
>>909
人間が見ると混在してるように見えるけど、コンピュータ側から見ると言語仕様の定義も実際のコードも同じルールで裁くのよ
全ての言語を表現できる最強の言語みたいな感じ?
911デフォルトの名無しさん:2012/03/08(木) 19:22:03.74
>>833-845のあたりの話をさらに汎用にした感じか
でもあまり広げすぎるとコンパイラ作成ツールキットだけ渡されそうなw
912デフォルトの名無しさん:2012/03/08(木) 20:12:37.11
伝統的にはyacc/lexとかの守備範囲ですね。
文法を定義して、ある言語を別の言語に翻訳する、
というシステム自体が実はチューリング完全だったりします。
(あまり「低級」な話ではないので、ややスレ違いか…)
913デフォルトの名無しさん:2012/03/09(金) 01:53:58.62
構文解析はコンパイル時の処理だから実行時の性能に影響を与えない点で低級と言えるし
言語自体をアセンブルする点でも低級と言える(メタ言語と言ってしまうと高級な感はあるが)
914デフォルトの名無しさん:2012/03/09(金) 15:29:57.79
boost/spiritの出番ですね
915デフォルトの名無しさん:2012/03/10(土) 18:08:22.75
ノScalaとパーサコンビネータとコンパイラプラグイン
916デフォルトの名無しさん:2012/03/10(土) 19:08:38.12
それらをどう整理・再設計するかだな
917デフォルトの名無しさん:2012/03/11(日) 22:37:27.10
そろそろプログラミングはコンピュータにやらせないか?
人間はミスが多すぎる。
918デフォルトの名無しさん:2012/03/12(月) 00:13:43.58
できるならそうしたい
プログラミングめんどい
919デフォルトの名無しさん:2012/03/12(月) 00:31:42.99
では人間様は何をすればよろしいか
920デフォルトの名無しさん:2012/03/12(月) 00:33:50.60
アニメ、映画みたいなことが今出来るとでも言ってるのかね?917は
921デフォルトの名無しさん:2012/03/12(月) 01:45:12.48
>>917
スレタイによれば、このスレの目的は、高速に実行すること。
プログラマが楽をすることではない
922デフォルトの名無しさん:2012/03/12(月) 01:49:17.09
いかにも中二な発想だよな。
923デフォルトの名無しさん:2012/03/12(月) 02:10:50.77
プログラマが楽をすることをめざしているのは、Rubyだ
924デフォルトの名無しさん:2012/03/12(月) 02:17:41.27
「public static void mainなど、コンピュータに伝える約束事が多くて、
やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」
http://toro.2ch.net/test/read.cgi/tech/1326687331/57
925デフォルトの名無しさん:2012/03/12(月) 05:44:32.75
誰かRubyのコンパイラ書いてくれ。VMとか使わないで動くやつ。そしたら本気で使う。
926デフォルトの名無しさん:2012/03/12(月) 12:50:42.58
>>917
そろそろって今までどうだって言いたいんだ?

昔、コーディング用紙でハンドアセンブルしてて確かにミスが多くて困った
それでアセンブラを自作とかはしたぜ

コンパイラがあってアセンブラがないという変な環境でもアセンブラを自作した
コンパイラが出力するバイナリに不満だらけだったからだ

人力と機械化は相互補完的なものってことだ
927デフォルトの名無しさん:2012/03/12(月) 16:16:15.92
最近、ネイティブなバイナリを吐く言語が減ったね
928デフォルトの名無しさん:2012/03/12(月) 16:28:54.19
減ってはいないだろ
他が増えたから割合が小さくなってるが。
929デフォルトの名無しさん:2012/03/12(月) 16:56:45.99
ABIがうざいからVMの割合が大きくなる
ABIをうざいと思わないやつは多分C言語に慣れていて不満も感じていない
930デフォルトの名無しさん:2012/03/12(月) 18:26:57.82
プログラミングをコンピュータに任せられるようになると
プログラミングで食ってる人はむしろ苦しくなる気がするw
931デフォルトの名無しさん:2012/03/12(月) 18:43:27.29
C に慣れると ABI に無関心になるって?

それは C に慣れたんではなく単一 ABI で
いつもまっさらのシステムに慣れただけだろ
慣れたというより、その域を出られないままとでも言うべき
932デフォルトの名無しさん:2012/03/12(月) 18:48:30.58
>>930
設計とテストだけ書いて、あとは全部おまかせ出来たら超便利そうなんだが。
933デフォルトの名無しさん:2012/03/12(月) 19:03:19.52
機: エラー。その設計は矛盾している。
機: エラー。テストが発散している。
機: エラー。○月△日までに修正しろ。
人: まさか、そんな・・・
機: 交信終了。
934デフォルトの名無しさん:2012/03/12(月) 19:43:56.59
>>931
最初の一つに慣れるのが大変なんだよ

二つも三つもあって困るというのは、技術的にはかなり慣れていて
政治的な問題に関心が移っている
935デフォルトの名無しさん:2012/03/13(火) 00:54:04.56
>>921
ハードワイヤードではなく、わざわざ言語を作(ってソフトウェアを作)るというだから、当然楽をすることを指向している。
C程度に高速な用途に用いることが出来、Cより楽にプログラミングできる言語を目指す。
936デフォルトの名無しさん:2012/03/13(火) 01:00:43.00
今ある言語だとどれがスレタイに近いの?
937デフォルトの名無しさん:2012/03/13(火) 01:02:21.87
MASM?
938デフォルトの名無しさん:2012/03/13(火) 01:03:27.82
C
939デフォルトの名無しさん:2012/03/13(火) 01:05:54.53
システム開発の効率化なら仮想化だろ。低級言語なんてもう要らないわ
したっぱがやってりゃいいんだよ
940デフォルトの名無しさん:2012/03/13(火) 02:18:32.60
>仮想化
?
941デフォルトの名無しさん:2012/03/13(火) 12:12:14.27
>>935
ハードも言語で作るって知ってた?
942デフォルトの名無しさん:2012/03/13(火) 12:44:58.43
「おまえ、これ作っとけ」
943デフォルトの名無しさん:2012/03/13(火) 13:10:39.85
いまどきなんでもlinux動くじゃん。Cで十分じゃん

>>935
ネイティブならC程度に高速だわな。C#とかJavaだってGC以外はC程度に高速
必要性を感じない

プログラムの全部を最適化する必要ってほとんど無いんだぜ?
一部なんだよ。そこはガチでアルゴリズムからアセンブラまで見直して最適化すればいいの
まあ、これも本当はしたっぱがやればいいんだけどな
944デフォルトの名無しさん:2012/03/13(火) 13:41:36.70
マトモな書き方してたら遅くてダメだったときに
アブノーマルな書き方で速度を稼ぐのは下っ端には荷が重すぎるだろ

ここで言う下っ端とはスキルが低い者のことで
下流工程を専門に引き受ける人のことではない
945デフォルトの名無しさん:2012/03/13(火) 13:54:34.20
>>944
そんな俺様辞書の俺様用語を説明されても
不要な知識だからな
946デフォルトの名無しさん:2012/03/13(火) 13:56:32.22
>>944
> ここで言う下っ端とはスキルが低い者のことで

日本語の辞書には無いけど、それは何言語?
947デフォルトの名無しさん:2012/03/13(火) 14:00:25.22
全部したっぱがやればいいんだよ。俺は書類にはんこを押すだけな
948デフォルトの名無しさん:2012/03/13(火) 17:03:58.34
遅延評価ならぬ遅延設計
その機能が必要になる直前まで設計・実装しない

これさえできれば
「機械に大まかに指示を投げる」だけですむ
949デフォルトの名無しさん:2012/03/13(火) 17:05:09.37
ホンバン方式として日本の主力商品に育てよう
950デフォルトの名無しさん:2012/03/18(日) 11:20:30.06
「電池は韓国より日本が優秀」 米テスラのケルティ氏

EV(電気自動車)スポーツカー「ロードスター」で一躍脚光を浴びた米国のテスラモーターズ。
今年、第2弾としてEVセダン「モデルS」も発売。全世界で9千台以上を受注した。
EVの心臓部であるリチウムイオン電池について、バッテリー技術部門を統括するカート・ケルティ部長に聞いた。

■韓国メーカーが車載用電池市場でも価格攻勢をかけているが、性能についての評価は?

 「サムスンやLGの場合は、他社の商品をまねするのがうまいうえが、
ただ、技術優位性では、パナソニックはじめ日本メーカーの方がやはり高い」

■どういった点で日本勢の技術レベルが高いのか?

 「日本メーカーは、高密度化など電池の性能を決定づける材料を深く知り尽くしている。
例えば、『電池の寿命が短くなったのはなぜか』との問い合わせに、すぐ対応してくれる。さらに、
材料の組み合わせによる電池の特性の変化なども深い部分で理解している。
一方、韓国メーカーに同じ質問をすると、『いろいろ試して、直すように頑張ります』となる。
材料に至るまで電池を化学的に理解しているという点で、日本は韓国メーカーより技術的に優位だ」

http://sankei.jp.msn.com/economy/news/120318/biz12031807000001-n3.htm
951デフォルトの名無しさん:2012/03/20(火) 08:02:55.18
今日も朝からアッセンブリブリ
952デフォルトの名無しさん:2012/03/20(火) 23:29:15.98
やはリアセンブラ最強だな
953デフォルトの名無しさん:2012/03/21(水) 03:41:13.64
リアセンブラ
954デフォルトの名無しさん:2012/03/24(土) 12:44:23.72
ただのアセンブリはつらいので型と式とブロックを追加しました。
955デフォルトの名無しさん:2012/03/24(土) 13:04:21.65
名前はCでいいかな
956デフォルトの名無しさん:2012/03/25(日) 04:33:42.23
⊂⊃∪∩cUCつっСс
957デフォルトの名無しさん:2012/03/25(日) 13:17:30.29
目の検査か
ということで、型推論を理解しよう。
その前に、パターンマッチングとユニフィケーションを理解しよう。
ユニフィケーションのもっと簡単な説明が今必要。
959デフォルトの名無しさん:2012/04/13(金) 02:16:16.45
Window window;
Size* p = window.GetSize();
int w = p->width;
int h = p->height;

この参照pをdeleteしていいのかわからんのがC++の嫌なところ。
メンバ変数の参照である可能性もあるし、オブジェクトプールに返す
必要があるかもしれない。GetSize()内で返り値に対する
deleteの振る舞いを変えられれば参照を取得した側にわかりやすい。
960デフォルトの名無しさん:2012/04/13(金) 08:05:16.28
>>959
deleter 付きのスマポでおk
961デフォルトの名無しさん:2012/04/13(金) 08:29:18.64
>>959
生ポインタなんか使うからそうなる。言語のせいじゃないだろ。
962デフォルトの名無しさん:2012/04/13(金) 11:26:08.92
>>959
その点は改善されたやん &&
963デフォルトの名無しさん:2012/04/13(金) 17:23:34.67
スマポとナマポの混在はいやれす
964デフォルトの名無しさん:2012/04/20(金) 12:40:53.61
ナマポを見たらガッするスレ
965デフォルトの名無しさん:2012/04/24(火) 18:09:01.17
ナマポ
966デフォルトの名無しさん:2012/04/29(日) 00:56:07.48
>959
C++では参照とポインタは別もんだよ。
967デフォルトの名無しさん:2012/07/01(日) 10:06:25.60
GC無しで循環参照って対応出来ないんだろうか
968デフォルトの名無しさん:2012/07/02(月) 12:15:58.69
>>967
循環参照に対応する機構を作れば、それはGCと呼ばれることになるだろう
969デフォルトの名無しさん:2012/07/02(月) 13:01:00.95
回収のタイミングが構文に対して不定でないという意味でってことね。

求めたのはstaticやglobal、ローカル変数などのルートノードから切り離された際に
循環参照があっても即時回収されるshared_ptrのようなもの。
もちろん大きすぎる計算量は無しで

例えばC#のusingやjavaのtry-finally-closeは、
(タスク/スレッド型の)GCのタイミングでは困るリソースの生存管理を行う手段(RAII)で、
GCは本質的にはメモリにしか対応していない
970デフォルトの名無しさん:2012/07/09(月) 23:12:45.59
アウトオーダー式に計算結果を事前に格納して、
あれはあれ、これはこれ、みたいにイベント入ったら
直値参照orコールバックで処理済ませるのってどうだろ
971デフォルトの名無しさん:2012/07/23(月) 19:33:22.23
そろそろ次スレたてようず

俺が一人で1000目指す
972デフォルトの名無しさん:2012/07/23(月) 19:49:07.93
Dがあるやん
973デフォルトの名無しさん :2012/07/23(月) 20:21:01.89
ところで激安中古CAD専門店でググると使えるソフトがかなり安い
おススメ!!使えた
974デフォルトの名無しさん:2012/07/23(月) 21:20:16.81
雑談スレで暴れてたひとか
975デフォルトの名無しさん:2012/07/24(火) 09:42:01.24
>>972
作ること自体が目的でもいいじゃん
楽しいじゃん
976デフォルトの名無しさん:2012/07/24(火) 13:12:16.73
そうやって出来たのが Ruby ですね
わかります
977デフォルトの名無しさん:2012/08/18(土) 17:38:50.65
javaとC++で同じコード書いたら最近はjavaの方が早いのな。
単純な計算だとC++の方が速いが最大でも倍程度に過ぎないし、世の中そんな単純な計算ばかりではない。
virtual使ったらjavaの方が速くなるのでオブジェクト指向を捨ててCライクに書かないと対抗できない。
978デフォルトの名無しさん:2012/08/18(土) 17:50:06.02
Javaや.NETだと動的にコードを差し替えられるから
仮想メソッド呼び出しをインライン展開できるんだっけ
979デフォルトの名無しさん:2012/08/19(日) 18:23:30.59
C++のコードがアホなだけだろ
980デフォルトの名無しさん:2012/08/19(日) 20:33:45.26
コンパイラが賢くなればなるほど抽象度が高い方が速くなる
981デフォルトの名無しさん:2012/08/19(日) 20:42:52.67
>>977
単純な計算をJavaで書き直したことがあるけどJavaの方が速かったよ
一箇所だけO(N^2)のループがあってそこがほとんど時間食ってるんだが
実行開始してから時間が経つにつれて段階的に最適化されて速くなっていくのが目に見えて面白かった
982デフォルトの名無しさん:2012/08/19(日) 20:43:26.78
バカ丸出し
983デフォルトの名無しさん:2012/08/19(日) 23:17:41.11
バカはバカって言葉を平気で使う、俺の第一法則
>>981
そう動的に最適化されていく感じなんだよな。
984デフォルトの名無しさん:2012/08/19(日) 23:19:13.83
じゃあ、無能君のほうがいいかな?
985デフォルトの名無しさん:2012/08/19(日) 23:56:00.23
無能は無能って言葉を平気で使う、俺の第二法則
986デフォルトの名無しさん
おちょくり返しにしては、今ひとつだね