1001コメント266KB

C++0x 2

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2007/10/08(月) 20:29:11

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

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

0002デフォルトの名無しさん

2007/10/08(月) 20:44:39

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

0003デフォルトの名無しさん

2007/10/08(月) 21:29:39

ん？　こっち使うの

0004デフォルトの名無しさん

2007/10/08(月) 21:33:37

よし、こっちを使おうぜ

0005デフォルトの名無しさん

2007/10/08(月) 21:52:06

>>1
乙

0006デフォルトの名無しさん

2007/10/08(月) 21:53:14

こっちでいくか。

0007デフォルトの名無しさん

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

0008デフォルトの名無しさん

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++"

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

0009デフォルトの名無しさん

2007/10/08(月) 22:15:41

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

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

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

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

0010デフォルトの名無しさん

2007/10/08(月) 22:41:24

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

0011デフォルトの名無しさん

2007/10/08(月) 23:00:04

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

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

0012デフォルトの名無しさん

2007/10/08(月) 23:04:28

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

0013デフォルトの名無しさん

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;

でいいのかな?

0014デフォルトの名無しさん

2007/10/08(月) 23:41:48

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

0015デフォルトの名無しさん

2007/10/09(火) 00:14:38

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

0016デフォルトの名無しさん

2007/10/09(火) 00:28:29

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

0017デフォルトの名無しさん

2007/10/09(火) 00:43:08

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

0018デフォルトの名無しさん

2007/10/09(火) 01:05:02

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

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

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

0019デフォルトの名無しさん

2007/10/09(火) 01:06:12

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

0020デフォルトの名無しさん

2007/10/09(火) 01:30:47

>>18
×duble
○double

0021デフォルトの名無しさん

2007/10/09(火) 01:35:53

using duble = double;

0022デフォルトの名無しさん

2007/10/09(火) 01:51:47

#define duble double

0023デフォルトの名無しさん

2007/10/09(火) 01:52:32

typedef double duble;

0024デフォルトの名無しさん

2007/10/09(火) 02:29:02

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

0025デフォルトの名無しさん

2007/10/09(火) 02:30:35

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

0026デフォルトの名無しさん

2007/10/09(火) 09:40:10

#define private public

0027デフォルトの名無しさん

2007/10/09(火) 12:47:17

#define class struct

0028デフォルトの名無しさん

2007/10/09(火) 15:46:48

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

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

0029デフォルトの名無しさん

2007/10/09(火) 16:36:27

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

0030デフォルトの名無しさん

2007/10/09(火) 16:42:21

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

0031デフォルトの名無しさん

2007/10/09(火) 16:43:08

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

0032デフォルトの名無しさん

2007/10/09(火) 16:44:10

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

0033デフォルトの名無しさん

2007/10/09(火) 16:48:49

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

0034デフォルトの名無しさん

2007/10/09(火) 17:01:14

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

ただしバグだらけ

0035デフォルトの名無しさん

2007/10/09(火) 17:02:05

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

0036デフォルトの名無しさん

2007/10/09(火) 17:03:10

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

0037デフォルトの名無しさん

2007/10/09(火) 20:08:28

boostに#ifdefの嵐が

0038デフォルトの名無しさん

2007/10/10(水) 12:35:20

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

0039デフォルトの名無しさん

2007/10/10(水) 18:23:55

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

0040デフォルトの名無しさん

2007/10/11(木) 05:59:41

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

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

0041デフォルトの名無しさん

2007/10/11(木) 06:27:54

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

0042デフォルトの名無しさん

2007/10/11(木) 08:24:12

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

0043デフォルトの名無しさん

2007/10/11(木) 10:49:04

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

0044デフォルトの名無しさん

2007/10/11(木) 17:50:13

TR?は一般人は無関係。

0045デフォルトの名無しさん

2007/10/11(木) 18:43:03

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

0046デフォルトの名無しさん

2007/10/11(木) 19:36:01

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

0047デフォルトの名無しさん

2007/10/11(木) 19:39:26

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

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

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

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

0048デフォルトの名無しさん

2007/10/11(木) 21:24:46

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

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

みたいな奴

0049デフォルトの名無しさん

2007/10/11(木) 21:56:02

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

0050デフォルトの名無しさん

2007/10/11(木) 22:04:29

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

0051デフォルトの名無しさん

2007/10/12(金) 01:27:50

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

0052デフォルトの名無しさん

2007/10/12(金) 06:44:24

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

0053デフォルトの名無しさん

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

0054デフォルトの名無しさん

2007/10/12(金) 17:15:28

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

0055デフォルトの名無しさん

2007/10/12(金) 17:39:48

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

0056デフォルトの名無しさん

2007/10/12(金) 18:29:10

㌧

0057デフォルトの名無しさん

2007/10/12(金) 19:58:56

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

0058デフォルトの名無しさん

2007/10/12(金) 22:27:28

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

0059デフォルトの名無しさん

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)

0060デフォルトの名無しさん

2007/10/13(土) 00:04:35

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

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

でもnullptr不要には同意。

0061デフォルトの名無しさん

2007/10/13(土) 00:18:01

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

0062デフォルトの名無しさん

2007/10/13(土) 00:18:02

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

0063デフォルトの名無しさん

2007/10/13(土) 00:28:59

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

0064デフォルトの名無しさん

2007/10/13(土) 02:14:03

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

0065デフォルトの名無しさん

2007/10/13(土) 02:51:43

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

0066デフォルトの名無しさん

2007/10/13(土) 04:42:02

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

0067デフォルトの名無しさん

2007/10/13(土) 09:17:37

nullptrに特殊化させたい。

0068デフォルトの名無しさん

2007/10/13(土) 09:28:11

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

0069デフォルトの名無しさん

2007/10/13(土) 12:09:20

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

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

0070デフォルトの名無しさん

2007/10/13(土) 12:11:25

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

007170

2007/10/13(土) 12:38:51

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

0072デフォルトの名無しさん

2007/10/13(土) 12:44:48

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

0073デフォルトの名無しさん

2007/10/13(土) 16:29:41

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

0074デフォルトの名無しさん

2007/10/13(土) 16:56:24

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

0075デフォルトの名無しさん

2007/10/13(土) 17:05:59

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

0076デフォルトの名無しさん

2007/10/13(土) 17:18:33

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

0077デフォルトの名無しさん

2007/10/13(土) 18:32:59

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

0078デフォルトの名無しさん

2007/10/13(土) 21:29:45

#define nullpo nullptr

0079デフォルトの名無しさん

2007/10/13(土) 21:32:11

>>78
誰かやると思った

#if defined nullpo
#define ga nullpo

0080デフォルトの名無しさん

2007/10/13(土) 21:37:10

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

0081デフォルトの名無しさん

2007/10/13(土) 21:46:52

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

0082デフォルトの名無しさん

2007/10/13(土) 21:51:51

#endif

0083デフォルトの名無しさん

2007/10/13(土) 23:22:06

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

0084デフォルトの名無しさん

2007/10/13(土) 23:25:20

やんぬるかな

0085デフォルトの名無しさん

2007/10/13(土) 23:28:42

病ん（でる）null？

0086デフォルトの名無しさん

2007/10/14(日) 02:59:02

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

0087デフォルトの名無しさん

2007/10/14(日) 03:55:27

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

0088デフォルトの名無しさん

2007/10/14(日) 03:56:30

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

0089デフォルトの名無しさん

2007/10/14(日) 04:08:52

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

0090デフォルトの名無しさん

2007/10/14(日) 05:31:31

はわわわわ

0091デフォルトの名無しさん

2007/10/14(日) 08:59:17

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

0092デフォルトの名無しさん

2007/10/14(日) 09:00:16

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

0093デフォルトの名無しさん

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 そのものが出てこない限りプログラムの意味論には影響しないと思われる。

0094デフォルトの名無しさん

2007/10/16(火) 21:52:03

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

0095デフォルトの名無しさん

2007/10/16(火) 22:06:33

C(i) （c omeko）

0096デフォルトの名無しさん

2007/10/17(水) 00:05:20

Cω (c sorewa watashi no oinarisan da)

0097デフォルトの名無しさん

2007/10/17(水) 01:09:25

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

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

0098デフォルトの名無しさん

2007/10/17(水) 01:16:47

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

0099デフォルトの名無しさん

2007/10/17(水) 03:21:29

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

0100デフォルトの名無しさん

2007/10/17(水) 03:36:30

2ch見すぎ

0101デフォルトの名無しさん

2007/10/17(水) 08:04:36

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

0102デフォルトの名無しさん

2007/10/17(水) 08:36:11

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

0103デフォルトの名無しさん

2007/10/17(水) 09:45:29

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

0104デフォルトの名無しさん

2007/10/17(水) 10:46:04

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

0105デフォルトの名無しさん

2007/10/17(水) 11:10:13

std::time_get じゃ不足?

0106デフォルトの名無しさん

2007/10/17(水) 11:37:03

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

0107デフォルトの名無しさん

2007/10/17(水) 13:06:28

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

0108デフォルトの名無しさん

2007/10/18(木) 17:35:17

>>107
日本語でおｋ

0109デフォルトの名無しさん

2007/10/19(金) 12:14:52

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

0110デフォルトの名無しさん

2007/10/19(金) 12:48:57

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

0111デフォルトの名無しさん

2007/10/19(金) 14:12:07

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

0112デフォルトの名無しさん

2007/10/19(金) 14:15:54

自分のこと?

0113デフォルトの名無しさん

2007/10/19(金) 17:17:15

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

0114デフォルトの名無しさん

2007/10/19(金) 18:01:36

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

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

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

0115デフォルトの名無しさん

2007/10/19(金) 19:11:25

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

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

0116デフォルトの名無しさん

2007/10/19(金) 23:42:39

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

0117デフォルトの名無しさん

2007/10/20(土) 00:35:20

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

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

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

0118デフォルトの名無しさん

2007/10/20(土) 10:03:14

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

0119デフォルトの名無しさん

2007/10/20(土) 10:42:50

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

0120デフォルトの名無しさん

2007/10/20(土) 11:52:29

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

0121デフォルトの名無しさん

2007/10/20(土) 12:10:38

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

0122デフォルトの名無しさん

2007/10/20(土) 12:40:26

>>121
日本語でok

0123デフォルトの名無しさん

2007/10/20(土) 12:44:54

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

0124デフォルトの名無しさん

2007/10/20(土) 12:47:08

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

0125デフォルトの名無しさん

2007/10/20(土) 12:54:28

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

0126デフォルトの名無しさん

2007/10/20(土) 12:56:45

俺もわからん

0127デフォルトの名無しさん

2007/10/20(土) 13:25:22

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

0128デフォルトの名無しさん

2007/10/20(土) 13:34:59

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

前者はboost::noncopyableとかかな

0129デフォルトの名無しさん

2007/10/20(土) 13:35:06

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

0130デフォルトの名無しさん

2007/10/20(土) 13:37:03

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

0131デフォルトの名無しさん

2007/10/20(土) 13:42:54

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

0132デフォルトの名無しさん

2007/10/20(土) 13:56:27

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

0133デフォルトの名無しさん

2007/10/20(土) 14:51:30

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

0134デフォルトの名無しさん

2007/10/20(土) 18:30:41

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

0135デフォルトの名無しさん

2007/10/20(土) 19:07:03

ワーオ

0136デフォルトの名無しさん

2007/10/20(土) 19:38:39

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

0137デフォルトの名無しさん

2007/10/20(土) 20:25:15

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

0138デフォルトの名無しさん

2007/10/20(土) 20:29:40

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

0139デフォルトの名無しさん

2007/10/21(日) 00:44:34

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

0140デフォルトの名無しさん

2007/10/21(日) 08:09:56

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

0141デフォルトの名無しさん

2007/10/21(日) 08:50:04

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

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

0142デフォルトの名無しさん

2007/10/21(日) 12:16:27

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

0143デフォルトの名無しさん

2007/10/21(日) 12:34:06

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

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

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

0144デフォルトの名無しさん

2007/10/21(日) 16:12:47

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

0145デフォルトの名無しさん

2007/10/21(日) 17:08:26

>>143

>sizeofを使った特殊化
kwsk

0146デフォルトの名無しさん

2007/10/21(日) 20:24:43

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

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

0147デフォルトの名無しさん

2007/10/21(日) 20:29:43

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

0148デフォルトの名無しさん

2007/10/21(日) 21:20:39

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

0149デフォルトの名無しさん

2007/10/21(日) 21:28:11

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

0150デフォルトの名無しさん

2007/10/21(日) 23:00:47

ロリコンの女ｗｗ

0151デフォルトの名無しさん

2007/10/21(日) 23:29:37

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

0152デフォルトの名無しさん

2007/10/22(月) 01:19:30

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

0153デフォルトの名無しさん

2007/10/22(月) 01:49:31

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

0154デフォルトの名無しさん

2007/10/22(月) 01:50:40

>>153
誰だよ？w

0155デフォルトの名無しさん

2007/10/22(月) 23:35:35

俺俺、俺だって

0156デフォルトの名無しさん

2007/10/22(月) 23:53:16

おまえかあ

0157デフォルトの名無しさん

2007/10/23(火) 00:11:43

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

0158デフォルトの名無しさん

2007/10/23(火) 10:36:59

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

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

0159デフォルトの名無しさん

2007/10/23(火) 10:38:33

賛成

0160デフォルトの名無しさん

2007/10/23(火) 11:54:33

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

0161デフォルトの名無しさん

2007/10/23(火) 12:59:28

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

0162デフォルトの名無しさん

2007/10/23(火) 14:29:32

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

0163デフォルトの名無しさん

2007/10/23(火) 14:57:09

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

0164デフォルトの名無しさん

2007/10/23(火) 15:34:17

>>163
-Wshadow かな?

0165デフォルトの名無しさん

2007/10/23(火) 15:39:11

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

0166デフォルトの名無しさん

2007/10/23(火) 15:58:32

なぜ？

0167デフォルトの名無しさん

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'

0168デフォルトの名無しさん

2007/10/23(火) 16:16:12

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

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

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

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

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

0169デフォルトの名無しさん

2007/10/23(火) 16:53:40

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

0170デフォルトの名無しさん

2007/10/23(火) 16:55:24

なぜ？

0171デフォルトの名無しさん

2007/10/23(火) 19:08:56

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

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

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

0172デフォルトの名無しさん

2007/10/23(火) 19:14:01

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

0173165

2007/10/23(火) 20:11:50

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

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

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

