C++0x 12

こんなか？

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が欲しいって話か(汗

43 ：デフォルトの名無しさん：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;
}

44 ：デフォルトの名無しさん：2011/02/24(木) 23:10:21.92

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

baz(i) は？

45 ：デフォルトの名無しさん：2011/02/24(木) 23:22:25.87

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

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

46 ：デフォルトの名無しさん：2011/02/24(木) 23:23:30.25

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

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

47 ：デフォルトの名無しさん：2011/02/24(木) 23:29:36.61

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

48 ：デフォルトの名無しさん：2011/02/25(金) 01:50:33.54

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

49 ：デフォルトの名無しさん：2011/02/25(金) 02:16:33.37

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

50 ：デフォルトの名無しさん：2011/02/25(金) 06:16:03.01

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

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

51 ：デフォルトの名無しさん：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

52 ：デフォルトの名無しさん：2011/02/25(金) 18:52:30.31

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

53 ：デフォルトの名無しさん：2011/02/25(金) 19:18:57.50

>>52
そうだね

54 ：デフォルトの名無しさん：2011/02/25(金) 19:39:18.82

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

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

55 ：デフォルトの名無しさん：2011/02/25(金) 20:21:06.15

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

56 ：デフォルトの名無しさん：2011/02/25(金) 20:26:28.86

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

57 ：デフォルトの名無しさん：2011/02/25(金) 20:30:21.06

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

58 ：デフォルトの名無しさん：2011/02/25(金) 23:49:09.51

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

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

59 ：デフォルトの名無しさん：2011/02/26(土) 00:33:42.71

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

60 ：デフォルトの名無しさん：2011/02/26(土) 01:24:09.25

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

61 ：デフォルトの名無しさん：2011/02/26(土) 02:30:00.71

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

62 ：デフォルトの名無しさん：2011/02/26(土) 02:50:09.24

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

63 ：デフォルトの名無しさん：2011/02/26(土) 03:49:41.58

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

64 ：デフォルトの名無しさん：2011/02/26(土) 05:40:13.63

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

65 ：デフォルトの名無しさん：2011/02/26(土) 05:44:20.78

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

66 ：デフォルトの名無しさん：2011/02/27(日) 01:50:12.67

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

67 ：デフォルトの名無しさん：2011/02/27(日) 19:30:53.14

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

意見求む。

68 ：デフォルトの名無しさん：2011/02/27(日) 19:51:14.58

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

69 ：デフォルトの名無しさん：2011/02/27(日) 20:00:26.49

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

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

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

70 ：デフォルトの名無しさん：2011/02/27(日) 20:17:53.39

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

71 ：デフォルトの名無しさん：2011/02/27(日) 20:35:03.88

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

72 ：デフォルトの名無しさん：2011/02/27(日) 21:45:45.05

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

73 ：デフォルトの名無しさん：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 ) { ...

のような記述もあり＾＾

74 ：デフォルトの名無しさん：2011/02/27(日) 22:51:24.70

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

75 ：デフォルトの名無しさん：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でもなんでもそれに使える機能がある時点で恵まれてるじゃないか……。

76 ：デフォルトの名無しさん：2011/02/27(日) 23:51:33.69

range_traitsを使う案2が好み

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

77 ：デフォルトの名無しさん：2011/02/27(日) 23:54:00.07

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

78 ：デフォルトの名無しさん：2011/02/28(月) 00:14:23.29

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

79 ：デフォルトの名無しさん：2011/02/28(月) 00:20:16.43

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

80 ：デフォルトの名無しさん：2011/02/28(月) 00:32:06.41

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

81 ：デフォルトの名無しさん：2011/02/28(月) 00:34:03.53

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

82 ：デフォルトの名無しさん：2011/02/28(月) 07:44:07.67

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

83 ：デフォルトの名無しさん：2011/02/28(月) 09:57:54.99

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

84 ：デフォルトの名無しさん：2011/02/28(月) 23:07:21.55

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

85 ：デフォルトの名無しさん：2011/02/28(月) 23:09:50.15

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

86 ：デフォルトの名無しさん：2011/02/28(月) 23:10:04.16

>>84
Adaptor 使えばいける

87 ：デフォルトの名無しさん：2011/02/28(月) 23:21:37.54

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

88 ：デフォルトの名無しさん：2011/03/01(火) 00:17:58.41

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

89 ：デフォルトの名無しさん：2011/03/01(火) 00:29:51.89

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

90 ：デフォルトの名無しさん：2011/03/01(火) 01:17:58.56

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

91 ：デフォルトの名無しさん：2011/03/01(火) 01:26:45.24

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

92 ：デフォルトの名無しさん：2011/03/01(火) 04:35:40.36

ttp://codepad.org/wxbJmLE7

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

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

93 ：デフォルトの名無しさん：2011/03/01(火) 04:40:45.07

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

94 ：デフォルトの名無しさん：2011/03/01(火) 05:43:29.88

ideone.com使えばいいじゃん

95 ：デフォルトの名無しさん：2011/03/01(火) 07:03:27.08

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

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

http://ideone.com/sHUiZ

96 ：デフォルトの名無しさん：2011/03/01(火) 12:54:33.07

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

97 ：デフォルトの名無しさん：2011/03/01(火) 14:14:45.33

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

98 ：92：2011/03/01(火) 15:35:15.94

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

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

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

99 ：デフォルトの名無しさん：2011/03/01(火) 18:38:43.21

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

100 ：デフォルトの名無しさん：2011/03/01(火) 20:19:31.08

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

101 ：デフォルトの名無しさん：2011/03/02(水) 01:55:43.32

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

まあいいや

102 ：デフォルトの名無しさん：2011/03/02(水) 02:59:57.14

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

103 ：デフォルトの名無しさん：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

104 ：デフォルトの名無しさん：2011/03/02(水) 18:24:27.87

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

105 ：デフォルトの名無しさん：2011/03/02(水) 18:55:19.24

range-based for の話は n3257 か

106 ：デフォルトの名無しさん：2011/03/02(水) 19:01:52.81

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

http://codepad.org/8k47jk4t

107 ：デフォルトの名無しさん：2011/03/02(水) 20:42:22.25

テンプレートマラメータ

108 ：デフォルトの名無しさん：2011/03/02(水) 23:44:51.52

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

http://codepad.org/ckzgITKY

109 ：デフォルトの名無しさん：2011/03/03(木) 00:13:21.61

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

110 ：デフォルトの名無しさん：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はもともとテンプレートがまともに動かないことが周知されてるんでいいんだけど。

111 ：デフォルトの名無しさん：2011/03/03(木) 00:40:10.29

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

112 ：デフォルトの名無しさん：2011/03/03(木) 00:50:06.00

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

VC++2010 Express 32bit版
10.0.30319.1 RTMRel

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

113 ：デフォルトの名無しさん：2011/03/03(木) 01:13:01.89

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

114 ：デフォルトの名無しさん：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 をインクルードしたらエラーが大量にｗ

115 ：デフォルトの名無しさん：2011/03/03(木) 02:25:15.69

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

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

116 ：デフォルトの名無しさん：2011/03/03(木) 02:28:55.25

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

117 ：デフォルトの名無しさん：2011/03/03(木) 02:37:47.16

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

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

118 ：デフォルトの名無しさん：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; と同義の方が良いのではないか？

119 ：デフォルトの名無しさん：2011/03/03(木) 06:45:47.31

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

120 ：デフォルトの名無しさん：2011/03/03(木) 06:49:40.73

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

121 ：デフォルトの名無しさん：2011/03/03(木) 06:57:31.58

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

122 ：デフォルトの名無しさん：2011/03/03(木) 07:27:52.12

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

123 ：デフォルトの名無しさん：2011/03/03(木) 07:56:52.96

int long unsigned const long *oops;

124 ：デフォルトの名無しさん：2011/03/03(木) 12:21:21.71

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

125 ：デフォルトの名無しさん：2011/03/03(木) 12:38:36.16

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

126 ：デフォルトの名無しさん：2011/03/03(木) 18:17:00.31

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

127 ：デフォルトの名無しさん：2011/03/04(金) 01:15:37.06

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

128 ：デフォルトの名無しさん：2011/03/04(金) 01:46:27.01

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

129 ：128：2011/03/04(金) 01:47:45.34

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

130 ：デフォルトの名無しさん：2011/03/04(金) 07:11:22.00

＼（＾o＾）／

131 ：デフォルトの名無しさん：2011/03/04(金) 09:25:00.28

突然声優スレに

132 ：デフォルトの名無しさん：2011/03/04(金) 14:43:11.25

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

133 ：デフォルトの名無しさん：2011/03/05(土) 11:36:40.49

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

134 ：デフォルトの名無しさん：2011/03/05(土) 11:58:34.50

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

135 ：133：2011/03/05(土) 12:05:47.74

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

136 ：133：2011/03/05(土) 12:16:31.99

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

137 ：デフォルトの名無しさん：2011/03/05(土) 12:18:21.38

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

138 ：デフォルトの名無しさん：2011/03/05(土) 12:19:22.68

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

139 ：デフォルトの名無しさん：2011/03/05(土) 12:42:09.62

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

140 ：デフォルトの名無しさん：2011/03/05(土) 12:49:27.12

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

141 ：デフォルトの名無しさん：2011/03/05(土) 12:50:10.22

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

142 ：133：2011/03/05(土) 12:54:55.47

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

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

143 ：デフォルトの名無しさん：2011/03/05(土) 16:58:36.47

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

144 ：デフォルトの名無しさん：2011/03/05(土) 18:17:01.20

>>140
今時.hかよ。

145 ：デフォルトの名無しさん：2011/03/05(土) 19:13:54.70

すぐ下を読んでやれよ

146 ：デフォルトの名無しさん：2011/03/05(土) 19:14:32.13

いやです！

147 ：デフォルトの名無しさん：2011/03/05(土) 19:41:26.48

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

148 ：デフォルトの名無しさん：2011/03/05(土) 20:15:17.27

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

149 ：デフォルトの名無しさん：2011/03/05(土) 20:28:18.64

\\\\

150 ：デフォルトの名無しさん：2011/03/05(土) 20:30:19.09

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

151 ：デフォルトの名無しさん：2011/03/05(土) 21:19:56.39

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

152 ：デフォルトの名無しさん：2011/03/05(土) 21:34:57.93

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

153 ：デフォルトの名無しさん：2011/03/05(土) 21:59:48.71

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

154 ：デフォルトの名無しさん：2011/03/05(土) 22:01:38.04

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

155 ：デフォルトの名無しさん：2011/03/05(土) 22:31:30.23

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

156 ：デフォルトの名無しさん：2011/03/05(土) 22:39:18.21

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

157 ：デフォルトの名無しさん：2011/03/05(土) 22:50:11.87

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

158 ：デフォルトの名無しさん：2011/03/05(土) 23:01:23.40

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

159 ：デフォルトの名無しさん：2011/03/05(土) 23:03:13.44

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

160 ：デフォルトの名無しさん：2011/03/06(日) 00:43:51.02

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

161 ：デフォルトの名無しさん：2011/03/06(日) 01:01:40.16

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

162 ：デフォルトの名無しさん：2011/03/06(日) 01:01:58.63

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

163 ：デフォルトの名無しさん：2011/03/06(日) 05:35:59.77

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

164 ：デフォルトの名無しさん：2011/03/06(日) 06:26:28.55

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

165 ：デフォルトの名無しさん：2011/03/06(日) 06:27:13.22

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

166 ：デフォルトの名無しさん：2011/03/06(日) 07:03:38.86

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

167 ：デフォルトの名無しさん：2011/03/06(日) 07:14:32.45

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

168 ：デフォルトの名無しさん：2011/03/06(日) 09:26:55.62

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

169 ：デフォルトの名無しさん：2011/03/06(日) 11:18:53.14

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

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

170 ：デフォルトの名無しさん：2011/03/06(日) 15:27:49.99

0xf年に間に合うの？

171 ：デフォルトの名無しさん：2011/03/06(日) 15:54:20.38

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

172 ：デフォルトの名無しさん：2011/03/06(日) 18:01:19.94

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

173 ：デフォルトの名無しさん：2011/03/06(日) 18:02:52.15

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

174 ：デフォルトの名無しさん：2011/03/06(日) 20:58:23.62

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

175 ：デフォルトの名無しさん：2011/03/06(日) 21:42:57.99

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

176 ：デフォルトの名無しさん：2011/03/07(月) 07:19:18.51

C++0x10

177 ：デフォルトの名無しさん：2011/03/08(火) 14:50:04.39

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

178 ：デフォルトの名無しさん：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;
}

179 ：デフォルトの名無しさん：2011/03/10(木) 07:05:17.76

親？

180 ：デフォルトの名無しさん：2011/03/10(木) 09:10:49.62

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

181 ：デフォルトの名無しさん：2011/03/10(木) 20:01:00.38

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

182 ：デフォルトの名無しさん：2011/03/10(木) 20:33:55.36

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

183 ：デフォルトの名無しさん：2011/03/10(木) 20:40:49.20

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

184 ：デフォルトの名無しさん：2011/03/10(木) 20:49:30.88

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

185 ：デフォルトの名無しさん：2011/03/10(木) 20:56:17.19

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

186 ：デフォルトの名無しさん：2011/03/10(木) 22:33:43.62

いや全然

187 ：parent：2011/03/10(木) 23:30:06.43

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

188 ：デフォルトの名無しさん：2011/03/10(木) 23:52:15.19

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

189 ：デフォルトの名無しさん：2011/03/11(金) 03:46:32.36

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

190 ：デフォルトの名無しさん：2011/03/21(月) 00:30:47.77

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

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

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

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

191 ：デフォルトの名無しさん：2011/03/21(月) 01:22:48.47

行を空ける奴、キモイ

192 ：デフォルトの名無しさん：2011/03/21(月) 01:30:06.45

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

193 ：デフォルトの名無しさん：2011/03/21(月) 01:37:53.14

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

194 ：デフォルトの名無しさん：2011/03/21(月) 07:39:30.32

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

195 ：デフォルトの名無しさん：2011/03/21(月) 11:55:28.98

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

196 ：デフォルトの名無しさん：2011/03/21(月) 12:03:15.15

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

197 ：デフォルトの名無しさん：2011/03/21(月) 12:30:32.00

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

198 ：デフォルトの名無しさん：2011/03/21(月) 13:16:34.88

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

199 ：デフォルトの名無しさん：2011/03/21(月) 13:58:46.79

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

200 ：デフォルトの名無しさん：2011/03/21(月) 14:31:51.68

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

201 ：デフォルトの名無しさん：2011/03/21(月) 14:38:22.91

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

202 ：デフォルトの名無しさん：2011/03/21(月) 14:52:40.20

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

203 ：デフォルトの名無しさん：2011/03/21(月) 15:27:03.37

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

204 ：デフォルトの名無しさん：2011/03/21(月) 16:07:41.32

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

205 ：デフォルトの名無しさん：2011/03/21(月) 16:15:07.56

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

206 ：デフォルトの名無しさん：2011/03/21(月) 17:01:37.80

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

207 ：デフォルトの名無しさん：2011/03/21(月) 17:07:45.93

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

208 ：デフォルトの名無しさん：2011/03/21(月) 19:38:50.89

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

209 ：デフォルトの名無しさん：2011/03/21(月) 20:01:19.92

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

210 ：デフォルトの名無しさん：2011/03/22(火) 19:51:52.07

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

211 ：デフォルトの名無しさん：2011/03/22(火) 19:54:24.78

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

212 ：210：2011/03/22(火) 19:57:59.36

なるほどね～

213 ：デフォルトの名無しさん：2011/03/22(火) 20:56:19.33

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

214 ：デフォルトの名無しさん：2011/03/22(火) 21:04:20.81

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

215 ：デフォルトの名無しさん：2011/03/22(火) 21:06:57.01

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

216 ：デフォルトの名無しさん：2011/03/22(火) 21:24:17.64

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

217 ：デフォルトの名無しさん：2011/03/22(火) 21:34:12.25

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

218 ：デフォルトの名無しさん：2011/03/23(水) 23:48:41.48

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

219 ：デフォルトの名無しさん：2011/03/24(木) 17:36:47.33

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

220 ：デフォルトの名無しさん：2011/03/24(木) 18:04:31.41

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

221 ：デフォルトの名無しさん：2011/03/24(木) 19:51:07.94

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

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

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

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

222 ：デフォルトの名無しさん：2011/03/24(木) 20:06:32.81

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

223 ：デフォルトの名無しさん：2011/03/24(木) 20:12:34.83

3.6.2 Initialization of non-local variables

224 ：デフォルトの名無しさん：2011/03/24(木) 21:26:41.54

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

225 ：デフォルトの名無しさん：2011/03/24(木) 22:50:48.70

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

226 ：221：2011/03/25(金) 21:08:59.20

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

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

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

意味が

227 ：デフォルトの名無しさん：2011/03/26(土) 01:46:11.23

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

228 ：デフォルトの名無しさん：2011/03/26(土) 02:20:47.32

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

229 ：デフォルトの名無しさん：2011/03/26(土) 02:38:39.04

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

230 ：デフォルトの名無しさん：2011/03/26(土) 02:41:22.75

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

231 ：デフォルトの名無しさん：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/

232 ：デフォルトの名無しさん：2011/03/26(土) 16:55:01.10

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

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

233 ：デフォルトの名無しさん：2011/03/26(土) 18:21:18.02

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

234 ：デフォルトの名無しさん：2011/03/26(土) 18:55:59.34

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

235 ：デフォルトの名無しさん：2011/03/26(土) 19:35:55.70

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

236 ：デフォルトの名無しさん：2011/03/26(土) 20:25:46.38

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

237 ：デフォルトの名無しさん：2011/03/27(日) 00:42:10.56

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

238 ：デフォルトの名無しさん：2011/03/27(日) 01:21:55.32

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

239 ：デフォルトの名無しさん：2011/03/27(日) 03:28:04.78

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

240 ：デフォルトの名無しさん：2011/03/27(日) 04:49:25.07

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

241 ：デフォルトの名無しさん：2011/03/27(日) 09:04:35.76

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

242 ：デフォルトの名無しさん：2011/03/27(日) 11:54:11.47

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

243 ：デフォルトの名無しさん：2011/03/27(日) 14:02:22.70

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

244 ：デフォルトの名無しさん：2011/03/27(日) 14:04:11.04

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

245 ：デフォルトの名無しさん：2011/03/27(日) 14:46:19.37

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

246 ：デフォルトの名無しさん：2011/03/27(日) 15:54:26.58

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

247 ：デフォルトの名無しさん：2011/03/27(日) 20:41:40.63

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

248 ：デフォルトの名無しさん：2011/03/27(日) 22:47:56.48

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

249 ：デフォルトの名無しさん：2011/03/28(月) 00:22:42.42

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

250 ：デフォルトの名無しさん：2011/03/28(月) 00:31:48.97

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

251 ：デフォルトの名無しさん：2011/03/28(月) 11:33:50.71

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

