[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 15:57 / Filesize : 207 KB / Number-of Response : 987
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++0x 2



1 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:29:11 ]
The C++ Standards Committee
ttp://www.open-std.org/jtc1/sc22/wg21/

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

2 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:44:39 ]
スレタイはC++1xだろ…常考

3 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 21:29:39 ]
ん? こっち使うの

4 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 21:33:37 ]
よし、こっちを使おうぜ

5 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 21:52:06 ]
>>1


6 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 21:53:14 ]
こっちでいくか。

7 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:05:18 ]
前スレから
ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry

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

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

9 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:15:41 ]
vector<int> v = { 1, 2, 3 }; 

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

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

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

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



11 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 23:00:04 ]
>10
va_list よりは大分ましだと思うが、std::initializer_list<T> を使うことになる。
www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2215.pdf
www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2385.pdf

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

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


13 名前:デフォルトの名無しさん [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/08(月) 23:41:48 ]
constexpr をつけたほうがいいのでは?

15 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 00:14:38 ]
clampみたいな、クロージャは入るのかな。

16 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 00:28:29 ]
最新のworking draftはこれかな。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

17 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 00:43:08 ]
>13
コーディング規約とかで真っ先に使用禁止になりそうな機能だ(w

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

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

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


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

20 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 01:30:47 ]
>>18
×duble
○double



21 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 01:35:53 ]
using duble = double;

22 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 01:51:47 ]
#define duble double

23 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 01:52:32 ]
typedef double duble;

24 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 02:29:02 ]
>>21-23
それはコーディング規約で禁止になるなwww

25 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 02:30:35 ]
そんなんバレなきゃ大丈夫

26 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 09:40:10 ]
#define private public

27 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 12:47:17 ]
#define class struct

28 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:46:48 ]
C++はVisual C++のバグとの戦いの歴史
Boostは今も戦いの最中

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

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

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



31 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 16:43:08 ]
もうC++はC++/CLRしかサポートしないんじゃないか?

32 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 16:44:10 ]
× C++/CLR
○ C++/CLI

33 名前:デフォルトの名無しさん [2007/10/09(火) 16:48:49 ]
そこで
C++0x/CLI
の登場ですよ!


34 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 17:01:14 ]
>>29
にわかだな
MSは速攻対応するに決まってるだろ

ただしバグだらけ

35 名前:デフォルトの名無しさん [2007/10/09(火) 17:02:05 ]
乳首ポチポチおxんこスリットクリトリス!?

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

37 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 20:08:28 ]
boostに#ifdefの嵐が

38 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 12:35:20 ]
また対応に数年かけるのは目に見えてるぜ・・・

39 名前:デフォルトの名無しさん mailto:sage [2007/10/10(水) 18:23:55 ]
そうこうしてるうちにC++1xがでるな。

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

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



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


42 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 08:24:12 ]
ところでTRはいくつまで出るんだ?
3ぐらい?

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

44 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 17:50:13 ]
TR?は一般人は無関係。

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

46 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 19:36:01 ]
>>43
working draftではもうstdに入ってる>>16

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

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

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

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

48 名前:デフォルトの名無しさん mailto:sage [2007/10/11(木) 21:24:46 ]
名前空間の階層化宣言て入ってるんだっけ?

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

みたいな奴

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

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



51 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 01:27:50 ]
>>47
C++はパッケージがないしなあ。



52 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 06:44:24 ]
>>48
それ、便利だよなぁ。あったら。

53 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 07:06:19 ]
>48
提案はあったようだけど
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1524.htm
Not ready for C++0x になってる。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2389.html

54 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 17:15:28 ]
ドラフトに入ってる機能が削除される可能性ってあるのかな?

55 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 17:39:48 ]
修正不能な大きな穴が見つからない限りない、
つまりない。

56 名前:デフォルトの名無しさん mailto:sage [2007/10/12(金) 18:29:10 ]
d

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

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


59 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 00:04:35 ]
[]演算子にしたらbidirectional iterator/rangeとか困る。

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

でもnullptr不要には同意。



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

62 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 00:18:02 ]
intXX_t系をしっかり実装してあればいい。(x=>数字)

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

64 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 02:14:03 ]
 こ こ ま で の レ ス は 、 す べ て 『 気 の せ い 』 で す 。

65 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 02:51:43 ]
そんなことじゃないかと思ってたよ

66 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 04:42:02 ]
MSと何の関係があるのかと…

67 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 09:17:37 ]
nullptrに特殊化させたい。


68 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 09:28:11 ]
>>67
それは nullptr がテンプレートとして実装されていればいいのにってこと?

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

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

70 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 12:11:25 ]
>>64
WindowsがLLP64モデルを採用してるからじゃない?



71 名前:70 mailto:sage [2007/10/13(土) 12:38:51 ]
アンカーミス
>>64>>66

72 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 12:44:48 ]
ttp://herbsutter.spaces.live.com/

73 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 16:29:41 ]
さったーさんはCLIの世界へ逝かれました。

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


75 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 17:05:59 ]
でもさ、C++/CLI って Java 厨がうざいこと言ってきたときには便利じゃね?

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

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

78 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:29:45 ]
#define nullpo nullptr

79 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:32:11 ]
>>78
誰かやると思った

#if defined nullpo
#define ga nullpo


80 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:37:10 ]
null
はダメなのか・・・
やっぱり誰かが使ってそうだから?



81 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:46:52 ]
>>79
それだと全てのgaがnullpoに置換されないか?

82 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 21:51:51 ]
#endif

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


84 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:25:20 ]
やんぬるかな

85 名前:デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:28:42 ]
病ん(でる)null?

86 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:59:02 ]
VC++ でも __null じゃなかったっけ?

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

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

89 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 04:08:52 ]
>>88
それなに?
C#の event みたいなやつ?
デリゲート使ってるやつ。

90 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 05:31:31 ]
はわわわわ



91 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 08:59:17 ]
>>86
/clr付ければnullptrが使える。

92 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 09:00:16 ]
>>87
どうせ
#define nullptr 0
ってなるだけだろ。

93 名前:デフォルトの名無しさん mailto:sage [2007/10/14(日) 09:37:57 ]
>92
それだと提案されてる内容を満たさない。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2214.pdf
nullptr の型は nullptr_t であり整数値として扱うことができない。

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

94 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 21:52:03 ]
C
C++ (c plus plus)
C# (c charp)
C* (c anal)
C@ (c gurochikuvi)

95 名前:デフォルトの名無しさん mailto:sage [2007/10/16(火) 22:06:33 ]
C(i) (c omeko)

96 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 00:05:20 ]
Cω (c sorewa watashi no oinarisan da)


97 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:09:25 ]
いや、わかって書いているとは思うんだが、一応。

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

98 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:16:47 ]
まあ、>>97さんて野暮なお方

99 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 03:21:29 ]
外人って ω とか見てもへっちゃらなのかね。変なものを想像したりしないのか?w

100 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 03:36:30 ]
2ch見すぎ



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

102 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 08:36:11 ]
スレ違いかも知れないが、
boostにある日付を扱うライブラリはだめ?

103 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 09:45:29 ]
いや、それが何で C++0x に追加されないのかな、と。

104 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 10:46:04 ]
変に入れるとローカライズがらみでJavaみたいにぐたぐたになるからじゃね?

105 名前:デフォルトの名無しさん [2007/10/17(水) 11:10:13 ]
std::time_get じゃ不足?

106 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 11:37:03 ]
あ、こんなのがあったんだ・・・。
別の場所読んでた。

107 名前:デフォルトの名無しさん mailto:sage [2007/10/17(水) 13:06:28 ]
な、なんだって〜!
このスレに来るの少し早いんと違うんかと
無いのかね、言いたいだけと違うんかと

108 名前:デフォルトの名無しさん mailto:sage [2007/10/18(木) 17:35:17 ]
>>107
日本語でおk

109 名前:デフォルトの名無しさん mailto:sage [2007/10/19(金) 12:14:52 ]
このスレ的には
C言語でおk

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



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

112 名前:デフォルトの名無しさん mailto:sage [2007/10/19(金) 14:15:54 ]
自分のこと?

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

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

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

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

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

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


116 名前:デフォルトの名無しさん mailto:sage [2007/10/19(金) 23:42:39 ]
>114
Perl モジュールだけど、
ttp://search.cpan.org/~lembark/Quantum-Superpositions-2.02/lib/Quantum/Superpositions.pm
と同じような記法で良ければ今でもライブラリとして実現できそうな予感。

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

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

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

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

119 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 10:42:50 ]
レベル低いのが混じってるなぁ

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



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

122 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 12:40:26 ]
>>121
日本語でok

123 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 12:44:54 ]
お前の理解力が無さ過ぎるだけ

124 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 12:47:08 ]
俺もわかんね
具体例でおしえてください

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

126 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 12:56:45 ]
俺もわからん

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

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

前者はboost::noncopyableとかかな


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

130 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 13:37:03 ]
それはコーダーの問題か。



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

132 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 13:56:27 ]
エスパーってほんと尊敬するよ。

133 名前:デフォルトの名無しさん [2007/10/20(土) 14:51:30 ]
www.open-std.org/jtc1/sc22/wg21/
News 2007-10-19: C++ Standard Core Language Issues List (Revision 51) is available

134 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 18:30:41 ]
コーディングのときにはヘッダファイルしかいらないだろ!

135 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 19:07:03 ]
ワーオ

136 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 19:38:39 ]
つまりコンパイラとリンカに問題があるんだな

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

138 名前:デフォルトの名無しさん mailto:sage [2007/10/20(土) 20:29:40 ]
         ____
       /      \    「ロリコン」に興味があるの?
      /  ─    ─\   変態っつーかキ○ガイじゃね?
    /    (●)  (●) \  こっち見んなよ
    |       (__人__)    |
     \      ` ⌒´   /

139 名前:デフォルトの名無しさん mailto:sage [2007/10/21(日) 00:44:34 ]
(゜д゜)(゜д゜)(゜д゜)

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



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

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

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

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

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

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

144 名前:デフォルトの名無しさん mailto:sage [2007/10/21(日) 16:12:47 ]
そりゃシネクドキだろ・・・って突っ込んで欲しかったのか?w

145 名前:デフォルトの名無しさん [2007/10/21(日) 17:08:26 ]
>>143

>sizeofを使った特殊化
kwsk

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

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

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

148 名前:デフォルトの名無しさん mailto:sage [2007/10/21(日) 21:20:39 ]
これは何ともハイレベルなC++のスレですね^^

149 名前:デフォルトの名無しさん mailto:sage [2007/10/21(日) 21:28:11 ]
>143
ttp://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
特殊化とはちょっと違う文脈な気もするけどこれですか。

150 名前:デフォルトの名無しさん mailto:sage [2007/10/21(日) 23:00:47 ]
ロリコンの女ww



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

152 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 01:19:30 ]
Wikipediaをwikiって言うの以上に無理がある気が…

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

154 名前:デフォルトの名無しさん mailto:rvalue reference [2007/10/22(月) 01:50:40 ]
>>153
誰だよ?w



155 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:35:35 ]
俺俺、俺だって

156 名前:デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:53:16 ]
おまえかあ

157 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:11:43 ]
>>154
平清盛の大叔父の平清岡だよ。
ちなみに弟は平盛岡。

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

こういう安全機構(といっても構文上の)が C++ にも必要じゃね?

159 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:38:33 ]
賛成

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



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

162 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:29:32 ]
>>161
まじっすか〜?
Visual C++ 2005 で警告をレベル4にしても出なかった希ガス

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

164 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 15:34:17 ]
>>163
-Wshadow かな?



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

166 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 15:58:32 ]
なぜ?

167 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:16:12 ]
>まずい設計の尻拭いの機能は言語仕様にはないほうがいいと思う

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

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

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

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


169 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:53:40 ]
1と3は矛盾
4は丸っきり逆

170 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:55:24 ]
なぜ?



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

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

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

172 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 19:14:01 ]
www.blender.org/documentation/intranet/conventions/codingstyleguide.html
によると、gcc でのお勧め警告フラグは、
* -Wall, -W
* -Wshadow
* -Wpointer-arith
* -Wbad-function-cast
* -Wcast-qual
* -Wcast-align
* -Waggregate-return
* -Wstrict-prototypes
* -Wmissing-prototypes
* -Wmissing-declarations
* -Wredundant-decls
* -Wnested-externs

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

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

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

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

175 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:25:50 ]
>>165

1.隠蔽不可
2.隠蔽可能&明示不要
3.隠蔽可能&明示必要

どれがいいと思ってるの?1?2?
自分は3だけど

176 名前:165 mailto:sage [2007/10/23(火) 21:34:33 ]
熟考はせずにいうけど
継承時には 1
そのほかでは 2
が良さそうい思う

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

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

177 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:53:21 ]
そうは思わない人がC#を作りましたと

178 名前:デフォルトの名無しさん mailto:sage [2007/10/24(水) 00:54:02 ]
>>173
巨大なクラスがどうこう、って話だったっけ?

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


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

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



181 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 00:16:13 ]
C++ って久々に使うと結構楽しいね。

182 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 03:55:26 ]
>>172
Visual C++ 2005 で同等の強さの警告出させたいものだ。

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


183 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 07:57:24 ]
boostのvaultのやつまで使用おkなら楽しいよ

184 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 08:01:26 ]
C++0xが来ればもっと楽しくなるだろうな。

185 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 09:10:11 ]
ConceptGCC楽し
はやくこいこいC++0x

186 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:06:50 ]
楽しいと言うかコーディングが楽になりそうでいいね。

187 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 11:06:48 ]
特に auto が。

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

189 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:41:15 ]
>>188
タイピング量を減らしたいからって理由で使ってたら可読性がワッシワッシ下がったのが俺
今じゃまったく使ってない

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

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



191 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:08:42 ]
イテレータを使うときにちょっと楽じゃね

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

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

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

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

195 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/25(木) 22:36:44 ]
そのときはまたboostが以下略

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

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

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

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

199 名前:デフォルトの名無しさん mailto:sage [2007/10/26(金) 00:51:25 ]
>>198
標準関数の引数並びは規定されてるだろ。
それ、どっから出てきた話?

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



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

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

202 名前:199 mailto:sage [2007/10/26(金) 01:44:20 ]
>>201
シグネチャの意味で「引数並び」って言った。でもやっぱり決まってるでしょ。

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

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

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

204 名前:199 mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/26(金) 15:28:41 ]
>>203の言ってる意味がよくわからん
誰かコードに落としてくれ

206 名前:デフォルトの名無しさん mailto:sage [2007/10/26(金) 16:23:30 ]
>>205
Exceptional C++ Styleにそのまま例が載ってるじゃん

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

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

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

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

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



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

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

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

213 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 01:09:12 ]
>Exceptional C++0x Style でまた書かれるぞ
また落とし穴が増えるのかよ
          ∧_∧
         ( ´Д⊂ヽ

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

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

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

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

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

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

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

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

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

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



221 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 13:58:08 ]
C++1xスレでも立てるか?

222 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 14:20:42 ]
>>220
じゃあどういう修正なら納得するかkwsk

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

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

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

224 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 16:57:44 ]
>>223
そりゃ204全削除できれば一番いいけどね。

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

225 名前:デフォルトの名無しさん mailto:sage [2007/10/27(土) 18:14:05 ]
>>224
なんで「デフォルト引数使えない」なんて話になるの?

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

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

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

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

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

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


229 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 01:47:11 ]
Expression Templateを使おうが、Boost Lambda使おうが、ショートカット評価は不可能だよ。



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

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

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

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

234 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 08:12:40 ]
0xにはDのlazyみたいなものないの?

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

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

236 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 13:16:45 ]
次の言語仕様に中傷メソッドでも入れる勢いだなおい

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

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

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

239 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 14:27:02 ]
ちょっと言い過ぎた。

240 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 21:06:43 ]
ぬこぬこ



241 名前:デフォルトの名無しさん [2007/10/28(日) 23:35:22 ]
coutって、printfより使えないと思うのは俺だけ?

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

243 名前:デフォルトの名無しさん mailto:sage [2007/10/28(日) 23:53:31 ]
こんなこともできるよ的なものじゃないの?

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

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

245 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:35:59 ]
しかし型安全性は欲しいところ

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

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

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

249 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 00:50:16 ]
怖くないよー怖くないよー

250 名前:デフォルトの名無しさん [2007/10/29(月) 01:14:46 ]
printf問題は書式文字列リテラルっていう文字列と別のリテラルを作って
コンパイラが型チェックするようにするのが結局いいんじゃないかなー



251 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 01:19:58 ]
実際、多くのコンパイラがそれに近い扱いで型チェックしてるわけだな

252 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 05:15:01 ]
stringstream でええやん。

253 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 20:02:05 ]
>>248
boost::formatは別にコンパイル時にややこしいことをしてないと思うけど。
そんなことをする意味がない。

254 名前:デフォルトの名無しさん [2007/10/29(月) 21:34:04 ]
>>253
仕組み説明してYO


255 名前:デフォルトの名無しさん [2007/10/29(月) 22:56:21 ]
C++0x 2なんてつぶれろ

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

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

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


256 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:10:53 ]
むしろわかりやすくなる方向に行ってると思うけどね

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

257 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:17:18 ]
確かにややこしすぎる感じはする
よく使われる主要な言語が難しいのは歓迎だけど、わかる人間の価値が高まるし
でもこの勢いだと主要でなくなりそう

258 名前:デフォルトの名無しさん mailto:sage [2007/10/29(月) 23:21:14 ]
右辺値参照を理解できない人が多そう

259 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:06:35 ]
>>255
よしきた
俺たちだけで勝手に遊ぶよ

260 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:06:49 ]
>>256
>むしろわかりやすくなる方向に行ってると思うけどね

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



261 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:10:58 ]
ややこしいのが嫌いな人には、今は代わりになる言語があるからね

262 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:15:56 ]
それよりいつになったらC++はまともなオブジェクト指向言語になるのかと

263 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:17:38 ]
いまのSTLすら理解できない人には
functionやbindは無視されるだろうね

264 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:21:24 ]
>>263
bint1st, bind2nd, mem_fun, ptr_funなんかよりbindのほうが全然わかりやすい件について。

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

だったら同意。


265 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:26:09 ]
>>264
bind1stとかについては同意

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

266 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:29:13 ]
関数ポインタよりfunctionの方が全然分かりやすい件について

267 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 00:34:18 ]
>>265
うん。大丈夫。以前経験した現場だと、C++初心者レベルのみんながboost::bindを使いまくって
プロジェクトが崩壊しかけたたよーん。

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


268 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 01:56:25 ]
bindでポインタ持ち運んだらえらいことになりそうだ

269 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 02:03:57 ]
C++初心者はC++なんて使っちゃ駄目なのだ
つまりC++を学ぶときは、いきなりC++の達人にならなければいけない

270 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 02:06:12 ]
んなこたぁ〜ない



271 名前:デフォルトの名無しさん [2007/10/30(火) 02:17:34 ]
www.open-std.org/jtc1/sc22/wg21/
News 2007-10-28: The 2007-10-post-Kona mailing is available
News 2007-10-28: The C++ Standard Library Issues List (Revision 52) is available

272 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 05:11:26 ]
便利な機能があるからって使わなきゃいけないということはない。
bindやconceptなんてライブラリビルダが使ってればよろしい。

273 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 08:21:15 ]
まさにC++は男坂

274 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 09:18:28 ]
いやbindは便利だよ
沢山引数を指定する関数のある引数だけを変えながら実行する場合、さらに具体的にいえば
初期化ルーチンで動作モードを調べながら実行するときとかよく使うし

275 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 12:33:27 ]
>>272
そのレベルで使うならC++の必然性が少ない。言語は他にいっぱいある。

276 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 12:57:35 ]
ぷろぱてぃというかげったーとかせったいみたいなのは
0xではいるんですか?はいらないんですか?
どうなんです?heheheh

277 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 13:21:27 ]
なんか変なのキタ

278 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 14:53:31 ]
下駄と雪駄?

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

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

279 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 17:00:46 ]
それだとプロパティごとにクラス作らなきゃという気がする

280 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 17:19:19 ]
>>279
プロパティは概念上、ダイレクトな生メンバとは違うものだから記述方法も違ってくるのかなと

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



281 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 18:47:44 ]
D言語マンセー

282 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 18:49:20 ]
CよりDがEけど結局F#

283 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 20:20:20 ]
Zもすでにあるみたいだし究極言語「ん」とか作ろうぜ

284 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 21:17:02 ]
プログラム言語じゃなくて仕様記述言語だけどな。

285 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 21:20:42 ]
ん、いいねぇ。

286 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 22:06:40 ]
>>278
プロパティの代用はできねーよ。

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

287 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:06:29 ]
>>286
getterとsetterが言語仕様に入るだろうか?という話をしているのに
なぜクラスのサイズという実装上の問題の話に摩り替わってしまうのだろうな?

288 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:23:14 ]
>>287
はぁ?頭大丈夫か?

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

289 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:25:26 ]
>>288に一票

290 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:57:08 ]
じゃあ俺は>>287に100億万票



291 名前:デフォルトの名無しさん mailto:sage [2007/10/30(火) 23:57:24 ]
>>288
正論だが物言いがよくない

292 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:15:31 ]
別に君は見えないままでいいんじゃない?
他の人は見えてるから問題無いし、君という一人の阿呆が困ったりムカついたりしても
誰も困らないし。

294 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:28:25 ]
個人攻撃をする間で関数の一つでも書こうぜ…

295 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:29:16 ]
>>293
>誰も困らないし。
>>292が困る件について

296 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:38:40 ]
>>292
それはお前の脳みその中だけで通用するパカ論理だということを忘れてはいけません。

297 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:41 ]
クラスのサイズが増える、って具体的に何が増えるの?マジで。

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

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

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

298 名前:デフォルトの名無しさん [2007/10/31(水) 01:00:34 ]
レベルひっく〜

299 名前:デフォルトの名無しさん [2007/10/31(水) 01:07:11 ]
   ∧_∧  / ̄ ̄ ̄ ̄ ̄
  ( ´∀`)< オマエモナー
  (    )  \_____
  | | |
  (__)_)

