C++11/C++1y 15

1 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/03(火) 15:18:20.76

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

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

前スレ: C++11/C++0x 15
http://toro.2ch.net/test/read.cgi/tech/1321453654/

2 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/03(火) 15:20:23.26

3 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/03(火) 15:22:08.92

スレ番間違えたけど気にするな

4 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/03(火) 18:21:44.82

>>1乙
C++1yって次の規格のことか

5 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/11(水) 20:22:05.59

std::hash<Type>()(element)ですが、戻り値に再現性はありますか？

6 ：デフォルトの名無しさん：2012/04/11(水) 21:29:19.49

>>5
ハッシュ計算アルゴリズムの規定はないからコンパイラが変われば結果は変わるだろうな

7 ：デフォルトの名無しさん：2012/04/12(木) 08:21:47.73

>>6
すみません言葉足らずでした。
はじめてプログラムが実行される時、内部で未初期化の値が使用されて
プログラムを起動する度（≠実行する度）に前回と違ったハッシュ値になりうるかどうかです。
以前、boost::hash_combineで上記の様な再現性の無い結果にはまったことがあったのでstd::hashでもそうなのかなと思いまして。

8 ：デフォルトの名無しさん：2012/04/12(木) 09:06:05.42

>>7
ハッシュ値の使用目的から常識的に考えて、そりゃバグだろ。

9 ：デフォルトの名無しさん：2012/04/12(木) 09:16:48.20

>>8
セキュリティの観点から、
プロセス起動ごとに、ハッシュ値を変える仕組みを採用していることがあるんだ。

ソルトのようなものだと思ってもらいたい。

10 ：デフォルトの名無しさん：2012/04/12(木) 09:29:00.37

そんな高尚な目的が無くても、アドレス値とか混ぜこんでるとそうなるな。

11 ：デフォルトの名無しさん：2012/04/12(木) 09:45:59.60

template <class T> struct hash<T*> の部分特殊化が標準ライブラリに含まれてるんで、
そういうことになるかな。

12 ：デフォルトの名無しさん：2012/04/12(木) 14:29:51.48

std::hashの目的としては、
単一のローカルなプログラムが、その一度の実行中に限り、
コンテナーの実装で使用するために十分なハッシュ値の提供。

ハッシュ値を比較することで文字列などのビット列の一致を調べるとか、
他のプログラムと通信してハッシュ値のやり取りとか、
暗号関連に十分な強度のあるハッシュではない。

CRCとかSHAみたいなハッシュ値を期待してはいけない。

次の規格改訂では、ユーザー型をstd::hashに簡単に対応させるためのライブラリが追加される予定。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3333.html

13 ：デフォルトの名無しさん：2012/04/13(金) 20:37:58.32

数年後にstd::hashを無節操に使ったプログラムが大問題を起こすんですねわかりました

14 ：デフォルトの名無しさん：2012/04/14(土) 00:42:36.83

std::weak_hashみたいな名前にしとけよ

15 ：デフォルトの名無しさん：2012/04/14(土) 00:52:46.90

std::ゼッケン

16 ：デフォルトの名無しさん：2012/04/14(土) 01:01:05.61

コンテナの実装にしか使えないなら<container_base>とか作って隔離しとけよな
<functional>なんかに入れんな

17 ：デフォルトの名無しさん：2012/04/14(土) 12:38:04.26

高速比較の用途ならいくらでもあるだろコンテナに限定する必要はない
でかいファイル同士の比較やロープ規模の文字列比較等
でかいデータの比較には重宝する

18 ：デフォルトの名無しさん：2012/04/14(土) 20:16:10.49

template <typename... Ts>
istream& operator>>(istream& is, tuple<Ts...>& t) {
//カンマ区切りのデータをタプルの各要素に読み込む。
//is >> get<i>(t) ができると仮定。
}

この実装をboostつかわずにしたいのですが、どうすればいいでしょうか？
まずは空白区切りでもいいです。

19 ：デフォルトの名無しさん：2012/04/14(土) 21:58:27.37

template <size_t remain>
struct helper
{
　　template <typename... Ts>
　　static void read(istream& is, tuple<Ts...>& t){
　　　　is >> get<sizeof...(Ts) - remain>(t);
　　　　helper<remain-1>::read(is, t);
　　}
};

template <>
struct helper<0>
{
　　template <typename... Ts>
　　static void read(istream& is, tuple<Ts...>& t){}
};

template <typename... Ts>
istream& operator>>(istream& is, tuple<Ts...>& t) {
　　helper<sizeof...(Ts)>::read(is, t);
　　return is;
}

20 ：541：2012/04/14(土) 23:41:06.10

>>19
ありがとうございます。
同じ方針で考えていましたが、
関数の部分特殊化ができないので挫折していました。
オブジェクトにすればよいのですね！

21 ：デフォルトの名無しさん：2012/04/15(日) 04:02:05.06

>>19
まだ使えるコンパイラないだろ

22 ：デフォルトの名無しさん：2012/04/15(日) 04:45:48.28

for(;;)
{
　　int left;
　　double right;

　　count = std::fscanf( stream, " %d, %f", &left, &right);
　　if( 1 != count ) break;
　　vector.push_back( std::tuple<int, double>( left, right ) );
}

何らかの構造化された文字列なら<cstdio>使ったほうが楽だぞ

23 ：デフォルトの名無しさん：2012/04/15(日) 06:23:07.31

>>21
Clang

24 ：デフォルトの名無しさん：2012/04/15(日) 11:25:58.06

gcc-4.7 もすでにリリース済みで、
めぼしい機能で実装されてないのは inheriting constructor くらい。
attributes さんはめぼしくないし

25 ：デフォルトの名無しさん：2012/04/15(日) 13:41:55.74

atomicは

26 ：デフォルトの名無しさん：2012/04/15(日) 14:02:11.43

thread_localは

27 ：デフォルトの名無しさん：2012/04/22(日) 05:11:31.96

日本の糞企業で働きたくない

28 ：デフォルトの名無しさん：2012/04/22(日) 09:46:10.66

同意

29 ：デフォルトの名無しさん：2012/04/22(日) 12:23:41.54

C++11を駆使したオープンソースなソフト開発の仕事ないかな

30 ：デフォルトの名無しさん：2012/04/23(月) 23:10:17.29

>>29
人柱乙

31 ：デフォルトの名無しさん：2012/04/23(月) 23:33:31.08

そんなコンパイラや環境が極端に制限されたオプソはちょっと…

32 ：デフォルトの名無しさん：2012/04/23(月) 23:41:24.49

オプソってハイソな感じがするよね。

33 ：デフォルトの名無しさん：2012/04/23(月) 23:42:38.32

個人的に使いたい言語に仕事を合わせようという考えは
正しいと思わないが否定もしたくない

どんなに理にかなった選択でも本人の原動力なくして成就し得ないからな

とりあえず C++11 にラブラブなら、コンパイラや規格そのものの中の人をやってはいかがかな
GCC なんて手段に過ぎない、スクラッチででもやってやるって勢いで

34 ：デフォルトの名無しさん：2012/04/23(月) 23:43:50.22

現実は C++ 規模のをスクラッチでっていうのはそうとう無謀だけどな。

35 ：デフォルトの名無しさん：2012/04/24(火) 01:01:11.09

Clangの開発を手伝ってやってくれ
Windowsでも手軽に使えるようにして
MSVCやVS IDEなんか吹っ飛ばしてしまおうぜ

36 ：デフォルトの名無しさん：2012/04/24(火) 02:03:17.67

MSVCはMSVCというC++によく似た何か用のコンパイラですし
Clangみたいな正統派でぶっ飛ばすのは無理ではないかと

37 ：デフォルトの名無しさん：2012/04/24(火) 02:11:06.64

だとしたらVSに寄生してるインテルコンパイラは何でしょうかw

38 ：デフォルトの名無しさん：2012/04/24(火) 02:16:23.16

エリンギ

39 ：デフォルトの名無しさん：2012/04/24(火) 06:58:52.84

cl.exeとVisual C++に依存してるヤツ多いんだな

40 ：デフォルトの名無しさん：2012/04/24(火) 07:13:34.73

gcc系だとSEHも満足に使えないし、--gc-sectionsすら動かないからなあ。

41 ：デフォルトの名無しさん：2012/04/24(火) 08:19:48.24

環境構築コスト+コード補完機能の有無
この差はすんごく大きいと思うよ

42 ：デフォルトの名無しさん：2012/04/24(火) 08:24:19.34

VC(VS)は、MSのサポートが案外というかやはり大きい

43 ：デフォルトの名無しさん：2012/04/24(火) 09:00:43.73

システム系のAPIはヘッダの移植+dllの呼び出しで何とかなると思うけど…
未だにC言語ベースのAPIが基本な状況を鑑みるに
c++のコードを呼び出すようなギミックがボトルネックなのかも
COMもイマイチな感じだし

44 ：デフォルトの名無しさん：2012/04/24(火) 17:32:22.47

C++が他言語との呼び出し規約にCの命名規則を使うからじゃないのかにゃー。

45 ：デフォルトの名無しさん：2012/04/24(火) 21:50:45.77

>>41
Qtやら他のツールでも同等なのが有るがな

46 ：デフォルトの名無しさん：2012/04/25(水) 02:37:55.86

テンプレート対応とかになってくると一気に選択幅が狭まるからねぇ

47 ：デフォルトの名無しさん：2012/04/25(水) 20:54:23.98

std::begin(container_type&)とstd::end(container_type&)があるのに
std::ｒbegin(container_type&)とstd::rend(container_type&)が無いのは
片手落ちだよな

48 ：デフォルトの名無しさん：2012/04/25(水) 21:15:27.26

container::const_iteratorがあるのにcontainer::volatile_iteratorがないとか、
std::cbegin/std::cendもないとか、accumute_nとかtransform_nとかinner_product_nとかがないとか、
std::u16printfとかがない(というか書式指定子さえない)とか、
何本手があっても落ちきれねぇな。

49 ：デフォルトの名無しさん：2012/04/25(水) 21:30:13.45

volatileに関しては、コンテナをvolatileにする意味が無いからしかたない

50 ：デフォルトの名無しさん：2012/04/25(水) 21:36:59.01

std::array なら意味があると思う

51 ：デフォルトの名無しさん：2012/04/25(水) 21:53:17.91

volatileは、ポインターかアセンブリで特殊な
セグメントに設置した外部変数じゃないと意味ないから
外部変数をオブジェクトにするならPODじゃないといけないし、
コンテナは使えない

52 ：デフォルトの名無しさん：2012/04/25(水) 22:07:52.34

C++11ではPODって言葉は無くなったんじゃなかったっけ

53 ：デフォルトの名無しさん：2012/04/25(水) 22:14:34.62

緩和されただけで無くなっちゃいない
PODじゃないオブジェクトをPOD代わりに使うと危険だからな

54 ：デフォルトの名無しさん：2012/04/25(水) 22:26:24.03

一時期ドラフトで軒並みPODが別の言葉に置き換えられてるの見たけど
消えてなくなったわけでもないんだ

55 ：デフォルトの名無しさん：2012/04/25(水) 22:27:41.77

別の言葉思い出した
trivial/non-trivial だな

56 ：デフォルトの名無しさん：2012/04/26(木) 00:18:58.25

trivialとPODじゃ全然違うじゃないか

57 ：デフォルトの名無しさん：2012/04/26(木) 00:46:31.45

PODとはtrivialかつstandard-layoutであること

58 ：デフォルトの名無しさん：2012/04/26(木) 10:08:51.40

>>51
マルチスレッドで共有しているオブジェクトとか…

59 ：デフォルトの名無しさん：2012/04/26(木) 13:28:11.26

>>58
マルチスレッドとvolatileは全く無関係。

60 ：デフォルトの名無しさん：2012/04/26(木) 13:59:58.86

>>51
シグナルハンドラと共有しているオブジェクトとか…

61 ：デフォルトの名無しさん：2012/04/26(木) 14:09:22.28

>>51 >>59
１つのスレッドが読み書きして他スレッドが読むだけのアトミック変数は？

62 ：デフォルトの名無しさん：2012/04/26(木) 14:23:19.96

>>60
シグナルハンドラと共有できるのは volatile sig_atomic_t 型。
任意のコンテナ型を共有することはできない。

>>61
アトミック変数って std::atomic のことか？
だったら、volatileとか関係なしにスレッドセーフだよ。

63 ：デフォルトの名無しさん：2012/04/26(木) 15:34:27.88

>>62
std::array<volatile sig_atomic_t, 5>とかやったときに、
volatile sig_atomic_t *なイテレータが欲しいじゃないか。

と思ったが、引数の型を修飾してる時点で::iteratorがそうなるのか？

64 ：デフォルトの名無しさん：2012/04/26(木) 17:43:47.40

>>63
うん

65 ：デフォルトの名無しさん：2012/04/26(木) 18:40:19.49

こ

66 ：デフォルトの名無しさん：2012/04/26(木) 18:53:03.37

　　　　　――― プログラム技術＠C++11スレ

67 ：デフォルトの名無しさん：2012/04/26(木) 20:39:41.14

>>61
何スレ前かで、極めて特殊な条件じゃないと
無意味だと散々論破されてたろ。
過去ログ読め。それからスレッドでvolatile使う話はもうするな。
クソレスで無駄にスレが伸びる。

68 ：デフォルトの名無しさん：2012/04/26(木) 21:16:15.19

volatileで荒れるのこれで何度目だよ

69 ：デフォルトの名無しさん：2012/04/26(木) 21:32:58.87

まだ大して荒れてないよ

70 ：デフォルトの名無しさん：2012/04/26(木) 22:40:02.48

他の言語、例えばJavaにもvolatileがあるから、
その辺でメモリモデルの理解に混乱が生じるのかも

71 ：デフォルトの名無しさん：2012/04/26(木) 23:19:08.65

JavaのvolatileとC++のvolatileは意味が違うしねえ

72 ：デフォルトの名無しさん：2012/04/26(木) 23:58:11.61

http://feezch.info/vt/show-71-22.html
73あたりからvolatileの話

73 ：デフォルトの名無しさん：2012/04/27(金) 00:20:39.61

Javaのvolatileのせいでスレッド用の機能だと思ってる奴が的外れなこと言い出したり
でもVCのスレッド用独自拡張で使えるからって混乱したり
なぜかatomicやrestrictの話が混ざってきて戦争になったり
メンバ関数のvolatile修飾を知らない初心者に乗っ取られたり
本の虫がvolatileなんか現代には必要ない遺物とかアホな事言い出して引っかき回したり

C++0xスレの歴史はvolatileとの戦いの歴史と言っても過言でない

74 ：デフォルトの名無しさん：2012/04/27(金) 01:45:02.36

>>72
気がついたら何の話だったかわからなくなっていた

75 ：デフォルトの名無しさん：2012/04/27(金) 12:17:52.77

memory mapped i/oや割り込みなど特殊なハードウェア事情→volatile
ただしvolatileはマルチスレッドの資源共有を想定して作られたものではないので
マルチスレッドの資源共有にはメモリバリアや同期機構が必要
こんなイメージで合ってます？

76 ：デフォルトの名無しさん：2012/04/27(金) 15:18:49.06

volatileはメモリリードの最適化に関するもの
メモリバリアはメモリアクセスの順序性に関するもの

77 ：デフォルトの名無しさん：2012/04/27(金) 20:24:49.14

>>75
あってるよ

てか、毎回思うがC++03の仕様すら把握してないヤツが
なんでこのスレ来るかねぇ。

78 ：デフォルトの名無しさん：2012/04/27(金) 21:51:06.98

1.9 プログラムの実行
1.10 マルチスレッド

のたった 7 ページに volatile のすべてが書かれている。
百遍読むといい。そこにかかれていないことは全部都市伝説か独自拡張。

(1.10 で直接的に volatile に言及されているのは第24段落だけだけど
volatile 変数の読み込みが side effect として間接的にたくさん言及されてる)

79 ：デフォルトの名無しさん：2012/04/28(土) 15:18:27.98

>>78
> (1.10 で直接的に volatile に言及されているのは第24段落だけだけど
> volatile 変数の読み込みが side effect として間接的にたくさん言及されてる)

data raceの条件にvolatileが全く関係ない以上、volatileに実質的に関係ある
1.10の記述は第24段落だけだと思うけど。
# つーか1.10の記述は全体的に、side effectsにvolatile readも含まれることを
# 忘れてるように見える。13段落のvisible side effectの定義なんて、
# "the value stored by the visible side effect" とか書いてるくらいだからなあ。

80 ：デフォルトの名無しさん：2012/04/28(土) 15:20:54.11

いいかげんvolatileとthreadの話をやめないか

81 ：デフォルトの名無しさん：2012/04/28(土) 16:00:19.68

やめなくていいけどWikiにでもまとめてテンプレ入りして欲しい

82 ：デフォルトの名無しさん：2012/04/28(土) 16:07:57.02

とりあえず、これをテンプレに入れとこうぜ。
http://www.jpcert.or.jp/sc-rules/c-pos03-c.html

83 ：デフォルトの名無しさん：2012/04/30(月) 23:04:56.57

template <typename T, typename U>
[何か] add(T x, U y) {return x+y;}
で、戻す型の名前をdecltype(x+y)以外で、
（できればTとUのみを使って）書きたいのですが、どうするんでしたっけ？
「decl何とか」ってのが他にもあった気がする。

84 ：デフォルトの名無しさん：2012/04/30(月) 23:08:01.82

自分で思い出したのですが、
decltype(declval<T>()+declval<U>())
ですね！

85 ：デフォルトの名無しさん：2012/05/01(火) 15:02:17.85

まったく話題にならんけど、ローカルクラスを親クラスにキャストせずとも直接
テンプレートの引数に渡せるようになったのな。便利ぃ。

86 ：デフォルトの名無しさん：2012/05/02(水) 05:38:16.07

これ、確認なのですが、
std::array<T,N> operator+(const std::array<T,N>&, const std::array<T,N>&);
以外に、
std::array<T,N>&& operator+(std::array<T,N>&&, const std::array<T,N>&);
とか、他に&&が移動したバージョン作る必要ありますか？
コピコンと代入演算子についてはもう実装されてるから、べつにこっちで何かする必要はないですよね？

あと、arrayついでですが、コピコン・代入演算子って、
array<array<T,N>,M> lhs = rhs;
みたいなのがあったときに、ネストした各要素までちゃんと期待した仕事してくれることは保証されてるんでしょうか？
（deep copyとshallow copyの差みたいなのって標準ライブラリで気をつけたほうがいいことってありますか？）

87 ：デフォルトの名無しさん：2012/05/02(水) 05:53:11.98

cpploverを読んで考えなおした。
template <typename T>
std::array<T,2> operator+(const std::array<T,2>&& lhs, const std::array<T,2>&& rhs) {
return std::array<T,2>{lhs[0]+rhs[0],lhs[1]+rhs[1]};
}
これでいいのかな？

88 ：デフォルトの名無しさん：2012/05/02(水) 05:59:43.43

これだけ実装しとけば、
typedef std::array<int,2> vec;
vec x={1,2},y={3,4};
vec z=x+y;//op+(const vec&（&&省略）, const vec&（&&省略）)のあとにコピコン
z=x+vec(5,6);//op+(const vec&, const vec&&)のあとに代入
って展開されていくと思っていい？

89 ：デフォルトの名無しさん：2012/05/02(水) 06:11:18.62

右辺値参照を理解していないなら無理して使わなくてもいいよ。
intのstd::arrayなんて右辺値参照を使ってもパフォーマンスは改善しないし。

90 ：デフォルトの名無しさん：2012/05/02(水) 06:15:07.21

>>89
理解したいからやってみたんだけど・・・

ところでさっきのは&&省略がはたらかないから
template <class vec>
vec operator+(const vec&&,const vec&&);
とするべきだったか？

91 ：デフォルトの名無しさん：2012/05/02(水) 06:18:41.45

あと、rvalueをconstにしても何の意味もないからconst vec&&じゃなく単にvec&&とするべきか？

92 ：デフォルトの名無しさん：2012/05/02(水) 07:10:14.36

戻り値がintのコンテナ（順序気にしない）で上限サイズn(<10)が決まっている場合に、
何度も呼び出して一番高速な方法は以下のどれ？
auto f() {
forward_list<int> ret;
...
return ret;
}

auto f() {
v.clear();//vはどこかでreserve(n)されたvector<int>
...
return v;
}

auto f() {
s.clear();//vはどこかで作ったset<int>
...
return s;
}

auto f() {
u.clear();//uはどこかで作ったunordered_set<int>
...
return u;
}

それ以外にもあれば教えてくれ。

93 ：デフォルトの名無しさん：2012/05/02(水) 07:46:45.19

● template <class T> f(T&&); と、 template <class T> f(Templ<T>&&); では
違う頭を使って考えよう。

(前者は T = const int& なども勝手に推論してくれるけど
(constがついててもOK / 左辺値参照でもOK)、
後者は const Templ<T>& にマッチしない)

● 右辺値参照と deep/shallow copy はまったく関係がない。
この二つを連想してしまうならば、何か勘違いしている。規格を読み直そう。

● > 他に&&が移動したバージョン作る必要ありますか？
ある。ただし、& と && で動作が変わるものだけでいい。

● > ネストした各要素までちゃんと期待した仕事してくれることは保証されてるんでしょうか？
保証されてる。ただし、「ムーブ」のデフォ動作はコピーすること。

● > コピコンと代入演算子についてはもう実装されてるから、べつにこっちで何かする必要はないですよね？
ある条件下のデフォルトコピーさんは D組に行ってしまった。
その条件下では、デフォルトムーブさんは作られないので注意。
... = default; を明示的に書いておくといい。

94 ：デフォルトの名無しさん：2012/05/04(金) 09:08:31.85

不自由なソフト使うのは駄目なのに
twitterみたいな不自由なサービスを使うのはいいのか？

95 ：デフォルトの名無しさん：2012/05/04(金) 21:54:20.93

>>94
いまの時代にストールマンとかがどんな生活してるのか気になる。
ネットとか利権だらけで、生理的に無理だろｗ

96 ：デフォルトの名無しさん：2012/05/04(金) 21:55:01.85

個々人で判断すればよい。
その判断を人にとやかく言われる筋合いはないのでは。
脱税とか悪いことしてるんじゃないんだから。

97 ：デフォルトの名無しさん：2012/05/04(金) 22:05:09.42

>>95
だからこそあれくらい苛烈に主張ないとバランスがとれないんだろ。

98 ：デフォルトの名無しさん：2012/05/04(金) 23:24:05.45

不自由なソフトウェアも不自由なサービスも使うべきではない
と不自由な2chに書き込んでみる

99 ：デフォルトの名無しさん：2012/05/04(金) 23:28:02.23

　＜━━━━━━━━＞

＞━━━━━━━━━━＜

こうすると下の棒の方が一見長く見えます。これが目の錯覚です。

100 ：デフォルトの名無しさん：2012/05/04(金) 23:58:28.82

上の棒の方が長く見えるんだが

101 ：はちみつ餃子 ◆8X2XSCHEME ：2012/05/05(土) 00:55:08.51

上の棒が遠くにあるように見える。

102 ：デフォルトの名無しさん：2012/05/05(土) 01:20:06.74

上の棒の方が上にあるように見えるんだが

103 ：デフォルトの名無しさん：2012/05/05(土) 04:21:58.55

俺の下の棒が長くなってきた｡｡

104 ：デフォルトの名無しさん：2012/05/05(土) 04:36:57.91

俺の下の棒は長くなっても短い

105 ：デフォルトの名無しさん：2012/05/05(土) 07:53:42.71

何がよくて何が悪いのか
それを他人に主張する必要があるのか
それが分からないやつはダメだ

106 ：デフォルトの名無しさん：2012/05/05(土) 08:16:25.33

>>105
それを他人に主張する必要あるの？

107 ：デフォルトの名無しさん：2012/05/05(土) 13:08:16.89

const int n=2;
array<int,n> xs={1,2};
cout << &xs[1] << endl;
array<int,n> ys = std::move(xs);
cout << &ys[1] << endl;

を見ると、moveが期待される仕事をしてないんですが、
（新たに領域確保し、xsの値をコピーしているようにみえる）
ys=my_move(xs)
によって、xsはundefし、ysはもともとxsが指していた格納領域を使うような
自前のmy_moveを作ることはできませんか？

108 ：デフォルトの名無しさん：2012/05/05(土) 13:10:39.62

なんでarrayを使うんだよ？

109 ：デフォルトの名無しさん：2012/05/05(土) 13:12:10.21

あと、ついでに気付いたのですが、
-Wallをつけると
array<int,n> xs={{1,2}};
と初期化リストを書かねばならん、というエラーが出ますが、
これって仕様的にはどうなってるんでしょうか？

110 ：デフォルトの名無しさん：2012/05/05(土) 13:13:36.11

>>108
たしかにvectorでまったく同じことをやれば期待通りなんだけど、
sizeof(vector<int,2>)がでかすぎる。

111 ：デフォルトの名無しさん：2012/05/05(土) 13:14:41.89

>>110
ミスった。
vector<int> xs = {1,2};
としたときの
sizeof(xs)のことね。

112 ：デフォルトの名無しさん：2012/05/05(土) 13:54:42.51

>>107
当然だろ？
ムーブのデフォルト動作はコピー。

array の設計思想からしてコピーするしかない。

113 ：デフォルトの名無しさん：2012/05/05(土) 13:55:12.95

std::arrayって配列のポインタを介さない単なる極薄ラッパーなんじゃなかったっけ？
それならシャローコピーのしようがないよね。
std::arrayのソース見てみればすぐわかると思うけど。

114 ：デフォルトの名無しさん：2012/05/05(土) 14:04:40.73

>>112
確かに配列の確保の仕方を考えると仕方ない気がしないでもないが、
tuple<int,int>でも全く同じ問題が起こることに失望した。

結局自前でメモリ確保しろってか？

115 ：デフォルトの名無しさん：2012/05/05(土) 14:09:35.25

>>114
array や tuple が malloc してたらそれこそ興ざめだろう

116 ：デフォルトの名無しさん：2012/05/05(土) 14:12:21.70

そりゃ中身がintだもの
intのムーブはコピー

117 ：デフォルトの名無しさん：2012/05/05(土) 14:23:12.01

まったく、俺はバカだな。
array<int,n>&& ys = std::move(xs);
でいいじゃんｗ

118 ：デフォルトの名無しさん：2012/05/05(土) 16:17:53.90

えっ

119 ：デフォルトの名無しさん：2012/05/05(土) 16:37:27.46

参照使うならそもそもstd::move要らなく内科

120 ：デフォルトの名無しさん：2012/05/05(土) 17:41:07.48

やばい、何が正解なのかわからなくなってきた。
古いの持ちだして申し訳ないが、
ttp://d.hatena.ne.jp/faith_and_brave/20080304/1204628281
にある次の例、
class person {
int age;
string name;
public:
person(person&& other)
: age(std::move(other.age)), name(std::move(other.name)) {}
};

でも、
person p{50,"hage"};
cout << &p.name << endl;
person q(move(p));
cout << &q.name << endl;
としたときズレてて、仕事してなくない？

121 ：デフォルトの名無しさん：2012/05/05(土) 17:43:55.77

