C++0x 7

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/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/

>>1死ね

嫌です（^ε^）

C++0xがいつ規格制定されるかは、髪のみぞ知る。

C++学園の人々

○コンセプトさん
ついに一度も登校することなくお星様になってしまった。
この事件によって学園に激震が走り、入学式が一年延期になる事態に。
彼女の再起はあるのだろうか。

○ラムダさん
コンセプトさんに代わって新入生代表に抜擢されることに。
だが服が汚い上デザインが二転三転してるのでよくいじめられる。
コンセプトさんと同じ目に遭わないかと内心ビクビクもの。

○右辺値参照さん
一足先に本格的な通学を始めつつある新入生。
よく出来た子として先生方には評判が高いが、
気難しいので普通の生徒たちからは敬遠されている。

○拡張for文さん
forさんの妹。コンセプトさん問題の一番の被害者。
きったない服で通学することになりテンションガタ落ち中。

○type_traitsさん
ライブラリ科の新入生。
コンセプトさんの代役としてにわかに注目を集め始めた。
思わぬスポットライトに浮かれすぎで最近テンションがやばい。

○static_assertさん
type_traitsさんの相方としてこちらも注目を集める新入生。
面倒な相手との仕事が増えそうで最近憂鬱。
assertさんの妹だが、マクロ科と予約語科の立場の違いで仲が悪い。

○initializer_listさん
vectorさんが泣いて喜ぶコンテナ部悲願の新人。
だが似たような服を着た生徒が元から多いので、一部では
「またややこしい奴が来た」と陰口を言われているらしい。

○テンプレート可変長引数さん
テンプレ部が泣いて喜ぶ期待の新人。部の熱狂的な歓迎ぶりと
「変態が増えた」と嘆く周囲の温度差に困惑中。
stdargさんとは顔がよく似てるが血の繋がりはない。

○autoさん
地味で消えそうだった子が一転、イメチェンで今やモテモテに。
そのあまりの変貌ぶりに周囲は戸惑いを隠せない。
最近まで同じ立場だったregisterさんの胸中はいかに…

○decltypeさん
autoさんの妹の新入生。姉が記憶クラス科にいた過去は知らない。
姉に劣らぬ人気者だが、服装のちょっとした違いで性格が変わる面倒な一面も。

○ユーザー定義リテラルさん
「わかりにくい」「見るからにきもい」「関数さんでいいじゃん」と
すこぶる評判の悪い新入生。強く生きていって欲しい。

○nullptrさん
「今さら来られても……」「なんで今までいなかったの？」という
心ない陰口に傷ついている地味な新入生。

○long longさん
え？新入生だったの？

○禿
校長先生。

>>5-6
乙

> きったない服で通学することになりテンションガタ落ち中。

ここで爆笑した

・Raw String Literalさん
なんだかよく分からないアクセサリーを頭とお尻に付けている。
しかもアクセサリーは日替わり。

・auto_ptrさん
落第。一応、まだ学校にはいる。

・unique_ptrさん
auto_ptrさんを蹴落として進級してきた。

・Smart pointerさん
とても頭がいいが、循環参照も扱えるかどうかは、学校によって異なる。

・Unordered associative containerさん
いつも、とても大きなカバンを引きずっている。
ただし、カバンから物を取り出すのはとても早い。

・Regular expressionさん
頭は良いらしいのだが、何を言っているのかよく分からない。
周囲からは中二病だと思われている。

・Atomic operationさん
細かいことばかり気にしている神経質な子。
口癖は、「だってその可能性はゼロじゃないし〜」

・threadさん
カバンも持たずに登校してくるミニマリスト。
ペンと紙一枚あればそれで十分でしょと言い張る。
どうしようもないときは、魔法の言葉、「ねぃてぃぶ・はんどる〜」を唱えると、とりあえず何とかなる。

・type_indexさん
type_info君と仲が良いらしい。
噂では、いくとこまでいったとかいってないとか。
ただし、開校前のクラス分けで離ればなれになってしまった。

・System error supportさん
いじめられて転校してきたらしい。
たぶん、どの学校でも相手にされない子。
ほとんどの学校には、学校独自の、もっとマシな子がいるし。

・Tupleさん
博愛平等主義者。ほとんどのクラスメートと仲が良い。

・Binder姉妹(bind1st,bind2nd)
落第。一応、まだ学校にはいる。

・Function template bindさんと、Polymorphic function wrapperさん
二人とも、とても頭が良い。
なんでも、「ぶーすと」という一流の進学校から転校してきたらしい。
あまりに成績が良かったために偏差値を押し上げて、Binder姉妹を落第させる原因をつくった。

・Time utilitieさん
2038年問題も3000年問題も大丈夫と豪語。

・Compile-time rational arithmetic君
Time utilitieさんと仲が良いらしい。

だんだん説明が投げやりになってるなｗ

あとは擬人化だ
絵師を呼べ！

lambdaが消されることはまずないよ。
range-based forとかuser defined literalsは、このままだと問題が多いと思うけれど。

>服装のちょっとした違いで性格が変わる面倒な一面
括弧のことか。

>>12
user defined literals の問題って何？

>>14
ユーザー定義リテラルの名前は必ずアンダースコアから始まらなければならない。

ただし、アンダースコア二つ、アンダースコアに続いて大文字の名前は予約されているので使えない。
じゃあ、アンダースコア一つに小文字か数字ならオッケーかというと、
アンダースコア一つから始まる名前は、グローバル名前空間において、予約されているので、注意が必要。

だから、現行のドラフトを忠実に守ろうとすると、
ユーザー定義リテラルは、必ず何らかの名前空間の中で定義しなければならない。
そして、実際に使う時は、そのスコープの中で、using directiveやusing declarationすることになる。


けど、誰がそこまで深く考えるかね。
後々互換性の問題が発生しそうで怖い。

>>15
これか。
17.6.3.3.5 User-defined literal suffixes
> Literal suffix identifiers that do not start with an underscore are reserved for future standardization.

しかし
> じゃあ、アンダースコア一つに小文字か数字ならオッケーかというと、
> アンダースコア一つから始まる名前は、グローバル名前空間において、予約されているので、注意が必要。
これが問題になるとは思わんな。

たとえば int operator "" _x (int n) で宣言される literal operator の「名前」は
operator "" _x であって、 _x じゃない。じゃあ _x は何なのかというと、
literal operator の名前の一部となる literal suffix identifiers と呼ばれるもの。

literal suffix identifiers に _X や __x を使うと、処理系定義のマクロやキーワードに
該当してしまう可能性があるのでアウトだけど、 _x であれば処理系定義の ::_x が
存在しても２つの名前 ::operator "" _x と ::_x は衝突しない。

ただ、確かに「アンダースコアつけないとダメ」と言いながらアンダースコアと大文字は
アウトってのは _MB とかうっかり使っちゃう人が多そうで、いやらしいルールだとは思うね。

自前の名前空間内ならアンダースコア無しのやつを使えるように、
「literal suffix identifiers の予約はグローバルな literal operator だけ」って明示して
もらうといいのかな？

すると、そのLiteral suffix identifiersとやらは、nameじゃないわけ？

>>17
3 Basic concepts p4 より、 name の定義。
> A name is a use of an identifier, operator-function-id,
> conversion-function-id, or template-id that denotes an entity or
> label.

これによると、 literal suffix identifier は name じゃないね。

続く p8 にはこんな記述もある。
> Two names are the same if
...
> - they are the names of literal operators formed with the same
> literal suffix identifier.

この記述からも literal suffix identifier は literal operator の name の
一部であると考えられる。

>>16
_で始まらないユーザ定義リテラルが予約されるのはライブラリ的な都合ではなく
将来のバージョンのC++における字句解析の都合じゃないんかね。

>>19
そういう用途も考えられてるかもしれないけど、たとえばライブラリ内の
クラスである std::string を返すようなユーザ定義リテラルを字句解析の
レベルに置くようなことは考えにくいわけで、ライブラリ的な都合ではない
と言うのは当たらないと思う。

そもそも、名前の予約がライブラリ的な都合なのか字句解析の都合なのか
というところは使う側にしたらどうでもいいような気もする。

>>18
でもさ、13.5.8にこう書いてあるんだよね。


13.5.8 User-defined literals

literal-operator-id:
　　operator "" identifier

1 The identifier in a literal-operator-id is called a literal suffix identifier.

これは、普通に解釈すれば、
literal suffix identifierであると同時に、identifierでもあるんだよね。

ということはやはり、nameなんじゃないの。

何にしても名前空間内にあるかどうかで特別扱いするのは無理だろう

>>21
literal suffix identifier が identifier なのは当然だけど、
identifier 単体が name であるためには、 >>18 で挙げた定義により
その identifier が "an entity or label" を示すものでなければいけない。

entity は、同じく 3 Basic concepts p3 で以下のように定義される。
> An entity is a value, object, variable, reference, function,
> enumerator, type, class member, template, template specialization,
> namespace, parameter pack, concept, or concept map.

int operator "" _x (int n) という宣言があっても、 _x という
識別子だけでは "an entity or label" に含まれるどれも指さない。

従って _x は（少なくとも Basic concepts で定義される範囲では） name ではない。


17.6.3.3 Reserved names では name の意味が Basic concepts で定義される
ものとは違うようで、ここにも混乱のもとがあるみたい。

アンダースコアひとつに小文字か数字の名前は、グローバル名前空間において予約されているに過ぎない。
だから、何らかの名前空間の中で使う分には、規格上、まったく問題はない。

問題は、user defined literalsの性格上、名前空間の中に入れると、使うのが面倒になるということだ。
なにしろ、ADLなど働きようがないからね。
すると、使う際に、using directiveかusing declarationを使うしか方法がない。

更に厳密に考えると、using directiveを使うのも問題になってくる。
処理系は、ユーザー定義リテラルに使える名前はすべて、グローバル名前空間で使っている可能性がある。
それこそ、処理系は独自のユーザー定義リテラルを提供することだって、規格上、合法かつ安全にできるわけだ。
using directiveを使うと、名前が衝突した場合、曖昧になってしまう。

すると確実に安全なのは、using declarationを使って、一個ずつ宣言していくしかない。

// 処理系は、独自のユーザー定義リテラルを、グローバル名前空間に提供しているかも知れない。
int operator ""( const char* ) _a ;

namespace foo {
int operator ""( const char* ) _a ;//実際のライブラリでは、もっとたくさん提供されている。
}

void f() {
// using directiveを使うと、実際に_aを使おうとした時に、曖昧でエラーになる。
using foo::operator "" _a ;// 以下、必要な名前を、いちいち全部列挙。

auto a = "ハーゲー　パーゲー　こんなのやーだー　髪の毛　去ってゆくー"_a ;
}

現行規格を真面目に守ろうとすると、簡単のため、ライブラリ側で、必要な複数のusing declarationに展開されるマクロを提供されるのが一般的になると思う。
ユーザーは、おまじないとして、関数内などで、そのマクロを先頭に記述することになるだろう。
最悪なのは、Joe Coderがこの辺のことをわきまえず、規格違反のコードが世にあふれ、後のリテラルの規格改定に影響を及ぼすこと。

>>23
あー、たしかにuser defined literalの識別子だけでは、entityたりえないようだなぁ。
すると、user defined literalの識別子は、予約語の制約を無視できるという事になるのか。

>>25
「グローバル名前空間内の名前」についての予約名は無視できるけど、 >>16 に
あるとおり _X や __x はやっぱりダメなんで、微妙な隙間を使うことしか許されていない
という嫌な状況であることにはちがいない。↓この部分ね。
> 規格違反のコードが世にあふれ、後のリテラルの規格改定に影響を及ぼすこと。

ユーザ定義リテラルなんて演算子オーバーロードでDSLつくっちゃうような人らにしか使われなさそう

>>26
ごめん。なぜアンダースコア二つから始まる名前、及びアンダースコアひとつに大文字で始まる名前がダメなんだ？
user defined literalの識別子は「名前」じゃないんだろ？

>>28
そいつらは "reserved to the implementation for any use" ということで、
処理系定義のマクロやキーワードとして使われている可能性があり、
該当する場合はそもそも文法上の identifier として認識されない可能性もある。
その場合はパース時点で >>21 にある構文にマッチしなくなる。

それは処理系の都合であって、確かに、大方の処理系はそうだろうけど、
規格上は、関係ないのでは。何しろ、名前じゃないんだから。

いやまあ、もちろん、現実的には、回避した方がいいことには変わりないんだが。

>>4
もうない。

>>5-11
よそでやれ。

>>28
03 の頃から決まってる。

>>30
言いたいことがよくわからない。
「それは処理系の都合」の「それ」って何？
「大方の処理系はそうだろう」の「そう」って何？
「規格上は、関係ないのでは」の「関係ない」って何と何の話？

リテラルなんてconstか#defineして使うものなんだからユーザー定義リテラルって要らなくないか？
直接コードにリテラルを書くと保守性が悪くならない？

>>33
ひとつ上のレスに対してのレス。
現実の処理系の実装どうあれ、
規格上では、名前に対しての予約語であるから、
user defined literalにまでは及ばないという話。

>>35
>>23 の最後にも書いてあるけど、 17.6.3.3 Reserved names では "name" が
マクロ名も含むなど、 Basic concepts で定義される "name" と違う意味でも
使われている。このため、厳密に読もうとすると、破綻している。

name の定義が見直されたのはわりと最近で、以前から identifier と name は
混同されがちであったことから、その混乱の一部と考えられる。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#485
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#719

C99 のほうを見ると "7.1.3 Reserved identifiers" となっていて識別子に
ついて予約が行われている。これに倣って C++ の 17.6.3.3 も全面的に
書き直すのがよさそう。

そもそも name と macro name がオーバーラップしない別物として定義されて
いるあたりも問題な気がする。

>>36
たしかに書き直して欲しいね。

Intel C++ compilerのバージョンがあがって、
C++0xがどれだけつかえるのかと思えば・・・
あんまりだね

Windows7対応かとおもったら、ビルドした実行プログラムが
とまってたやつ修正だけか

>>38
intel c++ 11.1のhelpにはrvalueが使えそうに書いてあるので、試したけどどうもうまく動かないのはなぜ？
class A
{
int a1;
int a2;
};

void test(A&& s) //ここの2個目の＆でエラーが出る。
{
}

>>39
右辺値つかえそうな記述とかあった？ないと思うよ
autoとラムダぐらいじゃないの？
テンプレートらへんも全然だったし・・・

「rvalueが使えそう」「右辺値つかえそう」
これじゃ意味がわからんだろ。右辺値参照って言えよ。

>>40
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

http://software.intel.com/en-us/forums/intel-c-compiler/topic/68087/
＞ we'll be supporting the rvalue feature in our next major release.
だそうだ

訳 : おにいちゃんおかえりなさい！

>>42のR-Value Referencesや、ヘルプのQstdの説明にrvalueの文字が見えたのてっきり使えると思ってました。
次のバージョンでサポートされるんですね。
コードに突込みが入らなかったので使い方はそれでよさそうか。

ありがとうです。

>>36
オーバラップうんぬんはどういうこと?
名前空間的な話?
そんなのいまさら変えられないでしょ。
予約語をきっちり定義すればいいだけの話。

>>46
常識的に考えて "name" ⊃ "macro name" なんだが、 C++ 標準規格の中では
それらはまったくの別物であって、わかりにくい、ということ。

つまりマクロ氏ねと
初心者の頃にCreateWindowでハマった数日を返せと

話の流れぶった切るけど
constexpr があれば static const の代替としても使えるのかな？

あと、In-class member initializers は無名クラスの
メンバー初期化にも使えると考えてよい？

