C++0x 2

The C++ Standards Committee
ttp://www.open-std.org/jtc1/sc22/wg21/

前スレ
http://pc11.2ch.net/test/read.cgi/tech/1149440647/

スレタイはC++1xだろ…常考

ん？　こっち使うの

よし、こっちを使おうぜ

>>1
乙

こっちでいくか。

転載だけど、こうなるらしい。 

--- C++98 Code --- 
vector<int> v; 
v.push_back(1); 
v.push_back(2); 
v.push_back(3); 
vector<int>::iterator i = find(v.begin(), v.end(), 2); 

--- C++0x Code --- 
vector<int> v = { 1, 2, 3 }; 
auto i = find(v, 2); 

STLヴァリヴァリな人にはとってもラクチンになる予感。 

前スレから
ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry

2007年10月に最初の完全なドラフト
2008年10月に最終文書
2009年に "ISO/IEC 14883(2009): Programming Language C++"

……という予定で今のところ作業中らしい。

vector<int> v = { 1, 2, 3 }; 

これってmapにも使えるのかな

map<int,string> m = {{0,"hoge"},{5,"hage"}}

とかできると個人的にはうれしい

>>7みたいな宣言に対応するためにva_listみたいなの使ってコンストラクタ実装することになるの？
うえー

>10
va_list よりは大分ましだと思うが、std::initializer_list<T> を使うことになる。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2215.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2385.pdf

>9
std::map にも initializer_list を受けるコンストラクタができるようなので可能。また、n2215 の 5 章にほぼ同じ例がある。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2220.pdf

>>10
コンストラクタの引数に std::initializer_list<T> を指定するだけらしいよ。

ユーザー定義リテラルをつかって

template <typename T>
std::complex<T> operator"i"(T arg) { return std::complex<T>(T(0), arg); }

として、

std::complex<double> z = 1.0 + 1.0i;

でいいのかな?

constexpr をつけたほうがいいのでは？

clampみたいな、クロージャは入るのかな。

最新のworking draftはこれかな。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

>13
コーディング規約とかで真っ先に使用禁止になりそうな機能だ（ｗ

>>17
まあ適切につかえば便利。>>15 と初期化リストとあわせて

vector<complex<duble>> v = { 1.0, 0.707 - 0.707i, 0.6 + 0.8i, 1.0i };

こう書けるし。これを従来の方法で書くのはうんざりするよ。

>>18
> >>15 と初期化リストとあわせて
　↑>>15 じゃなくて >>13 でした。

>>18
×duble
○double

using duble = double;

#define duble double

typedef double duble;

>>21-23
それはコーディング規約で禁止になるなｗｗｗ

そんなんバレなきゃ大丈夫

#define private public

#define class struct

C++はVisual C++のバグとの戦いの歴史
Boostは今も戦いの最中

0xはとんでもないバグだらけと予想

VC++が0xに対応するのなんて15年後くらいだろ。

>>29
VC7.1になるあたりの頃にHerb SutterがMSに入って直しまくったわけだが
まだ彼がMSにいるならすぐ追いつくんじゃないのかなあ

もうC++はC++/CLRしかサポートしないんじゃないか？

×　C++/CLR
○　C++/CLI

そこで
C++0x/CLI
の登場ですよ！

>>29
にわかだな
MSは速攻対応するに決まってるだろ

ただしバグだらけ

乳首ポチポチおｘんこスリットクリトリス！？

取り敢えずサンプルコードの3割がコンパイル通って、そのうち4割が正常に動くコンパイラ。

boostに#ifdefの嵐が

また対応に数年かけるのは目に見えてるぜ・・・

そうこうしてるうちにC++1xがでるな。

Visual C++ は boost のレグレッションテストでは
かなりいい成績出してるようだが。
ただし Boost 側の対処が頑張っているからではあるのだが。
それ言ったら Boost のコード読むと Borland C++ 向けの
#ifdef のほうが多い気もする。

というわけで、さっさと auto による型推定はできるようにしてほしい。
正直、テンプレートとか複雑になってくるともうわけわかめになるから。
このコンテナ使おうとしてるんだからイテレータの型くらい理解してくれよ、
とか思うこともある。

auto,decltype,pp,operatorを駆使すると
もっと難解なコード書けるけどな。

ところでTRはいくつまで出るんだ？
3ぐらい？

boost名前空間に配置されているライブラリーを多用しているんだけど
tr1 とかの名前空間に配置変えされていくの？
最終的には std の下に入るの？

TR?は一般人は無関係。

スマートポインタの利用が一般的になれば、
それだけで劇的に違うと思うんだがなあ

>>43
working draftではもうstdに入ってる>>16

せっかく名前空間があるのに
名前の重複を避けるためにunorderd_map
とか妙な名前になってるらしいですが、

現実にhash(hash_map?)をstd名前空間に定義しちゃってる
著名なライブラリとかってあるんですか？

そんなん「stdに書いちゃう奴が悪いだろ」で終了の気がするんですが

あるいはマクロでもあるのかな・・

名前空間の階層化宣言て入ってるんだっけ？

namespace std::collections
{
class AreKore
{
};
}

みたいな奴

>>45
もしGC入ったら趣味プロレベルはそっちに流れそうな気もする

>>47
SGI -STLはかなり初期から入ってた。
というか、今じゃほにゃららext系の名前空間にむしろ入ってないケースの方が多いくらいだが、
こいつらも一時期は std 内に生息していた。

>>47
C++はパッケージがないしなあ。

>>48
それ、便利だよなぁ。あったら。

>48
提案はあったようだけど
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1524.htm
Not ready for C++0x になってる。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2389.html

ドラフトに入ってる機能が削除される可能性ってあるのかな？

修正不能な大きな穴が見つからない限りない、
つまりない。

�d

ただ節目節目で投票に掛けるようだから、
最終投票まで油断は禁物。

取り敢えず今俺が望むのは
新しい予約語は増やさないで可能な限り記号で。
拡張forでbeginとendが必須とかいらん。[]辺り使ってくれ(現状は知らんケド)
nullptrとかlong longとか絶対要らん。
折角bit長決定してねぇんだからlongで代用させとけ。
いかにMSが文句言おうと規格無視して32bit前提にしてるのが悪い。

>58
C++0x に入るかもしれない提案だと、本当の予約語としてこれくらい追加。
() で囲んでるのは attribute の提案(n2379)が通ったら予約語にはならないと思われるもの。
実際には、キーワードの再利用とかもひどいし、std::inializer_list とか予約語じゃないけど
基本的な機能で使用されるものとかも多いので望み通りにはいきそうにないね。

[working paper]
(alignas), alignof, char16_t, char32_t, constexpr, decltype, static_assert

[concept]
axiom, concept ,concept_map, late_check, requires

[GC]
(gc_forbidden, gc_relaxed, gc_required, gc_safe, gc_strict)

[雑多なやつ]
nullptr, (thread_local)

[]演算子にしたらbidirectional iterator/rangeとか困る。

long longは現状追認で仕方ないだろ。C99にも入っているし。
それよりint 32 bit, long 64 bit, long long 128 bitなんて妄想しようぜ。

でもnullptr不要には同意。

可変単位整数ならテンプレート合わせで vint<8> のようなほうがいいな。

intXX_t系をしっかり実装してあればいい。(x=>数字）

なぁ、新しく追加されるconceptだけど、
gccにあったsignatureの方がよくね？
まぁ、廃止されたんだから、廃止されたなりの
デメリットがあったんだろうケド既存のクラスをいじらなくて済む分
signatureの方が便利そうだ

　こ　こ　ま　で　の　レ　ス　は　、　す　べ　て　『　気　の　せ　い　』　で　す　。

そんなことじゃないかと思ってたよ

MSと何の関係があるのかと…

nullptrに特殊化させたい。

>>67
それは nullptr がテンプレートとして実装されていればいいのにってこと？

本来のポインタと変換しやすいスマートポインタを書いたり、
ポインタを保持できるコンテナやアルゴリズムを書いたりするとき
ヌルポインタに対するテンプレート特殊化が書きやすい、
ってことだべ。

NULL=0定数を使うと整数の特殊化とかち合う。

>>64
WindowsがLLP64モデルを採用してるからじゃない？

アンカーミス
>>64 → >>66

ttp://herbsutter.spaces.live.com/

さったーさんはCLIの世界へ逝かれました。

というか、Lippmanにしても、
なんであそこまでC++/CLIに入れ込むのかわからん。
MSとの契約に書いてあるのかな?

でもさ、C++/CLI って Java 厨がうざいこと言ってきたときには便利じゃね？

実はいずれ標準にGCが入った時の事を考えてるに違いない

いや、マネージドという視点を入れると、おもしろいよ C++/CLI
リソース混合状態を考えると、何かがいることは確か

#define nullpo nullptr

>>78
誰かやると思った

#if defined nullpo
#define ga nullpo

null
はダメなのか・・・
やっぱり誰かが使ってそうだから？

>>79
それだと全てのgaがnullpoに置換されないか？

#endif

g++だと__nullというのがつたえたりするね。いまでも。

やんぬるかな

病ん（でる）null？

VC++ でも __null じゃなかったっけ？

nullptr が導入されても
T* p = ...;
if (!p) あぼん
は生きてるよね？

マルチメソッドはどうなったんだろう。
あれが入ったらダブルディスパッチが不要になるな。

>>88
それなに？
C#の event みたいなやつ？
デリゲート使ってるやつ。

はわわわわ

>>86
/clr付ければnullptrが使える。

>>87
どうせ
#define nullptr 0
ってなるだけだろ。

>92
それだと提案されてる内容を満たさない。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2214.pdf
nullptr の型は nullptr_t であり整数値として扱うことができない。

>87
定数 nullptr そのものが出てこない限りプログラムの意味論には影響しないと思われる。

C
C++ (c plus plus)
C# (c charp)
C* (c anal)
C@ (c gurochikuvi)

C(i) （c omeko）

Cω (c sorewa watashi no oinarisan da)

いや、わかって書いているとは思うんだが、一応。

Cωって存在するぜ？
http://ja.wikipedia.org/wiki/C%CF%89

まあ、>>97さんて野暮なお方

外人って　ω　とか見てもへっちゃらなのかね。変なものを想像したりしないのか？ｗ

2ch見すぎ

日時関連のクラスの導入とか無いのかね。
あっても良さそうなもんだと思うんだけど。

スレ違いかも知れないが、
boostにある日付を扱うライブラリはだめ？

いや、それが何で C++0x に追加されないのかな、と。

変に入れるとローカライズがらみでJavaみたいにぐたぐたになるからじゃね？

std::time_get じゃ不足?

あ、こんなのがあったんだ・・・。
別の場所読んでた。

な、なんだって〜！
このスレに来るの少し早いんと違うんかと
無いのかね、言いたいだけと違うんかと

>>107
日本語でおｋ

このスレ的には
C言語でおｋ

関数パラメータのケツのカンマ無視してくんねーかな。
enumや配列の初期化では無視してくれるだろ。

そうーいう仕様にすると、
void foo(int x)とvoid foo(int x, int y = 1)を定義しておいて、
foo(2)で前者を、foo(2,)で後者を呼べるようにしろ、
とゆー輩が現れそう。

自分のこと?

いやお前のこと、と言いたいけど、お前は思いつきすらしなかったっぽいな。

それもいいけど、判定をコンマ区切りで同時処理したい

if ( (i, j) == n )
||
if ( i == n && j == n )

って判断してくれないかなぁ

>>114
変数でなく定数のnに関してまとめるというのに違和感が…

それだったら m < i < n を m < i && i < n と同一視してくれの方がまだましだと思う。

>114
Perl モジュールだけど、
ttp://search.cpan.org/~lembark/Quantum-Superpositions-2.02/lib/Quantum/Superpositions.pm
と同じような記法で良ければ今でもライブラリとして実現できそうな予感。

>116
なるほど、any とか all とかで範囲を確定するライブラリを作るわけですね

result = ( notstd::any( i, j ,k ) < index ) ? true : false;

とかって書くわけだ。便利そうですね

>>116
これならいいね。
>>114はアレだけど、operator,で>>116を定義できちゃうかな?

レベル低いのが混じってるなぁ

正直、ライブラリレベルで勝手にやってくれって感じだな

C++の悪いところはコーディングの時点でのライブラリなのか副作用のあるライブラリなのかが分かりにくいという事だ

>>121
日本語でok

お前の理解力が無さ過ぎるだけ

俺もわかんね
具体例でおしえてください

どんなライブラリだってコーディングのときに使うんだよね？
あと、関数型言語じゃないんだから、副作用のないライブラリなんてほとんど全然ないとおもうんだけども？？？

俺もわからん

114周辺のライブラリの話なんかはコーディングの際にしか影響しない、
それに対しOpenGLとかは副作用そのものを目的としたライブラリで、肝心のC++のライブラリは
どっちに目的を置いたライブラリか分かり辛いのが多い、て事が言いたいんだろ。
どっちが目的かはグレーゾーンみたく明確な線引きは無理だろうけど

あぁやっとわかった
記述を簡単にするためのシンタクスシュガー的なライブラリと
それ以外の事か

前者はboost::noncopyableとかかな

むしろコーディング時にライブラリがいるっていうのが問題だろ

それはコーダーの問題か。

ライブラリの部分で言語を変造できるほど強力なのがC++の利点だと思う。
そういうのがキレイに分かれててほしいときはJavaとかC#を使えばいい。
俺は使い分けてるよ。

エスパーってほんと尊敬するよ。

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-10-19: C++ Standard Core Language Issues List (Revision 51) is available

コーディングのときにはヘッダファイルしかいらないだろ！

ワーオ

つまりコンパイラとリンカに問題があるんだな

ロリコンパイパイとダイナミックリンクしたい

　　　　　 　　　＿＿＿_
　　　　　　　／　　 　 　＼　　　　「ロリコン」に興味があるの？
　　　　 　／　　─　 　 ─＼　　　変態っつーかキ○ガイじゃね？
　　　　／ 　　 （●） 　（●） ＼　　こっち見んなよ
　　　　|　 　　 　 （__人__）　 　 |
　 　　 ＼　　 　　 ｀ ⌒´　 　／

(゜д゜)(゜д゜)(゜д゜)

ロリに興味はあっても、ロリコンに興味は抱かないよな。
気持ち悪い

最近はロリコンというと男の方を指すのか
時代は変われば変わるもんだなぁ

Comeauのlibcomoはwchar_t関連の実装が空っぽなので注意な

ロリコンはロリータコンプレックスの略で、それ自体を訳せば少女嗜好となり、時代に関係なく少女そのものを指す語ではない。

提喩つってだな、対象のある属性の名前が対象そのものを表すようになるのはよくあること。

>>133
"block scope"って用語は消えて、"local scope"に統一されるんだな。
あとは特筆すべき変化はないが、sizeofを使った特殊化の奴は、
meetingで方向決まったものの、まだ文書化されてないんだな。

最初の話に戻るが、提喩ってのは女の子を映画に誘うことじゃないぞ。

そりゃシネクドキだろ・・・って突っ込んで欲しかったのか？ｗ

>>143

>sizeofを使った特殊化
kwsk

＞提喩つってだな、対象のある属性の名前が対象そのものを表すようになるのはよくあること。

でもよー、いつからロリコンが女の子をあらわす言葉になったんだ？
まあロリコンの女もいるかも知らんが…

「ロリコン」が幼女・少女のほうを指していたことはただの一度も無いから、
これは単に「正しく認識しているかどうか」の問題。

これは何ともハイレベルなC++のスレですね＾＾

>143
ttp://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
特殊化とはちょっと違う文脈な気もするけどこれですか。

ロリコンの女ｗｗ

ロリがロリコンを指している場合もあったりしてワケワカメ

Wikipediaをwikiって言うの以上に無理がある気が…

清岡以前の世代はC++0xに興味を持っていないようだよ・・・寂しいね・・・

>>153
誰だよ？w

俺俺、俺だって

おまえかあ

>>154
平清盛の大叔父の平清岡だよ。
ちなみに弟は平盛岡。

>C++ では、継承によってメソッドが暗黙的に "隠ぺい" されます。
>C# では、new 修飾子を使用して、継承メンバを明示的に隠ぺい
>する必要があります。

こういう安全機構（といっても構文上の）が C++ にも必要じゃね？

賛成

俺なんかメンバ変数と同じ名前のローカル変数を
メソッドの中で使ってしまって●一日悩んだ．
こういうのも言語仕様上明示的に隠ぺいしなきゃ
ならないとしてくれるとありがたい．

>>160
今時のコンパイラなら適切に警告が出るはずだが。

>>161
まじっすか〜？
Visual C++ 2005 で警告をレベル4にしても出なかった希ガス

ゴメン。今見たら、手元のコンパイラはディフォルトでは全滅だった。
見た記憶はあるからgccのオプションであると思うんだけどなぁ。

>>163
-Wshadow かな?

そういう明示的な隠蔽とか
まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う
コンパイラのオプションにあるのは別にいいけど

なぜ？

$ cat test.c
class C {
int x, y;
int m(void) {
int x;
x = y * y;
return x;
}
};
$ g++ -c -Wshadow test.c
test.c: In member function 'int C::m()':
test.c:5: 警告: declaration of 'x' shadows a member of 'this'

>まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う

これにかかる「なぜ？」への答えは
以下のことが起こる可能性があるから

1 不必要なことを強制される
2 予約語が増える
3 言語仕様が大きくなる
4 まずい設計を支援する

> コンパイラのオプションにあるのは別にいいけど

これにかかる「なぜ？」への答えは、自分への悪影響はないから

１と３は矛盾
４は丸っきり逆

なぜ？

>>165
まずい設計のしりぬぐいってわけでもないと思うんだよ。

１）変数名の規則は設計というよりはコーディング規約
２）しりぬぐいじゃなくて、まずいコーディングが
　　やりにくいようにしておくのが幸せ

>>169 の指摘は正しいと思う。まずいコーディングを
支援するんじゃなくて「やりにくく」するのだから。

http://www.blender.org/documentation/intranet/conventions/codingstyleguide.html
によると、gcc でのお勧め警告フラグは、
* -Wall, -W
* -Wshadow
* -Wpointer-arith
* -Wbad-function-cast
* -Wcast-qual
* -Wcast-align
* -Waggregate-return
* -Wstrict-prototypes
* -Wmissing-prototypes
* -Wmissing-declarations
* -Wredundant-decls
* -Wnested-externs

自分が言ってるのは
明示的に隠蔽を宣言しなければ、うっかり意図せず名前を隠蔽しちゃうような
巨大なベースクラスは設計がまずい
ということ

継承の階層が深すぎたり、メンバが多すぎたりしなければ
明示的な隠蔽の宣言が必要なんて、押し付けがましく感じるってこと

で、明示的な隠蔽の宣言はそういうまずい設計を助けてしまう

いや、わかるけど
逆に継承させた人が隠蔽してることを明示したいって事もあるんじゃない

>>165

１．隠蔽不可
２．隠蔽可能＆明示不要
３．隠蔽可能＆明示必要

どれがいいと思ってるの？１？２？
自分は３だけど

熟考はせずにいうけど
継承時には 1
そのほかでは 2
が良さそうい思う

でも、ルールは少ないほうが良いので結局 2
つまり現状のC++

内側の名前が外側の名前を隠すのは直感的だと思うし

そうは思わない人がC#を作りましたと

>>173
巨大なクラスがどうこう、って話だったっけ？

導出クラスが作られた後で基底クラスが変更されて、
同じシグネチャのメソッドが追加されるととっても危険、
というJavaでの問題が報告されたから、
明示的な隠蔽みたいなのが出てきたんだと思ってたけど。

>>175
俺は２
理由はC系の言語ってそういうもんだと思っているから。
けど隠蔽を警告しない糞コンパイラは使う気しない。

過去のコードを捨て去るなら別の言語を作ってそっちでやってください、というのが現状の委員会でしょ

C++ って久々に使うと結構楽しいね。

>>172
Visual C++ 2005 で同等の強さの警告出させたいものだ。

>>181
まいにち使うと結構つらいよ。

boostのvaultのやつまで使用おkなら楽しいよ

C++0xが来ればもっと楽しくなるだろうな。

ConceptGCC楽し
はやくこいこいC++0x

楽しいと言うかコーディングが楽になりそうでいいね。

特に auto が。

auto ってなんでも推論できるんかね？
なんか馬鹿の一つ覚えみたいに auto が氾濫しそう。
そんあこたーない？

>>188
タイピング量を減らしたいからって理由で使ってたら可読性がﾜｯｼﾜｯｼ下がったのが俺
今じゃまったく使ってない

今までの言語仕様にautoだけプラスした、って環境ではかえって負担になる感じ
きちんとしたC++0xが出てくればまた違うと思うんだけれど

でも適切な使用法もあるはずだよ
そうでなければBoostからとっくにrejectされてるはず

イテレータを使うときにちょっと楽じゃね

ってところから使えば肩もこらないんじゃないかと

ML系の関数型言語では推論をするのに十分な型しか明示しなくても問題ないよ
可読性の低下は感じない
ML系は暗黙の変換がないけどね
そこさえ避ければ大丈夫そう

オーバーロードされてる関数のポインタを取得しようとして
void func(int);
void func(void*);
auto ptr = func;
エラーだなこりゃ。

>>193
そうそう。どこまで「自動」なのか知りたいね。
そして、C++0x的におｋな限界まで auto を乱用されると、きっと萎えるよな。

typedef std::vector<auto> vt;
void func(vt &v){...}
std::vector<int> v_a;
std::vector<short> v_b;
func(v_a);
func(v_b);

こんな事もできるようになるのかね？
template要らずだな

そのときはまたboostが以下略

>>195
それは型のパラメタ化であって推論ではない
やっぱりtemplateの出番

>>193
オーバーロードされた関数は名前だけで型を決められないので
auto だけじゃなく bind でも使いにくいしなあ。

それに、C++ のライブラリでは f(a) と f(a, b) が 2 つの関数として
定義されているのか、f(a, b = B()) みたいなデフォルト引数つきの
関数なのかは規定されてないらしく、bind1st/2nd をライブラリ関数に
使うことは(移植姓の観点から)よろしくないらしいし。

というわけで lambda 切望。むしろ bind イラネ。

>>198
標準関数の引数並びは規定されてるだろ。
それ、どっから出てきた話？

>>199はどっかを読み違えているのだろう
でも、どう読み違えて、そう解釈したのかが解らないから
うまくアドバイスしてやることも出来ない

>>199
引数並びではなくシグネチャの話。
正確には関数じゃなくて「メンバ関数」限定だった。ごめん。

「std::mem_fun は標準ライブラリのメンバー関数に使うなゴルァ」
by はーぶさったー (Exceptional C++ Style)
だってさ

>>201
シグネチャの意味で「引数並び」って言った。でもやっぱり決まってるでしょ。

メンバ関数に限定するってことは何か具体的な例があると思うんだけど、挙げてもらえる？

>>202
Exceptional C++ Style
P.29
>・デフォルトパラメータを持つメンバー関数のシグニチャは、
> 「等価な振る舞いを持つ2つ以上のメンバー関数のシグニチャ」に
> 置き換えても良い。
>・メンバー関数のシグニチャには、追加のデフォルトパラメータが
> 含まれていても良い。
P.30
>つまり、コードの移植姓を保ちながら標準ライブラリのメンバー関数
>へのポインタを生成することは不可能なのだ。

これ以上は立ち読みでもしてくれ

>>203
なんだかそういうルールがどこかに書かれてそうだな。

ってことで規格を signature あたりで検索したら、あった。
17.4.4.4p2
> An implementation can declare additional non-virtual member function signatures within a class:
> ? by adding arguments with default values to a member function signature;172) The same latitude does not
> extend to the implementation of virtual or global or non-member functions, however.
> ? by replacing a member function signature with default values by two or more member function signatures
> with equivalent behavior;
んで脚注 172 に
> 172) Hence, taking the address of a member function has an unspecified type.

