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

70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 4
http://pc12.2ch.net/test/read.cgi/tech/1271980246/

◆新言語の要件 v0.1◆

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


◆主な要望◆

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

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

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

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

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

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

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

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

◆新言語の位置づけ◆

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

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

えらい早漏さんだな

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

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

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


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

ちょいスレチな風味だが
直I/Oとか割り込みハンドラなどの低レベルライブラリが
CPU毎に異なってるのが組み込み屋の悩みだな
メーカ提供のライブラリの出来も千差万別だし
言語の話と離れるが、共通化してくれたらいいのにね

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

新しい言語はGoogle GoやDに勝たないとダメだと思う

とりあえず新言語名はＩ言語(アイ言語)にしませう

Mona OSとかもあるし、
Mona言語とかしぃ++(thi++)言語でいいんじゃね？

Monoでも良いぞ

i-Mono

Programming Language I に決定。

>>1
速度にこだわった低級言語といえばアセンブラ

>>5
文法はJavaベースで

自分がコンピュータ史上の人物として名を残したいのは分るけど
スレタイの事に労力を費やすなら、Dとか有望株を改良したりドキュメントを翻訳したり
積極的に採用して著名なアプリを作るとかしたほうがいいとおもうんだが。
こんな事は5スレ目だから、何度も言われているかな？

>>18
何を言っているんだ。このスレッドは雑談スレッドだぞ。
新しい言語を作るという妄想に浸りながら雑談するのが正しいスタイルだ。
新入り君はそこのところ勘違いしないほうがいい。

>>18
その発想は無かった

1スレの>>1はもういないだろ。
今は、話題に集まった奴が適当なことを言い合ってるだけ。

>>18
そんな色気は仕様が固まってから考えれば良いこと。
Ｄで良いと思う人はＤに行けば良い、
Ｃで良いと思う人はＣを使えば良い、
ＬＷＬが好きな人は好きで居続ければ良い、
ＣＯＢＯＬしか分からない人はそれで良い、

私見、
Ｄの問題点、ＣのリプレイスではなくてＣ＋＋の置き換えを目指してる、
曰く、Ｃとして読める構文はＣと同じ動きをする事等など。

Ｃの問題点、既出

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

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

>>23
COBOLってランタイムいるの？

Cにだってcrtというランタイムがあるんだが

>>24
主にＩ−Ｏセクションだけどね。

・enumがいいかんじにswitch周りで使えるといいな。
・3項演算子はif式がよいんだか、よくないんだか？
・多値があるとよさそう。
・インクルードは自動生成がいい。

っていうかんじですか？

・インクルードは不要。自動生成してもいいが必須ではない。

>>27
＞・多値があるとよさそう。
おいらはこれに反対なんだけど、議論にならないので放置してる（ｗ

・多値の戻り値は、一つのリスト型で行う。リスト型から要素を取り出す暗黙のキャストがあってもいい。

多値はリストじゃなくてタプルだろう。
もっというとstructだろう。って言い出すとまた前スレッドを蒸し返せるよ

関数に多値を許すことの最大の欠点は、Ｃ言語とバイナリー互換が
取れないこと。文法がＣ言語と違ってもＣ言語と同じ形式のバイナリー
フォーマットを維持できれば、旧来の資産を継承できるんだけどね。

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

C側から新言語によるオブジェクトを呼び出させい場合は、単値のみにするとか、ラッパーを作るとか、何かすればいいんじゃないの。

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

>>33
きみがそのらっぱーなら、どうぞ、どうぞ。
ちぇけらっちょ♪

(ﾟ�听)ﾂﾏﾝﾈ

俺も多値は要らんけど、Cとのバイナリー互換とかで妥協する必要はないと思うな。

structで返却するってインタフェースにすればいいじゃん。
どうせ多値なんだから返却する型の順序は決まっているわけで。

>>36
OSから全部作り直しになるけど、頑張ってください。
確かに意欲的な方向で考えるのは悪くはないと思うんですよ。
そこまで見えてやり遂げるつもりなら誰も止めません。

structでもリストでもタプルでも呼び名は何でもいいけど、
順序付きの複数の値をまとめられるデータ構造のリテラルがあればいいね。

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

>>38
その「作り直さなければいけないOS」とやりとりをしたいときだけ、多値を使わなければいいだけじゃん。
多値があるからOSから全部作り直しになるなんてことはないよ。

>>39
提案コードを書いてみては？議論はそこからかな？

OSはコーリングコンベンションと関係なかんべ

>>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）、剰余は捨てられる

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

>>43
無名構造体って感じなんだけど色々突っ込む前に。
てか突っ込めるほど堅くなさそうな気が。

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

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

>>44
だから、名前は何でもいいよ無名構造体でもミケでもタマ。

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

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

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

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

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

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

>>46
あなたがそうしたいならあなた自身その方針でどうぞ。

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

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

考えているからある程度の例が出てくるのであって、
突っ込みどころ見つけてケチつけるのは、議論じゃねーですよ？

>>48
構造体（のポインタやリファレンス）を返す事と見比べると、
あやふやな点が増えるだけに感じるのだが？

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

>>48
それだと、div_tを宣言しなければいけないのが、ちょっと美しくない感じが。

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

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

多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
v,r = a /% b
v = a / b
r = a % b
みないな感じでいんじゃね

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

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

>>52
> v,r = a /% b

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

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

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

MISD？
普通に割り算インストラクションは商と剰余を同じ返す奴が多いから
それをイメージしてるだけだけどｗ

ていうか通常の割り算のアルゴリズムでは
商と剰余は同じに求まるんだよなｗ

>>55
まあ、割り算は分かりやすいから例として使っているだけだろｗ

>>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)

>>53
関数を置けるところに関数のリスト置けてもいいな。

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

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

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

オサレでかっこいい。

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

>>60
それいいな(ﾟＡﾟ;)ｺﾞｸﾘ

>>60
例外処理の使い勝手の悪さ問題だよね。
例外処理が使えればエラー値戻しは
必要ないと思うんだが。

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

そうかな？多値の有り無しは別として
例外処理って本来は大域脱出の延長だから多用すべきではないんだよ
正常な処理としてのエラー処理と例外処理を同列に考えて
構文に入れちまったのが問題だと思うんだよな
無用なオーバーヘッドだってあるしね

> 多値戻しは鬼門になりそう

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

Lisp

Lispと言ってもいろいろだろｗ

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

Common Lispも多値に対応してるよ。

PythonやRubyはタプルみたいな奴で単値返しじゃないか？
構文的には多値風だけど。

なんでもいいよ。構文的に多値に見えれば。

>>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)


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

>>70
他意のない単なる質問だけど、その「タプル」とLispのリストって機能的な違いってあるの？同じもの？

Pythonについていうと似たようなもんだが
タプルは変更付加
ちょい汚いけどC++0xにも導入されてるね

ごめｗ不可ねｗ

>>72
なるほど。ありがとう。

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

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

リストがlisp的なリストのことなら通常リスト自体は変更可能なデータ型でしょ
タプルは作ったら変更不可で自身も無名、メンバーも無名なstructって感じと思えばいい

>>72
ビックリしたぁ、標準ライブラリじゃん。

そそ。C++らしく汚物的に汚いけどねｗ

タプルをリストに代入できるが、リストをタプルに代入できるとは限らないってことでおｋ？

>>77
言語の話してるときに標準ライブラリの話持ち出さない
程度の、なんかは無いのか？

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

>>23
C++がOKでJavaが論外というのが矛盾だらけだ。
JavaはJVMなしでネイティブで動かすこともできるのだが。

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

>>30-31
リスト型、structというかオブジェクト(class)で返すべき。
C++STLのvector型、JavaのListオブジェクト(型)のように。
そして当然ながらGenerics(template)と併用できる。

何回自慢げに同じ話ばかりすれば気がすむんですか？

低水準ってキーワードを無視しまくったレスを付けてる奴は頭悪い。

>>39
C++STLのvectorやJavaのjava.util.Listオブジェクトの真似をすることの何が不満なんだ
配列で返してもいいし、オブジェクトで返してもいい。

>>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;
}

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

>>60
例外処理に不満があるならC#の真似をしてみては。
あれはあれで問題を起こし、Java方式とC#方式で賛否両論があるが

>>85
低水準といっておきながらC++に変わる言語を作れっていう時点で
無理がある

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

>>88
, で式をつなげるのは無しにすればいいかな。

>>90
低水準に”も”使えればいいんだよ。無理はないよ。

スレタイに、C++が入っているのがそもそもの間違い。C++にかわる言語はいくらでもある。
次のスレは、C++をはずそう。

>>86
返り値を多値型にキャスト出来れば、別に何を返してもいいよ。

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

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

>>88
ちょっとウザイけど
c = 1, [v,r] = a/b;
とかでもいいかな。

>>88
Cのカンマ演算子は中途半端だから廃止でいいんじゃない
複数の式を1つにまとめるのといろんなもんの区切りが同じ,ってのは
いまいちな感じしないかな
forとか考えるといい構文も思いつかないんだけどｗ

(v = 1; b = 2)なんて言うのが式として有効ならいいかも

>>79
ああ。確かにライブラリだな
でもC++0xそのままは汚いっていうのはそういうのも込みの印象ね
無名、メンバー無名のstruct的なデータ型はFirst Classとして
アリなんじゃないかと思ったからさ

前スレ埋めろよ

>>98
C++は過去を引きずり過ぎてあんな感じにならざるをえないんだろうね。
そういう意味で、新言語は過去に引きずられて妥協することのないようにしたい。

>>100
ぶっちゃけいうと俺はCとgolangでいいとおもってるけど
C++とかいらねｗ
でもスレはネタとして楽しんでるよ

CとC++を比較すると
両者とも過去を引きずっているが、C++だけが未来に拘わりすぎてあんな感じ
というのが正しい

純粋に未来だけにこだわったC++も見てみたいな。
ある意味、この新言語なんだけど。

「便利」でかつ「低水準」を同時に満たす言語を目指すこと自体が
かなり至難の業だと思うんだが
「便利」と「低水準」はほとんどトレードオフで反比例の関係に位置するといってもいい
よほど意表をつくほどの斬新な発想でもしない限り厳しいのではないだろうか


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

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

>>103
未来にこだわっただけのC++＝Java、C#、D言語
ではないのか。

>>105
それは違うかな。右辺の言語はCの置き換えにならない。

Cでできることすべてできないと気が済まないのか

Cに代えたいのかCと互換性を持たせたいのか不明

新言語ではCでできることは全てカバーしたいね。

>>109
それはかなり無謀かと
C++の二の舞だ

C99でできることぐらいはカバーしておきたい

>>110
C++と違って、新言語にはCとの互換性はいらないよ。
「Cでできること」というのは「Cでの開発対象となっている分野」のこと。
だから何も無謀じゃない。

Cを使うよ

マシンコードに対してCが写像であるということに、うんたらかんたら

だからクロージャはサポートされないわけだ。

クロージャーはサポートしてもいいんじゃないの。流行りだし。

>>112
> 「Cでできること」というのは「Cでの開発対象となっている分野」のこと。

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

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

>>117
そういう分野を、最近のオサレ機能を交えつつ開発できたら、気分いいよね。

>>117
その分野の開発を行えることが絶対条件で、さらに上位の開発にも使えたらなお良い。

二兎追う者はなんたらかんたら

優先順位が付いているからその指摘には当たらないのでは。

クロージャの考え方を考えようぜ。

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

C++が糞と言われながら普及したのは結局Cとの互換性があったからだ

普通のクロージャと同等に使い勝手が良いものが欲しければGC必須でしょ
GCで管理されてるからこそ、環境（自由変数）が暗黙にクロージャに
キャプチャされても、ユーザは寿命の問題をいっさい気にしないで済む

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

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

>>122
「フラットな構造」ってどいうこと？

写像

結局の所今あるもので十分なんだろう

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

それは、オナニーだよ。

>>124
そうそう。まずCで一番じゃまっけなのがオブジェクトの寿命だ。

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

>124
いや、それ以前の話。
cの場合は自由変数が束縛されるのはグローバルスコープと関数スコープしかないよね。
関数から別の関数を呼び出す場合も引数でしか渡せないから、結局クロージャみたいな
大袈裟な仕組みは要らないよね、ということ。
それよりも真っ当なマクロがほしい。

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

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

GC入れるのはいいけど、従来のC言語と同様に手動管理も
出来る自由度は欲しい

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

参照カウンタじゃダメで、GCが必要なのって、循環参照がある場合だけかな？
他にもあるの？

とりあえずころころソート基準が変わる
ソート関数ポインタを作りたいんだが、どうすればいい？

まだGCとか言ってるバカがいるのか…
高級言語からのトップダウンじゃなくて、機械語やアセンブリからのボトムアップで考えろよ
じゃなきゃCの代替になんてなれるわけがない

>>130
真っ当マクロ路線なら前スレで
出てたCをLispにした奴だね。あれがいい。

>>134
良いこと言うね

>>132
参照カウンタはスレッドセーフにしずらい

>>137
なるほど。たしかに。

多値なんて無ければ無いでいいし
クロージャ、GC、VMは論外だろう
結局このスレ、俺構文オナニーショーなんだな

ぶっちゃけ、最終的にはgo言語になる気がする

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

言語自体はGCサポートして、GCを使いたくないときには、-WGC オプションをつけてコンパイルすると、どうしてもGCが必要なところで、GC使いますよってワーニングを出すような感じにできないかな。

