C++0x - 暇つぶし2ch

C++0x at TECH

1:デフォルトの名無しさん
06/06/05 02:04:07
どんな感じになるの？

2:デフォルトの名無しさん
06/06/05 02:08:28
2?

3:デフォルトの名無しさん
06/06/05 02:10:44
転載だけど、こうなるらしい。

--- C++98 Code ---
vector<int> v;
v.push_back(1);
v.push_back(2);
v.push_back(3);
vector<int>::iterator i = find(v.begin(), v.end(), 2);

--- C++0x Code ---
vector<int> v = { 1, 2, 3 };
auto i = find(v, 2);

STLヴァリヴァリな人にはとってもラクチンになる予感。

4:デフォルトの名無しさん
06/06/05 02:12:31
今まで出来なかったのが不思議

5:デフォルトの名無しさん
06/06/05 02:13:23
本当にあと2年半以内に出るのか？

6:デフォルトの名無しさん
06/06/05 02:14:26
標準C++に対してコンパイラの準拠レベルが低かったからでしょ。
規格だけ新しくしても実情が付いてこなけりゃどうにもならん。
実装してみて初めて分かることってのもあるし、様子を見てたんじゃないの？

7:デフォルトの名無しさん
06/06/05 02:15:11
>>5は算数を勉強しなおしたほうがいいと思う

8:デフォルトの名無しさん
06/06/05 02:15:27
コンパイル速度が速くなると良いな。Pascal 並みとは言わんけど、常識的な速度で plz.

9:デフォルトの名無しさん
06/06/05 02:17:19
またいろいろ肥大化するんだろうなあ。
こうしてC++は巨大言語の地位を不動のものとするのでありました。

10:デフォルトの名無しさん
06/06/05 04:25:24
標準化に関わってるメンバはインテルから金貰ってる。

11:デフォルトの名無しさん
06/06/05 12:08:10
さっさと右辺値参照と perfect forwarding よこしやがれこんちくしょー！！

12:デフォルトの名無しさん
06/06/05 14:18:42
2010年になってもまだ制定されてなかったら
0xは16進数のprefixだっていうことにならんかな

13:デフォルトの名無しさん
06/06/05 16:49:10
>>3
後者のfindは今のboost.range_ex相当だと思っていいんだよな？

14:デフォルトの名無しさん
06/06/05 17:38:27
>>11
C++ってもうプログラミング言語の実験室だな。

URLﾘﾝｸ(www.open-std.org)
を見ていると欲しい機能が満載w

15:デフォルトの名無しさん
06/06/05 18:58:15
javaみたいに継承禁止を指定できるようになる？

16:デフォルトの名無しさん
06/06/05 20:43:59
>>3
Boostでほぼ実現されているところが怖いな

>>15
BoostのVaultになんかあったぞ

17:デフォルトの名無しさん
06/06/05 21:55:44
std::tr1を実装しているところてあるのかな

18:デフォルトの名無しさん
06/06/05 21:56:24
>vector<int> v = { 1, 2, 3 };
これCとの互換性なくならない？
配列のサイズどうする気なの？

19:デフォルトの名無しさん
06/06/05 21:59:29
libstdc++にあるよ

$ ls /usr/include/c++/4.1.1/tr1
array bind_iterate.h bind_repeat.h boost_shared_ptr.h
functional functional_iterate.h hashtable memory
mu_iterate.h ref_fwd.h ref_wrap_iterate.h repeat.h
tuple tuple_iterate.h type_traits type_traits_fwd.h
unordered_map unordered_set utility

URLﾘﾝｸ(gcc.gnu.org)

20:デフォルトの名無しさん
06/06/05 22:03:35
>>18
> これCとの互換性なくならない？

どうなくなるの?

> 配列のサイズどうする気なの？

