2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん: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/

2 :デフォルトの名無しさん:2010/05/07(金) 11:37:28
◆新言語の要件 v0.1◆

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


◆主な要望◆

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

3 :デフォルトの名無しさん:2010/05/07(金) 11:40:03
286* 名前:デフォルトの名無しさん [] 投稿日:2010/04/27(火) 19:07:54
C言語の問題点。
1、コンパイラを軽く書きたいので色々端折ってる
2、軽く書きたいと良いながら、先読みが必要だったりする
3、軽く書けるので膨大な方言が発生し、それの取りまとめで仕様がボロボロ
4、機能の追加が必要最小限に留められているので、色々中途半端

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

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

そこで、プログラミング言語40年の歴史から学べる知見を総動員して、
C言語的なプログラミング言語を過去の遺産にとらわれず、今、開発
するとすればどんな仕様になるのだろうか?という事。

4 :デフォルトの名無しさん:2010/05/07(金) 11:42:16
450 名前:デフォルトの名無しさん [sage] 投稿日:2010/04/30(金) 16:32:34
GC有り言語とGC無し言語ではメモリに関する考え方がまるで違うから、
学習者からすれば一つの言語に混在するのは良くないんじゃないかな。

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

良い言語の条件は、
・読みやすい・メンテしやすいこと(他人の書いたperlコードなんて読みたくない)
・ライブラリが充実してること(画像読み取りぐらいは標準ライブラリに欲しい)
・熟練者じゃなくてもミスのないプログラムが書けること
なんじゃないかなと思う。

5 :デフォルトの名無しさん:2010/05/07(金) 11:48:25
◆新言語の位置づけ◆

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

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

6 :デフォルトの名無しさん:2010/05/07(金) 11:48:50
えらい早漏さんだな

7 :デフォルトの名無しさん:2010/05/07(金) 11:49:39
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

8 :デフォルトの名無しさん: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毎に異なってるのが組み込み屋の悩みだな
メーカ提供のライブラリの出来も千差万別だし
言語の話と離れるが、共通化してくれたらいいのにね

9 :デフォルトの名無しさん:2010/05/07(金) 11:50:40
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

10 :デフォルトの名無しさん:2010/05/07(金) 12:01:59
新しい言語はGoogle GoやDに勝たないとダメだと思う


11 :デフォルトの名無しさん:2010/05/07(金) 12:04:59
とりあえず新言語名はI言語(アイ言語)にしませう

12 :デフォルトの名無しさん:2010/05/07(金) 12:10:59
Mona OSとかもあるし、
Mona言語とかしぃ++(thi++)言語でいいんじゃね?

13 :デフォルトの名無しさん:2010/05/07(金) 12:36:48
Monoでも良いぞ

14 :デフォルトの名無しさん:2010/05/07(金) 12:38:44
i-Mono

15 :デフォルトの名無しさん:2010/05/07(金) 12:50:23
Programming Language I に決定。

16 :デフォルトの名無しさん:2010/05/07(金) 13:07:32
>>1
速度にこだわった低級言語といえばアセンブラ

17 :デフォルトの名無しさん:2010/05/07(金) 13:08:26
>>5
文法はJavaベースで

18 :デフォルトの名無しさん:2010/05/07(金) 13:10:38
自分がコンピュータ史上の人物として名を残したいのは分るけど
スレタイの事に労力を費やすなら、Dとか有望株を改良したりドキュメントを翻訳したり
積極的に採用して著名なアプリを作るとかしたほうがいいとおもうんだが。
こんな事は5スレ目だから、何度も言われているかな?

19 :デフォルトの名無しさん:2010/05/07(金) 13:12:53
>>18
何を言っているんだ。このスレッドは雑談スレッドだぞ。
新しい言語を作るという妄想に浸りながら雑談するのが正しいスタイルだ。
新入り君はそこのところ勘違いしないほうがいい。

20 :デフォルトの名無しさん:2010/05/07(金) 13:13:16
>>18
その発想は無かった

21 :デフォルトの名無しさん:2010/05/07(金) 13:13:24
1スレの>>1はもういないだろ。
今は、話題に集まった奴が適当なことを言い合ってるだけ。

22 :デフォルトの名無しさん:2010/05/07(金) 13:15:56
>>18
そんな色気は仕様が固まってから考えれば良いこと。
Dで良いと思う人はDに行けば良い、
Cで良いと思う人はCを使えば良い、
LWLが好きな人は好きで居続ければ良い、
COBOLしか分からない人はそれで良い、

23 :デフォルトの名無しさん:2010/05/07(金) 13:22:55
私見、
Dの問題点、CのリプレイスではなくてC++の置き換えを目指してる、
曰く、Cとして読める構文はCと同じ動きをする事等など。

Cの問題点、既出

LWLの問題点、論外、
JAVAの問題点、論外、
COBOLの問題点、論外。
これらはランタイムを必要とする。

関数型言語、論外
Cの代替を目指す言語にはならない。


24 :デフォルトの名無しさん:2010/05/07(金) 13:28:50
>>23
COBOLってランタイムいるの?

25 :デフォルトの名無しさん:2010/05/07(金) 13:29:26
Cにだってcrtというランタイムがあるんだが

26 :デフォルトの名無しさん:2010/05/07(金) 13:30:32
>>24
主にI−Oセクションだけどね。

27 :デフォルトの名無しさん:2010/05/07(金) 13:31:56
・enumがいいかんじにswitch周りで使えるといいな。
・3項演算子はif式がよいんだか、よくないんだか?
・多値があるとよさそう。
・インクルードは自動生成がいい。

っていうかんじですか?


28 :デフォルトの名無しさん:2010/05/07(金) 13:33:45
・インクルードは不要。自動生成してもいいが必須ではない。

29 :デフォルトの名無しさん:2010/05/07(金) 13:34:00
>>27
>・多値があるとよさそう。
おいらはこれに反対なんだけど、議論にならないので放置してる(w

30 :デフォルトの名無しさん:2010/05/07(金) 13:35:37
・多値の戻り値は、一つのリスト型で行う。リスト型から要素を取り出す暗黙のキャストがあってもいい。

31 :デフォルトの名無しさん:2010/05/07(金) 13:40:00
多値はリストじゃなくてタプルだろう。
もっというとstructだろう。って言い出すとまた前スレッドを蒸し返せるよ

32 :デフォルトの名無しさん:2010/05/07(金) 13:46:20
関数に多値を許すことの最大の欠点は、C言語とバイナリー互換が
取れないこと。文法がC言語と違ってもC言語と同じ形式のバイナリー
フォーマットを維持できれば、旧来の資産を継承できるんだけどね。

まぁその辺はトレードオフなので、多値戻しが好きな人はそっちで煮詰めて欲しい
と思う。頑張れって思う。良い仕様が出来たら説得されちゃう用意は何時でもある。
だけど今の議論はちょっと、あり得ない、LWL作ってるのか?とか思う。(wwww

33 :デフォルトの名無しさん:2010/05/07(金) 13:50:22
C側から新言語によるオブジェクトを呼び出させい場合は、単値のみにするとか、ラッパーを作るとか、何かすればいいんじゃないの。

既存の言語の古い制約に引きづられて、新言語の仕様を妥協はしない方がいい。

34 :デフォルトの名無しさん:2010/05/07(金) 13:54:31
>>33
きみがそのらっぱーなら、どうぞ、どうぞ。
ちぇけらっちょ♪

35 :デフォルトの名無しさん:2010/05/07(金) 13:59:34
(゚听)ツマンネ

36 :デフォルトの名無しさん:2010/05/07(金) 14:02:47
俺も多値は要らんけど、Cとのバイナリー互換とかで妥協する必要はないと思うな。

37 :デフォルトの名無しさん:2010/05/07(金) 14:06:44
structで返却するってインタフェースにすればいいじゃん。
どうせ多値なんだから返却する型の順序は決まっているわけで。

38 :デフォルトの名無しさん:2010/05/07(金) 14:07:40
>>36
OSから全部作り直しになるけど、頑張ってください。
確かに意欲的な方向で考えるのは悪くはないと思うんですよ。
そこまで見えてやり遂げるつもりなら誰も止めません。

39 :デフォルトの名無しさん:2010/05/07(金) 14:10:57
structでもリストでもタプルでも呼び名は何でもいいけど、
順序付きの複数の値をまとめられるデータ構造のリテラルがあればいいね。

C++的には「初期化リスト」と呼ぶけど、「リスト」という呼び名が嫌なら別にポチでもミケでも何でもいい。
とにかく、そういうものが欲しい。

40 :デフォルトの名無しさん:2010/05/07(金) 14:12:50
>>38
その「作り直さなければいけないOS」とやりとりをしたいときだけ、多値を使わなければいいだけじゃん。
多値があるからOSから全部作り直しになるなんてことはないよ。

41 :デフォルトの名無しさん:2010/05/07(金) 14:13:03
>>39
提案コードを書いてみては?議論はそこからかな?

42 :デフォルトの名無しさん:2010/05/07(金) 14:17:00
OSはコーリングコンベンションと関係なかんべ

43 :デフォルトの名無しさん: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)、剰余は捨てられる

多値内の要素の指定方法は要検討だが。。

44 :デフォルトの名無しさん:2010/05/07(金) 14:28:47
>>43
無名構造体って感じなんだけど色々突っ込む前に。
てか突っ込めるほど堅くなさそうな気が。

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

こう言うのを一回でUP出来ると、あぁこの人は考えてるなー
って思う。

45 :デフォルトの名無しさん:2010/05/07(金) 14:34:14
>>44
だから、名前は何でもいいよ無名構造体でもミケでもタマ。

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

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

構文についてはもう少し考えないとね。

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

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

もちろん、その考えが駄目かも知れないんだから、
こうやって議論するんだけど、何も考えずに欲しいとか
まだ考えてないけど欲しいってのは、議論じゃねーですよ?


47 :デフォルトの名無しさん:2010/05/07(金) 14:39:12
>>46
あなたがそうしたいならあなた自身その方針でどうぞ。

欲しい物を欲しいと表明するのは別に問題ないよ。

48 :デフォルトの名無しさん: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)と出来るのでは。 {} が無名構造体を作るという
流れに一貫して奇麗だと思うんだけど。


49 :デフォルトの名無しさん:2010/05/07(金) 14:40:28
考えているからある程度の例が出てくるのであって、
突っ込みどころ見つけてケチつけるのは、議論じゃねーですよ?


50 :デフォルトの名無しさん:2010/05/07(金) 14:45:33
>>48
構造体(のポインタやリファレンス)を返す事と見比べると、
あやふやな点が増えるだけに感じるのだが?

今までどおり構造体返しより得られるメリットは何?


51 :デフォルトの名無しさん:2010/05/07(金) 14:45:48
>>48
それだと、div_tを宣言しなければいけないのが、ちょっと美しくない感じが。

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

だから、divの戻り値の方も無名にしたいかな。

52 :デフォルトの名無しさん: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()は構文糖で同じ意味って感じはどう
多値返しは使い方次第とはいえたいして重くはならないと思う

どうせならちょい違うが積和演算も出来たら面白いなw

53 :デフォルトの名無しさん:2010/05/07(金) 15:00:38
>>52
> v,r = a /% b

これいいな。MISD(Multi Instruction Single Data)だな。

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

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

54 :デフォルトの名無しさん:2010/05/07(金) 15:03:06
MISD?
普通に割り算インストラクションは商と剰余を同じ返す奴が多いから
それをイメージしてるだけだけどw

55 :デフォルトの名無しさん:2010/05/07(金) 15:04:53
ていうか通常の割り算のアルゴリズムでは
商と剰余は同じに求まるんだよなw

56 :デフォルトの名無しさん:2010/05/07(金) 15:06:32
>>55
まあ、割り算は分かりやすいから例として使っているだけだろw

57 :48:2010/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)


58 :デフォルトの名無しさん:2010/05/07(金) 15:09:19
>>53
関数を置けるところに関数のリスト置けてもいいな。

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

それをパラに処理してくれると嬉しい。


59 :デフォルトの名無しさん:2010/05/07(金) 15:10:57
>>50
> 今までどおり構造体返しより得られるメリットは何?

オサレでかっこいい。

60 :デフォルトの名無しさん:2010/05/07(金) 15:12:47
汚いExceptionを少なくしてちゃんとエラー返すのに
多値があったらいいんよね
Cは本来の値以外に特殊な値を定義したり
変なグローバル変数を使ったりするからイマイチ
golangみたいな ret, ok = foo()記法は慣れると結構わかりよい

61 :デフォルトの名無しさん:2010/05/07(金) 15:17:59
>>60
それいいな(゚A゚;)ゴクリ

62 :デフォルトの名無しさん:2010/05/07(金) 15:23:04
>>60
例外処理の使い勝手の悪さ問題だよね。
例外処理が使えればエラー値戻しは
必要ないと思うんだが。

多値戻しは鬼門になりそうな気がするんだけどなぁ。


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


64 :デフォルトの名無しさん:2010/05/07(金) 15:31:15
> 多値戻しは鬼門になりそう

しかし、Python, Ruby, Goとすでに使われてるよね。 他にもあったっけ?

65 :デフォルトの名無しさん:2010/05/07(金) 15:36:49
Lisp

66 :デフォルトの名無しさん:2010/05/07(金) 15:39:23
Lispと言ってもいろいろだろw

S5R5は多値に対応してるな。

67 :デフォルトの名無しさん:2010/05/07(金) 15:40:34
Common Lispも多値に対応してるよ。

68 :デフォルトの名無しさん:2010/05/07(金) 15:42:10
PythonやRubyはタプルみたいな奴で単値返しじゃないか?
構文的には多値風だけど。

69 :デフォルトの名無しさん:2010/05/07(金) 15:43:07
なんでもいいよ。構文的に多値に見えれば。

70 :デフォルトの名無しさん: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)


つまり、タプルを複数の変数に代入出来るという機構があるだけという感じですね。

71 :デフォルトの名無しさん:2010/05/07(金) 16:49:00
>>70
他意のない単なる質問だけど、その「タプル」とLispのリストって機能的な違いってあるの?同じもの?

72 :デフォルトの名無しさん:2010/05/07(金) 17:18:31
Pythonについていうと似たようなもんだが
タプルは変更付加
ちょい汚いけどC++0xにも導入されてるね

73 :デフォルトの名無しさん:2010/05/07(金) 17:21:17
ごめw不可ねw


74 :デフォルトの名無しさん:2010/05/07(金) 17:23:59
>>72
なるほど。ありがとう。

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

慣れなのかもしれないけどね。

75 :デフォルトの名無しさん:2010/05/07(金) 17:30:03
リストがlisp的なリストのことなら通常リスト自体は変更可能なデータ型でしょ
タプルは作ったら変更不可で自身も無名、メンバーも無名なstructって感じと思えばいい

76 :デフォルトの名無しさん:2010/05/07(金) 17:31:33
>>72
ビックリしたぁ、標準ライブラリじゃん。

77 :デフォルトの名無しさん:2010/05/07(金) 17:38:12
そそ。C++らしく汚物的に汚いけどねw

78 :デフォルトの名無しさん:2010/05/07(金) 17:43:32
タプルをリストに代入できるが、リストをタプルに代入できるとは限らないってことでおk?

79 :デフォルトの名無しさん:2010/05/07(金) 18:04:43
>>77
言語の話してるときに標準ライブラリの話持ち出さない
程度の、なんかは無いのか?

80 :デフォルトの名無しさん:2010/05/07(金) 18:05:46
>>18
名を残すなんて用意ではないぞ。
まつもとゆきひろのようになるのも大変かと。
ましてやオブジェクト指向言語を作るとなると
コンパイラコンパイラで作るのもものすごい苦労するのではないかと。
Java言語を作った集団は10年以上もかけて研究してきた研究者だからな。
Javaを超える言語を作るのも至難の業。

81 :デフォルトの名無しさん:2010/05/07(金) 18:06:51
>>23
C++がOKでJavaが論外というのが矛盾だらけだ。
JavaはJVMなしでネイティブで動かすこともできるのだが。

82 :デフォルトの名無しさん:2010/05/07(金) 18:09:26
>>27
どうせならJavaのenum以上に高機能であることが望ましいな。
interfaceを実装できてクラスのように扱うことができジェネリックス(テンプレート)も使える。
そして列挙変数にメソッドを持たせることもできる。
JavaのenumはC++やC#のenumとも異なる超高機能列挙型だから
それを超えるenumが欲しい。
includeよりimportとpackage(namespace)のほうがいい。
ディレクトリやファイルパスという方式はヘッダファイル地獄に陥る。

83 :デフォルトの名無しさん:2010/05/07(金) 18:11:07
>>30-31
リスト型、structというかオブジェクト(class)で返すべき。
C++STLのvector型、JavaのListオブジェクト(型)のように。
そして当然ながらGenerics(template)と併用できる。

84 :デフォルトの名無しさん:2010/05/07(金) 18:11:21
何回自慢げに同じ話ばかりすれば気がすむんですか?

85 :デフォルトの名無しさん:2010/05/07(金) 18:12:27
低水準ってキーワードを無視しまくったレスを付けてる奴は頭悪い。

86 :デフォルトの名無しさん:2010/05/07(金) 18:12:50
>>39
C++STLのvectorやJavaのjava.util.Listオブジェクトの真似をすることの何が不満なんだ
配列で返してもいいし、オブジェクトで返してもいい。

87 :デフォルトの名無しさん: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;
}

88 :デフォルトの名無しさん:2010/05/07(金) 18:23:02
>>52
> 多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
> v,r = a /% b
それを許すと
v= 1, r = a / b;
という記述(C言語のv = 1; r = a / b;と同じ)がかわってしまうが、その点はどう対応する?
途中改行を許さないという文法にでもする?

89 :デフォルトの名無しさん:2010/05/07(金) 18:24:29
>>60
例外処理に不満があるならC#の真似をしてみては。
あれはあれで問題を起こし、Java方式とC#方式で賛否両論があるが

90 :デフォルトの名無しさん:2010/05/07(金) 18:25:51
>>85
低水準といっておきながらC++に変わる言語を作れっていう時点で
無理がある

あるていど高級言語にせざるをえないんでは。
しかも例外処理の話までしてる。

91 :デフォルトの名無しさん:2010/05/07(金) 18:29:29
>>88
, で式をつなげるのは無しにすればいいかな。

92 :デフォルトの名無しさん:2010/05/07(金) 18:30:58
>>90
低水準に”も”使えればいいんだよ。無理はないよ。

93 :デフォルトの名無しさん:2010/05/07(金) 18:31:57
スレタイに、C++が入っているのがそもそもの間違い。C++にかわる言語はいくらでもある。
次のスレは、C++をはずそう。

94 :デフォルトの名無しさん:2010/05/07(金) 18:35:37
>>86
返り値を多値型にキャスト出来れば、別に何を返してもいいよ。

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

で、func()の戻り値の配列なりオブジェクトなりの要素を何らかの法則に従って順序付けて並べたときの1,2,3,4番目の要素を、a,b,c,dに代入できればいい。

95 :デフォルトの名無しさん:2010/05/07(金) 18:37:58
>>88
ちょっとウザイけど
c = 1, [v,r] = a/b;
とかでもいいかな。

96 :デフォルトの名無しさん:2010/05/07(金) 19:17:43
>>88
Cのカンマ演算子は中途半端だから廃止でいいんじゃない
複数の式を1つにまとめるのといろんなもんの区切りが同じ,ってのは
いまいちな感じしないかな
forとか考えるといい構文も思いつかないんだけどw

97 :デフォルトの名無しさん:2010/05/07(金) 19:19:25
(v = 1; b = 2)なんて言うのが式として有効ならいいかも


98 :デフォルトの名無しさん:2010/05/07(金) 19:23:19
>>79
ああ。確かにライブラリだな
でもC++0xそのままは汚いっていうのはそういうのも込みの印象ね
無名、メンバー無名のstruct的なデータ型はFirst Classとして
アリなんじゃないかと思ったからさ


99 :デフォルトの名無しさん:2010/05/07(金) 19:26:58
前スレ埋めろよ

100 :デフォルトの名無しさん:2010/05/07(金) 19:27:08
>>98
C++は過去を引きずり過ぎてあんな感じにならざるをえないんだろうね。
そういう意味で、新言語は過去に引きずられて妥協することのないようにしたい。

101 :デフォルトの名無しさん:2010/05/07(金) 19:28:45
>>100
ぶっちゃけいうと俺はCとgolangでいいとおもってるけど
C++とかいらねw
でもスレはネタとして楽しんでるよ

102 :デフォルトの名無しさん:2010/05/07(金) 19:43:26
CとC++を比較すると
両者とも過去を引きずっているが、C++だけが未来に拘わりすぎてあんな感じ
というのが正しい

103 :デフォルトの名無しさん:2010/05/07(金) 19:44:42
純粋に未来だけにこだわったC++も見てみたいな。
ある意味、この新言語なんだけど。

104 :デフォルトの名無しさん:2010/05/07(金) 19:57:08
「便利」でかつ「低水準」を同時に満たす言語を目指すこと自体が
かなり至難の業だと思うんだが
「便利」と「低水準」はほとんどトレードオフで反比例の関係に位置するといってもいい
よほど意表をつくほどの斬新な発想でもしない限り厳しいのではないだろうか


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

>>100
しかし過去を切り捨てると低水準言語の仕様を廃したJavaのような高級言語になってしまう。
過去を残したからこそC++も低水準言語として扱うことができる。
このトレードオフな関係をどうにか解決しないことには「低水準言語」の過去を廃してオブジェクト指向言語のような
便利な言語でかつ低水準言語を作るのは難しいのでは。

105 :デフォルトの名無しさん:2010/05/07(金) 19:57:48
>>103
未来にこだわっただけのC++=Java、C#、D言語
ではないのか。

106 :デフォルトの名無しさん:2010/05/07(金) 20:02:03
>>105
それは違うかな。右辺の言語はCの置き換えにならない。

107 :デフォルトの名無しさん:2010/05/07(金) 20:12:27
Cでできることすべてできないと気が済まないのか

108 :デフォルトの名無しさん:2010/05/07(金) 21:10:41
Cに代えたいのかCと互換性を持たせたいのか不明

109 :デフォルトの名無しさん:2010/05/07(金) 21:59:03
新言語ではCでできることは全てカバーしたいね。

110 :デフォルトの名無しさん:2010/05/07(金) 23:10:25
>>109
それはかなり無謀かと
C++の二の舞だ

111 :デフォルトの名無しさん:2010/05/07(金) 23:11:11
C99でできることぐらいはカバーしておきたい

112 :デフォルトの名無しさん:2010/05/07(金) 23:24:56
>>110
C++と違って、新言語にはCとの互換性はいらないよ。
「Cでできること」というのは「Cでの開発対象となっている分野」のこと。
だから何も無謀じゃない。

113 :デフォルトの名無しさん:2010/05/07(金) 23:27:19
Cを使うよ

114 :デフォルトの名無しさん:2010/05/07(金) 23:29:47
マシンコードに対してCが写像であるということに、うんたらかんたら

115 :デフォルトの名無しさん:2010/05/07(金) 23:36:05
だからクロージャはサポートされないわけだ。

116 :デフォルトの名無しさん:2010/05/07(金) 23:38:15
クロージャーはサポートしてもいいんじゃないの。流行りだし。

117 :デフォルトの名無しさん:2010/05/07(金) 23:38:33
>>112
> 「Cでできること」というのは「Cでの開発対象となっている分野」のこと。

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

今となってはCの出番は
ほとんどそういう分野に限られてないか?

118 :デフォルトの名無しさん:2010/05/07(金) 23:39:53
>>117
そういう分野を、最近のオサレ機能を交えつつ開発できたら、気分いいよね。

119 :デフォルトの名無しさん:2010/05/07(金) 23:43:43
>>117
その分野の開発を行えることが絶対条件で、さらに上位の開発にも使えたらなお良い。

120 :デフォルトの名無しさん:2010/05/07(金) 23:47:17
二兎追う者はなんたらかんたら

