C++0x 7

0001デフォルトの名無しさん

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/

0002デフォルトの名無しさん

2009/09/18(金) 22:27:46

>>1死ね

0003デフォルトの名無しさん

2009/09/18(金) 22:34:15

嫌です（^ε^）

0004デフォルトの名無しさん

2009/09/18(金) 22:36:02

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

0005デフォルトの名無しさん

2009/09/18(金) 22:37:59

C++学園の人々

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

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

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

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

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

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

0006デフォルトの名無しさん

2009/09/18(金) 22:38:09

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

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

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

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

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

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

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

○禿
校長先生。

0007デフォルトの名無しさん

2009/09/18(金) 22:46:04

>>5-6
乙

0008デフォルトの名無しさん

2009/09/18(金) 22:54:08

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

ここで爆笑した

0009デフォルトの名無しさん

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

0010デフォルトの名無しさん

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さんと仲が良いらしい。

0011デフォルトの名無しさん

2009/09/18(金) 23:21:05

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

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

0012デフォルトの名無しさん

2009/09/18(金) 23:30:46

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

0013デフォルトの名無しさん

2009/09/18(金) 23:35:16

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

0014デフォルトの名無しさん

2009/09/19(土) 02:35:20

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

0015デフォルトの名無しさん

2009/09/19(土) 03:22:07

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

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

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

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

0016デフォルトの名無しさん

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 が
存在しても２つの名前 ::operator "" _x と ::_x は衝突しない。

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

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

0017デフォルトの名無しさん

2009/09/19(土) 04:42:55

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

0018デフォルトの名無しさん

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 の
一部であると考えられる。

0019デフォルトの名無しさん

2009/09/19(土) 05:03:38

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

0020デフォルトの名無しさん

2009/09/19(土) 05:16:52

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

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

0021デフォルトの名無しさん

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なんじゃないの。

0022デフォルトの名無しさん

2009/09/19(土) 05:37:29

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

0023デフォルトの名無しさん

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 で定義される
ものとは違うようで、ここにも混乱のもとがあるみたい。

0024デフォルトの名無しさん

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がこの辺のことをわきまえず、規格違反のコードが世にあふれ、後のリテラルの規格改定に影響を及ぼすこと。

0025デフォルトの名無しさん

2009/09/19(土) 06:17:12

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

0026デフォルトの名無しさん

2009/09/19(土) 06:25:33

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

0027デフォルトの名無しさん

2009/09/19(土) 06:30:25

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

0028デフォルトの名無しさん

2009/09/19(土) 06:30:59

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

0029デフォルトの名無しさん

2009/09/19(土) 06:42:00

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

0030デフォルトの名無しさん

2009/09/19(土) 06:43:34

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

003130

2009/09/19(土) 06:45:30

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

0032デフォルトの名無しさん

2009/09/19(土) 06:45:43

>>4
もうない。

>>5-11
よそでやれ。

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

0033デフォルトの名無しさん

2009/09/19(土) 07:13:32

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

0034デフォルトの名無しさん

2009/09/19(土) 11:54:17

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

0035デフォルトの名無しさん

2009/09/19(土) 13:05:50

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

0036デフォルトの名無しさん

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 がオーバーラップしない別物として定義されて
いるあたりも問題な気がする。

0037デフォルトの名無しさん

2009/09/19(土) 20:05:44

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

0038デフォルトの名無しさん

2009/09/19(土) 20:07:03

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

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

0039デフォルトの名無しさん

2009/09/19(土) 20:31:43

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

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

0040デフォルトの名無しさん

2009/09/20(日) 00:30:04

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

0041デフォルトの名無しさん

2009/09/20(日) 00:51:03

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

0042デフォルトの名無しさん

2009/09/20(日) 02:57:10

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

0043デフォルトの名無しさん

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.
だそうだ

0044デフォルトの名無しさん

2009/09/20(日) 09:01:53

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

0045デフォルトの名無しさん

2009/09/20(日) 10:00:50

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

ありがとうです。

0046デフォルトの名無しさん

2009/09/20(日) 11:57:49

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

0047デフォルトの名無しさん

2009/09/20(日) 12:03:59

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

0048デフォルトの名無しさん

2009/09/20(日) 13:37:48

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

0049デフォルトの名無しさん

2009/09/20(日) 18:07:18

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

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

0050デフォルトの名無しさん

2009/09/20(日) 18:43:20

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

0051デフォルトの名無しさん

2009/09/20(日) 18:49:17

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

0052デフォルトの名無しさん

2009/09/20(日) 18:51:52

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

0053デフォルトの名無しさん

2009/09/20(日) 18:56:54

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

0054デフォルトの名無しさん

2009/09/20(日) 19:59:59

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

0055デフォルトの名無しさん

2009/09/20(日) 20:03:22

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

0056デフォルトの名無しさん

2009/09/20(日) 20:24:29

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

0057デフォルトの名無しさん

2009/09/20(日) 22:40:28

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

0058デフォルトの名無しさん

2009/09/20(日) 22:58:14

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

0059デフォルトの名無しさん

2009/09/20(日) 23:11:24

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

0060デフォルトの名無しさん

2009/09/20(日) 23:22:27

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

0061デフォルトの名無しさん

2009/09/20(日) 23:25:20

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

0062デフォルトの名無しさん

2009/09/20(日) 23:59:24

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

0063デフォルトの名無しさん

2009/09/21(月) 09:39:40

普通はそう思う

0064デフォルトの名無しさん

2009/09/21(月) 10:19:22

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

0065デフォルトの名無しさん

2009/09/21(月) 10:36:31

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

0066デフォルトの名無しさん

2009/09/21(月) 12:52:50

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

0067デフォルトの名無しさん

2009/09/21(月) 13:01:06

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

0068デフォルトの名無しさん

2009/09/21(月) 13:59:40

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

0069デフォルトの名無しさん

2009/09/21(月) 14:03:07

ifかmatch withが必要だな

0070デフォルトの名無しさん

2009/09/21(月) 14:15:18

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

0071デフォルトの名無しさん

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

意外と面倒臭いすなあ

0072デフォルトの名無しさん

2009/09/21(月) 20:10:33

>>71
そんなもんじゃね

0073デフォルトの名無しさん

2009/09/21(月) 22:32:13

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

0074デフォルトの名無しさん

2009/09/21(月) 22:35:23

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

0075デフォルトの名無しさん

2009/09/21(月) 22:36:49

それMPLじゃなくね？

0076デフォルトの名無しさん

2009/09/21(月) 23:10:25

Generic Programming
Template Metaprogramming
Boost.MPL

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

0077デフォルトの名無しさん

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の部分にはなんと書いたらいいんだろうという話から始まるんだよ、きっと。

0078デフォルトの名無しさん

2009/09/21(月) 23:30:09

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

0079デフォルトの名無しさん

2009/09/21(月) 23:33:26

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

0080デフォルトの名無しさん

2009/09/21(月) 23:35:59

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

0081デフォルトの名無しさん

2009/09/21(月) 23:57:53

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

0082デフォルトの名無しさん

2009/09/22(火) 02:30:29

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

0083デフォルトの名無しさん

2009/09/22(火) 03:24:57

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

0084デフォルトの名無しさん

2009/09/22(火) 11:03:25

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

0085デフォルトの名無しさん

2009/09/22(火) 11:44:32

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

0086デフォルトの名無しさん

2009/09/22(火) 17:23:17

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

0087デフォルトの名無しさん

2009/09/22(火) 20:26:22

>85
俺漏れもー。

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

0088デフォルトの名無しさん

2009/09/22(火) 20:27:57

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

0089デフォルトの名無しさん

2009/09/23(水) 14:30:56

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

0090デフォルトの名無しさん

2009/09/23(水) 14:44:59

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

0091デフォルトの名無しさん

2009/09/23(水) 15:45:51

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

0092デフォルトの名無しさん

2009/09/23(水) 23:32:40

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

0093デフォルトの名無しさん

2009/09/24(木) 10:08:38

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

板違いだろ、このカス。

0094デフォルトの名無しさん

2009/09/24(木) 22:06:49

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

0095デフォルトの名無しさん

2009/09/24(木) 22:39:50

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

0096デフォルトの名無しさん

2009/09/24(木) 23:25:33

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

0097デフォルトの名無しさん

2009/09/25(金) 00:27:00

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

0098デフォルトの名無しさん

2009/09/25(金) 01:19:52

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

0099デフォルトの名無しさん

2009/09/25(金) 02:35:04

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

0100デフォルトの名無しさん

2009/09/25(金) 11:24:50

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

0101デフォルトの名無しさん

2009/09/25(金) 12:11:30

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

0102デフォルトの名無しさん

2009/09/25(金) 12:15:53

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

0103デフォルトの名無しさん

2009/09/25(金) 14:01:50

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

0104デフォルトの名無しさん

2009/09/25(金) 15:52:03

いらねーな。

0105デフォルトの名無しさん

2009/09/25(金) 18:03:56

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

0106デフォルトの名無しさん

2009/09/25(金) 18:39:53

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

0107デフォルトの名無しさん

2009/09/25(金) 21:56:30

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

0108デフォルトの名無しさん

2009/09/25(金) 22:06:47

関数オブジェクト

0109デフォルトの名無しさん

2009/09/25(金) 22:23:44

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

0110デフォルトの名無しさん

2009/09/25(金) 22:29:05

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

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

0111デフォルトの名無しさん

2009/09/25(金) 22:56:09

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

0112デフォルトの名無しさん

2009/09/26(土) 00:12:06

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

0113デフォルトの名無しさん

2009/09/26(土) 00:14:19

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

0114デフォルトの名無しさん

2009/09/26(土) 00:18:13

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

0115デフォルトの名無しさん

2009/09/26(土) 00:27:54

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

0116デフォルトの名無しさん

2009/09/26(土) 00:36:26

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

0117デフォルトの名無しさん

2009/09/26(土) 00:40:50

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

0118デフォルトの名無しさん

2009/09/26(土) 00:59:27

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

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

0119デフォルトの名無しさん

2009/09/26(土) 02:06:29

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

0120デフォルトの名無しさん

2009/09/26(土) 02:20:01

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

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

0121デフォルトの名無しさん

2009/09/26(土) 02:44:30

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

0122デフォルトの名無しさん

2009/09/26(土) 03:05:18

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

0123デフォルトの名無しさん

2009/09/26(土) 03:12:42

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

0124デフォルトの名無しさん

2009/09/26(土) 10:08:04

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

0125デフォルトの名無しさん

2009/09/26(土) 13:11:23

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

0126デフォルトの名無しさん

2009/09/26(土) 13:24:33

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

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

0127デフォルトの名無しさん

2009/09/26(土) 13:43:50

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

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

0128デフォルトの名無しさん

2009/09/26(土) 14:14:41

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

0129デフォルトの名無しさん

2009/09/26(土) 14:34:16

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

0130デフォルトの名無しさん

2009/09/26(土) 14:39:46

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

0131デフォルトの名無しさん

2009/09/26(土) 14:49:53

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

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

0132デフォルトの名無しさん

2009/09/26(土) 14:52:28

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

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

0133デフォルトの名無しさん

2009/09/26(土) 14:59:00

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

0134デフォルトの名無しさん

2009/09/26(土) 15:11:31

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

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

0135デフォルトの名無しさん

2009/09/26(土) 15:12:05

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

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

0136デフォルトの名無しさん

2009/09/26(土) 15:16:30

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

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

0137デフォルトの名無しさん

2009/09/26(土) 15:58:32

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

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

0138デフォルトの名無しさん

2009/09/26(土) 16:14:51

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

0139デフォルトの名無しさん

2009/09/26(土) 16:27:45

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

0140デフォルトの名無しさん

2009/09/26(土) 17:10:11

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

0141デフォルトの名無しさん

2009/09/26(土) 17:30:01

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

0142デフォルトの名無しさん

2009/09/26(土) 18:13:56

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

0143デフォルトの名無しさん

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

0144デフォルトの名無しさん

2009/09/26(土) 18:54:22

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

0145デフォルトの名無しさん

2009/09/26(土) 19:55:41

利点はもう一個あるな

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

0146デフォルトの名無しさん

2009/09/26(土) 20:10:23

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

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

0147デフォルトの名無しさん

2009/09/26(土) 20:19:19

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

0148デフォルトの名無しさん

2009/09/26(土) 20:31:30

不可能ではないし。

0149デフォルトの名無しさん

2009/09/26(土) 20:33:12

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

0150デフォルトの名無しさん

2009/09/26(土) 20:33:23

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

0151デフォルトの名無しさん

2009/09/26(土) 20:39:48

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

0152デフォルトの名無しさん

2009/09/26(土) 20:40:05

例えばこれが出来ない

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

0153デフォルトの名無しさん

2009/09/26(土) 20:42:21

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

