C++0x 2 - 暇つぶし2ch

C++0x 2 at TECH

1:デフォルトの名無しさん
07/10/08 20:29:11
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)

前スレ
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
07/10/08 20:44:39
スレタイはC++1xだろ…常考

3:デフォルトの名無しさん
07/10/08 21:29:39
ん？　こっち使うの

4:デフォルトの名無しさん
07/10/08 21:33:37
よし、こっちを使おうぜ

5:デフォルトの名無しさん
07/10/08 21:52:06
>>1
乙

6:デフォルトの名無しさん
07/10/08 21:53:14
こっちでいくか。

7:デフォルトの名無しさん
07/10/08 21:54:53
転載だけど、こうなるらしい。　

---　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ヴァリヴァリな人にはとってもラクチンになる予感。　

8:デフォルトの名無しさん
07/10/08 22:05:18
前スレから
URLﾘﾝｸ(herbsutter.spaces.live.com)

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

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

9:デフォルトの名無しさん
07/10/08 22:15:41
vector<int> v = { 1, 2, 3 };

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

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

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

10:デフォルトの名無しさん
07/10/08 22:41:24
>>7みたいな宣言に対応するためにva_listみたいなの使ってコンストラクタ実装することになるの？
うえー

11:デフォルトの名無しさん
07/10/08 23:00:04
>10
va_list よりは大分ましだと思うが、std::initializer_list<T> を使うことになる。
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)

>9
std::map にも initializer_list を受けるコンストラクタができるようなので可能。また、n2215 の 5 章にほぼ同じ例がある。
URLﾘﾝｸ(www.open-std.org)

12:デフォルトの名無しさん
07/10/08 23:04:28
>>10
コンストラクタの引数に std::initializer_list<T> を指定するだけらしいよ。

13:デフォルトの名無しさん
07/10/08 23:16:03
ユーザー定義リテラルをつかって

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;

でいいのかな?

14:デフォルトの名無しさん
07/10/08 23:41:48
constexpr をつけたほうがいいのでは？

15:デフォルトの名無しさん
07/10/09 00:14:38
clampみたいな、クロージャは入るのかな。

16:デフォルトの名無しさん
07/10/09 00:28:29
最新のworking draftはこれかな。
URLﾘﾝｸ(www.open-std.org)

17:デフォルトの名無しさん
07/10/09 00:43:08
>13
コーディング規約とかで真っ先に使用禁止になりそうな機能だ（ｗ

18:デフォルトの名無しさん
07/10/09 01:05:02
>>17
まあ適切につかえば便利。>>15 と初期化リストとあわせて

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

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

19:デフォルトの名無しさん
07/10/09 01:06:12
>>18
> >>15 と初期化リストとあわせて
　↑>>15 じゃなくて >>13 でした。

20:デフォルトの名無しさん
07/10/09 01:30:47
>>18
×duble
○double

21:デフォルトの名無しさん
07/10/09 01:35:53
using　duble　=　double;

22:デフォルトの名無しさん
07/10/09 01:51:47
#define duble double

23:デフォルトの名無しさん
07/10/09 01:52:32
typedef double duble;

24:デフォルトの名無しさん
07/10/09 02:29:02
>>21-23
それはコーディング規約で禁止になるなｗｗｗ

25:デフォルトの名無しさん
07/10/09 02:30:35
そんなんバレなきゃ大丈夫

26:デフォルトの名無しさん
07/10/09 09:40:10
#define private public

27:デフォルトの名無しさん
07/10/09 12:47:17
#define class struct

28:デフォルトの名無しさん
07/10/09 15:46:48
C++はVisual C++のバグとの戦いの歴史
Boostは今も戦いの最中

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

29:デフォルトの名無しさん
07/10/09 16:36:27
VC++が0xに対応するのなんて15年後くらいだろ。

30:デフォルトの名無しさん
07/10/09 16:42:21
>>29
VC7.1になるあたりの頃にHerb SutterがMSに入って直しまくったわけだが
まだ彼がMSにいるならすぐ追いつくんじゃないのかなあ

31:デフォルトの名無しさん
07/10/09 16:43:08
もうC++はC++/CLRしかサポートしないんじゃないか？

32:デフォルトの名無しさん
07/10/09 16:44:10
×　C++/CLR
○　C++/CLI

33:デフォルトの名無しさん
07/10/09 16:48:49
そこで
C++0x/CLI
の登場ですよ！