「言語自体はGCサポートして」というのは語弊があった。

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

GCの根本的な問題は「誰がリソースを管理するか」ということだよ。
GCをサポートするのならばリソース管理はGCにまかせるべきで、GCを使わないならばプログラマがちゃんと管理すべき。
オプションで切り替えるようなものじゃ無いよ。

>>143
限界ギリギリまでGCを使わないで、処理系にオブジェクトの管理をお任せすることって出来ない？

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

>>141
CにGCライブラリをリンクするのとどう違うのかね？
それにGCが必要かどうかの自動判断は無理

>>145
まさに処理系に「GCが必要かどうかの自動判断」をさせたいんだけど、無理なの？何ゆえ？

そんな切り替えができたら他の言語でとっくにやってるでしょ
ちなみにGCを起動させないことはできるよ

>>147
確かに。
他でやっていないから、出来ないってのは確かに消極的な証明にはなるね。

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

つーか何でそんなにGCを欲する？
10年以上CプログラマやってるがGC欲しいと思ったことなんて1度も無かったが

>>149
Cが何かとめんどくさくてインポテンツだから

>>149
ライブラリ作ってて、毎度毎度create-deleteペアを作ってやらなきゃいけないのに辟易したりしなかった？

>>151
それぞれのcreateとdeleteで違う処理をしなきゃいけないのに辟易も何もないわ
ただ解放すりゃいいなんて単純なライブラリは作らなかったし

>>148
停止性問題と同じくGCが必要か否かを証明する方法はない
単に不要と判断するならGCを殺せばいい

>144
>「GCが必要かどうかの自動判断」

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

そして再開する俺構文オナニーショー！！！！

↓最初の方、どぞ

>>153
停止性問題と同じではないでしょ。
GCよりもコンパイラーの方がメタなわけだし。

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

>>154
> 自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。

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

GC回収対象のオブジェクトを作らなければ不要でしょ
malloc使わなければfreeいらないのと同じ

>157
>リソースの生死の確認が必要かどうかの確認

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

>>159
> 所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。

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

GCがあると便利な場合は当然あって、それはそれでいいと思う。
ただ、一部のCユーザにはGC無しで自分でメモリ管理をする方が望ましいわけでしょ？
だったら両方できればいい

Garbage Collection (GC)について語るスレ
http://pc12.2ch.net/test/read.cgi/tech/1141646850/

>>159
GCを回しても、所有者のハッキリしないリソースがあるかどうかというのはわからないのでは。
GCで知れるのは、リソースの所有の有無と、所有者だよね？
所有者がハッキリするかどうかは別の問題ではないかと。

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

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

Objective-C

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

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

ね？ではなく、試せ

>>104
だれも便利は求めてないぞ（ｗ

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

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

>>108
>>１を嫁よ、Ｃ言語と文法上の互換性は必要ない。
ただしオブジェクトリンケージとか、Ｃ、Ｃ＋＋、ＪＡＶＡ
Ｄ，Ｇｏ，Ｃ＃で色々見知った事を生かしたい。

>>120
二兎を追うんじゃなくて、美味なる一匹

>>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;
}
てな事になってヤバイよね

> プログラマの意図どおりにバイナリを生成する保障はどこにもない。
> マクロはプリプロセスなので必ずインライン展開される。その違いを認識せよ。

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

誤爆かと思ったら前スレかｗ
定数に限っては意図どおりに展開されるよ

>>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;
}

>>173　続き

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

それはきめえわ

CPU固有言語たんハァハァですな。

マクロが必要か不要かの割合は１：９くらいでしょう。
不要だという人が多い。
ジェネリックスや多態性等で解決できるという主張だ。
でもジェネリックスを使いやすく発展させることを考えると
マクロに近づいていくというのがD言語のジェネリックスを見れば分かるかと。

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

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

>>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;　　　　　　　　　//呼び出し元が例外を受け取るならそちら任せる。
　　}
　}
}

>>178　続き
こうすればスタックの巻き戻しという大がかりな機構が必要なくなるし、
記述の一貫性が保てて良いと思うんだけど、例外の利点を何か失いそうな
感じがしてる。でもそれが何かまだ分からない。

>>179 続き。
>>178のコンパイラ自動設定の部分は、>>173で示したように、
Exceptionを関数定義で定義するかどうかによって、判断したら、
つまり、Exception引数を定義しなければ、旧来のＣ言語関数と
同じイメージになる。としてしまえば、総ての関数に、例外処理
というコードが組み込まれるのも避けられると思うんだ。

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

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

このスレは馬鹿しかいないな

>>181
無意味なこと書き込むお前ほどではない。

お前らの書き込んでいることは無意味ではないとw

>>183
人を馬鹿にするときには馬鹿にする前に馬鹿にする相手を論破しておかないと馬鹿にしているやつが馬鹿に見える。
お前のように実社会で馬鹿にされているからここにきて馬鹿にしに来ているやつにありがち。

書き込んでいる人間のプロファイリングとか
馬鹿しかしないわなw

>>178
必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
記述量が多い割に、値か関数かの判定は先読みしなければならないのも嬉しくない。
強力なマクロも実現できそうにない。

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

もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
話したいなら、そこだけ話せばいいのでは？

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

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

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

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

>>186　続き
>>187
>もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
>話したいなら、そこだけ話せばいいのでは？
関数定義も変更したいのとセットで語りたい部分だから。

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

>>189は>>188の続きの間違い。

>>188
いや、単語の長さとか、そういうレベルじゃない。
個人的には、お前は根本的にセンスがないと思う。

>>191
気分の議論は無意味だよ。とか書いても理解力は無いか。
まぁニギヤカシがいてるのが2chなのでしょうがない。

>>192
いや、気分の話じゃない。
言語を作るときに必要なのものとして、機能と文法があるとして、
文法の部分はかなりセンスを必要とする。

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

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

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

気分的には、再利用とカスタマイズへの拘りが感じられるスレだな
低級言語を低級ではない分野にも再利用したいとか
一からBNFを書き直すのではなくパーサーをカスタマイズしたいとか
そういう話題が多い

>188
直上の呼び出し元しか例外処理できないなんて無茶だわ。
そもそも「何の関数が呼び出したの？」という問題もあるし、結局まともに例外を実装しようとしたら
全部の関数にcatchを付けなきゃいけなくなって、オーバーヘッドが酷いことになるわな。
あとマクロとの相性が最悪なことになりそう。

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

>>195
＞直上の呼び出し元しか例外処理できないなんて無茶だわ。

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

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

>>193
だから、気分を語られても困るって（ｗｗｗ

>196
お前……例外使ったことないだろ。
細かい関数(thunkとか)実装した時に、それぞれの関数にcatchを用意しなきゃいけなくなるんだぜ？
オーバーヘッドで死んでしまうわ。どこの高水準言語だ

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

ここまで有用な話題なしと

>>124
GC必須にしたら結局低級言語にならないという
結論に到達するなw

>>152
お前デザインパターンを駆使するとdeleteするタイミング考えるの大変だぞ

デザインパターンは古い
クラウドを駆使するとソケットを閉じるだけだぞ

v = a / b
v,ok = a / b
v,r = a /% b
v,r,ok = a /% b

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

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

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

CPU固有君は最初から話がズレてる。
バラメータとソースとかも全く意味不明で戻り値の宣言も。f(g())出来ないとか、C++的オブジェクトありきとか。

>>203
ゼロ除算は結構簡単に発生するから良い例なんだよね。
異常度が高いというレベルで考えれば、数学概念を破壊するほど
高い異常な事態なんだけど、会計処理なんかでどかんと
処理したいときなんかは、簡単に発生するし。

>>201
そんなクリティカルな部分で悩むのにデザインパターンを
採用するのがキチガイなんだよね。

なんで割り算する前に判定しない前提なの？
知恵遅れなの？

例外は要らない

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

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

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

>>186
> >>178
> 必要以上に記述量が多いので大部分の人は使ってくれないでしょう。

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

errnoは今さらあり得ない。

イメージしやすいようerrnoを使ったまでだよ

なんで台無しにした後始末の話になるんだよ
未然に防ぐ方法を考えろや

例外なんて必要ない
ファイル開けなかったらabortすればいい

>>188
たまにしか使わない部分は長いほうがいいかもしれない。
でも、言語は常に使う部分だから短いほうがいい。
CもRubyも短くかけるから好まれる。

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

>>213
言語仕様をどうするかって話をしてるので、
俺の提案は、関数仕様ごと改革するべき、
という提案の中に例外が含まれている。

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

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

アプリケーションレベルならsetjmp/longjmpで十分な件。
OSとか作る場合他のプロセスの発生した例外の
トラップとか必要なわけでjavaなんか真似ても
全く使い物にならない件。

signalとごっちゃになっとるな

ブログラムエラーとかプログラムでは避け難いエラー処理を行うのが例外だからな
構文に入れちまったのはC++やJavaの設計ミスと思うがね

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

頭が設計ミスの奴がいるな

お前がな

あの辺の言語に try-catch が導入されていることを、ただ単に設計ミスと言っているようなヤツは、このスレで発言するのは控えてほしいな。

脳を0割しか使わないとこういう発言をしてしまうんだな

さらに新しい言語には導入されてない理由も考えずに戯言いうなよw

まあ形かえたgotoだからな
汚いのは当然

例外を文法でなくライブラリで実現した言語って何があったっけ？

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

むしろ関数の後ろにエラー専用のラベルを付けられるようにしろよ
VBみたく
結局ブロックでネストさせんのが面倒ってことだろ

setjmpを構文に取り入れただけだしな
OSとか組込とか例外自身を記述するのはどうすんだ？

longjmpにはjmp_bufを渡す必要があるわけだが、大抵の言語の例外は、そんな面倒な仕様じゃないぞ。

いろいろそういうことがあるから、OSはC++ではなく、Cで書かれているんじゃないか。

Cでもマクロで隠しちまえば似たことはできるわな
金粉かけても汚いモンはきたないし。

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

>214
なら関数仕様をどうするつもりなのか説明しないと話にならんな。
エスパーじゃないんだから、まとめて話してもらわんとわかるわけ無いだろ。
単にc++の例外仕様を変更しただけっつうなら単なる不燃ゴミだがな。

馬鹿の発言が頻繁すぎる

>>202
デザインパターンは普段当たり前のように使っているものでブームではないはずなんだが。
デザインパターンとクラウドは直交する概念

>224
scheme

>>231
賢い発言してくれよ

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

>>217
DivideByZeroExceptionを実装する代わりに
MATLABのように　
0/1
と入力すると
Inf (無限大)と出力でもする仕様にするのか？
pow(-1,1/2)　(-1の平方根)と入力するとNaNと出力せずに
i (虚数)
と出力する複素数型仕様にでもするのか？

>>222
C#、PHPで導入されているが何か

話が発散するから「低級言語」として適当でない話題は他所でやれよ
スレタイにC++が入ってるのがそもそも良くないんだが

>>238
新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

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

>>233
Lisp族でマクロで実現されているものはライブラリというより文法の一部だろ。

ライブラリで出来るなら
まずは既存の言語で優れたライブラリを作ってみたらどうだ？

>>238
低級言語でも例外処理とオブジェクト指向を適用しよう
というのは無理か

いまどきは組み込みですらC++使っているから

>>243
C++の機能をほとんど使わずにな

とりあえずここらでターゲットを明確にしておいたほうがいい。

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

C言語でもオブジェクト指向プログラミングは可能だし。
ジョークのストラウストラップインタビューにあるように、Xウィンドウシステムのフレームワークが
そうだし、解説した本も数冊ぐらいある。

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

デバドラなんて昔からOOチックだしな

組み込みの幅は広いからな

そりゃ自動でやってくれることを手動でやれば
Cでもオブジェクト指向は可能だろうよ。
めんどくさくてやってられないだけで

>>240
言語仕様を変えずに実現できれば、ライブラリで可能ということになるでしょう。
文法が変えられるならそれだけ言語のライブラリで出来ることが増えるだけなのに
反則と思ってもらってもなぁ。

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

例外ライブラリでやってなんかメリットあるのか？
ゼロオーバーヘッドにできるの？

あほが多用しなくなる

おまえがあほだろw

>>253
賢いなら
例外がどういう実装になるか
エラー処理として使う是非
普通にエラー返すのに比べての利点も教えてくれよ

普通にエラー返すんだったら、全部返り値チェックして、そのあとの処理をスキップする
ifがいるだろ。

ライブラリで例外作ってから来てくれよ

タイトルにCって入れたの間違いだったな
C++使ったことない奴レベルが低すぎる

>>256
setjmpとマクロで似たことできるし
at exitみたいなんでランタイムでひっかけてもいいかな

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

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

例外で処理をすっ飛ばすのを「エラー処理をさぼって」とかwwwwww

で、すっ飛ばしてリソース漏れを起こすんですね。わかります。

関数（メソッド）の引数が異常な場合は例外を投げるという仕様で、いろいろなものがすっきりする。
また、アンチgoto論者にも好まれる。

>>260
解放忘れは、例外がない場合の方が冒しやすい。

>>258
いいから作ってこいよ

ところがどっこい、例外で飛ばさずに全部いちいち処理せよと仰る御仁が現れたわけだ。
RAIIって全然普及してないんだな。

