2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++11/C++0x 14

1 :デフォルトの名無しさん:2011/09/23(金) 15:56:01.00
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/

2 :デフォルトの名無しさん:2011/09/23(金) 15:56:22.09
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/

3 :デフォルトの名無しさん:2011/09/23(金) 16:00:14.16
これ乙インテール

4 :デフォルトの名無しさん:2011/09/23(金) 16:07:16.73
                          刀、           , ヘ
                  /´ ̄`ヽ /: : : \_____/: : : : ヽ、
              ,. -‐┴─‐- <^ヽ、: : : : : : : : : : : : : : : : : : : : : : }
               /: : : : : : : : : : : : : :`.ヽl____: : : : : : : : : : : : : : : : : : /
     ,. -──「`: : : : : : : : : :ヽ: : : : : : : : :\ `ヽ ̄ ̄ ̄ フ: : : : :/
    /: :.,.-ァ: : : |: : : : : : : : :    :\: : : : :: : : :ヽ  \   /: : : :/
    ̄ ̄/: : : : ヽ: : : . . . . . . . . . . .、 \=--: : : :.i  / /: : : : :/
     /: :     ∧: \: : : : : : : : : : ヽ: :\: : : 〃}/  /: : : : :/         、
.    /: : /  . : : :! ヽ: : l\_\/: : : : :\: ヽ彡: : |  /: : : : :/            |\
   /: : ィ: : : : :.i: : |   \!___/ ヽ:: : : : : : :\|:.:.:.:/:!  ,': : : : /              |: : \
   / / !: : : : :.ト‐|-    ヽ    \: : : : : l::::__:' :/  i: : : : :{              |: : : :.ヽ
   l/   |: : :!: : .l: :|            \: : : l´r. Y   {: : : : :丶_______.ノ: : : : : :}
      l: : :l: : :ト、|         、___,ィ ヽ: :| ゝ ノ    '.: : : : : : : : : : : : : : : : : : : : : : /
      |: : :ト、: |: :ヽ ___,彡     ´ ̄´   ヽl-‐'     \: : : : : : : : : : : : : : : : : : イ
        !: :从ヽ!ヽ.ハ=≠' , ///// ///u /           ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
      V  ヽ|    }///  r‐'⌒ヽ  イ〉、
              ヽ、______ー‐‐' ィ´ /:/:7rt‐---、       こ、これは>>1乙じゃなくて
                  ィ幵ノ ./:/:./:.! !: : : : :!`ヽ     ポニーテールなんだから
              r‐'T¨「 |: | !:.∨:/:./: :| |: : : : .l: : : :\   変な勘違いしないでよね!
               /: : .|: :| !:.!ィ¨¨ヾ、:.:/ !: : : : l: : : : : :.\

5 :デフォルトの名無しさん:2011/09/23(金) 18:28:04.74
まだ、立てるの?


ふぁー

6 :デフォルトの名無しさん:2011/09/23(金) 19:03:42.81
日本語でおk

7 :デフォルトの名無しさん:2011/09/23(金) 22:09:32.72

      , '´ / r‐ 、`丶、_
      /   i  !  \ ノへ` ミ く ̄_`_ヽ___
    /    |   ,  '´     ̄`丶>‐ヘ / |
    {    | /     /  /V1    〈   l
    ヽ、   )′ / // / / ' `l l   `、 ハ
     ノ   // /ィ 〃_'_|_/ /  l | }   V |
   /   {Ti l  | i´/ レ l`{   '_〉V |  ト、ノ
  '´      `いl  | {y7汽くヽ!  // `ン リ_ / ! |
 {      /(ヘ、lハ{i::.::リ     r芯Y /r `ヽ/ヽ
  、     〃  `o、 `,,'′  , 〈::.:;ノシ^Zァ-r }   |
  丶、  {i     ,ヘ、  /^ヽ  `゛/ ,二/ |  ′
  ( ー‐'    _彡 _/_丶、 ‐'  . ィ/   r) l  /
   ` ̄{ ハ (   /::.::.:: ;ニヽ、´{  l   rく´  |/
      ヽ、`ー 厶イ :/  ∨ 〉ヽ」_」__::\ハ     >>1乙にゃん
         /): : /     /ヘ: /::.::.::.::.::|::.::.:/
         !': : 八丶、, ' : : `ヽ、:_:_:_:jLノ

8 :デフォルトの名無しさん:2011/09/24(土) 00:45:52.77
結局今残ってる学園の皆さんは?

9 :デフォルトの名無しさん:2011/09/24(土) 09:32:22.39
一度目は面白くてもネチネチ繰り返酢とキモチ悪いだけだ
忘れろてか絶対書くな

10 :デフォルトの名無しさん:2011/09/24(土) 15:48:28.56
はやくVC++で可変長天ぷらつかいたいよう
スクリプトで似たようなオーバーロードたくさん生成する作業はもういやだお


11 :デフォルトの名無しさん:2011/09/24(土) 15:52:32.87
GCCでもこの有様なのに

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

12 :デフォルトの名無しさん:2011/09/24(土) 18:17:04.09
エクセルでたくさん生成すればいいだろ
結構楽々だぜ?

13 :デフォルトの名無しさん:2011/09/24(土) 19:12:45.83
PHPを使えばいいと思うよ^^
ttp://www.kijineko.co.jp/lab/20100425-1

14 :デフォルトの名無しさん:2011/09/24(土) 21:57:20.35
Win32 APIの動的ロードをするときにdecltypeが死ぬほど便利と知った

15 :デフォルトの名無しさん:2011/09/24(土) 22:12:38.60
今頃知ったが
decltypeって関数の戻り値の型も取り出せるのか
オラワクだな


16 :デフォルトの名無しさん:2011/09/24(土) 23:39:04.02
>>11
4.3から実装されてる。コード晒して。

17 :デフォルトの名無しさん:2011/09/24(土) 23:58:13.72
>>14
なぜ便利なのですか?

18 :デフォルトの名無しさん:2011/09/25(日) 00:16:31.39
>>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;
}

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

19 :デフォルトの名無しさん:2011/09/25(日) 00:23:10.03
>>17
ヘルプを見なくても戻り値をなんとか受け取れます

20 :デフォルトの名無しさん:2011/09/25(日) 00:53:53.50
ヘルプを見なくてもその戻り値が使えるのん?

21 :デフォルトの名無しさん:2011/09/25(日) 01:19:09.37
学園はもう飽きたなら、今度はバーあたりどうかな

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

22 :デフォルトの名無しさん:2011/09/25(日) 02:06:18.36
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;
}

23 :デフォルトの名無しさん:2011/09/25(日) 02:23:14.26
template にtagとか入れちゃうのよく見るけどな

24 :デフォルトの名無しさん:2011/09/25(日) 02:30:42.28
constexprならいけるのか
そこら辺仕様なんだろうか?

25 :デフォルトの名無しさん:2011/09/25(日) 02:53:32.95
>>22
すげえ
gcc4.6.1(MinGW)でコンパイルして走ってしまった
しかしEclipse CDTが対応してないらしくまだエラーだらけの画面

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

26 :デフォルトの名無しさん:2011/09/25(日) 02:58:21.10
constexpr使うなら最初からsumfunc直接使えば良いな
sum::value要らない

27 :デフォルトの名無しさん:2011/09/25(日) 05:07:21.55
FDISの内容=規格でいいんだよな?

28 :デフォルトの名無しさん:2011/09/25(日) 17:30:02.05
規格定まったし、VC11がどのくらい準拠してくれるかねぇ
10と同じだったら嫌だ

29 :デフォルトの名無しさん:2011/09/25(日) 18:36:25.24
>>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で使ってるのは関数呼び出しからのテンプレート実引数推論であって上記とは別の機能。

30 :デフォルトの名無しさん:2011/09/25(日) 18:45:15.09
>>28
ほぼ同じ

31 :デフォルトの名無しさん:2011/09/25(日) 19:27:46.68
ふぁー、こいつらときたらw

32 :デフォルトの名無しさん:2011/09/25(日) 19:29:40.11
風と共に去りぬ



じゃなかった。。。



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

33 :デフォルトの名無しさん:2011/09/25(日) 20:27:36.53
時々現れる昭和臭がキツイおっさんはなんなの

34 :デフォルトの名無しさん:2011/09/26(月) 04:51:23.18
gcc とllvmが実装してくれさえすればVSも後から実装してくれるんじゃないだろうか

35 :デフォルトの名無しさん:2011/09/26(月) 07:56:38.85
clangのlambdaとvcの可変長テンプレートどっちが早いかな

36 :デフォルトの名無しさん:2011/09/26(月) 10:49:20.01
C++11フル実装はclangが一番早いと思われる。
開発者がIndiana版conceptの中の人だから。

37 :デフォルトの名無しさん:2011/09/26(月) 11:06:51.14
clangってlambda実装する気あんのかねぇ

38 :デフォルトの名無しさん:2011/09/26(月) 11:29:44.60
とりあえず自分が使うのは
VS gcc 両方で使える機能だけ

39 :デフォルトの名無しさん:2011/09/26(月) 11:51:34.97
>>37
基本的にマージされる方向。cfe-devにもよく登場する人。
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gigabytes/1


40 :デフォルトの名無しさん:2011/09/26(月) 23:15:17.44
v3以降 脱GPLの流れが加速してるな
不自由を強いられるようなもんだからこうなるのも当然ではあるけど

41 :デフォルトの名無しさん:2011/09/27(火) 21:58:53.13
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); } );

42 :デフォルトの名無しさん:2011/09/27(火) 23:59:50.01
また変態言語とか言われるからその辺で

43 :デフォルトの名無しさん:2011/09/28(水) 00:24:32.10
果たして使い道があるか。

//オブジェクトによる分岐
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); } );



44 :デフォルトの名無しさん:2011/09/28(水) 00:31:34.22
今考えるとブロックをサポートせずbool型をオブジェクトにしなかったJavaってアホだな

45 :デフォルトの名無しさん:2011/09/28(水) 00:39:33.45
gccのsequenceのサポートはバージョンいつからだろう
今の所ステータスNoになってるな

46 :デフォルトの名無しさん:2011/09/28(水) 00:40:01.90
あほはお前

47 :デフォルトの名無しさん:2011/09/28(水) 10:13:35.95
>>42
いまどきlambdaくらい他言語の人の方が理解あるだろ

48 :デフォルトの名無しさん:2011/09/28(水) 10:30:59.56
C++って基本的にネイティブコードを想像しながら書くのに使ってたんだが
こんなに仕様が大きくなったら追いつかないわ・・・

49 :デフォルトの名無しさん:2011/09/28(水) 11:49:42.16
どうせboost使って楽しようとし始めた時点でわけわからなくなる

50 :デフォルトの名無しさん:2011/09/28(水) 12:54:24.75
ネイティブコードから見れば逆にあまり変わってないような
的外れかもしれないが強いて挙げるならスレッドが仕様に含まれたのが大きいか

51 :デフォルトの名無しさん:2011/09/28(水) 16:33:36.87
>>47
確かに
関数オブジェクトをわざわざ別のクラスで定義しなければいけなかった
今までが異常だったとも言える

52 :デフォルトの名無しさん:2011/09/28(水) 16:42:30.70
c++11の新要素のうち、どの辺がネイティブコード想像できない?

53 :デフォルトの名無しさん:2011/09/28(水) 17:58:07.08
拡張for文だな
どこまで最適化してくれるもんなのやら

54 :デフォルトの名無しさん:2011/09/28(水) 19:39:36.52
規格に疑似コード書いてくれてんじゃん

55 :デフォルトの名無しさん:2011/09/28(水) 21:16:41.50
あんな擬似コードを馬鹿正直に実装するわけないじゃん
コードサイズがひどいことになる

56 :デフォルトの名無しさん:2011/09/28(水) 21:27:14.02
期待する最適化の結果は同じだろ

57 :デフォルトの名無しさん:2011/09/28(水) 21:27:20.75
最適化をイメージすりゃ良いじゃん

58 :デフォルトの名無しさん:2011/09/28(水) 23:48:45.77
憶測の応酬

59 :デフォルトの名無しさん:2011/09/29(木) 11:31:07.35
>>53
拡張じゃないforと何か変わりますか?

60 :デフォルトの名無しさん:2011/09/29(木) 13:04:46.65
正直JavaScriptの方が変態言語だと思うし、C++なんて平凡な言語だと思うわ

61 :デフォルトの名無しさん:2011/09/29(木) 13:50:32.86
スレッド関連をまとめたサイトってないのでしょうか

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

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



62 :デフォルトの名無しさん:2011/09/29(木) 14:06:43.95
>>61
mutexなりでガードするかatomic変数として宣言するかしないと、
data raceで未定義動作となる。

63 :デフォルトの名無しさん:2011/09/29(木) 14:45:54.81
c++11のスレッドに

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

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

64 :デフォルトの名無しさん:2011/09/29(木) 15:04:58.35
>>63
領域としてのスタックを指してるならそんな動作は100%害悪にしかならない
便利機能とか思ってるなら今日はもう顔洗って寝ろ

65 :デフォルトの名無しさん:2011/09/29(木) 15:45:26.54
>>63
> 途中で別スレッドに処理が移ったら

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

66 :デフォルトの名無しさん:2011/09/29(木) 15:48:42.44
c++11のスレッドでschemeの継続を作ろうとしてるブログ見たものだから
ひょっとそんな便利機能あるのかと期待してしまった

67 :デフォルトの名無しさん:2011/09/29(木) 15:59:14.29
この辺りの話かね。
http://en.wikipedia.org/wiki/Tail_call#Through_trampolining

68 :デフォルトの名無しさん:2011/09/29(木) 16:02:40.55
http://d.hatena.ne.jp/jonigata/20091003
これとかです

69 :デフォルトの名無しさん:2011/09/29(木) 16:04:09.26
継続
http://ja.wikipedia.org/wiki/%E7%B6%99%E7%B6%9A

70 :デフォルトの名無しさん:2011/09/29(木) 19:36:46.35
マイクロスレッドあればいいのになあ

71 :デフォルトの名無しさん:2011/10/02(日) 16:42:23.32
>>61
その前にスレッド間で広域変数なんて使うなよ。
グローバル変数が許されるのはI/O関係か割り込みかかメモリー関係ぐらい。
シグナルですらグローバル変数を回避できるのに。

72 :デフォルトの名無しさん:2011/10/02(日) 17:05:52.54
public static Hoge hoge = new Hoge();

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

73 :デフォルトの名無しさん:2011/10/02(日) 17:38:03.07
>>71
volatileとか知らない人?

74 :デフォルトの名無しさん:2011/10/02(日) 18:11:57.66
設計の話だろ

75 :デフォルトの名無しさん:2011/10/02(日) 18:46:46.57
>>71
非同期 I/O も割り込みもスレッドなのをご存知ない?
そもそも「許される例」があるのに、そこまで感情的になるのは間違ってるって思わないのか

76 :デフォルトの名無しさん:2011/10/02(日) 18:59:31.29
いや、グローバル変数なんかそうそう使うもんじゃないってのは
一般的な話だと思うが

77 :デフォルトの名無しさん:2011/10/02(日) 19:05:08.30
グローバルな存在があるのも一般的な話だろ
解こうとする問題と構造の一致しないモデルをなぜ強要するんだ

78 :デフォルトの名無しさん:2011/10/02(日) 19:14:46.59
>>73
volatileになんの関係が?

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

79 :デフォルトの名無しさん:2011/10/02(日) 19:18:06.85
仕様上どうなるのって話にスタイル上やるなって話で返す奴はどこにでもいるな。
自分のわからない話からわかる話にしようとしてるだけだから無視するが宜しい。

80 :デフォルトの名無しさん:2011/10/02(日) 19:21:56.16
既に排他しないと壊れるっつう話は出てるし

81 :デフォルトの名無しさん:2011/10/02(日) 19:29:42.87
JavaとかのvolatileとC++のvolatileの区別がつかないヤツがまだいるのか・・・

82 :デフォルトの名無しさん:2011/10/02(日) 19:33:59.03
実は、マルチスレッドでvolatileはタブーなんだけどな。

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

83 :デフォルトの名無しさん:2011/10/02(日) 19:44:02.96
フラグには問題ないだろ

84 :デフォルトの名無しさん:2011/10/02(日) 19:52:21.00
なにが?グローバル変数?

85 :デフォルトの名無しさん:2011/10/02(日) 20:01:05.16
C++使っててフラグってのもどうよ。
ましてやC++11のスレで発言できるネタじゃなくね。

86 :デフォルトの名無しさん:2011/10/02(日) 20:08:26.81
std::atomicでおk

87 :デフォルトの名無しさん:2011/10/02(日) 20:38:56.85
実は、マルチスレッドでvolatileはタブーなんだけどな。(キリッ

88 :デフォルトの名無しさん:2011/10/02(日) 20:50:29.42
uyさんがログインしました

89 :デフォルトの名無しさん:2011/10/02(日) 20:54:30.90
まともにスレッドつかったことのないやつばかり

90 :デフォルトの名無しさん:2011/10/02(日) 21:25:25.89
おかしいと思う所があるんならはっきり言えよ
お前の中だけで完結してるならチラシの裏にでも書いとけ

91 :デフォルトの名無しさん:2011/10/03(月) 00:11:36.92
なんかよく分かんないけどとりあえず、Win32でSemaphoreやEvent使ってるコードを
std::atomic、mutex、condition_variableで効率的に書きなおす移植用サンプルが欲しい

92 :デフォルトの名無しさん:2011/10/03(月) 00:56:14.33
>>78
↓はvolatile関係あるだろ

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


93 :デフォルトの名無しさん:2011/10/03(月) 01:40:24.48
JavaやC#じゃねぇから関係ねぇよ

a = true;
a = false;

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

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


94 :デフォルトの名無しさん:2011/10/03(月) 01:48:07.56
そもそもvolatileなんて組み込みやOSでのIO向け機能だし
((int*)0x10000) = 0x01;を連続で呼ばなきゃいけない場合とかに使う物
そもそもC++11以前のC++はスレッドの事を何にも知らん

95 :デフォルトの名無しさん:2011/10/03(月) 01:53:35.99
>>93
>mutexを呼んだ場合は、コンパイラが他の関数で参照する事を考え削除しない

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

96 :デフォルトの名無しさん:2011/10/03(月) 02:01:28.56
>>95
インライン展開しない関数全般の話
関数を呼んだ時点で、呼び出し元の変数はスタックに退避される。

97 :デフォルトの名無しさん:2011/10/03(月) 02:12:45.42
スレッドに限らず連続した代入式でも
関数の呼び出しを跨いでるものを
削除したらマズイ訳で

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

98 :デフォルトの名無しさん:2011/10/03(月) 02:29:47.41
>>96


99 :デフォルトの名無しさん:2011/10/03(月) 02:36:17.87
>>98 何が言いたい?mutexなら外部関数だからインライン展開されんぞ。


100 :デフォルトの名無しさん:2011/10/03(月) 02:39:20.53
>>96-97
理解できたかも。なるほどです

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

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

101 :デフォルトの名無しさん:2011/10/03(月) 02:42:20.09
実装上ありえないって話と仕様のどこで明示されてるって話は別だろ

102 :デフォルトの名無しさん:2011/10/03(月) 02:46:00.81
実装上でもありえんこと言ってる奴までいるし

103 :デフォルトの名無しさん:2011/10/03(月) 02:48:41.45
>>100
あ、ちがうか
mutexでロックするならループ内で直接読み取る場合でもメモリ書き込みコードは削除されないから
結局ロックをかける限りvolatileはいらないってことになりますね。なるほど

104 :デフォルトの名無しさん:2011/10/03(月) 02:49:06.75
仕様上どうするかロクに書いてないvolatileより
論理的に確実性がある分マシ

105 :デフォルトの名無しさん:2011/10/03(月) 02:50:29.93
そういうスレじゃないから

106 :デフォルトの名無しさん:2011/10/03(月) 02:51:30.12
>>102
だから主語を言えって。他人が読んでるわけで、
あんた一人が書いてるチラシの裏じゃないんだから。

107 :デフォルトの名無しさん:2011/10/03(月) 09:29:22.60
ラムダでキャプチャする変数を
一部だけ変更可能にする方法ないでしょうか
全部一括でconstかmute しかないの?

108 :デフォルトの名無しさん:2011/10/03(月) 12:49:54.36
>>97
いやvolatileが導入された時点でその意味は変更されてる。
強制したければ、volatile修飾子付けるしかない。

109 :デフォルトの名無しさん:2011/10/03(月) 12:57:28.34
イミフ

110 :デフォルトの名無しさん:2011/10/03(月) 13:02:03.86
>>108
何が言いたいのかわかんない。
volatile有ろうが無かろうがあのコードの動作は変わらんぞ。

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


111 :デフォルトの名無しさん:2011/10/03(月) 13:13:59.87
volatileがなんでマルチスレッドの話題に登場するんだ?

112 :デフォルトの名無しさん:2011/10/03(月) 13:15:00.12
globalにvolatile qual.付けなきゃ、
関数から戻って来た後の値は不定。
呼び出す前にメモリに書き込まなくていいから。

113 :デフォルトの名無しさん:2011/10/03(月) 13:18:11.58
>>112
mutex呼んだ時点で書き込まれるから要らん。
逆にvolatileをmutex がわりにする事もできん。

114 :デフォルトの名無しさん:2011/10/03(月) 13:20:43.34
C++でのvolatileの誤用についてはとりあえずあれだ、gosling先生が悪いってことにしとこうぜ

115 :デフォルトの名無しさん:2011/10/03(月) 13:23:53.16
>>110
> シグナル安全なブロッキング使うことになるから形骸的。

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

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


116 :デフォルトの名無しさん:2011/10/03(月) 13:36:44.10
>>113
>>97のコードはMutex読んでないし、
そもそもマルチスレッドの話しはしてない。

117 :デフォルトの名無しさん:2011/10/03(月) 13:40:16.33
結局どっちが正しいの?
volatile指定と関数呼び出しは、(コンパイラにとっての)可換なメモリバリア指定なの?

118 :デフォルトの名無しさん:2011/10/03(月) 13:46:28.10
>>117
volatileはmemorry barrierと直接関係無い。
最適化抑制にすぎない。
Barrierは別に必要になる。
可換どころか直交。

119 :デフォルトの名無しさん:2011/10/03(月) 13:49:37.11
>>112
んなわけないじゃん
全ての値の変更は副作用完了点を通れば完了するよ


もしかして釣り?

120 :デフォルトの名無しさん:2011/10/03(月) 15:12:52.88
実行スレッドから見てas isであればよい。

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

121 :デフォルトの名無しさん:2011/10/03(月) 15:15:46.19
「同一」実行スレッドと明示しておいた方がいいかな

122 :デフォルトの名無しさん:2011/10/03(月) 15:22:28.38
>>118
メモリバリアとか別の話をしてすまん
volatile指定と関数呼び出しは置き換え可能な最適化抑制なの?

123 :デフォルトの名無しさん:2011/10/03(月) 16:41:48.24
出来ない。
メモリアクセスに関する最適化抑制が出来るのはvolatileだけ。


124 :デフォルトの名無しさん:2011/10/03(月) 16:47:12.66
誰かわかりやすく3行でまとめろ


125 :デフォルトの名無しさん:2011/10/03(月) 16:55:04.78
>>124
インライン展開されない関数で変数を挟めば最適化を抑制できる
スレッド間で変数を共有したいならmutexで挟め(volatileなんて忘れろ)
volatile信者はアホ

126 :デフォルトの名無しさん:2011/10/03(月) 16:58:45.49
if(volatile_v)  ○ volatile_v=fail;
// 別threadが↑ここで書き換える可能性
// atomic云々関係なしで

127 :デフォルトの名無しさん:2011/10/03(月) 17:05:36.62
>>125
> インライン展開されない関数で変数を挟めば最適化を抑制できる

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

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


128 :デフォルトの名無しさん:2011/10/03(月) 17:07:46.31
もしかして : volatileを使ってmutexを実装する話をしている人が混ざっている

129 :デフォルトの名無しさん:2011/10/03(月) 17:16:10.42
>>127
なんでメモリバリアの話を持ち出すわけ?
メモリバリアしたけりゃmutex使え。
__asm__volatileとかそんな独自キーワード出されてもね。

130 :uy:2011/10/03(月) 17:22:47.75
>>88
ハァ>?

131 :デフォルトの名無しさん:2011/10/03(月) 17:33:53.18
>>126
今の話はソースコード通りの読み書きが保証されるか?って話で同期は関係無いだろ

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

132 :デフォルトの名無しさん:2011/10/03(月) 17:44:13.51
あれ、関数は論理的に副作用がなければ実行順序は無保証、volatileもその変数自身以外は無保証、だと思ってたが

133 :111:2011/10/03(月) 17:52:10.95
俺の質問に答えてくれ

134 :デフォルトの名無しさん:2011/10/03(月) 17:57:21.53
>>131
>直接展開するぜ
展開されちゃってるぞ。言いたいことは分かるけど。

135 :デフォルトの名無しさん:2011/10/03(月) 18:07:31.55
>>133
volatileがマルチスレッドに必要だと考えてるバカがいたから。

136 :デフォルトの名無しさん:2011/10/03(月) 18:08:29.84
>>120
そうだったな

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

137 :デフォルトの名無しさん:2011/10/03(月) 18:08:52.34
>>133
多分↓みたいな場合に最適化抑制用のvolatile修飾が変数vに必要か不要かって話じゃないの?
それでLLVMやLTO?でもそれは正しいのかっていう話だと思うけど
int v = 0;
mutex m;
void thread_main() {
 for (;;) {
  m.lock();
  if (v) { m.unlock(); break; }
  m.unlock();
 }
}


138 :デフォルトの名無しさん:2011/10/03(月) 18:27:10.91
>>115
int discripter=-1;

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

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

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


139 :デフォルトの名無しさん:2011/10/03(月) 18:36:39.85
>>137
不要な理由を挙げるとこんな感じか

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

140 :デフォルトの名無しさん:2011/10/03(月) 18:38:59.78
ghan&Ritchieの本『プログラミング言語 C』より
「volatileの目的は,黙っていると処理系で行われる最適化を抑止するこ とにある.
例えば,メモリ・マップ方式の入出力をもつマシンでは,ステー タス・レジスタに対するポインタは,
ポインタによる見かけ上,冗長な参照 をコンパイラが除去するのを防ぐのに,
volatileへのポインタと宣言するこ とが可能である.」

元々目的も違う。

141 :デフォルトの名無しさん:2011/10/03(月) 18:40:18.05
>>140
あっ名前が切れた。ごめんなさい先生。


142 :デフォルトの名無しさん:2011/10/03(月) 18:48:07.16
>>139
全部憶測じゃないの?それ
結局はそのmutexの仕様、コンパイラの仕様、CPUアーキの仕様にC++の仕様を合わせて個別に確認しないと
何も保証されないし何もわからないってことですよね

143 :デフォルトの名無しさん:2011/10/03(月) 19:00:05.66
>>142
mutex=メモリバリアしてくれる関数を前提として話しているので
意味不明な心配をされても困るんだけど
まあC++11のstd::mutexでも使いなよ。規格で保障されてるんだから

144 :デフォルトの名無しさん:2011/10/03(月) 19:00:40.20
憶測はおいといて、環境依存なのは当たり前。
C++はスレッドなんか知らんからな。

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

145 :デフォルトの名無しさん:2011/10/03(月) 19:04:26.33
mutexじゃなくてスピンロックならどうなるのかなっと

146 :デフォルトの名無しさん:2011/10/03(月) 19:27:17.69
>>145
そもそもCじゃまともなスピンロックはできない。
特にマルチコアなら顕著。
出来るのはアセンブリレベル。

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

147 :デフォルトの名無しさん:2011/10/03(月) 19:53:27.23
mutexなんてC++03の仕様にないんだから
規格の範囲内じゃmutexがどうこうなんてどうも言えん

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

149 :デフォルトの名無しさん:2011/10/03(月) 19:58:06.11
そのうちthread_volatileみたいな修飾子が出来るんじゃないの

150 :デフォルトの名無しさん:2011/10/03(月) 19:59:28.23
既にライブラリで解決すんのに何でそんなもんいるんだよ。

151 :デフォルトの名無しさん:2011/10/03(月) 20:09:03.87
>>146
std::atomicってそのためのもんじゃないのか

152 :デフォルトの名無しさん:2011/10/03(月) 20:10:09.57
#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 が変更される可能性があると判断されて
無限ループじゃなくなるんだけどね

153 :デフォルトの名無しさん:2011/10/03(月) 20:10:29.31
>>136
横から悪いけど、11から副作用完了点って削除されるの?どう処理されるか厳密に決められた訳?

154 :デフォルトの名無しさん:2011/10/03(月) 20:16:27.57
>>153
http://d.hatena.ne.jp/Cryolite/20101228#p1

155 :デフォルトの名無しさん:2011/10/03(月) 20:16:32.01
>>152
だからmutex( CriticalSection )挟めばいいだろ。
なんでvolatileに拘るんだ?必要な最適化もされなくなくなって無駄なだけだぞ。

156 :デフォルトの名無しさん:2011/10/03(月) 20:21:07.28
マルチスレッドプログラミング相談室 その8
http://hibari.2ch.net/test/read.cgi/tech/1253521167/

ほい


157 :デフォルトの名無しさん:2011/10/03(月) 20:21:14.65
このスレって割り込みやシグナルとスレッドをごっちゃにしてるヤツがいないか?
割り込みは、他の関数呼び出しが無理やり入るだけで、呼び出された関数が
終了するまで本筋の処理は中断するんだぞ。スレッドみたいに並走はしない。
volatileが割り込みで使えたからと言って訳が違う。

158 :デフォルトの名無しさん:2011/10/03(月) 20:37:09.39
もうvolatileを使ったクソコードなんて見たくも無いよ!!

159 :デフォルトの名無しさん:2011/10/03(月) 20:38:28.20
>>155
mutexはパフォーマンス落ちるからだろ
スレッド内でフラグ読むだけなら同期なんて要らないんだから
mutex使う方が無駄

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

160 :デフォルトの名無しさん:2011/10/03(月) 20:39:05.76
>>152の書き方はバグのもとだからwinならinterlockedを使うのが普通
で、interlockedを使えば最適化とかキャシングとか何も考えずにコーディングすれば間違いは起こらない
ってことでいいの?

161 :デフォルトの名無しさん:2011/10/03(月) 20:41:47.50
>>159
>>146 と同じ話なんで論外。
運悪ければデータ破損する。

162 :デフォルトの名無しさん:2011/10/03(月) 20:43:16.61
読み出ししかしてないんだから破損なんてしないだろ

163 :デフォルトの名無しさん:2011/10/03(月) 20:48:18.10
実際はなんかのタイミングを合わせるためにやってんだろ。
その実際の処理でデータが破壊される。
ま、本当に何の処理もせず>>152のコードまんまを
走らせたいんならどうでもいいけど。

164 :デフォルトの名無しさん:2011/10/03(月) 20:49:33.96
No。タイミング合わせじゃない

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

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

165 :デフォルトの名無しさん:2011/10/03(月) 21:07:20.72
どうやって入力して、どうやって出力する気か。
まぁいいや。スレ違いだそろそろやめるか。

166 :デフォルトの名無しさん:2011/10/03(月) 21:08:29.60
ポーリングウェイトとかいつの時代のプログラムだよ

167 :デフォルトの名無しさん:2011/10/03(月) 21:08:48.40
ポーリングウェイトとかいつの時代のプログラムだよ

168 :デフォルトの名無しさん:2011/10/03(月) 21:09:54.19
大事なことだったんですね。

169 :デフォルトの名無しさん:2011/10/03(月) 21:10:11.11
>>152はVC2010(x86)という特定の環境でこのシンプルな使用方法なら問題ないとおもうが
かなり汎用性にかけるので気持ち悪い。コードが複雑になってくればvolatileはバグの温床になるぞ

170 :デフォルトの名無しさん:2011/10/03(月) 21:10:27.45
演算しかしないならスレッドそのものを中断したほうが速いだろ
フラグで中断しようが、スレッドで中断しようが演算結果に大差ない

171 :デフォルトの名無しさん:2011/10/03(月) 21:19:07.10
>>154
ありがとう。勉強になった

172 :デフォルトの名無しさん:2011/10/03(月) 21:22:52.78
>>166
ウェイトじゃないって

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

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

173 :デフォルトの名無しさん:2011/10/03(月) 21:25:59.55
>>172
volatileじゃメモリバリアの保証が無いだろ。マルチスレッドプログラミングに用いるのは間違い。

174 :デフォルトの名無しさん:2011/10/03(月) 21:34:00.58
キャンセルしてスレッドは速やかに動作を終了し、
スレッドは共有してる他の情報に手を出さないんだから
関係ないと思うが

175 :デフォルトの名無しさん:2011/10/03(月) 21:34:18.87
どこのスレでもNULLとgotoとvolatileの話は盛り上がりますね

176 :デフォルトの名無しさん:2011/10/03(月) 21:36:57.65
そんなにメモリバリアを保証したけりゃ
フラグチェックした「後」にどうこうすればいい話
わざわざループ内でlockのコストを払う必要はない

177 :デフォルトの名無しさん:2011/10/03(月) 21:42:34.24
てかリードにメモリバリアとか関係あるの?
書く時だけでしょ

178 :デフォルトの名無しさん:2011/10/03(月) 21:43:39.49
ループにvolatile混じってたら自動ベクトル化が掛からんだろ。
演算ループだけ追い出して、ループごと強制終了。本気で速度が欲しいならコレおすすめ。

179 :デフォルトの名無しさん:2011/10/03(月) 21:45:22.13
だからVC2010でこのシンプルな使い方については問題ないと言ってる。

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

180 :デフォルトの名無しさん:2011/10/03(月) 21:50:45.80
実装コストも関係するんだけどね

181 :デフォルトの名無しさん:2011/10/03(月) 22:02:26.89
ん?

182 :デフォルトの名無しさん:2011/10/03(月) 22:10:39.54
必要のないコードを書くのは時間の無駄

183 :デフォルトの名無しさん:2011/10/03(月) 22:15:20.22
デバッグで時間を無駄にしないようにしてね

184 :デフォルトの名無しさん:2011/10/03(月) 22:22:40.42
するわけないだろw

185 :デフォルトの名無しさん:2011/10/03(月) 23:37:45.83
>>144
> 憶測はおいといて、環境依存なのは当たり前。
> C++はスレッドなんか知らんからな。

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

186 :デフォルトの名無しさん:2011/10/03(月) 23:44:26.75
C++11になってから初めてスレッドと邂逅したんだろ。

187 :デフォルトの名無しさん:2011/10/03(月) 23:50:37.83
コンパイラとアーキテクチャを限定していて、
かつ、他の環境では不都合が起こる可能性があることを覚悟してるんなら、
volatileだろうが何だろうが使えばいいじゃない。

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

188 :デフォルトの名無しさん:2011/10/03(月) 23:52:21.19
std::atomicってvolatileなくてもよかったっけ?
volatile std::atomic<volatile int> a; みたいなサンプルコードをどっかで見たような

189 :デフォルトの名無しさん:2011/10/03(月) 23:56:24.04
>>188
いらない。
誰だよ、そんなサンプルコード書いた奴は

190 :デフォルトの名無しさん:2011/10/03(月) 23:58:02.53
atomicにvolatileはイラんでしょ イラんでしょ

191 :デフォルトの名無しさん:2011/10/04(火) 00:39:07.03
そうなの?
N3290確認したらstd::atomicってvolatileメンバ関数いっぱい持ってるんだけど
これってvolatile atomicとして使う必要がある場合があることを想定してるんじゃないの

192 :デフォルトの名無しさん:2011/10/04(火) 00:44:24.04
ふむ
想定してた名残じゃなければ気になるところ

193 :デフォルトの名無しさん:2011/10/04(火) 02:10:28.99
>>191
C1xとatomic関連の仕様を共通にしようとgdgdやってたときの名残。
当時はヘッダファイル名も<cstdatomic>だったりしたな。

194 :デフォルトの名無しさん:2011/10/04(火) 06:16:29.37
正直世の中のC++で使われているvolatileの99%は誤って使われてる

195 :デフォルトの名無しさん:2011/10/04(火) 09:23:15.83
結局スレッドのキャンセルにしかみんな使ってないけどなw

196 :デフォルトの名無しさん:2011/10/04(火) 09:39:35.63
>>191
内部実装のために必要。
volatileなければ、ポータブルなatomic実装書くことは不可能。

197 :デフォルトの名無しさん:2011/10/04(火) 09:58:31.95
仕様があいまいな属性が実装に必要て変な話だな

198 :デフォルトの名無しさん:2011/10/04(火) 10:31:42.66
そもそもvolatileってロードやストアを必ず1命令になるようコンパイルする仕様上の保証とかあったっけ?

199 :デフォルトの名無しさん:2011/10/04(火) 10:38:32.66
>>198
なぜそんな質問をいきなりするのか不明。


200 :デフォルトの名無しさん:2011/10/04(火) 10:39:08.52
>>199
ロード・ストアが1命令になるよう必ずコンパイルされるという仕様上の保証がなければ
「ポータブルに」atomicは書けないじゃん

201 :デフォルトの名無しさん:2011/10/04(火) 11:15:52.69
CASとか最低限のところだけasm volatile、後はvolatileを使ってる。
volatile修飾子なかったら全部asm volatileで書くしかない。


202 :デフォルトの名無しさん:2011/10/04(火) 11:20:49.50
volatile指定しても他のスレッドでのアクセスが反映される保証は無いというのは
昔から全く状況は変わっていないし何を問題にしているのかわからない
処理系依存のコードと誤ったコードというのは別だろ

203 :デフォルトの名無しさん:2011/10/04(火) 11:42:38.00
>>200
ポータブルに書く必要はないし、
std::atomicの下はこのスレの範囲外だよ。gccスレなりvcスレなりで話せばいい

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

205 :デフォルトの名無しさん:2011/10/04(火) 13:19:08.04
>>201
CASってなんだ?
工業用のあれでは無いよな。

206 :デフォルトの名無しさん:2011/10/04(火) 14:13:45.96
volatile と atomic 操作ってまったく関係ないのに
なんでごっちゃになってるの?

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

207 :デフォルトの名無しさん:2011/10/04(火) 14:40:43.25
>>206
>volatile と atomic 操作ってまったく関係ないのに
>なんでごっちゃになってるの?

エスパーすると、「Writeスレッドがread-modify-writeしない場合は、volatile指定すれば良い」という認識のサイトが多いから、それで勘違いしてるんでは?

208 :デフォルトの名無しさん:2011/10/04(火) 15:05:07.49
何が問題で誰が何に反論してるのかわかりにくいな

209 :デフォルトの名無しさん:2011/10/04(火) 15:44:54.96
>>207
このスレにはそんな書き込みしてる奴いないのにねえ。



210 :デフォルトの名無しさん:2011/10/04(火) 15:57:47.36
>>202
> volatile指定しても他のスレッドでのアクセスが反映される保証は無いというのは
> 昔から全く状況は変わっていないし

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




211 :デフォルトの名無しさん:2011/10/04(火) 16:06:18.66
<atomic>にvolatile T*の引数を持つ関数が定義されてる。
新しい規格でvolatileの意味がまともに決まってないと思える頭の構造が分からん。
「全てのスレッドで〜」と説明するサブセクションでvolatileが言及されてるのに!

212 :デフォルトの名無しさん:2011/10/04(火) 16:31:14.87
>>210
1章読み直したがやっぱり変わってないぞ

213 :デフォルトの名無しさん:2011/10/04(火) 18:03:43.98
よかったじゃん

214 :デフォルトの名無しさん:2011/10/04(火) 18:25:15.49
結局atomicにvolatile付けなきゃならないのはいつなんだよ

215 :デフォルトの名無しさん:2011/10/04(火) 19:47:22.14
atomicが最適化されて期待通りの動作にならないことがあるとか?

216 :デフォルトの名無しさん:2011/10/04(火) 21:27:21.33
http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
これって最新の規格?
まだ未確定の時のヤツ?

217 :デフォルトの名無しさん:2011/10/04(火) 21:31:37.67
atomicにvolatile入ってんのは、atomicがvolatile必要なんじゃなくて、
volatile用のatomicが必要だからオーバーロードしてあるだけじゃねぇか。

218 :デフォルトの名無しさん:2011/10/04(火) 21:35:32.82
上の方でatomicにはvolatile必要ないって散々言ってたのは何だったのか

219 :デフォルトの名無しさん:2011/10/04(火) 21:35:58.91
>>216
そもそも規格ですらない
ただのテクニカルレポート

220 :デフォルトの名無しさん:2011/10/04(火) 21:37:41.28
どんな時に必要になるのかって話じゃないの?
メモリマップドIOにatomic使う訳でもないだろうし

221 :デフォルトの名無しさん:2011/10/04(火) 21:40:00.58
>>218
いや正しいだろ。

222 :デフォルトの名無しさん:2011/10/04(火) 21:42:49.13
メモリマップドIOにatomic使うんだろ
組み込みの世界じゃコアが32個とかザラだし。

223 :デフォルトの名無しさん:2011/10/04(火) 21:49:18.29
マルチスレッドでvolatile使うよ派の方々はvolatile使って何したいの?

224 :デフォルトの名無しさん:2011/10/04(火) 21:50:33.29
その話題は終わった

225 :デフォルトの名無しさん:2011/10/04(火) 21:57:35.91
マジか
んじゃまぁいいや

226 :デフォルトの名無しさん:2011/10/04(火) 22:00:30.94
volatile atomicのまとめ。

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


227 :デフォルトの名無しさん:2011/10/04(火) 22:05:53.69
volatile atomic_short *p = (volatile atomic_short *)0xA0000000;
みたいにして使えるの?

228 :デフォルトの名無しさん:2011/10/04(火) 22:08:40.87
>>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 ]


229 :デフォルトの名無しさん:2011/10/04(火) 22:11:13.23
>>227
せめて正式版ではないにしろ>>216ぐらいは読め。

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


230 :デフォルトの名無しさん:2011/10/04(火) 22:11:52.61
なるほど

231 :デフォルトの名無しさん:2011/10/04(火) 22:38:22.87
>>193 >>196 いい加減なこと言いすぎだろ。


232 :デフォルトの名無しさん:2011/10/04(火) 22:48:43.94
auto x = new auto(’a’);

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


233 :デフォルトの名無しさん:2011/10/04(火) 23:11:17.03
なんで条件変数まで入って、メッセージキューが無いのか。
それはともかくusingが地味に便利っぽいな。多重継承したとき、
1つに実装があればその実装でオーバーライドできるとか。
なんで今まで出来なかったのか。

234 :デフォルトの名無しさん:2011/10/04(火) 23:15:06.32
TRで追加されるんじゃないか?

235 :デフォルトの名無しさん:2011/10/05(水) 01:37:13.95
>>222
メモリマップドIOに普通のint型とかじゃなくてatomicを使う理由は何?
volatile atomic<int>じゃなくてvolatile intでいいじゃん。

236 :デフォルトの名無しさん:2011/10/05(水) 01:51:02.01
マルチコアでメモリマップドI/Oした場合、
他のCPUが信号送ってる途中に割り込むから危険だろうが。

237 :デフォルトの名無しさん:2011/10/05(水) 02:39:44.19
>>236
メモリマップ領域の同じアドレスに、異なるスレッドが同時に書き込んだりは普通しないでしょ。
別途mutexなどで排他し、同時アクセスはしないようにするだろ。

238 :デフォルトの名無しさん:2011/10/05(水) 03:43:38.37
メモリマップ領域にcompare and setとかせんわなw

239 :デフォルトの名無しさん:2011/10/05(水) 03:56:35.32
そのmutexをさぼるためでしょ
ほっとくとvolatileだけで大丈夫キリッとか言い出す馬鹿がいるから

240 :デフォルトの名無しさん:2011/10/05(水) 07:18:03.94
>>228
これってatomic<T>をvolatile atomic<T>にキャストしてもvolatileにならないから注意しろって書いてあるだけだよね

241 :240:2011/10/05(水) 08:10:57.62
後半しか見てなかった。忘れてくれ。

242 :デフォルトの名無しさん:2011/10/05(水) 08:19:15.80
メモリマップドI/O使うヤツにそんな馬鹿は居ないだろうけど。

243 :デフォルトの名無しさん:2011/10/05(水) 12:56:41.08
>>237
atomicの書き方しってる?

244 :デフォルトの名無しさん:2011/10/05(水) 16:11:18.22
>>239
あるメモリアドレスAに1を書きこんでからアドレスBのデータを読み込み最後にアドレスAに0を書く、
みたいな一連の操作の排他は、アドレスAやBをatomic変数にしてもできないでしょ。


245 :デフォルトの名無しさん:2011/10/05(水) 16:35:48.58
見えない敵と戦ってる人相手にしても…

246 :デフォルトの名無しさん:2011/10/05(水) 16:43:31.80
>>244
「一連」の操作にするにはmutex必須だな
「書き捨て」でいいならatomicで足りる

247 :デフォルトの名無しさん:2011/10/05(水) 17:23:54.81
atomicが何してるかもまるでわかってないのによく書き込む気になるな

248 :デフォルトの名無しさん:2011/10/05(水) 22:17:58.62
大部分はなんもしないだろ

249 :デフォルトの名無しさん:2011/10/05(水) 22:34:38.51
>>246
お前恥ずかしくないか

250 :デフォルトの名無しさん:2011/10/05(水) 22:51:18.85
>>229
そのコードも変だぞ

251 :デフォルトの名無しさん:2011/10/05(水) 22:53:31.52
このスレでこのレベルじゃ
atomicとvolatileをマスターすれば食うに困らんな。

252 :デフォルトの名無しさん:2011/10/05(水) 23:39:25.04
volatileはもうお腹いっぱいです

253 :デフォルトの名無しさん:2011/10/05(水) 23:43:35.34
C++0xの仕様まともに把握してるの日本で何人いるんだ?

254 :デフォルトの名無しさん:2011/10/05(水) 23:59:21.77
hito_hpp

255 :デフォルトの名無しさん:2011/10/06(木) 00:02:04.23
まとめ
volatileを付けるかどうか迷ったら付けとこう

256 :デフォルトの名無しさん:2011/10/06(木) 00:07:41.33
externとconstとstaticもつけておくか

257 :デフォルトの名無しさん:2011/10/06(木) 00:51:52.74
>>251
このスレには素人しか居ませんから。

258 :デフォルトの名無しさん:2011/10/06(木) 01:21:52.12
で。std::vectorの連続性が保証されるのは今回からか?
それともまだ見送り?

259 :デフォルトの名無しさん:2011/10/06(木) 01:22:55.74
03から保障されてるでしょ

260 :デフォルトの名無しさん:2011/10/06(木) 01:40:24.28
で。std::dequeの連続性が保証されるのは今回からか?
それともまだ見送り?

261 :デフォルトの名無しさん:2011/10/06(木) 01:43:27.63
大事なことだったんですね!

262 :デフォルトの名無しさん:2011/10/06(木) 01:58:23.26
>>260
アホ

263 :デフォルトの名無しさん:2011/10/06(木) 02:09:09.06
>>260
実装がLinkedListによるものだったらどうするつもりなんだろう・・・。

264 :デフォルトの名無しさん:2011/10/06(木) 02:20:05.36
如何にも無理やり中身を抉り出してます感
全開のvectorの直列仕様もどうなんだろ。
もっとましなアドレス取得用のインタフェース用意してくれんかね。

265 :デフォルトの名無しさん:2011/10/06(木) 02:27:47.56
>>264
正直、C言語使わないのであれば、参照でVector本体を渡してしまうので、アドレスの直列性とかはあんまり気にならんなー。
Cであってもstdioでファイル書きこむときくらいじゃないかな?直列性なくて困るのって。

266 :デフォルトの名無しさん:2011/10/06(木) 07:22:35.45
配列とvectorとどちらにでも対応できないと
困る関数もあんだろ

267 :デフォルトの名無しさん:2011/10/06(木) 07:51:22.83
>>265
SIMDが面倒

268 :デフォルトの名無しさん:2011/10/06(木) 08:38:24.71
そういやvolatileって常にメモリーから読み出されるか
どうかはなんら保証は無いよな。
>>152みたいにいつ止まろうがどうでもいい例は別として。
もしかしたら無限ループになるかもしれんけど。

269 :デフォルトの名無しさん:2011/10/06(木) 09:29:15.31
仕様が複雑すぎて馬鹿大量精算

270 :デフォルトの名無しさん:2011/10/06(木) 10:39:00.69
>>268
マルチスレッドがらみじゃないならスレ違い、
初心者スレで教えてもらってこい。


271 :デフォルトの名無しさん:2011/10/06(木) 10:50:38.38
volatileひとつにこんな議論してたんじゃアプリができるころにはおじいちゃんだな

272 :デフォルトの名無しさん:2011/10/06(木) 11:24:57.53
念じた通りに動けば実装コードなんてどーでもいいんだよ

273 :デフォルトの名無しさん:2011/10/06(木) 12:35:10.62
>>265
Cでも列挙子のインターフェースを提供すればいいじゃないか
COMのCINTERFACEのように見苦しくなりかねないが下手に並べ直すよりもコストは低いと思う

274 :デフォルトの名無しさん:2011/10/06(木) 12:55:21.98
>>270
ここは規格についてのスレだろ


275 :デフォルトの名無しさん:2011/10/06(木) 13:00:29.65
>>270
初心者もくそもJIS規格読んでみろや知ったかぶり

276 :デフォルトの名無しさん:2011/10/06(木) 20:10:59.86
誤訳だらけのJISのC++規格なんか読んじゃいけません

277 :デフォルトの名無しさん:2011/10/06(木) 21:38:22.44
>>275
なんで ``JIS規格'' か, 汲んでやれよ
英語読めない低能だから吠えてんだろ?


278 :デフォルトの名無しさん:2011/10/07(金) 17:52:05.36
Javaのvolatile相当の機能があると思い込んでんだろ

279 :デフォルトの名無しさん:2011/10/07(金) 19:15:11.05
Javaのvolatileはちゃんと実装されてない事があるみたいな事聞いた事あるけど
今は違うのか?

280 :デフォルトの名無しさん:2011/10/07(金) 20:00:42.74
JavaやC#のvolatileとC/C++のvolatileは全く違う機能
CとC++0xのautoくらい違う

281 :デフォルトの名無しさん:2011/10/07(金) 20:09:11.55
んなこたー知ってる

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

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

282 :デフォルトの名無しさん:2011/10/07(金) 20:12:41.25
JavaSE5以降で解決したらしいよ。
JSR133によって仕様が云々とか。

283 :デフォルトの名無しさん:2011/10/07(金) 20:23:13.62
解決したのか
良かった良かった

284 :デフォルトの名無しさん:2011/10/07(金) 20:47:26.64
もう9年以上も前の話だしな。
さすがに、まだ未解決のはずがない。

285 :デフォルトの名無しさん:2011/10/07(金) 21:14:03.98
>>279
そっちでもやっぱり使い方間違ってる人がいる、
ってだけ。

286 :デフォルトの名無しさん:2011/10/07(金) 21:24:39.25


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

288 :デフォルトの名無しさん:2011/10/07(金) 21:46:25.88
仕様より実装のほうが大事
マニュアル読まない奴はカス

289 :デフォルトの名無しさん:2011/10/07(金) 21:54:38.27
メモリバリアは保証しないけど
永遠に異なる値を指す事はあり得ないので
タイミングが重要でないものに使うのは問題ないと何度言えば

290 :デフォルトの名無しさん:2011/10/07(金) 21:54:56.88
だったらGCCなり、IC++なり、CLなり処理系のスレで叫んでろよ。
規格のスレでほざくんじゃねぇ。

291 :デフォルトの名無しさん:2011/10/07(金) 21:58:36.61
>>289
割り込みと違ってスレッドの場合は、永遠と値が異なる処理系があっても構わん。
命令の順序さえ変わらなきゃいいんだから、少しでも早くしたいリアルタイム系の
処理系なら有りうる。

292 :デフォルトの名無しさん:2011/10/07(金) 22:00:02.20
thread_localでないものが同一オブジェクトを指さないのは規格違反じゃね

293 :デフォルトの名無しさん:2011/10/07(金) 22:01:37.14
なんの規格だよ。

294 :デフォルトの名無しさん:2011/10/07(金) 22:06:45.31
アドレス同じなのに値が永遠に異なるとか
具体的にどういう処理系があんだ

295 :デフォルトの名無しさん:2011/10/07(金) 22:12:40.36
1.アドレスを参照しない
2.関数を呼ばない

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

296 :デフォルトの名無しさん:2011/10/07(金) 22:18:13.92
処理系の検知できない手段で変更がある可能性を考えて
最適化はvolatileつきでは行わないとか
volatileオブジェクトはabstract machineのルールに厳密に従わないといけないとか
書いてあるんだけど

297 :デフォルトの名無しさん:2011/10/07(金) 22:22:51.54
で、レジスタに配置することが最適化になるかね?
レジスタかメモリーか、それどころかvolatileの向こうは
ハードウェアですらいいことになってるんだけど。

298 :デフォルトの名無しさん:2011/10/07(金) 22:23:35.66
別にレジスタに配置されてもいいけど
それを検知できるというのがvolatileだ

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

299 :デフォルトの名無しさん:2011/10/07(金) 22:27:58.44
そもそも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.


300 :>>299:2011/10/07(金) 22:29:27.68
紛らわしいこと書いたが。「保証されない」だからね。

301 :デフォルトの名無しさん:2011/10/07(金) 22:34:17.38
いつ値が変更されるか分からないという意味で揮発修飾なわけだが
変更する奴が誰か分かっていて、
さらに変更する奴がいないと分かってる状態で
永遠に異なる値を指してもいいってのは拡大解釈じゃね

302 :デフォルトの名無しさん:2011/10/07(金) 22:39:21.99
>>299 読めば解るが、値が勝手に変わらないことを保証したければvolatileを付けない。
volatileを付けた時点で変数が以前の値を保持する義務が無くなる。

303 :デフォルトの名無しさん:2011/10/07(金) 22:42:17.58
いや、別スレッドで値が変えられることを考慮するためには
値が勝手に変わる事を保証しないと駄目だろ
以前の値を保持されちゃ困るからvolatileつけるってのに

304 :デフォルトの名無しさん:2011/10/07(金) 22:46:00.78
勝手に変わる事を保証、じゃないや
別に保証はいらなくて考慮さえされてればいい

305 :デフォルトの名無しさん:2011/10/07(金) 22:46:09.01
だから、それはvolatileの使い方が間違ってんの。

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

306 :デフォルトの名無しさん:2011/10/07(金) 22:58:15.42
volatilleを値共有に使いたい場合、プロセス間でのメモリマップドを
応用すれば一番確実な方法は

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

って事らしい。

307 :デフォルトの名無しさん:2011/10/07(金) 23:04:11.69
volatileは左辺値のキャッシングを行わないだけで
左辺値のアクセス自体に対しては特に特殊な要求はないように見えるが

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

308 :デフォルトの名無しさん:2011/10/07(金) 23:09:25.25
誰もってのはハードウェアから鼻から出た悪魔まで含めての話な

309 :デフォルトの名無しさん:2011/10/07(金) 23:09:45.90
C++11からマルチスレッドを考慮した規格になったので、
volatileオブジェクトへの書き込みは他スレッドから見られることになりました。


310 :デフォルトの名無しさん:2011/10/07(金) 23:10:22.66
具体的に書いてあったっけ?

311 :デフォルトの名無しさん:2011/10/07(金) 23:11:01.37
とにかくvolatileで保証されるのは、副作用(I/O)のための順序だけ。
volatile変数がメモリー上に存在しないかどうかは完全に処理依存。

312 :デフォルトの名無しさん:2011/10/07(金) 23:11:27.52
>>309
ソース。

313 :デフォルトの名無しさん:2011/10/07(金) 23:12:27.63
volatileは普通ポインタにつけるから
グローバル変数の話はどうでもいいよ・・・

314 :デフォルトの名無しさん:2011/10/07(金) 23:16:09.08
組み込みの世界じゃアセンブリで実体をハードに割り当てる場合も割とあるけどな
extern const long hard_clock;


315 :デフォルトの名無しさん:2011/10/07(金) 23:16:58.27
あ、まちがえた
extern const volatile long hard_clock;

316 :デフォルトの名無しさん:2011/10/07(金) 23:18:12.99
その場合はセクション割り振るから
メモリアドレス振られるのは保証されるんじゃない

317 :デフォルトの名無しさん:2011/10/07(金) 23:22:37.92
アセンブラで実体作ってるから
レジスタには置かれないな

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

318 :デフォルトの名無しさん:2011/10/07(金) 23:23:37.96
ハードに割り当てる話は、メモリとレジスタ云々には関係ないぞ
ポインタじゃなくても使うことがあるという例を書いただけ

319 :デフォルトの名無しさん:2011/10/07(金) 23:29:35.55
グローバル変数でexternしてないvolatileの実体が
メモリに置かれるとは限らない、という話だが、
グローバル変数をレジスタに置くのは規格に沿うのだろうか
registerはグローバル変数に付けられないし

320 :デフォルトの名無しさん:2011/10/07(金) 23:48:49.69
あーでもstaticで一箇所からしか使ってなければ
あり得なくはない・・・のか?

321 :デフォルトの名無しさん:2011/10/08(土) 00:02:49.42
>>319
元々registerは強制的にレジスタを割り当てる修飾子だったんだから
広域変数に割り当てられないのは当然だろ。関数呼び出しがおかしくなる。

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

322 :デフォルトの名無しさん:2011/10/08(土) 00:22:10.59
関数内で割当て?
複数関数で使ってても?

323 :デフォルトの名無しさん:2011/10/08(土) 14:40:52.77
>>322
このスレを>>93あたりから読み直せ

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

325 :デフォルトの名無しさん:2011/10/09(日) 00:40:00.98
全てアセンブラで書いてるときに
複数スレッドで1つのレジスタを共有なんてのは当たり前

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

326 :デフォルトの名無しさん:2011/10/09(日) 03:12:36.26
どんな環境?

327 :デフォルトの名無しさん:2011/10/09(日) 05:09:23.78
>>325
全部アセンブリで書くことなんて無いだろ。
てか、アセンブラで書くなんてほざいてる時点で
まともにアセンブリコード書いたこと無いだろ。

328 :デフォルトの名無しさん:2011/10/09(日) 09:05:09.04
フルアセンブラでスレッド?

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

330 :デフォルトの名無しさん:2011/10/09(日) 09:43:30.72
割り込みはマルチスレッドとは言わない
コンテキストスイッチがない

331 :デフォルトの名無しさん:2011/10/09(日) 10:32:24.34
あるよ
逆に CPU アフィニティなんぞコンテキストスイッチのないマルスレだしな

332 :デフォルトの名無しさん:2011/10/09(日) 11:05:07.12
退避するレジスタをケチったりしたなあ

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

334 :デフォルトの名無しさん:2011/10/09(日) 11:33:27.06
>>331
> CPU アフィニティなんぞコンテキストスイッチのないマルスレだしな
は?
じゃあ、シングルコアCPUでのマルチスレッドでは「コンテキストスイッチ」がないのかい?
馬鹿馬鹿しい。

335 :デフォルトの名無しさん:2011/10/09(日) 13:29:20.72
スレッドはいつ他のスレッドが動いても問題ないというものだからな
割り込みは違うわな

336 :デフォルトの名無しさん:2011/10/09(日) 16:06:15.87
>>329
割り込みは、並列稼働しないだろ。
割り込み処理が終わるまで、
メインの処理は止まる。

337 :デフォルトの名無しさん:2011/10/09(日) 16:19:59.86
マルチスレッドの実装を語るスレはここですか?

338 :デフォルトの名無しさん:2011/10/09(日) 16:47:53.59
いや、スッドレの定義を主張するスレでそ

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

339 :デフォルトの名無しさん:2011/10/09(日) 16:50:22.01
スレッドセーフな関数と割り込みセーフな関数が違う時点で、
全然別物だと気づくはずなんだけどな。

340 :デフォルトの名無しさん:2011/10/09(日) 17:24:39.53
>>331
コンテキストスイッチなんてPen3以前の頃からあったろ

341 :デフォルトの名無しさん:2011/10/09(日) 17:34:12.67
>>332
どのCPUでどういう処理書いててレジスタの退避けちったの?
普通、一つのスレッドは全てのレジスタを使う可能性が有るし
正数演算系のレジスタは全て使い倒さないと非効率だから
全部退避対象になるでしょ。
スレッド間でレジスタ共有なんてしたら非効率な上に危険。

342 :デフォルトの名無しさん:2011/10/09(日) 18:02:44.96
>>325 に、どのCPUでどんなコード書いたか書いてもらうのが早いな。
OSもあるなら、なんていうOSか聞きたい。
でも結局、昔の(Z80とかであるような)割り込みなんだろうな、そうなら書かなくていいよ。

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

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

344 :デフォルトの名無しさん:2011/10/09(日) 18:24:18.15
アフィニティってCPU 固定するだけだろ
何が言いたいんだ?
アフィニティだろうがコンテキストスイッチは無くならんぞ。

345 :デフォルトの名無しさん:2011/10/09(日) 18:34:21.46
>>344
少なくとも減らすためにすることで
減らなかった分はアフィニティと関係ないし

346 :デフォルトの名無しさん:2011/10/09(日) 18:50:52.18
>>343
で、何が言いたいんだ?
今までの流れだと、お前はコンテキストスイッチの無い
スレッドが存在すると主張してるように見えたんだが。

347 :デフォルトの名無しさん:2011/10/09(日) 19:03:07.03
>>346
だから、そうだよ
違うって言いたいのか?

348 :デフォルトの名無しさん:2011/10/09(日) 19:49:51.41
まだやってんのかよお前ら
せめてC++11絡めて話せよ

349 :デフォルトの名無しさん:2011/10/09(日) 19:51:14.38
C++erの視野の狭さは異常

350 :デフォルトの名無しさん:2011/10/09(日) 20:01:44.68
>>347
お前の話に一度もコンテキストスイッチの存在しない
実在環境の話が出てない。

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

351 :デフォルトの名無しさん:2011/10/09(日) 20:36:50.79
>>350
そうか、聞きてえのかw >実在環境
お願いしろよ、言ってやるかも知んねえから

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

352 :デフォルトの名無しさん:2011/10/09(日) 20:41:30.13
帰レ知ったかぶり

353 :デフォルトの名無しさん:2011/10/09(日) 20:51:45.96
コンテキストスイッチでレジスタの内容がスレッド毎別になるだろ
レジスタ共有するにはわざわざそのレジスタの内容をメモリから復帰しないといけなくて
使い物にならない

354 :デフォルトの名無しさん:2011/10/09(日) 21:02:08.86
>>353
言語は使う人が何を考えることができるのかを決めてしまう by禿
もっともお前さんが言ってるのは言語より以前の話なんだが

355 :デフォルトの名無しさん:2011/10/09(日) 21:08:56.11
レジスタの内容退避しないで特定の協調スレッドへステートの一部をレジスタ渡しするようなゲテモノを想像してしまった
ここは何スレだ一体

356 :デフォルトの名無しさん:2011/10/09(日) 21:11:01.05
>>354
バカは言語に使われるbyゲイツ

357 :デフォルトの名無しさん:2011/10/09(日) 21:11:03.28
レジスタ1個1個退避と復帰やってんのか
ご苦労な事だ

358 :デフォルトの名無しさん:2011/10/09(日) 21:44:23.82
>>341
おれは >>331 じゃないが
80系とかをセンブラで書いても普通にタスクスイッチするよ?
# なければ作るし
割り込みだけは特別扱いで, 全部アセンブラってノリかな


359 :デフォルトの名無しさん:2011/10/09(日) 21:58:02.02
タスクスイッチするのはいいけど
レジスタ共有はないな

360 :デフォルトの名無しさん:2011/10/09(日) 22:05:01.18
>>359
まぁな


361 :デフォルトの名無しさん:2011/10/10(月) 15:43:22.96
>>354
言語以前にレジスタ機械の問題だろ

362 :デフォルトの名無しさん:2011/10/10(月) 15:56:56.63
>>349
> C++erの視野の狭さは異常

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

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

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

363 :デフォルトの名無しさん:2011/10/10(月) 15:59:17.97
C++0xスレにも>>362のようなドカタくせぇレスがつくようになったのか
C++もおしまいだな

364 :デフォルトの名無しさん:2011/10/10(月) 16:01:20.55
volataleは正直組み込み系の人位しか使ってないから誤解が多いのも事実
そしてJavaにも存在して意味合いが違ってたりしてまた混乱に拍車をかける

365 :デフォルトの名無しさん:2011/10/10(月) 16:14:22.39
volatileポインタにメモリマップドI/Oのアドレス割り当てたとして、
ハードウェアがその値を変更せずとも、
コンパイラが生成したコードが適当なタイミングで勝手に値を変えても規格合致だと?

本当か?

366 :デフォルトの名無しさん:2011/10/10(月) 16:44:58.35
>>365
既にソースが上がってるだろ。
読めよ。

367 :デフォルトの名無しさん:2011/10/10(月) 17:19:29.34
しかし、あの仕様ではなぁ。

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


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



もう、C++終われよ

368 :デフォルトの名無しさん:2011/10/10(月) 17:26:43.30
有り難がってるお前らの額に文字が浮かんでるぞ。



「馬、鹿、。。」の文字がw

369 :デフォルトの名無しさん:2011/10/10(月) 17:34:17.77
くだらん書き込みでageるなカス
このスレでageてる書き込みはほとんどカスの書き込みだな

370 :デフォルトの名無しさん:2011/10/10(月) 17:36:41.69
と、つまらんペーペーのカスが言っております。

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


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



371 :デフォルトの名無しさん:2011/10/10(月) 17:45:35.82
やるならもうちょっと上手く煽れよ頭悪いな

372 :デフォルトの名無しさん:2011/10/10(月) 17:55:21.12
>>366
ないぞ

373 :デフォルトの名無しさん:2011/10/10(月) 17:55:47.71
>>364
同期プリミティブ書いてる人も使っているよ。

374 :デフォルトの名無しさん:2011/10/10(月) 18:13:26.71
おいおいvolatileはCとC++は殆ど共通仕様だろ。
何仕様もまともに読めない癖にC++乏してんの。
そういうのは一通りiso読んでからやれや。

375 :デフォルトの名無しさん:2011/10/10(月) 18:17:20.49
>>372
>>287
C99の仕様解説だがC++とは共通。

376 :デフォルトの名無しさん:2011/10/10(月) 18:23:02.03
>>373
ソース


377 :デフォルトの名無しさん:2011/10/10(月) 18:30:17.51
>>372
volatileオブジェクトは複数プロセス間で共有する変数として適用可能って書いてるぞ

378 :デフォルトの名無しさん:2011/10/10(月) 18:38:26.19
static volatile、static const volatileオブジェクトはメモリマップドI/Oに適用可能
volatileオブジェクトは複数プロセス間で共有する変数として適用可能
const volatileオブジェクトは別プロセスで変更される変数として適用可能

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

379 :デフォルトの名無しさん:2011/10/10(月) 18:45:10.93
>>377
プロセスであってスレッドでは無い。

380 :デフォルトの名無しさん:2011/10/10(月) 18:50:02.81
>>378
75ページの20 volatileに書いてあるだろ。
以前の値を保持することは保証しない。

381 :デフォルトの名無しさん:2011/10/10(月) 19:08:56.21
ちょっと前までは知恵は無くても知識欲だけは有りそうなヤツラが集ってたのに
フリーズに入ってからこのスレもうグダグダ棚

382 :デフォルトの名無しさん:2011/10/10(月) 19:14:18.50
>>379
プロセス内でも共有されるのだからスレッドでも共有される
それにプロセスってのは単なる例に過ぎない

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

383 :デフォルトの名無しさん:2011/10/10(月) 19:28:50.61
>>382
スレッドとプロセスは全然違うだろ、何いってんだ?


384 :デフォルトの名無しさん:2011/10/10(月) 19:31:17.39
>>382
処理系依存ってのは、ずっと解ってることじゃん。

385 :デフォルトの名無しさん:2011/10/10(月) 19:40:30.12
>>383


386 :デフォルトの名無しさん:2011/10/10(月) 19:51:38.92
プロセス間の場合変数の実体を通して値を共有する事は基本無い。
基本的に共有領域へのポインタによるアクセスになる。
この時ポインタにvolatile修飾が有れば、
共有領域への書き込みは保証される。
ただし、ポインタ自信がどこに有るかは不定。

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

387 :デフォルトの名無しさん:2011/10/10(月) 19:58:20.71
>>364
入力されたパスワード領域を後で確実にクリアするのにもvolatile使ってなかったっけ?
なんか昔問題になったような気がする。std::secure_fillみたいのがあればいいな。

388 :デフォルトの名無しさん:2011/10/10(月) 20:22:22.52
>>382
メモリが共有されるスレッドと共有されないプロセスじゃ安全性が全然違。。。


389 :デフォルトの名無しさん:2011/10/10(月) 20:34:10.72
全てのオブジェクトは全てのスレッドで扱えるって規格に書いてあんだろ

390 :デフォルトの名無しさん:2011/10/10(月) 21:03:13.88
>>389
何の事だ?どの仕様のどこに書いてある?
それはスレッドの項目に書いてある内容で
volatile固有の話じゃないだろ。

391 :デフォルトの名無しさん:2011/10/10(月) 21:19:41.35
まあC++11だがな
volatile固有ではないが、volatileにも当然適用される

392 :デフォルトの名無しさん:2011/10/10(月) 22:21:07.68
要するにvolatileが無くても同じ

393 :デフォルトの名無しさん:2011/10/10(月) 22:22:23.39
逆に全てのスレッドで使えなかったオブジェクトなんてあったか?

394 :デフォルトの名無しさん:2011/10/10(月) 23:22:28.70
プロセスAとプロセスBで共有しているものは
プロセスAのスレッドa1とプロセスBのスレッドb1で共有しているし
プロセスAのスレッドa1とプロセスBのスレッドb2でも共有しているし
つまりプロセスBのスレッドb1とプロセスBのスレッドb2で共有しているということ

395 :デフォルトの名無しさん:2011/10/10(月) 23:38:15.86
>>394
バカじゃねぇの。プロセス間通信とスレッド間通信の問題で
一般化された概念がどうとかいってねぇだろ。

396 :デフォルトの名無しさん:2011/10/11(火) 00:06:36.55
馬鹿にも分かるように説明してくれ

397 :デフォルトの名無しさん:2011/10/11(火) 00:54:15.36
あれを出せばこれがダメ、これを出せばあれがダメ・・・。

398 :デフォルトの名無しさん:2011/10/11(火) 00:57:15.33
処理系依存で済む話がなぜここまで発展してんの

399 :デフォルトの名無しさん:2011/10/11(火) 01:00:51.34
>>202が言うには誤ったコードらしいですよ奥さん
でたらめな話だけど

400 :デフォルトの名無しさん:2011/10/11(火) 01:56:13.65
>>393 コントロールスタックなんてもんはスレッド固有じゃないとまずいんじゃね?


401 :デフォルトの名無しさん:2011/10/11(火) 03:56:07.50
C++11の新機能をかいつまんでまとめてくれよ。もうついていけてないわw

402 :デフォルトの名無しさん:2011/10/11(火) 05:03:57.84
>>401
http://ja.wikipedia.org/wiki/C%2B%2B0x

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

403 :デフォルトの名無しさん:2011/10/11(火) 05:27:43.32
要するにスレッド間でvolatileを使うな。
仕様じゃ保護されん。
それだけの話。

404 :デフォルトの名無しさん:2011/10/11(火) 05:57:41.54
ところでchar16_t/char32_tって嬉しい新機能なん?

405 :デフォルトの名無しさん:2011/10/11(火) 06:15:54.53
charにぶっこむよりいいんじゃね

406 :デフォルトの名無しさん:2011/10/11(火) 07:34:15.91
>>404
linux じゃwchar_t は32bit だし
移植したい人にはべんりでしょ。

407 :デフォルトの名無しさん:2011/10/11(火) 07:53:20.87
strlenの代わりにchar_traits<char16_t>::length()なんだよね?
wchar_tと比べてなんか面倒くさそう
てかchar16_tってサロゲートペア考慮してるのかな

408 :デフォルトの名無しさん:2011/10/11(火) 08:07:30.52
は? それ char ってシフトJIS考慮しているのかな?と同レベルの質問だぞ。

409 :デフォルトの名無しさん:2011/10/11(火) 08:20:07.76
>>407
一応UTF系はサポートするそうな。
詳しくは仕様書見ろ。

410 :デフォルトの名無しさん:2011/10/11(火) 09:20:23.89
__STDC_ISO_10646__でない場合、他のUNIX系だとwchar_tはopaqueだったりするしなあ
別に型用意した分混乱少なさそうだけど、実際どういう使われ方になるのかなと

411 :デフォルトの名無しさん:2011/10/11(火) 10:15:31.84
>>399
処理系依存のコードであって誤ったコードではないと言ったんだよ
当たり前だろ

412 :デフォルトの名無しさん:2011/10/11(火) 10:38:57.49
>>411
正確には「処理系依存」ではなく「未定義動作」だ。

413 :デフォルトの名無しさん:2011/10/11(火) 10:42:00.01
どのコードが未定義動作だって?

414 :デフォルトの名無しさん:2011/10/11(火) 10:53:21.95
>>413
ループ脱出を他スレッドから指示するフラグ変数のように、
C++0xではstd::atomicを使うべきところに
単なるvolatile変数を用いているコード。

415 :デフォルトの名無しさん:2011/10/11(火) 11:00:06.43
>>410
char16_t/char32_tは読み込み用のバッファにして使う時はwstringに変換するとか?
もしいろんなライブラリがwchar_tから移行するなら移行するんだろうけど、どうなんだろ

416 :デフォルトの名無しさん:2011/10/11(火) 11:25:42.89
>>414
C++11 のスレッドで使うと data race が発生するから未定義動作、ってことでおk?
それって C++03 までは単に処理系依存なコードじゃないの?

417 :デフォルトの名無しさん:2011/10/11(火) 11:41:38.35
>>416
C++03単体で言えば undefined でしょ。仕様書でスレッドについて何も定義していないんだから。
C++03 + pthread みたいに組み合わせてはじめて
処理系依存だとかそういう話ができるわけで

418 :デフォルトの名無しさん:2011/10/11(火) 12:29:17.61
>>417
規格で何も定義していないことを指して未定義動作だとか undefined だとか、
明示的に未定義とされた箇所とまぎらわしいからやめてくれ。

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

419 :デフォルトの名無しさん:2011/10/11(火) 13:29:29.52
>>418
なんで区別する必要がある?
明示的だろうとそうでなかろうと、
仕様書の範囲外のことなので実装がどうなってようが関知しない
ってことでしょうが。

420 :デフォルトの名無しさん:2011/10/11(火) 14:29:01.99
>>419
ライブラリとしてスレッドが実装・利用されていた事実に反すると思ったんだけど、
規格としてはそうなるか。

ごめんよ。

421 :デフォルトの名無しさん:2011/10/11(火) 19:35:27.92
>>412
処理系依存です

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

422 :デフォルトの名無しさん:2011/10/11(火) 19:58:56.25
>>421
C++11の仕様書にはそんな文言は書かれてないんだが

423 :デフォルトの名無しさん:2011/10/11(火) 20:07:08.68
C99に書かれている
で、C++11

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

424 :デフォルトの名無しさん:2011/10/11(火) 20:17:13.77
特記するような事でなければ、
この手は、Cに倣えだからな。

425 :デフォルトの名無しさん:2011/10/11(火) 20:19:24.37
>>423
"In general"とか"intended to"の意味わかってる?
>416にもあるように、C++11では明示的に undefined behavior と書かれている。(1.10.21)

426 :デフォルトの名無しさん:2011/10/11(火) 20:30:16.26
ならC++03までは処理系依存ってことで

427 :デフォルトの名無しさん:2011/10/11(火) 20:46:11.93
これからは未定義だ。良かったな。

428 :デフォルトの名無しさん:2011/10/11(火) 20:50:22.61
明示的に implementation-defined と書いてなきゃ
それは undefined だろ

429 :デフォルトの名無しさん:2011/10/11(火) 21:28:35.59
最初にC99の仕様出してきた人に文句言ってくれ

430 :デフォルトの名無しさん:2011/10/12(水) 01:18:57.38
>>423(>>421)
それ C99 の規格じゃなくて rationale でしょ。ちゃんと区別してね。

431 :デフォルトの名無しさん:2011/10/12(水) 01:45:34.40
>>425
> C++11では明示的に undefined behavior と書かれている。(1.10.21)

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


432 :デフォルトの名無しさん:2011/10/12(水) 01:47:31.03
でも同じ変数にアクセスする以上
未定義の振る舞いになっちゃうんじゃないの?

433 :デフォルトの名無しさん:2011/10/12(水) 01:53:00.20
>>432
> でも同じ変数にアクセスする以上
> 未定義の振る舞いになっちゃうんじゃないの?

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


434 :デフォルトの名無しさん:2011/10/12(水) 01:55:24.15
「このようなデータレースは未定義の振る舞いをもたらす」
と書いてるから、何がっつーか、やった途端鼻から悪魔が出てくるんじゃないの?

435 :デフォルトの名無しさん:2011/10/12(水) 02:13:01.91
>>431
> ここはraceの話で、volatile関係ない。
そうだよ。data raceの条件にvolatileの有無は関係なく、
そしてdata raceの結果はundefined behaviorだ。
それが何か?

436 :デフォルトの名無しさん:2011/10/12(水) 02:16:47.27
>>414がおかしい。

437 :デフォルトの名無しさん:2011/10/12(水) 02:18:54.31
>>435
> そしてdata raceの結果はundefined behaviorだ。

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


438 :デフォルトの名無しさん:2011/10/12(水) 03:01:01.85
なんでそんなに必死なんだ?
undefinedって書いてあるんだから、その通りに解釈すればいいじゃない。

439 :デフォルトの名無しさん:2011/10/12(水) 03:26:20.94
>>438


440 :デフォルトの名無しさん:2011/10/12(水) 07:15:46.19
結果はundefinedだろ
具体的に言える訳が無い

441 :デフォルトの名無しさん:2011/10/12(水) 11:27:49.30
C++11ではatomic objectがvolatileであれば、
他スレッドの書き込みが別のスレッドからobservableであることが保証されている。
そういうメモリモデルが採用されている。

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

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


442 :デフォルトの名無しさん:2011/10/12(水) 11:54:39.05
>>441
> C++11ではatomic objectがvolatileであれば、
> 他スレッドの書き込みが別のスレッドからobservableであることが保証されている。
それはvolatileの有無に関係なく保証されてる。(1.10.25および29.3.13)

443 :デフォルトの名無しさん:2011/10/12(水) 13:57:52.86
>>441
APIも定義されてるでしょ。
memory_order_seq_cstとか。

444 :デフォルトの名無しさん:2011/10/12(水) 18:30:13.17
>>441
volatile だけだ書いてあるソースを書け。

445 :デフォルトの名無しさん:2011/10/12(水) 18:32:24.70
なんでボラ厨は仕様書を読まないの?
ここはC++11という規格のスレだよね。

446 :デフォルトの名無しさん:2011/10/12(水) 20:38:25.53
atomicならそりゃそうだろう

447 :デフォルトの名無しさん:2011/10/12(水) 21:15:54.20
>>443
標準規格にAPIなんざ無いぞ。

448 :デフォルトの名無しさん:2011/10/12(水) 22:27:30.02
>>447
ん?
APIってのが「スレッド間のメモリ可視性に関わるAPI」のことだと思ったから、
それならメモリバリア指定とかがそうだよね、と言ってるんだが。

449 :デフォルトの名無しさん:2011/10/12(水) 22:44:43.37
APIってのは特定のプラットフォーム向けの物であって
C++の規格という一般的で汎用的なものにそんなものが混じり込んでるはずはない

450 :デフォルトの名無しさん:2011/10/12(水) 22:55:15.58
>>449
普通にあるでしょ、exit の概念とか
ファイル名が DD name なのか DSN なのかとか

451 :デフォルトの名無しさん:2011/10/12(水) 23:13:06.51
すまん。プログラム超初心者でう。
for 文について教えてくれないか・・・・

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

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

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

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

452 :デフォルトの名無しさん:2011/10/12(水) 23:18:56.39
とりあえずこのスレでやる話じゃない
ここはC++11の規格に関して語るスレ
VBの話ならVBのスレに行った方が良いよ

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

453 :デフォルトの名無しさん:2011/10/12(水) 23:21:15.02
breakとかcontinueとかをしらべるがよろし。

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

455 :デフォルトの名無しさん:2011/10/12(水) 23:50:47.48
何かを利用する為のインタフェースは全部APIでしょ
別に最下層でないといけないわけではない
WebサービスAPIとか

iostreamもI/O用のAPIだよね

456 :デフォルトの名無しさん:2011/10/13(木) 00:04:06.13
WebサービスAPIは、Webとのゲートだから間違っちゃ無い。
それにWebサービスAPIは、それ以上上位の機能は提供しないだろ。

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

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

457 :デフォルトの名無しさん:2011/10/13(木) 00:12:50.65
「いろんなAPIの定義があります」で良いではないか良いではないか
http://en.wikipedia.org/wiki/Application_programming_interface

458 :デフォルトの名無しさん:2011/10/13(木) 00:15:37.32
>>452.453
ありがとなー

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

459 :デフォルトの名無しさん:2011/10/13(木) 00:17:27.49
InterfaceじゃないのにAPIってのもなぁ

460 :デフォルトの名無しさん:2011/10/13(木) 00:17:51.60
C++の規格的にAPIという語句はundefinedということでひとつ

461 :デフォルトの名無しさん:2011/10/13(木) 00:24:25.00
APIという単語自体曖昧だからな

462 :デフォルトの名無しさん:2011/10/13(木) 00:28:23.06
少なくともWin APIが台頭してた頃ははっきりしてたろ
OSへのアクセス手段 = API

463 :デフォルトの名無しさん:2011/10/13(木) 00:38:42.28
スレッドだと green thread ってのもあるから、システムコールが無くても実装できるんですが。

464 :デフォルトの名無しさん:2011/10/13(木) 00:49:59.72
attributeって結局pragmaと同程度の実装依存なのか?
カスタムattributeとか作れんのかね。関数がstatic変数を戻り値で返す場合、
参照で受け取ると警告出したりしたいんだけど。

465 :デフォルトの名無しさん:2011/10/13(木) 01:10:41.01
attributeはもうほとんど存在意義が無いんだよね
finalとか全部キーワード・・・とは微妙に違うけど、そんな感じのになっちゃったし

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

467 :デフォルトの名無しさん:2011/10/13(木) 01:58:51.79
まあboostとかでマクロ定義するのが楽にはなるな

468 :デフォルトの名無しさん:2011/10/14(金) 19:02:49.64
謹んでお悔やみ申し上げます。我々は、偉大な逸材を失った
ttp://tech.slashdot.org/story/11/10/13/0328230/dennis-ritchie-creator-of-c-programming-language-passed-away


469 :デフォルトの名無しさん:2011/10/14(金) 21:09:29.82
携帯のストラップが死んだのかと思った。


470 :デフォルトの名無しさん:2011/10/14(金) 21:11:03.55
スッポスッポは60歳だからまだまだこれからじゃきに
毛根は死んでるけど

471 :デフォルトの名無しさん:2011/10/15(土) 00:38:06.58
そろそろ値型のWrapperが用意されてもいいだろうに、
いくつ規格を重ねれば登場するんだろう?
完全抽象化Classを親に持つWrapperがあれば、
0階Tensorの実装がスゲェ楽になるのに。

472 :デフォルトの名無しさん:2011/10/15(土) 10:01:52.47
カーニハンは蟹飯ってあだながあるけど、リッチーはにちゃんねるでは何って呼ばれてんの?

473 :デフォルトの名無しさん:2011/10/15(土) 10:50:49.06
立地ん。

474 :デフォルトの名無しさん:2011/10/15(土) 11:47:26.45
リッチーはRPGみたなゲームでおなじみのアンデッド系キャラだよ。
つまり「スケルトン」「バンパイア」「ゾンビ」と同様に死んでいるけど
死んでない厄介なキャラだ。日本では【死神】と言われる場合が多い。

475 :デフォルトの名無しさん:2011/10/15(土) 16:14:35.86
オビワン

476 :デフォルトの名無しさん:2011/10/15(土) 16:17:41.41
リッチー
http://iphoneac.com/images/ff/ff113.jpg

477 :デフォルトの名無しさん:2011/10/15(土) 16:56:16.86
なんか本の虫氏が「日本語の解説本なんて滅べ。そうすりゃプログラマは全員英語読めるようになる」
みたいな事書いてるんだけど、やっぱC++11本は英語で出版するみたいなことにはしないでおくれよ?
1万円くらいまでなら買う気だからさ。(´・ω・`)

478 :デフォルトの名無しさん:2011/10/15(土) 17:02:05.06
ちょっと厨二病をこじらせてるだけだから
ほっとけば治るよ

479 :デフォルトの名無しさん:2011/10/15(土) 17:24:39.89
そのうちC++11の解説本が出て、翻訳も出るよ。
メイヤー先生のも結構いいし、増補版出すだろうし。

480 : ◆qQ4COMPILE :2011/10/16(日) 00:40:01.49
メイヤーさん C++11 本だすの?

481 :デフォルトの名無しさん:2011/10/16(日) 13:48:55.07
今更だけど override は頭に書きたかったなあ
行頭で揃ってないといじいじする

482 :デフォルトの名無しさん:2011/10/16(日) 14:06:38.62
>>480
出してもらわないと困る
C++11が出ると思って長い事C++本買ってないし

483 :デフォルトの名無しさん:2011/10/16(日) 14:29:33.63
C++11の本出た所で、まだ準拠率99%超えの実装がないから仕方が無い・・・

484 :デフォルトの名無しさん:2011/10/16(日) 18:26:26.28
だれか、禿に哀悼の意を伝える本を準備していろ。

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


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

485 :デフォルトの名無しさん:2011/10/16(日) 19:03:46.63
>>484
だれか一行にまとめて。

486 :デフォルトの名無しさん:2011/10/16(日) 19:16:08.47
>>484最強伝説。

487 :デフォルトの名無しさん:2011/10/16(日) 19:35:37.81
文句あるならてめーが純国産のプログラム言語を作りやがれ
てめーができないことを人に言うな

488 :デフォルトの名無しさん:2011/10/16(日) 19:43:57.51
和算を廃止し、洋算を専ら用ふるべし
と明治政府も言っております

489 :デフォルトの名無しさん:2011/10/16(日) 20:03:13.52
>>487
今使ってるコンピュータがですね、欧米産のノイマン型コンピュータなのですよ。
その理論だと、そこから自作するの?

490 :デフォルトの名無しさん:2011/10/16(日) 22:17:49.81
国産とか何が嬉しいのか。ナショナリストなのか。ここはコスモポリタン(笑)のスレ。

491 :デフォルトの名無しさん:2011/10/16(日) 22:19:46.60
生殺与奪を外国に握られているのはあまりいい事ではないな

492 :デフォルトの名無しさん:2011/10/16(日) 22:20:28.05
じゃあ石油は使えないな。

493 :デフォルトの名無しさん:2011/10/16(日) 22:38:18.58
>>484 くだらん書き込みでageるなカス

494 :デフォルトの名無しさん:2011/10/16(日) 22:43:21.62
国産うれしいじゃん
政治的圧力で潰されたけど

495 :デフォルトの名無しさん:2011/10/16(日) 22:52:37.57
自給可能なエネルギーがあるってのは強い事
アメリカはあれだけ戦争してるのもエネルギーのためで

496 :デフォルトの名無しさん:2011/10/17(月) 00:57:34.99
明治ぐらいの時期にほとんどの外来語の対応翻訳日本語がつくられて日本語と英語の違いはあまりなくなっているのに
英語がすばらしいとか連呼しているC++本作者がいると聞いて飛んできました
http://turezurebana2009.blog62.fc2.com/blog-entry-53.html


497 :デフォルトの名無しさん:2011/10/17(月) 01:14:53.19
>>496
前半はみんな興味ない話題だろうけど
後半に明治の時期に作られた新語「平和」の話がある

498 :デフォルトの名無しさん:2011/10/17(月) 05:45:16.51
>>496
本の虫の人のことなら、あれは古文至上主義だろ
英語はできて当たり前っつってるだけで(俺はそうは思わんけど)
ブログ読んでないのに言うなよ・・・

499 :デフォルトの名無しさん:2011/10/17(月) 12:19:18.04
>>489
ほう、おまえさんが使っているコンピュータが欧米の工場で生産されたロットなのか
そのことはプログラム言語の仕様とどう関係があるんだ?

500 :デフォルトの名無しさん:2011/10/17(月) 12:54:45.37
>>499
スレチ
http://hibari.2ch.net/test/read.cgi/tech/1179424842/

501 :デフォルトの名無しさん:2011/10/18(火) 00:11:34.22
まぁ新しめの概念とか和訳しにくにものは原語使った方が早いな

502 :デフォルトの名無しさん:2011/10/18(火) 02:58:38.61
どうしたらそんなTYPOになんねや

503 :デフォルトの名無しさん:2011/10/18(火) 21:22:25.72
さて、今回大規模に拡張したから
あと5年位したらやっぱり03と同じような
安定版というかマイナーバージョン的な規格が出るんだろうか。
11への本格的な乗り換えはその頃だろうな。

504 :デフォルトの名無しさん:2011/10/18(火) 21:25:04.26
vectorの連続性を保証しておいて
data()メンバ関数を追加しなかった03か

505 :デフォルトの名無しさん:2011/10/18(火) 22:56:55.44
えー。ただちにshared_ptrとscoped_ptrは使いたいし
ちょっと勘違いするくらいラムダ式を愛用していきたいよ・3・

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

506 :デフォルトの名無しさん:2011/10/18(火) 23:12:16.70
ローカル関数なんてないが
ラムダ式をそれっぽく使う事は可能だな

507 :デフォルトの名無しさん:2011/10/18(火) 23:28:29.94
ポインタの解放忘れってそんな重要か?
ほんとにシビアなら循環参照も確保解放順番も考える必要があるし
そこまで考えてるならなくても書けるよ

508 :デフォルトの名無しさん:2011/10/18(火) 23:34:48.57
scoped_ptrはboostや
unique_ptrや

509 :デフォルトの名無しさん:2011/10/18(火) 23:47:14.72
言語間の単語の輸入はその概念を本当に理解してないと無理だからね
英語じゃないと伝えられないとか言っちゃう奴は理解力と論理構成力がイマイチなことが多い
ちょっと人より英語ができたくらいで俺って頭イイとか勘違っちゃうからこんなことになる
ニートにはニートの理由があるってことだな
高い授業料だと思ってあきらめたら?

510 :デフォルトの名無しさん:2011/10/18(火) 23:51:59.99
毒電波の多い季節なのか?

511 :デフォルトの名無しさん:2011/10/19(水) 02:28:34.51
ニートの独電波
http://www.suri.cs.okayama-u.ac.jp/~niitsuma/real-life-bot/index.htm


512 :デフォルトの名無しさん:2011/10/19(水) 06:09:50.51
英語圏におけるラテン語からの翻訳などでも、優れた仕事は芸術とみなされる。
翻訳は常にクソとかいってるのはただの思考停止。

513 :デフォルトの名無しさん:2011/10/19(水) 12:01:38.25
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
という実行結果は起こり得る。



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

514 :デフォルトの名無しさん:2011/10/19(水) 13:02:55.64
>>513
常にmemory_order_seq_cstだけ使え。
そうすりゃそんなこと考えなくて済む。

515 :デフォルトの名無しさん:2011/10/19(水) 13:15:52.24
>>514
嫌な事、つらい事から目を逸らしてなかったことにするのは日本人の悪い癖ですよ

516 :デフォルトの名無しさん:2011/10/19(水) 18:48:41.80
>>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での変更結果が可視になる)

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

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

518 :デフォルトの名無しさん:2011/10/19(水) 20:41:56.91
>>517
いつThread3/4がThread1/2より後に実行されると錯覚していた?

519 :デフォルトの名無しさん:2011/10/19(水) 20:44:10.99
CPUにはそれぞれキャッシュというものがあってだな

520 :デフォルトの名無しさん:2011/10/19(水) 20:49:50.90
>>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にならない????


521 :デフォルトの名無しさん:2011/10/19(水) 21:26:41.12
>>517
> store/loadは排他して主記憶に書きこむ主記憶から読み込むという命令なんじゃないですか?
違う。排他なんかしない。あくまでatomicityを保証するだけだ。

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

522 :デフォルトの名無しさん:2011/10/19(水) 22:06:15.03
経験よりも歴史を信じるんだ!

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

523 :デフォルトの名無しさん:2011/10/20(木) 01:47:56.30
>>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の順になる
という処理系が存在しないということを規格は保証できない

524 :デフォルトの名無しさん:2011/10/20(木) 02:56:59.28
まあ結局自分の低能を棚に上げて
いやぁ〜日本語なんて意味ないわ〜やる気無くしちゃったなぁ〜
みんなボクくらいの英語力身につけるべきだよ(チラッチラッ
ってことだからな
テメーはミサワかとw

525 :デフォルトの名無しさん:2011/10/20(木) 03:18:48.74
ただの弱音だろうからほっといてやれよw
英語の規格や文献を調べてそれをまとめるような時間が増えると、
参考文献だけ紹介して同じもの読ませた方が誤解の余地無いんじゃね?とか思うんだろ。

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

526 :デフォルトの名無しさん:2011/10/20(木) 07:11:22.12
なんか脈絡の無いレスを付けるヤツが出てきたな。
何が言いたいのか解らんからコテハン付けてくれ。

527 :デフォルトの名無しさん:2011/10/20(木) 18:56:56.35
http://www.suri.cs.okayama-u.ac.jp/servlets/APPLICATION.rkt
schemeからc++0xの自動生成

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

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

528 :デフォルトの名無しさん:2011/10/20(木) 19:49:01.23
>>523
そんな基地外みたいな動作するマシンがあるわけないだろ
お前の処理系壊れてるよ

529 :デフォルトの名無しさん:2011/10/20(木) 20:09:34.11
NUMA始めそんな基地外みたいな動作する具体例はいくらでもあるかと

530 :デフォルトの名無しさん:2011/10/20(木) 20:47:05.03
じゃあatomicはcacheにアクセスしてるのか


531 :デフォルトの名無しさん:2011/10/20(木) 21:11:41.63
cacheをフラッシュさせてんじゃないの

532 :デフォルトの名無しさん:2011/10/20(木) 21:23:02.32
昔使っていたccNUMA機だと、load linked/store conditionalでアクセスすればOKだった。
atomicさんの中身はほとんどこの類いだろう。

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

533 :デフォルトの名無しさん:2011/10/20(木) 22:01:44.08
マジか最近のCPUって基地外ばっかりなのか
誰が得するためにそんな事になってんだ

534 :デフォルトの名無しさん:2011/10/20(木) 22:08:35.65
なので結論は >>514 で良いかと

535 :デフォルトの名無しさん:2011/10/20(木) 22:11:58.30
でもLockFreeとかWaitFree書くには必須技術なんだろ

536 :デフォルトの名無しさん:2011/10/20(木) 22:20:54.94
lock-free/wait-free かどうかと sequentially consistent かどうかは
一般には独立した概念では?

537 :デフォルトの名無しさん:2011/10/20(木) 22:22:40.00
memory_order_seq_cst以外のはよほど高速化が必要な場合のみってことか

538 :デフォルトの名無しさん:2011/10/20(木) 22:23:25.39
>>535の言っているのは知らなきゃ書けないってことだろ。
どういう突っ込みなんだよ。

539 :デフォルトの名無しさん:2011/10/20(木) 22:30:09.77
>>528
ほかの人が言ってるようにNUMAの計算機はThread3,4がそれぞれThread1,2の実行順序を互いにあべこべに観測する可能性がある。まぁそれはおいといて、
「Thread3から見たときにThread1->Thread2の順で
Thread4から見たときにThread2->Thread1の順になる
という処理系が存在する」ということも規格は保証しないよ
もちろん、「俺が持ってる処理系がそうである」ということも規格は保証しない

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

540 :デフォルトの名無しさん:2011/10/20(木) 22:35:16.45
とりあえずatomicならlong longを操作しても割り込まれて上位下位ビットが変になったりはしないんだろ
オレのような底辺にはそれだけわかれば十分だよ。ループ制御とか簡単な部分はatomicで、それ以外は安全重視でmutex使うし


541 :デフォルトの名無しさん:2011/10/20(木) 22:40:45.21
>>538
いえ, lock-free/wait-free に関する話は
メモリオーダーに関する話を完全に脇に置いておいて
sequential consistency を前提にした上で議論できますし,
少なくとも lock-free/wait-free に関して最初に学ぶ段階では
実際そうすべきではないかと.

542 :デフォルトの名無しさん:2011/10/20(木) 22:41:47.02
C++のmutexはメモリバリアを保証すんの?

543 :デフォルトの名無しさん:2011/10/20(木) 22:45:50.24
「最初に学ぶ段階では」
付けてなかった限定を付けるタイプの詭弁ですね。

544 :デフォルトの名無しさん:2011/10/20(木) 22:49:11.52
>>542
(実際にメモリバリアかどうかはともかく)
メモリバリアに相当する機能を持つことは保証されます

545 :デフォルトの名無しさん:2011/10/20(木) 22:56:12.35
>>528
"write atomicity" でググれ。
海外のMLとかでも、未だにちょくちょく議論になることがある。

546 :デフォルトの名無しさん:2011/10/20(木) 23:19:20.59
こんなの標準化しないほうが良かったのではないか
わかったつもりで書いた不良コードが世界中で量産されそうだ

547 :デフォルトの名無しさん:2011/10/20(木) 23:20:14.07
お前もう何も書かなくてもいいよ。

548 :デフォルトの名無しさん:2011/10/21(金) 07:33:17.47
デフォルトのmemory_order_seq_cstだけ使ってりゃ良いんだから
気にしなくて良い

549 :デフォルトの名無しさん:2011/10/21(金) 08:47:00.74
でも気になる!

550 :デフォルトの名無しさん:2011/10/21(金) 16:28:07.85
>>546
その意見も、ある意味もっともだ。

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

551 :デフォルトの名無しさん:2011/10/21(金) 19:28:59.05
インテルがC++の都合だけで動くわけないだろ…

552 :デフォルトの名無しさん:2011/10/21(金) 19:38:41.23
そこに高速化の余地があるなら環境依存性やリスクがあってもコンパイラやプログラマに選択する権利を与えるのがCの規格の方向性だ

553 :デフォルトの名無しさん:2011/10/21(金) 21:35:10.68
まあC++らしいよね

554 :186:2011/10/22(土) 09:43:30.71
>>552
ハードとソフトは相互依存とは言うが、そのうち、CPUはC Processing Unitの略だと勘違いする奴が出て来そうだな。

555 :デフォルトの名無しさん:2011/10/22(土) 09:48:18.55
コンパイラでsec_cst以外を弾くオプションか強制するオプションが必要。仕様に入れとけ
バグだらけになってC++はクソ言語って悪評がつくぞ
そしてみんなC系列にうんざりしてD言語に移動する



556 :デフォルトの名無しさん:2011/10/22(土) 09:53:40.88
Dも系列で言えばC系列だろ


557 :デフォルトの名無しさん:2011/10/22(土) 09:58:50.26
>>555
>仕様に入れとけ
これ言う人って、自分では提案する勇気もスキルも無いけど、誰かがやってくれたら、俺が主張していた事だって自慢するのかな?


558 :デフォルトの名無しさん:2011/10/22(土) 10:01:19.49
>>557
ひねくれてんな
性格矯正おすすめするよ


559 :デフォルトの名無しさん:2011/10/22(土) 15:52:12.69
C99と同じ運命になりそうだな。
実装された処理系がほとんど登場しないと・・・

560 :デフォルトの名無しさん:2011/10/22(土) 15:55:24.08
ライブラリの要求は高いので空気にはならんだろうね。
constexprもrvalue関係もほぼ必須だし。

561 :デフォルトの名無しさん:2011/10/22(土) 16:34:34.38
C99とは違ってVCがそれなりにやる気出してるから大丈夫だろ
まあVC11の実装は期待できないけど

562 :デフォルトの名無しさん:2011/10/22(土) 21:15:26.97
そのやる気は変な方向に行ってるけどな
独自の文法を更に追加。
attributeとは何だったのか。

563 :デフォルトの名無しさん:2011/10/22(土) 21:42:51.79
VC11出るん?

564 :デフォルトの名無しさん:2011/10/22(土) 21:43:17.66
C++/CLIと共存させないといけないからか?

565 :デフォルトの名無しさん:2011/10/22(土) 22:32:32.87
そりゃ当然あるだろう
MSの製品にするにはIDEごと対応表明せなあかんし

566 :デフォルトの名無しさん:2011/10/23(日) 22:13:23.37
APIを全部Win FXに入れ替えて
アプリケーションはすべて仮想マシン上で動くものとし、
中間コードを優遇してネイティブコードを殲滅させるという
Microsoftの野望は潰えたの?

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

567 :デフォルトの名無しさん:2011/10/23(日) 22:17:21.36
滅ぶわけないからその仮定は無意味

568 :デフォルトの名無しさん:2011/10/23(日) 22:21:59.56
プログラム板って煽りが多すぎて全然楽しくない

569 :デフォルトの名無しさん:2011/10/23(日) 22:22:49.08
おまえにきにいってもらおうとはおもわん

570 :デフォルトの名無しさん:2011/10/23(日) 22:27:04.11
普通は楽しもうと思ったら、話題を提供するか、金を払うかくらいじゃないの?

571 :デフォルトの名無しさん:2011/10/23(日) 22:27:46.47
他の板ではIDがつくから、イヤならすぐにけせるね

572 :デフォルトの名無しさん:2011/10/23(日) 22:29:30.47
>C++なんて存在意義なくなっちゃう
「Windowsにおいては」という限定をつけたらどうだろう?
セキュリティ強化のためにアプリケーションはすべて仮想マシン上でという
発想が本当に実現したとするなら、アンマネージドなコードを書けなくなるので
その環境ではC++の利点性は大幅に激安になると思いに蹴りな久かたに。

573 :デフォルトの名無しさん:2011/10/23(日) 23:14:41.14
仮想マシンが普及したところで、C++が無くなるつうのも微妙だ。
使える仮想環境が一番多い言語は実の所C++だし。
.Netでも動けばLLVMでも動く。
仮想環境に乗るわけではないが、Java VM に接続し、
クラスライブラリを使うこともできる。

574 :デフォルトの名無しさん:2011/10/23(日) 23:44:57.94
環境毎にコンパイルするの面倒だし
マルチOS対応ならJavaが楽だ

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

575 :デフォルトの名無しさん:2011/10/23(日) 23:49:20.57
そんなシビアに速度が要求されるような
システムなんて、ほとんどのヤツが開発
したことないくせに、みんなエラそうだな。

576 :デフォルトの名無しさん:2011/10/23(日) 23:59:50.81
>>575
ワロス

577 :デフォルトの名無しさん:2011/10/24(月) 00:00:09.38
>>574
Java のライブラリ使って書けば?
C++のテンプレート使えると、生産性が違うぞ。

578 :デフォルトの名無しさん:2011/10/24(月) 00:52:02.39
みんなgccからclangに移行してやがてObjectiveC++へ・・・とか
まあVCは関係ないけど

579 :デフォルトの名無しさん:2011/10/24(月) 03:15:55.26
gccもclangもその辺の立ち位置は変わらん。

580 :デフォルトの名無しさん:2011/10/24(月) 10:08:42.18
>>572
Singularityにおいては ならあり得る
あれはドライバも大半がC#で書かれてたし

581 :デフォルトの名無しさん:2011/10/24(月) 19:53:32.77
>>575
使ってっから言ってんだよ

582 :デフォルトの名無しさん:2011/10/24(月) 23:12:48.12
>>581
何だ、ただのユーザーか
開発しているわけでもないのに偉そうだな

583 :デフォルトの名無しさん:2011/10/24(月) 23:13:06.59


584 :デフォルトの名無しさん:2011/10/25(火) 00:55:32.97
速度を要求されないプログラマなどいない。
要求されてない奴はプログラマとは呼べない。

585 :デフォルトの名無しさん:2011/10/25(火) 01:00:44.83
好きにしろ

586 :デフォルトの名無しさん:2011/10/25(火) 03:28:15.96
C++よりCが速くなる場合ってどんな場合なんだろ

587 :デフォルトの名無しさん:2011/10/25(火) 03:35:34.42
>>586
ほとんどの場合だろ
今は体感できないけど、昔はオブジェクト指向は遅いって理由でCを使い続けるってのは良くあったらしい


588 :デフォルトの名無しさん:2011/10/25(火) 03:38:57.71
あとはその時提供されているC++の実装が、Cの実装に比べて遅かったりとか。
ちょうど今タイミングよくRaymond Chenが似たようなこと言ってるけど。
http://blogs.msdn.com/b/oldnewthing/archive/2011/10/24/10229097.aspx

589 :デフォルトの名無しさん:2011/10/25(火) 03:59:35.70
>>587
昔の話だ。

590 :デフォルトの名無しさん:2011/10/25(火) 04:00:09.53
>>587
C++よりCの方が早い、という意見はよく見かけるけど、単純な数値計算じゃなくて、C++のアルゴリズム相当のものを自作した場合でも成り立つんだろうか?

591 :デフォルトの名無しさん:2011/10/25(火) 04:17:34.56
>>590
単純な数値計算なら同じだろうし、C++の<algorithm>に明示的特殊化の可能性まで含めれば
Cより遅くなる理由は無い。

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

592 :デフォルトの名無しさん:2011/10/25(火) 04:18:32.48
>>588
実行速度の話してなくね?

593 :デフォルトの名無しさん:2011/10/25(火) 05:06:14.87
>>592
あまり使われない関数を同じページに押しこむとかのトリックが、当時のC++コンパイラーではうまくできなかった。
もちろん、断っているように、規格じゃなくて実装の話。

594 :デフォルトの名無しさん:2011/10/25(火) 05:29:05.93
今Cを使う理由はMISRA Cみたいにシビアに安全性が求められる場合じゃないの
速度面だとケースバイケースじゃん。qsortよりstd::sortの方が速いし

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

596 :デフォルトの名無しさん:2011/10/25(火) 07:38:13.37
あのコピペを貼って欲しいのか
Cでもマクロ使えば良いだけだろ

597 :デフォルトの名無しさん:2011/10/25(火) 08:11:51.85
std::qsort

598 :デフォルトの名無しさん:2011/10/25(火) 08:16:17.64
マクロは名前の汚染度や安全性を考えると実用には耐えられないね。見苦しい


599 :デフォルトの名無しさん:2011/10/25(火) 08:23:45.07
>>596
そういやなんでPreprocessor-Templateのqsortを標準化しなかったんだろうな

600 :デフォルトの名無しさん:2011/10/25(火) 09:24:26.70
見苦しいと思い込んでるだけ

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

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

602 :デフォルトの名無しさん:2011/10/25(火) 18:39:27.46
アホかそんな訳あるか
qsortの第三引数は何なんだよ

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

603 :デフォルトの名無しさん:2011/10/25(火) 19:09:08.15
g++ 4.6.1@i7 では qsort のほうが速かった

604 :デフォルトの名無しさん:2011/10/25(火) 20:00:39.41
ケースバイケースってことで

605 :デフォルトの名無しさん:2011/10/25(火) 20:13:46.17
memcpyが速い環境ならstd::is_podでもなんでも使って特殊化してくれればいいんだけど
それくらいコンパイラが最適化して欲しいな

606 :デフォルトの名無しさん:2011/10/25(火) 20:16:23.39
一要素のサイズが大きい→qsort
一要素のサイズが小さい→std::sort

こんな感じか

607 :デフォルトの名無しさん:2011/10/25(火) 20:45:06.68
C++0xになったらmoveするからちょっぱやだな

608 :デフォルトの名無しさん:2011/10/25(火) 20:47:39.27
moveできるような中身ならな・・・

609 :デフォルトの名無しさん:2011/10/25(火) 20:50:31.99
添え字かポインタで事前ソートしろ

610 :デフォルトの名無しさん:2011/10/25(火) 20:52:35.54
要素のサイズが大きい場合は普通は間接ソートするか

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

612 :デフォルトの名無しさん:2011/10/25(火) 21:03:44.70
そりゃおえんなあ

613 :デフォルトの名無しさん:2011/10/25(火) 22:26:38.57
式テンプレートみたいなテクニックがあるからC++が速度でもCに負ける日は永遠に来ない

614 :デフォルトの名無しさん:2011/10/25(火) 22:32:31.49
>>613
注意して書けばな...
むやみに new すると,
キャッシュやページテーブル意識して書いた C の半分以下ののスピード性能になる


615 :デフォルトの名無しさん:2011/10/25(火) 22:48:06.83
式テンプレートはコードが難解になるから嫌だ。
そりゃあ、ベクトルの演算程度ならかわいいもんよ。

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

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

616 :デフォルトの名無しさん:2011/10/26(水) 00:40:11.02
書けはするだろが、自分で書かないだろ。
Blits++とかublasとかおとなしく使えばいい。

617 :デフォルトの名無しさん:2011/10/26(水) 00:43:12.33
>>614
newなんてそれほど使わなくないか?
大抵自動変数かコンテナで済むだろ。

618 :デフォルトの名無しさん:2011/10/26(水) 00:52:50.10
ラムダ式の名前空間の話なんですが…

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

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

619 :デフォルトの名無しさん:2011/10/26(水) 01:07:09.29
>>618
ttp://ideone.com/OFro6
includeしてないとかそういうオチか?

620 :デフォルトの名無しさん:2011/10/26(水) 01:38:26.20
まずはコンパイラを示すんだ

621 :デフォルトの名無しさん:2011/10/26(水) 02:08:04.64
すいません、くそVisual C++2010です。
くそVisual C++2010のくそ仕様なんでしょうか…

622 :デフォルトの名無しさん:2011/10/26(水) 04:08:59.16
くそ言うな
くそに謝れ

623 :デフォルトの名無しさん:2011/10/26(水) 07:33:13.57
VC++2010は準拠率かなり低いから仕方が無い

624 :デフォルトの名無しさん:2011/10/26(水) 12:18:21.90
>>621
こいつは何を言っているんだ?
そもそも>>618でコンパイルエラーなんだが

625 :デフォルトの名無しさん:2011/10/26(水) 17:32:43.90
シンタックスエラーはともかくとして>>618では動くね。
以下のようにすると「定義されていない識別子です」と出た。

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

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

626 :デフォルトの名無しさん:2011/10/28(金) 12:54:58.89
C++11が正式になる前に作られたんだからそれに関して準拠度が低いのは仕方ない

627 :デフォルトの名無しさん:2011/10/28(金) 22:31:34.47
つか正式リリースする前につくるなよ。
またVC6,0の悲劇を繰り返す気か。

628 :デフォルトの名無しさん:2011/10/28(金) 23:14:48.33
そんなこと言ったらgccだって作ってただろ

629 :デフォルトの名無しさん:2011/10/28(金) 23:54:39.18
仕様・実装・利用の3者に時間差があるのは止むを得ない。
クラシックモードがあれば移行の時間稼ぎは出来る。

630 :デフォルトの名無しさん:2011/10/29(土) 00:44:39.96
理不尽なクレームを付けられるのは毎度のこととはいえMSも大変だな。

631 :デフォルトの名無しさん:2011/10/29(土) 08:04:11.41
>>628
gccは頻繁に更新あるけど
VCはそんなのないだろ

632 :使ってないからどうでもいいが、:2011/10/30(日) 10:50:06.17
VC++がMS内のスケジュール優先になるのは仕方ないんじゃないの?
MS内のdev系が全部引き摺られてアップデイトしていくわけだし、
WG21のスケジュールに合わせてられないでしょ。

633 :デフォルトの名無しさん:2011/10/30(日) 11:01:35.13
オプションで使えるようにして保証外みたい形にして実装するならいいと思うが
デフォルトで中途半端なC++11が使えるのはよろしくない
gccでも-std=c++0xないと使えないってのに

634 :デフォルトの名無しさん:2011/10/30(日) 13:26:30.85
>>477
英語で読むなら他に選択肢はあるしな。


635 :デフォルトの名無しさん:2011/10/30(日) 17:53:01.69
英語が出来る頭があるなら、
プログラマなんて底辺職業、やってない

636 :デフォルトの名無しさん:2011/10/30(日) 17:55:03.14
会話は無理目でもドキュメントの概要掴む位はできてくれないと
コンパイラのエラーメッセージすら読めないバカとかたまにいるからな

637 :デフォルトの名無しさん:2011/10/30(日) 17:56:55.28
>>636
コンパイルエラーぐらい、日本語で表示されるだろ。

638 :デフォルトの名無しさん:2011/10/30(日) 18:19:05.72
>>636
あれ読んでる奴いるのか?
クリックしてジャンプしてるだけだろ?

639 :デフォルトの名無しさん:2011/10/30(日) 18:41:23.45
>>635
じゃあ英国人や米国人は全員セレブか
じゃあGoogleやMicrosoftのプログラマは底辺か

おまえが底辺なだけ。

640 :デフォルトの名無しさん:2011/10/30(日) 19:08:10.12
>>638
涙拭けよ

641 :デフォルトの名無しさん:2011/10/30(日) 19:16:56.74
>>638
さすがにそれはない
すぐ分かるエラーならともかく

642 :デフォルトの名無しさん:2011/10/30(日) 19:22:20.82
構文エラーとかはエラー読むよりも飛んだほうが早いな。
エラークリックして、何がエラーかわからんときはエラーメッセージ読むなぁ。

643 :デフォルトの名無しさん:2011/10/30(日) 19:38:22.85
>>634,639,640
くだらん書き込みでageるなカス

644 :デフォルトの名無しさん:2011/10/30(日) 21:09:33.77
>>643
くだらん書き込みはお前のだ。

645 :デフォルトの名無しさん:2011/10/30(日) 22:57:33.24
どっちーもーどっちー。

646 :デフォルトの名無しさん:2011/10/31(月) 13:19:58.28
テンプレートのエラーメッセージは泣きたくなる

647 :デフォルトの名無しさん:2011/10/31(月) 14:20:40.75
デフォルトで変数constのコンパイルオプションとライブラリ用の仕組み設定してくんないかな
時既に遅しっぽいけど

648 :デフォルトの名無しさん:2011/10/31(月) 17:53:49.73
const namespace hoge{

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

}

うん、ないな

649 :デフォルトの名無しさん:2011/10/31(月) 21:56:25.83
テンプレートエラーなら読んだほうが寧ろ速いよな。

650 :デフォルトの名無しさん:2011/10/31(月) 22:58:59.34
やはりコンセプトが必要だな。

651 :デフォルトの名無しさん:2011/10/31(月) 23:10:23.33
コンセプト欲しいねー  本当、心待ち

652 :デフォルトの名無しさん:2011/10/31(月) 23:12:44.58
no concept no life

653 :デフォルトの名無しさん:2011/10/31(月) 23:17:44.36
うむ。conceptsは確かにイイ物だが
HTMLのCSS様にc++のヘッダ・ソースコードとは離れた言語外定義ファイル方式にして
「どうしてもイジリたい奴だけイジれ」みたいな
とにかく面倒じゃないやりかたにして欲しいね

654 :デフォルトの名無しさん:2011/10/31(月) 23:45:13.00
はあ?

655 :デフォルトの名無しさん:2011/11/01(火) 22:45:03.92
CSS?どゆこと?

656 :デフォルトの名無しさん:2011/11/01(火) 23:01:47.97
XMLのDTDのようなものを定義できるといいなー。ってかんじか?

657 :デフォルトの名無しさん:2011/11/01(火) 23:13:57.11
@[ExampleType:<int,long,{void} FunctionA>,<const char*,{size_t},FunctionB>]
とか定義すんのか。何の意味があるんだキモイだけだろ。

658 :デフォルトの名無しさん:2011/11/01(火) 23:50:04.05
C++自体キモカワイイのが売りだしー

659 :デフォルトの名無しさん:2011/11/02(水) 01:58:56.15
可愛くはない

660 :デフォルトの名無しさん:2011/11/04(金) 19:23:31.12
可愛いと思ってるのは単なる錯覚でそれはキモいC++を使いこなせるという虚栄心からくるもの。

661 :デフォルトの名無しさん:2011/11/04(金) 19:59:06.82
そういう感覚的な感情が必要なのかと・・・。

662 :デフォルトの名無しさん:2011/11/04(金) 20:10:57.67
C++みたいなキモい言語に対する虚栄心は大体において
構文規則の複雑さを理解したという感情からくるものだと思うけどな。

663 :デフォルトの名無しさん:2011/11/04(金) 20:14:34.12
複雑じゃないだろ
そういう意味ではperlとかのほうがよっぽどキモいわ

664 :デフォルトの名無しさん:2011/11/04(金) 20:44:21.57
Perlは内向きのキモさというか、キモさを工夫してもキモレベルが人に伝わりづらいのに対して
C++は頑張れば頑張っただけキモくなるし天井知らずでオエッてくるコードが書ける利点がある

665 :デフォルトの名無しさん:2011/11/04(金) 22:17:24.25
地味な女の子に変な性癖をつけるような達成感がある

666 :デフォルトの名無しさん:2011/11/04(金) 22:57:30.24
とりあえず template はなんとかならんのか

667 :デフォルトの名無しさん:2011/11/04(金) 23:03:33.05
どうなって欲しいんだ?

668 :デフォルトの名無しさん:2011/11/04(金) 23:34:11.66
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_ ;
...

みたいな

669 :デフォルトの名無しさん:2011/11/04(金) 23:34:15.50
Template Aliasesは欲しい。

670 :デフォルトの名無しさん:2011/11/04(金) 23:34:31.98
const_exprじゃだめなんか?

671 :デフォルトの名無しさん:2011/11/04(金) 23:41:18.85
operator定義のダルさを何とかして欲しいのはあるな

672 :デフォルトの名無しさん:2011/11/04(金) 23:42:53.75
>>670
型の計算できんの?

673 :デフォルトの名無しさん:2011/11/05(土) 14:14:54.49
ところで、暗黙のムーブコンストラクタ・ムーブ代入演算子って
どうなったか、ご存知の方います?

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

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

674 :デフォルトの名無しさん:2011/11/05(土) 14:20:18.76
どれだけ時代遅れだよ。
ユーザー定義のコピーがあれば暗黙のムーブは生成されない。
ちなみに、ユーザー定義のムーブがあれば、暗黙のコピーは生成されるが、この挙動はdeprecatedになった。
つまり頼るなってことだ。

675 :デフォルトの名無しさん:2011/11/05(土) 14:36:42.66
ちょっと先に情報を仕入れただけのにわかが俺スゲーってスレなのかな?

676 :デフォルトの名無しさん:2011/11/05(土) 14:53:30.75
自分で調べる気のないバカが聞きに来るスレです

677 :デフォルトの名無しさん:2011/11/05(土) 15:23:58.31
聞く奴いなくなったらお前も物足りないのだろう?

678 :デフォルトの名無しさん:2011/11/05(土) 15:39:31.81
伸びる奴はあらゆる手段(書籍、人、ネット、BBS、他)を使って貪欲に素早やく知識を獲得する。

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


679 :デフォルトの名無しさん:2011/11/05(土) 15:42:09.58
即レスした癖に
質問待ってるんだろ、素直になれよ

680 :デフォルトの名無しさん:2011/11/05(土) 17:10:35.68
ま、ぶっちゃけ人柱やるよりもうちょい情報がまとまってから調べ始めたほうが効率いいしな
あせってやるほどのことでもないし


681 :デフォルトの名無しさん:2011/11/05(土) 18:34:01.25
こんなスレにいるみなさんは十分意識高いですし
そこは認めたうえで殴り合ってください



682 :デフォルトの名無しさん:2011/11/05(土) 19:06:54.90
とりあえず、C++11のJIS規格票が出たら買うくらいはする。

683 :デフォルトの名無しさん:2011/11/05(土) 19:08:22.05
11に間に合うのか

684 :デフォルトの名無しさん:2011/11/05(土) 19:28:41.16
背に腹は代えられんが、しかしもう少し安くならんかな

685 :デフォルトの名無しさん:2011/11/05(土) 20:32:08.22
ttp://journal.mycom.co.jp/news/2011/11/04/014/index.html
なるほどね

686 :デフォルトの名無しさん:2011/11/05(土) 20:46:31.37
ローカル変数が、autoだらけになる訳か。B言語に回帰したみたいで胸が熱くなるな。

687 :デフォルトの名無しさん:2011/11/05(土) 21:12:15.72
可能な限り auto は反対だな
型が分かりにくくなる
型が大体想像できるイテレータとか
そういうのに限らないと読めたもんじゃないと思う

688 :デフォルトの名無しさん:2011/11/05(土) 21:27:25.65
ハンガリー人登場

689 :デフォルトの名無しさん:2011/11/05(土) 21:29:08.07
いやいや、特に整数型の式とか、
汎整数昇格やら何やら細かい規則があってややこしいんだぜ

690 :デフォルトの名無しさん:2011/11/05(土) 21:36:02.25
> Bjarne Stroustrup氏の記事「Elements of Modern C++ Style」

いやいや

691 :デフォルトの名無しさん:2011/11/05(土) 21:36:39.91
Integral typeだけやん

692 :デフォルトの名無しさん:2011/11/05(土) 22:23:08.72
>可能な限り従来のポインタとdeleteではなくスマートポインタを使うべき

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

693 :デフォルトの名無しさん:2011/11/05(土) 22:30:06.53
何でよ

694 :デフォルトの名無しさん:2011/11/05(土) 22:41:03.52
Javaのガベージコレクションは高度な遅延処理を含み軽量かつ高速で安全だからじゃないの?
ほとんどのイカしたC++プログラマはJavaレベルのメモリ管理なんて屁でもないけど
ほとんどのイカれたC++プログラマはまともにメモリ管理できないから。

695 :デフォルトの名無しさん:2011/11/05(土) 22:56:35.44
C++でメモリを正しく扱えるようになるころにはイカレてるから問題ない

696 :デフォルトの名無しさん:2011/11/06(日) 01:24:42.34
>690
サッターさん涙目w

697 :デフォルトの名無しさん:2011/11/06(日) 10:45:47.49
なんでJavaを持ち出すのか分からん
Javaを使った方がいい場面なら勝手に使えばいい

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

698 :デフォルトの名無しさん:2011/11/06(日) 11:02:04.28
スマポはスマポで、循環参照というミスはあるけどね

699 :デフォルトの名無しさん:2011/11/06(日) 11:06:45.44
循環なんて設計段階でわかるだろカス
知的障害の有るメンバが混じってるプロジェクト以外でスマポの循環が問題になったなんて事例は
いままで世界で一度も発生してないという事実を認識しろ

700 :デフォルトの名無しさん:2011/11/06(日) 11:34:36.03
スマポの問題じゃなくてshared_ptrで起こり得る問題だろ
優先すべきはunique_ptr。共有したいときにshared_ptrの出番。
循環参照のためにweak_ptrもあるし。

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

701 :デフォルトの名無しさん:2011/11/06(日) 11:43:20.99
unique_ptrとshared_ptrでdeleterの指定の仕方が違うとかなめてんの?

702 :デフォルトの名無しさん:2011/11/06(日) 11:45:45.45
違って当然だろ


703 :デフォルトの名無しさん:2011/11/06(日) 11:57:46.16
>>699
COM使ってて循環参照や生ポで受けてリークしてる例は何度も見てる
スマポ知らない人がスマポ使われてるプロジェクトに投入されるとよくある事

704 :デフォルトの名無しさん:2011/11/06(日) 13:03:47.09
>>687
OOPLで型が目に見えなきゃならん理由が解からん。
OOの概念からすりゃ型を意識しなきゃいけないのは悪だ。
型チェックは別に型が目に見えなくてもできる。
大体、テンプレートだって実際どの型が割り当てられるかなんて気にせず書いてる。

705 :デフォルトの名無しさん:2011/11/06(日) 13:14:18.13
じゃあ動的型言語でも使えばいいだろ
Dart(笑)でもやってろよ
C++の利点は静的型と生ポを扱えることなのに、それを否定してるだけに見える

706 :デフォルトの名無しさん:2011/11/06(日) 13:39:40.59
>>705
こいつ最高にアホ

707 :デフォルトの名無しさん:2011/11/06(日) 13:39:58.98
くだらないことでケンカするなよ。
結局似たようなこと言ってんのに字面の違いで言い合いするなんて不毛だ。

708 :デフォルトの名無しさん:2011/11/06(日) 13:48:21.08
>>705
動的型言語じゃ型チェックできないだろバカじゃねぇの
目でみえることと、型安全は別

709 :デフォルトの名無しさん:2011/11/06(日) 13:48:58.77
C++見たいな静的言語でも、any/function/bind/lambda使ってるとほとんど動的言語みたいだよなあ。
JavaScriptとかと比べてできないことってあとなにがあるんだったっけ?

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


710 :デフォルトの名無しさん:2011/11/06(日) 13:59:26.11
そのへんは型消去してるから動的だろ

711 :デフォルトの名無しさん:2011/11/06(日) 14:02:15.37
結局メンバ変数や引数にはauto使えないんだし、
autoを濫用すると「あれ? この値こいつに入れられるのか?」とか分かりにくくなる

712 :デフォルトの名無しさん:2011/11/06(日) 14:05:49.26
ここでハンガリー人登場

713 :デフォルトの名無しさん:2011/11/06(日) 14:06:02.61
頼りきらず無視もせず適切に使う
C系列の原則だろ


714 :デフォルトの名無しさん:2011/11/06(日) 14:43:22.55
C#のvarってどのくらい使われてんの

715 :デフォルトの名無しさん:2011/11/06(日) 14:46:38.19
ここで聞くことか?


716 :デフォルトの名無しさん:2011/11/06(日) 14:51:03.03
autoの参考になるじゃん

717 :デフォルトの名無しさん:2011/11/06(日) 14:56:27.78
そうだね
でも、もう一度聞くぞ?
ここで聞くことか?


718 :デフォルトの名無しさん:2011/11/06(日) 14:58:02.92
>>710
別に消えてないし、コンパイル時に決定してるから動的とは言わないだろ

719 :デフォルトの名無しさん:2011/11/06(日) 15:31:52.40
>>711
コンパイルエラーなり、エディタの補助ですぐ解るがな。

720 :デフォルトの名無しさん:2011/11/06(日) 15:35:11.07
>>709
関数をthisのマップに自動で詰め込む。
this["関数名"](・・・);で、いつでもスコープに所属する関数を呼び出せる。
C++もOSの力とマングリング関数を使えば完全に不可能でもないけどね。

721 :デフォルトの名無しさん:2011/11/06(日) 15:39:56.53
>>717
ここで聞くこと

722 :デフォルトの名無しさん:2011/11/06(日) 15:40:37.19
>>719
マンドクセ

723 :デフォルトの名無しさん:2011/11/06(日) 16:08:32.23
>>721
そうか、C#スレで聞くよりも回答確率は大分低いだろうが、まあガンガレ


724 :デフォルトの名無しさん:2011/11/06(日) 17:07:36.24
動的型/静的型
型推論による型特定/明示的型指定

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

725 :デフォルトの名無しさん:2011/11/06(日) 17:12:08.33
>>720
ああそうね。メンバ関数の実行時追加とかは無理か

726 :デフォルトの名無しさん:2011/11/06(日) 17:12:49.89
>>718
消えてるよ
静的型でラップしてるから消えてないように見えるだけ

727 :デフォルトの名無しさん:2011/11/06(日) 17:45:50.86
anyは型を消してるというのかねぇ。内部では持ってるわけだし。

728 :デフォルトの名無しさん:2011/11/06(日) 18:06:27.60
struct X {};
struct A : X {};
struct B : X {};
X * p = new A;
これだけでもうpから静的な型情報を取り出せないよanyも同じ

729 :デフォルトの名無しさん:2011/11/06(日) 18:07:54.25
>>726
少なくとも動的ではないな。
動的言語なら実行時に無視なり、エラーになる。

id object;
object = @"message";
[object isEqualToString: @"message"];

object = [ [NSError alloc] new ];
[object isEqualToString: @"message"];//無視

730 :デフォルトの名無しさん:2011/11/06(日) 18:09:01.88
間違えた、動的言語じゃない、動的型付け言語だった。

731 :デフォルトの名無しさん:2011/11/06(日) 18:29:24.88
>>728
anyは代入した型の型情報を保持してるでしょ

732 :デフォルトの名無しさん:2011/11/06(日) 18:54:31.31
>>729
> alloc] new ];

酷いねコレ

733 :デフォルトの名無しさん:2011/11/06(日) 19:25:33.07
>>731
動的にな

734 :デフォルトの名無しさん:2011/11/06(日) 19:25:52.50
>>732
initだわ間違えた。

735 :デフォルトの名無しさん:2011/11/07(月) 03:42:48.98
>>733
コンパイル時じゃね?

736 :デフォルトの名無しさん:2011/11/07(月) 08:07:57.52
C++闇の軍団って何ですか?

737 :デフォルトの名無しさん:2011/11/07(月) 08:15:08.80
もう恥ずかしいからそういうのよそうよ

738 :デフォルトの名無しさん:2011/11/07(月) 10:01:44.70
>>735
ちげーよ
出来るってんならanyからコンパイル時に元の形を得るメタ関数作ってみろや

739 :デフォルトの名無しさん:2011/11/07(月) 12:04:51.43
anyはややこしいことに、内部にValueTypeを保持してるが外側からはコンパイル時には扱えないので
どちらも正解と言える


740 :デフォルトの名無しさん:2011/11/07(月) 17:01:42.36
TMPはキモイ構文になりがちなので
メタ関数を普通の関数と同じように書けるようにしてほしいなぁ。

typename add_const(typename T)
{
return const T;
}
typename remove_const(const typename T)
{
return T;
}

constexprができたんだから、typenameだってできるだろう。

741 :デフォルトの名無しさん:2011/11/07(月) 17:12:21.06
autoは出来るだけ使うようにしてるな
置き換えてみればわかるけどautoで意味がわからなくなるようなら設計が悪い

742 :デフォルトの名無しさん:2011/11/07(月) 17:21:46.51
馬鹿長い変数名じゃないと意味がわからなくなるのは設計が悪い。変数名はvar+番号にせよ
auto信者の言ってることはこういうマヌケなことと本質的に同じだと気がついてくれ

743 :デフォルトの名無しさん:2011/11/07(月) 17:27:38.23
そもそもautoでややこしくなると思うなら、auto使わなければいい。
悪いスタイルで書けることを、必要以上に恐れないのがC系言語の設計。

744 :デフォルトの名無しさん:2011/11/07(月) 17:39:04.02
「型チェックしたいなー」ってところでは型を指定し、
「別にそうでもないなー」ってところでは型推論に任せてる

745 :デフォルトの名無しさん:2011/11/07(月) 17:55:01.21
autoなら意図していない型変換が起こらないから安全

class foo {};
class bar : public foo {};
bar func() ;


auto x = func(); // Good!
foo y = func(); // 実はbarとfooを間違えているのたけど警告すらでない!世界は崩壊する!


746 :デフォルトの名無しさん:2011/11/07(月) 18:15:28.90
こういうスタイルでコーディングできることもC++の強みのひとつになる
俺はJavaを使うようなスタイルでC++を使っている

747 :デフォルトの名無しさん:2011/11/07(月) 19:13:47.27
派生クラスの値返し自体稀じゃね

748 :デフォルトの名無しさん:2011/11/07(月) 19:18:35.72
全然稀じゃないだろ


749 :デフォルトの名無しさん:2011/11/07(月) 19:46:24.85
大抵はポインタ、スマポ、参照のどれかだな
基底クラスの存在感が希薄なクラスくらいならあるかもしれない

750 :デフォルトの名無しさん:2011/11/07(月) 19:49:20.50
普通はそもそもコピーコンストラクタが滅多に動かないように作るもんじゃね?
数値様クラスくらいならいいけども、
大抵複製考えるの面倒くさいか不可能なケースがほとんどで

751 :デフォルトの名無しさん:2011/11/07(月) 20:04:21.65
struct hoge_: ncopy {
void hello(void);
};

struct hoge {
hoge(void) : p_(new hoge_()) {}
inline void hello(void) { p_->hello(); }
private:
SP<hoge_> p_;
};

めんどくさいから小さいクラスとボトルネック以外はこれでお茶を濁す

752 :デフォルトの名無しさん:2011/11/07(月) 22:09:39.72
>>742
違うと思うなぁ。極論を出して本質とは言わんで欲しい。

753 :デフォルトの名無しさん:2011/11/07(月) 22:20:56.14
>>742
TMPLやlambda使ってればautoは必要だと感じると思うようになる。


754 :デフォルトの名無しさん:2011/11/07(月) 22:27:36.87
必要以上に型を気にするのは無駄なことだと理解できたら一人前

755 :デフォルトの名無しさん:2011/11/07(月) 22:35:09.76
その「必要」がどのラインかを見極められたら一人前。
現実の問題ってのはトレードオフの集合体。 こうすればすべて解決なんて方法は無い。

756 :デフォルトの名無しさん:2011/11/07(月) 22:50:13.86
正しいロジックを書けば勝手に型が合う物だよ。だからautoに渡しておけばいい。
間違ったロジックをかけばどこかで型の矛盾が生じてエラーになる。下手に不正確な型を書くと変なところでエラーが起きて解りにくくなる。

てか、autoの弊害が思い付かない

757 :デフォルトの名無しさん:2011/11/07(月) 23:09:31.56
autoのデメリットは後で見た人がストレスで禿げることかな


758 :デフォルトの名無しさん:2011/11/08(火) 00:06:21.32
>>738
anyはany_castが必要な時点で動的じゃねぇよ。
言うなりゃ片安全で多機能なvoid*。

//TypeAとTypeBは繋がりなし
boost::any any;
any = TypeA();
any->Function();
any = TypeB();
any->Function();

本当に動的型付ならダックタイプができなきゃならん。
動的片付けじゃないから、実行時に型情報から
関数情報のルックアップができない。

759 :デフォルトの名無しさん:2011/11/08(火) 00:10:10.79
void *の時点でどう見ても動的です。お疲れ様です

760 :デフォルトの名無しさん:2011/11/08(火) 00:12:24.44
void*が動的とか・・・

761 :デフォルトの名無しさん:2011/11/08(火) 00:14:23.98
>>759
void *だと実行時にメタ処理が走らないだろ。
コンパイル時にしているメタ処理が実行時に走るから動的っていうんだぞ。
お前の動的って何を根拠に言ってんだ?

762 :デフォルトの名無しさん:2011/11/08(火) 00:15:51.55
コンパイル時に型が決まっていないこと

763 :デフォルトの名無しさん:2011/11/08(火) 00:20:37.11
型は決まってるだろ型は

764 :デフォルトの名無しさん:2011/11/08(火) 00:22:21.62
え?

765 :デフォルトの名無しさん:2011/11/08(火) 00:23:44.44
void*に突っ込もうが、anyに突っ込もうが型は決まってるわな。
castしなきゃ正体が見えないだけで。castすりゃ動的言語ならCだって動的言語だわw

766 :デフォルトの名無しさん:2011/11/08(火) 00:38:50.57
Cは動的言語ってことで。

767 :デフォルトの名無しさん:2011/11/08(火) 00:39:23.60
voidポを動的とかいうレベルのヤツがC++11スレにいるのか
そのレベルでこのスレ開いちゃいかんだろ、恐ろしいな・・・

768 :デフォルトの名無しさん:2011/11/08(火) 00:42:28.75
動的言語と動的型付けを混同してる人がいる
ちゃんと区別してないと話かみ合わないぞ

769 :デフォルトの名無しさん:2011/11/08(火) 00:43:53.12
>>767
レベルとか云々以前にコミュ障じゃね。
技術文書にも書かれてないオレオレ定義主張してんだから。

770 :デフォルトの名無しさん:2011/11/08(火) 00:59:19.69
>>765
anyはコンパイル時に型が決まる。だから静的。
void*に突っ込まれる型はコンパイル時には決まらない。だから動的。

恐らくお前はanyの動作を勘違いしている。

771 :デフォルトの名無しさん:2011/11/08(火) 01:17:19.78
それで、いつになたらanyから元の型を取り出すメタ関数を見せてくれるんだ?
静的型を持ってるなら簡単なことだろう?はやくしてくれ

772 :デフォルトの名無しさん:2011/11/08(火) 01:21:37.53
>>771
動的言語ではないので無理です。

773 :デフォルトの名無しさん:2011/11/08(火) 01:27:56.47
>>770 void *はメモリブロックの位置を指してるだけで型情報なんにも知らないでしょ。
動的だって言うんなら、void *型からキャスト無しでメンバーにアクセスしたり、
四則演算ができたりする必要がある。動的型付けなら当然のように出来ること。
動的型付だと実行時にvoid *に当たるハンドルが実際の型情報を取り出し、
自動で演算子やメソッドを割り当てるからね。

774 :デフォルトの名無しさん:2011/11/08(火) 01:31:52.94
そういや、VariantというC++で無理やり動的型付けした仕組みがあったな。


775 :デフォルトの名無しさん:2011/11/08(火) 01:50:38.34
>>768
動的言語ってのは実行時に
型を定義できたりするアレだろ

if binding
    require "module.m"
end

// bindingがfalseなら型未定義でエラー
Plugin.new()



776 :デフォルトの名無しさん:2011/11/08(火) 01:50:51.04
>>774
ごく初期、禿は懐疑的な態度で臨んだアレか

777 :デフォルトの名無しさん:2011/11/08(火) 02:16:00.78
>770
型消去とかType Erasureで検索するよろし。

そういや昔boost::any用のマルチメソッド実装したなあ。便利だけど遅かった……



778 :デフォルトの名無しさん:2011/11/08(火) 02:24:47.78
C言語が別名カメレオン言語と呼ばれている理由がわかりました

779 :デフォルトの名無しさん:2011/11/08(火) 08:52:41.90
auto a = true ? [](){} : [](){};
これができないのは仕様ですか?
それともVS2010の仕様ですか?

void b(){}
void c(){}
auto a = true ? b : c;
これならできるのに、関数ポインタがラムダで置き換えできない。

780 :デフォルトの名無しさん:2011/11/08(火) 09:37:04.87
vs2010の仕様

781 :デフォルトの名無しさん:2011/11/08(火) 11:51:30.55
おまえらソースくらい読めよ。anyの型解決は
typeid(ValueType)
だよ。よってコンパイル時に決定してる。


782 :デフォルトの名無しさん:2011/11/08(火) 12:21:27.29
RTTI(runtime type information)

783 :デフォルトの名無しさん:2011/11/08(火) 12:54:34.73
思いのほかスレ住人のレベルが低いのなww

784 :デフォルトの名無しさん:2011/11/08(火) 13:10:03.22
any=動的厨はほっとこうや。
話が通じず困るのは本人なんだし。

785 :デフォルトの名無しさん:2011/11/08(火) 15:33:42.28
int a = nullptr; // エラー
bool a = nullptr; // ok

boolさんがおかしい

786 :デフォルトの名無しさん:2011/11/08(火) 17:27:00.94
>>784
話通じてないのは静的厨だろwww

787 :デフォルトの名無しさん:2011/11/08(火) 17:45:15.81
>>779
lambdaの結果が同じ型にならなきゃエラーになるんじゃないの?
function でラップすれば良くないか?

788 :デフォルトの名無しさん:2011/11/08(火) 18:01:08.62
>>785
nullptrはnullptr_t型の値であり、nullptr_t型は任意のポインタ型に暗黙返還できて、ポインタ型はbool型に暗黙変換できる。

789 :デフォルトの名無しさん:2011/11/08(火) 18:18:12.63
>>788
ただしくは、nullptr_t型の値から直接bool型の値falseに変換できる。

790 :デフォルトの名無しさん:2011/11/08(火) 19:41:07.33
誰得仕様やな
そんなこと出来ないほうが自然だ

791 :デフォルトの名無しさん:2011/11/08(火) 20:26:39.69
ifでnullptrをfalse扱いにする場合とかね


792 :デフォルトの名無しさん:2011/11/08(火) 20:31:59.70
if(ptr)って書いてる?
if(ptr == nullptr)って書いてる?

793 :デフォルトの名無しさん:2011/11/08(火) 20:32:16.89
ああこれじゃ意味逆か
まあいいか

794 :デフォルトの名無しさん:2011/11/08(火) 20:33:29.65
自分は明示的に、
if(Ptr == nullptr)/*do*/
って書くかな。

795 :デフォルトの名無しさん:2011/11/08(火) 20:44:40.14
>>792
前者だな。有効/無効と解釈できるから
後者は間違えやすいから。c#だと後者しか書けなくてはまる

796 :デフォルトの名無しさん:2011/11/08(火) 20:50:35.77
おれも前者だな。
ポインタとoptionalで同じように書きたいが
boost::optionalとnullptrの比較はなんかアレだ。

797 :デフォルトの名無しさん:2011/11/08(火) 21:09:48.98
>>790
テンプレート用。

798 :デフォルトの名無しさん:2011/11/08(火) 21:24:43.05
>>779
あらゆるラムダ式はお互いに型が違ってて(たとえ定義の形が同じでも)、暗黙変換も出来ないから仕様

799 :デフォルトの名無しさん:2011/11/08(火) 21:27:47.13
前者だとnullptrである必要がないじゃん
それはNULLでしょって話
nullptrというキーワードを新設したのになんでこんなことやったんだか

800 :794:2011/11/08(火) 21:31:13.53
後者は、NULLの実行値が変わっても大丈夫ということで使ってるなぁ。
まー、杞憂なんだろうけど。

801 :デフォルトの名無しさん:2011/11/08(火) 21:32:30.01
>>799
NULLの定義を見てごらん
整数の0と明確に区別出来るようになったでしょ。

802 :デフォルトの名無しさん:2011/11/08(火) 21:34:17.36
>>800
前者でも問題ないね

803 :デフォルトの名無しさん:2011/11/08(火) 21:53:40.21
問題があるかないかという話じゃないだろ

804 :デフォルトの名無しさん:2011/11/08(火) 21:57:50.50
decltype( template_arg ) pointer = nullptr; //テンプレート引数が整数だとエラーに出来る

805 :デフォルトの名無しさん:2011/11/08(火) 22:09:51.91
>>803
>>800 の論点はそこだぞ

実際に杞憂だけど

806 :デフォルトの名無しさん:2011/11/08(火) 22:22:10.65
>>788
なんでstd空間に定義してるのに _t ついてんだろうな。
型だけならnullpointerで良かったろうに。
あと本体もstd::nullptrじゃなくstd::nullじゃダメだったんだろか.。

807 :デフォルトの名無しさん:2011/11/09(水) 00:03:47.93
せっかくだから予約語にしたいけどいまさら null を追加なんてしたら衝突するから無理
ググったら nullptr なんて名前使ってるやつほとんどいないし短いからこれでいいや
型名は typedef decltype(nullptr) nullptr_t; ってことで _t 付けとけばいいな

そんなかんじ

808 :デフォルトの名無しさん:2011/11/09(水) 00:08:52.64
typedef型に_tをつけるのは命名規則だから仕方が無い

809 :デフォルトの名無しさん:2011/11/09(水) 01:18:54.96
value_typeとかもvalue_tにすればよかったのに

810 :デフォルトの名無しさん:2011/11/09(水) 01:26:12.85
標準の命名センスが皆無なのは仕様

811 :デフォルトの名無しさん:2011/11/09(水) 07:53:18.50
そこがいい

812 :デフォルトの名無しさん:2011/11/09(水) 08:01:27.90
>>807
ライブラリじゃなく予約語になったんだっけ?

813 :デフォルトの名無しさん:2011/11/09(水) 08:36:54.89
struct nullptr_t
{

template<typename T>
operator T*() const
{
return 0;
}

} nullptr;

c+03で実装するとしたらこんな感じ?

814 :デフォルトの名無しさん:2011/11/09(水) 08:40:35.04
>>813
bool変換とか*とか->とか

815 :デフォルトの名無しさん:2011/11/09(水) 09:23:22.93
C++03では完全な nullptr を作れない
一応 nullptr イディオムはすでに存在する
ttp://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

816 :デフォルトの名無しさん:2011/11/09(水) 09:47:30.57
メンバへのポインタが抜けてたか。


operator boolはどう使うんだ?

if(nullptr)
とか?

void hoge(bool flag){}
hoge(nullptr);
とか?

falseを書く所に使うとしたら、間違った使い方としか思えないんだがw


NULLは (void*)0 ただし、他のどのポインタにも暗黙に変換できる
というCでの定義を考えると、*と->はイランのじゃないか?


817 :デフォルトの名無しさん:2011/11/09(水) 12:19:24.74
> *と->はイランのじゃないか?
いらんな。nullptr自身はポインタ型ではないからな

818 :デフォルトの名無しさん:2011/11/09(水) 22:43:02.41
>>816
> if(nullptr)

言いたいことは分かるけど、こんなコードはないだろw

819 :デフォルトの名無しさん:2011/11/10(木) 07:41:48.89
>>818
マクロの出番だな。

820 :デフォルトの名無しさん:2011/11/10(木) 11:56:09.66
ポインタ変数をboolに変換することはあっても
nullptrは定数なんだから、falseになるのは当たり前なんだし
最初っからfalseって書けよって話だと思うんだが
ほかにnullptrのbool変換が必要な理由があるのか?

821 :デフォルトの名無しさん:2011/11/10(木) 12:30:52.06
template <typename Pointer>
void function(Pointer p) {
if (p) {
}
}

822 :デフォルトの名無しさん:2011/11/10(木) 19:01:06.69
長いことnullptrのbool変換は出来なかったんだけど
他のポインタではよく使う変換だしあえて禁止する理由なくね?
というような経緯だったと思う

823 :デフォルトの名無しさん:2011/11/10(木) 19:57:33.22
T<NULL>の悪夢さようなら

824 :デフォルトの名無しさん:2011/11/10(木) 20:02:45.39
それならint変換も禁止する必要なくね?

825 :デフォルトの名無しさん:2011/11/10(木) 20:32:09.16
それやったら本物の0と同じになってまう

826 :デフォルトの名無しさん:2011/11/11(金) 09:12:08.62
templateやマクロによってif(nullptr)になってしまった場合は
C++03のstructでoperator bool(){return false;}と
するより、最適化で消えてくれる可能性が高くなるのかな。

827 :デフォルトの名無しさん:2011/11/11(金) 14:58:43.29
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キーワードそのものが消えたのか。

828 :デフォルトの名無しさん:2011/11/11(金) 18:23:41.36
キーワードのままです。

829 :デフォルトの名無しさん:2011/11/12(土) 17:53:25.53
ほら、うつ病、統合失調症予備軍団がこれだけぞくぞくと。
何で、イチイチこだわらなくちゃいけないの?会社辞めたら?






数年後にここのスレに書き込んでいる奴の2〜3割が自殺。


830 :デフォルトの名無しさん:2011/11/12(土) 18:07:08.76
>>829
やんでるから病院言ってSIRIもらってこい

831 :デフォルトの名無しさん:2011/11/12(土) 19:18:19.40
ふーん、お前それを飲んでるんだ。

ま、自殺しないようになw

832 :デフォルトの名無しさん:2011/11/12(土) 19:24:33.45
放射能とTPPのダブルパンチで底辺PGなんてマジで3割ぐらい死んでるかおなwww

833 :デフォルトの名無しさん:2011/11/12(土) 19:31:04.48
配列リテラルって結局規格なの?
こういうやつ

(int[]){10, 20, 30};

834 :デフォルトの名無しさん:2011/11/12(土) 19:32:55.71
規格だよ

835 :デフォルトの名無しさん:2011/11/12(土) 19:39:34.67
>>792
後者。真偽値はちゃんと区別したい。

836 :デフォルトの名無しさん:2011/11/12(土) 19:44:59.31
VCで使える明示的オーバーライド(親クラス毎に関数の実装を選べる)って
規格じゃなくてVCの拡張だよね

837 :デフォルトの名無しさん:2011/11/12(土) 20:22:48.63
C++/CLIじゃなかったかそれ

838 :デフォルトの名無しさん:2011/11/12(土) 20:41:22.94
かもしれないけど、CLIを使うオプション入れなくても使える。
あと、ググると別の明示的オーバーライドが出てくるから
誤解してるかもしれない。ここでいってるはこんなヤツ。

struct Derived:public Base1,public Base2
{
      int Base1::Override(){}
      int Base2::Override(){}
};

839 :デフォルトの名無しさん:2011/11/12(土) 21:06:23.15
>>829,831 くだらん書き込みでageるなカス

840 :デフォルトの名無しさん:2011/11/12(土) 21:15:59.46
>>833
compound literalというC99の規格だけどC++の規格ではない

841 :デフォルトの名無しさん:2011/11/12(土) 21:19:14.21
いらねー規格はぽんぽこ追加するのに
便利な規格は見送るんだよな標準委員会って馬鹿なんじゃね?

842 :デフォルトの名無しさん:2011/11/12(土) 21:23:25.75
http://msdn.microsoft.com/library/ksek8777
Managed C++ 時代の名残だな
同様に for each が使える割には Range-based for がVC11でも実装されないらしい

843 :デフォルトの名無しさん:2011/11/12(土) 21:26:50.91
M$はどうしてそんなやる気ないの?

844 :デフォルトの名無しさん:2011/11/12(土) 21:27:58.32
C丼があるから

845 :デフォルトの名無しさん:2011/11/12(土) 21:29:38.67
多分過去の遺産のためにC++維持しようとしてるだけで、
もう新規開発は期待してないんじゃないの?
自社の所有コードを保守できればいいみたいな。

846 :デフォルトの名無しさん:2011/11/12(土) 21:43:10.58
VC11ではC++/CXの実装で忙しいんじゃないか

847 :デフォルトの名無しさん:2011/11/12(土) 22:39:39.93
優位を保てなければルールを変えてしまえって社訓だから
規格のポチをやるかどうかは気まぐれなんだよ

848 :デフォルトの名無しさん:2011/11/12(土) 22:41:29.08
迷惑な連中だな

849 :デフォルトの名無しさん:2011/11/12(土) 23:12:46.72
VC++を冷遇してもMinGWとかに流れてC#には流れることはないんじゃないかな。
最適化のレベルはどっちが上なのかな?


850 :デフォルトの名無しさん:2011/11/12(土) 23:29:27.63
どっちもどっち。MinGW(っていうかGCC)はUnicode対応がクソ過ぎ。

851 :デフォルトの名無しさん:2011/11/12(土) 23:30:49.32
ダントツでVC。コンパイラの正式名称もMicrosoft Optimize Compilerというだけあって
DLLの中までインライン展開するしレジスタの使い分けやコードのならび換えが半端ない。

852 :デフォルトの名無しさん:2011/11/12(土) 23:31:36.71
UnicodeがじゃなくてUTF-16がじゃないのか?

853 :デフォルトの名無しさん:2011/11/12(土) 23:43:19.84
>>851
DLL でインラインて、そんなに特殊なことか?

854 :デフォルトの名無しさん:2011/11/12(土) 23:56:43.91
>>843
Microsoftが必要としているのはWindowsとかの自分たちで用意した環境上でだけ動けば良いプログラムを作るための道具であって
C++でプログラムを作るための汎用的な道具ではないから。

855 :デフォルトの名無しさん:2011/11/12(土) 23:58:35.54
>>853
クロスプラットフォームなコンパイラじゃできないでしょ。
多分clangがWindowsに移植された場合もできないだろうし。

856 :デフォルトの名無しさん:2011/11/13(日) 00:13:25.12
>>855
え? え? クロスプラットフォーム??? 余計わけわかめ

857 :デフォルトの名無しさん:2011/11/13(日) 00:13:57.61
WindowsもJavaもXMLもUTF-16の時代だから。

858 :デフォルトの名無しさん:2011/11/13(日) 00:28:48.76
>>856
クロスコンパイル知ってる?

859 :デフォルトの名無しさん:2011/11/13(日) 00:46:13.08
今時UTF-16メインでつかってんのって、
WindowsとJavaぐらいじゃね。他のOSはUTF-8ベースだし、
Web関係のデータも大概UTF-8。DBもUTF-8サポート謳ってんのばっか。
XMLもUTF-16使ってんのは見たこと無いな。

860 :デフォルトの名無しさん:2011/11/13(日) 00:52:10.18
あっぽれはUTF-32じゃないの?詳しくは知らないけど。

UTF-8は1バイトしか使わないコードページでは
実際1バイトのコストで文字処理できるから、
一番合理的だと個人的には思う。愛していきたい。

861 :デフォルトの名無しさん:2011/11/13(日) 01:04:27.59
Appleは変則UTF-8

862 :デフォルトの名無しさん:2011/11/13(日) 01:05:01.11
VC++もクロスコンパイラだぞ
x86もx64もいける

863 :デフォルトの名無しさん:2011/11/13(日) 01:06:37.00
XMLはDOMがUTF-16だった経緯があるから。

864 :デフォルトの名無しさん:2011/11/13(日) 01:17:27.01
>>862
Windowsでしか動かんがな
せめてPE以外を吐けるようになってから言え

865 :デフォルトの名無しさん:2011/11/13(日) 01:18:27.24
>>863
デフォルトは有るだろうけど
XMLは別にエンコード固定じゃないだろ

866 :デフォルトの名無しさん:2011/11/13(日) 01:23:43.97
>>865
デフォルトの話じゃないんだよなあ。
libxml2がUTF-8なんで正規のXMLパーサーを名乗れなかったりとかいろいろ
有ったんだけど。

867 :デフォルトの名無しさん:2011/11/13(日) 01:25:37.69


<?xml version="1.0" encoding="UTF-8"?>

868 :デフォルトの名無しさん:2011/11/13(日) 01:28:54.44
ほんとめんどくさい人だな。
プログラム技術板なんだから、もう少し自分で調べるとかしなよ。
ほれ。

http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-C74D1578

869 :デフォルトの名無しさん:2011/11/13(日) 01:38:30.24
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.

870 :デフォルトの名無しさん:2011/11/13(日) 01:43:00.99
>>869
もともとDOMの話だろ。
ほんとにめんどくさい人だなあ。

871 :デフォルトの名無しさん:2011/11/13(日) 01:46:35.11
>>870
ああそうなの。>>857 見て書いたから知らんかったわ。

872 :デフォルトの名無しさん:2011/11/13(日) 01:48:22.86
>>871
ああそうかい、とっても恥ずかしい>>865はお前じゃないわけね。
なおさら恥ずかしいやつだと思ったわ。

みっともないやつだなあ。

873 :デフォルトの名無しさん:2011/11/13(日) 01:49:13.46
で、基本的なことを聞きたいんだけど、UTF-8 は char と wchar_t のどっちであつかったらいいの?('∀`)

874 :デフォルトの名無しさん:2011/11/13(日) 01:53:29.34
>>863
これを見てDOMのエンコードについて話してると思う人は居ないと思うが・・・。
DOMがUTF-16向けだからXMLもUTF-16が仕様なんだと言いたいように見える。

875 :デフォルトの名無しさん:2011/11/13(日) 01:54:52.06
>>873
wchar_tかcharかと言えば、char。
理屈上別にintに突っ込んでも構わんけど。

876 :デフォルトの名無しさん:2011/11/13(日) 01:57:49.61
>>875
ありがとん。
char s[] = "UTF-8エンコードな文字列";
cout.imbue( locale( "Japanese_Japan.65001" ) );
cout << s;
みたいなんでいけるんかな、実験してみよう…。

877 :デフォルトの名無しさん:2011/11/13(日) 01:58:17.76
>>865 って別にDOMのエンコードがどうのとか言ってなくね?

878 :デフォルトの名無しさん:2011/11/13(日) 02:03:10.95
>>865にDOMなんて書いてねーよな?

879 :デフォルトの名無しさん:2011/11/13(日) 02:04:38.84
たしかに>>865には一言もDOMと書いてない
あれを見てDOMの話だと分かるやつはいない

880 :デフォルトの名無しさん:2011/11/13(日) 02:08:06.79
私にも>>865がDOMの話だとは分かりませんでした。

881 :デフォルトの名無しさん:2011/11/13(日) 02:27:58.82
半年DOMってろ

882 :デフォルトの名無しさん:2011/11/13(日) 02:46:27.11
>>866
お前もXMLパーサー言っとるがな

883 :デフォルトの名無しさん:2011/11/13(日) 02:49:24.73
>>866
お前最悪だな

884 :デフォルトの名無しさん:2011/11/13(日) 02:50:30.11
>>866
>>866
>>866
>>866
>>866
>>866

885 :デフォルトの名無しさん:2011/11/13(日) 03:11:49.54
>>872

このレスさえつけなきゃ皆スルーしてくれたのになァ

886 :デフォルトの名無しさん:2011/11/13(日) 03:15:54.38
>>872

これで墓穴掘ってるな

887 :デフォルトの名無しさん:2011/11/13(日) 03:20:00.27
>>872
どこにDOMの話が出てくるんだ?最悪だなお前

888 :デフォルトの名無しさん:2011/11/13(日) 03:21:44.84
>>872
お前フルボッコじゃねーか
みんなお前が悪いってよ

889 :デフォルトの名無しさん:2011/11/13(日) 03:39:16.18
>>872

オラオラ出てこいよ

890 :デフォルトの名無しさん:2011/11/13(日) 05:18:06.28
どうせQだろ

891 :デフォルトの名無しさん:2011/11/13(日) 05:42:07.87
意訳「SAX?知らんがな」

892 :デフォルトの名無しさん:2011/11/13(日) 06:00:31.24
オラオラかかってこいよ!

893 : ◆QZaw55cn4c :2011/11/13(日) 08:54:44.39
>>830
×SIRI
○SSRI
あまりきかないどころか凶暴化するという。個人的にはメチルフェニデートがお勧めだが‥‥‥。

894 :デフォルトの名無しさん:2011/11/13(日) 09:03:37.45
>>839
釣りだったんだからほっときゃ良かったのに。

895 :デフォルトの名無しさん:2011/11/13(日) 09:05:18.26
>>893にレスしたつもりが間違えた。
どうでもいいか。

896 :デフォルトの名無しさん:2011/11/13(日) 09:53:01.56
>>859
内部までUTF-8のOSなんてある?
ほとんどUTF-32だろ。
glibcは最初期からそうだし。

897 :デフォルトの名無しさん:2011/11/13(日) 10:38:48.82
>>896

お前>>863だろ
もう出てくるな
うざい

いまどきUTF-8じゃないOSなんてWindowsくれーだろ
あとしね

898 :デフォルトの名無しさん:2011/11/13(日) 10:40:19.24
オラオラかかってこいよ!

899 :デフォルトの名無しさん:2011/11/13(日) 10:43:52.66
私も>>896は異常者だと思います。
狂ってると思います。

900 :デフォルトの名無しさん:2011/11/13(日) 10:47:12.01
>>896
>>896
>>896
>>896
>>896

901 :デフォルトの名無しさん:2011/11/13(日) 12:12:01.82
マッキントッシュがUTF-8じゃなかったっけ

902 :デフォルトの名無しさん:2011/11/13(日) 12:41:31.23
UTF-16=itanium
UTF-8 =amd64

903 :デフォルトの名無しさん:2011/11/13(日) 17:36:50.95
itaniumはUTF-32だろ

904 :デフォルトの名無しさん:2011/11/13(日) 17:43:38.99
UTF-32はSparkじゃね。

905 :デフォルトの名無しさん:2011/11/13(日) 18:04:44.59
よく分からない例えはやめなしゃれ

906 :デフォルトの名無しさん:2011/11/13(日) 18:32:38.53
内部コードにUTF-8使ってるOSなんて知らんな。

907 :デフォルトの名無しさん:2011/11/13(日) 19:32:04.24
MacOSXはUTF-8

908 :デフォルトの名無しさん:2011/11/13(日) 20:17:34.48
NSStringやCFStringは内部UTF-16に見えるが

909 :デフォルトの名無しさん:2011/11/13(日) 20:19:00.30
ファイルシステムやAPIでUTF-8が通るからと言って実装がどうこう言うのはなー
大御所Plan9でさえ怪しいのに

910 :デフォルトの名無しさん:2011/11/13(日) 20:21:03.04
linuxもKernel 2.6.x ぐらいからパッチ導入してUTF-8サポートした
Plan9以降UNIXはUTF-8だし。

911 :デフォルトの名無しさん:2011/11/13(日) 20:33:07.93
OSXはSJISとEUCの名残がある部分があるが、
UTF-16ってのは無いな。低水準APIがワイド文字使わないし。
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference
/CFStringRef/Reference/reference.html

912 :デフォルトの名無しさん:2011/11/13(日) 20:46:43.82
>>893
中学生ですかあんた…。
これだからメンヘラはキモイって言われるんだ。

913 :デフォルトの名無しさん:2011/11/13(日) 20:56:12.04
Qは完全な重症自己愛性人格障害だね

914 :デフォルトの名無しさん:2011/11/13(日) 22:02:22.72
>>858
当たり前でしょ、そんなこと! クロスコンパイルを知らないかって、そんな無礼な質問があるか!!
君はイエストシキイッソを知ってるか、そう聞かれたらどうするんだ君!

915 :デフォルトの名無しさん:2011/11/13(日) 22:05:45.11
ageてtypoまでしてつまんねぇとか

916 :デフォルトの名無しさん:2011/11/13(日) 22:25:57.78
そういうコピペだから

917 :デフォルトの名無しさん:2011/11/14(月) 01:02:47.72
>>910
それはパス名なんかの外部表現でしょ。
中はiconvベースだからUTF-32。


918 :デフォルトの名無しさん:2011/11/14(月) 01:42:37.14
>>911
CFStringは基本的にUTF-16(Mac OS X的にはUniChar)を
格納することを想定しているコンテナ。
他のものが格納されていても変換することはできるが。
その辺の事情はCFStringGetCharactersPtr等のドキュメントを読めば分かる。
iOSでプログラム書いた人間走ってることと思うが。

919 :デフォルトの名無しさん:2011/11/14(月) 01:51:17.86
俺はUTF-16なんて見たことない
いまどきUTF-16なんてM$だけだろ

920 :デフォルトの名無しさん:2011/11/14(月) 02:02:48.51
Mac, iOSがUTF-16なのはたぶん内部的にICUを使っているからでもあるからだろうな
ICUで使ってる内部表現がそうだから
プログラム言語だとUTF-16が多数派では(実際にはUCS-2にしか対応していない
ものが多いかもしれないが)



921 :デフォルトの名無しさん:2011/11/14(月) 02:23:03.17
>>919
土方には必要ないんで。

922 :デフォルトの名無しさん:2011/11/14(月) 05:20:50.11
WikipediaにはMacとUnixではwchar_tは32バットって書いてあるぞい?

923 :デフォルトの名無しさん:2011/11/14(月) 05:37:39.54
Unixが何を意味するのか分からないけど、俺の手元の資料ではロケールがサポートする
文字をすべて収納できる整数としか規定されていないな。

924 :デフォルトの名無しさん:2011/11/14(月) 06:33:31.96
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で扱う

どっちなんだい、まっ今ティッシュ^^

925 :デフォルトの名無しさん:2011/11/14(月) 08:09:41.28
>>922
それは事実。wchar _tが16なんて環境Windowsぐらいじゃね。

926 :デフォルトの名無しさん:2011/11/14(月) 08:16:12.23
>>917
興味があるから、カーネルのどの辺りのコードで変換してるか教えて。
カーネルソースをwchar_tでくぐってもそれらしいものが見つからなかった。
stringクラス的なものを構造体で作って管理してたりすんのかな。

927 :デフォルトの名無しさん:2011/11/14(月) 08:32:32.14
おまえら海栗コードスレでやれ

928 :デフォルトの名無しさん:2011/11/14(月) 08:38:20.66
M$はC++を捨てたんだから、ここもUNIXスレだろ。

929 :デフォルトの名無しさん:2011/11/14(月) 09:36:15.94
>>928
実装にかかわらずここは規格に沿ったC++のスレです

930 :デフォルトの名無しさん:2011/11/14(月) 15:41:13.42
サロゲートペアを許容してるCLのwchar_tは規格違反の気がする。
せっかくchar16_tがやってきたんだし、typedef WCHAR くらいは char16_t のほうにしてほしい。
むりだろうなあ

931 :デフォルトの名無しさん:2011/11/14(月) 17:25:52.14
>>928
msがC++捨てるにはxp,vista,7を捨てる必要が有るから、あと10年は捨てられんでしょ

そしたら中古になったvs2011拾ってやるよ


932 :デフォルトの名無しさん:2011/11/14(月) 17:28:56.86
カーネルがsingularityベースに変わるまではムリだろ

933 :デフォルトの名無しさん:2011/11/14(月) 19:29:20.68
>>924
wchar_tとunicodeは、直接関係ないからね。
unicode使っててもwchar_t使わないケースはいくらでもある。

934 :デフォルトの名無しさん:2011/11/14(月) 19:40:38.87
>>930
合成文字と異体字セレクタがある時点で、UTF-32なwchar_tも規格違反だけどな!
wchar_tは「とにかく全ての文字を固定長で表現できるなにか」なんだから。

935 :デフォルトの名無しさん:2011/11/14(月) 20:03:06.81
wchar_tってどっちかつうとUnicode よりマルチバイト文字向けだよな。

936 :デフォルトの名無しさん:2011/11/14(月) 20:24:24.87
wchar_tの類はコンテナだから中身には関与しないんだろうね。
今、妥当な使い方がUTF-16などっていうだけで。

937 :デフォルトの名無しさん:2011/11/14(月) 20:31:36.48
「全ての文字」の定義次第だな

938 :デフォルトの名無しさん:2011/11/14(月) 20:32:52.21
wchar_tはGCCでは32ビットだったような

939 :デフォルトの名無しさん:2011/11/14(月) 20:37:31.25
__STDC_ISO_10646__
が定義されている場合はwchar_tの中身がunicodeということになるはず

940 :デフォルトの名無しさん:2011/11/14(月) 20:40:31.81
ただし符号化方式は問わない・・・か

941 :デフォルトの名無しさん:2011/11/14(月) 21:05:44.98
Unicodeというと符号化文字集合と文字符号化方式の2つを指してしまうから、
符号化文字集合はUCS-4、文字符号化方式はUTF-xと呼ぼうぢゃないか。

942 :デフォルトの名無しさん:2011/11/15(火) 00:34:48.62
http://d.hatena.ne.jp/kamoya11/20100331/1270030798
固定長単位であつかうことがどうもうまくいかないっぽいから
もうUTF-8でいいんじゃないかって気もしないではないけど
専用の型や関数がない現状じゃめんどくさすぎるよな

943 :デフォルトの名無しさん:2011/11/15(火) 00:38:55.92
元々charが何ビットかって事自体実装依存なんだから、char8_tを作るべきだったよな。

944 :デフォルトの名無しさん:2011/11/15(火) 00:47:08.47
VC++ ExpressってC++11に対応してる?

945 :デフォルトの名無しさん:2011/11/15(火) 01:07:13.20
>>944
コンパイラで言えば仮対応してるだろ。
てか、タダなんだからためせ。

>>942
文字リテラルが一番の問題じゃね。
一回配列に突っ込んでしまえば、ダメ文字問題もないしそうそう困らないと思うけど。

946 :デフォルトの名無しさん:2011/11/15(火) 01:12:28.05
>>945
ロケールに従う従来のcharと、UTF-8なcharでオーバーロードができないって話じゃね?

947 :デフォルトの名無しさん:2011/11/15(火) 01:46:22.97
mblen(u8"UTF-8文字列", MB_LEN_MAX); // ロケール依存

文字数カウントもまともに出来ないようじゃなあ

948 :デフォルトの名無しさん:2011/11/15(火) 02:10:18.78
もうwchar_tでいいや

949 :デフォルトの名無しさん:2011/11/15(火) 07:20:03.84
マルチバイト文字数なんて必要か? そもそも

950 :デフォルトの名無しさん:2011/11/15(火) 08:00:30.25
おまえのバーチャンにnバイト以内で記述してくださいって言って通じるなら必要ない

951 :デフォルトの名無しさん:2011/11/15(火) 08:08:22.90
スレタイ

952 :デフォルトの名無しさん:2011/11/15(火) 08:25:12.63
ラムダ関数ってインライン関数になるんですか?

parallel_for(0,10000000,[](int a){/*短い処理*/});

関数が短いとき、インラインになることが保証されてないと
関数呼び出しコストがバカにならないような。

953 :デフォルトの名無しさん:2011/11/15(火) 08:29:20.72
>>949
1文字の途中で切れないようにするのに必要。
1024B容量あるとしても、1023バイト目は1バイト目で
切れてるとかは困るからね。とは言え複合文字のせいで
どのみち中途半端になるが。

954 :デフォルトの名無しさん:2011/11/15(火) 08:32:10.61
>>952
今までインライン展開が保証された事ないでしよ。
実装依存。

955 :デフォルトの名無しさん:2011/11/15(火) 11:11:00.19
>>953
UTF-8のときはmblenが合成文字やVSも含めた長さを返してくれれば……
でもそうすると切り出した一文字分をwchar_tに入れられない……

956 :デフォルトの名無しさん:2011/11/15(火) 13:10:06.98
C++でUnicodeを扱うのは、C++でGUIを扱うのと同じである…
こう考えれば済むだけの話だったんだよ。

957 :デフォルトの名無しさん:2011/11/15(火) 13:34:21.31
正規化まで考慮してUnicode扱ってるアプリなんて正直見たこと無い。
それで困らないということかもしれないが。

958 :デフォルトの名無しさん:2011/11/15(火) 18:29:49.35
C++の仕様についてまとめるより別のシステム向け言語つくってくれたほうが
万人にシアワセじゃねーのか。もうおじさんついてけないよ

959 :デフォルトの名無しさん:2011/11/15(火) 19:19:14.77
>>954
保証はともかく、inline指定したのと同じ効果になるかどうかだな

960 :デフォルトの名無しさん:2011/11/15(火) 19:22:21.07
これ一択みたいな文字コードライブラリって有るの?

961 :デフォルトの名無しさん:2011/11/15(火) 19:53:43.33
iconvくらいしか知らない

962 :デフォルトの名無しさん:2011/11/15(火) 20:06:54.89
IBM ICUだよ。
C++ bindingもあるけど11じゃないからスレ違いだけどな。

963 :デフォルトの名無しさん:2011/11/15(火) 20:10:19.12
>>956
GUIそんなに辛いか?
Qtなんか使うと他の言語の方が面倒に感じる。

964 :デフォルトの名無しさん:2011/11/15(火) 23:40:45.92
GUIはテキストベースのプログラミング言語自体と根本的に相性が悪い気がしないでもない
オーサリングツールがないとやってられん

965 :デフォルトの名無しさん:2011/11/16(水) 00:13:10.59
確かにシェルスクリプトやらPerlやらawkやらでGUIは辛いな。
コールバック可能な仕組み作るだけでも面倒だ。

966 :デフォルトの名無しさん:2011/11/16(水) 00:23:52.47
Perlはtkあるじゃん

967 :デフォルトの名無しさん:2011/11/16(水) 00:28:49.66
dtkshなら今のLL並に簡単にGUIアプリ書けるよ。

968 :デフォルトの名無しさん:2011/11/16(水) 00:32:24.32
C++ AMPの対抗馬というよりは、OpenMPのGPUアクセラレーション版と捉えた方が良いのかな
Nvidia’s OpenACC Standard | SemiAccurate
http://semiaccurate.com/2011/11/15/nvidias-openacc-standard/


969 :デフォルトの名無しさん:2011/11/16(水) 00:33:02.81
どうでもいいがPerlとかRubyとかLLって言うのおかしくね?
そんなん言ってるの非論理的な日本人だけじゃん。
海外サイトでLLっていったらCレベルの速度が言語の事。

970 :デフォルトの名無しさん:2011/11/16(水) 00:39:35.35
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;
        }
    );
}

