トップページ⇒tech
1001コメント269KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2010/04/13(火) 00:40:41
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 2
http://pc12.2ch.net/test/read.cgi/tech/1270254244/
0002デフォルトの名無しさん2010/04/13(火) 00:44:05
422* 名前：デフォルトの名無しさん [sage] 投稿日：2010/03/22(月) 20:49:29
それならCにできないけど低級言語に欲しい機能を挙げてみようぜ。
・Lispなみに弄くれるマクロ
- テンプレート
- 正規化された構文(S式とか)
・Forthなみに弄くれる駆動レコード
- コルーチン
- 強制インライン展開(レコードを新しく作らないルーチン)
- 駆動レコードへのアクセス
・実行制御
- 高度な並列処理(トランザクションとか)
- アトミック操作
- リアルタイム操作

こんなもんかね？ 他にどんなの欲しい？
0003デフォルトの名無しさん2010/04/13(火) 00:58:14
376* 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/08(木) 04:45:08
自分は構文上の話が詳しいのでそちらだけ書き込ませてもらいます。

以下の議論をしてみてほしいです。

・新しい言語は式ベースで作るべきかどうか？
コンパイラの研究に使われている関数型言語の構成が式ベースになっているので
それに習う?
いろんな機能てんこ盛りがよい？

・式言語をベースにする場合どういったものにするのがよいか？
演算子の優先順位は必要？
endで終わるほうがいい？
オフサイドルールって必要？
{}がいい？

・HaskellやPrologのようにユーザーが優先順位付きの演算子を登録できる機能が必要か？

ないほうが実装が楽になりますが自由度は減ります。

・EcmaScriptやScala、ActionScriptではXMLを直接かけるが必要かどうか？
0004デフォルトの名無しさん2010/04/13(火) 00:59:19
379 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/08(木) 05:20:33
>>376
このスレはCに代わる低級言語ってことで
基本的にCPUアーキテクチャに沿った
手続き系で余分なことをしない静的な型の言語以外あり得ないんじゃないかな

個人的には(構文だけではないけど)
- ブロックを明示しやすくて文でクロージャ作れるし{}がいいと思う
- オフサイドルールはコードはすっきりするけど賢いエディタ前提で深さがわかりにくい
- Cよりシンプルな構文が望ましいが別にC系でいいんでは
- 演算子の再定義はスパゲッティ化しやすいから不要
- マクロもインラインとか定数型などの別な方法で実現可能なので不要
- XMLなんかは外でやればいいんでは
- 勝手にデータを付加しないASN.1とかCの構造体的なメモリイメージと直結したデータ構造
- 動的型付け、GCや動的メモリ管理は明示的に利用を限定出来るならいいかも
- その他のシンタックスシュガーは適度にアリ

みたいな感じ
不勉強だからブートストラップみたいなベタなとこを関数型言語で書けるのかな？
って思うんですけど
0005デフォルトの名無しさん2010/04/13(火) 01:01:56
540 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/10(土) 08:44:46
基本データ型
整数、実数
[]整数
byte : 1 [octet]のみ、文字だって数値だし、文字型いらね
integer : CPUが自然に扱える範囲で
[]実数
floating : 浮動小数点数、IEEEのでもなんでもかまわん
fixed : 固定小数点数、誰得
複合データ型
配列、多次元配列、構造体(のようなもの)、列挙、参照、メモリ参照(つまりポインタ)
[]配列
type[n] array
[]多次元配列
type[n,m,...] array
[]構造体、列挙
Cのがいいよ
[]参照
関数の引数にのみ使える、いわゆる本当のcall by referenceを実現するため
また、メモリ参照を増やさないため
alias unsigned integer uint_t;
ret-type func(ref type[,] array, uint_t row, uint_t column);または
ret-type func(type[,] &array, uint_t row, uint_t column);
[]メモリ参照
type@ memref
integer@ memref = new integer[n];
integer int, @ memref_int = ∫
@memref_int = 128;
integer[n] array, [n,m] marray
memcpy(&marray[x,0], array, n);
&marray[x,0] != @(marray+x)+0, &array[0] == array
メモリをうまく抽象化できればいいんだけど
0006デフォルトの名無しさん2010/04/13(火) 01:03:11
主な要望

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
0007デフォルトの名無しさん2010/04/13(火) 01:22:56
volatileに相当する修飾のサポートは必須と思うな
0008デフォルトの名無しさん2010/04/13(火) 01:23:27
どの言語のvolatileだ？一応
0009デフォルトの名無しさん2010/04/13(火) 01:29:06
メモリマップドレジスタの宣言
#define XXXX_REG (*(volatile int *)(0xC0000004))
のような記述がださいので

これをサポートする記述構文と namespace が欲しいな
オフセットずらしもできるようにして
（Cの構造体でごまかすこともできるんだが）
0010デフォルトの名無しさん2010/04/13(火) 01:30:07
>>8 もちろんCです
0011デフォルトの名無しさん2010/04/13(火) 02:18:03
別に僕は今のC言語で問題ないんだけど
新しいのを作るとしたらポインタ、特に関数へのポインタを引数に取り、関数へのポインタを引数に取る関数へのポインタを返す関数へのポインタとかを美しく記述できる文法を切口にポインタに変わるアドレッシング方法を考えればいいとおもう
int<- p;
int ()(void)<- fp;
int ()(int ()(void)<-)<- ()(int<- ()(void)<-)<- fpp;
ダメだ、読みにくい
int (*(*fpp)(int (*)(void)))(int (*)(void));

そもそも関数ポインタに代わるなにか、高階関数とかあればよいのだろうか
0012デフォルトの名無しさん2010/04/13(火) 02:25:49
>>11
普通に関数ポインタをtypedefすれば良いんじゃない？
0013デフォルトの名無しさん2010/04/13(火) 02:26:51
>>11
そのための typedef。
0014122010/04/13(火) 02:27:09
まぁ、関数ポインタを見やすくすること自体は良いと思うけど…
0015デフォルトの名無しさん2010/04/13(火) 02:44:25
ちょっとした思い付きなんだけどスコープ内にある関数なら、
第一引数と一致する型の変数から暗黙的に関数を呼べると以外と便利かも…
※javascriptのthisポイントみたいな感じで

char *copy( char *src, *dst );
char *trim( char *src );
char *toupper( char *src );

*p->copy(*dst)->trim()->toupper();
0016152010/04/13(火) 02:45:59
アホだ俺、もう寝よう…orz

*p->copy(*dst)->trim()->toupper(); ×
p->copy(dst)->trim()->toupper(); ○
0017デフォルトの名無しさん2010/04/13(火) 02:47:32
>>15
文字列型があればよかったんだけどね。
0018デフォルトの名無しさん2010/04/13(火) 02:49:08
>>5
結局型のサイズって重要だから
stdint風でいんじゃない？
0019152010/04/13(火) 02:50:26
>>17
そう、文字の操作とか、延々と同じ型の計算を繰り返す処理の場合、
見通しが良くなるかなと思って…
0020デフォルトの名無しさん2010/04/13(火) 02:55:14
文字列型は動的メモリ管理と直結だから
Cには入ってないんよね
実行系が必須だと困る用途もあるし
0021デフォルトの名無しさん2010/04/13(火) 02:57:10
intやlongは非互換の巣窟だからbyte以外無くそう
0022デフォルトの名無しさん2010/04/13(火) 03:07:41
関数ポインタならDのfunctionやScalaの関数宣言が参考になると

int function(int) fp; // fp は関数へのポインタ
int delegate(int) dg; // dg は関数へのデリゲート

val f:(a:Int,b:Int)=>Int = {(a:Int,b:Int)=>a+b} がデリゲード
val f:(a:Int,b:Int)->Int が関数ポインタとか
0023デフォルトの名無しさん2010/04/13(火) 03:19:51
>>21
だよなw
いまさらlongが64bitとかいわれてもw
0024デフォルトの名無しさん2010/04/13(火) 03:29:10
整数型はこれな
int8 int16 int32 int64 int128
uint8 uint16 uint32 uint64 uint128
0025デフォルトの名無しさん2010/04/13(火) 03:49:46
>>20
そう。結局、型としてはプリミティブ型だけしか言語には組み込めない。
0026デフォルトの名無しさん2010/04/13(火) 04:55:02
前スレで並列機能の話がでてたが
occamの並列構文とかおもしろいがな
実装的にはjmpbuf内蔵するくらいのレベルで実現出来そうだし
低級言語で1st classとして扱えると面白そう
0027デフォルトの名無しさん2010/04/13(火) 07:41:22
>>15
それいい
0028デフォルトの名無しさん2010/04/13(火) 09:57:13
>>15
C#の拡張メソッドね。
乱用すんなとは言われてるけど、なかなか便利。
0029デフォルトの名無しさん2010/04/13(火) 10:24:18
スレタイに妄想って入れとけよ
0030デフォルトの名無しさん2010/04/13(火) 10:36:26
>>29
じゃあ次スレはそうしよう
0031デフォルトの名無しさん2010/04/13(火) 12:20:31
>>25
アロケーターを外へ出して、アロケーターが定義されたときだけ
使えるようになるのはだめ？
0032デフォルトの名無しさん2010/04/13(火) 13:59:46
>>31
Cの美点は最低限のランタイムに
四則演算位しかいらないことだね
0033デフォルトの名無しさん2010/04/13(火) 14:27:24
いままでのは論理ベースの手続き言語。
では非論理ベースの非手続き言語はあるだろうか？
0034デフォルトの名無しさん2010/04/13(火) 14:51:08
Cはビット操作系の命令とSIMDへの対応がなっていない
オマイラ演算子とデータ型を追加してみてくれ
0035デフォルトの名無しさん2010/04/13(火) 15:50:55
>>33
おまいの喋ってる言語だよw
0036デフォルトの名無しさん2010/04/13(火) 17:09:26
>>35
論理なしにどうやって意思を伝えるのだろう。
0037デフォルトの名無しさん2010/04/13(火) 17:16:24
情だろ、普通
恋愛したことないの？
0038デフォルトの名無しさん2010/04/13(火) 18:34:56
ラブプラスでもやってろ豚
0039デフォルトの名無しさん2010/04/13(火) 19:01:33
理論無しの言葉の実例w
0040デフォルトの名無しさん2010/04/13(火) 19:04:54
>>37
情の本質はなんでしょうか？
0041デフォルトの名無しさん2010/04/13(火) 19:14:30
結局>>1のやってる事って

【超高速】お前らC/C++に代わる低級言語を開発して俺に譲ってくれ

だよな
0042デフォルトの名無しさん2010/04/13(火) 19:18:46
>>41
ここを見てるお前もだろ
0043デフォルトの名無しさん2010/04/13(火) 19:20:55
次スレの名前案
【超高速】C/C++に代わる低級言語が欲しい【妄想全開】
0044デフォルトの名無しさん2010/04/13(火) 19:28:53
>>42
はぁ？

俺は一度も案に上がってない名前を勝手に付けて空Wiki立ち上げて影響力残そうとかしてねぇし

「名付け親、Wiki管理者の二つの名声は欲しいが、作業には関わらんし責任も取らん」とあそこまでハッキリ言いやがったんだぞ？

「譲ってくれ」のニュアンスも分からん文盲は黙ってろ
0045デフォルトの名無しさん2010/04/13(火) 19:30:52
d言語でいいじゃん
0046デフォルトの名無しさん2010/04/13(火) 19:32:00
何をムキになっとるかわからんが
こんなスレで作られるわけないし作られても譲るわけないだろ
馬鹿か
0047デフォルトの名無しさん2010/04/13(火) 19:34:14
>>46
脊髄反射レス乙
0048デフォルトの名無しさん2010/04/13(火) 19:52:41
>>47
お前もだろ
0049デフォルトの名無しさん2010/04/13(火) 20:06:07
文盲:ぶんもう
文がもうもうの意

0050デフォルトの名無しさん2010/04/13(火) 20:07:05
もう　とは　萌え　の方言である
0051デフォルトの名無しさん2010/04/13(火) 21:04:42
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0052デフォルトの名無しさん2010/04/13(火) 22:22:28
Schemeのように最小仕様で拡張性最大にできないかな？
0053デフォルトの名無しさん2010/04/13(火) 23:59:43
おれはゲーム開発用Javaを作成中
0054デフォルトの名無しさん2010/04/14(水) 00:07:46
おれも
0055デフォルトの名無しさん2010/04/14(水) 00:10:46
どんな仕様？
0056デフォルトの名無しさん2010/04/14(水) 01:13:09
classなしvmなしポインタとプリプロセッサ付けたjavaだよ
0057デフォルトの名無しさん2010/04/14(水) 01:27:28
そりゃだめだｗ
0058デフォルトの名無しさん2010/04/14(水) 02:09:10
>>52
lisp系が日の目を見る日はないなー
0059デフォルトの名無しさん2010/04/14(水) 02:13:13
関数型はメモリ管理複雑だろ
0060デフォルトの名無しさん2010/04/14(水) 02:50:49
Lispは基本部分だけならそれほどでも無いような
ただ、Lispでメモリ管理のコード自体を書くとなるとキツいと思う
0061デフォルトの名無しさん2010/04/14(水) 06:30:02
LispがマイナーなのはS式の表現力不足が問題です。

S式でC言語を書いたからといって、Lispのように実行する必要はなくて
コンパイルすればいいですよね。トランスレータでもいいし。

１．GC付き言語でS式ならぬC言語風の式言語を作る。
２．GC付き言語でC言語風式言語でLispっぽいマクロ言語を作る。
２．GC付き言語でそのC式を使ってアセンブラを作る。
　　これで、Lisp級マクロ付きのマクロアセンブラが出来上がる。
３．マクロアセンブラのマクロを拡張してC言語風言語を作る
４．その言語でC式で動くLisp風言語を作る。ここでメモリ管理の問題が出てくる。
５．最適化フェーズを追加する。

という感じでやればいい言語が出来上がると思います。
0062デフォルトの名無しさん2010/04/14(水) 06:53:14
オレは１じゃないけど、作るのに協力できるなら協力します。
著作権については修正free bsdライセンスのような、商用にも使える自由なやつがいいなぁ

新しい低レベル言語は言語仕様が小さい言語と大きい言語の２つを作るといいと思う。

自分はScheme的小さい言語仕様の言語を目指して作ってるけど、
最適化フェーズまでは頭が回らない。。。

とりあえず、式言語ベースでアセンブラを作らないとなぁってところです。

c++のjit用のアセンブラXbyakとかscheme製アセンブラとか、as3のアセンブラとか、llvmとかいろいろある
のを参考にそのうち作ります。
美しく作りたいので速くて２、３年かかると思います。

大きい仕様の言語はD言語からGCとかclassをはずした言語がいいんだろうなと。
大きい仕様の言語でも式言語としてパースできたらいいけど、それは無理なのかな？
0063デフォルトの名無しさん2010/04/14(水) 07:29:56
それは作りたいから作るの？
実用したいから作るの？
0064デフォルトの名無しさん2010/04/14(水) 11:31:12
>>41
色々誤解させてすまない。Wiki管理者と全スレの>>1は別人です。色々他のことやっているからあまり関われないのは事実です。権限とか名声とか興味ないです。
名前をプリン並みの強度で決定したのとWiki空っぽにしたのは翌朝以降に整備予定であったのと、何も決まっていないということの現状認識。
名声とかより仕様がまとまらず無駄に時間が流れていくのもどうかなと思ったから立てた。

>>44
悔しいのか怒りなのか思い込み激しすぎて理解できませんがEDではないでしょう？嫌でしたらご自分で勃起しては？
今回は罵倒するのは不当で正当な別途Wiki立てるのが拒否手段ですよ。用意されたツールを使うかどうかは周囲が選ぶべきです。
0065デフォルトの名無しさん2010/04/14(水) 16:16:13
C/C++に代わる低級ガラパゴス言語 Jap-C を作ろう。
0066デフォルトの名無しさん2010/04/14(水) 16:22:07
低脳の間違いだろ
0067デフォルトの名無しさん2010/04/14(水) 19:22:49
>>64
考え方が全然なってないわ
今すぐ身を引いたほうが良いぞ
0068デフォルトの名無しさん2010/04/14(水) 19:38:20
>>62
3段構成
(1)Core Spec.
(2)Sweeter Spec.
(3)Standard Lib.
0069デフォルトの名無しさん2010/04/14(水) 21:06:59
IDEによる支援がし易い文法にしたいね。
0070デフォルトの名無しさん2010/04/14(水) 21:28:10
Cの中であまり使われない機能に順位を付けて
上から順に削除していってスリムなCを見てみたい
ビットフィールドとか使わないよね？
0071デフォルトの名無しさん2010/04/14(水) 21:29:20
機能を削るだけなら使わなきゃいいんじゃないの？
あまり意味がない気がするんだけど
0072デフォルトの名無しさん2010/04/14(水) 21:31:01
EmbededCｗｗｗｗｗｗｗｗ
ﾃﾗﾊﾟｺﾞｽｗｗｗｗｗｗｗ
0073デフォルトの名無しさん2010/04/14(水) 21:31:21
>>70
おまえが使わないだけだヴォケ
0074デフォルトの名無しさん2010/04/14(水) 21:31:23
そうやってぶくぶく太っていくんだと思うんだな言語は
仕様書とかすっきりするじゃん
コンパイラも小さくなるし
0075デフォルトの名無しさん2010/04/14(水) 21:32:48
コンパイラが小さいｗｗｗｗｗ
0076デフォルトの名無しさん2010/04/14(水) 21:35:14
Cのどこが太ってるんだ
256kバイトの8086でもコンパイル出来たんだぞ
0077デフォルトの名無しさん2010/04/14(水) 21:38:33
よく読んでよ
太っていくって言ったのに
ここは低級言語を開発するスレじゃないの？
あれもこれもやってたらC++みたいになるのがオチなのに何故それが分からないのか？
0078デフォルトの名無しさん2010/04/14(水) 21:40:37
機能を追加するのなんでいつでもいくらでも出来る
よく使われる機能を選別して残すのが進化なんだ
0079デフォルトの名無しさん2010/04/14(水) 21:42:50
あれもこれもなんて誰も言ってねーよ
ビットフィールドを削るのは見当違いだって言ってんだ
0080デフォルトの名無しさん2010/04/14(水) 21:45:12
◆新言語の要件◆

（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的
（３）学習が容易なように程々の大きさの言語仕様
（４）最新のオサレ機能が使えてワクワクしながらプログラミング可能
0081デフォルトの名無しさん2010/04/14(水) 21:45:31
Objective-ASM
0082デフォルトの名無しさん2010/04/14(水) 21:45:47
そうかすまんね
だからその辺の統計をとって使われてない方から削除したのを見たいっていってるんだよ
もしビットフィールドを使ってる人が本当に少数派なら仕方がないということで
0083デフォルトの名無しさん2010/04/14(水) 21:46:46
見たいのは別にいいけど、スレ違い。
0084デフォルトの名無しさん2010/04/14(水) 21:52:26
統計をとるってのは多数決ってことだろ、ご冗談をｗ
多数決なんかとって歯抜けになったcなんぞ誰が使うんだよｗ
0085デフォルトの名無しさん2010/04/14(水) 21:54:12
>>80
３と４は矛盾してる
0086デフォルトの名無しさん2010/04/14(水) 21:54:54
>>85
どう矛盾しているのか、具体的に。
0087デフォルトの名無しさん2010/04/14(水) 21:56:29
>>80
めちゃくちゃだな。

(1)の時点で技術に比較的明るい人が使うんだろう。
(3)の必要性が不明。てかC知ってる人が新言語覚える時点で負担だろ。
(4)を導入すると(2)や(3)に反する。

何がしたいのか全然分からんね。
0088デフォルトの名無しさん2010/04/14(水) 21:57:25
草生やしてる人がうざい

>>86
（３）学習が容易
（４）最新のオサレ機能
この辺じゃないの
0089デフォルトの名無しさん2010/04/14(水) 22:02:42
要するに「Cよくわかりません。難しいです。でも速い言語使いたいです。」っていう
ガキにありがちなわがまま要求だろ。
0090デフォルトの名無しさん2010/04/14(水) 22:02:59
>>87
> (1)の時点で技術に比較的明るい人が使うんだろう。

そうでもないよ。
組み込み屋なんてピンきりだよ。とんでもないのがいる。
0091デフォルトの名無しさん2010/04/14(水) 22:05:42
その「とんでもないの」を場当たり的な新言語で
どうこうしようたってねえ…
0092デフォルトの名無しさん2010/04/14(水) 22:06:43
◆新言語の要件 v0.1◆

（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
0093デフォルトの名無しさん2010/04/14(水) 22:06:45
とんでもないのなんてどこにでもいるしな
そんな例外持ち出されても
0094デフォルトの名無しさん2010/04/14(水) 22:07:48
asとldは使われていないから削除ですね
統計的にわかります
0095デフォルトの名無しさん2010/04/14(水) 22:08:42
>>92
ハードウェアを操作するっていうのはメモリマップされたI/Oをじかに叩くとかだろ。
それって生ポインタだろ。
生ポインタは「学習が容易」ではないし「最新のオサレ機能」でもない。
0096デフォルトの名無しさん2010/04/14(水) 22:09:50
>>90
そんな「とんでもないやつ」にハード相手にプログラミングさせる必要ないだろ。
0097デフォルトの名無しさん2010/04/14(水) 22:10:56
＞（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能

具体的に何よ？
0098デフォルトの名無しさん2010/04/14(水) 22:12:50
ラムダ、モナド、タプル、クロージャー、マクロ
0099デフォルトの名無しさん2010/04/14(水) 22:14:37
Cの配列にはオーバーヘッドはないし
structも詰め物以外のオーバーヘッドはない
そういうベタ構造も、勿論必要だろうが、
超高級unionとしての代数的データ型とか
そういうのもあると、便利なような気がする

勿論オーバーヘッドの量（ワード一個とか）やメモリレイアウトが
分かりやすく、把握可能であるという前提で
google goのinterfaceはダックタイピング／structural subtyping風味で
好みなのだが、あれのオーバーヘッドはどれぐらいなのだろう
0100デフォルトの名無しさん2010/04/14(水) 22:15:19
ダックタイピングいいな
0101デフォルトの名無しさん2010/04/14(水) 22:18:37
動的結合なしでダックタイピングって意味ある？

意味あれば欲しいかも。
0102デフォルトの名無しさん2010/04/14(水) 22:19:19
そういうの高速化からどんどん遠ざかってるから
0103デフォルトの名無しさん2010/04/14(水) 22:19:58
>>80
低レベルって何処までなんだろうと考えていて
思わずrfc1149を思い浮かべてしまった…orz
でも、普通、低レベルって言ったら、それこそ機種依存になるけど、
ここで言われている低レベルって、何を指して低レベルって言ってるの？
0104デフォルトの名無しさん2010/04/14(水) 22:22:27
低レベル＝ハードウェアを直接操作する記述ができる
0105デフォルトの名無しさん2010/04/14(水) 22:25:12
>>102
抽象化したいときには抽象化できて
ベタで書けば高速にもできるってことならいいと思うんだが

goのinterfaceってのはクラス指向OOへのアンチテーゼだが
別にC++同様OOなんて使う必要ないし
VM系の、管理されたサンドボックスで走らせるために毎度毎度
境界チェックとかやるような仕様でなければ、特に問題ないんじゃないの
0106デフォルトの名無しさん2010/04/14(水) 22:25:37
ハードウエアを直接操作というと、IOや割り込みの管理などをイメージする。そんなことはCにもできない。
0107デフォルトの名無しさん2010/04/14(水) 22:26:04
>>104
ハードウェアを直接操作って言っても千差万別だけど、何処までなの？
>>95が言ってるように、メモリマップ程度に抑えるとか、
機種毎に拡張しやすいように、何でもできるインターフェイスを備えるとか…
0108デフォルトの名無しさん2010/04/14(水) 22:27:33
Cで直接操作できるのはメモリだけだよな

レジスタだのスタックフレームだのを弄ったりCPUを直接叩きたければ
アセンブリしかない
0109デフォルトの名無しさん2010/04/14(水) 22:28:54
インラインアセンブラがあるだろ
0110デフォルトの名無しさん2010/04/14(水) 22:28:58
インラインASMとかあるでしょ
0111デフォルトの名無しさん2010/04/14(水) 22:29:50
>>109
それは正確には「C」じゃないから
0112デフォルトの名無しさん2010/04/14(水) 22:31:13
>>105
＞抽象化したいときには抽象化できて
＞ベタで書けば高速にもできるってことならいいと思うんだが

そういう何でもアリな言語がいいのか、
スリムな言語いいのかどっち？
0113デフォルトの名無しさん2010/04/14(水) 22:31:38
>>109-110
インラインなんて使ったら、それこそ、アセンブラを使えば良いので、
単純にアセンブラとリンクできる仕様を決めておけば良いだけのような…
0114デフォルトの名無しさん2010/04/14(水) 22:32:30
スレタイがCとC++を同列に扱っているところに、話がまとまらない原因がある。
0115デフォルトの名無しさん2010/04/14(水) 22:32:38
>>111
一応規格にもasmという予約語はあるし（意味は処理系定義だが）
そもそもインラインアセンブラが書ける言語なんてどんだけあるんだよ
既にCの特徴と言ってもいいわ
0116デフォルトの名無しさん2010/04/14(水) 22:33:38
無名関数
0117デフォルトの名無しさん2010/04/14(水) 22:39:47
Cのpragmaで処理されているところは、C#の属性のような構文の方がスッキリする。
0118デフォルトの名無しさん2010/04/14(水) 22:41:04
implementation-defined
言語仕様を小さくする魔法の言葉
0119デフォルトの名無しさん2010/04/14(水) 22:43:05
関数リテラル、関数内関数ぐらいは問題なさげ
クロージャは、無限エクステントなしでよければ問題なさげ
それでもforeachみたいなのに渡す分には困らない
値として返せないけど
0120デフォルトの名無しさん2010/04/14(水) 22:44:28
>>112
Cの何に不満を持ってるかによるんじゃないの
C++に不満を持ってる人ならいっぱいいるだろうけどなｗ
0121デフォルトの名無しさん2010/04/14(水) 22:45:45
>>107
> ハードウェアを直接操作って言っても千差万別だけど、何処までなの？

