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

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

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

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

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

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

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

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

結論： C++になります

言語にあわせてCPUマイクロコードを設計しる

すでに多数あるが。

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

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

デバドラ屋だって、オサレ言語で開発したい！

OSに依存するものが多いな。

それをうまく抽象化するのが新言語の課題だろうね。

本当におまいらアイディア出さないな。 >1は一体どこに行った？

これまで出てきたもののほとんどは、OSが存在しないことには実装できないか、役に立たないものばかり。
とりあえずC99の機能を今流の文法にしたらどうなるかを考えてみたら。

　C/C++は古い────→　最新のオサレな言語・技術で
　　　↑　　　　　　　　　　　　　 「低レベル」なことしたい
　　　│　　　　　　　　　　　　　　　　　　　│
　　　│　　　　　　　　　　　　　　　　　　　↓
　　　│　　　　　　　　　　　　 でも、最新のオサレな言語・技術って、
結局、C/C++だよ←─── OSに依存すること多くね？
　　　　　　　　　　　　　　　　　OSより 「低レベル」なこと出来なくね？

同じ話の繰り返しにしかならないから
このスレ落とせ

>9
>4 みたいなのはどうなのよ。OSに依存するのは実行制御以下ぐらいじゃね？
それともこの話についていけてない？

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

>>12
OSがなかったら、ヒープすらないことに気付けよ。

と思ったら、そうでもないものが並んでいた。テンプレートはあってもいいが、プリミティブ型しかないならあまり役に立たない。

クラスに相当する機能位は欲しいな。

C++0xをブラッシュアップするだけでおｋ

で、どのように？

正規表現もファーストクラスで使えるように構文は用意したい

ビジネスクラスで十分

つまり、より広く使いたいと言うことだな

どう見てもこのスレはVIP

低級言語にポインタは必須だな。
機種依存も必須。
でもjavaみたいに間違いが起こりにくい仕組みは欲しい。

新スレ必要だったのか

ポインタより便利にアドレスを直接操作できるやり方ってあるのかな。

新スレまでいったのか。
いくら夢を語っても、どうせ現物はできないし、むなしくなるだけなのにな。

夢のない男の人って情けない。絶対に結婚したくないタイプ

これについてお前らの考察を聞かせてくれ

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

すばらしい

>>28
最適化のことを「条件付き」という筆者はバカ。

最適化できないプログラミング言語はダメだな

10年以上まえ、バブルソートをCとJavaで書いて時間を計ったら、
最適化なしなら大差なしで、最適化ありならCが倍くらい速かった。

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

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

C++「ちくしょーちくしょー！　最適化……　最適化さえすればー！」
JAVA「……おい、お前の言う最適化とやらは、そんなにすごいのか？」
C++「そうだ、最適化さえすればお前などに……」
JAVA「ほう、本当に速くなるんだな？」
C++「そうだ、最適化さえすればお前などに……」
JAVA「…………」
C++「ちくしょーちくしょー！　最適化……最適化さえすればー！」
ﾄﾗﾝｸｽ「……いったい何を話してるんだ？」
C++「ちくしょーちくしょー！　最適化……最適化さえすればー！」
JAVA「おい、やってみろよ。最適化を」
C++「なんだと！？」
ナレーション「いったい、どうなってしまうのか！？」

-O6

sseインラインアセンブラだと数倍差つくよね

最適化は”する”のが当然であって、しない状態とパフォーマンスの比較するるなんて全くナンセンス

>>33
逆だろｗ

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

javaも最適化してないわけがないから、やっぱ、

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

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

Javaが遅いのは、JITでの変換に伴うオーバーヘッドのせいではなく、変換した後でも遅い。

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

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

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

ほっとけばVMが最適化されて速くなると妄想できるだけでJAVAキチにとっては十分なんだよ

>>39
その理屈はおかしい。
・C++のコード→ネイティブのアセンブラ
で、速い最適化が可能なら、
・JavaVMのコード→ネイティブのマシン語
の変換中の最適化でも速い最適化ができない理由がない

理由がないのに遅いってことは、Sunの技術者はどうしようもない無能ってことだな。

無能だからSunなんかに入っちゃうんだろｗｗｗ

>>42
いや、>>39の考察が間違ってるってことだろ。

で、どう間違ってるのかは述べないんだ。

>>44
むしろ、>>42が>>41の考察が間違ってることを証明している。

>>45
>>39 が間違ってる理由は >>41 で述べたよ。
Javaが遅い理由は >>39 の考察した理由以外のところであるってことだけど、
それはしらない。

>>41はネイディブにすれば何でも速くなると思ってるマヌケ

>>41 が正しいというなら、C++がほかの言語(vmのコードも含めて)に比べて
最適化がしやすい理由が無ければならないけど、そんなことは無いから、
>>41 は完全に間違ってる。
Javaが遅い理由はほかに求めるべき。

>>49 のアンカー間違えたよ。>>39だった。

>>49
> >>41 は完全に間違ってる。

同意。

>>48
ぜんぜん見当違いの指摘。
話題についてこれない人は入ってこないでほしい。

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

JavaがC++と同程度にネイティブコードに最適化しやすいのであれば、最適化コードを生成できないSunの技術者はどうしようもない無能。
Sunの技術者がどうしようもない無能でないならば、JavaはC++と同程度にはネイティブコードに最適化できないクズ言語。

まあ、ポインターが使えるってだけでもJavaよりC++の方が最適化しやすいわな。
GC任せのメモリ管理をネイティブコードに最適化しようにも、そりゃオーバーヘッドが当然大きくなる。

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

Javaなんてクソ言語どうでもいいよ　┐(´д｀)┌ﾔﾚﾔﾚ

新言語の話しようぜ！

バカばっか
JAVAが遅いのはお前らみたいなタコがタココード書いても危険にならんようお仕着せ機能がてんこ盛りなだけで
JAVAが実際やってる事を機能的になぞるC++コードを書いたら同程度に遅くなるっつの
何がネイティブコードなら速いだよバカすぎ

>>53
Sunが無能って可能性もあるな。
C++でも、コンパイラによって最適化の性能が違うし、昔はJavaコンパイラ&VMの
性能差も各メーカー間でどうこうって話題があったしな。

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

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/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　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

>>56
話題についてこれない人は、入ってこなくていいって。

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

最後の捨て台詞で>>57の引込みがメデタクついたので、新言語の話題再開。

だれも>>59の俺理論にはついていけねーわｗ

>>58
いや、お前の中以外では、そうなんだよ。

>>59さん、僕たちを置いていかないでｗｗｗｗｗｗｗｗ

>>59
話題についてこれてないのはお前だよｗｗ

>>61
そういう理論っていうか、そういう話だもん。
どうせ、レスを2,3見て、話を把握せずに適当に「バカばっか」とか
中学生みたいなこと言いたくなったんでしょ?
>>56 は。

>>60
捨てゼリフっていうか、論点が>>39が間違ってるってことだったのに
関係ない話にすりかえてごまかそうとしてたから、とりあえずまとめてみたの。

なんか、痛々しい奴がいるなｗ

>>64
いや、>>28 のような単純なコードでなぜJavaが遅いかって話題でしょ?
それを安全な言語だから遅いとかツッコミ入れてるほうが、ぜんぜん話に
ついてこれてないよ。
とりあえず一行レスしとけばごまかせるとか思うのは卒業したほうがいいよ。

どうしても>>39が間違っていることにしたいようだが、そもそも>>41は>>39への反論になっていないし。
「ネイティブにすれば何でも速くなる」と思ってる時点で全然論理が成り立ってないんだよ。

>>68
バッカじゃねぇの？
マジ、バッカじゃねぇの？
どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ
何故遅いかだと？遅いに決まってんだろ

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

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

恐らく>>68は死んだ方がいい

ここまで新言語の話題なし

Javaプログラマーはネイティブコードに夢を抱きすぎだろｗ
ネイティブコードにしたからってそう簡単には速くはならんのだよｗ

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

>>69
だから言ってるじゃん。
それって >>28 のような単純なループとか数値演算ではどうなのよって。
都合の悪いことは見えないふりするんだな。

>>74 のつづき

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

型チェック境界チェックオーバー/アンダーフローチェック配列はオブジェクト
トーシロでもJAVAではこれ位やってるって事はわかる
で、これらと全く同じ要件をネイティブコード(笑)で書けば速いのか？

>>70
> バッカじゃねぇの？
> マジ、バッカじゃねぇの？
> どんなに単純なソースだろうとJAVAはC++では当然やらない膨大なお仕着せ処理が実行されるんだよ

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

>>76
>>75 で指摘されてやっと最低限の指摘がでてきた。

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

>>78
バカかお前
>>76は被っただけで75なんて読んでねぇよ

>>78
特大のバカ発言現る
実行時にその参照が固定配列を指してる保証がどこにある

>>79
そんなのわかってて煽っただけだよ。

>>78でコイツの器のミニマムさがこれ以上無いほど晒されたなｗｗｗ

>>81
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿と言う認識で宜しいか。

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

>>82
また技術的な指摘なしで、人格攻撃かよ。

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

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

>>78>>85
リフレクションのリの字も知らない低レベラー乙

>>87
int tbl = new int[100];
tbl[0] = 0;

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

>>86
つまり39の指摘は正しい事を認めつつも、ただ下らない煽りを続けてるのが今のお前の姿という訳だな。
なぜ「いや」から始めたのかが意味不明だが。

>>89
煽ったのは、お前のドジなところだから本題には関係ない。
そのくらい分かれよ。
とにかく揚げ足をとりたくてしかたないんだな。

もういいだろ
Javaを知らない馬鹿が、Javaを知らない振りをして低レベルスレに相応しい低レベルな煽りをしてるだけの話だ

>>90
どこをドジと言ってるんだ？素でわからん。

>>91
また人格攻撃がはじまった。
まあ、本題のほうは反論の余地がなくなったってことですね。
>>39 は間違ってるって結論で終了ってことで。

>>93
お前さんが無知すぎてもはや反論の余地が無いｗｗｗｗ

>>94
どこか無知か一つも指摘できないで、脳内で無知ってことにして煽る。
そういうのってむなしくないっすか?


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

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

LL言語とC/C++の速度比較とかありえない
どこの初心者だよ

>>95
そういう最適化はJITコンパイル時に行われるんじゃないの

そろそろ新言語の話しようぜ

まず名前からきめようか

GOがあるじゃないか

Goは、Cの代わりにならない。

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

Goは早くも下火になった
新物だったので一時的に話題を集めただけ
今ではD言語にも満たない

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

FORTRANにオブジェクト指向取り入れれば

>>105
確かとっくに取り入れられてなかったか？

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

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

じゃあ言語名はF++0xで

そういやおまいらの中でドラゴン本タイガー本中田本読んだのってどれぐらいいるの？
あとC++の設計を語るのならD&EとかARMとかも読んでいると思うけど、そのへんもどうなの？

読んでねーだろこんなアイちゃんスレに書き込む輩は

>>98
ラブプラス++

O+++

>>108
全員読んでる。当たり前だろ。

>>108
常識

>>99
「small」

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

>プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
そんなコンセプトじゃ無いだろ。
第一、言語仕様が小さいからといってヒューマンエラーが減るわけじゃない。
もしそうだとしたらForth最強じゃないか。

Forthはインタプリタの実装までを含めて仕様みたいなもんだから、
見た目ほど仕様が小さいわけでもないけどな。

