C++0x 12

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

2011/02/23(水) 23:20:44.31

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

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

前スレ: C++0x 11
http://hibari.2ch.net/test/read.cgi/tech/1285884294/

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

2011/02/23(水) 23:21:26.18

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

2011/02/23(水) 23:43:13.36

KISS

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

2011/02/24(木) 01:27:18.29

kill internal secret scope

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

2011/02/24(木) 02:06:52.32

次の C の規格が決まるのは 2012 年らしいけど、次の C++ は 0x12 年かあ、大分先だな

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

2011/02/24(木) 04:19:57.24

>>1乙

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

2011/02/24(木) 05:06:30.41

Cはもう新しい機能組み込まなくて良いよ。
どうせ対応しないんだから…

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

2011/02/24(木) 05:07:55.60

脳が硬直化したゴミおっさんは変化を嫌うからね。

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

2011/02/24(木) 05:20:34.15

C++はどんどん新しい機能を組み込んで良いよ。
どうせ対応しないんだから…

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

2011/02/24(木) 10:04:21.46

>>7
VC以外は大抵C99に(十分実用的なレベルで)対応してるから、
C1Xも多分対応するよ。

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

2011/02/24(木) 10:31:31.48

VC以外はって、gccとclangぐらいじゃね？
bccもdmcもopenwatcomも、和製CPU向けの組込みコンパイラも、複素数や複合リテラルなんて使えないはず……

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

2011/02/24(木) 10:42:17.18

>>7
マイナーチェンジはともかく
メジャーチェンジでは削除もすべきだな

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

2011/02/24(木) 10:47:06.66

とりあえずCは配列を値型として返せるようになるべきと思うんだ。
C++のstd::arrayとか無視して。

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

2011/02/24(木) 11:02:17.43

intelのiccを忘れてやるなよ。
あとbccはともかく、bmcは複合リテラルも複素数も使えるし、
WatcomCも undocumented feature という断りはあるものの
C99実装が入ってるよ。

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

2011/02/24(木) 11:04:13.44

bmcってなんだよ。dmcと間違えた。

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

2011/02/24(木) 12:15:24.76

C99も10年以上経っているのに
いつまでもコンパイラが枯れないね

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

2011/02/24(木) 12:24:04.94

>>16
何そのFUD?
コンパイラがC99完全準拠してないことを
枯れてないというなら、
C++はもっと枯れてないぞ。

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

2011/02/24(木) 13:22:06.14

枯れないというより周りの対応がいまいちかな
gslとかいつ_Complex対応するの？ってやつ

まあでもC++も時間かけてここまできたんだしこれからじゃないの

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

2011/02/24(木) 13:39:25.42

C99対応って言うとC++が例にあがるけど、Objective-Cって、
どの程度C99に対応してるのかな…？

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

2011/02/24(木) 13:52:41.77

>>9
投げやりな事言うなよｗ
Boostという強い味方がいるし

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

2011/02/24(木) 14:03:26.30

>>12
gets 削除だぜ

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

2011/02/24(木) 14:07:06.57

>>19
言語仕様としてはObjective-CはC99の(そしてC89とも)完全上位互換だよ。
コンパイラとしては、gccが対応している程度には対応してる。

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

2011/02/24(木) 16:08:08.65

>>22
で、そのObjective-CにはQtに相当するライブラリはあるの？

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

2011/02/24(木) 17:29:50.76

>>23
そりゃCocoaだろ。
Apple関係でしか使えないけど、
逆にそれ以外じゃObjective-Cなんて使わん。

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

2011/02/24(木) 17:33:26.03

Cocoaって言うか、iPhoneとか、iPadのコンソールアプリって作れるの？

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

2011/02/24(木) 18:12:35.12

なぜ作れないと思ったのか。

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

2011/02/24(木) 18:19:37.07

興味なかったから
コンソールアプリ作ると、あの画面上に、つらつらと文字が表示されるのか？

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

2011/02/24(木) 18:23:25.23

http://iphoneroot.com/wp-content/uploads/2010/05/93613164-1.jpg

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

2011/02/24(木) 18:31:09.59

へぇ～
iPadだったら問題なく使えそうだね
iPhoneだと、画面が小さいから工夫が必要だな…

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

2011/02/24(木) 19:18:40.02

作ったところで審査通るわけないだろw

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

2011/02/24(木) 20:00:33.31

自分で作ったアプリも審査通さないと、自分の実機で実行できないのか？

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

2011/02/24(木) 20:36:55.77

んな訳ないじゃん。つーかスレチ。余所でやれ

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

2011/02/24(木) 21:58:47.01

ラムダとか独自構文作ってないでBlocksを取り入れろよなー
マイナー言語の癖に

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

2011/02/24(木) 21:59:34.61

むしろあの腐ったリンゴは何でBlocksなんか作ったんだよ……

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

2011/02/24(木) 22:00:24.98

Grand Central Dispatch のためだよ。

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

2011/02/24(木) 22:09:50.74

規格策定始めた頃は今の状況が予想できなかったんだろうなぁ
ラムダなんか捨ててBlocksを使うように考え直した方がいいよ
今からでも遅くない

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

2011/02/24(木) 22:24:05.46

見てきたがきめぇな
変態ってレベルじゃねーぞ

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

2011/02/24(木) 22:31:17.21

そりゃスッキリしていたら 0x 年の内に完成しただろうさ・・・

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

2011/02/24(木) 22:31:44.19

関数ポインタの * を ^ にしただけジャン。

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

2011/02/24(木) 22:40:57.84

^の使い方がC++/CLIと被るのが若干気持ち悪いな。文法そのものはCの自然な拡張ならあんなもんじゃない？

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

2011/02/24(木) 22:46:25.41

typedefで定義した型名でもオーバーロード出来れば便利だと思うときない？

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

2011/02/24(木) 22:51:10.96

こんなか？

typedef int (*f)(int) | float (*f)(float);

int a(int x) { return x + 1; } // 1
float a(float x) { return x + 1.0; } // 2

f p = a;
p(10); // call 1
p(5.5); // call 2

実装は関数ポインタの組でいけそうだが、欲しいところが思いつかない。
……とここまで書いて気がついたが、単にstrong typedefが欲しいって話か(汗

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

2011/02/24(木) 23:03:56.76

strong typedefってのが良く分からんけど、こんな感じ

#include <iostream>

typedef int mint;

void foo( int i ) {
std::cout << "foo( int ): " << i << std::endl;
}

void foo( mint m ) {
std::cout << "foo( hoge ): " << m << std:: endl;
}

void bar( int i ) {
std::cout << "bar( int ): " << i << std:: endl;
}

int main() {
int i = 5;
mint m = 10;
foo(i); // void foo( int )を実行
foo(m); // void foo( mint )が定義されているのでvoid foo( mint )を実行
bar(i); // void bar( int )を実行
bar(m); // void bar( mint )が定義されてないのでプリミティブなvoid bar( int )を実行
return 0;
}

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

2011/02/24(木) 23:10:21.92

void baz( mint m ) {
std::cout << "baz( mint ): " << m << std:: endl;
}

baz(i) は？

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

2011/02/24(木) 23:22:25.87

>>44
明示的にキャストしないとコンパイルエラー
イメージとしては継承みたいな感じで
自分から一番近い継承元へ暗黙的に継承されるが、
継承先へはキャストされない

まぁ、今までのコードが通らなくなるから、typedefって名前じゃなくても良いけど…

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

2011/02/24(木) 23:23:30.25

Blocksは変数キャプチャの管理がおぞましすぎて
匿名関数として使うならともかくラムダとしては無いわ
場当たり仕事で言語作ってんじゃねえよ

Blocksを見てから戻ってくるとラムダさんの珍奇な服が合理的に見えるから不思議だ

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

2011/02/24(木) 23:29:36.61

暗黙的に継承って、おれアホだ…orz
>自分から一番近い継承元へ暗黙的に継承されるが、
自分から一番近い継承元へ暗黙的にキャストされるが、

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

2011/02/25(金) 01:50:33.54

>>40
`^' で、返り値を指定するのは、smalltalk 由来。
(「Objective-C だし、たぶん、そうでしょう。」ぐらいの確かさだけど。)

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

2011/02/25(金) 02:16:33.37

^はそんなに気にならないな
むしろ__blockとかBlock_copyとかに吐きそうになる

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

2011/02/25(金) 06:16:03.01

>>43
それをstrong typedefという。初期D言語にあったが今は撤廃されてるはず。あとAdaにもある。

ところで、int f(int)にmintを渡した場合、返値の型はどうなる？

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

2011/02/25(金) 17:57:17.24

>>50
int f( mint, int )とかの場合、判断できないからintが戻る
そう考えるとint型に対してmint()への暗黙的変換のルールがないと
関数呼んだ時に、毎回キャストが必要なのは不便だな…

operator int::mint() const { return (mint)( *this ); }

クラスじゃないのにint::mint()とかthisとかキモい…orz

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

2011/02/25(金) 18:52:30.31

それならint::operator mint()じゃないの？

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

2011/02/25(金) 19:18:57.50

>>52
そうだね

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

2011/02/25(金) 19:39:18.82

>>51
例えばAdaなら、intからmintを作った時点でint f(int)があれば、mint f(mint)もできる、
int f(mint, int)みたいなのはmint定義後でしか作れないから、こっちは常に定義通りintが返る、
みたいなルールがある。

あと暗黙の変換があると逆に微妙じゃね？
あって嬉しいのは整数リテラル→mintぐらいじゃ？

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

2011/02/25(金) 20:21:06.15

>>54
>例えばAdaなら、intからmintを作った時点でint f(int)があれば、mint f(mint)もできる、
それが出来るなら、そっちの方が良いけど、実装を考えると大変じゃない？
例えば、標準ライブラリとどうやってリンクさせるかとか…
って中間ファイルを作れば良いのか…？

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

2011/02/25(金) 20:26:28.86

>>55
リンクって……実体はひとつしか無いんだから。どっちもアドレスとると同じ関数だよ。
でもC++だとマングリングがあるから微妙かもな。

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

2011/02/25(金) 20:30:21.06

>>56
>でもC++だとマングリングがあるから微妙かもな。
そのためにリンク用の中間ファイルを作ればいけるのかって話

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

2011/02/25(金) 23:49:09.51

単純にコンパイラ的には中身空っぽの継承を一発宣言出来る記法があればいいんじゃないの

あとint f(int)とmint f(mint)が両方欲しいならtemplate使えがC++流だと思う

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

2011/02/26(土) 00:33:42.71

>>58
それは違う。
具体的用途としてはintからwidth型を作って、weight型との混同を防いだり
cout <<で専用の出力を用意したりになると思うので、
absのような汎用int向け関数はそのまま使いたいはず。

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

2011/02/26(土) 01:24:09.25

>>59
だからwidth型をint型の派生型として扱うような何らかの文法を用意すればいいんじゃないの?
abs(int i)はabs(width i)を用意しなければ暗黙キャストじゃん

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

2011/02/26(土) 02:30:00.71

>>58
現在あるプリミティブな型を全てクラス扱いにすればその通りになるが、
実装を考えると、なかなか厳しい。
標準ライブラリを切り捨てれば出来そうでもあるけど…

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

2011/02/26(土) 02:50:09.24

>>61
いやもちろん実際にクラスとして扱えって言ってるんじゃなくて、
strong typedef構文を作って論理的にコンパイラ上で継承っぽく扱うだけでよくね、って話な
manglingの互換性についてはstrong typedefのある世界から無い世界のライブラリを呼ぶ分には上位互換が保てるはずだし逆は有りえない

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

2011/02/26(土) 03:49:41.58

>>62
単純に上位互換は難しい気がする。
extern "primitive"
とかにすれば、ほぼ問題はないと思うけど、やりたくないでしょ？

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

2011/02/26(土) 05:40:13.63

>>60
引数はいいけど返値どうするのよ。毎回ダウンキャストする羽目になるぞ。

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

2011/02/26(土) 05:44:20.78

>>64
templateで解決って方向じゃダメ?

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

2011/02/27(日) 01:50:12.67

Dでstrong typedefが無くなった理由は何なの？

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

2011/02/27(日) 19:30:53.14

range-based forの変更の可能性。
http://cpplover.blogspot.com/2011/02/range-based-for.html

意見求む。

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

2011/02/27(日) 19:51:14.58

コンセプトが復活するまで無くしちまえという案はないのか

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

2011/02/27(日) 20:00:26.49

まあ案４でいいんじゃないの？
begin/endの外部関数を作るくらいなら
アダプタクラス作ったのでも手間は大差ないし、
ADLは俺もキモいと思う。

まあそもそもbegin/endメンバ関数が特別扱いになる時点でキモいけど。
range-based for 用として使えないようにする指定も必要ではないのだろうか？

>>68
いっその事コンセプトを復活させてしまおうという案はないのか

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

2011/02/27(日) 20:17:53.39

コンセプトまでrange-based forやらないのならもう0xはrange-based for無しでやれよw

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

2011/02/27(日) 20:35:03.88

>>67
この人、日本語変だなあ

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

2011/02/27(日) 21:45:45.05

for_eachを利用する側の責任でbegin、endが銅のこうの言う事自体おかしいと思うんだ

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

2011/02/27(日) 22:28:49.16

1.コンテナの先頭アドレスを返す特別な演算子 beginof を作る。
2.コンテナの終端アドレスを返す特別な演算子 endof を作る。
3.要素列の次の要素のアドレスを返す特別な演算子 nextof を作る。
4.上記3つの演算子をユーザー定義可能にする。
5.beginof, endof, nextof の3つの演算子が定義されているオブジェクトは range-based for に渡せるものとする＾＾

Container Obj;
for ( beginof Obj; endof Obj; nextof Obj ) { ...

のような記述もあり＾＾

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

2011/02/27(日) 22:51:24.70

おもしろ言語になっちゃうな。

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

2011/02/27(日) 22:52:43.20

どんな変なことになってもAda2012の同機能の提案よりはマシに思える俺ガイル。

案1) begin/endに相当する関数を、型宣言と一緒に変態構文で書かせる……。
　type T is (型宣言) with Variable_Indexing => (関数名), Default_Iterator => (関数名), 以下同様;

案2) begin/end相当のメンバ関数を持った特殊なクラスを継承させる……。

どっちも後付け不可能な上にキモいことこの上ない。
そもそもforeachのはしりのVBやらC#とかだってIEnumeratable継承してるわけだから
後付け可能な方向で進められてるだけC++は幸せと思うべき。
ADLでもなんでもそれに使える機能がある時点で恵まれてるじゃないか……。

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

2011/02/27(日) 23:51:33.69

range_traitsを使う案2が好み

まあコンセプトなしならrange-based forやめろとか
間に合わせの為にADL使うのはまじでやめろとかは思う

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

2011/02/27(日) 23:54:00.07

何がC++をこうしたんだろうな。templateの導入が分水嶺だったか。

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

2011/02/28(月) 00:14:23.29

案４はforを書くたびにAdaptorでラップしなきゃいけないのか？
かなり面倒だな。せっかくfor文が短くなるんだからAdaptorなんてタイプしたくない。
traits案で何とかしてほしい。

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

2011/02/28(月) 00:20:16.43

traitsを採用してしまうと、将来、TR2とかで、Rangeという一般的な概念をライブラリに持ち込む際、
既存のコードをどう取り込むかという問題に直面する。

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

2011/02/28(月) 00:32:06.41

変なルールを持ち込むとC99みたいな運命になるしな＾＾

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

2011/02/28(月) 00:34:03.53

その前に完成しないとな＾＾

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

2011/02/28(月) 07:44:07.67

これ以上ごちゃごちゃするなら、C++は最低限の修正に抑えて、
Cとの互換性に重きをおいて、追加したい規格は別物にしてしまえと思う。

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

2011/02/28(月) 09:57:54.99

conceptがないならいらないかな
正直range-based forについてあれこれ議論する時間があるならconceptにあててほしい

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

2011/02/28(月) 23:07:21.55

renge-based for で enum 使えるようにしておくれ

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

2011/02/28(月) 23:09:50.15

C++がどこへ行こうとしているのか正直良くわからん。

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

2011/02/28(月) 23:10:04.16

>>84
Adaptor 使えばいける

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

2011/02/28(月) 23:21:37.54

>>79
range-based for に traits を採用したとしても
将来的に concept が復活したら
iterator_traits や type_traits と一緒に
deprecated になるのでは

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

2011/03/01(火) 00:17:58.41

全く関係ないbegin, endを持ったクラスで誤爆しないためにも、>>73が一番いいよな。

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

2011/03/01(火) 00:29:51.89

contextual keywordをもう取り入れちゃったんだから怖いもんないよな
operator begin()とか作ったっていい訳だ

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

2011/03/01(火) 01:17:58.56

traits方式が一番安全だと思う

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

2011/03/01(火) 01:26:45.24

後から簡単に脱着できる点ではtraits方式がいいかなー。

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

2011/03/01(火) 04:35:40.36

ttp://codepad.org/wxbJmLE7

暇だからrange_traitsを自作してみた。この系統の案が最適だと思ったからね。
でも根本的に勘違いしてることがあるかもしれないのでツッコミ募集。

で、作ってから本の虫の人のページに行ったら、その系統では何か似たようなこと書いてあって不思議な気持ちになった。
しかし、色々本の虫の人のページのやつから見て劣化してるから、すごい悲しいです。
だれかフォークしてもっといい感じにしてくれんかね。お願いプリーズ。

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

2011/03/01(火) 04:40:45.07

そうそう。コードパッドってC++0x対応してないのね。
VCで部分的にできてるから、ちょっと甘く見てた。

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

2011/03/01(火) 05:43:29.88

ideone.com使えばいいじゃん

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

2011/03/01(火) 07:03:27.08

>>92
根本的に間違っている。
traitsってのはオブジェクトとして使うことを想定してない。
動的なポリモーフィズムではなく、テンプレートによる静的なポリモーフィズムを利用する。
だから、begin/endは、staticメンバー関数になる。

まあ、簡易的な実装としてはこんな感じ

http://ideone.com/sHUiZ

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

2011/03/01(火) 12:54:33.07

range-based forは見送りでいいよ。大して便利そうじゃないし。
変な仕様入れるのだけは避けて欲しい。

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

2011/03/01(火) 14:14:45.33

ですよね。
集合をコンパイル時に把握出来る場合は条件分岐を完全に消してくれるとか
最低でもＳＩＭＤ化してくれるとかその位言語機能に密着したforeachなら欲しいけど

009892

2011/03/01(火) 15:35:15.94

>>94
今度実験してみますー。

>>95
指摘感謝。そういうルールは知らなかった。勉強になるよ。
個人的にはC#のIEnumerator的な感じのものを考えてたんだけど、ハズレだったか。
とはいえ、俺、C#はC++よりも素人なんだけどね。

いやー、大変勉強になったよ。これで、引っ込みます～。

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

2011/03/01(火) 18:38:43.21

現状(C++03)でもBOOST_FOREACH無しじゃ面倒でやってられないよ。
正直どんな形でもいいからrange-based forは入って欲しいね。

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

2011/03/01(火) 20:19:31.08

std::for_eachとラムダで現状不便を感じない
変な物は入れないで欲しい
どうせ後で邪悪な負の遺産になるんだから

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

2011/03/02(水) 01:55:43.32

>>67
0 comments なんでポストしてみたけど捨てられたお(´・ω・`)

まあいいや

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

2011/03/02(水) 02:59:57.14

手動でOpenするようになってんじゃ？

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

2011/03/02(水) 03:08:03.18

http://www.open-std.org/jtc1/sc22/wg21/
News 2011-02-28: The deadline for the next mailing is 2011-04-08
News 2011-02-28: The 2011-02 pre-Madrid mailing is available (9000 kB tar.gz, .zip 9000 kB)
News 2011-02-28: The C++ Standard Core Language Issues List (Revision 75) is available
News 2011-02-28: The C++ Standard Library Issues List (Revision 74) is available

最新ドラフトは N3242

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

2011/03/02(水) 18:24:27.87

変更少ねえｗｗｗｗｗ
そろそろ大詰めだな

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

2011/03/02(水) 18:55:19.24

range-based for の話は n3257 か

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

2011/03/02(水) 19:01:52.81

ぜんぜん関係ないんだけど、非依存ベースクラスからもたらされた名前が
テンプレートパラメータより優先されるっていうルールに対して
テンプレートパラメータを明示指定する方法が導入されたりってことはないの？

http://codepad.org/8k47jk4t

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

2011/03/02(水) 20:42:22.25

テンプレートマラメータ

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

2011/03/02(水) 23:44:51.52

>>106
gcc と VC++ で結果が違うよどうなってんの～

http://codepad.org/ckzgITKY

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

2011/03/03(木) 00:13:21.61

>>108
typeid().name()は環境依存だろ
保証されているのは同じ名前は同じ型を示す事のみ

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

2011/03/03(木) 00:30:58.93

いや、そういう話ではなく、VC++ではどちらも obj_ がint 型となってしまうって話。

JIS X3014 プログラム言語Ｃ＋＋
p.213
7 クラステンプレート又はクラステンプレートのメンバの定義の中では,
《テンプレート仮引数》(14.6.2)に従属しない基底クラスのなめのそれぞれに対して,
その基底クラスの名前又はその規定クラスのメンバの名前が《テンプレート仮引数》(14.6.2)と同じ場合,
その規定クラスの名前又はそのメンバの名前は,《テンプレート仮引数》の名前を隠す(3.3.7参照)

p.214
3 クラステンプレート又はクラステンプレートのメンバの定義の中で,
そのクラステンプレートの基底クラスが《テンプレート仮引数》に従属する場合,
修飾されていない名前の検索では,その基底クラスの有効範囲は,
クラステンプレート又はメンバの定義においても,
クラステンプレート又はメンバの具象化においても,対象とならない。

明確な規格違反。まぁ、VCはもともとテンプレートがまともに動かないことが周知されてるんでいいんだけど。

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

2011/03/03(木) 00:40:10.29

>>108
MSVC10では正しく動作するぞ。

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

2011/03/03(木) 00:50:06.00

>>111
内部バージョンいくつ？うちでは
int
int
と表示されてしまう…orz

VC++2010 Express 32bit版
10.0.30319.1 RTMRel

Expressだからダメなのか！(・_☆)

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

2011/03/03(木) 01:13:01.89

>>112
規格違反（MSに言わせればLanguage extensionらしいが）を無効にするオプション、/Zaを使っていないんだろう。

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

2011/03/03(木) 02:16:42.24

おぃいぇー。やっぱりExpression版だからだめだったようだ↓

http://msdn.microsoft.com/ja-jp/library/0k0w269d(v=VS.100).aspx
Visual Studio 開発環境でこのコンパイラオプションを設定するには
・プロジェクトの [プロパティページ] ダイアログボックスを開きます。詳細については、「方法 : プロジェクトプロパティページを開く」を参照してください。
・[C/C++] フォルダーをクリックします。　←そんなフォルダはない
・[言語] プロパティページをクリックします。　←そんなページはない
・[言語拡張を無効にする] プロパティを変更します。　←そんなプロパティもない

コマンドラインから指定したらできた。
コマンドラインのヘルプには

-Za 拡張子を無効にします

拡張子ってなんだよ…
それから、-Za を指定した上で windows.h をインクルードしたらエラーが大量にｗ

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

2011/03/03(木) 02:25:15.69

連投ですまん。
いっぺんプロジェクトを保存したら出てきた。（？）

ながながとスレよごしすまんかったよ。
忘れてくれ。

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

2011/03/03(木) 02:28:55.25

>>114
「拡張子」は extension を機械翻訳かなんかしたんだろう。

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

2011/03/03(木) 02:37:47.16

>>114
ちゃんとあるぞ。
そもそも正しくプロパティページを見ているかどうか疑問だな。

Windows.hは諦めろ。
いや、まあ無理だが。

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