0174デフォルトの名無しさん

2007/10/23(火) 20:27:42

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

0175デフォルトの名無しさん

2007/10/23(火) 21:25:50

>>165

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

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

0176165

2007/10/23(火) 21:34:33

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

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

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

0177デフォルトの名無しさん

2007/10/23(火) 21:53:21

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

0178デフォルトの名無しさん

2007/10/24(水) 00:54:02

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

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

0179デフォルトの名無しさん

2007/10/24(水) 03:16:53

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

0180デフォルトの名無しさん

2007/10/24(水) 11:20:58

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

0181デフォルトの名無しさん

2007/10/25(木) 00:16:13

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

0182デフォルトの名無しさん

2007/10/25(木) 03:55:26

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

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

0183デフォルトの名無しさん

2007/10/25(木) 07:57:24

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

0184デフォルトの名無しさん

2007/10/25(木) 08:01:26

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

0185デフォルトの名無しさん

2007/10/25(木) 09:10:11

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

0186デフォルトの名無しさん

2007/10/25(木) 10:06:50

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

0187デフォルトの名無しさん

2007/10/25(木) 11:06:48

特に auto が。

0188デフォルトの名無しさん

2007/10/25(木) 13:29:38

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

0189デフォルトの名無しさん

2007/10/25(木) 13:41:15

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

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

0190デフォルトの名無しさん

2007/10/25(木) 13:57:34

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

0191デフォルトの名無しさん

2007/10/25(木) 22:08:42

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

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

0192デフォルトの名無しさん

2007/10/25(木) 22:17:37

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

0193デフォルトの名無しさん

2007/10/25(木) 22:28:36

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

0194デフォルトの名無しさん

2007/10/25(木) 22:32:59

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

0195デフォルトの名無しさん

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要らずだな

0196デフォルトの名無しさん

2007/10/25(木) 22:36:44

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

0197デフォルトの名無しさん

2007/10/25(木) 22:48:06

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

0198デフォルトの名無しさん

2007/10/26(金) 00:09:59

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

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

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

0199デフォルトの名無しさん

2007/10/26(金) 00:51:25

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

0200デフォルトの名無しさん

2007/10/26(金) 01:05:36

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

0201198

2007/10/26(金) 01:35:31

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

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

0202199

2007/10/26(金) 01:44:20

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

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

0203198

2007/10/26(金) 03:26:09

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

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

0204199

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 だから救われないけど。

0205デフォルトの名無しさん

2007/10/26(金) 15:28:41

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

0206デフォルトの名無しさん

2007/10/26(金) 16:23:30

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

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

0207デフォルトの名無しさん

2007/10/26(金) 21:48:45

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

0208デフォルトの名無しさん

2007/10/26(金) 22:42:06

push_back(T val,bool uramode=true)

0209デフォルトの名無しさん

2007/10/26(金) 22:45:16

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

0210デフォルトの名無しさん

2007/10/27(土) 00:35:22

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

0211デフォルトの名無しさん

2007/10/27(土) 00:47:04

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

0212デフォルトの名無しさん

2007/10/27(土) 01:07:04

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

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

0213デフォルトの名無しさん

2007/10/27(土) 01:09:12

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

0214デフォルトの名無しさん

2007/10/27(土) 01:12:22

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

0215デフォルトの名無しさん

2007/10/27(土) 01:26:38

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

0216デフォルトの名無しさん

2007/10/27(土) 04:01:16

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

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

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

0217デフォルトの名無しさん

2007/10/27(土) 10:07:03

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

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

0218デフォルトの名無しさん

2007/10/27(土) 10:39:08

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

0219デフォルトの名無しさん

2007/10/27(土) 13:46:39

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

0220デフォルトの名無しさん

2007/10/27(土) 13:50:12

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

0221デフォルトの名無しさん

2007/10/27(土) 13:58:08

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

0222デフォルトの名無しさん

2007/10/27(土) 14:20:42

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

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

0223デフォルトの名無しさん

2007/10/27(土) 16:13:50

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

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

0224デフォルトの名無しさん

2007/10/27(土) 16:57:44

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

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

0225デフォルトの名無しさん

2007/10/27(土) 18:14:05

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

0226デフォルトの名無しさん

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 は混ぜるな、に一票。

0227デフォルトの名無しさん

2007/10/27(土) 21:57:34

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

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

0228デフォルトの名無しさん

2007/10/28(日) 00:21:59

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

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

0229デフォルトの名無しさん

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 とか使えばほんとに非決定計算っぽくできるかもしれない。

0230デフォルトの名無しさん

2007/10/28(日) 01:47:11

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

0231デフォルトの名無しさん

2007/10/28(日) 02:22:58

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

0232デフォルトの名無しさん

2007/10/28(日) 02:40:30

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

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

0233デフォルトの名無しさん

2007/10/28(日) 07:13:39

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

0234デフォルトの名無しさん

2007/10/28(日) 08:12:40

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

0235デフォルトの名無しさん

2007/10/28(日) 09:42:07

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

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

0236デフォルトの名無しさん

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 使って木を生成した後で、"
　　　　"評価するときにこっちで勝手にショートカット評価してやればいい。"
　 );
　}
}

0237デフォルトの名無しさん

2007/10/28(日) 13:16:45

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

0238デフォルトの名無しさん

2007/10/28(日) 14:26:16

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

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

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

0239デフォルトの名無しさん

2007/10/28(日) 14:27:02

ちょっと言い過ぎた。

0240デフォルトの名無しさん

2007/10/28(日) 21:06:43

ぬこぬこ

0241デフォルトの名無しさん

2007/10/28(日) 23:35:22

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

0242デフォルトの名無しさん

2007/10/28(日) 23:45:22

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

0243デフォルトの名無しさん

2007/10/28(日) 23:53:31

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

0244デフォルトの名無しさん

2007/10/29(月) 00:33:23

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

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

0245デフォルトの名無しさん

2007/10/29(月) 00:35:59

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

0246デフォルトの名無しさん

2007/10/29(月) 00:37:33

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

0247デフォルトの名無しさん

2007/10/29(月) 00:42:32

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

0248デフォルトの名無しさん

2007/10/29(月) 00:48:29

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

0249デフォルトの名無しさん

2007/10/29(月) 00:50:16

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

0250デフォルトの名無しさん

2007/10/29(月) 01:14:46

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

0251デフォルトの名無しさん

2007/10/29(月) 01:19:58

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

0252デフォルトの名無しさん

2007/10/29(月) 05:15:01

stringstream でええやん。

0253デフォルトの名無しさん

2007/10/29(月) 20:02:05

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

0254デフォルトの名無しさん

2007/10/29(月) 21:34:04

>>253
仕組み説明してYO

0255デフォルトの名無しさん

2007/10/29(月) 22:56:21

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

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

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

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

0256デフォルトの名無しさん

2007/10/29(月) 23:10:53

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

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

0257デフォルトの名無しさん

2007/10/29(月) 23:17:18

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

0258デフォルトの名無しさん

2007/10/29(月) 23:21:14

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

0259デフォルトの名無しさん

2007/10/30(火) 00:06:35

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

0260デフォルトの名無しさん

2007/10/30(火) 00:06:49

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

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

0261デフォルトの名無しさん

2007/10/30(火) 00:10:58

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

0262デフォルトの名無しさん

2007/10/30(火) 00:15:56

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

0263デフォルトの名無しさん

2007/10/30(火) 00:17:38

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

0264デフォルトの名無しさん

2007/10/30(火) 00:21:24

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

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

だったら同意。

0265デフォルトの名無しさん

2007/10/30(火) 00:26:09

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

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

0266デフォルトの名無しさん

2007/10/30(火) 00:29:13

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

0267デフォルトの名無しさん

2007/10/30(火) 00:34:18

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

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

0268デフォルトの名無しさん

2007/10/30(火) 01:56:25

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

0269デフォルトの名無しさん

2007/10/30(火) 02:03:57

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

0270デフォルトの名無しさん

2007/10/30(火) 02:06:12

んなこたぁ～ない

0271デフォルトの名無しさん

2007/10/30(火) 02:17:34

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

0272デフォルトの名無しさん

2007/10/30(火) 05:11:26

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

0273デフォルトの名無しさん

2007/10/30(火) 08:21:15

まさにC++は男坂

0274デフォルトの名無しさん

2007/10/30(火) 09:18:28

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

0275デフォルトの名無しさん

2007/10/30(火) 12:33:27

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

0276デフォルトの名無しさん

2007/10/30(火) 12:57:35

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

0277デフォルトの名無しさん

2007/10/30(火) 13:21:27

なんか変なのキタ

0278デフォルトの名無しさん

2007/10/30(火) 14:53:31

下駄と雪駄？

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

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

0279デフォルトの名無しさん

2007/10/30(火) 17:00:46

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

0280デフォルトの名無しさん

2007/10/30(火) 17:19:19

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

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

0281デフォルトの名無しさん

2007/10/30(火) 18:47:44

D言語マンセー

0282デフォルトの名無しさん

2007/10/30(火) 18:49:20

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

0283デフォルトの名無しさん

2007/10/30(火) 20:20:20

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

0284デフォルトの名無しさん

2007/10/30(火) 21:17:02

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

0285デフォルトの名無しさん

2007/10/30(火) 21:20:42

ん、いいねぇ。

0286デフォルトの名無しさん

2007/10/30(火) 22:06:40

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

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

0287デフォルトの名無しさん

2007/10/30(火) 23:06:29

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

0288デフォルトの名無しさん

2007/10/30(火) 23:23:14

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

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

0289デフォルトの名無しさん

2007/10/30(火) 23:25:26

>>288に一票

0290デフォルトの名無しさん

2007/10/30(火) 23:57:08

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

0291デフォルトの名無しさん

2007/10/30(火) 23:57:24

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

0292デフォルトの名無しさん

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) と展開する合理性が見えません

0293デフォルトの名無しさん

2007/10/31(水) 00:15:31

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

0294デフォルトの名無しさん

2007/10/31(水) 00:28:25

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

0295デフォルトの名無しさん

2007/10/31(水) 00:29:16

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

0296デフォルトの名無しさん

2007/10/31(水) 00:38:40

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

0297デフォルトの名無しさん

2007/10/31(水) 00:55:41

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

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

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

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

0298デフォルトの名無しさん

2007/10/31(水) 01:00:34

レベルひっく～

0299デフォルトの名無しさん

2007/10/31(水) 01:07:11

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

0300デフォルトの名無しさん

2007/10/31(水) 01:32:05

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

0301デフォルトの名無しさん

2007/10/31(水) 02:10:04

バカばーっか。

0302デフォルトの名無しさん

2007/10/31(水) 02:26:48

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

0303デフォルトの名無しさん

2007/10/31(水) 03:38:05

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

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

0304デフォルトの名無しさん

2007/10/31(水) 08:50:15

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

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

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

0305デフォルトの名無しさん

2007/10/31(水) 09:40:43

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

0306デフォルトの名無しさん

2007/10/31(水) 09:41:41

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

0307デフォルトの名無しさん

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);

どっちが大きい？

0308デフォルトの名無しさん

2007/10/31(水) 12:21:10

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

0309デフォルトの名無しさん

2007/10/31(水) 13:45:53

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

0310デフォルトの名無しさん

2007/10/31(水) 13:56:59

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

0311デフォルトの名無しさん

2007/10/31(水) 13:59:14

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

0312デフォルトの名無しさん

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

無理かな。

0313デフォルトの名無しさん

2007/10/31(水) 14:48:07

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

0314デフォルトの名無しさん

2007/10/31(水) 15:35:48

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

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

0315デフォルトの名無しさん

2007/10/31(水) 15:42:33

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

0316デフォルトの名無しさん

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);
}

0317デフォルトの名無しさん

2007/10/31(水) 17:33:19

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

0318デフォルトの名無しさん

2007/10/31(水) 18:38:23

Dとかイラネェ

0319デフォルトの名無しさん

2007/10/31(水) 19:03:55

template <typename _T>
class property {

0320デフォルトの名無しさん

2007/10/31(水) 19:04:28

なかったことにしよう

0321デフォルトの名無しさん

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
}

0322デフォルトの名無しさん

2007/10/31(水) 19:49:38

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

0323デフォルトの名無しさん

2007/10/31(水) 20:47:09

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

0324デフォルトの名無しさん

2007/10/31(水) 21:35:04

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

0325デフォルトの名無しさん

2007/10/31(水) 21:57:53

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

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

0326デフォルトの名無しさん

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

0327デフォルトの名無しさん

2007/11/01(木) 01:57:51

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

0328デフォルトの名無しさん

2007/11/01(木) 07:48:40

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

0329デフォルトの名無しさん

2007/11/01(木) 19:46:00

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

0330デフォルトの名無しさん

2007/11/01(木) 20:32:27

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

0331デフォルトの名無しさん

2007/11/02(金) 03:20:43

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

0332デフォルトの名無しさん

2007/11/02(金) 10:42:00

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

0333デフォルトの名無しさん

2007/11/02(金) 11:02:23

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

0334デフォルトの名無しさん

2007/11/02(金) 11:11:10

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

0335デフォルトの名無しさん

2007/11/02(金) 11:23:07

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

0336デフォルトの名無しさん

2007/11/02(金) 11:57:04

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

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

みたいな。

0337デフォルトの名無しさん

2007/11/02(金) 13:39:58

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

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

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

0338デフォルトの名無しさん

2007/11/02(金) 13:50:31

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

0339デフォルトの名無しさん

2007/11/02(金) 13:58:51

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

0340デフォルトの名無しさん

2007/11/02(金) 21:00:15

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

0341デフォルトの名無しさん

2007/11/02(金) 21:20:46

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

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

0342デフォルトの名無しさん

2007/11/02(金) 22:23:43

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

0343デフォルトの名無しさん

2007/11/02(金) 22:28:18

へーすごいな
感心した

0344デフォルトの名無しさん

2007/11/02(金) 22:32:08

翻訳乙

0345デフォルトの名無しさん

2007/11/02(金) 22:36:47

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

0346デフォルトの名無しさん

2007/11/02(金) 23:07:38

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

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

0347デフォルトの名無しさん

2007/11/03(土) 00:17:33

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

0348デフォルトの名無しさん

2007/11/03(土) 00:26:04

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

0349デフォルトの名無しさん

2007/11/03(土) 00:34:06

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

0350デフォルトの名無しさん

2007/11/03(土) 00:36:35

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

0351デフォルトの名無しさん