>>120
動的確保された文字列へのポインタを比較したいんなら static_cast<void*>(&p.name[0]) だろ。

122 ：デフォルトの名無しさん：2012/05/05(土) 17:55:34.19

>>121
サンクス。お見逸れしました。

123 ：デフォルトの名無しさん：2012/05/05(土) 18:02:22.32

すまん、swapの例をintで使ったばあい
int tmp = move(a);
a = move(b);
b = move(tmp);

moveを（どれか）外してコピーが増える？

124 ：デフォルトの名無しさん：2012/05/05(土) 18:10:46.91

見てきたところ、intやdouble、そこから派生するtuple,array
に対してmoveとか頑張りどころが皆無なんだけど、何かある？

125 ：デフォルトの名無しさん：2012/05/05(土) 18:34:41.55

>>123 No
>>124 No

126 ：デフォルトの名無しさん：2012/05/05(土) 18:38:43.49

ムーブは、所有権の移動と考えろ。

127 ：デフォルトの名無しさん：2012/05/05(土) 18:46:45.91

constexpr inline int two() {return 1+1;}
と
constexpr int two() {return 1+1;}
って違いはありますか？

128 ：デフォルトの名無しさん：2012/05/05(土) 18:55:38.75

違いは、inlineであるかどうか。
constexpr関数にはinlineを指定できる。
普通の関数と何ら変わりない。

129 ：デフォルトの名無しさん：2012/05/05(土) 18:57:50.02

>>126
この流れだと、その説明がいちばんしっくりくるわ。
ポインタとか動的に確保されるコンテナには有効だと。

130 ：デフォルトの名無しさん：2012/05/05(土) 19:03:01.82

>>128
なるほど。
・constexprを指定しないとコンパイル時定数としてtwo()が使えない
・inlineを指定しないとインライン展開したい気持ちが伝わらない
（inline指定したところでインライン展開されるかどうかはコンパイラの最適化とかによる、と聞いたことがある）
ってことでいい？

131 ：デフォルトの名無しさん：2012/05/05(土) 19:06:04.04

>>129
あと、そもそもコピーという概念のないリソースもある。
開かれたファイルとかソケットとかスレッドとか。
もちろん、一部の環境ではハンドルの複製なんてこともできるが。

132 ：デフォルトの名無しさん：2012/05/05(土) 19:16:48.54

>>127
違わないよ。

7.1.5/2
> ... constexpr functions and constexpr constructors are implicitly inline.

133 ：デフォルトの名無しさん：2012/05/05(土) 19:18:53.69

>>132
なんとなくだけど、そういうことになってるんじゃないかと思って質問してみたんだ。
ありがとう。

134 ：デフォルトの名無しさん：2012/05/05(土) 19:19:51.80

ところで
constexpr constructor
って初めて聞いたけど、どこで使うんだ？

135 ：デフォルトの名無しさん：2012/05/05(土) 19:27:24.33

>>134 コンパイル時定数として扱って欲しいクラスオブジェクトを作るとき。

136 ：デフォルトの名無しさん：2012/05/05(土) 19:49:56.95

X& X::operator=(X&&)
のデフォルトって、
X::X(X&&)の定義から派生するもの？

そうだとすると
X(X&&)を定義して終わりでもよい？

137 ：デフォルトの名無しさん：2012/05/05(土) 19:53:27.72

だめ

138 ：デフォルトの名無しさん：2012/05/05(土) 19:56:01.93

>134 std::complexな値が定数の畳み込みとかしてくれたら嬉しいとか思ったことは無いかい?

139 ：デフォルトの名無しさん：2012/05/05(土) 19:56:37.05

>>135
なるほど。

なんか新概念の量がやばいことにいまさら気づきはじめた。
いままでライブラリの部分しか見てなかったけど、仕様書の言語機能の部分も読み込むべきなのか？
自分は単なる１ユーザなんだが、ストラウップの新しい本が出たところで全部カバーできるとはとても思えん・・・。

140 ：デフォルトの名無しさん：2012/05/05(土) 20:02:00.12

move ctor が noexcept なら
this->~X();
new (this) X(std::move(other));
return *this;
でダメなケースってのは無かったりするのかな？

141 ：デフォルトの名無しさん：2012/05/05(土) 20:02:05.75

>>138
実は、ちょうどそれっぽいこと（？）をやろうとしていたんだ。
だけど性能の面で、
constexpr array<int,2> f(int&& x, int&& y) { return array<int,2>{x,y}; }
と
constexpr array<int,2> f(const int& x, const int& y) { return array<int,2>{x,y}; }
の違いって下の例で見える？

int main()
{
const int x=1,y=2;
array<int,2> xs = f(x+y,x*y);
array<int,2> ys = g(x+y,x*y);
}

142 ：デフォルトの名無しさん：2012/05/05(土) 20:02:50.46

>>139 必要になってから調べればいいよ。

143 ：デフォルトの名無しさん：2012/05/05(土) 20:04:47.09

>>141
例もクソも、その２つのオーバーロードで性能面の差が出る理由が無い。

144 ：デフォルトの名無しさん：2012/05/05(土) 20:07:17.73

これじゃダメだな。
あくまでコンパイル時に使うかどうか、なのか。

145 ：デフォルトの名無しさん：2012/05/05(土) 20:10:55.36

>>138
コンパイル時にはないなぁ・・・（笑）

146 ：デフォルトの名無しさん：2012/05/05(土) 20:20:34.80

exp( K * j * theta ) とか(j=complex(0,1)ね)使わないか…

147 ：デフォルトの名無しさん：2012/05/05(土) 20:27:35.27

>>146
（コンパイラが悲鳴あげそうだけど）コンパイル時FFTとか、いいね！
けどそこまでやるには、やっぱtuple上でfor文とか、
せめてmap-reduce程度の操作ができないと辛いよな。
（色々やろうと考えたことはあるけど諦めた）

148 ：デフォルトの名無しさん：2012/05/05(土) 21:31:04.81

#include <iostream>
using namespace std;

struct X {
const int x;
X(const int& x): x(x) {}
X(const X&) = delete;
X& operator=(const X&) = delete;
X(X&& rhs): x(move(rhs.x)) {
cout << "called X(X&&)" << endl;
}
X& operator=(X&& rhs) {
cout << "called operator=(X&&)" << endl;
return *this = X(move(rhs));
}
};

int main()
{
X a = X(2);
cout << a.x << endl;
}

・・・誰が呼ばれたの？・・・

149 ：デフォルトの名無しさん：2012/05/05(土) 21:32:43.69

>>148
コンストラクタだろ

150 ：デフォルトの名無しさん：2012/05/05(土) 21:49:43.37

>X a = X(2);
これは代入じゃなくて初期化だ。

151 ：デフォルトの名無しさん：2012/05/05(土) 21:53:02.43

>>148
C++相談スレか、初心者向けのスレに行けよ
C++03の仕様すら知らないのに背伸びするな

152 ：デフォルトの名無しさん：2012/05/07(月) 03:48:07.06

>>147
コンパイル時DFTなら既にあるぞ
http://d.hatena.ne.jp/boleros/touch/20120430/1335794930

153 ：デフォルトの名無しさん：2012/05/11(金) 20:23:40.94

コピコンが delete されてるから形式上ムブコンが呼ばれる事になるが
最適化で消える

154 ：デフォルトの名無しさん：2012/05/12(土) 01:53:51.87

>>153
いやいや
X(const int&)
が呼ばれたということで質問者本人は納得したぞ。

恥さらしなので、しばらく初心者スレに行ってました（笑

155 ：デフォルトの名無しさん：2012/05/12(土) 02:52:36.50

そりゃ呼ばれるに決まってるw
その後の話が聞きたかったんじゃないのか

156 ：デフォルトの名無しさん：2012/05/13(日) 01:43:49.35

test

157 ：デフォルトの名無しさん：2012/05/20(日) 10:16:03.52

あれ？
template <int i> struct int2type {}
って、どこだっけ？
0xで標準のどこかに入ったと思ってたけど勘違いか？
メタプロのあたり見ても出てこない・・・

158 ：デフォルトの名無しさん：2012/05/20(日) 10:37:59.58

あったった。integral_constantか。
お騒がせ～。

159 ：デフォルトの名無しさん：2012/05/20(日) 12:17:02.83

>>151
ここは C++11/C++1y スレなので C++03 は関係ないし
右辺値参照を使っているレスに頓珍漢なこと言ってんじゃねえ

おまえこそ cfront 1.0 や ARM C++ の知識はあるのか

160 ：デフォルトの名無しさん：2012/05/20(日) 13:06:41.48

>>159
は？一つ前の規格ぐらい把握してから来いっつうのは当たり前だろ。
なんでC++お勉強スレでも無いのにそんな一つ前の規格調べれば
わかる内容を、手とり足取り教えなきゃならん。
ここは、新規格部分の内容や影響を話し合う隔離スレだろうが。

>おまえこそ cfront 1.0 や ARM C++ の知識はあるのか
前規格と関係ないだろ理論的に考えられんのか？
そんな思考じゃデバッグも苦手だろプログラマーやめっちまえ

161 ：デフォルトの名無しさん：2012/05/20(日) 13:13:16.30

>>159
何でC++相談室と分離されてるかよく考えろよ

162 ：デフォルトの名無しさん：2012/05/20(日) 13:25:36.65

>>160
「１つ」前ってのはおまえが勝手に言っていることで
俺は承認していないぞ

前提の置き方が主観的なやつこそプログラマなんか務まってねえだろどーせ

163 ：デフォルトの名無しさん：2012/05/20(日) 13:39:43.76

>>159
えっと、あほな質問した本人ですが、
>>148
の
X a = X(2);
は、
X a(2);
に化ける、つまり
X(const int&);
が一回呼ばれて終わり、
ということで納得したんだけど。

右辺値参照は関係ないということでよい？

164 ：デフォルトの名無しさん：2012/05/20(日) 13:48:06.32

ところでさ、split(vector<string>,str,delim)みたいなのがboostにあるけど、
C++11の新機能（stringで何かあったっけ？）使ってtokenizerかんたんに（短く）実装できたりしないかな。
・・・しないか。

あと、正規表現はGCCにまだ載ってないけど、載ったところでAPIがややこしすぎるから
簡単な用途で使わない気がする。乱数もそう。短くかけないから使うとしてもrandom_deviceだけ・・・。

165 ：デフォルトの名無しさん：2012/05/20(日) 13:50:20.18

あと仕様書のPDFをひっくり返すのが重いから、HTML版ほしいな。

166 ：デフォルトの名無しさん：2012/05/20(日) 14:06:06.21

>>159
C++03の話でスレを埋めて何の意味が有るんだ？

167 ：デフォルトの名無しさん：2012/05/20(日) 14:08:41.71

>>162
03の範疇ですむ話をされてもノイズなんだよ。
解らないだろうなぁ。

168 ：デフォルトの名無しさん：2012/05/20(日) 14:21:28.28

>>162
お前が知ってるかはどうでも良くて常識で
考えて空気を読めよって話じゃね？

169 ：デフォルトの名無しさん：2012/05/20(日) 14:55:47.79

>>163
文法上は化けないが、最適化によりムーブが省略される事が規格上許されてるので
最適化でムーブが省略されている

とりあえず無関係な代入演算子を削除した上で、
コピーもムーブも = delete してみ
コンパイルできなくなるから

170 ：デフォルトの名無しさん：2012/05/20(日) 17:24:00.82

>>167
ムーブが関係あるかどうか聞いているのに何バカ言ってんだよ
おまえこそ「ムーブが出てくる C++03」の隔離スレ作ってこもったまま二度と出てくるなドアホ

171 ：デフォルトの名無しさん：2012/05/20(日) 17:48:40.83

11以前の問題だと解らんのならこのスレ来ない方がいいだろ

172 ：デフォルトの名無しさん：2012/05/20(日) 20:17:25.73

03のコピーコンストラクタの最適化を知ってたら
そもそも疑問にも思わんな

173 ：デフォルトの名無しさん：2012/05/20(日) 20:37:26.41

RVOでググれと一言で済ましてれば良かったのに

174 ：デフォルトの名無しさん：2012/05/20(日) 21:51:45.09

>>173
いや質問者が「このスレくんな」って言われた瞬間、思い出したくらいだから、まともな対応だったと思うよ。
もうやめようぜ、せっかくのスレが埋まってしまうから。

175 ：デフォルトの名無しさん：2012/05/21(月) 00:25:24.06

RVOは戻り値最適化であって
ここでは関係なくね

176 ：デフォルトの名無しさん：2012/05/23(水) 21:27:03.45

OpenMPの単純な機能をC++11のthreadで書こうと思ったのですが、
WikipediaでC++11の項目をみると
Further high-level threading facilities such as thread pools have been remanded to a future C++ technical report.
とある。これに関してご存知の方いたら、どんな議論が現在なされているのか教えてもらえませんか。

ちなみに欲しい機能は本当に単純で、
int main() {
const int N = 100000;
static int a[N];
static int m
#pragma omp parallel for private(m)
for (int i=0; i<N; ++i) {
m=i;
a[i]=m;
}
}
程度のもの。threadの数とかは決め打ちでいいです。

177 ：デフォルトの名無しさん：2012/05/23(水) 21:39:13.60

>>175
確かRVO以前の問題で
X object( 10 );と、X object = X( 10 );は
どちらかが構文糖だったはず。
どのコンパイラでもコピコンとか
別のコンストラクターは介入しない
ようになってたと思う。

178 ：デフォルトの名無しさん：2012/05/23(水) 21:43:02.71

上の質問、何を気にしているかというと、

・ループの中身を別の関数で書いて
・thread数だけのプールにその関数をぶっこんで
・main内でthreadをjoinする

と書くことはできるだろうけど、
これだけのためにコードをわかりにくくする必要がないと思っていて、
この作業を抽象化したものがWikipediaで言われているthread poolだろう、
そして、それはOpenMPなみに直感的なものになるだろうと思うんだけど。

簡単にそういう高レベルな内容を実装できると思うならアイディアください。

179 ：デフォルトの名無しさん：2012/05/23(水) 21:49:04.65

threadpool.sf.net
というのがあるみたいですね。

180 ：デフォルトの名無しさん：2012/05/23(水) 22:02:19.43

>>177
canであってmustじゃない
C++ 12.8
when a temporary class object that has not been bound to a reference (12.2)
would be copied to a class object with the same cv-unqualified type,
the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy

181 ：デフォルトの名無しさん：2012/05/23(水) 23:10:52.48

>>177
後者はテンポラリ＋コピーとして解釈する必要がある。
それが直接初期化になるのは最適化として許されていること。
そのため後者ではコピーコンストラクタが private だったりすると
エラーにしなければならない。
というわけで構文糖ではないね。

182 ：デフォルトの名無しさん：2012/05/23(水) 23:12:54.74

Josuttisの標準ライブラリの本２版が出てるんだね。
この本のターゲットに上級者は含まれるんだろうか・・・。

183 ：デフォルトの名無しさん：2012/05/23(水) 23:54:07.50

>>178
よくわからんけどこれじゃだめ?
http://codepad.org/FwKwrASd

184 ：デフォルトの名無しさん：2012/05/24(木) 00:57:18.09

>>180
すぐ見られる仕様書が手元にないしどこに乗ってたか忘れてたが、
一時オブジェクトについての仕様じゃなくコンストラクターに
ついての仕様で書いてあったと思う
コンストラクター以外の関数が同じオブジェクトを返す場合とは
別問題だったはず

185 ：デフォルトの名無しさん：2012/05/24(木) 01:06:40.70

>>184
12.6.1 Explicit initialization
1. (略) [Example:
　　:
　complex c = complex(1,2); // construct complex(1,2)
　　　　　　　　　　　　　　　　　// using complex(double,double)
　　　　　　　　　　　　　　　　　// copy/move it into c
　　:
-- end example]

186 ：デフォルトの名無しさん：2012/05/24(木) 05:32:05.48

>>183
これはすごい。ほとんどfor_eachじゃないですか！
イテレータの部分を分離すればもっと綺麗になりそうだし。
これはSTLに組み込んでほしいですね。
勉強になります。

187 ：デフォルトの名無しさん：2012/05/24(木) 05:34:32.89

>>178
Intel TBBは知ってる？

188 ：デフォルトの名無しさん：2012/05/24(木) 16:38:32.58

>>187
お、知らなかった。
OpenMPとの力関係とか性能比較とか探してみようかな。

ところでスレッドプールと言いましたが、今日Javaの本で調べてみたら
OpenMPのforに対応するものはbarrierパターンと呼ぶようです。
並列for_eachだと終わった時にスレッドが破棄されてしまうのに対し、
mainのなかで再利用し続ける感じになるそう。
スレッドの生成と破棄にどの程度コストかかるのかよく分かりませんが。

189 ：デフォルトの名無しさん：2012/05/24(木) 16:45:00.06

Intel Core iですと大体20000～100000CPUサイクルくらいです。

190 ：デフォルトの名無しさん：2012/05/24(木) 16:52:02.55

>>189
本も出てるんですね。
若干スレチになってしまいましたが、ありがとうございます。

191 ：デフォルトの名無しさん：2012/05/24(木) 17:26:56.49

公式のWikiに「OpenMPはどうなの？」
という項目があって、それに対する回答は
「もしOpenMPがそのまま動くのであればそっちを使ってください。ぶっちゃけ作った人は同じです。TBBのメリットはアルゴリズムやデータのレベルで並列化するところにある」
ってことを言っていました。STLパラダイムにのっかったプログラムを並列化するならTBBってことのようですね。

C++1yに搭載されることを期待したい。
てか、APIはすごい良い感じだからstdにそのまま入れても遜色ないと思うが。

192 ：デフォルトの名無しさん：2012/05/24(木) 17:49:58.76

並列化の手段がマルチコアかGPUか知らないが、
for(auto &x: xs){x=x*x;}
とか書いておくだけで勝手に並列化してくれる時代はいつか来るのだらうか。

193 ：デフォルトの名無しさん：2012/05/24(木) 22:11:06.35

>>191
テレビ・冷蔵庫・電子レンジ・電子ピアノ・ミサイル・タンク・人工衛星。
世の中スレッドはともかく「マルチコアなんそれ」って環境は多い。
そういう環境で並列計算ライブラリなんか導入され手も役に立たないし、
PC用ソフトとライブラリを共有しようと思っても、並列計算が使われてたら
パフォーマンスが落ちるんで寧ろ邪魔になる。

194 ：デフォルトの名無しさん：2012/05/25(金) 00:38:56.42

>>193
そういう freestanding なのはそもそも現状でも隔離されてるじゃないの

195 ：デフォルトの名無しさん：2012/05/25(金) 01:31:53.53

>>192
今でもそれぐらいなら自動並列化が頑張ってくれるでしょ
C系言語の場合は特に、ポインタが混ざり始めたりして依存関係がわけわかんなくなると
最適化に困難が生じてはしまうが……

196 ：デフォルトの名無しさん：2012/05/25(金) 06:08:45.53

>>194
大型家電でフリースタンディングは無いべ。
リアルタイムOSとか入ってて、いわばシングルコアの
非力なPC状態

197 ：デフォルトの名無しさん：2012/05/25(金) 06:44:27.18

コア数-１のスレッドをたてるようにすればいいじゃん、と素朴に思うのだが
そういう問題ではないの？

198 ：デフォルトの名無しさん：2012/05/25(金) 07:29:47.44

libをリンクしなきゃいいだけじゃん

199 ：デフォルトの名無しさん：2012/05/25(金) 10:33:21.66

OpenMPはpragmaで書いて
コンパイラが対応してなければ無視されるようになってるな

200 ：デフォルトの名無しさん：2012/05/25(金) 18:20:26.25

template <class T>
void f(T x){
　　[&] {
　　　　auto y = x;
　　　　std::cout << (&x == &y) << std::endl;
　　}();
}

int main()
{
　　f(0);
}

gcc-4.7 だと true が表示されるんだけど、
これは正しい動作なのか、バグなのか。

201 ：デフォルトの名無しさん：2012/05/25(金) 18:21:05.14

マルチスレッドは実測してみるまで本当に高速化しているかどうかわからない。
要するに超環境依存。そんなものを標準ライブラリに入れる価値がない。

202 ：デフォルトの名無しさん：2012/05/25(金) 18:25:44.21

>>200
非明示的な型をautoで推論するとconst referenceが最優先されるからバグじゃない。

203 ：デフォルトの名無しさん：2012/05/25(金) 19:32:42.74

>>201
マルチスレッド自体は標準に存在すべき。
I/Oの問題は組み込みだろうが、PCだろうが
スレッドが必要になる。
要らないのは、並列計算ライブラリ。
スレッド == 高速化というわけではない

204 ：デフォルトの名無しさん：2012/05/25(金) 19:38:41.35

autoにも色々癖があるんだなあ・・・

205 ：デフォルトの名無しさん：2012/05/25(金) 20:30:58.73

>>202
しかしラムダがなければ false になるんだぜ…

template <class T>
void f(T x){
　　auto y = x;
　　std::cout << (&x == &y) << std::endl;
}

難しいもんだな

206 ：デフォルトの名無しさん：2012/05/25(金) 20:48:16.40

auto はdecltype(rhs) lhs = rhsと同じじゃなかったっけ？
だとすると>>202は正しくない。
ラムダがあってreferenceとして推論されるのは「[&]」で参照キャプチャされるからだと思う。
難しいというか、基礎的な知識から導く部類の問題だね。

207 ：デフォルトの名無しさん：2012/05/25(金) 21:10:44.06

[=]ならfalseということか

208 ：デフォルトの名無しさん：2012/05/25(金) 21:11:47.64

ラムダ式をあくまでも別の関数オブジェクトの呼出しとして説明しようとしたら>>202の動作もないと説明つかんかった

209 ：208：2012/05/25(金) 21:33:00.95

autoとdecltypeは違うという何か
http://ideone.com/2rP8E
http://ideone.com/0R81y

210 ：デフォルトの名無しさん：2012/05/25(金) 21:39:04.54

やっぱりバグっぽい?

7.1.6.4
6. auto の型推論は、関数テンプレートの呼び出しで、テンプレート引数に使われるものと同じ。
(auto を template <class U> の U で置き換えて、推論する)

template <class U>
void g(U z){ z = 2; }

template <class T>
void f(T x){
　　[&] {
　　　　std::cout << x << std::endl;
　　　　auto y = x; // auto が int& に推論されるなら
　　　　y = 1;
　　　　std::cout << x << std::endl;
　　　　g(x); // U も int& に推論されるはず
　　　　std::cout << x << std::endl; // x は変更されたか？
　　}();
}

int main(){ f(0); }

結果:
0
1 // auto は int& になった
1 // U は int になった

211 ：デフォルトの名無しさん：2012/05/25(金) 21:44:27.43

VC11は 0 0 0

212 ：デフォルトの名無しさん：2012/05/25(金) 21:59:14.13

もはやC++11は人智を超えてるだろ……ｗ
実装あるいは思考の道具であるべきプログラミング言語が
それ自体複雑すぎて理解困難とかもうね

213 ：デフォルトの名無しさん：2012/05/25(金) 22:29:27.73

折角Cで身軽にしたのにC++で複雑化してPL/Iの悪夢が再来・・・

214 ：デフォルトの名無しさん：2012/05/26(土) 00:13:32.81

ミサイルなんてパフォーマンスはどうでもよくね？
１秒おくれてに到達したとこで、なにがかわるのか？
１ｍはなれた位置に到達したとこで、なにがかわるのか？

215 ：デフォルトの名無しさん：2012/05/26(土) 00:25:45.44

旋回の制御が遅れりゃ1Km以上の単位で着弾がずれるぞ
とは言え、ミサイルなんてPS2流用してる程度の性能だけど

216 ：デフォルトの名無しさん：2012/05/26(土) 01:06:30.45

>>210
ラムダの中の x というのは f の引数の x ではなく、
ラムダにキャプチャされた x を指す
参照でキャプチャしてるから x は当然 T への参照になる

217 ：デフォルトの名無しさん：2012/05/26(土) 01:13:50.40

>>216
7.1.6.4 読んだ？

218 ：デフォルトの名無しさん：2012/05/26(土) 01:23:23.34

gの方がバグなのかねえ

219 ：デフォルトの名無しさん：2012/05/26(土) 03:44:28.39

auto& でなく auto で宣言してるのに参照になることって言語仕様的にありうるの？

220 ：デフォルトの名無しさん：2012/05/26(土) 16:13:38.11

あるよ

221 ：デフォルトの名無しさん：2012/05/26(土) 16:58:40.01

for(auto& x: xs)
と書けるのに
for_each(xs.begin(),xs.end(),[](auto& x){...})
とは書けない。
これなんで？

222 ：デフォルトの名無しさん：2012/05/26(土) 17:07:28.93

void func(auto a);と書けないのと同じ

223 ：デフォルトの名無しさん：2012/05/26(土) 17:27:33.58

void f(auto a) は template <class T> f(T a) の省略形ってことにしてくれたらはかどるのになあ。
ラムダだって template <class T> operator()(T a) っつーメンバ関数を持つオブジェクトってことにすればいい

>>219,220
5. Expressions
5. If an expression initially has the type "reference to T" (8.3.2, 8.5.3),
　the type is adjusted to T prior to any further analysis.

7.1.6.4 auto specifier
6. (省略)

14.8.2.1 Deducing template arguments from a function call
4. In general, the deduction process attempts to find template argument values
　that will make the deduced A identical to A

というわけなので、最初に T& が T 型へ修正される以上、
auto x = y; の x が参照になることはありえない。

224 ：デフォルトの名無しさん：2012/05/26(土) 19:38:32.99

とりあえず>>210でautoとUが同じ型にならないのはバグっぽいね

225 ：デフォルトの名無しさん：2012/05/26(土) 19:44:49.04

>>223
そんな事したらstd::functionに突っ込めなくなるがな

226 ：デフォルトの名無しさん：2012/05/26(土) 20:38:45.93

template <typename T>
auto f = [](const T& x){return x*x;};
名付けて「テンプレートラムダ」

template using ... と似ててよくね？
ここまでやって本当の関数型言語と呼べるだよ（笑）。

227 ：デフォルトの名無しさん：2012/05/26(土) 20:40:50.24

>>226
テキトーな思いつきなのでautoは決定不能ｗ

228 ：デフォルトの名無しさん：2012/05/26(土) 20:40:51.78

ラムダが使えるからと言って関数型と呼べる訳ではないわけで
(C++で関数型と呼べるのは部分特殊化による演算ぐらい)

229 ：デフォルトの名無しさん：2012/05/26(土) 20:42:03.92

>>226
template <typename T> auto f = [](const T& x){return x*x;} + 1;
って書いたら結果どうなるんだよ

230 ：デフォルトの名無しさん：2012/05/26(土) 20:43:41.12

やべ、冗談で書いたら噴火したｗ
誰か助けて～

231 ：デフォルトの名無しさん：2012/05/26(土) 20:53:36.99

>>229
operator+が定義されてないって怒られるんじゃないでしょうか。
autoに問題があるようには見えない。

232 ：デフォルトの名無しさん：2012/05/26(土) 20:57:49.95

>>231
int (functions)(void)[] = { function1, funciton2 };

(functions + 0)();
(functions + 1)();
ポインターならこういう演算ができる事しってる？
関数オブジェクトは、ローカル変数に依存しなければ
関数ポインターになるので演算自体はできる。