>>115
> そんなコンセプトじゃ無いだろ。

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

Cにとって代わるというのがコンセプトだろ。

Cにとって代わるのに加えて、
「プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、
できるだけ小さな言語仕様にしたい。」
という提案だろ？

>>119
言語仕様が小さくなったら、ヒューマンエラーは増えると思うが。

えっ

思うのは自由だ。

>>120
言語仕様が小さい方が、言語仕様を知らないことによる人間の失敗は少なくなるよね？
人間の記憶容量は有限だから。

たとえば、C言語でオブジェクト指向っぽいことをやろうとした時の煩雑さとかどうよ。

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

直感的で一貫性のある仕様がいいね。

教育用言語なら、再帰がない方が失敗が少なくなると言えなくもない。

再帰なんて、単に呼び出す関数がたまたま自分であったと言うだけであって、全く特別なものではない。
それを阻害するような例外（「ただし、自身を呼び出してはいけない」等）を仕様に付け加える方が混乱のもと。有害。

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

>>127
auto変数とかいう特別な変数がある

どう特別？スタックに乗るだけでは？

変数のためにわざわざスタックを使うのは、再帰があるからだよ
再帰が無いならすべてstaticかグローバル変数でOK

スタックを使わず、「staticかグローバル変数」にした場合のメリットは？

>>131
超高速。

>>132
どういう理由で？

「staticかグローバル変数」にしたら関数の外からでも参照できて危ないとしか思えんのだが

スタックポインタに足し算するのに何百クロックもかかる変なマシンを使ってる人が
ここにも登場w グローバル変数は速いと言い張るバカwwwwww

古い言語ではローカル変数をスタックに取ったりはしない。

>>134
関数の中でもstaticつかえるよ

で？

関数の中のstaticと関数の外のstaticは全く別の物だからな。
同じキーワードを使いまわしてるのは、ほとんど設計ミス。

>>123
ヒーマンエラーを減らすためにいろいろな機構があるのに。

グローバル変数が高速wwwwwww

静的に一度だけ確保され初期化がされるstaticと、
静的にメモリに配置されアプリケーション終了まで変わらないstatic？

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

>>140
その機構が、直感的で一貫性があればいいけどね。
特殊な例外の積み重ねで、プログラマーが勘違いすると、プログラマーの意図と違う結果になるのは避けたい。

>>142
名前空間がファイル単位になるんじゃなかったっけ

たぶんそれは名前空間じゃなくてスコープだと思う。

すまん、無名名前空間の話とごっちゃにしてた

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 はエラー

>>147
初心者スレでやれ

まぁ初心者云々はともかくC++におけるstaticの多義性が
>>143の「特殊な例外の積み重ね」であることは間違いないなw

そもそもCPUが何してるか知らない奴多くね？

論理回路の知識がなくてもプログラミングに差し支えはないだろ。
差し支えるようなプログラミング言語というのもあるかもしれんが。

仕事する上ではそれほど必要ないかもしれんが
低級言語作りたいって言うんだったら必要だろう

>>150
なぜそう思ったの？

Javaでプログラミングするとしても、パフォーマンスを考えるためにある程度の知識は必要だろ。

>>153
自分がCPUが何をしているか知らないから、それを知っていることが凄いとでも思っちゃったんじゃないの。

vbプログラマとかCPUのことよくわかってないの多いぞ

そんなに必要な機能があるなら、C99に取り込まれているだろう。

>>156
お前がそういうコミュニティーに属しているというだけだ

この流れじゃ、例えPart 3まで行っても何も決まらないだろうな

新言語とかどうでも良くてJAVAを叩ければそれで満足なカスが多すぎる

それって、Part3までに決めろよってことだろｗ
おまえ、ワクワクし過ぎｗ

は？

>>160
Javaなんて別に叩くほどの言語でも無いだろ。どうでもいい。

Javaは使えない言語だが貶すほどでもない

言い方を変えるか
とにかく何でも叩きたいだけの生産力絶無のカスが多すぎる

普及している言語をカスといっているヤツは、その理由がわかっていないカスだから相手にしなくていい。

歴史的理由にすぎない
とかいっているヤツはどうする

どうでもいい。

CPUどころか、OSが何してるのか知らない奴が多い。

>>169
なぜそう思ったの？

>>169がそういうコミュニティーに属してるんだろｗ

>>1
TMPできるようにして

世間一般はＧＵＩの出来でＯＳの評価してるからな

OSどころか、コンパイラが何してるのか知らない奴が多い。

そりゃ利用者はコンパイラのことなんか知る必要ないからな。

>>174
なぜそう思ったの？

ネイティブじゃないからと中間言語を批判しているやつは、コンパイラがなにやっているかわかっていないような気がする。

気がするのは自由だよ。

断定するのも自由だ

ということで、新言語の話をどうぞ。

お前らホントに>108読んでるのか？

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

PIR、RTLって何？

>>181
スレタイ嫁

Java bytecodeやCILに代わるものをやるわけではない

PIR: Parrot intermediate representation
Parrotで使っている中間言語
RTL: Register Transfer Language
GCCで使っている中間言語

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

プログラマーが三人集まると何も決まらないというのは本当ですな。
先ずは音頭を取るやつがいないと。誰か一人コテつけて幹事を名乗り出るんだ。

ここで開発する言語のコンパイラがRTL吐くってことだよね？

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

よし、じゃあ何か作ろうぜ。
まず、


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

DはC++と異なり、Cとのソースコード互換性を棄ててるから、レガシー排除したC++にあたる。
Cに代わるものは、Dのサブセットから構成できるのではないか。

>>189
具体的にサブセットに含まれる機能を提示してもらえると議論しやすい

このさい、基本データ型からきめようよ

>>189
互換性を捨てたものが普及した試しなんてあるの？Dは互換性捨てたから駄目なんだね。

C自体もそれ以前と互換性がないわけだが

ここの奴らは前スレ埋める事すらしないゴミクズばっかだなｗ

基本データ型はbyteのみ

最近じゃエンディアンすらしらねえクズが仕事してるしな

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

いまエンディアンを知る必要性なんてほとんどないだろ
昔は通信時なんかで考慮必要だった時もあったけどな

プログラム組む上で気にしなくてもいいけど知っとくべきだとは思うな

何らかのバイナリファイル読む場面なんて普通にあるから
エンディアンくらい普通の常識として知っとくべき。
>>197 は多分高級言語しか触らないか、テキストファイルくらいしか触らない奴と推測

>>199
アセンブラも書くよ
インラインでだけど

フレームワーク弄ってる分には必要のない知識なのは確かだ。

ここ低級な言語のスレだよな？
ま、俺は組み込み屋だからエンディアンは関係あり

>>188
void (far *func)();
*(unsigned long *)&func = 0xffff0000L;
func();
}

もうね、farとか見ただけで飯が鼻から出そうです