うーん。 bind に push_back とかコンテナのメンバ関数を使ったことがあったような
気がするんだけど、実装依存なコードだったのか。

あ virtual なメンバ関数には static_cast でシグネチャ明示すればなんとかいけるね。
コンテナとか普段使うやつはほとんど非 virtual だから救われないけど。

>>203の言ってる意味がよくわからん
誰かコードに落としてくれ

>>205
Exceptional C++ Styleにそのまま例が載ってるじゃん

std::mem_fun</*...*/>(&std::vector<int>::clear)が正しいかどうか
自分で検証してみればわかるはず。

極端は話、
push_back(T val,bool hoge=true,int hage = 5,float foo = 0.05f)
なんて実装でもいいわけか

push_back(T val,bool uramode=true)

デフォルトパラメータを利用して独自拡張ができるってことか

このあたりの標準の改定案は出てないんかな？
実装に自由裁量権を認めたはいいけど、自由度あり過ぎて
std::mem_fun の位置付けが中途半端になってしまったのは
仕様の不備という気もするし

>>210
コーディング標準として、
>>204に相当するようなコードは書かないようにするしかないかと。

>>211
現状の話じゃなくて、C++0x にも同じ制限を持ち越すのか？
ってことが知りたいわけで

Exceptional C++0x Style でまた書かれるぞ

>Exceptional C++0x Style でまた書かれるぞ
また落とし穴が増えるのかよ
　　　　　　　　 　∧＿∧
　　　　　　　　　（ ´Д⊂ヽ

>>212
とりあえず>>180は前提ですよ。馬鹿じゃない限り。

boost::function<void (std::vector<int>*)> vector_clear = &std::vector<int>::clear;

>>214
この件については >204 にあるような実装への自由度を制限することで
ライブラリユーザー向けに課せられていた暗黙の制限が解消されることになるだけで、
過去のコードは依然としてコンパイルできるし動作に変化は生じない。

2003 の規格に準拠した実装は変更された規格に適合しなくなるかもしれないけど、
古い実装が新しい規格に適合していないことになるのは何も問題ない。

C++09 にはもう手遅れだけど、提案してみれば将来につながる可能性はあると思う。

>>216
> 実装への自由度を制限することで
> 依然としてコンパイルできるし

どういうこと?
禁止したらコンパイルできないでしょ。

STL実装に依存した関数ポインタを使ってないかぎり大丈夫だろ

「オーバーロードセットが存在するメンバ関数だけにういて適用される」
みたいな制限だけでもだいぶ違うね。
そうなれば vector push_back, clear は問題なくなる。

>>219
そんな中途半端な仕様いやだよ。 push_back() はいけるのに insert() はだめとか。
仕様かえるなら半端にする必要ないでしょ。

C++1xスレでも立てるか？

>>220
じゃあどういう修正なら納得するかｋｗｓｋ

どのみちオーバーロードされたメンバ関数はシグネチャ明示しなければならんけど、
それ以外は一意に決まるってだけでも今よりだいぶマシじゃん。
根本的にはlambda式が導入されない限り解決にはならんと思うけど。

>>222
>219 のやつだと、オーバーロードされてるやつは static_cast でシグネチャを
明示しても移植性を確保できない。

どうせやるなら >204 にある記述を全部削除して、 public なメンバ関数の
シグネチャを規格でしばることにしたほうがいいと思う。そうすれば
オーバーロードされてるやつでも static_cast での明示さえ我慢すれば
移植性を保ちつつメンバ関数へのポインタが使えるはず。

>>223
そりゃ204全削除できれば一番いいけどね。

std::string とかメンバ関数100以上あるし、デフォルト引数使えないとなると
例えばfind_first_ofだけでも4つから7つに増えるわけで、実装側は大変だ。
少なくとも Defect Reports のレベルじゃ受け入れられなそうな印象。

>>224
なんで「デフォルト引数使えない」なんて話になるの？

流れぶった切りですまんけど >116 で紹介した Quantum::Superpositions の(簡易) C++ 版を作ってみた。
ttp://yak.myhome.cx/junks/index.html#cpp.superposition
superposition と非 superposition 間の関係演算子だけ実装。
スレ違いかもしれないけど、発端はここだし Variadic templates 版実装も作ったってことでここは一つ。

>213
とりあえず Variadic template と通常の template は混ぜるな、に一票。

>>226
読んで感想を書こうと思ったけど自宅モードでは
boost/preprocessorが使われているコードを読む集中力が沸かない

サンプルから察するに非決定的計算っぽく比較できるもの?
計算量はネストすると指数オーダーかな

>>225
すまん早とちりした
デフォルト引数の部分も含めて仕様にすればたしかに問題ないね

デフォルト引数の存在を意識せずにシグネチャ指定を可能にする、
みたいなものを夢想してしまったようだ
x.f(a) -> R (X::*)(A)
x.f(a. b) -> R (X::*)(A, B)

>227
> 非決定計算っぽく
そこまで大それたことを考えてたわけではなくて基本要求は >114 ね。

any(a, b, c) == d → any(a == d, b == d, c == d) → any(bool0, bool1, bool2) → bool0 || bool1 || bool2

のように評価される(bool* はそれぞれの評価結果)。all の場合は最後の || が && になる。
で、↑から大体想像つくかもしれないけど、重要なこと書き忘れてた。
この実装だとショートカット評価しない。全ての項目に対して対応する演算子が呼ばれて bool の tuple に変換されてから最後 || とか && してる。
ショートカット評価するなら Expression Template 使うのかな。その上で Boost Lambda とか使えばほんとに非決定計算っぽくできるかもしれない。

Expression Templateを使おうが、Boost Lambda使おうが、ショートカット評価は不可能だよ。

>230
評価のタイミングもコントロールできるのが Expression Template の強みの一つだと思う。
operator&& それ自体をショートカット評価にすることはできないけど、Expression Template 使って木を生成した後で、
評価するときにこっちで勝手にショートカット評価してやればいい。

なんか落ち着かないと思ったら、普通はショート「サーキット」評価だ。

で、ちょっと考え直してみたけど、a, b, c, d の評価自体が発生してしまうから、正しいショートサーキット評価にはならないってことでいい？
operator==() の呼び出しについてしか考えてなかった。

最近普通にshortcut evaluationって言うぞ。
Short circuitは古いだろ。マイキットじゃねーんだから。

0xにはDのlazyみたいなものないの？

>>233
短絡評価（short-circuit evaluation）や最小評価（minimal evaluation）に次いで
新たな用語が出てきたのかと思って調べてみたけど、どこで使われてる用語なの？

ここで話題にするってことは言語はC++なんだよね？
簡略評価ならVB書籍で見たことあるけど･･･。（正直誤訳だと思ってた）

>>231
ムリだって。


>>232
>で、ちょっと考え直してみたけど、a, b, c, d の評価自体が発生してしまうから、正しいショートサーキット評価にはならないってことでいい？
>operator==() の呼び出しについてしか考えてなかった。

operator==だけが短絡評価されて、なんの意味があるのか、普通そこまで考えるだろ。
お前の思考回路が短絡評価されてるよ。


void 思考回路(){
　if ( (operator==呼び出しを遅延できる) || (a,b,cの評価を遅延できる) ){
　　レス(
　　　　"評価のタイミングもコントロールできるのが Expression Template の強みの一つだと思う。"
　　　　"operator&& それ自体をショートカット評価にすることはできないけど、Expression Template 使って木を生成した後で、"
　　　　"評価するときにこっちで勝手にショートカット評価してやればいい。"
　 );
　}
}

次の言語仕様に中傷メソッドでも入れる勢いだなおい

>236
すまんね。a, b, c, d の評価はこっちではどうしようもないところだから思考の外にあった。
なのでむしろこんな感じだな。

void 思考回路() {
  if ( (operator==呼び出しを遅延できる) ){
    レス(/*略*/);
  }
}

bool out_of_scope = (a,b,cの評価を遅延できる);

