2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++0x 10

1 :デフォルトの名無しさん:2010/06/01(火) 15:58:42
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

前スレ: C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/

2 :デフォルトの名無しさん:2010/06/01(火) 16:00:03
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 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
C++0x 8
http://pc12.2ch.net/test/read.cgi/tech/1262874195/

3 :デフォルトの名無しさん:2010/06/01(火) 18:10:29
○禿
校長先生。

4 :デフォルトの名無しさん:2010/06/01(火) 19:17:12
0xになって記号の使い方が増えてますます気持ち悪い言語になったな

5 :デフォルトの名無しさん:2010/06/01(火) 19:49:12
C++学園の人々:0a年春の巻

○コンセプトさん(幽霊)
かつての痕跡が校内から着々と消されつつあるのを草葉の影で眺めている。
彼女の居た14.10番教室はオバケが出るという噂で閉鎖中。

○ラムダさん
そろそろみんな制服の柄にも慣れたらしく、何も言われなくなってきた。
それどころか、関数さんがラムダさんとお揃いの服を着たいと言いだして物議を醸している。

○右辺値参照さん
ここへ来て急に彼女のせいで校則が変わることになったらしい。
彼女自身はすっかり学園に馴染みつつあるが、聴講生へのイジメが酷くならないか心配している。

○拡張for文さん
服がクリーニングされそうな様子は一向にない。
屋上で「死にたい」と虚ろな目をして呟く様子がよく目撃されている。心配である。

○constexprさん
従姉妹のconstさんと同じく地味な実力派。しかし意外と頭が悪く、単純な話しか理解できない。
「りかーしぶ」の振り回し方次第ではカオスになりかねないので、周りの大人のサポートが大事である。
なぜかstatic_assertさんとは仲が悪い。

○type_traitsさん
最近ますます調子に乗って手が付けられなくなっている。
この間は「私だけで良かったんや!コンセプトなんか最初からいらんかったんや!」と言い放ち
static_assertさんにドロップキックを食らった。

○static_assertさん
暴走するtype_traitsさんとテンプレ部に振り回されて気苦労が絶えない。
姉貴はリリースコンパイルで逃げ出せるからいいよなーと愚痴りつつ仕事を真面目にこなす苦労人。

6 :デフォルトの名無しさん:2010/06/01(火) 19:50:04
○initializer_listさん
「ねえねえ配列さん、なんでコンストラクタさんと仲良くしないの?」「新入生が来たら仲良くするよ!」
定番と化しつつあるこのやりとりの繰り返しで過剰な期待が勝手に高まりつつある。
本人はあまり何も考えていない。

○テンプレート可変長引数さん
テンプレ部にはすっかり馴染んだが、相変わらず一般生徒からは「あんた何の役に立つの?」
と受けが悪い。最近はもう面倒臭いのでいちいち説明するのをやめた。

○autoさん
苦楽を共にしたregisterさんはついにD組に落第してしまった。
しかし一報を聞いたautoさんの反応は「ふーん、そう」という素っ気ないものだった。
昔の彼女はもういない。

○decltypeさん
一人前の型としての振る舞いも身につけ、いよいよ活躍が期待される所だが、
服の違いで性格が変わる悪癖はまだ直っていない。
いつか必ず問題を起こすと一部の先生からマークされている。

○ユーザー定義リテラルさん
「まだいたのか」と先生に暴言を吐かれ、体育館の陰で泣いていた。

○nullptrさん
誰もNULLさんと見分けが付かないので、既にこっそり通学していると噂されている。

○long longさん
intさんに「ほら!あんたはこっちでしょ!」と間違えて上級生のクラスに連れて行かれた。

○Raw String Literalさん
「お前全然Rawじゃねえじゃん」という状況は、トライグラフさんが譲る形で解決しつつある。
ちなみにトライグラフさんはしぶとく落第を免れ続けてるらしい。

7 :デフォルトの名無しさん:2010/06/01(火) 19:51:00
○unique_ptrさん
コンテナ部とも仲良くできます!あの女とは違うんです!と自分を売り込んでいるが、
みんなのauto_ptrさんのトラウマはなかなか払拭しきれず、苦戦している。

○shared_ptrさん
ライブラリ部が誇るご存じ優等生中の優等生。早く来てくれ。

○unordered_map・unordered_setさん姉妹
名字はhashが良かったが、大人の事情で付けられなかった。
おかげでmap・setさん姉妹との違いをいちいち説明する羽目に。

○Regular expressionさん
Perl学園ではバカにされていたが、ここでは大歓迎。
満更ではないものの、学園の行く末に一抹の不安を抱いている。

○Atomic operationさん
彼女と話していて業を煮やしたとある生徒が「こまけえこたぁいいんだよ!」と叫んで飛び出し
10分後に未定義動作にボコボコにされて帰ってきた。

○threadさん
最大のライバルであるpthreadさんを蹴落とすべく日々努力しているが、
親友のラムダさんがpthreadさんとも親しくなりそうで焦っている。

○System error supportさん
ユーザー定義リテラルさんとよく一緒に弁当を食べている。

○progress_displayたん
System error supportさん達と一緒に弁当を食べようとしたら断られた。

8 :デフォルトの名無しさん:2010/06/01(火) 19:51:52
○attributeさん
他の学校に、かならず一人はいる娘なので、学校側としても、しかたなく、入校させた。
服のセンスが、lambdaさんに負けず劣らず、相当悪い。
lambdaさんと、かぶっている帽子が、見る角度によっては、似ていることがあり、少々問題になっている。
lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。

○noexceptちゃん
入学試験の選考の最後になって、急に合格した赤ちゃん。
豪華にも、独自の制服を作ってもらった。

○Inheriting Constructorさん
地味にできる娘。何で今までいなかったのか、不思議に思われている。

○__VA_ARGS__さん
クラス分けで、プリプロセッサ組に通うことになった娘。
プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
その外見はあまりにもブサイクだが、密かにファンもいるらしい。


○exportさん
進級できなかった。

○Exception specificationさん
進級できなかったが、彼女の産んだ、まだ一歳にもならない赤ちゃんが、いきなり入校してきた。

9 :デフォルトの名無しさん:2010/06/01(火) 19:52:44
○type_indexさん
type_info君と仲が良いらしい。
噂では、いくとこまでいったとかいってないとか。
ただし、開校前のクラス分けで離ればなれになってしまった。

○System error supportさん
いじめられて転校してきたらしい。
たぶん、どの学校でも相手にされない子。
ほとんどの学校には、学校独自の、もっとマシな子がいるし。

○Tupleさん
博愛平等主義者。ほとんどのクラスメートと仲が良い。

○Binder姉妹(bind1st,bind2nd)
落第。一応、まだ学校にはいる。

○Function template bindさんと、Polymorphic function wrapperさん
二人とも、とても頭が良い。
なんでも、「ぶーすと」という一流の進学校から転校してきたらしい。
あまりに成績が良かったために偏差値を押し上げて、Binder姉妹を落第させる原因をつくった。

○Time utilitieさん
2038年問題も3000年問題も大丈夫と豪語。

○Compile-time rational arithmetic君
Time utilitieさんと仲が良いらしい。

10 :デフォルトの名無しさん:2010/06/01(火) 19:58:54
> ○コンセプトさん(幽霊)
0xスレ1か2くらいで「直ぐに実装できる」って言われてたのになんでこんな酷い事になってんの?

11 :デフォルトの名無しさん:2010/06/01(火) 20:12:36
○Blocksさん

12 :デフォルトの名無しさん:2010/06/01(火) 20:22:23
○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。

13 :デフォルトの名無しさん:2010/06/01(火) 20:37:16
なぜラムダ一族はおかしな帽子を被りたがるのか

14 :デフォルトの名無しさん:2010/06/01(火) 20:52:57
attributeって、新しい記号を導入しちゃだめなのかな
どうせtrigraphあるから、入力できない環境を作る事もないだろうし

15 :デフォルトの名無しさん:2010/06/01(火) 20:54:53
○Blocksさん
青森の林檎農家が付属小学校への裏口入学を試みているラムダさんの親戚。
とても気難しく、隣の部屋に行くにも「ぶろっくこぴー」という赤絨毯を要求する箱入り娘。

16 :デフォルトの名無しさん:2010/06/02(水) 14:21:46
もう2010年なんだから、そろそろC++ 1xでいいと思うんだが。

17 :デフォルトの名無しさん:2010/06/02(水) 15:32:11
stroustorup先生が00年代に0xと言ってしまったので

18 :デフォルトの名無しさん:2010/06/02(水) 17:23:49
C++1x 0 でも良かったか

19 :デフォルトの名無しさん:2010/06/02(水) 18:49:24
スレタイはC++0x0Aになると思ってた

20 :デフォルトの名無しさん:2010/06/02(水) 19:14:24
校長先生がC++0xのままでいくと言ったから
C++0xのままでおk
C++0x A あたりになるとは俺も思ったのだが
まあどうでもいい

21 :デフォルトの名無しさん:2010/06/03(木) 01:14:43
そろそろ#include棄てたいんだけどどうにかなるような話はなきや?

22 :デフォルトの名無しさん:2010/06/03(木) 01:15:58
boost.ppが死ぬのでなきや

23 :デフォルトの名無しさん:2010/06/03(木) 10:57:52
ラムダって関数ポインタにできないのか?

24 :デフォルトの名無しさん:2010/06/03(木) 13:48:54
template関数でラップしてそのポインタを取ればできる

25 :デフォルトの名無しさん:2010/06/03(木) 14:24:12
captureの無いλは関数へのポインタに変換出来るようにするという
提案があったと思うよ。

26 :デフォルトの名無しさん:2010/06/03(木) 18:49:07
captureがないやつだけか
まあそうだろうな

27 :デフォルトの名無しさん:2010/06/04(金) 20:24:32
むしろPreprocessorはもっと勢力拡張すべき。

28 :デフォルトの名無しさん:2010/06/04(金) 20:37:50
> ○__VA_ARGS__さん
> クラス分けで、プリプロセッサ組に通うことになった娘。
> プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
> その外見はあまりにもブサイクだが、密かにファンもいるらしい。

そう、これだ。



29 :デフォルトの名無しさん:2010/06/04(金) 22:54:31
__VA_ARGS__さんとテンプレート可変長引数さんとinitializer_listさんが組めば
空だって飛べる

30 :デフォルトの名無しさん:2010/06/04(金) 22:56:13
vc++2010の対応が雑魚過ぎて困る

31 :デフォルトの名無しさん:2010/06/04(金) 23:53:05
またVC6の頃みたいなバッドノウハウが累積される悪寒

32 :デフォルトの名無しさん:2010/06/05(土) 00:20:58
まだC++0x自体が出来上がってないんだし仕方ないよ。
ドラフトをフライング実装してforのスコープ問題みたいなことがまた起こっても困るし。

個人で買いにくい価格設定になっているのはMSの良心かもしれない。

33 :デフォルトの名無しさん:2010/06/05(土) 00:21:41
それならデフォルトではC++0xの機能をオフにして欲しかった

34 :デフォルトの名無しさん:2010/06/05(土) 00:52:11
そもそも0x機能オフにできるの?

35 :デフォルトの名無しさん:2010/06/05(土) 01:01:58
>>32
Express版があるぞ

36 :デフォルトの名無しさん:2010/06/05(土) 02:21:26
VC10はそもそも開発チーム自身が「新しいVC6だ」って言ってたし

37 :デフォルトの名無しさん:2010/06/05(土) 02:45:57
SPなりhotfixなりで矢継ぎ早に修正してくれれば問題ないんじゃない?
VC6は使われる時間が長すぎたからな

とりあえずさっさと可変長引数テンプレートサポートしてくれ

38 :デフォルトの名無しさん:2010/06/05(土) 07:15:15
MSは互換性を最優先させるから、
明らかに実装方法の誤りであっても次Ver.まで仕様で放置とか良くあるんだよな。

39 :デフォルトの名無しさん:2010/06/05(土) 07:24:24
vc++2010って初期化リスト周りおかしくね?

40 :デフォルトの名無しさん:2010/06/05(土) 08:47:18
初期化リストなんて面倒なこと言わずに{〜}をテンポラリな配列として扱えばよかったのに
そうすればtemplate <class T, size_t N> void func(const T (&a)[N]);で受け取れるし
コンパイル時にサイズもわかるし直にランダムアクセスもできる
なにより組み込みなのにstd名前空間とか気持ち悪い現象が発生しない

41 :デフォルトの名無しさん:2010/06/05(土) 09:13:11
parse上の問題でもあるんじゃない?

42 :デフォルトの名無しさん:2010/06/05(土) 09:15:39
配列はないな
サイズの取得が面倒くさい

43 :デフォルトの名無しさん:2010/06/05(土) 09:16:06
組み込みなのにstd名前空間とか別に普通だよ
new が失敗すりゃ std::bad_alloc 例外投げるし
それを抑制する時に使うものも std::nothrow だし

44 :デフォルトの名無しさん:2010/06/05(土) 10:59:04
std::initializer_list ってどう実装されてんの
引数を隠しローカル配列に入れておいて
そのポインタを保持するとか?

45 :デフォルトの名無しさん:2010/06/05(土) 12:38:49
前スレで紹介されてた
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
を見たところ、vc++2010はInitializer Lists対応してないね


確かにテンポラリな配列として扱えれば便利だよね
でも↓のような場合はstd::initializer_listがないと困る
// ヘッダファイル
void func(std::initializer_list<int> list);
// ソースファイル
void func(std::initializer_list<int> list) { ... }

と思ったけど仕様とか知らないからこれが可能なのかどうか
分からない

46 :デフォルトの名無しさん:2010/06/05(土) 12:43:37
>>45
このケースなら薄いテンプレートで分離できなくも無い

47 :デフォルトの名無しさん:2010/06/05(土) 12:54:49
使えないけど#include<initializer_list>は通るんだよな
中途半端なことやめて

48 :デフォルトの名無しさん:2010/06/05(土) 13:49:36
std::initializer_list のクラステンプレート自体は実装してある
でもそれだけなんだよな
中途半端やなあ

49 :デフォルトの名無しさん:2010/06/05(土) 16:26:52
g++4.5.0も a[{1,2}] を解釈してくれない。
FCDには例示されてるけど、後で加筆されたものなのか

50 :デフォルトの名無しさん:2010/06/05(土) 19:34:34
>>38
スイッチで切り替えられるようにしないのはどういうつもりなのかねえ。

51 :デフォルトの名無しさん:2010/06/05(土) 21:12:40
03にしたけりゃユーザーが勝手に自分で03の範疇で書いてろよ、って事でね?

52 :デフォルトの名無しさん:2010/06/05(土) 22:21:04
はあ?

53 :デフォルトの名無しさん:2010/06/05(土) 22:22:01
>>52
はあ?

54 :デフォルトの名無しさん:2010/06/05(土) 23:04:15
>>51
VC10のC++0xの対応レベルで互換性が問題になるのはautoぐらいじゃね?

55 :デフォルトの名無しさん:2010/06/05(土) 23:18:31
C++0xにはスマポ、正規表現、乱数とかいろいろあるから
それ全部使えなくなるってのはちょっと…
まあ、boostの使えば問題ないか

56 :デフォルトの名無しさん:2010/06/05(土) 23:21:01
右辺値参照はすでに使いまくってるぜ

57 :デフォルトの名無しさん:2010/06/05(土) 23:25:20
VC10でstd::tr1::shared_ptrとboost::shared_ptrがごっちゃになって困る。
using boost::shared_ptrして使っててstd::tr1::shared_ptrは使ってないつもりなのにstd::tr1::shared_ptrからboost::shared_ptrに変換できませんとか出る。何故なんだろう?

58 :デフォルトの名無しさん:2010/06/05(土) 23:35:40
>>57 そーすうp

59 :デフォルトの名無しさん:2010/06/05(土) 23:46:11
usingしなければよい

60 :デフォルトの名無しさん:2010/06/06(日) 00:23:14
>>57
気になる。ソースソース。

61 :デフォルトの名無しさん:2010/06/06(日) 08:48:10
ナントカルックアップだろ

62 :デフォルトの名無しさん:2010/06/06(日) 09:25:29
>>57
using namespace std;
なんてしてないよな?


63 :デフォルトの名無しさん:2010/06/06(日) 09:57:46
どっかのヘッダでusingしてる悪寒

64 :デフォルトの名無しさん:2010/06/06(日) 10:05:57
ヘッダでusingとかえんがちょにもほどがある

65 :デフォルトの名無しさん:2010/06/06(日) 10:16:49
>>64
ヘッダのnamespace内でusingすることはあるけどなぁ
boost::tr1の真似して

66 :デフォルトの名無しさん:2010/06/06(日) 10:26:16
ヘッダでusingするのは
名前を取り込みたい時であって
名前空間を省略したい時ではないぞ

67 :デフォルトの名無しさん:2010/06/06(日) 12:45:21
あーおれ面倒だから using namespace std::string よくやるわすまん・・・

68 :デフォルトの名無しさん:2010/06/06(日) 12:52:20
死刑

69 :デフォルトの名無しさん:2010/06/06(日) 13:28:06
ローカルの関数スコープ以外のusingを禁止するコンパイルオプションはなぜ無いのか

70 :デフォルトの名無しさん:2010/06/06(日) 15:16:35
auto f(int x) -> hoge
{
・・・
}
この書き方ってなんかイイコトあるんですか?

71 :デフォルトの名無しさん:2010/06/06(日) 15:23:13
-> decltype
が出来る、とか

72 :デフォルトの名無しさん:2010/06/06(日) 15:37:14
template <typename T1, typename T2>
auto add(const T1& a, const T2& b) -> decltype(a + b) { return a + b; }

ができるからと言われるけど

template <typename T1, typename T2>
auto add(const T1& a, const T2& b) { return a + b; }

を許してもらえるなら必要ないよね
そもそも a + b を2度書かないといけないのが気に食わない

73 :デフォルトの名無しさん:2010/06/06(日) 15:38:39
template <typename T1, typename T2>
auto add(const T1& a, const T2& b) -> decltype(a + b);


74 :デフォルトの名無しさん:2010/06/06(日) 15:50:35
auto hoge(fuga x) -> decltype(x + piyo())
{
piyo y;

return x + y;
}

この場合はこう書くの?
けっこうメンドクセーな

75 :デフォルトの名無しさん:2010/06/06(日) 16:23:37
template <typename T1, typename T2>
auto add(const T1&, const T2&) -> decltype(std::declval<T1>() + std::declval<T2>());

76 :デフォルトの名無しさん:2010/06/06(日) 17:24:05
struct Hoge
{
typedef int type ;
type f() ;
} ;
というクラスがあった場合、このHoge::fの定義を書くのに、
従来の関数宣言の場合、

Hoge::type Hoge::f() { return 0 ; }

新しい関数宣言の場合、

auto Hoge::f() -> type { return 0 ; }

戻り値にクラス名の修飾がいらない。


77 :デフォルトの名無しさん:2010/06/06(日) 17:26:41
まあそれなら便利な事もあるかな・・・
Hoge:: くらいなら auto -> 書くのと大差ないけど
もっと長いと使えるかも

78 :デフォルトの名無しさん:2010/06/06(日) 17:34:21
でもどっちかに統一しないと気持ち悪いよな

79 :デフォルトの名無しさん:2010/06/06(日) 17:43:35
必要に応じて便利な方を使うしかない。
気持ちを最優先にしてもコンパイルに関係ないし。

80 :デフォルトの名無しさん:2010/06/06(日) 18:11:30
コンパイルに関係ないなら気持ちは優先してもいいんじゃね?

81 :デフォルトの名無しさん:2010/06/06(日) 18:12:35
>>70
型が右に来る方が直感的

82 :デフォルトの名無しさん:2010/06/06(日) 18:31:24
それはない

83 :デフォルトの名無しさん:2010/06/06(日) 18:37:22
>>70

class LongLongHogeHugaItteyoshiClass{
public:
typedef VeryVeryLongLongHawawaTypeName T;
T f();
};

auto LongLongHogeHugaItteyoshiClass::f() -> T
{
...
}


84 :デフォルトの名無しさん:2010/06/06(日) 18:39:18
// LongLongHogeHugaItteyoshiClass.cpp

#include "LongLongHogeHugaItteyoshiClass.h"
typedef LongLongHogeHugaItteyoshiClass L;

L::T L::f() {
}

85 :83:2010/06/06(日) 18:40:00
ごめんなさい、すでに同じことが76に書かれてました。

86 :デフォルトの名無しさん:2010/06/06(日) 19:32:46
>>84 と違って、>>76, >>83 のやり方だと
class 中の private な typedef にも使用可能だったはず…

87 :デフォルトの名無しさん:2010/06/06(日) 19:49:53
privateなら好きに短い名前でtypedefすりゃええんやないの?

88 :デフォルトの名無しさん:2010/06/06(日) 20:28:57
書くのがだるいというだけでtypedefを使うやつを俺は信用しない
ていうか入力補完でいいじゃないか

89 :デフォルトの名無しさん:2010/06/06(日) 20:43:05
べ、別にあんたに信用されようなんて思ってないんだからねっ!

90 :デフォルトの名無しさん:2010/06/06(日) 20:47:06
typedefは必須だろう

91 :デフォルトの名無しさん:2010/06/06(日) 20:47:48
書くのがだるいだけじゃないぞ
読み辛い

92 :デフォルトの名無しさん:2010/06/06(日) 20:48:52
typedef使わずに素の宣言かいてたらクラスの変更とか困るだろ

93 :デフォルトの名無しさん:2010/06/06(日) 20:50:39
>>88
C#のひとか?

94 :デフォルトの名無しさん:2010/06/06(日) 20:53:31
C#でもmonoで書くと補完効かんぞ

95 :デフォルトの名無しさん:2010/06/06(日) 21:03:29
std::mapの値とかvalue_typeをtypedefしてるから明確になるのに。

96 :デフォルトの名無しさん:2010/06/06(日) 21:05:57
EDスクロールが早いから偽EDですね

97 :デフォルトの名無しさん:2010/06/06(日) 21:07:40
ごめん誤爆・・・

98 :デフォルトの名無しさん:2010/06/06(日) 21:08:39
知ってます

99 :デフォルトの名無しさん:2010/06/06(日) 21:35:10
typedefないとtemplate成立しない

100 :デフォルトの名無しさん:2010/06/06(日) 21:36:57
いやその理論はおかしい

101 :デフォルトの名無しさん:2010/06/06(日) 21:43:38
テンプレート引数をtypedefしないと
外から使えないし

102 :デフォルトの名無しさん:2010/06/06(日) 21:55:01
確かにtypedefだけではtemplateは成立しない。
typenameも必要だ。

103 :デフォルトの名無しさん:2010/06/06(日) 22:37:59
>>82
最近の言語はみんな右に書くようになってるんだぜ?

104 :デフォルトの名無しさん:2010/06/06(日) 22:39:05
例えば?

105 :デフォルトの名無しさん:2010/06/06(日) 22:40:47
Fortran

106 :デフォルトの名無しさん:2010/06/06(日) 23:06:40
>>103
C#はどうだっつんだ
てか、右でも左でもどっちでも変わらん
どちらが直感的とかない

107 :デフォルトの名無しさん:2010/06/06(日) 23:10:22
右に書く言語は
従来の文法を拡張したら仕方なくそうなったって奴が多いな

108 :デフォルトの名無しさん:2010/06/06(日) 23:12:13
なんだまたC#の人だったのか

109 :デフォルトの名無しさん:2010/06/07(月) 06:56:32
日本語的には左
英語的には右

110 :デフォルトの名無しさん:2010/06/07(月) 07:27:09
構文解析の都合を考えると左の方が便利

111 :デフォルトの名無しさん:2010/06/07(月) 07:32:54
int a;
int bb;
int ccc;
int dddd;

a : int
bb : int
ccc : int
dddd : int

下は揃わないな

112 :デフォルトの名無しさん:2010/06/07(月) 10:03:52
inline namespaceって何者なんですか?
存在意義がいまいち不明なんですが・・・

113 :デフォルトの名無しさん:2010/06/07(月) 10:40:53
名前空間バージョニングする場合色々問題があるのでその解決だそうだ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1344.pdf

114 :デフォルトの名無しさん:2010/06/08(火) 09:08:12
つまり…どういう事だってばよ?

115 :デフォルトの名無しさん:2010/06/08(火) 22:34:16
inline namespace だと?初耳だぜ。

116 :デフォルトの名無しさん:2010/06/08(火) 23:42:00
理解できる部分だけ使えばいいのさ

117 :デフォルトの名無しさん:2010/06/09(水) 10:14:37
>>109
数学的には右だな

118 :デフォルトの名無しさん:2010/06/09(水) 12:32:56
数学的にどうのと言うなら = の意味の違いをどうにかせえ

119 :デフォルトの名無しさん:2010/06/09(水) 13:19:19
数学的に何か問題あるのか?

120 :デフォルトの名無しさん:2010/06/09(水) 13:33:06
数学的な厳密さを言うんなら副作用がある時点で

121 :デフォルトの名無しさん:2010/06/09(水) 16:00:15
キャプチャなしのラムダをラップする関数ってどうやって作るの?

122 :デフォルトの名無しさん:2010/06/09(水) 23:11:25
キャプチャなしラムダなら関数ポインタに暗黙変換できるからラッパなんか必要なし

123 :デフォルトの名無しさん:2010/06/09(水) 23:19:10
次にお前は「おのれVC++2010」と言う

124 :デフォルトの名無しさん:2010/06/09(水) 23:19:54
>>122
VC++2010ですができませんよ?

125 :124:2010/06/09(水) 23:20:46
ハッ!?

126 :デフォルトの名無しさん:2010/06/09(水) 23:35:02
decltype(<<ラムダ式>>)::operator()のポインタ取れば?

127 :デフォルトの名無しさん:2010/06/09(水) 23:36:22
自演だよなっ?

128 :デフォルトの名無しさん:2010/06/09(水) 23:44:54
>>126
無理じゃね?

129 :デフォルトの名無しさん:2010/06/10(木) 16:02:02
自演だとしても笑えたから許す

130 :デフォルトの名無しさん:2010/06/10(木) 22:43:56
もうmailingは出ないのかしら

131 :デフォルトの名無しさん:2010/06/11(金) 01:30:34
>>124
VC++ 2010がまだ追い付いていないだけ。

132 :デフォルトの名無しさん:2010/06/11(金) 02:50:48
f(vector<int> &&);

auto *x = new vector<int>;
f(move(*x));
delete x; // ← このdeleteってなんか変なこと起こさないですか?

133 :デフォルトの名無しさん:2010/06/11(金) 02:55:30
moveの後で*xに触ってるから未定義動作だな

134 :デフォルトの名無しさん:2010/06/11(金) 03:26:59
デストラクタも呼べないのか?
そんなまさか

135 :デフォルトの名無しさん:2010/06/11(金) 04:03:25
やっぱりいるよ。
>>133みたいな勘違いする奴が。

136 :デフォルトの名無しさん:2010/06/12(土) 07:33:15
破壊的操作と未定義動作の区別がついて無いようだね。


137 :デフォルトの名無しさん:2010/06/12(土) 07:41:12
X x; std::move(x);
ができる以上、デストラクタは呼べるはず
だからdeleteしても問題ないはず

138 :デフォルトの名無しさん:2010/06/12(土) 07:58:10
やはり、std::moveなんて関数を標準で用意するから>>133みたいなバカがでるんだよ。
自前でstatic_castさせときゃいいんだよ。

139 :デフォルトの名無しさん:2010/06/12(土) 08:08:29
>>137
「はず」プゲラ

140 :デフォルトの名無しさん:2010/06/12(土) 08:16:22
たとえばこう書いて、RVO最適化可能ならムーブよりRVOが優先されるなんてあると嬉しいんですが。将来的にはありますか?
Hoge func()
{
Hoge temp;
temp.f1();
temp.f2();
return std::move(temp);
}


141 :デフォルトの名無しさん:2010/06/12(土) 08:18:59
今でもある。
その場合、
もしHogeがムーブコンストラクターを実装していなければ、
コピーコンストラクターが呼ばれる。

というか、最適化によって、コピーコンストラクターの呼び出しが省略される可能性もあるが。

142 :デフォルトの名無しさん:2010/06/12(土) 08:24:26
お前実はRVOがなんだかわかってないだろ

143 :デフォルトの名無しさん:2010/06/12(土) 08:26:54
ということは、
RVO可能->コピコンそのものが不用
RVO不可->コピコンまたはムーブ適用

ムーブコンストラクタがあってもRVO可能であればRVOが適用されるでいいのかな。

とりあえずstd::moveつけて置けば問題ないということでOK?


144 :デフォルトの名無しさん:2010/06/12(土) 08:32:04
>>142
ごめん、読み間違えた。「ムーブより・・・優先」とみて条件反射でコピーコンストラクターだと思ってしまった。

145 :デフォルトの名無しさん:2010/06/12(土) 08:36:07
>>143
よく考えたら、std::move通した時点でRVO可能なオブジェクトとコンパイラが認識できなくなる可能性があるね。

実験しないと分からないや


146 :デフォルトの名無しさん:2010/06/12(土) 08:39:15
>>145
なぜ? rvalue referenceにキャストしているだけじゃないか。
ポインターならともかく。

147 :デフォルトの名無しさん:2010/06/12(土) 08:40:11
というか何だその「実験」って。
未だにまともなC++コンパイラは存在しないんだぞ。
何を実験するというんだ。

148 :デフォルトの名無しさん:2010/06/12(土) 08:43:44
そうか、まだなのか。
RVO_OR_MOVE()マクロ作って後からまとめて切り替えられるようにしておこうか。



149 :デフォルトの名無しさん:2010/06/12(土) 08:45:58
>>146
キャストでコンパイラが自動変数って情報を落として最適化できなくなるんじゃないかなっと思った。


150 :デフォルトの名無しさん:2010/06/12(土) 08:47:35
てかムーブよりRVOが優先されると嬉しいってどういうケースじゃろ

151 :デフォルトの名無しさん:2010/06/12(土) 09:19:15
moveとかrvalueってさ、コンパイラに最適化のヒントを与える魔法のツールじゃないよね?

152 :デフォルトの名無しさん:2010/06/12(土) 09:24:16
moveは最適化じゃないから、適用されるかどうかは確実に判断できる。
RVOは最適化だから確実な予測はできない。

153 :デフォルトの名無しさん:2010/06/12(土) 09:33:36
>>150
RVOはコスト0

154 :デフォルトの名無しさん:2010/06/12(土) 17:52:49
>140
return std::move(temp);

じゃなくて

return temp;

とだけ書いていれば良いのでは?

155 :デフォルトの名無しさん:2010/06/12(土) 18:27:16
>>154
たとえばこれならほぼ確実にRVOがかかる。
return hoge(100);

だけど、こんな複雑な場合だとRVOがかからない場合がある。
hoge temp;
temp.func(100);//なんか操作する。
return temp;

RVOかからないなら次善策でムーブを使いたいなと。


156 :デフォルトの名無しさん:2010/06/12(土) 19:11:55
>>155
return文で(コピーではなく)ムーブすることも決まっていることも決まっているから、
return temp;とだけ書いておけば、NRVOが適用されるならそれで、
適用されないならムーブで処理されることになるはず。

157 :デフォルトの名無しさん:2010/06/12(土) 19:16:08
>155
いや,なのでそうとだけ書いておきさえすれば

(1)コンパイラが RVO を適用できるならする
(2)hoge が move constructor を持っているならば return で move を使う
(3)コピー

というのを上から順に適用していって可能なものを採用すると思います.
(2) は, return temp; という文においては temp が自動変数なので,
まず temp を自動的に右辺値として取り扱おうとするはずだからです.

158 :124:2010/06/12(土) 19:18:10
hoge func() { const hoge h; return h; }

moveにならなくて不愉快

159 :デフォルトの名無しさん:2010/06/12(土) 19:36:18
>>158
それはconstなオブジェクトからムーブできない話であって、また別の話。

ムーブは元オブジェクトを破壊してよいことを前提としているので、
constなオブジェクトはすなわち破壊できないので、そこからムーブできないということ。
可能な限りconst付ける教とムーブセマンティクスは本質的に相性が良くない。

160 :デフォルトの名無しさん:2010/06/12(土) 19:38:35 ?2BP(0)
それは当然・・・

161 :デフォルトの名無しさん:2010/06/12(土) 19:39:20 ?2BP(0)
>>160>>158へのレスな

162 :デフォルトの名無しさん:2010/06/12(土) 19:45:12
関数の戻り値として返すときは特別扱いして欲しいってことか

163 :デフォルトの名無しさん:2010/06/12(土) 19:46:59
>>157
丁寧な回答ありがとうです。
returnはmoveを使うで理解しました。
c++0xは思ったより気が利いてるなと感心したり

164 :デフォルトの名無しさん:2010/06/12(土) 20:58:40
VCのSP1はまだか

165 :デフォルトの名無しさん:2010/06/12(土) 21:41:28
>>164
あほか
まだVC2010そのものが店頭で売ってない
ダウンロード販売のみ
SP1はいくらなんでもその後だろう

あるとしたら店頭に並んでるものに既にSP1が適用してあるとか
そういう場合くらいしか

166 :デフォルトの名無しさん:2010/06/12(土) 22:58:10
世の中には発売前にパッチが出たりするソフトがあるんだよ

167 :デフォルトの名無しさん:2010/06/12(土) 23:22:51
というかVS2010は、よくあれでリリースしたなという出来なんだが。
IDEからしてクソすぎるし。

168 :デフォルトの名無しさん:2010/06/12(土) 23:29:15
>>167
さっさとてめえの化石PCを窓から投げ捨てろ

169 :デフォルトの名無しさん:2010/06/12(土) 23:40:21
遅いといってるわけではなさそうだが。完成度が低いというなら分かる。

170 :デフォルトの名無しさん:2010/06/13(日) 00:19:02
遅い上に完成度が低い

171 :デフォルトの名無しさん:2010/06/13(日) 00:24:47
2005proのIDEから2010eeのC++コンパイラが呼び出せたらベストなんだが

172 :デフォルトの名無しさん:2010/06/13(日) 00:26:23
そりゃ抱き合わせですよ
独占ですから

173 :デフォルトの名無しさん:2010/06/13(日) 05:08:33
>>171
devenv /useenv

174 :デフォルトの名無しさん:2010/06/16(水) 14:31:33
RVOやNRVOが出来たかどうか調べるにはどうしたらいいのだろうか・・・難しい・・・・・・・・

175 :デフォルトの名無しさん:2010/06/16(水) 14:53:13
コピーコンストラクタでログ録ってそれが無視されてたら最適化されたとみていいんじゃねーか?


176 :デフォルトの名無しさん:2010/06/16(水) 15:14:40
LLVM の C++ (の開発版)で、オプションつけると RVO/NRVO 対象に
できたかどうかわかるよ

177 :デフォルトの名無しさん:2010/06/16(水) 17:06:45
inlineみたいにされたか出るコマンドはGCCにはないですか?

178 :デフォルトの名無しさん:2010/06/16(水) 19:19:30
副作用があるのに勝手に消えられるのも困るよな

179 :デフォルトの名無しさん:2010/06/16(水) 20:49:23
RVOのような動作が変わる最適化はコンパイルメーカの独断ではできないから、あえて規格上で許してるんでしょう。
規格上許しているんだから、コピコン省かれて困る設計のほうがまずいんではないか?




180 :デフォルトの名無しさん:2010/06/16(水) 20:53:13
んだ

181 :デフォルトの名無しさん:2010/06/16(水) 21:29:39
VC++EE2010で

#include <iostream>
struct Hoge
{
static volatile int count_;
Hoge()
{
}
Hoge(const Hoge & hoge)
{
++count_;
}
};
volatile int Hoge::count_ = 0;
Hoge test()
{
return Hoge();
}
int main(void)
{
Hoge h(test()), g(test());
std::cout << Hoge::count_ << std::endl;
return 0;
}

ってやってみたけどcount_はゼロだったぜ
volatile無視かよ

182 :デフォルトの名無しさん:2010/06/16(水) 21:35:54
>>181
RVOでコピコンがそのもの省略されてるんだから、countのvolatileは無関係だろ。

183 :デフォルトの名無しさん:2010/06/16(水) 21:39:19
RVOが行われる場合、
コピコンが影響するのはアクセス制限くらいやで

184 :デフォルトの名無しさん:2010/06/16(水) 21:46:52
じゃあ人類にRVO最適化をコードから阻止する手段は残されていないのですか?

185 :デフォルトの名無しさん:2010/06/16(水) 21:56:38
>>184
こんなの通してreturnに渡したらかからなくなったことがあったような気がする
template<class T>
inline T& stop(T& a)
{
returan a;
}

RVOが効いて困るコードを書く方が問題があるぞ。バグの温床じゃないか?直したほうがいいよ。

186 :デフォルトの名無しさん:2010/06/16(水) 22:00:23
RVOが問題なるケースが思いつかない

187 :デフォルトの名無しさん:2010/06/16(水) 22:04:18
きっと常人には理解もできない状況なのだろう
理解したくもないが

188 :デフォルトの名無しさん:2010/06/17(木) 13:02:02
gccが__m128用のコピーコンストラクタ書いているのにスタックに積んで4バイトずつコピーするのはRVOのせいだったのか。
RVOうぜー。

189 :デフォルトの名無しさん:2010/06/17(木) 15:59:55
RVO,NRVO > move()>無し
だからね。
(RVO OR 無し) あるいは (move())
だから非常に困るね。

190 :デフォルトの名無しさん:2010/06/17(木) 18:31:44
>>189
もっと整理して書けよw
プログラムもそうなのか?

191 :デフォルトの名無しさん:2010/06/17(木) 20:03:02
>>188
コピーしているならRVOじゃないよね。コピーそのもの存在を無くすのがRVOなのに。

どんなコピーコンストラクタかいてるの?

192 :デフォルトの名無しさん:2010/06/17(木) 20:19:52
>>188
お前のコードが糞

193 :デフォルトの名無しさん:2010/06/17(木) 20:25:34
>>189
どこが困るのかな?

194 :デフォルトの名無しさん:2010/06/18(金) 09:27:08
可変長テンプレートつかった可変長引数の関数って引数は再帰で取り出すしかないんですか?
再帰はオーバーヘッドがありそうで嫌です

195 :デフォルトの名無しさん:2010/06/18(金) 12:04:45
じゃあ使うな

196 :デフォルトの名無しさん:2010/06/18(金) 12:07:27
>>194
ちょっと意味わからないから
コードを2chのこのスレッドに投稿してくれる??


197 :デフォルトの名無しさん:2010/06/18(金) 14:19:01 ?2BP(0)
「2chのこのスレッドに」とわざわざ言うのは
「this->」みたいなもんか

198 :デフォルトの名無しさん:2010/06/18(金) 15:45:10
const Hoge &は左辺・右辺とわず受け取れるけど
非constで左辺・右辺両方を受け取れるにはどうすればいいの?

199 :デフォルトの名無しさん:2010/06/18(金) 16:15:58
マクロで仮引数の型だけ違う同じ内容の函数を書き出す

200 :デフォルトの名無しさん:2010/06/18(金) 19:20:02
非constの右辺値受け取ってどうするんだろう

201 :デフォルトの名無しさん:2010/06/18(金) 19:30:21
move

202 :デフォルトの名無しさん:2010/06/18(金) 19:57:11
おいこらConceptはいつ入るんだ

203 :デフォルトの名無しさん:2010/06/18(金) 20:03:29
Conceptはみんなの心の中に生き続けているよ

204 :デフォルトの名無しさん:2010/06/18(金) 20:51:39
C++1xにご期待ください。

205 :デフォルトの名無しさん:2010/06/18(金) 20:53:31
>>200だけど、自分の書いたソースコードの中で使用例見つけてしまった。
コンテナから本体を書き換えることのできる部分コンテナを返す関数を
別の関数に参照渡しする場合だな。
具体的にはOpenCVのcv::Matの部分配列(ROI)なんだが。

VC++の非標準の拡張によって右辺値が非constの左辺値参照に置き換えられてたみたいだ。
コンパイルレベルをあげたら警告が出た。

206 :デフォルトの名無しさん:2010/06/18(金) 20:59:00
>>198
右辺値を非constで左辺値のように受けるのは危険だから受けられないようになっている。そのための&&だ。
まずそれが必要か考え直したほうがいい。

207 :デフォルトの名無しさん:2010/06/19(土) 02:14:34
すみません質問ですが
#include <iostream>
auto main() -> int
{
  []{ std::cout << "hello, world\n"; }();
}

以下の部分は何を意味してるのでしょうか?
main() -> int

208 :デフォルトの名無しさん:2010/06/19(土) 02:19:48
推論不能時の戻り値

209 :デフォルトの名無しさん:2010/06/19(土) 02:21:04
「返却値」だろうが

210 :デフォルトの名無しさん:2010/06/19(土) 02:24:04
それ俺がν速で書いた奴じゃないかw

211 :デフォルトの名無しさん:2010/06/19(土) 02:25:06
そんなクソ短いコードなんてとっくの昔に誰かが書いてるわ

212 :207:2010/06/19(土) 02:26:00
ありがとうございます

213 :デフォルトの名無しさん:2010/06/19(土) 08:36:41
戻り値を後ろに書く構文ってだけ

214 :デフォルトの名無しさん:2010/06/19(土) 08:43:30
>>213
auto func(int x)->decltype(hoge(x)){return hoge(x);}
これをこんな風にかけると二回同じ式を書かなくてすむんだけど
auto func(int x)->hoge(x);

215 :デフォルトの名無しさん:2010/06/19(土) 08:48:47
-> の後ろに直接式書くとかキモいことしなくても
普通にこれでええやん

auto func(int x) { return hoge(x); }

ラムダではできるのに普通の関数ではできない仕様なのは
ヘッダに書く関数や単一ファイル内で使う関数でないと意味がないからか?
と思ったけど、これやりたいのって大体関数テンプレートだから
できてもいいように思える

216 :デフォルトの名無しさん:2010/06/19(土) 08:51:03
Unified Function Syntaxにも戻り型推測提案してこい

217 :デフォルトの名無しさん:2010/06/19(土) 08:56:11
>>215
そんな記述もできるの?
{}のなかを評価しないと戻りの型が決まらないんでできないと思ってた。コンパイラは大変だなあ
もしこの関数がメンバー関数の場合{}の中は前方参照不可とか制約無いのかな?

218 :デフォルトの名無しさん:2010/06/19(土) 08:56:12
もうUnified function syntaxのことは忘れようぜ…
とっくにrejectされてんだから

219 :デフォルトの名無しさん:2010/06/19(土) 08:56:43
>>217
できない

220 :デフォルトの名無しさん:2010/06/19(土) 08:58:14
auto func = [](int x){return hoge(x);};
なら行ける

けどテンプレートにできんのよね

221 :デフォルトの名無しさん:2010/06/19(土) 09:04:05
>>218
VC++2010で使えるけど、これは先走ったわけか
auto hoge() -> int { return 0; } // OK
int main() { return hoge(); }

222 :デフォルトの名無しさん:2010/06/19(土) 09:16:20
もう仕事に0x使い始めてるところなんてあるの?

223 :デフォルトの名無しさん:2010/06/19(土) 09:23:29
>>218 え?使えなくなったの?


224 :デフォルトの名無しさん:2010/06/19(土) 09:24:51
>>221
unified function syntaxってのはこれ
[]main()->int{ return 0; }

225 :デフォルトの名無しさん:2010/06/19(土) 09:31:49
>>224
なるほど

226 :デフォルトの名無しさん:2010/06/19(土) 09:35:18
>>217
ラムダでは戻り値型の推測はできるので
普通の関数でもできないわけじゃないはずだ

普通の関数は多値returnができるけど
ラムダではできないという違いも
普通の関数での戻り値推測がない点に関係あるのだろうか?

227 :デフォルトの名無しさん:2010/06/19(土) 09:37:35
ラムダは実装もすぐに書くから返り値がわかるけど
普通の関数やメンバ関数はヘッダとソースが分かれてるかもしれない

228 :デフォルトの名無しさん:2010/06/19(土) 09:41:06
分かれてない場合には使えるじゃない、と

229 :デフォルトの名無しさん:2010/06/19(土) 10:08:13
>>226
> 普通の関数は多値returnができるけど
C++ って多値返せないだろ, どういう意味だ?


230 :デフォルトの名無しさん:2010/06/19(土) 10:16:22
文脈からみて一個の関数内にreturnが複数個あるって事じゃね?

231 :188:2010/06/19(土) 10:22:53
>>191-192
gcc 4.4.0で起きたからレポートしようと思っていたらgcc 4.5.0で直ってた

232 :デフォルトの名無しさん:2010/06/19(土) 10:33:26
>>229
std::initializer_list を引数に取るコンストラクタを持つクラスが戻り値の型になってる場合、
return { 0, 1 }; みたいにできる

233 :デフォルトの名無しさん:2010/06/19(土) 18:22:52
for_each(v, [](auto &x){ return x+=10; });
みたいな引数の型を推論してくれるようなラムダってないの?ないの?の?

234 :デフォルトの名無しさん:2010/06/19(土) 18:30:45
だからboost::lambdaがなくならないのさ

235 :デフォルトの名無しさん:2010/06/19(土) 18:36:53
いい加減多次元の動的配列をサポートしろよ

236 :デフォルトの名無しさん:2010/06/19(土) 19:04:51
>>235
イラネ、ライブラリで対応できる。
そういう言語サポートが必要なのは拡張能力の乏しい言語だけ

237 :デフォルトの名無しさん:2010/06/19(土) 19:07:57
どうしてBoost.MultiArrayを標準化しなかった。

238 :デフォルトの名無しさん:2010/06/19(土) 19:11:30
標準にするにはマニアックすぎたんじゃないか?
第二水準標準ライブラリとか作って採用して欲しい。

239 :デフォルトの名無しさん:2010/06/19(土) 19:14:26
ライブラリでできるからといって組み込みで必要ないというなら
initializer_listもライブラリでいいんだな?

240 :188:2010/06/19(土) 19:25:21
>>236
いや処理系の問題だが、ICCなんかループが深くなると添字の計算をループの外に出さなくなって途端に遅くなる問題とかあるぞ。

m x nの二次元配列aで直線的にアクセスする場合、
for ( int j = 0; j < n; ++j ) {
for ( int i = 0; i < m; ++i ) {
// a[i+j*m] を読み出してなんか処理
}}
で通常j*mはfor(i)の外に移動される。
でもこのループが同じ関数内でも4重5重とネストが深い時に外に出されなくなった。

これが三次元配列、四次元配列となるにつれ、
a[i+j*m+k*m*n+l*m*n*o ...]と式が複雑になっていって、コンパイラを混乱させる。
なので多次元配列が組み込みとして存在すれば、最適化の推論は簡単になる。

241 :デフォルトの名無しさん:2010/06/19(土) 19:28:25
>>240
多次元配列に夢の持ちすぎだろう。

242 :デフォルトの名無しさん:2010/06/19(土) 19:36:50
>>240
そういうのって、部分配列で次元数を減少させてループを書いたりするんじゃね?

いくら組み込みでも多次元の添え字をランダムアクセスで渡せば最適化できないだろう。結局同じテクニックが必要だと思うんだ。

243 :デフォルトの名無しさん:2010/06/19(土) 19:51:32
>>240
処理系の所為なら同じ問題が起きるだけじゃね?

244 :デフォルトの名無しさん:2010/06/19(土) 20:50:00
多次元配列って実装が一種類じゃないんだよね。
C配列、FORTRAN配列、row-first、collumn-first
使用目的に応じて実装できるライブラリが適してると思うんだよ。
行列にしても、帯行列、三角、スパース行列、など行列の特性に応じた格納方法があるし。

組み込み多次元配列を用意したところで適用できなければメリットは小さいと思うよ。

245 :188:2010/06/19(土) 21:13:45
>>244
その理論だとFORTRANに多次元配列がある説明になっていないぞ。

確かに疎行列のような特殊なものはライブラリで補うしかない。
row-first、column-firstも行列積の概念から来ているだけ。
C言語的に必要なのはa(i, j)があった時にメモリが隣接しているのはどっちの添字かという事だけ。縦も横も無い。
あとCの静的多次元配列は「ポインタの配列」または「ポインタのポインタ」と矛盾しないようにあんな順序になっているだけ。

>>235は単に基本となる配列を動的多次元にしてくれって言っているだけでしょ。
そしてその意見には>>240的観点から賛同する。

246 :デフォルトの名無しさん:2010/06/19(土) 21:32:22
いい加減自己主張やめて名前欄消せ

247 :デフォルトの名無しさん:2010/06/19(土) 23:56:42
可変長テンプレート引数を利用すれば
std::vectorからの0オーバーヘッドを保ちつつ作れそうか

248 :デフォルトの名無しさん:2010/06/20(日) 01:39:13
例え次元数固定でもテンプレートで作っちゃうと、毎回愚直にアドレス計算されるよ。

249 :デフォルトの名無しさん:2010/06/20(日) 01:54:51
特殊化すりゃいいだけじゃん

250 :デフォルトの名無しさん:2010/06/20(日) 06:25:21
特殊化してもj*mをループの外に移動出来ないでしょ。

251 :デフォルトの名無しさん:2010/06/20(日) 08:30:17
多次元配列が欲しいんじゃなくて最適化して欲しいだけじゃないか

252 :デフォルトの名無しさん:2010/06/20(日) 08:39:11
boostの多次元配列はコンパイル時間長いし、そもそもboost禁止の場合もある
組み込みの多次元配列が有ってうれしいことはあっても困ることはない

253 :デフォルトの名無しさん:2010/06/20(日) 09:05:12
組み込みの多次元配列がなくて困ると言う声がほとんどない以上、入る事はないな。

254 :デフォルトの名無しさん:2010/06/20(日) 09:14:11
利便性の向上でもあり、最適化のヒントにもなるツール。
言語の歴史から言えば多分RVOよかよっぽど基本的な話。

255 :デフォルトの名無しさん:2010/06/20(日) 09:14:41
困ることが無いから入れるという理屈では入ることは無い。
実現方法がたくさんあると、ライブラリ間でのデータの受け渡しに支障が出る。


256 :デフォルトの名無しさん:2010/06/20(日) 09:27:42
NULL終端じゃなくてサイズ+データの基本データ型があるだけでも汎用性高いんだけどね。
FORTRANはデータだけでもコンパイラに多次元配列である事を伝えることが出来る。
Cっぽく書くと
void func(int n, int m, int array[m][n]) {}
ってな感じ。

257 :デフォルトの名無しさん:2010/06/20(日) 09:32:53
C++ で数値計算しようと思わないからいらね > 多次元配列


258 :デフォルトの名無しさん:2010/06/20(日) 09:39:45
initializer_listで受け取った引数は連続領域にある前提で書いていいの?

259 :デフォルトの名無しさん:2010/06/20(日) 09:40:08
多次元配列はライブラリでできるのがC++
組み込みじゃないなと嫌っていう人はFORTRANを遣えば良いってだけの話。

260 :デフォルトの名無しさん:2010/06/20(日) 09:41:38
はいはい数値計算数値計算。
そういう本質が分からん奴に限ってWin32APIで絵を表示しようとしたときに
SetPixelを使って、「遅い」とか言い出すんだよなあ。

261 :デフォルトの名無しさん:2010/06/20(日) 09:42:22
必要度 concept>多次元配列

コンセプトは必要。マジ欲しい。

262 :デフォルトの名無しさん:2010/06/20(日) 09:44:00
>>255
そうそう
規格で統一すれば異なるライブラリ間で多次元配列を簡単にやり取りできるのにね

263 :デフォルトの名無しさん:2010/06/20(日) 09:50:59
>258
一旦配列に確保されたかのように扱われるから OK のはず。end() も begin() + size() になってる。

264 :デフォルトの名無しさん:2010/06/21(月) 12:34:28
最適化のためのキーワード(や、それに代わるもの)がほしいって話なら…
registerが肥やしに変わった以上、マジそれがないと実現不可能とかじゃないと追加は難しいんじゃないかな

上の例だと「ネストが深くても最適化してくんない?」ってIntelにリクエストすればいいだけだし

265 :デフォルトの名無しさん:2010/06/22(火) 02:03:03
これ以上議論する気はないけれど、配列に追加のキーワードはいらないだろ。
そんなこと言うならRVOとかmoveとか口にするなよ。
initializer_listだってなんだって、多くのものは利便性の向上をメインとして
更に最適化の機会向上も兼ね備えているんだよ。

266 :デフォルトの名無しさん:2010/06/22(火) 07:00:08
これ以上議論する気はないけれどと言っておきながら議論ふっかける男の人って。。。

267 :デフォルトの名無しさん:2010/06/22(火) 07:13:06
自分の言いたいことは言うけど、反論されるのは怖いからやめてください。

268 :デフォルトの名無しさん:2010/06/22(火) 07:22:11
initializer_listって配列の代わりに使えるよな
もっと一般化できそうだが

269 :デフォルトの名無しさん:2010/06/22(火) 08:18:46
反論は怖くない。そこから得られるものがあればいい。
あまり続けると、他の話題を出したい人が話に割り込めなくなるのが怖いだけだ。

270 :デフォルトの名無しさん:2010/06/22(火) 08:20:20
無様な言い訳をする男の人って軟弱でステキ!

271 :デフォルトの名無しさん:2010/06/22(火) 11:47:02
ユーザー定義リテラルなんかよりインクルードガードが欲しかったな

272 :デフォルトの名無しさん:2010/06/22(火) 11:51:11
途中まで #pragma once が規格に残っていたのにいつのまにか消えたのは何でだろう

273 :デフォルトの名無しさん:2010/06/22(火) 12:40:08
>>272
いい事だ

274 :デフォルトの名無しさん:2010/06/22(火) 13:21:51
gcc と vc は #pragma once 使えるから規格になくてもいいや

275 :デフォルトの名無しさん:2010/06/22(火) 14:59:48
LLVMのCLangも大きな派閥になってくると思う。
ConceptGCCの中の人がC++サポートをやってるし。

276 :デフォルトの名無しさん:2010/06/22(火) 21:01:57
>>272
インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
#pragma oneceだとヘッダの参照関係が循環してもコンパイルが通ってしまって不便、危険。


277 :デフォルトの名無しさん:2010/06/22(火) 21:23:05
??

278 :デフォルトの名無しさん:2010/06/22(火) 21:39:28
循環参照を気にしなくてもいいように#pragma once使うんじゃないの?

279 :デフォルトの名無しさん:2010/06/22(火) 21:39:43
#pragma once の問題はハードリンクをどう扱うか程度じゃなかったっけか?
そしてそれが致命傷

280 :デフォルトの名無しさん:2010/06/22(火) 21:41:36
インクルードガード内の循環参照は重複してインクルードされないだろ

281 :デフォルトの名無しさん:2010/06/22(火) 22:18:18
>>280
インクルードされないから循環参照をエラーとして検出できる。

282 :デフォルトの名無しさん:2010/06/22(火) 22:28:47
例を出せ
もちろんちゃんとコンパイルして期待した動作をすることを確かめてからな

283 :デフォルトの名無しさん:2010/06/22(火) 22:36:01
// a.h
#ifndef a_h
#define a_h
#include "b.h"
struct A {};
#endif a_h

// b.h
#ifndef b_h
#define b_h
#include "a.h" // 循環参照
struct B {};
#endif b_h

// a.cpp
#include <ostream>
#include "a.h"
int main() {
std::cout << sizeof(A) << ' ' << sizeof(B) << std::endl;
}

問題なくコンパイルできる

284 :デフォルトの名無しさん:2010/06/22(火) 22:37:43
循環参照が#pragma onceにしただけで解消されるとか
どんなファンタジーなんだ

285 :デフォルトの名無しさん:2010/06/23(水) 03:22:22
std::pair を
template<typename U, typename... Args> pair(U&&, Args&&...)
で構築するとして
pair<int, int> p(1);
の second は zero-initialized と決まってるんでしょうか

286 :デフォルトの名無しさん:2010/06/23(水) 04:22:40
インクルードガードを書けば循環参照が検出できるなんて
どんなファンタジーなんだ

287 :デフォルトの名無しさん:2010/06/23(水) 10:57:13
#includeは参照じゃないだろ。
ファイルに埋め込まれるから自己埋め込みになる。

288 :デフォルトの名無しさん:2010/06/23(水) 11:11:05
>インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
そろそろサンプルぷりーず

289 :デフォルトの名無しさん:2010/06/23(水) 11:22:58
#errorで自分でやるんじゃないの

290 :デフォルトの名無しさん:2010/06/23(水) 12:46:24
#includeはただの埋め込みだとなんどいったら(ry

291 :デフォルトの名無しさん:2010/06/23(水) 14:28:57
>285
そのコンストラクタは N3092 には無いです.

292 :デフォルトの名無しさん:2010/06/23(水) 16:29:09
クラスの循環参照とごっちゃになってる人がいる?

293 :デフォルトの名無しさん:2010/06/23(水) 16:32:27
このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンパイラの仕組みも理解してない人多くね?

294 :デフォルトの名無しさん:2010/06/23(水) 16:49:05
クラスの循環参照って何?

コンパイラの仕組みとか以前というか
自分で勝手に意味を決めてるやつが多いのかな?

295 :デフォルトの名無しさん:2010/06/23(水) 16:54:57
VCのpragma onceて、初見のソースにつき一回しか参照っていうか取り込みされないと思ってたのだがちがったのか?

296 :デフォルトの名無しさん:2010/06/23(水) 18:42:57
違わない

297 :デフォルトの名無しさん:2010/06/23(水) 19:13:15
だよ〜ね。

298 :デフォルトの名無しさん:2010/06/23(水) 19:21:41
しかし、ハードリンクが絡むと状況は複雑になる
パスが全く違っても同じ実体を指している事があるけど、
それも検出せなあかんのん? と

299 :デフォルトの名無しさん:2010/06/23(水) 19:24:20
iノード番号でわかるだろ

300 :デフォルトの名無しさん:2010/06/23(水) 19:25:10
内容が全く同じソースなら弾けばいいんじゃないのかしら?
たとえ実態が別々でも

301 :デフォルトの名無しさん:2010/06/23(水) 19:47:34
環境によっては色々面倒な話が出てくるから、規格から外されたわけだ。

302 :デフォルトの名無しさん:2010/06/23(水) 19:50:27
環境ごとの面倒な話を統一するための規格じゃないのか
根性ねえなぁ

303 :デフォルトの名無しさん:2010/06/23(水) 19:53:11
めんどくせぇ

304 :デフォルトの名無しさん:2010/06/23(水) 19:57:11
>>291
ソデスカ… orz
では、pair に限らず (U&&, Args&&... args) の args が省略された場合
fundamental type を forward<Args>(args)... で構築した場合
zero-initialized と期待していいのでしょうか

305 :デフォルトの名無しさん:2010/06/23(水) 20:11:31
>>302
ディレクトリ操作すら規格にない言語だから仕方がない
かろうじてディレクトリに関するerrnoがあるくらいだ

306 :デフォルトの名無しさん:2010/06/23(水) 21:34:56
禿は # で始まらない include を夢見てたようだが

307 :デフォルトの名無しさん:2010/06/23(水) 21:40:30
ソースファイルをコンパイルしたら
外部に公開できる宣言をまとめたファイルが自動的に作られて、
それをimportするような感じになってくれればなあと思う

308 :デフォルトの名無しさん:2010/06/23(水) 21:44:58
むしろ、ソースファイルを指定したら、
そこから必要な宣言集を構築してくれるような仕組みの方がいい。
わざわざ分ける必要はない。
いまどきヘッダーファイルなんて時代じゃねーだろ。

309 :デフォルトの名無しさん:2010/06/23(水) 21:45:58
それはC++/CLI

310 :デフォルトの名無しさん:2010/06/23(水) 22:44:31
>>308
C++でそれやると現実的なコンパイル速度にならない気がする

311 :デフォルトの名無しさん:2010/06/23(水) 23:00:42
>>307-308

まさにGoのやり方.

312 :デフォルトの名無しさん:2010/06/24(木) 08:09:14
コンパイルとリンクが別になってるのが既に時代遅れ

313 :デフォルトの名無しさん:2010/06/24(木) 08:39:24
暗号化がデフォじゃないのもね

314 :デフォルトの名無しさん:2010/06/24(木) 10:05:24
> 暗号化がデフォじゃないのもね
お前のプログラムがリバースエンジニアリングの対象になるわけねーだろ
思い上がるな

315 :デフォルトの名無しさん:2010/06/24(木) 10:38:37
このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンピューターの仕組みも理解してない人多くね?

316 :デフォルトの名無しさん:2010/06/24(木) 13:26:45
流石コンピューターおばあちゃんは言うことが違う

317 :デフォルトの名無しさん:2010/06/24(木) 14:57:25
bool operator && (function<bool ()> reval);
こんな感じで右辺の評価が自動で関数オブジェクトになりshort circuitが可能になると思っていたのに自分でlambdaにしないと駄目なのか

318 :デフォルトの名無しさん:2010/06/24(木) 21:38:20
initializer_listってどうなってんだ?
typedefしたらコンパイル通らなくなるし、配列のように振る舞うって聞いたのに代入したらベクターみたいに動作するし、[]の中に{}突っ込んでもエラー出るしでわけわからん

319 :デフォルトの名無しさん:2010/06/24(木) 21:41:03
VC++2010か
まだ対応してないぞ
定義はあるけど

320 :デフォルトの名無しさん:2010/06/24(木) 22:05:14
VC++2010は色々と残念

321 :デフォルトの名無しさん:2010/06/24(木) 22:09:17
>>320
IDEは2008の改良でいいのにあちこち退化して残念

322 :デフォルトの名無しさん:2010/06/24(木) 22:09:47
いやgcc4.5.0の話です

323 :デフォルトの名無しさん:2010/06/24(木) 22:18:40
-std=c++0x(gnu++0x)付けた?

324 :デフォルトの名無しさん:2010/06/24(木) 22:20:11
もちろん

325 :デフォルトの名無しさん:2010/06/24(木) 22:21:59
gccの実装はまだ完全じゃないからな。
typedefはワケ分からんが、operator []は、まだ実装してない。
だいたい、initializer_listは配列のように振舞わない、どこで聞いたんだそんな話。

326 :デフォルトの名無しさん:2010/06/24(木) 22:25:55
typedefが動かないバグは上がってないな。
報告しておいたら?

327 :デフォルトの名無しさん:2010/06/24(木) 22:28:11
いや、配列のようにってのはここできいたんだがw

328 :デフォルトの名無しさん:2010/06/24(木) 22:30:18
ネット上に出回る情報が全部正しい訳じゃないなんていつものこと

329 :デフォルトの名無しさん:2010/06/24(木) 22:34:33
まあ、リスト初期化の構文自体は、素の配列や構造体を初期化する文法を、
ユーザー定義のクラスでも使えるようにしようというものだから、
その辺が伝聞が変化したのかも。


初期化リスト(initializer list)は、あたかも配列を初期化するように振舞う

std::initializer_listは、あたかも配列のように振舞う


330 :デフォルトの名無しさん:2010/06/24(木) 22:43:25
ラムダからinitializer listをreturnできるようにしてくださいよぉ

331 :デフォルトの名無しさん:2010/06/24(木) 22:56:17
これじゃだめか?

[]() -> std::vector<int>
{
std::vector<int> v = {1,2,3} ;
return v ;
} ;

332 :デフォルトの名無しさん:2010/06/24(木) 22:59:13
auto foo = []() -> std::vector<int> { return { 1, 2, 3 }; };

みたいにしたいんだけどねえ
普通の関数ではできるのに

何で禁止したんだろ
実装が難しいの?

333 :デフォルトの名無しさん:2010/06/24(木) 23:05:10
ていうかそれでいいのなら、こういうことはできるがな。

[] { return std::vector<int>{1,2,3} ; } ;

334 :デフォルトの名無しさん:2010/06/25(金) 07:17:43
returnが多いと面倒くさいけど
仕方がないのかねえ

335 :デフォルトの名無しさん:2010/06/25(金) 08:19:46
おれ的には右辺値参照と可変長テンプレートとラムダだけで十分だった


336 :デフォルトの名無しさん:2010/06/25(金) 09:09:48
conceptほしかった…

337 :デフォルトの名無しさん:2010/06/25(金) 09:15:05
conceptは犠牲になったのだ……

338 :デフォルトの名無しさん:2010/06/25(金) 09:30:03
0xの犠牲にな

339 :デフォルトの名無しさん:2010/06/25(金) 10:11:30
最適化の為だけのキーワードが云々ほざいてる奴もいたが、俺はconstexprが好きだぜ。

340 :デフォルトの名無しさん:2010/06/25(金) 11:53:17
それって最適化か?

341 :デフォルトの名無しさん:2010/06/25(金) 19:24:21
332のコードは通るでしょ

342 :デフォルトの名無しさん:2010/06/25(金) 22:16:39
constexprはTMPの道具でしょ

343 :デフォルトの名無しさん:2010/06/26(土) 00:38:01
>>342
それだけじゃないよ

344 :デフォルトの名無しさん:2010/06/27(日) 11:03:16
<unordered_set>で余分なバケツを削る方法はありませんか?
(<vector>でのいわゆるswap技法に対応するもの)

345 :デフォルトの名無しさん:2010/06/27(日) 11:06:28
ん?swap技法使えないのか?

346 :デフォルトの名無しさん:2010/06/27(日) 11:15:36
こんな感じです。(コピペできなくてすみません)

unordered_set<int> s;
for (i in 0...100) s.insert(i);
cout << s.bucket_count() << endl;
unordered_set<int>(s).swap(s);
cout << s.bucket_count() << endl;

> 199
> 199