nearとかfar二度と見たくね('A`)
でも大半はsmallモデルで動いていたんだよなああの頃は

あれなんでageになってんだ

俺はずっと68kとかRISCが多かったから
あんまx86マシンコードの洗礼受けてないけど
見るたびに悪貨は良貨を...ってのを思い出してた。
今やスパコンを構成する位だもんな
思えば遠くへ来たもんだ

x86は怒濤のクロックアップ戦争があったからね
これに唯一勝ち残ったPowerPCだけがRISCとして活躍している
ARMは低消費電力の観点から別の路線を歩いているし

>>208
なぜ現存CPUコアアーキテクチャで最大勢力のMIPSに言及しないんだ？

MIPSか
最大勢力という程でもないだろ
ARMの方がよほど多い

腕っ節でねじりふせたと言う事か。　ARMだけに



とか言ってｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

よくわからんけどx86とかPowerPCは電池で動かすのは無理っしょ

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

ppcは高いんだよ

需要供給の法則か
まあx86は性能の割りには確かに安い

あとx86のソフトの豊富さを忘れちゃいけないな
FreeBSDがなければ2chも存在しなかったかもしれん

>>214
あーarmとかmipsと比べたら。
x86は性能以前に高すぎ

>>216
そうか
売れるから高くしても売れるってわけか
これでもまだ安くなってるんだぜ
AMDがなかったらもっとバカ高くなってるぞ

しかしx86の機械語は何回見ても汚いな
C/C++をコンパイルしたリストを眺めて「ゲロ〜こんなんで
よく動いてるな」といつも思うぜ

８６系は美しくないから、６８００系、次はRISCに性能で負けると言われていたけど、蹴散らしてしまったな。

機械語に美しさを求めるような奴は、エンジニアに向いていないよ。

>>220
分かってるんだ、分かってるけどどうしてもアセンブルリストを見る癖が抜けないorz

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

x86は優れているから普及した。悪貨ではない。

最後はチップの配線に美しさを求める人が出てくるんだろうか。

>>222
優れているか？どう考えてもゴッタ煮だぞ
古い部分から新しい部分までグチャグチャ

ゴッタ煮でグチャグチャな事と、優れていることは、背反ではない

よくわからんなあ・・・・

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

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/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　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

まあ、「美しさ」でしか取り柄の無い工業製品はいらないわなｗ

x86ダメとか、マーケティング知らないすぎ
利用者の立場で考えろよ
職人技術者には無理かな？

x86ダメとは言ってないから
ただ「汚いなあ」といつも思いながら仕事してるだけ
今のところシェアがすごいんだから目をつぶってるけど

良いものが売れるのではない
売れるものが良いものなのだ

>>231
屁理屈はどうでもいいから
文系はどっか行けよ

x86は優れているから売れた。

あーはいはいわかりました
Intel信者キモイな

一人で騒いでるお前がキモイ

お前が騒いでるじゃねーか馬鹿か

ということで、新言語の話をどうぞ。

昔はRISCが主流になるって言ってたのに
PowerPCがPentiumに取って代わると信じてたのに

os/2はwindowsに駆逐されたしな

>>238
だからintelの野望の前にはその理想郷は崩れ去ったんだよ

理想郷じゃないし。地上の楽園だろｗ

地上の楽園かあ
綺麗なアーキテクチャごときで地上の楽園と言い切れるお前の頭の中を
一度見てみたいものだ

>>242には地上の楽園の意味が通じていないようだな

知らない方が幸せなこともあります。

フォン・ノイマンアーキテクチャなら目くそ鼻くそだろ

x86系を汚れてると思えないやつはゆとり


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

出たｗ昔自慢ｗ

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

セグメントは先見の明があったな。
セグメントの無いCPU（MPU）なんて玩具だろ。

知識自慢大好き

I/Oにはダンプリストが掲載されていて、アセンブリ言語は殆ど書いていなかったけどな。

確かに80386で「割と」まともなアーキテクチャにはなったが、その前には
8086、80286という失敗作が存在した事も忘れてはいけない

メジャーどころを叩くと偉くなった気分を味わえるんだろ。

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

昔語りウザイな
ここに来てるオッサン連中なら誰でも知ってるつーの

8086、80286が失敗作とか、病院行けよ。

失敗作じゃねーか

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|

>>255
病院行け

俺もオッサンだが
結局wintelの商業的な勝利だな
ま、今となっては汚くてもコンパイラ使えばええし

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

もうすぐメジャーになるけどな。

残念ながらならねえよ

特に80286+OS/2は「CPUの速度を1/3にする素晴らしいOSです」
と揶揄されたぐらいだからな

RISC的方向性はPentium4とPOWER5で、いったんPC用途での限界を露呈してただろ
まあマルチスレッディングが一般的になってから登場した
Atom以降のSMT復権でだいぶいい扱いを受けるようになってきたが

386以前のx86はゴミだからな

>>262
そりゃ開発費が桁違いだからな
IntelとMicrosoftがx86にかけた金と労力をRISCに注いで
いたらもっといいCPUが出来てたろう

いかにも素人的な発想だなｗ

>>264
POWERもダメでAppleがキレちゃったじゃん
結局クロック上昇が物性的限界を迎えたところで、
同じクロック頻度でいかに多くの演算をするかという方向になったんで、
RISCのほうからx86的な方向に吸い寄せられているというかなんというか。

RISC真理教

ここまで新言語の話題なし

並列実行が重要ということで、Goで良いんじゃないか

>>265
んじゃプロのご意見どうぞ

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

goはいいね。でもGCがネックだな

>>270
モトローラに就職すればいいじゃんｗｗｗ

>>270
アーキテクトをかじるなよｗ

>>270
>んじゃプロのご意見どうぞ

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

>>274
結局内部はRISCプロセッサ風味だわな
ま、あの命令ベースでこんだけ速度出したのは驚異的だがな

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

GoってCもどきなんでしょ？

>>275
>CISC風味なマクロ命令+DSP命令なRISCが今のとこ理想的じゃね

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

このスレは病院に居た方が良い奴が多すぎるｗ

>>277
商業的には互換性がないとあかんけどなｗ

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

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

機械語見て頭痛くなる奴は技術者に向いてないわ

こういう議論をすると、技術的にもアーキテクチャ的にも結局x86が一番優れているという結論に落ち着いてしまうんだよな。

＞＞281
ま、半導体や回路設計の技術とx86とは一緒にはできんが
商業的、現物ベースでいうと、
特にここ最近のx86は優れていると言わざるをえんわな
実際サーバとかもx86ばっかだしな
あれでアセンブラ書きたいかという話とは別にして。

マーケティングが優秀なだけではなく、物理・アーキテクチャの両面でもIntelは優れている。
ある面でIntelに勝るアーキテクチャを開発することはできても、結局トータルではIntelアーキテクチャにはかなわない。

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

RISCでアセンブラ書きたいとか病院行けよ。あんなの絶対に書きたくない。
人間が書くなら、どう考えてもx86の方がいい。

>>284
CPUによるな。
確かにRISCの3オペランド系はつらい

RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
その点x86は人に優しいアーキテクチャ／コードセット。だからハンドアセンブルだってできる。

ハンドアセンブルするならRISCのが楽だぞｗ
てかアセンブラ、ディスアセンブラ作るのが超楽
直交性が高いから理不尽さはない
ま、直値入れるだけで2命令とか面倒ではあるが。

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

>>287
お前はCを超える低級言語があると考えているのか？

超えるって具体的にどういうことだろね

みんなプライドが高いだけの低脳

＞てかアセンブラ、ディスアセンブラ作るのが超楽
＞ま、直値入れるだけで2命令とか面倒ではあるが。
まさに
＞RISCはコンパイラが頑張るためのアーキテクチャ。人間にとっては美しくもわかりやすくも無い。
ということを説明しているようにしか見えないが・・・

>>286
x86が人に優しいって・・・68kのアセンブラ知らんのか？

知ってる。

しかし、68kは真っ向勝負でx86に負けた。

Cの不満な点は？(低級言語の範囲で)

Cは真っ向勝負しなかった。

Cは別に何かの言語と対抗しようとして作られた言語じゃないから
真っ向勝負など必要なかった

インテルはCPUに社運を賭けたから。
モトローラはメモリ売って儲けてた。

Cは実用的だったし
Unixという実例もあったし
それらに関わった人間はリスペクトされてた
主流になるべくしてなった感じじゃないか

Cの問題点はプロトタイプの導入でほぼ解決された。

>>41

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

>>300
俺はC大好きなんだが
宣言を二回書かないといけないのは欠点と言えると思うがね
あんな自動で出来ることは本来処理系でやっちまう方がいい話だな

正確には、ほとんど同じ物を、宣言と定義の頭の部分と2箇所に、だな。

Cはそれが開発された当時のしょぼいハードウェアに合わせて作られている。
いまどきのハードウェアの進歩に全く付いていけていない。
インラインアセンブラとかもう逃げの技術を駆使して何とか延命しているだけ
もう終わった存在だ。

釣られてやるよ
インラインアセンブラは逃げじゃねえ
普通の言語で書けないこと
特殊なレジスタへのアクセスとかCPU固有の演算機能とかのために使う
Cレベルで書ける言語は他にはないな

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

Cは、プロトタイプ宣言のおかげで、コンパイルとリンクを分離できている。

いまどきの言語ならそのへんなんとかして自動的に面倒見てほしいよな。

>>307
原理的に無理

>>304
Cがよくわからないので無くなってくれればいいんですね、わかります

おまえらってプログラマが多いの？
おれは単に手段として使えればよいだけなんで
使いやすくて高速に計算さえできれば細かいことは気にしないんだが

FORTRANでも使っときな
Cはポインタがあるから最適化しにくいしな

インラインアセンブラが書けて配列演算や純関数概念を持っているDが最強だな

Dだと？死んどけよ(　´,_ゝ｀)ﾌﾟｯ

D はなんで普及しないの

Dなんて誰も知らないからだろ

リスクを負ってまで移行する利点が全く無いから

Cが英語ならDはクリンゴン語並に人口少ないだろ
しょゆこと

phpは中国語って感じか
BASICはヒンディー

>>308
やろうと思えば普通にコンパイル時に集めた定義情報を吐き出して
インクルードするだけで実現できるし
そんな難しくもない話だと思うがね
protoizeとかでも省力化はできるし

依存関係が循環してると個別にコンパイルできなくなるから効率悪い。

>>319
よく考えてみ。コンパイル時に吐きだされるのでは遅いんだよ。

>>314
仕様がころころ変わるから

Dは名前が厨だから使うのが恥ずかしい

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

えっ？

Cのいやなところ
・マクロがクソ
・駆動レコードが弄れない（サブルーチン必須）
・評価しない引数が使えない
辺りかね。

・宣言と定義が別
・ヘッダーファイル

shared_ptrの構文糖が欲しいな

>>321
よく考えてみ。コンパイル時でいいんよ
循環は問題だが、
単純に多パスにするか
リンク時に遅延評価で解決できる

要するに、ヘッダファイルの呼び方を変えて
遅延リンクなんたらファイルにすればいいんだろ

人が書く必要ないなら書かない方がいいって話

ヘッダーファイルなんて実装を隠したいときだけ生成するようにすればいいんだよ

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

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

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

ヘッダーファイルは不要

インクルードスパゲティ作ったり
不要なのがすぐ残るしな
あとマクロ欲しいって言ってるが
一歩間違うと黒魔術になるから不要かな
cとgoの中間が俺には理想に近いな
個人的には名前付きパラメータが欲しいが

Lispぽいのがいい。

あんなの下手な奴に使わせたらgotoよりひでえ
そもそも理解できない奴、たぶん多数。

うまくなればいい。要は慣れ。

低能に合わせるためにマクロ不要なんて言うなよ。
単に低能にはマクロ使わせなきゃ良いだけだろ。

名前付きパラメータみたいな飾りはどうでもいいよ。
フロー制御どうするかとかの方が重要じゃない？

ご立派な設計を語る人間が１００人いても、何一つ作れないことの証明

優れたシステムは優れた個人と
優秀な少人数チームが核を作るからな
ここは雑談の場じゃないのw

>>337
低レベル言語にふさわしい制御なんて
ifと繰り返しとその変型しかない、じゃん
オブジェクト指向チックなのはoh高い

作る気の無い奴が1億人集まろうと作られる訳が無いだろ
次スレ立てるなら　【超高速】C/C++に代わる低級言語を妄想したい　に変えておけよ

母国語の１位が中国語だから中国語でかける言語がいいんじゃね？

Cでヘッダファイル不要何て言っているやつは、手動でコンパイルとリンクをやったことがないな。

>>343
でっていうｗｗｗｗ
そんなに手動でコンパイルがやりたいならどうぞご勝手にｗｗｗｗｗ

コンパイルとリンクの区別もついていないやつらばっかだから

手動でアセンブルって話しは分かるが
手動でコンパイルって何のこっちゃ。
どーやるの？

こんな部下いたら発狂するわ

コンパイルとリンクは統合されてくのが処理系の動向。

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

処理系の動向とか以前に、アセンブルと、コンパイルと、リンクの動作の違いをわかっていない人間がいるって話じゃないの？

何かの話について、実際の内容の観察や考察よりも、
勝ち負けとかあほみたいな視点で話をする奴がちょいちょい紛れ込んでるスレ

負け組は黙ってろ

つか、処理系作ったことあるヤツ少なそうだな
妄想はエロいのだけにしとけよ
ヘッダに関しては時代遅れとは思うがな

ハンドコンパイルwww

ハンドコンパイルって、言い方変えたら人間コンパイラだよなｗ
もはや超人だ

ん？CがないようなCPU向けにアルゴリズム記述とデバッグはCでやって
手でアセンブラになおすなんてのはあるんじゃね

なにそのシチュエーション

ごくふつうのブートストラップ

単にコマンドラインからコンパイラやリンカ直たたきで
コンパイルやリンクをするということなんだろうけど
ハンドコンパイルと言われると
直でオブジェクトファイルまで変換するように思えるなw

IDEしか使ったことないやつらが騒いでるな。

>>355
こういうのがハンドコンパイル
4bit CPUとか変なDSPとか、未だにCがないCPUもあるんさ

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

なになに？
>>343 はまるでRPMしか扱った事ないTaco がconfigureを初めて
叩いた時のように「手動でコンパイル」とか言ってたの？

cpuの１コアあたりの処理スピードが今より10万倍になれば
難しいコードを書く必要はないんだが

よってjavascriptで十分

よって大蛇Pythonたんが火を吹く

javascriptのネイティブコンパイラ欲しい

変数の型が決まってない言語ｲﾗﾈ

とりあえずネイティブなレベルで並列処理が欲しいな

Cに代わる低級言語のスレでJS,Pythonはアレだなｗ
>>362
10万倍といえばおおよそで8080/z80レベルの8bit CPUと最新のCPU位の差だな
実に興味深い

どういう点が興味深い？

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

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

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

等々と考えて、興味深い

CPU速度が十万倍になった今でも変わらない愛の形を探してるって事だろ

二十年後にはみんなUMLを進化させたような言語をいじってて
「速度を求めるならJAVA」とか言われるようになるのかね

伝説のプログラミング言語Cとか呼ばれるようになっているかもな

でもその頃になってもいまの話題と技術名を置き換えただけで、
おなじような話題で貶しあいループしてるだろうことだけは断言できる。
やっぱり人間の方が進歩しないとね。

>>372
UMLよりC言語の方が長生きすると思うぞ

自分は構文上の話が詳しいのでそちらだけ書き込ませてもらいます。

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

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

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

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

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

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

最近Cを勉強し始めてどれが関数名とか変数名とか型名(構造体)とか、
流し読みだと全然わからないんですが、これどうにかなったりしますか？

激しく書く場所を間違ったけど、そのままにしときます。

>>376
このスレはCに代わる低級言語ってことで
基本的にCPUアーキテクチャに沿った
手続き系で余分なことをしない静的な型の言語以外あり得ないんじゃないかな

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

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

>>377
慣習でカバー
俺はだいたい関数は動詞入り、変数は名詞形、型は_t

Dでいいんじゃないかな

>>381
何がいいのかと、その理由を。

定期的にD厨わくけどなんなの

Dがダメな理由なんてないからな。
言語統計を見れば分かると思うけど、優秀な技術者はDを洗濯する。

面白がってはいるし使い捨ての道具くらいは作るが、
事実上実用にはなってないというのが現状だろ

 

理由なき現実を受け入れるには、どうすればいいんだ

言語仕様がきれいなだけで、あとは他の言語と同じでは、広く使われることはないということのひとつの証明。

とはいえ一度javaを使うともうC++は使いたくないのが事実

パーソナルリアリティをレベルアップすればC++も使える

D言語
↓

>>389
JavaとC++では、特徴が全然違う

馬鹿でも使えるJava vs 馬鹿は使えないC++

馬鹿でも使えるJava vs 自称天才が脆弱性を入れ込むC++

>>392
>>389 は多分初心者なんだと思うぜ。

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

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

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

ちなみにC使いな俺はC++もJavaもさっぱりわからん

>>395
Javaですむことを、C++でやりたくはないというのは、初心者、上級者共通だと思うけどね。

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

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

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

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

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

まさに必死

必死になってハナ拭けばいいのになｗ

C++ですむことを、わざわざJavaなんかでやりたくはないわ。

>>393
馬鹿でも使える方が工学的には優れている。

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

いまどき、何でも出来る言語なんて低レベルを扱うのでなければ害悪。

ということで、低レベルを扱う新言語の話をしようか

上手い事話戻したなｗｗ

やっぱりe言語

結論
新言語を作る必要は全く認められない。C++で十分である。

C++のどの機能が良いのか具体的に述べるといいよ。

C++は、言語体系が崩壊しているから、近年、
C++に取って代わる言語はたくさん登場している。
けれども、Cに代わるものはほとんどない。

C系言語の修飾の判り辛さはどれも50歩100歩

新言語では、その辺、簡潔に、かつ直感的にプログラマーが勘違いしないようにしたいな。

アスタリスクでポインタとかなんとかなりませんこと？

といいますと？

それじゃ、こんなのにしちゃいましょう
double�icariable;

プリミティブに扱おうとするからちょっと変になる訳で構造体レベルまで降格。
pointer char p_char; pointer p_char p; // char *p;
typedef pointer pointer p_char pp_char; pp_char pp; // char **pp;

char **pp;
だと、
**pp　の型が　char　で
*p の型が　char* ってのは
かなり直感的なんだよな。

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

ポインタ脳に新しいものは作れない

char* p, q:

きもいよーきもいよー

ノイマン型アーキテクチャの上でJavaVMを書きましょうという話でポインタは避けては通れんだろ。

全て無いところから発明しろ
新たに

JavaVMなんて書かなくていいよ

いやJavaそのものがなくていいよもう

>>419
お前は(2* 3+4)が14にならないと文句を言うのか?

>>421
言語自体は全く新しく一から作るが、これまでの研究成果を生かさないのはもったいない。

良いものは取り入れる。

それが日本人の悪い癖だ

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

char* ptr = NULLPO;

char* pは間違いやすいからダメだな
char *pが文法的に理にかなってる

PerlとC#は、良いものを取り入れると伸びるタイプ

> お前は(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.

>>429
ご冗談でしょう

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

cgiがhtmlを吐くように、asmを吐くスクリプトを書け。

別にスクリプトでコンパイラ書いたっていいんだぜ

>>424
「char* p, q」はアスタリスクがcharと合体しつつpとスペースで区切られているのに
pにのみ効果を及ぼしてるのがきももも

>>433
コンパイラ書かなければ、文法とパーサで力尽きる心配が無くなるだろ

>>435
432か？asmを吐くスクリプト=コンパイラだろ

>>436
そうだよ
その定義に従うと、文法やパーサを作るのは必須ではない

>>437
意味わからんな。
文法はありもの言語でもいいがパーサがないとコンパイラは出来ないだろ。。。

>>438
Forthなんかは、パーサーないも同然だけどな。

ウダウダ言ってないでasm直接書けよ

obj のテキスト表記を変換するだけってのはどうだろう。
コード部分は hex で直書き。
作るのも簡単だし高速で簡潔だ。
使う側は少し大変かも知れないけど

意味わからん。それアセンブラじゃね

アセンブラじゃなくてbinutilsだな

テキストで書かれたコードを、一旦アセンブラコードに変換して実行させるっていうのはどうだ？

sレコードで書けばいいやん

>>444
それをするとどういうメリットが？
これまでのコンパイラでもアセンブラコードはけるけどそれとは違うの？

アセンブラでは移植性がない件

移植性より大切なものがあるだろう？

ポインタは
Hoge* pHoge
Hoge *pHoge
どっちで書くか

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

今でも悩む。

>>449
C#なら前者、Cなら後者。

C#でポインタとか使うなよ
劣化javaをさらに劣化させてどうする

C#が劣化Javaだと？聞き捨てならんな

a

>>447
じゃあ、アセンブラだけど、実装されていない命令を既存の命令に置き換えてアセンブルする
弱抽象化アセンブラとかどうよ。

>>454
マシン語がCPU間で似ていると思ったら大間違い。

>>455
マシン語じゃなくて、アセンブリ言語に変換するんだよ

何をアセンブリ言語に変換するんだよ。ソースコードをなら、従来のコンパイラが普通にできることだろ。

WindowsやLinuxなどがC/C++から乗り換えてくれるような言語が登場する可能性はあるの？

むしろ、新言語で作られたOSでWindowsやLinuxが置き換えられる。

それはない

>>454
昔々Base-80というアセンブラがあってな

>>449
後者は間違いの元だからダメだろ
やりたきゃtypedef

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

「〜な奴がいるな」はもういいよ。お前、凄いから。凄い凄い。

なんか凄い奴がいるな

>>450
>>462
どっちなんだよ

>>465
Hoge* pHoge;

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

>>466
その書き方がC++が流行り始めてから推奨されているが、あくまで型はHogeで*は定義する変数を修飾するものだから、pHogeにつける方が筋。
関数へのポインタとか書くときに型にくっつける書き方は破綻して一貫性がなくなる。

そこまでは素人の考え

玄人さんおねげーします

Hoge * pHoge;

ところで、C言語って完全にアセンブラを代替できるの？
アセンブラじゃないとかけないコードとかあったりしない？

あるよ。

Cだとアセンブラよりは短くならない。
あと、サブルーチンの構造前提になる。コルーチンとか継続渡しとか無理。

>>449
Ｃでも型は Hoge* だろ。キャストの時を考えろ。
ただしHoge*型の変数（つまりポインタ）の宣言は、Hoge *pHoge という構文で行う。

そして

Hoge* pA, pB;

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

アレって？

機械語から全て書き直して新構造のコンピュータの方が良い

ポインタ宣言時の*と、ポインタの型を示す*は似ているけど意味が違う記号と思え。
乗算の*とポインタ宣言時の*が一緒の意味でないのと同じことだ。

何いってんだ馬鹿。

>>475
pBはポインタでしょ？

>>477
アホか
この不況にどの企業にそんな時間と金の余裕がある？

>>478
じゃあ新言語は3つとも違う記号にしようぜ

>>480
pBはインスタンスだよ

これだけ自称できる連中が集ってるのに、ボインタ宣言すらてんでバラバラなあたりがCのヤバさ。

char **pp;
は、
char　→　**pp であり、
char*　→　*pp であり、
char**　→　pp である。

実に直感的かつ合理的。

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

>>481
第3のニューディールみたいな感じで雇用創出も出来る
ネイティブなレベルで並列命令作っておけば今後の進化にも対応できよう

ためしに++にしてみようか

>>485
２個以上のポインタを宣言すると全然成り立たないけど？

>>478 なんだっけ、

＞ポインタ宣言時の*

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

＞ポインタの型を示す*

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

>>488
1行で2個以上ポインタを宣言するな。

Ｃの*はコメントを除いても4通りぐらいの用法がある。そのうち３つがポインタ関連な。

ポインタの宣言と、間接参照演算子を同じ記号にするのは合理的。

それで関数宣言と配列宣言を混ぜたらあの読みにくい構文になるんだなこれが

読みやすく書くと長くなるからな
C++なら、Pointer< Pointer<char> > pp;と書けるかもしれないが、書きたくない

>>493
新言語に関数宣言と配列宣言があるとしたら、こうしよう↓

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

>>494
ポインタをあまり多様する必要がないという前提なら、そういう構文もありだと思う。
今のC/C++でやられると鬱陶しいだけだが。

>>495
それがまさしくC#なんだがな

配列だけな。

名前を後ろにすると、関数呼び出しを記述するときに先にパラメータを書かなければいけなくなるから、IDEが困りそう。
宣言と呼び出しは同じ形にしたいし。

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

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

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

気持ち悪いな
Ada崩れみたいだ

慣れだ。

じゃあ言語名、

Nareda に決定な。

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

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

intじゃなくてイントにしろよ
あとparamはパラムとか

基本的な構文が長いのは人に優しくない。

Function::ThatTakes<int>::AndReturns<bool>

コロンやアローいらねぇだろ
fn_nm ag0 int,ag1 const int[2]={0,1},r_type int=(ag0/ag1[0])*ag1[1]{;r_type;}

もっと機能の話はしないの？プリミティブとか制御とか駆動レコードとかスコープとか。
構文なんて後でいいんじゃね？

ユーザーが文法をカスタマイズできるようにすればいいんじゃないのか？

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

みたいな感じで。

低級言語の機能ならCで十分だろ

そそ
詰まる所どうあがいてもCには勝てっこない

仮想レジスタと仮想スタック定義出来て実機へ効率的に転写出来れば
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;}

＞仮想レジスタと仮想スタック定義出来て実機へ効率的に転写出来れば

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

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

ボインタのボインタのボインタって必要？
いやCなら出てくることがあるのはわかるけど
**までで良くない？

>>514
ポインタのポインタを他の関数に送って変更してもらう時に必要
但しC++は**&と最後をリファレンスにすればよい

test

ネイティブ層とマネージ層を持つ言語とかどうかな
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;
--}
}