2007/11/03(土) 00:41:28

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

0352デフォルトの名無しさん

2007/11/03(土) 08:06:03

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

0353デフォルトの名無しさん

2007/11/03(土) 08:40:08

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

0354デフォルトの名無しさん

2007/11/03(土) 16:00:14

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

0355デフォルトの名無しさん

2007/11/03(土) 17:01:51

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

0356デフォルトの名無しさん

2007/11/03(土) 18:08:58

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

0357デフォルトの名無しさん

2007/11/03(土) 18:37:12

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

0358デフォルトの名無しさん

2007/11/03(土) 18:46:55

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

0359デフォルトの名無しさん

2007/11/03(土) 18:51:32

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

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

0360デフォルトの名無しさん

2007/11/03(土) 19:03:44

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

0361デフォルトの名無しさん

2007/11/03(土) 19:18:50

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

0362デフォルトの名無しさん

2007/11/03(土) 20:23:18

いいから検索しろ、な

0363デフォルトの名無しさん

2007/11/03(土) 21:14:27

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

0364デフォルトの名無しさん

2007/11/03(土) 21:28:44

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

0365デフォルトの名無しさん

2007/11/03(土) 21:43:51

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

0366デフォルトの名無しさん

2007/11/03(土) 22:39:54

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

0367デフォルトの名無しさん

2007/11/03(土) 22:49:15

>>366
ｵﾏｴﾓﾅ

0368デフォルトの名無しさん

2007/11/03(土) 23:00:40

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

0369デフォルトの名無しさん

2007/11/03(土) 23:13:09

うん

0370デフォルトの名無しさん

2007/11/03(土) 23:23:41

もう大人だもんな

0371デフォルトの名無しさん

2007/11/03(土) 23:53:46

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

0372デフォルトの名無しさん

2007/11/03(土) 23:55:27

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

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

0373デフォルトの名無しさん

2007/11/03(土) 23:58:55

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

0374デフォルトの名無しさん

2007/11/04(日) 00:07:08

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

0375デフォルトの名無しさん

2007/11/04(日) 00:48:57

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

0376デフォルトの名無しさん

2007/11/04(日) 00:51:43

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

0377デフォルトの名無しさん

2007/11/04(日) 00:52:56

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

0378デフォルトの名無しさん

2007/11/04(日) 01:35:33

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

0379デフォルトの名無しさん

2007/11/04(日) 01:43:24

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

0380デフォルトの名無しさん

2007/11/04(日) 02:10:37

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

0381デフォルトの名無しさん

2007/11/04(日) 07:31:58

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

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

0382デフォルトの名無しさん

2007/11/04(日) 08:35:36

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

0383デフォルトの名無しさん

2007/11/04(日) 10:10:45

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

0384デフォルトの名無しさん

2007/11/04(日) 12:34:47

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

0385デフォルトの名無しさん

2007/11/04(日) 14:44:05

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

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

0386デフォルトの名無しさん

2007/11/04(日) 16:26:39

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

0387デフォルトの名無しさん

2007/11/04(日) 18:06:56

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

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

0388デフォルトの名無しさん

2007/11/04(日) 21:00:39

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

0389デフォルトの名無しさん

2007/11/05(月) 11:17:05

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

0390デフォルトの名無しさん

2007/11/05(月) 20:47:26

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

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

0391デフォルトの名無しさん

2007/11/05(月) 21:11:47

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

0392デフォルトの名無しさん

2007/11/05(月) 21:20:36

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

0393デフォルトの名無しさん

2007/11/05(月) 22:42:09

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

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

0394デフォルトの名無しさん

2007/11/05(月) 23:18:29

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

0395デフォルトの名無しさん

2007/11/06(火) 00:00:08

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

0396デフォルトの名無しさん

2007/11/07(水) 08:45:15

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

0397デフォルトの名無しさん

2007/11/07(水) 12:01:57

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

0398デフォルトの名無しさん

2007/11/07(水) 13:31:42

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

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

0399デフォルトの名無しさん

2007/11/07(水) 19:07:29

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

0400デフォルトの名無しさん

2007/11/07(水) 19:36:04

自分で作る

0401デフォルトの名無しさん

2007/11/07(水) 19:55:58

あGCCから持ってきました

0402デフォルトの名無しさん

2007/11/07(水) 19:59:48

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

0403デフォルトの名無しさん

2007/11/07(水) 22:26:47

boostつかえ

0404デフォルトの名無しさん

2007/11/07(水) 22:28:18

conceptは間に合うんだろうか

0405デフォルトの名無しさん

2007/11/08(木) 04:58:25

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

0406デフォルトの名無しさん

2007/11/08(木) 10:15:11

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

0407デフォルトの名無しさん

2007/11/08(木) 16:38:53

extern inline とかな

0408デフォルトの名無しさん

2007/11/12(月) 21:22:45

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

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

0409デフォルトの名無しさん

2007/11/13(火) 16:32:10

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

0410デフォルトの名無しさん

2007/11/13(火) 18:52:18

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

0411デフォルトの名無しさん

2007/11/13(火) 23:39:50

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

0412デフォルトの名無しさん

2007/11/13(火) 23:43:32

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

0413デフォルトの名無しさん

2007/11/13(火) 23:45:11

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

0414デフォルトの名無しさん

2007/11/13(火) 23:45:44

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

0415デフォルトの名無しさん

2007/11/13(火) 23:46:51

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

0416デフォルトの名無しさん

2007/11/13(火) 23:57:29

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

0417デフォルトの名無しさん

2007/11/14(水) 00:34:36

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

0418デフォルトの名無しさん

2007/11/14(水) 00:36:10

無料のC++だよね

0419デフォルトの名無しさん

2007/11/14(水) 00:42:19

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

0420デフォルトの名無しさん

2007/11/14(水) 00:54:06

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

0421デフォルトの名無しさん

2007/11/14(水) 00:59:09

C++1x

0422デフォルトの名無しさん

2007/11/14(水) 01:00:38

ISO/IEC 14882:201x

0423デフォルトの名無しさん

2007/11/14(水) 03:37:54

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

0424デフォルトの名無しさん

2007/11/14(水) 03:57:33

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

0425デフォルトの名無しさん

2007/11/14(水) 09:04:35

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

0426デフォルトの名無しさん

2007/11/14(水) 09:58:57

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

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

0427デフォルトの名無しさん

2007/11/14(水) 11:15:53

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

0428デフォルトの名無しさん

2007/11/14(水) 11:59:57

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

0429デフォルトの名無しさん

2007/11/14(水) 13:07:33

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

0430デフォルトの名無しさん

2007/11/14(水) 13:09:48

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

0431デフォルトの名無しさん

2007/11/14(水) 13:26:00

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

0432デフォルトの名無しさん

2007/11/14(水) 14:16:14

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

0433デフォルトの名無しさん

2007/11/14(水) 14:29:17

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

0434デフォルトの名無しさん

2007/11/14(水) 14:43:56

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

0435デフォルトの名無しさん

2007/11/14(水) 14:53:40

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

0436デフォルトの名無しさん

2007/11/14(水) 15:23:22

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

0437デフォルトの名無しさん

2007/11/14(水) 15:30:24

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

0438デフォルトの名無しさん

2007/11/14(水) 15:31:55

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

0439デフォルトの名無しさん

2007/11/14(水) 15:58:51

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

0440デフォルトの名無しさん

2007/11/14(水) 16:12:20

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

0441デフォルトの名無しさん

2007/11/14(水) 18:41:18

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

0442デフォルトの名無しさん

2007/11/14(水) 18:45:56

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

0443デフォルトの名無しさん

2007/11/14(水) 18:51:05

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

0444デフォルトの名無しさん

2007/11/14(水) 18:56:14

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

0445デフォルトの名無しさん

2007/11/14(水) 19:57:26

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

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

0446デフォルトの名無しさん

2007/11/14(水) 20:28:06

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

0447デフォルトの名無しさん

2007/11/14(水) 21:03:44

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

0448デフォルトの名無しさん

2007/11/14(水) 21:31:26

３人いるらしーよ。

0449デフォルトの名無しさん

2007/11/14(水) 21:42:16

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

0450デフォルトの名無しさん

2007/11/14(水) 23:09:23

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

0451デフォルトの名無しさん

2007/11/14(水) 23:47:46

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

0452デフォルトの名無しさん

2007/11/15(木) 02:24:43

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

0453デフォルトの名無しさん

2007/11/15(木) 02:45:47

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

0454453

2007/11/15(木) 02:51:08

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

0455デフォルトの名無しさん

2007/11/15(木) 08:47:34

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

0456デフォルトの名無しさん

2007/11/15(木) 08:48:28

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

0457デフォルトの名無しさん

2007/11/15(木) 09:10:39

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

0458デフォルトの名無しさん

2007/11/15(木) 13:35:38

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

n2329がgeneric版、n2413がmonomorphic版。

0459デフォルトの名無しさん

2007/11/15(木) 18:10:54

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

0460デフォルトの名無しさん

2007/11/15(木) 20:17:39

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

0461デフォルトの名無しさん

2007/11/15(木) 20:19:52

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

0462デフォルトの名無しさん

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"});
　// ...
}

に

0463デフォルトの名無しさん

2007/11/15(木) 21:06:25

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

0464デフォルトの名無しさん

2007/11/15(木) 21:30:25

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

0465デフォルトの名無しさん

2007/11/15(木) 21:59:59

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

0466デフォルトの名無しさん

2007/11/15(木) 22:57:50

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

0467デフォルトの名無しさん

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";});
じゃない?

0468デフォルトの名無しさん

2007/11/15(木) 23:06:55

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

0469デフォルトの名無しさん

2007/11/15(木) 23:13:50

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

0470デフォルトの名無しさん

2007/11/15(木) 23:17:33

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

0471デフォルトの名無しさん

2007/11/15(木) 23:21:44

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

0472デフォルトの名無しさん

2007/11/15(木) 23:36:52

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

0473デフォルトの名無しさん

2007/11/15(木) 23:39:54

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

0474デフォルトの名無しさん

2007/11/16(金) 01:02:11

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

0475デフォルトの名無しさん

2007/11/16(金) 02:23:58

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

0476デフォルトの名無しさん

2007/11/16(金) 06:14:03

（　ﾟдﾟ）ﾎﾟｶｰﾝ

0477デフォルトの名無しさん

2007/11/16(金) 09:04:24

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

0478デフォルトの名無しさん

2007/11/16(金) 09:08:15

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

0479デフォルトの名無しさん

2007/11/16(金) 09:15:24

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

0480デフォルトの名無しさん

2007/11/16(金) 09:45:18

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

0481デフォルトの名無しさん

2007/11/16(金) 12:53:51

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

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

0482デフォルトの名無しさん

2007/11/16(金) 22:08:51

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

0483デフォルトの名無しさん

2007/11/16(金) 22:15:25

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

0484404

2007/11/16(金) 23:16:50

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

0485デフォルトの名無しさん

2007/11/17(土) 15:42:44

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

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

0486デフォルトの名無しさん

2007/11/17(土) 22:43:25

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

0487デフォルトの名無しさん

2007/11/17(土) 23:55:37

もう出てますが…

0488デフォルトの名無しさん

2007/11/18(日) 00:19:37

詳細ごぼんぬ

0489デフォルトの名無しさん

2007/11/19(月) 01:21:01

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

0490デフォルトの名無しさん

2007/11/23(金) 02:11:42

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

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

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

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

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

0491デフォルトの名無しさん

2007/11/23(金) 02:15:09

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

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

0492デフォルトの名無しさん

2007/11/23(金) 02:55:50

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

0493デフォルトの名無しさん

2007/11/23(金) 04:49:56

placement newじゃだめなん

0494デフォルトの名無しさん

2007/11/23(金) 08:49:22

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

0495デフォルトの名無しさん

2007/11/23(金) 11:45:12

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

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

こんな感じでどうよ。

0496デフォルトの名無しさん

2007/11/23(金) 11:52:14

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

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

0497デフォルトの名無しさん

2007/11/23(金) 11:58:10

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

0498デフォルトの名無しさん

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();
}

0499デフォルトの名無しさん

2007/11/23(金) 12:35:52

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

0500デフォルトの名無しさん

2007/11/23(金) 12:36:27

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

0501デフォルトの名無しさん

2007/11/23(金) 12:52:18

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

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

0502デフォルトの名無しさん

2007/11/23(金) 12:54:42

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

0503デフォルトの名無しさん

2007/11/23(金) 13:02:18

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

0504デフォルトの名無しさん

2007/11/23(金) 13:22:08

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

0505デフォルトの名無しさん

2007/11/23(金) 13:24:22

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

0506デフォルトの名無しさん

2007/11/23(金) 13:30:59

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

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

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

0507デフォルトの名無しさん

2007/11/23(金) 13:34:18

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

0508デフォルトの名無しさん

2007/11/23(金) 13:36:38

つスルー力

0509デフォルトの名無しさん

2007/11/23(金) 13:37:02

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

0510デフォルトの名無しさん

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;

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

0511デフォルトの名無しさん

2007/11/23(金) 14:03:03

何かきったねーな。

0512デフォルトの名無しさん

2007/11/23(金) 14:06:17

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

0513デフォルトの名無しさん

2007/11/23(金) 14:08:32

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

0514デフォルトの名無しさん

2007/11/23(金) 14:11:44

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

0515デフォルトの名無しさん

2007/11/23(金) 14:15:18

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

0516デフォルトの名無しさん

2007/11/23(金) 14:16:38

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

0517デフォルトの名無しさん

2007/11/23(金) 14:44:43

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

0518デフォルトの名無しさん

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;
}

0519デフォルトの名無しさん

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のメンバーを仮想化すれば
操作に支障はない。

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

0520デフォルトの名無しさん

2007/11/23(金) 15:02:34

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

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

0521デフォルトの名無しさん

2007/11/23(金) 15:11:35

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

0522デフォルトの名無しさん

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"

0523デフォルトの名無しさん

2007/11/23(金) 15:17:24

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

0524519

2007/11/23(金) 15:19:39

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

0525デフォルトの名無しさん

2007/11/23(金) 15:20:36

意味不

0526デフォルトの名無しさん

2007/11/23(金) 15:22:07

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

0527デフォルトの名無しさん

2007/11/23(金) 15:24:10

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

0528デフォルトの名無しさん

2007/11/23(金) 15:24:52

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

0529デフォルトの名無しさん

2007/11/23(金) 15:25:00

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