252 ：デフォルトの名無しさん：2011/03/28(月) 13:09:12.59

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

253 ：デフォルトの名無しさん：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/

254 ：デフォルトの名無しさん：2011/03/28(月) 16:04:58.77

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

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

255 ：デフォルトの名無しさん：2011/03/28(月) 21:31:39.44

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

256 ：デフォルトの名無しさん：2011/03/29(火) 21:17:01.30

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

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

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

257 ：デフォルトの名無しさん：2011/03/29(火) 21:20:06.35

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

258 ：デフォルトの名無しさん：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),...

259 ：デフォルトの名無しさん：2011/03/29(火) 22:29:10.47

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

260 ：デフォルトの名無しさん：2011/03/29(火) 23:15:10.87

今回はなしでも良かったけどな。

261 ：デフォルトの名無しさん：2011/04/11(月) 12:27:21.01

void c(int && a)
int a;
int b&& =a;
c(a);
の３行目と４行目がエラーになるんですけど
おかしくないですか？
&&はconst以外なんでも束縛するってよんだのですけど。

262 ：デフォルトの名無しさん：2011/04/11(月) 13:51:31.83

>>261
とりあえず３行目は文法エラーだよね？
実際のコードと使ったコンパイラとエラーメッセージと「よんだ」もののURLを正確に貼るといいよ。

263 ：デフォルトの名無しさん：2011/04/11(月) 13:54:37.99

void c(int && a)
int a;
int&& b =a;
c(a);
すみません許してください。
初歩的なミスで文法間違えました。
それでも駄目でしたよ。
move(a)にするとできましたよ。
TDMのGCCをつかいましたよ。
コマンドラインにも0xを使うやつをつけましたよ。

264 ：デフォルトの名無しさん：2011/04/11(月) 14:02:44.29

aは左辺値なんだから当たり前だろ
c(b)なら通るだろうけど

265 ：デフォルトの名無しさん：2011/04/11(月) 14:04:02.97

bでも無理だわスマソ

266 ：デフォルトの名無しさん：2011/04/11(月) 14:08:07.41

一応ソースも張っておきますね。
http://d.hatena.ne.jp/ntnek/20090210/p1
＞更新可能な右辺値参照 Type&& は更新可能な左辺値や更新可能な右辺値を束縛する。
＞しかし、const な左辺値や const な右辺値は（const の一貫性に違反するので）束縛しない。

267 ：デフォルトの名無しさん：2011/04/11(月) 14:29:22.37

>>266
それちょっと古くないか
右辺値参照は右辺値しかとらないようになったよ
ttp://slashdot.jp/~taro-nishino/journal/507551
＞ノート：貴方が、オーバロードvoid foo(X&);を与えないで、void foo(X&&);を実装しているとせよ。
のあたり

268 ：デフォルトの名無しさん：2011/04/11(月) 14:34:03.29

なんでそこでaを右辺値だと勘違いするのかね

269 ：デフォルトの名無しさん：2011/04/11(月) 14:42:28.68

>>267
知りませんでした。
ということは完全転送ってやつはどうなったのか調べてみますね。

270 ：デフォルトの名無しさん：2011/04/11(月) 14:58:16.30

>>267の完全転送は右辺値参照が左辺値もとるやり方で書いてありますね。
一関数で書く書き方はもう無理っぽいですね。

271 ：デフォルトの名無しさん：2011/04/11(月) 15:41:10.80

完全転送ってテンプレートの話でしょ？

272 ：デフォルトの名無しさん：2011/04/11(月) 15:44:54.10

テンプレートでやってみて出来なかったから
intで実験しても出来なかったから質問したので
テンプレートで出来ないのはとうぜんでしょ？

273 ：デフォルトの名無しさん：2011/04/11(月) 15:46:55.14

俺がやったのは
template <typename T>
void c(T&& a, const T& b){}
って関数だけど完全転送と一緒だろ？

274 ：デフォルトの名無しさん：2011/04/11(月) 17:01:01.95

なんか聞きたいことがよく分かんないな……

>>273
完全か完全でないかはさておき
とりあえず転送しろよｗ

/.の記事は初めて見たけど完全転送に関しては十分に書かれてると思うけどな
とりあえずstd::forward使っていろいろ試してみれば？
std::forwardは関数テンプレート1つで書かれてるよ

275 ：デフォルトの名無しさん：2011/04/11(月) 18:04:26.40

もしかして完全転送のやつってテンプレートのインスタンス化の仕組みなのか？それなら
273のやつは違うエラーだな。

276 ：デフォルトの名無しさん：2011/04/11(月) 18:56:43.26

誰が誰だかわからねえ。質問者は名前欄になんかいれとけよ。

277 ：デフォルトの名無しさん：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段落の最後の例も参照)

278 ：277：2011/04/12(火) 12:52:10.71

>>263 は a も b も lvalue だから (b は名前付き右辺値参照 = lvalue)
c(a) も c(b) も当然エラーになる。

279 ：質問者：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&&に束縛したときどうしたらいいですか？

280 ：デフォルトの名無しさん：2011/04/12(火) 15:50:49.36

>>279
template<typename T>
void d(T &&a, const typename std::remove_reference<T>::type &b) { }

あとC++の前にその日本語なんとかして

281 ：デフォルトの名無しさん：2011/04/12(火) 16:24:40.27

Tが直接に型に使われなければTは&Tなるからそれは上手くいくということですよね？
この理解であってますか？
ありがとうございます。

282 ：デフォルトの名無しさん：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 みたくしないとダメみたい。

283 ：デフォルトの名無しさん：2011/04/12(火) 16:32:29.03

>>280
の第二の変数は参照じゃなくてconst T型だからコピーになって駄目ですね。

284 ：デフォルトの名無しさん：2011/04/12(火) 16:42:21.29

>>282説が正しそうだな。
エラーを見るとint &とint &になってたからな。

285 ：デフォルトの名無しさん：2011/04/12(火) 16:43:26.67

良く見ると、280には&が付いてるからあってるな。
俺が間違ってたな。

286 ：デフォルトの名無しさん：2011/04/12(火) 19:06:59.90

お前誰だよ

287 ：デフォルトの名無しさん：2011/04/12(火) 23:02:12.45

なんでこの板IDないんだ…

288 ：デフォルトの名無しさん：2011/04/13(水) 17:37:11.34

というか、本来はIDなんて無いのが2chだよ、何せ「匿名掲示板」だからな
投稿者を識別する必要がある板には付いてる、というだけ
ム板は常に投稿者を識別する必要はないだろ？
必要なときに自分のレス番を示せばいいだけだから、つけていない

289 ：デフォルトの名無しさん：2011/04/13(水) 20:01:34.21

そもそもこのような過疎板では、一人が一日に何度も書き込むことが少ないから、 ID は大した効果がない。
誰の書き込みか分からないと伝わりにくい書き込みは名前欄にレス番を入れるべきだし、そうしないのはコミュニケーションスキルが低いというべきだろう。

290 ：デフォルトの名無しさん：2011/04/13(水) 20:38:06.34

プログラマー的に考えて、掲示板のほうでID出すことで楽ができるならそうしたいだろう

291 ：デフォルトの名無しさん：2011/04/13(水) 21:20:13.23

直球でお尋ねする。
IDを出すと楽なのか？

292 ：デフォルトの名無しさん：2011/04/13(水) 23:19:20.82

んー、楽かどうかは怪しいが、議論がこんがらがったときの助けにはなるなあ。
もっとも、自分が参加してない議論はこんがらがってたら最初から読み飛ばすけど

293 ：デフォルトの名無しさん：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 。

294 ：デフォルトの名無しさん：2011/04/14(木) 12:48:53.76

member name checking組のnewさんとexplicitさんが退学処分になってしまった。
逆に、constexprちゃんは見違えるように優等生になった。

295 ：デフォルトの名無しさん：2011/04/15(金) 22:06:24.57

ユーザー定義リテラルさんがFDISまで生き残ってしまった…

入れる以上はchronoとかのリテラルも用意すべきだったし
char32_tとかもわざわざ予約語や組み込み型せずにライブラリで済んだはずなのに
整合性がろくに議論されてない感がプンプンする
どうしてこうなった

296 ：デフォルトの名無しさん：2011/04/15(金) 22:17:36.14

u8, u, Uの特別扱いはそんな悪くない選択だと思いますが。

297 ：デフォルトの名無しさん：2011/04/15(金) 22:25:20.95

悪くないのかもしれないけど、そもそも比較の議論すらされてないように見えるんだよな
見えない所でしてるのかもしれないけどさ

298 ：デフォルトの名無しさん：2011/04/15(金) 22:35:58.50

「ソースコードの文字コードが○×だから、
mbcsが○×になっていて、UTF-32にするにはiconvして～」って、
ソースコードの事情を考えないといけないところが、
コンパイル時に全て解決するのだから、すごくいい判断。
operator ""に任せると、ソースコードの事情を実行時まで持ち込むことになる。

Unicodeが普及してない頃は、文字コード中立な設計で、
もろもろ実行時まで持ち込むのは仕方のないことだったけど。

299 ：デフォルトの名無しさん：2011/04/15(金) 22:59:20.85

operator""だってconstexprにすればコンパイル時判断できるんじゃないの？

300 ：デフォルトの名無しさん：2011/04/15(金) 23:19:29.83

constexprは、
> 「ソースコードの文字コードが○×だから、
がいやらしいね。
Non-constexprを引数に使われた時は、
実行時に同じ事やらないといけないから、
gccの-finput-encoding=に相当する情報を
実行時まで持ち運ばないといけない。

301 ：デフォルトの名無しさん：2011/04/16(土) 01:50:04.41

>>300
コンパイル時計算のほうを exec charset でやれば済む話じゃないの？

302 ：デフォルトの名無しさん：2011/04/16(土) 02:12:21.39

ワイド文字(wchar_t)は文字コードを限定しないので曖昧すぎて使いにくい
煩わしい環境依存が減ってC++標準でunicodeが扱えるようになることは一応良いと思う

303 ：デフォルトの名無しさん：2011/04/16(土) 12:12:50.20

>>301
exec charsetはiconvの変換先。

304 ：デフォルトの名無しさん：2011/04/16(土) 12:56:56.94

>>303
だから何？

305 ：デフォルトの名無しさん：2011/04/16(土) 21:39:52.69

お前らって、どのコンパイラーでC++0xしてんだ？

306 ：デフォルトの名無しさん：2011/04/16(土) 21:48:54.37

gcc

307 ：デフォルトの名無しさん：2011/04/16(土) 22:06:24.83

次のVCが出るまでは使わないな。

308 ：デフォルトの名無しさん：2011/04/17(日) 07:55:29.75

今のVCのC++0xは中途半端すぎて使えない

309 ：デフォルトの名無しさん：2011/04/17(日) 18:36:09.63

VCだと、ラムダさんとautoさんしかつかってないなー。
スマートポインタ系もたまに使うか？？って感じ。

310 ：デフォルトの名無しさん：2011/04/18(月) 07:27:15.61

追加されたライブラリの方は結構使うな

311 ：デフォルトの名無しさん：2011/04/19(火) 13:13:59.91

どんなライブラリーがあるのかどうやってしらべる？
JAVAみたいにSDKマニュアルみたいなのがあればいいのだが
VCにしか無さそうだな。

312 ：デフォルトの名無しさん：2011/04/19(火) 13:40:48.36

英語読めないのか?

313 ：デフォルトの名無しさん：2011/04/19(火) 13:55:47.33

読めるけど？なにか？

314 ：デフォルトの名無しさん：2011/04/19(火) 14:04:03.00

ああ、まさか、ライブラリーをboostライブラリーと勘違いしちゃったのかな
標準ライブラリーの中身の話だよ。
付いていけないなら黙っていてくだちゃいねｗｗｗｗ
バブバブ

315 ：デフォルトの名無しさん：2011/04/19(火) 14:09:51.51

>>311 http://ja.lmgtfy.com/?q=C%2B%2B+reference

316 ：デフォルトの名無しさん：2011/04/19(火) 14:12:01.62

つ libstdc++ reference

317 ：デフォルトの名無しさん：2011/04/19(火) 14:14:03.98

>>311 >>1

318 ：デフォルトの名無しさん：2011/04/19(火) 14:14:19.08

>>315
ありがとうございました
ほんとうにどういたしまして
しんせつにどうも
ネットでしらべてみます。
ぼくもこれからは
けんさくします

319 ：デフォルトの名無しさん：2011/04/19(火) 15:20:44.21

何だかなあ

320 ：デフォルトの名無しさん：2011/04/19(火) 19:19:05.89

震災で、IEみたいに日本では数ヶ月遅れですか？

321 ：デフォルトの名無しさん：2011/04/19(火) 20:59:58.85

数ヶ月や数年で済めばいい方

322 ：デフォルトの名無しさん：2011/04/19(火) 21:33:43.95

>>320
JIS規格になるのって意味あるの？
どうせ日本製のフル実装のコンパイラなんて出ないと思うんだけど。

323 ：デフォルトの名無しさん：2011/04/19(火) 22:18:06.54

意味はないけど新しい用語のセンスない訳には興味ある

324 ：デフォルトの名無しさん：2011/04/20(水) 00:06:19.01

JIS用語は通じないことが多いよな

325 ：デフォルトの名無しさん：2011/04/20(水) 08:03:21.23

随伴と返却値くらいじゃね？

326 ：デフォルトの名無しさん：2011/04/20(水) 18:38:25.05

返り血

327 ：デフォルトの名無しさん：2011/04/20(水) 20:39:32.83

それに翻訳間違ってることあるしな。

328 ：デフォルトの名無しさん：2011/04/20(水) 22:34:19.57

勝手に大事な脚注消されてたりするしな

329 ：デフォルトの名無しさん：2011/04/21(木) 00:03:18.25

翻訳じゃないし、勝手じゃないし

330 ：デフォルトの名無しさん：2011/04/21(木) 15:01:05.62

objective-c++ で　auto使う方法ないのでしょうか

331 ：デフォルトの名無しさん：2011/04/21(木) 17:34:11.38

c++0xのコードを普通のc++に変換する方法ないですか

332 ：デフォルトの名無しさん：2011/04/21(木) 18:25:18.08

どっちも普通のC++だが・・・。
まー、C++0xのコードをBOOSTで置き換えるのが一番労力くわないんじゃね？

333 ：デフォルトの名無しさん：2011/04/21(木) 20:42:14.05

>>331
具体的にどぞ

334 ：デフォルトの名無しさん：2011/04/29(金) 11:28:50.51

そのうちC++03からの差分を赤字にしたFDISとかも作られるの？

335 ：デフォルトの名無しさん：2011/04/29(金) 14:29:56.28

あるだろ

336 ：デフォルトの名無しさん：2011/04/29(金) 19:47:35.70

あるの？
前のドラフトとの差分ならあるけど

337 ：デフォルトの名無しさん：2011/05/02(月) 22:11:22.96

ConceptGCCのサイト消滅

338 ：デフォルトの名無しさん：2011/05/02(月) 23:19:11.02

コンセプトさんとは一体何だったのか…

339 ：デフォルトの名無しさん：2011/05/03(火) 02:18:58.61

今の規格決まったらまた再燃するでしょ。
ただConceptGCCの中の人は、AppleでCLangやってるし、
ConceptGCC引き継ごうとした人に「最初から実装したほうがいいぜ」って言ってたw

340 ：デフォルトの名無しさん：2011/05/03(火) 02:20:18.91

外道だな

341 ：デフォルトの名無しさん：2011/05/03(火) 10:00:59.97

そろそろC++0xスレもオワコンだな
誰かC++2xスレ立てろよ

342 ：デフォルトの名無しさん：2011/05/03(火) 11:12:23.43

半世紀先かよ

343 ：デフォルトの名無しさん：2011/05/03(火) 13:30:52.17

0xってまだやってたのかwww
好い加減あきらめればいいのに

344 ：デフォルトの名無しさん：2011/05/03(火) 15:28:33.82

完成まで1年切ってるのにここであきらめるとかないわ

345 ：デフォルトの名無しさん：2011/05/03(火) 20:32:04.32

投票は残すところあと1回だけだからね。

346 ：デフォルトの名無しさん：2011/05/03(火) 20:48:44.74

次は、TR2を通すんだろう。
来年？

347 ：デフォルトの名無しさん：2011/05/03(火) 21:46:59.23

その辺の予定。

348 ：デフォルトの名無しさん：2011/05/04(水) 17:04:42.16

結局コンセプトは無し？
コンパイルエラーと戦う日々が続くのか

349 ：デフォルトの名無しさん：2011/05/04(水) 17:34:24.43

オブジェクトの生成場所をヒープに限定する
private:
~デストラクタ();

オブジェクトの生成場所をスタックに限定する
private:
void *operator new(size_t);
※ただし、オブジェクトがメンバー変数で作成された場合、
　ヒープ上に存在できてしまう。

この辺の小ネタ、0xで綺麗に書けるようになったりしないの？

350 ：デフォルトの名無しさん：2011/05/04(水) 19:01:44.06

= delete ;

351 ：デフォルトの名無しさん：2011/05/04(水) 19:03:41.09

スタック／ヒープの話は規格とは関係な･･･って話とは違うか。
しかし生成場所をスタック／ヒープに限定するって話でもないな。

352 ：デフォルトの名無しさん：2011/05/04(水) 19:15:54.14

動的生成の強制または禁止ということだろうけど
言語仕様でサポートするほどありがたいものには思えん
というか何に使うんだそんなもん

353 ：デフォルトの名無しさん：2011/05/04(水) 19:20:01.54

というか、newを使えなくしても、
placement newされればどうしようもない。

354 ：デフォルトの名無しさん：2011/05/04(水) 19:40:38.49

>>352

スマポをnewするようなバカな事を避けるとか、
外部からのdeleteでデストラクタを呼ばせず、破壊用の関数を呼んで
オブジェクトを廃棄させたい場合とか(例外が起こりうる処理は、
デストラクタでなく破壊用関数の中で処理する。)

>>353
確かになぁ。

355 ：デフォルトの名無しさん：2011/05/04(水) 19:52:34.75

そんな事するバカはこんな局所的な所だけ救っても無駄だろ

356 ：デフォルトの名無しさん：2011/05/04(水) 20:34:46.88

ドット演算子のオーバーロードはなぜ追加されないのですか？

357 ：デフォルトの名無しさん：2011/05/04(水) 20:38:34.77

>>356
どうやってオブジェクト本体のメソッド呼び出すんだよ。
あと、ドットの呼び出しで別のオブジェクトのメンバーを呼び出すなら、
最初からその別のオブジェクトを使ったって動作は変わらん。

358 ：デフォルトの名無しさん：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();

とかかな。

359 ：デフォルトの名無しさん：2011/05/04(水) 21:13:11.52

コピーもムーブも封じないとダメだね
でもそうなると標準コンテナ使えなくなるし…
ちょっと利点と欠点が釣り合わないかな

