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

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

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

1 :デフォルトの名無しさん:2010/04/03(土) 09:24:04
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。

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

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

2 :デフォルトの名無しさん:2010/04/03(土) 10:46:33
結論: C++になります

3 :デフォルトの名無しさん:2010/04/03(土) 13:20:19
言語にあわせてCPUマイクロコードを設計しる

すでに多数あるが。

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

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

5 :デフォルトの名無しさん:2010/04/03(土) 14:27:13
デバドラ屋だって、オサレ言語で開発したい!

6 :デフォルトの名無しさん:2010/04/03(土) 14:27:42
OSに依存するものが多いな。

7 :デフォルトの名無しさん:2010/04/03(土) 14:34:00
それをうまく抽象化するのが新言語の課題だろうね。

8 :デフォルトの名無しさん:2010/04/03(土) 15:24:33
本当におまいらアイディア出さないな。 >1は一体どこに行った?


9 :デフォルトの名無しさん:2010/04/03(土) 15:42:06
これまで出てきたもののほとんどは、OSが存在しないことには実装できないか、役に立たないものばかり。
とりあえずC99の機能を今流の文法にしたらどうなるかを考えてみたら。

10 :デフォルトの名無しさん:2010/04/03(土) 15:42:47
 C/C++は古い────→ 最新のオサレな言語・技術で
   ↑              「低レベル」なことしたい
   │                   │
   │                   ↓
   │             でも、最新のオサレな言語・技術って、
結局、C/C++だよ←─── OSに依存すること多くね?
                 OSより 「低レベル」なこと出来なくね?


11 :デフォルトの名無しさん:2010/04/03(土) 16:06:12
同じ話の繰り返しにしかならないから
このスレ落とせ

12 :デフォルトの名無しさん:2010/04/03(土) 16:14:44
>9
>4 みたいなのはどうなのよ。OSに依存するのは実行制御以下ぐらいじゃね?
それともこの話についていけてない?


13 :デフォルトの名無しさん:2010/04/03(土) 16:17:36
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

14 :デフォルトの名無しさん:2010/04/03(土) 16:25:22
>>12
OSがなかったら、ヒープすらないことに気付けよ。

15 :デフォルトの名無しさん:2010/04/03(土) 16:28:44
と思ったら、そうでもないものが並んでいた。テンプレートはあってもいいが、プリミティブ型しかないならあまり役に立たない。

16 :デフォルトの名無しさん:2010/04/03(土) 19:40:00
クラスに相当する機能位は欲しいな。

17 :デフォルトの名無しさん:2010/04/03(土) 20:20:49
C++0xをブラッシュアップするだけでおk

18 :デフォルトの名無しさん:2010/04/03(土) 22:05:05
で、どのように?

19 :デフォルトの名無しさん:2010/04/03(土) 22:46:26
正規表現もファーストクラスで使えるように構文は用意したい

20 :デフォルトの名無しさん:2010/04/03(土) 22:49:48
ビジネスクラスで十分

21 :デフォルトの名無しさん:2010/04/03(土) 22:52:47
つまり、より広く使いたいと言うことだな

22 :デフォルトの名無しさん:2010/04/03(土) 22:54:26
どう見てもこのスレはVIP

23 :デフォルトの名無しさん:2010/04/03(土) 23:04:18
低級言語にポインタは必須だな。
機種依存も必須。
でもjavaみたいに間違いが起こりにくい仕組みは欲しい。

24 :デフォルトの名無しさん:2010/04/03(土) 23:16:51
新スレ必要だったのか

25 :デフォルトの名無しさん:2010/04/03(土) 23:28:01
ポインタより便利にアドレスを直接操作できるやり方ってあるのかな。

26 :デフォルトの名無しさん:2010/04/03(土) 23:34:16
新スレまでいったのか。
いくら夢を語っても、どうせ現物はできないし、むなしくなるだけなのにな。

27 :デフォルトの名無しさん:2010/04/03(土) 23:36:38
夢のない男の人って情けない。絶対に結婚したくないタイプ

28 :デフォルトの名無しさん:2010/04/04(日) 00:01:48
これについてお前らの考察を聞かせてくれ

JavaとC++のパフォーマンスを比較する
http://japan.internet.com/developer/20100402/26.html

29 :デフォルトの名無しさん:2010/04/04(日) 00:03:53
すばらしい

30 :デフォルトの名無しさん:2010/04/04(日) 00:11:24
>>28
最適化のことを「条件付き」という筆者はバカ。

31 :デフォルトの名無しさん:2010/04/04(日) 00:20:37
最適化できないプログラミング言語はダメだな

32 :デフォルトの名無しさん:2010/04/04(日) 00:23:38
10年以上まえ、バブルソートをCとJavaで書いて時間を計ったら、
最適化なしなら大差なしで、最適化ありならCが倍くらい速かった。

単純にループでまわして配列にアクセスしたり、数値演算するだけ
のコードならもうJavaもCもかわらないとかって結果になっても
驚かない感じだけそ、まだそこまでも行ってないんだな。

一般的なアプリのコードだと、Javaは文字列も粒度の小さいクラス(構造体)
も全部ヒープに置かないといけないんで、どうがんばってもC++に
かなわないような気がする。

33 :デフォルトの名無しさん:2010/04/04(日) 00:32:40
C++「ちくしょーちくしょー! 最適化…… 最適化さえすればー!」
JAVA「……おい、お前の言う最適化とやらは、そんなにすごいのか?」
C++「そうだ、最適化さえすればお前などに……」
JAVA「ほう、本当に速くなるんだな?」
C++「そうだ、最適化さえすればお前などに……」
JAVA「…………」
C++「ちくしょーちくしょー! 最適化……最適化さえすればー!」
トランクス「……いったい何を話してるんだ?」
C++「ちくしょーちくしょー! 最適化……最適化さえすればー!」
JAVA「おい、やってみろよ。最適化を」
C++「なんだと!?」
ナレーション「いったい、どうなってしまうのか!?」

34 :デフォルトの名無しさん:2010/04/04(日) 00:38:54
-O6

35 :デフォルトの名無しさん:2010/04/04(日) 00:42:10
sseインラインアセンブラだと数倍差つくよね

36 :デフォルトの名無しさん:2010/04/04(日) 00:48:16
最適化は”する”のが当然であって、しない状態とパフォーマンスの比較するるなんて全くナンセンス


37 :デフォルトの名無しさん:2010/04/04(日) 01:17:15
>>33
逆だろw

JAVA「ちくしょーちくしょー! 最適化…… 最適化さえすればー!」
C++「……いや、最適化なんて普通だし」
JAVA「そうだ、最適化さえすればお前などに……」
C++「やればいいじゃん」
JAVA「そうだ、最適化さえすればお前などに……」
C++「…………」
JAVA「ちくしょーちくしょー! 最適化……最適化さえすればー!」
トランクス「……いったい何を話してるんだ?」
JAVA「ちくしょーちくしょー! 最適化……最適化さえすればー!」
C++「だからやればいいじゃん、最適化を」
JAVA「なんだと!?」
ナレーション「いったい、どうなってしまうのか!?」

38 :デフォルトの名無しさん:2010/04/04(日) 01:25:38
javaも最適化してないわけがないから、やっぱ、

vmのコードでコンパイル→それからJITで本当のマシン後に変換

ってあたりでどうしようもないんでしょ > 遅いの

39 :デフォルトの名無しさん:2010/04/04(日) 02:17:26
Javaが遅いのは、JITでの変換に伴うオーバーヘッドのせいではなく、変換した後でも遅い。

ネイティブコードにすれば何でも早くなるってモンじゃない。

プログラムは、ネイティブコードで速くなるように書いて初めて速くなる。

Javaではネイティブコードで速くなるようには書けない。だから遅い。

40 :デフォルトの名無しさん:2010/04/04(日) 02:31:33
ほっとけばVMが最適化されて速くなると妄想できるだけでJAVAキチにとっては十分なんだよ

41 :デフォルトの名無しさん:2010/04/04(日) 02:37:04
>>39
その理屈はおかしい。
・C++のコード→ネイティブのアセンブラ
で、速い最適化が可能なら、
・JavaVMのコード→ネイティブのマシン語
の変換中の最適化でも速い最適化ができない理由がない

42 :デフォルトの名無しさん:2010/04/04(日) 02:38:37
理由がないのに遅いってことは、Sunの技術者はどうしようもない無能ってことだな。

43 :デフォルトの名無しさん:2010/04/04(日) 02:41:26
無能だからSunなんかに入っちゃうんだろwww

44 :デフォルトの名無しさん:2010/04/04(日) 02:41:26
>>42
いや、>>39の考察が間違ってるってことだろ。

45 :デフォルトの名無しさん:2010/04/04(日) 02:42:11
で、どう間違ってるのかは述べないんだ。

46 :デフォルトの名無しさん:2010/04/04(日) 02:43:30
>>44
むしろ、>>42>>41の考察が間違ってることを証明している。

47 :デフォルトの名無しさん:2010/04/04(日) 02:44:48
>>45
>>39 が間違ってる理由は >>41 で述べたよ。
Javaが遅い理由は >>39 の考察した理由以外のところであるってことだけど、
それはしらない。

48 :デフォルトの名無しさん:2010/04/04(日) 02:45:25
>>41はネイディブにすれば何でも速くなると思ってるマヌケ

49 :デフォルトの名無しさん:2010/04/04(日) 02:48:37
>>41 が正しいというなら、C++がほかの言語(vmのコードも含めて)に比べて
最適化がしやすい理由が無ければならないけど、そんなことは無いから、
>>41 は完全に間違ってる。
Javaが遅い理由はほかに求めるべき。

50 :デフォルトの名無しさん:2010/04/04(日) 02:49:51
>>49 のアンカー間違えたよ。>>39だった。

51 :デフォルトの名無しさん:2010/04/04(日) 02:50:37
>>49
> >>41 は完全に間違ってる。

同意。

52 :デフォルトの名無しさん:2010/04/04(日) 02:52:52
>>48
ぜんぜん見当違いの指摘。
話題についてこれない人は入ってこないでほしい。

ネイティブに変換する前のコードがC++だったら
JavaVMのコードの場合より、最適化がしやすいかどうかっていうのが
問題になってる。




53 :デフォルトの名無しさん:2010/04/04(日) 02:58:09
JavaがC++と同程度にネイティブコードに最適化しやすいのであれば、最適化コードを生成できないSunの技術者はどうしようもない無能。
Sunの技術者がどうしようもない無能でないならば、JavaはC++と同程度にはネイティブコードに最適化できないクズ言語。

54 :デフォルトの名無しさん:2010/04/04(日) 03:05:03
まあ、ポインターが使えるってだけでもJavaよりC++の方が最適化しやすいわな。
GC任せのメモリ管理をネイティブコードに最適化しようにも、そりゃオーバーヘッドが当然大きくなる。

「ネイティブコードにしたからって速くなるわけじゃない」ってのに噛み付くって、どんだけド素人なんだよw