2011/03/03(木) 03:52:00.22

int const * p; // コンストintへのポインタp
int • const p; // intへのコンストポインタp
int const * const p; // コンストintへのコンストポインタp
const int * p; // コンストintへのポインタp
な訳だが
const int * p; // int const * const p; と同義の方が良いのではないか？

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

2011/03/03(木) 06:45:47.31

>>118
せっかく整合性が取れてるものに、わけわからんルールを追加するのはやめようぜ
const typedef int* p とか int cont typedef* p とかみたくストレージ指定子が混ざったらどうすんのさ

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

2011/03/03(木) 06:49:40.73

むしろconst intの語順を禁止しようぜ。
そうすれば全部逆から読めば済むようになる。

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

2011/03/03(木) 06:57:31.58

誰が既存のコードを修正するんだい？

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

2011/03/03(木) 07:27:52.12

ソースコードフォーマッタ通すだけだろ。#defineさえ無ければだけどな！

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

2011/03/03(木) 07:56:52.96

int long unsigned const long *oops;

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

2011/03/03(木) 12:21:21.71

>>118
同義だとなにがうれしいんだ？
ぱっと見const intの配列がイテレートできなくなる誰特仕様だと思うんだけど

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

2011/03/03(木) 12:38:36.16

>>108
うわっVC10だと本当に両方ともintになる

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

2011/03/03(木) 18:17:00.31

言語拡張は結構だが、MSDNに
言語拡張を有効にすると名前解決のルールが変更になる旨が書かれていないのが問題だ。
いや、C++の利用される世界は大部分がWindowsなんだから
むしろISOがVC++の挙動について記載するべきで
標準規格はMS基準に準拠していないのですみませんと謝るべきか？

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

2011/03/04(金) 01:15:37.06

ほかにも、/Zaなしだと、ユーザー定義の型変換を二回、暗黙に適用したりするぞ。

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

2011/03/04(金) 01:46:27.01

井上まりなちゃんって学習院大学卒業のスーパーエリート貴族だから
超ドSらしいね＾＾

0129128

2011/03/04(金) 01:47:45.34

すごい誤爆だよ＼（＾o＾）／

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

2011/03/04(金) 07:11:22.00

＼（＾o＾）／

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

2011/03/04(金) 09:25:00.28

突然声優スレに

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

2011/03/04(金) 14:43:11.25

ここはlispスレではありませんや

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

2011/03/05(土) 11:36:40.49

ここはC++のプロが集まっているところだと思うので、ちょっと質問させてください。
普段からpure C++（およびC++0x）しか使ってなくて、困ったことはないのですが、
C言語のほうが短く簡単に書けるようなことってたぶん結構あるんじゃないかと思うのです。
思いつくのを羅列してみると、
- I/O関係（printf,scanf,...）
- マクロ
- 配列初期化
- ポインタ演算
C++0xでかなり改善されているとはいえ（autoとか）、対応するコンパイラがマシンに入ってない場合も多いので、
ちょっとC言語も勉強してみようと思うのですが、みなさんが普段dirtyテクニックとしてCを混在させているものを教えてください。

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

2011/03/05(土) 11:58:34.50

マクロにしろ配列にしろポインタにしろ、別に全部C++でも同じように使えると思うが
マクロはC++的にはなるべく排除したい方向だけどboostとかでは使いまくりだし好きにすればいいと思う
printfの方が便利なのは同意

0135133

2011/03/05(土) 12:05:47.74

ちょっと書き方がまずかったかな。
私の理解では
(pure) C++の仕様には例えばprintfが含まれていないが、C/C++と考えるなら何でも使える。
えっと、C++0xの仕様にはprintf,scanfは含まれるんでしたっけ？

0136133

2011/03/05(土) 12:16:31.99

あとCなら「愚直な書き方をして高速なプログラムになる」という一番大事な性質を忘れてた。
式テンプレートとか、その場では書けない・・・。
Cを別の言語でコード生成するとか、そっち方面の話。

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

2011/03/05(土) 12:18:21.38

C++自体がC含んでるのに何を・・・
あとCとC++の速度はそんなに変わらん

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

2011/03/05(土) 12:19:22.68

向こうでやれよ馬鹿。
http://hibari.2ch.net/test/read.cgi/tech/1207419469/

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

2011/03/05(土) 12:42:09.62

あんたらプロ（笑）なんだから答えられますよね？！w
まで読んだ

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

2011/03/05(土) 12:49:27.12

C++の規格でCに全面的に依存してるのは<cxxx.h>系ヘッダの仕様だけだろ
あとは大体一から機能書いてる（C参照してる所もなくはないけど一部）

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

2011/03/05(土) 12:50:10.22

x <cxxx.h>系
o <cxxx>系と<xxx.h>系

0142133

2011/03/05(土) 12:54:55.47

>140,141
そうだったんですか！

>138
そのスレ知りませんでした。行ってみます。
たいへんお騒がせしました。
ここにはこれ以上書き込みしません。

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

2011/03/05(土) 16:58:36.47

>>141
どうでもいいことだけどそのoxの書き方始めてみた

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

2011/03/05(土) 18:17:01.20

>>140
今時.hかよ。

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

2011/03/05(土) 19:13:54.70

すぐ下を読んでやれよ

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

2011/03/05(土) 19:14:32.13

いやです！

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

2011/03/05(土) 19:41:26.48

iomanip とか本気で使ってる人いるんだろうかねえ
＞ printfの方が便利なのは同意

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

2011/03/05(土) 20:15:17.27

正規表現が標準でついてないのは痛い。
0xの正規表現はエスケープが痛い。

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

2011/03/05(土) 20:28:18.64

\\\\

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

2011/03/05(土) 20:30:19.09

スレ違いの駄文はスルーの方向で。> ALL

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

2011/03/05(土) 21:19:56.39

ADLが嫌われてるわけがよくわかんね
ADL無くてもオペレータオーバーロードを直観的に実装する事ができるの？

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

2011/03/05(土) 21:34:57.93

誰も嫌ってない。
ADLの必要性は誰もが認識している。
ただ現行の大き過ぎる影響を軽減したいだけ

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

2011/03/05(土) 21:59:48.71

Conceptがどっちの案に転ぶかも分からんから、
rangeのためにADLいじって、
将来conceptと整合性取れるのかどうか、全く不透明。
だから禿はADL改変は採用しないだろう。
Name lookupについてはかなり慎重だから。

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

2011/03/05(土) 22:01:38.04

ADLは実装によって解釈が違うことがあるしね…

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

2011/03/05(土) 22:31:30.23

>>153
いや、associated namespace採用直前だけど！

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

2011/03/05(土) 22:39:18.21

オペレータのオーバーロードが問題なら、オペレータだけ特別扱いしてくれればいいのに。
他の名前までADLしなくてもいい

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

2011/03/05(土) 22:50:11.87

ADLの仕様を形式言語で書き下しているのってないの？
g++やCLangのソースを除いて。

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

2011/03/05(土) 23:01:23.40

>>148
そのための Raw String Literal じゃないのか

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

2011/03/05(土) 23:03:13.44

Raw String Literal はこの前無くす提案が出てなかったっけ

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

2011/03/06(日) 00:43:51.02

Raw String Literal ってそんなに実装に手間がかかるの？
単純にエスケープ文字を無視して扱っているって思っているのだけど

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

2011/03/06(日) 01:01:40.16

規格の文言通りにやると一度エスケープ処理した後で差し戻さないといけないからすげえ手間になる
そうでない方法を取ろうとすると今度はコンパイルの手順自体が変わるから大改造になる
実装は極めて難しいよ

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

2011/03/06(日) 01:01:58.63

cppに取っては悪夢でしかない。
(phase 3で逆変換！)

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

2011/03/06(日) 05:35:59.77

>>153
むしろ禿はADLによるフォールバック推進派だったりする。

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

2011/03/06(日) 06:26:28.55

ただでさえ似たような機能が山ほどあるC++なのに、同じ機能ですら実現方法を複数用意するとかどうなのよ……

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

2011/03/06(日) 06:27:13.22

ラムダさんの悪口はやめるんだ

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

2011/03/06(日) 07:03:38.86

なら前置インクリメントは += 1 で代用できるから廃止で

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

2011/03/06(日) 07:14:32.45

演算子オーバーロードがあるからそう単純な話でもない

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

2011/03/06(日) 09:26:55.62

>>161
gccとdmcで既に実装済み

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

2011/03/06(日) 11:18:53.14

raw string を phase 3 で "revert" するって文面は消えたよ。

…と思ったら、Preprosessing token (2.5) に同じことが追記されてるね
でも前よりは投げやりな書き方でなくなったと思う。

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

2011/03/06(日) 15:27:49.99

0xf年に間に合うの？

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

2011/03/06(日) 15:54:20.38

0x10でも別にいいじゃない

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

2011/03/06(日) 18:01:19.94

++をインクリメントと考えて0xfなら16ってことでOK？

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

2011/03/06(日) 18:02:52.15

++ がインクリメントだとして、C の次期規格は来年出る予定だよ
C++ の 2000 年代は長そうだけど

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

2011/03/06(日) 20:58:23.62

Post incrementだから規格出た後で2010年代突入！

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

2011/03/06(日) 21:42:57.99

>>147
boost::formatの出力をユーザ定義するときに使った

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

2011/03/07(月) 07:19:18.51

C++0x10

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

2011/03/08(火) 14:50:04.39

規格が正式にいつ決まるかなんてどうでもいいや。
俺の欲しい機能は大方VCとgccにもう実装されているし。

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

2011/03/10(木) 02:22:22.53

当たり前かも知れんけど、ラムダに親から受けた任意のTを渡すことができるんだな。びっくりした。@VC10EE
あ、よく考えれば無いとこまるのか・・・。

#include <stdio.h>

template<class T,class F>
T Function(const T& Val,const F& Proc){
    return Proc(Val);
}

template<class T>
T Proc(const T Val){
    return Function(Val,[](const T& V){ return V*V;});
}

int main(){

    auto D = Proc(100);

    printf("%lf\n",D);

    return 0;
}

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

2011/03/10(木) 07:05:17.76

親？

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

2011/03/10(木) 09:10:49.62

local lambda expressionの定義されているブロックスコープのinnermost enclosing functionのことを言いたいんだろ。
変な独自用語を作って欲しくはないけどな。

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

2011/03/10(木) 20:01:00.38

あー、独自用語になっちゃったのはすまない。
最近は親とか子とかいわないのか。ふむー。

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

2011/03/10(木) 20:33:55.36

いや最近とかじゃなくて、どんな比喩にしても親子関係なんかないからそれ

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

2011/03/10(木) 20:40:49.20

ネスト構造を木構造に見立てて「親子」ってのは割と普通の言い方だと思うんだが。

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

2011/03/10(木) 20:49:30.88

単なる関数呼び出しをネスト構造って言うかね

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

2011/03/10(木) 20:56:17.19

言うよ
スタックツリーを頭に浮かべれば自然な言い方

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

2011/03/10(木) 22:33:43.62

いや全然

0187parent

2011/03/10(木) 23:30:06.43

私のことで争うのはやめてー！

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

2011/03/10(木) 23:52:15.19

N3242でparentが出てくるのはthreadのとこ1回だけか

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

2011/03/11(金) 03:46:32.36

あー定義が入れ子になってるのを親子って言ってるのか
勘違いした

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

2011/03/21(月) 00:30:47.77

で、右辺値参照はどうなった？

禿げか、何とか委員会かしらんけど

ゴチャゴチャ抜かしているとみんなC++そっぽ向くぞ！

って、もう向いてるか。。。

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

2011/03/21(月) 01:22:48.47

行を空ける奴、キモイ

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

2011/03/21(月) 01:30:06.45

raw stringなんて必要か？
正規表現だろうが、ファイルパスだろうが
普通そんな文字列コードから追い出すだろ。
そんなもん作るぐらいなら、既存のstringメッセージの読み込みを
何とかしてほしい。
みんな、windowsのリソースファイルやらサードパーティー
使っててC++標準使ってんの皆無だぞ。
てか、C++標準のstring/locale回り使ってるやつ皆無じゃね。

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

2011/03/21(月) 01:37:53.14

まあ、入出力と文字列操作は分けるべきだよな。

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

2011/03/21(月) 07:39:30.32

必要な人がいてそれが認められたから入ったんだろ

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

2011/03/21(月) 11:55:28.98

>>192
稚拙な文章で何言っているのかわからん。
うまくm17nする枠組みがほしいってこと

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

2011/03/21(月) 12:03:15.15

>>195
枠が欲しいんじゃなくて、
ユーザーに見捨てられてるライブラリーを何とかしろってこと。

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

2011/03/21(月) 12:30:32.00

localeが使われないのは実装側にも問題があると思うけどな
gccとか全く実装してないじゃん

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

2011/03/21(月) 13:16:34.88

「全く」は言いすぎだろｗ

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

2011/03/21(月) 13:58:46.79

>>197
POSIXはPosixで枠があるしWindowsは自分で枠持ってるし
Unicodeだってマッピングコンセンサス統一されてるわけじゃないし
実装できないのが現状だと思う

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

2011/03/21(月) 14:31:51.68

ググっても、メッセージカタログやら
collate使ってるサンプルコードなんてゼロ。使ってる？
いい加減unicordの具体的仕様に足突っ込みゃいいのに。

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

2011/03/21(月) 14:38:22.91

文字列とI/Oは専用スクリプトかなんか用意しC1xと足並み揃えて言語外へ出しちゃえよ

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

2011/03/21(月) 14:52:40.20

UnicodeってMS/NEC独自解釈で先走り(SJISの独自マッピング)とかが結構あるので
プラットフォームがかわると互換性がひくいんだよね.
べつにC++に限ったことじゃないけど

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

2011/03/21(月) 15:27:03.37

ゼロとか何を根拠に言っているの？
というか調べたことすらないんでしょ。
Unicodeはまた別問題だし。

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

2011/03/21(月) 16:07:41.32

>>203
"collate" "C++" でくぐって見つかる
標準ライブラリーのcollateに関する記事は35件未満。
それ以外はSQLのcollateか英単語としてのcollate。
見つかった35件未満の記事でも、内容は単なるリファレンスとFAQだけ。

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

2011/03/21(月) 16:15:07.56

メッセージカタログは見つかったら省いたわけねw

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

2011/03/21(月) 17:01:37.80

>>205
口だけか、人にいう前にググれよ。
"message" "locale" "C++"
でググった場合3件がリファレンス。
他の結果はまったく関係なし。

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

2011/03/21(月) 17:07:45.93

>>203
マルチバイトに関する仕様が言語に含まれるか含まれないでは全然違うだろ。
最低限1つのunicodeをサポートされてたなら、
openにwchar_tが使えないとか、サロゲートペアがどうのとか
気にする必要がなくなる。

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

2011/03/21(月) 19:38:50.89

> 最低限1つのunicode
意味がわからん?
Unicode て, 何種類もないだろ?

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

2011/03/21(月) 20:01:19.92

localeとか使わないな
まともに実装されてない事もあるし

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

2011/03/22(火) 19:51:52.07

0xって仕様固まるの来年だっけか？
んで、コンパイラが対応して新規格によるプログラミングが主流になるのに
どのくらいの年月がかかると思う？

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

2011/03/22(火) 19:54:24.78

>>210
便利な機能は速い速度で普及するだろう。すでにラムダはいい感じで普及してると思う。
業務で使うことになったらって話なら、OSの転換期とか大きなブレークスルーがないと互換性の問題から逃げられん。

0212210

2011/03/22(火) 19:57:59.36

なるほどね～

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

2011/03/22(火) 20:56:19.33

>>208
文字集合とコードはひとつだった気がするが、
符号化方式は少なくとも3種あり、処理法が全然違う。

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

2011/03/22(火) 21:04:20.81

unicodeは荒れるからそっちのスレでやってくれ

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

2011/03/22(火) 21:06:57.01

>>210
VCが対応したら。
やっぱりWindowsで普通に大多数が
使えるようにならないと。

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

2011/03/22(火) 21:24:17.64

WindowsでVC++ってのも徐々に減ってくんじゃないか？
C#辺りに流れて。C++人口はかなり減ると思う。

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

2011/03/22(火) 21:34:12.25

>>216
受託開発の場合、VC++の案件って既存システムの資産が
捨てられない案件しかないから、案件自体かなり減っている

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

2011/03/23(水) 23:48:41.48

ラムダ式は便利だねー。
っていうか、C++テンプレート完全ガイド読んで思ったけど
ファンクタ使うのマンドクセ。

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

2011/03/24(木) 17:36:47.33

たまに「この場合は関数オブジェクトの方が便利だな」とか思っちゃうのは普通なのか飼い馴らされてるだけなのか……

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

2011/03/24(木) 18:04:31.41

自分は式テンプレートの活躍の場が少なくなるかと思うと寂しくて仕方ないです。

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

2011/03/24(木) 19:51:07.94

規格仕様の確認をさせてください。

1つのファイルの中で、非ローカルの
オブジェクトが複数あった場合、その
コンストラクタの実行順序は、記述された
順とかでなく、不定なんでしたっけ？

複数ファイル間で不定なのは把握
してるんですけど、さすがに1ファイルの
中では仕様が定めてないのでしょうか？

できれば、規格の該当項目とあわせて
教えていただけると助かります。

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

2011/03/24(木) 20:06:32.81

ネームスペーススコープにあるものはコンパイル単位内では定義順だよ
ソースは↓

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

2011/03/24(木) 20:12:34.83

3.6.2 Initialization of non-local variables

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

2011/03/24(木) 21:26:41.54

グローバルネームスペースでは不定と言う事？

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

2011/03/24(木) 22:50:48.70

グローバルネームスペースもネームスペーススコープです
参照　3.3.5 - Namespace scope

0226221

2011/03/25(金) 21:08:59.20

>>222-223
どうもありがとうございます。
規格該当項目も確認できて、納得です。

やっぱりそうですよね。
そうでなければ逆にややこしそうでも
ありますし。

ただ、項目最後のほうの記述は、完全に
把握した自信がありませんが。orz

意味が

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

2011/03/26(土) 01:46:11.23

相互依存する定数を定義できなくなるからね。

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

2011/03/26(土) 02:20:47.32

g++で昔よく分からないバグが発生して、
結果、ヘッダAで定義されるconst定数（小数だったと思う）を使って
ヘッダBで定義されるconst定数を初期化してたのだが、
どうもヘッダAの値が初期化される前に
ヘッダAの値を使ってヘッダBの値が初期化されてる臭かった。
ヘッダなので翻訳単位をまたがるという類いの問題は起こらないと思うんだが、
単なるg++のバグだったんだろうか。
結局不本意ながらマクロにするしかなかった。

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

2011/03/26(土) 02:38:39.04

他の.cppでもインクルードしてたんじゃないの?

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

2011/03/26(土) 02:41:22.75

const定数は内部リンケージだから
そういう話とは関係ないはず

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

2011/03/26(土) 14:07:13.55

Madrid会議でFDIS可決。
http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-march-2011-c-standards-meeting/

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

2011/03/26(土) 16:55:01.10

>>231
そろそろ0xと呼ばなくてよくなりそうだね。

C++11になるかC++12になるかはまだわかんないけど…

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

2011/03/26(土) 18:21:18.02

finalって言ってるけど本当にこれで終わりなの？

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

2011/03/26(土) 18:55:59.34

>>233
文言の修正、追加はこれで終わりだけど、各国の委員会で蹴られる可能性がある

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

2011/03/26(土) 19:35:55.70

じゃあそろそろ反省会をしよう

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

2011/03/26(土) 20:25:46.38

投票とかするんだっけ？
蹴られたらどうなんの？

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

2011/03/27(日) 00:42:10.56

今後、各国支部（National Body）から、FDISに賛成するか反対するかという二択の投票がある。
もはや、NBコメントというのはない。全面的な賛成か反対かだけ。
各国一致で賛成でなければならない。
もし、一国でも反対した場合、規格の全面的な見直しが行われる。
その結果、規格制定が一年以上は、確実に延びる。

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

2011/03/27(日) 01:21:55.32

gdgdっぷりを見てるとすんなり通るとは思えないんだけど

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

2011/03/27(日) 03:28:04.78

そろそろ仕様読み込んでみようと思ったけど、
まだちょっと怖いのかなあ

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

2011/03/27(日) 04:49:25.07

俺的にはregexとラムダ式が入っていれば十分

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

2011/03/27(日) 09:04:35.76

今更反対はないな
文句あるなら最初から言ってるだろうし

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

2011/03/27(日) 11:54:11.47

C++0x が制定されたとして、 JIS 化されるのはいつ頃のことになるのかね？
拙者は英語がわからん人なので日本語の規格文書が必要でござる

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

2011/03/27(日) 14:02:22.70

無理に規格を読まなくても解説書籍は出る

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

2011/03/27(日) 14:04:11.04

本の虫さんの解説書を(出たら)買ってやれよ

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

2011/03/27(日) 14:46:19.37

何気なく JIS 見てたら冒頭に「制定すべきとの申出があり」って文があった。
これを「中出があり」と見間違えてけしからん奴だと思った。
なぁ、正直に言ってくれ。お前らもこの見間違えしただろ!! したよな？な？

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

2011/03/27(日) 15:54:26.58

JIS 見てると Programming languages C++ って書いてあるけど、
なんで languages なの？ language じゃ駄目なの？

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

2011/03/27(日) 20:41:40.63

Programming languages という区分の中の C++ ということではなくて？

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

2011/03/27(日) 22:47:56.48

>>244
サイト名 (ブログ名) で人を呼ぶのって古いスタイルな気がする。
まぁ、どうでもいいことだが。

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

2011/03/28(月) 00:22:42.42

>>248
２ちゃんねらーさんですよね？

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

2011/03/28(月) 00:31:48.97

そこはデフォルト名無しさんだろ

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

2011/03/28(月) 11:33:50.71

ナウなヤングにバカ受けな表現ですね

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

2011/03/28(月) 13:09:12.59

>>237
メンバー各国は賛成・反対・棄権の三択。承認のための条件は、
・全投票中、Pメンバー国の賛成票が2/3以上、
・全投票中、反対票が1/4以下、
この二つ。否決されたらプロジェクト自体が破棄されるので最初の投票からやり直し。
だからFDISまで来たら普通は成立させる。

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

2011/03/28(月) 14:17:15.79

スラドに記事でてたよ。

ttp://slashdot.jp/developers/11/03/28/0159242.shtml
ttp://herbsutter.com/2011/03/25/we-have-fdis-trip-report-march-2011-c-standards-meeting/

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

2011/03/28(月) 16:04:58.77

http://sourceforge.jp/magazine/11/03/28/0518233
http://gcc.gnu.org/gcc-4.6/

ついでに、これのお祝いも。

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

2011/03/28(月) 21:31:39.44

最新のドラフトはN3242でいいのかな？

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

2011/03/29(火) 21:17:01.30

http://zakkas783.tumblr.com/post/4148934727/c-0x-fdis

＞実装、もしくはテストされていない事を理由に、機能の削除を求めた提案は、圧倒的票差を以って否決された。

ユーザー定義リテラルさん「えっ」

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

2011/03/29(火) 21:20:06.35