0154デフォルトの名無しさん

2009/09/26(土) 20:44:09

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

0155デフォルトの名無しさん

2009/09/26(土) 20:46:08

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

0156デフォルトの名無しさん

2009/09/26(土) 20:47:06

ここで聞くなよ

0157デフォルトの名無しさん

2009/09/26(土) 20:50:04

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

0158デフォルトの名無しさん

2009/09/26(土) 20:52:07

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

0159デフォルトの名無しさん

2009/09/26(土) 21:06:48

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

0160デフォルトの名無しさん

2009/09/26(土) 21:12:54

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

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

0161デフォルトの名無しさん

2009/09/26(土) 21:16:03

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

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

0162デフォルトの名無しさん

2009/09/26(土) 21:17:49

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

0163デフォルトの名無しさん

2009/09/26(土) 21:19:35

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

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

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

0164デフォルトの名無しさん

2009/09/26(土) 21:19:41

杞憂ですね。

0165デフォルトの名無しさん

2009/09/26(土) 21:23:25

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

0166デフォルトの名無しさん

2009/09/26(土) 21:26:54

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

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

0167デフォルトの名無しさん

2009/09/26(土) 21:28:07

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

0168デフォルトの名無しさん

2009/09/26(土) 21:30:10

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

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

0169デフォルトの名無しさん

2009/09/26(土) 21:31:17

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

0170デフォルトの名無しさん

2009/09/26(土) 21:39:59

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

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

0171デフォルトの名無しさん

2009/09/26(土) 21:41:48

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

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

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

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

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

0172デフォルトの名無しさん

2009/09/26(土) 21:42:41

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

0173デフォルトの名無しさん

2009/09/26(土) 21:47:36

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

0174デフォルトの名無しさん

2009/09/26(土) 21:47:49

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

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

0175デフォルトの名無しさん

2009/09/26(土) 21:49:48

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

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

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

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

0176112

2009/09/26(土) 21:59:47

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

0177デフォルトの名無しさん

2009/09/26(土) 22:06:44

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

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

0178デフォルトの名無しさん

2009/09/26(土) 22:08:28

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

0179デフォルトの名無しさん

2009/09/26(土) 22:11:44

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

0180デフォルトの名無しさん

2009/09/26(土) 22:59:09

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

0181デフォルトの名無しさん

2009/09/27(日) 08:43:51

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

0182デフォルトの名無しさん

2009/09/27(日) 11:11:43

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

0183デフォルトの名無しさん

2009/09/27(日) 11:32:43

一人だけだろｗ

0184デフォルトの名無しさん

2009/09/27(日) 13:10:43

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

0185デフォルトの名無しさん

2009/09/27(日) 13:53:00

いや一人いる

0186デフォルトの名無しさん

2009/09/27(日) 14:30:55

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

0187デフォルトの名無しさん

2009/09/27(日) 14:48:53

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

0188デフォルトの名無しさん

2009/09/27(日) 15:18:42

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

0189デフォルトの名無しさん

2009/09/27(日) 15:22:27

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

0190デフォルトの名無しさん

2009/09/27(日) 15:36:04

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

0191デフォルトの名無しさん

2009/09/27(日) 15:43:49

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

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

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

0192デフォルトの名無しさん

2009/09/27(日) 15:51:03

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

0193デフォルトの名無しさん

2009/09/27(日) 16:00:23

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

0194デフォルトの名無しさん

2009/09/27(日) 16:18:28

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

0195デフォルトの名無しさん

2009/09/27(日) 16:24:04

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

0196デフォルトの名無しさん

2009/09/27(日) 17:25:58

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

0197196

2009/09/27(日) 17:29:13

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

0198デフォルトの名無しさん

2009/09/27(日) 17:31:54

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

0199デフォルトの名無しさん

2009/09/27(日) 19:05:09

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

0200デフォルトの名無しさん

2009/09/27(日) 19:10:26

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

0201デフォルトの名無しさん

2009/09/27(日) 20:38:30

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

0202デフォルトの名無しさん

2009/09/28(月) 22:58:30

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

0203デフォルトの名無しさん

2009/09/29(火) 00:01:43

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

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

0204デフォルトの名無しさん

2009/09/29(火) 02:05:52

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

0205デフォルトの名無しさん

2009/09/29(火) 03:15:26

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

0206デフォルトの名無しさん

2009/09/29(火) 09:28:31

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

0207デフォルトの名無しさん

2009/09/29(火) 22:14:34

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

0208デフォルトの名無しさん

2009/09/29(火) 23:56:23

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

0209デフォルトの名無しさん

2009/09/30(水) 01:33:37

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

0210デフォルトの名無しさん

2009/09/30(水) 01:58:39

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

0211デフォルトの名無しさん

2009/09/30(水) 01:59:20

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

0212デフォルトの名無しさん

2009/09/30(水) 07:46:44

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

0213デフォルトの名無しさん

2009/09/30(水) 12:20:12

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

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

0214デフォルトの名無しさん

2009/09/30(水) 18:19:51

よかったねラムダさん！

0215デフォルトの名無しさん

2009/09/30(水) 20:30:32

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

0216デフォルトの名無しさん

2009/09/30(水) 20:56:32

さようなら Boost な lambda さん！

0217デフォルトの名無しさん

2009/09/30(水) 22:21:46

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

0218234

2009/09/30(水) 23:47:10

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

0219デフォルトの名無しさん

2009/10/01(木) 00:54:57

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

0220デフォルトの名無しさん

2009/10/01(木) 01:47:54

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

0221デフォルトの名無しさん

2009/10/01(木) 02:51:51

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

Oh!

0222デフォルトの名無しさん

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

0223デフォルトの名無しさん

2009/10/01(木) 07:37:24

落とせない

0224デフォルトの名無しさん

2009/10/01(木) 17:53:06

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

0225デフォルトの名無しさん

2009/10/01(木) 19:54:17

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

0226デフォルトの名無しさん

2009/10/01(木) 19:55:46

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

0227デフォルトの名無しさん

2009/10/01(木) 20:22:12

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

0228デフォルトの名無しさん

2009/10/01(木) 20:27:10

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

0229デフォルトの名無しさん

2009/10/01(木) 23:50:31

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

0230デフォルトの名無しさん

2009/10/01(木) 23:55:35

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

0231デフォルトの名無しさん

2009/10/02(金) 00:07:00

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

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

0232デフォルトの名無しさん

2009/10/02(金) 00:12:44

名前が悪いってことだろ

0233デフォルトの名無しさん

2009/10/02(金) 00:26:09

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

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

0234デフォルトの名無しさん

2009/10/02(金) 00:26:10

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

0235デフォルトの名無しさん

2009/10/02(金) 00:48:15

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

0236デフォルトの名無しさん

2009/10/02(金) 02:29:57

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

0237デフォルトの名無しさん

2009/10/02(金) 07:35:25

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

0238デフォルトの名無しさん

2009/10/02(金) 07:46:35

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

0239デフォルトの名無しさん

2009/10/02(金) 08:16:00

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

0240デフォルトの名無しさん

2009/10/02(金) 08:50:13

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

0241デフォルトの名無しさん

2009/10/02(金) 11:11:33

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

0242デフォルトの名無しさん

2009/10/02(金) 11:21:48

俺はハッピーターン派

0243デフォルトの名無しさん

2009/10/02(金) 12:45:24

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

0244デフォルトの名無しさん

2009/10/03(土) 03:16:29

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

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

0245デフォルトの名無しさん

2009/10/03(土) 13:19:20

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

0246デフォルトの名無しさん

2009/10/03(土) 16:13:41

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

0247デフォルトの名無しさん

2009/10/03(土) 18:03:16

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

0248デフォルトの名無しさん

2009/10/05(月) 16:32:54

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

0249デフォルトの名無しさん

2009/10/05(月) 18:34:42

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

0250デフォルトの名無しさん

2009/10/05(月) 21:33:54

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

0251デフォルトの名無しさん

2009/10/07(水) 18:19:37

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

0252デフォルトの名無しさん

2009/10/07(水) 21:59:25

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

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

0253デフォルトの名無しさん

2009/10/07(水) 22:37:12

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

0254デフォルトの名無しさん

2009/10/08(木) 06:52:26

でくれあーたいぷ

0255デフォルトの名無しさん

2009/10/09(金) 03:57:40

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

0256デフォルトの名無しさん

2009/10/09(金) 06:57:50

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

0257デフォルトの名無しさん

2009/10/09(金) 07:19:35

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

0258デフォルトの名無しさん

2009/10/09(金) 08:20:00

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

0259デフォルトの名無しさん

2009/10/09(金) 18:52:18

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

0260デフォルトの名無しさん

2009/10/09(金) 19:07:05

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

0261デフォルトの名無しさん

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"));
}

0262デフォルトの名無しさん

2009/10/10(土) 09:54:29

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

0263デフォルトの名無しさん

2009/10/10(土) 10:01:57

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

0264デフォルトの名無しさん

2009/10/10(土) 17:45:49

>>261
きれい

0265デフォルトの名無しさん

2009/10/10(土) 19:16:17

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

0266デフォルトの名無しさん

2009/10/10(土) 19:20:51

mainがreturnしてないょ

0267デフォルトの名無しさん

2009/10/10(土) 19:23:32

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

0268デフォルトの名無しさん

2009/10/10(土) 19:27:08

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

0269デフォルトの名無しさん

2009/10/11(日) 01:10:59

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

0270デフォルトの名無しさん

2009/10/11(日) 01:32:21

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

0271デフォルトの名無しさん

2009/10/11(日) 01:45:53

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

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

0272デフォルトの名無しさん

2009/10/11(日) 02:51:34

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

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

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

0273デフォルトの名無しさん

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

0274デフォルトの名無しさん

2009/10/15(木) 15:17:22

雛苺乙

0275デフォルトの名無しさん

2009/10/15(木) 18:33:39

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

0276デフォルトの名無しさん

2009/10/15(木) 18:53:36

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

0277デフォルトの名無しさん

2009/10/15(木) 20:26:32

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

0278デフォルトの名無しさん

2009/10/16(金) 00:46:15

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

0279デフォルトの名無しさん

2009/10/16(金) 01:36:45

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

0280デフォルトの名無しさん

2009/10/16(金) 06:59:25

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

0281デフォルトの名無しさん

2009/10/16(金) 08:05:36

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

0282デフォルトの名無しさん

2009/10/16(金) 08:32:39

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

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

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

0283デフォルトの名無しさん

2009/10/16(金) 12:31:49

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

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

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

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

0284デフォルトの名無しさん

2009/10/16(金) 18:08:14

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

0285282

2009/10/16(金) 19:46:41

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

0286デフォルトの名無しさん

2009/10/16(金) 20:39:28

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

0287デフォルトの名無しさん

2009/10/16(金) 20:41:11

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

0288デフォルトの名無しさん

2009/10/17(土) 01:21:27

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

0289デフォルトの名無しさん

2009/10/18(日) 23:30:01

なんかすごいね

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

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

0290デフォルトの名無しさん

2009/10/19(月) 00:17:55

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

0291デフォルトの名無しさん

2009/10/19(月) 09:49:55

グダグダです。

0292デフォルトの名無しさん

2009/10/19(月) 20:34:04

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

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

0293デフォルトの名無しさん

2009/10/19(月) 20:57:34

#ifndef __INTEL__
#define __par
#endif

0294デフォルトの名無しさん

2009/10/20(火) 06:58:27

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

0295デフォルトの名無しさん

2009/10/20(火) 10:46:56

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

0296デフォルトの名無しさん

2009/10/20(火) 11:17:32

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

0297デフォルトの名無しさん

2009/10/20(火) 11:27:17

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

0298デフォルトの名無しさん

2009/10/20(火) 21:13:47

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

0299デフォルトの名無しさん

2009/10/20(火) 21:19:47

コンパイラ作ってます

0300デフォルトの名無しさん

2009/10/20(火) 21:24:09

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

0301デフォルトの名無しさん

2009/10/20(火) 22:30:41

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

0302デフォルトの名無しさん

2009/10/20(火) 22:33:42

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

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

0303デフォルトの名無しさん

2009/10/20(火) 23:02:54

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

0304デフォルトの名無しさん

2009/10/20(火) 23:12:02

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

0305デフォルトの名無しさん

2009/10/20(火) 23:25:02

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

0306デフォルトの名無しさん

2009/10/20(火) 23:33:38

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

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

0307デフォルトの名無しさん

2009/10/20(火) 23:34:43

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

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

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

0308デフォルトの名無しさん

2009/10/20(火) 23:35:55

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

0309デフォルトの名無しさん

2009/10/21(水) 00:05:39

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

0310デフォルトの名無しさん

2009/10/21(水) 08:50:04

まだ2ヶ月ある！