C++/CLIでいいじゃん

リフレクションとかできないじゃん
だからレイヤーつくって複数の環境組み合わせようYO
見た目　C#(Silverlight)
サーバー　Java
クリティカル部位　C++ D ASM

C/C++は増築限界超え始めたし
類似言語はピタゴラスイッチだし

C++/CLIはリフレクション出来るだろ

JITコンパイラは最低限必須な

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

そもそもスレタイの【超高速】が実現不可能なんだよ
単に新言語やコンパイラならバカでも作れるが
高度に最適化できるコンパイラなんて、それ専門のスペシャリストが
十人がかりでやっても何年かかるかわからない
つうかＣより高速で使いやすかったら億で売れる
ここにいる烏合の衆でそんなもんできるかよw

>>1なんか無視しろよ

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

>>521
よくない。それでデバッガどうするのさ。
インテリセンスもきかないからＣより明らかに不便でしょ。
新言語作る意味ないじゃない。

訂正>>524にレスしたつもりだった

デバッガやインテリセンスは言語仕様じゃないだろ

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

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

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

MONA OSはまさに立ちパーティション不明の失敗例だな

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

このスレは

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

IDEが無いとダメとかいう奴はC/C++を語る資格無し。
お前は誰かが作ったフレームワーク内で一生泳いでろ。