233 ：デフォルトの名無しさん：2012/05/26(土) 21:07:16.63

auto f = [](const T& x){return x->Member();}
そもそもラムダが生成された時点でラムダの実体を作り、
Memberのアドレスを決定せにゃならん。
ましてや、autoに代入する以上実体は必須。
なのでどうあがいても無理。

234 ：デフォルトの名無しさん：2012/05/26(土) 21:11:14.68

>>232
うぇっ初見。
関数ポインタなんか消えてしまえばいいのにｗ

235 ：デフォルトの名無しさん：2012/05/26(土) 21:21:13.35

割り込みベクタとかですげぇ基本的なテクなのに
拒否反応起こすヤツが居るんだ
どんだけC++11スレのレベル下がってんだよ

236 ：デフォルトの名無しさん：2012/05/26(土) 21:26:16.61

int (functions[])(void) = { function1, funciton2 };
じゃないのか

237 ：デフォルトの名無しさん：2012/05/26(土) 21:27:37.64

>>236
*も付けてなかったしな。ゴメン間違えた。

238 ：デフォルトの名無しさん：2012/05/26(土) 21:28:56.44

いや、まだ違うわ
int (*functions[])(void) = { function1, funciton2 };
だわ

これ配列型だから演算出来て当然だよ
関数ポインタは演算出来ない

239 ：デフォルトの名無しさん：2012/05/26(土) 21:33:12.85

http://codepad.org/TW17YYCe
せやろか？

240 ：デフォルトの名無しさん：2012/05/26(土) 21:34:38.70

関数ポインタテーブルって仮想関数の呼び出しに見えない所でバリバリ使われてるやん

241 ：デフォルトの名無しさん：2012/05/26(土) 21:37:00.60

>>239
それC89じゃないですかー

242 ：デフォルトの名無しさん：2012/05/26(土) 21:39:04.07

>>240
仮想関数テーブルは構造体なんで微妙に違うけどな。

struct struct_A_table
{
　int (*FunctionA)();
　int (*FunctionB)(int);
　int (*FunctionC)(int);
};

struct A
{
　static const struct_A_table vtable;
};

243 ：デフォルトの名無しさん：2012/05/26(土) 21:39:18.65

と思ったら-pedanticなしならいけるのか・・・

244 ：デフォルトの名無しさん：2012/05/26(土) 21:39:28.74

>>241
どれでも同じだろうが

245 ：デフォルトの名無しさん：2012/05/26(土) 21:39:34.01

>>239
gcc拡張だろ

246 ：デフォルトの名無しさん：2012/05/26(土) 21:40:37.65

>>245
おれMicrosoftのコンパイラー持ってないから
MSのアレでやってみてくれ

247 ：デフォルトの名無しさん：2012/05/26(土) 21:44:52.95

>>245
clangでも行ける

248 ：デフォルトの名無しさん：2012/05/26(土) 21:46:50.50

-pedantic ありだとやっぱ通らないので gcc 拡張でFA？

249 ：デフォルトの名無しさん：2012/05/26(土) 21:47:36.36

と思ったら -Wall してるからエラーになってるだけだったごめんよ

250 ：デフォルトの名無しさん：2012/05/26(土) 21:48:27.66

拡張疑うなら -std つけて試せよ。

251 ：デフォルトの名無しさん：2012/05/26(土) 21:55:52.44

-pedantic-errors でエラーになったからやっぱgcc拡張だわ

252 ：デフォルトの名無しさん：2012/05/26(土) 21:58:58.87

-std=??? や -ansi はそれだけで規格に厳密になるわけじゃなくて
-pedantic-errors をつけないと拡張機能が有効のまま

253 ：デフォルトの名無しさん：2012/05/26(土) 22:26:18.36

>>235
の後でこの流れｗ
クッソワロタ

結論：使わないが吉。

254 ：デフォルトの名無しさん：2012/05/26(土) 22:45:01.20

1.8 The C++ object model
1. A function is not an object,

5.7 Additive operators
For addition, either (略), or one operand shall be a pointer to a completely-defined object type
and the other shall have integral or unscoped enumeration type.

関数へのポインタの配列(もしくはポインタ)と、
関数へのポインタ自身とを混同しちゃいかん。

そして関数へのポインタは、a pointer to a completely-defined object type
ではない(なぜなら関数はオブジェクトではない)から、加算はできない。

C++11以前の問題だ。

255 ：デフォルトの名無しさん：2012/05/26(土) 22:46:00.82

>>253
関数ポインターはともかく、関数ポインターの配列は必須だろ
割り込みベクターとかハードウェアが要求するコールバックに
オブジェクトの配列なんて指定できんからな

256 ：デフォルトの名無しさん：2012/05/26(土) 22:56:46.02

>>252
-std= 付けても残る拡張機能って、どんなのがあるの？

257 ：デフォルトの名無しさん：2012/05/26(土) 23:01:00.19

>>256
関数ポインタの演算じゃね

258 ：デフォルトの名無しさん：2012/05/26(土) 23:02:17.37

>256 -std=c++98でlong longとか。

259 ：デフォルトの名無しさん：2012/05/26(土) 23:30:30.87

long longってなんで規格かしたんだろ
longが64bitのUnix系統はともかく、Windowsは、128bit CPU出たらどうする気だ？

260 ：デフォルトの名無しさん：2012/05/26(土) 23:35:39.76

そんなもん、shortとかlongとか相対的な単語を使ってる時点で最初から破綻してるだろ
最小サイズ、レジスタサイズ、最大サイズ以外は全部intxx_tでいいよ

261 ：デフォルトの名無しさん：2012/05/26(土) 23:41:08.20

int<64>みたいな文法を決めとくべきだった

262 ：デフォルトの名無しさん：2012/05/26(土) 23:59:38.47

extremely long
super long
ultra long
very long
long
int
short
very short
ultra short
super short
extremely short

こうですね

263 ：デフォルトの名無しさん：2012/05/27(日) 00:16:48.06

int64_tがあるからいいじゃないか
128bit必要ならint128_tも作られるさ

264 ：デフォルトの名無しさん：2012/05/27(日) 00:29:10.17

10進コンピュータならint,kint,Mint,Gint,Tint...か?

265 ：デフォルトの名無しさん：2012/05/27(日) 00:35:52.81

え？
intXX_tってGCC拡張じゃなかったっけ？

266 ：デフォルトの名無しさん：2012/05/27(日) 00:38:46.95

int<64>は同意。
メタプロやるときめっちゃ使う。
int64_tだと、桁数カウントしたいときとかもいちいち特殊化で対応しないといけないから。

267 ：デフォルトの名無しさん：2012/05/27(日) 00:39:46.78

ついでに多倍長も組み込むべきだった。
そういう話は出なかったのかな？
いまさらだけど・・・。

268 ：デフォルトの名無しさん：2012/05/27(日) 00:46:25.21

>>266
つstd::numeric_limits<T>

269 ：デフォルトの名無しさん：2012/05/27(日) 00:57:58.95

>>268
それじゃ足りないときもあるんだよ。

270 ：デフォルトの名無しさん：2012/05/27(日) 01:02:58.05

数値指定に対応するんならbitフィールド形式の方がいいわ
1bitとか7bitとか中途半端な場合は自動変数の場合のみコンパイルエラーにすりゃいい

int value:64;
int value:128;

271 ：デフォルトの名無しさん：2012/05/27(日) 01:45:15.47

>>265
C99で標準化
C++11でも採用

272 ：デフォルトの名無しさん：2012/05/27(日) 01:50:30.04

これでええんとちゃう
ttp://ideone.com/lYklg

273 ：デフォルトの名無しさん：2012/05/27(日) 01:56:08.75

C++ に採用するならついでに
　std::int_least<64>::type
　std::int_fast<64>::type
　std::int_exact<64>::type /* error if not supported */
って書かせてくれてもよかったのに。

274 ：デフォルトの名無しさん：2012/05/27(日) 02:50:39.42

boostにはかなり前からあるけどあんまり使われてないんだろうな

275 ：デフォルトの名無しさん：2012/05/27(日) 03:27:20.57

長ったらしいからな

276 ：デフォルトの名無しさん：2012/05/27(日) 07:26:52.95

>>259
またお前か

277 ：デフォルトの名無しさん：2012/05/27(日) 21:03:43.49

__int128でいいじゃん

278 ：デフォルトの名無しさん：2012/05/27(日) 22:42:27.93

環境依存じゃん

279 ：デフォルトの名無しさん：2012/05/27(日) 23:39:54.33

wchar_tが予約語になった位だから__int128も__int256も予約語にしちゃえ

280 ：デフォルトの名無しさん：2012/05/28(月) 00:47:41.21

何でバイトじゃなくビット表記にしたんだろうね？

281 ：デフォルトの名無しさん：2012/05/28(月) 00:51:56.94

>>279
アンダーバーが付いた予約語なんてやだよ

>>280
汎用機だと、16bitが1バイトだったりするから

282 ：デフォルトの名無しさん：2012/05/28(月) 08:56:00.68

将来、_int16777216を一発で間違いなく入れられる自信がない。

283 ：デフォルトの名無しさん：2012/05/28(月) 19:48:19.85

16777216は覚えやすい方だからいいんじゃないか
24bitフルカラーの色数でもあるし、それなりに使いどころもある

284 ：デフォルトの名無しさん：2012/05/29(火) 12:13:04.04

4294967296のほうが覚えられない

285 ：デフォルトの名無しさん：2012/05/30(水) 22:50:04.77

この初期化ってC++03でいけたっけ？
std::vector<int> v{5,6,4,3,2,6,7,9,3};
某サイトでサンプルに使われてるんだけど・・・。

286 ：デフォルトの名無しさん：2012/05/30(水) 23:01:17.79

いけない
C++03と称してサンプルに使ってるならそのサイト晒せ

287 ：デフォルトの名無しさん：2012/05/30(水) 23:09:16.68

ここです
ttp://www2.research.att.com/~bs/

288 ：デフォルトの名無しさん：2012/05/30(水) 23:31:30.80

規格も理解してねークズ野郎はC++を語ってはいけないよな!!
貴様ごときがC++について語ってんじゃねぇ。即刻閉鎖しろ、ってクレーム出しといてね。>>285

289 ：デフォルトの名無しさん：2012/05/30(水) 23:32:32.02

禿かよw
もうC++といえばC++11じゃん？　的に書いてるだけだと思うよ

290 ：285：2012/05/31(木) 00:55:10.36

>>287
オメー誰だよｗ

このサイトのnth_elementの項目。
http://en.cppreference.com/w/cpp/algorithm
たぶん移行中なんだろうから、許してあげて。

291 ：デフォルトの名無しさん：2012/05/31(木) 01:34:13.82

> たぶん移行中なんだろうから、許してあげて。
なに上から目線で言ってんだｗ
工事中のところが多いが11が基本で98/03に関してのほうがおまけのサイトじゃないか

292 ：デフォルトの名無しさん：2012/05/31(木) 06:12:18.50

VC++2010って右辺値参照一応載ってるみたいだけど安定してる？

293 ：デフォルトの名無しさん：2012/05/31(木) 07:17:30.10

>>290
nth_element自体はC++11じゃなくても使えるからC++11って書いてないだけだと思うよ

294 ：デフォルトの名無しさん：2012/05/31(木) 07:40:05.99

VCでも右辺値参照くらいは一応使えた

295 ：285：2012/05/31(木) 08:25:47.72

>>293
言われてみるとそのようだ。自分の早とちりでした。
けど、自前で11使ってると03に戻るのがしんどくて、つい書きそうになる。

296 ：デフォルトの名無しさん：2012/05/31(木) 09:54:35.97

>>294
ありがとう

297 ：デフォルトの名無しさん：2012/05/31(木) 20:19:30.86

C++ Builder が clang/LLVM 化により突如 C99/C++11 の準拠度トップクラスに躍り出るとか予想外だったw

298 ：デフォルトの名無しさん：2012/05/31(木) 20:26:29.56

マジか？
__propertyなんかは構文糖だから適当にパーサ弄れば済むだろうけど
delphireturnとかレジスタの使い方レベルの互換を取るのはどーすんだ？

299 ：デフォルトの名無しさん：2012/05/31(木) 20:50:23.82

>>298
まったく調べないで言ってるけどclang/LLVMに全て丸投げってことなんじゃないの？

300 ：デフォルトの名無しさん：2012/05/31(木) 23:59:01.79

>>299
VCL使えないと=Delphiと互換を取らないと=旧C++Builderの拡張構文を残さないと、
C++Builderである意味が無いじゃん。
いくらなんでも流石にパーサに手を入れるなりはすると思うんだが。
全部丸投げなら、Windows用のclangのIDE、っていう新製品になってしまう。

301 ：デフォルトの名無しさん：2012/06/01(金) 01:19:31.14

C++Builderにも劣るVisualC++
どうしてこうなった

302 ：デフォルトの名無しさん：2012/06/01(金) 01:35:25.91

C++11に関してVisual C++の対応が遅いのは、
MFCやWTL/ATLを改装する必要が出てくるからじゃろ。
で、改装すれば当然今度は互換性の検証が待っている。

というよりも、Visual StudioからC++が消えて
C++/CXオンリーになる時代も近い。

303 ：デフォルトの名無しさん：2012/06/01(金) 01:38:14.20

C++/CXってそんなたいそうな仕組みが入るもんなのか？

304 ：デフォルトの名無しさん：2012/06/01(金) 12:40:30.33

C++/CXの特徴のひとつはCOMを使いやすくする構文と認識してるわけなんだけど
Win32＋COMも同じように使えるなら・・・

305 ：デフォルトの名無しさん：2012/06/01(金) 13:30:34.21

今時、Win32＋COMって・・・
どんだけ化石だよ

今は、VM上でしか動作しない、インタプリタ系のC#やJAVAが主流だろ

306 ：デフォルトの名無しさん：2012/06/01(金) 13:57:43.65

化石でも動いちゃうんだからすごいよね

307 ：デフォルトの名無しさん：2012/06/01(金) 19:24:24.85

>>305
いや、未だCがトップで主流だけど

308 ：デフォルトの名無しさん：2012/06/01(金) 19:40:32.03

どの分野だよ

309 ：デフォルトの名無しさん：2012/06/01(金) 19:45:11.26

いまだにCOBOLが現役だぜ

310 ：デフォルトの名無しさん：2012/06/01(金) 19:50:24.52

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
まぁ、もっとも実際に使われるかどうかとは別だけど
普及度で言えばCとC++で1, 2になるだろうし
ゲーム屋とかパッケージ屋じゃ相変わらずC++が主流だし
サーバーもFastCGI勢(PHPやらPythonやら)のせいでJavaやC#の普及がいまいち
受注かホビーユーザーばかりが使うからなかなか大きく広まれない

311 ：デフォルトの名無しさん：2012/06/01(金) 22:43:25.18

速度の要求される部分をC++で作って
がわをC#ってのはよくある話

312 ：デフォルトの名無しさん：2012/06/01(金) 22:45:23.60

聞いたことねぇ

313 ：デフォルトの名無しさん：2012/06/01(金) 22:47:07.33

俺も、そんなソフト見たときねぇ

がわはC#でつくるなんてありえないだろ
あのもっさり、ちんたら感ｗ

314 ：デフォルトの名無しさん：2012/06/01(金) 22:51:58.48

ガワの速度がいらんのならスクリプト使う
Pythonとかよっぽど生産的だぞ

315 ：デフォルトの名無しさん：2012/06/01(金) 23:00:32.45

もっさりってどんな低スペック使ってんだ

316 ：デフォルトの名無しさん：2012/06/01(金) 23:11:27.95

.netのngenやmonoのaotオプション使うと、JITより遅くなるがもっさりは減る。
ただ、pythonのが手軽かな。
なんか組み込みはluaが増えてるけど。

317 ：デフォルトの名無しさん：2012/06/01(金) 23:14:31.22

UI部品のレンダリングはC++
どう組み合わせるかはスクリプト。
組み合わせの制御だけなら
もっさりも糞もない。

318 ：デフォルトの名無しさん：2012/06/02(土) 00:40:47.45

組合せるったって、レゴブロックじゃないんだから、組み合わせ以外の制御はどうするの？
組み合わせの制御ってのも良く分からんが、
その、組み合わせの制御とやらはC++では記述しにくいのか？
C++の方がベクトルクラスや行列クラスに演算子のオーバーロードがあるから
よほど記述性は高いと思うが。

319 ：デフォルトの名無しさん：2012/06/02(土) 01:39:36.79

C++で作った親ウィジェットと子ウィジェットを繋いだり、
C++の処理呼び出すイベントハンドラの登録削除したり。
ポインタ管理が要らなかったり、with的なモノが使えたり、
抽象化クラスの定義が不要だったり色々捗る

320 ：デフォルトの名無しさん：2012/06/02(土) 18:18:35.46

C++でコアロジック書いて
C#で画面作成という計画はいくつか見てきたが
そのほとんどが大失敗してる。

あるプロジェクトはC#プログラマの能力不足のせいで破綻した。
C++使える人間はコアロジックにまわされるから、画面を作ってるのは
まともな経験のないなんちゃってプログラマになるという構図がまずかった。

321 ：デフォルトの名無しさん：2012/06/02(土) 18:22:32.16

UIを．ｎｅｔなんてありえないだろ

のっけから失敗だよｗ

大抵、UIはVCL,Qt、MFC、WTLでやる。
WIN32APIのみは、なかなかないな

322 ：デフォルトの名無しさん：2012/06/02(土) 19:05:54.19

お前さんが知らないだけだよ

323 ：デフォルトの名無しさん：2012/06/02(土) 21:01:39.58

ウチの製品はプロトタイプをCUDA C++とMatlabで書いて、製品はASIC/FPGA/DSP + C/C++ + C#/Java/Python使ってるのが多いけど、よくないのかなあ。

324 ：デフォルトの名無しさん：2012/06/02(土) 21:06:16.95

別にいいんでね？

325 ：デフォルトの名無しさん：2012/06/03(日) 01:24:15.35

俺は、速度必要ないところはガンガン、スクリプト使うようにするけどな
外部コマンドの呼び出しをスクリプト化しとくと、多少修正が必要でも
再コンパイルが要らないから便利だ。特にPythonとかbatをスクリプトとして使うと便利。
Pythonは、スクリプトとして使うためのエンジンがboostにあるし、
batならWindowsであれば動く。

326 ：デフォルトの名無しさん：2012/06/03(日) 02:27:01.05

スクリプトで処理させると文字と数値を直接比較できるのも捗るな
何でC++はstd::stringと数値を比較できるように作ってないんだろ
1 == "10あ"とか数値以外混じってたら、falseでいいし難しくないだろうに

327 ：デフォルトの名無しさん：2012/06/03(日) 02:34:47.72

難しい簡単の問題じゃないだろ…

328 ：デフォルトの名無しさん：2012/06/03(日) 11:32:49.85

10 == "10" がtrueになるようなおぞましい言語は死んでいいです

329 ：デフォルトの名無しさん：2012/06/03(日) 11:34:56.23

何が問題だ？
確かに 10 == "10"は困るが、10 == std::string( "10" )なら
困ることないだろ。遅いかもしれんが、んなもん使う側の問題だし。

330 ：デフォルトの名無しさん：2012/06/03(日) 12:04:23.68

それでいいなら自分でore::string書けばいいじゃん。標準をけがす必要がどこに？

331 ：デフォルトの名無しさん：2012/06/03(日) 12:13:30.89

std::to_string(10) == "10" でいいだろ

332 ：デフォルトの名無しさん：2012/06/03(日) 12:17:17.54

std::to_string(10) == " 10" は false じゃないか

333 ：デフォルトの名無しさん：2012/06/03(日) 12:24:05.37

>>330
それを言ったらThreadなんてore::threadで良かったろうが

>>331
テンプレートで使えない

334 ：デフォルトの名無しさん：2012/06/03(日) 12:24:54.80

つか、 10 == atoi( "10" ) でいいじゃないっすか＾＾；

335 ：デフォルトの名無しさん：2012/06/03(日) 12:25:40.86

>>334
テンプレートで使えん

336 ：デフォルトの名無しさん：2012/06/03(日) 12:27:04.88

具体的にテンプレートでどんなふうに使いたいの？

337 ：デフォルトの名無しさん：2012/06/03(日) 12:27:58.34

>>334
それとatoiは事前判定するか、errnoに依存してエラーチェックが必要になる
それぐらいだったら、std::stringstreamの方がマシ。
ただ、どちらもテンプレートでの汎用性はない。

338 ：デフォルトの名無しさん：2012/06/03(日) 12:31:06.28

テンプレートでどう使いたいのか例がないからわからんけど、
そんなに有用だと思うんならハゲに直談判するといいよ。
ハゲは必要なものは採用してくれるハゲだから。

339 ：デフォルトの名無しさん：2012/06/03(日) 12:37:13.03

>>336
実際自分で演算子定義して使ってたりすんだけどね

SelfType &ChangeLevel( const Type &level )
{
　if( !( 0 <= level && level <= 8 ) ) throw InvalidValueError<Type>( key );
　this->level = key;
return *this;
}
※浮動少数系の比較演算子にならい、どちらかが数字でないなら
　　大小に関わらずfalseに倒れる
　　文字列の変換コストが掛かるが、キャッシュしてるので
　　2回目以降は速い。

340 ：デフォルトの名無しさん：2012/06/03(日) 12:39:09.80

変数名がおかしくなってた

SelfType &ChangeLevel( const Type &level )
{
　if( !( 0 <= level && level <= 8 ) ) throw InvalidValueError<Type>( level );
　this->level = level;
　return *this;
}

341 ：デフォルトの名無しさん：2012/06/03(日) 13:08:28.47

namespace ore
{
　　class string: public std::string
　　{
　　public:
　　　　// 比較演算以外は完全に std::string と互換で相互に変換可
　　　　template <class ...Args>
　　　　string(Args&& ...args): std::string(std::forward<Args>(args)...){}

　　　　// 独自の比較オペレータ
　　　　operator bool() const {
　　　　　　if(this->empty()) return false;
　　　　　　if(*this == "false") return false;
　　　　　　try{ return !!std::stoi(*this); } catch(...){}
　　　　　　return true;
　　　　}
　　};

　　// ore::string 独自の演算子定義
　　:
}

342 ：デフォルトの名無しさん：2012/06/03(日) 13:17:17.12

>>341
突っ込みどころ満載ではあるが、それはともかく標準であることに意義があるんだよ。
自作なら既に出来てる。

343 ：デフォルトの名無しさん：2012/06/03(日) 13:22:06.47

標準としてしかるべきところに提案したいならご随意に。そうでないなら只の雑音でしかない。

344 ：デフォルトの名無しさん：2012/06/03(日) 13:24:28.15

気が向いたときに提案するとしても
その前にこの方法で何がマズイかここで叩く事はできるだろ？

345 ：デフォルトの名無しさん：2012/06/03(日) 13:24:44.53

>>342
比較時に勝手に(しかも文字列が)変換される具体的な詳細なんて
合意がとれるわけない。

誰でも簡単に小労力で自分の好みに比較を実装できるんだから
好き勝手にやればいい

346 ：デフォルトの名無しさん：2012/06/03(日) 13:25:35.29

そう思うなら、そのような意図がわかるように素直に振舞うべきであろうよ。

347 ：デフォルトの名無しさん：2012/06/03(日) 13:27:13.12

>>346 to >>344

348 ：デフォルトの名無しさん：2012/06/03(日) 13:32:48.03

>>345
インタプリター系言語だと何故合意がとれてるの？

2番目の理由だと、<tuple>とか不要じゃね
一行書けば誰でも作れるじゃん

349 ：デフォルトの名無しさん：2012/06/03(日) 13:36:08.82

標準で、文字列と数値を比較したいってことは、
これはたぶん暗黙の型変換の類の話だな。
暗黙の型変換はCに在ったからC++に引き継がれたが、
暗黙の型変換はC++ではオーバーロードとの酷い競合を引き起こすから、
決して褒められたものではないのはC++erなら常識だよな。
C++は暗黙の型変換とオーバーロードでオーバーロードを選択したから、
これ以上に暗黙の型変換を増やすことはもう無いだろう。
もし、数値型と文字列を直接比較したいのなら、
==オペレータのオーバーロードで解決するのがC++流ってことになる。

350 ：デフォルトの名無しさん：2012/06/03(日) 13:38:52.88

元々比較演算子の話だよ

351 ：デフォルトの名無しさん：2012/06/03(日) 13:39:05.44

そして "0" == 0 でtrue/falseどっちを返しても非難gogoですね、わかります

352 ：デフォルトの名無しさん：2012/06/03(日) 13:41:30.64

>>348
javascript のバージョンによって、ブラウザによって、
0 == "0" の意味は変わってきた(はず)

それはつまりコンセンサスが取りづらいということ。

353 ：デフォルトの名無しさん：2012/06/03(日) 13:41:45.93

>>351
std::string( "0" ) == 0 でなんか問題あるの？

354 ：デフォルトの名無しさん：2012/06/03(日) 13:42:38.38

言ってることが場当たり的な気がする。頭の中にあるべき姿があるのか疑問。
最初にきちんとrationaleでも書いてみては。

355 ：デフォルトの名無しさん：2012/06/03(日) 13:45:48.92

>>352
0 == "0"がtrue以外の何になるの？
型まで判定するときは 0 === "0" じゃないと
ECMAScriptの規格外でしょ

356 ：デフォルトの名無しさん：2012/06/03(日) 13:47:29.43

>>354
一貫してstd::stringと数値の比較って言ってない？

357 ：デフォルトの名無しさん：2012/06/03(日) 13:47:45.52

>>351
0は数値なのかヌルポなのか分からないもんな。
このように、暗黙の型変換とオーバーロードは非常に相性が悪い。
C++にC由来の暗黙の型変換を残してしまったのは失敗だったね。

358 ：デフォルトの名無しさん：2012/06/03(日) 13:50:08.09

>>357
そもそも""はタダのchar配列で、std::stringじゃないでしょ。

359 ：デフォルトの名無しさん：2012/06/03(日) 13:51:11.72

>>355
ECMAScript が普及する前の話だよ。
=== が登場したのは 0 == "0" になってほしくない人々への言い訳だよ(多分)

スクリプト、というとき ECMAScript だけを念頭に置いているなら簡単じゃないか。
std::ECMAScript_string が欲しいって提案すれば事足りる

360 ：デフォルトの名無しさん：2012/06/03(日) 13:53:27.01

型安全に興味がなく、速度も気にしない…C++使う意味無いじゃないｗ
Effective C++にある通り、自動の型変換は危険でダーティ。C++では使わないに越したことはない。
それをどうしても必要としていて、なおかつ速度もきにしないのだから、C++で組む価値はない。

361 ：デフォルトの名無しさん：2012/06/03(日) 13:54:28.61

>>359
ECMAって規格に順次てないから問題になったんでしょ
そりゃC++だって規格に準じてなきゃどんな機能だって同じじゃん
現にC++11だって規格違反のコンパイラーはいっぱいある。
規格に成立させる上で何が問題かが重要でしょ。

362 ：デフォルトの名無しさん：2012/06/03(日) 13:56:17.68

>>360
厳密には暗黙の型変換じゃないし、型安全も変わらないんだけど。
型で保証される事は、実行時でも保証される訳じゃん。

363 ：デフォルトの名無しさん：2012/06/03(日) 13:57:35.90

型安全じゃないだろ。
少なくともEffective C++にはそう書いてあるようにしか自分には読めなかったが…（不勉強であることは認める）

364 ：デフォルトの名無しさん：2012/06/03(日) 13:58:32.41

std::string( "0" ).compare( NULL ) //true

365 ：デフォルトの名無しさん：2012/06/03(日) 13:59:54.11

>>363
あなたの型安全の定義を教えてもらえるかな？
私としては、実行時に型違反に伴うエラーが起きず
コンパイル時にチェックされることだと思ってるけど。

366 ：デフォルトの名無しさん：2012/06/03(日) 14:00:40.31

>>364
それで困ることあるの？

367 ：デフォルトの名無しさん：2012/06/03(日) 14:06:21.70

>>365
型安全の定義はそのとおりだが、
10 == "10" という構文を許すためにはどちらかに自動の型変換が必要になる。
自動の型変換（コンストラクタにせよoperatorにせよ）そのものがC++では危険（必ずしも1対1に対応しないケースが往々にして生じる）なので、
この構文を許す機構が型安全でなくなる…というのがEffective C++の主張だったように思う。

368 ：デフォルトの名無しさん：2012/06/03(日) 14:13:57.83

C++では型変換はコンストラクタで行うことになってる。
それも、暗黙ではなく、明示的に呼び出す形が推薦される。
変な予約語を追加してまで、わざわざそうした。
(予断だが、型変換オペレータもあるが、危険なので、今は誰も使っていない)
そこまでして暗黙の型変換を徹底的に排除する姿勢が今のC++。
std::string::compareが数値型を取ることは、C++の現状にマッチしていないのだよ。

369 ：デフォルトの名無しさん：2012/06/03(日) 14:23:07.15

>>367
operator Type()の話じゃないの？

比較演算子とか他のオーバーロードとは別物だと思う。
>>339-340にも書いたと思うけど、文字と数値を比較して
文字列に数字以外が混じっていればfalse。これは、
doubleのNaNと同じ動作だから問題にはならない筈で
型安全に問題をきたす事は無いと思うよ。

370 ：デフォルトの名無しさん：2012/06/03(日) 14:44:29.13

>>369
ああ、なるほど。
bool operator ==( int, string const & );
bool operator ==( string const &, int );
のような類を記述するってこと？それなら問題ない。
しかし、やはり標準には入れられない。
なぜなら、char*やstringの中に記述された数値列をどう扱うかは
人によって直感的でないから。
これはCording Standardsの主張だったはず。

371 ：デフォルトの名無しさん：2012/06/03(日) 14:45:03.94

>>368
boostもalgorithmもオーバーロードによる型変換を使ってるけど、オーバーロードも含めダメってのは
どこら辺を参考にすれば乗ってる話？MFCとかMS系はひどすぎるので勘弁して欲しい。

372 ：デフォルトの名無しさん：2012/06/03(日) 14:53:35.11

std::string::compare( int )を許すのなら、std::string::compare( double )も許す必要がある。
他にも数値型はある。std::std::complexや独自のものなど。
これらについての扱いをどうするのか考えなければならない。
さらに、compareだけ対応するのはおかしいので、assignやappend、その他にもこれを許す必要がある。
型*対応メソッドで爆発するから型変換をオーバーロードでサポートするのは現実的ではない。
だから型変換は別で行ったほうが良い。しかし、オーバーロードの関係上、型変換は明示的に行う必要がある。
明示的に行うということは、明示的に記述するのだが、
問題は、C++で型変換の記述がいまいち一本化されていないところ。
通常はコンストラクタで代用するが、基本型はクラスを持たないし、加えてC++はオープンクラスではないから、
後から拡張することが出来ない。
型変換はコンストラクタで一本化するとして、
後から拡張できるように、
コンストラクタをクラス外にも定義できるようにしてもらいたいところだね。

373 ：デフォルトの名無しさん：2012/06/03(日) 15:00:20.51

>>370
了解。「Cording Standards」はこういう名前の文章があるの？
何かの一部に書いてあるの？

>>372
std::istringstreamが対応してる型だけでいいじゃん。
他は、各自対応すればいい。メンバー関数じゃないから拡張できる。

あと、assingやappendは数値型と互換性がないから意味が無いでしょ
元々、数値型と同じテンプレートが使えるってのがメリットなんだし。
数値型にできない事ができてもしかたない。

374 ：デフォルトの名無しさん：2012/06/03(日) 15:05:32.81

別に暗黙に比較がしたいわけじゃなくて、テンプレート中で比較したいって話だよね？
boost::lexical_castが標準に入ればいいんじゃないかと

375 ：デフォルトの名無しさん：2012/06/03(日) 15:09:11.85

そうだぬ

376 ：デフォルトの名無しさん：2012/06/03(日) 15:10:38.83

LOCALEも考慮しようぜ!

377 ：デフォルトの名無しさん：2012/06/03(日) 15:14:40.06

>>373
>元々、数値型と同じテンプレートが使えるってのがメリットなんだし。
なら、std::stringについて、数値型で行える+や+=などの演算も対応するのか？
しかも str += i; は誰がもう見ても文字列ベースのappendにしか見えないのに、
実際には数値ベースの+=が行われるのか?
文字列と数値を同じように扱いたいなら、まず型を合わせることを考えたほうが良い。
型さえあってれば何の問題も無いのだから。
今回の話であれば、文字列を数値として扱いたいって話だから、
intのコンストラクタに　int( std::string & )　が有れば良いはなし。
C++はクラス外でのコンストラクタの拡張を認めてないけどね。

378 ：デフォルトの名無しさん：2012/06/03(日) 15:14:44.12

std::stringの持つtraitsに合わせりゃよくね。
そもそも、C++のロケールは、マルチバイト考慮してない糞だけど。

379 ：デフォルトの名無しさん：2012/06/03(日) 15:17:29.39

>>377
+=に比較演算子程のメリットがあればね。
×数値型の仕様の範囲を逸脱
○数値型の仕様の範囲に満たない
とは考えてる。

380 ：デフォルトの名無しさん：2012/06/03(日) 15:28:46.82

>>379
C++標準で、std::string( "0" ) == 1　が認められるなら、
std::string( "0" ) + 1 も認められないと。
比較だけ特別に認めるって変な仕様を標準化委員会が認めるとでも？

std::string( "0" ) + 1
しかしこれは、文字列ベースの結合なのか、数値演算の+なのか、
仮に数値演算の+動作だったとしても、
戻り値は文字列なのか整数型なのか、わけが分からないだろ。
だからまずは型を合わせることを考えるのだ。
型さえあってればその先で問題は出ないのだから。
std::string( "0" ) + std::string( 1 ) //文字列ベースの結合、戻り値std::string。
int( std::string( "0" ) ) + 1 //数値演算の+、戻り値int。
問題は、C++で型変換の方法がいまいち統一されていないところ。

381 ：デフォルトの名無しさん：2012/06/03(日) 15:32:37.85

そりゃI/O streamが認められたり、
コンテナに演算子として比較演算子と
代入演算子だけが認められてるんだから、なぁ・・・

382 ：デフォルトの名無しさん：2012/06/03(日) 15:36:29.10

それはそのコンテナの制約に過ぎないだろ。
std::string( "0" ) == 1　を認めるってのは、言語全体の根本の、演算の定義の話だぞ。

383 ：デフォルトの名無しさん：2012/06/03(日) 15:45:49.94

仮に　std::string( "0" ) == 1　だけ特別に認められるとしても、
あくまで数値ベースでの比較であるっていう暗黙さ加減はどうするよ。
ちゃんと型変換してから比較すれば、そういった曖昧さはなくなるんだよ。

384 ：デフォルトの名無しさん：2012/06/03(日) 17:31:00.80

なんかC++11になってからますます暗黙性が増してるよな。
auto然り、初期化リスト然り、コンストラクター継承然り、
無名関数のメモリー管理然り。iostreamで型に合わせて
暗黙で型変換してた時代から大してその姿勢は変わってないけど。

385 ：デフォルトの名無しさん：2012/06/03(日) 17:42:39.83

string を数値型と比較したいっていうけどさ、
string だけ特別扱いするわけにもいかないから
結局任意の型を数値型と比較できないといけなくなって、
それだったらやっぱり明示的に型変換したほうが
一貫性がとれてていいんじゃないの。

386 ：デフォルトの名無しさん：2012/06/03(日) 17:51:07.56

必要性もなければ、あとで追加できるのに、標準型でない
std::string以外も対応させなきゃいけない理由が解かんない
I/O Streamだって後で作った型は自分でなんとかしろって感じだし
あれに合わせりゃいいじゃん

387 ：デフォルトの名無しさん：2012/06/03(日) 17:51:28.96

そこまで複雑な動きは
== じゃなくて関数にするべき
スクリプト言語くらいいい加減ならともかく

388 ：デフォルトの名無しさん：2012/06/03(日) 17:55:29.15

I/O Streamだって同じ複雑な事してるし、シリアライズ系だって同じ複雑な事してる。
Boostの入出力系統や、アルゴリズム関係はもっと複雑なことする演算子を定義してるね。

389 ：デフォルトの名無しさん：2012/06/03(日) 17:59:28.81

iterator関係も単に文字と数字の比較とは比べ物にならん複雑な処理してるな

390 ：デフォルトの名無しさん：2012/06/03(日) 18:21:10.29

iostreamは、ストリームへの変換や、ストリームからの変換、と決まっている。
シリアライズ系も同様。
しかし、
std::string( "0" ) == 1
の場合は、文字列で比較するのか数値で比較するのかが不明。

391 ：デフォルトの名無しさん：2012/06/03(日) 19:41:09.65

std::string("0xFFFFFFFF") == 0xFFFFFFFF
std::string("10.0") == 10
std::string("1.00000000001") == 1.00000000001f
どれがtrueでどれがfalseになるのかわからん

392 ：デフォルトの名無しさん：2012/06/03(日) 20:25:13.48

>>391
std::string側にtraitみたいな感じで定義もたせときゃいいじゃん
iostreamだってtraitとは違うけどできてる訳だし

393 ：デフォルトの名無しさん：2012/06/03(日) 20:26:20.06

>>390
数値で比較する意味はあっても文字で比較する意味なくね？
どう足掻いても数値型の上限以上は比較しようが無いんだから。

394 ：デフォルトの名無しさん：2012/06/03(日) 20:32:44.06

そうだとしても、気持ち悪いだろ。
大小比較まで考えたら、文字コードでやるのと数値でやるので結果変わるし。

395 ：デフォルトの名無しさん：2012/06/03(日) 20:58:03.08

>>391
文字をどう数字として見なすかは、たとえatoiだろうが、
scanfだろうが、iostreamだろうが、どれを使っても同じ問題があるんじゃね。

396 ：デフォルトの名無しさん：2012/06/03(日) 21:00:45.20

同じ問題を抱えているのは、その中ではiostreamだけだな。

397 ：デフォルトの名無しさん：2012/06/03(日) 21:21:30.95

scanfもatoiもiostreamも十六進、八進、浮動少数表記をどう判断するか
どうしようもないのは同じハズですが？違いと言えば、atoiが代入先の変数に
縛られないぐらいでしょう。どのみちatolとか関数名で振り分けるんで大差ないですが。

398 ：デフォルトの名無しさん：2012/06/03(日) 22:17:08.37

誰でも分かる事は意見が大量に出て逆に議論が無茶苦茶になる・・・か

399 ：デフォルトの名無しさん：2012/06/03(日) 22:31:49.89

パーキンソンの凡俗法則だな

400 ：デフォルトの名無しさん：2012/06/03(日) 22:57:51.30

std::string("10") + std::string("100") == 110
std::string("10") + std::string("100") == 10100
どーちだっ？

401 ：デフォルトの名無しさん：2012/06/03(日) 23:18:40.05

10100に決まってるだろ
+は==より結合力が強い

402 ：デフォルトの名無しさん：2012/06/03(日) 23:29:52.02

std::string("10") + std::string("100") == 110こっちじゃ暗黙の型変換じゃねぇか
何が嬉しいんだよ

403 ：デフォルトの名無しさん：2012/06/03(日) 23:40:01.57

>>397
ぜんぜん違う。たとえば、scanfは引数で明示的にフォーマットを指定できる。
16進数のときは「x」などなど。
std::string("FFFF")　==　0xFFFF　//どうなるんでしょうね
scanfで↑こんな間抜けな問題は発生しない。

404 ：デフォルトの名無しさん：2012/06/03(日) 23:49:59.19

そういやそうだった。でもatoiにかんしちゃ同じでしょ。
というか、scanfファミリーとstrto*ファミリーぐらいか。
とは言え、通常はtraitとロケールで指定しときゃ十分だよね。
通常16進数か10進数ぐらいしか使わない訳だし。

405 ：デフォルトの名無しさん：2012/06/04(月) 00:06:48.32

atoiは10進数って、明示的に決まってるから、あいまいさは無いだろ。
std::string("FFFF")　==　0xFFFF
と同じ問題を抱えているのはiostreamだけだ。

406 ：デフォルトの名無しさん：2012/06/04(月) 00:17:02.11

じゃ10進数固定でいいんじゃね

407 ：デフォルトの名無しさん：2012/06/04(月) 06:10:40.51

PHPじゃあるまいし

408 ：デフォルトの名無しさん：2012/06/04(月) 17:00:34.78

全部Variant型に変換しようぜ

409 ：デフォルトの名無しさん：2012/06/04(月) 20:32:56.24

Variantにしたら半端なくおせぇだろうが

410 ：デフォルトの名無しさん：2012/06/04(月) 21:31:27.72

>>373
遅れたけど、Cording StandardsはC++ Cording Standardsっていう書籍名。
ハーブサッターとかが執筆していて、Effective C++みたいな本。

411 ：デフォルトの名無しさん：2012/06/04(月) 21:37:26.28

0 + std::string("10") + std::string("100") == 110 // true
std::string("10") + std::string("100") == 10100 // true

412 ：デフォルトの名無しさん：2012/06/05(火) 00:57:11.30

std::string("10") + 0 や std::string("10") + 0 + std::string("100") は?

413 ：デフォルトの名無しさん：2012/06/05(火) 20:30:36.38

>0 + std::string("10") + std::string("100") == 110 // true
>std::string("10") + std::string("100") == 10100 // true

下はともかく、上がtrueになるって発想がプログラマーとして終っとるわ
文字結合を数値に倒す言語が一つも存在しない事を考えりゃ上はありえん

414 ：デフォルトの名無しさん：2012/06/05(火) 21:01:02.79

Perlとか使った事無いのか

415 ：デフォルトの名無しさん：2012/06/05(火) 21:11:38.33

>>413
違う。「どっちもありえない」んだよ。
+は結合順位が左から右だから 0 + std::string("10") を処理する時点で
文字列と数値のどっちを優先するのか決めておく必要が生じる。
もしこれを文字列として扱うなら
std::string("100") == 110
という単一の式も110側を文字列に変換しないといけない。

文字列を数値に自動変換することを許してしまうと
>>411の上で良いことになってしまう。

416 ：デフォルトの名無しさん：2012/06/05(火) 21:14:23.07

すまん、途中で送信しちまったｗ
＞文字列を数値に自動変換することを許してしまうと
＞>>411の上で良いことになってしまう。
の部分はカットね。

417 ：デフォルトの名無しさん：2012/06/05(火) 21:26:41.13

>>415
他の言語にならえばいいじゃんそんなの。
無名関数や正規表現まで取り込んだなら
ゼロコストであるかぎり問題ないだろ

418 ：デフォルトの名無しさん：2012/06/05(火) 21:27:42.52

他の言語に倣うんだったら他の言語使えばいいんだよ。
別にC++は至高の言語でも究極の言語でもないんだから。

クソみたいな曖昧さはもうこれ以上結構。

419 ：デフォルトの名無しさん：2012/06/05(火) 21:29:13.44

数値と文字列で比較はできても結合できる必要は無いな
既に似たような仕組みがあるし

420 ：デフォルトの名無しさん：2012/06/05(火) 21:29:35.71

まあ文字列を数値として扱わないって決めるに至った議論は
はるかに偉いおっさんどもが長くかけたんで
いまさらここで「なんで？」とか言っても気持ち悪いだけなんだけどね…

421 ：デフォルトの名無しさん：2012/06/05(火) 21:31:14.10

じゃ無名関数も正規表現もautoも要らんだろ
他の言語にないC++だけが最初に実装した機能だけで十分

422 ：デフォルトの名無しさん：2012/06/05(火) 21:31:30.39

どうせstd::string("100") == 100こんなキモイの標準に入らないからどうでもいいよ

423 ：デフォルトの名無しさん：2012/06/05(火) 21:51:16.87

昔、stringクラスを各ベンダー独自に実装してた時代には、
実際そういうのができるものもあって、喧々諤々、結局削ったんだよな。
それでもなお、ベンダーどもが譲らなかったせいでstringクラスはあんな「物知りっく」なクラスにｗ

424 ：デフォルトの名無しさん：2012/06/05(火) 21:52:57.89

無名関数や正規表現の議論はイましている最中（いや、一応終わったんか）だが
stringの議論は十年以上前に決着がついてる。
単にここの人たちが周回遅れなだけ。

425 ：デフォルトの名無しさん：2012/06/05(火) 22:04:58.36

まだ伸びてたんですね。
とりあえず致命的な指摘も無かったので、
boostのIRCで向こうの意見を伺うことにしました。
ご意見ありがとうございました。

426 ：デフォルトの名無しさん：2012/06/05(火) 22:12:15.01

>>423
どう見ても貧相だろ
せめてマルチバイト対応ぐらいするべきだ
おかげで皆ベンダー実装ばかり使う

427 ：デフォルトの名無しさん：2012/06/05(火) 22:13:51.44

マルチバイト対応がおかしいのはlocaleのせいであって、stringのせいじゃないんじゃないか？

428 ：デフォルトの名無しさん：2012/06/05(火) 22:19:46.42

localeもあるが添字で文字単位じゃなく型単位でしか
参照できない。iteratorも文字単位じゃなく型単位でしか参照できない。
仮に型を1文字に合うように作ってもcharやwchar_tじゃないんで
std::ifstreamとかから取り込めない。

429 ：デフォルトの名無しさん：2012/06/05(火) 22:22:51.40

>>422
他の言語なら暗黙で文字列がStringに変換されて
直接比較できるように見える。
他の言語なら普通な表現だろ

430 ：デフォルトの名無しさん：2012/06/05(火) 22:26:36.30

std::string("l00") == 100

431 ：デフォルトの名無しさん：2012/06/05(火) 22:29:52.60

「他の言語」の具体例を上げてから言おうぜ。
そしてそれをプログラマ人口で欧文比例して、
普通といえるかどうかを議論しよう。うん。

432 ：デフォルトの名無しさん：2012/06/05(火) 22:37:29.58

しかも文字列じゃなくて、数値に変換しての比較だしな。
文字列の方が扱う広いのに、文字列のほうを数値に合わせるって時点で暗黙の変換とも言いにくいし。

433 ：デフォルトの名無しさん：2012/06/05(火) 22:42:09.79

javascript, php, vbs( vbaなども含む ) bash, zsh これだけでC++の人口超えるぞ

434 ：デフォルトの名無しさん：2012/06/05(火) 22:45:37.04

どうしてそういうクソ言語ばっかりなんですかっ！

435 ：デフォルトの名無しさん：2012/06/05(火) 22:46:58.12

明らかにフィールドの違う言語群を持ってこられても…なぁ
最初から同じ土俵にいないっていうか、戦う相手を間違えているというか

436 ：デフォルトの名無しさん：2012/06/05(火) 22:47:53.55

そういやperlも可能なんだっけか？

437 ：デフォルトの名無しさん：2012/06/05(火) 22:50:18.52

ゼロコスト機能かどうかが問題であって
土俵云々関係ないだろうが
だったら正規表現も
無名関数も土俵が違うだろ

438 ：デフォルトの名無しさん：2012/06/05(火) 23:12:52.08

どっひょー。

439 ：デフォルトの名無しさん：2012/06/05(火) 23:13:28.49

ゼロコストならナニ入れてもいいとか、それは幻想ですよ＾＾

440 ：デフォルトの名無しさん：2012/06/05(火) 23:18:27.89

>>434
どの言語ならなっとくすんだよw

441 ：デフォルトの名無しさん：2012/06/05(火) 23:20:09.28

型が静的な言語なら

442 ：デフォルトの名無しさん：2012/06/05(火) 23:21:44.91

boostに意見出しに行くとか言ってるヤツもいるし
そろそろどうでもいいや

443 ：デフォルトの名無しさん：2012/06/05(火) 23:26:03.50

>>441
つVB.net

444 ：デフォルトの名無しさん：2012/06/05(火) 23:28:29.18

>>443
vbならしょうがない

445 ：デフォルトの名無しさん：2012/06/08(金) 21:51:21.51

ここにするか、スレ立てるまでもないにするか迷ったが、聞きたい。
"C++11"の読みって"しーぷらぷらいちいち"でよいのか?

446 ：デフォルトの名無しさん：2012/06/08(金) 22:50:46.54

俗称なんだし好きにすればいいじゃない

447 ：デフォルトの名無しさん：2012/06/09(土) 01:26:48.21

スィープラスプラスイレヴン

448 ：デフォルトの名無しさん：2012/06/09(土) 07:31:07.99

filesystemってまだC++11に入ってないんだっけ？

449 ：デフォルトの名無しさん：2012/06/09(土) 10:16:47.51

TR2だな

450 ：デフォルトの名無しさん：2012/06/09(土) 15:06:58.12

>>445
http://shinh.skr.jp/yomikata/#C%2B%2B11
しーぷらすぷらすじゅういちとしーぷらぷらじゅういちがあっとうてきなとうひょうすうでわんつーふぃにっしゅです

451 ：デフォルトの名無しさん：2012/06/09(土) 23:19:07.28

Colorをコロールと読むかカラーと読むか、
Themeをスウィームと読むかテーマと読むか、
Directをドゥルゥクトと読むかダイレクトと読むかぐらいどうでもいい

452 ：デフォルトの名無しさん：2012/06/09(土) 23:58:38.22

ATAをｱﾀって読む人がいるんですけど・・・
良いんですかね？

453 ：デフォルトの名無しさん：2012/06/10(日) 00:04:41.82

つたわりゃ何でもいいだろ

454 ：デフォルトの名無しさん：2012/06/10(日) 01:27:59.42

ATAはｴｰﾃｨｰｴｰって読むけど
ATAPIならｱﾀﾋﾟｰって読む

455 ：デフォルトの名無しさん：2012/06/10(日) 05:30:39.50

SATA ｻﾀ,ｴｽｱﾀ
PATA ﾊﾟﾀ,ﾋﾟｰｱﾀ
ATA ｱﾀ

456 ：デフォルトの名無しさん：2012/06/11(月) 11:57:11.69

会話で出すときはシープライレブンまたはシープラジュウイチだな

457 ：デフォルトの名無しさん：2012/06/11(月) 14:20:30.19

シープラプライチイチになると予想

458 ：デフォルトの名無しさん：2012/06/11(月) 14:25:01.85

2011
ニーマルイチイチ
ニセンジュウイチ

459 ：デフォルトの名無しさん：2012/06/12(火) 12:14:17.47

シープラスプラスジュウイチだろＪＫ

460 ：デフォルトの名無しさん：2012/06/12(火) 13:37:10.68

インクリメントと読まないなら11もワンワンと読まなければ釣合が取れないな

461 ：デフォルトの名無しさん：2012/06/12(火) 21:04:03.64

シープラスプラスジュウイチだとうっかりC++1yでy=7になったときに困るだろ、常識的に考えて。

462 ：デフォルトの名無しさん：2012/06/12(火) 21:35:04.73

0xとか0yとかって名前もどうなんだろうな
C++00+yの方が自然だろうに

463 ：デフォルトの名無しさん：2012/06/13(水) 07:30:53.26

俺もシープライレブンだな

464 ：デフォルトの名無しさん：2012/06/13(水) 21:11:00.95

ジュウナナでいいじゃん

465 ：デフォルトの名無しさん：2012/06/13(水) 22:22:28.62

std::vectorの連続性って、Defect Report Listで決議されてただけで
規格にはなってないんだよな。いつになったら規格書に乗るんだ？
ま、別に規格にならないほうがメモリー分散して
スレッドを生かした実装とかできて便利だと思うが

466 ：デフォルトの名無しさん：2012/06/13(水) 22:30:54.46

bunsan_vectorとか新たに作れよ

467 ：デフォルトの名無しさん：2012/06/13(水) 22:37:27.76

http://toro.2ch.net/test/read.cgi/tech/1338365782/321-
C言語の仕様に異常に詳しい皆様、助けに来てください

468 ：デフォルトの名無しさん：2012/06/13(水) 22:39:32.60

とっくに規格に入ってるだろハゲ 23.3.6.1 Class template vector overview

469 ：デフォルトの名無しさん：2012/06/13(水) 22:42:44.05

C++03で入ってるもんなあ

470 ：デフォルトの名無しさん：2012/06/13(水) 23:41:15.31

>>467
文字列を介してfloatを正確に移動するには
同じサイズの整数型を中継するしか無い

fprintf(fp, "%u\n", *(unsigned*)&a);
fscanf(fp, "%u\n", (unsigned*)&a);
　註：どの整数型が最適かは環境依存。
　　　C99ならもうちょい移植性の高い書き方もできるけど、
　　　floatのサイズが4バイトである事を仮定しないと面倒になるのは変わらない
　　　参考 : http://seclan.dll.jp/c99d/c99d09.htm

もちろん出力される文字列はfloatとしての値を
容易に想起できるものではないけど、
正確さは保証される

小数値として出力してしまうと常に誤差との戦いになる
正確に移動できる場合もあるけど、できない場合もある
正確さが必要なら、可読性は犠牲にせざるを得ない

471 ：デフォルトの名無しさん：2012/06/13(水) 23:46:36.34

というか、C99なら%aが使えるわな
小数を16進数で出力するので精度を上げれば正確に出力できる

472 ：デフォルトの名無しさん：2012/06/14(木) 01:15:07.44

>>471
MSのVC2010はprintで%a使えるがscanでは使えないという糞だな

473 ：デフォルトの名無しさん：2012/06/14(木) 01:27:55.27

結局整数経由が楽だな

474 ：デフォルトの名無しさん：2012/06/14(木) 01:47:02.80

それも環境またぐと怪しいけどな

本当は指数部、仮数部、符号に分解してそれぞれ整数で保存するのが一番だろうけど
標準の範囲で出来たっけ

475 ：デフォルトの名無しさん：2012/06/14(木) 07:22:07.54

環境言い出すと、ある環境で表現出来る値が
別の環境で表現出来ないとか出てくるので、
そうなると100%再現不可能なケースがどうしても出てくるだろうな

476 ：デフォルトの名無しさん：2012/06/14(木) 08:45:11.02

>>474
frexp

477 ：デフォルトの名無しさん：2012/06/14(木) 09:02:56.13