ユーザ定義リテラル最高！(AA略

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

2011/03/29(火) 21:21:29.27

>>254
>>67 の件はどうなったんだろうね。

http://gcc.gnu.org/gcc-4.6/changes.html
Improved experimental support for the upcoming C++0x ISO C++ standard
(中略), range-based for loops (thanks to Rodrigo Rivas Costa),...

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

2011/03/29(火) 22:29:10.47

ttp://cpplover.blogspot.com/2011/03/c0xfdis.html
その人が書いてるよ

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

2011/03/29(火) 23:15:10.87

今回はなしでも良かったけどな。

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

2011/04/11(月) 12:27:21.01

void c(int && a)
int a;
int b&& =a;
c(a);
の３行目と４行目がエラーになるんですけど
おかしくないですか？
&&はconst以外なんでも束縛するってよんだのですけど。

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

2011/04/11(月) 13:51:31.83

>>261
とりあえず３行目は文法エラーだよね？
実際のコードと使ったコンパイラとエラーメッセージと「よんだ」もののURLを正確に貼るといいよ。

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

2011/04/11(月) 13:54:37.99

void c(int && a)
int a;
int&& b =a;
c(a);
すみません許してください。
初歩的なミスで文法間違えました。
それでも駄目でしたよ。
move(a)にするとできましたよ。
TDMのGCCをつかいましたよ。
コマンドラインにも0xを使うやつをつけましたよ。

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

2011/04/11(月) 14:02:44.29

aは左辺値なんだから当たり前だろ
c(b)なら通るだろうけど

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

2011/04/11(月) 14:04:02.97

bでも無理だわスマソ

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

2011/04/11(月) 14:08:07.41

一応ソースも張っておきますね。
http://d.hatena.ne.jp/ntnek/20090210/p1
＞更新可能な右辺値参照 Type&& は更新可能な左辺値や更新可能な右辺値を束縛する。
＞しかし、const な左辺値や const な右辺値は（const の一貫性に違反するので）束縛しない。

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

2011/04/11(月) 14:29:22.37

>>266
それちょっと古くないか
右辺値参照は右辺値しかとらないようになったよ
ttp://slashdot.jp/~taro-nishino/journal/507551
＞ノート：貴方が、オーバロードvoid foo(X&);を与えないで、void foo(X&&);を実装しているとせよ。
のあたり

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

2011/04/11(月) 14:34:03.29

なんでそこでaを右辺値だと勘違いするのかね

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

2011/04/11(月) 14:42:28.68

>>267
知りませんでした。
ということは完全転送ってやつはどうなったのか調べてみますね。

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

2011/04/11(月) 14:58:16.30

>>267の完全転送は右辺値参照が左辺値もとるやり方で書いてありますね。
一関数で書く書き方はもう無理っぽいですね。

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

2011/04/11(月) 15:41:10.80

完全転送ってテンプレートの話でしょ？

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

2011/04/11(月) 15:44:54.10

テンプレートでやってみて出来なかったから
intで実験しても出来なかったから質問したので
テンプレートで出来ないのはとうぜんでしょ？

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

2011/04/11(月) 15:46:55.14

俺がやったのは
template <typename T>
void c(T&& a, const T& b){}
って関数だけど完全転送と一緒だろ？

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

2011/04/11(月) 17:01:01.95

なんか聞きたいことがよく分かんないな……

>>273
完全か完全でないかはさておき
とりあえず転送しろよｗ

/.の記事は初めて見たけど完全転送に関しては十分に書かれてると思うけどな
とりあえずstd::forward使っていろいろ試してみれば？
std::forwardは関数テンプレート1つで書かれてるよ

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

2011/04/11(月) 18:04:26.40

もしかして完全転送のやつってテンプレートのインスタンス化の仕組みなのか？それなら
273のやつは違うエラーだな。

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

2011/04/11(月) 18:56:43.26

誰が誰だかわからねえ。質問者は名前欄になんかいれとけよ。

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

2011/04/12(火) 10:59:56.01

●テンプレートでは、T&& に左辺値を渡すとT&として扱われる↓
14.8.2.1
3. もしP(テンプレートな仮引数型)が cv被修飾型ならば、
　　Pのトップレベル cv修飾子は無視して型推論を行う。
　もしPが参照型ならば、Pに参照される型を使って型推論を行う。
　もしPが cv修飾なしのテンプレートパラメータへの右辺値参照であって
　　かつ実引数が lvalue ならば、
　　A(推論された型)の代わりに「A への左辺値参照」を使って型推論を行う。

●テンプレートでなければ、T&& にテンポラリを渡せる↓
13.3.3.1.4
3. 暗黙のオブジェクトパラメータ(メンバ関数のパラメータリストに
　暗黙に追加されるthisのこと)以外では、
　　const& 以外の左辺値参照を rvalue に束縛したり、
　　右辺値参照を lvalue に束縛したりするような
　標準変換を行ってはいけない。
　(★訳註: それ以外の変換ならやってもいいということ)

俺様例:
void f(double&& rr){}
void g(int&& rr){}

int main(){
　　int i = 0;
　　f(i); // OK: (double)i は prvalue なので、変換後のテンポラリを束縛できる
　　// g(i); //だめ
}

(8.5.3 第5段落の最後の例も参照)

0278277

2011/04/12(火) 12:52:10.71

>>263 は a も b も lvalue だから (b は名前付き右辺値参照 = lvalue)
c(a) も c(b) も当然エラーになる。

0279質問者

2011/04/12(火) 13:01:49.76

きのう帰ってから実験してみたけどわかったぞ。
template<typename T>
c(T && a){}
template<typename T>
d(T &&a, const T& b){}
int a, b;
c(a);
d(a , b);
上記のソースコードで７行目はエラーで6行目はエラーではなかった。
これはよそうだけど関数の引数のタイプがT&& aのときのみTが＆Tに変わるっぽい
だから７行目は左辺値のTを&&Tにバインドすることに新しく変わった右辺値のみバインドするルールで
駄目らしい。
例えばイテレーターでendは普遍だからconst T&に束縛したくてbegは別の変数にコピーしないで右辺値でも書き換え
たいからT&&に束縛したときどうしたらいいですか？

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

2011/04/12(火) 15:50:49.36

>>279
template<typename T>
void d(T &&a, const typename std::remove_reference<T>::type &b) { }

あとC++の前にその日本語なんとかして

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

2011/04/12(火) 16:24:40.27

Tが直接に型に使われなければTは&Tなるからそれは上手くいくということですよね？
この理解であってますか？
ありがとうございます。

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

2011/04/12(火) 16:31:59.39

template <class T>
void f(T&& begin, T const & end){}

int main()
{
　　int x = 0;
　　// f(x,x); // だめ
　　f<int&>(x, x); // OK
}

完全転送云々ってよりは、deduced context にならないのが問題っぽいね。
(ドラフト中から該当箇所を探せない。誰か教えて)

あと、
　　(int&) && = int&
　　(int&) const& = int&
だから、begin を int& にしたら end も int& になっちゃう。

>>280 みたくしないとダメみたい。

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

2011/04/12(火) 16:32:29.03

>>280
の第二の変数は参照じゃなくてconst T型だからコピーになって駄目ですね。

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

2011/04/12(火) 16:42:21.29

>>282説が正しそうだな。
エラーを見るとint &とint &になってたからな。

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

2011/04/12(火) 16:43:26.67

良く見ると、280には&が付いてるからあってるな。
俺が間違ってたな。

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

2011/04/12(火) 19:06:59.90

お前誰だよ

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

2011/04/12(火) 23:02:12.45

なんでこの板IDないんだ…

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

2011/04/13(水) 17:37:11.34

というか、本来はIDなんて無いのが2chだよ、何せ「匿名掲示板」だからな
投稿者を識別する必要がある板には付いてる、というだけ
ム板は常に投稿者を識別する必要はないだろ？
必要なときに自分のレス番を示せばいいだけだから、つけていない

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

2011/04/13(水) 20:01:34.21

そもそもこのような過疎板では、一人が一日に何度も書き込むことが少ないから、 ID は大した効果がない。
誰の書き込みか分からないと伝わりにくい書き込みは名前欄にレス番を入れるべきだし、そうしないのはコミュニケーションスキルが低いというべきだろう。

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

2011/04/13(水) 20:38:06.34

プログラマー的に考えて、掲示板のほうでID出すことで楽ができるならそうしたいだろう

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

2011/04/13(水) 21:20:13.23

直球でお尋ねする。
IDを出すと楽なのか？

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

2011/04/13(水) 23:19:20.82

んー、楽かどうかは怪しいが、議論がこんがらがったときの助けにはなるなあ。
もっとも、自分が参加してない議論はこんがらがってたら最初から読み飛ばすけど

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

2011/04/14(木) 02:29:11.92

http://www.open-std.org/jtc1/sc22/wg21/
News 2011-04-12: The deadline for the next mailing is 2011-07-22
News 2011-04-13: The 2011-04 post-Madrid mailing is available
News 2011-04-13: The C++ Standard Core Language Issues List (Revision 76) is available

最新ドラフトは N3291 。
変更箇所のマークアップとかを含まない FDIS は N3290 。

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

2011/04/14(木) 12:48:53.76

member name checking組のnewさんとexplicitさんが退学処分になってしまった。
逆に、constexprちゃんは見違えるように優等生になった。

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

2011/04/15(金) 22:06:24.57

ユーザー定義リテラルさんがFDISまで生き残ってしまった…

入れる以上はchronoとかのリテラルも用意すべきだったし
char32_tとかもわざわざ予約語や組み込み型せずにライブラリで済んだはずなのに
整合性がろくに議論されてない感がプンプンする
どうしてこうなった

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

2011/04/15(金) 22:17:36.14

u8, u, Uの特別扱いはそんな悪くない選択だと思いますが。

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

2011/04/15(金) 22:25:20.95

悪くないのかもしれないけど、そもそも比較の議論すらされてないように見えるんだよな
見えない所でしてるのかもしれないけどさ

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

2011/04/15(金) 22:35:58.50

「ソースコードの文字コードが○×だから、
mbcsが○×になっていて、UTF-32にするにはiconvして～」って、
ソースコードの事情を考えないといけないところが、
コンパイル時に全て解決するのだから、すごくいい判断。
operator ""に任せると、ソースコードの事情を実行時まで持ち込むことになる。

Unicodeが普及してない頃は、文字コード中立な設計で、
もろもろ実行時まで持ち込むのは仕方のないことだったけど。

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

2011/04/15(金) 22:59:20.85

operator""だってconstexprにすればコンパイル時判断できるんじゃないの？

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

2011/04/15(金) 23:19:29.83

constexprは、
> 「ソースコードの文字コードが○×だから、
がいやらしいね。
Non-constexprを引数に使われた時は、
実行時に同じ事やらないといけないから、
gccの-finput-encoding=に相当する情報を
実行時まで持ち運ばないといけない。

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

2011/04/16(土) 01:50:04.41

>>300
コンパイル時計算のほうを exec charset でやれば済む話じゃないの？

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

2011/04/16(土) 02:12:21.39

ワイド文字(wchar_t)は文字コードを限定しないので曖昧すぎて使いにくい
煩わしい環境依存が減ってC++標準でunicodeが扱えるようになることは一応良いと思う

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

2011/04/16(土) 12:12:50.20

>>301
exec charsetはiconvの変換先。

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

2011/04/16(土) 12:56:56.94

>>303
だから何？

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

2011/04/16(土) 21:39:52.69

お前らって、どのコンパイラーでC++0xしてんだ？

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

2011/04/16(土) 21:48:54.37

gcc

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

2011/04/16(土) 22:06:24.83

次のVCが出るまでは使わないな。

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

2011/04/17(日) 07:55:29.75

今のVCのC++0xは中途半端すぎて使えない

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

2011/04/17(日) 18:36:09.63

VCだと、ラムダさんとautoさんしかつかってないなー。
スマートポインタ系もたまに使うか？？って感じ。

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

2011/04/18(月) 07:27:15.61

追加されたライブラリの方は結構使うな

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

2011/04/19(火) 13:13:59.91

どんなライブラリーがあるのかどうやってしらべる？
JAVAみたいにSDKマニュアルみたいなのがあればいいのだが
VCにしか無さそうだな。

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

2011/04/19(火) 13:40:48.36

英語読めないのか?

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

2011/04/19(火) 13:55:47.33

読めるけど？なにか？

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

2011/04/19(火) 14:04:03.00

ああ、まさか、ライブラリーをboostライブラリーと勘違いしちゃったのかな
標準ライブラリーの中身の話だよ。
付いていけないなら黙っていてくだちゃいねｗｗｗｗ
バブバブ

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

2011/04/19(火) 14:09:51.51

>>311 http://ja.lmgtfy.com/?q=C%2B%2B+reference

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

2011/04/19(火) 14:12:01.62

つ libstdc++ reference

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

2011/04/19(火) 14:14:03.98

>>311 >>1

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

2011/04/19(火) 14:14:19.08

>>315
ありがとうございました
ほんとうにどういたしまして
しんせつにどうも
ネットでしらべてみます。
ぼくもこれからは
けんさくします

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

2011/04/19(火) 15:20:44.21

何だかなあ

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

2011/04/19(火) 19:19:05.89

震災で、IEみたいに日本では数ヶ月遅れですか？

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

2011/04/19(火) 20:59:58.85

数ヶ月や数年で済めばいい方

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

2011/04/19(火) 21:33:43.95

>>320
JIS規格になるのって意味あるの？
どうせ日本製のフル実装のコンパイラなんて出ないと思うんだけど。

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

2011/04/19(火) 22:18:06.54

意味はないけど新しい用語のセンスない訳には興味ある

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

2011/04/20(水) 00:06:19.01

JIS用語は通じないことが多いよな

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

2011/04/20(水) 08:03:21.23

随伴と返却値くらいじゃね？

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

2011/04/20(水) 18:38:25.05

返り血

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

2011/04/20(水) 20:39:32.83

それに翻訳間違ってることあるしな。

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

2011/04/20(水) 22:34:19.57

勝手に大事な脚注消されてたりするしな

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

2011/04/21(木) 00:03:18.25

翻訳じゃないし、勝手じゃないし

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

2011/04/21(木) 15:01:05.62

objective-c++ で　auto使う方法ないのでしょうか

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

2011/04/21(木) 17:34:11.38

c++0xのコードを普通のc++に変換する方法ないですか

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

2011/04/21(木) 18:25:18.08

どっちも普通のC++だが・・・。
まー、C++0xのコードをBOOSTで置き換えるのが一番労力くわないんじゃね？

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

2011/04/21(木) 20:42:14.05

>>331
具体的にどぞ

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

2011/04/29(金) 11:28:50.51

そのうちC++03からの差分を赤字にしたFDISとかも作られるの？

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

2011/04/29(金) 14:29:56.28

あるだろ

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

2011/04/29(金) 19:47:35.70

あるの？
前のドラフトとの差分ならあるけど

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

2011/05/02(月) 22:11:22.96

ConceptGCCのサイト消滅

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

2011/05/02(月) 23:19:11.02

コンセプトさんとは一体何だったのか…

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

2011/05/03(火) 02:18:58.61

今の規格決まったらまた再燃するでしょ。
ただConceptGCCの中の人は、AppleでCLangやってるし、
ConceptGCC引き継ごうとした人に「最初から実装したほうがいいぜ」って言ってたw

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

2011/05/03(火) 02:20:18.91

外道だな

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

2011/05/03(火) 10:00:59.97

そろそろC++0xスレもオワコンだな
誰かC++2xスレ立てろよ

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

2011/05/03(火) 11:12:23.43

半世紀先かよ

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

2011/05/03(火) 13:30:52.17

0xってまだやってたのかwww
好い加減あきらめればいいのに

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

2011/05/03(火) 15:28:33.82

完成まで1年切ってるのにここであきらめるとかないわ

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

2011/05/03(火) 20:32:04.32

投票は残すところあと1回だけだからね。

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

2011/05/03(火) 20:48:44.74

次は、TR2を通すんだろう。
来年？

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

2011/05/03(火) 21:46:59.23

その辺の予定。

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

2011/05/04(水) 17:04:42.16

結局コンセプトは無し？
コンパイルエラーと戦う日々が続くのか

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

2011/05/04(水) 17:34:24.43

オブジェクトの生成場所をヒープに限定する
private:
~デストラクタ();

オブジェクトの生成場所をスタックに限定する
private:
void *operator new(size_t);
※ただし、オブジェクトがメンバー変数で作成された場合、
　ヒープ上に存在できてしまう。

この辺の小ネタ、0xで綺麗に書けるようになったりしないの？

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

2011/05/04(水) 19:01:44.06

= delete ;

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

2011/05/04(水) 19:03:41.09

スタック／ヒープの話は規格とは関係な･･･って話とは違うか。
しかし生成場所をスタック／ヒープに限定するって話でもないな。

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

2011/05/04(水) 19:15:54.14

動的生成の強制または禁止ということだろうけど
言語仕様でサポートするほどありがたいものには思えん
というか何に使うんだそんなもん

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

2011/05/04(水) 19:20:01.54

というか、newを使えなくしても、
placement newされればどうしようもない。

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

2011/05/04(水) 19:40:38.49

>>352

スマポをnewするようなバカな事を避けるとか、
外部からのdeleteでデストラクタを呼ばせず、破壊用の関数を呼んで
オブジェクトを廃棄させたい場合とか(例外が起こりうる処理は、
デストラクタでなく破壊用関数の中で処理する。)

>>353
確かになぁ。

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

2011/05/04(水) 19:52:34.75

そんな事するバカはこんな局所的な所だけ救っても無駄だろ

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

2011/05/04(水) 20:34:46.88

ドット演算子のオーバーロードはなぜ追加されないのですか？

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

2011/05/04(水) 20:38:34.77

>>356
どうやってオブジェクト本体のメソッド呼び出すんだよ。
あと、ドットの呼び出しで別のオブジェクトのメンバーを呼び出すなら、
最初からその別のオブジェクトを使ったって動作は変わらん。

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

2011/05/04(水) 20:45:26.19

コンストラクタをprivateにしてfriendなファクトリを使って

//ヒープ限定
HOGE * pcreate(){return new HOGE;}
HOGE * p = pcreate();
//スタック限定
HOGE rcreate(){return HOGE();}
const HOGE & ch = rcreate();

そいで0xからは
//スタック限定
HOGE rcreate(){return HOGE();}
HOGE && rh = rcreate();

とかかな。

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

2011/05/04(水) 21:13:11.52

コピーもムーブも封じないとダメだね
でもそうなると標準コンテナ使えなくなるし…
ちょっと利点と欠点が釣り合わないかな

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

2011/05/04(水) 21:32:05.10

>>358
friend使うくらいならstatic関数使った方がよくね。

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

2011/05/04(水) 23:02:53.42

>>349
> オブジェクトの生成場所をヒープに限定する
> private:
> ~デストラクタ();

これ delete できなくならない？ cl が間違ってるの？

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

2011/05/04(水) 23:24:49.33

>>361

外からは破壊できないよ。
実際はこういう使い方。

public:
void Destroy()
{
//例外が起こり得る後始末
　delete this;//内部からなら破壊できる。
}
private:
~デストラクタ()
{
//例外の起こらない後始末
}

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

2011/05/04(水) 23:33:55.43

もしくは、friend宣言したクラスや関数からしか使えないクラスとかかな。
あんまり現実的なテクニックじゃないけど。

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

2011/05/04(水) 23:44:13.96

結局こういうのは汎用性のない小細工になるわな
考えるだけ無駄無駄

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

2011/05/05(木) 00:08:38.29

無駄無駄無駄ァァァーッ！！

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

2011/05/05(木) 01:01:25.08

なーる、内部でdeleteすればいいのか

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

2011/05/05(木) 01:21:16.41

外部で直接deleteさせない事が目的の一つだからね。
「デストラクタの中から例外は送出してはいけない」(デストラクタ内で例外処理するのはアリ)
これを実現するための一つの手段。
他の人はどうやってんのか知らんけど。

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

2011/05/05(木) 10:57:31.39

デストラクタで例外ってどんな作業してんだ？

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

2011/05/05(木) 11:02:57.32

C++0xの次の企画でいいから
参照カウント型の張替え可能参照を組み込んで

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

2011/05/05(木) 12:51:53.40

>>368
close関数がエラー返すとか

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

2011/05/05(木) 13:03:33.44

無理してデストラクタで開放しなくてもいいんじゃないのさ

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

2011/05/05(木) 13:49:52.86

その工夫が>>362なんじゃないの

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

2011/05/05(木) 13:52:01.60

RAIIだとデストラクタでリソース開放することが多くなるよね

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

2011/05/05(木) 14:29:43.97

>>372
工夫してって、デストラクタやdeleteを封印とか余計に無理してるじゃん
デストラクタやdeleteを封印するのはデメリットのほうが大きいよ

>>373
オブジェクトとリソースの寿命が必ずしも一致しないといけないなんてことはない
RAIIにこだわらなくてもリソースの開放漏れを防ぐ方法はいくらでもある

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

2011/05/05(木) 14:42:12.13

代替案は？

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

2011/05/05(木) 15:14:04.25

>>375 とりあえず std::fstream::close() があるな。

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

2011/05/05(木) 15:34:31.11

あるけど、デストラクタで閉じられるから大抵のヤツは無視するだろ。

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

2011/05/05(木) 15:41:32.32

どうりでC++はウンコプログラムが多いわけだ

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

2011/05/05(木) 15:45:25.06

>>377 これはひどい。

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

2011/05/05(木) 15:48:50.42

>>378
C で fclose() を忘れずに呼んで忘れずに戻り値チェックするのに比べればちょっとはマシ。

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

2011/05/05(木) 15:52:17.59

>>380
忘れずに閉じてエラーチェックまでしてるプログラムより>>377の何がマシなの？

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

2011/05/05(木) 15:59:29.04

>>381
え？プログラムと人を比べるの？何の話してるの？

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

2011/05/05(木) 16:03:41.80

>>382
なんで質問に質問で返すの？

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

2011/05/05(木) 16:14:44.92

http://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E8%B3%AA%E5%95%8F%E3%81%AE%E8%AA%A4%E8%AC%AC

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

2011/05/05(木) 16:17:24.81

デストラクタ内のエラーはシステムを信じて握りつぶす。通はこれだね

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

2011/05/05(木) 16:22:02.98

容量オーバーでエラーが返ってきたなら、無駄なファイルを削除する事で救えたデータもあっただろうに。
ネット越しなら再接続して送信を試みる事もできたろうに、ああかわひそふなことほした。

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

2011/05/05(木) 16:38:22.31

結局のところ処理内容によるんだよね
やるべき事は文法的にデストラクタを縛ることじゃなくて
処理内容に合わせたエラーハンドラの設定だよ

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

2011/05/05(木) 16:47:55.31

結局コンストラクターでクローズ時のハンドラ設定出きるようにしとくのが現実的か。

>>376 それって例外なり戻り値でエラー反したっけ？

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

2011/05/05(木) 16:52:52.89

つうか、closeでエラーが帰ってきたとしても特に何もする事はない。
close以前に問題がある事が普通だからな。
エラーメッセージとかログを残す事は必須だな。

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

2011/05/05(木) 16:55:55.26

デストラクタで処理できないエラーは
無視できることにしたいんですね、わかります

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

2011/05/05(木) 17:07:55.37

>>388
exceptions(failbit) 設定しとけば close() 失敗で例外が飛ぶ。
デフォルトのまま例外使わないなら、 close() のあと fail() や
good() や operator void* () で見ればいい。

>>389
書き込んだつもりのデータがバッファに溜まってただけで
書き込めてないことがあるんだよ。危ないよ。

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

2011/05/05(木) 17:15:42.80

>>389
ログ書き出しのcloseでバッファにメッセージが残ったままエラーが起きたらどうするんだろう・・・。

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

2011/05/05(木) 17:20:15.65

デストラクタでの処理は保険で
失敗する可能性がある奴は明示的に処理すればいいじゃない

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

2011/05/05(木) 17:24:01.35

というわけで 376 に戻るわけだ。

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

2011/05/05(木) 18:39:35.10

そんな半端な保険ならないほうがいい
デストラクタ呼ばれるまでに明示的に閉じてなければアサートを出すべき
起こりうるけど確率の低いバグしかもファイル処理でとか最悪のパターンだわ

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

2011/05/05(木) 18:50:28.14

　動画書き出しててディスクの容量足りないとかザラにある訳だけどな。
パーティションが一つとは限らんから別のパーティション利用したり何らかの対処している編集ソフト結構ある。

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

2011/05/05(木) 18:53:31.82

何スレだよ

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

2011/05/05(木) 18:56:55.44

C++0xでもエラー処理は楽にならない、というスレ

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

2011/05/05(木) 19:46:27.28

どっかのまとめサイトでも居たがデストラクタで云々言う奴はなんでclose時にしかエラー捕捉しないのか

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

2011/05/05(木) 19:56:24.02

バッファの書き込みはリソース解放ではないので、RAIIで処理する事は望ましくない。

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

2011/05/05(木) 19:57:52.46

>>399
少なくともこのスレじゃ誰もそんなこと言ってなくね？
勝手に相手をアホ認定すんなよ

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

2011/05/05(木) 19:59:48.73

誰もアホとか言ってないのになに切れてんだか

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

2011/05/05(木) 20:26:17.79

エラーも満足に補足できないプログラマは総じてアホだ

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

2011/05/05(木) 20:34:32.84

プログラマなんて道を選んだプログラマは総じてアホだ

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

2011/05/05(木) 20:34:34.68

エラーハンドリングが必要なら、先に明示的にバッファをflushしてからcloseするようにすればいいだけじゃん。
flushが成功したのにcloseが失敗したら、もうそれはアプリケーション側では回復不可能なエラーとして握りつぶしていいんじゃない？

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

2011/05/05(木) 20:40:46.49

わざわざデストラクタで閉じる前に flush() するくらいなら
そこで close() しちゃえば良いのに

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

2011/05/05(木) 21:07:08.42

>>406
いや、普通は
write()*n + flush()
が一つのトランザクションであり、
open() + トランザクション*m + close()
までがライフサイクルだろ？
だから、flush()とclose()は別にするべきだろう。

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

2011/05/05(木) 21:12:32.26

0xの話題がなくなるといつもこの話題が盛り上がるね

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

2011/05/05(木) 21:14:12.18

で右辺値参照は？

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

2011/05/05(木) 21:20:53.65

退学騒動がひと段落した後
変化があったとは聞かないけど

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

2011/05/05(木) 21:24:15.91

デストラクタでごにょごにょの件は
Effective C++に書いてなかったっけ
今手元にないから記憶が曖昧だけど

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

2011/05/05(木) 21:27:26.42

ここはアプリケーションの不具合の責任を言語に押し付けるスレですか？

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

2011/05/05(木) 21:31:26.33

　デストラクタの前に、エラーチェックをしないとコンパイルエラーにできる構文があってもよかったかもしれん。

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

2011/05/05(木) 22:47:48.64

>>413
explicit デストラクタさんか…。
スコープの最後に明示的に呼び出さなければエラー、とか。

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

2011/05/05(木) 22:56:18.27

動的に確保した時厳しそうだな

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

2011/05/05(木) 23:29:28.43

>>415
delete直前のポインタにかかるようになってたら可能かも。
ただ継承関係を考えたら面倒くさそうだ。

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

2011/05/06(金) 13:55:53.12

gccで
char16_t *c=u"あいうえお";
みたいにやっても出来ないんですけど。
どうやったら出来るんですか？
英数字なら出来るけど良く分かりません。

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

2011/05/06(金) 14:02:56.58

>>417
期待した結果と実際の結果を、違いがわかるように書きなさい。

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

2011/05/06(金) 14:04:16.70

ソースの文字コードは

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

2011/05/06(金) 14:05:46.50

何も設定変えないでエクリプスでやったやつだけど

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

2011/05/06(金) 14:14:19.96

uはユニコードにエンコードしてくれるしるしだから
文字コードは関係ないでしょう。

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

2011/05/06(金) 14:34:30.20

gccを新しくした場合、gccの認識する日本語文字コードが変わってる場合も

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

2011/05/06(金) 14:40:49.10

よくわからないのでとりあえず一発で解決する文字コードの直し方教えてください。

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

2011/05/06(金) 14:43:53.52

ASCIIのみ。これ鉄板。

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

2011/05/06(金) 15:11:31.17

とりあえず確認したコードを全部載せろや

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

2011/05/06(金) 15:16:50.06

これがガチ
char16_t * c = u"\x42\x30...

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

2011/05/06(金) 15:27:07.10

u だと４桁になるんじゃない？

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

2011/05/06(金) 15:46:11.61

> u だと４桁になるんじゃない？
ああそうだった。それと文字列リテラルはconstで受けるべきだからこうか
const char16_t * c = u"\x3042...

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

2011/05/06(金) 16:07:12.74

C++0xでconstなしじゃポインタでリテラル受けれなくなったっけ？

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

2011/05/06(金) 16:09:42.54

その暗号みたいな数字しかuをつかって0xは受け付けてくれないのか？

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

2011/05/06(金) 16:20:37.17

>>429
配列からポインタへの暗黙変換のルールの中でconst外しの例外がバッサリ削除

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

2011/05/06(金) 17:02:01.78

>>431
いい事だな

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

2011/05/06(金) 17:34:35.48

コンパイルするときは
2.2 第1段階
　　ソースファイルのキャラクターセットをユニコードに変換する。
　　(ただしASCII以外のはすべて \uXXXX の形にエスケープする)

2.2 第5段階
　　全ての文字リテラル・文字列リテラルを execution character set に変換する。
　　エスケープされてるやつも全部文字に置き換える。
　　(もし変換できない文字なら井桁みたいなのに置き換える)

2.2 第7段階
　　全ての字句が構文的・意味的に解釈される

という段階を踏むんだけど >>417 は第一段階で失敗してるんだろう。

俺、前も同じこと書き込んだけど、ドラフトを読む限り、
　　u'あ';
は、第5段階で一度 execution character set になった後、
もう一度第7段階でユニコードに変換されるっていうステップを踏む気がするんだよね。

だから
　　u'☃'
は第五段階で u'(井桁)' になった後、もう一度第7段階でユニコードに変換されて
ユニコードの井桁記号(本当はimplementation definedだけど)が出てくると思う。

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

2011/05/06(金) 17:56:52.59

>>430
ソースファイルの文字コードが問われない形にできるから、
>>433のいう理由、しかも一番起こりやすい、では失敗しないってことでしょ。

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

2011/05/06(金) 20:13:30.33

gccに食わせるソースファイルのエンコードはUTF-8にしておけ。

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

2011/05/06(金) 20:17:11.45

>>434
EBCDICだとまずいがな

0437433

2011/05/06(金) 20:25:05.92

すまん。単語を間違えてる。井桁は # じゃねえか。
= の太字ってなんていうんだっけ…

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

2011/05/06(金) 20:37:34.83

〓下駄

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

2011/05/06(金) 21:02:13.88

>>435
iconvがリンクされてないgccバイナリはだめだけどな

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

2011/05/10(火) 07:26:01.19

普通に使われてるSJISの文字は変換されないということか？
uで変換できるのは#/4343のような暗号の様な文字列をユニコードに変換する印ということか。
それならSJISの文字を暗号の様な文字列に変換するようなマクロがあれば良いな。
誰かつくってくれないかなぁ。

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

2011/05/10(火) 07:36:37.19

basic source character set以外の文字をソースファイルに使えるかどうかは実装依存。

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

2011/05/10(火) 09:52:51.73

出力を表示するところもSJISでないとだめだから
出力するときもユニコードからSJISに変換しなければいけないな。

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

2011/05/10(火) 10:08:37.91

Shift_JISはmbcsとして扱うのも大変だしね。
日本人以外の処理系開発者からしてみれば、
なんでこんな阿呆なcoding system使ってるのかと思うだろうね。

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

2011/05/10(火) 10:22:18.65

まだ続いてたのか。

>>440
uとかの文字列リテラルの前置は変換を指示なんかしない。
uはそれに続く文字列リテラルのバイト列をUTF-16の文字コードとみなしてくれとコンパイラに要請するだけで
それが実際にUTF-16の文字コードであるかはコンパイラにソースを渡すものが保障する必要がある。

reinterpret_castでポインタを無理やりキャストした場合の動作に近いイメージ。
double型の値へのポインタをreinterpret_cast<int*>でint型へのポインタに変換してint型の値として参照しても
期待したようなint型の値に変換されるわけではないのと同じ。

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

2011/05/10(火) 10:30:41.63

>>444
規格上の定義と実装上の都合をごっちゃにするなアホ。

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

2011/05/10(火) 10:55:11.14

最低でもascii<-->unicodeやunicode間の変換くらいはできるはずだがな(でないと意味がない)

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

2011/05/10(火) 11:05:57.07

>>426-428からして、
u"\u～"じゃなくて、u"\x～"だしなあ。
ちょっとスレの焦点が定まってないね。

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

2011/05/10(火) 12:22:03.89

struct hoge : typedef long_type_name t: public fuga< t, aloc<t>>{};

こういうこと出来るようなればc++もっと流行るのに

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

2011/05/10(火) 12:23:28.17

長くなったけど結論としては、
エクリプスでエディターの文字コードをユニコードにして
出力の文字コードもユニコードにして、
ＧＣＣに入力されるソースコードがユニコードであると指定すれば良いわけだな。
しかし、将来的にはS-JISコードがuによってユニコードに変換できるようになる
んだろうか？かりにそうならそうなるまで待つけど、そうじゃないならこうするしかないな。

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

2011/05/10(火) 12:27:43.36

>>444
> uはそれに続く文字列リテラルのバイト列をUTF-16の文字コードとみなしてくれとコンパイラに要請するだけで
> それが実際にUTF-16の文字コードであるかはコンパイラにソースを渡すものが保障する必要がある。
いや、それは誤解だ。

たとえばソースがSJIS だとするなら、翻訳段階 1で
　"あ" (22 82 a0 22) -> "\u3042"
　u"あ" (75 22 82 a0 22) -> u"\u3042"
と変換される。(たとえ u がつかなくてもユニコードの番号に変換される)

次に、たとえば実行形式のキャラクターセットが SJIS だとするなら、
翻訳段階5 で、文字列リテラルの中身が SJIS になる。
　"\u3042" -> "82 a0"
　u"\u3042" -> u"82 a0"
(u がついていても SJIS になる)

次に、翻訳段階7 で、このリテラルを意味的に解釈するに及んで、
u がついてるのは UTF-16 に変換される。
　"82 a0" -> バイト列 82 a0
　u"82 a0" -> バイト列 42 30

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

2011/05/10(火) 12:35:44.60

Unicodeスレでやってくれ
荒れるから

0452450

2011/05/10(火) 12:42:26.09

だから実行形式が純粋な ASCII の環境では、
u'\uXYZW' は一般に 0xXYZW と等しくない。
等しくなるのは 0xXYZW が 127 以下のときのみ。

俺はこの事実を信じたくないから
誰か根拠を添えて反論してほしい。

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

2011/05/10(火) 12:44:03.72

いや>>450はC++0xの規格の話だろ。
もともとCのTRだったから、Cのスレというのならまだ分かるが。

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

2011/05/10(火) 12:45:04.46

>>452
それ以外にどうしろと…

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

2011/05/10(火) 17:49:06.11

>>452
なにがだからかわからんが\uと\xは別物なんだから
等しくなるのは当然限定された条件下だけだろ
(純粋ASCII環境の意味とそこに限定する意味もわからんが)

(ソース表記 > 最終的な内部でのバイト表現)
"\u3042" > 82 a0 (実装依存実行キャラ:sjis)
"\x3042" > 42 30 (実装依存バイトオーダーLE 範囲外:mingw-gccの場合)
u8"\u3042" > e3 81 82
u8"\x3042" > 42 (実装依存範囲外:mingw-gccの場合)
u"\u3042" > 42 30 (実装依存バイトオーダーLE)
u"\x3042" > 42 30 (実装依存バイトオーダーLE)
U"\u3042" > 42 30 00 00 (実装依存バイトオーダーLE)
U"\x3042" > 42 30 00 00 (実装依存バイトオーダーLE)

0456450

2011/05/10(火) 19:22:00.80

>>455
\u と \x が別なのはいいよ。それは当然だよ。

だけど u'\u1234' != 0x1234 は気持ち悪くないか？

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

2011/05/10(火) 19:27:32.04

主観で語られましても

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

2011/05/10(火) 20:33:05.09

>>456
なんで気持ち悪い？
そもそも文字の内部表現を仮定して数値と比較するのは '0' == 0x30　でさえ真になるかは環境依存。
(今更非ascii系を考えてどうなるってのは置いとけ)
文字の内部表現が具体的にどういう数値になるかを仮定するのは危険ってのが
ユニコード文字にも変わらず適用されてるだけと思えばなにも気持ち悪いことはないだろ。
(そもそもそれからして気持ち悪かったというのなら、まあ･･･)

0459450

2011/05/10(火) 21:58:44.65

>>458
実行キャラセットが 7bit ASCII の環境で、
ファイルに utf-8 で「こんにちは」と書きだしたいとき
　std::fwrite(u8"\u3053\u3093\u306b\u3061\u306f", 1, 15, stream);
と書いても正しく出力されないんだぜ？

あるいは utf-8　のファイルから読み込んで strcmp しても一致しない。

結局処理系依存になるなら、何のためにユニコードを規格に取り込んだんだかわかりゃしない。

それに '0' == 0x30 は環境依存だけど
'\x30' == 0x30 が環境依存だなんて思ったことないよ
(char のビット幅が 5bit しかない、みたいなときを除けばだけど)

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

2011/05/10(火) 22:12:27.39

そもそも「実行キャラセットが 7bit ASCII の環境」なんてものがあるかどうか。

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

2011/05/10(火) 22:18:47.37

>>459
実行キャラセットが 7bit ASCII の環境で非ASCII文字が出力できるのか？
環境が融通を利かせて表示してくれるとしても各データが7bitまでで表現されてるバイト列を文字列として渡さなければならないだろ。
各データが8bitまでフルに使うUTF-8でエンコードした文字列を渡して正しく表示されるほうが驚きだ。
(8bitのデータを受け入れ可能なら7bit環境じゃないだろ)

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

2011/05/10(火) 22:24:08.80

charが最低8ビットって保証されてなかったっけ？
7bit環境ではそもそもC言語が使えないとかの話になるとおもう

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

2011/05/10(火) 22:28:23.30

>>462
charが1バイトで、sizeof(char)が返すのは1だという事は保証されている。
ただし、1バイトが何bitかは規定していない。一般的な用語で言えばchar型が
4byteな環境でも、C言語の規格で言えば単に1バイトが32bitな環境になる。

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

2011/05/10(火) 22:29:20.48

>>462
が、 signed char が -127 から +127 の範囲を表現できることは規定されてるな。
だから、実質的に最低8bitというのは課程できるだろうな。

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

2011/05/10(火) 22:30:17.38

>>460,461
7bit ASCII　という例が悪かったよ。日本語が全く使えない環境、という意味でしかなかった。

たとえ 8bit環境でも、実行キャラセットがひらがなを含んでいないLatin-1ならば、
u8"\u3053\u3093\u306b\u3061\u306f" は utf-8 の「こんにちは」とバイナリ表現が一致しない。

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

2011/05/10(火) 22:48:10.05

Unicodeを(実行時キャラクターセットを無視した)バイナリとして吐き出そうとしても
規格上リテラルが一旦実行時キャラクターセットを経由した変換がされてしまうので
化けてしまう、という危惧はよくわかるが

実際問題>>433みたいな変換を馬鹿正直に実装してるコンパイラなんて無いと思うので
気にしなくてもいいような

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

2011/05/10(火) 23:20:37.44

よくわかんないけど文字コードって怖いですね
ヨーロッパ人はもっと怖いんだろうな

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

2011/05/10(火) 23:51:45.39

>>465
mingw-gcc4.5.2でfexec-charset=Latin-1で試そうとしたら
実行以前にiconvがUTF-8からlatin-1への変換をサポートしてないとコンパイルエラーにされたでござる

0469468

2011/05/11(水) 00:49:16.51

iconvだとlatin1指定でござったorz
しかしmingw-gccでは内部でのバイナリ表現のずれはみられなかったでござるよ(環境によるでありましょうが)
テキストとしてファイル入出力を行ったゆえになにかしら無用な変換が入ったのでござらんか？
// fexec-charset=latin1
int main(){
const char cc[] = u8"\u3053\u3093\u306b\u3061\u306f ";
for (int i=0;i<15;++i){
int c = (reinterpret_cast<const unsigned char *>(cc))[i];
std::cout << c << ",";
}
return 0;
}

0470450

2011/05/11(水) 06:39:56.45

>>469
うん。実行キャラセットにない文字の処遇は処理系依存で、どう扱ってもいいので
gcc が latin1 でも utf8 をうまく扱ってるのは理解できるんだよ。

(実行キャラセットの最終的なエンコーディングは latin1 でも、
文字集合自体は unicode を包含していても構わないわけだし)

問題はそのGCCの挙動がISO準拠を謳うコンパイラに共通なのかどうかで。

n3290の俺の読み方が間違ってて本当は大丈夫なんだ、という指摘がほしかったんだけど
GCCでやってるぶんには大丈夫ってことでまあいいや。㌧

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

2011/05/11(水) 11:18:55.35

ユニコードのコードポイントと１６進数が恒等置換ではないとっていうなら
コードポイントと１６進数の対応は全単射なら何でも良いって分けか？

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

2011/05/11(水) 16:18:22.19

>>471
規格上はあるユニコード文字一文字を表現しているchar16_t,char32_t型の値はその文字のコードポイントの値と等しくなるとなっている。

それとは別にソースにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
実行キャラセットへの(不要な)変換およびユニコードへの再変換を経て実行段階ではAと異なる文字A'になるかもしれないのか？って話。

それで、もしそうならやだなあとか、
もしそうなら文字Aのコードポイントの値を直接使ったプログラムは意図したとおりに動かないことがあるなあ、って話。

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

2011/05/11(水) 17:06:04.40

それとは別にソースのユニコード指定した文字／文字列リテラルにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
だな。

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

2011/05/12(木) 03:41:36.98

>>450の解釈はどうも違うようだ。
間違ってると思うのは二点。
1 翻訳段階5で全ての文字列リテラルが単一の実行文字集合を使って変換されるとしたこと
2 翻訳段階7で再変換が行われることがあるとしたこと

翻訳段階5では複数の実行文字集合の中から文脈に応じて適切な文字集合が選ばれて変換に使われる。
根拠になりそうなのは以下

2.14.3
> The value of a wide-character literal containing a single c-char has value equal
> to the numerical value of the encoding of the c-char in the execution wide-character set, unless the c-char
> has no representation in the execution wide-character set, in which case the value is implementation-defined.
ただのexecution character setと異なるexecution wide-character setが存在することが示されている。

2.14.3
> A universal-character-name is translated to the encoding, in the appropriate execution character set, of the
> character named.
(文脈に応じた)適切なexecution character setの中の文字に変換されると読める。

翻訳段階7での再変換は翻訳段階5の誤った解釈により生じた問題を解決するための解釈のようだから
翻訳段階5の解釈が変われば不用。

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

2011/05/12(木) 03:43:08.68

上記の解釈に基づく挙動
例としてソース文字集合SJIS、実行文字集合SJISを指定、リトルエンディアン環境。

翻訳段階 1
基本ソース文字集合にない文字はユニバーサルキャラクターネームに置換される。

　"あ" (82 a0) -> "\u3042"
　L"あ" (82 a0) -> L"\u3042"
　u8"あ" (82 a0) -> u8"\u3042"
　u"あ" (82 a0) -> u"\u3042"
　U"あ" (82 a0) -> U"\u3042"

翻訳段階 5
リテラル中のエスケープシークエンスやユニバーサルキャラクターネームは
文脈に応じた実行文字集合内の該当する文字(を示すバイト列)に変換される。

　"\u3042" -> 82 a0 (実行文字集合に指定したSJIS文字集合内の文字に変換)
　L"\u3042" -> 42 30 (環境依存の文字集合内の文字に変換。ここではUTF-16とした)
　u8"\u3042" -> e3 81 82 (接頭辞u8という文脈からUTF-8文字集合内の文字に変換)
　u"\u3042" -> 42 30 (接頭辞uという文脈からUTF-16文字集合内の文字に変換)
　U"\u3042" -> 42 30 00 00 (接頭辞Uという文脈からUTF-32文字集合内の文字に変換)

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

2011/05/12(木) 14:48:19.80

SJISは変換されないんじゃ？

0477450

2011/05/13(金) 00:12:17.02

>>474
execution character set と execution wide-character set は↓で定義されているから
2.3-3
> The execution character set and the execution wide-character set
> are implementation-defined supersets of the basic execution character set
> and the basic execution wide-character set, respectively.

↓の "appropriate execution character set" は
narrow か wide かのどちらかだと思いこんでいたんだけど
2.14.3-5
> A universal-character-name is translated to the encoding,
> in the appropriate execution character set, of the character named.

確かに考えてみれば、UTF-32 や UTF-16 は
wide-character string でも narrow-character string でもないから
UTF-32/16に対して execution (wide-)character set は
どちらも "appropriate" とは言えないね。

ここでユニコード文字列にはユニコード自身が execution character set だと考えれば
万事上手に収まる、と。

なるほど…。そんな気がしてきた。

でもそれなら
the appropriate "execution" character set と限定するんじゃなくて
the appropriate character set って程度の表現にしないと誤解招くよなあ。

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

2011/05/13(金) 09:33:52.37

過去のメーリングをたどってみたら
　n2018 New Character Typers in C++
にてユニコード文字列が提案されてた。

universal character nameが導入されたのはもっと前。
文字列が narrow か wide の二種類しかない状態のときに
現在の翻訳段階 5 の文や 2.14.3-5 の文が書かれた。

そして n2018 でユニコード文字列を提案するときに、
翻訳段階 5 と 2.14.3-5 の修正を提案し忘れている。

具体的に Working Draft に組み込まれたのは n2284。
ここで n2018の通り加筆されたのが見て取れるけど、
"execution character set" に変換するという記述が
修正されることは、ついになかった。

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

2011/05/13(金) 09:58:36.28

"execution"あるとなんかまずい?

> in the appropriate execution character set

これはユニコード系とは限らないよね。

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

2011/05/13(金) 12:04:29.64

2.14.5-13
> [ Note: This concatenation is an interpretation, not a conversion.
> Because the interpretation happens in translation phase 6 (after
> each character from a literal has been translated into a value from
> the appropriate character set), a string literal’s initial rawness
> has no effect on the interpretation or well-formedness of the
> concatenation. --end note ]

↑翻訳段階 6 で結合が起きる前には、
各文字はすでにそれぞれ適切な文字集合のコード値に変換されている、
と注釈されてる。(ここには "execution" という単語はでてこない)

だから phase 5 はやはり
　"" は実行文字集合
　L"" はワイド実行文字集合、
　u8"", u"", U"" はユニコード
へそれぞれ適切に変換する、という意味で言いたいんだろう。

しかし conversion でなくて interpretation だ、というのは
どういう意味なんだろう。

>>479
execution (wide-)character set についての説明が
narrow/wide の二種類しかないような書き方だからまずいよ。

ないような、というか二種類しかなかったんだよ。書かれた当時は。

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

2011/05/13(金) 13:59:30.10

本筋の流れとは違うが説明しておくと

>>480
> しかし conversion でなくて interpretation だ、というのは
> どういう意味なんだろう。

これはそれまで『連続する複数の文字列リテラル』とみなしていたものを
これ以降は『(それらが連結された)ただ一つの文字列リテラル』とみなすことにする、という解釈の変更を行うだけで、
各文字列リテラルのバイト列はなにも変換されないといっている。

なぜこの注記が必要かというと例をあげる。

(実行文字集合はsjisとする。)
ソース: u"あ" "あ"
翻訳段階1: u"\u3042" "\u3042"
翻訳段階5: u"42 30" "82 a0" (厳密には 75(u) 22(") 42 30 22(") 20( ) 22(") 82 a0 22(") というバイト列)

翻訳段階6: u"42 30 82 a0" (とみなすことにする)

後ろの文字列リテラルのバイト列 82 a0 はユニコード文字を示すものとみなすには本質的に不適切な値だが
翻訳段階6では何も変換されずにただ連結される。

ソースの書き手としては u"ああ" と書いた場合と等しい結果を期待するかもしれないが
そうはならないので注意をうながしている。

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

2011/05/13(金) 14:13:06.54

>>480
> 　u8"", u"", U"" はユニコード
> へそれぞれ適切に変換する、という意味で言いたいんだろう。

この変換は必須ではないから解釈という言葉が出ているのでは?

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

2011/05/13(金) 17:19:26.52

>>481
// g++ (4.6.0) -fexec-charset=sjis -std=c++0x
#include <cstdio>
int main()
{
　　std::puts(u8"うにこーど" "えすじず");
};

↑utf8の端末できちんと表示されるんだが…。
もちろん u8 を消すと、文字化けして表示される。

>>481の通りだとすると"えすじず"は文字化けしないとおかしい。
(これは文字集合の変換・逆変換で非可換かもという問題とは別)

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

2011/05/13(金) 17:20:46.43

>>483
すまん
×非可換
○非可逆

0485481

2011/05/13(金) 19:45:40.96

>>483
ならどこかの処理に関する規格の解釈が違う。

翻訳段階6での処理に関する>>481の解釈が違う可能性もあるが
翻訳段階5での処理の解釈が違う可能性-

翻訳段階5の変換では翻訳段階6での結合を考慮したうえで変換すべき実行文字集合を決める。
>>481の例だと後ろの文字列リテラルが翻訳段階6の結合でchar16_t文字列リテラル(の一部)になることをみこして
UTF-16文字集合に変換する。
翻訳段階5: u"42 30" "42 30"

-もある。

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

2011/05/13(金) 20:25:20.35

C++0xのスレかと思ったら違うスレに迷い込んだようだ

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

2011/05/13(金) 20:43:15.18

間違ってはないよね

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

2011/05/14(土) 10:16:54.67

C の n1539 を読むと

6.4.5-6
> phase 7 でケツに 0 を付加して、
> ・"" はマルチバイト文字列そのまま、
> ・L"" はマルチバイト文字列を mbstowcs で変換したもの、
> ・u8"" はマルチバイト文字列を UTF8 に変換したもの、
> ・u"" はマルチバイト文字列を mbrtoc16 で変換したもの
> ・U"" はマルチバイト文字列を mbrtoc32 で変換したもの
> で、それぞれ初期化する。
>
> 実行文字集合にないマルチバイト文字が
> 文字列リテラル中でどういう値になるかは実装依存。

と書いてあった。

C++ がこれと同じことをするなら、結局いろいろ意見はあったけど
>>450 は正しいということだな。

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

2011/05/14(土) 12:26:40.94

なるほど。ということは結局
> それとは別にソースのユニコード指定した文字／文字列リテラルにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
> 実行キャラセットへの(不要な)変換およびユニコードへの再変換を経て実行段階ではAと異なる文字A'になるかもしれないのか？って話。
もありえるということになるのか？

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

2011/05/14(土) 16:25:33.57

処理系による。

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

2011/05/14(土) 18:25:02.99

状況不明は変わってないような気がするぞ。

規格に明確な文面はないが整合性の点で execution character set と execution wide-character set に加えて
execution unicode-character set が存在して翻訳段階5でユニコード文字列リテラルの変換に使われると解釈すべきでは
接頭辞なしのリテラル <-> execution character set
L"" ワイド文字リテラル <-> execution wide-character set
u8"" u"" U"" ユニコード文字リテラル <-> execution unicode-character set

という論点がでてきてるのだが。

それと混同して話を進めてる場合があるが文字集合と文字集合内の各文字の表現方法(エンコード方式)は別物だな。
>>475の翻訳段階5とかはその意味では明らかに間違い。

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

2011/05/14(土) 19:37:00.46

480だけど、
>>480で引いた注釈は、RAW文字列に対する言い訳だって気がする。

> This concatenation is an interpretation, not a conversion
結合は解釈であって変換ではない。
[=「raw stringは変換を受けない」云々の事柄とは無関係だ]

> Because the interpretation happens in translation phase 6 (after
> each character from a literal has been translated into a value from
> the appropriate character set),
この、結合に望んでの解釈は、
(文字列リテラル中の個々の文字が、適切な文字集合内の要素に変換された後の)
第六段階で起こるから
[= すでにエスケープシーケンスなどは変換済みだから]

> a string literal’s initial rawness
> has no effect on the interpretation or well-formedness of the
> concatenation
文字列リテラルが最初 raw文字列であろうがなかろうが
それは結合時の解釈や整合性にはなんら関係ない。

そうするとこの部分から
"a value from the appropriate character set"
を抜き出して「第五段階ですでにエンコード済み」とは言えなくなる。
「コード値に変換された」ではなくて
「エスケープシーケンスが一文字に変換された」という意味だから。

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

2011/05/17(火) 12:58:36.92

>>483みたいに-fexec-charset=sjis
をつければuでユニコードに変換できますか？

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

2011/05/17(火) 14:05:27.48

>>493
exec-charsetがどうかということとu付けたリテラルがユニコードで表現されるかということには何の関係もない。
意味もわからず呪文を唱えるのでなく仕組みを理解しな。

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

2011/05/17(火) 15:39:10.27

誰も教えてくれないからsjisはgcc4.5じゃなくて4.6から対応しているということで自分を納得させてみよう。

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

2011/05/18(水) 09:44:06.39

C++0xおっかけたいけどgccのビルド方法がイマイチわかんなくてどうにも・・・
どっかに初心者用解説とかないん？

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

2011/05/18(水) 10:15:31.35

じゃあバイナリで落とせば？

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

2011/05/18(水) 10:40:35.97

>>496
http://gcc.gnu.org/install/

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

2011/05/20(金) 23:05:41.38

ここ１年ほどおっかけてないけど、何かあった？

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

2011/05/20(金) 23:09:57.54

FDIS可決

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

2011/05/20(金) 23:17:08.22

Final Draft International Standardね。ありがとう。
しかし、GCCで動くぶんは使ってるから、ユーザ側としては規格より実装ヨロって感じです。

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

2011/05/21(土) 01:35:05.55

（　ﾟдﾟ）ﾎﾟｶｰﾝ

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

2011/05/21(土) 02:48:16.93

まだ可決どころか投票に入れてないよー。
Stageが50:20になったら、そこから2ヶ月に渡る投票開始。
ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372

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

2011/05/21(土) 11:03:49.97

仕事で安心して使えるようになるのはいつごろですか？

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

2011/05/21(土) 12:10:16.41

仕事の要件に従え
上司・責任者に聞け
自分の判断で好きにしていいなら自分で判断しろ

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

2011/05/21(土) 15:13:28.30

ttp://ideone.com/45Shg

動的資源を std::unique_ptr<T> で管理するとこんな感じになるのだろうか
クラス X の初期化リストをもっと綺麗に書けないだろうか

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

2011/05/21(土) 15:15:36.60

>>506 それの何が気に入らないの？

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

2011/05/21(土) 15:22:09.58

>>507

reset() を使うあたりが、どうもぱっとこない。
そもそも標準のスマポの使用作法なるものが良く分からないんですけどね。。

get() とか release() とか reset() とかを、スマポを使用する側で呼び出すと、
本来 std::unique_ptr<T> がもつ所有権移動のセマンティクスが壊れてしまうような気がして、気持悪いのです

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

2011/05/21(土) 15:47:34.38

それはないだろ

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

2011/05/21(土) 16:01:26.32

つまりunique_ptrのセマンティクスを意図的に壊すためのget メンバを
pointeeのオブジェクトをクローンするときに用いないといけないのが
気持ち悪い、ということか？

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

2011/05/21(土) 16:04:35.80

X& operator=( const X& that ) {
　if( this != &that ) { *this = X(that); }
　return *this;
}
↑はresetを使わずさらに例外安全の強い保障も提供する

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

2011/05/21(土) 16:11:50.38

>>508
release() についてはわかるが、 get() や reset() を嫌がるのは意味が解らん。

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

2011/05/21(土) 18:36:14.65

>>508
コピー不可のメンバがあるクラスにコピーコンストラクタとコピー代入演算子を実装しようとしてるんだから
すっきりしないコードになるのは当然のような気がする。

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

2011/05/21(土) 20:37:53.55

pimpl_ptrをパパっと作ってそれに持たせればおｋ

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

2011/05/21(土) 21:30:13.90

そもそも代入ってリセット以外の何物でもないんじゃないかな。

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

2011/05/21(土) 22:13:41.32

c++で仕事って、どんな案件なのか想像できない

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

2011/05/21(土) 22:17:38.55

ゲーム

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

2011/05/21(土) 22:24:22.29

>>516
一昔前で言うところのシステムソフトウェア。
カーネル、ブラウザ、ライブラリなど

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

2011/05/21(土) 22:25:55.44

※但し、Windowsに限る

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

2011/05/21(土) 22:31:02.00

>>519
　　　　/＼＿＿_／ヽ
　　／／~ 　　 ~＼:::::＼
　 . |　（･）　　　（･）　 .:|
　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::| 　　　は？
. 　 |　　｀-=ﾆ=- '　.:::::::|　　　
　　＼　　｀ﾆﾆ´　 .:::::／
　　　／｀ー‐--‐‐―´＼

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

2011/05/21(土) 22:33:21.14

ここはまともなC++スレなんで
荒らさないでください

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

2011/05/21(土) 23:03:24.01

ついにこのスレまで来たか

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

2011/05/23(月) 01:21:58.98

結局C++で純粋関数型記述できるようになる？

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

2011/05/23(月) 18:54:42.51

テンプレート使えば今でも出来るよ

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

2011/05/24(火) 22:23:59.34

C# でのプロパティとかインターフェースとかイベントとかは
導入されないんですか？

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

2011/05/24(火) 22:43:58.83

プロパティは却下です。
あまりにもC++的でないので当然です。
なにかもっとよりprimitiveなoperatorに還元できれば加えられるかも。

インターフェースはもっと強力なconceptがC++1xで議論される予定です。

イベント構文はアドホック過ぎてC++には付け加えられないでしょう。
C#はperlみたいにアドホック構文バンバン導入する流儀だけど。

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

2011/05/24(火) 22:58:22.86

お前誰だよ

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

2011/05/24(火) 23:03:51.45

オレオレ俺だよ

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

2011/05/24(火) 23:39:58.46

>>525
signatureじゃあるまいし、完全抽象化classで代用できるinterfaceはあっても意味ないだろ。
イベントって、Win32由来のEventObject? それともDelegateの事？
Delegateなら、無名関数で十分だろ。

Propertyってobject.value += x;　と書いたとき、
object.SetValue(x+object.GetValue()):　って展開されるって知ってる？
仮に、operator+(xの型,objectの型)がオーバーロードされてて
operator+の中で例外が発生したとすると、GetValueから受け取ったObjectが
何らかの理由で漏れる可能性がある。そういう訳で当分は実装されんだろうね。

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

2011/05/25(水) 01:13:25.73

例外を投げるoperator+とか最悪じゃないか

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

2011/05/25(水) 04:13:15.58

何故そう思ったの？

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

2011/05/25(水) 04:14:40.92

例外のことよくわかんないからに決まってんだろ。言わせんな。恥ずかしい。

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

2011/05/25(水) 06:01:59.33

std::string::operator+ は bad_alloc 投げるよね。

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

2011/05/25(水) 07:24:55.63

operator+はともかくoperator/なら有理数とかでゼロ除算で例外投げる
可能性はあるよな。まぁ、intやdoubleが例外投げないんでそれが正しいとも言えんけど。

あと、operator+=で要素追加可能なset系のコンテナがあったとするとoperator-=で
要素削除するのは自然。コンテナに要素がないのにoperator-=したら
大体例外出すように実装するだろうね。

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

2011/05/25(水) 09:13:59.61

>>529
インターフェースってのはgenericsのtype constraintのことじゃね？
だから回答としては>>526の「conceptで対応する」でいいと思う

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

2011/05/25(水) 18:08:57.05

＞operator+=で要素追加可能なset系のコンテナ
ｵｴｯ
+を足し算以外のセマンティクスで使うのはやめて下さい
本当にやめて下さい

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

2011/05/25(水) 18:43:44.08

intの0除算はCPU例外を出すのが普通じゃないか

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

2011/05/25(水) 19:19:06.48

singned のオーバーフローで投げられる可能性も

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

2011/05/25(水) 20:35:23.61

もうさ全部SafeIntでいいんじゃない

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

2011/05/25(水) 21:13:54.76

setで+といえば普通は和集合だし-といえば差集合だよな
要素の追加削除とかないわ

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

2011/05/25(水) 21:53:09.94

>>536
文字列クラスの+=も否定する系？

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

2011/05/25(水) 22:01:48.37

要素か？

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

2011/05/25(水) 22:19:11.71

>>540
こんなかんじか。

set super = (set){10,20,5,8} + (set){4,3,2};
super == (set){10,20,5,8,4,3,2};
※面倒なんでソートはしてない。

そういや初期化リストって、キャストはできないんだっけ？

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

2011/05/25(水) 22:28:00.39

>>541
文字列の結合は可換でないから加法ではないね
+記号を使うのは完全な間違いだ
別の演算子を導入したD言語が正しい

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

2011/05/25(水) 22:29:37.71

代入複合型も含めて四則演算子での例外はトラップ手段の無い不正落ち処理にしてしまおう。

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

2011/05/25(水) 22:31:16.02

よしBASICみたいに文字列結合は&で

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

2011/05/25(水) 22:33:00.81

浮動小数の < は順序じゃないから別のオペレータ考えるべきだねって言ってるようなもんだよ
> 可換でないから加法ではないね

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

2011/05/25(水) 22:39:51.77

>>546
& は優先順位的に不便。
if("a" == str1 & str2) // だめ

* がオススメ。
非可換でも誰も文句言わないし。

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

2011/05/25(水) 22:42:49.58

>>547
殆ど全順序のように振る舞う半順序と>>544を
一緒にするのは無理があるだろ

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

2011/05/25(水) 22:45:42.45

>>548
*は文字列をベクトルとみなしてかけ算したい時に困る。

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

2011/05/25(水) 22:48:49.93

>>550
"hello" * "world"で一体何が出来上がるんだ？

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

2011/05/25(水) 22:48:55.35

>>544
string last_name = name - string("mike");
みたいに引き算も用意したらある程度可換じゃね？

string("will") + ( name - string("jhone") );
これで数式らしく置換もできる。おっせぇけど。

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

2011/05/25(水) 22:50:54.42

文字列の掛け算は繰り返しっぽい

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

2011/05/25(水) 22:51:06.30

>>552
意味がわからない
それが可換性と何の関係があるんだ？

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

2011/05/25(水) 22:52:03.39

文字列の * はあれだよな
"x" * 3 -> "xxx"
とかだよな

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

2011/05/25(水) 22:52:18.57

じゃあ / か % だな
% はPythonのアレっぽいから / が一番だ

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

2011/05/25(水) 22:53:36.15

C++的には<<がいいんじゃね
iostreamでもつかうし

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

2011/05/25(水) 22:54:30.96

->*「俺の出番のようだな」

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

2011/05/25(水) 22:54:50.12

>>552
operator = に渡ったとき遅延評価で Add< string, Sub<string,string> >を受け取って
置換処理に渡せばある程度早くはできそうではあるな。

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

2011/05/25(水) 22:56:33.47

>>554
値と同列に扱えるってことじゃないの？
もしかして、2項演算子の左右可換の事言ってる？

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

2011/05/25(水) 22:58:09.27

あなたは値と同列に扱えることを可換と言うのか
斬新ですね

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

2011/05/25(水) 22:58:14.58

*の意味的には
3 * "x" -> "xxx"
のほうが綺麗だな
プログラミング的には最悪だは

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

2011/05/25(水) 23:01:21.66

string("Hello ") + "world!" == string("Hello world!")
string("Hello ") - "world!" == string("Hello world!")
string("Hello ") * "world!" == string("Hello world!")
string("Hello ") / "world!" == string("Hello world!")
string("Hello ") % "world!" == string("Hello world!")
string("Hello ") << "world!" == string("Hello world!")
string("Hello ") >> "world!" == string("Hello world!")
string("Hello ") ->* "world!" == string("Hello world!")

うーん

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

2011/05/25(水) 23:04:21.64

何で++案が出ないのか

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

2011/05/25(水) 23:05:45.61

節子、それ単項演算子や

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

2011/05/25(水) 23:06:24.76

C++に2項の++なんてあったっけ

AviSynthっていう動画用スクリプト言語兼フレームサーバでは++を結合に
よく使ってますが、どうでもいいですねすみません

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

2011/05/25(水) 23:06:49.17

>>561
置換可能を可換というのが一般的な日本語じゃなかったっけ？
うちのおかんにとっては、CDもBlu-rayも円盤という言葉で可換な存在だ。
また、バーチャルボーイもゲーセンの筐体も、ファミコンと可換だ。

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

2011/05/25(水) 23:08:36.66

手こずっているようだな尻を貸そう

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

2011/05/25(水) 23:08:49.76

>>563
(string){"Hello ", "World"};
でよくね？

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

2011/05/25(水) 23:09:57.48

>>567
ここでの可換というのはオペランドが可換かどうかの話だろ。
数学用語で使う意味の可換性だべ

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

2011/05/25(水) 23:10:19.39

2項演算に関するコンテキストでは、可換と言ったら
交換法則、すなわち
a・b = b・a
が成立することを指し、それ以外を意味しないのが普通だと思う

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

2011/05/25(水) 23:12:26.10

^_^はどうよ

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

2011/05/25(水) 23:14:13.39

それは空気と識別子_と空気をxorしてるんですかね

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

2011/05/25(水) 23:18:51.85

せっかくオーバーロードあるんだし
"hello"*3=="hellohellohello"
"hello"*"world"=="helloworld"

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

2011/05/25(水) 23:40:27.75

文字列が可換にならないのは、文字列のバイト表現と、
文字の順番が独立していないから。
つまり順番を独立させればいい。

nstring name = nstring(1,"Second") + nstring(0,"First");
name == string("FirstSecond");

name = nstring(1,name) + nstring(0,"Xero");
name == string("XeroFirstSecond");

name = nstring(0,name) - nstring(0,"eroFirst");
name == string("XSecond");

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

2011/05/25(水) 23:45:00.94

A ** 3 = AAA

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

2011/05/25(水) 23:45:19.68

>>571
まともな人間は、交換法則のことだけをさして「可換」とは言わない。

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

2011/05/25(水) 23:50:02.81

と言う訳で、次は結合法則の話題が続きます

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

2011/05/25(水) 23:53:33.95

>>577
>>544の文章を読んで、代数的な意味、つまり二項演算の交換法則の意味だと
理解できないのは、
ちょっと読解力に問題があるように思うのだが……

http://blogs.msdn.com/b/oldnewthing/archive/2011/02/11/10127845.aspx
これをお勧めしておく

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

2011/05/26(木) 00:03:53.50

>>575
それだと
string str = "FirSecondst-First";
str - nstring(0,"First") - nstring(0,"Second") != str - nstring(0,"Second") - nstring(0,"First");
になって一致しないだろ。やりなおし。

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

2011/05/26(木) 00:23:48.45

>>551
{'h'*'w', 'e'*'o', ...}

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

2011/05/26(木) 00:24:32.45

そろそろスレ違いな感じもするが、
こういう話題は好きなのでそういうスレがあれば誰か教えてくれ

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

2011/05/26(木) 00:48:15.37

多くの人々がだいぶ前に通過した場所だけどな。
根本は+の意味を数学的な加算に限定するか一般的な追加にまで拡張するかという思想の違い。

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

2011/05/26(木) 00:53:52.57

ベクトルを考えたときに、加算と連結は別の演算子として欲しいってのは当たり前と思うが。
兼ねてるほうが異常。

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

2011/05/26(木) 00:55:48.40

できれば数学と同じテンプレートが使えるようにしたいけどね。

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

2011/05/26(木) 01:02:43.74

*が外積なのか内積なのか分かりにくいので、・と×を導入してください

pythonの
　for i in range(a,b):
は
　for i in [a,b)
になります

代入は:=、比較は=くらいは言語によっては実施されてるか

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

2011/05/26(木) 01:15:21.82

ベクトルの連結を数学っぽく書くと(a b)になるのかな

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

2011/05/26(木) 01:18:25.16

a | b

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

2011/05/26(木) 01:25:15.01

腐れ数学オタのこだわりとか心底どうでもいい

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

2011/05/26(木) 01:26:49.99

>>586
そこまでやるんならinじゃなくて
i <- [a, b)
と書きたいな
内包表記はPythonよりHaskellのが断然いい

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

2011/05/26(木) 01:31:13.64

数学ヲタがキモイから、中置記法は全廃して、全て前置記法にするのが合理的だ。

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

2011/05/26(木) 01:35:42.16

a->b[c] += d
を
(set! (aref (slot-ref a b) c) (+ (aref (slot-ref a b) c) d))
とか書きたいんですよね、わかります

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

2011/05/26(木) 01:36:34.93

>>591
lisp化が進むんですねw

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

2011/05/26(木) 01:40:17.68

Python の 3 <= n < 10 みたいな書き方は正直羨ましい。

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

2011/05/26(木) 01:44:04.52

lispは生産性の点でちょっと…
>>594みたいな書き方は数学的だけど関数言語的じゃないし
そもそも数学って手続き的だし

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

2011/05/26(木) 01:49:59.50

>>595
え。。。
どの辺が手続き的？

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

2011/05/26(木) 01:53:20.78

純粋数学は別にいいんだけど、
実際にそれを使って証明だアルゴリズムだとなると、どうしても手続き的な使い方になるので
プログラミングとなると、さらにそういう側面が増えるし

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

2011/05/26(木) 01:57:16.21

タダのシンタックスシュガーだろ。難しく考えすぎ。

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

2011/05/26(木) 01:59:08.38

証明って手続き的か？
たとえば数学的帰納法が近いのは手続き的なループじゃなくて
関数的な再帰とパターンマッチだろうし
ニュートン法みたいな奴も、数学的に定式化する場合は要は漸化式じゃないの？

手続きといえば代入で
x = x + 1
なんだけど、これはメモリセルから値をとって1を足し、元の
メモリセルに代入するという数学的には意味のないことをやってるけど
しかしそれが手続き的プログラミングにおいては本質的

正直>>595や>>575が何を言ってるのか俺もよくわからない
Lispが生産性云々も、Lisperから見たらC++erがそれを言うのか？って感じだぞｗ

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

2011/05/26(木) 02:14:15.02

>>597
アルゴリズムって関数型言語の十八番な訳で、そこを否定して手続き的と言われてもな。。。

最近、数学ガールゲーデルの不完全性定理を読み終わったんだが、そこに出て来た論理体系がhaskellにそっくりでビビったぞ

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

2011/05/26(木) 02:22:52.72

多分想定してる分野が違う気がする
数学と言っても広い

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

2011/05/26(木) 07:13:27.99

>>577
まともな人間は今話している内容を考慮して
単語の意味を考えることができる。
それができないお前がバグ。

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

2011/05/26(木) 08:37:20.15

>>587を採用すると、
(string("Hello ") string("world!")) == string("Hello world!")
になるのか。
元々文字列リテラルの併記は結合されるし、C++には合ってるかもな。

で、オーバーロードしたいときはoperator ???……なんて書けばいいんだ？

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

2011/05/26(木) 09:27:09.88

>>603
std::string operator,(std::string const&, std::string const&);

auto helloworld = (std::string("hello "), std::string("world"));

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

2011/05/26(木) 20:50:57.60

コンマ演算子は確かにそれっぽいな
オーバーロードできないけど

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

2011/05/26(木) 20:56:46.31

->*演算子の出番のようだな

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

2011/05/26(木) 20:58:04.30

.*もあるな

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

2011/05/26(木) 21:02:02.29

std::string operator()(std::string const&, std::string const&);
auto helloworld = std::string("hello")("world")("!");

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

2011/05/26(木) 21:16:37.33

そんな変態用法、イラン

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

2011/05/26(木) 21:33:26.76

>>605
コンマはオーバーロードできるよ。
&& や || ができるんだから当然。

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

2011/05/27(金) 00:28:20.08

マクロ＋コンマ演算子オーバーロードによる可変長引数的変態関数

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

2011/05/27(金) 00:36:21.51

( eval,( output,( concat,"Hello"," ","World" ) ) );

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

2011/05/27(金) 00:43:26.90

やっぱりカンマは要らないな

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

2011/05/27(金) 00:47:52.29

そもそも関数型言語なら本質的にリスト作成以外の目的で括弧いらんだろ

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

2011/05/27(金) 01:27:57.33

それはないだろ

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

2011/05/27(金) 01:54:48.73

引数の数が固定なら構文解釈の結果は一意に定まるだろ

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

2011/05/27(金) 04:04:04.75

中置演算子の優先順位とか

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

2011/05/28(土) 15:11:08.27

>>594
便利さはわかるけど、冷静に考えたら、
曖昧卓。

そう感じるのはC脳だからか？

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

2011/05/28(土) 15:16:29.72

operator overloadで、
x < y < z
をうまくユーザ定義できる方法があるなら取り込んでもいいと思う。
アドホックな導入ならいらない。

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

2011/05/28(土) 15:22:23.23

>>618
そもそも文と式の使い方や暗黙的型変換がCとPythonじゃ違いすぎるからなあ

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

2011/05/28(土) 15:48:36.49

>>619
Python にも operator overload はあるから、問題はそっちよりも
C言語や過去のC++言語と互換性。構文レベルで全く違う意味に
なっちゃうからな。

C++ の a < b < c は (a < b) < c の意味だけど、 Python の a < b < c は
(a < b) && (b < c) の意味（ただし、bが評価されるのは1回）

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

2011/05/28(土) 16:17:26.08

rangeの概念を一般化して取り入れるべきだと考えている人もいるようだから
あるいはc++でもそのうちこんな記述が･･･ [n] & [3,10)

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

2011/05/28(土) 16:22:49.73

[,)を認めると、構文解析器が悲鳴を挙げないか？

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

2011/05/28(土) 16:24:04.18

operator<(int,int)とかoperator*(T*)とかの再定義の話になるからなあ

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

2011/05/28(土) 16:28:15.84

>>621
> 構文レベルで全く違う意味になっちゃうからな。

( ﾟдﾟ)ﾎﾟｶｰﾝ
構文レベルで意味…

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

2011/05/28(土) 16:35:30.56

おーぶんってライブラリがRange関係の機構を扱ってるらしい。
ライブラリでどうにかなるならライブラリでいいじゃない。

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

2011/05/28(土) 16:39:42.30

a < b < c が operator<( operator<(a, b), c ) でなく
operator<(a, b) && operator<(b, c) と解釈されたら困るコードってあるかなぁ…。

すでに a < b < c を数学の意味になるよう工夫したコード書いてる人がいたら困るか。

今から deprecate して20年後くらいに auto さんみたく生まれ変わらせるのはありかも

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

2011/05/28(土) 16:46:41.74

>>621
リスプ
(< a b c)
c++ もこうしてしまえばww
<(a b c)

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

2011/05/28(土) 16:52:01.50

Pythonだと a < b > c とも書けるみたいだから、
>>628 みたいにはいかないよね。
(a < c < b に置き換えられたら別の意味になっちゃうし)

ライブラリとかじゃなくて言語が頑張るような機能じゃないかなと思う。

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

2011/05/28(土) 16:53:46.29

>>629
> Pythonだと a < b > c とも書けるみたいだから、

ぶっちゃけ、これはあり得ない局面ではないがいらんだろ。

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

2011/05/28(土) 16:54:07.34

a < b > c
はなんかおかしい

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

2011/05/28(土) 17:06:56.81

すなおにb > max(a,c)って書けよと

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

2011/05/28(土) 17:33:38.76

if (o<O>o)

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

2011/05/28(土) 17:36:10.62

もう、変態的なコード止めてくれる？

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

2011/05/28(土) 17:44:30.92

>>633
タングラムさん、なにやってんすか。

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

2011/05/28(土) 18:36:12.71

a < b > c はテンプレートで困るん

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

2011/05/28(土) 19:11:01.45

Pythonの__cmp__みないのがないと無理

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

2011/05/28(土) 19:14:46.14

__nlp__

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

2011/05/28(土) 20:16:13.63

>>625
構文解析と意味解析は分離できるのが理想だが
C++の変態構文ではとてもじゃないが分離不可能

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

2011/05/28(土) 22:49:49.49

>>639
そういやそれってよく聞くけどどこら辺が面倒なの？

未だによくわからないんだが…

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

2011/05/28(土) 23:44:00.98

良い例がこれだな
識別子の意味が定まってないと<や>は不等号か山括弧か判断付かない
ttp://d.hatena.ne.jp/DigitalGhost/20090216/1234793122

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

2011/05/28(土) 23:56:45.38

WalterﾀﾝがC++が変態過ぎて辟易して
構文解析と意味解析が完全に分離されたD言語作った程

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

2011/05/29(日) 10:40:55.11

>>641
なるほど！
どうもありがとう

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

2011/05/29(日) 10:45:36.13

>>641
それ、C++0xだとエラーにならない？

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

2011/06/01(水) 21:01:15.73

n3290.pdfもn3291.pdfもみれなくなってしまった

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

2011/06/01(水) 22:43:05.51

n3291は持ってるからどうでもいい

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

2011/06/02(木) 01:10:57.13

へぇ。ローカルに確保しといて正解だった。

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

2011/06/02(木) 07:21:53.16

直列化って何で規格に入らないんだ？
ちょっとした通信したいときにめんどい。

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

2011/06/02(木) 08:17:31.76

>>648
ちょっとした用途ならboost::serializationが便利

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

2011/06/02(木) 09:31:22.99

いやいやいやそういう話じゃない

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

2011/06/02(木) 20:18:27.67

standard-layoutが規格化されてるからそれで充分だろ
通信は自分でやれ

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

2011/06/02(木) 20:52:46.34

パディングが入って32bitと64bitで互換がない、
またコンパイラによっても互換が無いので却下。
パディングをパックしろっつうのも目先しか
見えてないアホがやる事なので却下。

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

2011/06/02(木) 21:34:06.01

つalignas

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

2011/06/03(金) 00:01:32.51

stdint.h

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

2011/06/03(金) 01:47:49.72

C with Classesのころのシンプルさに戻して欲しい

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

2011/06/03(金) 01:52:52.32

だから、自分の使えない機能は使わなければいいだけ。

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

2011/06/03(金) 01:55:48.50

馬鹿が使いたがるのが困るんだって

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

2011/06/03(金) 01:59:04.48

そういうジャップはEmbedded C++でもシコシコ作ってろ

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

2011/06/03(金) 08:26:19.77

C with の時点ですでにシンプルではない

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

2011/06/03(金) 08:36:48.12

むしろrange based forとかnullptrやstrong enumは馬鹿こそ使うべきなんだけどな

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

2011/06/03(金) 08:54:50.86

シンプルだよねぇ

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

2011/06/03(金) 08:59:30.65

C++は馬鹿ホイホイ

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

2011/06/03(金) 09:41:35.41

strong enumさんとinitializer_listさん早く来ないかなー。

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

2011/06/03(金) 20:59:30.34

unique_ptr や shared_ptr のように null_ptr にしてほしかった

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

2011/06/04(土) 10:16:39.83

initializer_listを受け取るコンストラクタはexplicit指定外すべき？
hoge h = {...};
explicitにすると↑が出来なくなって無意味化するよね？

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

2011/06/04(土) 11:46:54.32

hoge h{...};
って書けばいいよ

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

2011/06/04(土) 15:41:01.12

キモイ

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

2011/06/05(日) 02:25:37.47

キモナイ

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

2011/06/05(日) 12:37:56.53

本の虫の人が出す本が、Ray Lischner の
C++ in a Nutshell を越えることを期待している

詳説C++ の第３版出ないかな
C++ in a Nutshell の0x対応版も出てほしい

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

2011/06/05(日) 13:46:59.48

C++0x本って出るのいつなんだ？

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

2011/06/05(日) 13:54:58.60

常識的に考えればまずは規格が正式に固まってからだろ

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

2011/06/05(日) 15:04:04.90

つまらない常識だな。
実務でリファレンスとして使うならそれでいいが、
今後どうなるかを知るための策定中規格の解説書にも需要はあると思うけどな。

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

2011/06/05(日) 15:15:13.96

もうFDISだから固まったようなもんだろ

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

2011/06/05(日) 15:27:18.65

conceptﾄﾞｺｰ

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

2011/06/05(日) 15:33:01.05

お星様になったんだよ

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

2011/06/05(日) 15:49:36.04

concept に根を下ろし　template と共に生きよう
auto と共に冬を越え　decltype と共に春を歌おう
どんなに恐ろしい構文を持っても
たくさんの可哀想な委員会を操っても
コンパイラから離れては生きられないのよ

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

2011/06/05(日) 16:13:33.29

concept は滅びぬ！何度でもよみがえるさ！

# 実際、今回の規格が発行したら、すぐに再燃するだろうな

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

2011/06/05(日) 16:13:56.63

ジェネリックは滅びぬ、何度でもよみがえるさ、抽象化の力こそ人類の夢だからだ！！

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

2011/06/05(日) 16:36:40.93

コンセプトマップ使えば、

int i = int.parse("0xff");

みたいに書けるようになってほしい。

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

2011/06/05(日) 16:40:06.86

知らんけど Ruby みたい

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

2011/06/05(日) 16:50:48.42

組み込み型にメンバ関数持たせたり継承できたりするのはキモイ
LL厨やOO厨が何と言おうとキモイもんはキモイ

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

2011/06/05(日) 17:30:09.34

組込み型だけが何か特殊な性質を持つ方がキモイわ

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

2011/06/05(日) 17:34:38.89

組み込み型は現実に特殊なんだよ
intは数値を表すバイト列そのものであるべきであって、間違ってもvtblなんか持っちゃいけないんだよ
VM持ちの言語ならそれでもいいのかもしれないけどCやC++では絶対ダメ

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

2011/06/05(日) 17:45:13.27

べつにint自体には影響ないから問題ないだろ

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

2011/06/05(日) 17:55:03.34

校長先生の本がついに出るとな
http://hibari.2ch.net/test/read.cgi/tech/1304856318/704

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

2011/06/05(日) 17:58:33.79

int* p = new DerivedTypeFromInt();
delete p; // あぼーん

int に vtable を持たせないとこうなる

でも derivable<int> みたいな感じで int とまったく同じに使えるのに継承可能なテンプレートは欲しい
少なくともコンパイルタイム有理数とかよりは需要あると思う

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

2011/06/05(日) 18:01:38.85

そもそもintは継承できないだろ

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

2011/06/05(日) 18:10:22.31

>>687
intが継承できないのは vtable 持たせられないからだ、というレスに
int には影響ないからいい、というレスがついていたので、
いや、int に影響を与えないとまともに継承できないじゃないか、というレスをつけた。

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

2011/06/05(日) 20:07:15.76

>>686
> でも derivable<int> みたいな感じで int とまったく同じに使えるのに継承可能なテンプレートは欲しい
> 少なくともコンパイルタイム有理数とかよりは需要あると思う

はあ？

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

2011/06/05(日) 20:34:42.19

言いたいことはわかるけどな
こんなのがしたいんだろ

class SafeInt : derivable<int>
{
SafeInt operator+(SafeInt lhs, SafeInt rhs){
long result = (long)lhs.get()+(long)rhs.get();
if(result<INT_MIN || INT_MAX<result) throw std::overflow_error();
return (SafeInt)(int)result;
}
}

あまりいいやり方とは思えない

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

2011/06/05(日) 20:41:25.46

>>686
?
仮想メンバーを一切持たないオブジェクトも問題なくdeleteできるんだけど。

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

2011/06/05(日) 20:55:58.45

できねえよ
お前は何を言ってるんだ

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

2011/06/05(日) 21:06:13.91

>>691はvtblがないオブジェクトとは言ってないからdelete出来る

論点はずれてる

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

2011/06/05(日) 21:14:06.04

>686
スライシングを避けるためには参照かポインタで持たなきゃいけないけど、
組込み型を参照とかポインタで持つことはほとんど無いからメリット無いんじゃね？

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

2011/06/05(日) 21:22:24.76

>>694
いや、組み込み型をポインタで持ちたいんじゃなくて
クラスのオブジェクトを組み込み型のポインタに入れたいんだよ。
でないと継承する意味ないよね。

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

2011/06/05(日) 21:24:00.81

何にせよ仮想デストラクタのない型でやる事じゃないわ
恐ろしすぎる

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

2011/06/05(日) 21:33:07.48

intのデストラクタをprotectedにしようぜ！

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

2011/06/05(日) 22:00:28.54

継承せずに使わせてよ

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

2011/06/05(日) 23:32:57.87

拡張メソッドみたいなのじゃだめなのか

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

2011/06/05(日) 23:38:17.22

そもそも「.」の左側と右側を区別する必要があるのかどうか

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

2011/06/06(月) 00:19:08.28

>>695
入れればいいじゃん。

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

2011/06/06(月) 00:51:27.01

>>695
vtableを持たない親classのポインタに子を入れても、
親classのポインタをdeleteしなけりゃ別に問題ない。

てか、親classのポインタでdeleteするヤツいる？
個人的には全くといっていいほどしたこと無いけど。

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

2011/06/06(月) 00:55:45.21

そらもういくらでも

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

2011/06/06(月) 01:14:23.96

スライシングとかdeleteミスとかはshared_ptrで回避できるのにな。

>682
単に組込み型をラップするクラスを用意してそっちを使えば良いと思うけどな。

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

2011/06/06(月) 02:25:04.78

int相手にdynamic deleterとか嫌だよ

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

2011/06/06(月) 10:46:32.49

conceptは無駄にプログラムが長くなるだけ
コンパイルエラーが出たらクラスの定義見ればいいし

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

2011/06/06(月) 10:48:24.01

>>706
> conceptは無駄にプログラムが長くなるだけ

全く逆

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

2011/06/09(木) 12:16:08.65

ムーヴコンストラクタはデフォルト指定出来るのにムーヴ代入はできないのか？中途半端やなぁ…

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

2011/06/09(木) 12:24:50.51

できるぞ。

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

2011/06/11(土) 16:37:11.77

6/10付けでFDIS(2ヶ月)の投票開始
ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372

8/10頃投票が終わってそこから発行手続きやら何やらで
うまく行って9月頃かな。

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

2011/06/11(土) 17:12:53.41

で、行列の積の問題は、moveで解決できるのでしょうか？

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

2011/06/11(土) 19:32:08.92

この人か
正直何を言ってるのかわからん

138+1　デフォルトの名無しさん 2010/04/02(金) 21:48:36
右辺値参照を用いて（a+b)*(c+d)*e のような行列の積を正しく計算
できますか？