0530デフォルトの名無しさん

2007/11/23(金) 15:25:47

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

0531デフォルトの名無しさん

2007/11/23(金) 15:27:27

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

0532デフォルトの名無しさん

2007/11/23(金) 15:27:40

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

0533デフォルトの名無しさん

2007/11/23(金) 15:28:33

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

0534デフォルトの名無しさん

2007/11/23(金) 15:30:30

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

0535デフォルトの名無しさん

2007/11/23(金) 15:30:44

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

0536デフォルトの名無しさん

2007/11/23(金) 15:33:54

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

0537デフォルトの名無しさん

2007/11/23(金) 15:37:20

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

0538デフォルトの名無しさん

2007/11/23(金) 15:40:45

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

0539デフォルトの名無しさん

2007/11/23(金) 15:43:08

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

0540デフォルトの名無しさん

2007/11/23(金) 15:45:08

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

0541デフォルトの名無しさん

2007/11/23(金) 15:49:50

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

0542デフォルトの名無しさん

2007/11/23(金) 15:51:43

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

0543デフォルトの名無しさん

2007/11/23(金) 15:53:33

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

0544デフォルトの名無しさん

2007/11/23(金) 15:55:25

馬鹿はスルーで。

0545デフォルトの名無しさん

2007/11/23(金) 15:57:12

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

0546デフォルトの名無しさん

2007/11/23(金) 15:57:40

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

0547デフォルトの名無しさん

2007/11/23(金) 15:58:18

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

0548デフォルトの名無しさん

2007/11/23(金) 16:09:57

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

0549デフォルトの名無しさん

2007/11/23(金) 16:16:27

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

0550デフォルトの名無しさん

2007/11/23(金) 16:18:54

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

0551デフォルトの名無しさん

2007/11/23(金) 16:36:02

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

0552デフォルトの名無しさん

2007/11/23(金) 16:37:25

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

0553デフォルトの名無しさん

2007/11/23(金) 16:56:12

>>551
え？　そうなん？

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

0554デフォルトの名無しさん

2007/11/23(金) 17:09:00

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

0555デフォルトの名無しさん

2007/11/23(金) 17:20:00

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

0556デフォルトの名無しさん

2007/11/23(金) 17:21:48

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

0557デフォルトの名無しさん

2007/11/23(金) 17:27:40

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

0558デフォルトの名無しさん

2007/11/23(金) 18:09:23

結論 : boost を使え

0559デフォルトの名無しさん

2007/11/24(土) 01:33:23

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

0560デフォルトの名無しさん

2007/11/24(土) 01:42:04

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

0561デフォルトの名無しさん

2007/11/24(土) 02:15:33

Cxx

0562デフォルトの名無しさん

2007/11/24(土) 19:47:30

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

0563デフォルトの名無しさん

2007/11/25(日) 16:07:49

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

0564デフォルトの名無しさん

2007/11/25(日) 16:08:30

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

0565デフォルトの名無しさん

2007/11/25(日) 16:18:10

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

0566デフォルトの名無しさん

2007/11/25(日) 17:27:21

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

0567デフォルトの名無しさん

2007/11/26(月) 00:24:08

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

0568デフォルトの名無しさん

2007/11/28(水) 07:27:49

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

0569デフォルトの名無しさん

2007/11/28(水) 07:34:46

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

0570デフォルトの名無しさん

2007/11/28(水) 08:08:55

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

0571デフォルトの名無しさん

2007/11/28(水) 08:28:34

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

0572デフォルトの名無しさん

2007/11/28(水) 09:56:20

コンパイラがいる！

0573デフォルトの名無しさん

2007/11/28(水) 12:02:31

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

0574デフォルトの名無しさん

2007/11/28(水) 12:15:41

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

0575デフォルトの名無しさん

2007/11/28(水) 12:15:43

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

0576デフォルトの名無しさん

2007/11/28(水) 16:06:58

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

0577デフォルトの名無しさん

2007/11/28(水) 16:45:17

>>576
げ、そうなのか。

0578デフォルトの名無しさん

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); // 範囲が重複していないと断言できる
}

0579デフォルトの名無しさん

2007/11/30(金) 14:56:06

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

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

0580デフォルトの名無しさん

2007/11/30(金) 15:44:52

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

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

0581579

2007/11/30(金) 15:48:04

>>580
うい、THX!

0582デフォルトの名無しさん

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について熱く語ろう！

0583デフォルトの名無しさん

2007/12/02(日) 04:38:19

0584デフォルトの名無しさん

2007/12/02(日) 20:33:15

nullptrをぬるぽと呼ぶスレ

0585デフォルトの名無しさん

2007/12/02(日) 20:40:10

ぬるぽたぁ

0586デフォルトの名無しさん

2007/12/04(火) 23:10:36

ぬるーぽったー

0587デフォルトの名無しさん

2007/12/05(水) 00:23:46

0588デフォルトの名無しさん

2007/12/05(水) 00:24:17

0589デフォルトの名無しさん

2007/12/05(水) 17:16:39

保守のつもりか？

0590デフォルトの名無しさん

2007/12/06(木) 00:02:41

そんなまさか

0591めかる ◆DzhWnUSADA

2007/12/06(木) 00:08:59

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

0592デフォルトの名無しさん

2007/12/07(金) 02:20:20

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

0593デフォルトの名無しさん

2007/12/14(金) 01:14:51

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

0594デフォルトの名無しさん

2007/12/14(金) 01:29:31

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

0595デフォルトの名無しさん

2007/12/14(金) 01:32:23

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

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

0596デフォルトの名無しさん

2007/12/14(金) 01:37:45

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

0597デフォルトの名無しさん

2007/12/14(金) 07:08:58

なにやってんだｗｗｗ

0598デフォルトの名無しさん

2007/12/14(金) 11:23:49

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

0599デフォルトの名無しさん

2007/12/14(金) 13:33:09

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

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

0600デフォルトの名無しさん

2007/12/15(土) 19:15:45

>>599
kwskおねがいします

0601デフォルトの名無しさん

2007/12/15(土) 19:26:27

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

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

0602デフォルトの名無しさん

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テンプレートの可変引数に対する再帰

0603デフォルトの名無しさん

2007/12/15(土) 19:34:30

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

0604デフォルトの名無しさん

2007/12/18(火) 15:08:36

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

0605デフォルトの名無しさん

2007/12/18(火) 20:15:09

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

0606デフォルトの名無しさん

2007/12/19(水) 01:19:08

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

0607デフォルトの名無しさん

2007/12/19(水) 01:39:15

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

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

0608デフォルトの名無しさん

2007/12/19(水) 01:43:01

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

0609606

2007/12/19(水) 03:30:56

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

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

0610デフォルトの名無しさん

2007/12/19(水) 10:16:53

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

0611デフォルトの名無しさん

2007/12/19(水) 11:35:50

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

0612デフォルトの名無しさん

2007/12/19(水) 11:47:59

スレ違いだろ。

0613デフォルトの名無しさん

2007/12/19(水) 16:16:49

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

0614デフォルトの名無しさん

2007/12/19(水) 21:36:45

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

0615デフォルトの名無しさん

2007/12/19(水) 22:05:03

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

0616デフォルトの名無しさん

2007/12/19(水) 22:27:48

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

0617デフォルトの名無しさん

2007/12/20(木) 03:58:03

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

0618デフォルトの名無しさん

2007/12/21(金) 12:13:52

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

0619デフォルトの名無しさん

2007/12/21(金) 23:01:57

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

0620デフォルトの名無しさん

2007/12/21(金) 23:05:40

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

0621デフォルトの名無しさん

2007/12/22(土) 23:40:39

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

0622デフォルトの名無しさん

2007/12/22(土) 23:48:08

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

0623デフォルトの名無しさん

2007/12/23(日) 00:13:46

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

0624デフォルトの名無しさん

2007/12/23(日) 01:34:21

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

0625デフォルトの名無しさん

2007/12/23(日) 01:45:01

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

0626デフォルトの名無しさん

2007/12/23(日) 04:18:53

>>621
いりません

0627デフォルトの名無しさん

2007/12/27(木) 12:36:37

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

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

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

0628デフォルトの名無しさん

2007/12/27(木) 12:57:19

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

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

0629デフォルトの名無しさん

2007/12/27(木) 13:25:42

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

0630デフォルトの名無しさん

2007/12/27(木) 13:32:56

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

0631デフォルトの名無しさん

2007/12/27(木) 13:34:24

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

0632デフォルトの名無しさん

2007/12/27(木) 13:35:28

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

0633デフォルトの名無しさん

2007/12/27(木) 13:41:34

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

0634デフォルトの名無しさん

2007/12/27(木) 13:45:13

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

0635デフォルトの名無しさん

2007/12/27(木) 13:50:07

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

0636デフォルトの名無しさん

2007/12/27(木) 14:02:29

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

0637デフォルトの名無しさん

2007/12/27(木) 14:20:24

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

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

0638デフォルトの名無しさん

2007/12/27(木) 14:26:48

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

0639デフォルトの名無しさん

2007/12/27(木) 17:33:02

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

0640デフォルトの名無しさん

2007/12/27(木) 20:16:22

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

0641デフォルトの名無しさん

2007/12/27(木) 21:23:50

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

0642デフォルトの名無しさん

2007/12/27(木) 22:24:07

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

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

0643デフォルトの名無しさん

2007/12/27(木) 22:56:51

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

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

0644デフォルトの名無しさん

2007/12/27(木) 23:00:08

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

0645デフォルトの名無しさん

2007/12/27(木) 23:32:45

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

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

0646デフォルトの名無しさん

2007/12/27(木) 23:59:34

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

0647デフォルトの名無しさん

2007/12/28(金) 00:08:54

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

0648デフォルトの名無しさん

2007/12/28(金) 00:14:45

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

0649デフォルトの名無しさん

2007/12/28(金) 00:33:16

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

0650デフォルトの名無しさん

2007/12/28(金) 00:36:11

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

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

0651デフォルトの名無しさん

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.

のところ。

0652デフォルトの名無しさん

2008/01/02(水) 21:58:13

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

0653デフォルトの名無しさん

2008/01/02(水) 22:12:45

2015年までおｋ

0654デフォルトの名無しさん

2008/01/02(水) 22:15:49

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

0655デフォルトの名無しさん

2008/01/02(水) 22:42:37

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

0656デフォルトの名無しさん

2008/01/02(水) 22:43:28

C++xx でいいじゃん。

0657デフォルトの名無しさん

2008/01/02(水) 22:44:35

Cxx

0658デフォルトの名無しさん

2008/01/02(水) 22:52:19

C+++

0659デフォルトの名無しさん

2008/01/03(木) 08:37:32

C#-

0660デフォルトの名無しさん

2008/01/03(木) 08:42:50

C++xxxxxx

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

0661デフォルトの名無しさん

2008/01/03(木) 08:45:41

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

0662デフォルトの名無しさん

2008/01/03(木) 16:07:34

C++0079

0663デフォルトの名無しさん

2008/01/03(木) 16:59:10

C++0083 STARDUST MEMORY

0664デフォルトの名無しさん

2008/01/03(木) 17:15:48

私は帰ってきた！

0665デフォルトの名無しさん

2008/01/03(木) 18:40:48

C++0x2010

0666デフォルトの名無しさん

2008/01/06(日) 19:33:16

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

0667デフォルトの名無しさん

2008/01/06(日) 19:35:38

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

0668デフォルトの名無しさん

2008/01/06(日) 22:12:07

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

0669デフォルトの名無しさん

2008/01/07(月) 02:01:59

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

0670デフォルトの名無しさん

2008/01/07(月) 11:56:29

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

0671デフォルトの名無しさん

2008/01/07(月) 15:31:36

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

0672デフォルトの名無しさん

2008/01/07(月) 16:16:34

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

0673デフォルトの名無しさん

2008/01/07(月) 16:47:53

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

0674デフォルトの名無しさん

2008/01/07(月) 16:54:43

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

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

0675デフォルトの名無しさん

2008/01/07(月) 17:47:35

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

0676デフォルトの名無しさん

2008/01/07(月) 18:01:55

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

0677デフォルトの名無しさん

2008/01/07(月) 19:04:43

ｶﾞﾍﾞｺﾚｷﾀｺﾚ

0678デフォルトの名無しさん

2008/01/07(月) 20:36:18

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

0679デフォルトの名無しさん

2008/01/07(月) 21:25:38

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

0680デフォルトの名無しさん

2008/01/07(月) 22:50:53

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

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

0681デフォルトの名無しさん

2008/01/07(月) 23:03:33

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

みたいなのは入るのかな

0682デフォルトの名無しさん

2008/01/08(火) 00:25:58

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

0683デフォルトの名無しさん

2008/01/08(火) 03:53:57

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

0684デフォルトの名無しさん

2008/01/08(火) 03:56:34

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

0685デフォルトの名無しさん

2008/01/08(火) 05:57:58

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

0686デフォルトの名無しさん

2008/01/08(火) 06:36:36

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

0687デフォルトの名無しさん

2008/01/08(火) 07:20:11

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

0688デフォルトの名無しさん

2008/01/08(火) 07:37:11

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

0689デフォルトの名無しさん

2008/01/08(火) 11:05:07

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

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

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

0690デフォルトの名無しさん

2008/01/08(火) 12:56:03

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

0691デフォルトの名無しさん

2008/01/08(火) 12:58:26

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

0692デフォルトの名無しさん

2008/01/08(火) 13:14:29

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

0693デフォルトの名無しさん

2008/01/08(火) 13:56:07

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

0694デフォルトの名無しさん

2008/01/08(火) 21:20:10

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

0695デフォルトの名無しさん

2008/01/08(火) 22:21:09

プリプリ中学生！

0696デフォルトの名無しさん

2008/01/08(火) 22:26:57

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

C++0x standard

0697デフォルトの名無しさん

2008/01/08(火) 22:27:59

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

0698デフォルトの名無しさん

2008/01/08(火) 22:32:01

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

0699デフォルトの名無しさん

2008/01/08(火) 22:41:35

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

まぁスレ違いか

0700デフォルトの名無しさん

2008/01/09(水) 00:49:51

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

0701デフォルトの名無しさん

2008/01/09(水) 10:03:02

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

0702デフォルトの名無しさん

2008/01/09(水) 10:08:49

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

0703デフォルトの名無しさん

2008/01/09(水) 10:30:20

禿は愛称です

0704デフォルトの名無しさん

2008/01/09(水) 12:09:52

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