ちょっと言い過ぎた。

ぬこぬこ

coutって、printfより使えないと思うのは俺だけ？

使えないとは言わないけども、
今思えば opeartor overload の乱用は失敗だったし、
フォーマット出力は欲しいってのはみんな思ってる。

こんなこともできるよ的なものじゃないの？

basic_ostreamはそもそもコンソール出力のために作ったものではないだろう
役割が違う

使いたければstd::printfを使えばいいだけの話ではないのかな
そういう言語だよね

しかし型安全性は欲しいところ

コンソール出力のためでないならば、具体的にどういう場合 printf よりグーなのだろうか

ていうか型安全を考えれば printf のほうがありえねーって感じ？
typedef されてる整数型を正しく出力するために対応するフォーマット文字列を
マクロで用意とか、やってられないでしょ。

でもboost::formatはどうコンパイルされてるやらさっぱりわからんから恐くて使えない。
0xでこのあたり、なにか改善はありますか？

怖くないよー怖くないよー

printf問題は書式文字列リテラルっていう文字列と別のリテラルを作って
コンパイラが型チェックするようにするのが結局いいんじゃないかなー

実際、多くのコンパイラがそれに近い扱いで型チェックしてるわけだな

stringstream でええやん。

>>248
boost::formatは別にコンパイル時にややこしいことをしてないと思うけど。
そんなことをする意味がない。

>>253
仕組み説明してYO

C++0x 2なんてつぶれろ

禿を含めたC++基地外共がややこしことばかり考えてるのに
これ以上つき合えるか！

どんなに論理的に強力な根拠があると言ってもややこしい論理は
結局受け入れられないんだよ。

お前らだけで勝手に遊んでろや！馬鹿

むしろわかりやすくなる方向に行ってると思うけどね

まぁ他の言語でも楽しんできてください

確かにややこしすぎる感じはする
よく使われる主要な言語が難しいのは歓迎だけど、わかる人間の価値が高まるし
でもこの勢いだと主要でなくなりそう

右辺値参照を理解できない人が多そう

>>255
よしきた
俺たちだけで勝手に遊ぶよ

>>256
>むしろわかりやすくなる方向に行ってると思うけどね

基本的には同意だが、どちらかというと
今までのややこしさを軽減させようとしているだけとも感じる。
つまり、今までのややこしさでC++に匙を投げた人間は、
C++0xを好意的に受け止めるとは思い難い。また、なんか追加されるのかよ的な感じで。
でも、そのおかげでオレのような本来はたいして有能でもない人間が、
チーム、部署内でのある程度の地位をキープできてる。
オレのまわりはC++敬遠ぎみの人が多いから。
まさにオレは禿のジョークを体現している。
そういうわけでC++0xには期待している。ほどよくややこしくしてほしい。

ややこしいのが嫌いな人には、今は代わりになる言語があるからね

それよりいつになったらC++はまともなオブジェクト指向言語になるのかと

いまのSTLすら理解できない人には
functionやbindは無視されるだろうね

>>263
bint1st, bind2nd, mem_fun, ptr_funなんかよりbindのほうが全然わかりやすい件について。

いまのMPLすら理解できない人には
C++0xの大部分はスルーされるだろうね

だったら同意。

>>264
bind1stとかについては同意

でもC++の文法からbindの存在を想像するのが難しいので
理解できないんじゃないかと思ったけど
インターフェースが簡単だから大丈夫なのかな

関数ポインタよりfunctionの方が全然分かりやすい件について

>>265
うん。大丈夫。以前経験した現場だと、C++初心者レベルのみんながboost::bindを使いまくって
プロジェクトが崩壊しかけたたよーん。

兄さん、そのbindしたthis、とっくに死んでます・・・みたいな。

bindでポインタ持ち運んだらえらいことになりそうだ

C++初心者はC++なんて使っちゃ駄目なのだ
つまりC++を学ぶときは、いきなりC++の達人にならなければいけない

んなこたぁ〜ない

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-10-28: The 2007-10-post-Kona mailing is available
News 2007-10-28: The C++ Standard Library Issues List (Revision 52) is available

便利な機能があるからって使わなきゃいけないということはない。
bindやconceptなんてライブラリビルダが使ってればよろしい。

まさにC++は男坂

いやbindは便利だよ
沢山引数を指定する関数のある引数だけを変えながら実行する場合、さらに具体的にいえば
初期化ルーチンで動作モードを調べながら実行するときとかよく使うし

>>272
そのレベルで使うならC++の必然性が少ない。言語は他にいっぱいある。

ぷろぱてぃというかげったーとかせったいみたいなのは
０ｘではいるんですか？はいらないんですか？
どうなんです？heheheh

なんか変なのキタ

下駄と雪駄？

もう入ってるだろうっつーか

下駄がcast operatorで
雪駄がassignment operatorで代用できそうな

それだとプロパティごとにクラス作らなきゃという気がする

>>279
プロパティは概念上、ダイレクトな生メンバとは違うものだから記述方法も違ってくるのかなと

下駄も雪駄もC++の原則
「テクニックでどうにもならない機能だけを言語仕様に頼む」
にはあたらないなあと

D言語マンセー

CよりDがEけど結局F#

Zもすでにあるみたいだし究極言語「ん」とか作ろうぜ

プログラム言語じゃなくて仕様記述言語だけどな。

ん、いいねぇ。

>>278
プロパティの代用はできねーよ。

そんなので代用したらクラスのサイズが無意味に増えるだろ。

>>286
getterとsetterが言語仕様に入るだろうか？という話をしているのに
なぜクラスのサイズという実装上の問題の話に摩り替わってしまうのだろうな？

>>287
はぁ？頭大丈夫か？

プロパティは
>下駄がcast operatorで
>雪駄がassignment operatorで代用できそうな
とか言う奴に、それで代用なんかできてないという話をしてるのに、
何故getterとsetterが言語仕様に入るだろうか、という話に摩り替えようとするんだよ。
バカかこいつ。

>>288に一票

じゃあ俺は>>287に100億万票

>>288
正論だが物言いがよくない

>>288
(1)getter/setterのC++0x化 → (2)下駄雪駄 → (3)代用はできない → (4)クラスのサイズが増える

で (1) || (2) の話をしている所に (2)->(3) と飛躍して (3) && (4) を適用していますが
話を逸らしている行為以外の何だと思っているのですか？

「代」わりに「用」いる、ではなく「そのテクニックは既にある言語仕様で実現できる」という話ですよ
(1) || (2) の時点で「あぁそうですね」で終わっていた話から (2)->(3) と展開する合理性が見えません

別に君は見えないままでいいんじゃない？
他の人は見えてるから問題無いし、君という一人の阿呆が困ったりムカついたりしても
誰も困らないし。

個人攻撃をする間で関数の一つでも書こうぜ…

>>293
>誰も困らないし。
>>292が困る件について

>>292
それはお前の脳みその中だけで通用するパカ論理だということを忘れてはいけません。

クラスのサイズが増える、って具体的に何が増えるの？マジで。

コードサイズだというならインライン化の度合はsetter-getterと同じかそれより強いと思うし、
データサイズが増えるわけはないし。

感情が先走って論理展開がムチャクチャになってないか。

本当に中傷メソッドが追加されるなこりゃｗ

レベルひっく〜

　　 ∧＿∧　　／￣￣￣￣￣
　　（　´∀｀）＜　オマエモナー
　　（　　　　） 　＼＿＿＿＿＿
　　｜ ｜　|
　　（＿_）＿）

たとえ内容がマトモでも罵倒口調だと読む気がしない

バカばーっか。

じゃ俺ははらたいらに3000点

もうお亡くなりになられました。

ってか、もういー加減にしろよｗ

>>297
パカ極まるなお前。

>下駄がcast operatorで
>雪駄がassignment operatorで代用できそうな

これで代用したプロパティを持つクラスを実際に作ってsizeofしてみろ場か

>>304
あなたの意見を私が証明しなければならない、というのは筋が通りませんが…
sizeof にコード量が反映されるという処理系は知りませんよ？私は

>>304
sizeof は変わらないでしょう。

>>306
template< typename V > struct property { .... };

// プロパティクラス
class foo {
　int value_;
public:
　foo() : { value.setref(value_); }
　property<int> value;
};

// プロパティ構文 C#
class bar {
　int value_;
public:
　int value { get{ return value_; } set(int val){ value_ = val; } };
};

sizeof(foo);
sizeof(bar);

どっちが大きい？

違う言語で比較してどうすんの？

もともと（C#にあるような）プロパティが欲しいって話じゃなかったっけ

syntax sugar 以上の意味があるの？

参照の分メモリを節約できるといいたんじゃないの

プロパティ + Template で楽しいことが出来ると思うけどな。
従来の構造体と、変数を分け隔てなく扱えるようになるとかさ。

struct Interface {
　virtual int value { ... }　← 仮想プロパティ
};

template< typename T > void init_val( T & val ) {
　val = 20;
}

int x = 0;
init_val(x); // x = 20;

Interface * p = ...;
init_val(p->value); // p->value = 20

無理かな。

>>307
cast operator と assignment operator では代用できない、という話ではなかったのですか？

漏れもデータメンバが増えるようでは setter と getter の
シンタックスシュガーの代用としては不適格だと思うが・・・

単一の本物のデータメンバであることを活かせる場面もあるだろうから、
どっちが良いという話ではないけど。

getとsetが予約語になったら楽しい

D言語マンセー

import std.stdio;
class Foo{
  private int value_;
  int value(){return value_;}
  int value(int val){return (value_=val);}
}
void main(){
  auto f = new Foo;
  f.value=10;
  writefln(f.value);
}

>>316
Dはそれでいいだろうが、C++で bind するとき大変そうだからヤダ

Dとかイラネェ