他言語を例に上げたくはないけどあえて言うなら、

新言語は、
「汎用的に使える言語であって、特に『現在Cが利用されていて、Javaが使用されていない分野』に利用出来ること特徴とする言語」
かな。

> >>95が言ってるように、メモリマップ程度に抑えるとか、
> 機種毎に拡張しやすいように、何でもできるインターフェイスを備えるとか…

メモリマップ程度に抑えても、上記特徴を達成出来るならそれでもいいけど、たぶんダメだよね。
0122デフォルトの名無しさん2010/04/14(水) 22:46:23
Cが低級ってのが、なんで、って感じ
0123デフォルトの名無しさん2010/04/14(水) 22:48:07
スレ読め
0124デフォルトの名無しさん2010/04/14(水) 22:49:59
Cでなければならないのは、OSと要件が厳しい組み込みぐらいではないか？
0125デフォルトの名無しさん2010/04/14(水) 22:50:23
低級なら、アセンブラでしょ
0126デフォルトの名無しさん2010/04/14(水) 22:52:43
>>125
そんな誰でも知っていることは不要。
0127デフォルトの名無しさん2010/04/14(水) 22:56:25
アセンブラ以上、C未満って、そんな難しいことを思いつく人がいるんかね
0128デフォルトの名無しさん2010/04/14(水) 23:00:11
C未満ってどこから出てきた条件？
0129デフォルトの名無しさん2010/04/14(水) 23:01:57
インラインアセンブラを使いたいだけなら、
特別なポインタを用意してやって、そこにマシン語を書き込んで、
コール出来るようにしてやれば良いと思う。
って言うか違うな…
アセンブラ関数が作れれば良いんじゃないか…？
で、引数と戻り値のルールや、変数等のポインタを共通化してやれば使いやすくなる？
0130デフォルトの名無しさん2010/04/14(水) 23:02:15
低級だからじゃね
0131デフォルトの名無しさん2010/04/14(水) 23:05:51
javaみたいに、仮想CPUとかの設計からやった方がいいんじゃないの
0132デフォルトの名無しさん2010/04/14(水) 23:05:52
>>121
あえて言うなら、現在のCは汎用的に使えないことが問題だと言いたいのか。

Cは、アセンブラでしかできないことは素直にアセンブラで書け、
より高級な言語が必要ならそれを使えという方針だな。

あえて言うなら、そういう所が気に入らないのか？
0133デフォルトの名無しさん2010/04/14(水) 23:09:55
>>132
> あえて言うなら、現在のCは汎用的に使えないことが問題だと言いたいのか。

そんなことは全く言っていないよ。
Cは汎用的に使える。

言いたいのは、新言語は低レベル記述を出来ようにしたいけど、
低レベルにだけ使えればいいわけではなく、汎用的にも使えるようにしたいと言うこと。
0134デフォルトの名無しさん2010/04/14(水) 23:11:04
>>131
低級と逆方向に進んでないか？
0135デフォルトの名無しさん2010/04/14(水) 23:12:14
汎用的なもんって、難しいよ。専用なら雛形作るのは早いかもしれないけど
0136デフォルトの名無しさん2010/04/14(水) 23:13:36
Cの問題点のひとつとしてマクロ。解読困難なものや、型チェックが働かないものがあったりする。
それなら、Cでよく使われているマクロを研究したら、より安全なCができるんじゃないか？
0137デフォルトの名無しさん2010/04/14(水) 23:13:42
低級用途には全く関心がないのに、新しい言語を作りたいだけの人間が紛れ込んでるな
0138デフォルトの名無しさん2010/04/14(水) 23:17:23
Cをよく理解していないのに新言語を作ろうとしてる奴も混ざってるしな
0139デフォルトの名無しさん2010/04/14(水) 23:18:28
結論はDが完成すればもういいや、か
完成しそうにない点が問題だが
0140デフォルトの名無しさん2010/04/14(水) 23:18:46
「奴」とか「人間」とかばっかり言ってるの連中よりはいいけどな
0141デフォルトの名無しさん2010/04/14(水) 23:24:58
>>139
GCありの言語は用途が違いすぎじゃないの
0142デフォルトの名無しさん2010/04/14(水) 23:27:43
標準ライブラリに参照カウンタでのメモリ管理入れておいて
0143デフォルトの名無しさん2010/04/14(水) 23:30:23
goto廃止
0144デフォルトの名無しさん2010/04/14(水) 23:30:41
低レベルって言っても、高速化を目的とした低レベル(レジスタやメモリを触りたい)と
汎用性を主眼においた低レベル(特殊な入出力等)って、方向性が違うから難しいよな…
01451442010/04/14(水) 23:32:23
何か、最終的に求めるものが違うから、Cより高レベルなものを求めたり
Cより低レベルなものを求めたりの意見の相違があるような気がする…
0146デフォルトの名無しさん2010/04/14(水) 23:36:27
Cより高レベルかつ低レベル。目指してるのはそこにある
インラインアセンブラを使うこともなければ、機能の少なさを嘆くこともない
0147デフォルトの名無しさん2010/04/14(水) 23:36:53
誰かが言った
ポリシーが違うならメカニズムを提供すればいいじゃない
0148デフォルトの名無しさん2010/04/14(水) 23:37:16
高速化を目的としなくても、単にレジスタやメモリを触りたいだけでも「低レベル」が必要になる
0149デフォルトの名無しさん2010/04/14(水) 23:38:53
Z80に対応出来るようにしてください
0150デフォルトの名無しさん2010/04/14(水) 23:39:31
Cで充分だと何度言えば
0151デフォルトの名無しさん2010/04/14(水) 23:45:36
>>145
Cのレベルと言っても、何か唯一のレベルがあるわけではなく、比較的高レベルから低レベルまで広がりを持っている。
Cに代わる言語だから、少なくとも現在Cがカバーしている分野はカバーするよ。

Cよりは便利にしたいから、高レベルの方はCよりも高レベルになるだろうね。
低レベルの方はCと同じ程度でいいんじゃないかな。
0152デフォルトの名無しさん2010/04/14(水) 23:46:24
low levelということは具体的だという事。抽象化の時代の流れを逆行している
0153デフォルトの名無しさん2010/04/14(水) 23:49:03
>>148
単にレジスタやメモリを触りたいだけって、
高速化や特殊処理以外で、レジスタやメモリを直接触ることって何がある？
CPU自体のデバッグとか、趣味で触ってみたいだけ位しか思いつかないが…
0154デフォルトの名無しさん2010/04/14(水) 23:50:26
>>153
デバイスドライバー
0155デフォルトの名無しさん2010/04/14(水) 23:52:55
>>154
それは、C++でもいける。
0156デフォルトの名無しさん2010/04/14(水) 23:52:55
馬鹿が言語を作ろうとすると
Embedded C++みたいなのが出来る
0157デフォルトの名無しさん2010/04/14(水) 23:52:59
Cは十分抽象的でしょ。
欠点を上げて修正するくらいでいいと思う。
0158デフォルトの名無しさん2010/04/14(水) 23:54:14
Embedded C++のどこが問題かはかなり難しい問題。
正直Embedded C++のほうが安全にプロジェクト進められることも多い。
0159デフォルトの名無しさん2010/04/14(水) 23:54:36
>>157
どうぞ好きに修正してください。さようなら。
0160デフォルトの名無しさん2010/04/14(水) 23:55:11
レベルひくっ
0161デフォルトの名無しさん2010/04/14(水) 23:55:34
それがいい。
0162デフォルトの名無しさん2010/04/15(木) 00:01:17
>>154
あんまり新しい言語の必要性が見えない
本当に高速化が必要な高速デバイスは、インラインアセンブラや
アセンブラで書くことになるし、低速デバイスであれは、
必要な部分だけ、C、C++で作って、残りは、デバイスにあった処理系を使うな…
0163デフォルトの名無しさん2010/04/15(木) 00:02:06
>>155
そうだけど、だから何なの？
0164デフォルトの名無しさん2010/04/15(木) 00:03:40
>>162
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
0165デフォルトの名無しさん2010/04/15(木) 00:04:57
>>89
その要求を満たしたD
0166デフォルトの名無しさん2010/04/15(木) 00:06:19
Ｃの利点問題点も共有できないのかよｗ
0167デフォルトの名無しさん2010/04/15(木) 00:06:30
>>153
あんたの言う「特殊処理」って奴が、まさに>>148の言う「高速化目的」以外の
ケースに該当すると思うんだが

誰でも思いつくような低水準な例以外のことで言うと、
例えばCのサブルーチン形式以外のもの（コルーチンや継続など）が欲しければ、
スタックや何かを操作する必要があるだろう
そしてそうしたことは、C言語仕様の範囲ではサポートされていない
0168デフォルトの名無しさん2010/04/15(木) 00:10:55
>>162
必要に迫られて言語を選ぶのでは遅い
何が必要か判明するより前に予め将来に備えてお勉強するのが現代人のライフスタイル
0169デフォルトの名無しさん2010/04/15(木) 00:11:00
でもライブラリで提供すればいい話じゃないか？
0170デフォルトの名無しさん2010/04/15(木) 00:16:42
>>167
だから、高速化と、それ以外の特殊しょりで、このスレで議論している
新しい言語の仕様が全然変わるんじゃねーのって話

ただ単にインラインアセンブラを呼ぶだけでも、
高速化が目的であれば、必要なレジスタの退避とかは、
全てアセンブラ側で持ちたいと思うし、呼び出し側の新しい言語も、
あんまり凝った、仕様はいらないって話になる

反対に、それ以外の目的では、オーバーヘッドはあまり気にしないから、
インラインアセンブラで記述するコードが極力減るように、
呼び出し側の言語で、ある程度制御して欲しいと思うし、
呼び出し側の言語の仕様も、C++よりも凝ったものになるんじゃないかってこと
0171デフォルトの名無しさん2010/04/15(木) 00:16:59
Cは実行時のコード生成／自己書き換えなんかも出来ない
アセンブリに比べて（少なくとも純粋な）Cの仕様では出来ないことってのは
結構多い
0172デフォルトの名無しさん2010/04/15(木) 00:18:52
それこそいらね
0173デフォルトの名無しさん2010/04/15(木) 00:19:24
>>170
アセンブラ呼ぶようなクリティカルで低水準な部分でオーバーヘッドを
許容してもいい派はあんまりいないんじゃないか、さすがに

パフォーマンスにおいてクリティカルでない部分で抽象度の高いコードを
書きたい、かどうかは意見の分かれるところだろう
0174デフォルトの名無しさん2010/04/15(木) 00:21:57
有名な例だけど、ATLではウィンドウインスタンスとC++のクラスインスタンスを
紐付けるサンクのコードにアセンブラを使っている

これの目的はまあ広い意味では高速化、狭い意味では、C++では実行時に
サンクコードを生成できないから
0175デフォルトの名無しさん2010/04/15(木) 00:24:21
まあ、Ｃに代わる言語が作れるなら、既にできてるけどね。存在しないのは不要だからだよ。
「こういう理由で不要だから作りません」なんて論文や製品にならないから出てこないけど

なぜ不要かという答えに議論を通じてたどり着ければ得るものはあるんじゃないかな。
0176デフォルトの名無しさん2010/04/15(木) 00:27:55
>>173
>>148の 単にレジスタやメモリを触りたいだけ
って話に対して、オーバーヘッドを気にするのかって話
0177デフォルトの名無しさん2010/04/15(木) 00:31:19
おい、１スレ目から何も話題が変わってないじゃないか
どういうことだ？
0178デフォルトの名無しさん2010/04/15(木) 00:34:52
おまえ２ちゃんになに期待してるんだｗ
0179デフォルトの名無しさん2010/04/15(木) 00:39:57
俺がベースを作ったら、後はお前らでなんとか出来るか？
0180デフォルトの名無しさん2010/04/15(木) 00:41:07
言語仕様のベース？
なんとか出来るかは、内容による。
0181デフォルトの名無しさん2010/04/15(木) 00:48:46
どこに作るの？名護？徳之島？
0182デフォルトの名無しさん2010/04/15(木) 00:49:01
>>180
コンパイラの基本部分のソースだよ
0183デフォルトの名無しさん2010/04/15(木) 00:50:09
仕様はお前らが考えて、
俺が動くものを作ってやるから、
後は好きに最適化すればいいよ。
0184デフォルトの名無しさん2010/04/15(木) 00:51:38
>>183
じゃあ、よろしく。
0185デフォルトの名無しさん2010/04/15(木) 00:52:16
日本人はものづくりがほんとにヘタだな
0186デフォルトの名無しさん2010/04/15(木) 00:52:21
ここは開発するスレじゃなくて
開発したいスレだからな
0187デフォルトの名無しさん2010/04/15(木) 00:54:57
>>185
これだけ理系が冷遇されていれば仕方がない。
0188デフォルトの名無しさん2010/04/15(木) 00:55:52
こんなだから金出せないんだろｗ
0189デフォルトの名無しさん2010/04/15(木) 00:56:56
そうだね。
0190デフォルトの名無しさん2010/04/15(木) 01:02:17
Galapagosly-C
0191子供1 ◆8EgSMaDgzc 2010/04/15(木) 01:06:03
誰か仕様まとめてくれ
0192デフォルトの名無しさん2010/04/15(木) 01:28:30
continuationとかaspectとかDbC/PbC希望！
0193デフォルトの名無しさん2010/04/15(木) 02:03:56
ちょい長文だが、
組み込みにインラインアセンブラや特殊機能は結構必要
OSや言語のラインタイム作る時にも結構便利
その他のgcc拡張なんかも有用

俺はインラインアセンブラは高速化も含むのだが
ほんの数行ですむがアセンブラ必須の特殊命令のために使うことが多い

例えば割禁なんかのようなCPU固有の特殊レジスタアクセスとか
キャッシュやバッファをスルーしてくれる入出命令とか
アトミックなメモリ操作とかだね
メモリマップドI/OったってCPUによってはvolatileつけたくらいじゃ
書き込み保証できないし

もちろんアセンブラで書いてもいいんだが
gccのようにレジスタを変数に割り付けてインラインで書けたりすると
コードも短いしオーバヘッドもなくなる
場合によっちゃスタックチェックなんかも書ける

同じくgcc固有だがattributeで高速SRAMとSDRAMを使い分けたり
セクションを分けたり、通信用にpackした構造体を用意したりな
linuxでもマクロで隠してあるが、
ドライバやモジュールの初期化処理を別セクションに分けてたりする

もちろん言語仕様的には超'例外’的な機能だが組み込み屋的には
あるとないとでは大違いな機能だったりする
つわけで、どこでどんな風に低レベル機能が必要とされてるかも考えてみてほしいね
OSの上で動くアプリとホントの低レベルでは要求がだいぶ違うんよ
0194デフォルトの名無しさん2010/04/15(木) 02:07:28
Cは長い間使われて鍛えられてるからなぁ。
でもC++はちょっと違うんだよな。なんでだろ。
0195デフォルトの名無しさん2010/04/15(木) 02:16:32
C++はランタイムが少し大きいのと
予期せぬところで見えない初期化や後処理が走るからだろうね
メモリ管理も抜け穴が出来やすいし

ベタなコード書きたいところではイマイチな感じ
もちろんそういうとこ抜けた後のアプリ部分では
ちゃんと使えば問題ないと思うけど
0196デフォルトの名無しさん2010/04/15(木) 02:21:08
無駄なところで嫌がらせのような多重継承したり
不要なところでテンプレート乱用したり
0197デフォルトの名無しさん2010/04/15(木) 02:34:06
Cの鬼マクロも昔はアレだったけど
C++はさらに輪をかけてるからな
書いた奴のレベルを自動判定して機能制限してくれるC++がほしいな
0198デフォルトの名無しさん2010/04/15(木) 02:37:01
そんな謎機能はいらないからｗ
詳細に機能をオフに出来るコンパイルオプションが欲しい
0199デフォルトの名無しさん2010/04/15(木) 03:15:11
>>198
インテリジェントじゃねえか
動的に文法をリミットだｗ
あんたはVBくらいねとかphp程度ねｗとか
0200デフォルトの名無しさん2010/04/15(木) 04:57:00
お前らが語ってることって40年前の黎明期より劣ってるんだけど自覚ある？
0201デフォルトの名無しさん2010/04/15(木) 05:25:54
最終的にどんなバイナリを吐くか？はコンパイラの仕事である。
言語仕様と実働環境の違いは完全に分離して考えなければならない。

例えば、言語としてはマルチコアをネイティブサポートしておいて、コンパイラが各ターゲット環境に合わせればよい。
ソースがマルチコアを使うように書かれていても、ターゲットがシングルコアならそれ用のバイナリを吐くだけ。
ペアになっているのはコンパイラと実働環境であり、言語仕様は切り離されているべきである。

いや、どうも言語仕様と実装を分けて考えられない御仁が多いみたいなんでね。
0202デフォルトの名無しさん2010/04/15(木) 05:49:54
すべからく設計にはトップダウン、ボトムアップ両方の側面がある
ボトムアップが100%いいとは言わないが、
特にCの領域をカバーしたいような低レベルな言語設計をするのに
実装を十分考慮せずに言語を設計しても実用性は？だと思うがね。
0203デフォルトの名無しさん2010/04/15(木) 05:55:25
>>202
実装に寄った言語をアセンブリ言語というんだよ。可搬性、抽象化なくして何のための言語か？
0204デフォルトの名無しさん2010/04/15(木) 06:27:33
基本的な考えとして、Cと比較してそれを載せると無条件で1以下になるようなものは却下だろ
GCだったり動的な型付けだったり、実行時に常に影響があるようなものはNGだ
コンパイル後は可能な限りstaticに固定的にコンパクトに、という方向は見失わないようにしないとな
シンタックスシュガーや環境依存が存在しないくらいにしっかりと記号や文字を使い分ける

一方で「用意するけど使わなくてもいい」に当てはまるものは問題ないだろう
文字列型や可変長型は今や必須と言っていいし、特定分野で使われるような高度な算術ライブラリとかも

てな感じで、1以下にならないものを選別していけばいいんじゃないだろうか？
0205デフォルトの名無しさん2010/04/15(木) 07:11:14
>>141
使わなければいい
そもそも OS 作成用途では malloc すら自作しないと使えないんじゃ
0206デフォルトの名無しさん2010/04/15(木) 07:28:52
>>205
mallocは言語関係ない。それを言うなら、new だ。
0207デフォルトの名無しさん2010/04/15(木) 07:41:58
それがGCだろ・・・？
0208デフォルトの名無しさん2010/04/15(木) 07:51:50
C++は、ほかの言語への置き換えがかなり進んできているけど、Cはそれに対抗するものはまだない。
0209デフォルトの名無しさん2010/04/15(木) 08:51:27
必要あくまで排除するのかということ
0210デフォルトの名無しさん2010/04/15(木) 09:00:47
>>203
0 or 1ですね。わかります
極端すぎるんだよ

環境依存したべたべたに書かれたハードウェア制御部分だって
Cとアセンブラでは開発効率が天と地ほど違うし
ちゃんと書けば性能も保ったまま可搬性をある程度は持たすことが出来る
まあ性能を求めれば求めるほど失われるがね
低レベルってのはそういう分野も含んだもんだと思ってるんだがな
そもそも抽象度は上げれば上げるほど動的な機能とメモリ管理が不可欠になる

>>204
みたいにGCなしといいつつ文字列型が欲しいとか相反する部分がどうしても出てくるし。
高速演算ライブラリなんてCとかアセンブラで用意して呼べばいいだけだし
普通にアプリを作りたいだけなら低級言語はいらんのじゃないか
0211デフォルトの名無しさん2010/04/15(木) 09:19:47
おまいらなんで、言語の実装とランタイムライブラリを一緒くたにしてんの？
0212デフォルトの名無しさん2010/04/15(木) 09:32:19
>>210
まず今のCの仕様で、特定の環境でしか動かないような仕様が存在するか？一つも無いだろ。
今のCですら、アセンブリ言語と比較して抽象化は高いレベルで実現されている。
実働環境と言語仕様は切り離されてなければ意味が無いんだよ。
でなきゃアセンブリ使えで済む話なんだから。共通ルールを作るとはそういうことだ。
もう一度言うが、環境に依存する機械語への翻訳はコンパイラの仕事。
0213デフォルトの名無しさん2010/04/15(木) 09:47:17
つーか、実装を考慮した言語設計って具体的にどんなの？って話だよ。
ある特定の機械に向けた実装をするなら、それは汎用言語ではなくなってしまうよ？
リソースのプアな機械があるからといって言語仕様に可変長型を入れてはいけない、ということにはならない。
取捨選択できる機能であり、かつ、使用する場合にメリットがデメリットを大きく上回るなら採用すべきだ。
0214デフォルトの名無しさん2010/04/15(木) 09:53:13
とりあえずOOP、GC、動的型付けは却下だな
コードサイズもメモリサイズもオーバーヘッドも常に肥大化するし
0215デフォルトの名無しさん2010/04/15(木) 09:53:13
>>164
それ、最初のスレで一人だけが執拗に繰り返してて、たぶん２スレ目はそいつが勝手に建てただけ。
他には誰もそんなこと言ってないっての。
0216デフォルトの名無しさん2010/04/15(木) 10:14:00
並列処理も却下
0217デフォルトの名無しさん2010/04/15(木) 10:17:05
SJISは良くない、って言って、SJISに似て非なるEUCを作った話から少しは学べよ。
UTF-8みたいにきちんと作らないと邪魔になるだけだって。
0218デフォルトの名無しさん2010/04/15(木) 10:17:06
プリプロセスは綺麗に出来るように。
それからコンパイラやリンカオプションはソースコード上でスイッチできるように。
0219デフォルトの名無しさん2010/04/15(木) 10:30:39
また長文だがｗ
>>212
Cの言語仕様の改訂はたいてい
低オーバヘッドで実現できて組み込みやらの移植性を上げるような方向だからな
でも既存言語という縛りがあるから、どうしても踏み込めてない部分も結構ある
volatileが導入される前は特定のソースだけオプティマイズ外したり
仕方なくアセンブラなんて普通にあったし

マシンコードだけが依存性の源でもないし
普通に書いても問題が出るような部分とか
生成されるコードを意識しないと書けない範疇
どうしても書く内容で移植性を下げるもの
エンディアンなんてつまらんものもそうだし
ま、そういう用途でも
新しいCに代わる低級言語ならアセンブラや環境依存の書き方以外の方法で
記述出来る能力か抜け道がないのか、より抽象度を上げた方法がないかどうか？

実際に使われる環境や対象を考えてない実用言語なんてほとんどないし
たいてい何らかの目的とユースケースを見据えて作られてる
もちろん汎用性があるから普及すればいろんな用途で使われるし
使われ出して長くなると立ち位置も変わるが
なかなかCを食う言語は出てこない

俺は趣味的な思考実験ちっくにこのスレ読んでるが
ちょっとそういう部分もあるんだなって考えてみてくれる人や
言語や見識がある人がいないかと思って書き込んだ
美しく抽象度の高い言語なら既にいっぱいあるっしょ
0220デフォルトの名無しさん2010/04/15(木) 10:30:45
＞プリプロセスは綺麗に出来るように
うわ言はチラシの裏にお願いします
0221デフォルトの名無しさん2010/04/15(木) 10:35:31
Cに対して明らかな優位性があって、
.o にバイナリコンパチブルがあるなら置き換わる可能性はある。
0222デフォルトの名無しさん2010/04/15(木) 10:38:30
そりゃ当たり前だ
0223デフォルトの名無しさん2010/04/15(木) 10:42:13
圧倒的な普及率を覆すほどの優位性なんて、そう出てくるもんじゃないけどな

現状の大抵のOSではシステムコールやAPIがCヘッダで提供されてるから
それがそのままincludeできないなら、それもCに対して（現状では）
利便性において劣る部分となる

一方、includeできるなら、プリプロセッサという化石とCの汚い言語仕様
をそのまま受け入れるということで、C++みたいな糞の山が出来上がるのがオチだ
0224デフォルトの名無しさん2010/04/15(木) 10:48:40
includeつーよりラッパーのライブラリとABIな
ヘッダだけなら機械的に他の言語に変換できるし。
C++は汚いが、Cはそこまで汚いとは思わん
0225デフォルトの名無しさん2010/04/15(木) 10:48:43
>>223
あんたもわかってるのかどうか怪しいなｗ
システムコールが仮にC形式で呼ばれるようになってたとしても、
Cヘッダ使わなくても呼び出しできるぞ。
C形式ってのは要するに、呼び出しアドレスがわかっていて、引数の形と数がわかっていて、
引数をスタック渡しで呼び出すシステムがあればそれでいい。
別にプリプロセッサとかヘッダとかをCと同じにする必要なんてない。
0226デフォルトの名無しさん2010/04/15(木) 10:53:46
>>225
んなことは分かっとるわ、アホか
LispやLLみたいな言語ですらffi経由でCのコードを呼べる

宣言を取り込み、呼べるようにするための手間が、
#include ほげ
と書くだけより「手間」なんだよ
それが「利便性において劣る」ってこと
0227デフォルトの名無しさん2010/04/15(木) 10:55:10
>>225
そもそも最近はレジスタ渡し＋スタックだな

さ、ちょいだけ仮眠して仕事するべさ
0228デフォルトの名無しさん2010/04/15(木) 10:57:38
>>226
いちいち罵倒しないと会話もできないのかよ。。。
0229デフォルトの名無しさん2010/04/15(木) 10:58:09
>>221
Dが流行らなかった原因ってそれ？
0230デフォルトの名無しさん2010/04/15(木) 10:58:10
そういや昔は引数もPascal方式とかC方式とかあったな
0231デフォルトの名無しさん2010/04/15(木) 10:59:16
最近のシステムコールには呼び出しアドレスがあるのか
0232デフォルトの名無しさん2010/04/15(木) 10:59:53
>>229
Dなんてlisp以上に純マイナーだからじゃないかｗ
GoogleかAppleかMicrosoftが採用したら一気に有名になるぞｗ
0233デフォルトの名無しさん2010/04/15(木) 11:01:01
>>230
今でもあるよ
0234デフォルトの名無しさん2010/04/15(木) 11:05:51
>>231
＞システムコールが仮にC形式で呼ばれるようになってたとしても〜
＞プリプロセッサとかヘッダとかをCと同じにする必要なんてない
という「概念」の話を、「実装」の話にすり替えないように。
0235デフォルトの名無しさん2010/04/15(木) 11:14:03
昔はシステムコールにアドレスがなかったのか？