360 ：デフォルトの名無しさん：2011/05/04(水) 21:32:05.10

>>358
friend使うくらいならstatic関数使った方がよくね。

361 ：デフォルトの名無しさん：2011/05/04(水) 23:02:53.42

>>349
> オブジェクトの生成場所をヒープに限定する
> private:
> ~デストラクタ();

これ delete できなくならない？ cl が間違ってるの？

362 ：デフォルトの名無しさん：2011/05/04(水) 23:24:49.33

>>361

外からは破壊できないよ。
実際はこういう使い方。

public:
void Destroy()
{
//例外が起こり得る後始末
　delete this;//内部からなら破壊できる。
}
private:
~デストラクタ()
{
//例外の起こらない後始末
}

363 ：デフォルトの名無しさん：2011/05/04(水) 23:33:55.43

もしくは、friend宣言したクラスや関数からしか使えないクラスとかかな。
あんまり現実的なテクニックじゃないけど。

364 ：デフォルトの名無しさん：2011/05/04(水) 23:44:13.96

結局こういうのは汎用性のない小細工になるわな
考えるだけ無駄無駄

365 ：デフォルトの名無しさん：2011/05/05(木) 00:08:38.29

無駄無駄無駄ァァァーッ！！

366 ：デフォルトの名無しさん：2011/05/05(木) 01:01:25.08

なーる、内部でdeleteすればいいのか

367 ：デフォルトの名無しさん：2011/05/05(木) 01:21:16.41

外部で直接deleteさせない事が目的の一つだからね。
「デストラクタの中から例外は送出してはいけない」(デストラクタ内で例外処理するのはアリ)
これを実現するための一つの手段。
他の人はどうやってんのか知らんけど。

368 ：デフォルトの名無しさん：2011/05/05(木) 10:57:31.39

デストラクタで例外ってどんな作業してんだ？

369 ：デフォルトの名無しさん：2011/05/05(木) 11:02:57.32

C++0xの次の企画でいいから
参照カウント型の張替え可能参照を組み込んで

370 ：デフォルトの名無しさん：2011/05/05(木) 12:51:53.40

>>368
close関数がエラー返すとか

371 ：デフォルトの名無しさん：2011/05/05(木) 13:03:33.44

無理してデストラクタで開放しなくてもいいんじゃないのさ

372 ：デフォルトの名無しさん：2011/05/05(木) 13:49:52.86

その工夫が>>362なんじゃないの

373 ：デフォルトの名無しさん：2011/05/05(木) 13:52:01.60

RAIIだとデストラクタでリソース開放することが多くなるよね

374 ：デフォルトの名無しさん：2011/05/05(木) 14:29:43.97

>>372
工夫してって、デストラクタやdeleteを封印とか余計に無理してるじゃん
デストラクタやdeleteを封印するのはデメリットのほうが大きいよ

>>373
オブジェクトとリソースの寿命が必ずしも一致しないといけないなんてことはない
RAIIにこだわらなくてもリソースの開放漏れを防ぐ方法はいくらでもある

375 ：デフォルトの名無しさん：2011/05/05(木) 14:42:12.13

代替案は？

376 ：デフォルトの名無しさん：2011/05/05(木) 15:14:04.25

>>375 とりあえず std::fstream::close() があるな。

377 ：デフォルトの名無しさん：2011/05/05(木) 15:34:31.11

あるけど、デストラクタで閉じられるから大抵のヤツは無視するだろ。

378 ：デフォルトの名無しさん：2011/05/05(木) 15:41:32.32

どうりでC++はウンコプログラムが多いわけだ

379 ：デフォルトの名無しさん：2011/05/05(木) 15:45:25.06

>>377 これはひどい。

380 ：デフォルトの名無しさん：2011/05/05(木) 15:48:50.42

>>378
C で fclose() を忘れずに呼んで忘れずに戻り値チェックするのに比べればちょっとはマシ。

381 ：デフォルトの名無しさん：2011/05/05(木) 15:52:17.59

>>380
忘れずに閉じてエラーチェックまでしてるプログラムより>>377の何がマシなの？

382 ：デフォルトの名無しさん：2011/05/05(木) 15:59:29.04

>>381
え？プログラムと人を比べるの？何の話してるの？

383 ：デフォルトの名無しさん：2011/05/05(木) 16:03:41.80

>>382
なんで質問に質問で返すの？

384 ：デフォルトの名無しさん：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

385 ：デフォルトの名無しさん：2011/05/05(木) 16:17:24.81

デストラクタ内のエラーはシステムを信じて握りつぶす。通はこれだね

386 ：デフォルトの名無しさん：2011/05/05(木) 16:22:02.98

容量オーバーでエラーが返ってきたなら、無駄なファイルを削除する事で救えたデータもあっただろうに。
ネット越しなら再接続して送信を試みる事もできたろうに、ああかわひそふなことほした。

387 ：デフォルトの名無しさん：2011/05/05(木) 16:38:22.31

結局のところ処理内容によるんだよね
やるべき事は文法的にデストラクタを縛ることじゃなくて
処理内容に合わせたエラーハンドラの設定だよ

388 ：デフォルトの名無しさん：2011/05/05(木) 16:47:55.31

結局コンストラクターでクローズ時のハンドラ設定出きるようにしとくのが現実的か。

>>376 それって例外なり戻り値でエラー反したっけ？

389 ：デフォルトの名無しさん：2011/05/05(木) 16:52:52.89

つうか、closeでエラーが帰ってきたとしても特に何もする事はない。
close以前に問題がある事が普通だからな。
エラーメッセージとかログを残す事は必須だな。

390 ：デフォルトの名無しさん：2011/05/05(木) 16:55:55.26

デストラクタで処理できないエラーは
無視できることにしたいんですね、わかります

391 ：デフォルトの名無しさん：2011/05/05(木) 17:07:55.37

>>388
exceptions(failbit) 設定しとけば close() 失敗で例外が飛ぶ。
デフォルトのまま例外使わないなら、 close() のあと fail() や
good() や operator void* () で見ればいい。

>>389
書き込んだつもりのデータがバッファに溜まってただけで
書き込めてないことがあるんだよ。危ないよ。

392 ：デフォルトの名無しさん：2011/05/05(木) 17:15:42.80

>>389
ログ書き出しのcloseでバッファにメッセージが残ったままエラーが起きたらどうするんだろう・・・。

393 ：デフォルトの名無しさん：2011/05/05(木) 17:20:15.65

デストラクタでの処理は保険で
失敗する可能性がある奴は明示的に処理すればいいじゃない

394 ：デフォルトの名無しさん：2011/05/05(木) 17:24:01.35

というわけで 376 に戻るわけだ。

395 ：デフォルトの名無しさん：2011/05/05(木) 18:39:35.10

そんな半端な保険ならないほうがいい
デストラクタ呼ばれるまでに明示的に閉じてなければアサートを出すべき
起こりうるけど確率の低いバグしかもファイル処理でとか最悪のパターンだわ

396 ：デフォルトの名無しさん：2011/05/05(木) 18:50:28.14

　動画書き出しててディスクの容量足りないとかザラにある訳だけどな。
パーティションが一つとは限らんから別のパーティション利用したり何らかの対処している編集ソフト結構ある。

397 ：デフォルトの名無しさん：2011/05/05(木) 18:53:31.82

何スレだよ

398 ：デフォルトの名無しさん：2011/05/05(木) 18:56:55.44

C++0xでもエラー処理は楽にならない、というスレ

399 ：デフォルトの名無しさん：2011/05/05(木) 19:46:27.28

どっかのまとめサイトでも居たがデストラクタで云々言う奴はなんでclose時にしかエラー捕捉しないのか

400 ：デフォルトの名無しさん：2011/05/05(木) 19:56:24.02

バッファの書き込みはリソース解放ではないので、RAIIで処理する事は望ましくない。

401 ：デフォルトの名無しさん：2011/05/05(木) 19:57:52.46

>>399
少なくともこのスレじゃ誰もそんなこと言ってなくね？
勝手に相手をアホ認定すんなよ

402 ：デフォルトの名無しさん：2011/05/05(木) 19:59:48.73

誰もアホとか言ってないのになに切れてんだか

403 ：デフォルトの名無しさん：2011/05/05(木) 20:26:17.79

エラーも満足に補足できないプログラマは総じてアホだ

404 ：デフォルトの名無しさん：2011/05/05(木) 20:34:32.84

プログラマなんて道を選んだプログラマは総じてアホだ

405 ：デフォルトの名無しさん：2011/05/05(木) 20:34:34.68

エラーハンドリングが必要なら、先に明示的にバッファをflushしてからcloseするようにすればいいだけじゃん。
flushが成功したのにcloseが失敗したら、もうそれはアプリケーション側では回復不可能なエラーとして握りつぶしていいんじゃない？

406 ：デフォルトの名無しさん：2011/05/05(木) 20:40:46.49

わざわざデストラクタで閉じる前に flush() するくらいなら
そこで close() しちゃえば良いのに

407 ：デフォルトの名無しさん：2011/05/05(木) 21:07:08.42

>>406
いや、普通は
write()*n + flush()
が一つのトランザクションであり、
open() + トランザクション*m + close()
までがライフサイクルだろ？
だから、flush()とclose()は別にするべきだろう。

408 ：デフォルトの名無しさん：2011/05/05(木) 21:12:32.26

0xの話題がなくなるといつもこの話題が盛り上がるね

409 ：デフォルトの名無しさん：2011/05/05(木) 21:14:12.18

で右辺値参照は？

410 ：デフォルトの名無しさん：2011/05/05(木) 21:20:53.65

退学騒動がひと段落した後
変化があったとは聞かないけど

411 ：デフォルトの名無しさん：2011/05/05(木) 21:24:15.91

デストラクタでごにょごにょの件は
Effective C++に書いてなかったっけ
今手元にないから記憶が曖昧だけど

412 ：デフォルトの名無しさん：2011/05/05(木) 21:27:26.42

ここはアプリケーションの不具合の責任を言語に押し付けるスレですか？

413 ：デフォルトの名無しさん：2011/05/05(木) 21:31:26.33

　デストラクタの前に、エラーチェックをしないとコンパイルエラーにできる構文があってもよかったかもしれん。

414 ：デフォルトの名無しさん：2011/05/05(木) 22:47:48.64

>>413
explicit デストラクタさんか…。
スコープの最後に明示的に呼び出さなければエラー、とか。

415 ：デフォルトの名無しさん：2011/05/05(木) 22:56:18.27

動的に確保した時厳しそうだな

416 ：デフォルトの名無しさん：2011/05/05(木) 23:29:28.43

>>415
delete直前のポインタにかかるようになってたら可能かも。
ただ継承関係を考えたら面倒くさそうだ。

417 ：デフォルトの名無しさん：2011/05/06(金) 13:55:53.12

gccで
char16_t *c=u"あいうえお";
みたいにやっても出来ないんですけど。
どうやったら出来るんですか？
英数字なら出来るけど良く分かりません。

418 ：デフォルトの名無しさん：2011/05/06(金) 14:02:56.58

>>417
期待した結果と実際の結果を、違いがわかるように書きなさい。

419 ：デフォルトの名無しさん：2011/05/06(金) 14:04:16.70

ソースの文字コードは

420 ：デフォルトの名無しさん：2011/05/06(金) 14:05:46.50

何も設定変えないでエクリプスでやったやつだけど

421 ：デフォルトの名無しさん：2011/05/06(金) 14:14:19.96

uはユニコードにエンコードしてくれるしるしだから
文字コードは関係ないでしょう。

422 ：デフォルトの名無しさん：2011/05/06(金) 14:34:30.20

gccを新しくした場合、gccの認識する日本語文字コードが変わってる場合も

423 ：デフォルトの名無しさん：2011/05/06(金) 14:40:49.10

よくわからないのでとりあえず一発で解決する文字コードの直し方教えてください。

424 ：デフォルトの名無しさん：2011/05/06(金) 14:43:53.52

ASCIIのみ。これ鉄板。

425 ：デフォルトの名無しさん：2011/05/06(金) 15:11:31.17

とりあえず確認したコードを全部載せろや

426 ：デフォルトの名無しさん：2011/05/06(金) 15:16:50.06

これがガチ
char16_t * c = u"\x42\x30...

427 ：デフォルトの名無しさん：2011/05/06(金) 15:27:07.10

u だと４桁になるんじゃない？

428 ：デフォルトの名無しさん：2011/05/06(金) 15:46:11.61

> u だと４桁になるんじゃない？
ああそうだった。それと文字列リテラルはconstで受けるべきだからこうか
const char16_t * c = u"\x3042...

429 ：デフォルトの名無しさん：2011/05/06(金) 16:07:12.74

C++0xでconstなしじゃポインタでリテラル受けれなくなったっけ？

430 ：デフォルトの名無しさん：2011/05/06(金) 16:09:42.54

その暗号みたいな数字しかuをつかって0xは受け付けてくれないのか？

431 ：デフォルトの名無しさん：2011/05/06(金) 16:20:37.17

>>429
配列からポインタへの暗黙変換のルールの中でconst外しの例外がバッサリ削除

432 ：デフォルトの名無しさん：2011/05/06(金) 17:02:01.78

>>431
いい事だな

433 ：デフォルトの名無しさん：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だけど)が出てくると思う。

434 ：デフォルトの名無しさん：2011/05/06(金) 17:56:52.59

>>430
ソースファイルの文字コードが問われない形にできるから、
>>433のいう理由、しかも一番起こりやすい、では失敗しないってことでしょ。

435 ：デフォルトの名無しさん：2011/05/06(金) 20:13:30.33

gccに食わせるソースファイルのエンコードはUTF-8にしておけ。

436 ：デフォルトの名無しさん：2011/05/06(金) 20:17:11.45

>>434
EBCDICだとまずいがな

437 ：433：2011/05/06(金) 20:25:05.92

すまん。単語を間違えてる。井桁は # じゃねえか。
= の太字ってなんていうんだっけ…

438 ：デフォルトの名無しさん：2011/05/06(金) 20:37:34.83

〓下駄

439 ：デフォルトの名無しさん：2011/05/06(金) 21:02:13.88

>>435
iconvがリンクされてないgccバイナリはだめだけどな

440 ：デフォルトの名無しさん：2011/05/10(火) 07:26:01.19

普通に使われてるSJISの文字は変換されないということか？
uで変換できるのは#/4343のような暗号の様な文字列をユニコードに変換する印ということか。
それならSJISの文字を暗号の様な文字列に変換するようなマクロがあれば良いな。
誰かつくってくれないかなぁ。

441 ：デフォルトの名無しさん：2011/05/10(火) 07:36:37.19

basic source character set以外の文字をソースファイルに使えるかどうかは実装依存。

442 ：デフォルトの名無しさん：2011/05/10(火) 09:52:51.73

出力を表示するところもSJISでないとだめだから
出力するときもユニコードからSJISに変換しなければいけないな。

443 ：デフォルトの名無しさん：2011/05/10(火) 10:08:37.91

Shift_JISはmbcsとして扱うのも大変だしね。
日本人以外の処理系開発者からしてみれば、
なんでこんな阿呆なcoding system使ってるのかと思うだろうね。

444 ：デフォルトの名無しさん：2011/05/10(火) 10:22:18.65

まだ続いてたのか。

>>440
uとかの文字列リテラルの前置は変換を指示なんかしない。
uはそれに続く文字列リテラルのバイト列をUTF-16の文字コードとみなしてくれとコンパイラに要請するだけで
それが実際にUTF-16の文字コードであるかはコンパイラにソースを渡すものが保障する必要がある。

reinterpret_castでポインタを無理やりキャストした場合の動作に近いイメージ。
double型の値へのポインタをreinterpret_cast<int*>でint型へのポインタに変換してint型の値として参照しても
期待したようなint型の値に変換されるわけではないのと同じ。

445 ：デフォルトの名無しさん：2011/05/10(火) 10:30:41.63

>>444
規格上の定義と実装上の都合をごっちゃにするなアホ。

446 ：デフォルトの名無しさん：2011/05/10(火) 10:55:11.14

最低でもascii<-->unicodeやunicode間の変換くらいはできるはずだがな(でないと意味がない)

447 ：デフォルトの名無しさん：2011/05/10(火) 11:05:57.07

>>426-428からして、
u"\u～"じゃなくて、u"\x～"だしなあ。
ちょっとスレの焦点が定まってないね。

448 ：デフォルトの名無しさん：2011/05/10(火) 12:22:03.89

struct hoge : typedef long_type_name t: public fuga< t, aloc<t>>{};

こういうこと出来るようなればc++もっと流行るのに

449 ：デフォルトの名無しさん：2011/05/10(火) 12:23:28.17

長くなったけど結論としては、
エクリプスでエディターの文字コードをユニコードにして
出力の文字コードもユニコードにして、
ＧＣＣに入力されるソースコードがユニコードであると指定すれば良いわけだな。
しかし、将来的にはS-JISコードがuによってユニコードに変換できるようになる
んだろうか？かりにそうならそうなるまで待つけど、そうじゃないならこうするしかないな。

450 ：デフォルトの名無しさん：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

451 ：デフォルトの名無しさん：2011/05/10(火) 12:35:44.60

Unicodeスレでやってくれ
荒れるから

452 ：450：2011/05/10(火) 12:42:26.09

だから実行形式が純粋な ASCII の環境では、
u'\uXYZW' は一般に 0xXYZW と等しくない。
等しくなるのは 0xXYZW が 127 以下のときのみ。

俺はこの事実を信じたくないから
誰か根拠を添えて反論してほしい。

453 ：デフォルトの名無しさん：2011/05/10(火) 12:44:03.72

いや>>450はC++0xの規格の話だろ。
もともとCのTRだったから、Cのスレというのならまだ分かるが。

454 ：デフォルトの名無しさん：2011/05/10(火) 12:45:04.46

>>452
それ以外にどうしろと…

455 ：デフォルトの名無しさん：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)

456 ：450：2011/05/10(火) 19:22:00.80

>>455
\u と \x が別なのはいいよ。それは当然だよ。

だけど u'\u1234' != 0x1234 は気持ち悪くないか？

457 ：デフォルトの名無しさん：2011/05/10(火) 19:27:32.04

主観で語られましても

458 ：デフォルトの名無しさん：2011/05/10(火) 20:33:05.09

>>456
なんで気持ち悪い？
そもそも文字の内部表現を仮定して数値と比較するのは '0' == 0x30　でさえ真になるかは環境依存。
(今更非ascii系を考えてどうなるってのは置いとけ)
文字の内部表現が具体的にどういう数値になるかを仮定するのは危険ってのが
ユニコード文字にも変わらず適用されてるだけと思えばなにも気持ち悪いことはないだろ。
(そもそもそれからして気持ち悪かったというのなら、まあ･･･)

459 ：450：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 しかない、みたいなときを除けばだけど)

460 ：デフォルトの名無しさん：2011/05/10(火) 22:12:27.39

そもそも「実行キャラセットが 7bit ASCII の環境」なんてものがあるかどうか。