300 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:32:05 ]
たとえ内容がマトモでも罵倒口調だと読む気がしない



301 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 02:10:04 ]
バカばーっか。

302 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 02:26:48 ]
じゃ俺ははらたいらに3000点

303 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 03:38:05 ]
もうお亡くなりになられました。

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

304 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 08:50:15 ]
>>297
パカ極まるなお前。

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

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

305 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 09:40:43 ]
>>304
あなたの意見を私が証明しなければならない、というのは筋が通りませんが…
sizeof にコード量が反映されるという処理系は知りませんよ?私は

306 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 09:41:41 ]
>>304
sizeof は変わらないでしょう。

307 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 12:21:10 ]
違う言語で比較してどうすんの?

309 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:45:53 ]
もともと(C#にあるような)プロパティが欲しいって話じゃなかったっけ

310 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:56:59 ]
syntax sugar 以上の意味があるの?



311 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 13:59:14 ]
参照の分メモリを節約できるといいたんじゃないの

312 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 14:48:07 ]
>>307
cast operator と assignment operator では代用できない、という話ではなかったのですか?

314 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 15:35:48 ]
漏れもデータメンバが増えるようでは setter と getter の
シンタックスシュガーの代用としては不適格だと思うが・・・

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

315 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 15:42:33 ]
getとsetが予約語になったら楽しい

316 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 17:33:19 ]
>>316
Dはそれでいいだろうが、C++で bind するとき大変そうだからヤダ

318 名前:デフォルトの名無しさん [2007/10/31(水) 18:38:23 ]
Dとかイラネェ

319 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:03:55 ]
template <typename _T>
class property {

320 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:04:28 ]
なかったことにしよう



321 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:49:38 ]
それ、publicメンバ変数に比べて何か嬉しいことあんの?

323 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 20:47:09 ]
なんもないw
default constructibleじゃないとだめだし
マジメなsetter/getter実装しようともったら結局なんらかの参照が必要になる

324 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:35:04 ]
C++ : 不便に感じる糞仕様がそれなりに多い
D : 妥協ライン
C# : マイコーソフトの柵
C++0x : 期待と不安の境目

325 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:57:53 ]
>>305
いつ誰がコード量が増えると言ったんだ?
筋が通ってないのはお前だよ。


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

326 名前:デフォルトの名無しさん mailto:sage [2007/10/31(水) 23:05:08 ]
一応こんな提案あったみたいだけど、Not ready for C++0x, but open to resubmit in future になってる。

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

327 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 01:57:51 ]
プロパティ話は Boostスレpart4 でもやってたやん
もういいよ

328 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 07:48:40 ]
>>327
それ言ったらほとんどのスレッドが終わっていく…

329 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 19:46:00 ]
>>326
C++1x?が待ち遠しくなった。

330 名前:デフォルトの名無しさん mailto:sage [2007/11/01(木) 20:32:27 ]
>>326
プロパティ1つ追加するごとに、ポインタ分だけオブジェクトのサイズが膨らむのか



331 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 03:20:43 ]
そもそもプロパティなんていらね

332 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 10:42:00 ]
たしかにいらね。
そのまま公開するんなら public メンバ変数にするさ。

333 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:02:23 ]
下駄と雪駄にfuck…もといhookかけられるならそれなりに有用になるかも

334 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:11:10 ]
hook をかけないプロパティになんのいみがあるのかと問いたい

335 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:23:07 ]
なんとなくオブジェクト指向している気になれるというなかなかぬるぽな効果があります

336 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 11:57:04 ]
プロパティいらねぇから、組み込み変数とPODに対してだけでいいから
変数の値が更新されたときにフックかけれるようにして欲しい。

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

みたいな。

337 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 13:39:58 ]
いつのまにやら日本語版にもC++0xの項目が

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

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

338 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 13:50:31 ]
項目ができてから1ヶ月余り?
それにしてはすごい量だな

339 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 13:58:51 ]
項目ができてから書き始めるわけじゃないですからw

340 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 21:00:15 ]
constexprにあらゆる再帰が不可能ってまじ?
再帰テンプレートとかも?



341 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 21:20:46 ]
>>336
それかっこいいね。
でも、俺の頭はまだ AOP に対応してないから、用途が思いつかん・・・orz

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

342 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 22:23:43 ]
>>338
履歴によれば、初版は英語版の翻訳。
ja.wikipedia.org/w/index.php?title=C%2B%2B0x&action=history

343 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 22:28:18 ]
へーすごいな
感心した

344 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 22:32:08 ]
翻訳乙

345 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 22:36:47 ]
どおりで訳文チックだとおもった

346 名前:デフォルトの名無しさん mailto:sage [2007/11/02(金) 23:07:38 ]
>>336
MyWindow win;
RECT *r = &win.windowRect;
external_library_function::foo(r); // rを弄る

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

347 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 00:17:33 ]
生のポインタの代わりに代入法・参照法を記述したサンクを渡せば桶

348 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 00:26:04 ]
>>347
生のポインタはいつでも取れるんだから、何の安全弁にもならないし、
カプセル化になってない気がするけど

349 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 00:34:06 ]
だから、生のポインタは取れなくて、メンバのように見えるものが欲しいという話なのでは?

350 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 00:36:35 ]
それこそプロパティではないか



351 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 00:41:28 ]
>>336 は「プロパティいらねぇから」と言いつつ、まさにプロパティが欲しいと言ってんだと思うっす。
対称性を考えれば参照時のフックも欲しくなるっす。

352 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 08:06:03 ]
じゃあ、右辺値、左辺値参照のoperator導入な。


353 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 08:40:08 ]
operator && () は入るんでしょ?

354 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 16:00:14 ]
>>353 すでにあるわけだが、何のことかな?

355 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 17:01:51 ]
operator && (void) ってokなの?

356 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 18:08:58 ]
>>354
既に無いわけですけど、何のことかな?

357 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 18:37:12 ]
二人の「既に」の時間が別な件について

358 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 18:46:55 ]
operator && って、あれだろ、オーバーロードするとショートサーッキットが
利かなくてはまるっていう。

359 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 18:51:32 ]
>>358
ttp://ja.wikipedia.org/wiki/C%2B%2B0x

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

360 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 19:03:44 ]
operator && があるかないかなら、あるだろ。常考。



361 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 19:18:50 ]
>>359
右辺値参照のために && が使われるようになることは知ってるけど、
operator && は昔から別の意味である。

362 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 20:23:18 ]
いいから検索しろ、な

363 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 21:14:27 ]
検索しても、 operator && について何が言いたいのかさっぱりわからない。

364 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 21:28:44 ]
右辺値参照の&&はそもそもoperatorじゃなくてkeywordってこと?

365 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 21:43:51 ]
&& を右辺値参照だけと勘違いしてる奴初めて見た。

366 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 22:39:54 ]
>>365
物言いを直さないと大人になったとき苦労するよ

367 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 22:49:15 ]
>>366
オマエモナ

368 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:00:40 ]
切り返しになってないなぁ。うん。

369 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:13:09 ]
うん

370 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:23:41 ]
もう大人だもんな



371 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:53:46 ]
>>364
そもそも今までだって構文上、型名の*や&、[]、関数の()などは演算子ではない。
そこに&&が加わるだけ。


372 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:55:27 ]
&&じゃなくて@とかにしなかったのはなんでだろ

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

373 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 23:58:55 ]
参照の記述に近いことと、字句解析に変更が要らないのがいいんじゃない?

374 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 00:07:08 ]
>>372
それもあるだろうけど
新たなトライグラフが必要になるからだと思う

375 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 00:48:57 ]
トライグラフは廃止の方向じゃなかったっけ

376 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 00:51:43 ]
でもダイグラフとか代替表記とかあるし。

377 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 00:52:56 ]
そんな提案があったの?
ドラフト(N2369)にはしっかり記述があるけど

378 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 01:35:33 ]
しかし@がない文字コードってあるの?

379 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 01:43:24 ]
>>378
っていう疑問がでてきて調査が必要になるので
新しい記号の導入はできるだけ避けたいと

380 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 02:10:37 ]
既に無いわけですけど、何のことかな?
「既に無い」にめっちゃ吹いたw



381 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 07:31:58 ]
#や[]にtrigraphがあるくらいだから油断禁物だな。
しかし@がないシステムは、dmr??.bell-labs.comとかやってんのかね。

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


382 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 08:35:36 ]
>>381
つっこむところ、そこだけじゃないよ。

383 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 10:10:45 ]
トライグラフ・ダイグラフって文字コードじゃなくて、
キーボードに対応するキーがない場合、ってのを問題にしてるんじゃね?
例えば日本語環境だとウムラウト付き文字を入力するの面倒だろ。

384 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 12:34:47 ]
@ が無いシステムじゃメールが使いにくそうだねw
今となってはソースは Unicode、入力法はエディタやインプットメソッドで勝手に解決しろ、でいいと思う。

385 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 14:44:05 ]
@なんて使われたらVCのマングリングが崩壊するから駄目です><

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

386 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 16:26:39 ]
>>385
なんで VC のマングリングが崩壊?
リンク時のシンボルと演算子としての @ の関係が分からん。

387 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 18:06:56 ]
>>378
ISO/IEC 646的には「#$[\]^{|}~@`」の12コードポイントが別文字になりうる
参照:ttp://ja.wikipedia.org/wiki/ISO/IEC_646

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

388 名前:デフォルトの名無しさん mailto:sage [2007/11/04(日) 21:00:39 ]
日本では改行は「¥n」と覚えてるし、英国人は「£include」で慣れているしね。
まあ過去の遺産でしょ。>トライグラフ・ダイグラフ

389 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 11:17:05 ]
けど、ソースがUnicodeになると、その慣れが一気に負の遺産に…

390 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 20:47:26 ]
え?ソースをunicodeで書いても解決しないでしょ?

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



391 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 21:11:47 ]
>>390
簡単に言うと、君の使ってるのが偽Unicodeだってこと
ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C

392 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 21:20:36 ]
いい機会なんで円記号はバックスラッシュに戻してほしかったな

393 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 22:42:09 ]
>>391
は?よく読めよ。何が偽だよ。

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



394 名前:デフォルトの名無しさん mailto:sage [2007/11/05(月) 23:18:29 ]
逆に言えば、U+5Cにバックスラッシュのグリフを持ったフォントを使えば、
バックスラッシュとして表示される。

395 名前:デフォルトの名無しさん mailto:sage [2007/11/06(火) 00:00:08 ]
まあその辺りに興味ある人は文字コードスレで。


