トップページ⇒tech
983コメント296KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/05/07(金) 11:36:35
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 4
http://pc12.2ch.net/test/read.cgi/tech/1271980246/
0153デフォルトの名無しさん2010/05/08(土) 01:33:50
>>148
停止性問題と同じくGCが必要か否かを証明する方法はない
単に不要と判断するならGCを殺せばいい
0154デフォルトの名無しさん2010/05/08(土) 01:35:58
>144
>「GCが必要かどうかの自動判断」

自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。
コンパイル時に全部スタックに乗っているかどうかをチェックさせるという手もあるとは思うけど、
それならGC自体が不要だわな。
0155デフォルトの名無しさん2010/05/08(土) 01:36:16
そして再開する俺構文オナニーショー！！！！

↓最初の方、どぞ
0156デフォルトの名無しさん2010/05/08(土) 01:36:36
>>153
停止性問題と同じではないでしょ。
GCよりもコンパイラーの方がメタなわけだし。

GCにGCの必要性は証明できないかもしれないけど、コンパイラーがGCの必要性を証明できないって事にはならないのでは。
0157デフォルトの名無しさん2010/05/08(土) 01:44:16
>>154
> 自動判断を行うためにはリソースの生死を確認する必要があるわけで。結局GC回す必要がある。

いや、「GCが必要かどうかの自動判断」というのは、リソースの生死の確認ではなく、リソースの生死の確認が必要かどうかの確認だよ。
後者にはGCは必要ないよね？
0158デフォルトの名無しさん2010/05/08(土) 01:46:12
GC回収対象のオブジェクトを作らなければ不要でしょ
malloc使わなければfreeいらないのと同じ
0159デフォルトの名無しさん2010/05/08(土) 01:57:33
>157
>リソースの生死の確認が必要かどうかの確認

所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。
結局プログラム自体を実行させる必要が出てきて、やっぱりGC回さなきゃ判らんよね、ということになるよ。
0160デフォルトの名無しさん2010/05/08(土) 01:59:34
>>159
> 所有者のハッキリしないリソースがあるかどうかというのをコンパイル時点にコンパイラに判断させるのは至難の業。

このあたりがもう少し具体的になると議論が深まるかも。
0161デフォルトの名無しさん2010/05/08(土) 01:59:56
GCがあると便利な場合は当然あって、それはそれでいいと思う。
ただ、一部のCユーザにはGC無しで自分でメモリ管理をする方が望ましいわけでしょ？
だったら両方できればいい
0162デフォルトの名無しさん2010/05/08(土) 02:06:45
Garbage Collection (GC)について語るスレ
http://pc12.2ch.net/test/read.cgi/tech/1141646850/
0163デフォルトの名無しさん2010/05/08(土) 02:08:16
>>159
GCを回しても、所有者のハッキリしないリソースがあるかどうかというのはわからないのでは。
GCで知れるのは、リソースの所有の有無と、所有者だよね？
所有者がハッキリするかどうかは別の問題ではないかと。
0164デフォルトの名無しさん2010/05/08(土) 03:01:11
>160
リソースの管理に関しては主に確保->(保持<->譲渡)->放棄という局面があるわけなんだけど、それらを紐付けて
関連付けるのはなかなか難しいことで。
あるオブジェクトが確保したリソースを複数のオブジェクトで盥回しにして解放するというのは良くある状況だけど、
普通のc++なんかのソースコードだとそれぞれモジュール化されて切り離されているから、それをコンパイル時に統合して
トレースするのはかなり大変なんじゃない？
ということ。

>159
コンパイラが所有者のハッキリしないリソースを見つける≒コンパイル時にGCが必要な状況を見分ける
ぐらいの意味ですな。


0165デフォルトの名無しさん2010/05/08(土) 03:10:45
Objective-C
0166デフォルトの名無しさん2010/05/08(土) 03:25:17
GC/nonGCについてですが、自分が今考えているのは、
通常のオブジェクトはCと同じように関数(グローバル)スコープでのみ生存し、
それとは別にDynamicObjectみたいな組み込みクラスを用意して、それを
継承したオブジェクトはGC対象にしようと思っています。
で、コンパイルオプションでDynamicObject自体を抑制できる、みたいな。

てのはどうでしょうかね？
0167デフォルトの名無しさん2010/05/08(土) 03:41:41
ね？ではなく、試せ
0168デフォルトの名無しさん2010/05/08(土) 05:55:57
>>104
だれも便利は求めてないぞ（ｗ

安全性が高い＝便利だけどね。

>>107
代替そちが有れば良いけどまるで出来ないのは辛い。

>>108
>>１を嫁よ、Ｃ言語と文法上の互換性は必要ない。
ただしオブジェクトリンケージとか、Ｃ、Ｃ＋＋、ＪＡＶＡ
Ｄ，Ｇｏ，Ｃ＃で色々見知った事を生かしたい。
0169デフォルトの名無しさん2010/05/08(土) 05:58:42
>>120
二兎を追うんじゃなくて、美味なる一匹
0170デフォルトの名無しさん2010/05/08(土) 06:01:42
>>160　例えば多値戻しのちょっと変な人が書いたコードなんだけどint[] div(int a, int b){
＞int[] div(int a, int b){
＞　int[] result = new int[2];
＞　result[0] = a / b;
＞　result[1] = a % b;
＞　return result;
＞}

これ良い例だと思うんだけど、呼び出し元では
void foo(){
　　int[] ret;

　　ret = div(13, 5);
　　return;
}
てな事になってヤバイよね
0171デフォルトの名無しさん2010/05/08(土) 07:44:37
> プログラマの意図どおりにバイナリを生成する保障はどこにもない。
> マクロはプリプロセスなので必ずインライン展開される。その違いを認識せよ。

どっちにしろ「意図通り」のコードを吐いてくれるかどうかなんてわからない。
50歩100歩。すっぽすっぽたんの言う通り、字面で書き換えを行うことによる
言語上の弊害のほうがきわめて大きい。
0172デフォルトの名無しさん2010/05/08(土) 08:01:39
誤爆かと思ったら前スレかｗ
定数に限っては意図どおりに展開されるよ
0173デフォルトの名無しさん2010/05/08(土) 08:13:49
>>170 続き

なので前スレか、前々すれで提案した。

戻り値タイプ　関数名
　　　　　　　Source(),　　　←値渡しがデフォルト
　　　　　　　Parameter(),　←const リファレンスがデフォルト。
　　　　　　　Result(),　　　←リファレンス
　　　　　　　Exception(); try文の糖衣構文でcatchするオブジェクトを指定できる


まだ考え中なんだけどさ、こういう関数定義にしておいて。

void foo(){
　　int[2] ret;//retはスコープ内の寿命
　　mathEx mEx;

　　div.Source(13, 5);
　　div.Result(ret);
　　div.Exception(mEx);

　　div.call(){
　　　　catch(mEx == overfllow){
　　　　}
　　　　catch(mEx == divbyzero){
　　　　}
　　}
　　return;
}
0174デフォルトの名無しさん2010/05/08(土) 08:15:10
>>173　続き

なんて風に行けると、コンパイラも最適化しやすいだろうし、
プログラミングもやりやすくなると思うんだよね。
構文については酷いし、例外はもっと考えないと不味いだろうけども。
例外についても2種類有るってのをどうやっていくか、とか、本当に2種類なのか
とか。
0175デフォルトの名無しさん2010/05/08(土) 08:23:05
それはきめえわ
0176デフォルトの名無しさん2010/05/08(土) 08:26:36
CPU固有言語たんハァハァですな。
0177デフォルトの名無しさん2010/05/08(土) 08:45:34
マクロが必要か不要かの割合は１：９くらいでしょう。
不要だという人が多い。
ジェネリックスや多態性等で解決できるという主張だ。
でもジェネリックスを使いやすく発展させることを考えると
マクロに近づいていくというのがD言語のジェネリックスを見れば分かるかと。

C言語がプリプロセッサと言語は分かれているようにマクロ部分と言語本体は分ければいい。
HaskellとかOcamlはそうなっている。

ジェネリックスというかC++のテンプレートはオブジェクト指向とは直接関係しない、
コンパイルタイムにプログラムを作成する関数指向なプログラムだから。
0178デフォルトの名無しさん2010/05/08(土) 08:53:05
>>174　続き。ところで例外なんだけども、180度考え方を変えて、
bool div
　　Source(int a, int b),
　　Result(int[] result);
　　Exception(mathEx mEx);
{
　mathEx& localmEx;　　　　　　　　//これを呼び元関数がException
　if(mEx == NULL){　　　　　　　　//を設定してるかどうかによって
　　localmEx = new mathEx(); 　　　//コンパイラが自動設定。
　　localmEx.setlocal();　　　　　　　　//スコープの問題や
　}else{　　　　　　　　　　　　　//変数寿命の問題が残るので、熟慮が必要。
　　localmEx = mEx;　　　　　　　　//
　}　　　　　　　　　　　　　　　　//

　if(0 == b){
　　localmEx.setdivbyzero;
　　throw localmEx;
　}
　result[0] = a / b;
　result[1] = a % b;
　return result;

　catch(localmEx){
　　if(local.divbyzero() && localmEx.islocal()){
　　　printf("divbyzero\n");　　　　　　//呼び出し元が例外を受け取らないのなら
　　　abort();　　　　　　　　　　　　　//例外を投げる側がシステム設定を定義。
　　}else{
　　　throw localmEx;　　　　　　　　　//呼び出し元が例外を受け取るならそちら任せる。
　　}
　}
}
0179デフォルトの名無しさん2010/05/08(土) 08:55:41
>>178　続き
こうすればスタックの巻き戻しという大がかりな機構が必要なくなるし、
記述の一貫性が保てて良いと思うんだけど、例外の利点を何か失いそうな
感じがしてる。でもそれが何かまだ分からない。
0180デフォルトの名無しさん2010/05/08(土) 09:32:56
>>179 続き。
>>178のコンパイラ自動設定の部分は、>>173で示したように、
Exceptionを関数定義で定義するかどうかによって、判断したら、
つまり、Exception引数を定義しなければ、旧来のＣ言語関数と
同じイメージになる。としてしまえば、総ての関数に、例外処理
というコードが組み込まれるのも避けられると思うんだ。

後、Source,Parameter,Resultに関しても関数定義するときに名前が
付くだけで、実際はＣ言語の引数リストと同様なので、旧来のシステム
と混在が可能だと思うんですよ。

提案の狙いはこの部分なので、お前の稚拙考えだとそれは実現できないとか
こんな場合はどうするとか、言ってくれると嬉しいんだけど、ここは２ｃｈ
なので>>175なのかもしれない。
0181デフォルトの名無しさん2010/05/08(土) 09:42:11
このスレは馬鹿しかいないな
0182デフォルトの名無しさん2010/05/08(土) 09:49:16
>>181
無意味なこと書き込むお前ほどではない。
0183デフォルトの名無しさん2010/05/08(土) 09:59:19
お前らの書き込んでいることは無意味ではないとw
0184デフォルトの名無しさん2010/05/08(土) 10:08:37
>>183
人を馬鹿にするときには馬鹿にする前に馬鹿にする相手を論破しておかないと馬鹿にしているやつが馬鹿に見える。
お前のように実社会で馬鹿にされているからここにきて馬鹿にしに来ているやつにありがち。
0185デフォルトの名無しさん2010/05/08(土) 10:16:22
書き込んでいる人間のプロファイリングとか
馬鹿しかしないわなw
0186デフォルトの名無しさん2010/05/08(土) 12:33:10
>>178
必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
記述量が多い割に、値か関数かの判定は先読みしなければならないのも嬉しくない。
強力なマクロも実現できそうにない。

例外を関数読んだあとに直ぐにキャッチしなきゃいけないなら、
返り値でいいでしょう。
返り値らしいboolはどこで返してるのか、使っているのか分からない。

0187デフォルトの名無しさん2010/05/08(土) 12:40:44
もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
話したいなら、そこだけ話せばいいのでは？

例外処理を入れるとなるとC++の例外処理では機能不足で関数毎に
例外処理のためのコードを入れる必要があると考えていて、

例外をjavaの検査例外にしておけば、例外投げないソースだけなら、
例外の処理を関数ごとに入れる必要がなくなってよいと思ってると
いうことですか？

0188デフォルトの名無しさん2010/05/08(土) 13:12:35
>>186
>必要以上に記述量が多いので大部分の人は使ってくれないでしょう。
その辺は後から有る程度はどうにでもなるから気にしてない。
P_,S_,R_,E_とかでも良いわけだしね。
それに大規模（ソース行数がミリオン超えっていみな）開発していくと、
結構みんな、逆にフルスペリングの方が間違いが無くて良いって事になる。
例えて言うと、GUI系のライブラリなんかそうだよね。

>>187
いや、JAVAもC++も同じなんだけど、スタックの巻き戻しやって、
最後にシステム基底のデフォルト例外処理にぶち当たるんだけど、
システム基底の例外処理にぶち当てるか、自分で例外キャッチするのかを
一番よく知ってるのは、呼び元の関数だろ、なに世界一周旅行に出かけなきゃ
ならないんだ？って部分への疑問を解決するためのコードというか例外処理。
0189デフォルトの名無しさん2010/05/08(土) 13:15:47
>>186　続き
>>187
>もしも新しいC言語に例外を組み込むとしたらどのようにしたらよいかを
>話したいなら、そこだけ話せばいいのでは？
関数定義も変更したいのとセットで語りたい部分だから。

>>178の下の部分は
catch(localmEx){
　　if(local.divbyzero() && localmEx.islocal()){
　　　system_default("divbyzero");　　　//こんな感じにシステムデフォルトにする事もできるしさ
　　　abort();　　　　　　　　　　　　　
　　}else{
　　　throw localmEx;　　　　　　　　　//呼び出し元が例外を受け取るならそちら任せる。
　　}
0190デフォルトの名無しさん2010/05/08(土) 13:17:08
>>189は>>188の続きの間違い。
0191デフォルトの名無しさん2010/05/08(土) 13:17:15
>>188
いや、単語の長さとか、そういうレベルじゃない。
個人的には、お前は根本的にセンスがないと思う。
0192デフォルトの名無しさん2010/05/08(土) 13:19:23
>>191
気分の議論は無意味だよ。とか書いても理解力は無いか。
まぁニギヤカシがいてるのが2chなのでしょうがない。
0193デフォルトの名無しさん2010/05/08(土) 13:28:27
>>192
いや、気分の話じゃない。
言語を作るときに必要なのものとして、機能と文法があるとして、
文法の部分はかなりセンスを必要とする。

お前の主張の例外の扱いの「機能」については、受け手が受け取られるか
どうかを判別できるようにする、というだけで、まったく魅力的な機能ではない。

そして、文法的にも全然すっきりしていない。

機能としても新しくなく、文法としても魅力がないものを訴えても、そりゃ
誰も理解を示さない。
0194デフォルトの名無しさん2010/05/08(土) 13:36:19
気分的には、再利用とカスタマイズへの拘りが感じられるスレだな
低級言語を低級ではない分野にも再利用したいとか
一からBNFを書き直すのではなくパーサーをカスタマイズしたいとか
そういう話題が多い
0195デフォルトの名無しさん2010/05/08(土) 13:36:23
>188
直上の呼び出し元しか例外処理できないなんて無茶だわ。
そもそも「何の関数が呼び出したの？」という問題もあるし、結局まともに例外を実装しようとしたら
全部の関数にcatchを付けなきゃいけなくなって、オーバーヘッドが酷いことになるわな。
あとマクロとの相性が最悪なことになりそう。

例外は「異常事態用の専用フローを用意する」ということが重要なのであって、例外発生時の効率を
考えるのは筋が悪いですな。
そんなことをするんだったら、forthみたいにスタックを直接操作できるようにした方が100倍マシ。
0196デフォルトの名無しさん2010/05/08(土) 13:42:04
>>195
＞直上の呼び出し元しか例外処理できないなんて無茶だわ。

なんで？　これがよく分からない。

＞そもそも「何の関数が呼び出したの？」という問題もあるし、
ねーよ馬鹿。
0197デフォルトの名無しさん2010/05/08(土) 13:43:04
>>193
だから、気分を語られても困るって（ｗｗｗ
0198デフォルトの名無しさん2010/05/08(土) 14:04:09
>196
お前……例外使ったことないだろ。
細かい関数(thunkとか)実装した時に、それぞれの関数にcatchを用意しなきゃいけなくなるんだぜ？
オーバーヘッドで死んでしまうわ。どこの高水準言語だ

>何の関数が呼び出したの？
サブルーチンだけに閉じてればOKだけど、もうサブルーチン決め打ちに決定したのか？
またマクロの実装をどうするか、遅延評価をどうするかとか色々な要因があるんだけど。
まあ、例外を効率化しようなんて馬鹿考えるやつなら想像力もこんなもんか。
0199デフォルトの名無しさん2010/05/08(土) 14:12:10
ここまで有用な話題なしと
0200デフォルトの名無しさん2010/05/08(土) 14:21:47
>>124
GC必須にしたら結局低級言語にならないという
結論に到達するなw
0201デフォルトの名無しさん2010/05/08(土) 14:23:37
>>152
お前デザインパターンを駆使するとdeleteするタイミング考えるの大変だぞ
0202デフォルトの名無しさん2010/05/08(土) 14:34:18
デザインパターンは古い
クラウドを駆使するとソケットを閉じるだけだぞ
0203デフォルトの名無しさん2010/05/08(土) 15:05:58
v = a / b
v,ok = a / b
v,r = a /% b
v,r,ok = a /% b

ま、そもそも0かどうか検査しなさいってこった。またはエラーを返して処理しなさいってこった。

例外はCPUの例外の様に異常度が高いものに限るべきで、その際は大域脱出した方がいい

例は割り算だが大規模でも小規模でもおなじ。例外は起こさない様にするのが原則。

CPU固有君は最初から話がズレてる。
バラメータとソースとかも全く意味不明で戻り値の宣言も。f(g())出来ないとか、C++的オブジェクトありきとか。
0204デフォルトの名無しさん2010/05/08(土) 15:11:04
>>203
ゼロ除算は結構簡単に発生するから良い例なんだよね。
異常度が高いというレベルで考えれば、数学概念を破壊するほど
高い異常な事態なんだけど、会計処理なんかでどかんと
処理したいときなんかは、簡単に発生するし。
0205デフォルトの名無しさん2010/05/08(土) 15:18:22
>>201
そんなクリティカルな部分で悩むのにデザインパターンを
採用するのがキチガイなんだよね。
0206デフォルトの名無しさん2010/05/08(土) 15:57:37
なんで割り算する前に判定しない前提なの？
知恵遅れなの？
0207デフォルトの名無しさん2010/05/08(土) 16:04:32
例外は要らない

ただ0除算例外の回避方法が、事前に０かどうか検査する、ってのはちょっと違う。
それは特定の例外を回避する方法に過ぎず、一般的にどんな例外が
起きるかはやってみないと分からない場合に使えない。

例外に代わる仕組みとしては、システムコールのerrnoみたいに
どこか別にエラー情報を持つのがいいと思う。

たとえば、
　 a = b / c;
　if(errno == division_by_zero)
           /* 0除算時の処理 */
あるいは、
　(a, errno) = b / c;
ですかね。
goみたいだけど
0208デフォルトの名無しさん2010/05/08(土) 16:16:58
>>186
> >>178
> 必要以上に記述量が多いので大部分の人は使ってくれないでしょう。

それが使ってるんだな、Javaで。弱冠文法が違うが。
0209デフォルトの名無しさん2010/05/08(土) 16:19:21
errnoは今さらあり得ない。
0210デフォルトの名無しさん2010/05/08(土) 16:24:27
イメージしやすいようerrnoを使ったまでだよ
0211デフォルトの名無しさん2010/05/08(土) 16:26:01
なんで台無しにした後始末の話になるんだよ
未然に防ぐ方法を考えろや
0212デフォルトの名無しさん2010/05/08(土) 16:28:07
例外なんて必要ない
ファイル開けなかったらabortすればいい
0213デフォルトの名無しさん2010/05/08(土) 16:28:11
>>188
たまにしか使わない部分は長いほうがいいかもしれない。
でも、言語は常に使う部分だから短いほうがいい。
CもRubyも短くかけるから好まれる。

例外の話に限ればもっと話してもいいかも。
>>189
関数定義の段階で賛同していないけど、例外処理の話はしてもいい人とも
話せなくなるよ。
0214デフォルトの名無しさん2010/05/08(土) 16:59:49
>>213
言語仕様をどうするかって話をしてるので、
俺の提案は、関数仕様ごと改革するべき、
という提案の中に例外が含まれている。

例外だけを話したい人は、その主旨を汲んでくれないと、
俺の側からはまだ歩み寄れない。分かるかな？これ。
言語仕様って部分と全体が有るので、部分ばかり追い求めると
機能ＡとＢが当たり困ったりするじゃん。

もちろん例外だけを話したい人でも、その方法では例外のこれが
このように出来ないとちゃんと（訳の分からないＯＳ持ち出さず）
話してくれるのなら聞く用意はとてもある。
0215デフォルトの名無しさん2010/05/08(土) 17:01:51
アプリケーションレベルならsetjmp/longjmpで十分な件。
OSとか作る場合他のプロセスの発生した例外の
トラップとか必要なわけでjavaなんか真似ても
全く使い物にならない件。
0216デフォルトの名無しさん2010/05/08(土) 17:04:01
signalとごっちゃになっとるな
0217デフォルトの名無しさん2010/05/08(土) 17:10:47
ブログラムエラーとかプログラムでは避け難いエラー処理を行うのが例外だからな
構文に入れちまったのはC++やJavaの設計ミスと思うがね

0割の例ならCPUがトラップする時点でランタイムやOSが関与するし、発生しないCPUもある
言語よりランタイムの話でいんじゃね
0218デフォルトの名無しさん2010/05/08(土) 17:13:26
頭が設計ミスの奴がいるな
0219デフォルトの名無しさん2010/05/08(土) 17:17:42
お前がな
0220デフォルトの名無しさん2010/05/08(土) 17:51:44
あの辺の言語に try-catch が導入されていることを、ただ単に設計ミスと言っているようなヤツは、このスレで発言するのは控えてほしいな。
0221デフォルトの名無しさん2010/05/08(土) 17:59:33
脳を0割しか使わないとこういう発言をしてしまうんだな
0222デフォルトの名無しさん2010/05/08(土) 18:10:48
さらに新しい言語には導入されてない理由も考えずに戯言いうなよw
0223デフォルトの名無しさん2010/05/08(土) 18:12:17
まあ形かえたgotoだからな
汚いのは当然
0224デフォルトの名無しさん2010/05/08(土) 18:16:20
例外を文法でなくライブラリで実現した言語って何があったっけ？

まさかsetjmp/longjmpを使えとか言うんじゃないよな。
0225デフォルトの名無しさん2010/05/08(土) 18:20:00
むしろ関数の後ろにエラー専用のラベルを付けられるようにしろよ
VBみたく
結局ブロックでネストさせんのが面倒ってことだろ
0226デフォルトの名無しさん2010/05/08(土) 18:23:52
setjmpを構文に取り入れただけだしな
OSとか組込とか例外自身を記述するのはどうすんだ？
0227デフォルトの名無しさん2010/05/08(土) 18:27:22
longjmpにはjmp_bufを渡す必要があるわけだが、大抵の言語の例外は、そんな面倒な仕様じゃないぞ。
0228デフォルトの名無しさん2010/05/08(土) 18:28:19
いろいろそういうことがあるから、OSはC++ではなく、Cで書かれているんじゃないか。
0229デフォルトの名無しさん2010/05/08(土) 18:36:53
Cでもマクロで隠しちまえば似たことはできるわな
金粉かけても汚いモンはきたないし。

あんなモン構文にいれちまうから
エラー処理まで例外にしちまうバカがでるし、
無用なオーバーヘッドを意識せずにつかっちまう
0230デフォルトの名無しさん2010/05/08(土) 18:39:25
>214
なら関数仕様をどうするつもりなのか説明しないと話にならんな。
エスパーじゃないんだから、まとめて話してもらわんとわかるわけ無いだろ。
単にc++の例外仕様を変更しただけっつうなら単なる不燃ゴミだがな。
0231デフォルトの名無しさん2010/05/08(土) 18:39:25
馬鹿の発言が頻繁すぎる
0232デフォルトの名無しさん2010/05/08(土) 18:39:48
>>202
デザインパターンは普段当たり前のように使っているものでブームではないはずなんだが。
デザインパターンとクラウドは直交する概念
0233デフォルトの名無しさん2010/05/08(土) 18:40:17
>224
scheme
0234デフォルトの名無しさん2010/05/08(土) 18:42:53
>>231
賢い発言してくれよ
0235デフォルトの名無しさん2010/05/08(土) 18:43:37
>>205
どこがクリティカルでどこがキチガイなんだ。
JavaやC#では「デザインパターンありき」で開発するからどこでメモリ解放するかを
きっちり意識する必要はないんだが。staticイニシャライザやProxyパターンを使わないでループ内でしつこく無駄にnewしてるわけでもなかろうし。
むしろぞんなメモリのことでキチガイのように無駄に悩む必要がないからデザインパターンを使えるわけだが。
0236デフォルトの名無しさん2010/05/08(土) 18:51:39
>>217
DivideByZeroExceptionを実装する代わりに
MATLABのように　
0/1
と入力すると
Inf (無限大)と出力でもする仕様にするのか？
pow(-1,1/2)　(-1の平方根)と入力するとNaNと出力せずに
i (虚数)
と出力する複素数型仕様にでもするのか？
0237デフォルトの名無しさん2010/05/08(土) 18:52:22
>>222
C#、PHPで導入されているが何か
0238デフォルトの名無しさん2010/05/08(土) 18:53:49
話が発散するから「低級言語」として適当でない話題は他所でやれよ
スレタイにC++が入ってるのがそもそも良くないんだが
0239デフォルトの名無しさん2010/05/08(土) 18:58:40
>>238
新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

おまえがこっちでやればいいだろ
0240デフォルトの名無しさん2010/05/08(土) 19:05:23
>>233
Lisp族でマクロで実現されているものはライブラリというより文法の一部だろ。
0241デフォルトの名無しさん2010/05/08(土) 19:06:40
ライブラリで出来るなら
まずは既存の言語で優れたライブラリを作ってみたらどうだ？
0242デフォルトの名無しさん2010/05/08(土) 19:13:27
>>238
低級言語でも例外処理とオブジェクト指向を適用しよう
というのは無理か
0243デフォルトの名無しさん2010/05/08(土) 19:16:15
いまどきは組み込みですらC++使っているから
0244デフォルトの名無しさん2010/05/08(土) 19:21:27
>>243
C++の機能をほとんど使わずにな
0245デフォルトの名無しさん2010/05/08(土) 19:24:12
とりあえずここらでターゲットを明確にしておいたほうがいい。

ファームウェア〜コンソールアプリもしくはサーバーサイドアプリくらいでいいよな？
0246デフォルトの名無しさん2010/05/08(土) 19:25:21
C言語でもオブジェクト指向プログラミングは可能だし。
ジョークのストラウストラップインタビューにあるように、Xウィンドウシステムのフレームワークが
そうだし、解説した本も数冊ぐらいある。

FORTHでOOをやったという話もあるぞ。
0247デフォルトの名無しさん2010/05/08(土) 19:28:04
デバドラなんて昔からOOチックだしな
0248デフォルトの名無しさん2010/05/08(土) 19:29:47
組み込みの幅は広いからな
0249デフォルトの名無しさん2010/05/08(土) 19:30:03
そりゃ自動でやってくれることを手動でやれば
Cでもオブジェクト指向は可能だろうよ。
めんどくさくてやってられないだけで
0250デフォルトの名無しさん2010/05/08(土) 19:33:25
>>240
言語仕様を変えずに実現できれば、ライブラリで可能ということになるでしょう。
文法が変えられるならそれだけ言語のライブラリで出来ることが増えるだけなのに
反則と思ってもらってもなぁ。

>>242
C++で出来てるから無理ではないけど、C言語レベルの話が
固まっていないうちからオブジェクト指向を持ち出すべきじゃないでしょう。

0251デフォルトの名無しさん2010/05/08(土) 19:39:24
例外ライブラリでやってなんかメリットあるのか？
ゼロオーバーヘッドにできるの？
0252デフォルトの名無しさん2010/05/08(土) 19:43:55
あほが多用しなくなる
■ このスレッドは過去ログ倉庫に格納されています