template <typename _T>
class property {

なかったことにしよう

template <typename _T>
class property {
private:
T t;
T* operator &();
public:
operator T () { return t; }
T& operator = ( const T& r ) { t = r; return *this; }
};

class A {
public:
property<int> value;
};

void test() {
A a;
int v = 1;
a.value = 0; //ok (a.value == 0)
v = a.value; //v = 1
a.value += 4; //error
}

それ、publicメンバ変数に比べて何か嬉しいことあんの？

なんもないｗ
default constructibleじゃないとだめだし
マジメなsetter/getter実装しようともったら結局なんらかの参照が必要になる

C++ : 不便に感じる糞仕様がそれなりに多い
D : 妥協ライン
C# : マイコーソフトの柵
C++0x : 期待と不安の境目

>>305
いつ誰がコード量が増えると言ったんだ？
筋が通ってないのはお前だよ。


>>313
どうみても代用できてないだろ。お前の目はフシアナかいな。

一応こんな提案あったみたいだけど、Not ready for C++0x, but open to resubmit in future になってる。

C++ Properties -- a Library Solution
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf

プロパティ話は Boostスレpart4 でもやってたやん
もういいよ

>>327
それ言ったらほとんどのスレッドが終わっていく…

>>326
C++1x？が待ち遠しくなった。

>>326
プロパティ1つ追加するごとに、ポインタ分だけオブジェクトのサイズが膨らむのか

そもそもプロパティなんていらね

たしかにいらね。
そのまま公開するんなら public メンバ変数にするさ。

下駄と雪駄にfuck…もといhookかけられるならそれなりに有用になるかも

hook をかけないプロパティになんのいみがあるのかと問いたい

なんとなくオブジェクト指向している気になれるというなかなかぬるぽな効果があります

プロパティいらねぇから、組み込み変数とPODに対してだけでいいから
変数の値が更新されたときにフックかけれるようにして欲しい。

class MyWindow {
　void updateRect( RECT old_value ) {
　　SetWindowRect(&windowRect);
　}
public:
　__declspec(onchange=updateRect) RECT windowRect;
}

みたいな。

いつのまにやら日本語版にもC++0xの項目が

ttp://ja.wikipedia.org/wiki/C%2B%2B0x

M＄が21世紀終わるまでにちゃんと実装してくれるとは思えん。

項目ができてから1ヶ月余り？
それにしてはすごい量だな

項目ができてから書き始めるわけじゃないですからｗ

constexprにあらゆる再帰が不可能ってまじ？
再帰テンプレートとかも？

>>336
それかっこいいね。
でも、俺の頭はまだ AOP に対応してないから、用途が思いつかん・・・orz

>>337
情報サンクス。
しかしよく纏まってるなぁ。

>>338
履歴によれば、初版は英語版の翻訳。
http://ja.wikipedia.org/w/index.php?title=C%2B%2B0x&action=history

へーすごいな
感心した

翻訳乙

どおりで訳文チックだとおもった

>>336
MyWindow win;
RECT *r = &win.windowRect;
external_library_function::foo(r); // rを弄る

こんなコードに対しても、フックを呼んで欲しいの？
いくらなんでも無理めじゃないか？

生のポインタの代わりに代入法・参照法を記述したサンクを渡せば桶

>>347
生のポインタはいつでも取れるんだから、何の安全弁にもならないし、
カプセル化になってない気がするけど

だから、生のポインタは取れなくて、メンバのように見えるものが欲しいという話なのでは？

それこそプロパティではないか

>>336 は「プロパティいらねぇから」と言いつつ、まさにプロパティが欲しいと言ってんだと思うっす。
対称性を考えれば参照時のフックも欲しくなるっす。

じゃあ、右辺値、左辺値参照のoperator導入な。

operator && () は入るんでしょ？

>>353 すでにあるわけだが、何のことかな？

operator && (void) ってokなの？

>>354
既に無いわけですけど、何のことかな？

二人の「既に」の時間が別な件について

operator && って、あれだろ、オーバーロードするとショートサーッキットが
利かなくてはまるっていう。

>>358
ttp://ja.wikipedia.org/wiki/C%2B%2B0x

で && で一通り検索してこい

operator && があるかないかなら、あるだろ。常考。

>>359
右辺値参照のために && が使われるようになることは知ってるけど、
operator && は昔から別の意味である。

いいから検索しろ、な

検索しても、 operator && について何が言いたいのかさっぱりわからない。

右辺値参照の&&はそもそもoperatorじゃなくてkeywordってこと？

&& を右辺値参照だけと勘違いしてる奴初めて見た。

>>365
物言いを直さないと大人になったとき苦労するよ

>>366
ｵﾏｴﾓﾅ

切り返しになってないなぁ。うん。

うん

もう大人だもんな

>>364
そもそも今までだって構文上、型名の*や&、[]、関数の()などは演算子ではない。
そこに&&が加わるだけ。

&&じゃなくて@とかにしなかったのはなんでだろ

参照なんですよ。という意味を込めたかったのかな

参照の記述に近いことと、字句解析に変更が要らないのがいいんじゃない？

>>372
それもあるだろうけど
新たなトライグラフが必要になるからだと思う

トライグラフは廃止の方向じゃなかったっけ

でもダイグラフとか代替表記とかあるし。

そんな提案があったの？
ドラフト(N2369)にはしっかり記述があるけど

しかし@がない文字コードってあるの?

>>378
っていう疑問がでてきて調査が必要になるので
新しい記号の導入はできるだけ避けたいと

既に無いわけですけど、何のことかな？
「既に無い」にめっちゃ吹いたw

#や[]にtrigraphがあるくらいだから油断禁物だな。
しかし@がないシステムは、dmr??.bell-labs.comとかやってんのかね。

>>371
後ろの「関数の」はいらないんじゃ?

>>381
つっこむところ、そこだけじゃないよ。

トライグラフ・ダイグラフって文字コードじゃなくて、
キーボードに対応するキーがない場合、ってのを問題にしてるんじゃね？
例えば日本語環境だとウムラウト付き文字を入力するの面倒だろ。

@ が無いシステムじゃメールが使いにくそうだねｗ
今となってはソースは Unicode、入力法はエディタやインプットメソッドで勝手に解決しろ、でいいと思う。

@なんて使われたらVCのマングリングが崩壊するから駄目です＞＜

あとは擬似コードで任意の演算子を示すときに使ったりするなあ

>>385
なんで VC のマングリングが崩壊？
リンク時のシンボルと演算子としての @ の関係が分からん。

>>378
ISO/IEC 646的には「#$[\]^{|}~@`」の12コードポイントが別文字になりうる
参照：ttp://ja.wikipedia.org/wiki/ISO/IEC_646

……んだけど、この文字コードで動いてるシステムって今どんだけあるのかなぁ

日本では改行は「￥n」と覚えてるし、英国人は「£include」で慣れているしね。
まあ過去の遺産でしょ。＞トライグラフ・ダイグラフ

けど、ソースがUnicodeになると、その慣れが一気に負の遺産に…

え？ソースをunicodeで書いても解決しないでしょ？

VC 2005とかunicodeで記述するのがデフォルトだけど、
バックスラッシュは相変わらず円マークですけど。

>>390
簡単に言うと、君の使ってるのが偽Unicodeだってこと
http://ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C

いい機会なんで円記号はバックスラッシュに戻してほしかったな

>>391
は？よく読めよ。何が偽だよ。

>これは日本語用のフォントデータの0x5Cの位置には円記号の字形を当ててしまうことで対処している

逆に言えば、U+5Cにバックスラッシュのグリフを持ったフォントを使えば、
バックスラッシュとして表示される。

まあその辺りに興味ある人は文字コードスレで。

フォントスレで事足りるな。

>>393
「簡単に言う」のなら、それは「偽Unicode」だろｗｗｗ

>>393
cout << "その本は500\です。\n" << endl;

同じグリフになったら、0x5cと0xc2 0x5cの見分けがつかないだろw
0x5cのYENだけ斜めにでもしとくのか?

VC2005でinttypes.hがつかえねーーーーーーーーーーーーー誰か代換え案ください・・・2008?

自分で作る

あGCCから持ってきました

Windows板行けよ。
C++0xに関係ないし。

boostつかえ

conceptは間に合うんだろうか

あ、concept は余裕で間に合うよ。安心しといて。
それより問題なのは export なんだよ。実は。

exportは実装されて実績も出てるが何が問題だろうか、と考えるに
メジャーベンダが｢ﾔﾗﾈ」と言い出してるあたりか
VCとgccは入れないんだよな、bccは最新版で入ってるらしいことは聞いた

extern inline とかな

concepts抜きでは送り出さんと書いてあるね。
ttp://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

知らん間にスケジュールが1年ずれてたんだな…

vs2008でどのくらい対応するんだろう・・・

vs2012くらいにならないと対応しないんじゃね？

g++0xとかになっちゃうのかな。
いままで3文字でやってきたのがちょっと気持ち悪い。
でもg0xとかだったら泣く。

VC++9.0でc++0xを実装するみたいだね

>>411
普通にg++ , C++ なりclなりでいいと思うんだが... C++/CLIなんていう類似品と違って正真正銘の時期標準規格なんだぞ？

拡張子が .cpp0x になってたら厭だな

むしろ全てのコードの拡張子は.txt

Content-Type: text/x-cplusplus0x-source; charset=utf-8
なんてメタデータが必須になります

C++0xはC++の新しいバージョンの仮称ってだけで
決まった後はただのC++だろ

無料のC++だよね

>>417
C90, C95, C99みたいに言葉は残るはず。
C++98, C++03, C++09かな。

>>413
CLIはISOに蹴られたんだったな

C++1x

ISO/IEC 14882:201x

来年の2月までミーティングないのか。
こりゃ本当にC++0aになりそうだなぁ。

C++0x0a
にすれば問題ないじゃないか

ぶっちゃけたところ、C++0xはメインストリームで使われる言語になれるのでしょうか？
なれるとしたら何年後くらいだと思いますか？

なれないだろうね。
組み込みとか、system layerの低いところ、e.g. OS kernel、では、
今後C++を使う例がどんどん増えていくと思うけれど。

ただC++がtemplateで行った実験は、
今後のプログラミング言語に大きな影響を与えると思う。
素晴らしい実験が今でも行われ続けている。

Embedded C++の覚醒と聞いて飛んできました

Embedded C++？どこにそんな情報が！？マジなら知りたい。

いやごめん、426の話を受けた冗談

>>425
まず、メインストリームが何かを定義してもらおうか

世間的には既に C++ がメインストリームではないからな。ｗ
C++ 族（？）の中では C++0x はメインストリームになると思うが。

Embedded関係ないのか･･･。
boost使えずやきもきしてたから小躍りしてしまったぞーーー！

Darwinのデバドラ・フレームワークのIOKitがEmbedded C++でしょ。
多重継承、template、name spaceないもん、boostは無理でしょw

難攻不落の女を口説いて落とすかのような面白さがある言語としてだな

それでもBoost.Preprocessorなら…Preprocessorならなんとかしてくれる

Embedded C++って本当に馬鹿な規格だよな。
フル規格のC++で、開発部隊毎にコーディング既約作ればいいだけなのに。
しかもまともなコンパイラすら作れないメーカが発起w

template使えないC++に用はありませんよねー

しかしEmbeddedでないC++コンパイラを作っても開発にコストがかさんで売れるかどうか。
そこらへんの妥協点を定めたのがEmbeddedなんじゃないの？

そんなひ弱な開発部隊が作ったコンパイラなんか使いたくないよ。
Cでさえ、マイナーコンパイラは悲惨だったのに。

いくら俺がネタにしたからって、おまいら叩きすぎです

>>436
同意。組み込み用ならランタイムが軽くなる仕様を考えるべきなのに、なぜかコンパイラ作りが
楽になる仕様にしたという馬鹿言語。
おそらく日本のマイコンメーカのソフト開発部門の能力に合わせたのだろう。ｗ

正直typeinfo以外にランタイムに問題になるものないでしょ。

自分で商用並みに完全な準拠コンパイラを作るにはどれぐらい手間かかる？

5人年くらいはかかるんじゃね。

>>441
ミニマムな規格にしていろんなCPU用に処理系が用意されるように、
ってのを目指したんじゃない？

ちゃんとした C++ を提供したいところは今まで通り gcc 等使うだろうし。

templateのexportを実装するのに3人年かかったらしい

込め合うの開発部隊って何人いるんだろ。

３人いるらしーよ。

少な！
でも多ければいいってもんでも無いか…

ラムダ式とクロージャが間に合うと嬉しいな

ラムダ式があるとサンプルプログラムが書きやすそう

あれ？ごめん、クロージャなんて入る予定あるの？

tr1::functionの事なんじゃまいか

あーなんか言い方おかしい…
ラムダとfunctionで似たような事ができるよってだけなのかな

>>452
ラムダ式の <&> で始まるやつのことじゃない？

functionってただの関数オブジェクトだよね？

>>455
やべぇ。また知らないものが出てきたぞ。
ラムダ式で <&> で始まるやつとやらの概要を教えて。

n2329の「7.1 The <&> form」読んでくれ。
半ページしかないから。
あとついでにn2413の「6.1 The <&> form」も。

n2329がgeneric版、n2413がmonomorphic版。

>>458
さんくす。
なるほどー。ただものじゃないな・・・この仕様。
ラムダ導入って単にちょっとした無名の関数を書けるだけかと思ってたけど、
実はちゃんとクロージャしてるんだね。
これ実装できるかねぇ。というかまず proposal が通らないと始まらないか。

とはいっても関数オブジェクトを手軽に書くための糖衣構文だけどね
でも喉から手が出るほど欲しかった甘さだ

ラムダ式＋クロージャが導入されたらコードはどういう風に変わるの？
変化を適当な例で示してくれよよよ

struct name_is
{
　string name;

　explicit name_is(string n) : name(n) {}

　bool operator()(cosnt employee& e) const
　{ return e.name() == name; }
};

void f(cosnt vector<employee>& es)
{
　auto found = find_if(es.begin(), es.end(), name_is("Stroustrup"));
　// ...
}

が

void g(cosnt vector<employee>& es)
{
　auto found = find_if(es.begin(), es.end(),
　　　　　　　　　　　　　　<>(const employee& e){ e.name() == "Stroustrup"});
　// ...
}

に

新キーワードを導入してもよかった気がするなあ

>>462
おー確かに凄い…
それと
> <&> form
<>の事だったのね･･･

>>463
「New function declaration syntax for deduced return types」
なんかを見ると <> の代わりに auto でも良さそうに思うね
auto の再利用が過ぎるか？

auto はちょっと怖いよね。
便利だろうけど、乱用するとコンパイラしか真実を知らない
なんてことになりそう・・・

意味、目的が全然違うじゃん。
lambdaの"<>"は、syntax上のconstructorで、
出来上がるものはfirst class objectだから。
typeについて何か言及するもんじゃない。

>>462
> 　　　　　　　　　　　　　　<>(const employee& e){ e.name() == "Stroustrup"});
これは、
< 　　　　　　　　　　　　　　<>(const employee& e)(e.name() == "Stroustrup"));
　あるいは
< 　　　　　　　　　　　　　　<>(const employee& e){ return e.name() == "Stroustrup";});
じゃない?

あ、n2329は { <式. } だったっけね。

うん、自分も記憶では式は () だったと思いながら
手近にあった n2329 を見ながら >>462 を書きました
n2413では () だね

>>467
まあ、そうなのかもしれないけど
n1978なんかを見ると auto を使うのもありかなと

mem_fun(&::f) より、<>(x){ x->f() } のほうが
インライン化が期待できる分、高速になる可能性があるな

>>470
n2329でいろいろな案が提案されて、
n2413で今の形に落ち着いてる。

>>471
Fig. 1 Example translation on lamba function. 〜
を見るとそう簡単な話でもなさそうだけど。
自由変数含まない時は、translationを最適化しないと駄目。

gcc拡張でクロージャできるけど、仕組みはあんな感じ？
でもあれマルチスレッドで破綻するよね。

>>474
関数内関数の事？あれC++だとサポートされてないよ

（　ﾟдﾟ）ﾎﾟｶｰﾝ

>>475
そうそれ。
g++でサポート外とかそういうことじゃなくてC++0xでの仕組みの話し。

>>477
lambdaは「式」なの。
レベル低すぎ。

>>478
シンタックス上はそうだね。
で例えばどういうバイナリになるのかって話。
レベルの高い人、解説よろしく。

translationがn2413載ってるから読め。
>>472に書いてあるだろ。

>>404
conceptsの策定はもう終盤だよ。
規格に入れる文言を練っているところだもの。
Libraryのconcept化は今回やらないし。(n2322)

微妙なのがthread。lambdaも油断ならない。

@ とか新しい文字を導入できないんだろうか。

今更無理だろ
@と$はいろいろ好き勝手使われてるから

>>481
たしかに08年の9月なら間に合うと思った
もうちょっと差し迫ってるのかと思ってた

C++1xまでお預けか…

いや、STLPortならやってくれるか？

コミュニティーからはconceptを使ったSTLの色々な実装が出てくるだろうね

もう出てますが…

詳細ごぼんぬ

遅ればせながらproposalやdefect reportを投げたい人向けのFAQ
ttp://www.comeaucomputing.com/csc/faq.html

コンストラクタのポインタって
出来ないのかなぁ。
例えば、

new (*p)();//コンストラクタ型ポインタの宣言
クラス名 *obj;//通常のポインタ

p=&クラス名;//コンストラクタのアドレス取得(実際はメタ情報を指す)

obj=new p();//オブジェクトの生成(メタ情報から本来のnewで生成したポインタを返す)

てな感じ。あればCallBacK関係で重宝
しそうなんだが、
問題はdeleteが…。

コンストラクタを呼ぶファンクタなら、今でもBoost.Lambdaに色々ある。
http://boost.org/doc/html/lambda/le_in_details.html#lambda.construction_and_destruction

消すほうはshared_ptrにでも入れておけばいいだろ。

テンプレートだと
void callback(new(*p)())
{
中略
}
void(*f)(new(*)())=callback;
f(&Type0);
f(&Type1);
って事は出来んだろ？
それと、
new (*p)=外部関数();
てな感じで別の翻訳単位のクラスを
取得するのも不可能だろ。

placement newじゃだめなん

Hoge hoge;
hoge.~Hoge();
new(&hoge) Hoge();

>>493
>>494
プレスメントだと同じ翻訳単位に
クラスが存在しないといけないから
無理だよ。
それと、さっきレスで
new (*p)=外部関数();
って書いたけど正しくは、
new (*p)()=外部関数();

あ､冷静に考えたら戻り値
の型要るな、
Type new *(*p)();
戻り値はポインタしかないから、
アスタリスク省略してもいい気も
する。
Type new (*p)();
一応Typeは渡すコンストラクタ
の親でも構わない(共変な型)。

こんな感じでどうよ。

どうよって言われても。このスレに書いたらC++0xに採用してくれるとか思ってんの？


つーか、そんなのテンプレートで定義すれば簡単に出来るから入らないよ。

というか、C++の関数ディスパッチのこと理解してないの丸出し

自信ないけどこうすればいい？
#include <iostream>
#include <boost/function.hpp>
#include <boost/shared_ptr.hpp>
template<typename T>
boost::shared_ptr<void> new_shared_ptr()
{
    boost::shared_ptr<T> p(new T);
    return boost::static_pointer_cast<void>(p);
}
struct mycls
{
    mycls() {std::cout << "constructor " << static_cast<void*>(this) << std::endl;}
    mycls(mycls const&) {std::cout << "copy constructor " << static_cast<void*>(this) << std::endl;}
    mycls& operator =(mycls const&) {std::cout << "operator =  " << static_cast<void*>(this) << std::endl; return *this;}
    ~mycls() {std::cout << "destructor " << static_cast<void*>(this) << std::endl;}
};
int main()
{
    using boost::shared_ptr;
    boost::function<boost::shared_ptr<void> ()> f = new_shared_ptr<mycls>;
    shared_ptr<void> ps1 = f(); //new mycls
    shared_ptr<mycls> ps = boost::static_pointer_cast<mycls>(pi1);
    *ps = mycls();
}

>>495
同じ翻訳単位にクラスが存在しなかったら、
作ったクラスを扱えんと思うのだが。

×作ったクラス
○作ったインスタンス

>>496
>C++0xに採用してくれる
>とか思ってんの？
確かにそうだが、実装されたい
機能の妄想ぐらいしてもいいだろ?
ここは2CHなんだから。

>つーかテンプレートで定義すれば簡単に出来る
マジで？
今のところ別の翻訳単位の
クラスでインスタンス化できる
テンプレート実装を見たことが
ないんだが。
exportですら同じ翻訳単位に
クラス定義が必要なのにどうやったら
できるの？

妄想はチラシの裏とか自分のブログとかでお願いします。ここは2chですよ。ｗ

クラス定義をヘッダに書いてそれをインクルードすれば、
こういう使い方では翻訳単位なんて問題ないだろ。

レベルが低すぎるから、他のスレに行って欲しいw

別の翻訳単位のクラスでインスタンス化できるテンプレートって表現がよくわからんから解説してくれ

>>501
は？
お前の案もクラス定義が必要なこといってますけど？それが？

>Type new (*p)();
>一応Typeは渡すコンストラクタ
>の親でも構わない(共変な型)。

クラスの親子関係はクラス定義がないとわからない。

動的型言語でもなければクラス宣言がないとどうしようもないべ。

つ スルー力

なんかロシア語っぽい響き

Type new (*p)();
こんな意味不明な関数ポインタ型を新しく作っても煩雑になるだけ。


ClassName* (*p)() = &ClassName;
と、既存の関数ポインタ型に入れられた方が便利。

これは
ClassName* create(){ return new ClassName(); }
という関数を用意して
ClassName* (*p)() = &create;
とすれば出来る。

あとはcreate関数をテンプレートで自動的に作れるようにするだけ

template<class Class, class Result>
struct Create{
static Result create(){ return Result(new Class()); }
};

ClassName* (*p)() = &Create<SubClass, ClassName*>::create;
shared_ptr<ClassName> (*p2)() = &Create<SubClass, shared_ptr<ClassName> >::create;