boost/preprocessor/array/*と同じ動作になるんじゃないの?

21:デフォルトの名無しさん
06/06/07 17:16:02
もしもBoost.LambdaがそのままC++に取り込まれたら世も末だな。

22:デフォルトの名無しさん
06/06/07 21:18:51
手続き、構造化、OOP、ジェネリック、さらに関数型の記述も混在できる！！

…確かに末だな。

23:デフォルトの名無しさん
06/06/07 21:23:41
え～，それが面白いんじゃんかー．ぶーぶーぶー

24:デフォルトの名無しさん
06/06/07 22:53:24
lambda記法は、新しい構文で提案されてますよ。

Lambda expressions and closures for C++
URLﾘﾝｸ(www.open-std.org)

25:21
06/06/07 23:07:50
>>24
勿論それは知っている。
だからこそ21を書いた。

26:デフォルトの名無しさん
06/06/08 09:24:36
Boostのlambdaなんて繋ぎですよ

27:デフォルトの名無しさん
06/06/08 18:50:12
io,stream,国際化関係
を分かりやすくかつ高パフォーマンスにして欲しい。
今のは使いにくい。

28:デフォルトの名無しさん
06/06/08 20:33:34
名前がかっこいいから策定されても仕様名はC++0xのままにしてほしい

29:デフォルトの名無しさん
06/06/08 20:54:05
勧告された暁にはちゃんと年月にちなんでC++0xFFと呼ばれます。

30:デフォルトの名無しさん
06/06/10 07:30:18
せめて標準ライブラリの部分だけでも、5年に一度ぐらいの割合で
改訂してくれんかな。

31:デフォルトの名無しさん
06/06/10 10:36:15
一応そのくらいでやるつもりなんでしょ。

32:デフォルトの名無しさん
06/06/11 11:33:06
二進数表記ができるようになってほしい。

33:デフォルトの名無しさん
06/06/11 11:47:29
>>32
2進←→16進なんて簡単に脳内で変換できるんだから要らなくね？

34:デフォルトの名無しさん
06/06/11 12:02:14
>>32
10bitまでならherumiさんのtemplateで出来るぞ。

35:デフォルトの名無しさん
06/06/11 12:08:43
>>33
ソース中に記述できることには別の意義がある。

36:デフォルトの名無しさん
06/06/11 12:19:32
>>35
例えば？

37:デフォルトの名無しさん
06/06/11 12:24:39
プレフィクスつけて指定する形を取ってるからなあ…
0 → 8進
0x → 16進
じゃあ2進は？

後ろにhとかoとかの形式なら、bを増やせばいいだけなんだが…。

38:デフォルトの名無しさん
06/06/11 12:31:38
D言語とかでは0bをプレフィックスにしてたな。
ただ、2進表記は微妙と個人的には思う。

0b10101010101010101010101010101010
0x55555555

ソースコード上の2進表記を読み取るより、
16進表記を脳内で2進に変換するほうが個人的には圧倒的に楽

39:デフォルトの名無しさん
06/06/11 12:37:17
仕様が２進表記を使っている場合に
ソース上で１６進表記になっていると、
仕様を変更するときには変換しないといけないだろ？
ソース中に２進表記ができればコピペで済む所が
脳内変換を必要とするわけよ。これはよくない。

40:デフォルトの名無しさん
06/06/11 12:39:05
2進 <-> 16進で脳内変換できないようなカスは別の言語をどうぞ

41:デフォルトの名無しさん
06/06/11 13:10:33
ぶっちゃけ2進数表記は長くなる傾向が多くて使い辛い。
短い表記ならtemplateでも対処できるわけだし。

42:デフォルトの名無しさん
06/06/11 13:29:32
2進と16審の脳内変換・・・って・・・
手間はコピペするのと大差無いだろ。何が問題なのかわからん。

それともいちいち、2進の各桁に2のn乗かけて・・ってやらないと変換出来ないヘタレか？
10進数を介さないと変換できません、とか。

そんな低脳のために余計な仕様付ける方がどうかしてるわ。

43:デフォルトの名無しさん
06/06/11 13:37:19
２進データ１０００個のテーブルでも
コピペと脳内変換で大差ないと思うの？
少なくとも俺は面倒で嫌だな。
２進と１６進の変換は普通にできるけどね。

44:デフォルトの名無しさん
06/06/11 13:48:08
どうせ2進テーブルっつったって0bみたいなprefixがついてるわけじゃないだろう？
正規表現やら何やらを使って半自動で追加させるのも、
16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
どちらにせよそんな限られた状況のためだけに2進数定数を仕様に導入する価値はないと思う。

45:デフォルトの名無しさん
06/06/11 13:54:55
>>44
> 16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
十分メンドクセェよ。仕事頼める人が限られるのもウザイ。

限られた状況なのはわかってる。しかし一部には確実なニーズがあり、
仕様については実装も簡単だし互換性に影響しないこともあるんで、
追加してもいいだろうとは思う。

これ以上は水掛け論だろうねぇ。

46:デフォルトの名無しさん
06/06/11 14:02:00
バイナリリテラルは、エンディアンやらビット長の問題で解釈の仕方が実装依存だから
標準規格に入ってない（というか入れられない）だけじゃなかったか？
今後も入ることはないだろ。

47:デフォルトの名無しさん
06/06/11 14:08:15
えぇー。1バイトが8ビットじゃないマシンって話にしか聞いたことないけど、まだあるの？

48:デフォルトの名無しさん
06/06/11 14:09:37
>>46
そんな問題は１６進でも同じじゃないか？

49:デフォルトの名無しさん
06/06/11 14:11:41
2<->16変換なんて自前で書きゃいいだろ30秒もかからんぞ
#include<stdio.h>
#include<stdlib.h>
int　main(){
　　　　char　s[80];
　　　　while(gets(s))printf("0x%08lX\n",strtoul(s,0,2));
　　　　return　0;
}

50:デフォルトの名無しさん
06/06/11 14:14:59
>>48
例えば
int i=0x10;
は、ビッグエンディアンなら10000、リトルエンディアンなら00001のビット列と解釈される（コンパイラが自動でやってくれる）ので
ソースコードを別マシンに移しても問題ないけれど、
int i=0b10000;
という表記を認めたら、それは0x10なのか、それとも0x1なのかの解釈がコンパイラによって変わってしまい、
ソースコードの移植性がなくなるって話だろ。

51:デフォルトの名無しさん
06/06/11 14:16:09
>>49
はいはい。スゲェスゲェ。

そのレベルで済ませられる奴が同じチームに何人居ると思う？
何人も居たとして、同じ（似たような）機能のツールを
世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？

52:デフォルトの名無しさん
06/06/11 14:17:54
10進数だけでいいじゃん

53:デフォルトの名無しさん
06/06/11 14:19:25
>>50
エンディアンはメモリなどのバイト列を考えたときの
バイトオーダーの話だから、数値の表現形式自体とは関係ないよ。
0x10 が 16 と定まるように、 0x10 は 0b10000 と定まる。

54:デフォルトの名無しさん
06/06/11 14:23:01
>>51
>そのレベルで済ませられる奴が同じチームに何人居ると思う？
>何人も居たとして、同じ（似たような）機能のツールを
>世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？
驚いたwwww
ひどい低能だな
お前にプログラミングは向いてない
やめたほうがいいと思われ

55:デフォルトの名無しさん
06/06/11 14:23:12
bitmapなんかをソースに埋め込みたいときに使えると便利だな

56:デフォルトの名無しさん
06/06/11 14:25:41
D&Eぐらい嫁。
C++標準委員会は既にバイナリリテラルへの対応を予備審査で却下してるんだから
これから実装されることはまずあり得ない。

57:デフォルトの名無しさん
06/06/11 14:25:58
>>54
質問には答えてほしかったんだが、まぁいい。
どうせ現実世界には影響の無い与太話だ。

58:デフォルトの名無しさん
06/06/11 14:35:53
今気づいたが、禿のC++Glossaryでは
　C++0x - the upcoming revision of the ISO C++ standard; 'x' is scheduled to be '9'. See my publicatons page.
2009年予定なのね…
ISOの改訂って5年ごとじゃなかったっけか？

59:デフォルトの名無しさん
06/06/11 15:11:00
個人的にはビットパターンを図示しやすくなるからバイナリリテラルはあってもいいと思う。
で、やるからには8or4ビットごとにセパレータを入れられればもっといい。
Ex. 0xdead → 0b1101_1110_1010_1101

60:デフォルトの名無しさん
06/06/11 15:51:52
URLﾘﾝｸ(www.illegal-immigration.com)
これか。いつ追加されるのだ
まーこんなのよく考えるもんだ

61:・∀・）っ-○◎● ◆toBASh....
06/06/11 18:00:21
_0b00000000～_0b11111111までとか定数定義して、あと16bitとか32bitとかマクロで連結する
ってことやってる会社は知ってる

62:デフォルトの名無しさん
06/06/11 18:03:11
全部マクロでやってるヘッダならboostで見た気がする

63:デフォルトの名無しさん
06/06/11 18:05:25
CでGUIアプリってつくれるの？
javaしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるCとか、かんたんできるCとか
いろいろ本でてますけどCUIだよな。
どうしたらCでGUIアプリ作れるの？

64:デフォルトの名無しさん
06/06/11 18:08:20
スレ違いも甚だしい

65:デフォルトの名無しさん
06/06/11 18:10:25
Javaでネイティブアプリってつくれるの？
Cしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるJavaとか、かんたんできるJavaとか
いろいろ本でてますけどVMだよな。
どうしたらJavaでネイティブアプリ作れるの？

66:デフォルトの名無しさん
06/06/11 18:22:05
GCJ

67:デフォルトの名無しさん
06/06/11 20:15:11
>>58
五年ごとって決まっているのは一部でしょ。
たとえばFORTRAN。

68:デフォルトの名無しさん
06/06/12 23:27:59
C++ Template Metaprogramming にはこんなのもあるよ。

template <unsigned long N>
struct binary
{
static unsigned const value
= binary<N/10>::value * 2 + N % 10;
}

69:デフォルトの名無しさん
06/06/12 23:31:13
>>68 assert(binary<0101>::value == 5);

70:デフォルトの名無しさん
06/06/12 23:39:28
59について思ったのだが、68で、テンプレート引数をいくつも取るようにしてやればいいと思った。

template<
　　　　unsigned　long　Byte1,　unsigned　long　Byte2,
　　　　unsigned　long　Byte3,　unsigned　long　Byte4>
struct　binary4
{
　　　　staic　const　unsigned　long　value　=
　　　　　　　　binary<Byte1>::value　<<　24　|
　　　　　　　　binary<Byte2>::value　<<　16　|
　　　　　　　　binary<Byte3>::value　<<　8　|
　　　　　　　　binary<Byte4>::value　<<　0;
};

binary4<11110001,　11100010,　11010011,　11000100>::value　==　0xf1e2d3e4

71:デフォルトの名無しさん
06/06/12 23:58:14
馬鹿には>>60が見えないのか？
templateはboostに却下された

72:デフォルトの名無しさん
06/06/13 00:03:22
Boostに入らなければ個人的に作って使えばよいだけ。

73:デフォルトの名無しさん
06/06/13 01:11:05
実用性ゼロの趣味テンプレート

74:デフォルトの名無しさん
06/06/20 19:53:27
保守

75:デフォルトの名無しさん
06/06/24 01:13:05
TR1の本ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!!!!

URLﾘﾝｸ(www.amazon.com)
URLﾘﾝｸ(www.aw-bc.com)

Pete Beckerﾊｧﾊｧ
URLﾘﾝｸ(www.petebecker.com)

76:デフォルトの名無しさん
06/06/24 01:37:47
>>75
本を出す意義がわからん。
↓のドラフトや boost の実装、ドキュメントで十分だろ。
URLﾘﾝｸ(www.open-std.org)

77:デフォルトの名無しさん
06/06/24 02:37:21
EffectiveSTLのTR1に合わせた改訂予定はあるのかな

78:デフォルトの名無しさん
06/06/24 05:35:16
ライブラリもいいけど、早いとこ concept や rvalue reference
決めねえと間に合わなくなると思うんだがな。こいつら入ったら
ライブラリ大幅に書き直しじゃん？

79:デフォルトの名無しさん
06/06/24 09:49:39
>>75
Peteが出すんだから、出す意味のある内容なんじゃないのかね。
>>78
0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。
C++って本当、永遠に仕様が確定しそうにないよな。

80:デフォルトの名無しさん
06/06/24 13:02:27
C++は完璧ではないし、完璧になることはあり得ない。常に進化し続ける。
とは禿の言葉だっけか

81:デフォルトの名無しさん
06/06/24 14:31:54
常に進化し続けるのはいいが仕様が確定しないと処理系が出てこないわけで。

82:export
06/06/24 14:55:05
すみません。
私を知っている人はいますか？

83:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/06/24 15:14:38
仕様があるのにどの処理系でも未だサポートされないキーワードの典型ですな

84:デフォルトの名無しさん
06/06/24 15:42:03
name lookup ruleも永遠に定まらないだろうな。

85:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/06/24 15:46:48
ガベコレでも標準ライブラリに入れて欲しいと思うの俺だけ？

86:デフォルトの名無しさん
06/06/24 16:53:21
ガベコレが必要なのはCだろう...
shared_ptrは再帰デストラクタ失敗するのが弱点だよな。

87:デフォルトの名無しさん
06/06/24 17:23:13
>>86
> shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
なんのこと？

88:デフォルトの名無しさん
06/06/24 17:30:52
循環参照のことでは？

89:デフォルトの名無しさん
06/06/24 18:50:37
>>82
concept の導入によりテンプレートの定義と実装を分けることが
可能になれば、あるいは再デビューできるかも試練よ

90:デフォルトの名無しさん
06/06/24 19:01:55
>>78
>0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。

現状の年２回のミーティングじゃ３年なんてあっと言う間だろう。

N2004より
>The following proposed changes will cause the C++0x schedule
>to slip if the committee does not commit to them by the end of
>the October, 2006 meeting, ...

91:デフォルトの名無しさん
06/06/24 20:46:20
200C年くらいに出れば御の字だよね

92:デフォルトの名無しさん
06/06/24 21:04:49
>>91
6198年後かよ

93:デフォルトの名無しさん
06/06/24 23:26:48
>>83
でも予約だけはされてんのな。

94:デフォルトの名無しさん
06/06/25 16:38:34
予約じゃないですよ。
既に規格の一部です。

95:デフォルトの名無しさん
06/06/26 08:09:14
予約だし、規格の一部だよ。

96:デフォルトの名無しさん
06/06/29 22:23:00
そういやどうして「予約語」っていうんだろう

97:デフォルトの名無しさん
06/06/29 23:45:12
>>96
字句は識別子としての要件を満たしているから。
だけど文法上特別な意味を持たすために、
識別子として使えないようコンパイラがその字句を「予約」している。

98:デフォルトの名無しさん
06/06/30 00:10:26
まあ「予約」語は誤訳みたいなもんで、(特に「予」め)
除外語がreserved workの訳には適当。

99:デフォルトの名無しさん
06/06/30 01:10:08
うはｗ　やべぇ concept_map 凶悪

concept_map InputIterator<int> {
　typedef int value_type;
　typedef int reference;
　typedef int* pointer;
　typedef int difference_type;
　int operator*(int x) { return x; }
};
copy(1, 17, ostream_iterator<int>(cout, " "));
　// prints: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

100:デフォルトの名無しさん
06/06/30 09:43:52
>98
「除外」のほうが違和感がある

101:デフォルトの名無しさん
06/06/30 12:53:14
「お客様、そこは除外席ですので、他の席をお使い下さい」

102:デフォルトの名無しさん
06/06/30 13:51:26
>>98
中学校からやり直せ。

いや、おまえは英語を読むな。

103:デフォルトの名無しさん
06/06/30 18:43:40
>>99
ヘタにガリガリ書くコーディングが減っていいんじゃないか？

104:デフォルトの名無しさん
06/07/10 12:59:49
　int operator*(int x) { return x; }
はやりすぎと思うが。

話題もないので張っときます。

URLﾘﾝｸ(www.open-std.org)

Strong candidates for TR2 include:
* Filesystem (accepted)
* Thread support
* Date and time
* Network file support
* Consistent system/OS error reporting
* Range-types, to complement iterators
* String algorithms
* Optional/Nullable values
* Range-checked numeric-casts
* 'Lexical' casts
* typesafe 'any' class
* interval arithmetic
* Unlimitted precision integer type

105:デフォルトの名無しさん
06/07/10 20:46:42
>>104
Thread単体でサポートしてもなぁ。
ACE見たく非同期関連のフレームワークと一緒でないとあんまり役に
たたない様な気がするけど。
(boost.)lexical_castはspiritがあるのでちっとも使わん。

106:デフォルトの名無しさん
06/07/11 03:12:35
>* typesafe 'any' class
　Boostにある、あれをそのまま盛り込むのだろうか。

>* Unlimitted precision integer type
　まあ、簡単につかえる標準ライブラリは欲しいかな。

107:デフォルトの名無しさん
06/07/11 06:56:10
基本的には同じ
Any Library Proposal for TR2
URLﾘﾝｸ(www.open-std.org)

かなり強力
Proposal for an Infinite Precision Integer for Library Technical Report 2, Revision 1
URLﾘﾝｸ(www.open-std.org)

108:デフォルトの名無しさん
06/07/12 22:26:27
>>105
でもC++に標準でスレッドサポートされる、というのは大きいんじゃまいか。
もしかしたら将来のCでもサポートされるかもしれんし。

109:デフォルトの名無しさん
06/07/12 22:42:35
tr2でXMLとかネットワークとかマジですか

実現したらかなり協力だなぁ

110:デフォルトの名無しさん
06/07/12 23:06:20
この調子で行けばC++　2xにはGUI関連が標準ライブラリに入るに違いない。

111:デフォルトの名無しさん
06/07/12 23:28:26
Boostで便利なのが軒並み入ってるな。
それ以外の勢力は元気なくてさみしい。

112:デフォルトの名無しさん
06/07/14 02:28:31
C++0xに対応したMSのコンパイラはいつ出るんだろ。
規格が決まってから、実装するまで何年ぐらいかかるのかな。

113:デフォルトの名無しさん
06/07/14 03:00:55
過去の例から考えると１０年くらいか orz

114:デフォルトの名無しさん
06/07/14 13:30:29
boost 1.34 には tr1が入るみたいだから、
boostからtr1が使っている部分だけ抜き出してそれをVC++用に使うようにすればいい
といってみるテスト

115:デフォルトの名無しさん
06/07/14 16:02:33
そういえば、いまさらで馬鹿にされる質問かもしれないけど、
新しいライブラリの名前空間はどうなるんだろう。
まさか　tr1　などというかっこ悪い名前空間のままだったりはしないよね。
でも、stdに押し込むと、既存のライブラリと衝突したりしないのかな

116:デフォルトの名無しさん
06/07/14 16:06:59
>>115
衝突しないようにstdに入れるんじゃまいか？

117:デフォルトの名無しさん
06/07/16 01:56:20
今はstd::tr1みたいだけど、最終的にはどうなるんだろね。

118:デフォルトの名無しさん
06/07/16 09:12:22
stdにいれるに決まってるじゃん。
けどJavaみたいに階層構造になっているのもいいよな。

importってのは、#includeとusingをうまく組み合わせていると思う。

119:デフォルトの名無しさん
06/07/16 10:13:57
階層化する前に、名前空間の記述の簡易化をはやく標準化して欲しいよ

120:デフォルトの名無しさん
06/07/16 10:46:32
namespace com { namespace example { namespace myproj { /* */ } } }
ってめんどくさいから、例えば
namespace com::example::myproj { /* */ }
とかね。