そりゃRAIIなんて使ってるメジャーな言語はC++ぐらいだからな

カリー化した関数にjavaのアノテーションをつけられたら、
いいなぁ、みたいな話だったんだろうな。

RAIIと言わずに「オブジェクトの所有権をハッキリさせる」とすれば良いよ。

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

大域ジャンプでスタックを巻き戻す際のデストラクタ呼び出せないよ、
スマートポインタどうしようもなくなってしまうよ問題

大域ジャンプを高機能化する
スコープ抜けるときに後始末をするようにするとか

いっぺんフリースタンディング環境で作ってみればいいよ
例外とかGCとかどんだけアフォな話してるのが理解できるから

>>270
フリースタンディングな環境ではわざわざ例外とかGCとか
作ってられないと？

>>271
OS作れるような言語と言っているのに、OSに依存するような機能を入れようとしている。

例外はCPUに依存するのではないでしょうか？
GCはライブラリに依存とはいえCPUごとに異なるので作るの大変。
それはOSの仕事に近い部分と。それは分かります。

むしろマルチタスクとかページングとか作るのが簡単だったりして
例外とGCはシングルタスクの殻に閉じこもってる

GCはOS必須ではないがな

>>275
必須だよ。

>>276
なぜGCにOSが必須なんですか？

行儀の悪いアプリが終了したとき＆強制終了したとき
掴んでたメモリを開放する処理は必要
一種のGCみたいなものになる。

それGCと関係なくね
だいたいOSの存在しない世界って、基本的にゼロ番地から全部自分のモンだろ
行儀の悪いアプリとか何だそりゃって話だ

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

>>277
GCどころかヒープでさえOS必須だ。ヒープなしでGCあっても意味ないだろ。

>>280
釣り？
OSのある世界しか知らない？
言語作ろうなんて1億年早い？

>>278
普通のOSならプロセスのリソースは管理されてるからな
またちょっと別だよ
RTOSは別だがありゃマルチスレッドだからな

ヒープから取得したメモリアドレスがどのプロセスに属してるかを
把握してないと開放できないとかあるとか？

MLton

を越えれるのかな

>>281
ヒープが何かを知ってからそういうことを言え。

>>283
OSがある世界ならヒープの元を仮想アドレスで割り付ける。
物理メモリの管理は必要だけど
アプリのヒープ自体はOSからは大して意味ないからね

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

OSやタスクやプロセスの線引きをどこで行うかの話でしかない
「OSは必要だよ」厨はスルーでよい

OS作るなら言語がヒープの管理してちゃ困るだろ

>>287
なんでOSがC++で書かれていないのかも分かっていないな。

>>285
常識的な知識位しかないね
組み込み屋だからOSなしの環境に
libcサブセットのmallocとかprintf位は作ったことあるがねｗ
当然だがリセットから初期化してヒープの準備とかもなｗ

タスクスイッチするだけのチープなOSもあるよ。
そういうのはヒープ＝スタックを除く物理メモリのこと。
GCを単体のタスクに対して行うか、全体に対して行うか。
前者ならOSは不要、後者ならOS上に乗っかってる。

>>289
C++で書かれてますって自慢してたOS、昔あったような
世間知らずさん

>>290
それはOSのメモリ管理のところを作っているじゃないか。

メモリ管理＝OSだと思ってるのかな
GCにOSは不要ですよー

>>288
別に困らないよ。
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおｋ。

まだくだらないことで揉めてんのかw
そもそもGCはスレ違いなんだよ

>>292
そういうで意味ならWindowsだってC++で書かれているし、NeXTはObjective-Cで書かれている。
その下により低水準のOSがいる。

>>296
確かに1970年代の低級言語にGCはなかったが
2010年だからということで揉めてる

GC付きでいいならD言語使えばいいのに

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

GC有り無し両方に対応したプログラムを単一のコード（あるいは最小限の修正）で記述出来ればいいね。

メモリ管理を書くのにメモリ管理がすでにあることを想定している言語を使う。

低水準言語という観点から言えば、2010年だろうが何だろうが
GC無しで使いたいことは多いはずなので
言語仕様のレベルでGCを前提にするのはやりすぎだろ
GC前提にすることで色々楽チンになって
クロージャのようなオサレ機能が使えるとしても我慢汁

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

>>301
C++/CLI

>>302
単に鶏が先か卵が先かという話と同じで、どちらかの完全な実装が先に存在しなくても全く問題ない。
少しずつ交互に積み上げていけばおｋ。

>>305
new が使えないC++は、もはやC++とは呼べない。

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

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

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

>>306
別に呼びたくなければ呼ばなくてもいい。
C++を作る過程で「new が使えないC++」を使って何の問題があるんだ？
すべてが常に完全である必要はない。
言語は単なる手段だ。使いやすいように使えればそれでいい。

>>307
馬鹿はコピペぐらいしか脳が無いのか

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

>>305
だがちょっと待ってほしい
既存の言語の上に何かを積み上げるのは無意味ではないのか

>>306
operator newは自分で実装できるし
placement newもあるだろ

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

>>306
newのお勉強スレ行ってこい

>>309
>言語仕様のレベルでGC前提なら、GCを動かすまではその言語は使えないということ

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

>>311
それじゃ、C++使っている意味ないだろ。

>>310
そう。
だから新言語の上に新言語を積み上げる。

ここは困ったちゃんを相手にするスレ

アホ避けが欲しいな
せめてD&Eくらいは読んでいて欲しい

>>314
は？何で無いんだよ
テンプレートだのクラスだのといった便利な抽象化機能が普通に使えるぞ

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

>>317
そんな無駄レス書き込んでる暇があったら、D&Eを読んだ成果を披露しろ

馬鹿の相手をするのも疲れるんだよ

気力を一方的に奪われるだけで得るものが何もないスレ

D、C++/CLI、Objective-C にある機能しか出てこないな。

Cで誰も本気で困っていないから。

C以上に低級だとアセンブラだし高級だとC++になっちまうしな

流石にnewが使えないとかいう妄言はないわ

GCにOSが必要とかなｗ

OSが無いとGC前提の言語は作れないとか言ってる人間は、天から与えられたOS、コンパイラしか使ったことがないんだろうな。

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

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

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

【第N+1フェーズ】
コンパイラ係：ローカル変数と例外対応しましたよ。
OS係：サンキュ。ところで、変数名は8文字以上だとエラー出るんだけど。
コンパイラ係：ああ、それ現在の仕様です。次までに言語仕様通り最低256文字まで使えるようにしておきます。
OS係：頼むわ。ああ、ヒープ使えるようにしたから、GC作っちゃって。
コンパイラ係：はい。やっておきます。

お前頭悪いだろｗ

CPUは既にあるものを使うし
Cなら既存のコンパイラが普通に使えるっつーの

リンカは別だけどな

>>329
> CPUは既にあるものを使うし

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

作るにしても最初はgccへのトランスレータにしてくれ
そうしないときっと使わない

>>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パターンで作ったクラスのシンタックスシュガーということ。

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

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

低レベルな層でもオブジェクト指向はできるよね。

>>327
うけたw
普通はクロスと既存の移植だろw

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

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

>>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);
　}
}

>>332
Vala/Genieでいんじゃないw

>>267
思うのだが
重たい問題は自動最適化コンパイラで解決できるような

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

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

RAMすら無しでブートしたりね
多分組み込みやったことないと想像も出来んだろ
それでも動かせるCは偉大だな

>>279
ちょっと気になるんだが

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

>>296
GCを実装したアセンブラ
ってのもなんだかわくわくするじゃないか

MMUにGC支援機能とか搭載しないのかな

いっそCPUにGCとオブジェクト指向命令を追加すればw

>>343
ちっともしない。
そんなのライブラリ呼び出すしかないじゃん。

>>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を実装すればいいのではないかな・

しかないかどうかは、これから決めること

>>344
MMUじゃ管理単位が荒過ぎるな
mark and sweep GC命令でw
FPGAなら書けるだろw

>>348
ノイマン型で決めるも何もないだろ

>>350
どういう意味？

>>336
ビットフィールドによるインデックスの管理は
そのリストや集合があまりにも膨大なとき真価を発揮するのだが。

LISPマシンてどういうアーキテクチャなの？

>>345
欲しいな。未来のCPUだ

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

なんか単語を並べてるだけだなこのスレ。

>>349
FPGAでは条件分岐が多い処理は性能が出ないから難しい。
下手するとCPUでソフトウェア処理するのより遅くなる。

ＧＣの実装とかコンパイラの実装の知識あって書いてんのかな

あって書いている場合もあれば、なしで書いている場合もあるだろう。
もちろんどちらも歓迎だ。

すこしはまとめてこうよ・・・

>>342
デフォルトで境界チェックあり、
オプションで外せるぐらいが無難な線ではなかろうか

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

>>359
どうぞ、どうぞ。

>>358
大きく間違ってる。
無い人でもせめてコードを読んだことがある
レベルじゃないと、話にならない。
このスレで言う素人はＧＣ実装の納品経験はないけども、
読んだことは有るし、改良加えようと遊びで弄ったことは有る。
というレベルじゃないと。

既存のGCの問題点

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

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

>>363
大体同じ意見なんだけど、少し視点を変えて、
ライブラリで対応可能（newとdeleteを上書きすればよい）
なＧＣを、言語仕様に取り込まなかった場合どういう不具合
が発生するか考えてみたい。

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

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

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

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

>>362
> ＧＣ実装の納品経験

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

GC納品・・・

独自のStringクラスやデータベースは、GCやってる。なんなら、オブジェクトはすべてデータベースに置くというのはどうだ。

アホは書き込まないで

まあ何を問題にしたいのかはわかるけどね。
低級言語と高級言語で例えばGCの有無により言語が全く異なる現状では、全く異なる言語を二つも学習しなければならない。
70年代の原始人ならそれで満足できるが、プライドばかり大きくなった現代人には耐えられない屈辱なわけだ。

>>364
> ライブラリで対応可能（newとdeleteを上書きすればよい）
> なＧＣを、言語仕様に取り込まなかった場合どういう不具合

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

>>370
何言ってるのか分からないから、具体的にソースで書いて。

GCの副作用もわからずにGCと言っているだけだろ。

>>371
void bar(char **p);
void foo()
{
　char *p = new char[10]; // [A]
bar(&p);
}

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

>･循環参照とスレッドセーフを同時に解決したGC技術は未だに確立されていない
これは嘘だろ
Javaはマルチスレッド対応していて循環参照も消せる。
インクリメンタルなリファレンスカウンタ方式のGCでも循環参照を解決する方法は存在する

GCをやりたければ単純なポインタ変数は禁止だろう。
オブジェクトポインタテーブルを用意し
オブジェクトポインタテーブルへのポインタを使わないと
メモリ管理そのものが成立しない。
当然実行効率は大きく低下する。

>>373
意味分からねー、
なぜに引用して同じ意味のことを書いたのだ？
ちょっとキチガイレベルの高い人を相手にしてるのかな？

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

>>376
コード示してもわからないなら、多分あんたには理解できないと
言うことだと思うよ。

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

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

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

GC無しで言語を作って置いて、GCありにも出来るようにすることは可能だ。
GCありにした場合だとGC無しのライブラリも、GCありのライブラリも使える。
GC無しだとGCありのライブラリは使えないと割り切るか、
混在して書くかという問題が出てきそう。

>>373
横だけどそれは生ポインタをそのまま使ってるからじゃないの？
そういう指摘がしたいの？やっぱり何が言いたいかわからないと思うんだけど。

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

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

Ｃ＃を改良しようスレでもないし、Ｃ＋＋プログラミングでもないんだけどな。

>>379
「ＣＧ使う時は、生ポインタなんて使わないでやるから、言語仕様なんかに
組込みなくてもいいじゃん」ということなの？

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

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

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

いやＧＣ云々の話は常にでてるから議論のネタではあるでしょう。
別にクラスじゃなく組み込み型・構造体・配列だけでもGCは実装可能ではあるし。
その場合はポインタの実装を考えなくてはいけなくなるが。

まあGCは無くていいんじゃね？
GCで解決するのはfree()し忘れる問題だけで
リソースリーク問題が無くなるわけじゃないし

スマポ内蔵ならいいんじゃない

S ex pression

>>380
GCありにしても
デストラクタの呼び出しタイミングが変わるだけで、
デストラクタの動作そのものが変わるわけではないでしょう。

GC有り無し混在するとしても、ポインタにメタデータ突っ込んどきゃいいんじゃね？
構造体にしてスマポ化するのも良いし、アライメントを活用するのもいいし。

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

GC最大の問題は最悪実行時間を保証できないこと
かといってGCが無いと、今度は無限エクステントは実現困難
わざわざ新たに設計する言語で、それはどうかと思うｗ

>>383
そういえば話は通じると思う。
お互い論点の確認せずに持論しかいってないように見えるからよくわからんとなってると思う。

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

GCのdelete呼び出しのタイミングが分からなくて
結果的にメモリ管理の考え方を変える必要があるわけだ。
だけど、そのGCありのプログラムとGCなしのプログラムが
混在した場合にどうあつかったらうまくいくかという点が問題なのでは？

そこでgcnew

混在させるメリットが不明。
同じコードをGCありでビルドするかなしでビルドさせるかという意味なら
ライブラリの使いまわしの話とかかなと思うが。

>>392
C++/CLIを見れば分かる
俺に言わせればただのカオス、あくまで橋渡し用のアダプタ構築言語と見るべきで
好き好んで使うような代物じゃない

お前に言われてもな

gc_ptr<Hoge> hoge(gcnew Hoge);
gc_ptr<Hoge> hoge2;

hoge2 = hoge;

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

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

>>398
タイミングを知って制御してるはずのコードをＧＣありに移行するメリットが明示されてないよ。
その場合の問題点とのメリットのトレードオフも。

>>398
例えばGC前提の言語仕様なら無限エクステントを作れるから
クロージャのようなものを言語仕様としてサポートできる
GCが単にライブラリとして利用可能、というだけならそれは無理

>>400
だからＬＷＬの人は寝て手くださいってばぁ
迷惑かけてるのにいい加減気がついてよ。

>>400
これを「面白い」ととるかが「人間性」の違い。

>>401
LWLって何だｗ
ちなみに俺は「GCを言語仕様のレベルで組み込むな」派だ
つまりクロージャなんて入れられないが、諦めろ
GC_malloc()でいいだろ

>>403
例えばCにGC_malloc()だけでどうやって具体的に実装するの？
参照されているかの判断の仕組みはどのように実装されるの？

>>399
組み込み向けに開発した画像圧縮プログラムが思いの外性能の良い
アルゴリズムで、互換性の問題も有ってOS上でも使いたい場合とか？
用はアルゴリズムは使い回したいけども、メモリ管理は別にいらなかった
とかかなぁ。この場合、メモリ管理を手作業からライブラリ任せにしても
問題ないだろうし。

■GCありなし混在のメリット
・新しいCにGCが欲しいという人といらないという人がいる。
・あるときはデストラクタを使ってリソース管理をしっかり行い、
　あるときはGCによって確実にメモリ開放できる。
・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。
■GCありなし混在のデメリット
・今のところ混在すると混乱する。

>>404
CでGCが利用できるライブラリなら既にあるよ
Boehm GCとかが有名なんで、興味あるんなら見てみれば
基本的に、ポインタ「に見える」ものをポインタとして扱うはず

>>406
GCありでデストラクタでリソース管理って何のジョークだよ

>>407
保守的GCをＧＣとして採用するのはどうかと

C++/CLIは失敗してると思う。
あれ以上は無理ならあきらめるべきだろうけど、
もっといい方法はないものか？

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

>404 >407
そのレベルの話なら、現段階で議論できるのはポインタを工夫するかどうかレベルだな。>389ぐらいか。
GCが管理するポインタとGCが管理しないポインタを区別できるようにしとけばいいんじゃね？

malloc()用のヒープとGC用のヒープ分ければ済む話と違うのか
アドレスの範囲で区別つくだろ

>>408
失礼しましたー、GCありでは確実にメモリ開放です。

ＧＣいらない派
１、有れば便利だけど失うものが多すぎる
２、ライブラリで対応できる
３、２の場合でもプログラムコードの手直しは最小限で済む

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

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

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

>>412
だから、OSの無い環境（OSを作る言語）でも
動かしたいＣ言語置き換え言語で、ヒープとか
言い出すなよ、も＝、もー、もー

GCのルートに登録されていればGC対象になればいいと。
保守的じゃない、GCをCレベルで実現することは可能ですかね？
ポインタ周りをいじれるようにしながら。。。

>>415
は？ヒープって何か特別なものだとでも思ってんの？
その場合はメモリの適当な領域を自分で区切るだけの話だ

>>416
むずいんじゃないの
GC管理されているヒープを指しているポインタなのか
ちょうどそれっぽい値を持つただの整数なのか
区別つかんでしょ

>>415
malloc使わない人がいるのはわかってる。
mallocしない人はGCと混在できる言語が出来たとしても
GC使わなきゃいいだけだって。

>>406
>・うまくすればRuby等のLWLの拡張をすっきり書くことが出来るようになる。

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

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

>>414
ちょっと恣意的杉。おれはC++的クラスがあるなら言語仕様にGCは必要がない派だけど
＞何故か
は必要ないだろ。
「ＧＣが有れば便利」は主張であり「失うものが多すぎる」とのトレードオフ項目だよ。
何を失うのはコンセプトとして得られるどのような便利さよりも重要であるというような議論が必要でしょう。

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

OS作成言語という前提があることは忘れてはならない

拡張したポインタも素のポインタと同じように扱えるようにしとけばいいだろ。
そうしとけばGCなんてライブラリ実装で十分だし。

>>420

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

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

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

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

>>423
その拡張したポインタはどのようなコストが払われているのでしょうか。

日本人はもっとブレストを研究・教育したほうがいいと思った。

デストラクタはデストラクタ、ファイナライザはファイナライザで
それぞれ別のもの。

スタックとメモリ空間だけがあって、
何番地から何番地はこれこれに使う。
という仕様にして、構造体のポインタにアドレスを入れてアクセスして
ほかのタスクとやり取りするといったような事にもC言語は使われている。
ヒープというからにはmallocなわけで、メモリ割り当てするには
それなりの実行コストが掛かる。
アドレス固定のスピードにはかなわない。

>425
構造体にする場合はポインタのサイズ。
アラインメントを活用する方向なら抽出コスト。

>424
厳格なGCにするとしてもポインタを工夫するだけの話だろ。グダグダ引っ張りすぎ。

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

>>430
・生ポインタはGCの追跡性を阻害する。
・ポインタを工夫するとそれなりのコストが発生する。
ここは議論対象でしょう。

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

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

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

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

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

>431
> ・生ポインタはGCの追跡性を阻害する。
ポインタにメタデータ突っ込めるように拡張性を持たせればいいんじゃね？>389のように

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

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

C++で実装されてるアイディアって良く出来てるよな。
問題はいろいろ出来すぎて不具合が発生しているところだと思う。
コンセプトを立ててC++から必要な機能セットだけを抽出するという作業は面白そう。

>>434
その辺で考えて書いても一晩経てば何故か使いやすいＬＷＬの議論に
なってる（ｗ

>>432
おい、白痴。

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

おれC++では生ポインタ使ってて,JavaではマークアンドスイープのＧＣ動作を期待してかいてるけど
shared_ptrを実用で使ったことない。
リーク０にしなければいけない状況だとして、循環参照が原理的に回避可能な手法ってあるの？

循環参照する時はweak_ptrを使う
既に開放されてるかどうかがチェックできる

あとはＣの歴史的な事情から残ってる機能で弊害が大きいもののリストアップも欲しい。

>>437
それは循環参照すると分かっているときは有効だけど
それを見分けるにはどうすればいいの？

文字列リテラルを非constなポインタに入れられるとか

>>440
これが理解できてなくて一日潰したことあるなｗ

>>439
そもそも普通は循環参照など起こさないように設計する
どうしても循環参照しないといけない時に、循環参照をする
当然その時は循環参照することは分かっている

スマートポインタはオブジェクト指向があっての物で
オブジェクト指向なしにしたいという話とはバッティングする。

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

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

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

どっちがいいんだ？

>>442
循環参照を起こさない設計って具体的なノウハウあるの？
ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない？

>>443
そんなことはないんじゃないの
C++では言語のレベルではスマートポインタを提供していないから
クラスとテンプレートを使ってそれを実装する必要があるというだけで、
言語のレベルでサポートするのなら、別にそれらは要らないと思うが

>>444
常に循環参照が起こるかどうか考えながら設計すればいいだけじゃん？
まあ相互参照するようなクラスはまず作らないってのは基本だけど

>>444
え？所有権のこともあやふやなんじゃ、スマポ使おうが使うまいが
C/C++でコードなんて書けないでしょうが

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

>>447
マークアンドスイープは解決するでしょう？
おれはshared_ptrで原理的に回避する方法を思いつかないから
new/deleteで徹底する方法をつかってる。

new/deleteで徹底できるなら
代わりにshared_ptr使えるでしょ

むしろそんな循環参照なんて発生するか？
直接の親子関係があって、子に親を持たせるケースくらいでしか
発生しないと思うんだが

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

>>450
そんなに発生するかどうかは実用レベルでは試してないのでわかんないけど
おれは原理的に回避できるアイディアが思いついてない。

クラスAがクラスBを生成するとする
仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
クラスB以降でクラスAを通じた循環参照は原理的に発生しない

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

>>444
>ポインタを渡さないというルールは厳しい気もするしポインタ渡しを許したときに
>それが循環参照になるかどうかの把握は特に他人のコードだと判断難しくない？

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

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

>>453
＞仮にクラスBがクラスAのポインタを保持せず、取得もできないのであれば、
この前提は厳しすぎない？
クラスAを親、クラスBを子としたときに
子が親の状況が見れないって制限厳しすぎると思うんだけど。

>>455
普通だろ
それを乱用している事自体、設計がなってない
当然必要な状況もあるけどな

>>454
なるほど所有権を使わないという宣言として生ポインタを渡すのか。
勉強になりました。

クラス図でも書けばいいんじゃない

>>454
これ目からうろこなんだけどこういう言及してる本ってあるの？

>>459
お前ポインターさわるな。

そもそも関数内で使うだけなら
引数にshared_ptr使っていようが循環参照は起きない
メンバに保持しない限り

>>460
いやお前リークしまくりだと思うわ

今時リークしたらデバッグ実行終了後にレポート出るだろ

>>461
使ってないことを明示するために生ポインタもらうってことなんだけど

別に保持しない事の明示にならないと思うが
生ポでメンバに保持するかもしんないから
ダングリングポインタになるのを心配する必要があって
weak_ptrの方がよほど安心

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

>>465
そこはルールだから。
ルール以上の決め事は言語仕様にでもするしかないと思うので。

>>463
で一定条件下でしかでないリークに気づいて躍起になって原因を探すんですね。

ルールは全員が確実に守る事が前提にあるから
あまりそれに頼ると困ったりするのよね
まあ悪いルールではないと思うけど

それはルール違反を検出するツールで対応するしかないと思うな。
その一手法が言語仕様。

生ポ、スマポ以外にシェアポとかウェイクポとかもあるんですか？

今扱ってるプログラムはCOMの扱いが分かってなくてリークしまくってるわ
プロジェクトに入ってから指摘してももう遅いってんで完全に放置状態だが
どうせ起動時に確保して終了時まで使うからリークしてもいいよね、みたいな状態

>>470
議論の本流とは外れるけど、
直ぽとか仮ぽとか近ぽとか遠ぽとか巨ぽとか

ぬるぽ

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

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

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

ポインタにメタデータとか
従来通りに使おうとする際にコストかかるからな
低級言語的にはアウト

>>454だが
関数の間口を不必要に狭めず、なるべく汎用性を上げる方針で書けば、
>>454のような帰結は自動的に出てくるはずなんだけどね

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

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

だな

自動的にでてくるはずの帰結なんだけどあまり流通してないのはなぜだろうね。

>>478
>>462が生活してる現実。

>>479
じゃあお前も防衛しとかないとダメじゃん。高みの見物気取ってる場合じゃないぞｗ

>>480
なんでおいらが関数定義の詳細化を提案してるのか、
理解できてないようだ。

ポインタにメタデータって型情報のポインタ持たせるだけですむのでは？
それで厳格な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が出来たり、
型サイズチェックできたり、
クラスに拡張したり、いろいろ有用そう。

>>481
お前が誰か分からんわｗ

>>483
俺は>>462がエンジニアとしてお金もらっちゃ詐欺になるレベルだと分かる。
誰か？は分からないけども。２ｃｈなんだからそれで充分。

関数定義で抽出したら対人コミュスキル不全がでてきたｗ

>>482
何をやりたいのかよくわからんけど、GC の問題が構造体の名前、
型やサイズ等の型情報でどうかなるわけではないことを知ってお
いたほうがいい。

無脳が人を見下すスレ

でもキミや俺みたいに無意味なレスするやつよりマシだけどな。

こんなにまとまらないくらいなものまとめるくらいならC使ってるわという気持ち。

>>483
Eulerだろ。

>>486
では何がそろえばGCを完全にできる？

ここを読んでみて
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

多少のコストは払ってもいいので完全なGCをCレベルで使って簡潔に
プログラムしたい。

スタック上やオブジェクト内にある参照でないデータも、参照をあらわすデータと見なして処理を進めるから
保守的になっちゃう。

おまえの言ってるＣレベルが分からん。
やろうと思えばC++のライブラリでも出来ると思うんだが
ここでいうC++とCレベルの違いは何？

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

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

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

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

何その言い換えｗ

完全なマークアンドスイープはC++クラスなしなら言語側に機構を持たないと無理。
C++ライブラリとしてなら実装可能だと思ってたけど実際に実装されてるライブラリって知らないや。
何か問題あるのか？

>>498
>>496と>>497は別人だよ

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

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

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

ますます分からんお前。そもそも>>496とつながってるとは思わんし。

>>499
わからないけど、探せばあるのかも。
今書き込んだ話も、この議論を見てて思いついたことだからなぁ。

>>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

実装の話は後でいいよ

実装可能性の判断は必要だよ

まあそうだな。じゃあ可能ってことで。

じゃあおまえのレスの正当性を判断しようか

>>491
何を持って「完全」と言うのかによるけど、shared_ptr ぐらいで我慢する
なら C++ のテンプレートレベルでいいし、きちんと管理したいのであれば
言語のサポートがないとどうにもならないと思う。

