- 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/
- 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には想定の範囲内だったと書いてあるんですよね
ｻｰｾﾝ
|
 |