いやc はともかくとしてC++ はvisual studio やeclipse 使い始めたらヘナチョコエディターなんかじゃ書いてらんない。

まさにお前のことだよ

C++ > C#, Java なんて言っているのは、コーディングばかりやってる底辺。

>>534
説得力がまるでないよ、君

ロジック書けよ

多様な思想があるから
他の言語選択スレみたいに、宗教論争になってまうね

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

やっぱIDEがないと駄目だな

基本データ型
整数、実数
[]整数
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
メモリをうまく抽象化できればいいんだけど

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

>>541
unmanagedを知らないのか？

やっぱC#が最強ってことか

Marshalとかな
ポインタももちろんある

Cより後から出来た言語はどこかでちゃっかりCの良い面だけを
取り入れているよな

C++に置けるインラインアセンブラの様に、今後の高級言語に
インラインCを搭載するのはどうだろう。

それなんとかして欲しいよ

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

>>546
objective-cはそれに近い
ていうかあれでcを名乗るのやめてほしい

よし、俺がインラインCで全てが書ける言語作るわ

>>547
intrinsicだっけ？
もうあれでいいじゃん。
どうせパイプライン埋めようとしたってCPUごとにいろいろ違うんだし。

>>510-511
プロジェクトX用に画面キャプチャしといた

>>514
「まで」も何も、*は2個までとか個数を制限するのはおかしい。

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

>>514
>>538

>>520
確かに。
新言語は、ドミノ倒しくらいにシンプルにしたいな。

gotoは必須

>554
だったらForthだろ。あるいは類似のConcatenative言語か。
後置・命令主体の言語ならTMの動作原理に近くなるから低水準にはちょうど良いぜ。
まあ、操作対象をスタックじゃなくてテープにしたBFはやり過ぎだと思うけど。

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

>>557
いやもういいから

 位覚えろ

>>514
初心者すぎる消えろ

初心者しかいないんだからいいじゃん

>557
ライブラリとしてトランスレーター用意すればいいだろ……
さらに言うと呼び出し規約を整理してリンクできるようにしておけば良いだけの話。
コアで話すようなことじゃ無いよ。

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

「〜なやつ」はもういいから。ウザイって。

stdout, stderr, stdinといった標準デバイスという概念も古いよな。

何が新しいの？

int型の 代入と 四則演算 のみを解釈できるインタープリタ作りからはじめれば？最初から最先端をやろうとせずに。

>>566
そんなのすでにやってるから。やりたければお前が一人で学習してろ。

うんうん、ラベルのパーズも大変だから飛び先は行番号でいいね

forとかwhileもめんどくさいからif〜thenとgotoがあればいいよね
あ、サブルーチンはさすがに必要だな、gosubとでもするか

>>561
FORTHの最大の利点はハードの抽象化レイヤーが非常に薄いということだね。
しかし一番の欠点は方言が多すぎるのとGPL実装がほとんどということかな。

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

よし、>>567が作ったインタープリタかコンパイラをみんなで評価しよう。どこかにアップしてくれ。

処理系の作りやすさよりも、先ずは使い易い言語仕様を考えよう。

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

>>552
ポインタのアドレス型ってのが独立してあれば良くないか？

意味不明

修正バージョンアップを繰り返すんだから、仕様が固まる事などないよ。
こう言う場合は、仕様と実装を並行してやるしかない。

>>575
それでは、どうぞ実装を勧めてください。

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

えっ スキル不足で俺には無理ですよ。誰かやってくれるんじゃないの？

>570
Occamかあ。
プロセスの抽象化は魅力的なんだけど、重たくなったりしないのかな？
あと、式の中身自体は普通の命令型の処理だよね？命令型の部分はどうしよう？

>>478
同じだろ。*は単独では型を表せないし
優先高いから変数にくっつける
c++は言語も汚いが慣習も理にかなわないからキライ

>>499
でgoができるワケだな

>>503
apple script w
読めるがかけねえ

>>538
今でも組み込みだと内部メモリと
外部のSDRAMで速度差あるから
普通にリンカスクリプトとattributeで使い分けるよ

>>570
Occum は Transputer のアセンブラだから、その意味では C より低水準で、
かつ、C に比べればずっと先進的な言語仕様だよね。

Transputerか。レジスタマシンでエミュレートすることを前提とするとセマンティックギャップがすごくなりそう。
効率的な変換器があったりするのかな？

>>579
全然違う。そもそも両者はコンパイラだって区別して扱っている。
同じならコンパイラも区別せず統一的に扱えるはず。

C#最強ってこと

行番号で直接コードをメモリアドレスに割り当てられるようにしようぜ

引数をレジスタ渡し一択
返値は逆にリッチにしてスタック上のリスト+レジスタ。

関数革命

初心者の集まりだったが、アホの集まりになったな。

ま、言語で云々ってレベルでは大したことないな
アルゴリズムで勝負するのが一番の高速化手法

どんな言語を作るとしてもアセンブラに変換→マシン語(バイナリ)なんだから
結局はC言語に似たり寄ったりになる

目標はhaskell

>>590
けど、LLじゃどんなに正しくクイックソートを書いても配列の計算で無駄な事してるから
どう頑張ってもCで書いたのには勝てないんだなぁ。

配列は全てsentinel方式に固定

ダサすぎるだろ

>>586
C# は unsafe でポインタ使ってカリカリのコード書いても
何故か C より遅いのが嫌なんだよなあ。
結局 C++/CLI と連携したりしなきゃならなくなる。
JIT 改善してくれれば良いのに。

>>596
DllImportしろ

つーかこの糞スレ、パート2かよ。ようやるわ

C#じゃなくていいけど、プロパティの仕組みは欲しいよな。

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

>>599
> あとC言語の引数を括弧で囲むのもやめてほしい。
どうしろと？

>>599
VB6使えば？

引数を括弧で囲むんじゃなくて、括弧で囲んでいるのが関数なんだよ。
でないと変数と区別がつかなくなる。

>>601
VBでも、関数は括弧必須だろ

>>602
関数として宣言するし、名前はユニークなんだから区別はつくでしょ。
MLとかHaskellでは引数に括弧はいらないよ。

関数型言語みたいに高階関数を引数にとるわけじゃないなら
括弧あった方が読みやすい

紙に印刷されたものを読むときは特に。

開発と名がついてる内でトップレベルの糞スレなのに不思議と伸びるよな

アセンブリ言語への変換を考えても、
高階関数を採用しても何ら問題ないように思う。

俺言語作っているやつの冷やかしが混ざっているから。
協力する気は毛頭無いだろうけど。

バザールモデルでモノが出来上がるわけがない。
何スレ使ったって無駄だよ。

Cに代わるものといいながら、Cの欠点としてマクロとヘッダしか上がってこない。

ポインタ演算・・は必要悪的なところがあるな
それより文字列をどうにかすべき

>>610
このスレみたいな開発スタイルは伽藍でもバザールでもなくて、
お互いに顔も名前も知らない多数の人間同士が話しあって何かを決めるスタイルだ。
名前が無いので付けるとしたら匿名直接民主主義スタイル。
しかし、俺の経験上、何かを決めるためには少数の、
それも３人以下の人数でないと何も決まらない。

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

>>608
同意。
最新のオサレ機能でパフォーマンスに影響を与えない機能は備えたいな。

>>615
それはもはや低級言語ではないな。

このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義しよう。

OSに依存する機能は入れないということでいいね。

CでもOS依存部分はライブラリだしな

>611
>4読んで消えてしまえ

OS依存機能はライブラリでいいけど、組み込みの機能がライブラリを呼び出してもいいんじゃない？
スレッドとか正規表現リテラルとかはあって欲しいな。

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

正規表現を言語仕様にだぁ？ご冗談を。それのどこが低級言語だよ。

ここの低級言語だ。

正規表現はOSに依存しなさそうだけど、文字列型は依存してしまいそう。

正規表現は高度な機能ではあるが、上層とか下層とかそういう次元の物ではないだろう

スレッドも正規表現も、ライブラリで対応って言ってるだろ

言語がリテラルを定義する機能を持てば、正規表現リテラルはなくてもいいかな。
むしろそっちの方がいいか。

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

>>622
言語仕様として定義されている組み込みライブラリに正規表現を含めるなら特に問題ないんじゃない。

「本で読んだことそのまま言ってるんだろうな…w」　ってレスがチラチラあるね…

明にか暗にかはわからないが、マルチスレッドに対応する機能は言語仕様に備えるべきだな。

>>626
それじゃサブセットの言語があるのと同じだからだめだよ。Cに対するC++のようなもの。スレタイはこのさい関係ない。

だから、OS前提の機能を標準ライブラリに入れるな。

言語がリテラルを定義する機能を持つなら、
言語コア仕様が文字列リテラルを持たなくても、標準ライブラリで文字列リテラルを提供してくれればいいよ。

>>613
ここまで読んで思い付いたのだが「烏合の衆モデル」てのはどうよ？
当然、成果物は得られないｗ

>>1
OS前提の機能ってなんだよ？

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

>>629
悪かったよ。
さっき ハインライン の 月は無慈悲な夜の女王 を読みきったところなんだよ。

文字列処理の機能があっても良いと思うけど、正規表現じゃなくてPEGだろ。

PEGって何？

>>632
CのライブラリのほとんどはOS前提だが。

>>636
同志

>>637
解析表現文法（かいせきひょうげんぶんぽう、英: Parsing expression grammar, PEG）
か。

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

>641
PEGは基本的にLL(∞)+αだから表現力は問題なし。
LLベースだから再帰との相性もいいし、パーツ毎の独立性も高い。

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

>>639
string関連のライブラリのほとんどはOSなしで書けるんじゃね
memcpy, memcmpとかも書けるし
stdioはもちろんOSないとダメだけども

言語仕様とライブラリが混同してるな

言語仕様でも標準ライブラリでもOSの機能を使っていいよ。

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

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

ところでお前ら何歳だよ
物知ってるな

>>644
追加インストールしなくても使えることが保証されてる標準ライブラリは言語仕様の一部だよ。

言語仕様がどんなものか判ってないんだろ。
ForthとLisp、Fortran、BASIC、BF、C辺りの違いがわかるやつも少そうだし。

ガベコレに依存するオブジェクトシステム
に依存する文字列は、言語仕様なのかライブラリなのか

>>645
使えない機能があるんだったら、はじめから仕様からはずしておくべき。
OSの機能を使っていいということになったら、ぜひとも入れたいという機能はいくらでも出てくる。

>>648
「やつ」の話はいらないって。

？

マ板のオブジェクト指向スレと流れが似てる。

>>650
例えば、
ヒープを確保するためにライブラリ関数を呼び出すのは美しくない。
言語仕様が備える機能で確保したい。

>>654
へ？ヒープはOSのサービスだろ？言語仕様関係ないべ？

だから、OSが提供する機能であっても言語仕様に含めるべきだと言ってるんだって。

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

そこで仮想レジスタ構文登場

言語仕様にOSが提供する機能を入れたら、それはここで言う低級言語ではない。

>>10

>>656
それってつまり、C++のnewが内部でOSのシステムコールMALLOCを呼んでる
（実際には間にCライブラリmalloc()が入る）みたいにしたいってことかい？
そういうふうに勝手にOSシステムコールしちゃう言語だと、OS書けなくなるけどいいの？

