トップページ⇒tech
983コメント296KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2010/05/07(金) 11:36:35
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 4
http://pc12.2ch.net/test/read.cgi/tech/1271980246/
0002デフォルトの名無しさん2010/05/07(金) 11:37:28
◆新言語の要件 v0.1◆

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


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
0003デフォルトの名無しさん2010/05/07(金) 11:40:03
286* 名前：デフォルトの名無しさん [] 投稿日：2010/04/27(火) 19:07:54
Ｃ言語の問題点。
１、コンパイラを軽く書きたいので色々端折ってる
２、軽く書きたいと良いながら、先読みが必要だったりする
３、軽く書けるので膨大な方言が発生し、それの取りまとめで仕様がボロボロ
４、機能の追加が必要最小限に留められているので、色々中途半端

Ｃ++の問題点
１、Ｃ言語との互換性を重視したので、記号が珍妙
２、追加、追加が多すぎて、なにがなんだか状態
３、オブジェクト指向の学識が高まるのと歩調を合わせた結果仕様が複雑
４、Ｃ言語の欠点を引き継いでしまってる

さて、以上の欠点は総て、言語が生まれた当時はまだ分かっていないことや、
当時では無理だったことが、後年解決された事など、色々に理由があって、
単に順調に成長した言語だから発生したとも言える。

そこで、プログラミング言語40年の歴史から学べる知見を総動員して、
Ｃ言語的なプログラミング言語を過去の遺産にとらわれず、今、開発
するとすればどんな仕様になるのだろうか？という事。
0004デフォルトの名無しさん2010/05/07(金) 11:42:16
450 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/30(金) 16:32:34
GC有り言語とGC無し言語ではメモリに関する考え方がまるで違うから、
学習者からすれば一つの言語に混在するのは良くないんじゃないかな。