396 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 08:45:15 ]
フォントスレで事足りるな。

397 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 12:01:57 ]
>>393
「簡単に言う」のなら、それは「偽Unicode」だろwww

398 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 13:31:42 ]
>>393
cout << "その本は500\です。\n" << endl;

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

399 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 19:07:29 ]
VC2005でinttypes.hがつかえねーーーーーーーーーーーーー誰か代換え案ください・・・2008?

400 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 19:36:04 ]
自分で作る



401 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 19:55:58 ]
あGCCから持ってきました

402 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 19:59:48 ]
Windows板行けよ。
C++0xに関係ないし。

403 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 22:26:47 ]
boostつかえ

404 名前:デフォルトの名無しさん mailto:sage [2007/11/07(水) 22:28:18 ]
conceptは間に合うんだろうか

405 名前:デフォルトの名無しさん mailto:sage [2007/11/08(木) 04:58:25 ]
あ、concept は余裕で間に合うよ。安心しといて。
それより問題なのは export なんだよ。実は。

406 名前:デフォルトの名無しさん mailto:sage [2007/11/08(木) 10:15:11 ]
exportは実装されて実績も出てるが何が問題だろうか、と考えるに
メジャーベンダが「ヤラネ」と言い出してるあたりか
VCとgccは入れないんだよな、bccは最新版で入ってるらしいことは聞いた

407 名前:デフォルトの名無しさん mailto:sage [2007/11/08(木) 16:38:53 ]
extern inline とかな

408 名前:デフォルトの名無しさん mailto:sage [2007/11/12(月) 21:22:45 ]
concepts抜きでは送り出さんと書いてあるね。
ttp://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!330.entry

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

409 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 16:32:10 ]
vs2008でどのくらい対応するんだろう・・・

410 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 18:52:18 ]
vs2012くらいにならないと対応しないんじゃね?



411 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:39:50 ]
g++0xとかになっちゃうのかな。
いままで3文字でやってきたのがちょっと気持ち悪い。
でもg0xとかだったら泣く。

412 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:43:32 ]
VC++9.0でc++0xを実装するみたいだね

413 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:45:11 ]
>>411
普通にg++ , C++ なりclなりでいいと思うんだが... C++/CLIなんていう類似品と違って正真正銘の時期標準規格なんだぞ?

414 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:45:44 ]
拡張子が .cpp0x になってたら厭だな

415 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:46:51 ]
むしろ全てのコードの拡張子は.txt

416 名前:デフォルトの名無しさん mailto:sage [2007/11/13(火) 23:57:29 ]
Content-Type: text/x-cplusplus0x-source; charset=utf-8
なんてメタデータが必須になります

417 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:34:36 ]
C++0xはC++の新しいバージョンの仮称ってだけで
決まった後はただのC++だろ

418 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:36:10 ]
無料のC++だよね

419 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:42:19 ]
>>417
C90, C95, C99みたいに言葉は残るはず。
C++98, C++03, C++09かな。

420 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:54:06 ]
>>413
CLIはISOに蹴られたんだったな



421 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 00:59:09 ]
C++1x

422 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 01:00:38 ]
ISO/IEC 14882:201x

423 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 03:37:54 ]
来年の2月までミーティングないのか。
こりゃ本当にC++0aになりそうだなぁ。

424 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 03:57:33 ]
C++0x0a
にすれば問題ないじゃないか

425 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 09:04:35 ]
ぶっちゃけたところ、C++0xはメインストリームで使われる言語になれるのでしょうか?
なれるとしたら何年後くらいだと思いますか?

426 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 09:58:57 ]
なれないだろうね。
組み込みとか、system layerの低いところ、e.g. OS kernel、では、
今後C++を使う例がどんどん増えていくと思うけれど。

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

427 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 11:15:53 ]
Embedded C++の覚醒と聞いて飛んできました

428 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 11:59:57 ]
Embedded C++?どこにそんな情報が!?マジなら知りたい。

429 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 13:07:33 ]
いやごめん、426の話を受けた冗談

430 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 13:09:48 ]
>>425
まず、メインストリームが何かを定義してもらおうか



431 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 13:26:00 ]
世間的には既に C++ がメインストリームではないからな。w
C++ 族(?)の中では C++0x はメインストリームになると思うが。

432 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 14:16:14 ]
Embedded関係ないのか・・・。
boost使えずやきもきしてたから小躍りしてしまったぞーーー!

433 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 14:29:17 ]
Darwinのデバドラ・フレームワークのIOKitがEmbedded C++でしょ。
多重継承、template、name spaceないもん、boostは無理でしょw

434 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 14:43:56 ]
難攻不落の女を口説いて落とすかのような面白さがある言語としてだな

435 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 14:53:40 ]
それでもBoost.Preprocessorなら…Preprocessorならなんとかしてくれる

436 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 15:23:22 ]
Embedded C++って本当に馬鹿な規格だよな。
フル規格のC++で、開発部隊毎にコーディング既約作ればいいだけなのに。
しかもまともなコンパイラすら作れないメーカが発起w


437 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 15:30:24 ]
template使えないC++に用はありませんよねー

438 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 15:31:55 ]
しかしEmbeddedでないC++コンパイラを作っても開発にコストがかさんで売れるかどうか。
そこらへんの妥協点を定めたのがEmbeddedなんじゃないの?

439 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 15:58:51 ]
そんなひ弱な開発部隊が作ったコンパイラなんか使いたくないよ。
Cでさえ、マイナーコンパイラは悲惨だったのに。

440 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 16:12:20 ]
いくら俺がネタにしたからって、おまいら叩きすぎです



441 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 18:41:18 ]
>>436
同意。組み込み用ならランタイムが軽くなる仕様を考えるべきなのに、なぜかコンパイラ作りが
楽になる仕様にしたという馬鹿言語。
おそらく日本のマイコンメーカのソフト開発部門の能力に合わせたのだろう。w

442 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 18:45:56 ]
正直typeinfo以外にランタイムに問題になるものないでしょ。

443 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 18:51:05 ]
自分で商用並みに完全な準拠コンパイラを作るにはどれぐらい手間かかる?

444 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 18:56:14 ]
5人年くらいはかかるんじゃね。

445 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 19:57:26 ]
>>441
ミニマムな規格にしていろんなCPU用に処理系が用意されるように、
ってのを目指したんじゃない?

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

446 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 20:28:06 ]
templateのexportを実装するのに3人年かかったらしい

447 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 21:03:44 ]
込め合うの開発部隊って何人いるんだろ。

448 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 21:31:26 ]
3人いるらしーよ。

449 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 21:42:16 ]
少な!
でも多ければいいってもんでも無いか…

450 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:09:23 ]
ラムダ式とクロージャが間に合うと嬉しいな



451 名前:デフォルトの名無しさん mailto:sage [2007/11/14(水) 23:47:46 ]
ラムダ式があるとサンプルプログラムが書きやすそう

452 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 02:24:43 ]
あれ?ごめん、クロージャなんて入る予定あるの?

453 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 02:45:47 ]
tr1::functionの事なんじゃまいか

454 名前:453 mailto:sage [2007/11/15(木) 02:51:08 ]
あーなんか言い方おかしい…
ラムダとfunctionで似たような事ができるよってだけなのかな

455 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 08:47:34 ]
>>452
ラムダ式の <&> で始まるやつのことじゃない?

456 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 08:48:28 ]
functionってただの関数オブジェクトだよね?

457 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 09:10:39 ]
>>455
やべぇ。また知らないものが出てきたぞ。
ラムダ式で <&> で始まるやつとやらの概要を教えて。

458 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 13:35:38 ]
n2329の「7.1 The <&> form」読んでくれ。
半ページしかないから。
あとついでにn2413の「6.1 The <&> form」も。

n2329がgeneric版、n2413がmonomorphic版。


459 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 18:10:54 ]
>>458
さんくす。
なるほどー。ただものじゃないな・・・この仕様。
ラムダ導入って単にちょっとした無名の関数を書けるだけかと思ってたけど、
実はちゃんとクロージャしてるんだね。
これ実装できるかねぇ。というかまず proposal が通らないと始まらないか。

460 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 20:17:39 ]
とはいっても関数オブジェクトを手軽に書くための糖衣構文だけどね
でも喉から手が出るほど欲しかった甘さだ



461 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 20:19:52 ]
ラムダ式+クロージャが導入されたらコードはどういう風に変わるの?
変化を適当な例で示してくれよよよ

462 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 21:06:25 ]
新キーワードを導入してもよかった気がするなあ

464 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 21:30:25 ]
>>462
おー確かに凄い…
それと
> <&> form
<>の事だったのね・・・

465 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 21:59:59 ]
>>463
「New function declaration syntax for deduced return types」
なんかを見ると <> の代わりに auto でも良さそうに思うね
auto の再利用が過ぎるか?

466 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 22:57:50 ]
auto はちょっと怖いよね。
便利だろうけど、乱用するとコンパイラしか真実を知らない
なんてことになりそう・・・

467 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:06:55 ]
あ、n2329は { <式. } だったっけね。

469 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:13:50 ]
うん、自分も記憶では式は () だったと思いながら
手近にあった n2329 を見ながら >>462 を書きました
n2413では () だね

470 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:17:33 ]
>>467
まあ、そうなのかもしれないけど
n1978なんかを見ると auto を使うのもありかなと



471 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:21:44 ]
mem_fun(&::f) より、<>(x){ x->f() } のほうが
インライン化が期待できる分、高速になる可能性があるな

472 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:36:52 ]
>>470
n2329でいろいろな案が提案されて、
n2413で今の形に落ち着いてる。

473 名前:デフォルトの名無しさん mailto:sage [2007/11/15(木) 23:39:54 ]
>>471
Fig. 1 Example translation on lamba function. 〜
を見るとそう簡単な話でもなさそうだけど。
自由変数含まない時は、translationを最適化しないと駄目。

474 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 01:02:11 ]
gcc拡張でクロージャできるけど、仕組みはあんな感じ?
でもあれマルチスレッドで破綻するよね。

475 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 02:23:58 ]
>>474
関数内関数の事?あれC++だとサポートされてないよ

476 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 06:14:03 ]
( ゚д゚)ポカーン

477 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 09:04:24 ]
>>475
そうそれ。
g++でサポート外とかそういうことじゃなくてC++0xでの仕組みの話し。



478 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 09:08:15 ]
>>477
lambdaは「式」なの。
レベル低すぎ。


479 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 09:15:24 ]
>>478
シンタックス上はそうだね。
で例えばどういうバイナリになるのかって話。
レベルの高い人、解説よろしく。

480 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 09:45:18 ]
translationがn2413載ってるから読め。
>>472に書いてあるだろ。



481 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 12:53:51 ]
>>404
conceptsの策定はもう終盤だよ。
規格に入れる文言を練っているところだもの。
Libraryのconcept化は今回やらないし。(n2322)

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


482 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:08:51 ]
@ とか新しい文字を導入できないんだろうか。

483 名前:デフォルトの名無しさん mailto:sage [2007/11/16(金) 22:15:25 ]
今更無理だろ
@と$はいろいろ好き勝手使われてるから

484 名前:404 mailto:sage [2007/11/16(金) 23:16:50 ]
>>481
たしかに08年の9月なら間に合うと思った
もうちょっと差し迫ってるのかと思ってた

485 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 15:42:44 ]
C++1xまでお預けか…

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

486 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 22:43:25 ]
コミュニティーからはconceptを使ったSTLの色々な実装が出てくるだろうね

487 名前:デフォルトの名無しさん mailto:sage [2007/11/17(土) 23:55:37 ]
もう出てますが…

488 名前:デフォルトの名無しさん mailto:sage [2007/11/18(日) 00:19:37 ]
詳細ごぼんぬ

489 名前:デフォルトの名無しさん mailto:sage [2007/11/19(月) 01:21:01 ]
遅ればせながらproposalやdefect reportを投げたい人向けのFAQ
ttp://www.comeaucomputing.com/csc/faq.html

490 名前:デフォルトの名無しさん [2007/11/23(金) 02:11:42 ]
コンストラクタのポインタって
出来ないのかなぁ。
例えば、

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

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

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

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



491 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 02:15:09 ]
コンストラクタを呼ぶファンクタなら、今でもBoost.Lambdaに色々ある。
boost.org/doc/html/lambda/le_in_details.html#lambda.construction_and_destruction

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

492 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 02:55:50 ]
テンプレートだと
void callback(new(*p)())
{
中略
}
void(*f)(new(*)())=callback;
f(&Type0);
f(&Type1);
って事は出来んだろ?
それと、
new (*p)=外部関数();
てな感じで別の翻訳単位のクラスを
取得するのも不可能だろ。

493 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 04:49:56 ]
placement newじゃだめなん

494 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 08:49:22 ]
Hoge hoge;
hoge.~Hoge();
new(&hoge) Hoge();

495 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 11:45:12 ]
>>493
>>494
プレスメントだと同じ翻訳単位に
クラスが存在しないといけないから
無理だよ。
それと、さっきレスで
new (*p)=外部関数();
って書いたけど正しくは、
new (*p)()=外部関数();

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

こんな感じでどうよ。

496 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 11:52:14 ]
どうよって言われても。このスレに書いたらC++0xに採用してくれるとか思ってんの?


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


497 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 11:58:10 ]
というか、C++の関数ディスパッチのこと理解してないの丸出し

498 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 12:35:52 ]
>>495
同じ翻訳単位にクラスが存在しなかったら、
作ったクラスを扱えんと思うのだが。

500 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 12:36:27 ]
×作ったクラス
○作ったインスタンス



501 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 12:52:18 ]
>>496
>C++0xに採用してくれる
>とか思ってんの?
確かにそうだが、実装されたい
機能の妄想ぐらいしてもいいだろ?
ここは2CHなんだから。

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

502 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 12:54:42 ]
妄想はチラシの裏とか自分のブログとかでお願いします。ここは2chですよ。w

503 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:02:18 ]
クラス定義をヘッダに書いてそれをインクルードすれば、
こういう使い方では翻訳単位なんて問題ないだろ。

504 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:22:08 ]
レベルが低すぎるから、他のスレに行って欲しいw

505 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:24:22 ]
別の翻訳単位のクラスでインスタンス化できるテンプレートって表現がよくわからんから解説してくれ

506 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:30:59 ]
>>501
は?
お前の案もクラス定義が必要なこといってますけど?それが?

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

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

507 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:34:18 ]
動的型言語でもなければクラス宣言がないとどうしようもないべ。

508 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:36:38 ]
つ スルー力

509 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 13:37:02 ]
なんかロシア語っぽい響き

510 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:03:03 ]
何かきったねーな。

512 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:06:17 ]
Createクラスをもっと複雑に作れば、
使う側はもっと簡易的に使うことも出来るけど、ま、それはきみへの宿題ということで。

513 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:08:32 ]
そんな簡単な事にいちいちえっらそうだなw

514 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:11:44 ]
客観的に見て、何も言わない癖に、文句だけはつけるお前の方が偉そうだと思う。

515 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:15:18 ]
客観的に見て、どっちも大して変わらない。

516 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:16:38 ]
文句や煽りしか出来ない低脳がウヨウヨ集まってきました。

517 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 14:44:43 ]
関数ポインタを返す関数を1つ作るだけで見た目綺麗になる。

518 名前:デフォルトの名無しさん mailto:sage [2007/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;
}

519 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:01:18 ]
>>506
面倒だから書きたくなかった
んだがしゃーない。

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

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

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

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

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

520 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:02:34 ]
>>518
その例は、そこだけ切り取れば綺麗に見えるだけ。

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




521 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:11:35 ]
>>510
それだと引数なしのオブジェクトしか
作れない訳だが

522 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:13:41 ]
javascriptならできるな、あれば面倒が減りそうではある

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

}

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

523 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:17:24 ]
>>521
Createを引数ありに改造するなんて簡単だろ

524 名前:519 mailto:sage [2007/11/23(金) 15:19:39 ]
一つ言い忘れた。この方法ならDLL間も渡せる。

525 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:20:36 ]
意味不

526 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:22:07 ]
>>524
templateでやってもDLL間でやり取りできる

527 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:24:10 ]
>>520
D言語なら渡せる(Foo delegate()型)。C++0xはシラネ。

528 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:24:52 ]
テンプレートとの本質的な違いは自分で生成関数を定義しなきゃいけないかどうかだけだよ