0311デフォルトの名無しさん

2009/10/21(水) 09:16:17

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

0312デフォルトの名無しさん

2009/10/21(水) 09:53:45

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

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

0313デフォルトの名無しさん

2009/10/21(水) 10:21:54

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

0314デフォルトの名無しさん

2009/10/21(水) 14:18:28

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

0315デフォルトの名無しさん

2009/10/21(水) 18:11:14

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

0316デフォルトの名無しさん

2009/10/21(水) 19:30:38

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

0317デフォルトの名無しさん

2009/10/21(水) 19:41:09

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

0318デフォルトの名無しさん

2009/10/21(水) 22:15:36

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

0319デフォルトの名無しさん

2009/10/21(水) 22:51:35

>>318
だまれ

0320デフォルトの名無しさん

2009/10/21(水) 22:54:53

C++0x2108

0321デフォルトの名無しさん

2009/10/22(木) 07:15:32

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

0322デフォルトの名無しさん

2009/10/22(木) 09:09:40

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

0323デフォルトの名無しさん

2009/10/22(木) 19:55:54

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

0324デフォルトの名無しさん

2009/10/22(木) 21:49:56

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

0325デフォルトの名無しさん

2009/10/22(木) 21:52:18

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

0326デフォルトの名無しさん

2009/10/22(木) 21:58:45

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

0327デフォルトの名無しさん

2009/10/22(木) 23:35:21

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

0328デフォルトの名無しさん

2009/10/23(金) 04:26:47

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

0329デフォルトの名無しさん

2009/10/23(金) 07:05:50

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

0330デフォルトの名無しさん

2009/10/23(金) 08:36:22

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

0331デフォルトの名無しさん

2009/10/23(金) 12:22:41

0x関係ないがな

0332デフォルトの名無しさん

2009/10/23(金) 19:15:04

VC10にnullptrがついたらしい

0333デフォルトの名無しさん

2009/10/23(金) 20:03:13

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

0334デフォルトの名無しさん

2009/10/23(金) 21:12:42

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

0335デフォルトの名無しさん

2009/10/23(金) 21:31:26

電子土木作業員

0336デフォルトの名無しさん

2009/10/23(金) 21:47:04

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

0337デフォルトの名無しさん

2009/10/23(金) 23:41:30

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

0338デフォルトの名無しさん

2009/10/23(金) 23:43:41

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

0339デフォルトの名無しさん

2009/10/24(土) 00:12:22

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

0340デフォルトの名無しさん

2009/10/24(土) 01:35:19

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

0341デフォルトの名無しさん

2009/10/24(土) 02:51:40

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

0342デフォルトの名無しさん

2009/10/24(土) 03:16:21

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

0343デフォルトの名無しさん

2009/10/24(土) 03:44:30

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

0344デフォルトの名無しさん

2009/10/24(土) 10:59:32

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

0345デフォルトの名無しさん

2009/10/24(土) 11:42:51

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

0346デフォルトの名無しさん

2009/10/24(土) 11:59:31

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

0347デフォルトの名無しさん

2009/10/24(土) 14:33:24

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

0348デフォルトの名無しさん

2009/10/24(土) 14:42:58

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

0349デフォルトの名無しさん

2009/10/24(土) 14:43:27

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

0350デフォルトの名無しさん

2009/10/24(土) 14:46:33

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

0351デフォルトの名無しさん

2009/10/24(土) 14:53:38

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

0352デフォルトの名無しさん

2009/10/24(土) 14:54:43

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

0353デフォルトの名無しさん

2009/10/24(土) 15:05:00

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

0354デフォルトの名無しさん

2009/10/24(土) 18:58:50

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

0355デフォルトの名無しさん

2009/10/24(土) 19:01:29

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

0356デフォルトの名無しさん

2009/10/24(土) 19:02:04

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

0357デフォルトの名無しさん

2009/10/24(土) 19:09:42

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

0358デフォルトの名無しさん

2009/10/24(土) 19:26:14

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

0359デフォルトの名無しさん

2009/10/24(土) 19:44:15

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

0360デフォルトの名無しさん

2009/10/25(日) 00:42:48

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

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

0361デフォルトの名無しさん

2009/10/25(日) 00:48:56

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

0362デフォルトの名無しさん

2009/10/25(日) 01:24:05

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

0363デフォルトの名無しさん

2009/10/25(日) 02:04:36

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

0364デフォルトの名無しさん

2009/10/25(日) 02:06:05

C++0x20くらいだろｗ

0365デフォルトの名無しさん

2009/10/25(日) 02:06:31

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

0366デフォルトの名無しさん

2009/10/25(日) 10:17:58

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

0367デフォルトの名無しさん

2009/10/25(日) 10:46:43

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

0368デフォルトの名無しさん

2009/10/25(日) 12:23:11

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

0369デフォルトの名無しさん

2009/10/25(日) 12:45:18

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

0370デフォルトの名無しさん

2009/10/25(日) 12:56:31

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

0371デフォルトの名無しさん

2009/10/25(日) 18:32:24

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

0372デフォルトの名無しさん

2009/10/25(日) 18:35:12

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

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

0373デフォルトの名無しさん

2009/10/25(日) 19:00:32

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

0374デフォルトの名無しさん

2009/10/25(日) 19:06:21

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

0375デフォルトの名無しさん

2009/10/25(日) 19:16:43

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

0376デフォルトの名無しさん

2009/10/25(日) 19:43:30

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

モグリだな。

0377デフォルトの名無しさん

2009/10/25(日) 20:54:20

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

0378デフォルトの名無しさん

2009/10/25(日) 21:51:01

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

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

0379デフォルトの名無しさん

2009/11/02(月) 16:05:35

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

0380デフォルトの名無しさん

2009/11/03(火) 11:23:01

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

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

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

0381デフォルトの名無しさん

2009/11/03(火) 11:33:43

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

0382デフォルトの名無しさん

2009/11/03(火) 11:37:14

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

0383デフォルトの名無しさん

2009/11/03(火) 11:41:24

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

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

0384デフォルトの名無しさん

2009/11/03(火) 12:30:07

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

0385デフォルトの名無しさん

2009/11/03(火) 14:35:53

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

0386デフォルトの名無しさん

2009/11/03(火) 17:45:15

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

0387デフォルトの名無しさん

2009/11/03(火) 18:43:21

未来のレスにレスですか

0388デフォルトの名無しさん

2009/11/03(火) 20:33:15

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

0389デフォルトの名無しさん

2009/11/03(火) 22:42:16

ksk

0390デフォルトの名無しさん

2009/11/03(火) 22:51:51

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

0391デフォルトの名無しさん

2009/11/05(木) 10:44:06

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

0392デフォルトの名無しさん

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
こんな解説などが見つかりましたが今ひとつ分かりません。

0393デフォルトの名無しさん

2009/11/05(木) 22:16:16

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

0394デフォルトの名無しさん

2009/11/05(木) 22:21:44

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

0395デフォルトの名無しさん

2009/11/06(金) 06:38:25

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

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

0396デフォルトの名無しさん

2009/11/06(金) 07:00:43

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

0397デフォルトの名無しさん

2009/11/06(金) 08:28:40

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

0398デフォルトの名無しさん

2009/11/06(金) 09:42:53

> スクリプト言語の仕様

頭おかしい人ですか?

0399デフォルトの名無しさん

2009/11/06(金) 15:17:26

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

0400デフォルトの名無しさん

2009/11/06(金) 16:08:27

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

0401デフォルトの名無しさん

2009/11/06(金) 17:45:40

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

0402デフォルトの名無しさん

2009/11/06(金) 18:00:27

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

0403デフォルトの名無しさん

2009/11/06(金) 18:08:14

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

0404デフォルトの名無しさん

2009/11/06(金) 18:33:45

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

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

]", date, length);

0405デフォルトの名無しさん

2009/11/06(金) 20:00:49

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

0406デフォルトの名無しさん

2009/11/06(金) 20:06:29

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

0407デフォルトの名無しさん

2009/11/06(金) 20:07:27

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

0408デフォルトの名無しさん

2009/11/06(金) 20:18:11

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

0409デフォルトの名無しさん

2009/11/07(土) 02:39:06

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

0410デフォルトの名無しさん

2009/11/07(土) 13:15:38

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

0411デフォルトの名無しさん

2009/11/07(土) 13:30:00

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

0412デフォルトの名無しさん

2009/11/07(土) 14:00:19

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

0413デフォルトの名無しさん

2009/11/07(土) 14:38:04

[&]

0414デフォルトの名無しさん

2009/11/07(土) 14:42:31

[[笑]]

0415デフォルトの名無しさん

2009/11/07(土) 15:47:31

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

0416デフォルトの名無しさん

2009/11/07(土) 15:51:49

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

0417デフォルトの名無しさん

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

0418デフォルトの名無しさん

2009/11/07(土) 19:35:59

4への不満が分からない

0419デフォルトの名無しさん

2009/11/07(土) 19:39:51

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

0420デフォルトの名無しさん

2009/11/07(土) 19:52:44

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

0421デフォルトの名無しさん

2009/11/07(土) 20:02:07

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

0422デフォルトの名無しさん

2009/11/07(土) 20:12:28

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

0423デフォルトの名無しさん

2009/11/07(土) 20:19:19

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

0424デフォルトの名無しさん

2009/11/07(土) 20:47:59

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

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

0425デフォルトの名無しさん

2009/11/07(土) 20:55:39

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

0426デフォルトの名無しさん

2009/11/07(土) 21:02:02

>>410
intrinsicsって何ですか？

0427デフォルトの名無しさん

2009/11/07(土) 22:29:50

__builtin_mallocみたいなの

0428デフォルトの名無しさん

2009/11/07(土) 22:35:14

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

0429デフォルトの名無しさん

2009/11/08(日) 02:55:08

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

0430デフォルトの名無しさん

2009/11/09(月) 12:07:54

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

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

0431デフォルトの名無しさん

2009/11/09(月) 12:51:48

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

0432デフォルトの名無しさん

2009/11/09(月) 12:59:23

馬鹿にはよくあること

0433デフォルトの名無しさん

2009/11/09(月) 16:39:59

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

0434デフォルトの名無しさん

2009/11/09(月) 20:44:51

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

0435デフォルトの名無しさん

2009/11/10(火) 18:51:22

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

0436デフォルトの名無しさん

2009/11/10(火) 19:59:22

Post Santa Cruz mailingﾏｰﾀﾞｰ?

0437デフォルトの名無しさん

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

0438デフォルトの名無しさん

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

0439デフォルトの名無しさん

2009/11/12(木) 21:38:57

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

0440デフォルトの名無しさん

2009/11/12(木) 21:50:54

郷の人気で吹っ飛ぶ鴨な

0441デフォルトの名無しさん

2009/11/12(木) 23:16:01

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

0442デフォルトの名無しさん

2009/11/12(木) 23:34:17

>>441
なぜ？

0443デフォルトの名無しさん

2009/11/12(木) 23:39:01

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

0444デフォルトの名無しさん

2009/11/12(木) 23:41:29

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

0445デフォルトの名無しさん

2009/11/12(木) 23:42:15

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

0446デフォルトの名無しさん

2009/11/12(木) 23:42:41

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

0447デフォルトの名無しさん

2009/11/12(木) 23:44:48

もなか？

0448デフォルトの名無しさん

2009/11/12(木) 23:50:13

11月号来た

0449デフォルトの名無しさん

2009/11/12(木) 23:53:05

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

0450デフォルトの名無しさん

2009/11/13(金) 00:01:16

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

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

0451デフォルトの名無しさん

2009/11/13(金) 00:08:13

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

0452デフォルトの名無しさん

2009/11/13(金) 00:35:19

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

0453デフォルトの名無しさん

2009/11/13(金) 00:43:04

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

0454デフォルトの名無しさん

2009/11/13(金) 01:08:00

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

0455デフォルトの名無しさん

2009/11/13(金) 01:43:40

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

0456デフォルトの名無しさん

2009/11/13(金) 01:51:02

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

0457デフォルトの名無しさん

2009/11/13(金) 01:52:57

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

0458デフォルトの名無しさん

2009/11/13(金) 03:45:52

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

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

0459デフォルトの名無しさん

2009/11/13(金) 05:05:48

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

0460デフォルトの名無しさん

2009/11/13(金) 08:15:14

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

0461デフォルトの名無しさん

2009/11/13(金) 10:53:10

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

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

0462デフォルトの名無しさん

2009/11/13(金) 10:55:36

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

0463デフォルトの名無しさん

2009/11/13(金) 11:02:19

それがGCなんだが

0464デフォルトの名無しさん

2009/11/13(金) 11:03:19

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

0465デフォルトの名無しさん

2009/11/13(金) 11:10:35

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

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

0466デフォルトの名無しさん

2009/11/13(金) 11:25:41

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