a *= bの行列演算では、裏側で一時オブジェクトを導入しない限り
正しい計算結果は得られないはずですが( a += bとはわけが違う )、
右辺値参照でもこれと同じような事は起きませんか？

｢いや、C=prod(A,B)のような使い方しか想定してない。｣と言うのなら
仕方ないですが。

※｢右辺値参照｣の右辺値という言葉はかえってわかりにくいと思うの
ですが、皆さんはどうですか？

140　デフォルトの名無しさん sage 2010/04/02(金) 23:49:29
>>138 何言ってるのかわからん。 >139 はエスパーか？

右項が正方行列な積の一次オブジェクトは左項の１行分だけ確保すれば十分なので
右辺値参照使うならそういう対処ができる

右項が長方行列な積であれば左項と結果のサイズが変わるので
結果は新しいオブジェクトを作るしかないが
その結果と足し算をするとか言う場合のために右辺値参照を返すのには価値はある

このくらいの事しか言えない

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

2011/06/11(土) 23:10:26.65

つまり、無理矢理右辺値参照を使うことは出来るが、効率的に意味がない、
という理解でよろしいでしょうか？

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

2011/06/11(土) 23:28:45.17

まず「行列の積の問題」とやらを明確にしてください

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

2011/06/12(日) 00:36:04.12