34:デフォルトの名無しさん
07/10/09 17:01:14
>>29
にわかだな
MSは速攻対応するに決まってるだろ

ただしバグだらけ

35:デフォルトの名無しさん
07/10/09 17:02:05
乳首ポチポチおｘんこスリットクリトリス！？

36:デフォルトの名無しさん
07/10/09 17:03:10
取り敢えずサンプルコードの3割がコンパイル通って、そのうち4割が正常に動くコンパイラ。

37:デフォルトの名無しさん
07/10/09 20:08:28
boostに#ifdefの嵐が

38:デフォルトの名無しさん
07/10/10 12:35:20
また対応に数年かけるのは目に見えてるぜ・・・

39:デフォルトの名無しさん
07/10/10 18:23:55
そうこうしてるうちにC++1xがでるな。

40:デフォルトの名無しさん
07/10/11 05:59:41
Visual C++ は boost のレグレッションテストでは
かなりいい成績出してるようだが。
ただし Boost 側の対処が頑張っているからではあるのだが。
それ言ったら Boost のコード読むと Borland C++ 向けの
#ifdef のほうが多い気もする。

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

41:デフォルトの名無しさん
07/10/11 06:27:54
auto,decltype,pp,operatorを駆使すると
もっと難解なコード書けるけどな。

42:デフォルトの名無しさん
07/10/11 08:24:12
ところでTRはいくつまで出るんだ？
3ぐらい？

43:デフォルトの名無しさん
07/10/11 10:49:04
boost名前空間に配置されているライブラリーを多用しているんだけど
tr1 とかの名前空間に配置変えされていくの？
最終的には std の下に入るの？

44:デフォルトの名無しさん
07/10/11 17:50:13
TR?は一般人は無関係。

45:デフォルトの名無しさん
07/10/11 18:43:03
スマートポインタの利用が一般的になれば、
それだけで劇的に違うと思うんだがなあ

46:デフォルトの名無しさん
07/10/11 19:36:01
>>43
working draftではもうstdに入ってる>>16

47:デフォルトの名無しさん
07/10/11 19:39:26
せっかく名前空間があるのに
名前の重複を避けるためにunorderd_map
とか妙な名前になってるらしいですが、

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

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

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

48:デフォルトの名無しさん
07/10/11 21:24:46
名前空間の階層化宣言て入ってるんだっけ？

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

みたいな奴

49:デフォルトの名無しさん
07/10/11 21:56:02
>>45
もしGC入ったら趣味プロレベルはそっちに流れそうな気もする

50:デフォルトの名無しさん
07/10/11 22:04:29
>>47
SGI -STLはかなり初期から入ってた。
というか、今じゃほにゃららext系の名前空間にむしろ入ってないケースの方が多いくらいだが、
こいつらも一時期は std 内に生息していた。

51:デフォルトの名無しさん
07/10/12 01:27:50
>>47
C++はパッケージがないしなあ。

52:デフォルトの名無しさん
07/10/12 06:44:24
>>48
それ、便利だよなぁ。あったら。

53:デフォルトの名無しさん
07/10/12 07:06:19
>48
提案はあったようだけど
URLﾘﾝｸ(www.open-std.org)
Not ready for C++0x になってる。
URLﾘﾝｸ(www.open-std.org)

54:デフォルトの名無しさん
07/10/12 17:15:28
ドラフトに入ってる機能が削除される可能性ってあるのかな？

55:デフォルトの名無しさん
07/10/12 17:39:48
修正不能な大きな穴が見つからない限りない、
つまりない。

56:デフォルトの名無しさん
07/10/12 18:29:10
㌧

57:デフォルトの名無しさん
07/10/12 19:58:56
ただ節目節目で投票に掛けるようだから、
最終投票まで油断は禁物。

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

59:デフォルトの名無しさん
07/10/12 23:57:31
>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)

60:デフォルトの名無しさん
07/10/13 00:04:35
[]演算子にしたらbidirectional　iterator/rangeとか困る。

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

でもnullptr不要には同意。

61:デフォルトの名無しさん
07/10/13 00:18:01
可変単位整数ならテンプレート合わせで vint<8> のようなほうがいいな。

