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

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん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/
0002デフォルトの名無しさん2010/04/03(土) 10:46:33
結論： C++になります
0003デフォルトの名無しさん2010/04/03(土) 13:20:19
言語にあわせてCPUマイクロコードを設計しる

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

こんなもんかね？ 他にどんなの欲しい？
0005デフォルトの名無しさん2010/04/03(土) 14:27:13
デバドラ屋だって、オサレ言語で開発したい！
0006デフォルトの名無しさん2010/04/03(土) 14:27:42
OSに依存するものが多いな。
0007デフォルトの名無しさん2010/04/03(土) 14:34:00
それをうまく抽象化するのが新言語の課題だろうね。
0008デフォルトの名無しさん2010/04/03(土) 15:24:33
本当におまいらアイディア出さないな。 >1は一体どこに行った？
0009デフォルトの名無しさん2010/04/03(土) 15:42:06
これまで出てきたもののほとんどは、OSが存在しないことには実装できないか、役に立たないものばかり。
とりあえずC99の機能を今流の文法にしたらどうなるかを考えてみたら。
0010デフォルトの名無しさん2010/04/03(土) 15:42:47
　C/C++は古い────→　最新のオサレな言語・技術で
　　　↑　　　　　　　　　　　　　 「低レベル」なことしたい
　　　│　　　　　　　　　　　　　　　　　　　│
　　　│　　　　　　　　　　　　　　　　　　　↓
　　　│　　　　　　　　　　　　 でも、最新のオサレな言語・技術って、
結局、C/C++だよ←─── OSに依存すること多くね？
　　　　　　　　　　　　　　　　　OSより 「低レベル」なこと出来なくね？
0011デフォルトの名無しさん2010/04/03(土) 16:06:12
同じ話の繰り返しにしかならないから
このスレ落とせ
0012デフォルトの名無しさん2010/04/03(土) 16:14:44
>9
>4 みたいなのはどうなのよ。OSに依存するのは実行制御以下ぐらいじゃね？
それともこの話についていけてない？
0013デフォルトの名無しさん2010/04/03(土) 16:17:36
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0014デフォルトの名無しさん2010/04/03(土) 16:25:22
>>12
OSがなかったら、ヒープすらないことに気付けよ。
0015デフォルトの名無しさん2010/04/03(土) 16:28:44
と思ったら、そうでもないものが並んでいた。テンプレートはあってもいいが、プリミティブ型しかないならあまり役に立たない。
0016デフォルトの名無しさん2010/04/03(土) 19:40:00
クラスに相当する機能位は欲しいな。
0017デフォルトの名無しさん2010/04/03(土) 20:20:49
C++0xをブラッシュアップするだけでおｋ
0018デフォルトの名無しさん2010/04/03(土) 22:05:05
で、どのように？
0019デフォルトの名無しさん2010/04/03(土) 22:46:26
正規表現もファーストクラスで使えるように構文は用意したい
0020デフォルトの名無しさん2010/04/03(土) 22:49:48
ビジネスクラスで十分
0021デフォルトの名無しさん2010/04/03(土) 22:52:47
つまり、より広く使いたいと言うことだな
0022デフォルトの名無しさん2010/04/03(土) 22:54:26
どう見てもこのスレはVIP
0023デフォルトの名無しさん2010/04/03(土) 23:04:18
低級言語にポインタは必須だな。
機種依存も必須。
でもjavaみたいに間違いが起こりにくい仕組みは欲しい。
0024デフォルトの名無しさん2010/04/03(土) 23:16:51
新スレ必要だったのか
0025デフォルトの名無しさん2010/04/03(土) 23:28:01
ポインタより便利にアドレスを直接操作できるやり方ってあるのかな。
0026デフォルトの名無しさん2010/04/03(土) 23:34:16
新スレまでいったのか。
いくら夢を語っても、どうせ現物はできないし、むなしくなるだけなのにな。
0027デフォルトの名無しさん2010/04/03(土) 23:36:38
夢のない男の人って情けない。絶対に結婚したくないタイプ
0028デフォルトの名無しさん2010/04/04(日) 00:01:48
これについてお前らの考察を聞かせてくれ

JavaとC++のパフォーマンスを比較する
http://japan.internet.com/developer/20100402/26.html
0029デフォルトの名無しさん2010/04/04(日) 00:03:53
すばらしい
0030デフォルトの名無しさん2010/04/04(日) 00:11:24
>>28
最適化のことを「条件付き」という筆者はバカ。
0031デフォルトの名無しさん2010/04/04(日) 00:20:37
最適化できないプログラミング言語はダメだな
0032デフォルトの名無しさん2010/04/04(日) 00:23:38
10年以上まえ、バブルソートをCとJavaで書いて時間を計ったら、
最適化なしなら大差なしで、最適化ありならCが倍くらい速かった。

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

一般的なアプリのコードだと、Javaは文字列も粒度の小さいクラス(構造体)
も全部ヒープに置かないといけないんで、どうがんばってもC++に
かなわないような気がする。
0033デフォルトの名無しさん2010/04/04(日) 00:32:40
C++「ちくしょーちくしょー！　最適化……　最適化さえすればー！」
JAVA「……おい、お前の言う最適化とやらは、そんなにすごいのか？」
C++「そうだ、最適化さえすればお前などに……」
JAVA「ほう、本当に速くなるんだな？」
C++「そうだ、最適化さえすればお前などに……」
JAVA「…………」
C++「ちくしょーちくしょー！　最適化……最適化さえすればー！」
ﾄﾗﾝｸｽ「……いったい何を話してるんだ？」
C++「ちくしょーちくしょー！　最適化……最適化さえすればー！」
JAVA「おい、やってみろよ。最適化を」
C++「なんだと！？」
ナレーション「いったい、どうなってしまうのか！？」
0034デフォルトの名無しさん2010/04/04(日) 00:38:54
-O6
0035デフォルトの名無しさん2010/04/04(日) 00:42:10
sseインラインアセンブラだと数倍差つくよね
0036デフォルトの名無しさん2010/04/04(日) 00:48:16
最適化は”する”のが当然であって、しない状態とパフォーマンスの比較するるなんて全くナンセンス
0037デフォルトの名無しさん2010/04/04(日) 01:17:15
>>33
逆だろｗ

JAVA「ちくしょーちくしょー！　最適化……　最適化さえすればー！」
C++「……いや、最適化なんて普通だし」
JAVA「そうだ、最適化さえすればお前などに……」
C++「やればいいじゃん」
JAVA「そうだ、最適化さえすればお前などに……」
C++「…………」
JAVA「ちくしょーちくしょー！　最適化……最適化さえすればー！」
ﾄﾗﾝｸｽ「……いったい何を話してるんだ？」
JAVA「ちくしょーちくしょー！　最適化……最適化さえすればー！」
C++「だからやればいいじゃん、最適化を」
JAVA「なんだと！？」
ナレーション「いったい、どうなってしまうのか！？」
0038デフォルトの名無しさん2010/04/04(日) 01:25:38
javaも最適化してないわけがないから、やっぱ、

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

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

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

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

Javaではネイティブコードで速くなるようには書けない。だから遅い。
0040デフォルトの名無しさん2010/04/04(日) 02:31:33
ほっとけばVMが最適化されて速くなると妄想できるだけでJAVAキチにとっては十分なんだよ
0041デフォルトの名無しさん2010/04/04(日) 02:37:04
>>39
その理屈はおかしい。
・C++のコード→ネイティブのアセンブラ
で、速い最適化が可能なら、
・JavaVMのコード→ネイティブのマシン語
の変換中の最適化でも速い最適化ができない理由がない
0042デフォルトの名無しさん2010/04/04(日) 02:38:37
理由がないのに遅いってことは、Sunの技術者はどうしようもない無能ってことだな。
0043デフォルトの名無しさん2010/04/04(日) 02:41:26
無能だからSunなんかに入っちゃうんだろｗｗｗ
0044デフォルトの名無しさん2010/04/04(日) 02:41:26
>>42
いや、>>39の考察が間違ってるってことだろ。
0045デフォルトの名無しさん2010/04/04(日) 02:42:11
で、どう間違ってるのかは述べないんだ。
0046デフォルトの名無しさん2010/04/04(日) 02:43:30
>>44
むしろ、>>42が>>41の考察が間違ってることを証明している。
0047デフォルトの名無しさん2010/04/04(日) 02:44:48
>>45
>>39 が間違ってる理由は >>41 で述べたよ。
Javaが遅い理由は >>39 の考察した理由以外のところであるってことだけど、
それはしらない。
0048デフォルトの名無しさん2010/04/04(日) 02:45:25
>>41はネイディブにすれば何でも速くなると思ってるマヌケ
0049デフォルトの名無しさん2010/04/04(日) 02:48:37
>>41 が正しいというなら、C++がほかの言語(vmのコードも含めて)に比べて
最適化がしやすい理由が無ければならないけど、そんなことは無いから、
>>41 は完全に間違ってる。
Javaが遅い理由はほかに求めるべき。
0050デフォルトの名無しさん2010/04/04(日) 02:49:51
>>49 のアンカー間違えたよ。>>39だった。
0051デフォルトの名無しさん2010/04/04(日) 02:50:37
>>49
> >>41 は完全に間違ってる。

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

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


0053デフォルトの名無しさん2010/04/04(日) 02:58:09
JavaがC++と同程度にネイティブコードに最適化しやすいのであれば、最適化コードを生成できないSunの技術者はどうしようもない無能。
Sunの技術者がどうしようもない無能でないならば、JavaはC++と同程度にはネイティブコードに最適化できないクズ言語。
0054デフォルトの名無しさん2010/04/04(日) 03:05:03
まあ、ポインターが使えるってだけでもJavaよりC++の方が最適化しやすいわな。
GC任せのメモリ管理をネイティブコードに最適化しようにも、そりゃオーバーヘッドが当然大きくなる。

「ネイティブコードにしたからって速くなるわけじゃない」ってのに噛み付くって、どんだけド素人なんだよｗ
0055デフォルトの名無しさん2010/04/04(日) 03:13:05
Javaなんてクソ言語どうでもいいよ　┐(´д｀)┌ﾔﾚﾔﾚ

新言語の話しようぜ！
0056デフォルトの名無しさん2010/04/04(日) 03:15:33
バカばっか
JAVAが遅いのはお前らみたいなタコがタココード書いても危険にならんようお仕着せ機能がてんこ盛りなだけで
JAVAが実際やってる事を機能的になぞるC++コードを書いたら同程度に遅くなるっつの
何がネイティブコードなら速いだよバカすぎ
0057デフォルトの名無しさん2010/04/04(日) 03:17:21
>>53
Sunが無能って可能性もあるな。
C++でも、コンパイラによって最適化の性能が違うし、昔はJavaコンパイラ&VMの
性能差も各メーカー間でどうこうって話題があったしな。

ま、どっちにしろ>>39の考察は間違ってるってことで。
0058デフォルトの名無しさん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　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶
0059デフォルトの名無しさん2010/04/04(日) 03:23:19
>>56
話題についてこれない人は、入ってこなくていいって。

その理屈だと >>28 のような、単純なループや数値計算だけの
コードでJavaが遅い理由がわからない。
0060デフォルトの名無しさん2010/04/04(日) 03:23:49
最後の捨て台詞で>>57の引込みがメデタクついたので、新言語の話題再開。
0061デフォルトの名無しさん2010/04/04(日) 03:25:14
だれも>>59の俺理論にはついていけねーわｗ
0062デフォルトの名無しさん2010/04/04(日) 03:26:46
>>58
いや、お前の中以外では、そうなんだよ。
0063デフォルトの名無しさん2010/04/04(日) 03:27:07
>>59さん、僕たちを置いていかないでｗｗｗｗｗｗｗｗ
0064デフォルトの名無しさん2010/04/04(日) 03:27:29
>>59
話題についてこれてないのはお前だよｗｗ
0065デフォルトの名無しさん2010/04/04(日) 03:29:50
>>61
そういう理論っていうか、そういう話だもん。
どうせ、レスを2,3見て、話を把握せずに適当に「バカばっか」とか
中学生みたいなこと言いたくなったんでしょ?
>>56 は。
0066デフォルトの名無しさん2010/04/04(日) 03:31:31
>>60
捨てゼリフっていうか、論点が>>39が間違ってるってことだったのに
関係ない話にすりかえてごまかそうとしてたから、とりあえずまとめてみたの。
0067デフォルトの名無しさん2010/04/04(日) 03:32:14
なんか、痛々しい奴がいるなｗ
0068デフォルトの名無しさん2010/04/04(日) 03:34:05
>>64
いや、>>28 のような単純なコードでなぜJavaが遅いかって話題でしょ?
それを安全な言語だから遅いとかツッコミ入れてるほうが、ぜんぜん話に
ついてこれてないよ。
とりあえず一行レスしとけばごまかせるとか思うのは卒業したほうがいいよ。
0069デフォルトの名無しさん2010/04/04(日) 03:37:20
どうしても>>39が間違っていることにしたいようだが、そもそも>>41は>>39への反論になっていないし。
「ネイティブにすれば何でも速くなる」と思ってる時点で全然論理が成り立ってないんだよ。
0070デフォルトの名無しさん2010/04/04(日) 03:46:42
>>68
バッカじゃねぇの？
マジ、バッカじゃねぇの？
どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ
何故遅いかだと？遅いに決まってんだろ

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

お前の主張が「単純なソースなのに何故チェック機構を無効化しないのか分からない」と言う物なら
もう死んだ方がいいレベル
0071デフォルトの名無しさん2010/04/04(日) 03:47:31
恐らく>>68は死んだ方がいい
0072デフォルトの名無しさん2010/04/04(日) 03:48:01
ここまで新言語の話題なし
0073デフォルトの名無しさん2010/04/04(日) 03:49:43
Javaプログラマーはネイティブコードに夢を抱きすぎだろｗ
ネイティブコードにしたからってそう簡単には速くはならんのだよｗ

英語ができれば俺だって国際的に活躍する一流の技術者になれるんだ、とか言ってるIT土方と一緒。
英語が話せたところでお前は一生底辺なんだよｗｗｗ
0074デフォルトの名無しさん2010/04/04(日) 03:53:48
>>69
だから言ってるじゃん。
それって >>28 のような単純なループとか数値演算ではどうなのよって。
都合の悪いことは見えないふりするんだな。
0075デフォルトの名無しさん2010/04/04(日) 03:57:21
>>74 のつづき

単純なループでも、配列のチェックとかオーバーフローのチェックとか
あるだろとか、最低限の技術的な突っ込みがあるだろうって思ってたのに、
そういうのは一切なしで、都合の悪いことは見えないふりで、ひたすら
見当違いのあおりとか、人格攻撃に終始して勝利宣言な。
ほんとうにどうしようもない連中だな。
0076デフォルトの名無しさん2010/04/04(日) 04:01:15
型チェック境界チェックオーバー/アンダーフローチェック配列はオブジェクト
トーシロでもJAVAではこれ位やってるって事はわかる
で、これらと全く同じ要件をネイティブコード(笑)で書けば速いのか？
0077デフォルトの名無しさん2010/04/04(日) 04:01:45
>>70
> バッカじゃねぇの？
> マジ、バッカじゃねぇの？
> どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ

本当に気にさわったみたいだな。
しかし、この「自分の都合の悪いことはスルー」のスルー力がすごすぎる。
指摘はひたすら無視して、
＞は正しい
で反論したつもりになってるんだもんな。
0078デフォルトの名無しさん2010/04/04(日) 04:05:56
>>76
>>75 で指摘されてやっと最低限の指摘がでてきた。

ループが固定回なら、配列のチェックなんて最適化できるだろ。
0079デフォルトの名無しさん2010/04/04(日) 04:06:42
>>78
バカかお前
>>76は被っただけで75なんて読んでねぇよ
0080デフォルトの名無しさん2010/04/04(日) 04:08:50
>>78
特大のバカ発言現る
実行時にその参照が固定配列を指してる保証がどこにある
0081デフォルトの名無しさん2010/04/04(日) 04:09:15
>>79
そんなのわかってて煽っただけだよ。
0082デフォルトの名無しさん2010/04/04(日) 04:10:38
>>78でコイツの器のミニマムさがこれ以上無いほど晒されたなｗｗｗ
0083デフォルトの名無しさん2010/04/04(日) 04:11:43
>>81
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿と言う認識で宜しいか。
0084デフォルトの名無しさん2010/04/04(日) 04:22:03
オブジェクト指向だから遅い
クラス階層が広くて深いから遅い
仮想関数使うから遅い
ガベージコレクションするから遅い
ヴァーチャルマシンをはさむから遅い
実行時の動的型決定を使うから遅い
短い関数を沢山書くから遅い
毎回毎回いちいち動的にメモリ確保するから遅い
なんでも実行時に決定させる設計だと遅い
goto使わせないから遅い
アセンブラを使わせないから遅い
ポインタを使わせないから遅い
モノリシックに書かないから遅い
移植性を考えるから遅い
0085デフォルトの名無しさん2010/04/04(日) 04:35:01
>>82
また技術的な指摘なしで、人格攻撃かよ。

動的言語のエディタでさえ、編集中の変数にどのインスタンスが
入れられたか見えてればインテリセンス聞かせられるのに、
宣言が見えてる配列の最適化なんて聞かせられない道理がないだろ。
0086デフォルトの名無しさん2010/04/04(日) 04:38:21
>>83
いや、>>76を見た瞬間は
「俺の指摘をまんまオウム返しにしてきた、こいつバカだろ」って思ったけど
いくらなんでも、それはバカ過ぎるから、またレスもろくに読まずに
反論してるんだなって、優しく解釈してあげた。
でも、すごい必死で面白いから、知らない振りして煽ってみた。
0087デフォルトの名無しさん2010/04/04(日) 04:42:08
>>78>>85
リフレクションのリの字も知らない低レベラー乙
0088デフォルトの名無しさん2010/04/04(日) 04:44:38
>>87
int tbl = new int[100];
tbl[0] = 0;

これのどこにリフレクションを考慮する余地があるんですか?
0089デフォルトの名無しさん2010/04/04(日) 04:44:58
>>86
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿という訳だな。
なぜ「いや」から始めたのかが意味不明だが。
0090デフォルトの名無しさん2010/04/04(日) 04:48:06
>>89
煽ったのは、お前のドジなところだから本題には関係ない。
そのくらい分かれよ。
とにかく揚げ足をとりたくてしかたないんだな。
0091デフォルトの名無しさん2010/04/04(日) 04:48:27
もういいだろ
Javaを知らない馬鹿が、Javaを知らない振りをして低レベルスレに相応しい低レベルな煽りをしてるだけの話だ
0092デフォルトの名無しさん2010/04/04(日) 04:52:36
>>90
どこをドジと言ってるんだ？素でわからん。
0093デフォルトの名無しさん2010/04/04(日) 04:52:49
>>91
また人格攻撃がはじまった。
まあ、本題のほうは反論の余地がなくなったってことですね。
>>39 は間違ってるって結論で終了ってことで。
0094デフォルトの名無しさん2010/04/04(日) 05:00:10
>>93
お前さんが無知すぎてもはや反論の余地が無いｗｗｗｗ
0095デフォルトの名無しさん2010/04/04(日) 05:07:09
>>94
どこか無知か一つも指摘できないで、脳内で無知ってことにして煽る。
そういうのってむなしくないっすか?


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

Javaで調べるんは面倒だからやらない。
0096デフォルトの名無しさん2010/04/04(日) 05:37:59
LL言語とC/C++の速度比較とかありえない
どこの初心者だよ
0097デフォルトの名無しさん2010/04/04(日) 10:22:36
>>95
そういう最適化はJITコンパイル時に行われるんじゃないの
0098デフォルトの名無しさん2010/04/04(日) 10:23:06
そろそろ新言語の話しようぜ
0099デフォルトの名無しさん2010/04/04(日) 11:04:25
まず名前からきめようか
0100デフォルトの名無しさん2010/04/04(日) 11:07:00
GOがあるじゃないか
0101デフォルトの名無しさん2010/04/04(日) 11:13:19
Goは、Cの代わりにならない。
0102デフォルトの名無しさん2010/04/04(日) 11:36:00
>>84
オブジェクト指向だから遅い → NO
クラス階層が広くて深いから遅い → NO
仮想関数使うから遅い → Yes（NOにできるかな？）
ガベージコレクションするから遅い → Yes
ヴァーチャルマシンをはさむから遅い → Yes
実行時の動的型決定を使うから遅い → Yes（NOにできるかな？）
短い関数を沢山書くから遅い → NO
毎回毎回いちいち動的にメモリ確保するから遅い → Yes（ただし、そうする必要もない）
なんでも実行時に決定させる設計だと遅い → NO
goto使わせないから遅い → NO
アセンブラを使わせないから遅い → NO
ポインタを使わせないから遅い → NO
モノリシックに書かないから遅い → NO
移植性を考えるから遅い → NO
0103デフォルトの名無しさん2010/04/04(日) 12:00:42
Goは早くも下火になった
新物だったので一時的に話題を集めただけ
今ではD言語にも満たない
0104デフォルトの名無しさん2010/04/04(日) 12:04:16
>>32
Javaもエスケープ解析を有効にしたらスタックにオブジェクトをおけるんだけど、
エスケープ解析ってコンパイル時にできるものなのにクラスロード時にしちゃうから、
今度は起動速度に悪影響があるんだよなぁ。
0105デフォルトの名無しさん2010/04/04(日) 12:22:48
FORTRANにオブジェクト指向取り入れれば
0106デフォルトの名無しさん2010/04/04(日) 12:29:48
>>105
確かとっくに取り入れられてなかったか？

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