一時オブジェクトの使用と右辺値参照はなんの関連もなく
右辺値参照を使うなら一時オブジェクトを使ってはいけないなんてことはあるはずもないんだが。

行列クラスMのa*=bの実装は
M tmp(a); a=tmp*b;
とか
M tmp; tmp=a*b; swap(a,tmp);
とかの形になるだろうがどちらもmoveの導入で効率をよくできる。

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

2011/06/12(日) 01:51:37.15

ん？右辺値参照って、原則無名のオブジェクトを参照している事を保証してる参照じゃねぇの？

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

2011/06/12(日) 01:59:09.64

いや、代入/コピーの右辺値の意味をユーザ定義できる機構。

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

2011/06/12(日) 02:18:32.93

そういやそうか、

std::string &&value = std::string("これやると危険だもんな");
typeA a = value;//valueが破壊される
typeB a = value;//おそらくセグフォ

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

2011/06/12(日) 02:19:15.24

>>713
どう読んだらそうなるんだ

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

2011/06/12(日) 02:26:45.74

無制限に無名オブジェクトを取れる訳じゃなく、
引数に取れる場合しか使えないって事だろ。

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

2011/06/12(日) 04:03:22.54

>>718
その定義だとvalueは右辺値を参照する左辺値だからvalueは破壊されない。
というか右辺値参照を思いっきり勘違いしてる気が。

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

