トップページ⇒tech
1001コメント237KB

C++0x 3

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2008/03/06(木) 21:53:47
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
0002デフォルトの名無しさん2008/03/06(木) 21:56:56
>>1 乙++0x
0003デフォルトの名無しさん2008/03/06(木) 22:26:28
>>1乙
by bjarne stroustrup
0004デフォルトの名無しさん2008/03/07(金) 04:54:57
いちおつ
ばいびょーんすっぽすっぽ
0005デフォルトの名無しさん2008/03/07(金) 06:43:35
>>1乙禿
0006デフォルトの名無しさん2008/03/07(金) 08:18:13
うちの会社には３３歳の美少女がいる
ときどき小学生と間違われている
でも処女じゃない
0007デフォルトの名無しさん2008/03/07(金) 08:19:09
>>1
wikiとwikipediaは違うぞw

MAILING 2008/02
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/#mailing2008-02
0008デフォルトの名無しさん2008/03/07(金) 10:02:14
int otu(int x) { return x >>1; }
0009デフォルトの名無しさん2008/03/07(金) 11:52:16
C++09/CLI とかヤル気あるんだろうか，マイクロソフト．
個人的には今の C++/CLI は好きだ．
0010デフォルトの名無しさん2008/03/07(金) 11:53:24
spaced keywordとか馬鹿なことやっているところが、
標準準拠を重く見ているわけがないと思う。
0011デフォルトの名無しさん2008/03/07(金) 13:23:22
spaced keyword 自体は標準で作る予定はないから、独自拡張で存在する分には
標準準拠の邪魔にはならないでしょ？
0012デフォルトの名無しさん2008/03/07(金) 13:36:54
で，GCは入るのか入らないのか．
それによって俺の人生が・・・・






もう終わってるけど
0013デフォルトの名無しさん2008/03/07(金) 13:41:43
今回は入らないはず。
けどベームさんが積極的にやってるから、
実装は今使える以上のものが出てくるんじゃないかな。
0014デフォルトの名無しさん2008/03/07(金) 13:42:24
なんだよぉ，言語使用には入らないのか．
残念だな．まぁいいか．
0015デフォルトの名無しさん2008/03/07(金) 13:49:34
>>12
イキロ
0016デフォルトの名無しさん2008/03/07(金) 14:13:18
GC使いたいと思ったことがないのでよくわからん
0017デフォルトの名無しさん2008/03/07(金) 21:54:28
boostのsharedポインターと比べて、GCって重いの？
0018デフォルトの名無しさん2008/03/07(金) 22:00:00
あれって「ベーム」って読むのか……
0019デフォルトの名無しさん2008/03/07(金) 22:10:33
>>17
ケースバイケース
0020デフォルトの名無しさん2008/03/07(金) 22:14:10
ぼえへむヽ(´ー｀)ノぼえへむ
0021デフォルトの名無しさん2008/03/08(土) 00:19:53
GC はあまり言語仕様に入れて欲しくはない。
標準ライブラリにあるのは別に構わんが。

C/C++ は色んな環境に使えることが肝なんだろうし、
そういうのは強制するもんじゃなくて
選択肢としてはありますが強制ではないですよってものであってほしい。
0022デフォルトの名無しさん2008/03/08(土) 00:24:30
強制するしないと、言語側かライブラリ側かは別の問題だよ。
個人的には「強制しない」「言語側」を支持する。
0023デフォルトの名無しさん2008/03/08(土) 00:42:54
gcnew みたいなやつか。
まさに C++/CLI だけど、あの珍妙な文法を見ると・・・。
0024デフォルトの名無しさん2008/03/08(土) 00:59:21
C++/CLIは考え方としては悪くないと思う。でも確かに文法設計のセンスは悪い。
0025デフォルトの名無しさん2008/03/08(土) 01:07:33
Foo<Hoge^>^
　　　　　　↑笑うなよ！
0026デフォルトの名無しさん2008/03/08(土) 01:09:14
今や Unicode が普通なんだから、もうちょっとマシな文字を使えよ、ってかｗ
0027デフォルトの名無しさん2008/03/08(土) 01:10:43
なんなんだろうな、あれは。
C++界隈で相当に有名な人が設計していて、
目指す方向は悪くないのに。
やっぱり言語設計は別物なんだな。

>>22
俺も言語側に何かないと今出てる以上のものは難しいと思う。
けど最低限のもので、汎用に使える聞こうにして欲しい。
まあ禿がいる限りそう言うものしか出てこないだろうけども。
0028デフォルトの名無しさん2008/03/08(土) 01:12:33
Pascalの時代は、^を↑と表示するシステムがあったらしいが…
0029デフォルトの名無しさん2008/03/08(土) 01:13:45
>>26
Foo<Hoge※>※
0030デフォルトの名無しさん2008/03/08(土) 01:16:12
Foo<Hoge/>/
0031デフォルトの名無しさん2008/03/08(土) 01:27:29
Foo<Hoge\>\
Foo<Hoge@>@
Foo<Hoge!>!
Foo<Hoge*>*
0032デフォルトの名無しさん2008/03/08(土) 01:39:01
* に対応する記号としてはやはり / だな・・・。
積つながりの & は既にアドレスや参照で使われてるし。
0033デフォルトの名無しさん2008/03/08(土) 01:42:56
Foo<Hoge/>/
ちょっとXMLっぽいｗ
0034デフォルトの名無しさん2008/03/08(土) 10:28:02
>>26
m17n界隈にはcharacter set independenceとかISO 2022に執着してる
アンチUnicodeの人がまだ生きてるし、変換表地獄でリアルに困ってる人もいるから、
EBCDICを気にしなくていい環境でもASCIIの範囲をはみ出すのはやめた方がいい。
特にメタ文字に使うような記号類は化けやすいし文字幅問題も出てくるから。
0035デフォルトの名無しさん2008/03/08(土) 10:50:56
女子中学生の話題でもちきりですね
0036デフォルトの名無しさん2008/03/08(土) 12:35:01
gcc4.3ｷﾀｰ
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html
Status of Experimental C++0x Support in GCC 4.3

Rvalue references N2118 Yes
Rvalue references for *this N2439 No
Variadic templates N2242 Yes
Static assertions N1720 Yes
Declared type of an expression N2343 Yes
Right angle brackets N1757 Yes
Default template arguments for function templates DR226 Yes
Extern templates N1987 Yes

C99 Features in C++0x
__func__ predefined identifier N2340 Yes
C99 preprocessor N1653 Yes
long long N1811 Yes

もちろんg++起動オプションでオンにしたときだけ。
http://gcc.gnu.org/gcc-4.3/changes.html
0037デフォルトの名無しさん2008/03/08(土) 12:48:43
こんせぷとまっぷはﾏﾀﾞｰ？
0038デフォルトの名無しさん2008/03/08(土) 16:01:56
Right angle brackets N1757 Yes
うおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお
0039デフォルトの名無しさん2008/03/08(土) 16:26:47
ケータイからだとさっぱりわからん
詳しく
0040デフォルトの名無しさん2008/03/08(土) 16:29:48
携帯からでも読んでワカラン奴は必要ないということ。
0041デフォルトの名無しさん2008/03/08(土) 16:34:38
右辺値参照 N2118 Yes
*thisの右辺値参照 N2439 No
可変個引数テンプレート N2242 Yes
静的アサーション N1720 Yes
式に対するdecltype N2343 Yes
山括弧閉じの件 N1757 Yes
テンプレート関数のデフォルトテンプレート引数 DR226 Yes
Extern templates N1987 Yes
0042デフォルトの名無しさん2008/03/08(土) 16:35:26
DR226ｷﾀｰ!
0043デフォルトの名無しさん2008/03/08(土) 16:36:26
>>38
ｋｔｋｒ
0044デフォルトの名無しさん2008/03/08(土) 16:38:50
結局、Proposed resolution (revised October 2002)でアクセプトされたのかな。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226
draft読まないとな。ディフォルト引数便利だし。
0045デフォルトの名無しさん2008/03/08(土) 17:50:46
>>6
相手は誰だ…
うらやましすぐる
0046デフォルトの名無しさん2008/03/08(土) 18:43:27
ローアングルブラジャー！？(;ﾟДﾟ)ポロリもあるよ！！
0047デフォルトの名無しさん2008/03/19(水) 00:34:38
最後の書き込みがブラジャーだと哀れなので保守
0048デフォルトの名無しさん2008/03/19(水) 20:09:10
Javaのクロージャが、
制御文やループ文のブロック仮引数使えて面白いんだが…