461 ：デフォルトの名無しさん：2011/05/10(火) 22:18:47.37

>>459
実行キャラセットが 7bit ASCII の環境で非ASCII文字が出力できるのか？
環境が融通を利かせて表示してくれるとしても各データが7bitまでで表現されてるバイト列を文字列として渡さなければならないだろ。
各データが8bitまでフルに使うUTF-8でエンコードした文字列を渡して正しく表示されるほうが驚きだ。
(8bitのデータを受け入れ可能なら7bit環境じゃないだろ)

462 ：デフォルトの名無しさん：2011/05/10(火) 22:24:08.80

charが最低8ビットって保証されてなかったっけ？
7bit環境ではそもそもC言語が使えないとかの話になるとおもう

463 ：デフォルトの名無しさん：2011/05/10(火) 22:28:23.30

>>462
charが1バイトで、sizeof(char)が返すのは1だという事は保証されている。
ただし、1バイトが何bitかは規定していない。一般的な用語で言えばchar型が
4byteな環境でも、C言語の規格で言えば単に1バイトが32bitな環境になる。

464 ：デフォルトの名無しさん：2011/05/10(火) 22:29:20.48

>>462
が、 signed char が -127 から +127 の範囲を表現できることは規定されてるな。
だから、実質的に最低8bitというのは課程できるだろうな。

465 ：デフォルトの名無しさん：2011/05/10(火) 22:30:17.38

>>460,461
7bit ASCII　という例が悪かったよ。日本語が全く使えない環境、という意味でしかなかった。

たとえ 8bit環境でも、実行キャラセットがひらがなを含んでいないLatin-1ならば、
u8"\u3053\u3093\u306b\u3061\u306f" は utf-8 の「こんにちは」とバイナリ表現が一致しない。

466 ：デフォルトの名無しさん：2011/05/10(火) 22:48:10.05

Unicodeを(実行時キャラクターセットを無視した)バイナリとして吐き出そうとしても
規格上リテラルが一旦実行時キャラクターセットを経由した変換がされてしまうので
化けてしまう、という危惧はよくわかるが

実際問題>>433みたいな変換を馬鹿正直に実装してるコンパイラなんて無いと思うので
気にしなくてもいいような

467 ：デフォルトの名無しさん：2011/05/10(火) 23:20:37.44

よくわかんないけど文字コードって怖いですね
ヨーロッパ人はもっと怖いんだろうな

468 ：デフォルトの名無しさん：2011/05/10(火) 23:51:45.39

>>465
mingw-gcc4.5.2でfexec-charset=Latin-1で試そうとしたら
実行以前にiconvがUTF-8からlatin-1への変換をサポートしてないとコンパイルエラーにされたでござる

469 ：468：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;
}

470 ：450：2011/05/11(水) 06:39:56.45

>>469
うん。実行キャラセットにない文字の処遇は処理系依存で、どう扱ってもいいので
gcc が latin1 でも utf8 をうまく扱ってるのは理解できるんだよ。

(実行キャラセットの最終的なエンコーディングは latin1 でも、
文字集合自体は unicode を包含していても構わないわけだし)

問題はそのGCCの挙動がISO準拠を謳うコンパイラに共通なのかどうかで。

n3290の俺の読み方が間違ってて本当は大丈夫なんだ、という指摘がほしかったんだけど
GCCでやってるぶんには大丈夫ってことでまあいいや。㌧

471 ：デフォルトの名無しさん：2011/05/11(水) 11:18:55.35

ユニコードのコードポイントと１６進数が恒等置換ではないとっていうなら
コードポイントと１６進数の対応は全単射なら何でも良いって分けか？

472 ：デフォルトの名無しさん：2011/05/11(水) 16:18:22.19

>>471
規格上はあるユニコード文字一文字を表現しているchar16_t,char32_t型の値はその文字のコードポイントの値と等しくなるとなっている。

それとは別にソースにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
実行キャラセットへの(不要な)変換およびユニコードへの再変換を経て実行段階ではAと異なる文字A'になるかもしれないのか？って話。

それで、もしそうならやだなあとか、
もしそうなら文字Aのコードポイントの値を直接使ったプログラムは意図したとおりに動かないことがあるなあ、って話。

473 ：デフォルトの名無しさん：2011/05/11(水) 17:06:04.40

それとは別にソースのユニコード指定した文字／文字列リテラルにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
だな。

474 ：デフォルトの名無しさん：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の解釈が変われば不用。

475 ：デフォルトの名無しさん：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文字集合内の文字に変換)

476 ：デフォルトの名無しさん：2011/05/12(木) 14:48:19.80

SJISは変換されないんじゃ？

477 ：450：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 って程度の表現にしないと誤解招くよなあ。

478 ：デフォルトの名無しさん：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" に変換するという記述が
修正されることは、ついになかった。

479 ：デフォルトの名無しさん：2011/05/13(金) 09:58:36.28

"execution"あるとなんかまずい?

> in the appropriate execution character set

これはユニコード系とは限らないよね。

480 ：デフォルトの名無しさん：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 の二種類しかないような書き方だからまずいよ。

ないような、というか二種類しかなかったんだよ。書かれた当時は。

481 ：デフォルトの名無しさん：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"ああ" と書いた場合と等しい結果を期待するかもしれないが
そうはならないので注意をうながしている。

482 ：デフォルトの名無しさん：2011/05/13(金) 14:13:06.54

>>480
> 　u8"", u"", U"" はユニコード
> へそれぞれ適切に変換する、という意味で言いたいんだろう。

この変換は必須ではないから解釈という言葉が出ているのでは?

483 ：デフォルトの名無しさん：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の通りだとすると"えすじず"は文字化けしないとおかしい。
(これは文字集合の変換・逆変換で非可換かもという問題とは別)

484 ：デフォルトの名無しさん：2011/05/13(金) 17:20:46.43

>>483
すまん
×非可換
○非可逆

485 ：481：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"

-もある。

486 ：デフォルトの名無しさん：2011/05/13(金) 20:25:20.35

C++0xのスレかと思ったら違うスレに迷い込んだようだ

487 ：デフォルトの名無しさん：2011/05/13(金) 20:43:15.18

間違ってはないよね

488 ：デフォルトの名無しさん：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 は正しいということだな。

489 ：デフォルトの名無しさん：2011/05/14(土) 12:26:40.94

なるほど。ということは結局
> それとは別にソースのユニコード指定した文字／文字列リテラルにuniversal-character-name記法でユニコード文字Aとして書いた文字であっても
> 実行キャラセットへの(不要な)変換およびユニコードへの再変換を経て実行段階ではAと異なる文字A'になるかもしれないのか？って話。
もありえるということになるのか？

490 ：デフォルトの名無しさん：2011/05/14(土) 16:25:33.57

処理系による。

491 ：デフォルトの名無しさん：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とかはその意味では明らかに間違い。

492 ：デフォルトの名無しさん：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"
を抜き出して「第五段階ですでにエンコード済み」とは言えなくなる。
「コード値に変換された」ではなくて
「エスケープシーケンスが一文字に変換された」という意味だから。

493 ：デフォルトの名無しさん：2011/05/17(火) 12:58:36.92

>>483みたいに-fexec-charset=sjis
をつければuでユニコードに変換できますか？

494 ：デフォルトの名無しさん：2011/05/17(火) 14:05:27.48

>>493
exec-charsetがどうかということとu付けたリテラルがユニコードで表現されるかということには何の関係もない。
意味もわからず呪文を唱えるのでなく仕組みを理解しな。

495 ：デフォルトの名無しさん：2011/05/17(火) 15:39:10.27

誰も教えてくれないからsjisはgcc4.5じゃなくて4.6から対応しているということで自分を納得させてみよう。

496 ：デフォルトの名無しさん：2011/05/18(水) 09:44:06.39

C++0xおっかけたいけどgccのビルド方法がイマイチわかんなくてどうにも・・・
どっかに初心者用解説とかないん？

497 ：デフォルトの名無しさん：2011/05/18(水) 10:15:31.35

じゃあバイナリで落とせば？

498 ：デフォルトの名無しさん：2011/05/18(水) 10:40:35.97

>>496
http://gcc.gnu.org/install/

499 ：デフォルトの名無しさん：2011/05/20(金) 23:05:41.38

ここ１年ほどおっかけてないけど、何かあった？

500 ：デフォルトの名無しさん：2011/05/20(金) 23:09:57.54

FDIS可決

501 ：デフォルトの名無しさん：2011/05/20(金) 23:17:08.22

Final Draft International Standardね。ありがとう。
しかし、GCCで動くぶんは使ってるから、ユーザ側としては規格より実装ヨロって感じです。

502 ：デフォルトの名無しさん：2011/05/21(土) 01:35:05.55

（　ﾟдﾟ）ﾎﾟｶｰﾝ

503 ：デフォルトの名無しさん：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

504 ：デフォルトの名無しさん：2011/05/21(土) 11:03:49.97

仕事で安心して使えるようになるのはいつごろですか？

505 ：デフォルトの名無しさん：2011/05/21(土) 12:10:16.41

仕事の要件に従え
上司・責任者に聞け
自分の判断で好きにしていいなら自分で判断しろ

506 ：デフォルトの名無しさん：2011/05/21(土) 15:13:28.30

ttp://ideone.com/45Shg

動的資源を std::unique_ptr<T> で管理するとこんな感じになるのだろうか
クラス X の初期化リストをもっと綺麗に書けないだろうか

507 ：デフォルトの名無しさん：2011/05/21(土) 15:15:36.60

>>506 それの何が気に入らないの？

508 ：デフォルトの名無しさん：2011/05/21(土) 15:22:09.58

>>507

reset() を使うあたりが、どうもぱっとこない。
そもそも標準のスマポの使用作法なるものが良く分からないんですけどね。。

get() とか release() とか reset() とかを、スマポを使用する側で呼び出すと、
本来 std::unique_ptr<T> がもつ所有権移動のセマンティクスが壊れてしまうような気がして、気持悪いのです

509 ：デフォルトの名無しさん：2011/05/21(土) 15:47:34.38

それはないだろ

510 ：デフォルトの名無しさん：2011/05/21(土) 16:01:26.32

つまりunique_ptrのセマンティクスを意図的に壊すためのget メンバを
pointeeのオブジェクトをクローンするときに用いないといけないのが
気持ち悪い、ということか？

511 ：デフォルトの名無しさん：2011/05/21(土) 16:04:35.80

X& operator=( const X& that ) {
　if( this != &that ) { *this = X(that); }
　return *this;
}
↑はresetを使わずさらに例外安全の強い保障も提供する

512 ：デフォルトの名無しさん：2011/05/21(土) 16:11:50.38

>>508
release() についてはわかるが、 get() や reset() を嫌がるのは意味が解らん。

513 ：デフォルトの名無しさん：2011/05/21(土) 18:36:14.65

>>508
コピー不可のメンバがあるクラスにコピーコンストラクタとコピー代入演算子を実装しようとしてるんだから
すっきりしないコードになるのは当然のような気がする。

514 ：デフォルトの名無しさん：2011/05/21(土) 20:37:53.55

pimpl_ptrをパパっと作ってそれに持たせればおｋ

515 ：デフォルトの名無しさん：2011/05/21(土) 21:30:13.90

そもそも代入ってリセット以外の何物でもないんじゃないかな。

516 ：デフォルトの名無しさん：2011/05/21(土) 22:13:41.32

c++で仕事って、どんな案件なのか想像できない

517 ：デフォルトの名無しさん：2011/05/21(土) 22:17:38.55

ゲーム

518 ：デフォルトの名無しさん：2011/05/21(土) 22:24:22.29

>>516
一昔前で言うところのシステムソフトウェア。
カーネル、ブラウザ、ライブラリなど

519 ：デフォルトの名無しさん：2011/05/21(土) 22:25:55.44

※但し、Windowsに限る

520 ：デフォルトの名無しさん：2011/05/21(土) 22:31:02.00

>>519
　　　　/＼＿＿_／ヽ
　　／／~ 　　 ~＼:::::＼
　 . |　（･）　　　（･）　 .:|
　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::| 　　　は？
. 　 |　　｀-=ﾆ=- '　.:::::::|　　　
　　＼　　｀ﾆﾆ´　 .:::::／
　　　／｀ー‐--‐‐―´＼

521 ：デフォルトの名無しさん：2011/05/21(土) 22:33:21.14

ここはまともなC++スレなんで
荒らさないでください

522 ：デフォルトの名無しさん：2011/05/21(土) 23:03:24.01

ついにこのスレまで来たか

523 ：デフォルトの名無しさん：2011/05/23(月) 01:21:58.98

結局C++で純粋関数型記述できるようになる？

524 ：デフォルトの名無しさん：2011/05/23(月) 18:54:42.51

テンプレート使えば今でも出来るよ

525 ：デフォルトの名無しさん：2011/05/24(火) 22:23:59.34

C# でのプロパティとかインターフェースとかイベントとかは
導入されないんですか？

526 ：デフォルトの名無しさん：2011/05/24(火) 22:43:58.83

プロパティは却下です。
あまりにもC++的でないので当然です。
なにかもっとよりprimitiveなoperatorに還元できれば加えられるかも。

インターフェースはもっと強力なconceptがC++1xで議論される予定です。

イベント構文はアドホック過ぎてC++には付け加えられないでしょう。
C#はperlみたいにアドホック構文バンバン導入する流儀だけど。

527 ：デフォルトの名無しさん：2011/05/24(火) 22:58:22.86

お前誰だよ

528 ：デフォルトの名無しさん：2011/05/24(火) 23:03:51.45

オレオレ俺だよ

529 ：デフォルトの名無しさん：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が
何らかの理由で漏れる可能性がある。そういう訳で当分は実装されんだろうね。

530 ：デフォルトの名無しさん：2011/05/25(水) 01:13:25.73

例外を投げるoperator+とか最悪じゃないか

531 ：デフォルトの名無しさん：2011/05/25(水) 04:13:15.58

何故そう思ったの？

532 ：デフォルトの名無しさん：2011/05/25(水) 04:14:40.92

例外のことよくわかんないからに決まってんだろ。言わせんな。恥ずかしい。

533 ：デフォルトの名無しさん：2011/05/25(水) 06:01:59.33

std::string::operator+ は bad_alloc 投げるよね。

534 ：デフォルトの名無しさん：2011/05/25(水) 07:24:55.63

operator+はともかくoperator/なら有理数とかでゼロ除算で例外投げる
可能性はあるよな。まぁ、intやdoubleが例外投げないんでそれが正しいとも言えんけど。

あと、operator+=で要素追加可能なset系のコンテナがあったとするとoperator-=で
要素削除するのは自然。コンテナに要素がないのにoperator-=したら
大体例外出すように実装するだろうね。

535 ：デフォルトの名無しさん：2011/05/25(水) 09:13:59.61

>>529
インターフェースってのはgenericsのtype constraintのことじゃね？
だから回答としては>>526の「conceptで対応する」でいいと思う

536 ：デフォルトの名無しさん：2011/05/25(水) 18:08:57.05

＞operator+=で要素追加可能なset系のコンテナ
ｵｴｯ
+を足し算以外のセマンティクスで使うのはやめて下さい
本当にやめて下さい

537 ：デフォルトの名無しさん：2011/05/25(水) 18:43:44.08

intの0除算はCPU例外を出すのが普通じゃないか

538 ：デフォルトの名無しさん：2011/05/25(水) 19:19:06.48

singned のオーバーフローで投げられる可能性も

539 ：デフォルトの名無しさん：2011/05/25(水) 20:35:23.61

もうさ全部SafeIntでいいんじゃない

540 ：デフォルトの名無しさん：2011/05/25(水) 21:13:54.76

setで+といえば普通は和集合だし-といえば差集合だよな
要素の追加削除とかないわ

541 ：デフォルトの名無しさん：2011/05/25(水) 21:53:09.94

>>536
文字列クラスの+=も否定する系？

542 ：デフォルトの名無しさん：2011/05/25(水) 22:01:48.37

要素か？

543 ：デフォルトの名無しさん：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};
※面倒なんでソートはしてない。

そういや初期化リストって、キャストはできないんだっけ？

544 ：デフォルトの名無しさん：2011/05/25(水) 22:28:00.39

>>541
文字列の結合は可換でないから加法ではないね
+記号を使うのは完全な間違いだ
別の演算子を導入したD言語が正しい

545 ：デフォルトの名無しさん：2011/05/25(水) 22:29:37.71

代入複合型も含めて四則演算子での例外はトラップ手段の無い不正落ち処理にしてしまおう。

546 ：デフォルトの名無しさん：2011/05/25(水) 22:31:16.02

よしBASICみたいに文字列結合は&で

547 ：デフォルトの名無しさん：2011/05/25(水) 22:33:00.81

浮動小数の < は順序じゃないから別のオペレータ考えるべきだねって言ってるようなもんだよ
> 可換でないから加法ではないね

548 ：デフォルトの名無しさん：2011/05/25(水) 22:39:51.77

>>546
& は優先順位的に不便。
if("a" == str1 & str2) // だめ

* がオススメ。
非可換でも誰も文句言わないし。

549 ：デフォルトの名無しさん：2011/05/25(水) 22:42:49.58

>>547
殆ど全順序のように振る舞う半順序と>>544を
一緒にするのは無理があるだろ

550 ：デフォルトの名無しさん：2011/05/25(水) 22:45:42.45

>>548
*は文字列をベクトルとみなしてかけ算したい時に困る。

551 ：デフォルトの名無しさん：2011/05/25(水) 22:48:49.93

>>550
"hello" * "world"で一体何が出来上がるんだ？

552 ：デフォルトの名無しさん：2011/05/25(水) 22:48:55.35

>>544
string last_name = name - string("mike");
みたいに引き算も用意したらある程度可換じゃね？

string("will") + ( name - string("jhone") );
これで数式らしく置換もできる。おっせぇけど。

553 ：デフォルトの名無しさん：2011/05/25(水) 22:50:54.42

文字列の掛け算は繰り返しっぽい

554 ：デフォルトの名無しさん：2011/05/25(水) 22:51:06.30

>>552
意味がわからない
それが可換性と何の関係があるんだ？

555 ：デフォルトの名無しさん：2011/05/25(水) 22:52:03.39

文字列の * はあれだよな
"x" * 3 -> "xxx"
とかだよな

556 ：デフォルトの名無しさん：2011/05/25(水) 22:52:18.57

じゃあ / か % だな
% はPythonのアレっぽいから / が一番だ

557 ：デフォルトの名無しさん：2011/05/25(水) 22:53:36.15

C++的には<<がいいんじゃね
iostreamでもつかうし

558 ：デフォルトの名無しさん：2011/05/25(水) 22:54:30.96

->*「俺の出番のようだな」

559 ：デフォルトの名無しさん：2011/05/25(水) 22:54:50.12

>>552
operator = に渡ったとき遅延評価で Add< string, Sub<string,string> >を受け取って
置換処理に渡せばある程度早くはできそうではあるな。