121 :デフォルトの名無しさん:2010/05/07(金) 23:50:47
優先順位が付いているからその指摘には当たらないのでは。

122 :デフォルトの名無しさん:2010/05/07(金) 23:52:52
クロージャの考え方を考えようぜ。

実際にはcはフラットな構造をしているから、手続き+環境というのはあんまりメリットないんだよね。
もしクロージャを取り込むんだったら、環境と手続きのセットを一級市民化する意味を考えないとムダだよ。


123 :デフォルトの名無しさん:2010/05/07(金) 23:53:05
C++が糞と言われながら普及したのは結局Cとの互換性があったからだ

124 :デフォルトの名無しさん:2010/05/07(金) 23:55:01
普通のクロージャと同等に使い勝手が良いものが欲しければGC必須でしょ
GCで管理されてるからこそ、環境(自由変数)が暗黙にクロージャに
キャプチャされても、ユーザは寿命の問題をいっさい気にしないで済む

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

クロージャでなくて単なる関数リテラルなら、ありだと思うよ

125 :デフォルトの名無しさん:2010/05/07(金) 23:55:02
>>122
「フラットな構造」ってどいうこと?

126 :デフォルトの名無しさん:2010/05/08(土) 00:05:28
写像

127 :デフォルトの名無しさん:2010/05/08(土) 00:10:02
結局の所今あるもので十分なんだろう

ネタに走った方が精神的に充実すると思うんだが

128 :デフォルトの名無しさん:2010/05/08(土) 00:15:15
それは、オナニーだよ。

129 :デフォルトの名無しさん:2010/05/08(土) 00:35:13
>>124
そうそう。まずCで一番じゃまっけなのがオブジェクトの寿命だ。

いろいろ考えると
現代のVM上での開発はかなり合理的だといえるね。

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

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

>129
それだとVMに制限されるだろ。VM自体が軽量でポータブルならともかく。
Forthみたいに全部スタックに積むという手もあるよ。

131 :デフォルトの名無しさん:2010/05/08(土) 00:55:22
GC入れるのはいいけど、従来のC言語と同様に手動管理も
出来る自由度は欲しい

言語仕様には両方実装しておいて、必要に応じて切り替えられる、
という感じでいいかと

132 :デフォルトの名無しさん:2010/05/08(土) 00:58:43
参照カウンタじゃダメで、GCが必要なのって、循環参照がある場合だけかな?
他にもあるの?

133 :デフォルトの名無しさん:2010/05/08(土) 00:58:58
とりあえずころころソート基準が変わる
ソート関数ポインタを作りたいんだが、どうすればいい?

134 :デフォルトの名無しさん:2010/05/08(土) 01:00:29
まだGCとか言ってるバカがいるのか…
高級言語からのトップダウンじゃなくて、機械語やアセンブリからのボトムアップで考えろよ
じゃなきゃCの代替になんてなれるわけがない

135 :デフォルトの名無しさん:2010/05/08(土) 01:01:26
>>130
真っ当マクロ路線なら前スレで
出てたCをLispにした奴だね。あれがいい。

136 :デフォルトの名無しさん:2010/05/08(土) 01:02:43
>>134
良いこと言うね

137 :デフォルトの名無しさん:2010/05/08(土) 01:04:16
>>132
参照カウンタはスレッドセーフにしずらい

138 :デフォルトの名無しさん:2010/05/08(土) 01:05:03
>>137
なるほど。たしかに。

139 :デフォルトの名無しさん:2010/05/08(土) 01:06:56
多値なんて無ければ無いでいいし
クロージャ、GC、VMは論外だろう
結局このスレ、俺構文オナニーショーなんだな

140 :デフォルトの名無しさん:2010/05/08(土) 01:08:38
ぶっちゃけ、最終的にはgo言語になる気がする

あるいはgo言語のマイナーチェンジ版に

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

142 :デフォルトの名無しさん:2010/05/08(土) 01:11:40
「言語自体はGCサポートして」というのは語弊があった。

「言語自体はオブジェクトの寿命管理を処理系にお任せできるようになっていて」…って方がいいね。


143 :デフォルトの名無しさん:2010/05/08(土) 01:13:01
GCの根本的な問題は「誰がリソースを管理するか」ということだよ。
GCをサポートするのならばリソース管理はGCにまかせるべきで、GCを使わないならばプログラマがちゃんと管理すべき。
オプションで切り替えるようなものじゃ無いよ。


144 :デフォルトの名無しさん:2010/05/08(土) 01:15:00
>>143
限界ギリギリまでGCを使わないで、処理系にオブジェクトの管理をお任せすることって出来ない?

どうしてもダメなときは、コンパイラが「ごめんなさいGC使わせてください」って言うの。

145 :デフォルトの名無しさん:2010/05/08(土) 01:15:04
>>141
CにGCライブラリをリンクするのとどう違うのかね?
それにGCが必要かどうかの自動判断は無理

146 :デフォルトの名無しさん:2010/05/08(土) 01:17:33
>>145
まさに処理系に「GCが必要かどうかの自動判断」をさせたいんだけど、無理なの?何ゆえ?

147 :デフォルトの名無しさん:2010/05/08(土) 01:18:33
そんな切り替えができたら他の言語でとっくにやってるでしょ
ちなみにGCを起動させないことはできるよ

148 :デフォルトの名無しさん:2010/05/08(土) 01:21:06
>>147
確かに。
他でやっていないから、出来ないってのは確かに消極的な証明にはなるね。

次なる目標は、なるべく同じ構文のまま、GCをON/OFFできるようにする。
ってとこかな。

149 :デフォルトの名無しさん:2010/05/08(土) 01:23:20
つーか何でそんなにGCを欲する?
10年以上CプログラマやってるがGC欲しいと思ったことなんて1度も無かったが

150 :デフォルトの名無しさん:2010/05/08(土) 01:24:25
>>149
Cが何かとめんどくさくてインポテンツだから

151 :デフォルトの名無しさん:2010/05/08(土) 01:25:44
>>149
ライブラリ作ってて、毎度毎度create-deleteペアを作ってやらなきゃいけないのに辟易したりしなかった?

152 :デフォルトの名無しさん:2010/05/08(土) 01:33:37
>>151
それぞれのcreateとdeleteで違う処理をしなきゃいけないのに辟易も何もないわ
ただ解放すりゃいいなんて単純なライブラリは作らなかったし

153 :デフォルトの名無しさん:2010/05/08(土) 01:33:50
>>148
停止性問題と同じくGCが必要か否かを証明する方法はない
単に不要と判断するならGCを殺せばいい

154 :デフォルトの名無しさん:2010/05/08(土) 01:35:58
>144
>「GCが必要かどうかの自動判断」

自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。
コンパイル時に全部スタックに乗っているかどうかをチェックさせるという手もあるとは思うけど、
それならGC自体が不要だわな。


155 :デフォルトの名無しさん:2010/05/08(土) 01:36:16
そして再開する俺構文オナニーショー!!!!

↓最初の方、どぞ

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

GCにGCの必要性は証明できないかもしれないけど、コンパイラーがGCの必要性を証明できないって事にはならないのでは。

157 :デフォルトの名無しさん:2010/05/08(土) 01:44:16
>>154
> 自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。

いや、「GCが必要かどうかの自動判断」というのは、リソースの生死の確認ではなく、リソースの生死の確認が必要かどうかの確認だよ。
後者にはGCは必要ないよね?

158 :デフォルトの名無しさん:2010/05/08(土) 01:46:12
GC回収対象のオブジェクトを作らなければ不要でしょ
malloc使わなければfreeいらないのと同じ

159 :デフォルトの名無しさん:2010/05/08(土) 01:57:33
>157
>リソースの生死の確認が必要かどうかの確認

所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。
結局プログラム自体を実行させる必要が出てきて、やっぱりGC回さなきゃ判らんよね、ということになるよ。


160 :デフォルトの名無しさん:2010/05/08(土) 01:59:34
>>159
> 所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。

このあたりがもう少し具体的になると議論が深まるかも。

161 :デフォルトの名無しさん:2010/05/08(土) 01:59:56
GCがあると便利な場合は当然あって、それはそれでいいと思う。
ただ、一部のCユーザにはGC無しで自分でメモリ管理をする方が望ましいわけでしょ?
だったら両方できればいい

162 :デフォルトの名無しさん:2010/05/08(土) 02:06:45
Garbage Collection (GC)について語るスレ
http://pc12.2ch.net/test/read.cgi/tech/1141646850/

163 :デフォルトの名無しさん:2010/05/08(土) 02:08:16
>>159
GCを回しても、所有者のハッキリしないリソースがあるかどうかというのはわからないのでは。
GCで知れるのは、リソースの所有の有無と、所有者だよね?
所有者がハッキリするかどうかは別の問題ではないかと。

164 :デフォルトの名無しさん:2010/05/08(土) 03:01:11
>160
リソースの管理に関しては主に確保->(保持<->譲渡)->放棄という局面があるわけなんだけど、それらを紐付けて
関連付けるのはなかなか難しいことで。
あるオブジェクトが確保したリソースを複数のオブジェクトで盥回しにして解放するというのは良くある状況だけど、
普通のc++なんかのソースコードだとそれぞれモジュール化されて切り離されているから、それをコンパイル時に統合して
トレースするのはかなり大変なんじゃない?
ということ。

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




165 :デフォルトの名無しさん:2010/05/08(土) 03:10:45
Objective-C

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

てのはどうでしょうかね?

167 :デフォルトの名無しさん:2010/05/08(土) 03:41:41
ね?ではなく、試せ

168 :デフォルトの名無しさん:2010/05/08(土) 05:55:57
>>104
だれも便利は求めてないぞ(w

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

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

>>108
>>1を嫁よ、C言語と文法上の互換性は必要ない。
ただしオブジェクトリンケージとか、C、C++、JAVA
D,Go,C#で色々見知った事を生かしたい。

169 :デフォルトの名無しさん:2010/05/08(土) 05:58:42
>>120
二兎を追うんじゃなくて、美味なる一匹

170 :デフォルトの名無しさん: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;
}
てな事になってヤバイよね


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

どっちにしろ「意図通り」のコードを吐いてくれるかどうかなんてわからない。
50歩100歩。すっぽすっぽたんの言う通り、字面で書き換えを行うことによる
言語上の弊害のほうがきわめて大きい。

172 :デフォルトの名無しさん:2010/05/08(土) 08:01:39
誤爆かと思ったら前スレかw
定数に限っては意図どおりに展開されるよ

173 :デフォルトの名無しさん: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;
}

174 :デフォルトの名無しさん:2010/05/08(土) 08:15:10
>>173 続き

なんて風に行けると、コンパイラも最適化しやすいだろうし、
プログラミングもやりやすくなると思うんだよね。
構文については酷いし、例外はもっと考えないと不味いだろうけども。
例外についても2種類有るってのをどうやっていくか、とか、本当に2種類なのか
とか。

175 :デフォルトの名無しさん:2010/05/08(土) 08:23:05
それはきめえわ

176 :デフォルトの名無しさん:2010/05/08(土) 08:26:36
CPU固有言語たんハァハァですな。


177 :デフォルトの名無しさん:2010/05/08(土) 08:45:34
マクロが必要か不要かの割合は1:9くらいでしょう。
不要だという人が多い。
ジェネリックスや多態性等で解決できるという主張だ。
でもジェネリックスを使いやすく発展させることを考えると
マクロに近づいていくというのがD言語のジェネリックスを見れば分かるかと。

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

ジェネリックスというかC++のテンプレートはオブジェクト指向とは直接関係しない、
コンパイルタイムにプログラムを作成する関数指向なプログラムだから。


178 :デフォルトの名無しさん: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;         //呼び出し元が例外を受け取るならそちら任せる。
  }
 }
}


179 :デフォルトの名無しさん:2010/05/08(土) 08:55:41
>>178 続き
こうすればスタックの巻き戻しという大がかりな機構が必要なくなるし、
記述の一貫性が保てて良いと思うんだけど、例外の利点を何か失いそうな
感じがしてる。でもそれが何かまだ分からない。


180 :デフォルトの名無しさん:2010/05/08(土) 09:32:56
>>179 続き。
>>178のコンパイラ自動設定の部分は、>>173で示したように、
Exceptionを関数定義で定義するかどうかによって、判断したら、
つまり、Exception引数を定義しなければ、旧来のC言語関数と
同じイメージになる。としてしまえば、総ての関数に、例外処理
というコードが組み込まれるのも避けられると思うんだ。

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

提案の狙いはこの部分なので、お前の稚拙考えだとそれは実現できないとか
こんな場合はどうするとか、言ってくれると嬉しいんだけど、ここは2ch
なので>>175なのかもしれない。


181 :デフォルトの名無しさん:2010/05/08(土) 09:42:11
このスレは馬鹿しかいないな

182 :デフォルトの名無しさん:2010/05/08(土) 09:49:16
>>181
無意味なこと書き込むお前ほどではない。

183 :デフォルトの名無しさん:2010/05/08(土) 09:59:19
お前らの書き込んでいることは無意味ではないとw

184 :デフォルトの名無しさん:2010/05/08(土) 10:08:37
>>183
人を馬鹿にするときには馬鹿にする前に馬鹿にする相手を論破しておかないと馬鹿にしているやつが馬鹿に見える。
お前のように実社会で馬鹿にされているからここにきて馬鹿にしに来ているやつにありがち。

185 :デフォルトの名無しさん:2010/05/08(土) 10:16:22
書き込んでいる人間のプロファイリングとか
馬鹿しかしないわなw

186 :デフォルトの名無しさん:2010/05/08(土) 12:33:10
>>178
必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
記述量が多い割に、値か関数かの判定は先読みしなければならないのも嬉しくない。
強力なマクロも実現できそうにない。

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



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

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

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



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

>>187
いや、JAVAもC++も同じなんだけど、スタックの巻き戻しやって、
最後にシステム基底のデフォルト例外処理にぶち当たるんだけど、
システム基底の例外処理にぶち当てるか、自分で例外キャッチするのかを
一番よく知ってるのは、呼び元の関数だろ、なに世界一周旅行に出かけなきゃ
ならないんだ?って部分への疑問を解決するためのコードというか例外処理。


189 :デフォルトの名無しさん:2010/05/08(土) 13:15:47
>>186 続き
>>187
>もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
>話したいなら、そこだけ話せばいいのでは?
関数定義も変更したいのとセットで語りたい部分だから。