アドレスがないとしたらメモリ空間には存在してなかったのか？
0236デフォルトの名無しさん2010/04/15(木) 11:14:48
>>229
GCありだからそもそもレイヤがちょと違うけど
・マイナー
・安定の二文字とは無縁な言語仕様（ビジネスでの利用は問題外、趣味でも
　昔のコードがすぐ動かなくなるのでついてくのがつらい）
・ヘッダをいちいち変換するのめんどい
など、流行らない理由はいくらでもあるだろうな
0237デフォルトの名無しさん2010/04/15(木) 11:15:51
会話が斜め上225℃を逝ってるな
0238デフォルトの名無しさん2010/04/15(木) 11:20:22
Cで記述された現存するOSの母国語、systems programming languageがCになるのは
当たり前
というわけで組み込みや新たなOS記述言語の地位狙いということになるのかな
0239デフォルトの名無しさん2010/04/15(木) 11:24:49
>>235
システムコールとライブラリコールの違い分かる？
0240デフォルトの名無しさん2010/04/15(木) 11:29:22
もしかしてCのコードから直接trapを発行してると思ってる？
0241デフォルトの名無しさん2010/04/15(木) 11:31:07
>>235
CP/Mやその派生にはないね。
0242デフォルトの名無しさん2010/04/15(木) 11:35:23
CP/M は call 0003 ってアドレス使ってなかったか
0243デフォルトの名無しさん2010/04/15(木) 11:36:46
>>229
Dが流行らなかった原因はCやC++やC#との差別化ができなかった所。
0244デフォルトの名無しさん2010/04/15(木) 11:37:15
>>242
3じゃなくて5な
0245デフォルトの名無しさん2010/04/15(木) 11:38:13
>>242
直接アドレス呼び出すなよ。
何のためのOSだよ
0246デフォルトの名無しさん2010/04/15(木) 11:39:20
いやCP/Mってリングプロテクションとか特権／保護とかやってる
モダンなOSじゃないから
0247デフォルトの名無しさん2010/04/15(木) 11:39:45
>>245
そういう OS だったんだから仕方ない
0248デフォルトの名無しさん2010/04/15(木) 11:42:58
ああ、本当のシステムコールじゃなくてシステムライブラリを
呼ぶという話しか。
0249デフォルトの名無しさん2010/04/15(木) 11:43:25
システムライブラリとはなんじゃらほい
0250デフォルトの名無しさん2010/04/15(木) 11:44:27
APIのことだろう
0251デフォルトの名無しさん2010/04/15(木) 11:44:49
ゲートのこっち側の、Cでリンクして呼べるようになってる
関数インタフェースのことじゃないか
0252デフォルトの名無しさん2010/04/15(木) 11:47:51
おまいらこれでも見てもちつけ
ttp://www.itmedia.co.jp/news/articles/1004/14/news068.html
0253デフォルトの名無しさん2010/04/15(木) 11:50:47
>>252
消えうせろゴミ
0254デフォルトの名無しさん2010/04/15(木) 12:07:29
>>248 crtじゃなくてシステムコールを直接呼んでる言語があるなら挙げてみやがれ
0255デフォルトの名無しさん2010/04/15(木) 12:12:19
>>248ではないが
crtってCランタイム、libcのことならまた全然別の話だろう
なんかどんどん斜め上に話が進んでるな
0256デフォルトの名無しさん2010/04/15(木) 12:15:42
Unixならman 2で出てくるのがシステムコール（のAPI）
man 3で出てくるのがlibc

直呼びってMS-DOSのINT21Hとかだろ
0257デフォルトの名無しさん2010/04/15(木) 12:43:20
そうだな。CPUの割り込み使って呼び出すヤツ
0258デフォルトの名無しさん2010/04/15(木) 12:51:23
システムコールはOSのカーネルが提供するサービスだよ。
低級言語ってのは、そのカーネル自体を作れるレベルの低水準言語。
0259デフォルトの名無しさん2010/04/15(木) 12:55:04
言い換えれば「ハード以外何もいらない」ってこと。
0260デフォルトの名無しさん2010/04/15(木) 12:56:32
>>258
JavaでもLispでもGoでも、そしてこのスレの誰かさんが大好きなDでもOSを作るぐらいできるよｗ
0261デフォルトの名無しさん2010/04/15(木) 13:02:18
次の名称を述べよ

1.各々のチップなどHWを制御する為のポートで提供される操作

2.BIOSの提供する制御操作

3.CPUの割り込みを利用して提供される制御操作

4.OSのカーネルが提供する制御操作

5.SDKが提供する制御操作
0262デフォルトの名無しさん2010/04/15(木) 13:09:23
javaでどうやってos作るの？
0263デフォルトの名無しさん2010/04/15(木) 13:12:52
>>262
JNode
0264デフォルトの名無しさん2010/04/15(木) 13:15:05
>>261
1 IO
2 BIOSコール
3 割り込み
4 システムコール
5 SDKが曖昧
0265デフォルトの名無しさん2010/04/15(木) 13:31:14
>>263
アセンブラ入ってんじゃん
そんなのjava製とはいえん
0266デフォルトの名無しさん2010/04/15(木) 13:32:21
>>265
じゃあC言語だけでOS作ってみろよｗ
0267デフォルトの名無しさん2010/04/15(木) 13:32:41
>>265
アセンブラなしででは、Cでもできない。
0268デフォルトの名無しさん2010/04/15(木) 14:40:05
>>236
なんだDってクソ言語じゃねーか。全く駄目だな
0269デフォルトの名無しさん2010/04/15(木) 14:49:59
でもDしかないし
0270デフォルトの名無しさん2010/04/15(木) 17:08:55
>>67
結局、罵倒したいだけですか。やれやれ。
ではバックアップ掲載しておきます。あとはご自分でどうぞ。