560 ：デフォルトの名無しさん：2011/05/25(水) 22:56:33.47

>>554
値と同列に扱えるってことじゃないの？
もしかして、2項演算子の左右可換の事言ってる？

561 ：デフォルトの名無しさん：2011/05/25(水) 22:58:09.27

あなたは値と同列に扱えることを可換と言うのか
斬新ですね

562 ：デフォルトの名無しさん：2011/05/25(水) 22:58:14.58

*の意味的には
3 * "x" -> "xxx"
のほうが綺麗だな
プログラミング的には最悪だは

563 ：デフォルトの名無しさん：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!")

うーん

564 ：デフォルトの名無しさん：2011/05/25(水) 23:04:21.64

何で++案が出ないのか

565 ：デフォルトの名無しさん：2011/05/25(水) 23:05:45.61

節子、それ単項演算子や

566 ：デフォルトの名無しさん：2011/05/25(水) 23:06:24.76

C++に2項の++なんてあったっけ

AviSynthっていう動画用スクリプト言語兼フレームサーバでは++を結合に
よく使ってますが、どうでもいいですねすみません

567 ：デフォルトの名無しさん：2011/05/25(水) 23:06:49.17

>>561
置換可能を可換というのが一般的な日本語じゃなかったっけ？
うちのおかんにとっては、CDもBlu-rayも円盤という言葉で可換な存在だ。
また、バーチャルボーイもゲーセンの筐体も、ファミコンと可換だ。

568 ：デフォルトの名無しさん：2011/05/25(水) 23:08:36.66

手こずっているようだな尻を貸そう

569 ：デフォルトの名無しさん：2011/05/25(水) 23:08:49.76

>>563
(string){"Hello ", "World"};
でよくね？

570 ：デフォルトの名無しさん：2011/05/25(水) 23:09:57.48

>>567
ここでの可換というのはオペランドが可換かどうかの話だろ。
数学用語で使う意味の可換性だべ

571 ：デフォルトの名無しさん：2011/05/25(水) 23:10:19.39

2項演算に関するコンテキストでは、可換と言ったら
交換法則、すなわち
a・b = b・a
が成立することを指し、それ以外を意味しないのが普通だと思う

572 ：デフォルトの名無しさん：2011/05/25(水) 23:12:26.10

^_^はどうよ

573 ：デフォルトの名無しさん：2011/05/25(水) 23:14:13.39

それは空気と識別子_と空気をxorしてるんですかね

574 ：デフォルトの名無しさん：2011/05/25(水) 23:18:51.85

せっかくオーバーロードあるんだし
"hello"*3=="hellohellohello"
"hello"*"world"=="helloworld"

575 ：デフォルトの名無しさん：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");

576 ：デフォルトの名無しさん：2011/05/25(水) 23:45:00.94

A ** 3 = AAA

577 ：デフォルトの名無しさん：2011/05/25(水) 23:45:19.68

>>571
まともな人間は、交換法則のことだけをさして「可換」とは言わない。

578 ：デフォルトの名無しさん：2011/05/25(水) 23:50:02.81

と言う訳で、次は結合法則の話題が続きます

579 ：デフォルトの名無しさん：2011/05/25(水) 23:53:33.95

>>577
>>544の文章を読んで、代数的な意味、つまり二項演算の交換法則の意味だと
理解できないのは、
ちょっと読解力に問題があるように思うのだが……

http://blogs.msdn.com/b/oldnewthing/archive/2011/02/11/10127845.aspx
これをお勧めしておく

580 ：デフォルトの名無しさん：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");
になって一致しないだろ。やりなおし。

581 ：デフォルトの名無しさん：2011/05/26(木) 00:23:48.45

>>551
{'h'*'w', 'e'*'o', ...}

582 ：デフォルトの名無しさん：2011/05/26(木) 00:24:32.45

そろそろスレ違いな感じもするが、
こういう話題は好きなのでそういうスレがあれば誰か教えてくれ

583 ：デフォルトの名無しさん：2011/05/26(木) 00:48:15.37

多くの人々がだいぶ前に通過した場所だけどな。
根本は+の意味を数学的な加算に限定するか一般的な追加にまで拡張するかという思想の違い。

584 ：デフォルトの名無しさん：2011/05/26(木) 00:53:52.57

ベクトルを考えたときに、加算と連結は別の演算子として欲しいってのは当たり前と思うが。
兼ねてるほうが異常。

585 ：デフォルトの名無しさん：2011/05/26(木) 00:55:48.40

できれば数学と同じテンプレートが使えるようにしたいけどね。

586 ：デフォルトの名無しさん：2011/05/26(木) 01:02:43.74

*が外積なのか内積なのか分かりにくいので、・と×を導入してください

pythonの
　for i in range(a,b):
は
　for i in [a,b)
になります

代入は:=、比較は=くらいは言語によっては実施されてるか

587 ：デフォルトの名無しさん：2011/05/26(木) 01:15:21.82

ベクトルの連結を数学っぽく書くと(a b)になるのかな

588 ：デフォルトの名無しさん：2011/05/26(木) 01:18:25.16

a | b

589 ：デフォルトの名無しさん：2011/05/26(木) 01:25:15.01

腐れ数学オタのこだわりとか心底どうでもいい

590 ：デフォルトの名無しさん：2011/05/26(木) 01:26:49.99

>>586
そこまでやるんならinじゃなくて
i <- [a, b)
と書きたいな
内包表記はPythonよりHaskellのが断然いい

591 ：デフォルトの名無しさん：2011/05/26(木) 01:31:13.64

数学ヲタがキモイから、中置記法は全廃して、全て前置記法にするのが合理的だ。

592 ：デフォルトの名無しさん：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))
とか書きたいんですよね、わかります

593 ：デフォルトの名無しさん：2011/05/26(木) 01:36:34.93

>>591
lisp化が進むんですねw

594 ：デフォルトの名無しさん：2011/05/26(木) 01:40:17.68

Python の 3 <= n < 10 みたいな書き方は正直羨ましい。

595 ：デフォルトの名無しさん：2011/05/26(木) 01:44:04.52

lispは生産性の点でちょっと…
>>594みたいな書き方は数学的だけど関数言語的じゃないし
そもそも数学って手続き的だし

596 ：デフォルトの名無しさん：2011/05/26(木) 01:49:59.50

>>595
え。。。
どの辺が手続き的？

597 ：デフォルトの名無しさん：2011/05/26(木) 01:53:20.78

純粋数学は別にいいんだけど、
実際にそれを使って証明だアルゴリズムだとなると、どうしても手続き的な使い方になるので
プログラミングとなると、さらにそういう側面が増えるし

598 ：デフォルトの名無しさん：2011/05/26(木) 01:57:16.21

タダのシンタックスシュガーだろ。難しく考えすぎ。

599 ：デフォルトの名無しさん：2011/05/26(木) 01:59:08.38

証明って手続き的か？
たとえば数学的帰納法が近いのは手続き的なループじゃなくて
関数的な再帰とパターンマッチだろうし
ニュートン法みたいな奴も、数学的に定式化する場合は要は漸化式じゃないの？

手続きといえば代入で
x = x + 1
なんだけど、これはメモリセルから値をとって1を足し、元の
メモリセルに代入するという数学的には意味のないことをやってるけど
しかしそれが手続き的プログラミングにおいては本質的

正直>>595や>>575が何を言ってるのか俺もよくわからない
Lispが生産性云々も、Lisperから見たらC++erがそれを言うのか？って感じだぞｗ

600 ：デフォルトの名無しさん：2011/05/26(木) 02:14:15.02

>>597
アルゴリズムって関数型言語の十八番な訳で、そこを否定して手続き的と言われてもな。。。

最近、数学ガールゲーデルの不完全性定理を読み終わったんだが、そこに出て来た論理体系がhaskellにそっくりでビビったぞ

601 ：デフォルトの名無しさん：2011/05/26(木) 02:22:52.72

多分想定してる分野が違う気がする
数学と言っても広い

602 ：デフォルトの名無しさん：2011/05/26(木) 07:13:27.99

>>577
まともな人間は今話している内容を考慮して
単語の意味を考えることができる。
それができないお前がバグ。

603 ：デフォルトの名無しさん：2011/05/26(木) 08:37:20.15

>>587を採用すると、
(string("Hello ") string("world!")) == string("Hello world!")
になるのか。
元々文字列リテラルの併記は結合されるし、C++には合ってるかもな。

で、オーバーロードしたいときはoperator ???……なんて書けばいいんだ？

604 ：デフォルトの名無しさん：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"));

605 ：デフォルトの名無しさん：2011/05/26(木) 20:50:57.60

コンマ演算子は確かにそれっぽいな
オーバーロードできないけど

606 ：デフォルトの名無しさん：2011/05/26(木) 20:56:46.31

->*演算子の出番のようだな

607 ：デフォルトの名無しさん：2011/05/26(木) 20:58:04.30

.*もあるな

608 ：デフォルトの名無しさん：2011/05/26(木) 21:02:02.29

std::string operator()(std::string const&, std::string const&);
auto helloworld = std::string("hello")("world")("!");

609 ：デフォルトの名無しさん：2011/05/26(木) 21:16:37.33

そんな変態用法、イラン

610 ：デフォルトの名無しさん：2011/05/26(木) 21:33:26.76

>>605
コンマはオーバーロードできるよ。
&& や || ができるんだから当然。

611 ：デフォルトの名無しさん：2011/05/27(金) 00:28:20.08

マクロ＋コンマ演算子オーバーロードによる可変長引数的変態関数

612 ：デフォルトの名無しさん：2011/05/27(金) 00:36:21.51

( eval,( output,( concat,"Hello"," ","World" ) ) );

613 ：デフォルトの名無しさん：2011/05/27(金) 00:43:26.90

やっぱりカンマは要らないな

614 ：デフォルトの名無しさん：2011/05/27(金) 00:47:52.29

そもそも関数型言語なら本質的にリスト作成以外の目的で括弧いらんだろ

615 ：デフォルトの名無しさん：2011/05/27(金) 01:27:57.33

それはないだろ

616 ：デフォルトの名無しさん：2011/05/27(金) 01:54:48.73

引数の数が固定なら構文解釈の結果は一意に定まるだろ

617 ：デフォルトの名無しさん：2011/05/27(金) 04:04:04.75

中置演算子の優先順位とか

618 ：デフォルトの名無しさん：2011/05/28(土) 15:11:08.27

>>594
便利さはわかるけど、冷静に考えたら、
曖昧卓。

そう感じるのはC脳だからか？

619 ：デフォルトの名無しさん：2011/05/28(土) 15:16:29.72

operator overloadで、
x < y < z
をうまくユーザ定義できる方法があるなら取り込んでもいいと思う。
アドホックな導入ならいらない。

620 ：デフォルトの名無しさん：2011/05/28(土) 15:22:23.23

>>618
そもそも文と式の使い方や暗黙的型変換がCとPythonじゃ違いすぎるからなあ

621 ：デフォルトの名無しさん：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回）

622 ：デフォルトの名無しさん：2011/05/28(土) 16:17:26.08

rangeの概念を一般化して取り入れるべきだと考えている人もいるようだから
あるいはc++でもそのうちこんな記述が･･･ [n] & [3,10)

623 ：デフォルトの名無しさん：2011/05/28(土) 16:22:49.73

[,)を認めると、構文解析器が悲鳴を挙げないか？

624 ：デフォルトの名無しさん：2011/05/28(土) 16:24:04.18

operator<(int,int)とかoperator*(T*)とかの再定義の話になるからなあ

625 ：デフォルトの名無しさん：2011/05/28(土) 16:28:15.84

>>621
> 構文レベルで全く違う意味になっちゃうからな。

( ﾟдﾟ)ﾎﾟｶｰﾝ
構文レベルで意味…

626 ：デフォルトの名無しさん：2011/05/28(土) 16:35:30.56

おーぶんってライブラリがRange関係の機構を扱ってるらしい。
ライブラリでどうにかなるならライブラリでいいじゃない。

627 ：デフォルトの名無しさん：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 さんみたく生まれ変わらせるのはありかも

628 ：デフォルトの名無しさん：2011/05/28(土) 16:46:41.74

>>621
リスプ
(< a b c)
c++ もこうしてしまえばww
<(a b c)

629 ：デフォルトの名無しさん：2011/05/28(土) 16:52:01.50

Pythonだと a < b > c とも書けるみたいだから、
>>628 みたいにはいかないよね。
(a < c < b に置き換えられたら別の意味になっちゃうし)

ライブラリとかじゃなくて言語が頑張るような機能じゃないかなと思う。

630 ：デフォルトの名無しさん：2011/05/28(土) 16:53:46.29

>>629
> Pythonだと a < b > c とも書けるみたいだから、

ぶっちゃけ、これはあり得ない局面ではないがいらんだろ。

631 ：デフォルトの名無しさん：2011/05/28(土) 16:54:07.34

a < b > c
はなんかおかしい

632 ：デフォルトの名無しさん：2011/05/28(土) 17:06:56.81

すなおにb > max(a,c)って書けよと

633 ：デフォルトの名無しさん：2011/05/28(土) 17:33:38.76

if (o<O>o)

634 ：デフォルトの名無しさん：2011/05/28(土) 17:36:10.62

もう、変態的なコード止めてくれる？

635 ：デフォルトの名無しさん：2011/05/28(土) 17:44:30.92

>>633
タングラムさん、なにやってんすか。

636 ：デフォルトの名無しさん：2011/05/28(土) 18:36:12.71

a < b > c はテンプレートで困るん

637 ：デフォルトの名無しさん：2011/05/28(土) 19:11:01.45

Pythonの__cmp__みないのがないと無理

638 ：デフォルトの名無しさん：2011/05/28(土) 19:14:46.14

__nlp__

639 ：デフォルトの名無しさん：2011/05/28(土) 20:16:13.63

>>625
構文解析と意味解析は分離できるのが理想だが
C++の変態構文ではとてもじゃないが分離不可能

640 ：デフォルトの名無しさん：2011/05/28(土) 22:49:49.49

>>639
そういやそれってよく聞くけどどこら辺が面倒なの？

未だによくわからないんだが…

641 ：デフォルトの名無しさん：2011/05/28(土) 23:44:00.98

良い例がこれだな
識別子の意味が定まってないと<や>は不等号か山括弧か判断付かない
ttp://d.hatena.ne.jp/DigitalGhost/20090216/1234793122

642 ：デフォルトの名無しさん：2011/05/28(土) 23:56:45.38

WalterﾀﾝがC++が変態過ぎて辟易して
構文解析と意味解析が完全に分離されたD言語作った程

643 ：デフォルトの名無しさん：2011/05/29(日) 10:40:55.11

>>641
なるほど！
どうもありがとう

644 ：デフォルトの名無しさん：2011/05/29(日) 10:45:36.13

>>641
それ、C++0xだとエラーにならない？

645 ：デフォルトの名無しさん：2011/06/01(水) 21:01:15.73

n3290.pdfもn3291.pdfもみれなくなってしまった

646 ：デフォルトの名無しさん：2011/06/01(水) 22:43:05.51

n3291は持ってるからどうでもいい

647 ：デフォルトの名無しさん：2011/06/02(木) 01:10:57.13

へぇ。ローカルに確保しといて正解だった。

648 ：デフォルトの名無しさん：2011/06/02(木) 07:21:53.16

直列化って何で規格に入らないんだ？
ちょっとした通信したいときにめんどい。

649 ：デフォルトの名無しさん：2011/06/02(木) 08:17:31.76

>>648
ちょっとした用途ならboost::serializationが便利

650 ：デフォルトの名無しさん：2011/06/02(木) 09:31:22.99

いやいやいやそういう話じゃない

651 ：デフォルトの名無しさん：2011/06/02(木) 20:18:27.67

standard-layoutが規格化されてるからそれで充分だろ
通信は自分でやれ

652 ：デフォルトの名無しさん：2011/06/02(木) 20:52:46.34

パディングが入って32bitと64bitで互換がない、
またコンパイラによっても互換が無いので却下。
パディングをパックしろっつうのも目先しか
見えてないアホがやる事なので却下。

653 ：デフォルトの名無しさん：2011/06/02(木) 21:34:06.01

つalignas

654 ：デフォルトの名無しさん：2011/06/03(金) 00:01:32.51

stdint.h

655 ：デフォルトの名無しさん：2011/06/03(金) 01:47:49.72

C with Classesのころのシンプルさに戻して欲しい

656 ：デフォルトの名無しさん：2011/06/03(金) 01:52:52.32

だから、自分の使えない機能は使わなければいいだけ。

657 ：デフォルトの名無しさん：2011/06/03(金) 01:55:48.50

馬鹿が使いたがるのが困るんだって

658 ：デフォルトの名無しさん：2011/06/03(金) 01:59:04.48

そういうジャップはEmbedded C++でもシコシコ作ってろ

659 ：デフォルトの名無しさん：2011/06/03(金) 08:26:19.77

C with の時点ですでにシンプルではない

660 ：デフォルトの名無しさん：2011/06/03(金) 08:36:48.12

むしろrange based forとかnullptrやstrong enumは馬鹿こそ使うべきなんだけどな

661 ：デフォルトの名無しさん：2011/06/03(金) 08:54:50.86

シンプルだよねぇ

662 ：デフォルトの名無しさん：2011/06/03(金) 08:59:30.65

C++は馬鹿ホイホイ

663 ：デフォルトの名無しさん：2011/06/03(金) 09:41:35.41

strong enumさんとinitializer_listさん早く来ないかなー。

664 ：デフォルトの名無しさん：2011/06/03(金) 20:59:30.34

unique_ptr や shared_ptr のように null_ptr にしてほしかった

665 ：デフォルトの名無しさん：2011/06/04(土) 10:16:39.83

initializer_listを受け取るコンストラクタはexplicit指定外すべき？
hoge h = {...};
explicitにすると↑が出来なくなって無意味化するよね？

666 ：デフォルトの名無しさん：2011/06/04(土) 11:46:54.32

hoge h{...};
って書けばいいよ

667 ：デフォルトの名無しさん：2011/06/04(土) 15:41:01.12

キモイ

668 ：デフォルトの名無しさん：2011/06/05(日) 02:25:37.47

キモナイ

669 ：デフォルトの名無しさん：2011/06/05(日) 12:37:56.53

本の虫の人が出す本が、Ray Lischner の
C++ in a Nutshell を越えることを期待している

詳説C++ の第３版出ないかな
C++ in a Nutshell の0x対応版も出てほしい

670 ：デフォルトの名無しさん：2011/06/05(日) 13:46:59.48

C++0x本って出るのいつなんだ？

671 ：デフォルトの名無しさん：2011/06/05(日) 13:54:58.60

常識的に考えればまずは規格が正式に固まってからだろ

672 ：デフォルトの名無しさん：2011/06/05(日) 15:04:04.90

つまらない常識だな。
実務でリファレンスとして使うならそれでいいが、
今後どうなるかを知るための策定中規格の解説書にも需要はあると思うけどな。

