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

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

2 ：デフォルトの名無しさん：2010/04/13(火) 00:44:05

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

こんなもんかね？他にどんなの欲しい？

3 ：デフォルトの名無しさん：2010/04/13(火) 00:58:14

376* 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/08(木) 04:45:08
自分は構文上の話が詳しいのでそちらだけ書き込ませてもらいます。

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

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

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

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

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

・EcmaScriptやScala、ActionScriptではXMLを直接かけるが必要かどうか？

4 ：デフォルトの名無しさん：2010/04/13(火) 00:59:19

379 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/08(木) 05:20:33
>>376
このスレはCに代わる低級言語ってことで
基本的にCPUアーキテクチャに沿った
手続き系で余分なことをしない静的な型の言語以外あり得ないんじゃないかな

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

みたいな感じ
不勉強だからブートストラップみたいなベタなとこを関数型言語で書けるのかな？
って思うんですけど

5 ：デフォルトの名無しさん：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
メモリをうまく抽象化できればいいんだけど

6 ：デフォルトの名無しさん：2010/04/13(火) 01:03:11

主な要望

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな

7 ：デフォルトの名無しさん：2010/04/13(火) 01:22:56

volatileに相当する修飾のサポートは必須と思うな

8 ：デフォルトの名無しさん：2010/04/13(火) 01:23:27

どの言語のvolatileだ？一応

9 ：デフォルトの名無しさん：2010/04/13(火) 01:29:06

メモリマップドレジスタの宣言
#define XXXX_REG (*(volatile int *)(0xC0000004))
のような記述がださいので

これをサポートする記述構文と namespace が欲しいな
オフセットずらしもできるようにして
（Cの構造体でごまかすこともできるんだが）

10 ：デフォルトの名無しさん：2010/04/13(火) 01:30:07

>>8 もちろんCです

11 ：デフォルトの名無しさん：2010/04/13(火) 02:18:03

別に僕は今のC言語で問題ないんだけど
新しいのを作るとしたらポインタ、特に関数へのポインタを引数に取り、関数へのポインタを引数に取る関数へのポインタを返す関数へのポインタとかを美しく記述できる文法を切口にポインタに変わるアドレッシング方法を考えればいいとおもう
int<- p;
int ()(void)<- fp;
int ()(int ()(void)<-)<- ()(int<- ()(void)<-)<- fpp;
ダメだ、読みにくい
int (*(*fpp)(int (*)(void)))(int (*)(void));

そもそも関数ポインタに代わるなにか、高階関数とかあればよいのだろうか

12 ：デフォルトの名無しさん：2010/04/13(火) 02:25:49

>>11
普通に関数ポインタをtypedefすれば良いんじゃない？

13 ：デフォルトの名無しさん：2010/04/13(火) 02:26:51

>>11
そのための typedef。

14 ：12：2010/04/13(火) 02:27:09

まぁ、関数ポインタを見やすくすること自体は良いと思うけど…

15 ：デフォルトの名無しさん：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();

16 ：15：2010/04/13(火) 02:45:59

アホだ俺、もう寝よう…orz

*p->copy(*dst)->trim()->toupper(); ×
p->copy(dst)->trim()->toupper(); ○

17 ：デフォルトの名無しさん：2010/04/13(火) 02:47:32

>>15
文字列型があればよかったんだけどね。

18 ：デフォルトの名無しさん：2010/04/13(火) 02:49:08

>>5
結局型のサイズって重要だから
stdint風でいんじゃない？

19 ：15：2010/04/13(火) 02:50:26

>>17
そう、文字の操作とか、延々と同じ型の計算を繰り返す処理の場合、
見通しが良くなるかなと思って…

20 ：デフォルトの名無しさん：2010/04/13(火) 02:55:14

文字列型は動的メモリ管理と直結だから
Cには入ってないんよね
実行系が必須だと困る用途もあるし

21 ：デフォルトの名無しさん：2010/04/13(火) 02:57:10

intやlongは非互換の巣窟だからbyte以外無くそう

22 ：デフォルトの名無しさん：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 が関数ポインタとか

23 ：デフォルトの名無しさん：2010/04/13(火) 03:19:51

>>21
だよなw
いまさらlongが64bitとかいわれてもw

24 ：デフォルトの名無しさん：2010/04/13(火) 03:29:10

整数型はこれな
int8 int16 int32 int64 int128
uint8 uint16 uint32 uint64 uint128

25 ：デフォルトの名無しさん：2010/04/13(火) 03:49:46

>>20
そう。結局、型としてはプリミティブ型だけしか言語には組み込めない。

26 ：デフォルトの名無しさん：2010/04/13(火) 04:55:02

前スレで並列機能の話がでてたが
occamの並列構文とかおもしろいがな
実装的にはjmpbuf内蔵するくらいのレベルで実現出来そうだし
低級言語で1st classとして扱えると面白そう

27 ：デフォルトの名無しさん：2010/04/13(火) 07:41:22

>>15
それいい

28 ：デフォルトの名無しさん：2010/04/13(火) 09:57:13

>>15
C#の拡張メソッドね。
乱用すんなとは言われてるけど、なかなか便利。

29 ：デフォルトの名無しさん：2010/04/13(火) 10:24:18

スレタイに妄想って入れとけよ

30 ：デフォルトの名無しさん：2010/04/13(火) 10:36:26

>>29
じゃあ次スレはそうしよう

31 ：デフォルトの名無しさん：2010/04/13(火) 12:20:31

>>25
アロケーターを外へ出して、アロケーターが定義されたときだけ
使えるようになるのはだめ？

32 ：デフォルトの名無しさん：2010/04/13(火) 13:59:46

>>31
Cの美点は最低限のランタイムに
四則演算位しかいらないことだね

33 ：デフォルトの名無しさん：2010/04/13(火) 14:27:24

いままでのは論理ベースの手続き言語。
では非論理ベースの非手続き言語はあるだろうか？

34 ：デフォルトの名無しさん：2010/04/13(火) 14:51:08

Cはビット操作系の命令とSIMDへの対応がなっていない
オマイラ演算子とデータ型を追加してみてくれ

35 ：デフォルトの名無しさん：2010/04/13(火) 15:50:55

>>33
おまいの喋ってる言語だよw

36 ：デフォルトの名無しさん：2010/04/13(火) 17:09:26

>>35
論理なしにどうやって意思を伝えるのだろう。

37 ：デフォルトの名無しさん：2010/04/13(火) 17:16:24

情だろ、普通
恋愛したことないの？

38 ：デフォルトの名無しさん：2010/04/13(火) 18:34:56

ラブプラスでもやってろ豚

39 ：デフォルトの名無しさん：2010/04/13(火) 19:01:33

理論無しの言葉の実例w

40 ：デフォルトの名無しさん：2010/04/13(火) 19:04:54

>>37
情の本質はなんでしょうか？

41 ：デフォルトの名無しさん：2010/04/13(火) 19:14:30

結局>>1のやってる事って

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

だよな

42 ：デフォルトの名無しさん：2010/04/13(火) 19:18:46

>>41
ここを見てるお前もだろ

43 ：デフォルトの名無しさん：2010/04/13(火) 19:20:55

次スレの名前案
【超高速】C/C++に代わる低級言語が欲しい【妄想全開】

44 ：デフォルトの名無しさん：2010/04/13(火) 19:28:53

>>42
はぁ？

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

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

「譲ってくれ」のニュアンスも分からん文盲は黙ってろ

45 ：デフォルトの名無しさん：2010/04/13(火) 19:30:52

d言語でいいじゃん

46 ：デフォルトの名無しさん：2010/04/13(火) 19:32:00

何をムキになっとるかわからんが
こんなスレで作られるわけないし作られても譲るわけないだろ
馬鹿か

47 ：デフォルトの名無しさん：2010/04/13(火) 19:34:14

>>46
脊髄反射レス乙

48 ：デフォルトの名無しさん：2010/04/13(火) 19:52:41

>>47
お前もだろ

49 ：デフォルトの名無しさん：2010/04/13(火) 20:06:07

文盲:ぶんもう
文がもうもうの意

50 ：デフォルトの名無しさん：2010/04/13(火) 20:07:05

もう　とは　萌え　の方言である

51 ：デフォルトの名無しさん：2010/04/13(火) 21:04:42

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

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

　　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

52 ：デフォルトの名無しさん：2010/04/13(火) 22:22:28

Schemeのように最小仕様で拡張性最大にできないかな？

53 ：デフォルトの名無しさん：2010/04/13(火) 23:59:43

おれはゲーム開発用Javaを作成中

54 ：デフォルトの名無しさん：2010/04/14(水) 00:07:46

おれも

55 ：デフォルトの名無しさん：2010/04/14(水) 00:10:46

どんな仕様？

56 ：デフォルトの名無しさん：2010/04/14(水) 01:13:09

classなしvmなしポインタとプリプロセッサ付けたjavaだよ

57 ：デフォルトの名無しさん：2010/04/14(水) 01:27:28

そりゃだめだｗ

58 ：デフォルトの名無しさん：2010/04/14(水) 02:09:10

>>52
lisp系が日の目を見る日はないなー

59 ：デフォルトの名無しさん：2010/04/14(水) 02:13:13

関数型はメモリ管理複雑だろ

60 ：デフォルトの名無しさん：2010/04/14(水) 02:50:49

Lispは基本部分だけならそれほどでも無いような
ただ、Lispでメモリ管理のコード自体を書くとなるとキツいと思う

61 ：デフォルトの名無しさん：2010/04/14(水) 06:30:02

LispがマイナーなのはS式の表現力不足が問題です。

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

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

という感じでやればいい言語が出来上がると思います。

62 ：デフォルトの名無しさん：2010/04/14(水) 06:53:14

オレは１じゃないけど、作るのに協力できるなら協力します。
著作権については修正free bsdライセンスのような、商用にも使える自由なやつがいいなぁ

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

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

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

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

大きい仕様の言語はD言語からGCとかclassをはずした言語がいいんだろうなと。
大きい仕様の言語でも式言語としてパースできたらいいけど、それは無理なのかな？

63 ：デフォルトの名無しさん：2010/04/14(水) 07:29:56

それは作りたいから作るの？
実用したいから作るの？

64 ：デフォルトの名無しさん：2010/04/14(水) 11:31:12

>>41
色々誤解させてすまない。Wiki管理者と全スレの>>1は別人です。色々他のことやっているからあまり関われないのは事実です。権限とか名声とか興味ないです。
名前をプリン並みの強度で決定したのとWiki空っぽにしたのは翌朝以降に整備予定であったのと、何も決まっていないということの現状認識。
名声とかより仕様がまとまらず無駄に時間が流れていくのもどうかなと思ったから立てた。

>>44
悔しいのか怒りなのか思い込み激しすぎて理解できませんがEDではないでしょう？嫌でしたらご自分で勃起しては？
今回は罵倒するのは不当で正当な別途Wiki立てるのが拒否手段ですよ。用意されたツールを使うかどうかは周囲が選ぶべきです。

65 ：デフォルトの名無しさん：2010/04/14(水) 16:16:13

C/C++に代わる低級ガラパゴス言語 Jap-C を作ろう。

66 ：デフォルトの名無しさん：2010/04/14(水) 16:22:07

低脳の間違いだろ

67 ：デフォルトの名無しさん：2010/04/14(水) 19:22:49

>>64
考え方が全然なってないわ
今すぐ身を引いたほうが良いぞ

68 ：デフォルトの名無しさん：2010/04/14(水) 19:38:20

>>62
3段構成
(1)Core Spec.
(2)Sweeter Spec.
(3)Standard Lib.

69 ：デフォルトの名無しさん：2010/04/14(水) 21:06:59

IDEによる支援がし易い文法にしたいね。

70 ：デフォルトの名無しさん：2010/04/14(水) 21:28:10

Cの中であまり使われない機能に順位を付けて
上から順に削除していってスリムなCを見てみたい
ビットフィールドとか使わないよね？

71 ：デフォルトの名無しさん：2010/04/14(水) 21:29:20

機能を削るだけなら使わなきゃいいんじゃないの？
あまり意味がない気がするんだけど

72 ：デフォルトの名無しさん：2010/04/14(水) 21:31:01

EmbededCｗｗｗｗｗｗｗｗ
ﾃﾗﾊﾟｺﾞｽｗｗｗｗｗｗｗ

73 ：デフォルトの名無しさん：2010/04/14(水) 21:31:21

>>70
おまえが使わないだけだヴォケ

74 ：デフォルトの名無しさん：2010/04/14(水) 21:31:23

そうやってぶくぶく太っていくんだと思うんだな言語は
仕様書とかすっきりするじゃん
コンパイラも小さくなるし

75 ：デフォルトの名無しさん：2010/04/14(水) 21:32:48

コンパイラが小さいｗｗｗｗｗ

76 ：デフォルトの名無しさん：2010/04/14(水) 21:35:14

Cのどこが太ってるんだ
256kバイトの8086でもコンパイル出来たんだぞ

77 ：デフォルトの名無しさん：2010/04/14(水) 21:38:33

よく読んでよ
太っていくって言ったのに
ここは低級言語を開発するスレじゃないの？
あれもこれもやってたらC++みたいになるのがオチなのに何故それが分からないのか？

78 ：デフォルトの名無しさん：2010/04/14(水) 21:40:37

機能を追加するのなんでいつでもいくらでも出来る
よく使われる機能を選別して残すのが進化なんだ

79 ：デフォルトの名無しさん：2010/04/14(水) 21:42:50

あれもこれもなんて誰も言ってねーよ
ビットフィールドを削るのは見当違いだって言ってんだ

80 ：デフォルトの名無しさん：2010/04/14(水) 21:45:12

◆新言語の要件◆

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

81 ：デフォルトの名無しさん：2010/04/14(水) 21:45:31

Objective-ASM

82 ：デフォルトの名無しさん：2010/04/14(水) 21:45:47

そうかすまんね
だからその辺の統計をとって使われてない方から削除したのを見たいっていってるんだよ
もしビットフィールドを使ってる人が本当に少数派なら仕方がないということで

83 ：デフォルトの名無しさん：2010/04/14(水) 21:46:46

見たいのは別にいいけど、スレ違い。

84 ：デフォルトの名無しさん：2010/04/14(水) 21:52:26

統計をとるってのは多数決ってことだろ、ご冗談をｗ
多数決なんかとって歯抜けになったcなんぞ誰が使うんだよｗ

85 ：デフォルトの名無しさん：2010/04/14(水) 21:54:12

>>80
３と４は矛盾してる

86 ：デフォルトの名無しさん：2010/04/14(水) 21:54:54

>>85
どう矛盾しているのか、具体的に。

87 ：デフォルトの名無しさん：2010/04/14(水) 21:56:29

>>80
めちゃくちゃだな。

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

何がしたいのか全然分からんね。

88 ：デフォルトの名無しさん：2010/04/14(水) 21:57:25

草生やしてる人がうざい

>>86
（３）学習が容易
（４）最新のオサレ機能
この辺じゃないの

89 ：デフォルトの名無しさん：2010/04/14(水) 22:02:42

要するに「Cよくわかりません。難しいです。でも速い言語使いたいです。」っていう
ガキにありがちなわがまま要求だろ。

90 ：デフォルトの名無しさん：2010/04/14(水) 22:02:59

>>87
> (1)の時点で技術に比較的明るい人が使うんだろう。

そうでもないよ。
組み込み屋なんてピンきりだよ。とんでもないのがいる。

91 ：デフォルトの名無しさん：2010/04/14(水) 22:05:42

その「とんでもないの」を場当たり的な新言語で
どうこうしようたってねえ…

92 ：デフォルトの名無しさん：2010/04/14(水) 22:06:43

◆新言語の要件 v0.1◆

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

93 ：デフォルトの名無しさん：2010/04/14(水) 22:06:45

とんでもないのなんてどこにでもいるしな
そんな例外持ち出されても

94 ：デフォルトの名無しさん：2010/04/14(水) 22:07:48

asとldは使われていないから削除ですね
統計的にわかります

95 ：デフォルトの名無しさん：2010/04/14(水) 22:08:42

>>92
ハードウェアを操作するっていうのはメモリマップされたI/Oをじかに叩くとかだろ。
それって生ポインタだろ。
生ポインタは「学習が容易」ではないし「最新のオサレ機能」でもない。

96 ：デフォルトの名無しさん：2010/04/14(水) 22:09:50

>>90
そんな「とんでもないやつ」にハード相手にプログラミングさせる必要ないだろ。

97 ：デフォルトの名無しさん：2010/04/14(水) 22:10:56

＞（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能

具体的に何よ？

98 ：デフォルトの名無しさん：2010/04/14(水) 22:12:50

ラムダ、モナド、タプル、クロージャー、マクロ

99 ：デフォルトの名無しさん：2010/04/14(水) 22:14:37

Cの配列にはオーバーヘッドはないし
structも詰め物以外のオーバーヘッドはない
そういうベタ構造も、勿論必要だろうが、
超高級unionとしての代数的データ型とか
そういうのもあると、便利なような気がする

勿論オーバーヘッドの量（ワード一個とか）やメモリレイアウトが
分かりやすく、把握可能であるという前提で
google goのinterfaceはダックタイピング／structural subtyping風味で
好みなのだが、あれのオーバーヘッドはどれぐらいなのだろう

100 ：デフォルトの名無しさん：2010/04/14(水) 22:15:19

ダックタイピングいいな

101 ：デフォルトの名無しさん：2010/04/14(水) 22:18:37

動的結合なしでダックタイピングって意味ある？

意味あれば欲しいかも。

102 ：デフォルトの名無しさん：2010/04/14(水) 22:19:19

そういうの高速化からどんどん遠ざかってるから

103 ：デフォルトの名無しさん：2010/04/14(水) 22:19:58

>>80
低レベルって何処までなんだろうと考えていて
思わずrfc1149を思い浮かべてしまった…orz
でも、普通、低レベルって言ったら、それこそ機種依存になるけど、
ここで言われている低レベルって、何を指して低レベルって言ってるの？

104 ：デフォルトの名無しさん：2010/04/14(水) 22:22:27

低レベル＝ハードウェアを直接操作する記述ができる

105 ：デフォルトの名無しさん：2010/04/14(水) 22:25:12

>>102
抽象化したいときには抽象化できて
ベタで書けば高速にもできるってことならいいと思うんだが

goのinterfaceってのはクラス指向OOへのアンチテーゼだが
別にC++同様OOなんて使う必要ないし
VM系の、管理されたサンドボックスで走らせるために毎度毎度
境界チェックとかやるような仕様でなければ、特に問題ないんじゃないの

106 ：デフォルトの名無しさん：2010/04/14(水) 22:25:37

ハードウエアを直接操作というと、IOや割り込みの管理などをイメージする。そんなことはCにもできない。

107 ：デフォルトの名無しさん：2010/04/14(水) 22:26:04

>>104
ハードウェアを直接操作って言っても千差万別だけど、何処までなの？
>>95が言ってるように、メモリマップ程度に抑えるとか、
機種毎に拡張しやすいように、何でもできるインターフェイスを備えるとか…

108 ：デフォルトの名無しさん：2010/04/14(水) 22:27:33

Cで直接操作できるのはメモリだけだよな

レジスタだのスタックフレームだのを弄ったりCPUを直接叩きたければ
アセンブリしかない

109 ：デフォルトの名無しさん：2010/04/14(水) 22:28:54

インラインアセンブラがあるだろ

110 ：デフォルトの名無しさん：2010/04/14(水) 22:28:58

インラインASMとかあるでしょ

111 ：デフォルトの名無しさん：2010/04/14(水) 22:29:50

>>109
それは正確には「C」じゃないから

112 ：デフォルトの名無しさん：2010/04/14(水) 22:31:13

>>105
＞抽象化したいときには抽象化できて
＞ベタで書けば高速にもできるってことならいいと思うんだが

そういう何でもアリな言語がいいのか、
スリムな言語いいのかどっち？

113 ：デフォルトの名無しさん：2010/04/14(水) 22:31:38

>>109-110
インラインなんて使ったら、それこそ、アセンブラを使えば良いので、
単純にアセンブラとリンクできる仕様を決めておけば良いだけのような…

114 ：デフォルトの名無しさん：2010/04/14(水) 22:32:30

スレタイがCとC++を同列に扱っているところに、話がまとまらない原因がある。

115 ：デフォルトの名無しさん：2010/04/14(水) 22:32:38

>>111
一応規格にもasmという予約語はあるし（意味は処理系定義だが）
そもそもインラインアセンブラが書ける言語なんてどんだけあるんだよ
既にCの特徴と言ってもいいわ

116 ：デフォルトの名無しさん：2010/04/14(水) 22:33:38

無名関数

117 ：デフォルトの名無しさん：2010/04/14(水) 22:39:47

Cのpragmaで処理されているところは、C#の属性のような構文の方がスッキリする。

118 ：デフォルトの名無しさん：2010/04/14(水) 22:41:04

implementation-defined
言語仕様を小さくする魔法の言葉

119 ：デフォルトの名無しさん：2010/04/14(水) 22:43:05

関数リテラル、関数内関数ぐらいは問題なさげ
クロージャは、無限エクステントなしでよければ問題なさげ
それでもforeachみたいなのに渡す分には困らない
値として返せないけど

120 ：デフォルトの名無しさん：2010/04/14(水) 22:44:28

>>112
Cの何に不満を持ってるかによるんじゃないの
C++に不満を持ってる人ならいっぱいいるだろうけどなｗ

121 ：デフォルトの名無しさん：2010/04/14(水) 22:45:45

>>107
> ハードウェアを直接操作って言っても千差万別だけど、何処までなの？

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

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

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

メモリマップ程度に抑えても、上記特徴を達成出来るならそれでもいいけど、たぶんダメだよね。

122 ：デフォルトの名無しさん：2010/04/14(水) 22:46:23

Cが低級ってのが、なんで、って感じ

123 ：デフォルトの名無しさん：2010/04/14(水) 22:48:07

スレ読め

124 ：デフォルトの名無しさん：2010/04/14(水) 22:49:59

Cでなければならないのは、OSと要件が厳しい組み込みぐらいではないか？

125 ：デフォルトの名無しさん：2010/04/14(水) 22:50:23

低級なら、アセンブラでしょ

126 ：デフォルトの名無しさん：2010/04/14(水) 22:52:43

>>125
そんな誰でも知っていることは不要。

127 ：デフォルトの名無しさん：2010/04/14(水) 22:56:25

アセンブラ以上、C未満って、そんな難しいことを思いつく人がいるんかね

128 ：デフォルトの名無しさん：2010/04/14(水) 23:00:11

C未満ってどこから出てきた条件？

129 ：デフォルトの名無しさん：2010/04/14(水) 23:01:57

インラインアセンブラを使いたいだけなら、
特別なポインタを用意してやって、そこにマシン語を書き込んで、
コール出来るようにしてやれば良いと思う。
って言うか違うな…
アセンブラ関数が作れれば良いんじゃないか…？
で、引数と戻り値のルールや、変数等のポインタを共通化してやれば使いやすくなる？

130 ：デフォルトの名無しさん：2010/04/14(水) 23:02:15

低級だからじゃね

131 ：デフォルトの名無しさん：2010/04/14(水) 23:05:51

javaみたいに、仮想CPUとかの設計からやった方がいいんじゃないの

132 ：デフォルトの名無しさん：2010/04/14(水) 23:05:52

>>121
あえて言うなら、現在のCは汎用的に使えないことが問題だと言いたいのか。

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

あえて言うなら、そういう所が気に入らないのか？

133 ：デフォルトの名無しさん：2010/04/14(水) 23:09:55

