トップページ⇒tech
982コメント261KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2010/03/18(木) 01:37:55
C/C++は高速だが過去のしがらみから文法が致命的に汚い。
C#の文法は洗練されているが中間コードやGCを前提としているため致命的に遅い。
LL系の言語さらに遅い。

そこで、C/C++に代わるOSも作れるような低級プログラミング言語を開発したい。

文法はCに似ている方が望ましいが、
低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
を担保出来るなら、どんな形式でも構わない。

プログラミングパラダイムについても、オブジェクト指向を備えることが望ましいが
生産性を高めることが出来るのであれば、他の方式が入っても構わない。
0002デフォルトの名無しさん2010/03/18(木) 01:39:11
ガベージコレクションは遅くないよきみはＣ＋＋がどうやってメモリ確保するか知ってるのかい
0003デフォルトの名無しさん2010/03/18(木) 01:40:53
>>2
どうやって確保するの？
0004デフォルトの名無しさん2010/03/18(木) 01:44:06
>>2
遅くないなら現在CやC++に含まれない理由って何なんだろう。
0005デフォルトの名無しさん2010/03/18(木) 01:46:24
ハードリアルタイムだと
GCは実用にならん
0006デフォルトの名無しさん2010/03/18(木) 01:48:02
C のコードを吐く初期の C++ コンパイラ (トランスレータ) みたいなもんでも作れよ。
0007デフォルトの名無しさん2010/03/18(木) 01:50:56
ということで、

GCの無い、過去のしがらみの無い、
高速で、低レベル記述ができる
生産性、可読性、簡潔さ、拡張性、学習の容易さに優れる

言語を作ろう。
0008デフォルトの名無しさん2010/03/18(木) 01:54:34
>>7
つ Pascal
0009デフォルトの名無しさん2010/03/18(木) 01:56:16
Pascalの低レベル記述ってどうなのよ
0010デフォルトの名無しさん2010/03/18(木) 01:57:30
C++を今の技術で１から作り直したらどうなるんだろうな。
0011デフォルトの名無しさん2010/03/18(木) 02:02:28
別にD言語でいいだろ。
それとも構文が複雑すぎてコンパイルに時間掛かるのが嫌で言ってるのか？
asmでもやってろクズ
0012デフォルトの名無しさん2010/03/18(木) 02:11:14
D言語が完成するより
ミッキーマウスの著作権が切れる方が早い
0013デフォルトの名無しさん2010/03/18(木) 02:25:23
>>1
>C#の文法は洗練されているが
おまえは何を言っているんだ？
0014デフォルトの名無しさん2010/03/18(木) 03:32:17
じゃあまずCの文法の汚いところを指摘して、改善案を出すところから始めようか？
どこが汚いの？
0015デフォルトの名無しさん2010/03/18(木) 03:54:18
マクロ
0016デフォルトの名無しさん2010/03/18(木) 04:10:59
C++のプリプロセッサはC++コード本体のセマンティクスの解析が行われる前にトークンレベルで処理が実行される。
美しいと思わんかね。
0017デフォルトの名無しさん2010/03/18(木) 04:14:47
キチガイが出たぞー
0018デフォルトの名無しさん2010/03/18(木) 04:36:20
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0019デフォルトの名無しさん2010/03/18(木) 07:29:49
D言語でおk


終了
0020GV2010/03/18(木) 10:33:23
いちいち；つけることがとっても汚い
0021デフォルトの名無しさん2010/03/18(木) 11:12:57
じゃぁ()にしようぜ
0022デフォルトの名無しさん2010/03/18(木) 11:36:29
高速性を考えていくとアセンブラに落ちつく
0023デフォルトの名無しさん2010/03/18(木) 11:52:01
D
C99
C++/CLI
Erlang
Go
0024デフォルトの名無しさん2010/03/18(木) 12:04:49
>>1
悪いことは言わない。C/C++系言語の再発明はやめておくべき。
以前調べたことあったんで言うが、どういうわけかC/C++系の亜種は屍の山。
ざっと30...100以上あるんだが。呪いでもかかってんじゃないかってくらい(w

それでもやりたいってなら既存のライセンスの非常に寛大なC系インタプリタを
叩き台として紹介するけど？
0025デフォルトの名無しさん2010/03/18(木) 12:23:17
>>9
それModular系言語では...?
0026デフォルトの名無しさん2010/03/18(木) 12:40:01
>>1
Cは明らかに高級言語だろ
低級言語ってのは1文1命令に対応してるのをいうんだよ
0027デフォルトの名無しさん2010/03/18(木) 12:46:33
・文法はC
・OOP
・テンプレートなし
・標準クラス装備(文字列やコレクションクラスなど)
・GCなし
その他新しい機能不要

これで十分だろ。
どいつもこいつも色々とステップ飛ばしすぎなんだよ。
先ずはコレ。
0028デフォルトの名無しさん2010/03/18(木) 13:40:20
>>27
それ、トランスレータの頃のC++と同じだな。
0029デフォルトの名無しさん2010/03/18(木) 15:04:03
ハードが進化してるのにソフトまで速くしてどうすんだよ
0030デフォルトの名無しさん2010/03/18(木) 15:09:21
>>27
(void*)でOOPすれば十分
と思えないなら継承とテンプレートは必須
0031デフォルトの名無しさん2010/03/18(木) 15:20:13
背後に仮想関数テーブルが必要なものは、Cの用途には向かないと思う。
OOPよりも、Cで欠けている機能は、例外処理を簡潔に書ける構文。
0032デフォルトの名無しさん2010/03/18(木) 15:34:56
longjmpが大暴れ
0033デフォルトの名無しさん2010/03/18(木) 15:51:20
しょうがないから関連スレ挙げてやるよ

新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

ブートストラッピングでコンパイラを作ろう
http://pc12.2ch.net/test/read.cgi/tech/1261910039/

C++ではこういう新しい機能が必要だと思う
http://pc12.2ch.net/test/read.cgi/tech/1173238573/

【信者】C++の問題点【アンチ】
http://pc12.2ch.net/test/read.cgi/tech/1223597633/

Ｃ系列って欠陥言語だろｗ
http://pc12.2ch.net/test/read.cgi/tech/1248205502/

例外機構を考察するスレ
http://pc12.2ch.net/test/read.cgi/tech/1249869471/
0034デフォルトの名無しさん2010/03/18(木) 19:28:03
いまどきtemplateなしとかありえん
0035デフォルトの名無しさん2010/03/18(木) 19:58:00
まじめに話する気ある奴いないみたいね
0036デフォルトの名無しさん2010/03/18(木) 20:02:01
静的型なら、総称型の必要性には疑問を挟む余地は無いように思えるけど
C++のtemplateのことを言っているのなら、それが必要かと言われると？だな
0037デフォルトの名無しさん2010/03/18(木) 21:22:43
C#ってC++とかわんなくね？
0038デフォルトの名無しさん2010/03/18(木) 21:36:43
>>37
記法以外で似ているところを探すのが難しいぐらいだ。
0039デフォルトの名無しさん2010/03/18(木) 21:44:20
Cの亜種のような小さい言語なら大学生の実習でやるだろ。
1はまず適当に作って、こんなのはどう？ってみんなに評価して貰った方がはやいぞ。
0040デフォルトの名無しさん2010/03/18(木) 22:23:47
>>24
C/C++系言語の再発明を目指しているわけではない。

過去のしがらみの無い、
高速で、低レベル記述ができる
生産性、可読性、簡潔さ、拡張性、学習の容易さに優れる言語

であれば、C/C++と似ている必要は全くない。
0041デフォルトの名無しさん2010/03/18(木) 22:36:11
ヘッダーファイルが要らない。
0042デフォルトの名無しさん2010/03/18(木) 23:00:46
いまどきの最適化技術の高さを考えたら、GCさえなかったら、Cとおんなじ
くらいのパフォーマンス出せそう。
0043デフォルトの名無しさん2010/03/18(木) 23:04:22
低級な処理に落とす段階で、C並の効率になるのなら、言語仕様は複雑でも構わないんじゃないか？

けれど、例えばHaskellみたいなのをかなり効率のいいアセンブラコードに変換なんてまず不可能ってことで言語仕様に制限がつくのであって、
言語仕様を制限することそのものには意義がない、ということは忘れちゃいけないな。

そういう意味では、プリプロセッサによるincludeは、あんまりいい処理とは言えないわけだ。
ヘッダファイルにいちいち
#ifndef FOO_H
#define FOO_H
〜
#endif
の定型句を書かせる必要はない。
あるいは、>>41のいうようにヘッダファイルそのものがいらないかもしれない。

プロトタイプ宣言だけソースファイルから抜き出すなんてこと、コンパイラにできるはず。
0044デフォルトの名無しさん2010/03/18(木) 23:06:09
まあヘッダは明らかに古臭いと思うよ
モダンな言語で、ヘッダなんて原始的コピペ機構を使ってるのC/C++ぐらいじゃないの
0045デフォルトの名無しさん2010/03/18(木) 23:32:41
最新のプログラミングパラダイムを盛り込んでいながら、C並のパフォーマンスが出させる言語が欲しい。

最近の言語はパフォーマンスを度外視し過ぎ。安易にパフォーマンスを落とす機能を導入し過ぎ。

未だにC/C++以外では現実的にOS作れないわけで。

かと言って、C++は増築増築で言語仕様が巨大過ぎて生産性を下げているし。

そういう意味ではCが一番まともだが、せっかくプログラミング言語研究が進んでいるわけだから、Cに代わるもっと現代風の言語が出てきてもいいだろう。
0046デフォルトの名無しさん2010/03/18(木) 23:39:42
いまどきのオサレ機能ってLispをはじめとする関数型言語由来のことが多くて
GC前提のものが多いような気がするんだが

最新のプログラミングパラダイムって具体的には何が欲しいの
0047デフォルトの名無しさん2010/03/18(木) 23:41:14
まあ関数リテラルや型推論ぐらいは普通にできるか
がんがれ！
0048デフォルトの名無しさん2010/03/19(金) 00:03:33
ヘッダと;は要らない子
あとコンパイルが速いのは絶対条件だろ
0049デフォルトの名無しさん2010/03/19(金) 00:11:47
新言語の条件

（１）シンプルな言語仕様（言語仕様が小さいことで、プログラマーの学習不足によるヒューマンエラーが減る）
（２）低レベル記述可能（OS、デバイスドライバーを作れる）
（３）IDEによる開発支援可能（ソースをあちこち見なくても、ソースを覚えていなくても、プログラムを書ける）
（４）多くのバグはツールが見つける
0050デフォルトの名無しさん2010/03/19(金) 00:26:06
>>49
それってＣじゃね？
0051デフォルトの名無しさん2010/03/19(金) 00:33:51
>>40
そういう用途ならEuphoriaでいいんじゃないの？と思う。
ttp://www.rapideuphoria.com/
ttp://oe.cowgar.com/docs/eu400_0001.html
ttp://9tailfox.web.fc2.com/euphoria/3.1.1/html/ja_jp/overview.htm

少なくとも3.1のDOS32版なら直接低レベル操作できるし、
Cトランスレータ応用(おそらくランタイムライブラリも書き換えて)して
EuphoriaでEuOSなんていうOSを途中まで書いていた人もいた。

>49
まあ解っていると思うけど(言語開発者は自前スキーな人多いから忠告だけど)、
IDEの自前は良くないのでやらないほうがいいよ。周辺ツールも既存のものを使えるようにしたほうがいい。

理由は考えればすくわかるからあえて言わない。
0052デフォルトの名無しさん2010/03/19(金) 01:00:25
>>50
Cは良いと思うが、Cが出来てから長い時間が立っているわけで
最近の研究成果を活かせば、
C程度の言語仕様の大きさで、もっと良い言語ができるんじゃないか？

C1Xはそういう方向性ではないようだし。
0053デフォルトの名無しさん2010/03/19(金) 01:22:25
>>40
生産性を高くするってことは、ある程度の高レベルなロジック記述も支援するってこと?
関数オブジェクトくらいはほしいよね。C の関数ポインタでもいいんだけど、構文がアレ
すぎる。
GC なしならクロージャは無理だろうけど (たぶん)、環境なしでもいいから関数オブジェ
クトを簡単に扱える仕組みはほしいなぁ。

と書きながら、扱い自体は C の関数ポインタでも簡単なのだから、構文さえなんとかす
りゃいいのかということに気づいた。
0054デフォルトの名無しさん2010/03/19(金) 01:30:49
>>53
> 生産性を高くするってことは、ある程度の高レベルなロジック記述も支援するってこと?

Yesだろうね。出来るに越したことはない。
パフォーマンスを落とさない範囲で可能な限りできればいい。

> 関数オブジェクトくらいはほしいよね。C の関数ポインタでもいいんだけど、構文がアレ
> すぎる。

型安全な（とは違っても少なくともコンパイラが誤りを検出可能な）関数オブジェクト（に相当するもの）は欲しい

> と書きながら、扱い自体は C の関数ポインタでも簡単なのだから、構文さえなんとかす
> りゃいいのかということに気づいた。

関数ポインタは構文よりは安全性が問題かな。。
0055デフォルトの名無しさん2010/03/19(金) 01:55:55
>>49
Cの仕様が複雑だとは思わんが、それでも理解不足によるヒューマンエラーは少なくないように見えるぞ。
0056デフォルトの名無しさん2010/03/19(金) 01:59:25
だから、近年の研究成果を取り入れて、C程度のパフォーマンスで、Cよりもヒューマンエラーの少ない言語が欲しい。
0057デフォルトの名無しさん2010/03/19(金) 02:05:11
PHP to C++仕えよ
0058デフォルトの名無しさん2010/03/19(金) 02:07:43
Cに代わる低級言語ってことはポインタ触れるんだろうし
GCも無いんだから、それでヒューマンエラー減らしたいつっても限界あるんでないの

JVMやCLRの上の世界と違って、よく定義された綺麗な型とだけお付き合いしてればいい
というわけにもいかんだろし
0059デフォルトの名無しさん2010/03/19(金) 02:08:45
効率を上げるためには、安全性を犠牲にしないといけないこともあるよな。

例えば、いわゆるLLだと
int a[2];
a[100]=0;
のようなことすると例外なりエラーなりで止まってくれるけど、Cだとメモリ破壊につながるわけだ。

今回のように定数を直接書いてる場合とか、複雑ではあってもコンパイル時間で決定できるものは
コンパイラがエラー出すこともできるけど、動的なものの場合は実行時にチェックするか、あるいはチェックしないで危険を冒すことが必要。


個人的には、配列の境界チェックはプログラマの責任にして動的チェックはしないようにしてほしいが、
メモリアロケーションの失敗とファイルオープンの失敗は自動チェックしてほしいかも。

そのへんの匙加減って、どうすればいいんだろう。
理想を杓子定規で当てはめた結果、誰も喜ばない仕様を作り出す過激派になったり、
毎度毎度細かい仕様で答えのない泥仕合になったりしない方法なんてあるのかなぁ。
0060デフォルトの名無しさん2010/03/19(金) 02:11:30
vc++は勝手に配列チェックして例外出る
リリースでも
0061デフォルトの名無しさん2010/03/19(金) 02:16:13
>>60
そんなんされたら、高速化のためにループ中での条件分岐を減らすとかの努力が水の泡ですがな……
0062デフォルトの名無しさん2010/03/19(金) 02:54:56
nullを
0063デフォルトの名無しさん2010/03/19(金) 03:14:48
新しい言語を作ったとして、IDEへの対応は簡単なのかな？
たとえばeclipseのプラグインをかくとか、どのくらいの難易度なんだろう。
そもそもそれで対応できるとか全然知らないけど。
0064デフォルトの名無しさん2010/03/19(金) 03:28:17
もうプログラムで速度を追求する時代は終わったのだよ
0065デフォルトの名無しさん2010/03/19(金) 03:48:26
>>63
言語仕様やコンパイラ作れる能力がある人には、退屈な単純作業にしか思えないくらいの低難易度。
0066デフォルトの名無しさん2010/03/19(金) 03:53:36
>>64
それはあまりに視野が狭すぎないかい？
科学計算とか、動画エンコードとか、まだまだいくらでも速度を追求したいプログラムはある。

けれど、大体の部分では速度を追求する必要がない時代に来ているのは事実。
LLとの連携強化だったり、ヘビーな高級ライブラリをboostやstlのようなポジションで用意するのはいい判断かもしれない。
0067デフォルトの名無しさん2010/03/19(金) 03:56:08
PHP to C++があればいい。
ライブラリ不足さえ解消されればC++に問題はない。
PHPから変換できて、上級者はC++をいじくるようにする。
Hiphop phpというのがあるがvc++では今は動かないようだ。
0068デフォルトの名無しさん2010/03/19(金) 03:58:13
HipHopはCentOSとFedora向けに開発されており、他のオペレーティングシステム上でのビルドは現在のところ機能しません。他のオペレーティングシステム向けのサポートは準備ができ次第追加されます。
http://blog.candycane.jp/archives/295
0069デフォルトの名無しさん2010/03/19(金) 07:05:29
PHPは、言語としてだめでしょ
0070デフォルトの名無しさん2010/03/19(金) 07:42:00
言語としてはちょっとと思うところはある。
しかし普及しているのでこれをメイン据えるのが良いと思う。
新規の言語開発するより低コスト。　仮に作ったところでPHP以下になる。
基本的には、C++のスクリプト板みたいな物だから少々手を加えればC++になる。
0071デフォルトの名無しさん2010/03/19(金) 07:44:06
言語使用と性能は関係無いと
デルファイの開発者が行ってた気がする。
パスカルは教育用と見なされていた。
しかしデルファイは、デルファイで書かれているらしい。
0072デフォルトの名無しさん2010/03/19(金) 09:52:58
>>61
もちろん嘘だから気にスンナ
0073デフォルトの名無しさん2010/03/19(金) 11:06:23
セミコロンがいらないとか言っている人ってどうすればいいと思っているのかな？
1. 別の記号にしたい
2. 一行1命令
3. 1ブロック1命令
4. 予約語が来たらなんでも命令の区切り
5. 言語に冗長性を持たせて、構文的に命令の切れ目がわかる
0074デフォルトの名無しさん2010/03/19(金) 12:39:42
6. 一行に2命令以上書く時だけセミコロン要求

0075デフォルトの名無しさん2010/03/19(金) 12:47:07
ここまでForth無し。
Forthそのものである必要は無いけど、低級でも良いから高速な言語というのならスタック指向がいいんじゃね？
0076デフォルトの名無しさん2010/03/19(金) 12:47:45
>>58
> Cに代わる低級言語ってことはポインタ触れるんだろうし
> GCも無いんだから、それでヒューマンエラー減らしたいつっても限界あるんでないの

それはお前の思考の限界だろ。まあ俺もそうだが。
どこかの頭の良い人間が解決するかもしれないし、もしかしたら既に解決しているかもしれない。
それを期待したい。
0077デフォルトの名無しさん2010/03/19(金) 12:52:04
>>70
そもそも、PHPでは速度以外の面でCの代わりはできないよ
0078デフォルトの名無しさん2010/03/19(金) 14:40:48
要は、

　　　　　目くそ鼻くその類似スクリプト言語ばかり安易に量産してないで

　　　　　これまでCが担ってきたOSやデバドラ開発の分野でも使える言語を

　　　　　最新の言語研究成果を取り入れて新しく作れ

ということだ。
0079デフォルトの名無しさん2010/03/19(金) 14:52:49
>>77
Cの代わりがだめなら、プリプロセッサの代わりのcpphpをつくるんだ
<define id="NULL">0</define>
XMLが古臭くなるまで、これでしのげる
0080デフォルトの名無しさん2010/03/19(金) 16:55:15
>>78
つかねぇ。漠然としすぎて、どうしたらいいか迷走していると思うんだが。
このままだと埒明かないから、まず言語名と言語族を決めて言語仕様書いたほうがいいんじゃないか？

とりあえず名前から。
このスレが立てられたのは3/18なので、とりあえず言語名のヒントになりそうなもの

Wikipedia(3/18) : ttp://ja.wikipedia.org/wiki/3%E6%9C%8818%E6%97%A5
誕生花 : とさみずき、アネモネ、折鶴蘭、ハナミズキ、イワウチワ、フロックス、アスパラガス...など
誕生石 : アレキサンドライト、エマイユ、アクアマリン...など
0081デフォルトの名無しさん2010/03/19(金) 18:32:28
2言語
0082デフォルトの名無しさん2010/03/19(金) 19:34:25
言語名に「言語」と付くプログラミング言語はあまりないけどな
0083デフォルトの名無しさん2010/03/19(金) 19:39:22
>>81
検索しにくい、発音しにくい、変なのはやめておいたほうがいいと思う。
ある意味でネーミングは駄洒落と連想ゲームなので、>>80の誕生花と
3月の旧暦(ttp://ja.wikipedia.org/wiki/3%E6%9C%88)を引っ掛けると、

3月 = 三月 = 花美月 = みづき → mizuki programming langage

とかなる。あとは接頭辞に適当なものを当てて
MInimum Z-layered Useful development Kit(最小Z層実用開発キット)

といった風になる(文法としては滅茶苦茶だけど)。
Zの意味は究極、最強、低級といったところかと。
0084デフォルトの名無しさん2010/03/19(金) 19:43:24
Ｃをもっと拡張して、クラスの概念を取り入れたら、良い言語ができるんじゃないかな。
0085デフォルトの名無しさん2010/03/19(金) 19:45:33
C++ Alternative 2ch-otaku Style
0086デフォルトの名無しさん2010/03/19(金) 20:09:36
これ見よがしに日本人が作ったんだとアピールするために日本語名にするべき
0087デフォルトの名無しさん2010/03/19(金) 20:25:18
これ見よがしに、ヘッダをXMLにする案をスルーしてませんか？
0088デフォルトの名無しさん2010/03/19(金) 20:55:52
XMLならS式の方がいいな。
0089デフォルトの名無しさん2010/03/19(金) 21:00:53
名前なんかよりコンセプトを考えようぜ。
スピード重視というなら手続き重視・スタック重視・静的動作になるけど、どうするのよ？

>87
XMLはクソ。S式の方が100倍マシ。
0090デフォルトの名無しさん2010/03/19(金) 21:04:23
言語と速度は関係無い。
C#やjavaやPHPですら、
最適化されたネイティブアセンブラに翻訳出来ればC言語に勝る。
コンパイラの性能次第。
言語使用はすでにあるやつで良いだろう。
php c# ruby バイソン　java c++使いやすいやつを受け継げよ。
0091デフォルトの名無しさん2010/03/19(金) 21:04:44
>>89
> スピード重視というなら手続き重視・スタック重視・静的動作になる

これは現在の最先端の人類の知識で最も確からしい帰結なの？
それとも単なる素人の妄想？

どっち？
0092デフォルトの名無しさん2010/03/19(金) 21:06:16
共通言語を開発して、多言語に
コンバートできる仕組みを作れば需要あるな。
出来るだけ簡易に記述が出来るなら。
0093デフォルトの名無しさん2010/03/19(金) 21:06:52
>>90
> 最適化されたネイティブアセンブラに翻訳出来ればC言語に勝る。

それでは、今なぜやらないのか？

できないからだ。
0094デフォルトの名無しさん2010/03/19(金) 21:07:59
コンパイルに時間掛かっちまうだろ
0095デフォルトの名無しさん2010/03/19(金) 21:09:20
掛ければいいだろ。
0096デフォルトの名無しさん2010/03/19(金) 21:10:16
手間かかるからな。
マイクロソフトでは、C#からネイティブexe作り出すコンパイラ作ってる気がする。
Hiphop for phpはC++のコードはき出す。
0097デフォルトの名無しさん2010/03/19(金) 21:13:41
ネイティブよりも、JITコンパイルの方が速くなることも原理的にはある。
そもそも、Cに代わるものというところでは、速度意外に必要なことがあるだろ。
0098デフォルトの名無しさん2010/03/19(金) 21:14:29
ネイティブexeができることと、Cと同等のパフォーマンスを出せることは全く別の話だろ。
0099デフォルトの名無しさん2010/03/19(金) 21:15:31
安全性と生産性の向上
0100デフォルトの名無しさん2010/03/19(金) 21:18:53
いまどきパフォーマンスのボトルネックになるのはDBアクセス、ファイルアクセス、通信等であって
いずれも言語は関係ないな
0101892010/03/19(金) 21:19:00
>91
素人なんで最新の情報は追えてないけど、
・最新のCPUの動作は基本手続きだろ。関数型のCPUは見たことがないよ。
・メモリ確保・解放でスタックよりも軽いのも知らないなあ。
・動作時よりもソースコード時点でたくさんの情報があったほうが最適化しやすいだろ。
　（もちろん、JITも併用した方がいいだろうけど）
じゃね？
0102デフォルトの名無しさん2010/03/19(金) 21:21:36
何か他言語をベースにすること自体には異論はないが、
それとは別に、他言語(できるだけ言語を限定することなく、広く)との連携のしやすさは重視してほしい。

>>90
言ってること自体は正しいかもしれんが、そんな素晴らしいコンパイラを作る方法が現状見つかっていないからさてどうしましょう？って言っている段階。

>>87
XMLにするとどんないいことがある？
そもそもヘッダ自体が必要かどうか微妙なのに。
0103デフォルトの名無しさん2010/03/19(金) 21:25:48
>>100
DB、ファイルシステム、通信ドライバはC/C++で記述されてるだろ。

DB、ファイルアクセス、通信を使うような上位プログラムは
LLでもHaskellでもC#でも今時の烏合のRAD系言語を使えばいい。
0104デフォルトの名無しさん2010/03/19(金) 21:26:46
>>100
そのボトルネックになるところはCで書かれてますよ＾＾
0105デフォルトの名無しさん2010/03/19(金) 21:37:45
>>100
いつの時代も巨大ループや多重ループはボトルネックになる。
計算のオーダがたとえ多項式オーダでも2乗3乗となってくると、
1個1個の処理が少し軽くなるだけで高速化の成果を実感できるようになる。

>>89
スタック利用、動的な処理は最小限に抑えてコンパイル時実行できるものを増やすというのは、外せないよな。

関数型言語に関してはほとんど知らないんだけど、純粋関数と静的処理って極めて相性がいいんじゃないのか？
あと、クラッシュバンディクーってゲームの一部がLispでかかれてるってのは、そこそこ有名な話。
関数型言語で書いてコンパイラが手続き型に翻訳するってのは非現実的な話なのかなぁ？
エロい人教えて
0106デフォルトの名無しさん2010/03/19(金) 21:39:24
>>102
XMLは具体的で現実的
古臭いとかいう先入観で敬遠される可能性が低い

もちろん、ヘッダを無くす素晴らしい方法が具体的にあるなら、そのほうが良い
そもそも、古臭くても構わないというなら、今のCのままでも良い
0107デフォルトの名無しさん2010/03/19(金) 21:42:38
単にネイティブコンパイル可能な関数型というだけなら別に珍しくも何ともないよ
パフォーマンスは
ttp://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php
この辺を見ればいい
0108デフォルトの名無しさん2010/03/19(金) 21:47:53
人間が手続き型で逐一こうしてこうしてと書くよりも、
関数型や論理型のようにある程度大雑把にこうしたいと指定してコンパイラに頑張ってもらった方が大抵は早くすることができるだろう。

ただ、大雑把な指定では致命的に遅いことが容易に指示できてしまうことが問題。
処理の99%を10000倍早くできても、残りの1%が1000倍遅くなったら、全体は10倍遅くなるからな。
（0.99 * T/10000 + 0.01 * T*1000 ≒ 10*T）

そのあたりのバランスを上手く取って生産性とパフォーマンスを両立出来る言語が欲しいところだ。
0109デフォルトの名無しさん2010/03/19(金) 21:53:53
>>108
俺は「低水準」が第一要求なのかと思ってたが
早い話が、ドライバやkernelのようなものが書けるということ

その方向性だと、また別物にならないか？
早い話が、少なくともメモリアドレスを隠蔽する程度に抽象度が高い言語では
ドライバは書けない
0110デフォルトの名無しさん2010/03/19(金) 22:02:52
>>109
目的を絞ろう。まずは、
「最新のプログラミング言語研究成果を取り入れたドライバやkernelを掛ける言語」
でいいだろう。

>早い話が、少なくともメモリアドレスを隠蔽する程度に抽象度が高い言語では
>ドライバは書けない

これは現在の最先端の人類の知識で最も確からしい帰結なの？

通常は隠蔽されていて、必要なときに実アドレスを取り出せるようになっていればいいのでは。
もちろん、隠蔽せずに生産性の高い、安全性の高い記述をする手法があれば越したことはないが。
0111デフォルトの名無しさん2010/03/19(金) 22:12:24
C++にいろいろと関数を標準でつけて、GUI作成も標準でつけて
面倒をなくせばOK。
C# PHP HSPの関数や簡単な記述法を持ち込めばいい。
C++ωにしておくか。
0112デフォルトの名無しさん2010/03/19(金) 22:15:58
C++/CLI はどうだ
0113デフォルトの名無しさん2010/03/19(金) 22:16:38
>>110
> 通常は隠蔽されていて、必要なときに実アドレスを取り出せるようになっていれば
> いいのでは。

.NETはまさにそういう仕様だが、ポインタはGC管理されているので、ロックないし
マーシャリングが発生する
低レベルなコードを扱うのだから、現存のCのobjやasmのコードと簡単に
協調できるようでなければならない

スレタイは「C/C++に代わる低級言語が開発したい」でしょ
それ以下で使われているのは現状アセンブリ言語しかないのだから、
C並に低級なことがC並に簡単にできるのでなければ、取って代われるはずは無いと
思うけど
0114デフォルトの名無しさん2010/03/19(金) 22:18:43
>>111
ただでさえ複雑なC++をこれ以上肥え太らせるって正気か
大体、GUI作成標準って、組み込み用途はどうすんだ
0115デフォルトの名無しさん2010/03/19(金) 22:19:36
>>112
それは簡単になっているとは言い難い。
それならc#使った方が良い。
STLとNETでかぶるってるしわかりにくい。
0116デフォルトの名無しさん2010/03/19(金) 22:19:46
C++を正しいレールにのせた言語でいい
0117デフォルトの名無しさん2010/03/19(金) 22:22:25
>>114
複雑と思う仕組みは使わなければすむ。C++をC言語として使うことも可能。
その複雑な仕組みで開発されたPHPやRubyも複雑か?
便利な機能を取り込んで不要な機能を使わなければすむ。
0118デフォルトの名無しさん2010/03/19(金) 22:24:19
>>117
ttp://yosefk.com/c++fqa/defective.html
ここでも見ればいいんじゃないか？

Rubyは複雑性を（なるべく）隠蔽している
C++は複雑性のはらわたが丸出しだ
0119デフォルトの名無しさん2010/03/19(金) 22:24:50
どんどん取り込んで、web、GUI、ゲームもこれ一本で済むようにする。
C++がサーバーで動く標準なり、他所でも同じコードがそのまま動くようにする。
0120デフォルトの名無しさん2010/03/19(金) 22:25:18
>>113
> .NETはまさにそういう仕様だが、ポインタはGC管理されているので、ロックないし
> マーシャリングが発生する

だから、パフォーマンスの問題を解決できないのであればGCは使わない。

> 低レベルなコードを扱うのだから、現存のCのobjやasmのコードと簡単に
> 協調できるようでなければならない

そのとおり。そういうことができるような言語仕様にしよう。

> スレタイは「C/C++に代わる低級言語が開発したい」でしょ
> それ以下で使われているのは現状アセンブリ言語しかないのだから、
> C並に低級なことがC並に簡単にできるのでなければ、取って代われるはずは無いと
> 思うけど

だから、 そういうことができるような言語仕様にしよう。
そのときに、最新のプログラミング言語研究の成果を取り入れてCより生産性を上げたい。
0121デフォルトの名無しさん2010/03/19(金) 22:27:12
GCもいれてオプションで切り替えられるようにして、インタプリタ動作も出来るようにする。
C++のコードのままでもそれは可能。
0122デフォルトの名無しさん2010/03/19(金) 22:27:22
>>118
はらわた丸出しで腹捩れるほど笑ったｗｗｗｗｗｗ
0123デフォルトの名無しさん2010/03/19(金) 22:28:19
>>117
「使わなければ済む」のであれば、constもassertもいらないんだよ。
何らかの強制的な制約がなければ必ず発生する。
0124デフォルトの名無しさん2010/03/19(金) 22:41:26
C++は改良されてきているとは言えベースは30年以上前に作られた言語だからな。
この30年の間に開発された手法を使ってより良いスマートな言語が作られてもいい頃だとは思う。
Cｂﾈら尚更だ。
0125デフォルトの名無しさん2010/03/19(金) 22:49:04
とりあえずC++からC互換性や歴史的制約を取り除いた言語をC/C++の委員会メンバーが
作成してISOに提案してくれればいいよ。言語名はCleanC++で。
問題は彼らにそんな金も時間もなく、かつC++はまだ進化半ばであることだ。
0126デフォルトの名無しさん2010/03/19(金) 22:52:52
>>125
誰得のそんなものはいらないな。
0127デフォルトの名無しさん2010/03/19(金) 23:45:26
じゃあ我々には出来ることはありませんね
0128デフォルトの名無しさん2010/03/19(金) 23:56:52
イメージとしてJavascript位の文法でカーネル書けるようになればいいのにな。
0129デフォルトの名無しさん2010/03/19(金) 23:57:35
ム板のスーパーハカーがさくっと叩き台つくればいいやん。
0130デフォルトの名無しさん2010/03/19(金) 23:58:48
c や c++ をスマートで記述性も高いと思わない人って居るの？
0131デフォルトの名無しさん2010/03/19(金) 23:59:15
イメージとしてScheme位の文法でカーネルが掛けるようになって欲しい。
0132デフォルトの名無しさん2010/03/20(土) 00:00:05
>>128
JavaScript は c より複雑じゃんｗｗｗ
0133デフォルトの名無しさん2010/03/20(土) 00:01:51
Javascriptには、ヘッダファイルがないし、マクロもない、シンプルだろ？
0134デフォルトの名無しさん2010/03/20(土) 00:06:30
こいうのを税金使ってやればいいんじゃないの？
0135デフォルトの名無しさん2010/03/20(土) 00:08:04
税金使って低水準Prolog作ってもいいよ。
0136デフォルトの名無しさん2010/03/20(土) 01:01:40
>>131
つうか、そんなのはC++でカーネルが書けるのも一緒だが中間言語的役割を
果たすに過ぎないし、今でも作る気なら作れる。意味が無いだけでｗ
0137デフォルトの名無しさん2010/03/20(土) 01:10:06
Scheme位の文法って、文法の規模のことだろ
0138デフォルトの名無しさん2010/03/20(土) 01:27:07
文法の規模を単純化したいって意味で言ってるなら、
アセンブラを高級言語に近づけた方がいいかもなｗ
0139デフォルトの名無しさん2010/03/20(土) 01:28:56
それならForthライクな言語だろ。concatenative languageかもしれないけど。
0140デフォルトの名無しさん2010/03/20(土) 01:54:16
Objective-C は？
0141デフォルトの名無しさん2010/03/20(土) 02:19:54
ObjectiveCは恐ろしい言語だぞ！ｗ
0142デフォルトの名無しさん2010/03/20(土) 02:29:12
Cycloneのruntimeを書き換えて手動メモリ管理できるunsafeモードを付け加えるとかじゃだめ？
0143デフォルトの名無しさん2010/03/20(土) 02:32:22
>>138
結果的に既存の何かに似ているものになるのかもしれないが、
はじめから既存の何かから始めるアプローチはとるべきじゃない。

先ずは先入観を持たずに、一から新しい言語を作る事を考えるんだ。
0144デフォルトの名無しさん2010/03/20(土) 02:40:08
>>143
その通り、だからCPU側からアプローチしようよｗ
高級言語からアプローチしても、ＯＳを作れる（つうか問題なのはデバドラ）
レベルのものにはなるまい。ノイマン型が滅びるその日までｗ
0145デフォルトの名無しさん2010/03/20(土) 03:02:54
>>144
どうぞ別スレで行ってください。応援します。
0146デフォルトの名無しさん2010/03/20(土) 03:16:24
>>144
第N世代コンピューターでも作ってProlog++でも開発してろ。
01471432010/03/20(土) 03:23:45
すまん飛びすぎたorz
0148デフォルトの名無しさん2010/03/20(土) 03:24:46
144だ、もう酔いすぎだなｗ
0149デフォルトの名無しさん2010/03/20(土) 04:25:30
PHPの文字列のなかに変数埋め込める機能は使えるな
Cだと面倒なんだ
0150デフォルトの名無しさん2010/03/20(土) 07:34:42
ここは中学２年生のスレか
0151デフォルトの名無しさん2010/03/20(土) 09:20:53
この手の話って時々出るけど、結局Cにはかなわないわけですよ。
Cをやってると、確かにいろいろな欠点、たとえば、マクロの仕様が適当だとか、staticの用途が複数あるとか、
プロトタイプ宣言がめんどくさいとか、関数のデフォルトがグローバルだとか、が目に付いて、もっと洗練された
高速な言語は作れないものかと考えてしまいがちなんだけれど、その辺を直してもしょせんは「亜流C」が
出来上がるだけで、それまでのCに慣れたプログラマが乗り換えるほどの価値のあるものにはならない。

この話は、「バイオリンは音は素晴らしいけれど、演奏の習得が大変なので、新しい技術を取り入れた
バイオリンを作ろう」っていう話に似ていて、結局こっちもうまくいかなくて（せいぜい、ピックアップをつけた
エレキバイオリンがある程度）、４００年前の仕様のままで演奏している。仕様変更してもたいした効果が
ないので、放置ってわけだ。

LL言語なら速度を度外視して、配列のサイズチェックやら、継承やらなんやら好き勝手に盛り込めばいいけど、
それの真似をすればするほどCの哲学である、簡潔さ、高速さ、プログラマが書いたままに動くこと、から
遠ざかっていく。

というわけで結論：ムリ。
0152デフォルトの名無しさん2010/03/20(土) 09:47:23
そしたらまず、なんでRubyでOSが書けないのかを具体的に理由を挙げてみたら？
0153デフォルトの名無しさん2010/03/20(土) 10:30:47
OSがどのように起動するのか知らないんだろうな
0154デフォルトの名無しさん2010/03/20(土) 10:37:00
152みたいなやつには、説明は難しい
0155デフォルトの名無しさん2010/03/20(土) 11:48:29
>>138
それだと、C構文を持つ低級言語としてC--なんて言語もある。
ttp://www.goosee.com/cmm/
ttp://www.cs.utexas.edu/users/tbone/c--/
ttp://sourceforge.net/projects/c--/
ttp://c--sphinx.narod.ru/indexe.htm

さらにアセンブリ言語風の文法を持つトイ言語としてEcstasy/Yaalなんてのもある。
> EcstasyYaal is a programming language with low level assembly-like syntax. It differs in that it is designed to be toyed with without worry of damaging the system, while keeping some of the feel of writing assembly.
http://sourceforge.net/projects/ecstasy/
0156デフォルトの名無しさん2010/03/20(土) 11:54:09
低級といえばZincという言語もあるんだっけな。
ttp://tibleiz.net/zinc/
0157デフォルトの名無しさん2010/03/20(土) 11:59:17
大昔はTurboPascalでもブートセクタが書けたけどな
0158デフォルトの名無しさん2010/03/20(土) 12:04:47
>>157
Turbo Pascalはポインタもあるので、C並みのことはできるんじゃないか
0159デフォルトの名無しさん2010/03/20(土) 12:14:16
>>158
C並みっつうかIO制御もできたし、インラインアセンブラも書けたし衝撃だった。
「Pascalって凄い低級言語じゃねえか！」と勘違いするくらいｗ
0160デフォルトの名無しさん2010/03/20(土) 12:48:22
上でクロージャの話が少し出ていたけど
C++0xのlambdaは
http://ja.wikipedia.org/wiki/C%2B%2B0x#.E3.83.A9.E3.83.A0.E3.83.80.E9.96.A2.E6.95.B0.E3.81.A8.E3.83.A9.E3.83.A0.E3.83.80.E5.BC.8F
を読む限りでは
1. 環境はキャプチャできるが、キャプチャする変数を手動で指定する必要がある
（透過的ではない）、ふべん！
2. GC頼みの無限エクステントがあるわけではないので
　変数をキャプチャする際に、コピーするか参照するか指定する
　高機能！
3. スタック上の変数を（コピーではなく）参照しているクロージャを
　戻り値としてリターンした場合の挙動は当然未定義
（upwards funarg problemってやつ）
4. 構文がキモいですが何か？
5. lambdaの型がとにかくキモくなるのでautoやfunctionテンプレート必須？
という感じのようですね
さすがC++です
0161デフォルトの名無しさん2010/03/20(土) 16:04:06
>>153-154
ある程度わかった上で、書いている。
ただ、その低級言語とやらを作る上での、最小の仕様を見つけるためにはそれが必要だと思っただけだ。
あと、Rubyってのは一例であって、別にRubyじゃなくても何でもいい。そもそも俺Rubyつかえねーし。

例えば、インタプリタ言語じゃOSどうやって起動するんだよ、ってのがまずある。
当然、ネイティブコードにコンパイル可能ってことは最低条件になるわなぁ。
(コンピュータサイエンス的意味でのできるできないじゃなく、現実的に実装可能という意味で)

で、じゃあRubyがネイティブコードにコンパイル可能になったとすれば、それでOSができんのか？まだ不十分だろ？
だったら、あとは何が必要か？って話がしたいわけ。
OSないとRuby動かねぇｗｗｗはい論破ｗｗｗなんて話はどうでもいい。
0162デフォルトの名無しさん2010/03/20(土) 16:05:56
ＰＬ／Ｉなんてｄぴだろう
0163デフォルトの名無しさん2010/03/20(土) 16:38:04
>151, 161
だからforth……smalltalkもほとんどOSだよな。

自分だけの知識が世界の全てだと思っちゃいかんよ。
それにOS開発が主目的じゃないだろ。
0164デフォルトの名無しさん2010/03/20(土) 17:21:22
いま、C/C++が無かったとして、
現在の最高のプログラミング言語設計者を集めて
「OSを作るから最先端の研究成果活かしてプログラミング言語作ってよ」って頼んだだら
どういうプログライング言語を作るだろうか、って観点で考えてみるといい。

「XXがあるからいいじゃん」とか、「YYから乗り換えるほどの価値がどうのこうの」とかは、無意味。
そもそも前提が違う。そういうXX、YYが存在しない前提で考えたい。
0165デフォルトの名無しさん2010/03/20(土) 17:30:00
そんなオレオレルール勝手につくられてもｗ
Cが無いプログラミングの世界なんて想像不可能です
0166デフォルトの名無しさん2010/03/20(土) 17:30:34
まずC/C++のいけ好かない点を列挙するとかは？
0167デフォルトの名無しさん2010/03/20(土) 17:31:29
{} ; が醜い
0168デフォルトの名無しさん2010/03/20(土) 17:46:54
Cの短所なら>151にいくつか挙げられてるが
0169デフォルトの名無しさん2010/03/20(土) 17:53:03
「おれの考えた最強言語」みたいな妄想スレっていろいろあるけど
実物ができたためしがない。
0170デフォルトの名無しさん2010/03/20(土) 17:55:48
関数が第１級オブジェクトじゃない
01711402010/03/20(土) 18:07:25
>>141
レスありがとう
勉強不足だったよ
0172デフォルトの名無しさん2010/03/20(土) 18:13:26
Cの短所を挙げるより、低級言語として何が必要かを挙げる方が、いいんじゃね？

先入観なく考えうる最高の低級言語を考えればいいわけだから。
0173デフォルトの名無しさん2010/03/20(土) 18:23:17
必要な物ならCに揃ってるんじゃないのか？
0174デフォルトの名無しさん2010/03/20(土) 18:30:53
>>1
そのとおり。
そこで、それは何であるかを明らかにし、
最新のやり方でCよりも優れたやり方でそれを実現したい。
0175デフォルトの名無しさん2010/03/20(土) 18:48:50
ところで、ここで「作りたい」と言ってる人間（>>1 含めて）は、当然
CないしC++で最低限何か成果物出してる人なんだよね？

GC言語しか使えない人間がなんとかして難しいと感じてる言語を回避しようとしてる
スレではなくて
0176デフォルトの名無しさん2010/03/20(土) 19:05:12
成果を出してる人間でも、成果を出してない人間でも、そんなのどちらでもいいよ。

C/C++に代わる低級言語を開発したい意志があれば、是非意見を述べて欲しい。
0177デフォルトの名無しさん2010/03/20(土) 19:08:57
だから無理だっていってんだろ
0178デフォルトの名無しさん2010/03/20(土) 19:09:55
無理な人間はあえて参加しなくてもいいのにね＾＾
0179デフォルトの名無しさん2010/03/20(土) 19:22:01
じゃあ言い方を変えよう。
やれるもんならやってみろ。生暖かく見守っててやるよ。
0180デフォルトの名無しさん2010/03/20(土) 19:42:37
低級言語というなら
◎メモリなどのH/Wへの高速アクセス手段
◎軽量なフロー制御
◎アトミック処理
◎リアルタイム性
辺りは欲しいかねぇ。後半はC/C++にも無いけど。
他にはどんなのが必要かな？
0181デフォルトの名無しさん2010/03/20(土) 19:49:31
このあたりを言語としてあまりオーバーヘッドなくうまく扱えるようになってると便利かな。

・マルチスレッド
・割り込み処理
・メモリ管理
・物理アドレス

ライブラリでの対応でもいいけど、その場合は、
もともと言語に備わっている機能とライブラリで提供される機能が区別なく使えるのが望ましい。
0182デフォルトの名無しさん2010/03/20(土) 20:04:37
先ずは、構文糖一切なしのベースとなるプリミティブな言語仕様を定義したいね。

その上で、あとから定義した機能がもともと言語に備わっている機能のように扱えるといいかも。
0183デフォルトの名無しさん2010/03/20(土) 20:19:19
まずはbrainfuckから始めろということね
0184デフォルトの名無しさん2010/03/20(土) 20:25:32
brainfuckは低水準処理のため効率的な記述ができないから不十分だろう。
やろうと思えばできるというだけではなく、効率的にできることが重要だから。
0185デフォルトの名無しさん2010/03/20(土) 20:31:38
>>184
効率的なって何言ってんだあんた
あんなもんで何一つ書けやしないよ
ためしにあれで電卓でもつくってみ。絶対つくれないと思うけど。
0186デフォルトの名無しさん2010/03/20(土) 20:35:42
あの、brainf*ckはTM等価なんですけど……
0187デフォルトの名無しさん2010/03/20(土) 20:38:04
だから書いてみろって
絶対書けないから
0188デフォルトの名無しさん2010/03/20(土) 21:36:20
>>185
>>184に言うなよ。>>184はbrainfuckを肯定してないだろ。>>183に言え。
0189デフォルトの名無しさん2010/03/20(土) 21:36:20
さすがに自分で組む気は無いなぁ
ttp://www.unkar.org/read/pc11.2ch.net/tech/1177988460
0190デフォルトの名無しさん2010/03/20(土) 22:17:01
俺もデバドラ開発でＣじゃない新しい言語使ってみたいよ。
0191デフォルトの名無しさん2010/03/20(土) 22:25:30
奴隷は一生C使ってろｗｗｗｗ
0192デフォルトの名無しさん2010/03/20(土) 22:28:35
一生使うならCよりもっと良い言語を使いたい。
0193デフォルトの名無しさん2010/03/20(土) 22:28:51
Cと今、普通に使われている高級言語の大きな違いは、言語自体にランタイムが必要か必要でないかの違いがある
文字列型の演算、ヒープとGC、例外処理などは、ランタイムが必要
0194デフォルトの名無しさん2010/03/20(土) 22:29:17
Cが出た当時は高級言語って位置づけだったような記憶が無くもない
0195デフォルトの名無しさん2010/03/20(土) 22:36:37
>>193
何言ってんだこいつ
0196デフォルトの名無しさん2010/03/20(土) 22:36:39
>>194
一般的には低級言語はアセンブリ言語だけ。
Cは高級言語の中では低級よりなんで、低級と言ってるひとが
いてもいちいちつっこまないけど。
0197デフォルトの名無しさん2010/03/20(土) 22:38:16
中級とか言ってる奴もいるけどなｗ
0198デフォルトの名無しさん2010/03/20(土) 22:39:53
中級という表現は悪くないと思うが
0199デフォルトの名無しさん2010/03/20(土) 22:40:41
いや、別にスイーツという表現も悪くないよｗｗ
0200デフォルトの名無しさん2010/03/20(土) 22:42:57
フルーツ
0201デフォルトの名無しさん2010/03/20(土) 22:43:15
>>193
便利にすると必然的にランタイムが必要になるってこと？
0202デフォルトの名無しさん2010/03/20(土) 22:48:41
使っていない機能を細かくリンクしないようにできるなら、別にランタイムがあってもいいんじゃないの。
でも、ランタイムが肥大化しないようにこの機能を使わないようにしましょうとかウザイことになるのも嫌だな。。
0203デフォルトの名無しさん2010/03/20(土) 22:50:57
>201
そんなことは無いよ
ランタイムとして分割しておいた方がプログラムする側にとって都合がいいだけの話。
0204デフォルトの名無しさん2010/03/20(土) 22:55:34
Cのマクロ削除してくれたらあとなんでもいいよ
0205デフォルトの名無しさん2010/03/20(土) 22:57:08
>>193の処理はぜんぜんランタイムと関係ないだろ。
0206デフォルトの名無しさん2010/03/20(土) 22:58:59
>>204
マクロの代わりにtemplate
0207デフォルトの名無しさん2010/03/20(土) 23:00:49
つかランタイムの概念を根本的に勘違いしている
0208デフォルトの名無しさん2010/03/20(土) 23:01:32
俺もヘッダーの;が要らないと思う
0209デフォルトの名無しさん2010/03/20(土) 23:02:50
>>208
なにそれ？
0210デフォルトの名無しさん2010/03/20(土) 23:08:41
クラスのメンバ定義部分(?)の最後に付いてるウンコ
0211デフォルトの名無しさん2010/03/20(土) 23:20:09
そもそも、ヒープが必要な言語を使ってOSのヒープを提供する部分は記述できない。
ヒープの提供までのところは、ヒープを使わないような構文に制限するとか、
OS内部で使用するための特製のヒープを使うというのは原理的にはあり得るが、
スマートではない。
0212デフォルトの名無しさん2010/03/20(土) 23:44:12
言語仕様をコア部と周辺部に分けて、コア部でヒープの実装をして、周辺部でヒープを使えるようにすればいいんじゃないの。
0213デフォルトの名無しさん2010/03/21(日) 00:15:29
>>212
それは、CとC++の関係と同じだね　
むずかしそうだろ
0214デフォルトの名無しさん2010/03/21(日) 00:20:55
いや、C++はC++で閉じてるだろ
0215デフォルトの名無しさん2010/03/21(日) 00:29:07
言語を開発するだけではだめで、せめてLinux Kernelをその言語で書いて、
全てにおいて有用であることを実証しなければ、Cを置き換えることは無理
0216デフォルトの名無しさん2010/03/21(日) 00:32:17
>>214
そう。
C++を使ったとたんに、たとえ外部の関数を全くつかわなくてもそれなりの大きさのランタイムが必要になる。
それがどのようになっているかを考えると、OSの記述ができる言語というものの条件が分かってくると思う。
0217デフォルトの名無しさん2010/03/21(日) 00:40:15
>>215
まあ、それはその段階になったらやるから、今は言語仕様考えような。なっ。
0218デフォルトの名無しさん2010/03/21(日) 00:44:05
ライブラリ使わない場合でもC++ってランタイムライブラリ必要なの？
0219デフォルトの名無しさん2010/03/21(日) 00:46:01
必要
0220デフォルトの名無しさん2010/03/21(日) 00:46:27
>>218
例えばnewを使っただけで内部関数を呼び出すコードになる。
0221デフォルトの名無しさん2010/03/21(日) 00:50:16
ああ、そういう意味か。
0222デフォルトの名無しさん2010/03/21(日) 00:57:04
new/deleteに関しては、
メモリ確保・解放を実際に行うoperator new関数とoperator delete関数を自分で定義すれば、
原理上、ランタイムへの依存は不要になる。
0223デフォルトの名無しさん2010/03/21(日) 01:00:28
OSだってランタイムみたいなもん
0224デフォルトの名無しさん2010/03/21(日) 01:01:37
ランタイムの有無は関係ない気がする
0225デフォルトの名無しさん2010/03/21(日) 01:01:55
まあ、結局コンパイラをどう作るかって話しだろ。
0226デフォルトの名無しさん2010/03/21(日) 01:05:49
>>223
OS作る場合の話してるんだけど
0227デフォルトの名無しさん2010/03/21(日) 01:06:16
へー
0228デフォルトの名無しさん2010/03/21(日) 01:08:30
どう作るかの前に誰が作るの？
0229デフォルトの名無しさん2010/03/21(日) 01:09:14
その前に何を作るかだよ。先ずは言語仕様だ。
0230デフォルトの名無しさん2010/03/21(日) 01:21:38
>>225
そういうこと。
0231デフォルトの名無しさん2010/03/21(日) 02:00:22
言語仕様なんて適当に意見出しあってできるもんじゃないよ。
実装者は別としてもそれを集約してまとめる人が必要だと思うな。
仕様が実現可能か判断できる能力も必要。特に文法設計が一番大変だと思う。
>>1にコンパイラを書く技術があるなら当然>>1がすべき。
0232デフォルトの名無しさん2010/03/21(日) 02:17:56
>1はもういないだろ。
誰もまとめようとしていないんだし、とりあえずは与太話を続けようぜ。
0233デフォルトの名無しさん2010/03/21(日) 03:04:54
集約してまとめるのは後でするから、今はまず意見出せよ。
0234デフォルトの名無しさん2010/03/21(日) 03:09:38
結局Cに修練するんだよ
0235デフォルトの名無しさん2010/03/21(日) 03:11:22
テンプレートは欲しいな。
0236デフォルトの名無しさん2010/03/21(日) 03:13:01
>>235
ということは、OOPが必須になりますね
0237デフォルトの名無しさん2010/03/21(日) 03:13:36
テンプレートはOOではない。
0238デフォルトの名無しさん2010/03/21(日) 03:19:08
>>234
こんな進化が早い業界で40年前の言語が最適解なわけがない。
C99だとしても10年以上前だ。

現在の知識で一から言語設計すれば、Cよりもっと良い解が必ず存在する。
0239デフォルトの名無しさん2010/03/21(日) 03:36:02
じゃあテンプレートいらね
0240デフォルトの名無しさん2010/03/21(日) 03:37:16
もうちょっと賢いマクロが欲しいな。型安全で。
0241デフォルトの名無しさん2010/03/21(日) 03:51:35
>>237
OOなしでテンプレートあってもあまりうれしくない。
0242デフォルトの名無しさん2010/03/21(日) 03:59:11
テンプレートはOOとは別の総称プログラミングパラダイムの実装であるので
テンプレートとOOの有無はあまり関係が無い
0243デフォルトの名無しさん2010/03/21(日) 07:45:52
OSの中身は継承と仮想メソッドのオンパレードだから、OOは良くマッチすると思う。
で、例えばlinux kernelだとこれをC言語+キャスト+関数ポインタで実装しているから安全性が低くてかなり問題。
個人的には、これからは並列計算機の時代だしメッセージパッシングベースのオブジェクト指向言語でOSを
書いてみたい。

アドレスを直接操作する必要がある本当に低レベルな処理はOS全体の割合で見れば一部だから、それができることを
メインの仕様にする必要はないと思う。
高級な機能を制限して、低級な機能を開放するコンパイルオプションでもあればいいんじゃない？
0244デフォルトの名無しさん2010/03/21(日) 09:39:47
abs, labs, llabs, fabs, fabsf, fabslが一つの記述にまとまるってだけでも十分にテンプレートの意義がある。
同様に、関数の多重定義も認めてほしいかも。

型付けは、どうせ動的型付けやら何でも入る変数やらは不適だろうから、静的な強い型付けでいいよね。
0245デフォルトの名無しさん2010/03/21(日) 09:41:09
>>243
それでいいんだったら、Cのインラインアセンブラみたいなノリで、既存コードに
__C{
　　...
}
でいいんじゃね？
0246デフォルトの名無しさん2010/03/21(日) 10:33:45
既存がどうこうではなく、
いま、最高のプログラミング言語研究者が新たに一から新しい言語を作るとしたらどういう言語を開発するか
という観点で考えて欲しい。
0247デフォルトの名無しさん2010/03/21(日) 10:34:52
それならいま、最高のプログラミング言語研究者に聞けよ馬鹿かお前
0248デフォルトの名無しさん2010/03/21(日) 10:49:21
お前には聞いてない
0249デフォルトの名無しさん2010/03/21(日) 10:50:50
osの実装と言語の理想は水の油かな。
だからvmみたいなのが出てくる必要があるのかな。
0250デフォルトの名無しさん2010/03/21(日) 10:53:19
>>246
またお前か
自分で考える気はないようだなｗ
0251デフォルトの名無しさん2010/03/21(日) 11:01:06
>>249
(0)まっさら→(1)OSのサポートなしでコンパイラ実装→(2)OS実装→(3)OSのサポートありでコンパイラ実装→(4)アプリケーション実装

(1)(3)を両立できる言語仕様がいいね。
0252デフォルトの名無しさん2010/03/21(日) 11:58:56
>>244
同意

あと、ラムダも欲しい。
0253デフォルトの名無しさん2010/03/21(日) 12:07:54
>>246
あなたのやっていることは既存言語という基礎を無視して新しい
言語作ろうとしているようなもの。どの分野でも先人の正負合わ
せた遺産から学ばずに無視すると失敗するよ。

それに永久脳内言語なんざ付き合うほうは迷惑なんで4/1までに
色々な言語調べて叩き台の言語仕様書または良質なベース言語を
用意しませう。
0254デフォルトの名無しさん2010/03/21(日) 12:17:22
俺大学でコンパイラ研究してる院生だけど、システム開発目的でC言語相当の低機能な言語を新しく作る研究なんて見かけた事ないな。
トレンドは速度より安全性で、関数型言語とか強い型付き言語でOS書こうとする研究が多い。
0255デフォルトの名無しさん2010/03/21(日) 13:41:45
それは言語を開発してるの？それとも既存の言語？だとしたらどの言語なの？
0256デフォルトの名無しさん2010/03/21(日) 13:57:23
例えばOSの為のプログラミング言語の学会でPLOS(Programming Languages and Operating Systems)ってのがある。
新しく言語を作るって研究はほとんどないね。JavaとかMLとかHaskellとか既存言語を使ってる。
日本だとFail-Safe Cとか有名。

でもこれは別にC言語の代替言語に需要がないといういう意味ではないよ。
CやC++と同レベルの物を作るってんじゃ研究ネタにならないから誰もやらないってだけ。
0257デフォルトの名無しさん2010/03/21(日) 15:18:49
日本の雑魚研究者が何してるかなんて興味ねえ
0258デフォルトの名無しさん2010/03/21(日) 15:32:22
と、雑魚以下のプランクトンが申しておりますｗ
0259デフォルトの名無しさん2010/03/21(日) 15:33:07
ム板にはその雑魚すらいません
0260デフォルトの名無しさん2010/03/21(日) 17:00:11
cへのトランスレータが流行る訳
0261デフォルトの名無しさん2010/03/21(日) 19:31:46
OSを作りたいという需要について
0262デフォルトの名無しさん2010/03/21(日) 19:50:05
誰もやってないから面白いんじゃないの?
研究者としてはw
0263デフォルトの名無しさん2010/03/21(日) 19:56:51
おそらく未踏で出てくるぞ。で、詐欺のような結果をだして逃げ切るはずｗｗ
0264デフォルトの名無しさん2010/03/21(日) 20:15:12
俺大学でコンパイラ研究してる院生だけど、プリキュアは初代以外認めないな
0265デフォルトの名無しさん2010/03/21(日) 20:33:27
おまえら本当に口だけだなあ……
草案でもいいから、なにか出してみろよ
0266デフォルトの名無しさん2010/03/21(日) 20:52:31
アイディアあるんだったら今作ってる俺言語に盛り込むよ。
面倒臭い思いしてまで草案なんて作るわけないだろ。
0267デフォルトの名無しさん2010/03/21(日) 21:19:46
Cにさしたる欠点がないから出てこないよ
0268デフォルトの名無しさん2010/03/21(日) 21:21:58
C(笑)
0269デフォルトの名無しさん2010/03/21(日) 21:48:08
>>254
他人がやってないと安心できない研究者ってダメだろｗ
0270デフォルトの名無しさん2010/03/21(日) 22:23:59
Cの再発明はそれ以下だけどな。
0271デフォルトの名無しさん2010/03/21(日) 22:39:45
ということで、LispやRubyやJavaの再発明ばかりしていないで、
最新の言語研究の成果を取り入れたCに代わる低級言語を開発しよう。
0272デフォルトの名無しさん2010/03/21(日) 22:51:24
D言語との差別化は？
0273デフォルトの名無しさん2010/03/21(日) 23:07:05
既存の何かと違う何かを作るのではない。

最新の言語研究の成果を取り入れた新しい低級言語を作るのだ。

既存言語との差は、言語仕様ができてからdiffをとれば分かる。
0274デフォルトの名無しさん2010/03/21(日) 23:30:49
だからお前の言う最新の言語研究の成果って具体的に何さ？論文持ってこいよ。
0275デフォルトの名無しさん2010/03/21(日) 23:39:59
最新の言語研究の成果について知らないなら、このスレに参加しなくていいですよ＾＾
0276デフォルトの名無しさん2010/03/21(日) 23:47:32
要はバカばっか
0277デフォルトの名無しさん2010/03/21(日) 23:48:51
どういう境遇にいればこんなざまで生きてこれるのか興味が
0278デフォルトの名無しさん2010/03/22(月) 00:05:33
最新の結果なんか、そいつらが実験的なプログラミング言語をつくってるだろ
実用を目指すなら、Matureなものから取捨選択だろ
0279デフォルトの名無しさん2010/03/22(月) 00:10:30
っていうか、実際作るつもりのやつっているのか。
0280デフォルトの名無しさん2010/03/22(月) 00:25:10
言語仕様ができたら作るだろ。
0281デフォルトの名無しさん2010/03/22(月) 00:39:17
>>1はスレ立てた時点で開発とコミュニティ育成が始まっているという認識無さすぎ。
スレ立てる前に言語仕様草案を作っておいて、さらに議論進めながら
協力者募るって一切やってない時点で空中分解している。

>>275
「私は何もできません。中二病に羅漢したいです。だれかやってください。他力本願(はぁと)」
っつうくだらない自己弁明はうざいから、お前の言う最新の計算機言語学関連論文の
リソースちゃんと出してくれる？ そうしないと一向に進まないんだが。
0282デフォルトの名無しさん2010/03/22(月) 00:41:46
ｷﾓｲ
0283デフォルトの名無しさん2010/03/22(月) 01:06:25
C相当の機能に、強力なマクロ（コンパイル時処理）とクラスと名前空間があればいい。
0284デフォルトの名無しさん2010/03/22(月) 01:14:31
×羅漢(らかん)
○罹患(りかん)
0285デフォルトの名無しさん2010/03/22(月) 01:15:31
>>283でいいよ
0286デフォルトの名無しさん2010/03/22(月) 01:16:33
ヘッダーファイルが要らない
0287デフォルトの名無しさん2010/03/22(月) 01:18:41
他人のマクロがうざい
0288デフォルトの名無しさん2010/03/22(月) 01:22:39
今から新しく作るのにマクロかよ
0289デフォルトの名無しさん2010/03/22(月) 01:24:19
型安全なマクロ
0290デフォルトの名無しさん2010/03/22(月) 01:30:19
おれjava2cppつくったよ。
俺専用なんでいろんな縛りあるけど実用してる。
0291デフォルトの名無しさん2010/03/22(月) 01:34:25
機能のトランスレートだけならどうにでもなる。
が、単にVMで動作していたものが関数呼び出しに変わるだけでは全く意味はない。

必要なのは実用的にオーバーヘッドなく低レベルの処理を記述できることだ。
0292デフォルトの名無しさん2010/03/22(月) 01:37:27
cppネイティブな記述に変換してるし速度的なメリットもあると思うけどな。
コードがシンプルになる＆どちらのプラットホームでも使えることを目的としてるし。
0293デフォルトの名無しさん2010/03/22(月) 01:39:02
>>83
langageって何語？
英単語では知らないけど、ドイツ語とかラテン語とかかな。
グーグルさんに「もしかして・・・」って指摘されないし。
0294デフォルトの名無しさん2010/03/22(月) 01:41:43
ひとつの記述から生成される実行プログラムは原理的には同じような性能しか持ち得ない。

一方が他方より性能が優れるのであれば、他方が単に馬鹿なだけだ。
0295デフォルトの名無しさん2010/03/22(月) 01:42:28
発想力が足りないね
0296デフォルトの名無しさん2010/03/22(月) 01:42:46
>>293
languageじゃないの？
0297デフォルトの名無しさん2010/03/22(月) 02:00:02
テンプレートが神速でコンパイルできる言語を開発して下さい
コンパイル時間短縮のためにメタ関数の遅延実行とか
考慮するのが面倒なんです
0298デフォルトの名無しさん2010/03/22(月) 02:04:11
>>1
C/C++に代わる言語のコンパイラは、先ずはCで書くの？
0299デフォルトの名無しさん2010/03/22(月) 02:04:37
コンパイル時間ために言語仕様を妥協することには反対。

コンパイルオプションでヘボイバイナリを高速に吐いたり、高速・コンパクトなバイナリをじっくり生成したり、選べるならいい。
0300デフォルトの名無しさん2010/03/22(月) 02:05:26
>>298
好きにしろ。Cでもいいよ。
0301デフォルトの名無しさん2010/03/22(月) 02:08:09
Dは、みなの希望を満たしているね
0302デフォルトの名無しさん2010/03/22(月) 02:08:59
Dは違う。
0303デフォルトの名無しさん2010/03/22(月) 02:11:34
>>302
何が不都合？
0304デフォルトの名無しさん2010/03/22(月) 02:13:26
言語名
0305デフォルトの名無しさん2010/03/22(月) 02:14:33
Linuxカーネルだって最初は小さいコードだったんだ。
どこかの一人の天才が先ず始めて、それからみんなでよってたかって作ればうまくいくよ。
0306デフォルトの名無しさん2010/03/22(月) 02:16:52
小さいコードでもその段階で「いける」って思わせるレベルのものなんだよな
0307デフォルトの名無しさん2010/03/22(月) 02:22:24
2ch発の言語が誕生するか見てるがまるで駄目だな。全くできそうな気配もないw
0308デフォルトの名無しさん2010/03/22(月) 02:23:41
お前、ワクワクし過ぎｗ
0309デフォルトの名無しさん2010/03/22(月) 02:30:38
結局どんな改良がしたいの？
0310デフォルトの名無しさん2010/03/22(月) 02:31:14
言語仕様に組み込みの機能（forとかifとかあれば）と全く同じように扱える、my_forとかmy_ifとかを独自に定義できるといいな。
0311デフォルトの名無しさん2010/03/22(月) 02:31:58
>>309
改良じゃない。

最新の言語研究の成果を取り入れた新しい低級言語を作るのだ。
0312デフォルトの名無しさん2010/03/22(月) 02:32:47
>>311
言葉遊びはいい。Cでできないなにを目的に新しい言語作りたいの？
0313デフォルトの名無しさん2010/03/22(月) 02:34:48
効率良くプログラミングをしたいんだろ。

Cがあるのに、C++、C#、Java、F#、Haskell、OCaml、Ruby、Pythonが出てきているのと同じことだ。
0314デフォルトの名無しさん2010/03/22(月) 02:37:07
効率よくって具体的になんだよ。
C++じゃだめなの？Javaじゃだめなの？
どこがだめだから違う言語がほしいの？
0315デフォルトの名無しさん2010/03/22(月) 02:37:31
蓮舫は来なくていいよ。
0316デフォルトの名無しさん2010/03/22(月) 02:38:37
答えられないと仕分けされるよ
0317デフォルトの名無しさん2010/03/22(月) 02:41:54
↓このヒトが言語仕様をまとめます
0318デフォルトの名無しさん2010/03/22(月) 02:44:20
いらない
0319デフォルトの名無しさん2010/03/22(月) 02:48:30
Cが無かったとして、

最高の研究者を集めてOS開発用のプログラミング言語を作らせたらどんな言語を作るだろうか

という思考実験としても興味がある。
0320デフォルトの名無しさん2010/03/22(月) 02:57:31
このスレざっと見たけど具体的なこというやつほとんどいないな。
0321デフォルトの名無しさん2010/03/22(月) 03:01:16
>>319
俺も興味アリ
0322デフォルトの名無しさん2010/03/22(月) 03:03:03
結局Cに収斂するよ
0323デフォルトの名無しさん2010/03/22(月) 03:08:21
>>1いわく
低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
とOOを保ちながら文法を整理するといってるみたいだが
文法の汚さって具体的にどこ？C++の部分？
0324デフォルトの名無しさん2010/03/22(月) 03:18:10
つーか、Cに不満はあっても、膨大な資産を捨てて新大陸作って移住しよう、ってほど
不満なCプログラマはほとんどいないだろ。
Cが全然使えません、って人なら新大陸欲しいのかもしれないけど。そんな奴が低水準
に触るのはぶっちゃけ無理だしスクリプト系で我慢しろと。重い安全装置付いてっから。
0325デフォルトの名無しさん2010/03/22(月) 03:22:26
セミコロンが死ぬほど嫌いならトランスレータ作ればいいよ
それこそPythonあたりで簡単に作れるよ

そのセミコロン排除言語を使いこなすには、Cを使いこなす能力が必要だけどな
あと、改行で続けたい時はバックスラッシュな
あと、普通のCを読み書きしようとすると死ぬ、ってのも覚悟な
0326デフォルトの名無しさん2010/03/22(月) 03:23:34
文法が汚いってだけならホントにどうでもいいな
0327デフォルトの名無しさん2010/03/22(月) 04:15:30
同じ事を何回繰り返せば気が済むんだろう
環境に依存しないアセンブラが理想、それはCであり、究極的にはJavaなんだよ
それ以上もそれ以下も無い。車輪の再発明はやめろ
0328デフォルトの名無しさん2010/03/22(月) 04:59:25
まずは、C のポインタで実現している機能・効率と、
Haskell 並みに強く型付けされた言語の安全性を両立したいなあ。

03291792010/03/22(月) 07:00:03
な、何も進まないだろ。
>>319のバカが同じこと何度も（すくなくとも４度は）書いてるだけで。
Ｃの牙城がいまだに崩れないのはそれなりに理由があるんだよ。
0330デフォルトの名無しさん2010/03/22(月) 07:03:18
Dでいいでしょ
Cの資源も使えるし
0331デフォルトの名無しさん2010/03/22(月) 07:12:41
Ｄって全然知らないけど何なの。
Ｃ＃はＣに見た目だけ似てるＬＬ言語だってのは知ってるけど、そんなようなもん？
ＪＡＶＡもそんなようなもんだし。
もしそうならＣの代わりなんてとても務められないじゃん。
0332デフォルトの名無しさん2010/03/22(月) 07:18:36
想像で何を言っとるんだwww
ネイティブコンパイルなマルチパラダイム言語だよ
0333デフォルトの名無しさん2010/03/22(月) 07:23:39
説明になってないな。
おまえは「プログラムできないやつが適当に話を合わせるスレ」に帰れよ。
0334デフォルトの名無しさん2010/03/22(月) 07:47:07
＞C/C++は高速だが過去のしがらみから文法が致命的に汚い。
＞C#の文法は洗練されているが中間コードやGCを前提としているため致命的に遅い。
＞LL系の言語さらに遅い。
Dは中間コードを吐かずネイティブコンパイルするので高速。
GCは備えてるが、malloc を使う事もできるので、GCの速度が気になるなら malloc を使えばいい。

＞そこで、C/C++に代わるOSも作れるような低級プログラミング言語を開発したい。
GCさえ使わなければOSを作る事も可能。

＞文法はCに似ている方が望ましいが、
＞低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
＞を担保出来るなら、どんな形式でも構わない。
文法はCにある程度似ている。
C++は文法がコンパイラの作成の容易さを考えて作られてないため
構文解析が非常に大変で、コンパイルも遅いが、
Dはコンパイラの作成の容易さも考えて作られているため、
コンパイラも作りやすいし、コンパイルが高速になる。
インラインアセンブラも使えて、ネイティブコンパイルなのでパフォーマンスも高く、
（敢えて複雑な事をしなければ）可読性も高く簡潔で、
Cの資源も利用できるし、現代的な各種言語仕様を取り入れており、拡張性も高い。
やれる事が多いので、学習の容易さに関しては難はあるかもしれない。

＞プログラミングパラダイムについても、オブジェクト指向を備えることが望ましいが
＞生産性を高めることが出来るのであれば、他の方式が入っても構わない。
OOP、テンプレート、mix-in、プロパティ、GC、高度な条件コンパイル、契約、
連想配列、遅延評価、ローカル関数、ラムダ式、クロージャなど、
伝統的な方式から現代的な方式までかたっぱしから取り入れられている。


欠点は言語仕様が安定しないこと。これに尽きる。
古いソースは今のコンパイラでは大抵コンパイルできない。
逆に言うと、言語仕様が安定しさえすれば普及するかもしんない。
0335デフォルトの名無しさん2010/03/22(月) 08:25:13
なんか全然まとまらないから、言語仕様作るとこまで自分が仕切ってみても良いですか？
0336デフォルトの名無しさん2010/03/22(月) 08:26:49
作るならDよりいいものにしてよね
0337デフォルトの名無しさん2010/03/22(月) 08:37:56
>>335
言語仕様があっても、バイナリを生成するコンパイラが出来なければ、まさしく絵に書いた餅で終わるわけだが

コンパイラを作るにはCPUの詳細な知識が必須でしょ？そんなやついるの？
0338デフォルトの名無しさん2010/03/22(月) 08:41:11
Cのソースにコンパイルできればそれでいいよ
0339デフォルトの名無しさん2010/03/22(月) 08:41:46
作れるけどこんなバカバカしい話には乗れん
0340デフォルトの名無しさん2010/03/22(月) 08:46:56
むしろ絵に書いた餅のうちが楽しいんだぞ
味を想像する余地があって
0341デフォルトの名無しさん2010/03/22(月) 09:01:28
動画、サウンド、2D/3D描画とかのライブラリも全部作り直しになるのか？
移植するにしても、Cと似てない構文なら大変そうだし、Cからの単純移植ならそれは新言語の特性を生かさないという意味では
0342デフォルトの名無しさん2010/03/22(月) 09:10:24
APIの呼び出しはそのままにしておけ
特に帰ることもないだろう
0343デフォルトの名無しさん2010/03/22(月) 09:10:31
Cのライブラリをそのまま使えればいい話だろ
03443352010/03/22(月) 09:15:11
自分もコンパイラは作れますが、まとめ役だけに徹します。
すごく面白い発想の言語なら作りたい人が現れるかもしれません。

とりあえず

・手続き型＋OO＋テンプレートのマルチパラダイム
・バイトコード無し・VM無し・GC無し

という意見が多そうですが、ここは固定でいいですか？
0345デフォルトの名無しさん2010/03/22(月) 09:20:15
多重継承out
mix-in in
で
0346デフォルトの名無しさん2010/03/22(月) 09:25:01
PHPでいいよ　これを改良しろよ
ガベージコレクションがあるか無いかは言語の文法とは別な気はするが。
PHPをGCなしでコンパイル使用とすれば出来る
C言語をGCありのスクリプトにも出来る。
0347デフォルトの名無しさん2010/03/22(月) 09:25:42
PHPみたいな糞言語をどうしろと
0348デフォルトの名無しさん2010/03/22(月) 09:26:32
ヒロポンとかいうOS作っていたやつのOSはどうなった?一度も動かしたことがない。
ある程度のシェアとれる見込みはあったのか。起動だけ出来れば良かったのか。
0349デフォルトの名無しさん2010/03/22(月) 09:44:21
テンプレートなんか許可したらコンパイラ作る手間が爆発的に増加するぞ
0350デフォルトの名無しさん2010/03/22(月) 09:56:43
（テンプレートを何だと思ってるんだろう）
0351デフォルトの名無しさん2010/03/22(月) 09:59:26
>>344
言語名はd--か。
0352デフォルトの名無しさん2010/03/22(月) 10:00:11
C C++ D-- D

なんだこれ
03533552010/03/22(月) 10:31:36
>>349
手間はとりあえず無視しますか。技術的に可能ならOKということで。

>>351
このままだと劣化C++になりそうですね。つまらないですね。

VMの有無に関して意見ないですか？
自分は今時ネイティブコンパイルとか古臭いと思っているのですが、みなさんどう思いますか？
0354デフォルトの名無しさん2010/03/22(月) 10:33:43
おいおい、低級プログラミング言語を作るんだろ？
ネイティブコンパイル一択だろ
0355デフォルトの名無しさん2010/03/22(月) 10:39:34
劣化C++ですらねーな
0356デフォルトの名無しさん2010/03/22(月) 10:46:24
だから>>151で終了してるんだと何度言えば
0357デフォルトの名無しさん2010/03/22(月) 10:48:01
C++にそれなりにとって変わられてんのに
結局Cにはかなわないと結論づけてる文に
どれだけの価値があるのか
0358デフォルトの名無しさん2010/03/22(月) 10:49:54
>>354
そもそもC言語ですら、低水準言語の定義には当てはまらないじゃないですか。
インラインアセンブリを使わないと書けない処理とかあるわけですから。

ネイティブコンパイルでも良いと思うんですが、OSが書けりゃいいんだし、
安全性や高速化という観点で検討してみてもいいかとは思います。
ただの問題提起です。
0359デフォルトの名無しさん2010/03/22(月) 10:50:59
C++で書かれたOSってなんかあるの？
0360デフォルトの名無しさん2010/03/22(月) 10:52:15
>>357
C++で書かれたOSの例を挙げてみろ
0361デフォルトの名無しさん2010/03/22(月) 10:52:53
OSの話なのか
0362デフォルトの名無しさん2010/03/22(月) 10:53:54
ずーっとＯＳの話してるだろアホかお前
0363デフォルトの名無しさん2010/03/22(月) 10:55:53
pascalで書かれたOSならあるな
0364デフォルトの名無しさん2010/03/22(月) 10:58:51
VMの話とかされちゃ
OSの話とは思わない罠
0365デフォルトの名無しさん2010/03/22(月) 11:00:22
InfernoとLimboの劣化再発明を議論しているスレはここですか？
0366デフォルトの名無しさん2010/03/22(月) 11:00:26
手続き型にするとして、駆動レコードとかどうする？
サブルーチン一択にする？コルーチンもOKにする？それともForthみたいにユーザーが駆動レコードを弄れるようにする？
新しいフレームを作らない手続きとかも欲しいなぁ。

というかForthやろうぜ。
0367デフォルトの名無しさん2010/03/22(月) 11:00:44
Ring0の命令を扱うための構文とかあったほうがいいのだろうか
ライブラリで十分か
0368デフォルトの名無しさん2010/03/22(月) 11:16:35
機種依存コードのIFDEFをすっきり書けるようにしてほしい
C++のclassとは別の枠組みで実装の特殊化ができる

後は、エンディアンやアラインメント指定のコンパイラ標準サポートとか
0369デフォルトの名無しさん2010/03/22(月) 11:22:37
>>368
中間言語使わずにやるのは夢物語だな
0370デフォルトの名無しさん2010/03/22(月) 11:24:53
＞機種依存コード・エンディアン
D言語のversion構文で十分
エンディアンによるversion分岐も標準でサポート

＞アライメント
D言語のalign属性で十分
0371デフォルトの名無しさん2010/03/22(月) 11:29:36
D言語ではダメな理由は？
0372デフォルトの名無しさん2010/03/22(月) 11:31:59
いろいろついてて重そうだな。
ゲーム機や組み込み機などの省資源では足かせになりそうだ。
0373デフォルトの名無しさん2010/03/22(月) 11:36:39
>>370
そうか、そういうのはDから輸入すればいいな

ただしエンディアンについてはversionで分けるだけでなく
同一記述から、指定したエンディアン用のコードが生成できる必要があると思うが
そういうのもＤは可能？
0374デフォルトの名無しさん2010/03/22(月) 11:37:21
enbeded Dでいいんじゃね
0375デフォルトの名無しさん2010/03/22(月) 11:39:52
>>373
流石にそういうのはないかなあ
まあそういうクラスを作れば可能だろうけど
03763352010/03/22(月) 11:41:39
自分はD言語で十分に思います。
スレの内容的にツッコミどころあるとすれば

最新の言語研究成果を使いたい(?)
→ D言語は成熟した・古い技術しか使っていない

超高速にしたい
→ D言語は高速化に重点を置いた言語仕様ではない。最適化が効かない。

くらいでしょうか。
0377デフォルトの名無しさん2010/03/22(月) 11:41:40
やっぱりD--だなw
0378デフォルトの名無しさん2010/03/22(月) 11:42:41
最新技術って例えばどういうもの？
0379デフォルトの名無しさん2010/03/22(月) 11:46:29
Dは仕様を提案すると
入れてくれることもあるで
03803352010/03/22(月) 11:49:12
>>378
例えば、JITや自動並列化などでしょうか？技術自体は古いですが、まだ広まっていはいないですね。
高速化以外だと、モデル検査による安全性の検証とかですかね。
0381デフォルトの名無しさん2010/03/22(月) 11:54:23
>>380
OS記述するとき、それらはどうなる
0382デフォルトの名無しさん2010/03/22(月) 12:03:05
JITはネイティブコンパイラには全くの無意味では・・・
自動並列化は面白いが、基本的にOSあってのものだよね

モデル検査とか一般的なプログラムで適用可能なんだろうか？
安全性に関してはDの契約が現実的な解な気がする
03833352010/03/22(月) 12:08:11
>>381

後者の場合、例えば
デバイスドライバなどのOSのモジュールが満たすべき要件を記述したファイルを用意しておいて、
ユーザのプログラムがそれを満たしているかコンパイル時に検査することで、安全性の高いOS開発ができる
といった使い方が提案がされています。

JITの場合は
OSの最下層にJITを組み込んだランタイムを用意して、OS本体やユーザアプリケーションはバイトコードの形式にし、
それをJITコンパイルして実行
という形が考えられます。高速化は期待できますね。
でもこれは、言語設計に制約は課さないから今考えなくてもいいかも知れません。

自動並列化の場合は言語設計が重要です。C・C++・Dの様な言語では困難な技術です。
0384デフォルトの名無しさん2010/03/22(月) 12:18:35
ヒープや並列処理は、OSがあるというのが前提なので、そういうのを言語自体にとりこむのは、目的にかなっていない。
03853352010/03/22(月) 12:48:57
別にブートローダとかメモリマネージャとかを書く専用言語を作りたいわけじゃないじゃないですか。
低レベルな処理を記述できる言語機能を持たせればいいのでは？
0386デフォルトの名無しさん2010/03/22(月) 12:53:54
コンパイラ自体が未知の（これから作る）OSの仕様に依存してどうすんのよと
03873352010/03/22(月) 12:59:59
並列化サポートのある言語で直列コードにコンパイルしても別にいいじゃないですか。
JITサポートのある言語をネイティブコードに(ry

GCとかとなれば話は別ですけれども。
0388デフォルトの名無しさん2010/03/22(月) 13:04:04
簡易な記述でハードウェアリソースを使い倒せて
既存のコードやライブラリが流用できるなら
OSごと入れ替える価値はあるなぁ

ネットワーク上の別マシンのリソースもローカルのコアも意識せずに扱えるとか
んで、リソース配分はJITでとか、夢が広がりまくりですな
0389デフォルトの名無しさん2010/03/22(月) 16:35:46
このスレでJITを持ち出すなんて
ただ技術的に新しいことやりたいって自己満足に過ぎないわ
0390デフォルトの名無しさん2010/03/22(月) 18:22:26
>>344
ちょっと前に流行ったカンスーガタとかを含めるのは難しいかな。
0391デフォルトの名無しさん2010/03/22(月) 19:19:44
文字列リテラルに直接文字列クラスのメソッドを適用できるようにして欲しい
0392デフォルトの名無しさん2010/03/22(月) 19:38:31
いらね
0393デフォルトの名無しさん2010/03/22(月) 19:50:22
便利で高速なライブラリでも開発した方が余程役立つだろ
0394デフォルトの名無しさん2010/03/22(月) 19:53:55
便利で高速なライブラリを開発できる言語仕様ができればいいと思う。
0395デフォルトの名無しさん2010/03/22(月) 19:54:51
理想言語スレなので役立つかどうかなんて正直どうでもいいのよ
0396デフォルトの名無しさん2010/03/22(月) 19:56:30
D言語が有名になればいいだけみたいだな
0397デフォルトの名無しさん2010/03/22(月) 19:57:24
>>395
同意。
0398デフォルトの名無しさん2010/03/22(月) 20:02:16
>>396
仕様が安定すれば、もう少し有名になるんじゃないか？
いや最近のD言語まわりの事情を知らんのだけれど
0399デフォルトの名無しさん2010/03/22(月) 20:04:05
D厨ウゼー
0400デフォルトの名無しさん2010/03/22(月) 20:07:26
クロージャー欲しい
0401デフォルトの名無しさん2010/03/22(月) 20:08:05
クロージャならD言語にあるで
0402デフォルトの名無しさん2010/03/22(月) 20:09:01
あんたらの求めてるモンD言語に全てありまっせ
0403デフォルトの名無しさん2010/03/22(月) 20:10:00
とりあえず片っ端からつっこみまくったからな
0404デフォルトの名無しさん2010/03/22(月) 20:12:42
そしてゴミ溜め状態になるんですねわかります
0405デフォルトの名無しさん2010/03/22(月) 20:13:07
腐臭がする
0406デフォルトの名無しさん2010/03/22(月) 20:13:11
クロージャってGCない環境でも実装できるの？
0407デフォルトの名無しさん2010/03/22(月) 20:13:36
コアの言語仕様は小さくして、拡張性を高めた方がいい
0408デフォルトの名無しさん2010/03/22(月) 20:16:17
片っ端から仕様を詰め込んではいるが
構文解析が楽になるよう言語仕様を決めてるから
コンパイラを作るのはC++に比べて格段に楽らしい
0409デフォルトの名無しさん2010/03/22(月) 20:19:41
何でもかんでも入れると結局使えない言語になるから、
>>407の言うように言語仕様は小さくて拡張性の高い言語にするのがいいだろうな。
0410デフォルトの名無しさん2010/03/22(月) 20:20:48
コアを小さくする必要はどこにもない
進化に付いていけない奴はこのバスから降りるしかない
0411デフォルトの名無しさん2010/03/22(月) 20:23:39
小さいからコアなんだろ、アホｗｗ
0412デフォルトの名無しさん2010/03/22(月) 20:25:29
昭和脳がITを窮屈にする
0413デフォルトの名無しさん2010/03/22(月) 20:25:29
何をコアと呼ぶかは議論があると思うが、言語仕様を階層化しておくのは良いやり方だと思う
0414デフォルトの名無しさん2010/03/22(月) 20:30:35
小さいコアならCで十分なような
0415デフォルトの名無しさん2010/03/22(月) 20:32:33
>>407ってLiXXとかLuXとかあの想像する
要するにカス
0416デフォルトの名無しさん2010/03/22(月) 20:33:45
>>414
十分とかそう言うのは関係なくて、

いま1から言語を作れといったらCにならないだろ。
40年前ならCになった。

じゃあ、今ならどうなるの？って話。
0417デフォルトの名無しさん2010/03/22(月) 20:35:15
ネイティブ生成が古いってのは、Googleの誰ぞが言ってるようなランタイム最適化
優位論に近いんかな？
正直あれはそんなうまく行くとは思わないんだけどな。Crusoe的な直線番長になる
だけだと思うが。立ち上がりは確実に悪いし、立ち上がりで作業が終わってしまう。
動的にやる分のコストもタダじゃない。MTで振り分ける手もあるかもしれないが、
MTならば並列化手法との比較優位が見えないと微妙。
不透明な動的コストが果たして低水準処理と相性がいいのかどうか。不透明な動的
コストといえばGCを思い出すが、原理的にはあれよりは扱いやすいかもしれないが。
そもそも低水準を触る理由は、速さが欲しいだけなのか、生じゃないと困るのか。
後者ならVMは論外。というか、VM路線がどうもうまく行かなくて後退してるのが
最近の流れだと思うが。VMと相性良さそうな携帯電話ですら。
つーかVMでいいならScalaでいいんじゃねーの。JavaVMはVMとしちゃ相当速いし。
0418デフォルトの名無しさん2010/03/22(月) 20:37:48
「OS/VMを作るための低水準言語を考えよう」って言えばいいのかもな。
0419デフォルトの名無しさん2010/03/22(月) 20:42:01
じゃあ今ならどうなるの？

→Dになります
0420デフォルトの名無しさん2010/03/22(月) 20:42:50
ｷﾓｲ
0421デフォルトの名無しさん2010/03/22(月) 20:44:57
今ならわざわざ作らない
0422デフォルトの名無しさん2010/03/22(月) 20:49:29
それならCにできないけど低級言語に欲しい機能を挙げてみようぜ。
・Lispなみに弄くれるマクロ
- テンプレート
- 正規化された構文(S式とか)
・Forthなみに弄くれる駆動レコード
- コルーチン
- 強制インライン展開(レコードを新しく作らないルーチン)
- 駆動レコードへのアクセス
・実行制御
- 高度な並列処理(トランザクションとか)
- アトミック操作
- リアルタイム操作

こんなもんかね？ 他にどんなの欲しい？
0423デフォルトの名無しさん2010/03/22(月) 20:51:04
>>422
>・Lispなみに弄くれるマクロ

これいいなぁ(ﾟＡﾟ;)ｺﾞｸﾘ
0424デフォルトの名無しさん2010/03/22(月) 20:52:51
並列化しやすいデータ構造とかループ構文とかくれ
0425デフォルトの名無しさん2010/03/22(月) 20:53:28
諸刃の剣だけどな
0426デフォルトの名無しさん2010/03/22(月) 20:59:04
>>346
CGありのCは需要がありそうだけど、
deleteだかfreeだかやらないといけないPHPなんてだれも使わなそう。
0427デフォルトの名無しさん2010/03/22(月) 21:00:08
1は「低級言語」って言ってんだからＤ言語なんて全く反対方向だと思うが…

それより、パフォーマンスだの可読性だのと一気に全て求める辺り
なんか>>1が言語の開発の何たるかを知らん臭い。

下記サイトでyacc/lexの勉強汁。
ttp://kmaebashi.com/programmer/devlang/index.html

つうか、じつは俺様もyaccの解説を幾ら読んでもチンプンカンプンだから、
そんとこを解るまで御教示願いたいと常々思ってるんだけどな。
解れば自分で勝手に好きな言語作ってシコシコする。
0428デフォルトの名無しさん2010/03/22(月) 21:02:41
> なんか>>1が言語の開発の何たるかを知らん臭い。

それはスレタイの時点で既に
0429デフォルトの名無しさん2010/03/22(月) 21:05:35
変数はレキシカルスコープでお願いします。
0430デフォルトの名無しさん2010/03/22(月) 21:08:34
>>422
・マルチスレッド

機能としてはライブラリでの提供でいいけど、構文としても備えていて欲しいな。
0431デフォルトの名無しさん2010/03/22(月) 21:45:56
>>422
トランスレータ形式での実装限定になるかもしれないがインラインアセンブリは当然としてインラインC/C++欲しいところです。
これによりライブラリラッパーが書きやすくなり、既存の資産を僅かな修正で活用できるかと。

さらに標準型(predefined-type)は少なく可読性に優れた文法のほうがいいですね。
0432デフォルトの名無しさん2010/03/22(月) 21:49:51
D（ry
0433デフォルトの名無しさん2010/03/22(月) 21:51:28
C/C++使えばいいだろ

じつに馬鹿だな君は
0434デフォルトの名無しさん2010/03/22(月) 22:24:00
全然知らないんだけどさ、GOってどうなの？
0435デフォルトの名無しさん2010/03/22(月) 22:41:24
>>335さんは今頃頑張ってる頃か。何にせよ具体的なものが出てきたら盛り上がるだろ。
04363352010/03/22(月) 22:53:32
>>435
今帰ってきた処で何も具体的な物は作ってません(--;
自分の分かる範囲で意見を書きます。

>>389
新しい事考えないと自分のモチベーションが維持できないので・・。確かに自己満足です。

>>390
手続き型言語に関数オブジェクトを追加という意味なら容易です。
関数型言語にするという意味なら、型システムの健全性(コンパイル可能ならプログラムは正しい)を保つのが大変そうです。でも面白そうですね。

>>406
ダイナミックスコープならGC無しでも可能だと思います。
レキシカルスコープなら、ヒープに確保した自由変数を解放する必要があります。GCがあった方が楽ではあるでしょう。

>>409
小さい仕様のコアを実装して、強力なメタプログラミング機能をつけるという感じでしょうか。

>>417
適材適所の一言に付きます。個人的にJITを推す理由を書きます。
- OS等の整数系プログラムの場合はAOTでは不可能な分岐除去が劇的に効く
- キャッシュ最適化はJITが遙かに優位
- ランタイムをOS組み込みにするならば、起動オーバヘッドは削減出来る。
- GCCがLLVMを取り入れたように、むしろ今のトレンドなのでは(自信ない)

>>422
LISPマクロいいですね。Forth面白いですね。
トランザクションは低級言語では難しそうですね。VM作ってSTMを実装ということになると思いますが、一部のプログラムを覗いて激しく遅いという噂です。

>>424
データ構造・ループ構文ももちろんですが、ポインタをどうにかする必要がありますね。
04374092010/03/22(月) 23:12:31
>>436
>小さい仕様のコアを実装して、強力なメタプログラミング機能をつけるという感じでしょうか。

そうだねー。
それと、”標準ライブラリ”が必要だろうから、それを見据えたメタプログラミング機能かな。
0438デフォルトの名無しさん2010/03/22(月) 23:15:36
>>436
繰り返しの話になってる気がするんだが、
「速度が欲しいんじゃなくて、低水準をほとんど生で触りたい」っつー需要については
守備範囲外だから引き続きC/C++を使っててください、ってことでいいのね？
その場合、低水準に触れるメリットは全く無く、C/C++に匹敵する速度、だけが売りに
なる訳だけど、そうするとScala辺りでいいんじゃないの、ってのはどうなのよ。

あと、VMの起動が重いなんて話じゃなく、アプリの中身のコードの立ち上がりが重い。
トレンドについては、実験ネタとして流行ってるが、どれも実験してるだけに見える。

まぁ、成功の見込みがそもそも無いと思うから、好きに実験すればいい気もする。
つーかこのネタについては建設的意見を全く持ち合わせてないから、この辺にしとく。
一応頑張れ。
0439デフォルトの名無しさん2010/03/22(月) 23:27:07
>>319
最高の研究者を集めてＣＰＵを作らせたらどんなＣＰＵを作るだろうか
という思考実験にはなぜ興味がないのだろうか

ＣＰＵに興味がないのと同様に、言語にも興味がなくなるように仕向けることは
できないだろうか
04403352010/03/22(月) 23:38:01
>>438
JITは言語バックエンドの話で、バックエンドは場合に応じて選択可能ですから「速度」と「低水準」を両立する事は可能だと思います。
「低水準を生で触る」という需要も満たせるように考えましょう。
というか、今JITの有無にこだわっても言語仕様には影響ないから意味なかったですね。すいません。

>>439
>>319は私ではありません。
0441デフォルトの名無しさん2010/03/22(月) 23:42:41
>>439
> 最高の研究者を集めてＣＰＵを作らせたらどんなＣＰＵを作るだろうか
> という思考実験にはなぜ興味がないのだろうか

興味あるけど、スレ違いだから別のスレッドでやってね＾＾
応援するよ＾＾
0442デフォルトの名無しさん2010/03/22(月) 23:47:00
「低水準を生で触る」を今風のやり方で出来るといいな。
0443デフォルトの名無しさん2010/03/23(火) 01:00:01
既存の〜があるからそっち使えばいいって正論だけど、日本発のオープンの言語を作ってやろうって
気概を持った人が少ないよ。いつから日本人はこんなに自信を失ってしまったんだ。
ガイジンが作ったものに飼い慣らされるな！

俺？気概も自信もあるわけないじゃないですか(^q^)
0444デフォルトの名無しさん2010/03/23(火) 01:03:03
　　　　　　　　　　　　　　　　　　｜

　　　　＼　　　　　　　　　　　　ノ´⌒ヽ,,　　　　　　　　　　／
　　　　　　　　　　　　　　γ⌒´　　　 　 ヽ,
　　　　　　　＼　　　　／／ ""⌒⌒＼　　）　　　　　／
　　　　　　　　　　　 　ｉ /　　 ⌒　 ⌒　ヽ　）
　　　　　　　　　　＼ 　!ﾞ　　 (･ ）｀ ´( ･） ｉ/　　／
　　　　　　　　　　　 　 |　　　　 （__人_）　|
　　　　　　　　　　　　　＼　　　　｀ー'　／　＜トラスト・ミー
　　　　　　　　　　　 　 ／ノ⌒)　　､､､､ヽ
＿＿＿＿＿＿　　∈　彡彡　　　　　　 }　　＿＿＿＿＿＿＿＿
　　　　　　　　　　　　~`ー┬―┬――"
　　　　　　　　　　　　　　　```　```
　　　　　　殺伐としたスレにポッポちゃんが現れ2get！！
0445デフォルトの名無しさん2010/03/23(火) 01:31:14
日本発はどうでもいいけど、>>422を備えた低級言語は使ってみたいな。
0446デフォルトの名無しさん2010/03/23(火) 01:57:03
>>443
作っても意味の無い物を作ろうとする気概なら無くていい
04473352010/03/23(火) 02:01:18
「低水準を生で触る」に関してですが、その為の言語機能を標準として組み込むべきか、拡張仕様とするかについて意見ないですか？
例えばポインタ型変数は標準として提供すべきでしょうか？
0448デフォルトの名無しさん2010/03/23(火) 02:04:42
提供すべき
04493352010/03/23(火) 02:05:42
具体的に根拠を是非
0450デフォルトの名無しさん2010/03/23(火) 02:15:31
根拠：Cにポインタがあるから
0451デフォルトの名無しさん2010/03/23(火) 02:22:39
>>447
「低水準を生で触る」ときパフォーマンスも要求されることが多いだろうから、
拡張仕様とすることによるオーバヘッド（実行時間が増える、記述の複雑になるなど）がない（or許容出来る程度に小さい）なら、拡張仕様でいいと思う。
そうでないなら、標準として提供すべきだろうね。
04523352010/03/23(火) 02:23:28
普段からポインタ演算や整数値からのキャスト、アドレス取得等を出来るようにしておくのか、
拡張機能として提供して普段は制限するのかという話です。
0453デフォルトの名無しさん2010/03/23(火) 02:25:58
Cがどうであるかは、どうでもいいと思う。
04543352010/03/23(火) 02:26:02
>>451
拡張にする場合、普段は禁止しておいてコンパイルオプションかなんかで部分的に許可するという形になるかと思います。
0455デフォルトの名無しさん2010/03/23(火) 02:29:25
>>454
コンパイルオプションでON/OFFするのは美しくないので、制限するにしてもソース中で解除出来た方がいいんじゃないかなー。
コンパイラがワーニング出すのはアリだと思うけど。
0456デフォルトの名無しさん2010/03/23(火) 02:31:32
「低水準を生で触る」機能は拡張機能で、拡張機能を使う宣言はソース中で行う、というのに1票
0457デフォルトの名無しさん2010/03/23(火) 02:33:55
隠蔽しすぎて敷居が高くなるのが懸念されるけど、、
0458デフォルトの名無しさん2010/03/23(火) 02:57:17
C/C++でいいような気がする
0459デフォルトの名無しさん2010/03/23(火) 03:58:15
Javaから入ってPython ,Ruby ,R,C# ときたけど
C/C++は本当に必要に迫られるまで触りたくない
0460デフォルトの名無しさん2010/03/23(火) 04:05:37
もし本気で誰かが言語を作ったとして、
文法覚えて使おうと本気で思ってる人居るの？
どう考えても集団オナヌーだと思うけどな。

Ｃ言語のココが気に入らねーって話なら解る。
あと俺様の希望は、低機能で良いから数KByteのRAMでも動く
マイコン用のＣ言語インタプリタ。SilentC最高。
0461デフォルトの名無しさん2010/03/23(火) 06:38:05
C、C++、C#のすべてを覚えれば代わりの言語なんて作る必要はない
0462デフォルトの名無しさん2010/03/23(火) 10:37:43
>>460
普通の言語は類似品が乱立し競争にさらされ努力しています。
しかしC言語には競争相手がいません。C言語は努力が足りません。C言語は甘え。
なのでC言語が気に入らねーです。
0463デフォルトの名無しさん2010/03/23(火) 10:51:18
Cycloneでいいんじゃね。
ttp://en.wikipedia.org/wiki/Cyclone_(programming_language)
0464デフォルトの名無しさん2010/03/23(火) 11:48:50
oocなんて言語もあるがな。
ttp://ooc-lang.org/
0465デフォルトの名無しさん2010/03/23(火) 11:59:04
C言語を拡張した言語ならいくらでもあるし、
CプリプロセッサもC言語へのトランスレータの一種
0466デフォルトの名無しさん2010/03/23(火) 13:06:12
Cではいけない根拠が薄弱過ぎ
最強を批判したところで最強にはなれんのだぞ
計画倒れどころか計画すらフワフワしてて論外だし
どうしてもと言うのなら、とりあえずその理想の言語っつーやつを開発して持ってこいよ
0467デフォルトの名無しさん2010/03/23(火) 13:27:42
まぐれで最強になったっぽい所が気に入らねーんだろうな。
偶然ではいけない、必然でないといけない、っていうのは宗教に近いが、
本人達は宗教だとは思っていないだろう。
0468デフォルトの名無しさん2010/03/23(火) 13:43:04
お前らは何マジになってんのと言われるまで自覚できないのか？
0469デフォルトの名無しさん2010/03/23(火) 13:51:41
俺らは常時本気なんだよ。
0470デフォルトの名無しさん2010/03/23(火) 15:11:09
”作ったとしたら”とか”作ったとしても”とか、んな事はどうでもいいんだよ。
3億当たったらどうするみたいな話してる時に、
まず当ててみろとか、詳細な使途を書けとか、
コミュ障害でもなけりゃそんな水差さないだろ普通。
0471デフォルトの名無しさん2010/03/23(火) 15:13:31
>>470
そんな途方もないことなわけ？ｗ
やっぱC/C++はすげーな
0472デフォルトの名無しさん2010/03/23(火) 15:24:07
回り見てもコミュ障害しかいませんｗｗｗ
0473デフォルトの名無しさん2010/03/23(火) 15:36:51
このスレの、どこが有意義なのかコミュ障害の人に教えてやれよ
0474デフォルトの名無しさん2010/03/23(火) 16:19:39
有意義じゃなければならないって言う前提が既に自己中心的だね
0475デフォルトの名無しさん2010/03/23(火) 16:21:11
つまりこのスレは無駄以外の何物でもないってことだな
0476デフォルトの名無しさん2010/03/23(火) 16:22:15
いまさら確認するまで気づかなかったのかよ
0477デフォルトの名無しさん2010/03/23(火) 16:26:06
みんな気付いてるよ。Cに代わる言語なんてないってね
馬鹿がC批判して偉そうにしてるだけ
逆にいえば、Cを批判して優越感に浸ると言う意味では、有意義かもしれないねｗ
0478デフォルトの名無しさん2010/03/23(火) 16:31:43
どうしてそう有意義さを見出そうと努力するのかな〜？
無駄な物、無駄な時間、無駄話があってもいいと思うのだけどｗ

神経質にやってるとハゲるよ
0479デフォルトの名無しさん2010/03/23(火) 16:34:00
合理性のないコードは汚いです。
無意味なものは存在してはならない。
0480デフォルトの名無しさん2010/03/23(火) 16:34:20
じゃあ>>470は何に水を差されたくなかったわけ
無駄ならいいじゃん。煽りだって無駄だろ？
0481デフォルトの名無しさん2010/03/23(火) 16:39:25
その考え方がコミュ障害なんだけど自覚できないでしょ？
言っても分からないだろうからとっとと黙っとけよｗ
0482デフォルトの名無しさん2010/03/23(火) 16:41:12
コミュ障害と言って話を終わらせる方がよっぽどコミュ障害だろｗｗｗ
「無駄な話してんのにツッコミいれんな！」ってかｗ
糞スレを正論で荒らされて発狂とかレベル低すぎ
0483デフォルトの名無しさん2010/03/23(火) 16:51:52
で、最新のオサレな言語仕様で、マイコンのレジスタアクセスするとか泥臭いことできるの？
0484デフォルトの名無しさん2010/03/23(火) 16:55:11
最新のオサレな言語が作られた理由が、そういう需要を満たすためならあるいは
0485デフォルトの名無しさん2010/03/23(火) 17:49:11
こんなに伸びてるのに何も進まないスレ

x86マクロアセンブラに、まるで新言語みたいな物量のマクロを定義すれば完成

で、以降はマクロアセンブラ製品の選定と、実際のマクロ内容の案出し

あと、その実際にマクロで記述した際に何か気づきがあればそれを列挙して、
そこから言語案出発でどうよ
0486デフォルトの名無しさん2010/03/23(火) 18:01:43
いいこと考えた
.NETのバイトコードのコンパイラを作るんだ
0487デフォルトの名無しさん2010/03/23(火) 18:07:47
>>486
C++/CLIは、それなりに要望を満たしてるよ。
汚いといわれるC++の拡張であることと、MS製なんでアンチがわくという問題があるけどな。
0488デフォルトの名無しさん2010/03/23(火) 18:16:16
>>486 関数呼び出しが大量に並ぶだけですね

>>485
マクロ名：STACKMAN
アドレス位置と長さを記録してるテーブルがあって、
主に関数呼び出し時のポインタPUSH/POPと引数の受け渡し、やローカル一時領域の確保に使う
またその際の記録(いわゆるポインタのポインタみたいな簡単な管理)をする


マクロ名：MEMORYMAN
仮想領域の確保を行うもっとも基本のマクロ。STACKMANもこれを使っている
アドレスのポインタ(レジスタに直入れする値)とサイズを持っていて、再確保の管理をする定型処理

マクロ名：PROCMAN
なんらかの引数と戻り値のポインタをレジスタに渡す為のポインタを管理する
ルーチンの呼び出し、プロシージャコールの原初的な実装


一番簡単な基礎がまずこれで‥ あとI/O関係はDOS/V関係の約束や仕様調べないとわかんね
0489デフォルトの名無しさん2010/03/23(火) 18:18:20
>>459
機会があればSoftintegration(国内代理店はラクネシー)が開発した
CインタプリタとしてChというのがあるから触ってみたら？
無償版あり。

>>484
直接的なハードウェアアクセス用ライブラリがあるなら大抵の言語では可能。

>>485
マクロでは保守面倒そう...。初期段階ではC以外のスクリプト言語を使って
foobar -> Cトランスレータとして実装したほうがいいと思う。

あと俺も今やっているFLOSS翻訳終わっていたら、
仕様調停役担当してもいいんですが事情と物量が邪魔して中断不可能な仕様。
0490デフォルトの名無しさん2010/03/23(火) 23:35:18
デバドラ屋だって、オサレ言語使いたい！
0491デフォルトの名無しさん2010/03/24(水) 00:08:20
じゃD言語使えば？
0492デフォルトの名無しさん2010/03/24(水) 00:15:52
D厨ウゼー
0493デフォルトの名無しさん2010/03/24(水) 00:17:15
Dはオサレじゃないし
0494デフォルトの名無しさん2010/03/24(水) 00:46:20
>>439
その結果できたのが、ItaniumやらCrusoeやら。そいつらがどうなったかは、ご存知の通り。
0495デフォルトの名無しさん2010/03/24(水) 01:06:04
ポインタ型自体やポインタ関連の関数類は別モジュールに置く程度のことはしてもいいだろうけど、
構文中のキーワードで文法自体を制御するってのはいささか気持ち悪さを感じるなぁ。
それにC/C++でも、ポインタは使わざるをえないから使ってるだけで、うっかり間違って使っちゃったってのはあんまりない気がする。

C++の参照のようにポインタを覆い隠す存在も用意していること、それを利用し大抵の操作はポインタなしで行えることは必要。
(Cのように、ポインタどうでもいいのにポインタを使わざるをえない場面というのは避けたい。もう、ポインタ使うのはポインタ用モジュールにまとめちゃっていいかも)

ポインタをどう隠そうと、その背後にメモリとメモリアドレスがあることは避けようがないことだし、
LLとかだとポインタを覆い隠して「同値性と同一性」とか「変更可能な型と変更不能な型」とかいろいろ頑張ってるけど
Cやってる人から見たら、ようはポインタなんだけど言語からポインタを消すために無理してるようにしか見えない。
高級言語ではそれでもポインタを覆い隠すことに意味があるんだけど、低級言語ではそんなことする意味はない。
0496デフォルトの名無しさん2010/03/24(水) 01:17:42
アドレスの抽象化ってポインタ変数が最良なのかな。

他のやり方はないのかな。
0497デフォルトの名無しさん2010/03/24(水) 02:17:52
物に名前をつける以上の抽象化は人間には無理だろｗ
0498デフォルトの名無しさん2010/03/24(水) 02:43:07
そもそもケースによってはメモリマップドIOだろうが、外部IOだろうが絶対アドレスをアクセスできるからこその
低級言語ではないのか？そこは「何らかの言語によるライブラリ」に任せるってのなら主題自体があまり意味が無い気が…
0499デフォルトの名無しさん2010/03/24(水) 04:59:21
>>498
意味ないに決まってんだろ。
このスレ見て他にどう思えるんだよ。
なんか語り口が乱暴でスマンけど。
0500デフォルトの名無しさん2010/03/24(水) 05:05:08
このスレは現実逃避のためだけにある
0501デフォルトの名無しさん2010/03/24(水) 05:18:16
だれも言わないからいっとく
DMR, Ken Thompson, Brian Kernighanらは神
おまいらヒゲが足らねえんだよ
0502デフォルトの名無しさん2010/03/24(水) 07:40:52
>>498
絶対アドレスへのアクセスをポインターよりももっと良いやり方があれば採用したい、ということだろう。
0503デフォルトの名無しさん2010/03/24(水) 10:06:43
ハードウェアが現在のアドレスモデルを採用している以上、これがどうにかならないと無理だな
LISPマシン再来？
0504デフォルトの名無しさん2010/03/24(水) 12:53:24
>>501
ICI言語の隠しページである

> Hey Kids! "Use ICI. It's good for your hair."
(やあボウヤ! ICIを使おう。こいつは髪(ヒゲ？)にいい(育毛剤ではなくカッコヨクなる)ぜ")
ttp://atrn.org/

かよ。
0505デフォルトの名無しさん2010/03/24(水) 16:08:58
Cの最大の利点＆欠点は自由に動き回れるポインタに尽きる
ポインタ演算排したgoのアプローチは面白いんだがGCがネックだな
0506デフォルトの名無しさん2010/03/24(水) 18:03:52
アドレス叩く能力が要らないならOCamlとかScalaとか既に優れた言語がある
0507デフォルトの名無しさん2010/03/24(水) 18:25:14
新言語なんて八方塞だろ。凡人が考えることなんて既に余裕で実行されてるわな
0508デフォルトの名無しさん2010/03/24(水) 19:14:18
トレンド（笑）な方面は特にな
0509デフォルトの名無しさん2010/03/24(水) 19:38:03
>>505
ポインタの扱いを厳格化したものとして既にCycloneがあり、
C -> Cyclone移植ガイドも用意されている。無いのは日本語マニュアルだけか。やってるけど。

またCトランスレータの実装を持つEuphoriaにはポインタは無いが
低レベルメモリーアクセス向けの組み込み関数で用意されている。
これにより共有ライブラリおよび低レベル操作を可能としており。
(少なくともライブラリのユーザーレベルでは)ポインタを意識する必要は無い
さらに関数ポインタと似た機能はルーチンIDとして実装されている。

新言語とか言う前に既存のしかもマイナー言語に勝てない仕様では
どうなんだか。
0510デフォルトの名無しさん2010/03/24(水) 19:41:20
じゃあそれらのマイナー言語を広めるだけで目的達成じゃね？
0511デフォルトの名無しさん2010/03/24(水) 19:58:22
ライブラリによるポインタ操作でもいいというなら、ほとんどすべての言語でポインタを扱うことができる。
0512デフォルトの名無しさん2010/03/24(水) 20:30:49
結局、低レベルに触りたい奴なら、Cをちょっと頑張って使いこなした方がいい
個人的にはアセンブラよりむしろCの方が理解しにくかったが、どっちにしろそう難しくはない

低レベルに触れなくてもいいなら、何度も言われてるが、いくらでも高速で便利な言語はある
0513デフォルトの名無しさん2010/03/24(水) 21:04:19
>509
解説のアクセス先ぐらい置いといてクレ。
ttp://c2.com/cgi/wiki?CycloneLanguage
ttp://www.rapideuphoria.com/hotnew.htm

あと、>422の機能を持つ低レベル言語って存在するのかね？
0514デフォルトの名無しさん2010/03/24(水) 21:15:41
　
　そしてこのスレは意外な　─　ある意味順当な　─　幕切れ迎えるのであった


　　　　　　　　　　　　　　　　　　　　　　　　完
　
　
　
　
　
0515デフォルトの名無しさん2010/03/24(水) 22:45:43
C
0516デフォルトの名無しさん2010/03/24(水) 22:52:36
C最強を確認するためだけのスレであった
0517デフォルトの名無しさん2010/03/25(木) 00:36:47
>>422の機能が実現できたらいいなー
0518デフォルトの名無しさん2010/03/25(木) 01:07:53
言語仕様どうこうより、優れたライブラリ、開発環境の方が100倍重要で、
>>1はその辺を致命的に勘違いしてる。
「低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ」
そんなもの開発効率と関係ないし、使う動機にならない。
GoやOCamlのような良さげな言語がいっこうに流行らないのもそんな理由でしょ。
0519デフォルトの名無しさん2010/03/25(木) 01:18:42
だって C/C++ がさっぱりわからないし怖いから
GC言語しか触ったことない自分にも簡単に理解出来て、
それでいて使ってて胸が張れるような、別の言語を新たに作ればいいって、
甘えんぼで怠惰な中学生みたいに話摩り替えただけのスレだもの
0520デフォルトの名無しさん2010/03/25(木) 01:35:23
Cのどこが怖いんだ
携帯の料金体系みたいな歪んだサービス精神で開発された言語のほうが怖いだろ
0521デフォルトの名無しさん2010/03/25(木) 01:47:10
まあ特定のOSに特化したものはだいたいそうだな
0522デフォルトの名無しさん2010/03/25(木) 02:34:49
Dでいいじゃない
0523デフォルトの名無しさん2010/03/25(木) 02:42:14
つうか、ＩＯ制御が書けるくらいの奴ならポインタの概念自体難しいとか思わないだろうし、
わかってない奴が無理難題言ってるだけにしか聞こえない。
たぶん彼らの理想がかなっても、その言語を使ってまともなものが作れるとは思えないｗ
0524デフォルトの名無しさん2010/03/25(木) 04:58:52
Dを知らないやつが、C++のアンチテーゼをほしがったんだろ
0525デフォルトの名無しさん2010/03/25(木) 05:32:34
Dはダメだろ
あと20年は完成しない
0526デフォルトの名無しさん2010/03/25(木) 05:33:47
そもそもDの仕様がさっさと安定すればこんなことには・・・
0527デフォルトの名無しさん2010/03/25(木) 06:42:31
Eを新規開発して半年で完成されて、C、Dのシェアを
奪い取る勢いにする。
0528デフォルトの名無しさん2010/03/25(木) 07:31:53
英語は不規則変化が多いからシンプルな言語を作りましょう、
つって今さら言っても誰もついてきてくれないのと一緒。
一番有名なエスペラントでさえ愛好者レベルでしか普及してないだろ。

プログラムの世界でも、
言語の一貫性なんかよりも、今ある資源や人口の方が重要。
言語は宗教でも学問でもないからな。

以前の言語でできないことができるようになった、ならともかく、
少しやりかたを変えてスマートにできるようになりました、ぐらいじゃ誰も移行しない。
0529デフォルトの名無しさん2010/03/25(木) 14:47:18
もうあるんだろうと思うけど、
状態遷移図をストレートかつ簡潔にコード
に落とし込めるような言語は欲しいな

あと真逆になるけどルールベースのアクションをストレートかつ以下略
0530デフォルトの名無しさん2010/03/25(木) 15:05:08
>>518
優れたライブラリを効率良く書くためには言語仕様も大事なわけで
0531デフォルトの名無しさん2010/03/25(木) 15:51:07
前の方読んでないけどDはGCがあるからダメなんじゃないの？
0532デフォルトの名無しさん2010/03/25(木) 16:13:31
>>509
Ken Thompson/Googleが作ったってのがポイントなんじゃw
どんなに優れていても話題にもならんのはダメ
自然言語と一緒だよ
goはnaclがらみで増えるかもしれん
0533デフォルトの名無しさん2010/03/25(木) 17:27:05
>>531
GC使わなければいいじゃん
0534デフォルトの名無しさん2010/03/25(木) 17:42:02
GC切れたんだｗ
詳しくないから知らなかったｗ
てかGC切ってまともに動くの？
0535デフォルトの名無しさん2010/03/25(木) 17:51:16
Objective-Cの作者がC++が流行ったのは
AT&Tだからだいってたな
0536デフォルトの名無しさん2010/03/25(木) 18:10:03
C++ はかなり早い時期に Microsoft と Apple が公式開発環境で採用したよね
Apple のなんて AT&T 謹製 cfront だった。
0537デフォルトの名無しさん2010/03/25(木) 18:23:48
>>529
そういうのはDSLとして実装したらいい
機械的にやりたいなら言語じゃないけど
yacc/bisonなんかでオートマトンでどうよ
0538デフォルトの名無しさん2010/03/25(木) 19:10:14
Objective-Cはあのキモい文法をまずなんとかしろと言いたい
0539デフォルトの名無しさん2010/03/25(木) 21:05:09
ぶっちゃけObjective-Cは重いのが敗因だろ。
重いと負けることが分かってるから、C++は何が何でもゼロオーバーヘッドを守ろう
とし続けてる訳だし。まぁ最近は例外機構のオーバーヘッドは避けられなくなりつつ
あるが。RTTIは今でも基本オフでおｋの世界だけど。

マシンパワーが余りつつあるから重さは気にしなくてもいい、ってのはあくまでもPC
の事務用途の話で、鯖だのゲームだの携帯だの、今でも必死な方面は多い。そういう
ところでは実行速度が出るかが足切り基準。開発速度の選り好みはその後の話。
0540デフォルトの名無しさん2010/03/25(木) 21:09:26
Objective-Cが重い？
0541デフォルトの名無しさん2010/03/25(木) 21:32:07
動的だからな
0542デフォルトの名無しさん2010/03/25(木) 21:57:30
糞言語と知れ渡ってるPHPが勝ち組なのも軽いからだな
軽さは要らないから圧倒的に手軽にしてくれ、という需要はLLが満たしてる

だから、軽い言語を求めるという点では>>1は間違っていない
その他が間違いだらけなだけで
0543デフォルトの名無しさん2010/03/25(木) 21:58:24
>>542補足
s/その他が/その他の点が/
0544デフォルトの名無しさん2010/03/25(木) 22:18:53
PHPのどこが軽い。
0545デフォルトの名無しさん2010/03/25(木) 22:20:30
>>539
ぶっちゃけC++は糞フレームワークと使う奴らがヘボ

Cはランタイム云々って話があったが
リセットベクタからアセンブラ数行程度で動き始める言語は他にはない
0546デフォルトの名無しさん2010/03/25(木) 22:26:04
どういう理由でCが使われているかということと、それに矛盾のないものしか機能として追加できないということは理解しておかないと。
0547デフォルトの名無しさん2010/03/25(木) 22:30:57
>>422 の Lisp みたいなマクロって、要は言語を構成する要素をデータとして
扱えればいいんだよね。そいで、それをコンパイル時に評価できて、プログラ
ムとして生成すると。
そう考えると、仮に S 式を捨てたとしてもそこまで夢の機能ってわけでもない
気がするんだけど、どうだろ。S 式じゃないとなるとお手軽さは失われそうだ
けども。
0548デフォルトの名無しさん2010/03/25(木) 22:36:56
Webサーバのグルー言語としちゃ断然軽いが、Apacheモジュールに比べたら非常に重い
0549デフォルトの名無しさん2010/03/25(木) 22:55:15
>547
・引数を評価しないでそのまま関数内に展開
・関数の中ではあくまで一つの要素として扱われる
という扱いができればS式に拘らなくてもOKじゃね？

遅延評価でけっこうカバーできるだろうけど、上手く作りこめば効率などで有利になれるんじゃない？
例えば引数（適用前の関数）の中身をコンパイラが理解して最適化するとか。
0550デフォルトの名無しさん2010/03/26(金) 00:53:49
>>545
CPUにもよるがうまく組めばRAMがまだ使えない状況でも動作するしなｗ
0551デフォルトの名無しさん2010/03/26(金) 06:50:14
俺は結局、Mcrosoftの意向だと思うな。

Ｃ言語に「//」で始まるコメントを許しちまうとか、
char　str[10][10]={”123”,”abc”,0}こんな初期化もMicrosoft拡張だったか…
unsigned shortをWORDとか、defineで凌げると思ってたらLONGLONGがfloatと別物だったり。

VisualBasicなんか完全オリジナルな訳だが、ソレしか知らんオッサンには
自分がなんで他言語のプログラマに蔑まされるか理解不能だわな。
Mcrosoftが高効率のバイナリーを吐くVisualBasic作ったらソレが標準になりかねん。
0552デフォルトの名無しさん2010/03/26(金) 06:54:57
いやそれはない
0553デフォルトの名無しさん2010/03/26(金) 07:00:05
VB>>>>>>>>>>>>>>>>>>>>D>>>超えられない壁>>>>>>>>>>>>>>>>>>>>その他のマイナー言語
が現実
0554デフォルトの名無しさん2010/03/26(金) 07:04:42
バカじゃね。COBOLだよCOBOL。
0555デフォルトの名無しさん2010/03/26(金) 07:07:20
C++使ってようがC#だろうがVBだろうがなんでもいいけど
MSの世界しかしらねえ奴の方が
よほど蔑まされてることに気づけよ
0556デフォルトの名無しさん2010/03/26(金) 07:08:47
COBOL>>>>>VB>>>>>>>>>>>>>>>>>>>無収入の壁>>>>>>>>>>>>>>>>>>>>D他マイナー言語
0557デフォルトの名無しさん2010/03/26(金) 07:24:13
>>551
無知まるだし
Cの独自拡張ならGCC
0558デフォルトの名無しさん2010/03/26(金) 07:26:33
LONGLONGがfloatってなに
0559デフォルトの名無しさん2010/03/26(金) 12:50:59
時折、無知や知ったかが現れるのも中二スレの特徴なり
0560デフォルトの名無しさん2010/03/26(金) 17:27:35
>>551
//はBCPL時代の仕様を勝手にサポートするコンパイラが多かっただけ
初期化の発祥は知らん
WORDやLONGLONGは言語標準じゃなくただのWindows標準ヘッダのマクロじゃね

とりあえずお前がMS以外の世界を全く知らないことはよく分かる
0561デフォルトの名無しさん2010/03/26(金) 20:55:44
いつの時代だよｗｗｗ

LONGLONGAGO
0562デフォルトの名無しさん2010/03/27(土) 13:17:13
GC無しのLispでいいんじゃね。
超高速だぞ。
0563デフォルトの名無しさん2010/03/27(土) 14:33:31
こんなのどうだ。
C並に低レベルな関数型言語。
http://www.bitc-lang.org/docs/bitc/spec.html
0564デフォルトの名無しさん2010/03/27(土) 14:34:13
BitC is a new systems programming language. It seeks to combine the flexibility, safety, and richness of Standard ML or Haskell with the low-level expressiveness of C.
0565デフォルトの名無しさん2010/03/27(土) 19:23:07
>>560
それでも>>551の言うようにMSの意向が大きいよ。C#の次はF#がくるかもよ。
0566デフォルトの名無しさん2010/03/27(土) 20:14:48
F#が来るにしても10年後の話だ
どうでもいい
0567デフォルトの名無しさん2010/03/27(土) 23:24:53
>>1はどこいったんだろう
0568デフォルトの名無しさん2010/03/27(土) 23:31:58
Cが最強だと納得して巣に帰りました
0569デフォルトの名無しさん2010/03/27(土) 23:34:37
OCamlは、プロトタイプにはすでによくつかわれているから、すぐ来るんじゃないかと。
0570デフォルトの名無しさん2010/03/27(土) 23:47:10
とりあえず、関数ベースのシステムコール設計はやめてgotoベースのシステムコールに設計し直して欲しい。
0571デフォルトの名無しさん2010/03/28(日) 00:14:50
なんで
0572デフォルトの名無しさん2010/03/28(日) 00:32:18
関数呼び出しは遅いから。
0573デフォルトの名無しさん2010/03/28(日) 00:33:44
push popすんなよ遅いんだよ。ジャンプ命令でシステムコールする新しいOS作れ
0574デフォルトの名無しさん2010/03/28(日) 00:46:14
昔のメインフレーム
0575デフォルトの名無しさん2010/03/28(日) 00:57:28
今のUnixやWindowsなどのOSはC言語で扱うために設計されているから
システムコールが関数呼び出しなのはしょうがないんだよね。
別にC言語にこだわらないならジャンプ命令でいいんだよ。
0576デフォルトの名無しさん2010/03/28(日) 01:16:34
最低でもリターンアドレスは詰む必要あるだろ
その際popは必要ないが
espをpush/popするかはコンパイラ次第
普通は必要なければpush/popしない
0577デフォルトの名無しさん2010/03/28(日) 01:30:10
>>563
チラ見しかしてないが、かなり良い感じがする。
0578デフォルトの名無しさん2010/03/28(日) 01:32:32
関数型でポインタとか泥臭いな
だがそこがいい
0579デフォルトの名無しさん2010/03/28(日) 02:12:24
おまえら頭悪いな
全部mainでやりゃいんだよ
0580デフォルトの名無しさん2010/03/28(日) 02:13:30
システムコールはtrapだろ
0581デフォルトの名無しさん2010/03/28(日) 02:16:00
連投してみる
>>576
risc cpuはコールするときレジスタに戻りアドレスを入れる
0582デフォルトの名無しさん2010/03/28(日) 02:59:18
>>454-455
C#のunsafe方式が頭をよぎった。
0583デフォルトの名無しさん2010/03/28(日) 03:09:57
つーか386のコールゲートも変な仕組みだった気がするが忘れた
0584デフォルトの名無しさん2010/03/28(日) 03:10:54
つまりCが最強C#が至高と言う事で宜しいか
0585デフォルトの名無しさん2010/03/28(日) 10:18:59
C++/CLIは、Cの範囲からC#の範囲までカバーしている。
0586デフォルトの名無しさん2010/03/28(日) 10:30:07
それはソース上の話じゃないか。実質C++/CLIは、どちらかと言えばほぼC#
0587デフォルトの名無しさん2010/03/28(日) 15:49:19
それのほぼC++版がD言語
0588デフォルトの名無しさん2010/03/28(日) 15:52:10
だから、デジタルマーズのD言語は流行らないんだって・・・いまどき
0589デフォルトの名無しさん2010/03/28(日) 15:54:25
C++をわずかに変化させただけの言語を今更利用しようと思う理由がない。
よほどの理由がない限り、多少の改善程度ではユーザーは移動しないんだよ。
0590デフォルトの名無しさん2010/03/28(日) 16:37:03
ありゃわずかじゃないだろ
膨大に変化してる
0591デフォルトの名無しさん2010/03/28(日) 16:47:49
C++のコードを何％縮められる？
0592デフォルトの名無しさん2010/03/28(日) 17:07:16
縮むとか縮まないとかそういう問題じゃないだろ
0593デフォルトの名無しさん2010/03/28(日) 17:16:52
>>592
そういう問題だと思うんだけど。
俺に言わせてみれば、セミナー屋が
「この機能で大幅にバグを減らせます」
と言っていることの９９．９％がウソか大げさ。
バグが潜む原因のほとんどは設計とアルゴリズムにあると思うね。
C++→D程度なら設計を変えるほどの大幅な仕様変更ではないし、
そもそもアルゴリズムは言語とは無関係。
0594デフォルトの名無しさん2010/03/28(日) 17:20:47
>>593
アルゴリズムのバグ。コード化で入り込むバグ。バグが発生しやすいような設計。
がきりわけられていないんじゃないか。
バグは言語と関係ないとう部分は多いが、脆弱性は大いに関係ある。
0595デフォルトの名無しさん2010/03/28(日) 17:21:16
バグを減らせるとか関係ない
便利な機能が色々増えてるけど
それが「コードが縮む」と言う事に繋がるとは限らないということ
例えばC89ではマクロを使っていたのをC++ではinlineに変更したとして、
これは便利にはなっているけどコードはむしろ長くなるでしょ
0596デフォルトの名無しさん2010/03/28(日) 17:24:33
言語的に原理的に発生しなくなるバグとかもあるしね
GC言語でのメモリリークとか
VBだとなぜか参照されていると見なされて似た現象が発生することもあるが・・・
0597デフォルトの名無しさん2010/03/28(日) 17:27:34
>>595
> C89ではマクロを使っていたのをC++ではinline
コード量は長くも短くもならないと思うよ。
0598デフォルトの名無しさん2010/03/28(日) 17:28:58
>>596
旧VBは、GCじゃないよ。
0599デフォルトの名無しさん2010/03/28(日) 17:30:33
CからC++に利用者が移動した理由は、
上位互換性とオブジェクト指向の導入でしょ。
inlineが決定的な理由じゃないよ。
0600デフォルトの名無しさん2010/03/28(日) 17:35:03
>>597
>コード量は長くも短くもならないと思うよ。
戻り値や引数に型つけたり { } つけたりするでしょ
inlineにする程度の長さなら、マクロ引数に ( ) をつける影響より大きくなる
0601デフォルトの名無しさん2010/03/28(日) 17:35:46
場合によってはreturnもだな
0602デフォルトの名無しさん2010/03/28(日) 17:39:04
>>600
それは、誤差範囲といっていいだろ。
0603デフォルトの名無しさん2010/03/28(日) 17:40:10
500行が1000行になるわけではなし、そんな些細なことを大ごとに語るなよ。
0604デフォルトの名無しさん2010/03/28(日) 17:44:30
C++からDに移行する最も大きい理由はなんですか？
0605デフォルトの名無しさん2010/03/28(日) 17:55:23
C++で書かれたコードを同じアルゴリズムでHaskellのコードを記述したらコード量が10分の1になった、
という事例ならあるんだけどね。
それぐらいのメリットがないと誰も移行を考えたりはしない。
0606デフォルトの名無しさん2010/03/28(日) 17:56:33
Haskellは難しいから普通のプログラマー向きじゃない
0607デフォルトの名無しさん2010/03/28(日) 18:05:04
１行が多分３〜４行になるけどね
0608デフォルトの名無しさん2010/03/28(日) 18:07:31
BoostのspiritとかMPLとか、言語内言語みたいなのがあるじゃない。
ああいうのをもっと綺麗な形でサポートしてほしいな。
0609デフォルトの名無しさん2010/03/28(日) 20:03:10
>>605
クイックソートのことなら、Haskellのは配列の要素入れ替えじゃなくて新しい配列を作って連結してるだけだろ。
それってSTLコンテナとか使ったらC++でも同じ方法ではできるようにならないの？
Haskellほど短くは書けないだろうけど、もっと少なくはなると思う。
0610デフォルトの名無しさん2010/03/28(日) 20:11:39
>>609
haskellのクイックソートって、デモンストレーションで、
実用じゃ使えないしな。
0611デフォルトの名無しさん2010/03/28(日) 20:25:18
そういえば、全く言語ごとの最適化とか考えずにベンチ書いて「Java最速でしたよ」
とかアホなこと書いた外人が理詰めでフルボッコされてたな
0612デフォルトの名無しさん2010/03/28(日) 22:06:01
「Java最強でしたよ」なら真理なのにな
0613デフォルトの名無しさん2010/03/28(日) 22:35:44
速度の話は、コードの良し悪し、向き不向きまで考えると、本当に難しい。大体の基準はあっても、個々にはケースバイケースとしか言いようがない。
ただ、言えることは

・高級言語では、アセンブラでの最速コードよりも速いコードは書けない(よくて同等。多くの場合はより落ちる)
・Cはアセンブラとほぼ同等な高級言語と言える
・C++はCとの互換性より、原理上はCと同等かもしくはより速いコードが書けるが「C++らしい」書き方をするにはCより遅くなる覚悟が必要
・JavaのようなVMを利用する言語、インタプリタ型言語のような非ネイティブな言語で、VMやインタプリタがネイティブな言語で書かれている場合
　　そのネイティブな言語で書き直せば、非ネイティブな言語で書いた場合と同等かそれ以上の速度で動作するコードを書ける
・VMやインタプリタが、非ネイティブな言語で書かれていたとしても、それが実際に動作する処理系である以上は元を辿ればネイティブな言語にたどり着く。
　　よって、やはり同等以上の速度でコードが書けるネイティブな言語は存在する

・ただし、最速のコードが「存在する」とは、書くことの大変さ、書ける人間が存在するかを一切無視しての話である
・例えば、下手にアセンブラ使うよりもCで書いてコンパイラの最適化に任せた方が結果的に速いコードができることが多い
・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる
・けど、LLよりも遅いCコード書いちゃう人はさすがにちょっと残念
0614デフォルトの名無しさん2010/03/28(日) 22:44:47
アセンブラでの最速コードは理論的最高値だから
同等だったら最高で文句の付けようが無い状態じゃん　＞よくて同等
0615デフォルトの名無しさん2010/03/28(日) 22:50:47
つうかx86コードをマイクロコードに変換して実行するとか、投機実行をする現在のプロセッサにおいて、
アセンブラで書けば速いなんて脳が20年前で止まってるとは言えるが、Javaで書いてもCより速くなる
なんてのは絶対無い。同じ仕様を同じロジックで書けばね。静的であるか動的であるかはそれくらい違う。
0616デフォルトの名無しさん2010/03/28(日) 22:54:35
Javaよりも遅いCコード書いちゃう人はさすがにちょっと残念ってことで
0617デフォルトの名無しさん2010/03/28(日) 23:11:06
>>613
>・JavaのようなVMを利用する言語、… VMやインタプリタがネイティブな言語で
> 書かれている場合

そもそもVMやインタプリタがネイディブで無い言語で書かれてることってあるのか。
(実用的な処理系で)

0618デフォルトの名無しさん2010/03/28(日) 23:14:11
「javaのVMがネイティブな言語で書かれてるから」って理由で
javaもネイティブな言語並みにスピード出せるっておかしいだろ。
0619デフォルトの名無しさん2010/03/28(日) 23:48:32
なんか話がスレタイから全速力で遠ざかってないかｗ
0620デフォルトの名無しさん2010/03/28(日) 23:53:57
必要ないってとこに収束しつつあるだけだよｗ
0621デフォルトの名無しさん2010/03/29(月) 00:09:24
言語の純粋な仕様・性能よりも、どこが作ったかが運命の分かれ道
0622デフォルトの名無しさん2010/03/29(月) 00:16:40
>>1 が自分でつくるつもりもなくてスレを立てたんなら、
最初から雑談スレになる運命。
0623デフォルトの名無しさん2010/03/29(月) 00:16:57
>>613
このての議論って
＞・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる
仮定を前提としてるけど、ひとつでも実例を示したことがあるのかって思うぞ。
0624デフォルトの名無しさん2010/03/29(月) 00:45:31
>>623
そもそも、あるPGがループソートをCで書き、他の言語では別のPGがクイックで書くとか、
そういう前提だから意味が無いｗ
0625デフォルトの名無しさん2010/03/29(月) 00:50:07
>>623
十数年前、Javaがではじめたころは、実行時にコードの実行状態を
見て動的に最適化できるから、Javaのほうが速くなる可能性があるって
話があったけど、いまだに「Javaで書いたwebサーバーのほうがapacheより
速いぜ」みたいな話って聞かないしな。
0626デフォルトの名無しさん2010/03/29(月) 00:55:16
JavaはGCで使ってるメモリが整理されて局所的になるからキャッシュがヒットし易くなる「可能性がある」とかいってたな。
そこにいたるまで膨大なＧＣのオーバーヘッドがあるわけだし。パフォーマンスは最悪値を保証しなければならないんで可能性なんて無意味だし。
0627デフォルトの名無しさん2010/03/29(月) 00:56:23
＞・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる

この言い様って、まるで 「１＋１は２とは限らない」 みたいな、小５病的な台詞
0628デフォルトの名無しさん2010/03/29(月) 01:14:52
>>627
そういう本読んだことがあるけど、水１リットルとアルコール１リットルを混ぜると２リットルより小さくなるって理屈だったな。
それは式の立て方が間違ってる。質量で計算しろと。
0629デフォルトの名無しさん2010/03/29(月) 01:35:34
アルコールがいつの間にか減ってたんじゃないの？それ
0630デフォルトの名無しさん2010/03/29(月) 01:46:19
たったの70グラムの砂糖を食べたらなぜか500グラム体重が増える不思議
0631デフォルトの名無しさん2010/03/29(月) 02:47:31
Cより書いた方が”実行時間が”速くなるというのは詭弁だろうが、生産性を考えるとOOP言語の方が良いし
汎用性を考えるとVMを利用する言語が良い。アルゴリズムにも言えるけど、速さが全てなのかって話
0632デフォルトの名無しさん2010/03/29(月) 03:20:33
vmはエコじゃねえな
0633デフォルトの名無しさん2010/03/29(月) 03:27:02
>>631
VM で動くブラウザやらIMEやらを使い
動画のコーデックも Java でokとか
そういう人以外がその発言するのは偽善

正直に、バカしか使えないような貧乏な
客が殆どなんだから LL にも価値あるだろ
と言え
0634デフォルトの名無しさん2010/03/29(月) 03:28:56
>>633
偽善じゃねーよ。環境に依存しないことがどれほどの意味を持ってるのか分かってんの？
0635デフォルトの名無しさん2010/03/29(月) 04:07:11
なんでもいいんだが、スレ違いだろって話。
OSやVMやGCやLLを書ける低レベルな言語について考えるスレなんだから。
0636デフォルトの名無しさん2010/03/29(月) 04:19:01
だからCより優れたものはあり得ないって結論が出ただろ。Cが最適
Cやアセンブラの弱点である汎用性はVMによって完成した。これだけの話なんだよ
0637デフォルトの名無しさん2010/03/29(月) 04:32:16
CとJavaを速度で比べる場合、Cでヒープを使うときはGCを使い、配列を使うときにはバウンドチェックしているコードでないと意味がない。
0638デフォルトの名無しさん2010/03/29(月) 05:31:00
Cとjavaを速度で比べるとか、正気かよ。それともただの初心者か。
比較にならないことは原理的にもすぐわかるし、Eclipseの殺人的な重さを見てみろよ。
0639デフォルトの名無しさん2010/03/29(月) 05:35:59
>>631
速さが全てだろ。
汎用性だ何だってのはゴミプログラマが自分の無能さを隠すための言い訳だよ。
Cで書いたって、コア部分は共通にして、機種依存部分のみ分けることで多機種開発は可能になる。
Cがよくわからないゴミプログラマには無理だがなｗ
0640デフォルトの名無しさん2010/03/29(月) 06:37:15
アルゴリズムは見た目の分かり易さが優先されることが往々にしてあるが。
悪意をもってしか文章を書けないなら他所でやればいいのに
正当性を欠いてるよ
0641デフォルトの名無しさん2010/03/29(月) 07:19:03
>>638
この人は、Eclipseと何を比べたのだろうか。
0642デフォルトの名無しさん2010/03/29(月) 07:23:48
NetBeansもJavaで書かれてるよね。Eclipseより速いとか聞いたんだがどうなんだろう
0643デフォルトの名無しさん2010/03/29(月) 07:33:37
新しい言語でなくていいだろ。
C#のコンパイラでネイティブコードを出力できるのを作れば。

0644デフォルトの名無しさん2010/03/29(月) 07:46:27
* Cでダメな理由は何か
* C++でダメな理由は何か
* Dでダメな理由は何か

これらの質問に多くの人が納得できる十分な答えがなければ、たぶん新しい言語はいらない
0645デフォルトの名無しさん2010/03/29(月) 07:55:10
>>643
CLIからネイティブへのコンバーターはあるからあるも同じ。
ILGeneratorクラスがあるので、VMを完全になくすことはできない。
0646デフォルトの名無しさん2010/03/29(月) 08:56:06
>>615
まぁ落ち着け。アセンブラで書けば一番速いのは事実だ。
何しろ、マイクロアーキへの最適化だろうがランタイム動的最適化だろうが、書く気に
なればアセンブラで書ける。労力が馬鹿馬鹿しいだけだ。
0647デフォルトの名無しさん2010/03/29(月) 09:17:46
>>614
だから、そう書いてるんじゃん。

>>616
「理論上の最速コード」においてCがアセンブラを越えられないのは今でも変わらない。
それに「下手にアセンブラ使うよりもCで書いてコンパイラの最適化に任せた方が結果的に速いコードができることが多い」
と書いている。

>Javaで書いてもCより速くなるなんてのは絶対無い。
>>611参照。
厳密な意味では、同じ仕様を同じロジックで、というのは大変難しいと思うが。

>>617
広く使われている処理系では、知らない。
一応、jruby, jython, groovyみたいなのもあるらしい。

>>618
え？そんな理由で出せるの？それはおかしい。
どんなにうまく書いても、ネイティブな言語を越えることはできないと書いてるだけ。

同等のスピードが出せるのは、一旦VMを作って中間コードを処理していくのがCで書いても最速な処理だった場合のみだな。
そんなコードあるとはとても思えないが、ないと言いきる自信はなかったから、同等以下という表現に止めた。

>>623
>>611

>>624
それが真理。けど、最速コードなんていうどこにあるのか分からないものを追い求めるのが実質不可能なのだから、
簡単に使えるものの中で一番マシなのを選ぶことになる。

>>627
プログラマなら、1+1が1になったり0になったりする場合を知っているはずだが。
0648デフォルトの名無しさん2010/03/29(月) 09:26:46
理論上の話をするなら、アセンブラで最適化するよりも、中間コードをJITで最適化する方が速いコードができる。
0649デフォルトの名無しさん2010/03/29(月) 10:31:02
>>648
今時のマトモなプログラマならプロファイラ
使ってフィードバック最適化するだろうから、
そういうケースは実に稀だと思う。
0650デフォルトの名無しさん2010/03/29(月) 10:32:34
その理論って、アセンブラは醜いCISCで、VMは美しいスタックマシン
という設定なんだろうな
0651デフォルトの名無しさん2010/03/29(月) 10:38:04
>>647 お前仕事してないだろ
そしてなんでお前が全レスする必要があるの？

＞プログラマなら、1+1が1になったり0になったりする場合を知っているはずだが。

プログラマだったら文意くらい読み取れよ。
0652デフォルトの名無しさん2010/03/29(月) 10:59:15
>>646
移植性が悪いじゃん
0653デフォルトの名無しさん2010/03/29(月) 11:05:31
＞プログラマだったら文意くらい読み取れよ。

「CよりJavaの方が速い場合もありうる」 なんて、本来ならば相当に前提や条件が "狭まらないと起こりえない話" を
例すら出さずに簡単に断言してしまうなんて、プログラマの感覚からするとありえない。
よって、「おまえ仕事してないだろ」　と仮定した。

また、細かい前提などはわからないけど、簡単な言葉で意表をつきたかった、っていう気持ちは、
何も知らない夢見がちな小学生くらいの子に時折見られる事なので、端的に例えて現した。

こういう事ですね。 >>647 は残念な子だとわかった。
0654デフォルトの名無しさん2010/03/29(月) 12:51:56
>>644
仕方ないことだがCはSecureではない。Human Errorに弱い。人間工学上は問題が多い。
歴史的経緯からSyntax/Statementが混乱している。C++は最初は良かったが巨大になりすぎた。
DとかGoはキラーアプリ次第。

さらにECERE SDK(eC)[ ttp://www.ecere.com/]は技術水準は高いが全般的に未完成。

しかし、上記の欠点はツールや時間が解決する問題であって現代の問題は入門書。
基礎しか考慮していない本のほうが多い。ほとんどの場合は次に読む本べきの便覧を載せていない気がする。
0655デフォルトの名無しさん2010/03/29(月) 12:53:38
前から思っていたが>>1の要求はEuphoria 4.0b3以降[ ttp://oe.cowgar.com/ ]で十分だろ。
これ以上に簡単で習得しやすく文法や構文の不自然さが少ない言語なんかあまり無いけどな。
BSDライセンスなんだし。必要eucを改造して生成コードの品質改善するなりGC無効化機能付ければいい。

もっとも、学生さんなら普通に生活しつつ言語開発に
３年くらい無駄にして失敗しても人生リカバリーできるから、やるならやっとけと。
(OSや言語といった規模の大きいものは若気の至りがないと進捗が遅い)
0656デフォルトの名無しさん2010/03/29(月) 13:58:54
汎用性ならCが一番だよ
ほぼどんな環境でも動くし。
あと最近はコンパイラの最適化より
早いasm書けるやつは少ないな
パイプラインと実行ユニット意識して書くのはめんどい
0657デフォルトの名無しさん2010/03/29(月) 14:02:17
つか、理論的にはどんな言語も大同小異
自然言語と同じでマイナーなのはダメ
誰もエスペラントなんて使わん
0658デフォルトの名無しさん2010/03/29(月) 14:03:01
CPUの構造なんて多種多様で昔みたいに単純じゃなくなってるから、
もはやコンパイラの方が遥かに優秀だよ。
0659デフォルトの名無しさん2010/03/29(月) 14:10:09
そもそもアセンブラでCPUを最大限まで活用できるプログラムが書けるほどの熟練者なら
世界最強のコンパイラを作れるよｗ
俺らより遥かに熟練した奴がコンパイラ作ってるんだから、そのコンパイラを使った方がいいに決まってる。
0660デフォルトの名無しさん2010/03/29(月) 14:20:58
高性能な低レベル言語を作りたいなら、まずはアセンブラでのプログラミングを極めて、
さらに論文などを読んでいろんな人が考えた最適化法を学ばないといけない。
そんな積み重ね無しに既存のCコンパイラを超える低級言語を作ろうなんて片腹痛い。
Cコンパイラですら一人で作るには限界があるっていうのにね。
動くものを作るだけなら簡単。最速を目指すならその10000倍の努力が必要。
0661デフォルトの名無しさん2010/03/29(月) 14:29:21
10000じゃすまないんじゃないか
熟練じゃ超えれない才能の壁がある
ぽっと出じゃ20年前のfortranすら超えれないなw
0662デフォルトの名無しさん2010/03/29(月) 14:31:34
まぁ、このスレでできる事といったら、いい感じの文法を考えて、Cへのトランスレータを作ることだね。
最適化はCコンパイラに任せればいいさ。
0663デフォルトの名無しさん2010/03/29(月) 14:37:13
>>662
それが現実的だな。
0664デフォルトの名無しさん2010/03/29(月) 14:42:21
なんか違うなあ
Cは速さへの執着を捨てて勝ち組になったのに
Cの速さに追いつくことしか考えてないやつが多すぎる
0665デフォルトの名無しさん2010/03/29(月) 14:51:06
>>664
アセンブラではプログラマの能力的に最速記述は現実的に不可能だし、
最新のCPUは全部C言語に最適化して設計されているし、
現状最速の低級言語は間違いなくC言語だという前提で話してるんだけどな。
そしてCコンパイラ並に最適化されたコンパイラを作るとなると相当な努力が必要だから、
最適化はCコンパイラに任せて、我々は文法を考えることに力を注ぐべきだと言っているわけね。
0666デフォルトの名無しさん2010/03/29(月) 14:55:50
>>665
分業とか現実解を考えたらそうなるよな
0667デフォルトの名無しさん2010/03/29(月) 14:59:22
665の最初の4行は読まなくていいと言っているわけね
0668デフォルトの名無しさん2010/03/29(月) 15:21:04
突っ込みどころ満載だなｗ
まあでも現状Cは高級アセンブラとしての地位を確立したし
これ以上も以下もいらんだろ
C++の末裔は同じ立ち位置には立てないな
06696652010/03/29(月) 15:28:22
>>668
どうぞ、突っ込んでください。
ツッコミ大歓迎。
0670デフォルトの名無しさん2010/03/29(月) 15:37:07
昔々国産でbaseとかいうアセンブラがあったな
ifでキャリーフラグとか見れた
0671デフォルトの名無しさん2010/03/29(月) 16:05:26
なんだこのスレ馬鹿しか居ねぇ
0672デフォルトの名無しさん2010/03/29(月) 16:07:46
>>671
賢そうに見える発言どうぞ
0673デフォルトの名無しさん2010/03/29(月) 16:13:40
とりあえずyaccとかでなんか作って遊んでみたらいい
0674デフォルトの名無しさん2010/03/29(月) 16:18:00
自分が何をやっているのか頭にするする入ってくるスパゲッティをかける言語作ってくださいよ
0675デフォルトの名無しさん2010/03/29(月) 16:38:36
>>665の理由でcは不動だし、
c++はc形式で書けちゃうし、c++ゴリゴリも出来るし、ちょうど良い間でも書けるし…
足りない部分は経年によるノウハウと自作・自社・サードハーティーなどのライブラリもあるし……

困ったね。
0676デフォルトの名無しさん2010/03/29(月) 16:41:16
>>675
> ゴリゴリ
用法がおかしい
0677デフォルトの名無しさん2010/03/29(月) 16:43:00
>>676
じゃあ「c++る」で
0678デフォルトの名無しさん2010/03/29(月) 17:00:07
スレ違いだが
センスは一年もたたずに開いてくる
ないヤツは経験でカバーしかないが
高見には登れないんだよな
0679デフォルトの名無しさん2010/03/29(月) 18:16:34
>>669
SIMD でマトモなコードを吐くコンパイラがないから、
速度が必要なトコではまだまだアセンブラが使われてるよ。
0680デフォルトの名無しさん2010/03/29(月) 18:26:15
>>679
SIMDはライブラリで利用できると思う。
0681デフォルトの名無しさん2010/03/29(月) 18:27:45
>>679
ふつーintrinsics
0682デフォルトの名無しさん2010/03/29(月) 18:31:56
普通は特定のCPU向きの機能を使うためのCライブラリが用意されていることがほとんどだから
インラインアセンブラを使うケースはほとんどなくなってきたね。
0683デフォルトの名無しさん2010/03/29(月) 21:16:29
なんでアセンブラの話が出てくるの？

おじいちゃんしかいないのここ？
0684デフォルトの名無しさん2010/03/29(月) 21:17:20
C/C++でアセンブラを使うのは普通
0685デフォルトの名無しさん2010/03/29(月) 21:21:33
アセンブラに逃げるのは思考の放棄に他ならないのである。
0686デフォルトの名無しさん2010/03/29(月) 21:22:34
とりあえず、静的なネイティブコンパイラよりも、
実行時中間コードコンパイラの方が速そうな気がする例。
本当かどうか知らない。 ためしてない。

for (int i = 0 ; i < 1000000000 ; i++) {
switch (ユーザ入力値) {
case 50: a[i] *= b[i] ;
case 70: a[i] &= b[i] ;
case 110: a[i] |= b[i] ;
case 130: a[i] ^= b[i] ;
case 170: a[i] += b[i] ;
default: a[i] -= b[i] ;
}
}
0687デフォルトの名無しさん2010/03/29(月) 21:30:17
>>685 アセンブラが逃げ道だとか本気で言ってるのか
そんなに狙ったロジックを実装するのが簡単だとでも思ってるのか
0688デフォルトの名無しさん2010/03/29(月) 21:41:58
>>686
ちゃんと最適化をするJITなら相当速くなるだろうね。Tracing JITとLoop unrollingとか。
0689デフォルトの名無しさん2010/03/29(月) 21:57:38
そりゃコンパイルなりコーディングなりしているときよりも、
JITの方が使える情報が多いから、理論的には中間コードをJITでコンパイルする方がアセンブラよりも速いコードになる。
0690デフォルトの名無しさん2010/03/29(月) 22:09:18
>>686
極端にランタイム最適化が有利なコードは、サンプルとしてならいくらでも書けるはず。
ただ、実アプリで実行時間に影響するような事例としてどれだけ出てくるか、というのが
問題で、それが言語の需要に直結するし、実用性そのものにも繋がる。
少なくとも、最適化処理を回す負荷を上回るだけの利得があって、それが体感されるほど
の時間スケールになっていないといけない。最適化が効いてくるまでは単純に遅い。結局、
差し引きで利得があるアプリはかなりレアかと思われ。
0691デフォルトの名無しさん2010/03/29(月) 22:12:13
去年は関数型言語が流行った気がするが
今年は中間コードか
0692デフォルトの名無しさん2010/03/29(月) 22:12:58
コンパイルタイムの最適化でカバーできない部分がどの程度あるのかだな
Javaアプリとかぶっちゃけ「起動以外も」糞重いんだし、ほとんどランタイムの
最適化は効いてないんじゃね？
結局、コードモーフィングと同じ結論になるんじゃないかと思うんだが
0693デフォルトの名無しさん2010/03/29(月) 22:14:44
心配しなくてもあと10年はJavaが第一線で使われ続けるよ
0694デフォルトの名無しさん2010/03/29(月) 22:18:38
Javaの心配してる奴なんかいた？
0695デフォルトの名無しさん2010/03/29(月) 22:20:29
一所懸命叩いてる奴ならいるな
0696デフォルトの名無しさん2010/03/29(月) 22:29:01
VMがネイティブより遅いって話をするとJava叩きにされるのかｗ
まぁPARROTとかもいつ出てくるんだって感じだし、Rubyとかも微妙なままだしな
0697デフォルトの名無しさん2010/03/29(月) 22:30:20
Javaは消えるなとは言わない、サーバサイドで頑張っていればいいと思う。
デスクトップ分野でだめなのはもう明らかだし、
あとはこれ以上携帯や組込分野に出しゃばってくれなければいいのだが。
0698デフォルトの名無しさん2010/03/29(月) 22:30:24
Parrotと書かないとまずいか
PARROTじゃハイファのランタイム最適化みたいだし
0699デフォルトの名無しさん2010/03/29(月) 22:30:44
Webサーバーで動いているものなら起動時間が長いといっても無視できる。
0700デフォルトの名無しさん2010/03/29(月) 22:32:22
前にも勘違いしてる奴がいたけど、遅いと言ってるのは起動時間の話じゃないからよく読め
0701デフォルトの名無しさん2010/03/29(月) 22:34:33
まぁ起動時間の遅さは一番目立ちやすいけどな
Javaアプリは起動した後も普通に重い
0702デフォルトの名無しさん2010/03/29(月) 22:36:36
いつの時代の話だよ
糞PC乙

とツッコまれるぞ
0703デフォルトの名無しさん2010/03/29(月) 22:38:44
モバイル系はしがらみの少ない分、純粋に性能で勝負できるからVM系が勝ち残るかも
しれないと思ったんだが、結局C++だのObjective-Cだのに完全に食われたな。
0704デフォルトの名無しさん2010/03/29(月) 22:41:22
言語のパフォーマンスの話をしている時にPC性能の話にすり替える奴

と逆に突っ込まれるんじゃね
0705デフォルトの名無しさん2010/03/29(月) 22:44:29
H.264のHD動画のデコーダをJavaで書かれてネットブックで再生してても気にならない
ような人ならあるいは
0706デフォルトの名無しさん2010/03/29(月) 22:45:35
いずれにしても、CとJavaのどちらで開発しようかと迷うことはまずない。
0707デフォルトの名無しさん2010/03/29(月) 22:50:34
>>703
RIMとGoogleとMicrosoft＋ガラケーがVM
NokiaとAppleがネイティブ
0708デフォルトの名無しさん2010/03/29(月) 23:41:52
ま、なんだかんだCPUは速くなるし
今時java位いんじゃね
ネイティブコードキャッシュすれば起動もはやくなるのに
0709デフォルトの名無しさん2010/03/30(火) 00:01:52
いつjavaはwindowsサービスで動くようになるの？
0710デフォルトの名無しさん2010/03/30(火) 00:03:09
WindowsのシェアがLinuxと逆転したら
0711デフォルトの名無しさん2010/03/30(火) 00:05:43
>>709
オープンソースになったんだから、お前がやればいい
0712デフォルトの名無しさん2010/03/30(火) 00:32:24
>>711
なんで俺が？
0713デフォルトの名無しさん2010/03/30(火) 00:47:27
Javaはウンコ過ぎる
少しはJavaScriptを見習え
0714デフォルトの名無しさん2010/03/30(火) 02:26:58
JavaScriptのx86ネイティブコンパイラってないの？
gccでコンパイルできればいいのに。
0715デフォルトの名無しさん2010/03/30(火) 03:24:18
phpとかperlとかのカスクリプト言語はjavascriptに統一されるべき
0716デフォルトの名無しさん2010/03/30(火) 03:37:30
速度出す為に縛りが出てくることを理解できない奴は帰れよ
0717デフォルトの名無しさん2010/03/30(火) 05:41:25
javascript？それはない
0718デフォルトの名無しさん2010/03/30(火) 05:58:04
pyhonでいいんじゃね
0719デフォルトの名無しさん2010/03/30(火) 08:43:21
ますますスレタイと離れて行くなw
goでいんじゃね
0720デフォルトの名無しさん2010/03/30(火) 08:47:03
だからスレタイの話はとっくに終わってんだよ
0721デフォルトの名無しさん2010/03/30(火) 10:53:39
C++は、まだまだ仕様を含ませてから、
もう後、30年ぐらいしてから一から新しく作り直せばいいよ
0722デフォルトの名無しさん2010/03/30(火) 10:59:31
いやーソフトもハードも汚くてもいいから下位互換性がある言語の
方が寿命が長い傾向があるｗ

x86しかりC/C++しかりだ

このままC++はより一層文法を汚くしながらしぶとく生き残るだろうｗ
0723デフォルトの名無しさん2010/03/30(火) 10:59:44
Cはあと30年はなくならない。C++は他の言語へシフトしていく。
0724デフォルトの名無しさん2010/03/30(火) 14:10:09
やっぱシンプルイズペストなんだよな
0725デフォルトの名無しさん2010/03/30(火) 14:14:23
いくらなんでもCは非力すぎ
0726デフォルトの名無しさん2010/03/30(火) 14:17:47
>>725
スタートに戻る
0727デフォルトの名無しさん2010/03/30(火) 17:29:59
Cが非力とかどんだけタコなんだよｗ
0728デフォルトの名無しさん2010/03/30(火) 17:44:21
やはり職人によるパンチカードが一番ですね。
0729デフォルトの名無しさん2010/03/30(火) 17:46:22
パンチカード世代ってどの辺り？
0730デフォルトの名無しさん2010/03/30(火) 17:51:47
あん？紙テープだろ
0731デフォルトの名無しさん2010/03/30(火) 17:52:23
カード枚数限られてる中、ミスるとどんどんカードが減っていくつらさ分からんだろ
0732デフォルトの名無しさん2010/03/30(火) 20:24:14
バグで無限ループしてプリントアウトした紙が１０ｃｍ超えて涙目になった経験ある人
0733デフォルトの名無しさん2010/03/30(火) 21:10:11
そのパンチカードは水玉パンツになりたかったのかよ。
0734デフォルトの名無しさん2010/03/30(火) 22:04:48
あん？トグルスイッチでアドレスとデータラインセットしてストローブだろ
0735デフォルトの名無しさん2010/03/30(火) 22:26:52
Cコンパイラがはくコードと同等のコードがはける
C#コンパイラをはやく出すんだ
0736デフォルトの名無しさん2010/03/30(火) 22:30:16
お前が出せ。出すんだ！
0737デフォルトの名無しさん2010/03/30(火) 22:40:42
Cはもっとスリムにしていくべき
0738デフォルトの名無しさん2010/03/30(火) 22:43:29
Cのマクロをもっと強力に・・・
0739デフォルトの名無しさん2010/03/30(火) 22:48:43
>>735 Cコンパイラと同等な結果がほしいなら
なんでCで書かないんだ
簡単な話じゃないか
0740デフォルトの名無しさん2010/03/30(火) 22:51:57
GLSLやHLSLが「高級」って呼ばれてるのに、おまいらときたらｗ
0741デフォルトの名無しさん2010/03/30(火) 22:54:12
めんどくさいからマネージドに向けて最適化したハード作れば良いよ
0742デフォルトの名無しさん2010/03/30(火) 22:59:33
>>738
HTMLをもっと強力にしたPHPのようなものか
0743デフォルトの名無しさん2010/03/30(火) 23:00:49
「俺は理解できないから、おまえが来ればいい」
って話か。めんどくさいなんて嘘
0744デフォルトの名無しさん2010/03/30(火) 23:06:43
>>742
昔metahtmlつのがあったな
lispのカッコを<>にしたようなヤツ
実行可能なhtml
0745デフォルトの名無しさん2010/03/30(火) 23:10:25
pythonの中にschemeっぽい（）を見かけたんだが、あれは何なんだ
0746デフォルトの名無しさん2010/03/30(火) 23:38:58
PHPはメタプログラミングの幻想をぶち壊す
0747デフォルトの名無しさん2010/03/31(水) 00:43:58
そもそもメタプログラミングが幻想なのかも知れない
0748デフォルトの名無しさん2010/03/31(水) 00:55:36
>>747
コンパイル時間がめちゃめちゃ延びるけど、手書きよりはるかに楽で正確
0749デフォルトの名無しさん2010/03/31(水) 00:58:00
メタプログラミングってメタボプログラミングの略ですか？
0750デフォルトの名無しさん2010/03/31(水) 01:12:55
ははっワロス
0751デフォルトの名無しさん2010/03/31(水) 01:13:40
Ultimate フレームワークとか超○○ツクールとかの劣化版。
メカプログラミングのなまりｗ
0752デフォルトの名無しさん2010/03/31(水) 01:18:20
一理ある
0753デフォルトの名無しさん2010/03/31(水) 01:19:04
クラスの自称人気者が集まるスレはここですか
0754デフォルトの名無しさん2010/03/31(水) 01:24:35
コンパイラより速く
同じasmコードが吐けるようになったらいいべ
0755デフォルトの名無しさん2010/03/31(水) 03:44:47
EclipseってJavaでできてるけど、結構快適だよな。
数少ない成功事例なのか。
0756デフォルトの名無しさん2010/03/31(水) 03:47:20
>>723
C++のシフト先って今ないだろ。
0757デフォルトの名無しさん2010/03/31(水) 04:03:26
>>755
ハァ？
超絶糞重いわプラグインはバグだらけだわの糞環境じゃねぇか
あんな糞を有難がるのは経済活動できてないクソニートだけだっつの
あれじゃ投資した時間の回収すらできねぇよ
0758デフォルトの名無しさん2010/03/31(水) 04:21:32
>>757
誰が有難いなんて話をしたよ

Cコンパイラだってトランスレータなんだから、Cの拡張としての言語内言語を定義した方が効率的だと思う
0759デフォルトの名無しさん2010/03/31(水) 05:57:57
この手のC言語関連のしょっぱい議論を見てると、マシンコードでコンピュータが走る
単純な流れを知ってるか否かだけで次元の壁があるよな、とつくづく実感させられる
0760デフォルトの名無しさん2010/03/31(水) 07:58:54
>>759
日本語がヤバイ
0761デフォルトの名無しさん2010/03/31(水) 10:14:28
この手のの内容をくわしく書けばいいんじゃないかな
0762デフォルトの名無しさん2010/03/31(水) 10:21:03
Objective-Cは、OSも書けるCよりも便利な言語として設計されている。
その方向で成功しているとは言い難いが。
0763デフォルトの名無しさん2010/03/31(水) 10:26:30
C++でできることがすべてできた上で何ができればいいのだ？
0764デフォルトの名無しさん2010/03/31(水) 10:48:50
「できるけどしてほしくないこと」をわかりやすく表現できればいい
なにもしないprivateメソッドとかがわかりにくい
0765デフォルトの名無しさん2010/03/31(水) 12:03:43
今やマシン語ですら高級言語じゃないの
0766デフォルトの名無しさん2010/03/31(水) 12:12:35
じゃあ何が低級言語なんだ
VHDLか？
0767デフォルトの名無しさん2010/03/31(水) 12:26:10
機械語でかけざん、割り算まで出来ちゃう現代のCPU
0768デフォルトの名無しさん2010/03/31(水) 13:55:21
C++は互換性を強く意識してでかくなりすぎた
C++にやらせたくない事をコーディング規約としてまとめた物を作ったとしたら、
価値はないだろうか？
0769582010/03/31(水) 14:36:01
記述力が高くてわかりやすい数式の記法ってのがあれば
数学はカンタンになるのか？
0770デフォルトの名無しさん2010/03/31(水) 14:46:07
>>769
微分積分の記号がない状態で微分積分の問題を取り扱うのが難しかったように、記述力が高い記号は数学を簡単にする助けになる
0771デフォルトの名無しさん2010/03/31(水) 14:50:58
微積の記号（インテグラル記号とか）はニュートンがほぼ今の原型を作ってるから最初からあるってことだぞ
0772デフォルトの名無しさん2010/03/31(水) 14:52:58
ニュートンじゃなくライプニッツな
0773デフォルトの名無しさん2010/03/31(水) 14:54:48
イギリスは独自の微分積分の記号を使ってたから
大陸より発達が遅れたんだよな
0774デフォルトの名無しさん2010/03/31(水) 14:56:31
ニュートンもライプニッツもイギリス人なんだが、そうなの？
0775デフォルトの名無しさん2010/03/31(水) 14:58:37
ライプニッツはドイツ人かと思われ
0776デフォルトの名無しさん2010/03/31(水) 15:03:10
はっきりとは言わなくても、実は数学に疎い人たちが多いって事だけはわかった
あと、>>769 は数学アレルギーで覚える気も無いって事もわかった

同じように、きっとJavaやC#のような単純なルールの言語なら覚えられるけど、
C/C++のようなあれもこれも可能な言語は覚えられない連中が多く、
そしてそれを認めるのが恥ずかしいって思ってる人たちが多いのもわかった。

以下、ひまわりスレ
0777デフォルトの名無しさん2010/03/31(水) 15:03:20
プライムのことをダッシュって読む人いるよね
0778デフォルトの名無しさん2010/03/31(水) 15:03:53
微分積分の概念は、関孝和も同水準に達していたけど、記号がないので発展しなかった面がある
0779デフォルトの名無しさん2010/03/31(水) 15:10:00
プライムよりダッシュだべ
英論文でプライムを初めて見たとき何のことだかしばらくわからんかった
0780デフォルトの名無しさん2010/03/31(水) 15:12:25
数学の教授が、日本人があんまりダッシュダッシュと言うからダッシュが普及し始めた
とか冗談言ってたな
0781デフォルトの名無しさん2010/03/31(水) 15:21:56
CC'=Σ(the prime denoting transpose)
主要な転置表記
0782デフォルトの名無しさん2010/03/31(水) 15:47:10
K'(ξ)=w, where prime denotes differentiation with respect to ξ.
素数はξの違いを表す
0783デフォルトの名無しさん2010/03/31(水) 15:58:05
>>776
覚えられないから簡単にしろって云う人への批判として
769 を書いたつもりなんだけど、難し過ぎましたか。
0784デフォルトの名無しさん2010/03/31(水) 16:21:26
cにあれ付けてこれ外してってよりも、javaにポインタつけて後どうしようか？
の方がスムーズに話が進む気がするんだけど。
0785デフォルトの名無しさん2010/03/31(水) 16:25:28
>>783
「こういうつもりで書いたんだ」 で済まさず一言余分に付け加えるあたり、
プライドの高さが垣間見えるようです。
0786デフォルトの名無しさん2010/03/31(水) 16:44:41
>>784
C#
0787デフォルトの名無しさん2010/03/31(水) 16:46:27
>>777
俺ミノムシって呼んでる
'←みのむし
"←ダブルみのむし
`←反対のみのむし
0788デフォルトの名無しさん2010/03/31(水) 16:59:42
>>787
俺もそうよんでるｗ
流行ってんの？
0789デフォルトの名無しさん2010/03/31(水) 17:02:44
俺の会社でもみんなみのむしって呼んでいるぞ
0790デフォルトの名無しさん2010/03/31(水) 17:03:34
>>787
当たり前じゃん。
ミノムシは世界共通だぜ。
0791デフォルトの名無しさん2010/03/31(水) 17:07:01
>>787-790
おい、誰だ　ミノムシ流行らせようとしてるやつｗ
俺も明日から使おうかな。
0792デフォルトの名無しさん2010/03/31(水) 17:22:32
スレから適当にピックアップしたけど途中で面倒になった。
適当に足しとして。


C/C++に無いけど欲しい機能
○欲しい
・アトミック処理
・リアルタイム性
・Lispなみに弄くれる型安全なマクロ
・Forthなみに弄くれる駆動レコード
　- 駆動レコードへのアクセス
　- 実行制御
　- 強制インライン展開(レコードを新しく作らないルーチン)
・マトモなクロージャ
・マルチスレッド対応／自動並列化／トランザクション
・割り込み処理

○微妙
・GC
・多重継承の代わりにmix-in
・コルーチン
・契約プログラミング

0793デフォルトの名無しさん2010/03/31(水) 17:41:50
C/C++に有るけど要らない機能はなんだよ
0794デフォルトの名無しさん2010/03/31(水) 17:55:18
>>792
スレ違いな事してんじゃねぇ
ここはミノムシを語るスレだ
0795デフォルトの名無しさん2010/03/31(水) 18:01:20
Cのマクロは今の視点ではいらないな。
0796デフォルトの名無しさん2010/03/31(水) 18:25:11
inlineがLispのマクロに相当するんじゃないの
0797デフォルトの名無しさん2010/03/31(水) 18:31:01
>>794
ある意味ネタスレだしな。これ以上の議論は期待できないね。

まあ、もっとも必要なら別スレとして
新言語Polka-dot(仮称)とか、C言語クローン総合スレ等の
新規スレとWiki立てるけど？
0798デフォルトの名無しさん2010/03/31(水) 18:35:09
具体的な低級言語に求める機能のアイデアは誰も語らないの？
0799デフォルトの名無しさん2010/03/31(水) 18:42:11
プログラミング初心者なんですが、GCが邪魔になるコードの例を教えてもらえませんか？
ゲームとか通信とか言われてもピンと来ないです。
0800デフォルトの名無しさん2010/03/31(水) 20:25:17
Lispのマクロは2回評価するのだ
08017922010/03/31(水) 20:44:42
>798
俺が語ってるだろ。
他にc/c++では実装できない／言語の助けの無い機能があったら挙げてくれ。
0802デフォルトの名無しさん2010/03/31(水) 20:48:07
C/C++の拡張が前提なわけ？
0803デフォルトの名無しさん2010/03/31(水) 20:49:03
0と1だけでプログラムをかける低級言語、01を作ろう
0804デフォルトの名無しさん2010/03/31(水) 21:20:48
>>799 GCが邪魔になるってのは、その処理そのものが害になると言うより、
しなくてもいいところでも走る（＝ＧＣ管理の為の処理や、開放など）から、
あえて言うなら邪魔だという話。　てか邪魔って言うより、常にそれありきじゃなくてOn/Offしたいって感じ

0805デフォルトの名無しさん2010/03/31(水) 22:21:55
>>803
whitespace使っとけよ
0806デフォルトの名無しさん2010/03/31(水) 22:23:54
ヘッダがいらない
0807デフォルトの名無しさん2010/03/31(水) 22:28:06
じゃあヘッダ自動生成のCのIDE作る
0808デフォルトの名無しさん2010/03/31(水) 22:54:21
>>804
> しなくてもいいところでも走る
はい、その点は理解しているのですが、
GCが走ると処理がわずかに中断されて、それが気になるほどの悪影響を与えるケースを
実証できるコードはどんなものか興味がありまして・・・
0809デフォルトの名無しさん2010/03/31(水) 22:58:49
>>808 だから悪影響を与える実証コードが云々じゃなくて、
無くてもいいものなら無い方がいいって話。

例えば関数一つ呼んで、何かの戻り値を得るとかの処理があった時、中に作られる自動変数やら何やら、
あるいはクラスをnewして得たなにやらを、自分で管理出来た方が都合がいいだろ？って話だよ
0810デフォルトの名無しさん2010/03/31(水) 23:04:31
>>808
FPSゲームなんかで交戦中には余計なことして画面がガクンとなるのはやめて欲しいから、
どうにもならない場面でだけGCするように作って、後は戦闘中以外の処理もたついてもいい場面でGCしたい。
なんてのは普通にあるんでないの？
0811デフォルトの名無しさん2010/03/31(水) 23:10:40
>>810
でもゲームでは入力や通信やらで非同期に余計な処理が結構いろいろあるので
GCが起きるぐらい些細な事なのではないか、と素人ながら思ったのですが・・・
0812デフォルトの名無しさん2010/03/31(水) 23:18:21
>>811
入力は全然問題ない。
動作を脅かすとんでもない入力なんてない。

通信はしらない。
フルタイムで通信してるようなゲームはその些細なことをそれなりに気にして作ってるんじゃないの。
だいたい通信量ってそんなめちゃくちゃな量はないと思う。
0813デフォルトの名無しさん2010/03/31(水) 23:18:32
そりゃ素人以下だな
0814デフォルトの名無しさん2010/03/31(水) 23:26:16
>>812
確かに通信料は少なそうですね。
実際グリグリ動くFPSでも100kbps程度だったりして驚きます。

う〜ん、では質問を変えますが、ゲーム中にGCが起こったとして何ミリ秒ぐらいゲームがストップしますか？

>>813
決して皆さんを侮辱しているわけではありませんので、怒らないで聞いてください。
単なる素人の疑問ですから。
0815デフォルトの名無しさん2010/03/31(水) 23:35:22
>>814
何が言いたいのかわからんが、認識できるレベルで止まる重くなるプログラムしか作れない言語なら問題があると言えないか？
作る側は良くてもやる方は甘くいこと言ってくれないぞ。
0816デフォルトの名無しさん2010/03/31(水) 23:37:13
100kbpsもあるのかFPSは
結構あんのな
0817デフォルトの名無しさん2010/03/31(水) 23:40:05
>>815
確かに問題ありますよね。
しかし、本当に言語に問題があるのかどうか皆さんの話を聞いているだけではピンと来ないので
そのケースを再現したプログラムなどがあれば理解もしやすいのですが・・・
リンクだけでも結構です
0818デフォルトの名無しさん2010/03/31(水) 23:43:41
>>814
そんなのはプラットフォーム次第。
たとえばヒープの少ない古い携帯電話なんかで、断片化の起きやすいコードを書いてれば秒レベルで止まる。
0819デフォルトの名無しさん2010/03/31(水) 23:50:01
たとえばだな

ルータを考えてみなよ
こっちの都合考えずに
パケットがガンガンくるでしょ
gcで0.1秒とか中断したら
パケット落ちちゃうかもでしょ？

動画のカメラのキャプチャが
1/30秒で画像送ってきたとする
途中でgcが走ったら画像おちるでしょ？

計測機が一定周期でモニタしてるとして
周期が乱れたらまずいでしょ？

gc避けたいのはそういう相手に合わせないといけない用途
人が使うものは時間短いなら普通大丈夫だが
ゲームや動画、音声なんかはシビアだね
0820デフォルトの名無しさん2010/03/31(水) 23:51:28
>>817
最初から信じる気ないだろ？
自分で大量のオブジェクトnewしまくるコードでも書いてみたら？
困らないなら話題にもならないよ。
0821デフォルトの名無しさん2010/03/31(水) 23:53:54
ゴミ回収のタイミングって、アルゴリズムがわかってればだいたい分かるんじゃないかな。
それにプログラミング側のテクニックでゴミが出にくいプログラミングも可能だと思うけど。
0822デフォルトの名無しさん2010/03/31(水) 23:54:13
gcは書き方や処理でだいぶ頻度が変わるが
不可抗力やエラーでもないのに
データが落ちたり抜けたりは
設計上許されないわな
0823デフォルトの名無しさん2010/03/31(水) 23:54:59
>>820
まさにそういうプログラミングするから大幅にGCに負荷がかかるんだよなぁ。
0824デフォルトの名無しさん2010/03/31(水) 23:55:13
GCといっても言語ごとに違うだろ。
ちなみにluaだとGCの動作で2倍くらい速度変わる。
実例として、EU3(市販ゲーム)でGCの調整パッチで
動作速度1.5倍くらい変わった。
0825デフォルトの名無しさん2010/03/31(水) 23:56:07
GCしたいときにGC関数実行すれば回収してくれるような仕様だったらどう？
0826デフォルトの名無しさん2010/03/31(水) 23:58:16
>>821
ま、普通シビアな分野では
メモリなんて動的に取らんがねw
最初に確保したら後は増え減りもしないw
0827デフォルトの名無しさん2010/03/31(水) 23:58:36
それはそれでGCが必要なときにGCされない危険が伴う。
0828デフォルトの名無しさん2010/03/31(水) 23:59:15
>>820
私が信じていないのは、>>821さんの仰るように、
プログラマーがGCの挙動を理解していないがために
GCへの負荷がかかりすぎてしまうプログラムを書いてしまって
いるのではないかということなんです。
0829デフォルトの名無しさん2010/04/01(木) 00:00:19
>>825
dojaがそうだけど、命令してもメモリがあまり使われてなかったらやらないとかいうし。
0830デフォルトの名無しさん2010/04/01(木) 00:01:02
>>826
そうそう。
絶対回収されないようにずっと保持して、そこを使いまわすのが普通のスタイル。
newしまくるのは下の下のプログラマのやることじゃないの。
0831デフォルトの名無しさん2010/04/01(木) 00:01:51
そもそもGCってのは自分でメモリのマネージできないようなアフォグラマの為のものだからね。
負荷の多いコーディングしてしまうのも仕方がないのさ。
0832デフォルトの名無しさん2010/04/01(木) 00:04:10
820だけど、バカにされてるみたいで嫌だからいうけど俺はそんなコードは書かないぞ。
例で言っただけなんだからっ
0833素人2010/04/01(木) 00:08:04
>>830
ではそういうプログラミングスタイルならば
GCありの言語でもリアルタイムな用途でつかえるということでしょうか？
0834デフォルトの名無しさん2010/04/01(木) 00:09:48
>>833
JavaみたいにGCありの言語で組み込みプログラミングする例だってあるんだから、
やってる人はいるんだよ。
0835デフォルトの名無しさん2010/04/01(木) 00:11:07
>>828
つまり、自分で結論出てるじゃないか
GCと言う便利な物があるからと言って、それにすべてを任せたら
まともに動作しない環境がある。昨今のデスクトップPCみたいに
恵まれている環境ばかりじゃないからね。
0836デフォルトの名無しさん2010/04/01(木) 00:15:45
自分の結論に同意して欲しいだけなら知恵袋にでも書いておけよ。
0837デフォルトの名無しさん2010/04/01(木) 00:20:34
PerlとかHaskellのゲームなら聞いたことがあるが
楽をするためではなくて、むしろ逆のような気がする
0838素人2010/04/01(木) 00:21:06
>>836
いろいろお騒がせしてすみませんでした。
0839デフォルトの名無しさん2010/04/01(木) 00:22:37
>>837
monadius有名だな
0840デフォルトの名無しさん2010/04/01(木) 00:25:21
そういやmonadiusで暫くプレイしてるとどんどん遅くなるって作者が言ってたな。
あれもgcのせいなのかね。
0841デフォルトの名無しさん2010/04/01(木) 00:26:57
>>840
原因が分からない（分かりにくい）のはデメリットだよな。
0842デフォルトの名無しさん2010/04/01(木) 00:29:00
少なくともCなら原因がどこにあるのかコードを見れば分かるんだけど、
Haskellみたいな遅延評価の言語はGCの挙動がわからん。
0843デフォルトの名無しさん2010/04/01(木) 00:32:48
>>834
組み込みにはリアルタイムのものと非リアルタイムのものがある。
リアルタイムのシステムには処理時間の最悪値が保障できないGCは使えない。
スレタイは超高速と謳ってる以上リアルタイムが最低条件だろ。
0844デフォルトの名無しさん2010/04/01(木) 00:41:09
リアルタイム性が要求される環境でGCあり言語が使えるかどうかって話しだけど
選択可能だとしても、好んで選択する人はあまり居ないと思う。

それだけシビアな環境だとまずはスループットが要求されるわけで、Cやasmが
選択できるなら、そっちを選ぶんじゃないかな。つまりGC単体で処理系を判断
する事はまず無くて、現状のGC搭載言語より、総合してC、asmの方が向いていると
判断する事の方が多いと思うわけだ。

ちなみに「シビアな環境」とはどういう環境かと言うと、
* ヒープは何バイトまで利用します
* スタックは何バイトまで利用します
* どんな事があってもこの処理は何ナノセカンドで戻ります
と言う事を、仕様として明確にして、責任を持たなければならない環境の事なんで
GCが入り込む余地はほとんど無いかも知れない。
0845デフォルトの名無しさん2010/04/01(木) 00:45:09
組み込み用処理系のGCならヒープどれだけ使うかは設定できるんじゃない？
Cとかアセンブラとかでやるときはプロファイラとにらめっこしながら試行錯誤するけど・・・
どっちも大して変わらんか。
0846素人2010/04/01(木) 00:49:26
組み込みなどのシビアな環境に詳しい方にお聞きしますが、
C言語でプログラミングしていて、
こういう機能があったらこういうシーンでもっと楽ができるのに！
と思う事があったら教えてください。
0847デフォルトの名無しさん2010/04/01(木) 00:53:52
脳に直接繋いで頭で考えるだけで実装されるデバイスがあれば良いのに
0848デフォルトの名無しさん2010/04/01(木) 00:54:52
>>846
ヒープを使わない短い文字列クラス、とか。
でもC++があれば、こういう必要な機能は必要に応じて何でも作れるしな。
0849デフォルトの名無しさん2010/04/01(木) 01:02:38
>>844で箇条書きした3つの要件を満たしているかどうかが
コンパイル時に分かれば、ムチャクチャうれしいね
0850デフォルトの名無しさん2010/04/01(木) 01:04:06
必要な機能のキーワードで検索すると即使えるフリーなライブラリが自動で組み込まれる
IDE直結型の検索エンジンが欲しいな。
0851デフォルトの名無しさん2010/04/01(木) 01:05:38
>>849
そこで形式的仕様記述言語での設計ですよ。
0852デフォルトの名無しさん2010/04/01(木) 01:06:24
ここは本当に物事を進める能力絶無な底辺キーパンチャしかいねぇな
事を起こすならまず最初にやるべき事をやれ
名前を付けろ
0853デフォルトの名無しさん2010/04/01(木) 01:07:39
じゃあ言語の名前つけます
「kuma-」
これでいいですか
0854デフォルトの名無しさん2010/04/01(木) 01:08:04
現役時代はハードパンチャーって云われたよ
0855デフォルトの名無しさん2010/04/01(木) 01:10:10
>>853
はい
0856デフォルトの名無しさん2010/04/01(木) 01:11:04
はいじゃないが
0857デフォルトの名無しさん2010/04/01(木) 01:11:23
>>853
はい
0858デフォルトの名無しさん2010/04/01(木) 01:12:12
はいじゃないが
0859デフォルトの名無しさん2010/04/01(木) 01:13:29
おし、じゃあまずはkuma-の言語仕様をBNFで書いてみることからはじめよう
0860デフォルトの名無しさん2010/04/01(木) 01:14:10
↓どうぞ
0861デフォルトの名無しさん2010/04/01(木) 01:14:24
クマって呼ばれてたものがあった気がするがなんだっけ
0862デフォルトの名無しさん2010/04/01(木) 01:14:29
名付けに失敗したプロジェクトは99%失敗するから
初期段階に名前で存分に悩むのは経済的に正しい
0863デフォルトの名無しさん2010/04/01(木) 01:15:27
ああ、AMDのCPUか。Kuma
0864デフォルトの名無しさん2010/04/01(木) 01:15:31
名無し言語
↓
0x7C言語
↓
|言語
0865デフォルトの名無しさん2010/04/01(木) 01:18:27
>853
どうせなら kummer- だろ。

名前以前にコンセプトをどうにかしようぜ。
0866デフォルトの名無しさん2010/04/01(木) 01:18:43
>>864
ぐぐれねーよｗ
0867デフォルトの名無しさん2010/04/01(木) 01:20:47
>>866
名無しなのに簡単に特定されたら困るだろ？
0868デフォルトの名無しさん2010/04/01(木) 01:21:59
俺的にpythonみたく{}を除去したい＾＾
0869デフォルトの名無しさん2010/04/01(木) 01:22:21
出た当初はC#もググれなかったんだが、今じゃ普通に出るな
0870デフォルトの名無しさん2010/04/01(木) 01:23:29
C# とか、.NETとか、MSは意図してググれなくしたように思えて仕方がない
0871デフォルトの名無しさん2010/04/01(木) 01:24:26
お前らが金出してGoogle アドワーズに表示するようにすればおｋ
0872デフォルトの名無しさん2010/04/01(木) 01:27:38
じゃあ|で検索結果出るようになったら俺らの勝ちだな
0873デフォルトの名無しさん2010/04/01(木) 01:33:29
{}がある方がブロックが明確でいいが強要はいやだな

組み込みやリアルタイムでもそこまでメモリシビアじゃないのも多いよ
特に32bit RISCの奴。
でも時間に関しては結構シビアだったりするな。

ただそういうのでも全てが時間制限あるわけじゃないし
単純にスループットならGCありでも稼げるしね。
GCが記述で決めれるなら静的に解析も出来るし
高プライオリティなのはNon GC, どうでもいい処理はGCありとか出来る
0874デフォルトの名無しさん2010/04/01(木) 01:44:03
じゃあ、手動でメモリ解放する手段も提供されていて、
かつGCしたいときにGC命令を実行すればGCしてくれるようにするのはどうだろう。
0875デフォルトの名無しさん2010/04/01(木) 01:48:35
問題ってのは言語が勝手に動的なメモリを解放・確保することなんよな
でもそれがメリットでもある
GC除外の宣言を変数にできたらどうだろ
0876デフォルトの名無しさん2010/04/01(木) 01:49:34
>>873
> {}がある方がブロックが明確でいいが強要はいやだな
python使うまではインデントブロックが強要されるのは気持ち悪いと思っていたけど、
実際に使ってみると案外メリットばかり感じるようになるんだよね。
{}のブロックだとどこからどこまでがブロックなのか、非常に視認性が悪い。
もちろんemacsなどのエディタでは自動でインデントしてくれるが、し忘れることもあって、
例えば多重ifなどで範囲を間違って読んでしまうこともある。
08778762010/04/01(木) 01:52:01
ほんとに、こういう使い勝手の問題は実際に使ってみないと分からないんだけどね。。
プログラミング言語は道具なだけに。
0878デフォルトの名無しさん2010/04/01(木) 01:58:37
>>875
確保はしないんじゃね
0879デフォルトの名無しさん2010/04/01(木) 02:00:35
>>876
視認性に関してはエディタに強く依存すると思う。
インデント強制は保守の面から悪くないとは思うけど。

ところで関数は
public static int hoge(int aaa,String bbb = null){}
なの？
public static function(aaa:int, bbb:String = null):int{}
の方がなんとなく好きなんだけど。
0880デフォルトの名無しさん2010/04/01(木) 02:12:29
>>878
言語によるよ
0881デフォルトの名無しさん2010/04/01(木) 02:14:43
ML流の引数を()で閉じないタイプが好きなんだけど、マシン語に落とす時に問題ある？
0882デフォルトの名無しさん2010/04/01(木) 02:37:26
1. 速度、移植性はC
2. その他(構文、ライブラリ)はPython

がベスト
0883デフォルトの名無しさん2010/04/01(木) 02:52:55
>>882
＞1. 速度、移植性はC
＞2. その他(構文、ライブラリ)はPython

2はインデントブロックに関しては賛成
ライブラリはjava流が簡単な気がする。
0884デフォルトの名無しさん2010/04/01(木) 06:29:30
>>882
Cがよくわからないからpython風に書きたいです、って言ってるだけじゃん
0885デフォルトの名無しさん2010/04/01(木) 06:30:49
Cがよくわからないからpython風に書きたいです
0886デフォルトの名無しさん2010/04/01(木) 06:45:59
習得しやすさはどうでもいい
強力で高速で普及してればいいから、C++で全く困らない
0887デフォルトの名無しさん2010/04/01(木) 08:35:25
>>883
それ目指してんのがgolangだな
0888デフォルトの名無しさん2010/04/01(木) 08:36:09
つーか一定以上難しくないと職を失うだろ
0889デフォルトの名無しさん2010/04/01(木) 08:36:52
golangには先手を取られたが、必ず追いついて見せる（ｷﾘｯ
0890デフォルトの名無しさん2010/04/01(木) 09:32:44
Pythonって書き方おかしいから嫌い
0891デフォルトの名無しさん2010/04/01(木) 12:02:42
>>888
書き方なんて簡単な方がいいよ
問題は何をどう書くかだから
それで職失うってのはそもそも不毛な仕事で不要な人間だわｗ
0892デフォルトの名無しさん2010/04/01(木) 12:08:38
いかにも難しくて一見して意味がわからない言語じゃないと
経営者が「俺でも分かる」と思い込んじゃって給料減らされるから。
0893デフォルトの名無しさん2010/04/01(木) 12:14:00
英語が分からないから、COBOLが分からないやつ
0894デフォルトの名無しさん2010/04/01(木) 12:14:12
そんな無能な経営者も不要だなｗ
0895デフォルトの名無しさん2010/04/01(木) 12:32:03
簡単ってなんなの
C/C++が普及しているのはC/C++が簡単だから？
0896デフォルトの名無しさん2010/04/01(木) 12:34:34
>>895
LinuxやWindowsがC言語で作られているので、システムコールがC言語の関数ベースだから。
0897デフォルトの名無しさん2010/04/01(木) 12:42:16
>>895
歴史。実用的で無駄の少ないコードがこのコンパイラ言語のおかげでずいぶん楽になったね、
って言う歴史
0898デフォルトの名無しさん2010/04/01(木) 14:23:42
>>875
CycloneはGCではなくregion based memory managementだな。
つか今のメモリー管理システムのトレンドってなんだろうな。
年表あればいいんだが。

>>892
無能な経営者は淘汰されるから心配しなくてもいい。
むしろバグ・ケアレスミス・保守や記述の冗長性が減れば
開発者の健康面で良いし、安全性や生産性があがるんで、
そっちのほうが重要だな。

それでプログラマの自殺減ったり開発がしやすくなればいいと思う。
0899デフォルトの名無しさん2010/04/01(木) 14:39:08
C言語の国産セキュア実装といえばFail-Safe CやVITCなんかもある。

ttp://web.yl.is.s.u-tokyo.ac.jp/
ttp://www.rcis.aist.go.jp/project/FailSafeC-ja.html
0900デフォルトの名無しさん2010/04/01(木) 14:42:19
>>875
その手の手法は既に C++/CLR で出来るな
新しいものなんて何も必要なかったんだ
0901デフォルトの名無しさん2010/04/01(木) 14:52:09
それならポインタがあるC#だってできるぞ。
0902デフォルトの名無しさん2010/04/01(木) 16:01:44
>>898
馬鹿め
無能な経営者は毎年途切れる事無く補充されるってことを知らんのか
0903デフォルトの名無しさん2010/04/01(木) 16:15:25
>>902
大丈夫、この不況でだいぶ消毒されたから。
0904デフォルトの名無しさん2010/04/01(木) 16:19:01
C++/CLIはもはやJavaのパクリではない点が新しい
0905デフォルトの名無しさん2010/04/01(木) 16:29:05
まあ無能なエンジニアはもっと生産されてるがなｗ

>>900
MSの作ったモノは。。。(ry
といいたいが、仕様見てみた。こんなもんかね。
0906デフォルトの名無しさん2010/04/01(木) 16:36:41
>>905
この不況で無能なエンジニアは就職できないんですよ。
だから少なくとも今年の新卒エンジニアは無能じゃない。
0907デフォルトの名無しさん2010/04/01(木) 16:41:43
就職できたら有能ってのはチト早合点
0908デフォルトの名無しさん2010/04/01(木) 17:11:27
なんかもう…
パフォーマンス必要な所だけCかasmで書いて、
あとはなんでもいいやー、な気分になってきてしまいました。
結局、今と変わらん。
0909デフォルトの名無しさん2010/04/01(木) 17:12:40
>>908
そのパフォーマンス必要な所を書く言語を作ろうと言っているわけで。
0910デフォルトの名無しさん2010/04/01(木) 17:27:23
なかなか伸びが速いが次スレか？
それともネタスレなので終了か？
次スレなら今の段階でスレ内容をまとめて>>2とかに貼るアレが必要だな。
0911デフォルトの名無しさん2010/04/01(木) 17:29:46
Cが最高って結論で終了で良いけど
0912デフォルトの名無しさん2010/04/01(木) 17:35:00
>>910
決まったこと：
言語名「kuma-」
0913デフォルトの名無しさん2010/04/01(木) 17:35:18
高機能な言語の便利な機能が、どのようなしくみで実現されているかを知れば、Cにそれらの機能がないのはなぜかが分かると思うのだが。
0914デフォルトの名無しさん2010/04/01(木) 17:40:20
リストもGCもないcamlとかどう？
0915デフォルトの名無しさん2010/04/01(木) 17:51:25
パフォーマンスが必要な部分なんて本当に小規模になるはずだし
ならCでよくね？


　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　完
0916デフォルトの名無しさん2010/04/01(木) 17:56:32
OSのことを忘れているだろ。
0917デフォルトの名無しさん2010/04/01(木) 18:27:58
>>912
次スレ作るならfc2 Wiki借りてくるが？ただし末尾のハイフン使えないサービスだから
そのままURLにするのは無理。次のうち一つ選んでくれ。

kuma-minus, kumamin, kumamens, kumaminkind, mrbear, mrkuma
0918デフォルトの名無しさん2010/04/01(木) 18:48:57
言語名は、|言語だろ？
0919デフォルトの名無しさん2010/04/01(木) 18:55:47
C with Classesでいいよ
0920デフォルトの名無しさん2010/04/01(木) 19:01:14
オブジェクト指向機能はつけた方がいいのか？
stackless Cとかどう？
0921デフォルトの名無しさん2010/04/01(木) 19:04:25
Cにクラスはいらない
0922デフォルトの名無しさん2010/04/01(木) 21:52:04
全然参加する気はないが、検索しやすい名前にしてくれ。
0923デフォルトの名無しさん2010/04/01(木) 21:59:14
>>919
欲しい機能を追加していくとC++になっちゃうな。
0924デフォルトの名無しさん2010/04/01(木) 22:07:19
オブジェクト指向の代わりにCSP機能つけたらどうだろう。
golangみたいに並列で動くとリアルタイム性が失われるので、
手動でタスクを切り替えられるようなコマンドを用意するとか。
0925デフォルトの名無しさん2010/04/02(金) 02:05:42
>>924
プリエンプティブなマルチスレッドにすればリアルタイム性は確保できる
プリミティブでPriority Inversion Safeなmutexと
シンプルなセマフォとメッセージがあればOKじゃね
手動での実行権放棄もありで。
。。。。言語にRTOS機能組み込みだなｗ
0926デフォルトの名無しさん2010/04/02(金) 02:06:16
まずは、すぐに、確実に出来る事からやってみないか。

現状カーネルやドライバ等を記述できる言語で実用的なのは、asm, C, C++って所だけど、
この中で一番機能豊富なのはC++である事は言うまでもない。にも関わらずC++が使いにくい
という印象があるのは、言語仕様が大きく、その割りに標準ライブラリが貧弱だから。

で…、

1. C++で使わない事にする機能をリストアップする
2. 標準ライブラリとして利用すべきライブラリをリストアップする

つまりコーディング規約を作ってみると言う話しだ。
0927デフォルトの名無しさん2010/04/02(金) 02:06:54
まずはclassがいらねえな
0928デフォルトの名無しさん2010/04/02(金) 02:14:09
それはstructで十分だから？
0929デフォルトの名無しさん2010/04/02(金) 02:19:00
CSPさえできればオブジェクト指向も理論的に実装可能
0930デフォルトの名無しさん2010/04/02(金) 02:29:58
これ以上質問されると言語教室になっちまう。
3時間1万円くらいなら教えるけど。

そんなどーでもいいこと気にしてないで言語を一通り覚えて、
なんか実用的なソフトを一つ開発すれば、データの扱いなんたるかだいたいわかるよ。
今の段階じゃ無理。
0931デフォルトの名無しさん2010/04/02(金) 02:31:05
盛大に誤爆した
0932デフォルトの名無しさん2010/04/02(金) 02:32:41
www
0933デフォルトの名無しさん2010/04/02(金) 02:38:32
>>928
えらい人にはわからんのですよ
0934デフォルトの名無しさん2010/04/02(金) 03:12:26
クラスとテンプレートは要るけどポリモルフィズム
なんて要らないから vtbl は無くてもいいな。
0935デフォルトの名無しさん2010/04/02(金) 03:32:21
インターフェースは多重継承したいね。
実装を伴うクラスは、継承できなくてもいいかも知れない。
0936デフォルトの名無しさん2010/04/02(金) 04:37:30
インターフェイスとか要るなら C++ 使えばいいじゃん。
高級マクロとしてのクラスとテンプレートで十分。
でも実装の継承はもちろん要る。
異論はあるだろうけど。

とかバカ書いてて思ったけど、proxy パターンとか delegation というか
メッセージの forwarding を簡潔にやれる文法あると良いな
0937デフォルトの名無しさん2010/04/02(金) 06:15:16
マルチスレッドを低級言語の言語体系に組み込むのは無意味。
0938デフォルトの名無しさん2010/04/02(金) 07:19:43
何スレ使ったってＣが最強っていう結論で終わるに決まってるのに
0939デフォルトの名無しさん2010/04/02(金) 07:26:34
>>937
今後はハイエンドの組み込みからシンメトリカルなマルチコア化が進んでいくだろうから
無意味とも言えないな
0940デフォルトの名無しさん2010/04/02(金) 07:45:16
>>939
どうやってスレッドの管理をしているのかを考えてみよう。
0941デフォルトの名無しさん2010/04/02(金) 11:25:45
>>939
標準ライブラリで良いと思うけど。
0942デフォルトの名無しさん2010/04/02(金) 12:56:36
結局、低水準を触ったことの無い奴が「仕組みよく分かんないけどCと同じ速度が欲しい」
と言ってるだけなのが良く分かる流れだな
0943デフォルトの名無しさん2010/04/02(金) 12:57:09
Cと同じ速度のJavaが欲しい
0944デフォルトの名無しさん2010/04/02(金) 13:15:59
>>942
いいじゃん、それで言語ができちゃったら面白いじゃん。
0945デフォルトの名無しさん2010/04/02(金) 13:19:37
コンパイラの勉強から始めましょう
0946デフォルトの名無しさん2010/04/02(金) 13:20:36
Cコンパイラなら作ったことあるよ。
激遅だけど。
0947デフォルトの名無しさん2010/04/02(金) 13:22:31
激遅でもいいじゃない。マシンスペックが高ければ
0948デフォルトの名無しさん2010/04/02(金) 13:29:27
>>943 とあるシンプルな言語があって、それに諸々の管理機構を取り付け、
全てをクラスとして表現し、プログラマがメモリ管理などを気にせずコーディングできる様な
そんな新しい言語をつくりました。それがあなたの得意なそれです。
0949デフォルトの名無しさん2010/04/02(金) 13:36:57
単純なことをやらす分には、JavaもCも速度は変わらん。
0950デフォルトの名無しさん2010/04/02(金) 14:19:02
>>940
言語に組み込んであるのがポイントなんだよ
0951デフォルトの名無しさん2010/04/02(金) 14:26:27
むしろ、言語に組み込まずに、後から実装して、
あたかも最初から言語に組み込まれていたかのように見えるような仕様を考えてみようよ。
0952デフォルトの名無しさん2010/04/02(金) 14:34:06
>>950
それではここで言う低級でなくなる
0953デフォルトの名無しさん2010/04/02(金) 14:37:41
ぶっちゃけ何でもいいからアセンブラ一つくらいは触れる奴じゃないと、低水準向けの
言語設計なんて話題では感覚が違いすぎて雑音にしかならない
だが、触れる奴ならCで大して困らない
0954デフォルトの名無しさん2010/04/02(金) 14:39:24
だからスレ立てた奴が何にも分かってなかったって結論がかなり最初に出ただろ馬鹿
0955デフォルトの名無しさん2010/04/02(金) 14:40:15
じゃあCの方言つくろうぜ
0956デフォルトの名無しさん2010/04/02(金) 14:57:21
どうやって言語実装するのか先に考えようぜ。
全部アセンブラで作ろう。
すると低級言語作るのに悪くないし、馬鹿よけにもなるので変な話題が入ってこない。
0957デフォルトの名無しさん2010/04/02(金) 15:00:36
>>956
移植性悪いじゃん。
馬鹿除けならHaskellで作ろうぜ。
0958デフォルトの名無しさん2010/04/02(金) 16:45:50
>>943
D言語じゃねーかよ
0959デフォルトの名無しさん2010/04/02(金) 16:59:12
>>956
馬鹿除けはFAQ読みな！の一言で片付けるからいいがアセンブリだと？
つかBDS Cかよ。

実装の汎用性求めるなら初期段階はスクリプト言語上に実装するのもあり。

0960デフォルトの名無しさん2010/04/02(金) 17:18:05
実装は、汎用性もあるJavaでいいんじゃないか。
0961デフォルトの名無しさん2010/04/02(金) 18:14:19
名前すらまともに決まらないほど誰も何もやる気が無いって事だな
さっさとこの糞スレ埋めて仕事に戻れよ
0962デフォルトの名無しさん2010/04/03(土) 09:14:04
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものでした。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0963デフォルトの名無しさん2010/04/03(土) 10:15:22
エンディングバージョン初めて見たｗ
0964デフォルトの名無しさん2010/04/03(土) 10:41:16
なんだもう終わりか
0965デフォルトの名無しさん2010/04/03(土) 14:20:17
次スレ

【超高速】C/C++に代わる低級言語を開発したい 2
http://pc12.2ch.net/test/read.cgi/tech/1270254244/
0966デフォルトの名無しさん2010/04/03(土) 15:29:14
アイちゃん、勝手に次スレ立てるなよ。
0967デフォルトの名無しさん2010/04/03(土) 16:04:30
>>965
ただのネタスレで話も同じ事の繰り返し＝進展しようが無いのに
なんでパート化させてんだ

ネタ雑談スレ立てたいならせめて違うアイデアにしろよ
0968デフォルトの名無しさん2010/04/03(土) 17:01:19
>>967
アイちゃんの訓練のために立ててるんだよ
0969デフォルトの名無しさん2010/04/03(土) 23:48:47
test
0970デフォルトの名無しさん2010/04/04(日) 23:05:02
さっさと埋めろ、アイちゃん
0971デフォルトの名無しさん2010/04/05(月) 01:05:48
埋めるって言っても、連投すると規制がかかるだろ?
何人かで強力しないと。
990とかギリギリになってから、次のスレたてれば良かったんだよ。
0972デフォルトの名無しさん2010/04/05(月) 01:43:26
次からは是非そうしてくれ。ume支援
0973デフォルトの名無しさん2010/04/05(月) 01:54:57
というか次がある気で居るのかｗ
1200レス消費しても何から決めるかすら決まってねえのにｗ
0974デフォルトの名無しさん2010/04/05(月) 02:32:26
蒼樹うめ
0975デフォルトの名無しさん2010/04/05(月) 03:02:56
じゃあ何から決めるか、先ずはそれを決めようじゃありませんか
0976デフォルトの名無しさん2010/04/05(月) 04:30:02
何から決めるかを決める前に物事を決める為の手順を決めなければ始まらないだろ
0977デフォルトの名無しさん2010/04/05(月) 08:33:24
埋め
0978デフォルトの名無しさん2010/04/05(月) 09:44:53
爪
0979デフォルトの名無しさん2010/04/05(月) 10:37:16
久米
0980デフォルトの名無しさん2010/04/05(月) 11:27:12
もうやめろよこんな糞スレ
0981デフォルトの名無しさん2010/04/05(月) 12:15:48
うまい棒
0982デフォルトの名無しさん2010/04/05(月) 14:10:03
はらへった
レス数が950を超えています。1000を超えると書き込みができなくなります。