347 :デフォルトの名無しさん:2010/06/27(日) 11:18:30
unordered_set<int>(s).swap(s);
これだとsと同じコンテナとsの中身を交換という形になってしまうぞ。
vectorで同じことをしてもreserveされた領域は小さくなるだろうが、サイズは変わらない。

348 :デフォルトの名無しさん:2010/06/27(日) 11:21:24
>>346
バケツとアイテム数は同じにはならないだろ。
1000個挿入して900個消してからやってみ

349 :デフォルトの名無しさん:2010/06/27(日) 11:23:29
unordered_set<int>().swap(s);

350 :デフォルトの名無しさん:2010/06/27(日) 11:24:03
s.empty()

351 :デフォルトの名無しさん:2010/06/27(日) 11:24:55
>>350これはひどい

まあこのメンバ関数名もどうかと思うけど

352 :デフォルトの名無しさん:2010/06/27(日) 11:27:01
わたし350だけど349したらs.empty()が真になるって言いたかったんだけど

353 :350:2010/06/27(日) 11:29:12
みんなひどい!もうしらない!

354 :デフォルトの名無しさん:2010/06/27(日) 11:30:05
やりたいことが伝わってなかったようで、申し訳ないです。
そもそもの目的は、
rehash(n)でバケツの数がn「以上」になってしまうのを
ちょうどnにしたいのです。

355 :デフォルトの名無しさん:2010/06/27(日) 11:30:07
clearしても真にはなるでしょ、と

356 :354:2010/06/27(日) 11:33:58
unordered_set<myclass>
になっていて、ハッシュ関数もユーザ定義しています。

357 :デフォルトの名無しさん:2010/06/27(日) 11:34:16
>>354
ならないし、気にするな

358 :354:2010/06/27(日) 11:38:24
>>357
やっぱ無理なんですか・・・。
別の目的に使うhackをしてたんだけど。残念です。

359 :デフォルトの名無しさん:2010/06/27(日) 11:40:36
我流unodered_setを作ろう

360 :デフォルトの名無しさん:2010/06/27(日) 11:42:59
>>359
そうだな、自分で作れば理由もわかるしな

361 :354:2010/06/27(日) 11:43:51
ウェブ上で複数の人が「バケツへのアクセスが提供されてる理由が不明」、
と言っておられるようですが、歴史的な経緯って誰か知りませんか?

362 :354:2010/06/27(日) 11:44:51
>> 359,360
CSの人じゃないので、
お手軽hackに走っちゃうんですよね・・・。
精進します。

363 :デフォルトの名無しさん:2010/06/27(日) 11:48:29
>>361
どういう意図で言ってるのか解らんのでurl貼って。

364 :デフォルトの名無しさん:2010/06/27(日) 11:51:41
>>361

http://www.google.co.jp/search?q=%22%83o%83P%83c%82%D6%82%CC%83A%83N%83Z%83X%82%AA%92%F1%8B%9F%82%B3%82%EA%82%C4%82%E9%97%9D%97R%82%AA%95s%96%BE%22

そんなことを言っている奴はいない。
なんでそういう嘘をつくんだよ?

365 :354:2010/06/27(日) 11:55:12
http://cpplover.blogspot.com/2008/05/c0xunordered.html
あいまいな記憶ですけどここ以外にもあったような。

366 :デフォルトの名無しさん:2010/06/27(日) 12:02:03
まあアクセスしたいこともあるだろう
ハッシュの性能評価とか

367 :デフォルトの名無しさん:2010/06/27(日) 12:03:33
>>365
>bucketの個数や容量、使用量を取得するメンバがあり、さらには、あるキーがどのbucketに属するかを取得するメンバもある
これだけ解ればハッシュをチューニングできるし、バケツにアクセスする必要ないだろう。
バケツへのアクセスを規定したら実装方法に制限を加えることになるから妥当じゃないのか。

368 :デフォルトの名無しさん:2010/06/27(日) 19:14:31
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html の G. Bucket Interface より
It's also useful to expose the bucket structure, for two reasons.
First, it lets users investigate how well their hash function performs: it lets them test how evenly elements are distributed within buckets,
and to look at the elements within a bucket to see if they have any common properties.
Second, if the iterators have an underlying segmented structure (as they do in existing singly linked list implementations),
algorithms that exploit that structure, with an explicit nested loop, can be more efficient than algorithms that view the elements as a flat range.

だそうだ

369 :354:2010/06/27(日) 20:34:24
おぉ、ということは変な使い方しても怒られないのね。
わざわざ調べていただいて、ありがとうございました。

370 :デフォルトの名無しさん:2010/06/27(日) 20:35:39
私も354ではありませんが勉強になりました。ありがとうございました。

371 :デフォルトの名無しさん:2010/06/27(日) 20:35:50
俺漏れも

372 :デフォルトの名無しさん:2010/06/29(火) 12:15:04
タプルはinit_listで初期化できないみたいですが、
こんなのを
my_tuple<int,int> tup={1,2};
自分でつくるとしたらどうするのがいいんですかね?
サイズの型チェックできなそうだし・・・。

373 :デフォルトの名無しさん:2010/06/29(火) 18:31:03
型が全て同じという前提なら作れるだろうけど
そうでなければboost::anyで包むしか

374 :デフォルトの名無しさん:2010/06/29(火) 20:37:31
てすと

375 :デフォルトの名無しさん:2010/06/29(火) 20:49:20
>>372
ctor がexplicit でなければ uniform initialization が使えるはず

376 :デフォルトの名無しさん:2010/06/29(火) 21:57:44
可変長テンプレートでコンストラクタ書いて{}で初期化したいって場合に
違う型が混ざってれば問題ないんだけどすべて同じ型だとイニリスになって定義してないとコンパイルエラー
納得いかないわ

377 :デフォルトの名無しさん:2010/06/29(火) 22:46:04
>>376
もしあなたの処理系で std::tuple<int,int,int> t = {1, 2, 3}; でコンパイルエラーがでないなら、
あなたが何か勘違いしてるのだろう。

378 :デフォルトの名無しさん:2010/06/29(火) 23:05:02
どういうこった? 素直に書くとこうなるが。

struct C
{
template < typename... Types >
C(Types... args) { }
} ;

int main()
{
C c = {1,2,3} ;
}

当然これは通る。
通らなければお前のコンパイラがマヌケなだけだが。

379 :デフォルトの名無しさん:2010/06/29(火) 23:10:44
gcc5.0.0だが通らないぞ
まじマヌケだなこの糞コンパイラ

380 :デフォルトの名無しさん:2010/06/29(火) 23:16:02
Comeau.Computing

Comeau C/C++
では通らないの?



381 :デフォルトの名無しさん:2010/06/30(水) 05:23:06
gcc 5.0。
未来からタイムマシーンでやってきたのか?

382 :デフォルトの名無しさん:2010/06/30(水) 08:36:29
gcc4.5.0ね間違えた

383 :デフォルトの名無しさん:2010/06/30(水) 08:43:38
まあ、gccはあてにならんな。
ちなみに、4.6だと>>378は通る。

384 :デフォルトの名無しさん:2010/06/30(水) 11:03:48
テンプレート関数のテンプレートで型を指定した場合にテンプレートの型が
ムーブコンストラクターを実装している場合に、その型のオブジェクトを返すとき戻り値をmove( );で返して
その他の場合はNRVOを使うために普通に返す。
なんて事ができる?

385 :デフォルトの名無しさん:2010/06/30(水) 11:35:10
普通に戻り値の型を非参照にして、return std::move(t)すりゃいいだろ。
それでRVOできなけりゃ、そりゃコンパイラがバカなだけだ。

386 :デフォルトの名無しさん:2010/06/30(水) 11:59:08
戻り値の型を非参照にするって???

387 :デフォルトの名無しさん:2010/06/30(水) 12:07:31
そのまんまの意味だよ。
参照ではないprvalueで返せばいい。

class C {} ;

C f() { C c ; return std::move(c) ; }

int main()
{
C c = f() ;// まともなコンパイラならRVOできる
}

388 :デフォルトの名無しさん:2010/06/30(水) 12:40:21
悪いけど全く意味が分からない。
日本語でおk

389 :デフォルトの名無しさん:2010/06/30(水) 13:18:57
正解かどうかはともかく言ってる意味は分かるだろ…
理解できる言語が日本語だけだと厳しいかもしれないがw

390 :デフォルトの名無しさん:2010/07/01(木) 12:03:39
>>384
そもそも return move(....); がいらないだろ。 return ...; で同じことになるんじゃなかったっけ?

391 :デフォルトの名無しさん:2010/07/01(木) 13:19:51
それもそうだ。

392 :デフォルトの名無しさん:2010/07/01(木) 13:47:54
それは最適化じゃなくて必ずそうなるって決まりなの?

393 :デフォルトの名無しさん:2010/07/01(木) 14:33:45
C++の標準規格には、必ず最適化せよという決まりは、まずないぞ。
Schemeの規格に、必ず末尾再帰の最適化をせよ、とあるのは、Schemeにとっては絶対に外せない根本的な概念だからなんだろうな。

ちなみに、return文の式は、コピーかムーブコンストラクターかのオーバーロード解決のためならば、
rvalueとして扱ってもいいことになっている。

394 :デフォルトの名無しさん:2010/07/01(木) 21:01:28
「扱ってもいい」って何だよ…
returnの式はソースだけじゃtaxon決まらないのかよ
相変わらず気持ち悪い仕様だな

395 :デフォルトの名無しさん:2010/07/02(金) 01:54:47
気持ち悪い=個人的に理解不能
ってだけの話

396 :デフォルトの名無しさん:2010/07/02(金) 02:09:17
そうかなぁ
lvalueかrvalueかがunspecifiedな第4のvalue taxonが隠れてるって事じゃないの?
キモイよ

397 :デフォルトの名無しさん:2010/07/02(金) 12:30:39
return move(....); がいらないってどういうことだよ?
無かったら一時オブジェクトにコピーするときコピーコンストラクターが
呼ばれてしまうとおもうがwwwww

398 :デフォルトの名無しさん:2010/07/02(金) 13:52:39
だから、rvalueとして扱っていいってことだよ。

return文の式は、関数の戻り値の型に変換される。
これが大前提の挙動。

このとき、コピー、ムーブコンストラクターの呼び出しを省略してもよい
これが、RVO(Return Value Optimization)と呼ばれるもの。

このとき、コピーかムーブかのコンストラクターのオーバーロード解決のために、
式をrvalueとみなしてもよい。(つまり、ムーブコンストラクターを呼べる)

どんな式でもというわけにはいかんが、どうせreturn文が評価されるということは、
その関数のブロックスコープを抜けるということであって、ローカル変数の寿命は終わる。
もし、式がローカル変数のlvalueだとしたら、ムーブしたっていいだろ、どうせすぐ死ぬんだから。

399 :デフォルトの名無しさん:2010/07/02(金) 13:58:24
誰か規格をもってきてくれ……

400 :デフォルトの名無しさん:2010/07/02(金) 14:00:29
>>398
机上の空論乙

401 :デフォルトの名無しさん:2010/07/02(金) 14:22:26
まあ移植した時にどうなるかわからんのだし明示的に書けばいいじゃん

402 :デフォルトの名無しさん:2010/07/02(金) 21:34:32
>398
「rvalue とみなしてもよい」ではなくて「まず rvalue とみなす」では?

403 :デフォルトの名無しさん:2010/07/02(金) 22:02:21
N3092 の 12.8/34 には
「ある基準が満たされたときに "when certain criteria are met",
RVO に相当する最適化をやっても良い "an implementation is allowed to...".
ごにょごにょ.
で, copy/move の省略は以下の状況で許される (...is permitted in the following circumstances).
(以下,その条件が列挙されている)」
と書いてあって, N3092 の 12.8/35 には
「copy の省略のための基準(★)が満たされていて "when the criteria for elision of a copy operation are met"
コピーされようとしているオブジェクトが lvalue なら,
コピーのためのコンストラクタを選択するオーバーロード解決は "overload resolution to select the constructor for the copy"
まずコピーされようとしているそのオブジェクトが rvalue であるかのように実行される
"is first performed as if the object were designated by an rvalue".」

★の基準は 12.8/34 に記述されている条件を指していると思われます.
で, 12.8/34 に列挙されている条件のうちの第1の bullet に書いてある内容から,
「return 文の式が,関数の戻り値型と (cv-qualification の違いを無視して) 同じ型の
non-volatile の自動オブジェクトの名前である場合」という条件の場合,
12.8/35 に書いてある挙動 (まず右辺値として扱ってみる) が発動すると思います.
(12.8/35 に書いてある挙動が発動することが許される,ではない)

404 :デフォルトの名無しさん:2010/07/02(金) 22:12:04
え〜っと,つまりまとめると,

12.8/34 には「ある条件下でコピーの省略 (いわゆる RVO) を行うことが*許される*.この条件の1つに
return 文に指定された式が戻り値と同じ型の左辺値自動オブジェクトの場合がある.」と書いてあって,
12.8/35 には「12.8/34 に示された条件下では,コピー元をまず右辺値とみなせ. (みなしても良い,ではない)」
と書いてあるように読めますがどうでしょうか?

405 :デフォルトの名無しさん:2010/07/03(土) 01:38:18
おお本当だ。
コピーが省略出来る場合で、しかも省略しない場合は、まずムーブコンストラクターを優先的に使うんだな。

406 :デフォルトの名無しさん:2010/07/03(土) 12:54:20
RVOもしらん馬鹿が一人紛れ込んだか

407 :デフォルトの名無しさん:2010/07/04(日) 01:07:10
そんなことで勝ち誇れるなんて幸せですね
もしかしてオランダ在住ですか?

408 :デフォルトの名無しさん:2010/07/04(日) 13:33:18
難しいな。例えば可視性が絡んだらどうなるんだろ?
例えば下のauto_ptr-ライクなコードはムーブコンストラクタ可能ならコンパイルできて、
コピーコンストラクタが呼ばれたり、RVOが採用される場合はコンパイルエラーになるの?
ちなみにVS2010だとムーブコンストラクタが呼ばれる。

class Foo {
public:
Foo() : ptr_(new int(3)) {
std::clog << "construct Foo()\n";
}
~Foo() {
std::clog << "destruct Foo()\n";
delete ptr_;
}
Foo(Foo&& rhs) : ptr_(rhs.ptr_) {
std::clog << "construct Foo() by move\n";
rhs.ptr_ = 0;
}
private:
Foo(const Foo& rhs);
Foo& operator=(const Foo&);
private:
int* ptr_;
};
Foo createFoo() {
Foo f;
return f;
}

409 :デフォルトの名無しさん:2010/07/04(日) 15:24:19
まずコピーが可能でなけりゃRVOは採用されない
ムーブが出来ない式ならコンパイルエラー
つーかunique_ptrに触れてみそ

410 :デフォルトの名無しさん:2010/07/05(月) 13:48:20
規格なんてどうでも良い、
GCCで出来るか出来ないか
それだけが問題だろ。

411 :デフォルトの名無しさん:2010/07/05(月) 15:52:25
規格も GCC もどうでも良い、
VCで出来るか出来ないか
それだけが問題さ。

412 :デフォルトの名無しさん:2010/07/05(月) 16:38:48
実装なんていらない。
規格がどうなっているか。
それだけが問題なり。

413 :デフォルトの名無しさん:2010/07/05(月) 17:31:20
実装がすべて。
委員会のメンバーは実装者/組織を代表している。
いかに自分たちの実装(に基づく規格)を通すか。
いかに自分たち(の実装に)不利な規格を落とすか。

だから日本からの提案は無いし(たまに)あっても通らない。
わかったかな?

414 :デフォルトの名無しさん:2010/07/05(月) 17:54:48
つまらんレスだな
わかるか?

415 :デフォルトの名無しさん:2010/07/05(月) 20:12:50
確かにお前のレスはつまらん

416 :デフォルトの名無しさん:2010/07/05(月) 21:22:06
うわホントにつまらんこの人

417 :デフォルトの名無しさん:2010/07/06(火) 12:57:30
http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Introduction-to-STL-with-Stephan-T-Lavavej/

Initializer ListとRange-base forが無い所為で残念なソースコード

418 :デフォルトの名無しさん:2010/07/06(火) 14:29:11
initializer listはともかく、コンセプトなしのrange based forなんてまったく骨抜きで使い物になんねーよ。

419 :デフォルトの名無しさん:2010/07/06(火) 14:31:34
c++2xにご期待ください

420 :デフォルトの名無しさん:2010/07/06(火) 14:56:09
>>418
そこでrange仮想クラスを継承ですよ、継承。

421 :デフォルトの名無しさん:2010/07/07(水) 10:36:09
今のところwindows環境でつかえる一番できのいい0xコンパイラーってどれですか?

422 :デフォルトの名無しさん:2010/07/07(水) 12:22:42
知るかボケ

423 :デフォルトの名無しさん:2010/07/07(水) 19:00:35
知っとけよアホ

424 :デフォルトの名無しさん:2010/07/07(水) 21:10:31
自分で作れ。
もちろんconceptsも実装してだ。

425 :デフォルトの名無しさん:2010/07/08(木) 00:51:06
C++0x以前に解決法があるのかもしれませんが、

template <class T, class P> class Base;
を次のように継承したい場合に
template <class T, template <class> class Q>
class Derived: Base<T,Q<T>> {
typedef Base<T,Q<T>> base;
}
長ったるいBase<T,Q<T>>を2度書くことになってしまいます。
うまい解決策はないでしょうか?

426 :デフォルトの名無しさん:2010/07/08(木) 01:03:59
つ define

427 :デフォルトの名無しさん:2010/07/08(木) 01:07:42
マクロはなしで・・・。

428 :デフォルトの名無しさん:2010/07/08(木) 01:15:33
手元のModern C++を眺めるかぎり、
#define TLIST_2(T1,T2) Typelist<T1, TLIST_1(T2)>
とかしてますね・・・。

やっぱ無理か。

429 :デフォルトの名無しさん:2010/07/08(木) 01:50:53
0xなら、usingで別名つければ少しは短くなりそうな。

430 :デフォルトの名無しさん:2010/07/08(木) 01:55:25
template <class T, template <class> class Q, typename U = Q<T>>
class Derived2: Base<T, U> {
  typedef Base<T, U> base;
};
とか

431 :デフォルトの名無しさん:2010/07/08(木) 02:15:04
>>430
その手を使うなら↓ここまでやったほうがよくね?
template <class T, template <class> class Q, class BaseT = Base<T,Q<T> > >
class Derived: BaseT {
typedef BaseT base;
};

432 :デフォルトの名無しさん:2010/07/08(木) 06:35:33
>>425

template <class T, template <class> class Q>
class Derived: Base<T,Q<T>> {
typedef Derived::Base base;
}

というかこれ、gccがおかしいんじゃねーかな。
Derivedにとって、Baseはinjected-class-nameだろ。

433 :デフォルトの名無しさん:2010/07/08(木) 06:36:52
あーすまん、この場合、BaseはDependant Nameじゃないな。そりゃ無理だ。

434 :425:2010/07/08(木) 13:58:25
各種ありがとうございました。

435 :デフォルトの名無しさん:2010/07/08(木) 20:25:39
C++0xの0xってどういう意味?

436 :デフォルトの名無しさん:2010/07/08(木) 20:28:31
xには0からF