constexprはメモリ上にどの様に配置されるかは実装依存だがコンパイルタイムに計算が終了するので速い。
static constで修飾したものの完全な代替として使えるわけじゃない。

テーブルの生成に使うのが一般的なのかな

constexprに基本的な数学関数が含まれるとうれしいんだが。sinとか。

>>52
言語の枠内でconstexprとして実装できない以上、
ライブラリ関数の仕様として要求すべきじゃないんじゃないかな。
コンパイル時に計算されてほしいってだけなら、
最近のgccはmfprだかgmpだかを組み込んで出来るようになってるみたいだね。

近似式で書かれた関数csinとかを用意すればコンパイラが計算してくれないかな。

多項式近似と引数剰余で何とかなるといいね。

kbk氏はUsenix88-lexic.pdfは知ってるのかな？

>>41
意味わかってくれてありがとう

>>54
ぶっちゃけPerlとかで定数埋めたソースを生成した方がマシだと思うな
というか、boostのソース眺めてたら実際に生成用のPerlが落ちてて笑った

constexpr再帰が認められれば級数計算も書けるはずだ

それ許可するとconstexprでメタプログラミング始める人が出るから危険。

constexpはそもそもメタプログラミングなわけだが。

どうせテンプレートで再帰できるんだから、constexprの再帰も認めてしまえ、むしろこっちのほうが見た目は自然っていう意見を見たことがある。

普通はそう思う

コンパイル時にステップ実行ができるデバッガーが欲しくなるね。

C++プログラマは副作用のないプログラムに最適のデバッガも使えなければならない。

>>59 収束しないと永遠にコンパイル終わらないんじゃないか？

なるほどなconstexpr関数が終了することを保証する必要があるんだな。

適当に精度を決めればおｋ

ifかmatch withが必要だな

条件演算子があるから大丈夫

constexpr fseries_impl(double x, double part, double next, double epsilon, int k){
return (next>0?next:-next) > epsilon ? fseries_impl(x, part+next, f(x, k), epsilon, k+1) : part;
}

//Σ[k=0...∞]f(x,k)
constexpr fseries(double x){
return fseries_impl(x, 0, f(x,0), 0.000000001, 0);
}

意外と面倒臭いすなあ

>>71
そんなもんじゃね

そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか

minテンプレート関数が最初の例題。
char,int,float,double用に関数を何個も作らなくてもいいんだぜ！えっへん

それMPLじゃなくね？

Generic Programming
Template Metaprogramming
Boost.MPL

どれも日本語の情報少ないよね。

>>75
template<typename T, typename U>
result_type min(T x, U y) {return x < y ? x : y;}
さて、result_typeの部分にはなんと書いたらいいんだろうという話から始まるんだよ、きっと。

C++ Templates: The Complete Guide
と
C++ Template Metaprogrammingは原著で我慢するから、
C++0x対応のテンプレート本が出たときには早く和訳してくれ

むしろその二つを和訳するから0xのテンプレート本は我慢してくれって雰囲気だな

ごくふつーのメタ関数の書き方を何通りか紹介すれば大体分かるんじゃね＞MPL

そのごくふつーのメタ関数を、理解させて、書けるように教えるためには、
C++ Templatesぐらいの厚みのあるページ数で解説しないといけないわけだが。

そうかなぁ
割と典型的なパターンは決まってる気もするけど
まぁパターンで教えちゃっていいんですかって話ではあるけど、関数の呼び出し規約
とかしっかり把握させる教科書も無い訳だから別にいいような気もしたり
ってのはちょっと話が違うか

普通にCの処理書くのとは考え方が根本的に違うからな
再帰使いまくりだし

そうかまず関数型言語を教えるところから始めないと

Modern -> MPL -> 関数型 とたどった俺が通りますよ

確かに関数型の初歩的な知識くらいは最低限欲しいな

>85
俺漏れもー。

でも一から MPL するならともかく Boost.MPL の上に乗っかっちゃえば
大分楽になるし割と適当でも何とかなる気はするんだ。

MPL と TMP を混同して意味不明なこと書いちまった。

スレタイ0xのままでいいのか？
16進数？

今年が終わったら1xにしてくれ。
ちなみによく間違われるが別に16進数という訳ではない。

間違われるんじゃなくて規格策定の遅れを揶揄されてるんですよ

36進数で平成33年に制定予定。

>>73
> そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか

板違いだろ、このカス。

まあ、MPLはやり過ぎだとしてもだ、メタプログラミングは必須だぜ。
まともな日本語の参考書なんてでるかねぇ。

C++ Templates: The Complete Guide が積読の山からでてきた
これマスターしたら俺もBoostみたいな変態ライブラリ書けるようになるん？

他にもいっぱいマスターしなきゃならないよ！

現状のTMPは知れば知るほど深みに嵌ってソースが難読化してくのが・・・

http://gcc.gnu.org/ml/gcc/2009-09/msg00507.html
最近gcc lambda brancheが頻繁に更新されていてまさか、と思ったけど
ついにメンテナ自ら4.5にマージするつもりであることを発言したね

gcc は元から関数内関数が実装されてたから、そこらへん流用できたのかな？

昔の実装（Usenix88-lexic.pdf）って、関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
lambdaってそのへんどうなの？

> 関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
それじゃ lambda の意味がないだろ?

lambda expressionの評価結果のclosure typeはcopy constructibleな関数オブジェクト
nested functionとは別物

>>99
関数内関数なんて、
デバッガのためのシンボル情報処理以外、実装は極めて簡単じゃん。
lambdaはずっと実装が難しい。

いらねーな。

意外と早かったな
conceptGCCの二の舞を恐れて急いでたのかな

そこだけVC++に先を越されてたからだろ

lambada関数は関数ポインタと関数オブジェクトのどっちで返されるん？

関数オブジェクト

ありがとう
すると、コンパイラの最適化もかかりそうで嬉しいな。
どんな型の関数オブジェクトか分からないけどautoで受ければいいから問題ないか。

lambdaで作られる関数オブジェクトのoperator()はインライン関数扱いみたいだしね
オーバーヘッドは最小限に抑えられるだろう

なんかlambdaの認識が弱いスレ住民が結構多いみたいだな
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf
lambdaだけなら大した分量でも無いから、paperあたろうぜ

仕様はコンパイラとのガチ勝負で覚えるのだ。

なんで、lambdaをオブジェクトにしたかなぁ。
static領域やらスレッドローカルストレージでも利用して
関数に偽装してくれりゃよかったのに。typeidやらbad_exceptionだけでも、
ライブラリ依存の機能はうんざりだったんだが。

そりゃキャプチャ持ってるからだろ

関数のコードとインスタンスは別だよ。

>>113-114
　それを知ってての上の話。
例外機構も事実上ライブラリ依存はしてるけど、
からくりを言語コアに封じ込めてるでしょ。
あんな感じにしてほしかった。
もっと言えば、昔BCCにクロージャーって機能があったが
あんな感じ。

関数オブジェクトがインライン展開されて丸儲けとしか思えないが、
何が問題なのか分からん。具体的に問題点を例を挙げて説明してくれ。

>>112
逆に考えるんだ。言語機能によって生成されるオブジェクトにアクセスするための
インターフェースとしてライブラリがあるのだと。 sizeof と size_t みたいなもんだ、と。

ところで、lambdaってライブラリ依存なんてしてるの？
型もオブジェクトも完全にコンパイラ内部で生成されてて
ヘッダのincludeもランタイムのリンクも必要無いよね

operator()すなわちライブラリって考え？

>>116
　ライブラリであるという事は、コンパイラが他の
クラスと同様の最適化しかできないということ。
　functionalオブジェクトを引き渡す相手がテンプレートなら
インライン展開できるかも知れないが、相手が別リンケージに
いるならそれも不可能。さらに、配列に放り込むにもポインタでは
無いので、次の式みたいに関数のポインタと混在させて利用する
なんて事も不可能。
void(*p[])()={function,[](){}};

>>119
ライブラリじゃなかったら別リンケージでもインライン展開出来るという根拠は？
関数オブジェクトでもLTOが発達すれば特に劣る理由は無いと思うし、
関数オブジェクト一般を扱うコードとの親和性が高い分マシ

下の例はstd::function使った方が汎用性があるよね

で、結局関数オブジェクト以外のどういう実装でどう差が出てくるんだ？
現時点だとEmbedded C++信奉者の方がまだまともなレベル

>>119
実装とベタベタに相互依存した最適化をすればいいだけじゃん
標準／準標準ライブラリあたりにはよくあること

どうせ
std::initializer_list も range-based for-loop も
実装依存した最適化されるんでしょうし

>>119
リンク時コード生成でインライン展開可能だよ

関数オブジェクトは最適化が期待できる。
関数ポインタは最適化の期待が薄い上に分岐予測の妨害になりやすい。
関数ポインタも関数オブジェクト(std::function)の配列に格納できるので関数オブジェクトと共存できる。
>>119　関数ポインタのメリットは？

生の関数ポインタは、間接性が全くなくて、そのアドレスに直接飛べるように
しなきゃならないから扱いが大変。

最近はスタックを実効不可にする例が増えてるけど、そうすると昔のgccの
関数内関数なんかは実行できなくなってるし。

「関数に偽装」って言ってるのが「関数そのものにしてくれ」とは別の意味なのだとしたら、
「lambdaも関数オブジェクトに偽装してるだけ」という可能性は考えないのだろうか

抽象的には関数オブジェクトが関数に劣る面は何も無いし、実装的にも融通は利かせやすい
んだから効率は上がりこそすれ下がりはしないだろう、普通に考えたら

関数ポインタの利点なら一番大事なのがあるだろ
Cのインターフェースに渡せること

Cのインターフェースに渡す自体が非効率的だからなぁ…
どうしても必要なら、関数オブジェクトでも効率そのままで渡せるし

なんか関数オブジェクトを魔法の杖みたいに思ってないか？

　最適化云々とは書いたが、実際そんなにパフォーマンスにはこだわってないんだがな。
テンプレート関数に引き渡すときは、インライン展開され関数のポインタに
引き渡されたときは関数の様に最適化されるといったところか。
　まぁ、ここまではFunctorと変わらないが更なる最適化は例外やらexportを
実装した狂人が考えるだろよ。lambda関数が内部で上位関数に対し
参照するポインタを定数に書き換えるぐらいやっても構わんだろうから。

　それより重要なのは、関数ポインタと互換性が有る点。
旧来の関数ポインタを使うスレッドを始としたコールバック関数に直接放り込める。
もちろん、関数ごとにラップしてやればFunctorでも使えなくは無いが面倒だろ。
それもlambdaが生まれたのと同様の理由で。

レガシーコードに渡すなら普通に関数を定義すれば良いんじゃないか
そもそも関数ポインタとして扱えてキャプチャと並列安全性を両立って実装出来るの？

Intel TBBとか見てると、C++0x lambdaはかなり現実のニーズに答えていると思うけどね
Appleのblocks拡張よりは好きだな

Cから呼べない関数もどきなんて何の価値もないからねぇ…
C＝レガシーって考えてるとしたら色々とズレてる

関数ポインタしか渡せない C のインターフェースに任意の関数オブジェクト渡す
なんて、「最適化」の範囲でできることなの？

汎用引数として void* が付いてるインターフェースならそこを経由させられるけど、
そうじゃなかったら追加の引数はどうやって渡されることになるの？
静的変数使ったりするの？

remove_ifに渡すlambda関数にオーバーヘッドがあったらそれこそ使えないだろう。

C++なんだから関数ポインタとかコールバック関数とかCのやり方にこだわる必要性を感じない。
稀な使用例のためにC++の仕様が後退するほうがデメリットが大きい。
コールバック関数が必要な場面なんか稀なんだからそのときにstatic関数を宣言すればいいとおもうよ。

C++に無名関数オブジェクトが必要だということは前々から言われてたこと

無名関数ポインタが欲しいなら、C1xに入れてもらえば良い
まともに実装可能で矛盾が無いならその後にC++に入るだろ

PODの要件緩くしたりunionも使いやすくしたり
Cとの連携は必要ないどころかC++0xでますます強化されてるんだけどな

ラムダもなんかの条件満たしたら関数ポインタになるようにすれば良かったんだ
POFとか言って

>PODの要件緩くしたり
これはCとの連携の強化とは逆の方向行ってるだろ

>>137
まだ、関数オブジェクトに対する関数ポインタのメリットが示されていない。

インタフェースの基本はCの関数だろ。あらゆるAPI、最新の言語でもそれを利用する。
そうでなければCOMの様な複雑なインターフェースを考えることになる。

>>140
で？
そんなところは局所化して一段ラップすれば済むんだから、関数ポインタに特化するような
規則を標準化する必要性にはつながらないでしょ？

>>139
思いつきで言ったのに反論されて、
粘着しているだけなんじゃないのかね。

こんなのを書いてみたけど、ラムダ式ってデフォルトコンストラクタを持ってないから使えないのか。残念。
template<typename T>
struct is_stateless {
  static const bool value = /*略*/;
};
template<typename S, typename F>
struct make_function_pointer_impl;
template<typename R, typename... A, typename F>
struct make_function_pointer_impl<R (A...), F> {
  static R func(A... args) {
    F f; // ←デフォルトコンストラクタが必要
    return f(args...);
  }
};
template<typename S, typename F>
inline S* make_function_pointer(F) {
  static_assert(is_stateless<F>::value, "The function object must be stateless");
  return make_function_pointer_impl<S, F>::func;
}

>>140
WindowsAPIはC呼び出しではなく、PASCAL呼び出し(stdcall)なんだけどな。

利点はもう一個あるな

関数ポインタは整数(intptr_t/uintptr_t)に変換して持ち運べる

コンテキストを保持する構造体無しで関数ポインタだけでクロージャを実装しろとか、
コンパイラ屋をなんだと思っているんだ

標準化の過程の中で、function pointerを通して扱えるlambdaを作る、
なんて案は提出された記録すらないんだから、もはやスレ違いだろ
http://pc12.2ch.net/test/read.cgi/tech/1173238573/
行け

何だと思ってるんだと言われても、現に関数オブジェクトなせいで使いづらくなってるだろ
むしろコンパイラ屋は何を考えてるんだといいたい

不可能ではないし。

ここでゴネて変更させようとしても
そりゃ不可能だよ。

>>147
> 現に関数オブジェクトなせいで使いづらくなってるだろ
？？？
たとえばどんなときに？
具体的に頼む。

関数オブジェクトの意味が分かってないだけなんじゃ、と思ってるのは俺だけだろうか

例えばこれが出来ない

qsort(a,100,sizeof(int),[](void*a,void*b)->int{return *(int*)a>*(int*)b;})

ここでqsortを出すとは、>>152のセンスに恐れ入った

アルゴリズムのヘッダが動かないと問題だと思うが。。。

C++のライブラリにソートないの？

ここで聞くなよ

>>152 それだと「 std::sort() 使え」でおしまいだな。意味がわからん。

「qsortに関数オブジェクト渡せないぞ！」とか言われても
「printfでoperator<<みたいにオブジェクト出力できないぞ！」とか言われてるような感じ。

>>152
CのヘッダーはC++では使うメリットが無いし。
#include <algorithm>
を使って議論しようよね。

たとえstd::sort()があったとしても、qsortも使えた方がいいに決まってるじゃん
std::sortはクイックソートじゃないかもしれないんだしさ

何もキャプチャしてないラムダ式くらい関数ポインタに暗黙変換してくれよ
出来るはずだろ

>>145
それって鼻から悪魔じゃなかったっけ

てか、FFIやら呼び出し規約やらでC言語関数の共用ができるとはいえ
所詮もともとC言語特有のものを他の言語であたりまえにサポートすると思うなよ･･･