971 :デフォルトの名無しさん:2011/11/16(水) 00:47:44.71
賢くて優秀なお前らに質問だ!

以下のようなコードを書いたんだ。
ttp://ideone.com/n4aAH

で、見ればわかるがランダムなコードのファイルを吐くだけの単純なコードなんだけど、乱数の初期化部分にstdlibのrand使ってるんだよ。
これはある程度乱数をコントロールしてファイルを吐きたい意図があるわけなんだが、今の時代にこれはないだろうと思うのさ。

そこで、大喜利逝ってみよう。
どうすれば、意図に沿った上で今風になるか。

ちなみに開発環境はVC10EEだけど、俺が読めるコードだったらそれに限らない。

どうよ!!

972 :デフォルトの名無しさん:2011/11/16(水) 00:49:07.55
まあ、C++11の機能なんてD言語みたいなものだから、いつまで経っても実際の現場では使えないんだろうな。

C++は結局Better C以上にはなり得ない。

973 :デフォルトの名無しさん:2011/11/16(水) 00:50:13.30
>>971
C++相談室でやれ。

974 :デフォルトの名無しさん:2011/11/16(水) 00:50:46.12
>>971
先ず、文章を今風にしてこい。

何年前の2ちゃんねるだよ。

975 :デフォルトの名無しさん:2011/11/16(水) 00:58:36.27
そういやVC10ってuint_leastN_tまともに実装してないな。
オーバーロードがまともに動かん。相変わらずのMSだ。