>>657
仮想マシンのバイトコードから現実のマシン語かアセンブラへの変換は難しいと思う。
それができるならx86からarmへのアプリのバイナリ変換による移植も容易くできる事になるが、
実際には難しいよね。

難しい部分はレジスタセット定義を環境別に用意して実装も別にする位じゃなきゃ
Cを超える事なんて出来んので

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

このスレでは、オーバーヘッドが少なくOSやデバドラ開発に使える言語を低級言語と定義する。

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

>>660
いつから malloc がシステムコールになったのか詳しく

>>664
先生それならCで書いたほうが早いですｗ

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

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

>>665
mallocってシステムコールじゃないの？
てか用語が間違ってるのかな。OSのサービスって言えばいい？

>>612
低水準なら、直接いじるって方法を捨てるわけにはいかんわなぁ。
C++のstringじゃ不満かい？

>>667
無駄な再発明したって仕方ないだろ
Cで書いたほうが早いじゃんって言われるような言語に何の意味がある

mallocはCの標準ライブラリで、mallocの中でOSのシステムコールを呼ぶ。

>>664
先生、あとOS作る人はコンパイラ作りません。

mallocはCの仕様で記述できるからOSの機能と呼ぶ必然性はない
OSと連携したほうが高機能になるが

>>671
X68000とかはシステムコール名がMALLOCだったわけだがそんなの出すのは反則ですか

>>668
> mallocってシステムコールじゃないの？
普通, brk/sblk とか malloc 使って全く別のインターフェースとして実装されてる

と、まぁ同じ事の堂々巡りにしかならない糞スレなんだから
次スレとか要らないよ　＞アイちゃん。

>>673
意味がよくわからない。
OSシステムコールを一切使わず、独立したコードでmallocが書けるって意味？
そんなこと出来ないはずだけど。

>>674
malloc()とMALLOC()はCでは別物だよね。他の言語では知らんけど。

>>672
OS じゃねぇけど, リアルタイムモニターもコンパイラも作ったが

>>677
そのとおり。
少なくともどこかでOSに問い合わせてメモリーを確保しなければいけないからな。

>>677
できますよ。
static char heap[1024*1024*HEAP_SIZE];
でこのメモリを管理。
組み込みでは一般的。

>>681
そのheapをどこに配置するかは誰が管理してるんだよ。

mallocもかけない奴が言語仕様語ってるのかｗ

>>668
どのOSの話してるのかは知らんが、K&R第2版にあったUNIXでmallocを実装する例では、
間接的にsbrkシステムコールを使ってメモリを取得しているようだった。

>>682
お前コード読めないの？
静的変数は言語仕様。

>>681
それはインチキ。OS使わないんじゃなくて、OSがメモリ管理機能を持ってないだけじゃん。

>>682
演算子は誰が実行してるんだよというくらいバカなレス

>>682
組み込みの場合は, *.h とかってファイルにメモリーのサイズと共に
スタティックに書かれてることが多い

>>686
このレベルがＯＳや言語仕様語ってるのかｗ

>>681
それのどこがmalloc何だ？HEAP_SIZEが変数？

唐突に見下されても意味わかんないし

>>690
あっキミちょっと黙ってて

やっべーメモリ管理も知らない奴が言語仕様てｗ

見下してると言うより、着いていけなくて、俺の分からない話はするなーってことでしょ。
小学校の時よくいた。

>>690の質問が余程きびしかったようだな。
必死にごまかそうとしている。>>692

>>695
煽ってもみんなわかってるからｗ

JavaやLL育ちのゆとりが、
8bitCPUレベルの組み込み用途にも使われるの言語について語るとか、マジ勘弁してくれ。

mallocすからかけない奴が言語仕様てｗ

>>690

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

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

void free(void* ptr)
{
ptrが指すメモリをheap[]に返す
}

void *malloc(size_t size);
は与えられたサイズ分のメモリーをヒープに確保してそのアドレスを戻り値に返す。

>>681は少なくともmallocの実装にはなっていないけど、どうなってるの？

「メモリ管理はOSさんがやってくれないと何もできません」
こんな奴が「言語仕様」ｗｗｗ

おまえは全ソースコードがないと理解できないのか。
いやソースあっても理解できないな・・・

なんかファビョってるのがいるな

スタックすら理解できなさそう

リンカすらOSと言い出しそう

>>699了解。
>>700を書き込んでからそれを読んだ。

>>706
だから黙っててと書いたのに。。。LL育ちがばれちゃったね。

薄識でも相手にしてもらえるスレ見つけてハイテンションになってる奴が巣くってるんだよ。

mallocを呼び出した後か前かは別にして、メモリーを確保するためにはどこかでOSにお伺い（システムコール）をたてる必要はある。

OSがメモリーを管理しているのであれば、>>681にしてもどこかでOSにお伺いをたてる必要がある。

リンカはＯＳだろ。知らなかったのか？バカじゃん？

>>709-710

リンカーがOSというのは語弊があるが、少なくともリンカーはOSが実行可能な形式のバイナリーを生成する。
だから、リンカーはOSに依存する。

ネタレスはいいから

動的リンクはOSに入りますか？

メモリのことは環境によって大違いなわけだから、OSが受け持つ仕事だろ。

いきなり０番地からのバイナリを吐き出すコンパイラとかの想像もできないのか

>>714
動的リンクはOSに入らないが、動的リンクの機能はOSに依存する。

言語仕様の話と実装の話が混乱しすぎ

2chはバカしかいなくなってしまった。
10年前に戻りたい。

>>719
他に居場所がないなら仕方ない

全員バカ、という奴が一番バカなのは古くからの常識

>>718
どう混乱しているのか具体的に

本物の初心者なんですが、コンパイルされた機械語（ROM？）は、どのCPUでも同じように動きますか？

>>723
動かない。

>>724
そうですか・・・

ROMてのはどっからきたんだｗ

マイコンに焼き付けるROMのことだろう

>>722
Ｃの仕様で記述できるものはどう実装されていようとかまわない。
実装がＯＳの機能を使おうと使わなかろうと本来関係がない。
知っている実装系がＯＳの機能を使っていようとも。

標準ライブラリはCの言語仕様ではない。
main関数すら慣例であって必須ではない。
OSレス、ディスクレス、コンソールレスの
組み込みシステムでも、簡単なレジスタと
メモリの初期化だけアセンブラで残して
後はすべてCで記述するとかいうことは
大昔から普通に行われている。
printfも自前のライブラリで実装とか当たり前だ。
そうした用途に使える言語はCしかない。

>>728
ああ、それなら完全に同意。
煽ってるだけかと思った。

とにかく、Cの場合、OSに依存している部分はライブラリに分離され、言語自身はOSとは独立している。

mallocは置いておいて、

OS無しの組み込み開発で使われることもあるプログラミング言語の
言語仕様にマルチスレッドを標準装備しろとか有り得ない。

malloc使えない香具師を罵倒して悦に入ってる香具師は
mallocの実装を自分で書いたこともないのだろう

>>729
あったねー
ゲーム機とかそんな感じだったね。
ライブラリ皆無で、memcpyやらstrcmpやらも自前で作ったｗ
もちろんmallocも。
printfは面倒だから作らなかったけど。
C以外でこれをやれって言われても、めんどくせえからやだ、で終わりだわな。
>>1はこういう経験あるんだろうか。
LL脳が粋がってわめいてるだけにしか思えないのだが。

>>732
ライブラリでなく言語仕様に標準装備って例えばどんなの？

>>721
ひろゆきもバカだけど年収１億超え＾＾

>>630 とか

Erlangのことか

言語仕様に文字列処理を含めたとしても、「但し文字列処理を使うためには標準ライブラリの”String”を実装してください」、というような仕様でもいいよ。
OS屋は文字列処理を使いたかったら、先ず”String”を実装して、それから文字列処理を使えばいい。

言語仕様のフル機能が常に揃っていなければいけないことはないわけだし。

>>739
それでは、実質的にStringがない別の言語があるのと同じ。

標準ライブラリってOS屋が作るものか？

言語仕様に含まれていれば、
if(!strcmp(str1, str2))
↑こんなことせずに
↓こうできる
if(str1 == str2)

いつもの俺ルールなんだろ

副作用なくして並列処理可能な言語仕様自体はできるとおもうが。

>>742
LL臭がプンプンする。。。
if (str1 == str2) には別の意味があるってのに。。。

本物の初心者なんですが、C言語の標準ライブラリというのは、
オブジェクト指向のダックタイピングみたいなもんですか？

文字列処理をライブラリに追い出すのがC/C++のコンセプトだと思うが。

>>745
>>742は例だ。何言語かも言及してないし、意味も定義していない。「別の意味」も何もない。
単に構文が簡単になるということを言っている。

>>744
時代に沿った流れとしては、低レベルでネイティブな並列処理が欲しい所ではある

>>742
Java

おまいらフロー制御はbool分岐だけなの？
もっとプリミティブなところ考えようぜ

>>749
イメージできてそのレスしてる？

>>749
欲しいね。

>>751
fortranの算術ifでも復活させたいのかね

低レベル並列処理ってなんだよｗ

>>755
どのコアで実行させるかとか、そう言うのじゃないの。

メモリーアドレスをポインター変数で隠蔽するように、コア番号を隠蔽するコア変数みたいのとか。

CPU1個,OS無しの状態で、言語仕様だけで並列処理が出来るのか考えてもらおうか

言いたいことはわかるけど、なんか表現が違う

>>758
どういう表現がいい？

Ｃってノイマン型ならコンパイラがライブラリもほとんどなくネイティブに変換する抽象アセンブラなイメージ

左手でゆりかごをゆらし、右手でプログラミングするってことじゃないの

>755
ルーチンにスレッド付けるかどうかを言語側でサポートする手もあるわな。
単にコルーチン・ファイバーに対応しても良いけど。

>754
パターンマッチングだのマルチスレッドだのいくつかあるぜ。

最近の言語でさえ、とりいれられているものはほんの一部である並列処理を、なぜ切望する？

>>757
並列処理を使いたい人が、並列処理を行うための機能を実装するんだろうね。
言語仕様としては、「並列処理を行う場合は”Thread”ライブラリを実装してください。」でいいと思うよ。

抽象化しなきゃ意味がない前提なのにコアの指定とか矛盾。
並列化可能にしやすい言語仕様にしてインラインアセンブラみたいなものや
プラットフォーム用ライブラリで最適化支援するしかないと思うが。

CPU１個だと並列処理させると普通に処理するより遅くなるんジャマイカ

そのスレッドを管理するのは誰なんだよ、　ライブラリかｗ

>>767
OSに頼れないなら、ライブラリだろうな。それ以外何がある？

リンカだな

なんか人工無脳がいるな

>>765
だから、ポインタ変数に代入する値を出力するmallocやnewがあるように、
コア変数に代入するbeginthreadとかrunとかを定めるんだろ。

アドレス同様、コア番号を直接扱う必要は殆どないよ。

並列化ってＯＳの仕事じゃないの？

マルチコアのCPU前提で語らないでくれないか

>>771
うーんお前あまり実装のイメージできてなくない？
スレッド管理って載ってるOSやCPUによってちがうだろ。
それをどう抽象化するつもりなの？
＞コア変数に代入するbeginthreadとかrunとかを定めるんだろ。
はライブラリにしか見えないけど。
そんなライブラリが載りやすい言語仕様という意味ならおれ多少アイディアあるけど。

>mallocやnewがあるように
新言語のことは完全に忘れ去られているｗ