673 ：デフォルトの名無しさん：2011/06/05(日) 15:15:13.96

もうFDISだから固まったようなもんだろ

674 ：デフォルトの名無しさん：2011/06/05(日) 15:27:18.65

conceptﾄﾞｺｰ

675 ：デフォルトの名無しさん：2011/06/05(日) 15:33:01.05

お星様になったんだよ

676 ：デフォルトの名無しさん：2011/06/05(日) 15:49:36.04

concept に根を下ろし　template と共に生きよう
auto と共に冬を越え　decltype と共に春を歌おう
どんなに恐ろしい構文を持っても
たくさんの可哀想な委員会を操っても
コンパイラから離れては生きられないのよ

677 ：デフォルトの名無しさん：2011/06/05(日) 16:13:33.29

concept は滅びぬ！何度でもよみがえるさ！

# 実際、今回の規格が発行したら、すぐに再燃するだろうな

678 ：デフォルトの名無しさん：2011/06/05(日) 16:13:56.63

ジェネリックは滅びぬ、何度でもよみがえるさ、抽象化の力こそ人類の夢だからだ！！

679 ：デフォルトの名無しさん：2011/06/05(日) 16:36:40.93

コンセプトマップ使えば、

int i = int.parse("0xff");

みたいに書けるようになってほしい。

680 ：デフォルトの名無しさん：2011/06/05(日) 16:40:06.86

知らんけど Ruby みたい

681 ：デフォルトの名無しさん：2011/06/05(日) 16:50:48.42

組み込み型にメンバ関数持たせたり継承できたりするのはキモイ
LL厨やOO厨が何と言おうとキモイもんはキモイ

682 ：デフォルトの名無しさん：2011/06/05(日) 17:30:09.34

組込み型だけが何か特殊な性質を持つ方がキモイわ

683 ：デフォルトの名無しさん：2011/06/05(日) 17:34:38.89

組み込み型は現実に特殊なんだよ
intは数値を表すバイト列そのものであるべきであって、間違ってもvtblなんか持っちゃいけないんだよ
VM持ちの言語ならそれでもいいのかもしれないけどCやC++では絶対ダメ

684 ：デフォルトの名無しさん：2011/06/05(日) 17:45:13.27

べつにint自体には影響ないから問題ないだろ

685 ：デフォルトの名無しさん：2011/06/05(日) 17:55:03.34

校長先生の本がついに出るとな
http://hibari.2ch.net/test/read.cgi/tech/1304856318/704

686 ：デフォルトの名無しさん：2011/06/05(日) 17:58:33.79

int* p = new DerivedTypeFromInt();
delete p; // あぼーん

int に vtable を持たせないとこうなる

でも derivable<int> みたいな感じで int とまったく同じに使えるのに継承可能なテンプレートは欲しい
少なくともコンパイルタイム有理数とかよりは需要あると思う

687 ：デフォルトの名無しさん：2011/06/05(日) 18:01:38.85

そもそもintは継承できないだろ

688 ：デフォルトの名無しさん：2011/06/05(日) 18:10:22.31

>>687
intが継承できないのは vtable 持たせられないからだ、というレスに
int には影響ないからいい、というレスがついていたので、
いや、int に影響を与えないとまともに継承できないじゃないか、というレスをつけた。

689 ：デフォルトの名無しさん：2011/06/05(日) 20:07:15.76

>>686
> でも derivable<int> みたいな感じで int とまったく同じに使えるのに継承可能なテンプレートは欲しい
> 少なくともコンパイルタイム有理数とかよりは需要あると思う

はあ？

690 ：デフォルトの名無しさん：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;
}
}

あまりいいやり方とは思えない

691 ：デフォルトの名無しさん：2011/06/05(日) 20:41:25.46

>>686
?
仮想メンバーを一切持たないオブジェクトも問題なくdeleteできるんだけど。

692 ：デフォルトの名無しさん：2011/06/05(日) 20:55:58.45

できねえよ
お前は何を言ってるんだ

693 ：デフォルトの名無しさん：2011/06/05(日) 21:06:13.91

>>691はvtblがないオブジェクトとは言ってないからdelete出来る

論点はずれてる

694 ：デフォルトの名無しさん：2011/06/05(日) 21:14:06.04

>686
スライシングを避けるためには参照かポインタで持たなきゃいけないけど、
組込み型を参照とかポインタで持つことはほとんど無いからメリット無いんじゃね？

695 ：デフォルトの名無しさん：2011/06/05(日) 21:22:24.76

>>694
いや、組み込み型をポインタで持ちたいんじゃなくて
クラスのオブジェクトを組み込み型のポインタに入れたいんだよ。
でないと継承する意味ないよね。

696 ：デフォルトの名無しさん：2011/06/05(日) 21:24:00.81

何にせよ仮想デストラクタのない型でやる事じゃないわ
恐ろしすぎる

697 ：デフォルトの名無しさん：2011/06/05(日) 21:33:07.48

intのデストラクタをprotectedにしようぜ！

698 ：デフォルトの名無しさん：2011/06/05(日) 22:00:28.54

継承せずに使わせてよ

699 ：デフォルトの名無しさん：2011/06/05(日) 23:32:57.87

拡張メソッドみたいなのじゃだめなのか

700 ：デフォルトの名無しさん：2011/06/05(日) 23:38:17.22

そもそも「.」の左側と右側を区別する必要があるのかどうか

701 ：デフォルトの名無しさん：2011/06/06(月) 00:19:08.28

>>695
入れればいいじゃん。

702 ：デフォルトの名無しさん：2011/06/06(月) 00:51:27.01

>>695
vtableを持たない親classのポインタに子を入れても、
親classのポインタをdeleteしなけりゃ別に問題ない。

てか、親classのポインタでdeleteするヤツいる？
個人的には全くといっていいほどしたこと無いけど。

703 ：デフォルトの名無しさん：2011/06/06(月) 00:55:45.21

そらもういくらでも

704 ：デフォルトの名無しさん：2011/06/06(月) 01:14:23.96

スライシングとかdeleteミスとかはshared_ptrで回避できるのにな。

>682
単に組込み型をラップするクラスを用意してそっちを使えば良いと思うけどな。

705 ：デフォルトの名無しさん：2011/06/06(月) 02:25:04.78

int相手にdynamic deleterとか嫌だよ

706 ：デフォルトの名無しさん：2011/06/06(月) 10:46:32.49

conceptは無駄にプログラムが長くなるだけ
コンパイルエラーが出たらクラスの定義見ればいいし

707 ：デフォルトの名無しさん：2011/06/06(月) 10:48:24.01

>>706
> conceptは無駄にプログラムが長くなるだけ

全く逆

708 ：デフォルトの名無しさん：2011/06/09(木) 12:16:08.65

ムーヴコンストラクタはデフォルト指定出来るのにムーヴ代入はできないのか？中途半端やなぁ…

709 ：デフォルトの名無しさん：2011/06/09(木) 12:24:50.51

できるぞ。

710 ：デフォルトの名無しさん：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月頃かな。

711 ：デフォルトの名無しさん：2011/06/11(土) 17:12:53.41

で、行列の積の問題は、moveで解決できるのでしょうか？

712 ：デフォルトの名無しさん：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 はエスパーか？

右項が正方行列な積の一次オブジェクトは左項の１行分だけ確保すれば十分なので
右辺値参照使うならそういう対処ができる

右項が長方行列な積であれば左項と結果のサイズが変わるので
結果は新しいオブジェクトを作るしかないが
その結果と足し算をするとか言う場合のために右辺値参照を返すのには価値はある

このくらいの事しか言えない

713 ：デフォルトの名無しさん：2011/06/11(土) 23:10:26.65

つまり、無理矢理右辺値参照を使うことは出来るが、効率的に意味がない、
という理解でよろしいでしょうか？

714 ：デフォルトの名無しさん：2011/06/11(土) 23:28:45.17

まず「行列の積の問題」とやらを明確にしてください

715 ：デフォルトの名無しさん：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の導入で効率をよくできる。

716 ：デフォルトの名無しさん：2011/06/12(日) 01:51:37.15

ん？右辺値参照って、原則無名のオブジェクトを参照している事を保証してる参照じゃねぇの？

717 ：デフォルトの名無しさん：2011/06/12(日) 01:59:09.64

いや、代入/コピーの右辺値の意味をユーザ定義できる機構。

718 ：デフォルトの名無しさん：2011/06/12(日) 02:18:32.93

そういやそうか、

std::string &&value = std::string("これやると危険だもんな");
typeA a = value;//valueが破壊される
typeB a = value;//おそらくセグフォ

719 ：デフォルトの名無しさん：2011/06/12(日) 02:19:15.24

>>713
どう読んだらそうなるんだ

720 ：デフォルトの名無しさん：2011/06/12(日) 02:26:45.74

無制限に無名オブジェクトを取れる訳じゃなく、
引数に取れる場合しか使えないって事だろ。

721 ：デフォルトの名無しさん：2011/06/12(日) 04:03:22.54

>>718
その定義だとvalueは右辺値を参照する左辺値だからvalueは破壊されない。
というか右辺値参照を思いっきり勘違いしてる気が。

722 ：デフォルトの名無しさん：2011/06/12(日) 09:06:08.66

そんなに右辺値参照の基本部分って難しいかねぇ？

723 ：デフォルトの名無しさん：2011/06/12(日) 10:31:43.06

３行で

724 ：デフォルトの名無しさん：2011/06/12(日) 15:33:55.49

変数に
割り当てられていない
値

725 ：デフォルトの名無しさん：2011/06/12(日) 17:26:07.53

「割り当てる」って代入のこと？

726 ：デフォルトの名無しさん：2011/06/12(日) 18:17:52.81

この世界で"割り当てる"のはメモリ(領域)だろ

727 ：デフォルトの名無しさん：2011/06/12(日) 18:24:30.61

対象となる目的語を聞いているのではなく、動詞の意味を聞いているのだけど。

「変数に（メモリ(領域)を）割り当てられない」とは、C++で具体的にどういう操作ができないということ？
「変数へ代入できない」とは別の意味？

728 ：デフォルトの名無しさん：2011/06/12(日) 18:38:34.81

>>727
ちゃんと読めよ。
「割り当てられていない」であって
「割り当てられない」ではないぞ。

729 ：デフォルトの名無しさん：2011/06/12(日) 18:42:21.43

了解。

つまり、
「変数に（メモリ(領域)を）割り当てられていない値」
が右辺値参照ということだね。

730 ：デフォルトの名無しさん：2011/06/12(日) 18:48:32.31

変数に束縛されていない値と言うべきかな

731 ：デフォルトの名無しさん：2011/06/12(日) 18:51:05.27

それは右辺値参照ではなく右辺値の説明では

732 ：718：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に渡される値は演算子の結果若しくは、関数の戻り値のみ。

733 ：デフォルトの名無しさん：2011/06/12(日) 19:25:07.86

std::moveの事もたまには思い出してやってください

734 ：デフォルトの名無しさん：2011/06/12(日) 20:23:39.19

> source.array = 0;//これが可能なのが右辺値って事じゃねぇの？
可能不可能でいうなら左辺値をconstでない普通の参照で受けても出来るけど。

735 ：デフォルトの名無しさん：2011/06/12(日) 20:45:42.50

右辺値参照って、要するに一時オブジェクトを束縛して、
消え行くオブジェクトのオーバーヘッドを減らして効率上げる機構だよね？？？
関数とかで返却されるオブジェクトのディープコピーよりももっと手数を短くしたいっていう欲求というか。。。

736 ：デフォルトの名無しさん：2011/06/12(日) 20:47:26.77

>>735
それは応用のひとつに過ぎない。

737 ：735：2011/06/12(日) 20:52:37.93

うそん。これだけだと・・・。
あと何があるのかなぁ？？？

738 ：デフォルトの名無しさん：2011/06/12(日) 21:00:05.33

右辺値参照は、右辺値の振る舞いを自由に定義できるローレベル機構。

あるオブジェクトが右辺値参照される回数をカウントしてログ取るだけでもいいし、
smart pointerのよりエレガントな実装に使ってもいい。

C++は>>735のような用途限定の機構は規格には入らない。

739 ：デフォルトの名無しさん：2011/06/12(日) 21:02:46.03

>>738
そりゃ屁理屈だろ。
別にthrowはif & dynamic_cast代わりにつかえるつってんのとかわんねぇじゃん。
そりゃ使えるだろよ。

740 ：デフォルトの名無しさん：2011/06/12(日) 23:19:01.22

ビットシフト演算子をストリームにとかあるし・・・

741 ：デフォルトの名無しさん：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誕生。

742 ：デフォルトの名無しさん：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脳になってしまう。

743 ：デフォルトの名無しさん：2011/06/13(月) 01:14:22.80

lvalueとrvalueで話がされてるけど、この概念も拡張されたんだよね？

744 ：デフォルトの名無しさん：2011/06/13(月) 01:20:52.73

そういやxvalueとか居たなぁ。

745 ：デフォルトの名無しさん：2011/06/13(月) 01:25:21.11

右辺値参照がlvalueとrvalueの相の子のような妙な代物になってしまったので
専用の名前（xvalue）を作って整理しただけで別に新しいことはないよ

746 ：デフォルトの名無しさん：2011/06/13(月) 01:27:30.51

int value;
const int &xvalue = function();
int &prvalue = value;

こういうことか。

747 ：デフォルトの名無しさん：2011/06/13(月) 12:23:39.58

右辺値参照で右辺値を束縛したら、その右辺値参照がスコープ外れて破棄されるまで値が束縛されるってことでいいん？
こんな感じに取った場合。
http://ideone.com/mghMo

748 ：デフォルトの名無しさん：2011/06/13(月) 16:47:10.23

effective 0xが出るまでは安心して使えないと思う

749 ：デフォルトの名無しさん：2011/06/14(火) 21:54:05.98

>>733

えっ？　move終わったの？

そもそも、いつのまにforwardなるものが･･･

750 ：デフォルトの名無しさん：2011/06/14(火) 23:22:26.11

>>749
最初から。(>>742)

751 ：デフォルトの名無しさん：2011/06/14(火) 23:28:27.75

いつまで考えてるつもりなの？
シェアなくなるまで？

752 ：デフォルトの名無しさん：2011/06/15(水) 02:00:43.79

753 ：デフォルトの名無しさん：2011/06/15(水) 08:18:15.93

いつISになるのかって話なら、3月にFDISが承認されたから今年の夏ごろ発行される予定と聞いたが

754 ：デフォルトの名無しさん：2011/06/15(水) 09:47:25.40

>>751

お前が首を吊るまでｗ

755 ：デフォルトの名無しさん：2011/06/15(水) 14:13:32.09

http://d.hatena.ne.jp/faith_and_brave/20081009/1223548246
なんで野家は漢字でいいんですか？

756 ：忍法帖【Lv=12,xxxPT】：2011/06/15(水) 14:17:47.02

u"ってしてるから

757 ：デフォルトの名無しさん：2011/06/15(水) 14:21:30.78

理屈の上ではそうですが実際は違うくないですか？

758 ：デフォルトの名無しさん：2011/06/15(水) 18:16:44.87

実際って具体的に何のどこを指しているんだ

759 ：デフォルトの名無しさん：2011/06/16(木) 12:22:07.48

>>755
野家が漢字でかまわないのは今まで通り。
(コンパイラがソースのキャラクターセットに対応している限り)

\U00020BB7 は\uffff より大きいことからわかるように
(多分)下の棒が長い吉。SJISのソースには書けないからエスケープされてる。

760 ：デフォルトの名無しさん：2011/06/17(金) 01:09:50.26

これ、楽しそうね。
http://cppandbeyond.com/

761 ：デフォルトの名無しさん：2011/06/18(土) 00:25:13.55

んでお前らは0x仕事で使えるようになった？

762 ：デフォルトの名無しさん：2011/06/18(土) 00:30:19.76

その前にC99を使えるようにしてください

763 ：デフォルトの名無しさん：2011/06/18(土) 04:27:16.93

autoとラムダ式とスマートポインタとarrayくらいだな。

764 ：デフォルトの名無しさん：2011/06/18(土) 06:21:39.54

関数型言語見切った
一人で作るならC++最強だな

765 ：デフォルトの名無しさん：2011/06/18(土) 07:35:26.21

nullptr、= default、= delete、スマートポインタは読みやすくなりそうだけど
autoとかはどのくらいの目安で使えばいいのか迷う

766 ：デフォルトの名無しさん：2011/06/18(土) 09:02:43.78

for (auto itr = hoge.begin(); ... )

767 ：デフォルトの名無しさん：2011/06/18(土) 09:50:10.70

auto i=3;じゃなくて、いきなりi=3;とか書ければいいのに

768 ：デフォルトの名無しさん：2011/06/18(土) 09:52:21.30

それはもう別物だろう
変数の宣言が必要のない言語なんてあるのか？

769 ：デフォルトの名無しさん：2011/06/18(土) 09:52:50.87

lua

770 ：デフォルトの名無しさん：2011/06/18(土) 09:56:44.82

Haskell

771 ：デフォルトの名無しさん：2011/06/18(土) 10:01:45.71

autoって書くのはLuaでlocalと書いたりHaskellでletと書いたりするのと同じじゃね

まあPythonあたりだとなんも無いけど、そのかわり関数スコープで
ブロックスコープ相当の機能はないし
上位スコープの変数を更新するのにいちいちglobal文やnonlocal文が必要だし
既存の変数を書き換えるつもりでtypoしても処理系はエラーを検出できないよ

772 ：デフォルトの名無しさん：2011/06/18(土) 10:03:45.24

for (const auto x : { 1,3,5,7,11 }) cout << x << '\n';

773 ：デフォルトの名無しさん：2011/06/18(土) 10:04:48.11

いや、C++にautoはあっていいけど、>>768みたいに言われるとね

774 ：デフォルトの名無しさん：2011/06/18(土) 10:21:58.60

>>767-768
古いCだな。

775 ：デフォルトの名無しさん：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) { ... });

こういう書き方が出来ればいいのに。

776 ：デフォルトの名無しさん：2011/06/18(土) 11:45:56.44

むしろ、こうしたい。
v.sort([&](const auto &lhs, const auto &rhs) { ... });

777 ：デフォルトの名無しさん：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) { ... });

778 ：デフォルトの名無しさん：2011/06/18(土) 11:59:29.23

マクロでも使えば？

779 ：デフォルトの名無しさん：2011/06/18(土) 12:02:04.70

もしvの型がベクターの参照で宣言されていたら

780 ：デフォルトの名無しさん：2011/06/18(土) 13:05:40.75

参照型から元の型に変換する型関数書いてそれを適用したものをdecltype

781 ：デフォルトの名無しさん：2011/06/18(土) 14:24:37.98

decltypeってキーワード長過ぎ

782 ：デフォルトの名無しさん：2011/06/18(土) 14:34:30.23

__tぐらいにしてくれ