0705デフォルトの名無しさん

2008/01/09(水) 12:24:57

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

0706デフォルトの名無しさん

2008/01/09(水) 13:22:38

禿かわゆす

0707デフォルトの名無しさん

2008/01/09(水) 17:35:10

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

0708デフォルトの名無しさん

2008/01/09(水) 17:41:43

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

Boost.Preprocessorは絶対に無理だ

0709デフォルトの名無しさん

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;
};

0710デフォルトの名無しさん

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;
};

0711デフォルトの名無しさん

2008/01/09(水) 20:31:57

>>700
チューリング完全だという論文がある。
http://d.hatena.ne.jp/earth2001y/20060929/p2

0712デフォルトの名無しさん

2008/01/10(木) 01:24:42

底学歴でさーせんwww

チューリングなんてまったく知らないんだけど、勉強した方がいいかな？(;´Д`)

0713デフォルトの名無しさん

2008/01/10(木) 02:04:31

少なくとも勉強したほうが悪いということは無いと思うぞ

0714デフォルトの名無しさん

2008/01/10(木) 02:05:07

知らなくたってPGは務まる。ってか大多数の職業PGは知らないと思う。

0715デフォルトの名無しさん

2008/01/10(木) 02:06:47

でも少なくとも情報工学科でたやつは習うでしょ

0716デフォルトの名無しさん

2008/01/10(木) 02:08:28

気になるなら調べりゃいい。それが勉強だ。

0717デフォルトの名無しさん

2008/01/10(木) 02:17:03

>>715
情報系出身だけど一切授業ではやってないよ。
http://ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E7%90%86%E8%AB%96
↑のページで授業で触れられたものはO記法くらいだなぁ。

0718デフォルトの名無しさん

2008/01/10(木) 02:34:46

情報系いうてもピンキリやな

0719712

2008/01/10(木) 03:32:48

ウィキペディア読んできたけど意味わかんね(;´Д`)w

0720デフォルトの名無しさん

2008/01/10(木) 04:50:29

授業でやった．しかし忘れた．
その時教科書使ってない．
センセのパワポだけ．
SIに就職後だけど，情報系出てるのに恥ずかしい．
いまさら何読めばいい？
英語は何とか問題ないと思うので英語の教科書でも．

次のレスでエロい人が読み物を列挙してくれる予定．
↓

0721デフォルトの名無しさん

2008/01/10(木) 07:01:00

つttp://wiredvision.jp/news/200710/2007102622.html

0722デフォルトの名無しさん

2008/01/10(木) 09:13:40

チューリング完全なんて数学の知識が要るから必要ないよ

0723デフォルトの名無しさん

2008/01/10(木) 09:26:34

知ってるに越したことはないけどね

0724デフォルトの名無しさん

2008/01/10(木) 09:27:46

美少女中学生と完全なチューをしている状態！(*´Д`)'`ｧ'`ｧ

0725デフォルトの名無しさん

2008/01/10(木) 15:31:05

数学の知識が無いのにそういう仕事してる時点で下流決定だろｗ

0726デフォルトの名無しさん

2008/01/10(木) 16:00:31

時点で、とか書く時点で厨レスだろｗ

0727デフォルトの名無しさん

2008/01/10(木) 18:32:54

2chやってる時点でｒｙ

0728デフォルトの名無しさん

2008/01/10(木) 20:44:36

>>726
厨リング完全なレスだな

0729デフォルトの名無しさん

2008/01/10(木) 21:36:30

>>728
誰がうまいことを（ｒｙ

0730デフォルトの名無しさん

2008/01/11(金) 00:09:56

まあしかし、すでにプログラムをかけるひとはチューリング完全のあたりを勉強するのはぜんぜん難しくないと思う
数学の記法つかってかいてない本とかあれば、だけど。

0731デフォルトの名無しさん

2008/01/11(金) 00:18:24

ありそうだな

0732デフォルトの名無しさん

2008/01/11(金) 01:22:11

あるよ？

0733デフォルトの名無しさん

2008/01/17(木) 02:26:47

include guard書くのが馬鹿らしいので#includeのプリプロセスで勝手に弾いてほしい。

0734デフォルトの名無しさん

2008/01/17(木) 09:55:47

#pragma once

0735デフォルトの名無しさん

2008/01/17(木) 10:03:19

pragma onceがなかなか標準にならないのは
いろいろ難しい問題があるらしい。

知らんけど

0736デフォルトの名無しさん

2008/01/17(木) 11:50:48

#pragma once って gcc でも vc でも使えるよね．

0737デフォルトの名無しさん

2008/01/17(木) 12:10:50

windowsのヘッダを通さなきゃならないコンパイラはみんなonceは通すよ

0738デフォルトの名無しさん

2008/01/17(木) 13:00:20

#pragma twice

0739デフォルトの名無しさん

2008/01/17(木) 13:55:22

>>735
一言で言えば、何で同一性を判定するのかという問題だね

0740デフォルトの名無しさん

2008/01/17(木) 20:19:03

インクルードガードを内部的に自動生成したのと同じ形に動作する程度でいいと思うんだがなあ。

0741デフォルトの名無しさん

2008/01/17(木) 21:33:07

その内部的に生成する際に、識別子をどうするかが問題なんでしょうが

0742デフォルトの名無しさん

2008/01/17(木) 22:29:02

GUIDを使って後は神に祈る

0743デフォルトの名無しさん

2008/01/17(木) 22:41:21

内部的に自動生成したのと「同じ形に動作する」わけだからどうとでもなるべ。

0744デフォルトの名無しさん

2008/01/17(木) 23:02:53

同じファイルに複数の名前がついてるような場合とかどうするのって話。

0745デフォルトの名無しさん

2008/01/17(木) 23:07:46

ローカルにあるファイルを、
直接と、ネットワーク越しにとでアクセスする場合とかか？

0746デフォルトの名無しさん

2008/01/17(木) 23:47:53

シンボリックリンクされてる場合とか。

0747デフォルトの名無しさん

2008/01/18(金) 00:02:15

「そういう場合は処理系定義とする」でもういいじゃん

0748デフォルトの名無しさん

2008/01/18(金) 00:16:03

いちいちヘッダを比較すればいい
違う名前だろうがなんだろうが一字一句同じなら同一としていいはずだからな

0749デフォルトの名無しさん

2008/01/18(金) 00:17:23

同じファイル名が別の場所にあって名前も内容も同じ場合ってのがシステムヘッダ
などでよく起きる。さらに内容はほぼ同じ（バージョン違い）とか考えだすときりがない。

0750デフォルトの名無しさん

2008/01/18(金) 00:20:26

それに関しては絶対パスで区別すりゃいい。
リンクされてる場合は、同一実体を指しているかもチェックする。
ただ、このあたりは環境依存な話が多く出てくるので
もう「処理系定義」でいいと思う。

0751デフォルトの名無しさん

2008/01/18(金) 00:31:00

提案書を書いて委員会へ提出よろ

0752デフォルトの名無しさん

2008/01/18(金) 00:31:06

そんならもう#pragma onceの扱いは処理系定義でいいじゃん。

0753デフォルトの名無しさん

2008/01/18(金) 00:31:46

そもそも pragma の扱いは処理系定義だｗ

0754デフォルトの名無しさん

2008/01/18(金) 00:53:37

#pragma onceってファイル内の中途半端な位置に書いてたり2か所に記述したりしたらどうなるんだろ

0755デフォルトの名無しさん

2008/01/18(金) 00:56:32

処理系定義だろ

0756デフォルトの名無しさん

2008/01/18(金) 03:04:14

>>752
ﾜﾛﾀ

0757デフォルトの名無しさん

2008/01/18(金) 07:42:44

#pragma once

#pragma once は同一ファイルの二度目以降のインクルードを無効にする。
ファイルの同一性判定の方法は処理系定義とする。

ファイル A の中で #pragma once が処理される前に #include があり、
その中でファイル A がインクルードされている場合、
#pragma once は効力を発揮しない。

#pragma once はファイル中に１カ所にしか出現してはいけない。

0758デフォルトの名無しさん

2008/01/18(金) 09:15:21

#pragma once(unique-id)
ちょっとタイプ量は増えるけど、こう書くようにすればいいんじゃなかろうか。
従来のようにidを省略したら、
#pragma once(__FILE__)
みたいになって、ファイルの同一性の比較は処理系定義と妄想

0759デフォルトの名無しさん

2008/01/18(金) 09:19:30

>>748
じゃだめなん？

0760デフォルトの名無しさん

2008/01/18(金) 09:38:45

全く同じファイルのコピーが二箇所にあって、両方ともincludeされてて、
なんかの拍子に片方を編集したら、コンパイルとおらなくなる。

鬱陶しくないか。

0761デフォルトの名無しさん

2008/01/18(金) 09:41:35

>>758がいいな
同一性はプログラマが定義することもできるし、コンパイラに任せることも出来る

0762デフォルトの名無しさん

2008/01/18(金) 10:10:44

普通にインクルードガードでいいだろJK

0763デフォルトの名無しさん

2008/01/18(金) 10:12:15

>>762
よく ifdef endif の対応関係がずれて
あわわわ～ってなる（笑

0764デフォルトの名無しさん

2008/01/18(金) 10:55:05

>>763
それは言語仕様でフォローすることではないな

0765デフォルトの名無しさん

2008/01/18(金) 12:13:46

>760
コンパイル通るようになったらなったで、
何からの拍子で、片方だけ、構造体の構成とか変更すると、
実行時に訳わかめなエラーになるんじゃねーの。

0766デフォルトの名無しさん

2008/01/18(金) 13:48:01

こういう仕様を考える時は「やっちゃいけないこと」から考えるといいぞ

0767デフォルトの名無しさん

2008/01/18(金) 16:34:02

include回りの問題の多くはModules in C++(N2316)が入れば解決じゃね？
仕様が固まる頃にはC++20くらいになってそうだけど。

0768デフォルトの名無しさん

2008/01/18(金) 20:45:37

もうプリプロセッサなくていいよ

0769デフォルトの名無しさん

2008/01/18(金) 20:46:29

>>768
まぁそういう意見もあるよな．
しかし過去の遺産のことを考えると
プリプロセッサの挙動をもっと厳格に
規格化したうえで存続した方がいい．

0770デフォルトの名無しさん

2008/01/18(金) 20:46:38

Cでプリプリ！なんていやらしい！

0771デフォルトの名無しさん

2008/01/18(金) 21:01:08

modulesを入れるとなあ、
exportどころじゃないぞ、実装の手間が。

templateもconceptも、実装をヘッダでincludeすること前提だしな。
必要な情報を全部中間言語に書き出すとなると大変。

0772デフォルトの名無しさん

2008/01/19(土) 00:51:35

もはや C++ ではない気がするなあ

0773デフォルトの名無しさん

2008/01/19(土) 02:29:00

D言語においでー

0774デフォルトの名無しさん

2008/01/19(土) 08:41:03

DはC++0xの実験的な実装

0775デフォルトの名無しさん

2008/01/19(土) 14:12:01

include guardも#pragma onceも、インクルードされる側のファイルに書く。つまり、読まれたかどうかはファイルを開かないと分からない。
なんつーか、Obj-Cのimportみたいのが欲しいんだよね。あれって多分開く前に同一性チェックをしてるでしょ。（#pragma onceもそうなのかな？）

0776デフォルトの名無しさん

2008/01/19(土) 14:16:09

美少女中学生のインクルードガードは固くないほうがいいなぁ
もしくは自分で破っちゃったりしててアアーッ

0777デフォルトの名無しさん

2008/01/19(土) 14:27:39

つttp://pc11.2ch.net/test/read.cgi/tech/1142089873/

0778デフォルトの名無しさん

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 は、
ファイル中に１カ所にしか出現してはならない。

0779デフォルトの名無しさん

2008/01/21(月) 01:06:40

Cプログラマ必須テキストです！

http://mori.eco.to/

0780デフォルトの名無しさん

2008/01/21(月) 07:06:50

俺はC++だから必要ないな

0781デフォルトの名無しさん

2008/01/21(月) 14:15:59

おまえがC++だったのか！

0782デフォルトの名無しさん

2008/01/21(月) 14:20:59

>>780
お前のせいで！

0783デフォルトの名無しさん

2008/01/21(月) 15:40:53

>>782
お前がハゲなのは親のせいだ。

0784デフォルトの名無しさん

2008/01/21(月) 15:56:56

C++のせいではなかったのか…orz

0785デフォルトの名無しさん

2008/01/22(火) 14:41:57

>>779
普通のC言語入門書っぽいな。
経験のあるプログラミング言語をわざわざ列挙してるのが何か笑える。

0786デフォルトの名無しさん

2008/01/22(火) 15:33:15

「普通の」じゃないだろ。
寧ろ本人曰く、「世のCを教える立場の人間は押し並べてCを判っていない」とのことなんだから。

0787デフォルトの名無しさん

2008/01/22(火) 15:34:09

>>785マルチ宣伝レスだから反応しないように

0788デフォルトの名無しさん

2008/01/22(火) 15:42:40

まともな本ならこんな宣伝しないよ

0789785

2008/01/22(火) 16:00:22

ｽﾏｿ

0790デフォルトの名無しさん

2008/01/22(火) 17:24:14

ハゲが怖ければ大豆イソフラボン摂れば良いよ。女性ホルモンに似た働きをして
ハゲや不本意な勃起を抑えてくれる事が医学的に証明されている。

0791デフォルトの名無しさん

2008/01/22(火) 23:32:49

>>790
ありがとう。さっそく試してみるよ。

0792デフォルトの名無しさん

2008/01/22(火) 23:46:14

結論は納豆というわけか

0793デフォルトの名無しさん

2008/01/29(火) 17:40:14

やっぱ豆蔵がいちばんっしょ。

0794デフォルトの名無しさん

2008/01/29(火) 17:43:55

>>790
俺の体で効果がない事は、俺の実体験により証明されている。

0795デフォルトの名無しさん

2008/01/29(火) 21:17:36

美少女中学生のいやらしいお豆！

0796デフォルトの名無しさん

2008/02/06(水) 10:18:26

あげるな危険。

0797デフォルトの名無しさん

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?

0798デフォルトの名無しさん

2008/02/06(水) 21:32:40

静的な型を表す。

0799デフォルトの名無しさん

2008/02/06(水) 21:48:43

>>798
ありがとうございます

実際に試せればわかるのに・・・

と思ったらconcept gccなんてのがあるんですね
ちょっと遊んでみます

0800デフォルトの名無しさん

2008/02/06(水) 22:34:07

decltype(pb)はBaseではなくBase*では？

0801デフォルトの名無しさん

2008/02/08(金) 17:25:38

operator[]　()　=　->　*

C++0xでこれら演算子をグローバルに定義できるみたいですが、
どういう意図で導入したんでしょうか

0802デフォルトの名無しさん

2008/02/08(金) 21:54:05

それは初耳。

0803デフォルトの名無しさん

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);