ポインタにタグを付けなきゃいかん、となると、OSどころか（というか、OSよりも）
ハードウェアでどうにかしないとだよな。

また適当な話になってまいりました。

>>508
きちんと管理する場合に最小限の言語仕様は何だと思います？

・利用されなくなったリソースの検出
・検出した時の処理の登録
・処理を明示的に登録されないかった場合のデフォルト処理

話を変えて、関数はデフォルトでconst関数と言うことにして、
const関数内から他の関数を呼び出せるのはconst関数のみ。
という事にして、制限をきつく、きつくデフォルトで決め込んでいくのは
どうだろうか？インターネット標準の、デフォルトは安全に振るを哲学に
するわけだ。

>>173を拡張して

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

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

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

General関数は普通に使える。

利用されなくなったリソースを検出したい時、
GCを使うと受動的にしかできない。
能動的に開放しようとしても、その時点で他にそれを参照する
リソースがあるかもしれないので開放できない。
開放されたかどうか分かるのはGCが起動した後。
つまりGCに任せると能動的開放はできない。

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

何が言いたいのか不明

脳内妄想をたれ流すスレ

------ここまで適当に読まなかった-------
GC派とそれ以外でスレを分けたらいいと思う

GARNET CROWと巨人対広島で分ければいいじゃない

>>473
ｶﾞｯ

C++とポインタとGCの勉強会終わった？

ノイズだらけでスレの意味が全くない
にちゃんのけいじばんのつかいかたをがくしゅうしよう！

>>521
１行目へのレスが２行目の文なんだよな？
自己完結してる。

>482
GCやるのならば型情報とオブジェクトの情報、参照元の情報がそれぞれ必要。
それぞれの情報を誰が管理するのかという話もあるけど。
（ポインタが管理するのか、GCが管理するのか、システムが管理するのか）

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

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

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

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

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

>524
そうするとGC必須にならない？オブジェクトが所有するリソースは明示的に解放しないとダメだろ。

>>525
「そうするとGC必須にならない？（GCが無ければ）オブジェクトが所有するリソースは明示的に解放しないとダメだろ。 」
って言いたいの？

GC言ってる奴は回線切って一通り実装して動かしてからこい

このスレはMultics つまりUnixを再現するための布石なんだよ!

GC欲しがるのは私はメモリ管理もできない無能ですと言ってるのと同じ

>>527-529

>>528
言語だからどっちかっつーとPL/Iじゃね？

神の作ったgoの仕様を100回見てこいよｗ
ほとんど全てがあるぞ。gc必須以外な

C++の代わりは既にいくらでも存在する。このスレで議論すべきはC言語の代替である。
次スレからはC++を除外、もしくはスレを分けよう。
そうすれば低水準言語にOOPや例外を、などとのたまうアフォ連中もいなくなるだろう。

低水準言語にOOPや例外はいらない、などとのたまうアフォを避けるために
わざわざC++を入れたんだろ。

まだアホがいるのか

まぁまぁ。
GCの話が嫌なら、GC以外の話すればいいっしょ。

>534
例外やOOPを実装するための機能なら議論しても良いが、例外やOOPそのものを議論するのはアホ過ぎる。
何でそんなに汎用性の無い機能を今の段階で議論するんだよ。

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

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

例外やOOPの議論がアホなら、マクロとルーチンの話もアホだろｗ
ドアホｗ

>>537
> あとサブルーチン以外のルーチンとか
その名も五郎ちゃんとかゴルーチンとかいうのがあるよ

神はmacroなんていらないって判断なんだよ
クロージャは作れるぜ

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

じゃあ、マクロの話しよう。

マクロなんてお前にゃどうせ使いこなせねえだろ

C言語にあのマクロがなかったら、
とたんにクソ言語の1つになるんだぜ

>>542
マクロなんてそんなに怖がるほどのものじゃないよｗ

俺はlispもOKだから別にって感じだが
Cのマクロは言語仕様じゃねえし
constとinlineで大半が不要だし

constとマクロの何が関係あるんだ
templateの間違いか？

>>546
こういうの↓を言ってるんだろ。たぶん。

#define VALUE 8

ああ、定数#defineか、ごめん理解した

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

構文いじれるマクロなんて
オナニー用だからな

Cには遅延評価やcall-by-nameは存在しないので
それっぽい（あくまで「ぽい」）ことを実現するのにマクロを使うこともある
要は式をそのまま渡したければマクロしかない

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

条件コンパイルもコンパイル時に値を渡せれたら問題ない

マクロは何よりも「引数を評価しない関数」としての機能が欲しいな。
これ自体は遅延評価でも引数を評価しない関数そのもの（Lispに昔あったそうな）でもいいけど、
この機能があれば制御フローなんかも実装できるようになる。

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

> 引数を評価しない関数そのもの
これがcall by nameでしょう
俺の知る限りではLispは正格言語であって、call by nameしたけりゃ
マクロだよ
だからLispのspecial formはマクロじゃないと書けない

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

Cのマクロで違う言語を作ろうとすると破綻するが(例boost)、
LISPでは破綻しない。
んなぜか

lispはマクロと普通の関数の違いが少ないからな
どうせ同じデータ扱うだけだし
その分人間には読みにくい

構文木を認識できて、その言語自身と同じ（異質でない）構文で構文木を
操作できるなら、Lispマクロと同等に強力と言えるんじゃないかな

それ簡単に言うがlispの用に簡単には行かないな
あいつはデータもマクロも関数も全部First classのlistだからこそ美しい

>>554
お前がCを知らないから
お前がboostを知らないから
お前がLISPを知らないから

の全部。

LISPでOCamlを作ろうとすると破綻するが
.NETでは破綻しない。

>>557
それは全く同意なんだけどね…

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

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

DSLは。。。どんだけドメインつくって言語作るんだよって感じで
いずれ見捨てられるか収束する技術だねえ

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

なんかコンセプトからはちゃめちゃだな

いあ、組み込み屋だから低レベルはかなりやってるが
動き回れるポインタをなくして配列の範囲チェックはあってもいい
golangのsliceはunsafeで任意のアドレスを割り当てることが出来るから
そういうのと最適化で効率は十分取れると思うんだよな

>>563
goってそんなsliceあるんだ
それは便利だなー

裏技的な使い方だしvolatileじゃないからI/Oには不向きだけどね

もうD--を考えてみてはどうか。
Dはここで議論されている新言語にしては機能過多なので、
高級機能はけずるかたちで。

>>565
まあ裏技とか低水準なことをさておいても、
そういう普通に欲しいものが無い言語多いんだよねー

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

組み込みではどうせメモリのほとんどは最初に確保するか静的に確保するから
解放にからむメモリリークはあんまないけど
オーバーランとかに絡むエラーの方がとりにくいんよね
単に固まるだけとかで情報取れないこと多いし。
だからバッファサイズがわかるとかオーバーをチェックする仕組みの方がありがたい

>>567
sliceは結局struct { void * ptr; int count; int max; } って感じの
組み込みデータ型だからレンジ情報は引き回す形になって
オーバーヘッド0って訳にはいかないけど
最適化次第とトレードオフかなと。

>>566
おいらはEmbedded Go Langって感じのが欲しいｗ

>>360
ポインタというか参照型は重要。
Javaのオブジェクトはみんな参照型。
新言語でもそういう条件をつけてメモリ効率をあげてみてはどうだろう。

>>363
> 既存のGCの問題点
>
> ･利用形態を問わず管理する人(メモリマネージャもどき)が絶対に必要
> ･効率優先である程度まとめてGC処理を走らせるためCPU時間を占有する

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

>>367
もっとパフォーマンスが堕ちるからやめてくれ

>>367はネタでしょｗ
笑えるかどうかはさておき

>>375
ついでに参照型と値型の違いも禁止するのはどうだろう。
intやdoubleなどの基本データ型はすべて値型で
それ以外の構造体、配列、文字列、リスト構造などはすべて参照型に。
そしてメソッドの引数に渡すときは参照渡しではなく参照をコピーして渡す
ということで。

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

それ何てJava

>>392-393
そんなマゾいことしないでデフォルトでGCありにすればいい。

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

またC++/GC/ポインタの勉強会になりそうだから傍観するわｗ

黙ってしてればいいだろ。宣言なんていらんよ。

>>438
scanf()
getchar()
string

>>579
GCやコンパイラの知識くらい言語設計するなら知ってるはずだろ
今更こんな話出てもつまらんって話だよ
MSのセンスねえ拡張に毒された話もつまらんし

傍観するんじゃなかったの？

Booも、オフサイドルール使うのかぁ。
力ありあまってるのかなぁ？
オフサイドルールって簡単に実装できるんだろうか？

>>582
あい。黙りますｗ

勉強会はいいが半日たたずにループはきつい。

勉強会になるだけマシ。
普段はお互い自分も理解してない単語の羅列が書き込まれてるだけだし。

>>583
難しく考えすぎだと思う

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

S式をアルゴル風な式に置き換えればいい。
Listじゃなくて演算子が式と式を結ぶ構文木を扱えばいい。
Consにタグが付いただけだからそんな複雑じゃなくてすむ。
コンパイルタイムではJavaScriptっぽい言語で式をいじればいいだけさ。

何言いたいんだ

>>583
難しく考えてないんですけど。短いソースでお願いします。

新言語では、ソース中でのタブ文字の使用を禁止したい。
あるいは、ソース中のタブ幅を例えば４文字に固定したい。

ループしてないようでよかったぜｗ
>>588
tcl乙

知ってる単語自慢大会

新言語に関係があれば、ループでも、知ってる単語自慢大会でも、いいよ。

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

>>593
知らない単語にめげてる人:1

tclはつかえない。理由は忘れた

>>588
S式と違って、アルゴル風な式は、見た目と構文木の構造が一致しないから
コンピューターにとっては複雑じゃなくても、人間にとっては扱うのが難しい。

今のTclって関数がファーストクラスになってるんだっけ
そうじゃなけりゃ
いまどきファーストクラスの関数を持たないLLの人って…
って感じ

>>578
C++/GC/ポインタの話についてこれない人:1

どこが低級言語の話だかよくわからない

>>600
初心者にはすぐにはわからないかも。
頑張れ。

ひどいいいぐさだな。tcl/tkな人。すいません。
tcl/tkは検討したのだけど、命令からパラメータ数が決まるとかいう
点がいまいちだと思ったんだったと思う。

>>599
C++は嫌いだが、lispとかSTの実装経験くらいなら学生の頃やったぜｗ
copy GCとリファカウントだけどなｗ

>>601
お前わかってないだろｗ

マクロだかマグロだかの話は低級高級関係ないお！
どんなに高級複雑なマグロでもプリプロセス／コンパイル時の話だからな！

多分、>>601がトリップ付けるだけで解決する

このスレ、id出して欲しいなｗ

id出さなくても/ｗ$/で抽出できる。

オンデマンドに強制ID付きでスレ立てできるようになるといいな
別に全スレでとは言わないから

>>588
おお、それじゃ、俺は理解できてるから人間をこえているのか？やった！
ってそんなことはないって。
BNFベースにするから構文木が分かりにくくなるので
演算子で繋がってるだけのものって理解すれば、そんな難しくないよ。

>>608
ありがとｗ
603だが604とは別人だよw
全角半角でいれといた

>>605
そんなことはない！
マクロは高級言語では他の機能で代替可能で分かりやすいから必要なくなる。
だけど、低級言語では機能が少なかったりスピード求められたりするから
明るく輝くんだ！あの夜空に輝く星々のように！

だからマクロはユーザーカスタマイズ可能なコンパイラだって。

構文いじるのは高階な関数系の言語にしとけって
Algol系では不要
FOREVER { }
とか書いてあったら恥ずかしいだろうが。

ユーザーカスタムって大抵可読性下がるよね

inlineもconstもない頃に仕方なく出来たcpp
昔はいいアイデアだったが今は弊害の方が大きいという認識だな
KenTompsonもgolangには全く入れてないし

とりあえず普段Cのマクロで「何を実現しているか」をリストアップしてはどうか？
本当にプリプロセスじゃなきゃできないことなのか、実は言語の一構文として組み込める処理なのか。
今のマクロはいわば「マクロ言語」とでも呼ぶべき独自路線と大域スコープで色々と問題を含む。
少なくとも言語本体と同じ構文でプリプロセスを書けるようにしたい。
inline constよりも確実で厳密な、完全なるインライン定数を定義するための修飾とかね。

神の名前をTypoしちまった
Kenneth Lane Thompson様すんません

constで定義した定数が確実で厳密でないってなに
cppは昔は良かったんだよ。コンパイラをシンプルに出来たからな。
条件コンパイルは今でも有用だが、代替手段は普通にあるし。

最初はenumもなかったな
こっちの方が定数定義に向いてるんじゃね

#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とそれぞれ使い分けている

まあ、おおむねC++やDで対応されてるかなあ、という辺りか

Cがなぜあれだけの機能しかないのかを分かっていないやつが多すぎ。

プリプロセッサのへぼさも理由があるしな

昔の理由なんて今通用するとは思えない

CPUのアーキテクチャもソフト工学も30年前から細かいとこしか進歩してないんだよ。ボク。

じゃあ説明してくれ

知ったかぶり大会に説明など不要

>>621
これってCのプリプロセッサディレクティブ？

>>455
フィールドやメソッドをprivateにすれば見えなくて当然。
protecedじゃないんだから。

またアホがきた

