09/09/18 22:26:17
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)
Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
C++0x
ｽﾚﾘﾝｸ(tech板)
C++0x 2
ｽﾚﾘﾝｸ(tech板)
C++0x 3
ｽﾚﾘﾝｸ(tech板)
C++0x 4
ｽﾚﾘﾝｸ(tech板)
C++0x 5
ｽﾚﾘﾝｸ(tech板)
C++0x 6
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/09/18 22:27:46
>>1死ね
3:デフォルトの名無しさん
09/09/18 22:34:15
嫌です（^ε^）
4:デフォルトの名無しさん
09/09/18 22:36:02
C++0xがいつ規格制定されるかは、髪のみぞ知る。
5:デフォルトの名無しさん
09/09/18 22:37:59
C++学園の人々
○コンセプトさん
ついに一度も登校することなくお星様になってしまった。
この事件によって学園に激震が走り、入学式が一年延期になる事態に。
彼女の再起はあるのだろうか。
○ラムダさん
コンセプトさんに代わって新入生代表に抜擢されることに。
だが服が汚い上デザインが二転三転してるのでよくいじめられる。
コンセプトさんと同じ目に遭わないかと内心ビクビクもの。
○右辺値参照さん
一足先に本格的な通学を始めつつある新入生。
よく出来た子として先生方には評判が高いが、
気難しいので普通の生徒たちからは敬遠されている。
○拡張for文さん
forさんの妹。コンセプトさん問題の一番の被害者。
きったない服で通学することになりテンションガタ落ち中。
○type_traitsさん
ライブラリ科の新入生。
コンセプトさんの代役としてにわかに注目を集め始めた。
思わぬスポットライトに浮かれすぎで最近テンションがやばい。
○static_assertさん
type_traitsさんの相方としてこちらも注目を集める新入生。
面倒な相手との仕事が増えそうで最近憂鬱。
assertさんの妹だが、マクロ科と予約語科の立場の違いで仲が悪い。
6:デフォルトの名無しさん
09/09/18 22:38:09
○initializer_listさん
vectorさんが泣いて喜ぶコンテナ部悲願の新人。
だが似たような服を着た生徒が元から多いので、一部では
「またややこしい奴が来た」と陰口を言われているらしい。
○テンプレート可変長引数さん
テンプレ部が泣いて喜ぶ期待の新人。部の熱狂的な歓迎ぶりと
「変態が増えた」と嘆く周囲の温度差に困惑中。
stdargさんとは顔がよく似てるが血の繋がりはない。
○autoさん
地味で消えそうだった子が一転、イメチェンで今やモテモテに。
そのあまりの変貌ぶりに周囲は戸惑いを隠せない。
最近まで同じ立場だったregisterさんの胸中はいかに…
○decltypeさん
autoさんの妹の新入生。姉が記憶クラス科にいた過去は知らない。
姉に劣らぬ人気者だが、服装のちょっとした違いで性格が変わる面倒な一面も。
○ユーザー定義リテラルさん
「わかりにくい」「見るからにきもい」「関数さんでいいじゃん」と
すこぶる評判の悪い新入生。強く生きていって欲しい。
○nullptrさん
「今さら来られても……」「なんで今までいなかったの？」という
心ない陰口に傷ついている地味な新入生。
○long longさん
え？新入生だったの？
○禿
校長先生。
7:デフォルトの名無しさん
09/09/18 22:46:04
>>5-6
乙
8:デフォルトの名無しさん
09/09/18 22:54:08
> きったない服で通学することになりテンションガタ落ち中。
ここで爆笑した
9:デフォルトの名無しさん
09/09/18 22:57:04
・Raw String Literalさん
なんだかよく分からないアクセサリーを頭とお尻に付けている。
しかもアクセサリーは日替わり。
・auto_ptrさん
落第。一応、まだ学校にはいる。
・unique_ptrさん
auto_ptrさんを蹴落として進級してきた。
・Smart pointerさん
とても頭がいいが、循環参照も扱えるかどうかは、学校によって異なる。
・Unordered associative containerさん
いつも、とても大きなカバンを引きずっている。
ただし、カバンから物を取り出すのはとても早い。
・Regular expressionさん
頭は良いらしいのだが、何を言っているのかよく分からない。
周囲からは中二病だと思われている。
・Atomic operationさん
細かいことばかり気にしている神経質な子。
口癖は、「だってその可能性はゼロじゃないし～」
・threadさん
カバンも持たずに登校してくるミニマリスト。
ペンと紙一枚あればそれで十分でしょと言い張る。
どうしようもないときは、魔法の言葉、「ねぃてぃぶ・はんどる～」を唱えると、とりあえず何とかなる。
10:デフォルトの名無しさん
09/09/18 23:13:33
・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さんと仲が良いらしい。
11:デフォルトの名無しさん
09/09/18 23:21:05
だんだん説明が投げやりになってるなｗ
あとは擬人化だ
絵師を呼べ！
12:デフォルトの名無しさん
09/09/18 23:30:46
lambdaが消されることはまずないよ。
range-based forとかuser defined literalsは、このままだと問題が多いと思うけれど。
13:デフォルトの名無しさん
09/09/18 23:35:16
>服装のちょっとした違いで性格が変わる面倒な一面
括弧のことか。
14:デフォルトの名無しさん
09/09/19 02:35:20
>>12
user defined literals の問題って何？
15:デフォルトの名無しさん
09/09/19 03:22:07
>>14
ユーザー定義リテラルの名前は必ずアンダースコアから始まらなければならない。
ただし、アンダースコア二つ、アンダースコアに続いて大文字の名前は予約されているので使えない。
じゃあ、アンダースコア一つに小文字か数字ならオッケーかというと、
アンダースコア一つから始まる名前は、グローバル名前空間において、予約されているので、注意が必要。
だから、現行のドラフトを忠実に守ろうとすると、
ユーザー定義リテラルは、必ず何らかの名前空間の中で定義しなければならない。
そして、実際に使う時は、そのスコープの中で、using directiveやusing declarationすることになる。
けど、誰がそこまで深く考えるかね。
後々互換性の問題が発生しそうで怖い。
16:デフォルトの名無しさん
09/09/19 03:55:29
>>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 だけ」って明示して
もらうといいのかな？
17:デフォルトの名無しさん
09/09/19 04:42:55
すると、そのLiteral suffix identifiersとやらは、nameじゃないわけ？
18:デフォルトの名無しさん
09/09/19 05:00:00
>>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 の
一部であると考えられる。
19:デフォルトの名無しさん
09/09/19 05:03:38
>>16
_で始まらないユーザ定義リテラルが予約されるのはライブラリ的な都合ではなく
将来のバージョンのC++における字句解析の都合じゃないんかね。
20:デフォルトの名無しさん
09/09/19 05:16:52
>>19
そういう用途も考えられてるかもしれないけど、たとえばライブラリ内の
クラスである std::string を返すようなユーザ定義リテラルを字句解析の
レベルに置くようなことは考えにくいわけで、ライブラリ的な都合ではない
と言うのは当たらないと思う。
そもそも、名前の予約がライブラリ的な都合なのか字句解析の都合なのか
というところは使う側にしたらどうでもいいような気もする。
21:デフォルトの名無しさん
09/09/19 05:34:10
>>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なんじゃないの。
22:デフォルトの名無しさん
09/09/19 05:37:29
何にしても名前空間内にあるかどうかで特別扱いするのは無理だろう
23:デフォルトの名無しさん
09/09/19 06:02:11
>>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 で定義される
ものとは違うようで、ここにも混乱のもとがあるみたい。
24:デフォルトの名無しさん
09/09/19 06:05:39
アンダースコアひとつに小文字か数字の名前は、グローバル名前空間において予約されているに過ぎない。
だから、何らかの名前空間の中で使う分には、規格上、まったく問題はない。
問題は、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がこの辺のことをわきまえず、規格違反のコードが世にあふれ、後のリテラルの規格改定に影響を及ぼすこと。
25:デフォルトの名無しさん
09/09/19 06:17:12
>>23
あー、たしかにuser defined literalの識別子だけでは、entityたりえないようだなぁ。
すると、user defined literalの識別子は、予約語の制約を無視できるという事になるのか。
26:デフォルトの名無しさん
09/09/19 06:25:33
>>25
「グローバル名前空間内の名前」についての予約名は無視できるけど、 >>16 に
あるとおり _X や __x はやっぱりダメなんで、微妙な隙間を使うことしか許されていない
という嫌な状況であることにはちがいない。↓この部分ね。
> 規格違反のコードが世にあふれ、後のリテラルの規格改定に影響を及ぼすこと。
27:デフォルトの名無しさん
09/09/19 06:30:25
ユーザ定義リテラルなんて演算子オーバーロードでDSLつくっちゃうような人らにしか使われなさそう
28:デフォルトの名無しさん
09/09/19 06:30:59
>>26
ごめん。なぜアンダースコア二つから始まる名前、及びアンダースコアひとつに大文字で始まる名前がダメなんだ？
user defined literalの識別子は「名前」じゃないんだろ？
29:デフォルトの名無しさん
09/09/19 06:42:00
>>28
そいつらは "reserved to the implementation for any use" ということで、
処理系定義のマクロやキーワードとして使われている可能性があり、
該当する場合はそもそも文法上の identifier として認識されない可能性もある。
その場合はパース時点で >>21 にある構文にマッチしなくなる。
30:デフォルトの名無しさん
09/09/19 06:43:34
それは処理系の都合であって、確かに、大方の処理系はそうだろうけど、
規格上は、関係ないのでは。何しろ、名前じゃないんだから。
31:30
09/09/19 06:45:30
いやまあ、もちろん、現実的には、回避した方がいいことには変わりないんだが。
32:デフォルトの名無しさん
09/09/19 06:45:43
>>4
もうない。
>>5-11
よそでやれ。
>>28
03 の頃から決まってる。
33:デフォルトの名無しさん
09/09/19 07:13:32
>>30
言いたいことがよくわからない。
「それは処理系の都合」の「それ」って何？
「大方の処理系はそうだろう」の「そう」って何？
「規格上は、関係ないのでは」の「関係ない」って何と何の話？
34:デフォルトの名無しさん
09/09/19 11:54:17
リテラルなんてconstか#defineして使うものなんだからユーザー定義リテラルって要らなくないか？
直接コードにリテラルを書くと保守性が悪くならない？
35:デフォルトの名無しさん
09/09/19 13:05:50
>>33
ひとつ上のレスに対してのレス。
現実の処理系の実装どうあれ、
規格上では、名前に対しての予約語であるから、
user defined literalにまでは及ばないという話。
36:デフォルトの名無しさん
09/09/19 14:25:15
>>35
>>23 の最後にも書いてあるけど、 17.6.3.3 Reserved names では "name" が
マクロ名も含むなど、 Basic concepts で定義される "name" と違う意味でも
使われている。このため、厳密に読もうとすると、破綻している。
name の定義が見直されたのはわりと最近で、以前から identifier と name は
混同されがちであったことから、その混乱の一部と考えられる。
URLﾘﾝｸ(www.open-std.org)
URLﾘﾝｸ(www.open-std.org)
C99 のほうを見ると "7.1.3 Reserved identifiers" となっていて識別子に
ついて予約が行われている。これに倣って C++ の 17.6.3.3 も全面的に
書き直すのがよさそう。
そもそも name と macro name がオーバーラップしない別物として定義されて
いるあたりも問題な気がする。
37:デフォルトの名無しさん
09/09/19 20:05:44
>>36
たしかに書き直して欲しいね。
38:デフォルトの名無しさん
09/09/19 20:07:03
Intel C++ compilerのバージョンがあがって、
C++0xがどれだけつかえるのかと思えば・・・
あんまりだね
Windows7対応かとおもったら、ビルドした実行プログラムが
とまってたやつ修正だけか
39:デフォルトの名無しさん
09/09/19 20:31:43
>>38
intel c++ 11.1のhelpにはrvalueが使えそうに書いてあるので、試したけどどうもうまく動かないのはなぜ？
class A
{
int a1;
int a2;
};
void test(A&& s) //ここの2個目の＆でエラーが出る。
{
}
40:デフォルトの名無しさん
09/09/20 00:30:04
>>39
右辺値つかえそうな記述とかあった？ないと思うよ
autoとラムダぐらいじゃないの？
テンプレートらへんも全然だったし・・・
41:デフォルトの名無しさん
09/09/20 00:51:03
「rvalueが使えそう」「右辺値つかえそう」
これじゃ意味がわからんだろ。右辺値参照って言えよ。
42:デフォルトの名無しさん
09/09/20 02:57:10
>>40
URLﾘﾝｸ(wiki.apache.org)
43:デフォルトの名無しさん
09/09/20 03:00:51
URLﾘﾝｸ(software.intel.com)
＞ we'll be supporting the rvalue feature in our next major release.
だそうだ
44:デフォルトの名無しさん
09/09/20 09:01:53
訳 : おにいちゃんおかえりなさい！
45:デフォルトの名無しさん
09/09/20 10:00:50
>>42のR-Value Referencesや、ヘルプのQstdの説明にrvalueの文字が見えたのてっきり使えると思ってました。
次のバージョンでサポートされるんですね。
コードに突込みが入らなかったので使い方はそれでよさそうか。
ありがとうです。
46:デフォルトの名無しさん
09/09/20 11:57:49
>>36
オーバラップうんぬんはどういうこと?
名前空間的な話?
そんなのいまさら変えられないでしょ。
予約語をきっちり定義すればいいだけの話。
47:デフォルトの名無しさん
09/09/20 12:03:59
>>46
常識的に考えて "name" ⊃ "macro name" なんだが、 C++ 標準規格の中では
それらはまったくの別物であって、わかりにくい、ということ。
48:デフォルトの名無しさん
09/09/20 13:37:48
つまりマクロ氏ねと
初心者の頃にCreateWindowでハマった数日を返せと
49:デフォルトの名無しさん
09/09/20 18:07:18
話の流れぶった切るけど
constexpr があれば static const の代替としても使えるのかな？
あと、In-class member initializers は無名クラスの
メンバー初期化にも使えると考えてよい？
50:デフォルトの名無しさん
09/09/20 18:43:20
constexprはメモリ上にどの様に配置されるかは実装依存だがコンパイルタイムに計算が終了するので速い。
static constで修飾したものの完全な代替として使えるわけじゃない。
51:デフォルトの名無しさん
09/09/20 18:49:17
テーブルの生成に使うのが一般的なのかな
52:デフォルトの名無しさん
09/09/20 18:51:52
constexprに基本的な数学関数が含まれるとうれしいんだが。sinとか。
53:デフォルトの名無しさん
09/09/20 18:56:54
>>52
言語の枠内でconstexprとして実装できない以上、
ライブラリ関数の仕様として要求すべきじゃないんじゃないかな。
コンパイル時に計算されてほしいってだけなら、
最近のgccはmfprだかgmpだかを組み込んで出来るようになってるみたいだね。
54:デフォルトの名無しさん
09/09/20 19:59:59
近似式で書かれた関数csinとかを用意すればコンパイラが計算してくれないかな。
55:デフォルトの名無しさん
09/09/20 20:03:22
多項式近似と引数剰余で何とかなるといいね。
56:デフォルトの名無しさん
09/09/20 20:24:29
kbk氏はUsenix88-lexic.pdfは知ってるのかな？
57:デフォルトの名無しさん
09/09/20 22:40:28
>>41
意味わかってくれてありがとう
58:デフォルトの名無しさん
09/09/20 22:58:14
>>54
ぶっちゃけPerlとかで定数埋めたソースを生成した方がマシだと思うな
というか、boostのソース眺めてたら実際に生成用のPerlが落ちてて笑った
59:デフォルトの名無しさん
09/09/20 23:11:24
constexpr再帰が認められれば級数計算も書けるはずだ
60:デフォルトの名無しさん
09/09/20 23:22:27
それ許可するとconstexprでメタプログラミング始める人が出るから危険。
61:デフォルトの名無しさん
09/09/20 23:25:20
constexpはそもそもメタプログラミングなわけだが。
62:デフォルトの名無しさん
09/09/20 23:59:24
どうせテンプレートで再帰できるんだから、constexprの再帰も認めてしまえ、むしろこっちのほうが見た目は自然っていう意見を見たことがある。
63:デフォルトの名無しさん
09/09/21 09:39:40
普通はそう思う
64:デフォルトの名無しさん
09/09/21 10:19:22
コンパイル時にステップ実行ができるデバッガーが欲しくなるね。
65:デフォルトの名無しさん
09/09/21 10:36:31
C++プログラマは副作用のないプログラムに最適のデバッガも使えなければならない。
66:デフォルトの名無しさん
09/09/21 12:52:50
>>59 収束しないと永遠にコンパイル終わらないんじゃないか？
67:デフォルトの名無しさん
09/09/21 13:01:06
なるほどなconstexpr関数が終了することを保証する必要があるんだな。
68:デフォルトの名無しさん
09/09/21 13:59:40
適当に精度を決めればおｋ
69:デフォルトの名無しさん
09/09/21 14:03:07
ifかmatch withが必要だな
70:デフォルトの名無しさん
09/09/21 14:15:18
条件演算子があるから大丈夫
71:デフォルトの名無しさん
09/09/21 14:23:57
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);
}
意外と面倒臭いすなあ
72:デフォルトの名無しさん
09/09/21 20:10:33
>>71
そんなもんじゃね
73:デフォルトの名無しさん
09/09/21 22:32:13
そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか
74:デフォルトの名無しさん
09/09/21 22:35:23
minテンプレート関数が最初の例題。
char,int,float,double用に関数を何個も作らなくてもいいんだぜ！えっへん
75:デフォルトの名無しさん
09/09/21 22:36:49
それMPLじゃなくね？
76:デフォルトの名無しさん
09/09/21 23:10:25
Generic Programming
Template Metaprogramming
Boost.MPL
どれも日本語の情報少ないよね。
77:デフォルトの名無しさん
09/09/21 23:15:03
>>75
template<typename T, typename U>
result_type min(T x, U y) {return x < y ? x : y;}
さて、result_typeの部分にはなんと書いたらいいんだろうという話から始まるんだよ、きっと。
78:デフォルトの名無しさん
09/09/21 23:30:09
C++ Templates: The Complete Guide
と
C++ Template Metaprogrammingは原著で我慢するから、
C++0x対応のテンプレート本が出たときには早く和訳してくれ
79:デフォルトの名無しさん
09/09/21 23:33:26
むしろその二つを和訳するから0xのテンプレート本は我慢してくれって雰囲気だな
80:デフォルトの名無しさん
09/09/21 23:35:59
ごくふつーのメタ関数の書き方を何通りか紹介すれば大体分かるんじゃね＞MPL
81:デフォルトの名無しさん
09/09/21 23:57:53
そのごくふつーのメタ関数を、理解させて、書けるように教えるためには、
C++ Templatesぐらいの厚みのあるページ数で解説しないといけないわけだが。
82:デフォルトの名無しさん
09/09/22 02:30:29
そうかなぁ
割と典型的なパターンは決まってる気もするけど
まぁパターンで教えちゃっていいんですかって話ではあるけど、関数の呼び出し規約
とかしっかり把握させる教科書も無い訳だから別にいいような気もしたり
ってのはちょっと話が違うか
83:デフォルトの名無しさん
09/09/22 03:24:57
普通にCの処理書くのとは考え方が根本的に違うからな
再帰使いまくりだし
84:デフォルトの名無しさん
09/09/22 11:03:25
そうかまず関数型言語を教えるところから始めないと
85:デフォルトの名無しさん
09/09/22 11:44:32
Modern -> MPL -> 関数型 とたどった俺が通りますよ
86:デフォルトの名無しさん
09/09/22 17:23:17
確かに関数型の初歩的な知識くらいは最低限欲しいな
87:デフォルトの名無しさん
09/09/22 20:26:22
>85
俺漏れもー。
でも一から MPL するならともかく Boost.MPL の上に乗っかっちゃえば
大分楽になるし割と適当でも何とかなる気はするんだ。
88:デフォルトの名無しさん
09/09/22 20:27:57
MPL と TMP を混同して意味不明なこと書いちまった。
89:デフォルトの名無しさん
09/09/23 14:30:56
スレタイ0xのままでいいのか？
16進数？
90:デフォルトの名無しさん
09/09/23 14:44:59
今年が終わったら1xにしてくれ。
ちなみによく間違われるが別に16進数という訳ではない。
91:デフォルトの名無しさん
09/09/23 15:45:51
間違われるんじゃなくて規格策定の遅れを揶揄されてるんですよ
92:デフォルトの名無しさん
09/09/23 23:32:40
36進数で平成33年に制定予定。
93:デフォルトの名無しさん
09/09/24 10:08:38
>>73
> そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか
板違いだろ、このカス。
94:デフォルトの名無しさん
09/09/24 22:06:49
まあ、MPLはやり過ぎだとしてもだ、メタプログラミングは必須だぜ。
まともな日本語の参考書なんてでるかねぇ。
95:デフォルトの名無しさん
09/09/24 22:39:50
C++ Templates: The Complete Guide が積読の山からでてきた
これマスターしたら俺もBoostみたいな変態ライブラリ書けるようになるん？
96:デフォルトの名無しさん
09/09/24 23:25:33
他にもいっぱいマスターしなきゃならないよ！
97:デフォルトの名無しさん
09/09/25 00:27:00
現状のTMPは知れば知るほど深みに嵌ってソースが難読化してくのが・・・
98:デフォルトの名無しさん
09/09/25 01:19:52
URLﾘﾝｸ(gcc.gnu.org)
最近gcc lambda brancheが頻繁に更新されていてまさか、と思ったけど
ついにメンテナ自ら4.5にマージするつもりであることを発言したね
99:デフォルトの名無しさん
09/09/25 02:35:04
gcc は元から関数内関数が実装されてたから、そこらへん流用できたのかな？
100:デフォルトの名無しさん
09/09/25 11:24:50
昔の実装（Usenix88-lexic.pdf）って、関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
lambdaってそのへんどうなの？
101:デフォルトの名無しさん
09/09/25 12:11:30
> 関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
それじゃ lambda の意味がないだろ?
102:デフォルトの名無しさん
09/09/25 12:15:53
lambda expressionの評価結果のclosure typeはcopy constructibleな関数オブジェクト
nested functionとは別物
103:デフォルトの名無しさん
09/09/25 14:01:50
>>99
関数内関数なんて、
デバッガのためのシンボル情報処理以外、実装は極めて簡単じゃん。
lambdaはずっと実装が難しい。
104:デフォルトの名無しさん
09/09/25 15:52:03
いらねーな。
105:デフォルトの名無しさん
09/09/25 18:03:56
意外と早かったな
conceptGCCの二の舞を恐れて急いでたのかな
106:デフォルトの名無しさん
09/09/25 18:39:53
そこだけVC++に先を越されてたからだろ
107:デフォルトの名無しさん
09/09/25 21:56:30
lambada関数は関数ポインタと関数オブジェクトのどっちで返されるん？
108:デフォルトの名無しさん
09/09/25 22:06:47
関数オブジェクト
109:デフォルトの名無しさん
09/09/25 22:23:44
ありがとう
すると、コンパイラの最適化もかかりそうで嬉しいな。
どんな型の関数オブジェクトか分からないけどautoで受ければいいから問題ないか。
110:デフォルトの名無しさん
09/09/25 22:29:05
lambdaで作られる関数オブジェクトのoperator()はインライン関数扱いみたいだしね
オーバーヘッドは最小限に抑えられるだろう
なんかlambdaの認識が弱いスレ住民が結構多いみたいだな
URLﾘﾝｸ(www.open-std.org)
lambdaだけなら大した分量でも無いから、paperあたろうぜ
111:デフォルトの名無しさん
09/09/25 22:56:09
仕様はコンパイラとのガチ勝負で覚えるのだ。
112:デフォルトの名無しさん
09/09/26 00:12:06
なんで、lambdaをオブジェクトにしたかなぁ。
static領域やらスレッドローカルストレージでも利用して
関数に偽装してくれりゃよかったのに。typeidやらbad_exceptionだけでも、
ライブラリ依存の機能はうんざりだったんだが。
113:デフォルトの名無しさん
09/09/26 00:14:19
そりゃキャプチャ持ってるからだろ
114:デフォルトの名無しさん
09/09/26 00:18:13
関数のコードとインスタンスは別だよ。
115:デフォルトの名無しさん
09/09/26 00:27:54
>>113-114
それを知ってての上の話。
例外機構も事実上ライブラリ依存はしてるけど、
からくりを言語コアに封じ込めてるでしょ。
あんな感じにしてほしかった。
もっと言えば、昔BCCにクロージャーって機能があったが
あんな感じ。
116:デフォルトの名無しさん
09/09/26 00:36:26
関数オブジェクトがインライン展開されて丸儲けとしか思えないが、
何が問題なのか分からん。具体的に問題点を例を挙げて説明してくれ。
117:デフォルトの名無しさん
09/09/26 00:40:50
>>112
逆に考えるんだ。言語機能によって生成されるオブジェクトにアクセスするための
インターフェースとしてライブラリがあるのだと。 sizeof と size_t みたいなもんだ、と。
118:デフォルトの名無しさん
09/09/26 00:59:27
ところで、lambdaってライブラリ依存なんてしてるの？
型もオブジェクトも完全にコンパイラ内部で生成されてて
ヘッダのincludeもランタイムのリンクも必要無いよね
operator()すなわちライブラリって考え？
119:デフォルトの名無しさん
09/09/26 02:06:29
>>116
ライブラリであるという事は、コンパイラが他の
クラスと同様の最適化しかできないということ。
functionalオブジェクトを引き渡す相手がテンプレートなら
インライン展開できるかも知れないが、相手が別リンケージに
いるならそれも不可能。さらに、配列に放り込むにもポインタでは
無いので、次の式みたいに関数のポインタと混在させて利用する
なんて事も不可能。
void(*p[])()={function,[](){}};
120:デフォルトの名無しさん
09/09/26 02:20:01
>>119
ライブラリじゃなかったら別リンケージでもインライン展開出来るという根拠は？
関数オブジェクトでもLTOが発達すれば特に劣る理由は無いと思うし、
関数オブジェクト一般を扱うコードとの親和性が高い分マシ
下の例はstd::function使った方が汎用性があるよね
121:デフォルトの名無しさん
09/09/26 02:44:30
で、結局関数オブジェクト以外のどういう実装でどう差が出てくるんだ？
現時点だとEmbedded C++信奉者の方がまだまともなレベル
122:デフォルトの名無しさん
09/09/26 03:05:18
>>119
実装とベタベタに相互依存した最適化をすればいいだけじゃん
標準／準標準ライブラリあたりにはよくあること
123:デフォルトの名無しさん
09/09/26 03:12:42
どうせ
std::initializer_list も range-based for-loop も
実装依存した最適化されるんでしょうし
124:デフォルトの名無しさん
09/09/26 10:08:04
>>119
リンク時コード生成でインライン展開可能だよ
125:デフォルトの名無しさん
09/09/26 13:11:23
関数オブジェクトは最適化が期待できる。
関数ポインタは最適化の期待が薄い上に分岐予測の妨害になりやすい。
関数ポインタも関数オブジェクト(std::function)の配列に格納できるので関数オブジェクトと共存できる。
>>119 関数ポインタのメリットは？
126:デフォルトの名無しさん
09/09/26 13:24:33
生の関数ポインタは、間接性が全くなくて、そのアドレスに直接飛べるように
しなきゃならないから扱いが大変。
最近はスタックを実効不可にする例が増えてるけど、そうすると昔のgccの
関数内関数なんかは実行できなくなってるし。
127:デフォルトの名無しさん
09/09/26 13:43:50
「関数に偽装」って言ってるのが「関数そのものにしてくれ」とは別の意味なのだとしたら、
「lambdaも関数オブジェクトに偽装してるだけ」という可能性は考えないのだろうか
抽象的には関数オブジェクトが関数に劣る面は何も無いし、実装的にも融通は利かせやすい
んだから効率は上がりこそすれ下がりはしないだろう、普通に考えたら
128:デフォルトの名無しさん
09/09/26 14:14:41
関数ポインタの利点なら一番大事なのがあるだろ
Cのインターフェースに渡せること
129:デフォルトの名無しさん
09/09/26 14:34:16
Cのインターフェースに渡す自体が非効率的だからなぁ…
どうしても必要なら、関数オブジェクトでも効率そのままで渡せるし
130:デフォルトの名無しさん
09/09/26 14:39:46
なんか関数オブジェクトを魔法の杖みたいに思ってないか？
131:デフォルトの名無しさん
09/09/26 14:49:53
最適化云々とは書いたが、実際そんなにパフォーマンスにはこだわってないんだがな。
テンプレート関数に引き渡すときは、インライン展開され関数のポインタに
引き渡されたときは関数の様に最適化されるといったところか。
まぁ、ここまではFunctorと変わらないが更なる最適化は例外やらexportを
実装した狂人が考えるだろよ。lambda関数が内部で上位関数に対し
参照するポインタを定数に書き換えるぐらいやっても構わんだろうから。
それより重要なのは、関数ポインタと互換性が有る点。
旧来の関数ポインタを使うスレッドを始としたコールバック関数に直接放り込める。
もちろん、関数ごとにラップしてやればFunctorでも使えなくは無いが面倒だろ。
それもlambdaが生まれたのと同様の理由で。
132:デフォルトの名無しさん
09/09/26 14:52:28
レガシーコードに渡すなら普通に関数を定義すれば良いんじゃないか
そもそも関数ポインタとして扱えてキャプチャと並列安全性を両立って実装出来るの？
Intel TBBとか見てると、C++0x lambdaはかなり現実のニーズに答えていると思うけどね
Appleのblocks拡張よりは好きだな
133:デフォルトの名無しさん
09/09/26 14:59:00
Cから呼べない関数もどきなんて何の価値もないからねぇ…
C＝レガシーって考えてるとしたら色々とズレてる
134:デフォルトの名無しさん
09/09/26 15:11:31
関数ポインタしか渡せない C のインターフェースに任意の関数オブジェクト渡す
なんて、「最適化」の範囲でできることなの？
汎用引数として void* が付いてるインターフェースならそこを経由させられるけど、
そうじゃなかったら追加の引数はどうやって渡されることになるの？
静的変数使ったりするの？
135:デフォルトの名無しさん
09/09/26 15:12:05
remove_ifに渡すlambda関数にオーバーヘッドがあったらそれこそ使えないだろう。
C++なんだから関数ポインタとかコールバック関数とかCのやり方にこだわる必要性を感じない。
稀な使用例のためにC++の仕様が後退するほうがデメリットが大きい。
コールバック関数が必要な場面なんか稀なんだからそのときにstatic関数を宣言すればいいとおもうよ。
136:デフォルトの名無しさん
09/09/26 15:16:30
C++に無名関数オブジェクトが必要だということは前々から言われてたこと
無名関数ポインタが欲しいなら、C1xに入れてもらえば良い
まともに実装可能で矛盾が無いならその後にC++に入るだろ
137:デフォルトの名無しさん
09/09/26 15:58:32
PODの要件緩くしたりunionも使いやすくしたり
Cとの連携は必要ないどころかC++0xでますます強化されてるんだけどな
ラムダもなんかの条件満たしたら関数ポインタになるようにすれば良かったんだ
POFとか言って
138:デフォルトの名無しさん
09/09/26 16:14:51
>PODの要件緩くしたり
これはCとの連携の強化とは逆の方向行ってるだろ
139:デフォルトの名無しさん
09/09/26 16:27:45
>>137
まだ、関数オブジェクトに対する関数ポインタのメリットが示されていない。
140:デフォルトの名無しさん
09/09/26 17:10:11
インタフェースの基本はCの関数だろ。あらゆるAPI、最新の言語でもそれを利用する。
そうでなければCOMの様な複雑なインターフェースを考えることになる。
141:デフォルトの名無しさん
09/09/26 17:30:01
>>140
で？
そんなところは局所化して一段ラップすれば済むんだから、関数ポインタに特化するような
規則を標準化する必要性にはつながらないでしょ？
142:デフォルトの名無しさん
09/09/26 18:13:56
>>139
思いつきで言ったのに反論されて、
粘着しているだけなんじゃないのかね。
143:デフォルトの名無しさん
09/09/26 18:40:08
こんなのを書いてみたけど、ラムダ式ってデフォルトコンストラクタを持ってないから使えないのか。残念。
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;
}
144:デフォルトの名無しさん
09/09/26 18:54:22
>>140
WindowsAPIはC呼び出しではなく、PASCAL呼び出し(stdcall)なんだけどな。
145:デフォルトの名無しさん
09/09/26 19:55:41
利点はもう一個あるな
関数ポインタは整数(intptr_t/uintptr_t)に変換して持ち運べる
146:デフォルトの名無しさん
09/09/26 20:10:23
コンテキストを保持する構造体無しで関数ポインタだけでクロージャを実装しろとか、
コンパイラ屋をなんだと思っているんだ
標準化の過程の中で、function pointerを通して扱えるlambdaを作る、
なんて案は提出された記録すらないんだから、もはやスレ違いだろ
ｽﾚﾘﾝｸ(tech板)
行け
147:デフォルトの名無しさん
09/09/26 20:19:19
何だと思ってるんだと言われても、現に関数オブジェクトなせいで使いづらくなってるだろ
むしろコンパイラ屋は何を考えてるんだといいたい
148:デフォルトの名無しさん
09/09/26 20:31:30
不可能ではないし。
149:デフォルトの名無しさん
09/09/26 20:33:12
ここでゴネて変更させようとしても
そりゃ不可能だよ。
150:デフォルトの名無しさん
09/09/26 20:33:23
>>147
> 現に関数オブジェクトなせいで使いづらくなってるだろ
？？？
たとえばどんなときに？
具体的に頼む。
151:デフォルトの名無しさん
09/09/26 20:39:48
関数オブジェクトの意味が分かってないだけなんじゃ、と思ってるのは俺だけだろうか
152:デフォルトの名無しさん
09/09/26 20:40:05
例えばこれが出来ない
qsort(a,100,sizeof(int),[](void*a,void*b)->int{return *(int*)a>*(int*)b;})
153:デフォルトの名無しさん
09/09/26 20:42:21
ここでqsortを出すとは、>>152のセンスに恐れ入った
154:デフォルトの名無しさん
09/09/26 20:44:09
アルゴリズムのヘッダが動かないと問題だと思うが。。。
155:デフォルトの名無しさん
09/09/26 20:46:08
C++のライブラリにソートないの？
156:デフォルトの名無しさん
09/09/26 20:47:06
ここで聞くなよ
157:デフォルトの名無しさん
09/09/26 20:50:04
>>152 それだと「 std::sort() 使え」でおしまいだな。意味がわからん。
158:デフォルトの名無しさん
09/09/26 20:52:07
「qsortに関数オブジェクト渡せないぞ！」とか言われても
「printfでoperator<<みたいにオブジェクト出力できないぞ！」とか言われてるような感じ。
159:デフォルトの名無しさん
09/09/26 21:06:48
>>152
CのヘッダーはC++では使うメリットが無いし。
#include <algorithm>
を使って議論しようよね。
160:デフォルトの名無しさん
09/09/26 21:12:54
たとえstd::sort()があったとしても、qsortも使えた方がいいに決まってるじゃん
std::sortはクイックソートじゃないかもしれないんだしさ
何もキャプチャしてないラムダ式くらい関数ポインタに暗黙変換してくれよ
出来るはずだろ
161:デフォルトの名無しさん
09/09/26 21:16:03
>>145
それって鼻から悪魔じゃなかったっけ
てか、FFIやら呼び出し規約やらでC言語関数の共用ができるとはいえ
所詮もともとC言語特有のものを他の言語であたりまえにサポートすると思うなよ･･･
162:デフォルトの名無しさん
09/09/26 21:17:49
他の言語ならそうだけど他ならぬC++だからな
Cとの連携はちゃんとしてもらわないと言語の意味がない
163:デフォルトの名無しさん
09/09/26 21:19:35
なんでgenericなstd::sortがあるのに、わざわざqsortを使わなきゃなんねーんだよ。
クイックソートであるかどうかにそんなに意味があるのかよ？
だいたい、クイックソートなんてこの１レスに収まる程度のコード量で実装できるだろうが。
もちろんgenericなクイックソートをな。
お前みたいなヤツはBoostに転がってるc_funtionでも使ってればいいだろ。
164:デフォルトの名無しさん
09/09/26 21:19:41
杞憂ですね。
165:デフォルトの名無しさん
09/09/26 21:23:25
彼、一人ですよね。レスが多いから多数派の意見なのかと不安になってくる
166:デフォルトの名無しさん
09/09/26 21:26:54
例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
qsortは中でmemcpy使うからね
というかラムダが使えないという話はqsortに限らずCのAPI全般での問題であって
いくらqsortを否定されても本題とは関係ないんだけど
167:デフォルトの名無しさん
09/09/26 21:28:07
>>162
lambdaがポインタでもオブジェクトでも後方互換は満たしてるじゃん。
新機能までわざわざCに追従させる意味があるんかいな。
168:デフォルトの名無しさん
09/09/26 21:30:10
>>160
qsort() なら実際のアルゴリズムがクイックソートだというのも間違い。
std::sort() と同じぐらいに実装は自由。
> 何もキャプチャしてないラムダ式くらい関数ポインタに暗黙変換してくれよ
これは、生成される関数オブジェクトの変換 operator としてあってもいいかもしれない。
169:デフォルトの名無しさん
09/09/26 21:31:17
追従はしなくていいけど、出来るものはなるべくするべきだろう
キャプチャ付きのラムダまで全部関数ポインタにしろとは誰も言わない
170:デフォルトの名無しさん
09/09/26 21:39:59
べ、別にCのためにlambdaを作ったわけじゃないんだから。勘違いしないでね。
C++の新機能をCのライブラリで使いたいってのが無謀じゃないのか。
171:デフォルトの名無しさん
09/09/26 21:41:48
>>166
> 例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
> qsortは中でmemcpy使うからね
qsort() が memcpy() 使うとは限らないし、 memcpy() 使うから速いというのも意味不明。
> いくらqsortを否定されても本題とは関係ないんだけど
ええと、「本題」が何なのかよくわからないんだけど、
「関数ポインタが欲しいところでも余計な記述無しに lambda を使いたい」ってことでいいの？
>>112 まで遡ると「lambdaをオブジェクトにした」のが嫌だって話が出てたんだけど、
その理由がこれだけのためってことなら lambda 式で生成されるものが
関数オブジェクトでも >>168 みたいな変換 operator があれば済むわけでちょっと
的を外してたかな、と思う。
172:デフォルトの名無しさん
09/09/26 21:42:41
>>171
その当然あるべき変換operatorが今の規格にないことが問題でしょ？
173:デフォルトの名無しさん
09/09/26 21:47:36
キミ以外の誰にとって問題なのか不明。
174:デフォルトの名無しさん
09/09/26 21:47:49
>>172
それが、>>163のc_functionだね。
今初めてc_functionの使い道が解った。こんなレアケースに対応する為のものだったとは。
boostスゲー
175:デフォルトの名無しさん
09/09/26 21:49:48
>>172
当然あるべきと思うかどうかは人による。そこを主張しても意味が無い。
関数ポインタへの変換 operator を追加することは妥当な提案かもしれないとは思うよ。
個人的には、一段ラップして済ませられるし、他の理由で結局ラップする必要がある
ことが多いから、要らないと思うけどね。
条件の規定とか、変換できる場合とできない場合の違いを一般のプログラマが
認識できるか、とか、いろいろ面倒な問題もあるわけで、費用対効果は微妙なところ
だろうとも思う。
176:112
09/09/26 21:59:47
なんか議論が粘着っぽくなってるんでひとつ。
>>112 = >>119 = >>131は俺。
スレッド関数とかAPIの替えの効かない関数にポインタ
突っ込めるから便利と言う発言以外は別人なのでよろしく。
C++で代用可能なライブラリとか、整数型に突っ込めるとかも別人。
177:デフォルトの名無しさん
09/09/26 22:06:44
現行のラムダさんは見た目は悪くても素直ないい子なのに、
常人に理解されにくい一面を増やしたりしたらかわいそうだよね
ただでさえC++はバッドノウハウの塊扱いされてるんだからさ
178:デフォルトの名無しさん
09/09/26 22:08:28
>>176
その別人はカタコトの言葉しか使えないようだし
ほとんどの人にとっては区別がつくと思う。
179:デフォルトの名無しさん
09/09/26 22:11:44
lambdaを関数ポインタとして呼べるようにしろってのは無茶言うなとは思うが、Cとの連携が強化されてほしいというのはわかる。
pmf-conversionとか、friend関数をExtension Methodのように取り扱えたらとか妄想して今日も寝る。
180:デフォルトの名無しさん
09/09/26 22:59:09
つーかPODかどうかでmemcpyを使い分けるくらいは今時のテンプレートなら余裕だろ
181:デフォルトの名無しさん
09/09/27 08:43:51
functionalだってqsortにはつかえねーじゃん…
182:デフォルトの名無しさん
09/09/27 11:11:43
おまえらどんだけqsort好きなんだよ
183:デフォルトの名無しさん
09/09/27 11:32:43
一人だけだろｗ
184:デフォルトの名無しさん
09/09/27 13:10:43
あのgccですらqsortをstd::sortに書き換えを試みてるってのに
qsortが好きな奴なんて居るわけが無い
185:デフォルトの名無しさん
09/09/27 13:53:00
いや一人いる
186:デフォルトの名無しさん
09/09/27 14:30:55
それでもqsortが優れているのは
世界共通言語たるCの標準ライブラリに含まれてる由緒正しい関数だということ
187:デフォルトの名無しさん
09/09/27 14:48:53
世界共通言語たるC++の標準ライブラリに含まれてる由緒正しいstd::sortはどうなのか
188:デフォルトの名無しさん
09/09/27 15:18:42
Cで動かないコンピュータは事実上存在しないけど
C++が使えない処理系ならいっぱいある
世界共通言語とは言えないね
189:デフォルトの名無しさん
09/09/27 15:22:27
>>188
いっぱいある？昔はそんなこともあったように思うが、今だともう思い当たらないな。
たとえばどの処理系のこと言ってるの？
190:デフォルトの名無しさん
09/09/27 15:36:04
そんなにC信者ならC使ってりゃいいじゃん。
191:デフォルトの名無しさん
09/09/27 15:43:49
freestandingだってC++処理系だよ
いい加減Cの話はやめてC++0xの話しようぜ
URLﾘﾝｸ(cpp-next.com)
でDave Abrahamsが書いてる記事くらいの質の情報が
日本語で得られるようになれば右辺値参照もすぐに広まるだろうになあ
192:デフォルトの名無しさん
09/09/27 15:51:03
C++0xで日本語ページをぐぐった結果を見ると絶望的だな
193:デフォルトの名無しさん
09/09/27 16:00:23
おまえら詳しいんだろうから書いてくれ
194:デフォルトの名無しさん
09/09/27 16:18:28
>>188
お前の言いたいのは処理系じゃなくて環境だろ。
195:デフォルトの名無しさん
09/09/27 16:24:04
環境といっても職場やチームの環境だったりしてな。
196:デフォルトの名無しさん
09/09/27 17:25:58
>>189
俺も同感。今時の開発環境でCが使えるのにC++が使えない環境を
教えて欲しいと思う。そういった仕事が来たら調査しないで速攻
で断りたいから。
197:196
09/09/27 17:29:13
あ、Linuxのカーネルモジュールの場合とかはあるな。
でも、その場合はしょうがないって諦められるから心理的
ストレスは（俺の場合）殆ど無い。
198:デフォルトの名無しさん
09/09/27 17:31:54
一部の組み込みみたいにリソースの厳しい場合もEmbedded C++でしっかりカバーできおっと誰か来たみたいだ
199:デフォルトの名無しさん
09/09/27 19:05:09
C++が使える場所でもメンバーの大体はベターC的なコード書いてて
そういうモジュールを使わなきゃいけないってことはよくあるというか
そういう場合の方が多いがなぁ。
200:デフォルトの名無しさん
09/09/27 19:10:26
「いっぱいある」と言いながら具体的な例はひとつも出せない。下手な印象操作の典型だな。
201:デフォルトの名無しさん
09/09/27 20:38:30
Better C的なコードを書くような連中はlambdaも使わないだろうからどうでもいい
202:デフォルトの名無しさん
09/09/28 22:58:30
> Cが使えるのにC++が使えない環境
実行時コンパイルとか、マニアックな条件ならありえる。
203:デフォルトの名無しさん
09/09/29 00:01:43
TCCのことかー
あと、clangなんかも良いCコンパイラだけど、
C++コード生成はまだまだ実装されそうにないな
それにしても、スレに沿った話で盛り上がらんな
204:デフォルトの名無しさん
09/09/29 02:05:52
懸案のコンセプトは消えて、主要機能はあらかた固まってきて
あとはRange-based forがどんどん腐っていくのを見守るくらいしかないからなぁ
205:デフォルトの名無しさん
09/09/29 03:15:26
C++0xを使い始めるのはVC10の正式リリース待ち、っていう住民も多いだろうが、
実装されるものはBeta1の時点でほぼ確定しているし、gcc使いにはあまり興味の沸かない話だ
206:デフォルトの名無しさん
09/09/29 09:28:31
range-based for、大丈夫かなあ
conceptに禍根を残さないようにお願いしたい
207:デフォルトの名無しさん
09/09/29 22:14:34
誰かrange-based forさんの服を洗濯してあげて下さい
208:デフォルトの名無しさん
09/09/29 23:56:23
洗濯したら破れちゃったんですが
209:デフォルトの名無しさん
09/09/30 01:33:37
禿は破れたのを繕うの得意です
210:デフォルトの名無しさん
09/09/30 01:58:39
range-based for
いらねぇぇ
将来conceptの邪魔になりそう
211:デフォルトの名無しさん
09/09/30 01:59:20
forさん「妹なんていなかった」
212:デフォルトの名無しさん
09/09/30 07:46:44
gcc lambda branchが最終調整に入ったようだ
これなら残り24時間ちょっとのstage 1終了までのマージに間に合うはず
stage 1が終わったら新機能の追加は許されなくなるから、
残りのC++0x実装は来年の4.6もしくは5.0に持ち越しかな
213:デフォルトの名無しさん
09/09/30 12:20:12
というわけで、lambda branchがtrunkにマージされた
URLﾘﾝｸ(gcc.gnu.org)
gcc-4.5-20091001のスナップショットに入るだろうから、だいぶ試しやすくなるだろう
214:デフォルトの名無しさん
09/09/30 18:19:51
よかったねラムダさん！
215:デフォルトの名無しさん
09/09/30 20:30:32
C++1xはinline perl（プリプロセッサ用）が搭載予定！
216:デフォルトの名無しさん
09/09/30 20:56:32
さようなら Boost な lambda さん！
217:デフォルトの名無しさん
09/09/30 22:21:46
std::bind 向けに Boost.Lambda っぽいのも残るんじゃなかった?
std::placeholder::_1 とかいうのが。
218:234
09/09/30 23:47:10
そういえば、lambdaとbindって機能がダブってない？
219:デフォルトの名無しさん
09/10/01 00:54:57
switchとifがダブってると思うならそうなんだろう
220:デフォルトの名無しさん
09/10/01 01:47:54
ifとswitchで条件分岐がダブってしまった…
ガーンだな
221:デフォルトの名無しさん
09/10/01 02:51:51
9月号来た。
>14.10 Concepts [concept]
>removed.
Oh!
222:デフォルトの名無しさん
09/10/01 03:22:16
URLﾘﾝｸ(www.open-std.org)
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
223:デフォルトの名無しさん
09/10/01 07:37:24
落とせない
224:デフォルトの名無しさん
09/10/01 17:53:06
>>218
そうかも
一応、bind自体の機能はbindの方がlambdaのbindよりも高機能だ
stdcallやfastcallの関数もbindできる
225:デフォルトの名無しさん
09/10/01 19:54:17
コンセプトさんの埋葬が終わったと聞いて
226:デフォルトの名無しさん
09/10/01 19:55:46
コンセプトさんはコールドスリープ中よ
227:デフォルトの名無しさん
09/10/01 20:22:12
>>224
専門家だけあって強力なのね。
228:デフォルトの名無しさん
09/10/01 20:27:10
あのクソみてえな拡張for文の文言が入っちゃってるよ…
229:デフォルトの名無しさん
09/10/01 23:50:31
autoがあるんだから普通にループ回せよ
どんだけタイピングしたくねぇんだよ
230:デフォルトの名無しさん
09/10/01 23:55:35
拡張for文があることで何か不都合があるというのであればそれを指摘するべきですな。
あって困るものとは思えません。
新しいことがもう覚えられないとかそういうことですか?
231:デフォルトの名無しさん
09/10/02 00:07:00
>>230
このスレでも誰か言っていなかったっけ。
次にConceptが入って拡張forを作り直すとき、
現在の拡張forが（互換性のためと言って）邪魔にならないだろうかという懸念。
個人的には、std::for_each+ラムダの手もあるし、
あるいは、もう数年BOOST_FOR_EACHのお世話になってもいいと考えているけど。
232:デフォルトの名無しさん
09/10/02 00:12:44
名前が悪いってことだろ
233:デフォルトの名無しさん
09/10/02 00:26:09
どうせSFINAEやらtraitsを使ったやつは
次にConceptを導入するときに書き直したりすることになるんでしょ
for loopがその中の一つになっても別にって感じ
今の拡張forの状態だと
begin/end関数は適切に書きましょう、そうしないとひどいぞ！ってことではあるが
234:デフォルトの名無しさん
09/10/02 00:26:10
URLﾘﾝｸ(gcc.gnu.org)
lambdaの影に隠れて、constexprも実装された件
これがはじめての実装だから弄るのが楽しみだな
235:デフォルトの名無しさん
09/10/02 00:48:15
とりあえず constexpr はまだ準備中ってところだね。
URLﾘﾝｸ(www.pubbs.net)
これからの発展を祈る！
236:デフォルトの名無しさん
09/10/02 02:29:57
BOOST_FOR_EACHとか書く奴が本当にBOOST_FOREACHのお世話になってるのか
疑わしい
237:デフォルトの名無しさん
09/10/02 07:35:25
仕事で使えるのはいつのことやら。
いじって遊ぶなんて意味ないんだが。
238:デフォルトの名無しさん
09/10/02 07:46:35
foreachに#defineするとかっこいいぞ
239:デフォルトの名無しさん
09/10/02 08:16:00
小文字にdefineしちゃうと「中身は実はマクロだから色々注意が要りますよ」感が
無くなるのがなぁ
240:デフォルトの名無しさん
09/10/02 08:50:13
BOOST_FOREACHEはマクロでの評価回数の罠を解決しているぞ。
でも、,の罠は引っかかるけどコンパイルエラーがでるから問題ない。
241:デフォルトの名無しさん
09/10/02 11:11:33
少しずつ間違えるのがナウなヤングにバカうけ？
242:デフォルトの名無しさん
09/10/02 11:21:48
俺はハッピーターン派
243:デフォルトの名無しさん
09/10/02 12:45:24
最近のコンパイラは18446744073709551616回未満のループなら展開しちゃうからforeachとか気にしなくていいよ
244:デフォルトの名無しさん
09/10/03 03:16:29
Win32 環境で gcc-4.5-20091001 使ってみた。
lambda は使えるけど、まだ関数構文の統合がされてなかった。
constexpr については今のところはあってもエラーにならないだけ。
245:デフォルトの名無しさん
09/10/03 13:19:20
まだも何もN2960ではまだ関数構文の統合は入ってないぞ
246:デフォルトの名無しさん
09/10/03 16:13:41
>>244
拡張sizeofもOKのようだ。
247:デフォルトの名無しさん
09/10/03 18:03:16
>>243
サーバプロセスのメインループで停まらないんですけど?
248:デフォルトの名無しさん
09/10/05 16:32:54
Conceptsを殺した上に今年中に作る気がないとかふざけ過ぎだろ。
249:デフォルトの名無しさん
09/10/05 18:34:42
キモい奴しか使わないゲンゴシヨウナンテイラネーヨ。
250:デフォルトの名無しさん
09/10/05 21:33:54
>>248
Conceptsあのままでも間に合わなかったが、
抜くことになって余計時間はかかることになった。
251:デフォルトの名無しさん
09/10/07 18:19:37
5年後には結局また入れることになるかもしれない文言を取り除いて調整する
不毛で後ろ向きな作業を見てるのは辛い
252:デフォルトの名無しさん
09/10/07 21:59:25
decltypeってどう読んどけばいいの？
俺はデックルタイプなんだけど
253:デフォルトの名無しさん
09/10/07 22:37:12
declared type of の略だからデクルタイプでいいんじゃない
254:デフォルトの名無しさん
09/10/08 06:52:26
でくれあーたいぷ
255:デフォルトの名無しさん
09/10/09 03:57:40
URLﾘﾝｸ(cpp-next.com)
デフォルトムーブコンストラクタを提供すれば右辺値参照を使っていない
既存のコードでも高速化が期待出来る、ってことだったけど
例外安全との絡みで結構ややこしいことになってるみたいだね
256:デフォルトの名無しさん
09/10/09 06:57:50
既存のコードでバグりそうだなｗ
257:デフォルトの名無しさん
09/10/09 07:19:35
で、聞きたいが、遅延展開は仕様に入ってるの？
258:デフォルトの名無しさん
09/10/09 08:20:00
>>255
ムーブコンストラクタは魔法使いにしか使えないよ。