529 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:25:00 ]
>>527
callbackとして使えるか?

530 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:25:47 ]
>>529
D言語なら使える。C++0xはシラネ。



531 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:27:27 ]
>>523
コンストラクタ毎に作るのか馬鹿だろ。
それとも引き数一つ取って一時オブジェクト
を渡しコピーするのか?
いずれにせよ利口ではないな

532 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:27:40 ]
>>530
嘘を言うな。Dでも出来ないよ

533 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:28:33 ]
>>531
どちらも違う。というかそんな方法しか思いつかないって頭悪いだろ。

534 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:30:30 ]
boost::make_tupleみたいにデフォルトテンプレートパラメータ引数を使っての特殊化でなんとかするんだろう多分
多分vaultにあるshared_newみたいな感じで作るんだろうなぁというかそれしか思いうかばねぇや

535 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:30:44 ]
>>532
できるっての。試してみ。

536 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:33:54 ]
お前ばかだろ
いいやお前の方がばかだ
なんだと
以下略

537 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:37:20 ]
>>490から、無駄レスだな。

538 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:40:45 ]
>>537は今日から全人類の敵になった

539 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:43:08 ]
>>526
DLL側にテンプレートを作って
呼び出すのは実質不可能
テンプレートをインスタンス化
させておく方法もあるが非効率
いったいどうやるの?

540 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:45:08 ]
>>539
関数ポインタとして渡すんだよ。
なんでそんなこともわからないの?



541 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:49:50 ]
だからー間に一段自前の生成関数挟むかどうかだけなんだってー

542 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:51:43 ]
>>540
テンプレート関係ないじゃん
テンプレート使ってできる方法言えよ

543 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:53:33 ]
>>542
お前このスレの何を見てきた。テンプレート使ってるよ。

544 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:55:25 ]
馬鹿はスルーで。

545 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:57:12 ]
しかし現実には
スルーできないのが馬鹿の特徴の一つ

546 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:57:40 ]
>>543
関数のポインタによるDLL間の
やりとりにテンプレートが介在
する余地があると?

547 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 15:58:18 ]
>>546
はいはい。ありますよ。

548 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:09:57 ]
普通はファクトリクラスを作るけど、
それが面倒ってことなのかな?

549 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:16:27 ]
>>548
馬鹿だから作れないし、作れると言ってる人が全員キチガイに見える、ってことでは。

550 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:18:54 ]
確かにC++は自分が作れないものを軽々作れるキチガイが多いよな…



551 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:36:02 ]
>>548
>>490辺りからずっとそういう話じゃない?
要はlamdaのようにいちいちクラスやら関数作らずに済ませたいと。

552 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:37:25 ]
そしてキチガイの作ったものを素人が間違って使って原因不明のバグを出す

553 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 16:56:12 ]
>>551
え? そうなん?

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

554 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 17:09:00 ]
元々はそういう話だな
既存の仕組みでもできるよっていう反論があったから
それじゃ便利にならないっていう流れで「〜じゃできない」って事だろ

555 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 17:20:00 ]
コンストラクタの引数の個数を
全クラスで揃えるのもどうかなあと思わんでも無い。

556 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 17:21:48 ]
boost/lambda/constructor.hppを見れば
既存の仕組みでも簡単にできることがよくわかるし
わりと簡単に思いつく、天才の閃きは要らない

557 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 17:27:40 ]
>>555
FactoryMethodがその辺りのwrapperやってくれるわな。

558 名前:デフォルトの名無しさん mailto:sage [2007/11/23(金) 18:09:23 ]
結論 : boost を使え

559 名前:デフォルトの名無しさん mailto:sage [2007/11/24(土) 01:33:23 ]
C++0x → C++xx「できませんでした」

560 名前:デフォルトの名無しさん mailto:sage [2007/11/24(土) 01:42:04 ]
>>559
2100年移行までおあずけですか



561 名前:デフォルトの名無しさん mailto:sage [2007/11/24(土) 02:15:33 ]
Cxx

562 名前:デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:47:30 ]
>>522を見て思い出したんだが
Objective-CにはClass型ってのがあったなtypeinfo
なんていらんからああいう型があってもおもしろいと思う。

563 名前:デフォルトの名無しさん mailto:sage [2007/11/25(日) 16:07:49 ]
C99とは相思相愛になれますか?

564 名前:デフォルトの名無しさん mailto:sage [2007/11/25(日) 16:08:30 ]
そういえば restrict ってどうなるんだ?無視?

565 名前:デフォルトの名無しさん mailto:sage [2007/11/25(日) 16:18:10 ]
相思相愛ではないけど、C99で追加された標準ライブラリは
一通りC++0xにも入るはず。

566 名前:デフォルトの名無しさん mailto:sage [2007/11/25(日) 17:27:21 ]
現在のところC互換部は C90 ってことになってるけど,
かといってそれが C99 になるわけではないよね.
予約語とか.

567 名前:デフォルトの名無しさん mailto:sage [2007/11/26(月) 00:24:08 ]
C99 の一部の機能は追加される。
可変個引数マクロとか _Pragma 演算子とか。

568 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 07:27:49 ]
>>564
restrict 有り/無しでオーバーロードしたらどうなるんだろ。
コンパイラには判断できないよなぁ。

569 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 07:34:46 ]
>>568
でもそれは欲しかったり。

570 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 08:08:55 ]
type checkとname lookupの疑似コードってないのかね。




571 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 08:28:34 ]
>>569
あってもコンパイラに判断できないっつってんだろ。

572 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 09:56:20 ]
コンパイラがいる!

573 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 12:02:31 ]
こちとらエラーメッセージ出すのもひと苦労なんですよ!
何回言ったらそのテンプレートの使い方覚えんだよ?

574 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 12:15:41 ]
>>571
const同様に扱えば判断できるべ。

575 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 12:15:43 ]
>>573
コンパイラに謝る上司の姿を想像して吹いた

576 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 16:06:58 ]
>>574
restrictは引数以外での指定ができないからそれは無理じゃないか?

577 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 16:45:17 ]
>>576
げ、そうなのか。

578 名前:デフォルトの名無しさん mailto:sage [2007/11/28(水) 17:10:05 ]
直前の文脈から考えて、restrictに相当すると断言できるかどうかを判断させることは可能だな。
ただ、restrictの有無で動作がかわらないようにしないとバグの温床になるけど。

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

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

579 名前:デフォルトの名無しさん mailto:sage [2007/11/30(金) 14:56:06 ]
gcc/iccでc99としてコンパイルすると、これはfree()の呼び出しで型変換の警告だけで通るけど。
char * restrict * foo = NULL;
free(foo);
# gcc/iccでC++としてコンパイルすると型変換のエラーにはなる。

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

580 名前:デフォルトの名無しさん mailto:sage [2007/11/30(金) 15:44:52 ]
スレ違いなんでスルーしたけど、普通に使えるよ。
6.7.3.11 EXAMPLE4 見て。

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




581 名前:579 mailto:sage [2007/11/30(金) 15:48:04 ]
>>580
うい、THX!

582 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 04:24:40 ]
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!

583 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 04:38:19 ]
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!

584 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 20:33:15 ]
nullptrをぬるぽと呼ぶスレ

585 名前:デフォルトの名無しさん mailto:sage [2007/12/02(日) 20:40:10 ]
ぬるぽたぁ

586 名前:デフォルトの名無しさん mailto:sage [2007/12/04(火) 23:10:36 ]
ぬるーぽったー

587 名前:デフォルトの名無しさん mailto:sage [2007/12/05(水) 00:23:46 ]
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!

588 名前:デフォルトの名無しさん mailto:sage [2007/12/05(水) 00:24:17 ]
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!
これからもC++0xについて熱く語ろう!これからもC++0xについて熱く語ろう!

589 名前:デフォルトの名無しさん mailto:sage [2007/12/05(水) 17:16:39 ]
保守のつもりか?

590 名前:デフォルトの名無しさん mailto:sage [2007/12/06(木) 00:02:41 ]
そんなまさか



591 名前:めかる ◆DzhWnUSADA [2007/12/06(木) 00:08:59 ]
カラアゲヽ(´ー`)ノ時代はカラアゲ!

592 名前:デフォルトの名無しさん mailto:sage [2007/12/07(金) 02:20:20 ]
static_cast dynamic_cast const_castのオーバーロードってどんな感じで記述するんだろうか。
使い方がテンプレートクラスっぽいから、やっぱり
struct someclass{
template<typename T> operator static_cast(T a);
};
ってなるんだろうか。

593 名前:デフォルトの名無しさん [2007/12/14(金) 01:14:51 ]
www.open-std.org/jtc1/sc22/wg21/
News 2007-12-13: The 2007-12 mailing is available
News 2007-12-13: The C++ Standard Library Issues List (Revision 53) is available
News 2007-12-13: C++ Standard Core Language Issues List (Revision 52) is available

594 名前:デフォルトの名無しさん [2007/12/14(金) 01:29:31 ]
記念火気庫ヽ( ´∀`)ノ ボッ

595 名前:デフォルトの名無しさん [2007/12/14(金) 01:32:23 ]
ってココID出ないのかorz

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

596 名前:デフォルトの名無しさん mailto:sage [2007/12/14(金) 01:37:45 ]
板ごとにID違うんだから意味ないだろw

597 名前:デフォルトの名無しさん mailto:sage [2007/12/14(金) 07:08:58 ]
なにやってんだwww

598 名前:デフォルトの名無しさん mailto:sage [2007/12/14(金) 11:23:49 ]
きっと彼はどっかの板で ID が C++0x だったんだろう ... と信じよう

599 名前:デフォルトの名無しさん mailto:sage [2007/12/14(金) 13:33:09 ]
>>593
> N2485
> A variadic std::min(T, ...) for the C++ Standard Library

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



600 名前:デフォルトの名無しさん [2007/12/15(土) 19:15:45 ]
>>599
kwskおねがいします



601 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 19:26:27 ]
variadic macro、可変長引数を取れるマクロかな。

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

602 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 19:31:07 ]
template <typename T>
const T& min( const T& a) { return a; }

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

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

603 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 19:34:30 ]
>>601
C99 との互換性なんだろうと思う。
他全てと互換性ない癖に今更と思わなくもないが。

604 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 15:08:36 ]
>>602
重箱だが、const参照の引数を参照で返したらダメだよ
引数に一時オブジェクトが渡されるときもあるから

605 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 20:15:09 ]
それは文脈しだいだろう
int x = min(min(1,2),3);

606 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 01:19:08 ]
>>604
戻り値で作られた一時オブジェクトはconst参照で延命できるけど、
このばやい戻り値(const T&)はrvalueじゃないからダメってこと?
ダメってソースとかあったらkwsk
延命できそうな気もしなくもないけど…どうなんだろう

607 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 01:39:15 ]
一時オブジェクトの寿命は完全式の終わりまでだから、
605の場合、xの初期化を行うときはまだ生きている。

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

608 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 01:43:01 ]
伸びないよ
int const & x = min(1,2); // ダングリング

609 名前:606 mailto:sage [2007/12/19(水) 03:30:56 ]
ググったらこんなの見つけた
ttp://it-reading.org/ebook/c%20faqs/content/0201309831_ch32lev1sec8.html

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

610 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 10:16:53 ]
GCが導入されたら、ほとんど変更せずに済むかも
・・・は甘いか。




611 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 11:35:50 ]
えーと、そもそも関数の戻り値をconst参照で受けるって使い方はありなんだろうか。

612 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 11:47:59 ]
スレ違いだろ。

613 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 16:16:49 ]
>>606
これ戻り値はrvalueじゃないの?

614 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 21:36:45 ]
>>602の戻り値がconst T&で宣言されてるから
俺だったら戻り値をconst T&で受ける書き方をしても安全だと期待するなあ
だからこそ危ないよっていう指摘なんだろうし。

615 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 22:05:03 ]
まあそういう言語だから仕方ない
iterator i = string().begin(); // ダングリング

616 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 22:27:48 ]
const参照でのみやり取りできるすまぽ作ったら便利じゃね?と思って
const smart_ptr& returns_pointer(const smart_ptr& sumapo)
こんな関数に渡したらreturn時に見事にデストラクトされた私が通りますよ。

617 名前:デフォルトの名無しさん mailto:sage [2007/12/20(木) 03:58:03 ]
どうせ最適化効くからコピーされてもいい

618 名前:デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:13:52 ]
VC8のstlだと、min, maxはしっかりconst参照を返してるな

619 名前:デフォルトの名無しさん mailto:sage [2007/12/21(金) 23:01:57 ]
>>618
返すのはいいんじゃない?問題になるのは
>const参照で受ける場合も、それで寿命が延びるから
>あまり問題にならないと思う。
こういう誤解をして、const T& hoge = min(..); と受けてしまった場合だけだから。

620 名前:デフォルトの名無しさん mailto:sage [2007/12/21(金) 23:05:40 ]
>618
だって規格でそうなってるんだもんよ。



621 名前:デフォルトの名無しさん mailto:sage [2007/12/22(土) 23:40:39 ]
なんつうか名前マングリングを少しは統一しようや
とか
ABIをある程度規定しないか
とか
その辺の動きはないのかねぇ

622 名前:デフォルトの名無しさん mailto:sage [2007/12/22(土) 23:48:08 ]
名前マングリングを統一した所で、
this をどう扱うかとか
例外をどう扱うかとか統一しないと意味ない希ガス。

623 名前:デフォルトの名無しさん mailto:sage [2007/12/23(日) 00:13:46 ]
>>621
互換性を考えると、どの処理系もいまさら変えられないでしょ。
せっかく決めても誰も使わない可能性大。

624 名前:デフォルトの名無しさん mailto:sage [2007/12/23(日) 01:34:21 ]
互換モード残せばいいだけじゃ

625 名前:デフォルトの名無しさん mailto:sage [2007/12/23(日) 01:45:01 ]
互換モードでもC++0xを謳えるの?

626 名前:デフォルトの名無しさん mailto:sage [2007/12/23(日) 04:18:53 ]
>>621
いりません

627 名前:デフォルトの名無しさん [2007/12/27(木) 12:36:37 ]
www.aoky.net/articles/steve_yegge/tour_de_babel.htm
これを読むとC++のことぼろくそに書いてあるんだけど、
本当のところはどうなんだろうか。

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

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

628 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 12:57:19 ]
実戦重視の人で、型システムについては全くの無知。
以前多重継承について犯した過ちを、今度はgenericsに対して犯している。
具体的にはconcept, interface, signatureあたりに対する無知。
というのが感想。

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

629 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:25:42 ]
VCに入らない限り90%近くの環境で無意味と思うんだが。

630 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:32:56 ]
>>627
的を得てると思う。趣味でコード書いている人ならともかく、
C++が大きなクソの山を作り出す、というのは多くの開発現場で実際起きていることだし
これを無知な奴のたわ言と切り捨てるのは、よほど恵まれた環境で仕事しているか
逆に実際の開発現場を知らない、それこそ無知な人でしょ。



631 名前:デフォルトの名無しさん [2007/12/27(木) 13:34:24 ]
蜂とか蟻ってさ、7割がせっせと働いて3割は巣でごろごろしてるんだぜ。
つまりオマエらNEETは勝ち組み?みたいな。


632 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:35:28 ]
それを言ったら90%近くの人はC++なんて使ってないだろw

633 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:41:34 ]
たまには某ランドの事も…

634 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:45:13 ]
VC で C++ しているひとの数と (除く C# その他)
gcc で C++ しているひとの数をくらべたら、後者のほうが
多かったりしないかな?しないか。

635 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 13:50:07 ]
>>633
あの社名だかブランドだかがコロコロ変わる会社のことか?w

636 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 14:02:29 ]
C#やVB.NETに移ったとはいえ、まだVC++利用人口多いと思うなぁ。

637 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 14:20:24 ]
そこらで売ってる窓のパッケージソフトから
VC製除いたら殆どなくなるんじゃないの?

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

638 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 14:26:48 ]
パッケージソフトという分野自体がマイナだけどな

639 名前:デフォルトの名無しさん [2007/12/27(木) 17:33:02 ]
>>604
これって標準ライブラリの定義をそのままvariadicにした>>599だよね。

640 名前:デフォルトの名無しさん [2007/12/27(木) 20:16:22 ]
変態的な仕様をやっと覚えたのに、
仕様が変わるのかぁ・・・