Cのプリプロセッサレベルで残すものは、__FILE__,#lineくらいでいいんじゃない？
ってのがD言語。それ以外は言語機能に組み込む。
LISPのマクロ言っているのは、C++やD等のテンプレートの先を言ってる。
何が何だか分からないのが問題なのでマクロでも何が何だか
分かるマクロで汚くなければ、問題はないと思うのです。

下降型の演算子順位法ですら難しい言われるのに、
短い例も出せないオフサイドルールはS式の代わりにはできそうにない。

構文いじって綺麗なわけない
コードがどう展開されるかの予想が付くのが
Cの利点というか低レベル言語に要求されることの一つだと思うぜ
そういう意味でC++はあんま低レベルとはいえん

いい加減もうCでいいじゃん
マクロフル活用でオサレっぽくかけるようにすりゃ十分だろ？

いにしえのratforみたいだな

最初のC++とかObjective Cとかもだね

いいかげん既存の言語にラッパークラスをライブラリとして自作して追加するだけでいいんじゃねって
思えてきた

さて、ここにいるのは何割プログラマやってる人？ＳＥでも。オレは会社でコボルいじってるけど

__FILE__, __LINE__ なんて、
コールスタックをダンプする機能があれば不要

ネイティブでコールスタックダンプとか、Ｄ言語でやって楽しかった。
GDBでオッケーとかいう話もあった。

GoLangってネイティブで厳格なＧＣついててっていいかんじっすね。
あとはマクロを使えれば、、、。

LISP風マクロを追加する試みって既に昔からあるよね
結局LISPのラッパーな感じだけど

だからGCはいらないと何度言ったら。
CでもGCできるんだからさ、各自で勝手にやればいいんだよ。

パズルみたいになるマクロいらない。

m4とかな

JavaPPって使ってた人いる？

Cプリプロセッサはマクロ中でマクロ定義できたらよかったのに
ちょっと中途半端なだけなんだよ

禿同

じゃあcalleeの中でcallerのローカル変数を定義できたらよいと思うか？
そんなものはレキシカルスコープが崩壊するだけだろ

プリプロセッサでは #line こそ必要不可欠

おJava女どれみ　プログラマー猿　カウボーイ・デバッグ　JAVAン
人月を探して　超電磁ロボ　コンパイラーVC++　パケットモンスター
機動戦士GNUDAM　エリア8KB　新言語Javaンゲリオン　あらいぐまオラクル
千と千尋のバグ隠し　あずまんがI/O　ゲットデバッカーズ　デバッグNo.1
Bugって仕様　人月姫　エスイー(SE)魔美　あしたの仕様ー　外注遣いに大切なこと
ガンダムsed　ガンダムOO（オブジェクト指向）　ランダムSEED
ガンパレード・デスマーチ 〜新たなる行軍歌〜　アルプスの少女High-C
Cosmic DataBase COMMITさん☆　ARMs　ハックしよう大魔王
魁！プロパティ高校　超時空要塞マクロ　湾岸MID$RIGHT$
ルパンSun製　グレートマシン語　逆襲のchar　ウルトラマンＺ８０
バグひな　戦え!超OS生命体TRONスフォーマー　gccさくら
キャプテンmalloc　金色のハッシュ！　おねがいt_char　typoしちゃうぞ
フォートラーン戦記　Excelサーガ　getcharロボ　焼きたて！！ＪＡＶＡん
データセンターあらし　忍者バグトリ君　ときめきメモリ枯渇　修羅のMON
ゴルゴ１Ｂ（バイト）　Rubyポップは笑わない　ELFを狩るものたち　迷宮組込

>>652
なんか笑った

新言語ではプリプロセッサでもその言語の機能を使えるようにしたい

>エリア8KB 千と千尋のバグ隠し typoしちゃうぞ getcharロボ　データセンターあらし　
すげー笑った
ありがとう

>>654
sizeof辺りの定数返すやつは欲しいなあ
あと、型が定義されているかとか

>>642
golangはC的なMacroは特にいらないよ
条件コンパイルはちょいつらいが
Refrectionもあるしな
Cの代替は無理だがC++だな

オフサイドルールなパーサ作ったヨット
<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()"/>

あ、ネストが、、、。
<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()"/>

ということで、敵に塩を送ってしまった。
しかも、パーサじゃなくてレキサだわな

>>652
くだらね
キモオタガンヲタは死ね

中にはキモヲタ関係ないのも入っているが
まさしくどうでも良い

>>660
オフサイドルールよく知らないんだけど
a
　　b
　c
　　　d
　e
　　f
g

で
(a ((b) c ((d)) e (f)) g)
みたいにはならないのかな

>>658
それがどうした？としか

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
というようなリソース管理に使えるかな、と思った
インデント構造でまっさきに思いつきそうなやつだけど

>>665
改行を許さない糞言語は不要

行末尾に\でもつければいいんだろ

>>665
YAML？

>>664
C言語風の式言語にはオフサイドルールはいらないと
言っているのはオフサイドルールを理解できない、
実装できないという理由からではない証明になったかと。

>>665
そういう設定用にはyamlがありますよね。

>>660
ネストによってブロックを表現するのがオフサイドルールなので
必要以上にネストは深くする必要はないのだと思います。
こんなかんじで出来るよって例でタブも１文字と数えてるので
PythonやHaskell等の仕様とは違います。

>>669
頭悪いのがコード貼り付ける前に、そんな議論あったか？
馬鹿がまたプログラムの勉強会始めたとか思ってたけど？

自作自演でスレを埋めるの辞めて欲しい。

いい加減、お前らが作りたい言語の仕様をしっかり定義しろよ

C言語とLISPの合体したコンパイラ

#lang lisp
(defun lisp () (puts "hello world"))
#lang c
int main() {
lisp();
return 0;
}

gccのソースコードみてみそ

見るとどうなるの？

RTLのmdファイルとかのこと言ってるんだろうけど
発想が全く違うよ

結局欲しいのはC言語としての出力なので、
LISPはあくまでも補助言語と考える。
LISPはプリプロセッサ的に使う、もしくはトランスレータを
内蔵しておき全てCとして出力する。内部のLISPランタイムや
GCなどが関係するコードが残るようならエラーとする。

例えば、マクロを定義するためならクロージャやGCオブジェクトなど、
LISPのフル機能が使えるが、出力にはLISPの痕跡は残らない。

Cの欠点のひとつとしてマクロがあげられるぐらいなのに、さらにパズルを増やすのか？

マクロだけとは限らない。
コードの自動生成にも応用できる。
C++のテンプレート以上の効果が期待できる。

昔、似たようなことをやってた人がいた気がするけど、
LISPランタイムをリンクするような形だったので、
それとは方向性が違う。
ROMに焼くような組み込みでも使える処理系を目指す。

一部にLisp入れるくらいなら、全部S式でいいよ。

目指す所は単なるLISP->Cトランスレーターとは違う。
ただのLISP処理系にしてしまうと目的がぼやけてしまうし、
S式をベースにすると冗長だったり書きにくい部分が必ずある。
Cとしての出力が目的なら、あくまでもメインはCであるべき。
学習コストと天秤に掛けると、独自言語という発想でもダメ、
それぞれ専門家のいる既成言語の組み合わせがちょうどいい。

あんまり混ぜるとrubyみたいになりますよ

それなら、新言語のマクロも新言語風の文法（A)で書ければいいんじゃないの。
なんで、新言語と異なる文法（B)でマクロをわざわざ書かなければいけないのかわからん。

異なる文法（B)の方が便利なら、新言語の文法自体をそちらの文法（B)にすればいいよね。

新言語、新言語風だと誰も使わない可能性がある。
俺はそんないつ消えるか判らない物は覚えたくない。
おれはCもLISPも知っている。だから両方使える言語を書く。
それだけ。

なんか、かっこいいですね
惚れました

>>686
スレ違い

はいさよなら。

まあ、マクロは言語自体の文法で書けるのがいいだろうな。

C言語のプリプロセッサの大部分は言語組み込みにしたほうがいいけど
マクロ関数は便利だしシンプルだ。
型安全ではないかもしれないが、動的言語のようにどんな型でも
変数に受け取って様々なことを高速に出来る。
遅延評価的なことも特別な仕組みもなく使える。
多くの言語の処理系では関数マクロを使われている。
インライン関数だけではなんともならない箇所もある。

多くの"高階な"言語だろ
マクロでいじり倒したコードなんて趣味のもんだな

新言語ではワクワクするようなコーディングをしたい。

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

低レベルな言語なんだろ？
趣味を満たしたかったらScalaでもOCamlでもやってた方がいいんじゃないか

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

低レベル＝実用的な言語が欲しいんだろ

まあスレッド、バリア、Mutexが
CSP風に組み込まれてたら面白そうだがな

いつも思うんだがお前らが作る言語は
どの言語にそっくりなのか

型に甘いの型に厳しいのか
動的型付けなのか静的型付けなのか
グローバル変数とグローバル関数は許すのか
goto文はありなのか
C/C++/Javaのように改行なしでも一行で膨大なコードを
書くことすらできるものなのか否か、
型に文字列型、配列型、整数型、小数型、文字型、bool型等
きっちり細かく決めるのかそこらへん適当なのか、
クラスはありなのか、
クラスがありのときjava.lang.Objectのような基底クラスがあるのか、
例外処理がありのとき、java.lang.Throwableのように例外やエラーの基底クラスがあるのか、
アサーションありなのか、
アスペクト指向でポイントカットやウィービングありなのか、
Java Generics、C++ templateのような型はありなのか、
マルチスレッドの扱いはどうなっているのか
staticと非staticの違いはありなのか
などなど疑問点が付きないのだが

なげえ。
Cに代わる低級言語ってスレタイ思い出してまとめろよ

Cの関数マクロは実用的だ。趣味だけじゃない。
VC++のメッセージもマクロだ。
RubyのCのメモリ管理周りもマクロだ。
VMの実装にもマクロ。
マクロ、マクロ。
Cのマクロはただ美しくないから嫌われてるだけ。
欲しいのは美しいマクロ。構造化されたマクロがその答えではないか？
テンプレートはホントに美しいか？
インターフェイスの記述をトランスレートするのが簡単であればよい。
エディタの色づけが楽であればよい。

マクロもテンプレートも、C/C++のきたないところ。

テンプレートは（文法以外は）美しい

>>698
自分は言語は小さく、ライブラリに出来るものはライブラリにする。
演算子定義とLispのマクロ的なコンパイルタイムプログラミングで
抽象化し記述力を上げる言語を考えているので以下のようになります。
どんな言語に似てるかはシンタックスはJavaScript、Lisp
機能的にはD、Scala、golangあたり。
型 プリプロセス時は甘く動的、コンパイル時は固く静的
グローバルありで、gotoあり、改行なしで書ける。
型の詳細は未定、クラスは言語で仕様はないけどライブラリで実装出来て、
例外はありで巻き戻し処理はマクロでやろうとする。
アスペクト指向はプリプロセッサでやれる。
ジェネリックス、C++テンプレートもプリプロセッサで、
Tではなくa'的なものを検討したり衛生的なマクロ等、後から出来る設計。
マルチスレッドはライブラリで。synchronized式をマクロで実現できれば。
グローバルなstaticはprivateで、関数内、class内staticはありかな？

テンプレートが美しいのは、文法だけ。

hoge<foo>とか超汚い

C++のテンプレートがクソなら
Java Genericsを適用すればいい

これをもう少しオサレにする感じで

LLVM Assembly Language Reference Manual
http://llvm.org/docs/LangRef.html

C/C++に変わる低級言語って、DとかGoじゃいかんの？

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

「なぜ、新たなプログラミング言語を考えることが目的になるのか」
を考えることには意味があるだろう
そうすることによって、作るべきものがもっと明確になる

じゃあ、考えようか。

とりあえず、Goが失敗したから

【このスレの趣旨】
初代>>1「とにかくC/C++は古くてダサいので、C/C++に変わる何かが欲しい。
　Cは今でも『低レベル』の開発で使ってるらしいから、そこで使える言語キボンヌ。
　言語研究の最新トレンドなら何でもいいけど、取りあえずOOぐらいは付けといて。」

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

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