Fortran2003で取り入れられているようだ
0107デフォルトの名無しさん2010/04/04(日) 12:35:39
じゃあ言語名はF++0xで
0108デフォルトの名無しさん2010/04/04(日) 13:25:53
そういやおまいらの中でドラゴン本タイガー本中田本読んだのってどれぐらいいるの？
あとC++の設計を語るのならD&EとかARMとかも読んでいると思うけど、そのへんもどうなの？
0109デフォルトの名無しさん2010/04/04(日) 13:50:34
読んでねーだろこんなアイちゃんスレに書き込む輩は
0110デフォルトの名無しさん2010/04/04(日) 13:51:16
>>98
ラブプラス++
0111デフォルトの名無しさん2010/04/04(日) 14:18:28
O+++
0112デフォルトの名無しさん2010/04/04(日) 15:23:43
>>108
全員読んでる。当たり前だろ。
0113デフォルトの名無しさん2010/04/04(日) 15:32:38
>>108
常識
0114デフォルトの名無しさん2010/04/04(日) 16:18:46
>>99
「small」

プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
できるだけ小さな言語仕様にしたい。
0115デフォルトの名無しさん2010/04/04(日) 16:35:45
>プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
そんなコンセプトじゃ無いだろ。
第一、言語仕様が小さいからといってヒューマンエラーが減るわけじゃない。
もしそうだとしたらForth最強じゃないか。
0116デフォルトの名無しさん2010/04/04(日) 16:38:18
Forthはインタプリタの実装までを含めて仕様みたいなもんだから、
見た目ほど仕様が小さいわけでもないけどな。
0117デフォルトの名無しさん2010/04/04(日) 16:39:56
>>115
> そんなコンセプトじゃ無いだろ。

じゃあ、どんなコンセプトなんだ？否定する前に意見を述べよう。
0118デフォルトの名無しさん2010/04/04(日) 16:49:12
Cにとって代わるというのがコンセプトだろ。
0119デフォルトの名無しさん2010/04/04(日) 16:51:52
Cにとって代わるのに加えて、
「プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
できるだけ小さな言語仕様にしたい。」
という提案だろ？
0120デフォルトの名無しさん2010/04/04(日) 17:02:05
>>119
言語仕様が小さくなったら、ヒューマンエラーは増えると思うが。
0121デフォルトの名無しさん2010/04/04(日) 17:03:07
えっ
0122デフォルトの名無しさん2010/04/04(日) 17:04:18
思うのは自由だ。
0123デフォルトの名無しさん2010/04/04(日) 17:20:02
>>120
言語仕様が小さい方が、言語仕様を知らないことによる人間の失敗は少なくなるよね？
人間の記憶容量は有限だから。
0124デフォルトの名無しさん2010/04/04(日) 17:32:30
たとえば、C言語でオブジェクト指向っぽいことをやろうとした時の煩雑さとかどうよ。

言語の支援があったほうがよい機能を全部ユーザーがやるというのは無理がある。
0125デフォルトの名無しさん2010/04/04(日) 17:34:38
直感的で一貫性のある仕様がいいね。
0126デフォルトの名無しさん2010/04/04(日) 18:04:48
教育用言語なら、再帰がない方が失敗が少なくなると言えなくもない。
0127デフォルトの名無しさん2010/04/04(日) 18:12:44
再帰なんて、単に呼び出す関数がたまたま自分であったと言うだけであって、全く特別なものではない。
それを阻害するような例外（「ただし、自身を呼び出してはいけない」等）を仕様に付け加える方が混乱のもと。有害。

そんな例外は、仕様に絶対に含めるべきではない。
0128デフォルトの名無しさん2010/04/04(日) 18:19:14
>>127
auto変数とかいう特別な変数がある
0129デフォルトの名無しさん2010/04/04(日) 18:26:51
どう特別？スタックに乗るだけでは？
0130デフォルトの名無しさん2010/04/04(日) 18:31:10
変数のためにわざわざスタックを使うのは、再帰があるからだよ
再帰が無いならすべてstaticかグローバル変数でOK
0131デフォルトの名無しさん2010/04/04(日) 18:33:48
スタックを使わず、「staticかグローバル変数」にした場合のメリットは？
0132デフォルトの名無しさん2010/04/04(日) 18:36:06
>>131
超高速。
0133デフォルトの名無しさん2010/04/04(日) 18:36:58
>>132
どういう理由で？
0134デフォルトの名無しさん2010/04/04(日) 18:56:59
「staticかグローバル変数」にしたら関数の外からでも参照できて危ないとしか思えんのだが
0135デフォルトの名無しさん2010/04/04(日) 19:02:02
スタックポインタに足し算するのに何百クロックもかかる変なマシンを使ってる人が
ここにも登場w グローバル変数は速いと言い張るバカwwwwww
0136デフォルトの名無しさん2010/04/04(日) 19:03:57
古い言語ではローカル変数をスタックに取ったりはしない。
0137デフォルトの名無しさん2010/04/04(日) 19:04:40
>>134
関数の中でもstaticつかえるよ
0138デフォルトの名無しさん2010/04/04(日) 19:05:05
で？
0139デフォルトの名無しさん2010/04/04(日) 19:06:59
関数の中のstaticと関数の外のstaticは全く別の物だからな。
同じキーワードを使いまわしてるのは、ほとんど設計ミス。
0140デフォルトの名無しさん2010/04/04(日) 19:07:44
>>123
ヒーマンエラーを減らすためにいろいろな機構があるのに。
0141デフォルトの名無しさん2010/04/04(日) 19:08:26
グローバル変数が高速wwwwwww
0142デフォルトの名無しさん2010/04/04(日) 19:16:52
静的に一度だけ確保され初期化がされるstaticと、
静的にメモリに配置されアプリケーション終了まで変わらないstatic？

ってあれ？グローバルに置かれた変数の方の staticって、
そうでない物と何が違うの？
0143デフォルトの名無しさん2010/04/04(日) 19:20:48
>>140
その機構が、直感的で一貫性があればいいけどね。
特殊な例外の積み重ねで、プログラマーが勘違いすると、プログラマーの意図と違う結果になるのは避けたい。
0144デフォルトの名無しさん2010/04/04(日) 19:25:34
>>142
名前空間がファイル単位になるんじゃなかったっけ
0145デフォルトの名無しさん2010/04/04(日) 19:34:18
たぶんそれは名前空間じゃなくてスコープだと思う。
0146デフォルトの名無しさん2010/04/04(日) 19:34:53
すまん、無名名前空間の話とごっちゃにしてた
0147デフォルトの名無しさん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 はエラー
0148デフォルトの名無しさん2010/04/04(日) 19:44:35
>>147
初心者スレでやれ
0149デフォルトの名無しさん2010/04/04(日) 19:53:39
まぁ初心者云々はともかくC++におけるstaticの多義性が
>>143の「特殊な例外の積み重ね」であることは間違いないなw
0150デフォルトの名無しさん2010/04/04(日) 20:18:23
そもそもCPUが何してるか知らない奴多くね？
0151デフォルトの名無しさん2010/04/04(日) 20:33:28
論理回路の知識がなくてもプログラミングに差し支えはないだろ。
差し支えるようなプログラミング言語というのもあるかもしれんが。
0152デフォルトの名無しさん2010/04/04(日) 20:53:19
仕事する上ではそれほど必要ないかもしれんが
低級言語作りたいって言うんだったら必要だろう
0153デフォルトの名無しさん2010/04/04(日) 20:58:10
>>150
なぜそう思ったの？
0154デフォルトの名無しさん2010/04/04(日) 21:00:13
Javaでプログラミングするとしても、パフォーマンスを考えるためにある程度の知識は必要だろ。
0155デフォルトの名無しさん2010/04/04(日) 21:05:47
>>153
自分がCPUが何をしているか知らないから、それを知っていることが凄いとでも思っちゃったんじゃないの。
0156デフォルトの名無しさん2010/04/04(日) 21:10:17
vbプログラマとかCPUのことよくわかってないの多いぞ
0157デフォルトの名無しさん2010/04/04(日) 21:10:40
そんなに必要な機能があるなら、C99に取り込まれているだろう。
0158デフォルトの名無しさん2010/04/04(日) 21:15:58
>>156
お前がそういうコミュニティーに属しているというだけだ
0159デフォルトの名無しさん2010/04/04(日) 21:27:08
この流れじゃ、例えPart 3まで行っても何も決まらないだろうな
0160デフォルトの名無しさん2010/04/04(日) 21:39:55
新言語とかどうでも良くてJAVAを叩ければそれで満足なカスが多すぎる
0161デフォルトの名無しさん2010/04/04(日) 21:40:53
それって、Part3までに決めろよってことだろｗ
おまえ、ワクワクし過ぎｗ
0162デフォルトの名無しさん2010/04/04(日) 21:42:18
は？
0163デフォルトの名無しさん2010/04/04(日) 21:43:18
>>160
Javaなんて別に叩くほどの言語でも無いだろ。どうでもいい。
0164デフォルトの名無しさん2010/04/04(日) 21:58:22
Javaは使えない言語だが貶すほどでもない
0165デフォルトの名無しさん2010/04/04(日) 22:01:06
言い方を変えるか
とにかく何でも叩きたいだけの生産力絶無のカスが多すぎる
0166デフォルトの名無しさん2010/04/04(日) 22:02:56
普及している言語をカスといっているヤツは、その理由がわかっていないカスだから相手にしなくていい。
0167デフォルトの名無しさん2010/04/04(日) 22:09:45
歴史的理由にすぎない
とかいっているヤツはどうする
0168デフォルトの名無しさん2010/04/04(日) 22:17:08
どうでもいい。
0169デフォルトの名無しさん2010/04/04(日) 22:59:43
CPUどころか、OSが何してるのか知らない奴が多い。
0170デフォルトの名無しさん2010/04/04(日) 23:00:21
>>169
なぜそう思ったの？
0171デフォルトの名無しさん2010/04/04(日) 23:01:34
>>169がそういうコミュニティーに属してるんだろｗ
0172デフォルトの名無しさん2010/04/04(日) 23:09:09
>>1
TMPできるようにして
0173デフォルトの名無しさん2010/04/04(日) 23:16:07
世間一般はＧＵＩの出来でＯＳの評価してるからな
0174デフォルトの名無しさん2010/04/04(日) 23:21:07
OSどころか、コンパイラが何してるのか知らない奴が多い。
0175デフォルトの名無しさん2010/04/04(日) 23:27:35
そりゃ利用者はコンパイラのことなんか知る必要ないからな。
0176デフォルトの名無しさん2010/04/04(日) 23:32:15
>>174
なぜそう思ったの？
0177デフォルトの名無しさん2010/04/04(日) 23:36:39
ネイティブじゃないからと中間言語を批判しているやつは、コンパイラがなにやっているかわかっていないような気がする。
0178デフォルトの名無しさん2010/04/04(日) 23:38:01
気がするのは自由だよ。
0179デフォルトの名無しさん2010/04/04(日) 23:40:43
断定するのも自由だ
0180デフォルトの名無しさん2010/04/04(日) 23:41:53
ということで、新言語の話をどうぞ。
0181デフォルトの名無しさん2010/04/04(日) 23:53:44
お前らホントに>108読んでるのか？

Javaにこだわるやつらは何考えているんだ？
低レベルなシステム開発向け言語というんだったらForthとかPIRとかRTLとかがターゲットじゃないの？
0182デフォルトの名無しさん2010/04/04(日) 23:56:34
PIR、RTLって何？
0183デフォルトの名無しさん2010/04/04(日) 23:58:41
>>181
スレタイ嫁
0184デフォルトの名無しさん2010/04/05(月) 00:02:18
Java bytecodeやCILに代わるものをやるわけではない
0185デフォルトの名無しさん2010/04/05(月) 00:05:01
PIR: Parrot intermediate representation
Parrotで使っている中間言語
RTL: Register Transfer Language
GCCで使っている中間言語

さすがにそこまでいくと凄いことになるな。
0186デフォルトの名無しさん2010/04/05(月) 00:07:11
プログラマーが三人集まると何も決まらないというのは本当ですな。
先ずは音頭を取るやつがいないと。誰か一人コテつけて幹事を名乗り出るんだ。
0187デフォルトの名無しさん2010/04/05(月) 00:07:41
ここで開発する言語のコンパイラがRTL吐くってことだよね？

RTLに代わるものを作るわけじゃない。
0188デフォルトの名無しさん2010/04/05(月) 00:16:14
よし、じゃあ何か作ろうぜ。
まず、


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



0189デフォルトの名無しさん2010/04/05(月) 00:19:46
DはC++と異なり、Cとのソースコード互換性を棄ててるから、レガシー排除したC++にあたる。
Cに代わるものは、Dのサブセットから構成できるのではないか。
0190デフォルトの名無しさん2010/04/05(月) 00:22:58
>>189
具体的にサブセットに含まれる機能を提示してもらえると議論しやすい
0191デフォルトの名無しさん2010/04/05(月) 00:24:31
このさい、基本データ型からきめようよ
0192デフォルトの名無しさん2010/04/05(月) 00:44:51
>>189
互換性を捨てたものが普及した試しなんてあるの？Dは互換性捨てたから駄目なんだね。
0193デフォルトの名無しさん2010/04/05(月) 00:47:36
C自体もそれ以前と互換性がないわけだが
0194デフォルトの名無しさん2010/04/05(月) 01:41:17
ここの奴らは前スレ埋める事すらしないゴミクズばっかだなｗ
0195デフォルトの名無しさん2010/04/05(月) 01:57:30
基本データ型はbyteのみ
0196デフォルトの名無しさん2010/04/05(月) 14:07:29
最近じゃエンディアンすらしらねえクズが仕事してるしな