976 :デフォルトの名無しさん:2011/11/16(水) 00:58:39.50
>>973
うーん。ここの人だったら明快な答えくれると思ったんだけど。
ま、誘導ありがとう。

>>974
レートマジョリティよりも行動が遅い俺にはちょっと難しいぜ。


いてきまーす。

977 :デフォルトの名無しさん:2011/11/16(水) 11:09:19.72
渡されたラムダ関数の引数の型によって呼び出す関数を変えるオーバーロードってできないんですか?

978 :デフォルトの名無しさん:2011/11/16(水) 11:44:08.82
関数ポインタに変換すればできそうだけど
vcじゃできないらしい…

979 :デフォルトの名無しさん:2011/11/16(水) 12:47:47.14
ラムダから関数ポインタへの変換は無理じゃね?だいたいキャプチャした変数どうするんだよ

980 :デフォルトの名無しさん:2011/11/16(水) 12:57:30.88
キャプチャを使っていないラムダ式は関数ポインタと同じように使えるって仕様が入ったんだよ

981 :デフォルトの名無しさん:2011/11/16(水) 13:01:39.12
キャプチャなしなら最適化でカンポに変えてよい

982 :デフォルトの名無しさん:2011/11/16(水) 17:29:33.14
>>977
ワンクッション挟んで
ttp://ideone.com/6Acp1

