C++0x 2

1 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:29:11 ] The C++ Standards Committee ttp://www.open-std.org/jtc1/sc22/wg21/ 前スレ pc11.2ch.net/test/read.cgi/tech/1149440647/ 809 名前：803 mailto:sage [2008/02/10(日) 17:01:20 ] >>807 参照型のメンバを持つpairだのtupleだのは、 代入演算子を持たなかったりswapが参照先を入れ換えちゃったりするわけで、 そういうものを「自然」に扱える必要はないでしょう。 810 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:08:36 ] >808 ＞C++98の考え方と全く違う異様な型推論 右辺値参照型をパラメタとする関数テンプレートの型パラメタの推論に関して 言及されてるならそれは同意します．もう template<class T> void f(T&&); の形は perfect forwarding のため (だけ) にあると理解したほうが早いと思います． 811 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:21:37 ] >>809 参照型のメンバを持つ pair/tuple における代入や swap の semantics がどうなるかは 従来から散々議論されているのは承知しています． 結論が出ているかどうかは知らないのですが． ただ，自分は forwarding などの局面で参照型メンバを持つ pair/ tuple を使うこと 想定してそういうものは自然に扱いたいという趣旨で発言しました． 誤解があるとあれなので補足しておきたいのですが， tuple<T1,...> はあらゆる型 T1, ... に対して代入や swap が well-defined である必要はなく， T1, ... に対してどういう操作が行えるかによって tuple<T1,...> に対して行える操作が限定される場面があっても構わないと思っています． そうしたときに，たとえば T1,... の一部またはすべてが参照型であるとき， tuple<T1,...> に対して値としての代入や swap を well-defined な形で提供するのは難しいですが， たとえば construction などは依然 well-defined に定義できますから， construction などしか行えない tuple を提供することはできます． で，そのような制限のかかった tuple でも forwarding などには十分使えますので それを自然に扱いたいという motivation は排除してほしくないです． 812 名前：デフォルトの名無しさん [2008/02/10(日) 18:36:30 ] やべぇ高度過ぎてわからん 813 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:07:34 ] へぼぐらまの俺にもいまいちわからん 0x の改修って一般のC++プログラマに受け入れられるのか？ なんか、実用する人たちから遊離した規格のような気が・・・ 814 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:16:39 ] >>813 そんなに大変な非互換性は取り込まれないと思うから、一般のプログラマは現状の 規格に不満がなければ気にしなくてもいいでしょ。 受け入れられるかどうかっていう点では、規格の変更に対応するかどうかという話で コンパイラベンダの反応が問題だと思う。 815 名前：803 mailto:sage [2008/02/10(日) 19:30:15 ] >>811 それを言い出したら、参照型メンバを持つpair/tupleにoperator=を定義したいとき T & && = T &&になっていれば mypair &operator=(const mypair &src) { first = src.first; second = src.second; return *this; } mypair &operator=(mypair &&src); { first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; } というふうに「自然に」定義できるよね、という議論もできる。 で、結局mypair<int, int>がPODになって欲しいという理由で 何らかのtraitsが必要になる、と。 816 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:37:26 ] ライブラリ書くようなエロいプログラマさんが頑張って書いてくれれば、 使ってる側からはあんまり気にしなくてもメリットはあると思う。 あと、この辺のおまじないは std::forward とか、std::move とかの裏側に隠されるし。 >808 >でも、だからといってT & && = T &のような直観に反する変換や どうなるのが望ましい？ その辺をおいといても、&? の方が明快なのはそう思う(これ static_cast も必要なくね？)。 やってること自体は今の && の反転みたいなものだし、ルール的にも決めるのはそう難しくなさそう。 欠点は &? が増えるってことだけかな？ 今更無理だろうけど誰か提案書いてくれw 817 名前：803 mailto:sage [2008/02/10(日) 19:51:49 ] >>816 型の一番右側に&&が付いていれば、オブジェクトを移動してほしくて わざわざ&&を付けたんだから素直に言うことを聞いて欲しい、と思う。 逆にT && &は(出現する場面を思い付かないけど)T &になってほしい。 > (これ static_cast も必要なくね？)。 { return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); } のこと？a1, a2という名前が付いた時点で左辺値になってるからstatic_castは必要。 818 名前：811 mailto:sage [2008/02/10(日) 20:08:33 ] >>815 ＞mypair &operator=(mypair &&src); ＞{ first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; } T & && -> T && という collapsing rule を仮定したときに， これがどういう意味で自然なのかいまいち理解できないです． おそらく template<class T1,class T2> class mypair{ T1 first; T2 second; ... }; という定義だと思うのですが， mypair のT1 が左辺値参照型であるとき， T & && -> T && という collapsing rule の下では first = static_cast<T1&&>(src.first); という構文が破壊的コピー (move) を呼ぶことになりますが， src.first は名前の付いた他のオブジェクトを指しているため，これはまずくないですか？ 819 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:46:28 ] >>813 いま問題になっている右辺値参照。 それによってもたらされる一般的なムーブ・セマンティクスは、 例えば関数の戻り値や、vectorで内部バッファリサイズ時の移動などといったときに 無駄なコピーの削減に役立つ。 ＃もちろんそれだけにとどまらないけど、それはとりあえず置いておく。 820 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:53:55 ] で、何が言いたいかって、各人がほっといたって、 ライブラリの中の人が頑張るために使うから、 気付かぬ内に恩恵を被るかもしれないよってこと。 821 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:12:29 ] move　semanticsなんて全コンテナ修正だな T&&のオーバーロード足すだけでいいのかな 822 名前：803 mailto:sage [2008/02/10(日) 21:23:32 ] >>818 mypair &operator=(const mypair &src); mypair &operator=(mypair &&src); という一般的なオーバーロードを前提にすれば、 後者が呼ばれるのは故意にmoveする場合に限られる。 だから名前の付いた他のオブジェクトをmoveして正解。 823 名前：803 mailto:sage [2008/02/10(日) 21:26:48 ] ごめん大嘘。関数の戻り値として参照を含むmypairを値で返されたら 後者の方にマッチしちゃう。これは確かにまずい。 824 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:53:55 ] アクロバティックな性体験を体験した美少女中学生のような気分になった 825 名前：デフォルトの名無しさん mailto:sage [2008/02/10(日) 23:36:37 ] 同じくヘボグラマの俺には、辛うじて意味は分かってもどうしても内容に関しては受動的にならざるを得ない。 826 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:24:55 ] そろそろ移動するべきかなぁと思ったのでこっちで。 【C++】STL（Standard Template Library）相談室 8 pc11.2ch.net/test/read.cgi/tech/1198435319/843 でオーバーロード面倒という声があったけど、場合によってはこんな風にできるかも。 Widget func(const Widget&, const Widget&, const Widget&); // move しない // helper 実際には Variadic template 化？ template<typename T0, typename T1, typename T2> Widget&& select(T0&& t0, T1&& t1, T2&& t2, std::enable_if<!std::lvalue_reference<T0>::value || !std::lvalue_reference<T1>::value || !std::lvalue_reference<T2>::value>>::type *dummy = 0) {   return !std::is_lvalue_reference<T0>::value ? std::move(t0) : !std::is_lvalue_reference<T1>::value ? std::move(t1) : std::move(t2); } template<typename T0, typename T1, typename T2> Widget&& func(T0&& t0, T1&& t1, T2&& t2) {   Widget& w = select(std::forward<T0>(t0), std::forward<T1>(t1), std::forward<T2>(t2)); // w に対する処理   return std::move(w); } あんま自信ないけどどうだろ？ 827 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:39:30 ] ムーブコンストラクタの呼び出しが最適化で削られるなら いいのかなあと思った。 828 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:52:27 ] >>826 func の return 文の std::move は不要では？ >>827 move constructor は副作用を持つでしょうから これを参照で返すのと同じにまで最適化するのは結構厳しい要求かと 829 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:55:27 ] 結局そんくらいのコストは勘弁してやれ、 それが嫌ならオーバーロードしろ、ということか。 830 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:01:51 ] move は一般にリソースの確保・解放を伴わないでしょうから， そこまでシビアに move が重くなる状況はあまりないとは自分も思うのですけれど． ただ std::string においては，例えば短文字列最適化を採用していると move を使っても内部の文字列のコピーが発生するので， 4つのオーバーロードをまともに書く意義はあるのかなぁ，と． それに4つのうち2つは他の実装に forward すればよいだけですし そこまでオーバーロードが苦になることもないかと． 831 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:14:22 ] そういう引数が４つあった１６個か。 832 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 02:31:49 ] Boost.Operatorsに期待。 833 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 19:43:22 ] 引数に関して言えば、 右辺値参照なんてものを導入するより、 右辺値→左辺値 変換演算子を導入した方がいいと思う。 どうせ戻り値はテンポラリオブジェクトとして作成されてて、 基本型でもなければ大抵メモリ上にあるわけで、 内部的には変換なんて行う必要はないはず。 基本型とかなら、テンポラリオブジェクトを作成して、 そのテンポラリオブジェクトへの参照を返せばいい。 const 参照へならここら辺勝手にやってくれるけど、 非 const 参照へもできる手段を与えてやるって感じ？ 自動的に変換されるのはおそらくマズそうなんで、 キャスト演算子の導入でなんとか。 834 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:09:34 ] 突発的！ちら裏!! １、SingleInt型かByte型を導入してくれ。。。 char型はiostreamで文字として解釈されてすごい不便。俺は文字じゃなくて１バイトの数字を書き込みたいんだ。。。 バイナリ指定してるはずなんだけどなぁ。@VC ２、Enumの名前ちゃんと考慮してクレイ。名前何のために付けてるんだか。。。 2種のEnum宣言したときの別々なのにメンバの多重定義できなくてメチャクチャ不便だ。 片方に宣言してもう片方に設定しようとすると型変換エラーでるし。 ゲームでステータス設定するときEnum重宝するんだがなぁ。 835 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:14:32 ] 2の方はC++0xになかったっけ enumにスコープがつくはず 836 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 04:11:22 ] charとsigned charとunsigned char 837 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 13:06:58 ] >>836 みんなbasic_istream/basic_ostreamに対するoprator >>/operator <<が定義されている。 838 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 14:01:38 ] >>834 ios::binaryってことじゃなくて？ 839 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 17:09:44 ] >>835 おぉ、ありがたい。 >>834 一応ｙってみたけど、なんか意図どおりにならなかったなぁ。 自分の不具合かもしれんが。。。 840 名前：839 [2008/02/22(金) 17:11:18 ] ミス。 >>834じゃなくて　>>838 841 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 18:14:50 ] foo(lvalue_cast(bar())); 842 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:42:00 ] integer semantics 843 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:55:46 ] template <typename T> 　T& lvalue_cast(const T& rvalue) { 　return const_cast<T&>(rvalue); } 何だ。今の C++ でも書けるじゃないか。 当然文をまたいで使う事はできないが、 move semantics なんて無くてもいいんじゃないか？ 844 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 21:30:21 ] >>843 ムーブとコピーの区別が付けられなくないか？ 845 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:12:30 ] >>844 引数は const 参照だが、 あくまでこれはテンポラリオブジェクトを作成するためのものであって、 引数には左辺値を渡してはいけない。 あくまで右辺値を左辺値に変換する際にしか使わない。 さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？ 846 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:17:36 ] いや待て。 別に左辺値を渡してもいいのか。 単にそれがそのまま返されるだけで。 const な左辺値を渡してはいけない、だな。 847 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:26:40 ] >>845 ごめんわからない。例えばこういう区別はどうなるの？ class Hoge { public: Hoge(const Hoge&); Hoge(Hoge&&); }; Hoge f(); Hoge x; Hoge y = x; //コピー Hoge z = f(); //ムーブ 848 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:30:08 ] >>845 ＞さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？ やめたほうがよいです．左辺値と右辺値の識別を現行規格でやろうとすると 非常にわずらわしいことを考えないとならないです． 個人的に徹底的に試行錯誤した経験があるんですが， 現行規格で右辺値・左辺値識別を行うのは自分としては絶対にお勧めしません． 実際やってみれば理解してもらえると思うのですが，たとえばGCCの実装における 現行規格の8.5.3/5の解釈にブチ切れたりすることになったりします． 一応，下の提案さえ通ればライブラリレベルで move を実装することはできますが…… www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html 849 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:32:23 ] ごめんHogeの定義こっちにしておく。 欲しいのは、右辺値を参照にすることじゃなくて、ムーブセマンティクスそのもの。 class Hoge { public:   Hoge(const Hoge& y) : p(new int(*y.p)) {}   Hoge(Hoge&& y) : p(y.p) {y.p = 0;}   Hoge() : p(new int) {}   ~Hoge() {delete p;} private   int* p; }; 850 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:42:47 ] >>847 俺の案は RVO されることを前提としてるから、 ムーブなんて無くても十分ということになる。 面倒くさいから RVO を規格で要求したら？ とさえ思ってる。 851 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:48:40 ] >>848 識別は難しいのか・・・。 852 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:51:55 ] なるほど。 でもそれだとbindなんかで呼出時に右辺値を直に引数にできないのは 解決できないように見える。 lvalue_castがあるって言うのかもしれないけど、 それだったら今でもboost::crefを使えば引数に渡せる点で同じと思う。 853 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:54:11 ] まあ、実際の所現行規格で別に実現できなくてもいい。 && を単項演算子として、それを頭に付けるとかいう言語拡張でも。 854 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:14:35 ] 何でもかんでもオーバーロードで解決すべきかってのは微妙な所で、 ２つの関数を実装させる手間、 いや、複数引数があれば４つ、８つと指数関数的に増えていく手間がかかってしまうのは かなりの問題だと思う。 右辺値参照を導入するとしても、 オーバーロード不要の代替案は用意した方が良さげ。 855 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:18:34 ] それはもう variadic template で書いてしまって， 意図しない呼び出しを SFINAE と deleted function 宣言で阻止してしまえば いいんじゃないですかね 具体的にどういう複数引数関数書きたいのかによりますけれど 856 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:23:02 ] テンプレートは export が実質使えなくてヘッダに実装せざるを得ない以上、 使う必要の無いところでなるべく使いたくはない。 857 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:24:31 ] だが、もはやテンプレートのないC++も使いたくない。わがままだ。 858 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:27:29 ] ムーブは無駄なコストが発生する上に RVO みたいな最適化もできなさそうなのがな。 pimpl 使えばポインタの移動だけでいいから まあ大したコストでもないのかもしれないが・・・。 859 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:33:33 ] boost::noncopyable の他に boost::nonmovable も必要になるのかな 860 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:46:03 ] 非const参照に右辺値を渡せちゃう処理系もあるから、 いらぬお世話って思ってる人もいるかもね。 861 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:48:30 ] >>858 pimplでなくとも、ポインタくらいのやり取りですむ（深いコピーが発生しない） ってのがムーブの売りだろ。 862 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:49:19 ] RVO で済む状況なら、RVO はコスト０だぜ。 非０は０には敵わない。 863 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:51:02 ] メンバが５個くらいあったら５個ムーブする必要がある。 １つ１つはポインタくらいのやり取りでも、 個数が増えるとバカになんないかもしんない。 864 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:59:18 ] んー，別に move を導入しても RVO が適用できる場面では依然 RVO が適用されるでしょうから， たとえば>>858さんが何を問題にされているのかいまいち把握できていないんですが…… もう少し詳しく教えてもらえると個人的にはうれしいんですが． 865 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:02:44 ] 実際、このコードだとconceptg++では全くムーブ発動しない。 $ conceptg++ t.cpp && ./a constructor: 0x22ccd0 destructor: 0x22ccd0 #include <iostream> using std::cout; using std::endl; struct hoge { hoge() : p(new int) {cout << "constructor: " << this << endl;} hoge(hoge&& r) : p(r.p) {cout << "move constructor: from " << &r << " to " << this << endl; r.p = 0;} ~hoge() {cout << "destructor: " << this << endl; delete p;} private: hoge(hoge const&); //今回使わないので int* p; }; hoge f() { hoge obj; return obj; } int main() { hoge t = f(); } 866 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:04:02 ] RVO と右辺値→左辺値変換さえあれば、 文法を複雑にし、コストを必要とし、ライブラリを大きく書き換える move とやらを導入する積極的な理由はないんじゃないの？ という話。 867 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:05:26 ] RVO を規格で保証してないのに理由とかあるの？ コンパイラの実装コストの問題？ 868 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:16:45 ] >>866 関数からの戻り値のコピーを排除するのは move の応用の1つに過ぎないです． RVO は return と throw に限定された話ですけれど， move はより広い文脈 (たとえば std::vector におけるバッファの再配置) でも きわめて重要な意義を持つ操作で，これは RVO 云々では取り扱いきれないように思います． それから ＞コストを必要とし、 の部分は，上にもありますけれど， RVO が適用できてコストがかからない部分では move が導入されても依然 RVO が適用されてコストがかからないようになると 思われますので， (ただし，これはあくまでコンパイラの実装如何ですが) RVO と move を比較してどのコストを憂慮されているのかがちょっと理解できていないです． 869 名前：852 mailto:sage [2008/02/23(土) 01:19:43 ] >>866 俺の話はどうしてくれるの？ いや、このためだけに言語を大きく拡張する価値はないと言いたいのか。 870 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:20:15 ] だから、右辺値を非 const 参照に渡すまともな手段は用意されてるの？ って話。 871 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:21:01 ] >>869 それが lvalue_cast じゃないの？ 872 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:02:07 ] あと、RVO が規格で強制されるものではないという点も。 873 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:22:09 ] 右辺値左辺値判定、こりゃ確かに無理だな・・・。 874 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 04:42:12 ] >>870 「まとも」とか変な基準を持ち出すなよ。 875 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 05:25:18 ] >>859 move 系コンストラクタや代入演算子が自動生成されないなら、要らないと思うんだけど、 こいつらもコンパイラが勝手に作っちゃうの？ 876 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 10:52:20 ] d = move(s) の途中で例外が起こった場合、sとdの状態はどうなるんだろうか？ std::vectorの再配置にしても例外安全の強い保証 (メソッドの途中で例外が発生してもオブジェクトの状態は以前と同じ) を行うなら、結局 　１、新しいバッファを確保 　２、それにすべてのオブジェクト内容をコピー 　３、バッファ作成に成功したら、ポインタの挿げ替えを行う 　４、古いバッファの削除 という手順を踏む必要があるんだけど・・・ 　１、新しいバッファを確保 　２、オブジェクト内容をmoveで移動 　３、ポインタの挿げ替え＆古いバッファの削除 とやってしまうと２の途中で例外が発生したときまずいことにならないか？ 877 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 11:38:09 ] swapみたいにmoveコンストラクタは例外の非送出が必要ということになっていると思う。 878 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 13:14:28 ] >>875 いえ，今の提案では move constructor や move assignment は自動では生成されないことになってます． >>876 move で強い例外安全性の保証を行おうとすると， move の rollback 操作が move そのもので，これが例外非送出でなければならないため， 結局 move 自身が例外非送出である必要が出てきます． 879 名前：デフォルトの名無しさん [2008/02/27(水) 10:58:47 ] C++の標準外のライブラリが破綻する最大の理由は ライブラリ作成側が守るべきプログラミングモデルをユーザに示さないからだよ。 コードから読み取れるモデルでなく、 モデル宣言をするべきなんだよ。 その完全性を支援するためにコンパイラがそれによって挙動を変えてもいい。 最初は完全なるOOを実現しているように見えた。 しかし、あるバージョンではマルチパラダイムに変身し OOの完全性を崩壊させるとかNe-Yo。 880 名前：デフォルトの名無しさん [2008/02/27(水) 14:10:39 ] こないだ STL スレで挙がった話なんだけど、 copy_if() がどうなってるかだれか知らない？ 未だにドラフトにも載ってないんだけど。っていうか 2003 の改訂で入らなかったのはなぜ？ 881 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 15:57:01 ] >>880 禿がまた忘れたんだろ 882 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 19:25:26 ] rangeがどうなるかだな 883 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:25:33 ] >>879 どっちかというとOOの世界に土足で上がり込もうとした 総称型プログラミングの要素の側が勝手に苦労してるだけに見える。 継承使ったら型推論できませんとか暗黙のキャストができませんとか。 マルチパラダイムになってOOサイドで何か問題起きてる？ むしろコンテナみたいな値系オブジェクトを下のレイヤに追い出すことで、 OOを純化できると思うんだけど。 884 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:46:38 ] 完全なOOとか、OOを純化とかには興味無いんだと思うよ。ｗ 一言で言えば「宗旨が違う」 885 名前：デフォルトの名無しさん [2008/02/28(木) 00:09:21 ] C++はOO側が極端に少ない＝OOが蔑ろにされる という構図がある。 つまり、そのときOOが成立するコードという理由で OO前提のコードを書いてしまうと 将来OO否定派が紛れ込んだときに混乱の元になるということ。 886 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 00:10:53 ] >>885 ３回読んだけど意味が判らん 887 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 01:37:54 ] 対立問題にしてどうしたいんだ 888 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:12:14 ] "virtual"を標準ライブラリから検索してみれば OOはC++自身に拒否されていると分かる 禿げ涙目である 889 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:25:52 ] >>887 勝利したいんだろ ほっとこうぜ 890 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 11:55:41 ] ふむ。OOをNGワードに登録、と。 891 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 12:44:18 ] WO 892 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 00:48:00 ] 元々何の信念もなく便利だからって適当に機能ぶちこんだだけのグチャグチャ言語に 今更何を言ってるんだ 893 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 01:03:24 ] >>892 馬鹿にされるから他では言わないほうがいいよ、その脳内C++ヒストリー。 894 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:19:46 ] そうですか じゃあこのC++と呼ばれる雑多にぶち込まれた大量の機能が お互いひどい副作用を起こし合ってるグチャグチャ言語は 一体どんな高尚な理念で作られたものなんですか 895 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:32:47 ] DnE 読んどけ 896 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:18:54 ] 無知ゆえに思い上がった口をきく若いオタクが興奮すると、文体似るよな、どういうわけか。 897 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:54:17 ] C++を雑多と呼ぶのはよした方が良い。 JavaやRubyなんかと違って、ここまで基本的な部分から整合性の練られた言語は他にない。 多くの機能は基本的な構文から基本的に導出されるが、JavaやRubyはそれらのプロセスを すっ飛ばして機能が実装されている事が多く、とても自由と小回りの利く言語じゃない。 898 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 04:25:57 ] Javaは曲がりなりにも「現実世界で、現実をどうにかするために」歩みを進めてきたけど、 Rubyは話にならない。現実よりも白昼夢のほうが大事な、言語オタの妄想の産物。 前線には一切出ず、安全地帯で仲間とダベりながら延々「クールな匍匐前進」を模索してる兵士が、 「俺はこの最高の匍匐前進でこの戦争を生き抜いてるんだ」って真顔で言い張ってるみたいな言語。役立たず。 899 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:02:14 ] という話はスレ違いなのでよそでやろうな。 900 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:27:54 ] 技術レベルの低い話は華麗にスルーしましょうよ。 規格ドラフトを読むような人が集まってんだからさ。 901 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 09:52:56 ] 糞してくるわ 902 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:34:26 ] スルーなの? 具体的にどのようなひどい副作用があったのか聞きたいんだが 903 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:41:11 ] >>902 妄想を聞きたいならせめてマ板でやってくれ。 904 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 11:34:16 ] いい糞出たわ 905 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 12:28:11 ] 895 もかいてるが、Design&Evolution of C++ を読んでから出直してこいとしか言い様がない 906 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 13:20:10 ] ちゃんとした本を読むと、最初の意見（>>892）を変えなきゃいけなくなるから、 ここで文章の素人達に不完全で不足の多い文章を書かせて、それに向かって そんなの信念があるうちに入らない、適当でしかない、と言って初期設定を維持するつもりなのでは。 907 名前：デフォルトの名無しさん [2008/02/29(金) 14:21:08 ] ミスを犯すのは常に人。 初心者にはそれがわからんのです。 908 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:53:25 ] 同じ予約語に3つも4つもまったく違った意味を与えたり 機能を作るたびに別の目的に悪用されて、同じような機能を何度も付け足す羽目になったり 無節操に記号に新しい意味を与えまくってパースを複雑怪奇にしたり わざとミスさせようとしてるとしか思えませんが 909 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:55:11 ] マジレスすると無節操に記号に新しい意味を与えまくってもパースは複雑怪奇にはならない。 910 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:06:13 ] 例えば不等号なんぞを無理矢理カッコ的なものに仕立てたせいで どれだけの脳内パーサが誤作動してると思う？ includeで使ってるからってなんも考えずにプリプロセッサの世界からコンパイラの世界に 持ち込んだバカのせいじゃないか 違うか 911 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:08:29 ] 無知なまま何を「思っ」たところで的外れなだけだから、 無知でなくなるための行動を起こすべきだろうね。既に本も薦められているのだし。 「何故それはそうでなければならなかったのか」という話に関して、 C++ほどシリアスでプラグマティックな内容盛り沢山の言語もそうは無い。 他の言語が「だってそのほうがきれいなんだもん」くらいの理由で決めちゃうところでも、 C++は「現実」を相手に、全然別の戦いをし続けてきたからな。 今の君の頭からは、>>892を裏付ける話は一切出てこないから、マシな頭になる努力をまずしよう。 912 名前：デフォルトの名無しさん [2008/02/29(金) 18:11:01 ] 何も考えていないことにしたい人が 考えの跡をしこたま記した本をこわがってるスレはここですね 913 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:15:41 ] じゃあ何をどう考えてるのか教えてくれよ 例えばstaticという語がバラバラのまったく違う4つの意味を持っていた方がよいと考えた理由教えて その本に書いてあるんだろ 914 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:21:40 ] ああ、これが>>906の読んだ展開か 915 名前：デフォルトの名無しさん [2008/02/29(金) 19:09:57 ] >>911 Javaやスクリプト言語は「現場の実情」に応える方向で発展したけど、 C++はそれ以前に「数学的現実」に足をすくわれ続けているような。 slice_arrayが動かないとかvector<bool>がコンテナじゃないとか。 テンプレートなんて、パースできなくてtypenameキーワードなんてものが 必要になった時点で常識的には破綻したというべきだし、 チューリング完全性が明らかになった時点でもう一度破綻している。 こうなるくらいだったらC++コンパイラにMLインタプリタでも組み込んだ方がマシ。 916 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:17:25 ] >>913 残念ながら、無名名前空間でファイルスコープのstaticを排除して、 C++のstaticは静的メンバという意味しか持たないようになったという流れなんだが。 917 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:30:19 ] >>915 ＞テンプレートなんて、パースできなくてtypenameキーワードなんてものが ＞必要になった時点で常識的には破綻したというべきだし、 これは理解できるとして ＞チューリング完全性が明らかになった時点でもう一度破綻している。 こっちはなぜ？ 918 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:51:55 ] メタプログラミングなんて邪悪だしJavaに無いし要らないってこと。 C++ の利用者は喜んで便利に使ってるが、それはそいつらが悪趣味な せいであって、断じてテンプレートの利便性を証明するものではない。 919 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:53:11 ] テンプレートはあくまでもジェネリクス用の構文であって ありとあらゆることに悪用できる万能の箱として用意されたものではないだろ C++マニアはそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではgoto文と大して変わらん メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか 920 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:20 ] テンプレートメタプログラミングは「発見」されたのだ！とか誇らしげに言ってるC++信者とかたまにいるけど それって結局は自分らが加えた仕組みが何をもたらすのか、誰もわかってなかったってことじゃないの あ、C++は全てにおいて考え抜かれた言語だから当然DnEには想定の範囲内だったと書いてあるんですよね ｻｰｾﾝ 921 名前：デフォルトの名無しさん [2008/02/29(金) 19:59:29 ] テンプレート、ポインタ、動的確保はgotoと同じく排除しよう 現物使用は避けるべき STLを主軸に据える 922 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:49 ] あんまり本気で主張するつもりはないけど： Javaのバイトコードは本来ポータビリティのためのものであって、直接バイトコードをいじって なんでもできる万能の素材として用意されたものではないだろ DI 信者はそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではアセンブラと大して変わらん メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか という状況と対比するとC++の方がまだ健全に思える。 923 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:02:05 ] >>921 矛盾していないか？テンプレートとSTLとか。 924 名前：デフォルトの名無しさん [2008/02/29(金) 20:05:36 ] 現物 = テンプレート、ポインタ、動的確保 ラッパー　= STL 925 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:05:38 ] try-catch文の醜悪さに比べれば、丁寧に書かれたgoto文の例外処理の方がずっと読みやすいし美しいと思う ごめん関係なかった 926 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:06:49 ] >>919 Cのプリプロセッサでジェネリクス実現しちゃう人だっていたんだから、 C++でそれ用の構文を用意したのは一歩進化だろ。 C++0xでconstexprも用意されたし、さらに一歩前進してるじゃないか。 なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。 927 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:42:43 ] >>919 >メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか shiroさんも最近似たこと言ってたね。 ttp://reddit.com/info/62o9s/comments/ ＞Lispマクロを言語に入れない理由として、 ＞よく「文法が変わるから他人の書いたコードが読めなくなる」と言われますが、 ＞カンマ演算子をこんな使い方したらもう充分読めないでしょうってことです。 928 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:43:47 ] >>926 > なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。 限界を試すのは重要と思われ。 ジャンボジェットのお披露目でバレルロールだっけ？　やっちゃったテストパイロットみたいに。 それをプロダクトに積極的に使おうとかやりだすと、ちょwww だけど。 929 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 21:24:04 ] >>920 ちょっと論点のずらし方が卑怯すぎて気持ち悪いなぁ、君は。 DnEが証明するのは、「何も考えていないわけではないこと」であって、「すべてを考えていたこと」ではないよ。 そして、少しでも「考えていたこと」があれば、>>892が馬鹿なことを言っていたことになるのを、忘れちゃダメだよ。 930 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:32:22 ] C++でgotoなんて危険すぎて使えんわ。 そのための例外なのに。 931 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:39:45 ] お前は全国の後藤さんを敵に回した 932 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:40:48 ] gotoさんの髪茹でたい 933 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:59:39 ] ここってなんのスレだったっけ？ 934 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:07:04 ] 次スレ建てました pc11.2ch.net/test/read.cgi/tech/1191754720/ 935 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:11:43 ] >>933 美少女中学生が顔を赤らめながら指の隙間からチラチラと覗くスレ 936 名前：デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:34:59 ] 大体他人が自分自身と一緒にPCを見ていなければ、顔は赤らめても赤らめなくてもどうでも良いけど 恥ずかしがって指の隙間から顔を隠しつつ見なくてもいいだろ。 最近の子供は意識の根底に公私混同が見られて将来が危ぶまれるな。本当にしっかりしてほしい。 937 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 01:30:58 ] まあ、繰り返しになるが、DnE 読んでから出直せとしか言い様がない。 あれは C++ 信者でない人にとっても、どのような方針で言語を拡張していくと こういうトンでもないことになってしまうのかという様子が詳細に書いてある という点で非常に勉強になりますよ。C++ スレで煽るためにも、 すぐ反論されないように基礎知識を磨いておくことも重要です。 まずは敵を知ることからです。 というわけで DnE 読んでから出直してください 938 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:04:38 ] 了解です。 939 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:33:45 ] try節ローカルなオブジェクトをcatch節で見られるようにさえなれば何でもいいよ 940 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:35:39 ] それは同意 Hoge* p; try{ p= new Hoge(); }catch(){ } とかダサすぎる pそこに置く意味ねぇだろと 941 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 03:29:56 ] >>939-940 try{ Hoge* p = new Hoge(); }catch(){ } 仮に catch の中で p が見れたとして、 new Hoge() から例外が飛んだ場合は p の初期化が済んでないわけだが、そんなものを見られるようにして何に使うの？ 942 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:44:04 ] >>941はわざとか？天然か？ 943 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:54:03 ] これがポインタではなくデストラクタのあるクラスのインスタンスだと考えると スコープの差異による影響は? 944 名前：デフォルトの名無しさん [2008/03/01(土) 09:59:01 ] 確かに>>940は例が悪いな 945 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:10:34 ] 例が悪さが、他人の頭の悪さを引き出したケース。 946 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:32:56 ] 初心者スレ行けと 947 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:00:25 ] 上の例ならスマートポインタ使うよな。 948 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:36:38 ] ぬるぽ 949 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:54:46 ] 華麗にスルー 950 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:55:59 ] >>941 using { 　Hoge* p = NULL; } try { 　p = new Hoge(); } catch(...) { 　// p を使用 } こうすればいい。 951 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:56:52 ] 突っ込んじゃ負けとかいうゲームですか？ 952 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:00:30 ] コンストラクタの中で例外を投げるなんて変態すぎる。 953 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:01:36 ] RAII全否定ですか 954 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:00 ] >>952 m9（＾Д＾）ﾌﾟｷﾞｬｰ www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html 955 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:10 ] RAII（）笑 956 名前：952 mailto:sage [2008/03/01(土) 20:05:55 ] (´；ω；`)おっおっううぇああぁああぅぅおぉぉおお 957 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:09:17 ] C++ ならデストラクタ使えよってことなんだろう。 958 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:10:34 ] >>956 お前はたぶんオレと同じスレをみている さぁガイドライン板に帰ろう 959 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:15:25 ] 泣いたらスカッとしました。 960 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 21:44:46 ] 関係なかった俺まで泣いた 961 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:30:37 ] >>954 切られている「比較的有名なサイト」ってこれだよね、たぶん。 C MAGAZINE - プログラミングの禁じ手Web版 C++編 ttp://www.cmagazine.jp/src/kinjite/cpp/ 適当にうろうろして見たところ、参考にしている人がそれなりにいる様子。 初心者が鵜呑みにするとまずいことを広められるのは困るなー。 962 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:41:02 ] C編はいいんだけどね 963 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:03:15 ] これ訂正してもらえないの？ いつまでもWeb上に残ってると勘違いするやつが後を絶たないと思うんだけど。 特にポインタのメンバが不定値になるとか、初期化子も知らないような書き方だし。 それともCマガの中の人は確信犯なんだろうか。 964 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:28:38 ] エキスパートなお前らの間ではコンストラクタで例外投げてもOKって判断なの？ 965 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:30:54 ] 自分では投げない場合も、投げられた場合への配慮は必要 966 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:32:30 ] >>963 糞ページ、糞本認定だけでいいじゃん。 それだって初心者スレでやるべき事だし。 >>963 初心者スレ行って教えて貰ってこい。 967 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:33:16 ] オブジェクトの構築に失敗したのに例外を投げないコンストラクタを持つクラスなんて、 初心者には使わせたくないな。 968 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:35:23 ] どっかの腐ったフレームワークの悪影響だろうね 969 名前：964 mailto:sage [2008/03/02(日) 01:41:54 ] 例外を投げないような初期化だけをコンストラクタでやって、 Initialize()とかのメソッドを作ってるんだけど。 なんだ、じゃぁ俺もバンバン例外なげるようにするよ 970 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:51:53 ] >>969 今までそう作ってきたなら、あえて変える必要は無いんじゃない。 問題なのは、「安全な処理のみでコンストラクタを実装していること」ではなく、 「安全でない処理に失敗したときに例外を投げないこと」なのだから。 971 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:53:18 ] 今気づいたけどスレ違いだな 972 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 08:25:21 ] うっすらと恥ずかしい毛が生えてきた美少女中学生のスリット違い 973 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 10:47:13 ] 古いんだよなアレ今となっては。著者が表に出る活動を凍結してるせいも あるんだろうが。 974 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 15:29:11 ] RAIIイディオムが一般的じゃなかった時代の知識だね 今となっては古臭い 975 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:02:27 ] 90年代から知られてるんだけどなw そのための初期化子リストだし。 976 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:16:51 ] 自分は何歳の若い美少女に手を付けたことがあるぞ〜って自慢する人がいるよね 俺は中学生が最高だと思いますが。おっぱい 977 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 12:43:23 ] 手を付けたことはないが 手に付いたことはある 978 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 13:11:08 ] 手を付けたことはないが、 懐かれたことはある。 979 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:05:29 ] おまえらここは0x歳の美少女に手をつけるスレじゃないぞ 980 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:33:52 ] 8歳未満はさすがにちょっと 981 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:10:09 ] 何進なのかが問題だ 982 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:14:59 ] 0頭でC系なら8進だろ、で1桁だから8歳未満 983 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:15:30 ] x が数値として使われている以上、34進数以上だろう。 そして、34進数以上のどの進数だろうが、 0x は 33 になる。 X と x を使い分けるとなってくると話は変わってくるが・・・。 984 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:28:38 ] 33で美少女はねーよｗってかそろそろスレチだからおわろー 985 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:29:50 ] つか、スレ自体が終わりそうだし 986 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 01:40:31 ] そういえば1000が近いな

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef