C++11/C++0x 14

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

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

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

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
C++0x 8
http://pc12.2ch.net/test/read.cgi/tech/1262874195/
C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/
C++0x 10
http://hibari.2ch.net/test/read.cgi/tech/1275375522/
C++0x 11
http://hibari.2ch.net/test/read.cgi/tech/1285884294/
C++0x 12
http://hibari.2ch.net/test/read.cgi/tech/1298470844/
親戚スレ
C1x
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

これ乙インテール

　　　　　　　　　　　　　　　　　　　　　　　　　 刀、　　　　　　　　 　 , ヘ
　　　　　　　　　　　　　　　　　　／´￣｀ヽ ／: : : ＼＿＿＿＿＿／: : : : ヽ、
　　　　　　　　　　　　　　,.　-‐┴─‐- ＜＾ヽ、: : : : : : : : : : : : : : : : : : : : : : }
　　　　　　 　 　 　 　 ／: : : : : : : : : : : : : :｀.ヽl____: : : : : : : : : : : : : : : : : : ／
　　　　　,.　-──「｀: : : : : : : : :　:ヽ: : : : : : : : :＼ ｀ヽ￣￣￣ フ: : : : :／
　　 　／: :.,.-ｧ: : : |: : : : : : : : :　　　 :＼: : : : :: : : :ヽ　 ＼ 　 ／: : : :／
　　　￣￣／: : : : ヽ: : : . . . . . . . . . . .､ ＼=--: : : :.i　 ／　/: : : : :/
　　　　 ／: : 　　　 ∧: ＼: : : : : : : : : : ヽ: :＼: : : 〃}/　　/: : : : :/　　　　　　　　 、
.　　　 /: : /　　. : : :! ヽ: : l＼_＼／: : : : :＼: ヽ彡: : |　　/: : : : :/　　　 　 　 　 　 |＼
　　　/: : ｨ: : : : :.i: : | 　 ＼!___／ ヽ:: : : : : : :＼|:.:.:.:/:!　 ,': : : : /　 　 　 　 　 　 　 |: : ＼
　　 / ／ !: : : : :.ト‐|-　 　 ヽ　　　　＼: : : : : l::::__:' :/　 i: : : : :{　　　 　 　 　 　 　 |: : : :.ヽ
　　 l/ 　 |: : :!: : .ｌ: :|　　　　　　　 　 　 ＼: : : l´r. Y　　 {: : : : :丶＿＿＿＿＿__.ノ: : : : : :}
　　　　　 l: : :ｌ: : :ﾄ､|　　　　 　 　 ､＿__,ィ ヽ: :| ゝ ﾉ　 　 '.: : : : : : : : : : : : : : : : : : : : : : ／
　　　　　 |: : :ﾄ､: |: :ヽ ___,彡 　 　 ´￣´　　 ヽl-‐'　　　　 ＼: : : : : : : : : : : : : : : : : : イ
　 　 　 　 !: :从ヽ!ヽ.ﾊ=≠'　, /////　///u /　　　　　　　 　 ￣￣￣￣￣￣￣￣
　　　　　　V　 ヽ|　 　 }///　 r‐'⌒ヽ　　イ〉、
　　　　　　　　　　　 　 ヽ､______ｰ‐‐' ィ´　/:/:7rt‐---､　　　　　　　こ、これは>>1乙じゃなくて
　　　　　　　　　　　　　　　　　　ィ幵ﾉ　./:/:./:.! !: : : : :!｀ヽ　　　　　ポニーテールなんだから
　　　　　　　　　　　　　　r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :＼　　　変な勘違いしないでよね！
　　　　　　　　　　 　 　 /: : .|: :|　!:.!ィ¨¨ヾ、:.:/　!: : : : l: : : : : :.＼

まだ、立てるの？


ふぁー

日本語でおｋ

　　　　　　,　'´ / r‐ ､｀丶､＿
　 　 　 ／　　 i　 !　　＼ ノへ｀ ミ く￣_｀_ヽ＿__
　　　 /　　　　|　　 ,　 '´　　　　￣｀丶>‐ﾍ ／　|
　 　 ｛　　　　｜ ／　　　　 /　　/V1　 　 〈　　 l
　　　 ヽ、　　　)′ / //　/　/　'　｀l　ｌ　　 ｀､　ﾊ
　　　　 ﾉ　　 // ／ｨ 〃_'_|_/　/　　l　| ｝　　 Ｖ　|
　　　／　　　{Ti ｌ　 | i´/　ﾚ l｀{　　 '_〉Ｖ　|　　ﾄ､ﾉ
　　'´　 　 　 ｀いl　 | {y7汽くヽ!　 // ｀ﾝ ﾘ_ / ! |
　{　　　　　　／(ﾍ、ｌﾊ{ｉ::.::ﾘ 　 　 r芯Y /r　｀ヽ/ヽ
　 ､　　　　 〃　 ｀ｏ､　｀,,'′　 , 〈::.:;ﾉｼ＾Zｧ-r } 　 |
　　丶、　　{i　　 　 ,ﾍ、　 /＾ヽ　 ｀゛/ ,二/　｜　 ′
　 （ ｰ‐'　　　　_彡 _/_丶、 ‐'　 . ィ／ 　 r）　l　 /
　　 ｀￣{　ﾊ （ 　 /::.::.:: ;ﾆヽ､´{　　l 　 rく´　 |／
　　　 　 ヽ､｀ｰ　厶イ :/　　∨ 〉ヽ」＿｣__::＼ﾊ 　　　　>>1乙にゃん
　　　　　　　　　/）: : / 　 　 /ﾍ: /::.::.::.::.::|::.::.:/
　　　　　　　　　!': : 八丶、, ' : : ｀ヽ､:_:_:_:jＬノ

結局今残ってる学園の皆さんは？

一度目は面白くてもネチネチ繰り返酢とキモチ悪いだけだ
忘れろてか絶対書くな

はやくVC++で可変長天ぷらつかいたいよう
スクリプトで似たようなオーバーロードたくさん生成する作業はもういやだお

GCCでもこの有様なのに

main.cpp:9:40: 残念ですが未実装です: cannot expand ‘ns ...’ into a fixed-length argument list

エクセルでたくさん生成すればいいだろ
結構楽々だぜ？

PHPを使えばいいと思うよ^^
ttp://www.kijineko.co.jp/lab/20100425-1

Win32 APIの動的ロードをするときにdecltypeが死ぬほど便利と知った

今頃知ったが
decltypeって関数の戻り値の型も取り出せるのか
オラワクだな

>>11
4.3から実装されてる。コード晒して。

>>14
なぜ便利なのですか？

>>16
#include <iostream>

template <int n, int... ns>
struct sum {
static const int value = n + sum<ns...>::value;
};

template <int n>
struct sum<n> {
static const int value = n;
};

int main()
{
std::cout << sum<1, 2, 3>::value << std::endl;
}

もしかして、こういう風には使えないのか？

>>17
ヘルプを見なくても戻り値をなんとか受け取れます

ヘルプを見なくてもその戻り値が使えるのん？

学園はもう飽きたなら、今度はバーあたりどうかな

禿：　マスター　（いらっしゃいませ、ただいまメニューはこちらになっております
コンパウンドリテラルさん：　いつも２人分の席にいらっしゃる貫禄
ホステス auto ：　双子の妹？　姉妹仲が修復不能状態
ホスト concept：　フェラーリでご出勤の稼ぎ頭・・・のはずだったが、入院または服役の噂。ゆっくり充電してね。
ホステス auto_ptr：　同伴が伸び悩み、若い子の面接でしょっぱい思いをしている低級管理職。
右辺値参照さん：　裏家業、別れさせ屋。カウンターではおとなしい。
ラッパー：　その名のとおり一気のみして現在昏睡状態、禿の一言に深く傷ついた模様。
マルチスレッド先生：　新機軸だった持論が実は７０年代とわかりストレス処理中。まわりが潤ういい荒れ方。

template(だけ)でコンパイル時計算ってのがすでに過去の遺物となりつつあるけどな。

constexpr int sumfunc(int v)
{
return v;
}

template<class... Args>
constexpr int sumfunc(int v, Args... args)
{
return v + sumfunc(args...);
}

template <int n, int... ns>
struct sum { static const int value = sumfunc(n, ns...); };

int main()
{
std::cout << sum<1, 2, 3>::value << std::endl;
int x[sum<4, 5>::value] = { 1 };
for(auto v: x) { std::cout << v << ", "; }
std::cout << std::endl;
}

template にtagとか入れちゃうのよく見るけどな

constexprならいけるのか
そこら辺仕様なんだろうか？

>>22
すげえ
gcc4.6.1(MinGW)でコンパイルして走ってしまった
しかしEclipse CDTが対応してないらしくまだエラーだらけの画面

実行結果
6
1, 0, 0, 0, 0, 0, 0, 0, 0,

constexpr使うなら最初からsumfunc直接使えば良いな
sum::value要らない

FDISの内容＝規格でいいんだよな？

規格定まったし、VC11がどのくらい準拠してくれるかねぇ
10と同じだったら嫌だ

>>16
今のところgccではテンプレート引数パックを固定長テンプレート引数リストに渡すのは実装されてない。

// gcc-4.6.1ではコンパイルエラー(未実装の機能)
template<int n>
struct Hoge {};

template<int... n>
struct Fuga { Hoge<n...> hoge; };

template<class T>
struct Toge {};

template<class... T>
struct Tuga { Toge<T...> toge; };

int main()
{
Fuga<1> fuga; //エラー
Tuga<int> tuga; //エラー
}

>>24
>>22で使ってるのは関数呼び出しからのテンプレート実引数推論であって上記とは別の機能。

>>28
ほぼ同じ

ふぁー、こいつらときたらｗ

風と共に去りぬ



じゃなかった。。。



禿と共に去りぬ。ナンマイダ―ｗ

時々現れる昭和臭がキツイおっさんはなんなの

gcc とllvmが実装してくれさえすればVSも後から実装してくれるんじゃないだろうか

clangのlambdaとvcの可変長テンプレートどっちが早いかな

C++11フル実装はclangが一番早いと思われる。
開発者がIndiana版conceptの中の人だから。

clangってlambda実装する気あんのかねぇ

とりあえず自分が使うのは
VS gcc 両方で使える機能だけ

>>37
基本的にマージされる方向。cfe-devにもよく登場する人。
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gigabytes/1

v3以降 脱GPLの流れが加速してるな
不自由を強いられるようなもんだからこうなるのも当然ではあるけど

lambdaのおかげでSmalltalkみたいな楽しいことができるようになったな。
Javaよりよっぽどオブジェクト指向言語らしく見える。

//オブジェクトによる分岐
( a == b )
            ( [](){ puts("Is True"); } )
            ( [](){ puts("Is False"); } );

//オブジェクトによる反復
for_each( seq( 0, 9 ) )
            ( [](int i){ printf("0-9 count: %d", i); } );

//メンドイんで省略して反復
for_seq( 0, 9 )
            ( [](int i){ printf("0-9 count: %d", i); } );

また変態言語とか言われるからその辺で

果たして使い道があるか。

//オブジェクトによる分岐
auto boolean =  a == b;

boolean
    ( [](){ puts("Is True"); } )
    ( [](){ puts("Is False"); } );

//オブジェクトによる反復
for_each loop( seq( 0, 9 ) );

loop
    ( [](int i){ printf("0-9 count: %d", i); } );

今考えるとブロックをサポートせずbool型をオブジェクトにしなかったJavaってアホだな

gccのsequenceのサポートはバージョンいつからだろう
今の所ステータスNoになってるな

あほはお前

>>42
いまどきlambdaくらい他言語の人の方が理解あるだろ

C++って基本的にネイティブコードを想像しながら書くのに使ってたんだが
こんなに仕様が大きくなったら追いつかないわ・・・

どうせboost使って楽しようとし始めた時点でわけわからなくなる

ネイティブコードから見れば逆にあまり変わってないような
的外れかもしれないが強いて挙げるならスレッドが仕様に含まれたのが大きいか

>>47
確かに
関数オブジェクトをわざわざ別のクラスで定義しなければいけなかった
今までが異常だったとも言える

c++11の新要素のうち、どの辺がネイティブコード想像できない？

拡張for文だな
どこまで最適化してくれるもんなのやら

規格に疑似コード書いてくれてんじゃん

あんな擬似コードを馬鹿正直に実装するわけないじゃん
コードサイズがひどいことになる

期待する最適化の結果は同じだろ

最適化をイメージすりゃ良いじゃん

憶測の応酬

>>53
拡張じゃないforと何か変わりますか?

正直JavaScriptの方が変態言語だと思うし、C++なんて平凡な言語だと思うわ

スレッド関連をまとめたサイトってないのでしょうか

std::packaged_task
ってグローバル変数もパックしてくれるの？

スレッドの中でグローバル変数参照しててグローバル変数を別スレッドで変更したらどうなるの？

>>61
mutexなりでガードするかatomic変数として宣言するかしないと、
data raceで未定義動作となる。

c++11のスレッドに

関数の再帰呼び出しでスタック積んでいって
途中で別スレッドに処理が移ったら
スタックの情報も別スレッドに移動してくれるとか

そんな便利機能を期待してたのだけど
全部指定しないとダメってことなのかな

>>63
領域としてのスタックを指してるならそんな動作は100%害悪にしかならない
便利機能とか思ってるなら今日はもう顔洗って寝ろ

>>63
> 途中で別スレッドに処理が移ったら

スレッドが「処理」の主体なのに「移る」の？

c++11のスレッドでschemeの継続を作ろうとしてるブログ見たものだから
ひょっとそんな便利機能あるのかと期待してしまった

この辺りの話かね。
http://en.wikipedia.org/wiki/Tail_call#Through_trampolining

http://d.hatena.ne.jp/jonigata/20091003
これとかです

継続
http://ja.wikipedia.org/wiki/%E7%B6%99%E7%B6%9A

マイクロスレッドあればいいのになあ

>>61
その前にスレッド間で広域変数なんて使うなよ。
グローバル変数が許されるのはI/O関係か割り込みかかメモリー関係ぐらい。
シグナルですらグローバル変数を回避できるのに。

public static Hoge hoge = new Hoge();

C#ではマルチスレッドでhogeに同時にアクセスしても、hogeの初期化は排他制御されるが
C++11で同様の事やる場合はどうなってるの?

>>71
volatileとか知らない人?

設計の話だろ

>>71
非同期 I/O も割り込みもスレッドなのをご存知ない？
そもそも「許される例」があるのに、そこまで感情的になるのは間違ってるって思わないのか

いや、グローバル変数なんかそうそう使うもんじゃないってのは
一般的な話だと思うが

グローバルな存在があるのも一般的な話だろ
解こうとする問題と構造の一致しないモデルをなぜ強要するんだ

>>73
volatileになんの関係が？

>>75
構文上許されたからどうした。
スレッドには引数で渡すだろ。

仕様上どうなるのって話にスタイル上やるなって話で返す奴はどこにでもいるな。
自分のわからない話からわかる話にしようとしてるだけだから無視するが宜しい。

既に排他しないと壊れるっつう話は出てるし

JavaとかのvolatileとC++のvolatileの区別がつかないヤツがまだいるのか・・・

実は、マルチスレッドでvolatileはタブーなんだけどな。

>volatile: a multithreaded programmer's worst enemy.
ttp://thread.gmane.org/gmane.comp.lib.boost.devel/221929/focus=222849
VCの制作スタッフも語ってる

フラグには問題ないだろ

なにが？グローバル変数？

C++使っててフラグってのもどうよ。
ましてやC++11のスレで発言できるネタじゃなくね。

std::atomicでおｋ

実は、マルチスレッドでvolatileはタブーなんだけどな。(ｷﾘｯ

uyさんがログインしました

まともにスレッドつかったことのないやつばかり

おかしいと思う所があるんならはっきり言えよ
お前の中だけで完結してるならチラシの裏にでも書いとけ

なんかよく分かんないけどとりあえず、Win32でSemaphoreやEvent使ってるコードを
std::atomic、mutex、condition_variableで効率的に書きなおす移植用サンプルが欲しい

>>78
↓はvolatile関係あるだろ

>>71
> シグナルですらグローバル変数を回避できるのに。

JavaやC#じゃねぇから関係ねぇよ

a = true;
a = false;

こんな風に連続して代入された場合、
1番目の代入が消えなくなる。他にも無駄な式が消えなくなる。
それから、レジスタではなくメモリーに値を取るようになる。
それだけの機能しか無い。

スレッド環境じゃメモリーに値を取るのは、mutex呼べば強制的に
押さえ込まれるので関係ない。2重代入の消去にしてもグローバル変数や
引数で渡されたポインタに関してもmutexを読んだ場合は、
コンパイラが他の関数で参照する事を考え削除しないので影響はない。
よってvolatileの意味はない。

そもそもvolatileなんて組み込みやOSでのIO向け機能だし
((int*)0x10000) = 0x01;を連続で呼ばなきゃいけない場合とかに使う物
そもそもC++11以前のC++はスレッドの事を何にも知らん

>>93
>mutexを呼んだ場合は、コンパイラが他の関数で参照する事を考え削除しない

これってstd::mutexに限った話です？
それともpthreadやWin32その他のAPIでもそうなるの？

>>95
インライン展開しない関数全般の話
関数を呼んだ時点で、呼び出し元の変数はスタックに退避される。

スレッドに限らず連続した代入式でも
関数の呼び出しを跨いでるものを
削除したらマズイ訳で

int global;
int Callee()
{
      return ++global;
}
void Caller()
{
      int n;
      global = 10;
      n = Callee();
      global = 15;
}
int main(){Caller();return 0;}

>>96

>>98 何が言いたい？mutexなら外部関数だからインライン展開されんぞ。

>>96-97
理解できたかも。なるほどです

スタティック領域/スタック領域/ヒープ領域などには関係なく、非インライン展開の関数をまたぐ場合、
コンパイラはメモリアクセス順を変えたり削除したりせずに常にメモリ書き込みコードを入れるってことかな
ただし書き込みと言ってもCPUキャッシュまでライトバックされるとは限らないから、スレッド間ではもちろんmutexが必要と

逆に言えば、ループ内でメモリを直接読み取る場合で、かつ関数をまたがないパスがあるなら、
コンパイラが最適化をかけて書き戻し命令が削除される可能性があるのでvolatileが必要
ってことですよね

実装上ありえないって話と仕様のどこで明示されてるって話は別だろ

実装上でもありえんこと言ってる奴までいるし

>>100
あ、ちがうか
mutexでロックするならループ内で直接読み取る場合でもメモリ書き込みコードは削除されないから
結局ロックをかける限りvolatileはいらないってことになりますね。なるほど

仕様上どうするかロクに書いてないvolatileより
論理的に確実性がある分マシ

そういうスレじゃないから

>>102
だから主語を言えって。他人が読んでるわけで、
あんた一人が書いてるチラシの裏じゃないんだから。

ラムダでキャプチャする変数を
一部だけ変更可能にする方法ないでしょうか
全部一括でconstかmute しかないの？

>>97
いやvolatileが導入された時点でその意味は変更されてる。
強制したければ、volatile修飾子付けるしかない。

ｲﾐﾌ

>>108
何が言いたいのかわかんない。
volatile有ろうが無かろうがあのコードの動作は変わらんぞ。

volatileの意味があるのはメモリマップドI/OとCの仕様書に
書いてあるようなシグナルとの通信のみ。
そのシグナルとの通信でさえ実際には、パイプとか
シグナル安全なブロッキング使うことになるから形骸的。

volatileがなんでマルチスレッドの話題に登場するんだ？

globalにvolatile qual.付けなきゃ、
関数から戻って来た後の値は不定。
呼び出す前にメモリに書き込まなくていいから。

>>112
mutex呼んだ時点で書き込まれるから要らん。
逆にvolatileをmutex がわりにする事もできん。

C++でのvolatileの誤用についてはとりあえずあれだ、gosling先生が悪いってことにしとこうぜ

>>110
> シグナル安全なブロッキング使うことになるから形骸的。

シグナルハンドラ側でもアクセスしたい場合、
volatile付けとかないと。

Atomicityと最適化抑制の区別付けられてないのでは？
(他人がつけられてないと思っているが、
実際は自分がつけられてない)

>>113
>>97のコードはMutex読んでないし、
そもそもマルチスレッドの話しはしてない。

結局どっちが正しいの？
volatile指定と関数呼び出しは、（コンパイラにとっての）可換なメモリバリア指定なの？

>>117
volatileはmemorry barrierと直接関係無い。
最適化抑制にすぎない。
Barrierは別に必要になる。
可換どころか直交。

>>112
んなわけないじゃん
全ての値の変更は副作用完了点を通れば完了するよ


もしかして釣り？

実行スレッドから見てas isであればよい。

それからこのスレ的には、
副作用完了点なんてものは過去のもの。

「同一」実行スレッドと明示しておいた方がいいかな

>>118
メモリバリアとか別の話をしてすまん
volatile指定と関数呼び出しは置き換え可能な最適化抑制なの？

出来ない。
メモリアクセスに関する最適化抑制が出来るのはvolatileだけ。

誰かわかりやすく３行でまとめろ

>>124
インライン展開されない関数で変数を挟めば最適化を抑制できる
スレッド間で変数を共有したいならmutexで挟め(volatileなんて忘れろ)
volatile信者はアホ

if(volatile_v) 　○　volatile_v=fail;
// 別threadが↑ここで書き換える可能性
// atomic云々関係なしで

>>125
> インライン展開されない関数で変数を挟めば最適化を抑制できる

出来ない。
評価順序の規程は同一実行スレッド内に限られた話。
順序は同一スレッドからas isでいいので、
副作用のある操作もメモリアクセスは保証されない。

なお、mutexは、例えばgcc/g++を使っている場合、
__asm__volatileを使って実装されている。

もしかして : volatileを使ってmutexを実装する話をしている人が混ざっている

>>127
なんでメモリバリアの話を持ち出すわけ？
メモリバリアしたけりゃmutex使え。
__asm__volatileとかそんな独自キーワード出されてもね。

>>88
ハァ＞？

>>126
今の話はソースコード通りの読み書きが保証されるか？って話で同期は関係無いだろ

ところで>>125の話は、LLVMやLTOみたいな、
「inlineを付けてなくてもプログラム全体を通して1箇所からしか呼ばれてないから直接展開するぜ」
みたいな最適化をするコンパイラだとどうなるんだ？

あれ、関数は論理的に副作用がなければ実行順序は無保証、volatileもその変数自身以外は無保証、だと思ってたが

俺の質問に答えてくれ

>>131
>直接展開するぜ
展開されちゃってるぞ。言いたいことは分かるけど。

>>133
volatileがマルチスレッドに必要だと考えてるバカがいたから。

>>120
そうだったな

それでも>>112が03でも11でも間違っていることに違いはないけど

>>133
多分↓みたいな場合に最適化抑制用のvolatile修飾が変数vに必要か不要かって話じゃないの？
それでLLVMやLTO？でもそれは正しいのかっていう話だと思うけど
int v = 0;
mutex m;
void thread_main() {
　for (;;) {
　　m.lock();
　　if (v) { m.unlock(); break; }
　　m.unlock();
　}
}

>>115
int discripter=-1;

void handler(int)
{
write(discripter ,略);
}
こういうケースなら論理上問題になら無い。

仕様でvolatileが保証すんのは、
シグナル実行中にグローバル変数の書き換えが発生した場合、
mainとhandlerどちらかの書き換えが飛ばされないということだけ。
handlerを動かす前に変数を初期化して、以降一切変更しないので
あれば影響無い。

因みにsignalとvolatileの話は、signal の仕様であってvolatileの
仕様ではない。別のページに書かれてる。

>>137
不要な理由を挙げるとこんな感じか

mutexの実装にOSのAPIを呼んでいるならAPIの展開なんてまず無理。
アセンブラで実装してるなら副作用の有無が分からないからアセンブラを挟んで最適化しない。
たとえアセンブラのコードを解析して最適化しようとしても、メモリバリア命令の存在が分かるだろうからやっぱり最適化しない。
そもそもmutexを使用しているのに最適化されるならmutexの存在する意味が無い。

ghan＆Ritchieの本『プログラミング言語 C』より
「volatileの目的は，黙っていると処理系で行われる最適化を抑止するこ とにある．
例えば，メモリ・マップ方式の入出力をもつマシンでは，ステー タス・レジスタに対するポインタは，
ポインタによる見かけ上，冗長な参照 をコンパイラが除去するのを防ぐのに，
volatileへのポインタと宣言するこ とが可能である．」

元々目的も違う。

>>140
あっ名前が切れた。ごめんなさい先生。

>>139
全部憶測じゃないの？それ
結局はそのmutexの仕様、コンパイラの仕様、CPUアーキの仕様にC++の仕様を合わせて個別に確認しないと
何も保証されないし何もわからないってことですよね

>>142
mutex＝メモリバリアしてくれる関数を前提として話しているので
意味不明な心配をされても困るんだけど
まあC++11のstd::mutexでも使いなよ。規格で保障されてるんだから

憶測はおいといて、環境依存なのは当たり前。
C++はスレッドなんか知らんからな。

だがmutexで囲む変数にvolatileを求める仕様は、
少なくともwindows ,unix, linux には無い。

mutexじゃなくてスピンロックならどうなるのかなっと

>>145
そもそもCじゃまともなスピンロックはできない。
特にマルチコアなら顕著。
出来るのはアセンブリレベル。

メモリから値を読み込み、条件判定をし、
ロックの更新をしてる間に、他のスレッドも
条件判定を通過できるんですぐ破綻する。

mutexなんてC++03の仕様にないんだから
規格の範囲内じゃmutexがどうこうなんてどうも言えん

x86以外の現役CPUは、ARMをはじめみんなI/Oポートをメモリー空間にマップしてんだよな。
C++にはメモリバリアも仕様で追加されたし、今の仕様のvolatileを必要とするCPUは大量にあるし、
今後C++2x、C++5xが登場しようとvolatileがスレッドに絡んでくることは無いだろうな。

そのうちthread_volatileみたいな修飾子が出来るんじゃないの

既にライブラリで解決すんのに何でそんなもんいるんだよ。

>>146
std::atomicってそのためのもんじゃないのか

#include <windows.h>
#include <process.h>
#include <io.h>

void Thread(void* param)
{
　　volatile bool* flag = (volatile bool*)param;
　　while (*flag)
　　{
　　　　// 終わる？　終わらない？
　　}
　　printf("end\n");
　　_endthread();
}

int main()
{
　　bool flag = true;
　　_beginthread(Thread, 0, &flag);
　　Sleep(2000);
　　flag = false;
　　Sleep(2000);
}

これ、volatile がないとVC++2010では無限ループ

まあ、while 内に関数呼び出しがあると
その中で *flag が変更される可能性があると判断されて
無限ループじゃなくなるんだけどね

>>136
横から悪いけど、11から副作用完了点って削除されるの？どう処理されるか厳密に決められた訳？

>>153
http://d.hatena.ne.jp/Cryolite/20101228#p1

>>152
だからmutex( CriticalSection )挟めばいいだろ。
なんでvolatileに拘るんだ？必要な最適化もされなくなくなって無駄なだけだぞ。

マルチスレッドプログラミング相談室 その8
http://hibari.2ch.net/test/read.cgi/tech/1253521167/

ほい

このスレって割り込みやシグナルとスレッドをごっちゃにしてるヤツがいないか？
割り込みは、他の関数呼び出しが無理やり入るだけで、呼び出された関数が
終了するまで本筋の処理は中断するんだぞ。スレッドみたいに並走はしない。
volatileが割り込みで使えたからと言って訳が違う。

もうvolatileを使ったクソコードなんて見たくも無いよ！！

>>155
mutexはパフォーマンス落ちるからだろ
スレッド内でフラグ読むだけなら同期なんて要らないんだから
mutex使う方が無駄

あと、それはmutex用の「関数呼び出し」があるおかげで最適化されないというだけの危うい方法

>>152の書き方はバグのもとだからwinならinterlockedを使うのが普通
で、interlockedを使えば最適化とかキャシングとか何も考えずにコーディングすれば間違いは起こらない
ってことでいいの？

>>159
>>146　と同じ話なんで論外。
運悪ければデータ破損する。

読み出ししかしてないんだから破損なんてしないだろ

実際はなんかのタイミングを合わせるためにやってんだろ。
その実際の処理でデータが破壊される。
ま、本当に何の処理もせず>>152のコードまんまを
走らせたいんならどうでもいいけど。

No。タイミング合わせじゃない

flagを変更したタイミングを厳密に見たい場合は当然lockしないといけないけど、
大体で良ければ同期せずvolatileのフラグをポーリングしておけばいい
ワーカスレッドの動作をあまりパフォーマンス落とさずにキャンセルさせる時によく使う

実際には何かの処理を行うが、
関数呼び出しのないただの演算のみって場合もあるので
その場合はvolatileがないとアウト

どうやって入力して、どうやって出力する気か。
まぁいいや。スレ違いだそろそろやめるか。

ポーリングウェイトとかいつの時代のプログラムだよ

ポーリングウェイトとかいつの時代のプログラムだよ

大事なことだったんですね。

>>152はVC2010(x86)という特定の環境でこのシンプルな使用方法なら問題ないとおもうが
かなり汎用性にかけるので気持ち悪い。コードが複雑になってくればvolatileはバグの温床になるぞ

演算しかしないならスレッドそのものを中断したほうが速いだろ
フラグで中断しようが、スレッドで中断しようが演算結果に大差ない

>>154
ありがとう。勉強になった

>>166
ウェイトじゃないって

>>169
volatileは最適化を阻害するから汎用性はある
どのコンパイラだろうが汎用的に使えるよ
フラグにしか使わない（使えない）からこれ以上複雑になる事もない

>>170
ループ外に問題があったら駄目だろ

>>172
volatileじゃメモリバリアの保証が無いだろ。マルチスレッドプログラミングに用いるのは間違い。

キャンセルしてスレッドは速やかに動作を終了し、
スレッドは共有してる他の情報に手を出さないんだから
関係ないと思うが

どこのスレでもNULLとgotoとvolatileの話は盛り上がりますね

そんなにメモリバリアを保証したけりゃ
フラグチェックした「後」にどうこうすればいい話
わざわざループ内でlockのコストを払う必要はない

てかリードにメモリバリアとか関係あるの？
書く時だけでしょ

ループにvolatile混じってたら自動ベクトル化が掛からんだろ。
演算ループだけ追い出して、ループごと強制終了。本気で速度が欲しいならコレおすすめ。

だからVC2010でこのシンプルな使い方については問題ないと言ってる。

大体コストが気になるほど猛烈な勢いで終了flagをチェックしてるのか？
windowsのクリティカルセクションの開放取得で80〜200サイクルだぞ

実装コストも関係するんだけどね

ん？

必要のないコードを書くのは時間の無駄

デバッグで時間を無駄にしないようにしてね

するわけないだろw

>>144
> 憶測はおいといて、環境依存なのは当たり前。
> C++はスレッドなんか知らんからな。

おいおい、規格ちゃんと読んでないのに、
そんな断定書き込むな。
4年くらい知識遅れてるじゃねーか。

C++11になってから初めてスレッドと邂逅したんだろ。

コンパイラとアーキテクチャを限定していて、
かつ、他の環境では不都合が起こる可能性があることを覚悟してるんなら、
volatileだろうが何だろうが使えばいいじゃない。

たが、残念ながらスレ違いだ。
ここはC++11スレなので、std::atomicやstd::mutexを使え、でFA

std::atomicってvolatileなくてもよかったっけ？
volatile std::atomic<volatile int> a; みたいなサンプルコードをどっかで見たような

>>188
いらない。
誰だよ、そんなサンプルコード書いた奴は

atomicにvolatileはイラんでしょ　イラんでしょ

そうなの？
N3290確認したらstd::atomicってvolatileメンバ関数いっぱい持ってるんだけど
これってvolatile atomicとして使う必要がある場合があることを想定してるんじゃないの

ふむ
想定してた名残じゃなければ気になるところ

>>191
C1xとatomic関連の仕様を共通にしようとgdgdやってたときの名残。
当時はヘッダファイル名も<cstdatomic>だったりしたな。

正直世の中のC++で使われているvolatileの99%は誤って使われてる

結局スレッドのキャンセルにしかみんな使ってないけどなw

>>191
内部実装のために必要。
volatileなければ、ポータブルなatomic実装書くことは不可能。

仕様があいまいな属性が実装に必要て変な話だな

そもそもvolatileってロードやストアを必ず1命令になるようコンパイルする仕様上の保証とかあったっけ？

>>198
なぜそんな質問をいきなりするのか不明。

>>199
ロード・ストアが1命令になるよう必ずコンパイルされるという仕様上の保証がなければ
「ポータブルに」atomicは書けないじゃん

CASとか最低限のところだけasm volatile、後はvolatileを使ってる。
volatile修飾子なかったら全部asm volatileで書くしかない。

volatile指定しても他のスレッドでのアクセスが反映される保証は無いというのは
昔から全く状況は変わっていないし何を問題にしているのかわからない
処理系依存のコードと誤ったコードというのは別だろ

>>200
ポータブルに書く必要はないし、
std::atomicの下はこのスレの範囲外だよ。gccスレなりvcスレなりで話せばいい

>>198
ねぇよ。アセンブリ命令がどうなるかなんて規定は無い。
ただCレベルから見て無駄な演算が消えたり、
Cレベルから見た演算順序が維持される。
例えば32bit環境で64bitの型を使うと
volatile 付けてても
2分割してメモリに書き込まれたりする。

>>201
CASってなんだ?
工業用のあれでは無いよな。

volatile と atomic 操作ってまったく関係ないのに
なんでごっちゃになってるの?

volatile って代入した次の瞬間にその変数の値は蒸発してしまって
何が入っているか見当がつかないっていう、それだけの意味だろ……

>>206
＞volatile と atomic 操作ってまったく関係ないのに
＞なんでごっちゃになってるの?
＞
エスパーすると、「Writeスレッドがread-modify-writeしない場合は、volatile指定すれば良い」という認識のサイトが多いから、それで勘違いしてるんでは？

何が問題で誰が何に反論してるのかわかりにくいな

>>207
このスレにはそんな書き込みしてる奴いないのにねえ。

>>202
> volatile指定しても他のスレッドでのアクセスが反映される保証は無いというのは
> 昔から全く状況は変わっていないし

C++11規格の第一章すら読んでないの丸バレ。

<atomic>にvolatile T*の引数を持つ関数が定義されてる。
新しい規格でvolatileの意味がまともに決まってないと思える頭の構造が分からん。
「全てのスレッドで〜」と説明するサブセクションでvolatileが言及されてるのに！

>>210
1章読み直したがやっぱり変わってないぞ

よかったじゃん

結局atomicにvolatile付けなきゃならないのはいつなんだよ

atomicが最適化されて期待通りの動作にならないことがあるとか？

http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
これって最新の規格？
まだ未確定の時のヤツ？

atomicにvolatile入ってんのは、atomicがvolatile必要なんじゃなくて、
volatile用のatomicが必要だからオーバーロードしてあるだけじゃねぇか。

上の方でatomicにはvolatile必要ないって散々言ってたのは何だったのか

>>216
そもそも規格ですらない
ただのテクニカルレポート

どんな時に必要になるのかって話じゃないの？
メモリマップドIOにatomic使う訳でもないだろうし

>>218
いや正しいだろ。

メモリマップドIOにatomic使うんだろ
組み込みの世界じゃコアが32個とかザラだし。

マルチスレッドでvolatile使うよ派の方々はvolatile使って何したいの？

その話題は終わった

マジか
んじゃまぁいいや

volatile　atomicのまとめ。

メモリマップドI/Oの際、連続して値を代入することが求められる。
そのため1回のロックをしている間複数回値の代入をする場合がある。
atomicはテンプレートでありインライン展開される。
インライン展開された場合、関数が消失し、その中にあるvolatile変数へ
の代入も消失する可能性がある。
よってvolatileを維持するためにatomicはvolatileメンバーを持っている。

volatile atomic_short *p = (volatile atomic_short *)0xA0000000;
みたいにして使えるの？

>>226
まとめも糞もおんなじ様なこと書いてあんじゃん

[ Note: Many operations are volatile-qualified. The "volatile as device register" semantics have not changed
in the standard. This qualification means that volatility is preserved when applying these operations to
volatile objects. It does not mean that operations on non-volatile objects become volatile. Thus, volatile
qualified operations on non-volatile objects may be merged under some conditions. ― end note ]

>>227
せめて正式版ではないにしろ>>216ぐらいは読め。

volatile atomic< int* > device = reinterpret_cast< int *>( 0x00000111 );

なるほど

>>193 >>196 いい加減なこと言いすぎだろ。

auto x = new auto(’a’);

こうできるといわれてみれば確かになんだが、地味に感心した。

なんで条件変数まで入って、メッセージキューが無いのか。
それはともかくusingが地味に便利っぽいな。多重継承したとき、
1つに実装があればその実装でオーバーライドできるとか。
なんで今まで出来なかったのか。

TRで追加されるんじゃないか？

>>222
メモリマップドIOに普通のint型とかじゃなくてatomicを使う理由は何?
volatile atomic<int>じゃなくてvolatile intでいいじゃん。

マルチコアでメモリマップドI/Oした場合、
他のCPUが信号送ってる途中に割り込むから危険だろうが。

>>236
メモリマップ領域の同じアドレスに、異なるスレッドが同時に書き込んだりは普通しないでしょ。
別途mutexなどで排他し、同時アクセスはしないようにするだろ。

メモリマップ領域にcompare and setとかせんわなw

そのmutexをさぼるためでしょ
ほっとくとvolatileだけで大丈夫キリッとか言い出す馬鹿がいるから

>>228
これってatomic<T>をvolatile atomic<T>にキャストしてもvolatileにならないから注意しろって書いてあるだけだよね

後半しか見てなかった。忘れてくれ。

メモリマップドI/O使うヤツにそんな馬鹿は居ないだろうけど。

>>237
atomicの書き方しってる？

>>239
あるメモリアドレスAに1を書きこんでからアドレスBのデータを読み込み最後にアドレスAに0を書く、
みたいな一連の操作の排他は、アドレスAやBをatomic変数にしてもできないでしょ。

見えない敵と戦ってる人相手にしても…

>>244
「一連」の操作にするにはmutex必須だな
「書き捨て」でいいならatomicで足りる

atomicが何してるかもまるでわかってないのによく書き込む気になるな

大部分はなんもしないだろ

>>246
お前恥ずかしくないか

>>229
そのコードも変だぞ

このスレでこのレベルじゃ
atomicとvolatileをマスターすれば食うに困らんな。

volatileはもうお腹いっぱいです

C++0xの仕様まともに把握してるの日本で何人いるんだ？

hito_hpp

まとめ
volatileを付けるかどうか迷ったら付けとこう

externとconstとstaticもつけておくか

>>251
このスレには素人しか居ませんから。

で。std::vectorの連続性が保証されるのは今回からか？
それともまだ見送り？

03から保障されてるでしょ

で。std::dequeの連続性が保証されるのは今回からか？
それともまだ見送り？

大事なことだったんですね！

>>260
アホ

>>260
実装がLinkedListによるものだったらどうするつもりなんだろう・・・。

如何にも無理やり中身を抉り出してます感
全開のvectorの直列仕様もどうなんだろ。
もっとましなアドレス取得用のインタフェース用意してくれんかね。

>>264
正直、C言語使わないのであれば、参照でVector本体を渡してしまうので、アドレスの直列性とかはあんまり気にならんなー。
Cであってもstdioでファイル書きこむときくらいじゃないかな？直列性なくて困るのって。

配列とvectorとどちらにでも対応できないと
困る関数もあんだろ

>>265
SIMDが面倒

そういやvolatileって常にメモリーから読み出されるか
どうかはなんら保証は無いよな。
>>152みたいにいつ止まろうがどうでもいい例は別として。
もしかしたら無限ループになるかもしれんけど。

仕様が複雑すぎて馬鹿大量精算

>>268
マルチスレッドがらみじゃないならスレ違い、
初心者スレで教えてもらってこい。

volatileひとつにこんな議論してたんじゃアプリができるころにはおじいちゃんだな

念じた通りに動けば実装コードなんてどーでもいいんだよ

>>265
Cでも列挙子のインターフェースを提供すればいいじゃないか
COMのCINTERFACEのように見苦しくなりかねないが下手に並べ直すよりもコストは低いと思う

>>270
ここは規格についてのスレだろ

>>270
初心者もくそもJIS規格読んでみろや知ったかぶり

誤訳だらけのJISのC++規格なんか読んじゃいけません

>>275
なんで ``JIS規格'' か, 汲んでやれよ
英語読めない低能だから吠えてんだろ?

Javaのvolatile相当の機能があると思い込んでんだろ

Javaのvolatileはちゃんと実装されてない事があるみたいな事聞いた事あるけど
今は違うのか？

JavaやC#のvolatileとC/C++のvolatileは全く違う機能
CとC++0xのautoくらい違う

んなこたー知ってる

http://www.ibm.com/developerworks/jp/java/library/j-dcl/
＞多くのJVMでは、順序の一貫性について、volatile が正しく実装されません。

ってのが今はどうなのかって事

JavaSE5以降で解決したらしいよ。
JSR133によって仕様が云々とか。

解決したのか
良かった良かった

もう9年以上も前の話だしな。
さすがに、まだ未解決のはずがない。

>>279
そっちでもやっぱり使い方間違ってる人がいる、
ってだけ。

？

http://www.open-std.org/jtc1/sc22/WG14/www/docs/C99RationaleV5.10.pdf
JISが不正確かどうかしらんが、volatileがメモリーに常に割り当てるかどうかはやっぱり未定義。
割り込みでsig_atomic_tを使った場合はともかく、スレッドで全てのシンボルが同一の値を指してる保証はない。
さてvolatile厨はどう反論するきだ？

仕様より実装のほうが大事
マニュアル読まない奴はカス

メモリバリアは保証しないけど
永遠に異なる値を指す事はあり得ないので
タイミングが重要でないものに使うのは問題ないと何度言えば

だったらGCCなり、IC++なり、CLなり処理系のスレで叫んでろよ。
規格のスレでほざくんじゃねぇ。

>>289
割り込みと違ってスレッドの場合は、永遠と値が異なる処理系があっても構わん。
命令の順序さえ変わらなきゃいいんだから、少しでも早くしたいリアルタイム系の
処理系なら有りうる。

thread_localでないものが同一オブジェクトを指さないのは規格違反じゃね

なんの規格だよ。

アドレス同じなのに値が永遠に異なるとか
具体的にどういう処理系があんだ

1.アドレスを参照しない
2.関数を呼ばない

1つの関数内でこれが守られていれば、
グローバル変数は関数の最初とreturn 時以外は
レジスタに配置しておいても規格上問題はない。

処理系の検知できない手段で変更がある可能性を考えて
最適化はvolatileつきでは行わないとか
volatileオブジェクトはabstract machineのルールに厳密に従わないといけないとか
書いてあるんだけど

で、レジスタに配置することが最適化になるかね？
レジスタかメモリーか、それどころかvolatileの向こうは
ハードウェアですらいいことになってるんだけど。

別にレジスタに配置されてもいいけど
それを検知できるというのがvolatileだ

要するに鼻から出てきた悪魔がメモリを変更しても
volatileがついてたらそれを検知できないといけない
ただ、現実問題同時性までは保証してないようだが

そもそもvolatileは同一の値を指してる事は保証しないとね。
名前からして揮発修飾しだしね。

volatile
No cacheing through this lvalue: each operation in the abstract semantics must
be performed (that is, no cacheing assumptions may be made, since the location
is not guaranteed to contain any previous value). In the absence of this qualifier,
the contents of the designated location may be assumed to be unchanged except
for possible aliasing.

紛らわしいこと書いたが。「保証されない」だからね。

いつ値が変更されるか分からないという意味で揮発修飾なわけだが
変更する奴が誰か分かっていて、
さらに変更する奴がいないと分かってる状態で
永遠に異なる値を指してもいいってのは拡大解釈じゃね

>>299 読めば解るが、値が勝手に変わらないことを保証したければvolatileを付けない。
volatileを付けた時点で変数が以前の値を保持する義務が無くなる。

いや、別スレッドで値が変えられることを考慮するためには
値が勝手に変わる事を保証しないと駄目だろ
以前の値を保持されちゃ困るからvolatileつけるってのに

勝手に変わる事を保証、じゃないや
別に保証はいらなくて考慮さえされてればいい

だから、それはvolatileの使い方が間違ってんの。

>>287 の75ページから読んでみろ。 >>299に書いてある内容の続きがあるから。

volatilleを値共有に使いたい場合、プロセス間でのメモリマップドを
応用すれば一番確実な方法は

int value;
const volatile int *referece = &value;

って事らしい。

volatileは左辺値のキャッシングを行わないだけで
左辺値のアクセス自体に対しては特に特殊な要求はないように見えるが

で、同じ左辺値が誰も変更操作を行ってないのに
見る箇所によって異なる値を持ち続けて良いのか、という事、
これはvolatileとは無関係な話でvolatileの規格だけ見ても埒があかない

誰もってのはハードウェアから鼻から出た悪魔まで含めての話な

C++11からマルチスレッドを考慮した規格になったので、
volatileオブジェクトへの書き込みは他スレッドから見られることになりました。

具体的に書いてあったっけ？

とにかくvolatileで保証されるのは、副作用(I/O)のための順序だけ。
volatile変数がメモリー上に存在しないかどうかは完全に処理依存。

>>309
ソース。

volatileは普通ポインタにつけるから
グローバル変数の話はどうでもいいよ・・・

組み込みの世界じゃアセンブリで実体をハードに割り当てる場合も割とあるけどな
extern const long hard_clock;

あ、まちがえた
extern const volatile long hard_clock;

その場合はセクション割り振るから
メモリアドレス振られるのは保証されるんじゃない

アセンブラで実体作ってるから
レジスタには置かれないな

てかexternのものはそもそも実体がレジスタには置かれない・・・よね？

ハードに割り当てる話は、メモリとレジスタ云々には関係ないぞ
ポインタじゃなくても使うことがあるという例を書いただけ

グローバル変数でexternしてないvolatileの実体が
メモリに置かれるとは限らない、という話だが、
グローバル変数をレジスタに置くのは規格に沿うのだろうか
registerはグローバル変数に付けられないし

あーでもstaticで一箇所からしか使ってなければ
あり得なくはない・・・のか？

>>319
元々registerは強制的にレジスタを割り当てる修飾子だったんだから
広域変数に割り当てられないのは当然だろ。関数呼び出しがおかしくなる。

register就職できないとはいえ、関数内で広域変数をレジスタに
割り当てるのはコンパイラの自由。というかレジスタマシンじゃ
割り当てないと計算できん。

関数内で割当て？
複数関数で使ってても？

>>322
このスレを>>93あたりから読み直せ

>>307
スレッドを無視すれば、関数から脱出するか、
別の関数を呼び出すまでレジスタだけに値を置いといても問題はない。
割り込みがあっても、sig_atomic以外は保持する義務も無いし、
言語仕様に基づいてプログラム書いてる限りでは、レジスタの値だけを
更新することは問題にはなりえんよ。

全てアセンブラで書いてるときに
複数スレッドで１つのレジスタを共有なんてのは当たり前

おおかた ARM のバンク切り替えあたりで思考停止したようだな

どんな環境?

>>325
全部アセンブリで書くことなんて無いだろ。
てか、アセンブラで書くなんてほざいてる時点で
まともにアセンブリコード書いたこと無いだろ。

フルアセンブラでスレッド？

ハードのデバッグ中なんかもちフル汗だし
そうでなくても割り込みなんぞ本質的にマルスレだね
ユニプロでちまちま書くかあっさり疎結合かにもよるが
前者ならレジスタ共有は捨てがたいテクだし

割り込みはマルチスレッドとは言わない
コンテキストスイッチがない

あるよ
逆に CPU アフィニティなんぞコンテキストスイッチのないマルスレだしな

退避するレジスタをケチったりしたなあ

シグナルとスレッドは似たところもあるけど、最大の違いは
「シグナルで割り込まれた側には、割り込んだシグナルハンドラの実行が終わるまで処理が戻ってこない」
ってこと。だから、内部でmutexを使ってるような関数をシグナルハンドラから呼ぶと簡単にデッドロックしてしまう。
mutexすらロクに使えないものを「スレッドの一種」とは言えないよねえ。

>>331
> CPU アフィニティなんぞコンテキストスイッチのないマルスレだしな
は？
じゃあ、シングルコアCPUでのマルチスレッドでは「コンテキストスイッチ」がないのかい？
馬鹿馬鹿しい。

スレッドはいつ他のスレッドが動いても問題ないというものだからな
割り込みは違うわな

>>329
割り込みは、並列稼働しないだろ。
割り込み処理が終わるまで、
メインの処理は止まる。

マルチスレッドの実装を語るスレはここですか？

いや、スッドレの定義を主張するスレでそ

// プリエンプトってどうやるんだっけね

スレッドセーフな関数と割り込みセーフな関数が違う時点で、
全然別物だと気づくはずなんだけどな。

>>331
コンテキストスイッチなんてPen3以前の頃からあったろ

>>332
どのCPUでどういう処理書いててレジスタの退避けちったの?
普通、一つのスレッドは全てのレジスタを使う可能性が有るし
正数演算系のレジスタは全て使い倒さないと非効率だから
全部退避対象になるでしょ。
スレッド間でレジスタ共有なんてしたら非効率な上に危険。

>>325 に、どのCPUでどんなコード書いたか書いてもらうのが早いな。
OSもあるなら、なんていうOSか聞きたい。
でも結局、昔の(Z80とかであるような)割り込みなんだろうな、そうなら書かなくていいよ。

アフィニティつってるのにユニプロが馬鹿馬鹿しいだのさー、
Pen2 にコンテキストスイッチがあったとかさー、
再入可能モジュールは色々あるとかさー、
なんか (1+1) は (2) みたいなことを説教されてもリアクションに困るんだよね

そういやレジスタの同時使用数が多いと最適化が裏目に出る CPU なんてのもあったね

アフィニティってCPU 固定するだけだろ
何が言いたいんだ？
アフィニティだろうがコンテキストスイッチは無くならんぞ。

>>344
少なくとも減らすためにすることで
減らなかった分はアフィニティと関係ないし

>>343
で、何が言いたいんだ？
今までの流れだと、お前はコンテキストスイッチの無い
スレッドが存在すると主張してるように見えたんだが。

>>346
だから、そうだよ
違うって言いたいのか？

まだやってんのかよお前ら
せめてC++11絡めて話せよ

C++erの視野の狭さは異常

>>347
お前の話に一度もコンテキストスイッチの存在しない
実在環境の話が出てない。

あとC++の話に戻すと、割り込みで使えた方法だとして、
スレッドと割り込みは別物なので
スレッドで安全に使えない。
C++が割り込みに対し保証してること=スレッドに対する保証
ではない。

>>350
そうか、聞きてえのかｗ　＞実在環境
お願いしろよ、言ってやるかも知んねえから

そもそもレジスタ共有は割り込みかスレッドかには関係ねえし

帰レ知ったかぶり

コンテキストスイッチでレジスタの内容がスレッド毎別になるだろ
レジスタ共有するにはわざわざそのレジスタの内容をメモリから復帰しないといけなくて
使い物にならない

>>353
言語は使う人が何を考えることができるのかを決めてしまう by禿
もっともお前さんが言ってるのは言語より以前の話なんだが

レジスタの内容退避しないで特定の協調スレッドへステートの一部をレジスタ渡しするようなゲテモノを想像してしまった
ここは何スレだ一体

>>354
バカは言語に使われるbyゲイツ

レジスタ１個１個退避と復帰やってんのか
ご苦労な事だ

>>341
おれは >>331 じゃないが
80系とかをセンブラで書いても普通にタスクスイッチするよ?
# なければ作るし
割り込みだけは特別扱いで, 全部アセンブラってノリかな

タスクスイッチするのはいいけど
レジスタ共有はないな

>>359
まぁな

>>354
言語以前にレジスタ機械の問題だろ

>>349
> C++erの視野の狭さは異常

そういうことじゃないんだよ。

ようやく、ちょっと口を挟める話になったから、
何人もの雑魚が知ったかぶって、見当違いの
レベルの低い話をしているだけ。

こいつらは C++er じゃなくて、ただの雑魚。

C++0xスレにも>>362のようなドカタくせぇレスがつくようになったのか
C++もおしまいだな

volataleは正直組み込み系の人位しか使ってないから誤解が多いのも事実
そしてJavaにも存在して意味合いが違ってたりしてまた混乱に拍車をかける

volatileポインタにメモリマップドI/Oのアドレス割り当てたとして、
ハードウェアがその値を変更せずとも、
コンパイラが生成したコードが適当なタイミングで勝手に値を変えても規格合致だと？

本当か？

>>365
既にソースが上がってるだろ。
読めよ。

しかし、あの仕様ではなぁ。

禿の爺さんも、チンポカムウアやエピスカレーの努力も認めるよ。
でもあれは呪文コードだって。


あんな、言語どうでもいいわ、と思えるのは仕方ないことだわ。
禿は禿で読む気にもならんツマラン入門書、書いてるし。



もう、C++終われよ

有り難がってるお前らの額に文字が浮かんでるぞ。



｢馬、鹿、。。｣の文字がｗ

くだらん書き込みでageるなカス
このスレでageてる書き込みはほとんどカスの書き込みだな

と、つまらんペーペーのカスが言っております。

どうか、みなさん御容赦を。


こら! 頭下げんか、できそこないのカスがｗ

やるならもうちょっと上手く煽れよ頭悪いな

>>366
ないぞ

>>364
同期プリミティブ書いてる人も使っているよ。

おいおいvolatileはCとC++は殆ど共通仕様だろ。
何仕様もまともに読めない癖にC++乏してんの。
そういうのは一通りiso読んでからやれや。

>>372
>>287
C99の仕様解説だがC++とは共通。

>>373
ソース

>>372
volatileオブジェクトは複数プロセス間で共有する変数として適用可能って書いてるぞ

static volatile、static const volatileオブジェクトはメモリマップドI/Oに適用可能
volatileオブジェクトは複数プロセス間で共有する変数として適用可能
const volatileオブジェクトは別プロセスで変更される変数として適用可能

勝手に値が変わっても良いなんて書いてないが
適用可能≠全環境で適用可能であって
何に適用できるようにするかは処理系依存と書いてあるな
メモリマップドI/Oや共有に使えると処理系のドキュメントに書いてあれば
そのように使って構わないと言う事か
逆に、これら全部に使えもしないような実装でも一応規格合致なのか
そんな糞実装実際問題ないだろうけど

>>377
プロセスであってスレッドでは無い。

>>378
75ページの20 volatileに書いてあるだろ。
以前の値を保持することは保証しない。

ちょっと前までは知恵は無くても知識欲だけは有りそうなヤツラが集ってたのに
フリーズに入ってからこのスレもうグダグダ棚

>>379
プロセス内でも共有されるのだからスレッドでも共有される
それにプロセスってのは単なる例に過ぎない

>>380
どこまで保持するかは処理系依存と書いてある
処理系が保証すれば問題ない

>>382
スレッドとプロセスは全然違うだろ、何いってんだ?

>>382
処理系依存ってのは、ずっと解ってることじゃん。

>>383
？

プロセス間の場合変数の実体を通して値を共有する事は基本無い。
基本的に共有領域へのポインタによるアクセスになる。
この時ポインタにvolatile修飾が有れば、
共有領域への書き込みは保証される。
ただし、ポインタ自信がどこに有るかは不定。

ちなみにMSのコンパイラだとdata_segを使って
変数の実体を共有できるが、volatileで修飾された変数が
msで使用されることはない。

>>364
入力されたパスワード領域を後で確実にクリアするのにもvolatile使ってなかったっけ？
なんか昔問題になったような気がする。std::secure_fillみたいのがあればいいな。

>>382
メモリが共有されるスレッドと共有されないプロセスじゃ安全性が全然違。。。

全てのオブジェクトは全てのスレッドで扱えるって規格に書いてあんだろ

>>389
何の事だ？どの仕様のどこに書いてある？
それはスレッドの項目に書いてある内容で
volatile固有の話じゃないだろ。

まあC++11だがな
volatile固有ではないが、volatileにも当然適用される

要するにvolatileが無くても同じ

逆に全てのスレッドで使えなかったオブジェクトなんてあったか?

プロセスAとプロセスBで共有しているものは
プロセスAのスレッドa1とプロセスBのスレッドb1で共有しているし
プロセスAのスレッドa1とプロセスBのスレッドb2でも共有しているし
つまりプロセスBのスレッドb1とプロセスBのスレッドb2で共有しているということ

>>394
バカじゃねぇの。プロセス間通信とスレッド間通信の問題で
一般化された概念がどうとかいってねぇだろ。

馬鹿にも分かるように説明してくれ

あれを出せばこれがダメ、これを出せばあれがダメ・・・。

処理系依存で済む話がなぜここまで発展してんの

>>202が言うには誤ったコードらしいですよ奥さん
でたらめな話だけど

>>393 コントロールスタックなんてもんはスレッド固有じゃないとまずいんじゃね?

C++11の新機能をかいつまんでまとめてくれよ。もうついていけてないわw

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

別についていかなくても、互換性はそれなりに保たれてるから安心して
これまでどおり使っててもいいんだぜ。どうせ C++03 切り捨てて使えるように
なるまでにはもう何年かかかるんだろうし。

要するにスレッド間でvolatileを使うな。
仕様じゃ保護されん。
それだけの話。

ところでchar16_t/char32_tって嬉しい新機能なん？

charにぶっこむよりいいんじゃね

>>404
linux じゃwchar_t は32bit だし
移植したい人にはべんりでしょ。

strlenの代わりにchar_traits<char16_t>::length()なんだよね？
wchar_tと比べてなんか面倒くさそう
てかchar16_tってサロゲートペア考慮してるのかな

は？ それ char ってシフトJIS考慮しているのかな？と同レベルの質問だぞ。

>>407
一応UTF系はサポートするそうな。
詳しくは仕様書見ろ。

__STDC_ISO_10646__でない場合、他のUNIX系だとwchar_tはopaqueだったりするしなあ
別に型用意した分混乱少なさそうだけど、実際どういう使われ方になるのかなと

>>399
処理系依存のコードであって誤ったコードではないと言ったんだよ
当たり前だろ

>>411
正確には「処理系依存」ではなく「未定義動作」だ。

どのコードが未定義動作だって？

>>413
ループ脱出を他スレッドから指示するフラグ変数のように、
C++0xではstd::atomicを使うべきところに
単なるvolatile変数を用いているコード。

>>410
char16_t/char32_tは読み込み用のバッファにして使う時はwstringに変換するとか？
もしいろんなライブラリがwchar_tから移行するなら移行するんだろうけど、どうなんだろ

>>414
C++11 のスレッドで使うと data race が発生するから未定義動作、ってことでおｋ？
それって C++03 までは単に処理系依存なコードじゃないの？

>>416
C++03単体で言えば undefined でしょ。仕様書でスレッドについて何も定義していないんだから。
C++03 + pthread みたいに組み合わせてはじめて
処理系依存だとかそういう話ができるわけで

>>417
規格で何も定義していないことを指して未定義動作だとか undefined だとか、
明示的に未定義とされた箇所とまぎらわしいからやめてくれ。

C++03 以前の話なら pthread なり何なりの仕様と照らし合わせないと結論は
出ないでしょ。

>>418
なんで区別する必要がある？
明示的だろうとそうでなかろうと、
仕様書の範囲外のことなので実装がどうなってようが関知しない
ってことでしょうが。

>>419
ライブラリとしてスレッドが実装・利用されていた事実に反すると思ったんだけど、
規格としてはそうなるか。

ごめんよ。

>>412
処理系依存です

Whatever decisions are adopted on such issues must be documented,
as volatile access is implementation-defined.

>>421
C++11の仕様書にはそんな文言は書かれてないんだが

C99に書かれている
で、C++11

In general, the semantics of volatile are intended to be the same in C++ as the are in C.

特記するような事でなければ、
この手は、Cに倣えだからな。

>>423
"In general"とか"intended to"の意味わかってる？
>416にもあるように、C++11では明示的に undefined behavior と書かれている。(1.10.21)

ならC++03までは処理系依存ってことで

これからは未定義だ。良かったな。

明示的に implementation-defined と書いてなきゃ
それは undefined だろ

最初にC99の仕様出してきた人に文句言ってくれ

>>423(>>421)
それ C99 の規格じゃなくて rationale でしょ。ちゃんと区別してね。

>>425
> C++11では明示的に undefined behavior と書かれている。(1.10.21)

ここはraceの話で、volatile関係ない。
raceとobservable behaviorを区別しろ。

でも同じ変数にアクセスする以上
未定義の振る舞いになっちゃうんじゃないの？

>>432
> でも同じ変数にアクセスする以上
> 未定義の振る舞いになっちゃうんじゃないの？

何が未定義になると考えたの?

「このようなデータレースは未定義の振る舞いをもたらす」
と書いてるから、何がっつーか、やった途端鼻から悪魔が出てくるんじゃないの？

>>431
> ここはraceの話で、volatile関係ない。
そうだよ。data raceの条件にvolatileの有無は関係なく、
そしてdata raceの結果はundefined behaviorだ。
それが何か?

>>414がおかしい。

>>435
> そしてdata raceの結果はundefined behaviorだ。

data raceの結果って何?
もっと具体的に言える?

なんでそんなに必死なんだ？
undefinedって書いてあるんだから、その通りに解釈すればいいじゃない。

>>438

結果はundefinedだろ
具体的に言える訳が無い

C++11ではatomic objectがvolatileであれば、
他スレッドの書き込みが別のスレッドからobservableであることが保証されている。
そういうメモリモデルが採用されている。

APIは定義しないが、メモリモデルだけ定義しておいた。
GCと同じパターン。

そもそもAPIを定義してないのに、上のようなメモリモデルすら定義しないのなら、
規格がスレッドに言及する意味は全くない。

>>441
> C++11ではatomic objectがvolatileであれば、
> 他スレッドの書き込みが別のスレッドからobservableであることが保証されている。
それはvolatileの有無に関係なく保証されてる。(1.10.25および29.3.13)

>>441
APIも定義されてるでしょ。
memory_order_seq_cstとか。

>>441
volatile だけだ書いてあるソースを書け。

なんでボラ厨は仕様書を読まないの?
ここはC++11という規格のスレだよね。

atomicならそりゃそうだろう

>>443
標準規格にAPIなんざ無いぞ。

>>447
ん？
APIってのが「スレッド間のメモリ可視性に関わるAPI」のことだと思ったから、
それならメモリバリア指定とかがそうだよね、と言ってるんだが。

APIってのは特定のプラットフォーム向けの物であって
C++の規格という一般的で汎用的なものにそんなものが混じり込んでるはずはない

>>449
普通にあるでしょ、exit の概念とか
ファイル名が DD name なのか DSN なのかとか

すまん。プログラム超初心者でう。
for　文について教えてくれないか・・・・

for　文の中に　また　for　文を作って　終わり記号（CでもVBでもなんでもいい）
を打ったんだけどさ。

中のfor文が１回　終わったあとに、外の　forを１回まわすのは、
どうしたらいい・・・

外の　for　が一階終わった後に　中の　for　が　回数上限まで回って、
外のforに制御がわたるんだよ。

for i 1++ <10
i = hoge + 1
for J 1++ <10
J = hote + 1
next
next
みたいになっちゃってんだよ。これをどうしたらいい？

とりあえずこのスレでやる話じゃない
ここはC++11の規格に関して語るスレ
VBの話ならVBのスレに行った方が良いよ

VB.NET質問スレ(Part37)
http://hibari.2ch.net/test/read.cgi/tech/1317448996/

breakとかcontinueとかをしらべるがよろし。

>>450
Java世代か？
C++以前のすげぇ初歩的な話だが、API(システムコール)ってのは、
OSやらミドルウェアと通信するために用意されてる最底辺の界面を言う。
APIの上位に築かれた関数群はAPIとは言わん。
ライブラリ関数を使わなくとも、外部システムとやりとりはできるが、
APIが存在しない場合は実質無理。APIをラップするライブラリ関数も作れない。

何かを利用する為のインタフェースは全部APIでしょ
別に最下層でないといけないわけではない
WebサービスAPIとか

iostreamもI/O用のAPIだよね

WebサービスAPIは、Webとのゲートだから間違っちゃ無い。
それにWebサービスAPIは、それ以上上位の機能は提供しないだろ。

だがiostreamはAPIじゃねえ。
iostreamはWriteFile、ReadFile、read、writeとかのAPIに
乗っかってるただのライブラリ。

Javaなんかは、そもそもAPIが無いのにVMとのAPIと称して
ライブラリとAPIの境がグダグダになってるけどな。

「いろんなAPIの定義があります」で良いではないか良いではないか
http://en.wikipedia.org/wiki/Application_programming_interface

>>452.453
ありがとなー

スレさえわからなかったんだよー。
ただ、制御構文を覚えるのが目的で、
Cにも行きたいからさ。
とりあえずVBにいってみるよ。

InterfaceじゃないのにAPIってのもなぁ

C++の規格的にAPIという語句はundefinedということでひとつ

APIという単語自体曖昧だからな

少なくともWin APIが台頭してた頃ははっきりしてたろ
OSへのアクセス手段 = API

スレッドだと green thread ってのもあるから、システムコールが無くても実装できるんですが。

attributeって結局pragmaと同程度の実装依存なのか？
カスタムattributeとか作れんのかね。関数がstatic変数を戻り値で返す場合、
参照で受け取ると警告出したりしたいんだけど。

attributeはもうほとんど存在意義が無いんだよね
finalとか全部キーワード・・・とは微妙に違うけど、そんな感じのになっちゃったし

従前では declarator 中のどの位置に置いた attribute が
何を修飾しているのかなどが曖昧であったり，コンパイラ間で差異ががあったりしたわけで，
そこの部分を統一して文法規則に組み入れたことだけでも十分に意味はあるのでは？
元々の proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf も
具体的な attribute の semantics に触れているのは10節においてだけで
ほとんどは attribute の syntax について議論しているわけで．

まあboostとかでマクロ定義するのが楽にはなるな

謹んでお悔やみ申し上げます。我々は、偉大な逸材を失った
ttp://tech.slashdot.org/story/11/10/13/0328230/dennis-ritchie-creator-of-c-programming-language-passed-away

携帯のストラップが死んだのかと思った。

スッポスッポは60歳だからまだまだこれからじゃきに
毛根は死んでるけど

そろそろ値型のWrapperが用意されてもいいだろうに、
いくつ規格を重ねれば登場するんだろう？
完全抽象化Classを親に持つWrapperがあれば、
0階Tensorの実装がスゲェ楽になるのに。

カーニハンは蟹飯ってあだながあるけど、リッチーはにちゃんねるでは何って呼ばれてんの？

立地ん。

リッチーはRPGみたなゲームでおなじみのアンデッド系キャラだよ。
つまり「スケルトン」「バンパイア」「ゾンビ」と同様に死んでいるけど
死んでない厄介なキャラだ。日本では【死神】と言われる場合が多い。

オビワン

リッチー
http://iphoneac.com/images/ff/ff113.jpg

なんか本の虫氏が「日本語の解説本なんて滅べ。そうすりゃプログラマは全員英語読めるようになる」
みたいな事書いてるんだけど、やっぱC++11本は英語で出版するみたいなことにはしないでおくれよ？
1万円くらいまでなら買う気だからさ。(´・ω・｀)

ちょっと厨二病をこじらせてるだけだから
ほっとけば治るよ

そのうちC++11の解説本が出て、翻訳も出るよ。
メイヤー先生のも結構いいし、増補版出すだろうし。

メイヤーさん C++11 本だすの？

今更だけど override は頭に書きたかったなあ
行頭で揃ってないといじいじする

>>480
出してもらわないと困る
C++11が出ると思って長い事C++本買ってないし

C++11の本出た所で、まだ準拠率99%超えの実装がないから仕方が無い・・・

だれか、禿に哀悼の意を伝える本を準備していろ。

こいつら欧米の技術ばかりをありがたがってパリサイ人の
解釈で得意になって想像力(あえて創造力とはいってない)
かけらもない糞ども全員死ね。


お前ら目障りなんだよ。さっさ消えろ

>>484
だれか一行にまとめて。

>>484最強伝説。

文句あるならてめーが純国産のプログラム言語を作りやがれ
てめーができないことを人に言うな

和算を廃止し、洋算を専ら用ふるべし
と明治政府も言っております

>>487
今使ってるコンピュータがですね、欧米産のノイマン型コンピュータなのですよ。
その理論だと、そこから自作するの？

国産とか何が嬉しいのか。ナショナリストなのか。ここはコスモポリタン(笑)のスレ。

生殺与奪を外国に握られているのはあまりいい事ではないな

じゃあ石油は使えないな。

>>484 くだらん書き込みでageるなカス

国産うれしいじゃん
政治的圧力で潰されたけど

自給可能なエネルギーがあるってのは強い事
アメリカはあれだけ戦争してるのもエネルギーのためで

明治ぐらいの時期にほとんどの外来語の対応翻訳日本語がつくられて日本語と英語の違いはあまりなくなっているのに
英語がすばらしいとか連呼しているC++本作者がいると聞いて飛んできました
http://turezurebana2009.blog62.fc2.com/blog-entry-53.html

>>496
前半はみんな興味ない話題だろうけど
後半に明治の時期に作られた新語「平和」の話がある

>>496
本の虫の人のことなら、あれは古文至上主義だろ
英語はできて当たり前っつってるだけで（俺はそうは思わんけど）
ブログ読んでないのに言うなよ・・・

>>489
ほう、おまえさんが使っているコンピュータが欧米の工場で生産されたロットなのか
そのことはプログラム言語の仕様とどう関係があるんだ？

>>499
スレチ
http://hibari.2ch.net/test/read.cgi/tech/1179424842/

まぁ新しめの概念とか和訳しにくにものは原語使った方が早いな

どうしたらそんなTYPOになんねや

さて、今回大規模に拡張したから
あと5年位したらやっぱり03と同じような
安定版というかマイナーバージョン的な規格が出るんだろうか。
11への本格的な乗り換えはその頃だろうな。

vectorの連続性を保証しておいて
data()メンバ関数を追加しなかった03か

えー。ただちにshared_ptrとscoped_ptrは使いたいし
ちょっと勘違いするくらいラムダ式を愛用していきたいよ・３・

あと、わりと便利に使えそうなローカル関数。
ローカルクラスのstatic関数より整理されてていい。

ローカル関数なんてないが
ラムダ式をそれっぽく使う事は可能だな

ポインタの解放忘れってそんな重要か？
ほんとにシビアなら循環参照も確保解放順番も考える必要があるし
そこまで考えてるならなくても書けるよ

scoped_ptrはboostや
unique_ptrや

言語間の単語の輸入はその概念を本当に理解してないと無理だからね
英語じゃないと伝えられないとか言っちゃう奴は理解力と論理構成力がイマイチなことが多い
ちょっと人より英語ができたくらいで俺って頭イイとか勘違っちゃうからこんなことになる
ニートにはニートの理由があるってことだな
高い授業料だと思ってあきらめたら？

毒電波の多い季節なのか？

ニートの独電波
http://www.suri.cs.okayama-u.ac.jp/~niitsuma/real-life-bot/index.htm

英語圏におけるラテン語からの翻訳などでも、優れた仕事は芸術とみなされる。
翻訳は常にクソとかいってるのはただの思考停止。

ttp://d.hatena.ne.jp/bsdhouse/20090816/1250446250

// 初期値
std::atomic<int> a(0), b(0);

// Thread 1
a.store(1, std::memory_order_release);

// Thread 2
b.store(1, std::memory_order_release);

// Thread 3
int r1 = a.load(std::memory_order_acquire);
int r2 = b.load(std::memory_order_acquire);

// Thread 4
int r3 = b.load(std::memory_order_acquire);
int r4 = a.load(std::memory_order_acquire);


r1 == 1 && r2 == 0 && r3 == 1 && r4 == 0
という実行結果は起こり得る。



信じられない
全部並び替えてみたけどそんな結果になる組み合わせなんかなかったよ

>>513
常にmemory_order_seq_cstだけ使え。
そうすりゃそんなこと考えなくて済む。

>>514
嫌な事、つらい事から目を逸らしてなかったことにするのは日本人の悪い癖ですよ

>>513
Thread 1/2での変更の結果はいつかはThread 3/4から見えるようになる。
ただしそれがいつかはわからないし、実際に処理が行われた順に見えるようになるわけでもない。
だから

a.store
b.store
(Thread 3でThread 1での変更結果が可視になる)
int r1 = a.load (== 1)
int r2 = b.load (== 0 Thread 2での変更結果はThread 3ではまだ不可視)
(Thread 3でThread 2での変更結果が可視になる)
(Thread 4でThread 2での変更結果が可視になる)
int r3 = b.load (== 1)
int r4 = a.load (== 0 Thread 1での変更結果はThread 4ではまだ不可視)
(Thread 4でThread 1での変更結果が可視になる)

ということは起こりえる。

>>516
その可視性っていうのが謎なんですけど
store/loadは排他して主記憶に書きこむ主記憶から読み込むという命令なんじゃないですか？
a.storeが成立した時点でメモリにはa=1と書きこまれていて
その後ほかのスレがどんなタイミングで見ようがそのメモリは1であると思うんだけど…
ああ、量子力学の波動性と粒子性の話を初めて聞いたとき以来の混乱だ

>>517
いつThread3/4がThread1/2より後に実行されると錯覚していた？

CPUにはそれぞれキャッシュというものがあってだな

>>518
3/4が先でもいいけどどっちにしろr1 == 1 && r2 == 0 && r3 == 1 && r4 == 0にはならないのでは？

int r1 = a.load (== 1) <- この時点でThread1は完了
int r2 = b.load (== 0) <- まだThread2は終わっていない
つまりr1=1,r2=0になるにはThread1->2の順番でないとならない

int r3 = b.load (== 1) <- Thread2は完了、もしr1=1,r2=0を満たすにはすでにThread1も終わってるはず（∵↑）つまりメモリにはa=1,b=1が書きこまれている
int r4 = a.load (== 0) <- Thread1,2両方終わってるのにメモリを読み込んだ値が1にならない？？？？

>>517
> store/loadは排他して主記憶に書きこむ主記憶から読み込むという命令なんじゃないですか？
違う。排他なんかしない。あくまでatomicityを保証するだけだ。

NUMAとかでは、あるメモリアドレスに対する書き込みが
異なるコアからは別のタイミングで見える、
なんてことは普通にある。

経験よりも歴史を信じるんだ！

つまり、自分のカンよりも先人の知恵の方が上ってことなのよ＾＾

>>520
1. Thread3とThread4の間には何の関係もない
2. Thread3から見て、Thread1とThread2はどちらが先に実行されるかわからない
3. Thread4から見ても、Thread1とThread2はどちらが先に実行されるかわからない

>>520の「つまりr1=1,r2=0になるには……」というのはThread3,4それぞれが互いに関係なく、Thread1,2との関係の上で決定するので
Thread3から見たときにThread1->Thread2の順で
Thread4から見たときにThread2->Thread1の順になる
という処理系が存在しないということを規格は保証できない

まあ結局自分の低能を棚に上げて
いやぁ〜日本語なんて意味ないわ〜やる気無くしちゃったなぁ〜
みんなボクくらいの英語力身につけるべきだよ（ﾁﾗｯﾁﾗｯ
ってことだからな
テメーはミサワかとｗ

ただの弱音だろうからほっといてやれよｗ
英語の規格や文献を調べてそれをまとめるような時間が増えると、
参考文献だけ紹介して同じもの読ませた方が誤解の余地無いんじゃね？とか思うんだろ。

きっと今もどこかの外人がC++11の本を英語で書いていて、同時に
どこかの日本人がC++11の本を日本語で書きながら英語圏の動向を気にしてて、
今このスレではスレッド間のデータの可視性を気にしてる。
ブンガクだね！

なんか脈絡の無いレスを付けるヤツが出てきたな。
何が言いたいのか解らんからコテハン付けてくれ。

http://www.suri.cs.okayama-u.ac.jp/servlets/APPLICATION.rkt
schemeからc++0xの自動生成

返値をdecltypdeで推定させるようにした。

SICPのコードを変換するとdecltypdeの中にlambdaがどうしても入ってしまう

>>523
そんな基地外みたいな動作するマシンがあるわけないだろ
お前の処理系壊れてるよ

NUMA始めそんな基地外みたいな動作する具体例はいくらでもあるかと

じゃあatomicはcacheにアクセスしてるのか

cacheをフラッシュさせてんじゃないの

昔使っていたccNUMA機だと、load linked/store conditionalでアクセスすればOKだった。
atomicさんの中身はほとんどこの類いだろう。

>>528の言う「気違いみたいな動作」しないのばかりだったのは、
cache coherence protocolでかっちり共有メモリの整合性保っていたいにしえの時代。
甘く見積もっても25年くらい前の話。

マジか最近のCPUって基地外ばっかりなのか
誰が得するためにそんな事になってんだ

なので結論は >>514 で良いかと

でもLockFreeとかWaitFree書くには必須技術なんだろ

lock-free/wait-free かどうかと sequentially consistent かどうかは
一般には独立した概念では？

memory_order_seq_cst以外のはよほど高速化が必要な場合のみってことか

>>535の言っているのは知らなきゃ書けないってことだろ。
どういう突っ込みなんだよ。

>>528
ほかの人が言ってるようにNUMAの計算機はThread3,4がそれぞれThread1,2の実行順序を互いにあべこべに観測する可能性がある。まぁそれはおいといて、
「Thread3から見たときにThread1->Thread2の順で
Thread4から見たときにThread2->Thread1の順になる
という処理系が存在する」ということも規格は保証しないよ
もちろん、「俺が持ってる処理系がそうである」ということも規格は保証しない

>>533
得をするのは計算機のユーザーだよ

とりあえずatomicならlong longを操作しても割り込まれて上位下位ビットが変になったりはしないんだろ
オレのような底辺にはそれだけわかれば十分だよ。ループ制御とか簡単な部分はatomicで、それ以外は安全重視でmutex使うし

>>538
いえ， lock-free/wait-free に関する話は
メモリオーダーに関する話を完全に脇に置いておいて
sequential consistency を前提にした上で議論できますし，
少なくとも lock-free/wait-free に関して最初に学ぶ段階では
実際そうすべきではないかと．

C++のmutexはメモリバリアを保証すんの？

「最初に学ぶ段階では」
付けてなかった限定を付けるタイプの詭弁ですね。

>>542
（実際にメモリバリアかどうかはともかく）
メモリバリアに相当する機能を持つことは保証されます

>>528
"write atomicity" でググれ。
海外のMLとかでも、未だにちょくちょく議論になることがある。

こんなの標準化しないほうが良かったのではないか
わかったつもりで書いた不良コードが世界中で量産されそうだ

お前もう何も書かなくてもいいよ。

デフォルトのmemory_order_seq_cstだけ使ってりゃ良いんだから
気にしなくて良い

でも気になる！

>>546
その意見も、ある意味もっともだ。

そもそもseq_cst以外のメモリバリアの存在意義はパフォーマンスだけなので、
seq_cstのオーバーヘッドが十分小さくなればそれ以外は不要になる。
だから、そうなるようにCPUメーカーに働きかけようぜ、って言ってる標準委員会メンバーも居る。

インテルがC++の都合だけで動くわけないだろ…

そこに高速化の余地があるなら環境依存性やリスクがあってもコンパイラやプログラマに選択する権利を与えるのがCの規格の方向性だ

まあC++らしいよね

>>552
ハードとソフトは相互依存とは言うが、そのうち、CPUはC Processing Unitの略だと勘違いする奴が出て来そうだな。

コンパイラでsec_cst以外を弾くオプションか強制するオプションが必要。仕様に入れとけ
バグだらけになってC++はクソ言語って悪評がつくぞ
そしてみんなC系列にうんざりしてD言語に移動する

Dも系列で言えばC系列だろ

>>555
＞仕様に入れとけ
これ言う人って、自分では提案する勇気もスキルも無いけど、誰かがやってくれたら、俺が主張していた事だって自慢するのかな？

>>557
ひねくれてんな
性格矯正おすすめするよ

C99と同じ運命になりそうだな。
実装された処理系がほとんど登場しないと・・・

ライブラリの要求は高いので空気にはならんだろうね。
constexprもrvalue関係もほぼ必須だし。

C99とは違ってVCがそれなりにやる気出してるから大丈夫だろ
まあVC11の実装は期待できないけど

そのやる気は変な方向に行ってるけどな
独自の文法を更に追加。
attributeとは何だったのか。

VC11出るん？

C++/CLIと共存させないといけないからか？

そりゃ当然あるだろう
MSの製品にするにはIDEごと対応表明せなあかんし

APIを全部Win FXに入れ替えて
アプリケーションはすべて仮想マシン上で動くものとし、
中間コードを優遇してネイティブコードを殲滅させるという
Microsoftの野望は潰えたの？

ネイティブコードが滅んだらC++なんて存在意義なくなっちゃうよねきっと。
おお、キッド。やぁ、マイケル。そんなことナイト2000。

滅ぶわけないからその仮定は無意味

プログラム板って煽りが多すぎて全然楽しくない

おまえにきにいってもらおうとはおもわん

普通は楽しもうと思ったら、話題を提供するか、金を払うかくらいじゃないの？

他の板ではIDがつくから、イヤならすぐにけせるね

＞C++なんて存在意義なくなっちゃう
「Windowsにおいては」という限定をつけたらどうだろう？
セキュリティ強化のためにアプリケーションはすべて仮想マシン上でという
発想が本当に実現したとするなら、アンマネージドなコードを書けなくなるので
その環境ではC++の利点性は大幅に激安になると思いに蹴りな久かたに。

仮想マシンが普及したところで、C++が無くなるつうのも微妙だ。
使える仮想環境が一番多い言語は実の所C++だし。
.Netでも動けばLLVMでも動く。
仮想環境に乗るわけではないが、Java VM に接続し、
クラスライブラリを使うこともできる。

環境毎にコンパイルするの面倒だし
マルチOS対応ならJavaが楽だ

C++は速度が必要なケースで生きのこる

そんなシビアに速度が要求されるような
システムなんて、ほとんどのヤツが開発
したことないくせに、みんなエラそうだな。

>>575
ワロス

>>574
Java のライブラリ使って書けば？
C++のテンプレート使えると、生産性が違うぞ。

みんなgccからclangに移行してやがてObjectiveC++へ・・・とか
まあVCは関係ないけど

gccもclangもその辺の立ち位置は変わらん。

>>572
Singularityにおいては ならあり得る
あれはドライバも大半がC#で書かれてたし

>>575
使ってっから言ってんだよ

>>581
何だ、ただのユーザーか
開発しているわけでもないのに偉そうだな

？

速度を要求されないプログラマなどいない。
要求されてない奴はプログラマとは呼べない。

好きにしろ

C++よりCが速くなる場合ってどんな場合なんだろ

>>586
ほとんどの場合だろ
今は体感できないけど、昔はオブジェクト指向は遅いって理由でCを使い続けるってのは良くあったらしい

あとはその時提供されているC++の実装が、Cの実装に比べて遅かったりとか。
ちょうど今タイミングよくRaymond Chenが似たようなこと言ってるけど。
http://blogs.msdn.com/b/oldnewthing/archive/2011/10/24/10229097.aspx

>>587
昔の話だ。

>>587
C++よりCの方が早い、という意見はよく見かけるけど、単純な数値計算じゃなくて、C++のアルゴリズム相当のものを自作した場合でも成り立つんだろうか？

>>590
単純な数値計算なら同じだろうし、C++の<algorithm>に明示的特殊化の可能性まで含めれば
Cより遅くなる理由は無い。

ところでスレ違いじゃないか？

>>588
実行速度の話してなくね？

>>592
あまり使われない関数を同じページに押しこむとかのトリックが、当時のC++コンパイラーではうまくできなかった。
もちろん、断っているように、規格じゃなくて実装の話。

今Cを使う理由はMISRA Cみたいにシビアに安全性が求められる場合じゃないの
速度面だとケースバイケースじゃん。qsortよりstd::sortの方が速いし

>>594
＞qsortよりstd::sortの方が速いし
そりゃ、関数ポインタ経由のコールを乱発する qsort() よりもインラインで展開する std::qsort の方が速いに決まってます。
テンプレートをはじめとするインライン展開/メタプログラミングを活用するのなら C よりも早くなります。サイズもでかくなりますが。

あのコピペを貼って欲しいのか
Cでもマクロ使えば良いだけだろ

std::qsort

マクロは名前の汚染度や安全性を考えると実用には耐えられないね。見苦しい

>>596
そういやなんでPreprocessor-Templateのqsortを標準化しなかったんだろうな

見苦しいと思い込んでるだけ

>>595
比較にインライン関数や関数オブジェクトでなく関数ポインタを指定した場合でも std::sort()
の方が速いです
データの移動が発生する時、std::sort() は operator =() を呼び出すので CPU のワード長で
コピーが行われたりしますが、qsort() 内部のコピー関数はコピー対象のサイズをあらかじめ
知らないので （コンパイル済みなので） 最適化できず、qsort() 呼び出しで指定されたサイズ
をもとにループで 1 バイトずつコピーするからです
また、オブジェクトをコピーする場合に qsort() はコンストラクタやデストラクタを呼ばない
のでデータが壊滅するおそれもあるので、std::sort() を使いましょう

どうせ書くならここまで書け

アホかそんな訳あるか
qsortの第三引数は何なんだよ

POD配列のソートならmemcpyを使うから大体qsortの方が早い

g++ 4.6.1@i7 では qsort のほうが速かった

ケースバイケースってことで

memcpyが速い環境ならstd::is_podでもなんでも使って特殊化してくれればいいんだけど
それくらいコンパイラが最適化して欲しいな

一要素のサイズが大きい→qsort
一要素のサイズが小さい→std::sort

こんな感じか

C++0xになったらmoveするからちょっぱやだな

moveできるような中身ならな・・・

添え字かポインタで事前ソートしろ

要素のサイズが大きい場合は普通は間接ソートするか

・vectorとかnewの使用を抑え極力自動変数を使う
・仮想関数と同時に同等のテンプレートを用意
この2点を守ってる限りじゃCより遅くなる事はないな。
Cでも同じ事をしようとすれば、同じアルゴリズムを
生成するコードを書かざるおえん。

そりゃおえんなあ

式テンプレートみたいなテクニックがあるからC++が速度でもCに負ける日は永遠に来ない

>>613
注意して書けばな...
むやみに new すると,
キャッシュやページテーブル意識して書いた C の半分以下ののスピード性能になる

式テンプレートはコードが難解になるから嫌だ。
そりゃあ、ベクトルの演算程度ならかわいいもんよ。

だが、行列乗算を式テンプレートでコーディングすると呪文の世界が。
それに100×100の行列乗算をやると、いつコンパイルが終わるかわからん。

面白いけど、意外と使い道のないテクニックだと思う。

書けはするだろが、自分で書かないだろ。
Blits++とかublasとかおとなしく使えばいい。

>>614
newなんてそれほど使わなくないか？
大抵自動変数かコンテナで済むだろ。

ラムダ式の名前空間の話なんですが…

int main() {
using namespace std;
[](){ std::cout; }
}

のように、ラムダ式内のcoutにはstd::修飾が必要になるんですが
これはラムダ式の本文内のスコープがmain関数の内側にないってことですよね？
じゃあどこにあるんでしょう。ほわわん。

>>618
ttp://ideone.com/OFro6
includeしてないとかそういうオチか？

まずはコンパイラを示すんだ

すいません、くそVisual C++2010です。
くそVisual C++2010のくそ仕様なんでしょうか…

くそ言うな
くそに謝れ

VC++2010は準拠率かなり低いから仕方が無い

>>621
こいつは何を言っているんだ？
そもそも>>618でコンパイルエラーなんだが

シンタックスエラーはともかくとして>>618では動くね。
以下のようにすると「定義されていない識別子です」と出た。

http://ideone.com/TkIjz
(打ち込み途中で setw を削ったので iomanip ヘッダは余計だった;;）

VCはC++11だけでなくテンプレートの準拠度も低いので
それでエラーになっているような気がする。
ちなみに「拡張子を無効にする」 /Za オプションつけてもだめだった。。

C++11が正式になる前に作られたんだからそれに関して準拠度が低いのは仕方ない

つか正式リリースする前につくるなよ。
またVC6,0の悲劇を繰り返す気か。

そんなこと言ったらgccだって作ってただろ

仕様・実装・利用の3者に時間差があるのは止むを得ない。
クラシックモードがあれば移行の時間稼ぎは出来る。

理不尽なクレームを付けられるのは毎度のこととはいえMSも大変だな。

>>628
gccは頻繁に更新あるけど
VCはそんなのないだろ

VC++がMS内のスケジュール優先になるのは仕方ないんじゃないの?
MS内のdev系が全部引き摺られてアップデイトしていくわけだし、
WG21のスケジュールに合わせてられないでしょ。

オプションで使えるようにして保証外みたい形にして実装するならいいと思うが
デフォルトで中途半端なC++11が使えるのはよろしくない
gccでも-std=c++0xないと使えないってのに

>>477
英語で読むなら他に選択肢はあるしな。

英語が出来る頭があるなら、
プログラマなんて底辺職業、やってない

会話は無理目でもドキュメントの概要掴む位はできてくれないと
コンパイラのエラーメッセージすら読めないバカとかたまにいるからな

>>636
コンパイルエラーぐらい、日本語で表示されるだろ。

>>636
あれ読んでる奴いるのか？
クリックしてジャンプしてるだけだろ？

>>635
じゃあ英国人や米国人は全員セレブか
じゃあGoogleやMicrosoftのプログラマは底辺か

おまえが底辺なだけ。

>>638
涙拭けよ

>>638
さすがにそれはない
すぐ分かるエラーならともかく

構文エラーとかはエラー読むよりも飛んだほうが早いな。
エラークリックして、何がエラーかわからんときはエラーメッセージ読むなぁ。

>>634,639,640
くだらん書き込みでageるなカス

>>643
くだらん書き込みはお前のだ。

どっちーもーどっちー。

テンプレートのエラーメッセージは泣きたくなる

デフォルトで変数constのコンパイルオプションとライブラリ用の仕組み設定してくんないかな
時既に遅しっぽいけど

const namespace hoge{

int a; //const
const int b; //const
mutable int c; //non-const

}

うん、ないな

テンプレートエラーなら読んだほうが寧ろ速いよな。

やはりコンセプトが必要だな。

コンセプト欲しいねー　　本当、心待ち

no concept no life

うむ。conceptsは確かにイイ物だが
HTMLのCSS様にc++のヘッダ・ソースコードとは離れた言語外定義ファイル方式にして
「どうしてもイジリたい奴だけイジれ」みたいな
とにかく面倒じゃないやりかたにして欲しいね

はあ？

CSS？どゆこと？

XMLのDTDのようなものを定義できるといいなー。ってかんじか？

@[ExampleType:<int,long,{void} FunctionA>,<const char*,{size_t},FunctionB>]
とか定義すんのか。何の意味があるんだキモイだけだろ。

C++自体キモカワイイのが売りだしー

可愛くはない

可愛いと思ってるのは単なる錯覚でそれはキモいC++を使いこなせるという虚栄心からくるもの。

そういう感覚的な感情が必要なのかと・・・。

C++みたいなキモい言語に対する虚栄心は大体において
構文規則の複雑さを理解したという感情からくるものだと思うけどな。

複雑じゃないだろ
そういう意味ではperlとかのほうがよっぽどキモいわ

Perlは内向きのキモさというか、キモさを工夫してもキモレベルが人に伝わりづらいのに対して
C++は頑張れば頑張っただけキモくなるし天井知らずでオエッてくるコードが書ける利点がある

地味な女の子に変な性癖をつけるような達成感がある

とりあえず template はなんとかならんのか

どうなって欲しいんだ？

TMPのような無理矢理感のある方法じゃなくてメタプログラミングのための記述を新たに仕様に入れろってことだろ
template<class T> class X {
if(is_pointer(T)) typedef remove_pointer(T) value_type ;
else typedef T value_type ;
private:
value_type v_ ;
...

みたいな

Template Aliasesは欲しい。

const_exprじゃだめなんか？

operator定義のダルさを何とかして欲しいのはあるな

>>670
型の計算できんの？

ところで、暗黙のムーブコンストラクタ・ムーブ代入演算子って
どうなったか、ご存知の方います？

最後まで揺れていたみたいだけど、どういう条件で
暗黙に作られたり、作られなかったりするんだろ

コピーコンストラクタ・コピー代入演算子との兼ね合いはどうなんでしょうか

どれだけ時代遅れだよ。
ユーザー定義のコピーがあれば暗黙のムーブは生成されない。
ちなみに、ユーザー定義のムーブがあれば、暗黙のコピーは生成されるが、この挙動はdeprecatedになった。
つまり頼るなってことだ。

ちょっと先に情報を仕入れただけのにわかが俺スゲーってスレなのかな？

自分で調べる気のないバカが聞きに来るスレです

聞く奴いなくなったらお前も物足りないのだろう？

伸びる奴はあらゆる手段（書籍、人、ネット、BBS、他）を使って貪欲に素早やく知識を獲得する。

チンタラと「自分で調べる気」になっていつまでも調べられない愚図はいらない。

即レスした癖に
質問待ってるんだろ、素直になれよ

ま、ぶっちゃけ人柱やるよりもうちょい情報がまとまってから調べ始めたほうが効率いいしな
あせってやるほどのことでもないし

こんなスレにいるみなさんは十分意識高いですし
そこは認めたうえで殴り合ってください

とりあえず、C++11のJIS規格票が出たら買うくらいはする。

11に間に合うのか

背に腹は代えられんが、しかしもう少し安くならんかな

ttp://journal.mycom.co.jp/news/2011/11/04/014/index.html
なるほどね

ローカル変数が、autoだらけになる訳か。B言語に回帰したみたいで胸が熱くなるな。

可能な限り auto は反対だな
型が分かりにくくなる
型が大体想像できるイテレータとか
そういうのに限らないと読めたもんじゃないと思う

ハンガリー人登場

いやいや、特に整数型の式とか、
汎整数昇格やら何やら細かい規則があってややこしいんだぜ

> Bjarne Stroustrup氏の記事「Elements of Modern C++ Style」

いやいや

Integral typeだけやん

＞可能な限り従来のポインタとdeleteではなくスマートポインタを使うべき

これやるくらいならJava使ったほうがよくね？

何でよ

Javaのガベージコレクションは高度な遅延処理を含み軽量かつ高速で安全だからじゃないの？
ほとんどのイカしたC++プログラマはJavaレベルのメモリ管理なんて屁でもないけど
ほとんどのイカれたC++プログラマはまともにメモリ管理できないから。

C++でメモリを正しく扱えるようになるころにはイカレてるから問題ない

>690
サッターさん涙目w

なんでJavaを持ち出すのか分からん
Javaを使った方がいい場面なら勝手に使えばいい

スマポ使うことを「これくらいやる」とか言ってる時点でおかしいだろ
生ポを正しく使う方が難しい。というかミスを防げないんだから

スマポはスマポで、循環参照というミスはあるけどね

循環なんて設計段階でわかるだろカス
知的障害の有るメンバが混じってるプロジェクト以外でスマポの循環が問題になったなんて事例は
いままで世界で一度も発生してないという事実を認識しろ

スマポの問題じゃなくてshared_ptrで起こり得る問題だろ
優先すべきはunique_ptr。共有したいときにshared_ptrの出番。
循環参照のためにweak_ptrもあるし。

というか生ポとの比較関係ねぇしｗ

unique_ptrとshared_ptrでdeleterの指定の仕方が違うとかなめてんの？

違って当然だろ

>>699
COM使ってて循環参照や生ポで受けてリークしてる例は何度も見てる
スマポ知らない人がスマポ使われてるプロジェクトに投入されるとよくある事

>>687
OOPLで型が目に見えなきゃならん理由が解からん。
OOの概念からすりゃ型を意識しなきゃいけないのは悪だ。
型チェックは別に型が目に見えなくてもできる。
大体、テンプレートだって実際どの型が割り当てられるかなんて気にせず書いてる。

じゃあ動的型言語でも使えばいいだろ
Dart（笑）でもやってろよ
C++の利点は静的型と生ポを扱えることなのに、それを否定してるだけに見える

>>705
こいつ最高にアホ

くだらないことでケンカするなよ。
結局似たようなこと言ってんのに字面の違いで言い合いするなんて不毛だ。

>>705
動的型言語じゃ型チェックできないだろバカじゃねぇの
目でみえることと、型安全は別

C++見たいな静的言語でも、any/function/bind/lambda使ってるとほとんど動的言語みたいだよなあ。
JavaScriptとかと比べてできないことってあとなにがあるんだったっけ？

まあevalで実行時にソース評価とかはできないか・・

そのへんは型消去してるから動的だろ

結局メンバ変数や引数にはauto使えないんだし、
autoを濫用すると「あれ？　この値こいつに入れられるのか？」とか分かりにくくなる

ここでハンガリー人登場

頼りきらず無視もせず適切に使う
C系列の原則だろ

C#のvarってどのくらい使われてんの

ここで聞くことか？

autoの参考になるじゃん

そうだね
でも、もう一度聞くぞ？
ここで聞くことか？

>>710
別に消えてないし、コンパイル時に決定してるから動的とは言わないだろ

>>711
コンパイルエラーなり、エディタの補助ですぐ解るがな。

>>709
関数をthisのマップに自動で詰め込む。
this["関数名"](・・・);で、いつでもスコープに所属する関数を呼び出せる。
C++もOSの力とマングリング関数を使えば完全に不可能でもないけどね。

>>717
ここで聞くこと

>>719
ﾏﾝﾄﾞｸｾ

>>721
そうか、C#スレで聞くよりも回答確率は大分低いだろうが、まあガンガレ

動的型/静的型
型推論による型特定/明示的型指定

この２つの軸を混同している人がいるね。

>>720
ああそうね。メンバ関数の実行時追加とかは無理か

>>718
消えてるよ
静的型でラップしてるから消えてないように見えるだけ

anyは型を消してるというのかねぇ。内部では持ってるわけだし。

struct X {};
struct A : X {};
struct B : X {};
X * p = new A;
これだけでもうpから静的な型情報を取り出せないよanyも同じ

>>726
少なくとも動的ではないな。
動的言語なら実行時に無視なり、エラーになる。

id object;
object = @"message";
[object isEqualToString: @"message"];

object = [ [NSError alloc] new ];
[object isEqualToString: @"message"];//無視

間違えた、動的言語じゃない、動的型付け言語だった。

>>728
anyは代入した型の型情報を保持してるでしょ

>>729
> alloc] new ];

酷いねコレ

>>731
動的にな

>>732
initだわ間違えた。

>>733
コンパイル時じゃね？

C++闇の軍団って何ですか？

もう恥ずかしいからそういうのよそうよ

>>735
ちげーよ
出来るってんならanyからコンパイル時に元の形を得るメタ関数作ってみろや

anyはややこしいことに、内部にValueTypeを保持してるが外側からはコンパイル時には扱えないので
どちらも正解と言える

TMPはキモイ構文になりがちなので
メタ関数を普通の関数と同じように書けるようにしてほしいなぁ。

typename add_const(typename T)
{
return const T;
}
typename remove_const(const typename T)
{
return T;
}

constexprができたんだから、typenameだってできるだろう。

autoは出来るだけ使うようにしてるな
置き換えてみればわかるけどautoで意味がわからなくなるようなら設計が悪い

馬鹿長い変数名じゃないと意味がわからなくなるのは設計が悪い。変数名はvar+番号にせよ
auto信者の言ってることはこういうマヌケなことと本質的に同じだと気がついてくれ

そもそもautoでややこしくなると思うなら、auto使わなければいい。
悪いスタイルで書けることを、必要以上に恐れないのがC系言語の設計。

「型チェックしたいなー」ってところでは型を指定し、
「別にそうでもないなー」ってところでは型推論に任せてる

autoなら意図していない型変換が起こらないから安全

class foo {};
class bar : public foo {};
bar func() ;


auto x = func(); // Good!
foo y = func(); // 実はbarとfooを間違えているのたけど警告すらでない！世界は崩壊する！

こういうスタイルでコーディングできることもC++の強みのひとつになる
俺はJavaを使うようなスタイルでC++を使っている

派生クラスの値返し自体稀じゃね

全然稀じゃないだろ

大抵はポインタ、スマポ、参照のどれかだな
基底クラスの存在感が希薄なクラスくらいならあるかもしれない

普通はそもそもコピーコンストラクタが滅多に動かないように作るもんじゃね？
数値様クラスくらいならいいけども、
大抵複製考えるの面倒くさいか不可能なケースがほとんどで

struct hoge_: ncopy {
void hello(void);
};

struct hoge {
hoge(void) : p_(new hoge_()) {}
inline void hello(void) { p_->hello(); }
private:
SP<hoge_> p_;
};

めんどくさいから小さいクラスとボトルネック以外はこれでお茶を濁す

>>742
違うと思うなぁ。極論を出して本質とは言わんで欲しい。

>>742
TMPLやlambda使ってればautoは必要だと感じると思うようになる。

必要以上に型を気にするのは無駄なことだと理解できたら一人前

その「必要」がどのラインかを見極められたら一人前。
現実の問題ってのはトレードオフの集合体。 こうすればすべて解決なんて方法は無い。

正しいロジックを書けば勝手に型が合う物だよ。だからautoに渡しておけばいい。
間違ったロジックをかけばどこかで型の矛盾が生じてエラーになる。下手に不正確な型を書くと変なところでエラーが起きて解りにくくなる。

てか、autoの弊害が思い付かない

autoのデメリットは後で見た人がストレスで禿げることかな

>>738
anyはany_castが必要な時点で動的じゃねぇよ。
言うなりゃ片安全で多機能なvoid*。

//TypeAとTypeBは繋がりなし
boost::any any;
any = TypeA();
any->Function();
any = TypeB();
any->Function();

本当に動的型付ならダックタイプができなきゃならん。
動的片付けじゃないから、実行時に型情報から
関数情報のルックアップができない。

void *の時点でどう見ても動的です。お疲れ様です

void*が動的とか・・・

>>759
void *だと実行時にメタ処理が走らないだろ。
コンパイル時にしているメタ処理が実行時に走るから動的っていうんだぞ。
お前の動的って何を根拠に言ってんだ？

コンパイル時に型が決まっていないこと

型は決まってるだろ型は

え？

void*に突っ込もうが、anyに突っ込もうが型は決まってるわな。
castしなきゃ正体が見えないだけで。castすりゃ動的言語ならCだって動的言語だわw

Cは動的言語ってことで。

voidポを動的とかいうレベルのヤツがC++11スレにいるのか
そのレベルでこのスレ開いちゃいかんだろ、恐ろしいな・・・

動的言語と動的型付けを混同してる人がいる
ちゃんと区別してないと話かみ合わないぞ

>>767
レベルとか云々以前にコミュ障じゃね。
技術文書にも書かれてないオレオレ定義主張してんだから。

>>765
anyはコンパイル時に型が決まる。だから静的。
void*に突っ込まれる型はコンパイル時には決まらない。だから動的。

恐らくお前はanyの動作を勘違いしている。

それで、いつになたらanyから元の型を取り出すメタ関数を見せてくれるんだ？
静的型を持ってるなら簡単なことだろう？はやくしてくれ

>>771
動的言語ではないので無理です。

>>770 void *はメモリブロックの位置を指してるだけで型情報なんにも知らないでしょ。
動的だって言うんなら、void *型からキャスト無しでメンバーにアクセスしたり、
四則演算ができたりする必要がある。動的型付けなら当然のように出来ること。
動的型付だと実行時にvoid *に当たるハンドルが実際の型情報を取り出し、
自動で演算子やメソッドを割り当てるからね。

そういや、VariantというC++で無理やり動的型付けした仕組みがあったな。

>>768
動的言語ってのは実行時に
型を定義できたりするアレだろ

if binding
    require "module.m"
end

// bindingがfalseなら型未定義でエラー
Plugin.new()

>>774
ごく初期、禿は懐疑的な態度で臨んだアレか

>770
型消去とかType Erasureで検索するよろし。

そういや昔boost::any用のマルチメソッド実装したなあ。便利だけど遅かった……

C言語が別名カメレオン言語と呼ばれている理由がわかりました

auto a = true ? [](){} : [](){};
これができないのは仕様ですか?
それともVS2010の仕様ですか?

void b(){}
void c(){}
auto a = true ? b : c;
これならできるのに、関数ポインタがラムダで置き換えできない。

vs2010の仕様

おまえらソースくらい読めよ。anyの型解決は
typeid(ValueType)
だよ。よってコンパイル時に決定してる。

RTTI(runtime type information)

思いのほかスレ住人のレベルが低いのなww

any=動的厨はほっとこうや。
話が通じず困るのは本人なんだし。

int a = nullptr; // エラー
bool a = nullptr; // ok

boolさんがおかしい

>>784
話通じてないのは静的厨だろｗｗｗ

>>779
lambdaの結果が同じ型にならなきゃエラーになるんじゃないの？
function でラップすれば良くないか？

>>785
nullptrはnullptr_t型の値であり、nullptr_t型は任意のポインタ型に暗黙返還できて、ポインタ型はbool型に暗黙変換できる。

>>788
ただしくは、nullptr_t型の値から直接bool型の値falseに変換できる。

誰得仕様やな
そんなこと出来ないほうが自然だ

ifでnullptrをfalse扱いにする場合とかね

if(ptr)って書いてる？
if(ptr == nullptr)って書いてる？

ああこれじゃ意味逆か
まあいいか

自分は明示的に、
if(Ptr == nullptr)/*do*/
って書くかな。

>>792
前者だな。有効/無効と解釈できるから
後者は間違えやすいから。c#だと後者しか書けなくてはまる

おれも前者だな。
ポインタとoptionalで同じように書きたいが
boost::optionalとnullptrの比較はなんかアレだ。

>>790
テンプレート用。

>>779
あらゆるラムダ式はお互いに型が違ってて（たとえ定義の形が同じでも）、暗黙変換も出来ないから仕様

前者だとnullptrである必要がないじゃん
それはNULLでしょって話
nullptrというキーワードを新設したのになんでこんなことやったんだか

後者は、NULLの実行値が変わっても大丈夫ということで使ってるなぁ。
まー、杞憂なんだろうけど。

>>799
NULLの定義を見てごらん
整数の０と明確に区別出来るようになったでしょ。

>>800
前者でも問題ないね

問題があるかないかという話じゃないだろ

decltype( template_arg ) pointer = nullptr; //テンプレート引数が整数だとエラーに出来る

>>803
>>800 の論点はそこだぞ

実際に杞憂だけど

>>788
なんでstd空間に定義してるのに _t ついてんだろうな。
型だけならnullpointerで良かったろうに。
あと本体もstd::nullptrじゃなくstd::nullじゃダメだったんだろか.。

せっかくだから予約語にしたいけどいまさら null を追加なんてしたら衝突するから無理
ググったら nullptr なんて名前使ってるやつほとんどいないし短いからこれでいいや
型名は typedef decltype(nullptr) nullptr_t; ってことで _t 付けとけばいいな

そんなかんじ

typedef型に_tをつけるのは命名規則だから仕方が無い

value_typeとかもvalue_tにすればよかったのに

標準の命名センスが皆無なのは仕様

そこがいい

>>807
ライブラリじゃなく予約語になったんだっけ？

struct nullptr_t
{

template<typename T>
operator T*() const
{
return 0;
}

} nullptr;

c+03で実装するとしたらこんな感じ?

>>813
bool変換とか*とか->とか

C++03では完全な nullptr を作れない
一応 nullptr イディオムはすでに存在する
ttp://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

メンバへのポインタが抜けてたか。


operator boolはどう使うんだ?

if(nullptr)
とか?

void hoge(bool flag){}
hoge(nullptr);
とか?

falseを書く所に使うとしたら、間違った使い方としか思えないんだがw


NULLは (void*)0 ただし、他のどのポインタにも暗黙に変換できる
というCでの定義を考えると、*と->はイランのじゃないか?

> *と->はイランのじゃないか?
いらんな。nullptr自身はポインタ型ではないからな

>>816
> if(nullptr)

言いたいことは分かるけど、こんなコードはないだろw

>>818
マクロの出番だな。

ポインタ変数をboolに変換することはあっても
nullptrは定数なんだから、falseになるのは当たり前なんだし
最初っからfalseって書けよって話だと思うんだが
ほかにnullptrのbool変換が必要な理由があるのか?

template <typename Pointer>
void function(Pointer p) {
if (p) {
}
}

長いことnullptrのbool変換は出来なかったんだけど
他のポインタではよく使う変換だしあえて禁止する理由なくね？
というような経緯だったと思う

T<NULL>の悪夢さようなら

それならint変換も禁止する必要なくね？

それやったら本物の0と同じになってまう

templateやマクロによってif(nullptr)になってしまった場合は
C++03のstructでoperator bool(){return false;}と
するより、最適化で消えてくれる可能性が高くなるのかな。

int main(int c,char**v){
　　auto int i = 0;
　　register auto j = 0;
　　return 0;
}

gcc-4.5.3 ./auto-auto-test.cpp
./auto-auto-test.cpp:4:15: error: ‘j’ does not name a type

gcc-4.5.3 -std=c++0x ./auto-auto-test.cpp
./auto-auto-test.cpp:3:10: error: two or more data types in declaration of ‘i’

旧autoキーワードそのものが消えたのか。

キーワードのままです。

ほら、うつ病、統合失調症予備軍団がこれだけぞくぞくと。
何で、イチイチこだわらなくちゃいけないの？会社辞めたら？






数年後にここのスレに書き込んでいる奴の２〜３割が自殺。

>>829
やんでるから病院言ってSIRIもらってこい

ふーん、お前それを飲んでるんだ。

ま、自殺しないようになｗ

放射能とTPPのダブルパンチで底辺PGなんてマジで３割ぐらい死んでるかおなｗｗｗ

配列リテラルって結局規格なの？
こういうやつ

(int[]){10, 20, 30};

規格だよ

>>792
後者。真偽値はちゃんと区別したい。

VCで使える明示的オーバーライド(親クラス毎に関数の実装を選べる)って
規格じゃなくてVCの拡張だよね

C++/CLIじゃなかったかそれ

かもしれないけど、CLIを使うオプション入れなくても使える。
あと、ググると別の明示的オーバーライドが出てくるから
誤解してるかもしれない。ここでいってるはこんなヤツ。

struct Derived:public Base1,public Base2
{
      int Base1::Override(){}
      int Base2::Override(){}
};

>>829,831 くだらん書き込みでageるなカス

>>833
compound literalというC99の規格だけどC++の規格ではない

いらねー規格はぽんぽこ追加するのに
便利な規格は見送るんだよな標準委員会って馬鹿なんじゃね？

http://msdn.microsoft.com/library/ksek8777
Managed C++ 時代の名残だな
同様に for each が使える割には Range-based for がVC11でも実装されないらしい

M$はどうしてそんなやる気ないの？

C丼があるから

多分過去の遺産のためにC++維持しようとしてるだけで、
もう新規開発は期待してないんじゃないの？
自社の所有コードを保守できればいいみたいな。

VC11ではC++/CXの実装で忙しいんじゃないか

優位を保てなければルールを変えてしまえって社訓だから
規格のポチをやるかどうかは気まぐれなんだよ

迷惑な連中だな

VC++を冷遇してもMinGWとかに流れてC#には流れることはないんじゃないかな。
最適化のレベルはどっちが上なのかな？

どっちもどっち。MinGW（っていうかGCC）はUnicode対応がクソ過ぎ。

ダントツでVC。コンパイラの正式名称もMicrosoft Optimize Compilerというだけあって
DLLの中までインライン展開するしレジスタの使い分けやコードのならび換えが半端ない。

UnicodeがじゃなくてUTF-16がじゃないのか？

>>851
DLL でインラインて、そんなに特殊なことか？

>>843
Microsoftが必要としているのはWindowsとかの自分たちで用意した環境上でだけ動けば良いプログラムを作るための道具であって
C++でプログラムを作るための汎用的な道具ではないから。

>>853
クロスプラットフォームなコンパイラじゃできないでしょ。
多分clangがWindowsに移植された場合もできないだろうし。

>>855
え？　え？　クロスプラットフォーム？？？　余計わけわかめ

WindowsもJavaもXMLもUTF-16の時代だから。

>>856
クロスコンパイル知ってる？

今時UTF-16メインでつかってんのって、
WindowsとJavaぐらいじゃね。他のOSはUTF-8ベースだし、
Web関係のデータも大概UTF-8。DBもUTF-8サポート謳ってんのばっか。
XMLもUTF-16使ってんのは見たこと無いな。

あっぽれはUTF-32じゃないの？詳しくは知らないけど。

UTF-8は1バイトしか使わないコードページでは
実際1バイトのコストで文字処理できるから、
一番合理的だと個人的には思う。愛していきたい。

Appleは変則UTF-8

VC++もクロスコンパイラだぞ
x86もx64もいける

XMLはDOMがUTF-16だった経緯があるから。

>>862
Windowsでしか動かんがな
せめてPE以外を吐けるようになってから言え

>>863
デフォルトは有るだろうけど
XMLは別にエンコード固定じゃないだろ

>>865
デフォルトの話じゃないんだよなあ。
libxml2がUTF-8なんで正規のXMLパーサーを名乗れなかったりとかいろいろ
有ったんだけど。

？

<?xml version="1.0" encoding="UTF-8"?>

ほんとめんどくさい人だな。
プログラム技術板なんだから、もう少し自分で調べるとかしなよ。
ほれ。

http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-C74D1578

Document Object Model (DOM) Level 1 Specification
                          Version 1.0
      W3C Recommendation 1 October, 1998
http://www.w3.org/TR/REC-DOM-Level-1/cover.html
これってDOMの仕様じゃん

Extensible Markup Language (XML) 1.0 (Fifth Edition)
　　　W3C Recommendation 26 November 2008
http://www.w3.org/TR/2008/REC-xml-20081126/#charencoding
XMLはこっち

XMLプロセッサはUTF-8とUTF-16の対応のみ求められるってさ。
> Each external parsed entity in an XML document may use a different encoding for its characters.
> All XML processors must be able to read entities in both the UTF-8 and UTF-16 encodings.
> The terms "UTF-8" and "UTF-16" in this specification do not apply to related character encodings,
> including but not limited to UTF-16BE, UTF-16LE, or CESU-8.

>>869
もともとDOMの話だろ。
ほんとにめんどくさい人だなあ。

>>870
ああそうなの。>>857 見て書いたから知らんかったわ。

>>871
ああそうかい、とっても恥ずかしい>>865はお前じゃないわけね。
なおさら恥ずかしいやつだと思ったわ。

みっともないやつだなあ。

で、基本的なことを聞きたいんだけど、UTF-8 は char と wchar_t のどっちであつかったらいいの？('∀`)

>>863
これを見てDOMのエンコードについて話してると思う人は居ないと思うが・・・。
DOMがUTF-16向けだからXMLもUTF-16が仕様なんだと言いたいように見える。

>>873
wchar_tかcharかと言えば、char。
理屈上別にintに突っ込んでも構わんけど。

>>875
ありがとん。
char s[] = "UTF-8エンコードな文字列";
cout.imbue( locale( "Japanese_Japan.65001" ) );
cout << s;
みたいなんでいけるんかな、実験してみよう…。

>>865 って別にDOMのエンコードがどうのとか言ってなくね？

>>865にDOMなんて書いてねーよな？

たしかに>>865には一言もDOMと書いてない
あれを見てDOMの話だと分かるやつはいない

私にも>>865がDOMの話だとは分かりませんでした。

半年DOMってろ

>>866
お前もXMLパーサー言っとるがな

>>866
お前最悪だな

>>866
>>866
>>866
>>866
>>866
>>866

>>872

このレスさえつけなきゃ皆スルーしてくれたのになァ

>>872

これで墓穴掘ってるな

>>872
どこにDOMの話が出てくるんだ？最悪だなお前

>>872
お前フルボッコじゃねーか
みんなお前が悪いってよ

>>872

オラオラ出てこいよ

どうせQだろ

意訳「SAX？知らんがな」

オラオラかかってこいよ！

>>830
×SIRI
○SSRI
あまりきかないどころか凶暴化するという。個人的にはメチルフェニデートがお勧めだが‥‥‥。

>>839
釣りだったんだからほっときゃ良かったのに。

>>893にレスしたつもりが間違えた。
どうでもいいか。

>>859
内部までUTF-8のOSなんてある？
ほとんどUTF-32だろ。
glibcは最初期からそうだし。

>>896

お前>>863だろ
もう出てくるな
うざい

いまどきUTF-8じゃないOSなんてWindowsくれーだろ
あとしね

オラオラかかってこいよ！

私も>>896は異常者だと思います。
狂ってると思います。

>>896
>>896
>>896
>>896
>>896

マッキントッシュがUTF-8じゃなかったっけ

UTF-16=itanium
UTF-8 =amd64

itaniumはUTF-32だろ

UTF-32はSparkじゃね。

よく分からない例えはやめなしゃれ

内部コードにUTF-8使ってるOSなんて知らんな。

MacOSXはUTF-8

NSStringやCFStringは内部UTF-16に見えるが

ファイルシステムやAPIでUTF-8が通るからと言って実装がどうこう言うのはなー
大御所Plan9でさえ怪しいのに

linuxもKernel 2.6.x ぐらいからパッチ導入してUTF-8サポートした
Plan9以降UNIXはUTF-8だし。

OSXはSJISとEUCの名残がある部分があるが、
UTF-16ってのは無いな。低水準APIがワイド文字使わないし。
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference
/CFStringRef/Reference/reference.html

>>893
中学生ですかあんた…。
これだからメンヘラはキモイって言われるんだ。

Qは完全な重症自己愛性人格障害だね

>>858
当たり前でしょ、そんなこと！　クロスコンパイルを知らないかって、そんな無礼な質問があるか！！
君はイエストシキイッソを知ってるか、そう聞かれたらどうするんだ君！

ageてtypoまでしてつまんねぇとか

そういうコピペだから

>>910
それはパス名なんかの外部表現でしょ。
中はiconvベースだからUTF-32。

>>911
CFStringは基本的にUTF-16(Mac OS X的にはUniChar)を
格納することを想定しているコンテナ。
他のものが格納されていても変換することはできるが。
その辺の事情はCFStringGetCharactersPtr等のドキュメントを読めば分かる。
iOSでプログラム書いた人間走ってることと思うが。

俺はUTF-16なんて見たことない
いまどきUTF-16なんてM$だけだろ

Mac, iOSがUTF-16なのはたぶん内部的にICUを使っているからでもあるからだろうな
ICUで使ってる内部表現がそうだから
プログラム言語だとUTF-16が多数派では（実際にはUCS-2にしか対応していない
ものが多いかもしれないが）

>>919
土方には必要ないんで。

WikipediaにはMacとUnixではwchar_tは32バットって書いてあるぞい？

Unixが何を意味するのか分からないけど、俺の手元の資料ではロケールがサポートする
文字をすべて収納できる整数としか規定されていないな。

http://ja.wikipedia.org/wiki/ワイド文字
＞内部表現
＞Windowsでは16ビット (UTF-16)、LinuxやMac OS Xでは32ビット (UTF-32)である

http://ja.wikipedia.org/wiki/UTF-8
＞Mac OS Xで使用されるHFS+ファイルシステムでは、ファイル名をNFDに正規化されたUTF-8で扱う

どっちなんだい、まっ今ティッシュ＾＾

>>922
それは事実。wchar _tが16なんて環境Windowsぐらいじゃね。

>>917
興味があるから、カーネルのどの辺りのコードで変換してるか教えて。
カーネルソースをwchar_tでくぐってもそれらしいものが見つからなかった。
stringクラス的なものを構造体で作って管理してたりすんのかな。

おまえら海栗コードスレでやれ

M$はC++を捨てたんだから、ここもUNIXスレだろ。

>>928
実装にかかわらずここは規格に沿ったC++のスレです

サロゲートペアを許容してるCLのwchar_tは規格違反の気がする。
せっかくchar16_tがやってきたんだし、typedef WCHAR くらいは char16_t のほうにしてほしい。
むりだろうなあ

>>928
msがC++捨てるにはxp,vista,7を捨てる必要が有るから、あと10年は捨てられんでしょ

そしたら中古になったvs2011拾ってやるよ

カーネルがsingularityベースに変わるまではムリだろ

>>924
wchar_tとunicodeは、直接関係ないからね。
unicode使っててもwchar_t使わないケースはいくらでもある。

>>930
合成文字と異体字セレクタがある時点で、UTF-32なwchar_tも規格違反だけどな！
wchar_tは「とにかく全ての文字を固定長で表現できるなにか」なんだから。

wchar_tってどっちかつうとUnicode よりマルチバイト文字向けだよな。

wchar_tの類はコンテナだから中身には関与しないんだろうね。
今、妥当な使い方がUTF-16などっていうだけで。

「全ての文字」の定義次第だな

wchar_tはGCCでは32ビットだったような

__STDC_ISO_10646__
が定義されている場合はwchar_tの中身がunicodeということになるはず

ただし符号化方式は問わない・・・か

Unicodeというと符号化文字集合と文字符号化方式の2つを指してしまうから、
符号化文字集合はUCS-4、文字符号化方式はUTF-xと呼ぼうぢゃないか。

http://d.hatena.ne.jp/kamoya11/20100331/1270030798
固定長単位であつかうことがどうもうまくいかないっぽいから
もうUTF-8でいいんじゃないかって気もしないではないけど
専用の型や関数がない現状じゃめんどくさすぎるよな

元々charが何ビットかって事自体実装依存なんだから、char8_tを作るべきだったよな。

VC++ ExpressってC++11に対応してる？

>>944
コンパイラで言えば仮対応してるだろ。
てか、タダなんだからためせ。

>>942
文字リテラルが一番の問題じゃね。
一回配列に突っ込んでしまえば、ダメ文字問題もないしそうそう困らないと思うけど。

>>945
ロケールに従う従来のcharと、UTF-8なcharでオーバーロードができないって話じゃね？

mblen(u8"UTF-8文字列", MB_LEN_MAX); // ロケール依存

文字数カウントもまともに出来ないようじゃなあ

もうwchar_tでいいや

マルチバイト文字数なんて必要か？ そもそも

おまえのﾊﾞｰﾁｬﾝにnバイト以内で記述してくださいって言って通じるなら必要ない

スレタイ

ラムダ関数ってインライン関数になるんですか?

parallel_for(0,10000000,[](int a){/*短い処理*/});

関数が短いとき、インラインになることが保証されてないと
関数呼び出しコストがバカにならないような。

>>949
1文字の途中で切れないようにするのに必要。
1024B容量あるとしても、1023バイト目は1バイト目で
切れてるとかは困るからね。とは言え複合文字のせいで
どのみち中途半端になるが。

>>952
今までインライン展開が保証された事ないでしよ。
実装依存。

>>953
UTF-8のときはmblenが合成文字やVSも含めた長さを返してくれれば……
でもそうすると切り出した一文字分をwchar_tに入れられない……

C++でUnicodeを扱うのは、C++でGUIを扱うのと同じである…
こう考えれば済むだけの話だったんだよ。

正規化まで考慮してUnicode扱ってるアプリなんて正直見たこと無い。
それで困らないということかもしれないが。

C++の仕様についてまとめるより別のシステム向け言語つくってくれたほうが
万人にシアワセじゃねーのか。もうおじさんついてけないよ

>>954
保証はともかく、inline指定したのと同じ効果になるかどうかだな

これ一択みたいな文字コードライブラリって有るの？

iconvくらいしか知らない

IBM ICUだよ。
C++ bindingもあるけど11じゃないからスレ違いだけどな。

>>956
GUIそんなに辛いか?
Qtなんか使うと他の言語の方が面倒に感じる。

GUIはテキストベースのプログラミング言語自体と根本的に相性が悪い気がしないでもない
オーサリングツールがないとやってられん

確かにシェルスクリプトやらPerlやらawkやらでGUIは辛いな。
コールバック可能な仕組み作るだけでも面倒だ。

Perlはtkあるじゃん

dtkshなら今のLL並に簡単にGUIアプリ書けるよ。

C++ AMPの対抗馬というよりは、OpenMPのGPUアクセラレーション版と捉えた方が良いのかな
Nvidia’s OpenACC Standard | SemiAccurate
http://semiaccurate.com/2011/11/15/nvidias-openacc-standard/

どうでもいいがPerlとかRubyとかLLって言うのおかしくね？
そんなん言ってるの非論理的な日本人だけじゃん。
海外サイトでLLっていったらCレベルの速度が言語の事。

C++11がまともに使えるようになるまであんまり使う気になれんな。
仕様的に安定して使えるのは2015年ぐらいか。

void sma_amp(int series_length, const float *series, float *moving_average, int window)
{
    array_view<float>  arr_in(series_length, series);
    array_view<float>  arr_out(series_length, moving_average);

    parallel_for_each
    (
        grid<1>(extent<1>(series_length-(window-1))),

        [=](index<1> idx) restrict(direct3d)
        {
            const int i = idx[0] + (window-1);

            float sum = 0;
            for (int j=i-(window-1); j<=i; i++)
                sum += arr_in[j];

            arr_out[i] = sum/window;
        }
    );
}

賢くて優秀なお前らに質問だ！

以下のようなコードを書いたんだ。
ttp://ideone.com/n4aAH

で、見ればわかるがランダムなコードのファイルを吐くだけの単純なコードなんだけど、乱数の初期化部分にstdlibのrand使ってるんだよ。
これはある程度乱数をコントロールしてファイルを吐きたい意図があるわけなんだが、今の時代にこれはないだろうと思うのさ。

そこで、大喜利逝ってみよう。
どうすれば、意図に沿った上で今風になるか。

ちなみに開発環境はVC10EEだけど、俺が読めるコードだったらそれに限らない。

どうよ！！

まあ、C++11の機能なんてD言語みたいなものだから、いつまで経っても実際の現場では使えないんだろうな。

C++は結局Better C以上にはなり得ない。

>>971
C++相談室でやれ。

>>971
先ず、文章を今風にしてこい。

何年前の２ちゃんねるだよ。

そういやVC10ってuint_leastN_tまともに実装してないな。
オーバーロードがまともに動かん。相変わらずのMSだ。

>>973
うーん。ここの人だったら明快な答えくれると思ったんだけど。
ま、誘導ありがとう。

>>974
レートマジョリティよりも行動が遅い俺にはちょっと難しいぜ。


いてきまーす。

渡されたラムダ関数の引数の型によって呼び出す関数を変えるオーバーロードってできないんですか？

関数ポインタに変換すればできそうだけど
vcじゃできないらしい…

ラムダから関数ポインタへの変換は無理じゃね？だいたいキャプチャした変数どうするんだよ

キャプチャを使っていないラムダ式は関数ポインタと同じように使えるって仕様が入ったんだよ

キャプチャなしなら最適化でカンポに変えてよい

>>977
ワンクッション挟んで
ttp://ideone.com/6Acp1

キャプチャ無しなら変換できたはず、最終的な仕様では

そろそろ次スレだが、C++0xってまだいるかね

>>977
可変長引数テンプレートを使ったクラスで包めば出来る。

>>984
バカが重複スレ立てるからいるだろ。

バカを隔離できるのはむしろメリットではないか？

ISO/IECのページやGCCのページもC++11って書いてるし
これからはC++0xって書くと、古い情報のように思われるかも

ttp://www.open-std.org/jtc1/sc22/wg21/
ttp://gcc.gnu.org/projects/cxx0x.html

C++11がいいと思う

C++11 15だけだとC++スレの1115本目だと思われる

じゃ C++11 0x0Fで

C++11/C++0x/ISO/IEC 14882:2011 15 で

「C++11 part15」でいいだろ

C++11はもう正式な標準になったんだから、C++11の話はC++相談室でいいだろ。
こっちはC++1xとか「次期C++標準」とか、そういうスレになるんじゃないの？

次期規格つっても5〜7年後だろ。
98⇨03⇨11って流れだからな。
ネタがないって。

最狂言語スレ？

>>993 ネタが無いならこのスレ終了ってことでいいんじゃね？

まともに実装されて普及されるまでは必要だな

スレタイ云々は次スレで決めてくれ
C++11/C++0x 15
http://hibari.2ch.net/test/read.cgi/tech/1321453654/

おまえらすぐハゲ頭になりそうだな
どうでもいいことで悩んで

999

1000ならC++11が普及する

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。