*低級言語 [#q34e2cc7]

-プリプロセス
--字句解析
--構文解析
--マクロ展開

-コンパイラ
--字句解析
--構文解析
--最適化
--コード生成
--アセンブル

-リンカ
--リンク
02712702010/04/15(木) 17:09:42
**プリプロセッサ、マクロ [#dd2a2569]

**型 [#pcaa63a2]
型は大文字？小文字？

|1byte|Byte|
|1byte|Ubyte|
|2byte|Short|
|2byte|Ushort|
|4byte|Int|
|4byte|Uint|
|8byte|Long|
|8byte|Ulong|
|4byte|Float|
|8byte|Double|
||ポインタ|

Double* a;
var a: *Double;
02722702010/04/15(木) 17:10:25
*型宣言 [#n0629b9d]

伝統的な形　前置

byte name = 3;// mutable
static byte name = 3;// static
const byte name = 3;// imutable

構文解析を簡単にするなら後置 (参考 ActionScript, Scala, haXe等)

var name:byte = 3; // mutable
val name:byte = 3; // imutable
def name:byte = 3; // static

def f:(a:Int,b:Int)=>Int = {a+b} // static function
val f:(a:Int,b:Int)=>Int = {a+b} // imutable function
var f:(a:Int,b:Int)=>Int = {a+b} // mutable function (function pointer)
02732702010/04/15(木) 17:12:53
**複合型 [#od53d6ce]
def A:struct {
var a:Int;
var b:Int;
}
enum
union
bitfield
variant
const

**構文 [#fd5994bf]

変数
関数
配列
if else
goto
while
do while
for
break
continue
typedef
02742702010/04/15(木) 17:14:47
**演算子 [#m86a3779]

= 代入演算子 a = b はプリプロセッサによりassign(a,b)に変換される。
+ 加算演算子 a + b -> add(a,b)

とか
---
以上です。
0275デフォルトの名無しさん2010/04/16(金) 00:01:00
新言語では、宣言文の中で、型を後ろに表記したい。

Cで書くと、変数とポインタは問題ないが、関数や配列は名前の前後に記述が来てわかりにくい。

int i; // i は int型
int *p; // *p は int型
int f(int n); // f(0) は int型
int a[100]; // a[0] は int型

後ろに型をかけば、変数もポインタも関数も配列も、すべてスッキリする。

i int; // i は int型
p* int; // p* は int型
f(int n) int; // f(0) は int型
a[100] int; // a[0] は int型

複雑な型であっても、スッキリする。表記も短くなる。

int (*fa[])(int (*fb)()); // [Cの場合] int型を返すint型を返す関数へのポインタ(fb)を引数にとる関数へのポインタの配列fa
fa[]*(fb*() int) int; // [提案方式の場合] int型を返すint型を返す関数へのポインタ(fb)を引数にとる関数へのポインタの配列fa

乗算(*)とポインタ参照(@)は違う演算子にした方がいいかもしれない。

i int; // i は int型
p@ int; // p@ は int型
f(int n) int; // f(0) は int型
a[100] int; // a[0] は int型
fa[]@(fb@() int) int; // [提案方式の場合] int型を返すint型を返す関数へのポインタ(fb)を引数にとる関数へのポインタの配列fa
　　　　　　　　　　　　　　　　　　　　　　　　　　　（　fa[0]@(fb@() int) は int型 かつ、fb@() は int型 ）
0276デフォルトの名無しさん2010/04/16(金) 00:08:49
wiki消えとるワロス
0277デフォルトの名無しさん2010/04/16(金) 00:11:17
別に消さなくてもいいのにね。
ちょっと煽られてヽ(`Д´)ﾉﾓｳｺﾈｴﾖ!!とか、近年稀に見る耐性が低さだわ。
0278デフォルトの名無しさん2010/04/16(金) 00:16:38
お前らなんて煽るだけで何もできないのにな
0279デフォルトの名無しさん2010/04/16(金) 00:17:00
そうだね。
0280デフォルトの名無しさん2010/04/16(金) 00:21:23
char[] array_char(100); // array_char is of char[] type
int* px, py; // both px and py are pointers of int* type

配列とポインタの宣言はこれでいいんだよ。ごちゃごちゃ抜かすな。

＠マークとかアホらしいから、C++でおなじみの->を流用しようぜ。

int z = px->; // int z = *px;
0281デフォルトの名無しさん2010/04/16(金) 00:34:12
>char[] array_char(100); // array_char is of char[] type

array_char(100) が char[] 型になるのか？
[] array_char(100) が char 型になるのか？

ならないなら、美しくない。

>a[100] int; // a[0] は int型

a[0] は int型
a は [100] int型

宣言と利用が同じ形をしている。だから、美しい。
0282デフォルトの名無しさん2010/04/16(金) 00:48:19
>>280
->とかキモいから全部@にしちゃえよ。
0283デフォルトの名無しさん2010/04/16(金) 00:48:41
>>281
どこに a[0] とか出てくるんだ？全然美しくないだろ。
[100]int型とかアホか。Ｃの基礎から勉強してこい。
Ｃの配列と異なるというなら、そんな配列は醜すぎる。
0284デフォルトの名無しさん2010/04/16(金) 00:49:26
すごくどうでもいい
0285デフォルトの名無しさん2010/04/16(金) 00:56:44
>>283
> [100]int型とかアホか。Ｃの基礎から勉強してこい。

Cの話はしていない。
0286デフォルトの名無しさん2010/04/16(金) 00:57:34
Ｃの場合、

char str[100];

は、char[] 型の配列変数 str を宣言し、
100要素分の連続したメモリ領域を確保して、
str がその先頭要素のアドレスを指すということだろ。

また、配列 str は char* 型 でもある。

型の char[] とか char* はキャストでは明確に出てくるが、
変数宣言時には出てこないので、初心者の意識には昇りにくい。

こういったＣの特性を踏まえれば、

char[] str(100);

のように宣言するのはＣを踏襲しているわけだが、
配列が宣言時のサイズによって型が違うようにするとか、Ｃの改悪で醜いもいいところ。
0287デフォルトの名無しさん2010/04/16(金) 01:03:15
スタックに構造体や配列をおける言語ってC以外にある？
0288デフォルトの名無しさん2010/04/16(金) 01:05:09
str [100] char; // char型の要素100個の配列

a char; // char型の変数a
a = str[0]; // char型のコピー

b [] char; // char型の要素数未定の配列b
b = str; // char型の配列のコピー
0289デフォルトの名無しさん2010/04/16(金) 01:09:13
なんだ。goの話してんのかと思たわ
あれの配列は
var a [10]int
まあsliceが強力だから配列よりそっちの方使うと思うがね
unsafeでmmapをsliceに直貼り出来たのにはわろたが
0290デフォルトの名無しさん2010/04/16(金) 01:11:04
goがそうなってるなら、goに習えばいいね。
0291デフォルトの名無しさん2010/04/16(金) 01:12:39
->記号がマジイミフ
可読性低いし打ち辛いしばかかと
0292デフォルトの名無しさん2010/04/16(金) 01:13:47
配列がコピーされてそんなにうれしいか
foo(n int) [] char { bar [n] char; return bar; }
bar [] char = foo(128);
こういうキモいこと(配列を返す関数)もできるわけか
0293デフォルトの名無しさん2010/04/16(金) 01:18:40
>>292
goの例でいうと戻り値が配列の場合
書き方にもよるがコピーじゃなく
戻り側の変数に直で書かれたりする
0294デフォルトの名無しさん2010/04/16(金) 01:23:43
->が可読性低いってほうがイミフ
0295デフォルトの名無しさん2010/04/16(金) 01:24:02
>>275
関数ポインタ要らない
関数をオブジェクトとして使うときはポインタに決まってるんだから

同じ理由で、メンバアクセス演算子は.だけでいい
わざわざ左オペランドの型で.と->を使い分ける必要が無い

関数の型は->とか=>で書きたい
int->int : intを受け取りintを返す関数

Cのうんざりするようなsignal関数の型は
(int, int->void) -> (int->void)
となる
関数宣言はこんな感じで
def signal(signum int, handler int->void) int->void {}
Cのものよりずっとシンプルで読み書きしやすい
0296デフォルトの名無しさん2010/04/16(金) 01:25:58
実体とポインタ両方ないなんてありえん
0297デフォルトの名無しさん2010/04/16(金) 01:26:46
あと、
＞p* int; // p* は int型
これ意味不明
pはint*型、じゃないの？

*intと書かせるのはキモいので、
&intと俺は書きたい。
02982972010/04/16(金) 01:27:42
ありゃ、最後の行失敗
p &int
のつもり
0299デフォルトの名無しさん2010/04/16(金) 01:27:56
>>297
p は *int 型
p* は int 型
0300デフォルトの名無しさん2010/04/16(金) 01:28:41
つーかメモリモデルすらわかってない奴多くね？
0301デフォルトの名無しさん2010/04/16(金) 01:29:09
「奴」とかの話はいらないから。
03022972010/04/16(金) 01:29:24
>>299
ああ、意図は理解した
型宣言の話をしているのかと思ったが、*演算子を後置にするという話が
混じっていたの？
その必要が無いように思えるけど
0303デフォルトの名無しさん2010/04/16(金) 01:41:00
メモリへのアドレスによる直接アクセスと、IOへの入出力と、
リアルタイムタイマの操作と、各種割り込みのトラップが出来れば
あとはなんでもいいや ＞ 低レベル言語
0304デフォルトの名無しさん2010/04/16(金) 01:43:11
アドレス以外ライブラリでいいな
0305デフォルトの名無しさん2010/04/16(金) 01:44:47
>>304
安全な言語目指すなら
アドレスもライブラリでいい
効率はオプティマイズで稼げる
0306デフォルトの名無しさん2010/04/16(金) 02:07:29
>295
数学の関係とか写像のイメージと同じでこれはいいと思ったが、

int (*(*f)(int (*)(int, int), int))(int (*)(int), int);
var f ((int, int)->int, int)->((int->int, int)->int)
0307デフォルトの名無しさん2010/04/16(金) 05:15:34
>>304
memory mapped I/O ならともかく、ポートが叩けないってことはライブラリはアセンブラで書くのか？
まあＣのio.h みたいに、マクロでインラインアセンブラが書いてあるのもありかもしれないが、
個人的にはポート型があって、コンパイラが解決してくれるほうがありがたいな。


0308デフォルトの名無しさん2010/04/16(金) 05:34:11
I/Oポートが独立してるCPUはもう86位じゃないかな
RISC CPUや組み込み向けCPUではmemory mappedが主流だね
Cとの相性がいいし、ハードもみため統一的になる

まあ言語に組み込むならI/Oポートはさほど速度もいらんし
せいぜい組み込み関数とかで解決でいい気がする
直アドレスも範囲限定出来たりすると安全かな

具体的にはsliceみたいなのをレジスタ範囲のアドレスに張り付けって感じ
同じ記述でI/Oポートも叩けたら、配列風な記述でI/O出来るな
go風に書くと

var xx_reg = iomap(0x1000, 0, 16)
var mm_reg = mmmap(0xff000000, 0, 16)
xx_reg[0] = 0x100

てな感じ
0309デフォルトの名無しさん2010/04/16(金) 06:54:18
マクロでfor文とsprintfが欲しいな
0310デフォルトの名無しさん2010/04/16(金) 07:08:09
C++をdefineで好みに再定義すりゃいいやん
0311デフォルトの名無しさん2010/04/16(金) 08:39:35
>>308
その86が今もって強いから問題かと。
言語的には特殊なメモリとして扱えれば十分だが。
0312デフォルトの名無しさん2010/04/16(金) 09:26:39
ポインタのデリファレンスは後置単項演算子のほうがエレガントなんだっけ？
0313デフォルトの名無しさん2010/04/16(金) 11:24:28
いろんな表現を発明して、それがCより優れてるとしても、Cの表現をマスターした人間にしてみれば
そんなのを再勉強するのは負担なので受け入れられないだろう。
int (*fnc)(int(*)(void)); がわからない？ハァ？勉強汁！でおわり。
逆に、勉強汁！って怒られた奴が恨みに思ってこんなスレ延ばしてるんじゃねえのかｗ
0314デフォルトの名無しさん2010/04/16(金) 11:28:04
ガベコレさえあればC/C++でいいよ
0315デフォルトの名無しさん2010/04/16(金) 11:57:21
どっちだよ
0316デフォルトの名無しさん2010/04/16(金) 11:59:07
>>313
今ここで勉強しているのだから大いに結構

>int (*fnc)(int(*)(void));
* -> (* -> (void) -> int) -> int

後置が良いってのは要するに、前置*と後置[]()が入り乱れるより
後置に統一する方が結合の順番がわかりやすい
つまり構文木の深いところから浅いところに向けて順番に並ぶのが良いということだな
0317デフォルトの名無しさん2010/04/16(金) 13:51:46
>>316
下のほうが分かりにくいw
0318デフォルトの名無しさん2010/04/16(金) 14:05:06
慣れの問題
0319デフォルトの名無しさん2010/04/16(金) 14:05:45
ポインタ宣言のツリー構造は、K&Rにふつうに書いてあるな
問題は、膨大な情弱用コンテンツに埋もれてK&Rに辿り着けない奴が多いこと。
0320デフォルトの名無しさん2010/04/16(金) 14:12:58
typedefがあるのだから、どうでもいい問題。
0321デフォルトの名無しさん2010/04/16(金) 14:46:46
>>318
慣れの問題なら、C表記に慣れてる人々を切り捨てて
誰もが慣れていない新表記を押し付けるのはコスト的に不都合
0322デフォルトの名無しさん2010/04/16(金) 15:22:02
>>320
それはまさに「名詞の王国」の発想
或いは、defがあるからlambdaを制限する・classがあるからスコープを制限する
のような思想
0323デフォルトの名無しさん2010/04/16(金) 15:33:06
Python対Ruby、Java対C#は偶然ではないね、偶然が二度続けばなんとかって言うし
0324デフォルトの名無しさん2010/04/16(金) 17:13:16
Cは一つの記号に複数の意味を持たせたものがいっぱいあるんだよな。
構文をシンプルにするためには、一つの記号に複数の意味を持たせないことだな。
ASCII文字の内、Cで使われていない@と`も含めフル活用して一意の意味付けをする。
あと、一見して意味が通じそうな<-や->みたいに、誰が見ても想像できそうな使い方は良いと思うよ。
一部分でしか使ってない<>とか#とかは文字列に置き換えて、他の部分に使ったほうがいいよ。
0325デフォルトの名無しさん2010/04/16(金) 17:21:57
>>324
＞@と`も含めフル活用して一意の意味付けをする
makeの失敗の歴史も知らずに何を偉そうに語ってるんだか
0326デフォルトの名無しさん2010/04/16(金) 17:34:22
アスタリスクが、ポインタが示す値の参照と掛け算の二つの意味があることで、読みにくくなることあるかな？
0327デフォルトの名無しさん2010/04/16(金) 17:44:40
<が比較演算子かtemplateの引数のカッコかわからない
0328デフォルトの名無しさん2010/04/16(金) 17:46:25
std::vector<std::vector<int> > hoge;
この「> >」のスペースがとっても嫌。
std::vector<std::vector<int>> hoge;
と書きたい。
0329デフォルトの名無しさん2010/04/16(金) 17:47:20
>>328
いまどきのコンパイラなら書けるでしょ
0330デフォルトの名無しさん2010/04/16(金) 17:49:21
>>329
どこのコンパイラで書けるのか実例を挙げてくれ
0331デフォルトの名無しさん2010/04/16(金) 17:55:00
>>330
こんにちは
スレ違いです
0332デフォルトの名無しさん2010/04/16(金) 17:56:26
デタラメを書く→追求される→スレ違いと言って逃げる
だから便所のラクガキなんだよ
0333デフォルトの名無しさん2010/04/16(金) 18:03:00
>>329
無知カス
0334デフォルトの名無しさん2010/04/16(金) 18:03:59
>>328
C++0xまでマテ
gcc なら -std=c++0x とか -std=gnu++0x でOK.
0335デフォルトの名無しさん2010/04/16(金) 18:06:04
VS2010で普通に書けるが？
0336デフォルトの名無しさん2010/04/16(金) 18:06:46
どっちが無知やら
0337デフォルトの名無しさん2010/04/16(金) 18:10:30
>>335
そんな方言持ち出していまどき扱いされてもなあ
0338デフォルトの名無しさん2010/04/16(金) 18:13:01
>>337
334が見えないのか
0339デフォルトの名無しさん2010/04/16(金) 18:13:44
>>338
そんな方言持ち出していまどき扱いされてもなあ
0340デフォルトの名無しさん2010/04/16(金) 18:15:46
おまえが使っているコンパイラどれだよ？
0341デフォルトの名無しさん2010/04/16(金) 18:16:37
C++0xこそ方言じゃねぇか
gcc以外の何が対応してんだよ
0342デフォルトの名無しさん2010/04/16(金) 18:16:46
みなさん恐れ入りますがスレ違いです
0343デフォルトの名無しさん2010/04/16(金) 18:19:24
そういやテンプレ引数で比較演算子使うと上手くいかない場合があるんだよな。
こういうの
template_type< const_arg1 >= const_arg2 >
0344デフォルトの名無しさん2010/04/16(金) 18:20:11
いまどきのコンパイラはだいたいC++0xに部分的に対応している
std::vector<std::vector<int>> hoge;
と書けないコンパイラの方が珍しい
0345デフォルトの名無しさん2010/04/16(金) 18:25:59
C＃のパーサーはテンプレートのところでパースに失敗すると、かっこの意味を変えてパースしなおす。VS2010もそうしているんだろう。
0346デフォルトの名無しさん2010/04/16(金) 18:28:55
括弧の種類を増やそうぜ
《》「」≪≫『』【】
0347デフォルトの名無しさん2010/04/16(金) 18:53:02
使える記号の少なさが
言語の進化を妨げているな
0348デフォルトの名無しさん2010/04/16(金) 19:04:15
そこで APL の出番だな
0349デフォルトの名無しさん2010/04/16(金) 19:11:43
複数意味がある記号がたくさんあると
その組み合わせ分だけパースしなおすのか
0350デフォルトの名無しさん2010/04/16(金) 21:41:37
全部()でいいよ。文法は単純な方がいい。
0351デフォルトの名無しさん2010/04/16(金) 21:44:35
VBやDでは()使ってるね
0352デフォルトの名無しさん2010/04/16(金) 21:44:36
　{}の方がエレガントだよ！
0353デフォルトの名無しさん2010/04/16(金) 21:45:37
()の前に!つかるとかださいよね
0354デフォルトの名無しさん2010/04/16(金) 22:17:48
シフトキーを押さなくてもいい記号だけにしろよ
0355デフォルトの名無しさん2010/04/16(金) 22:21:29
-^\@[];:,./
0356デフォルトの名無しさん2010/04/16(金) 22:25:36
101か106でも違うし…
0357デフォルトの名無しさん2010/04/16(金) 23:26:42
そこでドラムセット型キーボードの出番ですよ。
0358デフォルトの名無しさん2010/04/16(金) 23:39:16
F1 3C C9
0359デフォルトの名無しさん2010/04/17(土) 00:06:51
俺的にC/C++のメリットはメモリ管理が確実に読めるコードが書けることにあると思う。
GC使いたいならJavaやC#のほうがよくね？
0360デフォルトの名無しさん2010/04/17(土) 00:08:39
>>359
どこをとってもスレ違い
0361デフォルトの名無しさん2010/04/17(土) 00:10:39
>>360
頭悪くね？
0362デフォルトの名無しさん2010/04/17(土) 00:15:39
そうだね。
0363デフォルトの名無しさん2010/04/17(土) 00:41:42
C9がretなのは覚えてる
0364デフォルトの名無しさん2010/04/17(土) 01:31:04
お前らが語ってることって40年前の黎明期より劣ってるんだけど自覚ある？
0365デフォルトの名無しさん2010/04/17(土) 01:33:53
開発不要という結論に達するまで、あと何スレかかるかな。
0366デフォルトの名無しさん2010/04/17(土) 01:36:05
ってかむしろ開発不能というのが近い気が…
0367デフォルトの名無しさん2010/04/17(土) 01:37:09
開発できるような奴もいないだろ
0368デフォルトの名無しさん2010/04/17(土) 01:39:03
ちんけな最適化でよければ、Cコンパイラぐらいは書ける。
0369デフォルトの名無しさん2010/04/17(土) 01:39:45
template「class T」
void f()
{
vector「Ｔ」 v;
}
0370デフォルトの名無しさん2010/04/17(土) 01:43:35
Cのマクロを廃止して、今、マクロで行われていることの多くができる構文を導入したもの。
今のCでは、マクロが原因でIDEの支援がどうしても限定的で不正確になってしまっている。
0371デフォルトの名無しさん2010/04/17(土) 01:51:13
トランスレーター作ったことあるけどパーサーも抽象構文木の解釈処理も結構手間だ
0372デフォルトの名無しさん2010/04/17(土) 01:53:19
確かに、難しくはないが、面倒くさいな。
0373デフォルトの名無しさん2010/04/17(土) 02:07:10
template <typename T>
T add(T& a, T& b){ return a+b; }

は

add<T typename> (a &T, b &T ){ return a+b; } T;

でいい。
templateとかｲﾁｲﾁ書くのアホ臭い。
0374デフォルトの名無しさん2010/04/17(土) 02:12:01
Common Lispのマクロってどんな感じなの？
0375デフォルトの名無しさん2010/04/17(土) 03:09:53
なんでもできる。
0376デフォルトの名無しさん2010/04/17(土) 04:28:53
何でもできるってOS書けるの？
0377デフォルトの名無しさん2010/04/17(土) 05:07:18
"OS"
0378デフォルトの名無しさん2010/04/17(土) 05:22:31
http://gist.github.com/46417

とりあえず、こんなかんじでよろ
0379デフォルトの名無しさん2010/04/17(土) 08:35:07
>>370
糞重いIDEなんて使う気にならないからどうでもいい
0380デフォルトの名無しさん2010/04/17(土) 09:04:46
シンプルな低級言語を設計する話が、なんで複雑な最新技法の導入の話になってんの?
boostっぽいのとか全部すれ違いな気が…
0381デフォルトの名無しさん2010/04/17(土) 09:49:20
構文に美しさを求める人たちと、とにかく速くしたいと思う人たち

そのやり取りを上から眺めてニヤニヤしている、初代スレの>>1
0382デフォルトの名無しさん2010/04/17(土) 10:29:46
構文どうこう言ってる奴らは消え失せろ
スレ違いだ
0383デフォルトの名無しさん2010/04/17(土) 10:56:05
>>379
お前みたいなレガシーは、絶対少数派だから発言しなくていい。
0384デフォルトの名無しさん2010/04/17(土) 11:04:53
>>383
多数派に属さないと怖くて意見も言えないんですね（ﾌﾟ
0385デフォルトの名無しさん2010/04/17(土) 11:07:31
統計学的にも達人より初級者の方が多数派なのは明らかだしなあ
0386デフォルトの名無しさん2010/04/17(土) 11:09:19
統計出すまでもなく論理的にそうだろう
0387デフォルトの名無しさん2010/04/17(土) 11:11:04
新言語を設計するなら、IDEのことを考慮するのは当然。
0388デフォルトの名無しさん2010/04/17(土) 11:13:55
考慮は当然だがテキストエディタだけでも書きやすいほうがいいね。
0389デフォルトの名無しさん2010/04/17(土) 11:15:58
IDEごときに脳まで侵されてるんだな、可哀想に。
こんな人が他所の環境に異動にならないことを祈るばかりだ。
0390デフォルトの名無しさん2010/04/17(土) 11:23:36
>>379
Intel Core i7あたりのPC買って、何かIDE試してみなよ。便利だぞ。
0391デフォルトの名無しさん2010/04/17(土) 11:27:17
便利だがキャリアの長いプログラマは慣れたエディタでのノウハウも捨てがたいからな。
ほとんどIDE上のエディタ機能いらないことも多い。併用するだろ。
0392デフォルトの名無しさん2010/04/17(土) 11:54:07
IDEが言語に合わせろよ
0393デフォルトの名無しさん2010/04/17(土) 12:02:22
Eclipse ＋プラグイン
0394デフォルトの名無しさん2010/04/17(土) 12:03:31
統合開発したいと言われても胸が熱くならないな
ピンポイントで具体的なモチベーションがないと
0395デフォルトの名無しさん2010/04/17(土) 12:50:04
IDE使っていないやつは、IDEによって省力化できるところに、労力を費やしている。
0396デフォルトの名無しさん2010/04/17(土) 12:52:28
使い慣れた道具ってものがあるからIDE使うのは強制しないけど、
IDEを馬鹿にするのはおかしい。
0397デフォルトの名無しさん2010/04/17(土) 12:52:52
俺様はデバッガーの使い方分かんないけどな
0398デフォルトの名無しさん2010/04/17(土) 13:08:20
デバッガなんて作るもんで使うもんじゃねえな
エディタはemacsとviあればいいっしょ
0399デフォルトの名無しさん2010/04/17(土) 13:14:38
楽できるのなら楽をする
自分でやるな機械やらせろ
人間が機械にあわせてやる必要はない、機械が人間にあわせればいいんだ

なぜかデジャブが
0400デフォルトの名無しさん2010/04/17(土) 13:22:06
IDEは結局ターゲット変えたらやり直しだから経験不足のやつほどメリット強調しやすい
0401デフォルトの名無しさん2010/04/17(土) 13:26:32
マクロやPerlのような言語による省力化もあるんだが、GUIと相性悪くて
お互いに相手が原因だと言って譲らない状態
0402デフォルトの名無しさん2010/04/17(土) 14:39:56
自分が新言語に求めるものって

再利用性(抽象性) ＞ 構文の美しさ(読みやすさ) ＞ 速さ

かな
0403デフォルトの名無しさん2010/04/17(土) 14:42:31
再利用性(抽象性) ＞ 構文の美しさ(読みやすさ) ＞ 速さ ＞ IDE

0404デフォルトの名無しさん2010/04/17(土) 14:44:21
正解は

低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
0405デフォルトの名無しさん2010/04/17(土) 14:45:58
「C/C++に代わる」の意味考えてないだろ
0406デフォルトの名無しさん2010/04/17(土) 14:47:03
>>405
考えるとどうなるの？
0407デフォルトの名無しさん2010/04/17(土) 14:50:30
え？
0408デフォルトの名無しさん2010/04/17(土) 14:52:47
>>404
それなら C/C++ で充分
0409デフォルトの名無しさん2010/04/17(土) 14:54:01
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
0410デフォルトの名無しさん2010/04/17(土) 14:56:03
他言語に置き換えられてない部分といったら
OS/デバドラ/組み込み/ネイティブアプリ/過去のコード資産
あたり？
0411デフォルトの名無しさん2010/04/17(土) 14:57:40
>>410
新言語はまだ他言語に置き換えられるほど普及していないよ。
0412デフォルトの名無しさん2010/04/17(土) 15:04:29
>>409
ごめん
じゃあ言い換える

>>404 の主張は新たな言語の目的としてはおかしい(C/C++があるから)
0413デフォルトの名無しさん2010/04/17(土) 15:21:10
＞今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、

＞現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
＞一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、


0414デフォルトの名無しさん2010/04/17(土) 15:23:04
コードを書くたびにプログラム観が変わるんだが
プログラム言語の研究者って実際の実用コードどのくらい書いてるんだ？
0415デフォルトの名無しさん2010/04/17(土) 15:25:43
お前の業務経歴なんか、しるか。
0416デフォルトの名無しさん2010/04/17(土) 15:39:43
今の時点でリテラルに機能を乗っけようとしているやつは気にしているやつは何を考えているね？
まずは>2-4(のさらに低水準寄り）の議論しろよ。
0417デフォルトの名無しさん2010/04/17(土) 15:47:44
>>416
お前がしたい話があるなら、他の話を遮るのではなく、お前が主導してお前の話したい話を話せ。
0418デフォルトの名無しさん2010/04/17(土) 16:10:04
素で書いても書きやすく、IDEの支援があればなお書きやすくなるような言語仕様がいいな。
0419デフォルトの名無しさん2010/04/17(土) 16:52:42
プ板でやれ
0420デフォルトの名無しさん2010/04/17(土) 16:55:12
>413
Cはすでに実在する
>もしもCが発明されていなかったとして
は無意味
>現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで
>一から低レベルなシステム開発のためのプログラミング言語を作るとしたら
最先端の研究成果はCが発明されていたから得られた
0421デフォルトの名無しさん2010/04/17(土) 17:04:28
思考実験を無意味となｗ
0422デフォルトの名無しさん2010/04/17(土) 17:05:30
無意味な思考実験
0423デフォルトの名無しさん2010/04/17(土) 17:07:51
歴史のifみたいなもんで
そういう妄想を楽しめる人には無意味ではないんじゃないの
ま、そういう妄想を理解する必要は無いし、つまらなかったら見なければ良い
0424デフォルトの名無しさん2010/04/17(土) 18:03:39
思考実験でCがなかったとするなら
CじゃないXがあったと仮定してもいいけど
Xで最先端の研究成果を導き出すのが筋
0425デフォルトの名無しさん2010/04/17(土) 19:13:33
オレの思考実験では今頃人間以上のAIを持つメイドロボが身のまわりの世話をしてくれてるはずなんだが
0426デフォルトの名無しさん2010/04/17(土) 19:16:15
>>413
過去に超一流の研究者が出した成果がCだからな
当時からコンピュータアーキテクチャの
基本が変わってない以上
低レベルな言語はCを超えれない
0427デフォルトの名無しさん2010/04/17(土) 19:19:59
>>426
でもCは当時のコンピューターを想定して作ってるから
現代においては色々と時代錯誤な部分が確実にあるよ
世の中の流れはセキュリティ最優先なのにオーバーフローを考慮しない標準ライブラリとか
精度も生成結果も笑えるレベルの擬似乱数とか
0428デフォルトの名無しさん2010/04/17(土) 19:27:40
Cには代わらないなあ
0429デフォルトの名無しさん2010/04/17(土) 19:29:13
究極の言語だからな。
0430デフォルトの名無しさん2010/04/17(土) 19:30:42
>>427
セキュリティよりも速度を追求する場合があるから
標準ライブラリならあれでいい
0431デフォルトの名無しさん2010/04/17(土) 19:33:08
>>430
速度の問題ではないと思うんだが

get()は論外
strlcpy()やsnprintf()などは標準で用意されているべき
0432デフォルトの名無しさん2010/04/17(土) 19:34:01
なんでも用意されてる言語があるだろｗ
0433デフォルトの名無しさん2010/04/17(土) 19:34:04
scanfは最初から糞だったと思うぞ
0434デフォルトの名無しさん2010/04/17(土) 19:35:12
標準っていうかCの実証実験で適当に作ったサンプルがそのまま（ｒｙ
0435デフォルトの名無しさん2010/04/17(土) 19:35:40
オーバーフロー前提の演算ができなくなったら
ゲロ遅になって困るだろ
04364312010/04/17(土) 19:35:55
- get()
+ gets()
だ、すまん
0437デフォルトの名無しさん2010/04/17(土) 19:36:28
まさか自分でバッファサイズのチェックも出来ないゆとりグラマが
幅をきかせるとは、当時の誰にも予測不可能だったからな。
0438デフォルトの名無しさん2010/04/17(土) 19:36:37
>>435
多分「バッファオーバーフロー」のことを言っているのだと思うよ
0439デフォルトの名無しさん2010/04/17(土) 19:38:53
>>437
gets()でセキュアなコードを書けると思うのなら
ぜひ書いてみてくれ
0440デフォルトの名無しさん2010/04/17(土) 19:39:44
可変長構造体とか確保するときに
struct hoge {
int length;
char buf[0];
};
struct hoge *p = (struct hoge *)malloc(sizeof(struct hoge) + 123);
とか出来て便利なんだよ
0441デフォルトの名無しさん2010/04/17(土) 19:40:43
>>440
今はセキュアでない「ライブラリ」の話だから
ランタイムで配列の境界チェックをしろとは誰も言ってないと思うよ
0442デフォルトの名無しさん2010/04/17(土) 19:40:45
>>438
バッファオーバー風呂じゃなくて
バッファオーバーランでは？
0443デフォルトの名無しさん2010/04/17(土) 19:41:19
>440
それができるのはC99からだから
0444デフォルトの名無しさん2010/04/17(土) 19:41:56
>>441
ん?
そのポインタをセキュアなライブラリに渡したらどうなるか？って話でしょ
0445デフォルトの名無しさん2010/04/17(土) 19:42:01
>>442
質問する前に目の前の箱を使ってぐぐればいいのに
0446デフォルトの名無しさん2010/04/17(土) 19:43:25
>>444
いや今の議論の流れで分かるでしょ
gets()はプログラマサイドでバッファオーバーフローを回避する手段が
一切存在しないから、設計として非セキュア
そういうレベルの話だと思うが
0447デフォルトの名無しさん2010/04/17(土) 19:44:16
>>446
>strlcpy()やsnprintf()などは標準で用意されているべき

これ書いたのは？
0448デフォルトの名無しさん2010/04/17(土) 19:45:59
Cの作者の最大の誤算はここまで広く使われるとは思っていなかったことだろうな
0449デフォルトの名無しさん2010/04/17(土) 19:46:02
標準ライブラリやセキュリティのはなしはもう他の言語が改善してるじゃん
0450デフォルトの名無しさん2010/04/17(土) 20:06:30
こんなのを発見した。
ttp://ci.nii.ac.jp/naid/110002896056/

こういった発想の方がいいんじゃない？C/C++のつまらん枝葉の議論するよりかマシだと思うけど。
0451デフォルトの名無しさん2010/04/17(土) 20:14:58
C99 の次はまだ出ないのかなあ。
0452デフォルトの名無しさん2010/04/17(土) 20:18:42
言語とライブラリの話をごっちゃ混ぜにするやつらがいる
0453デフォルトの名無しさん2010/04/17(土) 20:31:34
>>426
言語やアーキテクチャとは関係ない話
セキュリティなんてライブラリの話
C自体はポインタやランタイムの範囲チェックはないが
それ故に組込からスパコンまで使えるスケーラビリティになってる

Cは神の様な一流が実験より実用を目指して作って成功した言語だよ
簡単に超えれないのは当然
0454デフォルトの名無しさん2010/04/17(土) 20:34:38
バッファオーバーは言語仕様の問題といっていいでしょう。
でもＣはそれがコンセプトだからね。どういうコンセプトにしたいかが問題。
0455デフォルトの名無しさん2010/04/17(土) 20:36:46
>>451
gcc にgnu99+ms-extensionで使いたい俺
次の標準には無名のメンバに
他で定義したのを使えるようにして欲しい
0456デフォルトの名無しさん2010/04/17(土) 20:38:46
>>453
あ、日本語おかしいかった
ポインタや配列のランタイムの範囲チェックな
0457デフォルトの名無しさん2010/04/17(土) 20:58:07
Cに何を乗せるか話し出すといる要らないで話が進まなくなるから
要らないものや使いにくい部分を外す方からはなさないか？
0458デフォルトの名無しさん2010/04/17(土) 21:18:23
このスレまだ続いてたんだ
0459デフォルトの名無しさん2010/04/17(土) 21:45:49
思考実験のネタスレで本当に言語作ろうとしてたのかｗ
0460デフォルトの名無しさん2010/04/17(土) 21:53:56
いろんな言語の原理主義者達がお互いを罵り合ってるだけで思考実験すら成立していない
0461デフォルトの名無しさん2010/04/17(土) 21:54:59
ここでいい案が出たって誰も何も作らないんだから、本気で考えるわけがないし。
0462デフォルトの名無しさん2010/04/17(土) 21:56:36
おれは案持ってるから自作中。
あと２年生きてられたら読み出せるから期待してくれ。
0463デフォルトの名無しさん2010/04/17(土) 22:22:31
俺もForth系を自作中。
俺言語設計するのは楽しいよな。
0464デフォルトの名無しさん2010/04/17(土) 22:27:40
つーかいい加減飽きろよ
0465デフォルトの名無しさん2010/04/17(土) 22:58:12
「どうせできない」と言ってるバカには一生できない
0466デフォルトの名無しさん2010/04/17(土) 23:08:11
じゃあお前は出来るのかと言われるだけ
0467デフォルトの名無しさん2010/04/17(土) 23:10:24
Cに代わる物なら、実装はそんなに難しくないだろうし、そうでなければならない。
0468デフォルトの名無しさん2010/04/17(土) 23:12:11
>>454
その「Cのコンセプト」って後付けの理由としか思えないんだよね
gets()なんかは立案当時のコンピュータのメモリがプアすぎてオーバーフローが起きるような使い方自体が難しかった
それにセキュアな設計といってもfgets()のようにほんの少しの工夫で解消されるもんだよ
セキュア=劇的に重くなるってのは単なる先入観だね
0469デフォルトの名無しさん2010/04/17(土) 23:14:53
ライブラリの不出来は作り直せばいいだけだから
0470デフォルトの名無しさん2010/04/17(土) 23:17:35
言語と関係ないライブラリの話を出すな
0471デフォルトの名無しさん2010/04/17(土) 23:17:48
>>430
>>435
みたいな奴に言ってるんじゃないのかな
0472デフォルトの名無しさん2010/04/17(土) 23:19:53
ForthだとかLispだとか、永遠に普及しないからやるだけ無駄
0473デフォルトの名無しさん2010/04/17(土) 23:20:34
>>457
auto、externは要らない
関数と関数ポインタは同一視していい
メンバアクセス演算子は.だけでいい

配列とポインタの関係はもっと綺麗にできないものだろうか
0474デフォルトの名無しさん2010/04/17(土) 23:24:52
組み込み型としての配列は廃止して、ポインタによるアドレス演算のシンタックスシュガーにすればいい
0475デフォルトの名無しさん2010/04/17(土) 23:27:19
スタックに配列つくれないなんて許せん
0476デフォルトの名無しさん2010/04/17(土) 23:28:36
>>475
それはalloca()でいいんだろうけど
構造体のメンバや、static記憶クラスの配列はどうするんだろう
0477デフォルトの名無しさん2010/04/17(土) 23:30:44
>>470
標準ライブラリの実装は実装者に依存するが
どういう機能をもった関数を揃えるか？は言語設計の範囲だよ
0478デフォルトの名無しさん2010/04/17(土) 23:31:19
スタティックに配列作れなきゃmallocをライブラリやアセンブラなしにかけないな
0479デフォルトの名無しさん2010/04/17(土) 23:32:38
気に入らなきゃライブラリを作り直せばいい
0480デフォルトの名無しさん2010/04/17(土) 23:33:04
構造体の中のみ、配列を許すようにしたらいい。
0481デフォルトの名無しさん2010/04/17(土) 23:43:25
後置がよい理由は:演算子を使って型を指定する場合に

aaa:int;
int:aaa;
のどちらがよいか？と考えたときにアセンブラなどのラベルは
name:
のように名前を先に書くことから
名前:型と書くほうがいいのです。

goが面白いところは
var a int;
と書いてvarを後置２項演算子（式を２つ取るってこと）と考えれば
名前は基本的にごにょごにょ書く必要ないのに対して型は
いろいごにょごにょ書くことに対して分かりやすいだろうというのがあります。
ただ、goの２項演算子方式だと、型推論を行いたいと思った場合に出来なくなることです。
新しい低レベル言語に型推論の機能が必要か、不必要かは議論が分かれるところだと思います。
ただ、似たような表記のより高レベルな言語を作成した場合はそのことが問題となるでしょう。
新しい低レベル言語は現在のC言語とそれに似た言語となる高級言語の元となるような形であるべきです。
となると、型指定演算子あるいは命名演算子があるとよいと考えます。
そして、その演算子として最有力候補が:です。
0482デフォルトの名無しさん2010/04/17(土) 23:45:17
>>481
Scalaかな
0483デフォルトの名無しさん2010/04/17(土) 23:45:55
記憶クラスの解釈をインテリジェントにしてはどうか？
内部的な処理の違いは隠蔽するようにして
0484デフォルトの名無しさん2010/04/17(土) 23:46:20
>>468
getsはメモリがプアなマシン用にはあったほうがよいけど
メモリが沢山ある場合はよくないので、今の時代に合わせて
fgetsを推奨、getsは非推奨ってことで。非推奨だけどプアなマシン用に必要になったら入れていいと。
0485デフォルトの名無しさん2010/04/17(土) 23:47:29
>>484
それって「標準ライブラリ」の範囲で言及する必要があるの？
0486デフォルトの名無しさん2010/04/17(土) 23:56:52
潜在的な脆弱性を取り除けないものは入れるべきではないと思うんだが
gets()を利用した方がいいケースなんて本当にあるのか？
0487デフォルトの名無しさん2010/04/18(日) 00:01:15
すれ違い
0488デフォルトの名無しさん2010/04/18(日) 00:01:57
関数の引数が2ワード増えただけで困る環境って、ちょっと想像がつかない
その環境ってC言語が本当に使えるの？
0489デフォルトの名無しさん2010/04/18(日) 00:09:10
困る困らないじゃなくて、
データ列が欲しいだけなのに、最大サイズとか指定するのがウザ過ぎるって話だろ。
0490デフォルトの名無しさん2010/04/18(日) 00:15:01
んなもん
#define gets(s) fgets(s, INT_MAX, stdin)
とでも定義すれば？
04914902010/04/18(日) 00:15:47
もちろん「自分で」ね
標準ライブラリにこんなもん入れろとか馬鹿げてる
0492デフォルトの名無しさん2010/04/18(日) 00:17:12
釣り…だろうな
0493デフォルトの名無しさん2010/04/18(日) 00:51:33
マクロとか要らない
マクロ使いたい奴はC使えばいい
0494デフォルトの名無しさん2010/04/18(日) 00:55:08
Lisp並に強力なマクロが欲しい

C程度のマクロ入らない
0495デフォルトの名無しさん2010/04/18(日) 00:59:27
なんかＣの偉大さを痛感するスレだなｗ
0496デフォルトの名無しさん2010/04/18(日) 01:04:27
>>494
「Lispマシンが流行っていたら」という仮定の思考実験を行えば
Lisp一つで低級から高級までカバーできるね
0497デフォルトの名無しさん2010/04/18(日) 01:06:04
関数型をネイティブに処理できる計算機開発してから言ってくれ
0498 [―{}@{}@{}-] デフォルトの名無しさん2010/04/18(日) 01:10:39
お前らの１００倍頭のいいやつが作って、
お前らの１０００倍頭のいいやつらが何十年もかかって、
誰も完全に代替できなかったのがＣな。

コピペにもあるけど、これまで誰もしてこなかったことってのは、
「思いつかなかったこと」じゃなくて、
「思いついて試したけど失敗したり、そもそも最初から意味のなさを悟ったから、
　誰も成果をあげてないだけのこと」なんだよね。
0499デフォルトの名無しさん2010/04/18(日) 01:21:24
だからその頭のイイ奴らが、今、１から低級言語を開発したらどうなるかを考えるのがこのスレの趣旨だろ。

30年前はCになったが、今ならCと完全に同じものには絶対にならない。
0500 [―{}@{}@{}-] デフォルトの名無しさん2010/04/18(日) 01:23:07
頭のいい奴らが考えることを、頭が悪いやつらが想像することほど馬鹿らしいことはないよ。
0501デフォルトの名無しさん2010/04/18(日) 01:31:02
>496
LispマクロとLispマシンはあんまり関係がない。


Lispマクロと引数を評価しない関数、スタックを作らない関数(強制inline)は欲しいなぁ。
0502デフォルトの名無しさん2010/04/18(日) 01:31:18
今なら C より良いものができるに違いない。
0503デフォルトの名無しさん2010/04/18(日) 01:51:02
型安全なマクロが欲しい。
0504デフォルトの名無しさん2010/04/18(日) 02:12:50
コボラーがJavaやるみたいなもんか
0505デフォルトの名無しさん2010/04/18(日) 02:18:08
どういう意味？
0506デフォルトの名無しさん2010/04/18(日) 02:18:51
言い換えれば、コボラーがJavaやるみたいなもんだってことになるだろ
0507デフォルトの名無しさん2010/04/18(日) 02:19:35
なんだ、そういう意味か。
0508デフォルトの名無しさん2010/04/18(日) 02:27:21
JavaってC/C++の反省を元に云々っていう開発の触れ込みがあったけど
現状はコボラーの置き換えにしか使われていないという罠
0509デフォルトの名無しさん2010/04/18(日) 02:29:06
すべてをリプレイスするわけじゃないけど領域を奪ってはいるな。
0510デフォルトの名無しさん2010/04/18(日) 02:32:39
>>503
インライン関数で出来なくてマクロが必要ってどういう用途？
0511デフォルトの名無しさん2010/04/18(日) 02:43:35
#define call(n) func_ ## n()

void func_1();
void func_999();

int main(){ call(1); call(999); return 0; }
0512デフォルトの名無しさん2010/04/18(日) 02:48:34
日本語で書ける言語作れよ
0513デフォルトの名無しさん2010/04/18(日) 02:53:50
すれ違いもはなはだしい
0514デフォルトの名無しさん2010/04/18(日) 03:19:29
基本的なデータ構造（アレイ、リスト、スタック、キュー等）は標準で扱えるようにしてくれ。
0515デフォルトの名無しさん2010/04/18(日) 03:27:55
ライブラリの話はあまり意味ない
0516デフォルトの名無しさん2010/04/18(日) 03:32:22
まあね
0517デフォルトの名無しさん2010/04/18(日) 03:32:52
>>481
ありゃ宣言文でしょ。式じゃないし
型推論も右辺値で決まるし同じやり方
記憶クラスの推論が難しそうだがやってるね
スコープから出そうならヒープ
出なさそうならスタックとか
Cより上のC++,java狙いかな
kenさんは神々の一人だから勉強になる
0518デフォルトの名無しさん2010/04/18(日) 03:42:40
>>514
同意。Cの標準ライブラリは抜けが多すぎる。
0519デフォルトの名無しさん2010/04/18(日) 03:47:16
>>490
意味不明過ぎるだろ

getsなんて遥か以前から問題になってるから
今時使うヤツはほとんどおらん
0520デフォルトの名無しさん2010/04/18(日) 03:48:45
>>511
型安全とは全く関係ない例だなw
0521デフォルトの名無しさん2010/04/18(日) 08:05:08
C言語の記号を多用した仕様はパーサの負荷を軽減するためのものだが
結果としてプログラマのタイプ量を減らす効果もあった。
C言語が無ければ同じ時間でプログラミングできる量は減っている。
つまり今日のコンピューティングの進歩も無かったことになる。
0522デフォルトの名無しさん2010/04/18(日) 08:14:58
>>521
パーサーの負担は変わらない。
0523デフォルトの名無しさん2010/04/18(日) 08:24:16
昔のパソコンの低スペック差をなめんな
0524デフォルトの名無しさん2010/04/18(日) 08:31:18
攻撃されてもシステムを止めないCコンパイラの新たなアイデア
http://itpro.nikkeibp.co.jp/members/NBY/ITARTICLE/20050525/161456/

これパクろうぜ
0525デフォルトの名無しさん2010/04/18(日) 08:51:50
>>524
これってCの言語仕様を変えてないか？
0526デフォルトの名無しさん2010/04/18(日) 08:57:24
今のプログラマは昔よりずっと、タイピング技術が上がっている。
日常的な会話を文字列でしてるのだから。
LISPのマクロはプリプロセッサの形で導入すればよい。
マクロがいらない人は使わなければいい。
でもマクロが欲しい人のために式ベースで言語を設計するといい。
マクロが不要な人には理解できないかもしれないけど。
HaskellにマクロはないけどテンプレートHaskell
OcamlにはCamlP4とかあるし、C++にはテンプレートがある。
マクロを使いたくない人は使わなきゃよくて、基本は使わなくてすむように設計するとよい。
式ベースにする利点はマクロだけではなくて、プログラムの自動生成にも役立てることが出来るし
プログラムの構文解析も簡単になる。完全な文法を把握しなくてもいい場合ってあるでしょ。
変数の宣言を取り出したいだけとか、関数だけ取り出したいとか。
式ベースになっていても、十分な表現が可能か、否か？
という点が重要で可能であるはず。

>>517
ScalaやActionScript、haXe等が宣言文であることは知ってますよ。
でもこれらは式ベースな言語ではないのではないでしょうか？
式ベースで言語を考えれば481のような考えになるという話です。
型を:で指定できるのはHaskell,Ocaml,Cleanもそうです。
Cleanはマクロを標準で持っている。
だから新しい言語は式ベースで作ったらいいのでは？と。
BNFベースで考えれば、いつまでも、Algolと同じだって言われることになる。
0527デフォルトの名無しさん2010/04/18(日) 08:59:39
長文って内容０が多いよなwww
0528デフォルトの名無しさん2010/04/18(日) 09:27:49
何時になったら「作ろうとしても無理」て結論に落ち着くのｗ
0529デフォルトの名無しさん2010/04/18(日) 09:32:44
実装は難しくないから、無理という結論にはならないな。無駄ならわかる。
0530デフォルトの名無しさん2010/04/18(日) 09:34:49
>>525
どうやって実現(実装)するか？は、言語仕様に含まれない
例えばスタックを使わずに関数の制御が実現できるなら、別にスタック自体使わなくてもいい

int func(int hoge, int fuga)という乗算関数を標準で用意する(=言語仕様)が、
正しい結果が得られる限り、hogeとfugaをどのように計算しても(=実装)いい

言語仕様と実装の区別とはそういうこと
0531デフォルトの名無しさん2010/04/18(日) 09:41:25
>>524
ローカルのデータをコールスタックと別のスタックにとれば解決すること。
既存のライブラリとの互換取れなくてもいいなら、難しくもない。
何やってるんだ。
0532デフォルトの名無しさん2010/04/18(日) 09:49:45
>>530
ポインターは言語仕様としてはどれほどはっきり定義されてるんだっけ？
一応指した物は勝手に動き回らないというのは約束事にはないのかな？　
0533デフォルトの名無しさん2010/04/18(日) 09:58:22
物理メモリはどこ指してるか判らんときもあるぞ
0534デフォルトの名無しさん2010/04/18(日) 10:02:36
>>532
勝手に動き回るの意味がよくわからんが
指しているものが意図しないものだったら誤動作するかもね、ってだけでしょ
ちゃんと整合性を取りつつ参照先を変えるのは何ら問題ない
つーかそれがポインタのアイデンティティだし
0535デフォルトの名無しさん2010/04/18(日) 10:02:41
物理メモリ上でいくら動いても
「アドレス」さえ変わらなければ問題ないと思う
実際、仮想メモリ使ってるとそうなってるし
0536デフォルトの名無しさん2010/04/18(日) 10:33:32
>>534
> 勝手に動き回るの意味がよくわからんが

>>524の記事によると、

　領域のあふれを検知したら，VITCではメモリー空間上の別の場所に，
　十分なサイズのバッファを確保する。そして，ここにデータを格納する。
　プログラム中で元のバッファのアドレスを参照する個所は，別の場所に確保
　したバッファを参照するようにポインタを書き換える。

だから、指してる先が移動して、参照も書き換えますよって言っているけど、
アドレス計算とかしてさらにそれをどっかにコピーしたのとか追従できるのかな？
0537デフォルトの名無しさん2010/04/18(日) 11:36:09
これだけ伸びてるのに仕様書一つもうｐするやつがいないとかレベル低すぎ
0538デフォルトの名無しさん2010/04/18(日) 11:37:02
>>520
だから、

#define call(int n) func_ ## n()

こんなふうにしたいってことじゃないの。
0539デフォルトの名無しさん2010/04/18(日) 12:28:26
>>536
それは勝手に動き回ってるんじゃなくて、ちゃんと整合性を保ってるじゃん
0540デフォルトの名無しさん2010/04/18(日) 12:31:59
>>536
それは、プラットフォームの仮想化レイヤーが備える機能であって、言語が備える機能ではないんじゃないの。
0541デフォルトの名無しさん2010/04/18(日) 13:03:11
>537
俺言語開発で忙しいから任せた。
0542デフォルトの名無しさん2010/04/18(日) 13:05:03
>>537
仕様書一つくらいお前がうｐすればいいだろ馬鹿
0543デフォルトの名無しさん2010/04/18(日) 13:07:10
>>538
#define call(n) (1 ## n), func_ ## n()

整数値のみを要求するなら
これで大体いける
0544デフォルトの名無しさん2010/04/18(日) 13:07:53
あ、全体を括弧で囲み忘れた
0545デフォルトの名無しさん2010/04/18(日) 13:12:19
>>543
で、そんな奇っ怪な表現ではなく、「nは整数ですよ」と明に素直に書けるようにしたいよね。
0546デフォルトの名無しさん2010/04/18(日) 13:14:55
#define IS_DIGIT(n) (1 ## n)
#define call(n) (IS_DIGIT(n), func_ ## n())
0547デフォルトの名無しさん2010/04/18(日) 13:22:29
そういうテクニックを使ったときの問題点は
コンパイルエラーが起きたときに、その原因が分からないこと
0548デフォルトの名無しさん2010/04/18(日) 13:26:58
そこでconceptですよ。
0549デフォルトの名無しさん2010/04/18(日) 13:36:51
増築を繰り返して糞化したC++みたくならないようにしないとな。
0550デフォルトの名無しさん2010/04/18(日) 13:40:59
スレの流れからしてCからC++のような物を作ろうとしているようにしか見えないがな
まさに車輪の再開発
0551デフォルトの名無しさん2010/04/18(日) 13:44:57
70年代の車輪はまだ使えるけど、擦り切れてスリップもするし燃費も悪い。
だから、2010年の今、優秀な技術者が新しい車輪を作ったらどうなるだろうかを考えてみるってことだろ。
0552デフォルトの名無しさん2010/04/18(日) 13:47:58
エンジンがパワーアップして、ボディーもいろいろカッコいいのが出てきてるからな。
道も良くなったし。

そろそろ、車輪も新しくしたいよね。
0553デフォルトの名無しさん2010/04/18(日) 13:50:13
#define IS_DIGIT(n) (1 ## n ## 0)

じゃないと n が suffix として有効な時にダメだったわ
0554デフォルトの名無しさん2010/04/18(日) 13:51:37
そんな機能いらん
0555デフォルトの名無しさん2010/04/18(日) 13:56:45
車輪を新しくってCのリサイクルじゃんｗ
0556デフォルトの名無しさん2010/04/18(日) 13:57:14
>>551
＞燃費も悪い
燃費は最高にいいだろ何言ってんだぼけ
0557デフォルトの名無しさん2010/04/18(日) 13:59:56
2010年の今なら車輪のない乗り物で良くね？
0558デフォルトの名無しさん2010/04/18(日) 14:01:13
大昔の未来想像図みたいな絵本思い出した
0559デフォルトの名無しさん2010/04/18(日) 14:04:20
Cがなかったとして。という思考実験であっても、いまの流行技術でつくったとして
今のC/C++のどこが問題だったものが、どう改善されるかの検討なければ意味ない。
かつその問題意識はCの方向性としての「低級言語」という視点からのものでなければならない。
0560デフォルトの名無しさん2010/04/18(日) 14:21:13
そこまでは素人の考え、それが前提。
0561デフォルトの名無しさん2010/04/18(日) 14:23:41
Cがなかったとして、って、事実でない仮定からスタートしてるが、数学の重要な定理を知らんのか？
「正しくない仮定からはどんな結論でも導き出せる」
だからこんなスレいくら続けたってムダ。
0562デフォルトの名無しさん2010/04/18(日) 14:25:58
>>540
ランタイムと混同してるな
言語でやるなら二重間接にしないと
仮想アドレスはそんなに粒度高くできないし
0563デフォルトの名無しさん2010/04/18(日) 14:28:48
>>561
ここって遊び／暇つぶし／ネタじゃないの？
マジでやってるんなら厨二入ってるなと思うけど
遊びならマジで突っ込むのは無粋だな
0564デフォルトの名無しさん2010/04/18(日) 14:30:14
遊びとしてルールが破綻していると言われてるんだろ
0565デフォルトの名無しさん2010/04/18(日) 14:32:10
>>564
もっと楽しいルールにしろということか
言いたいことは分かるが、つまらんのなら見なければいいんじゃないの
0566デフォルトの名無しさん2010/04/18(日) 14:34:02
>>561
最初のスレからわかってる奴はわかってたんだが、アホの>>1がしつこく繰り返したあげく、
次スレ立てやがったからな。
誰も同意してないてのに。
0567デフォルトの名無しさん2010/04/18(日) 14:35:50
>>565
俺が言ってんじゃねーよ
そもそもこのパートスレの１スレ目の最初の>>1は、お前が言うところの厨二で
最初はノリノリであれこれ言ってたが、それは無理だと突っ込まれて消えたし
0568デフォルトの名無しさん2010/04/18(日) 14:39:30
>>567
なんだ、>>1って消えたのｗ
ま、レスついてるってことは需要あるんじゃないの
需要なくなったらスレなんて自然消滅する
2chってそういうとこだと思うけど

君はなんでこんなところ見てるの？
0569デフォルトの名無しさん2010/04/18(日) 14:41:24
「最新のプログラミングパラダイム」とかいいながら、そもそもプログラムがどう動作しているかも知らなそうだったしなぁ。
ちっとは低水準を議論できるレベルになっていれば良かったのにな。
0570デフォルトの名無しさん2010/04/18(日) 14:41:38
ifの世界でのプログラミング言語を語る馬鹿スレ
0571デフォルトの名無しさん2010/04/18(日) 14:43:09
>>568
アホな妄想に突っ込むため
0572デフォルトの名無しさん2010/04/18(日) 14:43:45
>>571
言わずもがなだったなｗ
すまん
0573デフォルトの名無しさん2010/04/18(日) 14:44:25
思考実験って知らない奴が数学語ってるのか
0574デフォルトの名無しさん2010/04/18(日) 14:46:39
いるよね屁理屈だけで何も生み出さない奴。
0575デフォルトの名無しさん2010/04/18(日) 14:47:09
>>574
自己紹介乙
0576デフォルトの名無しさん2010/04/18(日) 14:47:34
>>574
人類の９５％以上はそのタイプ。
0577デフォルトの名無しさん2010/04/18(日) 14:48:42
>>575
悔しがりすぎｗ
0578デフォルトの名無しさん2010/04/18(日) 14:49:28
>>577
お前が生み出した物を紹介して欲しいんだけどｗ
0579デフォルトの名無しさん2010/04/18(日) 14:51:33
>>578
悔しがりすぎｗ
0580デフォルトの名無しさん2010/04/18(日) 14:52:53
いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。
0581デフォルトの名無しさん2010/04/18(日) 14:53:09
思考実験（笑）
0582デフォルトの名無しさん2010/04/18(日) 15:10:07
思考実験ｗｗｗ事実と反する仮定をもとに思考実験とかｗｗｗｗ
0583デフォルトの名無しさん2010/04/18(日) 15:23:49
>>580
悔しがりすぎｗ
0584デフォルトの名無しさん2010/04/18(日) 15:25:45
いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。
0585デフォルトの名無しさん2010/04/18(日) 15:25:59
>>582
君は剛体という存在を仮定することすら愚かというんだろうな。
教養のなさが染み出てるｗ
0586デフォルトの名無しさん2010/04/18(日) 15:27:31
いるよね「いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。
0587デフォルトの名無しさん2010/04/18(日) 15:30:36
while(1){
puts("悔しがりすぎ");
puts("何も生み出さない奴");
}
0588デフォルトの名無しさん2010/04/18(日) 15:34:18
いるよね「いるよね「いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。
0589デフォルトの名無しさん2010/04/18(日) 15:35:02
結局>>574が自分を棚に上げただけって話だったな。つまんね
0590デフォルトの名無しさん2010/04/18(日) 15:38:34
同属嫌悪って奴だろ
素直にネタも楽しめないつまんない奴なんだからそっとしておいてやれ
0591デフォルトの名無しさん2010/04/18(日) 15:41:00
他人を罵倒することでしか自己確認できない人が多いのが2ch
0592デフォルトの名無しさん2010/04/18(日) 15:42:21
メタなレスでスレを消費してもね
0593デフォルトの名無しさん2010/04/18(日) 15:43:28
抽象化したがるのがプログラマの性ですよ
0594デフォルトの名無しさん2010/04/18(日) 16:03:36
もう無責任にスレ立てを行った>>1が出てきて皆に謝罪しろよ
そうしてスレを落とせば、もう無駄な言い争いはしなくて済む
0595デフォルトの名無しさん2010/04/18(日) 16:05:52
有用なレスすれば言いだけ
0596デフォルトの名無しさん2010/04/18(日) 17:04:12
ネタすら投下できない無能は黙って去るべし
0597デフォルトの名無しさん2010/04/18(日) 17:17:25
>>596
お願いします
0598デフォルトの名無しさん2010/04/18(日) 17:35:46
しぃ言語って昔あったよな。
0599デフォルトの名無しさん2010/04/18(日) 17:48:28
ところで基本的質問で悪いんだが
Cってなに？
AとかBてのがあったの？
0600デフォルトの名無しさん2010/04/18(日) 17:55:46
ウィキペディアの「C言語」ぐらい読め
0601デフォルトの名無しさん2010/04/18(日) 18:13:55
>>599
BCPL->B->C
0602デフォルトの名無しさん2010/04/18(日) 18:33:45
STL相当のライブラリーは欲しいな。
0603デフォルトの名無しさん2010/04/18(日) 18:47:34
既にあるものが欲しいって、じゃあそれを使ってろよｗ
0604デフォルトの名無しさん2010/04/18(日) 18:50:09
1から作るのが難しかったら、
C ＋ STL ＋ 最新のオサレ機能
をベースにして、
新言語の言語仕様と標準ライブラリに整理し直したらいいかも。
0605デフォルトの名無しさん2010/04/18(日) 18:57:19
雑談スレだしw
でもここ見てると冷やかしと
低レベルが知らないヤツが多いのはわかるな
俺は低レベルはCで上はgc有りで
住み分けでいいと思うがね
消えるとするとやはりc++
0606デフォルトの名無しさん2010/04/18(日) 18:58:40
perfect forwardingって、名前がオサレだな。

C++以外でも意味ある？

C++の言語仕様が糞だから必要なのか、それ自体が他の言語でも有用な機能なのか。
0607デフォルトの名無しさん2010/04/18(日) 19:38:55
>>605
同感。でもＣもちょっと古すぎる。
１、charはbyteにして8bitアクセス
２、intはint8,int16,int32,int64
３、数値計算用にdouble　と　decimal（realとdecimalか？）
４、stringを文字列として導入
５、floatの廃止
６、#includeの廃止→代替案が必要
７、#ifdefの廃止→代替案が必要
８、互換性のためのラッピング関数に対して、コンパイラがラッピングをはずす
　　機能の提供。

後は、今ある言語をしっかり検討して、再設計するべきだと思おう
C++0xの説明少し読んだけど、悪夢？
とか思うほどに、なんか記号に満たされた感じだった。
ありゃもう駄目だと思う。読んでると、あぁこれは便利そうだとは
確かに思うのだけれども、もうね、記号がぐちゃぐちゃで文字化けかよ
って感じるほど酷いことになってる感じ。
0608デフォルトの名無しさん2010/04/18(日) 19:47:22
floatの廃止とか正気か？
グラフィック関連でどれだけ使われまくってると思ってんだ
0609デフォルトの名無しさん2010/04/18(日) 19:47:39
1-5までは別に言語とかコンパイラとか関係なく対応出来る
というかもうしてるのもあるよな。
0610デフォルトの名無しさん2010/04/18(日) 19:48:11
>>607
やはりDでいいな
0611デフォルトの名無しさん2010/04/18(日) 19:48:53
stringがライブラリである意味がわかってない奴が語るなよ
0612デフォルトの名無しさん2010/04/18(日) 19:55:15
後置構文は賛成
:でいいと俺も思う

>>457 >>473
あたりの話はもう終わりなのか
0613デフォルトの名無しさん2010/04/18(日) 19:55:44
>>607
C++0xは、個々の機能をみると、今までより簡単になったり分かりやすくなったりしたと思えるけど、
全体としてみれば、「ただでさえ複雑な言語がますますややこしくなった」という風に見える。

ところでfloat廃止はいただけないなあ。
今時みんなIEEE 754なんだから、単精度・倍精度に対応する型は必要。
もちろん、float/doubleという名前はぜったいだめだけど。
0614デフォルトの名無しさん2010/04/18(日) 19:56:46
> もちろん、float/doubleという名前はぜったいだめだけど。
なんで？
ダサくていまどきモテないから？
0615デフォルトの名無しさん2010/04/18(日) 19:58:21
>>608
単精度はサウンド関係でも使われまくってるよね
0616デフォルトの名無しさん2010/04/18(日) 20:11:37
float廃止って、素人だろ
遅いとか思ってるんだろうな
0617デフォルトの名無しさん2010/04/18(日) 20:18:25
>>614
その名前でfloat:主 double:従のような印象を受ける。
くだらないと思ったらすまない。

代替としては、例えばdouble→real、float→short realなど。
607のintXXに従うならfloat32/float64もありかな。
0618デフォルトの名無しさん2010/04/18(日) 20:22:30
>>617
それを言いたかったんだけど、そうだよね、
ダブル残すのはセンス無さ過ぎた（ｗｗｗｗｗ

なんのダブルなんだよって事だよな
0619デフォルトの名無しさん2010/04/18(日) 20:44:40
その命名理由はもっともだが、そんなもんどうでもいいだろうとw
0620デフォルトの名無しさん2010/04/18(日) 20:50:58
>>607
stringはライブラリちうか動的メモリ管理必須だってばさ
gc無しの前提だからな
でなきゃおまいの書いたのは
go始め実現してる言語は多いぞ
0621デフォルトの名無しさん2010/04/18(日) 20:53:11
>>620
これわかってないの多いよね
0622デフォルトの名無しさん2010/04/18(日) 20:55:51
D言語に対するツンデレスレなんだよな
0623デフォルトの名無しさん2010/04/18(日) 20:56:51
>>617
fixedなんてのもあるぞ_Fixedだっけ
整数は長さ指定なのにrealはないだろ
実際にfloat-ing pointなんだし。
realならimaginaryと対じゃね
long floatとかdouble floatなんてのはありだが
0624デフォルトの名無しさん2010/04/18(日) 21:00:31
complexは必要だがimaginaryはいらん
掛け算するとrealになってしまう
0625デフォルトの名無しさん2010/04/18(日) 21:02:43
floatは一切なしという仕様もありえる。
0626デフォルトの名無しさん2010/04/18(日) 21:06:02
float32 と fixed32, fixed16 あたりは必要だろう
float32 は GPUとかSSE SIMDで使われているし fixed はfloating 演算できない組み込みプロセッサ用に重要だ
0627デフォルトの名無しさん2010/04/18(日) 21:08:14
C#のDecimalってfixed128みたいな感じだっけか
0628デフォルトの名無しさん2010/04/18(日) 21:15:33
>>624
そんな機能があること知らん奴のほうが多いだろ
多分日本語にしてもわんない奴多そう
0629デフォルトの名無しさん2010/04/18(日) 21:19:31
可変長でなければ文字列型に動的メモリ管理なぞいらんよ
つーか文字型を廃止して、全ての文字は「0文字以上の文字列型」とする
で、文字列型はネイティブで扱える文字コードをasciiとunicodeにするだけでいい
あとはCのchar配列のような扱いで十分
0630デフォルトの名無しさん2010/04/18(日) 21:19:46
complexいるかあ？
業務で複素数の演算が必要になったことなんてほとんどないぞ。
言語仕様でサポートするほどの需要があるとはとても思えない。
0631デフォルトの名無しさん2010/04/18(日) 21:20:22
>>628
中学数学のはずだが？
0632デフォルトの名無しさん2010/04/18(日) 21:21:31
>>630
例えば4次方程式を解くとかだな
科学技術系計算が必要だと便利だぞ
0633デフォルトの名無しさん2010/04/18(日) 21:21:40
アルゴリズムとして実装可能などうでもいい機能は放っておけ
0634デフォルトの名無しさん2010/04/18(日) 21:24:27
>>632
４次方程式なんて解く案件いくつあんだよ
0635デフォルトの名無しさん2010/04/18(日) 21:27:46
>>632
Fortran99とかMatlabとかでなく
Cで科学技術計算やりたいケースって結構あるの？
0636デフォルトの名無しさん2010/04/18(日) 21:27:49
Cで科学技術計算はかなりされているし、メモリ管理も関係ない。実装も簡単。
complex型はありだ。ただし、ライブラリはCと互換性なくなる。
0637デフォルトの名無しさん2010/04/18(日) 21:29:25
また一人が必死に繰り返してるパターンか
0638デフォルトの名無しさん2010/04/18(日) 21:30:09
確かにcomplexはいらないと思う imaginaryが欲しいというのにネタレスしただけです
0639デフォルトの名無しさん2010/04/18(日) 21:32:19
>>634
俺はプログラマじゃないからな
この手の計算は年がら年中あるよ
0640デフォルトの名無しさん2010/04/18(日) 21:35:13
maximaとかmathematica使わんの？
0641デフォルトの名無しさん2010/04/18(日) 21:35:32
自分の知っている範囲を世界の全てと思い込むのは愚かなことだ
0642デフォルトの名無しさん2010/04/18(日) 21:41:39
>>640
遅いから駄目
大量データモンテカルロを高速にやるとかの用途に不向き
0643デフォルトの名無しさん2010/04/18(日) 21:44:22
C99にはcomplexもimaginaryもあるよ
0644デフォルトの名無しさん2010/04/18(日) 21:45:40
C99に代わる言語ってSFでもむずかしいよ
0645デフォルトの名無しさん2010/04/18(日) 21:47:50
complex型いらないけど、文字列型は必要なんていっているのは、まったくわかっていない。
0646デフォルトの名無しさん2010/04/18(日) 21:48:31
C99は普及率がイマイチ、やっぱ普及率って大切だな
新言語ってどんだけ優れてれば良いんだろう。文字列型は便利
0647デフォルトの名無しさん2010/04/18(日) 21:51:09
C/C++で実数のデフォルトはdoubleってことを分かってないのが多いな。
0648デフォルトの名無しさん2010/04/18(日) 21:53:02
>>647
分かってるとなんかいいことあるのか？
いいこと書いてみな
0649デフォルトの名無しさん2010/04/18(日) 21:53:51
>>647
デフォルトの意味がよくわからないが、doubleに変換して計算という仕様は変わった。
0650デフォルトの名無しさん2010/04/18(日) 21:56:14
charのデフォはunsignedにすべき
そもそもcharって名前が悪いからuint8_tでもbyteでもいいけど
0651デフォルトの名無しさん2010/04/18(日) 21:59:06
>>650
昔はその処理系も多かった。signedは、その名残。
Javaは、byteもsigned。
0652デフォルトの名無しさん2010/04/18(日) 22:00:50
虚数が中学か。すげえ天才じゃね
0653デフォルトの名無しさん2010/04/18(日) 22:05:04
>>651
ctypesのマクロに渡すときとか
符号拡張避けたい時にいちいちunsigned charにキャストしないといけなくて
ムカムカするんだよね

signed charでいいと思えることなんて一つも無い
全くASCIIのことしか考えてない馬鹿共は
0654デフォルトの名無しさん2010/04/18(日) 22:10:18
>>473

auto,externはいらないに賛成。
static関数はprivateにしたい。
メンバアクセスは.だけいけるところまで行けばよいと。
->は別機能用に使うとよいかと。
0655デフォルトの名無しさん2010/04/18(日) 22:12:41
整数とかfixedでもサチるやつと
回っちまうやつがあってもいいな
0656デフォルトの名無しさん2010/04/18(日) 22:13:54
octet型も欲しい所だ
0657デフォルトの名無しさん2010/04/18(日) 22:20:46
ビット演算周りの演算子優先順位は見直して欲しい
0658デフォルトの名無しさん2010/04/18(日) 22:23:51
>>657
それは初期から指摘されているが、この間違った優先順位を変えるのはもう遅い。
やるなら記号も変える。
0659デフォルトの名無しさん2010/04/18(日) 22:26:12
bit string (短い範囲で)と連結演算子ぐらいは欲しい
0660デフォルトの名無しさん2010/04/18(日) 22:30:02
なんかワーニングオプションの要望ばっかだな
0661デフォルトの名無しさん2010/04/18(日) 22:41:45
言語の規定に warning はウォーニングと読むと明記して欲しい。
0662デフォルトの名無しさん2010/04/18(日) 22:43:44
/awrg?n/
0663デフォルトの名無しさん2010/04/18(日) 22:48:05
今の段階で型云々言うなよ。演算子も早過ぎるだろ。

そもそも型システムと型関係の機能はどうすんだよ。
関数・演算子呼び出し一つとっても、型による多態／パターンマッチング／動的・静的とか
考えることたくさんあるのに。
0664デフォルトの名無しさん2010/04/18(日) 22:55:52
http://www23.atwiki.jp/newclang/

wikiなくなったので立ててみました。
まとめようと思っているのだけど、どうしたらまとまるんでしょうね？
構造をどうしたらいいのか悩む。
前スレとかのデータあったら教えて欲しいです。
0665デフォルトの名無しさん2010/04/18(日) 22:56:52
>>661
あっそれ欲しいｗ
ワーニングとかバカかよと思う。
0666デフォルトの名無しさん2010/04/18(日) 22:58:50
くだらね
0667デフォルトの名無しさん2010/04/19(月) 01:13:42
ウォーニン
0668デフォルトの名無しさん2010/04/19(月) 01:24:49
全部英語表記にしろ
0669デフォルトの名無しさん2010/04/19(月) 01:47:34
ウォーニング の検索結果 約 122,000 件中 1 - 10 件目 (0.12 秒)
ワーニング の検索結果 約 147,000 件中 1 - 10 件目 (0.20 秒)

star wars スターウォーズ
warp ワープ

ぶっちゃけどっちでもよくね
0670デフォルトの名無しさん2010/04/19(月) 02:13:50
アルトラマン
0671デフォルトの名無しさん2010/04/19(月) 02:57:51
スクールワーズ
0672デフォルトの名無しさん2010/04/19(月) 08:18:43
SFで普及してしまった「ワープ」が諸悪の根源。
あれが「ウォープ」でありさえすれば...
0673デフォルトの名無しさん2010/04/19(月) 08:27:11
>>669
野村克也「人間の最大の罪は鈍感であることだ」
0674デフォルトの名無しさん2010/04/19(月) 08:43:39
言語的に無理
0675デフォルトの名無しさん2010/04/19(月) 08:44:51
>>664
これ見たけど型の種類多すぎじゃね？

octetは数値を扱うためじゃなくてビット操作用なんだから8bit1つのみで十分。当然符号もいらん。
その代わりビットオーダー、配列にしたときのバイトオーダーを厳格にすればいい。

整数型はsintとuintがいいんじゃないか？符号を明示しない場合、潜在的な環境依存を含むことになる。
極少数の実装者が困るより、多数のプログラマが困るほうがより邪悪だ。

あとbooleanがないな。
0676デフォルトの名無しさん2010/04/19(月) 10:14:18
>>673
アップル→アポー
ゼロ→ズィーロウ
エッチ→エイチ
ガラス→グラス
ヒレ肉→フィレ肉
とかそんな感じで以後よろしく

ウォーニングを正しい発音だと思ってる俺カコイイとか
どこの中二病だよ
0677デフォルトの名無しさん2010/04/19(月) 10:17:33
>>685
octetという要望が出てくるのは、歴史的には
8bit=1byte=charな計算機ばかりじゃなかったからじゃないのかな
多分

というか、Wikiにまとめられてるのを見ると
カオスっぷりというかネタっぷりというか
ただの雑談をまとめるとこうなる、というレベルの低さが際立つなーと
俺は改めて思った
0678デフォルトの名無しさん2010/04/19(月) 10:47:46
>>676
あんた、さすが! カコイイね!!
0679デフォルトの名無しさん2010/04/19(月) 10:49:58
>>676
ワーニングを気持ち悪いと思わないほどの鈍感な奴には何を言ってもムダだな
0680デフォルトの名無しさん2010/04/19(月) 10:50:24
>>679
お前は今後ウォープでアルトラマンな
0681デフォルトの名無しさん2010/04/19(月) 10:52:14
あと、「グ」を気持ち悪く思わない時点でもう土着日本人だから
0682デフォルトの名無しさん2010/04/19(月) 10:55:07
言語の話しろよw
ウォーニング単体の話に他の話を混ぜてどうにかしたい人がいるということぐらいしかわからん。
0683デフォルトの名無しさん2010/04/19(月) 10:55:44
なんでそんな必死にワーニングを擁護するんだろう
0684デフォルトの名無しさん2010/04/19(月) 10:57:17
その人のアイデンティティーか何かなんだろう。
三つ子のワーニング、百まで。
0685デフォルトの名無しさん2010/04/19(月) 11:04:13
>>683
べっべつに必死でワーニングの擁護なんてしてないんだからね！

マジレスすると、ぐぐってワーニングのほうが多いほど定着してて
意味が通じないわけでもない用語に今更ケチつける意味が理解できない
しかも「2chで」だ
んなもんどっちでもいいだろ

つーかこの手の議論はfjのvoidでさんざん見飽きたわ
0686デフォルトの名無しさん2010/04/19(月) 11:07:24
>>685
だからそういう、みんなが言ってるんだからいいじゃん、ていう考え方を鈍感って言ってんだろうが
0687デフォルトの名無しさん2010/04/19(月) 11:08:41
>>686
いやだから、お前は自分の信念に基づいてウォープとかアルトラマンとか
言ってれば？
俺は止めないから
0688デフォルトの名無しさん2010/04/19(月) 11:12:21
なんでワーニングの話なのに別の単語を必死で持ち出すんだろう
0689デフォルトの名無しさん2010/04/19(月) 11:13:16
>>688
馬鹿にも分かるように言うと
war
warp
warning
全部warの部分の発音が一緒だから

ワープは良くてワーニングがダメなおまえさんの理由を言ってみな？
0690デフォルトの名無しさん2010/04/19(月) 11:14:59
話を摩り替えてることに自分で気づいてないらしい
0691デフォルトの名無しさん2010/04/19(月) 11:15:17
Honesty is such a lonely word
アーネスティ　サッチャ　ロウンリ　ワード
0692デフォルトの名無しさん2010/04/19(月) 11:16:00
そのうち全ての英単語はカタカナで表記できないと言い出す方に１０００カノッサ
0693デフォルトの名無しさん2010/04/19(月) 11:17:32
誰か
> ワープは良くてワーニングがダメなおまえさんの理由を言ってみな？

これに答えられないの？
0694デフォルトの名無しさん2010/04/19(月) 11:19:30
誰ひとりそんなことを言ってない件
0695デフォルトの名無しさん2010/04/19(月) 11:20:11
んじゃあ、なんで「ワーニング」をキモいと思うべきで
そう思わないのは鈍感で

「ワープ」との違いは何なの？
0696デフォルトの名無しさん2010/04/19(月) 11:22:00
どんどん違う単語を出せば永遠に逃げられますよね
0697デフォルトの名無しさん2010/04/19(月) 11:23:41
要するに、合理的な理由を一人も説明できないけど
中二病だからケチだけはつけたいってことでおｋ？

・発音が同じ
・表記の仕方も同じ
・定着してるからみんな使ってるということも同じ

だから「ワープ」の例を上げてるんだけど
そんなことも分からないほど馬鹿なの？
0698デフォルトの名無しさん2010/04/19(月) 11:44:39
ワーニング娘。はワーワーワーワー
0699デフォルトの名無しさん2010/04/19(月) 12:51:55
定着度合いが圧倒的に違う例を出してバカが必死、としか見えない。
0700デフォルトの名無しさん2010/04/19(月) 12:54:25
charをチャーと呼ぶかキャラと呼ぶかみたいなもんだろ
0701デフォルトの名無しさん2010/04/19(月) 12:56:16
チャラ
0702デフォルトの名無しさん2010/04/19(月) 13:08:17
>>700
英語人はキャーorカーな
0703デフォルトの名無しさん2010/04/19(月) 13:10:07
あとチャーもあるな
0704デフォルトの名無しさん2010/04/19(月) 13:23:48
>>702
カーだとLispのcarと紛らわしいな
0705デフォルトの名無しさん2010/04/19(月) 13:36:56
>>697
アルトラマンは無かったことになったんですかｗ
0706デフォルトの名無しさん2010/04/19(月) 13:43:31
>>669
「定着」って数の論理は認めるんだろ
なら今更ダダこねてももう無駄だから諦めろ
ずっと前から「ワーニング」は使われてしまっていて、グーグルでも
「ワーニング」のほうが多い
幸い「ウォーニング」も多いから、「ウォーニング」を使いたい奴は
こっちを使えるが
日本語としては本来「警告」で済む話だ
0707デフォルトの名無しさん2010/04/19(月) 13:49:46
なんでそんな必死なの
0708デフォルトの名無しさん2010/04/19(月) 13:50:27
俺がド厨房な上に、虫の居所が悪いからさ
0709デフォルトの名無しさん2010/04/19(月) 14:06:20
おまいらアホやな
発音記号で出力したら無問題
0710デフォルトの名無しさん2010/04/19(月) 14:07:52
ウァーニングでいいじゃん
0711デフォルトの名無しさん2010/04/19(月) 14:17:48
ウボァー
0712デフォルトの名無しさん2010/04/19(月) 14:33:24
>>709
Unicode使うにしても
タイプすんのめんどい
0713デフォルトの名無しさん2010/04/19(月) 14:44:26
>>712
ネタにマジで返すところがおまえの限界
0714デフォルトの名無しさん2010/04/19(月) 14:45:56
デフォの文字列リテラルをUCにするオプションは欲しいな。
0715デフォルトの名無しさん2010/04/19(月) 15:33:32
wɔːɼniň
ŋ
0716デフォルトの名無しさん2010/04/19(月) 15:34:17
wɔːɼniŋ
0717デフォルトの名無しさん2010/04/19(月) 17:16:51
octetに加えるならbigendianとlittleendian装飾もほしいな
普通に
bigendian uint16_t netdata;
uint16_t data;
if (data > netdata) ...
ローレベル言語チックじゃねえか
0718デフォルトの名無しさん2010/04/19(月) 17:18:00
ロベール？
0719デフォルトの名無しさん2010/04/19(月) 17:19:22
関数を装飾化する定義構文があれば全部解決するんだろうか？
0720デフォルトの名無しさん2010/04/19(月) 17:20:11
口ｩレヴル
0721デフォルトの名無しさん2010/04/19(月) 17:26:30
>>717
ちょっと面白いけど
byteswap系の関数やhtonl()の類を標準ライブラリで提供してくれれば
十分な気がする
0722デフォルトの名無しさん2010/04/19(月) 17:31:25
>>721
半分はネタのつもりだが
hton系は型セーフじゃないし、両方同じの使っちゃう奴もいたりするし
I/OなんかでもBig系Little系があったりするし面白いかなと
0723デフォルトの名無しさん2010/04/19(月) 19:17:03
ロゥレヴォゥ
0724デフォルトの名無しさん2010/04/19(月) 20:40:04
一気に糞スレになったな
0725デフォルトの名無しさん2010/04/19(月) 20:42:43
一瞬でも糞スレじゃなかった瞬間があったかよ
0726デフォルトの名無しさん2010/04/19(月) 21:31:13
俺思うんだけど、ＣＰＵの実装の違いを隠蔽するような、
低水準高級言語というアプローチが、Ｃの最大の欠点だと
思うんだよね。も乳論、誤変換だけど面白いからそのままで、
もとい、もちろん、当時の技術水準とかコンパイラの大きさ
という問題が有ったのは確かなんだけどさ。

インテルの浮動小数点は、80bitなんだし、余所のＣＰＵは
64ビットだったりするわけじゃん、これはこのままで良いと思う。
大切なのは、コードを移植するときに安全確実にその問題を把握
出来るか？ところで、ライトワンスは求めちゃいけないと思う、
というかそう言うのは、他の人たちがやってるから、もの凄い
便利な機械語、アセンブラ、というアプローチで行くべきだと思うんだ。

もろちん意図的に打ち間違ったけどそのまままで、
まとい、また意図的に打ち間違ったけどこのままで、

もちろん、文字列とかいちいちアセンブラレベルで作るのは面倒なので、
標準関数で処理するべきだと思うんだけど、そういうアプローチで行くべき
だと思うんだ。

ＳＩＭＤとか、各社各様に出てるのを上手いこと使いやすくするって言う
アプローチで言語設計した方が良いと思う。
0727デフォルトの名無しさん2010/04/19(月) 21:37:10
アセンブラ使ってろよ
86が一番多いと思ってんの？
0728デフォルトの名無しさん2010/04/19(月) 21:41:53
インテルはfpuやめてsse2に移りつつあるよ
0729デフォルトの名無しさん2010/04/19(月) 21:42:59
面白いと思ってんの？
0730デフォルトの名無しさん2010/04/19(月) 21:47:43
だいたい当時の技術水準とかあまく見過ぎ
0731デフォルトの名無しさん2010/04/19(月) 21:49:56
Aという機械に合わせてバイナリを吐くのはA用コンパイラの仕事だと何度言えば
0732デフォルトの名無しさん2010/04/19(月) 21:50:06
具体的に言うと、８bitＣＰＵでも16bitＣＰＵでも
intはintだったのが、Ｃ言語の混乱で、int8だったら
良かったんだよね、でもこれじゃあ、16bitへ移植するときに
int8をint16へエディターで変更しなきゃならない。
一括置換でいけるとは言えるんだけど、それで良いのかって
言えばそうでもなかったりするとは思うんだ。

そこで、提案なんだけど、ＣＯＢＯＬからEnviroment Divisionを
持ってきて、そこに様々な環境固有情報を記述して、コンパイラに
状況を設定させると言うアプローチはどうだろうか？

ENVIRONMENT DIVISION.
ORIGNAL SOURCE SECTION.
　　charctor set ＥＵＣ＿ＪＰ.
　　double intel_80bit.
END-DIVISION.
こう書いてあれば、"初めまして"という二重引用符の間は
ＥＵＣ＿ＪＰで記述されているって言う事ね。

で例えば、ＵＴＦ−８の環境でコンパイルしたいなって時は、
ワーニングモードを設定して、オリジナルソースをそのまま
コンパイラに喰わしてやると、
string buf1[8];
char buf2[17];

buf="１２３４５６７８";　←これはＯＫだけど
strcpy(buf2,"１２３４５６７８");これはコンパイルエラーになる。
memcpy(buf2,"１２３４５６７８",17);これはＯＫだけど警告が出る

っていうことが出来る言語設計があれば良いと思うんだよね。
0733デフォルトの名無しさん2010/04/19(月) 21:54:39
>>731
だからそう言うアプローチで言語を最大公約数的に言語を設計するのは
もうね、限界だし、他の人がやってるし。
面白くないじゃん。せっかく色んなＣＰＵが有るんだし。

>>727
だから、アセンブラ使っちゃえで終わるかどうかってところなんだよね。
やっぱりプログラミング規模が大きくなると見通し悪いしさ。
低水準高級言語というアプローチは大切にしたいじゃない。
このアプローチが大正解だったので、未だにＣ言語は廃れないし。
0734デフォルトの名無しさん2010/04/19(月) 21:56:28
いやいや最新の技術を使って
xmlで定義だろ
0735デフォルトの名無しさん2010/04/19(月) 21:58:11
で、言語というアプローチも大切なんだけど、コンパイラーという
部分の役割も大きくなって来るというか、コンパイラーを意識した
（コンパイル出来るとかだけなじゃなくてもっと具体的に意識した）
言語設計というアプローチになると思うんだよね。

ンで、具体的に言うとllvmがこれを意識してる訳じゃないけれども、
この辺の課題を解決するために、この辺の課題を意識した設計になってる
でしょ、だからこういうアプローチを言語設計に持ってくる言語設計も
可能な時代なんじゃないのかなって思うのですよ。
0736デフォルトの名無しさん2010/04/19(月) 22:03:02
>>733
最後の一行だけで話終わったな
論理が支離滅裂だし知識も無茶苦茶だし
ネタならもうチョイ練ってくれ
0737デフォルトの名無しさん2010/04/19(月) 22:05:40
馬鹿すぎ。コンパイラを意識していないコンパイル型言語なんて無い。
一件不合理に思える言語仕様も、コンパイルの速度や最適化の効率などを考えて作られてる。
きちんと最適化までする実用に耐えるコンパイラを作ったことがなきゃ、言語なんてできっこない。

結果として言語仕様は実装に縛られないものができたとしても、
実装を意識せずに作られた言語は無い。
0738デフォルトの名無しさん2010/04/19(月) 22:08:49
>>737
文盲がそう言うレスを付けるだろうなって思ってた。
いつもの文盲さんこんにちは。なんで２ｃｈには
どのスレ行っても、君のような文盲がいてるんだろ？
0739デフォルトの名無しさん2010/04/19(月) 22:11:08
>>734
結果ＸＭＬという話は出てくると思うけど、
まぁそう言うことなんだよね。最小公倍数というか
公倍数的なアプローチを行うよ、という言語設計。
でも、いきなりにＸＭＬとか言い出すと、ＸＭＬみたいに
なんか定義定義ばかりで話が進まないとは思う。
0740デフォルトの名無しさん2010/04/19(月) 22:12:24
2chでは思考や思想が並列化されてるからな
スタンドアローンコンプレックス現象ってやつだわさ
>>738みたいなレスも何度か見たことあるし、あるいは俺も書きこんだことがあるかも
0741デフォルトの名無しさん2010/04/19(月) 22:17:29
昔設計された言語は、コンパイラのことあまり考えられていないね。
COBOLとかPL/I
0742デフォルトの名無しさん2010/04/19(月) 22:19:57
>>739
公倍数て…あんたそりゃ高級言語の思想だよ
基準を最上位に持っていこうとするのが公倍数、つまり高級言語
基準を最低位に持っていこうとするのが公約数、つまり低級言語

根本から目指してるものがずれてる
0743デフォルトの名無しさん2010/04/19(月) 22:22:16
>>737
Cは最適化からかけ離れた言語だけどね。
0744デフォルトの名無しさん2010/04/19(月) 22:24:35
>>739
皮肉なんだが。。。
0745デフォルトの名無しさん2010/04/19(月) 22:26:22
>>743
ポインタは鬼門だあな
でも手動で最適化するなら最高だが
0746デフォルトの名無しさん2010/04/19(月) 22:27:26
明示されない限りポインタはデフォルトでrestrictにしてほしいな
0747デフォルトの名無しさん2010/04/19(月) 22:27:42
そういや99にはrestrictがあるな
0748デフォルトの名無しさん2010/04/19(月) 22:28:26
>>743
代わりに、コンパイラが最適化しなくても人力で最適化出来るようになっているね。
おかげで、手っ取り早くコンパイラの実装が出来る。
0749デフォルトの名無しさん2010/04/19(月) 22:29:28
>>746
難しいだろな
restrict自体危ないと思うんだよな
0750デフォルトの名無しさん2010/04/19(月) 22:38:33
いわば最適化が目的の小細工に過ぎないからな
0751デフォルトの名無しさん2010/04/19(月) 22:41:31
>>744
皮肉で俺の言ってる真意を理解していないことは知ってるけど、
でも、まぁ、文盲よりは理解してると思ったので。

つまりそう言うことなんだよね、ＸＭＬで抽象化するアプローチと
原理的、思想的に、似てる部分は有るんだよ。
そう言うことを言ってるので、君は皮肉として書いたとしても、
皮肉にならないんだよね、そこまで理解した上で書かないと皮肉に
ならないと言うこと。知性の圧倒的な量の違いで君のちっぽけな
脳みそと感情から皮肉だとしても、そして俺はそれを理解したけども、
君がどうなろうと俺の人生にはまったく関わらないので、>>739を
書いた。とこれだけかみ砕いても君には理解できない世界の話。
0752デフォルトの名無しさん2010/04/19(月) 22:52:56
じゃあ知性が足らないから訊くが
あんたのイメージに今一番近い言語はなんた？
バックエンドの仕事を設計に持ち込んだ言語なんて不要だし
llvmってなにかしってる？

わり。ネタにならないネタに反応しちまったよ
0753デフォルトの名無しさん2010/04/19(月) 22:54:06
>>751をもう放っておいてやれよ！
可哀相だろ！先生に言いつけるよ！！
0754デフォルトの名無しさん2010/04/19(月) 23:07:36
>>752
今、イメージに一番近いのは、llvmの中間表現。
これをもう少し人間が使いやすい形に出来ないのかな？
という発想と、それをするとソースのポータビリティが
無くなってしまうけども、それはそれで良いのではないか、
そもそもソースにポータビリティなど求めるのは違うのではないか？
と言う疑問点から落としどころ模索するべき、じゃないかという話。
0755デフォルトの名無しさん2010/04/19(月) 23:08:21
組み込みやってたらいつも思うんだけどさ、2進数の数も扱えるようにして欲しいんだよね。
あとビット演算ももっと強化できるはず。
0756デフォルトの名無しさん2010/04/19(月) 23:13:40
1bitの型があればいいんだけどな。
最適化でいくつかのbit型をまとめてbyteで処理したりできそう。
0757デフォルトの名無しさん2010/04/19(月) 23:23:04
>>756
遅くなる、ビットフィールドがある、バイナリ互換性で問題が出る。
0758デフォルトの名無しさん2010/04/19(月) 23:26:10
>>753
わかったよw

>>756
つvhdlw

bitはビットフィールドでいいが
数値の2進表記はほしいね
0b01010101みたいな
0759デフォルトの名無しさん2010/04/19(月) 23:27:34
>>755
<<,>>で回るヤツ位は欲しいよね
0760デフォルトの名無しさん2010/04/19(月) 23:34:12
ライブラリの話になっちゃうけど
stdioでfunopen()/fmemopen()の類は標準にしてほしい
そのうえで、stdioをbitstreamとしても使えるといい
getbits()
putbits()
みたいな感じで
0761デフォルトの名無しさん2010/04/19(月) 23:37:28
>>757
型安全であればコンパイラがビットをどのように扱おうと気にする必要はないのでは。
気になる人は最初からバイトで扱えばいいだけだし。
0762デフォルトの名無しさん2010/04/19(月) 23:38:06
>>755
仕様書見てそのままビットパターンを書き込めたら楽だよねえ。
0763デフォルトの名無しさん2010/04/19(月) 23:39:06
>>758
そういう表記方法を定義する一般的な方法を定義するにはどうすればいいだろう？
0764デフォルトの名無しさん2010/04/19(月) 23:41:03
>>762
pragmaで制御できるコンパイラもあるんじゃないか
0765デフォルトの名無しさん2010/04/19(月) 23:42:09
>>748
手動最適化は今や最適化の邪魔にしかならないけどな。
0766デフォルトの名無しさん2010/04/19(月) 23:42:27
C言語に足りないのは型安全性なんだよな。
型理論でカチカチに作り直したい。
0767デフォルトの名無しさん2010/04/19(月) 23:45:02
>>763
決めちまえばしまい
会議のルールを決める会議はいらない
再帰するだけ
0768デフォルトの名無しさん2010/04/19(月) 23:45:15
>>765
そこが、Cらしいところじゃない。
0769デフォルトの名無しさん2010/04/19(月) 23:46:16
>>766
具体的に、どういうものが安全ではないのですか？
0770デフォルトの名無しさん2010/04/19(月) 23:47:33
>>767
それだったら言語が普及してからこんな記法があったら良かったのにね、
ってことになって不満要素になるだろ。
それだったら、後で仕様変更が簡単になるようにメタ記法を考えた方が後の人のためになるでしょ。
0771デフォルトの名無しさん2010/04/19(月) 23:48:23
>>765
手動でオプティマイザを導いてやるなんて普通だろ
試して遅いなら戻すだけ
ダメダメなコードは頑張ってもやっぱしダメダメだし
0772デフォルトの名無しさん2010/04/19(月) 23:50:32
>>758
ってあるじゃん！ GNU 拡張！
http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html

って使ってみようとしたらないじゃん！
http://gcc.gnu.org/gcc-4.3/changes.html

くそ〜、4.3からか。　今仕事で使っているの4.1だから使えねえええ。
0773デフォルトの名無しさん2010/04/19(月) 23:51:18
>>770
んで書く人毎に違う何かが出来るわけだ
言語設計で決めちまえばしまいじゃん
0774デフォルトの名無しさん2010/04/19(月) 23:52:41
>>772
おう。知らんかった！
このスレで始めて有益な情報がw
0775デフォルトの名無しさん2010/04/19(月) 23:53:32
>>773
デフォルトを言語仕様で決め、後で違う記法も追加できる、という仕様が望ましいな。
0776デフォルトの名無しさん2010/04/19(月) 23:55:15
言語仕様は決め事だからね
追加はまた後で！でいいんちゃう
メタな機能は黒魔術に陥る危険が危ないよ
0777デフォルトの名無しさん2010/04/19(月) 23:57:27
マクロなlispマジック大好きなんだけどな。
0778デフォルトの名無しさん2010/04/20(火) 00:03:32
魔法のコードは
書いたヤツよりレベルが低いヤツには理解不能で
上のヤツには鼻で笑われるのが落ち
0779デフォルトの名無しさん2010/04/20(火) 00:20:08
新言語では少し練習すれば誰にでも最上級の魔法を使えるようにしたい
0780デフォルトの名無しさん2010/04/20(火) 00:23:11
目的が違うだろそれは
0781デフォルトの名無しさん2010/04/20(火) 00:37:10
>>769
例えばchar型に関していえば、
それが単なるバイトとして扱われているために、
数値も文字もゴッチャに扱われる。
0782デフォルトの名無しさん2010/04/20(火) 00:37:14
魔法は目的ではなく手段だ。
0783デフォルトの名無しさん2010/04/20(火) 00:37:19
mahaですね。わかります
0784デフォルトの名無しさん2010/04/20(火) 00:39:50
>>778
そんなことありません。鼻で笑う人は心が病んでいるのです。

>>776
Haskellなんか昔と今では仕様がガラッと変わったけど、
コアの仕様は何も変わってないよ。
なぜなら、仕様のほとんどがメタ機能で出来ているから。

ちなみに、厳密に言えば関数もメタなんだよ。
0785デフォルトの名無しさん2010/04/20(火) 00:40:29
reg [7:0] uint8;
reg [15:0] uint16;
reg [31:0] uint32;
0786デフォルトの名無しさん2010/04/20(火) 01:05:28
メタ機能は死んでくださーい
0787デフォルトの名無しさん2010/04/20(火) 01:14:38
強い静的型付けこそ正義だよな
あとLispみたいな〜って議論が結構あるが、
ラムダ関数を演算子化すればおｋじゃね？
0788デフォルトの名無しさん2010/04/20(火) 01:14:47
>>785
VHDL乙
0789デフォルトの名無しさん2010/04/20(火) 01:18:37
>>787
無名で関数定義するだけなら害はないよな
でもクロージャとか欲しくなると
ローレベルでは難しくなる
0790デフォルトの名無しさん2010/04/20(火) 01:24:35
>>788
Verilogだけどな。
0791デフォルトの名無しさん2010/04/20(火) 01:37:50
スタックマシーンでクロージャーって実現できないの？
0792デフォルトの名無しさん2010/04/20(火) 01:45:56
wikipediaの"クロージャ"の"実装"を見たらなんとなくわかるよ
0793デフォルトの名無しさん2010/04/20(火) 01:49:23
いや、今ある一実装を知りたいわけじゃないんだけど。
0794デフォルトの名無しさん2010/04/20(火) 02:04:48
>>787
強い静的型付けでないと、バグ追跡が難しくなるんだよね。
charに整数も文字も入れて使う場合でも、
整数型と文字型を分けて相互に型変換して使う場合でも、
どっちにしても結局は簡単な最適化で同じ結果になるんだから、
非効率ということはないだろうしね。
0795デフォルトの名無しさん2010/04/20(火) 07:44:20
>>794
その辺りが時代錯誤ということなんだよね
文字も内部では数値だから数値扱いのほうが(機械にとって)効率的→うん確かにその通り
でも使うのが人間である以上やはり文字列型は文字のみを扱えるべきなんだよ
0796デフォルトの名無しさん2010/04/20(火) 07:58:36
型宣言だけ強制と言うのも変な話だよね。
他のassertと同様任意でいいんじゃないかな。
0797デフォルトの名無しさん2010/04/20(火) 08:01:16
低レベルな用途には文字列なんてオマケ
gc前提なら他言語で普通にある
メモリ管理なしな文字列型で
結合すら出来ないならいらん
てこと。
0798デフォルトの名無しさん2010/04/20(火) 08:06:38
>>797
sprintf()
0799デフォルトの名無しさん2010/04/20(火) 08:09:14
>>795
と、言うか、文字列とバイト列は違うもんだし、
文字列やバイト列にサインは必要ないんだよね。
これを数値と同等に扱うのは本当に無意味な言語仕様
だと思う。

>>797
ＧＣが無くても文字列は扱えるんだよ。
ＧＣが有っても1024桁の数値は扱いにくいのと同様。
色々勘違いしてるので面白いと思う。
0800デフォルトの名無しさん2010/04/20(火) 08:18:00
別の言い方をすれば「数値であることが隠蔽されている」のが望ましい
そうでなくても文字コードは1byteのASCIIだけじゃないんだから数値演算で文字を扱えるのはおかしい
0801デフォルトの名無しさん2010/04/20(火) 08:20:46
>>799
勘違いね
多分お互い低レベルの意味が違うんだろ
メモリ管理なしの文字列なら
今のCのchar配列以上にはならんよ
例が無意味過ぎ
0802デフォルトの名無しさん2010/04/20(火) 08:23:46
>>801
可変長文字列型を頭から捨てろよｗ
0803デフォルトの名無しさん2010/04/20(火) 08:30:47
>>802
固定長ならchar []と変わらんだろw
文字コードとか持ち込むとややこしくなるし
0804デフォルトの名無しさん2010/04/20(火) 08:33:31
ま、文字列とバイト列が違うといいたいのはわかるが
gc無しでは型を分けるメリットが薄いでしょ
0805デフォルトの名無しさん2010/04/20(火) 08:34:26
>>803
もともと型安全の話をしてるんだが？
符号ありの1byte幅の数値ハイブリッドchar型で文字列を扱うのがおかしいって話
そこが解消されればchar[]のような使い方で何の問題もない
0806デフォルトの名無しさん2010/04/20(火) 08:55:33
>>804
ＣＰＵ依存型（言語仕様）
整数、実数、バイト、番地
ＣＰＵ非依存（ビルトイン）
ポインター、バイト列、配列
ＣＰＵ非依存（ライブラリ）
文字列型。

>>801
おまえ、本当にアセンブラ組んだこと有るのか？
それから、ＣとＣ++とＣＯＢＯＬとフォートランとＪＡＶＡ組んで
納品したこと有るのか？
0807デフォルトの名無しさん2010/04/20(火) 09:09:36
組んでって・・・
0808デフォルトの名無しさん2010/04/20(火) 11:21:43
rorだっけか。
ビット回転とか、上下4ビット交換とか
Ｃではインラインアセンブラになる命令の演算子が欲しいな。
対応できないアーキテクチャの時は
エラーを吐けば良いと思う。
0809デフォルトの名無しさん2010/04/20(火) 12:07:19
>>806
ねえ、オープンソース勢より品質の低いコード書いてる人って
何でそんなに業務アプリを作ったら偉いみたいな言い方をするのかな？
俺は業務アプリは書かない系の業界人だけど、
正直言ってソース公開できる奴はコードに相当自信がある奴だと思う。
自分のソースを晒すのってケツの穴を晒すようなもんだからね。
この業界で仕事でプログラミングしてる奴の95%は糞コードしか書けないと自信をもって言える。
0810デフォルトの名無しさん2010/04/20(火) 12:10:42
>>809
横から済まんがおまえの言ってることは支離滅裂だぞ
0811デフォルトの名無しさん2010/04/20(火) 12:33:01
業務で作ったソースは当然公開出来る場合と出来ない場合がある
ソースが公開出来ないのはまだマシで完成品を公開出来ないこともある
もっと言えば何を作ったか話すことすら禁じられている場合もある
0812デフォルトの名無しさん2010/04/20(火) 12:45:21
>>811
なにがなんでも書き込まなきゃ気が済まない人かよ。
議論がとっちらかるから、自重してよね。
ニフティじゃないんだから、そう言う話題なら腐るほど
別にスレがあるじゃない。

>>808
SIMD系の命令って言語仕様に組み込もうにも、ほとんどアセンブラに
なっちゃうから、アセンブラのまんまなんだよね。
でも、そろそろ、言語に組み込んでいった方が良いとは思う
＞対応できないアーキテクチャの時は
＞エラーを吐けば良いと思う。
その場合はソフトエミュレーションすれば良いと思うんだ。
ＣＰＵの性能を出し切れるけども、出せない場合はソフトえみゅ
この辺を見通しよく出来る言語が良いと思う。

ライトワンスは最初から諦めて、でも移植しやすい言語仕様。
そういう方向性が必要だと思う。


0813デフォルトの名無しさん2010/04/20(火) 12:50:54
そういう細かい機能は、Cなどの既存言語を拡張したらすむ話問題。
0814デフォルトの名無しさん2010/04/20(火) 13:03:03
>>813
>>1の主旨に沿う気が無いのなら、書き込まなきゃ良いのに。
拡張ではなく、そう言った問題を解決するために、ゼロベースで
考えようというのが>>1の主旨でしょ。
0815デフォルトの名無しさん2010/04/20(火) 13:35:41
まあ>>1の主旨ってのもデタラメだけどな。
現実にCがあるのに、Cが無かったとしてなんて考える意味ないし。
0816デフォルトの名無しさん2010/04/20(火) 13:37:48
>>814
ゼロベースだろうが既存の拡張だろうが、そんな細かいことは、ものができてからやればいいこと。
0817デフォルトの名無しさん2010/04/20(火) 13:44:25
>>815-816
そう考える人は別のスレに行けば良いだけ。
わざわざそんなこと無駄とか言う必要ないじゃん（ｗ
お前の仕事になるわけでも無いし。
よっぽど人生が貧しいんだと思うのだけれども、
なんでまたわざわざ、自分が何一つ協力する気がない
構想に口出しするんだ？
0818デフォルトの名無しさん2010/04/20(火) 13:51:58
>>817
おまえ協力してんのかよｗ
グダグダ勝手なこと書いてるだけじゃん。
0819デフォルトの名無しさん2010/04/20(火) 13:53:54
まだ、ブレスト段階でしょ。
社会人やったこと無いのかよ・・・
0820デフォルトの名無しさん2010/04/20(火) 13:55:48
社会人どうこういう奴は社会人にコンプレックスを持っている人間ですｗ
つまり、>>819はニートですね？ｗｗ
0821デフォルトの名無しさん2010/04/20(火) 13:57:57
ブレスト？？？
こんなｇｄｇｄなやりとりがブレスト？？？
何一つ現実的な目標もないし、何一つ効果が得られそうにない話がブレスト？？？
冗談だろ。どんなぬるい環境にいるんだよ。
08228192010/04/20(火) 14:08:20
すいませんブレストって言ってみたかっただけでした
0823デフォルトの名無しさん2010/04/20(火) 14:15:58
普通、自分が社会人だと認識しているなら、
他の誰が社会人なのかなんて気にならないよな。
それに、ちゃんとした技術者なら自分が技術的に学生より優れている点なんて
ほとんど無いことぐらい承知しているはずなのにね。
0824デフォルトの名無しさん2010/04/20(火) 14:18:13
>>823
おまえさっきから言ってる意味ぜんぜんわかんない
0825デフォルトの名無しさん2010/04/20(火) 14:18:56
>>824
経験論だよｗ
0826デフォルトの名無しさん2010/04/20(火) 14:20:16
"普通の"人ってこんなふうに考えるよね
って事を言ってるだけ。
別に複雑な事や論理的な事をいってるわけじゃないよｗ
0827デフォルトの名無しさん2010/04/20(火) 14:23:31
いっそのことCPU限定で言語を作ってしまったらどうだろう。
すべてのCPU毎に言語をカスタマイズするわけさ。
0828デフォルトの名無しさん2010/04/20(火) 14:26:19
今日は支離滅裂なキチガイが棲みついてるわけか
0829デフォルトの名無しさん2010/04/20(火) 14:28:29
非ポータブルという時点でC/C++の代替にはならないので
スレ的にはスレ違いだと思うけど
0830デフォルトの名無しさん2010/04/20(火) 14:29:50
>>828
お前みたいな人工無脳に言われたくない
0831デフォルトの名無しさん2010/04/20(火) 14:38:25
>>827
俺が言ってるのはそれに近いンだよ。
ENVIRONMET DIVISION．
を有効活用して、可搬性を持たせたいなと。
ただし、オリジナルのソースは絶対に他のＣＰＵじゃうごかねぇと
動かすためにどこが不味いのか、これを徹底的に報告出来るような
コンパイルシステムがあれば、ＣＰＵの発展にも良いと思うんだよね。

可搬性を意識しないでプログラムが組めるし、ＣＰＵも開発できる。
違うＣＰＵで動かしたいのなら、何とどこが不味いのか、それを
チェックして報告してくれる、そんなシステム。
0832デフォルトの名無しさん2010/04/20(火) 14:43:50
827は「それってアセンブラだろ！」っていう突っ込みを期待してるボケだと思うのだが
0833デフォルトの名無しさん2010/04/20(火) 14:49:19
言語がCPU特化のほうが潔いと思うね。
CPU毎に用意されたバージョンのコンパイラを使ってコンパイルし、
それぞれをリンクして、CPUを判定して利用する部分を切り替える。

>>832
アセンブラを抽象化しつつ、CPU独自の機能を使えるようにする。
高度な設計手法を使うことを意識した構造的なプログラミング言語を目指す。
0834デフォルトの名無しさん2010/04/20(火) 14:51:08
>>833
政策マニュフェスト乙
0835デフォルトの名無しさん2010/04/20(火) 15:04:25
仕事一服
>>806
FortranとCobolはねえなw
VBは若い頃一回だけあるがw
tcl/tkやperlやらjavaやらphpはあるな。
組み込みメインだからアセンブラなんて当然
デバドラやらRTOSとかtcp/ipやら
usbスタックも作ったし
Cコンパイラ移植もやったなw
ま、普通だよ
今は若いもんにかなりやらせてるがな
0836デフォルトの名無しさん2010/04/20(火) 15:10:27
>>832
マクロアセンブラだわなw

ソースなんて90-95%も可搬ならいんだよ
コード内にCPUの情報入れるとか正気じゃないなw
0837デフォルトの名無しさん2010/04/20(火) 15:16:27
ああ、いい過ぎ
今はtypedefやらdefineでヘッダで吸収してるわな
ま情報入れるなら型決めちまった方が楽だな
occamみたいな並列実行ヒントやら
サチる整数はあってもいいかな
dsp系の命令かけるな
0838デフォルトの名無しさん2010/04/20(火) 15:24:50
>>833
Cをそれにコンパイルしたらどうだろう！
0839デフォルトの名無しさん2010/04/20(火) 18:24:25
ソレ、単なるアーキテクチャ依存の最適化じゃねーか
0840デフォルトの名無しさん2010/04/20(火) 19:18:44
>>839
それを簡単にこなす言語処理系が無いんだよ。
アセンブラ使うか、Ｃ言語コンパイラの挙動を予測しながらの
コード記述。

で、この20年間の歴史はＣＰＵアーキテクチャーの整理に有ったけども
逆に、よりとんがった実装をしても相手にしてくれないという閉塞状況にも
追い込まれた訳よ。ＣＰＵ設計者はもっと自由に設計すれば良いと思う。
それを受け止める、言語が今必要とされているんじゃないかと思うわけだ。

ここに述べたことを考えるに変えると、ちょっとしたレポートになるぞ（ｗ
0841デフォルトの名無しさん2010/04/20(火) 19:28:47
そうだよな！
今必要なのはリスト操作とスタック重視アーキテクチャしかねえじゃん！
文字列操作もメモリ確保もCPU内蔵だぜベイベー
0842デフォルトの名無しさん2010/04/20(火) 19:41:53
CPUは必要最低限の命令だけを搭載させるべきだろ。
その方法で富士通のVENUSは世界最速じゃん。
0843デフォルトの名無しさん2010/04/20(火) 19:51:52
必要最小限って言っちゃうと、チューリングコンプリートであればいいのか？　って
言われちゃうぞw
0844デフォルトの名無しさん2010/04/20(火) 19:52:02
RISCの失敗
0845デフォルトの名無しさん2010/04/20(火) 19:56:02
RISC は何も失敗してないだろ。

Intel を駆逐するという予想が間違ってただけで。
0846デフォルトの名無しさん2010/04/20(火) 19:56:56
>>844
設計思想が失敗だったんじゃなくて、もっと泥臭い商売的な意味で失敗しただけ。
Intelの猛烈な商売根性に圧倒されただけだね。
0847デフォルトの名無しさん2010/04/20(火) 19:57:05
>>844
デスクトップではね。
組み込みはほぼRISCが制覇

>>842
なにいってんの！gcもいっそ内蔵しちまえば最強だぜ
0848デフォルトの名無しさん2010/04/20(火) 20:00:37
現にSPARCベースのVENUSはMIPS/Wも世界最高。
でも量産効果でIntel製の方が安いから普及しないｗ
可能性としてはSPARCの方が効率的らしいけどね。
iPhoneやiPadが普及することで非IntelアーキテクチャのCPUが
使われることが当たり前になったら、RISCも復権するかもしれないね。
0849デフォルトの名無しさん2010/04/20(火) 20:03:42
あのーふつーの携帯電話はRISCですが。
0850デフォルトの名無しさん2010/04/20(火) 20:06:17
低級なのは言語じゃなくて書き込んでる奴らだったようだな
0851デフォルトの名無しさん2010/04/20(火) 20:10:35
x86からはなれても、RISCにはならないだろう。
0852デフォルトの名無しさん2010/04/20(火) 20:11:01
ここにいる奴らは全員他力本願な何もできないクズ

ソースは俺
0853デフォルトの名無しさん2010/04/20(火) 20:18:41
はい
0854デフォルトの名無しさん2010/04/20(火) 20:21:45
>>851
つか、86以外はほとんどRISCｗ
86も内部はRISC
TIのDSPはVLIW
ま4bitとか8bitは除くがな
0855デフォルトの名無しさん2010/04/20(火) 20:34:46
うんこ
0856デフォルトの名無しさん2010/04/20(火) 20:41:29
DSPとか優秀だよな
速度の割に熱くならねえ
0857デフォルトの名無しさん2010/04/20(火) 22:31:18
とりあえず頭良い人がcコンパイラ作ってよ。
0858デフォルトの名無しさん2010/04/20(火) 23:01:20
作ったよ＾＾
http://gcc.gnu.org/
0859デフォルトの名無しさん2010/04/20(火) 23:04:05
今のIntel Core内部はRISCというよりはVLIWだろ。
0860デフォルトの名無しさん2010/04/20(火) 23:08:22
新言語にはデストラクタに相当する機能が是非欲しい。
0861デフォルトの名無しさん2010/04/20(火) 23:14:17
今のRISCは、単純な命令ばかりでとは言えない。
0862デフォルトの名無しさん2010/04/20(火) 23:16:51
それは昔から。
0863デフォルトの名無しさん2010/04/20(火) 23:19:56
>>860
ということは、クラスがあるってこと？
0864デフォルトの名無しさん2010/04/20(火) 23:20:34
優れたCPUが存在しても相変わらずIntelべったりにならざるを得ないのはWindowsが原因なんだろうな。
許せないMS
0865デフォルトの名無しさん2010/04/20(火) 23:20:58
RISCの命令の種類が少なかったのなんて、ほんの初期だけだからな
0866デフォルトの名無しさん2010/04/20(火) 23:21:47
>>863
クラスは知らんが、オブジェクトはあるだろうな。
0867デフォルトの名無しさん2010/04/20(火) 23:24:08
>>864
Intel以外のCPUは優れていないから淘汰されたんだよ＾＾
0868デフォルトの名無しさん2010/04/20(火) 23:31:41
C#のイベント機能をそのまんま割り込みに使えるようにしようぜ
0869デフォルトの名無しさん2010/04/20(火) 23:33:18
>>868
割り込みっていろいろ条件があるし、優先度もあるし、内部機能の数によっても決まるし・・・
0870デフォルトの名無しさん2010/04/20(火) 23:40:49
そういうのを包括できるような新言語を作ろうって話だろ
割り込みなんて大抵のCPUは、許可、不許可、優先度、ハンドラ関数くらいしか
設定することないんじゃないの？
0871デフォルトの名無しさん2010/04/20(火) 23:41:06
>>864,867
IBMの所為だよw
0872デフォルトの名無しさん2010/04/20(火) 23:58:42
>>864
かつて、Power, Alpha, MIPS用のWindowsもあったし、Windows CEだったらx86はアプリ開発用しかない。
0873デフォルトの名無しさん2010/04/21(水) 00:33:28
>>870
同意
0874デフォルトの名無しさん2010/04/21(水) 01:24:50
割り込みはCPU毎に違いが大きいからなー
ハンドラくらいしか一般化出来ねえな
Signalで補足出来たら面白いがな
0875デフォルトの名無しさん2010/04/21(水) 07:48:22
違い？具体的にどう違う？
0876デフォルトの名無しさん2010/04/21(水) 07:59:11
>>872
ん？　Windows CE、x86で走ってるぞ。
0877デフォルトの名無しさん2010/04/21(水) 09:36:00
>>875
おはよ。
一つはハード面、も一つはOSなんかのからみな

まずハード面では設定項目は似てるがハード構成が結構違う。
RISCなんかはコアの割り込みは一本で
信号線はコントローラ任せで
ステータス見て自分でテーブルとかで分岐だけど
コントローラ内蔵なCPUはベクター割り込みは自動だしね。

他にもコントローラには割り込みトリガー設定とかも必要かもしれんし
コントローラが外部デバイスだったりするかもだし
CPUはレジスタセットが切り替わるかもだし
スタックも切り替わるかもだし
MMUも切り替わるかもだし

OSに関しては
割り込みからユーザの関数コールまでの間の
アセンブラルーチンにコンテキスト保存を仕込んだりするわけだし
多重割り込みの処理もしないとだし
場合によってはコンテキストスイッチするかもしれん

言語でやるには要求が多いし違いが大きいと思うがね
ちゅーより下回りの共通ライブラリってのならありと思うけど。

例外やらSignalで処理出来たら面白いとは思うが
いろいろ考えると出来るとしてもせいぜいレジスタ保存とかが
出来るようなハンドラ記述レベルじゃね
0878デフォルトの名無しさん2010/04/21(水) 10:28:15
んなもんインラインアセンブラor外部モジュール結合でいいだろ
抽象化不可能とわかってる部分まで抽象化しようとすんな
0879デフォルトの名無しさん2010/04/21(水) 13:17:17
抽象化可能だが、具体的に扱うのが低級言語だろ。
0880デフォルトの名無しさん2010/04/21(水) 13:34:11
悪化は良貨を滅ぼす
x86、ARM、SPARC、PPC
RISCでもCISCでもアーキテクチャーの汚いものだけが残って
美しいものは消えていく運命にある。
今はMIPSが最後の砦だ。
0881デフォルトの名無しさん2010/04/21(水) 13:35:16
iPhoneにはARMが入っているわけだが
0882デフォルトの名無しさん2010/04/21(水) 13:51:11
CPUを売る能力がある企業は天才よりも組織に順応しやすい人間を選ぶからじゃないかな。
綺麗なアーキテクチャを考える天才は技術はあっても商才がないので売れないと。
0883デフォルトの名無しさん2010/04/21(水) 14:32:12
obj.x;でobj.x();が、obj.x = 1;でobj.x(10);が呼ばれる、みたいなプロパティっぽいシンタックスシュガー機能搭載してください
0884デフォルトの名無しさん2010/04/21(水) 18:49:48
>>878
868,870へのレスだよ
割り込みの抽象化は意外に難しいぜといいたかっただけ
ライブラリで済ませれるなら出来ない話じゃないがね
0885デフォルトの名無しさん2010/04/21(水) 19:56:13
本質を抽象する言語を開発したい
0886デフォルトの名無しさん2010/04/21(水) 20:02:48
>885
数学で十分だと思っている僕は負け組ですか
0887デフォルトの名無しさん2010/04/21(水) 20:10:45
yes
0888デフォルトの名無しさん2010/04/21(水) 20:11:17
＞＞885
あんたのしゃべってる言語じゃねえのｗ
0889デフォルトの名無しさん2010/04/21(水) 20:32:06
もしも抽象データ型が発明されていなかったとして、新たに作るとしたら
本質データ型という名前にしたい
0890デフォルトの名無しさん2010/04/21(水) 20:41:03
本質データ型はビット列を直接記述できます
0891デフォルトの名無しさん2010/04/21(水) 22:40:37
bit列でしか記述できないほうが美しい
0892デフォルトの名無しさん2010/04/21(水) 23:17:30
>>877
それを抽象化するのがプログラミング言語の仕事だろう。

割り込みの抽象化が難しいというのであれば、「変数」や「関数」や「オブジェクト」の抽象化だって難しい。
割り込みの抽象化が他の機能の抽象化に比べて特別に難しいことはない。
0893デフォルトの名無しさん2010/04/22(木) 01:17:04
>>892
Cレベルの言語にとって
変数や関数の抽象化レベルはひくいぞ
一緒にしない方がいい
無知と浅薄がバレる
例外なんていわない方がいい
0894デフォルトの名無しさん2010/04/22(木) 01:29:13
全く具体的な内容の無い反論。
0895デフォルトの名無しさん2010/04/22(木) 01:44:10
もう全部877で書いたからな
一言でいうと言語でやるにはレイヤ違い
0896デフォルトの名無しさん2010/04/22(木) 07:10:30
>>893は「変数」や「関数」や「オブジェクト」の一般的な実装方法すら分かっていない。
既にあるから簡単だと思ってしまっているだけ。

「変数」や「関数」や「オブジェクト」と、「割り込み」に”レイヤー”の違いなんてないし
”レイヤー”に違いがあるとしても言語で合わせればいいだけの話。
0897デフォルトの名無しさん2010/04/22(木) 07:43:53
割り込みの抽象化はOSの仕事だろ。抽象化の仕方もいろいろある。
0898デフォルトの名無しさん2010/04/22(木) 09:24:59
>>896
話噛み合わないなw
変数、関数とオブジェクトを一緒にしてる時点でまず話がすれ違う訳だよ

俺は無理そうな理由は書いたから
どう言語に入れるか具体的に書いてみなよ
0899デフォルトの名無しさん2010/04/22(木) 11:52:09
割り込みはOSが提供してるんだよ？
そのOSを作れるレベルの言語の話をしてるのに…レイヤー違いにも程がある
0900デフォルトの名無しさん2010/04/22(木) 12:00:07
>>899
割り込み自体はCPUの機能だよ
OSが提供してるのはそれをラップしたもの
番号振って統一的手段で使えるようにした割り込みサービスな
0901デフォルトの名無しさん2010/04/22(木) 13:21:52
割り込み処理に関しては>>897　>>900で良いかな。

んで、話変えさせて貰いたいんだけど、例外処理って
便利だけど使いにくくない？アサートと例外処理が
分かれてるのは分かるんだけど、なんとかまとめられない物か、
もしくはもっと明確に分けられない物か。

アサートはどっちかというと、開発時点のバグ検出に使って、
例外処理は実行時のエラー処理だよね。これを了解してない
開発組織が有って、アサートを使いましょう。
例外は全部受け取ること、なんて言う鼻血レベルのＣＭＭ組織を
おいらは実際に見たことが有るんだ。
何言ってるのかよく分からない、説明を求めると、
オタク、オタク、とか言われてプロジェクト燃え上がらせる
組織にほんの少し、参加したことがある。

おいらの理解もちょっと怪しいんだけど、例外処理は仕様書レベルで
規定されてる、実行時例外に近いレイヤー処理に向いていて、何を
トライすべきか、何をキャッチするべきは、プログラミングレベル
じゃなくて、仕様レベルで規定していく物だと思うのですよ。

例外処理の説明にプログラムが想定していない例外が発生したときに云々
という記述があるのが不味くて、例外処理は、プログラムが想定していた
例外に対処する処理を便利に記述する仕組みだと思うんです。
0902デフォルトの名無しさん2010/04/22(木) 13:33:34
>>901　
以上が前置きで、アサートと例外処理、これは独自に発展してきた
物なので、別物になってるんだけど、そして別でも、まぁ良いんだけど、
この辺をもう少しすっきりまとめ直せないかとか思うんだ。

後、例外処理の投げる方の記述は読みやすく、理解しやすくで問題ないんだけど、
トライとキャッチの方は、どうも、直感的じゃないと思う。

try{
一つ目
　　二つ目
}
catch{
}
とか、インデントが下がるのも嫌だし
（逆に例外を受け取る意志が読めるんだけどなんか好きになれない）
catchを見れば何を心配してるかは、読めるんだけど、
どうもトライとキャッチの間が離れすぎてるような気がするし。

単に例外に馴れてないから、良い例外処理を使い切ったプロジェクトに
参加したことがないから、ただそれだけなのかも知れないんだけど、
例外処理って、とってつけたようなプログラムが多いような気がするんだ。

んで、その辺の事情って、構文に問題があるような気がするんだけど
どうだろうか？
0903デフォルトの名無しさん2010/04/22(木) 13:38:26
普通にエラーコード決めて戻り値でいんじゃない
0904デフォルトの名無しさん2010/04/22(木) 13:46:59
ひとことで言えばassertはデバッグ支援で強制abortする
例外処理は例外(エラー)という名の正常処理をするための構文
0905デフォルトの名無しさん2010/04/22(木) 13:55:57
>>904
それは分かってるんだって、（分かってない人が多すぎるけど）
以下自己引用。
＞例外処理の説明にプログラムが想定していない例外が発生したときに云々
＞という記述があるのが不味くて、例外処理は、プログラムが想定していた
＞例外に対処する処理を便利に記述する仕組みだと思うんです。

で、そうだとしても、
try{
}
catch{
}
が好きになれないんだよね。この辺の構文をもっと直感的に
出来ないのか、switch文みたいに
try（ファイルオープン）
　catch 存在しない
　catch 使用中
　catch 権限不正
end-try

の方が見やすく、そして直感的じゃないか？とかなんだけど

だけどこうしちゃうと、
try{
　　一つ目
　　二つ目
　　三つ目
}
catch{
}
の形が難しくなるし、オブジェクト指向的に問題が出てきそうな
気もするし。
0906デフォルトの名無しさん2010/04/22(木) 14:04:37
OS書くような低水準言語にtry-catchとかイラネ。終わり。
0907デフォルトの名無しさん2010/04/22(木) 14:08:13
>>906
それはそれで一つの見解だと思うのだけれども、>>1はC++に変わるような、
と書いているので、try-catchに関しても考えてみたいと思うのです。
この構文は後から追加されたので、構文的にベストなのかどうか、
私は疑問で、ライブラリからのエラー通知に必要だから、最小限の機構として
追加された構文、と了解していて。

で、そもそも構文自体がとってつけた物なので、どうも使い勝手悪いんじゃ
無いのかな？という問題意識なんですよ。
0908デフォルトの名無しさん2010/04/22(木) 14:12:46
setjmpとsignalに砂糖まぶしたもんだしな
元々汚いんよ
ファイル開けたら失敗返してもらうもんさ
0909デフォルトの名無しさん2010/04/22(木) 14:40:09
Cのレベルの言語なら例外はいらんだろう
高級言語における「例外」そのものの有用性については、今更疑う必要があるとは
思えん、モダンな高級言語には大抵例外がある
C++の場合に限って言えば、C++特有の理由によって例外が使えないシロモノに
なっている
0910デフォルトの名無しさん2010/04/22(木) 14:44:56
goには無いな
理由はエラー処理をサボるからだそうな
GCと相性はいいがね
0911デフォルトの名無しさん2010/04/22(木) 14:46:09
goには無いな
理由はエラー処理をサボるからだそうな
GCと相性はいいがね
大域脱出を多用したらわかりにくいのは当然だが。

0912デフォルトの名無しさん2010/04/22(木) 14:53:10
同じことなので2回言いました＾＾
0913デフォルトの名無しさん2010/04/22(木) 14:58:22
携帯からなんで切れたと思ったら書けてた
すまんw
0914デフォルトの名無しさん2010/04/22(木) 14:59:03
>>911
＞大域脱出を多用したらわかりにくいのは当然だが。
これだーーーーーーーーー！！
そうなんだよね、当たり前なんだよね。言葉が見つからなかった。

例外処理の説明してる人間が、馬鹿に過ぎるんだよ、
if文の条件処理程度の意味合いで、説明しすぎてると思う。
大域で扱われる構文という、ところをもっとちゃんと説明しないから、
>>901で書いたような組織が生まれる。というかストラップ先生は
悪くなく、あの人は言語設計者としての記述なのに、それを読めずに
ストラップ先生が、例外を積極的に使って欲しいと書いてるから、
プログラマーは全部キャッチしろ、とか言うプロジェクト標準を書く
プログラムが組めないＰＭを据えるＣＭＭ３組織にＣＭＭ３を与える
ＣＭＭ認定機関が白痴なんだと思う、経済学部出身者がＣＭＭの
公認トレーナーになっていて、経済学部出身の公認トレナーに発注してる、
棒巨大企業がおかしいんだと思うんだ。

と、まぁ愚痴はこの位で、でもそれでも、例外の構文はどうなんだろ？
そっちはどう？　大域なので、
try{
　　一つ目
　　二つ目
　　三つ目
}
catch{
}
そう考えると、この構文は必要ないと思うんだ。
たまたま、一つめと二つめで似たような例外をスルーする可能性が有っても、
それはたまたまで、キャッチ節をまとめるメリットは、タイプ量が少し減る
だけで、可読性、見通しに関しては逆効果だと思う。
0915デフォルトの名無しさん2010/04/22(木) 15:09:02
構文に関してはあんなモンじゃないの？
他にあんまいいのも思いつかないけど
0916デフォルトの名無しさん2010/04/22(木) 15:12:36
後携帯じゃないんだからw
ストラウストラップなw
0917デフォルトの名無しさん2010/04/22(木) 15:53:37
>>901
> 割り込み処理に関しては>>897　>>900で良いかな。

別にそれで良いけど、言語機能に割り込みを入れることには何も影響はないね。

新言語では割り込みを第一級オブジェクトとして扱えるようにしよう。
0918デフォルトの名無しさん2010/04/22(木) 16:00:06
>>917
実はそれは有りだと思うんだよね。
例えばsignal構文みたいなのを作って、
ＯＳでのsignal処理と、ＣＰＵの割り込み処理では、
書けること書き方書くべきことが変わるだけ、
という抽象化はあり得ると思う。

その辺詳しくないので、構文の提案をして欲しい。
インテルチップと他のチップ、ＵＮＩＸ系のＯＳ、と言う具合に
提案してくれれば良いんじゃない？
0919デフォルトの名無しさん2010/04/22(木) 16:06:11
POSIXだと標準のsignal()じゃなくてsigaction()使うし
Windowsのsignal()は、言語標準だから仕方なくエミュレートして入れてるだけ
言語どころか標準ライブラリにも要らないと思う
0920デフォルトの名無しさん2010/04/22(木) 16:07:14
try-catch-finalの構文上の欠点は、ブロックを伴うために通常の処理であってもインデントをしたくなってしまう点。

こんな感じの方が、場合によってはよいこともある。

try my_area (キャッチする例外) { キャッチ時の処理 };
処理;
処理;
処理;
delete my_area;
0921デフォルトの名無しさん2010/04/22(木) 16:08:27
目標立てないとモチベーション上がらないだろ。

低級言語を作って、それを使ってMINIXを書き直す

っていう目標はどうよ？
0922デフォルトの名無しさん2010/04/22(木) 16:11:29
>>918
> インテルチップと他のチップ、ＵＮＩＸ系のＯＳ、と言う具合に
> 提案してくれれば良いんじゃない？

「という具合に」といっても、汎用言語でアーキテクチャ毎に構文を変えるようなアホなことはしないだろ？

イベントとイベントリスナーの構文を定義するんだろうな。
0923デフォルトの名無しさん2010/04/22(木) 16:23:25
>>922
俺は、Environment division提案した人で、
アーキテクチャーごとに可用範囲が変わるのは別に構わないと思ってる。
構文も出来るだけ統一した方が良いけども、違うＣＰＵや同じＣＰＵでも
違うＯＳに載ってるのなら、違っても良いと思う。

同じことは同じように、違うことは違うように書ければ良いと思うんだ。

なんども書くけど、ライトワンスは幻想、ライトワンスを目指したが為に
どれだけの非互換と、ポーティング時の悪夢に見舞われたか、同じように
書けば、どんなＣＰＵでも同じように動くが、違う場所ではそもそも
書けない（コンパイルエラー）というのが、新しい低水準高級言語に
求められる性格だと思うんだ。
0924デフォルトの名無しさん2010/04/22(木) 16:28:30
元々signal自体が割り込みの抽象化だしな
チョイ斜めにずれた延長上にtry-catchがあるわけだ。
グローバルにtry-catchみたいな構文にするのがいいだろう
割り込み用にcontinuationみたいなことが出来ても面白い

ま思考実験としてはいいが、ハード依存しすぎるｗ
sigactionとかマスク関係を言語に取り込むのはアホすぎる
むしろ実行中断して戻れるような制御構文を一つだけ考えて
ランタイムから起動するような方が建設的じゃないか

単なる例外と違って外部ハードが絡んで条件が多いし
言語専用OSで下位をラッピングしたら出来ると思うがそれじゃ意味ないな
OSのローレベル部分やベタな処理を書いたことがないやつが
書いてみたいってだけの流れに見える
0925デフォルトの名無しさん2010/04/22(木) 16:48:23
try catchはscalaがc++やjavaとちょっと違いますね。
try {}
catch {
case AException =>
case BException =>
}
と書きます。
visual basicのon error gotoならネストを深くしなくてすむのでうれしいですが、
gotoなのがいまいちです。

こんな感じでtry&catchがかければいいのかもしれませんね。
{try=>

catch AException=>
catch BException=>
}
0926デフォルトの名無しさん2010/04/22(木) 17:04:04
>>923
日本語でおｋ

つーかC/C++がライトワンスを目指した言語だなんて初めて聞いたわｗ
Javaと勘違いしてんじゃないの？
0927デフォルトの名無しさん2010/04/22(木) 17:10:49
>>924
正直、Abs(）と何が違うんだと言われるレベルだと思うんだけど、
それでもコンパイラーが知っているというのは、後々に違ってくる
と思うんだ。
0928デフォルトの名無しさん2010/04/22(木) 17:39:00
「使えないシステムや処理系はエラーにする」んだと、標準に入ったところで
別に今となんもかわらん気がするけど……

「使えない／意味を持たない環境では無視」でいい物なら、
#ifdefが減らせて多少楽になるかも
例えば near とか declspec(dllexport) とか

Javaのsynchronizedみたいな例は、ちょっとこのスレ的には高級すぎるが、
あれもスレッドが利用できない環境では無視、の方法でいいんだろうな
0929デフォルトの名無しさん2010/04/22(木) 17:40:00
あ、一行目は
使えないシステムや処理系「では」エラーにする
の間違い
0930デフォルトの名無しさん2010/04/22(木) 18:00:15
>>928
具体的にと問われると、妄想レベルになるんだけど、現状

intの隠蔽一つ見ても、uint16,int16や、u_int_16,s_int_16や、
uInt16,sInt16とかでしょ、なんかねもうね、うんざりなんですよ。

でこう言うのは、コンパイラが知らないからだと思うんですよね。
コンパイラが知ってるとなると、コンパイラの供給側で今回はこうするね
ＣＰＵ作った人がこうしたいって言ってるから、とかね、いけると思うんですよ。

なんちゅうか、何となく。


0931デフォルトの名無しさん2010/04/22(木) 18:02:27
>>930
あー例え悪いな、馬鹿に変なつっこみされそう。
でも、まぁ、コンパイラが知らないからぐちゃぐちゃしていくという
例としてあげた悪いこと。

でコンパイラが知ってればどう解決するんだってことはまだ模索中
だけども、知ってると言うことがまず必要だと思うって事。
0932デフォルトの名無しさん2010/04/22(木) 18:02:44
>>930
intに関してはC99ではstdint.hが標準になったし
特に反対する人はいないだろう
0933デフォルトの名無しさん2010/04/22(木) 18:52:47
>>923
> アーキテクチャーごとに可用範囲が変わるのは別に構わないと思ってる。
> 構文も出来るだけ統一した方が良いけども、違うＣＰＵや同じＣＰＵでも
> 違うＯＳに載ってるのなら、違っても良いと思う。

勝手に思ってろ。

アーキテクチャごとの仕様なんて、各アーキテクチャのコミュニティーで勝手に決めろ。
そのための自由記述できる領域指定の仕様を新言語に含めればいい。

__ASM{
　　＜＜ここに好きに書いてろ＞＞
}

ここでまず考えるのは汎用言語としてのアーキテクチャに依存しない機能だ。
アーキテクチャに依存しない割り込みハンドリング機能だ。

アーキテクチャ依存の機能は他所でやれ。
0934デフォルトの名無しさん2010/04/22(木) 19:17:34
>>924
例外を怖がりすぎだ。素人。
0935デフォルトの名無しさん2010/04/22(木) 19:19:08
この素人が怖がってるのは例外じゃなくて割り込みだよ
0936デフォルトの名無しさん2010/04/22(木) 19:46:50
割込み機能が単独で存在するのではなく、
割込み、例外、非同期IOとかを統一してイベント機能にするんだろうな。
0937デフォルトの名無しさん2010/04/22(木) 20:38:57
イベントドリブンだと困るようなリアルタイム処理オンリーの組み込みはどうすんねん
0938デフォルトの名無しさん2010/04/22(木) 20:59:42
例外を一緒くたに扱うのはものすごく違和感があるんだが……
別物だろ？
0939デフォルトの名無しさん2010/04/22(木) 21:02:55
例外と割り込みは全く違うだろ。
同じなのは、どちらもハンドラが起動されることぐらい。
0940デフォルトの名無しさん2010/04/22(木) 21:02:57
イベントドリブンなプログラムで汎用的に役に立つのがコルーチン
コルーチン欲しいな
0941デフォルトの名無しさん2010/04/22(木) 21:03:25
例外=割り込みっていうCPUもある罠
0942デフォルトの名無しさん2010/04/22(木) 21:13:52
ど素人がデタラメ言ってかき混ぜてるの図
0943デフォルトの名無しさん2010/04/22(木) 21:26:39
未熟さを新言語で補えると思ってるとか？
0944デフォルトの名無しさん2010/04/22(木) 21:28:09
>>937
どうするってどういう事？
別にリアルタイム処理すればいいじゃん。
0945デフォルトの名無しさん2010/04/22(木) 21:31:44
>>941
その「例外」って何？
CPUの機能として「例外」があるの？ソフトウェア割込みのこと？
0946デフォルトの名無しさん2010/04/22(木) 21:54:34
ゼロ除算とかページフォルトとかのことじゃないの
0947デフォルトの名無しさん2010/04/22(木) 22:37:27
>>934
素人だが、例外も割り込みも普通にアセンブラとCで書いてるよ
怖いからな
0948デフォルトの名無しさん2010/04/22(木) 22:39:46
スレの英才たちによって
いよいよCPU固有言語にRTOSを組み込む日が来そうだなｗ
0949デフォルトの名無しさん2010/04/22(木) 22:40:58
マジレスですまんが、CPU固有言語はイラネーは。
0950デフォルトの名無しさん2010/04/22(木) 22:43:08
まずは汎用言語だろうな
0951デフォルトの名無しさん2010/04/22(木) 22:48:01
CPU固有なら、構造化アセンブラでいいだろ。それなら、
asmをサポートしたC、あるいは、もうちょっと踏み込んで Turbo Cみたいにしてもいい。
0952デフォルトの名無しさん2010/04/22(木) 23:49:09
CPU固有なんて好きにやってろ。
言語仕様にはout of scopeだ。
0953デフォルトの名無しさん2010/04/23(金) 00:13:41
おまえらが週末までにどんなモノを出してくるか楽しみですわ。
0954デフォルトの名無しさん2010/04/23(金) 01:23:53
やはりみんな直接は触れたくないようだな
なんか出てるしな
0955デフォルトの名無しさん2010/04/23(金) 01:42:08
ぶっちゃけ今のgcc以上に組み込みにも使える低レベルな高級言語はないんだし
超える仕様をお願いね♪
0956デフォルトの名無しさん2010/04/23(金) 01:43:02
斜め上を通過するだろうな
0957デフォルトの名無しさん2010/04/23(金) 01:51:52
え、CPU固有言語にRTOSを組み込んでくれんじゃないの？
割り込み周りはvxWorksが良かったな
0958デフォルトの名無しさん2010/04/23(金) 01:55:18
正直、C以上に低レベルな言語は考えにくい。
だとしたら別の部分にこだわってみたらどうかな。
例えばライブラリが使い易い言語がいいな。
ライブラリを一つのファイルにまとめる方法を提供し、その一つのファイルを適当な場所にコピペしたら
リンクとかライブラリパスとかインクルードパスとかそんなの設定しなくても呼び出したら勝手にやってくれるのがいい。
中二言語とかいうなよ。使い易いんだからいいじゃん。
0959デフォルトの名無しさん2010/04/23(金) 01:57:48
C≒アセンブラだからな
0960デフォルトの名無しさん2010/04/23(金) 02:09:33
どういう人を対象にするかも決めといた方がいいな。
俺は中高生対象の低級言語を目指したい。
0961デフォルトの名無しさん2010/04/23(金) 02:10:57
中高生対象の勉強用低級言語な。
0962デフォルトの名無しさん2010/04/23(金) 02:11:42
だとしたら打倒Cより打倒VBの方が近い
0963デフォルトの名無しさん2010/04/23(金) 02:12:54
>>960
まぁ、実際にできたとしてもエンタープライズでは使ってもらえないだろうな。
こんなところで考えた怪しげな言語なんてｗ
0964デフォルトの名無しさん2010/04/23(金) 02:15:55
大学で作れば附属の学校に使わせることが出来るんだよな
作ったソフトを、何の成果もないのに（まあ成果を得るためにやるんだが）、小中学生に使わせてて驚いた
0965デフォルトの名無しさん2010/04/23(金) 02:18:47
それ低レベルつってもレベル違いじゃないのｗ
むしろSmalltalkやLegoなんかが目指した世界じゃ
0966デフォルトの名無しさん2010/04/23(金) 02:19:51
>>965
smalltalkではCPUの仕組みを意識したプログラミングなんてできないでしょ。
0967デフォルトの名無しさん2010/04/23(金) 02:20:55
CPUの仕組みを学習するための言語なの？
なんかそういう趣旨の本があった気がするな
0968デフォルトの名無しさん2010/04/23(金) 02:35:55
ふむ。でも中高生なら
やはりちゃんとした言語がいいと思うな
敷居は少し低めでもいいけど、ちゃんと実務に耐えるレベルの奴
0969デフォルトの名無しさん2010/04/23(金) 07:06:00
久々に来たらまだスレ続いててワロタ
ム板のＶＩＰ風スレは元気だな
てか、とりあえずたたき台でも作ろうぜ

まずは簡易なマクロアセンブラとヒープ管理と
一連のマクロをtypedefしてコンパイル時に型として解決される機能と
静的配列の機構と
typedef機能の範疇で構造を静的に定義できる機能用意した言語作って
拡充して改変して最終的にＣ言語って名前にしようぜ
0970デフォルトの名無しさん2010/04/23(金) 07:56:53
SimulaとBooを参考にした言語を作って
Dorifって名前にしようぜ
0971デフォルトの名無しさん2010/04/23(金) 12:22:29
中高生なんて吸収はやいんだからアセンブラとCをしっかりやらせた方が将来どれだけ役に立つか
0972デフォルトの名無しさん2010/04/23(金) 12:24:37
大学では、Cと関数型言語からやるんだろ。Lispはもう消えていい。
09739672010/04/23(金) 12:29:49
今日図書館で確認したら
「動かしながら理解するCPUの仕組み（ブルーバックス）」
言語はアセンブラだった
0974デフォルトの名無しさん2010/04/23(金) 13:07:59
ブルーバックスレベルなら俺でも書けそうだ
0975デフォルトの名無しさん2010/04/23(金) 13:39:00
素人に説明しようとして全然伝わらないでブチ切れるような奴には無理だぞ
0976environment2010/04/23(金) 13:51:39
叩く目安になりそうなのでコテハンは嫌なのだが
>>960
おいらの一連の提案はＣＰＵメーカーが新命令セット出すときに
おまけで付けられるような言語、というイーメージ。
言語の環境差異部分を読めば、新しいＣＰＵ（新たな開発でもＯＫ）が
理解できて、そのまま組み始めれるような感じ。

0977デフォルトの名無しさん2010/04/23(金) 15:22:13
次スレ要るのか？

厨房隔離スレとしての役割は果たしてるかな？
0978デフォルトの名無しさん2010/04/23(金) 16:22:15
>974
ブルーバックスナメんな。「集合とはなにか」レベルかけたら100冊買ってやる
0979デフォルトの名無しさん2010/04/23(金) 16:36:02
ブルーバックスは玉石
0980デフォルトの名無しさん2010/04/23(金) 16:39:16
おまえらはオール石だけどな
0981デフォルトの名無しさん2010/04/23(金) 19:50:18
東鳩オールストーン
0982デフォルトの名無しさん2010/04/23(金) 19:53:31
思いついた。
もしも何かこのスレで新言語作るってんなら、名前は是非

Koolong（クーロン："空論"のもじり）にしてくれ

‥皮肉っぽくていいだろ？ｗ
0983デフォルトの名無しさん2010/04/23(金) 20:56:52
ume

言語名はkuma-だっつってんだろ
0984デフォルトの名無しさん2010/04/23(金) 21:35:48
新言語は新言語で書かれるのだろうか？
0985デフォルトの名無しさん2010/04/23(金) 21:52:34
誰かBNFを・・・
0986デフォルトの名無しさん2010/04/23(金) 22:24:57
>>982
ハァ？空論もじってるとして、Koolong自体は何を現してるわけ？
空論をちょっと厨二臭く言ってみただけのカスッカスの能無し命名だろ？

何が「思いついた。」だよ
Dat落ちの頃合を狙って張ったんだろ？
万一ボロカスに否定されてもすぐ落ちるから、精神的ダメージは最小限に抑えられるってか？ｗ
0987デフォルトの名無しさん2010/04/23(金) 22:42:15
え、ネタスレじゃないの
0988デフォルトの名無しさん2010/04/23(金) 22:53:58
嘘から出た真…じゃなくて身から出た錆、か
0989デフォルトの名無しさん2010/04/23(金) 23:12:25
次スレ

【超高速】C/C++に代わる低級言語を開発したい 4
http://pc12.2ch.net/test/read.cgi/tech/1271980246/
0990デフォルトの名無しさん2010/04/23(金) 23:19:26
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものでした。

アイと研究員とのやり取りに利用するスレッドに書き込まれた、
関係者各位の皆様、ご協力ありがとうございました。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0991デフォルトの名無しさん2010/04/24(土) 00:33:31
ウキーッ、ウキッウキキ
0992デフォルトの名無しさん2010/04/24(土) 00:37:21
ちゃんと妄想って入れとけよ
0993デフォルトの名無しさん2010/04/24(土) 00:43:52
>>982
‥皮肉っぽくていいだろ？ｗ

ｗｗｗｗｗｗｗｗｗｗｗｗ
0994デフォルトの名無しさん2010/04/24(土) 00:57:28
>>970
pythonに対抗する国産言語に付けてやってくれ。

RubyをDorifに改名しようか。
0995デフォルトの名無しさん2010/04/24(土) 03:18:55
●フルマシンコード番号で書けば難解かつ超低レベル
0996デフォルトの名無しさん2010/04/24(土) 03:26:42
>>995が馬鹿すぎる
0997デフォルトの名無しさん2010/04/24(土) 06:21:57
>>996
もっと素晴らしいコードがあった。
そうだ、超低級言語を極めたら
0と1の2進数で記述すべきだ。
0998デフォルトの名無しさん2010/04/24(土) 06:46:22
じゃ、x86でhello worldのmain()な。
文字列自体はどっか別にあるとかは気にしないでくれ。

11000111000001001110110010000011
10000100100000000010010000000100
11110011111010000000100000000100
10000011111111111111111111111110
01011101010110010000010011000100
11000011111111000110000110001101
10010000100100001001000010010000
0999デフォルトの名無しさん2010/04/24(土) 07:08:27
>>986
そんなに長くて激しいレスもらえるとは思わなかった
しかもずいぶん内容が斜め上。ここが真正低脳隔離スレだと忘れてた
ＶＩＰに帰るわ
10009862010/04/24(土) 07:14:32
>>999
低脳はお前だろ
俺たちはお前の考えなんてお見通しなんだよ
第一空論じゃない。俺が実際に作っているし、公開の準備もしてる
お前はそれすら知らないだろ。無知乙

そうやって何も知らない癖に人を低脳よばわりすることは自らの低脳さをさらけ出してるって気付！！！！！！
俺が世界の中心なんだよ！！！
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。