0804デフォルトの名無しさん

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で処理すべきだろう。

0805デフォルトの名無しさん

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&&になっている。
これなら、上のコメントアウトを外した状態でもコンパイルできた。

0806デフォルトの名無しさん

2008/02/10(日) 16:31:07

>>803
最新の draft などでは>>805さんの書かれているように
move の定義が変わっているので，単に d = move(s) の構文で大丈夫なはずです．

>>804
そのように参照型を取る事例への対処を
より汎化した規則で書こうとした結果が，
現在の reference collapsing rule じゃないんでしょうか？

0807デフォルトの名無しさん

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&> と同等に捉えられますので
割と自然なように思えます．

0808803

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から大きく離れることもない。

0809803

2008/02/10(日) 17:01:20

>>807
参照型のメンバを持つpairだのtupleだのは、
代入演算子を持たなかったりswapが参照先を入れ換えちゃったりするわけで、
そういうものを「自然」に扱える必要はないでしょう。

0810デフォルトの名無しさん

2008/02/10(日) 17:08:36

>808
＞C++98の考え方と全く違う異様な型推論
右辺値参照型をパラメタとする関数テンプレートの型パラメタの推論に関して
言及されてるならそれは同意します．もう
template<class T> void f(T&&);
の形は perfect forwarding のため (だけ) にあると理解したほうが早いと思います．

0811デフォルトの名無しさん

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 は排除してほしくないです．

0812デフォルトの名無しさん

2008/02/10(日) 18:36:30

やべぇ高度過ぎてわからん

0813デフォルトの名無しさん

2008/02/10(日) 19:07:34

へぼぐらまの俺にもいまいちわからん
0x の改修って一般のC++プログラマに受け入れられるのか？
なんか、実用する人たちから遊離した規格のような気が・・・

0814デフォルトの名無しさん

2008/02/10(日) 19:16:39

>>813
そんなに大変な非互換性は取り込まれないと思うから、一般のプログラマは現状の
規格に不満がなければ気にしなくてもいいでしょ。

受け入れられるかどうかっていう点では、規格の変更に対応するかどうかという話で
コンパイラベンダの反応が問題だと思う。

0815803

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が必要になる、と。

0816デフォルトの名無しさん

2008/02/10(日) 19:37:26

ライブラリ書くようなエロいプログラマさんが頑張って書いてくれれば、
使ってる側からはあんまり気にしなくてもメリットはあると思う。
あと、この辺のおまじないは std::forward とか、std::move とかの裏側に隠されるし。

>808
>でも、だからといってT & && = T &のような直観に反する変換や
どうなるのが望ましい？

その辺をおいといても、&? の方が明快なのはそう思う(これ static_cast も必要なくね？)。
やってること自体は今の && の反転みたいなものだし、ルール的にも決めるのはそう難しくなさそう。
欠点は &? が増えるってことだけかな？
今更無理だろうけど誰か提案書いてくれw

0817803

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は必要。

0818811

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 は名前の付いた他のオブジェクトを指しているため，これはまずくないですか？

0819デフォルトの名無しさん

2008/02/10(日) 20:46:28

>>813
いま問題になっている右辺値参照。
それによってもたらされる一般的なムーブ・セマンティクスは、
例えば関数の戻り値や、vectorで内部バッファリサイズ時の移動などといったときに
無駄なコピーの削減に役立つ。

＃もちろんそれだけにとどまらないけど、それはとりあえず置いておく。

0820デフォルトの名無しさん

2008/02/10(日) 20:53:55

で、何が言いたいかって、各人がほっといたって、
ライブラリの中の人が頑張るために使うから、
気付かぬ内に恩恵を被るかもしれないよってこと。

0821デフォルトの名無しさん

2008/02/10(日) 21:12:29

move　semanticsなんて全コンテナ修正だな

T&&のオーバーロード足すだけでいいのかな

0822803

2008/02/10(日) 21:23:32

>>818
mypair &operator=(const mypair &src);
mypair &operator=(mypair &&src);
という一般的なオーバーロードを前提にすれば、
後者が呼ばれるのは故意にmoveする場合に限られる。
だから名前の付いた他のオブジェクトをmoveして正解。

0823803

2008/02/10(日) 21:26:48

ごめん大嘘。関数の戻り値として参照を含むmypairを値で返されたら
後者の方にマッチしちゃう。これは確かにまずい。

0824デフォルトの名無しさん

2008/02/10(日) 21:53:55

アクロバティックな性体験を体験した美少女中学生のような気分になった

0825デフォルトの名無しさん

2008/02/10(日) 23:36:37

同じくヘボグラマの俺には、辛うじて意味は分かってもどうしても内容に関しては受動的にならざるを得ない。

0826デフォルトの名無しさん

2008/02/21(木) 00:24:55

そろそろ移動するべきかなぁと思ったのでこっちで。

【C++】STL（Standard Template Library）相談室 8
http://pc11.2ch.net/test/read.cgi/tech/1198435319/843
でオーバーロード面倒という声があったけど、場合によってはこんな風にできるかも。

Widget func(const Widget&, const Widget&, const Widget&); // move しない

// helper 実際には Variadic template 化？
template<typename T0, typename T1, typename T2>
Widget&& select(T0&& t0, T1&& t1, T2&& t2, std::enable_if<!std::lvalue_reference<T0>::value || !std::lvalue_reference<T1>::value || !std::lvalue_reference<T2>::value>>::type *dummy = 0)
{
  return !std::is_lvalue_reference<T0>::value ? std::move(t0) : !std::is_lvalue_reference<T1>::value ? std::move(t1) : std::move(t2);
}

template<typename T0, typename T1, typename T2>
Widget&& func(T0&& t0, T1&& t1, T2&& t2)
{
  Widget& w = select(std::forward<T0>(t0), std::forward<T1>(t1), std::forward<T2>(t2));
// w に対する処理
  return std::move(w);
}

あんま自信ないけどどうだろ？

0827デフォルトの名無しさん

2008/02/21(木) 00:39:30

ムーブコンストラクタの呼び出しが最適化で削られるなら
いいのかなあと思った。

0828デフォルトの名無しさん

2008/02/21(木) 00:52:27

>>826
func の return 文の std::move は不要では？

>>827
move constructor は副作用を持つでしょうから
これを参照で返すのと同じにまで最適化するのは結構厳しい要求かと

0829デフォルトの名無しさん

2008/02/21(木) 00:55:27

結局そんくらいのコストは勘弁してやれ、
それが嫌ならオーバーロードしろ、ということか。

0830デフォルトの名無しさん

2008/02/21(木) 01:01:51

move は一般にリソースの確保・解放を伴わないでしょうから，
そこまでシビアに move が重くなる状況はあまりないとは自分も思うのですけれど．

ただ std::string においては，例えば短文字列最適化を採用していると
move を使っても内部の文字列のコピーが発生するので，
4つのオーバーロードをまともに書く意義はあるのかなぁ，と．
それに4つのうち2つは他の実装に forward すればよいだけですし
そこまでオーバーロードが苦になることもないかと．

0831デフォルトの名無しさん

2008/02/21(木) 01:14:22

そういう引数が４つあった１６個か。

0832デフォルトの名無しさん

2008/02/21(木) 02:31:49

Boost.Operatorsに期待。

0833デフォルトの名無しさん

2008/02/21(木) 19:43:22

引数に関して言えば、
右辺値参照なんてものを導入するより、
右辺値→左辺値変換演算子を導入した方がいいと思う。

どうせ戻り値はテンポラリオブジェクトとして作成されてて、
基本型でもなければ大抵メモリ上にあるわけで、
内部的には変換なんて行う必要はないはず。
基本型とかなら、テンポラリオブジェクトを作成して、
そのテンポラリオブジェクトへの参照を返せばいい。

const 参照へならここら辺勝手にやってくれるけど、
非 const 参照へもできる手段を与えてやるって感じ？
自動的に変換されるのはおそらくマズそうなんで、
キャスト演算子の導入でなんとか。

0834デフォルトの名無しさん

2008/02/22(金) 02:09:34

突発的！ちら裏!!

１、SingleInt型かByte型を導入してくれ。。。
char型はiostreamで文字として解釈されてすごい不便。俺は文字じゃなくて１バイトの数字を書き込みたいんだ。。。
バイナリ指定してるはずなんだけどなぁ。@VC

２、Enumの名前ちゃんと考慮してクレイ。名前何のために付けてるんだか。。。
2種のEnum宣言したときの別々なのにメンバの多重定義できなくてメチャクチャ不便だ。
片方に宣言してもう片方に設定しようとすると型変換エラーでるし。
ゲームでステータス設定するときEnum重宝するんだがなぁ。

0835デフォルトの名無しさん

2008/02/22(金) 02:14:32

2の方はC++0xになかったっけ
enumにスコープがつくはず

0836デフォルトの名無しさん

2008/02/22(金) 04:11:22

charとsigned charとunsigned char

0837デフォルトの名無しさん

2008/02/22(金) 13:06:58

>>836
みんなbasic_istream/basic_ostreamに対するoprator >>/operator <<が定義されている。

0838デフォルトの名無しさん

2008/02/22(金) 14:01:38

>>834
ios::binaryってことじゃなくて？

0839デフォルトの名無しさん

2008/02/22(金) 17:09:44

>>835
おぉ、ありがたい。

>>834
一応ｙってみたけど、なんか意図どおりにならなかったなぁ。
自分の不具合かもしれんが。。。

0840839

2008/02/22(金) 17:11:18

ミス。

>>834じゃなくて　>>838

0841デフォルトの名無しさん

2008/02/22(金) 18:14:50

foo(lvalue_cast(bar()));

0842デフォルトの名無しさん

2008/02/22(金) 19:42:00

integer semantics

0843デフォルトの名無しさん

2008/02/22(金) 19:55:46

template <typename T>
　T& lvalue_cast(const T& rvalue)
{
　return const_cast<T&>(rvalue);
}

何だ。今の C++ でも書けるじゃないか。
当然文をまたいで使う事はできないが、
move semantics なんて無くてもいいんじゃないか？

0844デフォルトの名無しさん

2008/02/22(金) 21:30:21

>>843
ムーブとコピーの区別が付けられなくないか？

0845デフォルトの名無しさん

2008/02/22(金) 23:12:30

>>844
引数は const 参照だが、
あくまでこれはテンポラリオブジェクトを作成するためのものであって、
引数には左辺値を渡してはいけない。
あくまで右辺値を左辺値に変換する際にしか使わない。

さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？

0846デフォルトの名無しさん

2008/02/22(金) 23:17:36

いや待て。
別に左辺値を渡してもいいのか。
単にそれがそのまま返されるだけで。
const な左辺値を渡してはいけない、だな。

0847デフォルトの名無しさん

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(); //ムーブ

0848デフォルトの名無しさん

2008/02/22(金) 23:30:08

>>845
＞さらにメタプロ駆使すれば左辺値を禁止することもできるかもしれない？
やめたほうがよいです．左辺値と右辺値の識別を現行規格でやろうとすると
非常にわずらわしいことを考えないとならないです．
個人的に徹底的に試行錯誤した経験があるんですが，
現行規格で右辺値・左辺値識別を行うのは自分としては絶対にお勧めしません．
実際やってみれば理解してもらえると思うのですが，たとえばGCCの実装における
現行規格の8.5.3/5の解釈にブチ切れたりすることになったりします．

一応，下の提案さえ通ればライブラリレベルで move を実装することはできますが……
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html

0849デフォルトの名無しさん

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;
};

0850デフォルトの名無しさん

2008/02/22(金) 23:42:47

>>847
俺の案は RVO されることを前提としてるから、
ムーブなんて無くても十分ということになる。
面倒くさいから RVO を規格で要求したら？とさえ思ってる。

0851デフォルトの名無しさん

2008/02/22(金) 23:48:40

>>848
識別は難しいのか・・・。

0852デフォルトの名無しさん

2008/02/22(金) 23:51:55

なるほど。
でもそれだとbindなんかで呼出時に右辺値を直に引数にできないのは
解決できないように見える。
lvalue_castがあるって言うのかもしれないけど、
それだったら今でもboost::crefを使えば引数に渡せる点で同じと思う。

0853デフォルトの名無しさん

2008/02/22(金) 23:54:11

まあ、実際の所現行規格で別に実現できなくてもいい。
&& を単項演算子として、それを頭に付けるとかいう言語拡張でも。

0854デフォルトの名無しさん

2008/02/23(土) 00:14:35

何でもかんでもオーバーロードで解決すべきかってのは微妙な所で、
２つの関数を実装させる手間、
いや、複数引数があれば４つ、８つと指数関数的に増えていく手間がかかってしまうのは
かなりの問題だと思う。
右辺値参照を導入するとしても、
オーバーロード不要の代替案は用意した方が良さげ。

0855デフォルトの名無しさん

2008/02/23(土) 00:18:34

それはもう variadic template で書いてしまって，
意図しない呼び出しを SFINAE と deleted function 宣言で阻止してしまえば
いいんじゃないですかね
具体的にどういう複数引数関数書きたいのかによりますけれど

0856デフォルトの名無しさん

2008/02/23(土) 00:23:02

テンプレートは export が実質使えなくてヘッダに実装せざるを得ない以上、
使う必要の無いところでなるべく使いたくはない。

0857デフォルトの名無しさん

2008/02/23(土) 00:24:31

だが、もはやテンプレートのないC++も使いたくない。わがままだ。

0858デフォルトの名無しさん

2008/02/23(土) 00:27:29

ムーブは無駄なコストが発生する上に
RVO みたいな最適化もできなさそうなのがな。
pimpl 使えばポインタの移動だけでいいから
まあ大したコストでもないのかもしれないが・・・。

0859デフォルトの名無しさん

2008/02/23(土) 00:33:33

boost::noncopyable の他に boost::nonmovable も必要になるのかな

0860デフォルトの名無しさん

2008/02/23(土) 00:46:03

非const参照に右辺値を渡せちゃう処理系もあるから、
いらぬお世話って思ってる人もいるかもね。

