08/05/03 23:18:53
URLﾘﾝｸ(jikes.sourceforge.net)
Jikesみたいなコンパイル速度が売りのコンパイラはC++にあるの?
836:デフォルトの名無しさん
08/05/03 23:23:08
>>834
特色のある言語処理系が色々と出てくるのは悪い事じゃない
例えばCINTとか
URLﾘﾝｸ(root.cern.ch)
837:デフォルトの名無しさん
08/05/03 23:25:23
まあでも今時C++を使ってる人間は余程の熟練者なんだろうな
そうじゃなきゃ普通は>>827みたいに考えるよね
838:デフォルトの名無しさん
08/05/03 23:25:35
>>835
頑張ってググッたようだけどjikesなんて使われてねぇよ
839:デフォルトの名無しさん
08/05/03 23:27:28
>>838
昔は結構使ってたぞ。それなりに有名だったんだが、最近の連中は知らんのか。
840:デフォルトの名無しさん
08/05/03 23:28:35
今は使われていない事に変わりはないだろ。
841:デフォルトの名無しさん
08/05/03 23:28:58
>>839
古参乙
いつのJDK互換か知ってて言ってるのか？
842:デフォルトの名無しさん
08/05/03 23:30:41
>>840
それでも言いたい事は分かるだろ
C++は今も昔もゼロなんだよ
843:デフォルトの名無しさん
08/05/03 23:31:03
C++と比べれば、Javaなんて標準のコンパイラでもめちゃくちゃ速いです。
844:デフォルトの名無しさん
08/05/03 23:32:43
>>843 つまらん
845:デフォルトの名無しさん
08/05/03 23:33:59
C++は標準のコンパイラも無いからポータビリティが大変です。
846:デフォルトの名無しさん
08/05/03 23:34:28
IBMみたいに体力あるところとかOSSならともかく、
独自実装なんてやったアホなコンパイラは標準について来れずに死滅しました
847:デフォルトの名無しさん
08/05/03 23:34:53
>>842
C++に大衆性がないのに同意しない人間はいないだろ。
firefoxとかadobe readerとか、一部のエリートプログラマは使っているが。
848:846
08/05/03 23:35:03
javaコンパイラのことな
849:デフォルトの名無しさん
08/05/03 23:36:05
>>847
エリート乙
850:デフォルトの名無しさん
08/05/03 23:38:08
>>846
Microsoft ってまだ Java やってたんだな…
851:デフォルトの名無しさん
08/05/03 23:41:52
>>821
>そんなの上位の一握りだし
今日一番寂しい言葉だったよ... (´･ω･｀)
852:デフォルトの名無しさん
08/05/03 23:43:28
>>850
やってないよ
お亡くなりになるJ#のこと？
853:デフォルトの名無しさん
08/05/03 23:45:15
>>851
何で？
メジャーな環境のフリーなコンパイラがあるのにそんなことするのは
余程上の人間か、もしくはただのアホだろ
854:デフォルトの名無しさん
08/05/03 23:45:43
>>852
やっぱりそうか
「独自実装」で一番最初に思い浮かんだw
855:デフォルトの名無しさん
08/05/03 23:48:08
>>853
何でって、昔は俺言語を作るのが普通だったから…
ガッコでコンパイラの授業あるだろう
856:デフォルトの名無しさん
08/05/03 23:48:17
J#あったなｗ
最後までJDK1.1(笑)互換だったけど騙されて使ってた会社は、
今もメンテで使ってるかもな。
857:デフォルトの名無しさん
08/05/03 23:50:58
授業で習って、その流れで俺言語作るのと、
実用のために俺言語作るのはわけが違うだろ常考。
どんだけの新言語がポシャッってると。
858:デフォルトの名無しさん
08/05/03 23:54:11
俺言語作るよりチャレンジングなのがC++のtemplate変態プログラミング。
859:デフォルトの名無しさん
08/05/03 23:55:29
ハードウェアとセットで囲い込むか、
マーケティング力が無いと無理だろうな。
そういう意味でRubyはすごいと思うよ。
Railsのおかげではあるけど。
860:デフォルトの名無しさん
08/05/03 23:55:35
実用の為の俺言語作ってる奴も多かったよ
ツール組み込みのマクロとか
861:デフォルトの名無しさん
08/05/03 23:58:29
マクロまでハードル落としたなｗ
そりゃマクロなら結構居るだろうさｗ
862:デフォルトの名無しさん
08/05/03 23:59:59
>>861
マクロっつってもフルセットの Scheme とかだぜ
まあ俺言語じゃないけど…
863:デフォルトの名無しさん
08/05/04 00:01:30
反応を見てると、やっぱり最近の人はそういうのやらないんだな…
864:デフォルトの名無しさん
08/05/04 00:05:39
俺の先輩は新入社員研修でCのコンパイラ作らされたって言ってたな
やっぱり文化が違うw
865:デフォルトの名無しさん
08/05/04 00:07:44
俺言語の話をしたいのか互換実装の話をしたいのかちゃんと絞ろうぜ・・・
俺も別に完全否定する気はないし、
小規模な俺言語（マクロ）
コンパイラが無いプラットフォームへの実装
標準についていく力がある組織による競合実装
なら十分有りだと思ってる。
C++の個人での俺拡張がありえないって言ってるわけで。
866:デフォルトの名無しさん
08/05/04 00:10:51
>>865
>C++の個人での俺拡張がありえない
俺もそう思うよ。腐った木に水やりをする人間はいないからね。
D や Java はそこら辺ちゃんと筋を通してる。
867:デフォルトの名無しさん
08/05/04 00:22:25
今日は入り浸りすぎたんで暫くレスを自粛するわ…
じゃあね
868:デフォルトの名無しさん
08/05/04 00:24:39
Javaはコンパイラ拡張が専門のPolyglotって実装があるよ。
C++はg++ベースが多い。例えばConceptGCC。
869:デフォルトの名無しさん
08/05/04 01:16:59
プログラム書くのにコンパイラの実装なんて気にする必要ないじゃん
つか、C++簡単だろう
わかんない、どんだけ低能なんだよ
870:デフォルトの名無しさん
08/05/04 01:20:55
簡単ではないだろう
STLからbostまでにどれだけの英知が必要だったか
871:デフォルトの名無しさん
08/05/04 01:38:30
>>870
それは別にC++が特別ではないだろ。
本格的な言語ならどれだって大量のリソースが注ぎ込まれているはず。
あと、使う方もC++が特別難しいとは思わないが、ほかが特別簡単とも思わない。
例えば、自分1人で作るプログラムなら当然C++は候補の1つ。
利点欠点を考え気分を加味して、C++が最良と思えばそれを使う。別のが良ければそれを使う。
872:デフォルトの名無しさん
08/05/04 01:50:00
程度問題だけど
標準ライブラリがあれほど言語の能力を使いきれてなかったのも珍しくない？
つまり標準化委員達にも把握できてなかったわけで
自分はC++を理解しているつもりだけど、本当はboostの先が果てしないのじゃないかと
873:デフォルトの名無しさん
08/05/04 01:56:03
そもそも標準ライブラリのbind.*とかが欠陥品だからなぁ･･･
874:デフォルトの名無しさん
08/05/04 01:58:11
かなり早い時期に作られたライブラリなんだから責めないで。
何年もの研究の成果があってこそのboostなんだし。
875:デフォルトの名無しさん
08/05/04 02:01:05
というわけで正しくC++を使うのは識者たちにも難しかった
876:デフォルトの名無しさん
08/05/04 02:13:02
正しくって？
限界まで、の間違いだろ
877:デフォルトの名無しさん
08/05/04 07:40:58
iostreamきもい
878:デフォルトの名無しさん
08/05/04 07:43:23
>>847
パソコンで箱売りされているソフトの大半がVCで書かれてますが？
879:デフォルトの名無しさん
08/05/04 07:49:17
土方の話はしてないからw
880:デフォルトの名無しさん
08/05/04 11:16:01
>>870
道具を作るのには英知が必要かもしれないが
道具を使うのには英知なんて必要ないだろうが
881:デフォルトの名無しさん
08/05/04 12:22:17
>>879
話を限定しないと、C++に大衆性が無いなんてトンデモ理論は
言い続けられないですもんねｗ
882:デフォルトの名無しさん
08/05/04 16:13:39
>>880
最近その言葉の意味を身をもって知ることになったんで同意する。
道具を使うのは簡単なんだよな。使い方勉強すればいいだけなんだし。
883:デフォルトの名無しさん
08/05/04 16:32:55
まぁ、使うのは作る知識の5%くらいは必要とかそんな感じなんじゃない。
その5%にも満たないという残念な実感、そんな経験が俺にもありました。
884:デフォルトの名無しさん
08/05/04 17:01:25
よく見ると>>2が痛々しいな
885:デフォルトの名無しさん
08/05/04 17:34:27
＞ 新総督はナナリーだよ！！！ ＜
￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ￣
_ - '´rニ- ､_ ノ}
／{／:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:￣._ﾆｱ ： , '´::::::::::::::::::::::::::::::｀丶、：
{:.:.| .:.:.:.:.:.:.:.:.:.:.:.:.:.:. :.ノl:.:.ヽ ： ／:::::::::::::::::::::::::::::::::::::::::::::::ヽ ：
__,>:.:.: .: :.:.l:.l:.:.l:.:.:.:.:. .: .ヽ､.:.:.＼ ： /::::::::::::::::::::::::::::::::::/::::::::::::::::::::', ：
∠_:.:.:.:.:.:.:.:.:.ﾉノ_:.`ﾆ=‐.:.:.:.:ﾊ:.ヽ:.:.:.:.ﾆ=- ： //::::l:::::::/:::::;/::/::::;ﾍ:::::::|:::::::::::::} ：
. |.:.:.:.:.|:.:.|:.:.|:.ゝゞ｀、:.:|:.|_}.:.|:.:.:.:..} ：／/::::::l:::::;ﾍ/, '/:/::/ ::::|:::::l:::::::::::::{ ：
. |:|.:.:.:.{:.:.{∨仁¨-､ヽ/≦ｿﾘ:.:i|ノ ： /|::::::l/（◯）, ､（ひ）::::ﾘ:/:::::::::::::l ：
ﾘ:.:（＼ヽ rr=-, r=;ｧ{:./´ ： .|ﾊ::|:::l"",rｪｪｪ､"" ::::::/::::::/｀i;':| ：
｀ヽヽゝヽ ￣ ￣ l:.ヽ､ ： l' |l:::! |,ｒ-ｒ-| :::::/;::::::;'_.'´ﾊ ：
∠_:..:.¨ヽ 'ｰ=-' ,ノ ￣ ： l;' ', ｀ﾆﾆ´ :::::/::／/:::/ ：
886:デフォルトの名無しさん
08/05/04 18:08:58
>>883
5%どころか0.05%ぐらいが妥当じゃないかと
887:デフォルトの名無しさん
08/05/04 22:22:26
>>880
残念だが、俺の作ったライブラリを使うには
とびっきりの英知が必要になるぞ
888:デフォルトの名無しさん
08/05/04 22:26:44
mb2sync乙
889:デフォルトの名無しさん
08/05/04 22:42:56
>>887
使い勝手が悪いってことじゃないかそれ。
890:デフォルトの名無しさん
08/05/04 23:25:02
>>887に英知が無いことだけは良く分かった
891:デフォルトの名無しさん
08/05/05 00:19:01
酷いネタにマジレスを見たｗ
892:デフォルトの名無しさん
08/05/05 10:27:56
レスを追ってて思ったんだが、
CのFree（）とC++のデストラクタとC#のDispose（）って具体的に挙動や用途としてはどうちがうの？
なんとなくはわかるんだが、正確にどういう違いがあるかわからん。
893:デフォルトの名無しさん
08/05/05 10:39:12
C++にはdeleteもあるぞ。
894:デフォルトの名無しさん
08/05/05 10:39:25
malloc して free しない →100%メモリリークする
new して delete しない →メモリリークするかどうかはケースバイケース
New して Disposeしない →メモリリークするが一部はガベージコレクションで救済される
895:デフォルトの名無しさん
08/05/05 11:25:11
ちょっと３レスに分けて書くよ。
＜C＞
・malloc() ：メモリ確保
・free() ：メモリ解放(mallocが再利用出来る。OSに返すとは限らない)
すぐ終了するプロセスは、大量に確保を
繰り返すもので無い限りfree()しなくても大丈夫。
長期的に動くプロセスはfree()を使わないと
malloc()で再利用出来ないため、問題となる。
ただし、mallocの実装によっては徐々に断片化してｵﾜﾙ。
なので、組み込みのようなものではmalloc系を使わない、
ページ単位で確保する処理でラップなどで対応。
896:デフォルトの名無しさん
08/05/05 11:25:40
＜C++＞
・new：malloc()して、それをthisとしてコンストラクタを実行
※厳密にはmallocとは限らない。
・delete：デストラクタを実行したあと、free()する
・デストラクタ：メモリ解放はしないけど、リソースの解放などをする。
なので基本的に呼ぶこと。
newを使用しない自動変数の場合は、
変数のスコープから出る際にデストラクタが呼ばれる。
リソースもモダンなOSはプロセス終了時に破棄するけど、
名前付き共有メモリマップのような
プロセスを超えて生存する仕様のリソースは当然残る。
897:デフォルトの名無しさん
08/05/05 11:26:06
＜C#＞
・メソッド内のusing：指定された変数が
usingのスコープから出る際にDispose()が呼ばれる。
・Dispose()：メモリ解放はしないけど、リソースの解放などをする。
なのでDisposableを持っている場合は基本的に呼ぶこと。
C#はGCがあるので放っておいてもメモリは解放される。
その前段でFinalizeが呼ばれるので、その際通常はDispose()が呼ばれる。
つまり明示的にDisposeしなくて呼ばれるが、
GCはコネクションプールの枯渇などを検知しないので、
メモリに余裕がある場合はいつまでもFinalizeも呼ばれず問題となる。
898:デフォルトの名無しさん
08/05/05 11:35:43
デストラクタはいるけど、deleteはいらないな。
899:デフォルトの名無しさん
08/05/05 11:39:44
そうだね
delete不要論はsmart_ptrによるRAIIのテクニックが広まった頃にC++プログラマは口々に言ってたよね
900:デフォルトの名無しさん
08/05/05 11:42:10
>>894
１行目をリークとするなら２行目も100%リークです。
３行目もおかしい。文脈的にはそのケースはメモリリークしない。
>>898
何で？
901:900
08/05/05 11:43:55
スマートポインタが内部的に呼ぶから明示的なdeleteは不要、
ということならおｋ。それなら同意なので。
902:デフォルトの名無しさん
08/05/05 11:51:30
ユーザコードでdeleteを記述したかどうかなんてのは、deleteの有無を論じる上で正確じゃない。
A * a = new A;
// iroiro
a->~A();
こんなコードを書く奴が出てきてしまうかもしれん。
903:デフォルトの名無しさん
08/05/05 12:07:00
>>902
しかし、
class A{
B *b;
public:
A(){
b = NULL;
};
~A(){
delete b;
};
void SetB(B *s){
b = s;
};
B *GetB(){
return b;
};
//色々な処理
}
というクラスの場合、
自分がnewしたからと言ってbを勝手にdeleteしちゃうと不味いよね
904:デフォルトの名無しさん
08/05/05 12:19:12
それただのクソコードじゃんｗ
どういう責任範囲か不明だし、Aが責任もつならSetBのときにdelete bだろ
905:デフォルトの名無しさん
08/05/05 12:21:21
newをユーザコードで直接使わずにfactory methodを使えと言うことですか
906:デフォルトの名無しさん
08/05/05 12:22:20
>>903
>>902のAの設計思想を知らんけど、Bの生存期間をAに移譲しないなら、
自分でdelete bに相当する操作を行うべきで、~Aにdelete bがあるのがおかしい。
仮に>>902のAをそのまま使うとしても、次のようなコードにするべきだ。
some_smart_ptr<A> a(new A);
some_smart_ptr<B> b(new B);
a->SetB(b.get());
// iroiro
a->SetB(NULL);
907:デフォルトの名無しさん
08/05/05 12:44:55
>>906
a = new A;
some_smart_ptr<A> b(a);
delete a;
908:デフォルトの名無しさん
08/05/05 12:50:13
>>907
何が言いたいんだｗ
バグを披露したいのか？
909:デフォルトの名無しさん
08/05/05 12:51:27
そこでGCだ
910:デフォルトの名無しさん
08/05/05 12:55:43
newしたらdeleteすべしと言うことは、>>907って事だろ
a->SetB(new B);
とどう違うのかって話にも取れるな
911:デフォルトの名無しさん
08/05/05 13:03:18
どんだけｗ
a = new A; //newしたら
some_smart_ptr<A> b(a); //deleteすべし
「明示的な」「責任」「生存期間」とか言い方はそれぞれだけど
>>899 >>901 >>902 >>904 >>906 は皆そういうことを言ってる
912:デフォルトの名無しさん
08/05/05 13:10:26
>>896
> ・delete：デストラクタを実行したあと、free()する
ちがうぞ。allocatorのdeallocate()を呼ぶ。
913:デフォルトの名無しさん
08/05/05 13:14:52
>>912
だから「※厳密にはmallocとは限らない。」って書いたんだけど・・・。
>>892向けに書いたから分かりやすいようにあえてそうしたの。
914:デフォルトの名無しさん
08/05/05 13:17:21
newも厳密に言ったらoperator newとか配置newとかあるしな
915:デフォルトの名無しさん
08/05/05 13:19:26
>>911
>>903コードだと、class Bは、class Aのプライベートなメンバーじゃん
class A以外で、*bをdeleteしちゃ不味いだろ、Aの生存期間が終了するまでの間にBを利用する可能性があるんだし
ゲタやセッタがあって、Aのコンストラクタでbをnewしないって事は、クラスBの派生クラスCを使う可能性だって考えられるし
916:デフォルトの名無しさん
08/05/05 13:21:52
>>911にclass Bなんか出てきてないけど。
917:デフォルトの名無しさん
08/05/05 13:23:30
>>916
>>903にでてるじゃん
918:デフォルトの名無しさん
08/05/05 13:23:55
>>913
malloc/free使う実装ってあるの?
919:デフォルトの名無しさん
08/05/05 13:27:32
>>915
> >>903コードだと
まだ>>903のコードのこと言ってると分かって軽くﾌｲﾀｗ
> プライベートな
privateだろうがset,getがあれば同じこと
> Aの生存期間が終了するまでの間にBを利用する可能性
>>904 >>906であるようにAの仕様が意味不明なので何とも言えない
> 派生クラスCを
Cを使っても問題無い（virtual ~B()でないのに継承してAに渡すのはただのバグ）
920:デフォルトの名無しさん
08/05/05 13:27:49
>>917
なぜ>>911に対してコメントしたの？
921:デフォルトの名無しさん
08/05/05 13:30:38
>>920
>>910への返答が>>911だから
922:デフォルトの名無しさん
08/05/05 13:31:55
>>918
あると思うよ。
923:919
08/05/05 13:33:41
>>921
ああｽﾏﾝ a->SetB(new B); のところはどうでも良すぎて無意識にスルーしてた
924:922
08/05/05 13:36:30
>>918
とりあえずVC++
URLﾘﾝｸ(okwave.jp)
925:デフォルトの名無しさん
08/05/05 13:42:05
a->SetB(new B)は駄目で、some_smart_ptr<A> a(new A)はいいって、どんなやねん
どっちもスマートポインタだろうがw
926:デフォルトの名無しさん
08/05/05 13:43:16
>>918
g++は下請のlibiberty/xmalloc.cからmalloc()呼び出してる。
libibertyは差し換えられるようになっているけれど。
927:デフォルトの名無しさん
08/05/05 13:48:46
＞どっちもスマートポインタだろうがw
＞Aの仕様が意味不明なので
とあるように、それならそうと始めから書いてくれないと。
>>903のようなコードからスマートポインタを
書こうとしたことを読み取るのは難しい。
分かってる人ならサフィックスに_ptr付けるとかする。
928:903
08/05/05 13:52:39
俺のコードですまんかった
C++覚えてまだ半年ぐらいで難しいことはわからん
ウインドウズ用のクラスライブラリ作ってて、MDIクライアントとかdeleteするのが面倒で、あんなコードをいっぱい書いてる
そっか、駄目なのか...楽でいいのに...orz
929:デフォルトの名無しさん
08/05/05 13:53:41
>>925
> どっちもスマートポインタだろうがw
分かんねぇよｗ
コンストラクタくらい付けろｗ
コピーされた場合もどうすんだよ
930:デフォルトの名無しさん
08/05/05 13:55:14
>>929
色々な処理に入ってるんじゃないの?
931:デフォルトの名無しさん
08/05/05 13:56:29
>>928
std::auto_ptr, boost::shared_ptrあたりの使い方を覚えるべき。
932:デフォルトの名無しさん
08/05/05 13:59:35
>>930
auto_ptrの仕様や、shared_ptr・weak_ptrが作られた理由は、
色々、で片付けられるほど気軽なものじゃないんだせ・・・。
933:デフォルトの名無しさん
08/05/05 14:05:27
＞ウインドウズ用の
まぁ今だったらマジでC#オヌヌメ
既存の資産もDLLにしとけばC#から使えるし。
934:903
08/05/05 14:13:05
>>933
大枠は既に出来て、あとは細かいコントロール類だけだから、今更C#を覚えるよりは速いかな
C++をマスターしたと思ったらC#も触ってみるよ
935:デフォルトの名無しさん
08/05/05 15:29:02
これらを元に考えると、 犯人は男、もしかすると女の可能性もあり。
年齢は10代～50代、あるいは60代以上。
身長は1m～2mくらい。
犯行は単独もしくは複数。
936:デフォルトの名無しさん
08/05/05 15:36:25
そして調査の結果、事故死であることが判明。
937:デフォルトの名無しさん
08/05/05 15:38:00
車の中でC#動いてたらイヤでしょ
938:デフォルトの名無しさん
08/05/06 01:14:19
>>937
バグでエンジンがかからなかったり事故を起こしたりしなければ別にどうでもいい。
939:デフォルトの名無しさん
08/05/06 01:20:41
プログラマって授業中にずっとノートにコード書いてたり、家でこそこそギャルゲ作ってて
将来のことで親と喧嘩して、ゲームとかソフトとかなにか作って食って生きたいって言うも、
そんな子供みたいなことをいつまでもやってるんじゃないって頭ごなしに否定されて
夜の街を彷徨って帰ってきたら、みんな寝てないみたいで、暖かいご飯が用意されてて、
おかんと「おとうさんが大事な話があるからって」「・・・うん」みたいな会話しちゃう生き物だと思ってたけど違うの？
940:デフォルトの名無しさん
08/05/06 01:27:21
>>939
それプログラマじゃなくてただの勘違いしたお子ちゃまだから。
941:デフォルトの名無しさん
08/05/06 07:06:03
>>939
そういう生き方でもいい。お前の人生なんだもの。お前の思うとおり生きれよ。
942:デフォルトの名無しさん
08/05/07 00:14:18
…といった具合にネタにマジレスしちゃうのがプログラマ
943:デフォルトの名無しさん
08/05/07 00:25:32
マジレスに見えるんだｗ
944:デフォルトの名無しさん
08/05/07 00:27:14
少なくとも>>941はマジレスじゃないだろｗ
945:デフォルトの名無しさん
08/05/07 00:27:51
被った・・・
946:デフォルトの名無しさん
08/05/07 04:01:18
…といった具合にネタにマジレスしちゃうのがプログラマ
947:デフォルトの名無しさん
08/05/07 05:21:21
C++と関係ない話題は他所でやれ
948:デフォルトの名無しさん
08/05/09 12:17:44
しかし、ベースになるクラスライブラリを作るのに、STL使えってのはどうなの?
むしろ、そういった物の場合は、vectorすらゆるさんぐらいで良いと思うが
949:デフォルトの名無しさん
08/05/09 14:10:30
vectorを許さないで俺vectorを書くんですね、わかります
950:デフォルトの名無しさん
08/05/09 17:28:18
自分の靴紐を持ち、上方にグイと強く引っ張ると身体が持ち上がります
次に反対側の靴の靴紐も同じ様に引き上げれば、宙に浮くことが出来ます
951:デフォルトの名無しさん
08/05/09 20:27:03
>>950
空飛べた！
サンクス
952:デフォルトの名無しさん
08/05/09 20:28:18
>>948
もちろんmalloc/free/printf/scanfも使わないんだよね？
対応するOSのAPIをラップするところから始めないと。
953:デフォルトの名無しさん
08/05/09 20:41:53
>>952
STL使う使わないとは関係ない話だけど、大抵のポータブルなライブラリでは
そこらへんはランタイムまかせにせずラップ関数を使ってるよね。
954:デフォルトの名無しさん
08/05/09 22:19:09
>>952
一歩間違えると、newやdeleteすら、オーバーロード無しには使えなかったりする環境もあるけどな
955:デフォルトの名無しさん
08/05/13 12:22:26
>>739
VB知らないから、的を外してるかもしれんが
AdaとかPythonは名前付きの引数使えるよ
956:デフォルトの名無しさん
08/05/16 06:37:04
D言語のテンプレート機構は、明示的なインスタンス化が必要になる代わりに、C++には出来ないようなことまで出来る。
それば事実なのだが、それがいいか悪いかは別問題である。思えばJavaやC#にもGenericsが導入され、いよいよ本格的に足並みをそろえた感もある。
また、やねうらおも通常はC++でテンプレートを用いてかなり複雑なメタプログラミングを行なうこともある。
しかしだ。やればやるほど、こういう方向性は根本的に誤っているのではないかという疑念をいだくようになった。
それぞれの言語がそれぞれの方法でテンプレートをサポートしたり、それぞれ異なる仕様のプリプロセッサを持っていたりするのは非常にばかげていると思う。
現実問題として、C++のソースをC#、あるいはJavaに移植しないといけないことがある。この逆をしないといけないこともある。
そういったときに、言語に依存する機能ほど移植を難解にするものはない。
その言語を使う限りは気持ちよくプログラミングできるのかも知れないが、そんなプログラムを移植させられる者はたまったもんではない。最近、それを特に感じる。
結局何が悪いかというと、Genericsやらメタプログラミングやら、プリプロセッサやら何やらかんやら。
そういったものは、言語間で共通するサードパーティ製のツールで実現するべきであって、決して、言語仕様そのものを改定すべき問題ではなかったと思うのだ。
たとえばmix-inにしても、AspectJ/C#/Cppを用いることで比較的すんなり実現できる。
言語そのものにmix-inを取り入れて、それをその言語のアドバンテージかのように言うのは、もういい加減やめにしないか？DbyC(design by contract:表明つきプログラム)にせよ、何にせよだ。
結局何が必要かというと、もっと汎用的なテンプレートやDbyCを実現するための、Aspectほにゃららをも包括するようなツールと、そういったツールを受容する言語側の仕組みなのだ。
決して、必要なのはGenericsでも何でもない。その言語にしかないような言語固有の機能なんてメリットでも何でもないのだ。いい加減、みんな早く目を醒ませ！
957:デフォルトの名無しさん
08/05/16 07:58:53
PL/1の夢、再来ですね。わかります
958:デフォルトの名無しさん
08/05/16 08:05:52
まぁ、俺も移植することあるから気持ちは分かるけど、
外部ツールで実現された場合、移植元と先の知識を持つ技術者も減ったりと、
移植は余計大変にならない？
そのツールがたまたま移植元と先を両方ともカバーしていれば
容易にはなるだろうけど。
それに、ソース生成系でなくても、
cfrontは例外が実装出来ずにティウンティウンしたし、
GCは言語・ランタイムのサポート無しでは完全な実装が不可能だしね。
※ Boehm GCはハックみたいなもの
あとC++,Java,C#のジェネリックは全然足並み揃ってないです・・・
959:デフォルトの名無しさん
08/05/16 08:51:10
>>958
> GCは言語・ランタイムのサポート無しでは完全な実装が不可能だしね。
> ※ Boehm GCはハックみたいなもの
「コンサバしか無理」と言えばいいのでは。
960:デフォルトの名無しさん
08/05/16 10:27:27
コンサバが何か分からずググちゃったよ・・・ｗ
「保守的GCしか実装出来ない」とは一度書いて消した。
そう呼びたくなくてね。
ハックみたいなもの、とやんわり言ったけど、
はっきり言うと俺はアレを「出来損ないGC」だと思っています・・・。
961:デフォルトの名無しさん
08/05/16 18:34:45
それにしても、C++の言語デザインは忌むべきものだと思う。
「Effective C++」や「More Effective C++」、あるいは「Modern C++ Design」、あと「Effective STL」有名なのが、この4冊。
あとARM(The Annotated C++ Reference Manual:注解C++リファレンスマニュアル)、それからFDIS(C++ Final Draft International Standard)
ついでに「Exceptional C++」とか「More Exceptional C++」とかもか。
プロのまともなC++プログラマならば、これらをすべて読んでいて然りだし、少なくともFDIS以外は精読していて然りである。
そうは思うものの、いま「Effective C++」やら何やらを読み返してみると、ホント頭悪いなぁと思う。
もちろん「Modern C++ Design」もだ。書いている人が頭が悪いと言っているのではない。
こんな解説書が必要になり、また必須であると思われている状況が、もうどうしようもなくやるせなくなるのだ。
こんな解説書が必要になるというのはC++の言語デザインの悪さゆえなのに。
「Modern C++ Design」を知らずしてテンプレートを語るなと言われる。確かにそうかも知れない。
この本以前のテンプレート批判は本当に的はずれだった。
かと言って、「Modern C++ Design」が珠玉のテクニック集か何かと思われている雰囲気、これがもうたまらない。
はっきり言って、こんなテクニックを理解する時間があれば、まともなコンパイラが実装できるのに。
そっちのほうが、何倍も有益で、普遍的なものなのに。
962:デフォルトの名無しさん
08/05/16 18:47:27
956も961も見覚えがあるんだが、いつどこでだったか思い出せない。
>>961
「C++の設計と進化」を追加。
そういうデザインにせざるを得なかった事情の一端が書いてある。
963:デフォルトの名無しさん
08/05/16 18:56:21
C++はともかくとしてJavaのGenericsは正直どーか？と思うが。
964:デフォルトの名無しさん
08/05/16 20:25:13
正直 C++ は酷いよなあ。
965:デフォルトの名無しさん
08/05/16 21:45:21
>>961
お前結構前で知識が止ってるよ。
試行錯誤時代の「Modern C++ Design」をそんなに熱く語られても。
966:デフォルトの名無しさん
08/05/16 21:46:37
上から目線ﾜﾗﾀ
967:デフォルトの名無しさん
08/05/16 23:11:25
ARM & FDISも今となってはC++03規格と0xドラフトに置き換えだな。
968:デフォルトの名無しさん
08/05/16 23:13:57
そして C++ は永遠に表舞台から消える訳か…
それ良いな
969:デフォルトの名無しさん
08/05/16 23:26:30
縁の下の力持ちとして生き続けるということですね、わかります
970:デフォルトの名無しさん
08/05/16 23:31:43
いや、どちらかというと蚊帳の外
971:デフォルトの名無しさん
08/05/16 23:31:54
>>967
ARMは規格と違ってannotatedの部分が面白いけど、D&Eに置き換えだね。
「オブジェクトモデル」に相当するのがない。
972:デフォルトの名無しさん
08/05/16 23:36:24
今北産業
973:デフォルトの名無しさん
08/05/17 00:01:05
>>972
言語に依存すると移植が大変
有名な本は全部読め
次スレ頼む
974:デフォルトの名無しさん
08/05/17 00:04:44
>>972
c++は言語オタが素人に本売るために複雑になっている
975:デフォルトの名無しさん
08/05/17 00:23:25
>>961
> はっきり言って、こんなテクニックを理解する時間があれば、まともなコンパイラが実装できるのに。
それは無いなぁｗ
976:デフォルトの名無しさん
08/05/17 01:15:56
VCが最後の砦という感じはする
977:デフォルトの名無しさん
08/05/17 01:17:36
Windows Universe ではそうかもしれんね
978:デフォルトの名無しさん
08/05/17 01:51:39
C++は最近使用範囲が広がってる感じがする
GoogleもMozillaも使っている
新しく始めるプロジェクトでC++を使えるのにCで書く必要はないのだ
名前空間と関数のオーバーロードがあるだけでかなりベターなCとして使えるのだから
もちろん主要なターゲット環境にCコンパイラしかないのならCを使うしかないが
979:デフォルトの名無しさん
08/05/17 02:01:54
Mozilla は昔からでしょ
Google は Java も Python も JavaScript も独自言語も使っているし
980:デフォルトの名無しさん
08/05/17 02:12:40
そうだよ
ネイティブコードを吐く言語としてC++を選択している
JavaもPythonもJavaScriptも使われる場面や用途が違う
981:デフォルトの名無しさん
08/05/17 02:20:40
でも Yahoo! の Hadoop とかは Java なんだよね…
982:デフォルトの名無しさん
08/05/17 02:28:35
そんな＞＜
983:デフォルトの名無しさん
08/05/17 06:05:50
名前空間はともかくオーバーロードはたまに困ったちゃん扱いされるじゃないか
ベターから外れる
984:デフォルトの名無しさん
08/05/17 12:29:03
JAVAそのものはC++じゃなかったけか?
985:デフォルトの名無しさん
08/05/17 12:44:06
C++を見捨てたというより、頭が悪くてC++についていけないだけの話だろ
986:デフォルトの名無しさん
08/05/17 13:48:25
>>985
残り少なくなった C++ 信者の脳内設定ではね。現実は真逆。
987:デフォルトの名無しさん
08/05/17 14:31:55
CとC++の中間に位置する言語があればいいのに。
988:デフォルトの名無しさん
08/05/17 14:39:00
中間もなにもC++でC++特有の機能を使わない様にコーティングすれば
済む話だと思うが。
989:デフォルトの名無しさん
08/05/17 14:47:15
C++の終わりなき拡張（でいいのかな？）のせいで
どんどんとっつきにくくなってるから
そろそろ現ANCI準拠のC++と今以上に拡張するC++は別物として扱って欲しい。
そんな俺は最近C++に触れ始めたC++初心者。
990:デフォルトの名無しさん
08/05/17 14:53:01
>>988
済まないからみんな困ってるんじゃないか
それで済むなら EC++ なんて作らないよ
もっと現実を直視しようぜ
991:デフォルトの名無しさん
08/05/17 15:41:22
ANCI
992:デフォルトの名無しさん
08/05/17 15:49:42
ANSIだったな。すまん
993:デフォルトの名無しさん
08/05/17 15:56:16
>>983
Cよりも新しい言語では関数のオーバーロードを許す言語は多いじゃない
そしてC++より新しい言語でも多いでしょ
言語設計者が有用であると判断しているケースが多いわけだ