ところでポインタがないから最適化できねえとか本気で書いてんのか
アホすぎ
0197デフォルトの名無しさん2010/04/05(月) 14:35:26
いまエンディアンを知る必要性なんてほとんどないだろ
昔は通信時なんかで考慮必要だった時もあったけどな
0198デフォルトの名無しさん2010/04/05(月) 14:40:06
プログラム組む上で気にしなくてもいいけど知っとくべきだとは思うな
0199デフォルトの名無しさん2010/04/05(月) 14:42:08
何らかのバイナリファイル読む場面なんて普通にあるから
エンディアンくらい普通の常識として知っとくべき。
>>197 は多分高級言語しか触らないか、テキストファイルくらいしか触らない奴と推測
0200デフォルトの名無しさん2010/04/05(月) 14:48:54
>>199
アセンブラも書くよ
インラインでだけど
0201デフォルトの名無しさん2010/04/05(月) 14:50:13
フレームワーク弄ってる分には必要のない知識なのは確かだ。
0202デフォルトの名無しさん2010/04/05(月) 14:55:48
ここ低級な言語のスレだよな？
ま、俺は組み込み屋だからエンディアンは関係あり
0203デフォルトの名無しさん2010/04/05(月) 18:42:54
>>188
void (far *func)();
*(unsigned long *)&func = 0xffff0000L;
func();
}
0204デフォルトの名無しさん2010/04/05(月) 18:55:32
もうね、farとか見ただけで飯が鼻から出そうです
0205デフォルトの名無しさん2010/04/05(月) 19:28:40
nearとかfar二度と見たくね('A`)
でも大半はsmallモデルで動いていたんだよなああの頃は
0206デフォルトの名無しさん2010/04/05(月) 19:29:58
あれなんでageになってんだ
0207デフォルトの名無しさん2010/04/05(月) 19:32:51
俺はずっと68kとかRISCが多かったから
あんまx86マシンコードの洗礼受けてないけど
見るたびに悪貨は良貨を...ってのを思い出してた。
今やスパコンを構成する位だもんな
思えば遠くへ来たもんだ
0208デフォルトの名無しさん2010/04/05(月) 19:47:15
x86は怒濤のクロックアップ戦争があったからね
これに唯一勝ち残ったPowerPCだけがRISCとして活躍している
ARMは低消費電力の観点から別の路線を歩いているし
0209デフォルトの名無しさん2010/04/05(月) 20:32:39
>>208
なぜ現存CPUコアアーキテクチャで最大勢力のMIPSに言及しないんだ？
0210デフォルトの名無しさん2010/04/05(月) 20:46:29
MIPSか
最大勢力という程でもないだろ
ARMの方がよほど多い
0211デフォルトの名無しさん2010/04/05(月) 20:50:15
腕っ節でねじりふせたと言う事か。　ARMだけに



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

ARMは電池で動くのでゲーム機とか携帯電話に多量に使われている
0213デフォルトの名無しさん2010/04/05(月) 21:38:23
ppcは高いんだよ
0214デフォルトの名無しさん2010/04/05(月) 21:41:43
需要供給の法則か
まあx86は性能の割りには確かに安い
0215デフォルトの名無しさん2010/04/05(月) 21:43:51
あとx86のソフトの豊富さを忘れちゃいけないな
FreeBSDがなければ2chも存在しなかったかもしれん
0216デフォルトの名無しさん2010/04/05(月) 21:44:08
>>214
あーarmとかmipsと比べたら。
x86は性能以前に高すぎ
0217デフォルトの名無しさん2010/04/05(月) 21:46:40
>>216
そうか
売れるから高くしても売れるってわけか
これでもまだ安くなってるんだぜ
AMDがなかったらもっとバカ高くなってるぞ
0218デフォルトの名無しさん2010/04/05(月) 22:07:43
しかしx86の機械語は何回見ても汚いな
C/C++をコンパイルしたリストを眺めて「ゲロ～こんなんで
よく動いてるな」といつも思うぜ
0219デフォルトの名無しさん2010/04/05(月) 22:18:20
８６系は美しくないから、６８００系、次はRISCに性能で負けると言われていたけど、蹴散らしてしまったな。
0220デフォルトの名無しさん2010/04/05(月) 22:21:15
機械語に美しさを求めるような奴は、エンジニアに向いていないよ。
0221デフォルトの名無しさん2010/04/05(月) 22:25:06
>>220
分かってるんだ、分かってるけどどうしてもアセンブルリストを見る癖が抜けないorz

>>219
悪貨、良貨を駆逐するの諺通りになってしまったな
0222デフォルトの名無しさん2010/04/05(月) 22:27:52
x86は優れているから普及した。悪貨ではない。
0223デフォルトの名無しさん2010/04/05(月) 22:45:38
最後はチップの配線に美しさを求める人が出てくるんだろうか。
0224デフォルトの名無しさん2010/04/05(月) 22:47:34
>>222
優れているか？どう考えてもゴッタ煮だぞ
古い部分から新しい部分までグチャグチャ
0225デフォルトの名無しさん2010/04/05(月) 22:53:28
ゴッタ煮でグチャグチャな事と、優れていることは、背反ではない
0226デフォルトの名無しさん2010/04/05(月) 22:54:20
よくわからんなあ・・・・

単にソフトが多いだけだと思うが
どう考えてもアーキテクチャ的には汚いぞ
0227デフォルトの名無しさん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　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶
0228デフォルトの名無しさん2010/04/05(月) 22:58:35
まあ、「美しさ」でしか取り柄の無い工業製品はいらないわなｗ
0229デフォルトの名無しさん2010/04/05(月) 23:02:59
x86ダメとか、マーケティング知らないすぎ
利用者の立場で考えろよ
職人技術者には無理かな？
0230デフォルトの名無しさん2010/04/05(月) 23:04:23
x86ダメとは言ってないから
ただ「汚いなあ」といつも思いながら仕事してるだけ
今のところシェアがすごいんだから目をつぶってるけど
0231デフォルトの名無しさん2010/04/05(月) 23:08:00
良いものが売れるのではない
売れるものが良いものなのだ
0232デフォルトの名無しさん2010/04/05(月) 23:10:57
>>231
屁理屈はどうでもいいから
文系はどっか行けよ
0233デフォルトの名無しさん2010/04/05(月) 23:11:24
x86は優れているから売れた。
0234デフォルトの名無しさん2010/04/05(月) 23:13:41
あーはいはいわかりました
Intel信者キモイな
0235デフォルトの名無しさん2010/04/05(月) 23:14:21
一人で騒いでるお前がキモイ
0236デフォルトの名無しさん2010/04/05(月) 23:17:00
お前が騒いでるじゃねーか馬鹿か
0237デフォルトの名無しさん2010/04/05(月) 23:20:50
ということで、新言語の話をどうぞ。
0238デフォルトの名無しさん2010/04/05(月) 23:30:50
昔はRISCが主流になるって言ってたのに
PowerPCがPentiumに取って代わると信じてたのに
0239デフォルトの名無しさん2010/04/05(月) 23:32:30
os/2はwindowsに駆逐されたしな
0240デフォルトの名無しさん2010/04/05(月) 23:34:21
>>238
だからintelの野望の前にはその理想郷は崩れ去ったんだよ
0241デフォルトの名無しさん2010/04/05(月) 23:36:17
理想郷じゃないし。地上の楽園だろｗ
0242デフォルトの名無しさん2010/04/05(月) 23:37:52
地上の楽園かあ
綺麗なアーキテクチャごときで地上の楽園と言い切れるお前の頭の中を
一度見てみたいものだ
0243デフォルトの名無しさん2010/04/05(月) 23:50:18
>>242には地上の楽園の意味が通じていないようだな
0244デフォルトの名無しさん2010/04/05(月) 23:52:39
知らない方が幸せなこともあります。
0245デフォルトの名無しさん2010/04/06(火) 00:01:40
フォン・ノイマンアーキテクチャなら目くそ鼻くそだろ
0246デフォルトの名無しさん2010/04/06(火) 00:07:12
x86系を汚れてると思えないやつはゆとり


PC88や98の時代から魔神語とか書いてた奴なら良く知ってる。
当時の月間I/Oとか読みふけってた奴なら良く知ってる。
でも分家ザイログたんのZ80Aは許す。（セグメントとか無いから）
0247デフォルトの名無しさん2010/04/06(火) 00:11:48
出たｗ昔自慢ｗ

魔神語と書いていたのは、マシン語を理解出来ないからだろ。
アーキテクチャの美醜を表現していたのではない。
0248デフォルトの名無しさん2010/04/06(火) 00:13:32
セグメントは先見の明があったな。
セグメントの無いCPU（MPU）なんて玩具だろ。
0249デフォルトの名無しさん2010/04/06(火) 00:14:46
知識自慢大好き
0250デフォルトの名無しさん2010/04/06(火) 00:26:15
I/Oにはダンプリストが掲載されていて、アセンブリ言語は殆ど書いていなかったけどな。
0251デフォルトの名無しさん2010/04/06(火) 00:27:00
確かに80386で「割と」まともなアーキテクチャにはなったが、その前には
8086、80286という失敗作が存在した事も忘れてはいけない
0252デフォルトの名無しさん2010/04/06(火) 00:28:08
メジャーどころを叩くと偉くなった気分を味わえるんだろ。

俺ってわかってる、みたいな。
0253デフォルトの名無しさん2010/04/06(火) 00:30:34
昔語りウザイな
ここに来てるオッサン連中なら誰でも知ってるつーの
0254デフォルトの名無しさん2010/04/06(火) 00:32:55
8086、80286が失敗作とか、病院行けよ。
0255デフォルトの名無しさん2010/04/06(火) 00:37:35
失敗作じゃねーか
0256デフォルトの名無しさん2010/04/06(火) 00:39:44
　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
0257デフォルトの名無しさん2010/04/06(火) 00:42:17
>>255
病院行け
0258デフォルトの名無しさん2010/04/06(火) 00:45:10
俺もオッサンだが
結局wintelの商業的な勝利だな
ま、今となっては汚くてもコンパイラ使えばええし

結局64bitで汎用レジスタ増やしたり
デコーダが電力食うとかって問題になってるよな
組み込みではx86はさほどメジャーじゃないし
0259デフォルトの名無しさん2010/04/06(火) 00:47:26
もうすぐメジャーになるけどな。
0260デフォルトの名無しさん2010/04/06(火) 00:49:25
残念ながらならねえよ
0261デフォルトの名無しさん2010/04/06(火) 00:50:53
特に80286+OS/2は「CPUの速度を1/3にする素晴らしいOSです」
と揶揄されたぐらいだからな
0262デフォルトの名無しさん2010/04/06(火) 00:51:04
RISC的方向性はPentium4とPOWER5で、いったんPC用途での限界を露呈してただろ
まあマルチスレッディングが一般的になってから登場した
Atom以降のSMT復権でだいぶいい扱いを受けるようになってきたが
0263デフォルトの名無しさん2010/04/06(火) 00:51:39
386以前のx86はゴミだからな
0264デフォルトの名無しさん2010/04/06(火) 00:53:38
>>262
そりゃ開発費が桁違いだからな
IntelとMicrosoftがx86にかけた金と労力をRISCに注いで
いたらもっといいCPUが出来てたろう
0265デフォルトの名無しさん2010/04/06(火) 00:59:14
いかにも素人的な発想だなｗ
0266デフォルトの名無しさん2010/04/06(火) 00:59:48
>>264
POWERもダメでAppleがキレちゃったじゃん
結局クロック上昇が物性的限界を迎えたところで、
同じクロック頻度でいかに多くの演算をするかという方向になったんで、
RISCのほうからx86的な方向に吸い寄せられているというかなんというか。
0267デフォルトの名無しさん2010/04/06(火) 01:00:07
RISC真理教
0268デフォルトの名無しさん2010/04/06(火) 01:00:53
ここまで新言語の話題なし
0269デフォルトの名無しさん2010/04/06(火) 01:04:05
並列実行が重要ということで、Goで良いんじゃないか
0270デフォルトの名無しさん2010/04/06(火) 01:04:26
>>265
んじゃプロのご意見どうぞ

俺もアーキテクトかじってたが
今全く新規にデザインし直すなら
結局68k的なRISC+CISCにDSP的命令付加になると思うぞ
x86はないない
0271デフォルトの名無しさん2010/04/06(火) 01:10:33
goはいいね。でもGCがネックだな
0272デフォルトの名無しさん2010/04/06(火) 01:13:13
>>270
モトローラに就職すればいいじゃんｗｗｗ
0273デフォルトの名無しさん2010/04/06(火) 01:14:13
>>270
アーキテクトをかじるなよｗ
0274デフォルトの名無しさん2010/04/06(火) 01:16:02
>>270
>んじゃプロのご意見どうぞ

互換性を保ちながら内部アーキテクチャの革新で性能を大幅に向上する。
0275デフォルトの名無しさん2010/04/06(火) 01:24:36
>>274
結局内部はRISCプロセッサ風味だわな
ま、あの命令ベースでこんだけ速度出したのは驚異的だがな

>>272
別にモトローラがいいつーこともいわんがｗ
フロントのバス帯域減らすのと時間のかかる演算のために
CISC風味なマクロ命令+DSP命令なRISCが今のとこ理想的じゃね
0276デフォルトの名無しさん2010/04/06(火) 01:25:16
GoってCもどきなんでしょ？
0277デフォルトの名無しさん2010/04/06(火) 01:27:28
>>275
>CISC風味なマクロ命令+DSP命令なRISCが今のとこ理想的じゃね

つまり、IAってことだな。
0278デフォルトの名無しさん2010/04/06(火) 01:30:11
このスレは病院に居た方が良い奴が多すぎるｗ
0279デフォルトの名無しさん2010/04/06(火) 01:31:53
>>277
商業的には互換性がないとあかんけどなｗ

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

>>276
ざっぱに(C+Python)/2って感じかね
C++じゃないとこがミソと思う
0280デフォルトの名無しさん2010/04/06(火) 01:35:55
機械語見て頭痛くなる奴は技術者に向いてないわ
0281デフォルトの名無しさん2010/04/06(火) 01:37:29
こういう議論をすると、技術的にもアーキテクチャ的にも結局x86が一番優れているという結論に落ち着いてしまうんだよな。
0282デフォルトの名無しさん2010/04/06(火) 01:44:58
＞＞281
ま、半導体や回路設計の技術とx86とは一緒にはできんが
商業的、現物ベースでいうと、
特にここ最近のx86は優れていると言わざるをえんわな
実際サーバとかもx86ばっかだしな
あれでアセンブラ書きたいかという話とは別にして。
0283デフォルトの名無しさん2010/04/06(火) 01:45:27
マーケティングが優秀なだけではなく、物理・アーキテクチャの両面でもIntelは優れている。
ある面でIntelに勝るアーキテクチャを開発することはできても、結局トータルではIntelアーキテクチャにはかなわない。

printfより高速な文字列表示関数を作りました！って自慢する中学生みたいなもの。
そりゃ、文字列定数を表示するだけなら速くなるでしょって話。
0284デフォルトの名無しさん2010/04/06(火) 01:48:17
RISCでアセンブラ書きたいとか病院行けよ。あんなの絶対に書きたくない。
人間が書くなら、どう考えてもx86の方がいい。
0285デフォルトの名無しさん2010/04/06(火) 01:53:16
>>284
CPUによるな。
確かにRISCの3オペランド系はつらい
0286デフォルトの名無しさん2010/04/06(火) 02:05:51
RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
その点x86は人に優しいアーキテクチャ／コードセット。だからハンドアセンブルだってできる。
0287デフォルトの名無しさん2010/04/06(火) 02:13:47
ハンドアセンブルするならRISCのが楽だぞｗ
てかアセンブラ、ディスアセンブラ作るのが超楽
直交性が高いから理不尽さはない
ま、直値入れるだけで2命令とか面倒ではあるが。

で、このスレ的にはC最強で結論出てるのか？
0288デフォルトの名無しさん2010/04/06(火) 05:03:09
>>287
お前はCを超える低級言語があると考えているのか？
0289デフォルトの名無しさん2010/04/06(火) 05:06:22
超えるって具体的にどういうことだろね
0290デフォルトの名無しさん2010/04/06(火) 06:16:06
みんなプライドが高いだけの低脳
0291デフォルトの名無しさん2010/04/06(火) 07:26:40
＞てかアセンブラ、ディスアセンブラ作るのが超楽
＞ま、直値入れるだけで2命令とか面倒ではあるが。
まさに
＞RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
ということを説明しているようにしか見えないが・・・
0292デフォルトの名無しさん2010/04/06(火) 07:45:18
>>286
x86が人に優しいって・・・68kのアセンブラ知らんのか？
0293デフォルトの名無しさん2010/04/06(火) 07:57:12
知ってる。
0294デフォルトの名無しさん2010/04/06(火) 07:59:28
しかし、68kは真っ向勝負でx86に負けた。
0295デフォルトの名無しさん2010/04/06(火) 08:16:58
Cの不満な点は？(低級言語の範囲で)
0296デフォルトの名無しさん2010/04/06(火) 08:33:07
Cは真っ向勝負しなかった。
0297デフォルトの名無しさん2010/04/06(火) 08:39:49
Cは別に何かの言語と対抗しようとして作られた言語じゃないから
真っ向勝負など必要なかった
0298デフォルトの名無しさん2010/04/06(火) 09:26:29
インテルはCPUに社運を賭けたから。
モトローラはメモリ売って儲けてた。
0299デフォルトの名無しさん2010/04/06(火) 10:22:42
Cは実用的だったし
Unixという実例もあったし
それらに関わった人間はリスペクトされてた
主流になるべくしてなった感じじゃないか
0300デフォルトの名無しさん2010/04/06(火) 11:47:23
Cの問題点はプロトタイプの導入でほぼ解決された。
0301デフォルトの名無しさん2010/04/06(火) 11:55:58
>>41

>>39は最適化の話なんてしてないけど
0302デフォルトの名無しさん2010/04/06(火) 12:16:23
>>300
俺はC大好きなんだが
宣言を二回書かないといけないのは欠点と言えると思うがね
あんな自動で出来ることは本来処理系でやっちまう方がいい話だな
0303デフォルトの名無しさん2010/04/06(火) 12:17:59
正確には、ほとんど同じ物を、宣言と定義の頭の部分と2箇所に、だな。
0304デフォルトの名無しさん2010/04/06(火) 13:01:05
Cはそれが開発された当時のしょぼいハードウェアに合わせて作られている。
いまどきのハードウェアの進歩に全く付いていけていない。
インラインアセンブラとかもう逃げの技術を駆使して何とか延命しているだけ
もう終わった存在だ。
0305デフォルトの名無しさん2010/04/06(火) 13:08:25
釣られてやるよ
インラインアセンブラは逃げじゃねえ
普通の言語で書けないこと
特殊なレジスタへのアクセスとかCPU固有の演算機能とかのために使う
Cレベルで書ける言語は他にはないな

そもそもハードウェアの進化ってなんだよ
単なるスピードアップか？ｗ
0306デフォルトの名無しさん2010/04/06(火) 13:28:52
Cは、プロトタイプ宣言のおかげで、コンパイルとリンクを分離できている。
0307デフォルトの名無しさん2010/04/06(火) 13:49:28
いまどきの言語ならそのへんなんとかして自動的に面倒見てほしいよな。
0308デフォルトの名無しさん2010/04/06(火) 14:00:17
>>307
原理的に無理
0309デフォルトの名無しさん2010/04/06(火) 14:01:53
>>304
Cがよくわからないので無くなってくれればいいんですね、わかります
0310デフォルトの名無しさん2010/04/06(火) 14:22:11
おまえらってプログラマが多いの？
おれは単に手段として使えればよいだけなんで
使いやすくて高速に計算さえできれば細かいことは気にしないんだが
0311デフォルトの名無しさん2010/04/06(火) 15:08:39
FORTRANでも使っときな
Cはポインタがあるから最適化しにくいしな
0312デフォルトの名無しさん2010/04/06(火) 15:32:16
インラインアセンブラが書けて配列演算や純関数概念を持っているDが最強だな
0313デフォルトの名無しさん2010/04/06(火) 15:32:44
Dだと？死んどけよ(　´,_ゝ｀)ﾌﾟｯ
0314デフォルトの名無しさん2010/04/06(火) 15:34:55
D はなんで普及しないの
0315デフォルトの名無しさん2010/04/06(火) 15:41:10
Dなんて誰も知らないからだろ
0316デフォルトの名無しさん2010/04/06(火) 18:06:36
リスクを負ってまで移行する利点が全く無いから
0317デフォルトの名無しさん2010/04/06(火) 18:57:23
Cが英語ならDはクリンゴン語並に人口少ないだろ
しょゆこと
0318デフォルトの名無しさん2010/04/06(火) 19:05:55
phpは中国語って感じか
BASICはヒンディー
0319デフォルトの名無しさん2010/04/06(火) 19:15:13
>>308
やろうと思えば普通にコンパイル時に集めた定義情報を吐き出して
インクルードするだけで実現できるし
そんな難しくもない話だと思うがね
protoizeとかでも省力化はできるし
0320デフォルトの名無しさん2010/04/06(火) 19:33:19
依存関係が循環してると個別にコンパイルできなくなるから効率悪い。
0321デフォルトの名無しさん2010/04/06(火) 19:40:38
>>319
よく考えてみ。コンパイル時に吐きだされるのでは遅いんだよ。
0322デフォルトの名無しさん2010/04/06(火) 20:23:01
>>314
仕様がころころ変わるから
0323デフォルトの名無しさん2010/04/06(火) 20:54:46
Dは名前が厨だから使うのが恥ずかしい

それで多くのユーザーを逃してる
0324デフォルトの名無しさん2010/04/06(火) 21:25:02
えっ？
0325デフォルトの名無しさん2010/04/06(火) 22:07:15
Cのいやなところ
・マクロがクソ
・駆動レコードが弄れない（サブルーチン必須）
・評価しない引数が使えない
辺りかね。
0326デフォルトの名無しさん2010/04/06(火) 22:09:09
・宣言と定義が別
・ヘッダーファイル
0327デフォルトの名無しさん2010/04/07(水) 00:51:54
shared_ptrの構文糖が欲しいな
0328デフォルトの名無しさん2010/04/07(水) 00:53:47
>>321
よく考えてみ。コンパイル時でいいんよ
循環は問題だが、
単純に多パスにするか
リンク時に遅延評価で解決できる
0329デフォルトの名無しさん2010/04/07(水) 01:02:55
要するに、ヘッダファイルの呼び方を変えて
遅延リンクなんたらファイルにすればいいんだろ
0330デフォルトの名無しさん2010/04/07(水) 01:07:45
人が書く必要ないなら書かない方がいいって話
0331デフォルトの名無しさん2010/04/07(水) 01:09:22
ヘッダーファイルなんて実装を隠したいときだけ生成するようにすればいいんだよ

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

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

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

ヘッダーファイルは不要
0332デフォルトの名無しさん2010/04/07(水) 01:22:34
インクルードスパゲティ作ったり
不要なのがすぐ残るしな
あとマクロ欲しいって言ってるが
一歩間違うと黒魔術になるから不要かな
cとgoの中間が俺には理想に近いな
個人的には名前付きパラメータが欲しいが
0333デフォルトの名無しさん2010/04/07(水) 01:26:10
Lispぽいのがいい。
0334デフォルトの名無しさん2010/04/07(水) 01:39:36
あんなの下手な奴に使わせたらgotoよりひでえ
そもそも理解できない奴、たぶん多数。
0335デフォルトの名無しさん2010/04/07(水) 01:45:27
うまくなればいい。要は慣れ。
0336デフォルトの名無しさん2010/04/07(水) 01:57:45
低能に合わせるためにマクロ不要なんて言うなよ。
単に低能にはマクロ使わせなきゃ良いだけだろ。
0337デフォルトの名無しさん2010/04/07(水) 02:07:57
名前付きパラメータみたいな飾りはどうでもいいよ。
フロー制御どうするかとかの方が重要じゃない？
0338デフォルトの名無しさん2010/04/07(水) 02:41:18
ご立派な設計を語る人間が１００人いても、何一つ作れないことの証明
0339デフォルトの名無しさん2010/04/07(水) 03:11:16
優れたシステムは優れた個人と
優秀な少人数チームが核を作るからな
ここは雑談の場じゃないのw
0340デフォルトの名無しさん2010/04/07(水) 03:14:10
>>337
低レベル言語にふさわしい制御なんて
ifと繰り返しとその変型しかない、じゃん
オブジェクト指向チックなのはoh高い
0341デフォルトの名無しさん2010/04/07(水) 03:50:35
作る気の無い奴が1億人集まろうと作られる訳が無いだろ
次スレ立てるなら　【超高速】C/C++に代わる低級言語を妄想したい　に変えておけよ
0342デフォルトの名無しさん2010/04/07(水) 03:55:49
母国語の１位が中国語だから中国語でかける言語がいいんじゃね？
0343デフォルトの名無しさん2010/04/07(水) 04:31:30
Cでヘッダファイル不要何て言っているやつは、手動でコンパイルとリンクをやったことがないな。
0344デフォルトの名無しさん2010/04/07(水) 05:39:07
>>343
でっていうｗｗｗｗ
そんなに手動でコンパイルがやりたいならどうぞご勝手にｗｗｗｗｗ
0345デフォルトの名無しさん2010/04/07(水) 05:42:46
コンパイルとリンクの区別もついていないやつらばっかだから
0346デフォルトの名無しさん2010/04/07(水) 06:02:20
手動でアセンブルって話しは分かるが
手動でコンパイルって何のこっちゃ。
どーやるの？
0347デフォルトの名無しさん2010/04/07(水) 06:12:34
こんな部下いたら発狂するわ
0348デフォルトの名無しさん2010/04/07(水) 08:18:47
コンパイルとリンクは統合されてくのが処理系の動向。

最適化とかリンク時にも考えられるからね。
0349デフォルトの名無しさん2010/04/07(水) 13:13:33
処理系の動向とか以前に、アセンブルと、コンパイルと、リンクの動作の違いをわかっていない人間がいるって話じゃないの？
0350デフォルトの名無しさん2010/04/07(水) 13:16:13
何かの話について、実際の内容の観察や考察よりも、
勝ち負けとかあほみたいな視点で話をする奴がちょいちょい紛れ込んでるスレ
0351デフォルトの名無しさん2010/04/07(水) 13:17:40
負け組は黙ってろ
0352デフォルトの名無しさん2010/04/07(水) 14:01:40
つか、処理系作ったことあるヤツ少なそうだな
妄想はエロいのだけにしとけよ
ヘッダに関しては時代遅れとは思うがな
0353デフォルトの名無しさん2010/04/07(水) 15:39:12
ハンドコンパイルwww
0354デフォルトの名無しさん2010/04/07(水) 16:18:16
ハンドコンパイルって、言い方変えたら人間コンパイラだよなｗ
もはや超人だ
0355デフォルトの名無しさん2010/04/07(水) 17:05:20
ん？CがないようなCPU向けにアルゴリズム記述とデバッグはCでやって
手でアセンブラになおすなんてのはあるんじゃね
0356デフォルトの名無しさん2010/04/07(水) 17:39:44
なにそのシチュエーション
0357デフォルトの名無しさん2010/04/07(水) 18:01:59
ごくふつうのブートストラップ
0358デフォルトの名無しさん2010/04/07(水) 19:25:23
単にコマンドラインからコンパイラやリンカ直たたきで
コンパイルやリンクをするということなんだろうけど
ハンドコンパイルと言われると
直でオブジェクトファイルまで変換するように思えるなw
0359デフォルトの名無しさん2010/04/07(水) 19:36:15
IDEしか使ったことないやつらが騒いでるな。
0360デフォルトの名無しさん2010/04/07(水) 19:43:33
>>355
こういうのがハンドコンパイル
4bit CPUとか変なDSPとか、未だにCがないCPUもあるんさ

コンパイラ手で叩くのはハンドコンパイルとはいわんがなｗ
0361デフォルトの名無しさん2010/04/07(水) 20:20:28
なになに？
>>343 はまるでRPMしか扱った事ないTaco がconfigureを初めて
叩いた時のように「手動でコンパイル」とか言ってたの？
0362デフォルトの名無しさん2010/04/07(水) 20:49:27
cpuの１コアあたりの処理スピードが今より10万倍になれば
難しいコードを書く必要はないんだが
0363デフォルトの名無しさん2010/04/07(水) 22:00:42
よってjavascriptで十分
0364デフォルトの名無しさん2010/04/08(木) 00:13:51
よって大蛇Pythonたんが火を吹く
0365デフォルトの名無しさん2010/04/08(木) 00:59:48
javascriptのネイティブコンパイラ欲しい
0366デフォルトの名無しさん2010/04/08(木) 01:03:01
変数の型が決まってない言語ｲﾗﾈ
0367デフォルトの名無しさん2010/04/08(木) 01:47:27
とりあえずネイティブなレベルで並列処理が欲しいな
0368デフォルトの名無しさん2010/04/08(木) 01:51:47
Cに代わる低級言語のスレでJS,Pythonはアレだなｗ
>>362
10万倍といえばおおよそで8080/z80レベルの8bit CPUと最新のCPU位の差だな
実に興味深い
0369デフォルトの名無しさん2010/04/08(木) 01:56:05
どういう点が興味深い？
0370デフォルトの名無しさん2010/04/08(木) 02:17:42
当時はCですら重くて、速度を求めるならアセンブラだった
PCでは取っつきやすいOld BASICの隆盛期だった
今は組み込みのCPUですらどん底を除くと数MIPSでCが主流
PCクラスでは当時のスパコンを超えCは既に最低レベルな階層の言語で
実行時にマシンコード生成したり、動的言語が多く使われてる

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

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

等々と考えて、興味深い
0371デフォルトの名無しさん2010/04/08(木) 02:37:20
CPU速度が十万倍になった今でも変わらない愛の形を探してるって事だろ
0372デフォルトの名無しさん2010/04/08(木) 02:39:15
二十年後にはみんなUMLを進化させたような言語をいじってて
「速度を求めるならJAVA」とか言われるようになるのかね
0373デフォルトの名無しさん2010/04/08(木) 02:52:18
伝説のプログラミング言語Cとか呼ばれるようになっているかもな
0374デフォルトの名無しさん2010/04/08(木) 02:56:41
でもその頃になってもいまの話題と技術名を置き換えただけで、
おなじような話題で貶しあいループしてるだろうことだけは断言できる。
やっぱり人間の方が進歩しないとね。
0375デフォルトの名無しさん2010/04/08(木) 03:57:30
>>372
UMLよりC言語の方が長生きすると思うぞ
0376デフォルトの名無しさん2010/04/08(木) 04:45:08
自分は構文上の話が詳しいのでそちらだけ書き込ませてもらいます。

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

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

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

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

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

・EcmaScriptやScala、ActionScriptではXMLを直接かけるが必要かどうか？
0377デフォルトの名無しさん2010/04/08(木) 05:07:30
最近Cを勉強し始めてどれが関数名とか変数名とか型名(構造体)とか、
流し読みだと全然わからないんですが、これどうにかなったりしますか？
0378デフォルトの名無しさん2010/04/08(木) 05:09:10
激しく書く場所を間違ったけど、そのままにしときます。
0379デフォルトの名無しさん2010/04/08(木) 05:20:33
>>376
このスレはCに代わる低級言語ってことで
基本的にCPUアーキテクチャに沿った
手続き系で余分なことをしない静的な型の言語以外あり得ないんじゃないかな

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

みたいな感じ
不勉強だからブートストラップみたいなベタなとこを関数型言語で書けるのかな？
って思うんですけど
0380デフォルトの名無しさん2010/04/08(木) 05:33:44
>>377
慣習でカバー
俺はだいたい関数は動詞入り、変数は名詞形、型は_t
0381デフォルトの名無しさん2010/04/08(木) 07:14:40
Dでいいんじゃないかな
0382デフォルトの名無しさん2010/04/08(木) 07:55:21
>>381
何がいいのかと、その理由を。
0383デフォルトの名無しさん2010/04/08(木) 08:33:21
定期的にD厨わくけどなんなの
0384デフォルトの名無しさん2010/04/08(木) 14:09:08
Dがダメな理由なんてないからな。
言語統計を見れば分かると思うけど、優秀な技術者はDを洗濯する。
0385デフォルトの名無しさん2010/04/08(木) 14:23:58
面白がってはいるし使い捨ての道具くらいは作るが、
事実上実用にはなってないというのが現状だろ
0386デフォルトの名無しさん2010/04/08(木) 14:39:10
 
0387デフォルトの名無しさん2010/04/08(木) 14:39:38
理由なき現実を受け入れるには、どうすればいいんだ
0388デフォルトの名無しさん2010/04/08(木) 14:43:12
言語仕様がきれいなだけで、あとは他の言語と同じでは、広く使われることはないということのひとつの証明。
0389デフォルトの名無しさん2010/04/08(木) 14:59:59
とはいえ一度javaを使うともうC++は使いたくないのが事実
0390デフォルトの名無しさん2010/04/08(木) 15:25:05
パーソナルリアリティをレベルアップすればC++も使える
0391デフォルトの名無しさん2010/04/08(木) 16:27:15
D言語
↓
0392デフォルトの名無しさん2010/04/08(木) 17:12:17
>>389
JavaとC++では、特徴が全然違う
0393デフォルトの名無しさん2010/04/08(木) 17:15:47
馬鹿でも使えるJava vs 馬鹿は使えないC++
0394デフォルトの名無しさん2010/04/08(木) 17:24:15
馬鹿でも使えるJava vs 自称天才が脆弱性を入れ込むC++
0395デフォルトの名無しさん2010/04/08(木) 17:39:24
>>392
>>389 は多分初心者なんだと思うぜ。

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

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

すっごいバカ。すっごい勘違い。すっごい勢いでハナ垂らした大学生
0396デフォルトの名無しさん2010/04/08(木) 17:42:11
ちなみにC使いな俺はC++もJavaもさっぱりわからん
0397デフォルトの名無しさん2010/04/08(木) 17:44:22
>>395
Javaですむことを、C++でやりたくはないというのは、初心者、上級者共通だと思うけどね。
0398デフォルトの名無しさん2010/04/08(木) 18:11:21
395 ：デフォルトの名無しさん：2010/04/08(木) 17:39:24
>>392
>>389 は多分初心者なんだと思うぜ。

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

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

すっごいバカ。すっごい勘違い。すっごい勢いでハナ垂らした大学生
0399デフォルトの名無しさん2010/04/08(木) 18:24:38
398 名前：デフォルトの名無しさん[] 投稿日：2010/04/08(木) 18:11:21
0400デフォルトの名無しさん2010/04/08(木) 19:01:42
まさに必死
0401デフォルトの名無しさん2010/04/08(木) 21:17:43
必死になってハナ拭けばいいのになｗ
0402デフォルトの名無しさん2010/04/08(木) 21:50:56
C++ですむことを、わざわざJavaなんかでやりたくはないわ。
0403デフォルトの名無しさん2010/04/08(木) 21:55:09
>>393
馬鹿でも使える方が工学的には優れている。

但し、Javaはできることが限られているから、イマイチな言語。
0404デフォルトの名無しさん2010/04/08(木) 22:02:44
いまどき、何でも出来る言語なんて低レベルを扱うのでなければ害悪。
0405デフォルトの名無しさん2010/04/08(木) 22:06:55
ということで、低レベルを扱う新言語の話をしようか
0406デフォルトの名無しさん2010/04/08(木) 22:09:42
上手い事話戻したなｗｗ
0407デフォルトの名無しさん2010/04/08(木) 22:10:23
やっぱりe言語
0408デフォルトの名無しさん2010/04/08(木) 22:11:42
結論
新言語を作る必要は全く認められない。C++で十分である。
0409デフォルトの名無しさん2010/04/08(木) 22:14:11
C++のどの機能が良いのか具体的に述べるといいよ。
0410デフォルトの名無しさん2010/04/08(木) 22:16:53
C++は、言語体系が崩壊しているから、近年、
C++に取って代わる言語はたくさん登場している。
けれども、Cに代わるものはほとんどない。
0411デフォルトの名無しさん2010/04/08(木) 22:49:46
C系言語の修飾の判り辛さはどれも50歩100歩
0412デフォルトの名無しさん2010/04/08(木) 22:53:12
新言語では、その辺、簡潔に、かつ直感的にプログラマーが勘違いしないようにしたいな。
0413デフォルトの名無しさん2010/04/08(木) 23:36:55
アスタリスクでポインタとかなんとかなりませんこと？
0414デフォルトの名無しさん2010/04/08(木) 23:43:52
といいますと？
0415デフォルトの名無しさん2010/04/08(木) 23:46:54
それじゃ、こんなのにしちゃいましょう
double㌍cariable;
0416デフォルトの名無しさん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;
0417デフォルトの名無しさん2010/04/08(木) 23:53:47
char **pp;
だと、
**pp　の型が　char　で
*p の型が　char* ってのは
かなり直感的なんだよな。

char　→　**pp
char*　→　*pp
char**　→　pp
0418デフォルトの名無しさん2010/04/09(金) 00:12:46
ポインタ脳に新しいものは作れない
0419デフォルトの名無しさん2010/04/09(金) 00:32:49
char* p, q:

きもいよーきもいよー
0420デフォルトの名無しさん2010/04/09(金) 00:33:49
ノイマン型アーキテクチャの上でJavaVMを書きましょうという話でポインタは避けては通れんだろ。
0421デフォルトの名無しさん2010/04/09(金) 00:34:50
全て無いところから発明しろ
新たに
0422デフォルトの名無しさん2010/04/09(金) 00:35:36
JavaVMなんて書かなくていいよ
0423デフォルトの名無しさん2010/04/09(金) 00:41:35
いやJavaそのものがなくていいよもう
0424デフォルトの名無しさん2010/04/09(金) 00:48:42
>>419
お前は(2* 3+4)が14にならないと文句を言うのか?
0425デフォルトの名無しさん2010/04/09(金) 00:49:05
>>421
言語自体は全く新しく一から作るが、これまでの研究成果を生かさないのはもったいない。

良いものは取り入れる。
0426デフォルトの名無しさん2010/04/09(金) 00:50:06
それが日本人の悪い癖だ

ハードウェアの世界ではそれで成功したがソフトウェアでは通用しない
0427デフォルトの名無しさん2010/04/09(金) 00:56:15
char* ptr = NULLPO;
0428デフォルトの名無しさん2010/04/09(金) 01:02:52
char* pは間違いやすいからダメだな
char *pが文法的に理にかなってる
0429デフォルトの名無しさん2010/04/09(金) 01:03:00
PerlとC#は、良いものを取り入れると伸びるタイプ
0430デフォルトの名無しさん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.
0431デフォルトの名無しさん2010/04/09(金) 01:23:25
>>429
ご冗談でしょう

つか低レベル言語の話でねえなｗ
0432デフォルトの名無しさん2010/04/09(金) 01:33:58
cgiがhtmlを吐くように、asmを吐くスクリプトを書け。
0433デフォルトの名無しさん2010/04/09(金) 01:40:37
別にスクリプトでコンパイラ書いたっていいんだぜ
0434デフォルトの名無しさん2010/04/09(金) 02:06:00
>>424
「char* p, q」はアスタリスクがcharと合体しつつpとスペースで区切られているのに
pにのみ効果を及ぼしてるのがきももも
0435デフォルトの名無しさん2010/04/09(金) 02:13:30
>>433
コンパイラ書かなければ、文法とパーサで力尽きる心配が無くなるだろ
0436デフォルトの名無しさん2010/04/09(金) 02:29:37
>>435
432か？asmを吐くスクリプト=コンパイラだろ
0437デフォルトの名無しさん2010/04/09(金) 02:50:22
>>436
そうだよ
その定義に従うと、文法やパーサを作るのは必須ではない
0438デフォルトの名無しさん2010/04/09(金) 03:30:38
>>437
意味わからんな。
文法はありもの言語でもいいがパーサがないとコンパイラは出来ないだろ。。。
0439デフォルトの名無しさん2010/04/09(金) 03:33:48
>>438
Forthなんかは、パーサーないも同然だけどな。
0440デフォルトの名無しさん2010/04/09(金) 04:13:37
ウダウダ言ってないでasm直接書けよ
0441デフォルトの名無しさん2010/04/09(金) 13:30:40
obj のテキスト表記を変換するだけってのはどうだろう。
コード部分は hex で直書き。
作るのも簡単だし高速で簡潔だ。
使う側は少し大変かも知れないけど
0442デフォルトの名無しさん2010/04/09(金) 14:16:51
意味わからん。それアセンブラじゃね
0443デフォルトの名無しさん2010/04/09(金) 15:26:43
アセンブラじゃなくてbinutilsだな
0444デフォルトの名無しさん2010/04/09(金) 21:34:28
テキストで書かれたコードを、一旦アセンブラコードに変換して実行させるっていうのはどうだ？
0445デフォルトの名無しさん2010/04/09(金) 21:58:59
sレコードで書けばいいやん
0446デフォルトの名無しさん2010/04/09(金) 22:22:23
>>444
それをするとどういうメリットが？
これまでのコンパイラでもアセンブラコードはけるけどそれとは違うの？
0447デフォルトの名無しさん2010/04/09(金) 22:50:41
アセンブラでは移植性がない件
0448デフォルトの名無しさん2010/04/09(金) 22:53:14
移植性より大切なものがあるだろう？
0449デフォルトの名無しさん2010/04/09(金) 23:06:27
ポインタは
Hoge* pHoge
Hoge *pHoge
どっちで書くか

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

今でも悩む。
0450デフォルトの名無しさん2010/04/09(金) 23:11:19
>>449
C#なら前者、Cなら後者。
0451デフォルトの名無しさん2010/04/09(金) 23:14:18
C#でポインタとか使うなよ
劣化javaをさらに劣化させてどうする
0452デフォルトの名無しさん2010/04/09(金) 23:14:46
C#が劣化Javaだと？聞き捨てならんな
0453デフォルトの名無しさん2010/04/09(金) 23:15:36
a
0454デフォルトの名無しさん2010/04/09(金) 23:16:49
>>447
じゃあ、アセンブラだけど、実装されていない命令を既存の命令に置き換えてアセンブルする
弱抽象化アセンブラとかどうよ。
0455デフォルトの名無しさん2010/04/09(金) 23:20:54
>>454
マシン語がCPU間で似ていると思ったら大間違い。
0456デフォルトの名無しさん2010/04/09(金) 23:22:09
>>455
マシン語じゃなくて、アセンブリ言語に変換するんだよ
0457デフォルトの名無しさん2010/04/09(金) 23:35:12
何をアセンブリ言語に変換するんだよ。ソースコードをなら、従来のコンパイラが普通にできることだろ。
0458デフォルトの名無しさん2010/04/09(金) 23:38:34
WindowsやLinuxなどがC/C++から乗り換えてくれるような言語が登場する可能性はあるの？
0459デフォルトの名無しさん2010/04/09(金) 23:41:25
むしろ、新言語で作られたOSでWindowsやLinuxが置き換えられる。
0460デフォルトの名無しさん2010/04/09(金) 23:42:40
それはない
0461デフォルトの名無しさん2010/04/09(金) 23:42:55
>>454
昔々Base-80というアセンブラがあってな
0462デフォルトの名無しさん2010/04/09(金) 23:48:21
>>449
後者は間違いの元だからダメだろ
やりたきゃtypedef

後、アセンブラでまとまった
コード書いたことないヤツがいるな
0463デフォルトの名無しさん2010/04/09(金) 23:57:08
「～な奴がいるな」はもういいよ。お前、凄いから。凄い凄い。
0464デフォルトの名無しさん2010/04/10(土) 00:00:57
なんか凄い奴がいるな
0465デフォルトの名無しさん2010/04/10(土) 00:02:46
>>450
>>462
どっちなんだよ
0466デフォルトの名無しさん2010/04/10(土) 00:04:17
>>465
Hoge* pHoge;

がおすすめ。１行に１宣言。コンマは使わない。
0467デフォルトの名無しさん2010/04/10(土) 00:08:47
>>466
その書き方がC++が流行り始めてから推奨されているが、あくまで型はHogeで*は定義する変数を修飾するものだから、pHogeにつける方が筋。
関数へのポインタとか書くときに型にくっつける書き方は破綻して一貫性がなくなる。
0468デフォルトの名無しさん2010/04/10(土) 00:11:30
そこまでは素人の考え
0469デフォルトの名無しさん2010/04/10(土) 00:12:56
玄人さんおねげーします
0470デフォルトの名無しさん2010/04/10(土) 00:14:28
Hoge * pHoge;
0471デフォルトの名無しさん2010/04/10(土) 00:18:45
ところで、C言語って完全にアセンブラを代替できるの？
アセンブラじゃないとかけないコードとかあったりしない？
0472デフォルトの名無しさん2010/04/10(土) 00:19:48
あるよ。
0473デフォルトの名無しさん2010/04/10(土) 00:22:55
Cだとアセンブラよりは短くならない。
あと、サブルーチンの構造前提になる。コルーチンとか継続渡しとか無理。
0474デフォルトの名無しさん2010/04/10(土) 00:24:20
>>449
Ｃでも型は Hoge* だろ。キャストの時を考えろ。
ただしHoge*型の変数（つまりポインタ）の宣言は、Hoge *pHoge という構文で行う。
0475デフォルトの名無しさん2010/04/10(土) 00:26:42
そして

Hoge* pA, pB;

で勘違いっていういつものアレが起こるわけです。
0476デフォルトの名無しさん2010/04/10(土) 00:27:42
アレって？
0477デフォルトの名無しさん2010/04/10(土) 00:30:15
機械語から全て書き直して新構造のコンピュータの方が良い
0478デフォルトの名無しさん2010/04/10(土) 00:30:28
ポインタ宣言時の*と、ポインタの型を示す*は似ているけど意味が違う記号と思え。
乗算の*とポインタ宣言時の*が一緒の意味でないのと同じことだ。
0479デフォルトの名無しさん2010/04/10(土) 00:32:10
何いってんだ馬鹿。
0480デフォルトの名無しさん2010/04/10(土) 00:32:11
>>475
pBはポインタでしょ？
0481デフォルトの名無しさん2010/04/10(土) 00:32:13
>>477
アホか
この不況にどの企業にそんな時間と金の余裕がある？
0482デフォルトの名無しさん2010/04/10(土) 00:33:25
>>478
じゃあ新言語は3つとも違う記号にしようぜ
0483デフォルトの名無しさん2010/04/10(土) 00:34:09
>>480
pBはインスタンスだよ
0484デフォルトの名無しさん2010/04/10(土) 00:36:05
これだけ自称できる連中が集ってるのに、ボインタ宣言すらてんでバラバラなあたりがCのヤバさ。
0485デフォルトの名無しさん2010/04/10(土) 00:36:29
char **pp;
は、
char　→　**pp であり、
char*　→　*pp であり、
char**　→　pp である。

実に直感的かつ合理的。

他の記号にするなんてとんでもない。
0486デフォルトの名無しさん2010/04/10(土) 00:37:42
>>481
第3のニューディールみたいな感じで雇用創出も出来る
ネイティブなレベルで並列命令作っておけば今後の進化にも対応できよう
0487デフォルトの名無しさん2010/04/10(土) 00:38:15
ためしに++にしてみようか
0488デフォルトの名無しさん2010/04/10(土) 00:38:46
>>485
２個以上のポインタを宣言すると全然成り立たないけど？
0489デフォルトの名無しさん2010/04/10(土) 00:38:47
>>478 なんだっけ、

＞ポインタ宣言時の*

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

＞ポインタの型を示す*

こっちは、 *hoge　ホゲポインタ型として中身を・・・　うーん、なんか上手い表現ないか
0490デフォルトの名無しさん2010/04/10(土) 00:39:50
>>488
1行で2個以上ポインタを宣言するな。
0491デフォルトの名無しさん2010/04/10(土) 00:40:36
Ｃの*はコメントを除いても4通りぐらいの用法がある。そのうち３つがポインタ関連な。
0492デフォルトの名無しさん2010/04/10(土) 00:55:37
ポインタの宣言と、間接参照演算子を同じ記号にするのは合理的。
0493デフォルトの名無しさん2010/04/10(土) 01:00:23
それで関数宣言と配列宣言を混ぜたらあの読みにくい構文になるんだなこれが
0494デフォルトの名無しさん2010/04/10(土) 01:04:09
読みやすく書くと長くなるからな
C++なら、Pointer< Pointer<char> > pp;と書けるかもしれないが、書きたくない
0495デフォルトの名無しさん2010/04/10(土) 01:08:31
>>493
新言語に関数宣言と配列宣言があるとしたら、こうしよう↓

type [] ARRAYNAME;
[capture] (type inparams, ...) -> outtype FUNCNAME;
0496デフォルトの名無しさん2010/04/10(土) 01:09:47
>>494
ポインタをあまり多様する必要がないという前提なら、そういう構文もありだと思う。
今のC/C++でやられると鬱陶しいだけだが。
0497デフォルトの名無しさん2010/04/10(土) 01:15:17
>>495
それがまさしくC#なんだがな
0498デフォルトの名無しさん2010/04/10(土) 01:30:58
配列だけな。
0499デフォルトの名無しさん2010/04/10(土) 01:36:30
名前を後ろにすると、関数呼び出しを記述するときに先にパラメータを書かなければいけなくなるから、IDEが困りそう。
宣言と呼び出しは同じ形にしたいし。

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

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

n : int;
a : int [];
f : [](param1 : int, param2 : int) -> int;
0500デフォルトの名無しさん2010/04/10(土) 01:38:45
気持ち悪いな
Ada崩れみたいだ
0501デフォルトの名無しさん2010/04/10(土) 01:40:35
慣れだ。
0502デフォルトの名無しさん2010/04/10(土) 01:45:49
じゃあ言語名、

Nareda に決定な。
0503デフォルトの名無しさん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);