783 ：デフォルトの名無しさん：2011/06/18(土) 14:48:03.45

#define ty decltype

784 ：デフォルトの名無しさん：2011/06/18(土) 16:48:52.69

perlでやれ

785 ：デフォルトの名無しさん：2011/06/18(土) 20:39:50.29

キーワードでなく、メンバにしてしまえばいいのさ
v.type みたいに

786 ：デフォルトの名無しさん：2011/06/18(土) 20:51:57.03

るびーみたいだな
あれは動的にやってるから解釈は簡単だけどそういうのをコンパイル時にするとなると一体どうなるのか
Dみたいにコンパイル時インタプリタ走らせてみるか？ｗ

787 ：デフォルトの名無しさん：2011/06/19(日) 01:30:26.64

C++テンプレートもチューリング完全ですよ。

788 ：デフォルトの名無しさん：2011/06/19(日) 01:31:18.78

誤爆

789 ：デフォルトの名無しさん：2011/06/19(日) 07:41:16.38

constexprがある以上、C++もコンパイル時インタプリタは走ってるはずw

790 ：デフォルトの名無しさん：2011/06/19(日) 20:08:06.28

めんどくさいから, もう()だらけのポーランド記法でいいよぉwwW

791 ：デフォルトの名無しさん：2011/06/19(日) 22:53:38.73

>>789
exprに制限あるけどな。

792 ：デフォルトの名無しさん：2011/06/21(火) 01:46:41.72

コンパイル時インタプリタに相当するものを走らせないといけない最たる場面ってSFINAEじゃ？
constexprよりもSFINAEのほうが面倒見なければいけない範囲が圧倒的に広い

793 ：デフォルトの名無しさん：2011/06/21(火) 04:39:42.41

なにいってんだお前は。
SFINAEがなければ、単にコンパイルエラーになるだけだ。

794 ：デフォルトの名無しさん：2011/06/23(木) 01:16:19.03

substitution failure の判定にコンパイル時インタプリタ相当のものが必要になるのでは？
ただし計算しなければいけないのは syntax の受理・不受理だけになるとは思いますけれど．

795 ：デフォルトの名無しさん：2011/06/23(木) 09:52:14.40

コマンドの出力をそのままインクルードできれば簡単なのに

796 ：デフォルトの名無しさん：2011/06/23(木) 10:45:23.57

Makeでやれと言われそう

797 ：デフォルトの名無しさん：2011/06/23(木) 11:23:43.68

>>794
何のインタープリタと主張してますか?
C++のインタープリタじゃないですよね?

798 ：デフォルトの名無しさん：2011/06/23(木) 12:01:40.38

>>797
あー，インタプリタという言葉を使うのは完全にまずいですね．すいません．
C++ のメタコンパイラ（？）とでも呼べるような機構が
substitution failure の判定のために走っている，ぐらいの表現になるかと思います．

799 ：デフォルトの名無しさん：2011/06/23(木) 13:03:47.19

お前の独自用語だと、文法エラーや意味エラーを判定するのは全部メタコンパイラだな。

800 ：デフォルトの名無しさん：2011/06/23(木) 15:15:09.39

議論するなら使う単語の定義の認識合わせしないと

801 ：デフォルトの名無しさん：2011/06/23(木) 22:16:46.08

新しい言語には NullPointerException を言語レベルでサポートして欲しい
出るたびに「ぬるぽ」と口に出してほくそ笑むのに必要

802 ：デフォルトの名無しさん：2011/06/23(木) 23:35:22.23

throw nullptr;

胸が熱くなるな

803 ：デフォルトの名無しさん：2011/06/24(金) 04:38:01.65

void *でcatch出来るのかな

804 ：デフォルトの名無しさん：2011/06/24(金) 10:25:45.35

>>802
なんか違うような……

805 ：デフォルトの名無しさん：2011/06/24(金) 15:54:59.70

>>802
手が滑ってヌルッとウナギみたいにすり抜けそう

806 ：デフォルトの名無しさん：2011/06/24(金) 16:22:39.92

>>802
gatch

807 ：デフォルトの名無しさん：2011/06/24(金) 18:06:59.44

ぬるっと滑ったらぽっと落ちる

808 ：デフォルトの名無しさん：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 ) {
　　...
}
みたいな感じ？誰も投げないと思うけど。。

809 ：デフォルトの名無しさん：2011/06/24(金) 21:32:24.36

try {
　　throw nullptr;
} catch ( std::nullptr_t gatt ) {
　　...
}

810 ：デフォルトの名無しさん：2011/06/24(金) 22:38:39.79

捕まえても変数に対して出来ることが無いな
catch ( std::nullptr_t )

811 ：デフォルトの名無しさん：2011/06/24(金) 22:56:23.75

std::nullptr_tってクラスかもしれないだろ

812 ：デフォルトの名無しさん：2011/06/24(金) 23:32:40.18

nullptrを捕まえられれば本望

813 ：デフォルトの名無しさん：2011/06/25(土) 00:30:13.71

普通にそれで動くで

814 ：デフォルトの名無しさん：2011/06/25(土) 08:47:58.94

segvをキャッチしたいって話じゃなかったっけ……？

815 ：デフォルトの名無しさん：2011/06/25(土) 10:11:04.20

つまらない奴だな

816 ：デフォルトの名無しさん：2011/06/26(日) 14:01:29.91

unionに普通のクラスとか載せれる（コンストラクタは勝手に走らない）ようになったってことは
template <class Foo> union Bar { Foo foo; };
これだけでFooの為のアラインドストレージになるってこと？

817 ：デフォルトの名無しさん：2011/06/26(日) 14:13:58.68

unionはアラインの保証なんかしないぞ。
アラインされたストレージが欲しければ、そのまんまの名前のaligned_storageがある。
ちなみに、アラインされたunionが欲しければ、これまたそのまんまの名前のaligned_unionがある。
単にクラスや変数のアラインを指定したいならalignasを使え。

818 ：デフォルトの名無しさん：2011/06/26(日) 14:16:20.43

unionってすべてのメンバに対してアラインが取れてる仕様じゃなかったっけ？
0xで変更になったの？

819 ：デフォルトの名無しさん：2011/06/27(月) 00:24:29.93

ぬるぽっぽ

820 ：天使 ◆uL5esZLBSE ：2011/07/02(土) 12:00:08.47

>>817
＞アラインされたストレージが欲しければ、そのまんまの名前のaligned_storageがある。
↑↑↑ハッアアアァアアア？？？？？？？？？？？

本当にバカだな
なんだ、ただのゴミか

821 ：デフォルトの名無しさん：2011/07/02(土) 12:04:17.05

>>818
で、これは結局どうなんですか？
このスレにはこんなことにも答えられない素人しかいないんですかね？
そんな人たちの一人が本を書こうとしてるなんて世も末ですね

822 ：デフォルトの名無しさん：2011/07/02(土) 12:12:30.56

夏休みはじまった

823 ：デフォルトの名無しさん：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 はどうなっててもいい。

これで満足かい？

824 ：デフォルトの名無しさん：2011/07/02(土) 17:28:26.25

番号も書かずに規格を語るな

825 ：デフォルトの名無しさん：2011/07/02(土) 18:19:46.87

最初からこんな所に頼らず
てめえで仕様読めよ

826 ：デフォルトの名無しさん：2011/07/02(土) 18:41:58.32

敗北宣言乙

827 ：デフォルトの名無しさん：2011/07/02(土) 18:51:21.83

脱北宣言に見えた

828 ：デフォルトの名無しさん：2011/07/02(土) 18:53:26.82

俺は脱糞宣言に見えた

829 ：デフォルトの名無しさん：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の要素で削除部分を埋める
　　実装が可能なため)

830 ：デフォルトの名無しさん：2011/07/03(日) 03:12:36.61

unorder_setとunorder_mapな
1. その名の通りbegin()からend()まで走れば全部舐めること以外は実装定義
2. ならない

831 ：デフォルトの名無しさん：2011/07/03(日) 03:17:40.19

てかそもそも削除できるのか？
どうやって対象の要素を空にする？

832 ：デフォルトの名無しさん：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);
}
//略
};

833 ：デフォルトの名無しさん：2011/07/03(日) 04:57:50.85

erase

834 ：デフォルトの名無しさん：2011/07/03(日) 05:33:09.06

普通vector<list<T>>じゃないの？

835 ：デフォルトの名無しさん：2011/07/03(日) 07:57:43.68

普通vector<set<T>>かvector<map<T>>だろ
listとかあほか

836 ：デフォルトの名無しさん：2011/07/03(日) 08:25:40.74

>>835
unorderの実装なのにsetやmap使ってどーすんだよ

837 ：デフォルトの名無しさん：2011/07/03(日) 08:34:20.03

え？

838 ：デフォルトの名無しさん：2011/07/03(日) 08:38:32.75

もうやだこいつ>>836
ハッシュテーブル使ってるからunorderedなんだろ

839 ：デフォルトの名無しさん：2011/07/03(日) 08:50:17.52

operator <(less<T>かも)を要求されないからunorderだろーが

840 ：デフォルトの名無しさん：2011/07/03(日) 08:52:32.38

アドレスの比較で十分

841 ：デフォルトの名無しさん：2011/07/03(日) 08:53:46.36

え？

842 ：デフォルトの名無しさん：2011/07/03(日) 08:54:38.02

>>840
それで実際にinsert書いてみろよ……

843 ：デフォルトの名無しさん：2011/07/03(日) 10:37:31.08

>>838
このスレはまだ早いのでは?

844 ：デフォルトの名無しさん：2011/07/03(日) 14:43:16.68

>>835
>>830を守れなくならないか？

845 ：デフォルトの名無しさん：2011/07/04(月) 07:21:54.11

右辺値参照が静的な参照カウントで実装されてるとすると
外部由来のポインタもってるクラスの扱いはどうなるんだろう？

846 ：デフォルトの名無しさん：2011/07/04(月) 07:34:06.24

>>844
どうして守れないと思うのかが分からない

847 ：デフォルトの名無しさん：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

上記の部分をまず理解してからでないと
何を言っても意味不明だよ。

848 ：デフォルトの名無しさん：2011/07/04(月) 08:49:56.63

ばかにしないでくれる
そのくらい知ってるわよ

849 ：デフォルトの名無しさん：2011/07/04(月) 09:08:45.55

AA忘れてるぞ

850 ：デフォルトの名無しさん：2011/07/04(月) 09:55:26.57

内容は正しいけど投下するタイミングを完全に間違ってるな

851 ：847：2011/07/04(月) 17:16:32.26

>>850
>>845 みたいなのが相も変わらず湧いてくるので…

852 ：デフォルトの名無しさん：2011/07/04(月) 17:24:13.84

えぞえさんの記事張ればいいじゃん

853 ：デフォルトの名無しさん：2011/07/04(月) 18:50:51.84

本人じゃね

854 ：デフォルトの名無しさん：2011/07/04(月) 22:19:20.76

>>846
setやmapの要素は削除するとiterator無効になるじゃん。

855 ：デフォルトの名無しさん：2011/07/04(月) 22:38:34.83

そんな当たり前のこと言われても困りんす

856 ：デフォルトの名無しさん：2011/07/04(月) 23:04:43.64

>>854
はつみみです
木の実装から考えて、無効にするほうが難しいと思うが・・・

857 ：デフォルトの名無しさん：2011/07/04(月) 23:19:36.30

>>856
何を言ってるんだおまえは
試してみろよ

858 ：デフォルトの名無しさん：2011/07/05(火) 02:48:17.18

実物のunordered実装の一つではdeque<slist<T>>（相当）を使ってたな

859 ：デフォルトの名無しさん：2011/07/05(火) 02:58:00.88

>>856
回転とか二重回転でぐぐってみろよ
木の再構成がどんなに複雑な過程かよく分かるから

860 ：デフォルトの名無しさん：2011/07/05(火) 03:05:26.99

結局削除後のiteratorを保証するには、衝突をlist相当のものにするしか無いのか。
衝突の度にnewだろ、なんか遅そうだな。

861 ：デフォルトの名無しさん：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木、赤黒木、スプレイ木)を使っていて、やっている事は大して差がない

862 ：デフォルトの名無しさん：2011/07/05(火) 03:36:20.67

何がsetやmapの要素は削除するとiterator無効になるからlistにしろだよ。
なわけねーだろ。最近レベル低いやつ多すぎ。

863 ：デフォルトの名無しさん：2011/07/05(火) 03:40:41.87

それとは別にわざわざunordered_mapでmapを使う意味もわからねーけど。

864 ：デフォルトの名無しさん：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;
}

865 ：デフォルトの名無しさん：2011/07/05(火) 04:21:41.45

>>864
うんそのとおり。俺もそのつもりで書いてるんだけど何が言いたいの？

それとコードの肝心な所が間違ってるぞ。

866 ：デフォルトの名無しさん：2011/07/05(火) 04:55:47.48

iterator無効云々の話が関係あるのか？
unordered_mapの実装にmapが使えない理由は>>839だろ

867 ：デフォルトの名無しさん：2011/07/05(火) 05:18:11.54

>866
operator < が無くてもmapに入れようと思えば入れ子にすることで入る。ただ本当に何のメリットもなくなるけど。
そもそもunordered_map自体hashの衝突が多くなってきたらhash tableを拡張することで性能を維持しようとするので
backetにmapを使っても重いだけ。

868 ：デフォルトの名無しさん：2011/07/05(火) 05:28:18.12

mapを使用するメリットがあるくらいhash衝突が多いなら計算量はO(logN)になり、
unordered_mapの特徴であるO(1)のアクセスが出来ないことになる

869 ：デフォルトの名無しさん：2011/07/05(火) 05:32:08.70

でもmapを使ってもバランスの取れるところはあるか・・・
やっぱり>>839が理由なのか

870 ：デフォルトの名無しさん：2011/07/05(火) 05:32:11.03

>>867
>入れ子

ハッシュ値をキーにするとかそんなか

871 ：デフォルトの名無しさん：2011/07/05(火) 05:37:13.66

>>870
うん。
「何のメリットもなくなる」と書いたのは同じbacket内なら全部hash同じだと考えたんだけど
よく考えれば別のhash関数を噛ませればばらけてくれるのでそんなことは無かった。

872 ：デフォルトの名無しさん：2011/07/05(火) 05:41:47.39

ハッシュ関数2つ通して、しかも両方が衝突したときのためにmultimapにして最後はop =で……とか考えると
オーダーの定数項部分が洒落にならん気もするしメモリも喰うだろうしで
普通に一番外側のテーブルを大きめに取ったほうがいいだろうな

873 ：デフォルトの名無しさん：2011/07/05(火) 07:38:35.50

>>859
まさか、削除したiterator自身が無効になるぜとか言ってんのか・・・？
当たり前だろ
今問題になってんのは削除されなかった要素を指しているiteratorが無効になるかどうかだろ

874 ：デフォルトの名無しさん：2011/07/05(火) 07:40:59.74

ハッシュテーブル大きすぎてもメモリ食うし
たまたま衝突多かったらパフォーマンスがO(N)にだだ下がりってのもどうなのよ　＞list

875 ：デフォルトの名無しさん：2011/07/05(火) 07:47:21.61

つーてもハッシュ関数ふたつ用意させるぐらいなら
最初から1種類のハッシュ関数の質を高めろよって話だしなあ
何重にしたところで全部衝突する可能性が残る以上必ず末端はlistになるんだし

876 ：デフォルトの名無しさん：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) は消去した次のメンバを返すのだから
それを利用したほうがいい。

877 ：デフォルトの名無しさん：2011/07/05(火) 09:02:54.14

規格上どうなってるか知らないけど素直に赤黒木を実装すれば走査漏れや二重走査は無いよ。
新しく挿入した要素が走査途中の要素より後ろにあれば走査されないけど。

878 ：デフォルトの名無しさん：2011/07/05(火) 10:44:03.59

>>877
木の構造が変わるから、左子ノードだけ操作したノードスタックが無効になり、
上位ノードに戻るのが容易ではない。

879 ：デフォルトの名無しさん：2011/07/05(火) 10:59:11.93

>>876
>>>864 みたくすると多分走査漏れがあったり、
>二重に走査してしまったりすると思う。

ちょっとこれ困るんですけど
eraseした先が無効になる以外は問題ないという事を前提にして
書かれたプログラムがたくさんある

880 ：デフォルトの名無しさん：2011/07/05(火) 11:35:24.08

C++0xが関係のない、かなり初歩的な事まで話題になり始めてるから、
アルゴリズムスレに移ったほうがいいと思う。

ちなみに並列安全なイタレータの分野では、C++はかなり遅れを取っています。
(捜査漏れがない、二重捜査しない、順序が狂わない、オーダなど)
やっぱりGCのある言語のほうがずっと簡単なんで。

881 ：876：2011/07/05(火) 14:46:02.84

>>877-879
すまん。確かに>>877の言う通りで、
map は「順序を保持した」木なのだから
枝を複雑に付け替えて木の構造が変わっても
あるノードの「次の」要素は絶対変わらない。

だから>>864は正しくて、>>876の俺のコメントは間違ってる。

882 ：デフォルトの名無しさん：2011/07/05(火) 21:07:51.98

>>874
ハッシュテーブルって元々そういうアルゴリズムだし。

883 ：デフォルトの名無しさん：2011/07/05(火) 21:12:10.06

STLportがスレッドセーフレベル2だったんだっけ

もう過去の遺物だけど

コンテナをスレッドセーフにしちゃうとVSみたいに標準関数が軒並み遅くなっちゃいそうだし
そのためにわざわざランタイムを2種類用意してたよな
VS10からは一本化されてしまったけど

884 ：デフォルトの名無しさん：2011/07/05(火) 21:40:21.40

一本化したのはVC8からなんだが

885 ：デフォルトの名無しさん：2011/07/05(火) 22:32:15.81

imcomplete type って何？
知ってる人教えてくだしあ

886 ：885：2011/07/05(火) 22:34:23.42

まちがえた。ごめんなさい
s/imcomplete/incomplete/

887 ：デフォルトの名無しさん：2011/07/06(水) 04:08:22.59

>>885
不完全型。宣言されているが定義されていない型のこと。
sizeofや実体化、コピー、派生、メンバや内部型へのアクセス等が出来ない。
関数宣言の引数・戻り値型やポインタの要素型、テンプレート引数に使う事は出来る。

888 ：885：2011/07/06(水) 19:38:36.39

>>887
分かりやすい解説、ありがとうございます。

ところで、新しい規格の話題で、最近スレが寂しい
そこで、ライブラリの使い方などのリクエストを受けて、無知ながらFDISを調べつつ
解説してみようと思うんだが、需要ある？

889 ：デフォルトの名無しさん：2011/07/06(水) 20:27:32.01

incomplete typeも自力で調べられない奴がか？

890 ：デフォルトの名無しさん：2011/07/06(水) 20:30:09.84

>>888
面白い冗談だ。

891 ：デフォルトの名無しさん：2011/07/06(水) 20:37:40.35