0467デフォルトの名無しさん

2009/11/13(金) 11:33:38

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

0468デフォルトの名無しさん

2009/11/13(金) 16:57:11

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

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

0469デフォルトの名無しさん

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はどうなるんだろうね。

0470デフォルトの名無しさん

2009/11/13(金) 17:38:37

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

0471デフォルトの名無しさん

2009/11/13(金) 18:01:51

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

0472デフォルトの名無しさん

2009/11/13(金) 18:04:48

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

0473デフォルトの名無しさん

2009/11/13(金) 18:40:54

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

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

0474デフォルトの名無しさん

2009/11/13(金) 21:29:40

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

0475デフォルトの名無しさん

2009/11/13(金) 21:32:03

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

0476デフォルトの名無しさん

2009/11/13(金) 21:35:34

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

0477デフォルトの名無しさん

2009/11/13(金) 21:40:16

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

0478デフォルトの名無しさん

2009/11/13(金) 21:50:03

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

0479デフォルトの名無しさん

2009/11/13(金) 21:50:25

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

0480デフォルトの名無しさん

2009/11/13(金) 23:20:40

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

0481デフォルトの名無しさん

2009/11/13(金) 23:30:58

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

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

0482デフォルトの名無しさん

2009/11/13(金) 23:38:40

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

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

0483デフォルトの名無しさん

2009/11/14(土) 05:04:54

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

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

0484デフォルトの名無しさん

2009/11/14(土) 05:15:05

alloca

0485デフォルトの名無しさん

2009/11/14(土) 05:55:07

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

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

0486デフォルトの名無しさん

2009/11/14(土) 10:31:27

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

0487デフォルトの名無しさん

2009/11/14(土) 10:34:32

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

0488デフォルトの名無しさん

2009/11/14(土) 10:39:13

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

0489デフォルトの名無しさん

2009/11/14(土) 11:03:30

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

0490デフォルトの名無しさん

2009/11/14(土) 11:05:52

馬鹿発見

0491デフォルトの名無しさん

2009/11/14(土) 11:14:59

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

0492デフォルトの名無しさん

2009/11/14(土) 11:19:56

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

0493デフォルトの名無しさん

2009/11/14(土) 11:25:38

>>489
俺もそれは思う。

だが！

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

0494デフォルトの名無しさん

2009/11/14(土) 17:34:00

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

0495デフォルトの名無しさん

2009/11/14(土) 17:40:25

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

0496デフォルトの名無しさん

2009/11/14(土) 17:46:50

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

0497デフォルトの名無しさん

2009/11/14(土) 18:49:58

お前らスレチ！

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

0498デフォルトの名無しさん

2009/11/14(土) 18:51:36

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

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

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

0499デフォルトの名無しさん

2009/11/14(土) 19:21:05

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

0500デフォルトの名無しさん

2009/11/14(土) 19:32:10

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

0501デフォルトの名無しさん

2009/11/14(土) 21:13:36

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

0502デフォルトの名無しさん

2009/11/16(月) 12:19:26

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

0503デフォルトの名無しさん

2009/11/16(月) 12:53:26

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

0504デフォルトの名無しさん

2009/11/16(月) 12:54:23

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

0505デフォルトの名無しさん

2009/11/16(月) 17:09:26

#define gcnew うんたらかんたら

0506デフォルトの名無しさん

2009/11/16(月) 17:18:30

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

0507デフォルトの名無しさん

2009/11/16(月) 17:31:17

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

あとスレチ

0508デフォルトの名無しさん

2009/11/16(月) 18:17:23

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

0509デフォルトの名無しさん

2009/11/16(月) 21:12:35

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

0510デフォルトの名無しさん

2009/11/16(月) 21:27:58

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

0511デフォルトの名無しさん

2009/11/16(月) 22:01:15

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

0512デフォルトの名無しさん

2009/11/16(月) 22:07:37

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

0513デフォルトの名無しさん

2009/11/16(月) 22:10:50

もっとメモリをください

0514デフォルトの名無しさん

2009/11/16(月) 22:13:47

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

0515デフォルトの名無しさん

2009/11/16(月) 22:19:26

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

0516デフォルトの名無しさん

2009/11/16(月) 22:24:28

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

0517デフォルトの名無しさん

2009/11/16(月) 22:38:25

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

0518デフォルトの名無しさん

2009/11/16(月) 23:40:30

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

0519デフォルトの名無しさん

2009/11/16(月) 23:43:20

急降下

0520デフォルトの名無しさん

2009/11/17(火) 00:55:46

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

0521デフォルトの名無しさん

2009/11/17(火) 03:23:37

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

0522デフォルトの名無しさん

2009/11/17(火) 16:49:13

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

0523デフォルトの名無しさん

2009/11/17(火) 18:29:50

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

0524デフォルトの名無しさん

2009/11/17(火) 18:47:46

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

0525デフォルトの名無しさん

2009/11/17(火) 19:04:20

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

0526デフォルトの名無しさん

2009/11/17(火) 19:10:18

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

0527デフォルトの名無しさん

2009/11/17(火) 19:15:45

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

0528デフォルトの名無しさん

2009/11/17(火) 19:49:13

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

0529デフォルトの名無しさん

2009/11/17(火) 19:51:07

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

0530デフォルトの名無しさん

2009/11/17(火) 20:23:35

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

0531デフォルトの名無しさん

2009/11/17(火) 20:24:34

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

0532デフォルトの名無しさん

2009/11/17(火) 20:24:43

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

0533529

2009/11/17(火) 20:42:11

s/思/言/

0534デフォルトの名無しさん

2009/11/17(火) 21:54:43

思うだけならタダ

0535デフォルトの名無しさん

2009/11/18(水) 00:50:24

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

0536デフォルトの名無しさん

2009/11/18(水) 01:08:56

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

0537デフォルトの名無しさん

2009/11/18(水) 01:20:45

意義？

異議だろ

出直して来い

0538デフォルトの名無しさん

2009/11/18(水) 12:28:29

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

0539デフォルトの名無しさん

2009/11/18(水) 13:09:44

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

0540デフォルトの名無しさん

2009/11/18(水) 13:15:29

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

0541デフォルトの名無しさん

2009/11/18(水) 17:52:58

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

0542デフォルトの名無しさん

2009/11/18(水) 18:08:35

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

0543デフォルトの名無しさん

2009/11/18(水) 18:16:43

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

0544デフォルトの名無しさん

2009/11/18(水) 20:40:25

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

0545デフォルトの名無しさん

2009/11/18(水) 21:30:23

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

0546542

2009/11/18(水) 23:11:07

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

0547デフォルトの名無しさん

2009/11/21(土) 23:52:40

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

0548デフォルトの名無しさん

2009/11/22(日) 00:07:56

int foo = 1;
auto &bar = foo;

これに何か不満が？

0549デフォルトの名無しさん

2009/11/22(日) 00:24:29

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

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

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

0550デフォルトの名無しさん

2009/11/22(日) 00:25:21

誤：unsined
正：unsigned

0551デフォルトの名無しさん

2009/11/23(月) 07:44:03

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

0552デフォルトの名無しさん

2009/11/23(月) 07:50:00

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

0553デフォルトの名無しさん

2009/11/23(月) 10:56:35

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

0554デフォルトの名無しさん

2009/11/23(月) 11:06:44

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

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

0555デフォルトの名無しさん

2009/11/23(月) 11:09:00

*だって別の意味に…

0556デフォルトの名無しさん

2009/11/23(月) 11:12:27

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

0557デフォルトの名無しさん

2009/11/23(月) 11:30:45

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

0558デフォルトの名無しさん

2009/11/23(月) 12:59:40

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

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

0559デフォルトの名無しさん

2009/11/23(月) 13:05:44

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

0560デフォルトの名無しさん

2009/11/23(月) 13:10:13

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

0561デフォルトの名無しさん

2009/11/23(月) 13:20:29

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

0562デフォルトの名無しさん

2009/11/23(月) 13:31:40

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

0563デフォルトの名無しさん

2009/11/23(月) 13:35:29

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

0564デフォルトの名無しさん

2009/11/23(月) 13:35:51

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

0565デフォルトの名無しさん

2009/11/23(月) 13:43:18

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

とか書きたかった？

0566デフォルトの名無しさん

2009/11/23(月) 13:48:43

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

0567デフォルトの名無しさん

2009/11/23(月) 13:51:12

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

0568デフォルトの名無しさん

2009/11/23(月) 13:53:46

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

0569デフォルトの名無しさん

2009/11/23(月) 13:53:48

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

0570デフォルトの名無しさん

2009/11/23(月) 13:54:38

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

0571デフォルトの名無しさん

2009/11/23(月) 13:58:22

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

0572デフォルトの名無しさん

2009/11/23(月) 13:59:35

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

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

0573デフォルトの名無しさん

2009/11/23(月) 14:01:56

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

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

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

0574デフォルトの名無しさん

2009/11/23(月) 14:02:58

間違えた w

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

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

0575デフォルトの名無しさん

2009/11/23(月) 14:03:36

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

0576デフォルトの名無しさん

2009/11/23(月) 14:05:57

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

0577デフォルトの名無しさん

2009/11/23(月) 14:08:19

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

0578デフォルトの名無しさん

2009/11/23(月) 14:09:13

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

0579デフォルトの名無しさん

2009/11/23(月) 14:10:05

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

0580デフォルトの名無しさん

2009/11/23(月) 14:10:46

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

0581デフォルトの名無しさん

2009/11/23(月) 14:11:46

>>568
いや
それはない

0582デフォルトの名無しさん

2009/11/23(月) 14:15:02

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

0583デフォルトの名無しさん

2009/11/23(月) 14:44:30

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

0584デフォルトの名無しさん

2009/11/23(月) 14:44:57

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

0585デフォルトの名無しさん

2009/11/23(月) 14:46:53

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

0586デフォルトの名無しさん

2009/11/23(月) 21:29:46

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

0587デフォルトの名無しさん

2009/11/23(月) 21:33:07

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

0588デフォルトの名無しさん

2009/11/23(月) 23:00:43

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

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

0589デフォルトの名無しさん

2009/11/23(月) 23:06:01

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

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

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

0590デフォルトの名無しさん

2009/11/23(月) 23:07:57

589は何も分かってないな

0591デフォルトの名無しさん

2009/11/23(月) 23:10:51

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

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

0592デフォルトの名無しさん

2009/11/23(月) 23:28:14

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

0593デフォルトの名無しさん

2009/11/23(月) 23:32:55

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

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

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

void f(int& x);

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

0594デフォルトの名無しさん

2009/11/23(月) 23:33:34

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

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

0595デフォルトの名無しさん

2009/11/23(月) 23:34:49

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

0596デフォルトの名無しさん

2009/11/23(月) 23:37:30

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

0597デフォルトの名無しさん

2009/11/23(月) 23:41:46

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

0598デフォルトの名無しさん

2009/11/23(月) 23:43:00

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

0599デフォルトの名無しさん

2009/11/23(月) 23:44:09

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

0600デフォルトの名無しさん

2009/11/23(月) 23:46:14

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

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

0601デフォルトの名無しさん

2009/11/23(月) 23:46:27

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

0602デフォルトの名無しさん

2009/11/23(月) 23:49:30

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

0603デフォルトの名無しさん

2009/11/23(月) 23:49:57

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

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

0604デフォルトの名無しさん

2009/11/23(月) 23:50:09

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

0605デフォルトの名無しさん

2009/11/23(月) 23:51:21

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

0606デフォルトの名無しさん

2009/11/23(月) 23:51:27

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

0607デフォルトの名無しさん

2009/11/23(月) 23:59:06

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

0608デフォルトの名無しさん

2009/11/23(月) 23:59:38

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

0609デフォルトの名無しさん

2009/11/24(火) 00:01:44

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

0610デフォルトの名無しさん

2009/11/24(火) 00:02:00

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

0611デフォルトの名無しさん

2009/11/24(火) 00:19:40

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

0612デフォルトの名無しさん

2009/11/24(火) 00:20:20

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

0613デフォルトの名無しさん

2009/11/24(火) 00:31:10

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

0614デフォルトの名無しさん

2009/11/24(火) 00:33:53

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

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

0615デフォルトの名無しさん

2009/11/24(火) 00:39:08

unkosure

0616デフォルトの名無しさん

2009/11/24(火) 00:41:04

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

0617デフォルトの名無しさん

2009/11/24(火) 00:41:04

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

>>455
これは好きだ。

0618デフォルトの名無しさん

2009/11/24(火) 02:48:40

>>602に禿しく同意

0619デフォルトの名無しさん

2009/11/25(水) 06:00:10

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

0620デフォルトの名無しさん

2009/11/25(水) 07:04:52

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

0621デフォルトの名無しさん

2009/11/25(水) 07:30:01

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

0622デフォルトの名無しさん

2009/11/25(水) 07:33:40

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

0623デフォルトの名無しさん

2009/11/25(水) 07:37:29

バグも合理的なのか。

0624デフォルトの名無しさん

2009/11/25(水) 07:41:03

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

0625デフォルトの名無しさん

2009/11/25(水) 07:44:24

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

0626デフォルトの名無しさん

2009/11/25(水) 07:47:02

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

0627デフォルトの名無しさん

2009/11/25(水) 07:51:05

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

0628デフォルトの名無しさん

2009/11/25(水) 07:58:40

＾ｑ＾

0629デフォルトの名無しさん

2009/11/25(水) 07:58:44

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

0630デフォルトの名無しさん

2009/11/25(水) 08:01:49

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

0631デフォルトの名無しさん

2009/11/25(水) 12:12:20

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

0632デフォルトの名無しさん

2009/11/25(水) 21:05:12

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

0633デフォルトの名無しさん

2009/11/25(水) 21:09:08

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

0634デフォルトの名無しさん

2009/11/25(水) 21:52:38

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

0635デフォルトの名無しさん

2009/11/25(水) 22:30:57

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

0636デフォルトの名無しさん

2009/11/25(水) 22:40:04

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

0637デフォルトの名無しさん

2009/11/25(水) 22:58:31

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

0638デフォルトの名無しさん

2009/11/25(水) 23:05:30

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

0639デフォルトの名無しさん

2009/11/26(木) 08:42:31

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

0640デフォルトの名無しさん

2009/11/26(木) 10:39:32

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

0641デフォルトの名無しさん

2009/11/26(木) 10:52:41

スレ違い

0642デフォルトの名無しさん

2009/11/26(木) 10:53:22

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

0643デフォルトの名無しさん

2009/11/26(木) 11:45:26

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

0644デフォルトの名無しさん

2009/11/26(木) 12:01:56

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

0645デフォルトの名無しさん

2009/11/26(木) 12:31:59

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

0646デフォルトの名無しさん

2009/11/26(木) 12:36:20

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

0647デフォルトの名無しさん

2009/11/26(木) 12:36:52

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

0648デフォルトの名無しさん

2009/11/26(木) 12:39:20

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

0649デフォルトの名無しさん

2009/11/26(木) 12:43:25

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

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

0650デフォルトの名無しさん

2009/11/26(木) 14:47:54

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

0651デフォルトの名無しさん

2009/11/26(木) 15:05:09

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

0652デフォルトの名無しさん

2009/11/26(木) 15:05:48

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

0653デフォルトの名無しさん

2009/11/26(木) 16:39:51

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

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

0654デフォルトの名無しさん

2009/11/26(木) 16:54:20

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

0655デフォルトの名無しさん

2009/11/26(木) 18:07:04

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

0656デフォルトの名無しさん

2009/11/26(木) 18:18:07

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

0657デフォルトの名無しさん

2009/11/26(木) 21:06:24

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

0658デフォルトの名無しさん

2009/11/26(木) 21:53:24

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

0659デフォルトの名無しさん

2009/11/26(木) 22:01:39

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

0660デフォルトの名無しさん

2009/11/26(木) 22:55:20

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

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

0661659

2009/11/26(木) 23:06:43

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

0662660

2009/11/26(木) 23:16:06

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

0663デフォルトの名無しさん

2009/11/27(金) 02:21:42

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

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

0664デフォルトの名無しさん

2009/11/27(金) 02:36:59

なこたない。適材適所

0665デフォルトの名無しさん

2009/11/27(金) 02:56:32

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

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

0666デフォルトの名無しさん

2009/11/27(金) 03:27:13

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

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

0667デフォルトの名無しさん

2009/11/27(金) 03:29:21

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

0668デフォルトの名無しさん

2009/11/27(金) 03:48:23

俺のはCだよ

0669デフォルトの名無しさん

2009/11/27(金) 09:03:09

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

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

0670デフォルトの名無しさん

2009/11/27(金) 10:42:27

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

0671デフォルトの名無しさん

2009/11/27(金) 11:32:33

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

0672デフォルトの名無しさん

2009/11/27(金) 11:47:03

goで作れ

0673デフォルトの名無しさん

2009/11/27(金) 11:54:06

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

0674デフォルトの名無しさん

2009/11/27(金) 13:20:02

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

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

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

0675デフォルトの名無しさん

2009/11/27(金) 13:35:19

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

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

0676デフォルトの名無しさん

2009/11/27(金) 13:39:54

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

0677デフォルトの名無しさん

2009/11/27(金) 13:43:53

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

0678デフォルトの名無しさん

2009/11/27(金) 13:45:18

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

0679デフォルトの名無しさん

2009/11/27(金) 13:58:24

判断できないなら使うな

0680デフォルトの名無しさん

2009/11/27(金) 14:06:28

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

0681デフォルトの名無しさん

2009/11/27(金) 14:22:24

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

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

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

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

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

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

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

0682デフォルトの名無しさん

2009/11/27(金) 14:24:31

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

0683デフォルトの名無しさん

2009/11/27(金) 14:38:26

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

0684デフォルトの名無しさん

2009/11/27(金) 14:38:34

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

0685デフォルトの名無しさん

2009/11/27(金) 15:00:05

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

0686デフォルトの名無しさん

2009/11/27(金) 15:13:00

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

0687デフォルトの名無しさん

2009/11/27(金) 15:23:31

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

0688デフォルトの名無しさん

2009/11/27(金) 15:25:53

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

0689デフォルトの名無しさん

2009/11/27(金) 15:44:38

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

0690デフォルトの名無しさん

2009/11/27(金) 15:58:23

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

0691デフォルトの名無しさん

2009/11/27(金) 15:58:55

×紗江
○さえ

0692デフォルトの名無しさん

2009/11/27(金) 16:03:34

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

0693デフォルトの名無しさん

2009/11/27(金) 16:45:09

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

0694デフォルトの名無しさん

2009/11/27(金) 16:57:11

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

0695デフォルトの名無しさん

2009/11/27(金) 17:43:16

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

0696デフォルトの名無しさん

2009/11/27(金) 17:56:51

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

0697デフォルトの名無しさん

2009/11/27(金) 17:58:55

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

0698デフォルトの名無しさん

2009/11/27(金) 18:40:25

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

0699デフォルトの名無しさん

2009/11/28(土) 01:02:20

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

0700デフォルトの名無しさん

2009/11/28(土) 03:21:38

VC2010でtemplate<class T, T N> struct ...ってできるけどこれって独自拡張？

0701デフォルトの名無しさん

2009/11/28(土) 10:00:50

え、今まで普通に使ってきたんだがMSの独自拡張だったんか・・・orz

0702デフォルトの名無しさん

2009/11/28(土) 10:03:15

>>701
まて、それだと
そのソースはWindows以外では使えないソースってことか？

・・・まあそう気を落とすな。

0703デフォルトの名無しさん

2009/11/28(土) 10:14:16

T が何型かわかるまで保留でいいと思うが・・・

0704デフォルトの名無しさん

2009/11/28(土) 10:45:29

>>700
違うと思う。boostでも使われてるし。
http://www.boost.org/doc/libs/1_41_0/boost/non_type.hpp

0705デフォルトの名無しさん

2009/11/28(土) 10:59:20

>>704
その
template <typename T, T n>
struct non_type { };
って何に使うんでしょうか？

0706デフォルトの名無しさん

2009/11/28(土) 11:26:12

組み込みで良く使われたQtとかSymbianとかがC++だけどどっちもオープンソース。
というか下位レイヤがクローズドソースのC++だと死ねる。仕様書もUMLも隠し、ドキュメントも不十分とか止めれ本当。

0707デフォルトの名無しさん

2009/11/28(土) 11:29:19

>>706
いきなり何の話をし始めるw
？

0708デフォルトの名無しさん

2009/11/28(土) 17:50:17

何で、Embedded C++にしつこく反応する。馬鹿か

0709デフォルトの名無しさん

2009/11/28(土) 18:08:15

shadow replying?

0710デフォルトの名無しさん

2009/11/28(土) 18:56:00

C++0xがなんのことか知らなくて、ただのC++スレと勘違いして来てる奴がいそうな気がする。

0711デフォルトの名無しさん

2009/11/28(土) 21:30:38

>>710
このスレをC++ 0x7と思ってるとかな

0712デフォルトの名無しさん

2009/11/28(土) 21:39:45

【次期規格】とか付けた方がいいのかねえ

0713デフォルトの名無しさん

2009/11/28(土) 21:52:33

C++プログラマならC++0xの存在は常識だと
思っていたのだが、そうでもなかったりするのか？

0714デフォルトの名無しさん

2009/11/29(日) 00:18:35

C++の次期機能の存在どころか…

0715デフォルトの名無しさん

2009/11/29(日) 00:29:21

ピンからキリまでいますからね

0716デフォルトの名無しさん

2009/11/29(日) 01:11:20

HTML5スレでも同じような話を見たなあ。
次期規格「HTML5」のスレなのに、HTMLスレのパート5と認識している奴がいるのでは？という話。

0717デフォルトの名無しさん

2009/11/29(日) 01:12:31

正式決定までドライでいたいし、そうあるべきだとも思う
戦いはそれから

次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている
スーパーセットの皮を被った本当はサブセット
へたするとテンプレートと C++ コアで機能拡大しながらその実簡素化という舵を切ってくれることを期待してる

テンプレート型のテンプレート引数で柔軟性を飛躍的に向上させた列概念を待っている

0718デフォルトの名無しさん

2009/11/29(日) 01:19:21

俺が会社でC++0xの話題を振ったところ意味がわかるのは20人中2人だった

0719デフォルトの名無しさん

2009/11/29(日) 02:53:55

>>700,701
遅レスだけどC++標準の仕様だよ。もちろん0x以前でも。

boost::non_type は何に使うのかようわからんけど、
boost::mpl::integral_c<T, N> で型として扱える定数をつくったりとか。

0720デフォルトの名無しさん

2009/11/29(日) 03:10:19

来年になったら、C++1xって呼ぶの？

0721デフォルトの名無しさん

2009/11/29(日) 03:12:44

来年限定で C++x0 (嘘)

0722デフォルトの名無しさん

2009/11/29(日) 04:39:41

Cは最初からC1xって呼んでるんだよな。

0723デフォルトの名無しさん

2009/11/29(日) 05:16:29

それは標準化委員会のやる気がないから

0724デフォルトの名無しさん

2009/11/29(日) 08:09:35

来年だったら　C++0A だから 0xでおｋ

0725デフォルトの名無しさん

2009/11/29(日) 08:11:17

だからそれは8進数リテラルだと……

0726デフォルトの名無しさん

2009/11/29(日) 08:39:29

C++0Z の次は C++0a ですね

0727デフォルトの名無しさん

2009/11/29(日) 09:04:56

>>726
そのうちコインやら王冠が出てきそうだな

0728デフォルトの名無しさん

2009/11/29(日) 10:10:42

>>727
それ何てマr ・・・うわなにをするやめ

0729デフォルトの名無しさん

2009/11/29(日) 12:54:23

>>717
> 次の規格はテンプレの理不尽さをもっと合理的にまとめてくれると希望的観測をしている

ドラフト読めよw

0730デフォルトの名無しさん

2009/11/29(日) 13:05:15

Wikipedia の仏語版だけ項目の見出しが C++1x という表記になってる。

0731デフォルトの名無しさん

2009/11/29(日) 13:21:35

エスプリってやつなんですね。

0732デフォルトの名無しさん

2009/11/29(日) 13:46:59

>>726
base64 だけであと 54年持つなw

0733デフォルトの名無しさん

2009/11/29(日) 14:09:18

64進数リテラルか。

0734デフォルトの名無しさん

2009/11/29(日) 20:58:40

base64だと0xは3377年。
範囲ではなく具体的な制定年を指定ということでは？

0735デフォルトの名無しさん

2009/11/29(日) 21:06:22

>>734
そうなのか！それなら今のペースでも余裕で間に合うな！

0736デフォルトの名無しさん

2009/11/29(日) 21:35:13

人類滅んでそうｗ

0737734

2009/11/29(日) 21:41:54

間違えたよ。リトルエンディアンで4307年、ビッグエンディアンで54032年

0738デフォルトの名無しさん

2009/11/29(日) 21:57:45

年号じゃなくてバージョン番号で命名すれば
何の問題ないのに、みんなバカなのか？

0739デフォルトの名無しさん

2009/11/29(日) 22:23:32

>>738
ドキュメントのバージョンが細かく上がってくからそういう風になったんでない？
ここで切りましょう。的な。

0740デフォルトの名無しさん

2009/11/29(日) 22:50:03

>>738
C++0xで何か問題でも起こりますか？