641 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 21:23:50 ]
どんどん変態するんですよ

642 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 22:24:07 ]
>>630
クソの山を作り出してるのは「C++」なのかね?
実際にはSTLだのBoostだの以前にプログラミング技法さえ身についてないヘボグラマが"普通の"プログラマ扱いになっている性だと思うんだが。
そんな連中はJavaだろうがPHPだろうがVBだろうが結局クソしか出せないわけだろ。

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

643 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 22:56:51 ]
いやいや、そんな連中でもJavaやPHPやVBなら「仕事」を出来てしまうんだよ。
そういう連中が仕事で使っても比較的被害が少ないように設計されている言語だからね。

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

644 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 23:00:08 ]
> そういう連中が仕事で使っても比較的被害が少ないように設計されている言語だからね。
それは幻想というものだ。

645 名前:デフォルトの名無しさん mailto:sage [2007/12/27(木) 23:32:45 ]
PHPやVBがC++よりも良いというのはいくらなんでも言い過ぎだ
あんなのニッチにうまくハマッただけの言語じゃないか

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

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

647 名前:デフォルトの名無しさん mailto:sage [2007/12/28(金) 00:08:54 ]
ただまぁ、C++ だと落とし穴が多いのは確かだと思う。
禿もこう言っていることだし。
>C++ has indeed become too "expert friendly"
ttp://www.technologyreview.com/Infotech/17831/page2/
それなりのコードが書けるようになるまでの閾値が高すぎると思うんだわ。

648 名前:デフォルトの名無しさん mailto:sage [2007/12/28(金) 00:14:45 ]
>>646
よく嫁。使い物になるなんて言ってない。「仕事」になるってだけ。
一緒に仕事したいとは思わんけど、あいつらがそれで喰ってる事実は否定できん。

649 名前:デフォルトの名無しさん mailto:sage [2007/12/28(金) 00:33:16 ]
まあ 646 は仕事で辛い目に毎日あってるみたいだから、許してあげようよ...

650 名前:デフォルトの名無しさん mailto:sage [2007/12/28(金) 00:36:11 ]
>>647
まあテンプレートメタプログラミングに始まり、関数型、オブジェクト指向手続き型、抽象データ型の扱いなど、「使いこなす」には大変だと思うよC++は。
でも、クラスベースのオブジェクト指向手続き型言語として、類似のJavaやC#の公約数的部分だけでも理解して使えれば十分なんだが、そこまでいくのもそんなに難しいものかねぇ・・・

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



651 名前:デフォルトの名無しさん mailto:sage [2007/12/28(金) 01:45:53 ]
C++は今後もプログラミング言語の実験場であり続けるだろう。
だからC++0xの話をして、プログラマ板向きの話題は窓から捨ててしまおう。

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

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

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

のところ。

652 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 21:58:13 ]
さんざん言われてるけど、2009年までにまとまるとは思えない

653 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:12:45 ]
2015年までおk

654 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:15:49 ]
なんとかまとまるだろ。
ただ、もう「C++0xの次」みたいのが言われ始めてるからなw

655 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:42:37 ]
もう 1x ってよばれてね?

656 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:43:28 ]
C++xx でいいじゃん。

657 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:44:35 ]
Cxx

658 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:52:19 ]
C+++

659 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 08:37:32 ]
C#-

660 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 08:42:50 ]
C++xxxxxx

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



661 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 08:45:41 ]
その頃には西暦なんてなくなってるかもしれないぞ

662 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 16:07:34 ]
C++0079

663 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 16:59:10 ]
C++0083 STARDUST MEMORY

664 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 17:15:48 ]
私は帰ってきた!

665 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 18:40:48 ]
C++0x2010

666 名前:デフォルトの名無しさん mailto:sage [2008/01/06(日) 19:33:16 ]
つか今更だがthreadすげえな。
何がすげえって、今までライブラリなりがガリガリ実装してたものを
言語が仕様だけ定めてあと実装はベンダに丸投げってその思想がすばらしい。
その手があったか、ってw

667 名前:デフォルトの名無しさん mailto:sage [2008/01/06(日) 19:35:38 ]
>>666
意味不明。ベンダとかライブラリって具体的には何をイメージしてる?

668 名前:デフォルトの名無しさん mailto:sage [2008/01/06(日) 22:12:07 ]
言わせとけよ
いちいち突っ込んでスレを荒らすな

669 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 02:01:59 ]
ついでに言うと、threadに限ったことではないだろ、それ。

670 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 11:56:29 ]
C/C++自体が環境依存って言うことも無きにしも非ず。



671 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 15:31:36 ]
今の環境(CPUとかOS)はほとんどC/C++と整合するように作られてるな。
昔のメインフレームはワードアドレスマシンとかあって整合性が悪そうだ。

672 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:16:34 ]
ほほぉ、CがPDP-11用に作られたと言う事実は無視かね。

673 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:47:53 ]
知識自慢はよそでお願いしますよ・・・

674 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:54:43 ]
そうだね、頭の足りていない>671はさておき、>672はスルーすべきだったね。

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

675 名前:デフォルトの名無しさん [2008/01/07(月) 17:47:35 ]
ガベコレは本当に入るのでしょうか?
ガベコレ対象となるクラスはまた特別な
クラスから継承しなければならないとか?

676 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 18:01:55 ]
どっちにしても、何も特別なことをしなければGC対象にはならないから安心汁

677 名前:デフォルトの名無しさん [2008/01/07(月) 19:04:43 ]
ガベコレキタコレ

678 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 20:36:18 ]
ガベコレくるの?
ユニークカウンタ(俺語です。)で処理すんの面倒なんでぜひ入ってほしい。

679 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 21:25:38 ]
使うかどうかは選べるんだから、(typeinfoのように)
とりあえず実装非依存な形で仕様に出来るかどうか研究して頂けると嬉しい。

680 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 22:50:53 ]
n2310をチラっと読んでみたけど新しいキーワード導入しすぎでしょ
これは当分入らないと思う

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



681 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 23:03:33 ]
以前ハゲの人が提案してた
#scope
#endscope

みたいなのは入るのかな

682 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 00:25:58 ]
それ{}が打てない地域用?

683 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 03:53:57 ]
>>682
トライグラフだっけ?それじゃだめなのか?

684 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 03:56:34 ]
もうそろそろプリプロセッサには退場してもらいたい
#includeだけでいいよ

685 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 05:57:58 ]
>>684
ifdefが無いとassertもできなくね?
ifdefなんて無いに越したことはないが、必要な部分はあると思うんだが。

686 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 06:36:36 ]
今更プリプロセッサ廃止したらBoost.Preprocessor使いまくりの俺のコードが全滅する

687 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 07:20:11 ]
>>681
プリプロセッサ用のスコープか?

688 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 07:37:11 ]
世界はプリプロセッサで出来ている

689 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 11:05:07 ]
>>687
そうマクロを制限する。
scope外のマクロ全部無効になって、
scope内のマクロはscopeの外に定義が出ない。
ただし必要なものだけimport/exportできる。

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

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


690 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 12:56:03 ]
まあ「プリプロセッサ」である限り使い勝手は悪いわな。プリプロセッサを廃止して必要な機能を
言語側でちゃんと実装すべきだと思うが、そうするともう C++ とは呼べないだろう。



691 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 12:58:26 ]
>>689
コンパイルフェーズでプリプロセッサが分かれているんだから、
namespace を解釈させるってのは難しいだろうね。

692 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 13:14:29 ]
なーんちゃってプリプリー

693 名前:デフォルトの名無しさん [2008/01/08(火) 13:56:07 ]
でもさ,プリプロセッサのおかげで
あんなことやこんな変態プレイができるんだぜ?

694 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 21:20:10 ]
プリプロセッサがチューリング完全だったらいいのに

695 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:21:09 ]
プリプリ中学生!

696 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:26:57 ]
ttp://blogs.msdn.com/vcblog/

C++0x standard

697 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:27:59 ]
え?!チューリング完全じゃないの?
てっきりそうだと思ってた

698 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:32:01 ]
LISPのマクロはチューリング完全だけど
C++のプリプロセッサがチューリング完全だとは聞いたことが無い。
テンプレートはチューリング完全だけどね。

699 名前:デフォルトの名無しさん mailto:sage [2008/01/08(火) 22:41:35 ]
Boost.Preprocessor使えばチューリングマシンぐらい実装できそうな気もするけど
規格でネストのレベルの上限が決まってるとかかな

まぁスレ違いか

700 名前:デフォルトの名無しさん [2008/01/09(水) 00:49:51 ]
>>697
m4マクロみたいに再帰的定義ができません。
>>698
テンプレートは原始帰納関数しか計算できないのでは?



701 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 10:03:02 ]
ビョーン様をハゲと言うのはやめろ!

702 名前:デフォルトの名無しさん [2008/01/09(水) 10:08:49 ]
権威を自分の下に置くことによって優越感を味わっているだけなんだよ
技術力の低い賎民の僻みなんだから気にしたら負けだ

703 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 10:30:20 ]
禿は愛称です

704 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 12:09:52 ]
いじめではなくプロレスごっこです

705 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 12:24:57 ]
禿は偉大だ・・・俺も禿るように頑張るよ。

706 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 13:22:38 ]
禿かわゆす

707 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 17:35:10 ]
ビョーン・ザ・バルドヘッド

708 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 17:41:43 ]
Boost.Preprocessorはすげえよ
Boost.MPLやBoost.Lambdaはがんばれば出来る
(かもしれない)

Boost.Preprocessorは絶対に無理だ

709 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 19:52:30 ]
>>700
アッカーマン関数なら計算できるけど。

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

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

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

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

710 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 19:53:18 ]
うわ、タブが文字化けした。
もっかい

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

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

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

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




711 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 20:31:57 ]
>>700
チューリング完全だという論文がある。
d.hatena.ne.jp/earth2001y/20060929/p2

712 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 01:24:42 ]
底学歴でさーせんwww




チューリングなんてまったく知らないんだけど、勉強した方がいいかな?(;´Д`)

713 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:04:31 ]
少なくとも勉強したほうが悪いということは無いと思うぞ

714 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:05:07 ]
知らなくたってPGは務まる。ってか大多数の職業PGは知らないと思う。

715 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:06:47 ]
でも少なくとも情報工学科でたやつは習うでしょ

716 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:08:28 ]
気になるなら調べりゃいい。それが勉強だ。

717 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:17:03 ]
>>715
情報系出身だけど一切授業ではやってないよ。
ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E7%90%86%E8%AB%96
↑のページで授業で触れられたものはO記法くらいだなぁ。

718 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 02:34:46 ]
情報系いうてもピンキリやな

719 名前:712 mailto:sage [2008/01/10(木) 03:32:48 ]
ウィキペディア読んできたけど意味わかんね(;´Д`)w

720 名前:デフォルトの名無しさん [2008/01/10(木) 04:50:29 ]
授業でやった.しかし忘れた.
その時教科書使ってない.
センセのパワポだけ.
SIに就職後だけど,情報系出てるのに恥ずかしい.
いまさら何読めばいい?
英語は何とか問題ないと思うので英語の教科書でも.

次のレスでエロい人が読み物を列挙してくれる予定.




721 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 07:01:00 ]
つttp://wiredvision.jp/news/200710/2007102622.html

722 名前:デフォルトの名無しさん [2008/01/10(木) 09:13:40 ]
チューリング完全なんて数学の知識が要るから必要ないよ

723 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 09:26:34 ]
知ってるに越したことはないけどね

724 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 09:27:46 ]
美少女中学生と完全なチューをしている状態!(*´Д`)'`ァ'`ァ

725 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 15:31:05 ]
数学の知識が無いのにそういう仕事してる時点で下流決定だろw

726 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 16:00:31 ]
時点で、とか書く時点で厨レスだろw

727 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 18:32:54 ]
2chやってる時点でry

728 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 20:44:36 ]
>>726
厨リング完全なレスだな

729 名前:デフォルトの名無しさん mailto:sage [2008/01/10(木) 21:36:30 ]
>>728
誰がうまいことを(ry

730 名前:デフォルトの名無しさん mailto:sage [2008/01/11(金) 00:09:56 ]
まあしかし、すでにプログラムをかけるひとはチューリング完全のあたりを勉強するのはぜんぜん難しくないと思う
数学の記法つかってかいてない本とかあれば、だけど。



731 名前:デフォルトの名無しさん mailto:sage [2008/01/11(金) 00:18:24 ]
ありそうだな

732 名前:デフォルトの名無しさん mailto:sage [2008/01/11(金) 01:22:11 ]
あるよ?

733 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 02:26:47 ]
include guard書くのが馬鹿らしいので#includeのプリプロセスで勝手に弾いてほしい。

734 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 09:55:47 ]
#pragma once

735 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 10:03:19 ]
pragma onceがなかなか標準にならないのは
いろいろ難しい問題があるらしい。

知らんけど

736 名前:デフォルトの名無しさん [2008/01/17(木) 11:50:48 ]
#pragma once って gcc でも vc でも使えるよね.

737 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 12:10:50 ]
windowsのヘッダを通さなきゃならないコンパイラはみんなonceは通すよ

738 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 13:00:20 ]
#pragma twice

739 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 13:55:22 ]
>>735
一言で言えば、何で同一性を判定するのかという問題だね

740 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 20:19:03 ]
インクルードガードを内部的に自動生成したのと同じ形に動作する程度でいいと思うんだがなあ。



741 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 21:33:07 ]
その内部的に生成する際に、識別子をどうするかが問題なんでしょうが

742 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 22:29:02 ]
GUIDを使って後は神に祈る

743 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 22:41:21 ]
内部的に自動生成したのと 「同じ形に動作する」 わけだからどうとでもなるべ。

744 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:02:53 ]
同じファイルに複数の名前がついてるような場合とかどうするのって話。

745 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:07:46 ]
ローカルにあるファイルを、
直接と、ネットワーク越しにとでアクセスする場合とかか?

746 名前:デフォルトの名無しさん mailto:sage [2008/01/17(木) 23:47:53 ]
シンボリックリンクされてる場合とか。

747 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:02:15 ]
「そういう場合は処理系定義とする」 でもういいじゃん

748 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:16:03 ]
いちいちヘッダを比較すればいい
違う名前だろうがなんだろうが一字一句同じなら同一としていいはずだからな

749 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:17:23 ]
同じファイル名が別の場所にあって名前も内容も同じ場合ってのがシステムヘッダ
などでよく起きる。さらに内容はほぼ同じ(バージョン違い)とか考えだすときりがない。

750 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:20:26 ]
それに関しては絶対パスで区別すりゃいい。
リンクされてる場合は、同一実体を指しているかもチェックする。
ただ、このあたりは環境依存な話が多く出てくるので
もう 「処理系定義」 でいいと思う。



751 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:00 ]
提案書を書いて委員会へ提出よろ

752 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:06 ]
そんならもう#pragma onceの扱いは処理系定義でいいじゃん。

753 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:31:46 ]
そもそも pragma の扱いは処理系定義だw

754 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:53:37 ]
#pragma onceってファイル内の中途半端な位置に書いてたり2か所に記述したりしたらどうなるんだろ

755 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 00:56:32 ]
処理系定義だろ

756 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 03:04:14 ]
>>752
ワロタ

757 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 07:42:44 ]
#pragma once

#pragma once は同一ファイルの二度目以降のインクルードを無効にする。
ファイルの同一性判定の方法は処理系定義とする。

ファイル A の中で #pragma once が処理される前に #include があり、
その中でファイル A がインクルードされている場合、
#pragma once は効力を発揮しない。

#pragma once はファイル中に1カ所にしか出現してはいけない。

758 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 09:15:21 ]
#pragma once(unique-id)
ちょっとタイプ量は増えるけど、こう書くようにすればいいんじゃなかろうか。
従来のようにidを省略したら、
#pragma once(__FILE__)
みたいになって、ファイルの同一性の比較は処理系定義と妄想

759 名前:デフォルトの名無しさん [2008/01/18(金) 09:19:30 ]
>>748
じゃだめなん?

760 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 09:38:45 ]
全く同じファイルのコピーが二箇所にあって、両方ともincludeされてて、
なんかの拍子に片方を編集したら、コンパイルとおらなくなる。

鬱陶しくないか。