>>132
> あえて言うなら、現在のCは汎用的に使えないことが問題だと言いたいのか。

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

言いたいのは、新言語は低レベル記述を出来ようにしたいけど、
低レベルにだけ使えればいいわけではなく、汎用的にも使えるようにしたいと言うこと。

134 ：デフォルトの名無しさん：2010/04/14(水) 23:11:04

>>131
低級と逆方向に進んでないか？

135 ：デフォルトの名無しさん：2010/04/14(水) 23:12:14

汎用的なもんって、難しいよ。専用なら雛形作るのは早いかもしれないけど

136 ：デフォルトの名無しさん：2010/04/14(水) 23:13:36

Cの問題点のひとつとしてマクロ。解読困難なものや、型チェックが働かないものがあったりする。
それなら、Cでよく使われているマクロを研究したら、より安全なCができるんじゃないか？

137 ：デフォルトの名無しさん：2010/04/14(水) 23:13:42

低級用途には全く関心がないのに、新しい言語を作りたいだけの人間が紛れ込んでるな

138 ：デフォルトの名無しさん：2010/04/14(水) 23:17:23

Cをよく理解していないのに新言語を作ろうとしてる奴も混ざってるしな

139 ：デフォルトの名無しさん：2010/04/14(水) 23:18:28

結論はDが完成すればもういいや、か
完成しそうにない点が問題だが

140 ：デフォルトの名無しさん：2010/04/14(水) 23:18:46

「奴」とか「人間」とかばっかり言ってるの連中よりはいいけどな

141 ：デフォルトの名無しさん：2010/04/14(水) 23:24:58

>>139
GCありの言語は用途が違いすぎじゃないの

142 ：デフォルトの名無しさん：2010/04/14(水) 23:27:43

標準ライブラリに参照カウンタでのメモリ管理入れておいて

143 ：デフォルトの名無しさん：2010/04/14(水) 23:30:23

goto廃止

144 ：デフォルトの名無しさん：2010/04/14(水) 23:30:41

低レベルって言っても、高速化を目的とした低レベル(レジスタやメモリを触りたい)と
汎用性を主眼においた低レベル(特殊な入出力等)って、方向性が違うから難しいよな…

145 ：144：2010/04/14(水) 23:32:23

何か、最終的に求めるものが違うから、Cより高レベルなものを求めたり
Cより低レベルなものを求めたりの意見の相違があるような気がする…

146 ：デフォルトの名無しさん：2010/04/14(水) 23:36:27

Cより高レベルかつ低レベル。目指してるのはそこにある
インラインアセンブラを使うこともなければ、機能の少なさを嘆くこともない

147 ：デフォルトの名無しさん：2010/04/14(水) 23:36:53

誰かが言った
ポリシーが違うならメカニズムを提供すればいいじゃない

148 ：デフォルトの名無しさん：2010/04/14(水) 23:37:16

高速化を目的としなくても、単にレジスタやメモリを触りたいだけでも「低レベル」が必要になる

149 ：デフォルトの名無しさん：2010/04/14(水) 23:38:53

Z80に対応出来るようにしてください

150 ：デフォルトの名無しさん：2010/04/14(水) 23:39:31

Cで充分だと何度言えば

151 ：デフォルトの名無しさん：2010/04/14(水) 23:45:36

>>145
Cのレベルと言っても、何か唯一のレベルがあるわけではなく、比較的高レベルから低レベルまで広がりを持っている。
Cに代わる言語だから、少なくとも現在Cがカバーしている分野はカバーするよ。

Cよりは便利にしたいから、高レベルの方はCよりも高レベルになるだろうね。
低レベルの方はCと同じ程度でいいんじゃないかな。

152 ：デフォルトの名無しさん：2010/04/14(水) 23:46:24

low levelということは具体的だという事。抽象化の時代の流れを逆行している

153 ：デフォルトの名無しさん：2010/04/14(水) 23:49:03

>>148
単にレジスタやメモリを触りたいだけって、
高速化や特殊処理以外で、レジスタやメモリを直接触ることって何がある？
CPU自体のデバッグとか、趣味で触ってみたいだけ位しか思いつかないが…

154 ：デフォルトの名無しさん：2010/04/14(水) 23:50:26

>>153
デバイスドライバー

155 ：デフォルトの名無しさん：2010/04/14(水) 23:52:55

>>154
それは、C++でもいける。

156 ：デフォルトの名無しさん：2010/04/14(水) 23:52:55

馬鹿が言語を作ろうとすると
Embedded C++みたいなのが出来る

157 ：デフォルトの名無しさん：2010/04/14(水) 23:52:59

Cは十分抽象的でしょ。
欠点を上げて修正するくらいでいいと思う。

158 ：デフォルトの名無しさん：2010/04/14(水) 23:54:14

Embedded C++のどこが問題かはかなり難しい問題。
正直Embedded C++のほうが安全にプロジェクト進められることも多い。

159 ：デフォルトの名無しさん：2010/04/14(水) 23:54:36

>>157
どうぞ好きに修正してください。さようなら。

160 ：デフォルトの名無しさん：2010/04/14(水) 23:55:11

レベルひくっ

161 ：デフォルトの名無しさん：2010/04/14(水) 23:55:34

それがいい。

162 ：デフォルトの名無しさん：2010/04/15(木) 00:01:17

>>154
あんまり新しい言語の必要性が見えない
本当に高速化が必要な高速デバイスは、インラインアセンブラや
アセンブラで書くことになるし、低速デバイスであれは、
必要な部分だけ、C、C++で作って、残りは、デバイスにあった処理系を使うな…

163 ：デフォルトの名無しさん：2010/04/15(木) 00:02:06

>>155
そうだけど、だから何なの？

164 ：デフォルトの名無しさん：2010/04/15(木) 00:03:40

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

165 ：デフォルトの名無しさん：2010/04/15(木) 00:04:57

>>89
その要求を満たしたD

166 ：デフォルトの名無しさん：2010/04/15(木) 00:06:19

Ｃの利点問題点も共有できないのかよｗ

167 ：デフォルトの名無しさん：2010/04/15(木) 00:06:30

>>153
あんたの言う「特殊処理」って奴が、まさに>>148の言う「高速化目的」以外の
ケースに該当すると思うんだが

誰でも思いつくような低水準な例以外のことで言うと、
例えばCのサブルーチン形式以外のもの（コルーチンや継続など）が欲しければ、
スタックや何かを操作する必要があるだろう
そしてそうしたことは、C言語仕様の範囲ではサポートされていない

168 ：デフォルトの名無しさん：2010/04/15(木) 00:10:55

>>162
必要に迫られて言語を選ぶのでは遅い
何が必要か判明するより前に予め将来に備えてお勉強するのが現代人のライフスタイル

169 ：デフォルトの名無しさん：2010/04/15(木) 00:11:00

でもライブラリで提供すればいい話じゃないか？

170 ：デフォルトの名無しさん：2010/04/15(木) 00:16:42

>>167
だから、高速化と、それ以外の特殊しょりで、このスレで議論している
新しい言語の仕様が全然変わるんじゃねーのって話

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

反対に、それ以外の目的では、オーバーヘッドはあまり気にしないから、
インラインアセンブラで記述するコードが極力減るように、
呼び出し側の言語で、ある程度制御して欲しいと思うし、
呼び出し側の言語の仕様も、C++よりも凝ったものになるんじゃないかってこと

171 ：デフォルトの名無しさん：2010/04/15(木) 00:16:59

Cは実行時のコード生成／自己書き換えなんかも出来ない
アセンブリに比べて（少なくとも純粋な）Cの仕様では出来ないことってのは
結構多い

172 ：デフォルトの名無しさん：2010/04/15(木) 00:18:52

それこそいらね

173 ：デフォルトの名無しさん：2010/04/15(木) 00:19:24

>>170
アセンブラ呼ぶようなクリティカルで低水準な部分でオーバーヘッドを
許容してもいい派はあんまりいないんじゃないか、さすがに

パフォーマンスにおいてクリティカルでない部分で抽象度の高いコードを
書きたい、かどうかは意見の分かれるところだろう

174 ：デフォルトの名無しさん：2010/04/15(木) 00:21:57

有名な例だけど、ATLではウィンドウインスタンスとC++のクラスインスタンスを
紐付けるサンクのコードにアセンブラを使っている

これの目的はまあ広い意味では高速化、狭い意味では、C++では実行時に
サンクコードを生成できないから

175 ：デフォルトの名無しさん：2010/04/15(木) 00:24:21

まあ、Ｃに代わる言語が作れるなら、既にできてるけどね。存在しないのは不要だからだよ。
「こういう理由で不要だから作りません」なんて論文や製品にならないから出てこないけど

なぜ不要かという答えに議論を通じてたどり着ければ得るものはあるんじゃないかな。

176 ：デフォルトの名無しさん：2010/04/15(木) 00:27:55

>>173
>>148の単にレジスタやメモリを触りたいだけ
って話に対して、オーバーヘッドを気にするのかって話

177 ：デフォルトの名無しさん：2010/04/15(木) 00:31:19

おい、１スレ目から何も話題が変わってないじゃないか
どういうことだ？

178 ：デフォルトの名無しさん：2010/04/15(木) 00:34:52

おまえ２ちゃんになに期待してるんだｗ

179 ：デフォルトの名無しさん：2010/04/15(木) 00:39:57

俺がベースを作ったら、後はお前らでなんとか出来るか？

180 ：デフォルトの名無しさん：2010/04/15(木) 00:41:07

言語仕様のベース？
なんとか出来るかは、内容による。

181 ：デフォルトの名無しさん：2010/04/15(木) 00:48:46

どこに作るの？名護？徳之島？

182 ：デフォルトの名無しさん：2010/04/15(木) 00:49:01

>>180
コンパイラの基本部分のソースだよ

183 ：デフォルトの名無しさん：2010/04/15(木) 00:50:09

仕様はお前らが考えて、
俺が動くものを作ってやるから、
後は好きに最適化すればいいよ。

184 ：デフォルトの名無しさん：2010/04/15(木) 00:51:38

>>183
じゃあ、よろしく。

185 ：デフォルトの名無しさん：2010/04/15(木) 00:52:16

日本人はものづくりがほんとにヘタだな

186 ：デフォルトの名無しさん：2010/04/15(木) 00:52:21

ここは開発するスレじゃなくて
開発したいスレだからな

187 ：デフォルトの名無しさん：2010/04/15(木) 00:54:57

>>185
これだけ理系が冷遇されていれば仕方がない。

188 ：デフォルトの名無しさん：2010/04/15(木) 00:55:52

こんなだから金出せないんだろｗ

189 ：デフォルトの名無しさん：2010/04/15(木) 00:56:56

そうだね。

190 ：デフォルトの名無しさん：2010/04/15(木) 01:02:17

Galapagosly-C

191 ：子供1 ◆8EgSMaDgzc ：2010/04/15(木) 01:06:03

誰か仕様まとめてくれ

192 ：デフォルトの名無しさん：2010/04/15(木) 01:28:30

continuationとかaspectとかDbC/PbC希望！

193 ：デフォルトの名無しさん：2010/04/15(木) 02:03:56

ちょい長文だが、
組み込みにインラインアセンブラや特殊機能は結構必要
OSや言語のラインタイム作る時にも結構便利
その他のgcc拡張なんかも有用

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

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

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

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

もちろん言語仕様的には超'例外’的な機能だが組み込み屋的には
あるとないとでは大違いな機能だったりする
つわけで、どこでどんな風に低レベル機能が必要とされてるかも考えてみてほしいね
OSの上で動くアプリとホントの低レベルでは要求がだいぶ違うんよ

194 ：デフォルトの名無しさん：2010/04/15(木) 02:07:28

Cは長い間使われて鍛えられてるからなぁ。
でもC++はちょっと違うんだよな。なんでだろ。

195 ：デフォルトの名無しさん：2010/04/15(木) 02:16:32

C++はランタイムが少し大きいのと
予期せぬところで見えない初期化や後処理が走るからだろうね
メモリ管理も抜け穴が出来やすいし

ベタなコード書きたいところではイマイチな感じ
もちろんそういうとこ抜けた後のアプリ部分では
ちゃんと使えば問題ないと思うけど

196 ：デフォルトの名無しさん：2010/04/15(木) 02:21:08

無駄なところで嫌がらせのような多重継承したり
不要なところでテンプレート乱用したり

197 ：デフォルトの名無しさん：2010/04/15(木) 02:34:06

Cの鬼マクロも昔はアレだったけど
C++はさらに輪をかけてるからな
書いた奴のレベルを自動判定して機能制限してくれるC++がほしいな

198 ：デフォルトの名無しさん：2010/04/15(木) 02:37:01

そんな謎機能はいらないからｗ
詳細に機能をオフに出来るコンパイルオプションが欲しい

199 ：デフォルトの名無しさん：2010/04/15(木) 03:15:11

>>198
インテリジェントじゃねえか
動的に文法をリミットだｗ
あんたはVBくらいねとかphp程度ねｗとか

200 ：デフォルトの名無しさん：2010/04/15(木) 04:57:00

お前らが語ってることって40年前の黎明期より劣ってるんだけど自覚ある？

201 ：デフォルトの名無しさん：2010/04/15(木) 05:25:54

最終的にどんなバイナリを吐くか？はコンパイラの仕事である。
言語仕様と実働環境の違いは完全に分離して考えなければならない。

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

いや、どうも言語仕様と実装を分けて考えられない御仁が多いみたいなんでね。

202 ：デフォルトの名無しさん：2010/04/15(木) 05:49:54

すべからく設計にはトップダウン、ボトムアップ両方の側面がある
ボトムアップが100%いいとは言わないが、
特にCの領域をカバーしたいような低レベルな言語設計をするのに
実装を十分考慮せずに言語を設計しても実用性は？だと思うがね。

203 ：デフォルトの名無しさん：2010/04/15(木) 05:55:25

>>202
実装に寄った言語をアセンブリ言語というんだよ。可搬性、抽象化なくして何のための言語か？

204 ：デフォルトの名無しさん：2010/04/15(木) 06:27:33

基本的な考えとして、Cと比較してそれを載せると無条件で1以下になるようなものは却下だろ
GCだったり動的な型付けだったり、実行時に常に影響があるようなものはNGだ
コンパイル後は可能な限りstaticに固定的にコンパクトに、という方向は見失わないようにしないとな
シンタックスシュガーや環境依存が存在しないくらいにしっかりと記号や文字を使い分ける

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

てな感じで、1以下にならないものを選別していけばいいんじゃないだろうか？

205 ：デフォルトの名無しさん：2010/04/15(木) 07:11:14

>>141
使わなければいい
そもそも OS 作成用途では malloc すら自作しないと使えないんじゃ

206 ：デフォルトの名無しさん：2010/04/15(木) 07:28:52

>>205
mallocは言語関係ない。それを言うなら、new だ。

207 ：デフォルトの名無しさん：2010/04/15(木) 07:41:58

それがGCだろ・・・？

208 ：デフォルトの名無しさん：2010/04/15(木) 07:51:50

C++は、ほかの言語への置き換えがかなり進んできているけど、Cはそれに対抗するものはまだない。

209 ：デフォルトの名無しさん：2010/04/15(木) 08:51:27

必要あくまで排除するのかということ

210 ：デフォルトの名無しさん：2010/04/15(木) 09:00:47

>>203
0 or 1ですね。わかります
極端すぎるんだよ

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

>>204
みたいにGCなしといいつつ文字列型が欲しいとか相反する部分がどうしても出てくるし。
高速演算ライブラリなんてCとかアセンブラで用意して呼べばいいだけだし
普通にアプリを作りたいだけなら低級言語はいらんのじゃないか

211 ：デフォルトの名無しさん：2010/04/15(木) 09:19:47

おまいらなんで、言語の実装とランタイムライブラリを一緒くたにしてんの？

212 ：デフォルトの名無しさん：2010/04/15(木) 09:32:19

>>210
まず今のCの仕様で、特定の環境でしか動かないような仕様が存在するか？一つも無いだろ。
今のCですら、アセンブリ言語と比較して抽象化は高いレベルで実現されている。
実働環境と言語仕様は切り離されてなければ意味が無いんだよ。
でなきゃアセンブリ使えで済む話なんだから。共通ルールを作るとはそういうことだ。
もう一度言うが、環境に依存する機械語への翻訳はコンパイラの仕事。

213 ：デフォルトの名無しさん：2010/04/15(木) 09:47:17

つーか、実装を考慮した言語設計って具体的にどんなの？って話だよ。
ある特定の機械に向けた実装をするなら、それは汎用言語ではなくなってしまうよ？
リソースのプアな機械があるからといって言語仕様に可変長型を入れてはいけない、ということにはならない。
取捨選択できる機能であり、かつ、使用する場合にメリットがデメリットを大きく上回るなら採用すべきだ。

214 ：デフォルトの名無しさん：2010/04/15(木) 09:53:13

とりあえずOOP、GC、動的型付けは却下だな
コードサイズもメモリサイズもオーバーヘッドも常に肥大化するし

215 ：デフォルトの名無しさん：2010/04/15(木) 09:53:13

>>164
それ、最初のスレで一人だけが執拗に繰り返してて、たぶん２スレ目はそいつが勝手に建てただけ。
他には誰もそんなこと言ってないっての。

216 ：デフォルトの名無しさん：2010/04/15(木) 10:14:00

並列処理も却下

217 ：デフォルトの名無しさん：2010/04/15(木) 10:17:05

SJISは良くない、って言って、SJISに似て非なるEUCを作った話から少しは学べよ。
UTF-8みたいにきちんと作らないと邪魔になるだけだって。

218 ：デフォルトの名無しさん：2010/04/15(木) 10:17:06

プリプロセスは綺麗に出来るように。
それからコンパイラやリンカオプションはソースコード上でスイッチできるように。

219 ：デフォルトの名無しさん：2010/04/15(木) 10:30:39

また長文だがｗ
>>212
Cの言語仕様の改訂はたいてい
低オーバヘッドで実現できて組み込みやらの移植性を上げるような方向だからな
でも既存言語という縛りがあるから、どうしても踏み込めてない部分も結構ある
volatileが導入される前は特定のソースだけオプティマイズ外したり
仕方なくアセンブラなんて普通にあったし

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

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

俺は趣味的な思考実験ちっくにこのスレ読んでるが
ちょっとそういう部分もあるんだなって考えてみてくれる人や
言語や見識がある人がいないかと思って書き込んだ
美しく抽象度の高い言語なら既にいっぱいあるっしょ

220 ：デフォルトの名無しさん：2010/04/15(木) 10:30:45

＞プリプロセスは綺麗に出来るように
うわ言はチラシの裏にお願いします

221 ：デフォルトの名無しさん：2010/04/15(木) 10:35:31

Cに対して明らかな優位性があって、
.o にバイナリコンパチブルがあるなら置き換わる可能性はある。

222 ：デフォルトの名無しさん：2010/04/15(木) 10:38:30

そりゃ当たり前だ

223 ：デフォルトの名無しさん：2010/04/15(木) 10:42:13

圧倒的な普及率を覆すほどの優位性なんて、そう出てくるもんじゃないけどな

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

一方、includeできるなら、プリプロセッサという化石とCの汚い言語仕様
をそのまま受け入れるということで、C++みたいな糞の山が出来上がるのがオチだ

224 ：デフォルトの名無しさん：2010/04/15(木) 10:48:40

includeつーよりラッパーのライブラリとABIな
ヘッダだけなら機械的に他の言語に変換できるし。
C++は汚いが、Cはそこまで汚いとは思わん

225 ：デフォルトの名無しさん：2010/04/15(木) 10:48:43

>>223
あんたもわかってるのかどうか怪しいなｗ
システムコールが仮にC形式で呼ばれるようになってたとしても、
Cヘッダ使わなくても呼び出しできるぞ。
C形式ってのは要するに、呼び出しアドレスがわかっていて、引数の形と数がわかっていて、
引数をスタック渡しで呼び出すシステムがあればそれでいい。
別にプリプロセッサとかヘッダとかをCと同じにする必要なんてない。

226 ：デフォルトの名無しさん：2010/04/15(木) 10:53:46

>>225
んなことは分かっとるわ、アホか
LispやLLみたいな言語ですらffi経由でCのコードを呼べる

宣言を取り込み、呼べるようにするための手間が、
#include ほげ
と書くだけより「手間」なんだよ
それが「利便性において劣る」ってこと

227 ：デフォルトの名無しさん：2010/04/15(木) 10:55:10

>>225
そもそも最近はレジスタ渡し＋スタックだな

さ、ちょいだけ仮眠して仕事するべさ

228 ：デフォルトの名無しさん：2010/04/15(木) 10:57:38

>>226
いちいち罵倒しないと会話もできないのかよ。。。

229 ：デフォルトの名無しさん：2010/04/15(木) 10:58:09

>>221
Dが流行らなかった原因ってそれ？

230 ：デフォルトの名無しさん：2010/04/15(木) 10:58:10

そういや昔は引数もPascal方式とかC方式とかあったな

231 ：デフォルトの名無しさん：2010/04/15(木) 10:59:16

最近のシステムコールには呼び出しアドレスがあるのか

232 ：デフォルトの名無しさん：2010/04/15(木) 10:59:53

>>229
Dなんてlisp以上に純マイナーだからじゃないかｗ
GoogleかAppleかMicrosoftが採用したら一気に有名になるぞｗ

233 ：デフォルトの名無しさん：2010/04/15(木) 11:01:01

>>230
今でもあるよ

234 ：デフォルトの名無しさん：2010/04/15(木) 11:05:51

>>231
＞システムコールが仮にC形式で呼ばれるようになってたとしても～
＞プリプロセッサとかヘッダとかをCと同じにする必要なんてない
という「概念」の話を、「実装」の話にすり替えないように。

235 ：デフォルトの名無しさん：2010/04/15(木) 11:14:03

昔はシステムコールにアドレスがなかったのか？

アドレスがないとしたらメモリ空間には存在してなかったのか？

236 ：デフォルトの名無しさん：2010/04/15(木) 11:14:48

>>229
GCありだからそもそもレイヤがちょと違うけど
・マイナー
・安定の二文字とは無縁な言語仕様（ビジネスでの利用は問題外、趣味でも
　昔のコードがすぐ動かなくなるのでついてくのがつらい）
・ヘッダをいちいち変換するのめんどい
など、流行らない理由はいくらでもあるだろうな

237 ：デフォルトの名無しさん：2010/04/15(木) 11:15:51

会話が斜め上225℃を逝ってるな

238 ：デフォルトの名無しさん：2010/04/15(木) 11:20:22

Cで記述された現存するOSの母国語、systems programming languageがCになるのは
当たり前
というわけで組み込みや新たなOS記述言語の地位狙いということになるのかな

239 ：デフォルトの名無しさん：2010/04/15(木) 11:24:49

>>235
システムコールとライブラリコールの違い分かる？

240 ：デフォルトの名無しさん：2010/04/15(木) 11:29:22

もしかしてCのコードから直接trapを発行してると思ってる？

241 ：デフォルトの名無しさん：2010/04/15(木) 11:31:07

>>235
CP/Mやその派生にはないね。

242 ：デフォルトの名無しさん：2010/04/15(木) 11:35:23

CP/M は call 0003 ってアドレス使ってなかったか

243 ：デフォルトの名無しさん：2010/04/15(木) 11:36:46

>>229
Dが流行らなかった原因はCやC++やC#との差別化ができなかった所。

244 ：デフォルトの名無しさん：2010/04/15(木) 11:37:15

>>242
3じゃなくて5な

245 ：デフォルトの名無しさん：2010/04/15(木) 11:38:13

