C++0x 3

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/

>>1 乙++0x

>>1乙
by bjarne stroustrup

いちおつ
ばいびょーんすっぽすっぽ

>>1乙禿

うちの会社には３３歳の美少女がいる
ときどき小学生と間違われている
でも処女じゃない

>>1
wikiとwikipediaは違うぞw

MAILING 2008/02
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/#mailing2008-02

int otu(int x) { return x >>1; }

C++09/CLI とかヤル気あるんだろうか，マイクロソフト．
個人的には今の C++/CLI は好きだ．

spaced keywordとか馬鹿なことやっているところが、
標準準拠を重く見ているわけがないと思う。

spaced keyword 自体は標準で作る予定はないから、独自拡張で存在する分には
標準準拠の邪魔にはならないでしょ？

で，GCは入るのか入らないのか．
それによって俺の人生が・・・・






もう終わってるけど

今回は入らないはず。
けどベームさんが積極的にやってるから、
実装は今使える以上のものが出てくるんじゃないかな。

なんだよぉ，言語使用には入らないのか．
残念だな．まぁいいか．

>>12
イキロ

GC使いたいと思ったことがないのでよくわからん

boostのsharedポインターと比べて、GCって重いの？

あれって「ベーム」って読むのか……

>>17
ケースバイケース

ぼえへむヽ(´ー｀)ノぼえへむ

GC はあまり言語仕様に入れて欲しくはない。
標準ライブラリにあるのは別に構わんが。

C/C++ は色んな環境に使えることが肝なんだろうし、
そういうのは強制するもんじゃなくて
選択肢としてはありますが強制ではないですよってものであってほしい。

強制するしないと、言語側かライブラリ側かは別の問題だよ。
個人的には「強制しない」「言語側」を支持する。

gcnew みたいなやつか。
まさに C++/CLI だけど、あの珍妙な文法を見ると・・・。

C++/CLIは考え方としては悪くないと思う。でも確かに文法設計のセンスは悪い。

Foo<Hoge^>^
　　　　　　↑笑うなよ！

今や Unicode が普通なんだから、もうちょっとマシな文字を使えよ、ってかｗ

なんなんだろうな、あれは。
C++界隈で相当に有名な人が設計していて、
目指す方向は悪くないのに。
やっぱり言語設計は別物なんだな。

>>22
俺も言語側に何かないと今出てる以上のものは難しいと思う。
けど最低限のもので、汎用に使える聞こうにして欲しい。
まあ禿がいる限りそう言うものしか出てこないだろうけども。

Pascalの時代は、^を↑と表示するシステムがあったらしいが…

>>26
Foo<Hoge※>※

Foo<Hoge/>/

Foo<Hoge\>\
Foo<Hoge@>@
Foo<Hoge!>!
Foo<Hoge*>*

* に対応する記号としてはやはり / だな・・・。
積つながりの & は既にアドレスや参照で使われてるし。

Foo<Hoge/>/
ちょっとXMLっぽいｗ

>>26
m17n界隈にはcharacter set independenceとかISO 2022に執着してる
アンチUnicodeの人がまだ生きてるし、変換表地獄でリアルに困ってる人もいるから、
EBCDICを気にしなくていい環境でもASCIIの範囲をはみ出すのはやめた方がいい。
特にメタ文字に使うような記号類は化けやすいし文字幅問題も出てくるから。

女子中学生の話題でもちきりですね

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

こんせぷとまっぷはﾏﾀﾞｰ？

Right angle brackets N1757 Yes
うおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお

ケータイからだとさっぱりわからん
詳しく

携帯からでも読んでワカラン奴は必要ないということ。

右辺値参照 N2118 Yes
*thisの右辺値参照 N2439 No
可変個引数テンプレート N2242 Yes
静的アサーション N1720 Yes
式に対するdecltype N2343 Yes
山括弧閉じの件 N1757 Yes
テンプレート関数のデフォルトテンプレート引数 DR226 Yes
Extern templates N1987 Yes

DR226ｷﾀｰ!

>>38
ｋｔｋｒ

結局、Proposed resolution (revised October 2002)でアクセプトされたのかな。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226
draft読まないとな。ディフォルト引数便利だし。

>>6
相手は誰だ…
うらやましすぐる

ローアングルブラジャー！？(;ﾟДﾟ)ポロリもあるよ！！

最後の書き込みがブラジャーだと哀れなので保守

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) { ...

ラムダ式はN2550でだいたい決まりかな
<> が [] になって、中にキャプチャ変数並べられるようにしたと
return は省略できないぽい？

おまえら最新ドラフト来てるなら知らせてくださいよ

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

しかしラムダを導入するために新しいキーワードを入れる気はサラサラないんだな

識別子に利用できるトークン列を割り当てると、
下方互換性がなくなるからね。
あまり奇怪な記号列も困るけどラムダ式は俺的にギリギリセーフ。

あとconceptのexportは取り下げられたねw

コンセプトのexport？
まさかテンプレートのexportと同じように、
別の翻訳単位のコンセプトを参照する機能？
そんなのあったんだ。そりゃはいらないだろうなぁ

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

俺も素直にキーワード導入した方がいいと思う。
検索のやりやすさが全然違う。

N2550を読んだのだけれど、lambda-parameter-declarationって、
もしかして省略できる？
つまり、

[](){}() ;

と同じ意味で

[]{}() ;

は可能？

しかし、邪悪なコードだ。

ラムダ用に新しい記号を導入してくれれば・・・

そんなに互換性を気にするならひらがなでも使えばいい。
std::for_each(v.begin(), v.end(), ら(int x) {std::cout << x;});

λでいいじゃん。

λ.....ﾄﾎﾞﾄﾎﾞ

#define lambda []
#define closure(captures) [captures]
こんなんほしいかもな。

>>55
文法のところにはっきり opt と書いてあるだろ。

$ 使おうぜ

盲点なような気がするが、\ を使えばいい気がする。

よくない

inlineとか使えそうだけどな

int n = 10;
auto x10 = inline [n] (int a) { return a * n; }

inline ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!

そこでvolatileですよ

export でどうだ

extern だな。

inline は正直結構イケるんじゃないかと思った。

#define Lambda

書いても書かなくてもいいタイプのマクロは害悪にしかならない。
構文に影響を与えるタイプのマクロも混乱を招くしかない。
しかし元の文法からして微妙。
どうすればいいんだ。

おまえらもうあきらめろｗ
100回くらい使ってれば慣れるよきっと

自分はいいんだ。問題は一見さんとかに説明するとき。

「100回くらい使ってれば慣れる」って説明すれば良いのでは？ｗ

decltype(x) lambda(x) { return x; }

美少女中学生にバイブをプレゼントした時みたいな反応だな

最初の抵抗感から最終的な快感への淫靡なプロセスをたどるわけだ

いや、その形状がドン引きするような感じだって話なのではw

というか美少女中学生にバイブにしろ何にしろ何かをプレゼントする機会なんてあるのかよ。

あるか、ないか、ではなく、つくるんだよ。迷惑だろうけど。ｗ

プレゼントではなくセクハラです。

何イッとるんだこのスレは

女子中学生にラムダを教えるにはどうすればいいのか検討するスレです

女子中学生にランダバを教えたい

ランバダのことか。

>>83-84ﾌｲﾀ

しかしあのラムダの構文は邪悪すぎると思うのだが ...
旧キャスト並に邪悪だ。

何が邪悪ですか?
旧キャストとはCスタイルのキャストのこと?
だとして、構文が邪悪?

おい誰か lambda introducer に inline 強制しろって提案出してくれよ。
こういうときに、えぴなんとか通せばいいの？

本来その手の提案とか defect report とかは comp.std.c++ が窓口なんだけど、
今年に入ってからトラブってるらしいんだよなあ。他の人はどうしてんだろ。

とりあえず proposal のところに書いてあるメルアドに投げとけばよいような？

いや、やっぱ [&] (const employee& e) {e.salary()=...}
とかいう構文は邪悪でしょう...

だから、どう邪悪なのか説明してくれんと頭の悪い漏れには判らん

個人的には一つのまとまりとして見づらい構文はやめて欲しいなぁ。

キーワードがあるほうが単純に検索できて良いと思うな。
そういう意味ではCスタイルキャストのいやらしさと似てる。

そんなに検索したいなら/*lambda*/[〜とでも書けばいいだろ

美少女中学生のグンゼのおばんつにおかんがマジックで名前を書いている状態か！

for も if も検索しにくいけどね

lambdaが検索し易くなければならない理由も判らなければ、
検索しにくい事がどう邪悪なのかも判らん
もっと判り易く説明してくれ

関数適用だって検索しにくいしなあ
関数適用が検索し易くなければならない理由もないけど

>>97-99
なんか必死だなあｗ
どちらかといえば探せたほうがいいかな、という程度の話なんだけどね。
関数の先頭とかも検索しにくいわけだから、構わんといえば構わんか。
あとは美観の問題だね。

>100
その程度の話なら別にいいんだけど,
邪悪だなんて穏やかでない言い方してるから
なんか構文的に問題があるなら教えてくれ、ってだけなんだけど

ここで言ってる邪悪というのは美観の問題じゃないかな。
構文の問題とかはさすがにないんだろ、偉い人が考えたんだから。ｗ

いや、どう考えても邪悪な類のコードだろ

goto は何にでも使えるから邪悪なように、
使い回すにしてもどれを使い回すか結構考えないと、
goto と同じくらい邪悪になってしまう。

ラムダ式の何がどう邪悪なのかもうちょっとｋｗｓｋ

レベルの低い奴は無視しろ

おっぱいの標高が低い美少女中学生ならみっちりねっとりお相手をお願いしたい

括弧が続いて読みづらい

コンビネーションですむのにそうしないところがラムダ式の存在の邪悪さ

それを言うならコンビネータじゃなかろか？

何か勘違いしてるんじゃないか？
コンビネータもλ式の一種だぞ。

単に [&] という三文字の並びがキモイ

俺は >>112 だな。難しいことはよくわからん。ｗ

キモいよな。

エディタのマクロで保存時にλを[&]に変換すれば桶

白スクを着てひざを抱えつつこっちを見てにっこりしている美少女中学生にしか見えない

ついにC++も AA 言語になってしまうのだなあ

新しい刺激に慣れるのに時間が掛かるタイプの人がいるのですね

いじりまわせばくせになる！！！！！！！！！！！！！！！！！！！！！！！！！

Perl とかいつまで経ってもキモいし。

美少女中学生のアレはキモくないぞ

同じシンボルでも$とか@とか[]とかの付けかたで参照する変数が違うからなー

つける下着で印象が変わるわけだな

今<>のパース失敗してるみたいに
[&]とoperator[]が絡んでおかしなことにならねえかな

"λ" が使えない処理系ではtrigraphとして "[&]" で代用しても良いというのなら許す

autoでもわかるように、どうあっても予約語増やす気は無いんだろう

おまえらはもうboostのラムダつかってなさい

__TheLambdaExpressionKeywordOfC++0xとか絶対かぶらないようなキーワードにすればいいのに

_Lambda をキーワードとして採用し、
#define lambda _Lambda を行うヘッダファイル lambda を用意すればいい。

美少女中学生の全裸ランバダ

>>129
それなんて _Bool ?

美少女中学生と lambda がいい具合に入り乱れててワロタw

ここまで来ると lisp 系言語の () の方が可愛く見えるな > lambda

この先も予約語増やさずに変な記号の組み合わせや予約語の転用でどんどん機能増やしていくんだろうか
C++2xくらいでは酷いことになってそうだ

オペレーター定義可能なHaskellに比べたら

C++の将来は墓穴掘ってユーザーからサヨナラされそうだな

既にもうマイナな言語だから大丈夫。今でも使ってる好き者たちなら付いてくるさ。ｗ

2029年か。想像できんな。
妄想してみるか。

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

C++以外の妄想
・宗教戦争は終わらない：言語、OS、コンパイラ、エディタ
・既に64bitが主流になり、32bitコードは16bitコードなみの扱いを受けている
・メモリを数十GB確保することは当然である
・そのようなハードウェアでも、最新の3Dゲームはまだ遅い
・96DPIより高いDPIのディスプレイが使われている。

関数型言語が主流になっているだろうな

>>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とか新たな単位がデファクトスタンダード化してたりして
妄想楽しかったわ

>>138
・GCは本当にC++標準になるか?
・CRTPの果たす機能を、より一般的でかつ抽象的な機構で実現できないか?
・daemon method, accessor hook

>>140
2038年問題は考えてたけれど、2029年には早すぎると思って入れるのをやめた。
人間が騒ぎ出すのは、大抵、問題がひっ迫してからだから、数年後に迫らないと、
本格的に議論されないと思う。

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

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

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

>HDDなんかがTB越えて
HDDに置き換わるものは、やはり20〜30年ぐらいじゃ無理かな。

>>141
mixin だな。今の C++ に足りないのは。

conceptはmixin風に使えるけど、
access controlがないのが痛いね。

>>142
まあY2Kと同じで大した問題は起きないだろうな。
と油断しておけば、いろいろ問題が起きて楽しめるかも。ｗ

>>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が無いのは困るし、マクロ定義が使えずにインラインというのもそれはそれでデバッグログ
出すときに困る…

2038年問題はスレ違い

namespace階層入れて欲しいなあ。
stdがどんどん増えるのは好ましくないと思う。

>>144
もうちょっとｋｗｓｋ

>>148
> stdがどんどん増えるのは好ましくないと思う。

わからなくはないが、STLの大半がコンテナであるうえに、stdというネームスペース名を考えると、
確かに新しい標準ライブラリは異なるネームスペースに入れて貰いたいという気もしなくもない
ついでに、マクロに C++0x 対応コンパイラなのかどうかを判別するマクロ用意して欲しいんだけど、
既にそれは予定済みだったりしてｗ

C++ にはヘッダファイルってものがあるから
気軽に using できない。
そう考えると、あんまり標準ライブラリの階層深いと
ダルくなると思う。

>>150
__cplusplusの値が増えているんじゃないの？

>>151
それそれ、頼むからヘッダファイルで using namespace std; とかしないで欲しい！
だが、今のPRJではそこら中にあるんだよね…
そんなに std::string とか std::vector って書くのがめんどくさいのかね

>>152
それもそうだｗ
__cplusplusなんて値を意識しないもんなぁ extern"C" くらいにしか使わないからｗ

美少女中学生を namespace 俺の姓; で囲んでバラ色の生活をだな

ADL対策でstlの中にも名前空間を作っていけないとやっていけないんじゃないのか？

>>151
単純にスタティックなオブジェクト言語の限界だと思うんだが

>>151
ヘッダも今や階層化されてるし。
>>156
そんなの関係ないねえ

>>157
> そんなの関係ないねえ
どんな意味で関係ないんだろ? >>151, >>156 は
> ヘッダも今や階層化されてるし。
このことを問題にしてるんじゃないのか?

皆の見解をまとめると、これからはD言語の時代ってことか。

それはない

何だかんだ言ってもここ20年間はおおむねCとC++の天下だったし、
それはこの先も変わらないだろうな

関数型言語に取って代わられるだろうと予想する。
オブジェクト指向やC++にはスマートさで限界を感じる。

まさか
LISPが誕生して50年になるけどその間に関数型言語が主流になったことなんて一度もないだろ

>>162
ほんとにそうよね。

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

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

というのを考えると、やっぱり C++ には限界を感じるんだけど。

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++色々取り込みすぎて記述レベルに難があるとは思う。

>>161
D言語はpure関数とかを導入して、関数プログラミングを取り込む方向で動いてるみたいだね。

http://www.digitalmars.com/d/2.0/accu-functional.pdf
どうなるかわかんないけど。

ついおこづかいでアクセサリーを買い込みすぎてしまう美少女中学生

>>166 美少女中学生以外は眼中にないのか?

>>164
わからん方が鈍いと思うけどね。

>>168
schemeをやってきた俺は勝ち組だがな。C++はのλはモドキだ。

馬鹿丸出しだな。

記述レベルに難がある
モドキ
だけじゃなくて、具体的に言わないと。
愚痴書くスレじゃないから。

やっべー、薄っぺらいことがばれてもうたｗｗｗ
でもテンプレートの可読性の低さは難だろ。キモ構文のオンパレード
それでもあなたはC++に期待しますか？

メタをテンプレートで実現するのは難アリ。

>>171
例えばscheme処理系は言語の機能として構文拡張が可能。
C++は言うに及ばず。

Schemeと比べてああだこうだ言われても。
Schemeのプリミティブは強力だけど、
Schemeだって得意じゃないことは一杯あるし。

C++のclosureは、Javaの奴みたいに、
コントロール拡張について考慮されてないのが寂しいですねえ。

>>175
＞C++のclosureは、Javaの奴みたいに、
＞コントロール拡張について考慮されてないのが寂しいですねえ。
もうちょっとｋｗｓｋ

つ http://jazoon.com/download/presentations/1680.pdf

range-based for-loopと絡めたいね。

>>162
まるでLISPが関数型言語みたいな言い方だな。ｗ

自分の知識がきっちりしていることをひけらかすだめだけの
細かい突っ込みは痛々しいよ。
その「句点のあとのダブリュー」に突っ込むくらい虚しいことだ。

美少女中学生が丸出し！

いい加減中学生から離れろ。

そうだそうだ。中学生なんてババアだろ。

>>180
あやふやな知識じゃ自慢できませんものね。ｗ

自慢というか、自爆。

美少女中学生の初めての自慰はダイソーバイブと相場が決まっていてな

つまりUnlambdaサイコー！ということですね
わかります

>>177
遅くなりましたけれどありがとうございます．
finally 周りを省略するための使い方は， scope guard 系の技法に
lambda expression を組み合わせれば C++0x でもおよそそのまま転用できそうですね．
Listener に Event 設定したり， thread function の設定に使うのは
C++ だと lifetime の問題が出てくるのでそのまま転用するのが
難しい局面が出てくると思いますけれど，
これはコントロール云々とは直接は関係ないですかね．

>>138
Dスレから来ました
＞ Brainf*ckやWhitespaceまでもがC++としてコンパイル可能
DでBrainfuckをDの関数としてコンパイルするサンプルはもう作ってみたよ。
C++でもテンプレートプログラミングが変態的になればできると思う。
メモリ管理がうまくいけばJavaあたりはC++で直接いけるような気がします

Dか。
Dはやねうらおが一時期信者だったので敬遠してたんだが、
今は離れたみたいだし、ちょっと遊んでみようかな。
流行るとは思わないけれど。

>>190
「誰々が信者だったから〜」
なんともくだらない理由だなww

Rubyはまつもとが××信者だったから〜

生理的に駄目なやつっているだろ

美少女中学生の生理なら駄目じゃないぞむしろ大歓迎

製作者がGPL信者だったから敬遠しますた

それは実害があるからしゃーないが・・・
坊主憎けりゃ袈裟まで憎いとか俺には一生分からない感情だろうな。

「誰誰が信者だったから〜〜」
「坊主憎けりゃなんとやらか」
「でも今日は気にしないよ」
「あー、"今朝まで憎い"ってか」

まつもとはいいかげん他言語を煽って目立とうとするのはやめてほしいんだが
煽りの内容もお前が言うなレベルの低次元なものだし・・・

子供っぽい美少女中学生はどこが坊主？

結局 Python に落ち着いた漏れ．
でも最近は仕事じゃPHPばっかりで萎える．

まぁ標準みたいなもんだし

C++0xはC++1xになるのだろうか…

0f までいけるからまあ大丈夫だろ。

07までだろ…

それは盲点だった

いいかげん0のプリフィクスで8進数リテラルっての止めて欲しい
誰も使わない上に紛らわしい

pythonを見習って止めるべし

つ 互換性

パーミション設定するときに使うべ。

そうだな
パーミションは3ビットだから8進使うと便利だな

そのために8進表記があるんじゃないのか

別にパーミションのためにあるわけじゃないぞ。

for all 3bit user

それより２進表記を作ってくれ 0b0100110101010 みたいな

読みづらいから D みたいに区切りを入れられるようにしてくれ。

>>212
これ良く書かれてるんだけど
0xdcとかが11011100とかに見えないの？
実に不思議だ

TMPで2進表記をする有名なサンプルがあってだな・・・

>>214
「実質ゼロ時間・ゼロ労力」でできるのはせいぜいその辺の変換+αくらいで、
その程度ではまるで不便だから「よく書かれる」んだろう。

もし「0xdcが11011100に見えないレベルの人が」よくこの要望を出しているのだと考えているなら、
勘違いで自分を相対的に持ち上げすぎ。不思議っていうか、君が不思議ちゃんだよｗ

頭の中で変換可能ならリテラルの表記は10進のみでおｋ
という話しになってしまうな

ただ二進数だと桁が多くなるから区切りがないと返って可読性落ちるな

>>216
どういうこと？
16進と2進は直接4桁ごとに変換できるから2進表記はないんだろ？
そしてそれをほとんどができるから
よく書かれるってのは皮肉で書いたんだけど

皮肉っていうのはおまえいつもそれ書いてるなって意味

俺は脳内で変換できるから、5進数でも大丈夫

16進でいいだろってのは釣りなんだから相手にしないでおけ。

C系言語使うつもりなら
・2進 <-> 8進 <-> 16進の変換
・0xF*0xFまでの16進九九
・文字定数 <-> ASCII値
・主要な2^n値の10進表記(n=1〜16,20,24,30,31,32,40,63,64あたり)
くらいは身につけてるのが常識だし、マナーだと思ってたが
最近はそうでもないのか

身につけるのが常識である事と、
そのままでいいこととは別の話だろ？

そんなのまで言語側で面倒見るべきではないと思うぞ
九九を知らない奴が家を設計できるようになることが良いこととは思えない

0b0100110101010
こんなのぱっと見て長すぎて分かりにくいし
たかだか16個のビットパターン覚えられないって方がネタだろ

>>222
この辺、本当にそう思うならちょっと披露して欲しいと思った。
・8進16進変換
普通の人は、2進を介在させないと難しいと思う。
・16進9x9
必要になるケースがレアすぎる。
・2^nのnが40とか64とか。
nが16以下なら普通に言えるけど。nが32でさえ桁数が多すぎて普通は無理。

D みたいに自由にアンダースコア入れれるようにすればいい。

>>222
そんな化石言語使いません。

マクロとか書けるけどな。
でも、できるなら言語的にサポートされてほしい。

0b001101000101ならすぐ0x345とわかるけど
これを0b1101000101とか書かれると困る
0bの後に続く数は4の倍数個に制限するべきだが、導入されたとして多分そうはならないだろ
だったら有害なだけ

いや32なら簡単だろさすがに

>>231は思いっきり勘違い

>>230
D ではこう書く。

0b11_0100_0101

特にメモリが4Gに迫って色々あったり2038年問題の影がちらつきだしたこのご時世に
2^31と2^32の10進値も知らないコンピュータ技術者がいるなんて信じたくない

だから、概数を覚えていることと全桁そらで言えることは違うって。

およそ40億としか覚えてなかった
1048576までなら覚えてるけど

20億代と40億代だと覚えておけば、
細かい値が必要なときだけ電卓でポンでいいだろ。
無駄な事覚えるのはタダのバカ。

約21億と約43億としか覚えてないなぁ
けど2^24は16777216って覚えてるな

>>234
2^10 = K
2^20 = M
2^30 = G

で十分だ。

>>238
俺も 16777216 は覚えてるな。
何か覚えやすい並びだしな。

>>239
Gってのは文脈によって1073741824・1047586000・1024000000・1000000000を意味する可能性がある
全然十分ではない

>>239
2^10=1024も知らないとか冗談だろ？

1024 は流石に知らないと恥ずかしいな。

>>241
例えば伝送速度は1k=1000、メモリ容量などは1k=1024換算だ。

>>242
んなもん覚えてるわ

2^31=2147483648は結構覚えやすいと思うんだけどな
万の区切りで48が2回出てくるし偶数桁目に4,4,3,4って調子よく並んでるし

>>241
文脈だって、馬鹿じゃね

2^8 = 256
2^10 = 1024
2^15 = 32768
2^16 = 65536

これはおさえとかないと確かにマズいな

データ容量でキロを1000メガを1000000と解釈するのは記録メディア業界だけ？

0xFFFF = 65535
これで覚えてる

>>248
メディア業界でも会社によってメガが1000000だったり1024000だったりするから困る
（1048576であることはまずないけど）

てかC++0xのスレだよな？

いつまでも0bなんて粘着に持ち出すゆとりのせいで荒れたじゃないか

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

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

#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)

とかの方が分かりやすい

0b literals considered harmful

Gauche使え

そういう思い込み書き込むスレじゃないから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);

コンパイラの都合臭がする記法だよな

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厨もおとなしくなるのに

なんか盛り上がってると思ったら、記憶力自慢の子が来てたのか。ｗ

typedefの何が気に食わなくてこんなキモい構文を

こういうのを見るとC/C++って下品なプログラミング言語だと思うよな。

>>262
そこがいい。下品な俺たちにぴったりなのだ。

>>261
templateの例はtypedefじゃきついだろ。

関数型表記の無理やり感がついに破綻しましたね。

>>260
というかその人達、これだけ会話が続いてもまだ
「16種類のビットパターンを覚えられないから0b表記を欲しがっている」
と思い込んでるのが痛い。

>>265
ごめん、違うの？

>>266
違うに決まってるだろ。
その記憶力でちゃんと日本語を覚えような。

ごめんなさいバカなのでわかりません
0bには16進のビットパターンを覚えられないゆとりのため以外にどのような利点があるのでしょうか

最近のGCCは独自拡張で0bを持っている。

>>268
バーカバーカ

>>268
保守性の向上

0bでは保守性向上しないだろ・・・

他の言語に採用されてる事に関しては疑問を持たないのかね

何を言おうと標準化委員会に却下された時点で0b厨の敗北は決定している

>>271
0bの方が読みやすい、だから保守性が向上するんだ！という主張ですね？

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

「16進のビットパターンを覚えられないゆとりのため」以外の理由を教えて下さい
この馬鹿な私に教えて下さい

>>274
こういう下品な理由こそが C++ に相応しい

>>275
君は馬鹿というより単純だと思う

面倒くさいから
「ゆとりと仕事する（或いは保守をやらせる）かも知れないから」
でいいんじゃね

>>275
一行目と二行目の間に凄い飛躍があるなw

>>279
0xが読めるなら0xだろうと0bだろうと保守性は変わらないんですから
0xが読めない人にのみ意味のある保守性の向上ということですよね？

普通に読めばそういう意味になると思いますが
どのような飛躍があるのか教えて下さい
単純な私に教えて下さい

読める人でも分かりやすさに差があるし、
2進で書くか16進で書くかによって
コードに込められた意図に差が出ることだってあるだろ。

>>280
「読める」と「読みやすい」の違いは判る？

そもそも16種類のビットパターンすら覚えられないような奴が
73種類もある（しかも多くは多重に意味のある）C++の予約語を覚えられるわけがないから
そういう奴は普通に考えてC++をいじるような仕事が出来るわけがないと思うんだが
0b入れたとしてもさ

駄目だ、こいつ粘着だよｗ

>>280
読みやすさなら圧倒的に16進だろ
0bには別のメリットがあるに決まってるじゃん馬鹿なの？

16進テトリスとかやったことあるけど、
やりづらいことこの上なかったぞw

>>283
本当に単純なんだね

>>281
そんな意図はコメントやドキュメントに書くべきであって
リテラルの形式に勝手にそんな暗黙の約束を置く方がかえって保守性下がると思うんだが

じゃあ for とか while とかじゃなくて goto 使ってください。

>>282
それはもちろんゆとりでも対応表を片手に一つずつ変換していけば読むこと自体は出来るに決まっていますから
今までの「読める」はすべて「読みやすい」の意味だと思って下さい
言葉が足りなくて申し訳ありませんでした

では改めて「16進のビットパターンを覚えられなくて0xを読みにくいゆとりのため」以外の理由を教えて下さい

10進と16進の使い分けだってやってるだろ？
まさか意味も無く16進使ってるわけはないよな？

>>288
Unixのchmodも10進数で書いちゃう人ですか？

>>289
forが出てくれば繰り返しだとわかるけど
コード中に「0xAA」と「0b10101010」が説明なしに出てきて
一体どうやってプログラマの意図をくみ取ればいいんだ？
同じ数だぞ？

chmodを16進で書くのも読みづらいな。
あれは8進で書くべき。
2進が欲しいってのも似たような理由だな。
2進の方が分かりやすい所では2進が使えた方がいい。

2進が使いやすいとしたら4ビットせいぜい8ビットまでだろ
それ以上はかえって読みにくくなるし
読みやすさのためだけなら必要ないと思うんだけど

>>293
例えば5ビットずつ情報を与えたい場合であれば、
0b11011_11101_01011 と書けた方がいいだろう。

10進と16進の使い分けはそりゃあるだろう
おおむね「ビットに意味のある数」が16進でそうじゃない数を10進で書くよな

さて、2進で書きたい数というのは多分「ビットに意味のある数」だろう
16進とどう使い分けるんだ？

5ビットずつってのは16ビットRGBを扱う際に出てくる。

0bが却下されてる理由なんだったっけ
ビットオーダーが環境依存だからだっけ？
でもシフト演算子の << >> の方向にあわせて0bの記法をきめちゃってよさそうなのにな。

そんな書き方16進数でもできないじゃん
これ_挟むの

できるようにすればいいじゃん。

RGB(なんたら)ってマクロでも使えばいいんじゃないの

>>299
ビットオーダーって単なる値には特に関係ないんじゃないかと思うんだが。
つか、それ言い出すと16進数もやばいんじゃね？

メモリ上にはそんな区切りはどこにも存在しないのに
勝手にそんなもの入れられるようにして何が嬉しいんだ？

その釣りは流石に稚拙だ

0x__________________1____________________________0________________________
とか書けるようになるんだろ
きめえ

_ を連続させられないようにすればいいだけだろ・・・そんなの。

>>307
お前はマクロ引数の反省を全く学んでいないんだな

？

個人的にはどっちでもいい。（特に欲しいとは思わないけど、入っても構わない）
おまえらの執着心には感心する。

導入されてる言語があって、そこで別に不自由ないんだから、
導入されても別に構わんだろ。
使いたくなきゃ使わなきゃいいんだし。

ここは変態言語らしく1〜36進数までサポートしようぜ

>>311
そんなのはC++の標準団体に言えよ
とりあえずそんな消極的な理由じゃ話にならない

委員会に却下された理由ってなんなの？

そういえば85進数でIPv6書こうっていうRFCがあったな

おお・・・驚異の1進数・・・
でも、便利そうな状況はありそうな気がするから困る。

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

とか。

等幅で見て

一進数は便利だ
数えれば幾つかすぐ分かる

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

unitary("11111"); /* == 5 */

unitaryじゃなくてunaryか

そこはこうだろ・・・

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

unitary(11111); /* == 5 */

今でも8進数の数字に8や9が使えちゃうことだし
0b入れたとしても中で2や3が使えることになってカオスになりそうだからいらない

エラーになるけど？？

コンパイラが親切なだけじゃないの？
規格上はおｋだったはず

octal-literal:
　0
　octal-literal octal-digit

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

と書いてあるが・・・。

あれ？
昔の話だったかもしれん。すまん

K&Rの2版で8と9は使えなくなったと書かれていたが。

C89の仕様ができるまでは、
そのへんルーズな処理系がいっぱいあってなゴホゴホ

ビットマスクには2進を使いたいじゃんね

15年前にアセンブラからCに移った時は欲しくて仕方なかったけど、
リテラル書くって、要するにマジックナンバー書くってことじゃん。
ダメ。
マクロなり変数なり関数なり、名前を付けてそれ使いなさい。
だから不要。

その理屈だと整数リテラルはすべて禁止だな

マクロ／変数（定数？）／関数が返す値をどうやって書くかという話なんだけどな。

１ビットだけならマクロ使って何ビット目が立ってるか書いた方が分かりやすいが、
複数ビットある場合は微妙かもしんないな。

結局はこう書いてこう使うだろ
#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)」だとしても同じこと）

64ビットの2進リテラルはきもい

もう想像力の欠如した粘着の相手はやめようぜ

ここは想像力の欠如した粘着と
想像力がありすぎる女子中学生好きのスレ

なんで || なんだよー

「1ビット目と3ビット目と4ビット目と9ビット目と12ビット目が立ってるか判定するときに
if(flg & 0b100100001101)って書ければ便利じゃん？0x90dって書くよりわかりやすいじゃんじゃん？？？」
ってのが0b厨の希望ということですね

規格に意見する前にもっとましなプログラミングスタイルを勉強した方がいいと思いますよ

面白いキャラ設定に興奮するのはいいけど、
相手より先に自分が興奮してると馬鹿にしか見えないですよ。

なんか自分を規格を策定する側にいると誤解して、必死に規格の正しさを言い張ってる
お子ちゃまがいますね

お前ら>>257にも少しは意見を寄せろ

まだやってるのかよ

こうまで論争の余地のある機能なんだったら
だったら入れるだけ入れて、使うかどうかは実装者に任せるのが
今までのC++のスタンスとして正しい

>>257
typeof(T+U) add(T, U)(t t, U u);

Dだとこうかな。TやUがstaticなopAddのオーバーロードを持ってると上手く動かないけど。

美少女中学生にオーバーライド

議論の余地ないだろ
入れろって言ってるやつが16進数表記では自分は読めないって以外の理由を
いまだ示せていないし

それが最大にして絶対的な理由だとなぜ気づかないんだ

読める読めないのみ議論の論点だと言い張ってる馬鹿が議論を放棄してるだけ
読める読めないが論点だと言うのなら、10進数表記以外に16進数表記が必要な理由でも説明してみろ

論点もなにもただのスレ違いだろ

プログラミング言語の全ての機能は可読性のためにあるんだよ
それがいらないって奴はBrainfuckでも使ってろ

0bが入ったって少なくとも可読性が下がることはない
だったら入れるべき

>>349
ありません。
16進数表記を必要としている人は、10進数を脳内で16進数変換できない頭の悪い人だけです。
だから俺は要りませんよ、16進数。

16進数が必要なのはコンピュータが2進数だから
そのコンピュータを低レベルで扱おうとしたとき16進数で書けた方が
人間にとって読んだり書いたりしやすくなる

>>349
16進数表記はビット演算のためです
そして2進数表記も入るとすればビット演算のためです
同じ機能は2つもいりません

勘違いしてるようだけど10進数と16進数は変換できないぞ
16進数と2進数はできるけど

じゃあ8進数が（ry

自説を曲げる気のない人にどれだけ言っても無駄じゃない？
なんか恐ろしく単純な人みたいだし

0bが欲しいって言ってるやつは0bと0xの変換が計算が必要な面倒な作業だと思ってるんだろうな

>>354
単項の - があるんだから、二項の - は廃止したほうが良いだろうね。
そのほうがシンプルになるだろう。

でなければ>>352みたいなことは書けない

p-> なんて贅肉。(*p). だけでいい。
p[i] もいらね。*(p+i) だけでいい。

>>358
0bが要らないって言ってるやつは単純な二元論者だから、シンプルな人生が歩めるだろうね

10進と16進の変換は下位桁の状況が上位にずっと波及するから計算が面倒
2進と16進は（2進の）4桁ごとに変換が閉じるから楽ちん

こうですかわかりません

徹底的に無視される8進数ｶﾜｲｿｽ

素人にも理解できる問題は盛り上がって良いね。
そろそろ専用スレでも建てようか？

しかも読みやすくなるならまだしも長ったらしくて読みにくくなるだけだし

>>361
p[i]はマジで害悪にしかなってないからなくなった方がいいと実際思ってる
まるでCに配列が存在するかのような幻想を初心者に与えて混乱させる元凶になってるだけ

区切り入れられるようにすれば読みやすいと何度言えば

ただの荒しだろこいつら

>>367
バカすぎる・・・

それで読みやすくなるコードが既に誤ったコーディングスタイルだってことも指摘されてるのに

権威主義に落ちてるのさ。批判的精神を失ったら、もう技術者としては終わりだ

一人で両方の意見を書いてるマッチポンプ野郎が２人くらい来ている気がする

[]がなかったら宣言ができなくなる

>>371
定数を定義するする地点で使うことに問題は無いと何度言えばいいのだろうか。

>>368
何の機能もない表現をプログラム本文中に入れるのは問題だと思う
本文中の記号はプログラムの動作に何かをもたらすものでなければいけない
（使われ方次第では無意味になることもあるとしても）

>>376
それで読みづらくなるんだったら意味が無い。ただのバカだな。

>>376
おまえ、改行と空白を敵に回したな

コメントも敵に回してるな。

>>377
何の意味もない記号なんてものが（コメント以外に）ある方がよほど読みづらいわ

>>380
そろそろ苦しいから諦めろ。

>>378
トークンを区切るという立派な仕事があるじゃないか
0bの中のアンダースコアはそれすらないんだぞ

>>376
ぜひ作ってくれ。
全てのトークンがプログラムの動作に影響を与える言語。

盛り上がってきたね。いいぞいいぞ。どちらも負けるな。もっとやれ。

>>382
Dでそれが問題になってるという話は聞かない。
ただの妄想に過ぎないな。

>>383
C＋＋は全てのコメント以外のトークンがプログラムの動作に影響を与えうる（もちろん与えないこともある）言語ですよ

0bの_は「絶対に」プログラムの動作に影響を与えない
0bXYと0bX_Yが違う意味を持つということはいかなる文脈でも絶対にない
無意味だと思わないか

上のほうで書かれてた5ビットずつのRGBってのもビット列自体に意味はないから
こんなの使う必要ないと思うんだけど

>>386
別に？

>>382
自明的にトークンを構成する文字の前後に冗長な空白を入れるのは禁止したほうが良いですね

>>386
「違う意味を持つということはいかなる文脈でも絶対にない」トークン列なんて無数に考えつくけど

変数名内の _ の使用も禁止。
全部英小文字のみにしろということか。

唯一使えるとしたらアイコンかなんかのパターンを記述するとき
ソースを見ただけでどんなアイコンか見当付きやすいってことくらいかな

他になんかある？

>>390
いやいや、そりゃあるだろうよ
でもそのトークン列で使われている記号はどれも、別のトークン列の中でなら区別に貢献する可能性があるわけだ

0bの中の_という記号は、それがどんな数値定数の中でも区別に寄与しない
機能自体が全く無意味なんだよ
あるトークンの中で無意味というのとは次元が違う

>>393
トークン間（空白等）は良くて、トークン内は許せないとする論拠は？

何でそれがダメなのか明確な理由が述べられていない。
さっさと言え。

>>391
D言語と同じようにするならその問題はない。

変数名に使える文字に _ を含めてる時点で
プログラムの見た目は非常に重要な要素だということを
言語レベルで認定しているようなもんなんだがな。

>>394
トークン間の空白はあるとないとで全く意味が変わる可能性があるじゃないか

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

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

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

_によって意味が変わることはどんなプログラムにおいても存在しない
だから無意味なんだ

>>397
abとa_bとa__bは違う識別子です
0b11と0b1_1と0b1__1は全く同じ意味です

int ab = 0;
int a_b = 0;
int a_b = 0;

意味は変わらないな。

>>398
何故無意味か説明できていない。
早く説明してくれ。

>>401
0bの中の_にプログラム的に意味がある場合がもしあるなら教えて下さい

>>398
空白だって連続している場所では意味を持たない、そうでない場所では意味を持つ
'_' だって数値リテラルの中では意味を持たない、そうでない場所では意味を持つ（識別子等）

さほど大きな違いがあるようには思えないのだが。

>>402
動作に違いが無いこととその存在が無意味であることには乖離がある。
なぜなら、プログラムはコンパイラだけが読むものではないからだ。

>>402
特定の文脈（この場合は0bの後）でのみ意味を持たないってだけでは？

>>401
398の説明で理解してもらえないとすれば
プログラム中の記号に「意味がある」というのはどういうことなのか
あなたの考えを聞かせていただきたい
可読性とか動作に関係ないことは除いてね

可読性に意味が無いと言う >>406 のプログラムは
たいそう汚いんだろうな。

そもそも必要あるの？
0b001_110_011 なんてやるより
(AAA | BBB | CCC) とかのほうが分かりやすいと思うんだけど

>>408
場合によるのでは？
極端なケースは上で出てきたアイコンのデザインとか。

ビットだけで考えてる人がいるようだが、
Dでは2進数に限らず _ を入れられるわけで、
長い10進数に区切りを入れるのもアリだ。

>>406
お前プロジェクトで人の話聞かないで周りに色々迷惑かけてそうだな
>>376から続いてる話なのにどうして「可読性に意味が無い」なんて馬鹿な読み方が出来るんだ？

move semanticsのディープな話題が出たときには沈黙してるくせに
おまえらって奴は

頭のおかしい奴が話を引っかき回してるようなので一回寝る

>>412
ムズカシイ話はワカラナイもん

>>410
そういや、お金の計算だと三桁ごとにカンマを入れるなぁ。
カンマの代わりに"_"を入れることができると。
int yen = 100_000_000;

>>403
確かにそう言われてしまうとそうなんだが
識別子中の_とリテラル中の_というのは全く別の扱いになる機能で
一方は全く無意味というのはどうなのかと

たまたま開いたら面白そうな話してたから参加してるだけ
普段はどんな話してるのか知らない

互換性的にはどうなの
__1とかって識別子になったっけ

>>418
途中にしか入れられないようにすれば問題ない。

・・・まさか >>413 は >>376 なのか・・・？
・・・ゴクリ。

もうC++0bにしちゃえよ

実際そうなりそうで怖い。2011年。

そんなに無意味な表記が嫌いなら一生マシン語でコード書いてろ

プログラミング言語自体、
マシン語のシンタックスシュガーみたいなもんだからな。
あくまでみたいなもんだけど。

>>412
美少女中学生の話も食い付き悪くてさみしい

>>425 昔から知的で美人の大学生のおねいさんの方がいいに決まってるんだが...

>>425
そんなオバサンの話されても。

構成された美少女中学生そのものが意味なのだ

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

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

繰り返す
構成された美少女中学生そのものが意味なのだ

それは脳内美少女中学生ってことで FA？

お前らバイナリバイナリうるせーんだよ。

#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;

10桁までしか使えないじゃんか・・・。
もっといいマクロならそこら辺に落ちてる。

最低128ビットくらいは使いたいんだけど

0bでスレが加速するってどんだけスレ違いなんだよ

文句があるならそのマクロとやらを使ってとっととこのスレから出て行きやがれ

ここはconstexprを使った例を出すべきだろ…
C++0x的に考えて

どんな底辺プログラマが書き込んでるんだ?

boost の static_assert は式版のがないのがうんこだな。
#define BOOST_STATIC_ASSERT_EXPR(b) ((void)(char(*)[(b) ? 1 : -1])0)
くらい用意してくれないと constexpr で困る。
・・・って、constexpr の引数って静的な値として認識されるんだよね？

>>437
式版の有る無しで何が変わるの？

キャストやカンマ演算子は定数式にはなれなかったような気がするし、
静的な式なら評価タイミングも関係ないし、あんまり意味が無いような。

#define 0B_00001111 0xff

そうなのか・・・。
じゃあ constexpr の引数をチェックできないの？

>>440
メタ関数書けば？
外向きに一段 constexpr 関数かませば使いやすくはなるかも。

>>432
2進数を128桁も書きたいというお前がマレｗ

static_assert の式版とかいうやつを使って
具体的にどういうコードが書きたいのかもうちょっとｋｗｓｋ

式に置換するマクロで

#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; みたいなことができれば
面白いなあと思ってね。

いまさらだけど、0b の話って、
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
が採用されたらさらに一般化されて解決されるんじゃないの？
誰も上で話に出してなかったけど ...

ユーザ定義リテラルは誰か途中で書いてなかったっけ
つうか0bの話ししてる奴の大半はドラフトなんか読んでないんじゃね

>>445
キモイ記法になるから組み込みにして欲しいって話だと思ってた。

>>445
>>259を忘れないで。
たぶんこれのことだよね？

>>259を理解できていたらここまでスレは加速しない。

あれって入る見込みありそうなの？

たぶん無理

入ったとしても定義できるのはサフィックスだけだから
0bは無理なので厨はお気に召さないだろう

別にサフィックス b でいいよ。

#define b0 0
#define b00 0
#define b000 0
// ... 一つの数値に128通りの#define
// = 2^129個の#define

すいません、アホな言い合いが続いていたので 259 を読み飛ばしてました。
でも constexpr って今の定義だとそんなに中にいろいろ書けないんじゃ？

ループを手動でアンロールすればいいっしょ。

ああ、配列アクセスしてる時点で無理なのか。

N2378 と最新のドラフト読む限りでは
suffix しか無理ながら，とりあえず constexpr リテラル化はできるような？
>>259 みたいに for 文を使用 (して，かつ constexpr 化) することは
現在の提案ではできないみたいですけれど

ようやくらしくなってきたが、未解決なのは変わらずか。

constexpr unsigned char operator "b" (unsigned int value) {
　return (value % 10 != 0) | ((value / 10 % 10 != 0) << 1) | ...;
}

このくらいならできるのか？

5bitしか扱えないけどね

いつの時代の住人だ

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 を使いました．

しかし、この例をみるにつけても C++0x は変態ですね

これはまだ分かりやすい方だろ。

美少女中学生は変態さん。なんと制服の下で身体を縄で縛って学校に行っちゃうのです

マジレスすると疲れるだけで全然えろくも変態でもない。

>467は人生の勝ち組

0b狂がいなくなったら誰もいなくなった

mailing2008-03読んでるけど、
0bで馬鹿らしくなって>>257くらいしか書き込んでないw

美少女中学生は空を見上げ待ち続けている…

C++0xで2進リテラルを作成するスレを別に立てたらどうだ？

糞スレたてんなよ

>>473
読まなければ良いのでは？

糞スレを立てると無駄なCO2を排出することになります

俺様のゲップに含まれるメタンガスに比べれば無視できる量だけどな

美少女中学生が排出したメタンを肺いっぱいに吸い込みたい

つ （美少女の）硫化水素

お前らスレタイ0x100回読め

スレンダーでタイツの似合う美少女中学生が俺の嫁

256回読みましたがわかりませんでした

>>481
美少女中学生について語ってはならないとは
スレタイにもテンプレにも書いてないんだが

# 個人的には平面の方が好きなんだけどな

C++0xは3次元あるいはそれ以上の次元を持つとはどこにも書いていないぞ。
まあ2次元とも決まっていないがな。
＃ん、C++タンの出番だな。

N2582
新しい関数宣言方法（ラムダ式と同じ形にする案）
[]foo(int x) -> int { return x; }

[] は大変キモいので、こういうマクロを標準で提供して欲しい。
lambda とかいうヘッダファイルを用意して。

#define labmda []
foo(lambda foo(int x) -> int { return x; });

typo したがｷﾆｼﾅｲ

[] にはもう既に慣れちゃった

委員会のキーワード忌避は強迫観念レベルだな

それほど既存のソースが多すぎるのさ。
そこはしゃーないと思う。
でも、C99 の #define bool _Bool みたいに
互換性を保ちつつキーワードを導入するテクはもっと使ってもいいと思う。

無名関数のおかげで無名構造体にコンストラクタとデストラクタを搭載できるようになりました！
大勝利ですね！

一方ロシアはコンストラクタをthisで定義できるようにした。

なんでlambda expressionのlambda-return-type-clauseって、
->を使うんだろ。
コロンじゃだめだったのかな。
たとえば、普通の関数も統一しようぜっていうN2582も、
こんな風に書けるのに。

[] func() : int
{
　　return 0 ;
}

#define : ->
は無理だったっけ ...

>>492
見た目が違うだけじゃんw

　[] main(int argc, char* argv[]) -> int
　{
　　//...
　}

>>492
コロンはコンストラクタの初期化子と競合しそうだな。

コンストラクタでは戻り値の型がないから大丈夫じゃね。
文法的な紛らわしさに関してはまああるかもしれないが。

ECMAScript4ってそんな感じじゃなかったっけ
いやだなぁ

function func() : int { return 0 ; }
だったか。ECMAScript4は文法キモすぎて見たくもない。
いつのまにかコンストラクタの初期化子まで採用してるし。

テンプレートもあるよ！
function func.<T>() : T { return new T(); }

ぐはぁ

しかしなぜ->なんだ
Haskellかよ

プログラミング言語 Scala
http://pc11.2ch.net/test/read.cgi/tech/1205156417/

Scala違いだ移動しる・・

returnでいいじゃんかよ
コンフリクトはないはずだ

[] func() return int
{
　　return 0 ;
}

なんかもうどうやってもキモいんだが。

ラムダ式くらい 100% 型推論でやってくれ。

そもそもどうしてラムダと形を合わせたいんだ
コピペのためか？

関数型言語的には→なんだから、
->でいいんじゃないの？

関数型言語的にどうかは知らんしどうでもいいが
C系言語的には->は昔からずっと間接参照演算子だ

美少女中学生的には -> と [] はブラのホックの両端だから

>>504
それ、俺も思っていたんだけど、
C++の文法としては、何か違和感あるよね。

ところで、@と$がC++の規格にないのは、何か理由があるの？

[] int foo() { ... } で不都合があったから -> になったんだと思うが、
どんな不都合があったの？

returnsのほうがいい

>>512
(charからcharへの関数)を引数に取り(intからintへの関数)を返す関数
を引数に取り(charからintへの関数)を返す関数の型を、
C++03(「関数」は「関数へのポインタ」とする)とC++0xで書いてみてくれ。

int (*(int (*(*)(char (*)(char)))(int)))(char) のことだよね？

グロい

まぁ現状十分汚い言語なんだから、
多少醜くなってもいいじゃん

>>517
いいこと言うなあ。君のそのレスで俺の気持ちは吹っ切れたよ。

[]([]([](char)->char)->([](int)->int))->([](char)->int)

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で作るべき

>>519の方がわかりやすいが?

>>519
これは従来のアナルっぽい記法よりは読みやすいな

>>511
いまさらtrigraphやdigraphの要るような記号追加するのもねえ…ってことじゃないかと予想

>>523
そういう理由なのかなぁ。
しかし、trigraphやdigraphって廃止しても、それほど互換性の問題も無いんじゃないかなとおもったりするんだけど。
西側の、なまじ7bitで全種類の文字を表せちゃったので、悲惨なことになっている連中も、
結局使ってないみたいだし。

>>521
まずそんなものを書く状況自体が無いな。
あっても >>519 も読みづらいから typedef 使うわ。

C++でtypedefを禁止したらどんなカオスなコードになるか見てみたい

>>526
template メタプログラミングがかなり出来なくなる気が ...

>>526
decltype と auto を駆使することになる

あーはやくautoが欲しい

正直、auto 以外、いらん。初期化もまぁあればいいね、程度だし

ここまでいじっちゃうともう新しく言語作った方が早い気がするしな。

Cとの互換性をとりつつ拡張するのに苦労してんのにそんな事言うなよ

互換性無視できる
ネイティブディレクティブとか作ろうよ

もう互換性なんかとっくにボロボロなのに今更何を

>>530
初期化指定子で初期化指定が完了するのは美しいと思わんか

なぁ、これは俺の思い過ごしかもしれんのだが

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

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

でも, らむだはデストラクションしないとまずいんだろ？

関数を動的に生成してるわけじゃないだろ

536 に便乗で聞くけど、
例えば C# の場合、ローカル変数を参照するようなラムダ式書くと、
クラスが自動生成されて、ローカル変数参照がメンバ参照に置き換わるんだけど、
そういう状態になった場合、デストラクタはどこで呼ばれるの？

ローカルスコープ内でしか使わないラムダ式ならいいけど、
例えば、「ラムダ式を返す関数」みたいなの作っちゃった場合。

そんなのローカル変数のポインタ返してるのと一緒だろ
クラッシュしても自業自得で済まされる話
C++はプログラマを全面的に信頼する言語ですよ

>>537
あんまマジにシンタックス見てないんであれなんだが

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

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

と、思った

ん、よくわからん。
スタックじゃないの？

alloca() を思い出した

new [...] (...) {...}
はないの？よくわからんけど

ラムダ式は関数オブジェクトのシンタックスシュガー
なので、単なる一時オブジェクトとして生成されると思う

関数から返せないということか。
何かエセっぽいな。

C的に考えると、それでいい気がする。

折角だからカリー化とかしたいのになあ。

ラムダキャプチャーを参照でなく値(コピー)にしたら返せる
関数オブジェクトと同じ
でも、戻り値の型を特定できないかも、新シンタックスで可能？

カリー化は手動だな

>>544
となると、>>543 みたいな、ラムダ式をヒープに取るような構文が必要じゃない？
（スマートポインタ使うにしても、まずはただのポインタが要るし。）

それか、ラムダ式から生成される関数オブジェクトが
適切な operator = を実装しててくれるなら別にどうでもいいことなのかな。

>>550
あっても困らないけど、なくても良いと思う
ポリモーフィズムは必要ないし、必要なら従来の関数オブジェクトがあるし

本物のC++プログラマは動的解決をしない。
本物のC++プログラマはコンパイル時に解決する。
コンパイラでできなければ、プリプロセッサでやる。
プリプロセッサでできなければ、それはやる価値が無いのだ。

new を入れたのが間違いの始まりだったんですね

プリプロセッサ（笑）

タイトルはどうなるんだろう。
「本物のプログラマはJavaを使わない」
あたりかな

本物のプログラマネタが分からないのは
流石に本物のプログラマとは言えないな。

本物のプログラマがわからなければ、そのネタは理解する価値が無いのだ。

>>555
間違いなく言語と環境をごっちゃにした反論が帰ってきそうなタイトルだなｗ

conceptがまだドラフトに入らないのが気になる
一番楽しみなのに

独立wordingの方でまだまだ直しが続いてる。

ここで聞くか、Boostスレで聞くか迷ったんだけど、
Unordered associativeコンテナの、bucket関連のメンバってなんに使うの？
規格読んだだけだと、どうもよくわからないんだけど。
あるキーがどのbucketに属するかのインデックスを返されたとしても、
実際のbucket単位に直接アクセスする方法って無いよね？
普通に要素へのイテレータしかないみたいだし。
そのどのbucketに入れられているかってことが分かって、ライブラリを使う側の人間にとって、何がうれしいの？

>>561
begin(i),end(i) で local_iterator を取得できたような。
ハッシュの分散結果をどう使うかってことなので、カスタムハッシュ関数次第
じゃないか？ まあ通常はあまり使わないかも

どっかのbucketにばっかり入っちゃうようなデータで、そのせいで遅くなるようなときに
調査するためじゃねえの

>>561
詳しいドキュメント読んでないから分からんけど、たぶん同一 hash 値だったら
同一の bucket に入ることが保証されるはずだから、次のような使い方ができる。

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

こんなときに、最初の二次元平面上の点に対して、ハッシュ関数を
(x座標値/1000)×(y座標値/1000) なんかに設定したコンテナを用意すると
元のデータが結構ばらけていたら、「同一 bucket 内に入るデータを全部調べる」
みたいなアルゴリズムで結構効率的に解ける。

おもろい

>>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に入るとも規定されてないよね。

あくまでハッシュという名称を使っているだけで、実装じゃないし。

境界の違うハッシュを2つ使えば？
(x/1000)*(y/1000) と ((x+500)/1000)*((y+500)/1000) みたいな

>>566
bucket の番号を用いる例のためだけに、アルゴリズムの細かなことを書くのは
面倒だったから、本当に方針だけを書いたつもりなんだけどなあ。


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

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

詳しいことは、適当な計算幾何学の本を読んで欲しいところ。
こういうのはバケット法などの名前で知られている割と標準的な技法。

えぴが陰毛茫々じゃないから
進みが遅いと思う

>>566
いや、だから規格では、同じハッシュ値のキーが同じbucketに入ってるって事ぐらいしか、
規定されてないような気がするんだけど。
似たようなハッシュ値が同じ、あるいは近いオフセットのbucketに入っているかもしれないとは書いてない。
そりゃ、大抵の実装はそうなるだろうけど。

間違えた、>>568

>>561
http://cpplover.blogspot.com/2008/05/c0xunordered.html

>>570
似たような点を同じハッシュにするって話じゃないの？

>>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) を実行することがこの操作に対応する）

で、0x関係あんのか

>>574
関係ねーだろ10000回染んで来い

そんなにdelete thisできないな

>>570
つうか、一体何が疑問なんだ
同じハッシュ値のキーが同じbucketに入ってるって事が規定されてりゃ十分だろう
同じハッシュ値になるようにハッシュ関数を作れば同じbucketに分類されるんだから

ああ、なるほど。
似たようなキーを同じハッシュにするのか。
それで(x座標値/1000)×(y座標値/1000)だったのか。

レベルが高すぎてよくわからん

そんなに高くないよ
情報系の学校入れば絶対習う程度

学無くても考えれば分かりそうな。

修学旅行での温泉の脱衣場の洗濯カゴみたいなもんだ
一つのカゴで一人の美少女中学生をイテレートできる
美少女中学生は控えめだから棚の下の方にハッシュされてるという寸法さベイベ♪

下着がなくなってたりするんだな

露骨なエロで興奮するあたり、それらが控えられた萌えに欲情する若者とは違うという部分がみえみえなスレだな。
勢力の足りないおっさんが無理にネタ振らなくても良いんだぜ？つまらないだけだから。

age

>>585
つまらない。

どうでもいいよ

ここんとこ寒いね

うんそうだね

今までが暑くて相対的に寒く感じるだけ。
平年並みだろ。