ふと思ったんだけど、C++0xはライブラリ以外の部分はどう変わるんだろう。

121:デフォルトの名無しさん
06/07/16 12:06:35
draft October 2005
URLﾘﾝｸ(www.open-std.org)

122:デフォルトの名無しさん
06/07/16 15:01:35
TR1のMathematical special functionsに球面調和関数が入ってるのね・・・
昨今のPRT人気の影響なんだろうか

123:デフォルトの名無しさん
06/07/17 09:20:31
>>121
追加削除あるところはだいたい文字色変えてあるのね。わかりやすくていい。

そこだけざっと見たところ、C99互換以外では、static_assert が増えてるのと、
コンテナやイテレータにちょこっとメンバが増えてるのくらいだな。

124:デフォルトの名無しさん
06/07/17 11:47:30
>>121
ドラフトで800ページオーバーかよ・・・・orz

125:デフォルトの名無しさん
06/07/17 12:52:37
Conceptおもしろいのう…

Generic Programming in ConceptC++
URLﾘﾝｸ(www.generic-programming.org)

126:デフォルトの名無しさん
06/07/19 18:16:54
予約語 where がなにか違和感
この調子で5W1Hの予約語が追加されたらｵﾓﾛ

127:デフォルトの名無しさん
06/07/19 18:57:33
この調子では来世紀にはすべての英単語が予約語になってしまうのではないか...

128:デフォルトの名無しさん
06/07/19 21:58:13
今のところ私は来世紀までには死ぬ予定になっているからへっちゃらです

129:デフォルトの名無しさん
06/07/19 22:00:17
英単語はどんどん増えるから大丈夫です。
フランス語だとあぶないかもですが。

130:デフォルトの名無しさん
06/07/20 11:12:13
問題は既存の汎用英単語を新しく作る事だ。

131:デフォルトの名無しさん
06/07/20 12:22:07
文脈依存のキーワードになるから無問題

132:デフォルトの名無しさん
06/07/20 12:29:00
既存のものを新しく作るのはかなり難しいだろうな

133:デフォルトの名無しさん
06/07/20 13:55:34
132だけ読むと、所謂パクリにも技術が要るという風にも読み取れるな。

すみません、関係ないです。はい。

134:デフォルトの名無しさん
06/07/20 18:37:25
活用や接頭接尾語まで予約されたら悪夢

ってどんどん無関係な話題になってないか？

135:デフォルトの名無しさん
06/07/20 21:33:30
じゃぁ、「もしこの英単語がC++の予約語になったら」でいってみようか。

136:デフォルトの名無しさん
06/07/20 22:04:17
hage

137:デフォルトの名無しさん
06/07/20 22:10:03
a, i, j, k, m, n, p, q, r, s, t, u, v, w, x, y