他の言語ならそうだけど他ならぬC++だからな
Cとの連携はちゃんとしてもらわないと言語の意味がない

なんでgenericなstd::sortがあるのに、わざわざqsortを使わなきゃなんねーんだよ。
クイックソートであるかどうかにそんなに意味があるのかよ？

だいたい、クイックソートなんてこの１レスに収まる程度のコード量で実装できるだろうが。
もちろんgenericなクイックソートをな。

お前みたいなヤツはBoostに転がってるc_funtionでも使ってればいいだろ。

杞憂ですね。

彼、一人ですよね。レスが多いから多数派の意見なのかと不安になってくる

例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
qsortは中でmemcpy使うからね

というかラムダが使えないという話はqsortに限らずCのAPI全般での問題であって
いくらqsortを否定されても本題とは関係ないんだけど

>>162
lambdaがポインタでもオブジェクトでも後方互換は満たしてるじゃん。
新機能までわざわざCに追従させる意味があるんかいな。

>>160
qsort() なら実際のアルゴリズムがクイックソートだというのも間違い。
std::sort() と同じぐらいに実装は自由。

> 何もキャプチャしてないラムダ式くらい関数ポインタに暗黙変換してくれよ
これは、生成される関数オブジェクトの変換 operator としてあってもいいかもしれない。

追従はしなくていいけど、出来るものはなるべくするべきだろう
キャプチャ付きのラムダまで全部関数ポインタにしろとは誰も言わない

べ、別にCのためにlambdaを作ったわけじゃないんだから。勘違いしないでね。

C++の新機能をCのライブラリで使いたいってのが無謀じゃないのか。

>>166
> 例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
> qsortは中でmemcpy使うからね

qsort() が memcpy() 使うとは限らないし、 memcpy() 使うから速いというのも意味不明。

> いくらqsortを否定されても本題とは関係ないんだけど

ええと、「本題」が何なのかよくわからないんだけど、
「関数ポインタが欲しいところでも余計な記述無しに lambda を使いたい」ってことでいいの？

>>112 まで遡ると「lambdaをオブジェクトにした」のが嫌だって話が出てたんだけど、
その理由がこれだけのためってことなら lambda 式で生成されるものが
関数オブジェクトでも >>168 みたいな変換 operator があれば済むわけでちょっと
的を外してたかな、と思う。

>>171
その当然あるべき変換operatorが今の規格にないことが問題でしょ？

キミ以外の誰にとって問題なのか不明。

>>172
それが、>>163のc_functionだね。

今初めてc_functionの使い道が解った。こんなレアケースに対応する為のものだったとは。
boostスゲー

>>172
当然あるべきと思うかどうかは人による。そこを主張しても意味が無い。

関数ポインタへの変換 operator を追加することは妥当な提案かもしれないとは思うよ。

個人的には、一段ラップして済ませられるし、他の理由で結局ラップする必要がある
ことが多いから、要らないと思うけどね。

条件の規定とか、変換できる場合とできない場合の違いを一般のプログラマが
認識できるか、とか、いろいろ面倒な問題もあるわけで、費用対効果は微妙なところ
だろうとも思う。

　なんか議論が粘着っぽくなってるんでひとつ。
>>112 = >>119 = >>131は俺。
スレッド関数とかAPIの替えの効かない関数にポインタ
突っ込めるから便利と言う発言以外は別人なのでよろしく。
C++で代用可能なライブラリとか、整数型に突っ込めるとかも別人。

現行のラムダさんは見た目は悪くても素直ないい子なのに、
常人に理解されにくい一面を増やしたりしたらかわいそうだよね

ただでさえC++はバッドノウハウの塊扱いされてるんだからさ

>>176
その別人はカタコトの言葉しか使えないようだし
ほとんどの人にとっては区別がつくと思う。

lambdaを関数ポインタとして呼べるようにしろってのは無茶言うなとは思うが、Cとの連携が強化されてほしいというのはわかる。
pmf-conversionとか、friend関数をExtension Methodのように取り扱えたらとか妄想して今日も寝る。

つーかPODかどうかでmemcpyを使い分けるくらいは今時のテンプレートなら余裕だろ

functionalだってqsortにはつかえねーじゃん…

おまえらどんだけqsort好きなんだよ

一人だけだろｗ

あのgccですらqsortをstd::sortに書き換えを試みてるってのに
qsortが好きな奴なんて居るわけが無い

いや一人いる

それでもqsortが優れているのは
世界共通言語たるCの標準ライブラリに含まれてる由緒正しい関数だということ

世界共通言語たるC++の標準ライブラリに含まれてる由緒正しいstd::sortはどうなのか

Cで動かないコンピュータは事実上存在しないけど
C++が使えない処理系ならいっぱいある
世界共通言語とは言えないね

>>188
いっぱいある？昔はそんなこともあったように思うが、今だともう思い当たらないな。
たとえばどの処理系のこと言ってるの？

そんなにC信者ならC使ってりゃいいじゃん。

freestandingだってC++処理系だよ

いい加減Cの話はやめてC++0xの話しようぜ

http://cpp-next.com/
でDave Abrahamsが書いてる記事くらいの質の情報が
日本語で得られるようになれば右辺値参照もすぐに広まるだろうになあ

C++0xで日本語ページをぐぐった結果を見ると絶望的だな

おまえら詳しいんだろうから書いてくれ

>>188
お前の言いたいのは処理系じゃなくて環境だろ。

環境といっても職場やチームの環境だったりしてな。

>>189
俺も同感。今時の開発環境でCが使えるのにC++が使えない環境を
教えて欲しいと思う。そういった仕事が来たら調査しないで速攻
で断りたいから。

あ、Linuxのカーネルモジュールの場合とかはあるな。
でも、その場合はしょうがないって諦められるから心理的
ストレスは（俺の場合）殆ど無い。

一部の組み込みみたいにリソースの厳しい場合もEmbedded C++でしっかりカバーできおっと誰か来たみたいだ

C++が使える場所でもメンバーの大体はベターC的なコード書いてて
そういうモジュールを使わなきゃいけないってことはよくあるというか
そういう場合の方が多いがなぁ。

「いっぱいある」と言いながら具体的な例はひとつも出せない。下手な印象操作の典型だな。

Better C的なコードを書くような連中はlambdaも使わないだろうからどうでもいい

> Cが使えるのにC++が使えない環境
実行時コンパイルとか、マニアックな条件ならありえる。

TCCのことかー
あと、clangなんかも良いCコンパイラだけど、
C++コード生成はまだまだ実装されそうにないな

それにしても、スレに沿った話で盛り上がらんな

懸案のコンセプトは消えて、主要機能はあらかた固まってきて
あとはRange-based forがどんどん腐っていくのを見守るくらいしかないからなぁ

C++0xを使い始めるのはVC10の正式リリース待ち、っていう住民も多いだろうが、
実装されるものはBeta1の時点でほぼ確定しているし、gcc使いにはあまり興味の沸かない話だ

range-based for、大丈夫かなあ
conceptに禍根を残さないようにお願いしたい

誰かrange-based forさんの服を洗濯してあげて下さい

洗濯したら破れちゃったんですが

禿は破れたのを繕うの得意です

range-based for
いらねぇぇ
将来conceptの邪魔になりそう

forさん「妹なんていなかった」

gcc lambda branchが最終調整に入ったようだ
これなら残り24時間ちょっとのstage 1終了までのマージに間に合うはず
stage 1が終わったら新機能の追加は許されなくなるから、
残りのC++0x実装は来年の4.6もしくは5.0に持ち越しかな

というわけで、lambda branchがtrunkにマージされた
http://gcc.gnu.org/viewcvs?view=revision&revision=152318

gcc-4.5-20091001のスナップショットに入るだろうから、だいぶ試しやすくなるだろう

よかったねラムダさん！

C++1xはinline perl（プリプロセッサ用）が搭載予定！

さようなら Boost な lambda さん！

std::bind 向けに Boost.Lambda っぽいのも残るんじゃなかった?
std::placeholder::_1 とかいうのが。

そういえば、lambdaとbindって機能がダブってない？

switchとifがダブってると思うならそうなんだろう

ifとswitchで条件分岐がダブってしまった…
ガーンだな

9月号来た。
>14.10 Concepts [concept]
>removed.

Oh!

http://www.open-std.org/jtc1/sc22/wg21/
News 2009-09-30: The deadline for the next mailing is 2009-11-06
News 2009-09-30: The 2009-09 pre-Santa-Cruz mailing is available
News 2009-09-30: The C++ Standard Core Language Issues List (Revision 66) is available
News 2009-09-30: The C++ Standard Library Issues List (Revision 67) is available

Draft: n2960

落とせない

>>218
そうかも
一応、bind自体の機能はbindの方がlambdaのbindよりも高機能だ
stdcallやfastcallの関数もbindできる

コンセプトさんの埋葬が終わったと聞いて

コンセプトさんはコールドスリープ中よ

>>224
専門家だけあって強力なのね。

あのクソみてえな拡張for文の文言が入っちゃってるよ…

autoがあるんだから普通にループ回せよ
どんだけタイピングしたくねぇんだよ

拡張for文があることで何か不都合があるというのであればそれを指摘するべきですな。
あって困るものとは思えません。
新しいことがもう覚えられないとかそういうことですか?

>>230
このスレでも誰か言っていなかったっけ。
次にConceptが入って拡張forを作り直すとき、
現在の拡張forが（互換性のためと言って）邪魔にならないだろうかという懸念。

個人的には、std::for_each+ラムダの手もあるし、
あるいは、もう数年BOOST_FOR_EACHのお世話になってもいいと考えているけど。

名前が悪いってことだろ

どうせSFINAEやらtraitsを使ったやつは
次にConceptを導入するときに書き直したりすることになるんでしょ
for loopがその中の一つになっても別にって感じ

今の拡張forの状態だと
begin/end関数は適切に書きましょう、そうしないとひどいぞ！ってことではあるが

http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=152358
lambdaの影に隠れて、constexprも実装された件
これがはじめての実装だから弄るのが楽しみだな

とりあえず constexpr はまだ準備中ってところだね。
http://www.pubbs.net/gcc/200909/129886/
これからの発展を祈る！

BOOST_FOR_EACHとか書く奴が本当にBOOST_FOREACHのお世話になってるのか
疑わしい

仕事で使えるのはいつのことやら。
いじって遊ぶなんて意味ないんだが。

foreachに#defineするとかっこいいぞ

小文字にdefineしちゃうと「中身は実はマクロだから色々注意が要りますよ」感が
無くなるのがなぁ

BOOST_FOREACHEはマクロでの評価回数の罠を解決しているぞ。
でも、,の罠は引っかかるけどコンパイルエラーがでるから問題ない。

少しずつ間違えるのがナウなヤングにバカうけ？

俺はハッピーターン派

最近のコンパイラは18446744073709551616回未満のループなら展開しちゃうからforeachとか気にしなくていいよ

Win32 環境で gcc-4.5-20091001 使ってみた。

lambda は使えるけど、まだ関数構文の統合がされてなかった。
constexpr については今のところはあってもエラーにならないだけ。

まだも何もN2960ではまだ関数構文の統合は入ってないぞ

>>244
拡張sizeofもOKのようだ。

>>243
サーバプロセスのメインループで停まらないんですけど?

Conceptsを殺した上に今年中に作る気がないとかふざけ過ぎだろ。

キモい奴しか使わないゲンゴシヨウナンテイラネーヨ。

>>248
Conceptsあのままでも間に合わなかったが、
抜くことになって余計時間はかかることになった。

5年後には結局また入れることになるかもしれない文言を取り除いて調整する
不毛で後ろ向きな作業を見てるのは辛い

decltypeってどう読んどけばいいの？

俺はデックルタイプなんだけど

declared type of の略だからデクルタイプでいいんじゃない

でくれあーたいぷ

http://cpp-next.com/archive/2009/10/exceptionally-moving/
デフォルトムーブコンストラクタを提供すれば右辺値参照を使っていない
既存のコードでも高速化が期待出来る、ってことだったけど
例外安全との絡みで結構ややこしいことになってるみたいだね

既存のコードでバグりそうだなｗ

で、聞きたいが、遅延展開は仕様に入ってるの？

>>255
ムーブコンストラクタは魔法使いにしか使えないよ。

おいおい、定義体の遅延展開もないの？
どれだけ現場を知らないやつが、仕様作ってるわけ⁈
馬鹿どもが。

ラムダ式を使えば遅延評価的なことは出来るんじゃないの

#define LAZY(expr) []{return (expr);}
#define LAZY_T(type) std::function<type()>&

void foo(bool b, LAZY_T(std::string) str){ if(b) std::cout << str(); }

int main(){
foo(false, LAZY(std::string("H") + "e" + "ll" + "o, w" + "orld" + "!" + "\n"));
}

「宣言だか関数呼び出しだかよくわからんものはとりあえず宣言として解釈しちゃうぜ」
的な問題は解決する気はないのかな

どこでも宣言が可能な以上、新たなキーワードなしには無理なんじゃない？
コンストラクタに関してはUniformな構文({}を使うやつ)で回避できるようになるけど。

>>261
きれい

[&]のほうがよくないか

mainがreturnしてないょ

　　　　　　　　　　　　 ／）
　　　　　　　　　　　／／／）
　　　　　　　　　 ／,.=ﾞ''"／　　　
　　　／　　　　 i f　,.r='"-‐'つ＿＿＿_　　　こまけぇこたぁいいんだよ！！
　　/　　　　　 /　　　_,.-‐'~／⌒　　⌒＼
　　　　／　 　,i　　　,二ﾆ⊃（ ●）.　（●）＼
　　　/　 　　ﾉ　　　 ilﾞフ::::::⌒（__人__）⌒::::: ＼
　　　　　　,ｲ｢ﾄ､　　,!,!|　　　　　|r┬-|　　　　　|
　　　　　/　iﾄヾヽ_/ｨ"＼ 　　 　 `ー'´ 　 　 ／

>>266
mainはreturnしなくてもいいよ

>>266
ユー・アー・古い！

266じゃないけど、そうなの？
returnもretrunもneutronもしなくていいの？

C++98や03の時点で、main関数でreturnすることなく関数の終わりに達したら
return 0;を行うというような旨の規定があるので省略可能。

ちなみに、これは確かC99にも持ち込まれたはず。

どうもありがとう。
X3014の35ページ 3.6.1 第5節に書いてあるのね。

>... return 文に出会うことなく制御が関数 main の終わり
>に達した場合，次の文の実行と同じ働きをもつ。
> return 0;

スレチなのに申し訳ない。

みてみて！シングルトンの汎用クラス作ったの！！シングルトンはあんまり好きじゃないけど、思考実験成功なの！！！
動的なメモリ確保はできなかったけど、必要十分だと思うの。環境はVC9EEなの〜。単発でごめんなの。
#include <iostream>
template<class T>
class Singleton:public T{
public:
    static T& GetInstance(){
        static Singleton<T> Value;
        return Value;
    }
private:
    Singleton(){}
    virtual ~Singleton(){}
};
class ScreenObj{
public:
    void Do(){std::cout<<"Do Something!!"<<std::endl;};
protected:
    ScreenObj(){std::cout<<"construct!"<<std::endl;};
    ~ScreenObj(){std::cout<<"destruct!"<<std::endl;};
};
int main(){
    Singleton<ScreenObj>::GetInstance().Do();
    return 0;
}

雛苺乙

仕事にどうやって使えと？

ScreenObjのコンストラクタがpublicでもSingleton<ScreenObj>が使えちまう。
どこがシングルトンなのかと小一時間。
せめて Curiously Recurring Template Pattern にしろよ。