>>242
直接アドレス呼び出すなよ。
何のためのOSだよ

246 ：デフォルトの名無しさん：2010/04/15(木) 11:39:20

いやCP/Mってリングプロテクションとか特権／保護とかやってる
モダンなOSじゃないから

247 ：デフォルトの名無しさん：2010/04/15(木) 11:39:45

>>245
そういう OS だったんだから仕方ない

248 ：デフォルトの名無しさん：2010/04/15(木) 11:42:58

ああ、本当のシステムコールじゃなくてシステムライブラリを
呼ぶという話しか。

249 ：デフォルトの名無しさん：2010/04/15(木) 11:43:25

システムライブラリとはなんじゃらほい

250 ：デフォルトの名無しさん：2010/04/15(木) 11:44:27

APIのことだろう

251 ：デフォルトの名無しさん：2010/04/15(木) 11:44:49

ゲートのこっち側の、Cでリンクして呼べるようになってる
関数インタフェースのことじゃないか

252 ：デフォルトの名無しさん：2010/04/15(木) 11:47:51

おまいらこれでも見てもちつけ
ttp://www.itmedia.co.jp/news/articles/1004/14/news068.html

253 ：デフォルトの名無しさん：2010/04/15(木) 11:50:47

>>252
消えうせろゴミ

254 ：デフォルトの名無しさん：2010/04/15(木) 12:07:29

>>248 crtじゃなくてシステムコールを直接呼んでる言語があるなら挙げてみやがれ

255 ：デフォルトの名無しさん：2010/04/15(木) 12:12:19

>>248ではないが
crtってCランタイム、libcのことならまた全然別の話だろう
なんかどんどん斜め上に話が進んでるな

256 ：デフォルトの名無しさん：2010/04/15(木) 12:15:42

Unixならman 2で出てくるのがシステムコール（のAPI）
man 3で出てくるのがlibc

直呼びってMS-DOSのINT21Hとかだろ

257 ：デフォルトの名無しさん：2010/04/15(木) 12:43:20

そうだな。CPUの割り込み使って呼び出すヤツ

258 ：デフォルトの名無しさん：2010/04/15(木) 12:51:23

システムコールはOSのカーネルが提供するサービスだよ。
低級言語ってのは、そのカーネル自体を作れるレベルの低水準言語。

259 ：デフォルトの名無しさん：2010/04/15(木) 12:55:04

言い換えれば「ハード以外何もいらない」ってこと。

260 ：デフォルトの名無しさん：2010/04/15(木) 12:56:32

>>258
JavaでもLispでもGoでも、そしてこのスレの誰かさんが大好きなDでもOSを作るぐらいできるよｗ

261 ：デフォルトの名無しさん：2010/04/15(木) 13:02:18

次の名称を述べよ

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

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

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

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

5.SDKが提供する制御操作

262 ：デフォルトの名無しさん：2010/04/15(木) 13:09:23

javaでどうやってos作るの？

263 ：デフォルトの名無しさん：2010/04/15(木) 13:12:52

>>262
JNode

264 ：デフォルトの名無しさん：2010/04/15(木) 13:15:05

>>261
1 IO
2 BIOSコール
3 割り込み
4 システムコール
5 SDKが曖昧

265 ：デフォルトの名無しさん：2010/04/15(木) 13:31:14

>>263
アセンブラ入ってんじゃん
そんなのjava製とはいえん

266 ：デフォルトの名無しさん：2010/04/15(木) 13:32:21

>>265
じゃあC言語だけでOS作ってみろよｗ

267 ：デフォルトの名無しさん：2010/04/15(木) 13:32:41

>>265
アセンブラなしででは、Cでもできない。

268 ：デフォルトの名無しさん：2010/04/15(木) 14:40:05

>>236
なんだDってクソ言語じゃねーか。全く駄目だな

269 ：デフォルトの名無しさん：2010/04/15(木) 14:49:59

でもDしかないし

270 ：デフォルトの名無しさん：2010/04/15(木) 17:08:55

>>67
結局、罵倒したいだけですか。やれやれ。
ではバックアップ掲載しておきます。あとはご自分でどうぞ。

*低級言語 [#q34e2cc7]

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

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

-リンカ
--リンク

271 ：270：2010/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;

272 ：270：2010/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)

273 ：270：2010/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

274 ：270：2010/04/15(木) 17:14:47