プログラミングも自然言語に近づければユーザーに優しいはず。
0504デフォルトの名無しさん2010/04/10(土) 01:48:45
intじゃなくてイントにしろよ
あとparamはパラムとか
0505デフォルトの名無しさん2010/04/10(土) 01:51:32
基本的な構文が長いのは人に優しくない。
0506デフォルトの名無しさん2010/04/10(土) 01:53:06
Function::ThatTakes<int>::AndReturns<bool>
0507デフォルトの名無しさん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;}
0508デフォルトの名無しさん2010/04/10(土) 01:56:41
もっと機能の話はしないの？プリミティブとか制御とか駆動レコードとかスコープとか。
構文なんて後でいいんじゃね？
0509デフォルトの名無しさん2010/04/10(土) 01:59:52
ユーザーが文法をカスタマイズできるようにすればいいんじゃないのか？

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

みたいな感じで。
0510デフォルトの名無しさん2010/04/10(土) 02:01:13
低級言語の機能ならCで十分だろ
0511デフォルトの名無しさん2010/04/10(土) 02:06:26
そそ
詰まる所どうあがいてもCには勝てっこない
0512デフォルトの名無しさん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;}
0513デフォルトの名無しさん2010/04/10(土) 02:16:41
＞仮想レジスタと仮想スタック定義出来て実機へ効率的に転写出来れば

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