761 名前:デフォルトの名無しさん [2008/01/18(金) 09:41:35 ]
>>758がいいな
同一性はプログラマが定義することもできるし、コンパイラに任せることも出来る

762 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 10:10:44 ]
普通にインクルードガードでいいだろJK

763 名前:デフォルトの名無しさん [2008/01/18(金) 10:12:15 ]
>>762
よく ifdef endif の対応関係がずれて
あわわわ〜ってなる(笑

764 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 10:55:05 ]
>>763
それは言語仕様でフォローすることではないな

765 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 12:13:46 ]
>760
コンパイル通るようになったらなったで、
何からの拍子で、片方だけ、構造体の構成とか変更すると、
実行時に訳わかめなエラーになるんじゃねーの。

766 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 13:48:01 ]
こういう仕様を考える時は「やっちゃいけないこと」から考えるといいぞ

767 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 16:34:02 ]
include回りの問題の多くはModules in C++(N2316)が入れば解決じゃね?
仕様が固まる頃にはC++20くらいになってそうだけど。

768 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 20:45:37 ]
もうプリプロセッサなくていいよ

769 名前:デフォルトの名無しさん [2008/01/18(金) 20:46:29 ]
>>768
まぁそういう意見もあるよな.
しかし過去の遺産のことを考えると
プリプロセッサの挙動をもっと厳格に
規格化したうえで存続した方がいい.

770 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 20:46:38 ]
Cでプリプリ!なんていやらしい!



771 名前:デフォルトの名無しさん mailto:sage [2008/01/18(金) 21:01:08 ]
modulesを入れるとなあ、
exportどころじゃないぞ、実装の手間が。

templateもconceptも、実装をヘッダでincludeすること前提だしな。
必要な情報を全部中間言語に書き出すとなると大変。

772 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 00:51:35 ]
もはや C++ ではない気がするなあ

773 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 02:29:00 ]
D言語においでー

774 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 08:41:03 ]
DはC++0xの実験的な実装

775 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:12:01 ]
include guardも#pragma onceも、インクルードされる側のファイルに書く。つまり、読まれたかどうかはファイルを開かないと分からない。
なんつーか、Obj-Cのimportみたいのが欲しいんだよね。あれって多分開く前に同一性チェックをしてるでしょ。(#pragma onceもそうなのかな?)

776 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:16:09 ]
美少女中学生のインクルードガードは固くないほうがいいなぁ
もしくは自分で破っちゃったりしててアアーッ

777 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:27:39 ]
つttp://pc11.2ch.net/test/read.cgi/tech/1142089873/

778 名前:デフォルトの名無しさん mailto:sage [2008/01/19(土) 14:38:18 ]
16.6.1 #pragma once

    #pragma once po-identifier_opt new-line

po-identifier:
    identifier or
    ( identifier )

#pragma once は同一ファイルの二度目以降のインクルードを無効にする。
identifier が指定されている場合は、identifier が同一である場合に同一ファイルであると判定する。
identifier が指定されていない場合のファイルの同一性判定の方法は処理系定義とする。

ファイル A の中で #pragma once が処理される前に #include があり、
その中でファイル A がインクルードされている場合、
#pragma once は効力を発揮しない。

identifier の指定の無い、または同じ identifier を持つ #pragma once は、
ファイル中に1カ所にしか出現してはならない。

779 名前:デフォルトの名無しさん [2008/01/21(月) 01:06:40 ]
Cプログラマ必須テキストです!

mori.eco.to/

780 名前:デフォルトの名無しさん mailto:sage [2008/01/21(月) 07:06:50 ]
俺はC++だから必要ないな



781 名前:デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:15:59 ]
おまえがC++だったのか!

782 名前:デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:20:59 ]
>>780
お前のせいで!

783 名前:デフォルトの名無しさん mailto:sage [2008/01/21(月) 15:40:53 ]
>>782
お前がハゲなのは親のせいだ。

784 名前:デフォルトの名無しさん mailto:sage [2008/01/21(月) 15:56:56 ]
C++のせいではなかったのか…orz

785 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 14:41:57 ]
>>779
普通のC言語入門書っぽいな。
経験のあるプログラミング言語をわざわざ列挙してるのが何か笑える。

786 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:33:15 ]
「普通の」じゃないだろ。
寧ろ本人曰く、「世のCを教える立場の人間は押し並べてCを判っていない」とのことなんだから。

787 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:34:09 ]
>>785マルチ宣伝レスだから反応しないように

788 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 15:42:40 ]
まともな本ならこんな宣伝しないよ

789 名前:785 mailto:sage [2008/01/22(火) 16:00:22 ]
スマソ

790 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 17:24:14 ]
ハゲが怖ければ大豆イソフラボン摂れば良いよ。女性ホルモンに似た働きをして
ハゲや不本意な勃起を抑えてくれる事が医学的に証明されている。



791 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 23:32:49 ]
>>790
ありがとう。さっそく試してみるよ。

792 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 23:46:14 ]
結論は納豆というわけか

793 名前:デフォルトの名無しさん mailto:sage [2008/01/29(火) 17:40:14 ]
やっぱ豆蔵がいちばんっしょ。

794 名前:デフォルトの名無しさん mailto:sage [2008/01/29(火) 17:43:55 ]
>>790
俺の体で効果がない事は、俺の実体験により証明されている。

795 名前:デフォルトの名無しさん [2008/01/29(火) 21:17:36 ]
美少女中学生のいやらしいお豆!

796 名前:デフォルトの名無しさん mailto:sage [2008/02/06(水) 10:18:26 ]
あげるな危険。

797 名前:デフォルトの名無しさん [2008/02/06(水) 21:31:19 ]
最近C++0xを勉強中なんですが

decltypeは静的な型を表すんでしょうか

class Derived : public Base
{}

Base* pb = new Derived();

std::cout << typeid(decltype(pb)).name(); //Baseと表示?Derived?

798 名前:デフォルトの名無しさん mailto:sage [2008/02/06(水) 21:32:40 ]
静的な型を表す。

799 名前:デフォルトの名無しさん [2008/02/06(水) 21:48:43 ]
>>798
ありがとうございます

実際に試せればわかるのに・・・

と思ったらconcept gccなんてのがあるんですね
ちょっと遊んでみます

800 名前:デフォルトの名無しさん mailto:sage [2008/02/06(水) 22:34:07 ]
decltype(pb)はBaseではなくBase*では?



801 名前:デフォルトの名無しさん [2008/02/08(金) 17:25:38 ]
operator[] () = -> *

C++0xでこれら演算子をグローバルに定義できるみたいですが、
どういう意図で導入したんでしょうか

802 名前:デフォルトの名無しさん mailto:sage [2008/02/08(金) 21:54:05 ]
それは初耳。

803 名前:デフォルトの名無しさん [2008/02/10(日) 14:30:08 ]
右辺値参照でT & &&がT &になるというのが納得できない。
例えばN1377には右辺値を左辺値に変換する関数moveが載っているが、
template <class T> inline T&& move(T&& x)
{ return static_cast<T&&>(x); }
moveを使った次のような(自然な)コードは動かない。
void foo(move_ptr<Bar> &d, move_ptr<Bar> &s) {
    (何か例外を投げる可能性がある処理)
    d = move(s); // 処理に成功したらsをdに移す
}
N1377やN1385で導入している型推論のルールによると、
Tはmove_ptr<Bar>ではなくmove_ptr<Bar> &になる。
するとmoveはmove_ptr<Bar> & &&型、つまりmove_ptr<Bar> &型を返すことになる。
上のような処理をしたければ、次のように直接static_castするしかない。
d = static_cast<move_ptr<Bar> &&>(s);

804 名前:デフォルトの名無しさん [2008/02/10(日) 14:43:44 ]
T & && = T &とする根拠として、N1377では次の例を挙げている。
compressed_pair<T1, T2>::compressed_pair(compressed_pair&& x)
    : first_ (static_cast<T1&&>(x.first_)),
      second_(static_cast<T2&&>(x.second_))
{}
が、そもそもpairのような値型オブジェクトが参照をメンバに持つこと自体
かなり特殊なことなんだから、こういうのはcall_traitsで処理すべきだろう。

805 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 14:46:40 ]
move_ptr<Bar> const&を引数に取るoperator =が無ければ大丈夫。ConceptGCCでやってみた。
struct c
{
c& operator =(c&&);
private:
// c& operator =(c const&);
};

template <class T> inline T&& move(T&& x) { return static_cast<T&&>(x); }

void f(c& x, c& y)
{
x = move(y);
}

また、N1690ではこのmoveの戻り値の型が
typename remove_reference<T>::type&&になっている。
これなら、上のコメントアウトを外した状態でもコンパイルできた。

806 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 16:31:07 ]
>>803
最新の draft などでは>>805さんの書かれているように
move の定義が変わっているので,単に d = move(s) の構文で大丈夫なはずです.

>>804
そのように参照型を取る事例への対処を
より汎化した規則で書こうとした結果が,
現在の reference collapsing rule じゃないんでしょうか?

807 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 16:43:41 ]
>>804
あと,複数引数などの forwarding を pair や tuple の形で行おうとすると,
普通に pair や tuple が参照型のメンバを持つ場面はあるように思われます.
そのような場合に,現在の reference collapsing rule だと
pair<T1&,T2&&> && や pair<T1&,T2&&> & に対して自然に collapsing rule を分配して
pair<T1&,T2&&> や pair<T1&,T2&> と同等に捉えられますので
割と自然なように思えます.

808 名前:803 mailto:sage [2008/02/10(日) 16:57:18 ]
>>806
compressed pairはおまけ的な例で、真の目的は
template <class T>
inline T&& forward(typename identity<T>::type&& t)
{ return t; }

template <class T, class A1, class A2>
shared_ptr<T> factory(A1&& a1, A2&& a2)
{ return shared_ptr<T>(new T(forward<A1>(a1), forward<A2>(a2))); }
のような転送を実現することみたいだね。
でも、だからといってT & && = T &のような直観に反する変換や
C++98の考え方と全く違う異様な型推論を導入するのはどうかと思う。
今まで型推論でさんざん苦しんだのに、またバグの温床を生むことになる。
もっと明示的に、「右辺値か左辺値か教えてくれ」という演算子「&?」を導入して、
template <class T, class A1, class A2>
shared_ptr<T> factory(A1&? a1, A2&? a2)
{ return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); }
と書ければ、プログラマの意図もはっきりするしC++98から大きく離れることもない。

809 名前:803 mailto:sage [2008/02/10(日) 17:01:20 ]
>>807
参照型のメンバを持つpairだのtupleだのは、
代入演算子を持たなかったりswapが参照先を入れ換えちゃったりするわけで、
そういうものを「自然」に扱える必要はないでしょう。

810 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:08:36 ]
>808
>C++98の考え方と全く違う異様な型推論
右辺値参照型をパラメタとする関数テンプレートの型パラメタの推論に関して
言及されてるならそれは同意します.もう
template<class T> void f(T&&);
の形は perfect forwarding のため (だけ) にあると理解したほうが早いと思います.



811 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 17:21:37 ]
>>809
参照型のメンバを持つ pair/tuple における代入や swap の semantics がどうなるかは
従来から散々議論されているのは承知しています.
結論が出ているかどうかは知らないのですが.
ただ,自分は forwarding などの局面で参照型メンバを持つ pair/ tuple を使うこと
想定してそういうものは自然に扱いたいという趣旨で発言しました.

誤解があるとあれなので補足しておきたいのですが,
tuple<T1,...> はあらゆる型 T1, ... に対して代入や swap が
well-defined である必要はなく, T1, ... に対してどういう操作が行えるかによって
tuple<T1,...> に対して行える操作が限定される場面があっても構わないと思っています.
そうしたときに,たとえば T1,... の一部またはすべてが参照型であるとき,
tuple<T1,...> に対して値としての代入や swap を well-defined な形で提供するのは難しいですが,
たとえば construction などは依然 well-defined に定義できますから,
construction などしか行えない tuple を提供することはできます.
で,そのような制限のかかった tuple でも forwarding などには十分使えますので
それを自然に扱いたいという motivation は排除してほしくないです.

812 名前:デフォルトの名無しさん [2008/02/10(日) 18:36:30 ]
やべぇ高度過ぎてわからん


813 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:07:34 ]
へぼぐらまの俺にもいまいちわからん
0x の改修って一般のC++プログラマに受け入れられるのか?
なんか、実用する人たちから遊離した規格のような気が・・・

814 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:16:39 ]
>>813
そんなに大変な非互換性は取り込まれないと思うから、一般のプログラマは現状の
規格に不満がなければ気にしなくてもいいでしょ。

受け入れられるかどうかっていう点では、規格の変更に対応するかどうかという話で
コンパイラベンダの反応が問題だと思う。

815 名前:803 mailto:sage [2008/02/10(日) 19:30:15 ]
>>811
それを言い出したら、参照型メンバを持つpair/tupleにoperator=を定義したいとき
T & && = T &&になっていれば
mypair &operator=(const mypair &src)
{ first = src.first; second = src.second; return *this; }
mypair &operator=(mypair &&src);
{ first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; }
というふうに「自然に」定義できるよね、という議論もできる。
で、結局mypair<int, int>がPODになって欲しいという理由で
何らかのtraitsが必要になる、と。

816 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 19:37:26 ]
ライブラリ書くようなエロいプログラマさんが頑張って書いてくれれば、
使ってる側からはあんまり気にしなくてもメリットはあると思う。
あと、この辺のおまじないは std::forward とか、std::move とかの裏側に隠されるし。

>808
>でも、だからといってT & && = T &のような直観に反する変換や
どうなるのが望ましい?

その辺をおいといても、&? の方が明快なのはそう思う(これ static_cast も必要なくね?)。
やってること自体は今の && の反転みたいなものだし、ルール的にも決めるのはそう難しくなさそう。
欠点は &? が増えるってことだけかな?
今更無理だろうけど誰か提案書いてくれw

817 名前:803 mailto:sage [2008/02/10(日) 19:51:49 ]
>>816
型の一番右側に&&が付いていれば、オブジェクトを移動してほしくて
わざわざ&&を付けたんだから素直に言うことを聞いて欲しい、と思う。
逆にT && &は(出現する場面を思い付かないけど)T &になってほしい。
> (これ static_cast も必要なくね?)。
{ return shared_ptr<T>(new T(static_cast<A1>(a1), static_cast<A2>(a2))); }
のこと?a1, a2という名前が付いた時点で左辺値になってるからstatic_castは必要。

818 名前:811 mailto:sage [2008/02/10(日) 20:08:33 ]
>>815
>mypair &operator=(mypair &&src);
>{ first = static_cast<T1&&>(src.first); second = static_cast<T2&&>(src.second); return *this; }
T & && -> T && という collapsing rule を仮定したときに,
これがどういう意味で自然なのかいまいち理解できないです.
おそらく
template<class T1,class T2> class mypair{ T1 first; T2 second; ... };
という定義だと思うのですが,
mypair のT1 が左辺値参照型であるとき,
T & && -> T && という collapsing rule の下では
first = static_cast<T1&&>(src.first);
という構文が破壊的コピー (move) を呼ぶことになりますが,
src.first は名前の付いた他のオブジェクトを指しているため,これはまずくないですか?

819 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:46:28 ]
>>813
いま問題になっている右辺値参照。
それによってもたらされる一般的なムーブ・セマンティクスは、
例えば関数の戻り値や、vectorで内部バッファリサイズ時の移動などといったときに
無駄なコピーの削減に役立つ。

#もちろんそれだけにとどまらないけど、それはとりあえず置いておく。

820 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 20:53:55 ]
で、何が言いたいかって、各人がほっといたって、
ライブラリの中の人が頑張るために使うから、
気付かぬ内に恩恵を被るかもしれないよってこと。



821 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:12:29 ]
move semanticsなんて全コンテナ修正だな

T&&のオーバーロード足すだけでいいのかな

822 名前:803 mailto:sage [2008/02/10(日) 21:23:32 ]
>>818
mypair &operator=(const mypair &src);
mypair &operator=(mypair &&src);
という一般的なオーバーロードを前提にすれば、
後者が呼ばれるのは故意にmoveする場合に限られる。
だから名前の付いた他のオブジェクトをmoveして正解。

823 名前:803 mailto:sage [2008/02/10(日) 21:26:48 ]
ごめん大嘘。関数の戻り値として参照を含むmypairを値で返されたら
後者の方にマッチしちゃう。これは確かにまずい。