(´-｀).｡ｏO(こいつらじゃ無理だな、まぁいいかどうせ糞スレだし）

(´-｀)←現実世界では間違いなくこいつが一番役に立たないんだけどな。

ＯＳとか今から作らないし
言語１から作るより多言語のオブジェクト利用でいいじゃないか
こういうスレで実際作られたの見た事ない

JavaのOSは一応あったぞ
たぶん他の言語でもいくつかはあるんじゃね？

プログラマーとして会社に勤めていても周りの奴らは
こいつ一人じゃいくら時間あってもまともなアプリケーションつくれないだろって奴だらけ

(´-｀)←こいつがな。

C言語の代替ということは即ちアセンブリ言語の代替に他ならない
アセンブリ言語(もっと言えば機械語)がわからんヤツは議論に参加する資格なし

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

多くのプログラマを困らせる(仕様上の)あいまい、無責任を許してはならない
今となっては使い物にならないものはバッサリと捨てる
多くのプログラマが毎回唱えるおなじないは簡素化もしくは自動化すべき

最後の1行だけ採用

要するに君達は
Ｃをキレイにしたいだけだろう

最近の言語で流行ってる機能も入れたい

>>718
Cに残っているマクロ以外の時代錯誤なしがらみってなんだ？
基本型のサイズがあいまい。これくらいか
他に何があるん。
そっからスタートしてみてはどうだ

>>711
goはこれからだよｗ

最近の CPU や OS に最適化しやすい設計がされててコードが綺麗に書ける奴頼むわ。
セルやマルチコア意識した奴。

メジャーなコンパイラ使ってれば哀れなメンテナが勝手に対応してくれるよ

T -> a' -> ?

マクロアセンブラは実用的
オブジェクティブアセンブラはあるのか？

アセンブラでなくなる気が

オブジェクト指向は素晴らしいので
アセンブラでもオブジェクト指向なプログラミングをすべき！

低級言語かどうかはわからないが、
マルチスレッドプログラムが安全効率的に書けるシンプル軽快な言語は欲しい

>>729
Erlang, Go-lang

マルチスレッドいいねえ

>>729
ここで言ってる低級よりは上の話だろうな
言語組込のメッセージパッシングやアクタとかだべ？

良いねぇそういうのが良い。

test

>>732
でもそういう理論だけでは効率的な実装ができないのは歴史が実証済み。

てかスレッドスケジュールはOSの仕事だと思うので、
OSに仕事を任せられる言語仕様が必要だと思う。
スレッドは頭痛いよね。ライブラリ対応しちゃうと
言語と離れすぎるし、言語対応するとランタイムの
問題が発生するし。

実行時のスレッド管理などそもそも言語仕様に含まれるようなもんじゃない。
言語仕様には「コンパイラへの指示(あるいはヒント)」を含めるんだよ。
「ここは(可能であれば)別スレッドにしてね」というだけ。
あとは環境ごとにコンパイラが合わせて最適なバイナリを吐く。
判断するのはコンパイラの仕事。それで十分。

>>737
スレッドモデルによって、何をヒントとして出さなければ
いかんのかが少し変わってくるし、シングルCPU上でスレッド
命令の取り扱いを決めなきゃ駄目だし。
そしてそれを検証できないと駄目。

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

誤爆した



だめだ今日はもう寝る

マルチスレッドの扱いも新言語のスコープだよ。

>>739 >>740
スレッドの切り替えに失敗したんですねw　

メッセージの送信先が間違ってたんだろｗ

標準ライブラリで用意する関数郡は全てスレッドセーフにするべきだ
strtok()とかロクに使わない上にスレッドセーフでもない完全にいらない子
自分が過去のしがらみと言ってるのはこういう部分だ

ソケット周りも巣窟だな

ランタイムはいるがCSPみたいなマルチスレッドサポートのデータ型とか
排他用の変数とかあったらいいよな
pthreadほどじゃなくていいけど、小さなRTOSレベルで制御できたらいいな

副作用を制限しつつノイマン型に最適化された言語が欲しい

>>725
Tとかa'って何？

型変数も知らんのか
お前にこのスレはまだ早い

早いも何も、googleにすら出てこない用語を使うのは、自己満足以外の何者でもないよ。

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

自己満足ではなく、他人と対話をしたいのなら、一般的な用語を使うべきでは。

トップに出てくるじゃねえか

コンパイラ用語のわからん奴は来るな

strcpyとか、memcpyとか、脆弱性無視した標準関数だらけのC言語は害悪。

いや、memcpyがなきゃ、OSのディスクバッファの読み書きとか書けないだろw

Cで脆弱性とか言っている時点で、参加する資格なし。

問答無用でセキュリティホールになるgetsとかは問題かな

組み込みでもマルチコア構成だったりネットワークに繋がったりする昨今
脆弱性を考慮しない>>755のような脳無しこそ本当の害悪だわ

ネットワークはいいとして、マルチコアと脆弱性に何の関係があるんだ？
知ってる言葉並べたがるお年頃なのか？

言語仕様の話かライブラリの話かはっきりしろ

memcpyはいいが、strcpyは時代遅れ。

京大霊長類研究所の猿が立てた雑談スレに書き込むに、なんの資格が居るんだｗ

で、結局T, a'って何なの

>>761
霊長類学修士か、獣医学修士

ゆとり世代といっても平均値が落ちてるだけでおまいらより優秀な奴はゴロゴロいる様に
霊長類の知能も平均値が落ちるだけでおまいらより優秀なアイちゃんはゴロゴロ居るわけだ

Haskell見てるとPrologでいいじゃん、て思うよね

>>761
アイちゃんへの溢れんばかりの愛を持ってる事ただ一つ

>>762
意味不明の単なるノイズだから気にしなくていいよ。

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の間違いです。
といったメッセージが表示されることです。
?は可能性爆発するのでそれなりの計算途中の状態が表示されることです。

inc(a) { return a + 1; }
↑これをこう↓書くと、どういうメリットが生まれるの？
[a] inc([a] a) { return a + 1; }

[a]によって何をさせたいのか明らかにすると議論が深まるよ。

>>768
OCamlでは
let inc n = n + 1
はint -> intに推論されるけど
Cの系統だと+演算子が整数や実数全部にオーバーロードされるから
この場合は「+が定義されている型」という制約つき総称型みたいなものに
自動的に推論して欲しいってことか？

推論するときは、推論したとログ吐いてくれればいい。

inc(a){return a + 1;}
では型が記述されてないんだけど、型推論によって
[T] inc([T] a){return a + 1;}
と推論されるといいねと。
#define inc(a) a + 1
と書くのと同等の記述量の少なさになって型なくて展開された後のコンパイルエラー
が分け分からないということもなくていいのかなと。

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

[a]は配列にしたいだろうからT[a]とするとかT{a}とかなにかいい記述方法あるといいと思います。

「[T]」って自動推論によって推論された型のことを表しているんだな。

オレ記法を説明なしで書かれると疲れるよ。

#define [A] inc([A] a) a + 1
深く考えてないですが、こんな感じの型付きのマクロでマクロ展開時の
コンパイルタイムプログラミングのエラー出力が
わかりやすくなったらいいなとか。
よりハイジニックなマクロが可能と。
ここらへんに改良の余地がありそうだと思うのですが、
自分で何言ってるかよくわからないので考えてみます

>>773
そうです。説明不足で、すいません

分かればいいよ。ドンマイ。

I thinking now...

ダックタイピングいいな

>>768
もうPerlとかPHPとかJavaScriptとかみたいな型にいい加減な言語でも
作りたいのかと

>>779
テンプレートライブラリと、マクロがごちゃくちゃになってる馬鹿が
書いてるのでそう誤解しちゃうんだと思う。
多分>>768馬鹿だけど、動的型変換は目指してないというか、目指すだけの
知恵が無いというか。

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

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

C/C++には、C言語の文法、C++の文法、プリプロセッサマクロ、さらに
STL文法という４つの文法が渾然一体となっていて、これが悲劇の理由だと思う。
さらに、標準ライブラリは古いは、基本スカラ型が曖昧だわ、悲劇の塊だと
思うのですよ。悪いのは>>768馬鹿が馬鹿を自覚してない事なんだけどね。

そんなに悔しかったんですかね。

新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。

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

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

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

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

782 ：デフォルトの名無しさん ：sage ：2010/05/15(土) 16:35:19
新言語では、メタな記述と、通常の記述を同じ文法で扱えるようにしたい。

バグがでにくい言語仕様が欲しい

バグが出にくく、かつ、煩雑で冗長な記述の繰り返しが少ない言語仕様が欲しい。

効率を最優先しつつそのなかで最もバグのでにくい仕様でおねがい

Javaのautoboxing、C#のboxing, unboxing変換はどうする気だ

クラスがなかったら、そんなのあってもうれしくないな。

ロジカルなバグはプログラマーが頑張るしかないんだけど、
if( a=1 || 32 % x){
}

こういう記述で、コンパイルが通り実行もかかるのに、
いくつもバグが入ってるってのは避けたいよね。

もう、前置記法でいいよ。

>>789
int型とbool型を明確に分けて、その間で暗黙のキャストをしないようにしたら解決する。
代わりに、パズル的記法の面白さはなくなる。

>>789
普通のコンパイラは警告が出る。

関数形でそんな暴挙に出たら使い物にならないぜ

代入の記号をもっと考えたほうがいいな。

>>794
:= 代入・複製
<= ムーブ

>>794
なれると間違えないようにはなる。
たまに、BASIC、PASCALを見ると違和感を感じるけど。

　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;;
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;;　　なれると間違えないようにはなる・・・
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんなふうに考えていた時期が
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f.　　　俺にもありました
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!

で、>>789が怖いのは、
なんだ書き間違いのバグじゃんって、事で

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

と書き直して、実行してみて結果が大丈夫で良かったと思って納品すると、
x==0の確認忘れてて、　1!=a の条件にぶち当たって、ゼロ除算例外で
プログラムが停止して、ものごっつい涙目って事がよくあるんだよね。

0除算って、構文の工夫で防げるものなの？

というか、C言語の仕様ではor条件のときに二番目を評価するかしないかは
実装依存。という事で、1==aの間はX==0でも評価されないので
zero助産が妊娠。

え？

>>800
えっ

なにそれこわい

>>800は伝説の釣り師

>>799
どちらかというとアルゴリズムの改良だね。単位ベクトルを求める演算を工夫して無くすとかだね

>>805
それって、既存言語と変わらないアプローチだよね？

新言語として構文の改良でどうにかするのは難しいかな。

>>806
/演算子を無くすぐらいしかできなくね？

変数を無くせばコンパイルエラーで弾けるな

0以外の数という型を新設して(数学っぽく書けばint*とか)
それを分母に持ってくるようにキャストするよう強制すれば
一応は0除算防げるが、誰も得しない。
non-null型と似たような発想。non-null型は得するけど。

加算と乗算が可能な自然数型を定義すればよい
減算と除算は自然数に関して閉じていないのでダメ

しかしそれでは不便なので、皆単なる整数を使うのであった…

「自然数」って何だか知ってる？

>>810
対象は符号なしのみか。

一回しか代入できない変数、
継承禁止、メソッドのオーバーライド禁止、メソッドの引数の上書き禁止に使う
finalは導入するのか？


それとも、メソッドのオーバーライドを可能にするvirtualを導入するのか？

>>805
単位ベクトルだと？
おまえはMATLABのような言語でも作ろうとしているのか？

>>799
防がずに複素数を導入したり
無限大やNaN、かのならNaNより複素数やを返すのもありだ

>>809
Rational型(有理数型)か？
クラスで実現可能だな。
Complex型(複素数型)の導入もありだが。

デフォルトでは、整数型・実数型は任意精度にしたいな。

必要の応じてコンパイルオプションやソース中で型宣言出来ればいい。

割り算は演算子をsizeofみたいな予約語にしてほしい
これだけでもコード確認が容易になる

なぜ割り算だけ

割り算だけは例外発生するから

例外発生させなきゃいいじゃん

やっぱり低級言語でも例外機構っているの? 組み込み系の人が怒りそう。

いや/0は例外発生しようがしまいが問題あるだろ

>>1
それは無限精度でもなければ、加減乗算でのオーバーフロー、アンダーフローでも同じことだろ。

割り算だけが０が特別だからだろ
オーバーフローアンダーフローは四則演算すべての問題

で、それと割り算だけsizeofみたいな予約語にすることと、どう関係があるの？

>>822
CPUによると思うけど0除算てCPU割り込み発生したりするでしょ

CPUによるね。

明らかに特殊な演算を記号にすると検索性の問題がある

四則演算は特殊じゃないよね。

四則演算は一心同体だろう。ひとつだけ特殊な扱いにするとかはない。
するなら全部する、しないなら全部しない。

割り算だけ特異点がある。
これが同じとか数学のセンスなさ杉。

余剰演算もたまには思い出して挙げてください

>>822
この件にまじめに答えると、
スタンドアロンな画面のない装置でも、
LEDとかでエラー通知する手段は設ける。
例外機構が使われないのは、追加ランタイムとかで
サイズが膨れあがる事が多いのと、ほとんどの場合
MCU側の仕組みを直接使う方が楽だから。

例外のある言語はクリティカルなソフトウェアの
構築には使えない。らしい。

>>832
四則演算の一つだけ構文的に特殊な扱いをすることにセンスを感じないが。

数学的な話すれば
引き算と割り算はそれぞれ足し算と掛け算で言うところの
逆元を使ってるだけ。

>>836
ヨーロッパのキリスト教徒は君と同じセンスで、
ゼロもマイナスも複素数も認めない、
っていう時代が、1685年ほど続いた。

一般に暗黒の中世と呼ばれてる時代。

>>837←単なる知識披露で全く意味が無い書き込みの例

>>837
必ずしも逆元は存在するわけではないって言ってるんじゃないの？

>>838
ひどい話のすり替えだな。

ゼロを認めないで特別扱いしようとしているのは君のセンスの方だろう。

特別扱いしないのなら０割はどういう扱いにするん？

inline関数のスコープはレキシカルスコープ。
Cのマクロはダイナミックスコープな関数と考えたら面白くないですか？

面白くない

>>842
0以外の定数でしか割れないようにすればいい

なんだかますますC言語でいいような気がしてきた！

で変数で除算するためにビット演算を駆使するんですね！

保守的だな

>>845
定数だけってそれこそ特別扱いじゃないか？
定数で割るってことは定数で掛けることと一緒だぜ。

なんか初心者がいるな

>>842
どれか

(1)例外を投げる
(2)NaNを返す
(3)仕様上、未定義にする（除数に0を入れたユーザーの責任）

またループか

どの辺が？

現状の方法に戻った

現状も何も、新言語はこれから作るんだけど？

>>851
NaNでいい。これが一番スマート。
未定義動作は極力含めない方向で。あいまいさは最も唾棄すべき仕様なので。

整数型の場合は？

(1) 0
(2)とりうる最大の値
(3)とりうる最小の値

0/0はどれ？

０除算したら、現状通りSIGFPEでプロセス終了でいい

現状なら例外ではなくて？

ユーザーにどう伝えるかの議論がないところがレベルの低さのゆえん

C++等は例外で拾えるんだっけ
勝手にシグナルハンドラ定義しているのかな

>>862
あなたの考えは？

なんか変な話になっとるね
- NaNは整数型では実現不可
- java/C++風の言語組み込みの例外は下品
- 858は意味不明

構文的な例外は不要だが
signalみたいな割り込みはあっても面白いかもな

0/0 の動作は implementation-defined か unspecified でいい

おまえらじゃCの代わりは作れんな

Cでは「言語があまり余計な事はしない」のが鉄則

生成バイナリは余計なことをしないほうがいいがそれ以外は手厚くすべき

速度に影響する２つの仕様案があるなら
速い方を選ぶのがCの基本

速い方と遅いけど色々出来る方の
両方を用意するのは構わないが

整数型のビットパターンのどれかをNaNにすれば…と思ったけど難しいな
そもそも2進数で最上位ビットのみを符号とみなしているのに残りのビットが正負で絶対値が異なるのは何故だっけ？

00001111 = 15
10001111 = -113 //何故 -15 ではない？

おまいらに任せても劣化 C しか出てこなさそうだな。

だからC最強だってw
C++みたいな劣化バージョンと一緒にすんなよw

>>871
ついに補数知らないヤツもきたか
2の補数、1の補数でくぐりな

>>874
補数は知ってるよ。何故そうするのか？を知りたい。

>>875
ここから出てくるな
http://pc12.2ch.net/test/read.cgi/tech/1178723829/

半加算器とかそのへんから

つまり古の時代に減算回路を省いたが故のしがらみということか

>>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 を返します。

>>837
だからそんなのでは0除算対策にならない。
MATLABのようにNaN、Infという値を新たに作るか、
それとも例外処理を追加するか、など検討しなければ

それから0除算対策として
割り算を分数として保持しておくてがある
RationalクラスやFractionクラスで作成する分数オブジェクト、といったところか

>>856
それは分子が0のときだろう。
分子が0以外の実数のときは -Infinityか+Infinityを返すべきだ

>>882
Infinity返すのは違うだろう。単に未定義なんだから。
例えば、lim[x->-0]-1/x の場合は+Infになる。

0で割ることはできない。意味がない。結果うんぬんの前に実行できない。だから例外を返すわけよ。
むりやり値にするならNA(not available)が一番近い。

面倒だから例外を投げるでいいよ
次は受け取る方法を書け

>>885
おまえが書けｗ

>>860
それCの仕様でも何でもなくて、x86ではたまたまそういう動作ってだけだべ

キャッチもできずいきなりプロセス終了って怖すぎて使えないな。

次スレは「【超光速】C/C++に代わる低脳言語を開発したい」な。

>>887
お前x86しか知らないだろう？

>>890
うん他の石はほとんど知らない
整数0除算を浮動小数点例外と同じ扱いにする石ってそんなに多いの？

SIGNALを受け取った後例外を投げるとすれば例外の話になる

構文上は
1)C++,java,C#の例外を使う
2)Visual Basic の on error goto の改良
3)Scalaの例外的なものにする。マッチング構文的なものに
4)もっといい例外構文を作る
{
try =>
　a = 10 / 0;
case e@Exception(_) => println("zero divide");
}
と書けるとか。