間接アドレシングとか単純にやろうとすると、
ほぼまんま C/C++と同じ格好になるので、そこをなんとか
0514デフォルトの名無しさん2010/04/10(土) 02:23:06
ボインタのボインタのボインタって必要？
いやCなら出てくることがあるのはわかるけど
**までで良くない？
0515デフォルトの名無しさん2010/04/10(土) 02:36:00
>>514
ポインタのポインタを他の関数に送って変更してもらう時に必要
但しC++は**&と最後をリファレンスにすればよい
0516デフォルトの名無しさん2010/04/10(土) 02:41:56
test
0517デフォルトの名無しさん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;
--}
}
0518デフォルトの名無しさん2010/04/10(土) 03:15:02
C++/CLIでいいじゃん
0519デフォルトの名無しさん2010/04/10(土) 03:24:36
リフレクションとかできないじゃん
だからレイヤーつくって複数の環境組み合わせようYO
見た目　C#(Silverlight)
サーバー　Java
クリティカル部位　C++ D ASM
0520デフォルトの名無しさん2010/04/10(土) 03:28:10
C/C++は増築限界超え始めたし
類似言語はピタゴラスイッチだし
0521デフォルトの名無しさん2010/04/10(土) 03:28:24
C++/CLIはリフレクション出来るだろ
0522デフォルトの名無しさん2010/04/10(土) 03:29:09
JITコンパイラは最低限必須な

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

新言語から既存言語のソース吐いて
MSやSunのツールにコンパイルさせればよし
0525デフォルトの名無しさん2010/04/10(土) 04:34:45
>>521
よくない。それでデバッガどうするのさ。
インテリセンスもきかないからＣより明らかに不便でしょ。
新言語作る意味ないじゃない。
0526デフォルトの名無しさん2010/04/10(土) 04:36:18
訂正>>524にレスしたつもりだった
0527デフォルトの名無しさん2010/04/10(土) 05:18:28
デバッガやインテリセンスは言語仕様じゃないだろ

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

まずはAntで動くぐらいの目標で十分すぎる
0528デフォルトの名無しさん2010/04/10(土) 05:42:18
みんな俺様の好きな仕様が入ってなかったら納得しないんだから
出来上がるのはゴチャゴチャ詰めこんだウンコ仕様に決まってる
理想を語るのは結構だが真っ当なライブラリとデバッガは必須
だいたい2ch発祥でものになったのは2chブラウザくらいじゃね
MONA OSとか誰も使わないしw安直に考え過ぎ
0529デフォルトの名無しさん2010/04/10(土) 06:14:01
MONA OSはまさに立ちパーティション不明の失敗例だな

用途は鯖か組み込みかクライアントアプリか、
またそれらの中のカテゴリーは何か絞らないと実用的にはならんな
0530デフォルトの名無しさん2010/04/10(土) 07:26:16
このスレは

是が非でもC/C++を勉強したくない(理解できなくて挫折したから)
Java厨、C#厨が心の叫びを漏らすスレ
0531デフォルトの名無しさん2010/04/10(土) 07:39:19
IDEが無いとダメとかいう奴はC/C++を語る資格無し。
お前は誰かが作ったフレームワーク内で一生泳いでろ。
0532デフォルトの名無しさん2010/04/10(土) 07:48:15
いやc はともかくとしてC++ はvisual studio やeclipse 使い始めたらヘナチョコエディターなんかじゃ書いてらんない。
0533デフォルトの名無しさん2010/04/10(土) 07:51:44
まさにお前のことだよ
0534デフォルトの名無しさん2010/04/10(土) 07:55:59
C++ > C#, Java なんて言っているのは、コーディングばかりやってる底辺。
0535デフォルトの名無しさん2010/04/10(土) 07:58:46
>>534
説得力がまるでないよ、君
0536デフォルトの名無しさん2010/04/10(土) 08:14:35
ロジック書けよ
0537デフォルトの名無しさん2010/04/10(土) 08:15:08
多様な思想があるから
他の言語選択スレみたいに、宗教論争になってまうね
0538デフォルトの名無しさん2010/04/10(土) 08:36:07
低級言語（本来は低水準言語）の意味をわかって書いてる奴がどれだけいるのやら。
例えばセガサターンは（昔の話だが）、メモリが分散して配置されていた。
片方は速く、片方は遅かった。
これらを効率よく扱うためには、本来はアセンブラで書くべきだが、
さすがにそれは開発効率が悪いので、Ｃで書いていた。
速いほうと遅いほう、両方の先頭アドレスをポインタで保持していた。
二次元配列とかも、フレームだけ定義し、実体は使用時にアロケートしていた。
メモリがもったいないからな。
（二次元配列の動的確保、できるか？出来ないなら「Ｃわかります」とか言うなよ？）
こういうことが出来ないとＯＳとか組み込み機とかゲームとかの開発は無理。
C++でも、メモリをどれだけ食うか走らせないとわからないので無理。
IDEがないとダメ、なんて論外。
0539デフォルトの名無しさん2010/04/10(土) 08:44:33
やっぱIDEがないと駄目だな
0540デフォルトの名無しさん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
メモリをうまく抽象化できればいいんだけど
0541デフォルトの名無しさん2010/04/10(土) 08:55:09
参照とポインタを一緒にしてる奴も後を絶たないね。
そんな奴が言語の設計とかｗ
参照は「必ず実体がある」点で、ポインタとはまったく違う。
ポインタは参照と違って、指し示すオブジェクトが１個だろうが、配列だろうが、
メモリが無い変なアドレスだろうが関知しない。
だから参照より危険だが、その代わり、I/Oアドレスでも何でもポイントできる。
デバイスドライバとか書くときは便利だよ。C#にこんなマネができるかね？
0542デフォルトの名無しさん2010/04/10(土) 08:56:14
>>541
unmanagedを知らないのか？
0543デフォルトの名無しさん2010/04/10(土) 08:56:32
やっぱC#が最強ってことか
0544デフォルトの名無しさん2010/04/10(土) 08:57:18
Marshalとかな
ポインタももちろんある
0545デフォルトの名無しさん2010/04/10(土) 08:58:01
Cより後から出来た言語はどこかでちゃっかりCの良い面だけを
取り入れているよな
0546デフォルトの名無しさん2010/04/10(土) 09:16:06
C++に置けるインラインアセンブラの様に、今後の高級言語に
インラインCを搭載するのはどうだろう。
0547デフォルトの名無しさん2010/04/10(土) 09:27:12
それなんとかして欲しいよ

x86-64のC++はインラインアセンブル禁止だとよ
どうやってSSEをチューニングしろと言うんだ？
0548デフォルトの名無しさん2010/04/10(土) 09:48:53
>>546
objective-cはそれに近い
ていうかあれでcを名乗るのやめてほしい
0549デフォルトの名無しさん2010/04/10(土) 10:38:34
よし、俺がインラインCで全てが書ける言語作るわ
0550デフォルトの名無しさん2010/04/10(土) 11:34:23
>>547
intrinsicだっけ？
もうあれでいいじゃん。
どうせパイプライン埋めようとしたってCPUごとにいろいろ違うんだし。
0551デフォルトの名無しさん2010/04/10(土) 12:02:32
>>510-511
プロジェクトX用に画面キャプチャしといた
0552デフォルトの名無しさん2010/04/10(土) 12:09:11
>>514
「まで」も何も、*は2個までとか個数を制限するのはおかしい。

ポインタ操作に「**」なんて演算子はなくて、単に「*」があるだけ。
0553デフォルトの名無しさん2010/04/10(土) 12:10:31
>>514
>>538
0554デフォルトの名無しさん2010/04/10(土) 12:14:14
>>520
確かに。
新言語は、ドミノ倒しくらいにシンプルにしたいな。
0555デフォルトの名無しさん2010/04/10(土) 12:20:48
gotoは必須
0556デフォルトの名無しさん2010/04/10(土) 12:24:44
>554
だったらForthだろ。あるいは類似のConcatenative言語か。
後置・命令主体の言語ならTMの動作原理に近くなるから低水準にはちょうど良いぜ。
まあ、操作対象をスタックじゃなくてテープにしたBFはやり過ぎだと思うけど。
0557デフォルトの名無しさん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;
--}
}
0558デフォルトの名無しさん2010/04/10(土) 12:47:16
>>557
いやもういいから
0559デフォルトの名無しさん2010/04/10(土) 12:47:46
 位覚えろ
0560デフォルトの名無しさん2010/04/10(土) 12:51:22
>>514
初心者すぎる消えろ
0561デフォルトの名無しさん2010/04/10(土) 12:57:27
初心者しかいないんだからいいじゃん
0562デフォルトの名無しさん2010/04/10(土) 13:01:10
>557
ライブラリとしてトランスレーター用意すればいいだろ……
さらに言うと呼び出し規約を整理してリンクできるようにしておけば良いだけの話。
コアで話すようなことじゃ無いよ。

>108とか情報科学とか勉強しているやつはいないのかしらん？「計算理論の基礎」は良い本だと思ったけど、誰か読んだ？
0563デフォルトの名無しさん2010/04/10(土) 13:33:52
「～なやつ」はもういいから。ウザイって。
0564デフォルトの名無しさん2010/04/10(土) 13:37:06
stdout, stderr, stdinといった標準デバイスという概念も古いよな。
0565デフォルトの名無しさん2010/04/10(土) 13:38:02
何が新しいの？
0566デフォルトの名無しさん2010/04/10(土) 13:39:34
int型の 代入と 四則演算 のみを解釈できるインタープリタ作りからはじめれば？最初から最先端をやろうとせずに。
0567デフォルトの名無しさん2010/04/10(土) 13:40:41
>>566
そんなのすでにやってるから。やりたければお前が一人で学習してろ。
0568デフォルトの名無しさん2010/04/10(土) 13:41:23
うんうん、ラベルのパーズも大変だから飛び先は行番号でいいね
0569デフォルトの名無しさん2010/04/10(土) 13:46:12
forとかwhileもめんどくさいからif～thenとgotoがあればいいよね
あ、サブルーチンはさすがに必要だな、gosubとでもするか
0570デフォルトの名無しさん2010/04/10(土) 13:47:24
>>561
FORTHの最大の利点はハードの抽象化レイヤーが非常に薄いということだね。
しかし一番の欠点は方言が多すぎるのとGPL実装がほとんどということかな。

んで出るのが20年早すぎたトランスピュータ生まれのOccamとかどうなんだろうな。
あれもある意味では組み込みに近いよな。
0571デフォルトの名無しさん2010/04/10(土) 13:52:11
よし、>>567が作ったインタープリタかコンパイラをみんなで評価しよう。どこかにアップしてくれ。
0572デフォルトの名無しさん2010/04/10(土) 13:54:18
処理系の作りやすさよりも、先ずは使い易い言語仕様を考えよう。

実装の話は言語仕様が固まってからだ。
0573デフォルトの名無しさん2010/04/10(土) 13:59:16
>>552
ポインタのアドレス型ってのが独立してあれば良くないか？
0574デフォルトの名無しさん2010/04/10(土) 14:00:29
意味不明
0575デフォルトの名無しさん2010/04/10(土) 14:02:00
修正バージョンアップを繰り返すんだから、仕様が固まる事などないよ。
こう言う場合は、仕様と実装を並行してやるしかない。
0576デフォルトの名無しさん2010/04/10(土) 14:04:50
>>575
それでは、どうぞ実装を勧めてください。

ただし、実装者のスキル不足に引っ張られて言語仕様を妥協しない方がいい。
0577デフォルトの名無しさん2010/04/10(土) 14:07:54
えっ スキル不足で俺には無理ですよ。誰かやってくれるんじゃないの？
0578デフォルトの名無しさん2010/04/10(土) 14:12:14
>570
Occamかあ。
プロセスの抽象化は魅力的なんだけど、重たくなったりしないのかな？
あと、式の中身自体は普通の命令型の処理だよね？命令型の部分はどうしよう？
0579デフォルトの名無しさん2010/04/10(土) 14:26:14
>>478
同じだろ。*は単独では型を表せないし
優先高いから変数にくっつける
c++は言語も汚いが慣習も理にかなわないからキライ
0580デフォルトの名無しさん2010/04/10(土) 14:30:12
>>499
でgoができるワケだな
0581デフォルトの名無しさん2010/04/10(土) 14:31:40
>>503
apple script w
読めるがかけねえ
0582デフォルトの名無しさん2010/04/10(土) 14:40:49
>>538
今でも組み込みだと内部メモリと
外部のSDRAMで速度差あるから
普通にリンカスクリプトとattributeで使い分けるよ
0583デフォルトの名無しさん2010/04/10(土) 15:00:34
>>570
Occum は Transputer のアセンブラだから、その意味では C より低水準で、
かつ、C に比べればずっと先進的な言語仕様だよね。
0584デフォルトの名無しさん2010/04/10(土) 15:18:11
Transputerか。レジスタマシンでエミュレートすることを前提とするとセマンティックギャップがすごくなりそう。
効率的な変換器があったりするのかな？
0585デフォルトの名無しさん2010/04/10(土) 15:22:05
>>579
全然違う。そもそも両者はコンパイラだって区別して扱っている。
同じならコンパイラも区別せず統一的に扱えるはず。
0586デフォルトの名無しさん2010/04/10(土) 15:43:58
C#最強ってこと
0587デフォルトの名無しさん2010/04/10(土) 15:48:49
行番号で直接コードをメモリアドレスに割り当てられるようにしようぜ
0588デフォルトの名無しさん2010/04/10(土) 16:43:45
引数をレジスタ渡し一択
返値は逆にリッチにしてスタック上のリスト+レジスタ。

関数革命
0589デフォルトの名無しさん2010/04/10(土) 16:47:38
初心者の集まりだったが、アホの集まりになったな。
0590デフォルトの名無しさん2010/04/10(土) 16:54:06
ま、言語で云々ってレベルでは大したことないな
アルゴリズムで勝負するのが一番の高速化手法
0591デフォルトの名無しさん2010/04/10(土) 18:25:44
どんな言語を作るとしてもアセンブラに変換→マシン語(バイナリ)なんだから
結局はC言語に似たり寄ったりになる
0592デフォルトの名無しさん2010/04/10(土) 18:29:50
目標はhaskell
0593デフォルトの名無しさん2010/04/10(土) 18:32:01
>>590
けど、LLじゃどんなに正しくクイックソートを書いても配列の計算で無駄な事してるから
どう頑張ってもCで書いたのには勝てないんだなぁ。
0594デフォルトの名無しさん2010/04/10(土) 18:54:47
配列は全てsentinel方式に固定
0595デフォルトの名無しさん2010/04/10(土) 20:00:51
ダサすぎるだろ
0596デフォルトの名無しさん2010/04/10(土) 20:19:04
>>586
C# は unsafe でポインタ使ってカリカリのコード書いても
何故か C より遅いのが嫌なんだよなあ。
結局 C++/CLI と連携したりしなきゃならなくなる。
JIT 改善してくれれば良いのに。
0597デフォルトの名無しさん2010/04/10(土) 20:22:26
>>596
DllImportしろ
0598デフォルトの名無しさん2010/04/10(土) 20:26:26
つーかこの糞スレ、パート2かよ。ようやるわ
0599デフォルトの名無しさん2010/04/10(土) 20:28:09
C#じゃなくていいけど、プロパティの仕組みは欲しいよな。

あとC言語の引数を括弧で囲むのもやめてほしい。
理由は関数合成が汚く見えるから。
0600デフォルトの名無しさん2010/04/10(土) 20:31:31
>>599
> あとC言語の引数を括弧で囲むのもやめてほしい。
どうしろと？
0601デフォルトの名無しさん2010/04/10(土) 20:33:48
>>599
VB6使えば？
0602デフォルトの名無しさん2010/04/10(土) 20:36:39
引数を括弧で囲むんじゃなくて、括弧で囲んでいるのが関数なんだよ。
でないと変数と区別がつかなくなる。
0603デフォルトの名無しさん2010/04/10(土) 20:37:11
>>601
VBでも、関数は括弧必須だろ
0604デフォルトの名無しさん2010/04/10(土) 20:39:32
>>602
関数として宣言するし、名前はユニークなんだから区別はつくでしょ。
MLとかHaskellでは引数に括弧はいらないよ。
0605デフォルトの名無しさん2010/04/10(土) 20:44:41
関数型言語みたいに高階関数を引数にとるわけじゃないなら
括弧あった方が読みやすい
0606デフォルトの名無しさん2010/04/10(土) 20:57:28
紙に印刷されたものを読むときは特に。
0607デフォルトの名無しさん2010/04/10(土) 21:00:31
開発と名がついてる内でトップレベルの糞スレなのに不思議と伸びるよな
0608デフォルトの名無しさん2010/04/10(土) 21:01:29
アセンブリ言語への変換を考えても、
高階関数を採用しても何ら問題ないように思う。
0609デフォルトの名無しさん2010/04/10(土) 21:02:16
俺言語作っているやつの冷やかしが混ざっているから。
協力する気は毛頭無いだろうけど。
0610デフォルトの名無しさん2010/04/10(土) 21:02:53
バザールモデルでモノが出来上がるわけがない。
何スレ使ったって無駄だよ。
0611デフォルトの名無しさん2010/04/10(土) 21:07:18
Cに代わるものといいながら、Cの欠点としてマクロとヘッダしか上がってこない。
0612デフォルトの名無しさん2010/04/10(土) 21:08:37
ポインタ演算・・は必要悪的なところがあるな
それより文字列をどうにかすべき
0613a36 ◆K0BqlCB3.k 2010/04/10(土) 21:08:41
>>610
このスレみたいな開発スタイルは伽藍でもバザールでもなくて、
お互いに顔も名前も知らない多数の人間同士が話しあって何かを決めるスタイルだ。
名前が無いので付けるとしたら匿名直接民主主義スタイル。
しかし、俺の経験上、何かを決めるためには少数の、
それも３人以下の人数でないと何も決まらない。
0614デフォルトの名無しさん2010/04/10(土) 21:16:07
>>611
じゃあ欠点挙げてやるよ。
○関数のデフォルトがグローバル
○static関数や変数でもプロトタイプが必要
○ポインタの宣言が難解
○二つの異なる動作が同じstaticキーワードで表現される
（staticグローバル変数と関数内static変数ね。実はアセンブラ的に考えると
同じ動作なのだが、アセンブラに興味のないプログラマには異なる動作と映る）
○switch-caseのデフォルトがfall thruough
○返り値のデフォルトがint
○演算子の記号が結構てきとう
○優先順位はもっとてきとう
0615デフォルトの名無しさん2010/04/10(土) 21:18:02
>>608
同意。
最新のオサレ機能でパフォーマンスに影響を与えない機能は備えたいな。
0616デフォルトの名無しさん2010/04/10(土) 21:19:27
>>615
それはもはや低級言語ではないな。
0617デフォルトの名無しさん2010/04/10(土) 21:25:18
このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義しよう。
0618デフォルトの名無しさん2010/04/10(土) 21:28:39
OSに依存する機能は入れないということでいいね。
0619デフォルトの名無しさん2010/04/10(土) 21:33:37
CでもOS依存部分はライブラリだしな
0620デフォルトの名無しさん2010/04/10(土) 21:37:01
>611
>4読んで消えてしまえ
0621デフォルトの名無しさん2010/04/10(土) 21:38:06
OS依存機能はライブラリでいいけど、組み込みの機能がライブラリを呼び出してもいいんじゃない？
スレッドとか正規表現リテラルとかはあって欲しいな。

当然ライブラリが無ければその機能は使えないけど、
OSを作る人はそのあたりは理解してどこまで使えるか考えながら使うでしょ。
0622デフォルトの名無しさん2010/04/10(土) 21:42:18
正規表現を言語仕様にだぁ？ご冗談を。それのどこが低級言語だよ。
0623デフォルトの名無しさん2010/04/10(土) 21:43:44
ここの低級言語だ。
0624デフォルトの名無しさん2010/04/10(土) 21:45:16
正規表現はOSに依存しなさそうだけど、文字列型は依存してしまいそう。
0625デフォルトの名無しさん2010/04/10(土) 21:45:35
正規表現は高度な機能ではあるが、上層とか下層とかそういう次元の物ではないだろう
0626デフォルトの名無しさん2010/04/10(土) 21:46:51
スレッドも正規表現も、ライブラリで対応って言ってるだろ
0627デフォルトの名無しさん2010/04/10(土) 21:48:44
言語がリテラルを定義する機能を持てば、正規表現リテラルはなくてもいいかな。
むしろそっちの方がいいか。