0741デフォルトの名無しさん

2009/11/29(日) 23:06:13

>>740
2100年問題が起きるだろ……

0742デフォルトの名無しさん

2009/11/29(日) 23:12:30

ハッシュで名前つければかぶらないよ。

0743デフォルトの名無しさん

2009/11/30(月) 11:07:46

ゴムを被せれば、ですね。わかります

0744デフォルトの名無しさん

2009/11/30(月) 11:15:06

そろそろマヤ歴を解読してC++0xが完成する日時を割り出す人とか出てきそう。

0745デフォルトの名無しさん

2009/11/30(月) 16:11:37

久々にC++0xの話題が続いてるな！

0746デフォルトの名無しさん

2009/11/30(月) 17:24:54

constexprで算出した値ってtemplate引数に渡せられる？

0747デフォルトの名無しさん

2009/11/30(月) 17:26:36

>>746
それが constexpr の目的の一つ。

0748デフォルトの名無しさん

2009/11/30(月) 18:11:34

>>745
気のせいだろ。

0749デフォルトの名無しさん

2009/11/30(月) 21:09:01

やっとnumeric_limits::maxが静的になるんですね！

0750デフォルトの名無しさん

2009/11/30(月) 21:18:20

つ boost::integer_traits::const_max

0751デフォルトの名無しさん

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を書かなくて済むと思うんだけどあってる？

0752デフォルトの名無しさん

2009/12/07(月) 14:51:44

あってる。
どうでもいいがVC10betaは本当に0xの役に立つ機能だけごっそり実装されてなくて悲しくなってくるな。

0753デフォルトの名無しさん

2009/12/07(月) 20:49:44

VC10はauto、lambda、右辺値参照がサポートされているだけでも嬉しい。
VC9はスルーしていまだにVC8だけど、VC10は買うよ。

0754デフォルトの名無しさん

2009/12/07(月) 20:57:41

VC10はdecltypeがないんだっけ

0755デフォルトの名無しさん

2009/12/07(月) 21:23:02

beta2使ってるが既にあｒう

0756デフォルトの名無しさん

2009/12/07(月) 22:41:41

decltype(*this)ってやると落ちるけどな

0757デフォルトの名無しさん

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 について２回発生する副作用がお互いに sequenced となれば
いいようですが、式中の２つの関数呼び出し内にある副作用についての
sequencing がどうなるのか、よくわかりませんでした。上記の記述に続く
"When calling a function ..." で説明されている気配はあるのですが。

「元々結果が定まらなかったんだから、こっそり未定義に格下げしたって
　だれも困りゃしねーよ。」
とかいう話になってたりしないか心配です。

0758デフォルトの名無しさん

2009/12/08(火) 19:03:10

>>757
今までもこれからも、処理系定義だと
思ってたけど、違うの？

0759デフォルトの名無しさん

2009/12/08(火) 21:06:19

>>757
質問なのですが、標準C++ 2003において、
　static int x;
　(++x)+(++x)
これは未定義の動作ですよね？
ところが
　int f() { static int x; return ++x; }
　f() + f()
は
　> 関数呼び出しに伴うシーケンスポイントがあるので
不定の動作になるということでしょうか？
（つまり一応動作はするということでしょうか？）

0760デフォルトの名無しさん

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.

0761デフォルトの名無しさん

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() とか

0762デフォルトの名無しさん

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 なので制約が緩くなってると考えてもいいんじゃないかな。

0763759

2009/12/08(火) 23:24:11

>>761
おっしゃるとおり、
前値と後置を間違えていたようです。
(++x)+(++x)の結果はいつも同じになるのですね。

>(x++)+(x++) ならコンパイラ依存だけど
こちらは未定義の動作ということでよろしいでしょうか？

0764デフォルトの名無しさん

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 を示唆する気もする。

0765デフォルトの名無しさん

2009/12/08(火) 23:51:25

俺も
(++x)+(++x)はundefined behaviorだったと思うんだけど。

> f(i = -1, i = -1); // the behavior is undefined
は知らなかった。ありがとう。

やっぱC/C++言語って難しい。

0766761

2009/12/09(水) 00:32:29

>>764
ごめん、嘘つきだった. おっしゃるとおり、2回変更してるからアウトです
へんにまぜっかえしてしまってもうしわけない

0767デフォルトの名無しさん

2009/12/09(水) 00:52:32

>>761
(++x)+(++x)も未定義。
「どちらから評価するか」が決まっていないのではないよ。

0768757

2009/12/09(水) 01:40:13

>>762
> 一方、他に特に明示されていない場合は、関数の実行と(呼び出し側の)その他の評価との間は indeterminately sequenced

片方の f() が呼び出された際の ++x と、その外にあるもう一方の f() 呼び出しとの
関係を見れば indeterminately sequenced になるということですね。

片方の f() ともう一方の f() とが unsequenced なので、それぞれの中にある２つの
++x について見ても unsequenced になるんじゃ・・・と思ってましたが、従来どおりという
ことで安心しました。ありがとうございました。

0769デフォルトの名無しさん

2009/12/10(木) 00:28:10

そんなコード書くなと思うのは俺だけか？

0770デフォルトの名無しさん

2009/12/10(木) 10:21:12

auto_ptrはこういう文法にすべき。
classA * auto ptr = classA(1, 2, 3);

0771デフォルトの名無しさん

2009/12/10(木) 16:29:14

一種類しかスマポ使えない世界ですか

0772デフォルトの名無しさん

2009/12/10(木) 16:34:07

梶本裕介ってだれ？

0773デフォルトの名無しさん

2009/12/10(木) 16:47:25

長門かわいい

0774デフォルトの名無しさん

2009/12/10(木) 16:47:55

意味不明

0775デフォルトの名無しさん

2009/12/10(木) 16:58:26

エピステーメーみたいな痛さがあるよねｗ

0776デフォルトの名無しさん

2009/12/10(木) 17:12:13

馬鹿に嫌われるタイプの人ってこと？

0777デフォルトの名無しさん

2009/12/10(木) 17:20:50

ちょっとマ板にスレたててくるわ

0778デフォルトの名無しさん

2009/12/10(木) 17:23:03

スーパープログラマー梶本裕介
http://pc11.2ch.net/test/read.cgi/prog/1260433369/

0779デフォルトの名無しさん

2009/12/12(土) 19:08:07

>>770
それはどんな動作を期待しとるん？
コピーなん？参照なん？

0780770

2009/12/12(土) 19:51:30

classA * auto ptr = new classA(1, 2, 3);
newを忘れてた。

0781デフォルトの名無しさん

2009/12/12(土) 20:12:13

型修飾子をオーバーロードするとカオスになるから

0782デフォルトの名無しさん

2009/12/12(土) 20:52:40

文法を変えずに、スマポが実装できるのがC++のいい所なのになあ。

0783デフォルトの名無しさん

2009/12/12(土) 23:26:13

生ポインタもライブラリにすべき。
ptr<int> p(new int(0));

0784デフォルトの名無しさん

2009/12/12(土) 23:59:39

むしろ * 演算子を無くして、全部 ptr<T> にすべきだと思う

0785デフォルトの名無しさん

2009/12/13(日) 00:02:17

const ref<array<ptr<int> > > a;

0786デフォルトの名無しさん

2009/12/13(日) 00:59:12

ここで1引数の場合は<>を省略できるルールを……

0787デフォルトの名無しさん

2009/12/13(日) 06:06:06

むしろこうなる悪寒。ドツボ
const std::ref<std::array<std::ptr<int> > > a;

0788デフォルトの名無しさん

2009/12/13(日) 06:27:24

Template typedefs あるし

0789デフォルトの名無しさん

2009/12/13(日) 06:41:34

何でみんな array に要素数を書かないの？

0790デフォルトの名無しさん

2009/12/13(日) 07:22:14

配列の要素数が10以下なら
要素数を省略できるんだよ

0791デフォルトの名無しさん

2009/12/13(日) 09:00:42

別にtemplate <typename T> class ptrを定義したっていいんだぞ
あと>>770は論外っつーかスマポをガチで使ったことねーだろ

0792770

2009/12/13(日) 09:29:58

コンパイラにとっては* autoくらいなんでもないくらい簡単だよ。

0793デフォルトの名無しさん

2009/12/13(日) 09:48:45

子供は外で遊んでなさい

0794デフォルトの名無しさん

2009/12/13(日) 10:47:05

お前はintrusive_ptrみたいなのやweak_ptrみたいなのが欲しい時にどうするつもりなんだよ

0795デフォルトの名無しさん

2009/12/13(日) 10:50:54

だだをこねる

0796デフォルトの名無しさん

2009/12/13(日) 10:54:02

ユーザー定義リテラル(だっけ？)が 0x では出来るんだから、
ユーザー定義ポインタが出来てもいいんでは。
T * hogehoge を hogehoge_ptr<T> に変換とか。

0797デフォルトの名無しさん

2009/12/13(日) 10:56:21

アホは発言を控えて！

0798デフォルトの名無しさん

2009/12/13(日) 11:01:59

>>797がいいこと言ったｗ

0799デフォルトの名無しさん

2009/12/13(日) 11:03:13

バカは自分のつまらない思い付きに興奮して固執するから困る

0800デフォルトの名無しさん

2009/12/13(日) 11:05:15

ユーザー定義リテラルさんは
>>6
で酷評されているw

0801デフォルトの名無しさん

2009/12/13(日) 11:06:12

まぁ、間違ったアイディアに囚われることは誰でもある
それに気付いて軌道修正できない奴は駄目だが

0802デフォルトの名無しさん

2009/12/13(日) 11:25:49

>>800
registerさんのイメチェンは何が良い？

0803デフォルトの名無しさん

2009/12/13(日) 12:12:11

registerさんはなんか将来もっと役立ちそうなところで使われるべき。

・・・それが何かはまだ思いつかないけどねw

0804デフォルトの名無しさん

2009/12/13(日) 12:24:09

autoさんってどんなところで出て来るんですか？？

0805デフォルトの名無しさん

2009/12/13(日) 12:44:59

ラムダ式扱うときにとか使うかもしれない
自分はラムダ式自体使ったことないけどね

0806804

2009/12/13(日) 12:48:36

>>805
Boostのラムダとは全然別物っていう代物ですよね確か。

・・・仕様が確定してから勉強しようと思います。

0807デフォルトの名無しさん

2009/12/13(日) 13:42:34

C++は複雑過ぎるから俺言語を作っちゃった方が速い。

0808デフォルトの名無しさん

2009/12/13(日) 13:48:31

何が何より速いんだよ

0809デフォルトの名無しさん

2009/12/13(日) 14:32:59

俺言語さんはDSLスレでも立てて一人でやっててくれ

0810デフォルトの名無しさん

2009/12/13(日) 14:36:02

>>804
std::vector<int> v(10);
for (auto i = v.begin(); i != v.end(); ++i)

イテレータの型名とかもかなりタイプ数減らせる。

0811デフォルトの名無しさん

2009/12/13(日) 14:38:40

>>810
すごいコードですね。
そんな使い方ができるのですね。

0812デフォルトの名無しさん

2009/12/13(日) 15:08:19

どうでもいい言語の表層をいじくり続けるのは
もういい加減にしたいですよ、まったく。
昔はC++コンパイラはC言語のコードを生成してた。
それがC++の仕様変更でできなくなったのなら、
C言語の次期規格C1Xで再びできるようにすればいいではないのか？

0813デフォルトの名無しさん

2009/12/13(日) 15:20:44

>>812
C++ to Cトランスレータがあれば極一部の人に便利ではあるかもしれないけど，
多くの最適化ができなくなるだろうし，
テンプレート回りのコンパイルとかはるかに遅くなるだろうから，
そんな処理系を作る人はいないんじゃないかね．

0814デフォルトの名無しさん

2009/12/13(日) 15:54:32

アホは発言を控えて！

0815デフォルトの名無しさん

2009/12/13(日) 19:08:31

バカは自分のつまらない思い付きに興奮して固執するから困る

0816812

2009/12/13(日) 19:21:25

>>815
C++0xの新機能を提案したヤツのことだろ。

0817デフォルトの名無しさん

2009/12/13(日) 19:53:55

暴れなさんな

0818デフォルトの名無しさん

2009/12/13(日) 20:12:31

逆に、Cのコードを吐くことができなくなるくらい深層をいじったと思えばいい。

0819デフォルトの名無しさん

2009/12/13(日) 20:37:57

というか

Comeauのこと、時々でいいから思い出してください

0820デフォルトの名無しさん

2009/12/13(日) 20:54:55

>>812 に Cfront0x でも作ってもらおうぜ

0821デフォルトの名無しさん

2009/12/13(日) 23:43:28

>>796
いらねーよ、そんなのw
ユーザ定義ポインタ(smart pointer)は今でもつくれるって。