低レベルならC/C++でいいけど、
何でも有りすぎて「やっちゃいけない」ことが多すぎるから、
できることを減らしていいからミスが少なくなるようなコンパクトな文法がいいな。
標準ライブラリの整理(scanfなんかいらない）や充実も必要に思う。

良い言語の条件は、
・読みやすい・メンテしやすいこと(他人の書いたperlコードなんて読みたくない）
・ライブラリが充実してること(画像読み取りぐらいは標準ライブラリに欲しい)
・熟練者じゃなくてもミスのないプログラムが書けること
なんじゃないかなと思う。
0005デフォルトの名無しさん2010/05/07(金) 11:48:25
◆新言語の位置づけ◆

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

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
0006デフォルトの名無しさん2010/05/07(金) 11:48:50
えらい早漏さんだな
0007デフォルトの名無しさん2010/05/07(金) 11:49:39
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0008デフォルトの名無しさん2010/05/07(金) 11:50:05
580* 名前：デフォルトの名無しさん [sage] 投稿日：2010/05/02(日) 00:57:35
ミニマリストにとってはマクロは魅力なのよ。下のほうからシームレスに弄れるし。
低水準言語だとForthなんかがそんな感じだよね。

まあ、マクロ無しでもインライン＆引数評価なし関数で十分代用できるけどね。
これでもまだ落とし穴たくさんあるけど。


816* 名前：デフォルトの名無しさん [sage] 投稿日：2010/05/05(水) 01:52:41
最近じゃめっきりアセンブラを使うことは減ったが
アセンブリでやる必要があるのはOSだけじゃないがね。

ちょいスレチな風味だが
直I/Oとか割り込みハンドラなどの低レベルライブラリが
CPU毎に異なってるのが組み込み屋の悩みだな
メーカ提供のライブラリの出来も千差万別だし
言語の話と離れるが、共通化してくれたらいいのにね
0009デフォルトの名無しさん2010/05/07(金) 11:50:40
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0010デフォルトの名無しさん2010/05/07(金) 12:01:59
新しい言語はGoogle GoやDに勝たないとダメだと思う
0011デフォルトの名無しさん2010/05/07(金) 12:04:59
とりあえず新言語名はＩ言語(アイ言語)にしませう
0012デフォルトの名無しさん2010/05/07(金) 12:10:59
Mona OSとかもあるし、
Mona言語とかしぃ++(thi++)言語でいいんじゃね？
0013デフォルトの名無しさん2010/05/07(金) 12:36:48
Monoでも良いぞ
0014デフォルトの名無しさん2010/05/07(金) 12:38:44
i-Mono
0015デフォルトの名無しさん2010/05/07(金) 12:50:23
Programming Language I に決定。
0016デフォルトの名無しさん2010/05/07(金) 13:07:32
>>1
速度にこだわった低級言語といえばアセンブラ
0017デフォルトの名無しさん2010/05/07(金) 13:08:26
>>5
文法はJavaベースで
0018デフォルトの名無しさん2010/05/07(金) 13:10:38
自分がコンピュータ史上の人物として名を残したいのは分るけど
スレタイの事に労力を費やすなら、Dとか有望株を改良したりドキュメントを翻訳したり
積極的に採用して著名なアプリを作るとかしたほうがいいとおもうんだが。
こんな事は5スレ目だから、何度も言われているかな？
0019デフォルトの名無しさん2010/05/07(金) 13:12:53
>>18
何を言っているんだ。このスレッドは雑談スレッドだぞ。
新しい言語を作るという妄想に浸りながら雑談するのが正しいスタイルだ。
新入り君はそこのところ勘違いしないほうがいい。
0020デフォルトの名無しさん2010/05/07(金) 13:13:16
>>18
その発想は無かった
0021デフォルトの名無しさん2010/05/07(金) 13:13:24
1スレの>>1はもういないだろ。
今は、話題に集まった奴が適当なことを言い合ってるだけ。
0022デフォルトの名無しさん2010/05/07(金) 13:15:56
>>18
そんな色気は仕様が固まってから考えれば良いこと。
Ｄで良いと思う人はＤに行けば良い、
Ｃで良いと思う人はＣを使えば良い、
ＬＷＬが好きな人は好きで居続ければ良い、
ＣＯＢＯＬしか分からない人はそれで良い、
0023デフォルトの名無しさん2010/05/07(金) 13:22:55
私見、
Ｄの問題点、ＣのリプレイスではなくてＣ＋＋の置き換えを目指してる、
曰く、Ｃとして読める構文はＣと同じ動きをする事等など。

Ｃの問題点、既出

ＬＷＬの問題点、論外、
JAVAの問題点、論外、
ＣＯＢＯＬの問題点、論外。
これらはランタイムを必要とする。

関数型言語、論外
Ｃの代替を目指す言語にはならない。
0024デフォルトの名無しさん2010/05/07(金) 13:28:50
>>23
COBOLってランタイムいるの？
0025デフォルトの名無しさん2010/05/07(金) 13:29:26
Cにだってcrtというランタイムがあるんだが
0026デフォルトの名無しさん2010/05/07(金) 13:30:32
>>24
主にＩ－Ｏセクションだけどね。
0027デフォルトの名無しさん2010/05/07(金) 13:31:56
・enumがいいかんじにswitch周りで使えるといいな。
・3項演算子はif式がよいんだか、よくないんだか？
・多値があるとよさそう。
・インクルードは自動生成がいい。

っていうかんじですか？
0028デフォルトの名無しさん2010/05/07(金) 13:33:45
・インクルードは不要。自動生成してもいいが必須ではない。
0029デフォルトの名無しさん2010/05/07(金) 13:34:00
>>27
＞・多値があるとよさそう。
おいらはこれに反対なんだけど、議論にならないので放置してる（ｗ
0030デフォルトの名無しさん2010/05/07(金) 13:35:37
・多値の戻り値は、一つのリスト型で行う。リスト型から要素を取り出す暗黙のキャストがあってもいい。
0031デフォルトの名無しさん2010/05/07(金) 13:40:00
多値はリストじゃなくてタプルだろう。
もっというとstructだろう。って言い出すとまた前スレッドを蒸し返せるよ
0032デフォルトの名無しさん2010/05/07(金) 13:46:20
関数に多値を許すことの最大の欠点は、Ｃ言語とバイナリー互換が
取れないこと。文法がＣ言語と違ってもＣ言語と同じ形式のバイナリー
フォーマットを維持できれば、旧来の資産を継承できるんだけどね。

まぁその辺はトレードオフなので、多値戻しが好きな人はそっちで煮詰めて欲しい
と思う。頑張れって思う。良い仕様が出来たら説得されちゃう用意は何時でもある。
だけど今の議論はちょっと、あり得ない、ＬＷＬ作ってるのか？とか思う。（ｗｗｗｗ
0033デフォルトの名無しさん2010/05/07(金) 13:50:22
C側から新言語によるオブジェクトを呼び出させい場合は、単値のみにするとか、ラッパーを作るとか、何かすればいいんじゃないの。

既存の言語の古い制約に引きづられて、新言語の仕様を妥協はしない方がいい。
0034デフォルトの名無しさん2010/05/07(金) 13:54:31
>>33
きみがそのらっぱーなら、どうぞ、どうぞ。
ちぇけらっちょ♪
0035デフォルトの名無しさん2010/05/07(金) 13:59:34
(ﾟ⊿ﾟ)ﾂﾏﾝﾈ
0036デフォルトの名無しさん2010/05/07(金) 14:02:47
俺も多値は要らんけど、Cとのバイナリー互換とかで妥協する必要はないと思うな。
0037デフォルトの名無しさん2010/05/07(金) 14:06:44
structで返却するってインタフェースにすればいいじゃん。
どうせ多値なんだから返却する型の順序は決まっているわけで。
0038デフォルトの名無しさん2010/05/07(金) 14:07:40
>>36
OSから全部作り直しになるけど、頑張ってください。
確かに意欲的な方向で考えるのは悪くはないと思うんですよ。
そこまで見えてやり遂げるつもりなら誰も止めません。
0039デフォルトの名無しさん2010/05/07(金) 14:10:57
structでもリストでもタプルでも呼び名は何でもいいけど、
順序付きの複数の値をまとめられるデータ構造のリテラルがあればいいね。

C++的には「初期化リスト」と呼ぶけど、「リスト」という呼び名が嫌なら別にポチでもミケでも何でもいい。
とにかく、そういうものが欲しい。
0040デフォルトの名無しさん2010/05/07(金) 14:12:50
>>38
その「作り直さなければいけないOS」とやりとりをしたいときだけ、多値を使わなければいいだけじゃん。
多値があるからOSから全部作り直しになるなんてことはないよ。
0041デフォルトの名無しさん2010/05/07(金) 14:13:03
>>39
提案コードを書いてみては？議論はそこからかな？
0042デフォルトの名無しさん2010/05/07(金) 14:17:00
OSはコーリングコンベンションと関係なかんべ
0043デフォルトの名無しさん2010/05/07(金) 14:18:34
>>41
例えば、C風で申し訳ないが、

{int, int} div(int a, int b)
{
　return {a/b, a%b};
}

{int, int} c = div(5, 3);　　　// c[0]に商（1）、c[1]に剰余（2）
int d = div(10, 6);　　　// dに商（1）、剰余は捨てられる

多値内の要素の指定方法は要検討だが。。
0044デフォルトの名無しさん2010/05/07(金) 14:28:47
>>43
無名構造体って感じなんだけど色々突っ込む前に。
てか突っ込めるほど堅くなさそうな気が。

で、一点、剰余だけ欲しい場合は？

こう言うのを一回でＵＰ出来ると、あぁこの人は考えてるなー
って思う。
0045デフォルトの名無しさん2010/05/07(金) 14:34:14
>>44
だから、名前は何でもいいよ無名構造体でもミケでもタマ。

暗黙のキャストはよく使われる要素が出てくればいいと思うよ。
この場合、商の方がよく使う要素だろうから、商が出てくる。

剰余が欲しい場合は、
int e = div(10,6)[1];
とか
{int, int} f, g = div(10,6);
でfを捨てたりするんじゃないの。

構文についてはもう少し考えないとね。
0046デフォルトの名無しさん2010/05/07(金) 14:37:15
＞構文についてはもう少し考えないとね。

考えてから、多値が欲しいって言うべきかな？
この構文ならすっきり出来るし、とか、そこから
議論始めようよ、突っ込まれて考え中とか無しだよ。

もちろん、その考えが駄目かも知れないんだから、
こうやって議論するんだけど、何も考えずに欲しいとか
まだ考えてないけど欲しいってのは、議論じゃねーですよ？
0047デフォルトの名無しさん2010/05/07(金) 14:39:12
>>46
あなたがそうしたいならあなた自身その方針でどうぞ。

欲しい物を欲しいと表明するのは別に問題ないよ。
0048デフォルトの名無しさん2010/05/07(金) 14:40:27
>>43

関数はdiv_tを返すという宣言のまま、初期値リストの逆みたいな構文を許せばいいんじゃない？

div_t Dとしたら

D = { 3, 4}　と出来るけど、逆に

int deno, rem として

{ deno, rem } = D とするSyntax sugarを加えるだけ．そうすれば

div_t div(int a, int b);の宣言のまま

{ deno, rem } = div(10,6)と出来るのでは。　{}　が無名構造体を作るという
流れに一貫して奇麗だと思うんだけど。
0049デフォルトの名無しさん2010/05/07(金) 14:40:28
考えているからある程度の例が出てくるのであって、
突っ込みどころ見つけてケチつけるのは、議論じゃねーですよ？
0050デフォルトの名無しさん2010/05/07(金) 14:45:33
>>48
構造体（のポインタやリファレンス）を返す事と見比べると、
あやふやな点が増えるだけに感じるのだが？

今までどおり構造体返しより得られるメリットは何？
0051デフォルトの名無しさん2010/05/07(金) 14:45:48
>>48
それだと、div_tを宣言しなければいけないのが、ちょっと美しくない感じが。

無名でできるものは無名にしたいよね。

だから、divの戻り値の方も無名にしたいかな。
0052デフォルトの名無しさん2010/05/07(金) 14:58:00
多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
v,r = a /% b
v = a / b
r = a % b
みないな感じでいんじゃね

Cの延長ならどうせ無名構造体と型推論はありだろうから
{ int a, int } foo () ... と宣言させておいて
{a, b} = foo()とa,b = foo()は構文糖で同じ意味って感じはどう
多値返しは使い方次第とはいえたいして重くはならないと思う

どうせならちょい違うが積和演算も出来たら面白いなｗ
0053デフォルトの名無しさん2010/05/07(金) 15:00:38
>>52
> v,r = a /% b

これいいな。MISD（Multi Instruction Single Data）だな。

調子にのってこんな構文があってもいいかも。

v, r = div,mod(a, b);
0054デフォルトの名無しさん2010/05/07(金) 15:03:06
MISD？
普通に割り算インストラクションは商と剰余を同じ返す奴が多いから
それをイメージしてるだけだけどｗ
0055デフォルトの名無しさん2010/05/07(金) 15:04:53
ていうか通常の割り算のアルゴリズムでは
商と剰余は同じに求まるんだよなｗ
0056デフォルトの名無しさん2010/05/07(金) 15:06:32
>>55
まあ、割り算は分かりやすいから例として使っているだけだろｗ
0057482010/05/07(金) 15:06:56
>>50
>今までどおり構造体返しより得られるメリットは何？
ない。　遊び遊び．

>>51
ああ、そうか。　{int, int} は div_tの無名記法と考えれば{int, int} div(int a, int b)も
納得できるな。

だったら43と48を合わせて

{int, int} div(int a, int b)
{
　return {a/b, a%b};
}

{deno, rem } = div(5,3)
0058デフォルトの名無しさん2010/05/07(金) 15:09:19
>>53
関数を置けるところに関数のリスト置けてもいいな。

v, r = {div,mod}(a, b);

それをパラに処理してくれると嬉しい。
0059デフォルトの名無しさん2010/05/07(金) 15:10:57
>>50
> 今までどおり構造体返しより得られるメリットは何？

オサレでかっこいい。
0060デフォルトの名無しさん2010/05/07(金) 15:12:47
汚いExceptionを少なくしてちゃんとエラー返すのに
多値があったらいいんよね
Cは本来の値以外に特殊な値を定義したり
変なグローバル変数を使ったりするからイマイチ
golangみたいな ret, ok = foo()記法は慣れると結構わかりよい
0061デフォルトの名無しさん2010/05/07(金) 15:17:59
>>60
それいいな(ﾟＡﾟ;)ｺﾞｸﾘ
0062デフォルトの名無しさん2010/05/07(金) 15:23:04
>>60
例外処理の使い勝手の悪さ問題だよね。
例外処理が使えればエラー値戻しは
必要ないと思うんだが。

多値戻しは鬼門になりそうな気がするんだけどなぁ。
0063デフォルトの名無しさん2010/05/07(金) 15:29:08
そうかな？多値の有り無しは別として
例外処理って本来は大域脱出の延長だから多用すべきではないんだよ
正常な処理としてのエラー処理と例外処理を同列に考えて
構文に入れちまったのが問題だと思うんだよな
無用なオーバーヘッドだってあるしね
0064デフォルトの名無しさん2010/05/07(金) 15:31:15
> 多値戻しは鬼門になりそう

しかし、Python, Ruby, Goとすでに使われてるよね。　他にもあったっけ？
0065デフォルトの名無しさん2010/05/07(金) 15:36:49
Lisp
0066デフォルトの名無しさん2010/05/07(金) 15:39:23
Lispと言ってもいろいろだろｗ

S5R5は多値に対応してるな。
0067デフォルトの名無しさん2010/05/07(金) 15:40:34
Common Lispも多値に対応してるよ。
0068デフォルトの名無しさん2010/05/07(金) 15:42:10
PythonやRubyはタプルみたいな奴で単値返しじゃないか？
構文的には多値風だけど。
0069デフォルトの名無しさん2010/05/07(金) 15:43:07
なんでもいいよ。構文的に多値に見えれば。
0070デフォルトの名無しさん2010/05/07(金) 16:19:54
>>68
こんな感じですね：
def mul():
　　return 5,6

>>> a,b = mul()
>>> a,b
(5, 6)
>>> a = mul()
>>> a
(5, 6)
>>>b,c = a
>>> b,c
(5, 6)


つまり、タプルを複数の変数に代入出来るという機構があるだけという感じですね。
0071デフォルトの名無しさん2010/05/07(金) 16:49:00
>>70
他意のない単なる質問だけど、その「タプル」とLispのリストって機能的な違いってあるの？同じもの？
0072デフォルトの名無しさん2010/05/07(金) 17:18:31
Pythonについていうと似たようなもんだが
タプルは変更付加
ちょい汚いけどC++0xにも導入されてるね
0073デフォルトの名無しさん2010/05/07(金) 17:21:17
ごめｗ不可ねｗ
0074デフォルトの名無しさん2010/05/07(金) 17:23:59
>>72
なるほど。ありがとう。

それなら、今はまだいいけど、
用語をタプル／可変タプルとか、リスト／定数リストのような感じで機能を表すようにして欲しいな。

慣れなのかもしれないけどね。
0075デフォルトの名無しさん2010/05/07(金) 17:30:03
リストがlisp的なリストのことなら通常リスト自体は変更可能なデータ型でしょ
タプルは作ったら変更不可で自身も無名、メンバーも無名なstructって感じと思えばいい
0076デフォルトの名無しさん2010/05/07(金) 17:31:33
>>72
ビックリしたぁ、標準ライブラリじゃん。
0077デフォルトの名無しさん2010/05/07(金) 17:38:12
そそ。C++らしく汚物的に汚いけどねｗ
0078デフォルトの名無しさん2010/05/07(金) 17:43:32
タプルをリストに代入できるが、リストをタプルに代入できるとは限らないってことでおｋ？
0079デフォルトの名無しさん2010/05/07(金) 18:04:43
>>77
言語の話してるときに標準ライブラリの話持ち出さない
程度の、なんかは無いのか？
0080デフォルトの名無しさん2010/05/07(金) 18:05:46
>>18
名を残すなんて用意ではないぞ。
まつもとゆきひろのようになるのも大変かと。
ましてやオブジェクト指向言語を作るとなると
コンパイラコンパイラで作るのもものすごい苦労するのではないかと。
Java言語を作った集団は10年以上もかけて研究してきた研究者だからな。
Javaを超える言語を作るのも至難の業。
0081デフォルトの名無しさん2010/05/07(金) 18:06:51
>>23
C++がOKでJavaが論外というのが矛盾だらけだ。
JavaはJVMなしでネイティブで動かすこともできるのだが。
0082デフォルトの名無しさん2010/05/07(金) 18:09:26
>>27
どうせならJavaのenum以上に高機能であることが望ましいな。
interfaceを実装できてクラスのように扱うことができジェネリックス(テンプレート)も使える。
そして列挙変数にメソッドを持たせることもできる。
JavaのenumはC++やC#のenumとも異なる超高機能列挙型だから
それを超えるenumが欲しい。
includeよりimportとpackage(namespace)のほうがいい。
ディレクトリやファイルパスという方式はヘッダファイル地獄に陥る。
0083デフォルトの名無しさん2010/05/07(金) 18:11:07
>>30-31
リスト型、structというかオブジェクト(class)で返すべき。
C++STLのvector型、JavaのListオブジェクト(型)のように。
そして当然ながらGenerics(template)と併用できる。
0084デフォルトの名無しさん2010/05/07(金) 18:11:21
何回自慢げに同じ話ばかりすれば気がすむんですか？
0085デフォルトの名無しさん2010/05/07(金) 18:12:27
低水準ってキーワードを無視しまくったレスを付けてる奴は頭悪い。
0086デフォルトの名無しさん2010/05/07(金) 18:12:50
>>39
C++STLのvectorやJavaのjava.util.Listオブジェクトの真似をすることの何が不満なんだ
配列で返してもいいし、オブジェクトで返してもいい。
0087デフォルトの名無しさん2010/05/07(金) 18:20:22
>>43
> {int, int} div(int a, int b)
> {
> 　return {a/b, a%b};
> }

なんかMATLABっぽい文法だな。MATLABだとこう書く。
[x, y] = function(a, b);
x = a / b;
y = a % b;
そしてファイル名をdiv.mとして保存してパスを通して
A = div(1,1)
とやると配列になって

A = [1, 0]
と出力される。


そしてJavaやC++だとこうなる。
<T extends Number> List<T> div(T a, T b){
　List<T> result = new ArrayList<T>();
　result.add(a / b);
　result.add(a % b);
　return result;
}

int[] div(int a, int b){
　int[] result = new int[2];
　result[0] = a / b;
　result[1] = a % b;
　return result;
}
0088デフォルトの名無しさん2010/05/07(金) 18:23:02
>>52
> 多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
> v,r = a /% b
それを許すと
v= 1, r = a / b;
という記述(C言語のv = 1; r = a / b;と同じ)がかわってしまうが、その点はどう対応する？
途中改行を許さないという文法にでもする？
0089デフォルトの名無しさん2010/05/07(金) 18:24:29
>>60
例外処理に不満があるならC#の真似をしてみては。
あれはあれで問題を起こし、Java方式とC#方式で賛否両論があるが
0090デフォルトの名無しさん2010/05/07(金) 18:25:51
>>85
低水準といっておきながらC++に変わる言語を作れっていう時点で
無理がある

あるていど高級言語にせざるをえないんでは。
しかも例外処理の話までしてる。
0091デフォルトの名無しさん2010/05/07(金) 18:29:29
>>88
, で式をつなげるのは無しにすればいいかな。
0092デフォルトの名無しさん2010/05/07(金) 18:30:58
>>90
低水準に”も”使えればいいんだよ。無理はないよ。
0093デフォルトの名無しさん2010/05/07(金) 18:31:57
スレタイに、C++が入っているのがそもそもの間違い。C++にかわる言語はいくらでもある。
次のスレは、C++をはずそう。
0094デフォルトの名無しさん2010/05/07(金) 18:35:37
>>86
返り値を多値型にキャスト出来れば、別に何を返してもいいよ。

a, b, c, d = func();

で、func()の戻り値の配列なりオブジェクトなりの要素を何らかの法則に従って順序付けて並べたときの1,2,3,4番目の要素を、a,b,c,dに代入できればいい。
0095デフォルトの名無しさん2010/05/07(金) 18:37:58
>>88
ちょっとウザイけど
c = 1, [v,r] = a/b;
とかでもいいかな。
0096デフォルトの名無しさん2010/05/07(金) 19:17:43
>>88
Cのカンマ演算子は中途半端だから廃止でいいんじゃない
複数の式を1つにまとめるのといろんなもんの区切りが同じ,ってのは
いまいちな感じしないかな
forとか考えるといい構文も思いつかないんだけどｗ
0097デフォルトの名無しさん2010/05/07(金) 19:19:25
(v = 1; b = 2)なんて言うのが式として有効ならいいかも
0098デフォルトの名無しさん2010/05/07(金) 19:23:19
>>79
ああ。確かにライブラリだな
でもC++0xそのままは汚いっていうのはそういうのも込みの印象ね
無名、メンバー無名のstruct的なデータ型はFirst Classとして
アリなんじゃないかと思ったからさ
0099デフォルトの名無しさん2010/05/07(金) 19:26:58
前スレ埋めろよ
0100デフォルトの名無しさん2010/05/07(金) 19:27:08
>>98
C++は過去を引きずり過ぎてあんな感じにならざるをえないんだろうね。
そういう意味で、新言語は過去に引きずられて妥協することのないようにしたい。
0101デフォルトの名無しさん2010/05/07(金) 19:28:45
>>100
ぶっちゃけいうと俺はCとgolangでいいとおもってるけど
C++とかいらねｗ
でもスレはネタとして楽しんでるよ
0102デフォルトの名無しさん2010/05/07(金) 19:43:26
CとC++を比較すると
両者とも過去を引きずっているが、C++だけが未来に拘わりすぎてあんな感じ
というのが正しい
0103デフォルトの名無しさん2010/05/07(金) 19:44:42
純粋に未来だけにこだわったC++も見てみたいな。
ある意味、この新言語なんだけど。
0104デフォルトの名無しさん2010/05/07(金) 19:57:08
「便利」でかつ「低水準」を同時に満たす言語を目指すこと自体が
かなり至難の業だと思うんだが
「便利」と「低水準」はほとんどトレードオフで反比例の関係に位置するといってもいい
よほど意表をつくほどの斬新な発想でもしない限り厳しいのではないだろうか


>>95
[v,r]に[]を使うということは、[]は配列には使わないということかな。
他でもいってるようにカンマの代わりにセミコロンで対応できそうだ。
そのかわりやはりfor文が厄介なことになる。

>>100
しかし過去を切り捨てると低水準言語の仕様を廃したJavaのような高級言語になってしまう。
過去を残したからこそC++も低水準言語として扱うことができる。
このトレードオフな関係をどうにか解決しないことには「低水準言語」の過去を廃してオブジェクト指向言語のような
便利な言語でかつ低水準言語を作るのは難しいのでは。
0105デフォルトの名無しさん2010/05/07(金) 19:57:48
>>103
未来にこだわっただけのC++＝Java、C#、D言語
ではないのか。
0106デフォルトの名無しさん2010/05/07(金) 20:02:03
>>105
それは違うかな。右辺の言語はCの置き換えにならない。
0107デフォルトの名無しさん2010/05/07(金) 20:12:27
Cでできることすべてできないと気が済まないのか
0108デフォルトの名無しさん2010/05/07(金) 21:10:41
Cに代えたいのかCと互換性を持たせたいのか不明
0109デフォルトの名無しさん2010/05/07(金) 21:59:03
新言語ではCでできることは全てカバーしたいね。
0110デフォルトの名無しさん2010/05/07(金) 23:10:25
>>109
それはかなり無謀かと
C++の二の舞だ
0111デフォルトの名無しさん2010/05/07(金) 23:11:11
C99でできることぐらいはカバーしておきたい
0112デフォルトの名無しさん2010/05/07(金) 23:24:56
>>110
C++と違って、新言語にはCとの互換性はいらないよ。
「Cでできること」というのは「Cでの開発対象となっている分野」のこと。
だから何も無謀じゃない。
0113デフォルトの名無しさん2010/05/07(金) 23:27:19
Cを使うよ
0114デフォルトの名無しさん2010/05/07(金) 23:29:47
マシンコードに対してCが写像であるということに、うんたらかんたら
0115デフォルトの名無しさん2010/05/07(金) 23:36:05
だからクロージャはサポートされないわけだ。
0116デフォルトの名無しさん2010/05/07(金) 23:38:15
クロージャーはサポートしてもいいんじゃないの。流行りだし。
0117デフォルトの名無しさん2010/05/07(金) 23:38:33
>>112
> 「Cでできること」というのは「Cでの開発対象となっている分野」のこと。

組み込み系、OS開発、デバイスドライバ開発

今となってはCの出番は
ほとんどそういう分野に限られてないか？
0118デフォルトの名無しさん2010/05/07(金) 23:39:53
>>117
そういう分野を、最近のオサレ機能を交えつつ開発できたら、気分いいよね。
0119デフォルトの名無しさん2010/05/07(金) 23:43:43
>>117
その分野の開発を行えることが絶対条件で、さらに上位の開発にも使えたらなお良い。
0120デフォルトの名無しさん2010/05/07(金) 23:47:17
二兎追う者はなんたらかんたら
0121デフォルトの名無しさん2010/05/07(金) 23:50:47
優先順位が付いているからその指摘には当たらないのでは。
0122デフォルトの名無しさん2010/05/07(金) 23:52:52
クロージャの考え方を考えようぜ。

実際にはcはフラットな構造をしているから、手続き+環境というのはあんまりメリットないんだよね。
もしクロージャを取り込むんだったら、環境と手続きのセットを一級市民化する意味を考えないとムダだよ。
0123デフォルトの名無しさん2010/05/07(金) 23:53:05
C++が糞と言われながら普及したのは結局Cとの互換性があったからだ
0124デフォルトの名無しさん2010/05/07(金) 23:55:01
普通のクロージャと同等に使い勝手が良いものが欲しければGC必須でしょ
GCで管理されてるからこそ、環境（自由変数）が暗黙にクロージャに
キャプチャされても、ユーザは寿命の問題をいっさい気にしないで済む

GC無しではそういう訳にはいかんよ
少なくともupward funarg problemを解決できない
自由変数をフィールドに保持する構造体を暗黙に生成させるとしても、
例えば自由変数がポインタだったとして、その寿命はどうすんのさ、という話になる

クロージャでなくて単なる関数リテラルなら、ありだと思うよ
0125デフォルトの名無しさん2010/05/07(金) 23:55:02
>>122
「フラットな構造」ってどいうこと？
0126デフォルトの名無しさん2010/05/08(土) 00:05:28
写像
0127デフォルトの名無しさん2010/05/08(土) 00:10:02
結局の所今あるもので十分なんだろう

ネタに走った方が精神的に充実すると思うんだが
0128デフォルトの名無しさん2010/05/08(土) 00:15:15
それは、オナニーだよ。
0129デフォルトの名無しさん2010/05/08(土) 00:35:13
>>124
そうそう。まずCで一番じゃまっけなのがオブジェクトの寿命だ。

いろいろ考えると
現代のVM上での開発はかなり合理的だといえるね。
0130デフォルトの名無しさん2010/05/08(土) 00:49:56
>124
いや、それ以前の話。
cの場合は自由変数が束縛されるのはグローバルスコープと関数スコープしかないよね。
関数から別の関数を呼び出す場合も引数でしか渡せないから、結局クロージャみたいな
大袈裟な仕組みは要らないよね、ということ。
それよりも真っ当なマクロがほしい。

>125
cには(基本的には)グローバルスコープと関数スコープの2つのスコープしか無いということ。

>129
それだとVMに制限されるだろ。VM自体が軽量でポータブルならともかく。
Forthみたいに全部スタックに積むという手もあるよ。
0131デフォルトの名無しさん2010/05/08(土) 00:55:22
GC入れるのはいいけど、従来のC言語と同様に手動管理も
出来る自由度は欲しい

言語仕様には両方実装しておいて、必要に応じて切り替えられる、
という感じでいいかと
0132デフォルトの名無しさん2010/05/08(土) 00:58:43
参照カウンタじゃダメで、GCが必要なのって、循環参照がある場合だけかな？
他にもあるの？
0133デフォルトの名無しさん2010/05/08(土) 00:58:58
とりあえずころころソート基準が変わる
ソート関数ポインタを作りたいんだが、どうすればいい？
0134デフォルトの名無しさん2010/05/08(土) 01:00:29
まだGCとか言ってるバカがいるのか…
高級言語からのトップダウンじゃなくて、機械語やアセンブリからのボトムアップで考えろよ
じゃなきゃCの代替になんてなれるわけがない
0135デフォルトの名無しさん2010/05/08(土) 01:01:26
>>130
真っ当マクロ路線なら前スレで
出てたCをLispにした奴だね。あれがいい。
0136デフォルトの名無しさん2010/05/08(土) 01:02:43
>>134
良いこと言うね
0137デフォルトの名無しさん2010/05/08(土) 01:04:16
>>132
参照カウンタはスレッドセーフにしずらい
0138デフォルトの名無しさん2010/05/08(土) 01:05:03
>>137
なるほど。たしかに。
0139デフォルトの名無しさん2010/05/08(土) 01:06:56
多値なんて無ければ無いでいいし
クロージャ、GC、VMは論外だろう
結局このスレ、俺構文オナニーショーなんだな
0140デフォルトの名無しさん2010/05/08(土) 01:08:38
ぶっちゃけ、最終的にはgo言語になる気がする

あるいはgo言語のマイナーチェンジ版に
0141デフォルトの名無しさん2010/05/08(土) 01:09:26
言語自体はGCサポートして、GCを使いたくないときには、-WGC オプションをつけてコンパイルすると、どうしてもGCが必要なところで、GC使いますよってワーニングを出すような感じにできないかな。
0142デフォルトの名無しさん2010/05/08(土) 01:11:40
「言語自体はGCサポートして」というのは語弊があった。

「言語自体はオブジェクトの寿命管理を処理系にお任せできるようになっていて」…って方がいいね。
0143デフォルトの名無しさん2010/05/08(土) 01:13:01
GCの根本的な問題は「誰がリソースを管理するか」ということだよ。
GCをサポートするのならばリソース管理はGCにまかせるべきで、GCを使わないならばプログラマがちゃんと管理すべき。
オプションで切り替えるようなものじゃ無いよ。
0144デフォルトの名無しさん2010/05/08(土) 01:15:00
>>143
限界ギリギリまでGCを使わないで、処理系にオブジェクトの管理をお任せすることって出来ない？

どうしてもダメなときは、コンパイラが「ごめんなさいGC使わせてください」って言うの。
0145デフォルトの名無しさん2010/05/08(土) 01:15:04
>>141
CにGCライブラリをリンクするのとどう違うのかね？
それにGCが必要かどうかの自動判断は無理
0146デフォルトの名無しさん2010/05/08(土) 01:17:33
>>145
まさに処理系に「GCが必要かどうかの自動判断」をさせたいんだけど、無理なの？何ゆえ？
0147デフォルトの名無しさん2010/05/08(土) 01:18:33
そんな切り替えができたら他の言語でとっくにやってるでしょ
ちなみにGCを起動させないことはできるよ
0148デフォルトの名無しさん2010/05/08(土) 01:21:06
>>147
確かに。
他でやっていないから、出来ないってのは確かに消極的な証明にはなるね。

次なる目標は、なるべく同じ構文のまま、GCをON/OFFできるようにする。
ってとこかな。
0149デフォルトの名無しさん2010/05/08(土) 01:23:20
つーか何でそんなにGCを欲する？
10年以上CプログラマやってるがGC欲しいと思ったことなんて1度も無かったが
0150デフォルトの名無しさん2010/05/08(土) 01:24:25
>>149
Cが何かとめんどくさくてインポテンツだから
0151デフォルトの名無しさん2010/05/08(土) 01:25:44
>>149
ライブラリ作ってて、毎度毎度create-deleteペアを作ってやらなきゃいけないのに辟易したりしなかった？
0152デフォルトの名無しさん2010/05/08(土) 01:33:37
>>151
それぞれのcreateとdeleteで違う処理をしなきゃいけないのに辟易も何もないわ
ただ解放すりゃいいなんて単純なライブラリは作らなかったし
0153デフォルトの名無しさん2010/05/08(土) 01:33:50
>>148
停止性問題と同じくGCが必要か否かを証明する方法はない
単に不要と判断するならGCを殺せばいい
0154デフォルトの名無しさん2010/05/08(土) 01:35:58
>144
>「GCが必要かどうかの自動判断」

自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。
コンパイル時に全部スタックに乗っているかどうかをチェックさせるという手もあるとは思うけど、
それならGC自体が不要だわな。
0155デフォルトの名無しさん2010/05/08(土) 01:36:16
そして再開する俺構文オナニーショー！！！！

↓最初の方、どぞ
0156デフォルトの名無しさん2010/05/08(土) 01:36:36
>>153
停止性問題と同じではないでしょ。
GCよりもコンパイラーの方がメタなわけだし。

GCにGCの必要性は証明できないかもしれないけど、コンパイラーがGCの必要性を証明できないって事にはならないのでは。
0157デフォルトの名無しさん2010/05/08(土) 01:44:16
>>154
> 自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。

いや、「GCが必要かどうかの自動判断」というのは、リソースの生死の確認ではなく、リソースの生死の確認が必要かどうかの確認だよ。
後者にはGCは必要ないよね？
0158デフォルトの名無しさん2010/05/08(土) 01:46:12
GC回収対象のオブジェクトを作らなければ不要でしょ
malloc使わなければfreeいらないのと同じ
0159デフォルトの名無しさん2010/05/08(土) 01:57:33
>157
>リソースの生死の確認が必要かどうかの確認

所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。
結局プログラム自体を実行させる必要が出てきて、やっぱりGC回さなきゃ判らんよね、ということになるよ。
0160デフォルトの名無しさん2010/05/08(土) 01:59:34
>>159
> 所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。

このあたりがもう少し具体的になると議論が深まるかも。
0161デフォルトの名無しさん2010/05/08(土) 01:59:56
GCがあると便利な場合は当然あって、それはそれでいいと思う。
ただ、一部のCユーザにはGC無しで自分でメモリ管理をする方が望ましいわけでしょ？
だったら両方できればいい
0162デフォルトの名無しさん2010/05/08(土) 02:06:45
Garbage Collection (GC)について語るスレ
http://pc12.2ch.net/test/read.cgi/tech/1141646850/
0163デフォルトの名無しさん2010/05/08(土) 02:08:16
>>159
GCを回しても、所有者のハッキリしないリソースがあるかどうかというのはわからないのでは。
GCで知れるのは、リソースの所有の有無と、所有者だよね？
所有者がハッキリするかどうかは別の問題ではないかと。
0164デフォルトの名無しさん2010/05/08(土) 03:01:11
>160
リソースの管理に関しては主に確保->(保持<->譲渡)->放棄という局面があるわけなんだけど、それらを紐付けて
関連付けるのはなかなか難しいことで。
あるオブジェクトが確保したリソースを複数のオブジェクトで盥回しにして解放するというのは良くある状況だけど、
普通のc++なんかのソースコードだとそれぞれモジュール化されて切り離されているから、それをコンパイル時に統合して
トレースするのはかなり大変なんじゃない？
ということ。

>159
コンパイラが所有者のハッキリしないリソースを見つける≒コンパイル時にGCが必要な状況を見分ける
ぐらいの意味ですな。


0165デフォルトの名無しさん2010/05/08(土) 03:10:45
Objective-C
0166デフォルトの名無しさん2010/05/08(土) 03:25:17
GC/nonGCについてですが、自分が今考えているのは、
通常のオブジェクトはCと同じように関数(グローバル)スコープでのみ生存し、
それとは別にDynamicObjectみたいな組み込みクラスを用意して、それを
継承したオブジェクトはGC対象にしようと思っています。
で、コンパイルオプションでDynamicObject自体を抑制できる、みたいな。

てのはどうでしょうかね？
0167デフォルトの名無しさん2010/05/08(土) 03:41:41
ね？ではなく、試せ
0168デフォルトの名無しさん2010/05/08(土) 05:55:57
>>104
だれも便利は求めてないぞ（ｗ

安全性が高い＝便利だけどね。

>>107
代替そちが有れば良いけどまるで出来ないのは辛い。

>>108
>>１を嫁よ、Ｃ言語と文法上の互換性は必要ない。
ただしオブジェクトリンケージとか、Ｃ、Ｃ＋＋、ＪＡＶＡ
Ｄ，Ｇｏ，Ｃ＃で色々見知った事を生かしたい。
0169デフォルトの名無しさん2010/05/08(土) 05:58:42
>>120
二兎を追うんじゃなくて、美味なる一匹
0170デフォルトの名無しさん2010/05/08(土) 06:01:42
>>160　例えば多値戻しのちょっと変な人が書いたコードなんだけどint[] div(int a, int b){
＞int[] div(int a, int b){
＞　int[] result = new int[2];
＞　result[0] = a / b;
＞　result[1] = a % b;
＞　return result;
＞}

これ良い例だと思うんだけど、呼び出し元では
void foo(){
　　int[] ret;

　　ret = div(13, 5);
　　return;
}
てな事になってヤバイよね
0171デフォルトの名無しさん2010/05/08(土) 07:44:37
> プログラマの意図どおりにバイナリを生成する保障はどこにもない。
> マクロはプリプロセスなので必ずインライン展開される。その違いを認識せよ。

どっちにしろ「意図通り」のコードを吐いてくれるかどうかなんてわからない。
50歩100歩。すっぽすっぽたんの言う通り、字面で書き換えを行うことによる
言語上の弊害のほうがきわめて大きい。
0172デフォルトの名無しさん2010/05/08(土) 08:01:39
誤爆かと思ったら前スレかｗ
定数に限っては意図どおりに展開されるよ
0173デフォルトの名無しさん2010/05/08(土) 08:13:49
>>170 続き

なので前スレか、前々すれで提案した。

戻り値タイプ　関数名
　　　　　　　Source(),　　　←値渡しがデフォルト
　　　　　　　Parameter(),　←const リファレンスがデフォルト。
　　　　　　　Result(),　　　←リファレンス
　　　　　　　Exception(); try文の糖衣構文でcatchするオブジェクトを指定できる


まだ考え中なんだけどさ、こういう関数定義にしておいて。

void foo(){
　　int[2] ret;//retはスコープ内の寿命
　　mathEx mEx;

　　div.Source(13, 5);
　　div.Result(ret);
　　div.Exception(mEx);

　　div.call(){
　　　　catch(mEx == overfllow){
　　　　}
　　　　catch(mEx == divbyzero){
　　　　}
　　}
　　return;
}
0174デフォルトの名無しさん2010/05/08(土) 08:15:10
>>173　続き

なんて風に行けると、コンパイラも最適化しやすいだろうし、
プログラミングもやりやすくなると思うんだよね。
構文については酷いし、例外はもっと考えないと不味いだろうけども。
例外についても2種類有るってのをどうやっていくか、とか、本当に2種類なのか
とか。
0175デフォルトの名無しさん2010/05/08(土) 08:23:05
それはきめえわ
0176デフォルトの名無しさん2010/05/08(土) 08:26:36
CPU固有言語たんハァハァですな。
0177デフォルトの名無しさん2010/05/08(土) 08:45:34
マクロが必要か不要かの割合は１：９くらいでしょう。
不要だという人が多い。
ジェネリックスや多態性等で解決できるという主張だ。
でもジェネリックスを使いやすく発展させることを考えると
マクロに近づいていくというのがD言語のジェネリックスを見れば分かるかと。

C言語がプリプロセッサと言語は分かれているようにマクロ部分と言語本体は分ければいい。
HaskellとかOcamlはそうなっている。

ジェネリックスというかC++のテンプレートはオブジェクト指向とは直接関係しない、
コンパイルタイムにプログラムを作成する関数指向なプログラムだから。
0178デフォルトの名無しさん2010/05/08(土) 08:53:05
>>174　続き。ところで例外なんだけども、180度考え方を変えて、
bool div
　　Source(int a, int b),
　　Result(int[] result);
　　Exception(mathEx mEx);
{
　mathEx& localmEx;　　　　　　　　//これを呼び元関数がException
　if(mEx == NULL){　　　　　　　　//を設定してるかどうかによって
　　localmEx = new mathEx(); 　　　//コンパイラが自動設定。
　　localmEx.setlocal();　　　　　　　　//スコープの問題や
　}else{　　　　　　　　　　　　　//変数寿命の問題が残るので、熟慮が必要。
　　localmEx = mEx;　　　　　　　　//
　}　　　　　　　　　　　　　　　　//

　if(0 == b){
　　localmEx.setdivbyzero;
　　throw localmEx;
　}
　result[0] = a / b;
　result[1] = a % b;
　return result;

　catch(localmEx){
　　if(local.divbyzero() && localmEx.islocal()){
　　　printf("divbyzero\n");　　　　　　//呼び出し元が例外を受け取らないのなら
　　　abort();　　　　　　　　　　　　　//例外を投げる側がシステム設定を定義。
　　}else{
　　　throw localmEx;　　　　　　　　　//呼び出し元が例外を受け取るならそちら任せる。
　　}
　}
}
0179デフォルトの名無しさん2010/05/08(土) 08:55:41
>>178　続き
こうすればスタックの巻き戻しという大がかりな機構が必要なくなるし、
記述の一貫性が保てて良いと思うんだけど、例外の利点を何か失いそうな
感じがしてる。でもそれが何かまだ分からない。
0180デフォルトの名無しさん2010/05/08(土) 09:32:56
>>179 続き。
>>178のコンパイラ自動設定の部分は、>>173で示したように、
Exceptionを関数定義で定義するかどうかによって、判断したら、
つまり、Exception引数を定義しなければ、旧来のＣ言語関数と
同じイメージになる。としてしまえば、総ての関数に、例外処理
というコードが組み込まれるのも避けられると思うんだ。

後、Source,Parameter,Resultに関しても関数定義するときに名前が
付くだけで、実際はＣ言語の引数リストと同様なので、旧来のシステム
と混在が可能だと思うんですよ。

提案の狙いはこの部分なので、お前の稚拙考えだとそれは実現できないとか
こんな場合はどうするとか、言ってくれると嬉しいんだけど、ここは２ｃｈ
なので>>175なのかもしれない。
0181デフォルトの名無しさん2010/05/08(土) 09:42:11
このスレは馬鹿しかいないな
0182デフォルトの名無しさん2010/05/08(土) 09:49:16
>>181
無意味なこと書き込むお前ほどではない。
0183デフォルトの名無しさん2010/05/08(土) 09:59:19
お前らの書き込んでいることは無意味ではないとw
0184デフォルトの名無しさん2010/05/08(土) 10:08:37
>>183
人を馬鹿にするときには馬鹿にする前に馬鹿にする相手を論破しておかないと馬鹿にしているやつが馬鹿に見える。
お前のように実社会で馬鹿にされているからここにきて馬鹿にしに来ているやつにありがち。
0185デフォルトの名無しさん2010/05/08(土) 10:16:22
書き込んでいる人間のプロファイリングとか
馬鹿しかしないわなw
0186デフォルトの名無しさん2010/05/08(土) 12:33:10
>>178
必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
記述量が多い割に、値か関数かの判定は先読みしなければならないのも嬉しくない。
強力なマクロも実現できそうにない。

例外を関数読んだあとに直ぐにキャッチしなきゃいけないなら、
返り値でいいでしょう。
返り値らしいboolはどこで返してるのか、使っているのか分からない。

0187デフォルトの名無しさん2010/05/08(土) 12:40:44
もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
話したいなら、そこだけ話せばいいのでは？

例外処理を入れるとなるとC++の例外処理では機能不足で関数毎に
例外処理のためのコードを入れる必要があると考えていて、

例外をjavaの検査例外にしておけば、例外投げないソースだけなら、
例外の処理を関数ごとに入れる必要がなくなってよいと思ってると
いうことですか？

0188デフォルトの名無しさん2010/05/08(土) 13:12:35
>>186
>必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
その辺は後から有る程度はどうにでもなるから気にしてない。
P_,S_,R_,E_とかでも良いわけだしね。
それに大規模（ソース行数がミリオン超えっていみな）開発していくと、
結構みんな、逆にフルスペリングの方が間違いが無くて良いって事になる。
例えて言うと、GUI系のライブラリなんかそうだよね。

>>187
いや、JAVAもC++も同じなんだけど、スタックの巻き戻しやって、
最後にシステム基底のデフォルト例外処理にぶち当たるんだけど、
システム基底の例外処理にぶち当てるか、自分で例外キャッチするのかを
一番よく知ってるのは、呼び元の関数だろ、なに世界一周旅行に出かけなきゃ
ならないんだ？って部分への疑問を解決するためのコードというか例外処理。
0189デフォルトの名無しさん2010/05/08(土) 13:15:47
>>186　続き
>>187
>もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
>話したいなら、そこだけ話せばいいのでは？
関数定義も変更したいのとセットで語りたい部分だから。

>>178の下の部分は
catch(localmEx){
　　if(local.divbyzero() && localmEx.islocal()){
　　　system_default("divbyzero");　　　//こんな感じにシステムデフォルトにする事もできるしさ
　　　abort();　　　　　　　　　　　　　
　　}else{
　　　throw localmEx;　　　　　　　　　//呼び出し元が例外を受け取るならそちら任せる。
　　}
0190デフォルトの名無しさん2010/05/08(土) 13:17:08
>>189は>>188の続きの間違い。
0191デフォルトの名無しさん2010/05/08(土) 13:17:15
>>188
いや、単語の長さとか、そういうレベルじゃない。
個人的には、お前は根本的にセンスがないと思う。
0192デフォルトの名無しさん2010/05/08(土) 13:19:23
>>191
気分の議論は無意味だよ。とか書いても理解力は無いか。
まぁニギヤカシがいてるのが2chなのでしょうがない。
0193デフォルトの名無しさん2010/05/08(土) 13:28:27
>>192
いや、気分の話じゃない。
言語を作るときに必要なのものとして、機能と文法があるとして、
文法の部分はかなりセンスを必要とする。

お前の主張の例外の扱いの「機能」については、受け手が受け取られるか
どうかを判別できるようにする、というだけで、まったく魅力的な機能ではない。

そして、文法的にも全然すっきりしていない。

機能としても新しくなく、文法としても魅力がないものを訴えても、そりゃ
誰も理解を示さない。
0194デフォルトの名無しさん2010/05/08(土) 13:36:19
気分的には、再利用とカスタマイズへの拘りが感じられるスレだな
低級言語を低級ではない分野にも再利用したいとか
一からBNFを書き直すのではなくパーサーをカスタマイズしたいとか
そういう話題が多い
0195デフォルトの名無しさん2010/05/08(土) 13:36:23
>188
直上の呼び出し元しか例外処理できないなんて無茶だわ。
そもそも「何の関数が呼び出したの？」という問題もあるし、結局まともに例外を実装しようとしたら
全部の関数にcatchを付けなきゃいけなくなって、オーバーヘッドが酷いことになるわな。
あとマクロとの相性が最悪なことになりそう。

例外は「異常事態用の専用フローを用意する」ということが重要なのであって、例外発生時の効率を
考えるのは筋が悪いですな。
そんなことをするんだったら、forthみたいにスタックを直接操作できるようにした方が100倍マシ。
0196デフォルトの名無しさん2010/05/08(土) 13:42:04
>>195
＞直上の呼び出し元しか例外処理できないなんて無茶だわ。

なんで？　これがよく分からない。

＞そもそも「何の関数が呼び出したの？」という問題もあるし、
ねーよ馬鹿。
0197デフォルトの名無しさん2010/05/08(土) 13:43:04
>>193
だから、気分を語られても困るって（ｗｗｗ
0198デフォルトの名無しさん2010/05/08(土) 14:04:09
>196
お前……例外使ったことないだろ。
細かい関数(thunkとか)実装した時に、それぞれの関数にcatchを用意しなきゃいけなくなるんだぜ？
オーバーヘッドで死んでしまうわ。どこの高水準言語だ

>何の関数が呼び出したの？
サブルーチンだけに閉じてればOKだけど、もうサブルーチン決め打ちに決定したのか？
またマクロの実装をどうするか、遅延評価をどうするかとか色々な要因があるんだけど。
まあ、例外を効率化しようなんて馬鹿考えるやつなら想像力もこんなもんか。
0199デフォルトの名無しさん2010/05/08(土) 14:12:10
ここまで有用な話題なしと
0200デフォルトの名無しさん2010/05/08(土) 14:21:47
>>124
GC必須にしたら結局低級言語にならないという
結論に到達するなw
0201デフォルトの名無しさん2010/05/08(土) 14:23:37
>>152
お前デザインパターンを駆使するとdeleteするタイミング考えるの大変だぞ
0202デフォルトの名無しさん2010/05/08(土) 14:34:18
デザインパターンは古い
クラウドを駆使するとソケットを閉じるだけだぞ
0203デフォルトの名無しさん2010/05/08(土) 15:05:58
v = a / b
v,ok = a / b
v,r = a /% b
v,r,ok = a /% b

ま、そもそも0かどうか検査しなさいってこった。またはエラーを返して処理しなさいってこった。

例外はCPUの例外の様に異常度が高いものに限るべきで、その際は大域脱出した方がいい

例は割り算だが大規模でも小規模でもおなじ。例外は起こさない様にするのが原則。

CPU固有君は最初から話がズレてる。
バラメータとソースとかも全く意味不明で戻り値の宣言も。f(g())出来ないとか、C++的オブジェクトありきとか。
0204デフォルトの名無しさん2010/05/08(土) 15:11:04
>>203
ゼロ除算は結構簡単に発生するから良い例なんだよね。
異常度が高いというレベルで考えれば、数学概念を破壊するほど
高い異常な事態なんだけど、会計処理なんかでどかんと
処理したいときなんかは、簡単に発生するし。
0205デフォルトの名無しさん2010/05/08(土) 15:18:22
>>201
そんなクリティカルな部分で悩むのにデザインパターンを
採用するのがキチガイなんだよね。
0206デフォルトの名無しさん2010/05/08(土) 15:57:37
なんで割り算する前に判定しない前提なの？
知恵遅れなの？
0207デフォルトの名無しさん2010/05/08(土) 16:04:32
例外は要らない

ただ0除算例外の回避方法が、事前に０かどうか検査する、ってのはちょっと違う。
それは特定の例外を回避する方法に過ぎず、一般的にどんな例外が
起きるかはやってみないと分からない場合に使えない。

例外に代わる仕組みとしては、システムコールのerrnoみたいに
どこか別にエラー情報を持つのがいいと思う。

たとえば、
　 a = b / c;
　if(errno == division_by_zero)
           /* 0除算時の処理 */
あるいは、
　(a, errno) = b / c;
ですかね。
goみたいだけど
0208デフォルトの名無しさん2010/05/08(土) 16:16:58
>>186
> >>178
> 必要以上に記述量が多いので大部分の人は使ってくれないでしょう。

それが使ってるんだな、Javaで。弱冠文法が違うが。
0209デフォルトの名無しさん2010/05/08(土) 16:19:21
errnoは今さらあり得ない。
0210デフォルトの名無しさん2010/05/08(土) 16:24:27
イメージしやすいようerrnoを使ったまでだよ
0211デフォルトの名無しさん2010/05/08(土) 16:26:01
なんで台無しにした後始末の話になるんだよ
未然に防ぐ方法を考えろや
0212デフォルトの名無しさん2010/05/08(土) 16:28:07
例外なんて必要ない
ファイル開けなかったらabortすればいい
0213デフォルトの名無しさん2010/05/08(土) 16:28:11
>>188
たまにしか使わない部分は長いほうがいいかもしれない。
でも、言語は常に使う部分だから短いほうがいい。
CもRubyも短くかけるから好まれる。

例外の話に限ればもっと話してもいいかも。
>>189
関数定義の段階で賛同していないけど、例外処理の話はしてもいい人とも
話せなくなるよ。
0214デフォルトの名無しさん2010/05/08(土) 16:59:49
>>213
言語仕様をどうするかって話をしてるので、
俺の提案は、関数仕様ごと改革するべき、
という提案の中に例外が含まれている。

例外だけを話したい人は、その主旨を汲んでくれないと、
俺の側からはまだ歩み寄れない。分かるかな？これ。
言語仕様って部分と全体が有るので、部分ばかり追い求めると
機能ＡとＢが当たり困ったりするじゃん。

もちろん例外だけを話したい人でも、その方法では例外のこれが
このように出来ないとちゃんと（訳の分からないＯＳ持ち出さず）
話してくれるのなら聞く用意はとてもある。
0215デフォルトの名無しさん2010/05/08(土) 17:01:51
アプリケーションレベルならsetjmp/longjmpで十分な件。
OSとか作る場合他のプロセスの発生した例外の
トラップとか必要なわけでjavaなんか真似ても
全く使い物にならない件。
0216デフォルトの名無しさん2010/05/08(土) 17:04:01
signalとごっちゃになっとるな
0217デフォルトの名無しさん2010/05/08(土) 17:10:47
ブログラムエラーとかプログラムでは避け難いエラー処理を行うのが例外だからな
構文に入れちまったのはC++やJavaの設計ミスと思うがね

0割の例ならCPUがトラップする時点でランタイムやOSが関与するし、発生しないCPUもある
言語よりランタイムの話でいんじゃね
0218デフォルトの名無しさん2010/05/08(土) 17:13:26
頭が設計ミスの奴がいるな
0219デフォルトの名無しさん2010/05/08(土) 17:17:42
お前がな
0220デフォルトの名無しさん2010/05/08(土) 17:51:44
あの辺の言語に try-catch が導入されていることを、ただ単に設計ミスと言っているようなヤツは、このスレで発言するのは控えてほしいな。
0221デフォルトの名無しさん2010/05/08(土) 17:59:33
脳を0割しか使わないとこういう発言をしてしまうんだな
0222デフォルトの名無しさん2010/05/08(土) 18:10:48
さらに新しい言語には導入されてない理由も考えずに戯言いうなよw
0223デフォルトの名無しさん2010/05/08(土) 18:12:17
まあ形かえたgotoだからな
汚いのは当然
0224デフォルトの名無しさん2010/05/08(土) 18:16:20
例外を文法でなくライブラリで実現した言語って何があったっけ？

まさかsetjmp/longjmpを使えとか言うんじゃないよな。
0225デフォルトの名無しさん2010/05/08(土) 18:20:00
むしろ関数の後ろにエラー専用のラベルを付けられるようにしろよ
VBみたく
結局ブロックでネストさせんのが面倒ってことだろ
0226デフォルトの名無しさん2010/05/08(土) 18:23:52
setjmpを構文に取り入れただけだしな
OSとか組込とか例外自身を記述するのはどうすんだ？
0227デフォルトの名無しさん2010/05/08(土) 18:27:22
longjmpにはjmp_bufを渡す必要があるわけだが、大抵の言語の例外は、そんな面倒な仕様じゃないぞ。
0228デフォルトの名無しさん2010/05/08(土) 18:28:19
いろいろそういうことがあるから、OSはC++ではなく、Cで書かれているんじゃないか。
0229デフォルトの名無しさん2010/05/08(土) 18:36:53
Cでもマクロで隠しちまえば似たことはできるわな
金粉かけても汚いモンはきたないし。

あんなモン構文にいれちまうから
エラー処理まで例外にしちまうバカがでるし、
無用なオーバーヘッドを意識せずにつかっちまう
0230デフォルトの名無しさん2010/05/08(土) 18:39:25
>214
なら関数仕様をどうするつもりなのか説明しないと話にならんな。
エスパーじゃないんだから、まとめて話してもらわんとわかるわけ無いだろ。
単にc++の例外仕様を変更しただけっつうなら単なる不燃ゴミだがな。
0231デフォルトの名無しさん2010/05/08(土) 18:39:25
馬鹿の発言が頻繁すぎる
0232デフォルトの名無しさん2010/05/08(土) 18:39:48
>>202
デザインパターンは普段当たり前のように使っているものでブームではないはずなんだが。
デザインパターンとクラウドは直交する概念
0233デフォルトの名無しさん2010/05/08(土) 18:40:17
>224
scheme
0234デフォルトの名無しさん2010/05/08(土) 18:42:53
>>231
賢い発言してくれよ
0235デフォルトの名無しさん2010/05/08(土) 18:43:37
>>205
どこがクリティカルでどこがキチガイなんだ。
JavaやC#では「デザインパターンありき」で開発するからどこでメモリ解放するかを
きっちり意識する必要はないんだが。staticイニシャライザやProxyパターンを使わないでループ内でしつこく無駄にnewしてるわけでもなかろうし。
むしろぞんなメモリのことでキチガイのように無駄に悩む必要がないからデザインパターンを使えるわけだが。
0236デフォルトの名無しさん2010/05/08(土) 18:51:39
>>217
DivideByZeroExceptionを実装する代わりに
MATLABのように　
0/1
と入力すると
Inf (無限大)と出力でもする仕様にするのか？
pow(-1,1/2)　(-1の平方根)と入力するとNaNと出力せずに
i (虚数)
と出力する複素数型仕様にでもするのか？
0237デフォルトの名無しさん2010/05/08(土) 18:52:22
>>222
C#、PHPで導入されているが何か
0238デフォルトの名無しさん2010/05/08(土) 18:53:49
話が発散するから「低級言語」として適当でない話題は他所でやれよ
スレタイにC++が入ってるのがそもそも良くないんだが
0239デフォルトの名無しさん2010/05/08(土) 18:58:40
>>238
新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

おまえがこっちでやればいいだろ
0240デフォルトの名無しさん2010/05/08(土) 19:05:23
>>233
Lisp族でマクロで実現されているものはライブラリというより文法の一部だろ。
0241デフォルトの名無しさん2010/05/08(土) 19:06:40
ライブラリで出来るなら
まずは既存の言語で優れたライブラリを作ってみたらどうだ？
0242デフォルトの名無しさん2010/05/08(土) 19:13:27
>>238
低級言語でも例外処理とオブジェクト指向を適用しよう
というのは無理か
0243デフォルトの名無しさん2010/05/08(土) 19:16:15
いまどきは組み込みですらC++使っているから
0244デフォルトの名無しさん2010/05/08(土) 19:21:27
>>243
C++の機能をほとんど使わずにな
0245デフォルトの名無しさん2010/05/08(土) 19:24:12
とりあえずここらでターゲットを明確にしておいたほうがいい。

ファームウェア～コンソールアプリもしくはサーバーサイドアプリくらいでいいよな？
0246デフォルトの名無しさん2010/05/08(土) 19:25:21
C言語でもオブジェクト指向プログラミングは可能だし。
ジョークのストラウストラップインタビューにあるように、Xウィンドウシステムのフレームワークが
そうだし、解説した本も数冊ぐらいある。

FORTHでOOをやったという話もあるぞ。
0247デフォルトの名無しさん2010/05/08(土) 19:28:04
デバドラなんて昔からOOチックだしな
0248デフォルトの名無しさん2010/05/08(土) 19:29:47
組み込みの幅は広いからな
0249デフォルトの名無しさん2010/05/08(土) 19:30:03
そりゃ自動でやってくれることを手動でやれば
Cでもオブジェクト指向は可能だろうよ。
めんどくさくてやってられないだけで
0250デフォルトの名無しさん2010/05/08(土) 19:33:25
>>240
言語仕様を変えずに実現できれば、ライブラリで可能ということになるでしょう。
文法が変えられるならそれだけ言語のライブラリで出来ることが増えるだけなのに
反則と思ってもらってもなぁ。

>>242
C++で出来てるから無理ではないけど、C言語レベルの話が
固まっていないうちからオブジェクト指向を持ち出すべきじゃないでしょう。

0251デフォルトの名無しさん2010/05/08(土) 19:39:24
例外ライブラリでやってなんかメリットあるのか？
ゼロオーバーヘッドにできるの？
0252デフォルトの名無しさん2010/05/08(土) 19:43:55
あほが多用しなくなる
0253デフォルトの名無しさん2010/05/08(土) 19:44:54
おまえがあほだろw
0254デフォルトの名無しさん2010/05/08(土) 20:02:34
>>253
賢いなら
例外がどういう実装になるか
エラー処理として使う是非
普通にエラー返すのに比べての利点も教えてくれよ
0255デフォルトの名無しさん2010/05/08(土) 20:04:52
普通にエラー返すんだったら、全部返り値チェックして、そのあとの処理をスキップする
ifがいるだろ。
0256デフォルトの名無しさん2010/05/08(土) 20:06:04
ライブラリで例外作ってから来てくれよ
0257デフォルトの名無しさん2010/05/08(土) 20:18:15
タイトルにCって入れたの間違いだったな
C++使ったことない奴レベルが低すぎる
0258デフォルトの名無しさん2010/05/08(土) 20:22:01
>>256
setjmpとマクロで似たことできるし
at exitみたいなんでランタイムでひっかけてもいいかな

>>255みたいにエラー処理サボって大域脱出のためならむしろ有害w

ま、完全に無くすのは無理だとは思ってるが
カジュアルに使うならあかんよw
0259デフォルトの名無しさん2010/05/08(土) 20:25:56
例外で処理をすっ飛ばすのを「エラー処理をさぼって」とかwwwwww
0260デフォルトの名無しさん2010/05/08(土) 20:29:37
で、すっ飛ばしてリソース漏れを起こすんですね。わかります。
0261デフォルトの名無しさん2010/05/08(土) 20:30:14
関数（メソッド）の引数が異常な場合は例外を投げるという仕様で、いろいろなものがすっきりする。
また、アンチgoto論者にも好まれる。
0262デフォルトの名無しさん2010/05/08(土) 20:32:20
>>260
解放忘れは、例外がない場合の方が冒しやすい。
0263デフォルトの名無しさん2010/05/08(土) 20:33:04
>>258
いいから作ってこいよ
0264デフォルトの名無しさん2010/05/08(土) 20:33:47
ところがどっこい、例外で飛ばさずに全部いちいち処理せよと仰る御仁が現れたわけだ。
RAIIって全然普及してないんだな。
0265デフォルトの名無しさん2010/05/08(土) 20:36:07
そりゃRAIIなんて使ってるメジャーな言語はC++ぐらいだからな
0266デフォルトの名無しさん2010/05/08(土) 20:52:09
カリー化した関数にjavaのアノテーションをつけられたら、
いいなぁ、みたいな話だったんだろうな。
0267デフォルトの名無しさん2010/05/08(土) 20:52:30
RAIIと言わずに「オブジェクトの所有権をハッキリさせる」とすれば良いよ。

>261
契約による設計かね？それもけっこう重たいよ。
まあ、(assertみたいに)コンパイルオプションで無効にできるようにするとか、関数の戻り値の契約と合致する場合は
動的チェックを省略するとか色々と改善の余地はあるけど。
0268デフォルトの名無しさん2010/05/08(土) 20:58:23
大域ジャンプでスタックを巻き戻す際のデストラクタ呼び出せないよ、
スマートポインタどうしようもなくなってしまうよ問題

0269デフォルトの名無しさん2010/05/08(土) 21:05:25
大域ジャンプを高機能化する
スコープ抜けるときに後始末をするようにするとか
0270デフォルトの名無しさん2010/05/08(土) 21:11:44
いっぺんフリースタンディング環境で作ってみればいいよ
例外とかGCとかどんだけアフォな話してるのが理解できるから
0271デフォルトの名無しさん2010/05/08(土) 21:16:35
>>270
フリースタンディングな環境ではわざわざ例外とかGCとか
作ってられないと？

0272デフォルトの名無しさん2010/05/08(土) 21:25:04
>>271
OS作れるような言語と言っているのに、OSに依存するような機能を入れようとしている。
0273デフォルトの名無しさん2010/05/08(土) 21:30:30
例外はCPUに依存するのではないでしょうか？
GCはライブラリに依存とはいえCPUごとに異なるので作るの大変。
それはOSの仕事に近い部分と。それは分かります。
0274デフォルトの名無しさん2010/05/08(土) 21:41:37
むしろマルチタスクとかページングとか作るのが簡単だったりして
例外とGCはシングルタスクの殻に閉じこもってる
0275デフォルトの名無しさん2010/05/08(土) 21:53:23
GCはOS必須ではないがな
0276デフォルトの名無しさん2010/05/08(土) 21:55:22
>>275
必須だよ。
0277デフォルトの名無しさん2010/05/08(土) 22:13:48
>>276
なぜGCにOSが必須なんですか？
0278デフォルトの名無しさん2010/05/08(土) 22:19:19
行儀の悪いアプリが終了したとき＆強制終了したとき
掴んでたメモリを開放する処理は必要
一種のGCみたいなものになる。
0279デフォルトの名無しさん2010/05/08(土) 22:26:42
それGCと関係なくね
だいたいOSの存在しない世界って、基本的にゼロ番地から全部自分のモンだろ
行儀の悪いアプリとか何だそりゃって話だ

モダンなGCは専用のタスクやスレッド裏で走らせるのが普通だと思うが
N88BASICとかにもガーベージコレクションはあっただろ
0280デフォルトの名無しさん2010/05/08(土) 22:51:44
>>277
GCどころかヒープでさえOS必須だ。ヒープなしでGCあっても意味ないだろ。
0281デフォルトの名無しさん2010/05/08(土) 22:59:58
>>280
釣り？
OSのある世界しか知らない？
言語作ろうなんて1億年早い？
0282デフォルトの名無しさん2010/05/08(土) 23:04:16
>>278
普通のOSならプロセスのリソースは管理されてるからな
またちょっと別だよ
RTOSは別だがありゃマルチスレッドだからな
0283デフォルトの名無しさん2010/05/08(土) 23:09:01
ヒープから取得したメモリアドレスがどのプロセスに属してるかを
把握してないと開放できないとかあるとか？
0284デフォルトの名無しさん2010/05/08(土) 23:20:48
MLton

を越えれるのかな
0285デフォルトの名無しさん2010/05/08(土) 23:24:38
>>281
ヒープが何かを知ってからそういうことを言え。
0286デフォルトの名無しさん2010/05/08(土) 23:29:17
>>283
OSがある世界ならヒープの元を仮想アドレスで割り付ける。
物理メモリの管理は必要だけど
アプリのヒープ自体はOSからは大して意味ないからね

ま、あんまネタまきすぎるのもアレだが
あんま低レベルでもないがValaとGenieはどうよ
0287デフォルトの名無しさん2010/05/08(土) 23:30:27
OSやタスクやプロセスの線引きをどこで行うかの話でしかない
「OSは必要だよ」厨はスルーでよい
0288デフォルトの名無しさん2010/05/08(土) 23:32:53
OS作るなら言語がヒープの管理してちゃ困るだろ
0289デフォルトの名無しさん2010/05/08(土) 23:33:15
>>287
なんでOSがC++で書かれていないのかも分かっていないな。
0290デフォルトの名無しさん2010/05/08(土) 23:34:28
>>285
常識的な知識位しかないね
組み込み屋だからOSなしの環境に
libcサブセットのmallocとかprintf位は作ったことあるがねｗ
当然だがリセットから初期化してヒープの準備とかもなｗ
0291デフォルトの名無しさん2010/05/08(土) 23:35:01
タスクスイッチするだけのチープなOSもあるよ。
そういうのはヒープ＝スタックを除く物理メモリのこと。
GCを単体のタスクに対して行うか、全体に対して行うか。
前者ならOSは不要、後者ならOS上に乗っかってる。
0292デフォルトの名無しさん2010/05/08(土) 23:36:39
>>289
C++で書かれてますって自慢してたOS、昔あったような
世間知らずさん
0293デフォルトの名無しさん2010/05/08(土) 23:39:32
>>290
それはOSのメモリ管理のところを作っているじゃないか。
0294デフォルトの名無しさん2010/05/08(土) 23:40:09
メモリ管理＝OSだと思ってるのかな
GCにOSは不要ですよー
0295デフォルトの名無しさん2010/05/08(土) 23:41:35
>>288
別に困らないよ。
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおｋ。
0296デフォルトの名無しさん2010/05/08(土) 23:42:57
まだくだらないことで揉めてんのかw
そもそもGCはスレ違いなんだよ
0297デフォルトの名無しさん2010/05/08(土) 23:45:28
>>292
そういうで意味ならWindowsだってC++で書かれているし、NeXTはObjective-Cで書かれている。
その下により低水準のOSがいる。
0298デフォルトの名無しさん2010/05/08(土) 23:49:45
>>296
確かに1970年代の低級言語にGCはなかったが
2010年だからということで揉めてる
0299デフォルトの名無しさん2010/05/08(土) 23:53:24
GC付きでいいならD言語使えばいいのに
0300デフォルトの名無しさん2010/05/08(土) 23:53:53
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
0301デフォルトの名無しさん2010/05/08(土) 23:55:59
GC有り無し両方に対応したプログラムを単一のコード（あるいは最小限の修正）で記述出来ればいいね。
0302デフォルトの名無しさん2010/05/08(土) 23:56:26
メモリ管理を書くのにメモリ管理がすでにあることを想定している言語を使う。
0303デフォルトの名無しさん2010/05/08(土) 23:57:07
低水準言語という観点から言えば、2010年だろうが何だろうが
GC無しで使いたいことは多いはずなので
言語仕様のレベルでGCを前提にするのはやりすぎだろ
GC前提にすることで色々楽チンになって
クロージャのようなオサレ機能が使えるとしても我慢汁

で、言語仕様のレベルでGCを前提にしないならライブラリで、ということになるが
それだけならCでも出来る
malloc()ではなくてGC_malloc()みたいなのを呼べばいいだけだ
つまりここで話すような事柄じゃない
0304デフォルトの名無しさん2010/05/08(土) 23:57:29
>>301
C++/CLI
0305デフォルトの名無しさん2010/05/08(土) 23:59:25
>>302
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおｋ。
0306デフォルトの名無しさん2010/05/09(日) 00:02:52
>>305
new が使えないC++は、もはやC++とは呼べない。
0307デフォルトの名無しさん2010/05/09(日) 00:02:55
>>303
低水準言語という観点から言えば、2010年だろうが何だろうが
除算無しで使いたいことは多いはずなので
言語仕様のレベルで除算を前提にするのはやりすぎだろ

低水準言語という観点から言えば、2010年だろうが何だろうが
goto無しで使いたいことは多いはずなので
言語仕様のレベルでgotoを前提にするのはやりすぎだろ

低水準言語という観点から言えば、2010年だろうが何だろうが
例外無しで使いたいことは多いはずなので
言語仕様のレベルで例外を前提にするのはやりすぎだろ
0308デフォルトの名無しさん2010/05/09(日) 00:06:18
>>306
別に呼びたくなければ呼ばなくてもいい。
C++を作る過程で「new が使えないC++」を使って何の問題があるんだ？
すべてが常に完全である必要はない。
言語は単なる手段だ。使いやすいように使えればそれでいい。
0309デフォルトの名無しさん2010/05/09(日) 00:07:11
>>307
馬鹿はコピペぐらいしか脳が無いのか

言語仕様のレベルでGC前提なら、GCを動かすまではその言語は使えないということ
だろが
それだとCより用途が確実に狭まる、言い換えれば上の層の言語になっちまうだろ
メモリマネージャみたいなのに頼れない場所でも貧者のmalloc()を自分で書いて
使えるのがCだ
0310デフォルトの名無しさん2010/05/09(日) 00:07:28
>>305
だがちょっと待ってほしい
既存の言語の上に何かを積み上げるのは無意味ではないのか
0311デフォルトの名無しさん2010/05/09(日) 00:08:51
>>306
operator newは自分で実装できるし
placement newもあるだろ

デフォルトのアロケータに頼り切ったような「普通の」C++コードを
そのまま使えないだけだ
0312デフォルトの名無しさん2010/05/09(日) 00:10:18
>>306
newのお勉強スレ行ってこい
0313デフォルトの名無しさん2010/05/09(日) 00:10:34
>>309
>言語仕様のレベルでGC前提なら、GCを動かすまではその言語は使えないということ

それはない。
言語仕様をすべて実装しなければ動かないのであれば、動くC++処理系はこの世に存在しない。
言語仕様のフル機能を備えたC++は存在しないからな。
0314デフォルトの名無しさん2010/05/09(日) 00:10:47
>>311
それじゃ、C++使っている意味ないだろ。
0315デフォルトの名無しさん2010/05/09(日) 00:11:31
>>310
そう。
だから新言語の上に新言語を積み上げる。
0316デフォルトの名無しさん2010/05/09(日) 00:13:57
ここは困ったちゃんを相手にするスレ
0317デフォルトの名無しさん2010/05/09(日) 00:14:43
アホ避けが欲しいな
せめてD&Eくらいは読んでいて欲しい
0318デフォルトの名無しさん2010/05/09(日) 00:16:29
>>314
は？何で無いんだよ
テンプレートだのクラスだのといった便利な抽象化機能が普通に使えるぞ

C++の規格に盛り込まれているfreestandingの意味も知らない
ド厨房はすっこんでろよ
0319デフォルトの名無しさん2010/05/09(日) 00:19:34
>>317
そんな無駄レス書き込んでる暇があったら、D&Eを読んだ成果を披露しろ
0320デフォルトの名無しさん2010/05/09(日) 00:22:04
馬鹿の相手をするのも疲れるんだよ
0321デフォルトの名無しさん2010/05/09(日) 00:34:13
気力を一方的に奪われるだけで得るものが何もないスレ
0322デフォルトの名無しさん2010/05/09(日) 00:35:44
D、C++/CLI、Objective-C にある機能しか出てこないな。
0323デフォルトの名無しさん2010/05/09(日) 00:40:28
Cで誰も本気で困っていないから。
0324デフォルトの名無しさん2010/05/09(日) 00:43:25
C以上に低級だとアセンブラだし高級だとC++になっちまうしな
0325デフォルトの名無しさん2010/05/09(日) 00:43:59
流石にnewが使えないとかいう妄言はないわ
0326デフォルトの名無しさん2010/05/09(日) 00:45:24
GCにOSが必要とかなｗ
0327デフォルトの名無しさん2010/05/09(日) 00:57:44
OSが無いとGC前提の言語は作れないとか言ってる人間は、天から与えられたOS、コンパイラしか使ったことがないんだろうな。

OSを作るような場合、コンパイラも自前である程度作る。
もちろん、全てを一から作るわけではなく、既存のコンパイラをポーティングしたりするが、その作業は自前で行う。

そのとき、フル機能のコンパイラを作ってから、OSを作りじめるなんてことはしない。
コンパイラを一部作り、OSを一部作り、コンパイラを一部作り、OSを一部作り、を繰り返して完成させる。

【第Nフェーズ】
コンパイラ係：とりあえず、制御系はforだけ作りました。ローカル変数はまだダメです。グローバル変数でやってください。
OS係：ローカル変数まだとかマジかよ。。まあいいや。次回までにお願い。
コンパイラ係：了解しました。ところで、GC作りたいんですけど、ヒープ周りの実装できてます？
OS係：ごめん、ヒープはもう少しかかる。先に例外やっといて。
コンパイラ係：はい。それじゃあ、ローカル変数と一緒に例外やっときます。

【第N+1フェーズ】
コンパイラ係：ローカル変数と例外対応しましたよ。
OS係：サンキュ。ところで、変数名は8文字以上だとエラー出るんだけど。
コンパイラ係：ああ、それ現在の仕様です。次までに言語仕様通り最低256文字まで使えるようにしておきます。
OS係：頼むわ。ああ、ヒープ使えるようにしたから、GC作っちゃって。
コンパイラ係：はい。やっておきます。
0328デフォルトの名無しさん2010/05/09(日) 00:58:41
お前頭悪いだろｗ
0329デフォルトの名無しさん2010/05/09(日) 01:03:21
CPUは既にあるものを使うし
Cなら既存のコンパイラが普通に使えるっつーの
0330デフォルトの名無しさん2010/05/09(日) 01:04:04
リンカは別だけどな
0331デフォルトの名無しさん2010/05/09(日) 01:13:59
>>329
> CPUは既にあるものを使うし

言語仕様に「既存のCPUを使うこと」って文言を入れるの？
なんたるCPU依存言語ｗｗ
0332デフォルトの名無しさん2010/05/09(日) 01:14:24
作るにしても最初はgccへのトランスレータにしてくれ
そうしないときっと使わない
0333デフォルトの名無しさん2010/05/09(日) 01:17:14
>>245
サーバサイドアプリを作るのになぜ低級言語が必要なんだ？

っていうツッコミが

低級言語のメリットは省メモリ超高速。

となるとそういう分野は
ハードウェア、組み込み系、OS系、デバイスドライバ系
となる。
するとそういう分野に強い言語は、最終的にC言語という結論にたどり着く。

ではどうすればいいかというとC言語からシガラミと汚物を削りとって理路整然とさせ生まれ変わらせることだね。

で、さて例外処理をどうするか、だがオブジェクト指向にするか？　という話だが…。

Javaを参考にするとどうしても高級言語の方向になる。
でもJavaでも低級言語にとって参考になる例がひとつある。
enum型とEnumSetだ。EnumSetはenum型の値を保持する重複を許さない集合だ。
そして内部はビットフィールドで管理されているということは、EnumSetにenum型1つを格納すると1ビット、2つ格納で2ビット、3つ格納で3ビット
と、オブジェクトにも関わらず超軽量オブジェクトを作ることができる。
なにせenum型の正体はSingletonパターンのSingletonであり継承できないクラス。メモリをうまく節約しているのが特徴だ。
ようするにJavaのenum型はSingletonになったType Safe enumパターンで作ったクラスのシンタックスシュガーということ。

こういうところだけ真似をすれば省メモリ超高速低級言語を作るさいの参考になるかもしれないぞ。
0334デフォルトの名無しさん2010/05/09(日) 01:18:57
１つ分かったことがある。
低レベルな層ではオブジェクト指向やクロージャが使えないから、
多態性を使えば出来るからいらない、クロージャ使えば出来るからいらない
テンプレートあれば出来るからいらないって話が通用しなくなる。
型安全性より、スピード。分かりやすさよりスピード。
そういう世界ではマクロ利用に対するニーズは高まる。
マクロは実行時のコストはゼロだからだ。
0335デフォルトの名無しさん2010/05/09(日) 01:20:33
低レベルな層でもオブジェクト指向はできるよね。
0336デフォルトの名無しさん2010/05/09(日) 01:28:29
>>327
うけたw
普通はクロスと既存の移植だろw

>>333
CPU固有君だろw
ビット単位はあんま速くないぞ

休日なのにこのスレは電波度高いなw
0337デフォルトの名無しさん2010/05/09(日) 01:29:32
>>246 もしこれから作る言語がCでオブジェクト指向っぽいことができるが
やりづらい言語ってのを目指しているなら

デフォルトでinterfaceやabstractクラスを作れない
デフォルトで継承できない
クラスのフィールド、メソッドはすべてデフォルトでstatic

ということにすればいいのではないだろうか。


わざとオブジェクト指向を使いにくくして
オブジェクト指向をやるには特別なオプションがいる、という手法。
これに似た手法は、C#のunsafeがある。
C#でC言語のようなメモリリークの原因を誘発するような危険なコードを
どうしても書きたいときはunsafeブロックで囲うという。

そのunsafeの逆をすることで、堅牢性が高く安全でかつオブジェクト指向チックなコードが
かけるというふうにすればいいのでは。
こんなふうに

safe {
　Map<Set<String>, List<?>> all = new LinkedHashMap<Set<String>, List<? extends Number>>();
　for(int i = 0; i < 100; i++){
　　Set<String> key = new LinkedHashSet<String>();
　　List<Integer> value = new LinkedList<Integer>();
　　for(int j = 0; j < 100; i++){
　　　key.add("Test" + j);
　　　value.add(j);
　　}　　
　　all.put(key. value);
　}
}
0338デフォルトの名無しさん2010/05/09(日) 01:31:20
>>332
Vala/Genieでいんじゃないw
0339デフォルトの名無しさん2010/05/09(日) 01:31:56
>>267
思うのだが
重たい問題は自動最適化コンパイラで解決できるような

そんなコンパイラを作るのはものすごい技術力と知能が必要だが
0340デフォルトの名無しさん2010/05/09(日) 01:33:27
ROMに書き込むような組み込みだと、、
多態どころか関数ポインタテーブルすら使いたくない状況がある。
パフォーマンスも重要だけど、傾向としてはサイズ＞スピードの場合が多い。
それとプリプロセッサの条件ディレクティブを多用することになる。
欲しいのはテンプレートぐらいかな。あえて言えば。
0341デフォルトの名無しさん2010/05/09(日) 01:37:39
RAMすら無しでブートしたりね
多分組み込みやったことないと想像も出来んだろ
それでも動かせるCは偉大だな
0342デフォルトの名無しさん2010/05/09(日) 01:37:40
>>279
ちょっと気になるんだが

ということはこのスレで作る言語の配列とやらは
初期化したときに宣言した配列領域をオーバーしたバッファーオーバーフローも当たり前ということか？
JavaのようにNegativeArrayExceptionとArrayIndexOutOfBoundsExceptionも吐かないと？
0343デフォルトの名無しさん2010/05/09(日) 01:39:25
>>296
GCを実装したアセンブラ
ってのもなんだかわくわくするじゃないか
0344デフォルトの名無しさん2010/05/09(日) 01:41:26
MMUにGC支援機能とか搭載しないのかな
0345デフォルトの名無しさん2010/05/09(日) 01:42:44
いっそCPUにGCとオブジェクト指向命令を追加すればw
0346デフォルトの名無しさん2010/05/09(日) 01:42:47
>>343
ちっともしない。
そんなのライブラリ呼び出すしかないじゃん。
0347デフォルトの名無しさん2010/05/09(日) 01:43:29
>>303
JavaでもGCがうざくなったときに対処するクラスがちゃんとあるよ
意図的にGCを発生させるSystem.gc()
不要になったオブジェクトを即座に破棄してくれるSoftReference

http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/ref/package-summary.html

これよりもさらに高機能なセミオートGCを実装すればいいのではないかな・
0348デフォルトの名無しさん2010/05/09(日) 01:43:33
しかないかどうかは、これから決めること
0349デフォルトの名無しさん2010/05/09(日) 01:44:45
>>344
MMUじゃ管理単位が荒過ぎるな
mark and sweep GC命令でw
FPGAなら書けるだろw
0350デフォルトの名無しさん2010/05/09(日) 01:44:55
>>348
ノイマン型で決めるも何もないだろ
0351デフォルトの名無しさん2010/05/09(日) 01:46:07
>>350
どういう意味？
0352デフォルトの名無しさん2010/05/09(日) 01:46:34
>>336
ビットフィールドによるインデックスの管理は
そのリストや集合があまりにも膨大なとき真価を発揮するのだが。
0353デフォルトの名無しさん2010/05/09(日) 01:46:34
LISPマシンてどういうアーキテクチャなの？
0354デフォルトの名無しさん2010/05/09(日) 01:47:39
>>345
欲しいな。未来のCPUだ

そして並列処理もできるといいな
0355デフォルトの名無しさん2010/05/09(日) 01:48:24
なんか単語を並べてるだけだなこのスレ。
0356デフォルトの名無しさん2010/05/09(日) 01:48:29
>>349
FPGAでは条件分岐が多い処理は性能が出ないから難しい。
下手するとCPUでソフトウェア処理するのより遅くなる。
0357デフォルトの名無しさん2010/05/09(日) 01:53:49
ＧＣの実装とかコンパイラの実装の知識あって書いてんのかな
0358デフォルトの名無しさん2010/05/09(日) 02:01:44
あって書いている場合もあれば、なしで書いている場合もあるだろう。
もちろんどちらも歓迎だ。
0359デフォルトの名無しさん2010/05/09(日) 02:11:29
すこしはまとめてこうよ・・・
0360デフォルトの名無しさん2010/05/09(日) 02:12:10
>>342
デフォルトで境界チェックあり、
オプションで外せるぐらいが無難な線ではなかろうか

ポインタって概念はなかなか秀逸だと思うが、
あまりに低水準で柔軟すぎて最適化の障害になってる
しかし、アドレス操作すらできないのではCの代替言語として問題があるだろう
配列との絡みも含めて、何をどこまで認めるか、悩ましいところ
0361デフォルトの名無しさん2010/05/09(日) 02:14:39
>>359
どうぞ、どうぞ。
0362デフォルトの名無しさん2010/05/09(日) 05:46:51
>>358
大きく間違ってる。
無い人でもせめてコードを読んだことがある
レベルじゃないと、話にならない。
このスレで言う素人はＧＣ実装の納品経験はないけども、
読んだことは有るし、改良加えようと遊びで弄ったことは有る。
というレベルじゃないと。
0363デフォルトの名無しさん2010/05/09(日) 08:15:55
既存のGCの問題点

･利用形態を問わず管理する人(メモリマネージャもどき)が絶対に必要
･効率優先である程度まとめてGC処理を走らせるためCPU時間を占有する
　もちろんアドレス移動とかしてるのでその間プログラムは停止するしかない
･その分だけCPUおよびメモリリソースを多く消費する
･循環参照とスレッドセーフを同時に解決したGC技術は未だに確立されていない

要約すると「言語に組み込む必要はない」「必要なときに(環境に合った)ライブラリ使用で十分」となる
個人的にはGCは優れた技術とは思わない
0364デフォルトの名無しさん2010/05/09(日) 08:43:56
>>363
大体同じ意見なんだけど、少し視点を変えて、
ライブラリで対応可能（newとdeleteを上書きすればよい）
なＧＣを、言語仕様に取り込まなかった場合どういう不具合
が発生するか考えてみたい。

だが、俺は思いつかない訳なんですよ。

ＧＣを言語仕様に取り込んでしまうと、deleteの存在がなくなってしまって
逆に、ＧＣを切るという行為がどのような不具合（プログラム）を発生させる
か予測が付かなくなってしまうんだよね。

逆に、ＧＣが無い、そういう前提で組まれたプログラムでも、どうしても
品質が上がらず、メモリーリークが発生して苦肉の策として、newとdelete
を拡張してＧＣ制御に移行したとしても、この場合チェックした既存のコードに
与える影響は前者より少ないと思うんだ。

ので、ＧＣは必要ないと思う。
0365デフォルトの名無しさん2010/05/09(日) 08:45:29
>>362
> ＧＣ実装の納品経験

そんな経験ある奴あんまりいないと思うが...
開発経験ならまだしも。
0366デフォルトの名無しさん2010/05/09(日) 08:56:13
GC納品・・・
0367デフォルトの名無しさん2010/05/09(日) 09:01:13
独自のStringクラスやデータベースは、GCやってる。なんなら、オブジェクトはすべてデータベースに置くというのはどうだ。
0368デフォルトの名無しさん2010/05/09(日) 09:19:09
アホは書き込まないで
0369デフォルトの名無しさん2010/05/09(日) 09:23:43
まあ何を問題にしたいのかはわかるけどね。
低級言語と高級言語で例えばGCの有無により言語が全く異なる現状では、全く異なる言語を二つも学習しなければならない。
70年代の原始人ならそれで満足できるが、プライドばかり大きくなった現代人には耐えられない屈辱なわけだ。
0370デフォルトの名無しさん2010/05/09(日) 09:25:05
>>364
> ライブラリで対応可能（newとdeleteを上書きすればよい）
> なＧＣを、言語仕様に取り込まなかった場合どういう不具合

「確保したりソースが不要になったことを確実に知ること」ができなくなる。
0371デフォルトの名無しさん2010/05/09(日) 09:26:39
>>370
何言ってるのか分からないから、具体的にソースで書いて。
0372デフォルトの名無しさん2010/05/09(日) 09:43:18
GCの副作用もわからずにGCと言っているだけだろ。
0373デフォルトの名無しさん2010/05/09(日) 09:44:57
>>371
void bar(char **p);
void foo()
{
　char *p = new char[10]; // [A]
bar(&p);
}

[A] で確保したメモリーがいつ不要になったかを知るのは難しい
でしょ。
0374デフォルトの名無しさん2010/05/09(日) 09:46:28
>･循環参照とスレッドセーフを同時に解決したGC技術は未だに確立されていない
これは嘘だろ
Javaはマルチスレッド対応していて循環参照も消せる。
インクリメンタルなリファレンスカウンタ方式のGCでも循環参照を解決する方法は存在する
0375デフォルトの名無しさん2010/05/09(日) 09:51:55
GCをやりたければ単純なポインタ変数は禁止だろう。
オブジェクトポインタテーブルを用意し
オブジェクトポインタテーブルへのポインタを使わないと
メモリ管理そのものが成立しない。
当然実行効率は大きく低下する。
0376デフォルトの名無しさん2010/05/09(日) 09:56:17
>>373
意味分からねー、
なぜに引用して同じ意味のことを書いたのだ？
ちょっとキチガイレベルの高い人を相手にしてるのかな？

>>364から引用して>>370を書いて>>371で問い直したら>>373って
どう解読すれば良いんだろ？
0377デフォルトの名無しさん2010/05/09(日) 10:59:21
>>376
コード示してもわからないなら、多分あんたには理解できないと
言うことだと思うよ。

どこをどう引用してて、どこを同じ意味に取ってるか、わけわか
らんこと書いてるし。

> ちょっとキチガイレベルの高い人を相手にしてるのかな？

鏡見たほうがいいと思うぞ。
0378デフォルトの名無しさん2010/05/09(日) 12:02:12
GC無しで言語を作って置いて、GCありにも出来るようにすることは可能だ。
GCありにした場合だとGC無しのライブラリも、GCありのライブラリも使える。
GC無しだとGCありのライブラリは使えないと割り切るか、
混在して書くかという問題が出てきそう。
0379デフォルトの名無しさん2010/05/09(日) 12:21:27
>>373
横だけどそれは生ポインタをそのまま使ってるからじゃないの？
そういう指摘がしたいの？やっぱり何が言いたいかわからないと思うんだけど。
0380デフォルトの名無しさん2010/05/09(日) 12:36:46
>>378
GC有りにするとデストラクタの動作が変わるぞ。互換性がなくなる。
C#を例にとるとデストラクタに相当するファイナライザ使う場合は呼び出し順序が不定なためマネージドオブジェクトへの参照が禁止になる。事実上デストラクタでは何もできない。言語外のリソース市か触れない。
結局、usingとか呼び出し側でdisposeのタイミングを調整しなくてはならならなくなってしまう。
0381デフォルトの名無しさん2010/05/09(日) 12:52:21
まったく同じにはならないな。
ビルドするコードが「deleteで解放したオブジェクトはその後使用されない」という前提なら
GCありの場合、deleteが呼ばれずにGCによってオブジェクトが解放される場合は
メモリ解放以外のデストラクタ処理を行わなければ互換性は取れると思う。
0382デフォルトの名無しさん2010/05/09(日) 12:55:24
Ｃ＃を改良しようスレでもないし、Ｃ＋＋プログラミングでもないんだけどな。
0383デフォルトの名無しさん2010/05/09(日) 12:57:02
>>379
「ＣＧ使う時は、生ポインタなんて使わないでやるから、言語仕様なんかに
組込みなくてもいいじゃん」ということなの？

別にその考え方は否定しないし、ある程度うまくいくと思う。

ただそれでいいなら、malloc()/free() でもうまくいくはずだし、現実大
抵のケースはうまくいってるよね。でも、言語仕様で規制しないとだめな
ケースは "0" にはできないだろ。

俺は >>364 が不具合示せというから、「不具合の一例」を書いただけ。
そんなケースは「俺のところではありえない」と言うだけならまだわかる
けど、「俺のところではありえないから意味わからん」と言われてもな。
0384デフォルトの名無しさん2010/05/09(日) 12:58:29
いやＧＣ云々の話は常にでてるから議論のネタではあるでしょう。
別にクラスじゃなく組み込み型・構造体・配列だけでもGCは実装可能ではあるし。
その場合はポインタの実装を考えなくてはいけなくなるが。
0385デフォルトの名無しさん2010/05/09(日) 12:58:46
まあGCは無くていいんじゃね？
GCで解決するのはfree()し忘れる問題だけで
リソースリーク問題が無くなるわけじゃないし
0386デフォルトの名無しさん2010/05/09(日) 13:00:26
スマポ内蔵ならいいんじゃない
0387デフォルトの名無しさん2010/05/09(日) 13:08:31
S ex pression
0388デフォルトの名無しさん2010/05/09(日) 13:08:52
>>380
GCありにしても
デストラクタの呼び出しタイミングが変わるだけで、
デストラクタの動作そのものが変わるわけではないでしょう。
0389デフォルトの名無しさん2010/05/09(日) 13:09:58
GC有り無し混在するとしても、ポインタにメタデータ突っ込んどきゃいいんじゃね？
構造体にしてスマポ化するのも良いし、アライメントを活用するのもいいし。

今の時点だと、GCを考慮するとしてもポインタの扱いをどうするかぐらいしかできないだろ。
それよりもマクロとルーチンの話をしようぜ。
0390デフォルトの名無しさん2010/05/09(日) 13:12:57
GC最大の問題は最悪実行時間を保証できないこと
かといってGCが無いと、今度は無限エクステントは実現困難
わざわざ新たに設計する言語で、それはどうかと思うｗ
0391デフォルトの名無しさん2010/05/09(日) 13:13:58
>>383
そういえば話は通じると思う。
お互い論点の確認せずに持論しかいってないように見えるからよくわからんとなってると思う。

＞ただそれでいいなら、malloc()/free() でもうまくいくはずだし、
これは特に論点になってないと思う。GCがいるかいらないかが論点だったから
例としてnew/deleteの話になってただけなんじゃないかな。当人じゃないから分からんけど。
＞言語仕様で規制しないとだめなケースは "0" にはできないだろ。
>>364の肩を持つわけではないけど言語側でポインタを実装するときに
shared_ptrクラスのようにクラスオブジェクトのように解釈すればやはり解決可能じゃないかな。
しかしこれはビルドオプションで切り替えるか
常にこの切り換えのためのコストを払った実装にしなければならないと思うけど。
0392デフォルトの名無しさん2010/05/09(日) 13:15:29
GCのdelete呼び出しのタイミングが分からなくて
結果的にメモリ管理の考え方を変える必要があるわけだ。
だけど、そのGCありのプログラムとGCなしのプログラムが
混在した場合にどうあつかったらうまくいくかという点が問題なのでは？

0393デフォルトの名無しさん2010/05/09(日) 13:15:45
そこでgcnew
0394デフォルトの名無しさん2010/05/09(日) 13:18:45
混在させるメリットが不明。
同じコードをGCありでビルドするかなしでビルドさせるかという意味なら
ライブラリの使いまわしの話とかかなと思うが。
0395デフォルトの名無しさん2010/05/09(日) 13:18:56
>>392
C++/CLIを見れば分かる
俺に言わせればただのカオス、あくまで橋渡し用のアダプタ構築言語と見るべきで
好き好んで使うような代物じゃない
0396デフォルトの名無しさん2010/05/09(日) 13:19:46
お前に言われてもな
0397デフォルトの名無しさん2010/05/09(日) 13:22:46
gc_ptr<Hoge> hoge(gcnew Hoge);
gc_ptr<Hoge> hoge2;

hoge2 = hoge;
0398デフォルトの名無しさん2010/05/09(日) 13:23:48
>>393
だーよね。何を議論してるかわからんのだよ。
ＧＣ無し実装時は実装者がdeleteのタイミングを知って制御してる、
この制御が失われて、ＧＣへdeleteが移行して困ることって有るのか？
>>383　>>391
まだ全然伝わってこない。ライブラリ対応可能な（と俺は思ってる）仕様を
言語仕様に持ち込む話を聞いてるんだって>>364言語仕様でＧＣを前提として
構文規則を持っておかなければ、失われる情報はなんだって事だよ？

まさか言語仕様とか、ライブラリとか、ポインターの説明から始めなきゃ駄目？
0399デフォルトの名無しさん2010/05/09(日) 13:26:50
>>398
タイミングを知って制御してるはずのコードをＧＣありに移行するメリットが明示されてないよ。
その場合の問題点とのメリットのトレードオフも。
0400デフォルトの名無しさん2010/05/09(日) 13:27:27
>>398
例えばGC前提の言語仕様なら無限エクステントを作れるから
クロージャのようなものを言語仕様としてサポートできる
GCが単にライブラリとして利用可能、というだけならそれは無理
0401デフォルトの名無しさん2010/05/09(日) 13:29:13
>>400
だからＬＷＬの人は寝て手くださいってばぁ
迷惑かけてるのにいい加減気がついてよ。
0402デフォルトの名無しさん2010/05/09(日) 13:30:11
>>400
これを「面白い」ととるかが「人間性」の違い。
0403デフォルトの名無しさん2010/05/09(日) 13:30:13
>>401
LWLって何だｗ
ちなみに俺は「GCを言語仕様のレベルで組み込むな」派だ
つまりクロージャなんて入れられないが、諦めろ
GC_malloc()でいいだろ
0404デフォルトの名無しさん2010/05/09(日) 13:33:02
>>403
例えばCにGC_malloc()だけでどうやって具体的に実装するの？
参照されているかの判断の仕組みはどのように実装されるの？
0405デフォルトの名無しさん2010/05/09(日) 13:33:38
>>399
組み込み向けに開発した画像圧縮プログラムが思いの外性能の良い
アルゴリズムで、互換性の問題も有ってOS上でも使いたい場合とか？
用はアルゴリズムは使い回したいけども、メモリ管理は別にいらなかった
とかかなぁ。この場合、メモリ管理を手作業からライブラリ任せにしても
問題ないだろうし。
0406デフォルトの名無しさん2010/05/09(日) 13:34:37
■GCありなし混在のメリット
・新しいCにGCが欲しいという人といらないという人がいる。
・あるときはデストラクタを使ってリソース管理をしっかり行い、
　あるときはGCによって確実にメモリ開放できる。
・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。
■GCありなし混在のデメリット
・今のところ混在すると混乱する。
0407デフォルトの名無しさん2010/05/09(日) 13:34:47
>>404
CでGCが利用できるライブラリなら既にあるよ
Boehm GCとかが有名なんで、興味あるんなら見てみれば
基本的に、ポインタ「に見える」ものをポインタとして扱うはず
0408デフォルトの名無しさん2010/05/09(日) 13:35:46
>>406
GCありでデストラクタでリソース管理って何のジョークだよ
0409デフォルトの名無しさん2010/05/09(日) 13:38:49
>>407
保守的GCをＧＣとして採用するのはどうかと
0410デフォルトの名無しさん2010/05/09(日) 13:41:05
C++/CLIは失敗してると思う。
あれ以上は無理ならあきらめるべきだろうけど、
もっといい方法はないものか？

Objective-C2.0ではGCありを選択できるようになったけど、
どういう仕組みなのでしょう？
うまく行ってるのかな？
0411デフォルトの名無しさん2010/05/09(日) 13:41:51
>404 >407
そのレベルの話なら、現段階で議論できるのはポインタを工夫するかどうかレベルだな。>389ぐらいか。
GCが管理するポインタとGCが管理しないポインタを区別できるようにしとけばいいんじゃね？
0412デフォルトの名無しさん2010/05/09(日) 13:43:34
malloc()用のヒープとGC用のヒープ分ければ済む話と違うのか
アドレスの範囲で区別つくだろ
04134062010/05/09(日) 13:44:27
>>408
失礼しましたー、GCありでは確実にメモリ開放です。
0414デフォルトの名無しさん2010/05/09(日) 13:49:06
ＧＣいらない派
１、有れば便利だけど失うものが多すぎる
２、ライブラリで対応できる
３、２の場合でもプログラムコードの手直しは最小限で済む

ＧＣ必要派
１、何故かＧＣ実装の方法を唱え出す
２、何故かＧＣが有れば便利だと唱え出す
３、何故か訳の分からないことを唱え出す。

議論になってないんだよ、有れば便利だけど失うものが多すぎるので
言語仕様に持ち込むのは諦めようというＧＣ不必要派へ、対論をみせない
と駄目なんだよ。

それはＯＳの存在しない環境で、実時間予測で動き、オーバーヘッドが
極めて少ないＧＣの実装方法を提案すること。
と、同義なのでそれをくださいって事。
0415デフォルトの名無しさん2010/05/09(日) 13:50:38
>>412
だから、OSの無い環境（OSを作る言語）でも
動かしたいＣ言語置き換え言語で、ヒープとか
言い出すなよ、も＝、もー、もー
04164062010/05/09(日) 13:50:40
GCのルートに登録されていればGC対象になればいいと。
保守的じゃない、GCをCレベルで実現することは可能ですかね？
ポインタ周りをいじれるようにしながら。。。
0417デフォルトの名無しさん2010/05/09(日) 13:51:56
>>415
は？ヒープって何か特別なものだとでも思ってんの？
その場合はメモリの適当な領域を自分で区切るだけの話だ
0418デフォルトの名無しさん2010/05/09(日) 13:52:43
>>416
むずいんじゃないの
GC管理されているヒープを指しているポインタなのか
ちょうどそれっぽい値を持つただの整数なのか
区別つかんでしょ
04194062010/05/09(日) 13:55:25
>>415
malloc使わない人がいるのはわかってる。
mallocしない人はGCと混在できる言語が出来たとしても
GC使わなきゃいいだけだって。
0420デフォルトの名無しさん2010/05/09(日) 13:59:03
>>406
>・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。

突っ込もうと思ったが、これはその新言語GCに上のLLがそのまま乗っかった場合の話か
「現状」の話をすれば、LLのGC実装は千差万別だから、絵空事だよなこれ

ちなみに混在ってのは何だ、今でもCでGCライブラリ使えるわけだけど
それとは違う話なの？
0421デフォルトの名無しさん2010/05/09(日) 14:00:12
>>414
ちょっと恣意的杉。おれはC++的クラスがあるなら言語仕様にGCは必要がない派だけど
＞何故か
は必要ないだろ。
「ＧＣが有れば便利」は主張であり「失うものが多すぎる」とのトレードオフ項目だよ。
何を失うのはコンセプトとして得られるどのような便利さよりも重要であるというような議論が必要でしょう。

＞、実時間予測で動き、オーバーヘッドが極めて少ないＧＣの実装方法を提案すること。
これが重要であるというコンセンサスをとる必要がある。
まあ俺もそう思ってるんだけど。
0422デフォルトの名無しさん2010/05/09(日) 14:03:28
OS作成言語という前提があることは忘れてはならない
0423デフォルトの名無しさん2010/05/09(日) 14:04:37
拡張したポインタも素のポインタと同じように扱えるようにしとけばいいだろ。
そうしとけばGCなんてライブラリ実装で十分だし。
04244062010/05/09(日) 14:05:59
>>420

LWLの話は半分絵空ごとでございます。
でも、Objective-C、Valaあたりで実現されているのかもしれません。

Cのライブラリ言うと保守的なGCですよね。おそらく。

出来るか、出来ないかはわからないけど以下のことを考えてます。

・保守的じゃないGCを実現したい。
・構文上、GC使う、使わない両方を綺麗に書けるようにしたい。
0425デフォルトの名無しさん2010/05/09(日) 14:07:17
>>423
その拡張したポインタはどのようなコストが払われているのでしょうか。
0426デフォルトの名無しさん2010/05/09(日) 14:08:04
日本人はもっとブレストを研究・教育したほうがいいと思った。
0427デフォルトの名無しさん2010/05/09(日) 14:17:40
デストラクタはデストラクタ、ファイナライザはファイナライザで
それぞれ別のもの。
0428デフォルトの名無しさん2010/05/09(日) 14:18:07
スタックとメモリ空間だけがあって、
何番地から何番地はこれこれに使う。
という仕様にして、構造体のポインタにアドレスを入れてアクセスして
ほかのタスクとやり取りするといったような事にもC言語は使われている。
ヒープというからにはmallocなわけで、メモリ割り当てするには
それなりの実行コストが掛かる。
アドレス固定のスピードにはかなわない。

0429デフォルトの名無しさん2010/05/09(日) 14:20:06
>425
構造体にする場合はポインタのサイズ。
アラインメントを活用する方向なら抽出コスト。
0430デフォルトの名無しさん2010/05/09(日) 14:23:07
>424
厳格なGCにするとしてもポインタを工夫するだけの話だろ。グダグダ引っ張りすぎ。

構文なんてクソくらえ。newなんて（構文上は）グローバル関数でも構わないだろ。
0431デフォルトの名無しさん2010/05/09(日) 14:26:13
>>430
・生ポインタはGCの追跡性を阻害する。
・ポインタを工夫するとそれなりのコストが発生する。
ここは議論対象でしょう。
0432デフォルトの名無しさん2010/05/09(日) 14:29:06
>>391
> お互い論点の確認せずに持論しかいってないように見えるからよくわか
> らんとなってると思う。
論点は、「ＧＣを、言語仕様に取り込まなかった場合どういう不具合が発
生するか」だろ、十分明確だと思う。
持論は >>364 は「不具合が思いつかない (≒不具合はない)」に対して俺
は、「不具合はある、理由は「確保したりソースが不要になったことを確
実に知ること」ができなくなる」と書いてる。
コード示せと言うから、コード示したら「わけわからん」とか「キチガイ
レベル」とか、まあ恥ずかしくて当分でてこれないとは思うが。

とか思ってたら、前スレでしきりに LWL とか騒いでた奴か。

>>931 は、「そういえば話は通じると思う」ととりあえず理解できてる
のに >>398 で「だーよね」って馬鹿だね～。

>>398
> 失われる情報はなんだって事だよ？

「リソースが不用になった」という情報。
0433デフォルトの名無しさん2010/05/09(日) 14:36:51
>431
> ・生ポインタはGCの追跡性を阻害する。
ポインタにメタデータ突っ込めるように拡張性を持たせればいいんじゃね？>389のように

>・ポインタを工夫するとそれなりのコストが発生する。
どこにコストをかけるかがポイントかね。
参照時にコストかかるのは論外として、ポインタのコピー時のコストをどうするか。
参照先の生成・破棄時のコストは別にどうでもいいんじゃね？どうせそれ以上のコストが発生するんだし。

そういった点を含めてポインタのスマポ化が一番簡単だと思うんだけど。
0434デフォルトの名無しさん2010/05/09(日) 14:37:32
C++で実装されてるアイディアって良く出来てるよな。
問題はいろいろ出来すぎて不具合が発生しているところだと思う。
コンセプトを立ててC++から必要な機能セットだけを抽出するという作業は面白そう。
0435デフォルトの名無しさん2010/05/09(日) 14:43:29
>>434
その辺で考えて書いても一晩経てば何故か使いやすいＬＷＬの議論に
なってる（ｗ

>>432
おい、白痴。

ポインター拡張するのなら構文の変更は必要ないんだから
黙って実装しとけや。
0436デフォルトの名無しさん2010/05/09(日) 14:45:43
おれC++では生ポインタ使ってて,JavaではマークアンドスイープのＧＣ動作を期待してかいてるけど
shared_ptrを実用で使ったことない。
リーク０にしなければいけない状況だとして、循環参照が原理的に回避可能な手法ってあるの？
0437デフォルトの名無しさん2010/05/09(日) 14:46:48
循環参照する時はweak_ptrを使う
既に開放されてるかどうかがチェックできる
0438デフォルトの名無しさん2010/05/09(日) 14:47:17
あとはＣの歴史的な事情から残ってる機能で弊害が大きいもののリストアップも欲しい。
0439デフォルトの名無しさん2010/05/09(日) 14:48:03
>>437
それは循環参照すると分かっているときは有効だけど
それを見分けるにはどうすればいいの？
0440デフォルトの名無しさん2010/05/09(日) 14:48:09
文字列リテラルを非constなポインタに入れられるとか
0441デフォルトの名無しさん2010/05/09(日) 14:49:17
>>440
これが理解できてなくて一日潰したことあるなｗ
0442デフォルトの名無しさん2010/05/09(日) 14:49:34
>>439
そもそも普通は循環参照など起こさないように設計する
どうしても循環参照しないといけない時に、循環参照をする
当然その時は循環参照することは分かっている
0443デフォルトの名無しさん2010/05/09(日) 14:51:25
スマートポインタはオブジェクト指向があっての物で
オブジェクト指向なしにしたいという話とはバッティングする。

コンパイルタイムで動く型レベルプログラミングか、
マクロで解決できればいいのかなと思えど嫌われる。

言語機能に組み込むのがベストなのかどうか？
というと、使わない派がいる。

オブジェクト指向がいいのか、
コンパイルタイムプログラミングがいいのか？

どっちがいいんだ？
0444デフォルトの名無しさん2010/05/09(日) 14:51:55
>>442
循環参照を起こさない設計って具体的なノウハウあるの？
ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない？
0445デフォルトの名無しさん2010/05/09(日) 14:54:52
>>443
そんなことはないんじゃないの
C++では言語のレベルではスマートポインタを提供していないから
クラスとテンプレートを使ってそれを実装する必要があるというだけで、
言語のレベルでサポートするのなら、別にそれらは要らないと思うが
0446デフォルトの名無しさん2010/05/09(日) 14:57:36
>>444
常に循環参照が起こるかどうか考えながら設計すればいいだけじゃん？
まあ相互参照するようなクラスはまず作らないってのは基本だけど
0447デフォルトの名無しさん2010/05/09(日) 14:57:58
>>444
え？所有権のこともあやふやなんじゃ、スマポ使おうが使うまいが
C/C++でコードなんて書けないでしょうが

スマポ使わなきゃ所有権の問題が解決する？そんなわけない
スマポで楽にできるところまで面倒になるだけ
0448デフォルトの名無しさん2010/05/09(日) 15:00:14
>>447
マークアンドスイープは解決するでしょう？
おれはshared_ptrで原理的に回避する方法を思いつかないから
new/deleteで徹底する方法をつかってる。
0449デフォルトの名無しさん2010/05/09(日) 15:02:40
new/deleteで徹底できるなら
代わりにshared_ptr使えるでしょ
0450デフォルトの名無しさん2010/05/09(日) 15:05:43
むしろそんな循環参照なんて発生するか？
直接の親子関係があって、子に親を持たせるケースくらいでしか
発生しないと思うんだが
0451デフォルトの名無しさん2010/05/09(日) 15:07:20
>>449
いやnew/deleteのルールを決めることができるなら
(例えばコンストラクタ・デストラクタのみで行う。)解放は自動化することが出来る。
shared_ptrはこういうことが可能ではないと思ってるんだけど。
コードのチェック方法がシンプルになるだけでもいいんだけど。
0452デフォルトの名無しさん2010/05/09(日) 15:08:33
>>450
そんなに発生するかどうかは実用レベルでは試してないのでわかんないけど
おれは原理的に回避できるアイディアが思いついてない。
0453デフォルトの名無しさん2010/05/09(日) 15:11:02
クラスAがクラスBを生成するとする
仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
クラスB以降でクラスAを通じた循環参照は原理的に発生しない

そもそも循環参照って部品化がうまくいってない事の証拠だから
大抵設計がおかしい
0454デフォルトの名無しさん2010/05/09(日) 15:11:14
>>444
>ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
>それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない？

こういうことを書いてるってことは、何でもかんでもポインタ渡しのときは
shared_ptr使うと思ってる？
その必要は全然無いよ、少なくとも俺はそうしない
例えばcallerがポインタの所有権を持っていて、calleeはただそれを一時的に
利用する、所有権は要らない、というよくある関数でのポインタ渡しでは
素直に生ポインタを渡せばいいんだよ、というか俺はそうする

shared_ptrを渡す必要があるのは、相手も所有権を必要としているときだけだ
だから、そう書いていれば自動的に明確だろ
0455デフォルトの名無しさん2010/05/09(日) 15:12:50
>>453
＞仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
この前提は厳しすぎない？
クラスAを親、クラスBを子としたときに
子が親の状況が見れないって制限厳しすぎると思うんだけど。
0456デフォルトの名無しさん2010/05/09(日) 15:14:32
>>455
普通だろ
それを乱用している事自体、設計がなってない
当然必要な状況もあるけどな
0457デフォルトの名無しさん2010/05/09(日) 15:14:55
>>454
なるほど所有権を使わないという宣言として生ポインタを渡すのか。
勉強になりました。
0458デフォルトの名無しさん2010/05/09(日) 15:18:44
クラス図でも書けばいいんじゃない
0459デフォルトの名無しさん2010/05/09(日) 15:19:26
>>454
これ目からうろこなんだけどこういう言及してる本ってあるの？
0460デフォルトの名無しさん2010/05/09(日) 15:22:18
>>459
お前ポインターさわるな。
0461デフォルトの名無しさん2010/05/09(日) 15:22:22
そもそも関数内で使うだけなら
引数にshared_ptr使っていようが循環参照は起きない
メンバに保持しない限り
0462デフォルトの名無しさん2010/05/09(日) 15:22:48
>>460
いやお前リークしまくりだと思うわ
0463デフォルトの名無しさん2010/05/09(日) 15:24:24
今時リークしたらデバッグ実行終了後にレポート出るだろ
0464デフォルトの名無しさん2010/05/09(日) 15:24:33
>>461
使ってないことを明示するために生ポインタもらうってことなんだけど
0465デフォルトの名無しさん2010/05/09(日) 15:27:22
別に保持しない事の明示にならないと思うが
生ポでメンバに保持するかもしんないから
ダングリングポインタになるのを心配する必要があって
weak_ptrの方がよほど安心

でも、生ポ使う事が悪いとは言わないけど
全部スマポでやってらんないと思うし（コスト的な意味で）
0466デフォルトの名無しさん2010/05/09(日) 15:31:06
>>465
そこはルールだから。
ルール以上の決め事は言語仕様にでもするしかないと思うので。
0467デフォルトの名無しさん2010/05/09(日) 15:32:50
>>463
で一定条件下でしかでないリークに気づいて躍起になって原因を探すんですね。
0468デフォルトの名無しさん2010/05/09(日) 15:33:19
ルールは全員が確実に守る事が前提にあるから
あまりそれに頼ると困ったりするのよね
まあ悪いルールではないと思うけど
0469デフォルトの名無しさん2010/05/09(日) 15:34:52
それはルール違反を検出するツールで対応するしかないと思うな。
その一手法が言語仕様。
0470デフォルトの名無しさん2010/05/09(日) 15:36:14
生ポ、スマポ以外にシェアポとかウェイクポとかもあるんですか？
0471デフォルトの名無しさん2010/05/09(日) 15:37:06
今扱ってるプログラムはCOMの扱いが分かってなくてリークしまくってるわ
プロジェクトに入ってから指摘してももう遅いってんで完全に放置状態だが
どうせ起動時に確保して終了時まで使うからリークしてもいいよね、みたいな状態
0472デフォルトの名無しさん2010/05/09(日) 15:39:28
>>470
議論の本流とは外れるけど、
直ぽとか仮ぽとか近ぽとか遠ぽとか巨ぽとか
0473デフォルトの名無しさん2010/05/09(日) 15:40:10
ぬるぽ
0474デフォルトの名無しさん2010/05/09(日) 15:40:24
>>435
> ポインター拡張するのなら構文の変更は必要ないんだから
> 黙って実装しとけや。

ポインタ拡張？ どうやって？
まさか「実装は任せた」とか言うオチじゃないよな。

※ >>389 見ろなんて言われたら、笑うしかないが。
0475デフォルトの名無しさん2010/05/09(日) 15:41:29
ポインタにメタデータとか
従来通りに使おうとする際にコストかかるからな
低級言語的にはアウト
0476デフォルトの名無しさん2010/05/09(日) 15:45:27
>>454だが
関数の間口を不必要に狭めず、なるべく汎用性を上げる方針で書けば、
>>454のような帰結は自動的に出てくるはずなんだけどね

参照するだけならconstをつけるだろ、そうすると非const/const両方の
ポインタを渡せるから
同じように、所有権が不要な場合は生で渡すインタフェースにする、
そうすると元が生だろうがshared_ptrだろうが、その関数が使えるから
不要なのにshared_ptrで受けるようにしちまうと、生が渡せなくなる

勿論、これによってコードの意図が明確になるというご利益も得られるので
いいことずくめだよ
0477デフォルトの名無しさん2010/05/09(日) 15:49:46
だな
0478デフォルトの名無しさん2010/05/09(日) 15:50:04
自動的にでてくるはずの帰結なんだけどあまり流通してないのはなぜだろうね。
0479デフォルトの名無しさん2010/05/09(日) 15:56:04
>>478
>>462が生活してる現実。
0480デフォルトの名無しさん2010/05/09(日) 15:57:04
>>479
じゃあお前も防衛しとかないとダメじゃん。高みの見物気取ってる場合じゃないぞｗ
0481デフォルトの名無しさん2010/05/09(日) 16:02:40
>>480
なんでおいらが関数定義の詳細化を提案してるのか、
理解できてないようだ。

0482デフォルトの名無しさん2010/05/09(日) 16:03:32
ポインタにメタデータって型情報のポインタ持たせるだけですむのでは？
それで厳格なGCに出来るなら悪くない。
newstruct A{
int a;
}
な構造体っぽい何かなら
struct A {
StructInfo* tag;
int a;
}
struct StructInfo {
int size;
TypeInfo* members;
char* name;
}
struct TypeInfo {
enum Type { STRUCT,INT,CHAR ... }
:
:
とかなんとかってなってて厳格なGCが出来たり、
型サイズチェックできたり、
クラスに拡張したり、いろいろ有用そう。
0483デフォルトの名無しさん2010/05/09(日) 16:03:52
>>481
お前が誰か分からんわｗ
0484デフォルトの名無しさん2010/05/09(日) 16:08:41
>>483
俺は>>462がエンジニアとしてお金もらっちゃ詐欺になるレベルだと分かる。
誰か？は分からないけども。２ｃｈなんだからそれで充分。
0485デフォルトの名無しさん2010/05/09(日) 16:10:35
関数定義で抽出したら対人コミュスキル不全がでてきたｗ
0486デフォルトの名無しさん2010/05/09(日) 16:12:45
>>482
何をやりたいのかよくわからんけど、GC の問題が構造体の名前、
型やサイズ等の型情報でどうかなるわけではないことを知ってお
いたほうがいい。
0487デフォルトの名無しさん2010/05/09(日) 16:13:02
無脳が人を見下すスレ
0488デフォルトの名無しさん2010/05/09(日) 16:22:17
でもキミや俺みたいに無意味なレスするやつよりマシだけどな。
0489デフォルトの名無しさん2010/05/09(日) 16:24:32
こんなにまとまらないくらいなものまとめるくらいならC使ってるわという気持ち。
0490デフォルトの名無しさん2010/05/09(日) 16:42:17
>>483
Eulerだろ。
0491デフォルトの名無しさん2010/05/09(日) 17:21:34
>>486
では何がそろえばGCを完全にできる？
0492デフォルトの名無しさん2010/05/09(日) 17:29:51
ここを読んでみて
http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%AF%E3%83%BB%E3%82%A2%E3%83%B3%E3%83%89%E3%83%BB%E3%82%B9%E3%82%A4%E3%83%BC%E3%83%97#.E4.BF.9D.E5.AE.88.E7.9A.84.E3.81.AA.E3.82.AC.E3.83.99.E3.83.BC.E3.82.B8.E3.82.B3.E3.83.AC.E3.82.AF.E3.82.BF
0493デフォルトの名無しさん2010/05/09(日) 17:33:27
多少のコストは払ってもいいので完全なGCをCレベルで使って簡潔に
プログラムしたい。
0494デフォルトの名無しさん2010/05/09(日) 17:35:32
スタック上やオブジェクト内にある参照でないデータも、参照をあらわすデータと見なして処理を進めるから
保守的になっちゃう。
0495デフォルトの名無しさん2010/05/09(日) 17:37:03
おまえの言ってるＣレベルが分からん。
やろうと思えばC++のライブラリでも出来ると思うんだが
ここでいうC++とCレベルの違いは何？
0496デフォルトの名無しさん2010/05/09(日) 17:45:48
>>495
クラスを使うかどうかかな？
C++いらんいう人がいるので。
リファレンスカウンタ方式ではないGCも選択出来たりしたらいいのかなと。
自分はC言語のライブラリレベルでGC可能なAPIを作って、それようの
シンタックスシュガーをマクロで実現できたらいいなと考えてる。
マクロもテンプレートもコンパイルタイムプログラミングって意味で
似たようなものだから、テンプレートはありと思ってる。
0497デフォルトの名無しさん2010/05/09(日) 17:46:09
◆新言語でのリソース管理方針◆

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

※GCは手段であって上記が満たされていれば必ずしも必須ではない。
0498デフォルトの名無しさん2010/05/09(日) 17:48:51
何その言い換えｗ
0499デフォルトの名無しさん2010/05/09(日) 18:06:51
完全なマークアンドスイープはC++クラスなしなら言語側に機構を持たないと無理。
C++ライブラリとしてなら実装可能だと思ってたけど実際に実装されてるライブラリって知らないや。
何か問題あるのか？
0500デフォルトの名無しさん2010/05/09(日) 18:09:21
>>498
>>496と>>497は別人だよ

ついでに夢を語ると、
いろんな言語の拡張をCで書くわけだけどそれぞれメモリ管理方法が違って
書き方が違う。

SWIGっちうのがあって知っている人は知っていると思うのだけど
そのへんのインターフェイスを書いておくと自動的にインターフェイス部分を
作ってくれるというものなわけだ。

でも、全部出来るわけじゃないと。
その仕事をうまいことラップ出来たりしたらいいなと。
Rubyのいいところは拡張を綺麗に書けることだけど、
もっと綺麗にできたらいいなぁっと。
それでいてメモリ管理のやり方を変えても大丈夫なように出来てたらいいな
0501デフォルトの名無しさん2010/05/09(日) 18:11:47
ますます分からんお前。そもそも>>496とつながってるとは思わんし。
0502デフォルトの名無しさん2010/05/09(日) 18:12:03
>>499
わからないけど、探せばあるのかも。
今書き込んだ話も、この議論を見てて思いついたことだからなぁ。
0503デフォルトの名無しさん2010/05/09(日) 18:17:54
>>501
なにその書き換え？
って、要件って書きかえたと思って。

GCのライブラリ探してきたよ。

http://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%A5%E9%A5%A4%A5%D6%A5%E9%A5%EA%B7%CF%2FC%2B%2B#Memory_GC
0504デフォルトの名無しさん2010/05/09(日) 18:33:23
実装の話は後でいいよ
0505デフォルトの名無しさん2010/05/09(日) 18:37:21
実装可能性の判断は必要だよ
0506デフォルトの名無しさん2010/05/09(日) 18:38:49
まあそうだな。じゃあ可能ってことで。
0507デフォルトの名無しさん2010/05/09(日) 18:41:37
じゃあおまえのレスの正当性を判断しようか
0508デフォルトの名無しさん2010/05/09(日) 18:52:08
>>491
何を持って「完全」と言うのかによるけど、shared_ptr ぐらいで我慢する
なら C++ のテンプレートレベルでいいし、きちんと管理したいのであれば
言語のサポートがないとどうにもならないと思う。
0509デフォルトの名無しさん2010/05/09(日) 18:57:38
ポインタにタグを付けなきゃいかん、となると、OSどころか（というか、OSよりも）
ハードウェアでどうにかしないとだよな。
0510デフォルトの名無しさん2010/05/09(日) 18:58:54
また適当な話になってまいりました。
0511デフォルトの名無しさん2010/05/09(日) 19:09:41
>>508
きちんと管理する場合に最小限の言語仕様は何だと思います？

0512デフォルトの名無しさん2010/05/09(日) 19:39:33
・利用されなくなったリソースの検出
・検出した時の処理の登録
・処理を明示的に登録されないかった場合のデフォルト処理
0513デフォルトの名無しさん2010/05/09(日) 20:00:35
話を変えて、関数はデフォルトでconst関数と言うことにして、
const関数内から他の関数を呼び出せるのはconst関数のみ。
という事にして、制限をきつく、きつくデフォルトで決め込んでいくのは
どうだろうか？インターネット標準の、デフォルトは安全に振るを哲学に
するわけだ。

>>173を拡張して

関数戻り値　関数名
　　　　　　　Attributes＝関数属性，　
　　　　　　　Parameter(),　←const リファレンスがデフォルト。
　　　　　　　Source(),　　　←値渡しがデフォルト
　　　　　　　Result(),　　　←リファレンス
　　　　　　　Exception(); try文の糖衣構文でcatchするオブジェクトを指定できる

で行きたいと思う。
※関数属性；const関数、pure関数、General関数
const関数の中で使えるのは定数値とブロック変数とconst修飾された関数のみ。
言い換えると、何時実行しても、同じ引数を与えれば、同じ答えが返ってくることが
保証されている関数。

pure関数の中で使えるのは定数値とブロック変数、グローバル変数のリードは許可されるが、
　　操作は出来ない。呼び出せる関数はconst修飾された関数,pure関数のみ。
言い換えると、一つのスコープ内で何度呼び出しても、同じ引数を与えているかぎり、
同じ答えが返ってくることが保証されている関数。

General関数は普通に使える。
0514デフォルトの名無しさん2010/05/09(日) 20:04:13
利用されなくなったリソースを検出したい時、
GCを使うと受動的にしかできない。
能動的に開放しようとしても、その時点で他にそれを参照する
リソースがあるかもしれないので開放できない。
開放されたかどうか分かるのはGCが起動した後。
つまりGCに任せると能動的開放はできない。

GC管轄外のリソースならこの限りではない。
0515デフォルトの名無しさん2010/05/09(日) 20:06:05
何が言いたいのか不明
0516デフォルトの名無しさん2010/05/09(日) 20:07:41
脳内妄想をたれ流すスレ
0517デフォルトの名無しさん2010/05/09(日) 20:08:57
------ここまで適当に読まなかった-------
GC派とそれ以外でスレを分けたらいいと思う
0518デフォルトの名無しさん2010/05/09(日) 20:29:26
GARNET CROWと巨人対広島で分ければいいじゃない
0519デフォルトの名無しさん2010/05/09(日) 20:30:30
>>473
ｶﾞｯ
0520デフォルトの名無しさん2010/05/09(日) 20:57:07
C++とポインタとGCの勉強会終わった？
0521デフォルトの名無しさん2010/05/09(日) 21:09:09
ノイズだらけでスレの意味が全くない
にちゃんのけいじばんのつかいかたをがくしゅうしよう！
0522デフォルトの名無しさん2010/05/09(日) 21:11:09
>>521
１行目へのレスが２行目の文なんだよな？
自己完結してる。
0523デフォルトの名無しさん2010/05/09(日) 21:30:31
>482
GCやるのならば型情報とオブジェクトの情報、参照元の情報がそれぞれ必要。
それぞれの情報を誰が管理するのかという話もあるけど。
（ポインタが管理するのか、GCが管理するのか、システムが管理するのか）

>497
ムリ言うなよ。所有者が始末するのが前提だろ。後始末しなくて良いわけじゃない。

>513
例外必須の言語が低水準とは思えんわ。機能も無駄にリッチすぎ。
そんなのよりかEiffelみたいな契約による設計の方が100倍マシだろ。

あと、constは制限緩すぎじゃね？効率も良くないし。
むしろClojureみたいに基本は変更不可・必要に応じて書き込みチャネルを用意した方がマシだろ。
将来的にチャネルを多機能化（トランザクション対応とか）できるし。
0524デフォルトの名無しさん2010/05/09(日) 21:32:22
>>523
> ムリ言うなよ。所有者が始末するのが前提だろ。後始末しなくて良いわけじゃない。

「明示的に」って書いているけど？
0525デフォルトの名無しさん2010/05/09(日) 21:44:02
>524
そうするとGC必須にならない？オブジェクトが所有するリソースは明示的に解放しないとダメだろ。
0526デフォルトの名無しさん2010/05/09(日) 21:48:33
>>525
「そうするとGC必須にならない？（GCが無ければ）オブジェクトが所有するリソースは明示的に解放しないとダメだろ。 」
って言いたいの？
0527デフォルトの名無しさん2010/05/09(日) 21:49:08
GC言ってる奴は回線切って一通り実装して動かしてからこい
0528デフォルトの名無しさん2010/05/09(日) 22:06:48
このスレはMultics つまりUnixを再現するための布石なんだよ!
0529デフォルトの名無しさん2010/05/09(日) 22:07:55
GC欲しがるのは私はメモリ管理もできない無能ですと言ってるのと同じ
0530デフォルトの名無しさん2010/05/09(日) 22:11:38
>>527-529
0531デフォルトの名無しさん2010/05/09(日) 22:11:57
>>528
言語だからどっちかっつーとPL/Iじゃね？
0532デフォルトの名無しさん2010/05/09(日) 22:17:40
神の作ったgoの仕様を100回見てこいよｗ
ほとんど全てがあるぞ。gc必須以外な
0533デフォルトの名無しさん2010/05/09(日) 22:23:11
C++の代わりは既にいくらでも存在する。このスレで議論すべきはC言語の代替である。
次スレからはC++を除外、もしくはスレを分けよう。
そうすれば低水準言語にOOPや例外を、などとのたまうアフォ連中もいなくなるだろう。
0534デフォルトの名無しさん2010/05/09(日) 22:25:32
低水準言語にOOPや例外はいらない、などとのたまうアフォを避けるために
わざわざC++を入れたんだろ。
0535デフォルトの名無しさん2010/05/09(日) 22:25:54
まだアホがいるのか
0536デフォルトの名無しさん2010/05/09(日) 22:28:33
まぁまぁ。
GCの話が嫌なら、GC以外の話すればいいっしょ。
0537デフォルトの名無しさん2010/05/09(日) 22:40:13
>534
例外やOOPを実装するための機能なら議論しても良いが、例外やOOPそのものを議論するのはアホ過ぎる。
何でそんなに汎用性の無い機能を今の段階で議論するんだよ。

それよりもマクロとルーチンの話をしようぜ。名前の話でも良いけどさ

>532
golangにマクロってあったっけ？
あとサブルーチン以外のルーチンとか
0538デフォルトの名無しさん2010/05/09(日) 22:46:01
例外やOOPの議論がアホなら、マクロとルーチンの話もアホだろｗ
ドアホｗ
0539デフォルトの名無しさん2010/05/09(日) 22:46:52
>>537
> あとサブルーチン以外のルーチンとか
その名も五郎ちゃんとかゴルーチンとかいうのがあるよ
0540デフォルトの名無しさん2010/05/09(日) 22:47:30
神はmacroなんていらないって判断なんだよ
クロージャは作れるぜ

てか、Windowsプログラマは低レベルなんて縁がないんだから
大人しくC#でも使ってなさいってこったな
0541デフォルトの名無しさん2010/05/09(日) 22:47:45
じゃあ、マクロの話しよう。
0542デフォルトの名無しさん2010/05/09(日) 22:53:19
マクロなんてお前にゃどうせ使いこなせねえだろ
0543デフォルトの名無しさん2010/05/09(日) 22:54:42
C言語にあのマクロがなかったら、
とたんにクソ言語の1つになるんだぜ
0544デフォルトの名無しさん2010/05/09(日) 22:55:14
>>542
マクロなんてそんなに怖がるほどのものじゃないよｗ
0545デフォルトの名無しさん2010/05/09(日) 23:00:07
俺はlispもOKだから別にって感じだが
Cのマクロは言語仕様じゃねえし
constとinlineで大半が不要だし
0546デフォルトの名無しさん2010/05/09(日) 23:01:46
constとマクロの何が関係あるんだ
templateの間違いか？
0547デフォルトの名無しさん2010/05/09(日) 23:03:19
>>546
こういうの↓を言ってるんだろ。たぶん。

#define VALUE 8
05485462010/05/09(日) 23:03:38
ああ、定数#defineか、ごめん理解した

CのマクロはLispよりずっと貧弱だが、#ifdefに限らずマクロを必要とする物は
沢山あるでしょ
0549デフォルトの名無しさん2010/05/09(日) 23:06:34
構文いじれるマクロなんて
オナニー用だからな
0550デフォルトの名無しさん2010/05/09(日) 23:07:03
Cには遅延評価やcall-by-nameは存在しないので
それっぽい（あくまで「ぽい」）ことを実現するのにマクロを使うこともある
要は式をそのまま渡したければマクロしかない

文字列化マクロとかトークンペーストマクロみたいなのも、マクロじゃないと
出来ないよ
0551デフォルトの名無しさん2010/05/09(日) 23:11:08
条件コンパイルもコンパイル時に値を渡せれたら問題ない
0552デフォルトの名無しさん2010/05/09(日) 23:20:02
マクロは何よりも「引数を評価しない関数」としての機能が欲しいな。
これ自体は遅延評価でも引数を評価しない関数そのもの（Lispに昔あったそうな）でもいいけど、
この機能があれば制御フローなんかも実装できるようになる。

あとは名前関連で安全な仕組みもほしい。
自分で長たらしい妙な名前を付けるのは面倒だから止めたいなぁ。
0553デフォルトの名無しさん2010/05/09(日) 23:22:40
> 引数を評価しない関数そのもの
これがcall by nameでしょう
俺の知る限りではLispは正格言語であって、call by nameしたけりゃ
マクロだよ
だからLispのspecial formはマクロじゃないと書けない

call by nameで有名な古典的な例はAlgol60らしいんだけど
俺触ったこと無いから知らないｗ
0554デフォルトの名無しさん2010/05/09(日) 23:32:35
Cのマクロで違う言語を作ろうとすると破綻するが(例boost)、
LISPでは破綻しない。
んなぜか
0555デフォルトの名無しさん2010/05/09(日) 23:38:20
lispはマクロと普通の関数の違いが少ないからな
どうせ同じデータ扱うだけだし
その分人間には読みにくい
0556デフォルトの名無しさん2010/05/09(日) 23:39:32
構文木を認識できて、その言語自身と同じ（異質でない）構文で構文木を
操作できるなら、Lispマクロと同等に強力と言えるんじゃないかな
0557デフォルトの名無しさん2010/05/09(日) 23:41:41
それ簡単に言うがlispの用に簡単には行かないな
あいつはデータもマクロも関数も全部First classのlistだからこそ美しい
0558デフォルトの名無しさん2010/05/09(日) 23:42:12
>>554
お前がCを知らないから
お前がboostを知らないから
お前がLISPを知らないから

の全部。
0559デフォルトの名無しさん2010/05/09(日) 23:43:50
LISPでOCamlを作ろうとすると破綻するが
.NETでは破綻しない。
0560デフォルトの名無しさん2010/05/09(日) 23:46:49
>>557
それは全く同意なんだけどね…

BooとかいうPython風のCLR言語は、非Lisp系だけどメタプログラミングできるらしい
使ったこと無いから、Lisp並かどうかは知らないけど
http://www.infoq.com/jp/articles/dsl-on-the-clr
ここに例載ってる

Scalaは、いわゆるマクロじゃないけど、ルーズな構文と、演算子多重定義や
ブロックのおかげで、「構文っぽく」見えるものを構築できるようになってるね
0561デフォルトの名無しさん2010/05/10(月) 00:05:36
DSLは。。。どんだけドメインつくって言語作るんだよって感じで
いずれ見捨てられるか収束する技術だねえ

てか、いずれにしろ高階な言語でないと高度なマクロはおいしくないし。
個人的には低レベルな言語から動き回れるポインタもなくしたいところだね
0562デフォルトの名無しさん2010/05/10(月) 00:07:07
なんかコンセプトからはちゃめちゃだな
0563デフォルトの名無しさん2010/05/10(月) 00:09:08
いあ、組み込み屋だから低レベルはかなりやってるが
動き回れるポインタをなくして配列の範囲チェックはあってもいい
golangのsliceはunsafeで任意のアドレスを割り当てることが出来るから
そういうのと最適化で効率は十分取れると思うんだよな
0564デフォルトの名無しさん2010/05/10(月) 00:14:05
>>563
goってそんなsliceあるんだ
それは便利だなー
0565デフォルトの名無しさん2010/05/10(月) 00:15:10
裏技的な使い方だしvolatileじゃないからI/Oには不向きだけどね
0566デフォルトの名無しさん2010/05/10(月) 00:18:46
もうD--を考えてみてはどうか。
Dはここで議論されている新言語にしては機能過多なので、
高級機能はけずるかたちで。
0567デフォルトの名無しさん2010/05/10(月) 00:19:28
>>565
まあ裏技とか低水準なことをさておいても、
そういう普通に欲しいものが無い言語多いんだよねー

Cで配列の部分を参照するためにポインタを使うのはよくあるユースケースだけど
Javaとかだと配列全部とレンジ情報を引き回すしかないし
Pythonにはスライスあるけどコピーになるから
0568デフォルトの名無しさん2010/05/10(月) 00:20:46
組み込みではどうせメモリのほとんどは最初に確保するか静的に確保するから
解放にからむメモリリークはあんまないけど
オーバーランとかに絡むエラーの方がとりにくいんよね
単に固まるだけとかで情報取れないこと多いし。
だからバッファサイズがわかるとかオーバーをチェックする仕組みの方がありがたい
0569デフォルトの名無しさん2010/05/10(月) 00:23:15
>>567
sliceは結局struct { void * ptr; int count; int max; } って感じの
組み込みデータ型だからレンジ情報は引き回す形になって
オーバーヘッド0って訳にはいかないけど
最適化次第とトレードオフかなと。
0570デフォルトの名無しさん2010/05/10(月) 00:25:01
>>566
おいらはEmbedded Go Langって感じのが欲しいｗ
0571デフォルトの名無しさん2010/05/10(月) 00:25:11
>>360
ポインタというか参照型は重要。
Javaのオブジェクトはみんな参照型。
新言語でもそういう条件をつけてメモリ効率をあげてみてはどうだろう。
0572デフォルトの名無しさん2010/05/10(月) 00:26:54
>>363
> 既存のGCの問題点
>
> ･利用形態を問わず管理する人(メモリマネージャもどき)が絶対に必要
> ･効率優先である程度まとめてGC処理を走らせるためCPU時間を占有する

JavaではそのためにSoftReferenceってやつがあるんだけど。
メモリ節約のテクニックやパフォーマンスチューニングのテクニックはJavaにもちゃんとあるんで。
0573デフォルトの名無しさん2010/05/10(月) 00:28:13
>>367
もっとパフォーマンスが堕ちるからやめてくれ
0574デフォルトの名無しさん2010/05/10(月) 00:29:04
>>367はネタでしょｗ
笑えるかどうかはさておき
0575デフォルトの名無しさん2010/05/10(月) 00:30:50
>>375
ついでに参照型と値型の違いも禁止するのはどうだろう。
intやdoubleなどの基本データ型はすべて値型で
それ以外の構造体、配列、文字列、リスト構造などはすべて参照型に。
そしてメソッドの引数に渡すときは参照渡しではなく参照をコピーして渡す
ということで。

これでメソッドに引数に&や*を付ける必要がいっさいなくなり、
ソースコードも読みやすくなる。
0576デフォルトの名無しさん2010/05/10(月) 00:33:29
それ何てJava
0577デフォルトの名無しさん2010/05/10(月) 00:35:05
>>392-393
そんなマゾいことしないでデフォルトでGCありにすればいい。

どうせならdeleteが必要なnew、ngcnewでも作るべき。
そしてこのngcnewは容易に使えないよう、例外的使用方法とする。
0578デフォルトの名無しさん2010/05/10(月) 00:38:52
またC++/GC/ポインタの勉強会になりそうだから傍観するわｗ
0579デフォルトの名無しさん2010/05/10(月) 00:39:59
黙ってしてればいいだろ。宣言なんていらんよ。
0580デフォルトの名無しさん2010/05/10(月) 00:40:59
>>438
scanf()
getchar()
string
0581デフォルトの名無しさん2010/05/10(月) 00:43:01
>>579
GCやコンパイラの知識くらい言語設計するなら知ってるはずだろ
今更こんな話出てもつまらんって話だよ
MSのセンスねえ拡張に毒された話もつまらんし
0582デフォルトの名無しさん2010/05/10(月) 00:44:11
傍観するんじゃなかったの？
0583デフォルトの名無しさん2010/05/10(月) 00:44:11
Booも、オフサイドルール使うのかぁ。
力ありあまってるのかなぁ？
オフサイドルールって簡単に実装できるんだろうか？
0584デフォルトの名無しさん2010/05/10(月) 00:45:11
>>582
あい。黙りますｗ
0585デフォルトの名無しさん2010/05/10(月) 00:48:02
勉強会はいいが半日たたずにループはきつい。
0586デフォルトの名無しさん2010/05/10(月) 00:50:42
勉強会になるだけマシ。
普段はお互い自分も理解してない単語の羅列が書き込まれてるだけだし。
0587デフォルトの名無しさん2010/05/10(月) 00:53:19
>>583
難しく考えすぎだと思う

字句解析の時、インデントが同じレベルの部分を認識して
前後にブロック部分を表すトークンをはさむだけ
後はふつうの言語と同じ具合に構文解析できる
0588デフォルトの名無しさん2010/05/10(月) 00:54:57
S式をアルゴル風な式に置き換えればいい。
Listじゃなくて演算子が式と式を結ぶ構文木を扱えばいい。
Consにタグが付いただけだからそんな複雑じゃなくてすむ。
コンパイルタイムではJavaScriptっぽい言語で式をいじればいいだけさ。
0589デフォルトの名無しさん2010/05/10(月) 00:56:23
何言いたいんだ
0590デフォルトの名無しさん2010/05/10(月) 00:56:55
>>583
難しく考えてないんですけど。短いソースでお願いします。
0591デフォルトの名無しさん2010/05/10(月) 00:58:04
新言語では、ソース中でのタブ文字の使用を禁止したい。
あるいは、ソース中のタブ幅を例えば４文字に固定したい。
0592デフォルトの名無しさん2010/05/10(月) 01:07:12
ループしてないようでよかったぜｗ
>>588
tcl乙
0593デフォルトの名無しさん2010/05/10(月) 01:12:36
知ってる単語自慢大会
0594デフォルトの名無しさん2010/05/10(月) 01:16:58
新言語に関係があれば、ループでも、知ってる単語自慢大会でも、いいよ。

興味がなければ、その流れに参加しなければいいだけだから。
0595デフォルトの名無しさん2010/05/10(月) 01:19:58
>>593
知らない単語にめげてる人:1
0596デフォルトの名無しさん2010/05/10(月) 01:20:27
tclはつかえない。理由は忘れた
0597デフォルトの名無しさん2010/05/10(月) 01:21:23
>>588
S式と違って、アルゴル風な式は、見た目と構文木の構造が一致しないから
コンピューターにとっては複雑じゃなくても、人間にとっては扱うのが難しい。
0598デフォルトの名無しさん2010/05/10(月) 01:21:50
今のTclって関数がファーストクラスになってるんだっけ
そうじゃなけりゃ
いまどきファーストクラスの関数を持たないLLの人って…
って感じ
0599デフォルトの名無しさん2010/05/10(月) 01:22:14
>>578
C++/GC/ポインタの話についてこれない人:1
0600デフォルトの名無しさん2010/05/10(月) 01:23:00
どこが低級言語の話だかよくわからない
0601デフォルトの名無しさん2010/05/10(月) 01:23:56
>>600
初心者にはすぐにはわからないかも。
頑張れ。
0602デフォルトの名無しさん2010/05/10(月) 01:24:54
ひどいいいぐさだな。tcl/tkな人。すいません。
tcl/tkは検討したのだけど、命令からパラメータ数が決まるとかいう
点がいまいちだと思ったんだったと思う。
0603デフォルトの名無しさん2010/05/10(月) 01:25:01
>>599
C++は嫌いだが、lispとかSTの実装経験くらいなら学生の頃やったぜｗ
copy GCとリファカウントだけどなｗ
0604デフォルトの名無しさん2010/05/10(月) 01:26:55
>>601
お前わかってないだろｗ
0605デフォルトの名無しさん2010/05/10(月) 01:28:14
マクロだかマグロだかの話は低級高級関係ないお！
どんなに高級複雑なマグロでもプリプロセス／コンパイル時の話だからな！
0606デフォルトの名無しさん2010/05/10(月) 01:29:08
多分、>>601がトリップ付けるだけで解決する
0607デフォルトの名無しさん2010/05/10(月) 01:29:48
このスレ、id出して欲しいなｗ
0608デフォルトの名無しさん2010/05/10(月) 01:30:57
id出さなくても/ｗ$/で抽出できる。
0609デフォルトの名無しさん2010/05/10(月) 01:31:03
オンデマンドに強制ID付きでスレ立てできるようになるといいな
別に全スレでとは言わないから
0610デフォルトの名無しさん2010/05/10(月) 01:32:17
>>588
おお、それじゃ、俺は理解できてるから人間をこえているのか？やった！
ってそんなことはないって。
BNFベースにするから構文木が分かりにくくなるので
演算子で繋がってるだけのものって理解すれば、そんな難しくないよ。
0611デフォルトの名無しさん2010/05/10(月) 01:33:17
>>608
ありがとｗ
603だが604とは別人だよw
全角半角でいれといた
0612デフォルトの名無しさん2010/05/10(月) 01:44:54
>>605
そんなことはない！
マクロは高級言語では他の機能で代替可能で分かりやすいから必要なくなる。
だけど、低級言語では機能が少なかったりスピード求められたりするから
明るく輝くんだ！あの夜空に輝く星々のように！
0613デフォルトの名無しさん2010/05/10(月) 02:27:40
だからマクロはユーザーカスタマイズ可能なコンパイラだって。
0614デフォルトの名無しさん2010/05/10(月) 02:39:32
構文いじるのは高階な関数系の言語にしとけって
Algol系では不要
FOREVER { }
とか書いてあったら恥ずかしいだろうが。
0615デフォルトの名無しさん2010/05/10(月) 02:40:52
ユーザーカスタムって大抵可読性下がるよね
0616デフォルトの名無しさん2010/05/10(月) 03:01:08
inlineもconstもない頃に仕方なく出来たcpp
昔はいいアイデアだったが今は弊害の方が大きいという認識だな
KenTompsonもgolangには全く入れてないし
0617デフォルトの名無しさん2010/05/10(月) 03:04:22
とりあえず普段Cのマクロで「何を実現しているか」をリストアップしてはどうか？
本当にプリプロセスじゃなきゃできないことなのか、実は言語の一構文として組み込める処理なのか。
今のマクロはいわば「マクロ言語」とでも呼ぶべき独自路線と大域スコープで色々と問題を含む。
少なくとも言語本体と同じ構文でプリプロセスを書けるようにしたい。
inline constよりも確実で厳密な、完全なるインライン定数を定義するための修飾とかね。
0618デフォルトの名無しさん2010/05/10(月) 03:04:24
神の名前をTypoしちまった
Kenneth Lane Thompson様すんません
0619デフォルトの名無しさん2010/05/10(月) 03:10:33
constで定義した定数が確実で厳密でないってなに
cppは昔は良かったんだよ。コンパイラをシンプルに出来たからな。
条件コンパイルは今でも有用だが、代替手段は普通にあるし。
0620デフォルトの名無しさん2010/05/10(月) 03:42:29
最初はenumもなかったな
こっちの方が定数定義に向いてるんじゃね
0621デフォルトの名無しさん2010/05/10(月) 04:23:52
#if _foo_, #if defined(_foo_), #if !defined(_foo_), #ifdef _foo_, #ifndef _foo_, #else, #elif _foo_, #endif
条件コンパイル

#define _foo_ [_bar_], #undef _foo_
置換(関数マクロ含む)、条件の空定義

#line decimal-number ["string"]
行制御、詳しくは知らない

#pragma _foo_
独自拡張とか

#error string
強制エラー

#
空の指令

_foo_ ## _bar_
トークン結合

# _foo_
文字列化

良く使うのが、条件コンパイル、置換とトークン結合
スコープ問題はfoo_nameのようにfoo_を付けて衝突を軽減している
整数定数はenum、テーブルはconst、置換(関数マクロね)や実数定数はdefineとそれぞれ使い分けている
0622デフォルトの名無しさん2010/05/10(月) 14:34:43
まあ、おおむねC++やDで対応されてるかなあ、という辺りか
0623デフォルトの名無しさん2010/05/10(月) 14:38:38
Cがなぜあれだけの機能しかないのかを分かっていないやつが多すぎ。
0624デフォルトの名無しさん2010/05/10(月) 17:42:15
プリプロセッサのへぼさも理由があるしな
0625デフォルトの名無しさん2010/05/10(月) 19:29:53
昔の理由なんて今通用するとは思えない
0626デフォルトの名無しさん2010/05/10(月) 20:24:20
CPUのアーキテクチャもソフト工学も30年前から細かいとこしか進歩してないんだよ。ボク。
0627デフォルトの名無しさん2010/05/10(月) 20:51:47
じゃあ説明してくれ
0628デフォルトの名無しさん2010/05/10(月) 23:27:09
知ったかぶり大会に説明など不要
0629デフォルトの名無しさん2010/05/11(火) 00:08:08
>>621
これってCのプリプロセッサディレクティブ？
0630デフォルトの名無しさん2010/05/11(火) 01:27:10
>>455
フィールドやメソッドをprivateにすれば見えなくて当然。
protecedじゃないんだから。
0631デフォルトの名無しさん2010/05/11(火) 01:32:49
またアホがきた
0632デフォルトの名無しさん2010/05/11(火) 09:45:40
Cのプリプロセッサレベルで残すものは、__FILE__,#lineくらいでいいんじゃない？
ってのがD言語。それ以外は言語機能に組み込む。
LISPのマクロ言っているのは、C++やD等のテンプレートの先を言ってる。
何が何だか分からないのが問題なのでマクロでも何が何だか
分かるマクロで汚くなければ、問題はないと思うのです。
0633デフォルトの名無しさん2010/05/11(火) 09:48:07
下降型の演算子順位法ですら難しい言われるのに、
短い例も出せないオフサイドルールはS式の代わりにはできそうにない。


0634デフォルトの名無しさん2010/05/11(火) 17:29:53
構文いじって綺麗なわけない
コードがどう展開されるかの予想が付くのが
Cの利点というか低レベル言語に要求されることの一つだと思うぜ
そういう意味でC++はあんま低レベルとはいえん
0635デフォルトの名無しさん2010/05/11(火) 17:34:21
いい加減もうCでいいじゃん
マクロフル活用でオサレっぽくかけるようにすりゃ十分だろ？
0636デフォルトの名無しさん2010/05/11(火) 17:37:44
いにしえのratforみたいだな
0637デフォルトの名無しさん2010/05/11(火) 17:39:20
最初のC++とかObjective Cとかもだね
0638デフォルトの名無しさん2010/05/11(火) 18:18:56
いいかげん既存の言語にラッパークラスをライブラリとして自作して追加するだけでいいんじゃねって
思えてきた
0639デフォルトの名無しさん2010/05/11(火) 19:17:19
さて、ここにいるのは何割プログラマやってる人？ＳＥでも。オレは会社でコボルいじってるけど
0640デフォルトの名無しさん2010/05/11(火) 19:53:23
__FILE__, __LINE__ なんて、
コールスタックをダンプする機能があれば不要
0641デフォルトの名無しさん2010/05/11(火) 21:05:27
ネイティブでコールスタックダンプとか、Ｄ言語でやって楽しかった。
GDBでオッケーとかいう話もあった。
0642デフォルトの名無しさん2010/05/11(火) 21:06:48
GoLangってネイティブで厳格なＧＣついててっていいかんじっすね。
あとはマクロを使えれば、、、。
0643デフォルトの名無しさん2010/05/11(火) 22:09:51
LISP風マクロを追加する試みって既に昔からあるよね
結局LISPのラッパーな感じだけど
0644デフォルトの名無しさん2010/05/11(火) 22:12:03
だからGCはいらないと何度言ったら。
CでもGCできるんだからさ、各自で勝手にやればいいんだよ。
0645デフォルトの名無しさん2010/05/11(火) 22:12:03
パズルみたいになるマクロいらない。
0646デフォルトの名無しさん2010/05/11(火) 22:23:46
m4とかな
0647デフォルトの名無しさん2010/05/11(火) 22:36:10
JavaPPって使ってた人いる？
0648デフォルトの名無しさん2010/05/11(火) 23:04:52
Cプリプロセッサはマクロ中でマクロ定義できたらよかったのに
ちょっと中途半端なだけなんだよ
0649デフォルトの名無しさん2010/05/11(火) 23:08:31
禿同
0650デフォルトの名無しさん2010/05/11(火) 23:31:33
じゃあcalleeの中でcallerのローカル変数を定義できたらよいと思うか？
そんなものはレキシカルスコープが崩壊するだけだろ
0651デフォルトの名無しさん2010/05/11(火) 23:46:40
プリプロセッサでは #line こそ必要不可欠
0652デフォルトの名無しさん2010/05/11(火) 23:55:45
おJava女どれみ　プログラマー猿　カウボーイ・デバッグ　JAVAン
人月を探して　超電磁ロボ　コンパイラーVC++　パケットモンスター
機動戦士GNUDAM　エリア8KB　新言語Javaンゲリオン　あらいぐまオラクル
千と千尋のバグ隠し　あずまんがI/O　ゲットデバッカーズ　デバッグNo.1
Bugって仕様　人月姫　エスイー(SE)魔美　あしたの仕様ー　外注遣いに大切なこと
ガンダムsed　ガンダムOO（オブジェクト指向）　ランダムSEED
ガンパレード・デスマーチ ～新たなる行軍歌～　アルプスの少女High-C
Cosmic DataBase COMMITさん☆　ARMs　ハックしよう大魔王
魁！プロパティ高校　超時空要塞マクロ　湾岸MID$RIGHT$
ルパンSun製　グレートマシン語　逆襲のchar　ウルトラマンＺ８０
バグひな　戦え!超OS生命体TRONスフォーマー　gccさくら
キャプテンmalloc　金色のハッシュ！　おねがいt_char　typoしちゃうぞ
フォートラーン戦記　Excelサーガ　getcharロボ　焼きたて！！ＪＡＶＡん
データセンターあらし　忍者バグトリ君　ときめきメモリ枯渇　修羅のMON
ゴルゴ１Ｂ（バイト）　Rubyポップは笑わない　ELFを狩るものたち　迷宮組込
0653デフォルトの名無しさん2010/05/11(火) 23:56:57
>>652
なんか笑った
0654デフォルトの名無しさん2010/05/12(水) 00:08:37
新言語ではプリプロセッサでもその言語の機能を使えるようにしたい
0655デフォルトの名無しさん2010/05/12(水) 00:26:26
>エリア8KB 千と千尋のバグ隠し typoしちゃうぞ getcharロボ　データセンターあらし　
すげー笑った
ありがとう
0656デフォルトの名無しさん2010/05/12(水) 00:35:12
>>654
sizeof辺りの定数返すやつは欲しいなあ
あと、型が定義されているかとか
0657デフォルトの名無しさん2010/05/12(水) 00:39:21
>>642
golangはC的なMacroは特にいらないよ
条件コンパイルはちょいつらいが
Refrectionもあるしな
Cの代替は無理だがC++だな
0658デフォルトの名無しさん2010/05/12(水) 00:52:09
オフサイドルールなパーサ作ったヨット
<script>
Array.prototype.toString = function() { return "[" + this.join(",") + "]" }
function run() {
var ls = (document.getElementById("in").value+"\n").split(/\n/)
var ts = [], ns = [-1,-1,0]
for(var i = 0; i < ls.length; i++) {
var m = ls[i].match(/(^\s*)(.*)/), n = m[1].length
if (n > ns[ns.length-1]) ts.push("("),ns.push(n)
else while (n < ns[ns.length - 1] && n <= ns[ns.length - 2])
ns.pop(),ts.push(")")
if (m[2].length!=0) ts = ts.concat(m[2].split(/\s/))
}
alert(ts)
}
</script>
<textarea rows="15" cols="80" id="in">
a
b c d e
a
b
c d e
d
</textarea>
<input type="button" onclick="run()"/>
0659デフォルトの名無しさん2010/05/12(水) 00:53:22
あ、ネストが、、、。
<script>
Array.prototype.toString = function() { return "[" + this.join(",") + "]" }
function run() {
　var ls = (document.getElementById("in").value+"\n").split(/\n/)
　var ts = [], ns = [-1,-1,0]
　for(var i = 0; i < ls.length; i++) {
　　var m = ls[i].match(/(^\s*)(.*)/), n = m[1].length
　　if (n > ns[ns.length-1]) ts.push("("),ns.push(n)
　　else while (n < ns[ns.length - 1] && n <= ns[ns.length - 2])
　　　ns.pop(),ts.push(")")
　　if (m[2].length!=0) ts = ts.concat(m[2].split(/\s/))
　}
　alert(ts)
}
</script>
<textarea rows="15" cols="80" id="in">
　a
　　b c d e
a
　b
　　c d e
　d
</textarea>
<input type="button" onclick="run()"/>
0660デフォルトの名無しさん2010/05/12(水) 00:56:03
ということで、敵に塩を送ってしまった。
しかも、パーサじゃなくてレキサだわな
0661デフォルトの名無しさん2010/05/12(水) 02:02:11
>>652
くだらね
キモオタガンヲタは死ね
0662デフォルトの名無しさん2010/05/12(水) 02:29:03
中にはキモヲタ関係ないのも入っているが
まさしくどうでも良い
0663デフォルトの名無しさん2010/05/12(水) 02:50:37
>>660
オフサイドルールよく知らないんだけど
a
　　b
　c
　　　d
　e
　　f
g

で
(a ((b) c ((d)) e (f)) g)
みたいにはならないのかな
0664デフォルトの名無しさん2010/05/12(水) 06:00:47
>>658
それがどうした？としか
0665デフォルトの名無しさん2010/05/12(水) 07:19:38
window
　caption "hoge"
　pos center center
　size 200 150
　child
　　pos 0 50
　　size 100 50
　　horiz
　　　button "apply"
　　　　id 1
default
　　　　tabstop
　　　button "eval"
　　　　id 2
　　　　tabstop
　child
　　pos 100 50
　　size 100 50
　　horiz
　　　button "ok"
　　　　id 3
　　　　tabstop
　　　button "cancel"
　　　　id 4
　　　　tabstop
というようなリソース管理に使えるかな、と思った
インデント構造でまっさきに思いつきそうなやつだけど
0666デフォルトの名無しさん2010/05/12(水) 09:02:10
>>665
改行を許さない糞言語は不要
0667デフォルトの名無しさん2010/05/12(水) 09:05:10
行末尾に\でもつければいいんだろ
0668デフォルトの名無しさん2010/05/12(水) 11:09:38
>>665
YAML？
0669デフォルトの名無しさん2010/05/12(水) 11:16:08
>>664
C言語風の式言語にはオフサイドルールはいらないと
言っているのはオフサイドルールを理解できない、
実装できないという理由からではない証明になったかと。

>>665
そういう設定用にはyamlがありますよね。
0670デフォルトの名無しさん2010/05/12(水) 11:21:58
>>660
ネストによってブロックを表現するのがオフサイドルールなので
必要以上にネストは深くする必要はないのだと思います。
こんなかんじで出来るよって例でタブも１文字と数えてるので
PythonやHaskell等の仕様とは違います。
0671デフォルトの名無しさん2010/05/12(水) 11:22:11
>>669
頭悪いのがコード貼り付ける前に、そんな議論あったか？
馬鹿がまたプログラムの勉強会始めたとか思ってたけど？
0672デフォルトの名無しさん2010/05/12(水) 11:23:00
自作自演でスレを埋めるの辞めて欲しい。
0673デフォルトの名無しさん2010/05/12(水) 15:52:09
いい加減、お前らが作りたい言語の仕様をしっかり定義しろよ
0674デフォルトの名無しさん2010/05/12(水) 19:34:35
C言語とLISPの合体したコンパイラ

#lang lisp
(defun lisp () (puts "hello world"))
#lang c
int main() {
lisp();
return 0;
}
0675デフォルトの名無しさん2010/05/12(水) 20:49:56
gccのソースコードみてみそ
0676デフォルトの名無しさん2010/05/12(水) 21:52:24
見るとどうなるの？
0677デフォルトの名無しさん2010/05/12(水) 21:57:40
RTLのmdファイルとかのこと言ってるんだろうけど
発想が全く違うよ
06786742010/05/12(水) 22:10:18
結局欲しいのはC言語としての出力なので、
LISPはあくまでも補助言語と考える。
LISPはプリプロセッサ的に使う、もしくはトランスレータを
内蔵しておき全てCとして出力する。内部のLISPランタイムや
GCなどが関係するコードが残るようならエラーとする。

例えば、マクロを定義するためならクロージャやGCオブジェクトなど、
LISPのフル機能が使えるが、出力にはLISPの痕跡は残らない。
0679デフォルトの名無しさん2010/05/12(水) 22:17:15
Cの欠点のひとつとしてマクロがあげられるぐらいなのに、さらにパズルを増やすのか？
06806742010/05/12(水) 22:30:05
マクロだけとは限らない。
コードの自動生成にも応用できる。
C++のテンプレート以上の効果が期待できる。
06816742010/05/12(水) 22:35:02
昔、似たようなことをやってた人がいた気がするけど、
LISPランタイムをリンクするような形だったので、
それとは方向性が違う。
ROMに焼くような組み込みでも使える処理系を目指す。
0682デフォルトの名無しさん2010/05/12(水) 22:46:51
一部にLisp入れるくらいなら、全部S式でいいよ。
06836742010/05/12(水) 23:10:00
目指す所は単なるLISP->Cトランスレーターとは違う。
ただのLISP処理系にしてしまうと目的がぼやけてしまうし、
S式をベースにすると冗長だったり書きにくい部分が必ずある。
Cとしての出力が目的なら、あくまでもメインはCであるべき。
学習コストと天秤に掛けると、独自言語という発想でもダメ、
それぞれ専門家のいる既成言語の組み合わせがちょうどいい。
0684デフォルトの名無しさん2010/05/12(水) 23:12:45
あんまり混ぜるとrubyみたいになりますよ
0685デフォルトの名無しさん2010/05/12(水) 23:15:12
それなら、新言語のマクロも新言語風の文法（A)で書ければいいんじゃないの。
なんで、新言語と異なる文法（B)でマクロをわざわざ書かなければいけないのかわからん。

異なる文法（B)の方が便利なら、新言語の文法自体をそちらの文法（B)にすればいいよね。
06866742010/05/12(水) 23:24:43
新言語、新言語風だと誰も使わない可能性がある。
俺はそんないつ消えるか判らない物は覚えたくない。
おれはCもLISPも知っている。だから両方使える言語を書く。
それだけ。
0687デフォルトの名無しさん2010/05/12(水) 23:30:31
なんか、かっこいいですね
惚れました
0688デフォルトの名無しさん2010/05/12(水) 23:33:38
>>686
スレ違い
06896742010/05/12(水) 23:36:56
はいさよなら。
0690デフォルトの名無しさん2010/05/12(水) 23:40:47
まあ、マクロは言語自体の文法で書けるのがいいだろうな。
0691デフォルトの名無しさん2010/05/13(木) 00:23:03
C言語のプリプロセッサの大部分は言語組み込みにしたほうがいいけど
マクロ関数は便利だしシンプルだ。
型安全ではないかもしれないが、動的言語のようにどんな型でも
変数に受け取って様々なことを高速に出来る。
遅延評価的なことも特別な仕組みもなく使える。
多くの言語の処理系では関数マクロを使われている。
インライン関数だけではなんともならない箇所もある。
0692デフォルトの名無しさん2010/05/13(木) 00:32:24
多くの"高階な"言語だろ
マクロでいじり倒したコードなんて趣味のもんだな
0693デフォルトの名無しさん2010/05/13(木) 00:36:03
新言語ではワクワクするようなコーディングをしたい。

そのためには趣味性も重要。
0694デフォルトの名無しさん2010/05/13(木) 00:58:06
低レベルな言語なんだろ？
趣味を満たしたかったらScalaでもOCamlでもやってた方がいいんじゃないか
0695デフォルトの名無しさん2010/05/13(木) 00:59:34
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
0696デフォルトの名無しさん2010/05/13(木) 02:08:29
低レベル＝実用的な言語が欲しいんだろ

まあスレッド、バリア、Mutexが
CSP風に組み込まれてたら面白そうだがな
0697デフォルトの名無しさん2010/05/13(木) 04:13:12
いつも思うんだがお前らが作る言語は
どの言語にそっくりなのか

型に甘いの型に厳しいのか
動的型付けなのか静的型付けなのか
グローバル変数とグローバル関数は許すのか
goto文はありなのか
C/C++/Javaのように改行なしでも一行で膨大なコードを
書くことすらできるものなのか否か、
型に文字列型、配列型、整数型、小数型、文字型、bool型等
きっちり細かく決めるのかそこらへん適当なのか、
クラスはありなのか、
クラスがありのときjava.lang.Objectのような基底クラスがあるのか、
例外処理がありのとき、java.lang.Throwableのように例外やエラーの基底クラスがあるのか、
アサーションありなのか、
アスペクト指向でポイントカットやウィービングありなのか、
Java Generics、C++ templateのような型はありなのか、
マルチスレッドの扱いはどうなっているのか
staticと非staticの違いはありなのか
などなど疑問点が付きないのだが
0698デフォルトの名無しさん2010/05/13(木) 05:38:46
なげえ。
Cに代わる低級言語ってスレタイ思い出してまとめろよ
0699デフォルトの名無しさん2010/05/13(木) 06:55:00
Cの関数マクロは実用的だ。趣味だけじゃない。
VC++のメッセージもマクロだ。
RubyのCのメモリ管理周りもマクロだ。
VMの実装にもマクロ。
マクロ、マクロ。
Cのマクロはただ美しくないから嫌われてるだけ。
欲しいのは美しいマクロ。構造化されたマクロがその答えではないか？
テンプレートはホントに美しいか？
インターフェイスの記述をトランスレートするのが簡単であればよい。
エディタの色づけが楽であればよい。
0700デフォルトの名無しさん2010/05/13(木) 07:14:07
マクロもテンプレートも、C/C++のきたないところ。
0701デフォルトの名無しさん2010/05/13(木) 07:32:33
テンプレートは（文法以外は）美しい
0702デフォルトの名無しさん2010/05/13(木) 07:33:18
>>698
自分は言語は小さく、ライブラリに出来るものはライブラリにする。
演算子定義とLispのマクロ的なコンパイルタイムプログラミングで
抽象化し記述力を上げる言語を考えているので以下のようになります。
どんな言語に似てるかはシンタックスはJavaScript、Lisp
機能的にはD、Scala、golangあたり。
型 プリプロセス時は甘く動的、コンパイル時は固く静的
グローバルありで、gotoあり、改行なしで書ける。
型の詳細は未定、クラスは言語で仕様はないけどライブラリで実装出来て、
例外はありで巻き戻し処理はマクロでやろうとする。
アスペクト指向はプリプロセッサでやれる。
ジェネリックス、C++テンプレートもプリプロセッサで、
Tではなくa'的なものを検討したり衛生的なマクロ等、後から出来る設計。
マルチスレッドはライブラリで。synchronized式をマクロで実現できれば。
グローバルなstaticはprivateで、関数内、class内staticはありかな？
0703デフォルトの名無しさん2010/05/13(木) 07:40:12
テンプレートが美しいのは、文法だけ。
0704デフォルトの名無しさん2010/05/13(木) 15:22:19
hoge<foo>とか超汚い
0705デフォルトの名無しさん2010/05/13(木) 15:38:14
C++のテンプレートがクソなら
Java Genericsを適用すればいい
0706デフォルトの名無しさん2010/05/13(木) 22:27:39
これをもう少しオサレにする感じで

LLVM Assembly Language Reference Manual
http://llvm.org/docs/LangRef.html
0707デフォルトの名無しさん2010/05/13(木) 23:48:56
C/C++に変わる低級言語って、DとかGoじゃいかんの？
0708デフォルトの名無しさん2010/05/13(木) 23:49:53
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
0709デフォルトの名無しさん2010/05/13(木) 23:55:01
「なぜ、新たなプログラミング言語を考えることが目的になるのか」
を考えることには意味があるだろう
そうすることによって、作るべきものがもっと明確になる
0710デフォルトの名無しさん2010/05/13(木) 23:56:38
じゃあ、考えようか。
0711デフォルトの名無しさん2010/05/13(木) 23:58:10
とりあえず、Goが失敗したから
0712デフォルトの名無しさん2010/05/14(金) 00:26:17
【このスレの趣旨】
初代>>1「とにかくC/C++は古くてダサいので、C/C++に変わる何かが欲しい。
　Cは今でも『低レベル』の開発で使ってるらしいから、そこで使える言語キボンヌ。
　言語研究の最新トレンドなら何でもいいけど、取りあえずOOぐらいは付けといて。」

Lisp　　　　（ ＾ω＾）「よし俺が」
Go・D　　　　（ ＾Д＾）「いや、俺らが」
LL・Java　　(^p^)　　「じゃぁ、ここは俺たちが」
Haskell　　(´ｑ｀)n　「いや、俺とForthで」

(´-｀).｡ｏO(で、お前らOS作れんの？)
（ ＾ω＾）「作れるお（実際作ったこと無いけど）
(´-｀).｡ｏO(で、ARMのMemory mapped I/Oとかアクセス出来んの？)
(^p^)「ARM汚い、x86汚い、マシン語が美しいのはMIPSだけ！！」

(´-｀).｡ｏO(こいつらじゃ無理だな、まぁいいかどうせ糞スレだし）
0713デフォルトの名無しさん2010/05/14(金) 00:36:28
(´-｀)←現実世界では間違いなくこいつが一番役に立たないんだけどな。
0714デフォルトの名無しさん2010/05/14(金) 00:42:48
ＯＳとか今から作らないし
言語１から作るより多言語のオブジェクト利用でいいじゃないか
こういうスレで実際作られたの見た事ない
0715デフォルトの名無しさん2010/05/14(金) 00:53:42
JavaのOSは一応あったぞ
たぶん他の言語でもいくつかはあるんじゃね？
0716デフォルトの名無しさん2010/05/14(金) 01:01:45
プログラマーとして会社に勤めていても周りの奴らは
こいつ一人じゃいくら時間あってもまともなアプリケーションつくれないだろって奴だらけ
0717デフォルトの名無しさん2010/05/14(金) 01:04:28
(´-｀)←こいつがな。
0718デフォルトの名無しさん2010/05/14(金) 01:30:49
C言語の代替ということは即ちアセンブリ言語の代替に他ならない
アセンブリ言語(もっと言えば機械語)がわからんヤツは議論に参加する資格なし

では何故、C言語の代替を求めるのか？
それはC言語に時代錯誤な過去のしがらみが大量に残っているからである

多くのプログラマを困らせる(仕様上の)あいまい、無責任を許してはならない
今となっては使い物にならないものはバッサリと捨てる
多くのプログラマが毎回唱えるおなじないは簡素化もしくは自動化すべき
0719デフォルトの名無しさん2010/05/14(金) 01:35:31
最後の1行だけ採用
0720デフォルトの名無しさん2010/05/14(金) 01:40:46
要するに君達は
Ｃをキレイにしたいだけだろう
0721デフォルトの名無しさん2010/05/14(金) 01:42:33
最近の言語で流行ってる機能も入れたい
0722デフォルトの名無しさん2010/05/14(金) 01:52:37
>>718
Cに残っているマクロ以外の時代錯誤なしがらみってなんだ？
基本型のサイズがあいまい。これくらいか
他に何があるん。
そっからスタートしてみてはどうだ

>>711
goはこれからだよｗ
0723デフォルトの名無しさん2010/05/14(金) 03:34:54
最近の CPU や OS に最適化しやすい設計がされててコードが綺麗に書ける奴頼むわ。
セルやマルチコア意識した奴。
0724デフォルトの名無しさん2010/05/14(金) 05:31:20
メジャーなコンパイラ使ってれば哀れなメンテナが勝手に対応してくれるよ
0725デフォルトの名無しさん2010/05/14(金) 06:45:38
T -> a' -> ?
0726デフォルトの名無しさん2010/05/14(金) 06:49:05
マクロアセンブラは実用的
オブジェクティブアセンブラはあるのか？
0727デフォルトの名無しさん2010/05/14(金) 07:04:00
アセンブラでなくなる気が
0728デフォルトの名無しさん2010/05/14(金) 07:23:14
オブジェクト指向は素晴らしいので
アセンブラでもオブジェクト指向なプログラミングをすべき！
0729デフォルトの名無しさん2010/05/14(金) 09:02:18
低級言語かどうかはわからないが、
マルチスレッドプログラムが安全効率的に書けるシンプル軽快な言語は欲しい
0730デフォルトの名無しさん2010/05/14(金) 09:07:35
>>729
Erlang, Go-lang
0731デフォルトの名無しさん2010/05/14(金) 17:07:21
マルチスレッドいいねえ
0732デフォルトの名無しさん2010/05/14(金) 17:11:55
>>729
ここで言ってる低級よりは上の話だろうな
言語組込のメッセージパッシングやアクタとかだべ？
0733デフォルトの名無しさん2010/05/14(金) 18:49:02
良いねぇそういうのが良い。
0734デフォルトの名無しさん2010/05/14(金) 19:04:45
test
0735デフォルトの名無しさん2010/05/14(金) 21:47:51
>>732
でもそういう理論だけでは効率的な実装ができないのは歴史が実証済み。
0736デフォルトの名無しさん2010/05/14(金) 22:14:42
てかスレッドスケジュールはOSの仕事だと思うので、
OSに仕事を任せられる言語仕様が必要だと思う。
スレッドは頭痛いよね。ライブラリ対応しちゃうと
言語と離れすぎるし、言語対応するとランタイムの
問題が発生するし。
0737デフォルトの名無しさん2010/05/14(金) 22:27:10
実行時のスレッド管理などそもそも言語仕様に含まれるようなもんじゃない。
言語仕様には「コンパイラへの指示(あるいはヒント)」を含めるんだよ。
「ここは(可能であれば)別スレッドにしてね」というだけ。
あとは環境ごとにコンパイラが合わせて最適なバイナリを吐く。
判断するのはコンパイラの仕事。それで十分。
0738デフォルトの名無しさん2010/05/14(金) 22:32:34
>>737
スレッドモデルによって、何をヒントとして出さなければ
いかんのかが少し変わってくるし、シングルCPU上でスレッド
命令の取り扱いを決めなきゃ駄目だし。
そしてそれを検証できないと駄目。
0739デフォルトの名無しさん2010/05/14(金) 22:36:46
ttp://www.lesson-abc.net/products/detail.php?product_id=2587&category_id=70
レビューに書いてあったけど　ほんとに寿甘みたいだった

ttp://www.lesson-abc.net/upload/save_image/00004396/sub5_500.jpg
0740デフォルトの名無しさん2010/05/14(金) 22:37:32
誤爆した



だめだ今日はもう寝る
0741デフォルトの名無しさん2010/05/14(金) 22:47:44
マルチスレッドの扱いも新言語のスコープだよ。
0742デフォルトの名無しさん2010/05/14(金) 23:07:19
>>739 >>740
スレッドの切り替えに失敗したんですねw　
0743デフォルトの名無しさん2010/05/14(金) 23:14:18
メッセージの送信先が間違ってたんだろｗ
0744デフォルトの名無しさん2010/05/14(金) 23:17:34
標準ライブラリで用意する関数郡は全てスレッドセーフにするべきだ
strtok()とかロクに使わない上にスレッドセーフでもない完全にいらない子
自分が過去のしがらみと言ってるのはこういう部分だ
0745デフォルトの名無しさん2010/05/14(金) 23:29:53
ソケット周りも巣窟だな
0746デフォルトの名無しさん2010/05/15(土) 00:33:41
ランタイムはいるがCSPみたいなマルチスレッドサポートのデータ型とか
排他用の変数とかあったらいいよな
pthreadほどじゃなくていいけど、小さなRTOSレベルで制御できたらいいな
0747デフォルトの名無しさん2010/05/15(土) 00:43:31
副作用を制限しつつノイマン型に最適化された言語が欲しい
0748デフォルトの名無しさん2010/05/15(土) 00:43:47
>>725
Tとかa'って何？
0749デフォルトの名無しさん2010/05/15(土) 01:06:06
型変数も知らんのか
お前にこのスレはまだ早い
0750デフォルトの名無しさん2010/05/15(土) 01:13:39
早いも何も、googleにすら出てこない用語を使うのは、自己満足以外の何者でもないよ。

http://www.google.co.jp/search?q=T+a%27

自己満足ではなく、他人と対話をしたいのなら、一般的な用語を使うべきでは。
0751デフォルトの名無しさん2010/05/15(土) 01:26:28
トップに出てくるじゃねえか
0752デフォルトの名無しさん2010/05/15(土) 08:21:06
コンパイラ用語のわからん奴は来るな
0753デフォルトの名無しさん2010/05/15(土) 08:26:25
strcpyとか、memcpyとか、脆弱性無視した標準関数だらけのC言語は害悪。
0754デフォルトの名無しさん2010/05/15(土) 08:37:04
いや、memcpyがなきゃ、OSのディスクバッファの読み書きとか書けないだろw
0755デフォルトの名無しさん2010/05/15(土) 10:00:54
Cで脆弱性とか言っている時点で、参加する資格なし。
0756デフォルトの名無しさん2010/05/15(土) 10:05:25
問答無用でセキュリティホールになるgetsとかは問題かな
0757デフォルトの名無しさん2010/05/15(土) 11:09:45
組み込みでもマルチコア構成だったりネットワークに繋がったりする昨今
脆弱性を考慮しない>>755のような脳無しこそ本当の害悪だわ
0758デフォルトの名無しさん2010/05/15(土) 11:22:15
ネットワークはいいとして、マルチコアと脆弱性に何の関係があるんだ？
知ってる言葉並べたがるお年頃なのか？
0759デフォルトの名無しさん2010/05/15(土) 11:27:23
言語仕様の話かライブラリの話かはっきりしろ
0760デフォルトの名無しさん2010/05/15(土) 11:35:40
memcpyはいいが、strcpyは時代遅れ。
0761デフォルトの名無しさん2010/05/15(土) 11:49:42
京大霊長類研究所の猿が立てた雑談スレに書き込むに、なんの資格が居るんだｗ
0762デフォルトの名無しさん2010/05/15(土) 12:02:44
で、結局T, a'って何なの
0763デフォルトの名無しさん2010/05/15(土) 12:05:08
>>761
霊長類学修士か、獣医学修士
0764デフォルトの名無しさん2010/05/15(土) 12:13:22
ゆとり世代といっても平均値が落ちてるだけでおまいらより優秀な奴はゴロゴロいる様に
霊長類の知能も平均値が落ちるだけでおまいらより優秀なアイちゃんはゴロゴロ居るわけだ
0765デフォルトの名無しさん2010/05/15(土) 12:15:16
Haskell見てるとPrologでいいじゃん、て思うよね
0766デフォルトの名無しさん2010/05/15(土) 12:15:39
>>761
アイちゃんへの溢れんばかりの愛を持ってる事ただ一つ
0767デフォルトの名無しさん2010/05/15(土) 12:17:53
>>762
意味不明の単なるノイズだから気にしなくていいよ。
0768デフォルトの名無しさん2010/05/15(土) 13:57:14
template<T> T inc(T a){return a + 1; }
と型変数定義を書くことなく
inc(a) { return a + 1; }
と書いて型推論されたりするといいよな
[a] inc([a] a) { return a + 1; }
って感じに。型変数の記述方法でC言語系統にあう記法ってないかな？
って話です。

T -> a' -> ?
に対する期待した結果は a'はocamlの型変数に似ていますが'aの間違いです。
といったメッセージが表示されることです。
?は可能性爆発するのでそれなりの計算途中の状態が表示されることです。
0769デフォルトの名無しさん2010/05/15(土) 14:05:12
inc(a) { return a + 1; }
↑これをこう↓書くと、どういうメリットが生まれるの？
[a] inc([a] a) { return a + 1; }

[a]によって何をさせたいのか明らかにすると議論が深まるよ。
0770デフォルトの名無しさん2010/05/15(土) 14:30:46
>>768
OCamlでは
let inc n = n + 1
はint -> intに推論されるけど
Cの系統だと+演算子が整数や実数全部にオーバーロードされるから
この場合は「+が定義されている型」という制約つき総称型みたいなものに
自動的に推論して欲しいってことか？
0771デフォルトの名無しさん2010/05/15(土) 15:09:05
推論するときは、推論したとログ吐いてくれればいい。
0772デフォルトの名無しさん2010/05/15(土) 15:11:48
inc(a){return a + 1;}
では型が記述されてないんだけど、型推論によって
[T] inc([T] a){return a + 1;}
と推論されるといいねと。
#define inc(a) a + 1
と書くのと同等の記述量の少なさになって型なくて展開された後のコンパイルエラー
が分け分からないということもなくていいのかなと。

>>770
そんなかんじです。Haskellに近くしたい感じですね。

[a]は配列にしたいだろうからT[a]とするとかT{a}とかなにかいい記述方法あるといいと思います。
0773デフォルトの名無しさん2010/05/15(土) 15:19:47
「[T]」って自動推論によって推論された型のことを表しているんだな。

オレ記法を説明なしで書かれると疲れるよ。
0774デフォルトの名無しさん2010/05/15(土) 15:25:50
#define [A] inc([A] a) a + 1
深く考えてないですが、こんな感じの型付きのマクロでマクロ展開時の
コンパイルタイムプログラミングのエラー出力が
わかりやすくなったらいいなとか。
よりハイジニックなマクロが可能と。
ここらへんに改良の余地がありそうだと思うのですが、
自分で何言ってるかよくわからないので考えてみます
0775デフォルトの名無しさん2010/05/15(土) 15:27:52
>>773
そうです。説明不足で、すいません
0776デフォルトの名無しさん2010/05/15(土) 15:28:47
分かればいいよ。ドンマイ。
0777デフォルトの名無しさん2010/05/15(土) 15:35:41
I thinking now...
0778デフォルトの名無しさん2010/05/15(土) 15:53:59
ダックタイピングいいな
0779デフォルトの名無しさん2010/05/15(土) 16:09:45
>>768
もうPerlとかPHPとかJavaScriptとかみたいな型にいい加減な言語でも
作りたいのかと
0780デフォルトの名無しさん2010/05/15(土) 16:22:55
>>779
テンプレートライブラリと、マクロがごちゃくちゃになってる馬鹿が
書いてるのでそう誤解しちゃうんだと思う。
多分>>768馬鹿だけど、動的型変換は目指してないというか、目指すだけの
知恵が無いというか。

んで話は変わるのだけれども、C/C++の方でもSTLの妖精から、
auto型の導入とか言い始めてて、さらに混乱に拍車をかけてるのが
もうね、C/C++は一回捨てたい。と考える理由。

でも、確かにテンプレートは必要かなって思うので、テンプレートの
書式を、言語の仕様とぶつからない形で導入したいと思う。

C/C++には、C言語の文法、C++の文法、プリプロセッサマクロ、さらに
STL文法という４つの文法が渾然一体となっていて、これが悲劇の理由だと思う。
さらに、標準ライブラリは古いは、基本スカラ型が曖昧だわ、悲劇の塊だと
思うのですよ。悪いのは>>768馬鹿が馬鹿を自覚してない事なんだけどね。
0781デフォルトの名無しさん2010/05/15(土) 16:29:31
そんなに悔しかったんですかね。
0782デフォルトの名無しさん2010/05/15(土) 16:35:19
新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。
0783デフォルトの名無しさん2010/05/15(土) 16:45:56
591 ：デフォルトの名無しさん ：sage ：2010/05/10(月) 00:58:04
新言語では、ソース中でのタブ文字の使用を禁止したい。
あるいは、ソース中のタブ幅を例えば４文字に固定したい。

654 ：デフォルトの名無しさん ：2010/05/12(水) 00:08:37
新言語ではプリプロセッサでもその言語の機能を使えるようにしたい

693 ：デフォルトの名無しさん ：2010/05/13(木) 00:36:03
新言語ではワクワクするようなコーディングをしたい。

そのためには趣味性も重要。

782 ：デフォルトの名無しさん ：sage ：2010/05/15(土) 16:35:19
新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。
0784デフォルトの名無しさん2010/05/15(土) 16:51:07
バグがでにくい言語仕様が欲しい
0785デフォルトの名無しさん2010/05/15(土) 17:00:11
バグが出にくく、かつ、煩雑で冗長な記述の繰り返しが少ない言語仕様が欲しい。
0786デフォルトの名無しさん2010/05/15(土) 17:17:27
効率を最優先しつつそのなかで最もバグのでにくい仕様でおねがい
0787デフォルトの名無しさん2010/05/15(土) 17:48:56
Javaのautoboxing、C#のboxing, unboxing変換はどうする気だ
0788デフォルトの名無しさん2010/05/15(土) 18:04:03
クラスがなかったら、そんなのあってもうれしくないな。
0789デフォルトの名無しさん2010/05/15(土) 18:09:38
ロジカルなバグはプログラマーが頑張るしかないんだけど、
if( a=1 || 32 % x){
}

こういう記述で、コンパイルが通り実行もかかるのに、
いくつもバグが入ってるってのは避けたいよね。
0790デフォルトの名無しさん2010/05/15(土) 18:14:15
もう、前置記法でいいよ。
0791デフォルトの名無しさん2010/05/15(土) 18:35:33
>>789
int型とbool型を明確に分けて、その間で暗黙のキャストをしないようにしたら解決する。
代わりに、パズル的記法の面白さはなくなる。
0792デフォルトの名無しさん2010/05/15(土) 18:41:34
>>789
普通のコンパイラは警告が出る。
0793デフォルトの名無しさん2010/05/15(土) 18:42:07
関数形でそんな暴挙に出たら使い物にならないぜ
0794デフォルトの名無しさん2010/05/15(土) 18:45:39
代入の記号をもっと考えたほうがいいな。
0795デフォルトの名無しさん2010/05/15(土) 18:49:18
>>794
:= 代入・複製
<= ムーブ
0796デフォルトの名無しさん2010/05/15(土) 18:51:58
>>794
なれると間違えないようにはなる。
たまに、BASIC、PASCALを見ると違和感を感じるけど。
0797デフォルトの名無しさん2010/05/15(土) 18:55:11
　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;;
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;;　　なれると間違えないようにはなる・・・
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんなふうに考えていた時期が
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f.　　　俺にもありました
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!
0798デフォルトの名無しさん2010/05/15(土) 18:58:10
で、>>789が怖いのは、
なんだ書き間違いのバグじゃんって、事で

if( 1==a || 32 % x){
}

と書き直して、実行してみて結果が大丈夫で良かったと思って納品すると、
x==0の確認忘れてて、　1!=a の条件にぶち当たって、ゼロ除算例外で
プログラムが停止して、ものごっつい涙目って事がよくあるんだよね。
0799デフォルトの名無しさん2010/05/15(土) 19:01:54
0除算って、構文の工夫で防げるものなの？
0800デフォルトの名無しさん2010/05/15(土) 19:22:56
というか、C言語の仕様ではor条件のときに二番目を評価するかしないかは
実装依存。という事で、1==aの間はX==0でも評価されないので
zero助産が妊娠。
0801デフォルトの名無しさん2010/05/15(土) 19:25:14
え？
0802デフォルトの名無しさん2010/05/15(土) 19:27:08
>>800
えっ
0803デフォルトの名無しさん2010/05/15(土) 19:28:07
なにそれこわい
0804デフォルトの名無しさん2010/05/15(土) 19:31:44
>>800は伝説の釣り師
0805デフォルトの名無しさん2010/05/15(土) 19:34:18
>>799
どちらかというとアルゴリズムの改良だね。単位ベクトルを求める演算を工夫して無くすとかだね
0806デフォルトの名無しさん2010/05/15(土) 19:39:33
>>805
それって、既存言語と変わらないアプローチだよね？

新言語として構文の改良でどうにかするのは難しいかな。
0807デフォルトの名無しさん2010/05/15(土) 19:41:48
>>806
/演算子を無くすぐらいしかできなくね？
0808デフォルトの名無しさん2010/05/15(土) 19:45:44
変数を無くせばコンパイルエラーで弾けるな
0809デフォルトの名無しさん2010/05/15(土) 19:51:07
0以外の数という型を新設して(数学っぽく書けばint*とか)
それを分母に持ってくるようにキャストするよう強制すれば
一応は0除算防げるが、誰も得しない。
non-null型と似たような発想。non-null型は得するけど。
0810デフォルトの名無しさん2010/05/15(土) 20:24:30
加算と乗算が可能な自然数型を定義すればよい
減算と除算は自然数に関して閉じていないのでダメ

しかしそれでは不便なので、皆単なる整数を使うのであった…
0811デフォルトの名無しさん2010/05/15(土) 20:32:12
「自然数」って何だか知ってる？
0812デフォルトの名無しさん2010/05/15(土) 20:34:13
>>810
対象は符号なしのみか。
0813デフォルトの名無しさん2010/05/15(土) 22:08:39
一回しか代入できない変数、
継承禁止、メソッドのオーバーライド禁止、メソッドの引数の上書き禁止に使う
finalは導入するのか？


それとも、メソッドのオーバーライドを可能にするvirtualを導入するのか？
0814デフォルトの名無しさん2010/05/15(土) 22:09:46
>>805
単位ベクトルだと？
おまえはMATLABのような言語でも作ろうとしているのか？
0815デフォルトの名無しさん2010/05/15(土) 22:11:08
>>799
防がずに複素数を導入したり
無限大やNaN、かのならNaNより複素数やを返すのもありだ
0816デフォルトの名無しさん2010/05/15(土) 22:11:55
>>809
Rational型(有理数型)か？
クラスで実現可能だな。
Complex型(複素数型)の導入もありだが。
0817デフォルトの名無しさん2010/05/15(土) 22:49:24
デフォルトでは、整数型・実数型は任意精度にしたいな。

必要の応じてコンパイルオプションやソース中で型宣言出来ればいい。
0818デフォルトの名無しさん2010/05/15(土) 23:18:07
割り算は演算子をsizeofみたいな予約語にしてほしい
これだけでもコード確認が容易になる
0819デフォルトの名無しさん2010/05/15(土) 23:19:36
なぜ割り算だけ
0820デフォルトの名無しさん2010/05/15(土) 23:22:53
割り算だけは例外発生するから
0821デフォルトの名無しさん2010/05/15(土) 23:32:14
例外発生させなきゃいいじゃん
0822デフォルトの名無しさん2010/05/15(土) 23:34:16
やっぱり低級言語でも例外機構っているの? 組み込み系の人が怒りそう。
0823デフォルトの名無しさん2010/05/15(土) 23:34:24
いや/0は例外発生しようがしまいが問題あるだろ
0824デフォルトの名無しさん2010/05/15(土) 23:37:43
>>1
それは無限精度でもなければ、加減乗算でのオーバーフロー、アンダーフローでも同じことだろ。
0825デフォルトの名無しさん2010/05/15(土) 23:39:39
割り算だけが０が特別だからだろ
オーバーフローアンダーフローは四則演算すべての問題
0826デフォルトの名無しさん2010/05/15(土) 23:42:56
で、それと割り算だけsizeofみたいな予約語にすることと、どう関係があるの？
0827デフォルトの名無しさん2010/05/15(土) 23:49:43
>>822
CPUによると思うけど0除算てCPU割り込み発生したりするでしょ
0828デフォルトの名無しさん2010/05/15(土) 23:50:42
CPUによるね。
0829デフォルトの名無しさん2010/05/15(土) 23:52:34
明らかに特殊な演算を記号にすると検索性の問題がある
0830デフォルトの名無しさん2010/05/15(土) 23:53:11
四則演算は特殊じゃないよね。
0831デフォルトの名無しさん2010/05/15(土) 23:57:05
四則演算は一心同体だろう。ひとつだけ特殊な扱いにするとかはない。
するなら全部する、しないなら全部しない。
0832デフォルトの名無しさん2010/05/16(日) 00:00:03
割り算だけ特異点がある。
これが同じとか数学のセンスなさ杉。
0833デフォルトの名無しさん2010/05/16(日) 00:00:08
余剰演算もたまには思い出して挙げてください
0834デフォルトの名無しさん2010/05/16(日) 00:00:30
>>822
この件にまじめに答えると、
スタンドアロンな画面のない装置でも、
LEDとかでエラー通知する手段は設ける。
例外機構が使われないのは、追加ランタイムとかで
サイズが膨れあがる事が多いのと、ほとんどの場合
MCU側の仕組みを直接使う方が楽だから。
0835デフォルトの名無しさん2010/05/16(日) 00:02:38
例外のある言語はクリティカルなソフトウェアの
構築には使えない。らしい。
0836デフォルトの名無しさん2010/05/16(日) 00:03:17
>>832
四則演算の一つだけ構文的に特殊な扱いをすることにセンスを感じないが。
0837デフォルトの名無しさん2010/05/16(日) 00:04:45
数学的な話すれば
引き算と割り算はそれぞれ足し算と掛け算で言うところの
逆元を使ってるだけ。
0838デフォルトの名無しさん2010/05/16(日) 00:08:14
>>836
ヨーロッパのキリスト教徒は君と同じセンスで、
ゼロもマイナスも複素数も認めない、
っていう時代が、1685年ほど続いた。

一般に暗黒の中世と呼ばれてる時代。
0839デフォルトの名無しさん2010/05/16(日) 00:08:45
>>837←単なる知識披露で全く意味が無い書き込みの例
0840デフォルトの名無しさん2010/05/16(日) 00:13:52
>>837
必ずしも逆元は存在するわけではないって言ってるんじゃないの？
0841デフォルトの名無しさん2010/05/16(日) 00:13:57
>>838
ひどい話のすり替えだな。

ゼロを認めないで特別扱いしようとしているのは君のセンスの方だろう。
0842デフォルトの名無しさん2010/05/16(日) 00:15:21
特別扱いしないのなら０割はどういう扱いにするん？
0843デフォルトの名無しさん2010/05/16(日) 00:17:23
inline関数のスコープはレキシカルスコープ。
Cのマクロはダイナミックスコープな関数と考えたら面白くないですか？
0844デフォルトの名無しさん2010/05/16(日) 00:17:34
面白くない
0845デフォルトの名無しさん2010/05/16(日) 00:25:08
>>842
0以外の定数でしか割れないようにすればいい
0846デフォルトの名無しさん2010/05/16(日) 00:26:27
なんだかますますC言語でいいような気がしてきた！
0847デフォルトの名無しさん2010/05/16(日) 00:28:27
で変数で除算するためにビット演算を駆使するんですね！
0848デフォルトの名無しさん2010/05/16(日) 00:29:01
保守的だな
0849デフォルトの名無しさん2010/05/16(日) 00:30:07
>>845
定数だけってそれこそ特別扱いじゃないか？
定数で割るってことは定数で掛けることと一緒だぜ。
0850デフォルトの名無しさん2010/05/16(日) 00:30:47
なんか初心者がいるな
0851デフォルトの名無しさん2010/05/16(日) 00:31:13
>>842
どれか

(1)例外を投げる
(2)NaNを返す
(3)仕様上、未定義にする（除数に0を入れたユーザーの責任）
0852デフォルトの名無しさん2010/05/16(日) 00:35:03
またループか
0853デフォルトの名無しさん2010/05/16(日) 00:36:01
どの辺が？
0854デフォルトの名無しさん2010/05/16(日) 00:42:11
現状の方法に戻った
0855デフォルトの名無しさん2010/05/16(日) 00:43:18
現状も何も、新言語はこれから作るんだけど？
0856デフォルトの名無しさん2010/05/16(日) 01:41:05
>>851
NaNでいい。これが一番スマート。
未定義動作は極力含めない方向で。あいまいさは最も唾棄すべき仕様なので。
0857デフォルトの名無しさん2010/05/16(日) 01:55:10
整数型の場合は？
0858デフォルトの名無しさん2010/05/16(日) 02:03:38
(1) 0
(2)とりうる最大の値
(3)とりうる最小の値
0859デフォルトの名無しさん2010/05/16(日) 02:06:58
0/0はどれ？
0860デフォルトの名無しさん2010/05/16(日) 02:13:11
０除算したら、現状通りSIGFPEでプロセス終了でいい
0861デフォルトの名無しさん2010/05/16(日) 02:17:00
現状なら例外ではなくて？
0862デフォルトの名無しさん2010/05/16(日) 02:18:30
ユーザーにどう伝えるかの議論がないところがレベルの低さのゆえん
0863デフォルトの名無しさん2010/05/16(日) 02:19:24
C++等は例外で拾えるんだっけ
勝手にシグナルハンドラ定義しているのかな
0864デフォルトの名無しさん2010/05/16(日) 02:30:24
>>862
あなたの考えは？
0865デフォルトの名無しさん2010/05/16(日) 02:32:13
なんか変な話になっとるね
- NaNは整数型では実現不可
- java/C++風の言語組み込みの例外は下品
- 858は意味不明

構文的な例外は不要だが
signalみたいな割り込みはあっても面白いかもな
0866デフォルトの名無しさん2010/05/16(日) 03:04:07
0/0 の動作は implementation-defined か unspecified でいい
0867デフォルトの名無しさん2010/05/16(日) 03:09:16
おまえらじゃCの代わりは作れんな
0868デフォルトの名無しさん2010/05/16(日) 03:11:58
Cでは「言語があまり余計な事はしない」のが鉄則
0869デフォルトの名無しさん2010/05/16(日) 03:13:19
生成バイナリは余計なことをしないほうがいいがそれ以外は手厚くすべき
0870デフォルトの名無しさん2010/05/16(日) 03:19:00
速度に影響する２つの仕様案があるなら
速い方を選ぶのがCの基本

速い方と遅いけど色々出来る方の
両方を用意するのは構わないが
0871デフォルトの名無しさん2010/05/16(日) 03:50:55
整数型のビットパターンのどれかをNaNにすれば…と思ったけど難しいな
そもそも2進数で最上位ビットのみを符号とみなしているのに残りのビットが正負で絶対値が異なるのは何故だっけ？

00001111 = 15
10001111 = -113 //何故 -15 ではない？
0872デフォルトの名無しさん2010/05/16(日) 03:54:39
おまいらに任せても劣化 C しか出てこなさそうだな。
0873デフォルトの名無しさん2010/05/16(日) 03:58:31
だからC最強だってw
C++みたいな劣化バージョンと一緒にすんなよw
0874デフォルトの名無しさん2010/05/16(日) 04:00:03
>>871
ついに補数知らないヤツもきたか
2の補数、1の補数でくぐりな
0875デフォルトの名無しさん2010/05/16(日) 04:02:10
>>874
補数は知ってるよ。何故そうするのか？を知りたい。
0876デフォルトの名無しさん2010/05/16(日) 04:04:40
>>875
ここから出てくるな
http://pc12.2ch.net/test/read.cgi/tech/1178723829/
0877デフォルトの名無しさん2010/05/16(日) 04:11:02
半加算器とかそのへんから
0878デフォルトの名無しさん2010/05/16(日) 05:05:31
つまり古の時代に減算回路を省いたが故のしがらみということか
0879デフォルトの名無しさん2010/05/16(日) 06:11:39
>>817
さて、それは何進法で表現するのか？
任意精度というからには、その分だけのバッファ領域を
どのタイミングで確保、再確保するのか？

2進数か10進数で表現するかなどでまた揉めるぞ
3進数や10進数を処理できる量子コンピュータが一般化すると2進数プログラムはゴミクズ以下の癌細胞になる
そして10進数は現代でもすでに金融系で重要視されている

JavaのBigInteger、BigDecimal型、C#のdecimal型のように

それから2進数と10進数との間には10進2進変換誤差があるからな


>>818
JavaのBigDecimal#divide()のようなメソッドで割り算を表現するというのか？
もし任意精度にすると、割り算メソッドの引数はこうなってしまうぞ。
「スケール」はバッファ領域や処理する最大桁数を意味する。roundingModeは丸めモードだ。端数を切り捨てるのか、切り上げるのか、
それとも奇数の場合切り上げ、偶数の場合切り捨てる、といった処理をするなどの選択をするためのものだ。
mathContextは桁数制度と丸目モードをカプセル化したオブジェクトだ。
コンストラクタであらかじめmathContextオブジェクトを詰めておけばこういう手間は省けるが。


http://java.sun.com/javase/ja/6/docs/ja/api/java/math/BigDecimal.html#divide(java.math.BigDecimal,%20int,%20java.math.RoundingMode)
BigDecimal#divide(BigDecimal, int, int)
divide(BigDecimal divisor, int scale, int roundingMode)
値が (this / divisor) で、スケールが指定されたものである BigDecimal を返します。
divide(BigDecimal divisor, int scale, RoundingMode roundingMode)
値が (this / divisor) で、スケールが指定されたものである BigDecimal を返します。
divide(BigDecimal divisor, MathContext mc)
コンテキスト設定に従った丸めを使用して、値が (this / divisor) である BigDecimal を返します。
0880デフォルトの名無しさん2010/05/16(日) 06:14:40
>>837
だからそんなのでは0除算対策にならない。
MATLABのようにNaN、Infという値を新たに作るか、
それとも例外処理を追加するか、など検討しなければ
0881デフォルトの名無しさん2010/05/16(日) 06:15:22
それから0除算対策として
割り算を分数として保持しておくてがある
RationalクラスやFractionクラスで作成する分数オブジェクト、といったところか
0882デフォルトの名無しさん2010/05/16(日) 06:17:11
>>856
それは分子が0のときだろう。
分子が0以外の実数のときは -Infinityか+Infinityを返すべきだ
0883デフォルトの名無しさん2010/05/16(日) 10:04:41
>>882
Infinity返すのは違うだろう。単に未定義なんだから。
例えば、lim[x->-0]-1/x の場合は+Infになる。
0884デフォルトの名無しさん2010/05/16(日) 10:09:22
0で割ることはできない。意味がない。結果うんぬんの前に実行できない。だから例外を返すわけよ。
むりやり値にするならNA(not available)が一番近い。
0885デフォルトの名無しさん2010/05/16(日) 10:12:45
面倒だから例外を投げるでいいよ
次は受け取る方法を書け
0886デフォルトの名無しさん2010/05/16(日) 10:17:36
>>885
おまえが書けｗ
0887デフォルトの名無しさん2010/05/16(日) 10:19:00
>>860
それCの仕様でも何でもなくて、x86ではたまたまそういう動作ってだけだべ
0888デフォルトの名無しさん2010/05/16(日) 10:23:02
キャッチもできずいきなりプロセス終了って怖すぎて使えないな。
0889デフォルトの名無しさん2010/05/16(日) 10:41:03
次スレは「【超光速】C/C++に代わる低脳言語を開発したい」な。
0890デフォルトの名無しさん2010/05/16(日) 10:44:23
>>887
お前x86しか知らないだろう？
0891デフォルトの名無しさん2010/05/16(日) 10:48:23
>>890
うん他の石はほとんど知らない
整数0除算を浮動小数点例外と同じ扱いにする石ってそんなに多いの？
0892デフォルトの名無しさん2010/05/16(日) 10:52:59
SIGNALを受け取った後例外を投げるとすれば例外の話になる

構文上は
1)C++,java,C#の例外を使う
2)Visual Basic の on error goto の改良
3)Scalaの例外的なものにする。マッチング構文的なものに
4)もっといい例外構文を作る
{
try =>
　a = 10 / 0;
case e@Exception(_) => println("zero divide");
}
と書けるとか。
0893デフォルトの名無しさん2010/05/16(日) 10:54:04
俺らにはできるな
0894デフォルトの名無しさん2010/05/16(日) 11:15:54
　　　　　　　　　　　 (＾G ＾)
＼(＾ J＾)×(＾ H＾)／ |　|＼(＾ D＾）／　俺たちならできる
　　 |　|　 　　|　|　　＜　＞　 |　|
　　<　 >　 ／　＞　　　　　 ／　＼

　　　　　　　　　　　　　　　　　　　　　　　　アイちゃん言語開発スレ
　　　　　　　　　　　　　　　　　　　　　　　　http://pc12.2ch.net/test/read.cgi/tech/1273199795/l50
0895デフォルトの名無しさん2010/05/16(日) 11:40:47
アイちゃんも応援しています
0896デフォルトの名無しさん2010/05/16(日) 11:44:55
>>891
石というよりOSの仕様だけど、たいていの場合Zero除算例外はSIGFPEだと思う
逆に浮動小数演算の例外は（デフォルトではCPU例外とならず）
SIGFPEにならないことが多い
0897デフォルトの名無しさん2010/05/16(日) 12:10:03
>>879
>さて、それは何進法で表現するのか？

数値の内部表現は実装依存だよ。コンパイラー屋さんが自由に決めていい。
言語仕様で規定することじゃないよね。

数値リテラルとしては、最低８進数と１０進数と１６進数は必要かな。
任意のN進数数値リテラルがあると便利かも。

>どのタイミングで確保、再確保するのか？

演算後、必要なときに、だね。

>そして10進数は現代でもすでに金融系で重要視されている

実用上はBCDだけあればいいんだろうけど、
数値の内部表現を任意N進数に指定できてもいいね。
0898デフォルトの名無しさん2010/05/16(日) 12:18:06
8進数リテラルって必要？
ファイルモードぐらいしか使ったことないんだけど・・
open(filename, O_CREAT, 0666)
0899デフォルトの名無しさん2010/05/16(日) 12:22:03
2進数リテラルは0b0000_0000って'_'を付けられると嬉しい
おれの自作処理系では受け入れる
0900デフォルトの名無しさん2010/05/16(日) 12:23:40
数値リテラルの区切り'_'は確かに欲しいかも。
0901デフォルトの名無しさん2010/05/16(日) 12:26:21
任意精度なんて可変長型や動的型付けと同じくらい効率悪そうだな
静的型付けで高速動作を期待する低水準言語には最もいらないものの一つだろう
0902デフォルトの名無しさん2010/05/16(日) 12:32:00
新言語は、低水準の記述”も”できる低水準言語だから、開発を容易にする高水準の記述も当然できるよ。
0903デフォルトの名無しさん2010/05/16(日) 12:36:19
>>902
>低水準の記述”も”できる低水準言語だから

日本語でおｋ
0904デフォルトの名無しさん2010/05/16(日) 12:37:37
ごめん。”は引用符で濁点じゃないよ。
0905デフォルトの名無しさん2010/05/16(日) 12:39:45
ぶっこみの択(なぜか変換できない)
0906デフォルトの名無しさん2010/05/16(日) 12:46:53
問題は名前をどうするかだ
特にイニシャルが重要だと思う

A awk ←Aは辞書順的にやっぱ強いよね。ここもありだよね
B basic
C C
D delphi
E erlang Eiffel
F FORTLAN F#
G golang
H HSP ←HSPと同じイニシャルはなんとなく嫌だよね
I ←ここだ！ここに空きがあるぞ
J java
K ←隣国を思い出すから使いたくないね
0907デフォルトの名無しさん2010/05/16(日) 12:50:09
>>906
@にして先頭ゲット
0908デフォルトの名無しさん2010/05/16(日) 12:50:11
>>906
ああ？Ioディスってんのか？！
0909デフォルトの名無しさん2010/05/16(日) 12:51:46
任意精度はライブラリだろ。
任意精度ライブラリが記述できるのが低級言語に課せられた使命。
0910デフォルトの名無しさん2010/05/16(日) 12:54:28
>>906
IChan
0911デフォルトの名無しさん2010/05/16(日) 12:54:35
>>908
IO(アイオー)とかぶってるから使いたくないよね
検索に引っかかる名前にするのは常識だよね
0912デフォルトの名無しさん2010/05/16(日) 12:55:31
asdfというのはどうだろう
0913デフォルトの名無しさん2010/05/16(日) 12:58:49
間をとってiM@Sで
俺は雪歩ライブラリを使う
0914デフォルトの名無しさん2010/05/16(日) 13:33:22
>>912
グンクツの音が聞こえる
0915デフォルトの名無しさん2010/05/16(日) 13:47:23
>>892
ということは例外はPHPの仕様でいいなw
0916デフォルトの名無しさん2010/05/16(日) 13:50:49
>>897
実装依存ねぇ
コンパイラが乱立するだけだろうねぇ
各型ごとに2進数型、10進数型というものをきめたほうが負担が減ると思うけどね
2進数型のdoubleはIEEE754規格に従うべきだね

http://ja.wikipedia.org/wiki/IEEE_754
0917デフォルトの名無しさん2010/05/16(日) 14:05:09
_
0918デフォルトの名無しさん2010/05/16(日) 14:48:45
まてまて、2進数"型"ってなんだ？2進数表記ってだけだろ？内部では全て2進数なんだから。

0b11111111 -> binary
0o777 -> octal
9999 -> dec
0xffff -> hex

とかを"ソース上で"表現できればいいだけだろ？
0919デフォルトの名無しさん2010/05/16(日) 14:52:09
レス嫁
0920デフォルトの名無しさん2010/05/16(日) 14:54:26
>>918
いや、少数の場合、内部表現の底によって無限小数になったりするんだよ。
例えば、１０進数の0.1は、２進数では0.000110011…の無限小数になる。
だから少なくとも実用上はBCD（Binaly Coded Decimal）のサポートがいる。
0921デフォルトの名無しさん2010/05/16(日) 14:55:09
Binaly → Binary
0922デフォルトの名無しさん2010/05/16(日) 15:13:11
10進数型のBCDではどのような分野で使われてるんですか？
0923デフォルトの名無しさん2010/05/16(日) 15:14:35
勘定系とか
0924デフォルトの名無しさん2010/05/16(日) 15:31:13
COBOLが使われているところ
0925デフォルトの名無しさん2010/05/16(日) 15:31:33
低級言語のスレじゃねえの
勘定系の話はいらんじゃろ
せいぜいオブショナルなデータ型があれば十分
0926デフォルトの名無しさん2010/05/16(日) 15:33:52
10進のハードウェアなら低水準でも10進型は必要だろ
0927デフォルトの名無しさん2010/05/16(日) 15:36:44
>>926
１０進ハードウェア用のデバイスドライバーを開発できればいいのであって、言語仕様に「１０進型」を含む必要はないのでは。
0928デフォルトの名無しさん2010/05/16(日) 15:42:51
なんつーか…会話してるように見えて実は座ってるフロアが違うっていう
B2Fで話してる人と31Fで話してる人では話がかみ合わないのも当然だな
0929デフォルトの名無しさん2010/05/16(日) 16:35:50
>>916
任意精度の話からなんでIEEE 754に結び付くのかよく分からないけど、
Cでいうfloat/doubleのような型はIEEE 754に従っておけばよいと言う点では同意。

CができたときはIEEE 754がなかったから、浮動小数点型の表現は実装依存とするしかなった。
C++もCと互換を取るためにそうせざるを得なかった。

しかし、IEEE 754ができてからは、CPUもそれに従うようになったし、
Javaなど後にできた言語も、浮動小数点数の内部表現は軒並みIEEE 754のものと仕様で規定している。
今度の言語もIEEE 754に従えばいいと思う。
0930デフォルトの名無しさん2010/05/16(日) 16:39:19
>>926-927
実際、十進浮動小数点演算を持っているCPU対象のGCCでは、
_Decimal64などそれ用のデータ型が使える。
0931デフォルトの名無しさん2010/05/16(日) 17:10:39
低水準にdecimal組み込んでも矛盾を起こさないからあってもいい。ライブラリで組み込んでも使いにくいし。
0932デフォルトの名無しさん2010/05/16(日) 17:34:48
たまにBCD接続な機器があったりするからな
8bitから64bitまで、CPUや構成もまちまちなのをカバーするには
オプショナルな部分は必須だな
0933デフォルトの名無しさん2010/05/16(日) 17:37:08
BCDだけでいい？
任意N進数型とかは要らない？
0934デフォルトの名無しさん2010/05/16(日) 17:38:13
なるほど。コンパイラ作る側ではめんどくなるし
つわなくていい人は関係ないけど、CPUにも機能があるから
言語仕様に入るべきってのは正論だと思います。
ライブラリで提供するとしたらライブラリで提供されていても
関数だけではなく演算子も使えるようになっていて欲しい。
関数だけで書け言われても、嫌だわ。
0935デフォルトの名無しさん2010/05/16(日) 19:27:49
任意N進はいらないんじゃね
BCDにしても必須てほど使われないしね
Decimal/Complexとかはあっても悪くない程度じゃないか
0936デフォルトの名無しさん2010/05/16(日) 19:47:49
ところで、新言語のVirtual Machineをどう実装するかお前らは考えたことはあるか？
0937デフォルトの名無しさん2010/05/16(日) 19:49:38
何のためにVMが必要なの？
0938デフォルトの名無しさん2010/05/16(日) 19:53:12
MMX・SIMD・SSEも使いたい
0939デフォルトの名無しさん2010/05/16(日) 19:55:36
いまどきの新言語はVM実装があたりまえ

PerlもC#もVMを実装
OS非依存目指すならそれくらいかないと
0940デフォルトの名無しさん2010/05/16(日) 19:59:09
そのPerlやC#が嫌だからこのスレがあるわけで
0941デフォルトの名無しさん2010/05/16(日) 20:29:41
高水準言語ならともかく、低水準言語にVMはないわ。
ていうかVMを実装するための言語。
0942デフォルトの名無しさん2010/05/16(日) 21:05:34
「低水準でも」使える言語なのでVMがあるのかどうかは関係ない。

それでもVM前提とか無いわ。
0943デフォルトの名無しさん2010/05/16(日) 21:21:17
>>939
で、何のためにVMが必要なの？
0944デフォルトの名無しさん2010/05/16(日) 21:36:58
Java, C#でさえ仕様上はVM必須というわけではないのに。
0945デフォルトの名無しさん2010/05/16(日) 21:40:30
共通の中間コードに一度変換した後に
その中間コードを各CPUにコンパイルするようにすれば
複数のCPUに対応したコンパイラが作成可能だ。
そこで共通の中間コードがネイティブで動く仮想マシンが必要になる。
0946デフォルトの名無しさん2010/05/16(日) 21:43:34
何で中間コードをそのまま動かそうとしてるんだよｗ

中間コードをさらに各CPUのネイティブコードにコンパイルするんだろ？
各CPUのネイティブコードとして動かせばそれでいいだろ
0947デフォルトの名無しさん2010/05/16(日) 21:54:36
基本レジスタ渡しな
レジスタは最低スタック用とフレーム用に2本かな
printfみたいな可変長引数はどうしようもないが
0948デフォルトの名無しさん2010/05/16(日) 21:55:15
C#のJITコンパイラは実際SSE2ありと無しでは吐くコードが違うからな
ぐぐってみ
0949デフォルトの名無しさん2010/05/16(日) 21:55:42
で？
0950デフォルトの名無しさん2010/05/16(日) 22:00:27
中間コードを考えるということは仮想的なマシンを考えるのと同義だ。
でも実装って書いてるな。むむぅ。
動的にコードを変更した最適化が可能だったりコードを小さく出来たり、
セキュリティ的にサンドボックスが作れるので
ネットワークでの配信が容易になったりするとか。
0951デフォルトの名無しさん2010/05/16(日) 22:00:32
LLVMでいいやん
0952デフォルトの名無しさん2010/05/16(日) 22:06:38
ネイティブコードを吐くコンパイラも、内部で中間コードにあたるものを生成していることを知らないらしい。
0953デフォルトの名無しさん2010/05/16(日) 22:06:41
ビットシフトを適当に使って書けば
最適化でビットローテート命令に使ってくれるかもしれないけど
言語側でビットローテート用の演算子がほしい
0954デフォルトの名無しさん2010/05/16(日) 22:15:04
>>953
どんな記号な演算子？
>>> <<< は算術ありなしとかだったから>>>> <<<<とか？
長いから >-> <-< とか？

0955デフォルトの名無しさん2010/05/16(日) 22:38:43
>rol>
>ror>
0956デフォルトの名無しさん2010/05/16(日) 22:59:00
頻繁に使うものじゃないし、ror()とかrol()とかの関数でいいんじゃないの？
0957デフォルトの名無しさん2010/05/16(日) 23:02:01
大抵はキャリーと組み合わせるから
キャリービットを扱う方法も欲しい
0958デフォルトの名無しさん2010/05/16(日) 23:07:32
またアホな話になってきたな
0959デフォルトの名無しさん2010/05/16(日) 23:11:16
(int a, bool carry) = a >ror> 3;
あるいは
(int a, bool carry) = ror(a, 3);
というかんじで使えるといいと。
0960デフォルトの名無しさん2010/05/16(日) 23:15:23
a >ror> 3
だと、 a > ror > 3　と区別がつかないのでいまいちじゃない？
記号のみの組み合わせにするとか、``でくくって`ror`にするとか
ror だけにするのがいいと思うよ。
0961デフォルトの名無しさん2010/05/16(日) 23:24:12
次スレ

【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/
0962デフォルトの名無しさん2010/05/16(日) 23:27:07
<@ >@
だな
顔文字か作れる言語にしようぜ
0963デフォルトの名無しさん2010/05/17(月) 02:00:37
とりあえずschemeでプロトタイプでも作るか
0964デフォルトの名無しさん2010/05/17(月) 02:18:18
期待してる
0965デフォルトの名無しさん2010/05/17(月) 07:08:34
S式の呪縛に囚われてはCに変わることは出来ないぞ
0966デフォルトの名無しさん2010/05/17(月) 07:27:01
反発も半端じゃないけどガンバレ！
0967デフォルトの名無しさん2010/05/17(月) 13:02:37
ああまだ5が残ってたのか

6に書いたけどニーモニック云々
0968デフォルトの名無しさん2010/05/18(火) 01:09:26
このスレの目指す言語はgolangじゃないかという気がする
並列処理組み込んでるし、ガベコレもあるし
0969デフォルトの名無しさん2010/05/18(火) 02:45:25
俺もそんな気がする
どうせ作らないだろ
0970デフォルトの名無しさん2010/05/18(火) 03:23:16
やっぱgoだよな
ガベコレ無しのgoが理想的なんだがな
0971デフォルトの名無しさん2010/05/18(火) 03:24:50
あとはWiring程度すら使いこなせねえレベルのもいるな
低レベルってのが俺からしたらドバイタワーの頂上みたいに見える話が多いし
0972デフォルトの名無しさん2010/05/20(木) 23:35:02
LISP民族とかLL民族がここぞとばかりに、
自分たちの言語に入ってる機能をねじ込もうとしているからな。
0973デフォルトの名無しさん2010/05/21(金) 00:27:45
蛮族に作法を教えてやってるのだ
0974デフォルトの名無しさん2010/05/21(金) 00:28:57
ねじ込ませたいと思うほどの機能なら、検討する価値がある。
0975デフォルトの名無しさん2010/05/21(金) 01:09:42
>>974
彼らはOSやドライバの仕組みを知らない。
0976デフォルトの名無しさん2010/05/21(金) 01:18:32
すべてを知っているのであれば、情報交換なんて必要ない。

自分が提供できるものを提供し、雑多な情報の中から自分に必要なものを拾うことで、高め合うことができる。
0977デフォルトの名無しさん2010/05/21(金) 01:20:39
妄想垂れ流して情報クレとな
0978デフォルトの名無しさん2010/05/21(金) 01:24:44
>>974
バカに混じれ酢するのもどうかと思うけど、
ＬＩＳＰやＬＬはアセンブラと相性悪いんだよ。
0979デフォルトの名無しさん2010/05/21(金) 01:27:11
と言って思考停止
0980デフォルトの名無しさん2010/05/21(金) 01:33:48
という類の発言は無意味である
0981デフォルトの名無しさん2010/05/21(金) 01:35:46
俺もそう思う。
0982デフォルトの名無しさん2010/05/21(金) 02:15:21
>>977
不覚にもわろた
0983デフォルトの名無しさん2010/05/21(金) 02:16:54
goはastがライブラリに入ってるから遊べるぞ
レス数が950を超えています。1000を超えると書き込みができなくなります。