言語がリテラルを定義する機能を持ち、
標準ライブラリが正規表現リテラルを提供してくれればそれでいい。
0628a36 ◆K0BqlCB3.k 2010/04/10(土) 21:48:52
>>622
言語仕様として定義されている組み込みライブラリに正規表現を含めるなら特に問題ないんじゃない。
0629デフォルトの名無しさん2010/04/10(土) 21:50:47
「本で読んだことそのまま言ってるんだろうな…w」　ってレスがチラチラあるね…
0630デフォルトの名無しさん2010/04/10(土) 21:50:53
明にか暗にかはわからないが、マルチスレッドに対応する機能は言語仕様に備えるべきだな。
0631デフォルトの名無しさん2010/04/10(土) 21:51:41
>>626
それじゃサブセットの言語があるのと同じだからだめだよ。Cに対するC++のようなもの。スレタイはこのさい関係ない。
0632デフォルトの名無しさん2010/04/10(土) 21:52:46
だから、OS前提の機能を標準ライブラリに入れるな。
0633デフォルトの名無しさん2010/04/10(土) 21:52:55
言語がリテラルを定義する機能を持つなら、
言語コア仕様が文字列リテラルを持たなくても、標準ライブラリで文字列リテラルを提供してくれればいいよ。
0634デフォルトの名無しさん2010/04/10(土) 21:55:09
>>613
ここまで読んで思い付いたのだが「烏合の衆モデル」てのはどうよ？
当然、成果物は得られないｗ
0635デフォルトの名無しさん2010/04/10(土) 21:57:22
>>1
OS前提の機能ってなんだよ？

標準出力
ファイル
スレッド
プロセス
メモリー
ネットワーク
グラフィックス
は、一般的なOSが提供するよな？
0636a36 ◆K0BqlCB3.k 2010/04/10(土) 21:58:12
>>629
悪かったよ。
さっき ハインライン の 月は無慈悲な夜の女王 を読みきったところなんだよ。
0637デフォルトの名無しさん2010/04/10(土) 22:01:19
文字列処理の機能があっても良いと思うけど、正規表現じゃなくてPEGだろ。
0638デフォルトの名無しさん2010/04/10(土) 22:01:53
PEGって何？
0639デフォルトの名無しさん2010/04/10(土) 22:01:57
>>632
CのライブラリのほとんどはOS前提だが。
0640デフォルトの名無しさん2010/04/10(土) 22:07:13
>>636
同志
0641デフォルトの名無しさん2010/04/10(土) 22:08:50
>>637
解析表現文法（かいせきひょうげんぶんぽう、英: Parsing expression grammar, PEG）
か。

正規表現にとって代われるものならこれもあってもいいけど、
使い慣れている人が多いから正規表現も必要だろうな。
0642デフォルトの名無しさん2010/04/10(土) 22:14:31
>641
PEGは基本的にLL(∞)+αだから表現力は問題なし。
LLベースだから再帰との相性もいいし、パーツ毎の独立性も高い。

問題はトラックバックが多いと性能悪化することだけど、まあ気にすんな。
0643デフォルトの名無しさん2010/04/10(土) 22:15:04
>>639
string関連のライブラリのほとんどはOSなしで書けるんじゃね
memcpy, memcmpとかも書けるし
stdioはもちろんOSないとダメだけども
0644デフォルトの名無しさん2010/04/10(土) 22:16:35
言語仕様とライブラリが混同してるな
0645デフォルトの名無しさん2010/04/10(土) 22:20:38
言語仕様でも標準ライブラリでもOSの機能を使っていいよ。

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

デバドラ屋にとっては問題ないし。
0646デフォルトの名無しさん2010/04/10(土) 22:23:45
ところでお前ら何歳だよ
物知ってるな
0647デフォルトの名無しさん2010/04/10(土) 22:24:20
>>644
追加インストールしなくても使えることが保証されてる標準ライブラリは言語仕様の一部だよ。
0648デフォルトの名無しさん2010/04/10(土) 22:25:02
言語仕様がどんなものか判ってないんだろ。
ForthとLisp、Fortran、BASIC、BF、C辺りの違いがわかるやつも少そうだし。
0649デフォルトの名無しさん2010/04/10(土) 22:25:31
ガベコレに依存するオブジェクトシステム
に依存する文字列は、言語仕様なのかライブラリなのか
0650デフォルトの名無しさん2010/04/10(土) 22:25:42
>>645
使えない機能があるんだったら、はじめから仕様からはずしておくべき。
OSの機能を使っていいということになったら、ぜひとも入れたいという機能はいくらでも出てくる。
0651デフォルトの名無しさん2010/04/10(土) 22:26:17
>>648
「やつ」の話はいらないって。
0652デフォルトの名無しさん2010/04/10(土) 22:28:08
？
0653デフォルトの名無しさん2010/04/10(土) 22:32:13
マ板のオブジェクト指向スレと流れが似てる。
0654デフォルトの名無しさん2010/04/10(土) 22:33:36
>>650
例えば、
ヒープを確保するためにライブラリ関数を呼び出すのは美しくない。
言語仕様が備える機能で確保したい。
0655デフォルトの名無しさん2010/04/10(土) 22:34:35
>>654
へ？ヒープはOSのサービスだろ？言語仕様関係ないべ？
0656デフォルトの名無しさん2010/04/10(土) 22:36:02
だから、OSが提供する機能であっても言語仕様に含めるべきだと言ってるんだって。

OSのサービスは言語仕様と関係ないと初めから決めつけるようなことではない。
0657デフォルトの名無しさん2010/04/10(土) 22:44:34
そこで仮想レジスタ構文登場
0658デフォルトの名無しさん2010/04/10(土) 22:46:56
言語仕様にOSが提供する機能を入れたら、それはここで言う低級言語ではない。
0659デフォルトの名無しさん2010/04/10(土) 22:48:28
>>10
0660デフォルトの名無しさん2010/04/10(土) 22:49:24
>>656
それってつまり、C++のnewが内部でOSのシステムコールMALLOCを呼んでる
（実際には間にCライブラリmalloc()が入る）みたいにしたいってことかい？
そういうふうに勝手にOSシステムコールしちゃう言語だと、OS書けなくなるけどいいの？
0661デフォルトの名無しさん2010/04/10(土) 22:51:00
>>657
仮想マシンのバイトコードから現実のマシン語かアセンブラへの変換は難しいと思う。
それができるならx86からarmへのアプリのバイナリ変換による移植も容易くできる事になるが、
実際には難しいよね。
0662デフォルトの名無しさん2010/04/10(土) 22:55:13
難しい部分はレジスタセット定義を環境別に用意して実装も別にする位じゃなきゃ
Cを超える事なんて出来んので

仮想レジスタ構文なんだよ
0663デフォルトの名無しさん2010/04/10(土) 22:55:13
このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義する。
0664デフォルトの名無しさん2010/04/10(土) 22:56:24
>>660
OS作る人は使えない機能があって困惑するかもしれないけど、
そもそもOS作る人がコンパイラを作る（またはポーティングする）んだろうから問題ないよ。
使えるようになった機能から使うようにすればいい。
0665デフォルトの名無しさん2010/04/10(土) 22:57:04
>>660
いつから malloc がシステムコールになったのか詳しく
0666デフォルトの名無しさん2010/04/10(土) 22:57:30
>>664
先生それならCで書いたほうが早いですｗ
0667デフォルトの名無しさん2010/04/10(土) 22:58:07
>>666
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
0668デフォルトの名無しさん2010/04/10(土) 22:58:35
>>665
mallocってシステムコールじゃないの？
てか用語が間違ってるのかな。OSのサービスって言えばいい？
0669デフォルトの名無しさん2010/04/10(土) 22:59:55
>>612
低水準なら、直接いじるって方法を捨てるわけにはいかんわなぁ。
C++のstringじゃ不満かい？
0670デフォルトの名無しさん2010/04/10(土) 23:00:03
>>667
無駄な再発明したって仕方ないだろ
Cで書いたほうが早いじゃんって言われるような言語に何の意味がある
0671デフォルトの名無しさん2010/04/10(土) 23:00:21
mallocはCの標準ライブラリで、mallocの中でOSのシステムコールを呼ぶ。
0672デフォルトの名無しさん2010/04/10(土) 23:01:44
>>664
先生、あとOS作る人はコンパイラ作りません。
0673デフォルトの名無しさん2010/04/10(土) 23:02:58
mallocはCの仕様で記述できるからOSの機能と呼ぶ必然性はない
OSと連携したほうが高機能になるが
0674デフォルトの名無しさん2010/04/10(土) 23:03:10
>>671
X68000とかはシステムコール名がMALLOCだったわけだがそんなの出すのは反則ですか
0675デフォルトの名無しさん2010/04/10(土) 23:03:25
>>668
> mallocってシステムコールじゃないの？
普通, brk/sblk とか malloc 使って全く別のインターフェースとして実装されてる
0676デフォルトの名無しさん2010/04/10(土) 23:03:35
と、まぁ同じ事の堂々巡りにしかならない糞スレなんだから
次スレとか要らないよ　＞アイちゃん。
0677デフォルトの名無しさん2010/04/10(土) 23:04:46
>>673
意味がよくわからない。
OSシステムコールを一切使わず、独立したコードでmallocが書けるって意味？
そんなこと出来ないはずだけど。
0678デフォルトの名無しさん2010/04/10(土) 23:05:01
>>674
malloc()とMALLOC()はCでは別物だよね。他の言語では知らんけど。
0679デフォルトの名無しさん2010/04/10(土) 23:05:27
>>672
OS じゃねぇけど, リアルタイムモニターもコンパイラも作ったが

0680デフォルトの名無しさん2010/04/10(土) 23:06:08
>>677
そのとおり。
少なくともどこかでOSに問い合わせてメモリーを確保しなければいけないからな。
0681デフォルトの名無しさん2010/04/10(土) 23:06:16
>>677
できますよ。
static char heap[1024*1024*HEAP_SIZE];
でこのメモリを管理。
組み込みでは一般的。
0682デフォルトの名無しさん2010/04/10(土) 23:07:32
>>681
そのheapをどこに配置するかは誰が管理してるんだよ。
0683デフォルトの名無しさん2010/04/10(土) 23:07:46
mallocもかけない奴が言語仕様語ってるのかｗ
0684デフォルトの名無しさん2010/04/10(土) 23:08:01
>>668
どのOSの話してるのかは知らんが、K&R第2版にあったUNIXでmallocを実装する例では、
間接的にsbrkシステムコールを使ってメモリを取得しているようだった。
0685デフォルトの名無しさん2010/04/10(土) 23:08:27
>>682
お前コード読めないの？
静的変数は言語仕様。
0686デフォルトの名無しさん2010/04/10(土) 23:09:11
>>681
それはインチキ。OS使わないんじゃなくて、OSがメモリ管理機能を持ってないだけじゃん。
0687デフォルトの名無しさん2010/04/10(土) 23:09:26
>>682
演算子は誰が実行してるんだよというくらいバカなレス
0688デフォルトの名無しさん2010/04/10(土) 23:10:10
>>682
組み込みの場合は, *.h とかってファイルにメモリーのサイズと共に
スタティックに書かれてることが多い
0689デフォルトの名無しさん2010/04/10(土) 23:10:21
>>686
このレベルがＯＳや言語仕様語ってるのかｗ
0690デフォルトの名無しさん2010/04/10(土) 23:11:56
>>681
それのどこがmalloc何だ？HEAP_SIZEが変数？
0691デフォルトの名無しさん2010/04/10(土) 23:12:04
唐突に見下されても意味わかんないし
0692デフォルトの名無しさん2010/04/10(土) 23:13:13
>>690
あっキミちょっと黙ってて
0693デフォルトの名無しさん2010/04/10(土) 23:13:33
やっべーメモリ管理も知らない奴が言語仕様てｗ
0694デフォルトの名無しさん2010/04/10(土) 23:13:38
見下してると言うより、着いていけなくて、俺の分からない話はするなーってことでしょ。
小学校の時よくいた。
0695デフォルトの名無しさん2010/04/10(土) 23:15:01
>>690の質問が余程きびしかったようだな。
必死にごまかそうとしている。>>692
0696デフォルトの名無しさん2010/04/10(土) 23:15:34
>>695
煽ってもみんなわかってるからｗ
0697デフォルトの名無しさん2010/04/10(土) 23:16:05
JavaやLL育ちのゆとりが、
8bitCPUレベルの組み込み用途にも使われるの言語について語るとか、マジ勘弁してくれ。
0698デフォルトの名無しさん2010/04/10(土) 23:16:26
mallocすからかけない奴が言語仕様てｗ
0699デフォルトの名無しさん2010/04/10(土) 23:16:40
>>690

俺681じゃないけど、こんなふうに実装すればできるよ。

void* malloc(size_t size)
{
return heap[]からsizeバイト確保したメモリを返す
}

void free(void* ptr)
{
ptrが指すメモリをheap[]に返す
}
0700デフォルトの名無しさん2010/04/10(土) 23:18:10
void *malloc(size_t size);
は与えられたサイズ分のメモリーをヒープに確保してそのアドレスを戻り値に返す。

>>681は少なくともmallocの実装にはなっていないけど、どうなってるの？
0701デフォルトの名無しさん2010/04/10(土) 23:18:10
「メモリ管理はOSさんがやってくれないと何もできません」
こんな奴が「言語仕様」ｗｗｗ
0702デフォルトの名無しさん2010/04/10(土) 23:19:01
おまえは全ソースコードがないと理解できないのか。
いやソースあっても理解できないな・・・
0703デフォルトの名無しさん2010/04/10(土) 23:19:07
なんかファビョってるのがいるな
0704デフォルトの名無しさん2010/04/10(土) 23:19:58
スタックすら理解できなさそう
0705デフォルトの名無しさん2010/04/10(土) 23:20:58
リンカすらOSと言い出しそう
0706デフォルトの名無しさん2010/04/10(土) 23:20:59
>>699了解。
>>700を書き込んでからそれを読んだ。
0707デフォルトの名無しさん2010/04/10(土) 23:21:55
>>706
だから黙っててと書いたのに。。。LL育ちがばれちゃったね。
0708デフォルトの名無しさん2010/04/10(土) 23:24:56
薄識でも相手にしてもらえるスレ見つけてハイテンションになってる奴が巣くってるんだよ。
0709デフォルトの名無しさん2010/04/10(土) 23:25:48
mallocを呼び出した後か前かは別にして、メモリーを確保するためにはどこかでOSにお伺い（システムコール）をたてる必要はある。

OSがメモリーを管理しているのであれば、>>681にしてもどこかでOSにお伺いをたてる必要がある。
0710デフォルトの名無しさん2010/04/10(土) 23:26:05
リンカはＯＳだろ。知らなかったのか？バカじゃん？
0711デフォルトの名無しさん2010/04/10(土) 23:26:41
>>709-710
0712デフォルトの名無しさん2010/04/10(土) 23:28:45
リンカーがOSというのは語弊があるが、少なくともリンカーはOSが実行可能な形式のバイナリーを生成する。
だから、リンカーはOSに依存する。
0713デフォルトの名無しさん2010/04/10(土) 23:28:53
ネタレスはいいから
0714デフォルトの名無しさん2010/04/10(土) 23:29:32
動的リンクはOSに入りますか？
0715デフォルトの名無しさん2010/04/10(土) 23:30:01
メモリのことは環境によって大違いなわけだから、OSが受け持つ仕事だろ。
0716デフォルトの名無しさん2010/04/10(土) 23:30:25
いきなり０番地からのバイナリを吐き出すコンパイラとかの想像もできないのか
0717デフォルトの名無しさん2010/04/10(土) 23:30:35
>>714
動的リンクはOSに入らないが、動的リンクの機能はOSに依存する。
0718デフォルトの名無しさん2010/04/10(土) 23:31:08
言語仕様の話と実装の話が混乱しすぎ
0719デフォルトの名無しさん2010/04/10(土) 23:31:10
2chはバカしかいなくなってしまった。
10年前に戻りたい。
0720デフォルトの名無しさん2010/04/10(土) 23:31:56
>>719
他に居場所がないなら仕方ない
0721デフォルトの名無しさん2010/04/10(土) 23:32:10
全員バカ、という奴が一番バカなのは古くからの常識
0722デフォルトの名無しさん2010/04/10(土) 23:32:18
>>718
どう混乱しているのか具体的に
0723デフォルトの名無しさん2010/04/10(土) 23:32:54
本物の初心者なんですが、コンパイルされた機械語（ROM？）は、どのCPUでも同じように動きますか？
0724デフォルトの名無しさん2010/04/10(土) 23:33:29
>>723
動かない。
0725デフォルトの名無しさん2010/04/10(土) 23:34:08
>>724
そうですか・・・
0726デフォルトの名無しさん2010/04/10(土) 23:34:27
ROMてのはどっからきたんだｗ
0727デフォルトの名無しさん2010/04/10(土) 23:35:29
マイコンに焼き付けるROMのことだろう
0728デフォルトの名無しさん2010/04/10(土) 23:35:49
>>722
Ｃの仕様で記述できるものはどう実装されていようとかまわない。
実装がＯＳの機能を使おうと使わなかろうと本来関係がない。
知っている実装系がＯＳの機能を使っていようとも。
0729デフォルトの名無しさん2010/04/10(土) 23:37:57
標準ライブラリはCの言語仕様ではない。
main関数すら慣例であって必須ではない。
OSレス、ディスクレス、コンソールレスの
組み込みシステムでも、簡単なレジスタと
メモリの初期化だけアセンブラで残して
後はすべてCで記述するとかいうことは
大昔から普通に行われている。
printfも自前のライブラリで実装とか当たり前だ。
そうした用途に使える言語はCしかない。
0730デフォルトの名無しさん2010/04/10(土) 23:38:51
>>728
ああ、それなら完全に同意。
煽ってるだけかと思った。
0731デフォルトの名無しさん2010/04/10(土) 23:39:35
とにかく、Cの場合、OSに依存している部分はライブラリに分離され、言語自身はOSとは独立している。
0732デフォルトの名無しさん2010/04/10(土) 23:40:09
mallocは置いておいて、

OS無しの組み込み開発で使われることもあるプログラミング言語の
言語仕様にマルチスレッドを標準装備しろとか有り得ない。
0733デフォルトの名無しさん2010/04/10(土) 23:41:00
malloc使えない香具師を罵倒して悦に入ってる香具師は
mallocの実装を自分で書いたこともないのだろう
0734デフォルトの名無しさん2010/04/10(土) 23:41:27
>>729
あったねー
ゲーム機とかそんな感じだったね。
ライブラリ皆無で、memcpyやらstrcmpやらも自前で作ったｗ
もちろんmallocも。
printfは面倒だから作らなかったけど。
C以外でこれをやれって言われても、めんどくせえからやだ、で終わりだわな。
>>1はこういう経験あるんだろうか。
LL脳が粋がってわめいてるだけにしか思えないのだが。
0735デフォルトの名無しさん2010/04/10(土) 23:42:32
>>732
ライブラリでなく言語仕様に標準装備って例えばどんなの？
0736デフォルトの名無しさん2010/04/10(土) 23:43:50
>>721
ひろゆきもバカだけど年収１億超え＾＾
0737デフォルトの名無しさん2010/04/10(土) 23:45:44
>>630 とか
0738デフォルトの名無しさん2010/04/10(土) 23:46:40
Erlangのことか
0739デフォルトの名無しさん2010/04/10(土) 23:47:25
言語仕様に文字列処理を含めたとしても、「但し文字列処理を使うためには標準ライブラリの”String”を実装してください」、というような仕様でもいいよ。
OS屋は文字列処理を使いたかったら、先ず”String”を実装して、それから文字列処理を使えばいい。

言語仕様のフル機能が常に揃っていなければいけないことはないわけだし。
0740デフォルトの名無しさん2010/04/10(土) 23:49:30
>>739
それでは、実質的にStringがない別の言語があるのと同じ。
0741デフォルトの名無しさん2010/04/10(土) 23:50:19
標準ライブラリってOS屋が作るものか？
0742デフォルトの名無しさん2010/04/10(土) 23:51:56
言語仕様に含まれていれば、
if(!strcmp(str1, str2))
↑こんなことせずに
↓こうできる
if(str1 == str2)
0743デフォルトの名無しさん2010/04/10(土) 23:52:07
いつもの俺ルールなんだろ
0744デフォルトの名無しさん2010/04/10(土) 23:53:09
副作用なくして並列処理可能な言語仕様自体はできるとおもうが。
0745デフォルトの名無しさん2010/04/10(土) 23:53:34
>>742
LL臭がプンプンする。。。
if (str1 == str2) には別の意味があるってのに。。。
0746デフォルトの名無しさん2010/04/10(土) 23:54:08
本物の初心者なんですが、C言語の標準ライブラリというのは、
オブジェクト指向のダックタイピングみたいなもんですか？
0747デフォルトの名無しさん2010/04/10(土) 23:54:32
文字列処理をライブラリに追い出すのがC/C++のコンセプトだと思うが。
0748デフォルトの名無しさん2010/04/10(土) 23:54:38
>>745
>>742は例だ。何言語かも言及してないし、意味も定義していない。「別の意味」も何もない。
単に構文が簡単になるということを言っている。
0749デフォルトの名無しさん2010/04/10(土) 23:55:07
>>744
時代に沿った流れとしては、低レベルでネイティブな並列処理が欲しい所ではある
0750デフォルトの名無しさん2010/04/10(土) 23:55:42
>>742
Java
0751デフォルトの名無しさん2010/04/10(土) 23:55:54
おまいらフロー制御はbool分岐だけなの？
もっとプリミティブなところ考えようぜ
0752デフォルトの名無しさん2010/04/10(土) 23:56:15
>>749
イメージできてそのレスしてる？
0753デフォルトの名無しさん2010/04/10(土) 23:56:56
>>749
欲しいね。
0754デフォルトの名無しさん2010/04/10(土) 23:57:35
>>751
fortranの算術ifでも復活させたいのかね
0755デフォルトの名無しさん2010/04/10(土) 23:57:44
低レベル並列処理ってなんだよｗ
0756デフォルトの名無しさん2010/04/11(日) 00:00:09
>>755
どのコアで実行させるかとか、そう言うのじゃないの。