0822デフォルトの名無しさん

2009/12/14(月) 22:39:28

>>811
テンプレートで使うときに、戻りの型が複雑すぎて手書きできない時なんかに便利。

0823812

2009/12/14(月) 22:56:11

>>820
それはあなたの仕事。
私はC1X委員会に働きかけて、
C++0xを完全にC1Xに変換できるようにします。
それができたら私は俺言語をつくりC1Xに変換するようにします。

0824デフォルトの名無しさん

2009/12/14(月) 22:58:51

C++03/0x->C89/99の変換ができるか出来ないかってだけなら、
どれもチューリング完全だから出来るに決まってるんだが
何をどうしたいの？

0825デフォルトの名無しさん

2009/12/14(月) 23:11:17

Cへのトランスレータっていえば、Valaがおもしろいよ。
ttp://live.gnome.org/Vala
このスレで存在を知ってる人ってどのくらいいるんだろうか？

0826デフォルトの名無しさん

2009/12/14(月) 23:39:23

たとえ、今でもC++がCのコードへ容易に変換できる仕様だったとしても、
結局、コンパイラの高速化などを理由に機械語やアセンブリ言語を
直接吐く処理系が主流になることにかわりはないと思う。

あったらあったで面白いだろうということは否定しないけど。

0827デフォルトの名無しさん

2009/12/15(火) 02:49:47

つーかトランスレータなんぞ作っても最適化がまともに掛からなくなるだけだろ
普通にコンパイルしてからC言語ディスコンパイラでも使ってろ

0828デフォルトの名無しさん

2009/12/15(火) 10:59:49

必要な人は作ればいいし
そうでない人にとってはどうでもいい話

0829デフォルトの名無しさん

2009/12/15(火) 19:42:04

>>827
お前の持ってる常識なんて一瞬で翻されるよ。

0830デフォルトの名無しさん

2009/12/15(火) 20:06:00

>>829
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1013807615
バカはこれを100回読みな

0831デフォルトの名無しさん

2009/12/15(火) 20:24:40

>>827
最適化が何なのかもわからないでよく言えるな。
具体的にC++コンパイラでやってる最適化の何が
トランスレータでできないのか言ってみろ。

0832デフォルトの名無しさん

2009/12/15(火) 20:53:54

そんなやりとり無駄なだけ。
暇を潰したい人だけ参加しな。

0833831

2009/12/15(火) 22:21:37

>>832
わざわざ無駄レスして相当の暇人ですね。
それでも一つも思い浮かばないわけですね。
他の暇人のみなさん、じっくり考えて下さいね。

0834ちんこ ◆GbXlaaQNk.

2009/12/15(火) 22:25:53

当方java使いですが、
C++って使ってて、生きた心地しなくないですか？
メモリ管理も動作とろいし、パフォーマンスもさほど高くないでしょ。
みんなjavaに来いよ。

0835デフォルトの名無しさん

2009/12/15(火) 22:28:56

そんな餌に釣られないクマ

0836デフォルトの名無しさん

2009/12/15(火) 22:29:18

C++使っててむしろ快感を覚える俺は変態だろうか。

ところでいつになったらC++0xが正式に採用されるの？
現時点での現実的な見込み時期ってあります？

0837デフォルトの名無しさん

2009/12/15(火) 22:29:23

>>834
> メモリ管理も動作とろいし
とろい理由を述べよ
ハスケルに目覚めてJava捨てたんじゃなかったのか?

0838ちんこ ◆GbXlaaQNk.

2009/12/15(火) 22:34:31

>>837
生成が遅くて、回収にも時間がかかると書いてあった。
javaは生成がC++より6倍くらい速くて、回収はほとんど０。

0839デフォルトの名無しさん

2009/12/15(火) 22:42:23

マイクロベンチマークならね

0840デフォルトの名無しさん

2009/12/15(火) 22:44:37

なんだ、ただの又聞きか

0841デフォルトの名無しさん

2009/12/15(火) 22:49:10

Hey, C++ Programmer EveryOne!

My word is " C++ is bitch !! ".

Good night.

0842デフォルトの名無しさん

2009/12/15(火) 23:28:21

ねぇ、なんで@itのサイトにC++のページがないの？

0843デフォルトの名無しさん

2009/12/15(火) 23:35:57

>>833
> わざわざ無駄レスして相当の暇人ですね。
ここはお前の喧嘩だから好きにしてくれればいいけど

> 他の暇人のみなさん、じっくり考えて下さいね。
なんだテメェは。失礼な。

0844デフォルトの名無しさん

2009/12/16(水) 00:31:49

>>842
土方サイトだから

0845デフォルトの名無しさん

2009/12/16(水) 11:14:01

>>836
ISO/IECの規格は、成立まで投票を3回(3ヶ月・4ヶ月・2ヶ月)しなきゃいけないんだけど、
1回目の投票が終わったところで例のconceptの一件が発生したので、多分最初からやり直し。

来年の7月からは投票制度が変わる予定なので、若干期間が短縮されるかもしれないけど、
どれだけ順調に行っても来年後半～再来年頭より早まることはないと思う。

0846デフォルトの名無しさん

2009/12/16(水) 16:57:14

>>824
> どれもチューリング完全だから出来るに決まってるんだが
無限長のテープを持ったチューリングマシンを用意してから言え。

0847デフォルトの名無しさん

2009/12/16(水) 16:58:30

いや、事実上問題にならないだろ、その辺は

0848デフォルトの名無しさん

2009/12/16(水) 17:42:43

そうですよねC++がトランスレータでも何の問題もない。

0849デフォルトの名無しさん

2009/12/16(水) 18:03:26

もちろん、全然問題ないですよ。存在しないことを除けば。

0850デフォルトの名無しさん

2009/12/17(木) 04:02:37

可能かどうかについては問題無い
実用的かどうかについては問題あり

0851デフォルトの名無しさん

2009/12/17(木) 09:45:52

理論上prologにだって変換可能

0852デフォルトの名無しさん

2009/12/17(木) 10:49:14

　void (*signal(int, void (*)(int)))(int);
って「統一された関数宣言構文」ではどう書けるの?

0853デフォルトの名無しさん

2009/12/17(木) 11:57:48

[] signal(int, [](*)(int)) -> [](*)(int);

これでいいのか自信は無い

0854デフォルトの名無しさん

2009/12/17(木) 12:13:44

-> void は省略可能なのか

0855デフォルトの名無しさん

2009/12/17(木) 22:44:42

>>853
なんか, スゲぶさいく
# lambdaちゃんそっくり

0856デフォルトの名無しさん

2009/12/17(木) 22:49:17

lambdaちゃんの妹です

0857デフォルトの名無しさん

2009/12/17(木) 23:35:14

どうせ判り切ったこと書きますが、C++2xはHaskellを大きく取り込むだろう。

0858デフォルトの名無しさん

2009/12/17(木) 23:45:04

というか、conceptはtype classを取り込んだも同然

0859デフォルトの名無しさん

2009/12/18(金) 23:58:58

そもそも
C++2xは来るのだろうか？

0860デフォルトの名無しさん

2009/12/19(土) 11:09:58

>>859
ふゆやすみ？

0861デフォルトの名無しさん

2009/12/19(土) 11:30:22

冬休みが楽しみな美少女中学生

0862859

2009/12/19(土) 12:42:32

>>860
何かおかしい事言った？

0863デフォルトの名無しさん

2009/12/19(土) 13:24:22

だから、冬休みになったのならその間にHaskellを勉強しておけってこと。

0864デフォルトの名無しさん

2009/12/19(土) 15:50:15

std::threadってどのヘッダに入ってるの？

0865デフォルトの名無しさん

2009/12/19(土) 16:31:48

0866857

2009/12/25(金) 22:41:28

マジで言ってます。
HaskellのエッセンスをC++に生かす研究している人いませんかね。

0867デフォルトの名無しさん

2009/12/26(土) 01:27:35

関数型プログラミングなら今でもテンプレート使って出来るけど？
Haskellのエッセンスって何

0868デフォルトの名無しさん

2009/12/26(土) 01:41:37

遅延評価かも

0869デフォルトの名無しさん

2009/12/26(土) 02:32:37

>>261で出来るよ

0870デフォルトの名無しさん

2009/12/26(土) 02:39:03

まあ、Haskellといえば遅延評価とカリー化と型クラスだよね
でもconceptが入らなくなっちゃったし

実際にHaskellで書いてて他との違いを一番感じるのは無限上等なとこなので
やっぱり遅延評価か

0871デフォルトの名無しさん

2009/12/26(土) 04:41:42

カリー化はクロージャのシンタックスシュガーでしかないし
型クラスはオーバーロードだったり継承だったりするので
やっぱ遅延評価だよね

0872デフォルトの名無しさん

2009/12/26(土) 08:34:23

型推論も忘れないでやってください

0873デフォルトの名無しさん

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の言うような余地は余りない。

0874デフォルトの名無しさん

2009/12/26(土) 23:25:40

シンタックスシュガーだって言語のエッセンスとして重要だぞ
カリー化有りか無しかは言語の特徴として特筆すべきことだと思う

0875デフォルトの名無しさん

2009/12/26(土) 23:30:07

カリー化は複数引数の関数を内部的にどう扱ってるかの違いだろう。
C系統の言語なら別に1番目の引数に特別な意味がある訳じゃないし

0876デフォルトの名無しさん

2009/12/26(土) 23:47:48

まあ、boost::bind がカリー化やっちゃってると言っても過言ではないかも
0x では型推論してくれるのでHaskellのカリー化より便利か

0877デフォルトの名無しさん

2009/12/27(日) 01:28:41

bindはまるで関数がカリー化されていたかのように
引数を部分的にapplyするためのテンプレート。

0878デフォルトの名無しさん

2009/12/27(日) 11:26:08

くだらね。三流どもが。

0879デフォルトの名無しさん

2009/12/27(日) 11:55:11

>>878
難しくて分かりませんって言えよ。w

0880デフォルトの名無しさん

2009/12/27(日) 16:01:27

全く理解できなくて一言の反撃すらできないけどとにかく否定したい、という気持ちが
凝縮されてるな

0881デフォルトの名無しさん

2009/12/27(日) 16:18:54

カリー化なんて何も難しいことないけどな
要は引数を1つずつ順番に使うってだけの話だし

0882デフォルトの名無しさん

2009/12/27(日) 16:22:25

まぁカリー化以外の話もしてるし、カリー化が何なのかが分かっただけじゃ反論は
始められないしな

0883デフォルトの名無しさん

2009/12/27(日) 16:39:11

>>881
つ関数を引数を一つづつ適用できるようにする

0884デフォルトの名無しさん

2009/12/27(日) 18:36:40

カリー化ってあれだろ、筋肉少女帯のほら

0885デフォルトの名無しさん

2009/12/27(日) 18:38:12

ナンってイースト菌使うっけ？

0886デフォルトの名無しさん

2009/12/27(日) 23:50:06

>>884 それは印度化。

0887デフォルトの名無しさん

2009/12/28(月) 09:05:08

bindをカリー化っていっちゃうのはちょっとな

3引数関数をcurry(f)すると
f(x)(y)(z)
f(x, y)(z)
f(x, y, z)
が全部できるとかならカリー化って感じはするが

0888デフォルトの名無しさん

2009/12/28(月) 11:10:45

>>887
fusionで上手いこと出来ないかな？

0889デフォルトの名無しさん

2009/12/28(月) 12:53:39

このへんの話を思い出した
ttp://d.hatena.ne.jp/kmizushima/20091216/1260969166

0890デフォルトの名無しさん

2009/12/28(月) 16:30:30

単純公理好きの数学だから＞一引数関数だけの世界
実際意味ねー

0891デフォルトの名無しさん

2009/12/28(月) 17:01:01

カリー化と言えばunlambdaですね！

0892デフォルトの名無しさん

2009/12/28(月) 22:00:36

カリー化とかHaskellとかって結局何が得意なん？

0893デフォルトの名無しさん

2009/12/29(火) 03:14:08

使い回し

0894デフォルトの名無しさん

2009/12/29(火) 08:22:40

そもそもcurry化って、
なんでcurryなのよさ。

0895デフォルトの名無しさん

2009/12/29(火) 08:26:17

それを考えた数学者の名前

0896デフォルトの名無しさん

2009/12/29(火) 08:37:17

>>895
そうだったのか。
サンクス。

0897デフォルトの名無しさん

2009/12/29(火) 09:02:37

印土人もびっくり

0898デフォルトの名無しさん

2009/12/29(火) 10:39:44

>887
とりあえずでっちあげ。Boost のバージョン違いで codepad だと動かないですが。
http://codepad.org/8h1gFMwQ

>888
fusion をどう使うイメージでしょうか。
引数を fusion に溜めておいて一時オブジェクトの破棄時に関数呼び出し？