**演算子 [#m86a3779]

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

とか
---
以上です。

275 ：デフォルトの名無しさん：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型）

276 ：デフォルトの名無しさん：2010/04/16(金) 00:08:49

wiki消えとるワロス

277 ：デフォルトの名無しさん：2010/04/16(金) 00:11:17

別に消さなくてもいいのにね。
ちょっと煽られてヽ(`Д´)ﾉﾓｳｺﾈｴﾖ!!とか、近年稀に見る耐性が低さだわ。

278 ：デフォルトの名無しさん：2010/04/16(金) 00:16:38

お前らなんて煽るだけで何もできないのにな

279 ：デフォルトの名無しさん：2010/04/16(金) 00:17:00

そうだね。

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

281 ：デフォルトの名無しさん：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型

宣言と利用が同じ形をしている。だから、美しい。

282 ：デフォルトの名無しさん：2010/04/16(金) 00:48:19

>>280
->とかキモいから全部@にしちゃえよ。

283 ：デフォルトの名無しさん：2010/04/16(金) 00:48:41

>>281
どこに a[0] とか出てくるんだ？全然美しくないだろ。
[100]int型とかアホか。Ｃの基礎から勉強してこい。
Ｃの配列と異なるというなら、そんな配列は醜すぎる。

284 ：デフォルトの名無しさん：2010/04/16(金) 00:49:26

すごくどうでもいい

285 ：デフォルトの名無しさん：2010/04/16(金) 00:56:44

>>283
> [100]int型とかアホか。Ｃの基礎から勉強してこい。

Cの話はしていない。

286 ：デフォルトの名無しさん：2010/04/16(金) 00:57:34

Ｃの場合、

char str[100];

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

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

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

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

char[] str(100);

のように宣言するのはＣを踏襲しているわけだが、
配列が宣言時のサイズによって型が違うようにするとか、Ｃの改悪で醜いもいいところ。

287 ：デフォルトの名無しさん：2010/04/16(金) 01:03:15

スタックに構造体や配列をおける言語ってC以外にある？

288 ：デフォルトの名無しさん：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型の配列のコピー

289 ：デフォルトの名無しさん：2010/04/16(金) 01:09:13

なんだ。goの話してんのかと思たわ
あれの配列は
var a [10]int
まあsliceが強力だから配列よりそっちの方使うと思うがね
unsafeでmmapをsliceに直貼り出来たのにはわろたが

290 ：デフォルトの名無しさん：2010/04/16(金) 01:11:04

goがそうなってるなら、goに習えばいいね。

291 ：デフォルトの名無しさん：2010/04/16(金) 01:12:39

->記号がマジイミフ
可読性低いし打ち辛いしばかかと

292 ：デフォルトの名無しさん：2010/04/16(金) 01:13:47

配列がコピーされてそんなにうれしいか
foo(n int) [] char { bar [n] char; return bar; }
bar [] char = foo(128);
こういうキモいこと(配列を返す関数)もできるわけか

293 ：デフォルトの名無しさん：2010/04/16(金) 01:18:40

>>292
goの例でいうと戻り値が配列の場合
書き方にもよるがコピーじゃなく
戻り側の変数に直で書かれたりする

294 ：デフォルトの名無しさん：2010/04/16(金) 01:23:43

->が可読性低いってほうがイミフ

295 ：デフォルトの名無しさん：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のものよりずっとシンプルで読み書きしやすい

296 ：デフォルトの名無しさん：2010/04/16(金) 01:25:58

実体とポインタ両方ないなんてありえん

297 ：デフォルトの名無しさん：2010/04/16(金) 01:26:46

あと、
＞p* int; // p* は int型
これ意味不明
pはint*型、じゃないの？

*intと書かせるのはキモいので、
&intと俺は書きたい。

298 ：297：2010/04/16(金) 01:27:42

ありゃ、最後の行失敗
p &int
のつもり

299 ：デフォルトの名無しさん：2010/04/16(金) 01:27:56

>>297
p は *int 型
p* は int 型

300 ：デフォルトの名無しさん：2010/04/16(金) 01:28:41

つーかメモリモデルすらわかってない奴多くね？

301 ：デフォルトの名無しさん：2010/04/16(金) 01:29:09

「奴」とかの話はいらないから。

302 ：297：2010/04/16(金) 01:29:24

>>299
ああ、意図は理解した
型宣言の話をしているのかと思ったが、*演算子を後置にするという話が
混じっていたの？
その必要が無いように思えるけど

303 ：デフォルトの名無しさん：2010/04/16(金) 01:41:00

メモリへのアドレスによる直接アクセスと、IOへの入出力と、
リアルタイムタイマの操作と、各種割り込みのトラップが出来れば
あとはなんでもいいや＞低レベル言語

304 ：デフォルトの名無しさん：2010/04/16(金) 01:43:11

アドレス以外ライブラリでいいな

305 ：デフォルトの名無しさん：2010/04/16(金) 01:44:47

>>304
安全な言語目指すなら
アドレスもライブラリでいい
効率はオプティマイズで稼げる

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

307 ：デフォルトの名無しさん：2010/04/16(金) 05:15:34

>>304
memory mapped I/O ならともかく、ポートが叩けないってことはライブラリはアセンブラで書くのか？
まあＣのio.h みたいに、マクロでインラインアセンブラが書いてあるのもありかもしれないが、
個人的にはポート型があって、コンパイラが解決してくれるほうがありがたいな。

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

てな感じ

309 ：デフォルトの名無しさん：2010/04/16(金) 06:54:18

マクロでfor文とsprintfが欲しいな

310 ：デフォルトの名無しさん：2010/04/16(金) 07:08:09

C++をdefineで好みに再定義すりゃいいやん

311 ：デフォルトの名無しさん：2010/04/16(金) 08:39:35

>>308
その86が今もって強いから問題かと。
言語的には特殊なメモリとして扱えれば十分だが。

312 ：デフォルトの名無しさん：2010/04/16(金) 09:26:39

ポインタのデリファレンスは後置単項演算子のほうがエレガントなんだっけ？

313 ：デフォルトの名無しさん：2010/04/16(金) 11:24:28

いろんな表現を発明して、それがCより優れてるとしても、Cの表現をマスターした人間にしてみれば
そんなのを再勉強するのは負担なので受け入れられないだろう。
int (*fnc)(int(*)(void)); がわからない？ハァ？勉強汁！でおわり。
逆に、勉強汁！って怒られた奴が恨みに思ってこんなスレ延ばしてるんじゃねえのかｗ

314 ：デフォルトの名無しさん：2010/04/16(金) 11:28:04

ガベコレさえあればC/C++でいいよ

315 ：デフォルトの名無しさん：2010/04/16(金) 11:57:21

どっちだよ

316 ：デフォルトの名無しさん：2010/04/16(金) 11:59:07

>>313
今ここで勉強しているのだから大いに結構

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

後置が良いってのは要するに、前置*と後置[]()が入り乱れるより
後置に統一する方が結合の順番がわかりやすい
つまり構文木の深いところから浅いところに向けて順番に並ぶのが良いということだな

317 ：デフォルトの名無しさん：2010/04/16(金) 13:51:46

>>316
下のほうが分かりにくいw

318 ：デフォルトの名無しさん：2010/04/16(金) 14:05:06

慣れの問題

319 ：デフォルトの名無しさん：2010/04/16(金) 14:05:45

ポインタ宣言のツリー構造は、K&Rにふつうに書いてあるな
問題は、膨大な情弱用コンテンツに埋もれてK&Rに辿り着けない奴が多いこと。

320 ：デフォルトの名無しさん：2010/04/16(金) 14:12:58

typedefがあるのだから、どうでもいい問題。

321 ：デフォルトの名無しさん：2010/04/16(金) 14:46:46

>>318
慣れの問題なら、C表記に慣れてる人々を切り捨てて
誰もが慣れていない新表記を押し付けるのはコスト的に不都合

322 ：デフォルトの名無しさん：2010/04/16(金) 15:22:02

>>320
それはまさに「名詞の王国」の発想
或いは、defがあるからlambdaを制限する・classがあるからスコープを制限する
のような思想

323 ：デフォルトの名無しさん：2010/04/16(金) 15:33:06

Python対Ruby、Java対C#は偶然ではないね、偶然が二度続けばなんとかって言うし

324 ：デフォルトの名無しさん：2010/04/16(金) 17:13:16

Cは一つの記号に複数の意味を持たせたものがいっぱいあるんだよな。
構文をシンプルにするためには、一つの記号に複数の意味を持たせないことだな。
ASCII文字の内、Cで使われていない@と`も含めフル活用して一意の意味付けをする。
あと、一見して意味が通じそうな<-や->みたいに、誰が見ても想像できそうな使い方は良いと思うよ。
一部分でしか使ってない<>とか#とかは文字列に置き換えて、他の部分に使ったほうがいいよ。

325 ：デフォルトの名無しさん：2010/04/16(金) 17:21:57

>>324
＞@と`も含めフル活用して一意の意味付けをする
makeの失敗の歴史も知らずに何を偉そうに語ってるんだか

326 ：デフォルトの名無しさん：2010/04/16(金) 17:34:22

アスタリスクが、ポインタが示す値の参照と掛け算の二つの意味があることで、読みにくくなることあるかな？

327 ：デフォルトの名無しさん：2010/04/16(金) 17:44:40

<が比較演算子かtemplateの引数のカッコかわからない

328 ：デフォルトの名無しさん：2010/04/16(金) 17:46:25

std::vector<std::vector<int> > hoge;
この「> >」のスペースがとっても嫌。
std::vector<std::vector<int>> hoge;
と書きたい。

329 ：デフォルトの名無しさん：2010/04/16(金) 17:47:20

>>328
いまどきのコンパイラなら書けるでしょ

330 ：デフォルトの名無しさん：2010/04/16(金) 17:49:21

>>329
どこのコンパイラで書けるのか実例を挙げてくれ

331 ：デフォルトの名無しさん：2010/04/16(金) 17:55:00

>>330
こんにちは
スレ違いです

332 ：デフォルトの名無しさん：2010/04/16(金) 17:56:26

デタラメを書く→追求される→スレ違いと言って逃げる
だから便所のラクガキなんだよ

333 ：デフォルトの名無しさん：2010/04/16(金) 18:03:00

>>329
無知カス

334 ：デフォルトの名無しさん：2010/04/16(金) 18:03:59

>>328
C++0xまでマテ
gcc なら -std=c++0x とか -std=gnu++0x でOK.

335 ：デフォルトの名無しさん：2010/04/16(金) 18:06:04

VS2010で普通に書けるが？

336 ：デフォルトの名無しさん：2010/04/16(金) 18:06:46

どっちが無知やら

337 ：デフォルトの名無しさん：2010/04/16(金) 18:10:30

>>335
そんな方言持ち出していまどき扱いされてもなあ

338 ：デフォルトの名無しさん：2010/04/16(金) 18:13:01

>>337
334が見えないのか

339 ：デフォルトの名無しさん：2010/04/16(金) 18:13:44

>>338
そんな方言持ち出していまどき扱いされてもなあ

340 ：デフォルトの名無しさん：2010/04/16(金) 18:15:46

おまえが使っているコンパイラどれだよ？

341 ：デフォルトの名無しさん：2010/04/16(金) 18:16:37

C++0xこそ方言じゃねぇか
gcc以外の何が対応してんだよ

342 ：デフォルトの名無しさん：2010/04/16(金) 18:16:46

みなさん恐れ入りますがスレ違いです

343 ：デフォルトの名無しさん：2010/04/16(金) 18:19:24

そういやテンプレ引数で比較演算子使うと上手くいかない場合があるんだよな。
こういうの
template_type< const_arg1 >= const_arg2 >

344 ：デフォルトの名無しさん：2010/04/16(金) 18:20:11

いまどきのコンパイラはだいたいC++0xに部分的に対応している
std::vector<std::vector<int>> hoge;
と書けないコンパイラの方が珍しい

345 ：デフォルトの名無しさん：2010/04/16(金) 18:25:59

C＃のパーサーはテンプレートのところでパースに失敗すると、かっこの意味を変えてパースしなおす。VS2010もそうしているんだろう。

346 ：デフォルトの名無しさん：2010/04/16(金) 18:28:55

括弧の種類を増やそうぜ
《》「」≪≫『』【】

347 ：デフォルトの名無しさん：2010/04/16(金) 18:53:02

使える記号の少なさが
言語の進化を妨げているな

348 ：デフォルトの名無しさん：2010/04/16(金) 19:04:15

そこで APL の出番だな

349 ：デフォルトの名無しさん：2010/04/16(金) 19:11:43

複数意味がある記号がたくさんあると
その組み合わせ分だけパースしなおすのか

350 ：デフォルトの名無しさん：2010/04/16(金) 21:41:37

全部()でいいよ。文法は単純な方がいい。

351 ：デフォルトの名無しさん：2010/04/16(金) 21:44:35

VBやDでは()使ってるね

352 ：デフォルトの名無しさん：2010/04/16(金) 21:44:36

　{}の方がエレガントだよ！

353 ：デフォルトの名無しさん：2010/04/16(金) 21:45:37

()の前に!つかるとかださいよね

354 ：デフォルトの名無しさん：2010/04/16(金) 22:17:48

シフトキーを押さなくてもいい記号だけにしろよ

355 ：デフォルトの名無しさん：2010/04/16(金) 22:21:29

-^\@[];:,./

356 ：デフォルトの名無しさん：2010/04/16(金) 22:25:36

101か106でも違うし…

357 ：デフォルトの名無しさん：2010/04/16(金) 23:26:42

そこでドラムセット型キーボードの出番ですよ。

358 ：デフォルトの名無しさん：2010/04/16(金) 23:39:16

F1 3C C9

359 ：デフォルトの名無しさん：2010/04/17(土) 00:06:51

俺的にC/C++のメリットはメモリ管理が確実に読めるコードが書けることにあると思う。
GC使いたいならJavaやC#のほうがよくね？

360 ：デフォルトの名無しさん：2010/04/17(土) 00:08:39

>>359
どこをとってもスレ違い

361 ：デフォルトの名無しさん：2010/04/17(土) 00:10:39

>>360
頭悪くね？

362 ：デフォルトの名無しさん：2010/04/17(土) 00:15:39

そうだね。

363 ：デフォルトの名無しさん：2010/04/17(土) 00:41:42

C9がretなのは覚えてる

364 ：デフォルトの名無しさん：2010/04/17(土) 01:31:04

お前らが語ってることって40年前の黎明期より劣ってるんだけど自覚ある？

365 ：デフォルトの名無しさん：2010/04/17(土) 01:33:53

開発不要という結論に達するまで、あと何スレかかるかな。

366 ：デフォルトの名無しさん：2010/04/17(土) 01:36:05

ってかむしろ開発不能というのが近い気が…

367 ：デフォルトの名無しさん：2010/04/17(土) 01:37:09

開発できるような奴もいないだろ

368 ：デフォルトの名無しさん：2010/04/17(土) 01:39:03

ちんけな最適化でよければ、Cコンパイラぐらいは書ける。

369 ：デフォルトの名無しさん：2010/04/17(土) 01:39:45

template「class T」
void f()
{
vector「Ｔ」 v;
}

370 ：デフォルトの名無しさん：2010/04/17(土) 01:43:35

Cのマクロを廃止して、今、マクロで行われていることの多くができる構文を導入したもの。
今のCでは、マクロが原因でIDEの支援がどうしても限定的で不正確になってしまっている。

371 ：デフォルトの名無しさん：2010/04/17(土) 01:51:13

トランスレーター作ったことあるけどパーサーも抽象構文木の解釈処理も結構手間だ

372 ：デフォルトの名無しさん：2010/04/17(土) 01:53:19

確かに、難しくはないが、面倒くさいな。

373 ：デフォルトの名無しさん：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とかｲﾁｲﾁ書くのアホ臭い。

374 ：デフォルトの名無しさん：2010/04/17(土) 02:12:01

Common Lispのマクロってどんな感じなの？

375 ：デフォルトの名無しさん：2010/04/17(土) 03:09:53

なんでもできる。

376 ：デフォルトの名無しさん：2010/04/17(土) 04:28:53

何でもできるってOS書けるの？

377 ：デフォルトの名無しさん：2010/04/17(土) 05:07:18

"OS"

378 ：デフォルトの名無しさん：2010/04/17(土) 05:22:31

http://gist.github.com/46417

とりあえず、こんなかんじでよろ

379 ：デフォルトの名無しさん：2010/04/17(土) 08:35:07

>>370
糞重いIDEなんて使う気にならないからどうでもいい

380 ：デフォルトの名無しさん：2010/04/17(土) 09:04:46

シンプルな低級言語を設計する話が、なんで複雑な最新技法の導入の話になってんの?
boostっぽいのとか全部すれ違いな気が…

381 ：デフォルトの名無しさん：2010/04/17(土) 09:49:20

構文に美しさを求める人たちと、とにかく速くしたいと思う人たち

そのやり取りを上から眺めてニヤニヤしている、初代スレの>>1

382 ：デフォルトの名無しさん：2010/04/17(土) 10:29:46

構文どうこう言ってる奴らは消え失せろ
スレ違いだ

383 ：デフォルトの名無しさん：2010/04/17(土) 10:56:05

>>379
お前みたいなレガシーは、絶対少数派だから発言しなくていい。

384 ：デフォルトの名無しさん：2010/04/17(土) 11:04:53

>>383
多数派に属さないと怖くて意見も言えないんですね（ﾌﾟ

385 ：デフォルトの名無しさん：2010/04/17(土) 11:07:31

統計学的にも達人より初級者の方が多数派なのは明らかだしなあ

386 ：デフォルトの名無しさん：2010/04/17(土) 11:09:19

統計出すまでもなく論理的にそうだろう

387 ：デフォルトの名無しさん：2010/04/17(土) 11:11:04

新言語を設計するなら、IDEのことを考慮するのは当然。

388 ：デフォルトの名無しさん：2010/04/17(土) 11:13:55

考慮は当然だがテキストエディタだけでも書きやすいほうがいいね。

389 ：デフォルトの名無しさん：2010/04/17(土) 11:15:58

IDEごときに脳まで侵されてるんだな、可哀想に。
こんな人が他所の環境に異動にならないことを祈るばかりだ。

390 ：デフォルトの名無しさん：2010/04/17(土) 11:23:36

>>379
Intel Core i7あたりのPC買って、何かIDE試してみなよ。便利だぞ。

391 ：デフォルトの名無しさん：2010/04/17(土) 11:27:17

便利だがキャリアの長いプログラマは慣れたエディタでのノウハウも捨てがたいからな。
ほとんどIDE上のエディタ機能いらないことも多い。併用するだろ。

392 ：デフォルトの名無しさん：2010/04/17(土) 11:54:07

IDEが言語に合わせろよ

393 ：デフォルトの名無しさん：2010/04/17(土) 12:02:22

Eclipse ＋プラグイン

394 ：デフォルトの名無しさん：2010/04/17(土) 12:03:31

統合開発したいと言われても胸が熱くならないな
ピンポイントで具体的なモチベーションがないと

395 ：デフォルトの名無しさん：2010/04/17(土) 12:50:04

IDE使っていないやつは、IDEによって省力化できるところに、労力を費やしている。

396 ：デフォルトの名無しさん：2010/04/17(土) 12:52:28

使い慣れた道具ってものがあるからIDE使うのは強制しないけど、
IDEを馬鹿にするのはおかしい。

397 ：デフォルトの名無しさん：2010/04/17(土) 12:52:52

俺様はデバッガーの使い方分かんないけどな

398 ：デフォルトの名無しさん：2010/04/17(土) 13:08:20

デバッガなんて作るもんで使うもんじゃねえな
エディタはemacsとviあればいいっしょ

399 ：デフォルトの名無しさん：2010/04/17(土) 13:14:38

楽できるのなら楽をする
自分でやるな機械やらせろ
人間が機械にあわせてやる必要はない、機械が人間にあわせればいいんだ

なぜかデジャブが

400 ：デフォルトの名無しさん：2010/04/17(土) 13:22:06

IDEは結局ターゲット変えたらやり直しだから経験不足のやつほどメリット強調しやすい

401 ：デフォルトの名無しさん：2010/04/17(土) 13:26:32

マクロやPerlのような言語による省力化もあるんだが、GUIと相性悪くて
お互いに相手が原因だと言って譲らない状態

402 ：デフォルトの名無しさん：2010/04/17(土) 14:39:56

自分が新言語に求めるものって

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

かな

403 ：デフォルトの名無しさん：2010/04/17(土) 14:42:31

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

404 ：デフォルトの名無しさん：2010/04/17(土) 14:44:21

正解は

低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)

405 ：デフォルトの名無しさん：2010/04/17(土) 14:45:58

「C/C++に代わる」の意味考えてないだろ

406 ：デフォルトの名無しさん：2010/04/17(土) 14:47:03

>>405
考えるとどうなるの？

407 ：デフォルトの名無しさん：2010/04/17(土) 14:50:30

え？

408 ：デフォルトの名無しさん：2010/04/17(土) 14:52:47

>>404
それなら C/C++ で充分

409 ：デフォルトの名無しさん：2010/04/17(土) 14:54:01

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

410 ：デフォルトの名無しさん：2010/04/17(土) 14:56:03

他言語に置き換えられてない部分といったら
OS/デバドラ/組み込み/ネイティブアプリ/過去のコード資産
あたり？

411 ：デフォルトの名無しさん：2010/04/17(土) 14:57:40

>>410
新言語はまだ他言語に置き換えられるほど普及していないよ。

412 ：デフォルトの名無しさん：2010/04/17(土) 15:04:29

>>409
ごめん
じゃあ言い換える

>>404 の主張は新たな言語の目的としてはおかしい(C/C++があるから)

413 ：デフォルトの名無しさん：2010/04/17(土) 15:21:10

＞今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、

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

414 ：デフォルトの名無しさん：2010/04/17(土) 15:23:04

コードを書くたびにプログラム観が変わるんだが
プログラム言語の研究者って実際の実用コードどのくらい書いてるんだ？

415 ：デフォルトの名無しさん：2010/04/17(土) 15:25:43

お前の業務経歴なんか、しるか。

416 ：デフォルトの名無しさん：2010/04/17(土) 15:39:43

今の時点でリテラルに機能を乗っけようとしているやつは気にしているやつは何を考えているね？
まずは>2-4(のさらに低水準寄り）の議論しろよ。

417 ：デフォルトの名無しさん：2010/04/17(土) 15:47:44

>>416
お前がしたい話があるなら、他の話を遮るのではなく、お前が主導してお前の話したい話を話せ。

418 ：デフォルトの名無しさん：2010/04/17(土) 16:10:04

素で書いても書きやすく、IDEの支援があればなお書きやすくなるような言語仕様がいいな。

419 ：デフォルトの名無しさん：2010/04/17(土) 16:52:42

プ板でやれ

420 ：デフォルトの名無しさん：2010/04/17(土) 16:55:12

>413
Cはすでに実在する
>もしもCが発明されていなかったとして
は無意味
>現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで
>一から低レベルなシステム開発のためのプログラミング言語を作るとしたら
最先端の研究成果はCが発明されていたから得られた

421 ：デフォルトの名無しさん：2010/04/17(土) 17:04:28

思考実験を無意味となｗ

422 ：デフォルトの名無しさん：2010/04/17(土) 17:05:30

無意味な思考実験

423 ：デフォルトの名無しさん：2010/04/17(土) 17:07:51

歴史のifみたいなもんで
そういう妄想を楽しめる人には無意味ではないんじゃないの
ま、そういう妄想を理解する必要は無いし、つまらなかったら見なければ良い

424 ：デフォルトの名無しさん：2010/04/17(土) 18:03:39

思考実験でCがなかったとするなら
CじゃないXがあったと仮定してもいいけど
Xで最先端の研究成果を導き出すのが筋

425 ：デフォルトの名無しさん：2010/04/17(土) 19:13:33

オレの思考実験では今頃人間以上のAIを持つメイドロボが身のまわりの世話をしてくれてるはずなんだが

426 ：デフォルトの名無しさん：2010/04/17(土) 19:16:15

>>413
過去に超一流の研究者が出した成果がCだからな
当時からコンピュータアーキテクチャの
基本が変わってない以上
低レベルな言語はCを超えれない

427 ：デフォルトの名無しさん：2010/04/17(土) 19:19:59

>>426
でもCは当時のコンピューターを想定して作ってるから
現代においては色々と時代錯誤な部分が確実にあるよ
世の中の流れはセキュリティ最優先なのにオーバーフローを考慮しない標準ライブラリとか
精度も生成結果も笑えるレベルの擬似乱数とか

428 ：デフォルトの名無しさん：2010/04/17(土) 19:27:40

Cには代わらないなあ

429 ：デフォルトの名無しさん：2010/04/17(土) 19:29:13

究極の言語だからな。

430 ：デフォルトの名無しさん：2010/04/17(土) 19:30:42

>>427
セキュリティよりも速度を追求する場合があるから
標準ライブラリならあれでいい

431 ：デフォルトの名無しさん：2010/04/17(土) 19:33:08

>>430
速度の問題ではないと思うんだが

get()は論外
strlcpy()やsnprintf()などは標準で用意されているべき

432 ：デフォルトの名無しさん：2010/04/17(土) 19:34:01

なんでも用意されてる言語があるだろｗ

433 ：デフォルトの名無しさん：2010/04/17(土) 19:34:04

scanfは最初から糞だったと思うぞ

434 ：デフォルトの名無しさん：2010/04/17(土) 19:35:12

標準っていうかCの実証実験で適当に作ったサンプルがそのまま（ｒｙ

435 ：デフォルトの名無しさん：2010/04/17(土) 19:35:40

オーバーフロー前提の演算ができなくなったら
ゲロ遅になって困るだろ

436 ：431：2010/04/17(土) 19:35:55

- get()
+ gets()
だ、すまん

437 ：デフォルトの名無しさん：2010/04/17(土) 19:36:28

まさか自分でバッファサイズのチェックも出来ないゆとりグラマが
幅をきかせるとは、当時の誰にも予測不可能だったからな。

438 ：デフォルトの名無しさん：2010/04/17(土) 19:36:37

>>435
多分「バッファオーバーフロー」のことを言っているのだと思うよ

439 ：デフォルトの名無しさん：2010/04/17(土) 19:38:53

>>437
gets()でセキュアなコードを書けると思うのなら
ぜひ書いてみてくれ

440 ：デフォルトの名無しさん：2010/04/17(土) 19:39:44

可変長構造体とか確保するときに
struct hoge {
int length;
char buf[0];
};
struct hoge *p = (struct hoge *)malloc(sizeof(struct hoge) + 123);
とか出来て便利なんだよ

441 ：デフォルトの名無しさん：2010/04/17(土) 19:40:43

>>440
今はセキュアでない「ライブラリ」の話だから
ランタイムで配列の境界チェックをしろとは誰も言ってないと思うよ

442 ：デフォルトの名無しさん：2010/04/17(土) 19:40:45

>>438
バッファオーバー風呂じゃなくて
バッファオーバーランでは？

443 ：デフォルトの名無しさん：2010/04/17(土) 19:41:19

>440
それができるのはC99からだから

444 ：デフォルトの名無しさん：2010/04/17(土) 19:41:56

>>441
ん?
そのポインタをセキュアなライブラリに渡したらどうなるか？って話でしょ

445 ：デフォルトの名無しさん：2010/04/17(土) 19:42:01

>>442
質問する前に目の前の箱を使ってぐぐればいいのに

446 ：デフォルトの名無しさん：2010/04/17(土) 19:43:25

>>444
いや今の議論の流れで分かるでしょ
gets()はプログラマサイドでバッファオーバーフローを回避する手段が
一切存在しないから、設計として非セキュア
そういうレベルの話だと思うが

447 ：デフォルトの名無しさん：2010/04/17(土) 19:44:16

>>446
>strlcpy()やsnprintf()などは標準で用意されているべき

これ書いたのは？

448 ：デフォルトの名無しさん：2010/04/17(土) 19:45:59

Cの作者の最大の誤算はここまで広く使われるとは思っていなかったことだろうな

449 ：デフォルトの名無しさん：2010/04/17(土) 19:46:02

標準ライブラリやセキュリティのはなしはもう他の言語が改善してるじゃん

450 ：デフォルトの名無しさん：2010/04/17(土) 20:06:30

こんなのを発見した。
ttp://ci.nii.ac.jp/naid/110002896056/

こういった発想の方がいいんじゃない？C/C++のつまらん枝葉の議論するよりかマシだと思うけど。

451 ：デフォルトの名無しさん：2010/04/17(土) 20:14:58

C99 の次はまだ出ないのかなあ。

452 ：デフォルトの名無しさん：2010/04/17(土) 20:18:42

言語とライブラリの話をごっちゃ混ぜにするやつらがいる

453 ：デフォルトの名無しさん：2010/04/17(土) 20:31:34

>>426
言語やアーキテクチャとは関係ない話
セキュリティなんてライブラリの話
C自体はポインタやランタイムの範囲チェックはないが
それ故に組込からスパコンまで使えるスケーラビリティになってる

Cは神の様な一流が実験より実用を目指して作って成功した言語だよ
簡単に超えれないのは当然

454 ：デフォルトの名無しさん：2010/04/17(土) 20:34:38

バッファオーバーは言語仕様の問題といっていいでしょう。
でもＣはそれがコンセプトだからね。どういうコンセプトにしたいかが問題。

455 ：デフォルトの名無しさん：2010/04/17(土) 20:36:46

>>451
gcc にgnu99+ms-extensionで使いたい俺
次の標準には無名のメンバに
他で定義したのを使えるようにして欲しい

456 ：デフォルトの名無しさん：2010/04/17(土) 20:38:46

>>453
あ、日本語おかしいかった
ポインタや配列のランタイムの範囲チェックな

457 ：デフォルトの名無しさん：2010/04/17(土) 20:58:07

Cに何を乗せるか話し出すといる要らないで話が進まなくなるから
要らないものや使いにくい部分を外す方からはなさないか？

458 ：デフォルトの名無しさん：2010/04/17(土) 21:18:23

このスレまだ続いてたんだ

459 ：デフォルトの名無しさん：2010/04/17(土) 21:45:49

思考実験のネタスレで本当に言語作ろうとしてたのかｗ

460 ：デフォルトの名無しさん：2010/04/17(土) 21:53:56

いろんな言語の原理主義者達がお互いを罵り合ってるだけで思考実験すら成立していない

461 ：デフォルトの名無しさん：2010/04/17(土) 21:54:59

ここでいい案が出たって誰も何も作らないんだから、本気で考えるわけがないし。

462 ：デフォルトの名無しさん：2010/04/17(土) 21:56:36

おれは案持ってるから自作中。
あと２年生きてられたら読み出せるから期待してくれ。

463 ：デフォルトの名無しさん：2010/04/17(土) 22:22:31

俺もForth系を自作中。
俺言語設計するのは楽しいよな。

464 ：デフォルトの名無しさん：2010/04/17(土) 22:27:40

つーかいい加減飽きろよ

465 ：デフォルトの名無しさん：2010/04/17(土) 22:58:12

「どうせできない」と言ってるバカには一生できない

466 ：デフォルトの名無しさん：2010/04/17(土) 23:08:11

じゃあお前は出来るのかと言われるだけ

467 ：デフォルトの名無しさん：2010/04/17(土) 23:10:24

Cに代わる物なら、実装はそんなに難しくないだろうし、そうでなければならない。

468 ：デフォルトの名無しさん：2010/04/17(土) 23:12:11

>>454
その「Cのコンセプト」って後付けの理由としか思えないんだよね
gets()なんかは立案当時のコンピュータのメモリがプアすぎてオーバーフローが起きるような使い方自体が難しかった
それにセキュアな設計といってもfgets()のようにほんの少しの工夫で解消されるもんだよ
セキュア=劇的に重くなるってのは単なる先入観だね

469 ：デフォルトの名無しさん：2010/04/17(土) 23:14:53

ライブラリの不出来は作り直せばいいだけだから

470 ：デフォルトの名無しさん：2010/04/17(土) 23:17:35

言語と関係ないライブラリの話を出すな

471 ：デフォルトの名無しさん：2010/04/17(土) 23:17:48

>>430
>>435
みたいな奴に言ってるんじゃないのかな

472 ：デフォルトの名無しさん：2010/04/17(土) 23:19:53

ForthだとかLispだとか、永遠に普及しないからやるだけ無駄

473 ：デフォルトの名無しさん：2010/04/17(土) 23:20:34

>>457
auto、externは要らない
関数と関数ポインタは同一視していい
メンバアクセス演算子は.だけでいい

配列とポインタの関係はもっと綺麗にできないものだろうか

474 ：デフォルトの名無しさん：2010/04/17(土) 23:24:52

組み込み型としての配列は廃止して、ポインタによるアドレス演算のシンタックスシュガーにすればいい

475 ：デフォルトの名無しさん：2010/04/17(土) 23:27:19

スタックに配列つくれないなんて許せん

476 ：デフォルトの名無しさん：2010/04/17(土) 23:28:36

>>475
それはalloca()でいいんだろうけど
構造体のメンバや、static記憶クラスの配列はどうするんだろう

477 ：デフォルトの名無しさん：2010/04/17(土) 23:30:44

>>470
標準ライブラリの実装は実装者に依存するが
どういう機能をもった関数を揃えるか？は言語設計の範囲だよ

478 ：デフォルトの名無しさん：2010/04/17(土) 23:31:19

スタティックに配列作れなきゃmallocをライブラリやアセンブラなしにかけないな

479 ：デフォルトの名無しさん：2010/04/17(土) 23:32:38

気に入らなきゃライブラリを作り直せばいい

480 ：デフォルトの名無しさん：2010/04/17(土) 23:33:04

構造体の中のみ、配列を許すようにしたらいい。

481 ：デフォルトの名無しさん：2010/04/17(土) 23:43:25

後置がよい理由は:演算子を使って型を指定する場合に

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

goが面白いところは
var a int;
と書いてvarを後置２項演算子（式を２つ取るってこと）と考えれば
名前は基本的にごにょごにょ書く必要ないのに対して型は
いろいごにょごにょ書くことに対して分かりやすいだろうというのがあります。
ただ、goの２項演算子方式だと、型推論を行いたいと思った場合に出来なくなることです。
新しい低レベル言語に型推論の機能が必要か、不必要かは議論が分かれるところだと思います。
ただ、似たような表記のより高レベルな言語を作成した場合はそのことが問題となるでしょう。
新しい低レベル言語は現在のC言語とそれに似た言語となる高級言語の元となるような形であるべきです。
となると、型指定演算子あるいは命名演算子があるとよいと考えます。
そして、その演算子として最有力候補が:です。

482 ：デフォルトの名無しさん：2010/04/17(土) 23:45:17

>>481
Scalaかな

483 ：デフォルトの名無しさん：2010/04/17(土) 23:45:55

記憶クラスの解釈をインテリジェントにしてはどうか？
内部的な処理の違いは隠蔽するようにして

484 ：デフォルトの名無しさん：2010/04/17(土) 23:46:20

>>468
getsはメモリがプアなマシン用にはあったほうがよいけど
メモリが沢山ある場合はよくないので、今の時代に合わせて
fgetsを推奨、getsは非推奨ってことで。非推奨だけどプアなマシン用に必要になったら入れていいと。

485 ：デフォルトの名無しさん：2010/04/17(土) 23:47:29

>>484
それって「標準ライブラリ」の範囲で言及する必要があるの？

486 ：デフォルトの名無しさん：2010/04/17(土) 23:56:52

潜在的な脆弱性を取り除けないものは入れるべきではないと思うんだが
gets()を利用した方がいいケースなんて本当にあるのか？

487 ：デフォルトの名無しさん：2010/04/18(日) 00:01:15

すれ違い

488 ：デフォルトの名無しさん：2010/04/18(日) 00:01:57

関数の引数が2ワード増えただけで困る環境って、ちょっと想像がつかない
その環境ってC言語が本当に使えるの？

489 ：デフォルトの名無しさん：2010/04/18(日) 00:09:10

困る困らないじゃなくて、
データ列が欲しいだけなのに、最大サイズとか指定するのがウザ過ぎるって話だろ。

490 ：デフォルトの名無しさん：2010/04/18(日) 00:15:01

んなもん
#define gets(s) fgets(s, INT_MAX, stdin)
とでも定義すれば？

491 ：490：2010/04/18(日) 00:15:47

もちろん「自分で」ね
標準ライブラリにこんなもん入れろとか馬鹿げてる

492 ：デフォルトの名無しさん：2010/04/18(日) 00:17:12

釣り…だろうな

493 ：デフォルトの名無しさん：2010/04/18(日) 00:51:33

マクロとか要らない
マクロ使いたい奴はC使えばいい

494 ：デフォルトの名無しさん：2010/04/18(日) 00:55:08

Lisp並に強力なマクロが欲しい

C程度のマクロ入らない

495 ：デフォルトの名無しさん：2010/04/18(日) 00:59:27

なんかＣの偉大さを痛感するスレだなｗ

496 ：デフォルトの名無しさん：2010/04/18(日) 01:04:27

>>494
「Lispマシンが流行っていたら」という仮定の思考実験を行えば
Lisp一つで低級から高級までカバーできるね

497 ：デフォルトの名無しさん：2010/04/18(日) 01:06:04

関数型をネイティブに処理できる計算機開発してから言ってくれ

498 ： [―{}@{}@{}-] デフォルトの名無しさん：2010/04/18(日) 01:10:39

お前らの１００倍頭のいいやつが作って、
お前らの１０００倍頭のいいやつらが何十年もかかって、
誰も完全に代替できなかったのがＣな。

コピペにもあるけど、これまで誰もしてこなかったことってのは、
「思いつかなかったこと」じゃなくて、
「思いついて試したけど失敗したり、そもそも最初から意味のなさを悟ったから、
　誰も成果をあげてないだけのこと」なんだよね。

499 ：デフォルトの名無しさん：2010/04/18(日) 01:21:24

だからその頭のイイ奴らが、今、１から低級言語を開発したらどうなるかを考えるのがこのスレの趣旨だろ。

30年前はCになったが、今ならCと完全に同じものには絶対にならない。

500 ： [―{}@{}@{}-] デフォルトの名無しさん：2010/04/18(日) 01:23:07

頭のいい奴らが考えることを、頭が悪いやつらが想像することほど馬鹿らしいことはないよ。

501 ：デフォルトの名無しさん：2010/04/18(日) 01:31:02

>496
LispマクロとLispマシンはあんまり関係がない。

Lispマクロと引数を評価しない関数、スタックを作らない関数(強制inline)は欲しいなぁ。

502 ：デフォルトの名無しさん：2010/04/18(日) 01:31:18

今なら C より良いものができるに違いない。

503 ：デフォルトの名無しさん：2010/04/18(日) 01:51:02

型安全なマクロが欲しい。

504 ：デフォルトの名無しさん：2010/04/18(日) 02:12:50

コボラーがJavaやるみたいなもんか

505 ：デフォルトの名無しさん：2010/04/18(日) 02:18:08

どういう意味？

506 ：デフォルトの名無しさん：2010/04/18(日) 02:18:51

言い換えれば、コボラーがJavaやるみたいなもんだってことになるだろ

507 ：デフォルトの名無しさん：2010/04/18(日) 02:19:35

なんだ、そういう意味か。

508 ：デフォルトの名無しさん：2010/04/18(日) 02:27:21

JavaってC/C++の反省を元に云々っていう開発の触れ込みがあったけど
現状はコボラーの置き換えにしか使われていないという罠

509 ：デフォルトの名無しさん：2010/04/18(日) 02:29:06

すべてをリプレイスするわけじゃないけど領域を奪ってはいるな。

510 ：デフォルトの名無しさん：2010/04/18(日) 02:32:39

>>503
インライン関数で出来なくてマクロが必要ってどういう用途？

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

512 ：デフォルトの名無しさん：2010/04/18(日) 02:48:34

日本語で書ける言語作れよ

513 ：デフォルトの名無しさん：2010/04/18(日) 02:53:50

すれ違いもはなはだしい

514 ：デフォルトの名無しさん：2010/04/18(日) 03:19:29

基本的なデータ構造（アレイ、リスト、スタック、キュー等）は標準で扱えるようにしてくれ。

515 ：デフォルトの名無しさん：2010/04/18(日) 03:27:55

ライブラリの話はあまり意味ない

516 ：デフォルトの名無しさん：2010/04/18(日) 03:32:22

まあね

517 ：デフォルトの名無しさん：2010/04/18(日) 03:32:52

>>481
ありゃ宣言文でしょ。式じゃないし
型推論も右辺値で決まるし同じやり方
記憶クラスの推論が難しそうだがやってるね
スコープから出そうならヒープ
出なさそうならスタックとか
Cより上のC++,java狙いかな
kenさんは神々の一人だから勉強になる

518 ：デフォルトの名無しさん：2010/04/18(日) 03:42:40

>>514
同意。Cの標準ライブラリは抜けが多すぎる。

519 ：デフォルトの名無しさん：2010/04/18(日) 03:47:16

>>490
意味不明過ぎるだろ

getsなんて遥か以前から問題になってるから
今時使うヤツはほとんどおらん

520 ：デフォルトの名無しさん：2010/04/18(日) 03:48:45

>>511
型安全とは全く関係ない例だなw

521 ：デフォルトの名無しさん：2010/04/18(日) 08:05:08

C言語の記号を多用した仕様はパーサの負荷を軽減するためのものだが
結果としてプログラマのタイプ量を減らす効果もあった。
C言語が無ければ同じ時間でプログラミングできる量は減っている。
つまり今日のコンピューティングの進歩も無かったことになる。

522 ：デフォルトの名無しさん：2010/04/18(日) 08:14:58

>>521
パーサーの負担は変わらない。

523 ：デフォルトの名無しさん：2010/04/18(日) 08:24:16

昔のパソコンの低スペック差をなめんな

524 ：デフォルトの名無しさん：2010/04/18(日) 08:31:18

攻撃されてもシステムを止めないCコンパイラの新たなアイデア
http://itpro.nikkeibp.co.jp/members/NBY/ITARTICLE/20050525/161456/

これパクろうぜ

525 ：デフォルトの名無しさん：2010/04/18(日) 08:51:50

>>524
これってCの言語仕様を変えてないか？

526 ：デフォルトの名無しさん：2010/04/18(日) 08:57:24

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

>>517
ScalaやActionScript、haXe等が宣言文であることは知ってますよ。
でもこれらは式ベースな言語ではないのではないでしょうか？
式ベースで言語を考えれば481のような考えになるという話です。
型を:で指定できるのはHaskell,Ocaml,Cleanもそうです。
Cleanはマクロを標準で持っている。
だから新しい言語は式ベースで作ったらいいのでは？と。
BNFベースで考えれば、いつまでも、Algolと同じだって言われることになる。

527 ：デフォルトの名無しさん：2010/04/18(日) 08:59:39

長文って内容０が多いよなwww

528 ：デフォルトの名無しさん：2010/04/18(日) 09:27:49

何時になったら「作ろうとしても無理」て結論に落ち着くのｗ

529 ：デフォルトの名無しさん：2010/04/18(日) 09:32:44

実装は難しくないから、無理という結論にはならないな。無駄ならわかる。

530 ：デフォルトの名無しさん：2010/04/18(日) 09:34:49

>>525
どうやって実現(実装)するか？は、言語仕様に含まれない
例えばスタックを使わずに関数の制御が実現できるなら、別にスタック自体使わなくてもいい

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

言語仕様と実装の区別とはそういうこと

531 ：デフォルトの名無しさん：2010/04/18(日) 09:41:25

>>524
ローカルのデータをコールスタックと別のスタックにとれば解決すること。
既存のライブラリとの互換取れなくてもいいなら、難しくもない。
何やってるんだ。

532 ：デフォルトの名無しさん：2010/04/18(日) 09:49:45

>>530
ポインターは言語仕様としてはどれほどはっきり定義されてるんだっけ？
一応指した物は勝手に動き回らないというのは約束事にはないのかな？　

533 ：デフォルトの名無しさん：2010/04/18(日) 09:58:22

物理メモリはどこ指してるか判らんときもあるぞ

534 ：デフォルトの名無しさん：2010/04/18(日) 10:02:36

>>532
勝手に動き回るの意味がよくわからんが
指しているものが意図しないものだったら誤動作するかもね、ってだけでしょ
ちゃんと整合性を取りつつ参照先を変えるのは何ら問題ない
つーかそれがポインタのアイデンティティだし

535 ：デフォルトの名無しさん：2010/04/18(日) 10:02:41

物理メモリ上でいくら動いても
「アドレス」さえ変わらなければ問題ないと思う
実際、仮想メモリ使ってるとそうなってるし

536 ：デフォルトの名無しさん：2010/04/18(日) 10:33:32

>>534
> 勝手に動き回るの意味がよくわからんが

>>524の記事によると、

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

だから、指してる先が移動して、参照も書き換えますよって言っているけど、
アドレス計算とかしてさらにそれをどっかにコピーしたのとか追従できるのかな？

537 ：デフォルトの名無しさん：2010/04/18(日) 11:36:09

これだけ伸びてるのに仕様書一つもうｐするやつがいないとかレベル低すぎ

538 ：デフォルトの名無しさん：2010/04/18(日) 11:37:02

>>520
だから、

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

こんなふうにしたいってことじゃないの。

539 ：デフォルトの名無しさん：2010/04/18(日) 12:28:26

>>536
それは勝手に動き回ってるんじゃなくて、ちゃんと整合性を保ってるじゃん

540 ：デフォルトの名無しさん：2010/04/18(日) 12:31:59

>>536
それは、プラットフォームの仮想化レイヤーが備える機能であって、言語が備える機能ではないんじゃないの。

541 ：デフォルトの名無しさん：2010/04/18(日) 13:03:11

>537
俺言語開発で忙しいから任せた。

542 ：デフォルトの名無しさん：2010/04/18(日) 13:05:03

>>537
仕様書一つくらいお前がうｐすればいいだろ馬鹿

543 ：デフォルトの名無しさん：2010/04/18(日) 13:07:10

>>538
#define call(n) (1 ## n), func_ ## n()

整数値のみを要求するなら
これで大体いける

544 ：デフォルトの名無しさん：2010/04/18(日) 13:07:53

あ、全体を括弧で囲み忘れた

545 ：デフォルトの名無しさん：2010/04/18(日) 13:12:19

>>543
で、そんな奇っ怪な表現ではなく、「nは整数ですよ」と明に素直に書けるようにしたいよね。

546 ：デフォルトの名無しさん：2010/04/18(日) 13:14:55

#define IS_DIGIT(n) (1 ## n)
#define call(n) (IS_DIGIT(n), func_ ## n())

547 ：デフォルトの名無しさん：2010/04/18(日) 13:22:29

そういうテクニックを使ったときの問題点は
コンパイルエラーが起きたときに、その原因が分からないこと

548 ：デフォルトの名無しさん：2010/04/18(日) 13:26:58

そこでconceptですよ。

549 ：デフォルトの名無しさん：2010/04/18(日) 13:36:51

増築を繰り返して糞化したC++みたくならないようにしないとな。

550 ：デフォルトの名無しさん：2010/04/18(日) 13:40:59

スレの流れからしてCからC++のような物を作ろうとしているようにしか見えないがな
まさに車輪の再開発

551 ：デフォルトの名無しさん：2010/04/18(日) 13:44:57

70年代の車輪はまだ使えるけど、擦り切れてスリップもするし燃費も悪い。
だから、2010年の今、優秀な技術者が新しい車輪を作ったらどうなるだろうかを考えてみるってことだろ。

552 ：デフォルトの名無しさん：2010/04/18(日) 13:47:58

エンジンがパワーアップして、ボディーもいろいろカッコいいのが出てきてるからな。
道も良くなったし。

そろそろ、車輪も新しくしたいよね。

553 ：デフォルトの名無しさん：2010/04/18(日) 13:50:13

#define IS_DIGIT(n) (1 ## n ## 0)

じゃないと n が suffix として有効な時にダメだったわ

554 ：デフォルトの名無しさん：2010/04/18(日) 13:51:37

そんな機能いらん

555 ：デフォルトの名無しさん：2010/04/18(日) 13:56:45

車輪を新しくってCのリサイクルじゃんｗ

556 ：デフォルトの名無しさん：2010/04/18(日) 13:57:14

>>551
＞燃費も悪い
燃費は最高にいいだろ何言ってんだぼけ

557 ：デフォルトの名無しさん：2010/04/18(日) 13:59:56

2010年の今なら車輪のない乗り物で良くね？

558 ：デフォルトの名無しさん：2010/04/18(日) 14:01:13

大昔の未来想像図みたいな絵本思い出した

559 ：デフォルトの名無しさん：2010/04/18(日) 14:04:20

Cがなかったとして。という思考実験であっても、いまの流行技術でつくったとして
今のC/C++のどこが問題だったものが、どう改善されるかの検討なければ意味ない。
かつその問題意識はCの方向性としての「低級言語」という視点からのものでなければならない。

560 ：デフォルトの名無しさん：2010/04/18(日) 14:21:13

そこまでは素人の考え、それが前提。

561 ：デフォルトの名無しさん：2010/04/18(日) 14:23:41

Cがなかったとして、って、事実でない仮定からスタートしてるが、数学の重要な定理を知らんのか？
「正しくない仮定からはどんな結論でも導き出せる」
だからこんなスレいくら続けたってムダ。

562 ：デフォルトの名無しさん：2010/04/18(日) 14:25:58

>>540
ランタイムと混同してるな
言語でやるなら二重間接にしないと
仮想アドレスはそんなに粒度高くできないし

563 ：デフォルトの名無しさん：2010/04/18(日) 14:28:48

>>561
ここって遊び／暇つぶし／ネタじゃないの？
マジでやってるんなら厨二入ってるなと思うけど
遊びならマジで突っ込むのは無粋だな

564 ：デフォルトの名無しさん：2010/04/18(日) 14:30:14

遊びとしてルールが破綻していると言われてるんだろ

565 ：デフォルトの名無しさん：2010/04/18(日) 14:32:10

>>564
もっと楽しいルールにしろということか
言いたいことは分かるが、つまらんのなら見なければいいんじゃないの

566 ：デフォルトの名無しさん：2010/04/18(日) 14:34:02

>>561
最初のスレからわかってる奴はわかってたんだが、アホの>>1がしつこく繰り返したあげく、
次スレ立てやがったからな。
誰も同意してないてのに。

567 ：デフォルトの名無しさん：2010/04/18(日) 14:35:50

>>565
俺が言ってんじゃねーよ
そもそもこのパートスレの１スレ目の最初の>>1は、お前が言うところの厨二で
最初はノリノリであれこれ言ってたが、それは無理だと突っ込まれて消えたし

568 ：デフォルトの名無しさん：2010/04/18(日) 14:39:30

>>567
なんだ、>>1って消えたのｗ
ま、レスついてるってことは需要あるんじゃないの
需要なくなったらスレなんて自然消滅する
2chってそういうとこだと思うけど

君はなんでこんなところ見てるの？

569 ：デフォルトの名無しさん：2010/04/18(日) 14:41:24

「最新のプログラミングパラダイム」とかいいながら、そもそもプログラムがどう動作しているかも知らなそうだったしなぁ。
ちっとは低水準を議論できるレベルになっていれば良かったのにな。

570 ：デフォルトの名無しさん：2010/04/18(日) 14:41:38

ifの世界でのプログラミング言語を語る馬鹿スレ

571 ：デフォルトの名無しさん：2010/04/18(日) 14:43:09

>>568
アホな妄想に突っ込むため

572 ：デフォルトの名無しさん：2010/04/18(日) 14:43:45

>>571
言わずもがなだったなｗ
すまん

573 ：デフォルトの名無しさん：2010/04/18(日) 14:44:25

思考実験って知らない奴が数学語ってるのか

574 ：デフォルトの名無しさん：2010/04/18(日) 14:46:39

いるよね屁理屈だけで何も生み出さない奴。

575 ：デフォルトの名無しさん：2010/04/18(日) 14:47:09

>>574
自己紹介乙

576 ：デフォルトの名無しさん：2010/04/18(日) 14:47:34

>>574
人類の９５％以上はそのタイプ。

577 ：デフォルトの名無しさん：2010/04/18(日) 14:48:42

>>575
悔しがりすぎｗ

578 ：デフォルトの名無しさん：2010/04/18(日) 14:49:28

>>577
お前が生み出した物を紹介して欲しいんだけどｗ

579 ：デフォルトの名無しさん：2010/04/18(日) 14:51:33

>>578
悔しがりすぎｗ

580 ：デフォルトの名無しさん：2010/04/18(日) 14:52:53

いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。

581 ：デフォルトの名無しさん：2010/04/18(日) 14:53:09

思考実験（笑）

582 ：デフォルトの名無しさん：2010/04/18(日) 15:10:07

思考実験ｗｗｗ事実と反する仮定をもとに思考実験とかｗｗｗｗ

583 ：デフォルトの名無しさん：2010/04/18(日) 15:23:49

>>580
悔しがりすぎｗ

584 ：デフォルトの名無しさん：2010/04/18(日) 15:25:45

いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。

585 ：デフォルトの名無しさん：2010/04/18(日) 15:25:59

>>582
君は剛体という存在を仮定することすら愚かというんだろうな。
教養のなさが染み出てるｗ

586 ：デフォルトの名無しさん：2010/04/18(日) 15:27:31

いるよね「いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。

587 ：デフォルトの名無しさん：2010/04/18(日) 15:30:36

while(1){
puts("悔しがりすぎ");
puts("何も生み出さない奴");
}

588 ：デフォルトの名無しさん：2010/04/18(日) 15:34:18

いるよね「いるよね「いるよね「悔しがりすぎｗ」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。」とレスするだけで何も生み出さない奴。

589 ：デフォルトの名無しさん：2010/04/18(日) 15:35:02

結局>>574が自分を棚に上げただけって話だったな。つまんね

590 ：デフォルトの名無しさん：2010/04/18(日) 15:38:34

同属嫌悪って奴だろ
素直にネタも楽しめないつまんない奴なんだからそっとしておいてやれ

591 ：デフォルトの名無しさん：2010/04/18(日) 15:41:00

他人を罵倒することでしか自己確認できない人が多いのが2ch

592 ：デフォルトの名無しさん：2010/04/18(日) 15:42:21

メタなレスでスレを消費してもね

593 ：デフォルトの名無しさん：2010/04/18(日) 15:43:28

抽象化したがるのがプログラマの性ですよ

594 ：デフォルトの名無しさん：2010/04/18(日) 16:03:36

もう無責任にスレ立てを行った>>1が出てきて皆に謝罪しろよ
そうしてスレを落とせば、もう無駄な言い争いはしなくて済む

595 ：デフォルトの名無しさん：2010/04/18(日) 16:05:52

有用なレスすれば言いだけ

596 ：デフォルトの名無しさん：2010/04/18(日) 17:04:12

ネタすら投下できない無能は黙って去るべし

597 ：デフォルトの名無しさん：2010/04/18(日) 17:17:25

>>596
お願いします

598 ：デフォルトの名無しさん：2010/04/18(日) 17:35:46

しぃ言語って昔あったよな。

599 ：デフォルトの名無しさん：2010/04/18(日) 17:48:28

ところで基本的質問で悪いんだが
Cってなに？
AとかBてのがあったの？

600 ：デフォルトの名無しさん：2010/04/18(日) 17:55:46

ウィキペディアの「C言語」ぐらい読め

601 ：デフォルトの名無しさん：2010/04/18(日) 18:13:55

>>599
BCPL->B->C

602 ：デフォルトの名無しさん：2010/04/18(日) 18:33:45

STL相当のライブラリーは欲しいな。

603 ：デフォルトの名無しさん：2010/04/18(日) 18:47:34

既にあるものが欲しいって、じゃあそれを使ってろよｗ

604 ：デフォルトの名無しさん：2010/04/18(日) 18:50:09

1から作るのが難しかったら、
C ＋ STL ＋最新のオサレ機能
をベースにして、
新言語の言語仕様と標準ライブラリに整理し直したらいいかも。

605 ：デフォルトの名無しさん：2010/04/18(日) 18:57:19

雑談スレだしw
でもここ見てると冷やかしと
低レベルが知らないヤツが多いのはわかるな
俺は低レベルはCで上はgc有りで
住み分けでいいと思うがね
消えるとするとやはりc++

606 ：デフォルトの名無しさん：2010/04/18(日) 18:58:40

perfect forwardingって、名前がオサレだな。

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

C++の言語仕様が糞だから必要なのか、それ自体が他の言語でも有用な機能なのか。

607 ：デフォルトの名無しさん：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の説明少し読んだけど、悪夢？
とか思うほどに、なんか記号に満たされた感じだった。
ありゃもう駄目だと思う。読んでると、あぁこれは便利そうだとは
確かに思うのだけれども、もうね、記号がぐちゃぐちゃで文字化けかよ
って感じるほど酷いことになってる感じ。

608 ：デフォルトの名無しさん：2010/04/18(日) 19:47:22

floatの廃止とか正気か？
グラフィック関連でどれだけ使われまくってると思ってんだ

609 ：デフォルトの名無しさん：2010/04/18(日) 19:47:39

1-5までは別に言語とかコンパイラとか関係なく対応出来る
というかもうしてるのもあるよな。

610 ：デフォルトの名無しさん：2010/04/18(日) 19:48:11

>>607
やはりDでいいな

611 ：デフォルトの名無しさん：2010/04/18(日) 19:48:53

stringがライブラリである意味がわかってない奴が語るなよ

612 ：デフォルトの名無しさん：2010/04/18(日) 19:55:15

後置構文は賛成
:でいいと俺も思う

>>457 >>473
あたりの話はもう終わりなのか

613 ：デフォルトの名無しさん：2010/04/18(日) 19:55:44

>>607
C++0xは、個々の機能をみると、今までより簡単になったり分かりやすくなったりしたと思えるけど、
全体としてみれば、「ただでさえ複雑な言語がますますややこしくなった」という風に見える。

ところでfloat廃止はいただけないなあ。
今時みんなIEEE 754なんだから、単精度・倍精度に対応する型は必要。
もちろん、float/doubleという名前はぜったいだめだけど。

614 ：デフォルトの名無しさん：2010/04/18(日) 19:56:46

> もちろん、float/doubleという名前はぜったいだめだけど。
なんで？
ダサくていまどきモテないから？

615 ：デフォルトの名無しさん：2010/04/18(日) 19:58:21

>>608
単精度はサウンド関係でも使われまくってるよね

616 ：デフォルトの名無しさん：2010/04/18(日) 20:11:37

float廃止って、素人だろ
遅いとか思ってるんだろうな

617 ：デフォルトの名無しさん：2010/04/18(日) 20:18:25

>>614
その名前でfloat:主 double:従のような印象を受ける。
くだらないと思ったらすまない。

代替としては、例えばdouble→real、float→short realなど。
607のintXXに従うならfloat32/float64もありかな。

618 ：デフォルトの名無しさん：2010/04/18(日) 20:22:30

>>617
それを言いたかったんだけど、そうだよね、
ダブル残すのはセンス無さ過ぎた（ｗｗｗｗｗ

なんのダブルなんだよって事だよな

619 ：デフォルトの名無しさん：2010/04/18(日) 20:44:40

その命名理由はもっともだが、そんなもんどうでもいいだろうとw

620 ：デフォルトの名無しさん：2010/04/18(日) 20:50:58

>>607
stringはライブラリちうか動的メモリ管理必須だってばさ
gc無しの前提だからな
でなきゃおまいの書いたのは
go始め実現してる言語は多いぞ

621 ：デフォルトの名無しさん：2010/04/18(日) 20:53:11

>>620
これわかってないの多いよね

622 ：デフォルトの名無しさん：2010/04/18(日) 20:55:51

D言語に対するツンデレスレなんだよな

623 ：デフォルトの名無しさん：2010/04/18(日) 20:56:51

>>617
fixedなんてのもあるぞ_Fixedだっけ
整数は長さ指定なのにrealはないだろ
実際にfloat-ing pointなんだし。
realならimaginaryと対じゃね
long floatとかdouble floatなんてのはありだが

624 ：デフォルトの名無しさん：2010/04/18(日) 21:00:31

complexは必要だがimaginaryはいらん
掛け算するとrealになってしまう

625 ：デフォルトの名無しさん：2010/04/18(日) 21:02:43

floatは一切なしという仕様もありえる。

626 ：デフォルトの名無しさん：2010/04/18(日) 21:06:02

float32 と fixed32, fixed16 あたりは必要だろう
float32 は GPUとかSSE SIMDで使われているし fixed はfloating 演算できない組み込みプロセッサ用に重要だ

627 ：デフォルトの名無しさん：2010/04/18(日) 21:08:14

C#のDecimalってfixed128みたいな感じだっけか

628 ：デフォルトの名無しさん：2010/04/18(日) 21:15:33

>>624
そんな機能があること知らん奴のほうが多いだろ
多分日本語にしてもわんない奴多そう

629 ：デフォルトの名無しさん：2010/04/18(日) 21:19:31

可変長でなければ文字列型に動的メモリ管理なぞいらんよ
つーか文字型を廃止して、全ての文字は「0文字以上の文字列型」とする
で、文字列型はネイティブで扱える文字コードをasciiとunicodeにするだけでいい
あとはCのchar配列のような扱いで十分

630 ：デフォルトの名無しさん：2010/04/18(日) 21:19:46

complexいるかあ？
業務で複素数の演算が必要になったことなんてほとんどないぞ。
言語仕様でサポートするほどの需要があるとはとても思えない。

631 ：デフォルトの名無しさん：2010/04/18(日) 21:20:22

>>628
中学数学のはずだが？

632 ：デフォルトの名無しさん：2010/04/18(日) 21:21:31

>>630
例えば4次方程式を解くとかだな
科学技術系計算が必要だと便利だぞ

633 ：デフォルトの名無しさん：2010/04/18(日) 21:21:40

アルゴリズムとして実装可能などうでもいい機能は放っておけ

634 ：デフォルトの名無しさん：2010/04/18(日) 21:24:27

>>632
４次方程式なんて解く案件いくつあんだよ

635 ：デフォルトの名無しさん：2010/04/18(日) 21:27:46

>>632
Fortran99とかMatlabとかでなく
Cで科学技術計算やりたいケースって結構あるの？

636 ：デフォルトの名無しさん：2010/04/18(日) 21:27:49

Cで科学技術計算はかなりされているし、メモリ管理も関係ない。実装も簡単。
complex型はありだ。ただし、ライブラリはCと互換性なくなる。

637 ：デフォルトの名無しさん：2010/04/18(日) 21:29:25

また一人が必死に繰り返してるパターンか

638 ：デフォルトの名無しさん：2010/04/18(日) 21:30:09

確かにcomplexはいらないと思う imaginaryが欲しいというのにネタレスしただけです

639 ：デフォルトの名無しさん：2010/04/18(日) 21:32:19

>>634
俺はプログラマじゃないからな
この手の計算は年がら年中あるよ

640 ：デフォルトの名無しさん：2010/04/18(日) 21:35:13

maximaとかmathematica使わんの？

641 ：デフォルトの名無しさん：2010/04/18(日) 21:35:32

自分の知っている範囲を世界の全てと思い込むのは愚かなことだ

642 ：デフォルトの名無しさん：2010/04/18(日) 21:41:39

>>640
遅いから駄目
大量データモンテカルロを高速にやるとかの用途に不向き

643 ：デフォルトの名無しさん：2010/04/18(日) 21:44:22

C99にはcomplexもimaginaryもあるよ

644 ：デフォルトの名無しさん：2010/04/18(日) 21:45:40

C99に代わる言語ってSFでもむずかしいよ

645 ：デフォルトの名無しさん：2010/04/18(日) 21:47:50

complex型いらないけど、文字列型は必要なんていっているのは、まったくわかっていない。

646 ：デフォルトの名無しさん：2010/04/18(日) 21:48:31

C99は普及率がイマイチ、やっぱ普及率って大切だな
新言語ってどんだけ優れてれば良いんだろう。文字列型は便利

647 ：デフォルトの名無しさん：2010/04/18(日) 21:51:09

C/C++で実数のデフォルトはdoubleってことを分かってないのが多いな。

648 ：デフォルトの名無しさん：2010/04/18(日) 21:53:02

>>647
分かってるとなんかいいことあるのか？
いいこと書いてみな

649 ：デフォルトの名無しさん：2010/04/18(日) 21:53:51

>>647
デフォルトの意味がよくわからないが、doubleに変換して計算という仕様は変わった。

650 ：デフォルトの名無しさん：2010/04/18(日) 21:56:14

charのデフォはunsignedにすべき
そもそもcharって名前が悪いからuint8_tでもbyteでもいいけど

651 ：デフォルトの名無しさん：2010/04/18(日) 21:59:06

>>650
昔はその処理系も多かった。signedは、その名残。
Javaは、byteもsigned。

652 ：デフォルトの名無しさん：2010/04/18(日) 22:00:50

虚数が中学か。すげえ天才じゃね

653 ：デフォルトの名無しさん：2010/04/18(日) 22:05:04

>>651
ctypesのマクロに渡すときとか
符号拡張避けたい時にいちいちunsigned charにキャストしないといけなくて
ムカムカするんだよね

signed charでいいと思えることなんて一つも無い
全くASCIIのことしか考えてない馬鹿共は

654 ：デフォルトの名無しさん：2010/04/18(日) 22:10:18

>>473

auto,externはいらないに賛成。
static関数はprivateにしたい。
メンバアクセスは.だけいけるところまで行けばよいと。
->は別機能用に使うとよいかと。

655 ：デフォルトの名無しさん：2010/04/18(日) 22:12:41

整数とかfixedでもサチるやつと
回っちまうやつがあってもいいな

656 ：デフォルトの名無しさん：2010/04/18(日) 22:13:54

octet型も欲しい所だ

657 ：デフォルトの名無しさん：2010/04/18(日) 22:20:46

ビット演算周りの演算子優先順位は見直して欲しい

658 ：デフォルトの名無しさん：2010/04/18(日) 22:23:51

>>657
それは初期から指摘されているが、この間違った優先順位を変えるのはもう遅い。
やるなら記号も変える。

659 ：デフォルトの名無しさん：2010/04/18(日) 22:26:12

bit string (短い範囲で)と連結演算子ぐらいは欲しい

660 ：デフォルトの名無しさん：2010/04/18(日) 22:30:02

なんかワーニングオプションの要望ばっかだな

661 ：デフォルトの名無しさん：2010/04/18(日) 22:41:45

言語の規定に warning はウォーニングと読むと明記して欲しい。

662 ：デフォルトの名無しさん：2010/04/18(日) 22:43:44

/awrg?n/

663 ：デフォルトの名無しさん：2010/04/18(日) 22:48:05

今の段階で型云々言うなよ。演算子も早過ぎるだろ。

そもそも型システムと型関係の機能はどうすんだよ。
関数・演算子呼び出し一つとっても、型による多態／パターンマッチング／動的・静的とか
考えることたくさんあるのに。

664 ：デフォルトの名無しさん：2010/04/18(日) 22:55:52

http://www23.atwiki.jp/newclang/

wikiなくなったので立ててみました。
まとめようと思っているのだけど、どうしたらまとまるんでしょうね？
構造をどうしたらいいのか悩む。
前スレとかのデータあったら教えて欲しいです。

665 ：デフォルトの名無しさん：2010/04/18(日) 22:56:52

>>661
あっそれ欲しいｗ
ワーニングとかバカかよと思う。

666 ：デフォルトの名無しさん：2010/04/18(日) 22:58:50

くだらね

667 ：デフォルトの名無しさん：2010/04/19(月) 01:13:42

ウォーニン

668 ：デフォルトの名無しさん：2010/04/19(月) 01:24:49

全部英語表記にしろ

669 ：デフォルトの名無しさん：2010/04/19(月) 01:47:34

ウォーニングの検索結果約 122,000 件中 1 - 10 件目 (0.12 秒)
ワーニングの検索結果約 147,000 件中 1 - 10 件目 (0.20 秒)

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

ぶっちゃけどっちでもよくね

670 ：デフォルトの名無しさん：2010/04/19(月) 02:13:50

アルトラマン

671 ：デフォルトの名無しさん：2010/04/19(月) 02:57:51

スクールワーズ

672 ：デフォルトの名無しさん：2010/04/19(月) 08:18:43

SFで普及してしまった「ワープ」が諸悪の根源。
あれが「ウォープ」でありさえすれば...

673 ：デフォルトの名無しさん：2010/04/19(月) 08:27:11

>>669
野村克也「人間の最大の罪は鈍感であることだ」

674 ：デフォルトの名無しさん：2010/04/19(月) 08:43:39

言語的に無理

675 ：デフォルトの名無しさん：2010/04/19(月) 08:44:51

>>664
これ見たけど型の種類多すぎじゃね？

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

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

あとbooleanがないな。

676 ：デフォルトの名無しさん：2010/04/19(月) 10:14:18

>>673
アップル→アポー
ゼロ→ズィーロウ
エッチ→エイチ
ガラス→グラス
ヒレ肉→フィレ肉
とかそんな感じで以後よろしく

ウォーニングを正しい発音だと思ってる俺カコイイとか
どこの中二病だよ

677 ：デフォルトの名無しさん：2010/04/19(月) 10:17:33

>>685
octetという要望が出てくるのは、歴史的には
8bit=1byte=charな計算機ばかりじゃなかったからじゃないのかな
多分

というか、Wikiにまとめられてるのを見ると
カオスっぷりというかネタっぷりというか
ただの雑談をまとめるとこうなる、というレベルの低さが際立つなーと
俺は改めて思った

678 ：デフォルトの名無しさん：2010/04/19(月) 10:47:46

>>676
あんた、さすが! カコイイね!!

679 ：デフォルトの名無しさん：2010/04/19(月) 10:49:58

>>676
ワーニングを気持ち悪いと思わないほどの鈍感な奴には何を言ってもムダだな

680 ：デフォルトの名無しさん：2010/04/19(月) 10:50:24

>>679
お前は今後ウォープでアルトラマンな

681 ：デフォルトの名無しさん：2010/04/19(月) 10:52:14

あと、「グ」を気持ち悪く思わない時点でもう土着日本人だから

682 ：デフォルトの名無しさん：2010/04/19(月) 10:55:07

言語の話しろよw
ウォーニング単体の話に他の話を混ぜてどうにかしたい人がいるということぐらいしかわからん。

683 ：デフォルトの名無しさん：2010/04/19(月) 10:55:44

なんでそんな必死にワーニングを擁護するんだろう

684 ：デフォルトの名無しさん：2010/04/19(月) 10:57:17

その人のアイデンティティーか何かなんだろう。
三つ子のワーニング、百まで。

685 ：デフォルトの名無しさん：2010/04/19(月) 11:04:13

>>683
べっべつに必死でワーニングの擁護なんてしてないんだからね！

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

つーかこの手の議論はfjのvoidでさんざん見飽きたわ

686 ：デフォルトの名無しさん：2010/04/19(月) 11:07:24

>>685
だからそういう、みんなが言ってるんだからいいじゃん、ていう考え方を鈍感って言ってんだろうが

687 ：デフォルトの名無しさん：2010/04/19(月) 11:08:41

>>686
いやだから、お前は自分の信念に基づいてウォープとかアルトラマンとか
言ってれば？
俺は止めないから

688 ：デフォルトの名無しさん：2010/04/19(月) 11:12:21

なんでワーニングの話なのに別の単語を必死で持ち出すんだろう

689 ：デフォルトの名無しさん：2010/04/19(月) 11:13:16

>>688
馬鹿にも分かるように言うと
war
warp
warning
全部warの部分の発音が一緒だから

ワープは良くてワーニングがダメなおまえさんの理由を言ってみな？

690 ：デフォルトの名無しさん：2010/04/19(月) 11:14:59

話を摩り替えてることに自分で気づいてないらしい

691 ：デフォルトの名無しさん：2010/04/19(月) 11:15:17

Honesty is such a lonely word
アーネスティ　サッチャ　ロウンリ　ワード

692 ：デフォルトの名無しさん：2010/04/19(月) 11:16:00

そのうち全ての英単語はカタカナで表記できないと言い出す方に１０００カノッサ

693 ：デフォルトの名無しさん：2010/04/19(月) 11:17:32

誰か
> ワープは良くてワーニングがダメなおまえさんの理由を言ってみな？

これに答えられないの？

694 ：デフォルトの名無しさん：2010/04/19(月) 11:19:30

誰ひとりそんなことを言ってない件

695 ：デフォルトの名無しさん：2010/04/19(月) 11:20:11

んじゃあ、なんで「ワーニング」をキモいと思うべきで
そう思わないのは鈍感で

「ワープ」との違いは何なの？

696 ：デフォルトの名無しさん：2010/04/19(月) 11:22:00

どんどん違う単語を出せば永遠に逃げられますよね

697 ：デフォルトの名無しさん：2010/04/19(月) 11:23:41

要するに、合理的な理由を一人も説明できないけど
中二病だからケチだけはつけたいってことでおｋ？

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

だから「ワープ」の例を上げてるんだけど
そんなことも分からないほど馬鹿なの？

698 ：デフォルトの名無しさん：2010/04/19(月) 11:44:39

ワーニング娘。はワーワーワーワー

699 ：デフォルトの名無しさん：2010/04/19(月) 12:51:55

定着度合いが圧倒的に違う例を出してバカが必死、としか見えない。

700 ：デフォルトの名無しさん：2010/04/19(月) 12:54:25

charをチャーと呼ぶかキャラと呼ぶかみたいなもんだろ

701 ：デフォルトの名無しさん：2010/04/19(月) 12:56:16

チャラ

702 ：デフォルトの名無しさん：2010/04/19(月) 13:08:17

>>700
英語人はキャーorカーな

703 ：デフォルトの名無しさん：2010/04/19(月) 13:10:07

あとチャーもあるな

704 ：デフォルトの名無しさん：2010/04/19(月) 13:23:48

>>702
カーだとLispのcarと紛らわしいな

705 ：デフォルトの名無しさん：2010/04/19(月) 13:36:56

>>697
アルトラマンは無かったことになったんですかｗ

706 ：デフォルトの名無しさん：2010/04/19(月) 13:43:31

>>669
「定着」って数の論理は認めるんだろ
なら今更ダダこねてももう無駄だから諦めろ
ずっと前から「ワーニング」は使われてしまっていて、グーグルでも
「ワーニング」のほうが多い
幸い「ウォーニング」も多いから、「ウォーニング」を使いたい奴は
こっちを使えるが
日本語としては本来「警告」で済む話だ

707 ：デフォルトの名無しさん：2010/04/19(月) 13:49:46

なんでそんな必死なの

708 ：デフォルトの名無しさん：2010/04/19(月) 13:50:27

俺がド厨房な上に、虫の居所が悪いからさ

709 ：デフォルトの名無しさん：2010/04/19(月) 14:06:20

おまいらアホやな
発音記号で出力したら無問題

710 ：デフォルトの名無しさん：2010/04/19(月) 14:07:52

ウァーニングでいいじゃん

711 ：デフォルトの名無しさん：2010/04/19(月) 14:17:48

ウボァー

712 ：デフォルトの名無しさん：2010/04/19(月) 14:33:24

>>709
Unicode使うにしても
タイプすんのめんどい

713 ：デフォルトの名無しさん：2010/04/19(月) 14:44:26

>>712
ネタにマジで返すところがおまえの限界

714 ：デフォルトの名無しさん：2010/04/19(月) 14:45:56

デフォの文字列リテラルをUCにするオプションは欲しいな。

715 ：デフォルトの名無しさん：2010/04/19(月) 15:33:32

wɔːɼniň
ŋ

716 ：デフォルトの名無しさん：2010/04/19(月) 15:34:17

wɔːɼniŋ

717 ：デフォルトの名無しさん：2010/04/19(月) 17:16:51

octetに加えるならbigendianとlittleendian装飾もほしいな
普通に
bigendian uint16_t netdata;
uint16_t data;
if (data > netdata) ...
ローレベル言語チックじゃねえか

718 ：デフォルトの名無しさん：2010/04/19(月) 17:18:00

ロベール？

719 ：デフォルトの名無しさん：2010/04/19(月) 17:19:22

関数を装飾化する定義構文があれば全部解決するんだろうか？

720 ：デフォルトの名無しさん：2010/04/19(月) 17:20:11

口ｩレヴル

721 ：デフォルトの名無しさん：2010/04/19(月) 17:26:30

>>717
ちょっと面白いけど
byteswap系の関数やhtonl()の類を標準ライブラリで提供してくれれば
十分な気がする

722 ：デフォルトの名無しさん：2010/04/19(月) 17:31:25

>>721
半分はネタのつもりだが
hton系は型セーフじゃないし、両方同じの使っちゃう奴もいたりするし
I/OなんかでもBig系Little系があったりするし面白いかなと

723 ：デフォルトの名無しさん：2010/04/19(月) 19:17:03

ロゥレヴォゥ

724 ：デフォルトの名無しさん：2010/04/19(月) 20:40:04

一気に糞スレになったな

725 ：デフォルトの名無しさん：2010/04/19(月) 20:42:43

一瞬でも糞スレじゃなかった瞬間があったかよ

726 ：デフォルトの名無しさん：2010/04/19(月) 21:31:13

俺思うんだけど、ＣＰＵの実装の違いを隠蔽するような、
低水準高級言語というアプローチが、Ｃの最大の欠点だと
思うんだよね。も乳論、誤変換だけど面白いからそのままで、
もとい、もちろん、当時の技術水準とかコンパイラの大きさ
という問題が有ったのは確かなんだけどさ。

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

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

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

ＳＩＭＤとか、各社各様に出てるのを上手いこと使いやすくするって言う
アプローチで言語設計した方が良いと思う。

727 ：デフォルトの名無しさん：2010/04/19(月) 21:37:10

アセンブラ使ってろよ
86が一番多いと思ってんの？

728 ：デフォルトの名無しさん：2010/04/19(月) 21:41:53

インテルはfpuやめてsse2に移りつつあるよ

729 ：デフォルトの名無しさん：2010/04/19(月) 21:42:59

面白いと思ってんの？

730 ：デフォルトの名無しさん：2010/04/19(月) 21:47:43

だいたい当時の技術水準とかあまく見過ぎ

731 ：デフォルトの名無しさん：2010/04/19(月) 21:49:56

Aという機械に合わせてバイナリを吐くのはA用コンパイラの仕事だと何度言えば

732 ：デフォルトの名無しさん：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);これはＯＫだけど警告が出る

っていうことが出来る言語設計があれば良いと思うんだよね。

733 ：デフォルトの名無しさん：2010/04/19(月) 21:54:39

>>731
だからそう言うアプローチで言語を最大公約数的に言語を設計するのは
もうね、限界だし、他の人がやってるし。
面白くないじゃん。せっかく色んなＣＰＵが有るんだし。

>>727
だから、アセンブラ使っちゃえで終わるかどうかってところなんだよね。
やっぱりプログラミング規模が大きくなると見通し悪いしさ。
低水準高級言語というアプローチは大切にしたいじゃない。
このアプローチが大正解だったので、未だにＣ言語は廃れないし。

734 ：デフォルトの名無しさん：2010/04/19(月) 21:56:28

いやいや最新の技術を使って
xmlで定義だろ

735 ：デフォルトの名無しさん：2010/04/19(月) 21:58:11

で、言語というアプローチも大切なんだけど、コンパイラーという
部分の役割も大きくなって来るというか、コンパイラーを意識した
（コンパイル出来るとかだけなじゃなくてもっと具体的に意識した）
言語設計というアプローチになると思うんだよね。

ンで、具体的に言うとllvmがこれを意識してる訳じゃないけれども、
この辺の課題を解決するために、この辺の課題を意識した設計になってる
でしょ、だからこういうアプローチを言語設計に持ってくる言語設計も
可能な時代なんじゃないのかなって思うのですよ。

736 ：デフォルトの名無しさん：2010/04/19(月) 22:03:02

>>733
最後の一行だけで話終わったな
論理が支離滅裂だし知識も無茶苦茶だし
ネタならもうチョイ練ってくれ

737 ：デフォルトの名無しさん：2010/04/19(月) 22:05:40

馬鹿すぎ。コンパイラを意識していないコンパイル型言語なんて無い。
一件不合理に思える言語仕様も、コンパイルの速度や最適化の効率などを考えて作られてる。
きちんと最適化までする実用に耐えるコンパイラを作ったことがなきゃ、言語なんてできっこない。

結果として言語仕様は実装に縛られないものができたとしても、
実装を意識せずに作られた言語は無い。

738 ：デフォルトの名無しさん：2010/04/19(月) 22:08:49

>>737
文盲がそう言うレスを付けるだろうなって思ってた。
いつもの文盲さんこんにちは。なんで２ｃｈには
どのスレ行っても、君のような文盲がいてるんだろ？

739 ：デフォルトの名無しさん：2010/04/19(月) 22:11:08

>>734
結果ＸＭＬという話は出てくると思うけど、
まぁそう言うことなんだよね。最小公倍数というか
公倍数的なアプローチを行うよ、という言語設計。
でも、いきなりにＸＭＬとか言い出すと、ＸＭＬみたいに
なんか定義定義ばかりで話が進まないとは思う。

740 ：デフォルトの名無しさん：2010/04/19(月) 22:12:24

2chでは思考や思想が並列化されてるからな
スタンドアローンコンプレックス現象ってやつだわさ
>>738みたいなレスも何度か見たことあるし、あるいは俺も書きこんだことがあるかも

741 ：デフォルトの名無しさん：2010/04/19(月) 22:17:29

昔設計された言語は、コンパイラのことあまり考えられていないね。
COBOLとかPL/I

742 ：デフォルトの名無しさん：2010/04/19(月) 22:19:57

>>739
公倍数て…あんたそりゃ高級言語の思想だよ
基準を最上位に持っていこうとするのが公倍数、つまり高級言語
基準を最低位に持っていこうとするのが公約数、つまり低級言語

根本から目指してるものがずれてる

743 ：デフォルトの名無しさん：2010/04/19(月) 22:22:16

>>737
Cは最適化からかけ離れた言語だけどね。

744 ：デフォルトの名無しさん：2010/04/19(月) 22:24:35

>>739
皮肉なんだが。。。

745 ：デフォルトの名無しさん：2010/04/19(月) 22:26:22

>>743
ポインタは鬼門だあな
でも手動で最適化するなら最高だが

746 ：デフォルトの名無しさん：2010/04/19(月) 22:27:26

明示されない限りポインタはデフォルトでrestrictにしてほしいな

747 ：デフォルトの名無しさん：2010/04/19(月) 22:27:42

そういや99にはrestrictがあるな

748 ：デフォルトの名無しさん：2010/04/19(月) 22:28:26

>>743
代わりに、コンパイラが最適化しなくても人力で最適化出来るようになっているね。
おかげで、手っ取り早くコンパイラの実装が出来る。

749 ：デフォルトの名無しさん：2010/04/19(月) 22:29:28

>>746
難しいだろな
restrict自体危ないと思うんだよな

750 ：デフォルトの名無しさん：2010/04/19(月) 22:38:33

いわば最適化が目的の小細工に過ぎないからな

751 ：デフォルトの名無しさん：2010/04/19(月) 22:41:31

>>744
皮肉で俺の言ってる真意を理解していないことは知ってるけど、
でも、まぁ、文盲よりは理解してると思ったので。

つまりそう言うことなんだよね、ＸＭＬで抽象化するアプローチと
原理的、思想的に、似てる部分は有るんだよ。
そう言うことを言ってるので、君は皮肉として書いたとしても、
皮肉にならないんだよね、そこまで理解した上で書かないと皮肉に
ならないと言うこと。知性の圧倒的な量の違いで君のちっぽけな
脳みそと感情から皮肉だとしても、そして俺はそれを理解したけども、
君がどうなろうと俺の人生にはまったく関わらないので、>>739を
書いた。とこれだけかみ砕いても君には理解できない世界の話。

752 ：デフォルトの名無しさん：2010/04/19(月) 22:52:56

じゃあ知性が足らないから訊くが
あんたのイメージに今一番近い言語はなんた？
バックエンドの仕事を設計に持ち込んだ言語なんて不要だし
llvmってなにかしってる？

わり。ネタにならないネタに反応しちまったよ

753 ：デフォルトの名無しさん：2010/04/19(月) 22:54:06

>>751をもう放っておいてやれよ！
可哀相だろ！先生に言いつけるよ！！

754 ：デフォルトの名無しさん：2010/04/19(月) 23:07:36

>>752
今、イメージに一番近いのは、llvmの中間表現。
これをもう少し人間が使いやすい形に出来ないのかな？
という発想と、それをするとソースのポータビリティが
無くなってしまうけども、それはそれで良いのではないか、
そもそもソースにポータビリティなど求めるのは違うのではないか？
と言う疑問点から落としどころ模索するべき、じゃないかという話。

755 ：デフォルトの名無しさん：2010/04/19(月) 23:08:21

組み込みやってたらいつも思うんだけどさ、2進数の数も扱えるようにして欲しいんだよね。
あとビット演算ももっと強化できるはず。

756 ：デフォルトの名無しさん：2010/04/19(月) 23:13:40

1bitの型があればいいんだけどな。
最適化でいくつかのbit型をまとめてbyteで処理したりできそう。

757 ：デフォルトの名無しさん：2010/04/19(月) 23:23:04

>>756
遅くなる、ビットフィールドがある、バイナリ互換性で問題が出る。

758 ：デフォルトの名無しさん：2010/04/19(月) 23:26:10

>>753
わかったよw

>>756
つvhdlw

bitはビットフィールドでいいが
数値の2進表記はほしいね
0b01010101みたいな

759 ：デフォルトの名無しさん：2010/04/19(月) 23:27:34

>>755
<<,>>で回るヤツ位は欲しいよね

760 ：デフォルトの名無しさん：2010/04/19(月) 23:34:12

ライブラリの話になっちゃうけど
stdioでfunopen()/fmemopen()の類は標準にしてほしい
そのうえで、stdioをbitstreamとしても使えるといい
getbits()
putbits()
みたいな感じで

761 ：デフォルトの名無しさん：2010/04/19(月) 23:37:28

>>757
型安全であればコンパイラがビットをどのように扱おうと気にする必要はないのでは。
気になる人は最初からバイトで扱えばいいだけだし。

762 ：デフォルトの名無しさん：2010/04/19(月) 23:38:06

>>755
仕様書見てそのままビットパターンを書き込めたら楽だよねえ。

763 ：デフォルトの名無しさん：2010/04/19(月) 23:39:06

>>758
そういう表記方法を定義する一般的な方法を定義するにはどうすればいいだろう？

764 ：デフォルトの名無しさん：2010/04/19(月) 23:41:03

>>762
pragmaで制御できるコンパイラもあるんじゃないか

765 ：デフォルトの名無しさん：2010/04/19(月) 23:42:09

>>748
手動最適化は今や最適化の邪魔にしかならないけどな。

766 ：デフォルトの名無しさん：2010/04/19(月) 23:42:27

C言語に足りないのは型安全性なんだよな。
型理論でカチカチに作り直したい。

767 ：デフォルトの名無しさん：2010/04/19(月) 23:45:02

>>763
決めちまえばしまい
会議のルールを決める会議はいらない
再帰するだけ

768 ：デフォルトの名無しさん：2010/04/19(月) 23:45:15

>>765
そこが、Cらしいところじゃない。

769 ：デフォルトの名無しさん：2010/04/19(月) 23:46:16

>>766
具体的に、どういうものが安全ではないのですか？

770 ：デフォルトの名無しさん：2010/04/19(月) 23:47:33

>>767
それだったら言語が普及してからこんな記法があったら良かったのにね、
ってことになって不満要素になるだろ。
それだったら、後で仕様変更が簡単になるようにメタ記法を考えた方が後の人のためになるでしょ。

771 ：デフォルトの名無しさん：2010/04/19(月) 23:48:23

>>765
手動でオプティマイザを導いてやるなんて普通だろ
試して遅いなら戻すだけ
ダメダメなコードは頑張ってもやっぱしダメダメだし

772 ：デフォルトの名無しさん：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だから使えねえええ。

773 ：デフォルトの名無しさん：2010/04/19(月) 23:51:18

>>770
んで書く人毎に違う何かが出来るわけだ
言語設計で決めちまえばしまいじゃん

774 ：デフォルトの名無しさん：2010/04/19(月) 23:52:41

>>772
おう。知らんかった！
このスレで始めて有益な情報がw

775 ：デフォルトの名無しさん：2010/04/19(月) 23:53:32

>>773
デフォルトを言語仕様で決め、後で違う記法も追加できる、という仕様が望ましいな。

776 ：デフォルトの名無しさん：2010/04/19(月) 23:55:15

言語仕様は決め事だからね
追加はまた後で！でいいんちゃう
メタな機能は黒魔術に陥る危険が危ないよ

777 ：デフォルトの名無しさん：2010/04/19(月) 23:57:27

マクロなlispマジック大好きなんだけどな。

778 ：デフォルトの名無しさん：2010/04/20(火) 00:03:32

魔法のコードは
書いたヤツよりレベルが低いヤツには理解不能で
上のヤツには鼻で笑われるのが落ち

779 ：デフォルトの名無しさん：2010/04/20(火) 00:20:08

新言語では少し練習すれば誰にでも最上級の魔法を使えるようにしたい

780 ：デフォルトの名無しさん：2010/04/20(火) 00:23:11

目的が違うだろそれは

781 ：デフォルトの名無しさん：2010/04/20(火) 00:37:10

>>769
例えばchar型に関していえば、
それが単なるバイトとして扱われているために、
数値も文字もゴッチャに扱われる。

782 ：デフォルトの名無しさん：2010/04/20(火) 00:37:14

魔法は目的ではなく手段だ。

783 ：デフォルトの名無しさん：2010/04/20(火) 00:37:19

mahaですね。わかります

784 ：デフォルトの名無しさん：2010/04/20(火) 00:39:50

>>778
そんなことありません。鼻で笑う人は心が病んでいるのです。

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

ちなみに、厳密に言えば関数もメタなんだよ。

785 ：デフォルトの名無しさん：2010/04/20(火) 00:40:29

reg [7:0] uint8;
reg [15:0] uint16;
reg [31:0] uint32;

786 ：デフォルトの名無しさん：2010/04/20(火) 01:05:28

メタ機能は死んでくださーい

787 ：デフォルトの名無しさん：2010/04/20(火) 01:14:38

強い静的型付けこそ正義だよな
あとLispみたいな～って議論が結構あるが、
ラムダ関数を演算子化すればおｋじゃね？

788 ：デフォルトの名無しさん：2010/04/20(火) 01:14:47

>>785
VHDL乙

789 ：デフォルトの名無しさん：2010/04/20(火) 01:18:37

>>787
無名で関数定義するだけなら害はないよな
でもクロージャとか欲しくなると
ローレベルでは難しくなる

790 ：デフォルトの名無しさん：2010/04/20(火) 01:24:35

>>788
Verilogだけどな。

791 ：デフォルトの名無しさん：2010/04/20(火) 01:37:50

スタックマシーンでクロージャーって実現できないの？

792 ：デフォルトの名無しさん：2010/04/20(火) 01:45:56

wikipediaの"クロージャ"の"実装"を見たらなんとなくわかるよ

793 ：デフォルトの名無しさん：2010/04/20(火) 01:49:23

いや、今ある一実装を知りたいわけじゃないんだけど。

794 ：デフォルトの名無しさん：2010/04/20(火) 02:04:48

>>787
強い静的型付けでないと、バグ追跡が難しくなるんだよね。
charに整数も文字も入れて使う場合でも、
整数型と文字型を分けて相互に型変換して使う場合でも、
どっちにしても結局は簡単な最適化で同じ結果になるんだから、
非効率ということはないだろうしね。

795 ：デフォルトの名無しさん：2010/04/20(火) 07:44:20

>>794
その辺りが時代錯誤ということなんだよね
文字も内部では数値だから数値扱いのほうが(機械にとって)効率的→うん確かにその通り
でも使うのが人間である以上やはり文字列型は文字のみを扱えるべきなんだよ

796 ：デフォルトの名無しさん：2010/04/20(火) 07:58:36

型宣言だけ強制と言うのも変な話だよね。
他のassertと同様任意でいいんじゃないかな。

797 ：デフォルトの名無しさん：2010/04/20(火) 08:01:16

低レベルな用途には文字列なんてオマケ
gc前提なら他言語で普通にある
メモリ管理なしな文字列型で
結合すら出来ないならいらん
てこと。

798 ：デフォルトの名無しさん：2010/04/20(火) 08:06:38

>>797
sprintf()

799 ：デフォルトの名無しさん：2010/04/20(火) 08:09:14

>>795
と、言うか、文字列とバイト列は違うもんだし、
文字列やバイト列にサインは必要ないんだよね。
これを数値と同等に扱うのは本当に無意味な言語仕様
だと思う。

>>797
ＧＣが無くても文字列は扱えるんだよ。
ＧＣが有っても1024桁の数値は扱いにくいのと同様。
色々勘違いしてるので面白いと思う。

800 ：デフォルトの名無しさん：2010/04/20(火) 08:18:00

別の言い方をすれば「数値であることが隠蔽されている」のが望ましい
そうでなくても文字コードは1byteのASCIIだけじゃないんだから数値演算で文字を扱えるのはおかしい

801 ：デフォルトの名無しさん：2010/04/20(火) 08:20:46

>>799
勘違いね
多分お互い低レベルの意味が違うんだろ
メモリ管理なしの文字列なら
今のCのchar配列以上にはならんよ
例が無意味過ぎ

802 ：デフォルトの名無しさん：2010/04/20(火) 08:23:46

>>801
可変長文字列型を頭から捨てろよｗ

803 ：デフォルトの名無しさん：2010/04/20(火) 08:30:47

>>802
固定長ならchar []と変わらんだろw
文字コードとか持ち込むとややこしくなるし

804 ：デフォルトの名無しさん：2010/04/20(火) 08:33:31

ま、文字列とバイト列が違うといいたいのはわかるが
gc無しでは型を分けるメリットが薄いでしょ

805 ：デフォルトの名無しさん：2010/04/20(火) 08:34:26

>>803
もともと型安全の話をしてるんだが？
符号ありの1byte幅の数値ハイブリッドchar型で文字列を扱うのがおかしいって話
そこが解消されればchar[]のような使い方で何の問題もない

806 ：デフォルトの名無しさん：2010/04/20(火) 08:55:33

>>804
ＣＰＵ依存型（言語仕様）
整数、実数、バイト、番地
ＣＰＵ非依存（ビルトイン）
ポインター、バイト列、配列
ＣＰＵ非依存（ライブラリ）
文字列型。

>>801
おまえ、本当にアセンブラ組んだこと有るのか？
それから、ＣとＣ++とＣＯＢＯＬとフォートランとＪＡＶＡ組んで
納品したこと有るのか？

807 ：デフォルトの名無しさん：2010/04/20(火) 09:09:36

組んでって・・・

808 ：デフォルトの名無しさん：2010/04/20(火) 11:21:43

rorだっけか。
ビット回転とか、上下4ビット交換とか
Ｃではインラインアセンブラになる命令の演算子が欲しいな。
対応できないアーキテクチャの時は
エラーを吐けば良いと思う。

809 ：デフォルトの名無しさん：2010/04/20(火) 12:07:19

>>806
ねえ、オープンソース勢より品質の低いコード書いてる人って
何でそんなに業務アプリを作ったら偉いみたいな言い方をするのかな？
俺は業務アプリは書かない系の業界人だけど、
正直言ってソース公開できる奴はコードに相当自信がある奴だと思う。
自分のソースを晒すのってケツの穴を晒すようなもんだからね。
この業界で仕事でプログラミングしてる奴の95%は糞コードしか書けないと自信をもって言える。

810 ：デフォルトの名無しさん：2010/04/20(火) 12:10:42

>>809
横から済まんがおまえの言ってることは支離滅裂だぞ

811 ：デフォルトの名無しさん：2010/04/20(火) 12:33:01

業務で作ったソースは当然公開出来る場合と出来ない場合がある
ソースが公開出来ないのはまだマシで完成品を公開出来ないこともある
もっと言えば何を作ったか話すことすら禁じられている場合もある

812 ：デフォルトの名無しさん：2010/04/20(火) 12:45:21

>>811
なにがなんでも書き込まなきゃ気が済まない人かよ。
議論がとっちらかるから、自重してよね。
ニフティじゃないんだから、そう言う話題なら腐るほど
別にスレがあるじゃない。

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

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

813 ：デフォルトの名無しさん：2010/04/20(火) 12:50:54

そういう細かい機能は、Cなどの既存言語を拡張したらすむ話問題。

814 ：デフォルトの名無しさん：2010/04/20(火) 13:03:03

>>813
>>1の主旨に沿う気が無いのなら、書き込まなきゃ良いのに。
拡張ではなく、そう言った問題を解決するために、ゼロベースで
考えようというのが>>1の主旨でしょ。

815 ：デフォルトの名無しさん：2010/04/20(火) 13:35:41

まあ>>1の主旨ってのもデタラメだけどな。
現実にCがあるのに、Cが無かったとしてなんて考える意味ないし。

816 ：デフォルトの名無しさん：2010/04/20(火) 13:37:48

>>814
ゼロベースだろうが既存の拡張だろうが、そんな細かいことは、ものができてからやればいいこと。

817 ：デフォルトの名無しさん：2010/04/20(火) 13:44:25

>>815-816
そう考える人は別のスレに行けば良いだけ。
わざわざそんなこと無駄とか言う必要ないじゃん（ｗ
お前の仕事になるわけでも無いし。
よっぽど人生が貧しいんだと思うのだけれども、
なんでまたわざわざ、自分が何一つ協力する気がない
構想に口出しするんだ？

818 ：デフォルトの名無しさん：2010/04/20(火) 13:51:58

>>817
おまえ協力してんのかよｗ
グダグダ勝手なこと書いてるだけじゃん。

819 ：デフォルトの名無しさん：2010/04/20(火) 13:53:54

まだ、ブレスト段階でしょ。
社会人やったこと無いのかよ・・・

820 ：デフォルトの名無しさん：2010/04/20(火) 13:55:48

社会人どうこういう奴は社会人にコンプレックスを持っている人間ですｗ
つまり、>>819はニートですね？ｗｗ

821 ：デフォルトの名無しさん：2010/04/20(火) 13:57:57

ブレスト？？？
こんなｇｄｇｄなやりとりがブレスト？？？
何一つ現実的な目標もないし、何一つ効果が得られそうにない話がブレスト？？？
冗談だろ。どんなぬるい環境にいるんだよ。

822 ：819：2010/04/20(火) 14:08:20

すいませんブレストって言ってみたかっただけでした

823 ：デフォルトの名無しさん：2010/04/20(火) 14:15:58

普通、自分が社会人だと認識しているなら、
他の誰が社会人なのかなんて気にならないよな。
それに、ちゃんとした技術者なら自分が技術的に学生より優れている点なんて
ほとんど無いことぐらい承知しているはずなのにね。

824 ：デフォルトの名無しさん：2010/04/20(火) 14:18:13

>>823
おまえさっきから言ってる意味ぜんぜんわかんない

825 ：デフォルトの名無しさん：2010/04/20(火) 14:18:56

>>824
経験論だよｗ

826 ：デフォルトの名無しさん：2010/04/20(火) 14:20:16

"普通の"人ってこんなふうに考えるよね
って事を言ってるだけ。
別に複雑な事や論理的な事をいってるわけじゃないよｗ

827 ：デフォルトの名無しさん：2010/04/20(火) 14:23:31

いっそのことCPU限定で言語を作ってしまったらどうだろう。
すべてのCPU毎に言語をカスタマイズするわけさ。

828 ：デフォルトの名無しさん：2010/04/20(火) 14:26:19

今日は支離滅裂なキチガイが棲みついてるわけか

829 ：デフォルトの名無しさん：2010/04/20(火) 14:28:29

非ポータブルという時点でC/C++の代替にはならないので
スレ的にはスレ違いだと思うけど

830 ：デフォルトの名無しさん：2010/04/20(火) 14:29:50

>>828
お前みたいな人工無脳に言われたくない

831 ：デフォルトの名無しさん：2010/04/20(火) 14:38:25

>>827
俺が言ってるのはそれに近いンだよ。
ENVIRONMET DIVISION．
を有効活用して、可搬性を持たせたいなと。
ただし、オリジナルのソースは絶対に他のＣＰＵじゃうごかねぇと
動かすためにどこが不味いのか、これを徹底的に報告出来るような
コンパイルシステムがあれば、ＣＰＵの発展にも良いと思うんだよね。

可搬性を意識しないでプログラムが組めるし、ＣＰＵも開発できる。
違うＣＰＵで動かしたいのなら、何とどこが不味いのか、それを
チェックして報告してくれる、そんなシステム。

832 ：デフォルトの名無しさん：2010/04/20(火) 14:43:50

827は「それってアセンブラだろ！」っていう突っ込みを期待してるボケだと思うのだが

833 ：デフォルトの名無しさん：2010/04/20(火) 14:49:19

言語がCPU特化のほうが潔いと思うね。
CPU毎に用意されたバージョンのコンパイラを使ってコンパイルし、
それぞれをリンクして、CPUを判定して利用する部分を切り替える。

>>832
アセンブラを抽象化しつつ、CPU独自の機能を使えるようにする。
高度な設計手法を使うことを意識した構造的なプログラミング言語を目指す。

834 ：デフォルトの名無しさん：2010/04/20(火) 14:51:08

>>833
政策マニュフェスト乙

835 ：デフォルトの名無しさん：2010/04/20(火) 15:04:25

仕事一服
>>806
FortranとCobolはねえなw
VBは若い頃一回だけあるがw
tcl/tkやperlやらjavaやらphpはあるな。
組み込みメインだからアセンブラなんて当然
デバドラやらRTOSとかtcp/ipやら
usbスタックも作ったし
Cコンパイラ移植もやったなw
ま、普通だよ
今は若いもんにかなりやらせてるがな

836 ：デフォルトの名無しさん：2010/04/20(火) 15:10:27

>>832
マクロアセンブラだわなw

ソースなんて90-95%も可搬ならいんだよ
コード内にCPUの情報入れるとか正気じゃないなw

837 ：デフォルトの名無しさん：2010/04/20(火) 15:16:27

ああ、いい過ぎ
今はtypedefやらdefineでヘッダで吸収してるわな
ま情報入れるなら型決めちまった方が楽だな
occamみたいな並列実行ヒントやら
サチる整数はあってもいいかな
dsp系の命令かけるな

838 ：デフォルトの名無しさん：2010/04/20(火) 15:24:50

>>833
Cをそれにコンパイルしたらどうだろう！

839 ：デフォルトの名無しさん：2010/04/20(火) 18:24:25

ソレ、単なるアーキテクチャ依存の最適化じゃねーか

840 ：デフォルトの名無しさん：2010/04/20(火) 19:18:44

>>839
それを簡単にこなす言語処理系が無いんだよ。
アセンブラ使うか、Ｃ言語コンパイラの挙動を予測しながらの
コード記述。

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

ここに述べたことを考えるに変えると、ちょっとしたレポートになるぞ（ｗ

841 ：デフォルトの名無しさん：2010/04/20(火) 19:28:47

そうだよな！
今必要なのはリスト操作とスタック重視アーキテクチャしかねえじゃん！
文字列操作もメモリ確保もCPU内蔵だぜベイベー

842 ：デフォルトの名無しさん：2010/04/20(火) 19:41:53

CPUは必要最低限の命令だけを搭載させるべきだろ。
その方法で富士通のVENUSは世界最速じゃん。

843 ：デフォルトの名無しさん：2010/04/20(火) 19:51:52

必要最小限って言っちゃうと、チューリングコンプリートであればいいのか？　って
言われちゃうぞw

844 ：デフォルトの名無しさん：2010/04/20(火) 19:52:02

RISCの失敗

845 ：デフォルトの名無しさん：2010/04/20(火) 19:56:02

RISC は何も失敗してないだろ。

Intel を駆逐するという予想が間違ってただけで。

846 ：デフォルトの名無しさん：2010/04/20(火) 19:56:56

>>844
設計思想が失敗だったんじゃなくて、もっと泥臭い商売的な意味で失敗しただけ。
Intelの猛烈な商売根性に圧倒されただけだね。

847 ：デフォルトの名無しさん：2010/04/20(火) 19:57:05

>>844
デスクトップではね。
組み込みはほぼRISCが制覇

>>842
なにいってんの！gcもいっそ内蔵しちまえば最強だぜ

848 ：デフォルトの名無しさん：2010/04/20(火) 20:00:37

現にSPARCベースのVENUSはMIPS/Wも世界最高。
でも量産効果でIntel製の方が安いから普及しないｗ
可能性としてはSPARCの方が効率的らしいけどね。
iPhoneやiPadが普及することで非IntelアーキテクチャのCPUが
使われることが当たり前になったら、RISCも復権するかもしれないね。

849 ：デフォルトの名無しさん：2010/04/20(火) 20:03:42

あのーふつーの携帯電話はRISCですが。

850 ：デフォルトの名無しさん：2010/04/20(火) 20:06:17

低級なのは言語じゃなくて書き込んでる奴らだったようだな

851 ：デフォルトの名無しさん：2010/04/20(火) 20:10:35

x86からはなれても、RISCにはならないだろう。

852 ：デフォルトの名無しさん：2010/04/20(火) 20:11:01

ここにいる奴らは全員他力本願な何もできないクズ

ソースは俺

853 ：デフォルトの名無しさん：2010/04/20(火) 20:18:41

はい

854 ：デフォルトの名無しさん：2010/04/20(火) 20:21:45

>>851
つか、86以外はほとんどRISCｗ
86も内部はRISC
TIのDSPはVLIW
ま4bitとか8bitは除くがな

855 ：デフォルトの名無しさん：2010/04/20(火) 20:34:46

うんこ

856 ：デフォルトの名無しさん：2010/04/20(火) 20:41:29

DSPとか優秀だよな
速度の割に熱くならねえ

857 ：デフォルトの名無しさん：2010/04/20(火) 22:31:18

とりあえず頭良い人がcコンパイラ作ってよ。

858 ：デフォルトの名無しさん：2010/04/20(火) 23:01:20

作ったよ＾＾
http://gcc.gnu.org/

859 ：デフォルトの名無しさん：2010/04/20(火) 23:04:05

今のIntel Core内部はRISCというよりはVLIWだろ。

860 ：デフォルトの名無しさん：2010/04/20(火) 23:08:22

新言語にはデストラクタに相当する機能が是非欲しい。

861 ：デフォルトの名無しさん：2010/04/20(火) 23:14:17

今のRISCは、単純な命令ばかりでとは言えない。

862 ：デフォルトの名無しさん：2010/04/20(火) 23:16:51

それは昔から。

863 ：デフォルトの名無しさん：2010/04/20(火) 23:19:56

>>860
ということは、クラスがあるってこと？

864 ：デフォルトの名無しさん：2010/04/20(火) 23:20:34

優れたCPUが存在しても相変わらずIntelべったりにならざるを得ないのはWindowsが原因なんだろうな。
許せないMS

865 ：デフォルトの名無しさん：2010/04/20(火) 23:20:58

RISCの命令の種類が少なかったのなんて、ほんの初期だけだからな

866 ：デフォルトの名無しさん：2010/04/20(火) 23:21:47

>>863
クラスは知らんが、オブジェクトはあるだろうな。

867 ：デフォルトの名無しさん：2010/04/20(火) 23:24:08

>>864
Intel以外のCPUは優れていないから淘汰されたんだよ＾＾

868 ：デフォルトの名無しさん：2010/04/20(火) 23:31:41

C#のイベント機能をそのまんま割り込みに使えるようにしようぜ

869 ：デフォルトの名無しさん：2010/04/20(火) 23:33:18

>>868
割り込みっていろいろ条件があるし、優先度もあるし、内部機能の数によっても決まるし・・・

870 ：デフォルトの名無しさん：2010/04/20(火) 23:40:49

そういうのを包括できるような新言語を作ろうって話だろ
割り込みなんて大抵のCPUは、許可、不許可、優先度、ハンドラ関数くらいしか
設定することないんじゃないの？

871 ：デフォルトの名無しさん：2010/04/20(火) 23:41:06

>>864,867
IBMの所為だよw

872 ：デフォルトの名無しさん：2010/04/20(火) 23:58:42

>>864
かつて、Power, Alpha, MIPS用のWindowsもあったし、Windows CEだったらx86はアプリ開発用しかない。

873 ：デフォルトの名無しさん：2010/04/21(水) 00:33:28

>>870
同意

874 ：デフォルトの名無しさん：2010/04/21(水) 01:24:50

割り込みはCPU毎に違いが大きいからなー
ハンドラくらいしか一般化出来ねえな
Signalで補足出来たら面白いがな

875 ：デフォルトの名無しさん：2010/04/21(水) 07:48:22

違い？具体的にどう違う？

876 ：デフォルトの名無しさん：2010/04/21(水) 07:59:11

>>872
ん？　Windows CE、x86で走ってるぞ。

877 ：デフォルトの名無しさん：2010/04/21(水) 09:36:00

>>875
おはよ。
一つはハード面、も一つはOSなんかのからみな

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

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

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

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

例外やらSignalで処理出来たら面白いとは思うが
いろいろ考えると出来るとしてもせいぜいレジスタ保存とかが
出来るようなハンドラ記述レベルじゃね

878 ：デフォルトの名無しさん：2010/04/21(水) 10:28:15

んなもんインラインアセンブラor外部モジュール結合でいいだろ
抽象化不可能とわかってる部分まで抽象化しようとすんな

879 ：デフォルトの名無しさん：2010/04/21(水) 13:17:17

抽象化可能だが、具体的に扱うのが低級言語だろ。

880 ：デフォルトの名無しさん：2010/04/21(水) 13:34:11

悪化は良貨を滅ぼす
x86、ARM、SPARC、PPC
RISCでもCISCでもアーキテクチャーの汚いものだけが残って
美しいものは消えていく運命にある。
今はMIPSが最後の砦だ。

881 ：デフォルトの名無しさん：2010/04/21(水) 13:35:16

iPhoneにはARMが入っているわけだが

882 ：デフォルトの名無しさん：2010/04/21(水) 13:51:11

CPUを売る能力がある企業は天才よりも組織に順応しやすい人間を選ぶからじゃないかな。
綺麗なアーキテクチャを考える天才は技術はあっても商才がないので売れないと。

883 ：デフォルトの名無しさん：2010/04/21(水) 14:32:12

obj.x;でobj.x();が、obj.x = 1;でobj.x(10);が呼ばれる、みたいなプロパティっぽいシンタックスシュガー機能搭載してください

884 ：デフォルトの名無しさん：2010/04/21(水) 18:49:48

>>878
868,870へのレスだよ
割り込みの抽象化は意外に難しいぜといいたかっただけ
ライブラリで済ませれるなら出来ない話じゃないがね

885 ：デフォルトの名無しさん：2010/04/21(水) 19:56:13

本質を抽象する言語を開発したい

886 ：デフォルトの名無しさん：2010/04/21(水) 20:02:48

>885
数学で十分だと思っている僕は負け組ですか

887 ：デフォルトの名無しさん：2010/04/21(水) 20:10:45

yes

888 ：デフォルトの名無しさん：2010/04/21(水) 20:11:17

＞＞885
あんたのしゃべってる言語じゃねえのｗ

889 ：デフォルトの名無しさん：2010/04/21(水) 20:32:06

もしも抽象データ型が発明されていなかったとして、新たに作るとしたら
本質データ型という名前にしたい

890 ：デフォルトの名無しさん：2010/04/21(水) 20:41:03

本質データ型はビット列を直接記述できます

891 ：デフォルトの名無しさん：2010/04/21(水) 22:40:37

bit列でしか記述できないほうが美しい

892 ：デフォルトの名無しさん：2010/04/21(水) 23:17:30

>>877
それを抽象化するのがプログラミング言語の仕事だろう。

割り込みの抽象化が難しいというのであれば、「変数」や「関数」や「オブジェクト」の抽象化だって難しい。
割り込みの抽象化が他の機能の抽象化に比べて特別に難しいことはない。

893 ：デフォルトの名無しさん：2010/04/22(木) 01:17:04

>>892
Cレベルの言語にとって
変数や関数の抽象化レベルはひくいぞ
一緒にしない方がいい
無知と浅薄がバレる
例外なんていわない方がいい

894 ：デフォルトの名無しさん：2010/04/22(木) 01:29:13

全く具体的な内容の無い反論。

895 ：デフォルトの名無しさん：2010/04/22(木) 01:44:10

もう全部877で書いたからな
一言でいうと言語でやるにはレイヤ違い

896 ：デフォルトの名無しさん：2010/04/22(木) 07:10:30

>>893は「変数」や「関数」や「オブジェクト」の一般的な実装方法すら分かっていない。
既にあるから簡単だと思ってしまっているだけ。

「変数」や「関数」や「オブジェクト」と、「割り込み」に”レイヤー”の違いなんてないし
”レイヤー”に違いがあるとしても言語で合わせればいいだけの話。

897 ：デフォルトの名無しさん：2010/04/22(木) 07:43:53

割り込みの抽象化はOSの仕事だろ。抽象化の仕方もいろいろある。

898 ：デフォルトの名無しさん：2010/04/22(木) 09:24:59

>>896
話噛み合わないなw
変数、関数とオブジェクトを一緒にしてる時点でまず話がすれ違う訳だよ

俺は無理そうな理由は書いたから
どう言語に入れるか具体的に書いてみなよ

899 ：デフォルトの名無しさん：2010/04/22(木) 11:52:09

割り込みはOSが提供してるんだよ？
そのOSを作れるレベルの言語の話をしてるのに…レイヤー違いにも程がある

900 ：デフォルトの名無しさん：2010/04/22(木) 12:00:07

>>899
割り込み自体はCPUの機能だよ
OSが提供してるのはそれをラップしたもの
番号振って統一的手段で使えるようにした割り込みサービスな

901 ：デフォルトの名無しさん：2010/04/22(木) 13:21:52

割り込み処理に関しては>>897　>>900で良いかな。

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

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

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

例外処理の説明にプログラムが想定していない例外が発生したときに云々
という記述があるのが不味くて、例外処理は、プログラムが想定していた
例外に対処する処理を便利に記述する仕組みだと思うんです。

902 ：デフォルトの名無しさん：2010/04/22(木) 13:33:34

>>901　
以上が前置きで、アサートと例外処理、これは独自に発展してきた
物なので、別物になってるんだけど、そして別でも、まぁ良いんだけど、
この辺をもう少しすっきりまとめ直せないかとか思うんだ。

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

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

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

んで、その辺の事情って、構文に問題があるような気がするんだけど
どうだろうか？

903 ：デフォルトの名無しさん：2010/04/22(木) 13:38:26

普通にエラーコード決めて戻り値でいんじゃない

904 ：デフォルトの名無しさん：2010/04/22(木) 13:46:59

ひとことで言えばassertはデバッグ支援で強制abortする
例外処理は例外(エラー)という名の正常処理をするための構文

905 ：デフォルトの名無しさん：2010/04/22(木) 13:55:57

>>904
それは分かってるんだって、（分かってない人が多すぎるけど）
以下自己引用。
＞例外処理の説明にプログラムが想定していない例外が発生したときに云々
＞という記述があるのが不味くて、例外処理は、プログラムが想定していた
＞例外に対処する処理を便利に記述する仕組みだと思うんです。

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

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

だけどこうしちゃうと、
try{
　　一つ目
　　二つ目
　　三つ目
}
catch{
}
の形が難しくなるし、オブジェクト指向的に問題が出てきそうな
気もするし。

906 ：デフォルトの名無しさん：2010/04/22(木) 14:04:37

OS書くような低水準言語にtry-catchとかイラネ。終わり。

907 ：デフォルトの名無しさん：2010/04/22(木) 14:08:13

>>906
それはそれで一つの見解だと思うのだけれども、>>1はC++に変わるような、
と書いているので、try-catchに関しても考えてみたいと思うのです。
この構文は後から追加されたので、構文的にベストなのかどうか、
私は疑問で、ライブラリからのエラー通知に必要だから、最小限の機構として
追加された構文、と了解していて。

で、そもそも構文自体がとってつけた物なので、どうも使い勝手悪いんじゃ
無いのかな？という問題意識なんですよ。

908 ：デフォルトの名無しさん：2010/04/22(木) 14:12:46

setjmpとsignalに砂糖まぶしたもんだしな
元々汚いんよ
ファイル開けたら失敗返してもらうもんさ

909 ：デフォルトの名無しさん：2010/04/22(木) 14:40:09

Cのレベルの言語なら例外はいらんだろう
高級言語における「例外」そのものの有用性については、今更疑う必要があるとは
思えん、モダンな高級言語には大抵例外がある
C++の場合に限って言えば、C++特有の理由によって例外が使えないシロモノに
なっている

910 ：デフォルトの名無しさん：2010/04/22(木) 14:44:56

goには無いな
理由はエラー処理をサボるからだそうな
GCと相性はいいがね

911 ：デフォルトの名無しさん：2010/04/22(木) 14:46:09

goには無いな
理由はエラー処理をサボるからだそうな
GCと相性はいいがね
大域脱出を多用したらわかりにくいのは当然だが。

912 ：デフォルトの名無しさん：2010/04/22(木) 14:53:10

同じことなので2回言いました＾＾

913 ：デフォルトの名無しさん：2010/04/22(木) 14:58:22

携帯からなんで切れたと思ったら書けてた
すまんw

914 ：デフォルトの名無しさん：2010/04/22(木) 14:59:03

>>911
＞大域脱出を多用したらわかりにくいのは当然だが。
これだーーーーーーーーー！！
そうなんだよね、当たり前なんだよね。言葉が見つからなかった。

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

と、まぁ愚痴はこの位で、でもそれでも、例外の構文はどうなんだろ？
そっちはどう？　大域なので、
try{
　　一つ目
　　二つ目
　　三つ目
}
catch{
}
そう考えると、この構文は必要ないと思うんだ。
たまたま、一つめと二つめで似たような例外をスルーする可能性が有っても、
それはたまたまで、キャッチ節をまとめるメリットは、タイプ量が少し減る
だけで、可読性、見通しに関しては逆効果だと思う。

915 ：デフォルトの名無しさん：2010/04/22(木) 15:09:02

構文に関してはあんなモンじゃないの？
他にあんまいいのも思いつかないけど

916 ：デフォルトの名無しさん：2010/04/22(木) 15:12:36

後携帯じゃないんだからw
ストラウストラップなw

917 ：デフォルトの名無しさん：2010/04/22(木) 15:53:37

>>901
> 割り込み処理に関しては>>897　>>900で良いかな。

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

新言語では割り込みを第一級オブジェクトとして扱えるようにしよう。

918 ：デフォルトの名無しさん：2010/04/22(木) 16:00:06

>>917
実はそれは有りだと思うんだよね。
例えばsignal構文みたいなのを作って、
ＯＳでのsignal処理と、ＣＰＵの割り込み処理では、
書けること書き方書くべきことが変わるだけ、
という抽象化はあり得ると思う。

その辺詳しくないので、構文の提案をして欲しい。
インテルチップと他のチップ、ＵＮＩＸ系のＯＳ、と言う具合に
提案してくれれば良いんじゃない？

919 ：デフォルトの名無しさん：2010/04/22(木) 16:06:11

POSIXだと標準のsignal()じゃなくてsigaction()使うし
Windowsのsignal()は、言語標準だから仕方なくエミュレートして入れてるだけ
言語どころか標準ライブラリにも要らないと思う

920 ：デフォルトの名無しさん：2010/04/22(木) 16:07:14

try-catch-finalの構文上の欠点は、ブロックを伴うために通常の処理であってもインデントをしたくなってしまう点。

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

try my_area (キャッチする例外) { キャッチ時の処理 };
処理;
処理;
処理;
delete my_area;

921 ：デフォルトの名無しさん：2010/04/22(木) 16:08:27

目標立てないとモチベーション上がらないだろ。

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

っていう目標はどうよ？

922 ：デフォルトの名無しさん：2010/04/22(木) 16:11:29

>>918
> インテルチップと他のチップ、ＵＮＩＸ系のＯＳ、と言う具合に
> 提案してくれれば良いんじゃない？

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

イベントとイベントリスナーの構文を定義するんだろうな。

923 ：デフォルトの名無しさん：2010/04/22(木) 16:23:25

>>922
俺は、Environment division提案した人で、
アーキテクチャーごとに可用範囲が変わるのは別に構わないと思ってる。
構文も出来るだけ統一した方が良いけども、違うＣＰＵや同じＣＰＵでも
違うＯＳに載ってるのなら、違っても良いと思う。

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

なんども書くけど、ライトワンスは幻想、ライトワンスを目指したが為に
どれだけの非互換と、ポーティング時の悪夢に見舞われたか、同じように
書けば、どんなＣＰＵでも同じように動くが、違う場所ではそもそも
書けない（コンパイルエラー）というのが、新しい低水準高級言語に
求められる性格だと思うんだ。

924 ：デフォルトの名無しさん：2010/04/22(木) 16:28:30

元々signal自体が割り込みの抽象化だしな
チョイ斜めにずれた延長上にtry-catchがあるわけだ。
グローバルにtry-catchみたいな構文にするのがいいだろう
割り込み用にcontinuationみたいなことが出来ても面白い

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

単なる例外と違って外部ハードが絡んで条件が多いし
言語専用OSで下位をラッピングしたら出来ると思うがそれじゃ意味ないな
OSのローレベル部分やベタな処理を書いたことがないやつが
書いてみたいってだけの流れに見える

925 ：デフォルトの名無しさん：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=>
}

926 ：デフォルトの名無しさん：2010/04/22(木) 17:04:04

>>923
日本語でおｋ

つーかC/C++がライトワンスを目指した言語だなんて初めて聞いたわｗ
Javaと勘違いしてんじゃないの？

927 ：デフォルトの名無しさん：2010/04/22(木) 17:10:49

>>924
正直、Abs(）と何が違うんだと言われるレベルだと思うんだけど、
それでもコンパイラーが知っているというのは、後々に違ってくる
と思うんだ。

928 ：デフォルトの名無しさん：2010/04/22(木) 17:39:00

「使えないシステムや処理系はエラーにする」んだと、標準に入ったところで
別に今となんもかわらん気がするけど……

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

Javaのsynchronizedみたいな例は、ちょっとこのスレ的には高級すぎるが、
あれもスレッドが利用できない環境では無視、の方法でいいんだろうな

929 ：デフォルトの名無しさん：2010/04/22(木) 17:40:00

あ、一行目は
使えないシステムや処理系「では」エラーにする
の間違い

930 ：デフォルトの名無しさん：2010/04/22(木) 18:00:15

>>928
具体的にと問われると、妄想レベルになるんだけど、現状

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

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

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

931 ：デフォルトの名無しさん：2010/04/22(木) 18:02:27

>>930
あー例え悪いな、馬鹿に変なつっこみされそう。
でも、まぁ、コンパイラが知らないからぐちゃぐちゃしていくという
例としてあげた悪いこと。

でコンパイラが知ってればどう解決するんだってことはまだ模索中
だけども、知ってると言うことがまず必要だと思うって事。

932 ：デフォルトの名無しさん：2010/04/22(木) 18:02:44

>>930
intに関してはC99ではstdint.hが標準になったし
特に反対する人はいないだろう

933 ：デフォルトの名無しさん：2010/04/22(木) 18:52:47

>>923
> アーキテクチャーごとに可用範囲が変わるのは別に構わないと思ってる。
> 構文も出来るだけ統一した方が良いけども、違うＣＰＵや同じＣＰＵでも
> 違うＯＳに載ってるのなら、違っても良いと思う。

勝手に思ってろ。

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

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

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

アーキテクチャ依存の機能は他所でやれ。

934 ：デフォルトの名無しさん：2010/04/22(木) 19:17:34

>>924
例外を怖がりすぎだ。素人。

935 ：デフォルトの名無しさん：2010/04/22(木) 19:19:08

この素人が怖がってるのは例外じゃなくて割り込みだよ

936 ：デフォルトの名無しさん：2010/04/22(木) 19:46:50

割込み機能が単独で存在するのではなく、
割込み、例外、非同期IOとかを統一してイベント機能にするんだろうな。

937 ：デフォルトの名無しさん：2010/04/22(木) 20:38:57

イベントドリブンだと困るようなリアルタイム処理オンリーの組み込みはどうすんねん

938 ：デフォルトの名無しさん：2010/04/22(木) 20:59:42

例外を一緒くたに扱うのはものすごく違和感があるんだが……
別物だろ？

939 ：デフォルトの名無しさん：2010/04/22(木) 21:02:55

例外と割り込みは全く違うだろ。
同じなのは、どちらもハンドラが起動されることぐらい。

940 ：デフォルトの名無しさん：2010/04/22(木) 21:02:57

イベントドリブンなプログラムで汎用的に役に立つのがコルーチン
コルーチン欲しいな

941 ：デフォルトの名無しさん：2010/04/22(木) 21:03:25

例外=割り込みっていうCPUもある罠

942 ：デフォルトの名無しさん：2010/04/22(木) 21:13:52

ど素人がデタラメ言ってかき混ぜてるの図

943 ：デフォルトの名無しさん：2010/04/22(木) 21:26:39

未熟さを新言語で補えると思ってるとか？

944 ：デフォルトの名無しさん：2010/04/22(木) 21:28:09

>>937
どうするってどういう事？
別にリアルタイム処理すればいいじゃん。

945 ：デフォルトの名無しさん：2010/04/22(木) 21:31:44

>>941
その「例外」って何？
CPUの機能として「例外」があるの？ソフトウェア割込みのこと？

946 ：デフォルトの名無しさん：2010/04/22(木) 21:54:34

ゼロ除算とかページフォルトとかのことじゃないの

947 ：デフォルトの名無しさん：2010/04/22(木) 22:37:27

>>934
素人だが、例外も割り込みも普通にアセンブラとCで書いてるよ
怖いからな

948 ：デフォルトの名無しさん：2010/04/22(木) 22:39:46

スレの英才たちによって
いよいよCPU固有言語にRTOSを組み込む日が来そうだなｗ

949 ：デフォルトの名無しさん：2010/04/22(木) 22:40:58

マジレスですまんが、CPU固有言語はイラネーは。

950 ：デフォルトの名無しさん：2010/04/22(木) 22:43:08

まずは汎用言語だろうな

951 ：デフォルトの名無しさん：2010/04/22(木) 22:48:01

CPU固有なら、構造化アセンブラでいいだろ。それなら、
asmをサポートしたC、あるいは、もうちょっと踏み込んで Turbo Cみたいにしてもいい。

952 ：デフォルトの名無しさん：2010/04/22(木) 23:49:09

CPU固有なんて好きにやってろ。
言語仕様にはout of scopeだ。

953 ：デフォルトの名無しさん：2010/04/23(金) 00:13:41

おまえらが週末までにどんなモノを出してくるか楽しみですわ。

954 ：デフォルトの名無しさん：2010/04/23(金) 01:23:53

やはりみんな直接は触れたくないようだな
なんか出てるしな

955 ：デフォルトの名無しさん：2010/04/23(金) 01:42:08

ぶっちゃけ今のgcc以上に組み込みにも使える低レベルな高級言語はないんだし
超える仕様をお願いね♪

956 ：デフォルトの名無しさん：2010/04/23(金) 01:43:02

斜め上を通過するだろうな

957 ：デフォルトの名無しさん：2010/04/23(金) 01:51:52

え、CPU固有言語にRTOSを組み込んでくれんじゃないの？
割り込み周りはvxWorksが良かったな

958 ：デフォルトの名無しさん：2010/04/23(金) 01:55:18

正直、C以上に低レベルな言語は考えにくい。
だとしたら別の部分にこだわってみたらどうかな。
例えばライブラリが使い易い言語がいいな。
ライブラリを一つのファイルにまとめる方法を提供し、その一つのファイルを適当な場所にコピペしたら
リンクとかライブラリパスとかインクルードパスとかそんなの設定しなくても呼び出したら勝手にやってくれるのがいい。
中二言語とかいうなよ。使い易いんだからいいじゃん。

959 ：デフォルトの名無しさん：2010/04/23(金) 01:57:48

C≒アセンブラだからな

960 ：デフォルトの名無しさん：2010/04/23(金) 02:09:33

どういう人を対象にするかも決めといた方がいいな。
俺は中高生対象の低級言語を目指したい。

961 ：デフォルトの名無しさん：2010/04/23(金) 02:10:57

中高生対象の勉強用低級言語な。

962 ：デフォルトの名無しさん：2010/04/23(金) 02:11:42

だとしたら打倒Cより打倒VBの方が近い

963 ：デフォルトの名無しさん：2010/04/23(金) 02:12:54

>>960
まぁ、実際にできたとしてもエンタープライズでは使ってもらえないだろうな。
こんなところで考えた怪しげな言語なんてｗ

964 ：デフォルトの名無しさん：2010/04/23(金) 02:15:55

大学で作れば附属の学校に使わせることが出来るんだよな
作ったソフトを、何の成果もないのに（まあ成果を得るためにやるんだが）、小中学生に使わせてて驚いた

965 ：デフォルトの名無しさん：2010/04/23(金) 02:18:47

それ低レベルつってもレベル違いじゃないのｗ
むしろSmalltalkやLegoなんかが目指した世界じゃ

966 ：デフォルトの名無しさん：2010/04/23(金) 02:19:51

>>965
smalltalkではCPUの仕組みを意識したプログラミングなんてできないでしょ。

967 ：デフォルトの名無しさん：2010/04/23(金) 02:20:55

CPUの仕組みを学習するための言語なの？
なんかそういう趣旨の本があった気がするな

968 ：デフォルトの名無しさん：2010/04/23(金) 02:35:55

ふむ。でも中高生なら
やはりちゃんとした言語がいいと思うな
敷居は少し低めでもいいけど、ちゃんと実務に耐えるレベルの奴

969 ：デフォルトの名無しさん：2010/04/23(金) 07:06:00

久々に来たらまだスレ続いててワロタ
ム板のＶＩＰ風スレは元気だな
てか、とりあえずたたき台でも作ろうぜ

まずは簡易なマクロアセンブラとヒープ管理と
一連のマクロをtypedefしてコンパイル時に型として解決される機能と
静的配列の機構と
typedef機能の範疇で構造を静的に定義できる機能用意した言語作って
拡充して改変して最終的にＣ言語って名前にしようぜ

970 ：デフォルトの名無しさん：2010/04/23(金) 07:56:53

SimulaとBooを参考にした言語を作って
Dorifって名前にしようぜ

971 ：デフォルトの名無しさん：2010/04/23(金) 12:22:29

中高生なんて吸収はやいんだからアセンブラとCをしっかりやらせた方が将来どれだけ役に立つか

972 ：デフォルトの名無しさん：2010/04/23(金) 12:24:37

大学では、Cと関数型言語からやるんだろ。Lispはもう消えていい。

973 ：967：2010/04/23(金) 12:29:49

今日図書館で確認したら
「動かしながら理解するCPUの仕組み（ブルーバックス）」
言語はアセンブラだった

974 ：デフォルトの名無しさん：2010/04/23(金) 13:07:59

ブルーバックスレベルなら俺でも書けそうだ

975 ：デフォルトの名無しさん：2010/04/23(金) 13:39:00

素人に説明しようとして全然伝わらないでブチ切れるような奴には無理だぞ

976 ：environment：2010/04/23(金) 13:51:39

叩く目安になりそうなのでコテハンは嫌なのだが
>>960
おいらの一連の提案はＣＰＵメーカーが新命令セット出すときに
おまけで付けられるような言語、というイーメージ。
言語の環境差異部分を読めば、新しいＣＰＵ（新たな開発でもＯＫ）が
理解できて、そのまま組み始めれるような感じ。

977 ：デフォルトの名無しさん：2010/04/23(金) 15:22:13

次スレ要るのか？

厨房隔離スレとしての役割は果たしてるかな？

978 ：デフォルトの名無しさん：2010/04/23(金) 16:22:15

>974
ブルーバックスナメんな。「集合とはなにか」レベルかけたら100冊買ってやる

979 ：デフォルトの名無しさん：2010/04/23(金) 16:36:02

ブルーバックスは玉石

980 ：デフォルトの名無しさん：2010/04/23(金) 16:39:16

おまえらはオール石だけどな

981 ：デフォルトの名無しさん：2010/04/23(金) 19:50:18

東鳩オールストーン

982 ：デフォルトの名無しさん：2010/04/23(金) 19:53:31

思いついた。
もしも何かこのスレで新言語作るってんなら、名前は是非

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

‥皮肉っぽくていいだろ？ｗ

983 ：デフォルトの名無しさん：2010/04/23(金) 20:56:52

ume

言語名はkuma-だっつってんだろ

984 ：デフォルトの名無しさん：2010/04/23(金) 21:35:48

新言語は新言語で書かれるのだろうか？

985 ：デフォルトの名無しさん：2010/04/23(金) 21:52:34

誰かBNFを・・・

986 ：デフォルトの名無しさん：2010/04/23(金) 22:24:57

>>982
ハァ？空論もじってるとして、Koolong自体は何を現してるわけ？
空論をちょっと厨二臭く言ってみただけのカスッカスの能無し命名だろ？

何が「思いついた。」だよ
Dat落ちの頃合を狙って張ったんだろ？
万一ボロカスに否定されてもすぐ落ちるから、精神的ダメージは最小限に抑えられるってか？ｗ

987 ：デフォルトの名無しさん：2010/04/23(金) 22:42:15

え、ネタスレじゃないの

988 ：デフォルトの名無しさん：2010/04/23(金) 22:53:58

嘘から出た真…じゃなくて身から出た錆、か

989 ：デフォルトの名無しさん：2010/04/23(金) 23:12:25

次スレ

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

990 ：デフォルトの名無しさん：2010/04/23(金) 23:19:26

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

991 ：デフォルトの名無しさん：2010/04/24(土) 00:33:31

ウキーッ、ウキッウキキ

992 ：デフォルトの名無しさん：2010/04/24(土) 00:37:21

ちゃんと妄想って入れとけよ

993 ：デフォルトの名無しさん：2010/04/24(土) 00:43:52

>>982
‥皮肉っぽくていいだろ？ｗ

ｗｗｗｗｗｗｗｗｗｗｗｗ

994 ：デフォルトの名無しさん：2010/04/24(土) 00:57:28

>>970
pythonに対抗する国産言語に付けてやってくれ。

RubyをDorifに改名しようか。

995 ：デフォルトの名無しさん：2010/04/24(土) 03:18:55

●フルマシンコード番号で書けば難解かつ超低レベル

996 ：デフォルトの名無しさん：2010/04/24(土) 03:26:42

>>995が馬鹿すぎる

997 ：デフォルトの名無しさん：2010/04/24(土) 06:21:57

>>996
もっと素晴らしいコードがあった。
そうだ、超低級言語を極めたら
0と1の2進数で記述すべきだ。

998 ：デフォルトの名無しさん：2010/04/24(土) 06:46:22

じゃ、x86でhello worldのmain()な。
文字列自体はどっか別にあるとかは気にしないでくれ。

11000111000001001110110010000011
10000100100000000010010000000100
11110011111010000000100000000100
10000011111111111111111111111110
01011101010110010000010011000100
11000011111111000110000110001101
10010000100100001001000010010000

999 ：デフォルトの名無しさん：2010/04/24(土) 07:08:27

>>986
そんなに長くて激しいレスもらえるとは思わなかった
しかもずいぶん内容が斜め上。ここが真正低脳隔離スレだと忘れてた
ＶＩＰに帰るわ

1000 ：986：2010/04/24(土) 07:14:32

>>999
低脳はお前だろ
俺たちはお前の考えなんてお見通しなんだよ
第一空論じゃない。俺が実際に作っているし、公開の準備もしてる
お前はそれすら知らないだろ。無知乙

そうやって何も知らない癖に人を低脳よばわりすることは自らの低脳さをさらけ出してるって気付！！！！！！
俺が世界の中心なんだよ！！！

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。