983 :デフォルトの名無しさん:2011/11/16(水) 19:02:36.75
キャプチャ無しなら変換できたはず、最終的な仕様では

984 :デフォルトの名無しさん:2011/11/16(水) 19:04:49.22
そろそろ次スレだが、C++0xってまだいるかね

985 :デフォルトの名無しさん:2011/11/16(水) 19:34:31.59
>>977
可変長引数テンプレートを使ったクラスで包めば出来る。

>>984
バカが重複スレ立てるからいるだろ。

986 :デフォルトの名無しさん:2011/11/16(水) 20:42:54.23
バカを隔離できるのはむしろメリットではないか?

987 :デフォルトの名無しさん:2011/11/16(水) 21:19:53.62
ISO/IECのページやGCCのページもC++11って書いてるし
これからはC++0xって書くと、古い情報のように思われるかも

ttp://www.open-std.org/jtc1/sc22/wg21/
ttp://gcc.gnu.org/projects/cxx0x.html

C++11がいいと思う

988 :デフォルトの名無しさん:2011/11/16(水) 22:20:15.94
C++11 15だけだとC++スレの1115本目だと思われる

989 :デフォルトの名無しさん:2011/11/16(水) 22:26:24.47
じゃ C++11 0x0Fで

990 :デフォルトの名無しさん:2011/11/16(水) 22:34:13.88
C++11/C++0x/ISO/IEC 14882:2011 15 で