0899デフォルトの名無しさん

2009/12/29(火) 11:27:17

>>896
Haskell Brooks Curry と申します。

0900デフォルトの名無しさん

2009/12/29(火) 20:45:40

カリー化って実用性ってあるの？

0901デフォルトの名無しさん

2009/12/29(火) 20:55:26

>>900
またそーやって痛いとこ付いちゃうwww

0902デフォルトの名無しさん

2009/12/29(火) 21:25:33

痛い奴だ

0903デフォルトの名無しさん

2009/12/29(火) 21:38:37

>>900
・curry化概念は実用的です。
・C++はcurry化がなくても実用的な言語です。
・curry化したければboostのLambdaを使って出来ます。
・一般にcurry化そのものよりも部分適用の方が有用です。
・関数がcurry化されているかのように部分適用するために、bindがあります。

0904デフォルトの名無しさん

2009/12/29(火) 23:02:26

カリー化があることで引数の順番に利益主導の法則が生まれる実利があると思う

と言ってみるものの、カリー化があると書いてて楽しいのなんのって

0905デフォルトの名無しさん

2009/12/30(水) 00:57:01

>>898
fusionで引数を与えて、再帰させならが引数を自動的に減少させていくような記述ができないかな？

0906デフォルトの名無しさん

2009/12/30(水) 00:58:56

boost::tupleの実装ってカリー化っぽくないか？

ただなんとなく。

0907デフォルトの名無しさん

2009/12/30(水) 10:07:55

カリー化って言うからわかりにくいんであって、遅延束縛（late binding）とか
部分束縛（partial binding）なら普通に理解できるだろう（と思う）。

0908デフォルトの名無しさん

2009/12/30(水) 10:18:57

数学的には、部分束縛できるような形に、もとのn引数の関数を
m（m < n）引数に変換するのがカリー化

0909デフォルトの名無しさん

2009/12/30(水) 10:42:25

関数の部分適用と併用して
普通の多引数関数を高階関数のように使える
ってぐらいしか使い道がわからないな

0910デフォルトの名無しさん

2009/12/30(水) 10:50:31

>>909
operator()に対して、
関数を引数に適用する
ってぐらいしか使い道がわからないな
って言ってるようなもの。

0911デフォルトの名無しさん

2009/12/30(水) 11:31:08

>>909
引数の型があらかじめ定まっていないから、色々なデータに対する操作が１引数関数１個で表現できるんだからすごいと思うよ。

0912デフォルトの名無しさん

2009/12/30(水) 11:32:48

>>910
> 関数を引数に適用する
ちなみにそれ以外の使い道なんてあるの？

0913デフォルトの名無しさん

2009/12/30(水) 11:51:46

>>911
それ多相ラムダ式の話じゃないかね？

0914デフォルトの名無しさん

2009/12/30(水) 18:00:46

何の話や、え？
加齢化？

0915デフォルトの名無しさん

2009/12/30(水) 18:08:53

アホは発言を控えて！

0916デフォルトの名無しさん

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 してるって感覚が薄くなるのが
便利なのかな。

0917デフォルトの名無しさん

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

0918デフォルトの名無しさん

2009/12/30(水) 19:57:10

>>915
誰がアホや？え？

0919デフォルトの名無しさん

2009/12/30(水) 20:55:43

>>898
関数オブジェクトの引数の数をコンパイル時に取得する手段がないと汎用的に書けないねぇ
arity_of<F>::value みたいな

というかそもそもオーバーロードされてるとダメか？
オーバーロードとカリー化って相性悪そう

0920デフォルトの名無しさん

2009/12/31(木) 00:40:03

コンセプトについて再考

0921デフォルトの名無しさん

2009/12/31(木) 09:41:05

conceptを捨てたC++0xに未来は無い

0922デフォルトの名無しさん

2009/12/31(木) 09:57:40

C++1xで入るだろ

0923デフォルトの名無しさん

2009/12/31(木) 10:36:11

今から次期規格作っても2xになる予感がします

0924デフォルトの名無しさん

2009/12/31(木) 10:48:53

もうこの際だからC++xxにしちまえ

0925デフォルトの名無しさん

2009/12/31(木) 10:50:17

c++++

0926デフォルトの名無しさん

2009/12/31(木) 11:03:56

コンセプトってパターンマッチの範囲を狭められれそうな気がするからコンパイルが速くなるんじゃないかな？みたいな？
もしかしてenable_ifをしっかり書けばコンパイル速くなる？

0927デフォルトの名無しさん

2009/12/31(木) 11:09:33

--(C++)

0928デフォルトの名無しさん

2009/12/31(木) 11:39:49

>>927
右辺値を--するとは、乙なことするな。

0929デフォルトの名無しさん

2009/12/31(木) 12:11:15

今日中に決まるよね？

0930デフォルトの名無しさん

2009/12/31(木) 12:21:00

>>928
operator++が参照を返すかも知れないぞ
それより不必要な括弧が言語名につくことこそ問題だと思う

0931デフォルトの名無しさん

2009/12/31(木) 12:27:50

>>930
そんなクソコードまで予想してなかったわ。

0932デフォルトの名無しさん

2009/12/31(木) 13:18:57

>>927
それってマイナスじゃん

0933デフォルトの名無しさん

2009/12/31(木) 15:43:10

>>932
何が？

0934デフォルトの名無しさん

2009/12/31(木) 16:29:36

戻りが減っちゃってるよ。

0935デフォルトの名無しさん

2009/12/31(木) 19:12:55

>>925
C#ならもうあるじゃん

0936デフォルトの名無しさん

2009/12/31(木) 19:18:52

あと5時間弱+9時間しかねーぞ
発表ﾏﾀﾞｰ?

0937デフォルトの名無しさん

2009/12/31(木) 19:46:25

9時間って何かと思ったら時差か。

0938デフォルトの名無しさん

2009/12/31(木) 19:54:57

UTC計算だね。
UTC-12のタイムゾーンを基準にするなら、更に12時間程度余裕がある

0939デフォルトの名無しさん

2009/12/31(木) 21:12:26

素直にC+=2

0940デフォルトの名無しさん

2010/01/01(金) 12:00:27

俺たちの0xはまだ始まったばかりだ！

0941デフォルトの名無しさん

2010/01/01(金) 12:02:06

始まってもいねぇなw

0942デフォルトの名無しさん

2010/01/01(金) 12:40:28

あるいは終わった・・・ってところかも

0943 【だん吉】【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年猶予があるぞ

0944デフォルトの名無しさん

2010/01/01(金) 22:36:54

やっと待ちに待ったゴールがきた。
誰か、公式の完成版仕様書のリンク貼れよ

0945デフォルトの名無しさん

2010/01/01(金) 23:12:06

>>944
ggrks　www

0946デフォルトの名無しさん

2010/01/02(土) 00:56:25

g++4.5.0 は「Unicode string literals」をサポートしてないの？
(char16_tとchar32_t)

0947デフォルトの名無しさん

2010/01/02(土) 08:11:15

>946
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html
ここだとサポートしてる事になってるけど実際には動作しないって事？

0948デフォルトの名無しさん

2010/01/02(土) 11:32:48

このスレには、

　　struct foo { auto f()->int && { ... } };
　が　int f() &&　か　int && f()　のどちらと
　解釈されるか？

という問いに正解できるヤツいる？

0949デフォルトの名無しさん

2010/01/02(土) 13:25:00

>>948
個人blogのネタコピペかっこわるい。

0950デフォルトの名無しさん

2010/01/02(土) 13:25:30

>>949
よく知ってるなw

0951デフォルトの名無しさん

2010/01/02(土) 18:11:08

ヒロヒト…

0952デフォルトの名無しさん

2010/01/02(土) 20:29:04

馬鹿ばっかし・・・

0953デフォルトの名無しさん

2010/01/02(土) 23:40:33

>>947
cucharがない

0954デフォルトの名無しさん

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 ライブラリ側の対応待ちじゃないかと思う。

0955デフォルトの名無しさん

2010/01/04(月) 00:09:37

つーか、いい加減に
C++０ｘがいつ発表されるのか決着つけてくれだれか

0956デフォルトの名無しさん

2010/01/04(月) 00:21:37

0xは90年待たないと…

0957デフォルトの名無しさん

2010/01/04(月) 10:03:41

C++0x → C++1x

0958デフォルトの名無しさん

2010/01/04(月) 13:49:56

>>946
typedef __CHAR16_TYPE__ char16_t;
typedef __CHAR32_TYPE__ char32_t;

0959デフォルトの名無しさん

2010/01/04(月) 19:32:26

C++0xってすでに二年前にC++010になってるじゃん
今年は012ですよ皆さん。

0960デフォルトの名無しさん

2010/01/04(月) 21:08:50

16進なのか8進なのか10進なのかは議論の分かれるところですなぁ。
俺は16進だと思う。

0961デフォルトの名無しさん

2010/01/04(月) 21:21:17

00
0x
x0
xx

二進数説

0962デフォルトの名無しさん

2010/01/04(月) 21:27:10

そんなんどうでもいいから
早くリリースしろ

と叫ぶしか俺らにはできることがない。

0963デフォルトの名無しさん

2010/01/04(月) 21:57:38

> 早くリリースしろ
同感

とは言うものの現 C++ の拙速感（特に STL）はもうたくさん
巧遅を早くやれってことだけど、どないもこないも・・・

0964デフォルトの名無しさん

2010/01/04(月) 22:07:57

>>961
奇才現る！！

0965デフォルトの名無しさん

2010/01/04(月) 22:27:39

C++は2000年頃にすっかり使わなくなって10年程になるのだが、
今、C++0xの内容も含めてリハビリするとしたら、どの辺りの
ドキュメント・書籍がおすすめ？和書洋書問わず。

0966デフォルトの名無しさん

2010/01/04(月) 22:32:30

ヒロヒロが著すC++0x本を待て

0967デフォルトの名無しさん

2010/01/04(月) 22:37:56

×ヒロヒロ
○ヒロヒト

0968デフォルトの名無しさん

2010/01/04(月) 23:48:19

>>965 >>1

0969デフォルトの名無しさん

2010/01/05(火) 00:57:05

>>968
なんかURLが羅列してあるだけなんですが

0970デフォルトの名無しさん

2010/01/05(火) 00:59:49

なにかもんだいでも？

0971デフォルトの名無しさん

2010/01/05(火) 01:58:29

0xの平易な解説書はまだ無いんじゃね
処理系もまだβ臭ぷんぷんなのに

0972デフォルトの名無しさん

2010/01/06(水) 20:41:10

C++の規格を読むと鬼難しい規則が膨大に羅列されていいる。
それでもなお規格の開発はすすむ。
C++はもう限界を越えて破滅の道を進んでいるんでしょうね。

0973デフォルトの名無しさん

2010/01/06(水) 20:58:27

>>972　限界とは？具体的に

0974デフォルトの名無しさん

2010/01/06(水) 20:59:05

auto とか簡単なものは簡単なんだが
右辺値参照とかどうなのよって感じ
あれば高速化に寄与するのは分かるけど
それ使ったコードは他の人に分かるんかと

0975デフォルトの名無しさん

2010/01/06(水) 21:04:01

右辺値参照はコンテナとかスマポとかのライブラリが対応するだけで、ライブラリの使い手は存在を知らないままでも高速化ができちゃうね。

0976デフォルトの名無しさん

2010/01/06(水) 21:07:34

>>975
それってある意味とてもすごいことだよな。
でも逆に自分がライブラリを書くときは
そこまで考えて書かないと
こいつなにやってんの？って思われるってことか？

0977デフォルトの名無しさん

2010/01/06(水) 21:16:17

これからC++コンパイラ作ろうとする奴がいたら死ぬな

0978デフォルトの名無しさん

2010/01/06(水) 21:19:30

しかもgccが
　標準ライブラリを利用してもソースコード公開不要
てなライセンスだから、それを越えて実装しないと
実質的に意味ないよね？

0979デフォルトの名無しさん

2010/01/06(水) 21:21:26

>>975
右辺値参照の準備は、const hoge func()をhoge func()に変えておく必要があるけどな。

0980デフォルトの名無しさん

2010/01/06(水) 21:45:36

>>979
そういやそうだったな。
Effective C++ に書いてあった内容が
現在にそぐわなくなるわけね。

0981!omikuji!dama

2010/01/06(水) 22:03:25

>>976
これまでの開発で右辺値参照が欲しいと思ったことがある奴にとっては大変ありがたい
そう思ったことが無い奴にとってはこれからも不要なので気にしなくてよい

0982>976

2010/01/06(水) 23:06:05

>>981
いままでは
テンポラリオブジェクトはconst参照で捕まえていたが、
あれがnon-constに捕まえられたら少しは早くなるだろうなぁ
と思ったことはある。