10/05/16 22:16:21
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 5
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
10/05/16 22:17:13
◆新言語の要件 v0.1◆
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件） ＞ 構文の美しさ(読みやすさ、学習の容易さ) ＞ 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
3:デフォルトの名無しさん
10/05/16 22:31:03
◆新言語の名称（仮）◆
Programming Language I
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。
4:デフォルトの名無しさん
10/05/16 22:32:11
PL/I
5:デフォルトの名無しさん
10/05/16 23:22:18
このスレたてたやつアホすぎる。
6:デフォルトの名無しさん
10/05/16 23:42:01
アイちゃんカモーン
7:デフォルトの名無しさん
10/05/16 23:47:18
schemeのように言語仕様の大部分を最小限の言語実装の上に構築できればいいのにな。
8:デフォルトの名無しさん
10/05/17 00:27:36
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
9:デフォルトの名無しさん
10/05/17 00:33:03
「ハードウェア制御のような低レベル処理を行える言語」ってのが大前提なのに、
未だにVMだのJITだの言いだす奴らが後を絶たない。
10:デフォルトの名無しさん
10/05/17 01:12:42
>>9
C#で書かれたプログラムでHDDのファームウェアを更新するのだってある時代だぞ
11:デフォルトの名無しさん
10/05/17 01:15:03
ファームをC#で書いているわけではないだろ。
12:デフォルトの名無しさん
10/05/17 01:29:24
ファームは機械語で書かれてる
Cでも大きすぎる
13:デフォルトの名無しさん
10/05/17 01:34:49
少なくとも一つ以上のメーカーで、HDDのファームはCで書かれている。
14:デフォルトの名無しさん
10/05/17 02:33:16
>>13
kwsk
15:デフォルトの名無しさん
10/05/17 03:04:00
C++は除外しろっつーの。あんなものに代わる必要などない。
16:デフォルトの名無しさん
10/05/17 04:24:52
既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。
17:デフォルトの名無しさん
10/05/17 07:15:11
算術演算以外の演算子は後置ってどういうこと？
18:デフォルトの名無しさん
10/05/17 07:44:10
>>7
SC CiSE Template Haskell MetaOCaml CamlP4
Prologのマクロ、演算子定義
Dylan Nemerle Boo Cyan
Cleanで作るインタプリタ C式 Compact ftdop4
19:デフォルトの名無しさん
10/05/17 07:57:40
6ってことは、前に5スレは消費したんだよな
流れとまとめはどこだ
20:デフォルトの名無しさん
10/05/17 11:19:42
>>19
全部似たような流れの糞スレと見た
21:デフォルトの名無しさん
10/05/17 11:38:42
C言語レベルの低級言語なのにガベコレつくれとかそういう話だったな
22:デフォルトの名無しさん
10/05/17 12:24:17
発想というか試みとしては評価したいが
当然64bitマシン対応だよな
ニーモニックを直接書けるようメモリアドレス確保する専用の汗・逆汗変換機能が欲しいかもしらん
23:デフォルトの名無しさん
10/05/17 14:31:54
>>21
C--がそういうコンセプトだし珍しくなかろう。
竹内先生はOSやアーキテクチャがガベコレを支援して然るべきと言ってるし。
24:デフォルトの名無しさん
10/05/17 15:15:49
OS書くといっているのに、また、OS前提の話をはじめる。
25:デフォルトの名無しさん
10/05/17 16:33:36
アイちゃんばっか
26:デフォルトの名無しさん
10/05/17 17:52:33
ゆとりには自分でメモリ管理なんてできないんです。
ガベコレが無いとメモリリークで落ちるんです。
わかってください。
27:デフォルトの名無しさん
10/05/17 17:56:30
だからおまえはOSも保護もなにもない8086で仕事してればいいの
28:デフォルトの名無しさん
10/05/17 19:31:54
ガベコレ有りでも無しでも書ければいいよね
29:デフォルトの名無しさん
10/05/17 19:44:19
仕事でCでRAIDカードのファーム書いてた
ごく一部アセンブラ。C++ではない。
性能的にはハードの理論値90%以上は出せた
新言語はこれ最低ラインにしてくれ
30:デフォルトの名無しさん
10/05/17 20:22:03
性能の大部分は最適化にかかってると思う
31:デフォルトの名無しさん
10/05/17 21:38:33
>>29
SiliconImageのドライバの出来が悪いのはCで書かれてるからなのか
32:デフォルトの名無しさん
10/05/18 00:45:09
>>26
ガベージコレクションあってもメモリリークで堕ちることはあるが。
33:デフォルトの名無しさん
10/05/18 03:13:18
>>30
その通り。最終的にはプロファイルしながらuS以下の単位で手動オプティマイズ
>>31
SIじゃないよ。もっとマイナーｗ
でドライバじゃなくファームなｗ
34:デフォルトの名無しさん
10/05/18 14:16:28
だから前スレ埋めてからにしろ糞虫共
35:デフォルトの名無しさん
10/05/18 18:44:15
golangのunsafeいいけどGC有りが前提なんだよな。
URLﾘﾝｸ(golang.jp)
36:デフォルトの名無しさん
10/05/18 18:46:11
golangでロードバランサーのファーム書いてよ
37:デフォルトの名無しさん
10/05/18 18:58:38
GC有り無し混在させつつGCは完全なGCをしたい。
struct A { A a = new A(); A a2 = gcnew A();}
A a1(){ return new A(); }
A a2(){ return gcnew A(); }
A a = a1();
a = a2();
というようなことをしたとする。
どれがGC対象でどれがGC対象ではないかはアドレスで判断できる。
しかし、gcnewした値をnewした変数が参照している場合
GC対象にするにはどうしたらいいのだろう？
gc対象外のオブジェクトは保守的にGCする？
それとも、すべてGC対象にしつつ
deleteすればたとえ参照が残っていても開放する？
すべてをGC対象にする場合は完全に型情報を把握できる？
完全に型情報を把握できない場合はどうする？保守的GC？
38:デフォルトの名無しさん
10/05/18 19:29:40
んなもんGCに任せるだけだよ
それよりで混在の問題はGC型で確保したデータを返すゲネレータパターンの引数にデストラクタ処理されるデータを渡した場合の不整合のほうが深刻
39:デフォルトの名無しさん
10/05/18 19:31:09
>>35
コンサバティブだと思う
簡単なプログラムでだが
mmapしたメモリをsliceに
貼り付け出来て走ってたが。
40:デフォルトの名無しさん
10/05/18 23:03:02
分かってる振りしてレスするスレ
41:デフォルトの名無しさん
10/05/19 01:32:04
GCアリ用に書いたコードをGCナシ用に簡単に書き変えられたらいいな。
あと、その逆も。
42:デフォルトの名無しさん
10/05/19 01:37:07
それが無理だって話を今してるわけだが
43:デフォルトの名無しさん
10/05/19 01:40:07
無理というのは、そういう構文を設計できないという意味？
44:デフォルトの名無しさん
10/05/19 01:56:53
無理ではないが面倒
45:デフォルトの名無しさん
10/05/19 02:06:15
面倒というのは、
GCアリ用に書いたコードをGCナシ用に簡単に書き変えられる構文を設計するのが面倒ってこと？
それとも、
GCアリ用に書いたコードをGCナシ用に書き換えるのはどんな構文にしたとしても常に面倒ってこと？
46:デフォルトの名無しさん
10/05/19 02:22:40
GCありなら基本ありがいい。混在の構文とかややこしいだけ
でも管理エリア外のメモリはGC対象外ってことでいけんじゃね
ていうか、GCの問題はメモリ以上に、実行が途中で不定な時間止まることだろ
47:デフォルトの名無しさん
10/05/19 02:35:17
static変数がある言語でのGCなんておまじないみたいなもの
48:デフォルトの名無しさん
10/05/19 11:00:09
たとえば、言語仕様上は記憶クラスとしてcollectableを指定した変数はGCに回収されるようにしてはどうだろうか。
collectableとstaticやautoは同時指定できず、無指定時のデフォルトはauto指定。
行頭で collectable: と指定すれば、それ以降のスコープブロック内では無指定でcollectable指定。
同様に collectable{ ... } とすれば、そのブロック内では無指定でcollectable指定。
autoやstaticも同様に指定できる。
GCの実装はコンパイラ依存とし、既存GCライブラリのラッパーであっても構わないし、OSに投げてもVMに投げても良い。もちろん独自実装だって構わない。
GC指定された変数を非GC指定へ渡す際は要キャスト(というか、ハードコピー)とすれば、不整合は起こりにくく出来るのでは？
もちろん、その場合はメモリをちゃんとプログラマ側で確保してあげるべきで、自動化してはいけない。
その際の構文は...
('A`)ﾉｼ ｱﾄ ﾊ ﾏｶｾﾀ
49:デフォルトの名無しさん
10/05/19 13:25:42
>48
>不整合は起こりにくく出来るのでは？
それだと不整合は起こりえるので全く使い物にならないから
言語サポートしたとはいえない
よく考えてから書け
50:デフォルトの名無しさん
10/05/19 13:30:28
new と gcnew の話をしているやつはC++/CLIで何か不都合があるのかな？
51:デフォルトの名無しさん
10/05/19 14:58:04
>>48
ブロック内でGCとか意味ないってことに気づけよ
変数単位じゃなく確保されたメモリ自体の管理だからな
gcnewとかいう半端な仕様なんて汚いだけ
ここはファームやドライバ書ける言語の話じゃねえの
Windowsしか知らないでプログラム組むならなんぼでも選択肢あんだろ
52:デフォルトの名無しさん
10/05/19 15:48:53
>>40
保守的GCだと管理外は回収されないってだけだよ
中みてないけどｗ
プログラム的には注意が必要だが便利ではある
特にでかいファイルをmmapできると行儀よく読むより速度が2桁変わるしな
53:デフォルトの名無しさん
10/05/19 15:53:22
GCの話してるときに、獲得メモリーの大きさで議論するのは
少し違和感があるんだけど、Windowsって大きなメモリー領域確保
すると遅くなるの？
54:デフォルトの名無しさん
10/05/19 17:00:33
大きさだけじゃなく、使い方かね
ほとんどのシステムで大きなメモリ領域をとると遅くなるが
抜け道的にGC対象外のエリアを使えるのと使えないのでは書ける範囲がだいぶ違う
例えばDBのエンジンとかその底のファイルアクセス部分とかね。
上の方はGCアリでいいが、下はむしろ有害だったりするし。
まあ俺はシステム屋、組み込み屋だからGCで不定時間停止とか
割り込みから使えない方が問題だがｗ
55:デフォルトの名無しさん
10/05/19 17:11:05
参照カウンタで十分
56:デフォルトの名無しさん
10/05/19 17:18:03
>>54
>ほとんどのシステムで大きなメモリ領域をとると遅くなるが
ならねーよ。バカ。
57:デフォルトの名無しさん
10/05/19 17:34:04
とりあえずなにか作ってみれば？
今要望が出てる機能だけで簡単(？)に作成してみればいい
58:デフォルトの名無しさん
10/05/19 17:58:19
あきらかに56がバカだ。
59:デフォルトの名無しさん
10/05/19 18:17:48
おれもそう思う。
60:デフォルトの名無しさん
10/05/19 22:09:05
作っているには作っているけど、簡単に作れません。
C++/CLIは.Net FrameworkのC++マネージ拡張を簡単にしたものなんだ。
知らなかった。orz
ポインタとハンドルがあって、ハンドルはGC対象ってわけか。なるほど。
ちゃんと触ってみるかぁ
61:デフォルトの名無しさん
10/05/20 01:04:35
>>56 >>57
理由言えバカ！勉強にならねーだろ。
56がバカかどうかわからないけど、
メモリ領域を大きく取る
＝＞ 物理メモリ外か？
YES＝＞ エラー or スワップから変換
NO ＝＞ アドレッシング解決による3サイクルアクセス
って感じで分かれないの？
ばかだなーって思ったやつは検索用語か読んどけ本書いていけ
62:デフォルトの名無しさん
10/05/20 01:18:30
>>61
何度も言うけどこのスレは勉強会のスレじゃないよ。
バカは黙ってろって何度言えば分かる？
勉強会のスレッドに不足してるわけでもないし、
このスレで勉強会始めるなよ。
63:デフォルトの名無しさん
10/05/20 01:36:00
記憶階層の勉強会かw
キャッシュ忘れんなよ
特に組み込みのCPUなんかで動画扱うと
桁変わる位速度が違う
64:デフォルトの名無しさん
10/05/20 01:59:48
勉強会のなにが悪いん？
学術的な話するのに勉強はするないうのはおかしいんじゃない？
勉強会スレってあるの？
65:デフォルトの名無しさん
10/05/20 02:01:34
バカバカうるさい
66:デフォルトの名無しさん
10/05/20 02:30:51
勉強会したいなら、どんなカスなレスでも調べてみろよ
中にはまともなの？もある
>>56みたいなのはバカといわれても文句は言えんな
67:デフォルトの名無しさん
10/05/20 02:32:25
俺もそう思う。
68:デフォルトの名無しさん
10/05/20 03:30:43
C++/CLIが内部でどうなってるのかわからないけど、
^がポインタ演算子ならぬ、ハンドル演算子みたいに働いてGC用型になり
ref classがGC対象クラスになるということが分かった。
GCなしがベースでGCありにしたいときに特別な修飾ができればいいんだな。
ポインタ操作はunsafeなライブラリが受け持つことにして隠蔽してしまえば
ハンドルとプリミティブだけでプログラムできる。
通常はjavaみたいにプリミティブと参照される型だけあるようにする。
A* a = new A()じゃなくA a = new A
stack A a = new A()等とするとスタックにメモリ確保されて
スコープから抜けると開放される。
A^ a = gcnew A
でgc対象にできるって感じでgc有り無し共存できたらいいかなぁ？
C#にアンマネージド機能を追加した感じで。
69:デフォルトの名無しさん
10/05/20 11:24:19
URLﾘﾝｸ(www.slideshare.net)
Hot Spot VMでは参照マップを使ってポインタとそうでないものを区別してるそう。
70:デフォルトの名無しさん
10/05/20 11:52:47
直前の計算結果のフラグを条件にできる構文がほしい
71:デフォルトの名無しさん
10/05/20 15:25:23
carry(a = a << 2){}
とか？
a = a << 2
if(CARRY_FLG){
}
とかですかね？
フラグの値を取り出してboolとして扱えるような構文
72:デフォルトの名無しさん
10/05/20 17:43:23
そうそうそんな感じの、キャリー立ったら、とかオーバーフローしたらこうする、みたいなの
アセンブラだと自然に
a = a + b
if(OV_FLG){
a = INT_MAX
}
みたいにできるんだけど、Cとかだと
if (INT_MAX-b<a)
a += b;
else
a = INT_MAX;
みたいにやらないといけないことが多くてまどろっこしい
73:デフォルトの名無しさん
10/05/20 17:47:24
前スレの内容がループしてるんだけど、
ループしてまで、なんとかスレを伸ばしたいのかな？
そうまでしてスレを伸ばしたいのなら、勉強会始めなきゃ
良いのにって思う。議論が進みそうになると勉強会初めて、
ネタに尽きるとループっていうのは２ｃｈの悪い所。
何時までたっても同じところから前に進めない。
つまり、バカが書き込むのはよくないと思う。
74:デフォルトの名無しさん
10/05/20 18:00:44
>>72
#define INT_CLIP(x) (int)(MAX((long)INT_MIN,MIN((long)INT_MAX,(long)x)))
a = INT_CLIP(a + b);
こう書いとけばコンパイラが勝手に最適化してくれるぞ
75:デフォルトの名無しさん
10/05/20 18:14:16
>>73
おまえ・・・ループしてね？
76:デフォルトの名無しさん
10/05/20 18:17:46
>>74
それが結構してくれねーんだ
律儀にビット拡張して計算してコンペアして分岐してくれる
77:デフォルトの名無しさん
10/05/20 18:22:20
＞＞76
暗黙の型変換が仕様なので、暗黙の型変換後を最適化する
普通の最適化だと無理なんだよね。
字句解析→構文解析、この辺で情報が落ちてしまいがち
でも、これもコンパイラの勉強会の話ですれ違い。
バカはどっか行け
>>75
俺もそう思う
78:デフォルトの名無しさん
10/05/20 18:38:35
ではここで関数型言語とGCとC#の話題をどぞー
79:デフォルトの名無しさん
10/05/20 23:16:24
バカ = バカ + バカ
ってことで
80:デフォルトの名無しさん
10/05/20 23:31:41
twitterで呟いてたのを見たんだけどContinuation Based Cっていうのが
基本ブロック単位でプログラムできるようです。
これこそ超高速C言語なのかもしれないですね。
よくわかってないですが、基本ブロック単位で関数みたいに出来るのかな？
81:デフォルトの名無しさん
10/05/20 23:46:28
ここで求められてるのは、Cより高速な言語じゃなくて、
VMとかGCとか遅くなる要素が無くて、C程度に速いオサレな言語だから。
82:デフォルトの名無しさん
10/05/20 23:49:03
違う。C言語の問題点を克服したパラレルCだ。
83:デフォルトの名無しさん
10/05/20 23:55:12
CARRY_FLGとかいまいちカッコ悪いから、こんな感じがいいな。
現スレッドオブジェクト current
現スレッドのALUオブジェクト current.alu
現スレッドのALUオブジェクトのキャリーフラグ current.alu.flag.carry
現スレッドのALUオブジェクトのゼロフラグ current.alu.flag.zero
using current.alu.flag;
でcurrent.alu.flagを省略できるとか。
84:デフォルトの名無しさん
10/05/21 00:19:34
C#ならunsafeを使えばポインタも扱える。
ただ、クラスがあったりする。
ポインタを使いたい場合はunsafe内で使える。
だけどVM不要な人がいちいちunsafeは書きたくない問題が残る。
例えば、unsafe:って書いておけばunsafeになるくらいだといいのかもしれない。
class C{
static void Main(){
unsafe {
int n;
int* pn = &n;
byte* p = (byte*)pn;
85:デフォルトの名無しさん
10/05/21 00:20:41
>>82
CBCはC言語の問題点を克服したパラレルCなんですね。
86:デフォルトの名無しさん
10/05/21 01:49:18
>>80
面白そうだからみてみたら
これの継続って引数付きgotoですな
一応戻るようなのも書けるみたいだが
ループのたびに継続作るのは
まとまったコードを書くのはキツそう
87:デフォルトの名無しさん
10/05/21 01:55:10
>>83
なんだよ。現スレッドって。
キャリーやフラグは扱えたら面白いが
最適化で実行順が変わるとアウトだし
CPUで挙動が異なるのがねー
88:デフォルトの名無しさん
10/05/21 05:49:29
C#では
int* x = stackalloc int[N]でスタックからアロケーション可能だけど
すべてのオブジェクトはGCで管理されるのでGCによって消される可能性がある。
対策として
fixed(double* p = &c.re){
*p = 10;
}
等としてfixedの間はGCが行われないようにすることができる。
ということで、C#の場合はGCありきな言語でポインタ操作もできると。
89:デフォルトの名無しさん
10/05/21 06:04:07
未だに前スレ埋めてないお前らの糞さにビックリだよ
90:デフォルトの名無しさん
10/05/21 06:12:27
>>89
早漏の >>1 の後始末なんて知ったこっちゃない。
91:デフォルトの名無しさん
10/05/21 06:15:00
関数型言語のGCはビットタグが付いててアレなのでSML#いいよ
URLﾘﾝｸ(www.pllab.riec.tohoku.ac.jp)
SML#の#は.Net Frameworkの前からあってレコード演算子"＃"を象徴するものと
92:デフォルトの名無しさん
10/05/21 06:17:38
>>89
ビックリマン登場
参照の必要があればGCしないほうがいい
93:デフォルトの名無しさん
10/05/21 07:33:21
で、言語ってどうやって作ればいいんだよ
94:デフォルトの名無しさん
10/05/21 08:56:43
設計思想はPythonがベストだと思う。
言語自体を限りなくコンパクトにして、豊富なライブラリを標準で付ける。
ライブラリとして分離されていればメンテしやすいのは自明。後から新技術を採用するのも容易。
つまり、GCとかVMとかライブラリでどうにでもなることは後で考えろ、ということ。
まず決めるべきは上っ面、構文のみである。
95:デフォルトの名無しさん
10/05/21 09:07:07
そういう発想なら、構文も後付けでどうとでもなるLispかFORTHでおk 終了、だろ
96:デフォルトの名無しさん
10/05/21 09:08:19
>>94
あと、GCやVMに言語が一切関係してなくて、ライブラリで実現してる例ってあるのかな？
あるなら教えてほしいもんだが。
97:デフォルトの名無しさん
10/05/21 09:24:06
>>96
その前に何故GCやVMが「言語の機能」だと思い込んでるの？
そっちのほうが不思議だわ
98:デフォルトの名無しさん
10/05/21 09:47:13
>>97
その前に何故GCやVMが「ライブラリだけで実現」できると思い込んでるの？
そっちのほうが不思議だわ
99:デフォルトの名無しさん
10/05/21 09:49:11
コンパクションもできなければexactなGCもできないライブラリを示して、勝利宣言とかやめてねw
100:デフォルトの名無しさん
10/05/21 09:55:04
8bitマイコン用の言語ができたら教えて
101:デフォルトの名無しさん
10/05/21 10:15:23
>>98
実行時の機能だから
おまえは言語の機能とパーサ以降の機能を分離できてない
102:デフォルトの名無しさん
10/05/21 10:21:33
言語機能の一部がライブラリで実現されてる例なんて山のようにあるお。
頭のなかだけで分離していて現実を見てない人の気配がするお。
103:デフォルトの名無しさん
10/05/21 10:29:24
GCを欲しがる奴らはこんなド低脳ばかり
104:デフォルトの名無しさん
10/05/21 10:56:08
いまどき、自分でメモリを管理して悦に入っている奴は、重要なことが何かがわかっていない。
105:デフォルトの名無しさん
10/05/21 10:58:50
ド低能って、自分でメモリを管理して悦に入っている奴のことだよな。
106:デフォルトの名無しさん
10/05/21 11:20:55
ド低能はプロジェクトによってメモリ管理を自分でやるか誰かにやらせるかを判断できない
107:デフォルトの名無しさん
10/05/21 11:23:17
>>106
低能が我慢できずに反してきたか。
それだけしか言えないか？
108:デフォルトの名無しさん
10/05/21 11:58:26
>>102
だから組み込む必要はない(ライブラリでいい)ねって話だろ。何か問題でも？
109:デフォルトの名無しさん
10/05/21 12:03:53
>>107
うん。それ以外に言う必要ないし
110:デフォルトの名無しさん
10/05/21 12:06:21
このバカを張り付けておくためだけでも有意義だな、このスレは
111:デフォルトの名無しさん
10/05/21 15:58:01
GC 自体が欲しいんじゃなくて、
GC 必須になるオサレな構文が、
112:デフォルトの名無しさん
10/05/21 16:48:07
GC前提は言語の設計に影響する
VMは影響しない
低レベルでGCありならgolang
無しならCで決まりじゃね
C++の末えいはみな悲惨
113:デフォルトの名無しさん
10/05/21 16:48:57
バカ量産言語だしな
114:デフォルトの名無しさん
10/05/21 16:52:06
>>111
クロージャや継続ですねわかります
115:デフォルトの名無しさん
10/05/21 18:01:43
メモリーリークが発生するのは、やたらとヒープにメモリを取るからで
オブジェクトのインスタンスをスコープを外して永続化したいとき以外
newを使えなくしてしまえば良いんじゃないかな。
するなといってもしてしまうのが人の常なので、newの構文は長くしよう。
奇数行だと、new_allocate_heep_memory_i_need_I_want_majide_majde
偶数行だと、new_allocate_heap_memori_I_need_i_want_maide_majide
こうやって無茶苦茶書きにくく、長く書く必要があれば嫌な感じがして、
となれば使うのを控えると思う。
後、スコープを外れてメモリーリークを避けるために、ローカル変数への
代入は永続変数の代入が無ければ、コンパイルエラーってことにすれば
良いと思う。
116:デフォルトの名無しさん
10/05/21 18:10:34
もう列挙子やラムダ式の無い言語には戻れないｗ
117:デフォルトの名無しさん
10/05/21 18:26:02
それで何故、メモリーリークの混乱が起きるのか？
って考えると、オブジェクト指向のhave a関係が
大雑把過ぎると思うんだよね。
人間には手がある。とその人は本を持ってる。
英語だとどちらもhasで表現されるけども、日本語では
単語レベルで概念が分かれてて、「ある」と「持ってる」
違った単語で表現するよね。プログラミングでもこの概念を
分けないと駄目だと思う。
英語詳しくないんだけど、have theとhave aで良いのかな？
have the でそのインスタンスを明確化して、参照やポインタを
持つのはhave aで表現する事にすれば、良いのではないかな？
118:デフォルトの名無しさん
10/05/21 18:35:20
持っているというより、くっついているイメージなんだが。
equipmentじゃないかと。
119:デフォルトの名無しさん
10/05/21 18:37:41
>>117
という事で、クラス定義の文法は
class Human
{
have the char name[40];
have the int age;
have a int money;
have a car* private_car;
}
とすれば色々判って便利だと思う。
120:デフォルトの名無しさん
10/05/21 18:38:40
ガンダムのビームライフルは外せるが、
ガンキャノンのキャノンは外せない
外せたら、それガンキャノンやない、ガンや！
121:デフォルトの名無しさん
10/05/21 18:41:57
>>120
そういうこと、文法でそこを縛ってやれば、
メモリーリークも見つけやすく自動化も楽になると思うんだ。
プログラムも組みやすいだろうし。
122:デフォルトの名無しさん
10/05/21 18:51:00
それ単にオブジェクト間の関連の多重度の話だろ
考えられる多重度って
0..1と1の二種類じゃないし、構文だけでどうにかしようってのは
あまり現実的でないと思うと思うが
Cライクな言語において、0..1の多重度を表現するのにNullポインタ的なものを
使うことが多いけど、
少なくとも高級な言語なら、OptionやMaybeがあるべき姿だと思う
Javaや.NETは型安全性を犠牲にした妥協と見える
123:デフォルトの名無しさん
10/05/21 18:55:00
>>122
オブジェクト指向プログラミングと、
オブジェクト指向分析の境界で、そのへんがあやふやだから、
そのインスタンスの性質を表してるのに、have関係的に
扱ったりしてややこしくなってると思うんだよね。
have the のインスタンスは、所有してるクラスが死ねばもろともで良いんだよ。
仮にそれを参照（所有）してる他のクラスが生きてるとしても、それは
それを持ってることがおかしいんだよ。
124:デフォルトの名無しさん
10/05/21 19:00:02
ホワイトベースが、ガンキャノンを持ってるから、
砲門を二つ持ってる。
ここでガンキャノンがシャア少佐の工作によって
破壊されてるのに、2門残ったりする。
ホワイトベースhave a ガンキャノン
ホワイトベースhave a ２門
とかやって、バグの原因になるんだよ。
ホワイトベースhave a ガンキャノン
ホワイトベース.数える砲門数（）
としなければおかしいんだよ。
125:デフォルトの名無しさん
10/05/21 19:02:38
他の誰かから参照されたくない物なら、単にそれをプライベートにして
その参照を返すようなメソッドだのを作らなければいいだけの話では
そうすれば自動的に寿命は所有者と同じになるだろ
プログラムを現実世界の直喩で考えても上手くいかんと思うがなあ
現実を直接的にそのままモデル化しようとするのは
OO初心者が陥りがちな罠では
126:デフォルトの名無しさん
10/05/21 19:06:27
>>125
逆>>122みたいなバカな事言い出すのがオブジェクト指向に混乱を
もたらしてる。
class Human{
have the hand[2];
have a handbag_list;
}
どちらも（0..N)関係だけど、意味合いがぜんぜん違う。
127:デフォルトの名無しさん
10/05/21 19:19:01
>>126
ああいいたいことは分かった
多重度というより、関連のconst性な
constでいいんじゃねえの
128:デフォルトの名無しさん
10/05/21 19:36:28
ええとつまりキャノンは構造体で定義しておくべきってことか？
129:デフォルトの名無しさん
10/05/21 19:44:28
整備とかでキャノンも外せるでしょ
そのときのガンキャノンは、まさしくガンだよ
130:デフォルトの名無しさん
10/05/21 20:27:10
なんでオブジェクト指向の勉強会なん
英語の勉強もか。have, belong, is
オブジェクト指向って自然発生的にやってたし
昔Smalltalkとか勉強したから理解が深まった
プリミティブじゃないifとかループとか美しいぜ
C++族の中途半端さが嫌いなやつはいねえのか
131:デフォルトの名無しさん
10/05/21 20:48:23
C++も最初に基底オブジェクトクラスを仕様化しとけば、
今ほどのカオスにはならなかったろうに。
132:デフォルトの名無しさん
10/05/21 20:58:46
つまりガンダムはライブラリ参照してるけど、ガンキャノンは初めから組み込んでいると
宣言によっては削ることも出来るが、それはもはやガンキャノンではありえないわけだな
133:デフォルトの名無しさん
10/05/21 20:58:53
このスレの奴らがいくら頑張って新言語を作ってもGoの方がはるかに
マシだろうな
無駄な努力はやめとけ
134:デフォルトの名無しさん
10/05/21 21:05:37
Goは、Cよりも上のレイヤーで使うことを想定している。代わりにはならない。
135:デフォルトの名無しさん
10/05/21 21:33:10
そのうち下位レイヤにも対応したGoToという言語を誇らしく発表
136:デフォルトの名無しさん
10/05/21 23:13:13
>>116
それって実行時のオーバーヘッドなく使える機能だよね？
新言語にはぜひ入れよう。
137:デフォルトの名無しさん
10/05/21 23:16:39
>>134
C#やらGCの話をしている時点でgolangの圧勝
OS本体はCで書いて、その上はgolangって感じだね
リンカとかコンパイラも書きやすそうだしな
Xprotocolの実装が入ってるし、そういうミドル層を狙ってるんだろう
現実的な解じゃないか
138:デフォルトの名無しさん
10/05/21 23:29:11
>OS本体はCで書いて、その上はgolangって感じだね
それなら、golangは新言語の直接の競合にはならないね。
新言語の主眼はCの置換えだから。
139:デフォルトの名無しさん
10/05/21 23:31:21
メモリ管理を組める言語ｷﾎﾞｿ
140:デフォルトの名無しさん
10/05/21 23:55:32
ルーチンとかの根幹的な構造も自分で組めるようにするの？
141:デフォルトの名無しさん
10/05/21 23:56:23
そうしたいね。
142:デフォルトの名無しさん
10/05/21 23:56:32
>>138
Cの置き換え言語の話でGCやらオブジェクトの話してるわけだが？
Cはある意味完成された言語。
だからこそgolangは別な層を目指したんだよ
現行の半端なOOへのアンチテーゼでもあるな
143:デフォルトの名無しさん
10/05/22 00:03:59
Goは総称型が無いのが残念
C++みたいなテンプレートは別に要らないけど
144:デフォルトの名無しさん
10/05/22 00:04:53
低級をカバーしつつ、流行りの機能を使えるのも新言語の持ち味だ。
golangがCとの共存を目指しているなら、golangがカバーしない部分では競合にはならない。
新言語はgolangと共存してもいいし、共存するくらいなら新言語だけを使ったほうがいいね。
145:デフォルトの名無しさん
10/05/22 00:08:28
GenericsはFAQだっけ？にはいずれ追加したいって書いてあるね
146:デフォルトの名無しさん
10/05/22 00:11:11
>>144
君はCPU固有言語君じゃないか？
頭をC#/C++/Winから離した方がいいよ
147:デフォルトの名無しさん
10/05/22 00:12:16
どこからC#/C++/Winなんて出てきたんだか。
148:デフォルトの名無しさん
10/05/22 00:18:47
>>147
俺エスパーかと思ったが違ったか
Cは英語みたいなもんだ。超えるのは難しいぞ
149:デフォルトの名無しさん
10/05/22 00:19:54
C代替だとGC依存/前提は話にならないと思う
使える分には構わないけど
150:デフォルトの名無しさん
10/05/22 00:27:55
GCなし言語にGCを追加すると汚くなるだけだよ
どうせ入れるなら最初から前提にしたらいい。
スレの意味はなくなるがｗ
>>144
C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。
151:デフォルトの名無しさん
10/05/22 00:28:57
どこが汚くなるのかまったく不明。
152:デフォルトの名無しさん
10/05/22 00:32:04
>>150
>C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。
だからこそ、低レベルで本当に「使える」新言語を作るんだろ。
153:デフォルトの名無しさん
10/05/22 00:35:25
>>150
> C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。
使っちゃ悪いということはないんじゃない？ Cで出来る事は何でもできるんだから。
eCosはかなりの低レベルだと思うけどC++で書かれている。
154:デフォルトの名無しさん
10/05/22 01:30:29
まあ、後ろ向きの話をしてる奴は相手にしなくてもいいよ。
「既存のXXXはダメだから、新言語もダメだ」
ではなく、
「既存のXXXはダメだから、新言語はこうしよう」
という議論を期待したい。
155:デフォルトの名無しさん
10/05/22 01:54:33
お前がやれよ
156:デフォルトの名無しさん
10/05/22 02:42:17
>>153
ん？あれCじゃないか？
C++のサポートはあったと思うが。
C++がCと同じことが出来るのは
比較的上の世界だよ
前向きにいうなら、Cの代替じゃなく
C++/java/C#の代替を考えたらどうだろう
ブートローダやOS、組込みなんかの
ベタな世界を知らないで
Cの置き換えを考えるのは無理と思うよ
157:デフォルトの名無しさん
10/05/22 02:49:50
ついでにいうと、
知り合いがC++使ってRTOS作ってたが
ブート部分は苦労してたな
世界を二つ作らないといけないし
リアルタイムな時間の保証も考えると
結局virtualはほとんど無し
クラス階層も浅めでやってたな
俺はCで書いたが、性能や時間保証は
余り苦労しなかったかな
158:デフォルトの名無しさん
10/05/22 02:52:11
>>156
> java/C#の代替を考えたらどうだろう
スレ違い
159:デフォルトの名無しさん
10/05/22 02:54:03
>>156
> C++がCと同じことが出来るのは
> 比較的上の世界だよ
Cに出来てC++に出来ないこととは？
160:デフォルトの名無しさん
10/05/22 03:14:12
>>159
例えばmain以前の部分や
プアなCPUやメモリの組込みなんかは？
書けなくもないが、C++てより
ただのCとして使うことになる
>>158
GCやらクロージャやら
オブジェクトがうんたらとかの話ばっかだろ
スレ違いじゃないと思うがな
161:デフォルトの名無しさん
10/05/22 03:22:15
>>160
> 例えばmain以前の部分や
> プアなCPUやメモリの組込みなんかは？
それって、Cに出来てC++に出来ないことなの？理由は？
> ただのCとして使うことになる
それでもC++であることには変わりない。
162:デフォルトの名無しさん
10/05/22 03:26:41
>>161
子供かよw
要するに
その場に書いてないコードが走ったり
余分にメモリ食って
余分なセットアップがいるC++は
最初から使わないんだよ
動的なメモリすら使わない世界な
163:デフォルトの名無しさん
10/05/22 03:33:40
>>162
で、>>159の質問には答えないの？
> 子供かよw
これで逃げるなら別にいいけど。
164:デフォルトの名無しさん
10/05/22 03:42:32
じゃあ尋ねるが
C++がC++として機能する前は何で書くんだ？
スタティックなコンストラクタ呼び出しやら
スタックやメモリ初期化周りとかな
C++の機能を全く使わずに書いてもC++なのか？
まあ、暇だからいいけど
現実に選択肢に入らないんだから
言葉遊びならこれ位に。
165:デフォルトの名無しさん
10/05/22 03:49:11
>>164
だから、それは、「Cに出来てC++に出来ないこと」の説明ではないだろ。
CはXXXが出来る。しかし、C++はXXXが出来ない。
端的にXXXを答えればいい。
166:デフォルトの名無しさん
10/05/22 04:04:31
C++はCの機能をほぼ完全に包含しているから
Cに出来てC++に出来ないことがあると論陣を張り続けるには無理がある。
ハンバーグとハンバーガーを比べてハンバーガーには肉が無いと言ってるようなものだ。
167:デフォルトの名無しさん
10/05/22 04:20:02
実行時に負荷にならない機能はリッチにしたいな
168:デフォルトの名無しさん
10/05/22 04:22:14
ではハンバーグが食べたいときにレストランでハンバーガーを頼むといい。
俺はハンバーグセットを頼むけどなｗ
>>166
余分なものが付いているから使われない世界もあるんよ。
Cとしてか使わないならそれはC++とは言えんだろってこと。
169:デフォルトの名無しさん
10/05/22 04:29:19
ランタイムでCが初期化してやらないとC++としては使えないからな
170:デフォルトの名無しさん
10/05/22 04:40:48
まだこの人、ハンバーガーには肉が無い、と言い張るようだ。
171:デフォルトの名無しさん
10/05/22 04:55:03
CもC++も単なる置き換え対象だからどうでもいいよ。
172:デフォルトの名無しさん
10/05/22 04:59:56
まあ、実際に組み込み分野ではC++コンパイラがあっても
ほとんど使われてないからどっちでもいいよｗ
新言語はC並にRAMがまだない状態でも動かせる言語にしてくれ
173:デフォルトの名無しさん
10/05/22 05:01:07
必死過ぎて笑える
174:デフォルトの名無しさん
10/05/22 05:41:43
うむｗくだらん言葉遊びに付き合っちまったなｗ
175:デフォルトの名無しさん
10/05/22 09:15:54
新しい言語はアンマネージがデフォでGC付きポインタである
ハンドル型があって共存できればいい。
で、マネージドな関数からアンマネージドな関数を呼び出すときは
GCを止めるフラグを立てて戻ってきたら立て直すのを自動で行ってくれるようにする。
マネージドなプログラムのスタックフレームは完全なGCが可能な情報があれば嬉しい。
マネージドなプログラムではポインタは扱わないでハンドルで扱う。
アンマネージドなプログラムではポインタを扱う。
とすれば融合できそうですね。
managed int main() {// mainがmanagedならgcライブラリをリンク
a();
}
managed struct A{}
struct B{}
managed int a(){
String s = @"str";// マネージドな文字列
A a = new A();
return unsafe();// 自動GC OFF
}
int unsafe() {
B b* = new B();
auto B b2* = new B(); // autoが付くとスタックから取得する。
delete b;
return 1;
}
176:デフォルトの名無しさん
10/05/22 09:17:28
GCはライブラリ提供でいいよ
177:デフォルトの名無しさん
10/05/22 09:29:56
ライブラリ提供では、保守的なGCになってしまいません？
178:デフォルトの名無しさん
10/05/22 09:39:07
言語仕様にGCを入れてスタックフレームの使い方を工夫することで
完全なGCが可能になるので、GCのアルゴリズムはライブラリでいいとしても
関数の呼び出し規約の変更と構造体にGCが可能にするための情報の
追加が行えるようにするといいと思うのです。
関数呼び出し時のスタックに何が入っているかも分かるようにするとか。
GC切った状態でならOSも、言語も作れる。
すくなくとも、言語仕様としてGC拡張に耐える文法であるといいと思います。
C++の
B b(3);
のように書いてスタックに変数をというのはやめて
auto B* b = new B(3);b.a
のように書けたらいいのではないかと。
179:デフォルトの名無しさん
10/05/22 09:51:53
GC処理によるCPU占有を許容できないシステムでも使われるのが低水準言語
しきりにGCGCとわめいてるクズ共はそういう世界を考慮していない根本から間違った奴ら
どうしても採用していならまずCPUを占有しないGCを発明してからにしろ
180:デフォルトの名無しさん
10/05/22 09:55:56
採用云々は別としてGCを実装可能な言語仕様を検討するのは意味ある
GC使用を選択可能というのも現実的な解だと思うが
181:デフォルトの名無しさん
10/05/22 09:59:28
>>180
ない
GC必須な仕様ではリアルタイム処理は絶対に作れない
タイムスライスを保証できないから
さらにGCがなくても高水準なプログラムは作れる
であれば採用しないのは当然の帰結だ
182:デフォルトの名無しさん
10/05/22 10:11:41
C++/CLIやObjective-Cでいいだろ。記法が気に入らないだけなら、どう変えたいのだ？
183:デフォルトの名無しさん
10/05/22 10:19:31
>>181
ゆとりはメモリ管理もできないんだ
許してやれ
184:デフォルトの名無しさん
10/05/22 10:24:38
ゆとりはコンカレントGCもパラレルGCもリアルタイムGCも知らないんだ
許してやれ
185:デフォルトの名無しさん
10/05/22 11:23:21
>>181
採用可能だが採用しないことも可能という言語仕様なら問題ないだろ。
コード流用の観点から言えば十分に検討の余地がある。
頭固すぎだろ。
186:デフォルトの名無しさん
10/05/22 11:41:41
リアルタイムGCが実用になっているとでも
187:デフォルトの名無しさん
10/05/22 11:59:55
リアルタイム処理にはGC使わないほうがいいので
リアルタイム処理専用のコンパイラならGCなしで使うようになってたほうがいい。
GCの言語機能はオプショナルなものとする。
GCありが可能なコンパイラでもオプションによってGCありが選択できる。
コーディング規約等にGCありオプションを付けてはいけないことと明記し
徹底することで対応できるのではないかと。
188:デフォルトの名無しさん
10/05/22 12:16:41
>>181
何で GC 可能を GC 必須にすり替えるんだ。
189:デフォルトの名無しさん
10/05/22 12:17:58
C++/CLIに対する不満はC++ベースであること。
A a;と書いてスタックに領域が取られるのが不満だ。
D言語だと auto A a = new A();と書くことでスタックに領域が取れるのでそうしたい。
Objective-Cは覚えるのに千本ノックが必要で老いた体に叩き込むのはキツイ。
D言語は保守的GCでマネージアンマネージがスタックフレームにごちゃまぜになってるのが不満。
C#はデフォルトGCありであることが不満で新しい言語はデフォルトGCなしが望ましい。
190:デフォルトの名無しさん
10/05/22 12:27:22
現実に存在する言語ではC++/CLIは素晴らしいので
C++/CLI拡張を念頭において新しい言語を作成して欲しいです。
191:デフォルトの名無しさん
10/05/22 14:56:21
パフォーマンスや少メモリーを求めるところではプログラマーが細かくオブジェクトの寿命をコントロールできて
それ以外のところではプログラマーが特に意識せずともメモリーリークが起こらないように処理系が良きにはからってくれればいい。
CGは単なる手段だから、後者を実現できるのであればCGである必要は全くない。
192:デフォルトの名無しさん
10/05/22 14:59:24
CGは板違いですが？
193:デフォルトの名無しさん
10/05/22 15:02:26
Cgのことか？
194:191
10/05/22 15:08:00
CGはGCの間違い
GCはgarbage collectionの略
195:デフォルトの名無しさん
10/05/22 15:13:55
GC必須 : 不可
GC可能 : 許可
196:デフォルトの名無しさん
10/05/22 15:16:21
必須とか可能とか、誰にとっての話？
197:デフォルトの名無しさん
10/05/22 15:16:37
OS制作者
198:デフォルトの名無しさん
10/05/22 15:20:04
OSなんて作りたいように作ればいい。
新言語の仕様に縛られなくていいよ。
199:デフォルトの名無しさん
10/05/22 15:24:55
>>191
何が言いたいかよくわからん
リアルタイム計算や少メモリのような要件のないプログラムはGCあり言語で書いて
そういう要件のあるプログラムはGCなし言語で書けばいいのでは？
だって、別のプログラムだろう？
メモリってグローバルな資源だから、特定のプログラムの一部分は
少メモリである必要があるとか、タイムクリティカルでなくていいとか
そういうことって無いと思うし
200:199
10/05/22 15:27:24
ああそれと、一部分だけタイムクリティカルってケースは
割り込みハンドラとかあんのかな、と思うけど
もしそれだけが問題なら、特定のブロックでGCが実行されないようにさえ
出来ればいいんじゃねえの
大抵そういう手段は用意されてると思うけど
201:デフォルトの名無しさん
10/05/22 15:29:23
GC自体が実行ファイルのサイズを肥大化させる
GCを完全に使わない設定がないと意味が無い
202:デフォルトの名無しさん
10/05/22 15:31:31
>>199
いくつも言語を覚えたくない。
203:デフォルトの名無しさん
10/05/22 15:33:49
GCの使える新言語A と GCの使えない新言語B を作って
簡単にそれぞれ移行出来ればいいな。
204:デフォルトの名無しさん
10/05/22 15:36:15
なんだ言語1個しか使えない無能ちゃんの集いなのか？ここ
今既に言語1個じゃ仕事にならんだろうに
205:デフォルトの名無しさん
10/05/22 15:39:50
ライブラリとは別に機能をアタッチメント式にすればよかろうよ
GCとかメモリ管理とか
206:デフォルトの名無しさん
10/05/22 15:41:12
GCがないと実現困難な言語仕様とかあるから
同時に巻き込まれて無効になる仕様があるのは仕方が無いな
207:デフォルトの名無しさん
10/05/22 16:04:28
Indexテーブルを使った、仮想メモリページ単位の管理にすれば、
大きさの変わるオブジェクトの管理が、
ちょっ速になりそうな気がするんだけどな。
テーブルをどこに置くかが問題だがｗ
208:デフォルトの名無しさん
10/05/22 16:17:48
>>188
そんなんこのスレでもさんざん言われてるだろ
オプショナルなGCは保守的になるんだよ
保守的GCは確実に解放していいと判断できるメモリしか解放できない
効果などあってなきが如し
209:デフォルトの名無しさん
10/05/22 16:44:04
>>208
それはC言語での話でしょ。
C++では保守的ではないマークアンドスイープが実装できるはず。
210:デフォルトの名無しさん
10/05/22 18:47:24
囲碁GCの話は禁止
211:デフォルトの名無しさん
10/05/22 18:59:34
リソースを適切に管理する仕組みであれば、それがGCである必要はない。
212:デフォルトの名無しさん
10/05/22 19:18:05
>>209
そういうことはオプショナルで且つ保守的でないGCを発明してから言ってくれる？
何が「はず」だヴォケ
213:デフォルトの名無しさん
10/05/22 19:30:43
>>212
出来ないと思っている理由は何？
C++はスタック・スタティック確保はコンストラクタ・デストラクタ呼び出すから対応済。
ヒープ確保はnewをオーバーライドすればすべてのインスタンスを追跡できる。
出来ないと思う理由が知りたい。
はずというのはそういう有名なライブラリがないからだができない理由が知りたいわ。
214:デフォルトの名無しさん
10/05/22 19:32:54
「僕がプロ野球選手になったらホウムラン８０本打ってホウムラン王になります。」
215:デフォルトの名無しさん
10/05/22 19:36:51
※クラス定義の話題は、カプセル化機能は欲しいからです。
friend というアクセス制限子があるけども、これってオブジェクト指向的に
必須というわけでもないと思うので、friendは廃止して良いよね。
いやいや、そうじゃないfriendが無いと大変な事になる、こういう場合
組めなくなるという意見があれば教えてください。
216:デフォルトの名無しさん
10/05/22 19:38:24
>>213
C++のポインタや型はナマだから、何の印もついてないし
ポインタと整数と適当に置き換えたりできるのもCと同じだ
それでなぜC++できちんとしたGCが出来ると思うのか理解できん
217:デフォルトの名無しさん
10/05/22 19:39:22
アーキテクチャが対応してないだけで言語の問題じゃないだろ
218:デフォルトの名無しさん
10/05/22 19:42:05
>>213
出来ないなんて誰も言ってないと思うけど？
根拠も実例も示さず妄想だけで議論を進めるのは危険でしょ。
219:デフォルトの名無しさん
10/05/22 19:55:03
>>216
理解してないのはわかった。
220:デフォルトの名無しさん
10/05/22 19:59:09
俺たちはいったい誰と戦っているんだ……!？
221:デフォルトの名無しさん
10/05/22 20:54:04
もうC++は許してやれよ
222:デフォルトの名無しさん
10/05/22 21:30:03
>>213
＞C++はスタック・スタティック確保はコンストラクタ・デストラクタ呼び出すから対応済。
一般にGCのある言語にはC++でいうデストラクタは無い。ファイナライザやディスポーザはヒープ外リソースの開放のためでデストラクタではない。
ましてや、ファイナライザが呼ばれないかもしれないGC付言語もある。
＞ヒープ確保はnewをオーバーライドすればすべてのインスタンスを追跡できる。
この追跡を０オーバーヘッド且つストップザワールド無しで実現できるアルゴリズムが存在しない。存在すれば直ぐに採用されている。
223:デフォルトの名無しさん
10/05/22 21:32:50
C++/CLIなんてのも無しな
あれが汚いと思わないならプログラミングやめたほうがいい
混在させるならGCありをベースにしないと半端になる
構造体はメモリと1:1で余分な追加物無し出ないと
かけないものが出てくる
RTOS並みのマルチスレッド管理をネイティブに言語に組み込めないかね
そういうのベース言語でOS作ってみたいな
224:デフォルトの名無しさん
10/05/22 21:37:41
>>223
頭痛が痛いんだ。
RTOSのスレッドをマルチスレッドと呼ぶのはなんか違うような気がする。
なんか違うけど誤解する程度には似てるので、確かに技術的なロードマップ
はありえると思うんだけど。
ただその場合、それは言語じゃなくてOSの話題になるわけで、
その辺り、自分の言ってる事が無茶苦茶にならないように書けてないので、
君は良くわかってないバカだと思う。
2chに限らず、その辺混乱しちゃうだろうから、と丁寧にかけないバカは
たいてい本当にバカ、二百万の書き込みの内ひとつだけ、こうやって突っ込むと
まともな答えが返ってくるけども、君はバカだと思う。
バカ多すぎ。
225:デフォルトの名無しさん
10/05/22 21:40:52
>>222
おれはC++はマークアンドスイープ型のＧＣは実装可能だといいたいんだけど。
一般的なＧＣ言語の話をして何が言いたいの？
＞この追跡を０オーバーヘッド且つストップザワールド無しで実現できるアルゴリズムが存在しない。
おれはC++で「保守的ではないマークアンドスイープが実装できる」はずといっている。
なぜオーバーヘッドの話になる？
ちなみにC++で実装可能なら、GCの採用不採用選択を言語が保証することは可能ということになるから
C++の仕様からその特性を抽出すればそのような言語は可能という主張ができる。
もしそうならオーバーヘッドの問題は不採用で回避可能だね。
でそのソースコードをマークアンドスイープ型ＧＣ採用のプログラムに流用も可能になる。
226:デフォルトの名無しさん
10/05/22 21:44:07
GCありと、そうでないものを共存させたら、本質的に互換性のないオブジェクトが二種類（さらにプリミティブ型）になるから汚くなって当然。妥協の問題。
227:デフォルトの名無しさん
10/05/22 21:44:47
＞「保守的ではないマークアンドスイープが実装できる」
オーバーヘッドを無視すればだけどな
実際にはオーバーヘッドがあるために採用できない
＞ちなみにC++で実装可能なら
実例出せればカッコイイけどな
228:デフォルトの名無しさん
10/05/22 21:46:51
>>226
両立できないんだよね、だが実際それを実装してしまうMicrosoftにそら恐ろしいもの感じるが。
229:デフォルトの名無しさん
10/05/22 21:47:07
オブジェクトはGCありを前提として設計するのと、そうではないのとでは言語の設計が変わる。共存させたいならそれによる不便も受け入れなくてはならない。
230:デフォルトの名無しさん
10/05/22 21:50:43
結局具体的に指摘したこと(>>213>>225)には反論できない。
で実装を見せない限り認めないと。自分はただ自説を繰り返すのみ。
プログラムは動作していない限り意味がないのは最終的にはそういうものだけど
ただ否定するだけって何も生まないね。
231:デフォルトの名無しさん
10/05/22 21:59:01
>>230
議論の段階は終わったから実装見せてくれ。
実装見せろとか後ろ向きなこというな。
が３スレにわたって繰り返されてる。
勢いを維持したいだけのバカがいるんだよ。
232:デフォルトの名無しさん
10/05/22 21:59:45
>>229
アルゴリズムが違うんだからどっちも完全に同じ結果になるような動作をすることはないね。
最大公約数のなかで記述することになるから面倒になることは間違いない。
GCない場合をデフォルトとして公約数内の範囲で記述すればGC採用上でも動作するというくらいだとおも。
233:デフォルトの名無しさん
10/05/22 22:07:53
>>230
具体的な指摘とはこれ？
＞おれはC++はマークアンドスイープ型のＧＣは実装可能だといいたいんだけど。
とりあえず、スレタイの[超高速]にマッチしているか指摘して欲しい
234:デフォルトの名無しさん
10/05/22 22:20:25
言語で実装可能なライブラリの速度と、言語そのものの速度は別物だと思うんだけど、どうだろうか
235:デフォルトの名無しさん
10/05/22 22:24:22
>>234
そういう質問するレベルなら、書き込むなよ。
初心者すれって山のようにある。
236:デフォルトの名無しさん
10/05/22 22:31:43
>>235 がイラついてることだけはよくわかった
237:デフォルトの名無しさん
10/05/22 22:32:34
GC否定派「GCはランタイムが必要だから嫌」
GC肯定派「こういうGCの方式がある、この言語ではこうしてる」
議論が噛み合ってないんだよ、否定派のランタイムが必要に
対して対論を（ランタイムなしで実現できるGC）を出してこいよ
バカの癖に書き込むなよ。
238:デフォルトの名無しさん
10/05/22 22:34:35
こんなスレに天才プログラマーが集まってるでも？
239:デフォルトの名無しさん
10/05/22 22:36:06
>>236
パタリロ・ド・マリネール８世曰く「いらいらする時はカルシウムを取るといい。」
240:デフォルトの名無しさん
10/05/22 22:38:51
ところで、新言語のGCは何言語で実装するんだ？
241:デフォルトの名無しさん
10/05/22 22:39:24
バカバカ言ってるのは、リアルで普段バカバカ言われて言い返せずストレス貯めてるグズだよ。
242:デフォルトの名無しさん
10/05/22 22:40:45
>>240
新言語自身だろうね。
243:デフォルトの名無しさん
10/05/22 22:41:44
もう脳内で仮想ノイマン式CPUのメモリ演算リアルタイムトレース出来るレベルの人以外書き込み禁止にしようぜ
244:デフォルトの名無しさん
10/05/22 22:42:08
で、今あるすごい実装のGCってどんな言語で書かれてるんだろう
Cかな
245:デフォルトの名無しさん
10/05/22 22:42:13
じゃぁ、新言語のGC作るときにはGC使うなよ。
246:デフォルトの名無しさん
10/05/22 22:43:15
>>245
そりゃそうだろ。
247:デフォルトの名無しさん
10/05/22 22:44:08
いや、お前らならやりかねないから。
248:デフォルトの名無しさん
10/05/22 23:08:48
>>224
理解不能ならそんでいいが
並列記述がOS依存な言語じゃなく
逆に言語とランタイムに入れちまうってこと。
CSPみたいなのは微妙だし。
んでOS書いたらOS自体も並列実行させやすいし。
スレッドみたいなんが1stクラスなら
OSの記述レベルがあがる。
シグナルとか例外なんかもあつかえるかな
ま、与太話だが、並列実行=OSありきつーのは想像力なさすぎだ
ディスバッチャなんざコアはランタイムに十分入るくらい小さいしな。
249:デフォルトの名無しさん
10/05/22 23:13:52
GCありなし混在は汚い。
せっかくメモリ管理自動にするメリットが
二種類のメモリを管理するコストに相殺されちまう。
250:デフォルトの名無しさん
10/05/22 23:33:06
>>249
ヒープとスタックの混在は？
ファイルとメモリーの混在は？
グローバル変数とローカル変数の混在は？
251:デフォルトの名無しさん
10/05/22 23:41:50
>>250
言ってる意味がわかりません。
252:デフォルトの名無しさん
10/05/22 23:45:13
汚いか汚くないか答えればいいんじゃない？
253:デフォルトの名無しさん
10/05/23 00:05:43
GC混在ができる言語は理論的には可能ですよね。
でも、C++ではポインタの追跡ができないんじゃない？
ポインタ禁止、スタックに配列、クラス、構造体の確保禁止、
配列も指定クラスを使いなんらかのマークが付いている。
スマートポインタのみ許可で、スマートポインタには何かマークが付いている。
マネージドなクラスにはクラス情報へのポインタが追加されている。
アンマネージドな関数呼び出し時はNOGC; a(b); GCON;みたいにする。
例外はとりあえず禁止。
等として、レジスタや中途半端な状態のデータだけは保守的にすれば
このへん適当ですけど、完全なGCはできるのかな？
254:デフォルトの名無しさん
10/05/23 00:13:32
Scalaにunmanagedを追加できると仮に考えて
1つ母音をとるとアンマネージドな意味にすると
そんなに汚くなくかけるんじゃないかなと思ったのですがどう思います？
例)
var a:Int = 0; val a:Int = 0; class A{} struct A{} def a(a:Int){}// managed
vr a:Int = 0; vl a:Int = 0; clss A{} strct A{} df a(a:Int){}// unmanaged
255:デフォルトの名無しさん
10/05/23 00:15:14
C++/CLIが存在している以上、マネージとアンマネージの混在は可能。Javaだって、ライブラリを用意すればアンマネージのヒープも使える。しかし、それらでOSがかけるわけではない。
256:デフォルトの名無しさん
10/05/23 00:19:31
なんでOS書けなきゃならないの
257:デフォルトの名無しさん
10/05/23 00:19:41
>>247
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ 俺はGC付き言語でGCを作ったことがあるぞ！
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
258:デフォルトの名無しさん
10/05/23 00:20:38
ちゃんとコピペしろ
259:デフォルトの名無しさん
10/05/23 00:21:30
>>256
OSは神が造り人に与えるものだとでも思っている？
260:デフォルトの名無しさん
10/05/23 00:21:50
GCの話は、
・生ポインタは無し。ただのポインタでもメタデータ付きにするか拡張可能な構造体にする。
・GCは、プリミティブ（ルーチンとか）の管理で必要なら言語として実装する。そうでなければライブラリ
でいいんじゃないの？
もっとプリミティブなポインタとかルーチンの話をしようぜ。
261:デフォルトの名無しさん
10/05/23 00:23:27
>>260
> もっとプリミティブなポインタとかルーチンの話をしようぜ。
以前も同様の書き込みを見たが、話をしたいなら自分から話題を振れ。
262:デフォルトの名無しさん
10/05/23 00:31:23
コンパイラがOSに合わせたコードをはくのであって、コンパイラに合わせてOSがかかれるわけ出刃ない。
263:デフォルトの名無しさん
10/05/23 00:32:02
>>255
現存の処理系による制約はあるが、
言語仕様としてはC++/CLIはCをほぼ完全に包含しているのだから、
CでかけるものはC++/CLIでかける。
即ち、C++/CLIでOSをかける。
264:デフォルトの名無しさん
10/05/23 00:40:01
C++/CLIのランタイムはOSが存在することが前提になっている。また、C++/CLIコンパイラはランタイムが存在してることを前提としている。
一方、Cはランタイムはなくても言語として成立している。
265:デフォルトの名無しさん
10/05/23 00:41:31
現存の処理系による制約はあるが、
言語仕様としてはC++/CLIはCをほぼ完全に包含している
266:デフォルトの名無しさん
10/05/23 00:42:26
>>263
仮にC++/CLIでOS書くとして、低水準な部分は全部#pragma unmanagedでコード書くということ？
たしかにそれでも「C++/CLIで書ける」は偽ではないだろうけど、
CもしくはC++でコンパイルできるコードをわざわざ
C++/CLIコンパイラでコンパイラしているだけという捉え方もできるぞ。
267:デフォルトの名無しさん
10/05/23 00:43:56
どうぞ、お捉えください。
268:デフォルトの名無しさん
10/05/23 00:45:29
>>263
包含してると言っても、水と油が分離している状態だけどな。綺麗に混ざれば問題なかったのだが。
マネージドのクラスのメンバーにC++のオブジェクト変数（ポインタじゃないよ）が作られれば良かったのに
269:デフォルトの名無しさん
10/05/23 00:46:17
新言語では綺麗に混ざるようにしたいね。
270:デフォルトの名無しさん
10/05/23 01:00:16
ふつうは綺麗に分離したいものですが
逆に考えるんですね
271:デフォルトの名無しさん
10/05/23 01:02:27
混ざるというのは、一つの言語仕様に綺麗に入れるってことだろ。
言語仕様の中で上手く統合できるか、綺麗に分離する必要があるかはまた別の議論。
272:デフォルトの名無しさん
10/05/23 01:11:46
GC混ぜる話はループするだけだから無用じゃないか
C++/CLIみたいなゴミを使いたきゃそっち使えばいい
管理情報振ってGCするとか、どんなハイレベルな言語作る気だよ
脳みそ腐ってるやつらばっかだな
273:デフォルトの名無しさん
10/05/23 01:23:41
C/C++とシェルを混ぜてみないか
シェルは文字列しかないからGC楽勝だろ
274:デフォルトの名無しさん
10/05/23 01:25:28
L'Arc?en?Ciel
275:デフォルトの名無しさん
10/05/23 01:33:14
しばらく傍観するわ
GC入れようって訴えてるヤツは「低水準も書ける高水準」を目指してることに気付いてないようだ
本来は完全なスレチなんだが相手するのも疲れた
276:デフォルトの名無しさん
10/05/23 01:37:52
先週も同じことを言ってたよねｗ
277:デフォルトの名無しさん
10/05/23 01:40:56
ガキの頃、「一抜けたー」って言って、誰も付いて来ないからすぐ戻ってくる奴いたよなｗｗ
278:デフォルトの名無しさん
10/05/23 01:42:10
ゆとりはメモリ管理もできないんだ
許してやれ
279:デフォルトの名無しさん
10/05/23 01:47:34
安直でありがちだが、managedとunmanagedで別構文にして管理を分けるんだろうな。
280:デフォルトの名無しさん
10/05/23 01:49:24
そういう流れじゃなかったのに結局自分の知ってるものしか理解できないんだな
281:デフォルトの名無しさん
10/05/23 01:52:23
ですよねー
282:デフォルトの名無しさん
10/05/23 02:19:50
>>275
GC入れちゃうとある程度以下の世界が書けなくかるんだよね
まあmanagedとかの話はほっとくのがいいな
ところで、さっきはアホが寄り付いたが
goroutineとchannelにmutexつかrmcみたいなオペか変数の装飾か
後はレジスタセットみたいな組込みデータ型か
なんてので低レベルな並列言語つーネタはどうよ
283:デフォルトの名無しさん
10/05/23 02:21:27
早速傍観できなくて出てきちゃいました＾＾
284:デフォルトの名無しさん
10/05/23 02:21:42
erlangはふつーにspawnだっけ
285:デフォルトの名無しさん
10/05/23 02:24:13
別人だよ
低レベルな言語にGCとか違和感持つ人間は多いんじゃね
286:デフォルトの名無しさん
10/05/23 02:26:20
別にいいんだよ。匿名掲示板だし。
書き込まれている内容が重要であって、誰が書き込んだかなんて関係ないから。
287:デフォルトの名無しさん
10/05/23 02:31:49
ＧＣ必須といってる奴なんて少数派なのになんでシャドウボクシングしてるんだろうね
288:デフォルトの名無しさん
10/05/23 02:34:18
ですよねー
289:デフォルトの名無しさん
10/05/23 02:35:39
C代替にGC使えたらいいなーはあってもGC前提はなかんべ
290:デフォルトの名無しさん
10/05/23 02:36:34
なら安心した
書き込みが目立つだけか
291:デフォルトの名無しさん
10/05/23 02:41:30
1名勘違いしているのが紛れ込んでいるようだが
GCを使うプログラムも、GCを使わないプログラムも両方書けるようにするには
言語仕様にはGCが入ることが必須になるんだよ。
言語仕様にはGCが必ず入っていて、
その仕様に基づいて作られるプログラムでは、GCを使う、使わないは任意に選べる。
言語仕様にGCが入ったからといって、GCを必ず使わなければならないということはない。
292:デフォルトの名無しさん
10/05/23 02:43:49
混在もあかんやろ
GCはメモリの生存時間をシステムに委ねて楽するわけだ
言語仕様も小さくなってきれいになる
楽とミスを減らすための機能なのに
区別して書くとか逆向き
293:デフォルトの名無しさん
10/05/23 02:44:17
言語仕様に含まれているとド素人ほど使いたくなってしまうからな
そういう意味では言語仕様に含めることはリスクを伴う
CGに反対しているのは自制の意味を込めているのだろう
294:デフォルトの名無しさん
10/05/23 02:46:27
・全てのリソースをGCに委ねる。
・GCに委ねるリソースと委ねないリソースを混在。
・全てのリソースをGCに委ねない。
どれにするかは、開発内容によって選べば良い。
295:デフォルトの名無しさん
10/05/23 02:47:02
ワーニングやコンパイルオプションも言語仕様に含めればいいんじゃないの？
296:デフォルトの名無しさん
10/05/23 02:49:01
うむ。この話は無限ループだな
俺もしばらく様子見。
297:デフォルトの名無しさん
10/05/23 02:49:04
静的と動的も区別できない奴が力説してる
298:デフォルトの名無しさん
10/05/23 02:50:25
>>275 >>296
無限ループって怖いねｗ
299:デフォルトの名無しさん
10/05/23 02:54:14
>>297
反論を恐れてアンカーすらつける勇気ない奴がごちゃごちゃ言うなｗｗ
300:デフォルトの名無しさん
10/05/23 02:54:32
>>299
おまえだよ
301:デフォルトの名無しさん
10/05/23 02:55:59
コードを使いまわしたいというのとGCありとGCなしを同一プログラムで混在させたいというのは別物。
302:デフォルトの名無しさん
10/05/23 03:03:47
話を先に進めたいんならGCなしでやっちゃえよ
どこかの天才が混在可能なオサレな文法作ってくれたらその時に考えればいい
303:デフォルトの名無しさん
10/05/23 03:04:06
>>298
別人だってw
人にケチつけてないで
お前こそなんかネタ振れよw
嫁もワンコも寝ちまってヒマなんだからよ
304:デフォルトの名無しさん
10/05/23 03:12:16
なんか典型的過ぎてイタイ
305:デフォルトの名無しさん
10/05/23 03:18:07
>>302だな
306:デフォルトの名無しさん
10/05/23 03:20:52
ここはGCスレの代理戦争カー！
307:デフォルトの名無しさん
10/05/23 06:04:03
完全なGCをするための、スタックフレームの使い方なのだけど、
アンマネージドな関数とマネージドな関数のスタックフレームは
別々に分けるとGCしやすくていいと思ったのだけどどうだろう？
コルーチンの呼び出しみたいに切り替えるの。
アンマネージド(GC起動前)→GC起動→マネージド→GC停止→アンマネージド
というようにすればいいと思ってたのだけど
スタックが分かれていればこうできるかなと。
アンマネージド(GC起動前)→GC起動&スタック切替→マネージド→スタック切替
→アンマネージド→スタック切替→マネージド…
こんなことがC++/CLIで起こってるのかな？
308:デフォルトの名無しさん
10/05/23 06:27:42
フルーチンとマネージャー
だけ読んだ
309:デフォルトの名無しさん
10/05/23 07:25:53
フルチンマネージャ
310:デフォルトの名無しさん
10/05/23 07:51:27
フルチンじゃなくて、フ・ルーチンな
311:デフォルトの名無しさん
10/05/23 09:44:31
URLﾘﾝｸ(source-ore.up.seesaa.net)
312:デフォルトの名無しさん
10/05/23 10:27:16
>>307
恐ろしくいろんなことを勘違いしてるように感じるのだけど、
その勘違いを紐解けない。Wikipediaのスタック、コールスタック
の記述を読んだだけでコードを書いたこと無い、似非プログラマーが
書いたって感じ。
313:デフォルトの名無しさん
10/05/23 10:58:36
実際につくってないからなｗ
勘違いしてて出来ないならそれはそれでいいんだ。
出来たらいいなってことで、ああしたらできるかな、こうしたら出来るかな？
って考えてるだけなので。今のところ。
GCありなし混在言語なんて、ほとんど誰も作ったことないだろうから
やってみるのがいいんでしょうね
314:デフォルトの名無しさん
10/05/23 11:12:13
スマポをＧＣと認めないとは随分反主流派ですね
315:デフォルトの名無しさん
10/05/23 11:13:33
Objective-C
316:デフォルトの名無しさん
10/05/23 11:33:00
「C言語って、16bitマイコンで動くファームウェアとかの開発でも使われてるんだけど」
「16bitマイコンで動くファームウェアがC言語で書かれているはずがない！」
「えっ？」
317:デフォルトの名無しさん
10/05/23 15:03:30
8bitマイコンを忘れないで
318:デフォルトの名無しさん
10/05/23 16:20:30
基本スマートポインターでいいけどな。ダメなケースをコンパイラが検出してくれれば。
319:デフォルトの名無しさん
10/05/23 16:31:32
メモリ管理は自分でやりたい
320:デフォルトの名無しさん
10/05/23 16:32:54
自分でやりたい人は、自分でやれるように
処理系にやらせたい人は、処理系にやらせれられるように
両方対応するのが望ましい。
321:デフォルトの名無しさん
10/05/23 16:33:17
>>319
スマポなら、自力管理から自動管理まで用途に応じて幅を持たせられるから便利だね。
322:デフォルトの名無しさん
10/05/23 16:34:31
>>314
しー、言っちゃだめよ。議論が終わっちゃうでしょ。
323:デフォルトの名無しさん
10/05/23 16:36:43
「スマポをＧＣと認めない」なんて話題出してるのは>>314だけだけどな。
324:デフォルトの名無しさん
10/05/23 16:58:08
>>323
君には理解できなかったんだね残念
325:デフォルトの名無しさん
10/05/23 17:02:23
まあ落ち込むな。
次は人に理解してもらえるように頑張れ。
326:デフォルトの名無しさん
10/05/23 17:04:16
あんまり頑張れとか言うと自殺しちゃうよｗｗ
327:デフォルトの名無しさん
10/05/23 17:05:45
具体的な指摘が出来ないから煽り始めた
328:デフォルトの名無しさん
10/05/23 17:06:07
人に理解してもらう前に、理系学部（計算機学科じゃない）なら
一般教養で勉強するレベルの事すら理解してないで、そこまで
理解してる人はいないんだからと書いてるやつは、勉強しなおすべきだと思う
ｽﾚﾘﾝｸ(tech板)
いいスレがあるんだけど、この本を読めるレベルじゃなくて、
書けるレベルがここに参加していい最低限度のレベル。
329:デフォルトの名無しさん
10/05/23 17:08:01
Japanese is ok.
330:デフォルトの名無しさん
10/05/23 17:08:11
>>313-314と読んで>>323なら人工無脳としか思えん
331:デフォルトの名無しさん
10/05/23 17:09:47
>>314が必死過ぎて笑える
332:デフォルトの名無しさん
10/05/23 17:10:57
横だけど必死なのはお前に見える
333:デフォルトの名無しさん
10/05/23 17:11:46
横ｗ
334:デフォルトの名無しさん
10/05/23 17:12:56
ここまで全部俺の自演
335:デフォルトの名無しさん
10/05/23 17:14:19
いや俺の自演
336:デフォルトの名無しさん
10/05/23 17:40:51
結局、プログラミング言語はリソース管理を如何に行うかだからな。
この分野はさんざん研究されているだろうから、
最新の最も簡単に安全に効率よく出来る手法を持ってきて
あとは最近ハヤリの構文や機能と上手く融合出来れば良いね。
337:デフォルトの名無しさん
10/05/23 17:42:14
リソース管理って?なんか言葉がちょっと抽象的な感じがするんだけど。
具体的にはどんなこと?
338:デフォルトの名無しさん
10/05/23 17:48:19
メモリー、ファイル、通信、プロセス、スレッド、各種デバイス、他
339:デフォルトの名無しさん
10/05/23 17:50:02
排他制御とかも
340:デフォルトの名無しさん
10/05/23 17:51:32
そっかw というか、「この分野」じゃなくて、全部じゃないかw
341:デフォルトの名無しさん
10/05/23 17:54:03
全部っていっても、リソースそのものの扱いではなく、その生成／消滅を扱う分野だろ？
342:デフォルトの名無しさん
10/05/23 17:56:15
じゃあメモリ確保とか、ガーベージコレクタとか、いつもの話題に戻るわけね。
343:デフォルトの名無しさん
10/05/23 18:02:46
>>336-342
ＯＳとプログラミング言語を意図的に（もしくは白痴）
混同してる。そしてそのことに何の疑問ももたない自作自演。
もうね、本当にね。バカばっかり。
344:デフォルトの名無しさん
10/05/23 18:03:31
>>343は病気なので触れないでください。
345:デフォルトの名無しさん
10/05/23 18:13:18
いい記事があったんだけど、
ポインターの定義構文と使用構文にやっぱ問題あるよな。
URLﾘﾝｸ(builder.japan.zdnet.com)
これでもかって言うぐらいに、間違えてくれてるんだ。
これを反面教師にして、ポインターの宣言とアドレスの取り扱い
周りの構文を考えたいんだけど、どうかな、Ｄ言語の場合が
参考になるわけなんだけど、Ｄ言語レベルで充分かなとも思うし。
それにしても、この人、良くこの文体で書けるなぁって思う。
ＩＢＭでこの文体で、この内容ってことは、
キ○○イに近いような気がする。
346:デフォルトの名無しさん
10/05/23 18:13:31
言語自体が扱うのはCPUとメモリ
スレッドはアリだな
occamみたいなん面白い
347:デフォルトの名無しさん
10/05/23 18:34:47
とりあえず
絶 対 に 入 れ る な
って機能先に洗い出して、残った物に優先順位つけてけばいいかと
348:デフォルトの名無しさん
10/05/23 18:39:10
超高速が目的なんで、VMとGCは絶対入れない機能だな
349:デフォルトの名無しさん
10/05/23 18:44:08
絶対に入れたいのは、並列処理だね
デフォルトでマルチスレッド・マルチコア環境前提でいい
350:デフォルトの名無しさん
10/05/23 18:50:30
並列化のスレッディングのアルゴリズムを記述できてライブラリとして供給する。
言語仕様に固定で組み込むのは駄目。あくまでもすべてを記述できる低級言語
351:デフォルトの名無しさん
10/05/23 18:57:23
絶対に入れるな？
variant型とかか
352:デフォルトの名無しさん
10/05/23 19:00:13
variant、GCは言語仕様に入れない。使いたい人がライブラリで実装すればいい。
353:デフォルトの名無しさん
10/05/23 19:06:22
「入れない」って列挙したものについては、
少なくとも設計がひと段落するまでは（欲しいか欲しくないかは別にして）
仕様に関係する議論から排除できるな
354:デフォルトの名無しさん
10/05/23 19:12:54
トリップをつけて「入れない」と宣言した機能は、そのトリップではその機能を議論しないという決断だと受け止めていいよ。
その他の自由な議論を阻害するものではない。
355:デフォルトの名無しさん
10/05/23 19:16:27
入れると言った人もトリップ付けて、責任もって入れることにしたら
議論が正常化すると思う。ＣＰＵは問わないけどもアセンブラリストを
要求された時点でＵＰする事。にすれば良いと思う。
356:デフォルトの名無しさん
10/05/23 19:16:28
どうせ本気で言語なんて作らないくせに
357:デフォルトの名無しさん
10/05/23 19:17:51
>>356
>>354-355で、本気の人だけになると思う。
そしてトリップ無しでの発言は基本荒らし行為って
事にすれば良いんだよ。
358:デフォルトの名無しさん
10/05/23 19:20:18
なるほど。
つまり>>357は荒らし行為ってことだな。
359:デフォルトの名無しさん
10/05/23 19:26:43
ある程度議論ルール固まったらＷｉｋｉってもいいかもんね
鳥無しの基本嵐認定は行き過ぎだが、鳥有り議論に対する影響を少なくするってのはありだな
要望っていうかスタンスがあるなら鳥つけろ、妄想垂れ流すだけで邪魔するなら荒らし認定されるんだろう
論理的で根拠がある話なら鳥有りが意見を組み入れるだろうし
360:デフォルトの名無しさん
10/05/23 19:28:18
>>352
初心者が全部の機能を使いたくなる気持ちはわかるけど
言語仕様に入っていても不要な機能は使わなければいいだけだよ。
361:デフォルトの名無しさん
10/05/23 19:29:29
議論するのはいいけどさ
コンパイラ作れる奴いるの？
いたとして、作る気あんの？
そこ抜きに話しても無駄に終わるぜ
362:デフォルトの名無しさん
10/05/23 19:32:33
>>359
「鳥付けろ！」とか「鳥無しばかりだから傍観するわ」とか言って荒らす奴が出てくるから鳥を余り強調しない方がいい。
付けたい奴が付けるだけでいい。
発言を尊重するかどうかは、鳥の有無によってではなく、あくまでもその内容によるべきだ。
363:デフォルトの名無しさん
10/05/23 19:34:24
>>362
確かにそうだな
364:デフォルトの名無しさん
10/05/23 19:34:28
>>359
Ｗｉｋｉは議論に向かないので、fj.comp.langに移動が良いと思う。
fj.comp.lang.cを間借りさせてもらうか、場合によっては作ってもらう
ってことで。雑音はいりにくいし（ｗ
365:デフォルトの名無しさん
10/05/23 19:37:23
>>363
そんなこと無いと思うよ。とりなしを無視できな奴もバカって
事にすれば良いだけ。とりなしをＮＧＩＤにすればすっきりするし。
ということで、鳥必須ってことで。
366:デフォルトの名無しさん
10/05/23 19:40:45
IDないぞ
367:取りに行くです ◆JZ1SFn6i7c
10/05/23 19:43:14
>>366
あっそうか、じゃあ鳥+コテハンって事で、デフォルト名無しさんを
ＮＧワードにするって事で。
368:デフォルトの名無しさん
10/05/23 19:44:07
お好きにどうぞ。
369:デフォルトの名無しさん
10/05/23 19:46:10
そこまで仕切って仕様を確定までして
コンパイラ作る技量ないとか言ったら
全部無駄になるんだが
そこんとこ分かってんのか？
370:デフォルトの名無しさん
10/05/23 19:48:23
どのレスを読むかは個々人で好きに決めればいいと思うよ。
NGもわざわざ宣言せずに黙ってやればいいし。
このスレでは内容にかかわらないところで発言の仕方を縛るようなことは一切しない。
レスの取捨選択はあくまでも個々人でやるべきことだから。
371:取りに行くです ◆JZ1SFn6i7c
10/05/23 19:49:39
以下いらない宣言。
ＧＣ 多値戻り
372:デフォルトの 名無しさん
10/05/23 19:51:40
既にNGされてる気がする
>>371
お前はコンパイラ作れるのか？
まずそれが知りたい
373:デフォルトの名無しさん
10/05/23 19:54:30
そういえば、多値戻りの話もあったなｗ
多値を扱うデータ型を用意して、関数（メソッド、サブルーチンコール、…）の入出力で自由に使えるようになっていると便利だな。
374:デフォルトの名無しさん
10/05/23 20:06:17
やはりC言語は神の作りたもうた言語だな
375:デフォルトの名無しさん
10/05/23 20:09:56
館はタプルでライブラリ行き。
ライブラリでできるものはライブラリにしないといつまでも作れないよ。
低級言語だから欲張らないことだ。
376:デフォルトの名無しさん
10/05/23 20:34:10
無名メンバー名無しの構造体と考えたら
タプルは基本データでいいんじゃない
377:デフォルトの名無しさん
10/05/23 20:37:40
C++0xみたいに構造体をreturnで初期化可能にする文法と
型推論のautoを導入すれば
struct { int a, b, c; } foo() { return { 1, 2, 3 }; }
auto x = foo();
printf("%d, %d, %d\n", x.a, x.b, x.c);
のようなことができる
378:デフォルトの名無しさん
10/05/23 20:54:34
すげーわろた
379:デフォルトの名無しさん
10/05/23 21:21:19
>>377
俺もそれがいいと思う。
380:デフォルトの名無しさん
10/05/23 21:22:07
URLﾘﾝｸ(www.objectclub.jp)
GCに関する議論がこの辺にありました。
考えてる人は考えているのですね。
381:デフォルトの名無しさん
10/05/23 21:28:28
C++でのGCについては0xで議論されてるよ。
結局入らなかったけど。
382:デフォルトの名無しさん
10/05/23 21:53:32
variantは、言語仕様にいれても低水準とは矛盾しない。
ライブラリでも実現できるが、見た目は悪くなる。
383:デフォルトの名無しさん
10/05/23 22:14:08
透過的なガーベジコレクションですか。
URLﾘﾝｸ(d.hatena.ne.jp)
結論からいうと、 C++0x に GC は入りません。
C++0x では、透過的な GC の導入が間に合わないので、
最低限の決めごとだけを行います。
なるほど。Hans Boehm 直々のペーパーもある。
384:デフォルトの名無しさん
10/05/23 22:23:50
>>380
日付を見ろよ、終わった議論なんだよ（ｗ
385:デフォルトの名無しさん
10/05/23 22:44:46
終わった議論であるなら、その結論は？
386:デフォルトの名無しさん
10/05/23 23:03:50
結論を問うと止まるスレ
387:デフォルトの名無しさん
10/05/23 23:21:49
>>382
variantの実行時オーバーヘッドってどうなの？
オーバーヘッドの程度によって使える場面は制限されるよね。
388:デフォルトの名無しさん
10/05/23 23:40:28
>>387
どれだけオーバーヘッドがあっても、言語仕様上は問題ないでしょ。
コプロがないと浮動小数点演算は整数演算の何百倍もかかるけど、言語仕様上は何の問題もない。
389:デフォルトの名無しさん
10/05/23 23:42:06
だから、別に言語仕様上問題あるなんて一言も言ってないよ。
オーバーヘッドがどれくらいなのかなって聞いているんだよ。
390:デフォルトの名無しさん
10/05/23 23:47:27
>>389
オーバーヘッドがあると何か不都合か？
391:デフォルトの名無しさん
10/05/23 23:48:08
C/C++に代わる低級言語を開発したい
なんのために？ 趣味？
392:デフォルトの名無しさん
10/05/23 23:49:27
>>390
程度によって使える場面が限られるでしょ？
最内周ループでは使わないようにしようとか。
393:デフォルトの名無しさん
10/05/23 23:54:42
>>392
その程度は実装によるから何とも言えないでしょ。
現実場面では、自作の共用体を使っていろいろするよりも高速になることが多いと思うが。
394:デフォルトの名無しさん
10/05/24 00:03:36
実装によるのは当然だけど、
例えば、実装によって型情報を保持する分負荷が増えるとか、
定性的な議論ができればと思って聞いたんだけどね。
いいや、別に。
395:デフォルトの名無しさん
10/05/24 00:17:43
トリップ入れてない人を相手にするのも嵐です。
396:デフォルトの名無しさん
10/05/24 00:26:30
ここから俺の自演だから
397:デフォルトの名無しさん
10/05/24 01:31:14
リフレクションは欲しい
398:デフォルトの名無しさん
10/05/24 02:09:31
リフレクションって設計に失敗してるプログラムで使うイメージしかない
399:デフォルトの名無しさん
10/05/24 03:11:11
結局低レベルってのから一瞬で離れるんだな
400:デフォルトの名無しさん
10/05/24 03:24:03
名前付き引数に対応してね☆ミ
401:デフォルトの名無しさん
10/05/24 03:43:27
クロージャと継続もほしいゆ
402:デフォルトの名無しさん
10/05/24 07:38:32
欲しい → 不要
あったら嬉しい → 不要
必要 → まれに必要
どうしても必要 → たまに必要
必ず必要 → もしかしたら必要
403:デフォルトの名無しさん
10/05/24 08:01:31
>>401
同意
404:デフォルトの名無しさん
10/05/24 09:18:39
名前付き引数は低レベルでも問題ない
405:デフォルトの名無しさん
10/05/24 09:24:06
リフレクションも低レベルでも問題ない。
406:デフォルトの名無しさん
10/05/24 09:28:27
c++0xでの議論
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)
407:取りに行くです ◆JZ1SFn6i7c
10/05/24 15:11:06
リフレクションはいらない。
名前付き引数は、コンパイル時にオーバーヘッドが解消できる事と、
（コンパイラが呼び出し関数に合わせて順番変えてやれば良いだけ）
関数定義や例外処理を変更したいって言ってる俺としては、有りかもと思う。
408:デフォルトの名無しさん
10/05/24 17:30:00
>>407
だからお前コンパイラ作れるの？
409:デフォルトの名無しさん
10/05/24 17:40:49
>>408
バカばかりでお前もバカの一員だと思うんだけど、
しつこいから答えると、その質問する奴がバカだと思う。
最適化ぶりぶりのコンパイラ作るのには、物凄いセンスが
必要だけども、コンパイラってようは単純なテキスト置換
処理なんだから、コンパイラを作れないと言う奴は、プログラムを
組めないと言ってるに等しい。つまり質問が無茶苦茶なんだよ。
そんな質問を平気でするのは馬鹿だからバカは黙ってて欲しい。
410:デフォルトの名無しさん
10/05/24 18:02:16
リフレクション自体は実行時にオーバーヘッドがあるかもしれないが、
リフレクションが有っても他の機能を阻害することはないから
リフレクションは言語仕様に含めていいと思うよ。
411:デフォルトの名無しさん
10/05/24 18:18:45
> コンパイラってようは単純なテキスト置換処理なんだから
シンボルテーブルまで作って単純なテキスト置換処理はないわな
412:デフォルトの名無しさん
10/05/24 18:27:23
シンボリックテーブルじゃね？
413:デフォルトの名無しさん
10/05/24 18:32:36
シンボリティフィケーショニングテーブル
414:デフォルトの名無しさん
10/05/24 18:39:03
シリコン？
415:デフォルトの名無しさん
10/05/24 18:45:24
>>409
つまり 取りに行くです ◆JZ1SFn6i7c はこういう考えの持ち主なわけね
コンパイラ＝テキスト置換ツール
OK把握した
416:デフォルトの名無しさん
10/05/24 18:52:14
>>409
どこまでヌケサクなの？
そのテキスト置換処理において、膨大な置換ルールを破綻無く実装する能力を持ってるか聞いてるんだけど？
質問が滅茶苦茶なんじゃなく、お前の読解力が滅茶苦茶貧弱なんだよ。
417:デフォルトの名無しさん
10/05/24 18:59:33
>>416
バカを重ねるな。
418:デフォルトの名無しさん
10/05/24 19:03:20
お前がなｗ
特徴的な改行、いつものキチガイ君だろ
419:デフォルトの名無しさん
10/05/24 19:09:27
俺もそう思う
420:デフォルトの名無しさん
10/05/24 19:11:48
>>409
私には無理なので貴方が作って下さい
421:デフォルトの名無しさん
10/05/24 19:41:31
>>420
黙ってれば良いと思う、君に出来るのはそれだけ。
422:デフォルトの名無しさん
10/05/24 19:48:26
>>421
作らないのならあんたも黙ってろ
423:デフォルトの名無しさん
10/05/24 19:50:57
あたいもそう思う。
424:デフォルトの名無しさん
10/05/24 20:00:14
このスレにはそれぞれが出来る範囲で参加すればいいよ。
何かを作らないから書き込んではいけないとか、そういうことは一切ない。
425:デフォルトの名無しさん
10/05/24 20:09:30
でもコンパイラ作る人が一人もいなけりゃ絵に書いた餅で終わるで
426:デフォルトの名無しさん
10/05/24 20:11:02
絵に描いたもちでも綺麗に書けてればいいと思うんだけど、
お餅とウンコの区別がつかない人が書き込むから駄目。
>>424
遊び場欲しくてそんなこと書いちゃうバカなんだと思うけど
バカの遊び場じゃないよ。
427:デフォルトの名無しさん
10/05/24 20:12:22
また病気の人が来てるね。
428:デフォルトの名無しさん
10/05/24 20:12:43
コンパイラという形にならない事が分かってたら
議論する気も起きない
429:デフォルトの名無しさん
10/05/24 20:15:17
議論する気が起きないなら書き込まなくていいよ
430:デフォルトの名無しさん
10/05/24 20:17:37
6スレにもなって成果が全く無い理由を考えてみたまえ
みんな適当に書き捨ててるだけなんだよ
取りまとめ役と処理系制作者がいないと
進むものも進まない事くらいそろそろ分かれ
431:デフォルトの名無しさん
10/05/24 20:24:20
>>430
＞6スレにもなって成果が全く無い理由を考えてみたまえ
バカが書き込んでスレを汚すから。
432:デフォルトの名無しさん
10/05/24 20:24:39
自己紹介乙
433:デフォルトの名無しさん
10/05/24 20:44:10
わ、わたし１４歳で胸の大きさに悩んでる女子中学生のおっさんだけど、この流れみてたらコンパイラ作る勉強してもいいかな、・・・って思っちゃった///
434:デフォルトの名無しさん
10/05/24 20:48:04
まとまらない原因は、スレタイに性質の異なる２言語を入れてしまっていること。
次は、CとC++でスレを分割すべし。
435:デフォルトの名無しさん
10/05/24 21:07:12
てか、このスレって簡単なコンパイラくらい
作ったことあるやつばっかじゃないの
普通高校生か大学生あたりで作るだろ
436:デフォルトの名無しさん
10/05/24 21:07:47
「超高速」「低級言語」を分かってない者が多いので、「【GC】低速高級言語【VM】」にも分割すべし
437:デフォルトの名無しさん
10/05/24 21:18:49
>>434
同意。
てか、たぶんCを超えるのは無理だからC++だけでいいんじゃね
438:デフォルトの名無しさん
10/05/24 21:20:38
０オーバーヘッドならどんなに文法が汚くても許容する。C++サイコー
439:デフォルトの名無しさん
10/05/24 21:25:15
C++は汚すぎる
440:デフォルトの名無しさん
10/05/24 21:26:31
>>434
まさに第二のCが目標なら、やることやれることは
そんなに多くないんじゃないかね。それでさえ迷う部分は多いがｗ
技術の進歩に伴って、いくつかの仕様は削れる
（register指定子、プロトタイプ宣言など）
長い歴史の中でC文法の問題点も明らかになってきた
でも本質的な部分はそれほどいじりようがないはず。Cはよくできてる
スレッド周りのサポートを入れて、あと名前空間とライブラリ？
超高速なんて簡単に言うが、アグレッシブな最適化を期待するなら
言語としての表現力に制約を加えて、処理系が仮定していい条件を増やしてやらないとダメ
プログラマが低水準を精密に操作したいという要求とは、かなり背反してしまう
441:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 21:32:58
>>440
お前センス無いなぁ、最適化を強力にするためには言語の表現力を
高めないと駄目なんだよ。ポインターと整数を可換にしたから
ポインター演算と整数演算の最適化に苦労したんだよ。
なので、関数にParametor引数、Result引数なんだよ。
そして関数属性；const関数、pure関数、General関数
442:デフォルトの名無しさん
10/05/24 21:36:01
Parametor
443:デフォルトの名無しさん
10/05/24 21:40:47
>>440
FORTRANコンパイラの最適化は神だからなｗ
Cのrestrictなんてのも結局プログラマ責任だし。
しかし文法的な問題ってさほどなくないか？
444:デフォルトの名無しさん
10/05/24 21:41:58
>>440
C++のautoやC#3.0程度の型推論はつけられるだろうし欲しい
個人的にはコルーチンもあると良い
最後らへんはFortranのほうがベクトル演算最適化しやすいとか
純粋関数型のほうが並列化しやすいとか
手書きループより抽象化されたmap/reduceのほうがいいとかいう話だよね？
基本的には同意
445:デフォルトの名無しさん
10/05/24 21:49:22
だれか441にも突っ込んでやって下さい
446:デフォルトの名無しさん
10/05/24 21:53:35
型推論は欲しいね。
447:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 21:54:16
>>445
レベルが違いすぎて無理だと思うよ。
442の為に、ちゃんとポイントは作ってあげた。
らそこは速攻だったのでその程度人しか今はいないと思う
>>442レベルの人が書き込まなくならないと無理だと思う。
448:デフォルトの名無しさん
10/05/24 21:55:10
らそこ
449:デフォルトの名無しさん
10/05/24 21:57:41
コンパイル時に処理できるものはどんどん入れてもいいな。
450:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 22:16:30
>>449
ランタイムを必要しないものと、
型安全性を破壊しないものは
有っても困らないとは思う。
データーの型はプログラマが明示的に破壊しない限り、
破壊できない事変わらないことが大切だと思うんだよね。
なので暗黙の型変換とかautoは禁止が良いと思う。
あと、autoはテンプレートにとっておきたい気もするし。
ともかく、安全に組める、早くできるという方向で行くべきだと思う。
451:デフォルトの名無しさん
10/05/24 22:19:40
autoは型安全だよね。
452:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 22:21:33
>>451
プログラマが理解してない場合がありえる、
と言う意味で型安全じゃない。
プログラマが理解してないのにコンパイルが通るので駄目
453:デフォルトの名無しさん
10/05/24 22:23:28
オレ定義
454:デフォルトの名無しさん
10/05/24 22:25:38
一文一文プログラマーの理解度をチェックする対話型コンパイラーとかいいね。
455:デフォルトの名無しさん
10/05/24 22:27:14
>>454
コンパイルする人間からプログラマを推定するのが型安全じゃないだろｗ
456:デフォルトの名無しさん
10/05/24 22:28:47
>>441
CPU固有言語君は美的センスを磨いた方がいい
C#とかC++に汚染されてる
中途半端な言語じゃなくLispとSmalltalk勉強しておいで。
457:デフォルトの名無しさん
10/05/24 22:29:43
触っちゃダメ
458:デフォルトの名無しさん
10/05/24 22:34:06
まあしかし関数型言語もいずれはPrologと同じ道を辿って
20年後もCを使っている気がするな
459:デフォルトの名無しさん
10/05/24 22:35:50
Prologより関数型言語の方が古いけどな
460:デフォルトの名無しさん
10/05/24 22:38:04
20年内に論理型言語の復権はありそうだけど。
461:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 22:40:23
>>456
aa.x86_rot(bit=CF)を提案してのは俺だけど、CPU固有言語という
言葉の元になったのは別人だと思う。
environmentというコテハンは一回使ったかなっておもう
後、継承はともかく、クラス、カプセル化は必須。
462:デフォルトの名無しさん
10/05/24 22:41:14
APLの復権はまだか
463:デフォルトの名無しさん
10/05/24 22:45:21
メンバーを指定するであろう位置に予約語を置いてしまう美的感覚が凄い
名前空間は無用に荒らしたくないよね
464:デフォルトの名無しさん
10/05/24 22:49:58
>>449
マクロ、テンプレート
型推論
465:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 22:51:43
>>463
お馬鹿な君達の為にあえてああやって書いて、
それじゃあそうなるから、こういう記述が
良いんじゃないかとか言わしてあげられるように
してあげてるのに、ぶーぶー文句言うばかり。
466:デフォルトの名無しさん
10/05/24 22:55:45
特に魅力があるわけでもない得体のしれないものを良くしようとは思わない。
どんなに酷くても何か一つでも輝きがあればいいんだけどね。
467:取りに行くです。 ◆JZ1SFn6i7c
10/05/24 22:57:19
>>464
マクロ→廃止
型推論→いらない
テンプレート→STLとはまったく別物（記述がわかりにくすぎるよ！！）
テンプレート実現のための型推論は必要。
>>466
なに？俺のこと？俺の提案の魅力を理解できない奴は書き込むなよ。
468:デフォルトの名無しさん
10/05/24 22:59:12
ちょいお遊びでキャリーを扱うのを考えてみた
あれほどのvolatileなデータだからやはり特殊変数以外ない
で'.'をキャリー、@をローテートとして
a = b + c
d = e + .
d = e +. f
これでADD/w C
a <<@ でローテート
a <<@. でローテートwC
ただのマクロアセンブラのようだ
469:デフォルトの名無しさん
10/05/24 23:01:23
Cの型は安全のためではなくて、アドレスやサイズを計算することが目的。
危険か安全かは関係なく、ただ書かれた通りに計算するだけ。
型＝安全という論点を強調するとCの代替案にはなれない。