テキストだから人間が読めないとダメです
人間というのは16進数で表現された浮動小数点数が読める異常な人間ではなく
そのへんにいる中学2年生の女の子を想定してください
いろんな人やいろんなコンピュータに読んでほしいです

なので本当の意味で正確に移動したいわけではなく
%Eで表現できる範囲でよくて（%Eで表現できる範囲が実装依存なのかは分かっていない）
その出力入力で（許される範囲で）値が同じことのテストが書きたいだけなのですが
floatのフォーマットや計算誤差についての説明を受けるなど厳しい対応を受けています

478 ：デフォルトの名無しさん：2012/06/14(木) 09:12:59.36

最近の中学2年生の女の子はfloatのフォーマットや計算誤差についての説明を求めるのか

479 ：デフォルトの名無しさん：2012/06/14(木) 09:13:12.09

一つのスレでやれ

480 ：デフォルトの名無しさん：2012/06/14(木) 09:57:31.25

呼んだつもりが割り込んでしまったので答えてしまいました
すみません

ところで別の話題ですが、C++にはstd::scientificやstd::hexfloatがありますが
あれを使うとfloatのやりとりが正確にできるとかそういうことはありますか

481 ：デフォルトの名無しさん：2012/06/14(木) 10:11:50.47

is_iec559でassert

482 ：デフォルトの名無しさん：2012/06/14(木) 22:07:31.59

>>465
うわっ！俺連続性を前提としてコード書いてた orz

483 ：デフォルトの名無しさん：2012/06/14(木) 22:09:11.81

>>468,469
あ、連続性前提にしても規格的に大丈夫なのね。よかったよかった。

484 ：デフォルトの名無しさん：2012/06/15(金) 00:48:50.71

ちなみにC++11でstringのバッファの連続性も規格に入りました。
C++03でもstring のバッファが不連続の実装があるとは思えないけど。

485 ：デフォルトの名無しさん：2012/06/15(金) 15:47:40.78

Template Aliases のサポートはgcc4.7.0からか。

どこかにWindows32bit版のバイナリーコードないかな。
makeするの結構めんどくさいし。TDM gccも 4.6.1でサポートが停止してるし。

486 ：デフォルトの名無しさん：2012/06/16(土) 17:56:47.74

ちょっと質問いいですか？

void func1( int &&i ){}

template< typename t >
void func2( t &&i ){}

int main()
{
　　int i=0;
　　func1( i ); //コンパイルエラー
　　func2( i ); //OK
　　return 0;
}

いったいコンパイラの中で何が起こってるの？

487 ：デフォルトの名無しさん：2012/06/16(土) 17:59:59.42

tがint&になるのでは?

488 ：デフォルトの名無しさん：2012/06/16(土) 18:08:27.02

そこの解釈が良くわからないんですよ。
どうしてint&になるの？

489 ：デフォルトの名無しさん：2012/06/16(土) 19:35:31.65

諦めろそういうもんだ

490 ：デフォルトの名無しさん：2012/06/16(土) 19:56:34.72

t=intだとfunc1と同じでダメだから
次の候補としてt=int&に挑戦するんだよ
int& &&はint&だからこれは上手く行って、t=int&だと最終的に判断する

491 ：デフォルトの名無しさん：2012/06/16(土) 20:19:11.47

↓コンパイラで起きていること

14.8.2.1 Deducing template arguments from a function call
●仮引数が rvalue reference で、実引数が lvalue のときは、
実引数の型 int は int そのものではなく int& として仮引数と比較される。

●仮引数が t& もしくは t&& の形のときは、t が実引数の型と比較される。

●仮引数の型は、実引数の型と一致するように決定される。

つまり t = int& になる。(t&& は int& && になる)

8.3.2 References 6段落
●int& && は int& と等しい。

最後に int& は int の lvalue を受け取ることができる。

492 ：デフォルトの名無しさん：2012/06/16(土) 20:31:14.47

丁寧な説明ありがとうございます。
しかし、本当にややこしい。

493 ：492：2012/06/16(土) 20:45:42.80

上記の話題は、
http://slashdot.jp/journal/507551/C%2B%2B%E5%8F%B3%E8%BE%BA%E5%80%A4%E5%8F%82%E7%85%A7%E8%A7%A3%E8%AA%AC
の下のほうに載ってたわ。
完全転送のための拡張だったのな。

494 ：デフォルトの名無しさん：2012/06/16(土) 20:49:49.65

もうさ、プログラミングって機械に任すべきじゃね？
俺達人間が扱ってもミスが多いし時間ばかりかかってしょうがないでしょ

495 ：デフォルトの名無しさん：2012/06/16(土) 20:51:06.07

uyは帰れ

496 ：デフォルトの名無しさん：2012/06/16(土) 21:05:31.13

これからは自動プログラミングの時代

自動プログラミング
http://toro.2ch.net/test/read.cgi/tech/1339847861/

497 ：デフォルトの名無しさん：2012/06/16(土) 21:32:57.82

しかし、std::forwardって使う意味あるのかね。
std::forward<X>(arg)　って書く替わりに、
(X &&)arg って書いても問題ないよね。

498 ：デフォルトの名無しさん：2012/06/16(土) 23:02:20.36

動作は問題ないけど旧方式キャストは滅亡すべきとされてるので問題あり

static_cast<X&&>(arg)なら本当に問題ないけどタイプ数は大して変わらないし
forwardの方が意図が出ててよい

499 ：デフォルトの名無しさん：2012/06/16(土) 23:08:27.06

はっはっはっ、関数だからSTLアルゴリズムに簡単に突っ込めるじゃないか。
…と思ったが、クロージャあるからどうという手間もないんだよな。

500 ：デフォルトの名無しさん：2012/06/16(土) 23:41:11.22

まあ右辺値参照がよくわからないって声はわりと聞くし
std::moveとかstd::forwardは理解の助けになるかもね

501 ：デフォルトの名無しさん：2012/06/17(日) 11:34:53.84

分かりにくいってより、使いどころが。

メソッドの引数でオブジェクトを受けるとき、
1．値渡しにすべきか、
2．左辺参照渡しにすべきか、
3．左辺参照渡し+右辺値参照渡しのオーバーロードにすべきか、
4．テンプレート+右辺値参照渡しで完全転送すべきか、
使いどころが難しい。
1．だとmoveに対応してない物を渡すときのコストが大きいし、
2．だと右辺参照の情報が消えるし、一時変数を渡せないし、
3．だと組み合わせ爆発するし、
4．だと常にテンプレート関数になるし、仮想関数に出来ない。

constは基本的にボトムアップな伝播だから旨く行ったけど、
右辺値左辺値情報のようなトップダウン伝播を、型で伝えるのは無理があったようだね。
素直に参照のバイト数を増やして、右辺値左辺値判定フラグを持たせたほうが良かっただろうな。

502 ：デフォルトの名無しさん：2012/06/17(日) 11:45:05.07

左辺値参照：壊したら駄目
右辺値参照：壊して良い　←new!

何が難しいのかが分からん
難しいのならとりあえずコピーコンストラクタに使っておけば良い

503 ：デフォルトの名無しさん：2012/06/17(日) 11:52:00.02

そういえば、JIS規格でのC++11の規格番号はどうなった？
IOSが正式発行しているんだから、JISも発行されてるはずだよな。
X3014は相変わらず03のままだから、別の番号を持ってくるんだよな？

JIS規格がないと右辺値参照の本格的パンツレスリング勉強ができない。

504 ：デフォルトの名無しさん：2012/06/17(日) 11:58:56.21

>>502
右辺値参照の情報を、関数を超えて持ちまわるのが面倒くさい。

505 ：デフォルトの名無しさん：2012/06/17(日) 12:12:28.47

持ちまわる必要ない

506 ：デフォルトの名無しさん：2012/06/17(日) 12:22:50.85

struct hoge_t{
　　std::vector< std::pair< std::string, std::string > > v;
　　template< typename t, typename u >
　　void push( t &&first, u &&second ){
　　　　v.push_back(
　　　　　　std::make_pair(
　　　　　　　　std::forward<t>( first ),
　　　　　　　　std::forward<u>( second ) ) );
　　}
};
int main(){
　　hoge_t hoge;
　　std::string str;
　　hoge.push( std::string(""), str );
}
firstとsecondはstd::stringの参照って分かりきってるのにテンプレートで非明示になるのが嫌だな。

507 ：デフォルトの名無しさん：2012/06/17(日) 13:20:23.67

>>503
誤訳脱落糞訳語だらけのJISなんか見ちゃいけません

508 ：デフォルトの名無しさん：2012/06/17(日) 13:27:40.77

だからといって自力で英語の文章を誤解なく確実に翻訳できる自信はない(´・ω・｀)

509 ：デフォルトの名無しさん：2012/06/17(日) 14:39:15.03

どうせなんか変だと感じた文は原文当たるし

510 ：デフォルトの名無しさん：2012/06/17(日) 15:03:56.97

JISは糞って時々見かけるけど
これをまともにする方法ってないの

511 ：デフォルトの名無しさん：2012/06/17(日) 15:51:48.45

お前が WG に参加してまともにしてこい。
いいだしっぺの法則。

512 ：デフォルトの名無しさん：2012/06/18(月) 20:58:36.12

>>488
templateの場合だけは特別扱いされる

513 ：デフォルトの名無しさん：2012/06/18(月) 21:12:06.79

>>497
言っている事がよく解からん
テンプレ関数の引数に左辺値だった値が渡されても右辺値になってしまうんだから、
左辺値の引数を左辺値として扱いたいならstd::forwordの様なキャストが必須だろうに。

514 ：デフォルトの名無しさん：2012/06/18(月) 21:52:41.25

template< typename X >void func( X &&arg ){ (X &&)arg; }
int i;
func( 0 ) → 「X=int」 void func( int &&arg ){ (int &&)arg; }
func( i ) → 「X=int&」 void func( int& &&arg ){ (int& &&)arg; }　→　void func( int& arg ){ (int&)arg; }

515 ：デフォルトの名無しさん：2012/06/18(月) 21:53:16.47

moveやforwardって要するにキャストなんだよね？

516 ：デフォルトの名無しさん：2012/06/18(月) 22:00:04.40

castだねぇ。castのwrapperだねぇ～。

517 ：デフォルトの名無しさん：2012/06/18(月) 22:05:24.93

条件分岐があることは忘れずに

518 ：デフォルトの名無しさん：2012/06/18(月) 22:42:36.00

やたら右辺値参照の話題が盛り上がるが、そんなに使うか？
shared_ptrが標準になったお陰でユーザーが見る代入の需要が益々減ってるように思うが。
(ライブラリ作る側には重要だとは思う)

519 ：デフォルトの名無しさん：2012/06/18(月) 22:52:36.16

いろいろ追加された言語機能の中でもコンパイラの実装が進んでて気軽に試せるものだし
コンセプトが先送りされた今となっては目玉機能だからなあ

520 ：デフォルトの名無しさん：2012/06/19(火) 00:41:26.00

std::vector<std::unique_ptr> がどれだけ右辺値参照の恩恵にあずかっているか

521 ：デフォルトの名無しさん：2012/06/19(火) 02:52:06.59

最適化で勝手に速くなる分には一向にかまわんって感じだよな。

テンプレートの可変引数にconstありなしの自動対応もよろしく。

522 ：デフォルトの名無しさん：2012/06/19(火) 23:27:13.16

operator +の実装では引数がrvalueとlvalueの場合の
4パターン実装するの？

523 ：デフォルトの名無しさん：2012/06/19(火) 23:31:44.63

破壊の必要なのって通常片方だけだし
そんなには必要ないと思われ

524 ：デフォルトの名無しさん：2012/06/22(金) 02:52:31.31

>>477
float.hのFLT_DIG, DBL_DIG, LDBL_DIGではだめかな？
（printfの精度指定でこれらの値を指定する）

525 ：デフォルトの名無しさん：2012/06/22(金) 11:02:11.43

>>521
template< typename t > void func( t && ){}
int main(){
　　int i=0;
　　int *p=&i, &r=i;
　　int const *cp=&i, &cr=i;
　　func( 0 ); //t=int
　　func( i ); //t=int &
　　func( p ); //t=int *&
　　func( r ); //t=int &
　　func( cp ); //t=const int *&
　　func( cr ); //t=const int &
　　return 0;
}
問題は、t=「intの何か」に制限できない点。
間違った型を渡してしまったとき、コンパイルエラーが深いところで出る。

526 ：デフォルトの名無しさん：2012/06/22(金) 11:03:33.67

あ、テンプレート可変引数の話か。ごめん

527 ：デフォルトの名無しさん：2012/06/27(水) 12:27:15.87

C++11 の参考書はよ

528 ：デフォルトの名無しさん：2012/06/27(水) 12:37:33.41

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf

529 ：デフォルトの名無しさん：2012/06/30(土) 01:22:17.16

go langの型推論に感動した。
value := 0;
代入式にコロンつけりゃ推論してくれる
なぜC++もこの方式を導入しなかったんだ。

530 ：デフォルトの名無しさん：2012/06/30(土) 01:34:42.58

:って

531 ：デフォルトの名無しさん：2012/06/30(土) 02:36:18.80

ぜんぶキャストしろ。　勝手に決めんな。

532 ：デフォルトの名無しさん：2012/06/30(土) 02:40:51.13

>>529
大体、右辺式の型を変数の型にする程度なら大昔からあるんだよ。
今更のように実装して、仰々しく「型推論」なんて呼ぶことすら、真面目にUnificationしている言語に失礼だ。

533 ：デフォルトの名無しさん：2012/06/30(土) 03:42:26.61

autoあるしね

534 ：デフォルトの名無しさん：2012/06/30(土) 05:46:49.41

:= は代入と比較を区別するために C 以前の大昔からある。

>>530 顔文字？小さい「っ」が鼻？

535 ：デフォルトの名無しさん：2012/06/30(土) 06:01:50.31

ヾ:っi

536 ：デフォルトの名無しさん：2012/06/30(土) 16:46:55.89

>>533
autoじゃなくて、:=が良かったって話で。

537 ：デフォルトの名無しさん：2012/06/30(土) 16:53:11.25

>>536
変数宣言の型名に何て書くの？
型名無しで「変数名 := 値;」を宣言構文にするってこと？

538 ：デフォルトの名無しさん：2012/06/30(土) 16:54:50.11

帰れ

539 ：デフォルトの名無しさん：2012/06/30(土) 16:58:09.69

お前が帰れ

540 ：デフォルトの名無しさん：2012/06/30(土) 17:20:25.84

:= は代入、= は比較って Pascal か

541 ：デフォルトの名無しさん：2012/06/30(土) 17:22:24.13

>>537
529にそう書いてあるじゃん

542 ：デフォルトの名無しさん：2012/06/30(土) 17:29:00.87

>>529
>なぜC++もこの方式を導入しなかったんだ
型を後置するGoと違ってC++でそれが採用されるわけないな
むしろ何故autoでなく:=が導入される余地があったと思ったのか

543 ：デフォルトの名無しさん：2012/06/30(土) 18:05:15.74

>>542
>型を後置するGoと違ってC++でそれが採用されるわけないな
意味がわからん

544 ：デフォルトの名無しさん：2012/06/30(土) 18:08:43.90

分からなくていいからGoスレに帰れ

545 ：デフォルトの名無しさん：2012/06/30(土) 18:11:00.15

TIOBE50位にも入らないクソ言語が何だって？

546 ：デフォルトの名無しさん：2012/06/30(土) 18:11:23.82

むしろ後置宣言の方が不要だろ

var value Type; この宣言の代わりに
var value := 100; でいいわけだからな

547 ：デフォルトの名無しさん：2012/06/30(土) 18:13:13.48

1言語狂信者が多いな、いつの間にRuby厨みたいなのが増えたんだ・・・

548 ：デフォルトの名無しさん：2012/06/30(土) 18:14:33.62

DとかGoとか特にいいところのない言語には興味ないだけ。

549 ：デフォルトの名無しさん：2012/06/30(土) 18:14:58.86

>>545
4～5年でTIOBE50に入ってる言語ってなんだよ
むしろそんな言語あったら教えてくれ

550 ：デフォルトの名無しさん：2012/06/30(土) 18:18:51.39

C#はvarがC++のauto相当だから
var value = 100; でいいしな

>>547
思い込み激しいって言われたこと無いか？

551 ：デフォルトの名無しさん：2012/06/30(土) 18:18:59.34

Goも本格的にGoogleが使い始めたら普及すんだろうにな
言い出しっぺが実践しないとなかなか普及しない
Androidの標準言語にでもすりゃいいんだ

552 ：デフォルトの名無しさん：2012/06/30(土) 18:22:44.85

いや一言語至上主義者が増えたな。
昔はC++関係は比較的そういう人が少ない傾向にあった。
複数の言語の中で気に入った言語があるのは良いことだが
他を排斥するようになったら終わりだ。

553 ：デフォルトの名無しさん：2012/06/30(土) 18:25:08.28

>>550
varやautoと排他的な話じゃないだろ
無駄だけどautoと:=を共存させることだって出来る
:=方がカスケードが効くってだけの違いだ

554 ：デフォルトの名無しさん：2012/06/30(土) 18:26:11.60

x := y := z := 0; か・・・

555 ：デフォルトの名無しさん：2012/06/30(土) 18:27:16.44

>>552
単に老害が増えたんだろ

556 ：デフォルトの名無しさん：2012/06/30(土) 18:37:36.15

>>552
標準委員会が蹴った提案も全部排斥呼ばわり出来るな
批判を認めない奴の方が終わってるよ

557 ：デフォルトの名無しさん：2012/06/30(土) 21:01:00.30

本当の意味で批判(Critical Thinking)できる奴も減ったな
外人がやってるのは批判だがお前らがいう批判は批難ばっか

558 ：デフォルトの名無しさん：2012/06/30(土) 22:20:48.31

そこで「外人」はどうなの？

559 ：デフォルトの名無しさん：2012/06/30(土) 22:44:52.15

Critical Thinkingでググれ

560 ：デフォルトの名無しさん：2012/06/30(土) 23:05:23.28

減るというよりコミュニティが大衆化する過程で薄まる的なよくある話

561 ：デフォルトの名無しさん：2012/06/30(土) 23:11:08.94

外人って韓国人のこと？

562 ：デフォルトの名無しさん：2012/06/30(土) 23:31:19.04

朝鮮人とCritical Thinkingなんて水と油だろ
奴らからしてみりゃ宇宙も韓国から始まってんだから

563 ：デフォルトの名無しさん：2012/06/30(土) 23:49:22.45

>>561
あれは外人でなく、人外だ。

564 ：デフォルトの名無しさん：2012/07/01(日) 00:06:12.67

今時「外人は～」って言い方を聞くとは思わなかった。
しかも批判精神がどうのこうのと云う人から。

565 ：デフォルトの名無しさん：2012/07/01(日) 01:08:27.70

>>559
googleのurlが分からないので、yahooじゃダメですか？

566 ：デフォルトの名無しさん：2012/07/01(日) 01:15:15.23

http://www.google.com/webhp?hl=de&complete=0

ほれ。
オレが繋いでるグーグル乃あどれすだ

567 ：デフォルトの名無しさん：2012/07/01(日) 21:53:08.56

>>529
そんなん、大昔の VB みたいにスペルミスのバグを防ぐために option explicit つけろってなるよ。
var value = 0; の方がずっといい。

568 ：デフォルトの名無しさん：2012/07/01(日) 23:23:58.78

>>567
型推論と動的型付言語の違い分かってる？
VBのアレは、動的型付の禁止だぞ

569 ：デフォルトの名無しさん：2012/07/01(日) 23:38:20.25

:= 式の型推論ってケン・トンプソンが発案者だっけか

570 ：デフォルトの名無しさん：2012/07/02(月) 12:49:24.75

C++11 の参考書はよ

571 ：デフォルトの名無しさん：2012/07/02(月) 18:12:41.78

あーでも、
x:=y:=z:=0; は便利そうだなぁ。
auto x=0, y=0, z=0;
ってのは宣言が前から修飾して代入が後ろから修飾するって言う、
宣言と代入の合わせ業になってて、それゆえに発展性がないんだよな。
宣言と代入を同時に行う文法を新たに増設するとして、
一貫して後ろから修飾するなら、x:=y;=z:=0;だろうし、
前から修飾するなら、0 x y z;　だな。
0 x y z; はC++の語感的には有りだけど、
typoして演算子とか書き忘れたら変数宣言になるってのは痛いな。

572 ：デフォルトの名無しさん：2012/07/03(火) 07:55:05.47

>>568
俺が何を言ってるのか分からないなら、
option explicit スペルミス
でググってよ。
value := 0;
(略)
if ( hoge ) {
valeu := 1;
}
のバグを見栄えで見つけるのが容易とは言い難いという話なんだけど。

573 ：デフォルトの名無しさん：2012/07/03(火) 08:02:46.19

valeu = 1;だったらバグっぽいと思うけど:=なんだし問題ないんじゃないの

574 ：デフォルトの名無しさん：2012/07/03(火) 14:15:52.33

なんで問題ないんだよｗ

575 ：デフォルトの名無しさん：2012/07/03(火) 14:39:50.91

valu := 1; は auto valu = 1; ってことだろ
宣言なんだから

576 ：デフォルトの名無しさん：2012/07/03(火) 15:09:13.95

>>575
はあ？
>>572はスペルミスの検出について言ってると思うんだけど。

577 ：デフォルトの名無しさん：2012/07/03(火) 15:10:26.50

どうやらauto万歳ってことみたいだな。

578 ：デフォルトの名無しさん：2012/07/03(火) 15:15:01.24

もしautoやDIM無しで変数宣言出来て代入式も宣言式にも違いが無かったら痛い言語だわ
for (value=0;value<END;++value){value=0;}

579 ：デフォルトの名無しさん：2012/07/03(火) 15:34:08.80

>>576
「:=」は宣言専用で代入には使わないってことじゃない？

俺もvarかautoの方が宣言と分かりやすくて良いと思うけど

580 ：デフォルトの名無しさん：2012/07/03(火) 15:36:19.72

LET もよろしく

581 ：デフォルトの名無しさん：2012/07/03(火) 15:38:25.30

>>529
C++は静的に出来るだけ型を決定する事により速度を高めている
goのそれはかなりの頻度で勝手な型推論を許してしまいバグの温床にならないか？

582 ：デフォルトの名無しさん：2012/07/03(火) 15:43:18.70

出来るだけどころか、完全に決定します。

583 ：デフォルトの名無しさん：2012/07/03(火) 17:02:44.80

型の自動変換もなくしたしな

584 ：デフォルトの名無しさん：2012/07/03(火) 18:55:49.86

>>582
仮想関数は例外なんだが

585 ：デフォルトの名無しさん：2012/07/03(火) 20:02:01.05

scalaで型推論＋自動変換でバリバリ持ち回られると激しく混乱してしまうのは
俺がバカなせい？

型推論使う時は明示的なキャストを、自動変換使う時は明示的な型宣言を
強制する方がソースコードは読みやすくなる気がするんだが・・・・・・

586 ：デフォルトの名無しさん：2012/07/03(火) 23:06:30.82

>>572
==と=でも間違えそうだね

587 ：uy ◆pdu1UZmweE ：2012/07/04(水) 01:30:05.37

>>585
おめでとうございます
よく気づいたな

型推論（笑）をやっていったその先に何があるかというと
動的言語と同じ問題が静的言語でも発生するようになるだけだよ

型推論のせいでタイプ数は減っても、
情報が目に見えなくなるから、可読性が落ちるのもそのひとつ
a := "test"
↓
～数百行～
↓
b := a　　←型推論　　　bの型なんてわかりゃしねえ

b := bb
c := cc ッ手やるべき場所を

b := cc
c := bb　ッ手やってもエラーは起きない
結局これなら中途半端に型推論とかやらないで最初から動的言語使っていたほうがいい
しかしこれから数年間は、変な奴らが型推論型推論あげまくってるから、この中途半端な概念のゴミカス型推論を使いまくった
超超ゴミッカスソースコードが量産されていくんだろうなｗｗｗｗ、そして１０～２０年後にソース引き継ぐ奴が涙目になるじゃんやったね

588 ：uy ◆pdu1UZmweE ：2012/07/04(水) 01:32:04.98

結局のところ静的言語は
型推論をかなり制限して、ちゃんと型をかくようなコードに落ち着くと思うよｗｗｗｗｗｗｗｗｗｗｗｗ

589 ：デフォルトの名無しさん：2012/07/04(水) 01:35:29.87

MLだと型システムが閉じているみたいだけど、仕事に使ってる場合はインターフェースに型を明示して共同作業しやすいようにしてると聞く。

590 ：デフォルトの名無しさん：2012/07/04(水) 01:36:56.95

型チェック=型推論らしい。

591 ：デフォルトの名無しさん：2012/07/04(水) 02:20:56.72

>>587
Haskelみたいな環境だと、その間違うかもしれない部分
b := ...
c := ...
の後にbとcがどのような型に参照されるかまでをプログラムの終わりまで
チェックするんで、そこを間違えただけならコンパイラはエラーを指摘できるよ

592 ：デフォルトの名無しさん：2012/07/04(水) 02:41:02.91

キー入力の手間を省くなら言語いじるんじゃなくて、エディタのほうをいじれよｗ

593 ：デフォルトの名無しさん：2012/07/04(水) 03:01:53.25

型推論で型注釈を省略しても
いつでも必要なときに
エディタに型を表示させられるよ

594 ：デフォルトの名無しさん：2012/07/04(水) 03:25:37.22

貶めるなら貶めるで、対象の言語をある程度使ってから書けよ…

595 ：デフォルトの名無しさん：2012/07/04(水) 08:03:29.98

アホはRubyとかJavaを使ってれば良いのに
どうしてC++スレに来るのだろうか？

自分に使いこなせない言語のスレに来て
無知丸出しの書き込みをするのに何の意味があるの？

596 ：デフォルトの名無しさん：2012/07/04(水) 09:51:40.71

>>587
じゃなくてコンパイラやIDEが知ってることが重要なんじゃん。
ダックタイプでどうやって推論結果のツールチップ出すの？

597 ：デフォルトの名無しさん：2012/07/04(水) 12:45:09.90

どうせなら、aが定義されてるかどうかも検出して
a = 100;
とかくと
int a = 100;
を勝手に補間してくれるエディタがあれば良いんでなかろうか。

598 ：デフォルトの名無しさん：2012/07/04(水) 20:48:27.04

>>597
int a=0;
…
{
　　a=100;
}

599 ：デフォルトの名無しさん：2012/07/04(水) 20:52:37.94

いまさらだけど、テンプレートクラスの構文は、
class name< type T >{};
が良かったなぁ。
テンプレート関数の構文も、
void func< type T >(){}
が良かったなぁ。

600 ：デフォルトの名無しさん：2012/07/04(水) 20:54:24.22

違うんだ。公式にはクラステンプレートであり、関数テンプレートなんだ。

601 ：デフォルトの名無しさん：2012/07/04(水) 21:01:40.46

>>599
戻り値後置記法があって初めて成り立つ文法じゃないか

602 ：デフォルトの名無しさん：2012/07/04(水) 21:06:58.59

void func< type T >(){}
これだと
T func< type T >(){}
ができないな

603 ：デフォルトの名無しさん：2012/07/04(水) 21:39:10.36