0861デフォルトの名無しさん

2008/02/23(土) 00:48:30

>>858
pimplでなくとも、ポインタくらいのやり取りですむ（深いコピーが発生しない）
ってのがムーブの売りだろ。

0862デフォルトの名無しさん

2008/02/23(土) 00:49:19

RVO で済む状況なら、RVO はコスト０だぜ。
非０は０には敵わない。

0863デフォルトの名無しさん

2008/02/23(土) 00:51:02

メンバが５個くらいあったら５個ムーブする必要がある。
１つ１つはポインタくらいのやり取りでも、
個数が増えるとバカになんないかもしんない。

0864デフォルトの名無しさん

2008/02/23(土) 00:59:18

んー，別に move を導入しても
RVO が適用できる場面では依然 RVO が適用されるでしょうから，
たとえば>>858さんが何を問題にされているのかいまいち把握できていないんですが……
もう少し詳しく教えてもらえると個人的にはうれしいんですが．

0865デフォルトの名無しさん

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();
}

0866デフォルトの名無しさん

2008/02/23(土) 01:04:02

RVO と右辺値→左辺値変換さえあれば、
文法を複雑にし、コストを必要とし、ライブラリを大きく書き換える
move とやらを導入する積極的な理由はないんじゃないの？
という話。

0867デフォルトの名無しさん

2008/02/23(土) 01:05:26

RVO を規格で保証してないのに理由とかあるの？
コンパイラの実装コストの問題？

0868デフォルトの名無しさん

2008/02/23(土) 01:16:45

>>866
関数からの戻り値のコピーを排除するのは move の応用の1つに過ぎないです．
RVO は return と throw に限定された話ですけれど，
move はより広い文脈 (たとえば std::vector におけるバッファの再配置) でも
きわめて重要な意義を持つ操作で，これは RVO 云々では取り扱いきれないように思います．

それから
＞コストを必要とし、
の部分は，上にもありますけれど， RVO が適用できてコストがかからない部分では
move が導入されても依然 RVO が適用されてコストがかからないようになると
思われますので， (ただし，これはあくまでコンパイラの実装如何ですが)
RVO と move を比較してどのコストを憂慮されているのかがちょっと理解できていないです．

0869852

2008/02/23(土) 01:19:43

>>866
俺の話はどうしてくれるの？
いや、このためだけに言語を大きく拡張する価値はないと言いたいのか。

0870デフォルトの名無しさん

2008/02/23(土) 01:20:15

だから、右辺値を非 const 参照に渡すまともな手段は用意されてるの？って話。

0871デフォルトの名無しさん

2008/02/23(土) 01:21:01

>>869
それが lvalue_cast じゃないの？

0872デフォルトの名無しさん

2008/02/23(土) 02:02:07

あと、RVO が規格で強制されるものではないという点も。

0873デフォルトの名無しさん

2008/02/23(土) 02:22:09

右辺値左辺値判定、こりゃ確かに無理だな・・・。

0874デフォルトの名無しさん

2008/02/23(土) 04:42:12

>>870
「まとも」とか変な基準を持ち出すなよ。

0875デフォルトの名無しさん

2008/02/23(土) 05:25:18

>>859
move 系コンストラクタや代入演算子が自動生成されないなら、要らないと思うんだけど、
こいつらもコンパイラが勝手に作っちゃうの？

0876デフォルトの名無しさん

2008/02/23(土) 10:52:20

d = move(s)
の途中で例外が起こった場合、sとdの状態はどうなるんだろうか？

std::vectorの再配置にしても例外安全の強い保証
(メソッドの途中で例外が発生してもオブジェクトの状態は以前と同じ)
を行うなら、結局
　１、新しいバッファを確保
　２、それにすべてのオブジェクト内容をコピー
　３、バッファ作成に成功したら、ポインタの挿げ替えを行う
　４、古いバッファの削除
という手順を踏む必要があるんだけど・・・

　１、新しいバッファを確保
　２、オブジェクト内容をmoveで移動
　３、ポインタの挿げ替え＆古いバッファの削除
とやってしまうと２の途中で例外が発生したときまずいことにならないか？

0877デフォルトの名無しさん

2008/02/23(土) 11:38:09

swapみたいにmoveコンストラクタは例外の非送出が必要ということになっていると思う。

0878デフォルトの名無しさん

2008/02/23(土) 13:14:28

>>875
いえ，今の提案では move constructor や
move assignment は自動では生成されないことになってます．

>>876
move で強い例外安全性の保証を行おうとすると， move の rollback 操作が
move そのもので，これが例外非送出でなければならないため，
結局 move 自身が例外非送出である必要が出てきます．

0879デフォルトの名無しさん

2008/02/27(水) 10:58:47

C++の標準外のライブラリが破綻する最大の理由は
ライブラリ作成側が守るべきプログラミングモデルをユーザに示さないからだよ。

コードから読み取れるモデルでなく、
モデル宣言をするべきなんだよ。
その完全性を支援するためにコンパイラがそれによって挙動を変えてもいい。

最初は完全なるOOを実現しているように見えた。
しかし、あるバージョンではマルチパラダイムに変身し
OOの完全性を崩壊させるとかNe-Yo。

0880デフォルトの名無しさん

2008/02/27(水) 14:10:39

こないだ STL スレで挙がった話なんだけど、 copy_if() がどうなってるかだれか知らない？
未だにドラフトにも載ってないんだけど。っていうか 2003 の改訂で入らなかったのはなぜ？

0881デフォルトの名無しさん

2008/02/27(水) 15:57:01

>>880
禿がまた忘れたんだろ

0882デフォルトの名無しさん

2008/02/27(水) 19:25:26

rangeがどうなるかだな

0883デフォルトの名無しさん

2008/02/27(水) 22:25:33

>>879
どっちかというとOOの世界に土足で上がり込もうとした
総称型プログラミングの要素の側が勝手に苦労してるだけに見える。
継承使ったら型推論できませんとか暗黙のキャストができませんとか。
マルチパラダイムになってOOサイドで何か問題起きてる？
むしろコンテナみたいな値系オブジェクトを下のレイヤに追い出すことで、
OOを純化できると思うんだけど。

0884デフォルトの名無しさん

2008/02/27(水) 22:46:38

完全なOOとか、OOを純化とかには興味無いんだと思うよ。ｗ
一言で言えば「宗旨が違う」

0885デフォルトの名無しさん

2008/02/28(木) 00:09:21

C++はOO側が極端に少ない＝OOが蔑ろにされる
という構図がある。

つまり、そのときOOが成立するコードという理由で
OO前提のコードを書いてしまうと

将来OO否定派が紛れ込んだときに混乱の元になるということ。

0886デフォルトの名無しさん

2008/02/28(木) 00:10:53

>>885
３回読んだけど意味が判らん

0887デフォルトの名無しさん

2008/02/28(木) 01:37:54

対立問題にしてどうしたいんだ

0888デフォルトの名無しさん

2008/02/28(木) 08:12:14

"virtual"を標準ライブラリから検索してみれば
OOはC++自身に拒否されていると分かる
禿げ涙目である

0889デフォルトの名無しさん

2008/02/28(木) 08:25:52

>>887
勝利したいんだろ

ほっとこうぜ

0890デフォルトの名無しさん

2008/02/28(木) 11:55:41

ふむ。OOをNGワードに登録、と。

0891デフォルトの名無しさん

2008/02/28(木) 12:44:18

0892デフォルトの名無しさん

2008/02/29(金) 00:48:00

元々何の信念もなく便利だからって適当に機能ぶちこんだだけのグチャグチャ言語に
今更何を言ってるんだ

0893デフォルトの名無しさん

2008/02/29(金) 01:03:24

>>892
馬鹿にされるから他では言わないほうがいいよ、その脳内C++ヒストリー。

0894デフォルトの名無しさん

2008/02/29(金) 02:19:46

そうですか
じゃあこのC++と呼ばれる雑多にぶち込まれた大量の機能が
お互いひどい副作用を起こし合ってるグチャグチャ言語は
一体どんな高尚な理念で作られたものなんですか

0895デフォルトの名無しさん

2008/02/29(金) 02:32:47

DnE 読んどけ

0896デフォルトの名無しさん

2008/02/29(金) 03:18:54

無知ゆえに思い上がった口をきく若いオタクが興奮すると、文体似るよな、どういうわけか。

0897デフォルトの名無しさん

2008/02/29(金) 03:54:17

C++を雑多と呼ぶのはよした方が良い。
JavaやRubyなんかと違って、ここまで基本的な部分から整合性の練られた言語は他にない。
多くの機能は基本的な構文から基本的に導出されるが、JavaやRubyはそれらのプロセスを
すっ飛ばして機能が実装されている事が多く、とても自由と小回りの利く言語じゃない。

0898デフォルトの名無しさん

2008/02/29(金) 04:25:57

Javaは曲がりなりにも「現実世界で、現実をどうにかするために」歩みを進めてきたけど、
Rubyは話にならない。現実よりも白昼夢のほうが大事な、言語オタの妄想の産物。
前線には一切出ず、安全地帯で仲間とダベりながら延々「クールな匍匐前進」を模索してる兵士が、
「俺はこの最高の匍匐前進でこの戦争を生き抜いてるんだ」って真顔で言い張ってるみたいな言語。役立たず。

0899デフォルトの名無しさん

2008/02/29(金) 05:02:14

という話はスレ違いなのでよそでやろうな。

0900デフォルトの名無しさん

2008/02/29(金) 05:27:54

技術レベルの低い話は華麗にスルーしましょうよ。
規格ドラフトを読むような人が集まってんだからさ。

0901デフォルトの名無しさん

2008/02/29(金) 09:52:56

糞してくるわ

0902デフォルトの名無しさん

2008/02/29(金) 10:34:26

スルーなの?
具体的にどのようなひどい副作用があったのか聞きたいんだが

0903デフォルトの名無しさん

2008/02/29(金) 10:41:11

>>902
妄想を聞きたいならせめてマ板でやってくれ。

0904デフォルトの名無しさん

2008/02/29(金) 11:34:16

いい糞出たわ

0905デフォルトの名無しさん

2008/02/29(金) 12:28:11

895 もかいてるが、Design&Evolution of C++ を読んでから出直してこいとしか言い様がない

0906デフォルトの名無しさん

2008/02/29(金) 13:20:10

ちゃんとした本を読むと、最初の意見（>>892）を変えなきゃいけなくなるから、
ここで文章の素人達に不完全で不足の多い文章を書かせて、それに向かって
そんなの信念があるうちに入らない、適当でしかない、と言って初期設定を維持するつもりなのでは。

0907デフォルトの名無しさん

2008/02/29(金) 14:21:08

ミスを犯すのは常に人。

初心者にはそれがわからんのです。

0908デフォルトの名無しさん

2008/02/29(金) 17:53:25

同じ予約語に3つも4つもまったく違った意味を与えたり
機能を作るたびに別の目的に悪用されて、同じような機能を何度も付け足す羽目になったり
無節操に記号に新しい意味を与えまくってパースを複雑怪奇にしたり
わざとミスさせようとしてるとしか思えませんが

0909デフォルトの名無しさん

2008/02/29(金) 17:55:11

マジレスすると無節操に記号に新しい意味を与えまくってもパースは複雑怪奇にはならない。

0910デフォルトの名無しさん

2008/02/29(金) 18:06:13

例えば不等号なんぞを無理矢理カッコ的なものに仕立てたせいで
どれだけの脳内パーサが誤作動してると思う？
includeで使ってるからってなんも考えずにプリプロセッサの世界からコンパイラの世界に
持ち込んだバカのせいじゃないか
違うか

0911デフォルトの名無しさん

2008/02/29(金) 18:08:29

無知なまま何を「思っ」たところで的外れなだけだから、
無知でなくなるための行動を起こすべきだろうね。既に本も薦められているのだし。

「何故それはそうでなければならなかったのか」という話に関して、
C++ほどシリアスでプラグマティックな内容盛り沢山の言語もそうは無い。
他の言語が「だってそのほうがきれいなんだもん」くらいの理由で決めちゃうところでも、
C++は「現実」を相手に、全然別の戦いをし続けてきたからな。

今の君の頭からは、>>892を裏付ける話は一切出てこないから、マシな頭になる努力をまずしよう。

0912デフォルトの名無しさん

2008/02/29(金) 18:11:01

何も考えていないことにしたい人が
考えの跡をしこたま記した本をこわがってるスレはここですね

0913デフォルトの名無しさん

2008/02/29(金) 18:15:41

じゃあ何をどう考えてるのか教えてくれよ
例えばstaticという語がバラバラのまったく違う4つの意味を持っていた方がよいと考えた理由教えて
その本に書いてあるんだろ

0914デフォルトの名無しさん

2008/02/29(金) 18:21:40

ああ、これが>>906の読んだ展開か

0915デフォルトの名無しさん

2008/02/29(金) 19:09:57

>>911
Javaやスクリプト言語は「現場の実情」に応える方向で発展したけど、
C++はそれ以前に「数学的現実」に足をすくわれ続けているような。
slice_arrayが動かないとかvector<bool>がコンテナじゃないとか。
テンプレートなんて、パースできなくてtypenameキーワードなんてものが
必要になった時点で常識的には破綻したというべきだし、
チューリング完全性が明らかになった時点でもう一度破綻している。
こうなるくらいだったらC++コンパイラにMLインタプリタでも組み込んだ方がマシ。

0916デフォルトの名無しさん

2008/02/29(金) 19:17:25

>>913
残念ながら、無名名前空間でファイルスコープのstaticを排除して、
C++のstaticは静的メンバという意味しか持たないようになったという流れなんだが。

0917デフォルトの名無しさん

2008/02/29(金) 19:30:19

>>915
＞テンプレートなんて、パースできなくてtypenameキーワードなんてものが
＞必要になった時点で常識的には破綻したというべきだし、
これは理解できるとして

＞チューリング完全性が明らかになった時点でもう一度破綻している。
こっちはなぜ？

0918デフォルトの名無しさん

2008/02/29(金) 19:51:55

メタプログラミングなんて邪悪だしJavaに無いし要らないってこと。

C++ の利用者は喜んで便利に使ってるが、それはそいつらが悪趣味な
せいであって、断じてテンプレートの利便性を証明するものではない。

0919デフォルトの名無しさん

2008/02/29(金) 19:53:11

