C++0x

1 ：デフォルトの名無しさん：2006/06/05(月) 02:04:07

どんな感じになるの？

2 ：デフォルトの名無しさん：2006/06/05(月) 02:08:28

3 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/05(月) 02:12:31

今まで出来なかったのが不思議

5 ：デフォルトの名無しさん：2006/06/05(月) 02:13:23

本当にあと2年半以内に出るのか？

6 ：デフォルトの名無しさん：2006/06/05(月) 02:14:26

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

7 ：デフォルトの名無しさん：2006/06/05(月) 02:15:11

>>5は算数を勉強しなおしたほうがいいと思う

8 ：デフォルトの名無しさん：2006/06/05(月) 02:15:27

コンパイル速度が速くなると良いな。Pascal 並みとは言わんけど、常識的な速度で plz.

9 ：デフォルトの名無しさん：2006/06/05(月) 02:17:19

またいろいろ肥大化するんだろうなあ。
こうしてC++は巨大言語の地位を不動のものとするのでありました。

10 ：デフォルトの名無しさん：2006/06/05(月) 04:25:24

標準化に関わってるメンバはインテルから金貰ってる。

11 ：デフォルトの名無しさん：2006/06/05(月) 12:08:10

さっさと右辺値参照と perfect forwarding よこしやがれこんちくしょー！！

12 ：デフォルトの名無しさん：2006/06/05(月) 14:18:42

2010年になってもまだ制定されてなかったら
0xは16進数のprefixだっていうことにならんかな

13 ：デフォルトの名無しさん：2006/06/05(月) 16:49:10

>>3
後者のfindは今のboost.range_ex相当だと思っていいんだよな？

14 ：デフォルトの名無しさん：2006/06/05(月) 17:38:27

>>11
C++ってもうプログラミング言語の実験室だな。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
を見ていると欲しい機能が満載w

15 ：デフォルトの名無しさん：2006/06/05(月) 18:58:15

javaみたいに継承禁止を指定できるようになる？

16 ：デフォルトの名無しさん：2006/06/05(月) 20:43:59

>>3
Boostでほぼ実現されているところが怖いな

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

17 ：デフォルトの名無しさん：2006/06/05(月) 21:55:44

std::tr1を実装しているところてあるのかな

18 ：デフォルトの名無しさん：2006/06/05(月) 21:56:24

>vector<int> v = { 1, 2, 3 };
これCとの互換性なくならない？
配列のサイズどうする気なの？

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

http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespacestd_1_1tr1.html

20 ：デフォルトの名無しさん：2006/06/05(月) 22:03:35

>>18
> これCとの互換性なくならない？

どうなくなるの?

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

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

21 ：デフォルトの名無しさん：2006/06/07(水) 17:16:02

もしもBoost.LambdaがそのままC++に取り込まれたら世も末だな。

22 ：デフォルトの名無しさん：2006/06/07(水) 21:18:51

手続き、構造化、OOP、ジェネリック、さらに関数型の記述も混在できる！！

…確かに末だな。

23 ：デフォルトの名無しさん：2006/06/07(水) 21:23:41

え～，それが面白いんじゃんかー．ぶーぶーぶー

24 ：デフォルトの名無しさん：2006/06/07(水) 22:53:24

lambda記法は、新しい構文で提案されてますよ。

Lambda expressions and closures for C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

25 ：21：2006/06/07(水) 23:07:50

>>24
勿論それは知っている。
だからこそ21を書いた。

26 ：デフォルトの名無しさん：2006/06/08(木) 09:24:36

Boostのlambdaなんて繋ぎですよ

27 ：デフォルトの名無しさん：2006/06/08(木) 18:50:12

io,stream,国際化関係
を分かりやすくかつ高パフォーマンスにして欲しい。
今のは使いにくい。

28 ：デフォルトの名無しさん：2006/06/08(木) 20:33:34

名前がかっこいいから策定されても仕様名はC++0xのままにしてほしい

29 ：デフォルトの名無しさん：2006/06/08(木) 20:54:05

勧告された暁にはちゃんと年月にちなんでC++0xFFと呼ばれます。

30 ：デフォルトの名無しさん：2006/06/10(土) 07:30:18

せめて標準ライブラリの部分だけでも、5年に一度ぐらいの割合で
改訂してくれんかな。

31 ：デフォルトの名無しさん：2006/06/10(土) 10:36:15

一応そのくらいでやるつもりなんでしょ。

32 ：デフォルトの名無しさん：2006/06/11(日) 11:33:06

二進数表記ができるようになってほしい。

33 ：デフォルトの名無しさん：2006/06/11(日) 11:47:29

>>32
2進←→16進なんて簡単に脳内で変換できるんだから要らなくね？

34 ：デフォルトの名無しさん：2006/06/11(日) 12:02:14

>>32
10bitまでならherumiさんのtemplateで出来るぞ。

35 ：デフォルトの名無しさん：2006/06/11(日) 12:08:43

>>33
ソース中に記述できることには別の意義がある。

36 ：デフォルトの名無しさん：2006/06/11(日) 12:19:32

>>35
例えば？

37 ：デフォルトの名無しさん：2006/06/11(日) 12:24:39

プレフィクスつけて指定する形を取ってるからなあ…
0 → 8進
0x → 16進
じゃあ2進は？

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

38 ：デフォルトの名無しさん：2006/06/11(日) 12:31:38

D言語とかでは0bをプレフィックスにしてたな。
ただ、2進表記は微妙と個人的には思う。

0b10101010101010101010101010101010
0x55555555

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

39 ：デフォルトの名無しさん：2006/06/11(日) 12:37:17

仕様が２進表記を使っている場合に
ソース上で１６進表記になっていると、
仕様を変更するときには変換しないといけないだろ？
ソース中に２進表記ができればコピペで済む所が
脳内変換を必要とするわけよ。これはよくない。

40 ：デフォルトの名無しさん：2006/06/11(日) 12:39:05

2進 <-> 16進で脳内変換できないようなカスは別の言語をどうぞ

41 ：デフォルトの名無しさん：2006/06/11(日) 13:10:33

ぶっちゃけ2進数表記は長くなる傾向が多くて使い辛い。
短い表記ならtemplateでも対処できるわけだし。

42 ：デフォルトの名無しさん：2006/06/11(日) 13:29:32

2進と16審の脳内変換・・・って・・・
手間はコピペするのと大差無いだろ。何が問題なのかわからん。

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

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

43 ：デフォルトの名無しさん：2006/06/11(日) 13:37:19

２進データ１０００個のテーブルでも
コピペと脳内変換で大差ないと思うの？
少なくとも俺は面倒で嫌だな。
２進と１６進の変換は普通にできるけどね。

44 ：デフォルトの名無しさん：2006/06/11(日) 13:48:08

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

45 ：デフォルトの名無しさん：2006/06/11(日) 13:54:55

>>44
> 16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
十分メンドクセェよ。仕事頼める人が限られるのもウザイ。

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

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

46 ：デフォルトの名無しさん：2006/06/11(日) 14:02:00

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

47 ：デフォルトの名無しさん：2006/06/11(日) 14:08:15

えぇー。1バイトが8ビットじゃないマシンって話にしか聞いたことないけど、まだあるの？

48 ：デフォルトの名無しさん：2006/06/11(日) 14:09:37

>>46
そんな問題は１６進でも同じじゃないか？

49 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/11(日) 14:14:59

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

51 ：デフォルトの名無しさん：2006/06/11(日) 14:16:09

>>49
はいはい。スゲェスゲェ。

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

52 ：デフォルトの名無しさん：2006/06/11(日) 14:17:54

10進数だけでいいじゃん

53 ：デフォルトの名無しさん：2006/06/11(日) 14:19:25

>>50
エンディアンはメモリなどのバイト列を考えたときの
バイトオーダーの話だから、数値の表現形式自体とは関係ないよ。
0x10 が 16 と定まるように、 0x10 は 0b10000 と定まる。

54 ：デフォルトの名無しさん：2006/06/11(日) 14:23:01

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

55 ：デフォルトの名無しさん：2006/06/11(日) 14:23:12

bitmapなんかをソースに埋め込みたいときに使えると便利だな

56 ：デフォルトの名無しさん：2006/06/11(日) 14:25:41

D&Eぐらい嫁。
C++標準委員会は既にバイナリリテラルへの対応を予備審査で却下してるんだから
これから実装されることはまずあり得ない。

57 ：デフォルトの名無しさん：2006/06/11(日) 14:25:58

>>54
質問には答えてほしかったんだが、まぁいい。
どうせ現実世界には影響の無い与太話だ。

58 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/11(日) 15:11:00

個人的にはビットパターンを図示しやすくなるからバイナリリテラルはあってもいいと思う。
で、やるからには8or4ビットごとにセパレータを入れられればもっといい。
Ex. 0xdead → 0b1101_1110_1010_1101

60 ：デフォルトの名無しさん：2006/06/11(日) 15:51:52

http://www.illegal-immigration.com/Riv/boost/binary_literal.hpp
これか。いつ追加されるのだ
まーこんなのよく考えるもんだ

61 ：・∀・）っ-○◎● ◆toBASh.... ：2006/06/11(日) 18:00:21

_0b00000000～_0b11111111までとか定数定義して、あと16bitとか32bitとかマクロで連結する
ってことやってる会社は知ってる

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

全部マクロでやってるヘッダならboostで見た気がする

63 ：デフォルトの名無しさん：2006/06/11(日) 18:05:25

CでGUIアプリってつくれるの？
javaしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるCとか、かんたんできるCとか
いろいろ本でてますけどCUIだよな。
どうしたらCでGUIアプリ作れるの？

64 ：デフォルトの名無しさん：2006/06/11(日) 18:08:20

スレ違いも甚だしい

65 ：デフォルトの名無しさん：2006/06/11(日) 18:10:25

Javaでネイティブアプリってつくれるの？
Cしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるJavaとか、かんたんできるJavaとか
いろいろ本でてますけどVMだよな。
どうしたらJavaでネイティブアプリ作れるの？

66 ：デフォルトの名無しさん：2006/06/11(日) 18:22:05

GCJ

67 ：デフォルトの名無しさん：2006/06/11(日) 20:15:11

>>58
五年ごとって決まっているのは一部でしょ。
たとえばFORTRAN。

68 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/12(月) 23:31:13

>>68 assert(binary<0101>::value == 5);

70 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/12(月) 23:58:14

馬鹿には>>60が見えないのか？
templateはboostに却下された

72 ：デフォルトの名無しさん：2006/06/13(火) 00:03:22

Boostに入らなければ個人的に作って使えばよいだけ。

73 ：デフォルトの名無しさん：2006/06/13(火) 01:11:05

実用性ゼロの趣味テンプレート

74 ：デフォルトの名無しさん：2006/06/20(火) 19:53:27

保守

75 ：デフォルトの名無しさん：2006/06/24(土) 01:13:05

TR1の本ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

http://www.amazon.com/gp/product/0321412990/
http://www.aw-bc.com/catalog/academic/product/0,1144,0321412990,00.html

Pete Beckerﾊｧﾊｧ
http://www.petebecker.com/

76 ：デフォルトの名無しさん：2006/06/24(土) 01:37:47

>>75
本を出す意義がわからん。
↓のドラフトや boost の実装、ドキュメントで十分だろ。
http://www.open-std.org/jtc1/sc22/wg21/

77 ：デフォルトの名無しさん：2006/06/24(土) 02:37:21

EffectiveSTLのTR1に合わせた改訂予定はあるのかな

78 ：デフォルトの名無しさん：2006/06/24(土) 05:35:16

ライブラリもいいけど、早いとこ concept や rvalue reference
決めねえと間に合わなくなると思うんだがな。こいつら入ったら
ライブラリ大幅に書き直しじゃん？

79 ：デフォルトの名無しさん：2006/06/24(土) 09:49:39

>>75
Peteが出すんだから、出す意味のある内容なんじゃないのかね。
>>78
0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。
C++って本当、永遠に仕様が確定しそうにないよな。

80 ：デフォルトの名無しさん：2006/06/24(土) 13:02:27

C++は完璧ではないし、完璧になることはあり得ない。常に進化し続ける。
とは禿の言葉だっけか

81 ：デフォルトの名無しさん：2006/06/24(土) 14:31:54

常に進化し続けるのはいいが仕様が確定しないと処理系が出てこないわけで。

82 ：export：2006/06/24(土) 14:55:05

すみません。
私を知っている人はいますか？

83 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/06/24(土) 15:14:38

仕様があるのにどの処理系でも未だサポートされないキーワードの典型ですな

84 ：デフォルトの名無しさん：2006/06/24(土) 15:42:03

name lookup ruleも永遠に定まらないだろうな。

85 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/06/24(土) 15:46:48

ガベコレでも標準ライブラリに入れて欲しいと思うの俺だけ？

86 ：デフォルトの名無しさん：2006/06/24(土) 16:53:21

ガベコレが必要なのはCだろう...
shared_ptrは再帰デストラクタ失敗するのが弱点だよな。

87 ：デフォルトの名無しさん：2006/06/24(土) 17:23:13

>>86
> shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
なんのこと？

88 ：デフォルトの名無しさん：2006/06/24(土) 17:30:52

循環参照のことでは？

89 ：デフォルトの名無しさん：2006/06/24(土) 18:50:37

>>82
concept の導入によりテンプレートの定義と実装を分けることが
可能になれば、あるいは再デビューできるかも試練よ

90 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/24(土) 20:46:20

200C年くらいに出れば御の字だよね

92 ：デフォルトの名無しさん：2006/06/24(土) 21:04:49

>>91
6198年後かよ

93 ：デフォルトの名無しさん：2006/06/24(土) 23:26:48

>>83
でも予約だけはされてんのな。

94 ：デフォルトの名無しさん：2006/06/25(日) 16:38:34

予約じゃないですよ。
既に規格の一部です。

95 ：デフォルトの名無しさん：2006/06/26(月) 08:09:14

予約だし、規格の一部だよ。

96 ：デフォルトの名無しさん：2006/06/29(木) 22:23:00

そういやどうして「予約語」っていうんだろう

97 ：デフォルトの名無しさん：2006/06/29(木) 23:45:12

>>96
字句は識別子としての要件を満たしているから。
だけど文法上特別な意味を持たすために、
識別子として使えないようコンパイラがその字句を「予約」している。

98 ：デフォルトの名無しさん：2006/06/30(金) 00:10:26

まあ「予約」語は誤訳みたいなもんで、(特に「予」め)
除外語がreserved workの訳には適当。

99 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/06/30(金) 09:43:52

>98
「除外」のほうが違和感がある

101 ：デフォルトの名無しさん：2006/06/30(金) 12:53:14

「お客様、そこは除外席ですので、他の席をお使い下さい」

102 ：デフォルトの名無しさん：2006/06/30(金) 13:51:26

>>98
中学校からやり直せ。

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

103 ：デフォルトの名無しさん：2006/06/30(金) 18:43:40

>>99
ヘタにガリガリ書くコーディングが減っていいんじゃないか？

104 ：デフォルトの名無しさん：2006/07/10(月) 12:59:49

　int operator*(int x) { return x; }
はやりすぎと思うが。

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

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2051.htm

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 ：デフォルトの名無しさん：2006/07/10(月) 20:46:42

>>104
Thread単体でサポートしてもなぁ。
ACE見たく非同期関連のフレームワークと一緒でないとあんまり役に
たたない様な気がするけど。
(boost.)lexical_castはspiritがあるのでちっとも使わん。

106 ：デフォルトの名無しさん：2006/07/11(火) 03:12:35

>* typesafe 'any' class
　Boostにある、あれをそのまま盛り込むのだろうか。

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

107 ：デフォルトの名無しさん：2006/07/11(火) 06:56:10

基本的には同じ
Any Library Proposal for TR2
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1939.html

かなり強力
Proposal for an Infinite Precision Integer for Library Technical Report 2, Revision 1
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2020.pdf

108 ：デフォルトの名無しさん：2006/07/12(水) 22:26:27

>>105
でもC++に標準でスレッドサポートされる、というのは大きいんじゃまいか。
もしかしたら将来のCでもサポートされるかもしれんし。

109 ：デフォルトの名無しさん：2006/07/12(水) 22:42:35

tr2でXMLとかネットワークとかマジですか

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

110 ：デフォルトの名無しさん：2006/07/12(水) 23:06:20

この調子で行けばC++ 2xにはGUI関連が標準ライブラリに入るに違いない。

111 ：デフォルトの名無しさん：2006/07/12(水) 23:28:26

Boostで便利なのが軒並み入ってるな。
それ以外の勢力は元気なくてさみしい。

112 ：デフォルトの名無しさん：2006/07/14(金) 02:28:31

C++0xに対応したMSのコンパイラはいつ出るんだろ。
規格が決まってから、実装するまで何年ぐらいかかるのかな。

113 ：デフォルトの名無しさん：2006/07/14(金) 03:00:55

過去の例から考えると１０年くらいか orz

114 ：デフォルトの名無しさん：2006/07/14(金) 13:30:29

boost 1.34 には tr1が入るみたいだから、
boostからtr1が使っている部分だけ抜き出してそれをVC++用に使うようにすればいい
といってみるテスト

115 ：デフォルトの名無しさん：2006/07/14(金) 16:02:33

そういえば、いまさらで馬鹿にされる質問かもしれないけど、
新しいライブラリの名前空間はどうなるんだろう。
まさか　tr1　などというかっこ悪い名前空間のままだったりはしないよね。
でも、stdに押し込むと、既存のライブラリと衝突したりしないのかな

116 ：デフォルトの名無しさん：2006/07/14(金) 16:06:59

>>115
衝突しないようにstdに入れるんじゃまいか？

117 ：デフォルトの名無しさん：2006/07/16(日) 01:56:20

今はstd::tr1みたいだけど、最終的にはどうなるんだろね。

118 ：デフォルトの名無しさん：2006/07/16(日) 09:12:22

stdにいれるに決まってるじゃん。
けどJavaみたいに階層構造になっているのもいいよな。

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

119 ：デフォルトの名無しさん：2006/07/16(日) 10:13:57

階層化する前に、名前空間の記述の簡易化をはやく標準化して欲しいよ

120 ：デフォルトの名無しさん：2006/07/16(日) 10:46:32

namespace com { namespace example { namespace myproj { /* */ } } }
ってめんどくさいから、例えば
namespace com::example::myproj { /* */ }
とかね。

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

121 ：デフォルトの名無しさん：2006/07/16(日) 12:06:35

draft October 2005
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf

122 ：デフォルトの名無しさん：2006/07/16(日) 15:01:35

TR1のMathematical special functionsに球面調和関数が入ってるのね・・・
昨今のPRT人気の影響なんだろうか

123 ：デフォルトの名無しさん：2006/07/17(月) 09:20:31

>>121
追加削除あるところはだいたい文字色変えてあるのね。わかりやすくていい。

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