テンプレートはファイルスコープかネームスペース規模で適用して欲しかったな
テンプレートメタなんて変態チックな技に対しても結構高い防壁になったろうし

604 ：デフォルトの名無しさん：2012/07/04(水) 22:36:09.75

func<type T>() -> T { } ならできるが
既に時遅しなんだろうなあ

605 ：デフォルトの名無しさん：2012/07/04(水) 22:41:06.04

もうプログラミング飽きたわ
こんな面倒くさいことは機械に任せたほうがいいだろ

606 ：デフォルトの名無しさん：2012/07/05(木) 00:12:03.60

アゼンブラ「オレのことか？」

607 ：デフォルトの名無しさん：2012/07/05(木) 01:08:01.08

プログラミングなんて仕事以外でやってるやつなんて変態だろ？ｗ
それか、よっぽど暇で友達いない奴くらいなもの

会社に行けば、嫌というほどやらされるｗ

608 ：デフォルトの名無しさん：2012/07/05(木) 01:08:32.24

そんな土方自慢されても困るわ…

609 ：デフォルトの名無しさん：2012/07/05(木) 01:14:05.91

そのドカタがやってること真似てる人って・・・

610 ：デフォルトの名無しさん：2012/07/05(木) 05:20:56.62

まさかドカタは自分が底辺ってことが分かってないのか？
お前等がやってるのはプログラミングというよりコピペだぞ

611 ：デフォルトの名無しさん：2012/07/05(木) 10:32:05.99

ちょっと高度な電卓の使い方に詳しいってだけでは何の意味も無いもんな。
本当に有意義な生産活動をしようと思ったら、
それぞれの分野についての専門知識が必要だわ。
実際に飯食おうと思ったら、
対象分野の知識　>　数学の知識　>　コンピュータの知識
って感じ。
しかし、数学は何するにしても必要だし、基礎体力だから、学生さん的には、
数学　>　専攻分野　>　コンピュータ
だろうな。
どちらにしても、コンピュータを学ぶのは後からでも間に合うわ。

612 ：デフォルトの名無しさん：2012/07/05(木) 10:50:52.68

>>610
プログラミングを少しでもやってる人なら
底辺こそ一番偉いのを知っているはず

おまえドライバとか書いたことないだろ

613 ：デフォルトの名無しさん：2012/07/05(木) 17:40:19.48

底辺は皆ドライバを書いているのだろうか
ドライバを書いた人はみな底辺なのだろうか
答えを求めて旅に出ようと思います

614 ：デフォルトの名無しさん：2012/07/06(金) 00:24:45.64

ドライバーとか書けない奴をドカタというんだろ
そもそも、代わりがいくらでもいる作業してるから
ドカタ呼ばわりされるわけで

615 ：デフォルトの名無しさん：2012/07/06(金) 00:33:16.89

蒸し返すなよw

616 ：デフォルトの名無しさん：2012/07/06(金) 00:58:17.36

UIを作る必要がないため、ドライバはもっともとっつきやすい
客先にあれこれいわれることもないし。

UIは本当に面倒

617 ：デフォルトの名無しさん：2012/07/06(金) 01:03:26.34

標準関数もユーザー空間のAPIも一切使えないのにとっつきやすい訳がない
ユーザーモードドライバーの話してんのか？

618 ：デフォルトの名無しさん：2012/07/06(金) 01:07:51.09

ソフトのバグかと思ったら
ハードのバグでしたとか
そういう事を聡く見抜ける人じゃないと無理

619 ：デフォルトの名無しさん：2012/07/06(金) 01:09:57.36

お客がどうのこうのとかスレ違いどころか板違いだろw
頭悪

620 ：デフォルトの名無しさん：2012/07/06(金) 01:10:47.69

ハードのバグ

621 ：デフォルトの名無しさん：2012/07/06(金) 01:15:49.62

ハードのバグをソフトでごまかしたり

622 ：デフォルトの名無しさん：2012/07/06(金) 23:04:18.79

よし、蒸し返すぞ＾＾
もう口が酸っぱくなるほどどんな起業本にも出てくるんで知ってるだろうけど、
業務っていうのは反復普遍でないとだめなわけだ。
これはつまり、従業員全員が代わりの聞くドカタであるのが最良の企業だといってるのとほぼ同じ。
そうじゃない奴は管理職になる。

儲かる仕組み、儲かる思考がルーチンワーク化しているから大企業は儲かり続けるんだ
という話はイノベーションのジレンマにも出てきた話。
しかし同様に、これが会社を滅ぼすというのがかの本のしてきなわけだけど

どーゆーあんだーすたんど？

623 ：デフォルトの名無しさん：2012/07/06(金) 23:51:03.78

そうですか
ところでそれがC++11と何の関係があるんですか

624 ：デフォルトの名無しさん：2012/07/09(月) 10:30:32.29

話を蒸し返すKY vs 話の流れが読めないアスペ

625 ：デフォルトの名無しさん：2012/07/12(木) 21:19:31.41

non-type template パラメータに、浮動小数点数が加わる日は来るのだろうか。

626 ：デフォルトの名無しさん：2012/07/12(木) 22:17:40.39

そして8087の付いたPCでコンパイルすると意図したように動かないという…

627 ：デフォルトの名無しさん：2012/07/12(木) 22:20:09.62

soft-floatで

628 ：デフォルトの名無しさん：2012/07/18(水) 10:43:34.80

test

629 ：デフォルトの名無しさん：2012/07/18(水) 10:45:55.04

template <size_t n>
void func(const double (&arr)[n]);
に
array<double,100> xs;
を渡す方法ありますか？
単純にfunc(xs.data())してもコンパイル通りません・・・。

630 ：デフォルトの名無しさん：2012/07/18(水) 11:11:07.05

スレ違いですので初心者スレへ。

631 ：デフォルトの名無しさん：2012/07/18(水) 21:58:53.77

array<T,N>::data() は T(&)[N] にしてもよかった気がする

632 ：デフォルトの名無しさん：2012/07/18(水) 22:06:06.73

配列の参照ってそう書くのか

633 ：デフォルトの名無しさん：2012/07/19(木) 00:28:58.90

おいおいw

634 ：デフォルトの名無しさん：2012/07/20(金) 10:10:04.28

　韓国のコミュニティサイト「ポムプ」の掲示板に「日本ビールがおいしくなければならない理由」とのスレッドが立てられたところ、
さまざまな意見が寄せられた。

　スレ主は、日本の食文化について言及し、日本では食に対するこだわりが深い人が多く、製菓技術や製パンは世界に誇れる水準であり、
ビールも同様に世界で認められているものの一つだと述べた。一方、韓国産のビールはまだまだ改善の余地があり、
新規参入による市場の拡大が望まれると指摘した。

　スレッドにはスレ主に対して同意し、日本の食文化について称賛する声が多数並んだ。

・「日本は食文化、特にグルメへのこだわりがすごいと思います。外国の食文化を受け入れ、百年以上の探求を経て、
　トップレベルにした。ビールも同じ」
・「率直にいって、日本の食べ物はおいしいものばかり」
・「日本は、国内市場があまりにも大きい。それに比べ、わが国の内需市場はすかすか」

　また、韓国内のビールメーカーなどを批判する声もみられた。

・「韓国のビール会社のマインドは最悪」
・「韓国ビールは日本でいえば、ビアテイスト飲料」
・「わが国のビールは日本では発泡酒。ビールと呼ばれること自体、恥ずかしくなる粗雑なもの」

　むしろ、北朝鮮のビールの方がおいしいのではといった発言も見られ、韓国人がビールに対して高い関心を寄せている様子がうかがえる。

・「聞いた話だが、北朝鮮のビールの味が韓国産のビールの味よりいいらしい。技術的な問題ではなく、制度や材料が大きな違いをもたらすのでは」
・「わが国のビールがまずい理由は、小規模な醸造所の法的な問題から構造の問題までたくさん。北朝鮮のビールと韓国のビールは、簡単に比較できません」

（編集担当：李信恵・山口幸治）

http://news.searchina.ne.jp/disp.cgi?y=2012&d=0719&f=national_0719_018.shtml

635 ：デフォルトの名無しさん：2012/07/26(木) 12:32:55.89

C++がディスられてる気がするけど気のせい？
http://lambda-the-ultimate.org/node/4554
http://commandcenter.blogspot.jp/2012/06/less-is-exponentially-more.html

636 ：デフォルトの名無しさん：2012/07/26(木) 13:12:51.94

C/C++は永遠に安泰だから気にする必要ない。

637 ：デフォルトの名無しさん：2012/07/26(木) 13:25:20.40

Goの中の人がC++を気にしている理由がわからない。
JavaやC#が対抗馬じゃないのか?
まさか本気でミドルウェア用言語としてのC++を
オーバーライド出来るとは思ってないだろうに。

638 ：デフォルトの名無しさん：2012/07/26(木) 13:33:35.26

C/C++はネイティブ系では既に無敵だから、
このフィールドで勝負仕掛けてくるやつはアホ。

639 ：デフォルトの名無しさん：2012/07/26(木) 13:53:33.08

本家のGoコンパイラは、C/C++とcalling convention違うからな。
奴らの特殊なCコンパイラ使わないとCのライブラリをリンクできない。
そしてC++のコンパイラはない。
だからwebkitとかC++のライブラリをGoにラップしてポートするのは大変。
悪い言語じゃないと思うが、これじゃ普及は厳しいだろう。

640 ：デフォルトの名無しさん：2012/07/26(木) 20:03:06.83

D言語が仕様安定してくれれば
普及に向けて色々動けるんだろうけど・・・

641 ：デフォルトの名無しさん：2012/07/26(木) 20:09:02.01

　インドのガンジス河の畔のヴァラナシ（ベナレス）に、世界の中心を表すという巨大な寺院がある。
そこには青銅のチューリングマシンに（中略）。これが「ブラフマーの塔」である。司祭たちはそこで、
昼夜を通してD言語の仕様を破壊的に変更している。そして、全ての仕様変更が終了したとき、
世界は崩壊し終焉を迎える。

と言われているが、自分も「かつての王にして未来の王」たる最終形態D言語には期待してる。

642 ：デフォルトの名無しさん：2012/07/26(木) 22:12:10.00

Dに期待するくらいならgccgoの方が100倍マシ。

643 ：デフォルトの名無しさん：2012/07/26(木) 22:25:27.61

goはなんかちがわくね

644 ：デフォルトの名無しさん：2012/07/26(木) 22:57:53.81

>>639
とは言え実装他にないわけだし
大差なくね？

645 ：デフォルトの名無しさん：2012/07/26(木) 22:58:16.00

なんというハノイの塔・・・

646 ：デフォルトの名無しさん：2012/07/26(木) 23:35:20.60

>>644
意味がわからん
kwsk

647 ：デフォルトの名無しさん：2012/07/27(金) 09:53:19.40

Dが安定するよりC++1y出る方が早いに100ペリカ。

648 ：デフォルトの名無しさん：2012/07/27(金) 20:17:06.06

>>646
Cとリンクできるコンパイラーしかないんだから、
言語上インターフェースが特殊だろうと関係ないんじゃなかろうか？
厳密にはコンパイラーが一個しか無いわけじゃないけど
同じパッケージで配布されるから実質1ソフトでしょ

649 ：デフォルトの名無しさん：2012/07/27(金) 20:49:59.77

>>648
ABIが違うとgccやclangがコンパイルしたライブラリバイナリはリンクできないってことは理解してる?

650 ：デフォルトの名無しさん：2012/07/27(金) 21:13:44.90

>>649
マングリングやら呼び出し規約やらが関係あるの？

それは置いといてsyscall.LoadLibraryで動的結合する際は
まず関係無いだろうしデフォでCリンケージとリンクはできるじゃん。
C++とリンクしたければgccgo使えばgccと互換性のあるリンクができちゃう。
コールバックが未対応だったけど、それもできるようになったよね。

なんかそれとは別に難しいのかねぇ？

651 ：デフォルトの名無しさん：2012/07/27(金) 21:40:37.12

理解してないなら、書き込まない。

652 ：デフォルトの名無しさん：2012/07/27(金) 21:44:06.87

で気になってる問題はなによ？

653 ：デフォルトの名無しさん：2012/07/27(金) 22:24:37.94

Goなんか誰が使うのかという問題

654 ：デフォルトの名無しさん：2012/07/27(金) 22:26:52.21

スレ違いだな

655 ：デフォルトの名無しさん：2012/07/28(土) 12:42:52.50

Boostスレないの？

656 ：デフォルトの名無しさん：2012/07/28(土) 12:46:59.08

あるよ

657 ：デフォルトの名無しさん：2012/07/28(土) 14:01:14.57

std::function<Base(int)> virtual_constructor( []( int arg )->Base*{ return new Delived( arg ); } );
仮想コンストラクター作ろうと思ったら↑か↓みたいにClassテンプレート自前で作るしか無いの？
std::function<Base(int)> virtual_constructor( Class<Delived(int)>() );
標準で↑のClassテンプレートみたいなのが欲しいんだけど。

658 ：デフォルトの名無しさん：2012/07/28(土) 22:15:55.80

constexpr関数の中に書けてコンパイル時にエラーを出す assert があればいいのに、無いね。

659 ：デフォルトの名無しさん：2012/07/28(土) 22:21:49.51

>>658
ttp://stackoverflow.com/questions/8626055/c11-static-assert-within-constexpr-function

660 ：デフォルトの名無しさん：2012/07/28(土) 22:32:53.34

>>659
その二つの Answer、両方ともコンパイル不可だよ。

661 ：デフォルトの名無しさん：2012/07/28(土) 22:40:54.84

>>660 throwの方は手元のg++4.8.0では通ったが。

662 ：デフォルトの名無しさん：2012/07/28(土) 22:43:16.27

clang3.1でも最後を ....> 0"),0); /* ,0を追加 */で通った。

663 ：デフォルトの名無しさん：2012/07/28(土) 22:56:22.00

662で通った、ｽﾏﾇ。

でも折角 constexpr だからコンパイル時エラーが欲しいのだ。

664 ：デフォルトの名無しさん：2012/08/02(木) 00:22:52.14

pair や tuple で返ってくるのを、
auto (v1,v2,v3) = hoge();
みたいに受け取れないかな。要は多値だけど。

initializer_list じゃなくて、returner_list とか。

665 ：デフォルトの名無しさん：2012/08/02(木) 01:59:49.64

>>664
できるよ。下のほうのパターンをマクロでラップすればだいたい期待通りになるよ。
ttp://ideone.com/U2YN1

666 ：デフォルトの名無しさん：2012/08/02(木) 11:53:13.24

>>665
参照型でくるんで、ナルホド。凄いな。

サンクス

667 ：デフォルトの名無しさん：2012/08/02(木) 12:11:56.47

おまえらperl好きだな

668 ：デフォルトの名無しさん：2012/08/02(木) 12:43:21.77

boost::tieだよね

669 ：デフォルトの名無しさん：2012/08/02(木) 18:19:19.92

C++11にはtieも入ってる

670 ：デフォルトの名無しさん：2012/08/04(土) 20:02:26.50

無限tie

671 ：デフォルトの名無しさん：2012/08/04(土) 20:37:36.04

複数戻り値って便利か？
Pythonとか使ってもエラー処理ぐらいでしかメリットを感じない

672 ：デフォルトの名無しさん：2012/08/04(土) 22:18:50.87

2個戻したい時はいつもstd::pairを使っていた
その延長の感覚だろtupleは

673 ：デフォルトの名無しさん：2012/08/04(土) 22:26:16.00

てことは、pairを返す関数の返り値をtieで受けたりもできる？便利そう。

674 ：デフォルトの名無しさん：2012/08/04(土) 22:49:07.75

>>673
できるよ。

675 ：デフォルトの名無しさん：2012/08/04(土) 23:23:22.95

tupleの有用な例ってどんなのがある？
RGBA(色)とか？

676 ：デフォルトの名無しさん：2012/08/05(日) 00:08:56.39

これだけのために構造体作んのもめんどいしなあ…ってとき

677 ：デフォルトの名無しさん：2012/08/05(日) 00:14:16.62

いや、それは判るんだけど具体例をね。

678 ：デフォルトの名無しさん：2012/08/05(日) 00:40:25.25

equal_rangeの戻り値をiteratorで取得したいとき

679 ：デフォルトの名無しさん：2012/08/05(日) 00:58:53.30

pairで良くね？

680 ：デフォルトの名無しさん：2012/08/05(日) 01:06:50.37

pair<value1, pair<value2, value3> >とかすんの？

681 ：デフォルトの名無しさん：2012/08/05(日) 01:07:21.41

あとから要素増やしてもそのまま動くところじゃね。

682 ：デフォルトの名無しさん：2012/08/05(日) 04:31:09.70

整数割り算とか
正規表現のマッチとか

多値なくてもプログラムはかけるが、(Turing完全！)
あれば便利な局面はいくらでもある。

683 ：デフォルトの名無しさん：2012/08/05(日) 04:32:21.47

C++は衰退しました
Pointer/Zero
僕はドキュメントが少ない

684 ：デフォルトの名無しさん：2012/08/05(日) 04:34:07.29

帰値は常に関数の一番目の引数ということにしておくと
複数の返値も扱える

685 ：デフォルトの名無しさん：2012/08/05(日) 04:38:30.11

tieよりもboost::fusionの方がよくないか？

686 ：デフォルトの名無しさん：2012/08/05(日) 07:04:33.94

関数の第一引数＝返値
という自分ルールを常に守っておくと
継続渡し変換が楽にできる

687 ：デフォルトの名無しさん：2012/08/05(日) 10:07:28.33

>>680
equal_rangeって引数2個で十分じゃね

688 ：デフォルトの名無しさん：2012/08/05(日) 10:08:04.81

○引数
×戻り値

689 ：デフォルトの名無しさん：2012/08/05(日) 10:29:28.39

ベクトルや複素数や行列のように、
まとまった一つの数と見なすものを除けば、
式の評価値が複数になることって、
数学的にも無い概念だから、
あまり複雑に考えないほうが良いよ。

690 ：デフォルトの名無しさん：2012/08/05(日) 11:10:36.18

>>689
> 数学的にも無い概念だから、

もうね

691 ：デフォルトの名無しさん：2012/08/05(日) 11:25:34.81

そんなことはない。
複数解を「組」や「ベクトル」と考えたりはしないよ。

692 ：デフォルトの名無しさん：2012/08/05(日) 11:32:14.14

式の評価値と解は別物。
戻り値は式の評価値。

693 ：デフォルトの名無しさん：2012/08/05(日) 14:00:02.37

Xcode で fusion動かないから
tuple 使ってるのだろうか

694 ：デフォルトの名無しさん：2012/08/05(日) 14:29:56.86

解が解の公式の答えの事言ってるなら
std::vectorでよくね。
x.size() == 0; //解なし
x.size() == 1; //解1個
x.size() == 2; //解2個

695 ：デフォルトの名無しさん：2012/08/05(日) 14:41:07.96

>>694
噛み合ってない。 >>691 は「数学的にも無い概念」に対するコメント。
個別の事例を C++ のどの表現にマッピングするかはプログラマの自由にすればいい話。
std::vector で表現して不都合がないならそれでいいよ。

696 ： ◆QZaw55cn4c ：2012/08/05(日) 15:00:07.77

>>694
定義域のすべてが解、というのもほしいところ。

697 ：デフォルトの名無しさん：2012/08/05(日) 16:53:03.99

template<typename Kai,typename X >
void
kansuu(Kai & kai,X &x)
{}
にすれば解がなんでも対応できるぞ

698 ：デフォルトの名無しさん：2012/08/05(日) 17:55:44.02

レベル落ちすぎ

699 ：デフォルトの名無しさん：2012/08/05(日) 19:32:58.35

>>689
お前は多価関数も知らんのか、対数とか。

700 ：デフォルトの名無しさん：2012/08/05(日) 20:23:45.17

対数て。

701 ： ◆QZaw55cn4c ：2012/08/05(日) 21:05:46.76

>>689
逆三角とか

702 ：デフォルトの名無しさん：2012/08/05(日) 21:49:53.33

>しかし現代的な定義での関数は写像の一種とみなされ、
>一つの入力があるときに出力を一つだけ得るものと定義されることが多く、
>この場合には多価関数を「関数」と呼ぶのは不適切となる
>つまり入力値が元の関数の写像によって移されて出力となるときに、
>入力に関する情報の一部が欠落してしまうために、出力から入力を再現できないのである。
>この場合、多価関数は元の関数の部分関数の逆関数 (partial inverse, en) であると言える。

というわけで、数学的にもイリーガルな扱いだから、
プログラミングでスマートに扱える必要ないよ。
sqrtも正しか返さないし。

703 ：デフォルトの名無しさん：2012/08/05(日) 21:56:13.94

>>702
高校生で数学とおさらばした部類ですね？

704 ：デフォルトの名無しさん：2012/08/05(日) 21:59:42.38

皆が高校進学してると思うなよ！

705 ：デフォルトの名無しさん：2012/08/05(日) 22:03:03.79

汎用プログラミング言語に、大学レベルの数学の表現力を求めてるの？
今現在のC++は、x+1=2;と記述して、xに1が代入されたりしない、
中学レベルの一次方程式すら満足に記述できない状況だってのに。

706 ：デフォルトの名無しさん：2012/08/05(日) 22:06:15.65

数学云々言い出したのは、お前の同志のの 689 なんだがｗ

707 ：デフォルトの名無しさん：2012/08/05(日) 22:07:44.31

まず、x+1=2;でxに1が代入されるようになって、
さらにそれから、x^2=4;の話になって、そこでようやく
多値やら多価関数の話が出てくるって言うのに。
まだ全然そんな段階に到達してないし、
誰もC++にそんな機能を求めてないし。

708 ：デフォルトの名無しさん：2012/08/05(日) 22:16:25.12

>>705
「数学にない概念だから」と語るには数学の知識が相当必要というだけの話。
頭悪いのね。

709 ：デフォルトの名無しさん：2012/08/06(月) 18:48:19.03

数学したけりゃMathematicaとかHaskellでも使ってればよろしい

710 ：デフォルトの名無しさん：2012/08/07(火) 09:05:42.96

夏休みですね。
宿題やっとけよ～。

711 ：デフォルトの名無しさん：2012/08/07(火) 14:47:36.68

#define decltype BOOST_TYPEOF

712 ：デフォルトの名無しさん：2012/08/07(火) 21:42:21.62

ラムダってコピーするときに例外出るとかでないとかどこで判断するんですか？
shared_ptr<ComObj> p(com, [](ComObj * com) { if(com) com->Release(); });
↑こういうのや類似のコードがいくつかあるんですけど、
削除子のコピーで例外がでてしまわないか不安です（削除子のコピーで例外が出るとリークするので）

713 ：デフォルトの名無しさん：2012/08/07(火) 22:02:09.96

ラムダ実行時じゃなくラムダそのもの？

714 ：デフォルトの名無しさん：2012/08/07(火) 22:04:41.26

>>713
そのもののコピー時の話です

715 ：デフォルトの名無しさん：2012/08/08(水) 00:56:13.01

コピーコンストラクタが例外を投げる可能性のあるクラスをコピーキャプチャしてればラムダのコピー時に例外を投げる可能性がある

716 ：デフォルトの名無しさん：2012/08/08(水) 07:37:15.99

20.7.2.2.1 shared_ptr constructors

template<class Y, class D> shared_ptr(Y* p, D d);
8. ...The copy constructor and destructor of D shall not throw exceptions.
　The expression d(p) shall be well formed, shall have well defined behavior,
　and shall not throw exceptions.

なので、例外投げる削除子を shared_ptr に使ってはいけない。

717 ：デフォルトの名無しさん：2012/08/08(水) 07:56:11.73

>>716
だからそれをどう判断するのかって712は聞いてるんだろ

718 ：デフォルトの名無しさん：2012/08/08(水) 07:58:01.89

例外投げるかどうかは noexcept でわかるよ。

// copy ctor が noexcept でないクラス
struct A{ A(){} A(A const&){} };

int main()
{
　　A a;
　　auto lambda1 = [a]{ return; };
　　auto lambda2 = []{ return; };

　　// コピーコンストラクタが例外を投げるか
　　std::printf("%d\n", noexcept(decltype(lambda1)(lambda1)));
　　std::printf("%d\n", noexcept(decltype(lambda2)(lambda2)));
}

誰も　noexcept なんて使わないと思うけど

719 ：デフォルトの名無しさん：2012/08/08(水) 08:31:48.50

>>716-717
削除子の呼び出しが例外を投げるかどうかじゃなくて、 712 が聞いてるのは
削除子のコピーが例外を投げるかどうか、だろ。その規定は関係ないよ。

720 ：デフォルトの名無しさん：2012/08/08(水) 08:36:12.32

>>719
ちゃんと読めよ
> The copy constructor and destructor of D shall not throw exceptions
削除子のコピーも例外投げちゃいけないんだよ。

ラムダがどうこう言う前に規格違反してる糞コードの方を修正しろ

721 ：デフォルトの名無しさん：2012/08/08(水) 08:46:51.10

ここはLispのスレでいいんですか？

722 ：720：2012/08/08(水) 08:56:22.94

あ、すまん。俺が >>712 をきちんと読んでなかった。

ラムダを削除子に使っていいかどうか、
規格適合かどうかを確かめたいって話ね。

noexcept を static_assert するしかないんじゃ

723 ：デフォルトの名無しさん：2012/08/08(水) 09:13:25.72

noexceptの実装なんてなかった

724 ：デフォルトの名無しさん：2012/08/08(水) 09:21:38.42

shared_ptr<ComObj> p(com, [](ComObj * com) { if(com) com->Release(); });

上記例ではラムダは何もキャプチャしていないのだから、
完全に無名関数扱いなので、単に関数ポインタがコピーされるだけ。
関数ポインタのコピーに例外が発生しうるコンパイラーなどありえない。

725 ：デフォルトの名無しさん：2012/08/08(水) 09:42:49.00

じゃあ宗教上の理由でどうしてもデリータのコピー例外を排除できないときはどうしてはるん？

726 ：デフォルトの名無しさん：2012/08/08(水) 10:00:16.54

どうしてもというなら
http://ideone.com/tBvrf
じゃないかと思ったけどコンパイルできない(´；ω；｀)

727 ：デフォルトの名無しさん：2012/08/08(水) 10:13:46.45

[]か[&]ならラムダのコピーやデストラクタで例外は出ません
デリータに[=]系を使っちゃ駄目

それにしてもデリータのコピー例外で例外安全に出来なかったのは何故だろう
デストラクタで例外出すなというのはshared_ptrに限らずC++全般だから当然だけど

728 ：デフォルトの名無しさん：2012/08/08(水) 10:17:31.82

>>725
>じゃあ宗教上の理由でどうしてもデリータのコピー例外を排除できないときはどうしてはるん？
コピーで例外が出るようなインテリジェンスなオブジェクトは、
キャプチャとか以前に、関数の引数とかでも、
参照やポインタなどの間接的な手法で渡す。
だから、そういった類のキャプチャは参照モードでするのが普通。
もしくは、ポインタやスマートポインタをコピーモードでキャプチャしてもよい。
宗教上そういうことが出来ない人は、ラムダのキャプチャ以前に、
関数の引数に、インテリジェンスなオブジェクトを値渡ししているような人なので、
そういう異次元の人と関わりあう必要は無い。