それだけ暑いのが続けば「平年並み」の気温も底上げされててもいいんだがなあ。

平均気温は過去20年のデータで計算するから、20年間で急激に気候が変動してると追いつかない。
そんだけ温暖化が深刻ってこったな。

strong typedef って入るんだったっけ？

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でもつかっておけば。

strong typedefってどういう物？
usingとかとは違くて？

typedef元とtypedef先が別の型として扱われるというtypedef。

C++09 になってんのか、もう。

え、まじ？

あ、いや、ちゃうわ。ごめん。

>>597
それあったらテンプレートがまたワクワクするものになりそうだな

数値型の暗黙の変換はC/C++の型システムの穴だから
strong typedef でまずその穴をふさぎたい

そんなもん別に機能にしなくてもこれでいいんじゃないの

class AnotherType : public Type{
private:
　operator Type();　//実装しない
}

そんなこともできるのか。それは欲しい

intとかでもやりたいんでは

実装あるもんなw

もう#define int nanikaしろよ

要するにこういうの作ればいいんだろ？

#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();
}

手抜きをするためのものなのに、メンバがコピーされないようじゃ意味がない。

mailing 2008-05 きてるお

^ω^

>>610
乙

コンテナとかSTLがみんなconcept化されてる！

ドラフトは N2606

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2601.html
がスゲイ

C99と同じ感じになったりしないの？
現行のC++から、この仕様のC++にキレイに置き換わってしまう？
また、複雑難解怪奇な文法を覚え直さなければいけないの？

>>616
GCCだけでなくVC++も実装してくると思う、現にTR1も対応しているし。
C99よりは広まると思う。

文法はどうしようもないな。現在でも複雑怪奇なんだから
今さら少しくらい増えたってどうってことないって構えをしたほうがいいかも。

better C++03 として使う人が多そうな予感。
auto とかは使うけど・・・って感じ。

ぶっちゃけC++が廃れる要因になるだけな気がしないでもない

化粧を覚えたてでちょっと厚塗りしてみた美少女中学生のような感じだな
化粧のナイステクを見つけるのが先かこっちが見慣れるのが先かというところか

今はネイティブで代わりがないから C++ 一択だけど、ObjCを綺麗にしたようなクラスベースの
言語があれば、もう C++ にこだわる気になれないなぁ。うんざりする

Cに速度的な最適化を期待したのが間違いだったんだ。
やるならfortranを++すれば良かったのに。

>>622
そこで Fortress ですよ

>>621
だからD言語を使えと(ry

>>623
あれは数値計算用途以外では使いたい文法でもないけど・・・
それ以前に、なかなか開発進んでなくね？

>624
GC がいらない

>>616
(ほぼ)今のままのコードで動く。

>>626
GCありというか明示的メモリ管理なしのC++ってもの使ってみたい。
DとかJavaじゃなくて、まっとうなC++で。

>628
だが、リソース管理は結局自前だろ
ファイナライザは入れないんだよな

>>618
現行でC++03としても使えてない奴の方が多いからな
その辺はしゃーない

サブセットでヘッダの要らない仕様を作ってくれないかな。
どうせ、プリコンパイルヘッダみたいな事やるんだから、
.cppをプリコンパイルして参照解決したっていいじゃん。

そうやってサブセットのスーパーセットを考えてるうちに C# になってしまいました

>>631
モジュールシステムを設計しなおすことになると思う

仕様を作るのはいいけどさ、
とりあえずその前にほとんどのコンパイラベンダに言いたいんだが
export を実装してくれよ！

Comeau 以外どこか実装してんの？

実装が大変な割に大したメリットがないからじゃないの

exportの実装がめんどうになった時点で分割コンパイルなんてあきらめればよかったのだ

extern inline なんかどこも完全実装できてないしな
Comeauでさえ

>>615
提案しているのが Lawrence Crowl だし，ほんの一瞬とはいえ
本気にして「なんだ！？とち狂ったのか！？」とか思った俺涙目ｗｗｗ

>>638
ｗ
ま、いつか入るかもな。競合は大丈夫そうだし。
16進浮動小数点数リテラルとか知名度低いのもあるし、こっそり紛れてても誰も騒がないでしょｗ

ASCII外の字をプログラム本文に持ち込むことをあっちの国の人らが許すはずがない

コメント文字列をプログラム本文とみなすかどうかだが
普通にやってるとチェコ語だかでパース失敗しなかったか？

なんだそりゃ。
まさかチェコ語は、スラッシュやアスタリスクにまで独自の文字を割り当てているのか？

チェコ語ということはutf-8か？
-Ku は当然付けてるよね。

コメントに??付けるだけでおかしくなります

もう APL になったつもりで変な字いっぱい使おうぜ

トリグラフも迂闊に追加できないこんな世の中じゃ。

つまりクアッドグラフが求められる時代になったということですね

concept 使った for_each がこう提案されてる
auto がこんな使い方できるんだ

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

役立たずだった auto が大人気だ

大人気で広まる
↓
恐ろしい副作用が見つかる
↓
カオス

の黄金パターンですね、わかります

>>639
十六進浮動小数点数は、C99由来だから知名度低くても余裕で入るだろ、たぶん。

concept のようなメタタイプを持つ言語がほかにあるんでしょうか？
Haskellのほかに
静的型付言語で

>>651
conceptの型理論を書いた人たちがGってのを作ったよ。
他にはない。concept_mapみたいなglueがあるのは。

conceptの一番の利点はコンパイル時のエラーメッセージ

>>653
concept_mapを理解してないね。

今度はコンセプトメタプログラミングの時代ですか

自然な流れじゃないかな
ジェネリックス系としては

そしてC++1xでは
コンセプトの型を規定するスーパーコンセプトが目玉機能になるんですね
わかりました

滅多metaな超言語それがC++1x

C++ 捨てて別言語使った方がいいんじゃね？
と、マジで思う今日このごろ

そんなあなたにC++0x。 もはや別言語だから。

まともなC++0x処理系ができるまでは暫く離れるのもいいだろうな

C++3xで会いましょう

namespaceスコープでアクセス制御が出来たらいいと思わね？

namespace hoge {
private: void priv();
public: void pub() { priv(); }
}
hoge::priv(); // error

>>663
入れ子にした無名 namespace で代用できない？

>>657
concept はコンセプトをパラメータにとることが出来るのでメタコンセプトは必要ないと思う

無名にしなくても、boostの
namespace detail {
はそういうことやってるんだわな。
>>663はスロット単位でやりたいんだろうけど。

>>654
「自尊心はあっても自信が無い」から、衝動で突っ込むけど説明添える勇気は無いんですね、わかります。

整数のイタレータのサンプルコード見ればいいんじゃない？ > concept_map

autoとcenceptでC++も分かりやすい言語になるかなあ。

ならんね

そもそも、現行C++も分かりやすい言語にするために
突っ走ってきたという面が多かったと思う、D&E読んだ直後の感想。

しかし、現実はと言うと……。
0xも同じ道を辿るに違いない。

>>671
> 分かりやすい言語にするために

皮肉とかじゃなく、そうは思えません。
やはりCとの互換性を抑えた上での、実行効率をメインに考えてきたと思います。

>>665
ｋｗｓｋ

Perl6 の二の舞になる、なんてことはないよな。あはは

>>673
やっぱ出来ねえや
勘違い

最近は使う人にやさしくなってきてるよね

つらいのはコンパイラベンダやライブラリベンダ

ここまで巨大仕様になるともう新規参入とか不可能だよな

GCCからforkすればいい。

現行の auto って型名のかわりに
auto i = v.begin();
みたいな書き方をする以外に使い方ありますか？

型名の現れうる場所全てに現れて
福音と混沌をもたらします

>648

自動変数の宣言

使うだけの人間としては規格の議論より処理系がいつできるかの方に興味がある

規格書いてる奴らが作る訳じゃないからな
2020 ぐらいじゃね？

だが実装可能性ぐらいは考えて欲しいんだぜ。

もう委員会が「完全準拠のコンパイラを最初に作ったチームに賞金」でいいだろ。
商用コンパイラとかだとその賞金が売り上げを下回るっていう可能性もあるから、
MSの無償配布してるものと同じ様なライセンスでなければいけないとかいう条件をつけてさ。
そうすれば販売方法を確立できない個人でも目指す事ができるし、万が一先を越されてしまっても
その場合は販売すれば良い。

C++03の下位互換性から考えると、exportも必須なわけか？
そんな非現実的で理想を追求した完全準拠のコンパイラは、まず実用にはならないと思われる。

外部テンプレートなんかさっさと規格からぶち殺して
貴重な予約語exportをもっと他の有意義なことに使えるように努力すべき

>>686
個人でやれるような範囲の話ではない

MSがバイナリインデックスの並び順で特許取っててそこをCOMに使ってるから無理
テーブルを先頭に持ってくるんだったか程度のもの

特許なんてそのうち切れるさ

vtblを頭に持ってくるって話？
ABIだと思ってたが、特許なのか？

>>684
Conceptは、Douglas Gregorが規格も処理系(ConceptGCC)も書いてるよー。

そのGCCではあのクソ気持ち悪いラムダ式とかもコンパイルできるのかい
だったらちょっと試してみたい

これはconcept branchだから、
他の新標準機能は入ってないよ。
http://gcc.gnu.org/projects/cxx0x.html
lambdaはgcc headで実装始まってるはず。

>>686
2100頃までC++は生き残るわけですね分かります

std::*Integralが、
std::*IntegralLikeになってやがる。
FloatingPointLikeってなんだよ
// Revision 1の頃から変わっていたのか

C++0xはそろそろJavaの時のような誇大広告を始めて盛り上げるべき。

どんだけ人集めてもmove semantics見たらみんな引くって。
大衆には見向きもせずプログラミング言語の実験室として頑張っていただきたい。

もはや C++ 自体が大衆向けじゃないよな。
でも、必要としている一部の人間のために頑張って頂きたい。ｗ

まずはまともな処理系を、話はそれからだ

Move SemanticsとかVariable TemplateとかConceptとか、
ライブラリを書く奴のための機能だから、
一般ピーポーが覚える必要は無いんじゃない？

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

STLヤベー、超便利ー。
↓
イテレータとか関数オブジェクトとか分からん。勉強するか。
↓
いわゆる、STLの解説本とかではまともに説明されてねー。何コレ。
↓
テンプレート解説本なら詳しく載ってる。やっべ、スゲー詳しい。面白れー。
↓
Boostたのしー。
↓
あれ、当初の目的って何だっけ？
STL？　デザインが貧弱すぎじゃね？　あれって。

素人の人たちに受けのいい機能も少し追加されたんじゃない。
auto とか。

conceptだってコンパイル・エラー見やすくなるしね。

今回は入門者のためにもなる改良がたくさんあるとどこかで聞きました

c++であと１０年は持つのかな
すでにフォートラン化しはじめてる？

当分、いろんな意味でC++を越える言語は出てこないだろうな。

export イラネ
予約語から外してほしい

export の実装って結局二度以上同じソースをコンパイルしてるだけだからな
prelink 工程というのがあってそこで全部解決するまで再帰的にコンパイルしつづける

関数がインラインにならないという効果はあるがそれ以上の利益はない気がする

>>706
FORTRAN 77とは全然違う。
FORTRAN 77は数値計算の世界では現役のまま陳腐化した。
C++0xは現役のまま最先端を走り続け、プログラマを置き去りにし続けてる。

置き去りかよｗ

道を踏み誤りつつあるマッドサイエンティストみたいなもんだな

exportは後々autoみたいに役に立つ日がくるのでほっといてやってください

>>710
> C++0xは現役のまま最先端を走り続け
「他言語に出来ることが出来ないので悔しい」
って、入れた機能がほとんどじゃないかい？

>710
Fortran2008は結構強烈だぞ？

>>714
conceptはHaskellだけじゃない、似てる機能があるのは。
しかもそれは後から分かったことだし。
traitsを置き換えるために生まれた。

move semanticsだってかなり狂ってるしね。
明示的なメモリ管理がある言語で導入するとは。

C++ はあまりお作法がない言語だったと思っていたんだが、今は作法が大杉って困る

意味が不明瞭だ
お作法って具体的にはどういうこと？

>>713
registerもいつか役に立つ日が来るのでしょうか?

>>715
Fortran2008のco-Arrayなんて、
Crayの実装の後追いじゃないですか。
C++0xなんて規格が独走状態ですよ。
一緒にしないでください、失礼です。

>>718
俺のエスパー能力を駆使すると、パラダイムをお作法と訳してるんじゃねーの。
禿げ曰く「C++はマルチパラダイム言語だ」と。
パラダイムがないつーか、ひとつに縛らない言語だがな。
パラダイムが何も無いのがすばらしいなら、ifとgotoだけでいいじゃねーかと。

規格を崇拝するお前らに楽しい問題。

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

これをもうちょっと人間的にするために、
なにかプログラマが優先順位を指定できるような機能はつくれないのかな。

暗黙的に呼ばれる変換コンストラクタに依存するのはよくないってのは有名な話じゃね。
だれしも一回は引っかかる罠だけどね。

その辺いじくるとスマートポインタが軒並みぶっ壊れるから
触れないし触らない方がいい

つ f(string("Hello"), string("Goodbye"));

正直ついていけてません。すみません orz

>>719
もしかしたら、&の使用を制限する目的に使えるかもしれない。
例えば、register int foo して func(& foo) したらエラーになるとか。
で、参照渡しができるのなら、ポインタの使用を禁止できることになる。
# 意味が違いすぎるなw

俺も最近まで register に & を付けれないと思ってたけど、
C++ では付けれるらしいよ。

もうラムダ式のキーワードにregister使ったらいいじゃん
どうせ予約語の意味なんてメチャクチャなんだから

何度も言うようだが inline がいいと思うお

却下されたんだろそれ

やっぱり解析が凶悪になるからか。

>>731
だれか提案したの？

ここの誰かが突撃してはいはいﾜﾛｽﾜﾛｽされた

キチガイ度で言えば現状もどっこいどっこいだと思うだけどな。

最初から頭の使い方が足りなくて狂ってるとしか思えないのと
考えに考えた末に発狂するのとでは筋が違うと思う。

オーバーロードは罠が多いから・・
特に特殊化と混じったりするとわけわからん

>>734
それどこで？
comp.std.c++ と comp.lang.c++ と流し読みしてるけど、とりあえず見覚えが無い。

inlineも規格化前に勝手な独自拡張でｸﾁｬｸﾁｬに使われてきた経緯があるから
あまり触れたくないよな

inlineってどうするの?

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

とか?

無名関数をinlineと呼ぶのはすげえ違和感がある

__lambdaとか_Lambdaでいいからキーワード追加してくれよ。
適当に#defineして使うからさあ

別に _Lambda だろうが [&] だろうがいいけど
とりあえず #include <lambda> をくれ。

C++03 の extern inline って C++0x にまだ残ってる？

>>722
でどっちが呼ばれるの？

ふつーに考えて1でしょ？
(ブーッという音が聞こえてるようだ)

失礼、答えつけててくれたんだね。。。
んで、pointer-to-boolなんて知らなかったので、さらに調査中。
昔はほんとにC++好きだったんだけどな。今は規格がぎしぎししてるね。

その馬鹿げた変換を何とかするためのnullptrだが
全然何ともなってないといういつものパターンなんだろ

もうポインタと整数
整数とbool
は互換禁止にすべきだな

やりたきゃ明示的にキャストしれと

if(smart_ptr)が出来なくなるとブーたれる奴らが強硬に反対するので無理です

それは暗黙的変換とは関係なくね？

NULL と比較しろよ・・・。
ただ、if (T* p = dynamic_cast<T*>(q)) { ... } がやりたいので
無くなると困る。

「さらば、式の中でも変数を定義できるようにして進ぜよう！」

なんでよりカオスな方向に解決するんだよw

オカス！？美少女中学生を！？

>>751
は？C++でNULLなんて使うなよ。0を使え。

これからはnullptrだろ常考

nullptrなんて意味ないよなぁ
どうせ変数に入れたら0と区別付かないからやりたい放題なのに

>>755
NULL をどう定義するかは処理系定義で、
整数変数に代入しようとした時に警告出してくれるように
定義してくれてるかもしれないというのに
何で 0 なんて使わないといけないのか。

>>758
Effective C++ を100回読め

NULLを0以外でdefineしてるC++の処理系なんてものがあったとしたら
今すぐ叩き壊した方がいいよ

C++では、マクロを使わない事を推奨されている。なのでNULLよりも0を使う方が綺麗。
もちろん、C++はある程度「綺麗」なスタイルを提示しながらも、そうじゃないスタイルを拒絶することはしない。
better Cとして、例外を使わなかったり、templateを使わなかったり、NULLを使っても良い。
ただし、それが推奨されているわけではないことは覚えておくべき。

>>760
g++ は __null で定義されているが・・・。

NULL 使ってる人は毎回 cstddef あたりを #include してるのか？

>>761
enum{NULL = 0};

<template T>
T *NULL(){
　return 0;
}

NULLより0ってのは、
Effective C++以前のC++ FAQの時代からの常識。
>>759
情けない…このスレに来るのは十年早いよ。

>>763
NULL は結構色んなヘッダファイルで定義されてるので
cstddef をインクルードするまでもないことが殆ど。

Effective C++ と C++ FAQ の説明内容に違いはあるの？お爺様

相変わらず破綻してる言語だな

>>765
それだとメンバへのポインタに対応できない気がする。

定期的に低レベルの話題で荒れるな

>>767
実際のコンパイルでエラーになるまで対応するヘッダをインクルードしないってこと？
ライブラリの実装に依存してそうでイヤじゃない？

>>771
低レベルの質問にはよく答えられる低の高くらいのレベルの人が多いんですよ。
おいらも含めて。ｗ

低の高っていうと
エントリーモデルの中で頭一つ出た商品みたいで所謂人気商品ってイメージ

ある意味正しいな。
今は、プレミアム系商品の人気が高くなっている辺りも含めて。

C--

>>776
廃れたね。
JVMもCLRもなければ主流になったかも知れないのに。

>>772
規格でどのヘッダがNULLを定義してるか決めてあるでしょ。

>>772の言っているのは、
使うなら、定義されてるヘッダを必ず明示的にインクルードしないと、
コンパイル通っても、実装依存なコードだってことでしょ。
実際多いよね、そういうコードは。
実装上の都合による孫インクルードに依存しているコード。

>>779
多いね。
うっかりやることもあるので、ちゃんと警告するシステムが欲しい。
（あるのかな？）

NULLはプリプロセッサマクロだから使うなと言う舌の根も乾かぬうちに
#includeの話題で盛り上がってるあたりC++の病巣がよく表れている

#include を使わずに済むしかけを入れて欲しかったな＞C++0x

シンボルだけを読み込む機能は確かに欲しいが、
いまさらC++に入れるくらいなら俺はDを使うわ。

標準ヘッダーファイルの拡張子を無くしたときにやるべきだったな

>>784
標準の拡張子無しのヤツはヘッダっていうんじゃなかった？
自分で作ったらヘッダーファイルだっけね。

ヘッダはファイルである必要は必ずしもないという実装者を挑発するルールです

Windows使っている俺は、実際のファイル名をヘッダ名と同じにしないでくれと思っている。
具体的に言うとファイル名に拡張子ほしい。<ios>でios.hppを探しに行くような感じで。
拡張子のないファイルは扱いが面倒臭い。

関連付け以外にも、色分けなどのために拡張子で種類を判別するエディタの多いこと。

ヘッダファイルにエディタへのヒントとして、ファイルタイプを書くか、
副次ストリームに書く。
エディタはそれを読んで判断。

ハードリンクでも張っとけばいいんじゃない？

副ストリームって最近冷遇されてる気がするなあ

><ios>でios.hppを探しに行くような感じで
でも結局iosのファイルの中身は
#include <ios.hpp>
だけだったりするんだよね

0xが正式に導入されたら、今ある入門書って買い換えなきゃいけない？

入門レベルなら大して変わらないかと

「対して変わらない入門書」なんてものは悪書としか言いようが無い。
C++標準化後にどれだけ旧態然とした入門書が悪影響を与えたか。

正式導入されたとしても、
結局 VC++ が無視したら広まらないんだろうな。
C99 みたいに。

既にTR1入れてるぐらいだし、比較的早めに0x対応するのではないかと楽観視している

STLの書き換えがダルそうだよな
俺らは使うだけだけど

どうせ書くのはdinkumwareだろ
MSじゃなくてさ

まあ TR1 くらいなら特にコンパイラいじる必要もないから簡単に入れれるけど、
言語仕様に手を入れるのはどうなんだろうね。
VCEE の C++ の力の入れ具合が 2005 で微妙だったのが（デフォでは Platform SDK なし）
2008 で微妙に改善されたので（デフォで Windows SDK あり）
もしかしたらやる気があるのかもしれない。

>>799
TR1だってispodとかコンパイラに手を入れないと無理なのもある。

ところで、もしVC++がExpressだと0x使えないって言われたら
喜んでStandard買いそうな気がしてならない。
そんときゃg++で我慢すればいいはずなのに。

で、結局入門書は買いなおしたほうがいいんだな？

しばらくは取って付けたような入門書ばかり出るんだろうけどね。

入門書なんてvarとshared_ptrあたりをさわるので精一杯じゃね

var じゃなくて auto じゃね

autoとヌルポは絶対教えるだろ。
あとはinitializerでのコンテナ初期化と範囲forとか

どうせ数ページ書き直しただけで「C++0x対応・全面改訂版」とかって帯付けて売るんだぜｗ

欄外に「新しいC++の規格ではこのように書くことも出来るようになりました」って注釈つけて終わりにしたりな

D&E 2015年版が出るなら絶対買う。

地味だけどlong longは間違いなくとり上げられる。

>>799
けどC++/CLI蹴られたし、ISO C++からは離れるかもね。

>>809
型の種類と値の範囲の表をちょっと増やすだけだもんなｗ

個人的にはUTF文字列をまともに扱って欲しい

美少女中学生にしてみれば下着の種類が増えるだけだからな
外に出るときの見た目は変わらない

対応したコンパイラって、すぐ出るのかな？

gccとか既に一部対応してるから、規格になることには全部対応してるんじゃね？

ふむ。
gccぶち込んでみるかな。

139 名前：デフォルトの名無しさん[sage] 投稿日：2008/06/11(水) 20:50:38
どうでも良いが個人的にまつもと氏に0xに改善されても尚C++が問題外かどうかを訊ねたい。

>>816
もっとだめと言うに100万ペリカ

ところで初心者向けと言えば、やっぱりテンプレート絡みの
エラーメッセージがまともになるという1点においてコンセプトが
一番簡単にアピールできる機能だと思う。
コンセプト自体は、入門書で取り上げられるような内容ではないだろうけど。

禿は0xむけに第4版出すんだろうか

第4版よりD&Eの第2版がほしい

D&Eの続編書いて欲しいな。別の本で。
>>693のGregorとか。
一人で大幅な改訂してる暇はたぶんないだろ。
WG21 papers、かなり名前出てくてるからな。

Wikiを読んでいると、「うざくなって？」って、思えてきたのですが、
そんなことない？

日本語でおｋ

美少女中学生が携帯で書き込んでいるようだな

>>823
ぼっぼくと付き合ってくださいっ！

>>824
文脈的には>>821が美少女中学生だと思う

TC++PLやD&Eの続編って書く予定ないのかな と思って禿のページ見に行ったら
なんかいまC++の入門書書いてるみたいだね

VCって、どこまで対応させるのかな〜？

>>825
おお、それは期待したい

テンプレートだって未だにまともになってないのに
そこにコンセプトなんか追加したらどうなることやら

「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」と書き込もうとしたけどやめた。

やめろよ

「もう美少女中学生とかどうでもいいだろC++0xの話をしろよ」っていう書き込みを見て「やめろよ」と書き込もうとしたけどやめた。

C++0xは美少女中学生萌え言語ですよ？

C++0xと美少女中学生には全く関連性がありません！
両者が結びついているかのような書き込みは控えてください！迷惑です！
ここはC++0xのスレッドです！C++0xの話をしてください！
美少女中学生の話がしたければどこかよそでやってください！

えぇーまじでぇー

C++0xなら美少女中学生なんてコンパイル時にゲットできる

NGワード : 少女

>>835
コンパイルに何年かかるんだ？

>>828
コンセプトが追加されてはじめてまともになるんじゃないか。何を言ってるんだ

>>838
紫の上のコンパイルはたった４年です。

>>784
拡張子をなくした理由ってなんだろ？

>>792
いつまで入門者でいるつもりなのかなー

>>840
ヘッダはファイルである必要は無い
とか言えるようにするため。

.hまで含めて名前です。とかでもよかったじゃん。

互換性を失う変更を導入するための苦肉の策だったのだと思う

名前空間の無い時代に

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

とか書かれたプログラムが大量にあってだな・・・。
それとの互換性を考えると名前を変えざるを

ほんっとしがらみいっぱい過ぎだよな。

互換性無視してしがらみ全部捨てたC++欲しいよな。
特に暗黙の型変換辺り。

ちなみにDなら不要だよ。

Dは自分でしがらみ作りまくったりしてるからな・・・
時には思い切って捨てたりしてるけど（信者を）それが逆にしがらみになってる。

>>847
仕様だけでも作ってくれ

>>847
暗黙関係はトラブルの元だからどうにかしたいな。暗黙関係は警告を出すオプションが欲しい。
デフォルトのコピーコンストラクタが作成できませんなんて余計な警告はあるのになんでないんだ？＞ＶＣ８

明示的なメモリ管理ができないC++とか
その場合でもmove semanticsは面白いこと出来ると思う。

暗黙の型変換を全部禁止したらどうなるのかな
double d = 1;
とか
Base *b = new Derived();
とかが全部エラーになるんだよな

アップキャストは安全なキャストだから禁止する必要もあるまい。

安全だろうと何だろうと、何かの暗黙の変換を認めたら
あれも認めろこれも認めろと言うキチガイが出てくるので全て禁止です

そういう思想で作られてる言語ねえのかな

OCaml は結構型に厳しかったと思う

double d = 1;
は実質
double d( 1 );
と同じだから明示的な変換を表しているんじゃないか?

暗黙的なコピーコンストラクタの実行をやめてくれって話じゃなかったのか

explicit でおkだっしょ

デフォルトのコピーコンストラクタはどうかなあ。

ああ、コピーコンストラクタの話か。
0x 的には = delete してくれってことじゃないのかな。

組み込み型の暗黙の型変換が結構うざいんだよな。
特にポインタ、文字型、論理型が整数様型と絡むと。

explicit をデフォルトにしてほしかった。

schemeみたいに簡単に方言作れるkitがあればいいのにな。

>>862
それはよく思う。
でも、今更変えらんないんだろうなあ。

Javaはreflection APIがあるから、
言語拡張＆コンパイラ実装の研究がどんどん進んでいるね。

セックスプリプリシット？

虚しいオッサンの虚しい書き込みが続いております

>>865
OpenC++の中の人も今はOpenJavaやってるね。

クラスの内部ポインタを交換するような例外安全な swap を書くとき
それを std 空間に template <> swap( .. ) と逐一定義しないと std::swap から呼ばれない。
理屈はわかるんですけど、なんとかならないですかね。
一々 namespace std { template <> swap( うんたらかんたらと書くのが面倒くさいです。

クラステンプレートならどうにもならない

自分の場合は using std::swap してから swap() を呼び出しているので
クラスと同じ名前空間に swap() を定義している。

swapなんか使わない設計にしなさい

そうですね。
これからは右辺値参照の時代ですもんね。

swapを使おうとする前に、一度立ち止まって
自分が値をあべこべに格納していないか考え直しなさい

　　　　　　　　　　　　　　　　　Bjarne Stroustrup

>>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 さえあれば良いということは必ずしも言えないかと思います．

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); }

↑ こういう感じのってダメなの？よくわからんけど…

>>876
template<HasSwapFunction T>
concept_map Swappable<T> { void swap(T &x, T &y){ x.swap(y); } }

多分，こんな感じで concept_map で差異を吸収したほうが楽なのではないかと．

交換も、コピーコンストラクタや代入演算子と同じように扱えばシンプルになると思うんだけど
・デフォルトはクラスが定義するswapを実行する
・swapが実装されていなければ、言語側で一時オブジェクトを作り処理する
とできないのかな
実装で埋めようとして複雑になっている印象がありますが

Namespace issue with specialized swap
http://groups.google.ca/group/comp.lang.c++.moderated/browse_thread/thread/b396fedad7dcdc81

for文の改良ってしないの？

foreachってC++0xになかったっけ？

入ったよ。
for (int &entry: aContainer) { ... }

Javaのクロージャを引数に取る拡張に比べるとつまらない。>>48
C++的には最悪のセンスだと思う。

Javaから構文パクるなんてC++も地に墜ちたもんだな

まあでもC++にeachとかinとかのキーワードを入れるのも有り得ないだろうし、
これくらいしか書きようがないと思う。

ところでこのループ変数は参照なの？
参照が指す先変えながらグルグル回るの？

キモッ

別にキモくはないだろ。
従来の、for無いのスコープで参照変数を宣言してるようなもの。

for (int &&entry: aContainer) { ... } はあり?

ぅん・・・

昔々、Sunにとある厨が居た。
彼はＣ言語の研修でポインターでつまづくような無能で、無論Ｃ＋＋など理解出来なかった。
プログラマーとしては全く使い物にならんということでネットワークエンジニアとして使われていた。当然役には立たなかったが、サーバー運びや配線や小間使いぐらいは出来た。
この世にポインターがあるから自分がそんな境遇に陥ったのだと不満を募らせた彼はポインターを憎悪し、ポインターの無い言語があればいいのに、と夢想するようになった。
彼はその夢想言語をJAVAと名付け陳腐な企画書を出したが、すべて無視された。
そんなある日、どうせ役には立たないんだからと、しつこいNetscape社の営業を追い払う仕事を任された。もちろん権限は一切なく、ただNetscape社の営業の話相手をし、すべてを断るだけの仕事だ。
彼は毎日のようにNetscape社の営業と無駄話をした。彼にとってそれは、愚痴や不平不満をこぼす絶好の機会だった。
Netscape社の営業は当然のように彼に同意した。彼の境遇に同情し、彼の才能を認め、褒め称えた。
そして誰も耳を傾けなかった夢想言語JAVAの話になるとNetscape社の営業は強い興味を持ち、ブラウザーに搭載したいと言い出した。当時のNetscape社は、動きのあるページを作る案を求めていた。
夢想言語JAVAが現実のものになる。彼は天にも昇る気持ちになり、全面的に協力を申し出た。が、やはり何の役にも立たなかった。すべての設計、策定、実装はNetscape社によって行われた。
Netscape社は、夢想言語JAVAを「何処でも全く同じに動く言語」としてブラウザーに搭載しようとしたのだ。
これを聞いて驚いたのはSunの役員達だ。直ちにNetscape社と交渉し、JAVAはそもそもSunのものであることを主張し始めた。
交渉の結果夢想言語JAVAの最初の実装はJavaScriptと改名することになり、SunのJAVAとは独立したNetscape社の言語となった。

Sunは直ちに「何処でも全く同じに動く言語」の現実性を調査し、仮想マシンを使うことで可能であることを検証した。
また夢想言語JAVAの詳細を厨に尋ね、規格をまとめ……ようとした。というのは、厨の頭の中には「ポインターを使わない」の他には支離滅裂な妄想以外何も無かったからだ。
役に立たない彼を「夢想言語JAVAを広める為の広報」に追い出し、夢想言語JAVAではなく現実的なJAVA言語の設計が行われた。
だが現実的設計にはいろいろと難があった。その度に開発部は厨に尋ね、その意向を可能な限り反映する努力を行った。しかし無能な厨の意向を反映することは困難を極めた。
その中で最も大きな障害となったのが、多重継承の禁止である。
未だにSunは公式に認めていないが、JAVAが多重継承を禁止する決断をさせたのは、実はMicrosoftの寄与するところが大きかった。
Microsoftは既にMFCとCOMによって多重継承が抱える問題を解決していたからである。
その後も厨は（何度出入り禁止を喰らっても）設計に口を出し、そして開発部はその意向を可能な限り反映する努力を行ない続けた。
特に厨が主張するコーディング規約は支離滅裂を極め、ゴスリンは「それまでに書かれたコードを書き直す量が最も少なくなるコーディング規約」をまとめる必要に迫られた。
この時にまとめられた何の意味も無いコーディング規約は後に、それを知らなかった企画部によって改めてまとめられJAVAの標準のコーディング規約として発表された。
ゴスリンはこの時の心境を「JAVAが最高だと生涯言い張り続ける覚悟を決めた」と述懐している。
厨は熱心に広報活動を行っていたが、役に立ったのは最初だけだった。すごい言語が出来る、ということを印象付けた後は、何の役にも立たなかった。
開発には近寄ることすら許されず、広報からは役立たずの烙印を押された。彼は再びネットワークエンジニアとして保守管理部に戻った。
今では彼は毎日何百ものＬＥＤを見張って、消えたらそれに対応するハードディスクドライブを交換する仕事をしていると言われている。名前は記録されていない。

ついに参照の指し変えが認められてしまったのか…

>>875
valid resourceless state てなーに？

Java の参照型はまさにポインタだろうが・・・。

NullPointerExceptionがあるしな

Javaの参照型はインクリメントできる？

>>893-895
ネタにマジレスｗ

マジレスもできない奴は板を替えたほうがいい

ネタにマジレスするのが最近のトレンドなんだぜ

ネタに、というよりホラにマジレスだな

>>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 の観点から見てやや大きな弱点を生じるように思います．

長い
3行でまとめろ

>>891
forの繰り返しの度に初期化が行われているとみるべきでは？
例えが悪いかもしれないけど、今だってBOOST_FOREACHでは要素を受ける変数の型に参照が使える。

ホラも技術レベルが低いのはつまらない。

>>900
右辺値オブジェクトからの move を保証するために決めたって感じだな。
RAII については、どうせ unique_ptr や shared_ptr その他スマポ使うこと
になるからあんまり問題にならないんじゃない？

そもそもグローバルヒープが制限されてるウチみたいな環境じゃ、
あまり MoveSemantics の恩恵にあずかれなそうだが。
あーでも ScopedAllocator 使えればちっとは便利になるんかな...

別にムーブするのが記憶領域と限られてるわけじゃないんだから、
環境はあんまり関係ないんじゃないの。

くだらんが馬鹿にウケるホラははびこるからたちがわるい。

まだ889, 890の話してんのか

>>894
>NullPo・・・

なんでNullReferenceExceptionにしなかったんだろうな

>>908
ガッ

std::basic_stringが異常に使いにくい点
std::exceptionがstringしか使えない点
はどうなるの？

>>911
> std::basic_stringが異常に使いにくい点
何の話？

> std::exceptionがstringしか使えない点
what() のことなら、変わらない。
UTF-8 なりシステムデフォルトなりにエンコーディングを決めて詰め込むのが正解。

whatはエラー表示部でgettextするのがいいと思う

文字コードの話じゃないと思う。
std::exception::what は wchar_t 文字列をキャストして返してもいいという仕様だし。

メモリ確保が問題だと思う。

>>914
> std::exception::what は wchar_t 文字列をキャストして返してもいいという仕様だし。

wchar_t 文字列に変換できるマルチバイト char 文字列、とか、そんな感じだったはず。
ここでいう変換はキャストじゃないと思う。

what はおまけ情報だし、受け取る側の文化も分からないから C の最小文字セットで十分じゃない。

たんに記号をつぶせば1バイトに文字が収まってしまう、貧弱な文字文化の人間が標準化委員会を占めていて、
国際化ということにまったく関心が無く、
「はぁ？　一文字は一バイトに決まってんだろ。野蛮な絵文字を使うアジアのイエロー達など知ったことか」
という意見が大多数を占めたために、こんな仕様になったんだろ。


まあ、実際のところは、当時はまだUnicodeなんて、
規格に入れるほど発達していなかったんだろうが。

年中反対ばっかりの野党議員みたいな情けないレスですね。

がっかりしました。

C++の例外は投げるほうからは受け取る側の情報はほとんど知らないから
exception はなるべくシンプルなほうがいいんだよ。

それより fstream のファイル名は wchar_t にも対応してほしい。

iostream関係は窓から放り投げて新しく作り直すべき。
まずロケールを廃止するところから。

C++0xが出たら当面はchar16_tとchar32_tの仕様強化を図ってほしいな。

>>921
localeとiostreamの関係は悪くないと思います。

VC がまともに C++ ロケールに対応できていないのは C 言語のロケールとの関係かな。

Windowsのモデルと合わないからでしょう。
POSIX/UNIXの方は、プラットフォームのデフォールト設定と、
プログラムの実行環境の設定が合致している必要がありませんが、
初期のWindowsのAPIの方は、合致している必要があったので、
より柔軟性の高いPOSIX localeモデルと組み合わせにくかったのでしょう。
C++はさらに柔軟性が高くなっていますから。(streamごと)

C++の標準文字列のデザインの悪さの一例。
・大量の文字劣苦ラスがライブラリ毎に量産されている点。


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

このようなものが次世代で生き残っていけるとは思えない。

落伍者は皆そう言って去っていったよ
君も元気でね

まあでもbasic_stringが糞なのはガチ。
かと言っても悲しいかな、今更どうしようもできない。

ArrayIndexOutOfBoundsExceptionなんて名前を平気で使ってる奴らが
タイプ量に文句付けるとかあんまり笑わせんな

>>928
せめて CString::GetBuffer 相当の関数が欲しいよね。

関数、じゃないや。機能、だ。
別に basic_string のメンバ関数にする必要は無くて
むしろ RAII なクラスを提供してくれる方がいい。

CStringはCStringでひっでえけどな
結局C++でまともな文字列クラスなんて作れないんだよ

そして結局char*が一番便利だということに気付くのでした

printfの便利さに触れると
<<なんてアホらしくて使ってられませんよねー

>>933
ただし、それはない。

ストリームに対して演算子を定義すれば
いくらでも新しい型を入出力に組み込めるんだから
<< >> の方が便利だろうが

でもさ、もしprintfの%を自分で再定義して同じことが出来たらもっと便利じゃね？

可変長テンプレートかなんか使ってprintfがもっと便利になって復活してくれたら
一生C++に付いて行くけど禿のことだから絶対ねえよなー

boostになかったっけ

>>934
俺も、昔は無理矢理iostream系使ってたけど、今はCスタイルがメインだ。

>>938
boost::formatのことかな

可変長引数を使いたくない とか
クラス型のオブジェクトも扱えるようにしたい とか
仮想関数を強制したくない とか
いう
理由があったんじゃないかと妄想を膨らましてみた時期が俺にもありました

C++0x で string の連続性も保証されることだし、
GetBuffer 代わりに str.resize(size + 1); して、
char* p = &str[0]; に文字列を書き込んで
ReleaseBuffer 代わりに str.resize(strlen(&str[0])); してもいいのか？

文字列クラスはメンバが中途半端な機能のしか無い割りにいっぱいあるんだよな

>>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;
}

+1 って要らないのかな。GetBuffer 的に考えて。

C++0x は std::basic_string s に対して s.data() より &s[0] の方がいいの?

s.data() は const char * 返すから
const_cast するのは気持ち悪いし。

.NETのStringって
非変更型の関数しかないけど
なんか理由あるの？

>>947
immutableだから。

immutableの方が何かと都合がいいから

C++でいうと

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

stringでコピーして共有するか選ばなきゃいけないわけだ。

効率より安全性を採用したわけね。

いやむしろ効率を重視してる。
immutableなコンテナはmutableにするための仕組みが不要だから高速化できる。
.Netのimmutable containerがそうだと断言はできないが、少なくともCocoaのFoundationはそう。

.NETはJIT前提だからね。immutableであることが判ってると、実行時にもいろんな最適化ができる。

ちょっとした処理が効率化されても
コピーが発生するのは致命的じゃないか？
メモリ確保も発生する訳で。

>>954
使いどころによる。mutableでも変更したら結局コピーやメモリ確保が発生する。
immutable containerの生成時は（それが他のコンテナに基づくものなら）内部データの参照カウンタを増やすだけかもしれない。

>>954
.NETでは頻繁に書き換える場合はStringBuilderというものを使う

boost::shared_ptr<string const> で immutable な string のできあがり？

なるほど。
使い分けてんのね。

D言語も2.0からimmutableになってたような

Dはinvariantとconstとmutableを使い分けられる変態言語

invariantって長いよね

言語にプログラムの解析を補助する機能を追加してくれないかな。
ドキュメント生成やリファクタリングのツールが作りやすくなるように。

んで.NETみたいに難読化ツールが必要になる、と。

コンパイルタイムリフレクションもほしい

>>962
テキストマクロを廃止するのが第一歩だろうな…

>>965
Javaみたいに味気ない言語になっちゃうなｗ
まぁ現状が残念なのは間違いないところだが

テキストマクロのかわりに文字列によるmixinを

それなんてD言語ってかんじだけど

D言語で導入予定のAST macroなんてどうだろう

これのP45〜ね。
http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

パターンマッチのドメインもはっきりしないしダサイです。
Dは全般的にセンスがダサイ。

Windowsライブラリなど各種ライブラリが充実していなければD言語なんて
使わない．しょせん，modula2のようにいつのまにか忘れ去られてしまう言語．

Dはコンパイラオタクが興味の赴くままに作ってる言語だから、
ライブラリにはまったく関心が払われてないな…

展開後に再度名前解決をやり直すんじゃなければ、
inline関数と違うのはパターンマッチだけじゃん。
そのパターンマッチもtemplate並なんじゃ、
全体の機能はtemplateよりもずっと貧弱。
よくこんな思いつきを付け足す気になるな。

concept_mapってコンセプトの特殊化だと考えれば、
concept_mapってキーワードは要らないんじゃないのかな?
コンセプトインスタンスごとに定義すればいいんだから。

引数評価はどうなってるんだ、Dのマクロ?
Lisp系言語のマクロの場合, 引数評価をコントロール可能なんで
マクロの意味があるんだが…

>>973
スライドでは、シンボルに$をつけると展開後に名前解決をする、と書いてあるようだが。

マクロが定義されたスコープと、マクロが実際に使用されたスコープの
二つだけ使い分けられればいいんじゃないの？ようわからん

ばーさんC++0xはまだいかな
待ってるうちにおら寿命が先に来ちまうでよ

>>974
もうちょっと想定している文法などを含めてｋｗｓｋ

要するに、
concept ForwardIterator<typename T> {
// なんだかんだ
};
concept ForwardIterater<int> { // concept_mapじゃなくて
// どうしたこうした
}
で十分じゃないかということ。templateがそうだもの。

>>962
VSに付いてる。

埋めようか++0x

まだあわてる様な時期じゃないさ

美少女中学生はうろたえないッ！

980越えたらいつ落ちるか分かんないよ

C++0x Part2
http://pc11.2ch.net/test/read.cgi/tech/1191754720/

があるから、これでいいんじゃね?

重複あったんなら再利用でいいな

いや、そこはダメだろw

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/

素マン間違えた

誰も立てないなら>>986再利用でいいよ

C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/

よし、埋めようか

そんなにあせらなくても

C++ に reflection は不要だな

コンパイル時のみテンプレートで、ならありうるんじゃないか?

それのどこがおいしいというのか?

>>995
実行時リフレクションはなくてもいいけど、
Dにあるみたいなコンパイルタイムリフレクションはほしい

コンパイル時リフレクションは非常にほしい

>>997
その発想は「ほげ言語のパラドックス」ですな。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。