2011/06/12(日) 09:06:08.66

そんなに右辺値参照の基本部分って難しいかねぇ？

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

2011/06/12(日) 10:31:43.06

３行で

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

2011/06/12(日) 15:33:55.49

変数に
割り当てられていない
値

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

2011/06/12(日) 17:26:07.53

「割り当てる」って代入のこと？

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

2011/06/12(日) 18:17:52.81

この世界で"割り当てる"のはメモリ(領域)だろ

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

2011/06/12(日) 18:24:30.61

対象となる目的語を聞いているのではなく、動詞の意味を聞いているのだけど。

「変数に（メモリ(領域)を）割り当てられない」とは、C++で具体的にどういう操作ができないということ？
「変数へ代入できない」とは別の意味？

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

2011/06/12(日) 18:38:34.81

>>727
ちゃんと読めよ。
「割り当てられていない」であって
「割り当てられない」ではないぞ。

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

2011/06/12(日) 18:42:21.43

了解。

つまり、
「変数に（メモリ(領域)を）割り当てられていない値」
が右辺値参照ということだね。

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

2011/06/12(日) 18:48:32.31

変数に束縛されていない値と言うべきかな

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

2011/06/12(日) 18:51:05.27

それは右辺値参照ではなく右辺値の説明では

0732718

2011/06/12(日) 19:17:19.13

Self &Self::operator = (Self &&source)
{
  delete[] this.array;
  this.array = source.array;
  source.array = 0;//これが可能なのが右辺値って事じゃねぇの？
  return *this;
}
sourceに渡された値は今後他に使用されない事が建前的に保証されてる。
sourceに渡される値は演算子の結果若しくは、関数の戻り値のみ。

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

2011/06/12(日) 19:25:07.86

std::moveの事もたまには思い出してやってください

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

2011/06/12(日) 20:23:39.19

> source.array = 0;//これが可能なのが右辺値って事じゃねぇの？
可能不可能でいうなら左辺値をconstでない普通の参照で受けても出来るけど。

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

2011/06/12(日) 20:45:42.50

右辺値参照って、要するに一時オブジェクトを束縛して、
消え行くオブジェクトのオーバーヘッドを減らして効率上げる機構だよね？？？
関数とかで返却されるオブジェクトのディープコピーよりももっと手数を短くしたいっていう欲求というか。。。

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

2011/06/12(日) 20:47:26.77

>>735
それは応用のひとつに過ぎない。

0737735

2011/06/12(日) 20:52:37.93

うそん。これだけだと・・・。
あと何があるのかなぁ？？？

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

2011/06/12(日) 21:00:05.33

右辺値参照は、右辺値の振る舞いを自由に定義できるローレベル機構。

あるオブジェクトが右辺値参照される回数をカウントしてログ取るだけでもいいし、
smart pointerのよりエレガントな実装に使ってもいい。

C++は>>735のような用途限定の機構は規格には入らない。

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

2011/06/12(日) 21:02:46.03

>>738
そりゃ屁理屈だろ。
別にthrowはif & dynamic_cast代わりにつかえるつってんのとかわんねぇじゃん。
そりゃ使えるだろよ。

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

2011/06/12(日) 23:19:01.22

ビットシフト演算子をストリームにとかあるし・・・

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

2011/06/13(月) 00:31:32.26

右辺値参照はもともとはmove(の概念)を汎用的で問題が起きにくい形で実装・使用できるように導入された仕組みだろ。
もちろんそれ以外の用途で使ってもかまわないが。

1 条件によってはmoveはcopyよりも効率的だというのは以前から知られていた。
2 より広い範囲でmoveを使えるようにmoveの実装・使用を助ける仕組みを規格として導入したいが
　・既存のコードに影響せず
　・できれば現在の仕様と親和性のある形の
　・意図しないmoveが発生しない
　ような仕組みを導入したい。
3 そうだ右辺値ならたとえ意図せずmoveされてもほとんどの場合問題にならない。
　右辺値のみを受け付けるインターフェイスを作ってそこを介した時だけmoveするようにしよう。
4 右辺値参照誕生。
5 少しあったがやはり左辺値を右辺値として扱える仕組みも必要だ。
6 std::moveやstd::forward誕生。

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

2011/06/13(月) 01:03:34.56

>>741
この問題は、その箇条書きで言えば3.が早い段階で議論されて、
その後、moveとforwardが議論されだしたって流れ。
もちろんconstベースのmove, forward最適化の議論はそれ以前からあったけど。

具体的に言えば、n1188でbindでreferenceを避けるために禿が&&を導入、
n1377でmove, n1385でforwardingに、あの&&使えるじゃん！となった。
これはJohn Spicerが思いついたらしい。
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#106 辺りを経由。

だからmoveしたいがために&&が検討されたってのは歴史的経緯としては間違い。
&&をmoveばかりで考えるのも、仕様の理解を妨げる。move脳になってしまう。

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

2011/06/13(月) 01:14:22.80

lvalueとrvalueで話がされてるけど、この概念も拡張されたんだよね？

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

2011/06/13(月) 01:20:52.73

そういやxvalueとか居たなぁ。

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

2011/06/13(月) 01:25:21.11

右辺値参照がlvalueとrvalueの相の子のような妙な代物になってしまったので
専用の名前（xvalue）を作って整理しただけで別に新しいことはないよ

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

2011/06/13(月) 01:27:30.51

int value;
const int &xvalue = function();
int &prvalue = value;

こういうことか。

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

2011/06/13(月) 12:23:39.58

右辺値参照で右辺値を束縛したら、その右辺値参照がスコープ外れて破棄されるまで値が束縛されるってことでいいん？
こんな感じに取った場合。
http://ideone.com/mghMo

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

2011/06/13(月) 16:47:10.23

effective 0xが出るまでは安心して使えないと思う

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

2011/06/14(火) 21:54:05.98

>>733

