2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++0x 7

1 :デフォルトの名無しさん:2009/09/18(金) 22:26:17
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/

2 :デフォルトの名無しさん:2009/09/18(金) 22:27:46
>>1死ね

3 :デフォルトの名無しさん:2009/09/18(金) 22:34:15
嫌です(^ε^)

4 :デフォルトの名無しさん:2009/09/18(金) 22:36:02
C++0xがいつ規格制定されるかは、髪のみぞ知る。

5 :デフォルトの名無しさん:2009/09/18(金) 22:37:59
C++学園の人々

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

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

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

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

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

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

6 :デフォルトの名無しさん:2009/09/18(金) 22:38:09
○initializer_listさん
vectorさんが泣いて喜ぶコンテナ部悲願の新人。
だが似たような服を着た生徒が元から多いので、一部では
「またややこしい奴が来た」と陰口を言われているらしい。

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

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

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

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

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

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

○禿
校長先生。

7 :デフォルトの名無しさん:2009/09/18(金) 22:46:04
>>5-6


8 :デフォルトの名無しさん:2009/09/18(金) 22:54:08
> きったない服で通学することになりテンションガタ落ち中。

ここで爆笑した

9 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/18(金) 23:21:05
だんだん説明が投げやりになってるなw

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

12 :デフォルトの名無しさん:2009/09/18(金) 23:30:46
lambdaが消されることはまずないよ。
range-based forとかuser defined literalsは、このままだと問題が多いと思うけれど。

13 :デフォルトの名無しさん:2009/09/18(金) 23:35:16
>服装のちょっとした違いで性格が変わる面倒な一面
括弧のことか。

14 :デフォルトの名無しさん:2009/09/19(土) 02:35:20
>>12
user defined literals の問題って何?

15 :デフォルトの名無しさん:2009/09/19(土) 03:22:07
>>14
ユーザー定義リテラルの名前は必ずアンダースコアから始まらなければならない。

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

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


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

16 :デフォルトの名無しさん:2009/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 が
存在しても2つの名前 ::operator "" _x と ::_x は衝突しない。

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

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

17 :デフォルトの名無しさん:2009/09/19(土) 04:42:55
すると、そのLiteral suffix identifiersとやらは、nameじゃないわけ?

18 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/19(土) 05:03:38
>>16
_で始まらないユーザ定義リテラルが予約されるのはライブラリ的な都合ではなく
将来のバージョンのC++における字句解析の都合じゃないんかね。

20 :デフォルトの名無しさん:2009/09/19(土) 05:16:52
>>19
そういう用途も考えられてるかもしれないけど、たとえばライブラリ内の
クラスである std::string を返すようなユーザ定義リテラルを字句解析の
レベルに置くようなことは考えにくいわけで、ライブラリ的な都合ではない
と言うのは当たらないと思う。

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

21 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/19(土) 05:37:29
何にしても名前空間内にあるかどうかで特別扱いするのは無理だろう

23 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/19(土) 06:17:12
>>23
あー、たしかにuser defined literalの識別子だけでは、entityたりえないようだなぁ。
すると、user defined literalの識別子は、予約語の制約を無視できるという事になるのか。

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

27 :デフォルトの名無しさん:2009/09/19(土) 06:30:25
ユーザ定義リテラルなんて演算子オーバーロードでDSLつくっちゃうような人らにしか使われなさそう

28 :デフォルトの名無しさん:2009/09/19(土) 06:30:59
>>26
ごめん。なぜアンダースコア二つから始まる名前、及びアンダースコアひとつに大文字で始まる名前がダメなんだ?
user defined literalの識別子は「名前」じゃないんだろ?

29 :デフォルトの名無しさん:2009/09/19(土) 06:42:00
>>28
そいつらは "reserved to the implementation for any use" ということで、
処理系定義のマクロやキーワードとして使われている可能性があり、
該当する場合はそもそも文法上の identifier として認識されない可能性もある。
その場合はパース時点で >>21 にある構文にマッチしなくなる。

30 :デフォルトの名無しさん:2009/09/19(土) 06:43:34
それは処理系の都合であって、確かに、大方の処理系はそうだろうけど、
規格上は、関係ないのでは。何しろ、名前じゃないんだから。

31 :30:2009/09/19(土) 06:45:30
いやまあ、もちろん、現実的には、回避した方がいいことには変わりないんだが。

32 :デフォルトの名無しさん:2009/09/19(土) 06:45:43
>>4
もうない。

>>5-11
よそでやれ。

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

33 :デフォルトの名無しさん:2009/09/19(土) 07:13:32
>>30
言いたいことがよくわからない。
「それは処理系の都合」の「それ」って何?
「大方の処理系はそうだろう」の「そう」って何?
「規格上は、関係ないのでは」の「関係ない」って何と何の話?

34 :デフォルトの名無しさん:2009/09/19(土) 11:54:17
リテラルなんてconstか#defineして使うものなんだからユーザー定義リテラルって要らなくないか?
直接コードにリテラルを書くと保守性が悪くならない?


35 :デフォルトの名無しさん:2009/09/19(土) 13:05:50
>>33
ひとつ上のレスに対してのレス。
現実の処理系の実装どうあれ、
規格上では、名前に対しての予約語であるから、
user defined literalにまでは及ばないという話。

36 :デフォルトの名無しさん:2009/09/19(土) 14:25:15
>>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 がオーバーラップしない別物として定義されて
いるあたりも問題な気がする。

37 :デフォルトの名無しさん:2009/09/19(土) 20:05:44
>>36
たしかに書き直して欲しいね。

38 :デフォルトの名無しさん:2009/09/19(土) 20:07:03
Intel C++ compilerのバージョンがあがって、
C++0xがどれだけつかえるのかと思えば・・・
あんまりだね

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

39 :デフォルトの名無しさん:2009/09/19(土) 20:31:43
>>38
intel c++ 11.1のhelpにはrvalueが使えそうに書いてあるので、試したけどどうもうまく動かないのはなぜ?
class A
{
int a1;
int a2;
};

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



40 :デフォルトの名無しさん:2009/09/20(日) 00:30:04
>>39
右辺値つかえそうな記述とかあった?ないと思うよ
autoとラムダぐらいじゃないの?
テンプレートらへんも全然だったし・・・

41 :デフォルトの名無しさん:2009/09/20(日) 00:51:03
「rvalueが使えそう」「右辺値つかえそう」
これじゃ意味がわからんだろ。右辺値参照って言えよ。

42 :デフォルトの名無しさん:2009/09/20(日) 02:57:10
>>40
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

43 :デフォルトの名無しさん:2009/09/20(日) 03:00:51
http://software.intel.com/en-us/forums/intel-c-compiler/topic/68087/
> we'll be supporting the rvalue feature in our next major release.
だそうだ

44 :デフォルトの名無しさん:2009/09/20(日) 09:01:53
訳 : おにいちゃんおかえりなさい!

45 :デフォルトの名無しさん:2009/09/20(日) 10:00:50
>>42のR-Value Referencesや、ヘルプのQstdの説明にrvalueの文字が見えたのてっきり使えると思ってました。
次のバージョンでサポートされるんですね。
コードに突込みが入らなかったので使い方はそれでよさそうか。

ありがとうです。


46 :デフォルトの名無しさん:2009/09/20(日) 11:57:49
>>36
オーバラップうんぬんはどういうこと?
名前空間的な話?
そんなのいまさら変えられないでしょ。
予約語をきっちり定義すればいいだけの話。

47 :デフォルトの名無しさん:2009/09/20(日) 12:03:59
>>46
常識的に考えて "name" ⊃ "macro name" なんだが、 C++ 標準規格の中では
それらはまったくの別物であって、わかりにくい、ということ。

48 :デフォルトの名無しさん:2009/09/20(日) 13:37:48
つまりマクロ氏ねと
初心者の頃にCreateWindowでハマった数日を返せと

49 :デフォルトの名無しさん:2009/09/20(日) 18:07:18
話の流れぶった切るけど
constexpr があれば static const の代替としても使えるのかな?

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

50 :デフォルトの名無しさん:2009/09/20(日) 18:43:20
constexprはメモリ上にどの様に配置されるかは実装依存だがコンパイルタイムに計算が終了するので速い。
static constで修飾したものの完全な代替として使えるわけじゃない。

51 :デフォルトの名無しさん:2009/09/20(日) 18:49:17
テーブルの生成に使うのが一般的なのかな

52 :デフォルトの名無しさん:2009/09/20(日) 18:51:52
constexprに基本的な数学関数が含まれるとうれしいんだが。sinとか。

53 :デフォルトの名無しさん:2009/09/20(日) 18:56:54
>>52
言語の枠内でconstexprとして実装できない以上、
ライブラリ関数の仕様として要求すべきじゃないんじゃないかな。
コンパイル時に計算されてほしいってだけなら、
最近のgccはmfprだかgmpだかを組み込んで出来るようになってるみたいだね。

54 :デフォルトの名無しさん:2009/09/20(日) 19:59:59
近似式で書かれた関数csinとかを用意すればコンパイラが計算してくれないかな。


55 :デフォルトの名無しさん:2009/09/20(日) 20:03:22
多項式近似と引数剰余で何とかなるといいね。

56 :デフォルトの名無しさん:2009/09/20(日) 20:24:29
kbk氏はUsenix88-lexic.pdfは知ってるのかな?

57 :デフォルトの名無しさん:2009/09/20(日) 22:40:28
>>41
意味わかってくれてありがとう

58 :デフォルトの名無しさん:2009/09/20(日) 22:58:14
>>54
ぶっちゃけPerlとかで定数埋めたソースを生成した方がマシだと思うな
というか、boostのソース眺めてたら実際に生成用のPerlが落ちてて笑った

59 :デフォルトの名無しさん:2009/09/20(日) 23:11:24
constexpr再帰が認められれば級数計算も書けるはずだ

60 :デフォルトの名無しさん:2009/09/20(日) 23:22:27
それ許可するとconstexprでメタプログラミング始める人が出るから危険。


61 :デフォルトの名無しさん:2009/09/20(日) 23:25:20
constexpはそもそもメタプログラミングなわけだが。

62 :デフォルトの名無しさん:2009/09/20(日) 23:59:24
どうせテンプレートで再帰できるんだから、constexprの再帰も認めてしまえ、むしろこっちのほうが見た目は自然っていう意見を見たことがある。

63 :デフォルトの名無しさん:2009/09/21(月) 09:39:40
普通はそう思う

64 :デフォルトの名無しさん:2009/09/21(月) 10:19:22
コンパイル時にステップ実行ができるデバッガーが欲しくなるね。

65 :デフォルトの名無しさん:2009/09/21(月) 10:36:31
C++プログラマは副作用のないプログラムに最適のデバッガも使えなければならない。

66 :デフォルトの名無しさん:2009/09/21(月) 12:52:50
>>59 収束しないと永遠にコンパイル終わらないんじゃないか?


67 :デフォルトの名無しさん:2009/09/21(月) 13:01:06
なるほどなconstexpr関数が終了することを保証する必要があるんだな。


68 :デフォルトの名無しさん:2009/09/21(月) 13:59:40
適当に精度を決めればおk

69 :デフォルトの名無しさん:2009/09/21(月) 14:03:07
ifかmatch withが必要だな

70 :デフォルトの名無しさん:2009/09/21(月) 14:15:18
条件演算子があるから大丈夫

71 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/21(月) 20:10:33
>>71
そんなもんじゃね

73 :デフォルトの名無しさん:2009/09/21(月) 22:32:13
そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか

74 :デフォルトの名無しさん:2009/09/21(月) 22:35:23
minテンプレート関数が最初の例題。
char,int,float,double用に関数を何個も作らなくてもいいんだぜ!えっへん

75 :デフォルトの名無しさん:2009/09/21(月) 22:36:49
それMPLじゃなくね?

76 :デフォルトの名無しさん:2009/09/21(月) 23:10:25
Generic Programming
Template Metaprogramming
Boost.MPL

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

77 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/21(月) 23:30:09
C++ Templates: The Complete Guide

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

79 :デフォルトの名無しさん:2009/09/21(月) 23:33:26
むしろその二つを和訳するから0xのテンプレート本は我慢してくれって雰囲気だな

80 :デフォルトの名無しさん:2009/09/21(月) 23:35:59
ごくふつーのメタ関数の書き方を何通りか紹介すれば大体分かるんじゃね>MPL

81 :デフォルトの名無しさん:2009/09/21(月) 23:57:53
そのごくふつーのメタ関数を、理解させて、書けるように教えるためには、
C++ Templatesぐらいの厚みのあるページ数で解説しないといけないわけだが。

82 :デフォルトの名無しさん:2009/09/22(火) 02:30:29
そうかなぁ
割と典型的なパターンは決まってる気もするけど
まぁパターンで教えちゃっていいんですかって話ではあるけど、関数の呼び出し規約
とかしっかり把握させる教科書も無い訳だから別にいいような気もしたり
ってのはちょっと話が違うか

83 :デフォルトの名無しさん:2009/09/22(火) 03:24:57
普通にCの処理書くのとは考え方が根本的に違うからな
再帰使いまくりだし

84 :デフォルトの名無しさん:2009/09/22(火) 11:03:25
そうかまず関数型言語を教えるところから始めないと

85 :デフォルトの名無しさん:2009/09/22(火) 11:44:32
Modern -> MPL -> 関数型 とたどった俺が通りますよ

86 :デフォルトの名無しさん:2009/09/22(火) 17:23:17
確かに関数型の初歩的な知識くらいは最低限欲しいな

87 :デフォルトの名無しさん:2009/09/22(火) 20:26:22
>85
俺漏れもー。

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

88 :デフォルトの名無しさん:2009/09/22(火) 20:27:57
MPL と TMP を混同して意味不明なこと書いちまった。

89 :デフォルトの名無しさん:2009/09/23(水) 14:30:56
スレタイ0xのままでいいのか?
16進数?

90 :デフォルトの名無しさん:2009/09/23(水) 14:44:59
今年が終わったら1xにしてくれ。
ちなみによく間違われるが別に16進数という訳ではない。

91 :デフォルトの名無しさん:2009/09/23(水) 15:45:51
間違われるんじゃなくて規格策定の遅れを揶揄されてるんですよ

92 :デフォルトの名無しさん:2009/09/23(水) 23:32:40
36進数で平成33年に制定予定。

93 :デフォルトの名無しさん:2009/09/24(木) 10:08:38
>>73
> そろそろ初心者にMPLをどうやって教えるかを考えようじゃないか

板違いだろ、このカス。

94 :デフォルトの名無しさん:2009/09/24(木) 22:06:49
まあ、MPLはやり過ぎだとしてもだ、メタプログラミングは必須だぜ。
まともな日本語の参考書なんてでるかねぇ。

95 :デフォルトの名無しさん:2009/09/24(木) 22:39:50
C++ Templates: The Complete Guide が積読の山からでてきた
これマスターしたら俺もBoostみたいな変態ライブラリ書けるようになるん?

96 :デフォルトの名無しさん:2009/09/24(木) 23:25:33
他にもいっぱいマスターしなきゃならないよ!

97 :デフォルトの名無しさん:2009/09/25(金) 00:27:00
現状のTMPは知れば知るほど深みに嵌ってソースが難読化してくのが・・・

98 :デフォルトの名無しさん:2009/09/25(金) 01:19:52
http://gcc.gnu.org/ml/gcc/2009-09/msg00507.html
最近gcc lambda brancheが頻繁に更新されていてまさか、と思ったけど
ついにメンテナ自ら4.5にマージするつもりであることを発言したね

99 :デフォルトの名無しさん:2009/09/25(金) 02:35:04
gcc は元から関数内関数が実装されてたから、そこらへん流用できたのかな?

100 :デフォルトの名無しさん:2009/09/25(金) 11:24:50
昔の実装(Usenix88-lexic.pdf)って、関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
lambdaってそのへんどうなの?

101 :デフォルトの名無しさん:2009/09/25(金) 12:11:30
> 関数内関数へのポインタを、外側の関数より外に持ち出せなかったけど、
それじゃ lambda の意味がないだろ?


102 :デフォルトの名無しさん:2009/09/25(金) 12:15:53
lambda expressionの評価結果のclosure typeはcopy constructibleな関数オブジェクト
nested functionとは別物

103 :デフォルトの名無しさん:2009/09/25(金) 14:01:50
>>99
関数内関数なんて、
デバッガのためのシンボル情報処理以外、実装は極めて簡単じゃん。
lambdaはずっと実装が難しい。

104 :デフォルトの名無しさん:2009/09/25(金) 15:52:03
いらねーな。

105 :デフォルトの名無しさん:2009/09/25(金) 18:03:56
意外と早かったな
conceptGCCの二の舞を恐れて急いでたのかな

106 :デフォルトの名無しさん:2009/09/25(金) 18:39:53
そこだけVC++に先を越されてたからだろ

107 :デフォルトの名無しさん:2009/09/25(金) 21:56:30
lambada関数は関数ポインタと関数オブジェクトのどっちで返されるん?


108 :デフォルトの名無しさん:2009/09/25(金) 22:06:47
関数オブジェクト

109 :デフォルトの名無しさん:2009/09/25(金) 22:23:44
ありがとう
すると、コンパイラの最適化もかかりそうで嬉しいな。
どんな型の関数オブジェクトか分からないけどautoで受ければいいから問題ないか。


110 :デフォルトの名無しさん:2009/09/25(金) 22:29:05
lambdaで作られる関数オブジェクトのoperator()はインライン関数扱いみたいだしね
オーバーヘッドは最小限に抑えられるだろう

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

111 :デフォルトの名無しさん:2009/09/25(金) 22:56:09
仕様はコンパイラとのガチ勝負で覚えるのだ。

112 :デフォルトの名無しさん:2009/09/26(土) 00:12:06
なんで、lambdaをオブジェクトにしたかなぁ。
static領域やらスレッドローカルストレージでも利用して
関数に偽装してくれりゃよかったのに。typeidやらbad_exceptionだけでも、
ライブラリ依存の機能はうんざりだったんだが。

113 :デフォルトの名無しさん:2009/09/26(土) 00:14:19
そりゃキャプチャ持ってるからだろ

114 :デフォルトの名無しさん:2009/09/26(土) 00:18:13
関数のコードとインスタンスは別だよ。

115 :デフォルトの名無しさん:2009/09/26(土) 00:27:54
>>113-114
 それを知ってての上の話。
例外機構も事実上ライブラリ依存はしてるけど、
からくりを言語コアに封じ込めてるでしょ。
あんな感じにしてほしかった。
もっと言えば、昔BCCにクロージャーって機能があったが
あんな感じ。

116 :デフォルトの名無しさん:2009/09/26(土) 00:36:26
関数オブジェクトがインライン展開されて丸儲けとしか思えないが、
何が問題なのか分からん。具体的に問題点を例を挙げて説明してくれ。



117 :デフォルトの名無しさん:2009/09/26(土) 00:40:50
>>112
逆に考えるんだ。言語機能によって生成されるオブジェクトにアクセスするための
インターフェースとしてライブラリがあるのだと。 sizeof と size_t みたいなもんだ、と。

118 :デフォルトの名無しさん:2009/09/26(土) 00:59:27
ところで、lambdaってライブラリ依存なんてしてるの?
型もオブジェクトも完全にコンパイラ内部で生成されてて
ヘッダのincludeもランタイムのリンクも必要無いよね

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

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


120 :デフォルトの名無しさん:2009/09/26(土) 02:20:01
>>119
ライブラリじゃなかったら別リンケージでもインライン展開出来るという根拠は?
関数オブジェクトでもLTOが発達すれば特に劣る理由は無いと思うし、
関数オブジェクト一般を扱うコードとの親和性が高い分マシ

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

121 :デフォルトの名無しさん:2009/09/26(土) 02:44:30
で、結局関数オブジェクト以外のどういう実装でどう差が出てくるんだ?
現時点だとEmbedded C++信奉者の方がまだまともなレベル

122 :デフォルトの名無しさん:2009/09/26(土) 03:05:18
>>119
実装とベタベタに相互依存した最適化をすればいいだけじゃん
標準/準標準ライブラリあたりにはよくあること