テンプレートはあくまでもジェネリクス用の構文であって
ありとあらゆることに悪用できる万能の箱として用意されたものではないだろ
C++マニアはそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではgoto文と大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

0920デフォルトの名無しさん

2008/02/29(金) 19:59:20

テンプレートメタプログラミングは「発見」されたのだ！とか誇らしげに言ってるC++信者とかたまにいるけど
それって結局は自分らが加えた仕組みが何をもたらすのか、誰もわかってなかったってことじゃないの

あ、C++は全てにおいて考え抜かれた言語だから当然DnEには想定の範囲内だったと書いてあるんですよね
ｻｰｾﾝ

0921デフォルトの名無しさん

2008/02/29(金) 19:59:29

テンプレート、ポインタ、動的確保はgotoと同じく排除しよう
現物使用は避けるべき
STLを主軸に据える

0922デフォルトの名無しさん

2008/02/29(金) 19:59:49

あんまり本気で主張するつもりはないけど：

Javaのバイトコードは本来ポータビリティのためのものであって、直接バイトコードをいじって
なんでもできる万能の素材として用意されたものではないだろ
DI 信者はそれが嬉しいんだろうけど、やりたい放題出来ちゃうという意味ではアセンブラと大して変わらん
メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

という状況と対比するとC++の方がまだ健全に思える。

0923デフォルトの名無しさん

2008/02/29(金) 20:02:05

>>921
矛盾していないか？テンプレートとSTLとか。

0924デフォルトの名無しさん

2008/02/29(金) 20:05:36

現物 = テンプレート、ポインタ、動的確保
ラッパー　= STL

0925デフォルトの名無しさん

2008/02/29(金) 20:05:38

try-catch文の醜悪さに比べれば、丁寧に書かれたgoto文の例外処理の方がずっと読みやすいし美しいと思う
ごめん関係なかった

0926デフォルトの名無しさん

2008/02/29(金) 20:06:49

>>919
Cのプリプロセッサでジェネリクス実現しちゃう人だっていたんだから、
C++でそれ用の構文を用意したのは一歩進化だろ。
C++0xでconstexprも用意されたし、さらに一歩前進してるじゃないか。

なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

0927デフォルトの名無しさん

2008/02/29(金) 20:42:43

>>919
>メタプログラミングをさせたいのなら、最初からそれ用の仕組みを作るべきなんじゃないのか

shiroさんも最近似たこと言ってたね。

ttp://reddit.com/info/62o9s/comments/
＞Lispマクロを言語に入れない理由として、
＞よく「文法が変わるから他人の書いたコードが読めなくなる」と言われますが、
＞カンマ演算子をこんな使い方したらもう充分読めないでしょうってことです。

0928デフォルトの名無しさん

2008/02/29(金) 20:43:47

>>926
> なんか技術与えられたら、想定外のことに使おうとするのはプログラマの悪い癖だと思うけど。

限界を試すのは重要と思われ。
ジャンボジェットのお披露目でバレルロールだっけ？　やっちゃったテストパイロットみたいに。

それをプロダクトに積極的に使おうとかやりだすと、ちょwww だけど。

0929デフォルトの名無しさん

2008/02/29(金) 21:24:04

>>920
ちょっと論点のずらし方が卑怯すぎて気持ち悪いなぁ、君は。
DnEが証明するのは、「何も考えていないわけではないこと」であって、「すべてを考えていたこと」ではないよ。
そして、少しでも「考えていたこと」があれば、>>892が馬鹿なことを言っていたことになるのを、忘れちゃダメだよ。

0930デフォルトの名無しさん

2008/02/29(金) 22:32:22

C++でgotoなんて危険すぎて使えんわ。
そのための例外なのに。

0931デフォルトの名無しさん

2008/02/29(金) 22:39:45

お前は全国の後藤さんを敵に回した

0932デフォルトの名無しさん

2008/02/29(金) 22:40:48

gotoさんの髪茹でたい

0933デフォルトの名無しさん

2008/02/29(金) 22:59:39

ここってなんのスレだったっけ？

0934デフォルトの名無しさん

2008/02/29(金) 23:07:04

次スレ建てました
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

0935デフォルトの名無しさん

2008/02/29(金) 23:11:43

>>933
美少女中学生が顔を赤らめながら指の隙間からチラチラと覗くスレ

0936デフォルトの名無しさん

2008/02/29(金) 23:34:59

大体他人が自分自身と一緒にPCを見ていなければ、顔は赤らめても赤らめなくてもどうでも良いけど
恥ずかしがって指の隙間から顔を隠しつつ見なくてもいいだろ。
最近の子供は意識の根底に公私混同が見られて将来が危ぶまれるな。本当にしっかりしてほしい。

0937デフォルトの名無しさん

2008/03/01(土) 01:30:58

まあ、繰り返しになるが、DnE 読んでから出直せとしか言い様がない。

あれは C++ 信者でない人にとっても、どのような方針で言語を拡張していくと
こういうトンでもないことになってしまうのかという様子が詳細に書いてある
という点で非常に勉強になりますよ。C++ スレで煽るためにも、
すぐ反論されないように基礎知識を磨いておくことも重要です。
まずは敵を知ることからです。

というわけで DnE 読んでから出直してください

0938デフォルトの名無しさん

2008/03/01(土) 02:04:38

了解です。

0939デフォルトの名無しさん

2008/03/01(土) 02:33:45

try節ローカルなオブジェクトをcatch節で見られるようにさえなれば何でもいいよ

0940デフォルトの名無しさん

2008/03/01(土) 02:35:39

それは同意
Hoge* p;
try{
p= new Hoge();
}catch(){
}
とかダサすぎる
pそこに置く意味ねぇだろと

0941デフォルトの名無しさん

2008/03/01(土) 03:29:56

>>939-940
try{
Hoge* p = new Hoge();
}catch(){
}

仮に catch の中で p が見れたとして、 new Hoge() から例外が飛んだ場合は
p の初期化が済んでないわけだが、そんなものを見られるようにして何に使うの？

0942デフォルトの名無しさん

2008/03/01(土) 08:44:04

>>941はわざとか？天然か？

0943デフォルトの名無しさん

2008/03/01(土) 08:54:03

これがポインタではなくデストラクタのあるクラスのインスタンスだと考えると
スコープの差異による影響は?

0944デフォルトの名無しさん

2008/03/01(土) 09:59:01

確かに>>940は例が悪いな

0945デフォルトの名無しさん

2008/03/01(土) 10:10:34

例が悪さが、他人の頭の悪さを引き出したケース。

0946デフォルトの名無しさん

2008/03/01(土) 10:32:56

初心者スレ行けと

0947デフォルトの名無しさん

2008/03/01(土) 18:00:25

上の例ならスマートポインタ使うよな。

0948デフォルトの名無しさん

2008/03/01(土) 18:36:38

ぬるぽ

0949デフォルトの名無しさん

2008/03/01(土) 19:54:46

華麗にスルー

0950デフォルトの名無しさん

2008/03/01(土) 19:55:59

>>941
using {
　Hoge* p = NULL;
} try {
　p = new Hoge();
} catch(...) {
　// p を使用
}

こうすればいい。

0951デフォルトの名無しさん

2008/03/01(土) 19:56:52

突っ込んじゃ負けとかいうゲームですか？

0952デフォルトの名無しさん

2008/03/01(土) 20:00:30

コンストラクタの中で例外を投げるなんて変態すぎる。

0953デフォルトの名無しさん

2008/03/01(土) 20:01:36

RAII全否定ですか

0954デフォルトの名無しさん

2008/03/01(土) 20:04:00

>>952
m9（＾Д＾）ﾌﾟｷﾞｬｰ
http://www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html

0955デフォルトの名無しさん

2008/03/01(土) 20:04:10

RAII（）笑

0956952

2008/03/01(土) 20:05:55

(´；ω；`)おっおっううぇああぁああぅぅおぉぉおお

0957デフォルトの名無しさん

2008/03/01(土) 20:09:17

C++ ならデストラクタ使えよってことなんだろう。

0958デフォルトの名無しさん

2008/03/01(土) 20:10:34

>>956
お前はたぶんオレと同じスレをみている
さぁガイドライン板に帰ろう

0959デフォルトの名無しさん

2008/03/01(土) 20:15:25

泣いたらスカッとしました。

0960デフォルトの名無しさん

2008/03/01(土) 21:44:46

関係なかった俺まで泣いた

0961デフォルトの名無しさん

2008/03/02(日) 00:30:37

>>954
切られている「比較的有名なサイト」ってこれだよね、たぶん。

C MAGAZINE - プログラミングの禁じ手Web版 C++編
ttp://www.cmagazine.jp/src/kinjite/cpp/

適当にうろうろして見たところ、参考にしている人がそれなりにいる様子。
初心者が鵜呑みにするとまずいことを広められるのは困るなー。

0962デフォルトの名無しさん

2008/03/02(日) 00:41:02

C編はいいんだけどね

0963デフォルトの名無しさん

2008/03/02(日) 01:03:15

これ訂正してもらえないの？
いつまでもWeb上に残ってると勘違いするやつが後を絶たないと思うんだけど。
特にポインタのメンバが不定値になるとか、初期化子も知らないような書き方だし。

それともCマガの中の人は確信犯なんだろうか。

0964デフォルトの名無しさん

2008/03/02(日) 01:28:38

エキスパートなお前らの間ではコンストラクタで例外投げてもOKって判断なの？

0965デフォルトの名無しさん

2008/03/02(日) 01:30:54

自分では投げない場合も、投げられた場合への配慮は必要

0966デフォルトの名無しさん

2008/03/02(日) 01:32:30

>>963
糞ページ、糞本認定だけでいいじゃん。
それだって初心者スレでやるべき事だし。
>>963
初心者スレ行って教えて貰ってこい。

0967デフォルトの名無しさん

2008/03/02(日) 01:33:16

オブジェクトの構築に失敗したのに例外を投げないコンストラクタを持つクラスなんて、
初心者には使わせたくないな。

0968デフォルトの名無しさん

2008/03/02(日) 01:35:23

どっかの腐ったフレームワークの悪影響だろうね

0969964

2008/03/02(日) 01:41:54

例外を投げないような初期化だけをコンストラクタでやって、
Initialize()とかのメソッドを作ってるんだけど。
なんだ、じゃぁ俺もバンバン例外なげるようにするよ

0970デフォルトの名無しさん

2008/03/02(日) 01:51:53

>>969
今までそう作ってきたなら、あえて変える必要は無いんじゃない。
問題なのは、「安全な処理のみでコンストラクタを実装していること」ではなく、
「安全でない処理に失敗したときに例外を投げないこと」なのだから。

0971デフォルトの名無しさん

2008/03/02(日) 01:53:18

今気づいたけどスレ違いだな

0972デフォルトの名無しさん

2008/03/02(日) 08:25:21

うっすらと恥ずかしい毛が生えてきた美少女中学生のスリット違い

0973デフォルトの名無しさん

2008/03/02(日) 10:47:13

古いんだよなアレ今となっては。著者が表に出る活動を凍結してるせいも
あるんだろうが。

0974デフォルトの名無しさん

2008/03/02(日) 15:29:11

RAIIイディオムが一般的じゃなかった時代の知識だね
今となっては古臭い

0975デフォルトの名無しさん

2008/03/02(日) 22:02:27

90年代から知られてるんだけどなw
そのための初期化子リストだし。

0976デフォルトの名無しさん

2008/03/02(日) 22:16:51

自分は何歳の若い美少女に手を付けたことがあるぞ～って自慢する人がいるよね

俺は中学生が最高だと思いますが。おっぱい

0977デフォルトの名無しさん

2008/03/04(火) 12:43:23

手を付けたことはないが
手に付いたことはある

0978デフォルトの名無しさん

2008/03/04(火) 13:11:08

手を付けたことはないが、
懐かれたことはある。

0979デフォルトの名無しさん

2008/03/04(火) 22:05:29

おまえらここは0x歳の美少女に手をつけるスレじゃないぞ

0980デフォルトの名無しさん

2008/03/04(火) 22:33:52

8歳未満はさすがにちょっと

0981デフォルトの名無しさん

2008/03/05(水) 00:10:09

何進なのかが問題だ

0982デフォルトの名無しさん

2008/03/05(水) 00:14:59

0頭でC系なら8進だろ、で1桁だから8歳未満

0983デフォルトの名無しさん

2008/03/05(水) 00:15:30

x が数値として使われている以上、34進数以上だろう。
そして、34進数以上のどの進数だろうが、
0x は 33 になる。
X と x を使い分けるとなってくると話は変わってくるが・・・。

0984デフォルトの名無しさん

2008/03/05(水) 00:28:38

33で美少女はねーよｗってかそろそろスレチだからおわろー

0985デフォルトの名無しさん

2008/03/05(水) 00:29:50

つか、スレ自体が終わりそうだし

0986デフォルトの名無しさん

2008/03/05(水) 01:40:31

そういえば1000が近いな

0987デフォルトの名無しさん

2008/03/05(水) 22:48:08

1000だったら（俺が出て行ってやっつけるのは）難しい

0988デフォルトの名無しさん

2008/03/06(木) 00:17:30

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/#mailing2008-02

ってもうスレで話題になってた？

0989デフォルトの名無しさん

2008/03/06(木) 00:28:57

ここの住人なら言われるまでもなく当たり前のように読んでいると思ってた

0990デフォルトの名無しさん

2008/03/06(木) 01:04:52

N2518, Compiler Support for type_traits
この提案とconceptの関係がワカランのだが?

0991デフォルトの名無しさん

2008/03/06(木) 21:30:06

立てれなかった。誰か頼む。

C++0x 3

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

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/

0992デフォルトの名無しさん

2008/03/06(木) 21:32:13

ここは？
C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

0993デフォルトの名無しさん

2008/03/06(木) 21:33:56

そこは放棄されたスレ。

0994デフォルトの名無しさん

2008/03/06(木) 21:55:07

C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/

たてますた

なんとなくwikiのリンクを貼ってみた

0995デフォルトの名無しさん

2008/03/06(木) 21:56:14

乙

0996デフォルトの名無しさん

2008/03/07(金) 05:06:41

0997デフォルトの名無しさん

2008/03/07(金) 05:07:07

0998デフォルトの名無しさん

2008/03/07(金) 05:09:10

0999デフォルトの名無しさん

2008/03/07(金) 05:09:36

1000小倉優子 ◆YUKOH0W58Q

2008/03/07(金) 05:09:56

1000ならジュースでも飲むか

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。