62:デフォルトの名無しさん
07/10/13 00:18:02
intXX_t系をしっかり実装してあればいい。(x=>数字）

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

64:デフォルトの名無しさん
07/10/13 02:14:03
　こ　こ　ま　で　の　レ　ス　は　、　す　べ　て　『　気　の　せ　い　』　で　す　。

65:デフォルトの名無しさん
07/10/13 02:51:43
そんなことじゃないかと思ってたよ

66:デフォルトの名無しさん
07/10/13 04:42:02
MSと何の関係があるのかと…

67:デフォルトの名無しさん
07/10/13 09:17:37
nullptrに特殊化させたい。

68:デフォルトの名無しさん
07/10/13 09:28:11
>>67
それは nullptr がテンプレートとして実装されていればいいのにってこと？

69:デフォルトの名無しさん
07/10/13 12:09:20
本来のポインタと変換しやすいスマートポインタを書いたり、
ポインタを保持できるコンテナやアルゴリズムを書いたりするとき
ヌルポインタに対するテンプレート特殊化が書きやすい、
ってことだべ。

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

70:デフォルトの名無しさん
07/10/13 12:11:25
>>64
WindowsがLLP64モデルを採用してるからじゃない？

71:70
07/10/13 12:38:51
アンカーミス
>>64 → >>66

72:デフォルトの名無しさん
07/10/13 12:44:48
URLﾘﾝｸ(herbsutter.spaces.live.com)

73:デフォルトの名無しさん
07/10/13 16:29:41
さったーさんはCLIの世界へ逝かれました。

74:デフォルトの名無しさん
07/10/13 16:56:24
というか、Lippmanにしても、
なんであそこまでC++/CLIに入れ込むのかわからん。
MSとの契約に書いてあるのかな?

75:デフォルトの名無しさん
07/10/13 17:05:59
でもさ、C++/CLI って Java 厨がうざいこと言ってきたときには便利じゃね？

76:デフォルトの名無しさん
07/10/13 17:18:33
実はいずれ標準にGCが入った時の事を考えてるに違いない

77:デフォルトの名無しさん
07/10/13 18:32:59
いや、マネージドという視点を入れると、おもしろいよ C++/CLI
リソース混合状態を考えると、何かがいることは確か

78:デフォルトの名無しさん
07/10/13 21:29:45
#define nullpo nullptr

79:デフォルトの名無しさん
07/10/13 21:32:11
>>78
誰かやると思った

#if defined nullpo
#define ga nullpo

80:デフォルトの名無しさん
07/10/13 21:37:10
null
はダメなのか・・・
やっぱり誰かが使ってそうだから？

81:デフォルトの名無しさん
07/10/13 21:46:52
>>79
それだと全てのgaがnullpoに置換されないか？

82:デフォルトの名無しさん
07/10/13 21:51:51
#endif

83:デフォルトの名無しさん
07/10/13 23:22:06
g++だと__nullというのがつたえたりするね。いまでも。

84:デフォルトの名無しさん
07/10/13 23:25:20
やんぬるかな

85:デフォルトの名無しさん
07/10/13 23:28:42
病ん（でる）null？

86:デフォルトの名無しさん
07/10/14 02:59:02
VC++ でも __null じゃなかったっけ？

87:デフォルトの名無しさん
07/10/14 03:55:27
nullptr が導入されても
T* p = ...;
if (!p) あぼん
は生きてるよね？

88:デフォルトの名無しさん
07/10/14 03:56:30
マルチメソッドはどうなったんだろう。
あれが入ったらダブルディスパッチが不要になるな。

89:デフォルトの名無しさん
07/10/14 04:08:52
>>88
それなに？
C#の event みたいなやつ？
デリゲート使ってるやつ。

90:デフォルトの名無しさん
07/10/14 05:31:31
はわわわわ

91:デフォルトの名無しさん
07/10/14 08:59:17
>>86
/clr付ければnullptrが使える。

92:デフォルトの名無しさん
07/10/14 09:00:16
>>87
どうせ
#define nullptr 0
ってなるだけだろ。

93:デフォルトの名無しさん
07/10/14 09:37:57
>92
それだと提案されてる内容を満たさない。
URLﾘﾝｸ(www.open-std.org)
nullptr の型は nullptr_t であり整数値として扱うことができない。

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

94:デフォルトの名無しさん
07/10/16 21:52:03
C
C++ (c plus plus)
C# (c charp)
C* (c anal)
C@ (c gurochikuvi)

95:デフォルトの名無しさん
07/10/16 22:06:33
C(i) （c omeko）

96:デフォルトの名無しさん
07/10/17 00:05:20
Cω (c sorewa watashi no oinarisan da)

97:デフォルトの名無しさん
07/10/17 01:09:25
いや、わかって書いているとは思うんだが、一応。

Cωって存在するぜ？
Wikipedia項目ﾘﾝｸ

98:デフォルトの名無しさん
07/10/17 01:16:47
まあ、>>97さんて野暮なお方

99:デフォルトの名無しさん
07/10/17 03:21:29
外人って　ω　とか見てもへっちゃらなのかね。変なものを想像したりしないのか？ｗ

100:デフォルトの名無しさん
07/10/17 03:36:30
2ch見すぎ

101:デフォルトの名無しさん
07/10/17 08:04:36
日時関連のクラスの導入とか無いのかね。
あっても良さそうなもんだと思うんだけど。

102:デフォルトの名無しさん
07/10/17 08:36:11
スレ違いかも知れないが、
boostにある日付を扱うライブラリはだめ？

103:デフォルトの名無しさん
07/10/17 09:45:29
いや、それが何で C++0x に追加されないのかな、と。

104:デフォルトの名無しさん
07/10/17 10:46:04
変に入れるとローカライズがらみでJavaみたいにぐたぐたになるからじゃね？

105:デフォルトの名無しさん
07/10/17 11:10:13
std::time_get じゃ不足?

106:デフォルトの名無しさん
07/10/17 11:37:03
あ、こんなのがあったんだ・・・。
別の場所読んでた。

107:デフォルトの名無しさん
07/10/17 13:06:28
な、なんだって～！
このスレに来るの少し早いんと違うんかと
無いのかね、言いたいだけと違うんかと

108:デフォルトの名無しさん
07/10/18 17:35:17
>>107
日本語でおｋ

109:デフォルトの名無しさん
07/10/19 12:14:52
このスレ的には
C言語でおｋ

110:デフォルトの名無しさん
07/10/19 12:48:57
関数パラメータのケツのカンマ無視してくんねーかな。
enumや配列の初期化では無視してくれるだろ。

111:デフォルトの名無しさん
07/10/19 14:12:07
そうーいう仕様にすると、
void foo(int x)とvoid foo(int x, int y = 1)を定義しておいて、
foo(2)で前者を、foo(2,)で後者を呼べるようにしろ、
とゆー輩が現れそう。

112:デフォルトの名無しさん
07/10/19 14:15:54
自分のこと?

113:デフォルトの名無しさん
07/10/19 17:17:15
いやお前のこと、と言いたいけど、お前は思いつきすらしなかったっぽいな。

114:デフォルトの名無しさん
07/10/19 18:01:36
それもいいけど、判定をコンマ区切りで同時処理したい

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

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

115:デフォルトの名無しさん
07/10/19 19:11:25
>>114
変数でなく定数のnに関してまとめるというのに違和感が…

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

116:デフォルトの名無しさん
07/10/19 23:42:39
>114
Perl モジュールだけど、
URLﾘﾝｸ(search.cpan.org)
と同じような記法で良ければ今でもライブラリとして実現できそうな予感。

117:デフォルトの名無しさん
07/10/20 00:35:20
>116
なるほど、any とか all とかで範囲を確定するライブラリを作るわけですね

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

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

118:デフォルトの名無しさん
07/10/20 10:03:14
>>116
これならいいね。
>>114はアレだけど、operator,で>>116を定義できちゃうかな?

119:デフォルトの名無しさん
07/10/20 10:42:50
レベル低いのが混じってるなぁ

120:デフォルトの名無しさん
07/10/20 11:52:29
正直、ライブラリレベルで勝手にやってくれって感じだな

121:デフォルトの名無しさん
07/10/20 12:10:38
C++の悪いところはコーディングの時点でのライブラリなのか副作用のあるライブラリなのかが分かりにくいという事だ

122:デフォルトの名無しさん
07/10/20 12:40:26
>>121
日本語でok

123:デフォルトの名無しさん
07/10/20 12:44:54
お前の理解力が無さ過ぎるだけ

124:デフォルトの名無しさん
07/10/20 12:47:08
俺もわかんね
具体例でおしえてください

125:デフォルトの名無しさん
07/10/20 12:54:28
どんなライブラリだってコーディングのときに使うんだよね？
あと、関数型言語じゃないんだから、副作用のないライブラリなんてほとんど全然ないとおもうんだけども？？？

126:デフォルトの名無しさん
07/10/20 12:56:45
俺もわからん

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

128:デフォルトの名無しさん
07/10/20 13:34:59
あぁやっとわかった
記述を簡単にするためのシンタクスシュガー的なライブラリと
それ以外の事か

前者はboost::noncopyableとかかな

129:デフォルトの名無しさん
07/10/20 13:35:06
むしろコーディング時にライブラリがいるっていうのが問題だろ

130:デフォルトの名無しさん
07/10/20 13:37:03
それはコーダーの問題か。

131:デフォルトの名無しさん
07/10/20 13:42:54
ライブラリの部分で言語を変造できるほど強力なのがC++の利点だと思う。
そういうのがキレイに分かれててほしいときはJavaとかC#を使えばいい。
俺は使い分けてるよ。

132:デフォルトの名無しさん
07/10/20 13:56:27
エスパーってほんと尊敬するよ。

133:デフォルトの名無しさん
07/10/20 14:51:30
URLﾘﾝｸ(www.open-std.org)
News 2007-10-19: C++ Standard Core Language Issues List (Revision 51) is available

134:デフォルトの名無しさん
07/10/20 18:30:41
コーディングのときにはヘッダファイルしかいらないだろ！

135:デフォルトの名無しさん
07/10/20 19:07:03
ワーオ

136:デフォルトの名無しさん
07/10/20 19:38:39
つまりコンパイラとリンカに問題があるんだな

137:デフォルトの名無しさん
07/10/20 20:25:15
ロリコンパイパイとダイナミックリンクしたい

138:デフォルトの名無しさん
07/10/20 20:29:40
　　　　　　　　＿＿＿_
　　　　　　　／　　　　＼　　　　「ロリコン」に興味があるの？
　　　　　／　　─　　 ─＼　　　変態っつーかキ○ガイじゃね？
　　　　／　　（●）　（●）＼　　こっち見んなよ
　　　　|　　　　（__人__）　　 |
　　　＼　　　　｀ ⌒´　　／

139:デフォルトの名無しさん
07/10/21 00:44:34
(゜д゜)(゜д゜)(゜д゜)

140:デフォルトの名無しさん
07/10/21 08:09:56
ロリに興味はあっても、ロリコンに興味は抱かないよな。
気持ち悪い

141:デフォルトの名無しさん
07/10/21 08:50:04
最近はロリコンというと男の方を指すのか
時代は変われば変わるもんだなぁ

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

142:デフォルトの名無しさん
07/10/21 12:16:27
ロリコンはロリータコンプレックスの略で、それ自体を訳せば少女嗜好となり、時代に関係なく少女そのものを指す語ではない。

143:デフォルトの名無しさん
07/10/21 12:34:06
提喩つってだな、対象のある属性の名前が対象そのものを表すようになるのはよくあること。

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

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

144:デフォルトの名無しさん
07/10/21 16:12:47
そりゃシネクドキだろ・・・って突っ込んで欲しかったのか？ｗ

145:デフォルトの名無しさん
07/10/21 17:08:26
>>143

>sizeofを使った特殊化
kwsk

146:デフォルトの名無しさん
07/10/21 20:24:43
＞提喩つってだな、対象のある属性の名前が対象そのものを表すようになるのはよくあること。

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

147:デフォルトの名無しさん
07/10/21 20:29:43
「ロリコン」が幼女・少女のほうを指していたことはただの一度も無いから、
これは単に「正しく認識しているかどうか」の問題。

148:デフォルトの名無しさん
07/10/21 21:20:39
これは何ともハイレベルなC++のスレですね＾＾

149:デフォルトの名無しさん
07/10/21 21:28:11
>143
URLﾘﾝｸ(www.open-std.org)
特殊化とはちょっと違う文脈な気もするけどこれですか。

150:デフォルトの名無しさん
07/10/21 23:00:47
ロリコンの女ｗｗ

151:デフォルトの名無しさん
07/10/21 23:29:37
ロリがロリコンを指している場合もあったりしてワケワカメ

152:デフォルトの名無しさん
07/10/22 01:19:30
Wikipediaをwikiって言うの以上に無理がある気が…

153:デフォルトの名無しさん
07/10/22 01:49:31
清岡以前の世代はC++0xに興味を持っていないようだよ・・・寂しいね・・・

154:デフォルトの名無しさん
07/10/22 01:50:40
>>153
誰だよ？w

155:デフォルトの名無しさん
07/10/22 23:35:35
俺俺、俺だって

156:デフォルトの名無しさん
07/10/22 23:53:16
おまえかあ

157:デフォルトの名無しさん
07/10/23 00:11:43
>>154
平清盛の大叔父の平清岡だよ。
ちなみに弟は平盛岡。

158:デフォルトの名無しさん
07/10/23 10:36:59
>C++ では、継承によってメソッドが暗黙的に "隠ぺい" されます。
>C# では、new 修飾子を使用して、継承メンバを明示的に隠ぺい
>する必要があります。

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

159:デフォルトの名無しさん
07/10/23 10:38:33
賛成

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

161:デフォルトの名無しさん
07/10/23 12:59:28
>>160
今時のコンパイラなら適切に警告が出るはずだが。

162:デフォルトの名無しさん
07/10/23 14:29:32
>>161
まじっすか～？
Visual C++ 2005 で警告をレベル4にしても出なかった希ガス

163:デフォルトの名無しさん
07/10/23 14:57:09
ゴメン。今見たら、手元のコンパイラはディフォルトでは全滅だった。
見た記憶はあるからgccのオプションであると思うんだけどなぁ。

164:デフォルトの名無しさん
07/10/23 15:34:17
>>163
-Wshadow かな?

165:デフォルトの名無しさん
07/10/23 15:39:11
そういう明示的な隠蔽とか
まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う
コンパイラのオプションにあるのは別にいいけど

166:デフォルトの名無しさん
07/10/23 15:58:32
なぜ？

167:デフォルトの名無しさん
07/10/23 16:15:38
$ 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'

168:デフォルトの名無しさん
07/10/23 16:16:12
>まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う

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

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

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

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

169:デフォルトの名無しさん
07/10/23 16:53:40
１と３は矛盾
４は丸っきり逆

170:デフォルトの名無しさん
07/10/23 16:55:24
なぜ？

171:デフォルトの名無しさん
07/10/23 19:08:56
>>165
まずい設計のしりぬぐいってわけでもないと思うんだよ。

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

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

172:デフォルトの名無しさん
07/10/23 19:14:01
URLﾘﾝｸ(www.blender.org)
によると、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

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

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

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

174:デフォルトの名無しさん
07/10/23 20:27:42
いや、わかるけど
逆に継承させた人が隠蔽してることを明示したいって事もあるんじゃない

175:デフォルトの名無しさん
07/10/23 21:25:50
>>165

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

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

176:165
07/10/23 21:34:33
熟考はせずにいうけど
継承時には 1
そのほかでは 2
が良さそうい思う

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

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

177:デフォルトの名無しさん
07/10/23 21:53:21
そうは思わない人がC#を作りましたと

178:デフォルトの名無しさん
07/10/24 00:54:02
>>173
巨大なクラスがどうこう、って話だったっけ？

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

179:デフォルトの名無しさん
07/10/24 03:16:53
>>175
俺は２
理由はC系の言語ってそういうもんだと思っているから。
けど隠蔽を警告しない糞コンパイラは使う気しない。

180:デフォルトの名無しさん
07/10/24 11:20:58
過去のコードを捨て去るなら別の言語を作ってそっちでやってください、というのが現状の委員会でしょ

181:デフォルトの名無しさん
07/10/25 00:16:13
C++ って久々に使うと結構楽しいね。

182:デフォルトの名無しさん
07/10/25 03:55:26
>>172
Visual C++ 2005 で同等の強さの警告出させたいものだ。

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

183:デフォルトの名無しさん
07/10/25 07:57:24
boostのvaultのやつまで使用おkなら楽しいよ

184:デフォルトの名無しさん
07/10/25 08:01:26
C++0xが来ればもっと楽しくなるだろうな。

185:デフォルトの名無しさん
07/10/25 09:10:11
ConceptGCC楽し
はやくこいこいC++0x

186:デフォルトの名無しさん
07/10/25 10:06:50
楽しいと言うかコーディングが楽になりそうでいいね。

187:デフォルトの名無しさん
07/10/25 11:06:48
特に auto が。

188:デフォルトの名無しさん
07/10/25 13:29:38
auto ってなんでも推論できるんかね？
なんか馬鹿の一つ覚えみたいに auto が氾濫しそう。
そんあこたーない？

189:デフォルトの名無しさん
07/10/25 13:41:15
>>188
タイピング量を減らしたいからって理由で使ってたら可読性がﾜｯｼﾜｯｼ下がったのが俺
今じゃまったく使ってない

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

190:デフォルトの名無しさん
07/10/25 13:57:34
でも適切な使用法もあるはずだよ
そうでなければBoostからとっくにrejectされてるはず

191:デフォルトの名無しさん
07/10/25 22:08:42
イテレータを使うときにちょっと楽じゃね

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

192:デフォルトの名無しさん
07/10/25 22:17:37
ML系の関数型言語では推論をするのに十分な型しか明示しなくても問題ないよ
可読性の低下は感じない
ML系は暗黙の変換がないけどね
そこさえ避ければ大丈夫そう

193:デフォルトの名無しさん
07/10/25 22:28:36
オーバーロードされてる関数のポインタを取得しようとして
void func(int);
void func(void*);
auto ptr = func;
エラーだなこりゃ。

194:デフォルトの名無しさん
07/10/25 22:32:59
>>193
そうそう。どこまで「自動」なのか知りたいね。
そして、C++0x的におｋな限界まで auto を乱用されると、きっと萎えるよな。

195:デフォルトの名無しさん
07/10/25 22:36:32
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要らずだな

196:デフォルトの名無しさん
07/10/25 22:36:44
そのときはまたboostが以下略

197:デフォルトの名無しさん
07/10/25 22:48:06
>>195
それは型のパラメタ化であって推論ではない
やっぱりtemplateの出番

198:デフォルトの名無しさん
07/10/26 00:09:59
>>193
オーバーロードされた関数は名前だけで型を決められないので
auto だけじゃなく bind でも使いにくいしなあ。

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

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

199:デフォルトの名無しさん
07/10/26 00:51:25
>>198
標準関数の引数並びは規定されてるだろ。
それ、どっから出てきた話？

200:デフォルトの名無しさん
07/10/26 01:05:36
>>199はどっかを読み違えているのだろう
でも、どう読み違えて、そう解釈したのかが解らないから
うまくアドバイスしてやることも出来ない

201:198
07/10/26 01:35:31
>>199
引数並びではなくシグネチャの話。
正確には関数じゃなくて「メンバ関数」限定だった。ごめん。

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

202:199
07/10/26 01:44:20
>>201
シグネチャの意味で「引数並び」って言った。でもやっぱり決まってるでしょ。

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

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

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

204:199
07/10/26 12:13:51
>>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 だから救われないけど。

205:デフォルトの名無しさん
07/10/26 15:28:41
>>203の言ってる意味がよくわからん
誰かコードに落としてくれ

206:デフォルトの名無しさん
07/10/26 16:23:30
>>205
Exceptional C++ Styleにそのまま例が載ってるじゃん

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

207:デフォルトの名無しさん
07/10/26 21:48:45
極端は話、
push_back(T val,bool hoge=true,int hage = 5,float foo = 0.05f)
なんて実装でもいいわけか

208:デフォルトの名無しさん
07/10/26 22:42:06
push_back(T val,bool uramode=true)

209:デフォルトの名無しさん
07/10/26 22:45:16
デフォルトパラメータを利用して独自拡張ができるってことか

210:デフォルトの名無しさん
07/10/27 00:35:22
このあたりの標準の改定案は出てないんかな？
実装に自由裁量権を認めたはいいけど、自由度あり過ぎて
std::mem_fun の位置付けが中途半端になってしまったのは
仕様の不備という気もするし

211:デフォルトの名無しさん
07/10/27 00:47:04
>>210
コーディング標準として、
>>204に相当するようなコードは書かないようにするしかないかと。

212:デフォルトの名無しさん
07/10/27 01:07:04
>>211
現状の話じゃなくて、C++0x にも同じ制限を持ち越すのか？
ってことが知りたいわけで

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

213:デフォルトの名無しさん
07/10/27 01:09:12
>Exceptional C++0x Style でまた書かれるぞ
また落とし穴が増えるのかよ
　　　　　　　　　∧＿∧
　　　　　　　　　（ ´Д⊂ヽ

214:デフォルトの名無しさん
07/10/27 01:12:22
>>212
とりあえず>>180は前提ですよ。馬鹿じゃない限り。

215:デフォルトの名無しさん
07/10/27 01:26:38
boost::function<void (std::vector<int>*)> vector_clear = &std::vector<int>::clear;

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

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

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

217:デフォルトの名無しさん
07/10/27 10:07:03
>>216
> 実装への自由度を制限することで
> 依然としてコンパイルできるし

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

218:デフォルトの名無しさん
07/10/27 10:39:08
STL実装に依存した関数ポインタを使ってないかぎり大丈夫だろ

219:デフォルトの名無しさん
07/10/27 13:46:39
「オーバーロードセットが存在するメンバ関数だけにういて適用される」
みたいな制限だけでもだいぶ違うね。
そうなれば vector push_back, clear は問題なくなる。

220:デフォルトの名無しさん
07/10/27 13:50:12
>>219
そんな中途半端な仕様いやだよ。 push_back() はいけるのに insert() はだめとか。
仕様かえるなら半端にする必要ないでしょ。

221:デフォルトの名無しさん
07/10/27 13:58:08
C++1xスレでも立てるか？

222:デフォルトの名無しさん
07/10/27 14:20:42
>>220
じゃあどういう修正なら納得するかｋｗｓｋ

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

223:デフォルトの名無しさん
07/10/27 16:13:50
>>222
>219 のやつだと、オーバーロードされてるやつは static_cast でシグネチャを
明示しても移植性を確保できない。

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

224:デフォルトの名無しさん
07/10/27 16:57:44
>>223
そりゃ204全削除できれば一番いいけどね。

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

225:デフォルトの名無しさん
07/10/27 18:14:05
>>224
なんで「デフォルト引数使えない」なんて話になるの？

226:デフォルトの名無しさん
07/10/27 19:38:09
流れぶった切りですまんけど >116 で紹介した Quantum::Superpositions の(簡易) C++ 版を作ってみた。
URLﾘﾝｸ(yak.myhome.cx)
superposition と非 superposition 間の関係演算子だけ実装。
スレ違いかもしれないけど、発端はここだし Variadic templates 版実装も作ったってことでここは一つ。

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

227:デフォルトの名無しさん
07/10/27 21:57:34
>>226
読んで感想を書こうと思ったけど自宅モードでは
boost/preprocessorが使われているコードを読む集中力が沸かない

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

228:デフォルトの名無しさん
07/10/28 00:21:59
>>225
すまん早とちりした
デフォルト引数の部分も含めて仕様にすればたしかに問題ないね

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

229:デフォルトの名無しさん
07/10/28 00:47:28
>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 とか使えばほんとに非決定計算っぽくできるかもしれない。

230:デフォルトの名無しさん
07/10/28 01:47:11
Expression Templateを使おうが、Boost Lambda使おうが、ショートカット評価は不可能だよ。

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

232:デフォルトの名無しさん
07/10/28 02:40:30
なんか落ち着かないと思ったら、普通はショート「サーキット」評価だ。

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

233:デフォルトの名無しさん
07/10/28 07:13:39
最近普通にshortcut evaluationって言うぞ。
Short circuitは古いだろ。マイキットじゃねーんだから。

234:デフォルトの名無しさん
07/10/28 08:12:40
0xにはDのlazyみたいなものないの？

235:デフォルトの名無しさん
07/10/28 09:42:07
>>233
短絡評価（short-circuit evaluation）や最小評価（minimal evaluation）に次いで
新たな用語が出てきたのかと思って調べてみたけど、どこで使われてる用語なの？

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

236:デフォルトの名無しさん
07/10/28 12:06:23
>>231
ムリだって。

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

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

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

237:デフォルトの名無しさん
07/10/28 13:16:45
次の言語仕様に中傷メソッドでも入れる勢いだなおい

238:デフォルトの名無しさん
07/10/28 14:26:16
>236
すまんね。a, b, c, d の評価はこっちではどうしようもないところだから思考の外にあった。
なのでむしろこんな感じだな。

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

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

239:デフォルトの名無しさん
07/10/28 14:27:02
ちょっと言い過ぎた。

240:デフォルトの名無しさん
07/10/28 21:06:43
ぬこぬこ

241:デフォルトの名無しさん
07/10/28 23:35:22
coutって、printfより使えないと思うのは俺だけ？

242:デフォルトの名無しさん
07/10/28 23:45:22
使えないとは言わないけども、
今思えば opeartor overload の乱用は失敗だったし、
フォーマット出力は欲しいってのはみんな思ってる。

243:デフォルトの名無しさん
07/10/28 23:53:31
こんなこともできるよ的なものじゃないの？

244:デフォルトの名無しさん
07/10/29 00:33:23
basic_ostreamはそもそもコンソール出力のために作ったものではないだろう
役割が違う

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

245:デフォルトの名無しさん
07/10/29 00:35:59
しかし型安全性は欲しいところ

246:デフォルトの名無しさん
07/10/29 00:37:33
コンソール出力のためでないならば、具体的にどういう場合 printf よりグーなのだろうか

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

248:デフォルトの名無しさん
07/10/29 00:48:29
でもboost::formatはどうコンパイルされてるやらさっぱりわからんから恐くて使えない。
0xでこのあたり、なにか改善はありますか？

次ページ