138:C++/CLI
06/07/21 01:17:11
spaced keyword(藁

139:デフォルトの名無しさん
06/07/21 02:08:14
fp, argc, argv

140:デフォルトの名無しさん
06/07/21 02:26:37

C++0x

魚の骨かと

141:デフォルトの名無しさん
06/07/21 05:39:13
Boostてどんな物なん？

142:デフォルトの名無しさん
06/07/21 11:07:18
おまえにこのスレは早すぎる

143:デフォルトの名無しさん
06/07/22 18:56:00
>>135
URLﾘﾝｸ(www.linkage-club.co.jp)

144:デフォルトの名無しさん
06/08/12 12:18:33
コンセプトとやらにテンポラリオブジェクトも含めて欲しい。
戻り値最適化が解決できるし。
STLコンテナやstringと相性いいと思うんだけどな。

T operator+(const T& lhs, const T& rhs)
T& operator+(temporary T& lhs, const T& rhs)
T& operator=(const T& t)
T& operator=(temporary T& t)

145:デフォルトの名無しさん
06/08/12 18:44:53
右辺値参照と違うの？

146:デフォルトの名無しさん
06/08/12 18:50:21
>>144
move　semanticsがC++に導入されるのを期待しよう。

147:デフォルトの名無しさん
06/08/12 23:04:01
うわー、まったくもってそのものな仕様だなこれ。恥ずかし。
でも例えばこう書ければなぁ、と思ってたんだけど
move semanticsの仕様でも多分できるよね。

string&& operator+(string&& lhs, const string& rhs) {
return lhs += rhs;
}

boost::arrayあたりはこう書けないと困るのだけど。

148:デフォルトの名無しさん
06/08/12 23:42:19
と、思ったけどexpression templateとmove semanticsを組み合わせれば
いらないか・・

149:デフォルトの名無しさん
06/08/13 01:48:17
お前らそーいうネタはどこで勉強してるのですか。

150:デフォルトの名無しさん
06/08/13 07:49:40
URLﾘﾝｸ(www.open-std.org)

151:デフォルトの名無しさん
06/09/07 04:19:13
tr1::regexって、もっとも多機能なsyntax_option_typeでも
ECMAScript相当なんだな。
うーん、今時look-behindがないってのは見劣りするなあ。

152:デフォルトの名無しさん
06/09/07 14:25:14
boostにTR1が実装されたみたいだけど、使ってみようかな

153:デフォルトの名無しさん
06/09/07 15:22:21
>>3を見るまでautoの存在を忘れていた

154:デフォルトの名無しさん
06/09/07 16:44:13
C++0xの0xが16進プレフィクスではなく
2010年までには出すぞ、という願望の現われだと今日知った。

早く使いたいな。

155:デフォルトの名無しさん
06/09/07 17:52:59
対応コンパイラが出るのは5年後です

156:デフォルトの名無しさん
06/09/07 21:27:24
C++0xが世に出るのは2109年だよ。
ドラえもんはそれで書かれてる。

157:デフォルトの名無しさん
06/09/07 23:56:45
C++0xの実装は跳ばされる

158:デフォルトの名無しさん
06/09/08 09:56:08
そんなことはないと言いたいところだけど、
exportの例があるからな…

159:デフォルトの名無しさん
06/09/08 12:25:16
あれはどちらかというと、実装の手間を考えずに策定した側に
問題あるような。

160:デフォルトの名無しさん
06/09/09 00:22:06
実際問題、実装しろとか言われたら嫌な汗出てくるもんな。
C++全体に渡ってそんな感じではあるが。

161:デフォルトの名無しさん
06/09/09 02:41:12
こんなこといいな、できたらいいなと何でもかんでも詰め込んだまではよかったが
不思議なポッケでかなえてくれるドラえもんはいないという点にまで気が回らなかったと

162:デフォルトの名無しさん
06/09/09 03:24:51
exportは一応EDGが3人年かけてかなえてくれたけどな
誰も近寄らなくなったけどw

163:デフォルトの名無しさん
06/09/09 04:32:41
C++は夢いっぱい

164:デフォルトの名無しさん
06/09/09 09:46:54
VC2005で、リンク時のコード生成を行ってるけど、exportじゃ無いのかな？

165:デフォルトの名無しさん
06/09/09 12:19:22
>>164
それは最適化。
たとえば、リンク時にインライン展開するとか。

166:デフォルトの名無しさん
06/09/09 13:39:37
exportが駄目でした、なんてのはどうでもいいが
コンパイルは出来るのにそれがC++言語として
正しいかどうか調べ回らないといけないのがつらい
ガベージコレクタの*ない*Javaがモダンな言語とは全く思わないが
write once, compile anywhereなのはうらやましい

167:デフォルトの名無しさん
06/09/09 13:45:23
実際、Javaはwrite once、compile once、run anywhereだもんな。
失うものも多いが、楽なのは確かだ。

168:デフォルトの名無しさん
06/09/09 13:48:10
拡張機能を切ってコンパイルすれば、そこそこ正しくはなる。
ただ、それでも他のコンパイラでコンパイルすると
不完全だと分かる事もよくある話。
難しいもんですな。

169:デフォルトの名無しさん
06/09/09 14:54:45
>167
debug anywhere だけどな

170:デフォルトの名無しさん
06/09/09 18:08:44
Write Once, Run Anywhere, Debug Everywhere!

171:デフォルトの名無しさん
06/09/09 20:42:30
やっぱり、#ifdef は要るよ

172:デフォルトの名無しさん
06/09/09 23:32:00
そんなあなたにBoost MPL。

173:デフォルトの名無しさん
06/09/11 06:00:00
Debug Everyday!

174:デフォルトの名無しさん
06/09/11 21:11:16
char を UTF-8、wchar_t を UTF-16 として認識する標準ライブラリおよび
コンパイルオプションが欲しい。

175:デフォルトの名無しさん
06/09/11 21:55:25
>>174
そういうlocale（特にcodecvt）を作ればいいという話ではないのか？

176:デフォルトの名無しさん
06/09/11 22:11:50
STLのlocale周りは、はっきり言って無駄だから、
さっくり削除してほしいと思っているのは自分だけ？

177:デフォルトの名無しさん
06/09/11 22:13:38
実装の話？仕様の話？

178:デフォルトの名無しさん
06/09/11 22:16:05
>>174
> char を UTF-8

どういうこと?
charというか、mbsのこと?

179:デフォルトの名無しさん
06/09/11 22:17:32
>>174
> wchar_t を UTF-16 として

どういうこと?
UTF-16じゃなくて、UCS-4でなく?

180:デフォルトの名無しさん
06/09/11 22:18:43
>>176
君みたいな人は少ないと思う。

181:デフォルトの名無しさん
06/09/12 01:02:06
サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか
邪魔にされる日が来るのかね。
1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。

182:デフォルトの名無しさん
06/09/12 01:24:19
しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、
欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
実際のところどうなのかは知らないが。

ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。

183:デフォルトの名無しさん
06/09/12 02:34:51
URLﾘﾝｸ(www.open-std.org)
> News 2006-09-11: The 2006-09 mailing is available (4700 kb tar.gz, .zip 4700 kb) individual papers
> News 2006-09-11: The C++ Standard Library Issues List (Revision 44) is available (.tar.gz)
> News 2006-09-11: C++ Standard Core Language Issues List (Revision 43) is available, also committee version

184:デフォルトの名無しさん
06/09/12 13:22:39
>>183
(ﾟ∀ﾟ)ktkr
待ってたぜ。これで仕事中こっそり楽し(ry

185:デフォルトの名無しさん
06/09/13 05:22:20
>>182
> 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
だからこそUTF-8でしょ
> ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
日本人の都合なんか知ったこっちゃないし

186:デフォルトの名無しさん
06/09/13 06:41:57
ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。

187:デフォルトの名無しさん
06/09/13 08:27:03
だからさ、char 型なんて廃止して、byte 型にしてほしいぜ
別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが

188:デフォルトの名無しさん
06/09/13 09:48:52
charが実装依存ですが?
basic_stringテンプレート知らない人ですか、ああそうですか

189:デフォルトの名無しさん
06/09/13 12:24:08
日本語も読めないのに皮肉を言おうとするとこうなる。

190:デフォルトの名無しさん
06/09/13 12:54:37
uint8_tで何が不満なんだ? > byte_t

191:デフォルトの名無しさん
06/09/13 18:51:23
8bitとは限らないから…とか？

192:デフォルトの名無しさん
06/09/13 21:24:18
uint8_t i = 32;
std::cout << i;

とやって、32じゃなくて、空白が出力されたるの嫌やん

193:デフォルトの名無しさん
06/09/13 21:26:02
1byteを表すchar
文字を表すchar
双方を別々に定義すべきだという主張かと

194:デフォルトの名無しさん
06/09/13 21:38:12
C++ でせっかく char と signed char と unsigned char に分かれたのに、
なんで cout << で全部文字になっちまうんだ？

195:デフォルトの名無しさん
06/09/13 21:54:36
実際問題、符号ないほうが都合がいいから
文字としてuchar使ってるケースあるし、その辺との兼ね合いでね？

196:デフォルトの名無しさん
06/09/14 08:34:29
>193
そう。バイト単位のデータを表す型と文字を表す型が同一であることが、本気で文字列を
なんとかしようという意志の無さの表れではないかと
実体が wchar_t であろうと char であろうと、１文字を１文字として扱えるなら関心はないよね
文字列の仕様なんてたぶんこの先もふらふらするんだから、ある程度距離を取っておいた
方がいいと思うんだな
string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい

197:デフォルトの名無しさん
06/09/14 08:52:47
>>196
文字列(というか文字)を何とかした結果が今の形 char だと思う。

>string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
ができる柔軟性も、char, wchar_tのおかげと思えば・・

198:デフォルトの名無しさん
06/09/14 22:37:48
char は C との互換性のために残しておく程度でいい
std::string と std::wstring 間にろくな互換性無いだろ？
これを柔軟性というのか？

199:デフォルトの名無しさん
06/09/14 23:06:50
>>198 そういう意味だったのか。

200:デフォルトの名無しさん
06/09/15 00:54:03
>>198
互換性って例えばどういうこと?

201:デフォルトの名無しさん
06/09/15 01:44:55
>>200 もう血が止まってるんだから、変にいじったりしないの！

202:デフォルトの名無しさん
06/09/15 09:11:21
おねがいします。

自分のファイル名(x.exe)を読み込んで
xの部分がAすなわちA.exeだったらaを実行して
xの部分がBすなわちB.exeだったらbを実行する
っていうようなCのプログラムを教えてください。

203:デフォルトの名無しさん
06/09/15 09:26:00
なんでまた C++0x スレに？
もしかしてマルチ？

204:デフォルトの名無しさん
06/09/15 09:34:41
マルチだね
どこだか忘れたが別スレで見た

>202
あっちのスレに答えが書いてあったぞ

205:デフォルトの名無しさん
06/09/17 00:49:06
C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？

たぶんそんなことはないだろうが

206:デフォルトの名無しさん
06/09/17 11:10:37
おじいさんは、裏山に畑を耕しに行ったんじゃない？

たぶんそんなことはないだろうが

207:デフォルトの名無しさん
06/09/17 15:01:57
いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。

208:デフォルトの名無しさん
06/09/17 20:43:56
>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。

209:デフォルトの名無しさん
06/09/17 23:24:34
書かれたものがキチガイだと
本当に誰にも通じないけどな。

210:デフォルトの名無しさん
06/11/24 14:31:34
N2133 06-0203
Editor's ReportPete Becker
2006-11-03
URLﾘﾝｸ(www.open-std.org)

N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
URLﾘﾝｸ(www.open-std.org)
新規色分け版

N2135 06-0205
Programming Languages －C++ Pete Becker
2006-11-06 N2134=06-0204
URLﾘﾝｸ(www.open-std.org)
色分けなし版

211:デフォルトの名無しさん
06/11/24 18:16:23
ちなみにADLのところ、3.4.2のルールが書き変わっています。

stringとchar_traitsのところも結構。
"文字"じゃなくてPODなら入れられる。

212:デフォルトの名無しさん
06/11/24 18:56:53
色の違いだったのね

213:デフォルトの名無しさん
06/11/24 22:19:20
論文リスト、ちらほら C++09 という記述が出始めたな

214:デフォルトの名無しさん
06/11/24 22:21:19
2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。

215:デフォルトの名無しさん
06/11/28 23:58:39
Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。

216:デフォルトの名無しさん
06/11/29 01:24:10
一番ほしいのはTemplate aliasesかな

217:デフォルトの名無しさん
06/11/29 01:31:43
>215
標準ライブラリに対する rvalue reference の導入は
下位互換を完全に意識した設計が提案されているので
＞STLも仕様決め直しだし、
という見方は少し違うような気がします．
std::auto_ptr などは deprecated なだけで廃止されるわけでもないですし．

というよりか，現在の標準ライブラリにおける rvalue reference 対応の提案は，
(いつものことですが) 下位互換の維持のために非常に設計が汚い印象があります．
move に対応していない場合 copy に fallback する設計は，
たとえば例外送出時のときなどの仕様と動作が極めて煩雑になるのではないか，
など個人的には不満も多いです．
(この汚さは標準ライブラリにおける rvalue reference 対応がもたらす汚さで，
言語仕様として導入される rvalue reference の仕様とは独立です)

言語仕様としての rvalue reference は， move semantics の導入と同時に，
the forwarding problem と呼ばれる非常に重要な問題を同時解決しますし，
(この問題の解決も見た目に比してインパクトが極めて大きいと思います)
『便利』程度の恩恵ではなく『マニア向け』の機能でもないと思います．

今現在，そもそも rvalue reference / move semantics 自体が机上の空論ですから，
これについて今何を語っても "almost as much of a hoax as Artificial Intelligence"
でしかないですが，それを承知であえて， rvalue reference / move semantics は
OOP・汎用プログラミング・関数プログラミング・効率・リソース管理・例外安全性
スレッド安全性など，ほぼあらゆるプログラミングパラダイム・概念の全域，
あと特にこれらの概念が交錯する領域での貢献が極めて大きい，
C++0x における (C++98 以来) 最大の進化だと主張したいです．

218:デフォルトの名無しさん
06/11/29 01:42:23
とマニアが言っております

219:デフォルトの名無しさん
06/11/29 01:48:06
いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。

220:デフォルトの名無しさん
06/11/29 12:59:00
>>219
明暗！

221:デフォルトの名無しさん
06/11/29 16:09:12
言い得て妙な変換だなｗ

222:デフォルトの名無しさん
06/11/29 17:42:23
namespace　std0x
{
　　using　namespace　std;
}

223:デフォルトの名無しさん
06/11/30 08:53:29
namespace std0x = std;

224:デフォルトの名無しさん
06/11/30 13:36:58
もうここはあれだ、Andrei Alexandrescu あたりに超変態的 template
テストケース書いてもらってさ、これにパスしないと C++0x 準拠とは
名乗らせないってのはどうよ。
もうさ、これまでみたいなコンパイラ毎の ifdef 分岐の嵐はさすがにもう
勘弁して暮れって感じ

225:デフォルトの名無しさん
06/11/30 13:50:21
>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。

226:デフォルトの名無しさん
06/11/30 14:41:25
>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ

227:デフォルトの名無しさん
06/11/30 16:22:54
BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい

228:デフォルトの名無しさん
06/11/30 16:52:46
"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…

229:デフォルトの名無しさん
06/11/30 20:58:15
>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。

230:デフォルトの名無しさん
06/11/30 23:42:40
>>217
Cryoliteたん？

231:デフォルトの名無しさん
06/12/05 21:36:18
>>215です。

>>217さんのおっしゃることには技術的に白黒の付く部分については同意です。
けど、やっぱりそうなるとC++はどんどんマイナー言語になっていくと思います。
じゃあ拡張しなければいいのかというとそういうわけでもないんですが…
C++の前に萌えた言語(システム)がCLOSである私としては切ない気持ちです。> マイナー化

232:デフォルトの名無しさん
06/12/05 22:07:30
rvalue referenceってなんなのさ？

233:デフォルトの名無しさん
06/12/05 22:37:14
ここで。

A Brief Introduction to Rvalue References
URLﾘﾝｸ(www.open-std.org)

234:デフォルトの名無しさん
06/12/05 22:49:58
>>233
よく纏まっていてわかりやすいね。

235:デフォルトの名無しさん
06/12/06 09:50:22
auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう

236:デフォルトの名無しさん
06/12/06 12:13:53
>>235
一度、標準に採用されたらベンダーの独自拡張じゃないから安心して使ってねっていう
意味を暗に含むから非推奨にはなっても廃止はまずありえんだろうな。

237:デフォルトの名無しさん
06/12/07 04:52:50
ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。

ストラスストラップのハゲの残り少ない髪の毛引き抜いて
クローンハゲを量産して、規格の策定に充てるとかすればいいんじゃないのかと思った。

238:デフォルトの名無しさん
06/12/08 18:26:39
その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし

239:デフォルトの名無しさん
06/12/09 01:08:57
ここで>>217に戻る。

240:デフォルトの名無しさん
06/12/09 01:15:54
まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし

241:デフォルトの名無しさん
06/12/09 05:11:42
>パフォーマンスゲインも5倍

なにその機動戦士ガンダム

242:デフォルトの名無しさん
06/12/09 09:13:34
こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。

243:デフォルトの名無しさん
06/12/09 12:42:51
コンパイル時間も5倍に…

244:デフォルトの名無しさん
06/12/09 12:56:47
>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ

245:デフォルトの名無しさん
06/12/09 16:56:31
父さん、言語拡張症にかかって…

246:デフォルトの名無しさん
06/12/09 22:35:18
これからは言語のモジュール化ですよ。

247:デフォルトの名無しさん
06/12/10 07:07:20
>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？

248:デフォルトの名無しさん
06/12/10 08:50:22
>>247
お前マジ天才じゃね？

249:デフォルトの名無しさん
06/12/10 10:16:27
最終的には今日コンパイルすると昨日完了するようになる

250:デフォルトの名無しさん
06/12/10 10:20:32
そのコンパイラでコンパイラをコンパイルさせてください。

251:デフォルトの名無しさん
06/12/10 10:53:35
おまいらホント暇だなｗ

252:デフォルトの名無しさん
06/12/10 17:55:34
最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？

253:デフォルトの名無しさん
06/12/10 19:57:26
ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか

254:デフォルトの名無しさん
06/12/10 20:04:18
autoはC++09に確実に入るんじゃないのかな?

255:デフォルトの名無しさん
06/12/10 20:17:08
標準委員会、キーワード追加症にかかって…

256:デフォルトの名無しさん
06/12/10 20:22:14
>>254 それはずっと前からキーワード。

257:デフォルトの名無しさん
06/12/10 20:56:19
意味が変更される予約語はautoだけかな

258:デフォルトの名無しさん
06/12/14 13:27:42
しかしautoはどうかと思う…
型の弱い言語みたいだ

259:デフォルトの名無しさん
06/12/14 13:32:51
初期化される時点で型が決まってしまうのに、どこが弱いんだか。

次ページ