>>882
set/map使えば最悪でもO(logN)で済むじゃん？
ハッシュが被らない場合でも各バケツ内で要素を探すための比較はどうせ行われるのだし、
listにする利点なんて追加のコストがちょっと下がるくらいじゃん？

892 ：デフォルトの名無しさん：2011/07/06(水) 20:51:06.74

ふたつめのキーも被ったら結局O(N)になるじゃん？

893 ：デフォルトの名無しさん：2011/07/06(水) 20:51:11.40

削除コストも下がるよ。

894 ：デフォルトの名無しさん：2011/07/06(水) 21:36:46.13

比較できない要素型だったら内部でordered使ったらコンパイル出来ねーだろうがアホか死ね

895 ：デフォルトの名無しさん：2011/07/06(水) 22:59:31.50

>>871

896 ：デフォルトの名無しさん：2011/07/07(木) 03:34:52.95

採択までずっとこんな流れなのか

897 ：デフォルトの名無しさん：2011/07/07(木) 05:35:06.98

>>893
イテレータが既にあるならコスト下がるけど
なければ削除するノードを検索するのにO(N)かかるよ

898 ：デフォルトの名無しさん：2011/07/07(木) 07:03:21.53

>>894
比較できなかったらそもそも値取り出せないだろwww
list使おうが要素の探索は必要になるんだぞ

899 ：デフォルトの名無しさん：2011/07/07(木) 07:52:09.59

結局アクセスの最悪オーダーをO(logN)に抑えるにはoperator < が必須になる
operator < を要求しないunordered_mapで実現するのは不可能。

900 ：デフォルトの名無しさん：2011/07/07(木) 11:05:46.27

STLスレに行けよ

901 ：885：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

902 ：デフォルトの名無しさん：2011/07/07(木) 20:53:54.36

OKの位置が変

903 ：デフォルトの名無しさん：2011/07/10(日) 01:46:22.25

上のほうで2つ目のハッシュを使って云々ってレスがあるけど、
それなら1つの配列(vector)にオープンアドレス法使えよ、と思う。
もちろん、それだとstd::unordered_の要件を満たせるものは作れないだろうことは分かるけど。

904 ：デフォルトの名無しさん：2011/07/10(日) 01:52:28.99

スレ違いも甚だしいが、要求しないのは要件ではない。
unorderedは、orderがあってはいけないことを意味しない。
このくらい理解してないと次期規格どころの騒ぎじゃない。

905 ：デフォルトの名無しさん：2011/07/10(日) 09:14:24.84

そりゃあれば使ってもいいけどさ、結局渡されたキーにoperator<が無い版の処理は必要だろう？

906 ：デフォルトの名無しさん：2011/07/10(日) 11:04:06.41

あれば使う、なければ使わない、って、
コンセプトさん無くてもできるんだっけ？

907 ：デフォルトの名無しさん：2011/07/10(日) 11:11:22.56

テンプレート＋ADLあれば可能。
>>905が何を言いたいのかわからんが。

908 ：デフォルトの名無しさん：2011/07/10(日) 12:17:00.48

基本リストにして、ポリスィーでコンテナ切り替えで十分でしょ
まあどうせboost使うからstlにはそんなに期待しないでいい

909 ：デフォルトの名無しさん：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< は無かったよ

910 ：デフォルトの名無しさん：2011/07/10(日) 14:30:10.09

STLスレに行けよw

911 ：デフォルトの名無しさん：2011/07/10(日) 14:51:48.65

unorderedだからC++0xでもいいんじゃね

912 ：デフォルトの名無しさん：2011/07/11(月) 18:58:55.41

>>907
std::unordered_map は、key の型に operator< が
定義されていなくても使えなくてはいけない。これは要求。

だから std::map が std::unordered_map の定義に紛れ込んではいけない

ということを>>904に向けて言ってるんじゃないの?

913 ：デフォルトの名無しさん：2011/07/11(月) 20:44:35.01

さらに言うと、 operator< が全順序でないといけない。
でも、テンプレートメタプログラミングでは < が定義されているかどうかは
分かっても、それが全順序かどうかを判別して実装を切り替えることができない。

なので、 unordered_map は全順序 < を要求するか、 < を一切利用しない実装に
しないといけない。

914 ：デフォルトの名無しさん：2011/07/12(火) 12:13:44.51

全順序じゃ無くてもどっちが大きいかランダムで返すってことでも良いはず

915 ：デフォルトの名無しさん：2011/07/12(火) 13:36:50.01

>>914
同じ引数に対してoperator<を適用するたびに結果が変わるならまともに順序があるとは言えない。
一意に定まるなら自動的に全順序が成り立つ。

問題は順序付きコンテナが必要とするoperator<の結果は全順序を満たす必要があるのに対し、
コンテナ要素の型Tが例えoperator<を持っていても、全順序である義務は無いということ。
例えばTがexpression templateをサポートしており、operator<はboolでは無い型を返すかもしれない。
そのようなオブジェクトがコンテナに入れられないとなると問題だろう。

916 ：デフォルトの名無しさん：2011/07/12(火) 13:56:31.62

>>913
> でも、テンプレートメタプログラミングでは < が定義されているかどうかは
> 分かっても、それが全順序かどうかを判別して実装を切り替えることができない。

現ライブラリでは、の間違い?

TotalOrdering<Op, T>で済む話だよね?
「テンプレートメタプログラミングでは」、
ライブラリ作成者が後から定義できるのが特徴。

Conceptでもっと使いやすくなるはずだったが…

917 ：デフォルトの名無しさん：2011/07/12(火) 17:00:47.42

>>915
たとえ一意でもoperator<をテキトーに決めたって全順序にはならんよ
推移律満たすとは限らないんだから

918 ：デフォルトの名無しさん：2011/07/12(火) 17:14:57.21

逆に言うと全順序じゃない物を並べられ無いと言うことになるけど
集合に全順序じゃない順序を入れて並べたいときはどうするんだ？

919 ：デフォルトの名無しさん：2011/07/12(火) 17:22:40.92

そんなのC++0xの話題なのか?
Strict weak orderingも知らん奴は初心者スレに行ってくれ。

920 ：デフォルトの名無しさん：2011/07/12(火) 17:33:01.28

やっぱりな全順序なんておかしいと思ってたよ。
Strict weak orderingで十分だとはうすうす思ってたんだよな。

921 ：デフォルトの名無しさん：2011/07/12(火) 17:33:07.04

>>917
operator<がboolをtrueとfalseでランダムに返すようにするか

922 ：デフォルトの名無しさん：2011/07/12(火) 17:48:51.66

いやいや、全順序（というか整列順序）自体は必要でしょ
begin()～end()の順番はとにかく決めないといけないんだし、同じコンテナのイテレータ同士が比較不能だなんて困る

923 ：デフォルトの名無しさん：2011/07/12(火) 18:01:22.21

トポロジカルソートもしらんのかいなﾔﾚﾔﾚ

924 ：デフォルトの名無しさん：2011/07/12(火) 18:54:26.54

スレ違いは他所でやれ

925 ：デフォルトの名無しさん：2011/07/12(火) 19:26:47.67

トロピカルリゾートくらい知ってるわな

926 ：デフォルトの名無しさん：2011/07/12(火) 19:54:27.93

トロピカルランドなら知ってるぜ

927 ：デフォルトの名無しさん：2011/07/12(火) 21:20:51.24

もうボゴソートでええやん

928 ：デフォルトの名無しさん：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_* は前進イテレータをサポートするんだってさ

929 ：デフォルトの名無しさん：2011/07/12(火) 22:56:22.43

なので、

930 ：デフォルトの名無しさん：2011/07/12(火) 23:01:13.80

うう、違うショートカットキーを押してしまった。。すみません

なので >>922 の言う begin()～end() の順番は、
処理系によってかなり変わる可能性もあると思う

最悪、hasher の返す size_t 型の値の順序でいいかと

931 ：デフォルトの名無しさん：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;

とすると通ります。
言語仕様的に正しい振る舞いなのでしょうか?

932 ：デフォルトの名無しさん：2011/07/15(金) 18:39:13.90

typename decltype(vec)::value_typeってしてみ

933 ：デフォルトの名無しさん：2011/07/15(金) 18:59:36.46

decltype(vec)::value_type は割と後になってから可能になった仕様なので
VC10ではまだサポートされていない

だったと思う

934 ：デフォルトの名無しさん：2011/07/18(月) 19:18:01.59

VC++2010ってデフォルト生成のムーブコンストラクタって対応してないのかな。
それとも俺が何か勘違いしてる?

http://codepad.org/BvrfyFBE

935 ：デフォルトの名無しさん：2011/07/18(月) 19:29:55.36

してません

936 ：デフォルトの名無しさん：2011/07/18(月) 20:55:21.12

イニシャライザリストさんも動かなかったりするから、もうちょっと待ったほうがいいかも。

937 ：デフォルトの名無しさん：2011/07/18(月) 20:58:00.10

VC++はいつだってクソだから

938 ：デフォルトの名無しさん：2011/07/18(月) 21:03:31.35

VC++の0x拡張はお勉強以外でつかうなよ。

939 ：デフォルトの名無しさん：2011/07/18(月) 21:15:43.92

MSはドラフト段階で取り入れた場合、製品の下位互換優先してFIXしてしまう。
ような気がする

940 ：デフォルトの名無しさん：2011/07/18(月) 22:57:31.79

発売日考えてやれよ・・・

941 ：デフォルトの名無しさん：2011/07/18(月) 23:05:51.83

Windows開発はMinGW+MSYSで十分すぎる
0xの機能もたくさん使えて楽しいしオプションで切ることもできるのが嬉しい
VC++は中途半端だからOFFにしようとしたけどオプションが見当たらなかった

942 ：デフォルトの名無しさん：2011/07/19(火) 19:36:36.70

同時期のgccを考えると
明らかにVC++は・・・

943 ：デフォルトの名無しさん：2011/07/19(火) 19:38:59.81

そもそもVCはやる気なかったやん

944 ：デフォルトの名無しさん：2011/07/19(火) 20:04:11.26

あんな中途半端な対応なのにオプションで外すことも出来ないとかVCないわ

945 ：デフォルトの名無しさん：2011/07/19(火) 20:05:04.90

いやC++03はVC++の方が先行してた時もあったよ。

ただMicrosoftとしては、C++0x対応を出してもあまりメリットがない。
あれはあくまでもWindows開発環境用にあるのだから。
Herb Shutterとかいるから、内部的には既にあるのだろうけど。

946 ：デフォルトの名無しさん：2011/07/19(火) 20:36:55.75

CLIはもうやる気無いけど
C99ガン無視のVCが0xに対応しようとしたあたり
いくらか前向きなんじゃないのかね

947 ：デフォルトの名無しさん：2011/07/19(火) 21:03:45.44

時期バージョンではC++/CLIのインテリセンス復活させるって話だからやる気はそれなりにありそう

948 ：デフォルトの名無しさん：2011/07/19(火) 21:18:13.03

C++/CLIはC++じゃないし…
delegate（）と干渉してラムダさん使えないし…

949 ：デフォルトの名無しさん：2011/07/20(水) 00:01:03.28

VCはC++コンパイラだから、Cの変更には追随しないってスタンスなのかも。

950 ：デフォルトの名無しさん：2011/07/20(水) 01:50:33.09

C99って何のために存在するの？

951 ：デフォルトの名無しさん：2011/07/20(水) 04:41:07.44

いらんことしい
減量すべきときにメタボ化しやがった

952 ：デフォルトの名無しさん：2011/07/20(水) 09:23:58.92

Microsoft は C99 はスキップして C1X を実装するよ

953 ：デフォルトの名無しさん：2011/07/20(水) 10:23:29.48

C++0x*0.75ぐらいがちょうどいい

954 ：デフォルトの名無しさん：2011/07/20(水) 12:10:55.12

C++ + (C++0x - C++) * 0.2
くらいがいいな

955 ：デフォルトの名無しさん：2011/07/20(水) 15:02:56.55

C++0x はうんこすぎる
あんなの使うなら C と ML 使うわ

956 ：デフォルトの名無しさん：2011/07/20(水) 15:05:35.39

ＭＬｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

957 ：デフォルトの名無しさん：2011/07/20(水) 15:17:39.63

C99 の轍は踏まないで欲しいな

958 ：デフォルトの名無しさん：2011/07/20(水) 16:24:39.89

コンパイル時リフレクションが欲しいのう

959 ：デフォルトの名無しさん：2011/07/20(水) 17:22:46.03

C99は数値計算屋には重要。いい改正だった。

960 ：デフォルトの名無しさん：2011/07/20(水) 17:28:42.28

特定用途にシフトしたってことだな
返す返すも設計思想を曲げた愚かしいことだ

961 ：デフォルトの名無しさん：2011/07/20(水) 17:28:55.19

数値計算やってるけど、Fortranならともかくpure C使うメリットが分からないんだけど

962 ：デフォルトの名無しさん：2011/07/20(水) 17:31:12.81

俺も数値計算屋やってるけど、Fortran なんて新規に書きたくねぇ
restrict がある時点で C99 でもいいやってなった

963 ：デフォルトの名無しさん：2011/07/20(水) 17:38:44.59

狭い視野での最適化を神格化するやつ多いんだよな
とかくそういうのは FPGA とか苦手だったりするし
行列の計算がしたいだけなのに FORTRAN とかもう・・・

964 ：デフォルトの名無しさん：2011/07/20(水) 17:50:33.00

C89で出来る事が出来なくなったわけでなし、
特定用途にシフトしたってのは違うだろ

965 ：デフォルトの名無しさん：2011/07/20(水) 18:16:07.41

C89 でさえ完全サポートできない（できても非現実的な）環境があるのに
そっちを無法状態のまま放置した結果がこのざまだっつーの

966 ：デフォルトの名無しさん：2011/07/20(水) 18:20:38.66

実装の強制はできんだろ
そんなこともわからないとかアホなの？

967 ：デフォルトの名無しさん：2011/07/20(水) 18:20:56.62

C++03はC99の上位互換を目指すべきだった
Cと互換性の無いC++になんの価値があろうか
設計思想を曲げたのはC++のほうだな

968 ：デフォルトの名無しさん：2011/07/20(水) 18:24:41.90

>>967
その通り

969 ：デフォルトの名無しさん：2011/07/20(水) 18:28:30.49

C99もちょっとC++98に対する配慮が欲しかったな。
C++98に合わせた部分もあるんだけども。

まあ俺は気にせずに両方使ってるよ。

970 ：デフォルトの名無しさん：2011/07/20(水) 18:32:19.58

>>965
フリースタンディング環境って知ってる？

971 ：デフォルトの名無しさん：2011/07/20(水) 18:39:50.11

C99なんて無視しとけ

972 ：デフォルトの名無しさん：2011/07/20(水) 18:50:04.68

>>970
その質問、そっくりおまえに返す

973 ：デフォルトの名無しさん：2011/07/20(水) 19:01:05.40

C89のフリースタンディング環境をサポートできない処理系もあるだろうが、
そんなもんC99がどんな仕様だったところで同様にサポートできんだろ
どうすりゃ良かったって言うんだ？

974 ：デフォルトの名無しさん：2011/07/20(水) 19:10:27.86

>>973
話の流れ読んでるか？　# サポートという言葉が出てきているから見てはいるようだが
おまえの言ってる「C99 がどんな仕様」てのは、現状の C99 を前提とした循環論法だろ

975 ：デフォルトの名無しさん：2011/07/20(水) 19:13:46.19

>>974
現状のC99は無視して良いよ
どんな仕様だったら良かったのかと聞いている

976 ：デフォルトの名無しさん：2011/07/20(水) 19:15:02.57

boostの行列とfortranの行列計算どっちが速いの？

977 ：デフォルトの名無しさん：2011/07/20(水) 19:25:09.93

>>975
C89 のフリースタンディング環境をサポートできない環境の具体例を１つでも知っていれば
そんな愚問は出るわけがなさそうに思うが、そこまで教えてやる気はないよ

978 ：デフォルトの名無しさん：2011/07/20(水) 19:29:04.89

うざい

979 ：デフォルトの名無しさん：2011/07/20(水) 19:37:40.62

「そこまで教えてやる気はないよ」（ｷﾘｯ

980 ：デフォルトの名無しさん：2011/07/20(水) 20:54:15.38

>>976
大規模並列計算とかだとfortranじゃないかなあ

981 ：デフォルトの名無しさん：2011/07/20(水) 21:03:04.85

>>976
いくらboostでも関数を横断するベクトル命令の管理はできないからなぁ。
引数をベクトルに割り当てたりとか無理臭いし。

982 ：デフォルトの名無しさん：2011/07/20(水) 21:17:23.45

Boost.SIMDっていうのが入りそうだよ。中身知らないけど。

983 ：デフォルトの名無しさん：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のほうが速いよ

984 ：デフォルトの名無しさん：2011/07/20(水) 23:10:02.02

>>982
AVX使いまくりか
Intelから頼まれたのかな

985 ：デフォルトの名無しさん：2011/07/21(木) 01:08:12.64

IntelのFORTRAN環境って優秀だったのか
まあICCもそれなりに良い評判だし、完成度高いの？

986 ：デフォルトの名無しさん：2011/07/21(木) 01:11:24.89

もとはDECのコンパイラだった気がするよ

987 ：デフォルトの名無しさん：2011/07/21(木) 01:39:03.96

CとFORTRANの行列の一番の差は行が先か列が先かの違いだけだけど、
Cはよく知られているようにポインタのエイリアスの問題があって最適化が著しく
制限されて速度が落ちる

これを避けるためにC99で導入されたのがrestrictで、同じエイリアスではない
事をユーザーがコンパイラに知らせる事でFORTRANと同等の最適化が可能

ではC99が必須かと言うとVCにも__restrictがあったりするし微妙
メインフレームで使うならC99だろうけど
どうせライブラリなんてどっちでも動くように再コンパイルされてるし

禿がD&Eで言ってるけど「C++はFORTRANと速度を競うつもりはない」
ので適材適所だな

988 ：デフォルトの名無しさん：2011/07/21(木) 04:05:03.56

別にギリギリのところで手間のかかる勝負はしてくれなくてもいいけど、
restrictは既にC99で導入されてる機能なんだから取り入れてくれたって悪くないのにって思う

989 ：デフォルトの名無しさん：2011/07/21(木) 07:51:47.81

おまいらC++0ｘの話をしろよ

990 ：デフォルトの名無しさん：2011/07/21(木) 09:45:37.14

じゃあ、0x年代に出せよ。

991 ：デフォルトの名無しさん：2011/07/21(木) 13:51:48.54

予言
2012年12月に世界は滅亡の危機にさらされる
その時にC++0x計画は破棄される

992 ：デフォルトの名無しさん：2011/07/21(木) 16:17:28.40

滅亡しねーよ

993 ：デフォルトの名無しさん：2011/07/21(木) 16:30:52.01

世界が滅んでもC++は死なず