437 :デフォルトの名無しさん:2010/07/08(木) 20:29:45
>>435
西暦200x年、人類に(ry

438 :デフォルトの名無しさん:2010/07/08(木) 20:58:21
一桁目だと誰が決めたのだろう
そう20x0だったんだよ!

439 :デフォルトの名無しさん:2010/07/08(木) 21:20:27
時が未来へ進むと誰が決めたんだ

440 :デフォルトの名無しさん:2010/07/08(木) 21:54:10
時代が

441 :デフォルトの名無しさん:2010/07/08(木) 23:08:14
多分次ぎはc++0y


442 :デフォルトの名無しさん:2010/07/08(木) 23:19:49
>>436 F でけりがつくんかい?
ハゲの論調だと 9 で終わりそうもないので 0...F みたいな感じだったが ...


443 :デフォルトの名無しさん:2010/07/09(金) 02:30:57
バージョンの数字か何かが続くってことなのかな?
数字の範囲を超えそうなら36進数にでもして
桁を増やしていけばいいのに、なんで0xなんてわざわざつけたんだろう

444 :デフォルトの名無しさん:2010/07/09(金) 18:19:31
今となっては信じ難いことだが
本当は2007年に完成する予定だったんだ

445 :デフォルトの名無しさん:2010/07/09(金) 19:46:32
C++98だって、延びに延びていたがな。

446 :デフォルトの名無しさん:2010/07/09(金) 21:22:26
xが何になろうと、右辺値参照とLambdaとautoが既に実装されてるから気にしない。一休み一休み

447 :デフォルトの名無しさん:2010/07/09(金) 21:24:15
うんこドドンパ

448 :デフォルトの名無しさん:2010/07/09(金) 21:44:33
>>447ですが、誤爆しました。すみません。

449 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 06:26:44
わざとですね分かります

450 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 16:56:52
イニリスの長さをコンパイル時に知りたいんだけどconstexprが実装されるのを待つしかないのか

451 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 17:00:45
コンパイル時に分かるわけねーだろ。

452 :名無しさん@そうだ選挙に行こう:2010/07/11(日) 08:38:27
アトリビュートの構文に違和感を覚えたのは俺だけでいい

453 :名無しさん@そうだ選挙に行こう:2010/07/11(日) 09:47:28
どんな構文でもマクロよりはましだと悟った

キレイなC++なんてC++じゃないんだ!

454 :デフォルトの名無しさん:2010/07/13(火) 17:13:47
パーサーが解析でないような構文を違和感のある構文っていうんだよ。

455 :デフォルトの名無しさん:2010/07/13(火) 21:29:44
元々汚かったC++の文法規則がattribute-specifierだらけになってますます小汚くなった

456 :デフォルトの名無しさん:2010/07/14(水) 12:34:04
C++0xの解説の本ありませんか?

457 :デフォルトの名無しさん:2010/07/14(水) 12:40:12
http://www.artima.com/shop/overview_of_the_new_cpp

458 :デフォルトの名無しさん:2010/07/14(水) 17:01:40
本屋からC++関連の本が綺麗に消えたな
C++0xに向けて調整中か?

459 :デフォルトの名無しさん:2010/07/14(水) 20:14:47
>>458
本屋がそんなこと把握してるのか・・・

460 :デフォルトの名無しさん:2010/07/14(水) 20:38:03
本屋にはウェブ書籍のコーナーにAjax本、Java本コーナーにJavaScript本があるって印象しかないなあ

461 :デフォルトの名無しさん:2010/07/15(木) 07:29:30
C++自体が消えたって可能性は考えないのか

462 :デフォルトの名無しさん:2010/07/15(木) 09:47:51
もういいかげん拡張はあきらめて新しい言語作ればいいのに

463 :デフォルトの名無しさん:2010/07/15(木) 21:05:28
そして生まれた言語の数々。

464 :デフォルトの名無しさん:2010/07/15(木) 23:26:27
いっぱいあんだろ。
そのうちJAVAでOS作るのが当たり前の時代とかもきちゃったりするぞ。

465 :デフォルトの名無しさん:2010/07/15(木) 23:30:37
D最終形態にはあらゆる言語がひれ伏すぞ。

466 :デフォルトの名無しさん:2010/07/15(木) 23:40:29
アルティメットD・・・
仮面ライダーにいたよ、そんな敵

467 :デフォルトの名無しさん:2010/07/15(木) 23:52:10
>>464
と、言われて10年たちましたね。

468 :デフォルトの名無しさん:2010/07/16(金) 00:42:26
eclipseでOS作ればJAVA使ったことになるのさ

469 :デフォルトの名無しさん:2010/07/16(金) 18:06:32
JavaでOSってどうやって書くの?
ブートローダで真っ先にJVM呼ぶの?
ハードウェアアクセスを全部JVM様にお願いして仲介してもらうの?
カーネルのメモリまで全部GCに支配されてんの?

オエッ

470 :デフォルトの名無しさん:2010/07/16(金) 18:16:20
Javaのバイトコードをネイティブにデコードするプロセッサなんだろう。きっと。

471 :デフォルトの名無しさん:2010/07/16(金) 18:59:50
>>469
こういう商業版はしってたが
http://en.wikipedia.org/wiki/JavaOS
http://en.wikipedia.org/wiki/SavaJe

オープンソースもいくつかあるね
http://en.wikipedia.org/wiki/JNode
http://en.wikipedia.org/wiki/JX_(operating_system)

472 :デフォルトの名無しさん:2010/07/16(金) 19:14:20
ちょっと待ってほしい
もし仮にPCに電源投入すると
Javaインタープリターが起ち上るとするならば、
これもまたJavaOSと名乗ることを許されるのではないだろうか

473 :デフォルトの名無しさん:2010/07/16(金) 19:28:29
そのインタプリタはCで書かれてるんですね
わかります

474 :デフォルトの名無しさん:2010/07/16(金) 20:06:12
JavaをJavaで書けるようになってからだね。

475 :デフォルトの名無しさん:2010/07/16(金) 22:41:08
Visual C++はVisual C++で作成されています。

ってVC++6.0のスプラッシュに書いてあった

476 :デフォルトの名無しさん:2010/07/16(金) 23:08:41
>>469
SingularityっていうC#(の拡張言語)で書かれた似たようなOSの場合は
WindowsでいうHALはC++で書かれていてそれ以外の部分がC#になってた

>>470
なんか10年前に話だけは聞いたことあるけどどうなったんだろうなアレ

477 :デフォルトの名無しさん:2010/07/16(金) 23:35:40
富士通とか携帯用プロセッサに乗っけてたな?

478 :デフォルトの名無しさん:2010/07/17(土) 01:41:41
>>476
今のTexas InstrumentのARMプロセッサは多くが"Java Acceleration"
という機能を謳っているけど何なんだろう?


479 :デフォルトの名無しさん:2010/07/17(土) 19:24:26


480 :478:2010/07/17(土) 20:14:33
気になってたのでちょっと調べた。 ちゃんとコアのARMアーキテクチャ
で定義されてるんだ。

Java Technology Knowledge Article
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/kiRFU6S7H96L83.html

機能としてはほとんどのバイトコードを直接実行するDBX (Direct Bytecode eXecution) と
AOTやJITのコンパイル機能を補佐するRCT(Run-time Compilation Target)の2つになる。

ARMってすごいなあ。

481 :デフォルトの名無しさん:2010/07/17(土) 20:22:57
D&E読んでるけどなんで既にconceptあるの

482 :デフォルトの名無しさん:2010/07/17(土) 20:45:05
何も最近新しく出来た概念ってわけじゃない。
当時からアイディアはあったんだよ。

ちなみに、今とまったく同じautoは、すでに1982年に、C with Classesの一部として、禿によって実装されていた。
残念ながら、Cとの互換性の問題で、消さなければならなかったっけれど。

483 :デフォルトの名無しさん:2010/07/17(土) 20:50:30
昔はCで組んでたけど、autoなんて使った記憶ないなあ。
消さなきゃ良かったのに。

484 :デフォルトの名無しさん:2010/07/17(土) 21:06:15
元のautoを有効利用したことがある奴いるの?

485 :デフォルトの名無しさん:2010/07/17(土) 21:14:35
>>484
auto
って何に使うの?


486 :デフォルトの名無しさん:2010/07/17(土) 21:38:31
registerでないことを明示したい時に使う

void foo(){
int x;
&x;
}

こんなxを勝手にレジスタに置いてポインタが取れないと癇癪を起こしてたのさ
昔々のコンパイラは

487 :485:2010/07/17(土) 21:41:08
元のauto、ね。
タイプ量を増やす以外の役割は??

488 :デフォルトの名無しさん:2010/07/17(土) 21:42:05
>>486
あ、ごめん、
> 昔々のコンパイラは
ね。
ってことは、途中で規格が改訂されて省略可能になったわけか。

ありがとうございます。


489 :デフォルトの名無しさん:2010/07/18(日) 11:33:32
昔のコンパイラはレジスタ配置すら人力だったのか……

490 :デフォルトの名無しさん:2010/07/18(日) 11:36:55
絶望した。

std::vector<int>& Get(){
    return vec;//クラス内で宣言済み
}
上のようなメソッドが有って、

auto vec = hoge.Get();

ってやったら、ムーブかコピーだった。参照で受け取れるとおもったんだが。
で、結局

auto& vec = hoge.Get()

ってやったら意図通りになった。@VC10

491 :デフォルトの名無しさん:2010/07/18(日) 12:02:20
>>490 の通りが普通だと思ってたんだけど、
規格上の動作はVC10と違うの?

492 :デフォルトの名無しさん:2010/07/18(日) 12:09:28
auto var = exp;はexpの評価されたTypeがvarの宣言/定義に使用される。
たとえhoge.Get()が参照を返したとしても、式中では参照のついたstd::vector<int>&ではなくstd::vector<int>として評価される。
これは0xに関係なく今の時点でもそう。
どうしてもと言いたければboost::refを使って式中の評価を参照修飾にする必要がある。

493 :デフォルトの名無しさん:2010/07/18(日) 12:14:12
decltype

494 :デフォルトの名無しさん:2010/07/18(日) 12:24:12
>>490
どこを困ってるかわからん

495 :デフォルトの名無しさん:2010/07/18(日) 12:25:56
decltype((hoge.Get())) vec = hoge.Get()

496 :デフォルトの名無しさん:2010/07/18(日) 12:27:31
#define BOOST_AUTO(E, F) decltype(E) F = E;

497 :490:2010/07/18(日) 12:31:26
返信ありがと〜。

>>491
いやー、俺の勘違いのようですよ。
戻り値の型を評価されるんだと思ってたので、&取られるのは気づきにくいなーと。

>>492
詳細ありがとう。理解が深まって助かるよ。
厳密にboostのようなものが必要だったわけじゃないからいいんだけど、
知らなかったら、コストかかるわ、バグの元になってるわで、自分的には不味かったんだ。

>>493
decltype先生はタイプ量増えるから難しいね。

498 :デフォルトの名無しさん:2010/07/18(日) 12:36:30
おっとっと。

>>494
最近はムーブされるから多少マシになったけど、その前はRVOか全コピーだからマズーって感じ??

>>495-496
decltype先生は用途がむずかしいね。

499 :デフォルトの名無しさん:2010/07/18(日) 12:56:32
decltype で書かなきゃいけないの? と思ってfcd読み返したら
auto& みたいな書き方でOKだったじゃないか。

>>495 みたいなのは、&で返ってくるときは&で、
値で返ってくるときは値で受け取りたいときに使うってことだね。

500 :490:2010/07/18(日) 14:00:35
>>499
なるほど。


皆さんありがとう。ノシ

501 :デフォルトの名無しさん:2010/07/18(日) 15:45:49
autoって互換性無くさなくてよくね?
今までだと
auto hoge h;
これからは
auto h = hoge();
だから別に構文は被ってないじゃん


502 :デフォルトの名無しさん:2010/07/18(日) 16:08:05
型を省略したらintとかそんなのなかったっけ?

503 :デフォルトの名無しさん:2010/07/18(日) 16:14:29
それはあまりにもフリーダム

504 :デフォルトの名無しさん:2010/07/18(日) 16:15:25
>>502
Cの戻り値がそんなんだったような気が

505 :デフォルトの名無しさん:2010/07/18(日) 16:17:11
まあ、いまだに残ってるんだよな。

unsigned x = 0 ;// unsigned int

506 :デフォルトの名無しさん:2010/07/18(日) 20:08:10
いや、unsigned x; は型名省略じゃない

507 :デフォルトの名無しさん:2010/07/18(日) 20:10:59
処理系の一番手ごろな型えらぶんだっけ??

508 :デフォルトの名無しさん:2010/07/18(日) 20:55:31
いや、unsigned/signed は unsigned int/signed int の別名だから。

509 :デフォルトの名無しさん:2010/07/18(日) 20:59:05
signedなんて予約語あったっけ?

510 :デフォルトの名無しさん:2010/07/18(日) 21:00:04
あるよ

511 :デフォルトの名無しさん:2010/07/18(日) 21:04:04
static x; みたいな例の方がわかりやすい。

512 :デフォルトの名無しさん:2010/07/18(日) 23:10:06
関数定義の戻り値省略とかも

513 :207:2010/07/19(月) 21:30:00
すみません
gccで現在コンパイルがC++0xとして行われているか判別する方法はないでしょうか
事前定義マクロのようなものはないでしょうか?


514 :デフォルトの名無しさん:2010/07/19(月) 21:31:19
auto a = test();とかやってみる

515 :デフォルトの名無しさん:2010/07/19(月) 21:43:07
>>514
すみません.言葉が足りませんでした.
コード中で0xに対応していればstd::threadを
対応してなければboost::threadを使う
といった使い方をしたいのです.

516 :デフォルトの名無しさん:2010/07/19(月) 21:47:26
#if __cplusplus > 199711L
でいいと思う

517 :デフォルトの名無しさん:2010/07/19(月) 21:52:10
ありがとうございます.
試してみます.

518 :デフォルトの名無しさん:2010/07/19(月) 21:58:47
__cplusplus
  In C++0x the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.
とのことで
#if __cplusplus != 199711L
少し不安ですがでいけました.ありがとうございました.


519 :デフォルトの名無しさん:2010/07/19(月) 22:02:50
>>518
!=は不適切じゃないか?

520 :デフォルトの名無しさん:2010/07/19(月) 22:24:08
#if __cplusplus < 199711L
// 0x
#else
// boost
#endif

まだ少し不安ですがこうしてみました.
バージョンが新しいほど値が小さくなるのでしょうか
gcc version 4.4.3 で試しています.

521 :デフォルトの名無しさん:2010/07/19(月) 22:26:01
>>520
制定日を示してる

522 :デフォルトの名無しさん:2010/07/19(月) 22:28:55
greater than

523 :デフォルトの名無しさん:2010/07/19(月) 22:32:22
>>521
なるほど

__cplusplusの値を見てみたのですが
 msvcでは199711Lでした
 gcc version 4.4.3では1でした

まだ制定されていないからでしょうか.
FAQにあるように,199711L以外としか決まってないのでしょうか
しょうが無いので1の場合は0xと見なして処理してみます.

524 :デフォルトの名無しさん:2010/07/19(月) 22:33:23
いやgccは昔からずっと1にしてるぞ

525 :デフォルトの名無しさん:2010/07/19(月) 22:36:39
なるほどそうだったのですか
とりあえずgccはコンパイラのバージョンを見て決めることにしてみます

526 :デフォルトの名無しさん:2010/07/19(月) 22:42:52
gcc の場合 __GXX_EXPERIMENTAL_CXX0X__

527 :デフォルトの名無しさん:2010/07/19(月) 22:46:42
_HAS_CPP0X とか、もうね(ry

528 :デフォルトの名無しさん:2010/07/21(水) 19:28:23
>>527じゃダメなの?

529 :デフォルトの名無しさん:2010/07/21(水) 22:41:59
_から始まるからだめ

530 :デフォルトの名無しさん:2010/07/22(木) 19:12:44
コンパイラが定義する分にはいいんじゃね?

531 :デフォルトの名無しさん:2010/07/22(木) 19:14:12
書いてて気持ち悪いからやだ

532 :デフォルトの名無しさん:2010/07/23(金) 06:58:11
VS2010にThreadがないんだけど、まだ入ってないん?

533 :デフォルトの名無しさん:2010/08/02(月) 15:24:30
あん…

534 :デフォルトの名無しさん:2010/08/02(月) 21:37:46
ぱん…

535 :デフォルトの名無しさん:2010/08/03(火) 00:21:21
まん・・・

536 :デフォルトの名無しさん:2010/08/03(火) 00:30:21
あたらしい質問です

C++0xでは例外指定が消えただの何だのと聞いたんですが、
try-catchが消えるってことですか?

537 :デフォルトの名無しさん:2010/08/03(火) 00:33:40
>>536
違う。

throw()のこと

538 :デフォルトの名無しさん:2010/08/03(火) 01:54:09
finallyは欲しいところ

539 :デフォルトの名無しさん:2010/08/03(火) 03:24:46
>>537
throwができなくなるor非推奨になるって認識で良いんでしょうか

540 :デフォルトの名無しさん:2010/08/03(火) 03:34:37
>>539
関数の定義の際に、
int hoge() throw(なんとか) { ... }
という書式があったんだよ。

541 :デフォルトの名無しさん:2010/08/03(火) 08:57:07
>>538
欲しいよね

542 :デフォルトの名無しさん:2010/08/03(火) 10:11:19
>>538
今から追加するならいっそのこと D のスコープガードにしてほしい。
http://www.kmonos.net/alang/d/2.0/exception-safe.html
http://www.kmonos.net/alang/d/2.0/statement.html#ScopeGuardStatement

543 :デフォルトの名無しさん:2010/08/03(火) 12:07:47
0xだとライブラリレベルのスコープガード実装で満足できる気がする

544 :デフォルトの名無しさん:2010/08/03(火) 13:57:44
0を返すテンプレート関数 zero() を作るとします。
template< typename result_type > result_type zero() { return result_type(0); }

そして、関数テンプレートの特殊化で、それぞれの型にあわせたzero()をt作るとします。
template< > int zero< int >() { return 0; } // 例1
template< > float zero< float >() { return 0.0f; } // 例2
template< > double zero< double >() { return 0.0; } // 例3

ある特殊な数を表す special_value< value_type > クラスがあり、
special_value< int > や special_value< char > など無数に定義されているとします。

この special_value< value_type > に対し、zero() を定義したいのですが、
現状だと special_value の具体的なクラスひとつひとつに特殊化を定義しなければならず、大変手間です。
template< > special_value< int > zero< special_value< int > >() { return 0; } // <-これが無数に必要

出来れば、特殊化は special_value< value_type > ひとつだけにして、
尚且つ、zero()の呼び出しも簡素な形にしたいのです。
special_value< int > i = zero(); // <-理想
special_value< int > i = zero< special_value< int > >(); // <-現実 少なくともこれ以上、呼び出し文を複雑にしたくない

関数テンプレートの特殊化は少なく、呼び出しは簡素な良い方法はないでしょうか?

545 :デフォルトの名無しさん:2010/08/03(火) 18:01:00
>544

struct {
template <typename T>
T operator()() const { return 0; }
} const zero = {};

546 :デフォルトの名無しさん:2010/08/03(火) 18:46:30
>>545
どうもコンパイルエラーがでる…

struct {
 template <typename T> operator T () const { return 0; }
} const zero = {};

として、

 special_value<int> i = zero;

だと、OK だった。

547 :デフォルトの名無しさん:2010/08/03(火) 18:52:24
>>545
>>546

結局、

 struct zero {
  template <typename T> operator T () const { return 0; }
 };

とすれば、

 special_value< int > i = zero();

で、いける。

548 :デフォルトの名無しさん:2010/08/03(火) 20:27:04
>>545-547
検証した結果、その方法で全てOKでした。
使わせてもらいます。ありがとうございました。

549 :デフォルトの名無しさん:2010/08/04(水) 12:43:14
>>542
これは素晴らしい。惚れた
C++にこの構文を入れるプリプロセッサとかないものか

550 :デフォルトの名無しさん:2010/08/04(水) 13:12:10
Boost.ScopeExit

551 :デフォルトの名無しさん:2010/08/04(水) 18:58:10
>実際ソースコード上で視覚的に大きく離れてしまします。

素晴らしい日本語だな

552 :デフォルトの名無しさん:2010/08/04(水) 19:02:28
boostだと表記が長ったらしくて嫌

553 :デフォルトの名無しさん:2010/08/04(水) 19:54:13
最近のboostはPP厨すぎて付いていけない

102 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)