withLock(lockVar) {
// do something
}
void withLock(Lock l, {Lock => void} b) { ...

for foo(T i : aCollection) {
// do something
}
void foo(C<T> c, {T => void} b) { ...
0049デフォルトの名無しさん2008/03/26(水) 00:05:23
ラムダ式はN2550でだいたい決まりかな
<> が [] になって、中にキャプチャ変数並べられるようにしたと
return は省略できないぽい？
0050デフォルトの名無しさん2008/03/26(水) 00:09:48
おまえら最新ドラフト来てるなら知らせてくださいよ

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf
0051デフォルトの名無しさん2008/03/26(水) 00:12:15
しかしラムダを導入するために新しいキーワードを入れる気はサラサラないんだな
0052デフォルトの名無しさん2008/03/26(水) 02:27:35
識別子に利用できるトークン列を割り当てると、
下方互換性がなくなるからね。
あまり奇怪な記号列も困るけどラムダ式は俺的にギリギリセーフ。

あとconceptのexportは取り下げられたねw
0053デフォルトの名無しさん2008/03/26(水) 02:56:22
コンセプトのexport？
まさかテンプレートのexportと同じように、
別の翻訳単位のコンセプトを参照する機能？
そんなのあったんだ。そりゃはいらないだろうなぁ

N2550を、今読んでいるんだけど、文法がものすごくキモいな。
本当に新しいキーワードがほしい。
新しいキーワードさえあれば、
どこでlambdaを使っているか、メモ帳ですら検索できるのに。


0054デフォルトの名無しさん2008/03/26(水) 03:27:16
俺も素直にキーワード導入した方がいいと思う。
検索のやりやすさが全然違う。
0055デフォルトの名無しさん2008/03/26(水) 04:26:40
N2550を読んだのだけれど、lambda-parameter-declarationって、
もしかして省略できる？
つまり、

[](){}() ;

と同じ意味で

[]{}() ;

は可能？

しかし、邪悪なコードだ。
0056デフォルトの名無しさん2008/03/26(水) 07:11:36
ラムダ用に新しい記号を導入してくれれば・・・
0057デフォルトの名無しさん2008/03/26(水) 11:20:09
そんなに互換性を気にするならひらがなでも使えばいい。
std::for_each(v.begin(), v.end(), ら(int x) {std::cout << x;});
0058デフォルトの名無しさん2008/03/26(水) 12:15:33
λでいいじゃん。

λ.....ﾄﾎﾞﾄﾎﾞ
0059デフォルトの名無しさん2008/03/26(水) 12:30:25
#define lambda []
#define closure(captures) [captures]
こんなんほしいかもな。
0060デフォルトの名無しさん2008/03/26(水) 12:31:44
>>55
文法のところにはっきり opt と書いてあるだろ。
0061デフォルトの名無しさん2008/03/26(水) 19:02:17
$ 使おうぜ
0062デフォルトの名無しさん2008/03/26(水) 19:21:48
盲点なような気がするが、\ を使えばいい気がする。
0063デフォルトの名無しさん2008/03/26(水) 19:36:11
よくない
0064デフォルトの名無しさん2008/03/26(水) 20:23:14
inlineとか使えそうだけどな

int n = 10;
auto x10 = inline [n] (int a) { return a * n; }
0065デフォルトの名無しさん2008/03/26(水) 21:04:17
inline ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!
0066デフォルトの名無しさん2008/03/26(水) 21:47:25
そこでvolatileですよ
0067デフォルトの名無しさん2008/03/26(水) 21:55:47
export でどうだ
0068デフォルトの名無しさん2008/03/26(水) 21:57:59
extern だな。
0069デフォルトの名無しさん2008/03/26(水) 21:58:59
inline は正直結構イケるんじゃないかと思った。
0070デフォルトの名無しさん2008/03/26(水) 22:01:07
#define Lambda
0071デフォルトの名無しさん2008/03/26(水) 22:02:11
書いても書かなくてもいいタイプのマクロは害悪にしかならない。
構文に影響を与えるタイプのマクロも混乱を招くしかない。
しかし元の文法からして微妙。
どうすればいいんだ。
0072デフォルトの名無しさん2008/03/26(水) 23:43:51
おまえらもうあきらめろｗ
100回くらい使ってれば慣れるよきっと
0073デフォルトの名無しさん2008/03/26(水) 23:44:27
自分はいいんだ。問題は一見さんとかに説明するとき。
0074デフォルトの名無しさん2008/03/27(木) 00:42:10
「100回くらい使ってれば慣れる」って説明すれば良いのでは？ｗ
0075デフォルトの名無しさん2008/03/27(木) 05:49:53
decltype(x) lambda(x) { return x; }
0076デフォルトの名無しさん2008/03/27(木) 07:40:59
美少女中学生にバイブをプレゼントした時みたいな反応だな

最初の抵抗感から最終的な快感への淫靡なプロセスをたどるわけだ
0077デフォルトの名無しさん2008/03/27(木) 10:58:46
いや、その形状がドン引きするような感じだって話なのではw
0078デフォルトの名無しさん2008/03/27(木) 11:49:13
というか美少女中学生にバイブにしろ何にしろ何かをプレゼントする機会なんてあるのかよ。
0079デフォルトの名無しさん2008/03/27(木) 13:39:31
あるか、ないか、ではなく、つくるんだよ。迷惑だろうけど。ｗ
0080デフォルトの名無しさん2008/03/27(木) 19:36:34
プレゼントではなくセクハラです。
0081デフォルトの名無しさん2008/04/06(日) 20:01:37
何イッとるんだこのスレは
0082デフォルトの名無しさん2008/04/06(日) 20:11:06
女子中学生にラムダを教えるにはどうすればいいのか検討するスレです
0083デフォルトの名無しさん2008/04/06(日) 21:25:26
女子中学生にランダバを教えたい
0084デフォルトの名無しさん2008/04/06(日) 23:25:53
ランバダのことか。
0085デフォルトの名無しさん2008/04/06(日) 23:27:34
>>83-84ﾌｲﾀ
0086デフォルトの名無しさん2008/04/07(月) 00:16:53
しかしあのラムダの構文は邪悪すぎると思うのだが ...
旧キャスト並に邪悪だ。
0087デフォルトの名無しさん2008/04/07(月) 00:21:24
何が邪悪ですか?
旧キャストとはCスタイルのキャストのこと?
だとして、構文が邪悪?
0088デフォルトの名無しさん2008/04/07(月) 00:23:29
おい誰か lambda introducer に inline 強制しろって提案出してくれよ。
こういうときに、えぴなんとか通せばいいの？
0089デフォルトの名無しさん2008/04/07(月) 00:35:49
本来その手の提案とか defect report とかは comp.std.c++ が窓口なんだけど、
今年に入ってからトラブってるらしいんだよなあ。他の人はどうしてんだろ。
0090デフォルトの名無しさん2008/04/07(月) 00:41:35
とりあえず proposal のところに書いてあるメルアドに投げとけばよいような？
0091デフォルトの名無しさん2008/04/07(月) 07:53:48
いや、やっぱ [&] (const employee& e) {e.salary()=...}
とかいう構文は邪悪でしょう...
0092デフォルトの名無しさん2008/04/07(月) 09:39:32
だから、どう邪悪なのか説明してくれんと頭の悪い漏れには判らん
0093デフォルトの名無しさん2008/04/07(月) 11:27:58
個人的には一つのまとまりとして見づらい構文はやめて欲しいなぁ。
0094デフォルトの名無しさん2008/04/07(月) 13:27:49
キーワードがあるほうが単純に検索できて良いと思うな。
そういう意味ではCスタイルキャストのいやらしさと似てる。
0095デフォルトの名無しさん2008/04/07(月) 14:24:31
そんなに検索したいなら/*lambda*/[〜とでも書けばいいだろ
0096デフォルトの名無しさん2008/04/07(月) 15:22:33
美少女中学生のグンゼのおばんつにおかんがマジックで名前を書いている状態か！
0097デフォルトの名無しさん2008/04/07(月) 21:31:48
for も if も検索しにくいけどね
0098デフォルトの名無しさん2008/04/07(月) 21:46:43
lambdaが検索し易くなければならない理由も判らなければ、
検索しにくい事がどう邪悪なのかも判らん
もっと判り易く説明してくれ
0099デフォルトの名無しさん2008/04/07(月) 21:48:48
関数適用だって検索しにくいしなあ
関数適用が検索し易くなければならない理由もないけど
0100デフォルトの名無しさん2008/04/07(月) 22:29:38
>>97-99
なんか必死だなあｗ
どちらかといえば探せたほうがいいかな、という程度の話なんだけどね。
関数の先頭とかも検索しにくいわけだから、構わんといえば構わんか。
あとは美観の問題だね。
0101デフォルトの名無しさん2008/04/07(月) 22:39:50
>100
その程度の話なら別にいいんだけど,
邪悪だなんて穏やかでない言い方してるから
なんか構文的に問題があるなら教えてくれ、ってだけなんだけど
0102デフォルトの名無しさん2008/04/07(月) 22:41:37
ここで言ってる邪悪というのは美観の問題じゃないかな。
構文の問題とかはさすがにないんだろ、偉い人が考えたんだから。ｗ
0103デフォルトの名無しさん2008/04/07(月) 23:13:22
いや、どう考えても邪悪な類のコードだろ
0104デフォルトの名無しさん2008/04/07(月) 23:17:11
goto は何にでも使えるから邪悪なように、
使い回すにしてもどれを使い回すか結構考えないと、
goto と同じくらい邪悪になってしまう。
0105デフォルトの名無しさん2008/04/07(月) 23:19:39
ラムダ式の何がどう邪悪なのかもうちょっとｋｗｓｋ
0106デフォルトの名無しさん2008/04/07(月) 23:21:28
レベルの低い奴は無視しろ
0107デフォルトの名無しさん2008/04/07(月) 23:50:42
おっぱいの標高が低い美少女中学生ならみっちりねっとりお相手をお願いしたい
0108デフォルトの名無しさん2008/04/07(月) 23:51:44
括弧が続いて読みづらい
0109デフォルトの名無しさん2008/04/07(月) 23:57:24
コンビネーションですむのにそうしないところがラムダ式の存在の邪悪さ
0110デフォルトの名無しさん2008/04/07(月) 23:59:44
それを言うならコンビネータじゃなかろか？
0111デフォルトの名無しさん2008/04/08(火) 00:05:07
何か勘違いしてるんじゃないか？
コンビネータもλ式の一種だぞ。
0112デフォルトの名無しさん2008/04/08(火) 00:08:03
単に [&] という三文字の並びがキモイ
0113デフォルトの名無しさん2008/04/08(火) 00:10:44
俺は >>112 だな。難しいことはよくわからん。ｗ
0114デフォルトの名無しさん2008/04/08(火) 00:12:54
キモいよな。
0115デフォルトの名無しさん2008/04/08(火) 00:18:39
エディタのマクロで保存時にλを[&]に変換すれば桶
0116デフォルトの名無しさん2008/04/08(火) 00:24:35
白スクを着てひざを抱えつつこっちを見てにっこりしている美少女中学生にしか見えない
0117デフォルトの名無しさん2008/04/08(火) 00:27:35
ついにC++も AA 言語になってしまうのだなあ
0118デフォルトの名無しさん2008/04/08(火) 00:40:30
新しい刺激に慣れるのに時間が掛かるタイプの人がいるのですね
0119デフォルトの名無しさん2008/04/08(火) 00:52:29
いじりまわせばくせになる！！！！！！！！！！！！！！！！！！！！！！！！！
0120デフォルトの名無しさん2008/04/08(火) 01:01:22
Perl とかいつまで経ってもキモいし。
0121デフォルトの名無しさん2008/04/08(火) 01:09:38
美少女中学生のアレはキモくないぞ
0122デフォルトの名無しさん2008/04/08(火) 01:10:04
同じシンボルでも$とか@とか[]とかの付けかたで参照する変数が違うからなー
0123デフォルトの名無しさん2008/04/08(火) 01:16:09
つける下着で印象が変わるわけだな
0124デフォルトの名無しさん2008/04/08(火) 02:02:33
今<>のパース失敗してるみたいに
[&]とoperator[]が絡んでおかしなことにならねえかな
0125デフォルトの名無しさん2008/04/08(火) 02:03:22
"λ" が使えない処理系ではtrigraphとして "[&]" で代用しても良いというのなら許す
0126デフォルトの名無しさん2008/04/08(火) 02:45:24
autoでもわかるように、どうあっても予約語増やす気は無いんだろう
0127デフォルトの名無しさん2008/04/08(火) 02:49:24
おまえらはもうboostのラムダつかってなさい
0128デフォルトの名無しさん2008/04/08(火) 03:03:30
__TheLambdaExpressionKeywordOfC++0xとか絶対かぶらないようなキーワードにすればいいのに
0129デフォルトの名無しさん2008/04/08(火) 07:31:32
_Lambda をキーワードとして採用し、
#define lambda _Lambda を行うヘッダファイル lambda を用意すればいい。
0130デフォルトの名無しさん2008/04/08(火) 08:31:41
美少女中学生の全裸ランバダ
0131デフォルトの名無しさん2008/04/08(火) 08:36:47
>>129
それなんて _Bool ?
0132デフォルトの名無しさん2008/04/08(火) 13:16:48
美少女中学生と lambda がいい具合に入り乱れててワロタw
0133デフォルトの名無しさん2008/04/08(火) 14:23:30
ここまで来ると lisp 系言語の () の方が可愛く見えるな > lambda
0134デフォルトの名無しさん2008/04/08(火) 19:27:05
この先も予約語増やさずに変な記号の組み合わせや予約語の転用でどんどん機能増やしていくんだろうか
C++2xくらいでは酷いことになってそうだ
0135デフォルトの名無しさん2008/04/08(火) 19:43:39
オペレーター定義可能なHaskellに比べたら
0136デフォルトの名無しさん2008/04/08(火) 20:06:52
C++の将来は墓穴掘ってユーザーからサヨナラされそうだな
0137デフォルトの名無しさん2008/04/08(火) 20:10:45
既にもうマイナな言語だから大丈夫。今でも使ってる好き者たちなら付いてくるさ。ｗ
0138デフォルトの名無しさん2008/04/08(火) 20:19:48
2029年か。想像できんな。
妄想してみるか。

・十分にハードウェアが高速になったとして、とうとうC++にもevalを導入
・メタプログラミングや賢いマクロを積極的に仕様に盛り込むことで、新たな文法を定義可能
　例えば、LispやPerl、Pythonはおろか、Brainf*ckやWhitespaceまでもがC++としてコンパイル可能
・現実世界で、本当にほしいライブラリが標準規格に盛り込まれる（XMLとかUnicodeとか）
・Bjarne Stroustrupがフサフサになる

C++以外の妄想
・宗教戦争は終わらない：言語、OS、コンパイラ、エディタ
・既に64bitが主流になり、32bitコードは16bitコードなみの扱いを受けている
・メモリを数十GB確保することは当然である
・そのようなハードウェアでも、最新の3Dゲームはまだ遅い
・96DPIより高いDPIのディスプレイが使われている。
0139デフォルトの名無しさん2008/04/08(火) 20:31:44
関数型言語が主流になっているだろうな
0140デフォルトの名無しさん2008/04/08(火) 20:57:47
>>138
2029年までC++は現役でいられるんだろうか？…
寧ろ、現役であることのほうが問題だとも感じてしまうのだが、C++0x仕様策定の経緯を考えると
僅か数年のライフサイクルの為にそんなことしないとも思えるわけで…
まだCPUが8ビットでOSなんか載ってなくて、アセンブリでがんがってた時代を顧みると、
既に量子コンピュータは無理としても量子マイコンみたいな4キュービットマシンがあったりしてｗ

そういやtime_tが32ビット符号付なLinuxディストリビューションが2038年にオーバーフローする件、
Y2Kのような事は起きないんだろうな
それまでにtime_tは64ビットは当たり前だったりするだろうし、CPUのレジスタやアドレス空間が
512ビット幅だったりしてねｗ
メモリはTBは余裕なんじゃないの？
15年くらい前は4MBとかだったのに15年程度で1〜2GBが標準だし
HDDなんかがTB越えてEBとか新たな単位がデファクトスタンダード化してたりして
妄想楽しかったわ
0141デフォルトの名無しさん2008/04/08(火) 21:09:01
>>138
・GCは本当にC++標準になるか?
・CRTPの果たす機能を、より一般的でかつ抽象的な機構で実現できないか?
・daemon method, accessor hook
0142デフォルトの名無しさん2008/04/08(火) 21:12:28
>>140
2038年問題は考えてたけれど、2029年には早すぎると思って入れるのをやめた。
人間が騒ぎ出すのは、大抵、問題がひっ迫してからだから、数年後に迫らないと、
本格的に議論されないと思う。

Y2Kのようなことはおきるね。32bitコードはそこらかしこで動いているだろうから。
一体誰がコンパイルしなおすの？

というか標準規格厨としては、POSIXのCライブラリは嫌い。
ANSI CやC99とは微妙に違うし。
というかそもそもCライブラリ自体が古いから、使われなくなってくれれば、うれしいんだけどなぁ。

>CPUのレジスタやアドレス空間が512ビット幅
というか本音を言うと、本当に64bitに移行できているかどうかも怪しい。
最悪、いまだにWindowsは32bit版が発売されているということも。

>HDDなんかがTB越えて
HDDに置き換わるものは、やはり20〜30年ぐらいじゃ無理かな。
0143デフォルトの名無しさん2008/04/08(火) 21:27:47
>>141
mixin だな。今の C++ に足りないのは。
0144デフォルトの名無しさん2008/04/08(火) 21:29:44
conceptはmixin風に使えるけど、
access controlがないのが痛いね。
0145デフォルトの名無しさん2008/04/08(火) 21:31:58
>>142
まあY2Kと同じで大した問題は起きないだろうな。
と油断しておけば、いろいろ問題が起きて楽しめるかも。ｗ
0146デフォルトの名無しさん2008/04/08(火) 21:36:25
>>142
冷静に考えると、CPUのアドレスバス幅を512bitなんかにする恩恵は殆ど無いね
64bitでも十分なアドレス空間があるし
確かに、32bitCPUのライフサイクルは長かった、というか今も64bitコアを64bitとして使ってる
OSは全体からすれば少数だろうし

CはもうC++のサブセットでいいんじゃないの？
今もC++コンパイラがオプションでCコンパイル出来るけど…
よりOOP色、AOP色強くなればなるほど、C標準ライブラリを使用することへの危機感はでかくなる
だろうし…
POSIX俺も好きじゃないし、なんやかんやいいつつも、ISOベースでいいとおもってるし
直近じゃC++0x、boostの幾つかを標準ライブラリとしてstdネームスペースに取り入れるようだし
それはコンパイラとしては歓迎されるのかも？
新コンパイラ出たところで、2038年問題とも絡んで古いコードは存在し続けるわけで、古い
コンパイラを使うだろうから新しいライブラリを使用するのは暫く様子を見ることになるんだろうし

32bitのソースなど、下手すりゃポインタ変数のサイズ=4バイトと決めうちのコードもあるから
リコンパイルだけじゃ済まなそう…
アライメント違反も出そうだなあ

とはいえ、プリプロセッサが2029年まで残ってるんだろうか？
今の俺の脳味噌ではプリプロセッサが無いと大変に困るわけだけど…
EffectiveC++なんかに指南される
　#define FOO "foobarfoo"
よりも
　const char* const FOO = "foobarfoo";
を使え、これは分かるが、
#if/#ifdefが無いのは困るし、マクロ定義が使えずにインラインというのもそれはそれでデバッグログ
出すときに困る…
0147デフォルトの名無しさん2008/04/08(火) 21:39:05
2038年問題はスレ違い
0148デフォルトの名無しさん2008/04/08(火) 21:40:01
namespace階層入れて欲しいなあ。
stdがどんどん増えるのは好ましくないと思う。
0149デフォルトの名無しさん2008/04/08(火) 21:49:59
>>144
もうちょっとｋｗｓｋ
0150デフォルトの名無しさん2008/04/08(火) 21:56:36
>>148
> stdがどんどん増えるのは好ましくないと思う。

わからなくはないが、STLの大半がコンテナであるうえに、stdというネームスペース名を考えると、
確かに新しい標準ライブラリは異なるネームスペースに入れて貰いたいという気もしなくもない
ついでに、マクロに C++0x 対応コンパイラなのかどうかを判別するマクロ用意して欲しいんだけど、
既にそれは予定済みだったりしてｗ
0151デフォルトの名無しさん2008/04/08(火) 21:59:10
C++ にはヘッダファイルってものがあるから
気軽に using できない。
そう考えると、あんまり標準ライブラリの階層深いと
ダルくなると思う。
0152デフォルトの名無しさん2008/04/08(火) 22:08:51
>>150
__cplusplusの値が増えているんじゃないの？
0153デフォルトの名無しさん2008/04/08(火) 22:16:47
>>151
それそれ、頼むからヘッダファイルで using namespace std; とかしないで欲しい！
だが、今のPRJではそこら中にあるんだよね…
そんなに std::string とか std::vector って書くのがめんどくさいのかね

>>152
それもそうだｗ
__cplusplusなんて値を意識しないもんなぁ extern"C" くらいにしか使わないからｗ
0154デフォルトの名無しさん2008/04/08(火) 22:42:46
美少女中学生を namespace 俺の姓; で囲んでバラ色の生活をだな
0155デフォルトの名無しさん2008/04/08(火) 22:49:26
ADL対策でstlの中にも名前空間を作っていけないとやっていけないんじゃないのか？
0156デフォルトの名無しさん2008/04/08(火) 23:23:08
>>151
単純にスタティックなオブジェクト言語の限界だと思うんだが
0157デフォルトの名無しさん2008/04/08(火) 23:47:46
>>151
ヘッダも今や階層化されてるし。
>>156
そんなの関係ないねえ
0158デフォルトの名無しさん2008/04/09(水) 00:30:10
>>157
> そんなの関係ないねえ
どんな意味で関係ないんだろ? >>151, >>156 は
> ヘッダも今や階層化されてるし。
このことを問題にしてるんじゃないのか?
0159デフォルトの名無しさん2008/04/09(水) 00:45:23
皆の見解をまとめると、これからはD言語の時代ってことか。
0160デフォルトの名無しさん2008/04/09(水) 01:54:30
それはない

何だかんだ言ってもここ20年間はおおむねCとC++の天下だったし、
それはこの先も変わらないだろうな
0161デフォルトの名無しさん2008/04/09(水) 03:09:07
関数型言語に取って代わられるだろうと予想する。
オブジェクト指向やC++にはスマートさで限界を感じる。
0162デフォルトの名無しさん2008/04/09(水) 04:26:18
まさか
LISPが誕生して50年になるけどその間に関数型言語が主流になったことなんて一度もないだろ
0163デフォルトの名無しさん2008/04/09(水) 04:44:38
>>162
ほんとにそうよね。

まあ、最近よく言われてるのは、
宣言型とか手続き型、静的とか動的の垣根がなくなっていくってのかな。

あとは、1つの言語で全部書くんじゃなくて、
多言語混在開発な方向に進んで行ってる。

というのを考えると、やっぱり C++ には限界を感じるんだけど。
0164デフォルトの名無しさん2008/04/09(水) 07:18:34
For me, easily the biggest news of the meeting was that we voted lambda functions and closures into C++0x.
･・・・・・・・・・・・・・・・・・
by Sutter
なぜlambdaやclosureに拘っているのかもわからん。
MSはF#に本腰を入れてるようだけど。
いずれにせよC++色々取り込みすぎて記述レベルに難があるとは思う。
0165デフォルトの名無しさん2008/04/09(水) 07:48:48
>>161
D言語はpure関数とかを導入して、関数プログラミングを取り込む方向で動いてるみたいだね。

http://www.digitalmars.com/d/2.0/accu-functional.pdf
どうなるかわかんないけど。
0166デフォルトの名無しさん2008/04/09(水) 07:55:09
ついおこづかいでアクセサリーを買い込みすぎてしまう美少女中学生
0167デフォルトの名無しさん2008/04/09(水) 08:29:09
>>166 美少女中学生以外は眼中にないのか?
0168デフォルトの名無しさん2008/04/09(水) 08:57:25
>>164
わからん方が鈍いと思うけどね。
0169デフォルトの名無しさん2008/04/09(水) 09:15:35
>>168
schemeをやってきた俺は勝ち組だがな。C++はのλはモドキだ。
0170デフォルトの名無しさん2008/04/09(水) 09:25:40
馬鹿丸出しだな。
0171デフォルトの名無しさん2008/04/09(水) 09:30:06
記述レベルに難がある
モドキ
だけじゃなくて、具体的に言わないと。
愚痴書くスレじゃないから。
0172デフォルトの名無しさん2008/04/09(水) 09:32:05
やっべー、薄っぺらいことがばれてもうたｗｗｗ
でもテンプレートの可読性の低さは難だろ。キモ構文のオンパレード
それでもあなたはC++に期待しますか？
0173デフォルトの名無しさん2008/04/09(水) 09:39:49
メタをテンプレートで実現するのは難アリ。
0174デフォルトの名無しさん2008/04/09(水) 09:45:09
>>171
例えばscheme処理系は言語の機能として構文拡張が可能。
C++は言うに及ばず。
0175デフォルトの名無しさん2008/04/09(水) 09:53:56
Schemeと比べてああだこうだ言われても。
Schemeのプリミティブは強力だけど、
Schemeだって得意じゃないことは一杯あるし。

C++のclosureは、Javaの奴みたいに、
コントロール拡張について考慮されてないのが寂しいですねえ。
0176デフォルトの名無しさん2008/04/09(水) 10:53:42
>>175
＞C++のclosureは、Javaの奴みたいに、
＞コントロール拡張について考慮されてないのが寂しいですねえ。
もうちょっとｋｗｓｋ
0177デフォルトの名無しさん2008/04/09(水) 11:23:44
つ http://jazoon.com/download/presentations/1680.pdf
0178デフォルトの名無しさん2008/04/09(水) 11:25:27
range-based for-loopと絡めたいね。
0179デフォルトの名無しさん2008/04/09(水) 12:31:24
>>162
まるでLISPが関数型言語みたいな言い方だな。ｗ
0180デフォルトの名無しさん2008/04/09(水) 13:17:07
自分の知識がきっちりしていることをひけらかすだめだけの
細かい突っ込みは痛々しいよ。
その「句点のあとのダブリュー」に突っ込むくらい虚しいことだ。
0181デフォルトの名無しさん2008/04/09(水) 13:17:51
美少女中学生が丸出し！
0182デフォルトの名無しさん2008/04/09(水) 13:35:51
いい加減中学生から離れろ。
0183デフォルトの名無しさん2008/04/09(水) 13:38:14
そうだそうだ。中学生なんてババアだろ。
0184デフォルトの名無しさん2008/04/09(水) 14:50:27
>>180
あやふやな知識じゃ自慢できませんものね。ｗ
0185デフォルトの名無しさん2008/04/09(水) 15:14:33
自慢というか、自爆。
0186デフォルトの名無しさん2008/04/09(水) 16:44:56
美少女中学生の初めての自慰はダイソーバイブと相場が決まっていてな
0187デフォルトの名無しさん2008/04/09(水) 17:39:48
つまりUnlambdaサイコー！ということですね
わかります
0188デフォルトの名無しさん2008/04/09(水) 21:42:03
>>177
遅くなりましたけれどありがとうございます．
finally 周りを省略するための使い方は， scope guard 系の技法に
lambda expression を組み合わせれば C++0x でもおよそそのまま転用できそうですね．
Listener に Event 設定したり， thread function の設定に使うのは
C++ だと lifetime の問題が出てくるのでそのまま転用するのが
難しい局面が出てくると思いますけれど，
これはコントロール云々とは直接は関係ないですかね．
0189デフォルトの名無しさん2008/04/10(木) 15:51:50
>>138
Dスレから来ました
＞ Brainf*ckやWhitespaceまでもがC++としてコンパイル可能
DでBrainfuckをDの関数としてコンパイルするサンプルはもう作ってみたよ。
C++でもテンプレートプログラミングが変態的になればできると思う。
メモリ管理がうまくいけばJavaあたりはC++で直接いけるような気がします
0190デフォルトの名無しさん2008/04/10(木) 16:11:46
Dか。
Dはやねうらおが一時期信者だったので敬遠してたんだが、
今は離れたみたいだし、ちょっと遊んでみようかな。
流行るとは思わないけれど。
0191デフォルトの名無しさん2008/04/11(金) 11:57:20
>>190
「誰々が信者だったから〜」
なんともくだらない理由だなww
0192デフォルトの名無しさん2008/04/11(金) 12:15:17
Rubyはまつもとが××信者だったから〜
0193デフォルトの名無しさん2008/04/11(金) 12:50:57
生理的に駄目なやつっているだろ

美少女中学生の生理なら駄目じゃないぞむしろ大歓迎
0194デフォルトの名無しさん2008/04/11(金) 18:00:43
製作者がGPL信者だったから敬遠しますた
0195デフォルトの名無しさん2008/04/11(金) 18:02:33
それは実害があるからしゃーないが・・・
坊主憎けりゃ袈裟まで憎いとか俺には一生分からない感情だろうな。
0196デフォルトの名無しさん2008/04/11(金) 18:30:23
「誰誰が信者だったから〜〜」
「坊主憎けりゃなんとやらか」
「でも今日は気にしないよ」
「あー、"今朝まで憎い"ってか」
0197デフォルトの名無しさん2008/04/11(金) 18:43:42
まつもとはいいかげん他言語を煽って目立とうとするのはやめてほしいんだが
煽りの内容もお前が言うなレベルの低次元なものだし・・・
0198デフォルトの名無しさん2008/04/11(金) 19:10:56
子供っぽい美少女中学生はどこが坊主？
0199デフォルトの名無しさん2008/04/11(金) 19:27:21
結局 Python に落ち着いた漏れ．
でも最近は仕事じゃPHPばっかりで萎える．
0200デフォルトの名無しさん2008/04/11(金) 20:40:51
まぁ標準みたいなもんだし
0201デフォルトの名無しさん2008/04/11(金) 23:00:49
C++0xはC++1xになるのだろうか…
0202デフォルトの名無しさん2008/04/12(土) 09:07:38
0f までいけるからまあ大丈夫だろ。
0203デフォルトの名無しさん2008/04/12(土) 09:27:12
07までだろ…
0204デフォルトの名無しさん2008/04/12(土) 11:47:56
それは盲点だった
0205デフォルトの名無しさん2008/04/12(土) 11:50:32
いいかげん0のプリフィクスで8進数リテラルっての止めて欲しい
誰も使わない上に紛らわしい

pythonを見習って止めるべし
0206デフォルトの名無しさん2008/04/12(土) 11:51:15
つ 互換性
0207デフォルトの名無しさん2008/04/12(土) 14:32:37
パーミション設定するときに使うべ。
0208デフォルトの名無しさん2008/04/12(土) 14:51:09
そうだな
パーミションは3ビットだから8進使うと便利だな
0209デフォルトの名無しさん2008/04/12(土) 14:55:54
そのために8進表記があるんじゃないのか
0210デフォルトの名無しさん2008/04/12(土) 14:59:15
別にパーミションのためにあるわけじゃないぞ。
0211デフォルトの名無しさん2008/04/12(土) 15:00:11
for all 3bit user
0212デフォルトの名無しさん2008/04/12(土) 16:04:49
それより２進表記を作ってくれ 0b0100110101010 みたいな
0213デフォルトの名無しさん2008/04/12(土) 16:08:27
読みづらいから D みたいに区切りを入れられるようにしてくれ。
0214デフォルトの名無しさん2008/04/12(土) 17:27:33
>>212
これ良く書かれてるんだけど
0xdcとかが11011100とかに見えないの？
実に不思議だ
0215デフォルトの名無しさん2008/04/12(土) 17:28:57
TMPで2進表記をする有名なサンプルがあってだな・・・
0216デフォルトの名無しさん2008/04/12(土) 17:34:12
>>214
「実質ゼロ時間・ゼロ労力」でできるのはせいぜいその辺の変換+αくらいで、
その程度ではまるで不便だから「よく書かれる」んだろう。

もし「0xdcが11011100に見えないレベルの人が」よくこの要望を出しているのだと考えているなら、
勘違いで自分を相対的に持ち上げすぎ。不思議っていうか、君が不思議ちゃんだよｗ
0217デフォルトの名無しさん2008/04/12(土) 17:36:42
頭の中で変換可能ならリテラルの表記は10進のみでおｋ
という話しになってしまうな

ただ二進数だと桁が多くなるから区切りがないと返って可読性落ちるな
0218デフォルトの名無しさん2008/04/12(土) 17:40:15
>>216
どういうこと？
16進と2進は直接4桁ごとに変換できるから2進表記はないんだろ？
そしてそれをほとんどができるから
よく書かれるってのは皮肉で書いたんだけど
0219デフォルトの名無しさん2008/04/12(土) 17:40:54
皮肉っていうのはおまえいつもそれ書いてるなって意味
0220デフォルトの名無しさん2008/04/12(土) 18:02:42
俺は脳内で変換できるから、5進数でも大丈夫
0221デフォルトの名無しさん2008/04/12(土) 18:04:05
16進でいいだろってのは釣りなんだから相手にしないでおけ。
0222デフォルトの名無しさん2008/04/12(土) 18:28:35
C系言語使うつもりなら
・2進 <-> 8進 <-> 16進の変換
・0xF*0xFまでの16進九九
・文字定数 <-> ASCII値
・主要な2^n値の10進表記(n=1〜16,20,24,30,31,32,40,63,64あたり)
くらいは身につけてるのが常識だし、マナーだと思ってたが
最近はそうでもないのか
0223デフォルトの名無しさん2008/04/12(土) 18:30:39
身につけるのが常識である事と、
そのままでいいこととは別の話だろ？
0224デフォルトの名無しさん2008/04/12(土) 18:34:33
そんなのまで言語側で面倒見るべきではないと思うぞ
九九を知らない奴が家を設計できるようになることが良いこととは思えない
0225デフォルトの名無しさん2008/04/12(土) 18:34:38
0b0100110101010
こんなのぱっと見て長すぎて分かりにくいし
たかだか16個のビットパターン覚えられないって方がネタだろ
0226デフォルトの名無しさん2008/04/12(土) 18:38:18
>>222
この辺、本当にそう思うならちょっと披露して欲しいと思った。
・8進16進変換
普通の人は、2進を介在させないと難しいと思う。
・16進9x9
必要になるケースがレアすぎる。
・2^nのnが40とか64とか。
nが16以下なら普通に言えるけど。nが32でさえ桁数が多すぎて普通は無理。
0227デフォルトの名無しさん2008/04/12(土) 18:38:20
D みたいに自由にアンダースコア入れれるようにすればいい。
0228デフォルトの名無しさん2008/04/12(土) 18:38:45
>>222
そんな化石言語使いません。
0229デフォルトの名無しさん2008/04/12(土) 18:39:30
マクロとか書けるけどな。
でも、できるなら言語的にサポートされてほしい。
0230デフォルトの名無しさん2008/04/12(土) 18:40:18
0b001101000101ならすぐ0x345とわかるけど
これを0b1101000101とか書かれると困る
0bの後に続く数は4の倍数個に制限するべきだが、導入されたとして多分そうはならないだろ
だったら有害なだけ
0231デフォルトの名無しさん2008/04/12(土) 18:40:59
いや32なら簡単だろさすがに
0232デフォルトの名無しさん2008/04/12(土) 18:41:41
>>231は思いっきり勘違い
0233デフォルトの名無しさん2008/04/12(土) 18:42:55
>>230
D ではこう書く。

0b11_0100_0101
0234デフォルトの名無しさん2008/04/12(土) 18:43:18
特にメモリが4Gに迫って色々あったり2038年問題の影がちらつきだしたこのご時世に
2^31と2^32の10進値も知らないコンピュータ技術者がいるなんて信じたくない
0235デフォルトの名無しさん2008/04/12(土) 18:44:27
だから、概数を覚えていることと全桁そらで言えることは違うって。
0236デフォルトの名無しさん2008/04/12(土) 18:45:06
およそ40億としか覚えてなかった
1048576までなら覚えてるけど
0237デフォルトの名無しさん2008/04/12(土) 18:45:36
20億代と40億代だと覚えておけば、
細かい値が必要なときだけ電卓でポンでいいだろ。
無駄な事覚えるのはタダのバカ。
0238デフォルトの名無しさん2008/04/12(土) 18:48:05
約21億と約43億としか覚えてないなぁ
けど2^24は16777216って覚えてるな
0239デフォルトの名無しさん2008/04/12(土) 18:48:14
>>234
2^10 = K
2^20 = M
2^30 = G

で十分だ。
0240デフォルトの名無しさん2008/04/12(土) 18:49:04
>>238
俺も 16777216 は覚えてるな。
何か覚えやすい並びだしな。
0241デフォルトの名無しさん2008/04/12(土) 18:50:18
>>239
Gってのは文脈によって1073741824・1047586000・1024000000・1000000000を意味する可能性がある
全然十分ではない
0242デフォルトの名無しさん2008/04/12(土) 18:51:08
>>239
2^10=1024も知らないとか冗談だろ？
0243デフォルトの名無しさん2008/04/12(土) 18:51:51
1024 は流石に知らないと恥ずかしいな。
0244デフォルトの名無しさん2008/04/12(土) 18:53:29
>>241
例えば伝送速度は1k=1000、メモリ容量などは1k=1024換算だ。

>>242
んなもん覚えてるわ
0245デフォルトの名無しさん2008/04/12(土) 18:53:37
2^31=2147483648は結構覚えやすいと思うんだけどな
万の区切りで48が2回出てくるし偶数桁目に4,4,3,4って調子よく並んでるし
0246デフォルトの名無しさん2008/04/12(土) 18:54:10
>>241
文脈だって、馬鹿じゃね
0247デフォルトの名無しさん2008/04/12(土) 18:54:58
2^8 = 256
2^10 = 1024
2^15 = 32768
2^16 = 65536

これはおさえとかないと確かにマズいな
0248デフォルトの名無しさん2008/04/12(土) 18:56:38
データ容量でキロを1000メガを1000000と解釈するのは記録メディア業界だけ？
0249デフォルトの名無しさん2008/04/12(土) 18:56:51
0xFFFF = 65535
これで覚えてる
0250デフォルトの名無しさん2008/04/12(土) 18:58:21
>>248
メディア業界でも会社によってメガが1000000だったり1024000だったりするから困る
（1048576であることはまずないけど）
0251デフォルトの名無しさん2008/04/12(土) 18:58:28
てかC++0xのスレだよな？
0252デフォルトの名無しさん2008/04/12(土) 18:59:21
いつまでも0bなんて粘着に持ち出すゆとりのせいで荒れたじゃないか
0253デフォルトの名無しさん2008/04/12(土) 19:04:49
0bを導入するメリットがあるとすればフラグを表す定数なんかで
#define FLAG_A 0b00000001
#define FLAG_B 0b00000010
#define FLAG_C 0b00000100
#define FLAG_D 0b00001000
#define FLAG_E 0b00010000
#define FLAG_F 0b00100000

なんて表現ができて初心者がフラグの定義の仕方を直感的に理解できるくらいか？
それ以外のメリットが思いつかん・・・

0254デフォルトの名無しさん2008/04/12(土) 19:06:21
#define BIT(n) (1u << (n))

#define FLAG_A BIT(0)
#define FLAG_B BIT(1)
#define FLAG_C BIT(2)
#define FLAG_D BIT(3)
#define FLAG_E BIT(4)
#define FLAG_F BIT(5)

とかの方が分かりやすい
0255デフォルトの名無しさん2008/04/12(土) 19:07:07
0b literals considered harmful
0256デフォルトの名無しさん2008/04/12(土) 19:10:50
Gauche使え
0257デフォルトの名無しさん2008/04/12(土) 19:12:27
そういう思い込み書き込むスレじゃないからw
マ板行けよ

新しい関数型の記法です。->を使う。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm

typedef int IFUNC(int);
IFUNC* fpif(int);
　↓
auto fpif(int)->int(*)(int)

template <class T, class U> decltype((*(T*)0)+(*(U*)0)) add(T t, U u);
　↓
template <class T, class U> auto add(T t, U u) -> decltype(t+u);
0258デフォルトの名無しさん2008/04/12(土) 19:17:28
コンパイラの都合臭がする記法だよな
0259デフォルトの名無しさん2008/04/12(土) 19:19:27
constexpr long operator prefix"0b"(const char *literal_string){
　　long n=0;
　　for(; *literal_string; literal_string++){
　　　　n = (n << 1) + *literal_string - '0';
　　}
　　return n
}
こういうのが出来れば0b厨もおとなしくなるのに
0260デフォルトの名無しさん2008/04/12(土) 19:21:37
なんか盛り上がってると思ったら、記憶力自慢の子が来てたのか。ｗ
0261デフォルトの名無しさん2008/04/12(土) 19:21:55
typedefの何が気に食わなくてこんなキモい構文を
0262デフォルトの名無しさん2008/04/12(土) 19:36:31
こういうのを見るとC/C++って下品なプログラミング言語だと思うよな。
0263デフォルトの名無しさん2008/04/12(土) 19:37:58
>>262
そこがいい。下品な俺たちにぴったりなのだ。
0264デフォルトの名無しさん2008/04/12(土) 19:50:37
>>261
templateの例はtypedefじゃきついだろ。

関数型表記の無理やり感がついに破綻しましたね。
0265デフォルトの名無しさん2008/04/12(土) 19:51:05
>>260
というかその人達、これだけ会話が続いてもまだ
「16種類のビットパターンを覚えられないから0b表記を欲しがっている」
と思い込んでるのが痛い。
0266デフォルトの名無しさん2008/04/12(土) 19:58:44
>>265
ごめん、違うの？
0267デフォルトの名無しさん2008/04/12(土) 19:59:45
>>266
違うに決まってるだろ。
その記憶力でちゃんと日本語を覚えような。
0268デフォルトの名無しさん2008/04/12(土) 20:04:25
ごめんなさいバカなのでわかりません
0bには16進のビットパターンを覚えられないゆとりのため以外にどのような利点があるのでしょうか
0269デフォルトの名無しさん2008/04/12(土) 20:06:34
最近のGCCは独自拡張で0bを持っている。
0270デフォルトの名無しさん2008/04/12(土) 20:07:39
>>268
バーカバーカ
0271デフォルトの名無しさん2008/04/12(土) 20:09:47
>>268
保守性の向上
0272デフォルトの名無しさん2008/04/12(土) 20:10:36
0bでは保守性向上しないだろ・・・
0273デフォルトの名無しさん2008/04/12(土) 20:12:12
他の言語に採用されてる事に関しては疑問を持たないのかね
0274デフォルトの名無しさん2008/04/12(土) 20:18:02
何を言おうと標準化委員会に却下された時点で0b厨の敗北は決定している
0275デフォルトの名無しさん2008/04/12(土) 20:20:56
>>271
0bの方が読みやすい、だから保守性が向上するんだ！という主張ですね？

つまり0xを読めない奴でも保守できるようにするための機能ということですから
16進のビットパターンを覚えられないゆとりのための機能という意味ですね
解答になってないですね

「16進のビットパターンを覚えられないゆとりのため」以外の理由を教えて下さい
この馬鹿な私に教えて下さい
0276デフォルトの名無しさん2008/04/12(土) 20:21:57
>>274
こういう下品な理由こそが C++ に相応しい
0277デフォルトの名無しさん2008/04/12(土) 20:22:32
>>275
君は馬鹿というより単純だと思う
0278デフォルトの名無しさん2008/04/12(土) 20:24:26
面倒くさいから
「ゆとりと仕事する（或いは保守をやらせる）かも知れないから」
でいいんじゃね
0279デフォルトの名無しさん2008/04/12(土) 20:24:42
>>275
一行目と二行目の間に凄い飛躍があるなw
0280デフォルトの名無しさん2008/04/12(土) 20:26:55
>>279
0xが読めるなら0xだろうと0bだろうと保守性は変わらないんですから
0xが読めない人にのみ意味のある保守性の向上ということですよね？

普通に読めばそういう意味になると思いますが
どのような飛躍があるのか教えて下さい
単純な私に教えて下さい
0281デフォルトの名無しさん2008/04/12(土) 20:31:06
読める人でも分かりやすさに差があるし、
2進で書くか16進で書くかによって
コードに込められた意図に差が出ることだってあるだろ。
0282デフォルトの名無しさん2008/04/12(土) 20:31:06
>>280
「読める」と「読みやすい」の違いは判る？
0283デフォルトの名無しさん2008/04/12(土) 20:31:27
そもそも16種類のビットパターンすら覚えられないような奴が
73種類もある（しかも多くは多重に意味のある）C++の予約語を覚えられるわけがないから
そういう奴は普通に考えてC++をいじるような仕事が出来るわけがないと思うんだが
0b入れたとしてもさ
0284デフォルトの名無しさん2008/04/12(土) 20:32:20
駄目だ、こいつ粘着だよｗ
0285デフォルトの名無しさん2008/04/12(土) 20:32:53
>>280
読みやすさなら圧倒的に16進だろ
0bには別のメリットがあるに決まってるじゃん馬鹿なの？
0286デフォルトの名無しさん2008/04/12(土) 20:33:16
16進テトリスとかやったことあるけど、
やりづらいことこの上なかったぞw
0287デフォルトの名無しさん2008/04/12(土) 20:33:17
>>283
本当に単純なんだね
0288デフォルトの名無しさん2008/04/12(土) 20:33:36
>>281
そんな意図はコメントやドキュメントに書くべきであって
リテラルの形式に勝手にそんな暗黙の約束を置く方がかえって保守性下がると思うんだが
0289デフォルトの名無しさん2008/04/12(土) 20:34:54
じゃあ for とか while とかじゃなくて goto 使ってください。
0290デフォルトの名無しさん2008/04/12(土) 20:35:29
>>282
それはもちろんゆとりでも対応表を片手に一つずつ変換していけば読むこと自体は出来るに決まっていますから
今までの「読める」はすべて「読みやすい」の意味だと思って下さい
言葉が足りなくて申し訳ありませんでした

では改めて「16進のビットパターンを覚えられなくて0xを読みにくいゆとりのため」以外の理由を教えて下さい
0291デフォルトの名無しさん2008/04/12(土) 20:35:33
10進と16進の使い分けだってやってるだろ？
まさか意味も無く16進使ってるわけはないよな？
0292デフォルトの名無しさん2008/04/12(土) 20:36:41
>>288
Unixのchmodも10進数で書いちゃう人ですか？
0293デフォルトの名無しさん2008/04/12(土) 20:38:17
>>289
forが出てくれば繰り返しだとわかるけど
コード中に「0xAA」と「0b10101010」が説明なしに出てきて
一体どうやってプログラマの意図をくみ取ればいいんだ？
同じ数だぞ？
0294デフォルトの名無しさん2008/04/12(土) 20:38:32
chmodを16進で書くのも読みづらいな。
あれは8進で書くべき。
2進が欲しいってのも似たような理由だな。
2進の方が分かりやすい所では2進が使えた方がいい。
0295デフォルトの名無しさん2008/04/12(土) 20:39:59
2進が使いやすいとしたら4ビットせいぜい8ビットまでだろ
それ以上はかえって読みにくくなるし
読みやすさのためだけなら必要ないと思うんだけど
0296デフォルトの名無しさん2008/04/12(土) 20:40:16
>>293
例えば5ビットずつ情報を与えたい場合であれば、
0b11011_11101_01011 と書けた方がいいだろう。
0297デフォルトの名無しさん2008/04/12(土) 20:40:52
10進と16進の使い分けはそりゃあるだろう
おおむね「ビットに意味のある数」が16進でそうじゃない数を10進で書くよな

さて、2進で書きたい数というのは多分「ビットに意味のある数」だろう
16進とどう使い分けるんだ？
0298デフォルトの名無しさん2008/04/12(土) 20:41:22
5ビットずつってのは16ビットRGBを扱う際に出てくる。
0299デフォルトの名無しさん2008/04/12(土) 20:42:18
0bが却下されてる理由なんだったっけ
ビットオーダーが環境依存だからだっけ？
でもシフト演算子の << >> の方向にあわせて0bの記法をきめちゃってよさそうなのにな。
0300デフォルトの名無しさん2008/04/12(土) 20:42:30
そんな書き方16進数でもできないじゃん
これ_挟むの
0301デフォルトの名無しさん2008/04/12(土) 20:44:22
できるようにすればいいじゃん。
0302デフォルトの名無しさん2008/04/12(土) 20:44:54
RGB(なんたら)ってマクロでも使えばいいんじゃないの
0303デフォルトの名無しさん2008/04/12(土) 20:45:41
>>299
ビットオーダーって単なる値には特に関係ないんじゃないかと思うんだが。
つか、それ言い出すと16進数もやばいんじゃね？
0304デフォルトの名無しさん2008/04/12(土) 20:46:26
メモリ上にはそんな区切りはどこにも存在しないのに
勝手にそんなもの入れられるようにして何が嬉しいんだ？
0305デフォルトの名無しさん2008/04/12(土) 20:46:53
その釣りは流石に稚拙だ
0306デフォルトの名無しさん2008/04/12(土) 20:49:16
0x__________________1____________________________0________________________
とか書けるようになるんだろ
きめえ
0307デフォルトの名無しさん2008/04/12(土) 20:54:26
_ を連続させられないようにすればいいだけだろ・・・そんなの。
0308デフォルトの名無しさん2008/04/12(土) 20:56:11
>>307
お前はマクロ引数の反省を全く学んでいないんだな
0309デフォルトの名無しさん2008/04/12(土) 20:57:08
？
0310デフォルトの名無しさん2008/04/12(土) 20:57:27
個人的にはどっちでもいい。（特に欲しいとは思わないけど、入っても構わない）
おまえらの執着心には感心する。
0311デフォルトの名無しさん2008/04/12(土) 21:01:14
導入されてる言語があって、そこで別に不自由ないんだから、
導入されても別に構わんだろ。
使いたくなきゃ使わなきゃいいんだし。
0312デフォルトの名無しさん2008/04/12(土) 21:01:32
ここは変態言語らしく1〜36進数までサポートしようぜ
0313デフォルトの名無しさん2008/04/12(土) 21:04:42
>>311
そんなのはC++の標準団体に言えよ
とりあえずそんな消極的な理由じゃ話にならない
0314デフォルトの名無しさん2008/04/12(土) 21:06:41
委員会に却下された理由ってなんなの？
0315デフォルトの名無しさん2008/04/12(土) 21:06:53
そういえば85進数でIPv6書こうっていうRFCがあったな
0316デフォルトの名無しさん2008/04/12(土) 21:07:25
おお・・・驚異の1進数・・・
でも、便利そうな状況はありそうな気がするから困る。

const char hoge[] = "abcdefg";
size_t btof =　　　 0u11111;

とか。
0317デフォルトの名無しさん2008/04/12(土) 21:07:52
等幅で見て
0318デフォルトの名無しさん2008/04/12(土) 21:14:30
一進数は便利だ
数えれば幾つかすぐ分かる
0319デフォルトの名無しさん2008/04/12(土) 21:17:40
#define unitary(s) (sizeof(s)-1)

unitary("11111"); /* == 5 */
0320デフォルトの名無しさん2008/04/12(土) 21:18:36
unitaryじゃなくてunaryか
0321デフォルトの名無しさん2008/04/12(土) 21:18:48
そこはこうだろ・・・

#define unitary(u) (sizeof #u - 1)

unitary(11111); /* == 5 */
0322デフォルトの名無しさん2008/04/12(土) 21:23:46
今でも8進数の数字に8や9が使えちゃうことだし
0b入れたとしても中で2や3が使えることになってカオスになりそうだからいらない
0323デフォルトの名無しさん2008/04/12(土) 21:25:36
エラーになるけど？？
0324デフォルトの名無しさん2008/04/12(土) 21:26:17
コンパイラが親切なだけじゃないの？
規格上はおｋだったはず
0325デフォルトの名無しさん2008/04/12(土) 21:34:45
octal-literal:
　0
　octal-literal octal-digit

octal-digit:
　0 1 2 3 4 5 6 7

と書いてあるが・・・。
0326デフォルトの名無しさん2008/04/12(土) 21:36:29
あれ？
昔の話だったかもしれん。すまん
0327デフォルトの名無しさん2008/04/12(土) 21:46:32
K&Rの2版で8と9は使えなくなったと書かれていたが。
0328デフォルトの名無しさん2008/04/13(日) 10:18:06
C89の仕様ができるまでは、
そのへんルーズな処理系がいっぱいあってなゴホゴホ
0329デフォルトの名無しさん2008/04/13(日) 16:44:18
ビットマスクには2進を使いたいじゃんね
0330デフォルトの名無しさん2008/04/13(日) 17:25:44
15年前にアセンブラからCに移った時は欲しくて仕方なかったけど、
リテラル書くって、要するにマジックナンバー書くってことじゃん。
ダメ。
マクロなり変数なり関数なり、名前を付けてそれ使いなさい。
だから不要。
0331デフォルトの名無しさん2008/04/13(日) 17:28:58
その理屈だと整数リテラルはすべて禁止だな
0332デフォルトの名無しさん2008/04/13(日) 17:29:05
マクロ／変数（定数？）／関数が返す値をどうやって書くかという話なんだけどな。
0333デフォルトの名無しさん2008/04/13(日) 17:35:07
１ビットだけならマクロ使って何ビット目が立ってるか書いた方が分かりやすいが、
複数ビットある場合は微妙かもしんないな。
0334デフォルトの名無しさん2008/04/13(日) 17:44:01
結局はこう書いてこう使うだろ
#define FLAG_HOGE 0x01
#define FLAG_FOO 0x02
#define FLAG_BAR 0x04
...

if(flg & (FLAG_FOO || FLAG_BAR)){
　　...
}

これが「#define FLAG_BAR 0b00000100」になったからって読みやすいとはとても思えないし
「if(flg & 0b00000110)」なんてのを書くようなら0b関係なく論外（「if(flg & 0x06)」だとしても同じこと）
0335デフォルトの名無しさん2008/04/13(日) 17:46:55
64ビットの2進リテラルはきもい
0336デフォルトの名無しさん2008/04/13(日) 17:46:59
もう想像力の欠如した粘着の相手はやめようぜ
0337デフォルトの名無しさん2008/04/13(日) 17:48:50
ここは想像力の欠如した粘着と
想像力がありすぎる女子中学生好きのスレ
0338デフォルトの名無しさん2008/04/13(日) 17:52:09
なんで || なんだよー
0339デフォルトの名無しさん2008/04/13(日) 17:53:22
「1ビット目と3ビット目と4ビット目と9ビット目と12ビット目が立ってるか判定するときに
if(flg & 0b100100001101)って書ければ便利じゃん？0x90dって書くよりわかりやすいじゃんじゃん？？？」
ってのが0b厨の希望ということですね

規格に意見する前にもっとましなプログラミングスタイルを勉強した方がいいと思いますよ
0340デフォルトの名無しさん2008/04/13(日) 18:02:14
面白いキャラ設定に興奮するのはいいけど、
相手より先に自分が興奮してると馬鹿にしか見えないですよ。
0341デフォルトの名無しさん2008/04/13(日) 18:10:57
なんか自分を規格を策定する側にいると誤解して、必死に規格の正しさを言い張ってる
お子ちゃまがいますね
0342デフォルトの名無しさん2008/04/13(日) 18:12:17
お前ら>>257にも少しは意見を寄せろ
0343デフォルトの名無しさん2008/04/13(日) 18:12:59
まだやってるのかよ
0344デフォルトの名無しさん2008/04/13(日) 18:16:54
こうまで論争の余地のある機能なんだったら
だったら入れるだけ入れて、使うかどうかは実装者に任せるのが
今までのC++のスタンスとして正しい
0345デフォルトの名無しさん2008/04/13(日) 18:34:27
>>257
typeof(T+U) add(T, U)(t t, U u);

Dだとこうかな。TやUがstaticなopAddのオーバーロードを持ってると上手く動かないけど。
0346デフォルトの名無しさん2008/04/13(日) 18:38:58
美少女中学生にオーバーライド
0347デフォルトの名無しさん2008/04/13(日) 19:06:18
議論の余地ないだろ
入れろって言ってるやつが16進数表記では自分は読めないって以外の理由を
いまだ示せていないし
0348デフォルトの名無しさん2008/04/13(日) 19:15:29
それが最大にして絶対的な理由だとなぜ気づかないんだ
0349デフォルトの名無しさん2008/04/13(日) 19:15:32
読める読めないのみ議論の論点だと言い張ってる馬鹿が議論を放棄してるだけ
読める読めないが論点だと言うのなら、10進数表記以外に16進数表記が必要な理由でも説明してみろ
0350デフォルトの名無しさん2008/04/13(日) 19:18:00
論点もなにもただのスレ違いだろ
0351デフォルトの名無しさん2008/04/13(日) 19:18:54
プログラミング言語の全ての機能は可読性のためにあるんだよ
それがいらないって奴はBrainfuckでも使ってろ

0bが入ったって少なくとも可読性が下がることはない
だったら入れるべき
0352デフォルトの名無しさん2008/04/13(日) 19:19:43
>>349
ありません。
16進数表記を必要としている人は、10進数を脳内で16進数変換できない頭の悪い人だけです。
だから俺は要りませんよ、16進数。
0353デフォルトの名無しさん2008/04/13(日) 19:19:54
16進数が必要なのはコンピュータが2進数だから
そのコンピュータを低レベルで扱おうとしたとき16進数で書けた方が
人間にとって読んだり書いたりしやすくなる
0354デフォルトの名無しさん2008/04/13(日) 19:20:45
>>349
16進数表記はビット演算のためです
そして2進数表記も入るとすればビット演算のためです
同じ機能は2つもいりません
0355デフォルトの名無しさん2008/04/13(日) 19:21:02
勘違いしてるようだけど10進数と16進数は変換できないぞ
16進数と2進数はできるけど
0356デフォルトの名無しさん2008/04/13(日) 19:21:53
じゃあ8進数が（ry
0357デフォルトの名無しさん2008/04/13(日) 19:24:10
自説を曲げる気のない人にどれだけ言っても無駄じゃない？
なんか恐ろしく単純な人みたいだし
0358デフォルトの名無しさん2008/04/13(日) 19:25:21
0bが欲しいって言ってるやつは0bと0xの変換が計算が必要な面倒な作業だと思ってるんだろうな
0359デフォルトの名無しさん2008/04/13(日) 19:25:42
>>354
単項の - があるんだから、二項の - は廃止したほうが良いだろうね。
そのほうがシンプルになるだろう。
0360デフォルトの名無しさん2008/04/13(日) 19:26:26
でなければ>>352みたいなことは書けない
0361デフォルトの名無しさん2008/04/13(日) 19:26:35
p-> なんて贅肉。(*p). だけでいい。
p[i] もいらね。*(p+i) だけでいい。
0362デフォルトの名無しさん2008/04/13(日) 19:26:53
>>358
0bが要らないって言ってるやつは単純な二元論者だから、シンプルな人生が歩めるだろうね
0363デフォルトの名無しさん2008/04/13(日) 19:27:06
10進と16進の変換は下位桁の状況が上位にずっと波及するから計算が面倒
2進と16進は（2進の）4桁ごとに変換が閉じるから楽ちん

こうですかわかりません
0364デフォルトの名無しさん2008/04/13(日) 19:27:55
徹底的に無視される8進数ｶﾜｲｿｽ
0365デフォルトの名無しさん2008/04/13(日) 19:28:07
素人にも理解できる問題は盛り上がって良いね。
そろそろ専用スレでも建てようか？
0366デフォルトの名無しさん2008/04/13(日) 19:28:40
しかも読みやすくなるならまだしも長ったらしくて読みにくくなるだけだし
0367デフォルトの名無しさん2008/04/13(日) 19:28:44
>>361
p[i]はマジで害悪にしかなってないからなくなった方がいいと実際思ってる
まるでCに配列が存在するかのような幻想を初心者に与えて混乱させる元凶になってるだけ
0368デフォルトの名無しさん2008/04/13(日) 19:28:59
区切り入れられるようにすれば読みやすいと何度言えば
0369デフォルトの名無しさん2008/04/13(日) 19:29:42
ただの荒しだろこいつら
0370デフォルトの名無しさん2008/04/13(日) 19:29:53
>>367
バカすぎる・・・
0371デフォルトの名無しさん2008/04/13(日) 19:30:46
それで読みやすくなるコードが既に誤ったコーディングスタイルだってことも指摘されてるのに
0372デフォルトの名無しさん2008/04/13(日) 19:31:17
権威主義に落ちてるのさ。批判的精神を失ったら、もう技術者としては終わりだ
0373デフォルトの名無しさん2008/04/13(日) 19:31:55
一人で両方の意見を書いてるマッチポンプ野郎が２人くらい来ている気がする
0374デフォルトの名無しさん2008/04/13(日) 19:32:02
[]がなかったら宣言ができなくなる
0375デフォルトの名無しさん2008/04/13(日) 19:32:07
>>371
定数を定義するする地点で使うことに問題は無いと何度言えばいいのだろうか。
0376デフォルトの名無しさん2008/04/13(日) 19:32:39
>>368
何の機能もない表現をプログラム本文中に入れるのは問題だと思う
本文中の記号はプログラムの動作に何かをもたらすものでなければいけない
（使われ方次第では無意味になることもあるとしても）
0377デフォルトの名無しさん2008/04/13(日) 19:33:36
>>376
それで読みづらくなるんだったら意味が無い。ただのバカだな。
0378デフォルトの名無しさん2008/04/13(日) 19:33:53
>>376
おまえ、改行と空白を敵に回したな
0379デフォルトの名無しさん2008/04/13(日) 19:34:10
コメントも敵に回してるな。
0380デフォルトの名無しさん2008/04/13(日) 19:35:27
>>377
何の意味もない記号なんてものが（コメント以外に）ある方がよほど読みづらいわ
0381デフォルトの名無しさん2008/04/13(日) 19:35:50
>>380
そろそろ苦しいから諦めろ。
0382デフォルトの名無しさん2008/04/13(日) 19:36:01
>>378
トークンを区切るという立派な仕事があるじゃないか
0bの中のアンダースコアはそれすらないんだぞ
0383デフォルトの名無しさん2008/04/13(日) 19:36:12
>>376
ぜひ作ってくれ。
全てのトークンがプログラムの動作に影響を与える言語。
0384デフォルトの名無しさん2008/04/13(日) 19:36:26
盛り上がってきたね。いいぞいいぞ。どちらも負けるな。もっとやれ。
0385デフォルトの名無しさん2008/04/13(日) 19:36:37
>>382
Dでそれが問題になってるという話は聞かない。
ただの妄想に過ぎないな。
0386デフォルトの名無しさん2008/04/13(日) 19:39:04
>>383
C＋＋は全てのコメント以外のトークンがプログラムの動作に影響を与えうる（もちろん与えないこともある）言語ですよ

0bの_は「絶対に」プログラムの動作に影響を与えない
0bXYと0bX_Yが違う意味を持つということはいかなる文脈でも絶対にない
無意味だと思わないか
0387デフォルトの名無しさん2008/04/13(日) 19:39:41
上のほうで書かれてた5ビットずつのRGBってのもビット列自体に意味はないから
こんなの使う必要ないと思うんだけど
0388デフォルトの名無しさん2008/04/13(日) 19:40:30
>>386
別に？
0389デフォルトの名無しさん2008/04/13(日) 19:40:50
>>382
自明的にトークンを構成する文字の前後に冗長な空白を入れるのは禁止したほうが良いですね
0390デフォルトの名無しさん2008/04/13(日) 19:42:16
>>386
「違う意味を持つということはいかなる文脈でも絶対にない」トークン列なんて無数に考えつくけど
0391デフォルトの名無しさん2008/04/13(日) 19:44:22
変数名内の _ の使用も禁止。
全部英小文字のみにしろということか。
0392デフォルトの名無しさん2008/04/13(日) 19:44:34
唯一使えるとしたらアイコンかなんかのパターンを記述するとき
ソースを見ただけでどんなアイコンか見当付きやすいってことくらいかな

他になんかある？
0393デフォルトの名無しさん2008/04/13(日) 19:45:09
>>390
いやいや、そりゃあるだろうよ
でもそのトークン列で使われている記号はどれも、別のトークン列の中でなら区別に貢献する可能性があるわけだ

0bの中の_という記号は、それがどんな数値定数の中でも区別に寄与しない
機能自体が全く無意味なんだよ
あるトークンの中で無意味というのとは次元が違う
0394デフォルトの名無しさん2008/04/13(日) 19:47:22
>>393
トークン間（空白等）は良くて、トークン内は許せないとする論拠は？
0395デフォルトの名無しさん2008/04/13(日) 19:47:40
何でそれがダメなのか明確な理由が述べられていない。
さっさと言え。
0396デフォルトの名無しさん2008/04/13(日) 19:47:49
>>391
D言語と同じようにするならその問題はない。
0397デフォルトの名無しさん2008/04/13(日) 19:49:48
変数名に使える文字に _ を含めてる時点で
プログラムの見た目は非常に重要な要素だということを
言語レベルで認定しているようなもんなんだがな。
0398デフォルトの名無しさん2008/04/13(日) 19:52:17
>>394
トークン間の空白はあるとないとで全く意味が変わる可能性があるじゃないか

ab　/*「ab」という識別子*/
a b　/*「a」と「b」という2つの識別子*/

_はあってもなくても絶対に何も変わらない

0b11 /* 10進数で3という数 */
0b1_1 /* これも10進数で3という数 */
0b____1___1_________ /* どう入れてみた所で3という数は変わりはしない */

_によって意味が変わることはどんなプログラムにおいても存在しない
だから無意味なんだ
0399デフォルトの名無しさん2008/04/13(日) 19:53:35
>>397
abとa_bとa__bは違う識別子です
0b11と0b1_1と0b1__1は全く同じ意味です
0400デフォルトの名無しさん2008/04/13(日) 19:53:36
int ab = 0;
int a_b = 0;
int a_b = 0;

意味は変わらないな。
0401デフォルトの名無しさん2008/04/13(日) 19:54:07
>>398
何故無意味か説明できていない。
早く説明してくれ。
0402デフォルトの名無しさん2008/04/13(日) 19:55:35
>>401
0bの中の_にプログラム的に意味がある場合がもしあるなら教えて下さい
0403デフォルトの名無しさん2008/04/13(日) 19:55:40
>>398
空白だって連続している場所では意味を持たない、そうでない場所では意味を持つ
'_' だって数値リテラルの中では意味を持たない、そうでない場所では意味を持つ（識別子等）

さほど大きな違いがあるようには思えないのだが。
0404デフォルトの名無しさん2008/04/13(日) 19:56:46
>>402
動作に違いが無いこととその存在が無意味であることには乖離がある。
なぜなら、プログラムはコンパイラだけが読むものではないからだ。
0405デフォルトの名無しさん2008/04/13(日) 19:57:28
>>402
特定の文脈（この場合は0bの後）でのみ意味を持たないってだけでは？
0406デフォルトの名無しさん2008/04/13(日) 19:57:55
>>401
398の説明で理解してもらえないとすれば
プログラム中の記号に「意味がある」というのはどういうことなのか
あなたの考えを聞かせていただきたい
可読性とか動作に関係ないことは除いてね
0407デフォルトの名無しさん2008/04/13(日) 19:58:40
可読性に意味が無いと言う >>406 のプログラムは
たいそう汚いんだろうな。
0408デフォルトの名無しさん2008/04/13(日) 19:59:51
そもそも必要あるの？
0b001_110_011 なんてやるより
(AAA | BBB | CCC) とかのほうが分かりやすいと思うんだけど
0409デフォルトの名無しさん2008/04/13(日) 20:00:42
>>408
場合によるのでは？
極端なケースは上で出てきたアイコンのデザインとか。
0410デフォルトの名無しさん2008/04/13(日) 20:01:42
ビットだけで考えてる人がいるようだが、
Dでは2進数に限らず _ を入れられるわけで、
長い10進数に区切りを入れるのもアリだ。
0411デフォルトの名無しさん2008/04/13(日) 20:02:30
>>406
お前プロジェクトで人の話聞かないで周りに色々迷惑かけてそうだな
>>376から続いてる話なのにどうして「可読性に意味が無い」なんて馬鹿な読み方が出来るんだ？
0412デフォルトの名無しさん2008/04/13(日) 20:02:46
move semanticsのディープな話題が出たときには沈黙してるくせに
おまえらって奴は
0413デフォルトの名無しさん2008/04/13(日) 20:03:30
頭のおかしい奴が話を引っかき回してるようなので一回寝る
0414デフォルトの名無しさん2008/04/13(日) 20:04:44
>>412
ムズカシイ話はワカラナイもん
0415デフォルトの名無しさん2008/04/13(日) 20:04:57
>>410
そういや、お金の計算だと三桁ごとにカンマを入れるなぁ。
カンマの代わりに"_"を入れることができると。
int yen = 100_000_000;
0416デフォルトの名無しさん2008/04/13(日) 20:05:26
>>403
確かにそう言われてしまうとそうなんだが
識別子中の_とリテラル中の_というのは全く別の扱いになる機能で
一方は全く無意味というのはどうなのかと
0417デフォルトの名無しさん2008/04/13(日) 20:05:43
たまたま開いたら面白そうな話してたから参加してるだけ
普段はどんな話してるのか知らない
0418デフォルトの名無しさん2008/04/13(日) 20:06:25
互換性的にはどうなの
__1とかって識別子になったっけ
0419デフォルトの名無しさん2008/04/13(日) 20:06:48
>>418
途中にしか入れられないようにすれば問題ない。
0420デフォルトの名無しさん2008/04/13(日) 20:09:45
・・・まさか >>413 は >>376 なのか・・・？
・・・ゴクリ。
0421デフォルトの名無しさん2008/04/13(日) 20:14:09
もうC++0bにしちゃえよ
0422デフォルトの名無しさん2008/04/13(日) 20:16:00
実際そうなりそうで怖い。2011年。
0423デフォルトの名無しさん2008/04/13(日) 20:26:43
そんなに無意味な表記が嫌いなら一生マシン語でコード書いてろ
0424デフォルトの名無しさん2008/04/13(日) 20:33:18
プログラミング言語自体、
マシン語のシンタックスシュガーみたいなもんだからな。
あくまでみたいなもんだけど。
0425デフォルトの名無しさん2008/04/13(日) 20:36:17
>>412
美少女中学生の話も食い付き悪くてさみしい
0426デフォルトの名無しさん2008/04/13(日) 20:58:02
>>425 昔から知的で美人の大学生のおねいさんの方がいいに決まってるんだが...
0427デフォルトの名無しさん2008/04/13(日) 21:19:59
>>425
そんなオバサンの話されても。
0428デフォルトの名無しさん2008/04/13(日) 21:29:25
構成された美少女中学生そのものが意味なのだ

パーツのどこそこに意味があるだのないだのとあげつらってみても
それらが集合して美少女中学生を構成しない限り意味を成すことはない

美少女中学生の一部分だけ見つづけると観察者はゲシュタルト崩壊を起こす
0b論も同じこと
いくら論じてもこの美少女中学生の現時点の美少女っぷりにはなんの影響も与えない

繰り返す
構成された美少女中学生そのものが意味なのだ
0429デフォルトの名無しさん2008/04/13(日) 22:04:51
それは脳内美少女中学生ってことで FA？
0430デフォルトの名無しさん2008/04/13(日) 23:08:55
お前らバイナリバイナリうるせーんだよ。

#include <boost/static_assert.hpp>

template<unsigned int v, unsigned int n> struct binary_i{
private:
BOOST_STATIC_ASSERT((n % 10) <= 1);

public:
enum{ value = (n % 10) + (binary_i<v, n / 10>::value) * 2 };
};

template<unsigned int a> struct binary_i<a, 0>{
enum{ value = 0 };
};

template<unsigned int v> struct binary{
enum{ value = binary_i<v, v>::value };
};

std::cout << binary<1001110101>::value << std::endl;
0431デフォルトの名無しさん2008/04/13(日) 23:13:32
10桁までしか使えないじゃんか・・・。
もっといいマクロならそこら辺に落ちてる。
0432デフォルトの名無しさん2008/04/13(日) 23:16:57
最低128ビットくらいは使いたいんだけど
0433デフォルトの名無しさん2008/04/13(日) 23:18:04
0bでスレが加速するってどんだけスレ違いなんだよ
0434デフォルトの名無しさん2008/04/13(日) 23:22:48
文句があるならそのマクロとやらを使ってとっととこのスレから出て行きやがれ
0435デフォルトの名無しさん2008/04/14(月) 00:31:21
ここはconstexprを使った例を出すべきだろ…
C++0x的に考えて
0436デフォルトの名無しさん2008/04/14(月) 00:39:07
どんな底辺プログラマが書き込んでるんだ?
0437デフォルトの名無しさん2008/04/14(月) 00:39:51
boost の static_assert は式版のがないのがうんこだな。
#define BOOST_STATIC_ASSERT_EXPR(b) ((void)(char(*)[(b) ? 1 : -1])0)
くらい用意してくれないと constexpr で困る。
・・・って、constexpr の引数って静的な値として認識されるんだよね？
0438デフォルトの名無しさん2008/04/14(月) 01:03:38
>>437
式版の有る無しで何が変わるの？

キャストやカンマ演算子は定数式にはなれなかったような気がするし、
静的な式なら評価タイミングも関係ないし、あんまり意味が無いような。
0439デフォルトの名無しさん2008/04/14(月) 04:35:03
#define 0B_00001111 0xff
0440デフォルトの名無しさん2008/04/14(月) 06:56:57
そうなのか・・・。
じゃあ constexpr の引数をチェックできないの？
0441デフォルトの名無しさん2008/04/14(月) 10:27:41
>>440
メタ関数書けば？
外向きに一段 constexpr 関数かませば使いやすくはなるかも。
0442デフォルトの名無しさん2008/04/14(月) 10:44:57
>>432
2進数を128桁も書きたいというお前がマレｗ
0443デフォルトの名無しさん2008/04/14(月) 13:28:45
static_assert の式版とかいうやつを使って
具体的にどういうコードが書きたいのかもうちょっとｋｗｓｋ
0444デフォルトの名無しさん2008/04/14(月) 19:18:59
式に置換するマクロで

#define TOHEX(n) (STATIC_ASSERT_EXPR(sizeof #n <= 9), 0x##n)

みたいなことをやってんだけど、
まあこれはそのまあ constexpr にするわけにゃいかんが、
constexpr の引数を静的にチェックしたいと思ってね。
typedef が constexpr の中に入れれるなら別に
BOOST_STATIC_ASSERT を使えばいいんだけど、どうだっけ？
無理なら return STATIC_ASSERT_EXPR(hoge < 10), hoge; みたいなことができれば
面白いなあと思ってね。
0445デフォルトの名無しさん2008/04/14(月) 22:37:44
いまさらだけど、0b の話って、
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
が採用されたらさらに一般化されて解決されるんじゃないの？
誰も上で話に出してなかったけど ...
0446デフォルトの名無しさん2008/04/14(月) 22:42:09
ユーザ定義リテラルは誰か途中で書いてなかったっけ
つうか0bの話ししてる奴の大半はドラフトなんか読んでないんじゃね
0447デフォルトの名無しさん2008/04/14(月) 23:38:21
>>445
キモイ記法になるから組み込みにして欲しいって話だと思ってた。
0448デフォルトの名無しさん2008/04/15(火) 00:21:30
>>445
>>259を忘れないで。
たぶんこれのことだよね？
0449デフォルトの名無しさん2008/04/15(火) 00:49:32
>>259を理解できていたらここまでスレは加速しない。
0450デフォルトの名無しさん2008/04/15(火) 01:23:02
あれって入る見込みありそうなの？
0451デフォルトの名無しさん2008/04/15(火) 01:23:26
たぶん無理
0452デフォルトの名無しさん2008/04/15(火) 03:11:10
入ったとしても定義できるのはサフィックスだけだから
0bは無理なので厨はお気に召さないだろう
0453デフォルトの名無しさん2008/04/15(火) 07:23:28
別にサフィックス b でいいよ。
0454デフォルトの名無しさん2008/04/15(火) 07:29:49
#define b0 0
#define b00 0
#define b000 0
// ... 一つの数値に128通りの#define
// = 2^129個の#define
04554452008/04/15(火) 09:59:34
すいません、アホな言い合いが続いていたので 259 を読み飛ばしてました。
でも constexpr って今の定義だとそんなに中にいろいろ書けないんじゃ？
0456デフォルトの名無しさん2008/04/15(火) 18:47:23
ループを手動でアンロールすればいいっしょ。
0457デフォルトの名無しさん2008/04/15(火) 18:47:45
ああ、配列アクセスしてる時点で無理なのか。
0458デフォルトの名無しさん2008/04/15(火) 22:59:46
N2378 と最新のドラフト読む限りでは
suffix しか無理ながら，とりあえず constexpr リテラル化はできるような？
>>259 みたいに for 文を使用 (して，かつ constexpr 化) することは
現在の提案ではできないみたいですけれど
0459デフォルトの名無しさん2008/04/16(水) 00:27:15
ようやくらしくなってきたが、未解決なのは変わらずか。
0460デフォルトの名無しさん2008/04/16(水) 03:32:48
constexpr unsigned char operator "b" (unsigned int value) {
　return (value % 10 != 0) | ((value / 10 % 10 != 0) << 1) | ...;
}

このくらいならできるのか？
0461デフォルトの名無しさん2008/04/16(水) 07:28:12
5bitしか扱えないけどね
0462デフォルトの名無しさん2008/04/16(水) 07:36:04
いつの時代の住人だ
0463デフォルトの名無しさん2008/04/16(水) 11:24:41
N2378 と N2588 に従うと以下のような感じになるとは思うんですが，
いかんせん以下をコンパイルして確認できる環境が存在しないので
間違いがある可能性が高いです．

template<char C>
unsigned long long binaryDigitToNum();

constexpr unsigned long long binaryDigitToNum<'0'>(){ return 0; }

constexpr unsigned long long binaryDigitToNum<'1'>(){ return 1; }

template<unsigned long long I, char C, char... TAIL>
constexpr unsigned long long binaryLiteralImpl()
{ return binaryLiteralImpl<I << 1 + binaryDigitToNum<C>(), TAIL>(); }

template<unsigned long long I, char C>
constexpr unsigned long long binaryLiteralImpl()
{ return I << 1 + binaryDigitToNum<C>(); }

template<char C, char... TAIL>
constexpr unsigned long long operator "b" ()
{ return binaryLiteralImpl<0, C, TAIL>(); }

普通の raw-form literal operator だと， '0', '1' 以外が来たときに
compile-time error を吐かせる方法がいまいちピンと来なかったので
variadic template form を使いました．
0464デフォルトの名無しさん2008/04/16(水) 12:22:30
しかし、この例をみるにつけても C++0x は変態ですね
0465デフォルトの名無しさん2008/04/16(水) 19:32:22
これはまだ分かりやすい方だろ。
0466デフォルトの名無しさん2008/04/16(水) 21:30:21
美少女中学生は変態さん。なんと制服の下で身体を縄で縛って学校に行っちゃうのです
0467デフォルトの名無しさん2008/04/16(水) 22:31:32
マジレスすると疲れるだけで全然えろくも変態でもない。
0468デフォルトの名無しさん2008/04/16(水) 23:03:57
>467は人生の勝ち組
0469デフォルトの名無しさん2008/04/20(日) 05:34:54
0b狂がいなくなったら誰もいなくなった
0470デフォルトの名無しさん2008/04/20(日) 10:36:22
mailing2008-03読んでるけど、
0bで馬鹿らしくなって>>257くらいしか書き込んでないw
0471デフォルトの名無しさん2008/04/20(日) 10:53:04
美少女中学生は空を見上げ待ち続けている…
0472デフォルトの名無しさん2008/04/20(日) 12:20:10
C++0xで2進リテラルを作成するスレを別に立てたらどうだ？
0473デフォルトの名無しさん2008/04/20(日) 12:22:39
糞スレたてんなよ
0474デフォルトの名無しさん2008/04/21(月) 01:15:32
>>473
読まなければ良いのでは？
0475デフォルトの名無しさん2008/04/21(月) 01:22:22
糞スレを立てると無駄なCO2を排出することになります
0476デフォルトの名無しさん2008/04/21(月) 01:31:12
俺様のゲップに含まれるメタンガスに比べれば無視できる量だけどな
0477デフォルトの名無しさん2008/04/23(水) 08:11:49
美少女中学生が排出したメタンを肺いっぱいに吸い込みたい
0478デフォルトの名無しさん2008/04/23(水) 08:33:53
つ （美少女の）硫化水素
0479デフォルトの名無しさん2008/04/23(水) 12:15:45
お前らスレタイ0x100回読め
0480デフォルトの名無しさん2008/04/23(水) 18:33:01
スレンダーでタイツの似合う美少女中学生が俺の嫁
0481デフォルトの名無しさん2008/04/23(水) 18:35:18
256回読みましたがわかりませんでした
0482デフォルトの名無しさん2008/04/26(土) 22:18:03
>>481
美少女中学生について語ってはならないとは
スレタイにもテンプレにも書いてないんだが

# 個人的には平面の方が好きなんだけどな
0483デフォルトの名無しさん2008/04/26(土) 23:25:12
C++0xは3次元あるいはそれ以上の次元を持つとはどこにも書いていないぞ。
まあ2次元とも決まっていないがな。
＃ん、C++タンの出番だな。
0484デフォルトの名無しさん2008/04/26(土) 23:27:23
N2582
新しい関数宣言方法（ラムダ式と同じ形にする案）
[]foo(int x) -> int { return x; }
0485デフォルトの名無しさん2008/04/26(土) 23:30:30
[] は大変キモいので、こういうマクロを標準で提供して欲しい。
lambda とかいうヘッダファイルを用意して。

#define labmda []
foo(lambda foo(int x) -> int { return x; });
0486デフォルトの名無しさん2008/04/26(土) 23:33:19
typo したがｷﾆｼﾅｲ
0487デフォルトの名無しさん2008/04/27(日) 00:49:50
[] にはもう既に慣れちゃった
0488デフォルトの名無しさん2008/04/27(日) 03:30:50
委員会のキーワード忌避は強迫観念レベルだな
0489デフォルトの名無しさん2008/04/27(日) 03:33:59
それほど既存のソースが多すぎるのさ。
そこはしゃーないと思う。
でも、C99 の #define bool _Bool みたいに
互換性を保ちつつキーワードを導入するテクはもっと使ってもいいと思う。
0490デフォルトの名無しさん2008/04/27(日) 03:48:53
無名関数のおかげで無名構造体にコンストラクタとデストラクタを搭載できるようになりました！
大勝利ですね！
0491デフォルトの名無しさん2008/04/27(日) 04:06:37
一方ロシアはコンストラクタをthisで定義できるようにした。
0492デフォルトの名無しさん2008/04/28(月) 11:12:49
なんでlambda expressionのlambda-return-type-clauseって、
->を使うんだろ。
コロンじゃだめだったのかな。
たとえば、普通の関数も統一しようぜっていうN2582も、
こんな風に書けるのに。

[] func() : int
{
　　return 0 ;
}
0493デフォルトの名無しさん2008/04/28(月) 11:35:23
#define : ->
は無理だったっけ ...
0494デフォルトの名無しさん2008/04/28(月) 11:44:20
>>492
見た目が違うだけじゃんw
0495デフォルトの名無しさん2008/04/28(月) 13:33:02
　[] main(int argc, char* argv[]) -> int
　{
　　//...
　}
0496デフォルトの名無しさん2008/04/28(月) 18:35:05
>>492
コロンはコンストラクタの初期化子と競合しそうだな。
0497デフォルトの名無しさん2008/04/28(月) 18:38:20
コンストラクタでは戻り値の型がないから大丈夫じゃね。
文法的な紛らわしさに関してはまああるかもしれないが。
0498デフォルトの名無しさん2008/04/28(月) 18:46:28
ECMAScript4ってそんな感じじゃなかったっけ
いやだなぁ
0499デフォルトの名無しさん2008/04/28(月) 19:30:15
function func() : int { return 0 ; }
だったか。ECMAScript4は文法キモすぎて見たくもない。
いつのまにかコンストラクタの初期化子まで採用してるし。
0500デフォルトの名無しさん2008/04/28(月) 19:35:51
テンプレートもあるよ！
function func.<T>() : T { return new T(); }
0501デフォルトの名無しさん2008/04/28(月) 20:35:43
ぐはぁ
0502デフォルトの名無しさん2008/04/28(月) 20:42:16
しかしなぜ->なんだ
Haskellかよ
0503デフォルトの名無しさん2008/04/28(月) 21:04:22
プログラミング言語 Scala
http://pc11.2ch.net/test/read.cgi/tech/1205156417/

Scala違いだ移動しる・・
0504デフォルトの名無しさん2008/04/28(月) 22:49:10
returnでいいじゃんかよ
コンフリクトはないはずだ

[] func() return int
{
　　return 0 ;
}
0505デフォルトの名無しさん2008/04/28(月) 22:50:51
なんかもうどうやってもキモいんだが。
0506デフォルトの名無しさん2008/04/28(月) 22:52:00
ラムダ式くらい 100% 型推論でやってくれ。
0507デフォルトの名無しさん2008/04/28(月) 22:53:18
そもそもどうしてラムダと形を合わせたいんだ
コピペのためか？
0508デフォルトの名無しさん2008/04/28(月) 22:56:04
関数型言語的には→なんだから、
->でいいんじゃないの？
0509デフォルトの名無しさん2008/04/28(月) 22:58:39
関数型言語的にどうかは知らんしどうでもいいが
C系言語的には->は昔からずっと間接参照演算子だ
0510デフォルトの名無しさん2008/04/28(月) 23:13:55
美少女中学生的には -> と [] はブラのホックの両端だから
0511デフォルトの名無しさん2008/04/28(月) 23:26:17
>>504
それ、俺も思っていたんだけど、
C++の文法としては、何か違和感あるよね。

ところで、@と$がC++の規格にないのは、何か理由があるの？
0512デフォルトの名無しさん2008/04/28(月) 23:30:21
[] int foo() { ... } で不都合があったから -> になったんだと思うが、
どんな不都合があったの？
0513デフォルトの名無しさん2008/04/28(月) 23:50:13
returnsのほうがいい
0514デフォルトの名無しさん2008/04/28(月) 23:53:10
>>512
(charからcharへの関数)を引数に取り(intからintへの関数)を返す関数
を引数に取り(charからintへの関数)を返す関数の型を、
C++03(「関数」は「関数へのポインタ」とする)とC++0xで書いてみてくれ。
0515デフォルトの名無しさん2008/04/28(月) 23:58:27
int (*(int (*(*)(char (*)(char)))(int)))(char) のことだよね？
0516デフォルトの名無しさん2008/04/29(火) 00:10:24
グロい
0517デフォルトの名無しさん2008/04/29(火) 00:11:59
まぁ現状十分汚い言語なんだから、
多少醜くなってもいいじゃん
0518デフォルトの名無しさん2008/04/29(火) 00:14:30
>>517
いいこと言うなあ。君のそのレスで俺の気持ちは吹っ切れたよ。
0519デフォルトの名無しさん2008/04/29(火) 00:19:47
[]([]([](char)->char)->([](int)->int))->([](char)->int)
0520デフォルトの名無しさん2008/04/29(火) 02:22:09
typedef char (*ctoc_t)(char);
typedef int (*itoi_t)(int);
typedef int (*itoc_t)(char);
typedef itoi_t (*ctoc_to_itoi_t)(ctoc_t);

typedef itoc_t (*answer_t)(ctoc_to_itoi_t);

こんな型何に使うかは知らんが、使うとしたら
きっと近くでitoc_t型やctoc_to_itoi_t型の変数も必要になるだろ
ならそんなキモい書き方しないで必要なものをtypedefで作るべき
0521デフォルトの名無しさん2008/04/29(火) 06:35:41
>>519の方がわかりやすいが?
0522デフォルトの名無しさん2008/04/29(火) 07:06:50
>>519
これは従来のアナルっぽい記法よりは読みやすいな
0523デフォルトの名無しさん2008/04/29(火) 07:15:37
>>511
いまさらtrigraphやdigraphの要るような記号追加するのもねえ…ってことじゃないかと予想
0524デフォルトの名無しさん2008/04/29(火) 07:38:26
>>523
そういう理由なのかなぁ。
しかし、trigraphやdigraphって廃止しても、それほど互換性の問題も無いんじゃないかなとおもったりするんだけど。
西側の、なまじ7bitで全種類の文字を表せちゃったので、悲惨なことになっている連中も、
結局使ってないみたいだし。
0525デフォルトの名無しさん2008/04/29(火) 09:39:20
>>521
まずそんなものを書く状況自体が無いな。
あっても >>519 も読みづらいから typedef 使うわ。
0526デフォルトの名無しさん2008/04/29(火) 11:51:29
C++でtypedefを禁止したらどんなカオスなコードになるか見てみたい
0527デフォルトの名無しさん2008/04/29(火) 11:53:44
>>526
template メタプログラミングがかなり出来なくなる気が ...
0528デフォルトの名無しさん2008/04/29(火) 11:58:25
>>526
decltype と auto を駆使することになる
0529デフォルトの名無しさん2008/04/29(火) 18:05:21
あーはやくautoが欲しい
0530デフォルトの名無しさん2008/04/29(火) 19:02:48
正直、auto 以外、いらん。初期化もまぁあればいいね、程度だし
0531デフォルトの名無しさん2008/04/29(火) 19:46:54
ここまでいじっちゃうともう新しく言語作った方が早い気がするしな。
0532デフォルトの名無しさん2008/04/29(火) 19:51:44
Cとの互換性をとりつつ拡張するのに苦労してんのにそんな事言うなよ
0533デフォルトの名無しさん2008/04/29(火) 20:12:56
互換性無視できる
ネイティブディレクティブとか作ろうよ
0534デフォルトの名無しさん2008/04/29(火) 20:36:05
もう互換性なんかとっくにボロボロなのに今更何を
0535デフォルトの名無しさん2008/04/29(火) 21:37:43
>>530
初期化指定子で初期化指定が完了するのは美しいと思わんか
0536デフォルトの名無しさん2008/04/29(火) 21:54:12
なぁ、これは俺の思い過ごしかもしれんのだが

ヒープ領域って誰が管理してくれるんだ?

ラムダ返されて、それ引数に関数呼び出して
関数の中でグローバルに束縛されて... ... ...

でも, らむだはデストラクションしないとまずいんだろ？
0537デフォルトの名無しさん2008/04/29(火) 22:07:15
関数を動的に生成してるわけじゃないだろ
0538デフォルトの名無しさん2008/04/29(火) 22:17:48
536 に便乗で聞くけど、
例えば C# の場合、ローカル変数を参照するようなラムダ式書くと、
クラスが自動生成されて、ローカル変数参照がメンバ参照に置き換わるんだけど、
そういう状態になった場合、デストラクタはどこで呼ばれるの？

ローカルスコープ内でしか使わないラムダ式ならいいけど、
例えば、「ラムダ式を返す関数」みたいなの作っちゃった場合。
0539デフォルトの名無しさん2008/04/29(火) 22:21:56
そんなのローカル変数のポインタ返してるのと一緒だろ
クラッシュしても自業自得で済まされる話
C++はプログラマを全面的に信頼する言語ですよ
0540デフォルトの名無しさん2008/04/29(火) 22:24:33
>>537
あんまマジにシンタックス見てないんであれなんだが

こんな感じの関数書くとするやん？
f(x, y) {
return [copy x]lambda(y){+ x; ...}
}
この場合, x はスタックじゃなくてヒープに取るしかないと思うんだ

で,
g(f(1), f(2)...)
とかな感じで, 呼び出したら？
f が返す関数に束縛されてる x がコピーされた領域は誰が回収するんだろ?

と、思った
0541デフォルトの名無しさん2008/04/29(火) 23:01:43
ん、よくわからん。
スタックじゃないの？
0542デフォルトの名無しさん2008/04/29(火) 23:04:43
alloca() を思い出した
0543デフォルトの名無しさん2008/04/29(火) 23:08:10
new [...] (...) {...}
はないの？よくわからんけど
0544デフォルトの名無しさん2008/04/29(火) 23:23:24
ラムダ式は関数オブジェクトのシンタックスシュガー
なので、単なる一時オブジェクトとして生成されると思う
0545デフォルトの名無しさん2008/04/29(火) 23:24:34
関数から返せないということか。
何かエセっぽいな。
0546デフォルトの名無しさん2008/04/29(火) 23:28:11
C的に考えると、それでいい気がする。
0547デフォルトの名無しさん2008/04/29(火) 23:30:37
折角だからカリー化とかしたいのになあ。
0548デフォルトの名無しさん2008/04/29(火) 23:31:35
ラムダキャプチャーを参照でなく値(コピー)にしたら返せる
関数オブジェクトと同じ
でも、戻り値の型を特定できないかも、新シンタックスで可能？
0549デフォルトの名無しさん2008/04/29(火) 23:33:07
カリー化は手動だな
0550デフォルトの名無しさん2008/04/29(火) 23:33:48
>>544
となると、>>543 みたいな、ラムダ式をヒープに取るような構文が必要じゃない？
（スマートポインタ使うにしても、まずはただのポインタが要るし。）

それか、ラムダ式から生成される関数オブジェクトが
適切な operator = を実装しててくれるなら別にどうでもいいことなのかな。
0551デフォルトの名無しさん2008/04/29(火) 23:37:49
>>550
あっても困らないけど、なくても良いと思う
ポリモーフィズムは必要ないし、必要なら従来の関数オブジェクトがあるし
0552デフォルトの名無しさん2008/04/30(水) 00:13:58
本物のC++プログラマは動的解決をしない。
本物のC++プログラマはコンパイル時に解決する。
コンパイラでできなければ、プリプロセッサでやる。
プリプロセッサでできなければ、それはやる価値が無いのだ。
0553デフォルトの名無しさん2008/04/30(水) 00:16:03
new を入れたのが間違いの始まりだったんですね
0554デフォルトの名無しさん2008/04/30(水) 00:30:05
プリプロセッサ（笑）
0555デフォルトの名無しさん2008/04/30(水) 00:36:14
タイトルはどうなるんだろう。
「本物のプログラマはJavaを使わない」
あたりかな
0556デフォルトの名無しさん2008/04/30(水) 00:36:39
本物のプログラマネタが分からないのは
流石に本物のプログラマとは言えないな。
0557デフォルトの名無しさん2008/04/30(水) 00:45:50
本物のプログラマがわからなければ、そのネタは理解する価値が無いのだ。
0558デフォルトの名無しさん2008/04/30(水) 01:03:02
>>555
間違いなく言語と環境をごっちゃにした反論が帰ってきそうなタイトルだなｗ
0559デフォルトの名無しさん2008/05/04(日) 00:38:19
conceptがまだドラフトに入らないのが気になる
一番楽しみなのに
0560デフォルトの名無しさん2008/05/04(日) 00:39:07
独立wordingの方でまだまだ直しが続いてる。
0561デフォルトの名無しさん2008/05/05(月) 18:01:34
ここで聞くか、Boostスレで聞くか迷ったんだけど、
Unordered associativeコンテナの、bucket関連のメンバってなんに使うの？
規格読んだだけだと、どうもよくわからないんだけど。
あるキーがどのbucketに属するかのインデックスを返されたとしても、
実際のbucket単位に直接アクセスする方法って無いよね？
普通に要素へのイテレータしかないみたいだし。
そのどのbucketに入れられているかってことが分かって、ライブラリを使う側の人間にとって、何がうれしいの？
0562デフォルトの名無しさん2008/05/05(月) 19:14:44
>>561
begin(i),end(i) で local_iterator を取得できたような。
ハッシュの分散結果をどう使うかってことなので、カスタムハッシュ関数次第
じゃないか？ まあ通常はあまり使わないかも
0563デフォルトの名無しさん2008/05/05(月) 19:23:03
どっかのbucketにばっかり入っちゃうようなデータで、そのせいで遅くなるようなときに
調査するためじゃねえの
0564デフォルトの名無しさん2008/05/05(月) 19:27:20
>>561
詳しいドキュメント読んでないから分からんけど、たぶん同一 hash 値だったら
同一の bucket に入ることが保証されるはずだから、次のような使い方ができる。

次の問題を考える：
　二次元平面上の点が大量に与えられる。これを前処理して
　新たな点 p が与えられたときに p に最も近い点を求めよ。

こんなときに、最初の二次元平面上の点に対して、ハッシュ関数を
(x座標値/1000)×(y座標値/1000) なんかに設定したコンテナを用意すると
元のデータが結構ばらけていたら、「同一 bucket 内に入るデータを全部調べる」
みたいなアルゴリズムで結構効率的に解ける。
0565デフォルトの名無しさん2008/05/05(月) 19:59:38
おもろい
0566デフォルトの名無しさん2008/05/05(月) 20:46:02
>>562
本当だ。
引数を取るb.begin(b), b.end(b)があったのか。
local_iteratorは、あるbucket内の要素のイテレータとは。

しかし、>>564には疑問だな。
例えば、その点pのハッシュ値が、ちょうどbucket単位の境にあった場合、
点pに最も近い点は、別のbucketに入るんじゃない？
すると、隣接するbucketも調べないといけないよね？
少なくとも二つ、大抵の場合は三つ。

それに、規格にあるのは、
>Keys with the same hash code appear in the same bucket.
だけで、似たようなハッシュ値が同じbucketに入るとは規定してないし。
隣接するbucketに入るとも規定されてないよね。

あくまでハッシュという名称を使っているだけで、実装じゃないし。
0567デフォルトの名無しさん2008/05/05(月) 21:01:51
境界の違うハッシュを2つ使えば？
(x/1000)*(y/1000) と ((x+500)/1000)*((y+500)/1000) みたいな
05685642008/05/05(月) 21:33:30
>>566
bucket の番号を用いる例のためだけに、アルゴリズムの細かなことを書くのは
面倒だったから、本当に方針だけを書いたつもりなんだけどなあ。


まず、点を含む領域以外も見ないといけないのはそのとおりで、
ちゃんとやるには、点を含む領域から近い順に探索することになる。
（それまでに見つけた最も近い点までの距離を覚えておき、
　見る必要のある領域を限定していく）

見る領域に対応する bucket の番号は、領域の座標値が分かっているのだから
領域座標 → ハッシュ を計算してやった後に ハッシュ → bucket 番号と取得する。
このとき、隣接領域で bucket 番号が隣接している必要はない。

詳しいことは、適当な計算幾何学の本を読んで欲しいところ。
こういうのはバケット法などの名前で知られている割と標準的な技法。
0569デフォルトの名無しさん2008/05/05(月) 21:36:55
えぴが陰毛茫々じゃないから
進みが遅いと思う
0570デフォルトの名無しさん2008/05/05(月) 21:40:38
>>566
いや、だから規格では、同じハッシュ値のキーが同じbucketに入ってるって事ぐらいしか、
規定されてないような気がするんだけど。
似たようなハッシュ値が同じ、あるいは近いオフセットのbucketに入っているかもしれないとは書いてない。
そりゃ、大抵の実装はそうなるだろうけど。
0571デフォルトの名無しさん2008/05/05(月) 21:40:59
間違えた、>>568
0572デフォルトの名無しさん2008/05/05(月) 22:01:44
>>561
http://cpplover.blogspot.com/2008/05/c0xunordered.html
0573デフォルトの名無しさん2008/05/05(月) 22:05:07
>>570
似たような点を同じハッシュにするって話じゃないの？
05745642008/05/05(月) 22:10:03
>>570
なんで似たようなハッシュ値が近いbucketに入る必要があると思うの？
そういう必要は無いですよ、と588で
> このとき、隣接領域で bucket 番号が隣接している必要はない。
と明記したつもりなんだけどなあ。


具体例で説明すると、たとえば 1000×1000 のメッシュに切って、
(x/1000)×(y/1000) % 100 をハッシュ関数として設定したとしよう。
ここに (10000,10000) の点 p が与えられたとしよう。
この点を含む領域に対応するハッシュ関数値は (10×10) % 100 = 0 だから、
ハッシュ関数値 0 に対応する bucket を持ってくればいい。
(点 p に対して bucket(p) を実行することが、この操作に対応する）

次に、この点を含む領域の左側の領域を調べることにしよう。
左側の領域の座標に対応するハッシュ関数値は (9×10) % 100 = 90
だから、ハッシュ関数値 90 に対応する bucket を持ってくればいい。
（p を左に 1000 だけ平行移動した点 q に対して
　bucket(q) を実行することがこの操作に対応する）
0575デフォルトの名無しさん2008/05/05(月) 22:34:13
で、0x関係あんのか
0576デフォルトの名無しさん2008/05/05(月) 22:41:03
>>574
関係ねーだろ10000回染んで来い
0577デフォルトの名無しさん2008/05/05(月) 23:41:50
そんなにdelete thisできないな
0578デフォルトの名無しさん2008/05/06(火) 00:17:58
>>570
つうか、一体何が疑問なんだ
同じハッシュ値のキーが同じbucketに入ってるって事が規定されてりゃ十分だろう
同じハッシュ値になるようにハッシュ関数を作れば同じbucketに分類されるんだから
0579デフォルトの名無しさん2008/05/06(火) 05:45:07
ああ、なるほど。
似たようなキーを同じハッシュにするのか。
それで(x座標値/1000)×(y座標値/1000)だったのか。
0580デフォルトの名無しさん2008/05/06(火) 21:04:03
レベルが高すぎてよくわからん
0581デフォルトの名無しさん2008/05/06(火) 21:05:26
そんなに高くないよ
情報系の学校入れば絶対習う程度
0582デフォルトの名無しさん2008/05/06(火) 21:26:48
学無くても考えれば分かりそうな。
0583デフォルトの名無しさん2008/05/06(火) 22:06:41
修学旅行での温泉の脱衣場の洗濯カゴみたいなもんだ
一つのカゴで一人の美少女中学生をイテレートできる
美少女中学生は控えめだから棚の下の方にハッシュされてるという寸法さベイベ♪
0584デフォルトの名無しさん2008/05/06(火) 22:08:43
下着がなくなってたりするんだな
0585デフォルトの名無しさん2008/05/06(火) 22:54:27
露骨なエロで興奮するあたり、それらが控えられた萌えに欲情する若者とは違うという部分がみえみえなスレだな。
勢力の足りないおっさんが無理にネタ振らなくても良いんだぜ？つまらないだけだから。
0586デフォルトの名無しさん2008/05/07(水) 02:20:45
age
0587デフォルトの名無しさん2008/05/09(金) 03:27:54
>>585
つまらない。
0588デフォルトの名無しさん2008/05/09(金) 09:42:13
どうでもいいよ
0589デフォルトの名無しさん2008/05/14(水) 03:55:48
ここんとこ寒いね
0590デフォルトの名無しさん2008/05/14(水) 04:05:16
うんそうだね
0591デフォルトの名無しさん2008/05/14(水) 04:34:23
今までが暑くて相対的に寒く感じるだけ。
平年並みだろ。
0592デフォルトの名無しさん2008/05/14(水) 21:41:35
それだけ暑いのが続けば「平年並み」の気温も底上げされててもいいんだがなあ。
0593デフォルトの名無しさん2008/05/17(土) 18:02:04
平均気温は過去20年のデータで計算するから、20年間で急激に気候が変動してると追いつかない。
そんだけ温暖化が深刻ってこったな。
0594デフォルトの名無しさん2008/05/17(土) 18:45:41
strong typedef って入るんだったっけ？
0595デフォルトの名無しさん2008/05/17(土) 19:32:54
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2141.html
これか？
入る見込みは無さそうだねぇ。

ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2565.html
>Not ready for C++0x, but open to resubmit in future

BOOST_STRONG_TYPEDEFでもつかっておけば。
0596デフォルトの名無しさん2008/05/17(土) 20:20:55
strong typedefってどういう物？
usingとかとは違くて？
0597デフォルトの名無しさん2008/05/17(土) 20:41:23
typedef元とtypedef先が別の型として扱われるというtypedef。
0598デフォルトの名無しさん2008/05/17(土) 20:43:10
C++09 になってんのか、もう。
0599デフォルトの名無しさん2008/05/17(土) 20:58:14
え、まじ？
0600デフォルトの名無しさん2008/05/17(土) 21:12:18
あ、いや、ちゃうわ。ごめん。
0601デフォルトの名無しさん2008/05/17(土) 22:19:45
>>597
それあったらテンプレートがまたワクワクするものになりそうだな
0602デフォルトの名無しさん2008/05/17(土) 22:38:47
数値型の暗黙の変換はC/C++の型システムの穴だから
strong typedef でまずその穴をふさぎたい
0603デフォルトの名無しさん2008/05/17(土) 22:43:14
そんなもん別に機能にしなくてもこれでいいんじゃないの

class AnotherType : public Type{
private:
　operator Type();　//実装しない
}
0604デフォルトの名無しさん2008/05/17(土) 22:44:25
そんなこともできるのか。それは欲しい
0605デフォルトの名無しさん2008/05/17(土) 23:11:50
intとかでもやりたいんでは
0606デフォルトの名無しさん2008/05/18(日) 22:50:15
実装あるもんなw
0607デフォルトの名無しさん2008/05/18(日) 23:24:53
もう#define int nanikaしろよ
0608デフォルトの名無しさん2008/05/19(月) 00:05:38
要するにこういうの作ればいいんだろ？

#include <iostream>

#define STRONG_TYPEDEF(base, name) \
template <typename Dummy = void> class name##_ { \
public: \
name##_() { } \
explicit name##_(const base& value) : m_value(value) { } \
base& get() { return m_value; } \
const base& get() const { return m_value; } \
name##_& operator=(const name##_& rhs) { m_value = rhs.m_value; return *this; } \
friend name##_ operator+(const name##_& lhs, const name##_& rhs) { return name##_(lhs.m_value + rhs.m_value); } \
private: \
base m_value; \
}; \
typedef name##_<> name

struct TestBase { void show() { std::cout << "Test" << std::endl; } };

STRONG_TYPEDEF(int, Hoge);
STRONG_TYPEDEF(TestBase, Test);

int main() {
Hoge a(1), b;
b = Hoge(2);
std::cout << (a + b).get() << std::endl;

Test t;
t.get().show();
}
0609デフォルトの名無しさん2008/05/19(月) 07:37:07
手抜きをするためのものなのに、メンバがコピーされないようじゃ意味がない。
0610デフォルトの名無しさん2008/05/21(水) 10:29:55
mailing 2008-05 きてるお
0611デフォルトの名無しさん2008/05/21(水) 11:09:49
^ω^
0612デフォルトの名無しさん2008/05/21(水) 12:32:56
>>610
乙
0613デフォルトの名無しさん2008/05/21(水) 12:37:34
コンテナとかSTLがみんなconcept化されてる！
0614デフォルトの名無しさん2008/05/21(水) 12:42:31
ドラフトは N2606
0615デフォルトの名無しさん2008/05/21(水) 12:48:01
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2601.html
がスゲイ
0616デフォルトの名無しさん2008/05/21(水) 18:04:02
C99と同じ感じになったりしないの？
現行のC++から、この仕様のC++にキレイに置き換わってしまう？
また、複雑難解怪奇な文法を覚え直さなければいけないの？
0617デフォルトの名無しさん2008/05/21(水) 18:49:37
>>616
GCCだけでなくVC++も実装してくると思う、現にTR1も対応しているし。
C99よりは広まると思う。

文法はどうしようもないな。現在でも複雑怪奇なんだから
今さら少しくらい増えたってどうってことないって構えをしたほうがいいかも。
0618デフォルトの名無しさん2008/05/21(水) 18:50:26
better C++03 として使う人が多そうな予感。
auto とかは使うけど・・・って感じ。
0619デフォルトの名無しさん2008/05/21(水) 20:38:48
ぶっちゃけC++が廃れる要因になるだけな気がしないでもない
0620デフォルトの名無しさん2008/05/21(水) 20:49:42
化粧を覚えたてでちょっと厚塗りしてみた美少女中学生のような感じだな
化粧のナイステクを見つけるのが先かこっちが見慣れるのが先かというところか
0621デフォルトの名無しさん2008/05/21(水) 21:21:56
今はネイティブで代わりがないから C++ 一択だけど、ObjCを綺麗にしたようなクラスベースの
言語があれば、もう C++ にこだわる気になれないなぁ。うんざりする
0622デフォルトの名無しさん2008/05/21(水) 21:36:41
Cに速度的な最適化を期待したのが間違いだったんだ。
やるならfortranを++すれば良かったのに。
0623デフォルトの名無しさん2008/05/21(水) 21:38:00
>>622
そこで Fortress ですよ
0624デフォルトの名無しさん2008/05/21(水) 22:35:21
>>621
だからD言語を使えと(ry
0625デフォルトの名無しさん2008/05/21(水) 22:36:59
>>623
あれは数値計算用途以外では使いたい文法でもないけど・・・
それ以前に、なかなか開発進んでなくね？
0626デフォルトの名無しさん2008/05/21(水) 22:40:30
>624
GC がいらない
0627デフォルトの名無しさん2008/05/21(水) 23:09:24
>>616
(ほぼ)今のままのコードで動く。
0628デフォルトの名無しさん2008/05/21(水) 23:10:26
>>626
GCありというか明示的メモリ管理なしのC++ってもの使ってみたい。
DとかJavaじゃなくて、まっとうなC++で。
0629デフォルトの名無しさん2008/05/22(木) 00:25:00
>628
だが、リソース管理は結局自前だろ
ファイナライザは入れないんだよな
0630デフォルトの名無しさん2008/05/22(木) 20:45:13
>>618
現行でC++03としても使えてない奴の方が多いからな
その辺はしゃーない
0631デフォルトの名無しさん2008/05/22(木) 22:04:12
サブセットでヘッダの要らない仕様を作ってくれないかな。
どうせ、プリコンパイルヘッダみたいな事やるんだから、
.cppをプリコンパイルして参照解決したっていいじゃん。
0632デフォルトの名無しさん2008/05/22(木) 22:09:22
そうやってサブセットのスーパーセットを考えてるうちに C# になってしまいました
0633デフォルトの名無しさん2008/05/22(木) 22:12:52
>>631
モジュールシステムを設計しなおすことになると思う
0634デフォルトの名無しさん2008/05/22(木) 22:49:18
仕様を作るのはいいけどさ、
とりあえずその前にほとんどのコンパイラベンダに言いたいんだが
export を実装してくれよ！

Comeau 以外どこか実装してんの？
0635デフォルトの名無しさん2008/05/22(木) 22:51:43
実装が大変な割に大したメリットがないからじゃないの
0636デフォルトの名無しさん2008/05/22(木) 22:54:50
exportの実装がめんどうになった時点で分割コンパイルなんてあきらめればよかったのだ
0637デフォルトの名無しさん2008/05/22(木) 22:59:03
extern inline なんかどこも完全実装できてないしな
Comeauでさえ
0638デフォルトの名無しさん2008/05/22(木) 23:51:17
>>615
提案しているのが Lawrence Crowl だし，ほんの一瞬とはいえ
本気にして「なんだ！？とち狂ったのか！？」とか思った俺涙目ｗｗｗ
0639デフォルトの名無しさん2008/05/23(金) 05:58:24
>>638
ｗ
ま、いつか入るかもな。競合は大丈夫そうだし。
16進浮動小数点数リテラルとか知名度低いのもあるし、こっそり紛れてても誰も騒がないでしょｗ
0640デフォルトの名無しさん2008/05/23(金) 18:12:45
ASCII外の字をプログラム本文に持ち込むことをあっちの国の人らが許すはずがない
0641デフォルトの名無しさん2008/05/23(金) 19:20:22
コメント文字列をプログラム本文とみなすかどうかだが
普通にやってるとチェコ語だかでパース失敗しなかったか？
0642デフォルトの名無しさん2008/05/23(金) 19:26:27
なんだそりゃ。
まさかチェコ語は、スラッシュやアスタリスクにまで独自の文字を割り当てているのか？
0643デフォルトの名無しさん2008/05/23(金) 20:05:42
チェコ語ということはutf-8か？
-Ku は当然付けてるよね。
0644デフォルトの名無しさん2008/05/23(金) 21:06:45
コメントに??付けるだけでおかしくなります
0645デフォルトの名無しさん2008/05/23(金) 22:02:47
もう APL になったつもりで変な字いっぱい使おうぜ
0646デフォルトの名無しさん2008/05/23(金) 22:46:19
トリグラフも迂闊に追加できないこんな世の中じゃ。
0647デフォルトの名無しさん2008/05/23(金) 23:01:50
つまりクアッドグラフが求められる時代になったということですね
0648デフォルトの名無しさん2008/05/23(金) 23:42:00
concept 使った for_each がこう提案されてる
auto がこんな使い方できるんだ

template<InputIterator Iter, Callable<auto, Iter::reference> Function>
Function for_each(Iter first , Iter last , Function f );

役立たずだった auto が大人気だ
0649デフォルトの名無しさん2008/05/23(金) 23:46:41
大人気で広まる
↓
恐ろしい副作用が見つかる
↓
カオス

の黄金パターンですね、わかります
0650デフォルトの名無しさん2008/05/24(土) 00:04:34
>>639
十六進浮動小数点数は、C99由来だから知名度低くても余裕で入るだろ、たぶん。
0651デフォルトの名無しさん2008/05/24(土) 01:17:23
concept のようなメタタイプを持つ言語がほかにあるんでしょうか？
Haskellのほかに
静的型付言語で
0652デフォルトの名無しさん2008/05/24(土) 03:58:02
>>651
conceptの型理論を書いた人たちがGってのを作ったよ。
他にはない。concept_mapみたいなglueがあるのは。
0653デフォルトの名無しさん2008/05/24(土) 11:43:16
conceptの一番の利点はコンパイル時のエラーメッセージ
0654デフォルトの名無しさん2008/05/24(土) 12:39:46
>>653
concept_mapを理解してないね。
0655デフォルトの名無しさん2008/05/24(土) 12:41:52
今度はコンセプトメタプログラミングの時代ですか
0656デフォルトの名無しさん2008/05/24(土) 12:44:38
自然な流れじゃないかな
ジェネリックス系としては
0657デフォルトの名無しさん2008/05/24(土) 14:23:27
そしてC++1xでは
コンセプトの型を規定するスーパーコンセプトが目玉機能になるんですね
わかりました
0658デフォルトの名無しさん2008/05/24(土) 14:32:03
滅多metaな超言語それがC++1x
0659デフォルトの名無しさん2008/05/24(土) 15:10:08
C++ 捨てて別言語使った方がいいんじゃね？
と、マジで思う今日このごろ
0660デフォルトの名無しさん2008/05/24(土) 15:11:07
そんなあなたにC++0x。 もはや別言語だから。
0661デフォルトの名無しさん2008/05/24(土) 15:12:28
まともなC++0x処理系ができるまでは暫く離れるのもいいだろうな
0662デフォルトの名無しさん2008/05/24(土) 15:18:31
C++3xで会いましょう
0663デフォルトの名無しさん2008/05/24(土) 16:09:52
namespaceスコープでアクセス制御が出来たらいいと思わね？

namespace hoge {
private: void priv();
public: void pub() { priv(); }
}
hoge::priv(); // error
0664デフォルトの名無しさん2008/05/24(土) 16:20:34
>>663
入れ子にした無名 namespace で代用できない？
0665デフォルトの名無しさん2008/05/24(土) 16:44:37
>>657
concept はコンセプトをパラメータにとることが出来るのでメタコンセプトは必要ないと思う
0666デフォルトの名無しさん2008/05/24(土) 16:46:20
無名にしなくても、boostの
namespace detail {
はそういうことやってるんだわな。
>>663はスロット単位でやりたいんだろうけど。
0667デフォルトの名無しさん2008/05/24(土) 17:02:23
>>654
「自尊心はあっても自信が無い」から、衝動で突っ込むけど説明添える勇気は無いんですね、わかります。
0668デフォルトの名無しさん2008/05/24(土) 17:51:48
整数のイタレータのサンプルコード見ればいいんじゃない？ > concept_map
0669デフォルトの名無しさん2008/05/24(土) 18:01:51
autoとcenceptでC++も分かりやすい言語になるかなあ。
0670デフォルトの名無しさん2008/05/24(土) 18:04:22
ならんね
0671デフォルトの名無しさん2008/05/24(土) 18:13:27
そもそも、現行C++も分かりやすい言語にするために
突っ走ってきたという面が多かったと思う、D&E読んだ直後の感想。

しかし、現実はと言うと……。
0xも同じ道を辿るに違いない。
0672デフォルトの名無しさん2008/05/24(土) 18:17:27
>>671
> 分かりやすい言語にするために

皮肉とかじゃなく、そうは思えません。
やはりCとの互換性を抑えた上での、実行効率をメインに考えてきたと思います。
0673デフォルトの名無しさん2008/05/24(土) 18:21:59
>>665
ｋｗｓｋ
0674デフォルトの名無しさん2008/05/24(土) 18:42:42
Perl6 の二の舞になる、なんてことはないよな。あはは
0675デフォルトの名無しさん2008/05/24(土) 18:42:58
>>673
やっぱ出来ねえや
勘違い
0676デフォルトの名無しさん2008/05/24(土) 20:09:08
最近は使う人にやさしくなってきてるよね

つらいのはコンパイラベンダやライブラリベンダ
0677デフォルトの名無しさん2008/05/24(土) 20:21:53
ここまで巨大仕様になるともう新規参入とか不可能だよな
0678デフォルトの名無しさん2008/05/27(火) 08:48:19
GCCからforkすればいい。
0679デフォルトの名無しさん2008/05/27(火) 16:55:43
現行の auto って型名のかわりに
auto i = v.begin();
みたいな書き方をする以外に使い方ありますか？
0680デフォルトの名無しさん2008/05/27(火) 19:07:49
型名の現れうる場所全てに現れて
福音と混沌をもたらします
0681デフォルトの名無しさん2008/05/27(火) 20:05:28
>648
0682デフォルトの名無しさん2008/05/27(火) 20:13:09
自動変数の宣言
0683デフォルトの名無しさん2008/05/27(火) 20:13:47
使うだけの人間としては規格の議論より処理系がいつできるかの方に興味がある
0684デフォルトの名無しさん2008/05/27(火) 21:57:30
規格書いてる奴らが作る訳じゃないからな
2020 ぐらいじゃね？
0685デフォルトの名無しさん2008/05/28(水) 09:04:38
だが実装可能性ぐらいは考えて欲しいんだぜ。
0686デフォルトの名無しさん2008/05/28(水) 15:41:55
もう委員会が「完全準拠のコンパイラを最初に作ったチームに賞金」でいいだろ。
商用コンパイラとかだとその賞金が売り上げを下回るっていう可能性もあるから、
MSの無償配布してるものと同じ様なライセンスでなければいけないとかいう条件をつけてさ。
そうすれば販売方法を確立できない個人でも目指す事ができるし、万が一先を越されてしまっても
その場合は販売すれば良い。
0687デフォルトの名無しさん2008/05/28(水) 15:53:55
C++03の下位互換性から考えると、exportも必須なわけか？
そんな非現実的で理想を追求した完全準拠のコンパイラは、まず実用にはならないと思われる。
0688デフォルトの名無しさん2008/05/28(水) 18:07:34
外部テンプレートなんかさっさと規格からぶち殺して
貴重な予約語exportをもっと他の有意義なことに使えるように努力すべき
0689デフォルトの名無しさん2008/05/28(水) 19:47:46
>>686
個人でやれるような範囲の話ではない
0690デフォルトの名無しさん2008/05/28(水) 20:16:07
MSがバイナリインデックスの並び順で特許取っててそこをCOMに使ってるから無理
テーブルを先頭に持ってくるんだったか程度のもの
0691デフォルトの名無しさん2008/05/28(水) 20:22:03
特許なんてそのうち切れるさ
0692デフォルトの名無しさん2008/05/28(水) 22:23:11
vtblを頭に持ってくるって話？
ABIだと思ってたが、特許なのか？
0693デフォルトの名無しさん2008/05/28(水) 23:46:26
>>684
Conceptは、Douglas Gregorが規格も処理系(ConceptGCC)も書いてるよー。
0694デフォルトの名無しさん2008/05/29(木) 00:25:18
そのGCCではあのクソ気持ち悪いラムダ式とかもコンパイルできるのかい
だったらちょっと試してみたい
0695デフォルトの名無しさん2008/05/29(木) 06:43:01
これはconcept branchだから、
他の新標準機能は入ってないよ。
http://gcc.gnu.org/projects/cxx0x.html
lambdaはgcc headで実装始まってるはず。
0696デフォルトの名無しさん2008/05/29(木) 08:49:35
>>686
2100頃までC++は生き残るわけですね分かります
0697デフォルトの名無しさん2008/05/29(木) 11:46:02
std::*Integralが、
std::*IntegralLikeになってやがる。
FloatingPointLikeってなんだよ
// Revision 1の頃から変わっていたのか
0698デフォルトの名無しさん2008/06/04(水) 13:39:48
C++0xはそろそろJavaの時のような誇大広告を始めて盛り上げるべき。
0699デフォルトの名無しさん2008/06/04(水) 13:52:25
どんだけ人集めてもmove semantics見たらみんな引くって。
大衆には見向きもせずプログラミング言語の実験室として頑張っていただきたい。
0700デフォルトの名無しさん2008/06/04(水) 14:03:10
もはや C++ 自体が大衆向けじゃないよな。
でも、必要としている一部の人間のために頑張って頂きたい。ｗ
0701デフォルトの名無しさん2008/06/04(水) 14:05:12
まずはまともな処理系を、話はそれからだ
0702デフォルトの名無しさん2008/06/04(水) 14:11:26
Move SemanticsとかVariable TemplateとかConceptとか、
ライブラリを書く奴のための機能だから、
一般ピーポーが覚える必要は無いんじゃない？

とは言ったものの、どうやって実装しているか分からないと、
俺としては、使う気にならなかったりするから微妙だ。

STLヤベー、超便利ー。
↓
イテレータとか関数オブジェクトとか分からん。勉強するか。
↓
いわゆる、STLの解説本とかではまともに説明されてねー。何コレ。
↓
テンプレート解説本なら詳しく載ってる。やっべ、スゲー詳しい。面白れー。
↓
Boostたのしー。
↓
あれ、当初の目的って何だっけ？
STL？　デザインが貧弱すぎじゃね？　あれって。
0703デフォルトの名無しさん2008/06/04(水) 16:25:03
素人の人たちに受けのいい機能も少し追加されたんじゃない。
auto とか。
0704デフォルトの名無しさん2008/06/04(水) 16:26:10
conceptだってコンパイル・エラー見やすくなるしね。
0705デフォルトの名無しさん2008/06/05(木) 04:01:49
今回は入門者のためにもなる改良がたくさんあるとどこかで聞きました
0706デフォルトの名無しさん2008/06/05(木) 14:58:46
c++であと１０年は持つのかな
すでにフォートラン化しはじめてる？
0707デフォルトの名無しさん2008/06/05(木) 16:44:53
当分、いろんな意味でC++を越える言語は出てこないだろうな。
0708デフォルトの名無しさん2008/06/05(木) 20:08:45
export イラネ
予約語から外してほしい
0709デフォルトの名無しさん2008/06/05(木) 20:23:20
export の実装って結局二度以上同じソースをコンパイルしてるだけだからな
prelink 工程というのがあってそこで全部解決するまで再帰的にコンパイルしつづける

関数がインラインにならないという効果はあるがそれ以上の利益はない気がする
0710デフォルトの名無しさん2008/06/05(木) 21:53:24
>>706
FORTRAN 77とは全然違う。
FORTRAN 77は数値計算の世界では現役のまま陳腐化した。
C++0xは現役のまま最先端を走り続け、プログラマを置き去りにし続けてる。
0711デフォルトの名無しさん2008/06/05(木) 21:55:37
置き去りかよｗ
0712デフォルトの名無しさん2008/06/05(木) 22:04:19
道を踏み誤りつつあるマッドサイエンティストみたいなもんだな
0713デフォルトの名無しさん2008/06/05(木) 22:04:26
exportは後々autoみたいに役に立つ日がくるのでほっといてやってください
0714デフォルトの名無しさん2008/06/05(木) 22:53:05
>>710
> C++0xは現役のまま最先端を走り続け
「他言語に出来ることが出来ないので悔しい」
って、入れた機能がほとんどじゃないかい？
0715デフォルトの名無しさん2008/06/05(木) 22:53:25
>710
Fortran2008は結構強烈だぞ？
0716デフォルトの名無しさん2008/06/05(木) 23:00:35
>>714
conceptはHaskellだけじゃない、似てる機能があるのは。
しかもそれは後から分かったことだし。
traitsを置き換えるために生まれた。

move semanticsだってかなり狂ってるしね。
明示的なメモリ管理がある言語で導入するとは。
0717デフォルトの名無しさん2008/06/05(木) 23:50:13
C++ はあまりお作法がない言語だったと思っていたんだが、今は作法が大杉って困る
0718デフォルトの名無しさん2008/06/06(金) 00:03:11
意味が不明瞭だ
お作法って具体的にはどういうこと？
0719デフォルトの名無しさん2008/06/06(金) 13:01:23
>>713
registerもいつか役に立つ日が来るのでしょうか?
0720デフォルトの名無しさん2008/06/06(金) 13:06:07
>>715
Fortran2008のco-Arrayなんて、
Crayの実装の後追いじゃないですか。
C++0xなんて規格が独走状態ですよ。
一緒にしないでください、失礼です。
0721デフォルトの名無しさん2008/06/06(金) 13:45:38
>>718
俺のエスパー能力を駆使すると、パラダイムをお作法と訳してるんじゃねーの。
禿げ曰く「C++はマルチパラダイム言語だ」と。
パラダイムがないつーか、ひとつに縛らない言語だがな。
パラダイムが何も無いのがすばらしいなら、ifとgotoだけでいいじゃねーかと。
0722デフォルトの名無しさん2008/06/06(金) 16:09:13
規格を崇拝するお前らに楽しい問題。

class string {
public:
　　string(const char*);
};

void f(string, string, bool = false); // 1
void f(string, bool = false); // 2

void g() {
// どちらの関数が呼ばれるか。
　　f(“Hello”, “Goodbye”);
}

俺はできなかった。
まあ、Overload Resolutionの厳密なルールを暗記してるわけじゃないし。
答え：ttp://blogs.msdn.com/vcblog/archive/2008/06/05/some-c-gotchas.aspx

これをもうちょっと人間的にするために、
なにかプログラマが優先順位を指定できるような機能はつくれないのかな。
0723デフォルトの名無しさん2008/06/06(金) 16:39:20
暗黙的に呼ばれる変換コンストラクタに依存するのはよくないってのは有名な話じゃね。
だれしも一回は引っかかる罠だけどね。
0724デフォルトの名無しさん2008/06/06(金) 17:49:35
その辺いじくるとスマートポインタが軒並みぶっ壊れるから
触れないし触らない方がいい
0725デフォルトの名無しさん2008/06/06(金) 17:52:57
つ f(string("Hello"), string("Goodbye"));

0726デフォルトの名無しさん2008/06/06(金) 18:45:45
正直ついていけてません。すみません orz
0727デフォルトの名無しさん2008/06/06(金) 19:38:40
>>719
もしかしたら、&の使用を制限する目的に使えるかもしれない。
例えば、register int foo して func(& foo) したらエラーになるとか。
で、参照渡しができるのなら、ポインタの使用を禁止できることになる。
# 意味が違いすぎるなw
0728デフォルトの名無しさん2008/06/06(金) 20:37:33
俺も最近まで register に & を付けれないと思ってたけど、
C++ では付けれるらしいよ。
0729デフォルトの名無しさん2008/06/06(金) 20:42:27
もうラムダ式のキーワードにregister使ったらいいじゃん
どうせ予約語の意味なんてメチャクチャなんだから
0730デフォルトの名無しさん2008/06/06(金) 20:42:58
何度も言うようだが inline がいいと思うお
0731デフォルトの名無しさん2008/06/06(金) 20:45:01
却下されたんだろそれ
0732デフォルトの名無しさん2008/06/06(金) 20:47:45
やっぱり解析が凶悪になるからか。
0733デフォルトの名無しさん2008/06/06(金) 22:20:43
>>731
だれか提案したの？
0734デフォルトの名無しさん2008/06/06(金) 22:45:36
ここの誰かが突撃してはいはいﾜﾛｽﾜﾛｽされた
0735デフォルトの名無しさん2008/06/06(金) 22:57:33
キチガイ度で言えば現状もどっこいどっこいだと思うだけどな。
0736デフォルトの名無しさん2008/06/06(金) 23:32:07
最初から頭の使い方が足りなくて狂ってるとしか思えないのと
考えに考えた末に発狂するのとでは筋が違うと思う。
0737デフォルトの名無しさん2008/06/06(金) 23:42:24
オーバーロードは罠が多いから・・
特に特殊化と混じったりするとわけわからん
0738デフォルトの名無しさん2008/06/06(金) 23:54:55
>>734
それどこで？
comp.std.c++ と comp.lang.c++ と流し読みしてるけど、とりあえず見覚えが無い。
0739デフォルトの名無しさん2008/06/07(土) 01:11:13
inlineも規格化前に勝手な独自拡張でｸﾁｬｸﾁｬに使われてきた経緯があるから
あまり触れたくないよな
0740デフォルトの名無しさん2008/06/07(土) 19:41:12
inlineってどうするの?

m = inline (auto x, auto y) { return x > y ? x : y; } (10, 20);

とか?
0741デフォルトの名無しさん2008/06/07(土) 20:23:44
無名関数をinlineと呼ぶのはすげえ違和感がある
0742デフォルトの名無しさん2008/06/07(土) 20:35:49
__lambdaとか_Lambdaでいいからキーワード追加してくれよ。
適当に#defineして使うからさあ
0743デフォルトの名無しさん2008/06/07(土) 21:21:55
別に _Lambda だろうが [&] だろうがいいけど
とりあえず #include <lambda> をくれ。
0744デフォルトの名無しさん2008/06/08(日) 20:07:30
C++03 の extern inline って C++0x にまだ残ってる？
0745デフォルトの名無しさん2008/06/09(月) 15:24:25
>>722
でどっちが呼ばれるの？

ふつーに考えて1でしょ？
(ブーッという音が聞こえてるようだ)
0746デフォルトの名無しさん2008/06/09(月) 15:31:18
失礼、答えつけててくれたんだね。。。
んで、pointer-to-boolなんて知らなかったので、さらに調査中。
昔はほんとにC++好きだったんだけどな。今は規格がぎしぎししてるね。
0747デフォルトの名無しさん2008/06/09(月) 18:31:18
その馬鹿げた変換を何とかするためのnullptrだが
全然何ともなってないといういつものパターンなんだろ
0748デフォルトの名無しさん2008/06/09(月) 19:25:05
もうポインタと整数
整数とbool
は互換禁止にすべきだな

やりたきゃ明示的にキャストしれと
0749デフォルトの名無しさん2008/06/09(月) 19:27:18
if(smart_ptr)が出来なくなるとブーたれる奴らが強硬に反対するので無理です
0750デフォルトの名無しさん2008/06/09(月) 20:17:32
それは暗黙的変換とは関係なくね？
0751デフォルトの名無しさん2008/06/09(月) 20:18:01
NULL と比較しろよ・・・。
ただ、if (T* p = dynamic_cast<T*>(q)) { ... } がやりたいので
無くなると困る。
0752デフォルトの名無しさん2008/06/09(月) 20:47:28
「さらば、式の中でも変数を定義できるようにして進ぜよう！」
0753デフォルトの名無しさん2008/06/09(月) 21:45:57
なんでよりカオスな方向に解決するんだよw
0754デフォルトの名無しさん2008/06/09(月) 22:27:43
オカス！？美少女中学生を！？
0755デフォルトの名無しさん2008/06/09(月) 23:42:09
>>751
は？C++でNULLなんて使うなよ。0を使え。
0756デフォルトの名無しさん2008/06/09(月) 23:48:56
これからはnullptrだろ常考
0757デフォルトの名無しさん2008/06/10(火) 00:34:52
nullptrなんて意味ないよなぁ
どうせ変数に入れたら0と区別付かないからやりたい放題なのに
0758デフォルトの名無しさん2008/06/10(火) 01:41:26
>>755
NULL をどう定義するかは処理系定義で、
整数変数に代入しようとした時に警告出してくれるように
定義してくれてるかもしれないというのに
何で 0 なんて使わないといけないのか。
0759デフォルトの名無しさん2008/06/10(火) 01:42:55
>>758
Effective C++ を100回読め
0760デフォルトの名無しさん2008/06/10(火) 01:49:27
NULLを0以外でdefineしてるC++の処理系なんてものがあったとしたら
今すぐ叩き壊した方がいいよ
0761デフォルトの名無しさん2008/06/10(火) 01:58:26
C++では、マクロを使わない事を推奨されている。なのでNULLよりも0を使う方が綺麗。
もちろん、C++はある程度「綺麗」なスタイルを提示しながらも、そうじゃないスタイルを拒絶することはしない。
better Cとして、例外を使わなかったり、templateを使わなかったり、NULLを使っても良い。
ただし、それが推奨されているわけではないことは覚えておくべき。
0762デフォルトの名無しさん2008/06/10(火) 02:08:51
>>760
g++ は __null で定義されているが・・・。
0763デフォルトの名無しさん2008/06/10(火) 02:35:32
NULL 使ってる人は毎回 cstddef あたりを #include してるのか？
0764デフォルトの名無しさん2008/06/10(火) 03:00:50
>>761
enum{NULL = 0};
0765デフォルトの名無しさん2008/06/10(火) 03:03:49
<template T>
T *NULL(){
　return 0;
}
0766デフォルトの名無しさん2008/06/10(火) 07:04:54
NULLより0ってのは、
Effective C++以前のC++ FAQの時代からの常識。
>>759
情けない…このスレに来るのは十年早いよ。
0767デフォルトの名無しさん2008/06/10(火) 07:20:10
>>763
NULL は結構色んなヘッダファイルで定義されてるので
cstddef をインクルードするまでもないことが殆ど。
0768デフォルトの名無しさん2008/06/10(火) 07:24:44
Effective C++ と C++ FAQ の説明内容に違いはあるの？お爺様
0769デフォルトの名無しさん2008/06/10(火) 07:28:50
相変わらず破綻してる言語だな
0770デフォルトの名無しさん2008/06/10(火) 07:29:45
>>765
それだとメンバへのポインタに対応できない気がする。
0771デフォルトの名無しさん2008/06/10(火) 08:42:09
定期的に低レベルの話題で荒れるな
0772デフォルトの名無しさん2008/06/10(火) 08:50:23
>>767
実際のコンパイルでエラーになるまで対応するヘッダをインクルードしないってこと？
ライブラリの実装に依存してそうでイヤじゃない？
0773デフォルトの名無しさん2008/06/10(火) 09:37:26
>>771
低レベルの質問にはよく答えられる低の高くらいのレベルの人が多いんですよ。
おいらも含めて。ｗ
0774デフォルトの名無しさん2008/06/10(火) 10:47:54
低の高っていうと
エントリーモデルの中で頭一つ出た商品みたいで所謂人気商品ってイメージ
0775デフォルトの名無しさん2008/06/10(火) 11:16:08
ある意味正しいな。
今は、プレミアム系商品の人気が高くなっている辺りも含めて。
0776デフォルトの名無しさん2008/06/10(火) 14:01:46
C--
0777デフォルトの名無しさん2008/06/10(火) 15:27:35
>>776
廃れたね。
JVMもCLRもなければ主流になったかも知れないのに。
0778デフォルトの名無しさん2008/06/10(火) 16:32:19
>>772
規格でどのヘッダがNULLを定義してるか決めてあるでしょ。
0779デフォルトの名無しさん2008/06/10(火) 17:05:26
>>772の言っているのは、
使うなら、定義されてるヘッダを必ず明示的にインクルードしないと、
コンパイル通っても、実装依存なコードだってことでしょ。
実際多いよね、そういうコードは。
実装上の都合による孫インクルードに依存しているコード。
0780デフォルトの名無しさん2008/06/10(火) 17:37:45
>>779
多いね。
うっかりやることもあるので、ちゃんと警告するシステムが欲しい。
（あるのかな？）
0781デフォルトの名無しさん2008/06/10(火) 17:43:48
NULLはプリプロセッサマクロだから使うなと言う舌の根も乾かぬうちに
#includeの話題で盛り上がってるあたりC++の病巣がよく表れている
0782デフォルトの名無しさん2008/06/10(火) 17:45:27
#include を使わずに済むしかけを入れて欲しかったな＞C++0x
0783デフォルトの名無しさん2008/06/10(火) 17:50:06
シンボルだけを読み込む機能は確かに欲しいが、
いまさらC++に入れるくらいなら俺はDを使うわ。
0784デフォルトの名無しさん2008/06/10(火) 17:52:09
標準ヘッダーファイルの拡張子を無くしたときにやるべきだったな
0785デフォルトの名無しさん2008/06/10(火) 18:46:50
>>784
標準の拡張子無しのヤツはヘッダっていうんじゃなかった？
自分で作ったらヘッダーファイルだっけね。
0786デフォルトの名無しさん2008/06/10(火) 20:53:48
ヘッダはファイルである必要は必ずしもないという実装者を挑発するルールです
0787デフォルトの名無しさん2008/06/10(火) 21:00:08
Windows使っている俺は、実際のファイル名をヘッダ名と同じにしないでくれと思っている。
具体的に言うとファイル名に拡張子ほしい。<ios>でios.hppを探しに行くような感じで。
拡張子のないファイルは扱いが面倒臭い。

関連付け以外にも、色分けなどのために拡張子で種類を判別するエディタの多いこと。
0788デフォルトの名無しさん2008/06/10(火) 21:19:21
ヘッダファイルにエディタへのヒントとして、ファイルタイプを書くか、
副次ストリームに書く。
エディタはそれを読んで判断。
0789デフォルトの名無しさん2008/06/10(火) 21:41:22
ハードリンクでも張っとけばいいんじゃない？
0790デフォルトの名無しさん2008/06/10(火) 23:15:03
副ストリームって最近冷遇されてる気がするなあ
0791デフォルトの名無しさん2008/06/10(火) 23:17:46
><ios>でios.hppを探しに行くような感じで
でも結局iosのファイルの中身は
#include <ios.hpp>
だけだったりするんだよね
0792デフォルトの名無しさん2008/06/10(火) 23:29:30
0xが正式に導入されたら、今ある入門書って買い換えなきゃいけない？
0793デフォルトの名無しさん2008/06/10(火) 23:31:43
入門レベルなら大して変わらないかと
0794デフォルトの名無しさん2008/06/10(火) 23:38:16
「対して変わらない入門書」なんてものは悪書としか言いようが無い。
C++標準化後にどれだけ旧態然とした入門書が悪影響を与えたか。
0795デフォルトの名無しさん2008/06/10(火) 23:54:23
正式導入されたとしても、
結局 VC++ が無視したら広まらないんだろうな。
C99 みたいに。
0796デフォルトの名無しさん2008/06/10(火) 23:56:17
既にTR1入れてるぐらいだし、比較的早めに0x対応するのではないかと楽観視している
0797デフォルトの名無しさん2008/06/10(火) 23:58:18
STLの書き換えがダルそうだよな
俺らは使うだけだけど
0798デフォルトの名無しさん2008/06/11(水) 00:00:01
どうせ書くのはdinkumwareだろ
MSじゃなくてさ
0799デフォルトの名無しさん2008/06/11(水) 00:00:45
まあ TR1 くらいなら特にコンパイラいじる必要もないから簡単に入れれるけど、
言語仕様に手を入れるのはどうなんだろうね。
VCEE の C++ の力の入れ具合が 2005 で微妙だったのが（デフォでは Platform SDK なし）
2008 で微妙に改善されたので（デフォで Windows SDK あり）
もしかしたらやる気があるのかもしれない。
0800デフォルトの名無しさん2008/06/11(水) 00:16:03
>>799
TR1だってispodとかコンパイラに手を入れないと無理なのもある。

ところで、もしVC++がExpressだと0x使えないって言われたら
喜んでStandard買いそうな気がしてならない。
そんときゃg++で我慢すればいいはずなのに。
0801デフォルトの名無しさん2008/06/11(水) 00:16:59
で、結局入門書は買いなおしたほうがいいんだな？
0802デフォルトの名無しさん2008/06/11(水) 00:19:50
しばらくは取って付けたような入門書ばかり出るんだろうけどね。
0803デフォルトの名無しさん2008/06/11(水) 00:20:53
入門書なんてvarとshared_ptrあたりをさわるので精一杯じゃね
0804デフォルトの名無しさん2008/06/11(水) 00:22:39
var じゃなくて auto じゃね
0805デフォルトの名無しさん2008/06/11(水) 00:23:59
autoとヌルポは絶対教えるだろ。
あとはinitializerでのコンテナ初期化と範囲forとか
0806デフォルトの名無しさん2008/06/11(水) 00:27:12
どうせ数ページ書き直しただけで「C++0x対応・全面改訂版」とかって帯付けて売るんだぜｗ
0807デフォルトの名無しさん2008/06/11(水) 00:29:05
欄外に「新しいC++の規格ではこのように書くことも出来るようになりました」って注釈つけて終わりにしたりな
0808デフォルトの名無しさん2008/06/11(水) 00:31:26
D&E 2015年版が出るなら絶対買う。
0809デフォルトの名無しさん2008/06/11(水) 00:43:26
地味だけどlong longは間違いなくとり上げられる。
0810デフォルトの名無しさん2008/06/11(水) 00:48:09
>>799
けどC++/CLI蹴られたし、ISO C++からは離れるかもね。
0811デフォルトの名無しさん2008/06/11(水) 00:53:26
>>809
型の種類と値の範囲の表をちょっと増やすだけだもんなｗ

個人的にはUTF文字列をまともに扱って欲しい
0812デフォルトの名無しさん2008/06/11(水) 18:58:03
美少女中学生にしてみれば下着の種類が増えるだけだからな
外に出るときの見た目は変わらない
0813デフォルトの名無しさん2008/06/11(水) 19:48:21
対応したコンパイラって、すぐ出るのかな？
0814デフォルトの名無しさん2008/06/11(水) 19:49:30
gccとか既に一部対応してるから、規格になることには全部対応してるんじゃね？
0815デフォルトの名無しさん2008/06/11(水) 19:53:42
ふむ。
gccぶち込んでみるかな。
0816デフォルトの名無しさん2008/06/11(水) 20:54:49
139 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/11(水) 20:50:38
どうでも良いが個人的にまつもと氏に0xに改善されても尚C++が問題外かどうかを訊ねたい。
0817デフォルトの名無しさん2008/06/11(水) 21:31:56
>>816
もっとだめと言うに100万ペリカ

ところで初心者向けと言えば、やっぱりテンプレート絡みの
エラーメッセージがまともになるという1点においてコンセプトが
一番簡単にアピールできる機能だと思う。
コンセプト自体は、入門書で取り上げられるような内容ではないだろうけど。
0818デフォルトの名無しさん2008/06/12(木) 08:16:26
禿は0xむけに第4版出すんだろうか
0819デフォルトの名無しさん2008/06/12(木) 10:28:13
第4版よりD&Eの第2版がほしい
0820デフォルトの名無しさん2008/06/12(木) 14:25:24
D&Eの続編書いて欲しいな。別の本で。
>>693のGregorとか。
一人で大幅な改訂してる暇はたぶんないだろ。
WG21 papers、かなり名前出てくてるからな。
0821デフォルトの名無しさん2008/06/12(木) 14:26:54
Wikiを読んでいると、「うざくなって？」って、思えてきたのですが、
そんなことない？
0822デフォルトの名無しさん2008/06/12(木) 14:32:27
日本語でおｋ
0823デフォルトの名無しさん2008/06/12(木) 16:20:39
美少女中学生が携帯で書き込んでいるようだな
0824デフォルトの名無しさん2008/06/12(木) 17:13:20
>>823
ぼっぼくと付き合ってくださいっ！
0825デフォルトの名無しさん2008/06/12(木) 18:01:42
>>824
文脈的には>>821が美少女中学生だと思う

TC++PLやD&Eの続編って書く予定ないのかな と思って禿のページ見に行ったら
なんかいまC++の入門書書いてるみたいだね
0826デフォルトの名無しさん2008/06/12(木) 18:30:15
VCって、どこまで対応させるのかな〜？
0827デフォルトの名無しさん2008/06/12(木) 20:21:40
>>825
おお、それは期待したい
0828デフォルトの名無しさん2008/06/12(木) 20:21:56
テンプレートだって未だにまともになってないのに
そこにコンセプトなんか追加したらどうなることやら
0829デフォルトの名無しさん2008/06/12(木) 22:22:58
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」と書き込もうとしたけどやめた。
0830デフォルトの名無しさん2008/06/12(木) 22:24:03
やめろよ
0831デフォルトの名無しさん2008/06/12(木) 22:31:25
「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」っていう書き込みを見て「やめろよ」と書き込もうとしたけどやめた。
0832デフォルトの名無しさん2008/06/12(木) 22:33:18
C++0xは美少女中学生萌え言語ですよ？
0833デフォルトの名無しさん2008/06/12(木) 22:35:17
C++0xと美少女中学生には全く関連性がありません！
両者が結びついているかのような書き込みは控えてください！迷惑です！
ここはC++0xのスレッドです！C++0xの話をしてください！
美少女中学生の話がしたければどこかよそでやってください！
0834デフォルトの名無しさん2008/06/12(木) 22:39:31
えぇーまじでぇー
0835デフォルトの名無しさん2008/06/12(木) 22:55:11
C++0xなら美少女中学生なんてコンパイル時にゲットできる
0836デフォルトの名無しさん2008/06/12(木) 22:56:41
NGワード : 少女
0837デフォルトの名無しさん2008/06/12(木) 22:57:56
>>835
コンパイルに何年かかるんだ？
0838デフォルトの名無しさん2008/06/12(木) 22:58:14
>>828
コンセプトが追加されてはじめてまともになるんじゃないか。何を言ってるんだ
0839デフォルトの名無しさん2008/06/12(木) 23:37:42
>>838
紫の上のコンパイルはたった４年です。
0840デフォルトの名無しさん2008/06/13(金) 21:31:21
>>784
拡張子をなくした理由ってなんだろ？
0841デフォルトの名無しさん2008/06/13(金) 21:32:15
>>792
いつまで入門者でいるつもりなのかなー
0842デフォルトの名無しさん2008/06/13(金) 21:38:19
>>840
ヘッダはファイルである必要は無い
とか言えるようにするため。
0843デフォルトの名無しさん2008/06/14(土) 00:34:50
.hまで含めて名前です。とかでもよかったじゃん。
0844デフォルトの名無しさん2008/06/14(土) 00:36:53
互換性を失う変更を導入するための苦肉の策だったのだと思う
0845デフォルトの名無しさん2008/06/14(土) 00:37:26
名前空間の無い時代に

#include <iostream.h>
int main() {
　cout << "hoge" << endl;
　return 0;
}

とか書かれたプログラムが大量にあってだな・・・。
それとの互換性を考えると名前を変えざるを
0846デフォルトの名無しさん2008/06/14(土) 10:06:58
ほんっとしがらみいっぱい過ぎだよな。
0847デフォルトの名無しさん2008/06/14(土) 10:11:18
互換性無視してしがらみ全部捨てたC++欲しいよな。
特に暗黙の型変換辺り。

ちなみにDなら不要だよ。
0848デフォルトの名無しさん2008/06/14(土) 10:12:46
Dは自分でしがらみ作りまくったりしてるからな・・・
時には思い切って捨てたりしてるけど（信者を）それが逆にしがらみになってる。
0849デフォルトの名無しさん2008/06/14(土) 10:25:48
>>847
仕様だけでも作ってくれ
0850デフォルトの名無しさん2008/06/14(土) 10:28:12
>>847
暗黙関係はトラブルの元だからどうにかしたいな。暗黙関係は警告を出すオプションが欲しい。
デフォルトのコピーコンストラクタが作成できませんなんて余計な警告はあるのになんでないんだ？＞ＶＣ８
0851デフォルトの名無しさん2008/06/14(土) 10:52:11
明示的なメモリ管理ができないC++とか
その場合でもmove semanticsは面白いこと出来ると思う。
0852デフォルトの名無しさん2008/06/14(土) 14:27:37
暗黙の型変換を全部禁止したらどうなるのかな
double d = 1;
とか
Base *b = new Derived();
とかが全部エラーになるんだよな
0853デフォルトの名無しさん2008/06/14(土) 14:29:42
アップキャストは安全なキャストだから禁止する必要もあるまい。
0854デフォルトの名無しさん2008/06/14(土) 14:33:28
安全だろうと何だろうと、何かの暗黙の変換を認めたら
あれも認めろこれも認めろと言うキチガイが出てくるので全て禁止です

そういう思想で作られてる言語ねえのかな
0855デフォルトの名無しさん2008/06/14(土) 14:42:53
OCaml は結構型に厳しかったと思う
0856デフォルトの名無しさん2008/06/14(土) 15:20:30
double d = 1;
は実質
double d( 1 );
と同じだから明示的な変換を表しているんじゃないか?
0857デフォルトの名無しさん2008/06/14(土) 15:22:16
暗黙的なコピーコンストラクタの実行をやめてくれって話じゃなかったのか
0858デフォルトの名無しさん2008/06/14(土) 15:29:26
explicit でおkだっしょ
0859デフォルトの名無しさん2008/06/14(土) 15:41:09
デフォルトのコピーコンストラクタはどうかなあ。
0860デフォルトの名無しさん2008/06/14(土) 15:42:31
ああ、コピーコンストラクタの話か。
0x 的には = delete してくれってことじゃないのかな。
0861デフォルトの名無しさん2008/06/14(土) 15:44:38
組み込み型の暗黙の型変換が結構うざいんだよな。
特にポインタ、文字型、論理型が整数様型と絡むと。
0862デフォルトの名無しさん2008/06/14(土) 15:46:08
explicit をデフォルトにしてほしかった。
0863デフォルトの名無しさん2008/06/14(土) 15:47:36
schemeみたいに簡単に方言作れるkitがあればいいのにな。
0864デフォルトの名無しさん2008/06/14(土) 15:55:09
>>862
それはよく思う。
でも、今更変えらんないんだろうなあ。
0865デフォルトの名無しさん2008/06/14(土) 15:57:43
Javaはreflection APIがあるから、
言語拡張＆コンパイラ実装の研究がどんどん進んでいるね。
0866デフォルトの名無しさん2008/06/14(土) 23:38:08
セックスプリプリシット？
0867デフォルトの名無しさん2008/06/15(日) 09:46:35
虚しいオッサンの虚しい書き込みが続いております
0868デフォルトの名無しさん2008/06/16(月) 13:47:36
>>865
OpenC++の中の人も今はOpenJavaやってるね。
0869デフォルトの名無しさん2008/06/17(火) 06:06:45
クラスの内部ポインタを交換するような例外安全な swap を書くとき
それを std 空間に template <> swap( .. ) と逐一定義しないと std::swap から呼ばれない。
理屈はわかるんですけど、なんとかならないですかね。
一々 namespace std { template <> swap( うんたらかんたらと書くのが面倒くさいです。
0870デフォルトの名無しさん2008/06/17(火) 06:50:04
クラステンプレートならどうにもならない
0871デフォルトの名無しさん2008/06/17(火) 12:24:39
自分の場合は using std::swap してから swap() を呼び出しているので
クラスと同じ名前空間に swap() を定義している。
0872デフォルトの名無しさん2008/06/17(火) 21:01:32
swapなんか使わない設計にしなさい
0873デフォルトの名無しさん2008/06/17(火) 21:08:06
そうですね。
これからは右辺値参照の時代ですもんね。
0874デフォルトの名無しさん2008/06/17(火) 23:41:59
swapを使おうとする前に、一度立ち止まって
自分が値をあべこべに格納していないか考え直しなさい

　　　　　　　　　　　　　　　　　Bjarne Stroustrup
0875デフォルトの名無しさん2008/06/18(水) 00:38:14
>>869
恐らくどうしようもないかと思います．
さらに， std 名前空間以外の名前空間で定義された関数テンプレート
(クラステンプレート内で定義されてた非テンプレート関数もこれに準じますが)
において， unqualified call で swap が呼ばれる場合にも対応しようとすると
クラスと同じ名前空間にも swap を定義しなければいけなくなります．

現時点において，規格として std 名前空間で定義された関数テンプレート内で
>>871 さんの提言する実装 (using std::swap;) が行われている保証が無いことが
本質的な問題だと思います．ただ，ここに文句を言っても現時点での問題は
何も解決されませんので，とりあえずの次善策として， std::swap の特殊化と
associated namespace に swap を定義することの両方を実施することを
個人的には勧めておきます．「面倒くさい」という問題の解決にまったくなっていませんが．
さらに >>870 さんの言うように，クラステンプレートの場合には
根本的な解決策はないです．

>>873
move できるかどうかは， swap できるかどうかとは本質的には独立で，
特に move が可能になるためには，オブジェクトに valid resourceless state が
存在することが必要になり，これはやや強い制限だと思いますから，
move はできないけれども swap はできるという状況は比較的容易に起こりえると思います．
なので， move さえあれば良いということは必ずしも言えないかと思います．
0876デフォルトの名無しさん2008/06/18(水) 00:51:43
concept HasSwapFunction<typename T> { T& swap(T&) throw (); }

template <typename T> requires HasSwapFunction<T>
inline void swap(T& x, T& y) throw () { x.swap(y); }

template <typename T>
inline void swap(T& x, T& y) throw () { std::swap(x, y); }

↑ こういう感じのってダメなの？よくわからんけど…
0877デフォルトの名無しさん2008/06/18(水) 01:00:17
>>876
template<HasSwapFunction T>
concept_map Swappable<T> { void swap(T &x, T &y){ x.swap(y); } }

多分，こんな感じで concept_map で差異を吸収したほうが楽なのではないかと．
0878デフォルトの名無しさん2008/06/18(水) 02:03:49
交換も、コピーコンストラクタや代入演算子と同じように扱えばシンプルになると思うんだけど
・デフォルトはクラスが定義するswapを実行する
・swapが実装されていなければ、言語側で一時オブジェクトを作り処理する
とできないのかな
実装で埋めようとして複雑になっている印象がありますが
0879デフォルトの名無しさん2008/06/18(水) 04:23:08
Namespace issue with specialized swap
http://groups.google.ca/group/comp.lang.c++.moderated/browse_thread/thread/b396fedad7dcdc81
0880デフォルトの名無しさん2008/06/18(水) 10:07:18
for文の改良ってしないの？
0881デフォルトの名無しさん2008/06/18(水) 11:18:58
foreachってC++0xになかったっけ？
0882デフォルトの名無しさん2008/06/18(水) 16:00:02
入ったよ。
for (int &entry: aContainer) { ... }

Javaのクロージャを引数に取る拡張に比べるとつまらない。>>48
C++的には最悪のセンスだと思う。
0883デフォルトの名無しさん2008/06/18(水) 17:41:05
Javaから構文パクるなんてC++も地に墜ちたもんだな
0884デフォルトの名無しさん2008/06/18(水) 17:58:22
まあでもC++にeachとかinとかのキーワードを入れるのも有り得ないだろうし、
これくらいしか書きようがないと思う。
0885デフォルトの名無しさん2008/06/18(水) 18:00:07
ところでこのループ変数は参照なの？
参照が指す先変えながらグルグル回るの？

キモッ
0886デフォルトの名無しさん2008/06/18(水) 18:21:35
別にキモくはないだろ。
従来の、for無いのスコープで参照変数を宣言してるようなもの。
0887デフォルトの名無しさん2008/06/18(水) 18:29:26
for (int &&entry: aContainer) { ... } はあり?
0888デフォルトの名無しさん2008/06/18(水) 18:55:18
ぅん・・・
08891/22008/06/18(水) 19:11:15
昔々、Sunにとある厨が居た。
彼はＣ言語の研修でポインターでつまづくような無能で、無論Ｃ＋＋など理解出来なかった。
プログラマーとしては全く使い物にならんということでネットワークエンジニアとして使われていた。当然役には立たなかったが、サーバー運びや配線や小間使いぐらいは出来た。
この世にポインターがあるから自分がそんな境遇に陥ったのだと不満を募らせた彼はポインターを憎悪し、ポインターの無い言語があればいいのに、と夢想するようになった。
彼はその夢想言語をJAVAと名付け陳腐な企画書を出したが、すべて無視された。
そんなある日、どうせ役には立たないんだからと、しつこいNetscape社の営業を追い払う仕事を任された。もちろん権限は一切なく、ただNetscape社の営業の話相手をし、すべてを断るだけの仕事だ。
彼は毎日のようにNetscape社の営業と無駄話をした。彼にとってそれは、愚痴や不平不満をこぼす絶好の機会だった。
Netscape社の営業は当然のように彼に同意した。彼の境遇に同情し、彼の才能を認め、褒め称えた。
そして誰も耳を傾けなかった夢想言語JAVAの話になるとNetscape社の営業は強い興味を持ち、ブラウザーに搭載したいと言い出した。当時のNetscape社は、動きのあるページを作る案を求めていた。
夢想言語JAVAが現実のものになる。彼は天にも昇る気持ちになり、全面的に協力を申し出た。が、やはり何の役にも立たなかった。すべての設計、策定、実装はNetscape社によって行われた。
Netscape社は、夢想言語JAVAを「何処でも全く同じに動く言語」としてブラウザーに搭載しようとしたのだ。
これを聞いて驚いたのはSunの役員達だ。直ちにNetscape社と交渉し、JAVAはそもそもSunのものであることを主張し始めた。
交渉の結果夢想言語JAVAの最初の実装はJavaScriptと改名することになり、SunのJAVAとは独立したNetscape社の言語となった。
08901/22008/06/18(水) 19:11:45
Sunは直ちに「何処でも全く同じに動く言語」の現実性を調査し、仮想マシンを使うことで可能であることを検証した。
また夢想言語JAVAの詳細を厨に尋ね、規格をまとめ……ようとした。というのは、厨の頭の中には「ポインターを使わない」の他には支離滅裂な妄想以外何も無かったからだ。
役に立たない彼を「夢想言語JAVAを広める為の広報」に追い出し、夢想言語JAVAではなく現実的なJAVA言語の設計が行われた。
だが現実的設計にはいろいろと難があった。その度に開発部は厨に尋ね、その意向を可能な限り反映する努力を行った。しかし無能な厨の意向を反映することは困難を極めた。
その中で最も大きな障害となったのが、多重継承の禁止である。
未だにSunは公式に認めていないが、JAVAが多重継承を禁止する決断をさせたのは、実はMicrosoftの寄与するところが大きかった。
Microsoftは既にMFCとCOMによって多重継承が抱える問題を解決していたからである。
その後も厨は（何度出入り禁止を喰らっても）設計に口を出し、そして開発部はその意向を可能な限り反映する努力を行ない続けた。
特に厨が主張するコーディング規約は支離滅裂を極め、ゴスリンは「それまでに書かれたコードを書き直す量が最も少なくなるコーディング規約」をまとめる必要に迫られた。
この時にまとめられた何の意味も無いコーディング規約は後に、それを知らなかった企画部によって改めてまとめられJAVAの標準のコーディング規約として発表された。
ゴスリンはこの時の心境を「JAVAが最高だと生涯言い張り続ける覚悟を決めた」と述懐している。
厨は熱心に広報活動を行っていたが、役に立ったのは最初だけだった。すごい言語が出来る、ということを印象付けた後は、何の役にも立たなかった。
開発には近寄ることすら許されず、広報からは役立たずの烙印を押された。彼は再びネットワークエンジニアとして保守管理部に戻った。
今では彼は毎日何百ものＬＥＤを見張って、消えたらそれに対応するハードディスクドライブを交換する仕事をしていると言われている。名前は記録されていない。
0891デフォルトの名無しさん2008/06/18(水) 19:12:40
ついに参照の指し変えが認められてしまったのか…
0892デフォルトの名無しさん2008/06/18(水) 20:18:37
>>875
valid resourceless state てなーに？
0893デフォルトの名無しさん2008/06/18(水) 22:24:14
Java の参照型はまさにポインタだろうが・・・。
0894デフォルトの名無しさん2008/06/18(水) 22:26:03
NullPointerExceptionがあるしな
0895デフォルトの名無しさん2008/06/18(水) 22:26:50
Javaの参照型はインクリメントできる？
0896デフォルトの名無しさん2008/06/18(水) 22:28:34
>>893-895
ネタにマジレスｗ
0897デフォルトの名無しさん2008/06/18(水) 22:29:56
マジレスもできない奴は板を替えたほうがいい
0898デフォルトの名無しさん2008/06/18(水) 22:30:34
ネタにマジレスするのが最近のトレンドなんだぜ
0899デフォルトの名無しさん2008/06/18(水) 22:37:47
ネタに、というよりホラにマジレスだな
0900デフォルトの名無しさん2008/06/18(水) 22:38:24
>>892
d = std::move(s);
という構文が実行された直後の s の状態が明確に定義されていなければならないですが，
この状態は有効な状態でなければならず，かつ，
いかなるリソースの所有権も保持していないような状態でなければならないです．
これを valid resourceless state と表現していました．

有効な状態 (valid) でなければならないというのは，
move された直後の s に対しての操作が
well-defined でなければならないという要請を表現したものです．
少なくとも最低限かつ自明の要求として，いかなるタイミングでも
デストラクタの発動は有効に機能しなければならない，という意味で
有効な状態でなければならないことは分かるかと思います．

また， move は no-fail，つまり失敗しない操作であることが要求されます．
ここで仮に move 直後の s が何らかのリソースの所有権を保持した状態であるとすると
s が保持するリソースの確保において失敗が発生する可能性があり，
move が no-fail であるという要求と矛盾します．
従って， s はいかなるリソースの所有権も保持していない状態
(resourceless) である必要が出てきます．

一般に，オブジェクトが常に何らかのリソースを確保している状態であることが自然な場合，
このようなオブジェクトに move の操作が行えることを要求すると，
オブジェクトの構築は完了しているがリソースの確保が完了していない
オブジェクトの状態を有効な状態としてユーザに暴露しなければならなくなり，
RAII の観点から見てやや大きな弱点を生じるように思います．
0901デフォルトの名無しさん2008/06/19(木) 00:18:58
長い
3行でまとめろ
0902デフォルトの名無しさん2008/06/19(木) 00:36:13
>>891
forの繰り返しの度に初期化が行われているとみるべきでは？
例えが悪いかもしれないけど、今だってBOOST_FOREACHでは要素を受ける変数の型に参照が使える。
0903デフォルトの名無しさん2008/06/19(木) 00:53:39
ホラも技術レベルが低いのはつまらない。
0904デフォルトの名無しさん2008/06/19(木) 01:53:07
>>900
右辺値オブジェクトからの move を保証するために決めたって感じだな。
RAII については、どうせ unique_ptr や shared_ptr その他スマポ使うこと
になるからあんまり問題にならないんじゃない？

そもそもグローバルヒープが制限されてるウチみたいな環境じゃ、
あまり MoveSemantics の恩恵にあずかれなそうだが。
あーでも ScopedAllocator 使えればちっとは便利になるんかな...
0905デフォルトの名無しさん2008/06/19(木) 07:55:32
別にムーブするのが記憶領域と限られてるわけじゃないんだから、
環境はあんまり関係ないんじゃないの。
0906デフォルトの名無しさん2008/06/19(木) 12:44:12
くだらんが馬鹿にウケるホラははびこるからたちがわるい。
0907デフォルトの名無しさん2008/06/19(木) 14:34:09
まだ889, 890の話してんのか
0908デフォルトの名無しさん2008/06/19(木) 20:14:51
>>894
>NullPo・・・
0909デフォルトの名無しさん2008/06/19(木) 21:08:56
なんでNullReferenceExceptionにしなかったんだろうな
0910デフォルトの名無しさん2008/06/19(木) 21:11:19
>>908
ガッ
0911デフォルトの名無しさん2008/06/20(金) 00:04:06
std::basic_stringが異常に使いにくい点
std::exceptionがstringしか使えない点
はどうなるの？
0912デフォルトの名無しさん2008/06/20(金) 01:57:11
>>911
> std::basic_stringが異常に使いにくい点
何の話？

> std::exceptionがstringしか使えない点
what() のことなら、変わらない。
UTF-8 なりシステムデフォルトなりにエンコーディングを決めて詰め込むのが正解。
0913デフォルトの名無しさん2008/06/20(金) 03:20:43
whatはエラー表示部でgettextするのがいいと思う
0914デフォルトの名無しさん2008/06/20(金) 07:41:28
文字コードの話じゃないと思う。
std::exception::what は wchar_t 文字列をキャストして返してもいいという仕様だし。

メモリ確保が問題だと思う。
0915デフォルトの名無しさん2008/06/20(金) 09:32:45
>>914
> std::exception::what は wchar_t 文字列をキャストして返してもいいという仕様だし。

wchar_t 文字列に変換できるマルチバイト char 文字列、とか、そんな感じだったはず。
ここでいう変換はキャストじゃないと思う。
0916デフォルトの名無しさん2008/06/20(金) 13:09:48
what はおまけ情報だし、受け取る側の文化も分からないから C の最小文字セットで十分じゃない。
0917デフォルトの名無しさん2008/06/20(金) 13:40:10
たんに記号をつぶせば1バイトに文字が収まってしまう、貧弱な文字文化の人間が標準化委員会を占めていて、
国際化ということにまったく関心が無く、
「はぁ？　一文字は一バイトに決まってんだろ。野蛮な絵文字を使うアジアのイエロー達など知ったことか」
という意見が大多数を占めたために、こんな仕様になったんだろ。


まあ、実際のところは、当時はまだUnicodeなんて、
規格に入れるほど発達していなかったんだろうが。
0918デフォルトの名無しさん2008/06/20(金) 13:41:31
年中反対ばっかりの野党議員みたいな情けないレスですね。
0919デフォルトの名無しさん2008/06/20(金) 14:08:05
がっかりしました。
0920デフォルトの名無しさん2008/06/20(金) 14:11:08
C++の例外は投げるほうからは受け取る側の情報はほとんど知らないから
exception はなるべくシンプルなほうがいいんだよ。

それより fstream のファイル名は wchar_t にも対応してほしい。
0921デフォルトの名無しさん2008/06/20(金) 14:20:58
iostream関係は窓から放り投げて新しく作り直すべき。
まずロケールを廃止するところから。
0922デフォルトの名無しさん2008/06/20(金) 14:36:37
C++0xが出たら当面はchar16_tとchar32_tの仕様強化を図ってほしいな。
0923デフォルトの名無しさん2008/06/20(金) 15:10:16
>>921
localeとiostreamの関係は悪くないと思います。
0924デフォルトの名無しさん2008/06/20(金) 15:57:40
VC がまともに C++ ロケールに対応できていないのは C 言語のロケールとの関係かな。
0925デフォルトの名無しさん2008/06/20(金) 16:03:33
Windowsのモデルと合わないからでしょう。
POSIX/UNIXの方は、プラットフォームのデフォールト設定と、
プログラムの実行環境の設定が合致している必要がありませんが、
初期のWindowsのAPIの方は、合致している必要があったので、
より柔軟性の高いPOSIX localeモデルと組み合わせにくかったのでしょう。
C++はさらに柔軟性が高くなっていますから。(streamごと)
0926デフォルトの名無しさん2008/06/20(金) 17:27:44
C++の標準文字列のデザインの悪さの一例。
・大量の文字劣苦ラスがライブラリ毎に量産されている点。


Boost含めてC++のライブラリの最大の欠点って
使い方が難しく直感的でない故に毎回、ドキュメントを参照せねば使えないことが多い。
タイプ量が多く、本質的シンプルさを追求せずに
いたずらに複雑さを選択し、使い勝手を軽視している。

このようなものが次世代で生き残っていけるとは思えない。
0927デフォルトの名無しさん2008/06/20(金) 18:32:35
落伍者は皆そう言って去っていったよ
君も元気でね
0928デフォルトの名無しさん2008/06/20(金) 18:37:23
まあでもbasic_stringが糞なのはガチ。
かと言っても悲しいかな、今更どうしようもできない。
0929デフォルトの名無しさん2008/06/20(金) 19:41:35
ArrayIndexOutOfBoundsExceptionなんて名前を平気で使ってる奴らが
タイプ量に文句付けるとかあんまり笑わせんな
0930デフォルトの名無しさん2008/06/20(金) 20:00:43
>>928
せめて CString::GetBuffer 相当の関数が欲しいよね。
0931デフォルトの名無しさん2008/06/20(金) 20:01:38
関数、じゃないや。機能、だ。
別に basic_string のメンバ関数にする必要は無くて
むしろ RAII なクラスを提供してくれる方がいい。
0932デフォルトの名無しさん2008/06/20(金) 20:01:56
CStringはCStringでひっでえけどな
結局C++でまともな文字列クラスなんて作れないんだよ
0933デフォルトの名無しさん2008/06/20(金) 20:09:51
そして結局char*が一番便利だということに気付くのでした
0934デフォルトの名無しさん2008/06/20(金) 20:24:29
printfの便利さに触れると
<<なんてアホらしくて使ってられませんよねー
0935デフォルトの名無しさん2008/06/20(金) 20:25:41
>>933
ただし、それはない。
0936デフォルトの名無しさん2008/06/20(金) 20:26:54
ストリームに対して演算子を定義すれば
いくらでも新しい型を入出力に組み込めるんだから
<< >> の方が便利だろうが
0937デフォルトの名無しさん2008/06/20(金) 20:31:11
でもさ、もしprintfの%を自分で再定義して同じことが出来たらもっと便利じゃね？

可変長テンプレートかなんか使ってprintfがもっと便利になって復活してくれたら
一生C++に付いて行くけど禿のことだから絶対ねえよなー
0938デフォルトの名無しさん2008/06/20(金) 20:34:31
boostになかったっけ
0939デフォルトの名無しさん2008/06/20(金) 21:15:40
>>934
俺も、昔は無理矢理iostream系使ってたけど、今はCスタイルがメインだ。
0940デフォルトの名無しさん2008/06/20(金) 21:21:12
>>938
boost::formatのことかな

可変長引数を使いたくない とか
クラス型のオブジェクトも扱えるようにしたい とか
仮想関数を強制したくない とか
いう
理由があったんじゃないかと妄想を膨らましてみた時期が俺にもありました
0941デフォルトの名無しさん2008/06/20(金) 21:38:20
C++0x で string の連続性も保証されることだし、
GetBuffer 代わりに str.resize(size + 1); して、
char* p = &str[0]; に文字列を書き込んで
ReleaseBuffer 代わりに str.resize(strlen(&str[0])); してもいいのか？
0942デフォルトの名無しさん2008/06/20(金) 21:48:48
文字列クラスはメンバが中途半端な機能のしか無い割りにいっぱいあるんだよな
0943デフォルトの名無しさん2008/06/20(金) 21:54:11
>>941 を作ってみた。
#include <iostream>
#include <string>

template < typename Char, typename Traits = std::char_traits<Char> >
　　class basic_bare_string
{
public:
　　typedef std::basic_string<Char, Traits> string;
　　basic_bare_string(string& str, typename string::size_type size) : m_str(str) { m_str.resize(size + 1); }
　　~basic_bare_string() { m_str[m_str.length() - 1] = '\0'; m_str.resize(Traits::length(&m_str[0])); }
　　operator Char*() { return &m_str[0]; }
　　typename string::size_type size() const { return m_str.length(); }

private:
　　basic_bare_string(const basic_bare_string&);
　　basic_bare_string& operator=(const basic_bare_string&);
　　std::string& m_str;
};
typedef basic_bare_string<char> bare_string;
typedef basic_bare_string<wchar_t> bare_wstring;

int main(){
　　std::string str;
　　try {
　　　　bare_string bare(str, 4);
　　　　strncpy(bare, "foobar", bare.size());
　　} catch (const std::bad_alloc&) {
　　}
　　std::cout << str << std::endl;
　　std::cout << str.length() << std::endl;
}
0944デフォルトの名無しさん2008/06/20(金) 21:57:32
+1 って要らないのかな。GetBuffer 的に考えて。
0945デフォルトの名無しさん2008/06/20(金) 22:39:20
C++0x は std::basic_string s に対して s.data() より &s[0] の方がいいの?
0946デフォルトの名無しさん2008/06/20(金) 22:50:28
s.data() は const char * 返すから
const_cast するのは気持ち悪いし。
0947デフォルトの名無しさん2008/06/20(金) 23:52:39
.NETのStringって
非変更型の関数しかないけど
なんか理由あるの？
0948デフォルトの名無しさん2008/06/21(土) 00:05:17
>>947
immutableだから。
0949デフォルトの名無しさん2008/06/21(土) 00:06:03
immutableの方が何かと都合がいいから
0950デフォルトの名無しさん2008/06/21(土) 00:15:24
C++でいうと

boost::shared_ptr<string>でしか使えないわけだから
何かの拍子に書き換えられるとヤバイのかな。

stringでコピーして共有するか選ばなきゃいけないわけだ。
0951デフォルトの名無しさん2008/06/21(土) 01:00:08
効率より安全性を採用したわけね。
0952デフォルトの名無しさん2008/06/21(土) 01:19:26
いやむしろ効率を重視してる。
immutableなコンテナはmutableにするための仕組みが不要だから高速化できる。
.Netのimmutable containerがそうだと断言はできないが、少なくともCocoaのFoundationはそう。
0953デフォルトの名無しさん2008/06/21(土) 01:26:43
.NETはJIT前提だからね。immutableであることが判ってると、実行時にもいろんな最適化ができる。
0954デフォルトの名無しさん2008/06/21(土) 01:28:38
ちょっとした処理が効率化されても
コピーが発生するのは致命的じゃないか？
メモリ確保も発生する訳で。
0955デフォルトの名無しさん2008/06/21(土) 01:33:47
>>954
使いどころによる。mutableでも変更したら結局コピーやメモリ確保が発生する。
immutable containerの生成時は（それが他のコンテナに基づくものなら）内部データの参照カウンタを増やすだけかもしれない。
0956デフォルトの名無しさん2008/06/21(土) 01:40:04
>>954
.NETでは頻繁に書き換える場合はStringBuilderというものを使う
0957デフォルトの名無しさん2008/06/21(土) 01:43:01
boost::shared_ptr<string const> で immutable な string のできあがり？
0958デフォルトの名無しさん2008/06/21(土) 01:45:24
なるほど。
使い分けてんのね。
0959デフォルトの名無しさん2008/06/21(土) 10:10:53
D言語も2.0からimmutableになってたような
0960デフォルトの名無しさん2008/06/21(土) 13:33:27
Dはinvariantとconstとmutableを使い分けられる変態言語
0961デフォルトの名無しさん2008/06/21(土) 14:42:03
invariantって長いよね
0962デフォルトの名無しさん2008/06/22(日) 14:48:03
言語にプログラムの解析を補助する機能を追加してくれないかな。
ドキュメント生成やリファクタリングのツールが作りやすくなるように。
0963デフォルトの名無しさん2008/06/22(日) 15:06:18
んで.NETみたいに難読化ツールが必要になる、と。
0964デフォルトの名無しさん2008/06/22(日) 15:10:05
コンパイルタイムリフレクションもほしい
0965デフォルトの名無しさん2008/06/22(日) 15:12:54
>>962
テキストマクロを廃止するのが第一歩だろうな…
0966デフォルトの名無しさん2008/06/22(日) 19:42:57
>>965
Javaみたいに味気ない言語になっちゃうなｗ
まぁ現状が残念なのは間違いないところだが
0967デフォルトの名無しさん2008/06/22(日) 19:55:35
テキストマクロのかわりに文字列によるmixinを

それなんてD言語ってかんじだけど
0968デフォルトの名無しさん2008/06/23(月) 09:21:04
D言語で導入予定のAST macroなんてどうだろう
09699682008/06/23(月) 09:23:39
これのP45〜ね。
http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf
0970デフォルトの名無しさん2008/06/23(月) 10:06:47
パターンマッチのドメインもはっきりしないしダサイです。
Dは全般的にセンスがダサイ。
0971デフォルトの名無しさん2008/06/23(月) 11:17:19
Windowsライブラリなど各種ライブラリが充実していなければD言語なんて
使わない．しょせん，modula2のようにいつのまにか忘れ去られてしまう言語．
0972デフォルトの名無しさん2008/06/23(月) 11:34:10
Dはコンパイラオタクが興味の赴くままに作ってる言語だから、
ライブラリにはまったく関心が払われてないな…
0973デフォルトの名無しさん2008/06/23(月) 12:06:17
展開後に再度名前解決をやり直すんじゃなければ、
inline関数と違うのはパターンマッチだけじゃん。
そのパターンマッチもtemplate並なんじゃ、
全体の機能はtemplateよりもずっと貧弱。
よくこんな思いつきを付け足す気になるな。
0974デフォルトの名無しさん2008/06/23(月) 13:15:26
concept_mapってコンセプトの特殊化だと考えれば、
concept_mapってキーワードは要らないんじゃないのかな?
コンセプトインスタンスごとに定義すればいいんだから。
0975デフォルトの名無しさん2008/06/23(月) 13:17:37
引数評価はどうなってるんだ、Dのマクロ?
Lisp系言語のマクロの場合, 引数評価をコントロール可能なんで
マクロの意味があるんだが…
0976デフォルトの名無しさん2008/06/23(月) 18:32:39
>>973
スライドでは、シンボルに$をつけると展開後に名前解決をする、と書いてあるようだが。
0977デフォルトの名無しさん2008/06/23(月) 18:43:10
マクロが定義されたスコープと、マクロが実際に使用されたスコープの
二つだけ使い分けられればいいんじゃないの？ようわからん
0978デフォルトの名無しさん2008/06/24(火) 10:25:20
ばーさんC++0xはまだいかな
待ってるうちにおら寿命が先に来ちまうでよ
0979デフォルトの名無しさん2008/06/24(火) 23:25:05
>>974
もうちょっと想定している文法などを含めてｋｗｓｋ
0980デフォルトの名無しさん2008/06/24(火) 23:51:18
要するに、
concept ForwardIterator<typename T> {
// なんだかんだ
};
concept ForwardIterater<int> { // concept_mapじゃなくて
// どうしたこうした
}
で十分じゃないかということ。templateがそうだもの。
0981デフォルトの名無しさん2008/06/25(水) 09:25:29
>>962
VSに付いてる。
0982デフォルトの名無しさん2008/06/25(水) 16:51:28
埋めようか++0x
0983デフォルトの名無しさん2008/06/25(水) 16:52:47
まだあわてる様な時期じゃないさ
0984デフォルトの名無しさん2008/06/25(水) 17:02:25
美少女中学生はうろたえないッ！
0985デフォルトの名無しさん2008/06/25(水) 20:37:26
980越えたらいつ落ちるか分かんないよ
0986デフォルトの名無しさん2008/06/25(水) 20:57:35
C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

があるから、これでいいんじゃね?
0987デフォルトの名無しさん2008/06/25(水) 21:11:06
重複あったんなら再利用でいいな
0988デフォルトの名無しさん2008/06/25(水) 22:13:13
いや、そこはダメだろw
0989デフォルトの名無しさん2008/06/25(水) 22:44:58
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
0990デフォルトの名無しさん2008/06/25(水) 22:48:27
素マン間違えた
0991デフォルトの名無しさん2008/06/25(水) 22:56:53
誰も立てないなら>>986再利用でいいよ
0992デフォルトの名無しさん2008/06/26(木) 00:25:47
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
0993デフォルトの名無しさん2008/06/26(木) 10:43:04
よし、埋めようか
0994デフォルトの名無しさん2008/06/26(木) 11:16:18
そんなにあせらなくても
0995デフォルトの名無しさん2008/06/26(木) 11:39:55
C++ に reflection は不要だな
0996デフォルトの名無しさん2008/06/26(木) 11:53:12
コンパイル時のみテンプレートで、ならありうるんじゃないか?
0997デフォルトの名無しさん2008/06/26(木) 12:02:51
それのどこがおいしいというのか?
0998デフォルトの名無しさん2008/06/26(木) 12:16:08
>>995
実行時リフレクションはなくてもいいけど、
Dにあるみたいなコンパイルタイムリフレクションはほしい
0999デフォルトの名無しさん2008/06/26(木) 12:25:47
コンパイル時リフレクションは非常にほしい
1000デフォルトの名無しさん2008/06/26(木) 13:20:23
>>997
その発想は「ほげ言語のパラドックス」ですな。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。