せっかくの0xスレなんだから何か新機能使えよ

>>273
staticなインスタンスを使用する、メイヤーズさんのシングルトンですな。
残念ながらこの方式には欠陥があることが知られている。
詳しくは「Modern C++ Design」を読もう。

初期化のタイミングだっけ。
昔critical sectionでこの方法を使おうとして悩まされたわ。

言語に悩まされるようじゃ、しごとでつかえねーよ。

これが駄目ならどの言語でも駄目だから、プログラミングの仕事はしない方がいい

VS2010スレで案内されてきました
右辺値参照について質問です

-----
ちょっと質問いいすか
const右辺値参照ってどこで使うの？
右辺値参照の提案書を見てもnon-constの使い方しか書いてない気がするんだけど…

Visual Studio 2010
http://pc12.2ch.net/test/read.cgi/tech/1231857024/529

>282
const 修飾された右辺値参照の使い道はおそらく
ほとんど無いのではないかと思います．

(1)右辺値参照でオーバーロードされた関数の内部で，
　 実引数が右辺値 (無名オブジェクト) であることが分かる
(2)無名，つまり他の誰からも参照されていないことが分かるので
　 そのオブジェクトはぶっ壊しても大丈夫

という流れでの使い方を想定しているので， const 修飾されている，
つまりぶっ壊せないオブジェクトは上のストーリで恩恵を受けられないからです．

元スレで指摘されていますが， mutable なメンバがあればもしかすれば
恩恵を受けられる文脈があるかも知れませんけれど自分は思いつきません．

ほとんど無い仕様なんかいらね〜。

>>283
なるほど…わかりました
ありがとうございます

>>283
template<class T>
void hoge(T&& a)
{

>>286　なんか送信してしまった
で　T=const Fuga が渡されたときでもそれっぽくいくようにじゃね？
でもconst Fugaだと結局関数内でエラーになるな。やっぱり意味ないか？

>>287
>>286 のときに T = const Fuga になるのは，
const 修飾した右辺値で hoge が呼び出されたとき
（か， hoge を T = const Fuga で explicit specialization したとき）ですけれど，
右辺値参照があるならば const 修飾した右辺値を生成することに
ほとんど意味が見出せなくなるので，そういう意味でもやはり意味が無いかと思います．

なんかすごいね

ttp://sourceforge.jp/magazine/09/09/10/1214252/4
インテル コンパイラー 11.1では、並列処理を容易に実行するためのC/C++キーワードが新たに追加されている。


でも、シングルプロセッサだと逆に遅くなっちゃうよね。
並列度もコーディングで決定するみたいだし、それほど効率よくなさそう。

せっかくの0xなんだからこういう拡張はattributeにしろと思わなくもない

グダグダです。

>>289
std::threadかintel TBBか、並列構文か、まあ、それぞれが競合しそうに無いから臨機応変に併用もできるのかな。


OpenMPのような機能だけど、intel以外だとコンパイルエラーになりそうだな。
OpenMPなら非対応コンパイラだとOpenMP構文は無視されるだけなんだけどね。

#ifndef __INTEL__
#define __par
#endif

仕事に使える、必要とされている機能以外はいらん。

>>294
意外かもしれないが、お前以外はお前と違う仕事をしてるから、
お前が必要としていない機能を必要とすることもあるんだよ。

独習C++0x〜仕事で使える新機能〜
翔泳社より201x年発行

第一章：C++0x以前、プリプロセッサのおさらい
第二章：raw string literalとは何ぞや
第三章：user defined literalのすすめ
第四章：conceptなしのrange-based forは超簡単

>>295
それって情報産業？
どんな仕事か言っでみ？

コンパイラ作ってます

>>298
工場長、今日はもう家に帰ってください。

いい加減ドモホルンリンクルを見つめ続けるのにも飽きたお

テンプレートと例外は必要とされてない
なぜなら俺様にはわからないからだ(ｷﾘｯ

こんなのが普通にうようよしてるから困る

unary_functionを継承しただけで数十行のコードレビューに2時間近くもかかる
(関数オブジェクトの基礎からレビュアーに説明)こんな世の中じゃ

そんなレビュアーは窓から投げ捨てればおｋ

投げ捨てられるのはむしろ自分になるという罠

むしろ投げ捨てられるのはprogre

あ、ここboostスレじゃなかった

数少ない概念で多くの状況に対応しえていた C から一転、
新しい概念を次から次へと追加しまくってメタボってる C++ には神を感じない

いやな予感は new からすでにくすぶっていたが type なんたらシリーズに至っては閉口もの
言語とライブラリの分業が巧くない（というより人柱的な）ことによる綻びが積もり積もって、
かつて滅んでいった親類縁者達の轍をすでに踏んでいるように見える

加えて造反組の仕事のお粗末さが、状況を更に悪化させていることも頭の痛い問題だ
「うようよしてる」連中の目線で造反してはいけないことを COBOL から学んでいない

>>307
具体的にしゃべれアホ

C++0xって、幻想だったの？夢だったの？
もうすぐ2009年が終わってしまうのに・・・

まだ2ヶ月ある！

ずっと前から2011年て予定出てたじゃん…最低でもそれより後になるでしょ

>>307
> 数少ない概念で多くの状況に対応しえていた C から一転、

今は無理でしょ。UNIX v7のコード量の少なさと言ったら…

xはまだa〜fまであるよ

0xの正規表現はSJIS使えますか？

>>313
xは１６進数だ！、って話はよく聞くけど、
それは、ネタなの？
本当に最初からそうで、情弱な俺が知らなかっただけ？

ネタだよ
なにしろ最初は2008年に発行するつもりだったんだから

発行しないほうが幸せだな。

ワシの0xは108まであるぞ

>>318
だまれ

C++0x2108

こんなお粗末な展開なら、出ても意味なしだな。

意味なんてあろうが無かろうが、仕事にフィットする言語/処理系を使えばいいだけ。

じゃあ私は言語に合った仕事を探すことにします。

>>308
いやな予感を new から感じ取れないアホに type なんたらシリーズという以上の説明は不能

説明できないんじゃないんですよね、わかります

　（　<●><●>）
　 （Ｕ　　 　　 ）つ 　わかってます。
　　　 ｕ　　ｕ

確かにplacement new[]とか例外時のplacement deleteとかクソなものはあるけど
そこは触らなければいいだけのことじゃない

>>324
new の何が嫌なのか言ってみろアホ

嫌な予感がするnewだからこそ、小回りが聞いて仕事にも使えたのにな。

newとtypeinfoは-というより
C++の演算子オーバーロード全体の問題だと思うけどね

0x関係ないがな

VC10にnullptrがついたらしい

g++ の std::set に emplace 入るのはいつなんだろうか…

で、お前ら仕事はなんだ？

電子土木作業員

>>328
>>307 で言ってるんだが
アホには通じてないというだけ

「いやな予感は new からすでにくすぶっていた」の一言だけで
お前がnewで嫌だと思う所が通じないのがアホだとしたら
この世にアホでない奴などいない

new[]はクソだがvector使うから使わない

統合失調の奴が書いた小説みたいな文章読まされても…

>>336
new の何が嫌なのか具体的に言ってみろアホ

「言語とライブラリの分業が巧くない」って言っているからには、
307自身が今から作るとしたらどうするかってのは気になるよね。

>>307はほっとくとしても
newみたいにコア機能とライブラリが癒着してるのは気持ち悪い
でも0xでまた増えるんだよなぁ…

まったく・・・
自分が嫌だと思うところがさも他人にも嫌であるに決まっていると盲信してるどころか
自分の考えが　状況に寄らず　科学的に真実であると思ってるだろ・・・
この場に>>307の主張を本人以外に説明できる人が現れたら>>307の話に耳を傾けることにする

ttp://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/

正しくて適切な素晴らしい判断ですね

プログラマーと言語設計者の関係は
顧客とプログラマーの関係に等しい……
無理ばっかり言ってきやがる。

もっと無理いっていいよ。
安定するまで使わなくてすむ。

客は金払っているから馬鹿でも言うこと聞く必要あることがあるが、
馬鹿なプログラマは無視すればすむから無問題。
MSみたいに委員会の有力者を雇って、
自社技術を規格に潜り込ませようとするのは勘弁。

安定? むしろ何を言おうが
無理言ってる人と無関係に言語仕様が固まるだけ。

C++の標準化委員会の人たちはみんなボランディアだから
うるさいプログラマたちにうんざりしたら辞めちゃうだけだよ

まあ少なくとも英語圏のサイトで英語でわめかなきゃ届かないでしょ。

Unicode決め撃ちにしてくれってのは英語で届いちゃったみたいですけどねw

もともと彼らの中にあるものは届きやすいだろうな。
少量の言葉の断片がかすっただけで「ああ、そのことね」と理解されるから。
でも、彼らの中に無い物は、必死で言葉にしていかなきゃ形にならないよ。

c++0xって2009年中に出せなくてもC++0xっていい続けるの？
それともC++1xになるの？

どうでもいいからみんな気にしてない。

xは16進数だから2015年まではC++0xでおｋ

正式な勧告で別称が確定するまでは、検索とかのためにC++0xと呼び続けた方が良いだろう

C++03とかの呼び方って勧告で決まってるんだっけ？
出た後はあくまでただの「C++」じゃないの

10年以内にまた改訂されることを考えるとC++1xの名称を残しておいてやっても良いんじゃないか

10年以内にあるとしてもC++98→C++03程度の改訂じゃないの？

ってそうかコンセプトのやり直しがあるのか

次は昔募集していたTR2だろう。

C90 の次が C9X と呼ばれていて C99 になったんだから現在検討中の規格が C++10 になったところで
その次の規格は C++1x と呼ばれるだけだろう。

確かに次の規格をなんて呼ぶかは難しいところだｗ

C++0x20くらいだろｗ

>>352 一般的なことですが，まとめ役は意見を聞いて集めたあと
ダメなものはダメと毅然と却下するべきだね

オタクはなぜ同じ話をぐだぐだと繰り返すのか

同じ面子がずっとここに居座ってると思ってるのか？

少なくともこの間から仕事がどうこう言う奴は居座ってるな

詳細部分を「どうこう」でまとめていいなら
結構大勢の人間を同一人物認定できるだろう。

すぐ具体的な指摘がない極論が出る始末

仕事で使える言語を頼む。

こんな感じで話がループして、
0xの仕様もなかなか決まらないのかな？

委員会のメンバーって仲悪いのか？

独裁者が居ないんだからしょうがない。
「仲」でモノが早く決まるような集まりに決めてもらっても困るし。

>>373
そうなの？
創始者のハゲに９割くらいの決定権があるのじゃないの？

禿に強力な権力があるならconceptがああなることはなかったろうな

>>374
おまえこのスレにいてこれすら読んでないとは、
ttp://www.devx.com/cplus/Article/42448/0/page/4

モグリだな。

一人一人が処理系作ってそれを定期的にレビューしあうようにすれ

禿の影響力は個人としてはかなり強いけど、
禿そのものが無茶慎重な性格だからな。

"Simplifying the use of concepts"だって、
結局は自分のもともとの意見に引き込んでいるけど、
他の人の議論をかなり咀嚼した上で書いてる。

やっぱり C++1x は「予約」しておく必要がありそうだ。

raw string はコードの見栄えがわるくするな。

std::cout << R"[hoge
foo]";

std::cout << R"[hoge
　　　　　　　　　　foo]";
↑ここにtab入れられない。

Raw String Literalってよく分からないなぁ。
どの辺が便利なんだろうか？

R"[\n とか書かなくても
こうやって改行とかできるところじゃね？
特に長文とかなると便利かも]";

ダブルクォートがガンガン入る文字列とか。

もしかすると regex 関連で入れることになったのかもしれない。

>>381
here documentを言語にいれるのが最近の流行りじゃん。
馬鹿っぽいけどやっぱり便利ではあるよ。
\nを解釈できるライブラリばかりじゃないし。

無理して入れるほどじゃないがあると便利なこともあるな。

std::cout <<
R"[
>>390は
こう書けばいいよ
]";

未来のレスにレスですか

>>387
>>390さんへの振りですか。

ksk

std::cout << "だが断る";

改行よりはバックスラッシュとかダブルクオートとかのほうで便利そう

>>384
here documentってどういう意味でしょうか？
ttp://yougo.ascii.jp/caltar/%E3%83%92%E3%82%A2%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88
こんな解説などが見つかりましたが今ひとつ分かりません。

ttp://blog.livedoor.jp/campanella_77/archives/50048510.html
こんな奴。スクリプト言語なんかではよくある。
複数行に渡る文字列なんかを埋め込む時は楽だし、余計な手間が無い分バグも入れ込み
にくいと俺は思う。

>>393
ありがとうございます。
やっとそれが導入されたわけですね。

これ以上、仕様を複雑にして、
機能を多くして、どうするよ？

・・・って、世界中の人は誰も思わないの？

>>395
むしろ足りないと思っているでしょうな。
TR2とか。

>>393
スクリプト言語の仕様なんかいらなくない？
なんでそんなの必要なの？

> スクリプト言語の仕様

頭おかしい人ですか?

C++でヒアドキュメントがあると嬉しい場面ってあまり思いつかないな。
CLIなツールを作るときにうさげ書くのが楽になるってくらいしか出てこない。

スクリプト言語の仕様なんかいらない

＞スクリプト言語の仕様
頭おかしい人ですか？

どう見ても頭おかしい人ですな

まさかの >>397 人気に嫉妬

iostreamよりprintf属の方が相性良さそう

printf(R"[Date: %s
Content-Type: text/html; charset=utf-8
Content-Length: %u

]", date, length);

関係ないがHTTPヘッダの改行はCRLFだから明示的に指定した方が安全だと思う

>>395
今の仕様が一貫性を欠いていて憶えにくいだけで、
例えば関数テンプレートを部分特殊化できないとか、
コンストラクタ実引数からクラステンプレート仮引数を導出できないとか、
その辺はむしろ「増やす」ことによってより単純化できるんじゃないか？

>>405
ふつー、>404ではCRは入らないと思う。

「ふつー」て、そんなの仕様次第じゃん。

下手するとソースの保存のしかたで変わってしまいそうな気がする。

インラインアセンブラ書く時ならヒアドキュメントもいいかも。
intrinsicsが浸透しつつある今ではインラインアセンブラの必要性自体が急速に減りつつあるけど。

ヒアドキュメントなんてスクリプト言語っぽくなって、
カッコ悪くなるからイラない。

C++なんてカッコ悪い構文だらけなのに何を今さら

[&]

[[笑]]

C++からpython使えるようにしてあると、生ソースを埋め込めてちょっと便利かも。

>>414
それは「括弧笑い」やー！

C++五大ダサ構文

1)
extern "C"

2)
typename Hoge<Fuga>::type x;

3)
Hoge::Hoge()
try: mem(0)
{ ...

4)
Hoge Hoge::operator ++(int)

5)
p->~Hoge();
Hoge::operator delete(p, x, y);

4への不満が分からない

3の関数監視try間違ってね？

>>418
intの意味のなさじゃね
前置と後置を区別する方法は他になかったのかと

ああ、後置インクリメントだったか

>>419
Borland では通らないけど、これは
15 Exception handrling の 1 の
function-try-block:
try ctor-initializer opt compound-statement handler-seq
に違反してるな

0xスレ的に0xの構文の話をすると、decltypeの括弧が個人的に一番アレ

>>417
:をctor-initializer_optじゃなくて、
tryの方にくっつけるスタイルは始めて見た。