>>178の下の部分は
catch(localmEx){
  if(local.divbyzero() && localmEx.islocal()){
   system_default("divbyzero");   //こんな感じにシステムデフォルトにする事もできるしさ
   abort();             
  }else{
   throw localmEx;         //呼び出し元が例外を受け取るならそちら任せる。
  }

190 :デフォルトの名無しさん:2010/05/08(土) 13:17:08
>>189>>188の続きの間違い。

191 :デフォルトの名無しさん:2010/05/08(土) 13:17:15
>>188
いや、単語の長さとか、そういうレベルじゃない。
個人的には、お前は根本的にセンスがないと思う。

192 :デフォルトの名無しさん:2010/05/08(土) 13:19:23
>>191
気分の議論は無意味だよ。とか書いても理解力は無いか。
まぁニギヤカシがいてるのが2chなのでしょうがない。

193 :デフォルトの名無しさん:2010/05/08(土) 13:28:27
>>192
いや、気分の話じゃない。
言語を作るときに必要なのものとして、機能と文法があるとして、
文法の部分はかなりセンスを必要とする。

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

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

機能としても新しくなく、文法としても魅力がないものを訴えても、そりゃ
誰も理解を示さない。

194 :デフォルトの名無しさん:2010/05/08(土) 13:36:19
気分的には、再利用とカスタマイズへの拘りが感じられるスレだな
低級言語を低級ではない分野にも再利用したいとか
一からBNFを書き直すのではなくパーサーをカスタマイズしたいとか
そういう話題が多い

195 :デフォルトの名無しさん:2010/05/08(土) 13:36:23
>188
直上の呼び出し元しか例外処理できないなんて無茶だわ。
そもそも「何の関数が呼び出したの?」という問題もあるし、結局まともに例外を実装しようとしたら
全部の関数にcatchを付けなきゃいけなくなって、オーバーヘッドが酷いことになるわな。
あとマクロとの相性が最悪なことになりそう。

例外は「異常事態用の専用フローを用意する」ということが重要なのであって、例外発生時の効率を
考えるのは筋が悪いですな。
そんなことをするんだったら、forthみたいにスタックを直接操作できるようにした方が100倍マシ。


196 :デフォルトの名無しさん:2010/05/08(土) 13:42:04
>>195
>直上の呼び出し元しか例外処理できないなんて無茶だわ。

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

>そもそも「何の関数が呼び出したの?」という問題もあるし、
ねーよ馬鹿。

197 :デフォルトの名無しさん:2010/05/08(土) 13:43:04
>>193
だから、気分を語られても困るって(www


198 :デフォルトの名無しさん:2010/05/08(土) 14:04:09
>196
お前……例外使ったことないだろ。
細かい関数(thunkとか)実装した時に、それぞれの関数にcatchを用意しなきゃいけなくなるんだぜ?
オーバーヘッドで死んでしまうわ。どこの高水準言語だ

>何の関数が呼び出したの?
サブルーチンだけに閉じてればOKだけど、もうサブルーチン決め打ちに決定したのか?
またマクロの実装をどうするか、遅延評価をどうするかとか色々な要因があるんだけど。
まあ、例外を効率化しようなんて馬鹿考えるやつなら想像力もこんなもんか。


199 :デフォルトの名無しさん:2010/05/08(土) 14:12:10
ここまで有用な話題なしと

200 :デフォルトの名無しさん:2010/05/08(土) 14:21:47
>>124
GC必須にしたら結局低級言語にならないという
結論に到達するなw

201 :デフォルトの名無しさん:2010/05/08(土) 14:23:37
>>152
お前デザインパターンを駆使するとdeleteするタイミング考えるの大変だぞ

202 :デフォルトの名無しさん:2010/05/08(土) 14:34:18
デザインパターンは古い
クラウドを駆使するとソケットを閉じるだけだぞ

203 :デフォルトの名無しさん: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++的オブジェクトありきとか。

204 :デフォルトの名無しさん:2010/05/08(土) 15:11:04
>>203
ゼロ除算は結構簡単に発生するから良い例なんだよね。
異常度が高いというレベルで考えれば、数学概念を破壊するほど
高い異常な事態なんだけど、会計処理なんかでどかんと
処理したいときなんかは、簡単に発生するし。

205 :デフォルトの名無しさん:2010/05/08(土) 15:18:22
>>201
そんなクリティカルな部分で悩むのにデザインパターンを
採用するのがキチガイなんだよね。

206 :デフォルトの名無しさん:2010/05/08(土) 15:57:37
なんで割り算する前に判定しない前提なの?
知恵遅れなの?

207 :デフォルトの名無しさん:2010/05/08(土) 16:04:32
例外は要らない

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

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

たとえば、
  a = b / c;
 if(errno == division_by_zero)
           /* 0除算時の処理 */
あるいは、
 (a, errno) = b / c;
ですかね。
goみたいだけど

208 :デフォルトの名無しさん:2010/05/08(土) 16:16:58
>>186
> >>178
> 必要以上に記述量が多いので大部分の人は使ってくれないでしょう。

それが使ってるんだな、Javaで。弱冠文法が違うが。

209 :デフォルトの名無しさん:2010/05/08(土) 16:19:21
errnoは今さらあり得ない。

210 :デフォルトの名無しさん:2010/05/08(土) 16:24:27
イメージしやすいようerrnoを使ったまでだよ

211 :デフォルトの名無しさん:2010/05/08(土) 16:26:01
なんで台無しにした後始末の話になるんだよ
未然に防ぐ方法を考えろや

212 :デフォルトの名無しさん:2010/05/08(土) 16:28:07
例外なんて必要ない
ファイル開けなかったらabortすればいい

213 :デフォルトの名無しさん:2010/05/08(土) 16:28:11
>>188
たまにしか使わない部分は長いほうがいいかもしれない。
でも、言語は常に使う部分だから短いほうがいい。
CもRubyも短くかけるから好まれる。

例外の話に限ればもっと話してもいいかも。
>>189
関数定義の段階で賛同していないけど、例外処理の話はしてもいい人とも
話せなくなるよ。


214 :デフォルトの名無しさん:2010/05/08(土) 16:59:49
>>213
言語仕様をどうするかって話をしてるので、
俺の提案は、関数仕様ごと改革するべき、
という提案の中に例外が含まれている。

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

もちろん例外だけを話したい人でも、その方法では例外のこれが
このように出来ないとちゃんと(訳の分からないOS持ち出さず)
話してくれるのなら聞く用意はとてもある。

215 :デフォルトの名無しさん:2010/05/08(土) 17:01:51
アプリケーションレベルならsetjmp/longjmpで十分な件。
OSとか作る場合他のプロセスの発生した例外の
トラップとか必要なわけでjavaなんか真似ても
全く使い物にならない件。

216 :デフォルトの名無しさん:2010/05/08(土) 17:04:01
signalとごっちゃになっとるな

217 :デフォルトの名無しさん:2010/05/08(土) 17:10:47
ブログラムエラーとかプログラムでは避け難いエラー処理を行うのが例外だからな
構文に入れちまったのはC++やJavaの設計ミスと思うがね

0割の例ならCPUがトラップする時点でランタイムやOSが関与するし、発生しないCPUもある
言語よりランタイムの話でいんじゃね

218 :デフォルトの名無しさん:2010/05/08(土) 17:13:26
頭が設計ミスの奴がいるな

219 :デフォルトの名無しさん:2010/05/08(土) 17:17:42
お前がな

220 :デフォルトの名無しさん:2010/05/08(土) 17:51:44
あの辺の言語に try-catch が導入されていることを、ただ単に設計ミスと言っているようなヤツは、このスレで発言するのは控えてほしいな。

221 :デフォルトの名無しさん:2010/05/08(土) 17:59:33
脳を0割しか使わないとこういう発言をしてしまうんだな

222 :デフォルトの名無しさん:2010/05/08(土) 18:10:48
さらに新しい言語には導入されてない理由も考えずに戯言いうなよw

223 :デフォルトの名無しさん:2010/05/08(土) 18:12:17
まあ形かえたgotoだからな
汚いのは当然

224 :デフォルトの名無しさん:2010/05/08(土) 18:16:20
例外を文法でなくライブラリで実現した言語って何があったっけ?

まさかsetjmp/longjmpを使えとか言うんじゃないよな。

225 :デフォルトの名無しさん:2010/05/08(土) 18:20:00
むしろ関数の後ろにエラー専用のラベルを付けられるようにしろよ
VBみたく
結局ブロックでネストさせんのが面倒ってことだろ

226 :デフォルトの名無しさん:2010/05/08(土) 18:23:52
setjmpを構文に取り入れただけだしな
OSとか組込とか例外自身を記述するのはどうすんだ?

227 :デフォルトの名無しさん:2010/05/08(土) 18:27:22
longjmpにはjmp_bufを渡す必要があるわけだが、大抵の言語の例外は、そんな面倒な仕様じゃないぞ。

228 :デフォルトの名無しさん:2010/05/08(土) 18:28:19
いろいろそういうことがあるから、OSはC++ではなく、Cで書かれているんじゃないか。

229 :デフォルトの名無しさん:2010/05/08(土) 18:36:53
Cでもマクロで隠しちまえば似たことはできるわな
金粉かけても汚いモンはきたないし。

あんなモン構文にいれちまうから
エラー処理まで例外にしちまうバカがでるし、
無用なオーバーヘッドを意識せずにつかっちまう

230 :デフォルトの名無しさん:2010/05/08(土) 18:39:25
>214
なら関数仕様をどうするつもりなのか説明しないと話にならんな。
エスパーじゃないんだから、まとめて話してもらわんとわかるわけ無いだろ。
単にc++の例外仕様を変更しただけっつうなら単なる不燃ゴミだがな。

231 :デフォルトの名無しさん:2010/05/08(土) 18:39:25
馬鹿の発言が頻繁すぎる

232 :デフォルトの名無しさん:2010/05/08(土) 18:39:48
>>202
デザインパターンは普段当たり前のように使っているものでブームではないはずなんだが。
デザインパターンとクラウドは直交する概念

233 :デフォルトの名無しさん:2010/05/08(土) 18:40:17
>224
scheme

234 :デフォルトの名無しさん:2010/05/08(土) 18:42:53
>>231
賢い発言してくれよ

235 :デフォルトの名無しさん:2010/05/08(土) 18:43:37
>>205
どこがクリティカルでどこがキチガイなんだ。
JavaやC#では「デザインパターンありき」で開発するからどこでメモリ解放するかを
きっちり意識する必要はないんだが。staticイニシャライザやProxyパターンを使わないでループ内でしつこく無駄にnewしてるわけでもなかろうし。
むしろぞんなメモリのことでキチガイのように無駄に悩む必要がないからデザインパターンを使えるわけだが。

236 :デフォルトの名無しさん:2010/05/08(土) 18:51:39
>>217
DivideByZeroExceptionを実装する代わりに
MATLABのように 
0/1
と入力すると
Inf (無限大)と出力でもする仕様にするのか?
pow(-1,1/2) (-1の平方根)と入力するとNaNと出力せずに
i (虚数)
と出力する複素数型仕様にでもするのか?

237 :デフォルトの名無しさん:2010/05/08(土) 18:52:22
>>222
C#、PHPで導入されているが何か

238 :デフォルトの名無しさん:2010/05/08(土) 18:53:49
話が発散するから「低級言語」として適当でない話題は他所でやれよ
スレタイにC++が入ってるのがそもそも良くないんだが

239 :デフォルトの名無しさん:2010/05/08(土) 18:58:40
>>238
新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

おまえがこっちでやればいいだろ

240 :デフォルトの名無しさん:2010/05/08(土) 19:05:23
>>233
Lisp族でマクロで実現されているものはライブラリというより文法の一部だろ。

241 :デフォルトの名無しさん:2010/05/08(土) 19:06:40
ライブラリで出来るなら
まずは既存の言語で優れたライブラリを作ってみたらどうだ?

242 :デフォルトの名無しさん:2010/05/08(土) 19:13:27
>>238
低級言語でも例外処理とオブジェクト指向を適用しよう
というのは無理か

243 :デフォルトの名無しさん:2010/05/08(土) 19:16:15
いまどきは組み込みですらC++使っているから

244 :デフォルトの名無しさん:2010/05/08(土) 19:21:27
>>243
C++の機能をほとんど使わずにな

245 :デフォルトの名無しさん:2010/05/08(土) 19:24:12
とりあえずここらでターゲットを明確にしておいたほうがいい。

ファームウェア〜コンソールアプリもしくはサーバーサイドアプリくらいでいいよな?

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

FORTHでOOをやったという話もあるぞ。

247 :デフォルトの名無しさん:2010/05/08(土) 19:28:04
デバドラなんて昔からOOチックだしな

248 :デフォルトの名無しさん:2010/05/08(土) 19:29:47
組み込みの幅は広いからな

249 :デフォルトの名無しさん:2010/05/08(土) 19:30:03
そりゃ自動でやってくれることを手動でやれば
Cでもオブジェクト指向は可能だろうよ。
めんどくさくてやってられないだけで

250 :デフォルトの名無しさん:2010/05/08(土) 19:33:25
>>240
言語仕様を変えずに実現できれば、ライブラリで可能ということになるでしょう。
文法が変えられるならそれだけ言語のライブラリで出来ることが増えるだけなのに
反則と思ってもらってもなぁ。

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



251 :デフォルトの名無しさん:2010/05/08(土) 19:39:24
例外ライブラリでやってなんかメリットあるのか?
ゼロオーバーヘッドにできるの?

252 :デフォルトの名無しさん:2010/05/08(土) 19:43:55
あほが多用しなくなる

253 :デフォルトの名無しさん:2010/05/08(土) 19:44:54
おまえがあほだろw

254 :デフォルトの名無しさん:2010/05/08(土) 20:02:34
>>253
賢いなら
例外がどういう実装になるか
エラー処理として使う是非
普通にエラー返すのに比べての利点も教えてくれよ

255 :デフォルトの名無しさん:2010/05/08(土) 20:04:52
普通にエラー返すんだったら、全部返り値チェックして、そのあとの処理をスキップする
ifがいるだろ。

256 :デフォルトの名無しさん:2010/05/08(土) 20:06:04
ライブラリで例外作ってから来てくれよ

257 :デフォルトの名無しさん:2010/05/08(土) 20:18:15
タイトルにCって入れたの間違いだったな
C++使ったことない奴レベルが低すぎる

258 :デフォルトの名無しさん:2010/05/08(土) 20:22:01
>>256
setjmpとマクロで似たことできるし
at exitみたいなんでランタイムでひっかけてもいいかな

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

ま、完全に無くすのは無理だとは思ってるが
カジュアルに使うならあかんよw

259 :デフォルトの名無しさん:2010/05/08(土) 20:25:56
例外で処理をすっ飛ばすのを「エラー処理をさぼって」とかwwwwww

260 :デフォルトの名無しさん:2010/05/08(土) 20:29:37
で、すっ飛ばしてリソース漏れを起こすんですね。わかります。

261 :デフォルトの名無しさん:2010/05/08(土) 20:30:14
関数(メソッド)の引数が異常な場合は例外を投げるという仕様で、いろいろなものがすっきりする。
また、アンチgoto論者にも好まれる。

262 :デフォルトの名無しさん:2010/05/08(土) 20:32:20
>>260
解放忘れは、例外がない場合の方が冒しやすい。

263 :デフォルトの名無しさん:2010/05/08(土) 20:33:04
>>258
いいから作ってこいよ

264 :デフォルトの名無しさん:2010/05/08(土) 20:33:47
ところがどっこい、例外で飛ばさずに全部いちいち処理せよと仰る御仁が現れたわけだ。
RAIIって全然普及してないんだな。

265 :デフォルトの名無しさん:2010/05/08(土) 20:36:07
そりゃRAIIなんて使ってるメジャーな言語はC++ぐらいだからな

266 :デフォルトの名無しさん:2010/05/08(土) 20:52:09
カリー化した関数にjavaのアノテーションをつけられたら、
いいなぁ、みたいな話だったんだろうな。

267 :デフォルトの名無しさん:2010/05/08(土) 20:52:30
RAIIと言わずに「オブジェクトの所有権をハッキリさせる」とすれば良いよ。

>261
契約による設計かね?それもけっこう重たいよ。
まあ、(assertみたいに)コンパイルオプションで無効にできるようにするとか、関数の戻り値の契約と合致する場合は
動的チェックを省略するとか色々と改善の余地はあるけど。

268 :デフォルトの名無しさん:2010/05/08(土) 20:58:23
大域ジャンプでスタックを巻き戻す際のデストラクタ呼び出せないよ、
スマートポインタどうしようもなくなってしまうよ問題



269 :デフォルトの名無しさん:2010/05/08(土) 21:05:25
大域ジャンプを高機能化する
スコープ抜けるときに後始末をするようにするとか

270 :デフォルトの名無しさん:2010/05/08(土) 21:11:44
いっぺんフリースタンディング環境で作ってみればいいよ
例外とかGCとかどんだけアフォな話してるのが理解できるから

271 :デフォルトの名無しさん:2010/05/08(土) 21:16:35
>>270
フリースタンディングな環境ではわざわざ例外とかGCとか
作ってられないと?



272 :デフォルトの名無しさん:2010/05/08(土) 21:25:04
>>271
OS作れるような言語と言っているのに、OSに依存するような機能を入れようとしている。

273 :デフォルトの名無しさん:2010/05/08(土) 21:30:30
例外はCPUに依存するのではないでしょうか?
GCはライブラリに依存とはいえCPUごとに異なるので作るの大変。
それはOSの仕事に近い部分と。それは分かります。

274 :デフォルトの名無しさん:2010/05/08(土) 21:41:37
むしろマルチタスクとかページングとか作るのが簡単だったりして
例外とGCはシングルタスクの殻に閉じこもってる

275 :デフォルトの名無しさん:2010/05/08(土) 21:53:23
GCはOS必須ではないがな

276 :デフォルトの名無しさん:2010/05/08(土) 21:55:22
>>275
必須だよ。

277 :デフォルトの名無しさん:2010/05/08(土) 22:13:48
>>276
なぜGCにOSが必須なんですか?

278 :デフォルトの名無しさん:2010/05/08(土) 22:19:19
行儀の悪いアプリが終了したとき&強制終了したとき
掴んでたメモリを開放する処理は必要
一種のGCみたいなものになる。

279 :デフォルトの名無しさん:2010/05/08(土) 22:26:42
それGCと関係なくね
だいたいOSの存在しない世界って、基本的にゼロ番地から全部自分のモンだろ
行儀の悪いアプリとか何だそりゃって話だ

モダンなGCは専用のタスクやスレッド裏で走らせるのが普通だと思うが
N88BASICとかにもガーベージコレクションはあっただろ

280 :デフォルトの名無しさん:2010/05/08(土) 22:51:44
>>277
GCどころかヒープでさえOS必須だ。ヒープなしでGCあっても意味ないだろ。

281 :デフォルトの名無しさん:2010/05/08(土) 22:59:58
>>280
釣り?
OSのある世界しか知らない?
言語作ろうなんて1億年早い?

282 :デフォルトの名無しさん:2010/05/08(土) 23:04:16
>>278
普通のOSならプロセスのリソースは管理されてるからな
またちょっと別だよ
RTOSは別だがありゃマルチスレッドだからな

283 :デフォルトの名無しさん:2010/05/08(土) 23:09:01
ヒープから取得したメモリアドレスがどのプロセスに属してるかを
把握してないと開放できないとかあるとか?

284 :デフォルトの名無しさん:2010/05/08(土) 23:20:48
MLton

を越えれるのかな

285 :デフォルトの名無しさん:2010/05/08(土) 23:24:38
>>281
ヒープが何かを知ってからそういうことを言え。

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

ま、あんまネタまきすぎるのもアレだが
あんま低レベルでもないがValaとGenieはどうよ


287 :デフォルトの名無しさん:2010/05/08(土) 23:30:27
OSやタスクやプロセスの線引きをどこで行うかの話でしかない
「OSは必要だよ」厨はスルーでよい

288 :デフォルトの名無しさん:2010/05/08(土) 23:32:53
OS作るなら言語がヒープの管理してちゃ困るだろ

289 :デフォルトの名無しさん:2010/05/08(土) 23:33:15
>>287
なんでOSがC++で書かれていないのかも分かっていないな。

290 :デフォルトの名無しさん:2010/05/08(土) 23:34:28
>>285
常識的な知識位しかないね
組み込み屋だからOSなしの環境に
libcサブセットのmallocとかprintf位は作ったことあるがねw
当然だがリセットから初期化してヒープの準備とかもなw


291 :デフォルトの名無しさん:2010/05/08(土) 23:35:01
タスクスイッチするだけのチープなOSもあるよ。
そういうのはヒープ=スタックを除く物理メモリのこと。
GCを単体のタスクに対して行うか、全体に対して行うか。
前者ならOSは不要、後者ならOS上に乗っかってる。

292 :デフォルトの名無しさん:2010/05/08(土) 23:36:39
>>289
C++で書かれてますって自慢してたOS、昔あったような
世間知らずさん

293 :デフォルトの名無しさん:2010/05/08(土) 23:39:32
>>290
それはOSのメモリ管理のところを作っているじゃないか。

294 :デフォルトの名無しさん:2010/05/08(土) 23:40:09
メモリ管理=OSだと思ってるのかな
GCにOSは不要ですよー


295 :デフォルトの名無しさん:2010/05/08(土) 23:41:35
>>288
別に困らないよ。
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおk。

296 :デフォルトの名無しさん:2010/05/08(土) 23:42:57
まだくだらないことで揉めてんのかw
そもそもGCはスレ違いなんだよ

297 :デフォルトの名無しさん:2010/05/08(土) 23:45:28
>>292
そういうで意味ならWindowsだってC++で書かれているし、NeXTはObjective-Cで書かれている。
その下により低水準のOSがいる。

298 :デフォルトの名無しさん:2010/05/08(土) 23:49:45
>>296
確かに1970年代の低級言語にGCはなかったが
2010年だからということで揉めてる

299 :デフォルトの名無しさん:2010/05/08(土) 23:53:24
GC付きでいいならD言語使えばいいのに

300 :デフォルトの名無しさん:2010/05/08(土) 23:53:53
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。

301 :デフォルトの名無しさん:2010/05/08(土) 23:55:59
GC有り無し両方に対応したプログラムを単一のコード(あるいは最小限の修正)で記述出来ればいいね。

302 :デフォルトの名無しさん:2010/05/08(土) 23:56:26
メモリ管理を書くのにメモリ管理がすでにあることを想定している言語を使う。

303 :デフォルトの名無しさん:2010/05/08(土) 23:57:07
低水準言語という観点から言えば、2010年だろうが何だろうが
GC無しで使いたいことは多いはずなので
言語仕様のレベルでGCを前提にするのはやりすぎだろ
GC前提にすることで色々楽チンになって
クロージャのようなオサレ機能が使えるとしても我慢汁

で、言語仕様のレベルでGCを前提にしないならライブラリで、ということになるが
それだけならCでも出来る
malloc()ではなくてGC_malloc()みたいなのを呼べばいいだけだ
つまりここで話すような事柄じゃない

304 :デフォルトの名無しさん:2010/05/08(土) 23:57:29
>>301
C++/CLI

305 :デフォルトの名無しさん:2010/05/08(土) 23:59:25
>>302
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおk。

306 :デフォルトの名無しさん:2010/05/09(日) 00:02:52
>>305
new が使えないC++は、もはやC++とは呼べない。

307 :デフォルトの名無しさん:2010/05/09(日) 00:02:55
>>303
低水準言語という観点から言えば、2010年だろうが何だろうが
除算無しで使いたいことは多いはずなので
言語仕様のレベルで除算を前提にするのはやりすぎだろ

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

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

308 :デフォルトの名無しさん:2010/05/09(日) 00:06:18
>>306
別に呼びたくなければ呼ばなくてもいい。
C++を作る過程で「new が使えないC++」を使って何の問題があるんだ?
すべてが常に完全である必要はない。
言語は単なる手段だ。使いやすいように使えればそれでいい。

309 :デフォルトの名無しさん:2010/05/09(日) 00:07:11
>>307
馬鹿はコピペぐらいしか脳が無いのか

言語仕様のレベルでGC前提なら、GCを動かすまではその言語は使えないということ
だろが
それだとCより用途が確実に狭まる、言い換えれば上の層の言語になっちまうだろ
メモリマネージャみたいなのに頼れない場所でも貧者のmalloc()を自分で書いて
使えるのがCだ

310 :デフォルトの名無しさん:2010/05/09(日) 00:07:28
>>305
だがちょっと待ってほしい
既存の言語の上に何かを積み上げるのは無意味ではないのか

311 :デフォルトの名無しさん:2010/05/09(日) 00:08:51
>>306
operator newは自分で実装できるし
placement newもあるだろ

デフォルトのアロケータに頼り切ったような「普通の」C++コードを
そのまま使えないだけだ

312 :デフォルトの名無しさん:2010/05/09(日) 00:10:18
>>306
newのお勉強スレ行ってこい

313 :デフォルトの名無しさん:2010/05/09(日) 00:10:34
>>309
>言語仕様のレベルでGC前提なら、GCを動かすまではその言語は使えないということ

それはない。
言語仕様をすべて実装しなければ動かないのであれば、動くC++処理系はこの世に存在しない。
言語仕様のフル機能を備えたC++は存在しないからな。

314 :デフォルトの名無しさん:2010/05/09(日) 00:10:47
>>311
それじゃ、C++使っている意味ないだろ。

315 :デフォルトの名無しさん:2010/05/09(日) 00:11:31
>>310
そう。
だから新言語の上に新言語を積み上げる。

316 :デフォルトの名無しさん:2010/05/09(日) 00:13:57
ここは困ったちゃんを相手にするスレ

317 :デフォルトの名無しさん:2010/05/09(日) 00:14:43
アホ避けが欲しいな
せめてD&Eくらいは読んでいて欲しい

318 :デフォルトの名無しさん:2010/05/09(日) 00:16:29
>>314
は?何で無いんだよ
テンプレートだのクラスだのといった便利な抽象化機能が普通に使えるぞ

C++の規格に盛り込まれているfreestandingの意味も知らない
ド厨房はすっこんでろよ

319 :デフォルトの名無しさん:2010/05/09(日) 00:19:34
>>317
そんな無駄レス書き込んでる暇があったら、D&Eを読んだ成果を披露しろ

320 :デフォルトの名無しさん:2010/05/09(日) 00:22:04
馬鹿の相手をするのも疲れるんだよ

321 :デフォルトの名無しさん:2010/05/09(日) 00:34:13
気力を一方的に奪われるだけで得るものが何もないスレ

322 :デフォルトの名無しさん:2010/05/09(日) 00:35:44
D、C++/CLI、Objective-C にある機能しか出てこないな。

323 :デフォルトの名無しさん:2010/05/09(日) 00:40:28
Cで誰も本気で困っていないから。

324 :デフォルトの名無しさん:2010/05/09(日) 00:43:25
C以上に低級だとアセンブラだし高級だとC++になっちまうしな

325 :デフォルトの名無しさん:2010/05/09(日) 00:43:59
流石にnewが使えないとかいう妄言はないわ

326 :デフォルトの名無しさん:2010/05/09(日) 00:45:24
GCにOSが必要とかなw

327 :デフォルトの名無しさん: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作っちゃって。
コンパイラ係:はい。やっておきます。

328 :デフォルトの名無しさん:2010/05/09(日) 00:58:41
お前頭悪いだろw

329 :デフォルトの名無しさん:2010/05/09(日) 01:03:21
CPUは既にあるものを使うし
Cなら既存のコンパイラが普通に使えるっつーの

330 :デフォルトの名無しさん:2010/05/09(日) 01:04:04
リンカは別だけどな

331 :デフォルトの名無しさん:2010/05/09(日) 01:13:59
>>329
> CPUは既にあるものを使うし

言語仕様に「既存のCPUを使うこと」って文言を入れるの?
なんたるCPU依存言語ww

332 :デフォルトの名無しさん:2010/05/09(日) 01:14:24
作るにしても最初はgccへのトランスレータにしてくれ
そうしないときっと使わない

333 :デフォルトの名無しさん: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パターンで作ったクラスのシンタックスシュガーということ。

こういうところだけ真似をすれば省メモリ超高速低級言語を作るさいの参考になるかもしれないぞ。

334 :デフォルトの名無しさん:2010/05/09(日) 01:18:57
1つ分かったことがある。
低レベルな層ではオブジェクト指向やクロージャが使えないから、
多態性を使えば出来るからいらない、クロージャ使えば出来るからいらない
テンプレートあれば出来るからいらないって話が通用しなくなる。
型安全性より、スピード。分かりやすさよりスピード。
そういう世界ではマクロ利用に対するニーズは高まる。
マクロは実行時のコストはゼロだからだ。

335 :デフォルトの名無しさん:2010/05/09(日) 01:20:33
低レベルな層でもオブジェクト指向はできるよね。

336 :デフォルトの名無しさん:2010/05/09(日) 01:28:29
>>327
うけたw
普通はクロスと既存の移植だろw

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

休日なのにこのスレは電波度高いなw

337 :デフォルトの名無しさん: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);
 }
}

338 :デフォルトの名無しさん:2010/05/09(日) 01:31:20
>>332
Vala/Genieでいんじゃないw

339 :デフォルトの名無しさん:2010/05/09(日) 01:31:56
>>267
思うのだが
重たい問題は自動最適化コンパイラで解決できるような

そんなコンパイラを作るのはものすごい技術力と知能が必要だが

340 :デフォルトの名無しさん:2010/05/09(日) 01:33:27
ROMに書き込むような組み込みだと、、
多態どころか関数ポインタテーブルすら使いたくない状況がある。
パフォーマンスも重要だけど、傾向としてはサイズ>スピードの場合が多い。
それとプリプロセッサの条件ディレクティブを多用することになる。
欲しいのはテンプレートぐらいかな。あえて言えば。

341 :デフォルトの名無しさん:2010/05/09(日) 01:37:39
RAMすら無しでブートしたりね
多分組み込みやったことないと想像も出来んだろ
それでも動かせるCは偉大だな

342 :デフォルトの名無しさん:2010/05/09(日) 01:37:40
>>279
ちょっと気になるんだが

ということはこのスレで作る言語の配列とやらは
初期化したときに宣言した配列領域をオーバーしたバッファーオーバーフローも当たり前ということか?
JavaのようにNegativeArrayExceptionとArrayIndexOutOfBoundsExceptionも吐かないと?

343 :デフォルトの名無しさん:2010/05/09(日) 01:39:25
>>296
GCを実装したアセンブラ
ってのもなんだかわくわくするじゃないか

344 :デフォルトの名無しさん:2010/05/09(日) 01:41:26
MMUにGC支援機能とか搭載しないのかな

345 :デフォルトの名無しさん:2010/05/09(日) 01:42:44
いっそCPUにGCとオブジェクト指向命令を追加すればw


346 :デフォルトの名無しさん:2010/05/09(日) 01:42:47
>>343
ちっともしない。
そんなのライブラリ呼び出すしかないじゃん。

347 :デフォルトの名無しさん: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を実装すればいいのではないかな・

348 :デフォルトの名無しさん:2010/05/09(日) 01:43:33
しかないかどうかは、これから決めること

349 :デフォルトの名無しさん:2010/05/09(日) 01:44:45
>>344
MMUじゃ管理単位が荒過ぎるな
mark and sweep GC命令でw
FPGAなら書けるだろw

350 :デフォルトの名無しさん:2010/05/09(日) 01:44:55
>>348
ノイマン型で決めるも何もないだろ

351 :デフォルトの名無しさん:2010/05/09(日) 01:46:07
>>350
どういう意味?

352 :デフォルトの名無しさん:2010/05/09(日) 01:46:34
>>336
ビットフィールドによるインデックスの管理は
そのリストや集合があまりにも膨大なとき真価を発揮するのだが。

353 :デフォルトの名無しさん:2010/05/09(日) 01:46:34
LISPマシンてどういうアーキテクチャなの?

354 :デフォルトの名無しさん:2010/05/09(日) 01:47:39
>>345
欲しいな。未来のCPUだ

そして並列処理もできるといいな

355 :デフォルトの名無しさん:2010/05/09(日) 01:48:24
なんか単語を並べてるだけだなこのスレ。

356 :デフォルトの名無しさん:2010/05/09(日) 01:48:29
>>349
FPGAでは条件分岐が多い処理は性能が出ないから難しい。
下手するとCPUでソフトウェア処理するのより遅くなる。

357 :デフォルトの名無しさん:2010/05/09(日) 01:53:49
GCの実装とかコンパイラの実装の知識あって書いてんのかな

358 :デフォルトの名無しさん:2010/05/09(日) 02:01:44
あって書いている場合もあれば、なしで書いている場合もあるだろう。
もちろんどちらも歓迎だ。

359 :デフォルトの名無しさん:2010/05/09(日) 02:11:29
すこしはまとめてこうよ・・・

360 :デフォルトの名無しさん:2010/05/09(日) 02:12:10
>>342
デフォルトで境界チェックあり、
オプションで外せるぐらいが無難な線ではなかろうか

ポインタって概念はなかなか秀逸だと思うが、
あまりに低水準で柔軟すぎて最適化の障害になってる
しかし、アドレス操作すらできないのではCの代替言語として問題があるだろう
配列との絡みも含めて、何をどこまで認めるか、悩ましいところ

361 :デフォルトの名無しさん:2010/05/09(日) 02:14:39
>>359
どうぞ、どうぞ。

