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ωって存在するぜ？
URLﾘﾝｸ(ja.wikipedia.org)
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でこのあたり、なにか改善はありますか？
249:デフォルトの名無しさん
07/10/29 00:50:16
怖くないよー怖くないよー
250:デフォルトの名無しさん
07/10/29 01:14:46
printf問題は書式文字列リテラルっていう文字列と別のリテラルを作って
コンパイラが型チェックするようにするのが結局いいんじゃないかなー
251:デフォルトの名無しさん
07/10/29 01:19:58
実際、多くのコンパイラがそれに近い扱いで型チェックしてるわけだな
252:デフォルトの名無しさん
07/10/29 05:15:01
stringstream でええやん。
253:デフォルトの名無しさん
07/10/29 20:02:05
>>248
boost::formatは別にコンパイル時にややこしいことをしてないと思うけど。
そんなことをする意味がない。
254:デフォルトの名無しさん
07/10/29 21:34:04
>>253
仕組み説明してYO
255:デフォルトの名無しさん
07/10/29 22:56:21
C++0x 2なんてつぶれろ
禿を含めたC++基地外共がややこしことばかり考えてるのに
これ以上つき合えるか！
どんなに論理的に強力な根拠があると言ってもややこしい論理は
結局受け入れられないんだよ。
お前らだけで勝手に遊んでろや！馬鹿
256:デフォルトの名無しさん
07/10/29 23:10:53
むしろわかりやすくなる方向に行ってると思うけどね
まぁ他の言語でも楽しんできてください
257:デフォルトの名無しさん
07/10/29 23:17:18
確かにややこしすぎる感じはする
よく使われる主要な言語が難しいのは歓迎だけど、わかる人間の価値が高まるし
でもこの勢いだと主要でなくなりそう
258:デフォルトの名無しさん
07/10/29 23:21:14
右辺値参照を理解できない人が多そう
259:デフォルトの名無しさん
07/10/30 00:06:35
>>255
よしきた
俺たちだけで勝手に遊ぶよ
260:デフォルトの名無しさん
07/10/30 00:06:49
>>256
>むしろわかりやすくなる方向に行ってると思うけどね
基本的には同意だが、どちらかというと
今までのややこしさを軽減させようとしているだけとも感じる。
つまり、今までのややこしさでC++に匙を投げた人間は、
C++0xを好意的に受け止めるとは思い難い。また、なんか追加されるのかよ的な感じで。
でも、そのおかげでオレのような本来はたいして有能でもない人間が、
チーム、部署内でのある程度の地位をキープできてる。
オレのまわりはC++敬遠ぎみの人が多いから。
まさにオレは禿のジョークを体現している。
そういうわけでC++0xには期待している。ほどよくややこしくしてほしい。
261:デフォルトの名無しさん
07/10/30 00:10:58
ややこしいのが嫌いな人には、今は代わりになる言語があるからね
262:デフォルトの名無しさん
07/10/30 00:15:56
それよりいつになったらC++はまともなオブジェクト指向言語になるのかと
263:デフォルトの名無しさん
07/10/30 00:17:38
いまのSTLすら理解できない人には
functionやbindは無視されるだろうね
264:デフォルトの名無しさん
07/10/30 00:21:24
>>263
bint1st, bind2nd, mem_fun, ptr_funなんかよりbindのほうが全然わかりやすい件について。
いまのMPLすら理解できない人には
C++0xの大部分はスルーされるだろうね
だったら同意。
265:デフォルトの名無しさん
07/10/30 00:26:09
>>264
bind1stとかについては同意
でもC++の文法からbindの存在を想像するのが難しいので
理解できないんじゃないかと思ったけど
インターフェースが簡単だから大丈夫なのかな
266:デフォルトの名無しさん
07/10/30 00:29:13
関数ポインタよりfunctionの方が全然分かりやすい件について
267:デフォルトの名無しさん
07/10/30 00:34:18
>>265
うん。大丈夫。以前経験した現場だと、C++初心者レベルのみんながboost::bindを使いまくって
プロジェクトが崩壊しかけたたよーん。
兄さん、そのbindしたthis、とっくに死んでます・・・みたいな。
268:デフォルトの名無しさん
07/10/30 01:56:25
bindでポインタ持ち運んだらえらいことになりそうだ
269:デフォルトの名無しさん
07/10/30 02:03:57
C++初心者はC++なんて使っちゃ駄目なのだ
つまりC++を学ぶときは、いきなりC++の達人にならなければいけない
270:デフォルトの名無しさん
07/10/30 02:06:12
んなこたぁ～ない
271:デフォルトの名無しさん
07/10/30 02:17:34
URLﾘﾝｸ(www.open-std.org)
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
272:デフォルトの名無しさん
07/10/30 05:11:26
便利な機能があるからって使わなきゃいけないということはない。
bindやconceptなんてライブラリビルダが使ってればよろしい。
273:デフォルトの名無しさん
07/10/30 08:21:15
まさにC++は男坂
274:デフォルトの名無しさん
07/10/30 09:18:28
いやbindは便利だよ
沢山引数を指定する関数のある引数だけを変えながら実行する場合、さらに具体的にいえば
初期化ルーチンで動作モードを調べながら実行するときとかよく使うし
275:デフォルトの名無しさん
07/10/30 12:33:27
>>272
そのレベルで使うならC++の必然性が少ない。言語は他にいっぱいある。
276:デフォルトの名無しさん
07/10/30 12:57:35
ぷろぱてぃというかげったーとかせったいみたいなのは
０ｘではいるんですか？はいらないんですか？
どうなんです？heheheh
277:デフォルトの名無しさん
07/10/30 13:21:27
なんか変なのキタ
278:デフォルトの名無しさん
07/10/30 14:53:31
下駄と雪駄？
もう入ってるだろうっつーか
下駄がcast operatorで
雪駄がassignment operatorで代用できそうな
279:デフォルトの名無しさん
07/10/30 17:00:46
それだとプロパティごとにクラス作らなきゃという気がする
280:デフォルトの名無しさん
07/10/30 17:19:19
>>279
プロパティは概念上、ダイレクトな生メンバとは違うものだから記述方法も違ってくるのかなと
下駄も雪駄もC++の原則
「テクニックでどうにもならない機能だけを言語仕様に頼む」
にはあたらないなあと
281:デフォルトの名無しさん
07/10/30 18:47:44
D言語マンセー
282:デフォルトの名無しさん
07/10/30 18:49:20
CよりDがEけど結局F#
283:デフォルトの名無しさん
07/10/30 20:20:20
Zもすでにあるみたいだし究極言語「ん」とか作ろうぜ
284:デフォルトの名無しさん
07/10/30 21:17:02
プログラム言語じゃなくて仕様記述言語だけどな。
285:デフォルトの名無しさん
07/10/30 21:20:42
ん、いいねぇ。
286:デフォルトの名無しさん
07/10/30 22:06:40
>>278
プロパティの代用はできねーよ。
そんなので代用したらクラスのサイズが無意味に増えるだろ。
287:デフォルトの名無しさん
07/10/30 23:06:29
>>286
getterとsetterが言語仕様に入るだろうか？という話をしているのに
なぜクラスのサイズという実装上の問題の話に摩り替わってしまうのだろうな？
288:デフォルトの名無しさん
07/10/30 23:23:14
>>287
はぁ？頭大丈夫か？
プロパティは
>下駄がcast operatorで
>雪駄がassignment operatorで代用できそうな
とか言う奴に、それで代用なんかできてないという話をしてるのに、
何故getterとsetterが言語仕様に入るだろうか、という話に摩り替えようとするんだよ。
バカかこいつ。
289:デフォルトの名無しさん
07/10/30 23:25:26
>>288に一票
290:デフォルトの名無しさん
07/10/30 23:57:08
じゃあ俺は>>287に100億万票
291:デフォルトの名無しさん
07/10/30 23:57:24
>>288
正論だが物言いがよくない
292:デフォルトの名無しさん
07/10/31 00:09:54
>>288
(1)getter/setterのC++0x化 → (2)下駄雪駄 → (3)代用はできない → (4)クラスのサイズが増える
で (1) || (2) の話をしている所に (2)->(3) と飛躍して (3) && (4) を適用していますが
話を逸らしている行為以外の何だと思っているのですか？
「代」わりに「用」いる、ではなく「そのテクニックは既にある言語仕様で実現できる」という話ですよ
(1) || (2) の時点で「あぁそうですね」で終わっていた話から (2)->(3) と展開する合理性が見えません
293:デフォルトの名無しさん
07/10/31 00:15:31
別に君は見えないままでいいんじゃない？
他の人は見えてるから問題無いし、君という一人の阿呆が困ったりムカついたりしても
誰も困らないし。
294:デフォルトの名無しさん
07/10/31 00:28:25
個人攻撃をする間で関数の一つでも書こうぜ…
295:デフォルトの名無しさん
07/10/31 00:29:16
>>293
>誰も困らないし。
>>292が困る件について
296:デフォルトの名無しさん
07/10/31 00:38:40
>>292
それはお前の脳みその中だけで通用するパカ論理だということを忘れてはいけません。
297:デフォルトの名無しさん
07/10/31 00:55:41
クラスのサイズが増える、って具体的に何が増えるの？マジで。
コードサイズだというならインライン化の度合はsetter-getterと同じかそれより強いと思うし、
データサイズが増えるわけはないし。
感情が先走って論理展開がムチャクチャになってないか。
本当に中傷メソッドが追加されるなこりゃｗ
298:デフォルトの名無しさん
07/10/31 01:00:34
レベルひっく～
299:デフォルトの名無しさん
07/10/31 01:07:11
∧＿∧ ／￣￣￣￣￣
（ ´∀｀）＜ オマエモナー
（ ） ＼＿＿＿＿＿
｜ ｜ |
（＿_）＿）
300:デフォルトの名無しさん
07/10/31 01:32:05
たとえ内容がマトモでも罵倒口調だと読む気がしない
301:デフォルトの名無しさん
07/10/31 02:10:04
バカばーっか。
302:デフォルトの名無しさん
07/10/31 02:26:48
じゃ俺ははらたいらに3000点
303:デフォルトの名無しさん
07/10/31 03:38:05
もうお亡くなりになられました。
ってか、もういー加減にしろよｗ
304:デフォルトの名無しさん
07/10/31 08:50:15
>>297
パカ極まるなお前。
>下駄がcast operatorで
>雪駄がassignment operatorで代用できそうな
これで代用したプロパティを持つクラスを実際に作ってsizeofしてみろ場か
305:デフォルトの名無しさん
07/10/31 09:40:43
>>304
あなたの意見を私が証明しなければならない、というのは筋が通りませんが…
sizeof にコード量が反映されるという処理系は知りませんよ？私は
306:デフォルトの名無しさん
07/10/31 09:41:41
>>304
sizeof は変わらないでしょう。
307:デフォルトの名無しさん
07/10/31 12:13:12
>>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);
どっちが大きい？
308:デフォルトの名無しさん
07/10/31 12:21:10
違う言語で比較してどうすんの？
309:デフォルトの名無しさん
07/10/31 13:45:53
もともと（C#にあるような）プロパティが欲しいって話じゃなかったっけ
310:デフォルトの名無しさん
07/10/31 13:56:59
syntax sugar 以上の意味があるの？
311:デフォルトの名無しさん
07/10/31 13:59:14
参照の分メモリを節約できるといいたんじゃないの
312:デフォルトの名無しさん
07/10/31 14:32:05
プロパティ + 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
無理かな。
313:デフォルトの名無しさん
07/10/31 14:48:07
>>307
cast operator と assignment operator では代用できない、という話ではなかったのですか？
314:デフォルトの名無しさん
07/10/31 15:35:48
漏れもデータメンバが増えるようでは setter と getter の
シンタックスシュガーの代用としては不適格だと思うが・・・
単一の本物のデータメンバであることを活かせる場面もあるだろうから、
どっちが良いという話ではないけど。
315:デフォルトの名無しさん
07/10/31 15:42:33
getとsetが予約語になったら楽しい
316:デフォルトの名無しさん
07/10/31 15:56:07
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);
}
317:デフォルトの名無しさん
07/10/31 17:33:19
>>316
Dはそれでいいだろうが、C++で bind するとき大変そうだからヤダ
318:デフォルトの名無しさん
07/10/31 18:38:23
Dとかイラネェ
319:デフォルトの名無しさん
07/10/31 19:03:55
template <typename _T>
class property {
320:デフォルトの名無しさん
07/10/31 19:04:28
なかったことにしよう
321:デフォルトの名無しさん
07/10/31 19:16:58
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
}
322:デフォルトの名無しさん
07/10/31 19:49:38
それ、publicメンバ変数に比べて何か嬉しいことあんの？
323:デフォルトの名無しさん
07/10/31 20:47:09
なんもないｗ
default constructibleじゃないとだめだし
マジメなsetter/getter実装しようともったら結局なんらかの参照が必要になる
324:デフォルトの名無しさん
07/10/31 21:35:04
C++ : 不便に感じる糞仕様がそれなりに多い
D : 妥協ライン
C# : マイコーソフトの柵
C++0x : 期待と不安の境目
325:デフォルトの名無しさん
07/10/31 21:57:53
>>305
いつ誰がコード量が増えると言ったんだ？
筋が通ってないのはお前だよ。
>>313
どうみても代用できてないだろ。お前の目はフシアナかいな。
326:デフォルトの名無しさん
07/10/31 23:05:08
一応こんな提案あったみたいだけど、Not ready for C++0x, but open to resubmit in future になってる。
C++ Properties -- a Library Solution
URLﾘﾝｸ(www.open-std.org)
327:デフォルトの名無しさん
07/11/01 01:57:51
プロパティ話は Boostスレpart4 でもやってたやん
もういいよ
328:デフォルトの名無しさん
07/11/01 07:48:40
>>327
それ言ったらほとんどのスレッドが終わっていく…
329:デフォルトの名無しさん
07/11/01 19:46:00
>>326
C++1x？が待ち遠しくなった。
330:デフォルトの名無しさん
07/11/01 20:32:27
>>326
プロパティ1つ追加するごとに、ポインタ分だけオブジェクトのサイズが膨らむのか
331:デフォルトの名無しさん
07/11/02 03:20:43
そもそもプロパティなんていらね
332:デフォルトの名無しさん
07/11/02 10:42:00
たしかにいらね。
そのまま公開するんなら public メンバ変数にするさ。
333:デフォルトの名無しさん
07/11/02 11:02:23
下駄と雪駄にfuck…もといhookかけられるならそれなりに有用になるかも
334:デフォルトの名無しさん
07/11/02 11:11:10
hook をかけないプロパティになんのいみがあるのかと問いたい
335:デフォルトの名無しさん
07/11/02 11:23:07
なんとなくオブジェクト指向している気になれるというなかなかぬるぽな効果があります
336:デフォルトの名無しさん
07/11/02 11:57:04
プロパティいらねぇから、組み込み変数とPODに対してだけでいいから
変数の値が更新されたときにフックかけれるようにして欲しい。
class MyWindow {
void updateRect( RECT old_value ) {
SetWindowRect(&windowRect);
}
public:
__declspec(onchange=updateRect) RECT windowRect;
}
みたいな。
337:デフォルトの名無しさん
07/11/02 13:39:58
いつのまにやら日本語版にもC++0xの項目が
URLﾘﾝｸ(ja.wikipedia.org)
M＄が21世紀終わるまでにちゃんと実装してくれるとは思えん。
338:デフォルトの名無しさん
07/11/02 13:50:31
項目ができてから1ヶ月余り？
それにしてはすごい量だな
339:デフォルトの名無しさん
07/11/02 13:58:51
項目ができてから書き始めるわけじゃないですからｗ
340:デフォルトの名無しさん
07/11/02 21:00:15
constexprにあらゆる再帰が不可能ってまじ？
再帰テンプレートとかも？
341:デフォルトの名無しさん
07/11/02 21:20:46
>>336
それかっこいいね。
でも、俺の頭はまだ AOP に対応してないから、用途が思いつかん・・・orz
>>337
情報サンクス。
しかしよく纏まってるなぁ。
342:デフォルトの名無しさん
07/11/02 22:23:43
>>338
履歴によれば、初版は英語版の翻訳。
URLﾘﾝｸ(ja.wikipedia.org)
343:デフォルトの名無しさん
07/11/02 22:28:18
へーすごいな
感心した
344:デフォルトの名無しさん
07/11/02 22:32:08
翻訳乙
345:デフォルトの名無しさん
07/11/02 22:36:47
どおりで訳文チックだとおもった
346:デフォルトの名無しさん
07/11/02 23:07:38
>>336
MyWindow win;
RECT *r = &win.windowRect;
external_library_function::foo(r); // rを弄る
こんなコードに対しても、フックを呼んで欲しいの？
いくらなんでも無理めじゃないか？
347:デフォルトの名無しさん
07/11/03 00:17:33
生のポインタの代わりに代入法・参照法を記述したサンクを渡せば桶
348:デフォルトの名無しさん
07/11/03 00:26:04
>>347
生のポインタはいつでも取れるんだから、何の安全弁にもならないし、
カプセル化になってない気がするけど
349:デフォルトの名無しさん
07/11/03 00:34:06
だから、生のポインタは取れなくて、メンバのように見えるものが欲しいという話なのでは？
350:デフォルトの名無しさん
07/11/03 00:36:35
それこそプロパティではないか
351:デフォルトの名無しさん
07/11/03 00:41:28
>>336 は「プロパティいらねぇから」と言いつつ、まさにプロパティが欲しいと言ってんだと思うっす。
対称性を考えれば参照時のフックも欲しくなるっす。
352:デフォルトの名無しさん
07/11/03 08:06:03
じゃあ、右辺値、左辺値参照のoperator導入な。
353:デフォルトの名無しさん
07/11/03 08:40:08
operator && () は入るんでしょ？
354:デフォルトの名無しさん
07/11/03 16:00:14
>>353 すでにあるわけだが、何のことかな？
355:デフォルトの名無しさん
07/11/03 17:01:51
operator && (void) ってokなの？
356:デフォルトの名無しさん
07/11/03 18:08:58
>>354
既に無いわけですけど、何のことかな？
357:デフォルトの名無しさん
07/11/03 18:37:12
二人の「既に」の時間が別な件について
358:デフォルトの名無しさん
07/11/03 18:46:55
operator && って、あれだろ、オーバーロードするとショートサーッキットが
利かなくてはまるっていう。
359:デフォルトの名無しさん
07/11/03 18:51:32
>>358
URLﾘﾝｸ(ja.wikipedia.org)
で && で一通り検索してこい
360:デフォルトの名無しさん
07/11/03 19:03:44
operator && があるかないかなら、あるだろ。常考。
361:デフォルトの名無しさん
07/11/03 19:18:50
>>359
右辺値参照のために && が使われるようになることは知ってるけど、
operator && は昔から別の意味である。
362:デフォルトの名無しさん
07/11/03 20:23:18
いいから検索しろ、な
363:デフォルトの名無しさん
07/11/03 21:14:27
検索しても、 operator && について何が言いたいのかさっぱりわからない。
364:デフォルトの名無しさん
07/11/03 21:28:44
右辺値参照の&&はそもそもoperatorじゃなくてkeywordってこと？
365:デフォルトの名無しさん
07/11/03 21:43:51
&& を右辺値参照だけと勘違いしてる奴初めて見た。
366:デフォルトの名無しさん
07/11/03 22:39:54
>>365
物言いを直さないと大人になったとき苦労するよ
367:デフォルトの名無しさん
07/11/03 22:49:15
>>366
ｵﾏｴﾓﾅ
368:デフォルトの名無しさん
07/11/03 23:00:40
切り返しになってないなぁ。うん。
369:デフォルトの名無しさん
07/11/03 23:13:09
うん
370:デフォルトの名無しさん
07/11/03 23:23:41
もう大人だもんな
371:デフォルトの名無しさん
07/11/03 23:53:46
>>364
そもそも今までだって構文上、型名の*や&、[]、関数の()などは演算子ではない。
そこに&&が加わるだけ。
372:デフォルトの名無しさん
07/11/03 23:55:27
&&じゃなくて@とかにしなかったのはなんでだろ
参照なんですよ。という意味を込めたかったのかな
373:デフォルトの名無しさん
07/11/03 23:58:55
参照の記述に近いことと、字句解析に変更が要らないのがいいんじゃない？
374:デフォルトの名無しさん
07/11/04 00:07:08
>>372
それもあるだろうけど
新たなトライグラフが必要になるからだと思う
375:デフォルトの名無しさん
07/11/04 00:48:57
トライグラフは廃止の方向じゃなかったっけ
376:デフォルトの名無しさん
07/11/04 00:51:43
でもダイグラフとか代替表記とかあるし。
377:デフォルトの名無しさん
07/11/04 00:52:56
そんな提案があったの？
ドラフト(N2369)にはしっかり記述があるけど
378:デフォルトの名無しさん
07/11/04 01:35:33
しかし@がない文字コードってあるの?
379:デフォルトの名無しさん
07/11/04 01:43:24
>>378
っていう疑問がでてきて調査が必要になるので
新しい記号の導入はできるだけ避けたいと
380:デフォルトの名無しさん
07/11/04 02:10:37
既に無いわけですけど、何のことかな？
「既に無い」にめっちゃ吹いたw
381:デフォルトの名無しさん
07/11/04 07:31:58
#や[]にtrigraphがあるくらいだから油断禁物だな。
しかし@がないシステムは、dmr??.bell-labs.comとかやってんのかね。
>>371
後ろの「関数の」はいらないんじゃ?
382:デフォルトの名無しさん
07/11/04 08:35:36
>>381
つっこむところ、そこだけじゃないよ。
383:デフォルトの名無しさん
07/11/04 10:10:45
トライグラフ・ダイグラフって文字コードじゃなくて、
キーボードに対応するキーがない場合、ってのを問題にしてるんじゃね？
例えば日本語環境だとウムラウト付き文字を入力するの面倒だろ。
384:デフォルトの名無しさん
07/11/04 12:34:47
@ が無いシステムじゃメールが使いにくそうだねｗ
今となってはソースは Unicode、入力法はエディタやインプットメソッドで勝手に解決しろ、でいいと思う。
385:デフォルトの名無しさん
07/11/04 14:44:05
@なんて使われたらVCのマングリングが崩壊するから駄目です＞＜
あとは擬似コードで任意の演算子を示すときに使ったりするなあ
386:デフォルトの名無しさん
07/11/04 16:26:39
>>385
なんで VC のマングリングが崩壊？
リンク時のシンボルと演算子としての @ の関係が分からん。
387:デフォルトの名無しさん
07/11/04 18:06:56
>>378
ISO/IEC 646的には「#$[\]^{|}~@`」の12コードポイントが別文字になりうる
参照：URLﾘﾝｸ(ja.wikipedia.org)
……んだけど、この文字コードで動いてるシステムって今どんだけあるのかなぁ
388:デフォルトの名無しさん
07/11/04 21:00:39
日本では改行は「￥n」と覚えてるし、英国人は「￡include」で慣れているしね。
まあ過去の遺産でしょ。＞トライグラフ・ダイグラフ
389:デフォルトの名無しさん
07/11/05 11:17:05
けど、ソースがUnicodeになると、その慣れが一気に負の遺産に…
390:デフォルトの名無しさん
07/11/05 20:47:26
え？ソースをunicodeで書いても解決しないでしょ？
VC 2005とかunicodeで記述するのがデフォルトだけど、
バックスラッシュは相変わらず円マークですけど。
391:デフォルトの名無しさん
07/11/05 21:11:47
>>390
簡単に言うと、君の使ってるのが偽Unicodeだってこと
URLﾘﾝｸ(ja.wikipedia.org)
392:デフォルトの名無しさん
07/11/05 21:20:36
いい機会なんで円記号はバックスラッシュに戻してほしかったな
393:デフォルトの名無しさん
07/11/05 22:42:09
>>391
は？よく読めよ。何が偽だよ。
>これは日本語用のフォントデータの0x5Cの位置には円記号の字形を当ててしまうことで対処している
394:デフォルトの名無しさん
07/11/05 23:18:29
逆に言えば、U+5Cにバックスラッシュのグリフを持ったフォントを使えば、
バックスラッシュとして表示される。
395:デフォルトの名無しさん
07/11/06 00:00:08
まあその辺りに興味ある人は文字コードスレで。
396:デフォルトの名無しさん
07/11/07 08:45:15
フォントスレで事足りるな。
397:デフォルトの名無しさん
07/11/07 12:01:57
>>393
「簡単に言う」のなら、それは「偽Unicode」だろｗｗｗ
398:デフォルトの名無しさん
07/11/07 13:31:42
>>393
cout << "その本は500\です。\n" << endl;
同じグリフになったら、0x5cと0xc2 0x5cの見分けがつかないだろw
0x5cのYENだけ斜めにでもしとくのか?
399:デフォルトの名無しさん
07/11/07 19:07:29
VC2005でinttypes.hがつかえねーーーーーーーーーーーーー誰か代換え案ください・・・2008?
400:デフォルトの名無しさん
07/11/07 19:36:04
自分で作る
401:デフォルトの名無しさん
07/11/07 19:55:58
あGCCから持ってきました
402:デフォルトの名無しさん
07/11/07 19:59:48
Windows板行けよ。
C++0xに関係ないし。
403:デフォルトの名無しさん
07/11/07 22:26:47
boostつかえ
404:デフォルトの名無しさん
07/11/07 22:28:18
conceptは間に合うんだろうか
405:デフォルトの名無しさん
07/11/08 04:58:25
あ、concept は余裕で間に合うよ。安心しといて。
それより問題なのは export なんだよ。実は。
406:デフォルトの名無しさん
07/11/08 10:15:11
exportは実装されて実績も出てるが何が問題だろうか、と考えるに
メジャーベンダが｢ﾔﾗﾈ」と言い出してるあたりか
VCとgccは入れないんだよな、bccは最新版で入ってるらしいことは聞いた
407:デフォルトの名無しさん
07/11/08 16:38:53
extern inline とかな
408:デフォルトの名無しさん
07/11/12 21:22:45
concepts抜きでは送り出さんと書いてあるね。
URLﾘﾝｸ(herbsutter.spaces.live.com)
知らん間にスケジュールが1年ずれてたんだな…
409:デフォルトの名無しさん
07/11/13 16:32:10
vs2008でどのくらい対応するんだろう・・・
410:デフォルトの名無しさん
07/11/13 18:52:18
vs2012くらいにならないと対応しないんじゃね？
411:デフォルトの名無しさん
07/11/13 23:39:50
g++0xとかになっちゃうのかな。
いままで3文字でやってきたのがちょっと気持ち悪い。
でもg0xとかだったら泣く。
412:デフォルトの名無しさん
07/11/13 23:43:32
VC++9.0でc++0xを実装するみたいだね
413:デフォルトの名無しさん
07/11/13 23:45:11
>>411
普通にg++ , C++ なりclなりでいいと思うんだが... C++/CLIなんていう類似品と違って正真正銘の時期標準規格なんだぞ？
414:デフォルトの名無しさん
07/11/13 23:45:44
拡張子が .cpp0x になってたら厭だな
415:デフォルトの名無しさん
07/11/13 23:46:51
むしろ全てのコードの拡張子は.txt
416:デフォルトの名無しさん
07/11/13 23:57:29
Content-Type: text/x-cplusplus0x-source; charset=utf-8
なんてメタデータが必須になります
417:デフォルトの名無しさん
07/11/14 00:34:36
C++0xはC++の新しいバージョンの仮称ってだけで
決まった後はただのC++だろ
418:デフォルトの名無しさん
07/11/14 00:36:10
無料のC++だよね
419:デフォルトの名無しさん
07/11/14 00:42:19
>>417
C90, C95, C99みたいに言葉は残るはず。
C++98, C++03, C++09かな。
420:デフォルトの名無しさん
07/11/14 00:54:06
>>413
CLIはISOに蹴られたんだったな
421:デフォルトの名無しさん
07/11/14 00:59:09
C++1x
422:デフォルトの名無しさん
07/11/14 01:00:38
ISO/IEC 14882:201x
423:デフォルトの名無しさん
07/11/14 03:37:54
来年の2月までミーティングないのか。
こりゃ本当にC++0aになりそうだなぁ。
424:デフォルトの名無しさん
07/11/14 03:57:33
C++0x0a
にすれば問題ないじゃないか
425:デフォルトの名無しさん
07/11/14 09:04:35
ぶっちゃけたところ、C++0xはメインストリームで使われる言語になれるのでしょうか？
なれるとしたら何年後くらいだと思いますか？
426:デフォルトの名無しさん
07/11/14 09:58:57
なれないだろうね。
組み込みとか、system layerの低いところ、e.g. OS kernel、では、
今後C++を使う例がどんどん増えていくと思うけれど。
ただC++がtemplateで行った実験は、
今後のプログラミング言語に大きな影響を与えると思う。
素晴らしい実験が今でも行われ続けている。
427:デフォルトの名無しさん
07/11/14 11:15:53
Embedded C++の覚醒と聞いて飛んできました
428:デフォルトの名無しさん
07/11/14 11:59:57
Embedded C++？どこにそんな情報が！？マジなら知りたい。
429:デフォルトの名無しさん
07/11/14 13:07:33
いやごめん、426の話を受けた冗談
430:デフォルトの名無しさん
07/11/14 13:09:48
>>425
まず、メインストリームが何かを定義してもらおうか
431:デフォルトの名無しさん
07/11/14 13:26:00
世間的には既に C++ がメインストリームではないからな。ｗ
C++ 族（？）の中では C++0x はメインストリームになると思うが。
432:デフォルトの名無しさん
07/11/14 14:16:14
Embedded関係ないのか･･･。
boost使えずやきもきしてたから小躍りしてしまったぞーーー！
433:デフォルトの名無しさん
07/11/14 14:29:17
Darwinのデバドラ・フレームワークのIOKitがEmbedded C++でしょ。
多重継承、template、name spaceないもん、boostは無理でしょw
434:デフォルトの名無しさん
07/11/14 14:43:56
難攻不落の女を口説いて落とすかのような面白さがある言語としてだな
435:デフォルトの名無しさん
07/11/14 14:53:40
それでもBoost.Preprocessorなら…Preprocessorならなんとかしてくれる
436:デフォルトの名無しさん
07/11/14 15:23:22
Embedded C++って本当に馬鹿な規格だよな。
フル規格のC++で、開発部隊毎にコーディング既約作ればいいだけなのに。
しかもまともなコンパイラすら作れないメーカが発起w
437:デフォルトの名無しさん
07/11/14 15:30:24
template使えないC++に用はありませんよねー
438:デフォルトの名無しさん
07/11/14 15:31:55
しかしEmbeddedでないC++コンパイラを作っても開発にコストがかさんで売れるかどうか。
そこらへんの妥協点を定めたのがEmbeddedなんじゃないの？
439:デフォルトの名無しさん
07/11/14 15:58:51
そんなひ弱な開発部隊が作ったコンパイラなんか使いたくないよ。
Cでさえ、マイナーコンパイラは悲惨だったのに。
440:デフォルトの名無しさん
07/11/14 16:12:20
いくら俺がネタにしたからって、おまいら叩きすぎです
441:デフォルトの名無しさん
07/11/14 18:41:18
>>436
同意。組み込み用ならランタイムが軽くなる仕様を考えるべきなのに、なぜかコンパイラ作りが
楽になる仕様にしたという馬鹿言語。
おそらく日本のマイコンメーカのソフト開発部門の能力に合わせたのだろう。ｗ
442:デフォルトの名無しさん
07/11/14 18:45:56
正直typeinfo以外にランタイムに問題になるものないでしょ。
443:デフォルトの名無しさん
07/11/14 18:51:05
自分で商用並みに完全な準拠コンパイラを作るにはどれぐらい手間かかる？
444:デフォルトの名無しさん
07/11/14 18:56:14
5人年くらいはかかるんじゃね。
445:デフォルトの名無しさん
07/11/14 19:57:26
>>441
ミニマムな規格にしていろんなCPU用に処理系が用意されるように、
ってのを目指したんじゃない？
ちゃんとした C++ を提供したいところは今まで通り gcc 等使うだろうし。
446:デフォルトの名無しさん
07/11/14 20:28:06
templateのexportを実装するのに3人年かかったらしい
447:デフォルトの名無しさん
07/11/14 21:03:44
込め合うの開発部隊って何人いるんだろ。
448:デフォルトの名無しさん
07/11/14 21:31:26
３人いるらしーよ。
449:デフォルトの名無しさん
07/11/14 21:42:16
少な！
でも多ければいいってもんでも無いか…
450:デフォルトの名無しさん
07/11/14 23:09:23
ラムダ式とクロージャが間に合うと嬉しいな
451:デフォルトの名無しさん
07/11/14 23:47:46
ラムダ式があるとサンプルプログラムが書きやすそう
452:デフォルトの名無しさん
07/11/15 02:24:43
あれ？ごめん、クロージャなんて入る予定あるの？
453:デフォルトの名無しさん
07/11/15 02:45:47
tr1::functionの事なんじゃまいか
454:453
07/11/15 02:51:08
あーなんか言い方おかしい…
ラムダとfunctionで似たような事ができるよってだけなのかな
455:デフォルトの名無しさん
07/11/15 08:47:34
>>452
ラムダ式の <&> で始まるやつのことじゃない？
456:デフォルトの名無しさん
07/11/15 08:48:28
functionってただの関数オブジェクトだよね？
457:デフォルトの名無しさん
07/11/15 09:10:39
>>455
やべぇ。また知らないものが出てきたぞ。
ラムダ式で <&> で始まるやつとやらの概要を教えて。
458:デフォルトの名無しさん
07/11/15 13:35:38
n2329の「7.1 The <&> form」読んでくれ。
半ページしかないから。
あとついでにn2413の「6.1 The <&> form」も。
n2329がgeneric版、n2413がmonomorphic版。
459:デフォルトの名無しさん
07/11/15 18:10:54
>>458
さんくす。
なるほどー。ただものじゃないな・・・この仕様。
ラムダ導入って単にちょっとした無名の関数を書けるだけかと思ってたけど、
実はちゃんとクロージャしてるんだね。
これ実装できるかねぇ。というかまず proposal が通らないと始まらないか。
460:デフォルトの名無しさん
07/11/15 20:17:39
とはいっても関数オブジェクトを手軽に書くための糖衣構文だけどね
でも喉から手が出るほど欲しかった甘さだ
461:デフォルトの名無しさん
07/11/15 20:19:52
ラムダ式＋クロージャが導入されたらコードはどういう風に変わるの？
変化を適当な例で示してくれよよよ
462:デフォルトの名無しさん
07/11/15 20:31:53
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"});
// ...
}
に
463:デフォルトの名無しさん
07/11/15 21:06:25
新キーワードを導入してもよかった気がするなあ
464:デフォルトの名無しさん
07/11/15 21:30:25
>>462
おー確かに凄い…
それと
> <&> form
<>の事だったのね･･･
465:デフォルトの名無しさん
07/11/15 21:59:59
>>463
「New function declaration syntax for deduced return types」
なんかを見ると <> の代わりに auto でも良さそうに思うね
auto の再利用が過ぎるか？
466:デフォルトの名無しさん
07/11/15 22:57:50
auto はちょっと怖いよね。
便利だろうけど、乱用するとコンパイラしか真実を知らない
なんてことになりそう・・・
467:デフォルトの名無しさん
07/11/15 23:03:56
意味、目的が全然違うじゃん。
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";});
じゃない?
468:デフォルトの名無しさん
07/11/15 23:06:55
あ、n2329は { <式. } だったっけね。
469:デフォルトの名無しさん
07/11/15 23:13:50
うん、自分も記憶では式は () だったと思いながら
手近にあった n2329 を見ながら >>462 を書きました
n2413では () だね
470:デフォルトの名無しさん
07/11/15 23:17:33
>>467
まあ、そうなのかもしれないけど
n1978なんかを見ると auto を使うのもありかなと
471:デフォルトの名無しさん
07/11/15 23:21:44
mem_fun(&::f) より、<>(x){ x->f() } のほうが
インライン化が期待できる分、高速になる可能性があるな
472:デフォルトの名無しさん
07/11/15 23:36:52
>>470
n2329でいろいろな案が提案されて、
n2413で今の形に落ち着いてる。
473:デフォルトの名無しさん
07/11/15 23:39:54
>>471
Fig. 1 Example translation on lamba function. ～
を見るとそう簡単な話でもなさそうだけど。
自由変数含まない時は、translationを最適化しないと駄目。
474:デフォルトの名無しさん
07/11/16 01:02:11
gcc拡張でクロージャできるけど、仕組みはあんな感じ？
でもあれマルチスレッドで破綻するよね。
475:デフォルトの名無しさん
07/11/16 02:23:58
>>474
関数内関数の事？あれC++だとサポートされてないよ
476:デフォルトの名無しさん
07/11/16 06:14:03
（ ﾟдﾟ）ﾎﾟｶｰﾝ
477:デフォルトの名無しさん
07/11/16 09:04:24
>>475
そうそれ。
g++でサポート外とかそういうことじゃなくてC++0xでの仕組みの話し。
478:デフォルトの名無しさん
07/11/16 09:08:15
>>477
lambdaは「式」なの。
レベル低すぎ。
479:デフォルトの名無しさん
07/11/16 09:15:24
>>478
シンタックス上はそうだね。
で例えばどういうバイナリになるのかって話。
レベルの高い人、解説よろしく。
480:デフォルトの名無しさん
07/11/16 09:45:18
translationがn2413載ってるから読め。
>>472に書いてあるだろ。
481:デフォルトの名無しさん
07/11/16 12:53:51
>>404
conceptsの策定はもう終盤だよ。
規格に入れる文言を練っているところだもの。
Libraryのconcept化は今回やらないし。(n2322)
微妙なのがthread。lambdaも油断ならない。
482:デフォルトの名無しさん
07/11/16 22:08:51
@ とか新しい文字を導入できないんだろうか。
483:デフォルトの名無しさん
07/11/16 22:15:25
今更無理だろ
@と$はいろいろ好き勝手使われてるから
484:404
07/11/16 23:16:50
>>481
たしかに08年の9月なら間に合うと思った
もうちょっと差し迫ってるのかと思ってた
485:デフォルトの名無しさん
07/11/17 15:42:44
C++1xまでお預けか…
いや、STLPortならやってくれるか？
486:デフォルトの名無しさん
07/11/17 22:43:25
コミュニティーからはconceptを使ったSTLの色々な実装が出てくるだろうね
487:デフォルトの名無しさん
07/11/17 23:55:37
もう出てますが…
488:デフォルトの名無しさん
07/11/18 00:19:37
詳細ごぼんぬ
489:デフォルトの名無しさん
07/11/19 01:21:01
遅ればせながらproposalやdefect reportを投げたい人向けのFAQ
URLﾘﾝｸ(www.comeaucomputing.com)
490:デフォルトの名無しさん
07/11/23 02:11:42
コンストラクタのポインタって
出来ないのかなぁ。
例えば、
new (*p)();//コンストラクタ型ポインタの宣言
クラス名 *obj;//通常のポインタ
p=&クラス名;//コンストラクタのアドレス取得(実際はメタ情報を指す)
obj=new p();//オブジェクトの生成(メタ情報から本来のnewで生成したポインタを返す)
てな感じ。あればCallBacK関係で重宝
しそうなんだが、
問題はdeleteが…。
491:デフォルトの名無しさん
07/11/23 02:15:09
コンストラクタを呼ぶファンクタなら、今でもBoost.Lambdaに色々ある。
URLﾘﾝｸ(boost.org)
消すほうはshared_ptrにでも入れておけばいいだろ。
492:デフォルトの名無しさん
07/11/23 02:55:50
テンプレートだと
void callback(new(*p)())
{
中略
}
void(*f)(new(*)())=callback;
f(&Type0);
f(&Type1);
って事は出来んだろ？
それと、
new (*p)=外部関数();
てな感じで別の翻訳単位のクラスを
取得するのも不可能だろ。
493:デフォルトの名無しさん
07/11/23 04:49:56
placement newじゃだめなん
494:デフォルトの名無しさん
07/11/23 08:49:22
Hoge hoge;
hoge.~Hoge();
new(&hoge) Hoge();
495:デフォルトの名無しさん
07/11/23 11:45:12
>>493
>>494
プレスメントだと同じ翻訳単位に
クラスが存在しないといけないから
無理だよ。
それと、さっきレスで
new (*p)=外部関数();
って書いたけど正しくは、
new (*p)()=外部関数();
あ､冷静に考えたら戻り値
の型要るな、
Type new *(*p)();
戻り値はポインタしかないから、
アスタリスク省略してもいい気も
する。
Type new (*p)();
一応Typeは渡すコンストラクタ
の親でも構わない(共変な型)。
こんな感じでどうよ。
496:デフォルトの名無しさん
07/11/23 11:52:14
どうよって言われても。このスレに書いたらC++0xに採用してくれるとか思ってんの？
つーか、そんなのテンプレートで定義すれば簡単に出来るから入らないよ。
497:デフォルトの名無しさん
07/11/23 11:58:10
というか、C++の関数ディスパッチのこと理解してないの丸出し
498:デフォルトの名無しさん
07/11/23 12:33:46
自信ないけどこうすればいい？
#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();
}
499:デフォルトの名無しさん
07/11/23 12:35:52
>>495
同じ翻訳単位にクラスが存在しなかったら、
作ったクラスを扱えんと思うのだが。
500:デフォルトの名無しさん
07/11/23 12:36:27
×作ったクラス
○作ったインスタンス
501:デフォルトの名無しさん
07/11/23 12:52:18
>>496
>C++0xに採用してくれる
>とか思ってんの？
確かにそうだが、実装されたい
機能の妄想ぐらいしてもいいだろ?
ここは2CHなんだから。
>つーかテンプレートで定義すれば簡単に出来る
マジで？
今のところ別の翻訳単位の
クラスでインスタンス化できる
テンプレート実装を見たことが
ないんだが。
exportですら同じ翻訳単位に
クラス定義が必要なのにどうやったら
できるの？
502:デフォルトの名無しさん
07/11/23 12:54:42
妄想はチラシの裏とか自分のブログとかでお願いします。ここは2chですよ。ｗ
503:デフォルトの名無しさん
07/11/23 13:02:18
クラス定義をヘッダに書いてそれをインクルードすれば、
こういう使い方では翻訳単位なんて問題ないだろ。
504:デフォルトの名無しさん
07/11/23 13:22:08
レベルが低すぎるから、他のスレに行って欲しいw
505:デフォルトの名無しさん
07/11/23 13:24:22
別の翻訳単位のクラスでインスタンス化できるテンプレートって表現がよくわからんから解説してくれ
506:デフォルトの名無しさん
07/11/23 13:30:59
>>501
は？
お前の案もクラス定義が必要なこといってますけど？それが？
>Type new (*p)();
>一応Typeは渡すコンストラクタ
>の親でも構わない(共変な型)。
クラスの親子関係はクラス定義がないとわからない。
507:デフォルトの名無しさん
07/11/23 13:34:18
動的型言語でもなければクラス宣言がないとどうしようもないべ。
508:デフォルトの名無しさん
07/11/23 13:36:38
つ スルー力
509:デフォルトの名無しさん
07/11/23 13:37:02
なんかロシア語っぽい響き
510:デフォルトの名無しさん
07/11/23 13:53:47
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;
はい、テンプレートで出来ました。
511:デフォルトの名無しさん
07/11/23 14:03:03
何かきったねーな。
512:デフォルトの名無しさん
07/11/23 14:06:17
Createクラスをもっと複雑に作れば、
使う側はもっと簡易的に使うことも出来るけど、ま、それはきみへの宿題ということで。
513:デフォルトの名無しさん
07/11/23 14:08:32
そんな簡単な事にいちいちえっらそうだなw
514:デフォルトの名無しさん
07/11/23 14:11:44
客観的に見て、何も言わない癖に、文句だけはつけるお前の方が偉そうだと思う。
515:デフォルトの名無しさん
07/11/23 14:15:18
客観的に見て、どっちも大して変わらない。
516:デフォルトの名無しさん
07/11/23 14:16:38
文句や煽りしか出来ない低脳がウヨウヨ集まってきました。
517:デフォルトの名無しさん
07/11/23 14:44:43
関数ポインタを返す関数を１つ作るだけで見た目綺麗になる。
518:デフォルトの名無しさん
07/11/23 14:46:04
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;
}