えっ？　move終わったの？

そもそも、いつのまにforwardなるものが･･･

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

2011/06/14(火) 23:22:26.11

>>749
最初から。(>>742)

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

2011/06/14(火) 23:28:27.75

いつまで考えてるつもりなの？
シェアなくなるまで？

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

2011/06/15(水) 02:00:43.79

??

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

2011/06/15(水) 08:18:15.93

いつISになるのかって話なら、3月にFDISが承認されたから今年の夏ごろ発行される予定と聞いたが

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

2011/06/15(水) 09:47:25.40

>>751

お前が首を吊るまでｗ

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

2011/06/15(水) 14:13:32.09

http://d.hatena.ne.jp/faith_and_brave/20081009/1223548246
なんで野家は漢字でいいんですか？

0756 忍法帖【Lv=12,xxxPT】

2011/06/15(水) 14:17:47.02

u"ってしてるから

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

2011/06/15(水) 14:21:30.78

理屈の上ではそうですが実際は違うくないですか？

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

2011/06/15(水) 18:16:44.87

実際って具体的に何のどこを指しているんだ

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

2011/06/16(木) 12:22:07.48

>>755
野家が漢字でかまわないのは今まで通り。
(コンパイラがソースのキャラクターセットに対応している限り)

\U00020BB7 は\uffff より大きいことからわかるように
(多分)下の棒が長い給g。SJISのソーャXには書けないｂｩらエスケープｂｳれてる。

0760ャfフォルトの名末ｳしさん

2011/06/17(金) 01:09:50.26

これ、楽しそうね。
http://cppandbeyond.com/

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

2011/06/18(土) 00:25:13.55

んでお前らは0x仕事で使えるようになった？

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

2011/06/18(土) 00:30:19.76

その前にC99を使えるようにしてください

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

2011/06/18(土) 04:27:16.93

autoとラムダ式とスマートポインタとarrayくらいだな。

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

2011/06/18(土) 06:21:39.54

関数型言語見切った
一人で作るならC++最強だな

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

2011/06/18(土) 07:35:26.21

nullptr、= default、= delete、スマートポインタは読みやすくなりそうだけど
autoとかはどのくらいの目安で使えばいいのか迷う

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

2011/06/18(土) 09:02:43.78

for (auto itr = hoge.begin(); ... )

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

2011/06/18(土) 09:50:10.70

auto i=3;じゃなくて、いきなりi=3;とか書ければいいのに

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

2011/06/18(土) 09:52:21.30

それはもう別物だろう
変数の宣言が必要のない言語なんてあるのか？

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

2011/06/18(土) 09:52:50.87

lua

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

2011/06/18(土) 09:56:44.82

Haskell

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

2011/06/18(土) 10:01:45.71

autoって書くのはLuaでlocalと書いたりHaskellでletと書いたりするのと同じじゃね

まあPythonあたりだとなんも無いけど、そのかわり関数スコープで
ブロックスコープ相当の機能はないし
上位スコープの変数を更新するのにいちいちglobal文やnonlocal文が必要だし
既存の変数を書き換えるつもりでtypoしても処理系はエラーを検出できないよ

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

2011/06/18(土) 10:03:45.24

for (const auto x : { 1,3,5,7,11 }) cout << x << '\n';

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

2011/06/18(土) 10:04:48.11

いや、C++にautoはあっていいけど、>>768みたいに言われるとね

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

2011/06/18(土) 10:21:58.60

>>767-768
古いCだな。

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

2011/06/18(土) 11:35:11.39

とりあえず、型名にテンプレートが入ったら迷わず auto って感じだな。
ラムダ式の仮引数に auto が使えないのは残念。

std::vector<std::shared_ptr<hoge>> v;
(略)
std::sort(v.begin(), v.end(), [&](const auto &lhs, const auto &rhs) { ... });

こういう書き方が出来ればいいのに。

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

2011/06/18(土) 11:45:56.44

むしろ、こうしたい。
v.sort([&](const auto &lhs, const auto &rhs) { ... });

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

2011/06/18(土) 11:54:53.79

decltypeも結構長くなるな
decltype(v)::value_type
decltype(*v.end())
decltype(v.back())
decltype(v[0])
std::sort(v.begin(), v.end(), [&](const decltype(v)::value_type &lhs, const decltype(v)::value_type &rhs) { ... });

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

2011/06/18(土) 11:59:29.23

マクロでも使えば？

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

2011/06/18(土) 12:02:04.70

もしvの型がベクターの参照で宣言されていたら

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

2011/06/18(土) 13:05:40.75

参照型から元の型に変換する型関数書いてそれを適用したものをdecltype

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

2011/06/18(土) 14:24:37.98

decltypeってキーワード長過ぎ

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

2011/06/18(土) 14:34:30.23

__tぐらいにしてくれ

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

2011/06/18(土) 14:48:03.45

#define ty decltype

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

2011/06/18(土) 16:48:52.69

perlでやれ

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

2011/06/18(土) 20:39:50.29

キーワードでなく、メンバにしてしまえばいいのさ
v.type みたいに

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

2011/06/18(土) 20:51:57.03

るびーみたいだな
あれは動的にやってるから解釈は簡単だけどそういうのをコンパイル時にするとなると一体どうなるのか
Dみたいにコンパイル時インタプリタ走らせてみるか？ｗ

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

2011/06/19(日) 01:30:26.64

C++テンプレートもチューリング完全ですよ。

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

2011/06/19(日) 01:31:18.78

誤爆

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

2011/06/19(日) 07:41:16.38

constexprがある以上、C++もコンパイル時インタプリタは走ってるはずw

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

2011/06/19(日) 20:08:06.28

めんどくさいから, もう()だらけのポーランド記法でいいよぉwwW

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

2011/06/19(日) 22:53:38.73

>>789
exprに制限あるけどな。

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

2011/06/21(火) 01:46:41.72

コンパイル時インタプリタに相当するものを走らせないといけない最たる場面ってSFINAEじゃ？
constexprよりもSFINAEのほうが面倒見なければいけない範囲が圧倒的に広い

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

2011/06/21(火) 04:39:42.41

なにいってんだお前は。
SFINAEがなければ、単にコンパイルエラーになるだけだ。

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

2011/06/23(木) 01:16:19.03

substitution failure の判定にコンパイル時インタプリタ相当のものが必要になるのでは？
ただし計算しなければいけないのは syntax の受理・不受理だけになるとは思いますけれど．

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

2011/06/23(木) 09:52:14.40

コマンドの出力をそのままインクルードできれば簡単なのに

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

2011/06/23(木) 10:45:23.57

Makeでやれと言われそう

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

2011/06/23(木) 11:23:43.68

>>794
何のインタープリタと主張してますか?
C++のインタープリタじゃないですよね?

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

2011/06/23(木) 12:01:40.38

>>797
あー，インタプリタという言葉を使うのは完全にまずいですね．すいません．
C++ のメタコンパイラ（？）とでも呼べるような機構が
substitution failure の判定のために走っている，ぐらいの表現になるかと思います．

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

2011/06/23(木) 13:03:47.19

お前の独自用語だと、文法エラーや意味エラーを判定するのは全部メタコンパイラだな。

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

2011/06/23(木) 15:15:09.39

議論するなら使う単語の定義の認識合わせしないと

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

2011/06/23(木) 22:16:46.08

新しい言語には NullPointerException を言語レベルでサポートして欲しい
出るたびに「ぬるぽ」と口に出してほくそ笑むのに必要

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

2011/06/23(木) 23:35:22.23

throw nullptr;

胸が熱くなるな

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

2011/06/24(金) 04:38:01.65

void *でcatch出来るのかな

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

2011/06/24(金) 10:25:45.35

>>802
なんか違うような……

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

2011/06/24(金) 15:54:59.70

>>802
手が滑ってヌルッとウナギみたいにすり抜けそう

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

2011/06/24(金) 16:22:39.92

>>802
gatch

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

2011/06/24(金) 18:06:59.44

ぬるっと滑ったらぽっと落ちる

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

2011/06/24(金) 18:39:15.47

>>803

キーワード nullptr は、std::nullptr_t 型の prvalue だと定義されて
いるみたいです。（FDISの2.14.7、46頁参照）

なので、もし本当に nullptr を投げるつもりなら
try {
　　throw nullptr;
} catch ( std::nullptr_t e ) {
　　...
}
みたいな感じ？誰も投げないと思うけど。。

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

2011/06/24(金) 21:32:24.36

try {
　　throw nullptr;
} catch ( std::nullptr_t gatt ) {
　　...
}

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

2011/06/24(金) 22:38:39.79

捕まえても変数に対して出来ることが無いな
catch ( std::nullptr_t )

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

2011/06/24(金) 22:56:23.75

std::nullptr_tってクラスかもしれないだろ

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

2011/06/24(金) 23:32:40.18

nullptrを捕まえられれば本望

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

2011/06/25(土) 00:30:13.71

普通にそれで動くで

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

2011/06/25(土) 08:47:58.94

segvをキャッチしたいって話じゃなかったっけ……？

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

2011/06/25(土) 10:11:04.20

つまらない奴だな

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

2011/06/26(日) 14:01:29.91

unionに普通のクラスとか載せれる（コンストラクタは勝手に走らない）ようになったってことは
template <class Foo> union Bar { Foo foo; };
これだけでFooの為のアラインドストレージになるってこと？

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

2011/06/26(日) 14:13:58.68

unionはアラインの保証なんかしないぞ。
アラインされたストレージが欲しければ、そのまんまの名前のaligned_storageがある。
ちなみに、アラインされたunionが欲しければ、これまたそのまんまの名前のaligned_unionがある。
単にクラスや変数のアラインを指定したいならalignasを使え。

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

2011/06/26(日) 14:16:20.43

unionってすべてのメンバに対してアラインが取れてる仕様じゃなかったっけ？
0xで変更になったの？

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

2011/06/27(月) 00:24:29.93

ぬるぽっぽ

0820天使 ◆uL5esZLBSE

2011/07/02(土) 12:00:08.47

>>817
＞アラインされたストレージが欲しければ、そのまんまの名前のaligned_storageがある。
↑↑↑ハッアアアァアアア？？？？？？？？？？？

本当にバカだな
なんだ、ただのゴミか

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

2011/07/02(土) 12:04:17.05

>>818
で、これは結局どうなんですか？
このスレにはこんなことにも答えられない素人しかいないんですかね？
そんな人たちの一人が本を書こうとしてるなんて世も末ですね

0822デフォルトの名無しさん

2011/07/02(土) 12:12:30.56

夏休みはじまった

0823デフォルトの名無しさん

2011/07/02(土) 16:51:02.90

union A { std::string s; ... };
A a;

A は standard layout でないから、
(void*)&a != (void*)&a.s

(void*)&a.s は std::string のアラインを守っている必要があるけど
(void*)&a はどうなっててもいい。

これで満足かい？

0824デフォルトの名無しさん

2011/07/02(土) 17:28:26.25

番号も書かずに規格を語るな

0825デフォルトの名無しさん

2011/07/02(土) 18:19:46.87

最初からこんな所に頼らず
てめえで仕様読めよ

0826デフォルトの名無しさん

2011/07/02(土) 18:41:58.32

敗北宣言乙

0827デフォルトの名無しさん

2011/07/02(土) 18:51:21.83

脱北宣言に見えた

0828デフォルトの名無しさん

2011/07/02(土) 18:53:26.82

俺は脱糞宣言に見えた

0829デフォルトの名無しさん

2011/07/03(日) 01:29:39.32

0xってhash_setとhash_map入るんだっけ？
そうなると、そのhash_setとhash_mapのiteratorの扱いはどうなるの？

1.iteratorの順序は？
2.eraseした時、erase対象以外の要素を指してるiteratorは無効になるの？
　(hash tableは、要素を削除したとき、他の同一hashの要素で削除部分を埋める
　　実装が可能なため)

0830デフォルトの名無しさん

2011/07/03(日) 03:12:36.61

unorder_setとunorder_mapな
1. その名の通りbegin()からend()まで走れば全部舐めること以外は実装定義
2. ならない

0831デフォルトの名無しさん

2011/07/03(日) 03:17:40.19

てかそもそも削除できるのか？
どうやって対象の要素を空にする？

0832デフォルトの名無しさん

2011/07/03(日) 04:57:16.84

とりあえずhashをこんな感じで考えていたがアカンで。
iterato保証すると、追加と削除と探索が遅くなるで。

template<class Type> size_t Hash(const Type&);
template<class Type> class HashSet
{
std::vector<Type> array;
HashSet<Type> *table;
public:
class iterator;
HashSet(size_t size):table(size){}
virtual ~HashSet(void){delete table;}

iterator insert(Type &object)
{
size_t offset = Hash( object ) % table.size();

if( !array[ offset ] )
{
array[ offset ] = object;
}
else if( object != array[ offset ] )
{
if( table ) table = new Table();
table->insert( object );
}
return iterator(this);
}
//略
};

0833デフォルトの名無しさん

2011/07/03(日) 04:57:50.85

erase

0834デフォルトの名無しさん

2011/07/03(日) 05:33:09.06

普通vector<list<T>>じゃないの？

0835デフォルトの名無しさん

2011/07/03(日) 07:57:43.68

普通vector<set<T>>かvector<map<T>>だろ
listとかあほか

0836デフォルトの名無しさん

2011/07/03(日) 08:25:40.74

>>835
unorderの実装なのにsetやmap使ってどーすんだよ

0837デフォルトの名無しさん

2011/07/03(日) 08:34:20.03

え？

0838デフォルトの名無しさん

2011/07/03(日) 08:38:32.75

もうやだこいつ>>836
ハッシュテーブル使ってるからunorderedなんだろ

0839デフォルトの名無しさん

2011/07/03(日) 08:50:17.52

operator <(less<T>かも)を要求されないからunorderだろーが

0840デフォルトの名無しさん

2011/07/03(日) 08:52:32.38

アドレスの比較で十分

0841デフォルトの名無しさん

2011/07/03(日) 08:53:46.36

え？

0842デフォルトの名無しさん

2011/07/03(日) 08:54:38.02

>>840
それで実際にinsert書いてみろよ……

0843デフォルトの名無しさん

2011/07/03(日) 10:37:31.08

>>838
このスレはまだ早いのでは?

0844デフォルトの名無しさん

2011/07/03(日) 14:43:16.68

>>835
>>830を守れなくならないか？

0845デフォルトの名無しさん

2011/07/04(月) 07:21:54.11

右辺値参照が静的な参照カウントで実装されてるとすると
外部由来のポインタもってるクラスの扱いはどうなるんだろう？

0846デフォルトの名無しさん

2011/07/04(月) 07:34:06.24

>>844
どうして守れないと思うのかが分からない

0847デフォルトの名無しさん

2011/07/04(月) 08:38:54.37

右辺値参照を誤解してるみなさんへ
8.3.2-2
Lvalue references and rvalue references are distinct types. Except
where explicitly noted, they are semantically equivalent ...
　　左辺値参照と右辺値参照は違う型だが、
　　明示的に注釈される箇所を除いて、意味的には変わらない
意味的には変わらない。右辺値参照は左辺値参照とまったく同じ実装になる。

じゃあ明示的に注釈される違いとは何か。
8.5.3-5
(要約)
　　・lvalue は、左辺値参照を初期化できる
　　・xvalue と prvalue は const左辺値参照か、もしくは右辺値参照を初期化できる

では lvalue, xvalue, prvalue とは何か。
prvalue:
5.1.1-1
A string literal is an lvalue; all other literals are prvalues.
　　文字列リテラル以外のリテラルは、prvalue。
xvalue, lvalue:
5-6
(要約)
　　・戻り値が右辺値参照の関数を呼び出した結果は xvalue
　　・右辺値参照にキャストした結果は xvalue
　　つまり「無名の」右辺値参照は xvalue。
　　それ以外はすべて lvalue。
　　右辺値参照の変数は、変数名がついているのでもちろん lvalue

上記の部分をまず理解してからでないと
何を言っても意味不明だよ。

0848デフォルトの名無しさん

2011/07/04(月) 08:49:56.63

ばかにしないでくれる
そのくらい知ってるわよ

0849デフォルトの名無しさん

2011/07/04(月) 09:08:45.55

AA忘れてるぞ

0850デフォルトの名無しさん

2011/07/04(月) 09:55:26.57

内容は正しいけど投下するタイミングを完全に間違ってるな

0851847

2011/07/04(月) 17:16:32.26

>>850
>>845 みたいなのが相も変わらず湧いてくるので…

0852デフォルトの名無しさん

2011/07/04(月) 17:24:13.84

えぞえさんの記事張ればいいじゃん

0853デフォルトの名無しさん

2011/07/04(月) 18:50:51.84

本人じゃね

0854デフォルトの名無しさん

2011/07/04(月) 22:19:20.76

>>846
setやmapの要素は削除するとiterator無効になるじゃん。

0855デフォルトの名無しさん

2011/07/04(月) 22:38:34.83

そんな当たり前のこと言われても困りんす

0856デフォルトの名無しさん

2011/07/04(月) 23:04:43.64

>>854
はつみみです
木の実装から考えて、無効にするほうが難しいと思うが・・・

0857デフォルトの名無しさん

2011/07/04(月) 23:19:36.30

>>856
何を言ってるんだおまえは
試してみろよ

0858デフォルトの名無しさん

2011/07/05(火) 02:48:17.18

実物のunordered実装の一つではdeque<slist<T>>（相当）を使ってたな

0859デフォルトの名無しさん

2011/07/05(火) 02:58:00.88

>>856
回転とか二重回転でぐぐってみろよ
木の再構成がどんなに複雑な過程かよく分かるから

0860デフォルトの名無しさん

2011/07/05(火) 03:05:26.99

結局削除後のiteratorを保証するには、衝突をlist相当のものにするしか無いのか。
衝突の度にnewだろ、なんか遅そうだな。

0861デフォルトの名無しさん

2011/07/05(火) 03:07:58.93

http://ja.wikipedia.org/wiki/%E6%9C%A8%E3%81%AE%E5%9B%9E%E8%BB%A2

ここら辺がいいな
もちろん実装依存で、どの木構造を使っているかはソースを読まないと分からないが、
大抵平衡木(AVL木、赤黒木、スプレイ木)を使っていて、やっている事は大して差がない

0862デフォルトの名無しさん

2011/07/05(火) 03:36:20.67

何がsetやmapの要素は削除するとiterator無効になるからlistにしろだよ。
なわけねーだろ。最近レベル低いやつ多すぎ。

0863デフォルトの名無しさん

2011/07/05(火) 03:40:41.87

それとは別にわざわざunordered_mapでmapを使う意味もわからねーけど。

0864デフォルトの名無しさん

2011/07/05(火) 04:13:07.84

>>862
setやmapのイテレータの指す要素を削除すると確かにそのイテレータは
無効になるが、イテレータを削除前にインクリメントして次の要素を指すように
しておけばそのまま使える

例えば次の通り

const int N = 100;

int main()
{
std::set<int> si;

std::srand(static_cast<unsigned>(std::time(0)));

for (int i = 0; i < N; i++)
si.insert(std::rand());

std::set<int>::iterator pos = si.begin(), tmp;

while (true) {
tmp = ++pos;
if (tmp == si.end())
break;
if (*pos % 2) // 奇数
si.erase(pos);
pos = tmp;
}

std::copy(si.begin(), si.end(), std::ostream_iterator<int>(std::cout, " "));
std::cout << std::endl;
}

0865デフォルトの名無しさん

2011/07/05(火) 04:21:41.45

>>864
うんそのとおり。俺もそのつもりで書いてるんだけど何が言いたいの？

それとコードの肝心な所が間違ってるぞ。

0866デフォルトの名無しさん

2011/07/05(火) 04:55:47.48

iterator無効云々の話が関係あるのか？
unordered_mapの実装にmapが使えない理由は>>839だろ

0867デフォルトの名無しさん

2011/07/05(火) 05:18:11.54

>866
operator < が無くてもmapに入れようと思えば入れ子にすることで入る。ただ本当に何のメリットもなくなるけど。
そもそもunordered_map自体hashの衝突が多くなってきたらhash tableを拡張することで性能を維持しようとするので
backetにmapを使っても重いだけ。

0868デフォルトの名無しさん

2011/07/05(火) 05:28:18.12

mapを使用するメリットがあるくらいhash衝突が多いなら計算量はO(logN)になり、
unordered_mapの特徴であるO(1)のアクセスが出来ないことになる

0869デフォルトの名無しさん

2011/07/05(火) 05:32:08.70

でもmapを使ってもバランスの取れるところはあるか・・・
やっぱり>>839が理由なのか

0870デフォルトの名無しさん

2011/07/05(火) 05:32:11.03

>>867
>入れ子

ハッシュ値をキーにするとかそんなか

0871デフォルトの名無しさん

2011/07/05(火) 05:37:13.66

>>870
うん。
「何のメリットもなくなる」と書いたのは同じbacket内なら全部hash同じだと考えたんだけど
よく考えれば別のhash関数を噛ませればばらけてくれるのでそんなことは無かった。

0872デフォルトの名無しさん

2011/07/05(火) 05:41:47.39

ハッシュ関数2つ通して、しかも両方が衝突したときのためにmultimapにして最後はop =で……とか考えると
オーダーの定数項部分が洒落にならん気もするしメモリも喰うだろうしで
普通に一番外側のテーブルを大きめに取ったほうがいいだろうな

0873デフォルトの名無しさん

2011/07/05(火) 07:38:35.50

>>859
まさか、削除したiterator自身が無効になるぜとか言ってんのか・・・？
当たり前だろ
今問題になってんのは削除されなかった要素を指しているiteratorが無効になるかどうかだろ

0874デフォルトの名無しさん

2011/07/05(火) 07:40:59.74

ハッシュテーブル大きすぎてもメモリ食うし
たまたま衝突多かったらパフォーマンスがO(N)にだだ下がりってのもどうなのよ　＞list

0875デフォルトの名無しさん

2011/07/05(火) 07:47:21.61

つーてもハッシュ関数ふたつ用意させるぐらいなら
最初から1種類のハッシュ関数の質を高めろよって話だしなあ
何重にしたところで全部衝突する可能性が残る以上必ず末端はlistになるんだし

0876デフォルトの名無しさん

2011/07/05(火) 08:28:26.64

23.2.4-9
...and the erase members shall invalidate only iterators and
references to the erased elements.

とあるから、map のイテレータも、eraseした奴以外は有効のままだよ。

ただ、枝の付け替えを行うから
>>864 みたくすると多分走査漏れがあったり、
二重に走査してしまったりすると思う。

せっかく erase(q) は消去した次のメンバを返すのだから
それを利用したほうがいい。

0877デフォルトの名無しさん

2011/07/05(火) 09:02:54.14

規格上どうなってるか知らないけど素直に赤黒木を実装すれば走査漏れや二重走査は無いよ。
新しく挿入した要素が走査途中の要素より後ろにあれば走査されないけど。

0878デフォルトの名無しさん

2011/07/05(火) 10:44:03.59

>>877
木の構造が変わるから、左子ノードだけ操作したノードスタックが無効になり、
上位ノードに戻るのが容易ではない。

0879デフォルトの名無しさん

2011/07/05(火) 10:59:11.93

>>876
>>>864 みたくすると多分走査漏れがあったり、
>二重に走査してしまったりすると思う。

ちょっとこれ困るんですけど
eraseした先が無効になる以外は問題ないという事を前提にして
書かれたプログラムがたくさんある

0880デフォルトの名無しさん

2011/07/05(火) 11:35:24.08

C++0xが関係のない、かなり初歩的な事まで話題になり始めてるから、
アルゴリズムスレに移ったほうがいいと思う。

ちなみに並列安全なイタレータの分野では、C++はかなり遅れを取っています。
(捜査漏れがない、二重捜査しない、順序が狂わない、オーダなど)
やっぱりGCのある言語のほうがずっと簡単なんで。