362 :デフォルトの名無しさん:2010/05/09(日) 05:46:51
>>358
大きく間違ってる。
無い人でもせめてコードを読んだことがある
レベルじゃないと、話にならない。
このスレで言う素人はGC実装の納品経験はないけども、
読んだことは有るし、改良加えようと遊びで弄ったことは有る。
というレベルじゃないと。

363 :デフォルトの名無しさん:2010/05/09(日) 08:15:55
既存のGCの問題点

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

要約すると「言語に組み込む必要はない」「必要なときに(環境に合った)ライブラリ使用で十分」となる
個人的にはGCは優れた技術とは思わない

364 :デフォルトの名無しさん:2010/05/09(日) 08:43:56
>>363
大体同じ意見なんだけど、少し視点を変えて、
ライブラリで対応可能(newとdeleteを上書きすればよい)
なGCを、言語仕様に取り込まなかった場合どういう不具合
が発生するか考えてみたい。

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

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

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

ので、GCは必要ないと思う。

365 :デフォルトの名無しさん:2010/05/09(日) 08:45:29
>>362
> GC実装の納品経験

そんな経験ある奴あんまりいないと思うが...
開発経験ならまだしも。

366 :デフォルトの名無しさん:2010/05/09(日) 08:56:13
GC納品・・・

367 :デフォルトの名無しさん:2010/05/09(日) 09:01:13
独自のStringクラスやデータベースは、GCやってる。なんなら、オブジェクトはすべてデータベースに置くというのはどうだ。

368 :デフォルトの名無しさん:2010/05/09(日) 09:19:09
アホは書き込まないで

369 :デフォルトの名無しさん:2010/05/09(日) 09:23:43
まあ何を問題にしたいのかはわかるけどね。
低級言語と高級言語で例えばGCの有無により言語が全く異なる現状では、全く異なる言語を二つも学習しなければならない。
70年代の原始人ならそれで満足できるが、プライドばかり大きくなった現代人には耐えられない屈辱なわけだ。

370 :デフォルトの名無しさん:2010/05/09(日) 09:25:05
>>364
> ライブラリで対応可能(newとdeleteを上書きすればよい)
> なGCを、言語仕様に取り込まなかった場合どういう不具合

「確保したりソースが不要になったことを確実に知ること」ができなくなる。

371 :デフォルトの名無しさん:2010/05/09(日) 09:26:39
>>370
何言ってるのか分からないから、具体的にソースで書いて。

372 :デフォルトの名無しさん:2010/05/09(日) 09:43:18
GCの副作用もわからずにGCと言っているだけだろ。

373 :デフォルトの名無しさん:2010/05/09(日) 09:44:57
>>371
void bar(char **p);
void foo()
{
 char *p = new char[10]; // [A]
bar(&p);
}

[A] で確保したメモリーがいつ不要になったかを知るのは難しい
でしょ。

374 :デフォルトの名無しさん:2010/05/09(日) 09:46:28
>・循環参照とスレッドセーフを同時に解決したGC技術は未だに確立されていない
これは嘘だろ
Javaはマルチスレッド対応していて循環参照も消せる。
インクリメンタルなリファレンスカウンタ方式のGCでも循環参照を解決する方法は存在する

375 :デフォルトの名無しさん:2010/05/09(日) 09:51:55
GCをやりたければ単純なポインタ変数は禁止だろう。
オブジェクトポインタテーブルを用意し
オブジェクトポインタテーブルへのポインタを使わないと
メモリ管理そのものが成立しない。
当然実行効率は大きく低下する。

376 :デフォルトの名無しさん:2010/05/09(日) 09:56:17
>>373
意味分からねー、
なぜに引用して同じ意味のことを書いたのだ?
ちょっとキチガイレベルの高い人を相手にしてるのかな?

>>364から引用して>>370を書いて>>371で問い直したら>>373って
どう解読すれば良いんだろ?

377 :デフォルトの名無しさん:2010/05/09(日) 10:59:21
>>376
コード示してもわからないなら、多分あんたには理解できないと
言うことだと思うよ。

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

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

鏡見たほうがいいと思うぞ。

378 :デフォルトの名無しさん:2010/05/09(日) 12:02:12
GC無しで言語を作って置いて、GCありにも出来るようにすることは可能だ。
GCありにした場合だとGC無しのライブラリも、GCありのライブラリも使える。
GC無しだとGCありのライブラリは使えないと割り切るか、
混在して書くかという問題が出てきそう。

379 :デフォルトの名無しさん:2010/05/09(日) 12:21:27
>>373
横だけどそれは生ポインタをそのまま使ってるからじゃないの?
そういう指摘がしたいの?やっぱり何が言いたいかわからないと思うんだけど。

380 :デフォルトの名無しさん:2010/05/09(日) 12:36:46
>>378
GC有りにするとデストラクタの動作が変わるぞ。互換性がなくなる。
C#を例にとるとデストラクタに相当するファイナライザ使う場合は呼び出し順序が不定なためマネージドオブジェクトへの参照が禁止になる。事実上デストラクタでは何もできない。言語外のリソース市か触れない。
結局、usingとか呼び出し側でdisposeのタイミングを調整しなくてはならならなくなってしまう。

381 :デフォルトの名無しさん:2010/05/09(日) 12:52:21
まったく同じにはならないな。
ビルドするコードが「deleteで解放したオブジェクトはその後使用されない」という前提なら
GCありの場合、deleteが呼ばれずにGCによってオブジェクトが解放される場合は
メモリ解放以外のデストラクタ処理を行わなければ互換性は取れると思う。

382 :デフォルトの名無しさん:2010/05/09(日) 12:55:24
C#を改良しようスレでもないし、C++プログラミングでもないんだけどな。


383 :デフォルトの名無しさん:2010/05/09(日) 12:57:02
>>379
「CG使う時は、生ポインタなんて使わないでやるから、言語仕様なんかに
組込みなくてもいいじゃん」ということなの?

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

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

俺は >>364 が不具合示せというから、「不具合の一例」を書いただけ。
そんなケースは「俺のところではありえない」と言うだけならまだわかる
けど、「俺のところではありえないから意味わからん」と言われてもな。

384 :デフォルトの名無しさん:2010/05/09(日) 12:58:29
いやGC云々の話は常にでてるから議論のネタではあるでしょう。
別にクラスじゃなく組み込み型・構造体・配列だけでもGCは実装可能ではあるし。
その場合はポインタの実装を考えなくてはいけなくなるが。

385 :デフォルトの名無しさん:2010/05/09(日) 12:58:46
まあGCは無くていいんじゃね?
GCで解決するのはfree()し忘れる問題だけで
リソースリーク問題が無くなるわけじゃないし

386 :デフォルトの名無しさん:2010/05/09(日) 13:00:26
スマポ内蔵ならいいんじゃない

387 :デフォルトの名無しさん:2010/05/09(日) 13:08:31
S ex pression

388 :デフォルトの名無しさん:2010/05/09(日) 13:08:52
>>380
GCありにしても
デストラクタの呼び出しタイミングが変わるだけで、
デストラクタの動作そのものが変わるわけではないでしょう。


389 :デフォルトの名無しさん:2010/05/09(日) 13:09:58
GC有り無し混在するとしても、ポインタにメタデータ突っ込んどきゃいいんじゃね?
構造体にしてスマポ化するのも良いし、アライメントを活用するのもいいし。

今の時点だと、GCを考慮するとしてもポインタの扱いをどうするかぐらいしかできないだろ。
それよりもマクロとルーチンの話をしようぜ。

390 :デフォルトの名無しさん:2010/05/09(日) 13:12:57
GC最大の問題は最悪実行時間を保証できないこと
かといってGCが無いと、今度は無限エクステントは実現困難
わざわざ新たに設計する言語で、それはどうかと思うw

391 :デフォルトの名無しさん:2010/05/09(日) 13:13:58
>>383
そういえば話は通じると思う。
お互い論点の確認せずに持論しかいってないように見えるからよくわからんとなってると思う。

>ただそれでいいなら、malloc()/free() でもうまくいくはずだし、
これは特に論点になってないと思う。GCがいるかいらないかが論点だったから
例としてnew/deleteの話になってただけなんじゃないかな。当人じゃないから分からんけど。
>言語仕様で規制しないとだめなケースは "0" にはできないだろ。
>>364の肩を持つわけではないけど言語側でポインタを実装するときに
shared_ptrクラスのようにクラスオブジェクトのように解釈すればやはり解決可能じゃないかな。
しかしこれはビルドオプションで切り替えるか
常にこの切り換えのためのコストを払った実装にしなければならないと思うけど。

392 :デフォルトの名無しさん:2010/05/09(日) 13:15:29
GCのdelete呼び出しのタイミングが分からなくて
結果的にメモリ管理の考え方を変える必要があるわけだ。
だけど、そのGCありのプログラムとGCなしのプログラムが
混在した場合にどうあつかったらうまくいくかという点が問題なのでは?



393 :デフォルトの名無しさん:2010/05/09(日) 13:15:45
そこでgcnew

394 :デフォルトの名無しさん:2010/05/09(日) 13:18:45
混在させるメリットが不明。
同じコードをGCありでビルドするかなしでビルドさせるかという意味なら
ライブラリの使いまわしの話とかかなと思うが。

395 :デフォルトの名無しさん:2010/05/09(日) 13:18:56
>>392
C++/CLIを見れば分かる
俺に言わせればただのカオス、あくまで橋渡し用のアダプタ構築言語と見るべきで
好き好んで使うような代物じゃない

396 :デフォルトの名無しさん:2010/05/09(日) 13:19:46
お前に言われてもな

397 :デフォルトの名無しさん:2010/05/09(日) 13:22:46
gc_ptr<Hoge> hoge(gcnew Hoge);
gc_ptr<Hoge> hoge2;

hoge2 = hoge;

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

まさか言語仕様とか、ライブラリとか、ポインターの説明から始めなきゃ駄目?

399 :デフォルトの名無しさん:2010/05/09(日) 13:26:50
>>398
タイミングを知って制御してるはずのコードをGCありに移行するメリットが明示されてないよ。
その場合の問題点とのメリットのトレードオフも。

400 :デフォルトの名無しさん:2010/05/09(日) 13:27:27
>>398
例えばGC前提の言語仕様なら無限エクステントを作れるから
クロージャのようなものを言語仕様としてサポートできる
GCが単にライブラリとして利用可能、というだけならそれは無理

401 :デフォルトの名無しさん:2010/05/09(日) 13:29:13
>>400
だからLWLの人は寝て手くださいってばぁ
迷惑かけてるのにいい加減気がついてよ。

402 :デフォルトの名無しさん:2010/05/09(日) 13:30:11
>>400
これを「面白い」ととるかが「人間性」の違い。

403 :デフォルトの名無しさん:2010/05/09(日) 13:30:13
>>401
LWLって何だw
ちなみに俺は「GCを言語仕様のレベルで組み込むな」派だ
つまりクロージャなんて入れられないが、諦めろ
GC_malloc()でいいだろ


404 :デフォルトの名無しさん:2010/05/09(日) 13:33:02
>>403
例えばCにGC_malloc()だけでどうやって具体的に実装するの?
参照されているかの判断の仕組みはどのように実装されるの?

405 :デフォルトの名無しさん:2010/05/09(日) 13:33:38
>>399
組み込み向けに開発した画像圧縮プログラムが思いの外性能の良い
アルゴリズムで、互換性の問題も有ってOS上でも使いたい場合とか?
用はアルゴリズムは使い回したいけども、メモリ管理は別にいらなかった
とかかなぁ。この場合、メモリ管理を手作業からライブラリ任せにしても
問題ないだろうし。

406 :デフォルトの名無しさん:2010/05/09(日) 13:34:37
■GCありなし混在のメリット
・新しいCにGCが欲しいという人といらないという人がいる。
・あるときはデストラクタを使ってリソース管理をしっかり行い、
 あるときはGCによって確実にメモリ開放できる。
・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。
■GCありなし混在のデメリット
・今のところ混在すると混乱する。

407 :デフォルトの名無しさん:2010/05/09(日) 13:34:47
>>404
CでGCが利用できるライブラリなら既にあるよ
Boehm GCとかが有名なんで、興味あるんなら見てみれば
基本的に、ポインタ「に見える」ものをポインタとして扱うはず

408 :デフォルトの名無しさん:2010/05/09(日) 13:35:46
>>406
GCありでデストラクタでリソース管理って何のジョークだよ

409 :デフォルトの名無しさん:2010/05/09(日) 13:38:49
>>407
保守的GCをGCとして採用するのはどうかと

410 :デフォルトの名無しさん:2010/05/09(日) 13:41:05
C++/CLIは失敗してると思う。
あれ以上は無理ならあきらめるべきだろうけど、
もっといい方法はないものか?

Objective-C2.0ではGCありを選択できるようになったけど、
どういう仕組みなのでしょう?
うまく行ってるのかな?


411 :デフォルトの名無しさん:2010/05/09(日) 13:41:51
>404 >407
そのレベルの話なら、現段階で議論できるのはポインタを工夫するかどうかレベルだな。>389ぐらいか。
GCが管理するポインタとGCが管理しないポインタを区別できるようにしとけばいいんじゃね?

412 :デフォルトの名無しさん:2010/05/09(日) 13:43:34
malloc()用のヒープとGC用のヒープ分ければ済む話と違うのか
アドレスの範囲で区別つくだろ

413 :406:2010/05/09(日) 13:44:27
>>408
失礼しましたー、GCありでは確実にメモリ開放です。


414 :デフォルトの名無しさん:2010/05/09(日) 13:49:06
GCいらない派
1、有れば便利だけど失うものが多すぎる
2、ライブラリで対応できる
3、2の場合でもプログラムコードの手直しは最小限で済む

GC必要派
1、何故かGC実装の方法を唱え出す
2、何故かGCが有れば便利だと唱え出す
3、何故か訳の分からないことを唱え出す。

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

それはOSの存在しない環境で、実時間予測で動き、オーバーヘッドが
極めて少ないGCの実装方法を提案すること。
と、同義なのでそれをくださいって事。

415 :デフォルトの名無しさん:2010/05/09(日) 13:50:38
>>412
だから、OSの無い環境(OSを作る言語)でも
動かしたいC言語置き換え言語で、ヒープとか
言い出すなよ、も=、もー、もー

416 :406:2010/05/09(日) 13:50:40
GCのルートに登録されていればGC対象になればいいと。
保守的じゃない、GCをCレベルで実現することは可能ですかね?
ポインタ周りをいじれるようにしながら。。。

417 :デフォルトの名無しさん:2010/05/09(日) 13:51:56
>>415
は?ヒープって何か特別なものだとでも思ってんの?
その場合はメモリの適当な領域を自分で区切るだけの話だ


418 :デフォルトの名無しさん:2010/05/09(日) 13:52:43
>>416
むずいんじゃないの
GC管理されているヒープを指しているポインタなのか
ちょうどそれっぽい値を持つただの整数なのか
区別つかんでしょ

419 :406:2010/05/09(日) 13:55:25
>>415
malloc使わない人がいるのはわかってる。
mallocしない人はGCと混在できる言語が出来たとしても
GC使わなきゃいいだけだって。

420 :デフォルトの名無しさん:2010/05/09(日) 13:59:03
>>406
>・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。

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

ちなみに混在ってのは何だ、今でもCでGCライブラリ使えるわけだけど
それとは違う話なの?

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

>、実時間予測で動き、オーバーヘッドが極めて少ないGCの実装方法を提案すること。
これが重要であるというコンセンサスをとる必要がある。
まあ俺もそう思ってるんだけど。

422 :デフォルトの名無しさん:2010/05/09(日) 14:03:28
OS作成言語という前提があることは忘れてはならない

423 :デフォルトの名無しさん:2010/05/09(日) 14:04:37
拡張したポインタも素のポインタと同じように扱えるようにしとけばいいだろ。
そうしとけばGCなんてライブラリ実装で十分だし。


424 :406:2010/05/09(日) 14:05:59
>>420

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

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

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

・保守的じゃないGCを実現したい。
・構文上、GC使う、使わない両方を綺麗に書けるようにしたい。

425 :デフォルトの名無しさん:2010/05/09(日) 14:07:17
>>423
その拡張したポインタはどのようなコストが払われているのでしょうか。

426 :デフォルトの名無しさん:2010/05/09(日) 14:08:04
日本人はもっとブレストを研究・教育したほうがいいと思った。

427 :デフォルトの名無しさん:2010/05/09(日) 14:17:40
デストラクタはデストラクタ、ファイナライザはファイナライザで
それぞれ別のもの。

428 :デフォルトの名無しさん:2010/05/09(日) 14:18:07
スタックとメモリ空間だけがあって、
何番地から何番地はこれこれに使う。
という仕様にして、構造体のポインタにアドレスを入れてアクセスして
ほかのタスクとやり取りするといったような事にもC言語は使われている。
ヒープというからにはmallocなわけで、メモリ割り当てするには
それなりの実行コストが掛かる。
アドレス固定のスピードにはかなわない。



429 :デフォルトの名無しさん:2010/05/09(日) 14:20:06
>425
構造体にする場合はポインタのサイズ。
アラインメントを活用する方向なら抽出コスト。

430 :デフォルトの名無しさん:2010/05/09(日) 14:23:07
>424
厳格なGCにするとしてもポインタを工夫するだけの話だろ。グダグダ引っ張りすぎ。

構文なんてクソくらえ。newなんて(構文上は)グローバル関数でも構わないだろ。


431 :デフォルトの名無しさん:2010/05/09(日) 14:26:13
>>430
・生ポインタはGCの追跡性を阻害する。
・ポインタを工夫するとそれなりのコストが発生する。
ここは議論対象でしょう。

432 :デフォルトの名無しさん:2010/05/09(日) 14:29:06
>>391
> お互い論点の確認せずに持論しかいってないように見えるからよくわか
> らんとなってると思う。
論点は、「GCを、言語仕様に取り込まなかった場合どういう不具合が発
生するか」だろ、十分明確だと思う。
持論は >>364 は「不具合が思いつかない (≒不具合はない)」に対して俺
は、「不具合はある、理由は「確保したりソースが不要になったことを確
実に知ること」ができなくなる」と書いてる。
コード示せと言うから、コード示したら「わけわからん」とか「キチガイ
レベル」とか、まあ恥ずかしくて当分でてこれないとは思うが。

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

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

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

「リソースが不用になった」という情報。

433 :デフォルトの名無しさん:2010/05/09(日) 14:36:51
>431
> ・生ポインタはGCの追跡性を阻害する。
ポインタにメタデータ突っ込めるように拡張性を持たせればいいんじゃね?>389のように

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

そういった点を含めてポインタのスマポ化が一番簡単だと思うんだけど。

434 :デフォルトの名無しさん:2010/05/09(日) 14:37:32
C++で実装されてるアイディアって良く出来てるよな。
問題はいろいろ出来すぎて不具合が発生しているところだと思う。
コンセプトを立ててC++から必要な機能セットだけを抽出するという作業は面白そう。