729 ：デフォルトの名無しさん：2012/08/08(水) 10:26:27.37

>>727
それは違う。[&}で自動変数を受けると、スタックを抜けたときに参照元が消えて、
いざデリータが発動した段階で死ぬ可能性がある。
ヒープに有るオブジェクトをさしている自動変数のポインタを渡すような場合は、
逆に[=]でなければならない。
そのほかにも、スマートポインタを渡す場合も[=]でなければ意味を成さない。

730 ：デフォルトの名無しさん：2012/08/08(水) 10:41:28.58

>[&}で自動変数を受けると、スタックを抜けたときに
それただのバグじゃん

731 ：デフォルトの名無しさん：2012/08/08(水) 10:51:27.35

コピー,代入,破棄で例外を投げる可能性がある非PODを
値型でキャプチャしたラムダは削除子に使えない

732 ：デフォルトの名無しさん：2012/08/08(水) 13:49:04.73

boost::mpl
に相当するものって導入されたの？

733 ：デフォルトの名無しさん：2012/08/08(水) 15:37:43.93

>>721
もうちょっと拡張したらLispと等価になるよ

734 ：デフォルトの名無しさん：2012/08/08(水) 22:08:57.35

こんなウンコ言語がLispと等価になるとか夢見過ぎですよ

735 ：デフォルトの名無しさん：2012/08/08(水) 22:17:27.76

Lisp？何それ？

736 ：デフォルトの名無しさん：2012/08/10(金) 14:17:02.36

ハスケルと等価になるのはいつぐらいですか？

737 ：デフォルトの名無しさん：2012/08/10(金) 14:27:37.54

http://stackoverflow.com/questions/8314780/haskell-equivalent-of-boost-fusion

738 ：デフォルトの名無しさん：2012/08/13(月) 20:29:38.11

decltype(*this)
ってできないんだね
子クラスの型情報を親クラスで処理したかったのに

739 ：デフォルトの名無しさん：2012/08/13(月) 20:52:44.60

そら普通に考えて、どんなクラスに継承されようが、
その基底クラスのコードは共通なわけだから。

基底クラスをテンプレートにするしか無いね。

class aaaa : public base< aaaa >{};

740 ：デフォルトの名無しさん：2012/08/14(火) 00:56:00.55

>738
CRTPで処理しろっつうことじゃない？
ttp://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms/%E5%A5%87%E5%A6%99%E3%81%AB%E5%86%8D%E5%B8%B0%E3%81%97%E3%81%9F%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%28Curiously_Recurring_Template_Pattern%29

741 ：デフォルトの名無しさん：2012/08/14(火) 01:07:31.48

>>738
何の制限にひっかかるんだ？

742 ：デフォルトの名無しさん：2012/08/14(火) 01:41:01.41

>741
規格的には呼び出したメンバ関数のクラスになるんじゃない？
>738の望みとは違うだろうけど。

743 ：デフォルトの名無しさん：2012/08/14(火) 03:28:32.74

ごめんよくわかんない。
decltype で動的型情報が取れると思った（けどできない）ってこと？
なら当たり前だろと思ってしまうんだが。

744 ：デフォルトの名無しさん：2012/08/14(火) 03:45:55.20

Base::foo()の中でdecltype(*this)を使ってればそれはBaseになる
Derived::foo()の中で使ってればDerivedになる
ただそれだけじゃないの？

745 ：デフォルトの名無しさん：2012/08/14(火) 05:04:51.40

ちょっと考えれば分かりそうなものだけど、何のクラスが継承しようが、
ベースクラスのコードは共通なのだから、
Base::foo()の中でのdecltype(*this)が変化するわけ無い。
変化させたければ、ベースクラスのコードをを継承するクラスによって変化させる、
つまりベースクラスをテンプレートにして>>739のようにする。

746 ：デフォルトの名無しさん：2012/08/14(火) 11:32:08.89

C++で突っ込んだ使い方しようとするときは、コンパイル時(静的)と実行時(動的)の違いを
意識しないとダメだよな。
autoとかdecltypeはコンパイル時に解決するものだから、動的には型情報を解決できないはず。

747 ：デフォルトの名無しさん：2012/08/14(火) 19:06:57.83

class Base{

template<typename T>
void some(T & dummy){
decltype(*this)
}
};

class Derived : public Base
{};

Derived d;
d.some(d);

748 ：デフォルトの名無しさん：2012/08/15(水) 02:50:27.52

http://stackoverflow.com/questions/8892083/auto-foo-decltypethis-is-there-some-workaround

749 ：デフォルトの名無しさん：2012/08/16(木) 06:16:50.05

for( auto i : { 'r', 'p' } ) {}
もしくは
for( auto i : std::vector<char>( { 'r', 'p' } ) ) {}
こういうのって出来ないんだっけ？

750 ：デフォルトの名無しさん：2012/08/16(木) 08:54:26.14

#include <initializer_list>
int main(){ for(auto i : {'a', 'b', 'c'}) std::printf("%c", i); }

問題ない

751 ：デフォルトの名無しさん：2012/08/16(木) 13:43:23.43

'a'ってintじゃなかったっけ

752 ：デフォルトの名無しさん：2012/08/16(木) 14:07:24.78

int だろうが　char だろうが、
printf に積んだら全部 int になるからどうせ関係ない。

753 ：デフォルトの名無しさん：2012/08/16(木) 14:09:06.72

fgetcの戻り値もintだしな。

754 ：デフォルトの名無しさん：2012/08/16(木) 14:10:19.80

auto v = 'a';
std::cout << sizeof(v) << ":" << typeid(v).name() << std::endl;
>1:c
http://ideone.com/lJae9

755 ：デフォルトの名無しさん：2012/08/16(木) 16:59:07.35

>>751
君は初心者スレに行け。
このスレはまだ早い。

756 ：デフォルトの名無しさん：2012/08/16(木) 21:26:02.82

$ cat sizeof.c
#include <stdio.h>
int main()
{
printf("%d\n", sizeof('a'));
return 0;
}
$ gcc sizeof.c && ./a.out
4
$ g++ sizeof.c && ./a.out
1

面倒な・・・ｗ

757 ：デフォルトの名無しさん：2012/08/16(木) 23:22:01.11

http://www.bohyoh.com/CandCPP/FAQ/FAQ00004.html
C と C++ で違ったのかよ

758 ：はちみつ餃子 ◆8X2XSCHEME ：2012/08/16(木) 23:33:07.95

>>757
C++ と C の間にある非互換の内で最も有名なものだと思う。
cout << 'A';
とかしたときに 65 が表示されたりするのはよくないだろ。
型の扱いを厳密した結果、そうせざるを得なくなったらしい。

759 ：デフォルトの名無しさん：2012/08/16(木) 23:38:25.99

規格について語るようなやつなら基本だな

760 ：デフォルトの名無しさん：2012/08/17(金) 00:37:23.56

初歩過ぎて笑える。
>>756知らん奴はC++プログラマーじゃねーよ。

761 ：デフォルトの名無しさん：2012/08/17(金) 01:29:47.81

横からだけど初めて知ったわー
むしろCの方が何故intにしようと思ったんだろう

762 ：デフォルトの名無しさん：2012/08/17(金) 01:46:03.33

だから初学者はソレ系のスレ行けよ

763 ：756：2012/08/17(金) 02:10:16.25

>>761
うちも初めて知ったクチだけど、
何故intなのか調べてもすぐには判らないね。

算術にするとintに昇格するから最初からintでいいんじゃね？
みたいな発想があったのかな。

char a = 'A';
char shift = 0x20;
cout << a << endl;
cout << a + shift << endl;
cout << (char)(a + shift) << endl;

結果は
A
97
a

764 ：デフォルトの名無しさん：2012/08/17(金) 02:25:43.72

Cの前にBって言語があって、その前にはBCPL
ここまでヒントやったからもう二度とこのスレには来ないでくれ。

765 ：デフォルトの名無しさん：2012/08/17(金) 07:11:32.81

>>763
Cにとってcharやshortは配列の容量を抑えるためのもんで
スカラーでの演算向けに考えて無いからだろ。

CはC++と違い型に文字だの整数だのってことは
あんまり考えてない。目安的に名前が付いてるだけで
実際はメモリー空間の消費量的な意味しかない。

それからint型は実装はともかく仕様上は最速の型だから
特に理由がなければCはなんでもintを使う。

766 ：デフォルトの名無しさん：2012/08/17(金) 08:12:54.21

むしろC++スレでCの話題出すやつが来ないでくれ

767 ：デフォルトの名無しさん：2012/08/17(金) 08:34:30.37

工夫したらCより速くできますか？

768 ：デフォルトの名無しさん：2012/08/17(金) 17:15:07.15

仮想関数やコンテナ、iostream、fstreamを使わなかったら速度的にはCと変わらないだろ

769 ：デフォルトの名無しさん：2012/08/17(金) 17:25:31.18

もはや言語の優劣ではないな

770 ：デフォルトの名無しさん：2012/08/18(土) 08:30:50.10

>>757
C で 'A' が int なのは、知らなかった

771 ：デフォルトの名無しさん：2012/08/18(土) 09:56:25.67

256個以外にEOFが必要

772 ：はちみつ餃子 ◆8X2XSCHEME ：2012/08/18(土) 10:24:38.21

>>771
getc 等の返却値が int であることの理由にはなっても、
文字リテラルが int の理由にはならないのでは？

773 ：デフォルトの名無しさん：2012/08/18(土) 11:44:22.81

ポインタも int で ok だった
ほほえましい時代だしなあ

774 ：はちみつ餃子 ◆8X2XSCHEME ：2012/08/18(土) 12:01:10.99

その逆パターンも。
unsigned が無かった頃は、かわりに void* を使ってたとかいう話もあるもんな。

775 ：デフォルトの名無しさん：2012/08/18(土) 12:21:47.16

charにしたとしても、どうせ演算すればintに昇格されるし、
それでもcharにぶっ込めるしで、無理にcharにする理由が無い
charにする理由が無ければとりあえずintを使うのがC流

C++でcharになったのは、オーバーロードで必要になったからだな

776 ：デフォルトの名無しさん：2012/08/18(土) 12:49:10.84

>>774
unsigned がなくて void があったコンパイラとは？

777 ： ◆QZaw55cn4c ：2012/08/18(土) 12:59:57.05

char *
じゃない。よくexec*()の最後の NULL につけてたやつ

778 ：デフォルトの名無しさん：2012/08/18(土) 13:17:14.45

>>777
だろうな

ポインタにビット演算がなくて、かわりに unsigned のほうがありそうな話だが

779 ：デフォルトの名無しさん：2012/08/18(土) 13:48:03.26

C++11/C++1y、関係ねえよ。Cすらよく知らん雑魚ども失せろ。

780 ：右翼 ◆gXFLM6waxs ：2012/08/27(月) 10:17:31.84

あげ

781 ：左翼 ◆MvRbZL6NeQ ：2012/08/27(月) 12:24:36.41

さげ

782 ：デフォルトの名無しさん：2012/09/05(水) 15:51:42.09

関数の return 文で
コンストラクタ呼び出しの場合は
explicit でも型名を省略できるようにして欲しい。
何か不都合でもあるのかな。

// 現状↓
　struct A { A(int); };
　struct B { explicit B(int); };
　
　A f() { return {1}; }
　B g() { return B{1}; } // return {1}; はダメ

783 ：デフォルトの名無しさん：2012/09/05(水) 16:00:50.22

B b = {1}; が許されないのにそれが出来ちゃ駄目だろう
不都合というか一貫性が無い

784 ：デフォルトの名無しさん：2012/09/05(水) 16:11:25.35

そこをreturn文の文脈では例外的に、ってことで。
別にそこで不具合が起きそうにも思えないし。

785 ：デフォルトの名無しさん：2012/09/05(水) 16:21:04.63

> B b = {1}; が許されないのに

一方で B b{1}; は OK だし、
return には元から = はないので問題ない気がする。

786 ：デフォルトの名無しさん：2012/09/05(水) 16:30:17.05

暗黙の変換を禁止するキーワード付けてるのに
暗黙の変換が出来たらバグだろ・・・
逆にreturnだけわざわざ例外にして何の意味があるんだ？

>=はない
関数の引数でも=はないだろ

787 ：デフォルトの名無しさん：2012/09/05(水) 16:38:30.82

番犬とやりあうつもりはなくて、飼い主と話がしたい。
知りたいのは、これを許すと他の部分にどのように波及するかだ。

788 ：デフォルトの名無しさん：2012/09/05(水) 17:03:14.74

わざわざ例外的な仕様を入れるメリットを示せないようでは話にならないと思うが
この人にでもメールしてみたら？標準化委員会のメンバーだし
ttp://cpplover.blogspot.jp/

789 ：デフォルトの名無しさん：2012/09/05(水) 18:10:45.19

ただの雑談ができない人たちを発見！！

790 ：デフォルトの名無しさん：2012/09/06(木) 04:50:12.53

このヒドいネタ振りで雑談しろと言われても困るというか消えろ。雑談スレでやれ。

791 ：デフォルトの名無しさん：2012/09/06(木) 10:10:14.73

眠れないから罵倒しました、みたいな

792 ：デフォルトの名無しさん：2012/09/06(木) 11:28:22.96

default ctorがexplicitの場合はreturn {};でもOKみたい

793 ：デフォルトの名無しさん：2012/09/06(木) 12:25:55.13

explicitが禁止するのは暗黙の型変換。

よく分からないならこっちへ。
【初心者歓迎】C/C++室 Ver.79【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1341052801/

794 ：デフォルトの名無しさん：2012/09/06(木) 21:23:16.87

>>792
それgccのバグ。

795 ：デフォルトの名無しさん：2012/09/07(金) 14:20:06.77

template <typename T1, typename T2> auto func(T1 && o1, T2 && o2) -> decltype(???) {
auto o3 = o1 * o2;
auto o4 = o1 * o3;
// 実際はもっと長い
return ox; // <- 型がよくわからない
}
このスタイルの関数宣言にローカルな変数を使いたい場合はどうするんですか？

796 ：デフォルトの名無しさん：2012/09/07(金) 14:22:05.74

どうしようもありません

797 ：デフォルトの名無しさん：2012/09/07(金) 14:30:33.76

>>795
ああそういうケースでautoを使うとauto以外では記述不能な場合がある

798 ：デフォルトの名無しさん：2012/09/08(土) 19:48:19.14

http://pbs.twimg.com/media/A2QrrZhCQAADG7l.jpg

靖国神社でこんなもん貰ったんだがwwwwwwww斬新な政治ビラwwww
http://twitter.com/u_n11/status/244368304360275971

799 ：デフォルトの名無しさん：2012/09/09(日) 09:37:35.50

>795
std::declval と decltype でなんとかなるんじゃね？
o4 の型だったらこう decltype(o1 * std::declval<decltype(o1*o2)>())

800 ：デフォルトの名無しさん：2012/09/12(水) 16:00:09.05

90 日間無料で Visual Studio 2012 をお試しください
とかいうメールが来てるんだけど
C++11のほとんどの機能が入ってたりするのかな

801 ：デフォルトの名無しさん：2012/09/12(水) 19:07:50.85

>>800
ほとんど、ではないが2010よりは進化してる

802 ：デフォルトの名無しさん：2012/09/12(水) 20:33:34.48

moveコンストラクタと右辺値参照は使えるようになったみたいね。
それに合わせてSTLも書き直したらしい。

803 ：デフォルトの名無しさん：2012/09/12(水) 20:34:35.47

2010からあることないかそれ

804 ：デフォルトの名無しさん：2012/09/12(水) 20:50:45.53

あーそうかも。

HPで確認したら、

・新しい STL のヘッダーのサポート: <atomic>、<chrono>、<condition_variable>、
　<filesystem>、<future>、<mutex>、<ratio> と <thread>。
・for-range-declaration:expression
・ステートレスラムダ
・スコープの列挙型のサポート

が追加要素みたい。

http://msdn.microsoft.com/ja-jp/library/vstudio/hh409293.aspx

805 ：デフォルトの名無しさん：2012/09/12(水) 20:53:01.95

thread_localはー

806 ：デフォルトの名無しさん：2012/09/12(水) 21:06:35.06

>>804
怖い反復子w

807 ：デフォルトの名無しさん：2012/09/12(水) 22:39:58.32

http://msdn.microsoft.com/en-us/library/hh567368.aspx

こっちのが分かりやすいかな。
Initializer lists = No になってて真っ白な灰に…

808 ：デフォルトの名無しさん：2012/09/13(木) 02:13:28.46

constexprもdefault/delete定義もUnicode文字列もnoexceptもないのか
なんだこの哀れなコンパイラは

809 ：デフォルトの名無しさん：2012/09/13(木) 05:45:46.50

MSやる気なさすぎ

810 ：デフォルトの名無しさん：2012/09/13(木) 08:39:30.33

可変長テンプラないと困るやん

811 ：デフォルトの名無しさん：2012/09/13(木) 12:45:57.92

>>807
Noを赤背景、Yesを緑背景にして
一目で分かるように・・・したくなかったんだろうなMSはｗ

812 ：デフォルトの名無しさん：2012/09/13(木) 14:43:53.41

>>811
それは酷いデザインだな。
コントラストが落ちてテキストが読み難くなる上に色弱の人には判別が付かない。
一方の背景を薄いパステル色にすれば十分だよ。

813 ：デフォルトの名無しさん：2012/09/13(木) 15:03:23.11

VC is far from satisfactory to us

814 ：デフォルトの名無しさん：2012/09/13(木) 15:10:55.37

>>812
その酷いデザイン
http://clang.llvm.org/cxx_status.html

815 ：デフォルトの名無しさん：2012/09/13(木) 20:49:12.27

http://msdn.microsoft.com/ja-jp/library/hh567368.aspx
http://i.msdn.microsoft.com/dynimg/IC604125.png
もともとは表が色わけされた画像だったんだけど画像やめろって言われて今の形になった
他国語版ではまだ画像のまま残ってる
まあ基本的にMSDNではHTMLへの部分的なスタイル変更をしないから画像やめた副作用だな

http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
酷いデザインがよければここで見ることができる

816 ：デフォルトの名無しさん：2012/09/13(木) 23:20:56.28

>>800
こういう90日限定って意味有るんかいな？
昔Expressに試用期間があったけど、
コマンドラインツールは無制限に使えて何がしたいのか解らなかった。

817 ：デフォルトの名無しさん：2012/09/13(木) 23:23:01.19

>>804
HPってMSの宣伝窓口になったのか？堕ちたな・・・

818 ：デフォルトの名無しさん：2012/09/13(木) 23:28:38.64

>>815
全然たりねーなー

819 ：デフォルトの名無しさん：2012/09/13(木) 23:30:40.18

windows版clang++はよう

820 ：デフォルトの名無しさん：2012/09/14(金) 22:43:26.67

>800

　http://msdn.microsoft.com/ja-jp/library/vstudio/bb386063.aspx#BKMK_VCPP
　C++11 言語の標準に準拠するコードを記述する。
　Visual C++ を使用して、範囲ベースの for ループ、標準スレッド、フューチャ、
　アトミック、そして標準 C++11 言語のその他の強力な新機能を使用する
　コードを記述できます。

だって。

>816
今回もVisual Studio Express 2012 for Windows Desktopがあるよ。
http://www.microsoft.com/visualstudio/jpn/products/visual-studio-express-for-windows-desktop#product-express-desktop-details

まだダウンロードできてないから詳細知らんけど。

821 ：デフォルトの名無しさん：2012/09/14(金) 23:00:06.13

昨日からダウンロード出来てるだろ

822 ：デフォルトの名無しさん：2012/09/14(金) 23:05:52.39

>>820が落としてないってことじゃね

823 ：デフォルトの名無しさん：2012/09/14(金) 23:39:50.90

おー、デスクトップ出てたのか。
知らなかった。
早速インストールしてみるか。

824 ：デフォルトの名無しさん：2012/09/15(土) 01:35:54.72

http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
ここのサポートリストはどれぐらいメンテされてるんだろう

825 ：デフォルトの名無しさん：2012/09/15(土) 01:38:56.57

今回のVS Expressから言語別でなくなり、F#も組み込まれたのか。

826 ：デフォルトの名無しさん：2012/09/18(火) 13:35:16.63

boostは終了なんでしょうか？

827 ：デフォルトの名無しさん：2012/09/18(火) 21:23:14.84

C++が終了だから、自動的にそうなるね

828 ：デフォルトの名無しさん：2012/09/18(火) 22:03:17.00

std::arrayの要素数を人間が書かないといけないバグはいつ直りますか

829 ：デフォルトの名無しさん：2012/09/18(火) 22:13:01.81

とっくに直ってる、というか始めからそんなバグはない
時間軸的には array と同期の constexpr が更なる改良となっている

830 ：デフォルトの名無しさん：2012/09/18(火) 22:43:46.65

バグではない仕様だ

831 ：デフォルトの名無しさん：2012/09/19(水) 08:50:00.16

釣れますか？

832 ：デフォルトの名無しさん：2012/09/19(水) 15:10:41.61

C++自体壮大な釣りだからな

833 ：デフォルトの名無しさん：2012/09/19(水) 15:15:49.67

プログラミングこそ一炊の夢よ

834 ：デフォルトの名無しさん：2012/09/20(木) 01:50:55.28

コンパイラが規格においつかないというのが納得できない

835 ：デフォルトの名無しさん：2012/09/20(木) 05:47:59.86

簡単な規格じゃないから開発にかけるリソースが不足してれば追いつかないよ

836 ：デフォルトの名無しさん：2012/09/20(木) 08:07:23.17

>>834
現状追認ばっかりしてるとｇｄｇｄになるんだよ
たとえばコンテナでない自動配列の初期化とか
char* でリテラルを指せるとか
long long くらいならまだ許せるけどね

837 ：デフォルトの名無しさん：2012/09/20(木) 09:34:45.64

>>834
仕様と実装の間には必ずタイムラグがある。
仕様と同時、もしくは前倒しできるのは、単一メーカー押しの言語のみ。
C♯とか。

838 ：デフォルトの名無しさん：2012/09/20(木) 09:42:01.35

つまりcppを捨てcsを使うのが正義

839 ：デフォルトの名無しさん：2012/09/20(木) 11:28:52.11

cpp=Cプリプロセッサ

840 ：デフォルトの名無しさん：2012/09/20(木) 11:59:11.90

TDM gccバイナリが4.7.1にバージョンアップしてた。

これでテンプレートのusingが使える。

841 ：デフォルトの名無しさん：2012/09/20(木) 12:02:02.82

じゃあvc++では使えるんですか？

842 ：デフォルトの名無しさん：2012/09/20(木) 12:06:12.02

VC2012EE

はまだ使っていないからなんとも。
すくなくともgccよりはサポート遅いかも。

843 ：デフォルトの名無しさん：2012/09/20(木) 12:22:17.95

ねーよ
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

844 ：デフォルトの名無しさん：2012/09/20(木) 12:39:29.15

Template Aliases だったw

VC++ではまだサポートしていないんだね。

便利なのに

845 ：デフォルトの名無しさん：2012/09/20(木) 21:51:51.40

仕様に着いて行けてないコンパイラ
そのコンパイラにすら着いて行けてない俺
要するに、俺が一番イケてない

846 ：デフォルトの名無しさん：2012/09/20(木) 22:07:07.43

冷静な奴だな。

847 ：デフォルトの名無しさん：2012/09/21(金) 01:19:32.85

コンパイルタイムにエンディアン調べるメタ関数教えてください！

848 ：デフォルトの名無しさん：2012/09/21(金) 01:29:24.86

メタ関数とは何でしょうか

849 ：デフォルトの名無しさん：2012/09/21(金) 01:31:32.68

コンパイル環境＝実行環境とは限らないから無理じゃね

850 ：デフォルトの名無しさん：2012/09/21(金) 01:37:55.48

__BIG_ENDIANとかそんなマクロが定義されてるだろう

851 ：847：2012/09/21(金) 02:05:27.04

よく考えると無理ですね下であきらめます
http://ideone.com/Ogvzy

852 ：デフォルトの名無しさん：2012/09/21(金) 02:10:51.18

なんで#ifdefじゃあかんのだ…

853 ：デフォルトの名無しさん：2012/09/21(金) 02:13:41.21

プリプロセッサは悪だし

854 ：デフォルトの名無しさん：2012/09/21(金) 06:21:11.17

コンパイル動作を変えるための方法の
一つが#ifdefなのだが、それを
悪とか言って思考停止しちゃったら
ソースコードを複数用意するしかない。

855 ：デフォルトの名無しさん：2012/09/21(金) 07:03:40.61

マクロでできるからいいや、の方が思考停止だろう。

856 ：デフォルトの名無しさん：2012/09/21(金) 07:35:28.97

__BIG_ENDIANが定義されたリトルエンディアン環境が無い事を保証出来ないからマクロ使いは運が悪いと解雇される
残念でしたね

857 ：デフォルトの名無しさん：2012/09/21(金) 08:14:10.79

C++使いのマクロ嫌いは異常
どうせCと決別してC++教に入信するときに洗脳されたんだろうけど
所詮C++なんて邪悪なガラクタの寄せ集めなんだから
「マクロは悪」なんて潔癖になっても意味ないのに

858 ：デフォルトの名無しさん：2012/09/21(金) 08:30:32.35

きもい

859 ：デフォルトの名無しさん：2012/09/21(金) 08:33:47.57

テンプレートはどうみても生成的マクロのなれのはてでしかないことからも彼らの業が深いことがしれよう彼らはマクロは嫌いだから欲しい機能があるとこれはマクロでないということにするのだ

860 ：デフォルトの名無しさん：2012/09/21(金) 09:27:35.30

仕方無いだろ。c++にはクソマクロしかないんだから。
制御されたマクロというだけでもテンプレートの価値は高いだろ。

Lispのマクロ程度の機能がありゃ良いんだけど。

861 ：デフォルトの名無しさん：2012/09/21(金) 09:32:48.01

素人はともかく、企業では
誰もレビューできない
難解なテンプレート書く奴より
きちんとドキュメントに
ソースの適用範囲・使い方を書く奴の方が
重宝される。

862 ：デフォルトの名無しさん：2012/09/21(金) 09:49:35.39

そりゃ、企業じゃtemplateなんか使わないでしょうね。
爆弾抱えるようなものだもの。

863 ：デフォルトの名無しさん：2012/09/21(金) 10:29:33.51

というかポータブルなコードでOSのシステムコールを呼ぶ場合はマクロ使わないと条件分岐出来なくね？
ビルドプロセスで分けるのか？

864 ：デフォルトの名無しさん：2012/09/21(金) 12:50:16.94

http://xmlvm.org/overview/

いっそコードをマクロとしてみたら
旦那、中々本筋に入らない落語みたいになってますがな
そりゃマクラです。お後がよろしいようで

865 ：デフォルトの名無しさん：2012/09/21(金) 12:57:47.22

>>859
ずれてる

いわゆる古典的なマクロは、コンパイラによる厳密な構文チェック(型チェック含む)が出来ないからきらわれているだけ

>>853
そう言う意味で、君もずれてる

866 ：デフォルトの名無しさん：2012/09/21(金) 13:55:03.11