123 :デフォルトの名無しさん:2009/09/26(土) 03:12:42
どうせ
std::initializer_list も range-based for-loop も
実装依存した最適化されるんでしょうし

124 :デフォルトの名無しさん:2009/09/26(土) 10:08:04
>>119
リンク時コード生成でインライン展開可能だよ

125 :デフォルトの名無しさん:2009/09/26(土) 13:11:23
関数オブジェクトは最適化が期待できる。
関数ポインタは最適化の期待が薄い上に分岐予測の妨害になりやすい。
関数ポインタも関数オブジェクト(std::function)の配列に格納できるので関数オブジェクトと共存できる。
>>119 関数ポインタのメリットは?


126 :デフォルトの名無しさん:2009/09/26(土) 13:24:33
生の関数ポインタは、間接性が全くなくて、そのアドレスに直接飛べるように
しなきゃならないから扱いが大変。

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

127 :デフォルトの名無しさん:2009/09/26(土) 13:43:50
「関数に偽装」って言ってるのが「関数そのものにしてくれ」とは別の意味なのだとしたら、
「lambdaも関数オブジェクトに偽装してるだけ」という可能性は考えないのだろうか

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

128 :デフォルトの名無しさん:2009/09/26(土) 14:14:41
関数ポインタの利点なら一番大事なのがあるだろ
Cのインターフェースに渡せること

129 :デフォルトの名無しさん:2009/09/26(土) 14:34:16
Cのインターフェースに渡す自体が非効率的だからなぁ…
どうしても必要なら、関数オブジェクトでも効率そのままで渡せるし

130 :デフォルトの名無しさん:2009/09/26(土) 14:39:46
なんか関数オブジェクトを魔法の杖みたいに思ってないか?

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

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

132 :デフォルトの名無しさん:2009/09/26(土) 14:52:28
レガシーコードに渡すなら普通に関数を定義すれば良いんじゃないか
そもそも関数ポインタとして扱えてキャプチャと並列安全性を両立って実装出来るの?

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

133 :デフォルトの名無しさん:2009/09/26(土) 14:59:00
Cから呼べない関数もどきなんて何の価値もないからねぇ…
C=レガシーって考えてるとしたら色々とズレてる

134 :デフォルトの名無しさん:2009/09/26(土) 15:11:31
関数ポインタしか渡せない C のインターフェースに任意の関数オブジェクト渡す
なんて、「最適化」の範囲でできることなの?

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

135 :デフォルトの名無しさん:2009/09/26(土) 15:12:05
remove_ifに渡すlambda関数にオーバーヘッドがあったらそれこそ使えないだろう。

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


136 :デフォルトの名無しさん:2009/09/26(土) 15:16:30
C++に無名関数オブジェクトが必要だということは前々から言われてたこと

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

137 :デフォルトの名無しさん:2009/09/26(土) 15:58:32
PODの要件緩くしたりunionも使いやすくしたり
Cとの連携は必要ないどころかC++0xでますます強化されてるんだけどな

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

138 :デフォルトの名無しさん:2009/09/26(土) 16:14:51
>PODの要件緩くしたり
これはCとの連携の強化とは逆の方向行ってるだろ

139 :デフォルトの名無しさん:2009/09/26(土) 16:27:45
>>137
まだ、関数オブジェクトに対する関数ポインタのメリットが示されていない。

140 :デフォルトの名無しさん:2009/09/26(土) 17:10:11
インタフェースの基本はCの関数だろ。あらゆるAPI、最新の言語でもそれを利用する。
そうでなければCOMの様な複雑なインターフェースを考えることになる。

141 :デフォルトの名無しさん:2009/09/26(土) 17:30:01
>>140
で?
そんなところは局所化して一段ラップすれば済むんだから、関数ポインタに特化するような
規則を標準化する必要性にはつながらないでしょ?

142 :デフォルトの名無しさん:2009/09/26(土) 18:13:56
>>139
思いつきで言ったのに反論されて、
粘着しているだけなんじゃないのかね。

143 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/09/26(土) 18:54:22
>>140
WindowsAPIはC呼び出しではなく、PASCAL呼び出し(stdcall)なんだけどな。


145 :デフォルトの名無しさん:2009/09/26(土) 19:55:41
利点はもう一個あるな

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

146 :デフォルトの名無しさん:2009/09/26(土) 20:10:23
コンテキストを保持する構造体無しで関数ポインタだけでクロージャを実装しろとか、
コンパイラ屋をなんだと思っているんだ

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

147 :デフォルトの名無しさん:2009/09/26(土) 20:19:19
何だと思ってるんだと言われても、現に関数オブジェクトなせいで使いづらくなってるだろ
むしろコンパイラ屋は何を考えてるんだといいたい

148 :デフォルトの名無しさん:2009/09/26(土) 20:31:30
不可能ではないし。

149 :デフォルトの名無しさん:2009/09/26(土) 20:33:12
ここでゴネて変更させようとしても
そりゃ不可能だよ。

150 :デフォルトの名無しさん:2009/09/26(土) 20:33:23
>>147
> 現に関数オブジェクトなせいで使いづらくなってるだろ
???
たとえばどんなときに?
具体的に頼む。

151 :デフォルトの名無しさん:2009/09/26(土) 20:39:48
関数オブジェクトの意味が分かってないだけなんじゃ、と思ってるのは俺だけだろうか

152 :デフォルトの名無しさん:2009/09/26(土) 20:40:05
例えばこれが出来ない

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

153 :デフォルトの名無しさん:2009/09/26(土) 20:42:21
ここでqsortを出すとは、>>152のセンスに恐れ入った

154 :デフォルトの名無しさん:2009/09/26(土) 20:44:09
アルゴリズムのヘッダが動かないと問題だと思うが。。。

155 :デフォルトの名無しさん:2009/09/26(土) 20:46:08
C++のライブラリにソートないの?

156 :デフォルトの名無しさん:2009/09/26(土) 20:47:06
ここで聞くなよ

157 :デフォルトの名無しさん:2009/09/26(土) 20:50:04
>>152 それだと「 std::sort() 使え」でおしまいだな。意味がわからん。

158 :デフォルトの名無しさん:2009/09/26(土) 20:52:07
「qsortに関数オブジェクト渡せないぞ!」とか言われても
「printfでoperator<<みたいにオブジェクト出力できないぞ!」とか言われてるような感じ。

159 :デフォルトの名無しさん:2009/09/26(土) 21:06:48
>>152
CのヘッダーはC++では使うメリットが無いし。
#include <algorithm>
を使って議論しようよね。



160 :デフォルトの名無しさん:2009/09/26(土) 21:12:54
たとえstd::sort()があったとしても、qsortも使えた方がいいに決まってるじゃん
std::sortはクイックソートじゃないかもしれないんだしさ

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

161 :デフォルトの名無しさん:2009/09/26(土) 21:16:03
>>145
それって鼻から悪魔じゃなかったっけ

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


162 :デフォルトの名無しさん:2009/09/26(土) 21:17:49
他の言語ならそうだけど他ならぬC++だからな
Cとの連携はちゃんとしてもらわないと言語の意味がない

163 :デフォルトの名無しさん:2009/09/26(土) 21:19:35
なんでgenericなstd::sortがあるのに、わざわざqsortを使わなきゃなんねーんだよ。
クイックソートであるかどうかにそんなに意味があるのかよ?

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

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

164 :デフォルトの名無しさん:2009/09/26(土) 21:19:41
杞憂ですね。

165 :デフォルトの名無しさん:2009/09/26(土) 21:23:25
彼、一人ですよね。レスが多いから多数派の意見なのかと不安になってくる

166 :デフォルトの名無しさん:2009/09/26(土) 21:26:54
例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
qsortは中でmemcpy使うからね

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

167 :デフォルトの名無しさん:2009/09/26(土) 21:28:07
>>162
lambdaがポインタでもオブジェクトでも後方互換は満たしてるじゃん。
新機能までわざわざCに追従させる意味があるんかいな。

168 :デフォルトの名無しさん:2009/09/26(土) 21:30:10
>>160
qsort() なら実際のアルゴリズムがクイックソートだというのも間違い。
std::sort() と同じぐらいに実装は自由。

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

169 :デフォルトの名無しさん:2009/09/26(土) 21:31:17
追従はしなくていいけど、出来るものはなるべくするべきだろう
キャプチャ付きのラムダまで全部関数ポインタにしろとは誰も言わない

170 :デフォルトの名無しさん:2009/09/26(土) 21:39:59
べ、別にCのためにlambdaを作ったわけじゃないんだから。勘違いしないでね。

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


171 :デフォルトの名無しさん:2009/09/26(土) 21:41:48
>>166
> 例えば少々大きめなPOD構造体の配列だったら、普通はqsortの方が早いでしょう
> qsortは中でmemcpy使うからね

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

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

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

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

172 :デフォルトの名無しさん:2009/09/26(土) 21:42:41
>>171
その当然あるべき変換operatorが今の規格にないことが問題でしょ?

173 :デフォルトの名無しさん:2009/09/26(土) 21:47:36
キミ以外の誰にとって問題なのか不明。

174 :デフォルトの名無しさん:2009/09/26(土) 21:47:49
>>172
それが、>>163のc_functionだね。

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


175 :デフォルトの名無しさん:2009/09/26(土) 21:49:48
>>172
当然あるべきと思うかどうかは人による。そこを主張しても意味が無い。

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

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

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

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


177 :デフォルトの名無しさん:2009/09/26(土) 22:06:44
現行のラムダさんは見た目は悪くても素直ないい子なのに、
常人に理解されにくい一面を増やしたりしたらかわいそうだよね

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

178 :デフォルトの名無しさん:2009/09/26(土) 22:08:28
>>176
その別人はカタコトの言葉しか使えないようだし
ほとんどの人にとっては区別がつくと思う。

179 :デフォルトの名無しさん:2009/09/26(土) 22:11:44
lambdaを関数ポインタとして呼べるようにしろってのは無茶言うなとは思うが、Cとの連携が強化されてほしいというのはわかる。
pmf-conversionとか、friend関数をExtension Methodのように取り扱えたらとか妄想して今日も寝る。

180 :デフォルトの名無しさん:2009/09/26(土) 22:59:09
つーかPODかどうかでmemcpyを使い分けるくらいは今時のテンプレートなら余裕だろ

181 :デフォルトの名無しさん:2009/09/27(日) 08:43:51
functionalだってqsortにはつかえねーじゃん…

182 :デフォルトの名無しさん:2009/09/27(日) 11:11:43
おまえらどんだけqsort好きなんだよ

183 :デフォルトの名無しさん:2009/09/27(日) 11:32:43
一人だけだろw

184 :デフォルトの名無しさん:2009/09/27(日) 13:10:43
あのgccですらqsortをstd::sortに書き換えを試みてるってのに
qsortが好きな奴なんて居るわけが無い

185 :デフォルトの名無しさん:2009/09/27(日) 13:53:00
いや一人いる

186 :デフォルトの名無しさん:2009/09/27(日) 14:30:55
それでもqsortが優れているのは
世界共通言語たるCの標準ライブラリに含まれてる由緒正しい関数だということ

187 :デフォルトの名無しさん:2009/09/27(日) 14:48:53
世界共通言語たるC++の標準ライブラリに含まれてる由緒正しいstd::sortはどうなのか

188 :デフォルトの名無しさん:2009/09/27(日) 15:18:42
Cで動かないコンピュータは事実上存在しないけど
C++が使えない処理系ならいっぱいある
世界共通言語とは言えないね

189 :デフォルトの名無しさん:2009/09/27(日) 15:22:27
>>188
いっぱいある?昔はそんなこともあったように思うが、今だともう思い当たらないな。
たとえばどの処理系のこと言ってるの?

190 :デフォルトの名無しさん:2009/09/27(日) 15:36:04
そんなにC信者ならC使ってりゃいいじゃん。

191 :デフォルトの名無しさん:2009/09/27(日) 15:43:49
freestandingだってC++処理系だよ

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

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

192 :デフォルトの名無しさん:2009/09/27(日) 15:51:03
C++0xで日本語ページをぐぐった結果を見ると絶望的だな

193 :デフォルトの名無しさん:2009/09/27(日) 16:00:23
おまえら詳しいんだろうから書いてくれ

194 :デフォルトの名無しさん:2009/09/27(日) 16:18:28
>>188
お前の言いたいのは処理系じゃなくて環境だろ。

195 :デフォルトの名無しさん:2009/09/27(日) 16:24:04
環境といっても職場やチームの環境だったりしてな。

196 :デフォルトの名無しさん:2009/09/27(日) 17:25:58
>>189
俺も同感。今時の開発環境でCが使えるのにC++が使えない環境を
教えて欲しいと思う。そういった仕事が来たら調査しないで速攻
で断りたいから。

197 :196:2009/09/27(日) 17:29:13
あ、Linuxのカーネルモジュールの場合とかはあるな。
でも、その場合はしょうがないって諦められるから心理的
ストレスは(俺の場合)殆ど無い。

198 :デフォルトの名無しさん:2009/09/27(日) 17:31:54
一部の組み込みみたいにリソースの厳しい場合もEmbedded C++でしっかりカバーできおっと誰か来たみたいだ

199 :デフォルトの名無しさん:2009/09/27(日) 19:05:09
C++が使える場所でもメンバーの大体はベターC的なコード書いてて
そういうモジュールを使わなきゃいけないってことはよくあるというか
そういう場合の方が多いがなぁ。

200 :デフォルトの名無しさん:2009/09/27(日) 19:10:26
「いっぱいある」と言いながら具体的な例はひとつも出せない。下手な印象操作の典型だな。

201 :デフォルトの名無しさん:2009/09/27(日) 20:38:30
Better C的なコードを書くような連中はlambdaも使わないだろうからどうでもいい

202 :デフォルトの名無しさん:2009/09/28(月) 22:58:30
> Cが使えるのにC++が使えない環境
実行時コンパイルとか、マニアックな条件ならありえる。

203 :デフォルトの名無しさん:2009/09/29(火) 00:01:43
TCCのことかー
あと、clangなんかも良いCコンパイラだけど、
C++コード生成はまだまだ実装されそうにないな

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

204 :デフォルトの名無しさん:2009/09/29(火) 02:05:52
懸案のコンセプトは消えて、主要機能はあらかた固まってきて
あとはRange-based forがどんどん腐っていくのを見守るくらいしかないからなぁ

205 :デフォルトの名無しさん:2009/09/29(火) 03:15:26
C++0xを使い始めるのはVC10の正式リリース待ち、っていう住民も多いだろうが、
実装されるものはBeta1の時点でほぼ確定しているし、gcc使いにはあまり興味の沸かない話だ

206 :デフォルトの名無しさん:2009/09/29(火) 09:28:31
range-based for、大丈夫かなあ
conceptに禍根を残さないようにお願いしたい

207 :デフォルトの名無しさん:2009/09/29(火) 22:14:34
誰かrange-based forさんの服を洗濯してあげて下さい

208 :デフォルトの名無しさん:2009/09/29(火) 23:56:23
洗濯したら破れちゃったんですが

209 :デフォルトの名無しさん:2009/09/30(水) 01:33:37
禿は破れたのを繕うの得意です

210 :デフォルトの名無しさん:2009/09/30(水) 01:58:39
range-based for
いらねぇぇ
将来conceptの邪魔になりそう

211 :デフォルトの名無しさん:2009/09/30(水) 01:59:20
forさん「妹なんていなかった」

212 :デフォルトの名無しさん:2009/09/30(水) 07:46:44
gcc lambda branchが最終調整に入ったようだ
これなら残り24時間ちょっとのstage 1終了までのマージに間に合うはず
stage 1が終わったら新機能の追加は許されなくなるから、
残りのC++0x実装は来年の4.6もしくは5.0に持ち越しかな

213 :デフォルトの名無しさん:2009/09/30(水) 12:20:12
というわけで、lambda branchがtrunkにマージされた
http://gcc.gnu.org/viewcvs?view=revision&revision=152318

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

214 :デフォルトの名無しさん:2009/09/30(水) 18:19:51
よかったねラムダさん!

215 :デフォルトの名無しさん:2009/09/30(水) 20:30:32
C++1xはinline perl(プリプロセッサ用)が搭載予定!

216 :デフォルトの名無しさん:2009/09/30(水) 20:56:32
さようなら Boost な lambda さん!

217 :デフォルトの名無しさん:2009/09/30(水) 22:21:46
std::bind 向けに Boost.Lambda っぽいのも残るんじゃなかった?
std::placeholder::_1 とかいうのが。

218 :234:2009/09/30(水) 23:47:10
そういえば、lambdaとbindって機能がダブってない?


219 :デフォルトの名無しさん:2009/10/01(木) 00:54:57
switchとifがダブってると思うならそうなんだろう

220 :デフォルトの名無しさん:2009/10/01(木) 01:47:54
ifとswitchで条件分岐がダブってしまった…
ガーンだな

221 :デフォルトの名無しさん:2009/10/01(木) 02:51:51
9月号来た。
>14.10 Concepts [concept]
>removed.

Oh!

222 :デフォルトの名無しさん:2009/10/01(木) 03:22:16
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

223 :デフォルトの名無しさん:2009/10/01(木) 07:37:24
落とせない

224 :デフォルトの名無しさん:2009/10/01(木) 17:53:06
>>218
そうかも
一応、bind自体の機能はbindの方がlambdaのbindよりも高機能だ
stdcallやfastcallの関数もbindできる

225 :デフォルトの名無しさん:2009/10/01(木) 19:54:17
コンセプトさんの埋葬が終わったと聞いて

226 :デフォルトの名無しさん:2009/10/01(木) 19:55:46
コンセプトさんはコールドスリープ中よ

227 :デフォルトの名無しさん:2009/10/01(木) 20:22:12
>>224
専門家だけあって強力なのね。


228 :デフォルトの名無しさん:2009/10/01(木) 20:27:10
あのクソみてえな拡張for文の文言が入っちゃってるよ…

229 :デフォルトの名無しさん:2009/10/01(木) 23:50:31
autoがあるんだから普通にループ回せよ
どんだけタイピングしたくねぇんだよ

230 :デフォルトの名無しさん:2009/10/01(木) 23:55:35
拡張for文があることで何か不都合があるというのであればそれを指摘するべきですな。
あって困るものとは思えません。
新しいことがもう覚えられないとかそういうことですか?

231 :デフォルトの名無しさん:2009/10/02(金) 00:07:00
>>230
このスレでも誰か言っていなかったっけ。
次にConceptが入って拡張forを作り直すとき、
現在の拡張forが(互換性のためと言って)邪魔にならないだろうかという懸念。

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

232 :デフォルトの名無しさん:2009/10/02(金) 00:12:44
名前が悪いってことだろ

233 :デフォルトの名無しさん:2009/10/02(金) 00:26:09
どうせSFINAEやらtraitsを使ったやつは
次にConceptを導入するときに書き直したりすることになるんでしょ
for loopがその中の一つになっても別にって感じ

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

234 :デフォルトの名無しさん:2009/10/02(金) 00:26:10
http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=152358
lambdaの影に隠れて、constexprも実装された件
これがはじめての実装だから弄るのが楽しみだな

235 :デフォルトの名無しさん:2009/10/02(金) 00:48:15
とりあえず constexpr はまだ準備中ってところだね。
http://www.pubbs.net/gcc/200909/129886/
これからの発展を祈る!

236 :デフォルトの名無しさん:2009/10/02(金) 02:29:57
BOOST_FOR_EACHとか書く奴が本当にBOOST_FOREACHのお世話になってるのか
疑わしい

237 :デフォルトの名無しさん:2009/10/02(金) 07:35:25
仕事で使えるのはいつのことやら。
いじって遊ぶなんて意味ないんだが。

238 :デフォルトの名無しさん:2009/10/02(金) 07:46:35
foreachに#defineするとかっこいいぞ

239 :デフォルトの名無しさん:2009/10/02(金) 08:16:00
小文字にdefineしちゃうと「中身は実はマクロだから色々注意が要りますよ」感が
無くなるのがなぁ

240 :デフォルトの名無しさん:2009/10/02(金) 08:50:13
BOOST_FOREACHEはマクロでの評価回数の罠を解決しているぞ。
でも、,の罠は引っかかるけどコンパイルエラーがでるから問題ない。



241 :デフォルトの名無しさん:2009/10/02(金) 11:11:33
少しずつ間違えるのがナウなヤングにバカうけ?

242 :デフォルトの名無しさん:2009/10/02(金) 11:21:48
俺はハッピーターン派

243 :デフォルトの名無しさん:2009/10/02(金) 12:45:24
最近のコンパイラは18446744073709551616回未満のループなら展開しちゃうからforeachとか気にしなくていいよ

244 :デフォルトの名無しさん:2009/10/03(土) 03:16:29
Win32 環境で gcc-4.5-20091001 使ってみた。

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

245 :デフォルトの名無しさん:2009/10/03(土) 13:19:20
まだも何もN2960ではまだ関数構文の統合は入ってないぞ

246 :デフォルトの名無しさん:2009/10/03(土) 16:13:41
>>244
拡張sizeofもOKのようだ。

247 :デフォルトの名無しさん:2009/10/03(土) 18:03:16
>>243
サーバプロセスのメインループで停まらないんですけど?

248 :デフォルトの名無しさん:2009/10/05(月) 16:32:54
Conceptsを殺した上に今年中に作る気がないとかふざけ過ぎだろ。

249 :デフォルトの名無しさん:2009/10/05(月) 18:34:42
キモい奴しか使わないゲンゴシヨウナンテイラネーヨ。

250 :デフォルトの名無しさん:2009/10/05(月) 21:33:54
>>248
Conceptsあのままでも間に合わなかったが、
抜くことになって余計時間はかかることになった。

251 :デフォルトの名無しさん:2009/10/07(水) 18:19:37
5年後には結局また入れることになるかもしれない文言を取り除いて調整する
不毛で後ろ向きな作業を見てるのは辛い

252 :デフォルトの名無しさん:2009/10/07(水) 21:59:25
decltypeってどう読んどけばいいの?

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

253 :デフォルトの名無しさん:2009/10/07(水) 22:37:12
declared type of の略だからデクルタイプでいいんじゃない

254 :デフォルトの名無しさん:2009/10/08(木) 06:52:26
でくれあーたいぷ

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

256 :デフォルトの名無しさん:2009/10/09(金) 06:57:50
既存のコードでバグりそうだなw

257 :デフォルトの名無しさん:2009/10/09(金) 07:19:35
で、聞きたいが、遅延展開は仕様に入ってるの?

258 :デフォルトの名無しさん:2009/10/09(金) 08:20:00
>>255
ムーブコンストラクタは魔法使いにしか使えないよ。

259 :デフォルトの名無しさん:2009/10/09(金) 18:52:18
おいおい、定義体の遅延展開もないの?
どれだけ現場を知らないやつが、仕様作ってるわけ⁈
馬鹿どもが。

260 :デフォルトの名無しさん:2009/10/09(金) 19:07:05
ラムダ式を使えば遅延評価的なことは出来るんじゃないの

261 :デフォルトの名無しさん:2009/10/09(金) 19:29:27
#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"));
}


262 :デフォルトの名無しさん:2009/10/10(土) 09:54:29
「宣言だか関数呼び出しだかよくわからんものはとりあえず宣言として解釈しちゃうぜ」
的な問題は解決する気はないのかな

263 :デフォルトの名無しさん:2009/10/10(土) 10:01:57
どこでも宣言が可能な以上、新たなキーワードなしには無理なんじゃない?
コンストラクタに関してはUniformな構文({}を使うやつ)で回避できるようになるけど。

264 :デフォルトの名無しさん:2009/10/10(土) 17:45:49
>>261
きれい

265 :デフォルトの名無しさん:2009/10/10(土) 19:16:17
[&]のほうがよくないか

266 :デフォルトの名無しさん:2009/10/10(土) 19:20:51
mainがreturnしてないょ

267 :デフォルトの名無しさん:2009/10/10(土) 19:23:32
             /)
           ///)
          /,.=゙''"/   
   /     i f ,.r='"-‐'つ____   こまけぇこたぁいいんだよ!!
  /      /   _,.-‐'~/⌒  ⌒\
    /   ,i   ,二ニ⊃( ●). (●)\
   /    ノ    il゙フ::::::⌒(__人__)⌒::::: \
      ,イ「ト、  ,!,!|     |r┬-|     |
     / iトヾヽ_/ィ"\      `ー'´     /

268 :デフォルトの名無しさん:2009/10/10(土) 19:27:08
>>266
mainはreturnしなくてもいいよ

269 :デフォルトの名無しさん:2009/10/11(日) 01:10:59
>>266
ユー・アー・古い!

270 :デフォルトの名無しさん:2009/10/11(日) 01:32:21
266じゃないけど、そうなの?
returnもretrunもneutronもしなくていいの?

271 :デフォルトの名無しさん:2009/10/11(日) 01:45:53
C++98や03の時点で、main関数でreturnすることなく関数の終わりに達したら
return 0;を行うというような旨の規定があるので省略可能。

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

272 :デフォルトの名無しさん:2009/10/11(日) 02:51:34
どうもありがとう。
X3014の35ページ 3.6.1 第5節に書いてあるのね。

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

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

273 :デフォルトの名無しさん:2009/10/15(木) 15:11:44
みてみて!シングルトンの汎用クラス作ったの!!シングルトンはあんまり好きじゃないけど、思考実験成功なの!!!
動的なメモリ確保はできなかったけど、必要十分だと思うの。環境は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;
}

274 :デフォルトの名無しさん:2009/10/15(木) 15:17:22
雛苺乙

275 :デフォルトの名無しさん:2009/10/15(木) 18:33:39
仕事にどうやって使えと?

276 :デフォルトの名無しさん:2009/10/15(木) 18:53:36
ScreenObjのコンストラクタがpublicでもSingleton<ScreenObj>が使えちまう。
どこがシングルトンなのかと小一時間。
せめて Curiously Recurring Template Pattern にしろよ。

277 :デフォルトの名無しさん:2009/10/15(木) 20:26:32
せっかくの0xスレなんだから何か新機能使えよ

278 :デフォルトの名無しさん:2009/10/16(金) 00:46:15
>>273
staticなインスタンスを使用する、メイヤーズさんのシングルトンですな。
残念ながらこの方式には欠陥があることが知られている。
詳しくは「Modern C++ Design」を読もう。

279 :デフォルトの名無しさん:2009/10/16(金) 01:36:45
初期化のタイミングだっけ。
昔critical sectionでこの方法を使おうとして悩まされたわ。

280 :デフォルトの名無しさん:2009/10/16(金) 06:59:25
言語に悩まされるようじゃ、しごとでつかえねーよ。

281 :デフォルトの名無しさん:2009/10/16(金) 08:05:36
これが駄目ならどの言語でも駄目だから、プログラミングの仕事はしない方がいい

282 :デフォルトの名無しさん:2009/10/16(金) 08:32:39
VS2010スレで案内されてきました
右辺値参照について質問です

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

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

283 :デフォルトの名無しさん:2009/10/16(金) 12:31:49
>282
const 修飾された右辺値参照の使い道はおそらく
ほとんど無いのではないかと思います.

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

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

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

284 :デフォルトの名無しさん:2009/10/16(金) 18:08:14
ほとんど無い仕様なんかいらね〜。

285 :282:2009/10/16(金) 19:46:41
>>283
なるほど…わかりました
ありがとうございます

286 :デフォルトの名無しさん:2009/10/16(金) 20:39:28
>>283
template<class T>
void hoge(T&& a)
{


287 :デフォルトの名無しさん:2009/10/16(金) 20:41:11
>>286 なんか送信してしまった
で T=const Fuga が渡されたときでもそれっぽくいくようにじゃね?
でもconst Fugaだと結局関数内でエラーになるな。やっぱり意味ないか?

288 :デフォルトの名無しさん:2009/10/17(土) 01:21:27
>>287
>>286 のときに T = const Fuga になるのは,
const 修飾した右辺値で hoge が呼び出されたとき
(か, hoge を T = const Fuga で explicit specialization したとき)ですけれど,
右辺値参照があるならば const 修飾した右辺値を生成することに
ほとんど意味が見出せなくなるので,そういう意味でもやはり意味が無いかと思います.

289 :デフォルトの名無しさん:2009/10/18(日) 23:30:01
なんかすごいね

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


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


290 :デフォルトの名無しさん:2009/10/19(月) 00:17:55
せっかくの0xなんだからこういう拡張はattributeにしろと思わなくもない

291 :デフォルトの名無しさん:2009/10/19(月) 09:49:55
グダグダです。

292 :デフォルトの名無しさん:2009/10/19(月) 20:34:04
>>289
std::threadかintel TBBか、並列構文か、まあ、それぞれが競合しそうに無いから臨機応変に併用もできるのかな。


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

293 :デフォルトの名無しさん:2009/10/19(月) 20:57:34
#ifndef __INTEL__
#define __par
#endif


294 :デフォルトの名無しさん:2009/10/20(火) 06:58:27
仕事に使える、必要とされている機能以外はいらん。


295 :デフォルトの名無しさん:2009/10/20(火) 10:46:56
>>294
意外かもしれないが、お前以外はお前と違う仕事をしてるから、
お前が必要としていない機能を必要とすることもあるんだよ。

296 :デフォルトの名無しさん:2009/10/20(火) 11:17:32
独習C++0x〜仕事で使える新機能〜
翔泳社より201x年発行

297 :デフォルトの名無しさん:2009/10/20(火) 11:27:17
第一章:C++0x以前、プリプロセッサのおさらい
第二章:raw string literalとは何ぞや
第三章:user defined literalのすすめ
第四章:conceptなしのrange-based forは超簡単


298 :デフォルトの名無しさん:2009/10/20(火) 21:13:47
>>295
それって情報産業?
どんな仕事か言っでみ?

299 :デフォルトの名無しさん:2009/10/20(火) 21:19:47
コンパイラ作ってます

300 :デフォルトの名無しさん:2009/10/20(火) 21:24:09
>>298
工場長、今日はもう家に帰ってください。

301 :デフォルトの名無しさん:2009/10/20(火) 22:30:41
いい加減ドモホルンリンクルを見つめ続けるのにも飽きたお

302 :デフォルトの名無しさん:2009/10/20(火) 22:33:42
テンプレートと例外は必要とされてない
なぜなら俺様にはわからないからだ(キリッ

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

303 :デフォルトの名無しさん:2009/10/20(火) 23:02:54
unary_functionを継承しただけで数十行のコードレビューに2時間近くもかかる
(関数オブジェクトの基礎からレビュアーに説明)こんな世の中じゃ

304 :デフォルトの名無しさん:2009/10/20(火) 23:12:02
そんなレビュアーは窓から投げ捨てればおk

305 :デフォルトの名無しさん:2009/10/20(火) 23:25:02
投げ捨てられるのはむしろ自分になるという罠

306 :デフォルトの名無しさん:2009/10/20(火) 23:33:38
むしろ投げ捨てられるのはprogre

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

307 :デフォルトの名無しさん:2009/10/20(火) 23:34:43
数少ない概念で多くの状況に対応しえていた C から一転、
新しい概念を次から次へと追加しまくってメタボってる C++ には神を感じない

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

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

308 :デフォルトの名無しさん:2009/10/20(火) 23:35:55
>>307
具体的にしゃべれアホ

309 :デフォルトの名無しさん:2009/10/21(水) 00:05:39
C++0xって、幻想だったの?夢だったの?
もうすぐ2009年が終わってしまうのに・・・

310 :デフォルトの名無しさん:2009/10/21(水) 08:50:04
まだ2ヶ月ある!

311 :デフォルトの名無しさん:2009/10/21(水) 09:16:17
ずっと前から2011年て予定出てたじゃん…最低でもそれより後になるでしょ

312 :デフォルトの名無しさん:2009/10/21(水) 09:53:45
>>307
> 数少ない概念で多くの状況に対応しえていた C から一転、

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



313 :デフォルトの名無しさん:2009/10/21(水) 10:21:54
xはまだa〜fまであるよ

314 :デフォルトの名無しさん:2009/10/21(水) 14:18:28
0xの正規表現はSJIS使えますか?

315 :デフォルトの名無しさん:2009/10/21(水) 18:11:14
>>313
xは16進数だ!、って話はよく聞くけど、
それは、ネタなの?
本当に最初からそうで、情弱な俺が知らなかっただけ?

316 :デフォルトの名無しさん:2009/10/21(水) 19:30:38
ネタだよ
なにしろ最初は2008年に発行するつもりだったんだから

317 :デフォルトの名無しさん:2009/10/21(水) 19:41:09
発行しないほうが幸せだな。

318 :デフォルトの名無しさん:2009/10/21(水) 22:15:36
ワシの0xは108まであるぞ

319 :デフォルトの名無しさん:2009/10/21(水) 22:51:35
>>318
だまれ

320 :デフォルトの名無しさん:2009/10/21(水) 22:54:53
C++0x2108

321 :デフォルトの名無しさん:2009/10/22(木) 07:15:32
こんなお粗末な展開なら、出ても意味なしだな。

322 :デフォルトの名無しさん:2009/10/22(木) 09:09:40
意味なんてあろうが無かろうが、仕事にフィットする言語/処理系を使えばいいだけ。

323 :デフォルトの名無しさん:2009/10/22(木) 19:55:54
じゃあ私は言語に合った仕事を探すことにします。

324 :デフォルトの名無しさん:2009/10/22(木) 21:49:56
>>308
いやな予感を new から感じ取れないアホに type なんたらシリーズという以上の説明は不能

325 :デフォルトの名無しさん:2009/10/22(木) 21:52:18
説明できないんじゃないんですよね、わかります

326 :デフォルトの名無しさん:2009/10/22(木) 21:58:45
 ( <●><●>)
  (U      )つ  わかってます。
    u  u

327 :デフォルトの名無しさん:2009/10/22(木) 23:35:21
確かにplacement new[]とか例外時のplacement deleteとかクソなものはあるけど
そこは触らなければいいだけのことじゃない

328 :デフォルトの名無しさん:2009/10/23(金) 04:26:47
>>324
new の何が嫌なのか言ってみろアホ

329 :デフォルトの名無しさん:2009/10/23(金) 07:05:50
嫌な予感がするnewだからこそ、小回りが聞いて仕事にも使えたのにな。


330 :デフォルトの名無しさん:2009/10/23(金) 08:36:22
newとtypeinfoは-というより
C++の演算子オーバーロード全体の問題だと思うけどね

331 :デフォルトの名無しさん:2009/10/23(金) 12:22:41
0x関係ないがな

332 :デフォルトの名無しさん:2009/10/23(金) 19:15:04
VC10にnullptrがついたらしい

333 :デフォルトの名無しさん:2009/10/23(金) 20:03:13
g++ の std::set に emplace 入るのはいつなんだろうか…

334 :デフォルトの名無しさん:2009/10/23(金) 21:12:42
で、お前ら仕事はなんだ?

335 :デフォルトの名無しさん:2009/10/23(金) 21:31:26
電子土木作業員

336 :デフォルトの名無しさん:2009/10/23(金) 21:47:04
>>328
>>307 で言ってるんだが
アホには通じてないというだけ

337 :デフォルトの名無しさん:2009/10/23(金) 23:41:30
「いやな予感は new からすでにくすぶっていた」の一言だけで
お前がnewで嫌だと思う所が通じないのがアホだとしたら
この世にアホでない奴などいない

338 :デフォルトの名無しさん:2009/10/23(金) 23:43:41
new[]はクソだがvector使うから使わない

339 :デフォルトの名無しさん:2009/10/24(土) 00:12:22
統合失調の奴が書いた小説みたいな文章読まされても…

340 :デフォルトの名無しさん:2009/10/24(土) 01:35:19
>>336
new の何が嫌なのか具体的に言ってみろアホ

341 :デフォルトの名無しさん:2009/10/24(土) 02:51:40
「言語とライブラリの分業が巧くない」って言っているからには、
307自身が今から作るとしたらどうするかってのは気になるよね。

342 :デフォルトの名無しさん:2009/10/24(土) 03:16:21
>>307はほっとくとしても
newみたいにコア機能とライブラリが癒着してるのは気持ち悪い
でも0xでまた増えるんだよなぁ…

343 :デフォルトの名無しさん:2009/10/24(土) 03:44:30
まったく・・・
自分が嫌だと思うところがさも他人にも嫌であるに決まっていると盲信してるどころか
自分の考えが 状況に寄らず 科学的に真実であると思ってるだろ・・・
この場に>>307の主張を本人以外に説明できる人が現れたら>>307の話に耳を傾けることにする

344 :デフォルトの名無しさん:2009/10/24(土) 10:59:32
ttp://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/

345 :デフォルトの名無しさん:2009/10/24(土) 11:42:51
正しくて適切な素晴らしい判断ですね

346 :デフォルトの名無しさん:2009/10/24(土) 11:59:31
プログラマーと言語設計者の関係は
顧客とプログラマーの関係に等しい……
無理ばっかり言ってきやがる。

347 :デフォルトの名無しさん:2009/10/24(土) 14:33:24
もっと無理いっていいよ。
安定するまで使わなくてすむ。

348 :デフォルトの名無しさん:2009/10/24(土) 14:42:58
客は金払っているから馬鹿でも言うこと聞く必要あることがあるが、
馬鹿なプログラマは無視すればすむから無問題。
MSみたいに委員会の有力者を雇って、
自社技術を規格に潜り込ませようとするのは勘弁。

349 :デフォルトの名無しさん:2009/10/24(土) 14:43:27
安定? むしろ何を言おうが
無理言ってる人と無関係に言語仕様が固まるだけ。

350 :デフォルトの名無しさん:2009/10/24(土) 14:46:33
C++の標準化委員会の人たちはみんなボランディアだから
うるさいプログラマたちにうんざりしたら辞めちゃうだけだよ

351 :デフォルトの名無しさん:2009/10/24(土) 14:53:38
まあ少なくとも英語圏のサイトで英語でわめかなきゃ届かないでしょ。

352 :デフォルトの名無しさん:2009/10/24(土) 14:54:43
Unicode決め撃ちにしてくれってのは英語で届いちゃったみたいですけどねw

353 :デフォルトの名無しさん:2009/10/24(土) 15:05:00
もともと彼らの中にあるものは届きやすいだろうな。
少量の言葉の断片がかすっただけで「ああ、そのことね」と理解されるから。
でも、彼らの中に無い物は、必死で言葉にしていかなきゃ形にならないよ。

354 :デフォルトの名無しさん:2009/10/24(土) 18:58:50
c++0xって2009年中に出せなくてもC++0xっていい続けるの?
それともC++1xになるの?

355 :デフォルトの名無しさん:2009/10/24(土) 19:01:29
どうでもいいからみんな気にしてない。

356 :デフォルトの名無しさん:2009/10/24(土) 19:02:04
xは16進数だから2015年まではC++0xでおk

357 :デフォルトの名無しさん:2009/10/24(土) 19:09:42
正式な勧告で別称が確定するまでは、検索とかのためにC++0xと呼び続けた方が良いだろう

358 :デフォルトの名無しさん:2009/10/24(土) 19:26:14
C++03とかの呼び方って勧告で決まってるんだっけ?
出た後はあくまでただの「C++」じゃないの

359 :デフォルトの名無しさん:2009/10/24(土) 19:44:15
10年以内にまた改訂されることを考えるとC++1xの名称を残しておいてやっても良いんじゃないか

360 :デフォルトの名無しさん:2009/10/25(日) 00:42:48
10年以内にあるとしてもC++98→C++03程度の改訂じゃないの?

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

361 :デフォルトの名無しさん:2009/10/25(日) 00:48:56
次は昔募集していたTR2だろう。

362 :デフォルトの名無しさん:2009/10/25(日) 01:24:05
C90 の次が C9X と呼ばれていて C99 になったんだから現在検討中の規格が C++10 になったところで
その次の規格は C++1x と呼ばれるだけだろう。

363 :デフォルトの名無しさん:2009/10/25(日) 02:04:36
確かに次の規格をなんて呼ぶかは難しいところだw

364 :デフォルトの名無しさん:2009/10/25(日) 02:06:05
C++0x20くらいだろw

365 :デフォルトの名無しさん:2009/10/25(日) 02:06:31
>>352 一般的なことですが,まとめ役は意見を聞いて集めたあと
ダメなものはダメと毅然と却下するべきだね

366 :デフォルトの名無しさん:2009/10/25(日) 10:17:58
オタクはなぜ同じ話をぐだぐだと繰り返すのか

367 :デフォルトの名無しさん:2009/10/25(日) 10:46:43
同じ面子がずっとここに居座ってると思ってるのか?

368 :デフォルトの名無しさん:2009/10/25(日) 12:23:11
少なくともこの間から仕事がどうこう言う奴は居座ってるな

369 :デフォルトの名無しさん:2009/10/25(日) 12:45:18
詳細部分を「どうこう」でまとめていいなら
結構大勢の人間を同一人物認定できるだろう。

370 :デフォルトの名無しさん:2009/10/25(日) 12:56:31
すぐ具体的な指摘がない極論が出る始末

371 :デフォルトの名無しさん:2009/10/25(日) 18:32:24
仕事で使える言語を頼む。

372 :デフォルトの名無しさん:2009/10/25(日) 18:35:12
こんな感じで話がループして、
0xの仕様もなかなか決まらないのかな?

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

373 :デフォルトの名無しさん:2009/10/25(日) 19:00:32
独裁者が居ないんだからしょうがない。
「仲」でモノが早く決まるような集まりに決めてもらっても困るし。

374 :デフォルトの名無しさん:2009/10/25(日) 19:06:21
>>373
そうなの?
創始者のハゲに9割くらいの決定権があるのじゃないの?

375 :デフォルトの名無しさん:2009/10/25(日) 19:16:43
禿に強力な権力があるならconceptがああなることはなかったろうな

376 :デフォルトの名無しさん:2009/10/25(日) 19:43:30
>>374
おまえこのスレにいてこれすら読んでないとは、
ttp://www.devx.com/cplus/Article/42448/0/page/4

モグリだな。


377 :デフォルトの名無しさん:2009/10/25(日) 20:54:20
一人一人が処理系作ってそれを定期的にレビューしあうようにすれ

378 :デフォルトの名無しさん:2009/10/25(日) 21:51:01
禿の影響力は個人としてはかなり強いけど、
禿そのものが無茶慎重な性格だからな。

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

379 :デフォルトの名無しさん:2009/11/02(月) 16:05:35
やっぱり C++1x は「予約」しておく必要がありそうだ。


380 :デフォルトの名無しさん:2009/11/03(火) 11:23:01
raw string はコードの見栄えがわるくするな。

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

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




381 :デフォルトの名無しさん:2009/11/03(火) 11:33:43
Raw String Literalってよく分からないなぁ。
どの辺が便利なんだろうか?


382 :デフォルトの名無しさん:2009/11/03(火) 11:37:14
R"[\n とか書かなくても
こうやって改行とかできるところじゃね?
特に長文とかなると便利かも]";

383 :デフォルトの名無しさん:2009/11/03(火) 11:41:24
ダブルクォートがガンガン入る文字列とか。

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

384 :デフォルトの名無しさん:2009/11/03(火) 12:30:07
>>381
here documentを言語にいれるのが最近の流行りじゃん。
馬鹿っぽいけどやっぱり便利ではあるよ。
\nを解釈できるライブラリばかりじゃないし。

385 :デフォルトの名無しさん:2009/11/03(火) 14:35:53
無理して入れるほどじゃないがあると便利なこともあるな。

386 :デフォルトの名無しさん:2009/11/03(火) 17:45:15
std::cout <<
R"[
>>390
こう書けばいいよ
]";

387 :デフォルトの名無しさん:2009/11/03(火) 18:43:21
未来のレスにレスですか

388 :デフォルトの名無しさん:2009/11/03(火) 20:33:15
>>387
>>390さんへの振りですか。


389 :デフォルトの名無しさん:2009/11/03(火) 22:42:16
ksk

390 :デフォルトの名無しさん:2009/11/03(火) 22:51:51
std::cout << "だが断る";

391 :デフォルトの名無しさん:2009/11/05(木) 10:44:06
改行よりはバックスラッシュとかダブルクオートとかのほうで便利そう

392 :デフォルトの名無しさん:2009/11/05(木) 22:05:10
>>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
こんな解説などが見つかりましたが今ひとつ分かりません。


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

394 :デフォルトの名無しさん:2009/11/05(木) 22:21:44
>>393
ありがとうございます。
やっとそれが導入されたわけですね。

395 :デフォルトの名無しさん:2009/11/06(金) 06:38:25
これ以上、仕様を複雑にして、
機能を多くして、どうするよ?

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

396 :デフォルトの名無しさん:2009/11/06(金) 07:00:43
>>395
むしろ足りないと思っているでしょうな。
TR2とか。

397 :デフォルトの名無しさん:2009/11/06(金) 08:28:40
>>393
スクリプト言語の仕様なんかいらなくない?
なんでそんなの必要なの?

398 :デフォルトの名無しさん:2009/11/06(金) 09:42:53
> スクリプト言語の仕様

頭おかしい人ですか?

399 :デフォルトの名無しさん:2009/11/06(金) 15:17:26
C++でヒアドキュメントがあると嬉しい場面ってあまり思いつかないな。
CLIなツールを作るときにうさげ書くのが楽になるってくらいしか出てこない。

400 :デフォルトの名無しさん:2009/11/06(金) 16:08:27
スクリプト言語の仕様なんかいらない

401 :デフォルトの名無しさん:2009/11/06(金) 17:45:40
>スクリプト言語の仕様
頭おかしい人ですか?

402 :デフォルトの名無しさん:2009/11/06(金) 18:00:27
どう見ても頭おかしい人ですな

403 :デフォルトの名無しさん:2009/11/06(金) 18:08:14
まさかの >>397 人気に嫉妬

404 :デフォルトの名無しさん:2009/11/06(金) 18:33:45
iostreamよりprintf属の方が相性良さそう

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

]", date, length);

405 :デフォルトの名無しさん:2009/11/06(金) 20:00:49
関係ないがHTTPヘッダの改行はCRLFだから明示的に指定した方が安全だと思う

406 :デフォルトの名無しさん:2009/11/06(金) 20:06:29
>>395
今の仕様が一貫性を欠いていて憶えにくいだけで、
例えば関数テンプレートを部分特殊化できないとか、
コンストラクタ実引数からクラステンプレート仮引数を導出できないとか、
その辺はむしろ「増やす」ことによってより単純化できるんじゃないか?

407 :デフォルトの名無しさん:2009/11/06(金) 20:07:27
>>405
ふつー、>404ではCRは入らないと思う。

408 :デフォルトの名無しさん:2009/11/06(金) 20:18:11
「ふつー」て、そんなの仕様次第じゃん。

409 :デフォルトの名無しさん:2009/11/07(土) 02:39:06
下手するとソースの保存のしかたで変わってしまいそうな気がする。

410 :デフォルトの名無しさん:2009/11/07(土) 13:15:38
インラインアセンブラ書く時ならヒアドキュメントもいいかも。
intrinsicsが浸透しつつある今ではインラインアセンブラの必要性自体が急速に減りつつあるけど。

411 :デフォルトの名無しさん:2009/11/07(土) 13:30:00
ヒアドキュメントなんてスクリプト言語っぽくなって、
カッコ悪くなるからイラない。

412 :デフォルトの名無しさん:2009/11/07(土) 14:00:19
C++なんてカッコ悪い構文だらけなのに何を今さら

413 :デフォルトの名無しさん:2009/11/07(土) 14:38:04
[&]

414 :デフォルトの名無しさん:2009/11/07(土) 14:42:31
[[笑]]

415 :デフォルトの名無しさん:2009/11/07(土) 15:47:31
C++からpython使えるようにしてあると、生ソースを埋め込めてちょっと便利かも。

416 :デフォルトの名無しさん:2009/11/07(土) 15:51:49
>>414
それは「括弧笑い」やー!

417 :デフォルトの名無しさん:2009/11/07(土) 16:53:54
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);


418 :デフォルトの名無しさん:2009/11/07(土) 19:35:59
4への不満が分からない

419 :デフォルトの名無しさん:2009/11/07(土) 19:39:51
3の関数監視try間違ってね?

420 :デフォルトの名無しさん:2009/11/07(土) 19:52:44
>>418
intの意味のなさじゃね
前置と後置を区別する方法は他になかったのかと

421 :デフォルトの名無しさん:2009/11/07(土) 20:02:07
ああ、後置インクリメントだったか

422 :デフォルトの名無しさん:2009/11/07(土) 20:12:28
>>419
Borland では通らないけど、これは
15 Exception handrling の 1 の
function-try-block:
try ctor-initializer opt compound-statement handler-seq
に違反してるな


423 :デフォルトの名無しさん:2009/11/07(土) 20:19:19
0xスレ的に0xの構文の話をすると、decltypeの括弧が個人的に一番アレ

424 :デフォルトの名無しさん:2009/11/07(土) 20:47:59
>>417
:をctor-initializer_optじゃなくて、
tryの方にくっつけるスタイルは始めて見た。

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

425 :デフォルトの名無しさん:2009/11/07(土) 20:55:39
ダサ「構文」とは関係ないだろ

426 :デフォルトの名無しさん:2009/11/07(土) 21:02:02
>>410
intrinsicsって何ですか?


427 :デフォルトの名無しさん:2009/11/07(土) 22:29:50
__builtin_mallocみたいなの

428 :デフォルトの名無しさん:2009/11/07(土) 22:35:14
>>417
5) はちがくね?
p->Hoge::~Hoge();

429 :デフォルトの名無しさん:2009/11/08(日) 02:55:08
pがHoge*ならちがくないよ

430 :デフォルトの名無しさん:2009/11/09(月) 12:07:54
×ちがくね?
○ちがわね?
○ちがってね?

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

431 :デフォルトの名無しさん:2009/11/09(月) 12:51:48
馬鹿に馬鹿さを突きつけると馬鹿なキレ方してくるよ

432 :デフォルトの名無しさん:2009/11/09(月) 12:59:23
馬鹿にはよくあること

433 :デフォルトの名無しさん:2009/11/09(月) 16:39:59
ネタにマジレスというネタか

434 :デフォルトの名無しさん:2009/11/09(月) 20:44:51
触ってやんなよ自己満足なんだから。

435 :デフォルトの名無しさん:2009/11/10(火) 18:51:22
| ||⊂⊃⊂⊃||
| || ロロロロロロ || がしゃーん
| || ・ ・・・ ・・ ||
| || ロロロロロロ ||
| || Coca Θ.|| がしゃーん
| ||口口口□||
|ミ||====||
   ̄ ̄ ̄ ̄
自動販売機だよ
自動で販売してくれる凄いやつだよ

436 :デフォルトの名無しさん:2009/11/10(火) 19:59:22
Post Santa Cruz mailingマーダー?

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

438 :デフォルトの名無しさん:2009/11/11(水) 14:15:22
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


439 :デフォルトの名無しさん:2009/11/12(木) 21:38:57
JavaScriptの改訂に先を越されそうだ

440 :デフォルトの名無しさん:2009/11/12(木) 21:50:54
郷の人気で吹っ飛ぶ鴨な

441 :デフォルトの名無しさん:2009/11/12(木) 23:16:01
GoはGC付き言語、JavaやC#やDと同じ
C/C++の代わりにはならない

442 :デフォルトの名無しさん:2009/11/12(木) 23:34:17
>>441
なぜ?

443 :デフォルトの名無しさん:2009/11/12(木) 23:39:01
>>441
お前の言い方だと
GC付き言語はC/C++の代わりにはならない
と言っているようにしか取れないんだけど、
何で?



444 :デフォルトの名無しさん:2009/11/12(木) 23:41:29
>>443
勉強しろ。お前には説明してもわからんよ

445 :デフォルトの名無しさん:2009/11/12(木) 23:42:15
デバドラの割り込みとかリアルタイム性のことを言ってるつもりなのか?

446 :デフォルトの名無しさん:2009/11/12(木) 23:42:41
だってGCが付いてたら実行時間予測できないじゃん
1秒を争う処理の最中に呑気にゴミ拾い始めたらどうするつもり?

447 :デフォルトの名無しさん:2009/11/12(木) 23:44:48
もなか?

448 :デフォルトの名無しさん:2009/11/12(木) 23:50:13
11月号来た

449 :デフォルトの名無しさん:2009/11/12(木) 23:53:05
>>444
> 勉強しろ。
お前は勉強した気になっているだけだろ。


450 :デフォルトの名無しさん:2009/11/13(金) 00:01:16
GCの性能は確かに上がってて、平均実行時間でならネイティブと大差なくなってきてるけどね
アプリならそれでいいんだろうけど、C++の得意分野で大事なのは最悪実行時間の方
少なくとも現代のGCはその方面では話にならない

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

451 :デフォルトの名無しさん:2009/11/13(金) 00:08:13
GCの有無だけで代わりにならないって言い切ってるところがすごいw

452 :デフォルトの名無しさん:2009/11/13(金) 00:35:19
だってそうでしょう
致命傷だも

453 :デフォルトの名無しさん:2009/11/13(金) 00:43:04
goやdはともかく、RTシステムに適用可能なGCとかあってもよさそうだけど。ないのかな?
もっとも、そろそろRTシステムのプログラミングは全部MATLABのオートコーダが持っていっちゃいそうな雰囲気だけどね

454 :デフォルトの名無しさん:2009/11/13(金) 01:08:00
Goおもしれー。D言語見たく、最初面白いけどその後意味不明にはなってほしくないな。
がんばれGoogleまけるなGoogle!

455 :デフォルトの名無しさん:2009/11/13(金) 01:43:40
N3010で頭痛くなってきた
わかるけどさ

456 :デフォルトの名無しさん:2009/11/13(金) 01:51:02
>>454
言語仕様のレベルで多機能や新しいパラダイムやスタイルを追っかけていけば意味不明になってくさ。

457 :デフォルトの名無しさん:2009/11/13(金) 01:52:57
>>451
GoがGCをオフにできるなら話は別だけどね。
どんな時にも使わなきゃいけないのなら、「C++にできてGoにできないことがある」わけで、
C++の必要性は潰えないのでは。

458 :デフォルトの名無しさん:2009/11/13(金) 03:45:52
メモリアロケートしなけりゃGC走らないんじゃないの

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

459 :デフォルトの名無しさん:2009/11/13(金) 05:05:48
「GCと同様」ってのが詐欺臭い言い回しだなぁw
とりあえずそのDの人はGCのペナの意味とかほとんど分かってないだろうな

460 :デフォルトの名無しさん:2009/11/13(金) 08:15:14
とりあえずおまえがわかってないな。

461 :デフォルトの名無しさん:2009/11/13(金) 10:53:10
GCが無ければいいような流れだけど、
GCがなくてもあまりいみないよ。

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

462 :デフォルトの名無しさん:2009/11/13(金) 10:55:36
そういうときは
あらかじめプールするんだが

463 :デフォルトの名無しさん:2009/11/13(金) 11:02:19
それがGCなんだが

464 :デフォルトの名無しさん:2009/11/13(金) 11:03:19
>>461
その機能がOSに無ければOSが動かなくなるだろ
98以前は再起動必要だったりしたが

465 :デフォルトの名無しさん:2009/11/13(金) 11:10:35
>>464
お前、アプリがメモリ要求したときに
いちいちOSからメモリをもらっていると思っているの?
そんなことしたらパフォーマンスが劣る

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

466 :デフォルトの名無しさん:2009/11/13(金) 11:25:41
プロセスなりスレッドなりの単位で
プールを確保・破棄すれば
断片化はある程度避けられるんだ

467 :デフォルトの名無しさん:2009/11/13(金) 11:33:38
GCもそんな感じで、パフォーマンスをあげているんだろうね。

468 :デフォルトの名無しさん:2009/11/13(金) 16:57:11
GCの問題は、GCがどのタイミングで動くかわからないところでしょ。
特にゲームではそれが問題になる。

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

469 :デフォルトの名無しさん:2009/11/13(金) 17:37:26
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-11
200x年最後のWorking Draftがn3000か。
結局Move Constructorはどうなるんだろうね。

470 :デフォルトの名無しさん:2009/11/13(金) 17:38:37
>>468
たいていの言語はGCを手動で実行・一時停止したり、
あらかじめメモリをプールしたり、特定のオブジェクトだけ破壊する方法をもってるよ。

471 :デフォルトの名無しさん:2009/11/13(金) 18:01:51
>>470
つまり結局手動でメモリ管理しなきゃならないわけだ

472 :デフォルトの名無しさん:2009/11/13(金) 18:04:48
>>471
GCのスケジューリングをメモリ管理と呼ぶならそうだな。
RAIIに関しては糖衣構文でかけるようになってる場合が多いから楽なもんだが

473 :デフォルトの名無しさん:2009/11/13(金) 18:40:54
>>470
GCが管理するメモリって自分が書いたコードのみならず、ライブラリも含まれるから、GCの動作を見積もれないよ。
手動でGCを操作するぐらいなら、GCない方が楽だし安全だと思う。

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

474 :デフォルトの名無しさん:2009/11/13(金) 21:29:40
メモリ管理を自分でしないなら、
C++の存在意義がなくなっちゃうじゃん。

475 :デフォルトの名無しさん:2009/11/13(金) 21:32:03
>>473
C++でもRAII使いたかったらオブジェクトをスタックに割り当てる必要があるだろ。
プログラマが気を遣うのはその程度で済むようになってる

476 :デフォルトの名無しさん:2009/11/13(金) 21:35:34
>>474
お前が確保したメモリは
物理メモリなのか
ディスク上のswapなのか
把握できるとでも言うのか?


477 :デフォルトの名無しさん:2009/11/13(金) 21:40:16
newをオーバーライドするようになって、
初めて一人前のC++使い

478 :デフォルトの名無しさん:2009/11/13(金) 21:50:03
newのオーバー…ライド???

479 :デフォルトの名無しさん:2009/11/13(金) 21:50:25
swapされてるとか関係ないじゃん

480 :デフォルトの名無しさん:2009/11/13(金) 23:20:40
>>475
RAIIとは言わないのかもしれないが、ヒープに割り当てた時でも、
オブジェクトが参照されなくなったらすぐにメモリ解放と一緒にデストラクタが呼ばれる事にメリットはあると思う。

481 :デフォルトの名無しさん:2009/11/13(金) 23:30:58
GCはメモリしか管理できないのが最大の問題点だと思う

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

482 :デフォルトの名無しさん:2009/11/13(金) 23:38:40
> 大して問題にはならない

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

483 :デフォルトの名無しさん:2009/11/14(土) 05:04:54
>>476
スワップ禁止の物理メモリに確保するAPIとか普通あると思うけど
そういうのが必要な時にそれを使えると使えないとの違いは大きい
必要ない時でも、RAIIの方がタイミングはコントロールしやすい

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

484 :デフォルトの名無しさん:2009/11/14(土) 05:15:05
alloca

485 :デフォルトの名無しさん:2009/11/14(土) 05:55:07
GC自体は禿も否定はしてない、むしろ肯定的。
しかしながらGCの存在が問題になる対象も確実にあり、C++はこれを切り捨てない。
他でもないC/C++が必要になる場面はこれからもあるだろう。

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

486 :デフォルトの名無しさん:2009/11/14(土) 10:31:27
既存言語を完全にリプレイスできる言語ってめったにないと思うんだ。

487 :デフォルトの名無しさん:2009/11/14(土) 10:34:32
>>486
そんなんあったら俺に教えてくれ。

488 :デフォルトの名無しさん:2009/11/14(土) 10:39:13
取って代わられて廃れるケースはあるな
C++みたいに膨大な利用ベースを持つ言語になると、そういうのも考えづらいが

489 :デフォルトの名無しさん:2009/11/14(土) 11:03:30
完全ではないがアセンブラをリプレースすべく作られ、ほぼ成功したのが C だったな

490 :デフォルトの名無しさん:2009/11/14(土) 11:05:52
馬鹿発見

491 :デフォルトの名無しさん:2009/11/14(土) 11:14:59
美少女中学生が馬鹿を発見しました!

492 :デフォルトの名無しさん:2009/11/14(土) 11:19:56
軽さは正義だからな。マシンパワーが増加すればやりたいこともまた増えるし。
フリーランチは終わったし、アムダールの法則も健在だから、当面はC++でいいけど。

493 :デフォルトの名無しさん:2009/11/14(土) 11:25:38
>>489
俺もそれは思う。



だが!

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

494 :デフォルトの名無しさん:2009/11/14(土) 17:34:00
>>481
GC付きの言語でも明示的にオブジェクトを破壊することができるから、それは全くの杞憂

495 :デフォルトの名無しさん:2009/11/14(土) 17:40:25
全部明示的に破壊すれば、だな
その場合、GCは無駄なオーバーヘッドになるが

496 :デフォルトの名無しさん:2009/11/14(土) 17:46:50
>>495
GC管理外のリソースを持っているオブジェクトだけ破壊すればいいのであってすべて明示的に壊す必要はない

497 :デフォルトの名無しさん:2009/11/14(土) 18:49:58
お前らスレチ!

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

498 :デフォルトの名無しさん:2009/11/14(土) 18:51:36
>>446
時間予測できればいいならGCありでもよさそうな気がする。
旧式のマークアンドストップじゃだめだけど。

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

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


499 :デフォルトの名無しさん:2009/11/14(土) 19:21:05
その辺ちゃんと考えて作られてればGC付きでもいいんだろうけどな
API駆使すれば一応出来るってんじゃなくて、言語設計の時点で

500 :デフォルトの名無しさん:2009/11/14(土) 19:32:10
>>499
最後の一言、しみ入るな
#include <gc>
とか、やめて欲しい

501 :デフォルトの名無しさん:2009/11/14(土) 21:13:36
>>493
話すべき事に、もともと実りがないんだから仕方がない。

502 :デフォルトの名無しさん:2009/11/16(月) 12:19:26
>>477
最近覚えたんだね^^

503 :デフォルトの名無しさん:2009/11/16(月) 12:53:26
無知の知とかあのプログラマーレベルの話を思い出した

504 :デフォルトの名無しさん:2009/11/16(月) 12:54:23
>>499-500
そうするとC++/CLIになる予感

505 :デフォルトの名無しさん:2009/11/16(月) 17:09:26
#define gcnew うんたらかんたら


506 :デフォルトの名無しさん:2009/11/16(月) 17:18:30
GCでストップとかGC作ってみればわかるよ。
回収しようとするから止まる。

507 :デフォルトの名無しさん:2009/11/16(月) 17:31:17
>>506
大方GCで予測困難な時間が発生するのは是か非かという議論だったと思うが…
誰も何故止まるかなんて話はしてない

あとスレチ

508 :デフォルトの名無しさん:2009/11/16(月) 18:17:23
みなさん誤解してますね。
GCというのはプログラム一つに一つとは限らないんですよね。
GCで管理されるオブジェクト上の資源を管理する別のGCがあってもいいし、
まったく無関係に独立のGCが複数あってもいい。
いくつでもありうるのです。
それならGCの時間を予測するのは簡単ですよね。

509 :デフォルトの名無しさん:2009/11/16(月) 21:12:35
なんで?
ただでさえ複雑なGCが複数動くなんて考えただけでも複雑すぎて恐ろしいんだけど

510 :デフォルトの名無しさん:2009/11/16(月) 21:27:58
複数GCが有っても他のGCのメモリを参照してたら、意味ないじゃん。回収時に全部止まるんじゃね?

511 :デフォルトの名無しさん:2009/11/16(月) 22:01:15
アセンブラ分からない奴が効率を語るとたまに頭おかしいこと言い出す、って話を思い出す

512 :デフォルトの名無しさん:2009/11/16(月) 22:07:37
参照カウンタならまだいいが、マーク&スイープが複数動いてたら死ねるな

513 :デフォルトの名無しさん:2009/11/16(月) 22:10:50
もっとメモリをください

514 :デフォルトの名無しさん:2009/11/16(月) 22:13:47
>>511
たまにじゃなくて頻繁に

515 :デフォルトの名無しさん:2009/11/16(月) 22:19:26
>>508はアセンブラどころかGCが何なのかすらよくわかってない
「プログラム一つに一つのGC」という頭の悪すぎる発言がその証拠

516 :デフォルトの名無しさん:2009/11/16(月) 22:24:28
ガベージコレクタと読み取るなら、その文自体は問題なくね
文章全体が言ってることはバカだけど

517 :デフォルトの名無しさん:2009/11/16(月) 22:38:25
そろそろGCを
あぼん した方が良さそうだな。

518 :デフォルトの名無しさん:2009/11/16(月) 23:40:30
時代はすでにWiiが主役だ。GCに用はない。

519 :デフォルトの名無しさん:2009/11/16(月) 23:43:20
急降下

520 :デフォルトの名無しさん:2009/11/17(火) 00:55:46
似たようなモンじゃねーか > Wii と GC


521 :デフォルトの名無しさん:2009/11/17(火) 03:23:37
GC(゚听)イラネ
デストラクタと関係ねーじゃん

522 :デフォルトの名無しさん:2009/11/17(火) 16:49:13
GCつかいたかったら、JavaやC#使えばいいじゃん。
C++を、これ以上、ブクブクに太らせてどうするのだ?

523 :デフォルトの名無しさん:2009/11/17(火) 18:29:50
>>522
太って困るのは実装する人。

524 :デフォルトの名無しさん:2009/11/17(火) 18:47:46
CPUの並列がどんどん進むので、
C++はもう未来はないな。
組み込み専用言語としての未来しかない。

525 :デフォルトの名無しさん:2009/11/17(火) 19:04:20
態々そんな事言いに来て
「尤もらしく意見する俺すげぇ」
とか思ってんのかしら

526 :デフォルトの名無しさん:2009/11/17(火) 19:10:18
>>522
というか今の実装でお前は満足しているのか?
そんな程度のお前にはTMPをお薦めしよう。

527 :デフォルトの名無しさん:2009/11/17(火) 19:15:45
TMPで生成したコードをコンパイルして実行ファイルが激重になってしまったが
動的型付けで書いたコードの方が実行ファイル軽くてしかも速度になんら問題ないというのは良くある話

528 :デフォルトの名無しさん:2009/11/17(火) 19:49:13
まぁ下手だとそうなって投げ出すのは良くある話だな

529 :デフォルトの名無しさん:2009/11/17(火) 19:51:07
wikipediaのTMPをみるとインライン展開とループアンローリングを
TMPの利点としてますが、C++がそうだといってるんですよね。
また世の中の全ての言語のTMPが同じようなものといいたいのでしょうね。
僕はそうは思わない。
C++のテンプレートはインライン展開をしないようにできない欠陥があるんだと思う。

530 :デフォルトの名無しさん:2009/11/17(火) 20:23:35
>>529
思う思わないはチラシの裏へどうぞ。

531 :デフォルトの名無しさん:2009/11/17(火) 20:24:34
ループアンロールなんてどうでもいいよ

532 :デフォルトの名無しさん:2009/11/17(火) 20:24:43
思う・思わないってのは論じゃねえしなあ
だからどうしたとしか言えんわな

533 :529:2009/11/17(火) 20:42:11
s/思/言/

534 :デフォルトの名無しさん:2009/11/17(火) 21:54:43
思うだけならタダ

535 :デフォルトの名無しさん:2009/11/18(水) 00:50:24
皆様に長らくご愛顧いただきました200x年代も、
残すところあと1ヶ月半となりました。

536 :デフォルトの名無しさん:2009/11/18(水) 01:08:56
意義あり。
21世紀は2001年から始まっているのだからして、
最初の10年には2010年の年末までが含まれるべきだ。

537 :デフォルトの名無しさん:2009/11/18(水) 01:20:45
意義?

異議だろ

出直して来い

538 :デフォルトの名無しさん:2009/11/18(水) 12:28:29
異議あり。
21世紀は2001年から始まっているのだからして、
最初の10年には2010年の年末までが含まれるべきだ。

539 :デフォルトの名無しさん:2009/11/18(水) 13:09:44
こ、こいつ…本当に出直して来やがった!

540 :デフォルトの名無しさん:2009/11/18(水) 13:15:29
現行C++でboostの実装見たりtemplate metaprogrammingで遊ぶのが趣味だったのに
0xの実装を落として自由と安息を手に入れて一気に生きる意味を見失った。

541 :デフォルトの名無しさん:2009/11/18(水) 17:52:58
右辺値参照やdecltypeを使って黒魔術を開発する作業しようぜ!

542 :デフォルトの名無しさん:2009/11/18(水) 18:08:35
C++はちょっとづつ言語を便利にするために
大勢のC++グルが10年づつ時間が必要だというところ。
これからの言語は基本的な小さな言語を定義して、
そのコードを生成する俺様言語の時代だろう。

543 :デフォルトの名無しさん:2009/11/18(水) 18:16:43
Domain Specific Languageのスレって立ってないの?

544 :デフォルトの名無しさん:2009/11/18(水) 20:40:25
「コンパイラ・スクリプトエンジン」相談室14
http://pc12.2ch.net/test/read.cgi/tech/1258431145/

545 :デフォルトの名無しさん:2009/11/18(水) 21:30:23
>>542
ただのLispじゃないか。

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

547 :デフォルトの名無しさん:2009/11/21(土) 23:52:40
参照って仮引数の話はおいといて、たとえば
 int foo = 1;
 using bar = foo;
とかでいい気がするんだけど、こういう文法だと何か面倒が起こるのかな?

548 :デフォルトの名無しさん:2009/11/22(日) 00:07:56
int foo = 1;
auto &bar = foo;

これに何か不満が?

549 :デフォルトの名無しさん:2009/11/22(日) 00:24:29
>>548
typdef代わりにusing使ってもよくなるし
multi-wayになること自体は別にいいのでは

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

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


550 :デフォルトの名無しさん:2009/11/22(日) 00:25:21
誤:unsined
正:unsigned

551 :デフォルトの名無しさん:2009/11/23(月) 07:44:03
混乱の元になるのに、そもそも、
なんでわざわざ既に別の意味で使われてる&に、
参照の意味を持たせたのだろうか?

552 :デフォルトの名無しさん:2009/11/23(月) 07:50:00
タイプコンストラクタと演算子は混同しえないから

553 :デフォルトの名無しさん:2009/11/23(月) 10:56:35
それで混乱するような奴はどっちにしろまともに使いこなせない言語だからいいんじゃね

554 :デフォルトの名無しさん:2009/11/23(月) 11:06:44
禿が考えてたのは、もともとこんな発想だろ
void a(int*);
a(&b);

void a(int&);
a(b);
つまりアドレス演算子を関数側でつけるってこと

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

555 :デフォルトの名無しさん:2009/11/23(月) 11:09:00
*だって別の意味に…

556 :デフォルトの名無しさん:2009/11/23(月) 11:12:27
別の意味を考えて赤面する美少女中学生

557 :デフォルトの名無しさん:2009/11/23(月) 11:30:45
いやいやそういう意味じゃないって!

558 :デフォルトの名無しさん:2009/11/23(月) 12:59:40
1つのキーワードに複数の意味を持たせるのはC++の悪い癖。

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

559 :デフォルトの名無しさん:2009/11/23(月) 13:05:44
使える記号は限られているわけで
無闇に記号使ったら
将来使える記号が無くなって困るんじゃない?

560 :デフォルトの名無しさん:2009/11/23(月) 13:10:13
禿「よし、次はUnicodeの絵文字領域を使うか」

561 :デフォルトの名無しさん:2009/11/23(月) 13:20:29
こんなんでややこしいと思う奴はC++どころかCの複雑な型宣言も扱えないだろうな

562 :デフォルトの名無しさん:2009/11/23(月) 13:31:40
そもそも参照の&って何のために必要だったの?
ポインタだけで何の不足もなかったのに何で付け足したの?
禿げってアホだったの?死ぬの?

563 :デフォルトの名無しさん:2009/11/23(月) 13:35:29
今頃そんな話がでてくるのかよ。

564 :デフォルトの名無しさん:2009/11/23(月) 13:35:51
参照無いと一時オブジェクトの扱いが悲惨なことに。

565 :デフォルトの名無しさん:2009/11/23(月) 13:43:18
Hoge operator+(Hoge *lhs, Hoge *rhs);
Hoge a,b,c;
c = &a+&b

とか書きたかった?

566 :デフォルトの名無しさん:2009/11/23(月) 13:48:43
>>559
記号じゃなくてもいいでしょ。
D言語は参照にrefっていうキーワード使ってる。
>>561
実際、C/C++は学習に時間がかかるでしょ。
わかりやすくて使いやすいに越したことはないと思うけど。

567 :デフォルトの名無しさん:2009/11/23(月) 13:51:12
過去の資産も上位互換も全く考えなくていいD言語をC++と同じ土俵に乗せるなと

568 :デフォルトの名無しさん:2009/11/23(月) 13:53:46
参照要らなかったんじゃないかと思ってる奴は、TMPどころかユーザー定義型すら
作るのに困りそうだが
「俺の理解できない物は実用的じゃないオモチャだ」の理論を使えば、心の平穏は
得られるんだろうけど

569 :デフォルトの名無しさん:2009/11/23(月) 13:53:48
しかし、同じ土俵で戦えない言語はすたれる。

570 :デフォルトの名無しさん:2009/11/23(月) 13:54:38
廃れるとしたらDの方だから問題無い

571 :デフォルトの名無しさん:2009/11/23(月) 13:58:22
ヌルい奴らは背伸びしてねーでスクリプト書いてるのがお互いの為だろ…

572 :デフォルトの名無しさん:2009/11/23(月) 13:59:35
初期にはキーワードを増やさない方針があったのだし
Cから参照の概念を抽出する過程ではC++もあんな感じにしかならんかった気がする。

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

573 :デフォルトの名無しさん:2009/11/23(月) 14:01:56
>>565
ポインタ渡しなら中身が書き換えられることが
呼ぶ側も呼ばれる側もソース見れば一目瞭然だった

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

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

574 :デフォルトの名無しさん:2009/11/23(月) 14:02:58
間違えた w

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

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




575 :デフォルトの名無しさん:2009/11/23(月) 14:03:36
>>573
その程度の初歩的な話はみんな見飽きてると思うよ

576 :デフォルトの名無しさん:2009/11/23(月) 14:05:57
元をただせばポインタ周りの文法がCでは「経済的」過ぎただけ。

577 :デフォルトの名無しさん:2009/11/23(月) 14:08:19
Cのポインタ周りの文法はごちゃごちゃだったので
それを整理しただけだと思えばいい >>573

578 :デフォルトの名無しさん:2009/11/23(月) 14:09:13
参照無かったらインライン関数どうすんの

579 :デフォルトの名無しさん:2009/11/23(月) 14:10:05
インライン関数無かったらクラス定義どうすんの

580 :デフォルトの名無しさん:2009/11/23(月) 14:10:46
もちろんマクロで書くさ!

581 :デフォルトの名無しさん:2009/11/23(月) 14:11:46
>>568
いや
それはない

582 :デフォルトの名無しさん:2009/11/23(月) 14:15:02
C++らしく書くには参照は必須だろう
それが分からんならCに帰った方が幸せになれる

583 :デフォルトの名無しさん:2009/11/23(月) 14:44:30
ただの参照でさえこうなるのに
右辺値参照とか見たら発狂するんじゃないのか

584 :デフォルトの名無しさん:2009/11/23(月) 14:44:57
>>567
D言語の例は>>559の「記号は有限」に対する反論のつもりで出した。
C++がD言語のように仕様変更できないのは御尤も。
>>572
確かにC/C++の結果があるから言える事ではある。

585 :デフォルトの名無しさん:2009/11/23(月) 14:46:53
>>583
それで発狂するくらいなら、他の言語でも結局発狂すると思う。

586 :デフォルトの名無しさん:2009/11/23(月) 21:29:46
参照は初学者のために追加されたってD&Eに書いてたような

587 :デフォルトの名無しさん:2009/11/23(月) 21:33:07
まず自分の本棚へ行き、本を開いて、該当個所を見つけてから書こうね。

588 :デフォルトの名無しさん:2009/11/23(月) 23:00:43
参照のせいで、最後までソースを追っかけないと、
変数の値が変えられてるのかどうだか分からなくなった。

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

589 :デフォルトの名無しさん:2009/11/23(月) 23:06:01
普通はconst参照か否かで終わるだろ。

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

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


590 :デフォルトの名無しさん:2009/11/23(月) 23:07:57
589は何も分かってないな

591 :デフォルトの名無しさん:2009/11/23(月) 23:10:51
>>588
いや、何を言っているのか。

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

592 :デフォルトの名無しさん:2009/11/23(月) 23:28:14
&の有無を目視で確認するよりか、書き換えてほしくないパラメータはconst変数/参照でもちなおして関数に渡した方が確実だと思う。
&は変数書き換えの目印というけど、int const*とかどうするんだろ。コーディング規約で禁止?

593 :デフォルトの名無しさん:2009/11/23(月) 23:32:55
多分 >>588
参照なしなら

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

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

void f(int& x);

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

594 :デフォルトの名無しさん:2009/11/23(月) 23:33:34
C++の場合、結果的な仕様が好きか嫌いかはともかく、
議論の有無だけでいえば、死ぬほど議論した上でそうなった仕様が殆ど。

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

595 :デフォルトの名無しさん:2009/11/23(月) 23:34:49
>>594
> 議論の有無だけでいえば、死ぬほど議論した上でそうなった仕様が殆ど。
同意。
わからんやつはこのC++0xの標準化委員会のごたごたを見てみろ!

596 :デフォルトの名無しさん:2009/11/23(月) 23:37:30
つーか既に現実にあるC++を受け入れられないのか知らんが
C++0xスレで文句を言ってもだな、……と思う

597 :デフォルトの名無しさん:2009/11/23(月) 23:41:46
&どころか、&&とか出てきて、
誰も保守できなくなりそうな勢いだから、怖いのだよ

598 :デフォルトの名無しさん:2009/11/23(月) 23:43:00
rvalue referenceの何が難しいっていうんだよ?

599 :デフォルトの名無しさん:2009/11/23(月) 23:44:09
大勢でよく議論されて、よく考えられたからと言って、良いものになるとは限らないと。
その主な例がC++とUnicode。

600 :デフォルトの名無しさん:2009/11/23(月) 23:46:14
>>591
>const参照ならオブジェクトは変更されていないだろ?

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

601 :デフォルトの名無しさん:2009/11/23(月) 23:46:27
良くないってわかってるんなら
じゃあ文句ばかり言ってても始まらんだろ

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

603 :デフォルトの名無しさん:2009/11/23(月) 23:49:57
>>596
> 既に現実にあるC++

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

604 :デフォルトの名無しさん:2009/11/23(月) 23:50:09
むしろ尖端恐怖症とか潔癖症(不潔恐怖症)のにおいがするんだが。

605 :デフォルトの名無しさん:2009/11/23(月) 23:51:21
>>603
こんな所でか? 冗談キツイっすw

606 :デフォルトの名無しさん:2009/11/23(月) 23:51:27
もっとも、俺自身も諸般の事情から思うところを出し切っているわけでもないけどね

607 :デフォルトの名無しさん:2009/11/23(月) 23:59:06
もうここまで来たら、ハゲが強権発動して、
適当に決めてしまって来年中にC++0Aを出せばいい。

608 :デフォルトの名無しさん:2009/11/23(月) 23:59:38
>>603
まだその位置にすら日本はたってないだろ。
時代錯誤というレベルだぜ。

609 :デフォルトの名無しさん:2009/11/24(火) 00:01:44
>>608
そう思うなら黙ってれば?

610 :デフォルトの名無しさん:2009/11/24(火) 00:02:00
>>607
その結果がexportだと思う。

611 :デフォルトの名無しさん:2009/11/24(火) 00:19:40
思う思わないだの、いい加減なことをいくら書いても議論にならんよ。

612 :デフォルトの名無しさん:2009/11/24(火) 00:20:20
なんてレベルの低いスレだ。

613 :デフォルトの名無しさん:2009/11/24(火) 00:31:10
C++0xに関係ない話題が出たときだけ伸びるスレだな

614 :デフォルトの名無しさん:2009/11/24(火) 00:33:53
基本的に英語が読めないから、今現在、
C++0xがどうなってるかなんて、分かりようもない。

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

615 :デフォルトの名無しさん:2009/11/24(火) 00:39:08
unkosure

616 :デフォルトの名無しさん:2009/11/24(火) 00:41:04
あなたの意見なんて聞いてませんよ

617 :デフォルトの名無しさん:2009/11/24(火) 00:41:04
C++にしてもUnicodeにしても、
確かにゴテゴテしているが、
積み重ねられた議論、
公開された提案は宝の山だぜ。

>>455
これは好きだ。

618 :デフォルトの名無しさん:2009/11/24(火) 02:48:40
>>602に禿しく同意

619 :デフォルトの名無しさん:2009/11/25(水) 06:00:10
プ
バッドノウハウ言語あげ

620 :デフォルトの名無しさん:2009/11/25(水) 07:04:52
むしろ何でもやろうという観点で考えるとできない事はできないと割り切っている言語よりはマシなのでは。

621 :デフォルトの名無しさん:2009/11/25(水) 07:30:01
なんでもしようとして、制限や出来ないことが増えてるけど。

622 :デフォルトの名無しさん:2009/11/25(水) 07:33:40
非合理的なことができなくなってるな。

623 :デフォルトの名無しさん:2009/11/25(水) 07:37:29
バグも合理的なのか。

624 :デフォルトの名無しさん:2009/11/25(水) 07:41:03
>>623
中学生にはわからない会話だから入ってきちゃ駄目。

625 :デフォルトの名無しさん:2009/11/25(水) 07:44:24
自分は分かってるつもりが一番痛いな。

626 :デフォルトの名無しさん:2009/11/25(水) 07:47:02
中学生って言われて中学生ならでは返しをしたらドツボですよ。

627 :デフォルトの名無しさん:2009/11/25(水) 07:51:05
自分に返されたと思った自意識過剰が一人。

628 :デフォルトの名無しさん:2009/11/25(水) 07:58:40
^q^

629 :デフォルトの名無しさん:2009/11/25(水) 07:58:44
ホントに青いなぁ、返しが。

630 :デフォルトの名無しさん:2009/11/25(水) 08:01:49
分かると言えるのはコンパイラ書いた人だけだな
それ以外はただの脳内

631 :デフォルトの名無しさん:2009/11/25(水) 12:12:20
コンパイラ書いてても信じられないくらい分かってない人もいるけどな…
実装面からの都合だけギャーギャー並べ立ててる奴

632 :デフォルトの名無しさん:2009/11/25(水) 21:05:12
C、C++は、コンパイラの実装が簡単になることも
言語仕様の設計コンセプトの一つだから、
他の言語ほど使う人最優先で言語仕様を決める
ってワケにはいかないのじゃね?

633 :デフォルトの名無しさん:2009/11/25(水) 21:09:08
最初から実装が簡単になるように作ってれば、
今みたいなことにはなっていなかっただろう

634 :デフォルトの名無しさん:2009/11/25(水) 21:52:38
後知恵なら何とでも言えるな
C++の前にC++無しだ

635 :デフォルトの名無しさん:2009/11/25(水) 22:30:57
自分の墓石にC++のコードを彫ってしまうんだろうね、あんた。
残念ながらC++はもう終わりです。
これからは俺言語の時代。

636 :デフォルトの名無しさん:2009/11/25(水) 22:40:04
じゃ俺言語としてC++を使おうじゃないか

637 :デフォルトの名無しさん:2009/11/25(水) 22:58:31
もうしばらくすると俺言語全盛の時代を迎える。
そのときあんたは俺言語の非常にコンパクトなバックエンド言語の
コンパイラをセコセコ作ってるだろう。

638 :デフォルトの名無しさん:2009/11/25(水) 23:05:30
俺言語とはつまりマーケティング指向言語だな

639 :デフォルトの名無しさん:2009/11/26(木) 08:42:31
別に汎用言語と俺言語を排他的に扱う必要はないと思うんだが

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

641 :デフォルトの名無しさん:2009/11/26(木) 10:52:41
スレ違い

642 :デフォルトの名無しさん:2009/11/26(木) 10:53:22
>>632
>コンパイラの実装が簡単になることも
C はそれで普及したけども、C++ はなあ…

643 :デフォルトの名無しさん:2009/11/26(木) 11:45:26
俺ストーリーを語る人ばっか

644 :デフォルトの名無しさん:2009/11/26(木) 12:01:56
>>643
池沼が1人か2人くらい暴れてるだけで
あとはいつもどおりの過疎スレです

645 :デフォルトの名無しさん:2009/11/26(木) 12:31:59
>>644
おまえら本当に哀れだな。C++0xの成功は無いよ。
COBOLプログラマがコボラーと呼ばれ散々バカにされ蔑まれただろ。
今度はC++プログラマはプラプラーと呼ばれてコボラーの末路をなぞるんだよ。

646 :デフォルトの名無しさん:2009/11/26(木) 12:36:20
必要悪だから使ってあげてるだけなんだからね!
勘違いしないでよね!

647 :デフォルトの名無しさん:2009/11/26(木) 12:36:52
根拠なき自信漲る荒らしかな

648 :デフォルトの名無しさん:2009/11/26(木) 12:39:20
俺以外みんなバカだし哀れだぜ

649 :デフォルトの名無しさん:2009/11/26(木) 12:43:25
>>645
スレ違い、板違いの話題はご遠慮ください。

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

650 :デフォルトの名無しさん:2009/11/26(木) 14:47:54
俺言語にC++っぽい構文移植するんだよ

651 :デフォルトの名無しさん:2009/11/26(木) 15:05:09
>>646
ツンデレ美少女中学生だ!

652 :デフォルトの名無しさん:2009/11/26(木) 15:05:48
むしろこのスレが禿板に立つべき

653 :デフォルトの名無しさん:2009/11/26(木) 16:39:51
>>651
なんで中学生なんだよ

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

654 :デフォルトの名無しさん:2009/11/26(木) 16:54:20
見苦しいからそういう事書き込むのやめた方がいいよ

655 :デフォルトの名無しさん:2009/11/26(木) 18:07:04
まあ、実務者不在の言語仕様なんて、
お経みたいなもんだ。

656 :デフォルトの名無しさん:2009/11/26(木) 18:18:07
> お経みたいなもんだ。
禿に掛けたのですね、わかります

657 :デフォルトの名無しさん:2009/11/26(木) 21:06:24
コンセプト無くなったしexportもD行きになるし
実装困難な所ってもうそんなにないんじゃないの

658 :デフォルトの名無しさん:2009/11/26(木) 21:53:24
ed使いというかedなんだろ
治療できますからあきらめないでくだしあ

659 :デフォルトの名無しさん:2009/11/26(木) 22:01:39
今exportバリバリでソース書いてる俺としては書き直さないと将来はないってこと?

660 :デフォルトの名無しさん:2009/11/26(木) 22:55:20
>>659
exportばりばりって・・・
どのコンパイラ使ってるの?Comeau?

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

661 :659:2009/11/26(木) 23:06:43
exportを使いたいからComeauを買った
色々面白い

662 :660:2009/11/26(木) 23:16:06
>>661
やっぱComeauか。
俺も買おうかなぁ。勉強になるだろうし。

663 :デフォルトの名無しさん:2009/11/27(金) 02:21:42
なんやかんや言ってもC++がプログラムの世界の
最高峰だろ?

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

664 :デフォルトの名無しさん:2009/11/27(金) 02:36:59
なこたない。適材適所

665 :デフォルトの名無しさん:2009/11/27(金) 02:56:32
素早いコーディングが大事な時はスクリプト言語
普通のアプリを真面目に書く時はC++
組み込みかそれに近い時はCやアセンブラ

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

666 :デフォルトの名無しさん:2009/11/27(金) 03:27:13
仕事の受注開発でC++なんて、怖くて使えんな。
開発には向かない言語じゃね?

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

667 :デフォルトの名無しさん:2009/11/27(金) 03:29:21
お前の使っているブラウザもC++で書かれているんだが

668 :デフォルトの名無しさん:2009/11/27(金) 03:48:23
俺のはCだよ

669 :デフォルトの名無しさん:2009/11/27(金) 09:03:09
時代の流れ的にアプリはそろそろC#
以前からjavaを使ってるところは変わらずjava
vbを使ってたところはvb.net

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

670 :デフォルトの名無しさん:2009/11/27(金) 10:42:27
C++で書くのが怖いってのは理解できてないから。
理解できないのは言語のせいでもあるしお前のせいでもある。
どっちにしろ理解できてる奴には関係ない話。

671 :デフォルトの名無しさん:2009/11/27(金) 11:32:33
コンシューマゲーム屋としては、今んとこC++しかないからなあ
そりゃツールとかではスクリプトも使うけどさ

672 :デフォルトの名無しさん:2009/11/27(金) 11:47:03
goで作れ

673 :デフォルトの名無しさん:2009/11/27(金) 11:54:06
WG21のpapersも読んだことない人はお断りのスレですよ

674 :デフォルトの名無しさん:2009/11/27(金) 13:20:02
>>670
仕事で作る場合は、スキルが上から下まで
いろいろなヤツが居て、チームで作るからな。
大きなプロジェクトになればなるほど。

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

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

675 :デフォルトの名無しさん:2009/11/27(金) 13:35:19
自分または身内で地雷踏んだからって、全ての企業の話に一般化されても困る
企業でもスキルの高い奴が集まってるとこは普通にあるしな

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

676 :デフォルトの名無しさん:2009/11/27(金) 13:39:54
マ業界は本当にピンキリだからなぁw

677 :デフォルトの名無しさん:2009/11/27(金) 13:43:53
で、結局、C++0A(仮)では、「理解できないなら使うな」度は、
パワーアップするのか?緩和されるのか?

678 :デフォルトの名無しさん:2009/11/27(金) 13:45:18
自分で判断できないとはね

679 :デフォルトの名無しさん:2009/11/27(金) 13:58:24
判断できないなら使うな

680 :デフォルトの名無しさん:2009/11/27(金) 14:06:28
慣れた時の安全性や効率性は上がるだろうが、C++の採用自体が困難な組織だったら
0xになっても同様に困難だろう
まぁ、中級者向けのトラップみたいなのは減るんじゃね?

681 :デフォルトの名無しさん:2009/11/27(金) 14:22:24
C++なんて使っていないという会社は多いぞ。

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

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

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

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

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

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

682 :デフォルトの名無しさん:2009/11/27(金) 14:24:31
辻演説はそこまでの方向で

683 :デフォルトの名無しさん:2009/11/27(金) 14:38:26
>>672
Goってウインドウツールキットってある??

684 :デフォルトの名無しさん:2009/11/27(金) 14:38:34
バカな社員のほうがまだマシだよな。
自称C++の達人とか邪魔どころか痛い。

685 :デフォルトの名無しさん:2009/11/27(金) 15:00:05
土方向けの仕事は土方がやった方がいいのは事実だな

686 :デフォルトの名無しさん:2009/11/27(金) 15:13:00
プログラマーにとって言語は目的ではなく手段だよね。
より生産効率の高い言語があったらそれを使いたいと思うでしょ。達人か素人か関係なく。

687 :デフォルトの名無しさん:2009/11/27(金) 15:23:31
でかい売り物の GUI ソフトって C++ だと思うんだが、たいてい。
あと、メジャーなオープンソースでは WebKit とか Qt は C++ だよね

688 :デフォルトの名無しさん:2009/11/27(金) 15:25:53
オープンソースは趣味で生まれる実用品だからね
付いてこられない開発者に悩まされる心配も全く無いし

689 :デフォルトの名無しさん:2009/11/27(金) 15:44:38
クローズドソースでもC++使ってるって

690 :デフォルトの名無しさん:2009/11/27(金) 15:58:23
>>681
>Embedded C++さえ
なんで「紗江」なのか知らんが、好き好んであんな糞使う人もあんまりいないだろう。
(よく解んない人が採用決めちゃうと渋々使うしかないかも知れんが)

691 :デフォルトの名無しさん:2009/11/27(金) 15:58:55
×紗江
○さえ

692 :デフォルトの名無しさん:2009/11/27(金) 16:03:34
Embedded C++は死んだ。
消えたのではない、死んだ。

693 :デフォルトの名無しさん:2009/11/27(金) 16:45:09
C++はCのオブジェクト指向拡張だってことだよ。
組み込みのガーベジコレクションのない
オブジェクト指向言語はいくらでもあるんだから。

694 :デフォルトの名無しさん:2009/11/27(金) 16:57:11
Embedded C++ってまだnamespace無いの?
正直templateよりも仮想関数よりも、namespaceが一番大事と思うんだが。

695 :デフォルトの名無しさん:2009/11/27(金) 17:43:16
だいたいEmbedded C++って日本のCPUベンダーの泣き言の産物だろ
誰が使うか

696 :デフォルトの名無しさん:2009/11/27(金) 17:56:51
C++を簡略化したサブセットを作ろうという発想自体は悪くなかったと思うんだ
問題は出来た物がサブセットになってなかったことだ

697 :デフォルトの名無しさん:2009/11/27(金) 17:58:55
誰かSabusetto C++作れ
SubsetじゃなくてSabusettoなのは馬鹿専用の印な。

698 :デフォルトの名無しさん:2009/11/27(金) 18:40:25
実際のC++プログラマは自分のサブセットでプログラムしてるしな。

699 :デフォルトの名無しさん:2009/11/28(土) 01:02:20
そして相変わらずC++0xの話題は出ないこのスレ

700 :デフォルトの名無しさん:2009/11/28(土) 03:21:38
VC2010でtemplate<class T, T N> struct ...ってできるけどこれって独自拡張?

701 :デフォルトの名無しさん:2009/11/28(土) 10:00:50
え、今まで普通に使ってきたんだがMSの独自拡張だったんか・・・orz

702 :デフォルトの名無しさん:2009/11/28(土) 10:03:15
>>701
まて、それだと
そのソースはWindows以外では使えないソースってことか?

・・・まあそう気を落とすな。

703 :デフォルトの名無しさん:2009/11/28(土) 10:14:16
T が何型かわかるまで保留でいいと思うが・・・

704 :デフォルトの名無しさん:2009/11/28(土) 10:45:29
>>700
違うと思う。boostでも使われてるし。
http://www.boost.org/doc/libs/1_41_0/boost/non_type.hpp

705 :デフォルトの名無しさん:2009/11/28(土) 10:59:20
>>704
その
template <typename T, T n>
struct non_type { };
って何に使うんでしょうか?


706 :デフォルトの名無しさん:2009/11/28(土) 11:26:12
組み込みで良く使われたQtとかSymbianとかがC++だけどどっちもオープンソース。
というか下位レイヤがクローズドソースのC++だと死ねる。仕様書もUMLも隠し、ドキュメントも不十分とか止めれ本当。

707 :デフォルトの名無しさん:2009/11/28(土) 11:29:19
>>706
いきなり何の話をし始めるw


708 :デフォルトの名無しさん:2009/11/28(土) 17:50:17
何で、Embedded C++にしつこく反応する。馬鹿か

709 :デフォルトの名無しさん:2009/11/28(土) 18:08:15
shadow replying?

710 :デフォルトの名無しさん:2009/11/28(土) 18:56:00
C++0xがなんのことか知らなくて、ただのC++スレと勘違いして来てる奴がいそうな気がする。

711 :デフォルトの名無しさん:2009/11/28(土) 21:30:38
>>710
このスレをC++ 0x7と思ってるとかな


712 :デフォルトの名無しさん:2009/11/28(土) 21:39:45
【次期規格】とか付けた方がいいのかねえ

713 :デフォルトの名無しさん:2009/11/28(土) 21:52:33
C++プログラマならC++0xの存在は常識だと
思っていたのだが、そうでもなかったりするのか?

714 :デフォルトの名無しさん:2009/11/29(日) 00:18:35
C++の次期機能の存在どころか…

715 :デフォルトの名無しさん:2009/11/29(日) 00:29:21
ピンからキリまでいますからね

716 :デフォルトの名無しさん:2009/11/29(日) 01:11:20
HTML5スレでも同じような話を見たなあ。
次期規格「HTML5」のスレなのに、HTMLスレのパート5と認識している奴がいるのでは?という話。

717 :デフォルトの名無しさん:2009/11/29(日) 01:12:31
正式決定までドライでいたいし、そうあるべきだとも思う
戦いはそれから

次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている
スーパーセットの皮を被った本当はサブセット
へたするとテンプレートと C++ コアで機能拡大しながらその実簡素化という舵を切ってくれることを期待してる

テンプレート型のテンプレート引数で柔軟性を飛躍的に向上させた列概念を待っている

718 :デフォルトの名無しさん:2009/11/29(日) 01:19:21
俺が会社でC++0xの話題を振ったところ意味がわかるのは20人中2人だった

719 :デフォルトの名無しさん:2009/11/29(日) 02:53:55
>>700,701
遅レスだけどC++標準の仕様だよ。もちろん0x以前でも。

boost::non_type は何に使うのかようわからんけど、
boost::mpl::integral_c<T, N> で型として扱える定数をつくったりとか。


720 :デフォルトの名無しさん:2009/11/29(日) 03:10:19
来年になったら、C++1xって呼ぶの?

721 :デフォルトの名無しさん:2009/11/29(日) 03:12:44
来年限定で C++x0 (嘘)

722 :デフォルトの名無しさん:2009/11/29(日) 04:39:41
Cは最初からC1xって呼んでるんだよな。

723 :デフォルトの名無しさん:2009/11/29(日) 05:16:29
それは標準化委員会のやる気がないから

724 :デフォルトの名無しさん:2009/11/29(日) 08:09:35
来年だったら C++0A だから 0xでおk

725 :デフォルトの名無しさん:2009/11/29(日) 08:11:17
だからそれは8進数リテラルだと……

726 :デフォルトの名無しさん:2009/11/29(日) 08:39:29
C++0Z の次は C++0a ですね

727 :デフォルトの名無しさん:2009/11/29(日) 09:04:56
>>726
そのうちコインやら王冠が出てきそうだな

728 :デフォルトの名無しさん:2009/11/29(日) 10:10:42
>>727
それ何て マr ・・・ うわなにをするやめ

729 :デフォルトの名無しさん:2009/11/29(日) 12:54:23
>>717
> 次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている

ドラフト読めよw

730 :デフォルトの名無しさん:2009/11/29(日) 13:05:15
Wikipedia の仏語版だけ項目の見出しが C++1x という表記になってる。

731 :デフォルトの名無しさん:2009/11/29(日) 13:21:35
エスプリってやつなんですね。

732 :デフォルトの名無しさん:2009/11/29(日) 13:46:59
>>726
base64 だけであと 54年持つなw

733 :デフォルトの名無しさん:2009/11/29(日) 14:09:18
64進数リテラルか。

734 :デフォルトの名無しさん:2009/11/29(日) 20:58:40
base64だと0xは3377年。
範囲ではなく具体的な制定年を指定ということでは?

735 :デフォルトの名無しさん:2009/11/29(日) 21:06:22
>>734
そうなのか!それなら今のペースでも余裕で間に合うな!


736 :デフォルトの名無しさん:2009/11/29(日) 21:35:13
人類滅んでそうw

737 :734:2009/11/29(日) 21:41:54
間違えたよ。リトルエンディアンで4307年、ビッグエンディアンで54032年

738 :デフォルトの名無しさん:2009/11/29(日) 21:57:45
年号じゃなくてバージョン番号で命名すれば
何の問題ないのに、みんなバカなのか?