0881876

2011/07/05(火) 14:46:02.84

>>877-879
すまん。確かに>>877の言う通りで、
map は「順序を保持した」木なのだから
枝を複雑に付け替えて木の構造が変わっても
あるノードの「次の」要素は絶対変わらない。

だから>>864は正しくて、>>876の俺のコメントは間違ってる。

0882デフォルトの名無しさん

2011/07/05(火) 21:07:51.98

>>874
ハッシュテーブルって元々そういうアルゴリズムだし。

0883デフォルトの名無しさん

2011/07/05(火) 21:12:10.06

STLportがスレッドセーフレベル2だったんだっけ

もう過去の遺物だけど

コンテナをスレッドセーフにしちゃうとVSみたいに標準関数が軒並み遅くなっちゃいそうだし
そのためにわざわざランタイムを2種類用意してたよな
VS10からは一本化されてしまったけど

0884デフォルトの名無しさん

2011/07/05(火) 21:40:21.40

一本化したのはVC8からなんだが

0885デフォルトの名無しさん

2011/07/05(火) 22:32:15.81

imcomplete type って何？
知ってる人教えてくだしあ

0886885

2011/07/05(火) 22:34:23.42

まちがえた。ごめんなさい
s/imcomplete/incomplete/

0887デフォルトの名無しさん

2011/07/06(水) 04:08:22.59

>>885
不完全型。宣言されているが定義されていない型のこと。
sizeofや実体化、コピー、派生、メンバや内部型へのアクセス等が出来ない。
関数宣言の引数・戻り値型やポインタの要素型、テンプレート引数に使う事は出来る。

0888885

2011/07/06(水) 19:38:36.39

>>887
分かりやすい解説、ありがとうございます。

ところで、新しい規格の話題で、最近スレが寂しい
そこで、ライブラリの使い方などのリクエストを受けて、無知ながらFDISを調べつつ
解説してみようと思うんだが、需要ある？

0889デフォルトの名無しさん

2011/07/06(水) 20:27:32.01

incomplete typeも自力で調べられない奴がか？

0890デフォルトの名無しさん

2011/07/06(水) 20:30:09.84

>>888
面白い冗談だ。

0891デフォルトの名無しさん

2011/07/06(水) 20:37:40.35

>>882
set/map使えば最悪でもO(logN)で済むじゃん？
ハッシュが被らない場合でも各バケツ内で要素を探すための比較はどうせ行われるのだし、
listにする利点なんて追加のコストがちょっと下がるくらいじゃん？

0892デフォルトの名無しさん

2011/07/06(水) 20:51:06.74

ふたつめのキーも被ったら結局O(N)になるじゃん？

0893デフォルトの名無しさん

2011/07/06(水) 20:51:11.40

削除コストも下がるよ。

0894デフォルトの名無しさん

2011/07/06(水) 21:36:46.13

比較できない要素型だったら内部でordered使ったらコンパイル出来ねーだろうがアホか死ね

0895デフォルトの名無しさん

2011/07/06(水) 22:59:31.50

>>871

0896デフォルトの名無しさん

2011/07/07(木) 03:34:52.95

採択までずっとこんな流れなのか

0897デフォルトの名無しさん

2011/07/07(木) 05:35:06.98

>>893
イテレータが既にあるならコスト下がるけど
なければ削除するノードを検索するのにO(N)かかるよ

0898デフォルトの名無しさん

2011/07/07(木) 07:03:21.53

>>894
比較できなかったらそもそも値取り出せないだろwww
list使おうが要素の探索は必要になるんだぞ

0899デフォルトの名無しさん

2011/07/07(木) 07:52:09.59

結局アクセスの最悪オーダーをO(logN)に抑えるにはoperator < が必須になる
operator < を要求しないunordered_mapで実現するのは不可能。

0900デフォルトの名無しさん

2011/07/07(木) 11:05:46.27

STLスレに行けよ

0901885

2011/07/07(木) 19:07:28.47

調べました。

3.9p5 で定義されています。incomplete type とは、
宣言されたが定義されないクラス型、
サイズ不明若しくは incomplete type の要素を持つ配列型、
又は void 型のこと。

具体例は 3.9p6 を参照して下さい：
class X; // この時点で X は不完全型

extern X* xp; // xp は不完全型へのポインタ
xp++; // ill-formed

struct X {}; // この時点で X は完全型

X x;
xp = &x; // OK

0902デフォルトの名無しさん

2011/07/07(木) 20:53:54.36

OKの位置が変

0903デフォルトの名無しさん

2011/07/10(日) 01:46:22.25

上のほうで2つ目のハッシュを使って云々ってレスがあるけど、
それなら1つの配列(vector)にオープンアドレス法使えよ、と思う。
もちろん、それだとstd::unordered_の要件を満たせるものは作れないだろうことは分かるけど。

0904デフォルトの名無しさん

2011/07/10(日) 01:52:28.99

スレ違いも甚だしいが、要求しないのは要件ではない。
unorderedは、orderがあってはいけないことを意味しない。
このくらい理解してないと次期規格どころの騒ぎじゃない。

0905デフォルトの名無しさん

2011/07/10(日) 09:14:24.84

そりゃあれば使ってもいいけどさ、結局渡されたキーにoperator<が無い版の処理は必要だろう？

0906デフォルトの名無しさん

2011/07/10(日) 11:04:06.41

あれば使う、なければ使わない、って、
コンセプトさん無くてもできるんだっけ？

0907デフォルトの名無しさん

2011/07/10(日) 11:11:22.56

テンプレート＋ADLあれば可能。
>>905が何を言いたいのかわからんが。

0908デフォルトの名無しさん

2011/07/10(日) 12:17:00.48

基本リストにして、ポリスィーでコンテナ切り替えで十分でしょ
まあどうせboost使うからstlにはそんなに期待しないでいい

0909デフォルトの名無しさん

2011/07/10(日) 12:18:22.21

不毛な議論が続いているような気がする
GCC のソース見ながら、１つずつ解釈していった方がずっと建設的では？

ttp://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html

23.2.5-1 に、最悪の場合に線形で、平均的にはそれよりずっと速い、
と書いてあるだけで、logN は見たことがない

それに、750頁の a_uniq.insert(t) も a_eq.insert(t) も同様になっている

一般的な二分探索の logN だけが、一人歩きしているような気がする
アルゴリズムと、今回の規格が混同されているのが、混乱の原因かと

23.5 をさらっと見てみたけど、どこにも operator< は無かったよ

0910デフォルトの名無しさん

2011/07/10(日) 14:30:10.09

STLスレに行けよw

0911デフォルトの名無しさん

2011/07/10(日) 14:51:48.65

unorderedだからC++0xでもいいんじゃね

0912デフォルトの名無しさん

2011/07/11(月) 18:58:55.41

>>907
std::unordered_map は、key の型に operator< が
定義されていなくても使えなくてはいけない。これは要求。

だから std::map が std::unordered_map の定義に紛れ込んではいけない

ということを>>904に向けて言ってるんじゃないの?

0913デフォルトの名無しさん

2011/07/11(月) 20:44:35.01

さらに言うと、 operator< が全順序でないといけない。
でも、テンプレートメタプログラミングでは < が定義されているかどうかは
分かっても、それが全順序かどうかを判別して実装を切り替えることができない。

なので、 unordered_map は全順序 < を要求するか、 < を一切利用しない実装に
しないといけない。

0914デフォルトの名無しさん

2011/07/12(火) 12:13:44.51

全順序じゃ無くてもどっちが大きいかランダムで返すってことでも良いはず

0915デフォルトの名無しさん

2011/07/12(火) 13:36:50.01

>>914
同じ引数に対してoperator<を適用するたびに結果が変わるならまともに順序があるとは言えない。
一意に定まるなら自動的に全順序が成り立つ。

問題は順序付きコンテナが必要とするoperator<の結果は全順序を満たす必要があるのに対し、
コンテナ要素の型Tが例えoperator<を持っていても、全順序である義務は無いということ。
例えばTがexpression templateをサポートしており、operator<はboolでは無い型を返すかもしれない。
そのようなオブジェクトがコンテナに入れられないとなると問題だろう。

0916デフォルトの名無しさん

2011/07/12(火) 13:56:31.62

>>913
> でも、テンプレートメタプログラミングでは < が定義されているかどうかは
> 分かっても、それが全順序かどうかを判別して実装を切り替えることができない。

現ライブラリでは、の間違い?

TotalOrdering<Op, T>で済む話だよね?
「テンプレートメタプログラミングでは」、
ライブラリ作成者が後から定義できるのが特徴。

Conceptでもっと使いやすくなるはずだったが…

0917デフォルトの名無しさん

2011/07/12(火) 17:00:47.42

>>915
たとえ一意でもoperator<をテキトーに決めたって全順序にはならんよ
推移律満たすとは限らないんだから

0918デフォルトの名無しさん

2011/07/12(火) 17:14:57.21

逆に言うと全順序じゃない物を並べられ無いと言うことになるけど
集合に全順序じゃない順序を入れて並べたいときはどうするんだ？

0919デフォルトの名無しさん

2011/07/12(火) 17:22:40.92

そんなのC++0xの話題なのか?
Strict weak orderingも知らん奴は初心者スレに行ってくれ。

0920デフォルトの名無しさん

2011/07/12(火) 17:33:01.28

やっぱりな全順序なんておかしいと思ってたよ。
Strict weak orderingで十分だとはうすうす思ってたんだよな。

0921デフォルトの名無しさん

2011/07/12(火) 17:33:07.04

>>917
operator<がboolをtrueとfalseでランダムに返すようにするか

0922デフォルトの名無しさん

2011/07/12(火) 17:48:51.66

いやいや、全順序（というか整列順序）自体は必要でしょ
begin()～end()の順番はとにかく決めないといけないんだし、同じコンテナのイテレータ同士が比較不能だなんて困る

0923デフォルトの名無しさん

2011/07/12(火) 18:01:22.21

トポロジカルソートもしらんのかいなﾔﾚﾔﾚ

0924デフォルトの名無しさん

2011/07/12(火) 18:54:26.54

スレ違いは他所でやれ

0925デフォルトの名無しさん

2011/07/12(火) 19:26:47.67

トロピカルリゾートくらい知ってるわな

0926デフォルトの名無しさん

2011/07/12(火) 19:54:27.93

トロピカルランドなら知ってるぜ

0927デフォルトの名無しさん

2011/07/12(火) 21:20:51.24

もうボゴソートでええやん

0928デフォルトの名無しさん

2011/07/12(火) 22:55:10.95

FDIS見てみたんだが、イテレータがコンテナの要素を走査する順序は、
23.2.5-6 により規格は指定していないみたい。

ただ、等値キーに対しては、隣り合った走査の順序になると

23.5.4.1-1、23.5.5.1-1、23.5.6.1-1及び23.5.7.1-1 にあるように
unordered_* は前進イテレータをサポートするんだってさ

0929デフォルトの名無しさん

2011/07/12(火) 22:56:22.43

なので、

0930デフォルトの名無しさん

2011/07/12(火) 23:01:13.80

うう、違うショートカットキーを押してしまった。。すみません

なので >>922 の言う begin()～end() の順番は、
処理系によってかなり変わる可能性もあると思う

最悪、hasher の返す size_t 型の値の順序でいいかと

0931デフォルトの名無しさん

2011/07/15(金) 16:26:58.17

std::vector<char> vec;
decltype(vec)::value_type value_type;

とするとVC++2010では構文エラーになります。

typedef decltype(vec) vec_type;
vec_type::value_type value_type;

とすると通ります。
言語仕様的に正しい振る舞いなのでしょうか?

0932デフォルトの名無しさん

2011/07/15(金) 18:39:13.90

typename decltype(vec)::value_typeってしてみ

0933デフォルトの名無しさん

2011/07/15(金) 18:59:36.46

decltype(vec)::value_type は割と後になってから可能になった仕様なので
VC10ではまだサポートされていない

だったと思う

0934デフォルトの名無しさん

2011/07/18(月) 19:18:01.59

VC++2010ってデフォルト生成のムーブコンストラクタって対応してないのかな。
それとも俺が何か勘違いしてる?

http://codepad.org/BvrfyFBE

0935デフォルトの名無しさん

2011/07/18(月) 19:29:55.36

してません

0936デフォルトの名無しさん

2011/07/18(月) 20:55:21.12

イニシャライザリストさんも動かなかったりするから、もうちょっと待ったほうがいいかも。

0937デフォルトの名無しさん

2011/07/18(月) 20:58:00.10

VC++はいつだってクソだから

0938デフォルトの名無しさん

2011/07/18(月) 21:03:31.35

VC++の0x拡張はお勉強以外でつかうなよ。

0939デフォルトの名無しさん

2011/07/18(月) 21:15:43.92

MSはドラフト段階で取り入れた場合、製品の下位互換優先してFIXしてしまう。
ような気がする

0940デフォルトの名無しさん

2011/07/18(月) 22:57:31.79

発売日考えてやれよ・・・

0941デフォルトの名無しさん

2011/07/18(月) 23:05:51.83

Windows開発はMinGW+MSYSで十分すぎる
0xの機能もたくさん使えて楽しいしオプションで切ることもできるのが嬉しい
VC++は中途半端だからOFFにしようとしたけどオプションが見当たらなかった

0942デフォルトの名無しさん

2011/07/19(火) 19:36:36.70

同時期のgccを考えると
明らかにVC++は・・・

0943デフォルトの名無しさん

2011/07/19(火) 19:38:59.81

そもそもVCはやる気なかったやん

0944デフォルトの名無しさん

2011/07/19(火) 20:04:11.26

あんな中途半端な対応なのにオプションで外すことも出来ないとかVCないわ

0945デフォルトの名無しさん

2011/07/19(火) 20:05:04.90

いやC++03はVC++の方が先行してた時もあったよ。

ただMicrosoftとしては、C++0x対応を出してもあまりメリットがない。
あれはあくまでもWindows開発環境用にあるのだから。
Herb Shutterとかいるから、内部的には既にあるのだろうけど。

0946デフォルトの名無しさん

2011/07/19(火) 20:36:55.75

CLIはもうやる気無いけど
C99ガン無視のVCが0xに対応しようとしたあたり
いくらか前向きなんじゃないのかね

0947デフォルトの名無しさん

2011/07/19(火) 21:03:45.44

時期バージョンではC++/CLIのインテリセンス復活させるって話だからやる気はそれなりにありそう

0948デフォルトの名無しさん

2011/07/19(火) 21:18:13.03

C++/CLIはC++じゃないし…
delegate（）と干渉してラムダさん使えないし…

0949デフォルトの名無しさん

2011/07/20(水) 00:01:03.28

VCはC++コンパイラだから、Cの変更には追随しないってスタンスなのかも。

0950デフォルトの名無しさん

2011/07/20(水) 01:50:33.09

C99って何のために存在するの？

0951デフォルトの名無しさん

2011/07/20(水) 04:41:07.44

いらんことしい
減量すべきときにメタボ化しやがった

0952デフォルトの名無しさん

2011/07/20(水) 09:23:58.92

Microsoft は C99 はスキップして C1X を実装するよ

0953デフォルトの名無しさん

2011/07/20(水) 10:23:29.48

C++0x*0.75ぐらいがちょうどいい

0954デフォルトの名無しさん

2011/07/20(水) 12:10:55.12

C++ + (C++0x - C++) * 0.2
くらいがいいな

0955デフォルトの名無しさん

2011/07/20(水) 15:02:56.55

C++0x はうんこすぎる
あんなの使うなら C と ML 使うわ

0956デフォルトの名無しさん

2011/07/20(水) 15:05:35.39

ＭＬｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

0957デフォルトの名無しさん

2011/07/20(水) 15:17:39.63

C99 の轍は踏まないで欲しいな

0958デフォルトの名無しさん

2011/07/20(水) 16:24:39.89

コンパイル時リフレクションが欲しいのう

0959デフォルトの名無しさん

2011/07/20(水) 17:22:46.03

C99は数値計算屋には重要。いい改正だった。

0960デフォルトの名無しさん

2011/07/20(水) 17:28:42.28

特定用途にシフトしたってことだな
返す返すも設計思想を曲げた愚かしいことだ

0961デフォルトの名無しさん

2011/07/20(水) 17:28:55.19

数値計算やってるけど、Fortranならともかくpure C使うメリットが分からないんだけど

0962デフォルトの名無しさん

2011/07/20(水) 17:31:12.81

俺も数値計算屋やってるけど、Fortran なんて新規に書きたくねぇ
restrict がある時点で C99 でもいいやってなった

0963デフォルトの名無しさん

2011/07/20(水) 17:38:44.59

狭い視野での最適化を神格化するやつ多いんだよな
とかくそういうのは FPGA とか苦手だったりするし
行列の計算がしたいだけなのに FORTRAN とかもう・・・

0964デフォルトの名無しさん

2011/07/20(水) 17:50:33.00

C89で出来る事が出来なくなったわけでなし、
特定用途にシフトしたってのは違うだろ

0965デフォルトの名無しさん

2011/07/20(水) 18:16:07.41

C89 でさえ完全サポートできない（できても非現実的な）環境があるのに
そっちを無法状態のまま放置した結果がこのざまだっつーの

0966デフォルトの名無しさん

2011/07/20(水) 18:20:38.66

実装の強制はできんだろ
そんなこともわからないとかアホなの？

0967デフォルトの名無しさん

2011/07/20(水) 18:20:56.62

C++03はC99の上位互換を目指すべきだった
Cと互換性の無いC++になんの価値があろうか
設計思想を曲げたのはC++のほうだな

0968デフォルトの名無しさん

2011/07/20(水) 18:24:41.90

>>967
その通り

0969デフォルトの名無しさん

2011/07/20(水) 18:28:30.49

C99もちょっとC++98に対する配慮が欲しかったな。
C++98に合わせた部分もあるんだけども。

まあ俺は気にせずに両方使ってるよ。

0970デフォルトの名無しさん

2011/07/20(水) 18:32:19.58

>>965
フリースタンディング環境って知ってる？

0971デフォルトの名無しさん

2011/07/20(水) 18:39:50.11

C99なんて無視しとけ

0972デフォルトの名無しさん

2011/07/20(水) 18:50:04.68

>>970
その質問、そっくりおまえに返す

0973デフォルトの名無しさん

2011/07/20(水) 19:01:05.40

C89のフリースタンディング環境をサポートできない処理系もあるだろうが、
そんなもんC99がどんな仕様だったところで同様にサポートできんだろ
どうすりゃ良かったって言うんだ？

0974デフォルトの名無しさん

2011/07/20(水) 19:10:27.86

>>973
話の流れ読んでるか？　# サポートという言葉が出てきているから見てはいるようだが
おまえの言ってる「C99 がどんな仕様」てのは、現状の C99 を前提とした循環論法だろ

0975デフォルトの名無しさん

2011/07/20(水) 19:13:46.19

>>974
現状のC99は無視して良いよ
どんな仕様だったら良かったのかと聞いている

0976デフォルトの名無しさん

2011/07/20(水) 19:15:02.57

boostの行列とfortranの行列計算どっちが速いの？

0977デフォルトの名無しさん

2011/07/20(水) 19:25:09.93

>>975
C89 のフリースタンディング環境をサポートできない環境の具体例を１つでも知っていれば
そんな愚問は出るわけがなさそうに思うが、そこまで教えてやる気はないよ

0978デフォルトの名無しさん

2011/07/20(水) 19:29:04.89

うざい

0979デフォルトの名無しさん

2011/07/20(水) 19:37:40.62

「そこまで教えてやる気はないよ」（ｷﾘｯ

0980デフォルトの名無しさん

2011/07/20(水) 20:54:15.38

>>976
大規模並列計算とかだとfortranじゃないかなあ

0981デフォルトの名無しさん

2011/07/20(水) 21:03:04.85

>>976
いくらboostでも関数を横断するベクトル命令の管理はできないからなぁ。
引数をベクトルに割り当てたりとか無理臭いし。

0982デフォルトの名無しさん

2011/07/20(水) 21:17:23.45

Boost.SIMDっていうのが入りそうだよ。中身知らないけど。

0983デフォルトの名無しさん

2011/07/20(水) 21:21:51.76

>>975
俺なら……もし、C89のフリースタンディング環境をC99でより制限的にしてもいいのなら、受理条件に「浮動小数点型を使用していない」を付け加えるかな
C風無法地帯言語環境には想像をはるかに上回るマジキチC環境もあったりするけどそういうのはCの適用範囲から外したほうがいいような気がする
そういうのには専用の制御言語があるしそっちのほうが楽

C99は各処理系でバラバラに存在してたものをまとめた機能はいいと思うんだけどね
_Boolと_Complexは間違いなくC99の癌だな。あれがなければもっと評価は高かったと思う

>>976
FORTRANコンパイラ(に入ってる行列ライブラリ)の出来による
IntelのFORTRANコンパイラ(に入ってるライブラリ) vs boost(ublas) とかならFORTRANのほうが速いよ

0984デフォルトの名無しさん

2011/07/20(水) 23:10:02.02

>>982
AVX使いまくりか
Intelから頼まれたのかな

0985デフォルトの名無しさん

2011/07/21(木) 01:08:12.64

IntelのFORTRAN環境って優秀だったのか
まあICCもそれなりに良い評判だし、完成度高いの？

0986デフォルトの名無しさん

2011/07/21(木) 01:11:24.89

もとはDECのコンパイラだった気がするよ

0987デフォルトの名無しさん

2011/07/21(木) 01:39:03.96

CとFORTRANの行列の一番の差は行が先か列が先かの違いだけだけど、
Cはよく知られているようにポインタのエイリアスの問題があって最適化が著しく
制限されて速度が落ちる

これを避けるためにC99で導入されたのがrestrictで、同じエイリアスではない
事をユーザーがコンパイラに知らせる事でFORTRANと同等の最適化が可能

ではC99が必須かと言うとVCにも__restrictがあったりするし微妙
メインフレームで使うならC99だろうけど
どうせライブラリなんてどっちでも動くように再コンパイルされてるし

禿がD&Eで言ってるけど「C++はFORTRANと速度を競うつもりはない」
ので適材適所だな

0988デフォルトの名無しさん

2011/07/21(木) 04:05:03.56

別にギリギリのところで手間のかかる勝負はしてくれなくてもいいけど、
restrictは既にC99で導入されてる機能なんだから取り入れてくれたって悪くないのにって思う

0989デフォルトの名無しさん

2011/07/21(木) 07:51:47.81

おまいらC++0ｘの話をしろよ

0990デフォルトの名無しさん

2011/07/21(木) 09:45:37.14

じゃあ、0x年代に出せよ。

0991デフォルトの名無しさん

2011/07/21(木) 13:51:48.54

予言
2012年12月に世界は滅亡の危機にさらされる
その時にC++0x計画は破棄される

0992デフォルトの名無しさん

2011/07/21(木) 16:17:28.40

滅亡しねーよ

0993デフォルトの名無しさん

2011/07/21(木) 16:30:52.01

世界が滅んでもC++は死なず

0994デフォルトの名無しさん

2011/07/21(木) 17:00:22.22

次スレ↓

0995デフォルトの名無しさん

2011/07/21(木) 18:26:29.01

0996デフォルトの名無しさん

2011/07/21(木) 18:27:02.19

まちごた

次スレ
C++0x 13
http://hibari.2ch.net/test/read.cgi/tech/1311240361/

0997デフォルトの名無しさん

2011/07/21(木) 19:19:45.25

u

0998デフォルトの名無しさん

2011/07/21(木) 19:20:03.86

m

0999デフォルトの名無しさん

2011/07/21(木) 19:20:28.06

e

1000デフォルトの名無しさん

2011/07/21(木) 19:30:07.06

無駄レス連投

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。