まあ4のoperator++が圧倒的にダサイ。
>>417さんはoperatorの後ろに空白入れるんだな。これも珍しい。

ダサ「構文」とは関係ないだろ

>>410
intrinsicsって何ですか？

__builtin_mallocみたいなの

>>417
5) はちがくね？
p->Hoge::~Hoge();

pがHoge*ならちがくないよ

×ちがくね?
○ちがわね?
○ちがってね?

×ちがくない
○ちがわない
○ちがってない

馬鹿に馬鹿さを突きつけると馬鹿なキレ方してくるよ

馬鹿にはよくあること

ネタにマジレスというネタか

触ってやんなよ自己満足なんだから。

|　||⊂⊃⊂⊃||
|　|| ﾛﾛﾛﾛﾛﾛ ||　がしゃーん
|　|| ･ ･･･ ・・ ||
|　|| ﾛﾛﾛﾛﾛﾛ ||
|　|| Coca Θ.||　がしゃーん
|　||口口口□||
|ミ||＝＝＝＝||
　 ￣￣￣￣
自動販売機だよ
自動で販売してくれる凄いやつだよ

Post Santa Cruz mailingﾏｰﾀﾞｰ?

無名関数なんですが、
DarwinのGrand Central Dispatchで採用された"Blocks"が、
FreeBSDでもGCDとともに導入されて、勢力を拡大しそうな感じです。
C++ではなくてCの拡張機能ですが。
http://libdispatch.macosforge.org/
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html

WebKit は流行ったけど、block はどうかな...
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf
http://clang.llvm.org/docs/BlockLanguageSpec.txt
http://clang.llvm.org/docs/BlockImplementation.txt

JavaScriptの改訂に先を越されそうだ

郷の人気で吹っ飛ぶ鴨な

GoはGC付き言語、JavaやC#やDと同じ
C/C++の代わりにはならない

>>441
なぜ？

>>441
お前の言い方だと
GC付き言語はC/C++の代わりにはならない
と言っているようにしか取れないんだけど、
何で？

>>443
勉強しろ。お前には説明してもわからんよ

デバドラの割り込みとかリアルタイム性のことを言ってるつもりなのか？

だってGCが付いてたら実行時間予測できないじゃん
1秒を争う処理の最中に呑気にゴミ拾い始めたらどうするつもり？

もなか？

11月号来た

>>444
> 勉強しろ。
お前は勉強した気になっているだけだろ。

GCの性能は確かに上がってて、平均実行時間でならネイティブと大差なくなってきてるけどね
アプリならそれでいいんだろうけど、C++の得意分野で大事なのは最悪実行時間の方
少なくとも現代のGCはその方面では話にならない

ところでN3000の最後に付いてる新しいindexは便利ですね

GCの有無だけで代わりにならないって言い切ってるところがすごいｗ

だってそうでしょう
致命傷だも

goやdはともかく、RTシステムに適用可能なGCとかあってもよさそうだけど。ないのかな？
もっとも、そろそろRTシステムのプログラミングは全部MATLABのオートコーダが持っていっちゃいそうな雰囲気だけどね

Goおもしれー。D言語見たく、最初面白いけどその後意味不明にはなってほしくないな。
がんばれGoogleまけるなGoogle！

N3010で頭痛くなってきた
わかるけどさ

>>454
言語仕様のレベルで多機能や新しいパラダイムやスタイルを追っかけていけば意味不明になってくさ。

>>451
GoがGCをオフにできるなら話は別だけどね。
どんな時にも使わなきゃいけないのなら、「C++にできてGoにできないことがある」わけで、
C++の必要性は潰えないのでは。

メモリアロケートしなけりゃGC走らないんじゃないの

逆にCでもメモリアロケートすればGCと同様のペナルティがある
ってDの人がいってた

「GCと同様」ってのが詐欺臭い言い回しだなぁｗ
とりあえずそのDの人はGCのペナの意味とかほとんど分かってないだろうな

とりあえずおまえがわかってないな。

GCが無ければいいような流れだけど、
GCがなくてもあまりいみないよ。

たとえばnew や malloc でヒープからメモリを利用する。
解放する、利用する、解放する、利用する、
そうすると、ヒープが断片化する。
断片化したメモリは、連続して扱えないから、
それを集めるガベージコレクションに似た操作が必要になる。

そういうときは
あらかじめプールするんだが

それがGCなんだが

>>461
その機能がOSに無ければOSが動かなくなるだろ
98以前は再起動必要だったりしたが

>>464
お前、アプリがメモリ要求したときに
いちいちOSからメモリをもらっていると思っているの？
そんなことしたらパフォーマンスが劣る

標準ライブラリが、OSからある一定量まとめて取得した後
アプリの要求に対して細かくメモリを割り当てているんだが。

プロセスなりスレッドなりの単位で
プールを確保・破棄すれば
断片化はある程度避けられるんだ

GCもそんな感じで、パフォーマンスをあげているんだろうね。

GCの問題は、GCがどのタイミングで動くかわからないところでしょ。
特にゲームではそれが問題になる。

あと、デストラクタがいつ呼び出されるのかわからなくなってRAIIがなくなるのが痛い。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-11
200x年最後のWorking Draftがn3000か。
結局Move Constructorはどうなるんだろうね。

>>468
たいていの言語はGCを手動で実行・一時停止したり、
あらかじめメモリをプールしたり、特定のオブジェクトだけ破壊する方法をもってるよ。

>>470
つまり結局手動でメモリ管理しなきゃならないわけだ

>>471
GCのスケジューリングをメモリ管理と呼ぶならそうだな。
RAIIに関しては糖衣構文でかけるようになってる場合が多いから楽なもんだが

>>470
GCが管理するメモリって自分が書いたコードのみならず、ライブラリも含まれるから、GCの動作を見積もれないよ。
手動でGCを操作するぐらいなら、GCない方が楽だし安全だと思う。

>>472
RAIIは、全てのクラスに対してRAIIが働くことが保障されてこそ、大きなメリットがあるんじゃない？

メモリ管理を自分でしないなら、
Ｃ＋＋の存在意義がなくなっちゃうじゃん。

>>473
C++でもRAII使いたかったらオブジェクトをスタックに割り当てる必要があるだろ。
プログラマが気を遣うのはその程度で済むようになってる

>>474
お前が確保したメモリは
物理メモリなのか
ディスク上のswapなのか
把握できるとでも言うのか？

newをオーバーライドするようになって、
初めて一人前のC++使い

newのオーバー…ライド？？？

swapされてるとか関係ないじゃん

>>475
RAIIとは言わないのかもしれないが、ヒープに割り当てた時でも、
オブジェクトが参照されなくなったらすぐにメモリ解放と一緒にデストラクタが呼ばれる事にメリットはあると思う。

GCはメモリしか管理できないのが最大の問題点だと思う

メモリは解放を遅延しても大して問題にはならないけど、
ファイルハンドルとかロックみたいに正しい時期に解放する必要のある資源も
デストラクタ＋RAIIだとうまいこと扱えるのがいいところ

> 大して問題にはならない

ここを勝手に解釈されることが問題なわけだが

>>476
スワップ禁止の物理メモリに確保するAPIとか普通あると思うけど
そういうのが必要な時にそれを使えると使えないとの違いは大きい
必要ない時でも、RAIIの方がタイミングはコントロールしやすい

GCのメリットっつーと、メモリ資源の解放が表舞台から隠蔽される、って点だろ？
最大のメリットは、コーディングしなくても面倒見てくれる、という点で、バグの入る
余地が無いに等しい
が、RAIIもきっちり運用すればバグの入る余地は乏しく、メモリ資源以外にも適用可能
だったりする訳だが
で、GCに付随するデメリットが響くようなアプリケーションなら、明らかに向いてない
訳で、別に世の中みんなそういうアプリなんて話じゃないから、使える場面では使える
だろうさ

alloca

GC自体は禿も否定はしてない、むしろ肯定的。
しかしながらGCの存在が問題になる対象も確実にあり、C++はこれを切り捨てない。
他でもないC/C++が必要になる場面はこれからもあるだろう。

そもそもの原因であるGo言語の設計者もインタビューで「既存の何かを
置き換えるものではない」と言ってるし。

既存言語を完全にリプレイスできる言語ってめったにないと思うんだ。

>>486
そんなんあったら俺に教えてくれ。

取って代わられて廃れるケースはあるな
C++みたいに膨大な利用ベースを持つ言語になると、そういうのも考えづらいが

完全ではないがアセンブラをリプレースすべく作られ、ほぼ成功したのが C だったな

馬鹿発見

美少女中学生が馬鹿を発見しました！

軽さは正義だからな。マシンパワーが増加すればやりたいこともまた増えるし。
フリーランチは終わったし、アムダールの法則も健在だから、当面はC++でいいけど。

>>489
俺もそれは思う。



だが！

ここは　C++0x　スレだ
お前らいい加減に実りある C++0x の話をしろ！

>>481
GC付きの言語でも明示的にオブジェクトを破壊することができるから、それは全くの杞憂

全部明示的に破壊すれば、だな
その場合、GCは無駄なオーバーヘッドになるが

>>495
GC管理外のリソースを持っているオブジェクトだけ破壊すればいいのであってすべて明示的に壊す必要はない

お前らスレチ！

C++0xにGCが導入されるならともかく、
されない以上　その話題は禁止！

>>446
時間予測できればいいならGCありでもよさそうな気がする。
旧式のマークアンドストップじゃだめだけど。

必要なときにはGCを強制オフってのもいいかもね。
あるいはGCいらないならそれ自体オフにしておけるとか。

リアルタイム系使われるAdaはそういう感じだっけ。

その辺ちゃんと考えて作られてればGC付きでもいいんだろうけどな
API駆使すれば一応出来るってんじゃなくて、言語設計の時点で

>>499
最後の一言、しみ入るな
#include <gc>
とか、やめて欲しい

>>493
話すべき事に、もともと実りがないんだから仕方がない。

>>477
最近覚えたんだね＾＾

無知の知とかあのプログラマーレベルの話を思い出した

>>499-500
そうするとC++/CLIになる予感

#define gcnew うんたらかんたら

GCでストップとかGC作ってみればわかるよ。
回収しようとするから止まる。

>>506
大方GCで予測困難な時間が発生するのは是か非かという議論だったと思うが…
誰も何故止まるかなんて話はしてない

あとスレチ

みなさん誤解してますね。
GCというのはプログラム一つに一つとは限らないんですよね。
GCで管理されるオブジェクト上の資源を管理する別のGCがあってもいいし、
まったく無関係に独立のGCが複数あってもいい。
いくつでもありうるのです。
それならGCの時間を予測するのは簡単ですよね。

なんで？
ただでさえ複雑なGCが複数動くなんて考えただけでも複雑すぎて恐ろしいんだけど

複数GCが有っても他のGCのメモリを参照してたら、意味ないじゃん。回収時に全部止まるんじゃね？

アセンブラ分からない奴が効率を語るとたまに頭おかしいこと言い出す、って話を思い出す

参照カウンタならまだいいが、マーク&スイープが複数動いてたら死ねるな

もっとメモリをください

>>511
たまにじゃなくて頻繁に

>>508はアセンブラどころかGCが何なのかすらよくわかってない
「プログラム一つに一つのGC」という頭の悪すぎる発言がその証拠

ガベージコレクタと読み取るなら、その文自体は問題なくね
文章全体が言ってることはバカだけど

そろそろGCを
あぼん した方が良さそうだな。

時代はすでにWiiが主役だ。GCに用はない。

急降下

似たようなモンじゃねーか > Wii と GC

GC(ﾟ�听)ｲﾗﾈ
デストラクタと関係ねーじゃん

ＧＣつかいたかったら、JavaやC#使えばいいじゃん。
C++を、これ以上、ブクブクに太らせてどうするのだ？

>>522
太って困るのは実装する人。

CPUの並列がどんどん進むので、
C++はもう未来はないな。
組み込み専用言語としての未来しかない。

態々そんな事言いに来て
「尤もらしく意見する俺すげぇ」
とか思ってんのかしら

>>522
というか今の実装でお前は満足しているのか？
そんな程度のお前にはTMPをお薦めしよう。

TMPで生成したコードをコンパイルして実行ファイルが激重になってしまったが
動的型付けで書いたコードの方が実行ファイル軽くてしかも速度になんら問題ないというのは良くある話

まぁ下手だとそうなって投げ出すのは良くある話だな

wikipediaのTMPをみるとインライン展開とループアンローリングを
TMPの利点としてますが、C++がそうだといってるんですよね。
また世の中の全ての言語のTMPが同じようなものといいたいのでしょうね。
僕はそうは思わない。
C++のテンプレートはインライン展開をしないようにできない欠陥があるんだと思う。

>>529
思う思わないはチラシの裏へどうぞ。

ループアンロールなんてどうでもいいよ

思う・思わないってのは論じゃねえしなあ
だからどうしたとしか言えんわな

s/思/言/

思うだけならタダ

皆様に長らくご愛顧いただきました200x年代も、
残すところあと1ヶ月半となりました。

意義あり。
２１世紀は２００１年から始まっているのだからして、
最初の１０年には２０１０年の年末までが含まれるべきだ。

意義？

異議だろ

出直して来い

異議あり。
２１世紀は２００１年から始まっているのだからして、
最初の１０年には２０１０年の年末までが含まれるべきだ。

こ、こいつ…本当に出直して来やがった！

現行C++でboostの実装見たりtemplate metaprogrammingで遊ぶのが趣味だったのに
0xの実装を落として自由と安息を手に入れて一気に生きる意味を見失った。

右辺値参照やdecltypeを使って黒魔術を開発する作業しようぜ！

C++はちょっとづつ言語を便利にするために
大勢のC++グルが10年づつ時間が必要だというところ。
これからの言語は基本的な小さな言語を定義して、
そのコードを生成する俺様言語の時代だろう。

Domain Specific Languageのスレって立ってないの？

「コンパイラ・スクリプトエンジン」相談室14
http://pc12.2ch.net/test/read.cgi/tech/1258431145/

>>542
ただのLispじゃないか。

俺様言語は特定の言語に限定しない。
C++のコードを生成してやってもいい。
右辺値参照のような機能は俺様言語にも有用だ。
そういった機能を定義、実装されることを望む。

参照って仮引数の話はおいといて、たとえば
　int foo = 1;
　using bar = foo;
とかでいい気がするんだけど、こういう文法だと何か面倒が起こるのかな？

int foo = 1;
auto &bar = foo;

これに何か不満が？

>>548
typdef代わりにusing使ってもよくなるし
multi-wayになること自体は別にいいのでは

>>547
その構文を採用するとなるとtypedefの意味のときに
typenameつけないといけなくなる気がする

　using UINT = unsined int;
　　↓
　using typename UINT = unsined int;

誤：unsined
正：unsigned

混乱の元になるのに、そもそも、
なんでわざわざ既に別の意味で使われてる&に、
参照の意味を持たせたのだろうか？

タイプコンストラクタと演算子は混同しえないから

それで混乱するような奴はどっちにしろまともに使いこなせない言語だからいいんじゃね

禿が考えてたのは、もともとこんな発想だろ
void a(int*);
a(&b);
↓
void a(int&);
a(b);
つまりアドレス演算子を関数側でつけるってこと

既に別の意味といえば & ならビット AND にも使われているわけで
そんなの気にしだしたらきりがない

*だって別の意味に…

別の意味を考えて赤面する美少女中学生

いやいやそういう意味じゃないって！

１つのキーワードに複数の意味を持たせるのはC++の悪い癖。

>>554
アドレス演算子、参照の宣言という関連があるところで同じ記号使うのは逆にタチが悪いと思う。

使える記号は限られているわけで
無闇に記号使ったら
将来使える記号が無くなって困るんじゃない？

禿「よし、次はUnicodeの絵文字領域を使うか」

こんなんでややこしいと思う奴はC++どころかCの複雑な型宣言も扱えないだろうな

そもそも参照の&って何のために必要だったの？
ポインタだけで何の不足もなかったのに何で付け足したの？
禿げってアホだったの？死ぬの？

今頃そんな話がでてくるのかよ。

参照無いと一時オブジェクトの扱いが悲惨なことに。

Hoge operator+(Hoge *lhs, Hoge *rhs);
Hoge a,b,c;
c = &a+&b

とか書きたかった？

>>559
記号じゃなくてもいいでしょ。
D言語は参照にrefっていうキーワード使ってる。
>>561
実際、C/C++は学習に時間がかかるでしょ。
わかりやすくて使いやすいに越したことはないと思うけど。

過去の資産も上位互換も全く考えなくていいD言語をC++と同じ土俵に乗せるなと

参照要らなかったんじゃないかと思ってる奴は、TMPどころかユーザー定義型すら
作るのに困りそうだが
「俺の理解できない物は実用的じゃないオモチャだ」の理論を使えば、心の平穏は
得られるんだろうけど

しかし、同じ土俵で戦えない言語はすたれる。

廃れるとしたらDの方だから問題無い

ヌルい奴らは背伸びしてねーでスクリプト書いてるのがお互いの為だろ…

初期にはキーワードを増やさない方針があったのだし
Cから参照の概念を抽出する過程ではC++もあんな感じにしかならんかった気がする。

それがあるからDやらJavaやC#はC++と同じ轍を踏まないようにしたって面も大きい。
歴史を結果から逆に見て批判しても無意味だよ。

>>565
ポインタ渡しなら中身が書き換えられることが
呼ぶ側も呼ばれる側もソース見れば一目瞭然だった

func(&hoge); なら hoge が書き換えられる可能性があるとみなせるし
&hoge += 1; なら hoge が呼んだ側の変数なんだろうとすぐに分かった

参照渡しを導入したことでそういうメリットがすべて台無しになった

間違えた w

x &hoge += 1; なら hoge が呼んだ側の変数なんだろうとすぐに分かった

o *hoge += 1; なら hoge が呼んだ側の変数なんだろうとすぐに分かった

>>573
その程度の初歩的な話はみんな見飽きてると思うよ

元をただせばポインタ周りの文法がCでは「経済的」過ぎただけ。

Cのポインタ周りの文法はごちゃごちゃだったので
それを整理しただけだと思えばいい >>573

参照無かったらインライン関数どうすんの

インライン関数無かったらクラス定義どうすんの

もちろんマクロで書くさ！

>>568
いや
それはない

C++らしく書くには参照は必須だろう
それが分からんならCに帰った方が幸せになれる

ただの参照でさえこうなるのに
右辺値参照とか見たら発狂するんじゃないのか

>>567
D言語の例は>>559の「記号は有限」に対する反論のつもりで出した。
C++がD言語のように仕様変更できないのは御尤も。
>>572
確かにC/C++の結果があるから言える事ではある。

>>583
それで発狂するくらいなら、他の言語でも結局発狂すると思う。

参照は初学者のために追加されたってD&Eに書いてたような

まず自分の本棚へ行き、本を開いて、該当個所を見つけてから書こうね。

参照のせいで、最後までソースを追っかけないと、
変数の値が変えられてるのかどうだか分からなくなった。

クソソースをデバッグするときのタイヘンさがパワーアップした。

普通はconst参照か否かで終わるだろ。

Cでも結局引数が構造体の場合には
余程サイズが小さくない限り
値渡しなんて効率考えたらあり得ない選択だよ。
結局基本構造体はポインタ渡しにせざるを得ない。

逆にC++でも基本型は、値渡しで済む用途の場合
値渡しで渡すのが当然

589は何も分かってないな

>>588
いや、何を言っているのか。

const参照ならオブジェクトは変更されていないだろ？
そして非constな参照の場合はオブジェクトは変更されている可能性があるだけ。
というかむしろもう俺は変更するぜという意思表示に近い物がある。

&の有無を目視で確認するよりか、書き換えてほしくないパラメータはconst変数/参照でもちなおして関数に渡した方が確実だと思う。
&は変数書き換えの目印というけど、int const*とかどうするんだろ。コーディング規約で禁止？

多分 >>588 は
参照なしなら

int a;
f(a);
g(&a);

の時点で a が変更されるのかどうかがわかるけど
参照があると

void f(int& x);

を見ないとわからないということを言いたいんだろう

C++の場合、結果的な仕様が好きか嫌いかはともかく、
議論の有無だけでいえば、死ぬほど議論した上でそうなった仕様が殆ど。

だから、自分の経験の枠内でしか物を考えない上、そういった議論の歴史を
解説しているような文書を読み込んだこともない自意識だけのドカタ君が、
「ぼくのすばらしいせんす」だけを頼りに論理を開陳しても、まず間違いなく
滑稽なものにしかならないと思うよ。

>>594
> 議論の有無だけでいえば、死ぬほど議論した上でそうなった仕様が殆ど。
同意。
わからんやつはこのC++0xの標準化委員会のごたごたを見てみろ！

つーか既に現実にあるC++を受け入れられないのか知らんが
C++0xスレで文句を言ってもだな、……と思う

&どころか、&&とか出てきて、
誰も保守できなくなりそうな勢いだから、怖いのだよ

rvalue referenceの何が難しいっていうんだよ？

大勢でよく議論されて、よく考えられたからと言って、良いものになるとは限らないと。
その主な例がC++とUnicode。

>>591
>const参照ならオブジェクトは変更されていないだろ？

const参照は単にreadonlyな参照であることを表明しているだけだがな。
単にreadonlyなだけなので、読み出すたびに内容が変わっていてもそれは問題ない。
キーワードの問題さえなければreadonly参照とでもするべきだった。

良くないってわかってるんなら
じゃあ文句ばかり言ってても始まらんだろ

>>599
それはまた別の話だね。
ここでのポイントは、いま仕様批判を頑張ってる子の根底にあると思われる
「こんな簡単なこともわからずに、なんでこんな仕様にしちゃったの？」っていう発想は、
自意識過剰な無能によくある「ぼくだけお利口、あとは馬鹿」タイプの勘違いに過ぎないということ。

>>596
> 既に現実にあるC++

これに問題大ありだからこそ、それを改訂すべく各所で論議されているわけで、
草の根からわき上がる様々な意見こそが貴重な原動力であり、
自らの思うところを黙っていることはただ乗りだと思うぞ

むしろ尖端恐怖症とか潔癖症(不潔恐怖症)のにおいがするんだが。

>>603
こんな所でか？ 冗談キツイっすw

もっとも、俺自身も諸般の事情から思うところを出し切っているわけでもないけどね

もうここまで来たら、ハゲが強権発動して、
適当に決めてしまって来年中にC++0Aを出せばいい。

>>603
まだその位置にすら日本はたってないだろ。
時代錯誤というレベルだぜ。

>>608
そう思うなら黙ってれば？

>>607
その結果がexportだと思う。

思う思わないだの、いい加減なことをいくら書いても議論にならんよ。

なんてレベルの低いスレだ。

C++0xに関係ない話題が出たときだけ伸びるスレだな

基本的に英語が読めないから、今現在、
C++0xがどうなってるかなんて、分かりようもない。

だから、別の話題にそれるのだろ？

unkosure

あなたの意見なんて聞いてませんよ

C++にしてもUnicodeにしても、
確かにゴテゴテしているが、
積み重ねられた議論、
公開された提案は宝の山だぜ。

>>455
これは好きだ。

>>602に禿しく同意

ﾌﾟ
バッドノウハウ言語あげ

むしろ何でもやろうという観点で考えるとできない事はできないと割り切っている言語よりはマシなのでは。

なんでもしようとして、制限や出来ないことが増えてるけど。

非合理的なことができなくなってるな。

バグも合理的なのか。

>>623
中学生にはわからない会話だから入ってきちゃ駄目。

自分は分かってるつもりが一番痛いな。

中学生って言われて中学生ならでは返しをしたらドツボですよ。

自分に返されたと思った自意識過剰が一人。

＾ｑ＾

ホントに青いなぁ、返しが。

分かると言えるのはコンパイラ書いた人だけだな
それ以外はただの脳内

コンパイラ書いてても信じられないくらい分かってない人もいるけどな…
実装面からの都合だけギャーギャー並べ立ててる奴

C、C++は、コンパイラの実装が簡単になることも
言語仕様の設計コンセプトの一つだから、
他の言語ほど使う人最優先で言語仕様を決める
ってワケにはいかないのじゃね？

最初から実装が簡単になるように作ってれば、
今みたいなことにはなっていなかっただろう

後知恵なら何とでも言えるな
C++の前にC++無しだ

自分の墓石にC++のコードを彫ってしまうんだろうね、あんた。
残念ながらC++はもう終わりです。
これからは俺言語の時代。

じゃ俺言語としてC++を使おうじゃないか

もうしばらくすると俺言語全盛の時代を迎える。
そのときあんたは俺言語の非常にコンパクトなバックエンド言語の
コンパイラをセコセコ作ってるだろう。

俺言語とはつまりマーケティング指向言語だな

別に汎用言語と俺言語を排他的に扱う必要はないと思うんだが

さてC++の生き残り戦略を考えようか。
俺言語はアセンブリ言語のコードを出力するのではなく
別のコンパクトな言語を生成するだろう。
C++はそのための言語として活用されるだろうか？
そうはならない。
C++は無駄に複雑で、汚い、学習に不向き、
俺言語の要求に応じて改訂するのも非常に大変、面倒くさい。
生産性の非常に高い俺言語が作られいき、
C++を学ぼうとする人は激減し
C++は単体のコンパイラとしてメンテナンスされなくなり
コンパクトな言語に変換されるトランスレータになる。
そしてリタイヤした特殊な人々が墓に入るまで
細々と小さな改訂をしていく…

スレ違い

>>632
>コンパイラの実装が簡単になることも
C はそれで普及したけども、C++ はなあ…

俺ストーリーを語る人ばっか

>>643
池沼が1人か2人くらい暴れてるだけで
あとはいつもどおりの過疎スレです

>>644
おまえら本当に哀れだな。C++0xの成功は無いよ。
COBOLプログラマがコボラーと呼ばれ散々バカにされ蔑まれただろ。
今度はC++プログラマはプラプラーと呼ばれてコボラーの末路をなぞるんだよ。

必要悪だから使ってあげてるだけなんだからね！
勘違いしないでよね！

根拠なき自信漲る荒らしかな

俺以外みんなバカだし哀れだぜ

>>645
スレ違い、板違いの話題はご遠慮ください。

C++プログラマの話をしたいならマ板へ。
バカにされたくないという話をしたいなら、よく知らんけど心の病の関係の板へ。

俺言語にC++っぽい構文移植するんだよ

>>646
ツンデレ美少女中学生だ！

むしろこのスレが禿板に立つべき

>>651
なんで中学生なんだよ

いや、好きなジャンルだけども。

見苦しいからそういう事書き込むのやめた方がいいよ

まあ、実務者不在の言語仕様なんて、
お経みたいなもんだ。

> お経みたいなもんだ。
禿に掛けたのですね、わかります

コンセプト無くなったしexportもD行きになるし
実装困難な所ってもうそんなにないんじゃないの

ed使いというかedなんだろ
治療できますからあきらめないでくだしあ

今exportバリバリでソース書いてる俺としては書き直さないと将来はないってこと？

>>659
exportばりばりって・・・
どのコンパイラ使ってるの？Comeau？

>>657
> コンセプト無くなったしexportもD行きになるし
決めつけるなよ。
きっと次のC++1xかC++2xくらいには・・・きっと・・・ね。

exportを使いたいからComeauを買った
色々面白い

>>661
やっぱComeauか。
俺も買おうかなぁ。勉強になるだろうし。

なんやかんや言ってもC++がプログラムの世界の
最高峰だろ？

最先端技術や研究は、みんなC++じゃね？

なこたない。適材適所

素早いコーディングが大事な時はスクリプト言語
普通のアプリを真面目に書く時はC++
組み込みかそれに近い時はCやアセンブラ

素人に書かせる時は、DSLをスクリプト言語で書いて使わせる
何しろ納期の前夜に仕様追加が必要になったりするから、スクリプト言語じゃないと
結構死ねる（スケジュールが完璧な会社なら無用な苦労なのかもしれないが）

仕事の受注開発でC++なんて、怖くて使えんな。
開発には向かない言語じゃね？

C++は、研究分野や趣味で使うもの。

お前の使っているブラウザもC++で書かれているんだが

俺のはCだよ

時代の流れ的にアプリはそろそろC#
以前からjavaを使ってるところは変わらずjava
vbを使ってたところはvb.net

処理速度や実行効率を求める場合にC++を使う

C++で書くのが怖いってのは理解できてないから。
理解できないのは言語のせいでもあるしお前のせいでもある。
どっちにしろ理解できてる奴には関係ない話。

コンシューマゲーム屋としては、今んとこC++しかないからなあ
そりゃツールとかではスクリプトも使うけどさ

goで作れ

WG21のpapersも読んだことない人はお断りのスレですよ

>>670
仕事で作る場合は、スキルが上から下まで
いろいろなヤツが居て、チームで作るからな。
大きなプロジェクトになればなるほど。

そんな状況でC++を選択するのは、リスク管理
の意識が低すぎて、ＳＥ失格。
ハゲには悪いが、現実的に大規模開発にC++は向かない。

だから、スキルの高いやつだけが集まって、
あるいは個人で、シコシコやる分には、問題ない。
それが、研究だったり、趣味だったりするのだろ？

自分または身内で地雷踏んだからって、全ての企業の話に一般化されても困る
企業でもスキルの高い奴が集まってるとこは普通にあるしな

結局は「理解できないなら使うな」に戻るんだよ、企業だろうが個人だろうが

マ業界は本当にピンキリだからなぁｗ

で、結局、C++0A（仮）では、「理解できないなら使うな」度は、
パワーアップするのか？緩和されるのか？

自分で判断できないとはね

判断できないなら使うな

慣れた時の安全性や効率性は上がるだろうが、C++の採用自体が困難な組織だったら
0xになっても同様に困難だろう
まぁ、中級者向けのトラップみたいなのは減るんじゃね？

C++なんて使っていないという会社は多いぞ。

上でだれかが書いてたようにスキルのレベルが違うプログラマ
が共同で開発するには危険な言語だ。

組込系でももっぱらC言語が使われていてEmbedded C++さえ
使われていないそうな。

個人の趣味で使う、あるいはC++の達人がソフトウェアの核の部分を
一人で開発するのには向いているかもしれんが。

まして、C++0xなんかリリースしても一般のプログラマからは
｢勝手にゴチャゴチャやってろ。どうせ使わんから｣と却下され
てしまうのでは？ Modula2みたいにね。

マイクロソフトもC++/CLRだかC++/CLIだかの標準規格認定を
却下されてからはＣ＋＋に対してやる気なしだというし。

C++規格委員会そのものが世間から浮き上がったカルト集団
になってるんじゃね？

辻演説はそこまでの方向で

>>672
Goってウインドウツールキットってある？？

バカな社員のほうがまだマシだよな。
自称C++の達人とか邪魔どころか痛い。

土方向けの仕事は土方がやった方がいいのは事実だな

プログラマーにとって言語は目的ではなく手段だよね。
より生産効率の高い言語があったらそれを使いたいと思うでしょ。達人か素人か関係なく。

でかい売り物の GUI ソフトって C++ だと思うんだが、たいてい。
あと、メジャーなオープンソースでは WebKit とか Qt は C++ だよね

オープンソースは趣味で生まれる実用品だからね
付いてこられない開発者に悩まされる心配も全く無いし

クローズドソースでもC++使ってるって

>>681
>Embedded C++さえ
なんで「紗江」なのか知らんが、好き好んであんな糞使う人もあんまりいないだろう。
(よく解んない人が採用決めちゃうと渋々使うしかないかも知れんが)

×紗江
○さえ

Embedded C++は死んだ。
消えたのではない、死んだ。

C++はCのオブジェクト指向拡張だってことだよ。
組み込みのガーベジコレクションのない
オブジェクト指向言語はいくらでもあるんだから。

Embedded C++ってまだnamespace無いの？
正直templateよりも仮想関数よりも、namespaceが一番大事と思うんだが。

だいたいEmbedded C++って日本のCPUベンダーの泣き言の産物だろ
誰が使うか

C++を簡略化したサブセットを作ろうという発想自体は悪くなかったと思うんだ
問題は出来た物がサブセットになってなかったことだ

誰かSabusetto C++作れ
SubsetじゃなくてSabusettoなのは馬鹿専用の印な。

実際のC++プログラマは自分のサブセットでプログラムしてるしな。

そして相変わらずC++0xの話題は出ないこのスレ

VC2010でtemplate<class T, T N> struct ...ってできるけどこれって独自拡張？

え、今まで普通に使ってきたんだがMSの独自拡張だったんか・・・orz

>>701
まて、それだと
そのソースはWindows以外では使えないソースってことか？

・・・まあそう気を落とすな。

T が何型かわかるまで保留でいいと思うが・・・

>>700
違うと思う。boostでも使われてるし。
http://www.boost.org/doc/libs/1_41_0/boost/non_type.hpp

>>704
その
template <typename T, T n>
struct non_type { };
って何に使うんでしょうか？

組み込みで良く使われたQtとかSymbianとかがC++だけどどっちもオープンソース。
というか下位レイヤがクローズドソースのC++だと死ねる。仕様書もUMLも隠し、ドキュメントも不十分とか止めれ本当。

>>706
いきなり何の話をし始めるw
？

何で、Embedded C++にしつこく反応する。馬鹿か

shadow replying?

C++0xがなんのことか知らなくて、ただのC++スレと勘違いして来てる奴がいそうな気がする。

>>710
このスレをC++ 0x7と思ってるとかな

【次期規格】とか付けた方がいいのかねえ

C++プログラマならC++0xの存在は常識だと
思っていたのだが、そうでもなかったりするのか？

C++の次期機能の存在どころか…

ピンからキリまでいますからね

HTML5スレでも同じような話を見たなあ。
次期規格「HTML5」のスレなのに、HTMLスレのパート5と認識している奴がいるのでは？という話。

正式決定までドライでいたいし、そうあるべきだとも思う
戦いはそれから

次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている
スーパーセットの皮を被った本当はサブセット
へたするとテンプレートと C++ コアで機能拡大しながらその実簡素化という舵を切ってくれることを期待してる

テンプレート型のテンプレート引数で柔軟性を飛躍的に向上させた列概念を待っている

俺が会社でC++0xの話題を振ったところ意味がわかるのは20人中2人だった

>>700,701
遅レスだけどC++標準の仕様だよ。もちろん0x以前でも。

boost::non_type は何に使うのかようわからんけど、
boost::mpl::integral_c<T, N> で型として扱える定数をつくったりとか。

来年になったら、C++1xって呼ぶの？

来年限定で C++x0 (嘘)

Cは最初からC1xって呼んでるんだよな。

それは標準化委員会のやる気がないから

来年だったら　C++0A だから 0xでおｋ

だからそれは8進数リテラルだと……

C++0Z の次は C++0a ですね

>>726
そのうちコインやら王冠が出てきそうだな

>>727
それ何て マr ・・・ うわなにをするやめ

>>717
> 次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている

ドラフト読めよw

Wikipedia の仏語版だけ項目の見出しが C++1x という表記になってる。

エスプリってやつなんですね。

>>726
base64 だけであと 54年持つなw

64進数リテラルか。

base64だと0xは3377年。
範囲ではなく具体的な制定年を指定ということでは？

>>734
そうなのか！それなら今のペースでも余裕で間に合うな！

人類滅んでそうｗ

間違えたよ。リトルエンディアンで4307年、ビッグエンディアンで54032年

年号じゃなくてバージョン番号で命名すれば
何の問題ないのに、みんなバカなのか？

>>738
ドキュメントのバージョンが細かく上がってくからそういう風になったんでない？
ここで切りましょう。的な。

>>738
C++0xで何か問題でも起こりますか？

>>740
2100年問題が起きるだろ……

ハッシュで名前つければかぶらないよ。

ゴムを被せれば、ですね。わかります

そろそろマヤ歴を解読してC++0xが完成する日時を割り出す人とか出てきそう。

久々にC++0xの話題が続いてるな！

constexprで算出した値ってtemplate引数に渡せられる？

>>746
それが constexpr の目的の一つ。

>>745
気のせいだろ。

やっとnumeric_limits::maxが静的になるんですね！

つ boost::integer_traits::const_max

template<bool cond, typename A, typename B>
using static_if = typename boost::mpl::if_c<cond, A, B>::type;

template aliasを使えばメタ関数の定義が楽になって呼び出す時も
typenameとか::typeを書かなくて済むと思うんだけどあってる？

あってる。
どうでもいいがVC10betaは本当に0xの役に立つ機能だけごっそり実装されてなくて悲しくなってくるな。

VC10はauto、lambda、右辺値参照がサポートされているだけでも嬉しい。
VC9はスルーしていまだにVC8だけど、VC10は買うよ。

VC10はdecltypeがないんだっけ

beta2使ってるが既にあｒう

decltype(*this)ってやると落ちるけどな

int f() { static int x; return ++x; }
↑このような関数について、
C++ 2003 では f() + f() の結果は引数の評価順が未規定であることにより
一意に定まりませんが、関数呼び出しに伴うシーケンスポイントがあるので
未定義の動作とはなりません。

これは「シーケンスポイント」が無くなる次期規格でも同じなんでしょうか？
同じだとするとどういう解釈になるんでしょうか？

ドラフト N3000 を見たところ、 1.9 p15 に以下の記述がありました。
> If a side effect on a scalar object is unsequenced relative to either
> another side effect on the same scalar object or a value computation
> using the value of the same scalar object, the behavior is undefined.

上記の例で x について２回発生する副作用がお互いに sequenced となれば
いいようですが、式中の２つの関数呼び出し内にある副作用についての
sequencing がどうなるのか、よくわかりませんでした。上記の記述に続く
"When calling a function ..." で説明されている気配はあるのですが。

「元々結果が定まらなかったんだから、こっそり未定義に格下げしたって
　だれも困りゃしねーよ。」
とかいう話になってたりしないか心配です。

>>757
今までもこれからも、処理系定義だと
思ってたけど、違うの？

>>757
質問なのですが、標準C++ 2003において、
　static int x;
　(++x)+(++x)
これは未定義の動作ですよね？
ところが
　int f() { static int x; return ++x; }
　f() + f()
は
　> 関数呼び出しに伴うシーケンスポイントがあるので
不定の動作になるということでしょうか？
（つまり一応動作はするということでしょうか？）

>758
評価順序は不定(unspecified)だよ。
> 14882:2003 5/4
>Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual
>expressions, and the order in which side effects take place, is unspecified.

>>757,759
++の前値と後置を間違えてない?
(x++)+(x++) ならコンパイラ依存だけど
(++x)+(++x)の結果は無問題.
int f() { static int x; return x++; }
f()+f() も無問題. 不定な例にするなら
extern int x;
int f1() { return x++; }
int f2() { x *= 2; return x; }
で f1()+f2() とか

>757
引数の評価は関数実行前に sequenced、
一方、他に特に明示されていない場合は、関数の実行と(呼び出し側の)その他の評価との間は indeterminately sequenced
(sequenced だけどどっちが先かは unspecified)って書いてあるみたい。
ということで結論は従来通り未規定のままだと思われ。

>758
n3000 だと 1.9/15
> Except where noted, evaluations of operands of individual operators and of subexpressions of individual
> expressions are unsequenced.
でやっぱり処理系定義ではないね。
オーバーラップしても OK なので制約が緩くなってると考えてもいいんじゃないかな。

>>761
おっしゃるとおり、
前値と後置を間違えていたようです。
(++x)+(++x)の結果はいつも同じになるのですね。

>(x++)+(x++) ならコンパイラ依存だけど
こちらは未定義の動作ということでよろしいでしょうか？

>761
「コンパイラ依存」は implementation defined か undefined behaviour かどっちの意味で言ってる？
sequence point 間で 2 回値を変更しているから (++x)+(++x) はやっぱり undefined behavior じゃないの？

n3000 だとこんな例もあるよ？
f(i = -1, i = -1); // the behavior is undefined

特に↑の新しいルールだと実行がオーバーラップしうるからなおさら undefined behavior を示唆する気もする。

俺も
(++x)+(++x)はundefined behaviorだったと思うんだけど。

> f(i = -1, i = -1); // the behavior is undefined
は知らなかった。ありがとう。

やっぱC/C++言語って難しい。

>>764
ごめん、嘘つきだった. おっしゃるとおり、2回変更してるからアウトです
へんにまぜっかえしてしまってもうしわけない

>>761
(++x)+(++x)も未定義。
「どちらから評価するか」が決まっていないのではないよ。

>>762
> 一方、他に特に明示されていない場合は、関数の実行と(呼び出し側の)その他の評価との間は indeterminately sequenced

片方の f() が呼び出された際の ++x と、その外にあるもう一方の f() 呼び出しとの
関係を見れば indeterminately sequenced になるということですね。

片方の f() ともう一方の f() とが unsequenced なので、それぞれの中にある２つの
++x について見ても unsequenced になるんじゃ・・・と思ってましたが、従来どおりという
ことで安心しました。ありがとうございました。

そんなコード書くなと思うのは俺だけか？

auto_ptrはこういう文法にすべき。
classA * auto ptr = classA(1, 2, 3);

一種類しかスマポ使えない世界ですか

梶本裕介ってだれ？

長門かわいい

意味不明

エピステーメーみたいな痛さがあるよねｗ

馬鹿に嫌われるタイプの人ってこと？

ちょっとマ板にスレたててくるわ

スーパープログラマー 梶本裕介
http://pc11.2ch.net/test/read.cgi/prog/1260433369/

>>770
それはどんな動作を期待しとるん？
コピーなん？参照なん？

classA * auto ptr = new classA(1, 2, 3);
newを忘れてた。

型修飾子をオーバーロードするとカオスになるから

文法を変えずに、スマポが実装できるのがC++のいい所なのになあ。

生ポインタもライブラリにすべき。
ptr<int> p(new int(0));

むしろ * 演算子を無くして、全部 ptr<T> にすべきだと思う

const ref<array<ptr<int> > > a;

ここで1引数の場合は<>を省略できるルールを……

むしろこうなる悪寒。ドツボ
const std::ref<std::array<std::ptr<int> > > a;

Template typedefs あるし

何でみんな array に要素数を書かないの？

配列の要素数が10以下なら
要素数を省略できるんだよ

別にtemplate <typename T> class ptrを定義したっていいんだぞ
あと>>770は論外っつーかスマポをガチで使ったことねーだろ

コンパイラにとっては* autoくらいなんでもないくらい簡単だよ。

子供は外で遊んでなさい

お前はintrusive_ptrみたいなのやweak_ptrみたいなのが欲しい時にどうするつもりなんだよ

だだをこねる

ユーザー定義リテラル(だっけ？)が 0x では出来るんだから、
ユーザー定義ポインタが出来てもいいんでは。
T * hogehoge を hogehoge_ptr<T> に変換とか。

アホは発言を控えて！

>>797がいいこと言ったｗ

バカは自分のつまらない思い付きに興奮して固執するから困る

ユーザー定義リテラルさんは
>>6
で酷評されているw

まぁ、間違ったアイディアに囚われることは誰でもある
それに気付いて軌道修正できない奴は駄目だが

>>800
registerさんのイメチェンは何が良い？

registerさんはなんか将来もっと役立ちそうなところで使われるべき。

・・・それが何かはまだ思いつかないけどねw

autoさんってどんなところで出て来るんですか？？

ラムダ式扱うときにとか使うかもしれない
自分はラムダ式自体使ったことないけどね

>>805
Boostのラムダとは全然別物っていう代物ですよね確か。

・・・仕様が確定してから勉強しようと思います。

C++は複雑過ぎるから俺言語を作っちゃった方が速い。

何が何より速いんだよ

俺言語さんはDSLスレでも立てて一人でやっててくれ

>>804
std::vector<int> v(10);
for (auto i = v.begin(); i != v.end(); ++i)

イテレータの型名とかもかなりタイプ数減らせる。

>>810
すごいコードですね。
そんな使い方ができるのですね。

どうでもいい言語の表層をいじくり続けるのは
もういい加減にしたいですよ、まったく。
昔はC++コンパイラはC言語のコードを生成してた。
それがC++の仕様変更でできなくなったのなら、
C言語の次期規格C1Xで再びできるようにすればいいではないのか？

>>812
C++ to Cトランスレータがあれば極一部の人に便利ではあるかもしれないけど，
多くの最適化ができなくなるだろうし，
テンプレート回りのコンパイルとかはるかに遅くなるだろうから，
そんな処理系を作る人はいないんじゃないかね．

アホは発言を控えて！

バカは自分のつまらない思い付きに興奮して固執するから困る

>>815
C++0xの新機能を提案したヤツのことだろ。

暴れなさんな

逆に、Cのコードを吐くことができなくなるくらい深層をいじったと思えばいい。

というか

Comeauのこと、時々でいいから思い出してください

>>812 に Cfront0x でも作ってもらおうぜ

>>796
いらねーよ、そんなのw
ユーザ定義ポインタ(smart pointer)は今でもつくれるって。

>>811
テンプレートで使うときに、戻りの型が複雑すぎて手書きできない時なんかに便利。

>>820
それはあなたの仕事。
私はC1X委員会に働きかけて、
C++0xを完全にC1Xに変換できるようにします。
それができたら私は俺言語をつくりC1Xに変換するようにします。

C++03/0x->C89/99の変換ができるか出来ないかってだけなら、
どれもチューリング完全だから出来るに決まってるんだが
何をどうしたいの？

Cへのトランスレータっていえば、Valaがおもしろいよ。
ttp://live.gnome.org/Vala
このスレで存在を知ってる人ってどのくらいいるんだろうか？

たとえ、今でもC++がCのコードへ容易に変換できる仕様だったとしても、
結局、コンパイラの高速化などを理由に機械語やアセンブリ言語を
直接吐く処理系が主流になることにかわりはないと思う。

あったらあったで面白いだろうということは否定しないけど。

つーかトランスレータなんぞ作っても最適化がまともに掛からなくなるだけだろ
普通にコンパイルしてからC言語ディスコンパイラでも使ってろ

必要な人は作ればいいし
そうでない人にとってはどうでもいい話

>>827
お前の持ってる常識なんて一瞬で翻されるよ。

>>829
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1013807615
バカはこれを100回読みな

>>827
最適化が何なのかもわからないでよく言えるな。
具体的にC++コンパイラでやってる最適化の何が
トランスレータでできないのか言ってみろ。

そんなやりとり無駄なだけ。
暇を潰したい人だけ参加しな。

>>832
わざわざ無駄レスして相当の暇人ですね。
それでも一つも思い浮かばないわけですね。
他の暇人のみなさん、じっくり考えて下さいね。

当方java使いですが、
C++って使ってて、生きた心地しなくないですか？
メモリ管理も動作とろいし、パフォーマンスもさほど高くないでしょ。
みんなjavaに来いよ。

そんな餌に釣られないクマ

C++使っててむしろ快感を覚える俺は変態だろうか。


ところでいつになったらC++0xが正式に採用されるの？
現時点での現実的な見込み時期ってあります？

>>834
> メモリ管理も動作とろいし
とろい理由を述べよ
ハスケルに目覚めてJava捨てたんじゃなかったのか?

>>837
生成が遅くて、回収にも時間がかかると書いてあった。
javaは生成がC++より6倍くらい速くて、回収はほとんど０。

マイクロベンチマークならね

なんだ、ただの又聞きか

Hey, C++ Programmer EveryOne!

My word is " C++ is bitch !! ".

Good night.

ねぇ、なんで@itのサイトにC++のページがないの？

>>833
> わざわざ無駄レスして相当の暇人ですね。
ここはお前の喧嘩だから好きにしてくれればいいけど

> 他の暇人のみなさん、じっくり考えて下さいね。
なんだテメェは。失礼な。

>>842
土方サイトだから

>>836
ISO/IECの規格は、成立まで投票を3回(3ヶ月・4ヶ月・2ヶ月)しなきゃいけないんだけど、
1回目の投票が終わったところで例のconceptの一件が発生したので、多分最初からやり直し。

来年の7月からは投票制度が変わる予定なので、若干期間が短縮されるかもしれないけど、
どれだけ順調に行っても来年後半〜再来年頭より早まることはないと思う。

>>824
> どれもチューリング完全だから出来るに決まってるんだが
無限長のテープを持ったチューリングマシンを用意してから言え。

いや、事実上問題にならないだろ、その辺は

そうですよねC++がトランスレータでも何の問題もない。

もちろん、全然問題ないですよ。存在しないことを除けば。

可能かどうかについては問題無い
実用的かどうかについては問題あり

理論上prologにだって変換可能

　void (*signal(int, void (*)(int)))(int);
って「統一された関数宣言構文」ではどう書けるの?

[] signal(int, [](*)(int)) -> [](*)(int);

これでいいのか自信は無い

-> void は省略可能なのか

>>853
なんか, スゲぶさいく
# lambdaちゃんそっくり

lambdaちゃんの妹です

どうせ判り切ったこと書きますが、C++2xはHaskellを大きく取り込むだろう。

というか、conceptはtype classを取り込んだも同然

そもそも
C++2xは来るのだろうか？

>>859
ふゆやすみ？

冬休みが楽しみな美少女中学生

>>860
何かおかしい事言った？

だから、冬休みになったのならその間にHaskellを勉強しておけってこと。

std::threadってどのヘッダに入ってるの？

<thread>

マジで言ってます。
HaskellのエッセンスをC++に生かす研究している人いませんかね。

関数型プログラミングなら今でもテンプレート使って出来るけど？
Haskellのエッセンスって何

遅延評価かも

>>261で出来るよ

まあ、Haskellといえば遅延評価とカリー化と型クラスだよね
でもconceptが入らなくなっちゃったし

実際にHaskellで書いてて他との違いを一番感じるのは無限上等なとこなので
やっぱり遅延評価か

カリー化はクロージャのシンタックスシュガーでしかないし
型クラスはオーバーロードだったり継承だったりするので
やっぱ遅延評価だよね

型推論も忘れないでやってください

>>871
> 型クラスはオーバーロードだったり継承だったりするので

これはconceptもtype classも理解してないと言わざるをえない。
Multiple constraintsもassociative type constraintsもC++ 2003にはない。
Generic programmingに重要と考えらえている要素がない。
個人的にはretroactive modelingが弱いのがきつい。

それからC++はconcept baseの0xになっても、
modular typeのサポートが弱い。Cを引き摺ってる。

ただ型の話はDouglas Gregorと愉快な仲間達が
すっかりやっちゃってるので、>>866の言うような余地は余りない。

シンタックスシュガーだって言語のエッセンスとして重要だぞ
カリー化有りか無しかは言語の特徴として特筆すべきことだと思う

カリー化は複数引数の関数を内部的にどう扱ってるかの違いだろう。
C系統の言語なら別に1番目の引数に特別な意味がある訳じゃないし

まあ、boost::bind がカリー化やっちゃってると言っても過言ではないかも
0x では型推論してくれるのでHaskellのカリー化より便利か

bindはまるで関数がカリー化されていたかのように
引数を部分的にapplyするためのテンプレート。

くだらね。三流どもが。

>>878
難しくて分かりませんって言えよ。w

全く理解できなくて一言の反撃すらできないけどとにかく否定したい、という気持ちが
凝縮されてるな

カリー化なんて何も難しいことないけどな
要は引数を1つずつ順番に使うってだけの話だし

まぁカリー化以外の話もしてるし、カリー化が何なのかが分かっただけじゃ反論は
始められないしな

>>881
つ 関数を引数を一つづつ適用できるようにする

カリー化ってあれだろ、筋肉少女帯のほら

ナンってイースト菌使うっけ？

>>884 それは印度化。

bindをカリー化っていっちゃうのはちょっとな

3引数関数をcurry(f)すると
f(x)(y)(z)
f(x, y)(z)
f(x, y, z)
が全部できるとかならカリー化って感じはするが

>>887
fusionで上手いこと出来ないかな？

このへんの話を思い出した
ttp://d.hatena.ne.jp/kmizushima/20091216/1260969166

単純公理好きの数学だから＞一引数関数だけの世界
実際意味ねー

カリー化と言えばunlambdaですね！

カリー化とかHaskellとかって結局何が得意なん？

使い回し

そもそもcurry化って、
なんでcurryなのよさ。

それを考えた数学者の名前

>>895
そうだったのか。
サンクス。

印土人もびっくり

>887
とりあえずでっちあげ。Boost のバージョン違いで codepad だと動かないですが。
http://codepad.org/8h1gFMwQ

>888
fusion をどう使うイメージでしょうか。
引数を fusion に溜めておいて一時オブジェクトの破棄時に関数呼び出し？

>>896
Haskell Brooks Curry と申します。

カリー化って実用性ってあるの？

>>900
またそーやって痛いとこ付いちゃうwww

痛い奴だ

>>900
・curry化概念は実用的です。
・C++はcurry化がなくても実用的な言語です。
・curry化したければboostのLambdaを使って出来ます。
・一般にcurry化そのものよりも部分適用の方が有用です。
・関数がcurry化されているかのように部分適用するために、bindがあります。

カリー化があることで引数の順番に利益主導の法則が生まれる実利があると思う

と言ってみるものの、カリー化があると書いてて楽しいのなんのって

>>898
fusionで引数を与えて、再帰させならが引数を自動的に減少させていくような記述ができないかな？

boost::tupleの実装ってカリー化っぽくないか？

ただなんとなく。

カリー化って言うからわかりにくいんであって、遅延束縛（late binding）とか
部分束縛（partial binding）なら普通に理解できるだろう（と思う）。

数学的には、部分束縛できるような形に、もとのn引数の関数を
m（m < n）引数に変換するのがカリー化

関数の部分適用と併用して
普通の多引数関数を高階関数のように使える
ってぐらいしか使い道がわからないな

>>909
operator()に対して、
関数を引数に適用する
ってぐらいしか使い道がわからないな
って言ってるようなもの。

>>909
引数の型があらかじめ定まっていないから、色々なデータに対する操作が１引数関数１個で表現できるんだからすごいと思うよ。

>>910
> 関数を引数に適用する
ちなみにそれ以外の使い道なんてあるの？

>>911
それ多相ラムダ式の話じゃないかね？

何の話や、え？
加齢化？

アホは発言を控えて！

カリー化って、いちいち bind しなくてもいい、という便利さもそうだけど、
すべての関数が部分適用の機能を自動的に持ってる感覚というか、
考えることが一つ減って自由になるみたいな感覚がある。

OCamlの例だけど、リストを条件でフィルタして変換して全部足す、
みたいな処理を、
　fold_left (+) 0 (map to_xxx (filter is_xxx lst))
と書くところを、
　let (|>) x f = f x
みたいな演算子を定義して（型は 'a -> ('a -> 'b) -> 'b）、
　lst |> filter is_xxx
　　　|> map to_xxx
　　　|> fold_left (+) 0
などと(見やすく)書いてみたりとか、さらに引数順が違うユーザー関数
xmap lst f があって、これを map の替わりに使いたいとかなったら、
　let flip f x y = f y x
とか汎用的に定義しておけば（型は ('a -> 'b -> 'c) -> 'b -> 'a -> 'c）、
　... |> flip xmap to_xxx |> ...
と書けるとか。

型推論とかラムダの記法のせいもあるけど、引数回りのインターフェースを
合わせるのが楽になって、あまり引数を bind してるって感覚が薄くなるのが
便利なのかな。

> リストを条件でフィルタして変換して全部足す、
> みたいな処理を、
> 　fold_left (+) 0 (map to_xxx (filter is_xxx lst))
> と書くところを、
> 　let (|>) x f = f x
> みたいな演算子を定義して（型は 'a -> ('a -> 'b) -> 'b）、
> 　lst |> filter is_xxx
> 　　　|> map to_xxx
> 　　　|> fold_left (+) 0
> などと(見やすく)書いてみたり
それovenとeggで(ry

>>915
誰がアホや？え？

>>898
関数オブジェクトの引数の数をコンパイル時に取得する手段がないと汎用的に書けないねぇ
arity_of<F>::value みたいな

というかそもそもオーバーロードされてるとダメか？
オーバーロードとカリー化って相性悪そう

コンセプトについて再考

conceptを捨てたC++0xに未来は無い

C++1xで入るだろ

今から次期規格作っても2xになる予感がします

もうこの際だからC++xxにしちまえ

c++++

コンセプトってパターンマッチの範囲を狭められれそうな気がするからコンパイルが速くなるんじゃないかな？みたいな？
もしかしてenable_ifをしっかり書けばコンパイル速くなる？

--(C++)

>>927
右辺値を--するとは、乙なことするな。

今日中に決まるよね？

>>928
operator++が参照を返すかも知れないぞ
それより不必要な括弧が言語名につくことこそ問題だと思う

>>930
そんなクソコードまで予想してなかったわ。

>>927
それってマイナスじゃん

>>932
何が？

戻りが減っちゃってるよ。

>>925
C#ならもうあるじゃん

あと5時間弱+9時間しかねーぞ
発表ﾏﾀﾞｰ?

9時間って何かと思ったら時差か。

UTC計算だね。
UTC-12のタイムゾーンを基準にするなら、更に12時間程度余裕がある

素直にC+=2

俺たちの0xはまだ始まったばかりだ！

始まってもいねぇなw

あるいは終わった・・・ってところかも

>[905]デフォルトの名無しさん<sage>
>2009/01/01(木) 02:18:43
>いよいよ09年なわけだが
>
>[906]デフォルトの名無しさん<sage>
>2009/01/01(木) 03:41:14
>今年中に纏まるとは思えないのだが。
>
>[907]デフォルトの名無しさん<sage>
>2009/01/01(木) 03:59:11
>日本限定なら09年度という便利な言葉が使えるんだが。
>
>[908]デフォルトの名無しさん<sage>
>2009/01/01(木) 04:04:08
>それでも猶予は4ヶ月しか増えないのだが
>
>[909]デフォルトの名無しさん<sage>
>2009/01/01(木) 06:57:41
>いや、そもそも0x年まであと27年もあるわけだが
>
>[910]デフォルトの名無しさん<sage>
>2009/01/01(木) 07:08:47
>C++0xa
>
>[911]デフォルトの名無しさん<sage>
>2009/01/01(木) 09:10:41
>(++0x)
>だからあと2年猶予があるぞ

やっと待ちに待ったゴールがきた。
誰か、公式の完成版仕様書のリンク貼れよ

>>944
ggrks　www

g++4.5.0 は「Unicode string literals」をサポートしてないの？
(char16_tとchar32_t)

>946
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html
ここだとサポートしてる事になってるけど実際には動作しないって事？

このスレには、

　　struct foo { auto f()->int && { ... } };
　が　int f() &&　か　int && f()　のどちらと
　解釈されるか？

という問いに正解できるヤツいる？

>>948
個人blogのネタコピペかっこわるい。

>>949
よく知ってるなw

ヒロヒト…

馬鹿ばっかし・・・

>>947
cucharがない

"Unicode string literals" っつったら u"char16_t" とか U"char32_t" とかの言語機能側を指すんじゃないの？
ライブラリ側は
> support for char16_t, char32_t

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
見る限りは C ライブラリ側の対応待ちじゃないかと思う。

つーか、いい加減に
C++０ｘがいつ発表されるのか決着つけてくれだれか

0xは90年待たないと…

C++0x → C++1x

>>946
typedef __CHAR16_TYPE__ char16_t;
typedef __CHAR32_TYPE__ char32_t;

C++0xってすでに二年前にC++010になってるじゃん
今年は012ですよ皆さん。

16進なのか8進なのか10進なのかは議論の分かれるところですなぁ。
俺は16進だと思う。

00
0x
x0
xx

二進数説

そんなんどうでもいいから
早くリリースしろ

と叫ぶしか俺らにはできることがない。

> 早くリリースしろ
同感

とは言うものの現 C++ の拙速感（特に STL）はもうたくさん
巧遅を早くやれってことだけど、どないもこないも・・・

>>961
奇才現る！！

C++は2000年頃にすっかり使わなくなって10年程になるのだが、
今、C++0xの内容も含めてリハビリするとしたら、どの辺りの
ドキュメント・書籍がおすすめ？和書洋書問わず。

ヒロヒロが著すC++0x本を待て

×ヒロヒロ
○ヒロヒト

>>965 >>1

>>968
なんかURLが羅列してあるだけなんですが

なにかもんだいでも？

0xの平易な解説書はまだ無いんじゃね
処理系もまだβ臭ぷんぷんなのに

C++の規格を読むと鬼難しい規則が膨大に羅列されていいる。
それでもなお規格の開発はすすむ。
C++はもう限界を越えて破滅の道を進んでいるんでしょうね。

>>972　限界とは？具体的に

auto とか簡単なものは簡単なんだが
右辺値参照とかどうなのよって感じ
あれば高速化に寄与するのは分かるけど
それ使ったコードは他の人に分かるんかと

右辺値参照はコンテナとかスマポとかのライブラリが対応するだけで、ライブラリの使い手は存在を知らないままでも高速化ができちゃうね。

>>975
それってある意味とてもすごいことだよな。
でも逆に自分がライブラリを書くときは
そこまで考えて書かないと
こいつなにやってんの？って思われるってことか？

これからC++コンパイラ作ろうとする奴がいたら死ぬな

しかもgccが
　標準ライブラリを利用してもソースコード公開不要
てなライセンスだから、それを越えて実装しないと
実質的に意味ないよね？

>>975
右辺値参照の準備は、const hoge func()をhoge func()に変えておく必要があるけどな。

>>979
そういやそうだったな。
Effective C++ に書いてあった内容が
現在にそぐわなくなるわけね。

>>976
これまでの開発で右辺値参照が欲しいと思ったことがある奴にとっては大変ありがたい
そう思ったことが無い奴にとってはこれからも不要なので気にしなくてよい

>>981
いままでは
テンポラリオブジェクトはconst参照で捕まえていたが、
あれがnon-constに捕まえられたら少しは早くなるだろうなぁ
と思ったことはある。