俺らにはできるな

　　　　　　　　　　　 (＾G ＾)
＼(＾ J＾)×(＾ H＾)／ |　|＼(＾ D＾）／　俺たちならできる
　　 |　|　 　　|　|　　＜　＞　 |　|
　　<　 >　 ／　＞　　　　　 ／　＼

　　　　　　　　　　　　　　　　　　　　　　　　アイちゃん言語開発スレ
　　　　　　　　　　　　　　　　　　　　　　　　http://pc12.2ch.net/test/read.cgi/tech/1273199795/l50

アイちゃんも応援しています

>>891
石というよりOSの仕様だけど、たいていの場合Zero除算例外はSIGFPEだと思う
逆に浮動小数演算の例外は（デフォルトではCPU例外とならず）
SIGFPEにならないことが多い

>>879
>さて、それは何進法で表現するのか？

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

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

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

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

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

実用上はBCDだけあればいいんだろうけど、
数値の内部表現を任意N進数に指定できてもいいね。

8進数リテラルって必要？
ファイルモードぐらいしか使ったことないんだけど・・
open(filename, O_CREAT, 0666)

2進数リテラルは0b0000_0000って'_'を付けられると嬉しい
おれの自作処理系では受け入れる

数値リテラルの区切り'_'は確かに欲しいかも。

任意精度なんて可変長型や動的型付けと同じくらい効率悪そうだな
静的型付けで高速動作を期待する低水準言語には最もいらないものの一つだろう

新言語は、低水準の記述”も”できる低水準言語だから、開発を容易にする高水準の記述も当然できるよ。

>>902
>低水準の記述”も”できる低水準言語だから

日本語でおｋ

ごめん。”は引用符で濁点じゃないよ。

ぶっこみの択(なぜか変換できない)

問題は名前をどうするかだ
特にイニシャルが重要だと思う

A awk ←Aは辞書順的にやっぱ強いよね。ここもありだよね
B basic
C C
D delphi
E erlang Eiffel
F FORTLAN F#
G golang
H HSP ←HSPと同じイニシャルはなんとなく嫌だよね
I ←ここだ！ここに空きがあるぞ
J java
K ←隣国を思い出すから使いたくないね

>>906
@にして先頭ゲット

>>906
ああ？Ioディスってんのか？！

任意精度はライブラリだろ。
任意精度ライブラリが記述できるのが低級言語に課せられた使命。

>>906
IChan

>>908
IO(アイオー)とかぶってるから使いたくないよね
検索に引っかかる名前にするのは常識だよね

asdfというのはどうだろう

間をとってiM@Sで
俺は雪歩ライブラリを使う

>>912
グンクツの音が聞こえる

>>892
ということは例外はPHPの仕様でいいなw

>>897
実装依存ねぇ
コンパイラが乱立するだけだろうねぇ
各型ごとに2進数型、10進数型というものをきめたほうが負担が減ると思うけどね
2進数型のdoubleはIEEE754規格に従うべきだね

http://ja.wikipedia.org/wiki/IEEE_754

_

まてまて、2進数"型"ってなんだ？2進数表記ってだけだろ？内部では全て2進数なんだから。

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

とかを"ソース上で"表現できればいいだけだろ？

レス嫁

>>918
いや、少数の場合、内部表現の底によって無限小数になったりするんだよ。
例えば、１０進数の0.1は、２進数では0.000110011…の無限小数になる。
だから少なくとも実用上はBCD（Binaly Coded Decimal）のサポートがいる。

Binaly → Binary

10進数型のBCDではどのような分野で使われてるんですか？

勘定系とか

COBOLが使われているところ

低級言語のスレじゃねえの
勘定系の話はいらんじゃろ
せいぜいオブショナルなデータ型があれば十分

10進のハードウェアなら低水準でも10進型は必要だろ

>>926
１０進ハードウェア用のデバイスドライバーを開発できればいいのであって、言語仕様に「１０進型」を含む必要はないのでは。

なんつーか…会話してるように見えて実は座ってるフロアが違うっていう
B2Fで話してる人と31Fで話してる人では話がかみ合わないのも当然だな

>>916
任意精度の話からなんでIEEE 754に結び付くのかよく分からないけど、
Cでいうfloat/doubleのような型はIEEE 754に従っておけばよいと言う点では同意。

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

しかし、IEEE 754ができてからは、CPUもそれに従うようになったし、
Javaなど後にできた言語も、浮動小数点数の内部表現は軒並みIEEE 754のものと仕様で規定している。
今度の言語もIEEE 754に従えばいいと思う。

>>926-927
実際、十進浮動小数点演算を持っているCPU対象のGCCでは、
_Decimal64などそれ用のデータ型が使える。

低水準にdecimal組み込んでも矛盾を起こさないからあってもいい。ライブラリで組み込んでも使いにくいし。

たまにBCD接続な機器があったりするからな
8bitから64bitまで、CPUや構成もまちまちなのをカバーするには
オプショナルな部分は必須だな

BCDだけでいい？
任意N進数型とかは要らない？

なるほど。コンパイラ作る側ではめんどくなるし
つわなくていい人は関係ないけど、CPUにも機能があるから
言語仕様に入るべきってのは正論だと思います。
ライブラリで提供するとしたらライブラリで提供されていても
関数だけではなく演算子も使えるようになっていて欲しい。
関数だけで書け言われても、嫌だわ。

任意N進はいらないんじゃね
BCDにしても必須てほど使われないしね
Decimal/Complexとかはあっても悪くない程度じゃないか

ところで、新言語のVirtual Machineをどう実装するかお前らは考えたことはあるか？

何のためにVMが必要なの？

MMX・SIMD・SSEも使いたい

いまどきの新言語はVM実装があたりまえ

PerlもC#もVMを実装
OS非依存目指すならそれくらいかないと

そのPerlやC#が嫌だからこのスレがあるわけで

高水準言語ならともかく、低水準言語にVMはないわ。
ていうかVMを実装するための言語。

「低水準でも」使える言語なのでVMがあるのかどうかは関係ない。

それでもVM前提とか無いわ。

>>939
で、何のためにVMが必要なの？

Java, C#でさえ仕様上はVM必須というわけではないのに。

共通の中間コードに一度変換した後に
その中間コードを各CPUにコンパイルするようにすれば
複数のCPUに対応したコンパイラが作成可能だ。
そこで共通の中間コードがネイティブで動く仮想マシンが必要になる。

何で中間コードをそのまま動かそうとしてるんだよｗ

中間コードをさらに各CPUのネイティブコードにコンパイルするんだろ？
各CPUのネイティブコードとして動かせばそれでいいだろ

基本レジスタ渡しな
レジスタは最低スタック用とフレーム用に2本かな
printfみたいな可変長引数はどうしようもないが

C#のJITコンパイラは実際SSE2ありと無しでは吐くコードが違うからな
ぐぐってみ

で？

中間コードを考えるということは仮想的なマシンを考えるのと同義だ。
でも実装って書いてるな。むむぅ。
動的にコードを変更した最適化が可能だったりコードを小さく出来たり、
セキュリティ的にサンドボックスが作れるので
ネットワークでの配信が容易になったりするとか。

LLVMでいいやん

ネイティブコードを吐くコンパイラも、内部で中間コードにあたるものを生成していることを知らないらしい。

ビットシフトを適当に使って書けば
最適化でビットローテート命令に使ってくれるかもしれないけど
言語側でビットローテート用の演算子がほしい

>>953
どんな記号な演算子？
>>> <<< は算術ありなしとかだったから>>>> <<<<とか？
長いから >-> <-< とか？

>rol>
>ror>

頻繁に使うものじゃないし、ror()とかrol()とかの関数でいいんじゃないの？

大抵はキャリーと組み合わせるから
キャリービットを扱う方法も欲しい

またアホな話になってきたな

(int a, bool carry) = a >ror> 3;
あるいは
(int a, bool carry) = ror(a, 3);
というかんじで使えるといいと。

a >ror> 3
だと、 a > ror > 3　と区別がつかないのでいまいちじゃない？
記号のみの組み合わせにするとか、``でくくって`ror`にするとか
ror だけにするのがいいと思うよ。

次スレ

【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/

<@ >@
だな
顔文字か作れる言語にしようぜ

とりあえずschemeでプロトタイプでも作るか

期待してる

S式の呪縛に囚われてはCに変わることは出来ないぞ

反発も半端じゃないけどガンバレ！

ああまだ5が残ってたのか

6に書いたけどニーモニック云々

このスレの目指す言語はgolangじゃないかという気がする
並列処理組み込んでるし、ガベコレもあるし

俺もそんな気がする
どうせ作らないだろ

やっぱgoだよな
ガベコレ無しのgoが理想的なんだがな

あとはWiring程度すら使いこなせねえレベルのもいるな
低レベルってのが俺からしたらドバイタワーの頂上みたいに見える話が多いし

LISP民族とかLL民族がここぞとばかりに、
自分たちの言語に入ってる機能をねじ込もうとしているからな。

蛮族に作法を教えてやってるのだ

ねじ込ませたいと思うほどの機能なら、検討する価値がある。

>>974
彼らはOSやドライバの仕組みを知らない。

すべてを知っているのであれば、情報交換なんて必要ない。

自分が提供できるものを提供し、雑多な情報の中から自分に必要なものを拾うことで、高め合うことができる。

妄想垂れ流して情報クレとな

>>974
バカに混じれ酢するのもどうかと思うけど、
ＬＩＳＰやＬＬはアセンブラと相性悪いんだよ。

と言って思考停止

という類の発言は無意味である

俺もそう思う。

>>977
不覚にもわろた

goはastがライブラリに入ってるから遊べるぞ