12/10/04 22:13:37.79
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)
Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
C++11/C++1y 15
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
12/10/04 23:22:19.44
君が死んでからもう１年。
君は今も僕を見守ってくれているのかな？
君は、僕の生まれて初めて出来た彼女だった。
すごく嬉しくて、幸せだったなあ。
突然、白血病だって医者に宣告されてから、君は病室で日に日に弱っていった。
「病院ってひまねえ」って笑う君を見て、僕はいつも泣いていたんだ。
君の為に、僕の小汚いノートパソコンをあげたら、君はすごく喜んでくれたよね。
ネットをするようになった君がいつも見ていたサイト、それが「２チャンネル」だった。
ある日君はいつものように、笑いながら言った。
「ほら、見て今日も２ゲット出来たよ。」
「あまりパソコンばっかいじってると身体に障るよ」
なんて僕が注意すると、「ごめんねえ。 でもね、これ見てよ。
ほら、この３のひと、２げっとぉ！なんて言っちゃってさぁ、ふふ」
僕は黙っていた。君がすごく楽しそうで、僕は何も言えなかった。
「ほらみて、この３のひと、変な絵文字使ってくやしぃ～！だって。かわいいねえ。 ふふ。」
僕はまだ黙っていた。笑う君を見て、どうしようもなく悲しくなった。
「憶えててくれるかなあ」 君がふと言った。
「…この３のひと、私がいなくなっても、あの時変な奴に２をとられたんだよなーなんて、憶えててくれないかなあ……無理かな……憶えてて、ほしいなぁ……」
それから数ヶ月後、君は家族と僕に見守れながら息を引き取った。
君はもうこの世に居ない、なのに僕は今F5を連続でクリックしている。
君の事を、３のひとが忘れないように、いつまでも、いつまでも忘れないように。
天国にいる君と一緒に、今ここに刻み込む
２ ゲ ッ ト
3:デフォルトの名無しさん
12/10/04 23:28:49.73
>>1
乙
4:デフォルトの名無しさん
12/10/05 00:04:02.16
前スレ最後の盛り上がりはどこへ？
5:デフォルトの名無しさん
12/10/05 00:08:18.31
スレをまたいで引っ張るようなネタか？
6:デフォルトの名無しさん
12/10/05 00:09:26.94
C++はオナニー言語。
業務アプリケーション開発には危険過ぎて使えず。
組み込みではCで充分という奴に迫害され、
難解な言語仕様勉強してる俺SUGEEEな
人たちが自分のプライドを保つための
最後の砦。
7:デフォルトの名無しさん
12/10/05 00:10:04.31
組み込みでもわりと使われてるけど
8:デフォルトの名無しさん
12/10/05 00:30:04.10
>>6の言う組み込みは土方系だろう。
9:デフォルトの名無しさん
12/10/05 00:49:29.29
難解な言語ではあるが、概念的に高度というわけではなく
ただ単にこんがらがっているだけ
10:デフォルトの名無しさん
12/10/05 00:52:59.34
プログラム言語Pastaに改名しよう
11:デフォルトの名無しさん
12/10/05 00:59:39.15
>>6
C++出来なくても仕事はあるから心配ないよ
12:デフォルトの名無しさん
12/10/05 01:42:50.82
言語仕様よりも、実行環境のほうが何故か重宝される。
VCも.NETがあるけど、.NETじゃコンパイルを実行時に後回しにした…という感じにしか思えない。
13:行動派は連絡を
12/10/05 05:55:57.17
━━━━━━━━━━━━━━━━━
マスコミも政党も大企業もネットも、日本は既に乗っ取られて操作されている。
Ｂ層よ、目を覚ませ。現在の日本は支配されている。 【疑う前に以下を見よ】
子供に教えられるかどうかで子供と日本の将来は大きく変わる。
騙されたと思って一度だけ、真摯に受け止めてみてよ。
URLﾘﾝｸ(s.webry.info) ★本題
URLﾘﾝｸ(s.webry.info) 政党
URLﾘﾝｸ(s.webry.info) マスコミ
URLﾘﾝｸ(s.webry.info) 1995
URLﾘﾝｸ(kenjyanoturugi.seesaa.net) 乗っ取られる日本
URLﾘﾝｸ(archive.mag2.com) 政治経済の真実
URLﾘﾝｸ(oujyujyu.blog114.fc2.com) 日本企業乗っ取り
URLﾘﾝｸ(www36.atwiki.jp) 戦後の金融資本の歴史
URLﾘﾝｸ(koramu2.blog59.fc2.com) ユダヤと反日朝鮮勢力
それでも何とか日本を守ろうと日々尽力を注ぐ日本勢力が現存する。
その勢力の反対勢力である左翼が「利権」と「原発」を徹底的に叩いている理由を解読せよ。
敵はマスゴミでも政党でも他国でもなく、背後で操る反日マイノリティー勢力だと意識せよ。
反日マイノリティー勢力の短期的目標は領土ではなく、人権委員会設置と外国人参政権。
そして大デキレースが遂にはじまった。Ｂ層向け茶番劇放送である地上波は絶対に見るな。
スカパー!HD(JCSAT-3A,4A)の衛星専門局か、できればアルジャジーラ(AsiaSat-3S)を見よ。
今の日本の世の中はまさに映画マトリックスの世界。
Ｂ層よ、今こそ目覚める時。
そして今後は各々で独立して情報分析して行動せよ。
━━━━━━━━━━━━━━━━━
※ この書き込みに対して【日本語がおかしな者】の妨害が入る様になりました。事実であるが故に反証できない上記内容が都合悪い様です。上記内容は特定の論者によるものではありません、念のため。
14:デフォルトの名無しさん
12/10/06 15:55:00.40
最近11の検討を始めたんだが、すごいな…
ラムダは待望だったから嬉しいけどけど、右辺値参照（だっけ？）にはワロタ
確かに使いどころによっては便利かもなとは思ったけど、マニアックすぎる
総じて、痒いところに手が届くのは嬉しいが、これから始める人には辛いかもな
ますますオッサン言語化してる気がするよ
15:デフォルトの名無しさん
12/10/06 16:00:03.88
というか今まで無かったのがなぞだよな右辺値参照って
16:デフォルトの名無しさん
12/10/06 22:36:06.33
代入や引数渡しの所で記述できるように言語でサポートするのは面白いよね。
高レベルのレイヤーでの利用ノウハウが溜まったら、
他の言語でも類似の機能がサポートされたりして。
17:デフォルトの名無しさん
12/10/06 22:42:30.12
っていうか右辺値参照みたいなのが必要になるのはオブジェクトが変数に埋めこまれるからで
オブジェクトといえばすべて参照経由な主流OOPLでは要らん機能だしなあ
埋めこみオブジェクトなOOPLって、C++以外だと何があるんだ
18:デフォルトの名無しさん
12/10/07 22:53:38.20
pre-Portland mailing 見るとまだまだお偉いさん方はC++いじる気満々だなｗ
新機能実験場というか論文のネタ場というか
ちっとは現場でメンテするプログラマのことも考えてほしいぜ
19:デフォルトの名無しさん
12/10/08 00:17:40.80
conceptが今後採用されることになれば
どうせ大規模な変更になるんだから
小手先のことなんてどうでもいいよ。
20:デフォルトの名無しさん
12/10/08 12:15:57.72
boostは完成しないからこそboostであり続ける
21:デフォルトの名無しさん
12/10/08 15:56:59.45
>>17
右辺値参照をメモリ管理だけの問題に矮小化しないでください！(怒
束縛と代入の動的な側面をプログラミング可能にし、
新しい意味や文脈を与える野心的な試みなんです。
問題は野心的過ぎることだけです。
全てのプログラミング要素は、最終的には右辺値参照に集約されるんですYO.
22:デフォルトの名無しさん
12/10/08 18:53:17.55
pre-Portlandにコンセプト関係の論文１つもないんだけど
23:デフォルトの名無しさん
12/10/08 19:18:50.67
pre-Kona で新しいのが提案されてる >concept
そのままC++Nowのキーノート・スピーチで解説されてた。
24:デフォルトの名無しさん
12/10/09 16:04:53.53
G++ now supports a -std=c++1y option for experimentation
with features proposed for the next revision of the standard,
expected around 2017.
25:デフォルトの名無しさん
12/10/12 20:47:32.93
右辺値参照、いくら話を聞いても使いドコロが分からない。
でかいコンテナの単なるコピーとかしないし・・・
英語でもいいから、何かよいリファレンスを教えてください。
26:デフォルトの名無しさん
12/10/12 20:55:33.43
使いどころっつったら std::vector<std::unique_ptr<T>> だろ常考
27:デフォルトの名無しさん
12/10/12 20:57:10.83
つ URLﾘﾝｸ(ja.m.wikipedia.org)
28:はちみつ餃子 ◆8X2XSCHEME
12/10/12 21:00:56.17
URLﾘﾝｸ(slashdot.jp)
29:デフォルトの名無しさん
12/10/12 21:49:50.28
使い所を考えるような物じゃなくて
不必要なコピーを出来るだけ無くしたるわってもんだからな
30:デフォルトの名無しさん
12/10/12 21:56:44.10
ムーブのメリットは様々な処理をノースローにできる事
31:デフォルトの名無しさん
12/10/12 21:58:25.51
右辺値参照はそれだけの話じゃないよ
今まで非共有スマポをコンテナに入れられなかったのは
コピーが不必要ではなく害悪だったから
害悪なコピーを回避するためにも右辺値参照は重要
32:デフォルトの名無しさん
12/10/12 22:05:20.58
>>31
って
>>26
のことだよね？
これは分かりやすいけど使わんのだよ。
たとえば
container<T> func() {
container<T> res;
...
return res;
}
みたいな関数をよく書くのですが、
最後の行を
return std::move(res);
にすれば使ってることになる？
33:デフォルトの名無しさん
12/10/12 22:11:51.49
書かなくてもそうなる
34:デフォルトの名無しさん
12/10/12 22:14:01.94
>>33
なるほど。
でもそれ以外のタイミングでコピーすることはないんだよなぁ。
自分のコーディングスタイルの問題なのかな？
・・・ちょっとスラドの記事よみ直してみます。
以前読んだけどありがたみがわからんかったので。
35:デフォルトの名無しさん
12/10/12 22:18:26.47
ぱっと眺めてなんとなく思ったのは、人様のライブラリを作ったことがないからかも。
すべて自分で書くぶんには、でかいオブジェクトのコピーを避けるように意識してるから、
operator=とか使わない習慣ができちゃってるのかも。
36:デフォルトの名無しさん
12/10/12 22:45:07.34
>>34
誰もコンテナのコピーの話なんてしてないぞ
要素のコピーの話しかしてない
従来仕様では push_back すら不可能
引数を使って新しい要素をコピーコンストラクトするから
非共有スマポは使えない
これがムーブできるようになったので大丈夫になった
メモリの再確保なんかもそうだな
37:デフォルトの名無しさん
12/10/12 23:20:40.18
>>32
container<T>が特殊なリソースを保持するハンドラでコピーはできんけど
func みたいな生成関数を用意したい、てときにマジ便利
しかもそんな特殊なハンドラを標準コンテナにいれても良いンだぜ
38:デフォルトの名無しさん
12/10/13 09:07:35.49
純粋仮想関数の書き方ってC++11でも
virtual void func() const = 0;
なんですか？
=0のかわりに=hoge
みたいなのが新しくできてたりしません？
39:デフォルトの名無しさん
12/10/13 09:21:00.84
#define hoge 0
40:デフォルトの名無しさん
12/10/13 09:43:18.84
= 0 があったら virtual は省略可にならないかな
41:デフォルトの名無しさん
12/10/13 09:47:28.53
#define pure 0
virtual void func() const = pure;
42:デフォルトの名無しさん
12/10/13 12:22:42.85
std::unordered_mapを使っていて、
std::_Hashtable<...>::_M_find_before_node(...)
が呼ばれまくってるのですが、これはハッシュ値の衝突と関係ありますか？
43:デフォルトの名無しさん
12/10/13 13:40:29.58
いいえ
44:デフォルトの名無しさん
12/10/14 02:49:32.87
質問者です。
URLﾘﾝｸ(gcc.gnu.org)
をみてみました。（hashtable.hのソースコード）
いろいろ省略したけど、だいたいこんな感じですね。
for文で（あるハッシュ値に対応する）バケツの中を徘徊しているように見えますが、これが長いのか、そもそも呼ばれた回数が多いのか・・・
そもそも_M_find_before_nodeの呼ばれた回数見てみます。
//Find the node whose key compares equal to k in the bucket n. Return nullptr if no node is found.
_BaseNode* _M_find_before_node(size_type __n, const key_type& __k, typename _Hashtable::_Hash_code_type __code) const
{
_BaseNode* __prev_p = _M_buckets[__n];
if (!__prev_p) return nullptr;
_Node* __p = static_cast<_Node*>(__prev_p->_M_nxt);
for (;; __p = __p->_M_next()) {
if (this->_M_equals(__k, __code, __p)) return __prev_p;
if (!(__p->_M_nxt) || _M_bucket_index(__p->_M_next()) != __n) break;
__prev_p = __p;
}
return nullptr;
}
45:デフォルトの名無しさん
12/10/14 03:39:22.50
ここって、unordered_mapの実装について質問するところなのか
46:デフォルトの名無しさん
12/10/14 08:41:27.79
まあ確かに相談室のほうに投下するべきだったけど。
上の件は、やはりハッシュ値の衝突が原因でした。
パフォーマンスが２倍変わったよ。
47:デフォルトの名無しさん
12/10/14 12:47:17.59
boostみたいにshared_ptrのマルチスレッド対応をOFFにしたいんだけどどうすればできますか？
48:デフォルトの名無しさん
12/10/14 15:00:01.57
無い
49:デフォルトの名無しさん
12/10/14 15:10:44.55
まじすか…
C++の「使わないときにコストかけるな」っていう理念はどこにいったんですか？
50:デフォルトの名無しさん
12/10/14 15:16:56.60
atomic_is_lock_free
51:デフォルトの名無しさん
12/10/14 15:41:46.11
実装の問題を規格の思想に言われてもな
52:デフォルトの名無しさん
12/10/14 15:49:32.67
まあ細かいこといったらC++からしたら「そんな義理は無い」ってことで終わりなんだろうけどさぁ
でもその理念を見失ったらC++のアイデンティティを失ったも同義だしほかの言語に全部持ってかれちゃうよ？
53:デフォルトの名無しさん
12/10/14 15:50:04.51
どうぞどうぞご勝手に
54:デフォルトの名無しさん
12/10/14 15:57:36.12
作るのに1時間もかからんしスレッドアンセーフっていうか無駄な機能最大限省いたSPつくりゃいいよね
stdのはライブラリのインターフェースに使ったりとにかく可搬性ある汎用的なコード書きたい場合だけでいい
55:デフォルトの名無しさん
12/10/14 16:13:20.19
というかboost::shared_ptrでダメな理由がないんだが
std::shared_ptrはboostの劣化バージョンだから乗り換える理由が今のところない
56:デフォルトの名無しさん
12/10/14 18:02:38.32
どのあたりが違うの
57:デフォルトの名無しさん
12/10/14 19:58:17.15
constexpr boost::shared_ptr<int> p(nullptr);
static_assert(noexcept(p.reset()), "boost::shared_ptrでは今のところ無理");
58:デフォルトの名無しさん
12/10/15 00:34:33.73
劣化バージョンというあたりを詳しく聞きたい
59:デフォルトの名無しさん
12/10/15 12:42:04.47
boost::scoped_ptrはstd::unique_ptrに置き換えても大丈夫かな
60:デフォルトの名無しさん
12/10/15 13:24:56.31
劣ってる部分有るか？
61:デフォルトの名無しさん
12/10/15 17:04:14.06
業務連絡：gcc-4.8 に inheriting constructors が実装された模様
62:デフォルトの名無しさん
12/10/15 17:41:54.63
後でコード追いにくくなる継承より
tuple返すメソッドでゴッソリ代入出来る構文を用意し欲しかった
63:デフォルトの名無しさん
12/10/15 21:30:33.05
>>58
マルチスレッドをオフにできない
すでにブーストで書かれている過去の資産との親和性が低い
64:デフォルトの名無しさん
12/10/15 22:47:04.00
お薬出しておきますね
65:デフォルトの名無しさん
12/10/15 22:48:11.27
反論は論理的に
悪口だけのレスは無価値です
66:デフォルトの名無しさん
12/10/15 23:29:32.92
>>63
> すでにブーストで書かれている過去の資産との親和性が低い
「ブーストで書かれている」が頭悪そう
67:デフォルトの名無しさん
12/10/15 23:35:17.88
このスレかどうか忘れたけど
boost::shared_ptrとの相互運用の方法が書かれてたから
親和性はあるんじゃないかな
68:デフォルトの名無しさん
12/10/16 01:00:48.96
前スレにあったな。
URLﾘﾝｸ(d.hatena.ne.jp)
69:デフォルトの名無しさん
12/10/16 06:49:51.69
>>67
コストかかり過ぎ
70:デフォルトの名無しさん
12/10/16 07:54:10.92
shared_ptr使ってる時点でコストを気にするもんじゃないと思うが
71:デフォルトの名無しさん
12/10/16 08:08:43.91
>>70
だからただでさえやばいコストがさらに膨れ上がるんじゃ使い物にならない
72:デフォルトの名無しさん
12/10/16 08:15:48.51
そりゃ相互運用にはコストがかかるもんさ。でも親和性とそれは全く別問題だよね。
少なくとも親和性は低くない、というかこれで相互乗り入れできるんだから親和性は結構高い
73:デフォルトの名無しさん
12/10/16 08:50:39.38
でも結局両方使えるならノーコストのboost::shared_ptrが有利だろ？
結局のところstdのほうが無駄が多いことは同じ
74:デフォルトの名無しさん
12/10/16 08:57:46.55
boost信者はこれだから困る。
実行時コストなんかどうでもいいんだよ。
標準ライブラリかどうかっていうのは致命的。
機能的に同じことをするなら標準の方法で
実装した方が後でメンテする人に迷惑がかからない。
今から入社してくる後輩に「おじいちゃんブーストって何？」
なんて聞かれたくないだろ。
75:デフォルトの名無しさん
12/10/16 09:31:53.59
>>74
どうでもいいは言い過ぎ
…だが、そこ以外には激しく同意
会社では保守性一番
76:デフォルトの名無しさん
12/10/16 09:52:30.99
boost使ったら保守性さがるとか驚きだなどんだけ低レベルのPGが集まってるんだ
コミュニティに提言したらどうだ？お前んとこのライブラリは糞だってな
77:デフォルトの名無しさん
12/10/16 10:04:02.08
std::shared_ptrで作ったライブラリはC++03以前では使えない
しかしboost::shared_ptrで作ったライブラリは古いコンパイラでも動く。この差は非常に大きい
仕様策定からまだ間もないし実装が追いついて無いからまだ古いコンパイラ使ってるところのが多いしな
だから可搬性ではstdよりはるかにboostのほうが高いしコンパイラのバージョンを気にしなくて良い分だけ「保守性も高い」
今から入社してくる後輩に「先輩このコードぼくのコンパイラだとコンパイルできないんですけどたすけてください」なんて聞かれたくないわなめんどくせぇし
stdのが扱いやすいとか言ってる雑魚はまだ現実が見えてないよ
stdが今のboostのような便利屋的な立場になるのはおそらく11の次の規格への乗り換えが始まるころだろうな
このころになればコンパイラの実装もほぼコンプリートしているからstdに乗り換える理由がようやっと出てくる
それまではどこの会社でもこれならboostのほうがええわという結論が出るだろう
というか標準のバカどもが気を利かせてboostとの互換性を持たせるように仕様を決めればイイハナシなんだがな
boostは次期標準を視野に入れたほとんど公式のライブラリなんだから標準はboostに敬意を払い互換性を持たせるべき
78:デフォルトの名無しさん
12/10/16 10:17:16.65
お薬増やしておきますね
79:デフォルトの名無しさん
12/10/16 10:19:21.41
ほう。論理的反論は不可能なようだなｗｗｗ
80:デフォルトの名無しさん
12/10/16 10:49:56.91
boostは準標準と見ていいよ
stdの仕様決めるC++標準化委員会の人達がboostコミュニティの中心なんだし
81:デフォルトの名無しさん
12/10/16 11:09:08.10
どこまで行っても準標準は標準にはなれないけどね
委員会メンバーもそれが分かっててわざわざ規格にブチ込んだわけだし
82:デフォルトの名無しさん
12/10/16 11:37:26.32
C++11のスレで、C++03以前の古いコンパイラがどうとか言ってるのは、まあ論外としても
まだドキュメントが少なくて利用実績のあまりない現状では、boost::shared_ptrを使うのは普通にアリだと思うよ
でも将来は「std::shared_ptrがあるのにわざわざboost::shared_ptrを使う理由が分からない」とか言われるんだろうな
結局ドキュメント類が多いほうが世の中に浸透するんだし、その点でISO標準に勝つのはどうしても難しい
（まあ、標準Pascal無視したDelphiとか、標準Basic無視したVBとか、例外はいくらでもあるが）
83:デフォルトの名無しさん
12/10/16 20:19:23.87
まあ混在させるよりはどっちかで統一させた方がいいと思う
84:デフォルトの名無しさん
12/10/16 20:23:14.10
>>83
となるとすでに使われてるboostなんだよなぁ
85:デフォルトの名無しさん
12/10/16 20:38:01.39
完全新規案件ならstd::shared_ptrで
ただし、C++11が普及してからな
86:デフォルトの名無しさん
12/10/16 22:57:26.18
>>85
現在は普及しているのか？
87:デフォルトの名無しさん
12/10/16 22:59:21.70
してないな
少なくともVSが対応してからだな
88:デフォルトの名無しさん
12/10/17 00:38:12.18
>>87
だとすると、「完全新規案件なら」というくだりは、まったく無意味な話か
89:デフォルトの名無しさん
12/10/17 00:54:08.17
完全新規案件で、かつ、C++11が普及していたら、という条件文だろ
どこが無意味なんだ
90:デフォルトの名無しさん
12/10/17 01:03:48.95
>>89
現時点では「C++11が普及していたら」が偽なので、少なくとも現時点では他に何が書かれていても無駄になる。
91:デフォルトの名無しさん
12/10/17 01:05:21.91
>>85
何をもって普及したとみなせるのか書いてないから
他人からすれば何も言ってないに等しいな
当人の脳内では自明なんだろうけど
92:デフォルトの名無しさん
12/10/17 01:17:01.29
>>90
>現時点では「C++11が普及していたら」が偽
Linux界隈ではVC気にしなくていいから、局所的な見方ができるなら偽と言い切れるものではないな
実際にはC++11でかつLinux案件とかを想定してるんじゃね
もちろん、何を以て普及したと見做すのかは>>89に聞かないと分からんけどな
（そしてその答えによっては>>89の文章全体が無意味になる）
93:デフォルトの名無しさん
12/10/17 01:48:48.77
してからな、って言ってるように、
今はまだ厳しいというイメージで言った
94:デフォルトの名無しさん
12/10/17 02:03:08.23
イメージとかそういうのはどうでもいい
95:デフォルトの名無しさん
12/10/17 02:06:51.96
脳内自明なイメージを
表現することなく
十分に書けたつもりに
96:デフォルトの名無しさん
12/10/17 09:11:38.32
Macで使えれば十分だよ
今後Mac以外は廃れるから考慮しなくてよい
97:デフォルトの名無しさん
12/10/17 18:42:30.11
おう
98:デフォルトの名無しさん
12/10/17 21:42:49.10
Macはもうない
99:デフォルトの名無しさん
12/10/17 22:19:33.35
今C++11やるならMacかLinux
普通はMacを使う
100:デフォルトの名無しさん
12/10/17 22:38:27.59
Mac以外のマシンは滅ぼせ！
101:デフォルトの名無しさん
12/10/17 22:42:57.11
Xcodeで使えるのん？
102:デフォルトの名無しさん
12/10/18 07:58:16.13
MacPortsが更新遅すぎて（最新から１年遅れとかザラ）使う気にならない。
更新されてもGCCとかソースからコンパイルしよるから、その間なにすればいいの状態ｗ
103:デフォルトの名無しさん
12/10/18 08:00:54.28
Fortran77が死なない理由は優秀なライブラリだよね・・・
C++03でそんな事情はないから多分そのうち死んでくれると思う。
それよりCが死んでくれないことが大問題だよ。
104:デフォルトの名無しさん
12/10/18 08:03:03.84
連投スマソ。
C++11で導入された標準ライブラリの速度が出ないんだけど、
そのうち改善されていく見込みはあるんだろうか？
現時点のGCCは成熟度何％くらいだと思ってたらいいか分かる人いる？
105:デフォルトの名無しさん
12/10/18 08:10:19.67
Cが死ぬ前にC++が死ぬよ
106:デフォルトの名無しさん
12/10/18 08:13:33.58
まぁそんな気がする。
しかしここ数年、言語界のアイディアも枯渇しててC++11でしばらくは行けそうな感じだよな。
すくなくとも逐次計算にかぎれば。
並列計算に特化した言語モデル（でまともなの）が出てくれば死ぬかも。
107:デフォルトの名無しさん
12/10/18 08:29:09.46
>>104
１１は速度をあきらめて扱いの楽さを優先したから速度でないのは当たり前だよ
今はどうしても速さがほしいならいままでどおりC/C++03を
楽さを求めるならほかの言語をって感じ
108:デフォルトの名無しさん
12/10/18 10:39:22.72
>>107
なるほど。
では今後に期待～
109:デフォルトの名無しさん
12/10/18 15:48:17.03
>>107
え？
110:デフォルトの名無しさん
12/10/18 15:52:08.60
>>107
規格の影響を受ける問題じゃあるまいし
111:デフォルトの名無しさん
12/10/18 15:56:17.41
>>110
なにいってんの？
112:デフォルトの名無しさん
12/10/18 16:00:31.15
C++11にしたら速度が出ないという妄想の話？
113:デフォルトの名無しさん
12/10/18 16:19:35.62
STLは右辺値参照を使って大幅に書き直されているから速度が上がってるだろ
スピードが出ないのはiostreamとかfstreamの話だろ？
あれほどstd::ios::sync_with_stdio(false); を実行しとけと言ってるのに
それかcstdioだけを使うか
114:デフォルトの名無しさん
12/10/18 16:31:59.01
ワロタ
もともと最適化あるから右辺値参照ぐらいじゃ大して変わらんよ
それよりshared_ptrやスレッドがバカに乱用されてパフォーマンス悪くバグが増えることが問題
115:デフォルトの名無しさん
12/10/18 16:35:42.19
>>114
URLﾘﾝｸ(blogs.msdn.com)
よく調べてから物を言えよ
恥かくだけだぞ
116:デフォルトの名無しさん
12/10/18 16:36:32.38
あとこんなのもあるなあ
URLﾘﾝｸ(cpp-next.com)
こちらは無名のブログなので自分で検証してみ
117:デフォルトの名無しさん
12/10/18 21:40:43.97
結局参照もポインタと同じ道を辿ったな
わかりにくく使いづらく扱いを誤れば危険だしパフォーマンスも落とすクソ機能
その分色んなことが出来るからいいんだいという反論があるだろが、
参照はポインタほどの融通も効かないから中途半端
118:デフォルトの名無しさん
12/10/18 22:14:12.43
STLで右辺値参照使ってると言っても
ムーブが定義されてなきゃ今まで通りなんでしょ？
遅くなるってどういう事だよ
119:デフォルトの名無しさん
12/10/18 22:22:17.57
一応、(リンク時にdead code eliminationしなきゃ)
関数の数が増える=実行ファイルサイズが増える=コードがキャッシュに乗る率が減る=遅くなる
かもしれない
120:デフォルトの名無しさん
12/10/18 22:28:39.64
dead code elimination も何も
クラステンプレートは使わないメンバ関数は
実体化しないという仕様だから
121:デフォルトの名無しさん
12/10/19 10:56:10.40
>>117
使い方を誤る奴が悪い終了
122:デフォルトの名無しさん
12/10/19 21:03:48.49
ラムダってテンプレート引数使えないんのか
struct Func { template <typename T> void operator () (T const & obj) { } };
みたいに、ラムダで
template <typename T> [](T && obj) { func(forward<T>(obj)); }
書ければいいのにね
つかどうせならC#みたいに省略できればよかったのに
123:デフォルトの名無しさん
12/10/19 21:12:23.15
関数内どんだけ肥大化させる気？
124:デフォルトの名無しさん
12/10/19 21:21:14.01
関数内でテンプレートってそもそも必要？
125:デフォルトの名無しさん
12/10/19 21:28:30.12
引数の型書くのが面倒なんよ
そう思わないか？
ラムダがあればファンクタ書くのは楽になるが中途半端だ
どうせならとことん楽したいやん
126:デフォルトの名無しさん
12/10/19 21:36:48.84
template <typename T> と書く手間で
typedef decltype(a) T; が書ける
127:デフォルトの名無しさん
12/10/20 00:21:49.05
C++1yで多相ラムダが使えるようになるまでの我慢我慢
128:デフォルトの名無しさん
12/10/20 10:24:25.79
>>127
２年くらい前にこのスレで[](auto&){...}使えるといいねって話をしたら
バカにされてあえなく撤退したわｗ
129:デフォルトの名無しさん
12/10/20 12:56:01.55
>128
型が記述位置で一意にならないんじゃね？テンプレートなきゃムリだろ。
130:デフォルトの名無しさん
12/10/20 13:14:06.10
別にそれでいいじゃん
131:デフォルトの名無しさん
12/10/20 13:24:30.56
>>129
２年前にまったく同じ事を言われた。
コンパイラ作ってる人からすればそうだろうけど、利用者からすればまったく自然な発想。
テンプレートでいいから何とかしてくれ。
sort(v.begin(),v.end(),[](const super_complicated_template_container_type::super_long_named_value_type& x){return x+1;});
とか、アホくさくて耐えられないｗ
132:デフォルトの名無しさん
12/10/20 13:26:02.36
適当に書いたけどsort用のラムダじゃなかったな。
比較関数になるとさらに醜いことになる。
133:デフォルトの名無しさん
12/10/20 13:46:15.50
decltype((x)) const &
まあoperator()がテンプレートなファンクタはもとからできるので実装上の問題はなく構文をどうするかだろう
一般の関数にまで拡張して void f(auto x) を template<class T> void f(T x) のシンタックスシュガーにするかとかにまで広がるだろうし
134:デフォルトの名無しさん
12/10/20 13:54:41.97
ん、xじゃないな
135:デフォルトの名無しさん
12/10/20 14:46:05.38
URLﾘﾝｸ(www.open-std.org)
>>131の例なら
sort(v.begin(),v.end(),[](const &x) x+1);
にしようぜってのが今の提案
136:デフォルトの名無しさん
12/10/20 17:44:51.28
>>135
いいね！
搭載までにどれくらいかかるのか分かりませんが期待してます。
137:デフォルトの名無しさん
12/10/21 22:37:41.22
というか一番最初のラムダのペーパーはすげえ短く書けてｗｋｔｋだったんだがな... まだ[]が<>だったころ
だまされたー!
138:デフォルトの名無しさん
12/10/21 23:16:30.59
C#と同じ書式にしてしまうのはダメなんかなぁ
…ユーザーオブジェクトの扱いが違うからダメか…
sort(v.begin(), v.end(), x => x+1);
139:デフォルトの名無しさん
12/10/23 09:15:20.10
今C++11何か使ったら理解できないやつが続出して全てが自分に回ってきそうで、取り敢えずようす見ることにしてるわ。
140:デフォルトの名無しさん
12/10/23 09:35:02.93
cpp3よりわかりやすいと思うけど？
一回教えれば今より面倒も減ると思う
141:デフォルトの名無しさん
12/10/23 10:33:23.26
他にもっといいラムダ式の書式があったのかもしれないが、C++11標準化委員会が
新しいアイデアを待ったけど誰も出してこないのでこういう変な格好に落ち着いたらしい
まあタイプ量が少なくて直感的だからいいんじゃね
142:デフォルトの名無しさん
12/10/23 10:36:57.12
仮想プロパティはいつになったら使えるようになるねん
143:デフォルトの名無しさん
12/10/23 22:16:53.45
>>139
会社で使う人はそういう悩みもあるのか・・・
11を03のソースに変換するツールとかあれば自分だけ使えてウハウハになれるでしょうか？
144:デフォルトの名無しさん
12/10/23 22:39:57.88
マ板行けよ。
145:デフォルトの名無しさん
12/10/23 23:02:22.30
C++11難しくないだろ
C++03の方がよほど面倒だぞ
146:デフォルトの名無しさん
12/10/23 23:17:54.28
C++03より簡単に書ける、のは確かだけれど、
C++11はC++03互換の形式でも書けるようになってるので、結果的に複雑。
難しくない、というのは言い過ぎ
147:デフォルトの名無しさん
12/10/23 23:40:40.96
11で切り捨てられる機能って何かある？
たとえば副作用のあるラムダは外部に変数定義しないといけないから、
カプセル化を破ってしまう。カプセル化するためには関数オブジェクトが必要。
完全にdeprecateされた言語機能ってそれほどないのでは？
アルゴリズム、コンテナ、どちらも増えただけだし・・・。
148:デフォルトの名無しさん
12/10/23 23:50:54.98
完全に削除されたexportがあるだろ
149:デフォルトの名無しさん
12/10/24 00:37:49.63
折角 export を実装した Comeau C++ が可哀想です
150:デフォルトの名無しさん
12/10/24 01:16:07.92
export実装する前にtemplateのネストを実装すればよかったw > Comeau
151:デフォルトの名無しさん
12/11/02 20:39:03.23
やっぱり、これからは並列処理が簡単にできる言語の時代かも
152:デフォルトの名無しさん
12/11/02 22:24:19.84
提案にいくつか並列化関係のあるよな
TR2に入ったらうれしい