824 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 21:53:55 ]
アクロバティックな性体験を体験した美少女中学生のような気分になった

825 名前:デフォルトの名無しさん mailto:sage [2008/02/10(日) 23:36:37 ]
同じくヘボグラマの俺には、辛うじて意味は分かってもどうしても内容に関しては受動的にならざるを得ない。

826 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:24:55 ]
そろそろ移動するべきかなぁと思ったのでこっちで。

【C++】STL(Standard Template Library)相談室 8
pc11.2ch.net/test/read.cgi/tech/1198435319/843
でオーバーロード面倒という声があったけど、場合によってはこんな風にできるかも。

Widget func(const Widget&, const Widget&, const Widget&); // move しない

// helper 実際には Variadic template 化?
template<typename T0, typename T1, typename T2>
Widget&& select(T0&& t0, T1&& t1, T2&& t2, std::enable_if<!std::lvalue_reference<T0>::value || !std::lvalue_reference<T1>::value || !std::lvalue_reference<T2>::value>>::type *dummy = 0)
{
  return !std::is_lvalue_reference<T0>::value ? std::move(t0) : !std::is_lvalue_reference<T1>::value ? std::move(t1) : std::move(t2);
}

template<typename T0, typename T1, typename T2>
Widget&& func(T0&& t0, T1&& t1, T2&& t2)
{
  Widget& w = select(std::forward<T0>(t0), std::forward<T1>(t1), std::forward<T2>(t2));
// w に対する処理
  return std::move(w);
}

あんま自信ないけどどうだろ?

827 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:39:30 ]
ムーブコンストラクタの呼び出しが最適化で削られるなら
いいのかなあと思った。

828 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:52:27 ]
>>826
func の return 文の std::move は不要では?

>>827
move constructor は副作用を持つでしょうから
これを参照で返すのと同じにまで最適化するのは結構厳しい要求かと

829 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 00:55:27 ]
結局そんくらいのコストは勘弁してやれ、
それが嫌ならオーバーロードしろ、ということか。

830 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:01:51 ]
move は一般にリソースの確保・解放を伴わないでしょうから,
そこまでシビアに move が重くなる状況はあまりないとは自分も思うのですけれど.

ただ std::string においては,例えば短文字列最適化を採用していると
move を使っても内部の文字列のコピーが発生するので,
4つのオーバーロードをまともに書く意義はあるのかなぁ,と.
それに4つのうち2つは他の実装に forward すればよいだけですし
そこまでオーバーロードが苦になることもないかと.



831 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 01:14:22 ]
そういう引数が4つあった16個か。

832 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 02:31:49 ]
Boost.Operatorsに期待。

833 名前:デフォルトの名無しさん mailto:sage [2008/02/21(木) 19:43:22 ]
引数に関して言えば、
右辺値参照なんてものを導入するより、
右辺値→左辺値 変換演算子を導入した方がいいと思う。

どうせ戻り値はテンポラリオブジェクトとして作成されてて、
基本型でもなければ大抵メモリ上にあるわけで、
内部的には変換なんて行う必要はないはず。
基本型とかなら、テンポラリオブジェクトを作成して、
そのテンポラリオブジェクトへの参照を返せばいい。

const 参照へならここら辺勝手にやってくれるけど、
非 const 参照へもできる手段を与えてやるって感じ?
自動的に変換されるのはおそらくマズそうなんで、
キャスト演算子の導入でなんとか。

834 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:09:34 ]
突発的!ちら裏!!

1、SingleInt型かByte型を導入してくれ。。。
char型はiostreamで文字として解釈されてすごい不便。俺は文字じゃなくて1バイトの数字を書き込みたいんだ。。。
バイナリ指定してるはずなんだけどなぁ。@VC

2、Enumの名前ちゃんと考慮してクレイ。名前何のために付けてるんだか。。。
2種のEnum宣言したときの別々なのにメンバの多重定義できなくてメチャクチャ不便だ。
片方に宣言してもう片方に設定しようとすると型変換エラーでるし。
ゲームでステータス設定するときEnum重宝するんだがなぁ。


835 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 02:14:32 ]
2の方はC++0xになかったっけ
enumにスコープがつくはず

836 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 04:11:22 ]
charとsigned charとunsigned char

837 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 13:06:58 ]
>>836
みんなbasic_istream/basic_ostreamに対するoprator >>/operator <<が定義されている。

838 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 14:01:38 ]
>>834
ios::binaryってことじゃなくて?


839 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 17:09:44 ]
>>835
おぉ、ありがたい。

>>834
一応yってみたけど、なんか意図どおりにならなかったなぁ。
自分の不具合かもしれんが。。。

840 名前:839 [2008/02/22(金) 17:11:18 ]
ミス。

>>834じゃなくて >>838



841 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 18:14:50 ]
foo(lvalue_cast(bar()));

842 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:42:00 ]
integer semantics

843 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 19:55:46 ]
template <typename T>
 T& lvalue_cast(const T& rvalue)
{
 return const_cast<T&>(rvalue);
}

何だ。今の C++ でも書けるじゃないか。
当然文をまたいで使う事はできないが、
move semantics なんて無くてもいいんじゃないか?

844 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 21:30:21 ]
>>843
ムーブとコピーの区別が付けられなくないか?

845 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:12:30 ]
>>844
引数は const 参照だが、
あくまでこれはテンポラリオブジェクトを作成するためのものであって、
引数には左辺値を渡してはいけない。
あくまで右辺値を左辺値に変換する際にしか使わない。

さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない?

846 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:17:36 ]
いや待て。
別に左辺値を渡してもいいのか。
単にそれがそのまま返されるだけで。
const な左辺値を渡してはいけない、だな。

847 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:26:40 ]
>>845
ごめんわからない。例えばこういう区別はどうなるの?
class Hoge
{
public:
Hoge(const Hoge&);
Hoge(Hoge&&);
};

Hoge f();

Hoge x;
Hoge y = x; //コピー
Hoge z = f(); //ムーブ

848 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:30:08 ]
>>845
>さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない?
やめたほうがよいです.左辺値と右辺値の識別を現行規格でやろうとすると
非常にわずらわしいことを考えないとならないです.
個人的に徹底的に試行錯誤した経験があるんですが,
現行規格で右辺値・左辺値識別を行うのは自分としては絶対にお勧めしません.
実際やってみれば理解してもらえると思うのですが,たとえばGCCの実装における
現行規格の8.5.3/5の解釈にブチ切れたりすることになったりします.

一応,下の提案さえ通ればライブラリレベルで move を実装することはできますが……
www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html

849 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:32:23 ]
ごめんHogeの定義こっちにしておく。
欲しいのは、右辺値を参照にすることじゃなくて、ムーブセマンティクスそのもの。
class Hoge
{
public:
  Hoge(const Hoge& y) : p(new int(*y.p)) {}
  Hoge(Hoge&& y) : p(y.p) {y.p = 0;}
  Hoge() : p(new int) {}
  ~Hoge() {delete p;}
private
  int* p;
};

850 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:42:47 ]
>>847
俺の案は RVO されることを前提としてるから、
ムーブなんて無くても十分ということになる。
面倒くさいから RVO を規格で要求したら? とさえ思ってる。



851 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:48:40 ]
>>848
識別は難しいのか・・・。

852 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:51:55 ]
なるほど。
でもそれだとbindなんかで呼出時に右辺値を直に引数にできないのは
解決できないように見える。
lvalue_castがあるって言うのかもしれないけど、
それだったら今でもboost::crefを使えば引数に渡せる点で同じと思う。

853 名前:デフォルトの名無しさん mailto:sage [2008/02/22(金) 23:54:11 ]
まあ、実際の所現行規格で別に実現できなくてもいい。
&& を単項演算子として、それを頭に付けるとかいう言語拡張でも。

854 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:14:35 ]
何でもかんでもオーバーロードで解決すべきかってのは微妙な所で、
2つの関数を実装させる手間、
いや、複数引数があれば4つ、8つと指数関数的に増えていく手間がかかってしまうのは
かなりの問題だと思う。
右辺値参照を導入するとしても、
オーバーロード不要の代替案は用意した方が良さげ。

855 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:18:34 ]
それはもう variadic template で書いてしまって,
意図しない呼び出しを SFINAE と deleted function 宣言で阻止してしまえば
いいんじゃないですかね
具体的にどういう複数引数関数書きたいのかによりますけれど

856 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:23:02 ]
テンプレートは export が実質使えなくてヘッダに実装せざるを得ない以上、
使う必要の無いところでなるべく使いたくはない。

857 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:24:31 ]
だが、もはやテンプレートのないC++も使いたくない。わがままだ。

858 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:27:29 ]
ムーブは無駄なコストが発生する上に
RVO みたいな最適化もできなさそうなのがな。
pimpl 使えばポインタの移動だけでいいから
まあ大したコストでもないのかもしれないが・・・。

859 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:33:33 ]
boost::noncopyable の他に boost::nonmovable も必要になるのかな

860 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:46:03 ]
非const参照に右辺値を渡せちゃう処理系もあるから、
いらぬお世話って思ってる人もいるかもね。



861 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:48:30 ]
>>858
pimplでなくとも、ポインタくらいのやり取りですむ(深いコピーが発生しない)
ってのがムーブの売りだろ。

862 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:49:19 ]
RVO で済む状況なら、RVO はコスト0だぜ。
非0は0には敵わない。

863 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:51:02 ]
メンバが5個くらいあったら5個ムーブする必要がある。
1つ1つはポインタくらいのやり取りでも、
個数が増えるとバカになんないかもしんない。

864 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:59:18 ]
んー,別に move を導入しても
RVO が適用できる場面では依然 RVO が適用されるでしょうから,
たとえば>>858さんが何を問題にされているのかいまいち把握できていないんですが……
もう少し詳しく教えてもらえると個人的にはうれしいんですが.

865 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:02:44 ]
実際、このコードだとconceptg++では全くムーブ発動しない。
$ conceptg++ t.cpp && ./a
constructor: 0x22ccd0
destructor: 0x22ccd0

#include <iostream>

using std::cout;
using std::endl;

struct hoge
{
hoge() : p(new int) {cout << "constructor: " << this << endl;}
hoge(hoge&& r) : p(r.p) {cout << "move constructor: from " << &r << " to " << this << endl; r.p = 0;}
~hoge() {cout << "destructor: " << this << endl; delete p;}
private:
hoge(hoge const&); //今回使わないので
int* p;
};

hoge f()
{
hoge obj;
return obj;
}


int main()
{
hoge t = f();
}

866 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:04:02 ]
RVO と右辺値→左辺値変換さえあれば、
文法を複雑にし、コストを必要とし、ライブラリを大きく書き換える
move とやらを導入する積極的な理由はないんじゃないの?
という話。

867 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:05:26 ]
RVO を規格で保証してないのに理由とかあるの?
コンパイラの実装コストの問題?

868 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:16:45 ]
>>866
関数からの戻り値のコピーを排除するのは move の応用の1つに過ぎないです.
RVO は return と throw に限定された話ですけれど,
move はより広い文脈 (たとえば std::vector におけるバッファの再配置) でも
きわめて重要な意義を持つ操作で,これは RVO 云々では取り扱いきれないように思います.

それから
>コストを必要とし、
の部分は,上にもありますけれど, RVO が適用できてコストがかからない部分では
move が導入されても依然 RVO が適用されてコストがかからないようになると
思われますので, (ただし,これはあくまでコンパイラの実装如何ですが)
RVO と move を比較してどのコストを憂慮されているのかがちょっと理解できていないです.

869 名前:852 mailto:sage [2008/02/23(土) 01:19:43 ]
>>866
俺の話はどうしてくれるの?
いや、このためだけに言語を大きく拡張する価値はないと言いたいのか。

870 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:20:15 ]
だから、右辺値を非 const 参照に渡すまともな手段は用意されてるの? って話。



871 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 01:21:01 ]
>>869
それが lvalue_cast じゃないの?

872 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:02:07 ]
あと、RVO が規格で強制されるものではないという点も。

873 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 02:22:09 ]
右辺値左辺値判定、こりゃ確かに無理だな・・・。

874 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 04:42:12 ]
>>870
「まとも」とか変な基準を持ち出すなよ。

875 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 05:25:18 ]
>>859
move 系コンストラクタや代入演算子が自動生成されないなら、要らないと思うんだけど、
こいつらもコンパイラが勝手に作っちゃうの?

876 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 10:52:20 ]
d = move(s)
の途中で例外が起こった場合、sとdの状態はどうなるんだろうか?

std::vectorの再配置にしても例外安全の強い保証
(メソッドの途中で例外が発生してもオブジェクトの状態は以前と同じ)
を行うなら、結局
 1、新しいバッファを確保
 2、それにすべてのオブジェクト内容をコピー
 3、バッファ作成に成功したら、ポインタの挿げ替えを行う
 4、古いバッファの削除
という手順を踏む必要があるんだけど・・・

 1、新しいバッファを確保
 2、オブジェクト内容をmoveで移動
 3、ポインタの挿げ替え&古いバッファの削除
とやってしまうと2の途中で例外が発生したときまずいことにならないか?

877 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 11:38:09 ]
swapみたいにmoveコンストラクタは例外の非送出が必要ということになっていると思う。

878 名前:デフォルトの名無しさん mailto:sage [2008/02/23(土) 13:14:28 ]
>>875
いえ,今の提案では move constructor や
move assignment は自動では生成されないことになってます.

>>876
move で強い例外安全性の保証を行おうとすると, move の rollback 操作が
move そのもので,これが例外非送出でなければならないため,
結局 move 自身が例外非送出である必要が出てきます.

879 名前:デフォルトの名無しさん [2008/02/27(水) 10:58:47 ]
C++の標準外のライブラリが破綻する最大の理由は
ライブラリ作成側が守るべきプログラミングモデルをユーザに示さないからだよ。

コードから読み取れるモデルでなく、
モデル宣言をするべきなんだよ。
その完全性を支援するためにコンパイラがそれによって挙動を変えてもいい。

最初は完全なるOOを実現しているように見えた。
しかし、あるバージョンではマルチパラダイムに変身し
OOの完全性を崩壊させるとかNe-Yo。



880 名前:デフォルトの名無しさん [2008/02/27(水) 14:10:39 ]
こないだ STL スレで挙がった話なんだけど、 copy_if() がどうなってるかだれか知らない?
未だにドラフトにも載ってないんだけど。っていうか 2003 の改訂で入らなかったのはなぜ?



881 名前:デフォルトの名無しさん mailto:sage [2008/02/27(水) 15:57:01 ]
>>880
禿がまた忘れたんだろ

882 名前:デフォルトの名無しさん mailto:sage [2008/02/27(水) 19:25:26 ]
rangeがどうなるかだな

883 名前:デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:25:33 ]
>>879
どっちかというとOOの世界に土足で上がり込もうとした
総称型プログラミングの要素の側が勝手に苦労してるだけに見える。
継承使ったら型推論できませんとか暗黙のキャストができませんとか。
マルチパラダイムになってOOサイドで何か問題起きてる?
むしろコンテナみたいな値系オブジェクトを下のレイヤに追い出すことで、
OOを純化できると思うんだけど。

884 名前:デフォルトの名無しさん mailto:sage [2008/02/27(水) 22:46:38 ]
完全なOOとか、OOを純化とかには興味無いんだと思うよ。w
一言で言えば「宗旨が違う」

885 名前:デフォルトの名無しさん [2008/02/28(木) 00:09:21 ]
C++はOO側が極端に少ない=OOが蔑ろにされる
という構図がある。

つまり、そのときOOが成立するコードという理由で
OO前提のコードを書いてしまうと

将来OO否定派が紛れ込んだときに混乱の元になるということ。


886 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 00:10:53 ]
>>885
3回読んだけど意味が判らん

887 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 01:37:54 ]
対立問題にしてどうしたいんだ

888 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:12:14 ]
"virtual"を標準ライブラリから検索してみれば
OOはC++自身に拒否されていると分かる
禿げ涙目である

889 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 08:25:52 ]
>>887
勝利したいんだろ

ほっとこうぜ

890 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 11:55:41 ]
ふむ。OOをNGワードに登録、と。



891 名前:デフォルトの名無しさん mailto:sage [2008/02/28(木) 12:44:18 ]
WO