メモリーアドレスをポインター変数で隠蔽するように、コア番号を隠蔽するコア変数みたいのとか。
0757デフォルトの名無しさん2010/04/11(日) 00:00:43
CPU1個,OS無しの状態で、言語仕様だけで並列処理が出来るのか考えてもらおうか
0758デフォルトの名無しさん2010/04/11(日) 00:00:52
言いたいことはわかるけど、なんか表現が違う
0759デフォルトの名無しさん2010/04/11(日) 00:01:28
>>758
どういう表現がいい？
0760デフォルトの名無しさん2010/04/11(日) 00:02:23
Ｃってノイマン型ならコンパイラがライブラリもほとんどなくネイティブに変換する抽象アセンブラなイメージ
0761デフォルトの名無しさん2010/04/11(日) 00:02:32
左手でゆりかごをゆらし、右手でプログラミングするってことじゃないの
0762デフォルトの名無しさん2010/04/11(日) 00:03:36
>755
ルーチンにスレッド付けるかどうかを言語側でサポートする手もあるわな。
単にコルーチン・ファイバーに対応しても良いけど。

>754
パターンマッチングだのマルチスレッドだのいくつかあるぜ。
0763デフォルトの名無しさん2010/04/11(日) 00:04:55
最近の言語でさえ、とりいれられているものはほんの一部である並列処理を、なぜ切望する？
0764デフォルトの名無しさん2010/04/11(日) 00:05:13
>>757
並列処理を使いたい人が、並列処理を行うための機能を実装するんだろうね。
言語仕様としては、「並列処理を行う場合は”Thread”ライブラリを実装してください。」でいいと思うよ。
0765デフォルトの名無しさん2010/04/11(日) 00:05:51
抽象化しなきゃ意味がない前提なのにコアの指定とか矛盾。
並列化可能にしやすい言語仕様にしてインラインアセンブラみたいなものや
プラットフォーム用ライブラリで最適化支援するしかないと思うが。
0766デフォルトの名無しさん2010/04/11(日) 00:05:59
CPU１個だと並列処理させると普通に処理するより遅くなるんジャマイカ
0767デフォルトの名無しさん2010/04/11(日) 00:06:11
そのスレッドを管理するのは誰なんだよ、　ライブラリかｗ
0768デフォルトの名無しさん2010/04/11(日) 00:07:19
>>767
OSに頼れないなら、ライブラリだろうな。それ以外何がある？
0769デフォルトの名無しさん2010/04/11(日) 00:08:41
リンカだな
0770デフォルトの名無しさん2010/04/11(日) 00:10:05
なんか人工無脳がいるな
0771デフォルトの名無しさん2010/04/11(日) 00:10:29
>>765
だから、ポインタ変数に代入する値を出力するmallocやnewがあるように、
コア変数に代入するbeginthreadとかrunとかを定めるんだろ。

アドレス同様、コア番号を直接扱う必要は殆どないよ。
0772デフォルトの名無しさん2010/04/11(日) 00:12:13
並列化ってＯＳの仕事じゃないの？
0773デフォルトの名無しさん2010/04/11(日) 00:12:40
マルチコアのCPU前提で語らないでくれないか
0774デフォルトの名無しさん2010/04/11(日) 00:13:33
>>771
うーんお前あまり実装のイメージできてなくない？
スレッド管理って載ってるOSやCPUによってちがうだろ。
それをどう抽象化するつもりなの？
＞コア変数に代入するbeginthreadとかrunとかを定めるんだろ。
はライブラリにしか見えないけど。
そんなライブラリが載りやすい言語仕様という意味ならおれ多少アイディアあるけど。
0775デフォルトの名無しさん2010/04/11(日) 00:14:33
>mallocやnewがあるように
新言語のことは完全に忘れ去られているｗ
0776デフォルトの名無しさん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);
こんな感じで書けってか？
これってコアが４つとれない環境だとかえって遅くなるよ。。。
言語でやるのって意味ないと思うけど。OSの仕事だろ上皇。
0777デフォルトの名無しさん2010/04/11(日) 00:17:27
>>776
その場合はその構文使わなければいいのでは？
0778デフォルトの名無しさん2010/04/11(日) 00:19:13
>>776
どう見てもクラスライブラリｗ
0779デフォルトの名無しさん2010/04/11(日) 00:21:03
int cpuCount = getCPUCount();
Core *cpu = allocate_core(cpucount);
とかやれば・・・

って、書いてて思ったけど、
これ OS の APIじゃね？
0780デフォルトの名無しさん2010/04/11(日) 00:21:53
使えるコアの数を返すのはどの関数なんでしょうね。
0781デフォルトの名無しさん2010/04/11(日) 00:25:09
>>779
コーディング時に並列実行させたいタスクの数は静的に決まるから、
動的にCPU数を貰ってもあんまり良いことはない。むしろコードが複雑になる。
4個なら4個よこせってOS(じゃないんだっけ？ｗ)に訊いて、例えば３個しか
無い環境なら 0, 1, 2, 2 と返すとかしてくれないと使えない。

ていうか並列処理はＯＳの仕事でＦＡだろうけど。
0782 [―{}@{}@{}-] デフォルトの名無しさん2010/04/11(日) 00:27:12
ＯＳ依存は言語仕様外ってw

今時、そんな糞言語作って誰が使うんだ。
0783デフォルトの名無しさん2010/04/11(日) 00:27:43
ついてこれないなら無理にレスしなくていいよ
0784デフォルトの名無しさん2010/04/11(日) 00:29:13
いや正直俺もついていけてない
特に並列がどうとか正規表現がどうとかいうあたりｗ
0785デフォルトの名無しさん2010/04/11(日) 00:31:44
低レベルなシステム開発ってことは,
OS有りだけど, 直でI/O叩いたり,
OS無しのシステムだったり,
OS自体を作ったり・・・
って事でいいんかな.
0786デフォルトの名無しさん2010/04/11(日) 00:33:25
OS自体が作れる
これが出来ないと低級じゃないな
0787デフォルトの名無しさん2010/04/11(日) 00:33:45
迷ったときはとりあえず量子化すればいいんじゃね
0788デフォルトの名無しさん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…}
0789デフォルトの名無しさん2010/04/11(日) 00:34:34
>>785
そうだね。
但し、それらを行うときに新言語のフル機能が常に揃っている必要はなくて
新言語の一部機能は制限された形で開発することになるということはあるだろうね。
0790デフォルトの名無しさん2010/04/11(日) 00:35:01
CはインラインアセンブラなしにOSつくれないだろ
0791デフォルトの名無しさん2010/04/11(日) 00:36:48
となると, インラインアセンブラ(のような機能)は入れるべき?
0792デフォルトの名無しさん2010/04/11(日) 00:37:29
ご冗談を
アセンブラと一緒にリンクすれば作れますぜ
0793デフォルトの名無しさん2010/04/11(日) 00:38:21
じゃあリンクできればＣじゃなくてもいいな
0794デフォルトの名無しさん2010/04/11(日) 00:40:18
スタートアップルーチン必須の言語は無理ですぜダンナ
0795デフォルトの名無しさん2010/04/11(日) 00:42:55
OS本見ながらOSちょろっと書いてたとき思ったけど,
アセンブラ使わず, 1つの言語で全部できたらいいのにーって
思うのは俺だけだろうか・・・.

といっても, ブート部分とかCPU依存無しで,
書けるような言語って・・・できるのか?

0796デフォルトの名無しさん2010/04/11(日) 00:45:47
CPU側が言語仕様にあわせればできるだろうがそこまですることじゃないってこと。
0797デフォルトの名無しさん2010/04/11(日) 00:48:15
OSブート用のコンパイルオプションがあればできる
0798デフォルトの名無しさん2010/04/11(日) 00:49:14
どんなオプションだよｗ
0799デフォルトの名無しさん2010/04/11(日) 00:51:49
Linuxカーネルやgcc作ってる人って、どうせIBMやらredhatやらGoogleで働いてるｽｰﾊﾟｰﾊｯｶｰなんだろ
お前らにそんな人らの真似事なんか出来るんですか
0800デフォルトの名無しさん2010/04/11(日) 00:52:50
OSブート用のオプションさ！
0801デフォルトの名無しさん2010/04/11(日) 00:53:11
人生つぎ込めるなら出来ない仕事じゃないでしょう。品質や完成度が問題。
0802デフォルトの名無しさん2010/04/11(日) 00:53:26
>>799
出来る。
0803デフォルトの名無しさん2010/04/11(日) 00:54:03
イマイチつかめてないけど,
ロードするアドレスとかスタックサイズとか指定したら
OS無しの状態で, NEW言語で書かれたものが
動く環境まで出来ちゃうコードを自動生成するんかなぁ？

>> 799
あきらめちゃそこで終わりだ！
0804デフォルトの名無しさん2010/04/11(日) 00:54:34
CのCはChromeのC
0805デフォルトの名無しさん2010/04/11(日) 00:57:13
いろいろなツールをつかって、最適化なしでいいなら、Cコンパイラの製作自体は入門レベル。
0806デフォルトの名無しさん2010/04/11(日) 00:58:36
>>799
真似したくないんだろ
真似するだけならCでいいんだが
0807デフォルトの名無しさん2010/04/11(日) 00:58:43
とはいってもひとりで実装するのは結構メンドイけどね。
このスレに実装したことあるような人間がどのくらいいるのか。
おれは言語トランスレータしかつくったことない。
0808デフォルトの名無しさん2010/04/11(日) 01:01:53
>>742
演算子のオーバーロードがあれば、言語仕様に含まれてなくてもできるよ。
0809デフォルトの名無しさん2010/04/11(日) 01:02:19
仕事で簡易スクリプトぐらいしか・・・.
家では, yacc とか使わず Dでパーサ作ったぐらい orz.
0810デフォルトの名無しさん2010/04/11(日) 01:04:20
iPhoneアプリで大儲け出来るアイデアを考えた方が生産的
0811デフォルトの名無しさん2010/04/11(日) 01:04:36
そろそろ, 基本型とか欲しくないかい？
個人的には, 固定サイズの型があると嬉しいんだが・・・.
Cの環境依存は何かと・・・
char が 1 byte じゃない時とか移植コマッタゼヨ。。。

0812デフォルトの名無しさん2010/04/11(日) 01:05:24
C99のstdintじゃだめなん？
0813デフォルトの名無しさん2010/04/11(日) 01:05:52
最初のcharは、9bit
0814デフォルトの名無しさん2010/04/11(日) 01:08:58
それ、1byteだろ。
0815 [―{}@{}@{}-] デフォルトの名無しさん2010/04/11(日) 01:14:37
型は byte だけ。1バイトは8ビット固定。
２バイト以上が欲しければ byte(2) のようにする。
浮動小数やsigned/unsignedの区別は自分で行う。
08168112010/04/11(日) 01:14:46
あぁ・・・そうか. すみません.
1 byte が 9bit って書かないとだめでした. m(_ _)m
0817デフォルトの名無しさん2010/04/11(日) 01:17:04
つまらん議論
0818デフォルトの名無しさん2010/04/11(日) 01:17:45
仲間に入れて欲しいんだよね＾＾
0819デフォルトの名無しさん2010/04/11(日) 01:20:22
>>815
byte(8) x = 10;
byte(8) y = 3;
byte(8) z = x / y;

z には, 3 が入るん? それとも浮動小数?

0820デフォルトの名無しさん2010/04/11(日) 01:20:33
型とか他の言語でも改善されてるしC99でも規定されてるしなぁ。typedefもあるし。
0821デフォルトの名無しさん2010/04/11(日) 01:56:54
>>810
競争激化により110円か無料でしか見向きもされず、30%をappleに取られ、一体何が残るんだ？
0822デフォルトの名無しさん2010/04/11(日) 05:58:04
そろそろ次スレかな？
0823デフォルトの名無しさん2010/04/11(日) 07:37:59
>>821
知ったかでした
すみません
0824デフォルトの名無しさん2010/04/11(日) 07:41:12
>>821
９９ドルを知らない人
0825デフォルトの名無しさん2010/04/11(日) 09:09:54
>>815
死ぬほど使いにくい
0826デフォルトの名無しさん2010/04/11(日) 09:40:27
>>815
Ada
0827デフォルトの名無しさん2010/04/11(日) 11:20:28
>>597
遅いから C 使いたいだけなのになんで dllimport なんて
使わなきゃなんないんだよ。
一部のアセンブリを C++/CLI で方がずっと簡単じゃん。
0828デフォルトの名無しさん2010/04/11(日) 12:14:54
WebAPI対応しないの？
0829デフォルトの名無しさん2010/04/11(日) 13:56:47
↓この人が言語仕様をまとめます
0830デフォルトの名無しさん2010/04/11(日) 14:12:58
C/C++でいいじゃん
0831デフォルトの名無しさん2010/04/11(日) 14:14:57
ボインタのボインタのボインタって必要？
いやCなら出てくることがあるのはわかるけど
**までで良くない？
0832デフォルトの名無しさん2010/04/11(日) 14:19:01
だったら＊だけでいいだろ

なぜ＊＊なんだ？
0833デフォルトの名無しさん2010/04/11(日) 14:19:10
ボインボインうるさい
0834デフォルトの名無しさん2010/04/11(日) 14:21:05
メンバー参照は全部 . でいい。
0835デフォルトの名無しさん2010/04/11(日) 14:24:22
参照渡しは書き換えられてしまうので.じゃないほうがいい
0836デフォルトの名無しさん2010/04/11(日) 14:31:01
メモ渡しでＯＫ
0837デフォルトの名無しさん2010/04/11(日) 14:38:43
矢切りの渡しでOK
0838デフォルトの名無しさん2010/04/11(日) 14:56:00
参照渡しと . はどう関係するんだ？
0839デフォルトの名無しさん2010/04/11(日) 16:29:16
>838
c/c++の場合関係ない
0840デフォルトの名無しさん2010/04/11(日) 16:36:25
参照渡し禁止ってLapack禁止ってことですか？
行列演算どうしますか？
0841デフォルトの名無しさん2010/04/11(日) 16:40:43
参照を値渡し
0842デフォルトの名無しさん2010/04/11(日) 16:55:47
>>839
C/C++の場合の話を聞いているわけではなく、どのような場合に関係してどう関係するのかを聞いているんだろ。
0843デフォルトの名無しさん2010/04/11(日) 18:07:49
>>831
出来ないように改悪されて困る人はいても、誰も得しないだろ
0844デフォルトの名無しさん2010/04/11(日) 18:53:59
いまどき、マルチスレッドにも対応できないような言語は糞
0845デフォルトの名無しさん2010/04/11(日) 18:58:02
明示的なポインタなくしたらダメ？


void func(ref int val)
{
val = 1;
}

func(10); // コンパイルエラー

int x = 10;
func(x);
// x = 1になる.
0846デフォルトの名無しさん2010/04/11(日) 19:08:50
>>845
そんなの、いくらでもあるが。
0847デフォルトの名無しさん2010/04/11(日) 19:22:43
おまいらgolangみてみ
GC以外は理想的だぞ
さすがと言わざるを得ない言語仕様
0848デフォルトの名無しさん2010/04/11(日) 19:23:16
>>845
> 明示的なポインタなくしたらダメ？

なくすも何も、新言語はこれから作るのだが。
何をなくすかではなく、言語仕様に何を含めるかを語って欲しい。
0849デフォルトの名無しさん2010/04/11(日) 19:24:02
多値返してエラー処理とかめんどくせぇよ
0850デフォルトの名無しさん2010/04/11(日) 19:25:52
じゃあ、例外にする？
0851デフォルトの名無しさん2010/04/11(日) 19:27:40
例外の方がもっとめんどいし汚い
0852デフォルトの名無しさん2010/04/11(日) 19:31:07
ということで、多値返してエラー処理になります。
0853デフォルトの名無しさん2010/04/11(日) 19:34:23
タプルを(1,2,3)、リストを[1,2,3]、みたいな記法を直接構文に含めずに、
後からいつでもそういう記法を作ることができるような構文ってどういうふうに定義すればいいのでしょうか？
0854デフォルトの名無しさん2010/04/11(日) 19:39:30
Java がネイティブコンパイルに対応したら OK なんじゃね？
0855デフォルトの名無しさん2010/04/11(日) 19:42:19
C++風ならこんな感じじゃないの。bracketは予約語で。

独自括弧「」の定義として

MyBracket bracket「」(int v, ...){
　　処理;
　　return new MyBracket;
}
0856デフォルトの名無しさん2010/04/11(日) 19:42:40
>>847
if文で括弧がないのが致命的にイヤだ
0857デフォルトの名無しさん2010/04/11(日) 19:43:36
>>853
バックエンドを先に作る。フロントエンドは後で作る。
0858デフォルトの名無しさん2010/04/11(日) 20:21:43
>>854
それほとんどD言語だろｗ
0859デフォルトの名無しさん2010/04/11(日) 20:23:30
>847
マクロと駆動操作クレ。
サブルーチン縛りはやだ。
0860デフォルトの名無しさん2010/04/11(日) 20:24:04
Dの仕様が安定して、GCのつけはずしが可能になれば無問題
0861デフォルトの名無しさん2010/04/11(日) 20:29:10
お前ら普段どんな言語使ってるの？
主観で使用比率もつけて教えてくれ
0862デフォルトの名無しさん2010/04/11(日) 20:38:13
ぷっ、D やてw
0863デフォルトの名無しさん2010/04/11(日) 21:05:06
D言語で金になる案件はあるの？
0864デフォルトの名無しさん2010/04/11(日) 21:12:26
ないでしょ。ただのオナニー言語だからね。
0865デフォルトの名無しさん2010/04/11(日) 21:33:45
D言語って、何年か昔にドラフトが出た日に一度見たことはあるけど、厨臭い言語だなと思ったよ。
絶対流行らないってね。
0866デフォルトの名無しさん2010/04/11(日) 21:35:31
漏れも
0867デフォルトの名無しさん2010/04/11(日) 21:36:19
流行らせれば流行る、そういう可能性を秘めたのがD言語。
0868デフォルトの名無しさん2010/04/11(日) 21:38:56
>>867
人を納得させられるだけの材料がなければどんな言語も流行らないよ。
Dの売りはなんだ？
0869デフォルトの名無しさん2010/04/11(日) 21:40:42
ＣはUNIXの記述から流行ったんだっけ？
最近はJava,C#なんか企業戦略だよね。
LLはオープンソースかな？
0870デフォルトの名無しさん2010/04/11(日) 21:42:26
>>868
C/C++に代わる低級言語
0871デフォルトの名無しさん2010/04/11(日) 21:43:20
>>869
> ＣはUNIXの記述から流行ったんだっけ？
UnixのAPIがC言語の関数だったからCを使わざるを得なかったんだよ。
別にアセンブリ言語でも書けるけど、Cだと余計なことを考えずに関数を作るだけだからな。
0872デフォルトの名無しさん2010/04/11(日) 21:45:36
>>869
C は、抽象化されたノイマンマシンの高級アセンブラとして普及した
Unix の記述は、ある意味実証実験でしかない
0873デフォルトの名無しさん2010/04/11(日) 21:52:37
ある意味
0874デフォルトの名無しさん2010/04/11(日) 21:53:26
おまえらのそういうところ、嫌いじゃないぜ
0875デフォルトの名無しさん2010/04/11(日) 21:59:58
残念ながら片思いだ
0876デフォルトの名無しさん2010/04/11(日) 22:05:23
>>872
自動プログラミングっていえよｗ
0877デフォルトの名無しさん2010/04/11(日) 22:09:41
今最も平均年収が高いのはC#だよ
0878デフォルトの名無しさん2010/04/11(日) 22:11:49
銀行員の方が高い
0879デフォルトの名無しさん2010/04/11(日) 22:13:52
D言語はC言語よりも高度な処理を目的とした言語。
低級な処理には向かない

Object Cとか、Cから派生してる言語はいっぱいあるが、
低級処理ならCが最高
移植性は世界一
0880デフォルトの名無しさん2010/04/11(日) 22:15:13
お前らの作る糞アプリで移植するケースなんてあるの？
0881デフォルトの名無しさん2010/04/11(日) 22:16:47
>>880
俺らの作る糞アプリではなく、過去の巨匠たちが作った
コードを引き継ぐ必要がある
0882デフォルトの名無しさん2010/04/11(日) 22:16:50
C#の仕事って具体的にどんなの？
0883デフォルトの名無しさん2010/04/11(日) 22:18:14
CのシンプルさにJavaのシンプルな部分のみを追加して欲しい。
C++はひどい。
0884デフォルトの名無しさん2010/04/11(日) 22:19:02
>>882
ASP.NET
Windows Forms
XNA
WPF
Silverlight
0885デフォルトの名無しさん2010/04/11(日) 22:20:11
XNAて
Silverlight案件なんてあるの？
0886デフォルトの名無しさん2010/04/11(日) 22:21:54
>>885
まだない。
これからはある。




かもしれない。
0887デフォルトの名無しさん2010/04/11(日) 22:23:29
サーバーサイドでも３分の１はWindowsエコシステムの仕事。
基幹系であぐらをかいてる人間はそんな世界があることさえ知らない。
0888デフォルトの名無しさん2010/04/11(日) 22:23:30
>>884
このなかで実際にありそうな仕事って
＞ASP.NET
だけじゃね？
0889デフォルトの名無しさん2010/04/11(日) 22:26:23
>>888
XNAとかSilverlightは別にして、デスクトップアプリならありそうだが
0890デフォルトの名無しさん2010/04/11(日) 22:41:37
簡単に高機能が使えると低級じゃないのか？

おまえらの低級の定義って「初心者が使えないもの」なのか？
0891デフォルトの名無しさん2010/04/11(日) 22:44:27
>>890
スレを最初から読みなおせ
0892デフォルトの名無しさん2010/04/11(日) 22:49:07
この糞スレを最初から読むほど暇じゃないんで。
0893デフォルトの名無しさん2010/04/11(日) 22:50:40
レベル低すぎて煽りにもなってないｗ
0894デフォルトの名無しさん2010/04/11(日) 22:59:12
アルゴリズムを知らない単なるプログラマが増えるとレベルが下がるスレ
0895デフォルトの名無しさん2010/04/11(日) 23:11:36
アルゴリズムを知らないでプログラミングできません
0896デフォルトの名無しさん2010/04/11(日) 23:12:57
できるよ
0897デフォルトの名無しさん2010/04/11(日) 23:16:28
>>896
マザーボード　CPU　メモリ　電源買ってきてパソコン作れるよ　って言ってるのと同じレベルｗ
0898デフォルトの名無しさん2010/04/11(日) 23:25:45
キーボードは？
0899デフォルトの名無しさん2010/04/11(日) 23:28:45
じゃあ言語作るのに必要なアルゴリズムを列挙してくれ
0900デフォルトの名無しさん2010/04/11(日) 23:44:01
言語作るのに必要なアルゴリズムを列挙するほど暇じゃないんで。
0901デフォルトの名無しさん2010/04/11(日) 23:56:48
expとかlogとかをいかに速くするか？
へるみが作ってるけど
0902デフォルトの名無しさん2010/04/12(月) 00:01:01
>>854
gcj
0903デフォルトの名無しさん2010/04/12(月) 00:03:26
gcjsが欲しい。
0904デフォルトの名無しさん2010/04/12(月) 00:09:53
>>894
アルゴリズムを知らないプログラマはいない
なんか別の何かだろ

ここはWinしか知らないゴミばっかでないだろうが、出てくると話のレベルが地に落ちるな

RTOSでもないOSのシステムコールがCとか思ってるバカまでいるのか？CPUの特権モードとか知らんのか
0905デフォルトの名無しさん2010/04/12(月) 00:10:39
>>903
そいつは悪くないな
0906デフォルトの名無しさん2010/04/12(月) 00:12:14
かんたんな例で最大値を求めるとか、近似解を求めるとか、知らん奴多いぞ
0907デフォルトの名無しさん2010/04/12(月) 00:14:46
>>904
勘違いなやつが来たぞー
0908デフォルトの名無しさん2010/04/12(月) 00:31:15
>>904
アホがきたwww
0909デフォルトの名無しさん2010/04/12(月) 00:50:04
☆【米軍による女の扱いマニュアル 】 ☆
１．女には強気で押せ。抵抗する場合は大声で命令しろ。　　　　　
２．命令を聞かない場合は身体で解らせろ。
３．同じことをくり返す場合、犬のように何回でも同じ様に叱れ。
　　こちらが上と言うことを身体で解らせろ。
４．理由は聞くな。どうせ大したことは言っていない。
５．身体で解らせた場合、根に持つ場合があるので、後で身辺には気をつけて行動しろ。
　　但し、徹底的に解らせる迄、手を抜いてはいけない。
６．相手を3才児と思い、信用したり頼りにはするな。重要な仕事は任せるな。

☆【 旧ソ連共産党による女の扱い方 】 ☆
1、頭痛の種になるだけだから関わるな　　　　
2、手段を選ばぬキチガイ揃いだから関わるな
3、関わるとこっちが痛い目に遭うから関わるな　
4、関わってきたらウォッカを飲んで忘れること
787 名前： Classical名無しさん 投稿日： 10/03/28 18:38 ID:IbdJJ54w
たったレベルの煽りだなｗｗｗｗｗ

767 名前：Classical名無しさん[] 投稿日：10/03/27(土) 23:39 ID:fHdM4fuo
☆【 旧日本陸軍の女に対する注意書き】☆
一、いつ、いかなる時でもお菓子を食事に際し好きなだけ使わすこと。
一、絶対に頭、体を叩いてはいけない。怨みを持って復讐する気質があり、脱走の原因となる。
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。
一、危険な状況下では銃を投げ捨てて「ひぎぃ」と泣き出す習癖があるから、
　　　日本兵二名で一名の女を入れて行動せよ。
0910デフォルトの名無しさん2010/04/12(月) 00:50:13
津波の心配はございません
津波の心配はございません
0911デフォルトの名無しさん2010/04/12(月) 21:13:37
急に過疎ったな
0912デフォルトの名無しさん2010/04/12(月) 21:16:01
やっぱりこういう流れか・・・。
Part3作るならC/C++に代わる言語を探すのもありかと思うがな。

現状解として、どこかから>>1の言うもの近いものを持ってきてマニュアルやライブラリを
ローライズする。そして国内向けにパッケージングするのも抗議の意味ではプログラミング言語を
作るという行為だよ。
0913デフォルトの名無しさん2010/04/12(月) 21:17:56
>>911
結局、なんだったんだろうな。スレの80%は自作自演だとか？
だとしたら時間もったいないけどな。

>>912
抗議じゃねえ広義だ。
0914デフォルトの名無しさん2010/04/12(月) 21:27:11
そもそも、CとC++では、対象としている階層が違う。
C++に代わるものならいくらでもあり、移行が始まっている。
0915デフォルトの名無しさん2010/04/12(月) 21:33:42
C/C++と括ってる時点でこのスレは見当違いであり
このトンチンカンなスレで4行以上レスするのは馬鹿の証左であり
従ってこのスレは馬鹿発表会にしかならない
0916デフォルトの名無しさん2010/04/12(月) 21:34:39
>>913 冗談だけども、
ローライズパンツ履いて国内向けにパッケージングすると、何かの抗議になるのかと思ってお茶ﾌｲﾀｗ
0917デフォルトの名無しさん2010/04/12(月) 21:59:37
ポインタとオサレ機能を両立してくれればそれでいい
0918デフォルトの名無しさん2010/04/12(月) 22:32:01
ポインタ以外に物理（仮想）アドレスをうまく扱う仕組みってあるのかな？
0919デフォルトの名無しさん2010/04/12(月) 22:48:39
サイズ情報と格納型情報をもう少し綺麗に分類すればいいんだよ
C++の参照型を進めた形で引数・返値にはサイズ情報型のポインタは使えなくするとサ
0920デフォルトの名無しさん2010/04/12(月) 22:49:49
オーバーヘッドを最小限にするなら、ポインタが一番いい手段だろ。
それ以外に考えられるわけがない。

ポインタの問題点は？それを解決するためには制御されたメモリアクセスが必要なのでは？
0921デフォルトの名無しさん2010/04/12(月) 22:51:16
>>920
> それ以外に考えられるわけがない。

それはお前が無能だからだろ。無能でも考えるくらいはしろよ。
0922デフォルトの名無しさん2010/04/12(月) 22:55:17
無能ほど他人を無能と言わずにはいられないんだよね。
0923デフォルトの名無しさん2010/04/12(月) 22:57:31
>>918
スライスっていうのがあるよ。
0924デフォルトの名無しさん2010/04/12(月) 22:59:48
>>921
有能なあなた様のご意見を是非聞きたいですなあ
0925デフォルトの名無しさん2010/04/12(月) 23:02:41
有能とか無能とかより何をやるかが重要だろ。
名無し相手にそんな事を言う意味がないし、
みんな名無しなんだから自分に言ってるのと同じことだぜ。
0926デフォルトの名無しさん2010/04/12(月) 23:12:05
C/C++をやらないことが重要だとしか言いようのないスレで、何をやるかと言われても。
0927デフォルトの名無しさん2010/04/12(月) 23:14:27
７０年代に発明されたCを、２０１０年代の今、発明するとしたらどんな言語になるかと言うことを考えるスレです。
0928デフォルトの名無しさん2010/04/12(月) 23:18:46
だよね
0929デフォルトの名無しさん2010/04/12(月) 23:28:58
お前ら馬鹿だろ
もっと簡単な言語でも超高速に実行できるコンパイラ考えるほうが良いだろ
社会的ニーズはそのほうがはるかに大きい

お前ら失業するけど
0930デフォルトの名無しさん2010/04/12(月) 23:30:17
C/C++は文法があいまいすぎた上に愚かな拡張を重ねて遅くなった
0931デフォルトの名無しさん2010/04/12(月) 23:30:30
組込み屋だけど、関数型とダックタイピングしたい。
0932デフォルトの名無しさん2010/04/12(月) 23:31:56
>>930
愚かな拡張は重ねたが、遅くはなっていない。
0933デフォルトの名無しさん2010/04/12(月) 23:33:02
UNIXを駆逐するOSが現れた時、Cは滅ぶだろう
UNIXはCと共にあり、CはUNIXと共にある
0934デフォルトの名無しさん2010/04/12(月) 23:35:53
>>929
失業は、しないと思う。
プログラマ程汎用的な職業は他に無い。
俺ら以上にプロセスを組み立てる達人は他にいるか？
0935デフォルトの名無しさん2010/04/12(月) 23:37:30
Cはアセンブラを駆逐していない。共存している。
Cの次があるとしても、Cを駆逐する事にはならないだろう。
0936デフォルトの名無しさん2010/04/12(月) 23:37:35
CPUアーキテクチャがunixの頃から
基本的に変わってないのに変わるワケない
ポインタはレジスタそのものだから効率いい

スライスは悪くないがオーバヘッドがあるからな
0937デフォルトの名無しさん2010/04/12(月) 23:39:42
Dは低級言語じゃないんか？
0938デフォルトの名無しさん2010/04/12(月) 23:40:12
>>936
スライスは従来のポインタ演算に変換出来そうに見えるけどな。
0939デフォルトの名無しさん2010/04/12(月) 23:40:28
Dにインラインアセンブラってあったっけ
0940デフォルトの名無しさん2010/04/12(月) 23:40:44
>>935
いやかなりの部分駆逐したよ
昔はコンパイラなんて効率悪いものとされてリッチだった
今は逆にアセンブラの使用がかなり限定的になった
組込屋だが。
0941デフォルトの名無しさん2010/04/12(月) 23:42:31
>>937
デジマのDコンパイラとIntelのCコンパイラでそれぞれコンパイルして実行したらどっちがどれだけ速いの？
0942デフォルトの名無しさん2010/04/12(月) 23:42:46
>>938
オプティマイズでかなりいけそうだけど
範囲チェックとどこかで二重間接を無くせないでしょ
0943デフォルトの名無しさん2010/04/12(月) 23:43:45
>>ポインタはレジスタそのものだから効率いい
ん？どういう理屈だそりゃ？
0944デフォルトの名無しさん2010/04/12(月) 23:45:58
>>943
コンパイラの吐いたコードみたらわかるっしょ
人間が最適化の手伝いしてるようなもん
ま、ヘタが作ると逆効果だが。。
0945デフォルトの名無しさん2010/04/12(月) 23:48:58
で、どういう理屈なの？
0946デフォルトの名無しさん2010/04/12(月) 23:51:15
>>944
ごめん
さっぱり意味がわからん
0947デフォルトの名無しさん2010/04/12(月) 23:53:12
ヘタを語っても、語る奴がヘタでない証明にはならない。
0948デフォルトの名無しさん2010/04/12(月) 23:57:31
944逃げたなｗ
0949デフォルトの名無しさん2010/04/12(月) 23:58:37
ポインタってマシン語だと何が入ってるんだ？
TLBとかのアドレスになるのか？
0950デフォルトの名無しさん2010/04/12(月) 23:59:14
仮想アドレスだろ。
0951デフォルトの名無しさん2010/04/13(火) 00:05:23
コンパイラが吐くコードも見ないようなやつらが語ってたのか・・・
0952デフォルトの名無しさん2010/04/13(火) 00:05:44
>>940
Cも既に限定的になっていて、学習コストを支払っても限定的なリターンしか得られない
ことに不満が出てきている段階なんだろうな
0953デフォルトの名無しさん2010/04/13(火) 00:06:20
>>947
証明というより、信用の問題かな。
彼自身が追求されたら困る問題で他人に追求した場合、
彼自身も反撃で同じように追求されることがわかっているなら、
彼はそのリスクを恐れているだろうからその問題を抱えていないだろう、
という心理だね。
0954デフォルトの名無しさん2010/04/13(火) 00:08:05
>>949
gccで-sオプションつけてコンパイルしてみれば分かるよ。
0955デフォルトの名無しさん2010/04/13(火) 00:08:47
で、どういう理屈なの？
0956デフォルトの名無しさん2010/04/13(火) 00:22:55
>>1
俺は色々やることがあるからあまり関われないがWiki借りてきた。
名前決まらないから適当にL言語にしておきます。
次スレやるなら追加しておいてくれ。CAPTCHA認証だから編集はご自由に。

ttp://ldev.wiki.fc2.com/
0957(u＿・y) ◆e6.oHu1j.o 2010/04/13(火) 00:25:23
ポインタはレジスタそのものだとはつまり
Cでポインタ変数を使うと
機械語になったときにたいてい一番速度の速いレジスタに
優先的に入るみたいな事じゃねっ
通常の変数よりも速度面では僅かに優遇されているとかじゃねっ
0958デフォルトの名無しさん2010/04/13(火) 00:26:19
>>956
kuma-だっつってんだろ
0959デフォルトの名無しさん2010/04/13(火) 00:29:41
>>956
L言語は既に被ってるから却下
そしてメインで関わるつもりが無いならしゃしゃり出てくんな
Wiki管理人の座を掠め取りたいだけだろ？
0960デフォルトの名無しさん2010/04/13(火) 00:30:37
>>949
何と表現すれば良いか分からんが、マシン語にポインタはない
NULLってマシン語だと何が入ってるんだ？
とかと同じで、何が入ってようが、実装側の自由だし、
普通は、アドレスとインデックスでポインタを表しているが、
そんなもの、最適化次第で、決まった形なんかないし…
0961デフォルトの名無しさん2010/04/13(火) 00:31:53
大抵のプロセッサが備えているアドレッシング用レジスタ１個でポインタを実装できるからだろ
言葉尻の話は中身が無くてつまらんから、やめれ
0962デフォルトの名無しさん2010/04/13(火) 00:44:33
>>961
言葉尻の話ではなく、ポインタの本質はアドレスじゃなくて、
インデックスにあるけど、アドレスとも切り離せない(インデックスがない場合もある)から
マシン後にポインタはないって話なんだが？
0963デフォルトの名無しさん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はインライン展開されるから高速と言われるが、そうとも限らない
0964デフォルトの名無しさん2010/04/13(火) 00:49:15
>>963
ポインタとポインタ減算は正しいとは限らない罠
0965デフォルトの名無しさん2010/04/13(火) 00:50:00
更に{p[i]=0;}と書いた方が最適化オプ如何に関わらず最高速だったりする環境もあるらしいし
0966デフォルトの名無しさん2010/04/13(火) 00:53:21
関わる気もないしトップページすら1行たりとも書き加えてないのに、次スレに追加しておいてくれだとさー
0967デフォルトの名無しさん2010/04/13(火) 00:58:55
>>965
確かに添字パタンの方が速い環境も多いね
0968デフォルトの名無しさん2010/04/13(火) 01:02:40
>>966
関わる気はないけど、成果物をどうこうする権利だけは欲しいタイプですね。
0969デフォルトの名無しさん2010/04/13(火) 01:08:43
つーか、アセンブラに関わる気がないと成果物を作れないわけだが
Cは嫌いだがアセンブラには関わってもよいという奴が何人いるんだろうか
0970デフォルトの名無しさん2010/04/13(火) 01:10:48
>>966
全く、何かやろうとするところには必ずこういう奴が現れるんだよなぁ
自分は何もしないけど権利だけ欲しいっていう奴
ほんと、リアル社会でもこういうヤツが足引っ張るんだよなぁ
0971デフォルトの名無しさん2010/04/13(火) 01:11:59
次スレ

【超高速】C/C++に代わる低級言語を開発したい 3
http://pc12.2ch.net/test/read.cgi/tech/1271086841/
0972デフォルトの名無しさん2010/04/13(火) 01:12:56
ポインタの本質はアドレスレジスタ
それ以上でも以下でもない
これがわかんないなら話にならん
86脳でもこれ位はわかんだろ
0973デフォルトの名無しさん2010/04/13(火) 01:29:33
>>972
何のためにポインタを加算した時のサイズが
型によって違うと思ってるの？
ポインタの本質がアドレスレジスタだと思ってるのなら、
全部void型のポインタでも使えば？
0974デフォルトの名無しさん2010/04/13(火) 01:31:11
お前さすがに支離滅裂
0975デフォルトの名無しさん2010/04/13(火) 01:34:31
>>973
それじゃアセンブラだろ？
抽象化と構造化だろ
ちゃんと歴史を勉強しな
0976デフォルトの名無しさん2010/04/13(火) 01:41:50
>>974-975
俺は、ポインタの本質はアドレスではなくて、
ポインタが指し示す先の型のサイズを持っていることだと思ってるんだが？
ただ>>972がアドレスが本質だと言ってるから、
そこが本質じゃない(サイズが無いと不便)と分かりやすいように
void型でも使えば？って言ってるだけだが？
0977デフォルトの名無しさん2010/04/13(火) 01:42:38
会話になってない
0978デフォルトの名無しさん2010/04/13(火) 01:44:47
本質って言葉が許せなかったんだね。
正直キモイ。
0979デフォルトの名無しさん2010/04/13(火) 01:45:03
アイちゃんスレに期待してどうする
0980デフォルトの名無しさん2010/04/13(火) 01:45:31
>>976
アドレスレジスタだよ
アドレスそのものじゃない
コンパイラだよ。もっとlow levelで考えたらいい
0981デフォルトの名無しさん2010/04/13(火) 01:47:27
>>977
だから、アドレスレジスタのみを指して、それがポインタの本質だって言われても
型のサイズ(ポインタに1を加算した先のアドレス)が分からなければ、意味がないって言ってるのだが？
0982デフォルトの名無しさん2010/04/13(火) 01:47:44
お互いの前提が違うから何言い合っても無駄。
２ちゃんてほんと不毛だな。
0983デフォルトの名無しさん2010/04/13(火) 01:50:48
>>978
あ、それかもな

Cが生まれたマシンは68Kの祖先を想像したらいい
アドレスレジスタを抽象化したのがポインタのはじまりだ
インデックスみたいなオフセット付が効率いいかどうかは別
今のrisc的CPUは全部バラした風だからな
0984デフォルトの名無しさん2010/04/13(火) 01:51:20
俺もアドレスレジスタ＋インデックスレジスタが本質と言われれば大きく反論はしないが、
ポインタは、次のアドレスが分からないければポインタの意味がないよ
0985デフォルトの名無しさん2010/04/13(火) 01:52:59
「なんの」本質かを語らずになに言ってるんだおまえら。
ポインタの「なんの」本質かによって視点が違うのは当たり前。
0986デフォルトの名無しさん2010/04/13(火) 01:59:09
>>949
釣りじゃなければTLBがなにか知ってるのか？
あんな低レベルでCPU依存なもん言語でやらんわい
0987デフォルトの名無しさん2010/04/13(火) 02:02:41
>>984
まだわからんの
次のアドレスなんかより、
アドレスが何のデータを指してるかが大事なのよ
今後は演算出来ないポインタが流行るよ
安全じゃないからな
0988デフォルトの名無しさん2010/04/13(火) 02:07:29
>>987
本気で言ってるなら、ある意味尊敬する。
0989デフォルトの名無しさん2010/04/13(火) 02:10:04
>>985
ぶっちゃけ本質とかいわんかったら
俺もなんもいわんかった
ヒマだったからつい。
>>988
ま、精進しなよ
0990デフォルトの名無しさん2010/04/13(火) 02:25:48
>>960
なんか特定のCPUなのか？86?
普通はレジスタ一個だよ
インデックス用レジスタもったいない
0991デフォルトの名無しさん2010/04/13(火) 02:57:54
>>990
アドレスとインデックスであって
アドレスレジスタとインデックスレジスタではない
普通は、どちらが一方がレジスタで、もう一方が定数やスタックなど
0992デフォルトの名無しさん2010/04/13(火) 03:12:49
>>991
CPU依存の話だな
ポインタはアドレスだよ
なんでインデックス付けたら速い場合があるかわかる？
0993デフォルトの名無しさん2010/04/13(火) 03:30:27
分からん埋め
0994デフォルトの名無しさん2010/04/13(火) 03:34:21
知らん梅
0995デフォルトの名無しさん2010/04/13(火) 04:27:33
興味ない埋め
0996デフォルトの名無しさん2010/04/13(火) 04:40:49
興味ないとオプティマイザが作れない梅
0997デフォルトの名無しさん2010/04/13(火) 04:54:34
どうせ作らないっしょ宇目
0998デフォルトの名無しさん2010/04/13(火) 04:56:21
あんたが正しい雨女
0999デフォルトの名無しさん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１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。