991 :デフォルトの名無しさん:2011/11/16(水) 23:08:35.14
「C++11 part15」でいいだろ

992 :デフォルトの名無しさん:2011/11/16(水) 23:17:17.49
C++11はもう正式な標準になったんだから、C++11の話はC++相談室でいいだろ。
こっちはC++1xとか「次期C++標準」とか、そういうスレになるんじゃないの?

993 :デフォルトの名無しさん:2011/11/16(水) 23:21:22.74
次期規格つっても5〜7年後だろ。
98⇨03⇨11って流れだからな。
ネタがないって。

994 :デフォルトの名無しさん:2011/11/16(水) 23:21:59.16
最狂言語スレ?

995 :デフォルトの名無しさん:2011/11/16(水) 23:22:54.74
>>993 ネタが無いならこのスレ終了ってことでいいんじゃね?

996 :デフォルトの名無しさん:2011/11/16(水) 23:24:24.02
まともに実装されて普及されるまでは必要だな

997 :デフォルトの名無しさん:2011/11/16(水) 23:28:18.80
スレタイ云々は次スレで決めてくれ
C++11/C++0x 15
http://hibari.2ch.net/test/read.cgi/tech/1321453654/

998 :デフォルトの名無しさん:2011/11/16(水) 23:34:19.32
おまえらすぐハゲ頭になりそうだな
どうでもいいことで悩んで

999 :デフォルトの名無しさん:2011/11/16(水) 23:55:19.91
999

1000 :デフォルトの名無しさん:2011/11/16(水) 23:55:38.73
1000ならC++11が普及する

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

204 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)