435 :デフォルトの名無しさん:2010/05/09(日) 14:43:29
>>434
その辺で考えて書いても一晩経てば何故か使いやすいLWLの議論に
なってる(w

>>432
おい、白痴。

ポインター拡張するのなら構文の変更は必要ないんだから
黙って実装しとけや。

436 :デフォルトの名無しさん:2010/05/09(日) 14:45:43
おれC++では生ポインタ使ってて,JavaではマークアンドスイープのGC動作を期待してかいてるけど
shared_ptrを実用で使ったことない。
リーク0にしなければいけない状況だとして、循環参照が原理的に回避可能な手法ってあるの?

437 :デフォルトの名無しさん:2010/05/09(日) 14:46:48
循環参照する時はweak_ptrを使う
既に開放されてるかどうかがチェックできる

438 :デフォルトの名無しさん:2010/05/09(日) 14:47:17
あとはCの歴史的な事情から残ってる機能で弊害が大きいもののリストアップも欲しい。

439 :デフォルトの名無しさん:2010/05/09(日) 14:48:03
>>437
それは循環参照すると分かっているときは有効だけど
それを見分けるにはどうすればいいの?

440 :デフォルトの名無しさん:2010/05/09(日) 14:48:09
文字列リテラルを非constなポインタに入れられるとか

441 :デフォルトの名無しさん:2010/05/09(日) 14:49:17
>>440
これが理解できてなくて一日潰したことあるなw

442 :デフォルトの名無しさん:2010/05/09(日) 14:49:34
>>439
そもそも普通は循環参照など起こさないように設計する
どうしても循環参照しないといけない時に、循環参照をする
当然その時は循環参照することは分かっている

443 :デフォルトの名無しさん:2010/05/09(日) 14:51:25
スマートポインタはオブジェクト指向があっての物で
オブジェクト指向なしにしたいという話とはバッティングする。

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

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

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

どっちがいいんだ?

444 :デフォルトの名無しさん:2010/05/09(日) 14:51:55
>>442
循環参照を起こさない設計って具体的なノウハウあるの?
ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない?

445 :デフォルトの名無しさん:2010/05/09(日) 14:54:52
>>443
そんなことはないんじゃないの
C++では言語のレベルではスマートポインタを提供していないから
クラスとテンプレートを使ってそれを実装する必要があるというだけで、
言語のレベルでサポートするのなら、別にそれらは要らないと思うが

446 :デフォルトの名無しさん:2010/05/09(日) 14:57:36
>>444
常に循環参照が起こるかどうか考えながら設計すればいいだけじゃん?
まあ相互参照するようなクラスはまず作らないってのは基本だけど

447 :デフォルトの名無しさん:2010/05/09(日) 14:57:58
>>444
え?所有権のこともあやふやなんじゃ、スマポ使おうが使うまいが
C/C++でコードなんて書けないでしょうが

スマポ使わなきゃ所有権の問題が解決する?そんなわけない
スマポで楽にできるところまで面倒になるだけ

448 :デフォルトの名無しさん:2010/05/09(日) 15:00:14
>>447
マークアンドスイープは解決するでしょう?
おれはshared_ptrで原理的に回避する方法を思いつかないから
new/deleteで徹底する方法をつかってる。

449 :デフォルトの名無しさん:2010/05/09(日) 15:02:40
new/deleteで徹底できるなら
代わりにshared_ptr使えるでしょ

450 :デフォルトの名無しさん:2010/05/09(日) 15:05:43
むしろそんな循環参照なんて発生するか?
直接の親子関係があって、子に親を持たせるケースくらいでしか
発生しないと思うんだが

451 :デフォルトの名無しさん:2010/05/09(日) 15:07:20
>>449
いやnew/deleteのルールを決めることができるなら
(例えばコンストラクタ・デストラクタのみで行う。)解放は自動化することが出来る。
shared_ptrはこういうことが可能ではないと思ってるんだけど。
コードのチェック方法がシンプルになるだけでもいいんだけど。

452 :デフォルトの名無しさん:2010/05/09(日) 15:08:33
>>450
そんなに発生するかどうかは実用レベルでは試してないのでわかんないけど
おれは原理的に回避できるアイディアが思いついてない。

453 :デフォルトの名無しさん:2010/05/09(日) 15:11:02
クラスAがクラスBを生成するとする
仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
クラスB以降でクラスAを通じた循環参照は原理的に発生しない

そもそも循環参照って部品化がうまくいってない事の証拠だから
大抵設計がおかしい

454 :デフォルトの名無しさん:2010/05/09(日) 15:11:14
>>444
>ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
>それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない?

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

shared_ptrを渡す必要があるのは、相手も所有権を必要としているときだけだ
だから、そう書いていれば自動的に明確だろ

455 :デフォルトの名無しさん:2010/05/09(日) 15:12:50
>>453
>仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
この前提は厳しすぎない?
クラスAを親、クラスBを子としたときに
子が親の状況が見れないって制限厳しすぎると思うんだけど。

456 :デフォルトの名無しさん:2010/05/09(日) 15:14:32
>>455
普通だろ
それを乱用している事自体、設計がなってない
当然必要な状況もあるけどな

457 :デフォルトの名無しさん:2010/05/09(日) 15:14:55
>>454
なるほど所有権を使わないという宣言として生ポインタを渡すのか。
勉強になりました。

458 :デフォルトの名無しさん:2010/05/09(日) 15:18:44
クラス図でも書けばいいんじゃない

459 :デフォルトの名無しさん:2010/05/09(日) 15:19:26
>>454
これ目からうろこなんだけどこういう言及してる本ってあるの?

460 :デフォルトの名無しさん:2010/05/09(日) 15:22:18
>>459
お前ポインターさわるな。

461 :デフォルトの名無しさん:2010/05/09(日) 15:22:22
そもそも関数内で使うだけなら
引数にshared_ptr使っていようが循環参照は起きない
メンバに保持しない限り

462 :デフォルトの名無しさん:2010/05/09(日) 15:22:48
>>460
いやお前リークしまくりだと思うわ

463 :デフォルトの名無しさん:2010/05/09(日) 15:24:24
今時リークしたらデバッグ実行終了後にレポート出るだろ

464 :デフォルトの名無しさん:2010/05/09(日) 15:24:33
>>461
使ってないことを明示するために生ポインタもらうってことなんだけど

465 :デフォルトの名無しさん:2010/05/09(日) 15:27:22
別に保持しない事の明示にならないと思うが
生ポでメンバに保持するかもしんないから
ダングリングポインタになるのを心配する必要があって
weak_ptrの方がよほど安心

でも、生ポ使う事が悪いとは言わないけど
全部スマポでやってらんないと思うし(コスト的な意味で)

466 :デフォルトの名無しさん:2010/05/09(日) 15:31:06
>>465
そこはルールだから。
ルール以上の決め事は言語仕様にでもするしかないと思うので。

467 :デフォルトの名無しさん:2010/05/09(日) 15:32:50
>>463
で一定条件下でしかでないリークに気づいて躍起になって原因を探すんですね。

468 :デフォルトの名無しさん:2010/05/09(日) 15:33:19
ルールは全員が確実に守る事が前提にあるから
あまりそれに頼ると困ったりするのよね
まあ悪いルールではないと思うけど

469 :デフォルトの名無しさん:2010/05/09(日) 15:34:52
それはルール違反を検出するツールで対応するしかないと思うな。
その一手法が言語仕様。

470 :デフォルトの名無しさん:2010/05/09(日) 15:36:14
生ポ、スマポ以外にシェアポとかウェイクポとかもあるんですか?

471 :デフォルトの名無しさん:2010/05/09(日) 15:37:06
今扱ってるプログラムはCOMの扱いが分かってなくてリークしまくってるわ
プロジェクトに入ってから指摘してももう遅いってんで完全に放置状態だが
どうせ起動時に確保して終了時まで使うからリークしてもいいよね、みたいな状態

472 :デフォルトの名無しさん:2010/05/09(日) 15:39:28
>>470
議論の本流とは外れるけど、
直ぽとか仮ぽとか近ぽとか遠ぽとか巨ぽとか

473 :デフォルトの名無しさん:2010/05/09(日) 15:40:10
ぬるぽ

474 :デフォルトの名無しさん:2010/05/09(日) 15:40:24
>>435
> ポインター拡張するのなら構文の変更は必要ないんだから
> 黙って実装しとけや。

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

>>389 見ろなんて言われたら、笑うしかないが。

475 :デフォルトの名無しさん:2010/05/09(日) 15:41:29
ポインタにメタデータとか
従来通りに使おうとする際にコストかかるからな
低級言語的にはアウト

476 :デフォルトの名無しさん:2010/05/09(日) 15:45:27
>>454だが
関数の間口を不必要に狭めず、なるべく汎用性を上げる方針で書けば、
>>454のような帰結は自動的に出てくるはずなんだけどね

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

勿論、これによってコードの意図が明確になるというご利益も得られるので
いいことずくめだよ

477 :デフォルトの名無しさん:2010/05/09(日) 15:49:46
だな

478 :デフォルトの名無しさん:2010/05/09(日) 15:50:04
自動的にでてくるはずの帰結なんだけどあまり流通してないのはなぜだろうね。

479 :デフォルトの名無しさん:2010/05/09(日) 15:56:04
>>478
>>462が生活してる現実。

480 :デフォルトの名無しさん:2010/05/09(日) 15:57:04
>>479
じゃあお前も防衛しとかないとダメじゃん。高みの見物気取ってる場合じゃないぞw

481 :デフォルトの名無しさん:2010/05/09(日) 16:02:40
>>480
なんでおいらが関数定義の詳細化を提案してるのか、
理解できてないようだ。



482 :デフォルトの名無しさん: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が出来たり、
型サイズチェックできたり、
クラスに拡張したり、いろいろ有用そう。


483 :デフォルトの名無しさん:2010/05/09(日) 16:03:52
>>481
お前が誰か分からんわw

484 :デフォルトの名無しさん:2010/05/09(日) 16:08:41
>>483
俺は>>462がエンジニアとしてお金もらっちゃ詐欺になるレベルだと分かる。
誰か?は分からないけども。2chなんだからそれで充分。

485 :デフォルトの名無しさん:2010/05/09(日) 16:10:35
関数定義で抽出したら対人コミュスキル不全がでてきたw

486 :デフォルトの名無しさん:2010/05/09(日) 16:12:45
>>482
何をやりたいのかよくわからんけど、GC の問題が構造体の名前、
型やサイズ等の型情報でどうかなるわけではないことを知ってお
いたほうがいい。

487 :デフォルトの名無しさん:2010/05/09(日) 16:13:02
無脳が人を見下すスレ

488 :デフォルトの名無しさん:2010/05/09(日) 16:22:17
でもキミや俺みたいに無意味なレスするやつよりマシだけどな。

489 :デフォルトの名無しさん:2010/05/09(日) 16:24:32
こんなにまとまらないくらいなものまとめるくらいならC使ってるわという気持ち。

490 :デフォルトの名無しさん:2010/05/09(日) 16:42:17
>>483
Eulerだろ。

491 :デフォルトの名無しさん:2010/05/09(日) 17:21:34
>>486
では何がそろえばGCを完全にできる?


492 :デフォルトの名無しさん: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

493 :デフォルトの名無しさん:2010/05/09(日) 17:33:27
多少のコストは払ってもいいので完全なGCをCレベルで使って簡潔に
プログラムしたい。

494 :デフォルトの名無しさん:2010/05/09(日) 17:35:32
スタック上やオブジェクト内にある参照でないデータも、参照をあらわすデータと見なして処理を進めるから
保守的になっちゃう。

495 :デフォルトの名無しさん:2010/05/09(日) 17:37:03
おまえの言ってるCレベルが分からん。
やろうと思えばC++のライブラリでも出来ると思うんだが
ここでいうC++とCレベルの違いは何?

496 :デフォルトの名無しさん:2010/05/09(日) 17:45:48
>>495
クラスを使うかどうかかな?
C++いらんいう人がいるので。
リファレンスカウンタ方式ではないGCも選択出来たりしたらいいのかなと。
自分はC言語のライブラリレベルでGC可能なAPIを作って、それようの
シンタックスシュガーをマクロで実現できたらいいなと考えてる。
マクロもテンプレートもコンパイルタイムプログラミングって意味で
似たようなものだから、テンプレートはありと思ってる。

497 :デフォルトの名無しさん:2010/05/09(日) 17:46:09
◆新言語でのリソース管理方針◆

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

※GCは手段であって上記が満たされていれば必ずしも必須ではない。

498 :デフォルトの名無しさん:2010/05/09(日) 17:48:51
何その言い換えw

499 :デフォルトの名無しさん:2010/05/09(日) 18:06:51
完全なマークアンドスイープはC++クラスなしなら言語側に機構を持たないと無理。
C++ライブラリとしてなら実装可能だと思ってたけど実際に実装されてるライブラリって知らないや。
何か問題あるのか?

500 :デフォルトの名無しさん:2010/05/09(日) 18:09:21
>>498
>>496>>497は別人だよ

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

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

でも、全部出来るわけじゃないと。
その仕事をうまいことラップ出来たりしたらいいなと。
Rubyのいいところは拡張を綺麗に書けることだけど、
もっと綺麗にできたらいいなぁっと。
それでいてメモリ管理のやり方を変えても大丈夫なように出来てたらいいな

501 :デフォルトの名無しさん:2010/05/09(日) 18:11:47
ますます分からんお前。そもそも>>496とつながってるとは思わんし。

502 :デフォルトの名無しさん:2010/05/09(日) 18:12:03
>>499
わからないけど、探せばあるのかも。
今書き込んだ話も、この議論を見てて思いついたことだからなぁ。

503 :デフォルトの名無しさん: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


504 :デフォルトの名無しさん:2010/05/09(日) 18:33:23
実装の話は後でいいよ

505 :デフォルトの名無しさん:2010/05/09(日) 18:37:21
実装可能性の判断は必要だよ

506 :デフォルトの名無しさん:2010/05/09(日) 18:38:49
まあそうだな。じゃあ可能ってことで。

507 :デフォルトの名無しさん:2010/05/09(日) 18:41:37
じゃあおまえのレスの正当性を判断しようか

508 :デフォルトの名無しさん:2010/05/09(日) 18:52:08
>>491
何を持って「完全」と言うのかによるけど、shared_ptr ぐらいで我慢する
なら C++ のテンプレートレベルでいいし、きちんと管理したいのであれば
言語のサポートがないとどうにもならないと思う。

509 :デフォルトの名無しさん:2010/05/09(日) 18:57:38
ポインタにタグを付けなきゃいかん、となると、OSどころか(というか、OSよりも)
ハードウェアでどうにかしないとだよな。

510 :デフォルトの名無しさん:2010/05/09(日) 18:58:54
また適当な話になってまいりました。

511 :デフォルトの名無しさん:2010/05/09(日) 19:09:41
>>508
きちんと管理する場合に最小限の言語仕様は何だと思います?



512 :デフォルトの名無しさん:2010/05/09(日) 19:39:33
・利用されなくなったリソースの検出
・検出した時の処理の登録
・処理を明示的に登録されないかった場合のデフォルト処理

513 :デフォルトの名無しさん: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関数は普通に使える。


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

GC管轄外のリソースならこの限りではない。

515 :デフォルトの名無しさん:2010/05/09(日) 20:06:05
何が言いたいのか不明

516 :デフォルトの名無しさん:2010/05/09(日) 20:07:41
脳内妄想をたれ流すスレ

517 :デフォルトの名無しさん:2010/05/09(日) 20:08:57
------ここまで適当に読まなかった-------
GC派とそれ以外でスレを分けたらいいと思う

518 :デフォルトの名無しさん:2010/05/09(日) 20:29:26
GARNET CROWと巨人対広島で分ければいいじゃない

519 :デフォルトの名無しさん:2010/05/09(日) 20:30:30
>>473
ガッ

520 :デフォルトの名無しさん:2010/05/09(日) 20:57:07
C++とポインタとGCの勉強会終わった?

521 :デフォルトの名無しさん:2010/05/09(日) 21:09:09
ノイズだらけでスレの意味が全くない
にちゃんのけいじばんのつかいかたをがくしゅうしよう!

522 :デフォルトの名無しさん:2010/05/09(日) 21:11:09
>>521
1行目へのレスが2行目の文なんだよな?
自己完結してる。

523 :デフォルトの名無しさん:2010/05/09(日) 21:30:31
>482
GCやるのならば型情報とオブジェクトの情報、参照元の情報がそれぞれ必要。
それぞれの情報を誰が管理するのかという話もあるけど。
(ポインタが管理するのか、GCが管理するのか、システムが管理するのか)

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

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

あと、constは制限緩すぎじゃね?効率も良くないし。
むしろClojureみたいに基本は変更不可・必要に応じて書き込みチャネルを用意した方がマシだろ。
将来的にチャネルを多機能化(トランザクション対応とか)できるし。


524 :デフォルトの名無しさん:2010/05/09(日) 21:32:22
>>523
> ムリ言うなよ。所有者が始末するのが前提だろ。後始末しなくて良いわけじゃない。

「明示的に」って書いているけど?

525 :デフォルトの名無しさん:2010/05/09(日) 21:44:02
>524
そうするとGC必須にならない?オブジェクトが所有するリソースは明示的に解放しないとダメだろ。

526 :デフォルトの名無しさん:2010/05/09(日) 21:48:33
>>525
「そうするとGC必須にならない?(GCが無ければ)オブジェクトが所有するリソースは明示的に解放しないとダメだろ。 」
って言いたいの?

527 :デフォルトの名無しさん:2010/05/09(日) 21:49:08
GC言ってる奴は回線切って一通り実装して動かしてからこい

528 :デフォルトの名無しさん:2010/05/09(日) 22:06:48
このスレはMultics つまりUnixを再現するための布石なんだよ!

529 :デフォルトの名無しさん:2010/05/09(日) 22:07:55
GC欲しがるのは私はメモリ管理もできない無能ですと言ってるのと同じ


530 :デフォルトの名無しさん:2010/05/09(日) 22:11:38
>>527-529

531 :デフォルトの名無しさん:2010/05/09(日) 22:11:57
>>528
言語だからどっちかっつーとPL/Iじゃね?

532 :デフォルトの名無しさん:2010/05/09(日) 22:17:40
神の作ったgoの仕様を100回見てこいよw
ほとんど全てがあるぞ。gc必須以外な

533 :デフォルトの名無しさん:2010/05/09(日) 22:23:11
C++の代わりは既にいくらでも存在する。このスレで議論すべきはC言語の代替である。
次スレからはC++を除外、もしくはスレを分けよう。
そうすれば低水準言語にOOPや例外を、などとのたまうアフォ連中もいなくなるだろう。

534 :デフォルトの名無しさん:2010/05/09(日) 22:25:32
低水準言語にOOPや例外はいらない、などとのたまうアフォを避けるために
わざわざC++を入れたんだろ。

535 :デフォルトの名無しさん:2010/05/09(日) 22:25:54
まだアホがいるのか

536 :デフォルトの名無しさん:2010/05/09(日) 22:28:33
まぁまぁ。
GCの話が嫌なら、GC以外の話すればいいっしょ。

537 :デフォルトの名無しさん:2010/05/09(日) 22:40:13
>534
例外やOOPを実装するための機能なら議論しても良いが、例外やOOPそのものを議論するのはアホ過ぎる。
何でそんなに汎用性の無い機能を今の段階で議論するんだよ。

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

>532
golangにマクロってあったっけ?
あとサブルーチン以外のルーチンとか

538 :デフォルトの名無しさん:2010/05/09(日) 22:46:01
例外やOOPの議論がアホなら、マクロとルーチンの話もアホだろw
ドアホw

539 :デフォルトの名無しさん:2010/05/09(日) 22:46:52
>>537
> あとサブルーチン以外のルーチンとか
その名も五郎ちゃんとかゴルーチンとかいうのがあるよ

540 :デフォルトの名無しさん:2010/05/09(日) 22:47:30
神はmacroなんていらないって判断なんだよ
クロージャは作れるぜ

てか、Windowsプログラマは低レベルなんて縁がないんだから
大人しくC#でも使ってなさいってこったな


541 :デフォルトの名無しさん:2010/05/09(日) 22:47:45
じゃあ、マクロの話しよう。

542 :デフォルトの名無しさん:2010/05/09(日) 22:53:19
マクロなんてお前にゃどうせ使いこなせねえだろ

543 :デフォルトの名無しさん:2010/05/09(日) 22:54:42
C言語にあのマクロがなかったら、
とたんにクソ言語の1つになるんだぜ

544 :デフォルトの名無しさん:2010/05/09(日) 22:55:14
>>542
マクロなんてそんなに怖がるほどのものじゃないよw

545 :デフォルトの名無しさん:2010/05/09(日) 23:00:07
俺はlispもOKだから別にって感じだが
Cのマクロは言語仕様じゃねえし
constとinlineで大半が不要だし

546 :デフォルトの名無しさん:2010/05/09(日) 23:01:46
constとマクロの何が関係あるんだ
templateの間違いか?

547 :デフォルトの名無しさん:2010/05/09(日) 23:03:19
>>546
こういうの↓を言ってるんだろ。たぶん。

#define VALUE 8

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

CのマクロはLispよりずっと貧弱だが、#ifdefに限らずマクロを必要とする物は
沢山あるでしょ

549 :デフォルトの名無しさん:2010/05/09(日) 23:06:34
構文いじれるマクロなんて
オナニー用だからな

550 :デフォルトの名無しさん:2010/05/09(日) 23:07:03
Cには遅延評価やcall-by-nameは存在しないので
それっぽい(あくまで「ぽい」)ことを実現するのにマクロを使うこともある
要は式をそのまま渡したければマクロしかない

文字列化マクロとかトークンペーストマクロみたいなのも、マクロじゃないと
出来ないよ

551 :デフォルトの名無しさん:2010/05/09(日) 23:11:08
条件コンパイルもコンパイル時に値を渡せれたら問題ない

552 :デフォルトの名無しさん:2010/05/09(日) 23:20:02
マクロは何よりも「引数を評価しない関数」としての機能が欲しいな。
これ自体は遅延評価でも引数を評価しない関数そのもの(Lispに昔あったそうな)でもいいけど、
この機能があれば制御フローなんかも実装できるようになる。

あとは名前関連で安全な仕組みもほしい。
自分で長たらしい妙な名前を付けるのは面倒だから止めたいなぁ。

553 :デフォルトの名無しさん:2010/05/09(日) 23:22:40
> 引数を評価しない関数そのもの
これがcall by nameでしょう
俺の知る限りではLispは正格言語であって、call by nameしたけりゃ
マクロだよ
だからLispのspecial formはマクロじゃないと書けない

call by nameで有名な古典的な例はAlgol60らしいんだけど
俺触ったこと無いから知らないw

554 :デフォルトの名無しさん:2010/05/09(日) 23:32:35
Cのマクロで違う言語を作ろうとすると破綻するが(例boost)、
LISPでは破綻しない。
んなぜか

555 :デフォルトの名無しさん:2010/05/09(日) 23:38:20
lispはマクロと普通の関数の違いが少ないからな
どうせ同じデータ扱うだけだし
その分人間には読みにくい

556 :デフォルトの名無しさん:2010/05/09(日) 23:39:32
構文木を認識できて、その言語自身と同じ(異質でない)構文で構文木を
操作できるなら、Lispマクロと同等に強力と言えるんじゃないかな

557 :デフォルトの名無しさん:2010/05/09(日) 23:41:41
それ簡単に言うがlispの用に簡単には行かないな
あいつはデータもマクロも関数も全部First classのlistだからこそ美しい

558 :デフォルトの名無しさん:2010/05/09(日) 23:42:12
>>554
お前がCを知らないから
お前がboostを知らないから
お前がLISPを知らないから

の全部。

559 :デフォルトの名無しさん:2010/05/09(日) 23:43:50
LISPでOCamlを作ろうとすると破綻するが
.NETでは破綻しない。

560 :デフォルトの名無しさん:2010/05/09(日) 23:46:49
>>557
それは全く同意なんだけどね…

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

Scalaは、いわゆるマクロじゃないけど、ルーズな構文と、演算子多重定義や
ブロックのおかげで、「構文っぽく」見えるものを構築できるようになってるね

561 :デフォルトの名無しさん:2010/05/10(月) 00:05:36
DSLは。。。どんだけドメインつくって言語作るんだよって感じで
いずれ見捨てられるか収束する技術だねえ

てか、いずれにしろ高階な言語でないと高度なマクロはおいしくないし。
個人的には低レベルな言語から動き回れるポインタもなくしたいところだね

562 :デフォルトの名無しさん:2010/05/10(月) 00:07:07
なんかコンセプトからはちゃめちゃだな

563 :デフォルトの名無しさん:2010/05/10(月) 00:09:08
いあ、組み込み屋だから低レベルはかなりやってるが
動き回れるポインタをなくして配列の範囲チェックはあってもいい
golangのsliceはunsafeで任意のアドレスを割り当てることが出来るから
そういうのと最適化で効率は十分取れると思うんだよな


564 :デフォルトの名無しさん:2010/05/10(月) 00:14:05
>>563
goってそんなsliceあるんだ
それは便利だなー

565 :デフォルトの名無しさん:2010/05/10(月) 00:15:10
裏技的な使い方だしvolatileじゃないからI/Oには不向きだけどね

566 :デフォルトの名無しさん:2010/05/10(月) 00:18:46
もうD--を考えてみてはどうか。
Dはここで議論されている新言語にしては機能過多なので、
高級機能はけずるかたちで。

567 :デフォルトの名無しさん:2010/05/10(月) 00:19:28
>>565
まあ裏技とか低水準なことをさておいても、
そういう普通に欲しいものが無い言語多いんだよねー

Cで配列の部分を参照するためにポインタを使うのはよくあるユースケースだけど
Javaとかだと配列全部とレンジ情報を引き回すしかないし
Pythonにはスライスあるけどコピーになるから

568 :デフォルトの名無しさん:2010/05/10(月) 00:20:46
組み込みではどうせメモリのほとんどは最初に確保するか静的に確保するから
解放にからむメモリリークはあんまないけど
オーバーランとかに絡むエラーの方がとりにくいんよね
単に固まるだけとかで情報取れないこと多いし。
だからバッファサイズがわかるとかオーバーをチェックする仕組みの方がありがたい

569 :デフォルトの名無しさん:2010/05/10(月) 00:23:15
>>567
sliceは結局struct { void * ptr; int count; int max; } って感じの
組み込みデータ型だからレンジ情報は引き回す形になって
オーバーヘッド0って訳にはいかないけど
最適化次第とトレードオフかなと。

570 :デフォルトの名無しさん:2010/05/10(月) 00:25:01
>>566
おいらはEmbedded Go Langって感じのが欲しいw

571 :デフォルトの名無しさん:2010/05/10(月) 00:25:11
>>360
ポインタというか参照型は重要。
Javaのオブジェクトはみんな参照型。
新言語でもそういう条件をつけてメモリ効率をあげてみてはどうだろう。

572 :デフォルトの名無しさん:2010/05/10(月) 00:26:54
>>363
> 既存のGCの問題点
>
> ・利用形態を問わず管理する人(メモリマネージャもどき)が絶対に必要
> ・効率優先である程度まとめてGC処理を走らせるためCPU時間を占有する

JavaではそのためにSoftReferenceってやつがあるんだけど。
メモリ節約のテクニックやパフォーマンスチューニングのテクニックはJavaにもちゃんとあるんで。

573 :デフォルトの名無しさん:2010/05/10(月) 00:28:13
>>367
もっとパフォーマンスが堕ちるからやめてくれ

574 :デフォルトの名無しさん:2010/05/10(月) 00:29:04
>>367はネタでしょw
笑えるかどうかはさておき

575 :デフォルトの名無しさん:2010/05/10(月) 00:30:50
>>375
ついでに参照型と値型の違いも禁止するのはどうだろう。
intやdoubleなどの基本データ型はすべて値型で
それ以外の構造体、配列、文字列、リスト構造などはすべて参照型に。
そしてメソッドの引数に渡すときは参照渡しではなく参照をコピーして渡す
ということで。

これでメソッドに引数に&や*を付ける必要がいっさいなくなり、
ソースコードも読みやすくなる。

576 :デフォルトの名無しさん:2010/05/10(月) 00:33:29
それ何てJava

577 :デフォルトの名無しさん:2010/05/10(月) 00:35:05
>>392-393
そんなマゾいことしないでデフォルトでGCありにすればいい。

どうせならdeleteが必要なnew、ngcnewでも作るべき。
そしてこのngcnewは容易に使えないよう、例外的使用方法とする。

578 :デフォルトの名無しさん:2010/05/10(月) 00:38:52
またC++/GC/ポインタの勉強会になりそうだから傍観するわw

579 :デフォルトの名無しさん:2010/05/10(月) 00:39:59
黙ってしてればいいだろ。宣言なんていらんよ。

580 :デフォルトの名無しさん:2010/05/10(月) 00:40:59
>>438
scanf()
getchar()
string

581 :デフォルトの名無しさん:2010/05/10(月) 00:43:01
>>579
GCやコンパイラの知識くらい言語設計するなら知ってるはずだろ
今更こんな話出てもつまらんって話だよ
MSのセンスねえ拡張に毒された話もつまらんし

582 :デフォルトの名無しさん:2010/05/10(月) 00:44:11
傍観するんじゃなかったの?

583 :デフォルトの名無しさん:2010/05/10(月) 00:44:11
Booも、オフサイドルール使うのかぁ。
力ありあまってるのかなぁ?
オフサイドルールって簡単に実装できるんだろうか?

584 :デフォルトの名無しさん:2010/05/10(月) 00:45:11
>>582
あい。黙りますw

585 :デフォルトの名無しさん:2010/05/10(月) 00:48:02
勉強会はいいが半日たたずにループはきつい。

586 :デフォルトの名無しさん:2010/05/10(月) 00:50:42
勉強会になるだけマシ。
普段はお互い自分も理解してない単語の羅列が書き込まれてるだけだし。

587 :デフォルトの名無しさん:2010/05/10(月) 00:53:19
>>583
難しく考えすぎだと思う

字句解析の時、インデントが同じレベルの部分を認識して
前後にブロック部分を表すトークンをはさむだけ
後はふつうの言語と同じ具合に構文解析できる

588 :デフォルトの名無しさん:2010/05/10(月) 00:54:57
S式をアルゴル風な式に置き換えればいい。
Listじゃなくて演算子が式と式を結ぶ構文木を扱えばいい。
Consにタグが付いただけだからそんな複雑じゃなくてすむ。
コンパイルタイムではJavaScriptっぽい言語で式をいじればいいだけさ。

589 :デフォルトの名無しさん:2010/05/10(月) 00:56:23
何言いたいんだ

590 :デフォルトの名無しさん:2010/05/10(月) 00:56:55
>>583
難しく考えてないんですけど。短いソースでお願いします。

591 :デフォルトの名無しさん:2010/05/10(月) 00:58:04
新言語では、ソース中でのタブ文字の使用を禁止したい。
あるいは、ソース中のタブ幅を例えば4文字に固定したい。

592 :デフォルトの名無しさん:2010/05/10(月) 01:07:12
ループしてないようでよかったぜw
>>588
tcl乙

593 :デフォルトの名無しさん:2010/05/10(月) 01:12:36
知ってる単語自慢大会

594 :デフォルトの名無しさん:2010/05/10(月) 01:16:58
新言語に関係があれば、ループでも、知ってる単語自慢大会でも、いいよ。

興味がなければ、その流れに参加しなければいいだけだから。

595 :デフォルトの名無しさん:2010/05/10(月) 01:19:58
>>593
知らない単語にめげてる人:1

596 :デフォルトの名無しさん:2010/05/10(月) 01:20:27
tclはつかえない。理由は忘れた

597 :デフォルトの名無しさん:2010/05/10(月) 01:21:23
>>588
S式と違って、アルゴル風な式は、見た目と構文木の構造が一致しないから
コンピューターにとっては複雑じゃなくても、人間にとっては扱うのが難しい。

598 :デフォルトの名無しさん:2010/05/10(月) 01:21:50
今のTclって関数がファーストクラスになってるんだっけ
そうじゃなけりゃ
いまどきファーストクラスの関数を持たないLLの人って…
って感じ

599 :デフォルトの名無しさん:2010/05/10(月) 01:22:14
>>578
C++/GC/ポインタの話についてこれない人:1

600 :デフォルトの名無しさん:2010/05/10(月) 01:23:00
どこが低級言語の話だかよくわからない

601 :デフォルトの名無しさん:2010/05/10(月) 01:23:56
>>600
初心者にはすぐにはわからないかも。
頑張れ。

602 :デフォルトの名無しさん:2010/05/10(月) 01:24:54
ひどいいいぐさだな。tcl/tkな人。すいません。
tcl/tkは検討したのだけど、命令からパラメータ数が決まるとかいう
点がいまいちだと思ったんだったと思う。

603 :デフォルトの名無しさん:2010/05/10(月) 01:25:01
>>599
C++は嫌いだが、lispとかSTの実装経験くらいなら学生の頃やったぜw
copy GCとリファカウントだけどなw

604 :デフォルトの名無しさん:2010/05/10(月) 01:26:55
>>601
お前わかってないだろw

605 :デフォルトの名無しさん:2010/05/10(月) 01:28:14
マクロだかマグロだかの話は低級高級関係ないお!
どんなに高級複雑なマグロでもプリプロセス/コンパイル時の話だからな!

606 :デフォルトの名無しさん:2010/05/10(月) 01:29:08
多分、>>601がトリップ付けるだけで解決する

607 :デフォルトの名無しさん:2010/05/10(月) 01:29:48
このスレ、id出して欲しいなw

608 :デフォルトの名無しさん:2010/05/10(月) 01:30:57
id出さなくても/w$/で抽出できる。

609 :デフォルトの名無しさん:2010/05/10(月) 01:31:03
オンデマンドに強制ID付きでスレ立てできるようになるといいな
別に全スレでとは言わないから

610 :デフォルトの名無しさん:2010/05/10(月) 01:32:17
>>588
おお、それじゃ、俺は理解できてるから人間をこえているのか?やった!
ってそんなことはないって。
BNFベースにするから構文木が分かりにくくなるので
演算子で繋がってるだけのものって理解すれば、そんな難しくないよ。

611 :デフォルトの名無しさん:2010/05/10(月) 01:33:17
>>608
ありがとw
603だが604とは別人だよw
全角半角でいれといた

612 :デフォルトの名無しさん:2010/05/10(月) 01:44:54
>>605
そんなことはない!
マクロは高級言語では他の機能で代替可能で分かりやすいから必要なくなる。
だけど、低級言語では機能が少なかったりスピード求められたりするから
明るく輝くんだ!あの夜空に輝く星々のように!

613 :デフォルトの名無しさん:2010/05/10(月) 02:27:40
だからマクロはユーザーカスタマイズ可能なコンパイラだって。

614 :デフォルトの名無しさん:2010/05/10(月) 02:39:32
構文いじるのは高階な関数系の言語にしとけって
Algol系では不要
FOREVER { }
とか書いてあったら恥ずかしいだろうが。

615 :デフォルトの名無しさん:2010/05/10(月) 02:40:52
ユーザーカスタムって大抵可読性下がるよね

616 :デフォルトの名無しさん:2010/05/10(月) 03:01:08
inlineもconstもない頃に仕方なく出来たcpp
昔はいいアイデアだったが今は弊害の方が大きいという認識だな
KenTompsonもgolangには全く入れてないし

617 :デフォルトの名無しさん:2010/05/10(月) 03:04:22
とりあえず普段Cのマクロで「何を実現しているか」をリストアップしてはどうか?
本当にプリプロセスじゃなきゃできないことなのか、実は言語の一構文として組み込める処理なのか。
今のマクロはいわば「マクロ言語」とでも呼ぶべき独自路線と大域スコープで色々と問題を含む。
少なくとも言語本体と同じ構文でプリプロセスを書けるようにしたい。
inline constよりも確実で厳密な、完全なるインライン定数を定義するための修飾とかね。

618 :デフォルトの名無しさん:2010/05/10(月) 03:04:24
神の名前をTypoしちまった
Kenneth Lane Thompson様すんません

619 :デフォルトの名無しさん:2010/05/10(月) 03:10:33
constで定義した定数が確実で厳密でないってなに
cppは昔は良かったんだよ。コンパイラをシンプルに出来たからな。
条件コンパイルは今でも有用だが、代替手段は普通にあるし。

620 :デフォルトの名無しさん:2010/05/10(月) 03:42:29
最初はenumもなかったな
こっちの方が定数定義に向いてるんじゃね

621 :デフォルトの名無しさん: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とそれぞれ使い分けている

622 :デフォルトの名無しさん:2010/05/10(月) 14:34:43
まあ、おおむねC++やDで対応されてるかなあ、という辺りか

623 :デフォルトの名無しさん:2010/05/10(月) 14:38:38
Cがなぜあれだけの機能しかないのかを分かっていないやつが多すぎ。

624 :デフォルトの名無しさん:2010/05/10(月) 17:42:15
プリプロセッサのへぼさも理由があるしな

625 :デフォルトの名無しさん:2010/05/10(月) 19:29:53
昔の理由なんて今通用するとは思えない

626 :デフォルトの名無しさん:2010/05/10(月) 20:24:20
CPUのアーキテクチャもソフト工学も30年前から細かいとこしか進歩してないんだよ。ボク。

627 :デフォルトの名無しさん:2010/05/10(月) 20:51:47
じゃあ説明してくれ

628 :デフォルトの名無しさん:2010/05/10(月) 23:27:09
知ったかぶり大会に説明など不要

629 :デフォルトの名無しさん:2010/05/11(火) 00:08:08
>>621
これってCのプリプロセッサディレクティブ?

630 :デフォルトの名無しさん:2010/05/11(火) 01:27:10
>>455
フィールドやメソッドをprivateにすれば見えなくて当然。
protecedじゃないんだから。

631 :デフォルトの名無しさん:2010/05/11(火) 01:32:49
またアホがきた

632 :デフォルトの名無しさん:2010/05/11(火) 09:45:40
Cのプリプロセッサレベルで残すものは、__FILE__,#lineくらいでいいんじゃない?
ってのがD言語。それ以外は言語機能に組み込む。
LISPのマクロ言っているのは、C++やD等のテンプレートの先を言ってる。
何が何だか分からないのが問題なのでマクロでも何が何だか
分かるマクロで汚くなければ、問題はないと思うのです。


633 :デフォルトの名無しさん:2010/05/11(火) 09:48:07
下降型の演算子順位法ですら難しい言われるのに、
短い例も出せないオフサイドルールはS式の代わりにはできそうにない。




634 :デフォルトの名無しさん:2010/05/11(火) 17:29:53
構文いじって綺麗なわけない
コードがどう展開されるかの予想が付くのが
Cの利点というか低レベル言語に要求されることの一つだと思うぜ
そういう意味でC++はあんま低レベルとはいえん

635 :デフォルトの名無しさん:2010/05/11(火) 17:34:21
いい加減もうCでいいじゃん
マクロフル活用でオサレっぽくかけるようにすりゃ十分だろ?

636 :デフォルトの名無しさん:2010/05/11(火) 17:37:44
いにしえのratforみたいだな

637 :デフォルトの名無しさん:2010/05/11(火) 17:39:20
最初のC++とかObjective Cとかもだね

638 :デフォルトの名無しさん:2010/05/11(火) 18:18:56
いいかげん既存の言語にラッパークラスをライブラリとして自作して追加するだけでいいんじゃねって
思えてきた

639 :デフォルトの名無しさん:2010/05/11(火) 19:17:19
さて、ここにいるのは何割プログラマやってる人?SEでも。オレは会社でコボルいじってるけど

640 :デフォルトの名無しさん:2010/05/11(火) 19:53:23
__FILE__, __LINE__ なんて、
コールスタックをダンプする機能があれば不要

641 :デフォルトの名無しさん:2010/05/11(火) 21:05:27
ネイティブでコールスタックダンプとか、D言語でやって楽しかった。
GDBでオッケーとかいう話もあった。


642 :デフォルトの名無しさん:2010/05/11(火) 21:06:48
GoLangってネイティブで厳格なGCついててっていいかんじっすね。
あとはマクロを使えれば、、、。

643 :デフォルトの名無しさん:2010/05/11(火) 22:09:51
LISP風マクロを追加する試みって既に昔からあるよね
結局LISPのラッパーな感じだけど


644 :デフォルトの名無しさん:2010/05/11(火) 22:12:03
だからGCはいらないと何度言ったら。
CでもGCできるんだからさ、各自で勝手にやればいいんだよ。

645 :デフォルトの名無しさん:2010/05/11(火) 22:12:03
パズルみたいになるマクロいらない。

646 :デフォルトの名無しさん:2010/05/11(火) 22:23:46
m4とかな

647 :デフォルトの名無しさん:2010/05/11(火) 22:36:10
JavaPPって使ってた人いる?

648 :デフォルトの名無しさん:2010/05/11(火) 23:04:52
Cプリプロセッサはマクロ中でマクロ定義できたらよかったのに
ちょっと中途半端なだけなんだよ

649 :デフォルトの名無しさん:2010/05/11(火) 23:08:31
禿同

650 :デフォルトの名無しさん:2010/05/11(火) 23:31:33
じゃあcalleeの中でcallerのローカル変数を定義できたらよいと思うか?
そんなものはレキシカルスコープが崩壊するだけだろ

651 :デフォルトの名無しさん:2010/05/11(火) 23:46:40
プリプロセッサでは #line こそ必要不可欠

652 :デフォルトの名無しさん: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 ウルトラマンZ80
バグひな 戦え!超OS生命体TRONスフォーマー gccさくら
キャプテンmalloc 金色のハッシュ! おねがいt_char typoしちゃうぞ
フォートラーン戦記 Excelサーガ getcharロボ 焼きたて!!JAVAん
データセンターあらし 忍者バグトリ君 ときめきメモリ枯渇 修羅のMON
ゴルゴ1B(バイト) Rubyポップは笑わない ELFを狩るものたち 迷宮組込

653 :デフォルトの名無しさん:2010/05/11(火) 23:56:57
>>652
なんか笑った

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

655 :デフォルトの名無しさん:2010/05/12(水) 00:26:26
>エリア8KB 千と千尋のバグ隠し typoしちゃうぞ getcharロボ データセンターあらし 
すげー笑った
ありがとう

656 :デフォルトの名無しさん:2010/05/12(水) 00:35:12
>>654
sizeof辺りの定数返すやつは欲しいなあ
あと、型が定義されているかとか

657 :デフォルトの名無しさん:2010/05/12(水) 00:39:21
>>642
golangはC的なMacroは特にいらないよ
条件コンパイルはちょいつらいが
Refrectionもあるしな
Cの代替は無理だがC++だな

658 :デフォルトの名無しさん: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()"/>

659 :デフォルトの名無しさん: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()"/>

660 :デフォルトの名無しさん:2010/05/12(水) 00:56:03
ということで、敵に塩を送ってしまった。
しかも、パーサじゃなくてレキサだわな

661 :デフォルトの名無しさん:2010/05/12(水) 02:02:11
>>652
くだらね
キモオタガンヲタは死ね

662 :デフォルトの名無しさん:2010/05/12(水) 02:29:03
中にはキモヲタ関係ないのも入っているが
まさしくどうでも良い

663 :デフォルトの名無しさん:2010/05/12(水) 02:50:37
>>660
オフサイドルールよく知らないんだけど
a
  b
 c
   d
 e
  f
g


(a ((b) c ((d)) e (f)) g)
みたいにはならないのかな

664 :デフォルトの名無しさん:2010/05/12(水) 06:00:47
>>658
それがどうした?としか

665 :デフォルトの名無しさん: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
というようなリソース管理に使えるかな、と思った
インデント構造でまっさきに思いつきそうなやつだけど

666 :デフォルトの名無しさん:2010/05/12(水) 09:02:10
>>665
改行を許さない糞言語は不要

667 :デフォルトの名無しさん:2010/05/12(水) 09:05:10
行末尾に\でもつければいいんだろ

668 :デフォルトの名無しさん:2010/05/12(水) 11:09:38
>>665
YAML?

669 :デフォルトの名無しさん:2010/05/12(水) 11:16:08
>>664
C言語風の式言語にはオフサイドルールはいらないと
言っているのはオフサイドルールを理解できない、
実装できないという理由からではない証明になったかと。

>>665
そういう設定用にはyamlがありますよね。

670 :デフォルトの名無しさん:2010/05/12(水) 11:21:58
>>660
ネストによってブロックを表現するのがオフサイドルールなので
必要以上にネストは深くする必要はないのだと思います。
こんなかんじで出来るよって例でタブも1文字と数えてるので
PythonやHaskell等の仕様とは違います。

671 :デフォルトの名無しさん:2010/05/12(水) 11:22:11
>>669
頭悪いのがコード貼り付ける前に、そんな議論あったか?
馬鹿がまたプログラムの勉強会始めたとか思ってたけど?

672 :デフォルトの名無しさん:2010/05/12(水) 11:23:00
自作自演でスレを埋めるの辞めて欲しい。

673 :デフォルトの名無しさん:2010/05/12(水) 15:52:09
いい加減、お前らが作りたい言語の仕様をしっかり定義しろよ

674 :デフォルトの名無しさん:2010/05/12(水) 19:34:35
C言語とLISPの合体したコンパイラ

#lang lisp
(defun lisp () (puts "hello world"))
#lang c
int main() {
lisp();
return 0;
}


675 :デフォルトの名無しさん:2010/05/12(水) 20:49:56
gccのソースコードみてみそ

676 :デフォルトの名無しさん:2010/05/12(水) 21:52:24
見るとどうなるの?

677 :デフォルトの名無しさん:2010/05/12(水) 21:57:40
RTLのmdファイルとかのこと言ってるんだろうけど
発想が全く違うよ

678 :674:2010/05/12(水) 22:10:18
結局欲しいのはC言語としての出力なので、
LISPはあくまでも補助言語と考える。
LISPはプリプロセッサ的に使う、もしくはトランスレータを
内蔵しておき全てCとして出力する。内部のLISPランタイムや
GCなどが関係するコードが残るようならエラーとする。

例えば、マクロを定義するためならクロージャやGCオブジェクトなど、
LISPのフル機能が使えるが、出力にはLISPの痕跡は残らない。


679 :デフォルトの名無しさん:2010/05/12(水) 22:17:15
Cの欠点のひとつとしてマクロがあげられるぐらいなのに、さらにパズルを増やすのか?

680 :674:2010/05/12(水) 22:30:05
マクロだけとは限らない。
コードの自動生成にも応用できる。
C++のテンプレート以上の効果が期待できる。

681 :674:2010/05/12(水) 22:35:02
昔、似たようなことをやってた人がいた気がするけど、
LISPランタイムをリンクするような形だったので、
それとは方向性が違う。
ROMに焼くような組み込みでも使える処理系を目指す。

682 :デフォルトの名無しさん:2010/05/12(水) 22:46:51
一部にLisp入れるくらいなら、全部S式でいいよ。

683 :674:2010/05/12(水) 23:10:00
目指す所は単なるLISP->Cトランスレーターとは違う。
ただのLISP処理系にしてしまうと目的がぼやけてしまうし、
S式をベースにすると冗長だったり書きにくい部分が必ずある。
Cとしての出力が目的なら、あくまでもメインはCであるべき。
学習コストと天秤に掛けると、独自言語という発想でもダメ、
それぞれ専門家のいる既成言語の組み合わせがちょうどいい。

684 :デフォルトの名無しさん:2010/05/12(水) 23:12:45
あんまり混ぜるとrubyみたいになりますよ

685 :デフォルトの名無しさん:2010/05/12(水) 23:15:12
それなら、新言語のマクロも新言語風の文法(A)で書ければいいんじゃないの。
なんで、新言語と異なる文法(B)でマクロをわざわざ書かなければいけないのかわからん。

異なる文法(B)の方が便利なら、新言語の文法自体をそちらの文法(B)にすればいいよね。

686 :674:2010/05/12(水) 23:24:43
新言語、新言語風だと誰も使わない可能性がある。
俺はそんないつ消えるか判らない物は覚えたくない。
おれはCもLISPも知っている。だから両方使える言語を書く。
それだけ。

687 :デフォルトの名無しさん:2010/05/12(水) 23:30:31
なんか、かっこいいですね
惚れました

688 :デフォルトの名無しさん:2010/05/12(水) 23:33:38
>>686
スレ違い

689 :674:2010/05/12(水) 23:36:56
はいさよなら。

690 :デフォルトの名無しさん:2010/05/12(水) 23:40:47
まあ、マクロは言語自体の文法で書けるのがいいだろうな。

691 :デフォルトの名無しさん:2010/05/13(木) 00:23:03
C言語のプリプロセッサの大部分は言語組み込みにしたほうがいいけど
マクロ関数は便利だしシンプルだ。
型安全ではないかもしれないが、動的言語のようにどんな型でも
変数に受け取って様々なことを高速に出来る。
遅延評価的なことも特別な仕組みもなく使える。
多くの言語の処理系では関数マクロを使われている。
インライン関数だけではなんともならない箇所もある。

692 :デフォルトの名無しさん:2010/05/13(木) 00:32:24
多くの"高階な"言語だろ
マクロでいじり倒したコードなんて趣味のもんだな

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

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

694 :デフォルトの名無しさん:2010/05/13(木) 00:58:06
低レベルな言語なんだろ?
趣味を満たしたかったらScalaでもOCamlでもやってた方がいいんじゃないか

695 :デフォルトの名無しさん:2010/05/13(木) 00:59:34
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。

696 :デフォルトの名無しさん:2010/05/13(木) 02:08:29
低レベル=実用的な言語が欲しいんだろ

まあスレッド、バリア、Mutexが
CSP風に組み込まれてたら面白そうだがな

697 :デフォルトの名無しさん:2010/05/13(木) 04:13:12
いつも思うんだがお前らが作る言語は
どの言語にそっくりなのか

型に甘いの型に厳しいのか
動的型付けなのか静的型付けなのか
グローバル変数とグローバル関数は許すのか
goto文はありなのか
C/C++/Javaのように改行なしでも一行で膨大なコードを
書くことすらできるものなのか否か、
型に文字列型、配列型、整数型、小数型、文字型、bool型等
きっちり細かく決めるのかそこらへん適当なのか、
クラスはありなのか、
クラスがありのときjava.lang.Objectのような基底クラスがあるのか、
例外処理がありのとき、java.lang.Throwableのように例外やエラーの基底クラスがあるのか、
アサーションありなのか、
アスペクト指向でポイントカットやウィービングありなのか、
Java Generics、C++ templateのような型はありなのか、
マルチスレッドの扱いはどうなっているのか
staticと非staticの違いはありなのか
などなど疑問点が付きないのだが

698 :デフォルトの名無しさん:2010/05/13(木) 05:38:46
なげえ。
Cに代わる低級言語ってスレタイ思い出してまとめろよ


699 :デフォルトの名無しさん:2010/05/13(木) 06:55:00
Cの関数マクロは実用的だ。趣味だけじゃない。
VC++のメッセージもマクロだ。
RubyのCのメモリ管理周りもマクロだ。
VMの実装にもマクロ。
マクロ、マクロ。
Cのマクロはただ美しくないから嫌われてるだけ。
欲しいのは美しいマクロ。構造化されたマクロがその答えではないか?
テンプレートはホントに美しいか?
インターフェイスの記述をトランスレートするのが簡単であればよい。
エディタの色づけが楽であればよい。

700 :デフォルトの名無しさん:2010/05/13(木) 07:14:07
マクロもテンプレートも、C/C++のきたないところ。

701 :デフォルトの名無しさん:2010/05/13(木) 07:32:33
テンプレートは(文法以外は)美しい

702 :デフォルトの名無しさん:2010/05/13(木) 07:33:18
>>698
自分は言語は小さく、ライブラリに出来るものはライブラリにする。
演算子定義とLispのマクロ的なコンパイルタイムプログラミングで
抽象化し記述力を上げる言語を考えているので以下のようになります。
どんな言語に似てるかはシンタックスはJavaScript、Lisp
機能的にはD、Scala、golangあたり。
型 プリプロセス時は甘く動的、コンパイル時は固く静的
グローバルありで、gotoあり、改行なしで書ける。
型の詳細は未定、クラスは言語で仕様はないけどライブラリで実装出来て、
例外はありで巻き戻し処理はマクロでやろうとする。
アスペクト指向はプリプロセッサでやれる。
ジェネリックス、C++テンプレートもプリプロセッサで、
Tではなくa'的なものを検討したり衛生的なマクロ等、後から出来る設計。
マルチスレッドはライブラリで。synchronized式をマクロで実現できれば。
グローバルなstaticはprivateで、関数内、class内staticはありかな?

703 :デフォルトの名無しさん:2010/05/13(木) 07:40:12
テンプレートが美しいのは、文法だけ。

704 :デフォルトの名無しさん:2010/05/13(木) 15:22:19
hoge<foo>とか超汚い

705 :デフォルトの名無しさん:2010/05/13(木) 15:38:14
C++のテンプレートがクソなら
Java Genericsを適用すればいい

706 :デフォルトの名無しさん:2010/05/13(木) 22:27:39
これをもう少しオサレにする感じで

LLVM Assembly Language Reference Manual
http://llvm.org/docs/LangRef.html

707 :デフォルトの名無しさん:2010/05/13(木) 23:48:56
C/C++に変わる低級言語って、DとかGoじゃいかんの?

708 :デフォルトの名無しさん:2010/05/13(木) 23:49:53
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。

709 :デフォルトの名無しさん:2010/05/13(木) 23:55:01
「なぜ、新たなプログラミング言語を考えることが目的になるのか」
を考えることには意味があるだろう
そうすることによって、作るべきものがもっと明確になる

710 :デフォルトの名無しさん:2010/05/13(木) 23:56:38
じゃあ、考えようか。

711 :デフォルトの名無しさん:2010/05/13(木) 23:58:10
とりあえず、Goが失敗したから

712 :デフォルトの名無しさん:2010/05/14(金) 00:26:17
【このスレの趣旨】
初代>>1「とにかくC/C++は古くてダサいので、C/C++に変わる何かが欲しい。
 Cは今でも『低レベル』の開発で使ってるらしいから、そこで使える言語キボンヌ。
 言語研究の最新トレンドなら何でもいいけど、取りあえずOOぐらいは付けといて。」

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

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

(´-`).。oO(こいつらじゃ無理だな、まぁいいかどうせ糞スレだし)

713 :デフォルトの名無しさん:2010/05/14(金) 00:36:28
(´-`)←現実世界では間違いなくこいつが一番役に立たないんだけどな。

714 :デフォルトの名無しさん:2010/05/14(金) 00:42:48
OSとか今から作らないし
言語1から作るより多言語のオブジェクト利用でいいじゃないか
こういうスレで実際作られたの見た事ない

715 :デフォルトの名無しさん:2010/05/14(金) 00:53:42
JavaのOSは一応あったぞ
たぶん他の言語でもいくつかはあるんじゃね?

716 :デフォルトの名無しさん:2010/05/14(金) 01:01:45
プログラマーとして会社に勤めていても周りの奴らは
こいつ一人じゃいくら時間あってもまともなアプリケーションつくれないだろって奴だらけ

717 :デフォルトの名無しさん:2010/05/14(金) 01:04:28
(´-`)←こいつがな。

718 :デフォルトの名無しさん:2010/05/14(金) 01:30:49
C言語の代替ということは即ちアセンブリ言語の代替に他ならない
アセンブリ言語(もっと言えば機械語)がわからんヤツは議論に参加する資格なし

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

多くのプログラマを困らせる(仕様上の)あいまい、無責任を許してはならない
今となっては使い物にならないものはバッサリと捨てる
多くのプログラマが毎回唱えるおなじないは簡素化もしくは自動化すべき

719 :デフォルトの名無しさん:2010/05/14(金) 01:35:31
最後の1行だけ採用

720 :デフォルトの名無しさん:2010/05/14(金) 01:40:46
要するに君達は
Cをキレイにしたいだけだろう

721 :デフォルトの名無しさん:2010/05/14(金) 01:42:33
最近の言語で流行ってる機能も入れたい

722 :デフォルトの名無しさん:2010/05/14(金) 01:52:37
>>718
Cに残っているマクロ以外の時代錯誤なしがらみってなんだ?
基本型のサイズがあいまい。これくらいか
他に何があるん。
そっからスタートしてみてはどうだ

>>711
goはこれからだよw


723 :デフォルトの名無しさん:2010/05/14(金) 03:34:54
最近の CPU や OS に最適化しやすい設計がされててコードが綺麗に書ける奴頼むわ。
セルやマルチコア意識した奴。

724 :デフォルトの名無しさん:2010/05/14(金) 05:31:20
メジャーなコンパイラ使ってれば哀れなメンテナが勝手に対応してくれるよ

725 :デフォルトの名無しさん:2010/05/14(金) 06:45:38
T -> a' -> ?

726 :デフォルトの名無しさん:2010/05/14(金) 06:49:05
マクロアセンブラは実用的
オブジェクティブアセンブラはあるのか?

727 :デフォルトの名無しさん:2010/05/14(金) 07:04:00
アセンブラでなくなる気が

728 :デフォルトの名無しさん:2010/05/14(金) 07:23:14
オブジェクト指向は素晴らしいので
アセンブラでもオブジェクト指向なプログラミングをすべき!

729 :デフォルトの名無しさん:2010/05/14(金) 09:02:18
低級言語かどうかはわからないが、
マルチスレッドプログラムが安全効率的に書けるシンプル軽快な言語は欲しい

730 :デフォルトの名無しさん:2010/05/14(金) 09:07:35
>>729
Erlang, Go-lang

731 :デフォルトの名無しさん:2010/05/14(金) 17:07:21
マルチスレッドいいねえ

732 :デフォルトの名無しさん:2010/05/14(金) 17:11:55
>>729
ここで言ってる低級よりは上の話だろうな
言語組込のメッセージパッシングやアクタとかだべ?

733 :デフォルトの名無しさん:2010/05/14(金) 18:49:02
良いねぇそういうのが良い。

734 :デフォルトの名無しさん:2010/05/14(金) 19:04:45
test

735 :デフォルトの名無しさん:2010/05/14(金) 21:47:51
>>732
でもそういう理論だけでは効率的な実装ができないのは歴史が実証済み。

736 :デフォルトの名無しさん:2010/05/14(金) 22:14:42
てかスレッドスケジュールはOSの仕事だと思うので、
OSに仕事を任せられる言語仕様が必要だと思う。
スレッドは頭痛いよね。ライブラリ対応しちゃうと
言語と離れすぎるし、言語対応するとランタイムの
問題が発生するし。

737 :デフォルトの名無しさん:2010/05/14(金) 22:27:10
実行時のスレッド管理などそもそも言語仕様に含まれるようなもんじゃない。
言語仕様には「コンパイラへの指示(あるいはヒント)」を含めるんだよ。
「ここは(可能であれば)別スレッドにしてね」というだけ。
あとは環境ごとにコンパイラが合わせて最適なバイナリを吐く。
判断するのはコンパイラの仕事。それで十分。

738 :デフォルトの名無しさん:2010/05/14(金) 22:32:34
>>737
スレッドモデルによって、何をヒントとして出さなければ
いかんのかが少し変わってくるし、シングルCPU上でスレッド
命令の取り扱いを決めなきゃ駄目だし。
そしてそれを検証できないと駄目。

739 :デフォルトの名無しさん: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

740 :デフォルトの名無しさん:2010/05/14(金) 22:37:32
誤爆した



だめだ今日はもう寝る

741 :デフォルトの名無しさん:2010/05/14(金) 22:47:44
マルチスレッドの扱いも新言語のスコープだよ。

742 :デフォルトの名無しさん:2010/05/14(金) 23:07:19
>>739 >>740
スレッドの切り替えに失敗したんですねw 

743 :デフォルトの名無しさん:2010/05/14(金) 23:14:18
メッセージの送信先が間違ってたんだろw

744 :デフォルトの名無しさん:2010/05/14(金) 23:17:34
標準ライブラリで用意する関数郡は全てスレッドセーフにするべきだ
strtok()とかロクに使わない上にスレッドセーフでもない完全にいらない子
自分が過去のしがらみと言ってるのはこういう部分だ

745 :デフォルトの名無しさん:2010/05/14(金) 23:29:53
ソケット周りも巣窟だな

746 :デフォルトの名無しさん:2010/05/15(土) 00:33:41
ランタイムはいるがCSPみたいなマルチスレッドサポートのデータ型とか
排他用の変数とかあったらいいよな
pthreadほどじゃなくていいけど、小さなRTOSレベルで制御できたらいいな

747 :デフォルトの名無しさん:2010/05/15(土) 00:43:31
副作用を制限しつつノイマン型に最適化された言語が欲しい

748 :デフォルトの名無しさん:2010/05/15(土) 00:43:47
>>725
Tとかa'って何?

749 :デフォルトの名無しさん:2010/05/15(土) 01:06:06
型変数も知らんのか
お前にこのスレはまだ早い

750 :デフォルトの名無しさん:2010/05/15(土) 01:13:39
早いも何も、googleにすら出てこない用語を使うのは、自己満足以外の何者でもないよ。

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

自己満足ではなく、他人と対話をしたいのなら、一般的な用語を使うべきでは。

751 :デフォルトの名無しさん:2010/05/15(土) 01:26:28
トップに出てくるじゃねえか

752 :デフォルトの名無しさん:2010/05/15(土) 08:21:06
コンパイラ用語のわからん奴は来るな

753 :デフォルトの名無しさん:2010/05/15(土) 08:26:25
strcpyとか、memcpyとか、脆弱性無視した標準関数だらけのC言語は害悪。

754 :デフォルトの名無しさん:2010/05/15(土) 08:37:04
いや、memcpyがなきゃ、OSのディスクバッファの読み書きとか書けないだろw

755 :デフォルトの名無しさん:2010/05/15(土) 10:00:54
Cで脆弱性とか言っている時点で、参加する資格なし。

756 :デフォルトの名無しさん:2010/05/15(土) 10:05:25
問答無用でセキュリティホールになるgetsとかは問題かな

757 :デフォルトの名無しさん:2010/05/15(土) 11:09:45
組み込みでもマルチコア構成だったりネットワークに繋がったりする昨今
脆弱性を考慮しない>>755のような脳無しこそ本当の害悪だわ

758 :デフォルトの名無しさん:2010/05/15(土) 11:22:15
ネットワークはいいとして、マルチコアと脆弱性に何の関係があるんだ?
知ってる言葉並べたがるお年頃なのか?

759 :デフォルトの名無しさん:2010/05/15(土) 11:27:23
言語仕様の話かライブラリの話かはっきりしろ

760 :デフォルトの名無しさん:2010/05/15(土) 11:35:40
memcpyはいいが、strcpyは時代遅れ。

761 :デフォルトの名無しさん:2010/05/15(土) 11:49:42
京大霊長類研究所の猿が立てた雑談スレに書き込むに、なんの資格が居るんだw

762 :デフォルトの名無しさん:2010/05/15(土) 12:02:44
で、結局T, a'って何なの

763 :デフォルトの名無しさん:2010/05/15(土) 12:05:08
>>761
霊長類学修士か、獣医学修士

764 :デフォルトの名無しさん:2010/05/15(土) 12:13:22
ゆとり世代といっても平均値が落ちてるだけでおまいらより優秀な奴はゴロゴロいる様に
霊長類の知能も平均値が落ちるだけでおまいらより優秀なアイちゃんはゴロゴロ居るわけだ

765 :デフォルトの名無しさん:2010/05/15(土) 12:15:16
Haskell見てるとPrologでいいじゃん、て思うよね

766 :デフォルトの名無しさん:2010/05/15(土) 12:15:39
>>761
アイちゃんへの溢れんばかりの愛を持ってる事ただ一つ

767 :デフォルトの名無しさん:2010/05/15(土) 12:17:53
>>762
意味不明の単なるノイズだから気にしなくていいよ。

768 :デフォルトの名無しさん: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の間違いです。
といったメッセージが表示されることです。
?は可能性爆発するのでそれなりの計算途中の状態が表示されることです。

769 :デフォルトの名無しさん:2010/05/15(土) 14:05:12
inc(a) { return a + 1; }
↑これをこう↓書くと、どういうメリットが生まれるの?
[a] inc([a] a) { return a + 1; }

[a]によって何をさせたいのか明らかにすると議論が深まるよ。

770 :デフォルトの名無しさん:2010/05/15(土) 14:30:46
>>768
OCamlでは
let inc n = n + 1
はint -> intに推論されるけど
Cの系統だと+演算子が整数や実数全部にオーバーロードされるから
この場合は「+が定義されている型」という制約つき総称型みたいなものに
自動的に推論して欲しいってことか?

771 :デフォルトの名無しさん:2010/05/15(土) 15:09:05
推論するときは、推論したとログ吐いてくれればいい。

772 :デフォルトの名無しさん: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}とかなにかいい記述方法あるといいと思います。

773 :デフォルトの名無しさん:2010/05/15(土) 15:19:47
「[T]」って自動推論によって推論された型のことを表しているんだな。

オレ記法を説明なしで書かれると疲れるよ。

774 :デフォルトの名無しさん:2010/05/15(土) 15:25:50
#define [A] inc([A] a) a + 1
深く考えてないですが、こんな感じの型付きのマクロでマクロ展開時の
コンパイルタイムプログラミングのエラー出力が
わかりやすくなったらいいなとか。
よりハイジニックなマクロが可能と。
ここらへんに改良の余地がありそうだと思うのですが、
自分で何言ってるかよくわからないので考えてみます

775 :デフォルトの名無しさん:2010/05/15(土) 15:27:52
>>773
そうです。説明不足で、すいません

776 :デフォルトの名無しさん:2010/05/15(土) 15:28:47
分かればいいよ。ドンマイ。

777 :デフォルトの名無しさん:2010/05/15(土) 15:35:41
I thinking now...


778 :デフォルトの名無しさん:2010/05/15(土) 15:53:59
ダックタイピングいいな

779 :デフォルトの名無しさん:2010/05/15(土) 16:09:45
>>768
もうPerlとかPHPとかJavaScriptとかみたいな型にいい加減な言語でも
作りたいのかと

780 :デフォルトの名無しさん:2010/05/15(土) 16:22:55
>>779
テンプレートライブラリと、マクロがごちゃくちゃになってる馬鹿が
書いてるのでそう誤解しちゃうんだと思う。
多分>>768馬鹿だけど、動的型変換は目指してないというか、目指すだけの
知恵が無いというか。

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

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

C/C++には、C言語の文法、C++の文法、プリプロセッサマクロ、さらに
STL文法という4つの文法が渾然一体となっていて、これが悲劇の理由だと思う。
さらに、標準ライブラリは古いは、基本スカラ型が曖昧だわ、悲劇の塊だと
思うのですよ。悪いのは>>768馬鹿が馬鹿を自覚してない事なんだけどね。

781 :デフォルトの名無しさん:2010/05/15(土) 16:29:31
そんなに悔しかったんですかね。

782 :デフォルトの名無しさん:2010/05/15(土) 16:35:19
新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。

783 :デフォルトの名無しさん:2010/05/15(土) 16:45:56
591 :デフォルトの名無しさん :sage :2010/05/10(月) 00:58:04
新言語では、ソース中でのタブ文字の使用を禁止したい。
あるいは、ソース中のタブ幅を例えば4文字に固定したい。

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

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

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

782 :デフォルトの名無しさん :sage :2010/05/15(土) 16:35:19
新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。


784 :デフォルトの名無しさん:2010/05/15(土) 16:51:07
バグがでにくい言語仕様が欲しい

785 :デフォルトの名無しさん:2010/05/15(土) 17:00:11
バグが出にくく、かつ、煩雑で冗長な記述の繰り返しが少ない言語仕様が欲しい。

786 :デフォルトの名無しさん:2010/05/15(土) 17:17:27
効率を最優先しつつそのなかで最もバグのでにくい仕様でおねがい

787 :デフォルトの名無しさん:2010/05/15(土) 17:48:56
Javaのautoboxing、C#のboxing, unboxing変換はどうする気だ

788 :デフォルトの名無しさん:2010/05/15(土) 18:04:03
クラスがなかったら、そんなのあってもうれしくないな。

789 :デフォルトの名無しさん:2010/05/15(土) 18:09:38
ロジカルなバグはプログラマーが頑張るしかないんだけど、
if( a=1 || 32 % x){
}

こういう記述で、コンパイルが通り実行もかかるのに、
いくつもバグが入ってるってのは避けたいよね。


790 :デフォルトの名無しさん:2010/05/15(土) 18:14:15
もう、前置記法でいいよ。

791 :デフォルトの名無しさん:2010/05/15(土) 18:35:33
>>789
int型とbool型を明確に分けて、その間で暗黙のキャストをしないようにしたら解決する。
代わりに、パズル的記法の面白さはなくなる。

792 :デフォルトの名無しさん:2010/05/15(土) 18:41:34
>>789
普通のコンパイラは警告が出る。

793 :デフォルトの名無しさん:2010/05/15(土) 18:42:07
関数形でそんな暴挙に出たら使い物にならないぜ

794 :デフォルトの名無しさん:2010/05/15(土) 18:45:39
代入の記号をもっと考えたほうがいいな。

795 :デフォルトの名無しさん:2010/05/15(土) 18:49:18
>>794
:= 代入・複製
<= ムーブ

796 :デフォルトの名無しさん:2010/05/15(土) 18:51:58
>>794
なれると間違えないようにはなる。
たまに、BASIC、PASCALを見ると違和感を感じるけど。

797 :デフォルトの名無しさん:2010/05/15(土) 18:55:11
  ,j;;;;;j,. ---一、 `  ―--‐、_ l;;;;;;
 {;;;;;;ゝ T辷iフ i    f'辷jァ  !i;;;;;  なれると間違えないようにはなる・・・
  ヾ;;;ハ    ノ       .::!lリ;;r゙
   `Z;i   〈.,_..,.      ノ;;;;;;;;>  そんなふうに考えていた時期が
   ,;ぇハ、 、_,.ー-、_',.    ,f゙: Y;;f.   俺にもありました
   ~''戈ヽ   `二´    r'´:::. `!

798 :デフォルトの名無しさん:2010/05/15(土) 18:58:10
で、>>789が怖いのは、
なんだ書き間違いのバグじゃんって、事で

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

と書き直して、実行してみて結果が大丈夫で良かったと思って納品すると、
x==0の確認忘れてて、 1!=a の条件にぶち当たって、ゼロ除算例外で
プログラムが停止して、ものごっつい涙目って事がよくあるんだよね。

799 :デフォルトの名無しさん:2010/05/15(土) 19:01:54
0除算って、構文の工夫で防げるものなの?

800 :デフォルトの名無しさん:2010/05/15(土) 19:22:56
というか、C言語の仕様ではor条件のときに二番目を評価するかしないかは
実装依存。という事で、1==aの間はX==0でも評価されないので
zero助産が妊娠。

801 :デフォルトの名無しさん:2010/05/15(土) 19:25:14
え?

802 :デフォルトの名無しさん:2010/05/15(土) 19:27:08
>>800
えっ

803 :デフォルトの名無しさん:2010/05/15(土) 19:28:07
なにそれこわい

804 :デフォルトの名無しさん:2010/05/15(土) 19:31:44
>>800は伝説の釣り師

805 :デフォルトの名無しさん:2010/05/15(土) 19:34:18
>>799
どちらかというとアルゴリズムの改良だね。単位ベクトルを求める演算を工夫して無くすとかだね

806 :デフォルトの名無しさん:2010/05/15(土) 19:39:33
>>805
それって、既存言語と変わらないアプローチだよね?

新言語として構文の改良でどうにかするのは難しいかな。

807 :デフォルトの名無しさん:2010/05/15(土) 19:41:48
>>806
/演算子を無くすぐらいしかできなくね?

808 :デフォルトの名無しさん:2010/05/15(土) 19:45:44
変数を無くせばコンパイルエラーで弾けるな

809 :デフォルトの名無しさん:2010/05/15(土) 19:51:07
0以外の数という型を新設して(数学っぽく書けばint*とか)
それを分母に持ってくるようにキャストするよう強制すれば
一応は0除算防げるが、誰も得しない。
non-null型と似たような発想。non-null型は得するけど。

810 :デフォルトの名無しさん:2010/05/15(土) 20:24:30
加算と乗算が可能な自然数型を定義すればよい
減算と除算は自然数に関して閉じていないのでダメ

しかしそれでは不便なので、皆単なる整数を使うのであった…

811 :デフォルトの名無しさん:2010/05/15(土) 20:32:12
「自然数」って何だか知ってる?

812 :デフォルトの名無しさん:2010/05/15(土) 20:34:13
>>810
対象は符号なしのみか。

813 :デフォルトの名無しさん:2010/05/15(土) 22:08:39
一回しか代入できない変数、
継承禁止、メソッドのオーバーライド禁止、メソッドの引数の上書き禁止に使う
finalは導入するのか?


それとも、メソッドのオーバーライドを可能にするvirtualを導入するのか?

814 :デフォルトの名無しさん:2010/05/15(土) 22:09:46
>>805
単位ベクトルだと?
おまえはMATLABのような言語でも作ろうとしているのか?

815 :デフォルトの名無しさん:2010/05/15(土) 22:11:08
>>799
防がずに複素数を導入したり
無限大やNaN、かのならNaNより複素数やを返すのもありだ

816 :デフォルトの名無しさん:2010/05/15(土) 22:11:55
>>809
Rational型(有理数型)か?
クラスで実現可能だな。
Complex型(複素数型)の導入もありだが。

817 :デフォルトの名無しさん:2010/05/15(土) 22:49:24
デフォルトでは、整数型・実数型は任意精度にしたいな。

必要の応じてコンパイルオプションやソース中で型宣言出来ればいい。

818 :デフォルトの名無しさん:2010/05/15(土) 23:18:07
割り算は演算子をsizeofみたいな予約語にしてほしい
これだけでもコード確認が容易になる

819 :デフォルトの名無しさん:2010/05/15(土) 23:19:36
なぜ割り算だけ

820 :デフォルトの名無しさん:2010/05/15(土) 23:22:53
割り算だけは例外発生するから

821 :デフォルトの名無しさん:2010/05/15(土) 23:32:14
例外発生させなきゃいいじゃん

822 :デフォルトの名無しさん:2010/05/15(土) 23:34:16
やっぱり低級言語でも例外機構っているの? 組み込み系の人が怒りそう。

823 :デフォルトの名無しさん:2010/05/15(土) 23:34:24
いや/0は例外発生しようがしまいが問題あるだろ

824 :デフォルトの名無しさん:2010/05/15(土) 23:37:43
>>1
それは無限精度でもなければ、加減乗算でのオーバーフロー、アンダーフローでも同じことだろ。

825 :デフォルトの名無しさん:2010/05/15(土) 23:39:39
割り算だけが0が特別だからだろ
オーバーフローアンダーフローは四則演算すべての問題

826 :デフォルトの名無しさん:2010/05/15(土) 23:42:56
で、それと割り算だけsizeofみたいな予約語にすることと、どう関係があるの?

827 :デフォルトの名無しさん:2010/05/15(土) 23:49:43
>>822
CPUによると思うけど0除算てCPU割り込み発生したりするでしょ

828 :デフォルトの名無しさん:2010/05/15(土) 23:50:42
CPUによるね。

829 :デフォルトの名無しさん:2010/05/15(土) 23:52:34
明らかに特殊な演算を記号にすると検索性の問題がある

830 :デフォルトの名無しさん:2010/05/15(土) 23:53:11
四則演算は特殊じゃないよね。

831 :デフォルトの名無しさん:2010/05/15(土) 23:57:05
四則演算は一心同体だろう。ひとつだけ特殊な扱いにするとかはない。
するなら全部する、しないなら全部しない。

832 :デフォルトの名無しさん:2010/05/16(日) 00:00:03
割り算だけ特異点がある。
これが同じとか数学のセンスなさ杉。

833 :デフォルトの名無しさん:2010/05/16(日) 00:00:08
余剰演算もたまには思い出して挙げてください

834 :デフォルトの名無しさん:2010/05/16(日) 00:00:30
>>822
この件にまじめに答えると、
スタンドアロンな画面のない装置でも、
LEDとかでエラー通知する手段は設ける。
例外機構が使われないのは、追加ランタイムとかで
サイズが膨れあがる事が多いのと、ほとんどの場合
MCU側の仕組みを直接使う方が楽だから。

835 :デフォルトの名無しさん:2010/05/16(日) 00:02:38
例外のある言語はクリティカルなソフトウェアの
構築には使えない。らしい。

836 :デフォルトの名無しさん:2010/05/16(日) 00:03:17
>>832
四則演算の一つだけ構文的に特殊な扱いをすることにセンスを感じないが。

837 :デフォルトの名無しさん:2010/05/16(日) 00:04:45
数学的な話すれば
引き算と割り算はそれぞれ足し算と掛け算で言うところの
逆元を使ってるだけ。

838 :デフォルトの名無しさん:2010/05/16(日) 00:08:14
>>836
ヨーロッパのキリスト教徒は君と同じセンスで、
ゼロもマイナスも複素数も認めない、
っていう時代が、1685年ほど続いた。

一般に暗黒の中世と呼ばれてる時代。

839 :デフォルトの名無しさん:2010/05/16(日) 00:08:45
>>837←単なる知識披露で全く意味が無い書き込みの例

840 :デフォルトの名無しさん:2010/05/16(日) 00:13:52
>>837
必ずしも逆元は存在するわけではないって言ってるんじゃないの?

841 :デフォルトの名無しさん:2010/05/16(日) 00:13:57
>>838
ひどい話のすり替えだな。

ゼロを認めないで特別扱いしようとしているのは君のセンスの方だろう。

842 :デフォルトの名無しさん:2010/05/16(日) 00:15:21
特別扱いしないのなら0割はどういう扱いにするん?

843 :デフォルトの名無しさん:2010/05/16(日) 00:17:23
inline関数のスコープはレキシカルスコープ。
Cのマクロはダイナミックスコープな関数と考えたら面白くないですか?

844 :デフォルトの名無しさん:2010/05/16(日) 00:17:34
面白くない

845 :デフォルトの名無しさん:2010/05/16(日) 00:25:08
>>842
0以外の定数でしか割れないようにすればいい

846 :デフォルトの名無しさん:2010/05/16(日) 00:26:27
なんだかますますC言語でいいような気がしてきた!

847 :デフォルトの名無しさん:2010/05/16(日) 00:28:27
で変数で除算するためにビット演算を駆使するんですね!

848 :デフォルトの名無しさん:2010/05/16(日) 00:29:01
保守的だな

849 :デフォルトの名無しさん:2010/05/16(日) 00:30:07
>>845
定数だけってそれこそ特別扱いじゃないか?
定数で割るってことは定数で掛けることと一緒だぜ。

850 :デフォルトの名無しさん:2010/05/16(日) 00:30:47
なんか初心者がいるな

851 :デフォルトの名無しさん:2010/05/16(日) 00:31:13
>>842
どれか

(1)例外を投げる
(2)NaNを返す
(3)仕様上、未定義にする(除数に0を入れたユーザーの責任)

852 :デフォルトの名無しさん:2010/05/16(日) 00:35:03
またループか

853 :デフォルトの名無しさん:2010/05/16(日) 00:36:01
どの辺が?

854 :デフォルトの名無しさん:2010/05/16(日) 00:42:11
現状の方法に戻った

855 :デフォルトの名無しさん:2010/05/16(日) 00:43:18
現状も何も、新言語はこれから作るんだけど?

856 :デフォルトの名無しさん:2010/05/16(日) 01:41:05
>>851
NaNでいい。これが一番スマート。
未定義動作は極力含めない方向で。あいまいさは最も唾棄すべき仕様なので。

857 :デフォルトの名無しさん:2010/05/16(日) 01:55:10
整数型の場合は?

858 :デフォルトの名無しさん:2010/05/16(日) 02:03:38
(1) 0
(2)とりうる最大の値
(3)とりうる最小の値

859 :デフォルトの名無しさん:2010/05/16(日) 02:06:58
0/0はどれ?

860 :デフォルトの名無しさん:2010/05/16(日) 02:13:11
0除算したら、現状通りSIGFPEでプロセス終了でいい

861 :デフォルトの名無しさん:2010/05/16(日) 02:17:00
現状なら例外ではなくて?

862 :デフォルトの名無しさん:2010/05/16(日) 02:18:30
ユーザーにどう伝えるかの議論がないところがレベルの低さのゆえん

863 :デフォルトの名無しさん:2010/05/16(日) 02:19:24
C++等は例外で拾えるんだっけ
勝手にシグナルハンドラ定義しているのかな

864 :デフォルトの名無しさん:2010/05/16(日) 02:30:24
>>862
あなたの考えは?

865 :デフォルトの名無しさん:2010/05/16(日) 02:32:13
なんか変な話になっとるね
- NaNは整数型では実現不可
- java/C++風の言語組み込みの例外は下品
- 858は意味不明

構文的な例外は不要だが
signalみたいな割り込みはあっても面白いかもな


866 :デフォルトの名無しさん:2010/05/16(日) 03:04:07
0/0 の動作は implementation-defined か unspecified でいい

867 :デフォルトの名無しさん:2010/05/16(日) 03:09:16
おまえらじゃCの代わりは作れんな

868 :デフォルトの名無しさん:2010/05/16(日) 03:11:58
Cでは「言語があまり余計な事はしない」のが鉄則

869 :デフォルトの名無しさん:2010/05/16(日) 03:13:19
生成バイナリは余計なことをしないほうがいいがそれ以外は手厚くすべき

870 :デフォルトの名無しさん:2010/05/16(日) 03:19:00
速度に影響する2つの仕様案があるなら
速い方を選ぶのがCの基本

速い方と遅いけど色々出来る方の
両方を用意するのは構わないが

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

00001111 = 15
10001111 = -113 //何故 -15 ではない?

872 :デフォルトの名無しさん:2010/05/16(日) 03:54:39
おまいらに任せても劣化 C しか出てこなさそうだな。

873 :デフォルトの名無しさん:2010/05/16(日) 03:58:31
だからC最強だってw
C++みたいな劣化バージョンと一緒にすんなよw

874 :デフォルトの名無しさん:2010/05/16(日) 04:00:03
>>871
ついに補数知らないヤツもきたか
2の補数、1の補数でくぐりな

875 :デフォルトの名無しさん:2010/05/16(日) 04:02:10
>>874
補数は知ってるよ。何故そうするのか?を知りたい。

876 :デフォルトの名無しさん:2010/05/16(日) 04:04:40
>>875
ここから出てくるな
http://pc12.2ch.net/test/read.cgi/tech/1178723829/


877 :デフォルトの名無しさん:2010/05/16(日) 04:11:02
半加算器とかそのへんから

878 :デフォルトの名無しさん:2010/05/16(日) 05:05:31
つまり古の時代に減算回路を省いたが故のしがらみということか

879 :デフォルトの名無しさん: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 を返します。

880 :デフォルトの名無しさん:2010/05/16(日) 06:14:40
>>837
だからそんなのでは0除算対策にならない。
MATLABのようにNaN、Infという値を新たに作るか、
それとも例外処理を追加するか、など検討しなければ

881 :デフォルトの名無しさん:2010/05/16(日) 06:15:22
それから0除算対策として
割り算を分数として保持しておくてがある
RationalクラスやFractionクラスで作成する分数オブジェクト、といったところか

882 :デフォルトの名無しさん:2010/05/16(日) 06:17:11
>>856
それは分子が0のときだろう。
分子が0以外の実数のときは -Infinityか+Infinityを返すべきだ

883 :デフォルトの名無しさん:2010/05/16(日) 10:04:41
>>882
Infinity返すのは違うだろう。単に未定義なんだから。
例えば、lim[x->-0]-1/x の場合は+Infになる。

884 :デフォルトの名無しさん:2010/05/16(日) 10:09:22
0で割ることはできない。意味がない。結果うんぬんの前に実行できない。だから例外を返すわけよ。
むりやり値にするならNA(not available)が一番近い。

885 :デフォルトの名無しさん:2010/05/16(日) 10:12:45
面倒だから例外を投げるでいいよ
次は受け取る方法を書け

886 :デフォルトの名無しさん:2010/05/16(日) 10:17:36
>>885
おまえが書けw

887 :デフォルトの名無しさん:2010/05/16(日) 10:19:00
>>860
それCの仕様でも何でもなくて、x86ではたまたまそういう動作ってだけだべ

888 :デフォルトの名無しさん:2010/05/16(日) 10:23:02
キャッチもできずいきなりプロセス終了って怖すぎて使えないな。

889 :デフォルトの名無しさん:2010/05/16(日) 10:41:03
次スレは「【超光速】C/C++に代わる低脳言語を開発したい」な。

890 :デフォルトの名無しさん:2010/05/16(日) 10:44:23
>>887
お前x86しか知らないだろう?

891 :デフォルトの名無しさん:2010/05/16(日) 10:48:23
>>890
うん他の石はほとんど知らない
整数0除算を浮動小数点例外と同じ扱いにする石ってそんなに多いの?

892 :デフォルトの名無しさん: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");
}
と書けるとか。

893 :デフォルトの名無しさん:2010/05/16(日) 10:54:04
俺らにはできるな

894 :デフォルトの名無しさん:2010/05/16(日) 11:15:54
            (^G ^)
\(^ J^)×(^ H^)/ | |\(^ D^)/ 俺たちならできる
   | |    | |  < >  | |
  <  >  / >      / \

                        アイちゃん言語開発スレ
                        http://pc12.2ch.net/test/read.cgi/tech/1273199795/l50

895 :デフォルトの名無しさん:2010/05/16(日) 11:40:47
アイちゃんも応援しています

896 :デフォルトの名無しさん:2010/05/16(日) 11:44:55
>>891
石というよりOSの仕様だけど、たいていの場合Zero除算例外はSIGFPEだと思う
逆に浮動小数演算の例外は(デフォルトではCPU例外とならず)
SIGFPEにならないことが多い


897 :デフォルトの名無しさん:2010/05/16(日) 12:10:03
>>879
>さて、それは何進法で表現するのか?

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

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

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

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

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

実用上はBCDだけあればいいんだろうけど、
数値の内部表現を任意N進数に指定できてもいいね。

898 :デフォルトの名無しさん:2010/05/16(日) 12:18:06
8進数リテラルって必要?
ファイルモードぐらいしか使ったことないんだけど・・
open(filename, O_CREAT, 0666)

899 :デフォルトの名無しさん:2010/05/16(日) 12:22:03
2進数リテラルは0b0000_0000って'_'を付けられると嬉しい
おれの自作処理系では受け入れる

900 :デフォルトの名無しさん:2010/05/16(日) 12:23:40
数値リテラルの区切り'_'は確かに欲しいかも。

901 :デフォルトの名無しさん:2010/05/16(日) 12:26:21
任意精度なんて可変長型や動的型付けと同じくらい効率悪そうだな
静的型付けで高速動作を期待する低水準言語には最もいらないものの一つだろう

902 :デフォルトの名無しさん:2010/05/16(日) 12:32:00
新言語は、低水準の記述”も”できる低水準言語だから、開発を容易にする高水準の記述も当然できるよ。

903 :デフォルトの名無しさん:2010/05/16(日) 12:36:19
>>902
>低水準の記述”も”できる低水準言語だから

日本語でおk

904 :デフォルトの名無しさん:2010/05/16(日) 12:37:37
ごめん。”は引用符で濁点じゃないよ。

905 :デフォルトの名無しさん:2010/05/16(日) 12:39:45
ぶっこみの択(なぜか変換できない)

906 :デフォルトの名無しさん: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 ←隣国を思い出すから使いたくないね

907 :デフォルトの名無しさん:2010/05/16(日) 12:50:09
>>906
@にして先頭ゲット

908 :デフォルトの名無しさん:2010/05/16(日) 12:50:11
>>906
ああ?Ioディスってんのか?!

909 :デフォルトの名無しさん:2010/05/16(日) 12:51:46
任意精度はライブラリだろ。
任意精度ライブラリが記述できるのが低級言語に課せられた使命。

910 :デフォルトの名無しさん:2010/05/16(日) 12:54:28
>>906
IChan

911 :デフォルトの名無しさん:2010/05/16(日) 12:54:35
>>908
IO(アイオー)とかぶってるから使いたくないよね
検索に引っかかる名前にするのは常識だよね

912 :デフォルトの名無しさん:2010/05/16(日) 12:55:31
asdfというのはどうだろう

913 :デフォルトの名無しさん:2010/05/16(日) 12:58:49
間をとってiM@Sで
俺は雪歩ライブラリを使う

914 :デフォルトの名無しさん:2010/05/16(日) 13:33:22
>>912
グンクツの音が聞こえる

915 :デフォルトの名無しさん:2010/05/16(日) 13:47:23
>>892
ということは例外はPHPの仕様でいいなw

916 :デフォルトの名無しさん:2010/05/16(日) 13:50:49
>>897
実装依存ねぇ
コンパイラが乱立するだけだろうねぇ
各型ごとに2進数型、10進数型というものをきめたほうが負担が減ると思うけどね
2進数型のdoubleはIEEE754規格に従うべきだね

http://ja.wikipedia.org/wiki/IEEE_754

917 :デフォルトの名無しさん:2010/05/16(日) 14:05:09
_

918 :デフォルトの名無しさん:2010/05/16(日) 14:48:45
まてまて、2進数"型"ってなんだ?2進数表記ってだけだろ?内部では全て2進数なんだから。

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

とかを"ソース上で"表現できればいいだけだろ?

919 :デフォルトの名無しさん:2010/05/16(日) 14:52:09
レス嫁

920 :デフォルトの名無しさん:2010/05/16(日) 14:54:26
>>918
いや、少数の場合、内部表現の底によって無限小数になったりするんだよ。
例えば、10進数の0.1は、2進数では0.000110011…の無限小数になる。
だから少なくとも実用上はBCD(Binaly Coded Decimal)のサポートがいる。

921 :デフォルトの名無しさん:2010/05/16(日) 14:55:09
Binaly → Binary

922 :デフォルトの名無しさん:2010/05/16(日) 15:13:11
10進数型のBCDではどのような分野で使われてるんですか?

923 :デフォルトの名無しさん:2010/05/16(日) 15:14:35
勘定系とか

924 :デフォルトの名無しさん:2010/05/16(日) 15:31:13
COBOLが使われているところ

925 :デフォルトの名無しさん:2010/05/16(日) 15:31:33
低級言語のスレじゃねえの
勘定系の話はいらんじゃろ
せいぜいオブショナルなデータ型があれば十分

926 :デフォルトの名無しさん:2010/05/16(日) 15:33:52
10進のハードウェアなら低水準でも10進型は必要だろ

927 :デフォルトの名無しさん:2010/05/16(日) 15:36:44
>>926
10進ハードウェア用のデバイスドライバーを開発できればいいのであって、言語仕様に「10進型」を含む必要はないのでは。

928 :デフォルトの名無しさん:2010/05/16(日) 15:42:51
なんつーか…会話してるように見えて実は座ってるフロアが違うっていう
B2Fで話してる人と31Fで話してる人では話がかみ合わないのも当然だな

929 :デフォルトの名無しさん: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に従えばいいと思う。

930 :デフォルトの名無しさん:2010/05/16(日) 16:39:19
>>926-927
実際、十進浮動小数点演算を持っているCPU対象のGCCでは、
_Decimal64などそれ用のデータ型が使える。

931 :デフォルトの名無しさん:2010/05/16(日) 17:10:39
低水準にdecimal組み込んでも矛盾を起こさないからあってもいい。ライブラリで組み込んでも使いにくいし。

932 :デフォルトの名無しさん:2010/05/16(日) 17:34:48
たまにBCD接続な機器があったりするからな
8bitから64bitまで、CPUや構成もまちまちなのをカバーするには
オプショナルな部分は必須だな

933 :デフォルトの名無しさん:2010/05/16(日) 17:37:08
BCDだけでいい?
任意N進数型とかは要らない?

934 :デフォルトの名無しさん:2010/05/16(日) 17:38:13
なるほど。コンパイラ作る側ではめんどくなるし
つわなくていい人は関係ないけど、CPUにも機能があるから
言語仕様に入るべきってのは正論だと思います。
ライブラリで提供するとしたらライブラリで提供されていても
関数だけではなく演算子も使えるようになっていて欲しい。
関数だけで書け言われても、嫌だわ。

935 :デフォルトの名無しさん:2010/05/16(日) 19:27:49
任意N進はいらないんじゃね
BCDにしても必須てほど使われないしね
Decimal/Complexとかはあっても悪くない程度じゃないか

936 :デフォルトの名無しさん:2010/05/16(日) 19:47:49
ところで、新言語のVirtual Machineをどう実装するかお前らは考えたことはあるか?

937 :デフォルトの名無しさん:2010/05/16(日) 19:49:38
何のためにVMが必要なの?

938 :デフォルトの名無しさん:2010/05/16(日) 19:53:12
MMX・SIMD・SSEも使いたい

939 :デフォルトの名無しさん:2010/05/16(日) 19:55:36
いまどきの新言語はVM実装があたりまえ

PerlもC#もVMを実装
OS非依存目指すならそれくらいかないと

940 :デフォルトの名無しさん:2010/05/16(日) 19:59:09
そのPerlやC#が嫌だからこのスレがあるわけで

941 :デフォルトの名無しさん:2010/05/16(日) 20:29:41
高水準言語ならともかく、低水準言語にVMはないわ。
ていうかVMを実装するための言語。

942 :デフォルトの名無しさん:2010/05/16(日) 21:05:34
「低水準でも」使える言語なのでVMがあるのかどうかは関係ない。

それでもVM前提とか無いわ。

943 :デフォルトの名無しさん:2010/05/16(日) 21:21:17
>>939
で、何のためにVMが必要なの?

944 :デフォルトの名無しさん:2010/05/16(日) 21:36:58
Java, C#でさえ仕様上はVM必須というわけではないのに。

945 :デフォルトの名無しさん:2010/05/16(日) 21:40:30
共通の中間コードに一度変換した後に
その中間コードを各CPUにコンパイルするようにすれば
複数のCPUに対応したコンパイラが作成可能だ。
そこで共通の中間コードがネイティブで動く仮想マシンが必要になる。

946 :デフォルトの名無しさん:2010/05/16(日) 21:43:34
何で中間コードをそのまま動かそうとしてるんだよw

中間コードをさらに各CPUのネイティブコードにコンパイルするんだろ?
各CPUのネイティブコードとして動かせばそれでいいだろ

947 :デフォルトの名無しさん:2010/05/16(日) 21:54:36
基本レジスタ渡しな
レジスタは最低スタック用とフレーム用に2本かな
printfみたいな可変長引数はどうしようもないが


948 :デフォルトの名無しさん:2010/05/16(日) 21:55:15
C#のJITコンパイラは実際SSE2ありと無しでは吐くコードが違うからな
ぐぐってみ

949 :デフォルトの名無しさん:2010/05/16(日) 21:55:42
で?

950 :デフォルトの名無しさん:2010/05/16(日) 22:00:27
中間コードを考えるということは仮想的なマシンを考えるのと同義だ。
でも実装って書いてるな。むむぅ。
動的にコードを変更した最適化が可能だったりコードを小さく出来たり、
セキュリティ的にサンドボックスが作れるので
ネットワークでの配信が容易になったりするとか。

951 :デフォルトの名無しさん:2010/05/16(日) 22:00:32
LLVMでいいやん

952 :デフォルトの名無しさん:2010/05/16(日) 22:06:38
ネイティブコードを吐くコンパイラも、内部で中間コードにあたるものを生成していることを知らないらしい。

953 :デフォルトの名無しさん:2010/05/16(日) 22:06:41
ビットシフトを適当に使って書けば
最適化でビットローテート命令に使ってくれるかもしれないけど
言語側でビットローテート用の演算子がほしい

954 :デフォルトの名無しさん:2010/05/16(日) 22:15:04
>>953
どんな記号な演算子?
>>> <<< は算術ありなしとかだったから>>>> <<<<とか?
長いから >-> <-< とか?



955 :デフォルトの名無しさん:2010/05/16(日) 22:38:43
>rol>
>ror>

956 :デフォルトの名無しさん:2010/05/16(日) 22:59:00
頻繁に使うものじゃないし、ror()とかrol()とかの関数でいいんじゃないの?

957 :デフォルトの名無しさん:2010/05/16(日) 23:02:01
大抵はキャリーと組み合わせるから
キャリービットを扱う方法も欲しい

958 :デフォルトの名無しさん:2010/05/16(日) 23:07:32
またアホな話になってきたな

959 :デフォルトの名無しさん:2010/05/16(日) 23:11:16
(int a, bool carry) = a >ror> 3;
あるいは
(int a, bool carry) = ror(a, 3);
というかんじで使えるといいと。

960 :デフォルトの名無しさん:2010/05/16(日) 23:15:23
a >ror> 3
だと、 a > ror > 3 と区別がつかないのでいまいちじゃない?
記号のみの組み合わせにするとか、``でくくって`ror`にするとか
ror だけにするのがいいと思うよ。


961 :デフォルトの名無しさん:2010/05/16(日) 23:24:12
次スレ

【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/

962 :デフォルトの名無しさん:2010/05/16(日) 23:27:07
<@ >@
だな
顔文字か作れる言語にしようぜ

963 :デフォルトの名無しさん:2010/05/17(月) 02:00:37
とりあえずschemeでプロトタイプでも作るか

964 :デフォルトの名無しさん:2010/05/17(月) 02:18:18
期待してる

965 :デフォルトの名無しさん:2010/05/17(月) 07:08:34
S式の呪縛に囚われてはCに変わることは出来ないぞ

966 :デフォルトの名無しさん:2010/05/17(月) 07:27:01
反発も半端じゃないけどガンバレ!

967 :デフォルトの名無しさん:2010/05/17(月) 13:02:37
ああまだ5が残ってたのか

6に書いたけどニーモニック云々

968 :デフォルトの名無しさん:2010/05/18(火) 01:09:26
このスレの目指す言語はgolangじゃないかという気がする
並列処理組み込んでるし、ガベコレもあるし

969 :デフォルトの名無しさん:2010/05/18(火) 02:45:25
俺もそんな気がする
どうせ作らないだろ

970 :デフォルトの名無しさん:2010/05/18(火) 03:23:16
やっぱgoだよな
ガベコレ無しのgoが理想的なんだがな

971 :デフォルトの名無しさん:2010/05/18(火) 03:24:50
あとはWiring程度すら使いこなせねえレベルのもいるな
低レベルってのが俺からしたらドバイタワーの頂上みたいに見える話が多いし

972 :デフォルトの名無しさん:2010/05/20(木) 23:35:02
LISP民族とかLL民族がここぞとばかりに、
自分たちの言語に入ってる機能をねじ込もうとしているからな。

973 :デフォルトの名無しさん:2010/05/21(金) 00:27:45
蛮族に作法を教えてやってるのだ

974 :デフォルトの名無しさん:2010/05/21(金) 00:28:57
ねじ込ませたいと思うほどの機能なら、検討する価値がある。

975 :デフォルトの名無しさん:2010/05/21(金) 01:09:42
>>974
彼らはOSやドライバの仕組みを知らない。

976 :デフォルトの名無しさん:2010/05/21(金) 01:18:32
すべてを知っているのであれば、情報交換なんて必要ない。

自分が提供できるものを提供し、雑多な情報の中から自分に必要なものを拾うことで、高め合うことができる。

977 :デフォルトの名無しさん:2010/05/21(金) 01:20:39
妄想垂れ流して情報クレとな

978 :デフォルトの名無しさん:2010/05/21(金) 01:24:44
>>974
バカに混じれ酢するのもどうかと思うけど、
LISPやLLはアセンブラと相性悪いんだよ。

979 :デフォルトの名無しさん:2010/05/21(金) 01:27:11
と言って思考停止

980 :デフォルトの名無しさん:2010/05/21(金) 01:33:48
という類の発言は無意味である

981 :デフォルトの名無しさん:2010/05/21(金) 01:35:46
俺もそう思う。

982 :デフォルトの名無しさん:2010/05/21(金) 02:15:21
>>977
不覚にもわろた

983 :デフォルトの名無しさん:2010/05/21(金) 02:16:54
goはastがライブラリに入ってるから遊べるぞ

229 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)