892 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 00:48:00 ]
元々何の信念もなく便利だからって適当に機能ぶちこんだだけのグチャグチャ言語に
今更何を言ってるんだ

893 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 01:03:24 ]
>>892
馬鹿にされるから他では言わないほうがいいよ、その脳内C++ヒストリー。

894 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:19:46 ]
そうですか
じゃあこのC++と呼ばれる雑多にぶち込まれた大量の機能が
お互いひどい副作用を起こし合ってるグチャグチャ言語は
一体どんな高尚な理念で作られたものなんですか

895 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 02:32:47 ]
DnE 読んどけ

896 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:18:54 ]
無知ゆえに思い上がった口をきく若いオタクが興奮すると、文体似るよな、どういうわけか。

897 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 03:54:17 ]
C++を雑多と呼ぶのはよした方が良い。
JavaやRubyなんかと違って、ここまで基本的な部分から整合性の練られた言語は他にない。
多くの機能は基本的な構文から基本的に導出されるが、JavaやRubyはそれらのプロセスを
すっ飛ばして機能が実装されている事が多く、とても自由と小回りの利く言語じゃない。

898 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 04:25:57 ]
Javaは曲がりなりにも「現実世界で、現実をどうにかするために」歩みを進めてきたけど、
Rubyは話にならない。現実よりも白昼夢のほうが大事な、言語オタの妄想の産物。
前線には一切出ず、安全地帯で仲間とダベりながら延々「クールな匍匐前進」を模索してる兵士が、
「俺はこの最高の匍匐前進でこの戦争を生き抜いてるんだ」って真顔で言い張ってるみたいな言語。役立たず。

899 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:02:14 ]
という話はスレ違いなのでよそでやろうな。

900 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 05:27:54 ]
技術レベルの低い話は華麗にスルーしましょうよ。
規格ドラフトを読むような人が集まってんだからさ。





901 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 09:52:56 ]
糞してくるわ

902 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:34:26 ]
スルーなの?
具体的にどのようなひどい副作用があったのか聞きたいんだが

903 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 10:41:11 ]
>>902
妄想を聞きたいならせめてマ板でやってくれ。

904 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 11:34:16 ]
いい糞出たわ

905 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 12:28:11 ]
895 もかいてるが、Design&Evolution of C++ を読んでから出直してこいとしか言い様がない

906 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 13:20:10 ]
ちゃんとした本を読むと、最初の意見(>>892)を変えなきゃいけなくなるから、
ここで文章の素人達に不完全で不足の多い文章を書かせて、それに向かって
そんなの信念があるうちに入らない、適当でしかない、と言って初期設定を維持するつもりなのでは。

907 名前:デフォルトの名無しさん [2008/02/29(金) 14:21:08 ]
ミスを犯すのは常に人。

初心者にはそれがわからんのです。


908 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:53:25 ]
同じ予約語に3つも4つもまったく違った意味を与えたり
機能を作るたびに別の目的に悪用されて、同じような機能を何度も付け足す羽目になったり
無節操に記号に新しい意味を与えまくってパースを複雑怪奇にしたり
わざとミスさせようとしてるとしか思えませんが

909 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 17:55:11 ]
マジレスすると無節操に記号に新しい意味を与えまくってもパースは複雑怪奇にはならない。

910 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:06:13 ]
例えば不等号なんぞを無理矢理カッコ的なものに仕立てたせいで
どれだけの脳内パーサが誤作動してると思う?
includeで使ってるからってなんも考えずにプリプロセッサの世界からコンパイラの世界に
持ち込んだバカのせいじゃないか
違うか



911 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:08:29 ]
無知なまま何を「思っ」たところで的外れなだけだから、
無知でなくなるための行動を起こすべきだろうね。既に本も薦められているのだし。

「何故それはそうでなければならなかったのか」という話に関して、
C++ほどシリアスでプラグマティックな内容盛り沢山の言語もそうは無い。
他の言語が「だってそのほうがきれいなんだもん」くらいの理由で決めちゃうところでも、
C++は「現実」を相手に、全然別の戦いをし続けてきたからな。

今の君の頭からは、>>892を裏付ける話は一切出てこないから、マシな頭になる努力をまずしよう。

912 名前:デフォルトの名無しさん [2008/02/29(金) 18:11:01 ]
何も考えていないことにしたい人が
考えの跡をしこたま記した本をこわがってるスレはここですね

913 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:15:41 ]
じゃあ何をどう考えてるのか教えてくれよ
例えばstaticという語がバラバラのまったく違う4つの意味を持っていた方がよいと考えた理由教えて
その本に書いてあるんだろ

914 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 18:21:40 ]
ああ、これが>>906の読んだ展開か

915 名前:デフォルトの名無しさん [2008/02/29(金) 19:09:57 ]
>>911
Javaやスクリプト言語は「現場の実情」に応える方向で発展したけど、
C++はそれ以前に「数学的現実」に足をすくわれ続けているような。
slice_arrayが動かないとかvector<bool>がコンテナじゃないとか。
テンプレートなんて、パースできなくてtypenameキーワードなんてものが
必要になった時点で常識的には破綻したというべきだし、
チューリング完全性が明らかになった時点でもう一度破綻している。
こうなるくらいだったらC++コンパイラにMLインタプリタでも組み込んだ方がマシ。

916 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:17:25 ]
>>913
残念ながら、無名名前空間でファイルスコープのstaticを排除して、
C++のstaticは静的メンバという意味しか持たないようになったという流れなんだが。

917 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:30:19 ]
>>915
>テンプレートなんて、パースできなくてtypenameキーワードなんてものが
>必要になった時点で常識的には破綻したというべきだし、
これは理解できるとして

>チューリング完全性が明らかになった時点でもう一度破綻している。
こっちはなぜ?

918 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:51:55 ]
メタプログラミングなんて邪悪だしJavaに無いし要らないってこと。

C++ の利用者は喜んで便利に使ってるが、それはそいつらが悪趣味な
せいであって、断じてテンプレートの利便性を証明するものではない。

919 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:53:11 ]
テンプレートはあくまでもジェネリクス用の構文であって
ありとあらゆることに悪用できる万能の箱として用意されたものではないだろ
C++マニアはそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではgoto文と大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

920 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:20 ]
テンプレートメタプログラミングは「発見」されたのだ!とか誇らしげに言ってるC++信者とかたまにいるけど
それって結局は自分らが加えた仕組みが何をもたらすのか、誰もわかってなかったってことじゃないの

あ、C++は全てにおいて考え抜かれた言語だから当然DnEには想定の範囲内だったと書いてあるんですよね
サーセン



921 名前:デフォルトの名無しさん [2008/02/29(金) 19:59:29 ]
テンプレート、ポインタ、動的確保はgotoと同じく排除しよう
現物使用は避けるべき
STLを主軸に据える

922 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 19:59:49 ]
あんまり本気で主張するつもりはないけど:

Javaのバイトコードは本来ポータビリティのためのものであって、直接バイトコードをいじって
なんでもできる万能の素材として用意されたものではないだろ
DI 信者はそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではアセンブラと大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

という状況と対比するとC++の方がまだ健全に思える。

923 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:02:05 ]
>>921
矛盾していないか?テンプレートとSTLとか。

924 名前:デフォルトの名無しさん [2008/02/29(金) 20:05:36 ]
現物 = テンプレート、ポインタ、動的確保
ラッパー = STL

925 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:05:38 ]
try-catch文の醜悪さに比べれば、丁寧に書かれたgoto文の例外処理の方がずっと読みやすいし美しいと思う
ごめん関係なかった

926 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:06:49 ]
>>919
Cのプリプロセッサでジェネリクス実現しちゃう人だっていたんだから、
C++でそれ用の構文を用意したのは一歩進化だろ。
C++0xでconstexprも用意されたし、さらに一歩前進してるじゃないか。

なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

927 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:42:43 ]
>>919
>メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

shiroさんも最近似たこと言ってたね。

ttp://reddit.com/info/62o9s/comments/
>Lispマクロを言語に入れない理由として、
>よく「文法が変わるから他人の書いたコードが読めなくなる」と言われますが、
>カンマ演算子をこんな使い方したらもう充分読めないでしょうってことです。

928 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 20:43:47 ]
>>926
> なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

限界を試すのは重要と思われ。
ジャンボジェットのお披露目でバレルロールだっけ? やっちゃったテストパイロットみたいに。

それをプロダクトに積極的に使おうとかやりだすと、ちょwww だけど。

929 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 21:24:04 ]
>>920
ちょっと論点のずらし方が卑怯すぎて気持ち悪いなぁ、君は。
DnEが証明するのは、「何も考えていないわけではないこと」であって、「すべてを考えていたこと」ではないよ。
そして、少しでも「考えていたこと」があれば、>>892が馬鹿なことを言っていたことになるのを、忘れちゃダメだよ。

930 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:32:22 ]
C++でgotoなんて危険すぎて使えんわ。
そのための例外なのに。



931 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:39:45 ]
お前は全国の後藤さんを敵に回した

932 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:40:48 ]
gotoさんの髪茹でたい

933 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 22:59:39 ]
ここってなんのスレだったっけ?

934 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:07:04 ]
次スレ建てました
pc11.2ch.net/test/read.cgi/tech/1191754720/

935 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:11:43 ]
>>933
美少女中学生が顔を赤らめながら指の隙間からチラチラと覗くスレ

936 名前:デフォルトの名無しさん mailto:sage [2008/02/29(金) 23:34:59 ]
大体他人が自分自身と一緒にPCを見ていなければ、顔は赤らめても赤らめなくてもどうでも良いけど
恥ずかしがって指の隙間から顔を隠しつつ見なくてもいいだろ。
最近の子供は意識の根底に公私混同が見られて将来が危ぶまれるな。本当にしっかりしてほしい。

937 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 01:30:58 ]
まあ、繰り返しになるが、DnE 読んでから出直せとしか言い様がない。

あれは C++ 信者でない人にとっても、どのような方針で言語を拡張していくと
こういうトンでもないことになってしまうのかという様子が詳細に書いてある
という点で非常に勉強になりますよ。C++ スレで煽るためにも、
すぐ反論されないように基礎知識を磨いておくことも重要です。
まずは敵を知ることからです。

というわけで DnE 読んでから出直してください

938 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:04:38 ]
了解です。

939 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:33:45 ]
try節ローカルなオブジェクトをcatch節で見られるようにさえなれば何でもいいよ

940 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:35:39 ]
それは同意
Hoge* p;
try{
p= new Hoge();
}catch(){
}
とかダサすぎる
pそこに置く意味ねぇだろと



941 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 03:29:56 ]
>>939-940
try{
Hoge* p = new Hoge();
}catch(){
}

仮に catch の中で p が見れたとして、 new Hoge() から例外が飛んだ場合は
p の初期化が済んでないわけだが、そんなものを見られるようにして何に使うの?

942 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:44:04 ]
>>941はわざとか?天然か?

943 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 08:54:03 ]
これがポインタではなくデストラクタのあるクラスのインスタンスだと考えると
スコープの差異による影響は?

944 名前:デフォルトの名無しさん [2008/03/01(土) 09:59:01 ]
確かに>>940は例が悪いな

945 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:10:34 ]
例が悪さが、他人の頭の悪さを引き出したケース。

946 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 10:32:56 ]
初心者スレ行けと

947 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:00:25 ]
上の例ならスマートポインタ使うよな。

948 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 18:36:38 ]
ぬるぽ

949 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:54:46 ]
華麗にスルー

950 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:55:59 ]
>>941
using {
 Hoge* p = NULL;
} try {
 p = new Hoge();
} catch(...) {
 // p を使用
}

こうすればいい。



951 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 19:56:52 ]
突っ込んじゃ負けとかいうゲームですか?

952 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:00:30 ]
コンストラクタの中で例外を投げるなんて変態すぎる。

953 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:01:36 ]
RAII全否定ですか

954 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:00 ]
>>952
m9(^Д^)プギャー
www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html

955 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:04:10 ]
RAII()笑

956 名前:952 mailto:sage [2008/03/01(土) 20:05:55 ]
(´;ω;`)おっおっううぇああぁああぅぅおぉぉおお

957 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:09:17 ]
C++ ならデストラクタ使えよってことなんだろう。

958 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:10:34 ]
>>956
お前はたぶんオレと同じスレをみている
さぁガイドライン板に帰ろう

959 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 20:15:25 ]
泣いたらスカッとしました。

960 名前:デフォルトの名無しさん mailto:sage [2008/03/01(土) 21:44:46 ]
関係なかった俺まで泣いた



961 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:30:37 ]
>>954
切られている「比較的有名なサイト」ってこれだよね、たぶん。

C MAGAZINE - プログラミングの禁じ手Web版 C++編
ttp://www.cmagazine.jp/src/kinjite/cpp/

適当にうろうろして見たところ、参考にしている人がそれなりにいる様子。
初心者が鵜呑みにするとまずいことを広められるのは困るなー。


962 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 00:41:02 ]
C編はいいんだけどね

963 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:03:15 ]
これ訂正してもらえないの?
いつまでもWeb上に残ってると勘違いするやつが後を絶たないと思うんだけど。
特にポインタのメンバが不定値になるとか、初期化子も知らないような書き方だし。

それともCマガの中の人は確信犯なんだろうか。

964 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:28:38 ]
エキスパートなお前らの間ではコンストラクタで例外投げてもOKって判断なの?

965 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:30:54 ]
自分では投げない場合も、投げられた場合への配慮は必要

966 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:32:30 ]
>>963
糞ページ、糞本認定だけでいいじゃん。
それだって初心者スレでやるべき事だし。
>>963
初心者スレ行って教えて貰ってこい。

967 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:33:16 ]
オブジェクトの構築に失敗したのに例外を投げないコンストラクタを持つクラスなんて、
初心者には使わせたくないな。

968 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:35:23 ]
どっかの腐ったフレームワークの悪影響だろうね

969 名前:964 mailto:sage [2008/03/02(日) 01:41:54 ]
例外を投げないような初期化だけをコンストラクタでやって、
Initialize()とかのメソッドを作ってるんだけど。
なんだ、じゃぁ俺もバンバン例外なげるようにするよ

970 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:51:53 ]
>>969
今までそう作ってきたなら、あえて変える必要は無いんじゃない。
問題なのは、「安全な処理のみでコンストラクタを実装していること」ではなく、
「安全でない処理に失敗したときに例外を投げないこと」なのだから。



971 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 01:53:18 ]
今気づいたけどスレ違いだな

972 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 08:25:21 ]
うっすらと恥ずかしい毛が生えてきた美少女中学生のスリット違い

973 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 10:47:13 ]
古いんだよなアレ今となっては。著者が表に出る活動を凍結してるせいも
あるんだろうが。

974 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 15:29:11 ]
RAIIイディオムが一般的じゃなかった時代の知識だね
今となっては古臭い

975 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:02:27 ]
90年代から知られてるんだけどなw
そのための初期化子リストだし。

976 名前:デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:16:51 ]
自分は何歳の若い美少女に手を付けたことがあるぞ〜って自慢する人がいるよね

俺は中学生が最高だと思いますが。おっぱい

977 名前:デフォルトの名無しさん mailto:sage [2008/03/04(火) 12:43:23 ]
手を付けたことはないが
手に付いたことはある

978 名前:デフォルトの名無しさん mailto:sage [2008/03/04(火) 13:11:08 ]
手を付けたことはないが、
懐かれたことはある。

979 名前:デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:05:29 ]
おまえらここは0x歳の美少女に手をつけるスレじゃないぞ

980 名前:デフォルトの名無しさん mailto:sage [2008/03/04(火) 22:33:52 ]
8歳未満はさすがにちょっと



981 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:10:09 ]
何進なのかが問題だ

982 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:14:59 ]
0頭でC系なら8進だろ、で1桁だから8歳未満

983 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:15:30 ]
x が数値として使われている以上、34進数以上だろう。
そして、34進数以上のどの進数だろうが、
0x は 33 になる。
X と x を使い分けるとなってくると話は変わってくるが・・・。

984 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:28:38 ]
33で美少女はねーよwってかそろそろスレチだからおわろー

985 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 00:29:50 ]
つか、スレ自体が終わりそうだし

986 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 01:40:31 ]
そういえば1000が近いな






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<207KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef