06/06/05 02:08:28
2?
3:デフォルトの名無しさん
06/06/05 02:10:44
転載だけど、こうなるらしい。
--- C++98 Code ---
vector<int> v;
v.push_back(1);
v.push_back(2);
v.push_back(3);
vector<int>::iterator i = find(v.begin(), v.end(), 2);
--- C++0x Code ---
vector<int> v = { 1, 2, 3 };
auto i = find(v, 2);
STLヴァリヴァリな人にはとってもラクチンになる予感。
4:デフォルトの名無しさん
06/06/05 02:12:31
今まで出来なかったのが不思議
5:デフォルトの名無しさん
06/06/05 02:13:23
本当にあと2年半以内に出るのか？
6:デフォルトの名無しさん
06/06/05 02:14:26
標準C++に対してコンパイラの準拠レベルが低かったからでしょ。
規格だけ新しくしても実情が付いてこなけりゃどうにもならん。
実装してみて初めて分かることってのもあるし、様子を見てたんじゃないの？
7:デフォルトの名無しさん
06/06/05 02:15:11
>>5は算数を勉強しなおしたほうがいいと思う
8:デフォルトの名無しさん
06/06/05 02:15:27
コンパイル速度が速くなると良いな。Pascal 並みとは言わんけど、常識的な速度で plz.
9:デフォルトの名無しさん
06/06/05 02:17:19
またいろいろ肥大化するんだろうなあ。
こうしてC++は巨大言語の地位を不動のものとするのでありました。
10:デフォルトの名無しさん
06/06/05 04:25:24
標準化に関わってるメンバはインテルから金貰ってる。
11:デフォルトの名無しさん
06/06/05 12:08:10
さっさと右辺値参照と perfect forwarding よこしやがれこんちくしょー！！
12:デフォルトの名無しさん
06/06/05 14:18:42
2010年になってもまだ制定されてなかったら
0xは16進数のprefixだっていうことにならんかな
13:デフォルトの名無しさん
06/06/05 16:49:10
>>3
後者のfindは今のboost.range_ex相当だと思っていいんだよな？
14:デフォルトの名無しさん
06/06/05 17:38:27
>>11
C++ってもうプログラミング言語の実験室だな。
URLﾘﾝｸ(www.open-std.org)
を見ていると欲しい機能が満載w
15:デフォルトの名無しさん
06/06/05 18:58:15
javaみたいに継承禁止を指定できるようになる？
16:デフォルトの名無しさん
06/06/05 20:43:59
>>3
Boostでほぼ実現されているところが怖いな
>>15
BoostのVaultになんかあったぞ
17:デフォルトの名無しさん
06/06/05 21:55:44
std::tr1を実装しているところてあるのかな
18:デフォルトの名無しさん
06/06/05 21:56:24
>vector<int> v = { 1, 2, 3 };
これCとの互換性なくならない？
配列のサイズどうする気なの？
19:デフォルトの名無しさん
06/06/05 21:59:29
libstdc++にあるよ
$ ls /usr/include/c++/4.1.1/tr1
array bind_iterate.h bind_repeat.h boost_shared_ptr.h
functional functional_iterate.h hashtable memory
mu_iterate.h ref_fwd.h ref_wrap_iterate.h repeat.h
tuple tuple_iterate.h type_traits type_traits_fwd.h
unordered_map unordered_set utility
URLﾘﾝｸ(gcc.gnu.org)
20:デフォルトの名無しさん
06/06/05 22:03:35
>>18
> これCとの互換性なくならない？
どうなくなるの?
> 配列のサイズどうする気なの？
boost/preprocessor/array/*と同じ動作になるんじゃないの?
21:デフォルトの名無しさん
06/06/07 17:16:02
もしもBoost.LambdaがそのままC++に取り込まれたら世も末だな。
22:デフォルトの名無しさん
06/06/07 21:18:51
手続き、構造化、OOP、ジェネリック、さらに関数型の記述も混在できる！！
…確かに末だな。
23:デフォルトの名無しさん
06/06/07 21:23:41
え～，それが面白いんじゃんかー．ぶーぶーぶー
24:デフォルトの名無しさん
06/06/07 22:53:24
lambda記法は、新しい構文で提案されてますよ。
Lambda expressions and closures for C++
URLﾘﾝｸ(www.open-std.org)
25:21
06/06/07 23:07:50
>>24
勿論それは知っている。
だからこそ21を書いた。
26:デフォルトの名無しさん
06/06/08 09:24:36
Boostのlambdaなんて繋ぎですよ
27:デフォルトの名無しさん
06/06/08 18:50:12
io,stream,国際化関係
を分かりやすくかつ高パフォーマンスにして欲しい。
今のは使いにくい。
28:デフォルトの名無しさん
06/06/08 20:33:34
名前がかっこいいから策定されても仕様名はC++0xのままにしてほしい
29:デフォルトの名無しさん
06/06/08 20:54:05
勧告された暁にはちゃんと年月にちなんでC++0xFFと呼ばれます。
30:デフォルトの名無しさん
06/06/10 07:30:18
せめて標準ライブラリの部分だけでも、5年に一度ぐらいの割合で
改訂してくれんかな。
31:デフォルトの名無しさん
06/06/10 10:36:15
一応そのくらいでやるつもりなんでしょ。
32:デフォルトの名無しさん
06/06/11 11:33:06
二進数表記ができるようになってほしい。
33:デフォルトの名無しさん
06/06/11 11:47:29
>>32
2進←→16進なんて簡単に脳内で変換できるんだから要らなくね？
34:デフォルトの名無しさん
06/06/11 12:02:14
>>32
10bitまでならherumiさんのtemplateで出来るぞ。
35:デフォルトの名無しさん
06/06/11 12:08:43
>>33
ソース中に記述できることには別の意義がある。
36:デフォルトの名無しさん
06/06/11 12:19:32
>>35
例えば？
37:デフォルトの名無しさん
06/06/11 12:24:39
プレフィクスつけて指定する形を取ってるからなあ…
0 → 8進
0x → 16進
じゃあ2進は？
後ろにhとかoとかの形式なら、bを増やせばいいだけなんだが…。
38:デフォルトの名無しさん
06/06/11 12:31:38
D言語とかでは0bをプレフィックスにしてたな。
ただ、2進表記は微妙と個人的には思う。
0b10101010101010101010101010101010
0x55555555
ソースコード上の2進表記を読み取るより、
16進表記を脳内で2進に変換するほうが個人的には圧倒的に楽
39:デフォルトの名無しさん
06/06/11 12:37:17
仕様が２進表記を使っている場合に
ソース上で１６進表記になっていると、
仕様を変更するときには変換しないといけないだろ？
ソース中に２進表記ができればコピペで済む所が
脳内変換を必要とするわけよ。これはよくない。
40:デフォルトの名無しさん
06/06/11 12:39:05
2進 <-> 16進で脳内変換できないようなカスは別の言語をどうぞ
41:デフォルトの名無しさん
06/06/11 13:10:33
ぶっちゃけ2進数表記は長くなる傾向が多くて使い辛い。
短い表記ならtemplateでも対処できるわけだし。
42:デフォルトの名無しさん
06/06/11 13:29:32
2進と16審の脳内変換・・・って・・・
手間はコピペするのと大差無いだろ。何が問題なのかわからん。
それともいちいち、2進の各桁に2のn乗かけて・・ってやらないと変換出来ないヘタレか？
10進数を介さないと変換できません、とか。
そんな低脳のために余計な仕様付ける方がどうかしてるわ。
43:デフォルトの名無しさん
06/06/11 13:37:19
２進データ１０００個のテーブルでも
コピペと脳内変換で大差ないと思うの？
少なくとも俺は面倒で嫌だな。
２進と１６進の変換は普通にできるけどね。
44:デフォルトの名無しさん
06/06/11 13:48:08
どうせ2進テーブルっつったって0bみたいなprefixがついてるわけじゃないだろう？
正規表現やら何やらを使って半自動で追加させるのも、
16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
どちらにせよそんな限られた状況のためだけに2進数定数を仕様に導入する価値はないと思う。
45:デフォルトの名無しさん
06/06/11 13:54:55
>>44
> 16進にコンバートするコンバータをちゃちゃっと書いてしまうのも大差ないと思うが。
十分メンドクセェよ。仕事頼める人が限られるのもウザイ。
限られた状況なのはわかってる。しかし一部には確実なニーズがあり、
仕様については実装も簡単だし互換性に影響しないこともあるんで、
追加してもいいだろうとは思う。
これ以上は水掛け論だろうねぇ。
46:デフォルトの名無しさん
06/06/11 14:02:00
バイナリリテラルは、エンディアンやらビット長の問題で解釈の仕方が実装依存だから
標準規格に入ってない（というか入れられない）だけじゃなかったか？
今後も入ることはないだろ。
47:デフォルトの名無しさん
06/06/11 14:08:15
えぇー。1バイトが8ビットじゃないマシンって話にしか聞いたことないけど、まだあるの？
48:デフォルトの名無しさん
06/06/11 14:09:37
>>46
そんな問題は１６進でも同じじゃないか？
49:デフォルトの名無しさん
06/06/11 14:11:41
2<->16変換なんて自前で書きゃいいだろ30秒もかからんぞ
#include<stdio.h>
#include<stdlib.h>
int main(){
char s[80];
while(gets(s))printf("0x%08lX\n",strtoul(s,0,2));
return 0;
}
50:デフォルトの名無しさん
06/06/11 14:14:59
>>48
例えば
int i=0x10;
は、ビッグエンディアンなら10000、リトルエンディアンなら00001のビット列と解釈される（コンパイラが自動でやってくれる）ので
ソースコードを別マシンに移しても問題ないけれど、
int i=0b10000;
という表記を認めたら、それは0x10なのか、それとも0x1なのかの解釈がコンパイラによって変わってしまい、
ソースコードの移植性がなくなるって話だろ。
51:デフォルトの名無しさん
06/06/11 14:16:09
>>49
はいはい。スゲェスゲェ。
そのレベルで済ませられる奴が同じチームに何人居ると思う？
何人も居たとして、同じ（似たような）機能のツールを
世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？
52:デフォルトの名無しさん
06/06/11 14:17:54
10進数だけでいいじゃん
53:デフォルトの名無しさん
06/06/11 14:19:25
>>50
エンディアンはメモリなどのバイト列を考えたときの
バイトオーダーの話だから、数値の表現形式自体とは関係ないよ。
0x10 が 16 と定まるように、 0x10 は 0b10000 と定まる。
54:デフォルトの名無しさん
06/06/11 14:23:01
>>51
>そのレベルで済ませられる奴が同じチームに何人居ると思う？
>何人も居たとして、同じ（似たような）機能のツールを
>世界中のプログラマが繰り返し実装するのを無駄だとは思わんかね？
驚いたwwww
ひどい低能だな
お前にプログラミングは向いてない
やめたほうがいいと思われ
55:デフォルトの名無しさん
06/06/11 14:23:12
bitmapなんかをソースに埋め込みたいときに使えると便利だな
56:デフォルトの名無しさん
06/06/11 14:25:41
D&Eぐらい嫁。
C++標準委員会は既にバイナリリテラルへの対応を予備審査で却下してるんだから
これから実装されることはまずあり得ない。
57:デフォルトの名無しさん
06/06/11 14:25:58
>>54
質問には答えてほしかったんだが、まぁいい。
どうせ現実世界には影響の無い与太話だ。
58:デフォルトの名無しさん
06/06/11 14:35:53
今気づいたが、禿のC++Glossaryでは
C++0x - the upcoming revision of the ISO C++ standard; 'x' is scheduled to be '9'. See my publicatons page.
2009年予定なのね…
ISOの改訂って5年ごとじゃなかったっけか？
59:デフォルトの名無しさん
06/06/11 15:11:00
個人的にはビットパターンを図示しやすくなるからバイナリリテラルはあってもいいと思う。
で、やるからには8or4ビットごとにセパレータを入れられればもっといい。
Ex. 0xdead → 0b1101_1110_1010_1101
60:デフォルトの名無しさん
06/06/11 15:51:52
URLﾘﾝｸ(www.illegal-immigration.com)
これか。いつ追加されるのだ
まーこんなのよく考えるもんだ
61:・∀・）っ-○◎● ◆toBASh....
06/06/11 18:00:21
_0b00000000～_0b11111111までとか定数定義して、あと16bitとか32bitとかマクロで連結する
ってことやってる会社は知ってる
62:デフォルトの名無しさん
06/06/11 18:03:11
全部マクロでやってるヘッダならboostで見た気がする
63:デフォルトの名無しさん
06/06/11 18:05:25
CでGUIアプリってつくれるの？
javaしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるCとか、かんたんできるCとか
いろいろ本でてますけどCUIだよな。
どうしたらCでGUIアプリ作れるの？
64:デフォルトの名無しさん
06/06/11 18:08:20
スレ違いも甚だしい
65:デフォルトの名無しさん
06/06/11 18:10:25
Javaでネイティブアプリってつくれるの？
Cしかやったことないんで。
しかもさ、本にのってないよね？
よくわかるJavaとか、かんたんできるJavaとか
いろいろ本でてますけどVMだよな。
どうしたらJavaでネイティブアプリ作れるの？
66:デフォルトの名無しさん
06/06/11 18:22:05
GCJ
67:デフォルトの名無しさん
06/06/11 20:15:11
>>58
五年ごとって決まっているのは一部でしょ。
たとえばFORTRAN。
68:デフォルトの名無しさん
06/06/12 23:27:59
C++ Template Metaprogramming にはこんなのもあるよ。
template <unsigned long N>
struct binary
{
static unsigned const value
= binary<N/10>::value * 2 + N % 10;
}
69:デフォルトの名無しさん
06/06/12 23:31:13
>>68 assert(binary<0101>::value == 5);
70:デフォルトの名無しさん
06/06/12 23:39:28
59について思ったのだが、68で、テンプレート引数をいくつも取るようにしてやればいいと思った。
template<
unsigned long Byte1, unsigned long Byte2,
unsigned long Byte3, unsigned long Byte4>
struct binary4
{
staic const unsigned long value =
binary<Byte1>::value << 24 |
binary<Byte2>::value << 16 |
binary<Byte3>::value << 8 |
binary<Byte4>::value << 0;
};
binary4<11110001, 11100010, 11010011, 11000100>::value == 0xf1e2d3e4
71:デフォルトの名無しさん
06/06/12 23:58:14
馬鹿には>>60が見えないのか？
templateはboostに却下された
72:デフォルトの名無しさん
06/06/13 00:03:22
Boostに入らなければ個人的に作って使えばよいだけ。
73:デフォルトの名無しさん
06/06/13 01:11:05
実用性ゼロの趣味テンプレート
74:デフォルトの名無しさん
06/06/20 19:53:27
保守
75:デフォルトの名無しさん
06/06/24 01:13:05
TR1の本ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!!!!
URLﾘﾝｸ(www.amazon.com)
URLﾘﾝｸ(www.aw-bc.com)
Pete Beckerﾊｧﾊｧ
URLﾘﾝｸ(www.petebecker.com)
76:デフォルトの名無しさん
06/06/24 01:37:47
>>75
本を出す意義がわからん。
↓のドラフトや boost の実装、ドキュメントで十分だろ。
URLﾘﾝｸ(www.open-std.org)
77:デフォルトの名無しさん
06/06/24 02:37:21
EffectiveSTLのTR1に合わせた改訂予定はあるのかな
78:デフォルトの名無しさん
06/06/24 05:35:16
ライブラリもいいけど、早いとこ concept や rvalue reference
決めねえと間に合わなくなると思うんだがな。こいつら入ったら
ライブラリ大幅に書き直しじゃん？
79:デフォルトの名無しさん
06/06/24 09:49:39
>>75
Peteが出すんだから、出す意味のある内容なんじゃないのかね。
>>78
0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。
C++って本当、永遠に仕様が確定しそうにないよな。
80:デフォルトの名無しさん
06/06/24 13:02:27
C++は完璧ではないし、完璧になることはあり得ない。常に進化し続ける。
とは禿の言葉だっけか
81:デフォルトの名無しさん
06/06/24 14:31:54
常に進化し続けるのはいいが仕様が確定しないと処理系が出てこないわけで。
82:export
06/06/24 14:55:05
すみません。
私を知っている人はいますか？
83:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/06/24 15:14:38
仕様があるのにどの処理系でも未だサポートされないキーワードの典型ですな
84:デフォルトの名無しさん
06/06/24 15:42:03
name lookup ruleも永遠に定まらないだろうな。
85:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/06/24 15:46:48
ガベコレでも標準ライブラリに入れて欲しいと思うの俺だけ？
86:デフォルトの名無しさん
06/06/24 16:53:21
ガベコレが必要なのはCだろう...
shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
87:デフォルトの名無しさん
06/06/24 17:23:13
>>86
> shared_ptrは再帰デストラクタ失敗するのが弱点だよな。
なんのこと？
88:デフォルトの名無しさん
06/06/24 17:30:52
循環参照のことでは？
89:デフォルトの名無しさん
06/06/24 18:50:37
>>82
concept の導入によりテンプレートの定義と実装を分けることが
可能になれば、あるいは再デビューできるかも試練よ
90:デフォルトの名無しさん
06/06/24 19:01:55
>>78
>0xは2009らしいから、ライブラリも頑張って全面的に書き直すんじゃないのかね。
現状の年２回のミーティングじゃ３年なんてあっと言う間だろう。
N2004より
>The following proposed changes will cause the C++0x schedule
>to slip if the committee does not commit to them by the end of
>the October, 2006 meeting, ...
91:デフォルトの名無しさん
06/06/24 20:46:20
200C年くらいに出れば御の字だよね
92:デフォルトの名無しさん
06/06/24 21:04:49
>>91
6198年後かよ
93:デフォルトの名無しさん
06/06/24 23:26:48
>>83
でも予約だけはされてんのな。
94:デフォルトの名無しさん
06/06/25 16:38:34
予約じゃないですよ。
既に規格の一部です。
95:デフォルトの名無しさん
06/06/26 08:09:14
予約だし、規格の一部だよ。
96:デフォルトの名無しさん
06/06/29 22:23:00
そういやどうして「予約語」っていうんだろう
97:デフォルトの名無しさん
06/06/29 23:45:12
>>96
字句は識別子としての要件を満たしているから。
だけど文法上特別な意味を持たすために、
識別子として使えないようコンパイラがその字句を「予約」している。
98:デフォルトの名無しさん
06/06/30 00:10:26
まあ「予約」語は誤訳みたいなもんで、(特に「予」め)
除外語がreserved workの訳には適当。
99:デフォルトの名無しさん
06/06/30 01:10:08
うはｗ やべぇ concept_map 凶悪
concept_map InputIterator<int> {
typedef int value_type;
typedef int reference;
typedef int* pointer;
typedef int difference_type;
int operator*(int x) { return x; }
};
copy(1, 17, ostream_iterator<int>(cout, " "));
// prints: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
100:デフォルトの名無しさん
06/06/30 09:43:52
>98
「除外」のほうが違和感がある
101:デフォルトの名無しさん
06/06/30 12:53:14
「お客様、そこは除外席ですので、他の席をお使い下さい」
102:デフォルトの名無しさん
06/06/30 13:51:26
>>98
中学校からやり直せ。
いや、おまえは英語を読むな。
103:デフォルトの名無しさん
06/06/30 18:43:40
>>99
ヘタにガリガリ書くコーディングが減っていいんじゃないか？
104:デフォルトの名無しさん
06/07/10 12:59:49
int operator*(int x) { return x; }
はやりすぎと思うが。
話題もないので張っときます。
URLﾘﾝｸ(www.open-std.org)
Strong candidates for TR2 include:
* Filesystem (accepted)
* Thread support
* Date and time
* Network file support
* Consistent system/OS error reporting
* Range-types, to complement iterators
* String algorithms
* Optional/Nullable values
* Range-checked numeric-casts
* 'Lexical' casts
* typesafe 'any' class
* interval arithmetic
* Unlimitted precision integer type
105:デフォルトの名無しさん
06/07/10 20:46:42
>>104
Thread単体でサポートしてもなぁ。
ACE見たく非同期関連のフレームワークと一緒でないとあんまり役に
たたない様な気がするけど。
(boost.)lexical_castはspiritがあるのでちっとも使わん。
106:デフォルトの名無しさん
06/07/11 03:12:35
>* typesafe 'any' class
Boostにある、あれをそのまま盛り込むのだろうか。
>* Unlimitted precision integer type
まあ、簡単につかえる標準ライブラリは欲しいかな。
107:デフォルトの名無しさん
06/07/11 06:56:10
基本的には同じ
Any Library Proposal for TR2
URLﾘﾝｸ(www.open-std.org)
かなり強力
Proposal for an Infinite Precision Integer for Library Technical Report 2, Revision 1
URLﾘﾝｸ(www.open-std.org)
108:デフォルトの名無しさん
06/07/12 22:26:27
>>105
でもC++に標準でスレッドサポートされる、というのは大きいんじゃまいか。
もしかしたら将来のCでもサポートされるかもしれんし。
109:デフォルトの名無しさん
06/07/12 22:42:35
tr2でXMLとかネットワークとかマジですか
実現したらかなり協力だなぁ
110:デフォルトの名無しさん
06/07/12 23:06:20
この調子で行けばC++ 2xにはGUI関連が標準ライブラリに入るに違いない。
111:デフォルトの名無しさん
06/07/12 23:28:26
Boostで便利なのが軒並み入ってるな。
それ以外の勢力は元気なくてさみしい。
112:デフォルトの名無しさん
06/07/14 02:28:31
C++0xに対応したMSのコンパイラはいつ出るんだろ。
規格が決まってから、実装するまで何年ぐらいかかるのかな。
113:デフォルトの名無しさん
06/07/14 03:00:55
過去の例から考えると１０年くらいか orz
114:デフォルトの名無しさん
06/07/14 13:30:29
boost 1.34 には tr1が入るみたいだから、
boostからtr1が使っている部分だけ抜き出してそれをVC++用に使うようにすればいい
といってみるテスト
115:デフォルトの名無しさん
06/07/14 16:02:33
そういえば、いまさらで馬鹿にされる質問かもしれないけど、
新しいライブラリの名前空間はどうなるんだろう。
まさか tr1 などというかっこ悪い名前空間のままだったりはしないよね。
でも、stdに押し込むと、既存のライブラリと衝突したりしないのかな
116:デフォルトの名無しさん
06/07/14 16:06:59
>>115
衝突しないようにstdに入れるんじゃまいか？
117:デフォルトの名無しさん
06/07/16 01:56:20
今はstd::tr1みたいだけど、最終的にはどうなるんだろね。
118:デフォルトの名無しさん
06/07/16 09:12:22
stdにいれるに決まってるじゃん。
けどJavaみたいに階層構造になっているのもいいよな。
importってのは、#includeとusingをうまく組み合わせていると思う。
119:デフォルトの名無しさん
06/07/16 10:13:57
階層化する前に、名前空間の記述の簡易化をはやく標準化して欲しいよ
120:デフォルトの名無しさん
06/07/16 10:46:32
namespace com { namespace example { namespace myproj { /* */ } } }
ってめんどくさいから、例えば
namespace com::example::myproj { /* */ }
とかね。
ふと思ったんだけど、C++0xはライブラリ以外の部分はどう変わるんだろう。
121:デフォルトの名無しさん
06/07/16 12:06:35
draft October 2005
URLﾘﾝｸ(www.open-std.org)
122:デフォルトの名無しさん
06/07/16 15:01:35
TR1のMathematical special functionsに球面調和関数が入ってるのね・・・
昨今のPRT人気の影響なんだろうか
123:デフォルトの名無しさん
06/07/17 09:20:31
>>121
追加削除あるところはだいたい文字色変えてあるのね。わかりやすくていい。
そこだけざっと見たところ、C99互換以外では、static_assert が増えてるのと、
コンテナやイテレータにちょこっとメンバが増えてるのくらいだな。
124:デフォルトの名無しさん
06/07/17 11:47:30
>>121
ドラフトで800ページオーバーかよ・・・・orz
125:デフォルトの名無しさん
06/07/17 12:52:37
Conceptおもしろいのう…
Generic Programming in ConceptC++
URLﾘﾝｸ(www.generic-programming.org)
126:デフォルトの名無しさん
06/07/19 18:16:54
予約語 where がなにか違和感
この調子で5W1Hの予約語が追加されたらｵﾓﾛ
127:デフォルトの名無しさん
06/07/19 18:57:33
この調子では来世紀にはすべての英単語が予約語になってしまうのではないか...
128:デフォルトの名無しさん
06/07/19 21:58:13
今のところ私は来世紀までには死ぬ予定になっているからへっちゃらです
129:デフォルトの名無しさん
06/07/19 22:00:17
英単語はどんどん増えるから大丈夫です。
フランス語だとあぶないかもですが。
130:デフォルトの名無しさん
06/07/20 11:12:13
問題は既存の汎用英単語を新しく作る事だ。
131:デフォルトの名無しさん
06/07/20 12:22:07
文脈依存のキーワードになるから無問題
132:デフォルトの名無しさん
06/07/20 12:29:00
既存のものを新しく作るのはかなり難しいだろうな
133:デフォルトの名無しさん
06/07/20 13:55:34
132だけ読むと、所謂パクリにも技術が要るという風にも読み取れるな。
すみません、関係ないです。はい。
134:デフォルトの名無しさん
06/07/20 18:37:25
活用や接頭接尾語まで予約されたら悪夢
ってどんどん無関係な話題になってないか？
135:デフォルトの名無しさん
06/07/20 21:33:30
じゃぁ、「もしこの英単語がC++の予約語になったら」でいってみようか。
136:デフォルトの名無しさん
06/07/20 22:04:17
hage
137:デフォルトの名無しさん
06/07/20 22:10:03
a, i, j, k, m, n, p, q, r, s, t, u, v, w, x, y
138:C++/CLI
06/07/21 01:17:11
spaced keyword(藁
139:デフォルトの名無しさん
06/07/21 02:08:14
fp, argc, argv
140:デフォルトの名無しさん
06/07/21 02:26:37
C++0x
魚の骨かと
141:デフォルトの名無しさん
06/07/21 05:39:13
Boostてどんな物なん？
142:デフォルトの名無しさん
06/07/21 11:07:18
おまえにこのスレは早すぎる
143:デフォルトの名無しさん
06/07/22 18:56:00
>>135
URLﾘﾝｸ(www.linkage-club.co.jp)
144:デフォルトの名無しさん
06/08/12 12:18:33
コンセプトとやらにテンポラリオブジェクトも含めて欲しい。
戻り値最適化が解決できるし。
STLコンテナやstringと相性いいと思うんだけどな。
T operator+(const T& lhs, const T& rhs)
T& operator+(temporary T& lhs, const T& rhs)
T& operator=(const T& t)
T& operator=(temporary T& t)
145:デフォルトの名無しさん
06/08/12 18:44:53
右辺値参照と違うの？
146:デフォルトの名無しさん
06/08/12 18:50:21
>>144
move semanticsがC++に導入されるのを期待しよう。
147:デフォルトの名無しさん
06/08/12 23:04:01
うわー、まったくもってそのものな仕様だなこれ。恥ずかし。
でも例えばこう書ければなぁ、と思ってたんだけど
move semanticsの仕様でも多分できるよね。
string&& operator+(string&& lhs, const string& rhs) {
return lhs += rhs;
}
boost::arrayあたりはこう書けないと困るのだけど。
148:デフォルトの名無しさん
06/08/12 23:42:19
と、思ったけどexpression templateとmove semanticsを組み合わせれば
いらないか・・
149:デフォルトの名無しさん
06/08/13 01:48:17
お前らそーいうネタはどこで勉強してるのですか。
150:デフォルトの名無しさん
06/08/13 07:49:40
URLﾘﾝｸ(www.open-std.org)
151:デフォルトの名無しさん
06/09/07 04:19:13
tr1::regexって、もっとも多機能なsyntax_option_typeでも
ECMAScript相当なんだな。
うーん、今時look-behindがないってのは見劣りするなあ。
152:デフォルトの名無しさん
06/09/07 14:25:14
boostにTR1が実装されたみたいだけど、使ってみようかな
153:デフォルトの名無しさん
06/09/07 15:22:21
>>3を見るまでautoの存在を忘れていた
154:デフォルトの名無しさん
06/09/07 16:44:13
C++0xの0xが16進プレフィクスではなく
2010年までには出すぞ、という願望の現われだと今日知った。
早く使いたいな。
155:デフォルトの名無しさん
06/09/07 17:52:59
対応コンパイラが出るのは5年後です
156:デフォルトの名無しさん
06/09/07 21:27:24
C++0xが世に出るのは2109年だよ。
ドラえもんはそれで書かれてる。
157:デフォルトの名無しさん
06/09/07 23:56:45
C++0xの実装は跳ばされる
158:デフォルトの名無しさん
06/09/08 09:56:08
そんなことはないと言いたいところだけど、
exportの例があるからな…
159:デフォルトの名無しさん
06/09/08 12:25:16
あれはどちらかというと、実装の手間を考えずに策定した側に
問題あるような。
160:デフォルトの名無しさん
06/09/09 00:22:06
実際問題、実装しろとか言われたら嫌な汗出てくるもんな。
C++全体に渡ってそんな感じではあるが。
161:デフォルトの名無しさん
06/09/09 02:41:12
こんなこといいな、できたらいいなと何でもかんでも詰め込んだまではよかったが
不思議なポッケでかなえてくれるドラえもんはいないという点にまで気が回らなかったと
162:デフォルトの名無しさん
06/09/09 03:24:51
exportは一応EDGが3人年かけてかなえてくれたけどな
誰も近寄らなくなったけどw
163:デフォルトの名無しさん
06/09/09 04:32:41
C++は夢いっぱい
164:デフォルトの名無しさん
06/09/09 09:46:54
VC2005で、リンク時のコード生成を行ってるけど、exportじゃ無いのかな？
165:デフォルトの名無しさん
06/09/09 12:19:22
>>164
それは最適化。
たとえば、リンク時にインライン展開するとか。
166:デフォルトの名無しさん
06/09/09 13:39:37
exportが駄目でした、なんてのはどうでもいいが
コンパイルは出来るのにそれがC++言語として
正しいかどうか調べ回らないといけないのがつらい
ガベージコレクタの*ない*Javaがモダンな言語とは全く思わないが
write once, compile anywhereなのはうらやましい
167:デフォルトの名無しさん
06/09/09 13:45:23
実際、Javaはwrite once、compile once、run anywhereだもんな。
失うものも多いが、楽なのは確かだ。
168:デフォルトの名無しさん
06/09/09 13:48:10
拡張機能を切ってコンパイルすれば、そこそこ正しくはなる。
ただ、それでも他のコンパイラでコンパイルすると
不完全だと分かる事もよくある話。
難しいもんですな。
169:デフォルトの名無しさん
06/09/09 14:54:45
>167
debug anywhere だけどな
170:デフォルトの名無しさん
06/09/09 18:08:44
Write Once, Run Anywhere, Debug Everywhere!
171:デフォルトの名無しさん
06/09/09 20:42:30
やっぱり、#ifdef は要るよ
172:デフォルトの名無しさん
06/09/09 23:32:00
そんなあなたにBoost MPL。
173:デフォルトの名無しさん
06/09/11 06:00:00
Debug Everyday!
174:デフォルトの名無しさん
06/09/11 21:11:16
char を UTF-8、wchar_t を UTF-16 として認識する標準ライブラリおよび
コンパイルオプションが欲しい。
175:デフォルトの名無しさん
06/09/11 21:55:25
>>174
そういうlocale（特にcodecvt）を作ればいいという話ではないのか？
176:デフォルトの名無しさん
06/09/11 22:11:50
STLのlocale周りは、はっきり言って無駄だから、
さっくり削除してほしいと思っているのは自分だけ？
177:デフォルトの名無しさん
06/09/11 22:13:38
実装の話？仕様の話？
178:デフォルトの名無しさん
06/09/11 22:16:05
>>174
> char を UTF-8
どういうこと?
charというか、mbsのこと?
179:デフォルトの名無しさん
06/09/11 22:17:32
>>174
> wchar_t を UTF-16 として
どういうこと?
UTF-16じゃなくて、UCS-4でなく?
180:デフォルトの名無しさん
06/09/11 22:18:43
>>176
君みたいな人は少ないと思う。
181:デフォルトの名無しさん
06/09/12 01:02:06
サロゲート無しのUCS-2じゃ、やっぱりそのうちUCS-4に駆逐されるというか
邪魔にされる日が来るのかね。
1文字2Bytesは呑めても、4Bytesは呑み込み辛い…様な。
182:デフォルトの名無しさん
06/09/12 01:24:19
しかし1文字2バイトを許容できるのは、日本人が元から2バイト文字に慣れ親しんでいたからであって、
欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
実際のところどうなのかは知らないが。
ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
183:デフォルトの名無しさん
06/09/12 02:34:51
URLﾘﾝｸ(www.open-std.org)
> News 2006-09-11: The 2006-09 mailing is available (4700 kb tar.gz, .zip 4700 kb) individual papers
> News 2006-09-11: The C++ Standard Library Issues List (Revision 44) is available (.tar.gz)
> News 2006-09-11: C++ Standard Core Language Issues List (Revision 43) is available, also committee version
184:デフォルトの名無しさん
06/09/12 13:22:39
>>183
(ﾟ∀ﾟ)ktkr
待ってたぜ。これで仕事中こっそり楽し(ry
185:デフォルトの名無しさん
06/09/13 05:22:20
>>182
> 欧米人は1文字2バイトも受け入れがたい存在なのではないかと考えたことがある。
だからこそUTF-8でしょ
> ちなみに俺は仮名漢字がほとんどの場合、UTF-8でも受け入れ難い。
日本人の都合なんか知ったこっちゃないし
186:デフォルトの名無しさん
06/09/13 06:41:57
ゴチョゴチョうるさいから、だから言語の規格では文字コード未定義扱いなの。
187:デフォルトの名無しさん
06/09/13 08:27:03
だからさ、char 型なんて廃止して、byte 型にしてほしいぜ
別個に string 型を用意して、string::char を定義して、あとは実装依存でいいと思うんだが
188:デフォルトの名無しさん
06/09/13 09:48:52
charが実装依存ですが?
basic_stringテンプレート知らない人ですか、ああそうですか
189:デフォルトの名無しさん
06/09/13 12:24:08
日本語も読めないのに皮肉を言おうとするとこうなる。
190:デフォルトの名無しさん
06/09/13 12:54:37
uint8_tで何が不満なんだ? > byte_t
191:デフォルトの名無しさん
06/09/13 18:51:23
8bitとは限らないから…とか？
192:デフォルトの名無しさん
06/09/13 21:24:18
uint8_t i = 32;
std::cout << i;
とやって、32じゃなくて、空白が出力されたるの嫌やん
193:デフォルトの名無しさん
06/09/13 21:26:02
1byteを表すchar
文字を表すchar
双方を別々に定義すべきだという主張かと
194:デフォルトの名無しさん
06/09/13 21:38:12
C++ でせっかく char と signed char と unsigned char に分かれたのに、
なんで cout << で全部文字になっちまうんだ？
195:デフォルトの名無しさん
06/09/13 21:54:36
実際問題、符号ないほうが都合がいいから
文字としてuchar使ってるケースあるし、その辺との兼ね合いでね？
196:デフォルトの名無しさん
06/09/14 08:34:29
>193
そう。バイト単位のデータを表す型と文字を表す型が同一であることが、本気で文字列を
なんとかしようという意志の無さの表れではないかと
実体が wchar_t であろうと char であろうと、１文字を１文字として扱えるなら関心はないよね
文字列の仕様なんてたぶんこの先もふらふらするんだから、ある程度距離を取っておいた
方がいいと思うんだな
string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
197:デフォルトの名無しさん
06/09/14 08:52:47
>>196
文字列(というか文字)を何とかした結果が今の形 char だと思う。
>string と encode をセットで別個にライブラリとして定義してもらった方が個人的には嬉しい
ができる柔軟性も、char, wchar_tのおかげと思えば・・
198:デフォルトの名無しさん
06/09/14 22:37:48
char は C との互換性のために残しておく程度でいい
std::string と std::wstring 間にろくな互換性無いだろ？
これを柔軟性というのか？
199:デフォルトの名無しさん
06/09/14 23:06:50
>>198 そういう意味だったのか。
200:デフォルトの名無しさん
06/09/15 00:54:03
>>198
互換性って例えばどういうこと?
201:デフォルトの名無しさん
06/09/15 01:44:55
>>200 もう血が止まってるんだから、変にいじったりしないの！
202:デフォルトの名無しさん
06/09/15 09:11:21
おねがいします。
自分のファイル名(x.exe)を読み込んで
xの部分がAすなわちA.exeだったらaを実行して
xの部分がBすなわちB.exeだったらbを実行する
っていうようなCのプログラムを教えてください。
203:デフォルトの名無しさん
06/09/15 09:26:00
なんでまた C++0x スレに？
もしかしてマルチ？
204:デフォルトの名無しさん
06/09/15 09:34:41
マルチだね
どこだか忘れたが別スレで見た
>202
あっちのスレに答えが書いてあったぞ
205:デフォルトの名無しさん
06/09/17 00:49:06
C++0xだと既存のC++とは比べ物にならないほどスマートにかけるとかそういう例題なんじゃね？
たぶんそんなことはないだろうが
206:デフォルトの名無しさん
06/09/17 11:10:37
おじいさんは、裏山に畑を耕しに行ったんじゃない？
たぶんそんなことはないだろうが
207:デフォルトの名無しさん
06/09/17 15:01:57
いいレス思いついた、と思ったら
書き込む前にまず他人に通じるかどうか考えようぜ。
208:デフォルトの名無しさん
06/09/17 20:43:56
>>207
そりゃ無理だ。読む奴が基地外だったら、どんな書き方をしても通じない。
とにかく書きゃいいんだって。
209:デフォルトの名無しさん
06/09/17 23:24:34
書かれたものがキチガイだと
本当に誰にも通じないけどな。
210:デフォルトの名無しさん
06/11/24 14:31:34
N2133 06-0203
Editor's ReportPete Becker
2006-11-03
URLﾘﾝｸ(www.open-std.org)
N2134 06-0204
Working Draft, Standard for Programming Language C++Pete Becker
2006-11-03N2009=06-0079
URLﾘﾝｸ(www.open-std.org)
新規色分け版
N2135 06-0205
Programming Languages －C++ Pete Becker
2006-11-06 N2134=06-0204
URLﾘﾝｸ(www.open-std.org)
色分けなし版
211:デフォルトの名無しさん
06/11/24 18:16:23
ちなみにADLのところ、3.4.2のルールが書き変わっています。
stringとchar_traitsのところも結構。
"文字"じゃなくてPODなら入れられる。
212:デフォルトの名無しさん
06/11/24 18:56:53
色の違いだったのね
213:デフォルトの名無しさん
06/11/24 22:19:20
論文リスト、ちらほら C++09 という記述が出始めたな
214:デフォルトの名無しさん
06/11/24 22:21:19
2009かあ。もうちょいペース上げてほしいなあ。
これじゃ本格的に使えるのは2010年代半ばになりそうだ。
215:デフォルトの名無しさん
06/11/28 23:58:39
Rvalue referenceって本当に規格にはいるのかね?
STLも仕様決め直しだし、それよりなにより、C++はマニア向けの言語になっちゃう…
Move semantics、あれば便利なのは確かなんだけど。
216:デフォルトの名無しさん
06/11/29 01:24:10
一番ほしいのはTemplate aliasesかな
217:デフォルトの名無しさん
06/11/29 01:31:43
>215
標準ライブラリに対する rvalue reference の導入は
下位互換を完全に意識した設計が提案されているので
＞STLも仕様決め直しだし、
という見方は少し違うような気がします．
std::auto_ptr などは deprecated なだけで廃止されるわけでもないですし．
というよりか，現在の標準ライブラリにおける rvalue reference 対応の提案は，
(いつものことですが) 下位互換の維持のために非常に設計が汚い印象があります．
move に対応していない場合 copy に fallback する設計は，
たとえば例外送出時のときなどの仕様と動作が極めて煩雑になるのではないか，
など個人的には不満も多いです．
(この汚さは標準ライブラリにおける rvalue reference 対応がもたらす汚さで，
言語仕様として導入される rvalue reference の仕様とは独立です)
言語仕様としての rvalue reference は， move semantics の導入と同時に，
the forwarding problem と呼ばれる非常に重要な問題を同時解決しますし，
(この問題の解決も見た目に比してインパクトが極めて大きいと思います)
『便利』程度の恩恵ではなく『マニア向け』の機能でもないと思います．
今現在，そもそも rvalue reference / move semantics 自体が机上の空論ですから，
これについて今何を語っても "almost as much of a hoax as Artificial Intelligence"
でしかないですが，それを承知であえて， rvalue reference / move semantics は
OOP・汎用プログラミング・関数プログラミング・効率・リソース管理・例外安全性
スレッド安全性など，ほぼあらゆるプログラミングパラダイム・概念の全域，
あと特にこれらの概念が交錯する領域での貢献が極めて大きい，
C++0x における (C++98 以来) 最大の進化だと主張したいです．
218:デフォルトの名無しさん
06/11/29 01:42:23
とマニアが言っております
219:デフォルトの名無しさん
06/11/29 01:48:06
いっそのこと名前空間std0xに新しいライブラリを作って、名前空間stdごと非推奨にしてしまえ。
220:デフォルトの名無しさん
06/11/29 12:59:00
>>219
明暗！
221:デフォルトの名無しさん
06/11/29 16:09:12
言い得て妙な変換だなｗ
222:デフォルトの名無しさん
06/11/29 17:42:23
namespace std0x
{
using namespace std;
}
223:デフォルトの名無しさん
06/11/30 08:53:29
namespace std0x = std;
224:デフォルトの名無しさん
06/11/30 13:36:58
もうここはあれだ、Andrei Alexandrescu あたりに超変態的 template
テストケース書いてもらってさ、これにパスしないと C++0x 準拠とは
名乗らせないってのはどうよ。
もうさ、これまでみたいなコンパイラ毎の ifdef 分岐の嵐はさすがにもう
勘弁して暮れって感じ
225:デフォルトの名無しさん
06/11/30 13:50:21
>>224
テストケースには boost 使えばいいんじゃねーの。
mpl ができてから、それ使ってコーディングした部品も増えてるし。
226:デフォルトの名無しさん
06/11/30 14:41:25
>>224
Discriminated Unions みたいに変態的すぎて
すべてのコンパイラでコンパイルが通らないなんて
ことになりそうだなｗ
227:デフォルトの名無しさん
06/11/30 16:22:54
BOOST_FOREACHは実際そうなので
それぞれのコンパイラのバグでエミュレートしている
恐ろしい
228:デフォルトの名無しさん
06/11/30 16:52:46
"D&E"もC++0xに合わせて更新してくれ。
"Inside the C++ Object Model"でもいいけど、やつは既にC#の一味か…
229:デフォルトの名無しさん
06/11/30 20:58:15
>>217
その熱い主張に興味がわいてきた。
rvalue ref.とmove semanticsがどういうものか、もう少し語ってはくれまいか。
230:デフォルトの名無しさん
06/11/30 23:42:40
>>217
Cryoliteたん？
231:デフォルトの名無しさん
06/12/05 21:36:18
>>215です。
>>217さんのおっしゃることには技術的に白黒の付く部分については同意です。
けど、やっぱりそうなるとC++はどんどんマイナー言語になっていくと思います。
じゃあ拡張しなければいいのかというとそういうわけでもないんですが…
C++の前に萌えた言語(システム)がCLOSである私としては切ない気持ちです。> マイナー化
232:デフォルトの名無しさん
06/12/05 22:07:30
rvalue referenceってなんなのさ？
233:デフォルトの名無しさん
06/12/05 22:37:14
ここで。
A Brief Introduction to Rvalue References
URLﾘﾝｸ(www.open-std.org)
234:デフォルトの名無しさん
06/12/05 22:49:58
>>233
よく纏まっていてわかりやすいね。
235:デフォルトの名無しさん
06/12/06 09:50:22
auto_ptr とかホントは廃止したくてたまらないんだろうなあ＞委員会
とりあえず、Deleter 指定できる unique_ptr 使って std::move してね☆
とか言いつつ、Effective C++ で「shared_ptr 使え、以上」とか書かれそう
236:デフォルトの名無しさん
06/12/06 12:13:53
>>235
一度、標準に採用されたらベンダーの独自拡張じゃないから安心して使ってねっていう
意味を暗に含むから非推奨にはなっても廃止はまずありえんだろうな。
237:デフォルトの名無しさん
06/12/07 04:52:50
ていうか、その非推奨じたいをC++はもっとガンガンやるべき。
そこら辺のGURUな人々に無茶苦茶やらせるより先に
標準もっと仕事しやがれこんちくしょー、みたいな。
ストラスストラップのハゲの残り少ない髪の毛引き抜いて
クローンハゲを量産して、規格の策定に充てるとかすればいいんじゃないのかと思った。
238:デフォルトの名無しさん
06/12/08 18:26:39
その前にrvalue referenceが導入されるのか？って感じだが
かなり大部分のライブラリに変更が必要になるし
239:デフォルトの名無しさん
06/12/09 01:08:57
ここで>>217に戻る。
240:デフォルトの名無しさん
06/12/09 01:15:54
まあ導入されれば便利にはなるんだけどね。
便利なだけじゃなくパフォーマンスゲインも5倍以上になるし
241:デフォルトの名無しさん
06/12/09 05:11:42
>パフォーマンスゲインも5倍
なにその機動戦士ガンダム
242:デフォルトの名無しさん
06/12/09 09:13:34
こいつをお前のC++コンパイラに取り付けろ。
すごいぞぉ。
コンパイラの性能は5倍以上跳ね上がる。
243:デフォルトの名無しさん
06/12/09 12:42:51
コンパイル時間も5倍に…
244:デフォルトの名無しさん
06/12/09 12:56:47
>>243
そのコンパイラをコンパイルするときに５倍コンパイラを使えばへっちゃらですよ
245:デフォルトの名無しさん
06/12/09 16:56:31
父さん、言語拡張症にかかって…
246:デフォルトの名無しさん
06/12/09 22:35:18
これからは言語のモジュール化ですよ。
247:デフォルトの名無しさん
06/12/10 07:07:20
>>244
おまえマジで頭いいな
じゃあそのコンパイラをそのコンパイラでコンパイル
したらさらに5倍早くなるんじゃね？
248:デフォルトの名無しさん
06/12/10 08:50:22
>>247
お前マジ天才じゃね？
249:デフォルトの名無しさん
06/12/10 10:16:27
最終的には今日コンパイルすると昨日完了するようになる
250:デフォルトの名無しさん
06/12/10 10:20:32
そのコンパイラでコンパイラをコンパイルさせてください。
251:デフォルトの名無しさん
06/12/10 10:53:35
おまいらホント暇だなｗ
252:デフォルトの名無しさん
06/12/10 17:55:34
最新のドラフトに static_assert っていうキーワードがあったんだけど、
キーワード増えるのってこれだけかな？
253:デフォルトの名無しさん
06/12/10 19:57:26
ドラフトレベルならもっとがっつりあるぞ。
コンセプトだけでも concept,concept_map,where,axiom,late_check
他にも alignof とか decltype とか constexpr とか
254:デフォルトの名無しさん
06/12/10 20:04:18
autoはC++09に確実に入るんじゃないのかな?
255:デフォルトの名無しさん
06/12/10 20:17:08
標準委員会、キーワード追加症にかかって…
256:デフォルトの名無しさん
06/12/10 20:22:14
>>254 それはずっと前からキーワード。
257:デフォルトの名無しさん
06/12/10 20:56:19
意味が変更される予約語はautoだけかな
258:デフォルトの名無しさん
06/12/14 13:27:42
しかしautoはどうかと思う…
型の弱い言語みたいだ
259:デフォルトの名無しさん
06/12/14 13:32:51
初期化される時点で型が決まってしまうのに、どこが弱いんだか。
260:デフォルトの名無しさん
06/12/14 14:11:35
コンパイル時に型が決定するのだから、弱いわけがないわな。
261:デフォルトの名無しさん
06/12/14 14:17:45
しかしtemplate引数の省略はどうかと思う・・・
型の弱い言語みたいだ
262:デフォルトの名無しさん
06/12/14 14:19:49
しかしboost.Anyが実装できるのはどうかと思う。
型の弱（ｒｙ
263:デフォルトの名無しさん
06/12/14 19:08:59
キャス(ry
264:デフォルトの名無しさん
06/12/14 20:18:58
vo(ry
265:デフォルトの名無しさん
06/12/14 20:29:55
悲しいかな、reinterpret_castやvoid*などの存在で、
C++が弱い型付けと分類されていることを見かける。
266:デフォルトの名無しさん
06/12/14 20:44:04
まあ強い型付けされるとキーボードも痛みやすいからな…弱くていいんじゃないの
267:デフォルトの名無しさん
06/12/14 21:48:36
その理屈だと、アセンブラは弱い肩か？
268:デフォルトの名無しさん
06/12/14 23:04:19
アセンブラは弱すぎ。虚弱体質だな。
269:デフォルトの名無しさん
06/12/14 23:12:43
低級言語は型とかないだろ
270:デフォルトの名無しさん
06/12/14 23:31:02
>>265
まさにカタ無しだね
271:デフォルトの名無しさん
06/12/15 00:04:48
しかしこのスレの流れはどうかと思う。
頭の弱い……
272:デフォルトの名無しさん
06/12/21 11:30:13
JIS X3014:2003って、
ISO/IEC 14882:2003の逐語訳じゃないんですね。
省略されているところがあってびっくりしました。
13.3.1.2.3のnon-memberのところ。
273:デフォルトの名無しさん
07/01/03 19:15:16
>>272
JISチームのチョンボで抜けちゃったとかじゃなくて？
そういえば、JIS X3014:2003 って買った時期によってPDFの"しおり"があったりなかったり
するらしいね。なんか以前、cppll で金返せ的なことを愚痴ってたヤツがいた。
274:デフォルトの名無しさん
07/01/12 19:40:21
シンボルの undef とこっから先 const の機能がほしい
スレ違いか？
275:デフォルトの名無しさん
07/01/12 20:41:03
シンボルの undef というか、スコープ付の define がほしい。
ここから先 const はいらんなあ。値を変えるところと変えないところで
関数が分かれてないのは設計ミスだと思う。
276:デフォルトの名無しさん
07/01/12 22:21:49
派生の禁止はできるようにならんの？
277:デフォルトの名無しさん
07/01/12 22:29:27
URLﾘﾝｸ(article.gmane.org)
278:デフォルトの名無しさん
07/01/12 23:23:42
あーなるほどね、宣言は出来るけどインスタンスは作れない、と。
279:デフォルトの名無しさん
07/01/12 23:29:21
>>273
>JISチームのチョンボ
まことしやかにささやかれてるけど真実味あるなｗ
280:デフォルトの名無しさん
07/01/13 03:24:39
>>276
あと、派遣の禁止も欲しいよなぁ。
281:デフォルトの名無しさん
07/01/13 23:29:46
>>277
古い。illegal
noninheritableがどっかにあったな
282:デフォルトの名無しさん
07/01/13 23:44:57
boostはなんでこのての接頭辞が non なんだろう。 not や um だとなにがまずいんだろう。
283:デフォルトの名無しさん
07/01/13 23:47:38
-ableにnotは不味いだろ。
284:デフォルトの名無しさん
07/01/13 23:50:06
>>283
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
285:デフォルトの名無しさん
07/01/13 23:51:08
>>282
英語的にはunが正しい。
何故nonになっているのかは不明
286:デフォルトの名無しさん
07/01/13 23:56:44
im と un を混同したのではないか
287:デフォルトの名無しさん
07/01/14 08:33:30
Boostスレかどこかで非英語圏向けにあえてnon-にしていると聞いたことがある。
288:デフォルトの名無しさん
07/01/14 17:09:42
それは俺の戯言なので真に受けないように
289:デフォルトの名無しさん
07/01/14 22:53:43
Effectice C++ 3版でも突っ込まれてたような
290:デフォルトの名無しさん
07/01/26 20:55:16
URLﾘﾝｸ(en.wikipedia.org)
右辺値参照についてここでは一言も触れていないけど、C++0xに入るんだよね？
291:デフォルトの名無しさん
07/01/27 09:21:41
未定
292:wankuma
07/01/27 19:20:53
わんくま加盟求む
URLﾘﾝｸ(blogs.wankuma.com)
293:デフォルトの名無しさん
07/02/19 19:49:16
URLﾘﾝｸ(herbsutter.spaces.live.com)
>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:デフォルトの名無しさん
07/02/19 20:04:02
もうC++0fでいいよ。
295:デフォルトの名無しさん
07/02/20 03:31:04
どうせVC7.1であと10年がんばるんですよ
296:デフォルトの名無しさん
07/02/20 08:41:21
>>295
スレ違い。
297:デフォルトの名無しさん
07/02/20 12:48:39
>>157
298:デフォルトの名無しさん
07/03/03 09:39:19
vector<int> v;
auto var = v.begin();
と型推論？ぽい事ができる様になるらしいですが、
この時のvarの型は
vector<int>::iterator
になるんでしょうか それとも
vector<int>::const_iterator?
299:デフォルトの名無しさん
07/03/03 10:30:49
前者でないと困る。
前者なら、後者はauto const varという宣言で済むと思うが。
300:デフォルトの名無しさん
07/03/03 10:34:50
そうすると、vector<int>::const_iteratorではなくて、
cont vector<int>::iteratorになりそうな
301:デフォルトの名無しさん
07/03/03 11:14:10
const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。
302:デフォルトの名無しさん
07/03/03 11:19:20
ああboost::cref使えば良さそうな気がする
303:デフォルトの名無しさん
07/03/03 11:20:36
vector<int> v;
auto var = const_cast<const vector<int>&>(v).begin();
これでいいでしょ？
304:デフォルトの名無しさん
07/03/03 11:24:56
vをconstにしたいって話でcref？
305:デフォルトの名無しさん
07/03/03 11:27:11
>>303
それやるならstatic_castだろ。
型名書くのがめんどくさい場合はcrefじゃね？
306:デフォルトの名無しさん
07/03/03 11:28:58
C++0xを知らんけど
そんなことしてまでauto使う意味わかんね。
307:デフォルトの名無しさん
07/03/03 11:31:24
どっちかっていうと
そんなことまでしてconst_iteratorにする意味わかんね。
308:デフォルトの名無しさん
07/03/03 11:48:48
こういう手もある。まあかえって長ったらしくなっているけど。
boost::range_const_iterator<decltype(v)>::type var = v.begin();
309:デフォルトの名無しさん
07/03/03 11:57:47
アホが来た
310:デフォルトの名無しさん
07/03/03 12:03:54
>>301
cbegin(), cend(), crbegin(), crend() がイイんじゃね？
URLﾘﾝｸ(www.open-std.org)
最新のドラフトには載ってるから、採用されたのかな？
311:デフォルトの名無しさん
07/03/03 12:23:44
boost::cref (std::tr1::cref) では無理なのでは？
template< class T >
T const &as_const( T &x )
{ return x; }
とか作って使うのではダメなん？
312:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/03 13:16:55
boostにconst_beginってなかったっけ？
314:デフォルトの名無しさん
07/03/03 13:20:02
こんにちは、rvalueの型をconst_iteratorにすべく、華麗なるタイプ速度を披露する皆様。
315:デフォルトの名無しさん
07/03/03 13:27:28
>>312
get() 使うなら当然できるけれど，それなら311で良いのでは？
316:デフォルトの名無しさん
07/03/03 19:12:34
v.begin()じゃなくて、begin(v)を使う派なのだが
（これだと、配列にもbegin(a)とか使えるし、crbegin(v)なんかもできる）
こんな人にも、autoは役に立つのかしらん？
317:デフォルトの名無しさん
07/03/03 20:28:01
auto v = v.begin() const;
みたいな呼び出しができたらいいのにと思った
318:デフォルトの名無しさん
07/03/03 20:38:02
const audo v = v.begin()
の方がいいかも！？と思った
319:デフォルトの名無しさん
07/03/03 22:25:17
>>318
>>300
流れよめんのか
320:デフォルトの名無しさん
07/03/05 08:00:08
const_付きのが欲しかったらboost::refと似たようなものを
コンテナ側に被せればいいのかな。
321:デフォルトの名無しさん
07/03/05 09:26:00
containerの場合は、>>310のcbegin()で、今のところwファイナルアンサーです。
出典は、URLﾘﾝｸ(www.open-std.org)
二バージョンないケースでは、何か工夫する必要があるね。
322:デフォルトの名無しさん
07/03/05 10:13:24
一文字の接頭辞が複数続くのってなんかいやん
crend とかなにって感じー
323:デフォルトの名無しさん
07/03/07 00:05:13
何だかんだで、const auto& cv(v);
してから、cv.begin(), cv.end() が一番読みやすいかも
324:デフォルトの名無しさん
07/03/07 16:48:34
数学の関数とかみたいに
コンパイル時に式自体
を計算・展開できるような式関数導入して欲しい。
325:デフォルトの名無しさん
07/03/07 18:43:00
実装も添えて提案して頂かないとイメージが沸かない
326:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/03/07 20:07:41
今時のコンパイラならそのくらいは最適化の範囲内でやるだろ。
328:デフォルトの名無しさん
07/03/07 20:43:12
>>326
少なくとも 5+1 を 6 にするほうは、コンパイラは必ずやらなければならない(must)と
規定されている。インライン関数のほうもほとんどのコンパイラがやると思う。
329:デフォルトの名無しさん
07/03/07 23:01:37
がんばってtemplateでsinを実装するんだ(w
330:デフォルトの名無しさん
07/03/07 23:04:59
整数演算だけでか？ｗ
331:デフォルトの名無しさん
07/03/07 23:15:43
前に、どこかのスレで、nontype templateのメタプログラミングで、浮動小数点数を実装したという猛者がいた気がする。
332:デフォルトの名無しさん
07/03/07 23:26:01
コンパイル時変数と実行時変数を明示的に区別して定義できるようにならないかなあ。
いっそのことプログラムの実行そのものをコンパイル時と実行時で分けて、
コンパイル時実行ではインタプリタ型で動いて、コンパイル時変数にのみアクセス可能で
JavaScriptばりにクラスのメンバ関数の追加や削除、関数の構成、evalができて、とか。
333:デフォルトの名無しさん
07/03/07 23:29:13
D 言語でいいよ、もう。
334:324
07/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:デフォルトの名無しさん
07/03/08 00:05:30
スクリプトでも使ってジェネレートした方がはやくね？
336:デフォルトの名無しさん
07/03/08 00:40:01
プリプロセッサ強化だな。
337:デフォルトの名無しさん
07/03/08 01:35:03
URLﾘﾝｸ(video.google.com)
コンセプト今まで知らなかったけれど、かなりよさそう。
コンパイル時間が気になるけれど。
338:デフォルトの名無しさん
07/03/08 09:01:29
templateの処理をプリプロセッサの役割とする
↓
Cでもtemplateできるようにする。
339:デフォルトの名無しさん
07/03/08 09:50:31
Cfrontみたいだな
340:デフォルトの名無しさん
07/03/08 11:46:16
もう終わった言語なんだから、なるべく互換性保持に努めてくれたまえ
341:デフォルトの名無しさん
07/03/08 16:12:16
>>340
「バカヤロウ、まだ始まってもいねえよ。」
342:デフォルトの名無しさん
07/03/08 16:34:10
互換性はあるんじゃないか？今までのが非推奨になる感じで
343:デフォルトの名無しさん
07/03/08 16:35:46
old style cast とかどうするんだろ
344:デフォルトの名無しさん
07/03/08 18:25:58
>>324
再帰はできないわ，まともな制御構文はないわ，で良ければ一応
C++0x に向けて active に動いているっぽい提案
URLﾘﾝｸ(www.open-std.org)
いずれにしろ，元々が traits などに使われるのを想定した提案ですので非力極まりない
もっと抜本的な提案なら
URLﾘﾝｸ(www.open-std.org)
ですけれど，こちらは C++0x には間に合わない様子
345:デフォルトの名無しさん
07/03/14 20:34:06
C++0a になりそうな気配が濃厚になってまいりました
346:デフォルトの名無しさん
07/03/15 00:49:43
C++0x2010でいいからもう
347:デフォルトの名無しさん
07/03/15 23:22:40
それは勘弁してw
348:デフォルトの名無しさん
07/03/16 00:23:13
C+(+0x2010)
→ 0x201C
いや、わかっているよ、こう解釈されないことくらい。
349:デフォルトの名無しさん
07/03/16 15:02:28
>>346
8208www
350:デフォルトの名無しさん
07/03/26 18:39:26
C++2008
351:デフォルトの名無しさん
07/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 の概要は↓がわかりやすい
URLﾘﾝｸ(www.open-std.org)
↓は規格の変更点について
URLﾘﾝｸ(www.open-std.org)
GCC 4.3 の experimental c++0x mode で、また ConceptGCC では >217 で机上の空論と書かれていた rvalue reference、さらに decltype とともに実装されたそうで。
URLﾘﾝｸ(conceptgcc.wordpress.com)
おまいらもヒトバシラーしてみませんか？
352:デフォルトの名無しさん
07/03/28 08:47:26
Variadic Templates、入るかねえ?
353:デフォルトの名無しさん
07/04/01 22:08:44
>352
何か具体的な懸念が？
提案者自身は
>Variadic templates seem to be moving smoothly,
と言ってるけどね。
URLﾘﾝｸ(conceptgcc.wordpress.com)
354:デフォルトの名無しさん
07/04/12 07:04:47
URLﾘﾝｸ(www.devsource.com)
によれば、template aliases が入ることになっているなあ。嬉しい。
355:デフォルトの名無しさん
07/04/16 20:57:47
nameof(type) とか nameof(value) で型名のリテラルが取れたら便利だと思うんだけど
そういうのはないんかな
356:デフォルトの名無しさん
07/04/16 21:18:55
#define nameof(x) typeid(x).name()
357:デフォルトの名無しさん
07/04/16 21:21:15
typeid(hoge).name()があるでしょ。
マングルされてたりいろいろ面倒だけど。
358:デフォルトの名無しさん
07/04/16 22:08:34
typeid().name()は正直使えない
359:デフォルトの名無しさん
07/04/16 22:13:47
まあ保証されている事と言えば同一の型のname()も同一である
という事だけだからな
リフレクションのような事は正直無理
360:デフォルトの名無しさん
07/04/27 00:24:43
>352
URLﾘﾝｸ(conceptgcc.wordpress.com)
だそうな。
361:デフォルトの名無しさん
07/04/27 07:28:21
まじか。
機能的にはC++0xに入る必然性があるけれど、
さらにデバックしにくくなりそう…
variadic templatesを直接使う人じゃなくて、
variadic templatesが使われたlibraryを使う人ね。
エラーメッセージがさらにハナモゲラ化w
362:デフォルトの名無しさん
07/04/27 12:49:13
>>361
現状でも Boost.Function とか Boost.Variant とか
BOOST__PP_* で T0,T1,T2,... を生成してるやつは
エラーメッセージがハナモゲラ化してるわけで
その部分が T0... みたいに可変長ぽく省略表示されるだけで
だいぶ見やすくなると思うんだが
363:デフォルトの名無しさん
07/05/14 14:22:20
concept が入ればエラーメッセージはかなりましになるのでは？
364:デフォルトの名無しさん
07/05/14 14:24:15
URLﾘﾝｸ(www.open-std.org)
365:デフォルトの名無しさん
07/05/28 01:09:30
ほ
366:デフォルトの名無しさん
07/05/31 00:47:25
とりあえずC99準拠で
367:デフォルトの名無しさん
07/05/31 01:59:00
C99はC++の精神に反しているのに
実装にはC++の機能が必要というトンデモ言語
368:デフォルトの名無しさん
07/05/31 03:13:42
C++の精神自体がトンデモの塊だから問題ない
369:デフォルトの名無しさん
07/05/31 06:35:41
Javaのキャストみたいなもんだな
370:デフォルトの名無しさん
07/05/31 06:43:51
c99にc++の機能が必要とは初耳だな。
371:デフォルトの名無しさん
07/05/31 06:56:08
コードに1000個のバイナリを埋め込む行為自体に問題があるとは思わないかね？
372:デフォルトの名無しさん
07/05/31 07:09:44
内容的には>>360>>364で既出ですが、URLﾘﾝｸ(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:デフォルトの名無しさん
07/05/31 16:54:12
へー、N2249入るかもしれないんだ。
とうとうC++の世界でも明示的にユニコード文字列が扱えるようになるのか。
374:デフォルトの名無しさん
07/05/31 17:46:31
すると現実の実装では、事実上wchar_tがchar16_tまたはchar32_tと同じ大きさを持つ型
（当然整数型とwchar_tのようにtypedefではない）という扱いになるんだろうなと思う。
375:デフォルトの名無しさん
07/05/31 19:57:46
これですな
URLﾘﾝｸ(www.open-std.org)
そのうちstd::u16stringとかstd::u32stringとかもできるんだろか
376:373
07/06/01 00:57:02
入るかもしれないじゃないや。もう最新のドラフトに入ってるわ。
377:デフォルトの名無しさん
07/06/01 01:12:11
L"文字列" はどういう扱いになるん？
378:デフォルトの名無しさん
07/06/01 01:36:05
こんな感じかな？
wchar_t wc = L'あ'; // wcの値は実装依存 (今と同じ)
char16_t c16 = u'あ'; // c16は0x3042
char32_t c32 = U'あ'; // c32は0x00003042
379:デフォルトの名無しさん
07/06/01 01:39:40
UTF-8 は使えないの？
UTF-16BE と UTF-16LE （32も）の選択は環境依存？
380:デフォルトの名無しさん
07/06/01 01:40:47
あ、BE と LE はこのレベルでは関係ないか？
実用上面倒くさい事になりそうな気はするが。
381:デフォルトの名無しさん
07/06/01 01:44:07
UTF-8の型も用意するか、逆にUTF-32だけにするか
してほしい気もする
382:デフォルトの名無しさん
07/06/01 08:22:04
>>379
UTF-8は、
・ソースコードで使って、処理系が変換。例えばU'A'などを。(規格外)
・今後Unicode系mbsライブラリが充実させる。
って感じなんじゃないの?
383:デフォルトの名無しさん
07/06/01 08:22:49
>>376
もう規格の外に出ることはないでしょ。修正が入るだけで。
384:デフォルトの名無しさん
07/06/01 08:35:43
下地になったCのn1040には、utf-8はchar型を使ってどうのこうのって
書いてあるけど、charはビット数を保証してないよなあ
385:デフォルトの名無しさん
07/06/01 09:07:21
uint8_tと読み直せばいいんじゃない。
386:デフォルトの名無しさん
07/06/01 09:09:30
uint8_t って optional だったよね。
387:デフォルトの名無しさん
07/06/01 13:30:21
何年か経ったらwchar_tはいらない子扱いされてそうだ
388:デフォルトの名無しさん
07/06/01 15:19:52
tcharでいいじゃん
389:デフォルトの名無しさん
07/06/01 16:02:57
>>387
Unicode依存コードじゃなければ、wchar_t推奨でしょ。
>>384
char8_tのドラフトを書けw
390:デフォルトの名無しさん
07/06/01 16:43:08
>>386
つuint_least8_t
ちなみにchar16/32_tはそれぞれuint_least16/32_tと同じ大きさと規定される>>375
391:デフォルトの名無しさん
07/06/01 17:00:04
どうせウニコードなんか窓しか使わないのにイラネ
392:デフォルトの名無しさん
07/06/01 17:05:18
>>389
何年か経ってもUnicodeでないOSが残ってるかどうかｗ
393:デフォルトの名無しさん
07/06/01 17:14:12
LinuxもUTF-8なご時世になんて寝言を……
394:デフォルトの名無しさん
07/06/01 17:43:00
ふつーにEUC
395:デフォルトの名無しさん
07/06/01 18:46:06
Unicode関連のロケールが標準に入ると考えていいんだろうか・・
396:デフォルトの名無しさん
07/06/01 20:20:04
CHAR_BIT >= 8 だから、UTF-8 は char を使ったんで別にいいんでない？
397:デフォルトの名無しさん
07/06/01 20:53:50
8は保証されてるの？
398:デフォルトの名無しさん
07/06/01 21:14:54
下限が 8 なのは保証されている。
別に 9 だろうが 16 だろうが問題ないが、7 とかはない。
399:デフォルトの名無しさん
07/06/02 11:33:29
世の中のプログラマのほとんどが
>どうせウニコードなんか窓しか使わないのにイラネ
と思っていたはずなのに
>LinuxもUTF-8なご時世になんて寝言を……
になってしまったのはいつから？なぜ？
400:デフォルトの名無しさん
07/06/02 11:43:17
>>399
いつからかは知らんが、そうでもせんとまともな国際化対応できんだろうが。
401:デフォルトの名無しさん
07/06/02 11:44:01
そんなこと思ってもいませんでしたよ。
今も昔もUnicode onlyは早計すぎると思っているだけ。
なんだかんだ言ってもUnicode周辺には、
"Technical Notes", "Technical Reports"その他に、
ノウハウがたまってきているので、強力にサポートすべき。
wchar_tの実装をUnicode onlyにするなんてのには大反対。
n2249はGJ。
402:デフォルトの名無しさん
07/06/02 11:55:15
じゃぁ、wchar_t はTRON用ということでおｋ？
403:デフォルトの名無しさん
07/06/02 12:29:48
TRONはwwchar_tです。
404:デフォルトの名無しさん
07/06/02 13:10:56
でも、Windows は UTF-16 なんだよな？
405:デフォルトの名無しさん
07/06/02 13:31:23
>>404
Windows のは WCHAR であってその実装は wchar_t とは限らず unsigned short int の場合なんかもある。
406:デフォルトの名無しさん
07/06/02 13:41:47
どちらにしろ UTF-16 だろ？
407:デフォルトの名無しさん
07/06/02 15:39:01
つWM_UNICHAR
URLﾘﾝｸ(msdn2.microsoft.com)
408:デフォルトの名無しさん
07/06/02 18:51:20
char(16|32)_t用の関連関数のドラフトはc++0xに間に合うのかねえ。
is系とかprintfとかfacetとか、結構ありそうだが。
409:デフォルトの名無しさん
07/06/02 19:15:39
C95みたいに後から追補出せばいいよ
410:デフォルトの名無しさん
07/06/02 19:44:42
streamやfacetsは対応しないみたい
URLﾘﾝｸ(www2.open-std.org)
あとUTF-8の案もあった
今のところWDには含められていないけど
URLﾘﾝｸ(www2.open-std.org)
プリフィックスは E で、1バイト8ビット以上を保証すると
411:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/02 22:39:06
まあその辺はゆっくりやって、後から補完でいいんじゃないの?
Primitive typeとして導入されたわけだから、
いろいろ実装してみるための最低限のことは決まるわけだからさ。
typedefやマクロに比べて出きることが多すぎるから、慎重になるんでしょ。
413:デフォルトの名無しさん
07/06/02 22:59:52
Windows が UTF-16 だし、
デフォで UTF-16 が扱えるなら
そういう意味であちらさんにも価値はあるように思うんだけどな。
414:デフォルトの名無しさん
07/06/02 23:14:12
WCHARあるからねー
415:デフォルトの名無しさん
07/06/03 00:28:53
>>413
意味が分からない。
どれに対するレス?
416:デフォルトの名無しさん
07/06/03 00:29:10
Windowsなんかうんこ
417:デフォルトの名無しさん
07/06/03 00:29:51
>>415
>>411
418:デフォルトの名無しさん
07/06/03 00:35:57
char16_tやchar32_tのストリームを実装するとしたら
現状のワイド文字ストリームのようにマルチバイトに／へ変換するようなもんだと思ったんだが
419:デフォルトの名無しさん
07/06/03 00:35:59
それはWindowsにはニュートラルな話。
420:デフォルトの名無しさん
07/06/03 00:37:38
Windowsとか持ち出してるのはただの馬鹿だろ
421:デフォルトの名無しさん
07/06/03 00:46:50
>>418
wifstream, wcin辺りができたばかりだし、
char16_tなら、ほとんどの処理系は(sizeof(wchar_t)>2だろうから )codecvtでなんとかなるし、
char16ifstreamとかchar16cinとか乱発する前に、ちょっと考えてみるだけでしょ。
急いで、うんこライブラリを標準に入れるわけにいかないし。
422:デフォルトの名無しさん
07/06/03 00:56:23
GCC だと wchar_t は 4 だったな。
423:デフォルトの名無しさん
07/06/03 01:00:45
>>422
現在ではプラットフォーム依存。たとえば Cygwin の wchar_t は2バイト。
あと、-fshort-wchar なんてオプションもあるので、gccだからという判定は危険。
424:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/03 01:32:30
なるほど。その環境で扱える最大の文字セットも格納できる事が必要なんだ。
426:デフォルトの名無しさん
07/06/03 02:03:02
wchar_tがUnicodeじゃない処理系ってあるのかな？
427:デフォルトの名無しさん
07/06/03 02:10:30
>>426
*BSDやSolarisのi18nフレームワークがそうなんじゃないの?
428:デフォルトの名無しさん
07/06/03 04:26:58
GCC 4.3にC++0xの実験的サポート
URLﾘﾝｸ(gcc.gnu.org)
429:デフォルトの名無しさん
07/06/03 04:55:14
>>428
ﾜｸﾜｸﾃｶﾃｶしつつDLしてregexを見てみた。
@todo Implement this function.
@todo Document this function.
だらけだった。
430:デフォルトの名無しさん
07/06/03 05:36:10
w
431:デフォルトの名無しさん
07/06/04 22:53:08
MSも試験実装すればいいのに。
Cの_s系関数はフライングで取り入れたんだから。
432:デフォルトの名無しさん
07/06/05 01:37:14
C#.NET以外は捨てなんだろう
C++/CLIは後方互換性だけなんだろうし。
433:デフォルトの名無しさん
07/06/05 22:01:36
久しぶりにスレ伸びたな～
434:デフォルトの名無しさん
07/06/05 23:26:19
まあ全部俺の一人芝居なんだけどな
435:デフォルトの名無しさん
07/06/06 01:57:38
同感
436:デフォルトの名無しさん
07/06/06 10:51:13
全部俺の独り芝居だったら同感って思う必要も無かったかな、とちょっと反省してみた。
437:デフォルトの名無しさん
07/06/06 12:41:13
それがまさに独り芝居というものでは？
438:デフォルトの名無しさん
07/06/06 13:20:54
自問自答++
439:デフォルトの名無しさん
07/06/06 14:47:48
そうか、僕はここにいてもいいんだ！
440:デフォルトの名無しさん
07/06/06 16:22:24
おめでとう
441:デフォルトの名無しさん
07/06/06 16:54:37
>>431-432
まあでもC++0xに全く無関心でない様子は伺える
URLﾘﾝｸ(blogs.msdn.com)
442:デフォルトの名無しさん
07/06/06 17:40:42
そりゃSC22/WG21の中の人たちがやっているからなあ。
VC++はC++/CLIオンリーじゃないし。
443:デフォルトの名無しさん
07/06/06 17:56:40
struct S {
int m;
};
sizeof(S::m)
これが規格外だったなんて知らなかった。
そういえばこれは合法になるのかな？
template < typename T >
class Foo
{
friend T ;
}
444:デフォルトの名無しさん
07/06/06 18:38:36
>>443
nondirivableかなんかで話題にあがったが、確か違法だったと思う
445:デフォルトの名無しさん
07/06/06 18:48:08
いや、C++0xではどうなるかという話なんだけど。
446:デフォルトの名無しさん
07/06/06 22:03:04
friend のはこれ？ (PDF)
URLﾘﾝｸ(www.open-std.org)
447:デフォルトの名無しさん
07/06/07 03:54:58
443の上は通らないけど下が普通に通る…
マジ意味不明
しかもなまじ役に立ちそうなのが一層もどかしさを増幅させる
448:デフォルトの名無しさん
07/06/07 05:25:03
sizeof(S().m)みたいに一時インスタンス化すればおｋ？
449:デフォルトの名無しさん
07/06/08 12:09:52
OKでしょ。
450:デフォルトの名無しさん
07/06/17 22:03:19
ところで、wchar_tとい不細工なネーミングは、
どうにかならんのかね。
short charとか、long charとかの方が自然だ
ろうし、文法上追加の余地はあるだろうに。
451:デフォルトの名無しさん
07/06/17 22:07:28
いっそUnicode str;を入れようぜ
452:デフォルトの名無しさん
07/06/17 22:57:31
>>450
少なくとも極自然なネーミングなんだがね。
これが極自然なネーミングだとお前が思えないなら
それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
453:デフォルトの名無しさん
07/06/17 22:58:22
>>451
そんな既存のソースコードと衝突しそうな新しい予約語は却下
454:デフォルトの名無しさん
07/06/17 23:00:08
じゃ、_Unicode str;
えーい、いっそのことソースコードもUTF8強制して
文字 str = L"こんちには世界";
って書けるようにしようぜ？
455:デフォルトの名無しさん
07/06/17 23:23:48
まあでも始めからCにワイド文字型が組込型として存在したら、
単にwcharという名前になっていたとは思う
456:デフォルトの名無しさん
07/06/17 23:30:08
>>455
俺はむしろいっそのこと、int_t, double_t, char_t てなネーミングで
統一されてたほうがよかったんじゃねぇかとすら思うけどなぁ。
457:デフォルトの名無しさん
07/06/17 23:34:21
ワイドな文字ってよく考えると意味不明だよね
458:デフォルトの名無しさん
07/06/17 23:37:11
仮にUnicode型があったとして、
UTF-16かUTF-32かはたまたUTF-8かなんてことが処理系定義になりそうだｗ
459:デフォルトの名無しさん
07/06/17 23:39:23
もうUTF8って名前に決めちゃえばいいよ
460:デフォルトの名無しさん
07/06/18 08:27:41
ちょっと上の話題ぐらい読もうや。
461:デフォルトの名無しさん
07/06/18 08:36:17
>>458
UTF-8はmbs、つまりchar[]だろ。
462:デフォルトの名無しさん
07/06/18 22:47:59
>>452
確かに、2Byte=WORDという意味でword char
をwcharとするなら、別に構わないが、wchat_tと
書くと、いかにも規格外で後からつけました感が
あって、気に入らんのだがねぇ。それより、
shortやlongといった元からあり、且つwordの様に
変数のサイズを2Byteとか具体的に意識させない型の方が、
自然な感じがするんだけどねぇ。
463:デフォルトの名無しさん
07/06/18 22:50:57
名前の衝突を避けるにはダサネーミングはある程度しかたない
_Boolとかunorderd_mapとかダサすぎるし
464:デフォルトの名無しさん
07/06/18 23:10:05
ライブラリならダサネーミングも仕方ないが、予約語としてはちょっと頂けないってことじゃね？
基本的には同感。（今さらしょうがないけど）
465:デフォルトの名無しさん
07/06/18 23:10:16
virtual void hogehoge() = 0
なんて文法を導入しちゃう言語に対していまさらだな・・・
466:デフォルトの名無しさん
07/06/18 23:25:01
>>462
wchar_tのwは、wideでは？
467:デフォルトの名無しさん
07/06/18 23:47:46
>>450のshort charとか、long charとかで思い出したけど、
昔、整数型のshort (int) - int - long (int)からの連想で、
浮動小数点数型も、short float - float - long floatにすれば良かったのにと考えたことがあった
468:デフォルトの名無しさん
07/06/19 00:32:15
そうすると、long floatの省略が不可能になる罠。
まあ、long doubleは今でも省略不可だけどサ。
469:デフォルトの名無しさん
07/06/19 01:35:30
>>464
C++では予約語だが、Cではそうではない。
470:デフォルトの名無しさん
07/06/19 01:41:38
_Bool は仕方がないとは思うが失笑したな。
471:デフォルトの名無しさん
07/06/19 02:37:05
wordが2バイト圏の人か
俺の国では2バイトはhalf wordなんだな
472:デフォルトの名無しさん
07/06/19 02:40:36
MASM 使ってたら word = 2 バイトで使ってしまうな。
科学計算やってると word = 8 バイト（double）なことも多いんだがな。
473:デフォルトの名無しさん
07/06/19 04:43:21
>>462
本当にモロ、
>それはお前が勉強不足で且つ経験不足なお子ちゃまってだけな話だ。
で、ﾜﾛｽｗｗｗ
474:デフォルトの名無しさん
07/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
07/06/19 20:25:01
訂正
× >>464
○ >>473
自分を指して何やってんだが…。
476:474
07/06/19 20:29:41
また間違えた...。欝だ。
× >>462
○ >>473
病院でも行ってくる。
477:デフォルトの名無しさん
07/06/19 20:30:02
もともとobj-cはC++とは全然別物だろうに
478:デフォルトの名無しさん
07/06/19 22:43:01
>>474
なんかまだ少し勘違いしてそうだから、念のために書いておくと
必ずしも sizeof(wchar_t)==2 じゃないぞ。 sizeof(wchar_t)==4 な環境・処理系もある。
まぁ、あんまり気を落とすな。
479:デフォルトの名無しさん
07/06/19 22:58:22
gccがsizeof(wchar_t)==4でいいんだったっけ
480:デフォルトの名無しさん
07/06/19 23:51:09
-fshort_wchar フラグを指定したら 2 になるけどな。
481:デフォルトの名無しさん
07/06/20 02:58:24
>>474
C++/CLIは、WG21の中のマイクロソフトの人がどうするかにかかっていると思う。
しかし純然たる研究者だったはずの二人が、
どうしてC++/CLIに必死なのか良くワカランネ。
契約になんか書かれているのかな。
482:デフォルトの名無しさん
07/06/20 08:40:01
C++0x実現まであと9年もあるから大丈夫
483:デフォルトの名無しさん
07/06/21 22:32:37
>479
cygwin 上だと gcc でも 2。
484:デフォルトの名無しさん
07/06/22 01:24:22
今は亡き、Windows版CodeWarriorでもsizeof(wchar_t)==4。
亡くなって当然ｗ
485:デフォルトの名無しさん
07/06/22 01:24:48
>477
Objective-C++ という Obj-C の C++ 拡張が存在する
C++/CLI はどうせコンパイラの開発部分は共通だから強引に組み込むでしょ
直接ぶつかるところは少ないし、そもそも普及に至っては・・・
486:デフォルトの名無しさん
07/06/22 01:44:27
後半二行、何を言っているのかわからん。
「組み込む」対象は何なんだ?
487:デフォルトの名無しさん
07/06/22 22:10:11
え、VC の cl にだけど
488:デフォルトの名無しさん
07/06/23 10:46:35
マイクロソフトは規格への追従遅いじゃん。
メジャー番号が変わるまで延々放置って事がよくある。
スイッチで切り替えて、細心の規格に追従した動作になるってこともあまりない。
489:デフォルトの名無しさん
07/06/24 21:02:05
C++1xに名前変えるか
490:デフォルトの名無しさん
07/06/25 06:03:52
何でこんなに時間掛かるんだろう？
491:デフォルトの名無しさん
07/06/25 09:41:11
やっつけでやられても困る。
492:デフォルトの名無しさん
07/06/25 13:37:16
>>490
天才のお前が傍観者だからだよ
493:デフォルトの名無しさん
07/06/25 17:37:29
Javaの初期のクラスライブラリみたいな不細工なのは困る。
iostreamだって今になってみれば、設計し直したいところ多数。
494:デフォルトの名無しさん
07/06/25 19:56:26
>>474
ObjC++はコンパイラがC++のバージョン選べるようにしてくれるでしょ。
495:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/26 03:12:13
C++X
の方が魚の骨っぽくて好き
497:デフォルトの名無しさん
07/06/26 13:38:12
もう規格なんてやめてBoost全部取り込んじゃえよ
498:デフォルトの名無しさん
07/06/26 17:06:10
それは行き過ぎだろうけど、ライブラリをほかとは別規格にするというのはありだと思う
499:デフォルトの名無しさん
07/06/26 17:57:38
古い Fortran みたいにいくつかのレベルに分ければよかったのに、と
時々思うわけさね。
500:デフォルトの名無しさん
07/06/26 18:18:06
C++はPL/Iを超える化け物言語になりつつあるな。
501:デフォルトの名無しさん
07/06/26 22:21:29
Javaほどじゃないけどな
502:デフォルトの名無しさん
07/06/26 22:24:57
は？
503:デフォルトの名無しさん
07/06/26 22:31:00
またジャバグラマか。
504:デフォルトの名無しさん
07/06/26 23:26:45
そろそろミーティング回数増やさねえとヤヴァくね？
最近あんま進展ないし、また議論不足で vector<bool> とか auto_ptr みたいな
半端者が生まれちまうぜ
505:デフォルトの名無しさん
07/06/26 23:27:57
禿が死ぬまでには出来てると思うから気長に待つよ
506:デフォルトの名無しさん
07/06/27 03:44:26
なぁに禿が死んだら誰かが代わりに永久脱毛すればいい話
507:デフォルトの名無しさん
07/06/27 09:25:40
>500
あのALGOL系とCOBOLを無理矢理繋げたような変態言語と比べられても…
…いや、的確か
508:デフォルトの名無しさん
07/06/27 09:29:07
PL/Iを馬鹿にするなー
本当に何でもできる言語なんだぞー
あ、でも糞言語だったけどね
消えたし
509:デフォルトの名無しさん
07/06/27 09:58:55
他の言語は要らなくなるから、Programming Language/1。
510:デフォルトの名無しさん
07/06/27 10:33:28
その C++ と Objective-C を無理矢理繋げた変態言語の立場は。
511:デフォルトの名無しさん
07/06/27 22:21:53
お前ら頭良いんだからサッサと立派な規格でまとめてくれよ
512:デフォルトの名無しさん
07/06/27 22:24:43
よしきた
513:デフォルトの名無しさん
07/06/27 22:27:55
標準ヘッダファイル2chを追加
514:デフォルトの名無しさん
07/06/27 22:30:20
boostをはじめとするライブラリが整備されている今でこそC++は「使える」言語だと思えるんだけど
それらがあんまり無かった時代になんであんなに流行ったのかがいまいちよく分からない
515:デフォルトの名無しさん
07/06/27 22:33:48
競争相手が無かったから
516:デフォルトの名無しさん
07/06/27 23:05:19
C++がもしなかったらと考えると興味深い。
JavaやLL言語のようなものはあっただろうか？
LISPやSmalltalkの影響はもっと大きかっただろうか？
517:デフォルトの名無しさん
07/06/27 23:09:41
>JavaやLL言語のようなものはあっただろうか？
普通にあったんじゃない？
518:デフォルトの名無しさん
07/06/27 23:18:46
ねーよ。
C++の影響は計り知れない
519:デフォルトの名無しさん
07/06/28 01:15:28
cfront最終版の頃には、
Modula-3, Oberon, CLU, Argus, Effiel, Ada 9X, Delhpi, Smalltalkあたりが軒並死亡宣告。
NEXTSTEP, Display PostscriptのおかげでObjective-Cが生き残っている程度だった。
520:デフォルトの名無しさん
07/06/28 01:34:50
その言語大絶滅は何か原因はあるの？
//まあマイナー言語の生成消滅は常に起きてるだろうけど。
521:デフォルトの名無しさん
07/06/28 09:02:38
勝手に言ってるだけだろ。もともとニッチなのもいくつかあるし
死んでないのもいくつかあるし。
要はC++が広まりすぎて、他の言語が相対的に影が薄くなったって
ことだと思う。
522:デフォルトの名無しさん
07/06/28 09:09:11
C++とJavaは、プログラミング言語の研究者をしゃぶりつくしているけどな。
こんなに人材が集まったことは今だかつてないんじゃないか?
C++に関して言えば、マクロ(特殊化当たり前)由来のtemplateが決定打だったな。
523:デフォルトの名無しさん
07/06/28 12:08:12
C++ってマクロなんでしょ？
524:デフォルトの名無しさん
07/06/28 12:11:46
???
525:デフォルトの名無しさん
07/06/28 14:00:51
っ MFC
526:デフォルトの名無しさん
07/06/28 14:14:36
MFCとVC6は大量のC++挫折者を生み出しました
527:デフォルトの名無しさん
07/06/28 17:52:57
>>522
C++がひろがってたのはtemplate以前からだけどね。
TMPがはいって地獄がより強固になった。
528:デフォルトの名無しさん
07/06/28 20:02:22
シェア90%のOSが推奨すれば広まって当然
529:デフォルトの名無しさん
07/06/28 21:26:08
じゃあこれからはドトネト天国だね
530:デフォルトの名無しさん
07/06/28 21:38:39
C#する気もしない気も～VMの性能にかかっているんだよ～
531:デフォルトの名無しさん
07/06/28 22:21:08
C++は滅びぬ！何度でもよみがえるさ。
ネイティブコードの力こそ人類の夢だからだ
532:デフォルトの名無しさん
07/06/28 22:22:00
D が完成しさえすれば・・・。
533:デフォルトの名無しさん
07/06/28 22:50:37
ネイティブでGC無しというところが、
C++の強さにして弱み。
534:デフォルトの名無しさん
07/06/28 22:52:36
し、C++/CLIとかどうですか・・
535:デフォルトの名無しさん
07/06/29 00:03:58
Dもキメラ過ぎる
536:デフォルトの名無しさん
07/06/29 23:28:16
Dがもっとリッチに色々揃えば良いけど。
537:デフォルトの名無しさん
07/06/29 23:32:38
やっぱC++は最高だな
538:デフォルトの名無しさん
07/06/30 19:25:36
C++0xになったらどんなステキな世界が待っているんだろう。
アスペクト志向取り入れないかな
539:デフォルトの名無しさん
07/06/30 19:46:15
>533
でも委員会で GC の話してるみたいよ？
540:デフォルトの名無しさん
07/06/30 20:31:26
今のところHans Boehmの提案が最有力候補かな？
541:デフォルトの名無しさん
07/06/30 20:32:07
GC ねえ。
GC なしで組めるモードもあるんだよね？
542:デフォルトの名無しさん
07/06/30 21:19:39
C99に合わせたりはしないのかな。
543:デフォルトの名無しさん
07/06/30 21:37:25
>>541
＞GC なしで組めるモードもあるんだよね？
C++(0x)的にほぼ採用のための必須条件とおもわれ
544:デフォルトの名無しさん
07/06/30 22:30:57
>>542
だいたいのところは取り込まれてるみたい。
545:デフォルトの名無しさん
07/07/01 11:32:07
URLﾘﾝｸ(www.open-std.org)
News 2007-06-30: The 2007-06-pre-Toronto mailing is available
546:デフォルトの名無しさん
07/07/01 11:33:18
>>543
えーーー！
いくらなんでもそれは無くね？
547:546
07/07/01 11:34:11
勘違いしてた
「GCなしでも組める」事が必須条件なのね
ごめんなさい
548:デフォルトの名無しさん
07/07/01 11:51:16
C++的には、使わなければ余分なコストはかからないというのは必須だろ。
549:デフォルトの名無しさん
07/07/01 11:53:34
そこでGCCですよ
550:デフォルトの名無しさん
07/07/01 11:57:17
GCを使うか使わないかを不具合無しで簡単に切り替えられるのがいい
例えばアロケータを差し替えるだけでとかそういうので
551:デフォルトの名無しさん
07/07/01 12:00:52
GC自体はあってもいいが破棄のコードが無いと対称性が崩れてキモチワルイな
552:デフォルトの名無しさん
07/07/01 12:02:25
>>551
現行の C++ でも delete はほとんど auto_ptr や shared_ptr 任せで
コードには無いだろ。
553:デフォルトの名無しさん
07/07/01 12:03:19
>>551
ではauto_ptrやshared_ptrについてどうお考えでしょうか？
554:デフォルトの名無しさん
07/07/01 12:05:59
shared_ptrとかは削除子指定できるからな
GCも同様に削除子が指定できれるならば生成子と対照が簡単に取れるから問題なし