Core *cpu = allocate_core(4);
cpu[0].run(task0);
cpu[1].run(task1);
cpu[2].run(task2);
cpu[3].run(task3);
こんな感じで書けってか？
これってコアが４つとれない環境だとかえって遅くなるよ。。。
言語でやるのって意味ないと思うけど。OSの仕事だろ上皇。

>>776
その場合はその構文使わなければいいのでは？

>>776
どう見てもクラスライブラリｗ

int cpuCount = getCPUCount();
Core *cpu = allocate_core(cpucount);
とかやれば・・・

って、書いてて思ったけど、
これ OS の APIじゃね？

使えるコアの数を返すのはどの関数なんでしょうね。

>>779
コーディング時に並列実行させたいタスクの数は静的に決まるから、
動的にCPU数を貰ってもあんまり良いことはない。むしろコードが複雑になる。
4個なら4個よこせってOS(じゃないんだっけ？ｗ)に訊いて、例えば３個しか
無い環境なら 0, 1, 2, 2 と返すとかしてくれないと使えない。

ていうか並列処理はＯＳの仕事でＦＡだろうけど。

ＯＳ依存は言語仕様外ってw

今時、そんな糞言語作って誰が使うんだ。

ついてこれないなら無理にレスしなくていいよ

いや正直俺もついていけてない
特に並列がどうとか正規表現がどうとかいうあたりｗ

低レベルなシステム開発ってことは,
OS有りだけど, 直でI/O叩いたり,
OS無しのシステムだったり,
OS自体を作ったり・・・
って事でいいんかな.

OS自体が作れる
これが出来ないと低級じゃないな

迷ったときはとりあえず量子化すればいいんじゃね

並列化も仮想レジスタセット定義の機能に含めればいいじゃん。
MACHINE X{register…}
MACHINE XS SMP2{register…}
MACHINE XN NUMA16{register…}
MACHINE XT THREAD16{register…}
MACHINE XH {MACHINE PhysX,register…}

>>785
そうだね。
但し、それらを行うときに新言語のフル機能が常に揃っている必要はなくて
新言語の一部機能は制限された形で開発することになるということはあるだろうね。

CはインラインアセンブラなしにOSつくれないだろ

となると, インラインアセンブラ(のような機能)は入れるべき?

ご冗談を
アセンブラと一緒にリンクすれば作れますぜ

じゃあリンクできればＣじゃなくてもいいな

スタートアップルーチン必須の言語は無理ですぜダンナ

OS本見ながらOSちょろっと書いてたとき思ったけど,
アセンブラ使わず, 1つの言語で全部できたらいいのにーって
思うのは俺だけだろうか・・・.

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

CPU側が言語仕様にあわせればできるだろうがそこまですることじゃないってこと。

OSブート用のコンパイルオプションがあればできる

どんなオプションだよｗ

Linuxカーネルやgcc作ってる人って、どうせIBMやらredhatやらGoogleで働いてるｽｰﾊﾟｰﾊｯｶｰなんだろ
お前らにそんな人らの真似事なんか出来るんですか

OSブート用のオプションさ！

人生つぎ込めるなら出来ない仕事じゃないでしょう。品質や完成度が問題。

>>799
出来る。

イマイチつかめてないけど,
ロードするアドレスとかスタックサイズとか指定したら
OS無しの状態で, NEW言語で書かれたものが
動く環境まで出来ちゃうコードを自動生成するんかなぁ？

>> 799
あきらめちゃそこで終わりだ！

CのCはChromeのC

いろいろなツールをつかって、最適化なしでいいなら、Cコンパイラの製作自体は入門レベル。

>>799
真似したくないんだろ
真似するだけならCでいいんだが

とはいってもひとりで実装するのは結構メンドイけどね。
このスレに実装したことあるような人間がどのくらいいるのか。
おれは言語トランスレータしかつくったことない。

>>742
演算子のオーバーロードがあれば、言語仕様に含まれてなくてもできるよ。

仕事で簡易スクリプトぐらいしか・・・.
家では, yacc とか使わず Dでパーサ作ったぐらい orz.

iPhoneアプリで大儲け出来るアイデアを考えた方が生産的

そろそろ, 基本型とか欲しくないかい？
個人的には, 固定サイズの型があると嬉しいんだが・・・.
Cの環境依存は何かと・・・
char が 1 byte じゃない時とか移植コマッタゼヨ。。。

C99のstdintじゃだめなん？

最初のcharは、9bit

それ、1byteだろ。

型は byte だけ。1バイトは8ビット固定。
２バイト以上が欲しければ byte(2) のようにする。
浮動小数やsigned/unsignedの区別は自分で行う。

あぁ・・・そうか. すみません.
1 byte が 9bit って書かないとだめでした. m(_ _)m

つまらん議論

仲間に入れて欲しいんだよね＾＾

>>815
byte(8) x = 10;
byte(8) y = 3;
byte(8) z = x / y;

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

型とか他の言語でも改善されてるしC99でも規定されてるしなぁ。typedefもあるし。

>>810
競争激化により110円か無料でしか見向きもされず、30%をappleに取られ、一体何が残るんだ？

そろそろ次スレかな？

>>821
知ったかでした
すみません

>>821
９９ドルを知らない人

>>815
死ぬほど使いにくい

>>815
Ada

>>597
遅いから C 使いたいだけなのになんで dllimport なんて
使わなきゃなんないんだよ。
一部のアセンブリを C++/CLI で方がずっと簡単じゃん。

WebAPI対応しないの？

↓この人が言語仕様をまとめます

C/C++でいいじゃん

ボインタのボインタのボインタって必要？
いやCなら出てくることがあるのはわかるけど
**までで良くない？

だったら＊だけでいいだろ

なぜ＊＊なんだ？

ボインボインうるさい

メンバー参照は全部 . でいい。

参照渡しは書き換えられてしまうので.じゃないほうがいい

メモ渡しでＯＫ

矢切りの渡しでOK

参照渡しと . はどう関係するんだ？

>838
c/c++の場合関係ない

参照渡し禁止ってLapack禁止ってことですか？
行列演算どうしますか？

参照を値渡し

>>839
C/C++の場合の話を聞いているわけではなく、どのような場合に関係してどう関係するのかを聞いているんだろ。

>>831
出来ないように改悪されて困る人はいても、誰も得しないだろ

いまどき、マルチスレッドにも対応できないような言語は糞

明示的なポインタなくしたらダメ？


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

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

int x = 10;
func(x);
// x = 1になる.

>>845
そんなの、いくらでもあるが。

おまいらgolangみてみ
GC以外は理想的だぞ
さすがと言わざるを得ない言語仕様

>>845
> 明示的なポインタなくしたらダメ？

なくすも何も、新言語はこれから作るのだが。
何をなくすかではなく、言語仕様に何を含めるかを語って欲しい。

多値返してエラー処理とかめんどくせぇよ

じゃあ、例外にする？

例外の方がもっとめんどいし汚い

ということで、多値返してエラー処理になります。

タプルを(1,2,3)、リストを[1,2,3]、みたいな記法を直接構文に含めずに、
後からいつでもそういう記法を作ることができるような構文ってどういうふうに定義すればいいのでしょうか？

Java がネイティブコンパイルに対応したら OK なんじゃね？

C++風ならこんな感じじゃないの。bracketは予約語で。

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

MyBracket bracket「」(int v, ...){
　　処理;
　　return new MyBracket;
}

>>847
if文で括弧がないのが致命的にイヤだ

>>853
バックエンドを先に作る。フロントエンドは後で作る。

>>854
それほとんどD言語だろｗ

>847
マクロと駆動操作クレ。
サブルーチン縛りはやだ。

Dの仕様が安定して、GCのつけはずしが可能になれば無問題

お前ら普段どんな言語使ってるの？
主観で使用比率もつけて教えてくれ

ぷっ、D やてw

D言語で金になる案件はあるの？

ないでしょ。ただのオナニー言語だからね。

D言語って、何年か昔にドラフトが出た日に一度見たことはあるけど、厨臭い言語だなと思ったよ。
絶対流行らないってね。

漏れも

流行らせれば流行る、そういう可能性を秘めたのがD言語。

>>867
人を納得させられるだけの材料がなければどんな言語も流行らないよ。
Dの売りはなんだ？

ＣはUNIXの記述から流行ったんだっけ？
最近はJava,C#なんか企業戦略だよね。
LLはオープンソースかな？

>>868
C/C++に代わる低級言語

>>869
> ＣはUNIXの記述から流行ったんだっけ？
UnixのAPIがC言語の関数だったからCを使わざるを得なかったんだよ。
別にアセンブリ言語でも書けるけど、Cだと余計なことを考えずに関数を作るだけだからな。

>>869
C は、抽象化されたノイマンマシンの高級アセンブラとして普及した
Unix の記述は、ある意味実証実験でしかない

ある意味

おまえらのそういうところ、嫌いじゃないぜ

残念ながら片思いだ

>>872
自動プログラミングっていえよｗ

今最も平均年収が高いのはC#だよ

銀行員の方が高い

D言語はC言語よりも高度な処理を目的とした言語。
低級な処理には向かない

Object Cとか、Cから派生してる言語はいっぱいあるが、
低級処理ならCが最高
移植性は世界一

お前らの作る糞アプリで移植するケースなんてあるの？

>>880
俺らの作る糞アプリではなく、過去の巨匠たちが作った
コードを引き継ぐ必要がある

C#の仕事って具体的にどんなの？

CのシンプルさにJavaのシンプルな部分のみを追加して欲しい。
C++はひどい。

>>882
ASP.NET
Windows Forms
XNA
WPF
Silverlight

XNAて
Silverlight案件なんてあるの？

>>885
まだない。
これからはある。




かもしれない。

サーバーサイドでも３分の１はWindowsエコシステムの仕事。
基幹系であぐらをかいてる人間はそんな世界があることさえ知らない。

>>884
このなかで実際にありそうな仕事って
＞ASP.NET
だけじゃね？

>>888
XNAとかSilverlightは別にして、デスクトップアプリならありそうだが

簡単に高機能が使えると低級じゃないのか？

おまえらの低級の定義って「初心者が使えないもの」なのか？

>>890
スレを最初から読みなおせ

この糞スレを最初から読むほど暇じゃないんで。

レベル低すぎて煽りにもなってないｗ

アルゴリズムを知らない単なるプログラマが増えるとレベルが下がるスレ

アルゴリズムを知らないでプログラミングできません

できるよ

>>896
マザーボード　CPU　メモリ　電源買ってきてパソコン作れるよ　って言ってるのと同じレベルｗ

キーボードは？

じゃあ言語作るのに必要なアルゴリズムを列挙してくれ

言語作るのに必要なアルゴリズムを列挙するほど暇じゃないんで。

expとかlogとかをいかに速くするか？
へるみが作ってるけど

>>854
gcj

gcjsが欲しい。

>>894
アルゴリズムを知らないプログラマはいない
なんか別の何かだろ

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

RTOSでもないOSのシステムコールがCとか思ってるバカまでいるのか？CPUの特権モードとか知らんのか

>>903
そいつは悪くないな

かんたんな例で最大値を求めるとか、近似解を求めるとか、知らん奴多いぞ

>>904
勘違いなやつが来たぞー

>>904
アホがきたwww

☆【米軍による女の扱いマニュアル 】 ☆
１．女には強気で押せ。抵抗する場合は大声で命令しろ。　　　　　
２．命令を聞かない場合は身体で解らせろ。
３．同じことをくり返す場合、犬のように何回でも同じ様に叱れ。
　　こちらが上と言うことを身体で解らせろ。
４．理由は聞くな。どうせ大したことは言っていない。
５．身体で解らせた場合、根に持つ場合があるので、後で身辺には気をつけて行動しろ。
　　但し、徹底的に解らせる迄、手を抜いてはいけない。
６．相手を3才児と思い、信用したり頼りにはするな。重要な仕事は任せるな。

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

767 名前：Classical名無しさん[] 投稿日：10/03/27(土) 23:39 ID:fHdM4fuo
☆【 旧日本陸軍の女に対する注意書き】☆
一、いつ、いかなる時でもお菓子を食事に際し好きなだけ使わすこと。
一、絶対に頭、体を叩いてはいけない。怨みを持って復讐する気質があり、脱走の原因となる。
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。
一、危険な状況下では銃を投げ捨てて「ひぎぃ」と泣き出す習癖があるから、
　　　日本兵二名で一名の女を入れて行動せよ。

津波の心配はございません
津波の心配はございません

急に過疎ったな

やっぱりこういう流れか・・・。
Part3作るならC/C++に代わる言語を探すのもありかと思うがな。

現状解として、どこかから>>1の言うもの近いものを持ってきてマニュアルやライブラリを
ローライズする。そして国内向けにパッケージングするのも抗議の意味ではプログラミング言語を
作るという行為だよ。

>>911
結局、なんだったんだろうな。スレの80%は自作自演だとか？
だとしたら時間もったいないけどな。

>>912
抗議じゃねえ広義だ。

そもそも、CとC++では、対象としている階層が違う。
C++に代わるものならいくらでもあり、移行が始まっている。

C/C++と括ってる時点でこのスレは見当違いであり
このトンチンカンなスレで4行以上レスするのは馬鹿の証左であり
従ってこのスレは馬鹿発表会にしかならない

>>913 冗談だけども、
ローライズパンツ履いて国内向けにパッケージングすると、何かの抗議になるのかと思ってお茶ﾌｲﾀｗ

ポインタとオサレ機能を両立してくれればそれでいい

ポインタ以外に物理（仮想）アドレスをうまく扱う仕組みってあるのかな？

サイズ情報と格納型情報をもう少し綺麗に分類すればいいんだよ
C++の参照型を進めた形で引数・返値にはサイズ情報型のポインタは使えなくするとサ

オーバーヘッドを最小限にするなら、ポインタが一番いい手段だろ。
それ以外に考えられるわけがない。

ポインタの問題点は？それを解決するためには制御されたメモリアクセスが必要なのでは？

>>920
> それ以外に考えられるわけがない。

それはお前が無能だからだろ。無能でも考えるくらいはしろよ。

無能ほど他人を無能と言わずにはいられないんだよね。

>>918
スライスっていうのがあるよ。

>>921
有能なあなた様のご意見を是非聞きたいですなあ

有能とか無能とかより何をやるかが重要だろ。
名無し相手にそんな事を言う意味がないし、
みんな名無しなんだから自分に言ってるのと同じことだぜ。

C/C++をやらないことが重要だとしか言いようのないスレで、何をやるかと言われても。

７０年代に発明されたCを、２０１０年代の今、発明するとしたらどんな言語になるかと言うことを考えるスレです。

だよね

お前ら馬鹿だろ
もっと簡単な言語でも超高速に実行できるコンパイラ考えるほうが良いだろ
社会的ニーズはそのほうがはるかに大きい

お前ら失業するけど

C/C++は文法があいまいすぎた上に愚かな拡張を重ねて遅くなった

組込み屋だけど、関数型とダックタイピングしたい。

>>930
愚かな拡張は重ねたが、遅くはなっていない。

UNIXを駆逐するOSが現れた時、Cは滅ぶだろう
UNIXはCと共にあり、CはUNIXと共にある

>>929
失業は、しないと思う。
プログラマ程汎用的な職業は他に無い。
俺ら以上にプロセスを組み立てる達人は他にいるか？

Cはアセンブラを駆逐していない。共存している。
Cの次があるとしても、Cを駆逐する事にはならないだろう。

CPUアーキテクチャがunixの頃から
基本的に変わってないのに変わるワケない
ポインタはレジスタそのものだから効率いい

スライスは悪くないがオーバヘッドがあるからな

Dは低級言語じゃないんか？

>>936
スライスは従来のポインタ演算に変換出来そうに見えるけどな。

Dにインラインアセンブラってあったっけ

>>935
いやかなりの部分駆逐したよ
昔はコンパイラなんて効率悪いものとされてリッチだった
今は逆にアセンブラの使用がかなり限定的になった
組込屋だが。

>>937
デジマのDコンパイラとIntelのCコンパイラでそれぞれコンパイルして実行したらどっちがどれだけ速いの？

>>938
オプティマイズでかなりいけそうだけど
範囲チェックとどこかで二重間接を無くせないでしょ

>>ポインタはレジスタそのものだから効率いい
ん？どういう理屈だそりゃ？

>>943
コンパイラの吐いたコードみたらわかるっしょ
人間が最適化の手伝いしてるようなもん
ま、ヘタが作ると逆効果だが。。

で、どういう理屈なの？

>>944
ごめん
さっぱり意味がわからん

ヘタを語っても、語る奴がヘタでない証明にはならない。

944逃げたなｗ

ポインタってマシン語だと何が入ってるんだ？
TLBとかのアドレスになるのか？

仮想アドレスだろ。

コンパイラが吐くコードも見ないようなやつらが語ってたのか・・・

>>940
Cも既に限定的になっていて、学習コストを支払っても限定的なリターンしか得られない
ことに不満が出てきている段階なんだろうな

>>947
証明というより、信用の問題かな。
彼自身が追求されたら困る問題で他人に追求した場合、
彼自身も反撃で同じように追求されることがわかっているなら、
彼はそのリスクを恐れているだろうからその問題を抱えていないだろう、
という心理だね。

>>949
gccで-sオプションつけてコンパイルしてみれば分かるよ。

で、どういう理屈なの？

>>1
俺は色々やることがあるからあまり関われないがWiki借りてきた。
名前決まらないから適当にL言語にしておきます。
次スレやるなら追加しておいてくれ。CAPTCHA認証だから編集はご自由に。

ttp://ldev.wiki.fc2.com/

ポインタはレジスタそのものだとはつまり
Cでポインタ変数を使うと
機械語になったときにたいてい一番速度の速いレジスタに
優先的に入るみたいな事じゃねっ
通常の変数よりも速度面では僅かに優遇されているとかじゃねっ

>>956
kuma-だっつってんだろ

>>956
L言語は既に被ってるから却下
そしてメインで関わるつもりが無いならしゃしゃり出てくんな
Wiki管理人の座を掠め取りたいだけだろ？

>>949
何と表現すれば良いか分からんが、マシン語にポインタはない
NULLってマシン語だと何が入ってるんだ？
とかと同じで、何が入ってようが、実装側の自由だし、
普通は、アドレスとインデックスでポインタを表しているが、
そんなもの、最適化次第で、決まった形なんかないし…

大抵のプロセッサが備えているアドレッシング用レジスタ１個でポインタを実装できるからだろ
言葉尻の話は中身が無くてつまらんから、やめれ

>>961
言葉尻の話ではなく、ポインタの本質はアドレスじゃなくて、
インデックスにあるけど、アドレスとも切り離せない(インデックスがない場合もある)から
マシン後にポインタはないって話なんだが？

そういや 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はインライン展開されるから高速と言われるが、そうとも限らない

>>963
ポインタとポインタ減算は正しいとは限らない罠

更に{p[i]=0;}と書いた方が最適化オプ如何に関わらず最高速だったりする環境もあるらしいし

関わる気もないしトップページすら1行たりとも書き加えてないのに、次スレに追加しておいてくれだとさー

>>965
確かに添字パタンの方が速い環境も多いね

>>966
関わる気はないけど、成果物をどうこうする権利だけは欲しいタイプですね。

つーか、アセンブラに関わる気がないと成果物を作れないわけだが
Cは嫌いだがアセンブラには関わってもよいという奴が何人いるんだろうか

>>966
全く、何かやろうとするところには必ずこういう奴が現れるんだよなぁ
自分は何もしないけど権利だけ欲しいっていう奴
ほんと、リアル社会でもこういうヤツが足引っ張るんだよなぁ

次スレ

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

ポインタの本質はアドレスレジスタ
それ以上でも以下でもない
これがわかんないなら話にならん
86脳でもこれ位はわかんだろ

>>972
何のためにポインタを加算した時のサイズが
型によって違うと思ってるの？
ポインタの本質がアドレスレジスタだと思ってるのなら、
全部void型のポインタでも使えば？

お前さすがに支離滅裂

>>973
それじゃアセンブラだろ？
抽象化と構造化だろ
ちゃんと歴史を勉強しな

>>974-975
俺は、ポインタの本質はアドレスではなくて、
ポインタが指し示す先の型のサイズを持っていることだと思ってるんだが？
ただ>>972がアドレスが本質だと言ってるから、
そこが本質じゃない(サイズが無いと不便)と分かりやすいように
void型でも使えば？って言ってるだけだが？

会話になってない

本質って言葉が許せなかったんだね。
正直キモイ。

アイちゃんスレに期待してどうする

>>976
アドレスレジスタだよ
アドレスそのものじゃない
コンパイラだよ。もっとlow levelで考えたらいい

>>977
だから、アドレスレジスタのみを指して、それがポインタの本質だって言われても
型のサイズ(ポインタに1を加算した先のアドレス)が分からなければ、意味がないって言ってるのだが？

お互いの前提が違うから何言い合っても無駄。
２ちゃんてほんと不毛だな。

>>978
あ、それかもな

Cが生まれたマシンは68Kの祖先を想像したらいい
アドレスレジスタを抽象化したのがポインタのはじまりだ
インデックスみたいなオフセット付が効率いいかどうかは別
今のrisc的CPUは全部バラした風だからな

俺もアドレスレジスタ＋インデックスレジスタが本質と言われれば大きく反論はしないが、
ポインタは、次のアドレスが分からないければポインタの意味がないよ

「なんの」本質かを語らずになに言ってるんだおまえら。
ポインタの「なんの」本質かによって視点が違うのは当たり前。

>>949
釣りじゃなければTLBがなにか知ってるのか？
あんな低レベルでCPU依存なもん言語でやらんわい

>>984
まだわからんの
次のアドレスなんかより、
アドレスが何のデータを指してるかが大事なのよ
今後は演算出来ないポインタが流行るよ
安全じゃないからな

>>987
本気で言ってるなら、ある意味尊敬する。

>>985
ぶっちゃけ本質とかいわんかったら
俺もなんもいわんかった
ヒマだったからつい。
>>988
ま、精進しなよ

>>960
なんか特定のCPUなのか？86?
普通はレジスタ一個だよ
インデックス用レジスタもったいない

>>990
アドレスとインデックスであって
アドレスレジスタとインデックスレジスタではない
普通は、どちらが一方がレジスタで、もう一方が定数やスタックなど

>>991
CPU依存の話だな
ポインタはアドレスだよ
なんでインデックス付けたら速い場合があるかわかる？

分からん埋め

知らん梅

興味ない埋め

興味ないとオプティマイザが作れない梅

どうせ作らないっしょ宇目

あんたが正しい雨女

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

1000ならC言語大勝利

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。