55 :デフォルトの名無しさん:2010/04/04(日) 03:13:05
Javaなんてクソ言語どうでもいいよ ┐(´д`)┌ヤレヤレ

新言語の話しようぜ!

56 :デフォルトの名無しさん:2010/04/04(日) 03:15:33
バカばっか
JAVAが遅いのはお前らみたいなタコがタココード書いても危険にならんようお仕着せ機能がてんこ盛りなだけで
JAVAが実際やってる事を機能的になぞるC++コードを書いたら同程度に遅くなるっつの
何がネイティブコードなら速いだよバカすぎ

57 :デフォルトの名無しさん:2010/04/04(日) 03:17:21
>>53
Sunが無能って可能性もあるな。
C++でも、コンパイラによって最適化の性能が違うし、昔はJavaコンパイラ&VMの
性能差も各メーカー間でどうこうって話題があったしな。

ま、どっちにしろ>>39の考察は間違ってるってことで。

58 :デフォルトの名無しさん:2010/04/04(日) 03:18:59
     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |
.   /: : : //ヾ ; :|!: イ、||ll|||||::||    ノノ  イ|||||||ヾ、 |: ::|!: : イ: ::|/   な 思 が
   /: : ://: : :ヽソ::ヽl |{ i||ll"ン    ´   i| l|||l"l `|: /|: : /'!/l     ん う
 ∠: : : ~: : : : : : : :丶ゝ-―-      ,  ー=z_ソ   |/ ハメ;, :: ::|.   だ ん
   i|::ハ: : : : : : : : : : : 、ヘヘヘヘ     、  ヘヘヘヘヘ /: : : : : \,|.   ろ な
   |!l |: : : : : : : : :、: ::\    、-―-,      / : : :丶;,,;,:ミヽ   う  ら
     丶: :ハ、lヽ: :ヽ: : ::\__  `~ "      /: : ト; lヽ)   ゝ
       レ `| `、l`、>=ニ´        ,  _´ : :} `   /
         ,,、r"^~´"''''"t-`r、 _  -、 ´ヽノ \ノ   /    お ・
       ,;'~  _r-- 、__     ~f、_>'、_         |  で  前 ・
      f~  ,;"     ~"t___    ミ、 ^'t         |  は  ん ・
      ,"  ,~         ヾ~'-、__ ミ_ξ丶     |  な  中 ・
     ;'  ,イ ..          ヽ_   ヾ、0ヽ丶    l         /
     ( ;":: |: :: ..          .`,   ヾ 丶 !    \____/
     ;;;; :: 入:: :: ::      l`ー-、   )l   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶


59 :デフォルトの名無しさん:2010/04/04(日) 03:23:19
>>56
話題についてこれない人は、入ってこなくていいって。

その理屈だと >>28 のような、単純なループや数値計算だけの
コードでJavaが遅い理由がわからない。

60 :デフォルトの名無しさん:2010/04/04(日) 03:23:49
最後の捨て台詞で>>57の引込みがメデタクついたので、新言語の話題再開。

61 :デフォルトの名無しさん:2010/04/04(日) 03:25:14
だれも>>59の俺理論にはついていけねーわw

62 :デフォルトの名無しさん:2010/04/04(日) 03:26:46
>>58
いや、お前の中以外では、そうなんだよ。

63 :デフォルトの名無しさん:2010/04/04(日) 03:27:07
>>59さん、僕たちを置いていかないでwwwwwwww

64 :デフォルトの名無しさん:2010/04/04(日) 03:27:29
>>59
話題についてこれてないのはお前だよww

65 :デフォルトの名無しさん:2010/04/04(日) 03:29:50
>>61
そういう理論っていうか、そういう話だもん。
どうせ、レスを2,3見て、話を把握せずに適当に「バカばっか」とか
中学生みたいなこと言いたくなったんでしょ?
>>56 は。

66 :デフォルトの名無しさん:2010/04/04(日) 03:31:31
>>60
捨てゼリフっていうか、論点が>>39が間違ってるってことだったのに
関係ない話にすりかえてごまかそうとしてたから、とりあえずまとめてみたの。


67 :デフォルトの名無しさん:2010/04/04(日) 03:32:14
なんか、痛々しい奴がいるなw

68 :デフォルトの名無しさん:2010/04/04(日) 03:34:05
>>64
いや、>>28 のような単純なコードでなぜJavaが遅いかって話題でしょ?
それを安全な言語だから遅いとかツッコミ入れてるほうが、ぜんぜん話に
ついてこれてないよ。
とりあえず一行レスしとけばごまかせるとか思うのは卒業したほうがいいよ。


69 :デフォルトの名無しさん:2010/04/04(日) 03:37:20
どうしても>>39が間違っていることにしたいようだが、そもそも>>41>>39への反論になっていないし。
「ネイティブにすれば何でも速くなる」と思ってる時点で全然論理が成り立ってないんだよ。

70 :デフォルトの名無しさん:2010/04/04(日) 03:46:42
>>68
バッカじゃねぇの?
マジ、バッカじゃねぇの?
どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ
何故遅いかだと?遅いに決まってんだろ

その意味では>>39
> Javaではネイティブコードで速くなるようには書けない。
は正しい

お前の主張が「単純なソースなのに何故チェック機構を無効化しないのか分からない」と言う物なら
もう死んだ方がいいレベル

71 :デフォルトの名無しさん:2010/04/04(日) 03:47:31
恐らく>>68は死んだ方がいい

72 :デフォルトの名無しさん:2010/04/04(日) 03:48:01
ここまで新言語の話題なし

73 :デフォルトの名無しさん:2010/04/04(日) 03:49:43
Javaプログラマーはネイティブコードに夢を抱きすぎだろw
ネイティブコードにしたからってそう簡単には速くはならんのだよw

英語ができれば俺だって国際的に活躍する一流の技術者になれるんだ、とか言ってるIT土方と一緒。
英語が話せたところでお前は一生底辺なんだよwww

74 :デフォルトの名無しさん:2010/04/04(日) 03:53:48
>>69
だから言ってるじゃん。
それって >>28 のような単純なループとか数値演算ではどうなのよって。
都合の悪いことは見えないふりするんだな。

75 :デフォルトの名無しさん:2010/04/04(日) 03:57:21
>>74 のつづき

単純なループでも、配列のチェックとかオーバーフローのチェックとか
あるだろとか、最低限の技術的な突っ込みがあるだろうって思ってたのに、
そういうのは一切なしで、都合の悪いことは見えないふりで、ひたすら
見当違いのあおりとか、人格攻撃に終始して勝利宣言な。
ほんとうにどうしようもない連中だな。


76 :デフォルトの名無しさん:2010/04/04(日) 04:01:15
型チェック境界チェックオーバー/アンダーフローチェック配列はオブジェクト
トーシロでもJAVAではこれ位やってるって事はわかる
で、これらと全く同じ要件をネイティブコード(笑)で書けば速いのか?

77 :デフォルトの名無しさん:2010/04/04(日) 04:01:45
>>70
> バッカじゃねぇの?
> マジ、バッカじゃねぇの?
> どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ

本当に気にさわったみたいだな。
しかし、この「自分の都合の悪いことはスルー」のスルー力がすごすぎる。
指摘はひたすら無視して、
>は正しい
で反論したつもりになってるんだもんな。

78 :デフォルトの名無しさん:2010/04/04(日) 04:05:56
>>76
>>75 で指摘されてやっと最低限の指摘がでてきた。

ループが固定回なら、配列のチェックなんて最適化できるだろ。


79 :デフォルトの名無しさん:2010/04/04(日) 04:06:42
>>78
バカかお前
>>76は被っただけで75なんて読んでねぇよ

80 :デフォルトの名無しさん:2010/04/04(日) 04:08:50
>>78
特大のバカ発言現る
実行時にその参照が固定配列を指してる保証がどこにある

81 :デフォルトの名無しさん:2010/04/04(日) 04:09:15
>>79
そんなのわかってて煽っただけだよ。

82 :デフォルトの名無しさん:2010/04/04(日) 04:10:38
>>78でコイツの器のミニマムさがこれ以上無いほど晒されたなwww

83 :デフォルトの名無しさん:2010/04/04(日) 04:11:43
>>81
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿と言う認識で宜しいか。

84 :デフォルトの名無しさん:2010/04/04(日) 04:22:03
オブジェクト指向だから遅い
クラス階層が広くて深いから遅い
仮想関数使うから遅い
ガベージコレクションするから遅い
ヴァーチャルマシンをはさむから遅い
実行時の動的型決定を使うから遅い
短い関数を沢山書くから遅い
毎回毎回いちいち動的にメモリ確保するから遅い
なんでも実行時に決定させる設計だと遅い
goto使わせないから遅い
アセンブラを使わせないから遅い
ポインタを使わせないから遅い
モノリシックに書かないから遅い
移植性を考えるから遅い


85 :デフォルトの名無しさん:2010/04/04(日) 04:35:01
>>82
また技術的な指摘なしで、人格攻撃かよ。

動的言語のエディタでさえ、編集中の変数にどのインスタンスが
入れられたか見えてればインテリセンス聞かせられるのに、
宣言が見えてる配列の最適化なんて聞かせられない道理がないだろ。


86 :デフォルトの名無しさん:2010/04/04(日) 04:38:21
>>83
いや、>>76を見た瞬間は
「俺の指摘をまんまオウム返しにしてきた、こいつバカだろ」って思ったけど
いくらなんでも、それはバカ過ぎるから、またレスもろくに読まずに
反論してるんだなって、優しく解釈してあげた。
でも、すごい必死で面白いから、知らない振りして煽ってみた。

87 :デフォルトの名無しさん:2010/04/04(日) 04:42:08
>>78>>85
リフレクションのリの字も知らない低レベラー乙

88 :デフォルトの名無しさん:2010/04/04(日) 04:44:38
>>87
int tbl = new int[100];
tbl[0] = 0;

これのどこにリフレクションを考慮する余地があるんですか?

89 :デフォルトの名無しさん:2010/04/04(日) 04:44:58
>>86
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿という訳だな。
なぜ「いや」から始めたのかが意味不明だが。

90 :デフォルトの名無しさん:2010/04/04(日) 04:48:06
>>89
煽ったのは、お前のドジなところだから本題には関係ない。
そのくらい分かれよ。
とにかく揚げ足をとりたくてしかたないんだな。

91 :デフォルトの名無しさん:2010/04/04(日) 04:48:27
もういいだろ
Javaを知らない馬鹿が、Javaを知らない振りをして低レベルスレに相応しい低レベルな煽りをしてるだけの話だ

92 :デフォルトの名無しさん:2010/04/04(日) 04:52:36
>>90
どこをドジと言ってるんだ?素でわからん。

93 :デフォルトの名無しさん:2010/04/04(日) 04:52:49
>>91
また人格攻撃がはじまった。
まあ、本題のほうは反論の余地がなくなったってことですね。
>>39 は間違ってるって結論で終了ってことで。

94 :デフォルトの名無しさん:2010/04/04(日) 05:00:10
>>93
お前さんが無知すぎてもはや反論の余地が無いwwww

95 :デフォルトの名無しさん:2010/04/04(日) 05:07:09
>>94
どこか無知か一つも指摘できないで、脳内で無知ってことにして煽る。
そういうのってむなしくないっすか?


てか、実際最適化してるかどうかjavaと似てるC#で
int tbl = new int[100];
tbl[0] = 100;
をコンパイルしてみたら、律儀に配列の境界チェックのコードが入ってたな。
なんで最適化しないんだろ。
最適化技術の問題か、それとも言語仕様上の問題なのか。
まあ、>>87のリフレクション説はないと思うけど。

Javaで調べるんは面倒だからやらない。


96 :デフォルトの名無しさん:2010/04/04(日) 05:37:59
LL言語とC/C++の速度比較とかありえない
どこの初心者だよ


97 :デフォルトの名無しさん:2010/04/04(日) 10:22:36
>>95
そういう最適化はJITコンパイル時に行われるんじゃないの

98 :デフォルトの名無しさん:2010/04/04(日) 10:23:06
そろそろ新言語の話しようぜ

99 :デフォルトの名無しさん:2010/04/04(日) 11:04:25
まず名前からきめようか

100 :デフォルトの名無しさん:2010/04/04(日) 11:07:00
GOがあるじゃないか

101 :デフォルトの名無しさん:2010/04/04(日) 11:13:19
Goは、Cの代わりにならない。

102 :デフォルトの名無しさん:2010/04/04(日) 11:36:00
>>84
オブジェクト指向だから遅い → NO
クラス階層が広くて深いから遅い → NO
仮想関数使うから遅い → Yes(NOにできるかな?)
ガベージコレクションするから遅い → Yes
ヴァーチャルマシンをはさむから遅い → Yes
実行時の動的型決定を使うから遅い → Yes(NOにできるかな?)
短い関数を沢山書くから遅い → NO
毎回毎回いちいち動的にメモリ確保するから遅い → Yes(ただし、そうする必要もない)
なんでも実行時に決定させる設計だと遅い → NO
goto使わせないから遅い → NO
アセンブラを使わせないから遅い → NO
ポインタを使わせないから遅い → NO
モノリシックに書かないから遅い → NO
移植性を考えるから遅い → NO

103 :デフォルトの名無しさん:2010/04/04(日) 12:00:42
Goは早くも下火になった
新物だったので一時的に話題を集めただけ
今ではD言語にも満たない

104 :デフォルトの名無しさん:2010/04/04(日) 12:04:16
>>32
Javaもエスケープ解析を有効にしたらスタックにオブジェクトをおけるんだけど、
エスケープ解析ってコンパイル時にできるものなのにクラスロード時にしちゃうから、
今度は起動速度に悪影響があるんだよなぁ。

105 :デフォルトの名無しさん:2010/04/04(日) 12:22:48
FORTRANにオブジェクト指向取り入れれば

106 :デフォルトの名無しさん:2010/04/04(日) 12:29:48
>>105
確かとっくに取り入れられてなかったか?

http://ja.wikipedia.org/wiki/Fortran

Fortran2003で取り入れられているようだ

107 :デフォルトの名無しさん:2010/04/04(日) 12:35:39
じゃあ言語名はF++0xで

108 :デフォルトの名無しさん:2010/04/04(日) 13:25:53
そういやおまいらの中でドラゴン本タイガー本中田本読んだのってどれぐらいいるの?
あとC++の設計を語るのならD&EとかARMとかも読んでいると思うけど、そのへんもどうなの?


109 :デフォルトの名無しさん:2010/04/04(日) 13:50:34
読んでねーだろこんなアイちゃんスレに書き込む輩は

110 :デフォルトの名無しさん:2010/04/04(日) 13:51:16
>>98
ラブプラス++

111 :デフォルトの名無しさん:2010/04/04(日) 14:18:28
O+++

112 :デフォルトの名無しさん:2010/04/04(日) 15:23:43
>>108
全員読んでる。当たり前だろ。

113 :デフォルトの名無しさん:2010/04/04(日) 15:32:38
>>108
常識

114 :デフォルトの名無しさん:2010/04/04(日) 16:18:46
>>99
「small」

プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
できるだけ小さな言語仕様にしたい。

115 :デフォルトの名無しさん:2010/04/04(日) 16:35:45
>プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
そんなコンセプトじゃ無いだろ。
第一、言語仕様が小さいからといってヒューマンエラーが減るわけじゃない。
もしそうだとしたらForth最強じゃないか。

116 :デフォルトの名無しさん:2010/04/04(日) 16:38:18
Forthはインタプリタの実装までを含めて仕様みたいなもんだから、
見た目ほど仕様が小さいわけでもないけどな。

117 :デフォルトの名無しさん:2010/04/04(日) 16:39:56
>>115
> そんなコンセプトじゃ無いだろ。

じゃあ、どんなコンセプトなんだ?否定する前に意見を述べよう。

118 :デフォルトの名無しさん:2010/04/04(日) 16:49:12
Cにとって代わるというのがコンセプトだろ。

119 :デフォルトの名無しさん:2010/04/04(日) 16:51:52
Cにとって代わるのに加えて、
「プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
できるだけ小さな言語仕様にしたい。」
という提案だろ?


120 :デフォルトの名無しさん:2010/04/04(日) 17:02:05
>>119
言語仕様が小さくなったら、ヒューマンエラーは増えると思うが。

121 :デフォルトの名無しさん:2010/04/04(日) 17:03:07
えっ

122 :デフォルトの名無しさん:2010/04/04(日) 17:04:18
思うのは自由だ。

123 :デフォルトの名無しさん:2010/04/04(日) 17:20:02
>>120
言語仕様が小さい方が、言語仕様を知らないことによる人間の失敗は少なくなるよね?
人間の記憶容量は有限だから。

124 :デフォルトの名無しさん:2010/04/04(日) 17:32:30
たとえば、C言語でオブジェクト指向っぽいことをやろうとした時の煩雑さとかどうよ。

言語の支援があったほうがよい機能を全部ユーザーがやるというのは無理がある。

125 :デフォルトの名無しさん:2010/04/04(日) 17:34:38
直感的で一貫性のある仕様がいいね。

126 :デフォルトの名無しさん:2010/04/04(日) 18:04:48
教育用言語なら、再帰がない方が失敗が少なくなると言えなくもない。

127 :デフォルトの名無しさん:2010/04/04(日) 18:12:44
再帰なんて、単に呼び出す関数がたまたま自分であったと言うだけであって、全く特別なものではない。
それを阻害するような例外(「ただし、自身を呼び出してはいけない」等)を仕様に付け加える方が混乱のもと。有害。

そんな例外は、仕様に絶対に含めるべきではない。

128 :デフォルトの名無しさん:2010/04/04(日) 18:19:14
>>127
auto変数とかいう特別な変数がある

129 :デフォルトの名無しさん:2010/04/04(日) 18:26:51
どう特別?スタックに乗るだけでは?

130 :デフォルトの名無しさん:2010/04/04(日) 18:31:10
変数のためにわざわざスタックを使うのは、再帰があるからだよ
再帰が無いならすべてstaticかグローバル変数でOK

131 :デフォルトの名無しさん:2010/04/04(日) 18:33:48
スタックを使わず、「staticかグローバル変数」にした場合のメリットは?

132 :デフォルトの名無しさん:2010/04/04(日) 18:36:06
>>131
超高速。

133 :デフォルトの名無しさん:2010/04/04(日) 18:36:58
>>132
どういう理由で?

134 :デフォルトの名無しさん:2010/04/04(日) 18:56:59
「staticかグローバル変数」にしたら関数の外からでも参照できて危ないとしか思えんのだが

135 :デフォルトの名無しさん:2010/04/04(日) 19:02:02
スタックポインタに足し算するのに何百クロックもかかる変なマシンを使ってる人が
ここにも登場w グローバル変数は速いと言い張るバカwwwwww

136 :デフォルトの名無しさん:2010/04/04(日) 19:03:57
古い言語ではローカル変数をスタックに取ったりはしない。

137 :デフォルトの名無しさん:2010/04/04(日) 19:04:40
>>134
関数の中でもstaticつかえるよ

138 :デフォルトの名無しさん:2010/04/04(日) 19:05:05
で?

139 :デフォルトの名無しさん:2010/04/04(日) 19:06:59
関数の中のstaticと関数の外のstaticは全く別の物だからな。
同じキーワードを使いまわしてるのは、ほとんど設計ミス。

140 :デフォルトの名無しさん:2010/04/04(日) 19:07:44
>>123
ヒーマンエラーを減らすためにいろいろな機構があるのに。

141 :デフォルトの名無しさん:2010/04/04(日) 19:08:26
グローバル変数が高速wwwwwww

142 :デフォルトの名無しさん:2010/04/04(日) 19:16:52
静的に一度だけ確保され初期化がされるstaticと、
静的にメモリに配置されアプリケーション終了まで変わらないstatic?

ってあれ?グローバルに置かれた変数の方の staticって、
そうでない物と何が違うの?

143 :デフォルトの名無しさん:2010/04/04(日) 19:20:48
>>140
その機構が、直感的で一貫性があればいいけどね。
特殊な例外の積み重ねで、プログラマーが勘違いすると、プログラマーの意図と違う結果になるのは避けたい。

144 :デフォルトの名無しさん:2010/04/04(日) 19:25:34
>>142
名前空間がファイル単位になるんじゃなかったっけ

145 :デフォルトの名無しさん:2010/04/04(日) 19:34:18
たぶんそれは名前空間じゃなくてスコープだと思う。

146 :デフォルトの名無しさん:2010/04/04(日) 19:34:53
すまん、無名名前空間の話とごっちゃにしてた

147 :デフォルトの名無しさん:2010/04/04(日) 19:43:06
file1.cpp ---
int a = 1234;
static int b = 6789;

file2.cpp ---
extern が無いと a も b も見えない。

------------
file1.h
int a = 1234;
static int b = 6789;

もしも file1.h が複数回includeされていても、b は安泰だが a はエラー


148 :デフォルトの名無しさん:2010/04/04(日) 19:44:35
>>147
初心者スレでやれ

149 :デフォルトの名無しさん:2010/04/04(日) 19:53:39
まぁ初心者云々はともかくC++におけるstaticの多義性が
>>143の「特殊な例外の積み重ね」であることは間違いないなw

150 :デフォルトの名無しさん:2010/04/04(日) 20:18:23
そもそもCPUが何してるか知らない奴多くね?

151 :デフォルトの名無しさん:2010/04/04(日) 20:33:28
論理回路の知識がなくてもプログラミングに差し支えはないだろ。
差し支えるようなプログラミング言語というのもあるかもしれんが。

152 :デフォルトの名無しさん:2010/04/04(日) 20:53:19
仕事する上ではそれほど必要ないかもしれんが
低級言語作りたいって言うんだったら必要だろう

153 :デフォルトの名無しさん:2010/04/04(日) 20:58:10
>>150
なぜそう思ったの?

154 :デフォルトの名無しさん:2010/04/04(日) 21:00:13
Javaでプログラミングするとしても、パフォーマンスを考えるためにある程度の知識は必要だろ。

155 :デフォルトの名無しさん:2010/04/04(日) 21:05:47
>>153
自分がCPUが何をしているか知らないから、それを知っていることが凄いとでも思っちゃったんじゃないの。

156 :デフォルトの名無しさん:2010/04/04(日) 21:10:17
vbプログラマとかCPUのことよくわかってないの多いぞ

157 :デフォルトの名無しさん:2010/04/04(日) 21:10:40
そんなに必要な機能があるなら、C99に取り込まれているだろう。

158 :デフォルトの名無しさん:2010/04/04(日) 21:15:58
>>156
お前がそういうコミュニティーに属しているというだけだ

159 :デフォルトの名無しさん:2010/04/04(日) 21:27:08
この流れじゃ、例えPart 3まで行っても何も決まらないだろうな

160 :デフォルトの名無しさん:2010/04/04(日) 21:39:55
新言語とかどうでも良くてJAVAを叩ければそれで満足なカスが多すぎる

161 :デフォルトの名無しさん:2010/04/04(日) 21:40:53
それって、Part3までに決めろよってことだろw
おまえ、ワクワクし過ぎw

162 :デフォルトの名無しさん:2010/04/04(日) 21:42:18
は?

163 :デフォルトの名無しさん:2010/04/04(日) 21:43:18
>>160
Javaなんて別に叩くほどの言語でも無いだろ。どうでもいい。

164 :デフォルトの名無しさん:2010/04/04(日) 21:58:22
Javaは使えない言語だが貶すほどでもない

165 :デフォルトの名無しさん:2010/04/04(日) 22:01:06
言い方を変えるか
とにかく何でも叩きたいだけの生産力絶無のカスが多すぎる

166 :デフォルトの名無しさん:2010/04/04(日) 22:02:56
普及している言語をカスといっているヤツは、その理由がわかっていないカスだから相手にしなくていい。

167 :デフォルトの名無しさん:2010/04/04(日) 22:09:45
歴史的理由にすぎない
とかいっているヤツはどうする

168 :デフォルトの名無しさん:2010/04/04(日) 22:17:08
どうでもいい。

169 :デフォルトの名無しさん:2010/04/04(日) 22:59:43
CPUどころか、OSが何してるのか知らない奴が多い。

170 :デフォルトの名無しさん:2010/04/04(日) 23:00:21
>>169
なぜそう思ったの?

171 :デフォルトの名無しさん:2010/04/04(日) 23:01:34
>>169がそういうコミュニティーに属してるんだろw

172 :デフォルトの名無しさん:2010/04/04(日) 23:09:09
>>1
TMPできるようにして

173 :デフォルトの名無しさん:2010/04/04(日) 23:16:07
世間一般はGUIの出来でOSの評価してるからな

174 :デフォルトの名無しさん:2010/04/04(日) 23:21:07
OSどころか、コンパイラが何してるのか知らない奴が多い。

175 :デフォルトの名無しさん:2010/04/04(日) 23:27:35
そりゃ利用者はコンパイラのことなんか知る必要ないからな。

176 :デフォルトの名無しさん:2010/04/04(日) 23:32:15
>>174
なぜそう思ったの?

177 :デフォルトの名無しさん:2010/04/04(日) 23:36:39
ネイティブじゃないからと中間言語を批判しているやつは、コンパイラがなにやっているかわかっていないような気がする。

178 :デフォルトの名無しさん:2010/04/04(日) 23:38:01
気がするのは自由だよ。

179 :デフォルトの名無しさん:2010/04/04(日) 23:40:43
断定するのも自由だ

180 :デフォルトの名無しさん:2010/04/04(日) 23:41:53
ということで、新言語の話をどうぞ。

181 :デフォルトの名無しさん:2010/04/04(日) 23:53:44
お前らホントに>108読んでるのか?

Javaにこだわるやつらは何考えているんだ?
低レベルなシステム開発向け言語というんだったらForthとかPIRとかRTLとかがターゲットじゃないの?


182 :デフォルトの名無しさん:2010/04/04(日) 23:56:34
PIR、RTLって何?

183 :デフォルトの名無しさん:2010/04/04(日) 23:58:41
>>181
スレタイ嫁

184 :デフォルトの名無しさん:2010/04/05(月) 00:02:18
Java bytecodeやCILに代わるものをやるわけではない

185 :デフォルトの名無しさん:2010/04/05(月) 00:05:01
PIR: Parrot intermediate representation
Parrotで使っている中間言語
RTL: Register Transfer Language
GCCで使っている中間言語

さすがにそこまでいくと凄いことになるな。


186 :デフォルトの名無しさん:2010/04/05(月) 00:07:11
プログラマーが三人集まると何も決まらないというのは本当ですな。
先ずは音頭を取るやつがいないと。誰か一人コテつけて幹事を名乗り出るんだ。

187 :デフォルトの名無しさん:2010/04/05(月) 00:07:41
ここで開発する言語のコンパイラがRTL吐くってことだよね?

RTLに代わるものを作るわけじゃない。

188 :デフォルトの名無しさん:2010/04/05(月) 00:16:14
よし、じゃあ何か作ろうぜ。
まず、


int main(void)
{
 // ↓続きよろしく





189 :デフォルトの名無しさん:2010/04/05(月) 00:19:46
DはC++と異なり、Cとのソースコード互換性を棄ててるから、レガシー排除したC++にあたる。
Cに代わるものは、Dのサブセットから構成できるのではないか。

190 :デフォルトの名無しさん:2010/04/05(月) 00:22:58
>>189
具体的にサブセットに含まれる機能を提示してもらえると議論しやすい

191 :デフォルトの名無しさん:2010/04/05(月) 00:24:31
このさい、基本データ型からきめようよ

192 :デフォルトの名無しさん:2010/04/05(月) 00:44:51
>>189
互換性を捨てたものが普及した試しなんてあるの?Dは互換性捨てたから駄目なんだね。

193 :デフォルトの名無しさん:2010/04/05(月) 00:47:36
C自体もそれ以前と互換性がないわけだが

194 :デフォルトの名無しさん:2010/04/05(月) 01:41:17
ここの奴らは前スレ埋める事すらしないゴミクズばっかだなw

195 :デフォルトの名無しさん:2010/04/05(月) 01:57:30
基本データ型はbyteのみ

196 :デフォルトの名無しさん:2010/04/05(月) 14:07:29
最近じゃエンディアンすらしらねえクズが仕事してるしな

ところでポインタがないから最適化できねえとか本気で書いてんのか
アホすぎ

197 :デフォルトの名無しさん:2010/04/05(月) 14:35:26
いまエンディアンを知る必要性なんてほとんどないだろ
昔は通信時なんかで考慮必要だった時もあったけどな

198 :デフォルトの名無しさん:2010/04/05(月) 14:40:06
プログラム組む上で気にしなくてもいいけど知っとくべきだとは思うな

199 :デフォルトの名無しさん:2010/04/05(月) 14:42:08
何らかのバイナリファイル読む場面なんて普通にあるから
エンディアンくらい普通の常識として知っとくべき。
>>197 は多分高級言語しか触らないか、テキストファイルくらいしか触らない奴と推測


200 :デフォルトの名無しさん:2010/04/05(月) 14:48:54
>>199
アセンブラも書くよ
インラインでだけど

201 :デフォルトの名無しさん:2010/04/05(月) 14:50:13
フレームワーク弄ってる分には必要のない知識なのは確かだ。

202 :デフォルトの名無しさん:2010/04/05(月) 14:55:48
ここ低級な言語のスレだよな?
ま、俺は組み込み屋だからエンディアンは関係あり

203 :デフォルトの名無しさん:2010/04/05(月) 18:42:54
>>188
void (far *func)();
*(unsigned long *)&func = 0xffff0000L;
func();
}

204 :デフォルトの名無しさん:2010/04/05(月) 18:55:32
もうね、farとか見ただけで飯が鼻から出そうです

205 :デフォルトの名無しさん:2010/04/05(月) 19:28:40
nearとかfar二度と見たくね('A`)
でも大半はsmallモデルで動いていたんだよなああの頃は

206 :デフォルトの名無しさん:2010/04/05(月) 19:29:58
あれなんでageになってんだ

207 :デフォルトの名無しさん:2010/04/05(月) 19:32:51
俺はずっと68kとかRISCが多かったから
あんまx86マシンコードの洗礼受けてないけど
見るたびに悪貨は良貨を...ってのを思い出してた。
今やスパコンを構成する位だもんな
思えば遠くへ来たもんだ


208 :デフォルトの名無しさん:2010/04/05(月) 19:47:15
x86は怒濤のクロックアップ戦争があったからね
これに唯一勝ち残ったPowerPCだけがRISCとして活躍している
ARMは低消費電力の観点から別の路線を歩いているし

209 :デフォルトの名無しさん:2010/04/05(月) 20:32:39
>>208
なぜ現存CPUコアアーキテクチャで最大勢力のMIPSに言及しないんだ?

210 :デフォルトの名無しさん:2010/04/05(月) 20:46:29
MIPSか
最大勢力という程でもないだろ
ARMの方がよほど多い

211 :デフォルトの名無しさん:2010/04/05(月) 20:50:15
腕っ節でねじりふせたと言う事か。 ARMだけに



とか言ってwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww


212 :デフォルトの名無しさん:2010/04/05(月) 20:59:22
よくわからんけどx86とかPowerPCは電池で動かすのは無理っしょ

ARMは電池で動くのでゲーム機とか携帯電話に多量に使われている

213 :デフォルトの名無しさん:2010/04/05(月) 21:38:23
ppcは高いんだよ

214 :デフォルトの名無しさん:2010/04/05(月) 21:41:43
需要供給の法則か
まあx86は性能の割りには確かに安い

215 :デフォルトの名無しさん:2010/04/05(月) 21:43:51
あとx86のソフトの豊富さを忘れちゃいけないな
FreeBSDがなければ2chも存在しなかったかもしれん

216 :デフォルトの名無しさん:2010/04/05(月) 21:44:08
>>214
あーarmとかmipsと比べたら。
x86は性能以前に高すぎ

217 :デフォルトの名無しさん:2010/04/05(月) 21:46:40
>>216
そうか
売れるから高くしても売れるってわけか
これでもまだ安くなってるんだぜ
AMDがなかったらもっとバカ高くなってるぞ

218 :デフォルトの名無しさん:2010/04/05(月) 22:07:43
しかしx86の機械語は何回見ても汚いな
C/C++をコンパイルしたリストを眺めて「ゲロ〜こんなんで
よく動いてるな」といつも思うぜ

219 :デフォルトの名無しさん:2010/04/05(月) 22:18:20
86系は美しくないから、6800系、次はRISCに性能で負けると言われていたけど、蹴散らしてしまったな。

220 :デフォルトの名無しさん:2010/04/05(月) 22:21:15
機械語に美しさを求めるような奴は、エンジニアに向いていないよ。

221 :デフォルトの名無しさん:2010/04/05(月) 22:25:06
>>220
分かってるんだ、分かってるけどどうしてもアセンブルリストを見る癖が抜けないorz

>>219
悪貨、良貨を駆逐するの諺通りになってしまったな

222 :デフォルトの名無しさん:2010/04/05(月) 22:27:52
x86は優れているから普及した。悪貨ではない。

223 :デフォルトの名無しさん:2010/04/05(月) 22:45:38
最後はチップの配線に美しさを求める人が出てくるんだろうか。

224 :デフォルトの名無しさん:2010/04/05(月) 22:47:34
>>222
優れているか?どう考えてもゴッタ煮だぞ
古い部分から新しい部分までグチャグチャ

225 :デフォルトの名無しさん:2010/04/05(月) 22:53:28
ゴッタ煮でグチャグチャな事と、優れていることは、背反ではない

226 :デフォルトの名無しさん:2010/04/05(月) 22:54:20
よくわからんなあ・・・・

単にソフトが多いだけだと思うが
どう考えてもアーキテクチャ的には汚いぞ

227 :デフォルトの名無しさん:2010/04/05(月) 22:57:04
     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |
.   /: : : //ヾ ; :|!: イ、||ll|||||::||    ノノ  イ|||||||ヾ、 |: ::|!: : イ: ::|/   な 思 が
   /: : ://: : :ヽソ::ヽl |{ i||ll"ン    ´   i| l|||l"l `|: /|: : /'!/l     ん う
 ∠: : : ~: : : : : : : :丶ゝ-―-      ,  ー=z_ソ   |/ ハメ;, :: ::|.   だ ん
   i|::ハ: : : : : : : : : : : 、ヘヘヘヘ     、  ヘヘヘヘヘ /: : : : : \,|.   ろ な
   |!l |: : : : : : : : :、: ::\    、-―-,      / : : :丶;,,;,:ミヽ   う  ら
     丶: :ハ、lヽ: :ヽ: : ::\__  `~ "      /: : ト; lヽ)   ゝ
       レ `| `、l`、>=ニ´        ,  _´ : :} `   /
         ,,、r"^~´"''''"t-`r、 _  -、 ´ヽノ \ノ   /    お ・
       ,;'~  _r-- 、__     ~f、_>'、_         |  で  前 ・
      f~  ,;"     ~"t___    ミ、 ^'t         |  は  ん ・
      ,"  ,~         ヾ~'-、__ ミ_ξ丶     |  な  中 ・
     ;'  ,イ ..          ヽ_   ヾ、0ヽ丶    l         /
     ( ;":: |: :: ..          .`,   ヾ 丶 !    \____/
     ;;;; :: 入:: :: ::      l`ー-、   )l   ヾ 丶
     "~、ソ:: :い:: :     \_  ノ ,    ヾ 丶

228 :デフォルトの名無しさん:2010/04/05(月) 22:58:35
まあ、「美しさ」でしか取り柄の無い工業製品はいらないわなw

229 :デフォルトの名無しさん:2010/04/05(月) 23:02:59
x86ダメとか、マーケティング知らないすぎ
利用者の立場で考えろよ
職人技術者には無理かな?

230 :デフォルトの名無しさん:2010/04/05(月) 23:04:23
x86ダメとは言ってないから
ただ「汚いなあ」といつも思いながら仕事してるだけ
今のところシェアがすごいんだから目をつぶってるけど

231 :デフォルトの名無しさん:2010/04/05(月) 23:08:00
良いものが売れるのではない
売れるものが良いものなのだ

232 :デフォルトの名無しさん:2010/04/05(月) 23:10:57
>>231
屁理屈はどうでもいいから
文系はどっか行けよ

233 :デフォルトの名無しさん:2010/04/05(月) 23:11:24
x86は優れているから売れた。

234 :デフォルトの名無しさん:2010/04/05(月) 23:13:41
あーはいはいわかりました
Intel信者キモイな

235 :デフォルトの名無しさん:2010/04/05(月) 23:14:21
一人で騒いでるお前がキモイ

236 :デフォルトの名無しさん:2010/04/05(月) 23:17:00
お前が騒いでるじゃねーか馬鹿か

237 :デフォルトの名無しさん:2010/04/05(月) 23:20:50
ということで、新言語の話をどうぞ。

238 :デフォルトの名無しさん:2010/04/05(月) 23:30:50
昔はRISCが主流になるって言ってたのに
PowerPCがPentiumに取って代わると信じてたのに

239 :デフォルトの名無しさん:2010/04/05(月) 23:32:30
os/2はwindowsに駆逐されたしな

240 :デフォルトの名無しさん:2010/04/05(月) 23:34:21
>>238
だからintelの野望の前にはその理想郷は崩れ去ったんだよ

241 :デフォルトの名無しさん:2010/04/05(月) 23:36:17
理想郷じゃないし。地上の楽園だろw

242 :デフォルトの名無しさん:2010/04/05(月) 23:37:52
地上の楽園かあ
綺麗なアーキテクチャごときで地上の楽園と言い切れるお前の頭の中を
一度見てみたいものだ

243 :デフォルトの名無しさん:2010/04/05(月) 23:50:18
>>242には地上の楽園の意味が通じていないようだな

244 :デフォルトの名無しさん:2010/04/05(月) 23:52:39
知らない方が幸せなこともあります。

245 :デフォルトの名無しさん:2010/04/06(火) 00:01:40
フォン・ノイマンアーキテクチャなら目くそ鼻くそだろ

246 :デフォルトの名無しさん:2010/04/06(火) 00:07:12
x86系を汚れてると思えないやつはゆとり


PC88や98の時代から魔神語とか書いてた奴なら良く知ってる。
当時の月間I/Oとか読みふけってた奴なら良く知ってる。
でも分家ザイログたんのZ80Aは許す。(セグメントとか無いから)


247 :デフォルトの名無しさん:2010/04/06(火) 00:11:48
出たw昔自慢w

魔神語と書いていたのは、マシン語を理解出来ないからだろ。
アーキテクチャの美醜を表現していたのではない。

248 :デフォルトの名無しさん:2010/04/06(火) 00:13:32
セグメントは先見の明があったな。
セグメントの無いCPU(MPU)なんて玩具だろ。

249 :デフォルトの名無しさん:2010/04/06(火) 00:14:46
知識自慢大好き

250 :デフォルトの名無しさん:2010/04/06(火) 00:26:15
I/Oにはダンプリストが掲載されていて、アセンブリ言語は殆ど書いていなかったけどな。

251 :デフォルトの名無しさん:2010/04/06(火) 00:27:00
確かに80386で「割と」まともなアーキテクチャにはなったが、その前には
8086、80286という失敗作が存在した事も忘れてはいけない

252 :デフォルトの名無しさん:2010/04/06(火) 00:28:08
メジャーどころを叩くと偉くなった気分を味わえるんだろ。

俺ってわかってる、みたいな。

253 :デフォルトの名無しさん:2010/04/06(火) 00:30:34
昔語りウザイな
ここに来てるオッサン連中なら誰でも知ってるつーの

254 :デフォルトの名無しさん:2010/04/06(火) 00:32:55
8086、80286が失敗作とか、病院行けよ。

255 :デフォルトの名無しさん:2010/04/06(火) 00:37:35
失敗作じゃねーか

256 :デフォルトの名無しさん:2010/04/06(火) 00:39:44
     /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ    ___
     /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、  /     ヽ
    /ヽヽ: ://: :!:,X~::|: /;,,;,/: :/  リ!: ::/ノ  l`ヽl !: : |: : : :l: :l: リ / そ そ お \
   /: : ヽヾ/: : l/::l |/|||llllヾ,、  / |: :/ , -==、 l\:::|: : : :|i: | /   う う  前  |

257 :デフォルトの名無しさん:2010/04/06(火) 00:42:17
>>255
病院行け

258 :デフォルトの名無しさん:2010/04/06(火) 00:45:10
俺もオッサンだが
結局wintelの商業的な勝利だな
ま、今となっては汚くてもコンパイラ使えばええし

結局64bitで汎用レジスタ増やしたり
デコーダが電力食うとかって問題になってるよな
組み込みではx86はさほどメジャーじゃないし

259 :デフォルトの名無しさん:2010/04/06(火) 00:47:26
もうすぐメジャーになるけどな。

260 :デフォルトの名無しさん:2010/04/06(火) 00:49:25
残念ながらならねえよ

261 :デフォルトの名無しさん:2010/04/06(火) 00:50:53
特に80286+OS/2は「CPUの速度を1/3にする素晴らしいOSです」
と揶揄されたぐらいだからな

262 :デフォルトの名無しさん:2010/04/06(火) 00:51:04
RISC的方向性はPentium4とPOWER5で、いったんPC用途での限界を露呈してただろ
まあマルチスレッディングが一般的になってから登場した
Atom以降のSMT復権でだいぶいい扱いを受けるようになってきたが

263 :デフォルトの名無しさん:2010/04/06(火) 00:51:39
386以前のx86はゴミだからな

264 :デフォルトの名無しさん:2010/04/06(火) 00:53:38
>>262
そりゃ開発費が桁違いだからな
IntelとMicrosoftがx86にかけた金と労力をRISCに注いで
いたらもっといいCPUが出来てたろう


265 :デフォルトの名無しさん:2010/04/06(火) 00:59:14
いかにも素人的な発想だなw

266 :デフォルトの名無しさん:2010/04/06(火) 00:59:48
>>264
POWERもダメでAppleがキレちゃったじゃん
結局クロック上昇が物性的限界を迎えたところで、
同じクロック頻度でいかに多くの演算をするかという方向になったんで、
RISCのほうからx86的な方向に吸い寄せられているというかなんというか。

267 :デフォルトの名無しさん:2010/04/06(火) 01:00:07
RISC真理教

268 :デフォルトの名無しさん:2010/04/06(火) 01:00:53
ここまで新言語の話題なし

269 :デフォルトの名無しさん:2010/04/06(火) 01:04:05
並列実行が重要ということで、Goで良いんじゃないか

270 :デフォルトの名無しさん:2010/04/06(火) 01:04:26
>>265
んじゃプロのご意見どうぞ

俺もアーキテクトかじってたが
今全く新規にデザインし直すなら
結局68k的なRISC+CISCにDSP的命令付加になると思うぞ
x86はないない


271 :デフォルトの名無しさん:2010/04/06(火) 01:10:33
goはいいね。でもGCがネックだな

272 :デフォルトの名無しさん:2010/04/06(火) 01:13:13
>>270
モトローラに就職すればいいじゃんwww

273 :デフォルトの名無しさん:2010/04/06(火) 01:14:13
>>270
アーキテクトをかじるなよw

274 :デフォルトの名無しさん:2010/04/06(火) 01:16:02
>>270
>んじゃプロのご意見どうぞ

互換性を保ちながら内部アーキテクチャの革新で性能を大幅に向上する。

275 :デフォルトの名無しさん:2010/04/06(火) 01:24:36
>>274
結局内部はRISCプロセッサ風味だわな
ま、あの命令ベースでこんだけ速度出したのは驚異的だがな

>>272
別にモトローラがいいつーこともいわんがw
フロントのバス帯域減らすのと時間のかかる演算のために
CISC風味なマクロ命令+DSP命令なRISCが今のとこ理想的じゃね

276 :デフォルトの名無しさん:2010/04/06(火) 01:25:16
GoってCもどきなんでしょ?

277 :デフォルトの名無しさん:2010/04/06(火) 01:27:28
>>275
>CISC風味なマクロ命令+DSP命令なRISCが今のとこ理想的じゃね

つまり、IAってことだな。

278 :デフォルトの名無しさん:2010/04/06(火) 01:30:11
このスレは病院に居た方が良い奴が多すぎるw

279 :デフォルトの名無しさん:2010/04/06(火) 01:31:53
>>277
商業的には互換性がないとあかんけどなw

メーカ内部でしか使わないような
変なCPUとか見てるといい加減頭痛くなる

>>276
ざっぱに(C+Python)/2って感じかね
C++じゃないとこがミソと思う

280 :デフォルトの名無しさん:2010/04/06(火) 01:35:55
機械語見て頭痛くなる奴は技術者に向いてないわ

281 :デフォルトの名無しさん:2010/04/06(火) 01:37:29
こういう議論をすると、技術的にもアーキテクチャ的にも結局x86が一番優れているという結論に落ち着いてしまうんだよな。

282 :デフォルトの名無しさん:2010/04/06(火) 01:44:58
>>281
ま、半導体や回路設計の技術とx86とは一緒にはできんが
商業的、現物ベースでいうと、
特にここ最近のx86は優れていると言わざるをえんわな
実際サーバとかもx86ばっかだしな
あれでアセンブラ書きたいかという話とは別にして。

283 :デフォルトの名無しさん:2010/04/06(火) 01:45:27
マーケティングが優秀なだけではなく、物理・アーキテクチャの両面でもIntelは優れている。
ある面でIntelに勝るアーキテクチャを開発することはできても、結局トータルではIntelアーキテクチャにはかなわない。

printfより高速な文字列表示関数を作りました!って自慢する中学生みたいなもの。
そりゃ、文字列定数を表示するだけなら速くなるでしょって話。

284 :デフォルトの名無しさん:2010/04/06(火) 01:48:17
RISCでアセンブラ書きたいとか病院行けよ。あんなの絶対に書きたくない。
人間が書くなら、どう考えてもx86の方がいい。

285 :デフォルトの名無しさん:2010/04/06(火) 01:53:16
>>284
CPUによるな。
確かにRISCの3オペランド系はつらい

286 :デフォルトの名無しさん:2010/04/06(火) 02:05:51
RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
その点x86は人に優しいアーキテクチャ/コードセット。だからハンドアセンブルだってできる。

287 :デフォルトの名無しさん:2010/04/06(火) 02:13:47
ハンドアセンブルするならRISCのが楽だぞw
てかアセンブラ、ディスアセンブラ作るのが超楽
直交性が高いから理不尽さはない
ま、直値入れるだけで2命令とか面倒ではあるが。

で、このスレ的にはC最強で結論出てるのか?

288 :デフォルトの名無しさん:2010/04/06(火) 05:03:09
>>287
お前はCを超える低級言語があると考えているのか?

289 :デフォルトの名無しさん:2010/04/06(火) 05:06:22
超えるって具体的にどういうことだろね

290 :デフォルトの名無しさん:2010/04/06(火) 06:16:06
みんなプライドが高いだけの低脳

291 :デフォルトの名無しさん:2010/04/06(火) 07:26:40
>てかアセンブラ、ディスアセンブラ作るのが超楽
>ま、直値入れるだけで2命令とか面倒ではあるが。
まさに
>RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
ということを説明しているようにしか見えないが・・・

292 :デフォルトの名無しさん:2010/04/06(火) 07:45:18
>>286
x86が人に優しいって・・・68kのアセンブラ知らんのか?

293 :デフォルトの名無しさん:2010/04/06(火) 07:57:12
知ってる。

294 :デフォルトの名無しさん:2010/04/06(火) 07:59:28
しかし、68kは真っ向勝負でx86に負けた。

295 :デフォルトの名無しさん:2010/04/06(火) 08:16:58
Cの不満な点は?(低級言語の範囲で)

296 :デフォルトの名無しさん:2010/04/06(火) 08:33:07
Cは真っ向勝負しなかった。

297 :デフォルトの名無しさん:2010/04/06(火) 08:39:49
Cは別に何かの言語と対抗しようとして作られた言語じゃないから
真っ向勝負など必要なかった

298 :デフォルトの名無しさん:2010/04/06(火) 09:26:29
インテルはCPUに社運を賭けたから。
モトローラはメモリ売って儲けてた。

299 :デフォルトの名無しさん:2010/04/06(火) 10:22:42
Cは実用的だったし
Unixという実例もあったし
それらに関わった人間はリスペクトされてた
主流になるべくしてなった感じじゃないか

300 :デフォルトの名無しさん:2010/04/06(火) 11:47:23
Cの問題点はプロトタイプの導入でほぼ解決された。

301 :デフォルトの名無しさん:2010/04/06(火) 11:55:58
>>41

>>39は最適化の話なんてしてないけど


302 :デフォルトの名無しさん:2010/04/06(火) 12:16:23
>>300
俺はC大好きなんだが
宣言を二回書かないといけないのは欠点と言えると思うがね
あんな自動で出来ることは本来処理系でやっちまう方がいい話だな

303 :デフォルトの名無しさん:2010/04/06(火) 12:17:59
正確には、ほとんど同じ物を、宣言と定義の頭の部分と2箇所に、だな。

304 :デフォルトの名無しさん:2010/04/06(火) 13:01:05
Cはそれが開発された当時のしょぼいハードウェアに合わせて作られている。
いまどきのハードウェアの進歩に全く付いていけていない。
インラインアセンブラとかもう逃げの技術を駆使して何とか延命しているだけ
もう終わった存在だ。

305 :デフォルトの名無しさん:2010/04/06(火) 13:08:25
釣られてやるよ
インラインアセンブラは逃げじゃねえ
普通の言語で書けないこと
特殊なレジスタへのアクセスとかCPU固有の演算機能とかのために使う
Cレベルで書ける言語は他にはないな

そもそもハードウェアの進化ってなんだよ
単なるスピードアップか?w

306 :デフォルトの名無しさん:2010/04/06(火) 13:28:52
Cは、プロトタイプ宣言のおかげで、コンパイルとリンクを分離できている。

307 :デフォルトの名無しさん:2010/04/06(火) 13:49:28
いまどきの言語ならそのへんなんとかして自動的に面倒見てほしいよな。

308 :デフォルトの名無しさん:2010/04/06(火) 14:00:17
>>307
原理的に無理

309 :デフォルトの名無しさん:2010/04/06(火) 14:01:53
>>304
Cがよくわからないので無くなってくれればいいんですね、わかります

310 :デフォルトの名無しさん:2010/04/06(火) 14:22:11
おまえらってプログラマが多いの?
おれは単に手段として使えればよいだけなんで
使いやすくて高速に計算さえできれば細かいことは気にしないんだが

311 :デフォルトの名無しさん:2010/04/06(火) 15:08:39
FORTRANでも使っときな
Cはポインタがあるから最適化しにくいしな

312 :デフォルトの名無しさん:2010/04/06(火) 15:32:16
インラインアセンブラが書けて配列演算や純関数概念を持っているDが最強だな

313 :デフォルトの名無しさん:2010/04/06(火) 15:32:44
Dだと?死んどけよ( ´,_ゝ`)プッ

314 :デフォルトの名無しさん:2010/04/06(火) 15:34:55
D はなんで普及しないの

315 :デフォルトの名無しさん:2010/04/06(火) 15:41:10
Dなんて誰も知らないからだろ

316 :デフォルトの名無しさん:2010/04/06(火) 18:06:36
リスクを負ってまで移行する利点が全く無いから

317 :デフォルトの名無しさん:2010/04/06(火) 18:57:23
Cが英語ならDはクリンゴン語並に人口少ないだろ
しょゆこと

318 :デフォルトの名無しさん:2010/04/06(火) 19:05:55
phpは中国語って感じか
BASICはヒンディー

319 :デフォルトの名無しさん:2010/04/06(火) 19:15:13
>>308
やろうと思えば普通にコンパイル時に集めた定義情報を吐き出して
インクルードするだけで実現できるし
そんな難しくもない話だと思うがね
protoizeとかでも省力化はできるし

320 :デフォルトの名無しさん:2010/04/06(火) 19:33:19
依存関係が循環してると個別にコンパイルできなくなるから効率悪い。

321 :デフォルトの名無しさん:2010/04/06(火) 19:40:38
>>319
よく考えてみ。コンパイル時に吐きだされるのでは遅いんだよ。

322 :デフォルトの名無しさん:2010/04/06(火) 20:23:01
>>314
仕様がころころ変わるから

323 :デフォルトの名無しさん:2010/04/06(火) 20:54:46
Dは名前が厨だから使うのが恥ずかしい

それで多くのユーザーを逃してる

324 :デフォルトの名無しさん:2010/04/06(火) 21:25:02
えっ?

325 :デフォルトの名無しさん:2010/04/06(火) 22:07:15
Cのいやなところ
・マクロがクソ
・駆動レコードが弄れない(サブルーチン必須)
・評価しない引数が使えない
辺りかね。

326 :デフォルトの名無しさん:2010/04/06(火) 22:09:09
・宣言と定義が別
・ヘッダーファイル

327 :デフォルトの名無しさん:2010/04/07(水) 00:51:54
shared_ptrの構文糖が欲しいな

328 :デフォルトの名無しさん:2010/04/07(水) 00:53:47
>>321
よく考えてみ。コンパイル時でいいんよ
循環は問題だが、
単純に多パスにするか
リンク時に遅延評価で解決できる

329 :デフォルトの名無しさん:2010/04/07(水) 01:02:55
要するに、ヘッダファイルの呼び方を変えて
遅延リンクなんたらファイルにすればいいんだろ

330 :デフォルトの名無しさん:2010/04/07(水) 01:07:45
人が書く必要ないなら書かない方がいいって話

331 :デフォルトの名無しさん:2010/04/07(水) 01:09:22
ヘッダーファイルなんて実装を隠したいときだけ生成するようにすればいいんだよ

内部開発でもいちいち作らせるのがおかしい

プロトタイプを自動生成するくらい大した処理じゃないのだからコンパイラがやれって話

新言語では基本は定義だけですべて実装できるようにすべきだよ

ヘッダーファイルは不要

332 :デフォルトの名無しさん:2010/04/07(水) 01:22:34
インクルードスパゲティ作ったり
不要なのがすぐ残るしな
あとマクロ欲しいって言ってるが
一歩間違うと黒魔術になるから不要かな
cとgoの中間が俺には理想に近いな
個人的には名前付きパラメータが欲しいが

333 :デフォルトの名無しさん:2010/04/07(水) 01:26:10
Lispぽいのがいい。

334 :デフォルトの名無しさん:2010/04/07(水) 01:39:36
あんなの下手な奴に使わせたらgotoよりひでえ
そもそも理解できない奴、たぶん多数。

335 :デフォルトの名無しさん:2010/04/07(水) 01:45:27
うまくなればいい。要は慣れ。

336 :デフォルトの名無しさん:2010/04/07(水) 01:57:45
低能に合わせるためにマクロ不要なんて言うなよ。
単に低能にはマクロ使わせなきゃ良いだけだろ。

337 :デフォルトの名無しさん:2010/04/07(水) 02:07:57
名前付きパラメータみたいな飾りはどうでもいいよ。
フロー制御どうするかとかの方が重要じゃない?

338 :デフォルトの名無しさん:2010/04/07(水) 02:41:18
ご立派な設計を語る人間が100人いても、何一つ作れないことの証明

339 :デフォルトの名無しさん:2010/04/07(水) 03:11:16
優れたシステムは優れた個人と
優秀な少人数チームが核を作るからな
ここは雑談の場じゃないのw


340 :デフォルトの名無しさん:2010/04/07(水) 03:14:10
>>337
低レベル言語にふさわしい制御なんて
ifと繰り返しとその変型しかない、じゃん
オブジェクト指向チックなのはoh高い

341 :デフォルトの名無しさん:2010/04/07(水) 03:50:35
作る気の無い奴が1億人集まろうと作られる訳が無いだろ
次スレ立てるなら 【超高速】C/C++に代わる低級言語を妄想したい に変えておけよ

342 :デフォルトの名無しさん:2010/04/07(水) 03:55:49
母国語の1位が中国語だから中国語でかける言語がいいんじゃね?

343 :デフォルトの名無しさん:2010/04/07(水) 04:31:30
Cでヘッダファイル不要何て言っているやつは、手動でコンパイルとリンクをやったことがないな。

344 :デフォルトの名無しさん:2010/04/07(水) 05:39:07
>>343
でっていうwwww
そんなに手動でコンパイルがやりたいならどうぞご勝手にwwwww

345 :デフォルトの名無しさん:2010/04/07(水) 05:42:46
コンパイルとリンクの区別もついていないやつらばっかだから

346 :デフォルトの名無しさん:2010/04/07(水) 06:02:20
手動でアセンブルって話しは分かるが
手動でコンパイルって何のこっちゃ。
どーやるの?


347 :デフォルトの名無しさん:2010/04/07(水) 06:12:34
こんな部下いたら発狂するわ

348 :デフォルトの名無しさん:2010/04/07(水) 08:18:47
コンパイルとリンクは統合されてくのが処理系の動向。

最適化とかリンク時にも考えられるからね。

349 :デフォルトの名無しさん:2010/04/07(水) 13:13:33
処理系の動向とか以前に、アセンブルと、コンパイルと、リンクの動作の違いをわかっていない人間がいるって話じゃないの?


350 :デフォルトの名無しさん:2010/04/07(水) 13:16:13
何かの話について、実際の内容の観察や考察よりも、
勝ち負けとかあほみたいな視点で話をする奴がちょいちょい紛れ込んでるスレ

351 :デフォルトの名無しさん:2010/04/07(水) 13:17:40
負け組は黙ってろ

352 :デフォルトの名無しさん:2010/04/07(水) 14:01:40
つか、処理系作ったことあるヤツ少なそうだな
妄想はエロいのだけにしとけよ
ヘッダに関しては時代遅れとは思うがな

353 :デフォルトの名無しさん:2010/04/07(水) 15:39:12
ハンドコンパイルwww

354 :デフォルトの名無しさん:2010/04/07(水) 16:18:16
ハンドコンパイルって、言い方変えたら人間コンパイラだよなw
もはや超人だ

355 :デフォルトの名無しさん:2010/04/07(水) 17:05:20
ん?CがないようなCPU向けにアルゴリズム記述とデバッグはCでやって
手でアセンブラになおすなんてのはあるんじゃね

356 :デフォルトの名無しさん:2010/04/07(水) 17:39:44
なにそのシチュエーション

357 :デフォルトの名無しさん:2010/04/07(水) 18:01:59
ごくふつうのブートストラップ

358 :デフォルトの名無しさん:2010/04/07(水) 19:25:23
単にコマンドラインからコンパイラやリンカ直たたきで
コンパイルやリンクをするということなんだろうけど
ハンドコンパイルと言われると
直でオブジェクトファイルまで変換するように思えるなw

359 :デフォルトの名無しさん:2010/04/07(水) 19:36:15
IDEしか使ったことないやつらが騒いでるな。

360 :デフォルトの名無しさん:2010/04/07(水) 19:43:33
>>355
こういうのがハンドコンパイル
4bit CPUとか変なDSPとか、未だにCがないCPUもあるんさ

コンパイラ手で叩くのはハンドコンパイルとはいわんがなw

361 :デフォルトの名無しさん:2010/04/07(水) 20:20:28
なになに?
>>343 はまるでRPMしか扱った事ないTaco がconfigureを初めて
叩いた時のように「手動でコンパイル」とか言ってたの?


362 :デフォルトの名無しさん:2010/04/07(水) 20:49:27
cpuの1コアあたりの処理スピードが今より10万倍になれば
難しいコードを書く必要はないんだが

363 :デフォルトの名無しさん:2010/04/07(水) 22:00:42
よってjavascriptで十分

364 :デフォルトの名無しさん:2010/04/08(木) 00:13:51
よって大蛇Pythonたんが火を吹く

365 :デフォルトの名無しさん:2010/04/08(木) 00:59:48
javascriptのネイティブコンパイラ欲しい

366 :デフォルトの名無しさん:2010/04/08(木) 01:03:01
変数の型が決まってない言語イラネ

367 :デフォルトの名無しさん:2010/04/08(木) 01:47:27
とりあえずネイティブなレベルで並列処理が欲しいな

368 :デフォルトの名無しさん:2010/04/08(木) 01:51:47
Cに代わる低級言語のスレでJS,Pythonはアレだなw
>>362
10万倍といえばおおよそで8080/z80レベルの8bit CPUと最新のCPU位の差だな
実に興味深い


369 :デフォルトの名無しさん:2010/04/08(木) 01:56:05
どういう点が興味深い?

370 :デフォルトの名無しさん:2010/04/08(木) 02:17:42
当時はCですら重くて、速度を求めるならアセンブラだった
PCでは取っつきやすいOld BASICの隆盛期だった
今は組み込みのCPUですらどん底を除くと数MIPSでCが主流
PCクラスでは当時のスパコンを超えCは既に最低レベルな階層の言語で
実行時にマシンコード生成したり、動的言語が多く使われてる

使われる用途も規模も当時とは比べものにならないくらい大きく広くなっているが
当時の知識や技術は形は変われども今でも有効だし本質は変わってない
使われるプログラミング言語も、8bit CPU以前に設計されたものの延長がベースだ

今のまま10万倍高速で大容量なコンピュータが主流になる頃
もちろんいろんな変化があるだろうが
やはり本質的には今と変わらないのじゃないか

等々と考えて、興味深い


371 :デフォルトの名無しさん:2010/04/08(木) 02:37:20
CPU速度が十万倍になった今でも変わらない愛の形を探してるって事だろ

372 :デフォルトの名無しさん:2010/04/08(木) 02:39:15
二十年後にはみんなUMLを進化させたような言語をいじってて
「速度を求めるならJAVA」とか言われるようになるのかね

373 :デフォルトの名無しさん:2010/04/08(木) 02:52:18
伝説のプログラミング言語Cとか呼ばれるようになっているかもな


374 :デフォルトの名無しさん:2010/04/08(木) 02:56:41
でもその頃になってもいまの話題と技術名を置き換えただけで、
おなじような話題で貶しあいループしてるだろうことだけは断言できる。
やっぱり人間の方が進歩しないとね。

375 :デフォルトの名無しさん:2010/04/08(木) 03:57:30
>>372
UMLよりC言語の方が長生きすると思うぞ


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

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

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

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

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

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

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

377 :デフォルトの名無しさん:2010/04/08(木) 05:07:30
最近Cを勉強し始めてどれが関数名とか変数名とか型名(構造体)とか、
流し読みだと全然わからないんですが、これどうにかなったりしますか?

378 :デフォルトの名無しさん:2010/04/08(木) 05:09:10
激しく書く場所を間違ったけど、そのままにしときます。

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

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

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

380 :デフォルトの名無しさん:2010/04/08(木) 05:33:44
>>377
慣習でカバー
俺はだいたい関数は動詞入り、変数は名詞形、型は_t


381 :デフォルトの名無しさん:2010/04/08(木) 07:14:40
Dでいいんじゃないかな

382 :デフォルトの名無しさん:2010/04/08(木) 07:55:21
>>381
何がいいのかと、その理由を。

383 :デフォルトの名無しさん:2010/04/08(木) 08:33:21
定期的にD厨わくけどなんなの

384 :デフォルトの名無しさん:2010/04/08(木) 14:09:08
Dがダメな理由なんてないからな。
言語統計を見れば分かると思うけど、優秀な技術者はDを洗濯する。

385 :デフォルトの名無しさん:2010/04/08(木) 14:23:58
面白がってはいるし使い捨ての道具くらいは作るが、
事実上実用にはなってないというのが現状だろ

386 :デフォルトの名無しさん:2010/04/08(木) 14:39:10
 

387 :デフォルトの名無しさん:2010/04/08(木) 14:39:38
理由なき現実を受け入れるには、どうすればいいんだ

388 :デフォルトの名無しさん:2010/04/08(木) 14:43:12
言語仕様がきれいなだけで、あとは他の言語と同じでは、広く使われることはないということのひとつの証明。

389 :デフォルトの名無しさん:2010/04/08(木) 14:59:59
とはいえ一度javaを使うともうC++は使いたくないのが事実

390 :デフォルトの名無しさん:2010/04/08(木) 15:25:05
パーソナルリアリティをレベルアップすればC++も使える

391 :デフォルトの名無しさん:2010/04/08(木) 16:27:15
D言語


392 :デフォルトの名無しさん:2010/04/08(木) 17:12:17
>>389
JavaとC++では、特徴が全然違う

393 :デフォルトの名無しさん:2010/04/08(木) 17:15:47
馬鹿でも使えるJava vs 馬鹿は使えないC++

394 :デフォルトの名無しさん:2010/04/08(木) 17:24:15
馬鹿でも使えるJava vs 自称天才が脆弱性を入れ込むC++

395 :デフォルトの名無しさん:2010/04/08(木) 17:39:24
>>392
>>389 は多分初心者なんだと思うぜ。

大方、プログラミング覚えたくて人に勧められるままC++始めて、しかし理解出来ずにそのまま挫折して、
ゆとり丸だしで面倒になって逃げ出したんだが何かのタイミングでJavaを知り、俺様解釈でしか知らないけどOOPはかっこいいとか思っちゃって

それできっと「もう戻りたくない」とか堂々と言っちゃってるんだと思う

すっごいバカ。すっごい勘違い。すっごい勢いでハナ垂らした大学生


396 :デフォルトの名無しさん:2010/04/08(木) 17:42:11
ちなみにC使いな俺はC++もJavaもさっぱりわからん

397 :デフォルトの名無しさん:2010/04/08(木) 17:44:22
>>395
Javaですむことを、C++でやりたくはないというのは、初心者、上級者共通だと思うけどね。

398 :デフォルトの名無しさん:2010/04/08(木) 18:11:21
395 :デフォルトの名無しさん:2010/04/08(木) 17:39:24
>>392
>>389 は多分初心者なんだと思うぜ。

大方、プログラミング覚えたくて人に勧められるままC++始めて、しかし理解出来ずにそのまま挫折して、
ゆとり丸だしで面倒になって逃げ出したんだが何かのタイミングでJavaを知り、俺様解釈でしか知らないけどOOPはかっこいいとか思っちゃって

それできっと「もう戻りたくない」とか堂々と言っちゃってるんだと思う

すっごいバカ。すっごい勘違い。すっごい勢いでハナ垂らした大学生

399 :デフォルトの名無しさん:2010/04/08(木) 18:24:38
398 名前:デフォルトの名無しさん[] 投稿日:2010/04/08(木) 18:11:21


400 :デフォルトの名無しさん:2010/04/08(木) 19:01:42
まさに必死

401 :デフォルトの名無しさん:2010/04/08(木) 21:17:43
必死になってハナ拭けばいいのになw

402 :デフォルトの名無しさん:2010/04/08(木) 21:50:56
C++ですむことを、わざわざJavaなんかでやりたくはないわ。

403 :デフォルトの名無しさん:2010/04/08(木) 21:55:09
>>393
馬鹿でも使える方が工学的には優れている。

但し、Javaはできることが限られているから、イマイチな言語。

404 :デフォルトの名無しさん:2010/04/08(木) 22:02:44
いまどき、何でも出来る言語なんて低レベルを扱うのでなければ害悪。

405 :デフォルトの名無しさん:2010/04/08(木) 22:06:55
ということで、低レベルを扱う新言語の話をしようか

406 :デフォルトの名無しさん:2010/04/08(木) 22:09:42
上手い事話戻したなww

407 :デフォルトの名無しさん:2010/04/08(木) 22:10:23
やっぱりe言語

408 :デフォルトの名無しさん:2010/04/08(木) 22:11:42
結論
新言語を作る必要は全く認められない。C++で十分である。

409 :デフォルトの名無しさん:2010/04/08(木) 22:14:11
C++のどの機能が良いのか具体的に述べるといいよ。

410 :デフォルトの名無しさん:2010/04/08(木) 22:16:53
C++は、言語体系が崩壊しているから、近年、
C++に取って代わる言語はたくさん登場している。
けれども、Cに代わるものはほとんどない。

411 :デフォルトの名無しさん:2010/04/08(木) 22:49:46
C系言語の修飾の判り辛さはどれも50歩100歩

412 :デフォルトの名無しさん:2010/04/08(木) 22:53:12
新言語では、その辺、簡潔に、かつ直感的にプログラマーが勘違いしないようにしたいな。

413 :デフォルトの名無しさん:2010/04/08(木) 23:36:55
アスタリスクでポインタとかなんとかなりませんこと?

414 :デフォルトの名無しさん:2010/04/08(木) 23:43:52
といいますと?

415 :デフォルトの名無しさん:2010/04/08(木) 23:46:54
それじゃ、こんなのにしちゃいましょう
doubleicariable;

416 :デフォルトの名無しさん:2010/04/08(木) 23:48:07
プリミティブに扱おうとするからちょっと変になる訳で構造体レベルまで降格。
pointer char p_char; pointer p_char p; // char *p;
typedef pointer pointer p_char pp_char; pp_char pp; // char **pp;

417 :デフォルトの名無しさん:2010/04/08(木) 23:53:47
char **pp;
だと、
**pp の型が char で
*p の型が char* ってのは
かなり直感的なんだよな。

char → **pp
char* → *pp
char** → pp

418 :デフォルトの名無しさん:2010/04/09(金) 00:12:46
ポインタ脳に新しいものは作れない

419 :デフォルトの名無しさん:2010/04/09(金) 00:32:49
char* p, q:

きもいよーきもいよー

420 :デフォルトの名無しさん:2010/04/09(金) 00:33:49
ノイマン型アーキテクチャの上でJavaVMを書きましょうという話でポインタは避けては通れんだろ。

421 :デフォルトの名無しさん:2010/04/09(金) 00:34:50
全て無いところから発明しろ
新たに

422 :デフォルトの名無しさん:2010/04/09(金) 00:35:36
JavaVMなんて書かなくていいよ

423 :デフォルトの名無しさん:2010/04/09(金) 00:41:35
いやJavaそのものがなくていいよもう

424 :デフォルトの名無しさん:2010/04/09(金) 00:48:42
>>419
お前は(2* 3+4)が14にならないと文句を言うのか?

425 :デフォルトの名無しさん:2010/04/09(金) 00:49:05
>>421
言語自体は全く新しく一から作るが、これまでの研究成果を生かさないのはもったいない。

良いものは取り入れる。

426 :デフォルトの名無しさん:2010/04/09(金) 00:50:06
それが日本人の悪い癖だ

ハードウェアの世界ではそれで成功したがソフトウェアでは通用しない

427 :デフォルトの名無しさん:2010/04/09(金) 00:56:15
char* ptr = NULLPO;

428 :デフォルトの名無しさん:2010/04/09(金) 01:02:52
char* pは間違いやすいからダメだな
char *pが文法的に理にかなってる


429 :デフォルトの名無しさん:2010/04/09(金) 01:03:00
PerlとC#は、良いものを取り入れると伸びるタイプ

430 :デフォルトの名無しさん:2010/04/09(金) 01:13:55
> お前は(2* 3+4)が14にならないと文句を言うのか?
(2* 3+4)

; in: LAMBDA NIL
; (2* |3+4|)
;
; caught STYLE-WARNING:
; undefined function: 2*
;
; caught WARNING:
; undefined variable: |3+4|
;
; compilation unit finished
; Undefined function:
; 2*
; Undefined variable:
; |3+4|
; caught 1 WARNING condition
; caught 1 STYLE-WARNING condition
; Evaluation aborted.


431 :デフォルトの名無しさん:2010/04/09(金) 01:23:25
>>429
ご冗談でしょう

つか低レベル言語の話でねえなw

432 :デフォルトの名無しさん:2010/04/09(金) 01:33:58
cgiがhtmlを吐くように、asmを吐くスクリプトを書け。

433 :デフォルトの名無しさん:2010/04/09(金) 01:40:37
別にスクリプトでコンパイラ書いたっていいんだぜ

434 :デフォルトの名無しさん:2010/04/09(金) 02:06:00
>>424
「char* p, q」はアスタリスクがcharと合体しつつpとスペースで区切られているのに
pにのみ効果を及ぼしてるのがきももも

435 :デフォルトの名無しさん:2010/04/09(金) 02:13:30
>>433
コンパイラ書かなければ、文法とパーサで力尽きる心配が無くなるだろ

436 :デフォルトの名無しさん:2010/04/09(金) 02:29:37
>>435
432か?asmを吐くスクリプト=コンパイラだろ

437 :デフォルトの名無しさん:2010/04/09(金) 02:50:22
>>436
そうだよ
その定義に従うと、文法やパーサを作るのは必須ではない

438 :デフォルトの名無しさん:2010/04/09(金) 03:30:38
>>437
意味わからんな。
文法はありもの言語でもいいがパーサがないとコンパイラは出来ないだろ。。。


439 :デフォルトの名無しさん:2010/04/09(金) 03:33:48
>>438
Forthなんかは、パーサーないも同然だけどな。

440 :デフォルトの名無しさん:2010/04/09(金) 04:13:37
ウダウダ言ってないでasm直接書けよ

441 :デフォルトの名無しさん:2010/04/09(金) 13:30:40
obj のテキスト表記を変換するだけってのはどうだろう。
コード部分は hex で直書き。
作るのも簡単だし高速で簡潔だ。
使う側は少し大変かも知れないけど

442 :デフォルトの名無しさん:2010/04/09(金) 14:16:51
意味わからん。それアセンブラじゃね

443 :デフォルトの名無しさん:2010/04/09(金) 15:26:43
アセンブラじゃなくてbinutilsだな

444 :デフォルトの名無しさん:2010/04/09(金) 21:34:28
テキストで書かれたコードを、一旦アセンブラコードに変換して実行させるっていうのはどうだ?

445 :デフォルトの名無しさん:2010/04/09(金) 21:58:59
sレコードで書けばいいやん

446 :デフォルトの名無しさん:2010/04/09(金) 22:22:23
>>444
それをするとどういうメリットが?
これまでのコンパイラでもアセンブラコードはけるけどそれとは違うの?

447 :デフォルトの名無しさん:2010/04/09(金) 22:50:41
アセンブラでは移植性がない件

448 :デフォルトの名無しさん:2010/04/09(金) 22:53:14
移植性より大切なものがあるだろう?

449 :デフォルトの名無しさん:2010/04/09(金) 23:06:27
ポインタは
Hoge* pHoge
Hoge *pHoge
どっちで書くか

アドレス型なのだと思えば前者
型自体はHogeなのだと考えれば後者

今でも悩む。

450 :デフォルトの名無しさん:2010/04/09(金) 23:11:19
>>449
C#なら前者、Cなら後者。

451 :デフォルトの名無しさん:2010/04/09(金) 23:14:18
C#でポインタとか使うなよ
劣化javaをさらに劣化させてどうする

452 :デフォルトの名無しさん:2010/04/09(金) 23:14:46
C#が劣化Javaだと?聞き捨てならんな

453 :デフォルトの名無しさん:2010/04/09(金) 23:15:36
a

454 :デフォルトの名無しさん:2010/04/09(金) 23:16:49
>>447
じゃあ、アセンブラだけど、実装されていない命令を既存の命令に置き換えてアセンブルする
弱抽象化アセンブラとかどうよ。

455 :デフォルトの名無しさん:2010/04/09(金) 23:20:54
>>454
マシン語がCPU間で似ていると思ったら大間違い。

456 :デフォルトの名無しさん:2010/04/09(金) 23:22:09
>>455
マシン語じゃなくて、アセンブリ言語に変換するんだよ

457 :デフォルトの名無しさん:2010/04/09(金) 23:35:12
何をアセンブリ言語に変換するんだよ。ソースコードをなら、従来のコンパイラが普通にできることだろ。

458 :デフォルトの名無しさん:2010/04/09(金) 23:38:34
WindowsやLinuxなどがC/C++から乗り換えてくれるような言語が登場する可能性はあるの?

459 :デフォルトの名無しさん:2010/04/09(金) 23:41:25
むしろ、新言語で作られたOSでWindowsやLinuxが置き換えられる。

460 :デフォルトの名無しさん:2010/04/09(金) 23:42:40
それはない

461 :デフォルトの名無しさん:2010/04/09(金) 23:42:55
>>454
昔々Base-80というアセンブラがあってな

462 :デフォルトの名無しさん:2010/04/09(金) 23:48:21
>>449
後者は間違いの元だからダメだろ
やりたきゃtypedef

後、アセンブラでまとまった
コード書いたことないヤツがいるな

463 :デフォルトの名無しさん:2010/04/09(金) 23:57:08
「〜な奴がいるな」はもういいよ。お前、凄いから。凄い凄い。

464 :デフォルトの名無しさん:2010/04/10(土) 00:00:57
なんか凄い奴がいるな

465 :デフォルトの名無しさん:2010/04/10(土) 00:02:46
>>450
>>462
どっちなんだよ

466 :デフォルトの名無しさん:2010/04/10(土) 00:04:17
>>465
Hoge* pHoge;

がおすすめ。1行に1宣言。コンマは使わない。

467 :デフォルトの名無しさん:2010/04/10(土) 00:08:47
>>466
その書き方がC++が流行り始めてから推奨されているが、あくまで型はHogeで*は定義する変数を修飾するものだから、pHogeにつける方が筋。
関数へのポインタとか書くときに型にくっつける書き方は破綻して一貫性がなくなる。

468 :デフォルトの名無しさん:2010/04/10(土) 00:11:30
そこまでは素人の考え

469 :デフォルトの名無しさん:2010/04/10(土) 00:12:56
玄人さんおねげーします

470 :デフォルトの名無しさん:2010/04/10(土) 00:14:28
Hoge * pHoge;


471 :デフォルトの名無しさん:2010/04/10(土) 00:18:45
ところで、C言語って完全にアセンブラを代替できるの?
アセンブラじゃないとかけないコードとかあったりしない?

472 :デフォルトの名無しさん:2010/04/10(土) 00:19:48
あるよ。

473 :デフォルトの名無しさん:2010/04/10(土) 00:22:55
Cだとアセンブラよりは短くならない。
あと、サブルーチンの構造前提になる。コルーチンとか継続渡しとか無理。


474 :デフォルトの名無しさん:2010/04/10(土) 00:24:20
>>449
Cでも型は Hoge* だろ。キャストの時を考えろ。
ただしHoge*型の変数(つまりポインタ)の宣言は、Hoge *pHoge という構文で行う。

475 :デフォルトの名無しさん:2010/04/10(土) 00:26:42
そして

Hoge* pA, pB;

で勘違いっていういつものアレが起こるわけです。

476 :デフォルトの名無しさん:2010/04/10(土) 00:27:42
アレって?

477 :デフォルトの名無しさん:2010/04/10(土) 00:30:15
機械語から全て書き直して新構造のコンピュータの方が良い

478 :デフォルトの名無しさん:2010/04/10(土) 00:30:28
ポインタ宣言時の*と、ポインタの型を示す*は似ているけど意味が違う記号と思え。
乗算の*とポインタ宣言時の*が一緒の意味でないのと同じことだ。

479 :デフォルトの名無しさん:2010/04/10(土) 00:32:10
何いってんだ馬鹿。

480 :デフォルトの名無しさん:2010/04/10(土) 00:32:11
>>475
pBはポインタでしょ?

481 :デフォルトの名無しさん:2010/04/10(土) 00:32:13
>>477
アホか
この不況にどの企業にそんな時間と金の余裕がある?

482 :デフォルトの名無しさん:2010/04/10(土) 00:33:25
>>478
じゃあ新言語は3つとも違う記号にしようぜ

483 :デフォルトの名無しさん:2010/04/10(土) 00:34:09
>>480
pBはインスタンスだよ

484 :デフォルトの名無しさん:2010/04/10(土) 00:36:05
これだけ自称できる連中が集ってるのに、ボインタ宣言すらてんでバラバラなあたりがCのヤバさ。

485 :デフォルトの名無しさん:2010/04/10(土) 00:36:29
char **pp;
は、
char → **pp であり、
char* → *pp であり、
char** → pp である。

実に直感的かつ合理的。

他の記号にするなんてとんでもない。

486 :デフォルトの名無しさん:2010/04/10(土) 00:37:42
>>481
第3のニューディールみたいな感じで雇用創出も出来る
ネイティブなレベルで並列命令作っておけば今後の進化にも対応できよう

487 :デフォルトの名無しさん:2010/04/10(土) 00:38:15
ためしに++にしてみようか

488 :デフォルトの名無しさん:2010/04/10(土) 00:38:46
>>485
2個以上のポインタを宣言すると全然成り立たないけど?

489 :デフォルトの名無しさん:2010/04/10(土) 00:38:47
>>478 なんだっけ、

>ポインタ宣言時の*

これって、 Hoge * の * は、「Hoge型のどこか」 って意味だったっけ?ポインタとして、Hoge型のどこかを差すから、*。
そして、

>ポインタの型を示す*

こっちは、 *hoge ホゲポインタ型として中身を・・・ うーん、なんか上手い表現ないか

490 :デフォルトの名無しさん:2010/04/10(土) 00:39:50
>>488
1行で2個以上ポインタを宣言するな。

491 :デフォルトの名無しさん:2010/04/10(土) 00:40:36
Cの*はコメントを除いても4通りぐらいの用法がある。そのうち3つがポインタ関連な。

492 :デフォルトの名無しさん:2010/04/10(土) 00:55:37
ポインタの宣言と、間接参照演算子を同じ記号にするのは合理的。

493 :デフォルトの名無しさん:2010/04/10(土) 01:00:23
それで関数宣言と配列宣言を混ぜたらあの読みにくい構文になるんだなこれが

494 :デフォルトの名無しさん:2010/04/10(土) 01:04:09
読みやすく書くと長くなるからな
C++なら、Pointer< Pointer<char> > pp;と書けるかもしれないが、書きたくない

495 :デフォルトの名無しさん:2010/04/10(土) 01:08:31
>>493
新言語に関数宣言と配列宣言があるとしたら、こうしよう↓

type [] ARRAYNAME;
[capture] (type inparams, ...) -> outtype FUNCNAME;

496 :デフォルトの名無しさん:2010/04/10(土) 01:09:47
>>494
ポインタをあまり多様する必要がないという前提なら、そういう構文もありだと思う。
今のC/C++でやられると鬱陶しいだけだが。

497 :デフォルトの名無しさん:2010/04/10(土) 01:15:17
>>495
それがまさしくC#なんだがな

498 :デフォルトの名無しさん:2010/04/10(土) 01:30:58
配列だけな。

499 :デフォルトの名無しさん:2010/04/10(土) 01:36:30
名前を後ろにすると、関数呼び出しを記述するときに先にパラメータを書かなければいけなくなるから、IDEが困りそう。
宣言と呼び出しは同じ形にしたいし。

なので、型を後ろにしよう。

ARRAYNAME : type [];
FUNCNAME : [capture] (type inparams, ...) -> outtype;

n : int;
a : int [];
f : [](param1 : int, param2 : int) -> int;

500 :デフォルトの名無しさん:2010/04/10(土) 01:38:45
気持ち悪いな
Ada崩れみたいだ

501 :デフォルトの名無しさん:2010/04/10(土) 01:40:35
慣れだ。

502 :デフォルトの名無しさん:2010/04/10(土) 01:45:49
じゃあ言語名、

Nareda に決定な。

503 :デフォルトの名無しさん:2010/04/10(土) 01:48:42
declare n, variable of int; // int n;
declare pt, variable of pointer to int; // int *n;
declare str, array of char with 10 elements; // char str[10];
declare func, function that takes param, variable of int, and returns variable of bool; // bool func(int param);

プログラミングも自然言語に近づければユーザーに優しいはず。

504 :デフォルトの名無しさん:2010/04/10(土) 01:48:45
intじゃなくてイントにしろよ
あとparamはパラムとか

505 :デフォルトの名無しさん:2010/04/10(土) 01:51:32
基本的な構文が長いのは人に優しくない。

506 :デフォルトの名無しさん:2010/04/10(土) 01:53:06
Function::ThatTakes<int>::AndReturns<bool>

507 :デフォルトの名無しさん:2010/04/10(土) 01:53:32
コロンやアローいらねぇだろ
fn_nm ag0 int,ag1 const int[2]={0,1},r_type int=(ag0/ag1[0])*ag1[1]{;r_type;}

508 :デフォルトの名無しさん:2010/04/10(土) 01:56:41
もっと機能の話はしないの?プリミティブとか制御とか駆動レコードとかスコープとか。
構文なんて後でいいんじゃね?


509 :デフォルトの名無しさん:2010/04/10(土) 01:59:52
ユーザーが文法をカスタマイズできるようにすればいいんじゃないのか?

define "declare" + token + ", variable of" + type
= type token;

みたいな感じで。

510 :デフォルトの名無しさん:2010/04/10(土) 02:01:13
低級言語の機能ならCで十分だろ

511 :デフォルトの名無しさん:2010/04/10(土) 02:06:26
そそ
詰まる所どうあがいてもCには勝てっこない

512 :デフォルトの名無しさん:2010/04/10(土) 02:09:59
仮想レジスタと仮想スタック定義出来て実機へ効率的に転写出来れば
MACHINE poor32;{A,B 32;C ADDR;F0,F1 ieee754;D OF;E UF;S0,S1 STACK}
uint32_t function(uint32_t _base,int32_t _offset){
using MECHNE poor32;
A=_base;B=_offset;A+=B;C=A;S0=C;A=S1;A*=S0;return A;}

513 :デフォルトの名無しさん:2010/04/10(土) 02:16:41
>仮想レジスタと仮想スタック定義出来て実機へ効率的に転写出来れば

とりあえずそれだ。 あと、メモリ空間の動的割り当てと開放の部分をすっきりしたい
日常的に使う部分だ。

間接アドレシングとか単純にやろうとすると、
ほぼまんま C/C++と同じ格好になるので、そこをなんとか

514 :デフォルトの名無しさん:2010/04/10(土) 02:23:06
ボインタのボインタのボインタって必要?
いやCなら出てくることがあるのはわかるけど
**までで良くない?

515 :デフォルトの名無しさん:2010/04/10(土) 02:36:00
>>514
ポインタのポインタを他の関数に送って変更してもらう時に必要
但しC++は**&と最後をリファレンスにすればよい

516 :デフォルトの名無しさん:2010/04/10(土) 02:41:56
test

517 :デフォルトの名無しさん:2010/04/10(土) 03:12:28
ネイティブ層とマネージ層を持つ言語とかどうかな
JNIを使ってたようなところを楽にかけるようになる
出力はC++とJavaのソースコード(C#.netもいいかも)

class Sample
--@Manage
--hello() : void {
----String msg = "hello world";
----log(msg);
--}
--@Native
--world() : int char[] {
----char* mozi = "hoge";
----int length = strlen(mozi);
----return length, mozi;
--}
}

518 :デフォルトの名無しさん:2010/04/10(土) 03:15:02
C++/CLIでいいじゃん

519 :デフォルトの名無しさん:2010/04/10(土) 03:24:36
リフレクションとかできないじゃん
だからレイヤーつくって複数の環境組み合わせようYO
見た目 C#(Silverlight)
サーバー Java
クリティカル部位 C++ D ASM


520 :デフォルトの名無しさん:2010/04/10(土) 03:28:10
C/C++は増築限界超え始めたし
類似言語はピタゴラスイッチだし

521 :デフォルトの名無しさん:2010/04/10(土) 03:28:24
C++/CLIはリフレクション出来るだろ

522 :デフォルトの名無しさん:2010/04/10(土) 03:29:09
JITコンパイラは最低限必須な

JavaVMとかもうやめてくれ
重くて使い物にならん

523 :デフォルトの名無しさん:2010/04/10(土) 04:12:17
そもそもスレタイの【超高速】が実現不可能なんだよ
単に新言語やコンパイラならバカでも作れるが
高度に最適化できるコンパイラなんて、それ専門のスペシャリストが
十人がかりでやっても何年かかるかわからない
つうかCより高速で使いやすかったら億で売れる
ここにいる烏合の衆でそんなもんできるかよw

524 :デフォルトの名無しさん:2010/04/10(土) 04:16:55
>>1なんか無視しろよ

新言語から既存言語のソース吐いて
MSやSunのツールにコンパイルさせればよし

525 :デフォルトの名無しさん:2010/04/10(土) 04:34:45
>>521
よくない。それでデバッガどうするのさ。
インテリセンスもきかないからCより明らかに不便でしょ。
新言語作る意味ないじゃない。

526 :デフォルトの名無しさん:2010/04/10(土) 04:36:18
訂正>>524にレスしたつもりだった

527 :デフォルトの名無しさん:2010/04/10(土) 05:18:28
デバッガやインテリセンスは言語仕様じゃないだろ

VisualStudioとかEclipseみたいなIDEを作るとかいう話は
あってもなくてもいい話だ

まずはAntで動くぐらいの目標で十分すぎる

528 :デフォルトの名無しさん:2010/04/10(土) 05:42:18
みんな俺様の好きな仕様が入ってなかったら納得しないんだから
出来上がるのはゴチャゴチャ詰めこんだウンコ仕様に決まってる
理想を語るのは結構だが真っ当なライブラリとデバッガは必須
だいたい2ch発祥でものになったのは2chブラウザくらいじゃね
MONA OSとか誰も使わないしw安直に考え過ぎ

529 :デフォルトの名無しさん:2010/04/10(土) 06:14:01
MONA OSはまさに立ちパーティション不明の失敗例だな

用途は鯖か組み込みかクライアントアプリか、
またそれらの中のカテゴリーは何か絞らないと実用的にはならんな

530 :デフォルトの名無しさん:2010/04/10(土) 07:26:16
このスレは

是が非でもC/C++を勉強したくない(理解できなくて挫折したから)
Java厨、C#厨が心の叫びを漏らすスレ


531 :デフォルトの名無しさん:2010/04/10(土) 07:39:19
IDEが無いとダメとかいう奴はC/C++を語る資格無し。
お前は誰かが作ったフレームワーク内で一生泳いでろ。


532 :デフォルトの名無しさん:2010/04/10(土) 07:48:15
いやc はともかくとしてC++ はvisual studio やeclipse 使い始めたらヘナチョコエディターなんかじゃ書いてらんない。

533 :デフォルトの名無しさん:2010/04/10(土) 07:51:44
まさにお前のことだよ

534 :デフォルトの名無しさん:2010/04/10(土) 07:55:59
C++ > C#, Java なんて言っているのは、コーディングばかりやってる底辺。

535 :デフォルトの名無しさん:2010/04/10(土) 07:58:46
>>534
説得力がまるでないよ、君

536 :デフォルトの名無しさん:2010/04/10(土) 08:14:35
ロジック書けよ

537 :デフォルトの名無しさん:2010/04/10(土) 08:15:08
多様な思想があるから
他の言語選択スレみたいに、宗教論争になってまうね

538 :デフォルトの名無しさん:2010/04/10(土) 08:36:07
低級言語(本来は低水準言語)の意味をわかって書いてる奴がどれだけいるのやら。
例えばセガサターンは(昔の話だが)、メモリが分散して配置されていた。
片方は速く、片方は遅かった。
これらを効率よく扱うためには、本来はアセンブラで書くべきだが、
さすがにそれは開発効率が悪いので、Cで書いていた。
速いほうと遅いほう、両方の先頭アドレスをポインタで保持していた。
二次元配列とかも、フレームだけ定義し、実体は使用時にアロケートしていた。
メモリがもったいないからな。
(二次元配列の動的確保、できるか?出来ないなら「Cわかります」とか言うなよ?)
こういうことが出来ないとOSとか組み込み機とかゲームとかの開発は無理。
C++でも、メモリをどれだけ食うか走らせないとわからないので無理。
IDEがないとダメ、なんて論外。


539 :デフォルトの名無しさん:2010/04/10(土) 08:44:33
やっぱIDEがないと駄目だな

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

541 :デフォルトの名無しさん:2010/04/10(土) 08:55:09
参照とポインタを一緒にしてる奴も後を絶たないね。
そんな奴が言語の設計とかw
参照は「必ず実体がある」点で、ポインタとはまったく違う。
ポインタは参照と違って、指し示すオブジェクトが1個だろうが、配列だろうが、
メモリが無い変なアドレスだろうが関知しない。
だから参照より危険だが、その代わり、I/Oアドレスでも何でもポイントできる。
デバイスドライバとか書くときは便利だよ。C#にこんなマネができるかね?

542 :デフォルトの名無しさん:2010/04/10(土) 08:56:14
>>541
unmanagedを知らないのか?

543 :デフォルトの名無しさん:2010/04/10(土) 08:56:32
やっぱC#が最強ってことか

544 :デフォルトの名無しさん:2010/04/10(土) 08:57:18
Marshalとかな
ポインタももちろんある

545 :デフォルトの名無しさん:2010/04/10(土) 08:58:01
Cより後から出来た言語はどこかでちゃっかりCの良い面だけを
取り入れているよな

546 :デフォルトの名無しさん:2010/04/10(土) 09:16:06
C++に置けるインラインアセンブラの様に、今後の高級言語に
インラインCを搭載するのはどうだろう。

547 :デフォルトの名無しさん:2010/04/10(土) 09:27:12
それなんとかして欲しいよ

x86-64のC++はインラインアセンブル禁止だとよ
どうやってSSEをチューニングしろと言うんだ?

548 :デフォルトの名無しさん:2010/04/10(土) 09:48:53
>>546
objective-cはそれに近い
ていうかあれでcを名乗るのやめてほしい


549 :デフォルトの名無しさん:2010/04/10(土) 10:38:34
よし、俺がインラインCで全てが書ける言語作るわ

550 :デフォルトの名無しさん:2010/04/10(土) 11:34:23
>>547
intrinsicだっけ?
もうあれでいいじゃん。
どうせパイプライン埋めようとしたってCPUごとにいろいろ違うんだし。

551 :デフォルトの名無しさん:2010/04/10(土) 12:02:32
>>510-511
プロジェクトX用に画面キャプチャしといた

552 :デフォルトの名無しさん:2010/04/10(土) 12:09:11
>>514
「まで」も何も、*は2個までとか個数を制限するのはおかしい。

ポインタ操作に「**」なんて演算子はなくて、単に「*」があるだけ。

553 :デフォルトの名無しさん:2010/04/10(土) 12:10:31
>>514
>>538

554 :デフォルトの名無しさん:2010/04/10(土) 12:14:14
>>520
確かに。
新言語は、ドミノ倒しくらいにシンプルにしたいな。

555 :デフォルトの名無しさん:2010/04/10(土) 12:20:48
gotoは必須

556 :デフォルトの名無しさん:2010/04/10(土) 12:24:44
>554
だったらForthだろ。あるいは類似のConcatenative言語か。
後置・命令主体の言語ならTMの動作原理に近くなるから低水準にはちょうど良いぜ。
まあ、操作対象をスタックじゃなくてテープにしたBFはやり過ぎだと思うけど。

557 :デフォルトの名無しさん:2010/04/10(土) 12:44:27
>>517の続きだけど外部のCやJavaソースとの連携性も重要だな

@Export("C++")
interface yahho {
--struct Value {
----char ch1, ch2;
--}
--void cs();
--void java();
--Value cpp();
}

class Sample implements yahho
--@Manage(".Net")
--cs() : void {
--}

--@Manage("JVM")
--java() : void {
--}

--@Native("C++")
--cpp() : char char {
----char ch1, ch2;
----asm {
------mov ch1, 'A'
------mov ch2, 'B'
----}
----return ch1, ch2;
--}
}

558 :デフォルトの名無しさん:2010/04/10(土) 12:47:16
>>557
いやもういいから

559 :デフォルトの名無しさん:2010/04/10(土) 12:47:46
 位覚えろ

560 :デフォルトの名無しさん:2010/04/10(土) 12:51:22
>>514
初心者すぎる消えろ

561 :デフォルトの名無しさん:2010/04/10(土) 12:57:27
初心者しかいないんだからいいじゃん

562 :デフォルトの名無しさん:2010/04/10(土) 13:01:10
>557
ライブラリとしてトランスレーター用意すればいいだろ……
さらに言うと呼び出し規約を整理してリンクできるようにしておけば良いだけの話。
コアで話すようなことじゃ無いよ。

>108とか情報科学とか勉強しているやつはいないのかしらん?「計算理論の基礎」は良い本だと思ったけど、誰か読んだ?

563 :デフォルトの名無しさん:2010/04/10(土) 13:33:52
「〜なやつ」はもういいから。ウザイって。

564 :デフォルトの名無しさん:2010/04/10(土) 13:37:06
stdout, stderr, stdinといった標準デバイスという概念も古いよな。


565 :デフォルトの名無しさん:2010/04/10(土) 13:38:02
何が新しいの?

566 :デフォルトの名無しさん:2010/04/10(土) 13:39:34
int型の 代入と 四則演算 のみを解釈できるインタープリタ作りからはじめれば?最初から最先端をやろうとせずに。

567 :デフォルトの名無しさん:2010/04/10(土) 13:40:41
>>566
そんなのすでにやってるから。やりたければお前が一人で学習してろ。

568 :デフォルトの名無しさん:2010/04/10(土) 13:41:23
うんうん、ラベルのパーズも大変だから飛び先は行番号でいいね

569 :デフォルトの名無しさん:2010/04/10(土) 13:46:12
forとかwhileもめんどくさいからif〜thenとgotoがあればいいよね
あ、サブルーチンはさすがに必要だな、gosubとでもするか

570 :デフォルトの名無しさん:2010/04/10(土) 13:47:24
>>561
FORTHの最大の利点はハードの抽象化レイヤーが非常に薄いということだね。
しかし一番の欠点は方言が多すぎるのとGPL実装がほとんどということかな。

んで出るのが20年早すぎたトランスピュータ生まれのOccamとかどうなんだろうな。
あれもある意味では組み込みに近いよな。

571 :デフォルトの名無しさん:2010/04/10(土) 13:52:11
よし、>>567が作ったインタープリタかコンパイラをみんなで評価しよう。どこかにアップしてくれ。

572 :デフォルトの名無しさん:2010/04/10(土) 13:54:18
処理系の作りやすさよりも、先ずは使い易い言語仕様を考えよう。

実装の話は言語仕様が固まってからだ。

573 :デフォルトの名無しさん:2010/04/10(土) 13:59:16
>>552
ポインタのアドレス型ってのが独立してあれば良くないか?

574 :デフォルトの名無しさん:2010/04/10(土) 14:00:29
意味不明

575 :デフォルトの名無しさん:2010/04/10(土) 14:02:00
修正バージョンアップを繰り返すんだから、仕様が固まる事などないよ。
こう言う場合は、仕様と実装を並行してやるしかない。

576 :デフォルトの名無しさん:2010/04/10(土) 14:04:50
>>575
それでは、どうぞ実装を勧めてください。

ただし、実装者のスキル不足に引っ張られて言語仕様を妥協しない方がいい。

577 :デフォルトの名無しさん:2010/04/10(土) 14:07:54
えっ スキル不足で俺には無理ですよ。誰かやってくれるんじゃないの?

578 :デフォルトの名無しさん:2010/04/10(土) 14:12:14
>570
Occamかあ。
プロセスの抽象化は魅力的なんだけど、重たくなったりしないのかな?
あと、式の中身自体は普通の命令型の処理だよね?命令型の部分はどうしよう?


579 :デフォルトの名無しさん:2010/04/10(土) 14:26:14
>>478
同じだろ。*は単独では型を表せないし
優先高いから変数にくっつける
c++は言語も汚いが慣習も理にかなわないからキライ

580 :デフォルトの名無しさん:2010/04/10(土) 14:30:12
>>499
でgoができるワケだな

581 :デフォルトの名無しさん:2010/04/10(土) 14:31:40
>>503
apple script w
読めるがかけねえ

582 :デフォルトの名無しさん:2010/04/10(土) 14:40:49
>>538
今でも組み込みだと内部メモリと
外部のSDRAMで速度差あるから
普通にリンカスクリプトとattributeで使い分けるよ

583 :デフォルトの名無しさん:2010/04/10(土) 15:00:34
>>570
Occum は Transputer のアセンブラだから、その意味では C より低水準で、
かつ、C に比べればずっと先進的な言語仕様だよね。

584 :デフォルトの名無しさん:2010/04/10(土) 15:18:11
Transputerか。レジスタマシンでエミュレートすることを前提とするとセマンティックギャップがすごくなりそう。
効率的な変換器があったりするのかな?

585 :デフォルトの名無しさん:2010/04/10(土) 15:22:05
>>579
全然違う。そもそも両者はコンパイラだって区別して扱っている。
同じならコンパイラも区別せず統一的に扱えるはず。

586 :デフォルトの名無しさん:2010/04/10(土) 15:43:58
C#最強ってこと

587 :デフォルトの名無しさん:2010/04/10(土) 15:48:49
行番号で直接コードをメモリアドレスに割り当てられるようにしようぜ

588 :デフォルトの名無しさん:2010/04/10(土) 16:43:45
引数をレジスタ渡し一択
返値は逆にリッチにしてスタック上のリスト+レジスタ。

関数革命

589 :デフォルトの名無しさん:2010/04/10(土) 16:47:38
初心者の集まりだったが、アホの集まりになったな。

590 :デフォルトの名無しさん:2010/04/10(土) 16:54:06
ま、言語で云々ってレベルでは大したことないな
アルゴリズムで勝負するのが一番の高速化手法

591 :デフォルトの名無しさん:2010/04/10(土) 18:25:44
どんな言語を作るとしてもアセンブラに変換→マシン語(バイナリ)なんだから
結局はC言語に似たり寄ったりになる

592 :デフォルトの名無しさん:2010/04/10(土) 18:29:50
目標はhaskell

593 :デフォルトの名無しさん:2010/04/10(土) 18:32:01
>>590
けど、LLじゃどんなに正しくクイックソートを書いても配列の計算で無駄な事してるから
どう頑張ってもCで書いたのには勝てないんだなぁ。

594 :デフォルトの名無しさん:2010/04/10(土) 18:54:47
配列は全てsentinel方式に固定

595 :デフォルトの名無しさん:2010/04/10(土) 20:00:51
ダサすぎるだろ

596 :デフォルトの名無しさん:2010/04/10(土) 20:19:04
>>586
C# は unsafe でポインタ使ってカリカリのコード書いても
何故か C より遅いのが嫌なんだよなあ。
結局 C++/CLI と連携したりしなきゃならなくなる。
JIT 改善してくれれば良いのに。

597 :デフォルトの名無しさん:2010/04/10(土) 20:22:26
>>596
DllImportしろ

598 :デフォルトの名無しさん:2010/04/10(土) 20:26:26
つーかこの糞スレ、パート2かよ。ようやるわ

599 :デフォルトの名無しさん:2010/04/10(土) 20:28:09
C#じゃなくていいけど、プロパティの仕組みは欲しいよな。

あとC言語の引数を括弧で囲むのもやめてほしい。
理由は関数合成が汚く見えるから。

600 :デフォルトの名無しさん:2010/04/10(土) 20:31:31
>>599
> あとC言語の引数を括弧で囲むのもやめてほしい。
どうしろと?

601 :デフォルトの名無しさん:2010/04/10(土) 20:33:48
>>599
VB6使えば?

602 :デフォルトの名無しさん:2010/04/10(土) 20:36:39
引数を括弧で囲むんじゃなくて、括弧で囲んでいるのが関数なんだよ。
でないと変数と区別がつかなくなる。

603 :デフォルトの名無しさん:2010/04/10(土) 20:37:11
>>601
VBでも、関数は括弧必須だろ

604 :デフォルトの名無しさん:2010/04/10(土) 20:39:32
>>602
関数として宣言するし、名前はユニークなんだから区別はつくでしょ。
MLとかHaskellでは引数に括弧はいらないよ。

605 :デフォルトの名無しさん:2010/04/10(土) 20:44:41
関数型言語みたいに高階関数を引数にとるわけじゃないなら
括弧あった方が読みやすい

606 :デフォルトの名無しさん:2010/04/10(土) 20:57:28
紙に印刷されたものを読むときは特に。

607 :デフォルトの名無しさん:2010/04/10(土) 21:00:31
開発と名がついてる内でトップレベルの糞スレなのに不思議と伸びるよな

608 :デフォルトの名無しさん:2010/04/10(土) 21:01:29
アセンブリ言語への変換を考えても、
高階関数を採用しても何ら問題ないように思う。

609 :デフォルトの名無しさん:2010/04/10(土) 21:02:16
俺言語作っているやつの冷やかしが混ざっているから。
協力する気は毛頭無いだろうけど。

610 :デフォルトの名無しさん:2010/04/10(土) 21:02:53
バザールモデルでモノが出来上がるわけがない。
何スレ使ったって無駄だよ。


611 :デフォルトの名無しさん:2010/04/10(土) 21:07:18
Cに代わるものといいながら、Cの欠点としてマクロとヘッダしか上がってこない。

612 :デフォルトの名無しさん:2010/04/10(土) 21:08:37
ポインタ演算・・は必要悪的なところがあるな
それより文字列をどうにかすべき

613 :a36 ◆K0BqlCB3.k :2010/04/10(土) 21:08:41
>>610
このスレみたいな開発スタイルは伽藍でもバザールでもなくて、
お互いに顔も名前も知らない多数の人間同士が話しあって何かを決めるスタイルだ。
名前が無いので付けるとしたら匿名直接民主主義スタイル。
しかし、俺の経験上、何かを決めるためには少数の、
それも3人以下の人数でないと何も決まらない。

614 :デフォルトの名無しさん:2010/04/10(土) 21:16:07
>>611
じゃあ欠点挙げてやるよ。
○関数のデフォルトがグローバル
○static関数や変数でもプロトタイプが必要
○ポインタの宣言が難解
○二つの異なる動作が同じstaticキーワードで表現される
(staticグローバル変数と関数内static変数ね。実はアセンブラ的に考えると
同じ動作なのだが、アセンブラに興味のないプログラマには異なる動作と映る)
○switch-caseのデフォルトがfall thruough
○返り値のデフォルトがint
○演算子の記号が結構てきとう
○優先順位はもっとてきとう


615 :デフォルトの名無しさん:2010/04/10(土) 21:18:02
>>608
同意。
最新のオサレ機能でパフォーマンスに影響を与えない機能は備えたいな。

616 :デフォルトの名無しさん:2010/04/10(土) 21:19:27
>>615
それはもはや低級言語ではないな。

617 :デフォルトの名無しさん:2010/04/10(土) 21:25:18
このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義しよう。

618 :デフォルトの名無しさん:2010/04/10(土) 21:28:39
OSに依存する機能は入れないということでいいね。

619 :デフォルトの名無しさん:2010/04/10(土) 21:33:37
CでもOS依存部分はライブラリだしな

620 :デフォルトの名無しさん:2010/04/10(土) 21:37:01
>611
>4読んで消えてしまえ

621 :デフォルトの名無しさん:2010/04/10(土) 21:38:06
OS依存機能はライブラリでいいけど、組み込みの機能がライブラリを呼び出してもいいんじゃない?
スレッドとか正規表現リテラルとかはあって欲しいな。

当然ライブラリが無ければその機能は使えないけど、
OSを作る人はそのあたりは理解してどこまで使えるか考えながら使うでしょ。

622 :デフォルトの名無しさん:2010/04/10(土) 21:42:18
正規表現を言語仕様にだぁ?ご冗談を。それのどこが低級言語だよ。

623 :デフォルトの名無しさん:2010/04/10(土) 21:43:44
ここの低級言語だ。

624 :デフォルトの名無しさん:2010/04/10(土) 21:45:16
正規表現はOSに依存しなさそうだけど、文字列型は依存してしまいそう。

625 :デフォルトの名無しさん:2010/04/10(土) 21:45:35
正規表現は高度な機能ではあるが、上層とか下層とかそういう次元の物ではないだろう

626 :デフォルトの名無しさん:2010/04/10(土) 21:46:51
スレッドも正規表現も、ライブラリで対応って言ってるだろ

627 :デフォルトの名無しさん:2010/04/10(土) 21:48:44
言語がリテラルを定義する機能を持てば、正規表現リテラルはなくてもいいかな。
むしろそっちの方がいいか。

言語がリテラルを定義する機能を持ち、
標準ライブラリが正規表現リテラルを提供してくれればそれでいい。

628 :a36 ◆K0BqlCB3.k :2010/04/10(土) 21:48:52
>>622
言語仕様として定義されている組み込みライブラリに正規表現を含めるなら特に問題ないんじゃない。

629 :デフォルトの名無しさん:2010/04/10(土) 21:50:47
「本で読んだことそのまま言ってるんだろうな…w」 ってレスがチラチラあるね…

630 :デフォルトの名無しさん:2010/04/10(土) 21:50:53
明にか暗にかはわからないが、マルチスレッドに対応する機能は言語仕様に備えるべきだな。

631 :デフォルトの名無しさん:2010/04/10(土) 21:51:41
>>626
それじゃサブセットの言語があるのと同じだからだめだよ。Cに対するC++のようなもの。スレタイはこのさい関係ない。

632 :デフォルトの名無しさん:2010/04/10(土) 21:52:46
だから、OS前提の機能を標準ライブラリに入れるな。

633 :デフォルトの名無しさん:2010/04/10(土) 21:52:55
言語がリテラルを定義する機能を持つなら、
言語コア仕様が文字列リテラルを持たなくても、標準ライブラリで文字列リテラルを提供してくれればいいよ。

634 :デフォルトの名無しさん:2010/04/10(土) 21:55:09
>>613
ここまで読んで思い付いたのだが「烏合の衆モデル」てのはどうよ?
当然、成果物は得られないw

635 :デフォルトの名無しさん:2010/04/10(土) 21:57:22
>>1
OS前提の機能ってなんだよ?

標準出力
ファイル
スレッド
プロセス
メモリー
ネットワーク
グラフィックス
は、一般的なOSが提供するよな?

636 :a36 ◆K0BqlCB3.k :2010/04/10(土) 21:58:12
>>629
悪かったよ。
さっき ハインライン の 月は無慈悲な夜の女王 を読みきったところなんだよ。

637 :デフォルトの名無しさん:2010/04/10(土) 22:01:19
文字列処理の機能があっても良いと思うけど、正規表現じゃなくてPEGだろ。

638 :デフォルトの名無しさん:2010/04/10(土) 22:01:53
PEGって何?

639 :デフォルトの名無しさん:2010/04/10(土) 22:01:57
>>632
CのライブラリのほとんどはOS前提だが。

640 :デフォルトの名無しさん:2010/04/10(土) 22:07:13
>>636
同志

641 :デフォルトの名無しさん:2010/04/10(土) 22:08:50
>>637
解析表現文法(かいせきひょうげんぶんぽう、英: Parsing expression grammar, PEG)
か。

正規表現にとって代われるものならこれもあってもいいけど、
使い慣れている人が多いから正規表現も必要だろうな。

642 :デフォルトの名無しさん:2010/04/10(土) 22:14:31
>641
PEGは基本的にLL(∞)+αだから表現力は問題なし。
LLベースだから再帰との相性もいいし、パーツ毎の独立性も高い。

問題はトラックバックが多いと性能悪化することだけど、まあ気にすんな。


643 :デフォルトの名無しさん:2010/04/10(土) 22:15:04
>>639
string関連のライブラリのほとんどはOSなしで書けるんじゃね
memcpy, memcmpとかも書けるし
stdioはもちろんOSないとダメだけども


644 :デフォルトの名無しさん:2010/04/10(土) 22:16:35
言語仕様とライブラリが混同してるな

645 :デフォルトの名無しさん:2010/04/10(土) 22:20:38
言語仕様でも標準ライブラリでもOSの機能を使っていいよ。

OS作る人は使えない機能があって困惑するかもしれないけど、
そもそもOS作る人がコンパイラを作る(またはポーティングする)んだろうから問題ないよ。
使えるようになった機能から使うようにすればいい。

デバドラ屋にとっては問題ないし。

646 :デフォルトの名無しさん:2010/04/10(土) 22:23:45
ところでお前ら何歳だよ
物知ってるな

647 :デフォルトの名無しさん:2010/04/10(土) 22:24:20
>>644
追加インストールしなくても使えることが保証されてる標準ライブラリは言語仕様の一部だよ。

648 :デフォルトの名無しさん:2010/04/10(土) 22:25:02
言語仕様がどんなものか判ってないんだろ。
ForthとLisp、Fortran、BASIC、BF、C辺りの違いがわかるやつも少そうだし。

649 :デフォルトの名無しさん:2010/04/10(土) 22:25:31
ガベコレに依存するオブジェクトシステム
に依存する文字列は、言語仕様なのかライブラリなのか

650 :デフォルトの名無しさん:2010/04/10(土) 22:25:42
>>645
使えない機能があるんだったら、はじめから仕様からはずしておくべき。
OSの機能を使っていいということになったら、ぜひとも入れたいという機能はいくらでも出てくる。

651 :デフォルトの名無しさん:2010/04/10(土) 22:26:17
>>648
「やつ」の話はいらないって。

652 :デフォルトの名無しさん:2010/04/10(土) 22:28:08


653 :デフォルトの名無しさん:2010/04/10(土) 22:32:13
マ板のオブジェクト指向スレと流れが似てる。


654 :デフォルトの名無しさん:2010/04/10(土) 22:33:36
>>650
例えば、
ヒープを確保するためにライブラリ関数を呼び出すのは美しくない。
言語仕様が備える機能で確保したい。

655 :デフォルトの名無しさん:2010/04/10(土) 22:34:35
>>654
へ?ヒープはOSのサービスだろ?言語仕様関係ないべ?

656 :デフォルトの名無しさん:2010/04/10(土) 22:36:02
だから、OSが提供する機能であっても言語仕様に含めるべきだと言ってるんだって。

OSのサービスは言語仕様と関係ないと初めから決めつけるようなことではない。

657 :デフォルトの名無しさん:2010/04/10(土) 22:44:34
そこで仮想レジスタ構文登場

658 :デフォルトの名無しさん:2010/04/10(土) 22:46:56
言語仕様にOSが提供する機能を入れたら、それはここで言う低級言語ではない。

659 :デフォルトの名無しさん:2010/04/10(土) 22:48:28
>>10

660 :デフォルトの名無しさん:2010/04/10(土) 22:49:24
>>656
それってつまり、C++のnewが内部でOSのシステムコールMALLOCを呼んでる
(実際には間にCライブラリmalloc()が入る)みたいにしたいってことかい?
そういうふうに勝手にOSシステムコールしちゃう言語だと、OS書けなくなるけどいいの?


661 :デフォルトの名無しさん:2010/04/10(土) 22:51:00
>>657
仮想マシンのバイトコードから現実のマシン語かアセンブラへの変換は難しいと思う。
それができるならx86からarmへのアプリのバイナリ変換による移植も容易くできる事になるが、
実際には難しいよね。

662 :デフォルトの名無しさん:2010/04/10(土) 22:55:13
難しい部分はレジスタセット定義を環境別に用意して実装も別にする位じゃなきゃ
Cを超える事なんて出来んので

仮想レジスタ構文なんだよ

663 :デフォルトの名無しさん:2010/04/10(土) 22:55:13
このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義する。

664 :デフォルトの名無しさん:2010/04/10(土) 22:56:24
>>660
OS作る人は使えない機能があって困惑するかもしれないけど、
そもそもOS作る人がコンパイラを作る(またはポーティングする)んだろうから問題ないよ。
使えるようになった機能から使うようにすればいい。

665 :デフォルトの名無しさん:2010/04/10(土) 22:57:04
>>660
いつから malloc がシステムコールになったのか詳しく


666 :デフォルトの名無しさん:2010/04/10(土) 22:57:30
>>664
先生それならCで書いたほうが早いですw

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

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。

668 :デフォルトの名無しさん:2010/04/10(土) 22:58:35
>>665
mallocってシステムコールじゃないの?
てか用語が間違ってるのかな。OSのサービスって言えばいい?

669 :デフォルトの名無しさん:2010/04/10(土) 22:59:55
>>612
低水準なら、直接いじるって方法を捨てるわけにはいかんわなぁ。
C++のstringじゃ不満かい?

670 :デフォルトの名無しさん:2010/04/10(土) 23:00:03
>>667
無駄な再発明したって仕方ないだろ
Cで書いたほうが早いじゃんって言われるような言語に何の意味がある


671 :デフォルトの名無しさん:2010/04/10(土) 23:00:21
mallocはCの標準ライブラリで、mallocの中でOSのシステムコールを呼ぶ。

672 :デフォルトの名無しさん:2010/04/10(土) 23:01:44
>>664
先生、あとOS作る人はコンパイラ作りません。

673 :デフォルトの名無しさん:2010/04/10(土) 23:02:58
mallocはCの仕様で記述できるからOSの機能と呼ぶ必然性はない
OSと連携したほうが高機能になるが

674 :デフォルトの名無しさん:2010/04/10(土) 23:03:10
>>671
X68000とかはシステムコール名がMALLOCだったわけだがそんなの出すのは反則ですか

675 :デフォルトの名無しさん:2010/04/10(土) 23:03:25
>>668
> mallocってシステムコールじゃないの?
普通, brk/sblk とか malloc 使って全く別のインターフェースとして実装されてる


676 :デフォルトの名無しさん:2010/04/10(土) 23:03:35
と、まぁ同じ事の堂々巡りにしかならない糞スレなんだから
次スレとか要らないよ >アイちゃん。

677 :デフォルトの名無しさん:2010/04/10(土) 23:04:46
>>673
意味がよくわからない。
OSシステムコールを一切使わず、独立したコードでmallocが書けるって意味?
そんなこと出来ないはずだけど。


678 :デフォルトの名無しさん:2010/04/10(土) 23:05:01
>>674
malloc()とMALLOC()はCでは別物だよね。他の言語では知らんけど。

679 :デフォルトの名無しさん:2010/04/10(土) 23:05:27
>>672
OS じゃねぇけど, リアルタイムモニターもコンパイラも作ったが



680 :デフォルトの名無しさん:2010/04/10(土) 23:06:08
>>677
そのとおり。
少なくともどこかでOSに問い合わせてメモリーを確保しなければいけないからな。

681 :デフォルトの名無しさん:2010/04/10(土) 23:06:16
>>677
できますよ。
static char heap[1024*1024*HEAP_SIZE];
でこのメモリを管理。
組み込みでは一般的。

682 :デフォルトの名無しさん:2010/04/10(土) 23:07:32
>>681
そのheapをどこに配置するかは誰が管理してるんだよ。

683 :デフォルトの名無しさん:2010/04/10(土) 23:07:46
mallocもかけない奴が言語仕様語ってるのかw

684 :デフォルトの名無しさん:2010/04/10(土) 23:08:01
>>668
どのOSの話してるのかは知らんが、K&R第2版にあったUNIXでmallocを実装する例では、
間接的にsbrkシステムコールを使ってメモリを取得しているようだった。


685 :デフォルトの名無しさん:2010/04/10(土) 23:08:27
>>682
お前コード読めないの?
静的変数は言語仕様。

686 :デフォルトの名無しさん:2010/04/10(土) 23:09:11
>>681
それはインチキ。OS使わないんじゃなくて、OSがメモリ管理機能を持ってないだけじゃん。


687 :デフォルトの名無しさん:2010/04/10(土) 23:09:26
>>682
演算子は誰が実行してるんだよというくらいバカなレス

688 :デフォルトの名無しさん:2010/04/10(土) 23:10:10
>>682
組み込みの場合は, *.h とかってファイルにメモリーのサイズと共に
スタティックに書かれてることが多い


689 :デフォルトの名無しさん:2010/04/10(土) 23:10:21
>>686
このレベルがOSや言語仕様語ってるのかw

690 :デフォルトの名無しさん:2010/04/10(土) 23:11:56
>>681
それのどこがmalloc何だ?HEAP_SIZEが変数?

691 :デフォルトの名無しさん:2010/04/10(土) 23:12:04
唐突に見下されても意味わかんないし

692 :デフォルトの名無しさん:2010/04/10(土) 23:13:13
>>690
あっキミちょっと黙ってて

693 :デフォルトの名無しさん:2010/04/10(土) 23:13:33
やっべーメモリ管理も知らない奴が言語仕様てw

694 :デフォルトの名無しさん:2010/04/10(土) 23:13:38
見下してると言うより、着いていけなくて、俺の分からない話はするなーってことでしょ。
小学校の時よくいた。

695 :デフォルトの名無しさん:2010/04/10(土) 23:15:01
>>690の質問が余程きびしかったようだな。
必死にごまかそうとしている。>>692

696 :デフォルトの名無しさん:2010/04/10(土) 23:15:34
>>695
煽ってもみんなわかってるからw

697 :デフォルトの名無しさん:2010/04/10(土) 23:16:05
JavaやLL育ちのゆとりが、
8bitCPUレベルの組み込み用途にも使われるの言語について語るとか、マジ勘弁してくれ。

698 :デフォルトの名無しさん:2010/04/10(土) 23:16:26
mallocすからかけない奴が言語仕様てw

699 :デフォルトの名無しさん:2010/04/10(土) 23:16:40
>>690

俺681じゃないけど、こんなふうに実装すればできるよ。

void* malloc(size_t size)
{
return heap[]からsizeバイト確保したメモリを返す
}

void free(void* ptr)
{
ptrが指すメモリをheap[]に返す
}


700 :デフォルトの名無しさん:2010/04/10(土) 23:18:10
void *malloc(size_t size);
は与えられたサイズ分のメモリーをヒープに確保してそのアドレスを戻り値に返す。

>>681は少なくともmallocの実装にはなっていないけど、どうなってるの?

701 :デフォルトの名無しさん:2010/04/10(土) 23:18:10
「メモリ管理はOSさんがやってくれないと何もできません」
こんな奴が「言語仕様」www

702 :デフォルトの名無しさん:2010/04/10(土) 23:19:01
おまえは全ソースコードがないと理解できないのか。
いやソースあっても理解できないな・・・

703 :デフォルトの名無しさん:2010/04/10(土) 23:19:07
なんかファビョってるのがいるな


704 :デフォルトの名無しさん:2010/04/10(土) 23:19:58
スタックすら理解できなさそう

705 :デフォルトの名無しさん:2010/04/10(土) 23:20:58
リンカすらOSと言い出しそう

706 :デフォルトの名無しさん:2010/04/10(土) 23:20:59
>>699了解。
>>700を書き込んでからそれを読んだ。

707 :デフォルトの名無しさん:2010/04/10(土) 23:21:55
>>706
だから黙っててと書いたのに。。。LL育ちがばれちゃったね。

708 :デフォルトの名無しさん:2010/04/10(土) 23:24:56
薄識でも相手にしてもらえるスレ見つけてハイテンションになってる奴が巣くってるんだよ。

709 :デフォルトの名無しさん:2010/04/10(土) 23:25:48
mallocを呼び出した後か前かは別にして、メモリーを確保するためにはどこかでOSにお伺い(システムコール)をたてる必要はある。

OSがメモリーを管理しているのであれば、>>681にしてもどこかでOSにお伺いをたてる必要がある。

710 :デフォルトの名無しさん:2010/04/10(土) 23:26:05
リンカはOSだろ。知らなかったのか?バカじゃん?

711 :デフォルトの名無しさん:2010/04/10(土) 23:26:41
>>709-710

712 :デフォルトの名無しさん:2010/04/10(土) 23:28:45
リンカーがOSというのは語弊があるが、少なくともリンカーはOSが実行可能な形式のバイナリーを生成する。
だから、リンカーはOSに依存する。

713 :デフォルトの名無しさん:2010/04/10(土) 23:28:53
ネタレスはいいから

714 :デフォルトの名無しさん:2010/04/10(土) 23:29:32
動的リンクはOSに入りますか?

715 :デフォルトの名無しさん:2010/04/10(土) 23:30:01
メモリのことは環境によって大違いなわけだから、OSが受け持つ仕事だろ。

716 :デフォルトの名無しさん:2010/04/10(土) 23:30:25
いきなり0番地からのバイナリを吐き出すコンパイラとかの想像もできないのか

717 :デフォルトの名無しさん:2010/04/10(土) 23:30:35
>>714
動的リンクはOSに入らないが、動的リンクの機能はOSに依存する。

718 :デフォルトの名無しさん:2010/04/10(土) 23:31:08
言語仕様の話と実装の話が混乱しすぎ

719 :デフォルトの名無しさん:2010/04/10(土) 23:31:10
2chはバカしかいなくなってしまった。
10年前に戻りたい。

720 :デフォルトの名無しさん:2010/04/10(土) 23:31:56
>>719
他に居場所がないなら仕方ない

721 :デフォルトの名無しさん:2010/04/10(土) 23:32:10
全員バカ、という奴が一番バカなのは古くからの常識

722 :デフォルトの名無しさん:2010/04/10(土) 23:32:18
>>718
どう混乱しているのか具体的に

723 :デフォルトの名無しさん:2010/04/10(土) 23:32:54
本物の初心者なんですが、コンパイルされた機械語(ROM?)は、どのCPUでも同じように動きますか?

724 :デフォルトの名無しさん:2010/04/10(土) 23:33:29
>>723
動かない。

725 :デフォルトの名無しさん:2010/04/10(土) 23:34:08
>>724
そうですか・・・

726 :デフォルトの名無しさん:2010/04/10(土) 23:34:27
ROMてのはどっからきたんだw

727 :デフォルトの名無しさん:2010/04/10(土) 23:35:29
マイコンに焼き付けるROMのことだろう

728 :デフォルトの名無しさん:2010/04/10(土) 23:35:49
>>722
Cの仕様で記述できるものはどう実装されていようとかまわない。
実装がOSの機能を使おうと使わなかろうと本来関係がない。
知っている実装系がOSの機能を使っていようとも。

729 :デフォルトの名無しさん:2010/04/10(土) 23:37:57
標準ライブラリはCの言語仕様ではない。
main関数すら慣例であって必須ではない。
OSレス、ディスクレス、コンソールレスの
組み込みシステムでも、簡単なレジスタと
メモリの初期化だけアセンブラで残して
後はすべてCで記述するとかいうことは
大昔から普通に行われている。
printfも自前のライブラリで実装とか当たり前だ。
そうした用途に使える言語はCしかない。

730 :デフォルトの名無しさん:2010/04/10(土) 23:38:51
>>728
ああ、それなら完全に同意。
煽ってるだけかと思った。

731 :デフォルトの名無しさん:2010/04/10(土) 23:39:35
とにかく、Cの場合、OSに依存している部分はライブラリに分離され、言語自身はOSとは独立している。

732 :デフォルトの名無しさん:2010/04/10(土) 23:40:09
mallocは置いておいて、

OS無しの組み込み開発で使われることもあるプログラミング言語の
言語仕様にマルチスレッドを標準装備しろとか有り得ない。

733 :デフォルトの名無しさん:2010/04/10(土) 23:41:00
malloc使えない香具師を罵倒して悦に入ってる香具師は
mallocの実装を自分で書いたこともないのだろう

734 :デフォルトの名無しさん:2010/04/10(土) 23:41:27
>>729
あったねー
ゲーム機とかそんな感じだったね。
ライブラリ皆無で、memcpyやらstrcmpやらも自前で作ったw
もちろんmallocも。
printfは面倒だから作らなかったけど。
C以外でこれをやれって言われても、めんどくせえからやだ、で終わりだわな。
>>1はこういう経験あるんだろうか。
LL脳が粋がってわめいてるだけにしか思えないのだが。

735 :デフォルトの名無しさん:2010/04/10(土) 23:42:32
>>732
ライブラリでなく言語仕様に標準装備って例えばどんなの?

736 :デフォルトの名無しさん:2010/04/10(土) 23:43:50
>>721
ひろゆきもバカだけど年収1億超え^^

737 :デフォルトの名無しさん:2010/04/10(土) 23:45:44
>>630 とか

738 :デフォルトの名無しさん:2010/04/10(土) 23:46:40
Erlangのことか

739 :デフォルトの名無しさん:2010/04/10(土) 23:47:25
言語仕様に文字列処理を含めたとしても、「但し文字列処理を使うためには標準ライブラリの”String”を実装してください」、というような仕様でもいいよ。
OS屋は文字列処理を使いたかったら、先ず”String”を実装して、それから文字列処理を使えばいい。

言語仕様のフル機能が常に揃っていなければいけないことはないわけだし。

740 :デフォルトの名無しさん:2010/04/10(土) 23:49:30
>>739
それでは、実質的にStringがない別の言語があるのと同じ。

741 :デフォルトの名無しさん:2010/04/10(土) 23:50:19
標準ライブラリってOS屋が作るものか?

742 :デフォルトの名無しさん:2010/04/10(土) 23:51:56
言語仕様に含まれていれば、
if(!strcmp(str1, str2))
↑こんなことせずに
↓こうできる
if(str1 == str2)

743 :デフォルトの名無しさん:2010/04/10(土) 23:52:07
いつもの俺ルールなんだろ

744 :デフォルトの名無しさん:2010/04/10(土) 23:53:09
副作用なくして並列処理可能な言語仕様自体はできるとおもうが。

745 :デフォルトの名無しさん:2010/04/10(土) 23:53:34
>>742
LL臭がプンプンする。。。
if (str1 == str2) には別の意味があるってのに。。。


746 :デフォルトの名無しさん:2010/04/10(土) 23:54:08
本物の初心者なんですが、C言語の標準ライブラリというのは、
オブジェクト指向のダックタイピングみたいなもんですか?

747 :デフォルトの名無しさん:2010/04/10(土) 23:54:32
文字列処理をライブラリに追い出すのがC/C++のコンセプトだと思うが。

748 :デフォルトの名無しさん:2010/04/10(土) 23:54:38
>>745
>>742は例だ。何言語かも言及してないし、意味も定義していない。「別の意味」も何もない。
単に構文が簡単になるということを言っている。

749 :デフォルトの名無しさん:2010/04/10(土) 23:55:07
>>744
時代に沿った流れとしては、低レベルでネイティブな並列処理が欲しい所ではある

750 :デフォルトの名無しさん:2010/04/10(土) 23:55:42
>>742
Java

751 :デフォルトの名無しさん:2010/04/10(土) 23:55:54
おまいらフロー制御はbool分岐だけなの?
もっとプリミティブなところ考えようぜ

752 :デフォルトの名無しさん:2010/04/10(土) 23:56:15
>>749
イメージできてそのレスしてる?

753 :デフォルトの名無しさん:2010/04/10(土) 23:56:56
>>749
欲しいね。

754 :デフォルトの名無しさん:2010/04/10(土) 23:57:35
>>751
fortranの算術ifでも復活させたいのかね

755 :デフォルトの名無しさん:2010/04/10(土) 23:57:44
低レベル並列処理ってなんだよw

756 :デフォルトの名無しさん:2010/04/11(日) 00:00:09
>>755
どのコアで実行させるかとか、そう言うのじゃないの。

メモリーアドレスをポインター変数で隠蔽するように、コア番号を隠蔽するコア変数みたいのとか。

757 :デフォルトの名無しさん:2010/04/11(日) 00:00:43
CPU1個,OS無しの状態で、言語仕様だけで並列処理が出来るのか考えてもらおうか

758 :デフォルトの名無しさん:2010/04/11(日) 00:00:52
言いたいことはわかるけど、なんか表現が違う

759 :デフォルトの名無しさん:2010/04/11(日) 00:01:28
>>758
どういう表現がいい?

760 :デフォルトの名無しさん:2010/04/11(日) 00:02:23
Cってノイマン型ならコンパイラがライブラリもほとんどなくネイティブに変換する抽象アセンブラなイメージ

761 :デフォルトの名無しさん:2010/04/11(日) 00:02:32
左手でゆりかごをゆらし、右手でプログラミングするってことじゃないの

762 :デフォルトの名無しさん:2010/04/11(日) 00:03:36
>755
ルーチンにスレッド付けるかどうかを言語側でサポートする手もあるわな。
単にコルーチン・ファイバーに対応しても良いけど。

>754
パターンマッチングだのマルチスレッドだのいくつかあるぜ。

763 :デフォルトの名無しさん:2010/04/11(日) 00:04:55
最近の言語でさえ、とりいれられているものはほんの一部である並列処理を、なぜ切望する?

764 :デフォルトの名無しさん:2010/04/11(日) 00:05:13
>>757
並列処理を使いたい人が、並列処理を行うための機能を実装するんだろうね。
言語仕様としては、「並列処理を行う場合は”Thread”ライブラリを実装してください。」でいいと思うよ。

765 :デフォルトの名無しさん:2010/04/11(日) 00:05:51
抽象化しなきゃ意味がない前提なのにコアの指定とか矛盾。
並列化可能にしやすい言語仕様にしてインラインアセンブラみたいなものや
プラットフォーム用ライブラリで最適化支援するしかないと思うが。

766 :デフォルトの名無しさん:2010/04/11(日) 00:05:59
CPU1個だと並列処理させると普通に処理するより遅くなるんジャマイカ

767 :デフォルトの名無しさん:2010/04/11(日) 00:06:11
そのスレッドを管理するのは誰なんだよ、 ライブラリかw

768 :デフォルトの名無しさん:2010/04/11(日) 00:07:19
>>767
OSに頼れないなら、ライブラリだろうな。それ以外何がある?

769 :デフォルトの名無しさん:2010/04/11(日) 00:08:41
リンカだな

770 :デフォルトの名無しさん:2010/04/11(日) 00:10:05
なんか人工無脳がいるな

771 :デフォルトの名無しさん:2010/04/11(日) 00:10:29
>>765
だから、ポインタ変数に代入する値を出力するmallocやnewがあるように、
コア変数に代入するbeginthreadとかrunとかを定めるんだろ。

アドレス同様、コア番号を直接扱う必要は殆どないよ。

772 :デフォルトの名無しさん:2010/04/11(日) 00:12:13
並列化ってOSの仕事じゃないの?

773 :デフォルトの名無しさん:2010/04/11(日) 00:12:40
マルチコアのCPU前提で語らないでくれないか

774 :デフォルトの名無しさん:2010/04/11(日) 00:13:33
>>771
うーんお前あまり実装のイメージできてなくない?
スレッド管理って載ってるOSやCPUによってちがうだろ。
それをどう抽象化するつもりなの?
>コア変数に代入するbeginthreadとかrunとかを定めるんだろ。
はライブラリにしか見えないけど。
そんなライブラリが載りやすい言語仕様という意味ならおれ多少アイディアあるけど。

775 :デフォルトの名無しさん:2010/04/11(日) 00:14:33
>mallocやnewがあるように
新言語のことは完全に忘れ去られているw

776 :デフォルトの名無しさん:2010/04/11(日) 00:16:14
Core *cpu = allocate_core(4);
cpu[0].run(task0);
cpu[1].run(task1);
cpu[2].run(task2);
cpu[3].run(task3);
こんな感じで書けってか?
これってコアが4つとれない環境だとかえって遅くなるよ。。。
言語でやるのって意味ないと思うけど。OSの仕事だろ上皇。

777 :デフォルトの名無しさん:2010/04/11(日) 00:17:27
>>776
その場合はその構文使わなければいいのでは?

778 :デフォルトの名無しさん:2010/04/11(日) 00:19:13
>>776
どう見てもクラスライブラリw

779 :デフォルトの名無しさん:2010/04/11(日) 00:21:03
int cpuCount = getCPUCount();
Core *cpu = allocate_core(cpucount);
とかやれば・・・

って、書いてて思ったけど、
これ OS の APIじゃね?

780 :デフォルトの名無しさん:2010/04/11(日) 00:21:53
使えるコアの数を返すのはどの関数なんでしょうね。

781 :デフォルトの名無しさん:2010/04/11(日) 00:25:09
>>779
コーディング時に並列実行させたいタスクの数は静的に決まるから、
動的にCPU数を貰ってもあんまり良いことはない。むしろコードが複雑になる。
4個なら4個よこせってOS(じゃないんだっけ?w)に訊いて、例えば3個しか
無い環境なら 0, 1, 2, 2 と返すとかしてくれないと使えない。

ていうか並列処理はOSの仕事でFAだろうけど。


782 : [―{}@{}@{}-] デフォルトの名無しさん:2010/04/11(日) 00:27:12
OS依存は言語仕様外ってw

今時、そんな糞言語作って誰が使うんだ。

783 :デフォルトの名無しさん:2010/04/11(日) 00:27:43
ついてこれないなら無理にレスしなくていいよ

784 :デフォルトの名無しさん:2010/04/11(日) 00:29:13
いや正直俺もついていけてない
特に並列がどうとか正規表現がどうとかいうあたりw


785 :デフォルトの名無しさん:2010/04/11(日) 00:31:44
低レベルなシステム開発ってことは,
OS有りだけど, 直でI/O叩いたり,
OS無しのシステムだったり,
OS自体を作ったり・・・
って事でいいんかな.


786 :デフォルトの名無しさん:2010/04/11(日) 00:33:25
OS自体が作れる
これが出来ないと低級じゃないな

787 :デフォルトの名無しさん:2010/04/11(日) 00:33:45
迷ったときはとりあえず量子化すればいいんじゃね

788 :デフォルトの名無しさん:2010/04/11(日) 00:33:51
並列化も仮想レジスタセット定義の機能に含めればいいじゃん。
MACHINE X{register…}
MACHINE XS SMP2{register…}
MACHINE XN NUMA16{register…}
MACHINE XT THREAD16{register…}
MACHINE XH {MACHINE PhysX,register…}

789 :デフォルトの名無しさん:2010/04/11(日) 00:34:34
>>785
そうだね。
但し、それらを行うときに新言語のフル機能が常に揃っている必要はなくて
新言語の一部機能は制限された形で開発することになるということはあるだろうね。

790 :デフォルトの名無しさん:2010/04/11(日) 00:35:01
CはインラインアセンブラなしにOSつくれないだろ

791 :デフォルトの名無しさん:2010/04/11(日) 00:36:48
となると, インラインアセンブラ(のような機能)は入れるべき?

792 :デフォルトの名無しさん:2010/04/11(日) 00:37:29
ご冗談を
アセンブラと一緒にリンクすれば作れますぜ

793 :デフォルトの名無しさん:2010/04/11(日) 00:38:21
じゃあリンクできればCじゃなくてもいいな

794 :デフォルトの名無しさん:2010/04/11(日) 00:40:18
スタートアップルーチン必須の言語は無理ですぜダンナ

795 :デフォルトの名無しさん:2010/04/11(日) 00:42:55
OS本見ながらOSちょろっと書いてたとき思ったけど,
アセンブラ使わず, 1つの言語で全部できたらいいのにーって
思うのは俺だけだろうか・・・.

といっても, ブート部分とかCPU依存無しで,
書けるような言語って・・・できるのか?



796 :デフォルトの名無しさん:2010/04/11(日) 00:45:47
CPU側が言語仕様にあわせればできるだろうがそこまですることじゃないってこと。

797 :デフォルトの名無しさん:2010/04/11(日) 00:48:15
OSブート用のコンパイルオプションがあればできる


798 :デフォルトの名無しさん:2010/04/11(日) 00:49:14
どんなオプションだよw

799 :デフォルトの名無しさん:2010/04/11(日) 00:51:49
Linuxカーネルやgcc作ってる人って、どうせIBMやらredhatやらGoogleで働いてるスーパーハッカーなんだろ
お前らにそんな人らの真似事なんか出来るんですか

800 :デフォルトの名無しさん:2010/04/11(日) 00:52:50
OSブート用のオプションさ!

801 :デフォルトの名無しさん:2010/04/11(日) 00:53:11
人生つぎ込めるなら出来ない仕事じゃないでしょう。品質や完成度が問題。

802 :デフォルトの名無しさん:2010/04/11(日) 00:53:26
>>799
出来る。

803 :デフォルトの名無しさん:2010/04/11(日) 00:54:03
イマイチつかめてないけど,
ロードするアドレスとかスタックサイズとか指定したら
OS無しの状態で, NEW言語で書かれたものが
動く環境まで出来ちゃうコードを自動生成するんかなぁ?

>> 799
あきらめちゃそこで終わりだ!


804 :デフォルトの名無しさん:2010/04/11(日) 00:54:34
CのCはChromeのC

805 :デフォルトの名無しさん:2010/04/11(日) 00:57:13
いろいろなツールをつかって、最適化なしでいいなら、Cコンパイラの製作自体は入門レベル。

806 :デフォルトの名無しさん:2010/04/11(日) 00:58:36
>>799
真似したくないんだろ
真似するだけならCでいいんだが

807 :デフォルトの名無しさん:2010/04/11(日) 00:58:43
とはいってもひとりで実装するのは結構メンドイけどね。
このスレに実装したことあるような人間がどのくらいいるのか。
おれは言語トランスレータしかつくったことない。

808 :デフォルトの名無しさん:2010/04/11(日) 01:01:53
>>742
演算子のオーバーロードがあれば、言語仕様に含まれてなくてもできるよ。

809 :デフォルトの名無しさん:2010/04/11(日) 01:02:19
仕事で簡易スクリプトぐらいしか・・・.
家では, yacc とか使わず Dでパーサ作ったぐらい orz.


810 :デフォルトの名無しさん:2010/04/11(日) 01:04:20
iPhoneアプリで大儲け出来るアイデアを考えた方が生産的

811 :デフォルトの名無しさん:2010/04/11(日) 01:04:36
そろそろ, 基本型とか欲しくないかい?
個人的には, 固定サイズの型があると嬉しいんだが・・・.
Cの環境依存は何かと・・・
char が 1 byte じゃない時とか移植コマッタゼヨ。。。



812 :デフォルトの名無しさん:2010/04/11(日) 01:05:24
C99のstdintじゃだめなん?

813 :デフォルトの名無しさん:2010/04/11(日) 01:05:52
最初のcharは、9bit

814 :デフォルトの名無しさん:2010/04/11(日) 01:08:58
それ、1byteだろ。

815 : [―{}@{}@{}-] デフォルトの名無しさん:2010/04/11(日) 01:14:37
型は byte だけ。1バイトは8ビット固定。
2バイト以上が欲しければ byte(2) のようにする。
浮動小数やsigned/unsignedの区別は自分で行う。

816 :811:2010/04/11(日) 01:14:46
あぁ・・・そうか. すみません.
1 byte が 9bit って書かないとだめでした. m(_ _)m


817 :デフォルトの名無しさん:2010/04/11(日) 01:17:04
つまらん議論

818 :デフォルトの名無しさん:2010/04/11(日) 01:17:45
仲間に入れて欲しいんだよね^^

819 :デフォルトの名無しさん:2010/04/11(日) 01:20:22
>>815
byte(8) x = 10;
byte(8) y = 3;
byte(8) z = x / y;

z には, 3 が入るん? それとも浮動小数?



820 :デフォルトの名無しさん:2010/04/11(日) 01:20:33
型とか他の言語でも改善されてるしC99でも規定されてるしなぁ。typedefもあるし。

821 :デフォルトの名無しさん:2010/04/11(日) 01:56:54
>>810
競争激化により110円か無料でしか見向きもされず、30%をappleに取られ、一体何が残るんだ?

822 :デフォルトの名無しさん:2010/04/11(日) 05:58:04
そろそろ次スレかな?

823 :デフォルトの名無しさん:2010/04/11(日) 07:37:59
>>821
知ったかでした
すみません

824 :デフォルトの名無しさん:2010/04/11(日) 07:41:12
>>821
99ドルを知らない人

825 :デフォルトの名無しさん:2010/04/11(日) 09:09:54
>>815
死ぬほど使いにくい

826 :デフォルトの名無しさん:2010/04/11(日) 09:40:27
>>815
Ada

827 :デフォルトの名無しさん:2010/04/11(日) 11:20:28
>>597
遅いから C 使いたいだけなのになんで dllimport なんて
使わなきゃなんないんだよ。
一部のアセンブリを C++/CLI で方がずっと簡単じゃん。

828 :デフォルトの名無しさん:2010/04/11(日) 12:14:54
WebAPI対応しないの?

829 :デフォルトの名無しさん:2010/04/11(日) 13:56:47
↓この人が言語仕様をまとめます

830 :デフォルトの名無しさん:2010/04/11(日) 14:12:58
C/C++でいいじゃん

831 :デフォルトの名無しさん:2010/04/11(日) 14:14:57
ボインタのボインタのボインタって必要?
いやCなら出てくることがあるのはわかるけど
**までで良くない?

832 :デフォルトの名無しさん:2010/04/11(日) 14:19:01
だったら*だけでいいだろ

なぜ**なんだ?

833 :デフォルトの名無しさん:2010/04/11(日) 14:19:10
ボインボインうるさい

834 :デフォルトの名無しさん:2010/04/11(日) 14:21:05
メンバー参照は全部 . でいい。

835 :デフォルトの名無しさん:2010/04/11(日) 14:24:22
参照渡しは書き換えられてしまうので.じゃないほうがいい

836 :デフォルトの名無しさん:2010/04/11(日) 14:31:01
メモ渡しでOK

837 :デフォルトの名無しさん:2010/04/11(日) 14:38:43
矢切りの渡しでOK

838 :デフォルトの名無しさん:2010/04/11(日) 14:56:00
参照渡しと . はどう関係するんだ?

839 :デフォルトの名無しさん:2010/04/11(日) 16:29:16
>838
c/c++の場合関係ない

840 :デフォルトの名無しさん:2010/04/11(日) 16:36:25
参照渡し禁止ってLapack禁止ってことですか?
行列演算どうしますか?

841 :デフォルトの名無しさん:2010/04/11(日) 16:40:43
参照を値渡し

842 :デフォルトの名無しさん:2010/04/11(日) 16:55:47
>>839
C/C++の場合の話を聞いているわけではなく、どのような場合に関係してどう関係するのかを聞いているんだろ。

843 :デフォルトの名無しさん:2010/04/11(日) 18:07:49
>>831
出来ないように改悪されて困る人はいても、誰も得しないだろ

844 :デフォルトの名無しさん:2010/04/11(日) 18:53:59
いまどき、マルチスレッドにも対応できないような言語は糞

845 :デフォルトの名無しさん:2010/04/11(日) 18:58:02
明示的なポインタなくしたらダメ?


void func(ref int val)
{
val = 1;
}

func(10); // コンパイルエラー

int x = 10;
func(x);
// x = 1になる.


846 :デフォルトの名無しさん:2010/04/11(日) 19:08:50
>>845
そんなの、いくらでもあるが。

847 :デフォルトの名無しさん:2010/04/11(日) 19:22:43
おまいらgolangみてみ
GC以外は理想的だぞ
さすがと言わざるを得ない言語仕様

848 :デフォルトの名無しさん:2010/04/11(日) 19:23:16
>>845
> 明示的なポインタなくしたらダメ?

なくすも何も、新言語はこれから作るのだが。
何をなくすかではなく、言語仕様に何を含めるかを語って欲しい。

849 :デフォルトの名無しさん:2010/04/11(日) 19:24:02
多値返してエラー処理とかめんどくせぇよ

850 :デフォルトの名無しさん:2010/04/11(日) 19:25:52
じゃあ、例外にする?

851 :デフォルトの名無しさん:2010/04/11(日) 19:27:40
例外の方がもっとめんどいし汚い

852 :デフォルトの名無しさん:2010/04/11(日) 19:31:07
ということで、多値返してエラー処理になります。

853 :デフォルトの名無しさん:2010/04/11(日) 19:34:23
タプルを(1,2,3)、リストを[1,2,3]、みたいな記法を直接構文に含めずに、
後からいつでもそういう記法を作ることができるような構文ってどういうふうに定義すればいいのでしょうか?

854 :デフォルトの名無しさん:2010/04/11(日) 19:39:30
Java がネイティブコンパイルに対応したら OK なんじゃね?

855 :デフォルトの名無しさん:2010/04/11(日) 19:42:19
C++風ならこんな感じじゃないの。bracketは予約語で。

独自括弧「」の定義として

MyBracket bracket「」(int v, ...){
  処理;
  return new MyBracket;
}

856 :デフォルトの名無しさん:2010/04/11(日) 19:42:40
>>847
if文で括弧がないのが致命的にイヤだ

857 :デフォルトの名無しさん:2010/04/11(日) 19:43:36
>>853
バックエンドを先に作る。フロントエンドは後で作る。

858 :デフォルトの名無しさん:2010/04/11(日) 20:21:43
>>854
それほとんどD言語だろw

859 :デフォルトの名無しさん:2010/04/11(日) 20:23:30
>847
マクロと駆動操作クレ。
サブルーチン縛りはやだ。

860 :デフォルトの名無しさん:2010/04/11(日) 20:24:04
Dの仕様が安定して、GCのつけはずしが可能になれば無問題

861 :デフォルトの名無しさん:2010/04/11(日) 20:29:10
お前ら普段どんな言語使ってるの?
主観で使用比率もつけて教えてくれ

862 :デフォルトの名無しさん:2010/04/11(日) 20:38:13
ぷっ、D やてw


863 :デフォルトの名無しさん:2010/04/11(日) 21:05:06
D言語で金になる案件はあるの?

864 :デフォルトの名無しさん:2010/04/11(日) 21:12:26
ないでしょ。ただのオナニー言語だからね。

865 :デフォルトの名無しさん:2010/04/11(日) 21:33:45
D言語って、何年か昔にドラフトが出た日に一度見たことはあるけど、厨臭い言語だなと思ったよ。
絶対流行らないってね。

866 :デフォルトの名無しさん:2010/04/11(日) 21:35:31
漏れも

867 :デフォルトの名無しさん:2010/04/11(日) 21:36:19
流行らせれば流行る、そういう可能性を秘めたのがD言語。

868 :デフォルトの名無しさん:2010/04/11(日) 21:38:56
>>867
人を納得させられるだけの材料がなければどんな言語も流行らないよ。
Dの売りはなんだ?

869 :デフォルトの名無しさん:2010/04/11(日) 21:40:42
CはUNIXの記述から流行ったんだっけ?
最近はJava,C#なんか企業戦略だよね。
LLはオープンソースかな?

870 :デフォルトの名無しさん:2010/04/11(日) 21:42:26
>>868
C/C++に代わる低級言語

871 :デフォルトの名無しさん:2010/04/11(日) 21:43:20
>>869
> CはUNIXの記述から流行ったんだっけ?
UnixのAPIがC言語の関数だったからCを使わざるを得なかったんだよ。
別にアセンブリ言語でも書けるけど、Cだと余計なことを考えずに関数を作るだけだからな。

872 :デフォルトの名無しさん:2010/04/11(日) 21:45:36
>>869
C は、抽象化されたノイマンマシンの高級アセンブラとして普及した
Unix の記述は、ある意味実証実験でしかない


873 :デフォルトの名無しさん:2010/04/11(日) 21:52:37
ある意味

874 :デフォルトの名無しさん:2010/04/11(日) 21:53:26
おまえらのそういうところ、嫌いじゃないぜ

875 :デフォルトの名無しさん:2010/04/11(日) 21:59:58
残念ながら片思いだ

876 :デフォルトの名無しさん:2010/04/11(日) 22:05:23
>>872
自動プログラミングっていえよw

877 :デフォルトの名無しさん:2010/04/11(日) 22:09:41
今最も平均年収が高いのはC#だよ

878 :デフォルトの名無しさん:2010/04/11(日) 22:11:49
銀行員の方が高い

879 :デフォルトの名無しさん:2010/04/11(日) 22:13:52
D言語はC言語よりも高度な処理を目的とした言語。
低級な処理には向かない

Object Cとか、Cから派生してる言語はいっぱいあるが、
低級処理ならCが最高
移植性は世界一

880 :デフォルトの名無しさん:2010/04/11(日) 22:15:13
お前らの作る糞アプリで移植するケースなんてあるの?

881 :デフォルトの名無しさん:2010/04/11(日) 22:16:47
>>880
俺らの作る糞アプリではなく、過去の巨匠たちが作った
コードを引き継ぐ必要がある

882 :デフォルトの名無しさん:2010/04/11(日) 22:16:50
C#の仕事って具体的にどんなの?

883 :デフォルトの名無しさん:2010/04/11(日) 22:18:14
CのシンプルさにJavaのシンプルな部分のみを追加して欲しい。
C++はひどい。

884 :デフォルトの名無しさん:2010/04/11(日) 22:19:02
>>882
ASP.NET
Windows Forms
XNA
WPF
Silverlight

885 :デフォルトの名無しさん:2010/04/11(日) 22:20:11
XNAて
Silverlight案件なんてあるの?

886 :デフォルトの名無しさん:2010/04/11(日) 22:21:54
>>885
まだない。
これからはある。




かもしれない。

887 :デフォルトの名無しさん:2010/04/11(日) 22:23:29
サーバーサイドでも3分の1はWindowsエコシステムの仕事。
基幹系であぐらをかいてる人間はそんな世界があることさえ知らない。

888 :デフォルトの名無しさん:2010/04/11(日) 22:23:30
>>884
このなかで実際にありそうな仕事って
>ASP.NET
だけじゃね?

889 :デフォルトの名無しさん:2010/04/11(日) 22:26:23
>>888
XNAとかSilverlightは別にして、デスクトップアプリならありそうだが

890 :デフォルトの名無しさん:2010/04/11(日) 22:41:37
簡単に高機能が使えると低級じゃないのか?

おまえらの低級の定義って「初心者が使えないもの」なのか?

891 :デフォルトの名無しさん:2010/04/11(日) 22:44:27
>>890
スレを最初から読みなおせ

892 :デフォルトの名無しさん:2010/04/11(日) 22:49:07
この糞スレを最初から読むほど暇じゃないんで。

893 :デフォルトの名無しさん:2010/04/11(日) 22:50:40
レベル低すぎて煽りにもなってないw

894 :デフォルトの名無しさん:2010/04/11(日) 22:59:12
アルゴリズムを知らない単なるプログラマが増えるとレベルが下がるスレ

895 :デフォルトの名無しさん:2010/04/11(日) 23:11:36
アルゴリズムを知らないでプログラミングできません

896 :デフォルトの名無しさん:2010/04/11(日) 23:12:57
できるよ

897 :デフォルトの名無しさん:2010/04/11(日) 23:16:28
>>896
マザーボード CPU メモリ 電源買ってきてパソコン作れるよ って言ってるのと同じレベルw

898 :デフォルトの名無しさん:2010/04/11(日) 23:25:45
キーボードは?

899 :デフォルトの名無しさん:2010/04/11(日) 23:28:45
じゃあ言語作るのに必要なアルゴリズムを列挙してくれ

900 :デフォルトの名無しさん:2010/04/11(日) 23:44:01
言語作るのに必要なアルゴリズムを列挙するほど暇じゃないんで。

901 :デフォルトの名無しさん:2010/04/11(日) 23:56:48
expとかlogとかをいかに速くするか?
へるみが作ってるけど

902 :デフォルトの名無しさん:2010/04/12(月) 00:01:01
>>854
gcj


903 :デフォルトの名無しさん:2010/04/12(月) 00:03:26
gcjsが欲しい。

904 :デフォルトの名無しさん:2010/04/12(月) 00:09:53
>>894
アルゴリズムを知らないプログラマはいない
なんか別の何かだろ

ここはWinしか知らないゴミばっかでないだろうが、出てくると話のレベルが地に落ちるな

RTOSでもないOSのシステムコールがCとか思ってるバカまでいるのか?CPUの特権モードとか知らんのか

905 :デフォルトの名無しさん:2010/04/12(月) 00:10:39
>>903
そいつは悪くないな

906 :デフォルトの名無しさん:2010/04/12(月) 00:12:14
かんたんな例で最大値を求めるとか、近似解を求めるとか、知らん奴多いぞ

907 :デフォルトの名無しさん:2010/04/12(月) 00:14:46
>>904
勘違いなやつが来たぞー

908 :デフォルトの名無しさん:2010/04/12(月) 00:31:15
>>904
アホがきたwww

909 :デフォルトの名無しさん:2010/04/12(月) 00:50:04
☆【米軍による女の扱いマニュアル 】 ☆
1.女には強気で押せ。抵抗する場合は大声で命令しろ。     
2.命令を聞かない場合は身体で解らせろ。
3.同じことをくり返す場合、犬のように何回でも同じ様に叱れ。
  こちらが上と言うことを身体で解らせろ。
4.理由は聞くな。どうせ大したことは言っていない。
5.身体で解らせた場合、根に持つ場合があるので、後で身辺には気をつけて行動しろ。
  但し、徹底的に解らせる迄、手を抜いてはいけない。
6.相手を3才児と思い、信用したり頼りにはするな。重要な仕事は任せるな。

☆【 旧ソ連共産党による女の扱い方 】 ☆
1、頭痛の種になるだけだから関わるな    
2、手段を選ばぬキチガイ揃いだから関わるな
3、関わるとこっちが痛い目に遭うから関わるな 
4、関わってきたらウォッカを飲んで忘れること
787 名前: Classical名無しさん 投稿日: 10/03/28 18:38 ID:IbdJJ54w
たったレベルの煽りだなwwwww

767 名前:Classical名無しさん[] 投稿日:10/03/27(土) 23:39 ID:fHdM4fuo
☆【 旧日本陸軍の女に対する注意書き】☆
一、いつ、いかなる時でもお菓子を食事に際し好きなだけ使わすこと。
一、絶対に頭、体を叩いてはいけない。怨みを持って復讐する気質があり、脱走の原因となる。
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。
一、危険な状況下では銃を投げ捨てて「ひぎぃ」と泣き出す習癖があるから、
   日本兵二名で一名の女を入れて行動せよ。

910 :デフォルトの名無しさん:2010/04/12(月) 00:50:13
津波の心配はございません
津波の心配はございません

911 :デフォルトの名無しさん:2010/04/12(月) 21:13:37
急に過疎ったな

912 :デフォルトの名無しさん:2010/04/12(月) 21:16:01
やっぱりこういう流れか・・・。
Part3作るならC/C++に代わる言語を探すのもありかと思うがな。

現状解として、どこかから>>1の言うもの近いものを持ってきてマニュアルやライブラリを
ローライズする。そして国内向けにパッケージングするのも抗議の意味ではプログラミング言語を
作るという行為だよ。

913 :デフォルトの名無しさん:2010/04/12(月) 21:17:56
>>911
結局、なんだったんだろうな。スレの80%は自作自演だとか?
だとしたら時間もったいないけどな。

>>912
抗議じゃねえ広義だ。

914 :デフォルトの名無しさん:2010/04/12(月) 21:27:11
そもそも、CとC++では、対象としている階層が違う。
C++に代わるものならいくらでもあり、移行が始まっている。

915 :デフォルトの名無しさん:2010/04/12(月) 21:33:42
C/C++と括ってる時点でこのスレは見当違いであり
このトンチンカンなスレで4行以上レスするのは馬鹿の証左であり
従ってこのスレは馬鹿発表会にしかならない

916 :デフォルトの名無しさん:2010/04/12(月) 21:34:39
>>913 冗談だけども、
ローライズパンツ履いて国内向けにパッケージングすると、何かの抗議になるのかと思ってお茶フイタw


917 :デフォルトの名無しさん:2010/04/12(月) 21:59:37
ポインタとオサレ機能を両立してくれればそれでいい

918 :デフォルトの名無しさん:2010/04/12(月) 22:32:01
ポインタ以外に物理(仮想)アドレスをうまく扱う仕組みってあるのかな?

919 :デフォルトの名無しさん:2010/04/12(月) 22:48:39
サイズ情報と格納型情報をもう少し綺麗に分類すればいいんだよ
C++の参照型を進めた形で引数・返値にはサイズ情報型のポインタは使えなくするとサ

920 :デフォルトの名無しさん:2010/04/12(月) 22:49:49
オーバーヘッドを最小限にするなら、ポインタが一番いい手段だろ。
それ以外に考えられるわけがない。

ポインタの問題点は?それを解決するためには制御されたメモリアクセスが必要なのでは?

921 :デフォルトの名無しさん:2010/04/12(月) 22:51:16
>>920
> それ以外に考えられるわけがない。

それはお前が無能だからだろ。無能でも考えるくらいはしろよ。

922 :デフォルトの名無しさん:2010/04/12(月) 22:55:17
無能ほど他人を無能と言わずにはいられないんだよね。

923 :デフォルトの名無しさん:2010/04/12(月) 22:57:31
>>918
スライスっていうのがあるよ。

924 :デフォルトの名無しさん:2010/04/12(月) 22:59:48
>>921
有能なあなた様のご意見を是非聞きたいですなあ

925 :デフォルトの名無しさん:2010/04/12(月) 23:02:41
有能とか無能とかより何をやるかが重要だろ。
名無し相手にそんな事を言う意味がないし、
みんな名無しなんだから自分に言ってるのと同じことだぜ。

926 :デフォルトの名無しさん:2010/04/12(月) 23:12:05
C/C++をやらないことが重要だとしか言いようのないスレで、何をやるかと言われても。

927 :デフォルトの名無しさん:2010/04/12(月) 23:14:27
70年代に発明されたCを、2010年代の今、発明するとしたらどんな言語になるかと言うことを考えるスレです。

928 :デフォルトの名無しさん:2010/04/12(月) 23:18:46
だよね

929 :デフォルトの名無しさん:2010/04/12(月) 23:28:58
お前ら馬鹿だろ
もっと簡単な言語でも超高速に実行できるコンパイラ考えるほうが良いだろ
社会的ニーズはそのほうがはるかに大きい

お前ら失業するけど

930 :デフォルトの名無しさん:2010/04/12(月) 23:30:17
C/C++は文法があいまいすぎた上に愚かな拡張を重ねて遅くなった


931 :デフォルトの名無しさん:2010/04/12(月) 23:30:30
組込み屋だけど、関数型とダックタイピングしたい。

932 :デフォルトの名無しさん:2010/04/12(月) 23:31:56
>>930
愚かな拡張は重ねたが、遅くはなっていない。

933 :デフォルトの名無しさん:2010/04/12(月) 23:33:02
UNIXを駆逐するOSが現れた時、Cは滅ぶだろう
UNIXはCと共にあり、CはUNIXと共にある

934 :デフォルトの名無しさん:2010/04/12(月) 23:35:53
>>929
失業は、しないと思う。
プログラマ程汎用的な職業は他に無い。
俺ら以上にプロセスを組み立てる達人は他にいるか?

935 :デフォルトの名無しさん:2010/04/12(月) 23:37:30
Cはアセンブラを駆逐していない。共存している。
Cの次があるとしても、Cを駆逐する事にはならないだろう。

936 :デフォルトの名無しさん:2010/04/12(月) 23:37:35
CPUアーキテクチャがunixの頃から
基本的に変わってないのに変わるワケない
ポインタはレジスタそのものだから効率いい

スライスは悪くないがオーバヘッドがあるからな

937 :デフォルトの名無しさん:2010/04/12(月) 23:39:42
Dは低級言語じゃないんか?

938 :デフォルトの名無しさん:2010/04/12(月) 23:40:12
>>936
スライスは従来のポインタ演算に変換出来そうに見えるけどな。

939 :デフォルトの名無しさん:2010/04/12(月) 23:40:28
Dにインラインアセンブラってあったっけ

940 :デフォルトの名無しさん:2010/04/12(月) 23:40:44
>>935
いやかなりの部分駆逐したよ
昔はコンパイラなんて効率悪いものとされてリッチだった
今は逆にアセンブラの使用がかなり限定的になった
組込屋だが。

941 :デフォルトの名無しさん:2010/04/12(月) 23:42:31
>>937
デジマのDコンパイラとIntelのCコンパイラでそれぞれコンパイルして実行したらどっちがどれだけ速いの?

942 :デフォルトの名無しさん:2010/04/12(月) 23:42:46
>>938
オプティマイズでかなりいけそうだけど
範囲チェックとどこかで二重間接を無くせないでしょ

943 :デフォルトの名無しさん:2010/04/12(月) 23:43:45
>>ポインタはレジスタそのものだから効率いい
ん?どういう理屈だそりゃ?

944 :デフォルトの名無しさん:2010/04/12(月) 23:45:58
>>943
コンパイラの吐いたコードみたらわかるっしょ
人間が最適化の手伝いしてるようなもん
ま、ヘタが作ると逆効果だが。。

945 :デフォルトの名無しさん:2010/04/12(月) 23:48:58
で、どういう理屈なの?

946 :デフォルトの名無しさん:2010/04/12(月) 23:51:15
>>944
ごめん
さっぱり意味がわからん

947 :デフォルトの名無しさん:2010/04/12(月) 23:53:12
ヘタを語っても、語る奴がヘタでない証明にはならない。

948 :デフォルトの名無しさん:2010/04/12(月) 23:57:31
944逃げたなw

949 :デフォルトの名無しさん:2010/04/12(月) 23:58:37
ポインタってマシン語だと何が入ってるんだ?
TLBとかのアドレスになるのか?

950 :デフォルトの名無しさん:2010/04/12(月) 23:59:14
仮想アドレスだろ。

951 :デフォルトの名無しさん:2010/04/13(火) 00:05:23
コンパイラが吐くコードも見ないようなやつらが語ってたのか・・・

952 :デフォルトの名無しさん:2010/04/13(火) 00:05:44
>>940
Cも既に限定的になっていて、学習コストを支払っても限定的なリターンしか得られない
ことに不満が出てきている段階なんだろうな

953 :デフォルトの名無しさん:2010/04/13(火) 00:06:20
>>947
証明というより、信用の問題かな。
彼自身が追求されたら困る問題で他人に追求した場合、
彼自身も反撃で同じように追求されることがわかっているなら、
彼はそのリスクを恐れているだろうからその問題を抱えていないだろう、
という心理だね。

954 :デフォルトの名無しさん:2010/04/13(火) 00:08:05
>>949
gccで-sオプションつけてコンパイルしてみれば分かるよ。

955 :デフォルトの名無しさん:2010/04/13(火) 00:08:47
で、どういう理屈なの?

956 :デフォルトの名無しさん:2010/04/13(火) 00:22:55
>>1
俺は色々やることがあるからあまり関われないがWiki借りてきた。
名前決まらないから適当にL言語にしておきます。
次スレやるなら追加しておいてくれ。CAPTCHA認証だから編集はご自由に。

ttp://ldev.wiki.fc2.com/

957 :(u_・y) ◆e6.oHu1j.o :2010/04/13(火) 00:25:23
ポインタはレジスタそのものだとはつまり
Cでポインタ変数を使うと
機械語になったときにたいてい一番速度の速いレジスタに
優先的に入るみたいな事じゃねっ
通常の変数よりも速度面では僅かに優遇されているとかじゃねっ

958 :デフォルトの名無しさん:2010/04/13(火) 00:26:19
>>956
kuma-だっつってんだろ

959 :デフォルトの名無しさん:2010/04/13(火) 00:29:41
>>956
L言語は既に被ってるから却下
そしてメインで関わるつもりが無いならしゃしゃり出てくんな
Wiki管理人の座を掠め取りたいだけだろ?

960 :デフォルトの名無しさん:2010/04/13(火) 00:30:37
>>949
何と表現すれば良いか分からんが、マシン語にポインタはない
NULLってマシン語だと何が入ってるんだ?
とかと同じで、何が入ってようが、実装側の自由だし、
普通は、アドレスとインデックスでポインタを表しているが、
そんなもの、最適化次第で、決まった形なんかないし…

961 :デフォルトの名無しさん:2010/04/13(火) 00:31:53
大抵のプロセッサが備えているアドレッシング用レジスタ1個でポインタを実装できるからだろ
言葉尻の話は中身が無くてつまらんから、やめれ

962 :デフォルトの名無しさん:2010/04/13(火) 00:44:33
>>961
言葉尻の話ではなく、ポインタの本質はアドレスじゃなくて、
インデックスにあるけど、アドレスとも切り離せない(インデックスがない場合もある)から
マシン後にポインタはないって話なんだが?

963 :デフォルトの名無しさん:2010/04/13(火) 00:45:32
そういや C++のSTLライクなstyleでメモリ操作関数を実装すると、例えばこんなふうに
void fill_zero(int *begin, int *end)
{
for (int *p=begin; p!=end; ++p) { *p=0; }
}
実行プロセッサが、アドレッシング用レジスタに対する比較命令を備えてないために
ループ終了判定チェックのために、汎用レジスタへの変換命令を必要としてしまい
実行速度が遅くなる環境がありがちなんだよね

こう書き直せば速くなるんだけれど、その書き換えがあほらしい
int N=end-begin;
for (int i=0; i<N; ++i) { *p++=0; }
STLはインライン展開されるから高速と言われるが、そうとも限らない

964 :デフォルトの名無しさん:2010/04/13(火) 00:49:15
>>963
ポインタとポインタ減算は正しいとは限らない罠

965 :デフォルトの名無しさん:2010/04/13(火) 00:50:00
更に{p[i]=0;}と書いた方が最適化オプ如何に関わらず最高速だったりする環境もあるらしいし

966 :デフォルトの名無しさん:2010/04/13(火) 00:53:21
関わる気もないしトップページすら1行たりとも書き加えてないのに、次スレに追加しておいてくれだとさー

967 :デフォルトの名無しさん:2010/04/13(火) 00:58:55
>>965
確かに添字パタンの方が速い環境も多いね

968 :デフォルトの名無しさん:2010/04/13(火) 01:02:40
>>966
関わる気はないけど、成果物をどうこうする権利だけは欲しいタイプですね。

969 :デフォルトの名無しさん:2010/04/13(火) 01:08:43
つーか、アセンブラに関わる気がないと成果物を作れないわけだが
Cは嫌いだがアセンブラには関わってもよいという奴が何人いるんだろうか

970 :デフォルトの名無しさん:2010/04/13(火) 01:10:48
>>966
全く、何かやろうとするところには必ずこういう奴が現れるんだよなぁ
自分は何もしないけど権利だけ欲しいっていう奴
ほんと、リアル社会でもこういうヤツが足引っ張るんだよなぁ

971 :デフォルトの名無しさん:2010/04/13(火) 01:11:59
次スレ

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

972 :デフォルトの名無しさん:2010/04/13(火) 01:12:56
ポインタの本質はアドレスレジスタ
それ以上でも以下でもない
これがわかんないなら話にならん
86脳でもこれ位はわかんだろ

973 :デフォルトの名無しさん:2010/04/13(火) 01:29:33
>>972
何のためにポインタを加算した時のサイズが
型によって違うと思ってるの?
ポインタの本質がアドレスレジスタだと思ってるのなら、
全部void型のポインタでも使えば?

974 :デフォルトの名無しさん:2010/04/13(火) 01:31:11
お前さすがに支離滅裂

975 :デフォルトの名無しさん:2010/04/13(火) 01:34:31
>>973
それじゃアセンブラだろ?
抽象化と構造化だろ
ちゃんと歴史を勉強しな

976 :デフォルトの名無しさん:2010/04/13(火) 01:41:50
>>974-975
俺は、ポインタの本質はアドレスではなくて、
ポインタが指し示す先の型のサイズを持っていることだと思ってるんだが?
ただ>>972がアドレスが本質だと言ってるから、
そこが本質じゃない(サイズが無いと不便)と分かりやすいように
void型でも使えば?って言ってるだけだが?

977 :デフォルトの名無しさん:2010/04/13(火) 01:42:38
会話になってない

978 :デフォルトの名無しさん:2010/04/13(火) 01:44:47
本質って言葉が許せなかったんだね。
正直キモイ。

979 :デフォルトの名無しさん:2010/04/13(火) 01:45:03
アイちゃんスレに期待してどうする

980 :デフォルトの名無しさん:2010/04/13(火) 01:45:31
>>976
アドレスレジスタだよ
アドレスそのものじゃない
コンパイラだよ。もっとlow levelで考えたらいい

981 :デフォルトの名無しさん:2010/04/13(火) 01:47:27
>>977
だから、アドレスレジスタのみを指して、それがポインタの本質だって言われても
型のサイズ(ポインタに1を加算した先のアドレス)が分からなければ、意味がないって言ってるのだが?

982 :デフォルトの名無しさん:2010/04/13(火) 01:47:44
お互いの前提が違うから何言い合っても無駄。
2ちゃんてほんと不毛だな。

983 :デフォルトの名無しさん:2010/04/13(火) 01:50:48
>>978
あ、それかもな

Cが生まれたマシンは68Kの祖先を想像したらいい
アドレスレジスタを抽象化したのがポインタのはじまりだ
インデックスみたいなオフセット付が効率いいかどうかは別
今のrisc的CPUは全部バラした風だからな

984 :デフォルトの名無しさん:2010/04/13(火) 01:51:20
俺もアドレスレジスタ+インデックスレジスタが本質と言われれば大きく反論はしないが、
ポインタは、次のアドレスが分からないければポインタの意味がないよ

985 :デフォルトの名無しさん:2010/04/13(火) 01:52:59
「なんの」本質かを語らずになに言ってるんだおまえら。
ポインタの「なんの」本質かによって視点が違うのは当たり前。

986 :デフォルトの名無しさん:2010/04/13(火) 01:59:09
>>949
釣りじゃなければTLBがなにか知ってるのか?
あんな低レベルでCPU依存なもん言語でやらんわい

987 :デフォルトの名無しさん:2010/04/13(火) 02:02:41
>>984
まだわからんの
次のアドレスなんかより、
アドレスが何のデータを指してるかが大事なのよ
今後は演算出来ないポインタが流行るよ
安全じゃないからな

988 :デフォルトの名無しさん:2010/04/13(火) 02:07:29
>>987
本気で言ってるなら、ある意味尊敬する。

989 :デフォルトの名無しさん:2010/04/13(火) 02:10:04
>>985
ぶっちゃけ本質とかいわんかったら
俺もなんもいわんかった
ヒマだったからつい。
>>988
ま、精進しなよ

990 :デフォルトの名無しさん:2010/04/13(火) 02:25:48
>>960
なんか特定のCPUなのか?86?
普通はレジスタ一個だよ
インデックス用レジスタもったいない

991 :デフォルトの名無しさん:2010/04/13(火) 02:57:54
>>990
アドレスとインデックスであって
アドレスレジスタとインデックスレジスタではない
普通は、どちらが一方がレジスタで、もう一方が定数やスタックなど

992 :デフォルトの名無しさん:2010/04/13(火) 03:12:49
>>991
CPU依存の話だな
ポインタはアドレスだよ
なんでインデックス付けたら速い場合があるかわかる?


993 :デフォルトの名無しさん:2010/04/13(火) 03:30:27
分からん埋め

994 :デフォルトの名無しさん:2010/04/13(火) 03:34:21
知らん梅

995 :デフォルトの名無しさん:2010/04/13(火) 04:27:33
興味ない埋め

996 :デフォルトの名無しさん:2010/04/13(火) 04:40:49
興味ないとオプティマイザが作れない梅

997 :デフォルトの名無しさん:2010/04/13(火) 04:54:34
どうせ作らないっしょ宇目

998 :デフォルトの名無しさん:2010/04/13(火) 04:56:21
あんたが正しい雨女

999 :デフォルトの名無しさん:2010/04/13(火) 05:36:40
【超高速】C/C++に代わる低級言語を開発したい 3
http://pc12.2ch.net/test/read.cgi/tech/1271086841/

1000 :デフォルトの名無しさん:2010/04/13(火) 05:44:29
1000ならC言語大勝利

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

189 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)