型チェックの方が重要だけど加えて名前空間も無いしね
だからといって全否定なわけない

867 ：デフォルトの名無しさん：2012/09/21(金) 15:33:33.16

まあでもネイティブエンディアン⇔ビッグエンディアン⇔リトルエンディアンの変換関数ぐらい
コンパイラ付属ヘッダー調べつくしたらしれっと紛れてるような気がするけどな
ドキュメントにも載ってないようなささやかなやつ

868 ：デフォルトの名無しさん：2012/09/21(金) 23:55:36.49

#ifdef __cplusplus
を強要するやつが何を言うか

869 ：デフォルトの名無しさん：2012/09/22(土) 09:27:08.70

Cに寄生してるウンコ言語だからね
まあ最近はCに依存せずやって行けると勘違いして
順調にシェアを落としてるけど

870 ：デフォルトの名無しさん：2012/09/22(土) 09:30:35.86

なんでIT技術者って後方互換性を気にするんだろう
適当なサイクルで一新したほうが結果的に効率的だろ
新しい技術への移行や書き換えで雇用もできるし
拡張してばかりだと新陳代謝しない生き物みたいで不健全だよ

871 ：デフォルトの名無しさん：2012/09/22(土) 09:45:31.88

互換性気にしないならいっそC/C++に似た新言語作るし
実際いっぱい作られてるし移行もしてるし健全じゃないですかー

872 ：デフォルトの名無しさん：2012/09/22(土) 09:47:07.53

過去資産が膨大すぎるからなあ

873 ：デフォルトの名無しさん：2012/09/22(土) 09:55:11.18

どうでもいいスレチな話のときだけスレが伸びる

874 ：デフォルトの名無しさん：2012/09/22(土) 09:56:12.98

>>870
あなたにはD言語がおすすめです。

875 ：デフォルトの名無しさん：2012/09/22(土) 10:12:14.63

Deprecated Language ?

876 ：デフォルトの名無しさん：2012/09/22(土) 10:37:18.63

いやいや、互換性の話題はスレチとも言い切れんぞ
c++の規格を更新するときに、かなり考慮する的な言い方を、ストラウさんもしてたような

877 ：デフォルトの名無しさん：2012/09/22(土) 11:35:11.74

>>870
企業のトップが文系か機械いじりだからソフトに金かけるはずがない
適当なサイクルで一新する工数なんて出るわけない

878 ：デフォルトの名無しさん：2012/09/22(土) 13:00:31.20

>870
書き換えはトラブルの元なんだよ。
リファクタリングだって元のソースが動作すること前提だしな。

879 ：デフォルトの名無しさん：2012/09/22(土) 16:30:17.86

今あるコードは今あるコンパイラでコンパイルすればいいんじゃないのか？
新しい規格は別のコンパイラで出せばそれでコンパイルするのは新しく書くコードだろうから互換性無くても問題ないのではないか？

880 ：デフォルトの名無しさん：2012/09/22(土) 16:46:19.39

業界はおろか世界的全産業的に、新しい儲け話がなくトンネルの出口が一向に見えてこない状況で
＞新しい技術への移行や書き換え
なんかにコストを払う余裕はないのでは？

881 ：デフォルトの名無しさん：2012/09/22(土) 16:57:53.09

頭わるそうな議論は他所でやれよ。
ここはC++の新規格のスレ。

882 ：デフォルトの名無しさん：2012/09/22(土) 17:04:37.22

>>879
コンパイラが違うとリンクできないとか良くある話だろ

883 ：デフォルトの名無しさん：2012/09/22(土) 17:08:25.41

>879
さすがに現実知らなすぎだろ……ライブラリは全部捨てろってか？

884 ：デフォルトの名無しさん：2012/09/22(土) 17:15:33.67

>>879
よくねえよ
テスト NG びしばし出るからだいたい

# デビュー前の学生さんでさえ gcc のビルドくらいやってるだろうに
# 当然そこで直面する現実を知らないわけもなし

885 ：デフォルトの名無しさん：2012/09/22(土) 17:16:23.57

>>879
おまえ、、、
その新しいコンパイラで、互換性が全くなくなったら、原因究明から動作検証までどんだけのコストがかかると思ってんだ？
趣味でフリーソフト作ってるヤツばかりじゃないんだぞ

886 ：デフォルトの名無しさん：2012/09/22(土) 17:34:13.02

そろそろ釣り宣言しとけ。 >879

887 ：デフォルトの名無しさん：2012/09/22(土) 17:51:55.45

すぐ近い未来を見た場合は過去の資産を使ったほうがよいだろう
だが長い目で見た場合それは逆に生産性を悪くするよ
マシンにたとえるとわかりやすいかもしれない
今手元にあってすぐ使えるけど性能が悪いマシンを使い続ける
金や購入の手間をかけて性能のいい最新機を買いセッティングもする
どちらの人がより仕事を多くこなせるだろうか
最初のうちは古いマシンを使うほうが多い仕事をするだろう
だがそれは本当に最初のうちだけであっという間に新しいマシンを使う人に追い抜かれそして二度と追いつくことはできない
プログラミング言語にも同じことが言える
今すぐ使えるが使いにくい言語より作る手間や資産の移植の手間はあるがいつか必ず古い物に追いつき追い越せる言語のほうが得なんだよ

888 ：デフォルトの名無しさん：2012/09/22(土) 17:56:05.86

駄文ノーサンキュー

889 ：デフォルトの名無しさん：2012/09/22(土) 18:15:45.27

三行で纏めて。読点付きで。

890 ：デフォルトの名無しさん：2012/09/22(土) 18:20:18.46

ま、実際環境をバージョンアップする事はあるし、
100%過去環境で開発するわけでもないのは確かだな
ただ、それはお金との相談になる

891 ：デフォルトの名無しさん：2012/09/22(土) 18:36:57.34

使えなくなるものを資産とは普通呼ばない。

892 ：デフォルトの名無しさん：2012/09/22(土) 18:54:02.15

環境を残せば使えるお

893 ：デフォルトの名無しさん：2012/09/22(土) 19:07:06.06

だから釣り宣言しとけよ。>887

>今すぐ使えるが使いにくい言語より作る手間や資産の移植の手間はあるが
>いつか必ず古い物に追いつき追い越せる言語のほうが得なんだよ

いくらでもあるだろ、そんな言語。c++である必要はないわな。

894 ：デフォルトの名無しさん：2012/09/23(日) 02:21:24.19

C++11がらみのABIが4.7.0以前に戻ったgcc 4.7.2が出たよー

895 ：デフォルトの名無しさん：2012/09/23(日) 03:05:28.44

>>887
で？
それで客を納得させて金がもらえれば、その提案は通るんじゃね？
ただ、一新にはかなりのリスクを伴うので、一般的には嫌われる

896 ：デフォルトの名無しさん：2012/09/23(日) 09:24:55.43

気球に乗って流されるだけの人生かライト兄弟になろうとする意思があるか
その辺の意識の違いはふだんの仕事にも透けて見えてくるんだろうな
顧客もそういうとこはちゃんと見てるから気をつけたほうが良いよ

897 ：デフォルトの名無しさん：2012/09/23(日) 09:39:02.10

むしろ客の方が気球に乗ったままで、飛行機を恐れて近寄らない。
うちは、.NETに移って、C++ と VB6 を捨てた（一部サポートのみ）が、
同時に、客の何割かも切り捨て始めているわけだ。

898 ：デフォルトの名無しさん：2012/09/23(日) 10:03:06.05

扱いにくいレガシーを資産って言って自分を誤魔化して使い続けて自縄自縛してる人ってなんかいつまでもXPにしがみつく愚者を連想させるよね

899 ：デフォルトの名無しさん：2012/09/23(日) 10:18:26.26

未だにDOS使ってるシステムもあるんだぜ

900 ：デフォルトの名無しさん：2012/09/23(日) 10:27:55.65

で？
大事な事なのでもう一度

選択するのは客であって、提供側ではない

901 ：デフォルトの名無しさん：2012/09/23(日) 10:31:52.92

だからこそだろw
いくらこっちが変えた方がいいと思っても無理なんだよ

902 ：デフォルトの名無しさん：2012/09/23(日) 10:32:52.13

その顧客がじょじょにC++から離れていってるわけだが？
ほんともう過去の資産（もはや借金レベルだが）に縛られて仕方なくいやいやC++使ってるだけで移行できるならさっさとしたいってのがほとんどだろ
麻薬みたいなもんだなやめたいのにやめられないやればやるほどやめられなくなるしメリットはほとんどないほとんど地獄だよ

903 ：デフォルトの名無しさん：2012/09/23(日) 10:34:02.26

>>901
すまん >>900 は >>898 へのレスだ

904 ：デフォルトの名無しさん：2012/09/23(日) 10:37:07.92

>>902
確認しておくが、おまえ >>887 か？
すまん、俺が勘違いレスしたかも

905 ：デフォルトの名無しさん：2012/09/23(日) 10:45:48.13

まだこの話続けてたのかよ。スレ違いだから止めろ。
しかも微妙に話が変わっているし。

c++の互換性が要らないんだったらc++以外を選べばいいだろ。
それ以上でもそれ以下でも無いわ。ぐだぐだ意味のない議論しているなよ。

906 ：デフォルトの名無しさん：2012/09/23(日) 13:14:35.70

派遣社員は仕事がなくてくさくさする気持ちもわかる。

907 ：デフォルトの名無しさん：2012/09/23(日) 18:52:57.53

shared_ptrとかtemplate周りのABIって保証されるのかな？
戻り値、引数やpimpleにshared_ptr使った.soとか不安になる。

908 ：デフォルトの名無しさん：2012/09/23(日) 19:45:09.16

shared_ptrが保証されないとしたら、そりゃデストラクタが動かないってことだろう。
そんなだったらC++全否定に等しいんじゃないかい？ｗ

909 ：デフォルトの名無しさん：2012/09/23(日) 20:31:55.78

「ABI」が通じてないお燗

910 ：デフォルトの名無しさん：2012/09/23(日) 20:50:56.74

やればわかる

911 ：デフォルトの名無しさん：2012/09/24(月) 00:50:46.11

ダイナミックライブラリのI/Fにtemplateとか使うとかいう発想持ったやつ初めてみた

912 ：デフォルトの名無しさん：2012/09/24(月) 00:54:19.50

C++ランタイムもstd::basic_string使ってるだろ

913 ：デフォルトの名無しさん：2012/09/24(月) 00:58:28.88

クラスオブジェクトを
異なるバージョンのコンパイラの結果
に渡せるかと言えば
一般的には不可じゃね？

914 ：デフォルトの名無しさん：2012/09/24(月) 01:16:23.34

>>912
本当に？
聞いたことないんだけど、例えばどれ？

915 ：デフォルトの名無しさん：2012/09/24(月) 02:12:16.30

nm -DC /usr/lib64/libstdc++.so.6
するとこんな感じのシンボルがあるよ。
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::al
長いことインタフェース番号変わってないのはすごいよね。

916 ：デフォルトの名無しさん：2012/09/24(月) 06:19:40.02

win用のランタイムモジュールに互換性があるとしてもそれがABI準拠かは別なんじゃないの

917 ：デフォルトの名無しさん：2012/09/24(月) 09:50:50.77

クラスのDLL ExportがあるからMicrosoftの拡張としてのABIはあるんじゃない？
そうじゃないとMFCは実現出来ない。

918 ：デフォルトの名無しさん：2012/09/24(月) 10:40:56.14

MSVCの場合、DLLは分からんけどStaticライブラリだと
STLの互換性が無くなる組み合わせがあったね。

919 ：デフォルトの名無しさん：2012/09/24(月) 20:01:14.86

C++にクラスオブジェクトなんかあったっけ?

920 ：デフォルトの名無しさん：2012/09/24(月) 20:03:17.75

絶賛スルー中だったのです。

921 ：デフォルトの名無しさん：2012/09/25(火) 22:48:04.68

mailing2012-09
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/#mailing2012-09

922 ：デフォルトの名無しさん：2012/09/26(水) 08:55:40.31

attributeさんに仕事が増えるといいね＞[[deprecated]]

923 ：デフォルトの名無しさん：2012/09/26(水) 19:31:59.22

registerをdeprecatedにしたい

924 ：デフォルトの名無しさん：2012/09/26(水) 21:10:49.80

なってるよ

925 ：デフォルトの名無しさん：2012/09/26(水) 22:21:14.54

いや、autoみたいに再利用しようぜ。

926 ：デフォルトの名無しさん：2012/09/26(水) 22:26:44.88

++1yの1yって何なのさ

927 ：デフォルトの名無しさん：2012/09/26(水) 22:50:04.71

928 ：デフォルトの名無しさん：2012/09/26(水) 22:51:28.96

templateでis_registerとかis_autoってつくれんの？

929 ：デフォルトの名無しさん：2012/09/26(水) 23:57:31.83

最適化の邪魔になるから無視されてるのに今更register復活とはおめでてえな

930 ：デフォルトの名無しさん：2012/09/27(木) 00:16:22.30

忌み子 → 後継候補
volatile → atomic
register → asm

931 ：デフォルトの名無しさん：2012/09/27(木) 00:17:28.10

誰もコンセプトさんに触れてない…

932 ：デフォルトの名無しさん：2012/09/27(木) 00:18:26.15

世の中のOSSが2012に対応するまでは殆どの人は2010のままだと思う

933 ：デフォルトの名無しさん：2012/09/27(木) 00:50:06.43

autoに倣うなら、機械語のレジスタではなく、「登録」の意味で何か用途を探すとか？

934 ：デフォルトの名無しさん：2012/09/27(木) 00:59:59.26

>>928
簡単にできるよ

935 ：デフォルトの名無しさん：2012/09/27(木) 01:24:40.05

予約語から解放するだけでいいんじゃね

936 ：デフォルトの名無しさん：2012/09/27(木) 01:25:38.33

>>934
うん、やって

937 ：デフォルトの名無しさん：2012/09/28(金) 01:00:37.13

https://github.com/niitsuma/scm2cpp.hpp/blob/master/scm2cpp.hpp
C++のstd::vectorなどをlispぽく操作する関数コレクション

car(std::vector)=v[0]
みたいな感じ
具体的な使用例は
https://github.com/niitsuma/scm2cpp.hpp/blob/master/usage.cpp
を参照

eq? が単純なアドレス比較
&x == &y
として実装されてる
なので
cons(double, std::list)
がboost::ptr_listになるようになっている

他に
std::vector std::list
boost::fusion::listなどが使える

std::pairもconsとして扱える

938 ：デフォルトの名無しさん：2012/09/29(土) 22:54:04.56

bootsは今後どうなっちゃうんでしょうか。
deprecated？

939 ：デフォルトの名無しさん：2012/09/29(土) 22:57:46.32

聞いたことないなそれは

940 ：デフォルトの名無しさん：2012/09/29(土) 23:09:24.50

i need your clothes, your boots, and your motorcycle.

941 ：デフォルトの名無しさん：2012/09/29(土) 23:12:27.41

boostと共存するのか。
めんどうを増やしているとしか思えん。

942 ：デフォルトの名無しさん：2012/09/29(土) 23:17:28.08

シラネ

でもboostの開発者にはC++標準化委員会の人が多くいるから文句も言えない

943 ：デフォルトの名無しさん：2012/09/29(土) 23:19:04.62

C++を終わらせる最強の言語を開発すればおｋ

944 ：デフォルトの名無しさん：2012/09/29(土) 23:23:53.56

当分は無理じゃね

C++は最強言語と言われたCの虎の威を借りてるからな
それを超えるとなると相当難しいぞ

945 ：デフォルトの名無しさん：2012/09/29(土) 23:25:54.73

そこでDですよ

946 ：デフォルトの名無しさん：2012/09/29(土) 23:26:31.97

　　　　/＼＿＿_／ヽ
　　／／~ 　　 ~＼:::::＼
　 . |　（･）　　　（･）　 .:|
　　|　　 ,,ﾉ(､_, )ヽ､,,　.::::| 　　　は？
. 　 |　　｀-=ﾆ=- '　.:::::::|　　　
　　＼　　｀ﾆﾆ´　 .:::::／
　　　／｀ー‐--‐‐―´＼

947 ：デフォルトの名無しさん：2012/09/30(日) 00:58:15.25

C++信者の多くはDの進化に恐れをなしているらしいよ

948 ：デフォルトの名無しさん：2012/09/30(日) 01:02:39.17

C++の標準ライブラリは.NetとかCocoaに比べるとサービス悪い。

949 ：デフォルトの名無しさん：2012/09/30(日) 01:47:31.03

D信者がなぜC++11スレに出張してきてんの？
M$がD言語を.NETでもいいから採用したら考えないでもないけど無視されてるじゃん

950 ：デフォルトの名無しさん：2012/09/30(日) 02:07:34.72

>>927
そんなんするなら、こんな感じの方が性能いいと思うぞ
typedef std::complex< float, std::complex<float, std::complex< float, float > > > Quaternion;
Quaternion quaternion;

951 ：デフォルトの名無しさん：2012/09/30(日) 07:41:38.78

>>949
OSSだからな

952 ：デフォルトの名無しさん：2012/09/30(日) 14:21:26.92

TR1の時もboostはこれからどうなるのか？
って頓珍漢なこと言ってる人いたな。
参照実装になったり、規格外のことやってくだけ。

953 ：デフォルトの名無しさん：2012/10/02(火) 03:08:49.50

boost→C++11 の移行って中途半端なんだよな。
基本 boost なしで C++11 だけで完結してもらいたいのだが、そういうふうになっていない。
Cocoaと.Netに慣れてる身からすると、サービス悪いとおもってまう。
だからといってC++から離れることもできず。

954 ：デフォルトの名無しさん：2012/10/02(火) 05:00:31.48

標準ライブラリがboost並の頻度で仕様変更とかD言語みたいなことになったらいやだ

955 ：デフォルトの名無しさん：2012/10/02(火) 11:07:50.82

英語読めない奴はboostについて行けないし、
置いてきぼりにされた気持ちになるのだろう。

956 ：デフォルトの名無しさん：2012/10/02(火) 11:09:46.38

>>953
boost内で特に優秀な成績を収めた者がstdに昇格します
移行ではありません

957 ：デフォルトの名無しさん：2012/10/02(火) 12:43:13.05

ゆーしゅーな成績って基準は何よ？
C++でゴリゴリ書きたい人（＝車輪の再発明をしたい人）のげばひょうかい？

958 ：デフォルトの名無しさん：2012/10/02(火) 13:08:51.86

はい

959 ：デフォルトの名無しさん：2012/10/02(火) 13:27:52.64

std::progress_display

960 ：デフォルトの名無しさん：2012/10/02(火) 16:16:31.80

新鮮味も斬新さもなくboostの空気に合わないと判断されたものがstdに降格されるんだろ

stdに行ったら夢も希望もない墓場だ

961 ：デフォルトの名無しさん：2012/10/02(火) 16:19:20.97

別にstdに行ったからってboostからなくなるわけじゃないんだが…

962 ：デフォルトの名無しさん：2012/10/02(火) 16:41:02.01

丸ごとぱくってるわけでもなく微妙に違うし

963 ：デフォルトの名無しさん：2012/10/02(火) 20:26:24.95

std行きは降格じゃ無くて昇格だろ常識的に考えて

964 ：デフォルトの名無しさん：2012/10/02(火) 20:37:33.56

boost::shared_ptrからstd::shared_ptrに変換するベストアンサーは？
古いライブラリがboost::shared_ptr形式でオブジェクトを生成するが古いソースには触りたくない
新しいプロジェクトではstd::shared_ptr形式でそのオブジェクトを使いたい

965 ：デフォルトの名無しさん：2012/10/02(火) 21:18:11.33

変換しない

966 ：デフォルトの名無しさん：2012/10/02(火) 21:21:32.38

そこをなんとか。どうしてもしないとだめなんです
文系の上司がそうしないとお前を解雇するって・・・・・・

967 ：デフォルトの名無しさん：2012/10/02(火) 21:21:43.78

>>964
http://d.hatena.ne.jp/yohhoy/20120921/p1

968 ：デフォルトの名無しさん：2012/10/03(水) 01:04:37.25

>>967
なにこの劣化weak_ptr。
既存のboost::shared_ptrが生存している限り、
「変換」されたstd::shared_ptrが使えるというだけじゃん。
逆もしかり。
「変換」されたshared_ptrは、shared_ptrとしての機能を果たさないので、
生ポインタ使うのと変わらん。

969 ：デフォルトの名無しさん：2012/10/03(水) 01:07:48.89

>>968
よく読んで考えろ

970 ：デフォルトの名無しさん：2012/10/03(水) 01:11:44.82

>>969
ああ、コピーキャプチャか。
なるほど。

971 ：デフォルトの名無しさん：2012/10/03(水) 06:19:16.48

>>968
ﾌﾟｷﾞｬｰ

972 ：デフォルトの名無しさん：2012/10/04(木) 08:47:50.94

これコスパ最悪だな＾＾；
頻繁に相互変換起こると爆死じゃんｗｗｗ
やはりライブラリでshared_ptrを返すやつは信頼できない
生ポインタを返すべきだったんだ

973 ：デフォルトの名無しさん：2012/10/04(木) 08:56:58.44

お前の設計が糞

974 ：デフォルトの名無しさん：2012/10/04(木) 09:04:31.02

今までまともなライブラリでshared_ptr返すやつなんて見たことないわ
C++11になって標準化したからこれからは当たり前になってくるだろうけどな

975 ：デフォルトの名無しさん：2012/10/04(木) 14:42:45.72

ラムダってC#みたいにテンポラリ変数のキャプチャとか引数の型省略とかできないの？
なんかちょっと不便じゃね？[weak_ptr<T>(spObj)]() {}みたいに書きたいときあるよね？
いちいち新しい変数作るの？あとくそ長い型名を引数にとるラムダとか見苦しいじゃん
こんな汚いなら外に関数として普通に書くわってなるじゃん
そこを楽して省略したいのにできないとか泣ける

976 ：デフォルトの名無しさん：2012/10/04(木) 15:02:31.63

weak_ptr<T>(spObj)これにラムダ内からどうやってアクセスすんの？

977 ：デフォルトの名無しさん：2012/10/04(木) 15:11:51.94

observee.add_observer([w](A a) {
auto s(w.lock()); if(s) { s->notify(a); }
});

978 ：デフォルトの名無しさん：2012/10/04(木) 18:53:04.13

そもそもポインタがshared_ptrになったからって何が安全になるのか
当然ながらXSSやSQLインジェクションみたいなありがちな脆弱性には全くの無力だし
メモリ絡みにしたってバッファオーバーランやNULLのデリファレンスみたいなのは防げないでしょ

「deleteし忘れ」を防ぐためだけに、本当に支払う価値のあるオーバーヘッドなのかね
プログラマが気をつけるべき問題じゃないの
逆にオーバーヘッドが気にならないリッチな環境ならそれこそGC言語使えよっていう話じゃ

979 ：デフォルトの名無しさん：2012/10/04(木) 19:01:08.12

XSSやSQLインジェクションやバッファオーバーランやNULLのデリファレンスだってプログラマが気を付けるべき問題だろ

980 ：デフォルトの名無しさん：2012/10/04(木) 19:03:00.95

>>978
長文かつ駄文。普段どんなコード書いてる人なのか…

981 ：デフォルトの名無しさん：2012/10/04(木) 19:48:58.67

>>978
そんな万能なセキュリティが言語に備わってたら、いったいどんなコードを書くんだ。

982 ：デフォルトの名無しさん：2012/10/04(木) 20:08:44.16

バッファオーバーランは単に動的配列があればいいし、
NULLのデリファレンスも、not null修飾がある言語もある。

結局Cの拡張なんだからスタート地点がボロボロなのは仕方ないだろ

983 ：デフォルトの名無しさん：2012/10/04(木) 20:13:01.20

バッファオーバーランと動的配列がどう関係するのだろう…

984 ：デフォルトの名無しさん：2012/10/04(木) 20:25:18.53

http://toro.2ch.net/test/read.cgi/tech/1345823164/762 さんじゃね？

985 ：デフォルトの名無しさん：2012/10/04(木) 20:43:00.23

スタティック領域とスタックとヒープが別物ってC以前にPC知識の基礎じゃん。

986 ：デフォルトの名無しさん：2012/10/04(木) 20:59:48.59

>>983
バッファオーバーランは要は固定領域に可変サイズデータを入れるから起きるんだろ？
可変サイズデータは最初っから可変で取る慣習さえできていればそもそも起こりえない。

で、Cでそういう慣習が無いのを引きずってるわけで。
わかってる人はC++なら全部vector使ってたろ？

987 ：デフォルトの名無しさん：2012/10/04(木) 21:13:50.74

バッファサイズ追加指定で済ますのと、
動的バッファに変更するのとじゃ……

988 ：デフォルトの名無しさん：2012/10/04(木) 21:14:28.67

for文やwhile文のループ条件にサイズ指定が有るかどうかで、静的や動的は関係ない気が。

989 ：デフォルトの名無しさん：2012/10/04(木) 21:50:34.73

>>986
動的とか固定とかは本質的な問題じゃない
あるバッファへの書き込みデータ数に対して、サイズ制限できるかどうかが全て

990 ：デフォルトの名無しさん：2012/10/04(木) 21:55:44.51

なんかバッファオーバーランの定義がちがくないか

991 ：デフォルトの名無しさん：2012/10/04(木) 22:04:41.03

>>989
既存領域にデータを書き込むという発想の時点で、Cの呪縛がかかってるだろ
その都度必要な領域を取るんだよ

992 ：デフォルトの名無しさん：2012/10/04(木) 22:11:01.12

vectorを使っても、new文が別の文法で書けるというだけで、
アクセスするたびに領域確保という美味い事にはならない気が。

993 ：デフォルトの名無しさん：2012/10/04(木) 22:13:09.79

>>991
純粋関数家の方ですね?

994 ：デフォルトの名無しさん：2012/10/04(木) 22:13:53.62

http://toro.2ch.net/test/read.cgi/tech/1349356417/
次スレ

995 ：デフォルトの名無しさん：2012/10/04(木) 22:16:04.83

バッファーオーバーランとは
「有限のサイズを持つ領域に
何のチェックも行わず無制限に
データ書き込みを許したら
溢れて壊れちゃった」ってだけ。

vectorは馬鹿でに使わせても多少安全なように
・長さ情報を持つことを強要した
・一部のアクセスはサイズチェックを自動的にする
という点がマシになったが、
バカには結局何を使わせても無駄。

996 ：デフォルトの名無しさん：2012/10/04(木) 22:17:03.68

でも賢い人はPGなんかにならないからPGには馬鹿しかいないはずだよね？それでいいのかこの業界

997 ：デフォルトの名無しさん：2012/10/04(木) 22:21:03.87

有能なコンピューター馬鹿居るし

998 ：デフォルトの名無しさん：2012/10/04(木) 22:25:46.15

未だにC++なんてやってる奴は賢い奴だけだろ。

999 ：デフォルトの名無しさん：2012/10/04(木) 22:25:59.44

>>995
> 「有限のサイズを持つ領域に

まるで無限のサイズを持つ領域があるかのような書き方だな。

1000 ：デフォルトの名無しさん：2012/10/04(木) 22:27:55.19

少々賢いだけでは生きにくくなっただけ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。