739 :デフォルトの名無しさん:2009/11/29(日) 22:23:32
>>738
ドキュメントのバージョンが細かく上がってくからそういう風になったんでない?
ここで切りましょう。的な。

740 :デフォルトの名無しさん:2009/11/29(日) 22:50:03
>>738
C++0xで何か問題でも起こりますか?

741 :デフォルトの名無しさん:2009/11/29(日) 23:06:13
>>740
2100年問題が起きるだろ……

742 :デフォルトの名無しさん:2009/11/29(日) 23:12:30
ハッシュで名前つければかぶらないよ。


743 :デフォルトの名無しさん:2009/11/30(月) 11:07:46
ゴムを被せれば、ですね。わかります

744 :デフォルトの名無しさん:2009/11/30(月) 11:15:06
そろそろマヤ歴を解読してC++0xが完成する日時を割り出す人とか出てきそう。

745 :デフォルトの名無しさん:2009/11/30(月) 16:11:37
久々にC++0xの話題が続いてるな!

746 :デフォルトの名無しさん:2009/11/30(月) 17:24:54
constexprで算出した値ってtemplate引数に渡せられる?

747 :デフォルトの名無しさん:2009/11/30(月) 17:26:36
>>746
それが constexpr の目的の一つ。

748 :デフォルトの名無しさん:2009/11/30(月) 18:11:34
>>745
気のせいだろ。

749 :デフォルトの名無しさん:2009/11/30(月) 21:09:01
やっとnumeric_limits::maxが静的になるんですね!

750 :デフォルトの名無しさん:2009/11/30(月) 21:18:20
つ boost::integer_traits::const_max

751 :デフォルトの名無しさん:2009/12/07(月) 13:53:42
template<bool cond, typename A, typename B>
using static_if = typename boost::mpl::if_c<cond, A, B>::type;

template aliasを使えばメタ関数の定義が楽になって呼び出す時も
typenameとか::typeを書かなくて済むと思うんだけどあってる?

752 :デフォルトの名無しさん:2009/12/07(月) 14:51:44
あってる。
どうでもいいがVC10betaは本当に0xの役に立つ機能だけごっそり実装されてなくて悲しくなってくるな。

753 :デフォルトの名無しさん:2009/12/07(月) 20:49:44
VC10はauto、lambda、右辺値参照がサポートされているだけでも嬉しい。
VC9はスルーしていまだにVC8だけど、VC10は買うよ。

754 :デフォルトの名無しさん:2009/12/07(月) 20:57:41
VC10はdecltypeがないんだっけ

755 :デフォルトの名無しさん:2009/12/07(月) 21:23:02
beta2使ってるが既にあrう

756 :デフォルトの名無しさん:2009/12/07(月) 22:41:41
decltype(*this)ってやると落ちるけどな

757 :デフォルトの名無しさん:2009/12/08(火) 13:37:33
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 について2回発生する副作用がお互いに sequenced となれば
いいようですが、式中の2つの関数呼び出し内にある副作用についての
sequencing がどうなるのか、よくわかりませんでした。上記の記述に続く
"When calling a function ..." で説明されている気配はあるのですが。

「元々結果が定まらなかったんだから、こっそり未定義に格下げしたって
 だれも困りゃしねーよ。」
とかいう話になってたりしないか心配です。

758 :デフォルトの名無しさん:2009/12/08(火) 19:03:10
>>757
今までもこれからも、処理系定義だと
思ってたけど、違うの?


759 :デフォルトの名無しさん:2009/12/08(火) 21:06:19
>>757
質問なのですが、標準C++ 2003において、
 static int x;
 (++x)+(++x)
これは未定義の動作ですよね?
ところが
 int f() { static int x; return ++x; }
 f() + f()

 > 関数呼び出しに伴うシーケンスポイントがあるので
不定の動作になるということでしょうか?
(つまり一応動作はするということでしょうか?)


760 :デフォルトの名無しさん:2009/12/08(火) 22:35:49
>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.

761 :デフォルトの名無しさん:2009/12/08(火) 23:03:53
>>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() とか

762 :デフォルトの名無しさん:2009/12/08(火) 23:19:40
>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 なので制約が緩くなってると考えてもいいんじゃないかな。

763 :759:2009/12/08(火) 23:24:11
>>761
おっしゃるとおり、
前値と後置を間違えていたようです。
(++x)+(++x)の結果はいつも同じになるのですね。

>(x++)+(x++) ならコンパイラ依存だけど
こちらは未定義の動作ということでよろしいでしょうか?


764 :デフォルトの名無しさん:2009/12/08(火) 23:34:02
>761
「コンパイラ依存」は implementation defined か undefined behaviour かどっちの意味で言ってる?
sequence point 間で 2 回値を変更しているから (++x)+(++x) はやっぱり undefined behavior じゃないの?

n3000 だとこんな例もあるよ?
f(i = -1, i = -1); // the behavior is undefined

特に↑の新しいルールだと実行がオーバーラップしうるからなおさら undefined behavior を示唆する気もする。

765 :デフォルトの名無しさん:2009/12/08(火) 23:51:25
俺も
(++x)+(++x)はundefined behaviorだったと思うんだけど。

> f(i = -1, i = -1); // the behavior is undefined
は知らなかった。ありがとう。

やっぱC/C++言語って難しい。


766 :761:2009/12/09(水) 00:32:29
>>764
ごめん、嘘つきだった. おっしゃるとおり、2回変更してるからアウトです
へんにまぜっかえしてしまってもうしわけない

767 :デフォルトの名無しさん:2009/12/09(水) 00:52:32
>>761
(++x)+(++x)も未定義。
「どちらから評価するか」が決まっていないのではないよ。

768 :757:2009/12/09(水) 01:40:13
>>762
> 一方、他に特に明示されていない場合は、関数の実行と(呼び出し側の)その他の評価との間は indeterminately sequenced

片方の f() が呼び出された際の ++x と、その外にあるもう一方の f() 呼び出しとの
関係を見れば indeterminately sequenced になるということですね。

片方の f() ともう一方の f() とが unsequenced なので、それぞれの中にある2つの
++x について見ても unsequenced になるんじゃ・・・と思ってましたが、従来どおりという
ことで安心しました。ありがとうございました。

769 :デフォルトの名無しさん:2009/12/10(木) 00:28:10
そんなコード書くなと思うのは俺だけか?

770 :デフォルトの名無しさん:2009/12/10(木) 10:21:12
auto_ptrはこういう文法にすべき。
classA * auto ptr = classA(1, 2, 3);

771 :デフォルトの名無しさん:2009/12/10(木) 16:29:14
一種類しかスマポ使えない世界ですか

772 :デフォルトの名無しさん:2009/12/10(木) 16:34:07
梶本裕介ってだれ?

773 :デフォルトの名無しさん:2009/12/10(木) 16:47:25
長門かわいい

774 :デフォルトの名無しさん:2009/12/10(木) 16:47:55
意味不明

775 :デフォルトの名無しさん:2009/12/10(木) 16:58:26
エピステーメーみたいな痛さがあるよねw

776 :デフォルトの名無しさん:2009/12/10(木) 17:12:13
馬鹿に嫌われるタイプの人ってこと?

777 :デフォルトの名無しさん:2009/12/10(木) 17:20:50
ちょっとマ板にスレたててくるわ

778 :デフォルトの名無しさん:2009/12/10(木) 17:23:03
スーパープログラマー 梶本裕介
http://pc11.2ch.net/test/read.cgi/prog/1260433369/

779 :デフォルトの名無しさん:2009/12/12(土) 19:08:07
>>770
それはどんな動作を期待しとるん?
コピーなん?参照なん?


780 :770:2009/12/12(土) 19:51:30
classA * auto ptr = new classA(1, 2, 3);
newを忘れてた。

781 :デフォルトの名無しさん:2009/12/12(土) 20:12:13
型修飾子をオーバーロードするとカオスになるから

782 :デフォルトの名無しさん:2009/12/12(土) 20:52:40
文法を変えずに、スマポが実装できるのがC++のいい所なのになあ。


783 :デフォルトの名無しさん:2009/12/12(土) 23:26:13
生ポインタもライブラリにすべき。
ptr<int> p(new int(0));

784 :デフォルトの名無しさん:2009/12/12(土) 23:59:39
むしろ * 演算子を無くして、全部 ptr<T> にすべきだと思う

785 :デフォルトの名無しさん:2009/12/13(日) 00:02:17
const ref<array<ptr<int> > > a;

786 :デフォルトの名無しさん:2009/12/13(日) 00:59:12
ここで1引数の場合は<>を省略できるルールを……

787 :デフォルトの名無しさん:2009/12/13(日) 06:06:06
むしろこうなる悪寒。ドツボ
const std::ref<std::array<std::ptr<int> > > a;

788 :デフォルトの名無しさん:2009/12/13(日) 06:27:24
Template typedefs あるし

789 :デフォルトの名無しさん:2009/12/13(日) 06:41:34
何でみんな array に要素数を書かないの?

790 :デフォルトの名無しさん:2009/12/13(日) 07:22:14
配列の要素数が10以下なら
要素数を省略できるんだよ

791 :デフォルトの名無しさん:2009/12/13(日) 09:00:42
別にtemplate <typename T> class ptrを定義したっていいんだぞ
あと>>770は論外っつーかスマポをガチで使ったことねーだろ

792 :770:2009/12/13(日) 09:29:58
コンパイラにとっては* autoくらいなんでもないくらい簡単だよ。

793 :デフォルトの名無しさん:2009/12/13(日) 09:48:45
子供は外で遊んでなさい

794 :デフォルトの名無しさん:2009/12/13(日) 10:47:05
お前はintrusive_ptrみたいなのやweak_ptrみたいなのが欲しい時にどうするつもりなんだよ

795 :デフォルトの名無しさん:2009/12/13(日) 10:50:54
だだをこねる

796 :デフォルトの名無しさん:2009/12/13(日) 10:54:02
ユーザー定義リテラル(だっけ?)が 0x では出来るんだから、
ユーザー定義ポインタが出来てもいいんでは。
T * hogehoge を hogehoge_ptr<T> に変換とか。

797 :デフォルトの名無しさん:2009/12/13(日) 10:56:21
アホは発言を控えて!

798 :デフォルトの名無しさん:2009/12/13(日) 11:01:59
>>797がいいこと言ったw

799 :デフォルトの名無しさん:2009/12/13(日) 11:03:13
バカは自分のつまらない思い付きに興奮して固執するから困る

800 :デフォルトの名無しさん:2009/12/13(日) 11:05:15
ユーザー定義リテラルさんは
>>6
で酷評されているw

801 :デフォルトの名無しさん:2009/12/13(日) 11:06:12
まぁ、間違ったアイディアに囚われることは誰でもある
それに気付いて軌道修正できない奴は駄目だが

802 :デフォルトの名無しさん:2009/12/13(日) 11:25:49
>>800
registerさんのイメチェンは何が良い?


803 :デフォルトの名無しさん:2009/12/13(日) 12:12:11
registerさんはなんか将来もっと役立ちそうなところで使われるべき。

・・・それが何かはまだ思いつかないけどねw


804 :デフォルトの名無しさん:2009/12/13(日) 12:24:09
autoさんってどんなところで出て来るんですか??

805 :デフォルトの名無しさん:2009/12/13(日) 12:44:59
ラムダ式扱うときにとか使うかもしれない
自分はラムダ式自体使ったことないけどね

806 :804:2009/12/13(日) 12:48:36
>>805
Boostのラムダとは全然別物っていう代物ですよね確か。

・・・仕様が確定してから勉強しようと思います。


807 :デフォルトの名無しさん:2009/12/13(日) 13:42:34
C++は複雑過ぎるから俺言語を作っちゃった方が速い。

808 :デフォルトの名無しさん:2009/12/13(日) 13:48:31
何が何より速いんだよ

809 :デフォルトの名無しさん:2009/12/13(日) 14:32:59
俺言語さんはDSLスレでも立てて一人でやっててくれ

810 :デフォルトの名無しさん:2009/12/13(日) 14:36:02
>>804
std::vector<int> v(10);
for (auto i = v.begin(); i != v.end(); ++i)

イテレータの型名とかもかなりタイプ数減らせる。

811 :デフォルトの名無しさん:2009/12/13(日) 14:38:40
>>810
すごいコードですね。
そんな使い方ができるのですね。


812 :デフォルトの名無しさん:2009/12/13(日) 15:08:19
どうでもいい言語の表層をいじくり続けるのは
もういい加減にしたいですよ、まったく。
昔はC++コンパイラはC言語のコードを生成してた。
それがC++の仕様変更でできなくなったのなら、
C言語の次期規格C1Xで再びできるようにすればいいではないのか?

813 :デフォルトの名無しさん:2009/12/13(日) 15:20:44
>>812
C++ to Cトランスレータがあれば極一部の人に便利ではあるかもしれないけど,
多くの最適化ができなくなるだろうし,
テンプレート回りのコンパイルとかはるかに遅くなるだろうから,
そんな処理系を作る人はいないんじゃないかね.

814 :デフォルトの名無しさん:2009/12/13(日) 15:54:32
アホは発言を控えて!

815 :デフォルトの名無しさん:2009/12/13(日) 19:08:31
バカは自分のつまらない思い付きに興奮して固執するから困る

816 :812:2009/12/13(日) 19:21:25
>>815
C++0xの新機能を提案したヤツのことだろ。

817 :デフォルトの名無しさん:2009/12/13(日) 19:53:55
暴れなさんな

818 :デフォルトの名無しさん:2009/12/13(日) 20:12:31
逆に、Cのコードを吐くことができなくなるくらい深層をいじったと思えばいい。

819 :デフォルトの名無しさん:2009/12/13(日) 20:37:57
というか

Comeauのこと、時々でいいから思い出してください


820 :デフォルトの名無しさん:2009/12/13(日) 20:54:55
>>812 に Cfront0x でも作ってもらおうぜ

821 :デフォルトの名無しさん:2009/12/13(日) 23:43:28
>>796
いらねーよ、そんなのw
ユーザ定義ポインタ(smart pointer)は今でもつくれるって。

822 :デフォルトの名無しさん:2009/12/14(月) 22:39:28
>>811
テンプレートで使うときに、戻りの型が複雑すぎて手書きできない時なんかに便利。


823 :812:2009/12/14(月) 22:56:11
>>820
それはあなたの仕事。
私はC1X委員会に働きかけて、
C++0xを完全にC1Xに変換できるようにします。
それができたら私は俺言語をつくりC1Xに変換するようにします。

824 :デフォルトの名無しさん:2009/12/14(月) 22:58:51
C++03/0x->C89/99の変換ができるか出来ないかってだけなら、
どれもチューリング完全だから出来るに決まってるんだが
何をどうしたいの?

825 :デフォルトの名無しさん:2009/12/14(月) 23:11:17
Cへのトランスレータっていえば、Valaがおもしろいよ。
ttp://live.gnome.org/Vala
このスレで存在を知ってる人ってどのくらいいるんだろうか?


826 :デフォルトの名無しさん:2009/12/14(月) 23:39:23
たとえ、今でもC++がCのコードへ容易に変換できる仕様だったとしても、
結局、コンパイラの高速化などを理由に機械語やアセンブリ言語を
直接吐く処理系が主流になることにかわりはないと思う。

あったらあったで面白いだろうということは否定しないけど。

827 :デフォルトの名無しさん:2009/12/15(火) 02:49:47
つーかトランスレータなんぞ作っても最適化がまともに掛からなくなるだけだろ
普通にコンパイルしてからC言語ディスコンパイラでも使ってろ

828 :デフォルトの名無しさん:2009/12/15(火) 10:59:49
必要な人は作ればいいし
そうでない人にとってはどうでもいい話

829 :デフォルトの名無しさん:2009/12/15(火) 19:42:04
>>827
お前の持ってる常識なんて一瞬で翻されるよ。

830 :デフォルトの名無しさん:2009/12/15(火) 20:06:00
>>829
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1013807615
バカはこれを100回読みな

831 :デフォルトの名無しさん:2009/12/15(火) 20:24:40
>>827
最適化が何なのかもわからないでよく言えるな。
具体的にC++コンパイラでやってる最適化の何が
トランスレータでできないのか言ってみろ。

832 :デフォルトの名無しさん:2009/12/15(火) 20:53:54
そんなやりとり無駄なだけ。
暇を潰したい人だけ参加しな。

833 :831:2009/12/15(火) 22:21:37
>>832
わざわざ無駄レスして相当の暇人ですね。
それでも一つも思い浮かばないわけですね。
他の暇人のみなさん、じっくり考えて下さいね。

834 :ちんこ ◆GbXlaaQNk. :2009/12/15(火) 22:25:53
当方java使いですが、
C++って使ってて、生きた心地しなくないですか?
メモリ管理も動作とろいし、パフォーマンスもさほど高くないでしょ。
みんなjavaに来いよ。

835 :デフォルトの名無しさん:2009/12/15(火) 22:28:56
そんな餌に釣られないクマ

836 :デフォルトの名無しさん:2009/12/15(火) 22:29:18
C++使っててむしろ快感を覚える俺は変態だろうか。


ところでいつになったらC++0xが正式に採用されるの?
現時点での現実的な見込み時期ってあります?

837 :デフォルトの名無しさん:2009/12/15(火) 22:29:23
>>834
> メモリ管理も動作とろいし
とろい理由を述べよ
ハスケルに目覚めてJava捨てたんじゃなかったのか?


838 :ちんこ ◆GbXlaaQNk. :2009/12/15(火) 22:34:31
>>837
生成が遅くて、回収にも時間がかかると書いてあった。
javaは生成がC++より6倍くらい速くて、回収はほとんど0。

839 :デフォルトの名無しさん:2009/12/15(火) 22:42:23
マイクロベンチマークならね

840 :デフォルトの名無しさん:2009/12/15(火) 22:44:37
なんだ、ただの又聞きか

841 :デフォルトの名無しさん:2009/12/15(火) 22:49:10
Hey, C++ Programmer EveryOne!

My word is " C++ is bitch !! ".

Good night.

842 :デフォルトの名無しさん:2009/12/15(火) 23:28:21
ねぇ、なんで@itのサイトにC++のページがないの?

843 :デフォルトの名無しさん:2009/12/15(火) 23:35:57
>>833
> わざわざ無駄レスして相当の暇人ですね。
ここはお前の喧嘩だから好きにしてくれればいいけど

> 他の暇人のみなさん、じっくり考えて下さいね。
なんだテメェは。失礼な。

844 :デフォルトの名無しさん:2009/12/16(水) 00:31:49
>>842
土方サイトだから

845 :デフォルトの名無しさん:2009/12/16(水) 11:14:01
>>836
ISO/IECの規格は、成立まで投票を3回(3ヶ月・4ヶ月・2ヶ月)しなきゃいけないんだけど、
1回目の投票が終わったところで例のconceptの一件が発生したので、多分最初からやり直し。

来年の7月からは投票制度が変わる予定なので、若干期間が短縮されるかもしれないけど、
どれだけ順調に行っても来年後半〜再来年頭より早まることはないと思う。

846 :デフォルトの名無しさん:2009/12/16(水) 16:57:14
>>824
> どれもチューリング完全だから出来るに決まってるんだが
無限長のテープを持ったチューリングマシンを用意してから言え。

847 :デフォルトの名無しさん:2009/12/16(水) 16:58:30
いや、事実上問題にならないだろ、その辺は

848 :デフォルトの名無しさん:2009/12/16(水) 17:42:43
そうですよねC++がトランスレータでも何の問題もない。

849 :デフォルトの名無しさん:2009/12/16(水) 18:03:26
もちろん、全然問題ないですよ。存在しないことを除けば。

850 :デフォルトの名無しさん:2009/12/17(木) 04:02:37
可能かどうかについては問題無い
実用的かどうかについては問題あり

851 :デフォルトの名無しさん:2009/12/17(木) 09:45:52
理論上prologにだって変換可能

852 :デフォルトの名無しさん:2009/12/17(木) 10:49:14
 void (*signal(int, void (*)(int)))(int);
って「統一された関数宣言構文」ではどう書けるの?

853 :デフォルトの名無しさん:2009/12/17(木) 11:57:48
[] signal(int, [](*)(int)) -> [](*)(int);

これでいいのか自信は無い

854 :デフォルトの名無しさん:2009/12/17(木) 12:13:44
-> void は省略可能なのか

855 :デフォルトの名無しさん:2009/12/17(木) 22:44:42
>>853
なんか, スゲぶさいく
# lambdaちゃんそっくり


856 :デフォルトの名無しさん:2009/12/17(木) 22:49:17
lambdaちゃんの妹です

857 :デフォルトの名無しさん:2009/12/17(木) 23:35:14
どうせ判り切ったこと書きますが、C++2xはHaskellを大きく取り込むだろう。

858 :デフォルトの名無しさん:2009/12/17(木) 23:45:04
というか、conceptはtype classを取り込んだも同然

859 :デフォルトの名無しさん:2009/12/18(金) 23:58:58
そもそも
C++2xは来るのだろうか?

860 :デフォルトの名無しさん:2009/12/19(土) 11:09:58
>>859
ふゆやすみ?

861 :デフォルトの名無しさん:2009/12/19(土) 11:30:22
冬休みが楽しみな美少女中学生

862 :859:2009/12/19(土) 12:42:32
>>860
何かおかしい事言った?


863 :デフォルトの名無しさん:2009/12/19(土) 13:24:22
だから、冬休みになったのならその間にHaskellを勉強しておけってこと。

864 :デフォルトの名無しさん:2009/12/19(土) 15:50:15
std::threadってどのヘッダに入ってるの?

865 :デフォルトの名無しさん:2009/12/19(土) 16:31:48
<thread>

866 :857:2009/12/25(金) 22:41:28
マジで言ってます。
HaskellのエッセンスをC++に生かす研究している人いませんかね。

867 :デフォルトの名無しさん:2009/12/26(土) 01:27:35
関数型プログラミングなら今でもテンプレート使って出来るけど?
Haskellのエッセンスって何

868 :デフォルトの名無しさん:2009/12/26(土) 01:41:37
遅延評価かも

869 :デフォルトの名無しさん:2009/12/26(土) 02:32:37
>>261で出来るよ

870 :デフォルトの名無しさん:2009/12/26(土) 02:39:03
まあ、Haskellといえば遅延評価とカリー化と型クラスだよね
でもconceptが入らなくなっちゃったし

実際にHaskellで書いてて他との違いを一番感じるのは無限上等なとこなので
やっぱり遅延評価か

871 :デフォルトの名無しさん:2009/12/26(土) 04:41:42
カリー化はクロージャのシンタックスシュガーでしかないし
型クラスはオーバーロードだったり継承だったりするので
やっぱ遅延評価だよね

872 :デフォルトの名無しさん:2009/12/26(土) 08:34:23
型推論も忘れないでやってください

873 :デフォルトの名無しさん:2009/12/26(土) 10:52:34
>>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の言うような余地は余りない。

874 :デフォルトの名無しさん:2009/12/26(土) 23:25:40
シンタックスシュガーだって言語のエッセンスとして重要だぞ
カリー化有りか無しかは言語の特徴として特筆すべきことだと思う

875 :デフォルトの名無しさん:2009/12/26(土) 23:30:07
カリー化は複数引数の関数を内部的にどう扱ってるかの違いだろう。
C系統の言語なら別に1番目の引数に特別な意味がある訳じゃないし

876 :デフォルトの名無しさん:2009/12/26(土) 23:47:48
まあ、boost::bind がカリー化やっちゃってると言っても過言ではないかも
0x では型推論してくれるのでHaskellのカリー化より便利か

877 :デフォルトの名無しさん:2009/12/27(日) 01:28:41
bindはまるで関数がカリー化されていたかのように
引数を部分的にapplyするためのテンプレート。

878 :デフォルトの名無しさん:2009/12/27(日) 11:26:08
くだらね。三流どもが。

879 :デフォルトの名無しさん:2009/12/27(日) 11:55:11
>>878
難しくて分かりませんって言えよ。w

880 :デフォルトの名無しさん:2009/12/27(日) 16:01:27
全く理解できなくて一言の反撃すらできないけどとにかく否定したい、という気持ちが
凝縮されてるな

881 :デフォルトの名無しさん:2009/12/27(日) 16:18:54
カリー化なんて何も難しいことないけどな
要は引数を1つずつ順番に使うってだけの話だし

882 :デフォルトの名無しさん:2009/12/27(日) 16:22:25
まぁカリー化以外の話もしてるし、カリー化が何なのかが分かっただけじゃ反論は
始められないしな

883 :デフォルトの名無しさん:2009/12/27(日) 16:39:11
>>881
つ 関数を引数を一つづつ適用できるようにする


884 :デフォルトの名無しさん:2009/12/27(日) 18:36:40
カリー化ってあれだろ、筋肉少女帯のほら

885 :デフォルトの名無しさん:2009/12/27(日) 18:38:12
ナンってイースト菌使うっけ?

886 :デフォルトの名無しさん:2009/12/27(日) 23:50:06
>>884 それは印度化。

887 :デフォルトの名無しさん:2009/12/28(月) 09:05:08
bindをカリー化っていっちゃうのはちょっとな

3引数関数をcurry(f)すると
f(x)(y)(z)
f(x, y)(z)
f(x, y, z)
が全部できるとかならカリー化って感じはするが


888 :デフォルトの名無しさん:2009/12/28(月) 11:10:45
>>887
fusionで上手いこと出来ないかな?

889 :デフォルトの名無しさん:2009/12/28(月) 12:53:39
このへんの話を思い出した
ttp://d.hatena.ne.jp/kmizushima/20091216/1260969166


890 :デフォルトの名無しさん:2009/12/28(月) 16:30:30
単純公理好きの数学だから>一引数関数だけの世界
実際意味ねー

891 :デフォルトの名無しさん:2009/12/28(月) 17:01:01
カリー化と言えばunlambdaですね!

892 :デフォルトの名無しさん:2009/12/28(月) 22:00:36
カリー化とかHaskellとかって結局何が得意なん?

893 :デフォルトの名無しさん:2009/12/29(火) 03:14:08
使い回し

894 :デフォルトの名無しさん:2009/12/29(火) 08:22:40
そもそもcurry化って、
なんでcurryなのよさ。


895 :デフォルトの名無しさん:2009/12/29(火) 08:26:17
それを考えた数学者の名前

896 :デフォルトの名無しさん:2009/12/29(火) 08:37:17
>>895
そうだったのか。
サンクス。

897 :デフォルトの名無しさん:2009/12/29(火) 09:02:37
印土人もびっくり

898 :デフォルトの名無しさん:2009/12/29(火) 10:39:44
>887
とりあえずでっちあげ。Boost のバージョン違いで codepad だと動かないですが。
http://codepad.org/8h1gFMwQ

>888
fusion をどう使うイメージでしょうか。
引数を fusion に溜めておいて一時オブジェクトの破棄時に関数呼び出し?

899 :デフォルトの名無しさん:2009/12/29(火) 11:27:17
>>896
Haskell Brooks Curry と申します。

900 :デフォルトの名無しさん:2009/12/29(火) 20:45:40
カリー化って実用性ってあるの?

901 :デフォルトの名無しさん:2009/12/29(火) 20:55:26
>>900
またそーやって痛いとこ付いちゃうwww

902 :デフォルトの名無しさん:2009/12/29(火) 21:25:33
痛い奴だ

903 :デフォルトの名無しさん:2009/12/29(火) 21:38:37
>>900
・curry化概念は実用的です。
・C++はcurry化がなくても実用的な言語です。
・curry化したければboostのLambdaを使って出来ます。
・一般にcurry化そのものよりも部分適用の方が有用です。
・関数がcurry化されているかのように部分適用するために、bindがあります。

904 :デフォルトの名無しさん:2009/12/29(火) 23:02:26
カリー化があることで引数の順番に利益主導の法則が生まれる実利があると思う

と言ってみるものの、カリー化があると書いてて楽しいのなんのって


905 :デフォルトの名無しさん:2009/12/30(水) 00:57:01
>>898
fusionで引数を与えて、再帰させならが引数を自動的に減少させていくような記述ができないかな?

906 :デフォルトの名無しさん:2009/12/30(水) 00:58:56
boost::tupleの実装ってカリー化っぽくないか?

ただなんとなく。

907 :デフォルトの名無しさん:2009/12/30(水) 10:07:55
カリー化って言うからわかりにくいんであって、遅延束縛(late binding)とか
部分束縛(partial binding)なら普通に理解できるだろう(と思う)。

908 :デフォルトの名無しさん:2009/12/30(水) 10:18:57
数学的には、部分束縛できるような形に、もとのn引数の関数を
m(m < n)引数に変換するのがカリー化

909 :デフォルトの名無しさん:2009/12/30(水) 10:42:25
関数の部分適用と併用して
普通の多引数関数を高階関数のように使える
ってぐらいしか使い道がわからないな

910 :デフォルトの名無しさん:2009/12/30(水) 10:50:31
>>909
operator()に対して、
関数を引数に適用する
ってぐらいしか使い道がわからないな
って言ってるようなもの。


911 :デフォルトの名無しさん:2009/12/30(水) 11:31:08
>>909
引数の型があらかじめ定まっていないから、色々なデータに対する操作が1引数関数1個で表現できるんだからすごいと思うよ。


912 :デフォルトの名無しさん:2009/12/30(水) 11:32:48
>>910
> 関数を引数に適用する
ちなみにそれ以外の使い道なんてあるの?

913 :デフォルトの名無しさん:2009/12/30(水) 11:51:46
>>911
それ多相ラムダ式の話じゃないかね?

914 :デフォルトの名無しさん:2009/12/30(水) 18:00:46
何の話や、え?
加齢化?

915 :デフォルトの名無しさん:2009/12/30(水) 18:08:53
アホは発言を控えて!

916 :デフォルトの名無しさん:2009/12/30(水) 18:34:02
カリー化って、いちいち 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 してるって感覚が薄くなるのが
便利なのかな。

917 :デフォルトの名無しさん:2009/12/30(水) 18:53:11
> リストを条件でフィルタして変換して全部足す、
> みたいな処理を、
>  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

918 :デフォルトの名無しさん:2009/12/30(水) 19:57:10
>>915
誰がアホや?え?

919 :デフォルトの名無しさん:2009/12/30(水) 20:55:43
>>898
関数オブジェクトの引数の数をコンパイル時に取得する手段がないと汎用的に書けないねぇ
arity_of<F>::value みたいな

というかそもそもオーバーロードされてるとダメか?
オーバーロードとカリー化って相性悪そう

920 :デフォルトの名無しさん:2009/12/31(木) 00:40:03
コンセプトについて再考

921 :デフォルトの名無しさん:2009/12/31(木) 09:41:05
conceptを捨てたC++0xに未来は無い

922 :デフォルトの名無しさん:2009/12/31(木) 09:57:40
C++1xで入るだろ

923 :デフォルトの名無しさん:2009/12/31(木) 10:36:11
今から次期規格作っても2xになる予感がします

924 :デフォルトの名無しさん:2009/12/31(木) 10:48:53
もうこの際だからC++xxにしちまえ

925 :デフォルトの名無しさん:2009/12/31(木) 10:50:17
c++++

926 :デフォルトの名無しさん:2009/12/31(木) 11:03:56
コンセプトってパターンマッチの範囲を狭められれそうな気がするからコンパイルが速くなるんじゃないかな?みたいな?
もしかしてenable_ifをしっかり書けばコンパイル速くなる?

927 :デフォルトの名無しさん:2009/12/31(木) 11:09:33
--(C++)

928 :デフォルトの名無しさん:2009/12/31(木) 11:39:49
>>927
右辺値を--するとは、乙なことするな。

929 :デフォルトの名無しさん:2009/12/31(木) 12:11:15
今日中に決まるよね?

930 :デフォルトの名無しさん:2009/12/31(木) 12:21:00
>>928
operator++が参照を返すかも知れないぞ
それより不必要な括弧が言語名につくことこそ問題だと思う

931 :デフォルトの名無しさん:2009/12/31(木) 12:27:50
>>930
そんなクソコードまで予想してなかったわ。

932 :デフォルトの名無しさん:2009/12/31(木) 13:18:57
>>927
それってマイナスじゃん

933 :デフォルトの名無しさん:2009/12/31(木) 15:43:10
>>932
何が?

934 :デフォルトの名無しさん:2009/12/31(木) 16:29:36
戻りが減っちゃってるよ。

935 :デフォルトの名無しさん:2009/12/31(木) 19:12:55
>>925
C#ならもうあるじゃん

936 :デフォルトの名無しさん:2009/12/31(木) 19:18:52
あと5時間弱+9時間しかねーぞ
発表マダー?

937 :デフォルトの名無しさん:2009/12/31(木) 19:46:25
9時間って何かと思ったら時差か。

938 :デフォルトの名無しさん:2009/12/31(木) 19:54:57
UTC計算だね。
UTC-12のタイムゾーンを基準にするなら、更に12時間程度余裕がある

939 :デフォルトの名無しさん:2009/12/31(木) 21:12:26
素直にC+=2

940 :デフォルトの名無しさん:2010/01/01(金) 12:00:27
俺たちの0xはまだ始まったばかりだ!

941 :デフォルトの名無しさん:2010/01/01(金) 12:02:06
始まってもいねぇなw

942 :デフォルトの名無しさん:2010/01/01(金) 12:40:28
あるいは終わった・・・ってところかも

943 : 【だん吉】 【1118円】 :2010/01/01(金) 16:45:03
>[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 :デフォルトの名無しさん:2010/01/01(金) 22:36:54
やっと待ちに待ったゴールがきた。
誰か、公式の完成版仕様書のリンク貼れよ

945 :デフォルトの名無しさん:2010/01/01(金) 23:12:06
>>944
ggrks www


946 :デフォルトの名無しさん:2010/01/02(土) 00:56:25
g++4.5.0 は「Unicode string literals」をサポートしてないの?
(char16_tとchar32_t)

947 :デフォルトの名無しさん:2010/01/02(土) 08:11:15
>946
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html
ここだとサポートしてる事になってるけど実際には動作しないって事?

948 :デフォルトの名無しさん:2010/01/02(土) 11:32:48
このスレには、

  struct foo { auto f()->int && { ... } };
 が int f() && か int && f() のどちらと
 解釈されるか?

という問いに正解できるヤツいる?


949 :デフォルトの名無しさん:2010/01/02(土) 13:25:00
>>948
個人blogのネタコピペかっこわるい。

950 :デフォルトの名無しさん:2010/01/02(土) 13:25:30
>>949
よく知ってるなw

951 :デフォルトの名無しさん:2010/01/02(土) 18:11:08
ヒロヒト…

952 :デフォルトの名無しさん:2010/01/02(土) 20:29:04
馬鹿ばっかし・・・


953 :デフォルトの名無しさん:2010/01/02(土) 23:40:33
>>947
cucharがない

954 :デフォルトの名無しさん:2010/01/03(日) 09:47:59
"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 ライブラリ側の対応待ちじゃないかと思う。

955 :デフォルトの名無しさん:2010/01/04(月) 00:09:37
つーか、いい加減に
C++0xがいつ発表されるのか決着つけてくれだれか

956 :デフォルトの名無しさん:2010/01/04(月) 00:21:37
0xは90年待たないと…

957 :デフォルトの名無しさん:2010/01/04(月) 10:03:41
C++0x → C++1x

958 :デフォルトの名無しさん:2010/01/04(月) 13:49:56
>>946
typedef __CHAR16_TYPE__ char16_t;
typedef __CHAR32_TYPE__ char32_t;


959 :デフォルトの名無しさん:2010/01/04(月) 19:32:26
C++0xってすでに二年前にC++010になってるじゃん
今年は012ですよ皆さん。


960 :デフォルトの名無しさん:2010/01/04(月) 21:08:50
16進なのか8進なのか10進なのかは議論の分かれるところですなぁ。
俺は16進だと思う。

961 :デフォルトの名無しさん:2010/01/04(月) 21:21:17
00
0x
x0
xx

二進数説

962 :デフォルトの名無しさん:2010/01/04(月) 21:27:10
そんなんどうでもいいから
早くリリースしろ

と叫ぶしか俺らにはできることがない。

963 :デフォルトの名無しさん:2010/01/04(月) 21:57:38
> 早くリリースしろ
同感

とは言うものの現 C++ の拙速感(特に STL)はもうたくさん
巧遅を早くやれってことだけど、どないもこないも・・・

964 :デフォルトの名無しさん:2010/01/04(月) 22:07:57
>>961
奇才現る!!

965 :デフォルトの名無しさん:2010/01/04(月) 22:27:39
C++は2000年頃にすっかり使わなくなって10年程になるのだが、
今、C++0xの内容も含めてリハビリするとしたら、どの辺りの
ドキュメント・書籍がおすすめ?和書洋書問わず。

966 :デフォルトの名無しさん:2010/01/04(月) 22:32:30
ヒロヒロが著すC++0x本を待て

967 :デフォルトの名無しさん:2010/01/04(月) 22:37:56
×ヒロヒロ
○ヒロヒト

968 :デフォルトの名無しさん:2010/01/04(月) 23:48:19
>>965 >>1

969 :デフォルトの名無しさん:2010/01/05(火) 00:57:05
>>968
なんかURLが羅列してあるだけなんですが

970 :デフォルトの名無しさん:2010/01/05(火) 00:59:49
なにかもんだいでも?

971 :デフォルトの名無しさん:2010/01/05(火) 01:58:29
0xの平易な解説書はまだ無いんじゃね
処理系もまだβ臭ぷんぷんなのに

972 :デフォルトの名無しさん:2010/01/06(水) 20:41:10
C++の規格を読むと鬼難しい規則が膨大に羅列されていいる。
それでもなお規格の開発はすすむ。
C++はもう限界を越えて破滅の道を進んでいるんでしょうね。

973 :デフォルトの名無しさん:2010/01/06(水) 20:58:27
>>972 限界とは?具体的に

974 :デフォルトの名無しさん:2010/01/06(水) 20:59:05
auto とか簡単なものは簡単なんだが
右辺値参照とかどうなのよって感じ
あれば高速化に寄与するのは分かるけど
それ使ったコードは他の人に分かるんかと

975 :デフォルトの名無しさん:2010/01/06(水) 21:04:01
右辺値参照はコンテナとかスマポとかのライブラリが対応するだけで、ライブラリの使い手は存在を知らないままでも高速化ができちゃうね。


976 :デフォルトの名無しさん:2010/01/06(水) 21:07:34
>>975
それってある意味とてもすごいことだよな。
でも逆に自分がライブラリを書くときは
そこまで考えて書かないと
こいつなにやってんの?って思われるってことか?

977 :デフォルトの名無しさん:2010/01/06(水) 21:16:17
これからC++コンパイラ作ろうとする奴がいたら死ぬな

978 :デフォルトの名無しさん:2010/01/06(水) 21:19:30
しかもgccが
 標準ライブラリを利用してもソースコード公開不要
てなライセンスだから、それを越えて実装しないと
実質的に意味ないよね?


979 :デフォルトの名無しさん:2010/01/06(水) 21:21:26
>>975
右辺値参照の準備は、const hoge func()をhoge func()に変えておく必要があるけどな。


980 :デフォルトの名無しさん:2010/01/06(水) 21:45:36
>>979
そういやそうだったな。
Effective C++ に書いてあった内容が
現在にそぐわなくなるわけね。

981 :!omikuji!dama:2010/01/06(水) 22:03:25
>>976
これまでの開発で右辺値参照が欲しいと思ったことがある奴にとっては大変ありがたい
そう思ったことが無い奴にとってはこれからも不要なので気にしなくてよい

982 :>976:2010/01/06(水) 23:06:05
>>981
いままでは
テンポラリオブジェクトはconst参照で捕まえていたが、
あれがnon-constに捕まえられたら少しは早くなるだろうなぁ
と思ったことはある。


190 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)