はい、テンプレートで出来ました。

何かきったねーな。

Createクラスをもっと複雑に作れば、
使う側はもっと簡易的に使うことも出来るけど、ま、それはきみへの宿題ということで。

そんな簡単な事にいちいちえっらそうだなw

客観的に見て、何も言わない癖に、文句だけはつけるお前の方が偉そうだと思う。

客観的に見て、どっちも大して変わらない。

文句や煽りしか出来ない低脳がウヨウヨ集まってきました。

関数ポインタを返す関数を１つ作るだけで見た目綺麗になる。

lamda使えばD言語並に綺麗にできるyo! 以下D言語。

class Foo{}
class Bar:Foo{}
void main(){
  auto p = {return cast(Foo)new Bar;};
}

以下見様見真似のC++0x。
class Foo{};
class Bar:Foo{};
int main(){
  auto p = <>()( Foo(new Bar()); );
  return 0;
}

>>506
面倒だから書きたくなかった
んだがしゃーない。

head.h
class A{…};
void f(A new(*)());

src1.cpp
#include"head.h"
void f(A new(*p)())
{
A *obj=new p();
}

src2.cpp
#include"head.h"
struct B:A{…};
void call()
{
f(&B);
}

こうすれば関数fはBを直接知らずとも
Bのオブジェクト生成できるでしょ？
それに、Aのメンバーを仮想化すれば
操作に支障はない。

さて、何やら俺が痛い子にみえて
来たんでそろそろお暇させていた
だくわ。

>>518
その例は、そこだけ切り取れば綺麗に見えるだけ。

例えばそのautoで受け取ったlamdaを他の関数に渡せないだろ。

>>510
それだと引数なしのオブジェクトしか
作れない訳だが

javascriptならできるな、あれば面倒が減りそうではある

function getCtors() {
return [
function () { this.name = "A"; }
function () { this.name = "B"; }
function () { this.name = "C"; }
];

}

var obj = new getCtors()[0];
//obj.name == "A"

>>521
Createを引数ありに改造するなんて簡単だろ

一つ言い忘れた｡この方法ならDLL間も渡せる。

意味不

>>524
templateでやってもDLL間でやり取りできる

>>520
D言語なら渡せる(Foo delegate()型)。C++0xはシラネ。

テンプレートとの本質的な違いは自分で生成関数を定義しなきゃいけないかどうかだけだよ

>>527
callbackとして使えるか？

>>529
D言語なら使える。C++0xはシラネ。

>>523
コンストラクタ毎に作るのか馬鹿だろ。
それとも引き数一つ取って一時オブジェクト
を渡しコピーするのか？
いずれにせよ利口ではないな

>>530
嘘を言うな。Dでも出来ないよ

>>531
どちらも違う。というかそんな方法しか思いつかないって頭悪いだろ。

boost::make_tupleみたいにデフォルトテンプレートパラメータ引数を使っての特殊化でなんとかするんだろう多分
多分vaultにあるshared_newみたいな感じで作るんだろうなぁというかそれしか思いうかばねぇや

>>532
できるっての。試してみ。

お前ばかだろ
いいやお前の方がばかだ
なんだと
以下略

>>490から、無駄レスだな。

>>537は今日から全人類の敵になった

>>526
DLL側にテンプレートを作って
呼び出すのは実質不可能
テンプレートをインスタンス化
させておく方法もあるが非効率
いったいどうやるの？

>>539
関数ポインタとして渡すんだよ。
なんでそんなこともわからないの？

だからー間に一段自前の生成関数挟むかどうかだけなんだってー

>>540
テンプレート関係ないじゃん
テンプレート使ってできる方法言えよ

>>542
お前このスレの何を見てきた。テンプレート使ってるよ。

馬鹿はスルーで。

しかし現実には
スルーできないのが馬鹿の特徴の一つ

>>543
関数のポインタによるDLL間の
やりとりにテンプレートが介在
する余地があると？

>>546
はいはい。ありますよ。

普通はファクトリクラスを作るけど、
それが面倒ってことなのかな？

>>548
馬鹿だから作れないし、作れると言ってる人が全員キチガイに見える、ってことでは。

確かにC++は自分が作れないものを軽々作れるキチガイが多いよな…

>>548
>>490辺りからずっとそういう話じゃない？
要はlamdaのようにいちいちクラスやら関数作らずに済ませたいと。

そしてキチガイの作ったものを素人が間違って使って原因不明のバグを出す

>>551
え？　そうなん？

519は「既存の仕組みだと　・・・ができない！」ってことを強調してるような気がするけど

元々はそういう話だな
既存の仕組みでもできるよっていう反論があったから
それじゃ便利にならないっていう流れで「〜じゃできない」って事だろ

コンストラクタの引数の個数を
全クラスで揃えるのもどうかなあと思わんでも無い。

boost/lambda/constructor.hppを見れば
既存の仕組みでも簡単にできることがよくわかるし
わりと簡単に思いつく、天才の閃きは要らない

>>555
FactoryMethodがその辺りのwrapperやってくれるわな。

結論 : boost を使え

C++0x → C++xx「できませんでした」

>>559
2100年移行までおあずけですか

Cxx

>>522を見て思い出したんだが
Objective-CにはClass型ってのがあったなtypeinfo
なんていらんからああいう型があってもおもしろいと思う。

C99とは相思相愛になれますか？

そういえば restrict ってどうなるんだ？無視？

相思相愛ではないけど、C99で追加された標準ライブラリは
一通りC++0xにも入るはず。

現在のところC互換部は C90 ってことになってるけど，
かといってそれが C99 になるわけではないよね．
予約語とか．

C99 の一部の機能は追加される。
可変個引数マクロとか _Pragma 演算子とか。

>>564
restrict 有り／無しでオーバーロードしたらどうなるんだろ。
コンパイラには判断できないよなぁ。

>>568
でもそれは欲しかったり。

type checkとname lookupの疑似コードってないのかね。

>>569
あってもコンパイラに判断できないっつってんだろ。

コンパイラがいる！

こちとらエラーメッセージ出すのもひと苦労なんですよ！
何回言ったらそのテンプレートの使い方覚えんだよ？

>>571
const同様に扱えば判断できるべ。

>>573
コンパイラに謝る上司の姿を想像して吹いた

>>574
restrictは引数以外での指定ができないからそれは無理じゃないか？

>>576
げ、そうなのか。

直前の文脈から考えて、restrictに相当すると断言できるかどうかを判断させることは可能だな。
ただ、restrictの有無で動作がかわらないようにしないとバグの温床になるけど。

void copy(char* src, char* dst);
void copy(char* restrict src, char* restrict dst);

f(char* s, char* t) {
char a[10];
char b[10];
copy(a, b); // 範囲が重複していないと断言できる
copy(s, b); // 範囲が重複していないと断言できる
copy(s, t); // 範囲が重複していないとは断言できない
}
g(char* restrict s, char* restrict t) {
copy(s, t); // 範囲が重複していないと断言できる
}

gcc/iccでc99としてコンパイルすると、これはfree()の呼び出しで型変換の警告だけで通るけど。
char * restrict * foo = NULL;
free(foo);
# gcc/iccでC++としてコンパイルすると型変換のエラーにはなる。

つまり、見かけ上はconst同様に扱われているから普通に変数に指定できると。
>576によると引き数以外での指定ができないとあるが、規格的にはどうなってるのかな。

スレ違いなんでスルーしたけど、普通に使えるよ。
6.7.3.11 EXAMPLE4 見て。

C++0xへのC99統合で、何か特別な処置でもしない限り、Cのスレでやってね。

>>580
うい、THX!

これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！

これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！

nullptrをぬるぽと呼ぶスレ

ぬるぽたぁ

ぬるーぽったー

これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！

これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！
これからもC++0xについて熱く語ろう！これからもC++0xについて熱く語ろう！

保守のつもりか？

そんなまさか

カラアゲヽ(´ー｀)ノ時代はカラアゲ！

static_cast dynamic_cast const_castのオーバーロードってどんな感じで記述するんだろうか。
使い方がテンプレートクラスっぽいから、やっぱり
struct someclass{
template<typename T> operator static_cast(T a);
};
ってなるんだろうか。

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-12-13: The 2007-12 mailing is available
News 2007-12-13: The C++ Standard Library Issues List (Revision 53) is available
News 2007-12-13: C++ Standard Core Language Issues List (Revision 52) is available

記念火気庫ヽ( ´∀`)ノ　ﾎﾞｯ

ってココＩＤ出ないのかorz

せっかくC++だったのに…

板ごとにID違うんだから意味ないだろｗ

なにやってんだｗｗｗ

きっと彼はどっかの板で ID が C++0x だったんだろう ... と信じよう

>>593
> N2485
> A variadic std::min(T, ...) for the C++ Standard Library

さっそくこういうの出てきていい感じですね。

>>599
kwskおねがいします

variadic macro、可変長引数を取れるマクロかな。

__VA_ARGS__ を使う仕様はなんとかならないかなぁ。
.NET みたいに配列（あるいは、記法だけでも配列風）にはできないもんだろうか。

template <typename T>
const T& min( const T& a) { return a; }

template < LessThanComparable T, typename ... Args >
requires SameType <T, Args >...
const T& min( const T& a, const T& b, const Args &... args )
{ return std :: min( b < a ? b : a, args ...); }

minテンプレートの可変引数に対する再帰

>>601
C99 との互換性なんだろうと思う。
他全てと互換性ない癖に今更と思わなくもないが。

>>602
重箱だが、const参照の引数を参照で返したらダメだよ
引数に一時オブジェクトが渡されるときもあるから

それは文脈しだいだろう
int x = min(min(1,2),3);

>>604
戻り値で作られた一時オブジェクトはconst参照で延命できるけど、
このばやい戻り値(const T&)はrvalueじゃないからダメってこと？
ダメってソースとかあったらｋｗｓｋ
延命できそうな気もしなくもないけど…どうなんだろう

一時オブジェクトの寿命は完全式の終わりまでだから、
605の場合、xの初期化を行うときはまだ生きている。

const参照で受ける場合も、それで寿命が延びるから
あまり問題にならないと思う。

伸びないよ
int const & x = min(1,2); // ダングリング

ググったらこんなの見つけた
ttp://it-reading.org/ebook/c%20faqs/content/0201309831_ch32lev1sec8.html

あー、昔書いたコード見直さないとあかんかも...orz

GCが導入されたら、ほとんど変更せずに済むかも
・・・は甘いか。

えーと、そもそも関数の戻り値をconst参照で受けるって使い方はありなんだろうか。

スレ違いだろ。

>>606
これ戻り値はrvalueじゃないの？

>>602の戻り値がconst T&で宣言されてるから
俺だったら戻り値をconst T&で受ける書き方をしても安全だと期待するなあ
だからこそ危ないよっていう指摘なんだろうし。

まあそういう言語だから仕方ない
iterator i = string().begin(); // ダングリング

const参照でのみやり取りできるすまぽ作ったら便利じゃね？と思って
const smart_ptr& returns_pointer(const smart_ptr& sumapo)
こんな関数に渡したらreturn時に見事にデストラクトされた私が通りますよ。

どうせ最適化効くからコピーされてもいい

VC8のstlだと、min, maxはしっかりconst参照を返してるな

>>618
返すのはいいんじゃない？問題になるのは
＞const参照で受ける場合も、それで寿命が延びるから
＞あまり問題にならないと思う。
こういう誤解をして、const T& hoge = min(..); と受けてしまった場合だけだから。

>618
だって規格でそうなってるんだもんよ。

なんつうか名前マングリングを少しは統一しようや
とか
ABIをある程度規定しないか
とか
その辺の動きはないのかねぇ

名前マングリングを統一した所で、
this をどう扱うかとか
例外をどう扱うかとか統一しないと意味ない希ガス。

>>621
互換性を考えると、どの処理系もいまさら変えられないでしょ。
せっかく決めても誰も使わない可能性大。

互換モード残せばいいだけじゃ

互換モードでもC++0xを謳えるの？

>>621
いりません

http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
これを読むとC++のことぼろくそに書いてあるんだけど、
本当のところはどうなんだろうか。

自分としては boost::lambda とか強力なメタプログラミング
ライブラリもあるし、好きなんだけど・・・・
なんかね、俺、流されやすいのよ。

そりゃ業務では好き嫌いなく必要な言語使うけど。

実戦重視の人で、型システムについては全くの無知。
以前多重継承について犯した過ちを、今度はgenericsに対して犯している。
具体的にはconcept, interface, signatureあたりに対する無知。
というのが感想。

型システムについて語りたければ、Haskellのtype classくらいは勉強しないと。
今や型理論を知らないと型システムの良し悪しについて語れない時代。

VCに入らない限り90%近くの環境で無意味と思うんだが。

>>627
的を得てると思う。趣味でコード書いている人ならともかく、
C++が大きなクソの山を作り出す、というのは多くの開発現場で実際起きていることだし
これを無知な奴のたわ言と切り捨てるのは、よほど恵まれた環境で仕事しているか
逆に実際の開発現場を知らない、それこそ無知な人でしょ。

蜂とか蟻ってさ、7割がせっせと働いて3割は巣でごろごろしてるんだぜ。
つまりオマエらNEETは勝ち組み？みたいな。

それを言ったら90%近くの人はC++なんて使ってないだろｗ

たまには某ランドの事も…

VC で C++ しているひとの数と (除く C# その他)
gcc で C++ しているひとの数をくらべたら、後者のほうが
多かったりしないかな？しないか。

>>633
あの社名だかブランドだかがコロコロ変わる会社のことか？ｗ

C#やVB.NETに移ったとはいえ、まだVC++利用人口多いと思うなぁ。

そこらで売ってる窓のパッケージソフトから
VC製除いたら殆どなくなるんじゃないの？

逆に、UNIXの世界だと、C++のウェイトなんかそんなに大きくないし。

パッケージソフトという分野自体がマイナだけどな

>>604
これって標準ライブラリの定義をそのままvariadicにした>>599だよね。

変態的な仕様をやっと覚えたのに、
仕様が変わるのかぁ・・・

どんどん変態するんですよ

>>630
クソの山を作り出してるのは「C++」なのかね？
実際にはSTLだのBoostだの以前にプログラミング技法さえ身についてないヘボグラマが"普通の"プログラマ扱いになっている性だと思うんだが。
そんな連中はJavaだろうがPHPだろうがVBだろうが結局クソしか出せないわけだろ。

実際問題たかがプログラミング言語ひとつ、C++ごときでヒィヒィ言ってるようなやつが「実践」「実用」なんていったい何処のサル山のボス猿気取りですかって感じ。

いやいや、そんな連中でもJavaやPHPやVBなら「仕事」を出来てしまうんだよ。
そういう連中が仕事で使っても比較的被害が少ないように設計されている言語だからね。

クソな連中だが、そういうのが世の中の９割らしいぞ。ｗ

> そういう連中が仕事で使っても比較的被害が少ないように設計されている言語だからね。
それは幻想というものだ。

PHPやVBがC++よりも良いというのはいくらなんでも言い過ぎだ
あんなのニッチにうまくハマッただけの言語じゃないか

6、7年前のコミュニティーが使い方をわかってなかった頃のC++なら糞に見えるかもしれないが
いまはC++は凄く良い言語じゃないか？

>>643
JavaやPHP,VBにしたってクソが勝手に使い物になるような魔法は仕組まれてないよ。
手続きと関数の区別もつかないようなやつが書いた、どうせ数週間後には1から書き直されるようなソースコードに資産価値なんぞないわけで、
兵卒のレベルに合わせて入門書そのままのクソもデータ構造なんて存在しないゴミソースの山に、それを正常動作させるために膨れ上がった無用なテストの山
WordだPDFだの装飾がついてることありきでそのためメンテが面倒で追いつかないドキュメントもどきに、何もかもが手動、人力管理の非効率プロジェクト。
そんなクソの万魔殿のなかで、せいぜい後に残る知識・資産が業務の片手間に残したメモ書き数枚なんて状況で、ちゃんとした「仕事」をこなしたなんて恐れ多くて言えたモンじゃないよ。
どうせそうやって作った成果物だって妥協の限りを尽くして作り上げられた代物で、当初の要求に似ても似つかないようなスクラップじゃ納品した矢先に客先に「使い物にならん」と言われて終わりだよ。

ただまぁ、C++ だと落とし穴が多いのは確かだと思う。
禿もこう言っていることだし。
>C++ has indeed become too "expert friendly"
ttp://www.technologyreview.com/Infotech/17831/page2/
それなりのコードが書けるようになるまでの閾値が高すぎると思うんだわ。

>>646
よく嫁。使い物になるなんて言ってない。「仕事」になるってだけ。
一緒に仕事したいとは思わんけど、あいつらがそれで喰ってる事実は否定できん。

まあ 646 は仕事で辛い目に毎日あってるみたいだから、許してあげようよ...

>>647
まあテンプレートメタプログラミングに始まり、関数型、オブジェクト指向手続き型、抽象データ型の扱いなど、「使いこなす」には大変だと思うよC++は。
でも、クラスベースのオブジェクト指向手続き型言語として、類似のJavaやC#の公約数的部分だけでも理解して使えれば十分なんだが、そこまでいくのもそんなに難しいものかねぇ･･･

>>648
よく読んだ。確かに対価はもらっている以上「仕事」としては成立しているわけではある。
無駄に噛み付いてすまんかった。

C++は今後もプログラミング言語の実験場であり続けるだろう。
だからC++0xの話をして、プログラマ板向きの話題は窓から捨ててしまおう。

俺が今勉強中なのは、late_checkの、

ConceptGCC Developer's Blog
Late-Checked Templates, Revisited
January 18, 2007 by Douglas Gregor

So, in a discussion with Jaakko Jarvi, we decided that the right
approach is to change the granularity of late_check. Instead of
operating at the level of expressions or types, it acts at the level
of entire templates.

のところ。

さんざん言われてるけど、2009年までにまとまるとは思えない

2015年までおｋ

なんとかまとまるだろ。
ただ、もう「C++0xの次」みたいのが言われ始めてるからなｗ

もう 1x ってよばれてね？

C++xx でいいじゃん。

Cxx

C+++

C#-

C++xxxxxx

西暦999999年までに決まればおｋ

その頃には西暦なんてなくなってるかもしれないぞ

C++0079

C++0083 STARDUST MEMORY

私は帰ってきた！

C++0x2010

つか今更だがthreadすげえな。
何がすげえって、今までライブラリなりがガリガリ実装してたものを
言語が仕様だけ定めてあと実装はベンダに丸投げってその思想がすばらしい。
その手があったか、ってｗ

>>666
意味不明。ベンダとかライブラリって具体的には何をイメージしてる？

言わせとけよ
いちいち突っ込んでスレを荒らすな

ついでに言うと、threadに限ったことではないだろ、それ。

C/C++自体が環境依存って言うことも無きにしも非ず。

今の環境（CPUとかOS）はほとんどC/C++と整合するように作られてるな。
昔のメインフレームはワードアドレスマシンとかあって整合性が悪そうだ。

ほほぉ、CがPDP-11用に作られたと言う事実は無視かね。

知識自慢はよそでお願いしますよ・・・

そうだね、頭の足りていない>671はさておき、>672はスルーすべきだったね。

つーことで、>671-674 はまとめてスレ違い。

ｶﾞﾍﾞｺﾚは本当に入るのでしょうか？
ｶﾞﾍﾞｺﾚ対象となるクラスはまた特別な
クラスから継承しなければならないとか？

どっちにしても、何も特別なことをしなければGC対象にはならないから安心汁

ｶﾞﾍﾞｺﾚｷﾀｺﾚ

ガベコレくるの？
ユニークカウンタ（俺語です。）で処理すんの面倒なんでぜひ入ってほしい。

使うかどうかは選べるんだから、(typeinfoのように)
とりあえず実装非依存な形で仕様に出来るかどうか研究して頂けると嬉しい。

n2310をチラっと読んでみたけど新しいキーワード導入しすぎでしょ
これは当分入らないと思う

ちゃんと読めばそんなことない？

以前ハゲの人が提案してた
#scope
#endscope

みたいなのは入るのかな

それ{}が打てない地域用？

>>682
トライグラフだっけ？それじゃだめなのか？

もうそろそろプリプロセッサには退場してもらいたい
#includeだけでいいよ

>>684
ifdefが無いとassertもできなくね？
ifdefなんて無いに越したことはないが、必要な部分はあると思うんだが。

今更プリプロセッサ廃止したらBoost.Preprocessor使いまくりの俺のコードが全滅する

>>681
プリプロセッサ用のスコープか？

世界はプリプロセッサで出来ている

>>687
そうマクロを制限する。
scope外のマクロ全部無効になって、
scope内のマクロはscopeの外に定義が出ない。
ただし必要なものだけimport/exportできる。

#undefよりはスマートに書けるが、
泥縄的だから標準には入らないと思う。

namescapeを導入した時に、マクロ名も識別子と同様、
namespaceに入ることにしたら良かったんじゃないか。

まあ「プリプロセッサ」である限り使い勝手は悪いわな。プリプロセッサを廃止して必要な機能を
言語側でちゃんと実装すべきだと思うが、そうするともう C++ とは呼べないだろう。

>>689
コンパイルフェーズでプリプロセッサが分かれているんだから、
namespace を解釈させるってのは難しいだろうね。

なーんちゃってプリプリー

でもさ，プリプロセッサのおかげで
あんなことやこんな変態プレイができるんだぜ？

プリプロセッサがチューリング完全だったらいいのに

プリプリ中学生！

ttp://blogs.msdn.com/vcblog/

C++0x standard

え？！チューリング完全じゃないの？
てっきりそうだと思ってた

LISPのマクロはチューリング完全だけど
C++のプリプロセッサがチューリング完全だとは聞いたことが無い。
テンプレートはチューリング完全だけどね。

Boost.Preprocessor使えばチューリングマシンぐらい実装できそうな気もするけど
規格でネストのレベルの上限が決まってるとかかな

まぁスレ違いか

>>697
m4マクロみたいに再帰的定義ができません。
>>698
テンプレートは原始帰納関数しか計算できないのでは?

ビョーン様をハゲと言うのはやめろ！

権威を自分の下に置くことによって優越感を味わっているだけなんだよ
技術力の低い賎民の僻みなんだから気にしたら負けだ

禿は愛称です

いじめではなくプロレスごっこです

禿は偉大だ・・・俺も禿るように頑張るよ。

禿かわゆす

ビョーン・ザ・バルドヘッド

Boost.Preprocessorはすげえよ
Boost.MPLやBoost.Lambdaはがんばれば出来る
(かもしれない)

Boost.Preprocessorは絶対に無理だ

>>700
アッカーマン関数なら計算できるけど。

template <unsigned long long m, unsigned long long n>
struct Ack
{
%9static const unsigned long long value = Ack<m-1, Ack<m, n-1>::value>::value;
};

template<unsigned long long n>
struct Ack<0, n> {
%9static const unsigned long long value = n+1;
};

template <unsigned long long m>
struct Ack<m, 0> {
%9static const unsigned long long value = Ack<m-1, 1>::value;
};

template <>
struct Ack<0, 0>
{
%9static const unsigned long long value = 1;
};

うわ、タブが文字化けした。
もっかい

template <unsigned long long m, unsigned long long n>
struct Ack
{
static const unsigned long long value = Ack<m-1, Ack<m, n-1>::value>::value;
};

template<unsigned long long n>
struct Ack<0, n> {
static const unsigned long long value = n+1;
};

template <unsigned long long m>
struct Ack<m, 0> {
static const unsigned long long value = Ack<m-1, 1>::value;
};

template <>
struct Ack<0, 0>
{
static const unsigned long long value = 1;
};

>>700
チューリング完全だという論文がある。
http://d.hatena.ne.jp/earth2001y/20060929/p2

底学歴でさーせんwww




チューリングなんてまったく知らないんだけど、勉強した方がいいかな？(;´Д`)

少なくとも勉強したほうが悪いということは無いと思うぞ

知らなくたってPGは務まる。ってか大多数の職業PGは知らないと思う。

でも少なくとも情報工学科でたやつは習うでしょ

気になるなら調べりゃいい。それが勉強だ。

>>715
情報系出身だけど一切授業ではやってないよ。
http://ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E7%90%86%E8%AB%96
↑のページで授業で触れられたものはO記法くらいだなぁ。

情報系いうてもピンキリやな

ウィキペディア読んできたけど意味わかんね(;´Д`)w

授業でやった．しかし忘れた．
その時教科書使ってない．
センセのパワポだけ．
SIに就職後だけど，情報系出てるのに恥ずかしい．
いまさら何読めばいい？
英語は何とか問題ないと思うので英語の教科書でも．

次のレスでエロい人が読み物を列挙してくれる予定．
↓

つttp://wiredvision.jp/news/200710/2007102622.html

チューリング完全なんて数学の知識が要るから必要ないよ

知ってるに越したことはないけどね

美少女中学生と完全なチューをしている状態！(*´Д`)'`ｧ'`ｧ

数学の知識が無いのにそういう仕事してる時点で下流決定だろｗ

時点で、とか書く時点で厨レスだろｗ

2chやってる時点でｒｙ

>>726
厨リング完全なレスだな

>>728
誰がうまいことを（ｒｙ

まあしかし、すでにプログラムをかけるひとはチューリング完全のあたりを勉強するのはぜんぜん難しくないと思う
数学の記法つかってかいてない本とかあれば、だけど。

ありそうだな

あるよ？

include guard書くのが馬鹿らしいので#includeのプリプロセスで勝手に弾いてほしい。

#pragma once

pragma onceがなかなか標準にならないのは
いろいろ難しい問題があるらしい。

知らんけど

#pragma once って gcc でも vc でも使えるよね．

windowsのヘッダを通さなきゃならないコンパイラはみんなonceは通すよ

#pragma twice

>>735
一言で言えば、何で同一性を判定するのかという問題だね

インクルードガードを内部的に自動生成したのと同じ形に動作する程度でいいと思うんだがなあ。

その内部的に生成する際に、識別子をどうするかが問題なんでしょうが

GUIDを使って後は神に祈る

内部的に自動生成したのと 「同じ形に動作する」 わけだからどうとでもなるべ。

同じファイルに複数の名前がついてるような場合とかどうするのって話。

ローカルにあるファイルを、
直接と、ネットワーク越しにとでアクセスする場合とかか？

シンボリックリンクされてる場合とか。

「そういう場合は処理系定義とする」 でもういいじゃん

いちいちヘッダを比較すればいい
違う名前だろうがなんだろうが一字一句同じなら同一としていいはずだからな

同じファイル名が別の場所にあって名前も内容も同じ場合ってのがシステムヘッダ
などでよく起きる。さらに内容はほぼ同じ（バージョン違い）とか考えだすときりがない。

それに関しては絶対パスで区別すりゃいい。
リンクされてる場合は、同一実体を指しているかもチェックする。
ただ、このあたりは環境依存な話が多く出てくるので
もう 「処理系定義」 でいいと思う。

提案書を書いて委員会へ提出よろ

そんならもう#pragma onceの扱いは処理系定義でいいじゃん。

そもそも pragma の扱いは処理系定義だｗ

#pragma onceってファイル内の中途半端な位置に書いてたり2か所に記述したりしたらどうなるんだろ

処理系定義だろ

>>752
ﾜﾛﾀ

#pragma once

#pragma once は同一ファイルの二度目以降のインクルードを無効にする。
ファイルの同一性判定の方法は処理系定義とする。

ファイル A の中で #pragma once が処理される前に #include があり、
その中でファイル A がインクルードされている場合、
#pragma once は効力を発揮しない。

#pragma once はファイル中に１カ所にしか出現してはいけない。

#pragma once(unique-id)
ちょっとタイプ量は増えるけど、こう書くようにすればいいんじゃなかろうか。
従来のようにidを省略したら、
#pragma once(__FILE__)
みたいになって、ファイルの同一性の比較は処理系定義と妄想

>>748
じゃだめなん？

全く同じファイルのコピーが二箇所にあって、両方ともincludeされてて、
なんかの拍子に片方を編集したら、コンパイルとおらなくなる。

鬱陶しくないか。

>>758がいいな
同一性はプログラマが定義することもできるし、コンパイラに任せることも出来る

普通にインクルードガードでいいだろJK

>>762
よく ifdef endif の対応関係がずれて
あわわわ〜ってなる（笑

>>763
それは言語仕様でフォローすることではないな

>760
コンパイル通るようになったらなったで、
何からの拍子で、片方だけ、構造体の構成とか変更すると、
実行時に訳わかめなエラーになるんじゃねーの。

こういう仕様を考える時は「やっちゃいけないこと」から考えるといいぞ

include回りの問題の多くはModules in C++(N2316)が入れば解決じゃね？
仕様が固まる頃にはC++20くらいになってそうだけど。

もうプリプロセッサなくていいよ

>>768
まぁそういう意見もあるよな．
しかし過去の遺産のことを考えると
プリプロセッサの挙動をもっと厳格に
規格化したうえで存続した方がいい．

Cでプリプリ！なんていやらしい！

modulesを入れるとなあ、
exportどころじゃないぞ、実装の手間が。

templateもconceptも、実装をヘッダでincludeすること前提だしな。
必要な情報を全部中間言語に書き出すとなると大変。

もはや C++ ではない気がするなあ

D言語においでー

DはC++0xの実験的な実装

include guardも#pragma onceも、インクルードされる側のファイルに書く。つまり、読まれたかどうかはファイルを開かないと分からない。
なんつーか、Obj-Cのimportみたいのが欲しいんだよね。あれって多分開く前に同一性チェックをしてるでしょ。（#pragma onceもそうなのかな？）

美少女中学生のインクルードガードは固くないほうがいいなぁ
もしくは自分で破っちゃったりしててアアーッ

つttp://pc11.2ch.net/test/read.cgi/tech/1142089873/

16.6.1 #pragma once

　　　　#pragma once po-identifier_opt new-line

po-identifier:
　　　　identifier or
　　　　( identifier )

#pragma once は同一ファイルの二度目以降のインクルードを無効にする。
identifier が指定されている場合は、identifier が同一である場合に同一ファイルであると判定する。
identifier が指定されていない場合のファイルの同一性判定の方法は処理系定義とする。

ファイル A の中で #pragma once が処理される前に #include があり、
その中でファイル A がインクルードされている場合、
#pragma once は効力を発揮しない。

identifier の指定の無い、または同じ identifier を持つ #pragma once は、
ファイル中に１カ所にしか出現してはならない。

Cプログラマ必須テキストです！

http://mori.eco.to/

俺はC++だから必要ないな

おまえがC++だったのか！

>>780
お前のせいで！

>>782
お前がハゲなのは親のせいだ。

C++のせいではなかったのか…orz

>>779
普通のC言語入門書っぽいな。
経験のあるプログラミング言語をわざわざ列挙してるのが何か笑える。

「普通の」じゃないだろ。
寧ろ本人曰く、「世のCを教える立場の人間は押し並べてCを判っていない」とのことなんだから。

>>785マルチ宣伝レスだから反応しないように

まともな本ならこんな宣伝しないよ

ｽﾏｿ

ハゲが怖ければ大豆イソフラボン摂れば良いよ。女性ホルモンに似た働きをして
ハゲや不本意な勃起を抑えてくれる事が医学的に証明されている。

>>790
ありがとう。さっそく試してみるよ。

結論は納豆というわけか

やっぱ豆蔵がいちばんっしょ。

>>790
俺の体で効果がない事は、俺の実体験により証明されている。

美少女中学生のいやらしいお豆！

あげるな危険。

最近C++0xを勉強中なんですが

decltypeは静的な型を表すんでしょうか

class Derived : public Base
{}

Base* pb = new Derived();

std::cout << typeid(decltype(pb)).name(); //Baseと表示?Derived?

静的な型を表す。

>>798
ありがとうございます

実際に試せればわかるのに・・・

と思ったらconcept gccなんてのがあるんですね
ちょっと遊んでみます

decltype(pb)はBaseではなくBase*では？

operator[]　()　=　->　*

C++0xでこれら演算子をグローバルに定義できるみたいですが、
どういう意図で導入したんでしょうか

それは初耳。

右辺値参照でT & &&がT &になるというのが納得できない。
例えばN1377には右辺値を左辺値に変換する関数moveが載っているが、
template <class T> inline T&& move(T&& x)
{ return static_cast<T&&>(x); }
moveを使った次のような(自然な)コードは動かない。
void foo(move_ptr<Bar> &d, move_ptr<Bar> &s) {
    (何か例外を投げる可能性がある処理)
    d = move(s); // 処理に成功したらsをdに移す
}
N1377やN1385で導入している型推論のルールによると、
Tはmove_ptr<Bar>ではなくmove_ptr<Bar> &になる。
するとmoveはmove_ptr<Bar> & &&型、つまりmove_ptr<Bar> &型を返すことになる。
上のような処理をしたければ、次のように直接static_castするしかない。
d = static_cast<move_ptr<Bar> &&>(s);

T & && = T &とする根拠として、N1377では次の例を挙げている。
compressed_pair<T1, T2>::compressed_pair(compressed_pair&& x)
    : first_ (static_cast<T1&&>(x.first_)),
      second_(static_cast<T2&&>(x.second_))
{}
が、そもそもpairのような値型オブジェクトが参照をメンバに持つこと自体
かなり特殊なことなんだから、こういうのはcall_traitsで処理すべきだろう。

move_ptr<Bar> const&を引数に取るoperator =が無ければ大丈夫。ConceptGCCでやってみた。
struct c
{
c& operator =(c&&);
private:
// c& operator =(c const&);
};

template <class T> inline T&& move(T&& x) { return static_cast<T&&>(x); }

void f(c& x, c& y)
{
x = move(y);
}

また、N1690ではこのmoveの戻り値の型が
typename remove_reference<T>::type&&になっている。
これなら、上のコメントアウトを外した状態でもコンパイルできた。

>>803
最新の draft などでは>>805さんの書かれているように
move の定義が変わっているので，単に d = move(s) の構文で大丈夫なはずです．

>>804
そのように参照型を取る事例への対処を
より汎化した規則で書こうとした結果が，
現在の reference collapsing rule じゃないんでしょうか？

>>804
あと，複数引数などの forwarding を pair や tuple の形で行おうとすると，
普通に pair や tuple が参照型のメンバを持つ場面はあるように思われます．
そのような場合に，現在の reference collapsing rule だと
pair<T1&,T2&&> && や pair<T1&,T2&&> & に対して自然に collapsing rule を分配して
pair<T1&,T2&&> や pair<T1&,T2&> と同等に捉えられますので
割と自然なように思えます．

>>806
compressed pairはおまけ的な例で、真の目的は
template <class T>
inline T&& forward(typename identity<T>::type&& t)
{ return t; }

template <class T, class A1, class A2>
shared_ptr<T> factory(A1&& a1, A2&& a2)
{ return shared_ptr<T>(new T(forward<A1>(a1), forward<A2>(a2))); }
のような転送を実現することみたいだね。
でも、だからといってT & && = T &のような直観に反する変換や
C++98の考え方と全く違う異様な型推論を導入するのはどうかと思う。
今まで型推論でさんざん苦しんだのに、またバグの温床を生むことになる。
もっと明示的に、「右辺値か左辺値か教えてくれ」という演算子「&?」を導入して、
template <class T, class A1, class A2>
shared_ptr<T> factory(A1&? a1, A2&? a2)
{ return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); }
と書ければ、プログラマの意図もはっきりするしC++98から大きく離れることもない。

>>807
参照型のメンバを持つpairだのtupleだのは、
代入演算子を持たなかったりswapが参照先を入れ換えちゃったりするわけで、
そういうものを「自然」に扱える必要はないでしょう。

>808
＞C++98の考え方と全く違う異様な型推論
右辺値参照型をパラメタとする関数テンプレートの型パラメタの推論に関して
言及されてるならそれは同意します．もう
template<class T> void f(T&&);
の形は perfect forwarding のため (だけ) にあると理解したほうが早いと思います．

>>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 は排除してほしくないです．

やべぇ高度過ぎてわからん

へぼぐらまの俺にもいまいちわからん
0x の改修って一般のC++プログラマに受け入れられるのか？
なんか、実用する人たちから遊離した規格のような気が・・・

>>813
そんなに大変な非互換性は取り込まれないと思うから、一般のプログラマは現状の
規格に不満がなければ気にしなくてもいいでしょ。

受け入れられるかどうかっていう点では、規格の変更に対応するかどうかという話で
コンパイラベンダの反応が問題だと思う。

>>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が必要になる、と。

ライブラリ書くようなエロいプログラマさんが頑張って書いてくれれば、
使ってる側からはあんまり気にしなくてもメリットはあると思う。
あと、この辺のおまじないは std::forward とか、std::move とかの裏側に隠されるし。

>808
>でも、だからといってT & && = T &のような直観に反する変換や
どうなるのが望ましい？

その辺をおいといても、&? の方が明快なのはそう思う(これ static_cast も必要なくね？)。
やってること自体は今の && の反転みたいなものだし、ルール的にも決めるのはそう難しくなさそう。
欠点は &? が増えるってことだけかな？
今更無理だろうけど誰か提案書いてくれw

>>816
型の一番右側に&&が付いていれば、オブジェクトを移動してほしくて
わざわざ&&を付けたんだから素直に言うことを聞いて欲しい、と思う。
逆にT && &は(出現する場面を思い付かないけど)T &になってほしい。
> (これ static_cast も必要なくね？)。
{ return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); }
のこと？a1, a2という名前が付いた時点で左辺値になってるからstatic_castは必要。

>>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 は名前の付いた他のオブジェクトを指しているため，これはまずくないですか？

>>813
いま問題になっている右辺値参照。
それによってもたらされる一般的なムーブ・セマンティクスは、
例えば関数の戻り値や、vectorで内部バッファリサイズ時の移動などといったときに
無駄なコピーの削減に役立つ。

＃もちろんそれだけにとどまらないけど、それはとりあえず置いておく。

で、何が言いたいかって、各人がほっといたって、
ライブラリの中の人が頑張るために使うから、
気付かぬ内に恩恵を被るかもしれないよってこと。

move　semanticsなんて全コンテナ修正だな

T&&のオーバーロード足すだけでいいのかな

>>818
mypair &operator=(const mypair &src);
mypair &operator=(mypair &&src);
という一般的なオーバーロードを前提にすれば、
後者が呼ばれるのは故意にmoveする場合に限られる。
だから名前の付いた他のオブジェクトをmoveして正解。

ごめん大嘘。関数の戻り値として参照を含むmypairを値で返されたら
後者の方にマッチしちゃう。これは確かにまずい。

アクロバティックな性体験を体験した美少女中学生のような気分になった

同じくヘボグラマの俺には、辛うじて意味は分かってもどうしても内容に関しては受動的にならざるを得ない。

そろそろ移動するべきかなぁと思ったのでこっちで。

【C++】STL（Standard Template Library）相談室 8
http://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);
}

あんま自信ないけどどうだろ？

ムーブコンストラクタの呼び出しが最適化で削られるなら
いいのかなあと思った。

>>826
func の return 文の std::move は不要では？

>>827
move constructor は副作用を持つでしょうから
これを参照で返すのと同じにまで最適化するのは結構厳しい要求かと

結局そんくらいのコストは勘弁してやれ、
それが嫌ならオーバーロードしろ、ということか。

move は一般にリソースの確保・解放を伴わないでしょうから，
そこまでシビアに move が重くなる状況はあまりないとは自分も思うのですけれど．

ただ std::string においては，例えば短文字列最適化を採用していると
move を使っても内部の文字列のコピーが発生するので，
4つのオーバーロードをまともに書く意義はあるのかなぁ，と．
それに4つのうち2つは他の実装に forward すればよいだけですし
そこまでオーバーロードが苦になることもないかと．

そういう引数が４つあった１６個か。

Boost.Operatorsに期待。

引数に関して言えば、
右辺値参照なんてものを導入するより、
右辺値→左辺値 変換演算子を導入した方がいいと思う。

どうせ戻り値はテンポラリオブジェクトとして作成されてて、
基本型でもなければ大抵メモリ上にあるわけで、
内部的には変換なんて行う必要はないはず。
基本型とかなら、テンポラリオブジェクトを作成して、
そのテンポラリオブジェクトへの参照を返せばいい。

const 参照へならここら辺勝手にやってくれるけど、
非 const 参照へもできる手段を与えてやるって感じ？
自動的に変換されるのはおそらくマズそうなんで、
キャスト演算子の導入でなんとか。

突発的！ちら裏!!

１、SingleInt型かByte型を導入してくれ。。。
char型はiostreamで文字として解釈されてすごい不便。俺は文字じゃなくて１バイトの数字を書き込みたいんだ。。。
バイナリ指定してるはずなんだけどなぁ。@VC

２、Enumの名前ちゃんと考慮してクレイ。名前何のために付けてるんだか。。。
2種のEnum宣言したときの別々なのにメンバの多重定義できなくてメチャクチャ不便だ。
片方に宣言してもう片方に設定しようとすると型変換エラーでるし。
ゲームでステータス設定するときEnum重宝するんだがなぁ。

2の方はC++0xになかったっけ
enumにスコープがつくはず

charとsigned charとunsigned char

>>836
みんなbasic_istream/basic_ostreamに対するoprator >>/operator <<が定義されている。

>>834
ios::binaryってことじゃなくて？

>>835
おぉ、ありがたい。

>>834
一応ｙってみたけど、なんか意図どおりにならなかったなぁ。
自分の不具合かもしれんが。。。

ミス。

>>834じゃなくて　>>838

foo(lvalue_cast(bar()));

integer semantics

template <typename T>
　T& lvalue_cast(const T& rvalue)
{
　return const_cast<T&>(rvalue);
}

何だ。今の C++ でも書けるじゃないか。
当然文をまたいで使う事はできないが、
move semantics なんて無くてもいいんじゃないか？

>>843
ムーブとコピーの区別が付けられなくないか？

>>844
引数は const 参照だが、
あくまでこれはテンポラリオブジェクトを作成するためのものであって、
引数には左辺値を渡してはいけない。
あくまで右辺値を左辺値に変換する際にしか使わない。

さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？

いや待て。
別に左辺値を渡してもいいのか。
単にそれがそのまま返されるだけで。
const な左辺値を渡してはいけない、だな。

>>845
ごめんわからない。例えばこういう区別はどうなるの？
class Hoge
{
public:
Hoge(const Hoge&);
Hoge(Hoge&&);
};

Hoge f();

Hoge x;
Hoge y = x; //コピー
Hoge z = f(); //ムーブ

>>845
＞さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？
やめたほうがよいです．左辺値と右辺値の識別を現行規格でやろうとすると
非常にわずらわしいことを考えないとならないです．
個人的に徹底的に試行錯誤した経験があるんですが，
現行規格で右辺値・左辺値識別を行うのは自分としては絶対にお勧めしません．
実際やってみれば理解してもらえると思うのですが，たとえばGCCの実装における
現行規格の8.5.3/5の解釈にブチ切れたりすることになったりします．

一応，下の提案さえ通ればライブラリレベルで move を実装することはできますが……
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html

ごめん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;
};

>>847
俺の案は RVO されることを前提としてるから、
ムーブなんて無くても十分ということになる。
面倒くさいから RVO を規格で要求したら？ とさえ思ってる。

>>848
識別は難しいのか・・・。

なるほど。
でもそれだとbindなんかで呼出時に右辺値を直に引数にできないのは
解決できないように見える。
lvalue_castがあるって言うのかもしれないけど、
それだったら今でもboost::crefを使えば引数に渡せる点で同じと思う。

まあ、実際の所現行規格で別に実現できなくてもいい。
&& を単項演算子として、それを頭に付けるとかいう言語拡張でも。

何でもかんでもオーバーロードで解決すべきかってのは微妙な所で、
２つの関数を実装させる手間、
いや、複数引数があれば４つ、８つと指数関数的に増えていく手間がかかってしまうのは
かなりの問題だと思う。
右辺値参照を導入するとしても、
オーバーロード不要の代替案は用意した方が良さげ。

それはもう variadic template で書いてしまって，
意図しない呼び出しを SFINAE と deleted function 宣言で阻止してしまえば
いいんじゃないですかね
具体的にどういう複数引数関数書きたいのかによりますけれど

テンプレートは export が実質使えなくてヘッダに実装せざるを得ない以上、
使う必要の無いところでなるべく使いたくはない。

だが、もはやテンプレートのないC++も使いたくない。わがままだ。

ムーブは無駄なコストが発生する上に
RVO みたいな最適化もできなさそうなのがな。
pimpl 使えばポインタの移動だけでいいから
まあ大したコストでもないのかもしれないが・・・。

boost::noncopyable の他に boost::nonmovable も必要になるのかな

非const参照に右辺値を渡せちゃう処理系もあるから、
いらぬお世話って思ってる人もいるかもね。

>>858
pimplでなくとも、ポインタくらいのやり取りですむ（深いコピーが発生しない）
ってのがムーブの売りだろ。

RVO で済む状況なら、RVO はコスト０だぜ。
非０は０には敵わない。

メンバが５個くらいあったら５個ムーブする必要がある。
１つ１つはポインタくらいのやり取りでも、
個数が増えるとバカになんないかもしんない。

んー，別に move を導入しても
RVO が適用できる場面では依然 RVO が適用されるでしょうから，
たとえば>>858さんが何を問題にされているのかいまいち把握できていないんですが……
もう少し詳しく教えてもらえると個人的にはうれしいんですが．

実際、このコードだと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();
}

RVO と右辺値→左辺値変換さえあれば、
文法を複雑にし、コストを必要とし、ライブラリを大きく書き換える
move とやらを導入する積極的な理由はないんじゃないの？
という話。

RVO を規格で保証してないのに理由とかあるの？
コンパイラの実装コストの問題？

>>866
関数からの戻り値のコピーを排除するのは move の応用の1つに過ぎないです．
RVO は return と throw に限定された話ですけれど，
move はより広い文脈 (たとえば std::vector におけるバッファの再配置) でも
きわめて重要な意義を持つ操作で，これは RVO 云々では取り扱いきれないように思います．

それから
＞コストを必要とし、
の部分は，上にもありますけれど， RVO が適用できてコストがかからない部分では
move が導入されても依然 RVO が適用されてコストがかからないようになると
思われますので， (ただし，これはあくまでコンパイラの実装如何ですが)
RVO と move を比較してどのコストを憂慮されているのかがちょっと理解できていないです．

>>866
俺の話はどうしてくれるの？
いや、このためだけに言語を大きく拡張する価値はないと言いたいのか。

だから、右辺値を非 const 参照に渡すまともな手段は用意されてるの？ って話。

>>869
それが lvalue_cast じゃないの？

あと、RVO が規格で強制されるものではないという点も。

右辺値左辺値判定、こりゃ確かに無理だな・・・。

>>870
「まとも」とか変な基準を持ち出すなよ。

>>859
move 系コンストラクタや代入演算子が自動生成されないなら、要らないと思うんだけど、
こいつらもコンパイラが勝手に作っちゃうの？

d = move(s)
の途中で例外が起こった場合、sとdの状態はどうなるんだろうか？

std::vectorの再配置にしても例外安全の強い保証
(メソッドの途中で例外が発生してもオブジェクトの状態は以前と同じ)
を行うなら、結局
　１、新しいバッファを確保
　２、それにすべてのオブジェクト内容をコピー
　３、バッファ作成に成功したら、ポインタの挿げ替えを行う
　４、古いバッファの削除
という手順を踏む必要があるんだけど・・・

　１、新しいバッファを確保
　２、オブジェクト内容をmoveで移動
　３、ポインタの挿げ替え＆古いバッファの削除
とやってしまうと２の途中で例外が発生したときまずいことにならないか？

swapみたいにmoveコンストラクタは例外の非送出が必要ということになっていると思う。

>>875
いえ，今の提案では move constructor や
move assignment は自動では生成されないことになってます．

>>876
move で強い例外安全性の保証を行おうとすると， move の rollback 操作が
move そのもので，これが例外非送出でなければならないため，
結局 move 自身が例外非送出である必要が出てきます．

C++の標準外のライブラリが破綻する最大の理由は
ライブラリ作成側が守るべきプログラミングモデルをユーザに示さないからだよ。

コードから読み取れるモデルでなく、
モデル宣言をするべきなんだよ。
その完全性を支援するためにコンパイラがそれによって挙動を変えてもいい。

最初は完全なるOOを実現しているように見えた。
しかし、あるバージョンではマルチパラダイムに変身し
OOの完全性を崩壊させるとかNe-Yo。

こないだ STL スレで挙がった話なんだけど、 copy_if() がどうなってるかだれか知らない？
未だにドラフトにも載ってないんだけど。っていうか 2003 の改訂で入らなかったのはなぜ？

>>880
禿がまた忘れたんだろ

rangeがどうなるかだな

>>879
どっちかというとOOの世界に土足で上がり込もうとした
総称型プログラミングの要素の側が勝手に苦労してるだけに見える。
継承使ったら型推論できませんとか暗黙のキャストができませんとか。
マルチパラダイムになってOOサイドで何か問題起きてる？
むしろコンテナみたいな値系オブジェクトを下のレイヤに追い出すことで、
OOを純化できると思うんだけど。

完全なOOとか、OOを純化とかには興味無いんだと思うよ。ｗ
一言で言えば「宗旨が違う」

C++はOO側が極端に少ない＝OOが蔑ろにされる
という構図がある。

つまり、そのときOOが成立するコードという理由で
OO前提のコードを書いてしまうと

将来OO否定派が紛れ込んだときに混乱の元になるということ。

>>885
３回読んだけど意味が判らん

対立問題にしてどうしたいんだ

"virtual"を標準ライブラリから検索してみれば
OOはC++自身に拒否されていると分かる
禿げ涙目である

>>887
勝利したいんだろ

ほっとこうぜ

ふむ。OOをNGワードに登録、と。

WO

元々何の信念もなく便利だからって適当に機能ぶちこんだだけのグチャグチャ言語に
今更何を言ってるんだ

>>892
馬鹿にされるから他では言わないほうがいいよ、その脳内C++ヒストリー。

そうですか
じゃあこのC++と呼ばれる雑多にぶち込まれた大量の機能が
お互いひどい副作用を起こし合ってるグチャグチャ言語は
一体どんな高尚な理念で作られたものなんですか

DnE 読んどけ

無知ゆえに思い上がった口をきく若いオタクが興奮すると、文体似るよな、どういうわけか。

C++を雑多と呼ぶのはよした方が良い。
JavaやRubyなんかと違って、ここまで基本的な部分から整合性の練られた言語は他にない。
多くの機能は基本的な構文から基本的に導出されるが、JavaやRubyはそれらのプロセスを
すっ飛ばして機能が実装されている事が多く、とても自由と小回りの利く言語じゃない。

Javaは曲がりなりにも「現実世界で、現実をどうにかするために」歩みを進めてきたけど、
Rubyは話にならない。現実よりも白昼夢のほうが大事な、言語オタの妄想の産物。
前線には一切出ず、安全地帯で仲間とダベりながら延々「クールな匍匐前進」を模索してる兵士が、
「俺はこの最高の匍匐前進でこの戦争を生き抜いてるんだ」って真顔で言い張ってるみたいな言語。役立たず。

という話はスレ違いなのでよそでやろうな。

技術レベルの低い話は華麗にスルーしましょうよ。
規格ドラフトを読むような人が集まってんだからさ。

糞してくるわ

スルーなの?
具体的にどのようなひどい副作用があったのか聞きたいんだが

>>902
妄想を聞きたいならせめてマ板でやってくれ。

いい糞出たわ

895 もかいてるが、Design&Evolution of C++ を読んでから出直してこいとしか言い様がない

ちゃんとした本を読むと、最初の意見（>>892）を変えなきゃいけなくなるから、
ここで文章の素人達に不完全で不足の多い文章を書かせて、それに向かって
そんなの信念があるうちに入らない、適当でしかない、と言って初期設定を維持するつもりなのでは。

ミスを犯すのは常に人。

初心者にはそれがわからんのです。

同じ予約語に3つも4つもまったく違った意味を与えたり
機能を作るたびに別の目的に悪用されて、同じような機能を何度も付け足す羽目になったり
無節操に記号に新しい意味を与えまくってパースを複雑怪奇にしたり
わざとミスさせようとしてるとしか思えませんが

マジレスすると無節操に記号に新しい意味を与えまくってもパースは複雑怪奇にはならない。

例えば不等号なんぞを無理矢理カッコ的なものに仕立てたせいで
どれだけの脳内パーサが誤作動してると思う？
includeで使ってるからってなんも考えずにプリプロセッサの世界からコンパイラの世界に
持ち込んだバカのせいじゃないか
違うか

無知なまま何を「思っ」たところで的外れなだけだから、
無知でなくなるための行動を起こすべきだろうね。既に本も薦められているのだし。

「何故それはそうでなければならなかったのか」という話に関して、
C++ほどシリアスでプラグマティックな内容盛り沢山の言語もそうは無い。
他の言語が「だってそのほうがきれいなんだもん」くらいの理由で決めちゃうところでも、
C++は「現実」を相手に、全然別の戦いをし続けてきたからな。

今の君の頭からは、>>892を裏付ける話は一切出てこないから、マシな頭になる努力をまずしよう。

何も考えていないことにしたい人が
考えの跡をしこたま記した本をこわがってるスレはここですね

じゃあ何をどう考えてるのか教えてくれよ
例えばstaticという語がバラバラのまったく違う4つの意味を持っていた方がよいと考えた理由教えて
その本に書いてあるんだろ

ああ、これが>>906の読んだ展開か

>>911
Javaやスクリプト言語は「現場の実情」に応える方向で発展したけど、
C++はそれ以前に「数学的現実」に足をすくわれ続けているような。
slice_arrayが動かないとかvector<bool>がコンテナじゃないとか。
テンプレートなんて、パースできなくてtypenameキーワードなんてものが
必要になった時点で常識的には破綻したというべきだし、
チューリング完全性が明らかになった時点でもう一度破綻している。
こうなるくらいだったらC++コンパイラにMLインタプリタでも組み込んだ方がマシ。

>>913
残念ながら、無名名前空間でファイルスコープのstaticを排除して、
C++のstaticは静的メンバという意味しか持たないようになったという流れなんだが。

>>915
＞テンプレートなんて、パースできなくてtypenameキーワードなんてものが
＞必要になった時点で常識的には破綻したというべきだし、
これは理解できるとして

＞チューリング完全性が明らかになった時点でもう一度破綻している。
こっちはなぜ？

メタプログラミングなんて邪悪だしJavaに無いし要らないってこと。

C++ の利用者は喜んで便利に使ってるが、それはそいつらが悪趣味な
せいであって、断じてテンプレートの利便性を証明するものではない。

テンプレートはあくまでもジェネリクス用の構文であって
ありとあらゆることに悪用できる万能の箱として用意されたものではないだろ
C++マニアはそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではgoto文と大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

テンプレートメタプログラミングは「発見」されたのだ！とか誇らしげに言ってるC++信者とかたまにいるけど
それって結局は自分らが加えた仕組みが何をもたらすのか、誰もわかってなかったってことじゃないの

あ、C++は全てにおいて考え抜かれた言語だから当然DnEには想定の範囲内だったと書いてあるんですよね
ｻｰｾﾝ

テンプレート、ポインタ、動的確保はgotoと同じく排除しよう
現物使用は避けるべき
STLを主軸に据える

あんまり本気で主張するつもりはないけど：

Javaのバイトコードは本来ポータビリティのためのものであって、直接バイトコードをいじって
なんでもできる万能の素材として用意されたものではないだろ
DI 信者はそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではアセンブラと大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

という状況と対比するとC++の方がまだ健全に思える。

>>921
矛盾していないか？テンプレートとSTLとか。

現物 = テンプレート、ポインタ、動的確保
ラッパー　= STL

try-catch文の醜悪さに比べれば、丁寧に書かれたgoto文の例外処理の方がずっと読みやすいし美しいと思う
ごめん関係なかった

>>919
Cのプリプロセッサでジェネリクス実現しちゃう人だっていたんだから、
C++でそれ用の構文を用意したのは一歩進化だろ。
C++0xでconstexprも用意されたし、さらに一歩前進してるじゃないか。

なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

>>919
>メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

shiroさんも最近似たこと言ってたね。

ttp://reddit.com/info/62o9s/comments/
＞Lispマクロを言語に入れない理由として、
＞よく「文法が変わるから他人の書いたコードが読めなくなる」と言われますが、
＞カンマ演算子をこんな使い方したらもう充分読めないでしょうってことです。

>>926
> なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

限界を試すのは重要と思われ。
ジャンボジェットのお披露目でバレルロールだっけ？　やっちゃったテストパイロットみたいに。

それをプロダクトに積極的に使おうとかやりだすと、ちょwww だけど。

>>920
ちょっと論点のずらし方が卑怯すぎて気持ち悪いなぁ、君は。
DnEが証明するのは、「何も考えていないわけではないこと」であって、「すべてを考えていたこと」ではないよ。
そして、少しでも「考えていたこと」があれば、>>892が馬鹿なことを言っていたことになるのを、忘れちゃダメだよ。

C++でgotoなんて危険すぎて使えんわ。
そのための例外なのに。

お前は全国の後藤さんを敵に回した

gotoさんの髪茹でたい

ここってなんのスレだったっけ？

次スレ建てました
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

>>933
美少女中学生が顔を赤らめながら指の隙間からチラチラと覗くスレ

大体他人が自分自身と一緒にPCを見ていなければ、顔は赤らめても赤らめなくてもどうでも良いけど
恥ずかしがって指の隙間から顔を隠しつつ見なくてもいいだろ。
最近の子供は意識の根底に公私混同が見られて将来が危ぶまれるな。本当にしっかりしてほしい。

まあ、繰り返しになるが、DnE 読んでから出直せとしか言い様がない。

あれは C++ 信者でない人にとっても、どのような方針で言語を拡張していくと
こういうトンでもないことになってしまうのかという様子が詳細に書いてある
という点で非常に勉強になりますよ。C++ スレで煽るためにも、
すぐ反論されないように基礎知識を磨いておくことも重要です。
まずは敵を知ることからです。

というわけで DnE 読んでから出直してください

了解です。

try節ローカルなオブジェクトをcatch節で見られるようにさえなれば何でもいいよ

それは同意
Hoge* p;
try{
p= new Hoge();
}catch(){
}
とかダサすぎる
pそこに置く意味ねぇだろと

>>939-940
try{
Hoge* p = new Hoge();
}catch(){
}

仮に catch の中で p が見れたとして、 new Hoge() から例外が飛んだ場合は
p の初期化が済んでないわけだが、そんなものを見られるようにして何に使うの？

>>941はわざとか？天然か？

これがポインタではなくデストラクタのあるクラスのインスタンスだと考えると
スコープの差異による影響は?

確かに>>940は例が悪いな

例が悪さが、他人の頭の悪さを引き出したケース。

初心者スレ行けと

上の例ならスマートポインタ使うよな。

ぬるぽ

華麗にスルー

>>941
using {
　Hoge* p = NULL;
} try {
　p = new Hoge();
} catch(...) {
　// p を使用
}

こうすればいい。

突っ込んじゃ負けとかいうゲームですか？

コンストラクタの中で例外を投げるなんて変態すぎる。

RAII全否定ですか

>>952
m9（＾Д＾）ﾌﾟｷﾞｬｰ
http://www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html

RAII（）笑

(´；ω；`)おっおっううぇああぁああぅぅおぉぉおお

C++ ならデストラクタ使えよってことなんだろう。

>>956
お前はたぶんオレと同じスレをみている
さぁガイドライン板に帰ろう

泣いたらスカッとしました。

関係なかった俺まで泣いた

>>954
切られている「比較的有名なサイト」ってこれだよね、たぶん。

C MAGAZINE - プログラミングの禁じ手Web版 C++編
ttp://www.cmagazine.jp/src/kinjite/cpp/

適当にうろうろして見たところ、参考にしている人がそれなりにいる様子。
初心者が鵜呑みにするとまずいことを広められるのは困るなー。

C編はいいんだけどね

これ訂正してもらえないの？
いつまでもWeb上に残ってると勘違いするやつが後を絶たないと思うんだけど。
特にポインタのメンバが不定値になるとか、初期化子も知らないような書き方だし。

それともCマガの中の人は確信犯なんだろうか。

エキスパートなお前らの間ではコンストラクタで例外投げてもOKって判断なの？

自分では投げない場合も、投げられた場合への配慮は必要

>>963
糞ページ、糞本認定だけでいいじゃん。
それだって初心者スレでやるべき事だし。
>>963
初心者スレ行って教えて貰ってこい。

オブジェクトの構築に失敗したのに例外を投げないコンストラクタを持つクラスなんて、
初心者には使わせたくないな。

どっかの腐ったフレームワークの悪影響だろうね

例外を投げないような初期化だけをコンストラクタでやって、
Initialize()とかのメソッドを作ってるんだけど。
なんだ、じゃぁ俺もバンバン例外なげるようにするよ

>>969
今までそう作ってきたなら、あえて変える必要は無いんじゃない。
問題なのは、「安全な処理のみでコンストラクタを実装していること」ではなく、
「安全でない処理に失敗したときに例外を投げないこと」なのだから。

今気づいたけどスレ違いだな

うっすらと恥ずかしい毛が生えてきた美少女中学生のスリット違い

古いんだよなアレ今となっては。著者が表に出る活動を凍結してるせいも
あるんだろうが。

RAIIイディオムが一般的じゃなかった時代の知識だね
今となっては古臭い

90年代から知られてるんだけどなw
そのための初期化子リストだし。

自分は何歳の若い美少女に手を付けたことがあるぞ〜って自慢する人がいるよね

俺は中学生が最高だと思いますが。おっぱい

手を付けたことはないが
手に付いたことはある

手を付けたことはないが、
懐かれたことはある。

おまえらここは0x歳の美少女に手をつけるスレじゃないぞ

8歳未満はさすがにちょっと

何進なのかが問題だ

0頭でC系なら8進だろ、で1桁だから8歳未満

x が数値として使われている以上、34進数以上だろう。
そして、34進数以上のどの進数だろうが、
0x は 33 になる。
X と x を使い分けるとなってくると話は変わってくるが・・・。

33で美少女はねーよｗってかそろそろスレチだからおわろー

つか、スレ自体が終わりそうだし

そういえば1000が近いな

1000だったら（俺が出て行ってやっつけるのは）難しい

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/#mailing2008-02

ってもうスレで話題になってた？

ここの住人なら言われるまでもなく当たり前のように読んでいると思ってた

N2518, Compiler Support for type_traits
この提案とconceptの関係がワカランのだが?

立てれなかった。誰か頼む。

C++0x 3

The C++ Standards Committee
ttp://www.open-std.org/jtc1/sc22/wg21/

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/

ここは？
C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

そこは放棄されたスレ。

C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/

たてますた

なんとなくwikiのリンクを貼ってみた

乙

.

.

t

t

1000ならジュースでも飲むか

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。