124 ：デフォルトの名無しさん：2006/07/17(月) 11:47:30

>>121
ドラフトで800ページオーバーかよ・・・・orz

125 ：デフォルトの名無しさん：2006/07/17(月) 12:52:37

Conceptおもしろいのう…

Generic Programming in ConceptC++
http://www.generic-programming.org/languages/conceptcpp/

126 ：デフォルトの名無しさん：2006/07/19(水) 18:16:54

予約語 where がなにか違和感
この調子で5W1Hの予約語が追加されたらｵﾓﾛ

127 ：デフォルトの名無しさん：2006/07/19(水) 18:57:33

この調子では来世紀にはすべての英単語が予約語になってしまうのではないか...

128 ：デフォルトの名無しさん：2006/07/19(水) 21:58:13

今のところ私は来世紀までには死ぬ予定になっているからへっちゃらです

129 ：デフォルトの名無しさん：2006/07/19(水) 22:00:17

英単語はどんどん増えるから大丈夫です。
フランス語だとあぶないかもですが。

130 ：デフォルトの名無しさん：2006/07/20(木) 11:12:13

問題は既存の汎用英単語を新しく作る事だ。

131 ：デフォルトの名無しさん：2006/07/20(木) 12:22:07

文脈依存のキーワードになるから無問題

132 ：デフォルトの名無しさん：2006/07/20(木) 12:29:00

既存のものを新しく作るのはかなり難しいだろうな

133 ：デフォルトの名無しさん：2006/07/20(木) 13:55:34

132だけ読むと、所謂パクリにも技術が要るという風にも読み取れるな。

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

134 ：デフォルトの名無しさん：2006/07/20(木) 18:37:25

活用や接頭接尾語まで予約されたら悪夢

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

135 ：デフォルトの名無しさん：2006/07/20(木) 21:33:30

じゃぁ、「もしこの英単語がC++の予約語になったら」でいってみようか。

136 ：デフォルトの名無しさん：2006/07/20(木) 22:04:17

hage

137 ：デフォルトの名無しさん：2006/07/20(木) 22:10:03

a, i, j, k, m, n, p, q, r, s, t, u, v, w, x, y

138 ：C++/CLI：2006/07/21(金) 01:17:11

spaced keyword(藁

139 ：デフォルトの名無しさん：2006/07/21(金) 02:08:14

fp, argc, argv

140 ：デフォルトの名無しさん：2006/07/21(金) 02:26:37

C++0x

魚の骨かと

141 ：デフォルトの名無しさん：2006/07/21(金) 05:39:13

Boostてどんな物なん？

142 ：デフォルトの名無しさん：2006/07/21(金) 11:07:18

おまえにこのスレは早すぎる

143 ：デフォルトの名無しさん：2006/07/22(土) 18:56:00

>>135
http://www.linkage-club.co.jp/ExamInfo&Data/BNC%20lemma%20Web.txt

144 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/08/12(土) 18:44:53

右辺値参照と違うの？

146 ：デフォルトの名無しさん：2006/08/12(土) 18:50:21

>>144
move semanticsがC++に導入されるのを期待しよう。

147 ：デフォルトの名無しさん：2006/08/12(土) 23:04:01

うわー、まったくもってそのものな仕様だなこれ。恥ずかし。
でも例えばこう書ければなぁ、と思ってたんだけど
move semanticsの仕様でも多分できるよね。

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

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

148 ：デフォルトの名無しさん：2006/08/12(土) 23:42:19

と、思ったけどexpression templateとmove semanticsを組み合わせれば
いらないか・・

149 ：デフォルトの名無しさん：2006/08/13(日) 01:48:17

お前らそーいうネタはどこで勉強してるのですか。

150 ：デフォルトの名無しさん：2006/08/13(日) 07:49:40

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

151 ：デフォルトの名無しさん：2006/09/07(木) 04:19:13

tr1::regexって、もっとも多機能なsyntax_option_typeでも
ECMAScript相当なんだな。
うーん、今時look-behindがないってのは見劣りするなあ。

152 ：デフォルトの名無しさん：2006/09/07(木) 14:25:14

boostにTR1が実装されたみたいだけど、使ってみようかな

153 ：デフォルトの名無しさん：2006/09/07(木) 15:22:21

>>3を見るまでautoの存在を忘れていた

154 ：デフォルトの名無しさん：2006/09/07(木) 16:44:13

C++0xの0xが16進プレフィクスではなく
2010年までには出すぞ、という願望の現われだと今日知った。

早く使いたいな。

155 ：デフォルトの名無しさん：2006/09/07(木) 17:52:59

対応コンパイラが出るのは5年後です

156 ：デフォルトの名無しさん：2006/09/07(木) 21:27:24

C++0xが世に出るのは2109年だよ。
ドラえもんはそれで書かれてる。

157 ：デフォルトの名無しさん：2006/09/07(木) 23:56:45

C++0xの実装は跳ばされる

158 ：デフォルトの名無しさん：2006/09/08(金) 09:56:08

そんなことはないと言いたいところだけど、
exportの例があるからな…

159 ：デフォルトの名無しさん：2006/09/08(金) 12:25:16

あれはどちらかというと、実装の手間を考えずに策定した側に
問題あるような。

160 ：デフォルトの名無しさん：2006/09/09(土) 00:22:06

実際問題、実装しろとか言われたら嫌な汗出てくるもんな。
C++全体に渡ってそんな感じではあるが。

161 ：デフォルトの名無しさん：2006/09/09(土) 02:41:12

こんなこといいな、できたらいいなと何でもかんでも詰め込んだまではよかったが
不思議なポッケでかなえてくれるドラえもんはいないという点にまで気が回らなかったと

162 ：デフォルトの名無しさん：2006/09/09(土) 03:24:51

exportは一応EDGが3人年かけてかなえてくれたけどな
誰も近寄らなくなったけどw

163 ：デフォルトの名無しさん：2006/09/09(土) 04:32:41

C++は夢いっぱい

164 ：デフォルトの名無しさん：2006/09/09(土) 09:46:54

VC2005で、リンク時のコード生成を行ってるけど、exportじゃ無いのかな？

165 ：デフォルトの名無しさん：2006/09/09(土) 12:19:22

>>164
それは最適化。
たとえば、リンク時にインライン展開するとか。

166 ：デフォルトの名無しさん：2006/09/09(土) 13:39:37

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

167 ：デフォルトの名無しさん：2006/09/09(土) 13:45:23

実際、Javaはwrite once、compile once、run anywhereだもんな。
失うものも多いが、楽なのは確かだ。

168 ：デフォルトの名無しさん：2006/09/09(土) 13:48:10

拡張機能を切ってコンパイルすれば、そこそこ正しくはなる。
ただ、それでも他のコンパイラでコンパイルすると
不完全だと分かる事もよくある話。
難しいもんですな。

169 ：デフォルトの名無しさん：2006/09/09(土) 14:54:45

>167
debug anywhere だけどな

170 ：デフォルトの名無しさん：2006/09/09(土) 18:08:44

Write Once, Run Anywhere, Debug Everywhere!

171 ：デフォルトの名無しさん：2006/09/09(土) 20:42:30

やっぱり、#ifdef は要るよ

172 ：デフォルトの名無しさん：2006/09/09(土) 23:32:00

そんなあなたにBoost MPL。

173 ：デフォルトの名無しさん：2006/09/11(月) 06:00:00

Debug Everyday!

174 ：デフォルトの名無しさん：2006/09/11(月) 21:11:16

char を UTF-8、wchar_t を UTF-16 として認識する標準ライブラリおよび
コンパイルオプションが欲しい。

175 ：デフォルトの名無しさん：2006/09/11(月) 21:55:25

>>174
そういうlocale（特にcodecvt）を作ればいいという話ではないのか？

176 ：デフォルトの名無しさん：2006/09/11(月) 22:11:50

STLのlocale周りは、はっきり言って無駄だから、
さっくり削除してほしいと思っているのは自分だけ？

177 ：デフォルトの名無しさん：2006/09/11(月) 22:13:38

実装の話？仕様の話？

178 ：デフォルトの名無しさん：2006/09/11(月) 22:16:05

>>174
> char を UTF-8

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

179 ：デフォルトの名無しさん：2006/09/11(月) 22:17:32

>>174
> wchar_t を UTF-16 として

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

180 ：デフォルトの名無しさん：2006/09/11(月) 22:18:43

>>176
君みたいな人は少ないと思う。

181 ：デフォルトの名無しさん：2006/09/12(火) 01:02:06

サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか
邪魔にされる日が来るのかね。
1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。

182 ：デフォルトの名無しさん：2006/09/12(火) 01:24:19

しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、
欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
実際のところどうなのかは知らないが。

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

183 ：デフォルトの名無しさん：2006/09/12(火) 02:34:51

http://www.open-std.org/jtc1/sc22/wg21/
> 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 ：デフォルトの名無しさん：2006/09/12(火) 13:22:39

>>183
(ﾟ∀ﾟ)ktkr
待ってたぜ。これで仕事中こっそり楽し(ry

185 ：デフォルトの名無しさん：2006/09/13(水) 05:22:20

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

186 ：デフォルトの名無しさん：2006/09/13(水) 06:41:57

ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。

187 ：デフォルトの名無しさん：2006/09/13(水) 08:27:03

だからさ、char 型なんて廃止して、byte 型にしてほしいぜ
別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが

188 ：デフォルトの名無しさん：2006/09/13(水) 09:48:52

charが実装依存ですが?
basic_stringテンプレート知らない人ですか、ああそうですか

189 ：デフォルトの名無しさん：2006/09/13(水) 12:24:08

日本語も読めないのに皮肉を言おうとするとこうなる。

190 ：デフォルトの名無しさん：2006/09/13(水) 12:54:37

uint8_tで何が不満なんだ? > byte_t

191 ：デフォルトの名無しさん：2006/09/13(水) 18:51:23

8bitとは限らないから…とか？

192 ：デフォルトの名無しさん：2006/09/13(水) 21:24:18

uint8_t i = 32;
std::cout << i;

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

193 ：デフォルトの名無しさん：2006/09/13(水) 21:26:02

1byteを表すchar
文字を表すchar
双方を別々に定義すべきだという主張かと

194 ：デフォルトの名無しさん：2006/09/13(水) 21:38:12

C++ でせっかく char と signed char と unsigned char に分かれたのに、
なんで cout << で全部文字になっちまうんだ？

195 ：デフォルトの名無しさん：2006/09/13(水) 21:54:36

実際問題、符号ないほうが都合がいいから
文字としてuchar使ってるケースあるし、その辺との兼ね合いでね？

196 ：デフォルトの名無しさん：2006/09/14(木) 08:34:29

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

197 ：デフォルトの名無しさん：2006/09/14(木) 08:52:47

>>196
文字列(というか文字)を何とかした結果が今の形 char だと思う。

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

198 ：デフォルトの名無しさん：2006/09/14(木) 22:37:48

char は C との互換性のために残しておく程度でいい
std::string と std::wstring 間にろくな互換性無いだろ？
これを柔軟性というのか？

199 ：デフォルトの名無しさん：2006/09/14(木) 23:06:50

>>198 そういう意味だったのか。

200 ：デフォルトの名無しさん：2006/09/15(金) 00:54:03

>>198
互換性って例えばどういうこと?

201 ：デフォルトの名無しさん：2006/09/15(金) 01:44:55

>>200 もう血が止まってるんだから、変にいじったりしないの！

202 ：デフォルトの名無しさん：2006/09/15(金) 09:11:21

おねがいします。

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

203 ：デフォルトの名無しさん：2006/09/15(金) 09:26:00

なんでまた C++0x スレに？
もしかしてマルチ？

204 ：デフォルトの名無しさん：2006/09/15(金) 09:34:41

マルチだね
どこだか忘れたが別スレで見た

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

205 ：デフォルトの名無しさん：2006/09/17(日) 00:49:06

C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？

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

206 ：デフォルトの名無しさん：2006/09/17(日) 11:10:37

おじいさんは、裏山に畑を耕しに行ったんじゃない？

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

207 ：デフォルトの名無しさん：2006/09/17(日) 15:01:57

いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。

208 ：デフォルトの名無しさん：2006/09/17(日) 20:43:56

>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。

209 ：デフォルトの名無しさん：2006/09/17(日) 23:24:34

書かれたものがキチガイだと
本当に誰にも通じないけどな。

210 ：デフォルトの名無しさん：2006/11/24(金) 14:31:34

N2133 06-0203
Editor's ReportPete Becker
2006-11-03
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2133.html

N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
新規色分け版

N2135 06-0205
Programming Languages －C++ Pete Becker
2006-11-06 N2134=06-0204
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf
色分けなし版

211 ：デフォルトの名無しさん：2006/11/24(金) 18:16:23

ちなみにADLのところ、3.4.2のルールが書き変わっています。

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

212 ：デフォルトの名無しさん：2006/11/24(金) 18:56:53

色の違いだったのね

213 ：デフォルトの名無しさん：2006/11/24(金) 22:19:20

論文リスト、ちらほら C++09 という記述が出始めたな

214 ：デフォルトの名無しさん：2006/11/24(金) 22:21:19

2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。

215 ：デフォルトの名無しさん：2006/11/28(火) 23:58:39

Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。

216 ：デフォルトの名無しさん：2006/11/29(水) 01:24:10

一番ほしいのはTemplate aliasesかな

217 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/11/29(水) 01:42:23

とマニアが言っております

219 ：デフォルトの名無しさん：2006/11/29(水) 01:48:06

いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。

220 ：デフォルトの名無しさん：2006/11/29(水) 12:59:00

>>219
明暗！

221 ：デフォルトの名無しさん：2006/11/29(水) 16:09:12

言い得て妙な変換だなｗ

222 ：デフォルトの名無しさん：2006/11/29(水) 17:42:23

namespace std0x
{
using namespace std;
}

223 ：デフォルトの名無しさん：2006/11/30(木) 08:53:29

namespace std0x = std;

224 ：デフォルトの名無しさん：2006/11/30(木) 13:36:58

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

225 ：デフォルトの名無しさん：2006/11/30(木) 13:50:21

>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。

226 ：デフォルトの名無しさん：2006/11/30(木) 14:41:25

>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ

227 ：デフォルトの名無しさん：2006/11/30(木) 16:22:54

BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい

228 ：デフォルトの名無しさん：2006/11/30(木) 16:52:46

"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…

229 ：デフォルトの名無しさん：2006/11/30(木) 20:58:15

>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。

230 ：デフォルトの名無しさん：2006/11/30(木) 23:42:40

>>217
Cryoliteたん？

231 ：デフォルトの名無しさん：2006/12/05(火) 21:36:18

>>215です。

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

232 ：デフォルトの名無しさん：2006/12/05(火) 22:07:30

rvalue referenceってなんなのさ？

233 ：デフォルトの名無しさん：2006/12/05(火) 22:37:14

ここで。

A Brief Introduction to Rvalue References
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html

234 ：デフォルトの名無しさん：2006/12/05(火) 22:49:58

>>233
よく纏まっていてわかりやすいね。

235 ：デフォルトの名無しさん：2006/12/06(水) 09:50:22

auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう

236 ：デフォルトの名無しさん：2006/12/06(水) 12:13:53

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

237 ：デフォルトの名無しさん：2006/12/07(木) 04:52:50

ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。

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

238 ：デフォルトの名無しさん：2006/12/08(金) 18:26:39

その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし

239 ：デフォルトの名無しさん：2006/12/09(土) 01:08:57

ここで>>217に戻る。

240 ：デフォルトの名無しさん：2006/12/09(土) 01:15:54

まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし

241 ：デフォルトの名無しさん：2006/12/09(土) 05:11:42

>パフォーマンスゲインも5倍

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

242 ：デフォルトの名無しさん：2006/12/09(土) 09:13:34

こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。

243 ：デフォルトの名無しさん：2006/12/09(土) 12:42:51

コンパイル時間も5倍に…

244 ：デフォルトの名無しさん：2006/12/09(土) 12:56:47

>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ

245 ：デフォルトの名無しさん：2006/12/09(土) 16:56:31

父さん、言語拡張症にかかって…

246 ：デフォルトの名無しさん：2006/12/09(土) 22:35:18

これからは言語のモジュール化ですよ。

247 ：デフォルトの名無しさん：2006/12/10(日) 07:07:20

>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？

248 ：デフォルトの名無しさん：2006/12/10(日) 08:50:22

>>247
お前マジ天才じゃね？

249 ：デフォルトの名無しさん：2006/12/10(日) 10:16:27

最終的には今日コンパイルすると昨日完了するようになる

250 ：デフォルトの名無しさん：2006/12/10(日) 10:20:32

そのコンパイラでコンパイラをコンパイルさせてください。

251 ：デフォルトの名無しさん：2006/12/10(日) 10:53:35

おまいらホント暇だなｗ

252 ：デフォルトの名無しさん：2006/12/10(日) 17:55:34

最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？

253 ：デフォルトの名無しさん：2006/12/10(日) 19:57:26

ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか

254 ：デフォルトの名無しさん：2006/12/10(日) 20:04:18

autoはC++09に確実に入るんじゃないのかな?

255 ：デフォルトの名無しさん：2006/12/10(日) 20:17:08

標準委員会、キーワード追加症にかかって…

256 ：デフォルトの名無しさん：2006/12/10(日) 20:22:14

>>254 それはずっと前からキーワード。

257 ：デフォルトの名無しさん：2006/12/10(日) 20:56:19

意味が変更される予約語はautoだけかな

258 ：デフォルトの名無しさん：2006/12/14(木) 13:27:42

しかしautoはどうかと思う…
型の弱い言語みたいだ

259 ：デフォルトの名無しさん：2006/12/14(木) 13:32:51

初期化される時点で型が決まってしまうのに、どこが弱いんだか。

260 ：デフォルトの名無しさん：2006/12/14(木) 14:11:35

コンパイル時に型が決定するのだから、弱いわけがないわな。

261 ：デフォルトの名無しさん：2006/12/14(木) 14:17:45

しかしtemplate引数の省略はどうかと思う・・・
型の弱い言語みたいだ

262 ：デフォルトの名無しさん：2006/12/14(木) 14:19:49

しかしboost.Anyが実装できるのはどうかと思う。
型の弱（ｒｙ

263 ：デフォルトの名無しさん：2006/12/14(木) 19:08:59

キャス(ry

264 ：デフォルトの名無しさん：2006/12/14(木) 20:18:58

vo(ry

265 ：デフォルトの名無しさん：2006/12/14(木) 20:29:55

悲しいかな、reinterpret_castやvoid*などの存在で、
C++が弱い型付けと分類されていることを見かける。

266 ：デフォルトの名無しさん：2006/12/14(木) 20:44:04

まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの

267 ：デフォルトの名無しさん：2006/12/14(木) 21:48:36

その理屈だと、アセンブラは弱い肩か？

268 ：デフォルトの名無しさん：2006/12/14(木) 23:04:19

アセンブラは弱すぎ。虚弱体質だな。

269 ：デフォルトの名無しさん：2006/12/14(木) 23:12:43

低級言語は型とかないだろ

270 ：デフォルトの名無しさん：2006/12/14(木) 23:31:02

>>265
まさにカタ無しだね

271 ：デフォルトの名無しさん：2006/12/15(金) 00:04:48

しかしこのスレの流れはどうかと思う。
頭の弱い……

272 ：デフォルトの名無しさん：2006/12/21(木) 11:30:13

JIS X3014:2003って、
ISO/IEC 14882:2003の逐語訳じゃないんですね。
省略されているところがあってびっくりしました。

13.3.1.2.3のnon-memberのところ。

273 ：デフォルトの名無しさん：2007/01/03(水) 19:15:16

>>272
JISチームのチョンボで抜けちゃったとかじゃなくて？
そういえば、JIS X3014:2003 って買った時期によってPDFの"しおり"があったりなかったり
するらしいね。なんか以前、cppll で金返せ的なことを愚痴ってたヤツがいた。

274 ：デフォルトの名無しさん：2007/01/12(金) 19:40:21

シンボルの undef とこっから先 const の機能がほしい
スレ違いか？

275 ：デフォルトの名無しさん：2007/01/12(金) 20:41:03

シンボルの undef というか、スコープ付の define がほしい。

ここから先 const はいらんなあ。値を変えるところと変えないところで
関数が分かれてないのは設計ミスだと思う。

276 ：デフォルトの名無しさん：2007/01/12(金) 22:21:49

派生の禁止はできるようにならんの？

277 ：デフォルトの名無しさん：2007/01/12(金) 22:29:27

ttp://article.gmane.org/gmane.comp.lib.boost.devel/101260

278 ：デフォルトの名無しさん：2007/01/12(金) 23:23:42

あーなるほどね、宣言は出来るけどインスタンスは作れない、と。

279 ：デフォルトの名無しさん：2007/01/12(金) 23:29:21

>>273
>JISチームのチョンボ
まことしやかにささやかれてるけど真実味あるなｗ

280 ：デフォルトの名無しさん：2007/01/13(土) 03:24:39

>>276
あと、派遣の禁止も欲しいよなぁ。

281 ：デフォルトの名無しさん：2007/01/13(土) 23:29:46

>>277
古い。illegal

noninheritableがどっかにあったな

282 ：デフォルトの名無しさん：2007/01/13(土) 23:44:57

boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。

283 ：デフォルトの名無しさん：2007/01/13(土) 23:47:38

-ableにnotは不味いだろ。

284 ：デフォルトの名無しさん：2007/01/13(土) 23:50:06

>>283
ttp://msdn2.microsoft.com/ja-jp/library/h278d2d4(VS.80).aspx

285 ：デフォルトの名無しさん：2007/01/13(土) 23:51:08

>>282
英語的にはunが正しい。
何故nonになっているのかは不明

286 ：デフォルトの名無しさん：2007/01/13(土) 23:56:44

im と un を混同したのではないか

287 ：デフォルトの名無しさん：2007/01/14(日) 08:33:30

Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。

288 ：デフォルトの名無しさん：2007/01/14(日) 17:09:42

それは俺の戯言なので真に受けないように

289 ：デフォルトの名無しさん：2007/01/14(日) 22:53:43

Effectice C++ 3版でも突っ込まれてたような

290 ：デフォルトの名無しさん：2007/01/26(金) 20:55:16

http://en.wikipedia.org/wiki/C%2B%2B0x
右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね？

291 ：デフォルトの名無しさん：2007/01/27(土) 09:21:41

未定

292 ：wankuma：2007/01/27(土) 19:20:53

わんくま加盟求む
http://blogs.wankuma.com/

293 ：デフォルトの名無しさん：2007/02/19(月) 19:49:16

ttp://herbsutter.spaces.live.com/Blog/cns!2D4327CC297151BB!159.entry
>we finish the document in 2009, but because ISO takes most of
>a year to approve and publish a standard, it would end up as
>"C++10" (or, one could uncomfortably imagine, "C++0a").

294 ：デフォルトの名無しさん：2007/02/19(月) 20:04:02

もうC++0fでいいよ。

295 ：デフォルトの名無しさん：2007/02/20(火) 03:31:04

どうせVC7.1であと10年がんばるんですよ

296 ：デフォルトの名無しさん：2007/02/20(火) 08:41:21

>>295
スレ違い。

297 ：デフォルトの名無しさん：2007/02/20(火) 12:48:39

>>157

298 ：デフォルトの名無しさん：2007/03/03(土) 09:39:19

vector<int> v;
auto var = v.begin();

と型推論？ぽい事ができる様になるらしいですが、
この時のvarの型は
vector<int>::iterator
になるんでしょうか　それとも
vector<int>::const_iterator?

299 ：デフォルトの名無しさん：2007/03/03(土) 10:30:49

前者でないと困る。
前者なら、後者はauto const varという宣言で済むと思うが。

300 ：デフォルトの名無しさん：2007/03/03(土) 10:34:50

そうすると、vector<int>::const_iteratorではなくて、
cont vector<int>::iteratorになりそうな

301 ：デフォルトの名無しさん：2007/03/03(土) 11:14:10

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

302 ：デフォルトの名無しさん：2007/03/03(土) 11:19:20

ああboost::cref使えば良さそうな気がする

303 ：デフォルトの名無しさん：2007/03/03(土) 11:20:36

vector<int> v;
auto var = const_cast<const vector<int>&>(v).begin();
これでいいでしょ？

304 ：デフォルトの名無しさん：2007/03/03(土) 11:24:56

vをconstにしたいって話でcref？

305 ：デフォルトの名無しさん：2007/03/03(土) 11:27:11

>>303
それやるならstatic_castだろ。

型名書くのがめんどくさい場合はcrefじゃね？

306 ：デフォルトの名無しさん：2007/03/03(土) 11:28:58

C++0xを知らんけど
そんなことしてまでauto使う意味わかんね。

307 ：デフォルトの名無しさん：2007/03/03(土) 11:31:24

どっちかっていうと
そんなことまでしてconst_iteratorにする意味わかんね。

308 ：デフォルトの名無しさん：2007/03/03(土) 11:48:48

こういう手もある。まあかえって長ったらしくなっているけど。
boost::range_const_iterator<decltype(v)>::type var = v.begin();

309 ：デフォルトの名無しさん：2007/03/03(土) 11:57:47

アホが来た

310 ：デフォルトの名無しさん：2007/03/03(土) 12:03:54

>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf

最新のドラフトには載ってるから、採用されたのかな？

311 ：デフォルトの名無しさん：2007/03/03(土) 12:23:44

boost::cref (std::tr1::cref) では無理なのでは？

template< class T >
T const &as_const( T &x )
{ return x; }

とか作って使うのではダメなん？

312 ：デフォルトの名無しさん：2007/03/03(土) 13:02:44

#include <iostream>
#include <vector>
#include <tr1/functional>

using namespace std;

int main(void)
{
    vector<int> v(10);
    cout << typeid(v.begin()).name() << endl;
    cout << typeid(tr1::cref(v).get().begin()).name() << endl;
    return 0;
}

313 ：デフォルトの名無しさん：2007/03/03(土) 13:16:55

boostにconst_beginってなかったっけ？

314 ：デフォルトの名無しさん：2007/03/03(土) 13:20:02

こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。

315 ：デフォルトの名無しさん：2007/03/03(土) 13:27:28

>>312
get() 使うなら当然できるけれど，それなら311で良いのでは？

316 ：デフォルトの名無しさん：2007/03/03(土) 19:12:34

v.begin()じゃなくて、begin(v)を使う派なのだが
（これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる）
こんな人にも、autoは役に立つのかしらん？

317 ：デフォルトの名無しさん：2007/03/03(土) 20:28:01

auto v = v.begin() const;
みたいな呼び出しができたらいいのにと思った

318 ：デフォルトの名無しさん：2007/03/03(土) 20:38:02

const audo v = v.begin()
の方がいいかも！？と思った

319 ：デフォルトの名無しさん：2007/03/03(土) 22:25:17

>>318
>>300
流れよめんのか

320 ：デフォルトの名無しさん：2007/03/05(月) 08:00:08

const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。

321 ：デフォルトの名無しさん：2007/03/05(月) 09:26:00

containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1865.pdf

二バージョンないケースでは、何か工夫する必要があるね。

322 ：デフォルトの名無しさん：2007/03/05(月) 10:13:24

一文字の接頭辞が複数続くのってなんかいやん
crend とかなにって感じー

323 ：デフォルトの名無しさん：2007/03/07(水) 00:05:13

何だかんだで、const auto& cv(v);
してから、cv.begin(), cv.end() が一番読みやすいかも

324 ：デフォルトの名無しさん：2007/03/07(水) 16:48:34

数学の関数とかみたいに
コンパイル時に式自体
を計算・展開できるような式関数導入して欲しい。

325 ：デフォルトの名無しさん：2007/03/07(水) 18:43:00

実装も添えて提案して頂かないとイメージが沸かない

326 ：デフォルトの名無しさん：2007/03/07(水) 20:01:57

>>324

つまり
int a = 5+1;
は、コンパイラが
int a = 6;
としてコードを生成してくれるってことか。

inline int func(int x) { return x*2; }
int c = func(5);
をコンパイラが
int c = 10;
にしてくれるとか。

sinはコンパイラではなくコンパイル後に
リンクするライブラリにある処理だから難しいな。

LUTを作るの面倒だから判らなくもない。

327 ：デフォルトの名無しさん：2007/03/07(水) 20:07:41

今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。

328 ：デフォルトの名無しさん：2007/03/07(水) 20:43:12

>>326
少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と
規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。

329 ：デフォルトの名無しさん：2007/03/07(水) 23:01:37

がんばってtemplateでsinを実装するんだ(w

330 ：デフォルトの名無しさん：2007/03/07(水) 23:04:59

整数演算だけでか？ｗ

331 ：デフォルトの名無しさん：2007/03/07(水) 23:15:43

前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。

332 ：デフォルトの名無しさん：2007/03/07(水) 23:26:01

コンパイル時変数と実行時変数を明示的に区別して定義できるようにならないかなあ。
いっそのことプログラムの実行そのものをコンパイル時と実行時で分けて、
コンパイル時実行ではインタプリタ型で動いて、コンパイル時変数にのみアクセス可能で
JavaScriptばりにクラスのメンバ関数の追加や削除、関数の構成、evalができて、とか。

333 ：デフォルトの名無しさん：2007/03/07(水) 23:29:13

D 言語でいいよ、もう。

334 ：324：2007/03/08(木) 00:03:20

同様にmy_cos,my_tanを作って
my_tan:=my_sin/my_cos;
という関係を作っておく。

my_sin(x)/my_cos(x)という式を使ったときは左記の関数はCallされずに
my_tan(x)がCallされて計算されるといった感じのもの。

//いいかげんなmy_sinの例
template <typename T> T my_sin(T x)
where Type(T,Re) //T：実数
{
calc{return x(1-x*x/6);}//計算値
expr(T a){my_sin(a);}//計算式
}

335 ：デフォルトの名無しさん：2007/03/08(木) 00:05:30

スクリプトでも使ってジェネレートした方がはやくね？

336 ：デフォルトの名無しさん：2007/03/08(木) 00:40:01

プリプロセッサ強化だな。

337 ：デフォルトの名無しさん：2007/03/08(木) 01:35:03

ttp://video.google.com/videoplay?docid=-1790714981047186825
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。

338 ：デフォルトの名無しさん：2007/03/08(木) 09:01:29

templateの処理をプリプロセッサの役割とする
↓
Cでもtemplateできるようにする。

339 ：デフォルトの名無しさん：2007/03/08(木) 09:50:31

Cfrontみたいだな

340 ：デフォルトの名無しさん：2007/03/08(木) 11:46:16

もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ　

341 ：デフォルトの名無しさん：2007/03/08(木) 16:12:16

>>340
「バカヤロウ、まだ始まってもいねえよ。」

342 ：デフォルトの名無しさん：2007/03/08(木) 16:34:10

互換性はあるんじゃないか？今までのが非推奨になる感じで

343 ：デフォルトの名無しさん：2007/03/08(木) 16:35:46

old style cast とかどうするんだろ

344 ：デフォルトの名無しさん：2007/03/08(木) 18:25:58

>>324
再帰はできないわ，まともな制御構文はないわ，で良ければ一応
C++0x に向けて active に動いているっぽい提案
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2116.pdf
いずれにしろ，元々が traits などに使われるのを想定した提案ですので非力極まりない

もっと抜本的な提案なら
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
ですけれど，こちらは C++0x には間に合わない様子

345 ：デフォルトの名無しさん：2007/03/14(水) 20:34:06

C++0a になりそうな気配が濃厚になってまいりました

346 ：デフォルトの名無しさん：2007/03/15(木) 00:49:43

C++0x2010でいいからもう

347 ：デフォルトの名無しさん：2007/03/15(木) 23:22:40

それは勘弁してw

348 ：デフォルトの名無しさん：2007/03/16(金) 00:23:13

C+(+0x2010)
→ 0x201C
いや、わかっているよ、こう解釈されないことくらい。

349 ：デフォルトの名無しさん：2007/03/16(金) 15:02:28

>>346
8208www

350 ：デフォルトの名無しさん：2007/03/26(月) 18:39:26

C++2008

351 ：デフォルトの名無しさん：2007/03/28(水) 02:06:06

可変個引数テンプレート(Variadic Templates)だけど、template の specialization を使って一つづつ取り出していくだけかと思ったらなかなかすごいことになってるのね。

こんな展開が可能だったり、
---
template<typename...> struct Tuple {};
template<typename T1, typename T2> struct Pair {};

template<typename... Args1> struct zip {
  template<typename... Args2> struct with {
    typedef Tuple<Pair<Args1, Args2>...> type;
};
};

typedef zip<short, int>::with<unsigned short, unsigned>::type T1;　// T1 is Tuple<Pair<short, unsigned short>, Pair<int, unsigned> >
---

これで任意引数個の perfect forwarding function になったり(rvalue reference利用)
---
template<typename T>
struct allocator {
  template<typename... Args>
  void construct(T* ptr, Args&&... args) { new (ptr)(static cast<Args&&>(args)...); }
};
---

Variadic Templates の概要は↓がわかりやすい
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2080.pdf
↓は規格の変更点について
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2152.pdf
GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。
http://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/
おまいらもヒトバシラーしてみませんか？

352 ：デフォルトの名無しさん：2007/03/28(水) 08:47:26

Variadic Templates、入るかねえ?

353 ：デフォルトの名無しさん：2007/04/01(日) 22:08:44

>352
何か具体的な懸念が？
提案者自身は
>Variadic templates seem to be moving smoothly,
と言ってるけどね。
ttp://conceptgcc.wordpress.com/2007/02/15/decltype-and-rvalue-references-and-variadic-templates-oh-my/#comment-131

354 ：デフォルトの名無しさん：2007/04/12(木) 07:04:47

http://www.devsource.com/article2/0,1895,2061095,00.asp
によれば、template aliases が入ることになっているなあ。嬉しい。

355 ：デフォルトの名無しさん：2007/04/16(月) 20:57:47

nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど
そういうのはないんかな

356 ：デフォルトの名無しさん：2007/04/16(月) 21:18:55

#define nameof(x) typeid(x).name()

357 ：デフォルトの名無しさん：2007/04/16(月) 21:21:15

typeid(hoge).name()があるでしょ。
マングルされてたりいろいろ面倒だけど。

358 ：デフォルトの名無しさん：2007/04/16(月) 22:08:34

typeid().name()は正直使えない

359 ：デフォルトの名無しさん：2007/04/16(月) 22:13:47

まあ保証されている事と言えば同一の型のname()も同一である
という事だけだからな
リフレクションのような事は正直無理

360 ：デフォルトの名無しさん：2007/04/27(金) 00:24:43

>352
ttp://conceptgcc.wordpress.com/2007/04/24/variadic-templates-are-in-c0x/
だそうな。

361 ：デフォルトの名無しさん：2007/04/27(金) 07:28:21

まじか。
機能的にはC++0xに入る必然性があるけれど、
さらにデバックしにくくなりそう…

variadic templatesを直接使う人じゃなくて、
variadic templatesが使われたlibraryを使う人ね。
エラーメッセージがさらにハナモゲラ化w

362 ：デフォルトの名無しさん：2007/04/27(金) 12:49:13

>>361
現状でも Boost.Function とか Boost.Variant とか
BOOST__PP_* で T0,T1,T2,... を生成してるやつは
エラーメッセージがハナモゲラ化してるわけで

その部分が T0... みたいに可変長ぽく省略表示されるだけで
だいぶ見やすくなると思うんだが

363 ：デフォルトの名無しさん：2007/05/14(月) 14:22:20

concept が入ればエラーメッセージはかなりましになるのでは？

364 ：デフォルトの名無しさん：2007/05/14(月) 14:24:15

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-05

365 ：デフォルトの名無しさん：2007/05/28(月) 01:09:30

ほ

366 ：デフォルトの名無しさん：2007/05/31(木) 00:47:25

とりあえずC99準拠で

367 ：デフォルトの名無しさん：2007/05/31(木) 01:59:00

C99はC++の精神に反しているのに
実装にはC++の機能が必要というトンデモ言語

368 ：デフォルトの名無しさん：2007/05/31(木) 03:13:42

C++の精神自体がトンデモの塊だから問題ない

369 ：デフォルトの名無しさん：2007/05/31(木) 06:35:41

Javaのキャストみたいなもんだな

370 ：デフォルトの名無しさん：2007/05/31(木) 06:43:51

c99にc++の機能が必要とは初耳だな。

371 ：デフォルトの名無しさん：2007/05/31(木) 06:56:08

コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？

372 ：デフォルトの名無しさん：2007/05/31(木) 07:09:44

内容的には>>360 >>364で既出ですが、http://herbsutter.spaces.live.com/より

New Language Features Voted Into (Draft) C++09
・Template aliases (aka typedef templates, generalized typedefs) [N2258]
・Variadic templates (aka "type varargs" for templates) [N2242; see N2087 for a more readable description and rationale]
・Unicode characters and strings [N2249]
・Rvalue references [N1952]

373 ：デフォルトの名無しさん：2007/05/31(木) 16:54:12

へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。

374 ：デフォルトの名無しさん：2007/05/31(木) 17:46:31

すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。

375 ：デフォルトの名無しさん：2007/05/31(木) 19:57:46

これですな
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html

そのうちstd::u16stringとかstd::u32stringとかもできるんだろか

376 ：373：2007/06/01(金) 00:57:02

入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。

377 ：デフォルトの名無しさん：2007/06/01(金) 01:12:11

L"文字列" はどういう扱いになるん？

378 ：デフォルトの名無しさん：2007/06/01(金) 01:36:05

こんな感じかな？

wchar_t wc = L'あ';　// wcの値は実装依存 (今と同じ)
char16_t c16 = u'あ';　// c16は0x3042
char32_t c32 = U'あ';　// c32は0x00003042

379 ：デフォルトの名無しさん：2007/06/01(金) 01:39:40

UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？

380 ：デフォルトの名無しさん：2007/06/01(金) 01:40:47

あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。

381 ：デフォルトの名無しさん：2007/06/01(金) 01:44:07

UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする

382 ：デフォルトの名無しさん：2007/06/01(金) 08:22:04

>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?

383 ：デフォルトの名無しさん：2007/06/01(金) 08:22:49

>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。

384 ：デフォルトの名無しさん：2007/06/01(金) 08:35:43

下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ

385 ：デフォルトの名無しさん：2007/06/01(金) 09:07:21

uint8_tと読み直せばいいんじゃない。

386 ：デフォルトの名無しさん：2007/06/01(金) 09:09:30

uint8_t って optional だったよね。

387 ：デフォルトの名無しさん：2007/06/01(金) 13:30:21

何年か経ったらwchar_tはいらない子扱いされてそうだ

388 ：デフォルトの名無しさん：2007/06/01(金) 15:19:52

tcharでいいじゃん

389 ：デフォルトの名無しさん：2007/06/01(金) 16:02:57

>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw

390 ：デフォルトの名無しさん：2007/06/01(金) 16:43:08

>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375

391 ：デフォルトの名無しさん：2007/06/01(金) 17:00:04

どうせウニコードなんか窓しか使わないのにイラネ

392 ：デフォルトの名無しさん：2007/06/01(金) 17:05:18

>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ

393 ：デフォルトの名無しさん：2007/06/01(金) 17:14:12

LinuxもUTF-8なご時世になんて寝言を……

394 ：デフォルトの名無しさん：2007/06/01(金) 17:43:00

ふつーにEUC

395 ：デフォルトの名無しさん：2007/06/01(金) 18:46:06

Unicode関連のロケールが標準に入ると考えていいんだろうか・・

396 ：デフォルトの名無しさん：2007/06/01(金) 20:20:04

CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？

397 ：デフォルトの名無しさん：2007/06/01(金) 20:53:50

8は保証されてるの？

398 ：デフォルトの名無しさん：2007/06/01(金) 21:14:54

下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。

399 ：デフォルトの名無しさん：2007/06/02(土) 11:33:29

世の中のプログラマのほとんどが

>どうせウニコードなんか窓しか使わないのにイラネ

と思っていたはずなのに

>LinuxもUTF-8なご時世になんて寝言を……

になってしまったのはいつから？なぜ？

400 ：デフォルトの名無しさん：2007/06/02(土) 11:43:17

>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。

401 ：デフォルトの名無しさん：2007/06/02(土) 11:44:01

そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。

なんだかんだ言ってもUnicode周辺には、
"Technical Notes", "Technical Reports"その他に、
ノウハウがたまってきているので、強力にサポートすべき。

wchar_tの実装をUnicode onlyにするなんてのには大反対。
n2249はGJ。

402 ：デフォルトの名無しさん：2007/06/02(土) 11:55:15

じゃぁ、wchar_t はTRON用ということでおｋ？

403 ：デフォルトの名無しさん：2007/06/02(土) 12:29:48

TRONはwwchar_tです。

404 ：デフォルトの名無しさん：2007/06/02(土) 13:10:56

でも、Windows は UTF-16 なんだよな？

405 ：デフォルトの名無しさん：2007/06/02(土) 13:31:23

>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。

406 ：デフォルトの名無しさん：2007/06/02(土) 13:41:47

どちらにしろ UTF-16 だろ？

407 ：デフォルトの名無しさん：2007/06/02(土) 15:39:01

つWM_UNICHAR
http://msdn2.microsoft.com/en-us/library/ms646288.aspx

408 ：デフォルトの名無しさん：2007/06/02(土) 18:51:20

char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。

409 ：デフォルトの名無しさん：2007/06/02(土) 19:15:39

C95みたいに後から追補出せばいいよ

410 ：デフォルトの名無しさん：2007/06/02(土) 19:44:42

streamやfacetsは対応しないみたい
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2238.html

あとUTF-8の案もあった
今のところWDには含められていないけど
ttp://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2209.html

プリフィックスは E で、1バイト8ビット以上を保証すると

411 ：デフォルトの名無しさん：2007/06/02(土) 21:41:23

>streams of non-char types have not attracted wide usage, so it is not clear
>that there is a real need for

う～ん…8bit圏の人にとっちゃそうかもしれんけどさ。

412 ：デフォルトの名無しさん：2007/06/02(土) 22:39:06

まあその辺はゆっくりやって、後から補完でいいんじゃないの?
Primitive typeとして導入されたわけだから、
いろいろ実装してみるための最低限のことは決まるわけだからさ。
typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。

413 ：デフォルトの名無しさん：2007/06/02(土) 22:59:52

Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。

414 ：デフォルトの名無しさん：2007/06/02(土) 23:14:12

WCHARあるからねー

415 ：デフォルトの名無しさん：2007/06/03(日) 00:28:53

>>413
意味が分からない。
どれに対するレス?

416 ：デフォルトの名無しさん：2007/06/03(日) 00:29:10

Windowsなんかうんこ

417 ：デフォルトの名無しさん：2007/06/03(日) 00:29:51

>>415
>>411

418 ：デフォルトの名無しさん：2007/06/03(日) 00:35:57

char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが

419 ：デフォルトの名無しさん：2007/06/03(日) 00:35:59

それはWindowsにはニュートラルな話。

420 ：デフォルトの名無しさん：2007/06/03(日) 00:37:38

Windowsとか持ち出してるのはただの馬鹿だろ

421 ：デフォルトの名無しさん：2007/06/03(日) 00:46:50

>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。

422 ：デフォルトの名無しさん：2007/06/03(日) 00:56:23

GCC だと wchar_t は 4 だったな。

423 ：デフォルトの名無しさん：2007/06/03(日) 01:00:45

>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。

424 ：デフォルトの名無しさん：2007/06/03(日) 01:27:10

char16_t, char32_tの入った処理系では、
typedef char16_t wchar_t か、typedef char32_t wchar_t で、
wchar_tなライブラリも使えるし、char*_tなライブラリも構築していけるし、
とりえあえずは問題ないんじゃない?

>>423
utf-32が扱える処理系では、
wchar_tが2 byteだと規格違反だけどね。

>Type wchar_t is a distinct type whose values can represent distinct codes for all members
>of the largest extended character set specified among the supported locales (22.1.1).

425 ：デフォルトの名無しさん：2007/06/03(日) 01:32:30

なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。

426 ：デフォルトの名無しさん：2007/06/03(日) 02:03:02

wchar_tがUnicodeじゃない処理系ってあるのかな？

427 ：デフォルトの名無しさん：2007/06/03(日) 02:10:30

>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?

428 ：デフォルトの名無しさん：2007/06/03(日) 04:26:58

GCC 4.3にC++0xの実験的サポート
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

429 ：デフォルトの名無しさん：2007/06/03(日) 04:55:14

>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。

@todo Implement this function.
@todo Document this function.
だらけだった。

430 ：デフォルトの名無しさん：2007/06/03(日) 05:36:10

431 ：デフォルトの名無しさん：2007/06/04(月) 22:53:08

MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。

432 ：デフォルトの名無しさん：2007/06/05(火) 01:37:14

C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。

433 ：デフォルトの名無しさん：2007/06/05(火) 22:01:36

久しぶりにスレ伸びたな～

434 ：デフォルトの名無しさん：2007/06/05(火) 23:26:19

まあ全部俺の一人芝居なんだけどな

435 ：デフォルトの名無しさん：2007/06/06(水) 01:57:38

同感

436 ：デフォルトの名無しさん：2007/06/06(水) 10:51:13

全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。

437 ：デフォルトの名無しさん：2007/06/06(水) 12:41:13

それがまさに独り芝居というものでは？

438 ：デフォルトの名無しさん：2007/06/06(水) 13:20:54

自問自答++

439 ：デフォルトの名無しさん：2007/06/06(水) 14:47:48

そうか、僕はここにいてもいいんだ！

440 ：デフォルトの名無しさん：2007/06/06(水) 16:22:24

おめでとう

441 ：デフォルトの名無しさん：2007/06/06(水) 16:54:37

>>431-432
まあでもC++0xに全く無関心でない様子は伺える
http://blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx

442 ：デフォルトの名無しさん：2007/06/06(水) 17:40:42

そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。

443 ：デフォルトの名無しさん：2007/06/06(水) 17:56:40

struct S {

　　int m;
};

sizeof(S::m)

これが規格外だったなんて知らなかった。
そういえばこれは合法になるのかな？

template < typename T >
class Foo
{
　　friend T ;
}

444 ：デフォルトの名無しさん：2007/06/06(水) 18:38:36

>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う

445 ：デフォルトの名無しさん：2007/06/06(水) 18:48:08

いや、C++0xではどうなるかという話なんだけど。

446 ：デフォルトの名無しさん：2007/06/06(水) 22:03:04

friend のはこれ？ (PDF)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf

447 ：デフォルトの名無しさん：2007/06/07(木) 03:54:58

443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる

448 ：デフォルトの名無しさん：2007/06/07(木) 05:25:03

sizeof(S().m)みたいに一時インスタンス化すればおｋ？

449 ：デフォルトの名無しさん：2007/06/08(金) 12:09:52

OKでしょ。

450 ：デフォルトの名無しさん：2007/06/17(日) 22:03:19

ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。

451 ：デフォルトの名無しさん：2007/06/17(日) 22:07:28

いっそUnicode str;を入れようぜ

452 ：デフォルトの名無しさん：2007/06/17(日) 22:57:31

>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。

453 ：デフォルトの名無しさん：2007/06/17(日) 22:58:22

>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下

454 ：デフォルトの名無しさん：2007/06/17(日) 23:00:08

じゃ、_Unicode str;

えーい、いっそのことソースコードもUTF8強制して

文字 str = L"こんちには世界";

って書けるようにしようぜ？

455 ：デフォルトの名無しさん：2007/06/17(日) 23:23:48

まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う

456 ：デフォルトの名無しさん：2007/06/17(日) 23:30:08

>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。

457 ：デフォルトの名無しさん：2007/06/17(日) 23:34:21

ワイドな文字ってよく考えると意味不明だよね

458 ：デフォルトの名無しさん：2007/06/17(日) 23:37:11

仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ

459 ：デフォルトの名無しさん：2007/06/17(日) 23:39:23

もうUTF8って名前に決めちゃえばいいよ

460 ：デフォルトの名無しさん：2007/06/18(月) 08:27:41

ちょっと上の話題ぐらい読もうや。

461 ：デフォルトの名無しさん：2007/06/18(月) 08:36:17

>>458
UTF-8はmbs、つまりchar[]だろ。

462 ：デフォルトの名無しさん：2007/06/18(月) 22:47:59

>>452
確かに、2Byte=WORDという意味でword char
をwcharとするなら、別に構わないが、wchat_tと
書くと、いかにも規格外で後からつけました感が
あって、気に入らんのだがねぇ。それより、
shortやlongといった元からあり、且つwordの様に
変数のサイズを2Byteとか具体的に意識させない型の方が、
自然な感じがするんだけどねぇ。

463 ：デフォルトの名無しさん：2007/06/18(月) 22:50:57

名前の衝突を避けるにはダサネーミングはある程度しかたない

_Boolとかunorderd_mapとかダサすぎるし

464 ：デフォルトの名無しさん：2007/06/18(月) 23:10:05

ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）

465 ：デフォルトの名無しさん：2007/06/18(月) 23:10:16

virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・

466 ：デフォルトの名無しさん：2007/06/18(月) 23:25:01

>>462
wchar_tのwは、wideでは？

467 ：デフォルトの名無しさん：2007/06/18(月) 23:47:46

>>450のshort charとか、long charとかで思い出したけど、
昔、整数型のshort (int) - int - long (int)からの連想で、
浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった

468 ：デフォルトの名無しさん：2007/06/19(火) 00:32:15

そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。

469 ：デフォルトの名無しさん：2007/06/19(火) 01:35:30

>>464
C++では予約語だが、Cではそうではない。

470 ：デフォルトの名無しさん：2007/06/19(火) 01:41:38

_Bool は仕方がないとは思うが失笑したな。

471 ：デフォルトの名無しさん：2007/06/19(火) 02:37:05

wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな

472 ：デフォルトの名無しさん：2007/06/19(火) 02:40:36

MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。

473 ：デフォルトの名無しさん：2007/06/19(火) 04:43:21

>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ

474 ：デフォルトの名無しさん：2007/06/19(火) 20:23:00

>>462
　そうだね勉強するよ。
　そういえば、1語長2語長なんて言葉もあったね。(敢えて言うが、
勿論1語長が1Byteなどと思っているわけではない。)
MSのAPIの影響(DWORDとかQWORDとか)でWORDを2byteと仮定して書いてしまった。
　あと、wchar_tはwide charなのにword charと書いたのは、素で間違えた。

　それはそうと、C++0xが実現するとObjective-C++やC++/CLIはどうなるんだ
ろうねぇ。三者三様の完全別言語路線に進むのか？0xに合わせてそれぞれ拡張
するのはは厳しい気がするが。実装的に。

475 ：474：2007/06/19(火) 20:25:01

訂正

× >>464
○ >>473

自分を指して何やってんだが…。

476 ：474：2007/06/19(火) 20:29:41

また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。

477 ：デフォルトの名無しさん：2007/06/19(火) 20:30:02

もともとobj-cはC++とは全然別物だろうに

478 ：デフォルトの名無しさん：2007/06/19(火) 22:43:01

>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。

まぁ、あんまり気を落とすな。

479 ：デフォルトの名無しさん：2007/06/19(火) 22:58:22

gccがsizeof(wchar_t)==4でいいんだったっけ

480 ：デフォルトの名無しさん：2007/06/19(火) 23:51:09

-fshort_wchar フラグを指定したら 2 になるけどな。

481 ：デフォルトの名無しさん：2007/06/20(水) 02:58:24

>>474
C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。
しかし純然たる研究者だったはずの二人が、
どうしてC++/CLIに必死なのか良くワカランネ。
契約になんか書かれているのかな。

482 ：デフォルトの名無しさん：2007/06/20(水) 08:40:01

C++0x実現まであと9年もあるから大丈夫

483 ：デフォルトの名無しさん：2007/06/21(木) 22:32:37

>479
cygwin 上だと gcc でも 2。

484 ：デフォルトの名無しさん：2007/06/22(金) 01:24:22

今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。

亡くなって当然ｗ

485 ：デフォルトの名無しさん：2007/06/22(金) 01:24:48

>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・

486 ：デフォルトの名無しさん：2007/06/22(金) 01:44:27

後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?

487 ：デフォルトの名無しさん：2007/06/22(金) 22:10:11

え、VC の cl にだけど

488 ：デフォルトの名無しさん：2007/06/23(土) 10:46:35

マイクロソフトは規格への追従遅いじゃん。
メジャー番号が変わるまで延々放置って事がよくある。
スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。

489 ：デフォルトの名無しさん：2007/06/24(日) 21:02:05

C++1xに名前変えるか

490 ：デフォルトの名無しさん：2007/06/25(月) 06:03:52

何でこんなに時間掛かるんだろう？

491 ：デフォルトの名無しさん：2007/06/25(月) 09:41:11

やっつけでやられても困る。

492 ：デフォルトの名無しさん：2007/06/25(月) 13:37:16

>>490
天才のお前が傍観者だからだよ

493 ：デフォルトの名無しさん：2007/06/25(月) 17:37:29

Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。

494 ：デフォルトの名無しさん：2007/06/25(月) 19:56:26

>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。

495 ：デフォルトの名無しさん：2007/06/26(火) 03:02:50

News 2007-06-25: C++ Standard Core Language Issues List (Revision 48) is available
News 2007-06-25: The C++ Standard Library Issues List (Revision 49) is available

今までC++相談室に貼ってた JTC1/SC22/WG21 の更新情報は
今回からこっちに貼ることにしました。

496 ：デフォルトの名無しさん：2007/06/26(火) 03:12:13

C++X
の方が魚の骨っぽくて好き

497 ：デフォルトの名無しさん：2007/06/26(火) 13:38:12

もう規格なんてやめてBoost全部取り込んじゃえよ

498 ：デフォルトの名無しさん：2007/06/26(火) 17:06:10

それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う

499 ：デフォルトの名無しさん：2007/06/26(火) 17:57:38

古い Fortran みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。

500 ：デフォルトの名無しさん：2007/06/26(火) 18:18:06

C++はPL/Iを超える化け物言語になりつつあるな。

501 ：デフォルトの名無しさん：2007/06/26(火) 22:21:29

Javaほどじゃないけどな

502 ：デフォルトの名無しさん：2007/06/26(火) 22:24:57

は？

503 ：デフォルトの名無しさん：2007/06/26(火) 22:31:00

またジャバグラマか。

504 ：デフォルトの名無しさん：2007/06/26(火) 23:26:45

そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ

505 ：デフォルトの名無しさん：2007/06/26(火) 23:27:57

禿が死ぬまでには出来てると思うから気長に待つよ

506 ：デフォルトの名無しさん：2007/06/27(水) 03:44:26

なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話

507 ：デフォルトの名無しさん：2007/06/27(水) 09:25:40

>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…

…いや、的確か

508 ：デフォルトの名無しさん：2007/06/27(水) 09:29:07

PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー

あ、でも糞言語だったけどね
消えたし

509 ：デフォルトの名無しさん：2007/06/27(水) 09:58:55

他の言語は要らなくなるから、Programming Language/1。

510 ：デフォルトの名無しさん：2007/06/27(水) 10:33:28

その C++ と Objective-C を無理矢理繋げた変態言語の立場は。

511 ：デフォルトの名無しさん：2007/06/27(水) 22:21:53

お前ら頭良いんだからサッサと立派な規格でまとめてくれよ

512 ：デフォルトの名無しさん：2007/06/27(水) 22:24:43

よしきた

513 ：デフォルトの名無しさん：2007/06/27(水) 22:27:55

標準ヘッダファイル2chを追加

514 ：デフォルトの名無しさん：2007/06/27(水) 22:30:20

boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない

515 ：デフォルトの名無しさん：2007/06/27(水) 22:33:48

競争相手が無かったから

516 ：デフォルトの名無しさん：2007/06/27(水) 23:05:19

C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？

517 ：デフォルトの名無しさん：2007/06/27(水) 23:09:41

>JavaやLL言語のようなものはあっただろうか？

普通にあったんじゃない？

518 ：デフォルトの名無しさん：2007/06/27(水) 23:18:46

ねーよ。
C++の影響は計り知れない

519 ：デフォルトの名無しさん：2007/06/28(木) 01:15:28

cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。

520 ：デフォルトの名無しさん：2007/06/28(木) 01:34:50

その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。

521 ：デフォルトの名無しさん：2007/06/28(木) 09:02:38

勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。

522 ：デフォルトの名無しさん：2007/06/28(木) 09:09:11

C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。
こんなに人材が集まったことは今だかつてないんじゃないか?
C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。

523 ：デフォルトの名無しさん：2007/06/28(木) 12:08:12

C++ってマクロなんでしょ？

524 ：デフォルトの名無しさん：2007/06/28(木) 12:11:46

???

525 ：デフォルトの名無しさん：2007/06/28(木) 14:00:51

っ MFC

526 ：デフォルトの名無しさん：2007/06/28(木) 14:14:36

MFCとVC6は大量のC++挫折者を生み出しました

527 ：デフォルトの名無しさん：2007/06/28(木) 17:52:57

>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。

528 ：デフォルトの名無しさん：2007/06/28(木) 20:02:22

シェア90%のOSが推奨すれば広まって当然

529 ：デフォルトの名無しさん：2007/06/28(木) 21:26:08

じゃあこれからはドトネト天国だね

530 ：デフォルトの名無しさん：2007/06/28(木) 21:38:39

C#する気もしない気も～VMの性能にかかっているんだよ～

531 ：デフォルトの名無しさん：2007/06/28(木) 22:21:08

C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ

532 ：デフォルトの名無しさん：2007/06/28(木) 22:22:00

D が完成しさえすれば・・・。

533 ：デフォルトの名無しさん：2007/06/28(木) 22:50:37

ネイティブでGC無しというところが、
C++の強さにして弱み。

534 ：デフォルトの名無しさん：2007/06/28(木) 22:52:36

し、C++/CLIとかどうですか・・

535 ：デフォルトの名無しさん：2007/06/29(金) 00:03:58

Dもキメラ過ぎる

536 ：デフォルトの名無しさん：2007/06/29(金) 23:28:16

Dがもっとリッチに色々揃えば良いけど。

537 ：デフォルトの名無しさん：2007/06/29(金) 23:32:38

やっぱC++は最高だな

538 ：デフォルトの名無しさん：2007/06/30(土) 19:25:36

C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな

539 ：デフォルトの名無しさん：2007/06/30(土) 19:46:15

>533
でも委員会で GC の話してるみたいよ？

540 ：デフォルトの名無しさん：2007/06/30(土) 20:31:26

今のところHans Boehmの提案が最有力候補かな？

541 ：デフォルトの名無しさん：2007/06/30(土) 20:32:07

GC ねえ。
GC なしで組めるモードもあるんだよね？

542 ：デフォルトの名無しさん：2007/06/30(土) 21:19:39

C99に合わせたりはしないのかな。

543 ：デフォルトの名無しさん：2007/06/30(土) 21:37:25

>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ

544 ：デフォルトの名無しさん：2007/06/30(土) 22:30:57

>>542
だいたいのところは取り込まれてるみたい。

545 ：デフォルトの名無しさん：2007/07/01(日) 11:32:07

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-06-30: The 2007-06-pre-Toronto mailing is available

546 ：デフォルトの名無しさん：2007/07/01(日) 11:33:18

>>543
えーーー！

いくらなんでもそれは無くね？

547 ：546：2007/07/01(日) 11:34:11

勘違いしてた

「GCなしでも組める」事が必須条件なのね

ごめんなさい

548 ：デフォルトの名無しさん：2007/07/01(日) 11:51:16

C++的には、使わなければ余分なコストはかからないというのは必須だろ。

549 ：デフォルトの名無しさん：2007/07/01(日) 11:53:34

そこでGCCですよ

550 ：デフォルトの名無しさん：2007/07/01(日) 11:57:17

GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので

551 ：デフォルトの名無しさん：2007/07/01(日) 12:00:52

GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな

552 ：デフォルトの名無しさん：2007/07/01(日) 12:02:25

>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。

553 ：デフォルトの名無しさん：2007/07/01(日) 12:03:19

>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？

554 ：デフォルトの名無しさん：2007/07/01(日) 12:05:59

shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし

555 ：デフォルトの名無しさん：2007/07/01(日) 12:07:50

なんだよかたそういう対照性か。
まさかソースコード上の対照性を言っているのかと思って心配になった。

556 ：デフォルトの名無しさん：2007/07/01(日) 12:11:55

>>554
メモリ管理専用にしないと GC によるメリットなんて得られないんじゃない？
削除子なんか入れたら実行タイミングに完全な規格を定義しないといけないでしょ。

557 ：556：2007/07/01(日) 12:16:45

うーんもうちょっと調べ物してから言えばよかったかな。
あんまりはっきりしたこともいえないんで、スルー推奨。

558 ：デフォルトの名無しさん：2007/07/01(日) 12:17:46

超基本的な質問なんだけど

GCありの場合でも自動変数がスコープ抜けた時とかにデストラクタは呼ばれるの？
その場合、そのクラスがフリーストアへのポインタを持っていた場合、
クラスのインスタンス自体は破棄されるけど、参照されていたメモリは
GCの場合はすぐに回収されないってことになるの？

559 ：デフォルトの名無しさん：2007/07/01(日) 12:21:51

GCってオンオフするもんなの？
当方C++/CLIのイメージが強いもんで、C++0xでどうなるのかわからないんだけどさ。
^とgcnewみたいなものじゃまずいのかなぁ。

560 ：デフォルトの名無しさん：2007/07/01(日) 12:38:43

すみません
int a[] = new int[10];
int *b = new int[10];
みたいに確保したときって
delete a;
delete a[];
delete b;
delete b[];
それぞれ解放の仕方で動作おかしくなりますか？

561 ：デフォルトの名無しさん：2007/07/01(日) 12:45:19

>>560 スレ違い。こっち逝け→ http://pc11.2ch.net/test/read.cgi/tech/1182740506/

562 ：デフォルトの名無しさん：2007/07/01(日) 15:35:28

>>560
とりあえず Effective C++ でも買ってこい

563 ：デフォルトの名無しさん：2007/07/01(日) 23:47:23

>>545
今回はいつもよりちと早めだね
小技系だが、N2332 がはげしく欲しい

564 ：デフォルトの名無しさん：2007/07/02(月) 07:35:17

やっぱSL73だろ
http://gradeup.blog39.fc2.com/blog-entry-31.html

565 ：デフォルトの名無しさん：2007/07/02(月) 09:24:38

みんな好き勝手いいやがって……だれが実装すると思ってるんだ

566 ：デフォルトの名無しさん：2007/07/02(月) 12:50:56

>>563
make_*関数が要らなくなるのは確かに便利だな。

567 ：デフォルトの名無しさん：2007/08/07(火) 08:31:37

最近のSutterは完全にC++/CLI宣伝だな。
そういう契約なのかな…

568 ：デフォルトの名無しさん：2007/08/09(木) 21:18:40

最新のドラフトってこれでいいのかな？

# ISO/IEC 14882: Programming Language C++ - draft
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2315.pdf

569 ：デフォルトの名無しさん：2007/08/09(木) 21:27:04

今日付けでn2369が出たみたい。

570 ：デフォルトの名無しさん：2007/08/09(木) 22:45:56

今日付けw　何とタイムリーな。
こいつかな？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf

571 ：デフォルトの名無しさん：2007/08/09(木) 22:49:14

今日じゃないや、6日だ…

今月分のもろもろ。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-08

572 ：デフォルトの名無しさん：2007/08/09(木) 23:50:33

decltype 追加か。細かい仕様はともかく、追加は確定なのかな。
あと alignas, alignof, constexpr も追加。
そして、char16_t, char32_t も追加？色は変わってないけど。

constexpr は D のコンパイル時実行みたいなもんか。
メタプロの世界がまた１つ広がりそうだな。

alignas と alignof は構造体のアラインメント関連か。
alignas で指定して、alignof で取得する、といったところか。

char16_t と char32_t は UTF-16 と UTF-32 用の char だっけ？
何か前に話題に出てたよね。

573 ：デフォルトの名無しさん：2007/08/10(金) 00:01:26

しかし、結構ドラスティックな変更が多いと思うけど、
こんなんがあと二年でまとまるんだろうか

574 ：デフォルトの名無しさん：2007/08/10(金) 00:10:12

constexprは制限が強すぎて見た目ほど強力じゃなかったはず

575 ：デフォルトの名無しさん：2007/08/10(金) 06:15:42

http://www.open-std.org/jtc1/sc22/wg21/
News 2007-08-09: The 2007-08-post-Toronto mailing is available
News 2007-08-09: C++ Standard Core Language Issues List (Revision 49) is available
News 2007-08-09: The C++ Standard Library Issues List (Revision 50) is available

576 ：デフォルトの名無しさん：2007/08/10(金) 09:46:56

FORTRESSに、禿の"Generalizing Operator for C++2000"風の演算子拡張があって、
気になって仕方がない。

577 ：デフォルトの名無しさん：2007/08/11(土) 06:43:14

= default と = delete がいまいち分かんないな。

= default はデフォルトで作られるメンバ関数を非 inline 化するためのもの・・・でいいのか？
いまいち使い道が分からんが。

= delete は関数を使えなくする・・・でいいのか？
こっちはまあ使い道あるだろうけど、
10.3p14 を見るに、基底クラスのメンバを殺すのには使えんのか？

578 ：デフォルトの名無しさん：2007/08/11(土) 08:08:25

うわあああ
もう予約語の使いまわしはやめてくれぇぇぇぇぇぇぇ
=0ですらキモすぎるのに=deleteとか=defaultとか

579 ：デフォルトの名無しさん：2007/08/11(土) 08:13:20

フフフ。そのキモさが C++ なのさ！

580 ：デフォルトの名無しさん：2007/08/11(土) 08:41:36

純粋仮想関数とかいいながら、構文が汚れてるよな

581 ：デフォルトの名無しさん：2007/08/11(土) 08:47:17

不純だわ

582 ：デフォルトの名無しさん：2007/08/11(土) 08:51:54

不接触の純粋さは当然のこと。
穢れに触れて、それでも尚純粋であることの方が素晴らしい。

583 ：デフォルトの名無しさん：2007/08/11(土) 09:01:36

それもこれもstaticが全ての始まりでした…

584 ：デフォルトの名無しさん：2007/08/11(土) 09:23:04

*じゃね？

585 ：デフォルトの名無しさん：2007/08/11(土) 09:24:11

& もなかなか

586 ：デフォルトの名無しさん：2007/08/11(土) 09:34:31

POD という表現がことごとく修正されてるのは、
やっぱ constexpr の影響？

587 ：デフォルトの名無しさん：2007/08/23(木) 18:52:57

>>577
デフォルトのコピーコンストラクタはビットコピーする。
だから、単純なコピーで済むクラスなら書かなくていい。
しかし宣言すら存在しないのは、
プログラマがクラスのコピーについて何も言及していないようで、
必要がなくて書かなかったのか、書き忘れてるのか分からない。
じゃあコメントで言及？
それは美学がない。
そういう訳で、=defaultを使う。

588 ：デフォルトの名無しさん：2007/08/23(木) 19:01:10

defaultをわざわざ指定するというのも可笑しい

589 ：デフォルトの名無しさん：2007/08/23(木) 19:02:33

default constructorをprivate宣言してというIDEOMともおさらばか。

590 ：デフォルトの名無しさん：2007/08/23(木) 19:04:07

.hと.cppを分けて書かせるのはいつになったらやめてくれるんだ

591 ：デフォルトの名無しさん：2007/08/23(木) 19:17:14

.hだけ書いて.cppの骨組みは自動生成するようにして、
関数の中身にタグジャンプとかすれば大して気にならんと思うけど

592 ：デフォルトの名無しさん：2007/08/23(木) 19:22:48

そんなん冗長にして無駄そのものじゃないか
現役言語でそんなことやってるのC++だけだぜ
存在することのメリットが一つもない

593 ：デフォルトの名無しさん：2007/08/23(木) 19:38:14

inline指定できないほど長い関数はアンチパターンだ
というのが委員会の非公式な見解（うそ）

594 ：デフォルトの名無しさん：2007/08/23(木) 19:47:39

.hを自動生成するg++へのpatch誰か作れ

595 ：デフォルトの名無しさん：2007/08/23(木) 19:49:23

>590
全部テンプレートで解決

596 ：デフォルトの名無しさん：2007/08/23(木) 19:52:47

>>587
= default は inline 化されないと書いてあるんだけど、
inline と = default の同時指定とかできるのかな？
同時指定できるならその目的に使えるとは思うけど。

597 ：デフォルトの名無しさん：2007/08/23(木) 20:01:59

ダメって書いてないから、出来るんじゃないの。
宣言は明示的だけど、実装はdefaultってのが、= defaultだから、
勝手にinline宣言したことにもしないって流儀じゃないかな。

598 ：デフォルトの名無しさん：2007/08/23(木) 20:33:39

.hが更新されてるかどうかで再コンパイルするかどうか決めるっていう
仕組みが前提だから.hが必要なんだろ
誰がこんなアホな仕組みにしたんだ

599 ：デフォルトの名無しさん：2007/08/23(木) 21:31:34

>>597
なるほど。それなら使い道あるやね。
protected にするとか使えそう。

600 ：デフォルトの名無しさん：2007/08/23(木) 22:13:27

>>598
それは別に問題ないよ。
.hを自動生成すればいいだけの話。

Javaは.classが.o(.obj)と.hを兼ねているけど、
あれはbyte codeだから.oサイドも共通にできる。
C++で.cpp, .h, .oに分かれているのは自然。

601 ：デフォルトの名無しさん：2007/08/23(木) 22:15:03

D とか .h と .d とに分かれてないけど

602 ：デフォルトの名無しさん：2007/08/23(木) 22:25:43

しかし.hが内容同じでも更新時間が変わってたら
再コンパイルされちまうぞ

603 ：デフォルトの名無しさん：2007/08/23(木) 22:31:54

それはC++0xの言語仕様じゃなくて、処理系の問題。

604 ：デフォルトの名無しさん：2007/08/23(木) 22:33:36

細かく差分みてコンパイルしてくれるような開発環境が必要だな

605 ：デフォルトの名無しさん：2007/08/23(木) 22:38:58

UMLでクラス図を書く→スケルトンとテストケース、make生成→あとは.cpp埋めてくだけ
ってのが欲しい

606 ：デフォルトの名無しさん：2007/08/23(木) 22:45:15

それはヘッダを生成するさいに、一時ファイル経由でdiffでもとって、
変更がなければ上書きしなければよいのでは

607 ：デフォルトの名無しさん：2007/08/23(木) 23:02:32

誰かヘッダ生成ツール作ってくれえ

608 ：デフォルトの名無しさん：2007/08/23(木) 23:08:19

欲しいと思ったときがプログラミング時です

609 ：デフォルトの名無しさん：2007/08/23(木) 23:08:59

いいこと言うなあ

610 ：デフォルトの名無しさん：2007/08/23(木) 23:16:44

たしかVC++もGCCもプロトタイプ生成の機能は持っているはず。
関数・変数だけだったらヘッダ生成に使えるだろうけど。

611 ：デフォルトの名無しさん：2007/08/23(木) 23:19:44

Cの現状はCとの互換性のためだからしょーがないだろ
C99があさっての方にいっちゃったけど、今更捨てる気もないだろし

612 ：デフォルトの名無しさん：2007/08/23(木) 23:20:27

C99でCﾊｼﾞﾏﾀと思ったのは俺だけじゃないはず

613 ：デフォルトの名無しさん：2007/08/23(木) 23:22:08

Cなんて代物を使うのは移植性と過去のしがらみのためだけで、
それ気にする必要も無いんならC++使うよ

C99なんて使いどころが全然無い

614 ：デフォルトの名無しさん：2007/08/23(木) 23:37:46

いいこと言うなあ

615 ：デフォルトの名無しさん：2007/08/23(木) 23:46:16

ObjC厨の俺に喧嘩売ってんのか

616 ：デフォルトの名無しさん：2007/08/23(木) 23:51:37

Objected-Cは今後どうなるの？

617 ：デフォルトの名無しさん：2007/08/23(木) 23:57:42

どうにもならないだろうな

618 ：デフォルトの名無しさん：2007/08/24(金) 00:03:12

Objected-Cってなんだよｗ

619 ：デフォルトの名無しさん：2007/08/24(金) 00:04:46

これから始めれば無問題

620 ：デフォルトの名無しさん：2007/08/24(金) 01:17:02

>>600
dはコンパイル時に.hに相当するものを生成するオプションがある
ライブラリ作成時には必須

621 ：デフォルトの名無しさん：2007/08/24(金) 02:13:11

つーか.hは.cppから生成しないと最適化に必要な情報をぼんぼん取りこぼすと思うけどなあ
だからって最適化のためにいちいちinline展開しなきゃいけないというのもおかしな話だし

622 ：デフォルトの名無しさん：2007/08/24(金) 02:29:04

クラスの定義もcppに書くのかい？

623 ：デフォルトの名無しさん：2007/08/24(金) 02:42:36

>>587
デフォルトのコピーコンストラクタは各基底クラスと各データメンバのコピーコンストラクタを
使う。ビットコピーじゃないよ。

624 ：デフォルトの名無しさん：2007/08/24(金) 02:46:17

つーか、IDE 使うんなら .h と .cpp というファイルを直接編集するんじゃなくて、
もっと抽象的な形で編集できていいと思うんだよ。

625 ：デフォルトの名無しさん：2007/08/24(金) 03:13:45

>>624
その「抽象的な形」で書くってことは、つまり C++ ではない別の言語を使うということに
なるのではないかな。

626 ：デフォルトの名無しさん：2007/08/24(金) 07:12:43

俺の書くクラスは、.hppのクラス定義の中に全てのメンバー関数定義がある。
inline指定ない関数も、毎回コンパイルされているが、気にしない。
.cppも.hもない。

627 ：デフォルトの名無しさん：2007/08/24(金) 08:24:18

export template を使っておりますよ

628 ：デフォルトの名無しさん：2007/08/24(金) 09:51:35

hppに書いたらinlineと書かなくてもinline展開しようとする、と
言語仕様で決まってるんじゃなかったっけ
hppに書いたらinline展開するか、再コンパイルするかなど
コンパイラがよきにはからう、という言語仕様にしてれば
今頃は誰も分割なんかしてないだろう

629 ：デフォルトの名無しさん：2007/08/24(金) 09:56:39

>>628
> hppに書いたらinlineと書かなくてもinline展開しようとする

クラス定義内の関数定義は、暗黙のinline宣言だね。

> inline展開するか、再コンパイルするかなど
> コンパイラがよきにはからう、という言語仕様にしてれば

そういう仕様だよ。inline宣言はコンパイラに対するヒントに過ぎない。
"prefered"ではあるんだけれど。

630 ：デフォルトの名無しさん：2007/08/24(金) 09:57:14

inlineを指定しなくても指定したかのように扱われるのは、
メンバ関数の定義をクラス定義内に書いたらの話。

631 ：デフォルトの名無しさん：2007/08/24(金) 10:15:36

しかしhppに全部書いたら関数に変更加えるだけで
依存するクラス全部再コンパイルされて、
それに依存するクラスも全部再コンパイルされて・・・
となってほぼ全クラス再コンパイルされちまうよな
なんでこんな糞仕様なんだ

632 ：デフォルトの名無しさん：2007/08/24(金) 10:20:36

>>631
Visual C++の簡易リビルドは、そういうときに
再コンパイルをしなくていいものはしないという機能ではないか？
仕様がアレでもコンパイラが頑張るとそんなこともできるという話。

633 ：デフォルトの名無しさん：2007/08/24(金) 10:32:04

>>631
つ pimpl

634 ：デフォルトの名無しさん：2007/08/24(金) 10:51:23

こうなったら
inline = default
も追加だ

635 ：デフォルトの名無しさん：2007/08/24(金) 10:54:29

>>633
pimplは.hと.cppをがっつり分けてもなお依存性がやばいことになるという
C++の仕様に対する対策じゃん
ポインタ越しの関数もinline展開されたらまるで対抗できない

>>632
簡易リビルドを指定すれば.hと.cppを分けなくてもいいという話は聞いたことがないぜ
.hが変更されていても再コンパイルする必要がない場合は有効だろうけど
inline展開されてたらどうしたって再コンパイルしなきゃならなくなるし
まあデバッグビルドならinline展開されないだろうから大丈夫なのかな

636 ：デフォルトの名無しさん：2007/08/24(金) 11:03:51

gccにもプリコンパイルドヘッダはありますが。

637 ：デフォルトの名無しさん：2007/08/24(金) 11:05:41

簡易リビルドは、ヘッダが変更されていても、
変更された部分に依存していなければ再コンパイルする必要がない場合を
うまく見分ける機能じゃないの？
gccにそんなんあるかい

638 ：デフォルトの名無しさん：2007/08/24(金) 11:29:08

>>635
> ポインタ越しの関数もinline展開されたらまるで対抗できない

ｵｲｵｲw

639 ：デフォルトの名無しさん：2007/08/24(金) 11:33:25

>>638
.hに実装を書いたらpimpl使ったって
virtualでない限り基本的にはinline展開されちまうだろ

640 ：デフォルトの名無しさん：2007/08/24(金) 17:32:10

いったいコンパイラは実装が別の翻訳単位にある
メソッドをどうやってインライン展開するというのだろうか。

641 ：デフォルトの名無しさん：2007/08/24(金) 17:33:08

リンク時にがんばればいい。

642 ：デフォルトの名無しさん：2007/08/24(金) 17:58:10

あれ、展開されないか
かなりおかしなことを言ってるな

643 ：デフォルトの名無しさん：2007/08/24(金) 18:46:25

>>640
cl.exe の /Og がまさにそれじゃなかったか？

644 ：デフォルトの名無しさん：2007/08/24(金) 18:51:29

そういえばVC++は最適化のために
.cppに書いてあるものも勝手にinline展開したりするんだよな

645 ：デフォルトの名無しさん：2007/08/24(金) 18:57:51

まあよくわからんけど、.hと.cppに分けないとpimplも使えないし
そもそも何もしなくてもデフォルトでpimplになってるべきだよな
その辺の仕様が古臭すぎる

646 ：デフォルトの名無しさん：2007/08/24(金) 19:24:17

>>644
gccもiccも当たり前のようにinline展開しますが何か。

647 ：デフォルトの名無しさん：2007/08/24(金) 19:30:47

毎日コンパイルしてテストせよという時代に
pimplなど笑止千万。

648 ：デフォルトの名無しさん：2007/08/24(金) 19:45:17

毎日コンパイルしてテストせなならんから
コンパイル速度を上げるpimplが必要なんだろ

649 ：デフォルトの名無しさん：2007/08/24(金) 19:59:58

>>647はpimplを何だと思ってるんだ？

650 ：デフォルトの名無しさん：2007/08/24(金) 20:04:01

にきび

651 ：デフォルトの名無しさん：2007/08/24(金) 20:04:26

>>644
それどころかDLL内の関数すらインライン展開できる。
http://msdn2.microsoft.com/ja-jp/library/feffc7b5(vs.80).aspx

652 ：デフォルトの名無しさん：2007/08/24(金) 22:12:58

VCの最適化能力は異常

653 ：デフォルトの名無しさん：2007/08/24(金) 22:27:32

>>639 がスルーされている件について

654 ：デフォルトの名無しさん：2007/08/24(金) 22:47:10

うまいことごまかしたと思ったんだが・・・

655 ：デフォルトの名無しさん：2007/08/24(金) 23:50:52

.cppが無理やりインライン展開されちまうんじゃ
.cppのちょっとした変更でも再コンパイルがわけわかんないとこまで広がりかねんな

656 ：デフォルトの名無しさん：2007/08/25(土) 00:15:18

そこでインライン展開は実行時JITに任せる方式が登場するわけです

657 ：デフォルトの名無しさん：2007/08/25(土) 00:43:06

おまえらここじゃなくて最適化スレを活用しろよ
0x++でそこらへんの仕様が変わるって言うなら別だが

658 ：デフォルトの名無しさん：2007/08/25(土) 00:53:15

そこらへんの仕様は変わらんのか
じゃあC++の今後には何の期待も出来んな

659 ：デフォルトの名無しさん：2007/08/25(土) 01:51:03

それはお前の勝手。

660 ：デフォルトの名無しさん：2007/08/25(土) 02:15:58

もっと声をあげていかなアカンと思うぜ
.hと.cppを分けなければならないのは冗長で腐った考え方だ
クロージャを導入する前にそこをまずなんとかしろ

テンプレートのメタプログラミングはわけわからんからまともなマクロを導入しろ
足元をまず見直せ

661 ：デフォルトの名無しさん：2007/08/25(土) 02:20:22

>>660
言語仕様を俺の頭の悪さに合わせろ！とはなんとも無茶な注文ですね

662 ：デフォルトの名無しさん：2007/08/25(土) 04:27:56

まじめな顔して書くが
>>660みたいなのはDやればと思ってしまう

663 ：デフォルトの名無しさん：2007/08/25(土) 08:25:25

そもそも規格自体は .h と .cpp をわけろとか一言も書いてないと思うけど...
標準のヘッダは .h というか拡張しなかったりするけど、それ以外は
プリプロセッサが処理したあとの話しか規定してないわけだし。

664 ：デフォルトの名無しさん：2007/08/25(土) 09:05:30

分けたくないなら全部.hに書けよ、一人で勝手にさぁ。

665 ：デフォルトの名無しさん：2007/08/25(土) 09:42:43

まあでも、ヘッダとcppファイル間の間には、
IDEの支援がもっとあってもいいと思う。

666 ：デフォルトの名無しさん：2007/08/25(土) 10:47:41

D言語はGCがあるからパフォーマンスが必要なプログラムが書けない
せっかくネイティブなのに

まあDelphi使えばいいんだけどな

667 ：デフォルトの名無しさん：2007/08/25(土) 10:51:29

.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
言語仕様で決まってるんだよスカタン
なんだこの糞仕様

668 ：デフォルトの名無しさん：2007/08/25(土) 10:54:09

＞.hに実装まで書いたらコンパイラは全部inline展開しようとする、と
妄想乙。

669 ：デフォルトの名無しさん：2007/08/25(土) 11:00:46

妄想じゃねー
暗黙 inline とかでぐぐれ

670 ：デフォルトの名無しさん：2007/08/25(土) 11:13:39

>>667は文章が下手。
「全部inline展開しようとする」は、
「全部必ずinline展開しようとする」、
「全部inline展開の考慮対象とする」のどちらにも読める。

671 ：デフォルトの名無しさん：2007/08/25(土) 11:27:38

>>670
どっちも同じ意味だろ
どっちも間違ってない

672 ：デフォルトの名無しさん：2007/08/25(土) 11:27:45

>>669
それはクラス定義内での関数定義の話ではないのか？

673 ：デフォルトの名無しさん：2007/08/25(土) 11:31:32

>>672
定義と宣言というのは正しい用語だがわかりにくいから
俺は.hに実装を書けばという言い方をする
.hの中でクラス定義と関数定義を分ける意味がないから普通は
クラス定義内の関数定義のことだと分かってもらえると思うが

674 ：デフォルトの名無しさん：2007/08/25(土) 11:35:31

>>673
こんなスレでそんなわかりにくさを気にするような奴はいないから、
そんな気を使う必要はないよ。

675 ：デフォルトの名無しさん：2007/08/25(土) 11:38:04

でも気遣う努力は素晴らしいことだよ、とフォロー。

676 ：デフォルトの名無しさん：2007/08/25(土) 11:58:39

>>673
> .hの中でクラス定義と関数定義を分ける意味がないから、普通は
> クラス定義内の関数定義のことだと分かってもらえると思うが
俺はごく短いもの以外、inlineさせたいメンバ関数は、.hの中で分けて書いてinline付けてるよ。
class hoge { }; のひとカタマリは、できるだけインターフェースの全容を一望しやすい形にしておきたいんで。
俺みたいな好みを持たない人でも、クラステンプレートがかなりでかいメンバ関数を持つことになって、
それを.hの中で分けて書いた、なんてことは何度もあるんじゃないかと思う。

つまり、「.hの中でクラス定義と関数定義を分ける」ことは、割とある。
だから「.hに実装を書く」という表現で、一気に「クラス定義部に実装を書くこと」まで限定した会話が
できると考えるのは、ちょっと行き過ぎなんじゃないかと思う。

・・・でもそれはそれとして、クラス定義内の強制inlineに対する気持ちはわかるｗ

677 ：デフォルトの名無しさん：2007/08/25(土) 12:28:02

outline とか追加されねーかなあ

678 ：デフォルトの名無しさん：2007/08/25(土) 12:29:20

7.1.2 Function specifiers

A function declaration with an inline specifier declares an inline function.

インライン指定を備えた関数宣言はインライン関数を宣言します。

The inline specifier indicates to the implementation
that inline substitution of the function body at
the point of call is to be preferred to
the usual function call mechanism.

インライン指定は、呼び出し位置の関数本体のインライン置換が
通常の関数呼び出し機構より優先されることを実装に示します。

An implementation is not required to perform
this inline substitution at the point of call;

実装は呼び出し位置でこのインライン置換を実行することは要求されません。

679 ：デフォルトの名無しさん：2007/08/25(土) 12:36:45

実装隠したければ・リンク互換性保ちたければ
pimpl使えってことじゃないのC++的には
ただのイディオムではなく言語的にもっとサポートがあると楽でいいんだがな
いつもいつもいちいち委譲のコードなんて書きたくないし

680 ：デフォルトの名無しさん：2007/08/25(土) 12:44:01

#includeなんてソースコードほんとに読み込むしな
原始的すぎる
Packageみたいなものをサポートする予定はないのかね

681 ：デフォルトの名無しさん：2007/08/25(土) 14:08:32

ヘッダでインクルードガードを検出したら同じ翻訳単位内では以後無視する最適化はしてあるよね
pImpl は extern と export で撲滅できるし

682 ：デフォルトの名無しさん：2007/08/25(土) 14:23:56

>>666
GC使わないこともできるよ。

683 ：デフォルトの名無しさん：2007/08/25(土) 14:24:42

インクルードガードも、たとえばVCの#pragma onceみたいなものを規格化すべきだと思っているんだけど、
必要ないのかな？

684 ：デフォルトの名無しさん：2007/08/25(土) 14:28:03

>>681
むしろexportのほうが撲滅されそうないきおいジャマイカ

685 ：デフォルトの名無しさん：2007/08/25(土) 14:29:14

インクルードの仕組み自体全部作り直せよ
ソースを置き換えるっていうこと自体問題が多すぎる
パッケージ内のクラス定義を一気に導入して
実際に使っているクラス定義にしか依存しない、という機能があればいい

686 ：デフォルトの名無しさん：2007/08/25(土) 14:30:19

>>685
Cとの互換性を捨てていいんならいくらでもやりようはあるだろうけど
今更それは出来んだろ

687 ：デフォルトの名無しさん：2007/08/25(土) 14:32:45

includeはincludeで残して、
packageというのを作ればいいんじゃね
これ導入したらincludeまで壊れるか？

688 ：デフォルトの名無しさん：2007/08/25(土) 14:33:46

ああ、includeも互換性のために残したままでシンボルテーブルをインポートする
新しい仕組みを作るのか
それならいいかもな

689 ：デフォルトの名無しさん：2007/08/25(土) 15:21:21

それはどこの .net f(ry

690 ：デフォルトの名無しさん：2007/08/25(土) 15:46:32

>>667 は inline 関数は全部 inline 展開されるとでも思ってるのかね。

691 ：デフォルトの名無しさん：2007/08/25(土) 15:59:32

「しようとする」という書き方を見て、「されるとでも思ってるのかね」もないもんだと思うがなぁ。

692 ：デフォルトの名無しさん：2007/08/25(土) 16:05:57

頭大丈夫か?

693 ：デフォルトの名無しさん：2007/08/25(土) 16:19:37

>>692
お前の頭の話なら、ダメかも。

694 ：デフォルトの名無しさん：2007/08/25(土) 16:51:25

>>684
export を使うとコンパイルの挙動が異様におもしろくなるので
コード書きのモチベーションに変化があったりなかっ…なくはない

695 ：デフォルトの名無しさん：2007/08/25(土) 17:20:34

なんでexportでpimplがいらなくなるんだ？

696 ：デフォルトの名無しさん：2007/08/25(土) 17:41:12

>>678
"to be preferred"を"優先される"は強すぎるだろ。
これこそ「しようとする」だ。

697 ：デフォルトの名無しさん：2007/08/25(土) 19:39:43

C++0xに関する映像出てるね
びょーんすっぽすっぽサマの声が聞けて嬉しす。

698 ：デフォルトの名無しさん：2007/08/25(土) 22:04:39

>>686
C++は既にCとの互換性を失っていますが

699 ：デフォルトの名無しさん：2007/08/25(土) 23:07:46

C++をおかしくした禿げのことか

700 ：デフォルトの名無しさん：2007/08/29(水) 02:32:45

これは良スレ

701 ：デフォルトの名無しさん：2007/08/29(水) 18:31:03

もうJavaっぽいGCなしのネイティブ言語つくろうぜ

702 ：デフォルトの名無しさん：2007/08/29(水) 18:34:46

Qtをさわった感じがそんなんだった。＞GC無しJava

703 ：デフォルトの名無しさん：2007/08/29(水) 18:45:41

字句解析つきマクロがあれば何でもできる。

704 ：デフォルトの名無しさん：2007/08/29(水) 19:49:27

そこでNemerleですよ

705 ：デフォルトの名無しさん：2007/08/29(水) 21:06:18

boostを作った変態たちにまともなマクロを与えたら
とんでもない言語を作ってくれると思うんだけどなあ
templateだけじゃやっぱ弱いよ

706 ：デフォルトの名無しさん：2007/08/29(水) 21:20:25

今のところ成功してるマクロはLispのものしかないな
「何でもできる」ってのはやっぱ危険だよ。

707 ：デフォルトの名無しさん：2007/08/29(水) 21:21:09

なんでも出来るのがC++の強みだよ

708 ：デフォルトの名無しさん：2007/08/29(水) 21:50:44

SASのマクロもかなり強力でかなり凶悪ですよ。
知っている人ほとんどいないと思うけど･･･

709 ：デフォルトの名無しさん：2007/08/29(水) 22:06:29

>>701
D言語に謝れ

710 ：デフォルトの名無しさん：2007/08/29(水) 22:54:57

実際組んでると auto が便利すぎてﾜﾗﾀなんだこれ

711 ：デフォルトの名無しさん：2007/08/29(水) 22:57:17

autoってなに？
typeof(hoge) var;のこと？

712 ：デフォルトの名無しさん：2007/08/29(水) 23:00:05

>711
多分同じことを指してるだろうが auto i = c.begin(); みたいに書いた方がわかりやすくないか？

713 ：デフォルトの名無しさん：2007/08/29(水) 23:01:57

暗黙的な型推論はC#3.0は本決まりでJavaは検討段階だっけかな

714 ：710：2007/08/29(水) 23:34:19

auto 仕様

※ PDF ! PDF !

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

715 ：デフォルトの名無しさん：2007/08/29(水) 23:40:21

記憶指定子のautoよさらば！
って感じだな。
で、ついでにデフォルトのintも廃止されるのかな。

716 ：デフォルトの名無しさん：2007/08/29(水) 23:41:31

デフォルトの int ってまだ有効なんだっけ？

717 ：デフォルトの名無しさん：2007/08/29(水) 23:49:25

少なくともISO C++98にはない。おそらくそれ以前になくなったはず。
ついでに言うとC99でもなくなった。

718 ：デフォルトの名無しさん：2007/08/30(木) 02:01:46

後生大事に auto を予約語に残しておいた甲斐があったなｗ

719 ：デフォルトの名無しさん：2007/08/30(木) 02:15:02

export…

720 ：デフォルトの名無しさん：2007/08/30(木) 09:53:48

C++ 0xを実験的に実装したコンパイラとかないのか

721 ：デフォルトの名無しさん：2007/08/30(木) 10:19:44

>>720
Comeauのv439β使ってる
コンパイラの実装制限による仕様抑制が全くないC++の開発効率の高さは異常

722 ：デフォルトの名無しさん：2007/08/30(木) 10:20:22

地味な変更に今更気づいたけど、
別のコンストラクタを呼ぶことができるようになったんだね。

struct C {
　C(int) { }
　C() : C(42) { }
};

723 ：デフォルトの名無しさん：2007/08/30(木) 10:20:59

Comeau ってことは、export が使えるやつか。いいなあ。

724 ：デフォルトの名無しさん：2007/08/30(木) 10:35:37

ConceptGCCもそれなりに0x実装しているんじゃないのかな

725 ：デフォルトの名無しさん：2007/08/30(木) 12:22:54

込め会うってどこで手にはいるの？

726 ：デフォルトの名無しさん：2007/08/30(木) 12:26:41

ここから買え→ http://www.comeaucomputing.com/

727 ：デフォルトの名無しさん：2007/08/30(木) 14:50:23

>>720 g++

728 ：デフォルトの名無しさん：2007/08/30(木) 23:32:23

補足。
ttp://gcc.gnu.org/gcc-4.3/cxx0x_status.html

729 ：デフォルトの名無しさん：2007/08/31(金) 00:01:53

>>726
下の方でチラチラしてるやつ胡散くせーなぁｗ

730 ：デフォルトの名無しさん：2007/08/31(金) 09:03:54

0xには結局GCは入るの？

731 ：デフォルトの名無しさん：2007/08/31(金) 09:30:59

gcnew

732 ：デフォルトの名無しさん：2007/08/31(金) 21:32:29

GCCでもexport使えるようにならんのかなぁ

733 ：デフォルトの名無しさん：2007/08/31(金) 22:32:47

>>726
広告ｳｻﾞｽｗｗｗｗｗ
どこぞのエロサイトかと

734 ：デフォルトの名無しさん：2007/08/31(金) 22:38:57

export早く消えねえかな

735 ：デフォルトの名無しさん：2007/08/31(金) 22:43:50

20年後位にautoみたいなすてきキーワードになって帰ってくるはずさ

736 ：デフォルトの名無しさん：2007/08/31(金) 23:23:33

たまにはregisterのことも思い出してやってください

737 ：デフォルトの名無しさん：2007/08/31(金) 23:31:22

完全に忘れてたｗ

738 ：デフォルトの名無しさん：2007/08/31(金) 23:43:15

覚えてるよ
しかし使ったのは４年くらい前が最後か

739 ：デフォルトの名無しさん：2007/08/31(金) 23:47:34

>>736
なつかしす。autoみたいに、いかす再利用法を考えてあげようぜ。

740 ：デフォルトの名無しさん：2007/08/31(金) 23:48:54

なんかregisterも、いつの日か再利用される日が来たりして。

741 ：デフォルトの名無しさん：2007/08/31(金) 23:50:22

単語の意味的に再利用する方法がおもいつかん…

autoは見事すぎる。現れる位置ももともとのautoに近いし

742 ：デフォルトの名無しさん：2007/09/01(土) 00:09:08

「登録する」とか系の意味で再利用できんかな

743 ：デフォルトの名無しさん：2007/09/01(土) 01:00:41

744 ：デフォルトの名無しさん：2007/09/01(土) 02:13:49

レジスタと同じ大きさの数値型とか。
intはCPU/OS依存ではなく処理系依存だしねぇ。

745 ：デフォルトの名無しさん：2007/09/01(土) 02:46:49

javaみたいに整数型のビット数は言語仕様で固定として、
浮動小数点数は strictfp で IEEE 仕様に変更できるとかがいいな。
その上でregisterが整数型として存在するならありがたい。

746 ：デフォルトの名無しさん：2007/09/01(土) 02:57:18

template引数でビット数とか浮動小数点の精度とか
数の特性を指定できるようにすりゃいいんだよ
型も作っちゃいますみたいな

747 ：デフォルトの名無しさん：2007/09/01(土) 03:48:58

>>743
分かって言ってるんだとは思うが、抵抗するはresist

748 ：デフォルトの名無しさん：2007/09/01(土) 04:01:33

re gist erをgoogle翻訳すると「再要点えー」

749 ：デフォルトの名無しさん：2007/09/01(土) 06:00:46

>745
strictfpって、遅くなる可能性がなかった？

750 ：デフォルトの名無しさん：2007/09/01(土) 10:28:48

不動小数点数の扱いを規格化作するから速度的にはね。
飽くまでCPUごとのFPUに依存したくないときに指定するものだし。

751 ：デフォルトの名無しさん：2007/09/01(土) 11:13:09

near,farが完全に忘れられてるんだが

752 ：デフォルトの名無しさん：2007/09/01(土) 11:17:20

DOSとその有害な子孫の16ビット処理系コンパイラにしか存在して無いだろ

753 ：デフォルトの名無しさん：2007/09/01(土) 11:19:42

ファーッ、こんな侮辱初めてだわ。

754 ：デフォルトの名無しさん：2007/09/01(土) 11:20:13

ニイヤー、それほどでもないよ。

755 ：デフォルトの名無しさん：2007/09/01(土) 12:26:44

美少女中学生のフラットなおっぱいの先端を仮想エクステンドさせで何度もコールするとにゃッとかふァァッとかいい声で鳴くわけですね

756 ：デフォルトの名無しさん：2007/09/01(土) 12:27:56

すごい勢いでクソスレ化している

757 ：デフォルトの名無しさん：2007/09/02(日) 09:01:11

near, far って既に規格から消去されてないか？

758 ：デフォルトの名無しさん：2007/09/02(日) 09:02:38

一度でも標準規格に載ったことがあったか？

759 ：デフォルトの名無しさん：2007/09/02(日) 09:06:26

もちろん参考扱いだったはずだが、
JIS X3014:2003を見ると、allocatorのところに、
farポインタ用のchar_traitsを定義する例が載っているんだ。

760 ：デフォルトの名無しさん：2007/09/02(日) 10:36:39

アロケータでnearとfarを隠蔽する試みって結局失敗したんじゃないか？

761 ：デフォルトの名無しさん：2007/09/02(日) 13:46:10

ISO/IEC 14882:2003 24.3.1.2

[Note: If there is an additional pointer type _ _far such that
the difference of two _ _far is of type long, an implementation may define

template<class T> struct iterator_traits<T _ _far*> {
　typedef long difference_type;
　typedef T value_type;
　typedef T _ _far* pointer;
　typedef T _ _far& reference;
　typedef random_access_iterator_tag iterator_category;
};

-end note]

762 ：デフォルトの名無しさん：2007/09/02(日) 14:10:30

C++0xって楽しそう！
使ってみたい！
あ

763 ：デフォルトの名無しさん：2007/09/02(日) 18:19:28

い

764 ：南米院 ◆QUsHlZHWHA ：2007/09/02(日) 21:45:39

う

765 ：デフォルトの名無しさん：2007/09/03(月) 04:08:08

766 ：デフォルトの名無しさん：2007/09/03(月) 09:05:16

オスマン・サンコンですぅ～

767 ：デフォルトの名無しさん：2007/09/03(月) 11:32:23

だまれ

768 ：デフォルトの名無しさん：2007/09/03(月) 12:18:21

>>762->>766
つあ
http://pc11.2ch.net/test/read.cgi/tech/1186388884/

769 ：768：2007/09/03(月) 12:22:31

あれっなんか変だ…
○>>762-768

770 ：768：2007/09/03(月) 12:25:34

×>>769
○>>762-766
スレ汚してすまそん逝ってきます…orz

771 ：デフォルトの名無しさん：2007/09/03(月) 12:31:07

急に盛り上がってると思ったらゴミレスか

772 ：デフォルトの名無しさん：2007/09/03(月) 22:32:34

もう俺C++ 0xで開発するわ
autoのない世界に戻れそうにない

773 ：デフォルトの名無しさん：2007/09/04(火) 19:25:48

C++03なら既に入手可能だな

774 ：デフォルトの名無しさん：2007/09/04(火) 20:42:51

03は98とほぼ同じ代物だし

775 ：デフォルトの名無しさん：2007/09/04(火) 20:45:22

C++2.0とか命名しなかったセンスは褒めたい

776 ：デフォルトの名無しさん：2007/09/04(火) 21:51:29

あんな風潮に迎合できるほど彼らの髪は残ってないからな。

777 ：デフォルトの名無しさん：2007/09/04(火) 21:54:46

777

778 ：デフォルトの名無しさん：2007/09/04(火) 21:56:09

どうせすぐにC++1xの策定準備に入るつもりだからだろう

779 ：デフォルトの名無しさん：2007/09/04(火) 22:00:49

アメ公ならx使ったら次は360とかにするかも

780 ：デフォルトの名無しさん：2007/09/04(火) 23:24:49

++C++

781 ：デフォルトの名無しさん：2007/09/05(水) 00:24:27

C++ 2008 XP Professional

782 ：デフォルトの名無しさん：2007/09/05(水) 01:06:04

C++ Home Edition

783 ：デフォルトの名無しさん：2007/09/05(水) 01:07:59

C++ Ultimate

784 ：デフォルトの名無しさん：2007/09/05(水) 02:56:47

C++ Orz

785 ：デフォルトの名無しさん：2007/09/05(水) 02:59:32

>>784
C++にひざまずいてるように見えるな

786 ：デフォルトの名無しさん：2007/09/05(水) 09:48:16

Wirth先生、PASCALがヒットしたのに(Turbo Pascalがあったからね)
気をよくして第２？３弾としてMODULA２を作ったけどさっぱりだった。

C++0xもほどほどで公開した方がいい。あんまりもったいぶると、いざ
公開されたときには｢こんなのイラネ｣と誰も使わないかもしれんぞ。

ご存知のように、言語とかライブラリとかは技術的に優れているから
受け入れられるかというと必ずしもそうではない。アメリカの某団体
が強く推奨するとか、マイクロソフトが採用する、とか運みたいな
ものがあるから。

787 ：デフォルトの名無しさん：2007/09/05(水) 09:54:05

↑
ageてる割に中身が無く、
誰に言ってるのかわからない文章

788 ：デフォルトの名無しさん：2007/09/05(水) 10:06:41

　　ﾋﾞﾖ～ﾝ
～（＾Д＾）～

789 ：デフォルトの名無しさん：2007/09/05(水) 10:08:20

>>786
Modula-3, Oberon, Oberon-2も知らないのね。

790 ：デフォルトの名無しさん：2007/09/05(水) 10:38:40

>>789
知らんでもいい。
Ada-95を知っていれば十分。

791 ：デフォルトの名無しさん：2007/09/05(水) 15:11:27

C--
C>>
C<<
C==
C||
C&&

792 ：デフォルトの名無しさん：2007/09/05(水) 15:47:19

C
C++
C+=2
C+=3

793 ：デフォルトの名無しさん：2007/09/05(水) 15:59:14

Dを先にとられちゃったのが痛いな

794 ：デフォルトの名無しさん：2007/09/05(水) 16:27:20

C Abnormal

795 ：デフォルトの名無しさん：2007/09/05(水) 16:30:18

>>793
「元祖D」とか「総本家D」で桶

796 ：デフォルトの名無しさん：2007/09/05(水) 16:47:29

はじめてのC

797 ：デフォルトの名無しさん：2007/09/05(水) 18:24:19

やればできるC
いきなりのC

798 ：デフォルトの名無しさん：2007/09/05(水) 18:25:49

それは入門書の名前だろ

799 ：デフォルトの名無しさん：2007/09/05(水) 20:48:47

HOW TO 本だろ

800 ：デフォルトの名無しさん：2007/09/05(水) 21:24:49

はうはううううう

801 ：デフォルトの名無しさん：2007/09/05(水) 22:36:25

頭文字C

802 ：デフォルトの名無しさん：2007/09/05(水) 22:57:43

--D

803 ：デフォルトの名無しさん：2007/09/05(水) 23:06:24

804 ：デフォルトの名無しさん：2007/09/05(水) 23:17:40

いつからC++の次期バージョンの名前を考えるスレに？

805 ：デフォルトの名無しさん：2007/09/05(水) 23:20:53

そろそろ、捨てるべきものを捨てて言語を整理するべき時期に来たんじゃないかな
だから、新しい名前が必要に・・・

806 ：デフォルトの名無しさん：2007/09/05(水) 23:24:12

もっとあぶないC++

807 ：デフォルトの名無しさん：2007/09/05(水) 23:49:05

C++フォーエヴァー TVスペシャル0x

808 ：デフォルトの名無しさん：2007/09/06(木) 00:17:09

C^2

809 ：デフォルトの名無しさん：2007/09/06(木) 09:19:00

JavaC++

810 ：デフォルトの名無しさん：2007/09/06(木) 10:42:56

C++ デンマークから愛をこめて
C++ C++は二度死ぬ
C++ わたしを愛したJava

811 ：デフォルトの名無しさん：2007/09/06(木) 12:34:26

愛をこぬて

812 ：デフォルトの名無しさん：2007/09/06(木) 12:55:55

C NEXT

813 ：デフォルトの名無しさん：2007/09/06(木) 18:11:21

After C

814 ：デフォルトの名無しさん：2007/09/06(木) 19:55:48

Alternate+C

815 ：デフォルトの名無しさん：2007/09/06(木) 20:13:50

CXX mkII

816 ：デフォルトの名無しさん：2007/09/06(木) 22:50:58

817 ：デフォルトの名無しさん：2007/09/06(木) 23:10:49

Cex

818 ：デフォルトの名無しさん：2007/09/07(金) 00:16:00

C++'s Counterattack

819 ：デフォルトの名無しさん：2007/09/07(金) 17:46:48

関数テンプレート構文がこんな感じに書けたら楽なのにな
auto func<int val>(auto arg) { return val * arg; }

820 ：デフォルトの名無しさん：2007/09/07(金) 18:43:45

それって
template <int val, typename T> T func(T arg) { return val * arg; };
だとなんかマズい？

821 ：デフォルトの名無しさん：2007/09/07(金) 18:46:31

あぁ、書き方の問題か。

822 ：デフォルトの名無しさん：2007/09/07(金) 22:04:11

>>819
それって、引数に与える型によって返値型がころころ変わるのがいやだなあ。

823 ：デフォルトの名無しさん：2007/09/07(金) 22:18:32

>>819
引数や返値にautoを使用したとすると、参照にしたい時とか面倒そうだなあ

824 ：デフォルトの名無しさん：2007/09/08(土) 00:08:47

きっと auto& を使うんだyo

825 ：auto：2007/09/08(土) 00:15:41

#include <auto.h>

int main()
{
auto ;//Do anything you want.
return 0 ;
}

826 ：デフォルトの名無しさん：2007/09/08(土) 00:16:50

>>822
template構文でも、こう書けば同様に戻り値の型が
ころころ変わることを表現できそう（実際これが可能かは知らない）。
template<int val, typename T>
decltype(val * T()) func(T arg);

Boost.Lambdaみたいなライブラリでは役に立つのかもしれないと思う。

827 ：デフォルトの名無しさん：2007/09/08(土) 19:16:25

auto func = <>(val) { <>(arg : val) { val * arg } };
auto func10 = func(10);

828 ：デフォルトの名無しさん：2007/09/08(土) 19:19:28

…というのはクロージャじゃないからダメかなやっぱ (N2329ね)

829 ：デフォルトの名無しさん：2007/09/08(土) 23:08:45

C++0xのコンパイラどこ？

830 ：デフォルトの名無しさん：2007/09/08(土) 23:12:37

ドクロが見つめる一本杉の根本に埋めてあるよ

831 ：デフォルトの名無しさん：2007/09/08(土) 23:18:24

>>830
ドラえもん乙

832 ：デフォルトの名無しさん：2007/09/09(日) 01:59:47

>>830
教えてくれてありがとう！

833 ：デフォルトの名無しさん：2007/09/09(日) 02:06:05

>>830
ぴぴるぴるぴる（略

834 ：デフォルトの名無しさん：2007/09/15(土) 10:51:47

9月分来てるね。

835 ：デフォルトの名無しさん：2007/09/19(水) 19:09:37

何が変わってる？

836 ：デフォルトの名無しさん：2007/09/20(木) 18:33:43

マルチメソッドなんて入るの？

837 ：デフォルトの名無しさん：2007/09/20(木) 21:59:39

C++に入れられない仕様など無い。

838 ：デフォルトの名無しさん：2007/09/20(木) 23:43:23

マルチメソッドって禿のお気に入りだったやつ？
D&Eでしつこいほどに言及してたけど。

839 ：デフォルトの名無しさん：2007/09/21(金) 08:45:21

>835
9 月分だと draft の変更はなし。concurrency 関連の paper が多め、といったところだと思う。

>826
簡単に T が Default constructible でなくても良く書く方法として
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
に、↓な書き方が提案されている。
template<int val, typename T>
auto func (T arg) -> decltype(val * arg);

840 ：デフォルトの名無しさん：2007/09/21(金) 08:52:53

正直Objective-C++0xに期待してまふ

841 ：デフォルトの名無しさん：2007/09/21(金) 12:34:23

げろげろ

842 ：デフォルトの名無しさん：2007/09/21(金) 15:30:53

俺はC++/CLI0xに期待だぜ

843 ：デフォルトの名無しさん：2007/09/21(金) 16:15:30

C++/CLI (笑)

844 ：デフォルトの名無しさん：2007/09/21(金) 16:26:56

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1978.pdf
を読んでて、ふと思ったんだけど 2.4.1 Variable and function names の所で
int foo(char);
decltype(&foo) // int(*)(char)
decltype(*&foo) // int(&)(char)
とグローバル関数については例が載ってるけど、メンバ関数については
class A {
int foo(char);
};
decltype(&A::foo) // int(Foo::*)(char)
と、メンバ関数ポインタについてのみ書いてある。
decltype(*&A::foo) // int(Foo::&)(char)
とかってのは駄目？

845 ：デフォルトの名無しさん：2007/09/21(金) 17:39:06

どんな型を持った変数に戻り値を入れるんだろうと
::&演算子?

846 ：デフォルトの名無しさん：2007/09/23(日) 06:58:20

あと2年半弱か..

847 ：デフォルトの名無しさん：2007/09/23(日) 08:24:34

やっぱり、2009年内に間に合わなかったら
そこからあと90年待つのかな。

848 ：デフォルトの名無しさん：2007/09/23(日) 10:34:44

>>844
現行のC++にもメンバへの参照はないな。

849 ：デフォルトの名無しさん：2007/09/23(日) 16:09:28

>>848
レスありがと。
そっか、別に必要と思う局面は思いつかないけど
なんで無いんだろうねぇ。

850 ：デフォルトの名無しさん：2007/09/23(日) 16:44:05

>>849
参照は必ず実体を指す、という制約がクラス継承によってさっくり破られるからな

851 ：デフォルトの名無しさん：2007/09/23(日) 18:48:13

>>850
おー！なるほど！
そういうことだったのか。
T& を T* const と思い込んでたから気付かなかったんだぜ。

852 ：デフォルトの名無しさん：2007/09/24(月) 14:39:56

C++0x　<-よーくみろ！これは数字じゃなくて16進定数のプレフィックスだ！
ってことは、ってことは！！

この動作は不定ってことだぁーーーーーーーーーーーー。

まさに外道。

853 ：デフォルトの名無しさん：2007/09/24(月) 14:49:53

C → C++ → C++0x → <<C++0x → <<C++0x() → <<C++0x(\->)

854 ：デフォルトの名無しさん：2007/09/24(月) 18:13:39

それなんて顔文字？

855 ：デフォルトの名無しさん：2007/09/25(火) 03:58:34

ほんとにC++09は間に合うのかね？
てか、g++は追従できるんだろうか・・・。

856 ：デフォルトの名無しさん：2007/09/25(火) 08:31:55

comeauならやってくれるさ

857 ：デフォルトの名無しさん：2007/09/25(火) 08:48:01

米屋ぁう

858 ：デフォルトの名無しさん：2007/09/25(火) 11:43:41

859 ：デフォルトの名無しさん：2007/09/25(火) 22:45:09

C++0x2009

860 ：デフォルトの名無しさん：2007/09/26(水) 12:27:55

>>859だと C+(+0x2009)になるのかな？

861 ：デフォルトの名無しさん：2007/09/27(木) 18:36:20

>>860

$ cat > a.cc
int main() {
int C = 0;
C++0x2009;
}
$ g++ a.cc
a.cc: In function `int main()':
a.cc:3: error: expected `;' before numeric constant
$ orz
bash: orz: command not found

862 ：デフォルトの名無しさん：2007/09/28(金) 00:31:01

VC8だとローカルクラスをテンプレートパラメータに渡せてしまったんだが、
これが標準になれば、lambda無くても良くね？

863 ：デフォルトの名無しさん：2007/09/28(金) 00:45:41

むしろローカル関数を

864 ：デフォルトの名無しさん：2007/09/28(金) 00:50:49

lambdaじゃなくて名前付きのローカル関数？

865 ：デフォルトの名無しさん：2007/09/28(金) 01:46:21

>>863
ローカルクラスのstaticメソッドで十分では。

866 ：デフォルトの名無しさん：2007/09/28(金) 02:07:00

>>865
めんどいしhackっぽいのが嫌じゃない？
クロージャも使えないし。

867 ：デフォルトの名無しさん：2007/09/28(金) 03:35:47

>>866
たしかに面倒というほかないが、
tr1::bindとstaticメソッドさえあればクロージャはできるよね。
まあ、lambda欲しいけど。

868 ：デフォルトの名無しさん：2007/09/28(金) 23:26:53

たのむ、0x0000_0000_0000って書ける様にしてくれ。64ビット時代になったらしむる。
そんな大それたお願いじゃないからさ

869 ：デフォルトの名無しさん：2007/09/29(土) 00:23:38

32進数を作ればいいじゃない

870 ：デフォルトの名無しさん：2007/09/29(土) 00:24:23

>>868
2進表記もほすい

871 ：デフォルトの名無しさん：2007/09/29(土) 01:27:17

template <unsigned long N>
struct Binary {
enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
enum { value = 0 };
};
で
Binary<1101>::value -> 13
あるいは
#define HEX_DIGIT_0000 0
#define HEX_DIGIT_0001 1
...
#define HEX_DIGIT_1111 f
#define HEX_DIGIT(a) HEX_DIGIT ## a

#define BINARY8H(a,b,c,d,e,f,g,h) (0x##a##b##c##d##e##f##g##h)
#define BINARY8I(a,b,c,d,e,f,g,h) BINARY8H(a,b,c,d,e,f,g,h)
#define BINARY8(a,b,c,d,e,f,g,h) BINARY8I(HEX_DIGIT(a), HEX_DIGIT(b), ..., HEX_DIGIT(h))
で
BINARY8(1010,0101,1010,0101,1010,0101,1010,0101) -> 0xa5a5a5a5

872 ：デフォルトの名無しさん：2007/09/29(土) 13:56:24

typeofはどうなるんだ

873 ：デフォルトの名無しさん：2007/09/29(土) 16:47:09

decltype が入るジャン？

874 ：デフォルトの名無しさん：2007/09/29(土) 19:23:05

どうせなら好きな基数で数を書けるようにして欲しい
3進法や5進法が欲しくなることもたまにあるし

875 ：デフォルトの名無しさん：2007/09/29(土) 20:01:52

アンダースコアによる数値の書式整理は欲しいね。Python がうらやましい

876 ：デフォルトの名無しさん：2007/09/30(日) 07:30:05

>>875
Pythonにアンスコ区切りないよ？
バイナリリテラルはあるかも知れないが

877 ：デフォルトの名無しさん：2007/09/30(日) 09:51:09

人気者のPythonがうらやましす

878 ：デフォルトの名無しさん：2007/09/30(日) 12:08:03

>876
あれ。違ったか。ごめん。ずっと Python だと覚えてた
12_000_000 って数値の書式を整理できるﾔｼ

879 ：デフォルトの名無しさん：2007/09/30(日) 12:46:51

_区切りは慣れると手放しがたくて困る。

880 ：デフォルトの名無しさん：2007/09/30(日) 14:33:48

perlは_区切りできる。
perlで出きるのを見てて、Cでも出来るものと勘違いしてたよ。
あると読みやすいね。

881 ：デフォルトの名無しさん：2007/09/30(日) 14:37:18

64bitが主流になったら検討されるかな

int64_t hoge = 0xFFFFFFFFFFFFFFFF;

とか書きたくないな

882 ：デフォルトの名無しさん：2007/09/30(日) 14:46:06

昔ながらのMAKEWORDの類のマクロまたはインライン関数でいいんじゃねぇの？
コンパイル時に定数として埋め込まれるでしょ

883 ：デフォルトの名無しさん：2007/09/30(日) 15:27:06

アンスコを数値に追加してパース時に読み飛ばしてくれるだけで対応できるんだけど
こういうちょっと便利な内容っていつでもできるからって議題に上がらなくて
結局、入らないんだよね

int64_t max_value = 3_764_000_000;
int64_t max_value = UNDERSCOUT_FORMAT(3_764_000_000);

可読性がぜんぜん違うっしょ

884 ：デフォルトの名無しさん：2007/09/30(日) 17:42:05

>>881
int64_t hoge = ~0;

885 ：デフォルトの名無しさん：2007/09/30(日) 17:46:30

>>871
ごめん。スレ違いだけどちょっと気になって・・・

template <bool B> struct static_assert;
template <> struct static_assert<true> {};

template <unsigned long N>
struct Binary {
static_assert<N % 10 == 0 || N % 10 == 1> illegal_bin_digit_found;
enum { value = (Binary<N / 10>::value << 1) + N % 10 };
};
template <>
struct Binary<0> {
enum { value = 0 };
};

886 ：デフォルトの名無しさん：2007/09/30(日) 18:50:56

>>871
Binary<0101>::value で static_assert 失敗するのはダメだろ。

887 ：デフォルトの名無しさん：2007/09/30(日) 19:07:45

>>886
8進数になるから無視していいのでは。

888 ：デフォルトの名無しさん：2007/09/30(日) 22:53:01

数値のカンマ区切りならoperator orverloadで現行でも何とかなりそうとか思ってみたりみなかったり

889 ：デフォルトの名無しさん：2007/09/30(日) 23:20:19

英語力に自信のある人、ドラフト投げてみてくれ。
今を逃すとc++1x送りになるだろし。

890 ：デフォルトの名無しさん：2007/09/30(日) 23:58:34

>>888
そりゃ難しくないかい？俺の頭では無理っぽい。
だって、何桁目のカンマか識別できないもん・・・(´・ω・｀)

891 ：デフォルトの名無しさん：2007/10/01(月) 00:00:56

return rhs*1000+lhs; すりゃいいわけだから、識別しなくていいんじゃね？

892 ：デフォルトの名無しさん：2007/10/01(月) 00:02:11

実行時評価ｗ

893 ：デフォルトの名無しさん：2007/10/01(月) 00:02:40

こういうのって可読性の問題だから「俺様定義すれば可能」より「標準の機能」であることが
好ましいように思うな。でも何十年も拒否してきた機能を今さら入れるだろうか？

894 ：デフォルトの名無しさん：2007/10/01(月) 00:03:46

>>891
lhsとrhsが逆じゃね？（普通の習慣では）

895 ：デフォルトの名無しさん：2007/10/01(月) 00:03:57

いま>>892がいいことを言った。

896 ：デフォルトの名無しさん：2007/10/01(月) 00:06:31

演算子オーバーロードってユーザ定義型じゃないとだめじゃん

897 ：デフォルトの名無しさん：2007/10/01(月) 00:18:29

orepp → cpp → cc → ar
これで解決
流用できないのでGPLも怖くないｗｗｗ

898 ：デフォルトの名無しさん：2007/10/01(月) 00:23:07

そんなQtみたいなソルーションは断る。

899 ：デフォルトの名無しさん：2007/10/01(月) 00:23:37

誰が使うの？

900 ：デフォルトの名無しさん：2007/10/01(月) 00:37:02

しゃーねーなぁ。一丁ドラフトでも書いてみるか。
0b10101010 とか 0xAA_BB_CC_DD とか 1,024 とか。

901 ：デフォルトの名無しさん：2007/10/01(月) 00:39:22

俺の英語力を駆使してみた。
I want to use >>900.

902 ：デフォルトの名無しさん：2007/10/01(月) 00:44:00

0bはすでに脚下済では？

903 ：デフォルトの名無しさん：2007/10/01(月) 00:46:59

>901
お前頭いいなぁ

904 ：デフォルトの名無しさん：2007/10/01(月) 00:50:41

0bは滅びぬ。何度でも蘇るさ。

905 ：デフォルトの名無しさん：2007/10/01(月) 01:07:50

こりゃ次スレが必要だね。

906 ：デフォルトの名無しさん：2007/10/01(月) 01:13:41

>>885
このstatic assert頭よくね？
コンパイルタイムでなくリンクタイムの失敗になるだろうけど。

907 ：デフォルトの名無しさん：2007/10/01(月) 01:23:41

>>906
コンパイルタイムに弾くよ。
だって、static_assert<false> は未定義になるから、
illegal_bin_digit_found のサイズがわからーんってなるもん。

908 ：デフォルトの名無しさん：2007/10/01(月) 01:24:09

>>906
失敗したらコンパイルエラーで止まるよ。

909 ：デフォルトの名無しさん：2007/10/01(月) 01:26:13

勘違い。ごめん。
boostのはもちっと複雑だよね？boostのも同じ原理だっけ?

910 ：デフォルトの名無しさん：2007/10/01(月) 08:24:02

>>900
>1,024

既存プログラムに非互換が出るから駄目だと思う。

911 ：デフォルトの名無しさん：2007/10/01(月) 08:33:10

0-Fを見て0000-1111が浮かばないのか？

912 ：デフォルトの名無しさん：2007/10/01(月) 08:46:56

だったら下線や空白なら平気ではないのか？

913 ：デフォルトの名無しさん：2007/10/01(月) 12:05:06

dead_beefという変数に誤爆する可能性はないか？いや、無いか

914 ：デフォルトの名無しさん：2007/10/01(月) 14:42:09

やべ、牛肉供給日の beef_feed も誤爆？いや、無いか

915 ：デフォルトの名無しさん：2007/10/01(月) 14:47:59

0xを先行させるルールを忘れたもうな。

916 ：デフォルトの名無しさん：2007/10/01(月) 15:04:47

(0x0)

917 ：デフォルトの名無しさん：2007/10/01(月) 15:11:13

XCは0b出来たよな、記憶違いか…？

918 ：デフォルトの名無しさん：2007/10/01(月) 15:13:34

独自に 0b をサポートしてるコンパイラは多い

919 ：デフォルトの名無しさん：2007/10/01(月) 16:06:56

$ cat > a.cc
int i = 0b1010;
$ g++ -c a.cc
a.cc:1:9: invalid suffix "b1010" on integer constant
$ orz
bash: orz: command not found

920 ：デフォルトの名無しさん：2007/10/01(月) 17:29:43

俺が慰めてやるよ

orz.c

#include <stdio.h>
main(){
printf("まあまあ\n");
}

コンパイルして使ってくれ。

921 ：デフォルトの名無しさん：2007/10/01(月) 17:32:17

↓mainの戻り値云々

922 ：デフォルトの名無しさん：2007/10/01(月) 17:33:41

こまけーこというなよ

923 ：919：2007/10/01(月) 17:34:25

>>920
(TдT)ｱﾘｶﾞﾄｳ

924 ：デフォルトの名無しさん：2007/10/01(月) 17:41:28

$ cat > orz.cc
#include <iostream>
int main() {
std::cout << "orz===3 ﾌﾟｽｰ" << std::endl;
}
$ g++ -o orz orz.cc
$ orz
orz===3 ﾌﾟｽｰ
$ w
17:39:23 up 25 days, 23:16, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
yy tty1 - 17:40 0.00s 0.09s 0.01s w

925 ：デフォルトの名無しさん：2007/10/01(月) 17:45:42

>>921
orzの戻り値に依存してコード組んだら文字通りorzな結果になるんだから、
それはそれでいい。

926 ：デフォルトの名無しさん：2007/10/01(月) 18:03:04

そろそろ次スレのことも視野に入れることが必要にもかかわらず
だんだんと低俗になってゆく悪寒。

927 ：デフォルトの名無しさん：2007/10/01(月) 18:06:08

alias orz="echo '(´･ω･｀)'"

928 ：デフォルトの名無しさん：2007/10/01(月) 18:28:25

>>919
ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479

929 ：デフォルトの名無しさん：2007/10/01(月) 21:12:13

>>928
情報ありが豚。

930 ：デフォルトの名無しさん：2007/10/01(月) 21:43:54

リトルエンディアンとビッグエンディアンで二通りのルール作っていいから、
ビットフィールドの上がLSBって規格にしてくれないかな。

ビットフィールドに限らないけど、構造体で新しいメンバを下に書き足したら、
既存のメンバの位置がずれるなんて馬鹿かと。（そんなのに依存する書き方を
するなとか言うのはまた今度。言語としてルールが決まってても困らんだろうし）

931 ：デフォルトの名無しさん：2007/10/02(火) 02:08:13

最適化の機会を奪うな！なーんてな。

932 ：デフォルトの名無しさん：2007/10/02(火) 02:50:04

メンバポインタ使えばいいのに

933 ：デフォルトの名無しさん：2007/10/02(火) 04:08:44

残念ながら世の中にはリトルでもビッグでもない変態エンディアンのアーキテクチャが存在します

934 ：デフォルトの名無しさん：2007/10/02(火) 06:07:59

ttp://ml.tietew.jp/cppll/cppll/article/12789
こういうのかw
これは正直ワロタ

935 ：デフォルトの名無しさん：2007/10/02(火) 08:04:39

>>930
やれやれ
初心者スレ行ってくれ

936 ：デフォルトの名無しさん：2007/10/02(火) 08:14:32

0bってなんで却下されたの？

937 ：デフォルトの名無しさん：2007/10/02(火) 10:07:15

>>935
自分がさも玄人のように上から見下ろした書き方をしているが、
実際にはお前だって大した人間じゃないだろう

938 ：デフォルトの名無しさん：2007/10/02(火) 10:34:53

目くそ鼻くそ。

939 ：デフォルトの名無しさん：2007/10/02(火) 10:48:05

大違いってことだな。

940 ：デフォルトの名無しさん：2007/10/02(火) 13:22:29

しかし今さら非互換が出る構造体配置規定はないでしょう

941 ：デフォルトの名無しさん：2007/10/02(火) 13:53:26

boostがsmart_struct作ってくれるよきっと

942 ：デフォルトの名無しさん：2007/10/02(火) 14:51:09

>>940
現状特に規定が無いのだから、今さら非互換ってのにはあたらない
と思うが。あと0xは現状との互換性を完全に踏襲しようとしてるの？

943 ：デフォルトの名無しさん：2007/10/02(火) 14:57:37

アーキテクチャによってはメンバーポインタがかなり複雑な実装になりそう。

944 ：デフォルトの名無しさん：2007/10/03(水) 00:19:55

>>943
そのこころは？

945 ：デフォルトの名無しさん：2007/10/06(土) 21:38:02

なんか、DがC++とリンク可能になったらしい…
クラスオブジェクトも相互利用できるらしい…
C++0xの優位性って何…？

946 ：デフォルトの名無しさん：2007/10/06(土) 21:42:21

>>945
そうなの？C++ってABIぐちゃぐちゃなのに
g++の出力した*.oとはリンクできるとか、そういう話か？

どっちみち現在のC++はテンプレートベースのライブラリが多いから、
*.oとリンクできたところで何が嬉しいんだかよくわからん
それだけじゃ、STLもboostも使えないだろ

947 ：デフォルトの名無しさん：2007/10/06(土) 21:47:56

そういえば、var って戻り値として宣言できるの？

948 ：デフォルトの名無しさん：2007/10/06(土) 21:52:21

>>945
そもそも名前マングリングさえ統一されてないのに
どうやってリンクすんの？
特定の環境限定？

949 ：デフォルトの名無しさん：2007/10/06(土) 23:03:14

というかDに何の興味もない

950 ：デフォルトの名無しさん：2007/10/06(土) 23:27:19

>>945
boostが使えねーyo

951 ：デフォルトの名無しさん：2007/10/06(土) 23:32:25

boostスレのこのコードは0xでは通る?
enum{ value = "a"[0] };

952 ：デフォルトの名無しさん：2007/10/06(土) 23:33:56

ぱっと見では通りそうに見えるけど…
（キャストしなくてもいいのかは気になるが）
なんか問題あるコードなんだっけ？

953 ：デフォルトの名無しさん：2007/10/06(土) 23:37:14

>>952
Boostスレ見れ

954 ：デフォルトの名無しさん：2007/10/06(土) 23:48:08

C++0xが試せるコンパイラってあんの？
GCC4.3とか?

955 ：デフォルトの名無しさん：2007/10/07(日) 00:28:14

>>954

Status of Experimental C++0x Support in GCC 4.3
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html

956 ：デフォルトの名無しさん：2007/10/07(日) 00:47:32

>>948
どうせDMC限定でしょ？

957 ：デフォルトの名無しさん：2007/10/07(日) 10:41:44

0xが出るおかげでD涙目ｗｗｗ

958 ：デフォルトの名無しさん：2007/10/07(日) 10:54:37

どうせ両方とも変態言語なんだから方向性を尊重しつつ影響を与えあいつつ仲良くやってきゃいいと思うんだけどね。

959 ：デフォルトの名無しさん：2007/10/07(日) 13:04:32

0b の話を蒸し返すけど
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
が通れば同じようなことはできるようになるはず。prefix じゃなくて suffix だけど。
ユーザーが拡張可能になるからものすごい変態的機能が実現できそうな気がする。

960 ：デフォルトの名無しさん：2007/10/07(日) 13:30:32

これ大真面目に議論されているのかな。
C++ってどんな言語だったっけ。

961 ：デフォルトの名無しさん：2007/10/07(日) 13:43:39

C with classes

962 ：デフォルトの名無しさん：2007/10/07(日) 13:54:34

「何でもあり」
とWikipediaに書き込んだのは俺

963 ：デフォルトの名無しさん：2007/10/07(日) 14:35:58

>>962
おまのせいでこんな言語になったのか！

964 ：デフォルトの名無しさん：2007/10/07(日) 14:57:54

perlより読みにくいコードになりそうだな

965 ：デフォルトの名無しさん：2007/10/07(日) 16:44:18

perlが読みにくいとか（笑）