C++11/C++1y 16

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
2デフォルトの名無しさん:2012/10/04(木) 23:22:19.44
君が死んでからもう1年。
君は今も僕を見守ってくれているのかな?
君は、僕の生まれて初めて出来た彼女だった。
すごく嬉しくて、幸せだったなあ。
突然、白血病だって医者に宣告されてから、君は病室で日に日に弱っていった。
「病院ってひまねえ」って笑う君を見て、僕はいつも泣いていたんだ。
君の為に、僕の小汚いノートパソコンをあげたら、君はすごく喜んでくれたよね。
ネットをするようになった君がいつも見ていたサイト、それが「2チャンネル」だった。
ある日君はいつものように、笑いながら言った。
「ほら、見て今日も2ゲット出来たよ。」
「あまりパソコンばっかいじってると身体に障るよ」
なんて僕が注意すると、「ごめんねえ。 でもね、これ見てよ。
ほら、この3のひと、2げっとぉ!なんて言っちゃってさぁ、ふふ」
僕は黙っていた。君がすごく楽しそうで、僕は何も言えなかった。
「ほらみて、この3のひと、変な絵文字使ってくやしぃ〜!だって。かわいいねえ。 ふふ。」
僕はまだ黙っていた。笑う君を見て、どうしようもなく悲しくなった。
「憶えててくれるかなあ」 君がふと言った。
「…この3のひと、私がいなくなっても、あの時変な奴に2をとられたんだよなーなんて、憶えててくれないかなあ……無理かな……憶えてて、ほしいなぁ……」

それから数ヶ月後、君は家族と僕に見守れながら息を引き取った。
君はもうこの世に居ない、なのに僕は今F5を連続でクリックしている。
君の事を、3のひとが忘れないように、いつまでも、いつまでも忘れないように。

天国にいる君と一緒に、今ここに刻み込む

        2 ゲ ッ ト
3デフォルトの名無しさん:2012/10/04(木) 23:28:49.73
>>1
4デフォルトの名無しさん:2012/10/05(金) 00:04:02.16
前スレ最後の盛り上がりはどこへ?
5デフォルトの名無しさん:2012/10/05(金) 00:08:18.31
スレをまたいで引っ張るようなネタか?
6デフォルトの名無しさん:2012/10/05(金) 00:09:26.94
C++はオナニー言語。
業務アプリケーション開発には危険過ぎて使えず。
組み込みではCで充分という奴に迫害され、
難解な言語仕様勉強してる俺SUGEEEな
人たちが自分のプライドを保つための
最後の砦。
7デフォルトの名無しさん:2012/10/05(金) 00:10:04.31
組み込みでもわりと使われてるけど
8デフォルトの名無しさん:2012/10/05(金) 00:30:04.10
>>6の言う組み込みは土方系だろう。
9デフォルトの名無しさん:2012/10/05(金) 00:49:29.29
難解な言語ではあるが、概念的に高度というわけではなく
ただ単にこんがらがっているだけ
10デフォルトの名無しさん:2012/10/05(金) 00:52:59.34
プログラム言語Pastaに改名しよう
11デフォルトの名無しさん:2012/10/05(金) 00:59:39.15
>>6
C++出来なくても仕事はあるから心配ないよ
12デフォルトの名無しさん:2012/10/05(金) 01:42:50.82
言語仕様よりも、実行環境のほうが何故か重宝される。
VCも.NETがあるけど、.NETじゃコンパイルを実行時に後回しにした…という感じにしか思えない。
13行動派は連絡を:2012/10/05(金) 05:55:57.17
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
マスコミも政党も大企業もネットも、日本は既に乗っ取られて操作されている。
B層よ、目を覚ませ。現在の日本は支配されている。 【疑う前に以下を見よ】

子供に教えられるかどうかで子供と日本の将来は大きく変わる。
騙されたと思って一度だけ、真摯に受け止めてみてよ。

http://s.webry.info/sp/stktakemoto4216.at.webry.info/201201/article_10.html ★本題
http://s.webry.info/sp/stktakemoto4216.at.webry.info/201201/article_11.html 政党
http://s.webry.info/sp/stktakemoto4216.at.webry.info/201201/article_9.html マスコミ
http://s.webry.info/sp/stktakemoto4216.at.webry.info/201201/article_60.html 1995
http://kenjyanoturugi.seesaa.net/article/148207356.html 乗っ取られる日本
http://archive.mag2.com/0000154606/20081014060012000.html 政治経済の真実
http://oujyujyu.blog114.fc2.com/blog-entry-328.html 日本企業乗っ取り
http://www36.atwiki.jp/anti-rothschild/pages/15.html 戦後の金融資本の歴史
http://koramu2.blog59.fc2.com/blog-entry-812.html ユダヤと反日朝鮮勢力

それでも何とか日本を守ろうと日々尽力を注ぐ日本勢力が現存する。
その勢力の反対勢力である左翼が「利権」と「原発」を徹底的に叩いている理由を解読せよ。

敵はマスゴミでも政党でも他国でもなく、背後で操る反日マイノリティー勢力だと意識せよ。
反日マイノリティー勢力の短期的目標は領土ではなく、人権委員会設置と外国人参政権。

そして大デキレースが遂にはじまった。B層向け茶番劇放送である地上波は絶対に見るな。
スカパー!HD(JCSAT-3A,4A)の衛星専門局か、できればアルジャジーラ(AsiaSat-3S)を見よ。

今の日本の世の中はまさに映画マトリックスの世界。
B層よ、今こそ目覚める時。
そして今後は各々で独立して情報分析して行動せよ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

※ この書き込みに対して【日本語がおかしな者】の妨害が入る様になりました。事実であるが故に反証できない上記内容が都合悪い様です。上記内容は特定の論者によるものではありません、念のため。
14デフォルトの名無しさん:2012/10/06(土) 15:55:00.40
最近11の検討を始めたんだが、すごいな…
ラムダは待望だったから嬉しいけどけど、右辺値参照(だっけ?)にはワロタ
確かに使いどころによっては便利かもなとは思ったけど、マニアックすぎる
総じて、痒いところに手が届くのは嬉しいが、これから始める人には辛いかもな
ますますオッサン言語化してる気がするよ
15デフォルトの名無しさん:2012/10/06(土) 16:00:03.88
というか今まで無かったのがなぞだよな右辺値参照って
16デフォルトの名無しさん:2012/10/06(土) 22:36:06.33
代入や引数渡しの所で記述できるように言語でサポートするのは面白いよね。
高レベルのレイヤーでの利用ノウハウが溜まったら、
他の言語でも類似の機能がサポートされたりして。
17デフォルトの名無しさん:2012/10/06(土) 22:42:30.12
っていうか右辺値参照みたいなのが必要になるのはオブジェクトが変数に埋めこまれるからで
オブジェクトといえばすべて参照経由な主流OOPLでは要らん機能だしなあ

埋めこみオブジェクトなOOPLって、C++以外だと何があるんだ
18デフォルトの名無しさん:2012/10/07(日) 22:53:38.20
pre-Portland mailing 見るとまだまだお偉いさん方はC++いじる気満々だなw
新機能実験場というか論文のネタ場というか

ちっとは現場でメンテするプログラマのことも考えてほしいぜ
19デフォルトの名無しさん:2012/10/08(月) 00:17:40.80
conceptが今後採用されることになれば
どうせ大規模な変更になるんだから
小手先のことなんてどうでもいいよ。
20デフォルトの名無しさん:2012/10/08(月) 12:15:57.72
boostは完成しないからこそboostであり続ける
21デフォルトの名無しさん:2012/10/08(月) 15:56:59.45
>>17
右辺値参照をメモリ管理だけの問題に矮小化しないでください!(怒
束縛と代入の動的な側面をプログラミング可能にし、
新しい意味や文脈を与える野心的な試みなんです。
問題は野心的過ぎることだけです。
全てのプログラミング要素は、最終的には右辺値参照に集約されるんですYO.
22デフォルトの名無しさん:2012/10/08(月) 18:53:17.55
pre-Portlandにコンセプト関係の論文1つもないんだけど
23デフォルトの名無しさん:2012/10/08(月) 19:18:50.67
pre-Kona で新しいのが提案されてる >concept
そのままC++Nowのキーノート・スピーチで解説されてた。
24デフォルトの名無しさん:2012/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デフォルトの名無しさん:2012/10/12(金) 20:47:32.93
右辺値参照、いくら話を聞いても使いドコロが分からない。
でかいコンテナの単なるコピーとかしないし・・・
英語でもいいから、何かよいリファレンスを教えてください。
26デフォルトの名無しさん:2012/10/12(金) 20:55:33.43
使いどころっつったら std::vector<std::unique_ptr<T>> だろ常考
27デフォルトの名無しさん:2012/10/12(金) 20:57:10.83
28はちみつ餃子 ◆8X2XSCHEME :2012/10/12(金) 21:00:56.17
29デフォルトの名無しさん:2012/10/12(金) 21:49:50.28
使い所を考えるような物じゃなくて
不必要なコピーを出来るだけ無くしたるわってもんだからな
30デフォルトの名無しさん:2012/10/12(金) 21:56:44.10
ムーブのメリットは様々な処理をノースローにできる事
31デフォルトの名無しさん:2012/10/12(金) 21:58:25.51
右辺値参照はそれだけの話じゃないよ

今まで非共有スマポをコンテナに入れられなかったのは
コピーが不必要ではなく害悪だったから
害悪なコピーを回避するためにも右辺値参照は重要
32デフォルトの名無しさん:2012/10/12(金) 22:05:20.58
>>31
って
>>26
のことだよね?
これは分かりやすいけど使わんのだよ。

たとえば
container<T> func() {
container<T> res;
...
return res;
}
みたいな関数をよく書くのですが、
最後の行を
return std::move(res);
にすれば使ってることになる?
33デフォルトの名無しさん:2012/10/12(金) 22:11:51.49
書かなくてもそうなる
34デフォルトの名無しさん:2012/10/12(金) 22:14:01.94
>>33
なるほど。
でもそれ以外のタイミングでコピーすることはないんだよなぁ。
自分のコーディングスタイルの問題なのかな?

・・・ちょっとスラドの記事よみ直してみます。
以前読んだけどありがたみがわからんかったので。
35デフォルトの名無しさん:2012/10/12(金) 22:18:26.47
ぱっと眺めてなんとなく思ったのは、人様のライブラリを作ったことがないからかも。
すべて自分で書くぶんには、でかいオブジェクトのコピーを避けるように意識してるから、
operator=とか使わない習慣ができちゃってるのかも。
36デフォルトの名無しさん:2012/10/12(金) 22:45:07.34
>>34
誰もコンテナのコピーの話なんてしてないぞ
要素のコピーの話しかしてない

従来仕様では push_back すら不可能
引数を使って新しい要素をコピーコンストラクトするから
非共有スマポは使えない
これがムーブできるようになったので大丈夫になった

メモリの再確保なんかもそうだな
37デフォルトの名無しさん:2012/10/12(金) 23:20:40.18
>>32
container<T>が特殊なリソースを保持するハンドラでコピーはできんけど
func みたいな生成関数を用意したい、てときにマジ便利
しかもそんな特殊なハンドラを標準コンテナにいれても良いンだぜ
38デフォルトの名無しさん:2012/10/13(土) 09:07:35.49
純粋仮想関数の書き方ってC++11でも
virtual void func() const = 0;
なんですか?
=0のかわりに=hoge
みたいなのが新しくできてたりしません?
39デフォルトの名無しさん:2012/10/13(土) 09:21:00.84
#define hoge 0
40デフォルトの名無しさん:2012/10/13(土) 09:43:18.84
= 0 があったら virtual は省略可にならないかな
41デフォルトの名無しさん:2012/10/13(土) 09:47:28.53
#define pure 0
virtual void func() const = pure;
42デフォルトの名無しさん:2012/10/13(土) 12:22:42.85
std::unordered_mapを使っていて、
std::_Hashtable<...>::_M_find_before_node(...)
が呼ばれまくってるのですが、これはハッシュ値の衝突と関係ありますか?
43デフォルトの名無しさん:2012/10/13(土) 13:40:29.58
いいえ
44デフォルトの名無しさん:2012/10/14(日) 02:49:32.87
質問者です。
ttp://gcc.gnu.org/onlinedocs/gcc-4.7.1/libstdc++/api/a01197_source.html
をみてみました。(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デフォルトの名無しさん:2012/10/14(日) 03:39:22.50
ここって、unordered_mapの実装について質問するところなのか
46デフォルトの名無しさん:2012/10/14(日) 08:41:27.79
まあ確かに相談室のほうに投下するべきだったけど。
上の件は、やはりハッシュ値の衝突が原因でした。
パフォーマンスが2倍変わったよ。
47デフォルトの名無しさん:2012/10/14(日) 12:47:17.59
boostみたいにshared_ptrのマルチスレッド対応をOFFにしたいんだけどどうすればできますか?
48デフォルトの名無しさん:2012/10/14(日) 15:00:01.57
無い
49デフォルトの名無しさん:2012/10/14(日) 15:10:44.55
まじすか…
C++の「使わないときにコストかけるな」っていう理念はどこにいったんですか?
50デフォルトの名無しさん:2012/10/14(日) 15:16:56.60
atomic_is_lock_free
51デフォルトの名無しさん:2012/10/14(日) 15:41:46.11
実装の問題を規格の思想に言われてもな
52デフォルトの名無しさん:2012/10/14(日) 15:49:32.67
まあ細かいこといったらC++からしたら「そんな義理は無い」ってことで終わりなんだろうけどさぁ
でもその理念を見失ったらC++のアイデンティティを失ったも同義だしほかの言語に全部持ってかれちゃうよ?
53デフォルトの名無しさん:2012/10/14(日) 15:50:04.51
どうぞどうぞご勝手に
54デフォルトの名無しさん:2012/10/14(日) 15:57:36.12
作るのに1時間もかからんしスレッドアンセーフっていうか無駄な機能最大限省いたSPつくりゃいいよね
stdのはライブラリのインターフェースに使ったりとにかく可搬性ある汎用的なコード書きたい場合だけでいい
55デフォルトの名無しさん:2012/10/14(日) 16:13:20.19
というかboost::shared_ptrでダメな理由がないんだが
std::shared_ptrはboostの劣化バージョンだから乗り換える理由が今のところない
56デフォルトの名無しさん:2012/10/14(日) 18:02:38.32
どのあたりが違うの
57デフォルトの名無しさん:2012/10/14(日) 19:58:17.15
constexpr boost::shared_ptr<int> p(nullptr);
static_assert(noexcept(p.reset()), "boost::shared_ptrでは今のところ無理");
58デフォルトの名無しさん:2012/10/15(月) 00:34:33.73
劣化バージョンというあたりを詳しく聞きたい
59デフォルトの名無しさん:2012/10/15(月) 12:42:04.47
boost::scoped_ptrはstd::unique_ptrに置き換えても大丈夫かな
60デフォルトの名無しさん:2012/10/15(月) 13:24:56.31
劣ってる部分有るか?
61デフォルトの名無しさん:2012/10/15(月) 17:04:14.06
業務連絡:gcc-4.8 に inheriting constructors が実装された模様
62デフォルトの名無しさん:2012/10/15(月) 17:41:54.63
後でコード追いにくくなる継承より
tuple返すメソッドでゴッソリ代入出来る構文を用意し欲しかった
63デフォルトの名無しさん:2012/10/15(月) 21:30:33.05
>>58
マルチスレッドをオフにできない
すでにブーストで書かれている過去の資産との親和性が低い
64デフォルトの名無しさん:2012/10/15(月) 22:47:04.00
お薬出しておきますね
65デフォルトの名無しさん:2012/10/15(月) 22:48:11.27
反論は論理的に
悪口だけのレスは無価値です
66デフォルトの名無しさん:2012/10/15(月) 23:29:32.92
>>63
> すでにブーストで書かれている過去の資産との親和性が低い

「ブーストで書かれている」が頭悪そう
67デフォルトの名無しさん:2012/10/15(月) 23:35:17.88
このスレかどうか忘れたけど
boost::shared_ptrとの相互運用の方法が書かれてたから
親和性はあるんじゃないかな
68デフォルトの名無しさん:2012/10/16(火) 01:00:48.96
前スレにあったな。
http://d.hatena.ne.jp/yohhoy/20120921/p1
69デフォルトの名無しさん:2012/10/16(火) 06:49:51.69
>>67
コストかかり過ぎ
70デフォルトの名無しさん:2012/10/16(火) 07:54:10.92
shared_ptr使ってる時点でコストを気にするもんじゃないと思うが
71デフォルトの名無しさん:2012/10/16(火) 08:08:43.91
>>70
だからただでさえやばいコストがさらに膨れ上がるんじゃ使い物にならない
72デフォルトの名無しさん:2012/10/16(火) 08:15:48.51
そりゃ相互運用にはコストがかかるもんさ。でも親和性とそれは全く別問題だよね。
少なくとも親和性は低くない、というかこれで相互乗り入れできるんだから親和性は結構高い
73デフォルトの名無しさん:2012/10/16(火) 08:50:39.38
でも結局両方使えるならノーコストのboost::shared_ptrが有利だろ?
結局のところstdのほうが無駄が多いことは同じ
74デフォルトの名無しさん:2012/10/16(火) 08:57:46.55
boost信者はこれだから困る。
実行時コストなんかどうでもいいんだよ。
標準ライブラリかどうかっていうのは致命的。

機能的に同じことをするなら標準の方法で
実装した方が後でメンテする人に迷惑がかからない。
今から入社してくる後輩に「おじいちゃんブーストって何?」
なんて聞かれたくないだろ。
75デフォルトの名無しさん:2012/10/16(火) 09:31:53.59
>>74
どうでもいいは言い過ぎ
…だが、そこ以外には激しく同意
会社では保守性一番
76デフォルトの名無しさん:2012/10/16(火) 09:52:30.99
boost使ったら保守性さがるとか驚きだなどんだけ低レベルのPGが集まってるんだ
コミュニティに提言したらどうだ?お前んとこのライブラリは糞だってな
77デフォルトの名無しさん:2012/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デフォルトの名無しさん:2012/10/16(火) 10:17:16.65
お薬増やしておきますね
79デフォルトの名無しさん:2012/10/16(火) 10:19:21.41
ほう。論理的反論は不可能なようだなwww
80デフォルトの名無しさん:2012/10/16(火) 10:49:56.91
boostは準標準と見ていいよ
stdの仕様決めるC++標準化委員会の人達がboostコミュニティの中心なんだし
81デフォルトの名無しさん:2012/10/16(火) 11:09:08.10
どこまで行っても準標準は標準にはなれないけどね
委員会メンバーもそれが分かっててわざわざ規格にブチ込んだわけだし
82デフォルトの名無しさん:2012/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デフォルトの名無しさん:2012/10/16(火) 20:19:23.87
まあ混在させるよりはどっちかで統一させた方がいいと思う
84デフォルトの名無しさん:2012/10/16(火) 20:23:14.10
>>83
となるとすでに使われてるboostなんだよなぁ
85デフォルトの名無しさん:2012/10/16(火) 20:38:01.39
完全新規案件ならstd::shared_ptrで
ただし、C++11が普及してからな
86デフォルトの名無しさん:2012/10/16(火) 22:57:26.18
>>85
現在は普及しているのか?
87デフォルトの名無しさん:2012/10/16(火) 22:59:21.70
してないな
少なくともVSが対応してからだな
88デフォルトの名無しさん:2012/10/17(水) 00:38:12.18
>>87
だとすると、「完全新規案件なら」というくだりは、まったく無意味な話か
89デフォルトの名無しさん:2012/10/17(水) 00:54:08.17
完全新規案件で、かつ、C++11が普及していたら、という条件文だろ
どこが無意味なんだ
90デフォルトの名無しさん:2012/10/17(水) 01:03:48.95
>>89
現時点では「C++11が普及していたら」が偽なので、少なくとも現時点では他に何が書かれていても無駄になる。
91デフォルトの名無しさん:2012/10/17(水) 01:05:21.91
>>85
何をもって普及したとみなせるのか書いてないから
他人からすれば何も言ってないに等しいな
当人の脳内では自明なんだろうけど
92デフォルトの名無しさん:2012/10/17(水) 01:17:01.29
>>90
>現時点では「C++11が普及していたら」が偽
Linux界隈ではVC気にしなくていいから、局所的な見方ができるなら偽と言い切れるものではないな
実際にはC++11でかつLinux案件とかを想定してるんじゃね

もちろん、何を以て普及したと見做すのかは>>89に聞かないと分からんけどな
(そしてその答えによっては>>89の文章全体が無意味になる)
93デフォルトの名無しさん:2012/10/17(水) 01:48:48.77
してからな、って言ってるように、
今はまだ厳しいというイメージで言った
94デフォルトの名無しさん:2012/10/17(水) 02:03:08.23
イメージとかそういうのはどうでもいい
95デフォルトの名無しさん:2012/10/17(水) 02:06:51.96
脳内自明なイメージを
表現することなく
十分に書けたつもりに
96デフォルトの名無しさん:2012/10/17(水) 09:11:38.32
Macで使えれば十分だよ
今後Mac以外は廃れるから考慮しなくてよい
97デフォルトの名無しさん:2012/10/17(水) 18:42:30.11
おう
98デフォルトの名無しさん:2012/10/17(水) 21:42:49.10
Macはもうない
99デフォルトの名無しさん:2012/10/17(水) 22:19:33.35
今C++11やるならMacかLinux
普通はMacを使う
100デフォルトの名無しさん:2012/10/17(水) 22:38:27.59
Mac以外のマシンは滅ぼせ!
101デフォルトの名無しさん:2012/10/17(水) 22:42:57.11
Xcodeで使えるのん?
102デフォルトの名無しさん:2012/10/18(木) 07:58:16.13
MacPortsが更新遅すぎて(最新から1年遅れとかザラ)使う気にならない。
更新されてもGCCとかソースからコンパイルしよるから、その間なにすればいいの状態w
103デフォルトの名無しさん:2012/10/18(木) 08:00:54.28
Fortran77が死なない理由は優秀なライブラリだよね・・・
C++03でそんな事情はないから多分そのうち死んでくれると思う。
それよりCが死んでくれないことが大問題だよ。
104デフォルトの名無しさん:2012/10/18(木) 08:03:03.84
連投スマソ。
C++11で導入された標準ライブラリの速度が出ないんだけど、
そのうち改善されていく見込みはあるんだろうか?
現時点のGCCは成熟度何%くらいだと思ってたらいいか分かる人いる?
105デフォルトの名無しさん:2012/10/18(木) 08:10:19.67
Cが死ぬ前にC++が死ぬよ
106デフォルトの名無しさん:2012/10/18(木) 08:13:33.58
まぁそんな気がする。
しかしここ数年、言語界のアイディアも枯渇しててC++11でしばらくは行けそうな感じだよな。
すくなくとも逐次計算にかぎれば。
並列計算に特化した言語モデル(でまともなの)が出てくれば死ぬかも。
107デフォルトの名無しさん:2012/10/18(木) 08:29:09.46
>>104
11は速度をあきらめて扱いの楽さを優先したから速度でないのは当たり前だよ
今はどうしても速さがほしいならいままでどおりC/C++03を
楽さを求めるならほかの言語をって感じ
108デフォルトの名無しさん:2012/10/18(木) 10:39:22.72
>>107
なるほど。
では今後に期待〜
109デフォルトの名無しさん:2012/10/18(木) 15:48:17.03
>>107
え?
110デフォルトの名無しさん:2012/10/18(木) 15:52:08.60
>>107
規格の影響を受ける問題じゃあるまいし
111デフォルトの名無しさん:2012/10/18(木) 15:56:17.41
>>110
なにいってんの?
112デフォルトの名無しさん:2012/10/18(木) 16:00:31.15
C++11にしたら速度が出ないという妄想の話?
113デフォルトの名無しさん:2012/10/18(木) 16:19:35.62
STLは右辺値参照を使って大幅に書き直されているから速度が上がってるだろ
スピードが出ないのはiostreamとかfstreamの話だろ?

あれほどstd::ios::sync_with_stdio(false); を実行しとけと言ってるのに
それかcstdioだけを使うか
114デフォルトの名無しさん:2012/10/18(木) 16:31:59.01
ワロタ
もともと最適化あるから右辺値参照ぐらいじゃ大して変わらんよ
それよりshared_ptrやスレッドがバカに乱用されてパフォーマンス悪くバグが増えることが問題
115デフォルトの名無しさん:2012/10/18(木) 16:35:42.19
>>114
http://blogs.msdn.com/b/vcblog/archive/2009/06/23/stl-performance.aspx

よく調べてから物を言えよ
恥かくだけだぞ
116デフォルトの名無しさん:2012/10/18(木) 16:36:32.38
あとこんなのもあるなあ

http://cpp-next.com/archive/2010/10/howards-stl-move-semantics-benchmark/

こちらは無名のブログなので自分で検証してみ
117デフォルトの名無しさん:2012/10/18(木) 21:40:43.97
結局参照もポインタと同じ道を辿ったな
わかりにくく使いづらく扱いを誤れば危険だしパフォーマンスも落とすクソ機能
その分色んなことが出来るからいいんだいという反論があるだろが、
参照はポインタほどの融通も効かないから中途半端
118デフォルトの名無しさん:2012/10/18(木) 22:14:12.43
STLで右辺値参照使ってると言っても
ムーブが定義されてなきゃ今まで通りなんでしょ?
遅くなるってどういう事だよ
119デフォルトの名無しさん:2012/10/18(木) 22:22:17.57
一応、(リンク時にdead code eliminationしなきゃ)
関数の数が増える=実行ファイルサイズが増える=コードがキャッシュに乗る率が減る=遅くなる
かもしれない
120デフォルトの名無しさん:2012/10/18(木) 22:28:39.64
dead code elimination も何も
クラステンプレートは使わないメンバ関数は
実体化しないという仕様だから
121デフォルトの名無しさん:2012/10/19(金) 10:56:10.40
>>117
使い方を誤る奴が悪い終了
122デフォルトの名無しさん:2012/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デフォルトの名無しさん:2012/10/19(金) 21:12:23.15
関数内どんだけ肥大化させる気?
124デフォルトの名無しさん:2012/10/19(金) 21:21:14.01
関数内でテンプレートってそもそも必要?
125デフォルトの名無しさん:2012/10/19(金) 21:28:30.12
引数の型書くのが面倒なんよ
そう思わないか?
ラムダがあればファンクタ書くのは楽になるが中途半端だ
どうせならとことん楽したいやん
126デフォルトの名無しさん:2012/10/19(金) 21:36:48.84
template <typename T> と書く手間で
typedef decltype(a) T; が書ける
127デフォルトの名無しさん:2012/10/20(土) 00:21:49.05
C++1yで多相ラムダが使えるようになるまでの我慢我慢
128デフォルトの名無しさん:2012/10/20(土) 10:24:25.79
>>127
2年くらい前にこのスレで[](auto&){...}使えるといいねって話をしたら
バカにされてあえなく撤退したわw
129デフォルトの名無しさん:2012/10/20(土) 12:56:01.55
>128
型が記述位置で一意にならないんじゃね?テンプレートなきゃムリだろ。
130デフォルトの名無しさん:2012/10/20(土) 13:14:06.10
別にそれでいいじゃん
131デフォルトの名無しさん:2012/10/20(土) 13:24:30.56
>>129
2年前にまったく同じ事を言われた。
コンパイラ作ってる人からすればそうだろうけど、利用者からすればまったく自然な発想。
テンプレートでいいから何とかしてくれ。
sort(v.begin(),v.end(),[](const super_complicated_template_container_type::super_long_named_value_type& x){return x+1;});
とか、アホくさくて耐えられないw
132デフォルトの名無しさん:2012/10/20(土) 13:26:02.36
適当に書いたけどsort用のラムダじゃなかったな。
比較関数になるとさらに醜いことになる。
133デフォルトの名無しさん:2012/10/20(土) 13:46:15.50
decltype((x)) const &

まあoperator()がテンプレートなファンクタはもとからできるので実装上の問題はなく構文をどうするかだろう
一般の関数にまで拡張して void f(auto x) を template<class T> void f(T x) のシンタックスシュガーにするかとかにまで広がるだろうし
134デフォルトの名無しさん:2012/10/20(土) 13:54:41.97
ん、xじゃないな
135デフォルトの名無しさん:2012/10/20(土) 14:46:05.38
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
>>131の例なら
sort(v.begin(),v.end(),[](const &x) x+1);
にしようぜってのが今の提案
136デフォルトの名無しさん:2012/10/20(土) 17:44:51.28
>>135
いいね!
搭載までにどれくらいかかるのか分かりませんが期待してます。
137デフォルトの名無しさん:2012/10/21(日) 22:37:41.22
というか一番最初のラムダのペーパーはすげえ短く書けてwktkだったんだがな... まだ[]が<>だったころ

だまされたー!
138デフォルトの名無しさん:2012/10/21(日) 23:16:30.59
C#と同じ書式にしてしまうのはダメなんかなぁ
…ユーザーオブジェクトの扱いが違うからダメか…

sort(v.begin(), v.end(), x => x+1);
139デフォルトの名無しさん:2012/10/23(火) 09:15:20.10
今C++11何か使ったら理解できないやつが続出して全てが自分に回ってきそうで、取り敢えずようす見ることにしてるわ。
140デフォルトの名無しさん:2012/10/23(火) 09:35:02.93
cpp3よりわかりやすいと思うけど?
一回教えれば今より面倒も減ると思う
141デフォルトの名無しさん:2012/10/23(火) 10:33:23.26
他にもっといいラムダ式の書式があったのかもしれないが、C++11標準化委員会が
新しいアイデアを待ったけど誰も出してこないのでこういう変な格好に落ち着いたらしい

まあタイプ量が少なくて直感的だからいいんじゃね
142デフォルトの名無しさん:2012/10/23(火) 10:36:57.12
仮想プロパティはいつになったら使えるようになるねん
143デフォルトの名無しさん:2012/10/23(火) 22:16:53.45
>>139
会社で使う人はそういう悩みもあるのか・・・
11を03のソースに変換するツールとかあれば自分だけ使えてウハウハになれるでしょうか?
144デフォルトの名無しさん:2012/10/23(火) 22:39:57.88
マ板行けよ。
145デフォルトの名無しさん:2012/10/23(火) 23:02:22.30
C++11難しくないだろ
C++03の方がよほど面倒だぞ
146デフォルトの名無しさん:2012/10/23(火) 23:17:54.28
C++03より簡単に書ける、のは確かだけれど、
C++11はC++03互換の形式でも書けるようになってるので、結果的に複雑。
難しくない、というのは言い過ぎ
147デフォルトの名無しさん:2012/10/23(火) 23:40:40.96
11で切り捨てられる機能って何かある?
たとえば副作用のあるラムダは外部に変数定義しないといけないから、
カプセル化を破ってしまう。カプセル化するためには関数オブジェクトが必要。
完全にdeprecateされた言語機能ってそれほどないのでは?
アルゴリズム、コンテナ、どちらも増えただけだし・・・。
148デフォルトの名無しさん:2012/10/23(火) 23:50:54.98
完全に削除されたexportがあるだろ
149デフォルトの名無しさん:2012/10/24(水) 00:37:49.63
折角 export を実装した Comeau C++ が可哀想です
150デフォルトの名無しさん:2012/10/24(水) 01:16:07.92
export実装する前にtemplateのネストを実装すればよかったw > Comeau
151デフォルトの名無しさん:2012/11/02(金) 20:39:03.23
やっぱり、これからは並列処理が簡単にできる言語の時代かも
152デフォルトの名無しさん:2012/11/02(金) 22:24:19.84
提案にいくつか並列化関係のあるよな
TR2に入ったらうれしい
153デフォルトの名無しさん:2012/11/04(日) 11:32:05.24
規格の発行から1年以上経ってるんだけど
本の虫の本はまだなの?
154デフォルトの名無しさん:2012/11/04(日) 20:25:09.35
さあ
C++の仕様は難解かつ膨大で、あれを隅々まで理解して
解説書出すのはかなり難儀な仕事だと思う
155デフォルトの名無しさん:2012/11/04(日) 20:26:11.69
禿は出さないのか
156デフォルトの名無しさん:2012/11/04(日) 20:31:05.23
すっぽすっぽ先生の解説を翻訳すりゃいいんじゃねーかと思う。
157デフォルトの名無しさん:2012/11/04(日) 20:49:42.94
本の虫の本を買ったら負けだと思っている
158デフォルトの名無しさん:2012/11/04(日) 21:20:26.75
すっぽすっぽ大先生は要点は押さえて概説は書けるだろうけど、
規格の隅々に微に入り細に入りしたような詳説は書けないし、また書く時間もないだろうな。
159デフォルトの名無しさん:2012/11/04(日) 21:28:36.57
Cの時点でさえCリファレンスマニュアルがないと
細部をあらかた理解するのは難しいのに
160デフォルトの名無しさん:2012/11/04(日) 21:32:10.41
世の中のプログラマーの99%は
言語仕様も知らずに適当に書いてるから
OK
161デフォルトの名無しさん:2012/11/04(日) 21:39:34.83
禿、どうも及び腰っぽいんだよなあ・・・ 寂しいなあ
だからこそ、こないだ出た動画は食い入るように見た
162デフォルトの名無しさん:2012/11/04(日) 21:40:36.91
void f( A const& a, B const& b );
void f( A&& a, B const& b );
void f( A const& a, B&& b );
void f( A&& a, B&& b );

こういうのって全部用意しなきゃいかんの?
template のときは特別扱いがあるらしいのは分かったんだけど、
だからってあらうる関数の引数を template にしてしまうわけにもいかないし…。
163デフォルトの名無しさん:2012/11/04(日) 21:50:45.01
いや、template にしろって意味だよ
164デフォルトの名無しさん:2012/11/04(日) 22:02:32.75
>>163
まぢっすか。オーバーロードしたいときとかどうするんだ。
165デフォルトの名無しさん:2012/11/04(日) 22:06:59.12
値渡しでmoveすればという意見もある。
void f(A a, B b) {
 std::move(a);
}
166デフォルトの名無しさん:2012/11/04(日) 22:09:39.46
>>164
そもそもテンプレートがオーバーロードできるし
is_rvalue_referenceまであるやろ
167デフォルトの名無しさん:2012/11/04(日) 22:31:40.88
>>166
あんまり意味ない例だけど、
f( vector<int>& );
f( vector<int>&& );
f( deque<int>& );
f( deque<int>&& );
こういうオーバーロードしたいときに、
template<class T> f( T&& );
で同じことをするのは、可能ではあっても面倒だと思うんだけど。
168デフォルトの名無しさん:2012/11/04(日) 23:00:16.82
具体的にどういうシーンで162みたいなコードが必要になるの?
169デフォルトの名無しさん:2012/11/04(日) 23:00:55.51
>>167
そのケースで特殊化もアホくせえけど
左辺値参照は黒歴史でいいし
テンプレートテンプレート引数もクールだぜ
170デフォルトの名無しさん:2012/11/04(日) 23:04:58.98
>>162
引数にアダプタかませばいいよ
171デフォルトの名無しさん:2012/11/04(日) 23:08:02.75
>>168
例えば container.push_pair( x, y ); 的な。
172デフォルトの名無しさん:2012/11/04(日) 23:34:38.09
>>168
operator+ なんかで頻出。
たとえば A + B はconst参照で済ましたいけど、
A + B + C だと一時オブジェクトができるのでmoveしたい。
173デフォルトの名無しさん:2012/11/04(日) 23:45:17.42
左辺値の場合には目を瞑って>>165みたいに値渡しとmoveするのが手軽な解決法だと思う
174デフォルトの名無しさん:2012/11/05(月) 00:05:03.89
>>172
その程度ならテンプレートでいいじゃん
>>162みたいなのが要求されてて更に翻訳単位わけないとだめな程度の規模の関数ってなに?
175デフォルトの名無しさん:2012/11/05(月) 00:07:36.45
スレ違いだろ、初心者スレ行け。
176デフォルトの名無しさん:2012/11/05(月) 00:42:01.15
そろそろ post-Portland mailing の公表の時期ですな。
177デフォルトの名無しさん:2012/11/05(月) 11:36:40.60
template <class ...Args>
void f(Args&& ...args)
{
  [ /*どうキャプチャしたらいいの?*/ ]
  {
    std::printf(args...);
  }();
}

int main(){ f("%s\n", "Hello, world!"); }
178デフォルトの名無しさん:2012/11/05(月) 13:02:13.25
>>177
[args...]
ただしGCC4.7ではエラーになって通らない(他のコンパイラ・バーションでは知らない)

可能ならとりあえず引数で代替
[](Args ... args) { std::printf(args ...); }(args ...);
179デフォルトの名無しさん:2012/11/05(月) 17:24:51.02
> [args...]
そうだよねえ、そんな気がしたんだけど gcc は trunk でもだめだった

このラムダを普通のクラステンプレートを使って書き換えようとしたら、
可変個メンバーみたいなのを持たせないといけないから (不可能)
そもそも禁止されてるのかもしれないとも思った
180デフォルトの名無しさん:2012/11/05(月) 17:39:40.49
N3337だと5.1.2の23に例が載ってるな
181デフォルトの名無しさん:2012/11/05(月) 20:01:12.84
>>179
> このラムダを普通のクラステンプレートを使って書き換えようとしたら、
> 可変個メンバーみたいなのを持たせないといけないから (不可能)
ファンクタがローカルクラスじゃなくなっちゃうがboost.fusion使えばできるぞ

#include <cstdio>
#include <boost/fusion/container/vector.hpp>
#include <boost/fusion/functional.hpp>

template<class... T>
struct F
{
boost::fusion::vector<T...> args;
F(T... a) : args(a...) {}
auto operator()() -> decltype(boost::fusion::invoke_procedure(std::printf, args))
{
boost::fusion::invoke_procedure(std::printf, args);
}
};

template <class... Args>
void f(Args... args)
{
F<Args...> f(args...);
f();
}

int main()
{
f("%s\n", "Hello, world!");
}
182デフォルトの名無しさん:2012/11/05(月) 20:09:55.55
ほんとだ載ってた
コンパイラが悪いのね
183はちみつ餃子 ◆8X2XSCHEME :2012/11/05(月) 21:13:08.87
悪いっていうか追い付いてない感じ。
もう C++ の拡張はそろそろ限界だろ。
184デフォルトの名無しさん:2012/11/05(月) 21:35:58.08
185デフォルトの名無しさん:2012/11/06(火) 03:59:34.40
2進リテラル・・・
186デフォルトの名無しさん:2012/11/06(火) 07:14:25.77
胸熱
187デフォルトの名無しさん:2012/11/06(火) 07:26:58.90
いや、この2進リテラル全然駄目だろ
D言語みたいにセパレータを入れられるようにしないと
訳分からなくなるぞ
188デフォルトの名無しさん:2012/11/06(火) 07:47:12.84
桁区切りの提案はN3342がある
189デフォルトの名無しさん:2012/11/06(火) 18:24:00.36
2進リテラルなんかいる訳ねえだろwwww却下wwwww(2008頃)

せっかくユーザー定義リテラルがあるから2進リテラルライブラリ作ろうぜ(N3402)

こんな小汚いライブラリが標準になるくらいならコア言語でサポートしよう(Portland)

なにこれ
190デフォルトの名無しさん:2012/11/06(火) 18:28:27.07
C++0xスレ名物だった0b戦争に終止符が打たれるのか
191デフォルトの名無しさん:2012/11/06(火) 18:55:33.35
区切りなしで 48bit とか拷問だろ
192デフォルトの名無しさん:2012/11/06(火) 19:12:50.66
concept、インディアナvsテキサスでもっと盛り上がるかと思ったが、
以外にあっさりと収斂しそうな気配だな。テキサス寄りになりそうな気配だが、
基礎的な研究面でのインディアナ大学の貢献が素晴らしすぎる。
193デフォルトの名無しさん:2012/11/06(火) 19:37:39.34
>>189
昔は2進リテラル必要はなかったんだよ
まだ8進や16進で十分理解できる頃のC畑のやつらばっかりだったからな
時代が変わったってことだろ
194デフォルトの名無しさん:2012/11/06(火) 21:09:49.72
Verilog・VHDLみたいな超低水準を扱う言語だと
2進リテラルは普通にあるから、
ビットを扱うにあたっての必然性は強いと思うけどなあ

処理系の実装が難しいわけでもなさそうだし、何が問題なの?
もしくはなぜ歴史的に無かったのかが気になる
195デフォルトの名無しさん:2012/11/06(火) 21:38:01.47
>>188
ああ、2進数とは別に案があるのね

>>194
パッと見01がずらっと並んでたら見辛いからとかなのかね
196デフォルトの名無しさん:2012/11/06(火) 22:17:26.79
C++標準委員の皆さんはなんでXMLパーサーなどなど実用殿高い有用なライブラリを標準にしないでお遊びみたいな部分ばかり強化してドヤ顔さらしてるんですか?恥ずかしくないんですか?
197デフォルトの名無しさん:2012/11/06(火) 22:49:00.80
>>194
昔は8進があればいいという人が主流だったので。
8進が好まれた理由は省スペース、少入力のはず。
昔はパンチカードでコーディングしてたから。

俺も16進あれば問題ない。2進があってもいいが。

>>196
応用は範疇外です。
198デフォルトの名無しさん:2012/11/06(火) 22:55:18.38
boostのスレでも暴れてたやつだから触るなよ
199デフォルトの名無しさん:2012/11/06(火) 23:43:16.05
2進はあっても使わないな。16進で十分。
あとXMLパーサにはW3C DOMっつー標準仕様があるだろうに。
200デフォルトの名無しさん:2012/11/07(水) 00:11:31.18
マイコン用のC++コンパイラに二進数リテラルが実装されていてよく使った覚えがあるけど逆にそういうハードよりのコードじゃないとほぼ出番無いかもね

ところで自分はstd::signatureにとても期待しているのだけれどもC++1yでリフレクションのサポートは一体どれくらい進むのだろうか
201デフォルトの名無しさん:2012/11/07(水) 00:44:24.70
Serialization
Parallel hierarchies
Overloading reflection and more perfect forwarding
Delegates
Getter/Setter generation
enum information
Capturing default arguments
と応用も広いし、何がしか入るんじゃないかな。
202デフォルトの名無しさん:2012/11/07(水) 09:46:03.94
>196
そういうのはQtで出来るから標準には要らない
203デフォルトの名無しさん:2012/11/07(水) 12:52:51.06
>>202
サードパーティにあるからいらないと言ったら全部いらないだろ
204デフォルトの名無しさん:2012/11/07(水) 12:59:34.23
標準でなんでもかんでも詰め込もうとすると Java みたいなことになっちゃうからだめよ
205デフォルトの名無しさん:2012/11/07(水) 16:23:33.59
Java便利だよ
206デフォルトの名無しさん:2012/11/07(水) 16:24:26.47
>>165, >>173
なるほど。 C++11 なら値渡しもアリなのか。 move が一回増えるのをどう見るかだなー。
207デフォルトの名無しさん:2012/11/07(水) 19:41:10.90
>>194
HDLは4値(以上)だからビットで書かざるを得ないけど、
2値だったら無きゃ無いで済むよ。
208デフォルトの名無しさん:2012/11/07(水) 20:07:57.11
JavaやPythonみたいに最初から全部入りがいい!って人もいるだろうけどね
209デフォルトの名無しさん:2012/11/07(水) 20:16:22.17
何をするにもライブラリ探してこないといけないとか面倒くさいことこの上ない
210デフォルトの名無しさん:2012/11/07(水) 20:58:59.68
共通規格を決めてるのに、一過性のファイルフォーマットに過ぎないものを含めるはずがない
211デフォルトの名無しさん:2012/11/07(水) 21:04:57.00
一過性でもいいから含めてくれ
そんなだからC++は・・・
212デフォルトの名無しさん:2012/11/07(水) 21:57:01.06
>>211
お前の思いは分かった。
だが、捨て置く。
213デフォルトの名無しさん:2012/11/07(水) 21:58:17.94
捨て置かれるのはC++の方であった
214デフォルトの名無しさん:2012/11/07(水) 22:13:30.27
全部入りってアンチパターンじゃねえかよ
215デフォルトの名無しさん:2012/11/07(水) 22:17:25.03
yutori
216194:2012/11/07(水) 22:19:47.18
>>195
>>197
>>207
なるほど感謝。バイナリアンの人は8/16進でも読めるから、
わざわざ冗長な2進表記を用意する必要性がないって感じか
全体として消極的反対が目立つのかなあ
217デフォルトの名無しさん:2012/11/07(水) 23:35:31.33
最小セットと便利ライブラリに分ければよい
218はちみつ餃子 ◆8X2XSCHEME :2012/11/07(水) 23:45:03.43
無理に標準化せずに面倒そうなやつは全部 Boost に集約しとけばいいよ。
219デフォルトの名無しさん:2012/11/08(木) 01:15:14.74
日本語のちゃんとした解説書、
いつになったら出るの?
220デフォルトの名無しさん:2012/11/08(木) 02:22:25.64
XMLはもうboostので十分だろ。
221デフォルトの名無しさん:2012/11/08(木) 02:25:56.13
>>219
いつかは出ると思ってるのか。
出ないという展開に100ペリカ
222デフォルトの名無しさん:2012/11/08(木) 02:52:06.55
流行()のオープンプロジェクトで翻訳でもすりゃいいんじゃね。

現場で使えるようになるまでは、コンパイラ製作してるやつもあんまいないし需要も供給もそりゃないだろうよ。
223デフォルトの名無しさん:2012/11/08(木) 02:52:40.58
Common Lispの分厚い解説書がCLtL2で止まってるのを彷彿とさせる……
224デフォルトの名無しさん:2012/11/08(木) 06:10:35.76
>>216
2進に特化したリテラル表現導入なんて本来ANSI Cの領分で、
C++だけでやるならC++的に意味のある形でないと。
225デフォルトの名無しさん:2012/11/08(木) 09:10:12.69
翻訳しようにもライセンス的に白な原本あるの?
226デフォルトの名無しさん:2012/11/08(木) 12:59:50.04
constexpr unsigned long long operator "" _c (const char* str)
{
return
[](const char* first, const char* last) -> unsigned long long
{
return *last ? koko_nantekakunda(first, last + 1) :
[](const char* first, const char* last) -> unsigned long long
{
first == last ? 0 : ugugugu(first, last - 1) << 1 | last[-1] & 1;
}(first, last);
}(str, str + 1);
}
227デフォルトの名無しさん:2012/11/08(木) 13:00:46.78
あ、間違えた _bin ね
228デフォルトの名無しさん:2012/11/08(木) 13:18:22.80
適当でもいいから battery included がいい、って人がなんで C++1y のスレッドにいるんだろう…。

まあでも、 boost みたいにガチガチの設計じゃなくて、もう少し肩の力を抜いたゆるふわライブラリが
あってもいいかなーと思うこともある。 Qt とか、 STL, boost に比べるとゆるふわしていて、
モサいなあと思いつつもけっこう便利だったりする。

C++ の面倒さって、ライブラリの設計が一般化とか例外安全とかを頑張りすぎてるのが一つの原因だと
思うのだよな。
229デフォルトの名無しさん:2012/11/08(木) 15:10:13.38
>>225
JIS X 3015
230デフォルトの名無しさん:2012/11/08(木) 15:46:36.65
>>228
それぞれが背丈に見合ったライブラリを使えばいい。
次期仕様を話すスレで「肩の力を抜いたゆるふわライブラリ」の話なんか出るわけない。
231デフォルトの名無しさん:2012/11/08(木) 15:58:10.51
>>229
JISは見れなくなって久しいな
IE8/9、Chromeいずれでも見れない
232デフォルトの名無しさん:2012/11/08(木) 17:40:51.45
>>224
www.open-std.org/jtc1/sc22/wg14/の方でも、
整定数の2進表現は議論されてないっぽい。
233デフォルトの名無しさん:2012/11/08(木) 19:21:47.35
C++11 で非推奨になった機能一覧みたいなのってある?
234デフォルトの名無しさん:2012/11/08(木) 19:41:11.21
>>233
規格票の巻末にある Annex D がもろにそれ
235デフォルトの名無しさん:2012/11/08(木) 20:27:18.91
>>234
ありがと。
deprecated になっている言語仕様って、こんなに少ないんだ。
236デフォルトの名無しさん:2012/11/08(木) 21:25:25.00
ライブラリでかくないし、慎重に規格を更新してるのに、
多かったらむしろやばいだろ。
237デフォルトの名無しさん:2012/11/08(木) 23:09:09.54
C++11 の専門書って出てますか?
238デフォルトの名無しさん:2012/11/08(木) 23:18:12.99
C++11も解説している洋書なら
239デフォルトの名無しさん:2012/11/08(木) 23:25:35.26
EffectiveなメイヤーさんがPDFを売ってるよ。
240デフォルトの名無しさん:2012/11/08(木) 23:27:53.59
確か組み込み向けも出してなかったっけ
241デフォルトの名無しさん:2012/11/10(土) 13:24:08.67
2進数リテラルなんかまともなプログラマには必要ないし誰も欲しがってない

でもユーザー定義リテラルで独自実装が蔓延し標準ライブラリの提案まで出てきてしまった

状況が悪化しないように仕方なく2進数リテラルをサポートする事に


あれ?全部ユーザー定義リテラルさんのせいじゃね
242デフォルトの名無しさん:2012/11/10(土) 14:37:39.58
2進数リテラル採用する前にリテラルの区切りを標準化しる
243デフォルトの名無しさん:2012/11/10(土) 14:45:42.33
前じゃないといけないのか?
n3472は同時にやるぜ?
244デフォルトの名無しさん:2012/11/10(土) 14:47:24.66
マジかよn3472さんマジかっけーな
245デフォルトの名無しさん:2012/11/10(土) 15:33:45.41
入れてねえよ。それは他でやってくれって書いてるw
246デフォルトの名無しさん:2012/11/10(土) 18:35:55.73
64bitだと16進数でも桁数大杉でワケワカラン
247デフォルトの名無しさん:2012/11/10(土) 19:11:39.83
64bitって16桁だろ?

0000,0000,0000,0000〜FFFF,FFFF,FFFF,FFFF

セパレータさえあれば、そんなに多くは感じないような
248デフォルトの名無しさん:2012/11/10(土) 19:15:04.34
セパレータがないからワケワカランっつってんだ
249デフォルトの名無しさん:2012/11/11(日) 01:13:33.59
文字列で書いてパーサに渡せばOK
unsigned int n = toInt("0000,0000,...,0000");
250デフォルトの名無しさん:2012/11/11(日) 01:22:41.13
Rubyだとアンダースコアを使うな

1111_2222_3333_4444

字句解析器にちょっと手を入れれば実装できそうだが
何かと衝突しそうな気がしないでもない
C++は複雑すぎて、何に手を入れると何が起きるのか想像がつかない
251デフォルトの名無しさん:2012/11/11(日) 01:42:42.35
文字列をコンパイル時に変換したらあかんのか
252デフォルトの名無しさん:2012/11/11(日) 01:43:55.10
invalid な文字列を渡されたとき、エラーが出せなくない?
253デフォルトの名無しさん:2012/11/11(日) 01:59:46.30
int a = 0;
のときの 0 は 8 進リテラル
これ豆な
254デフォルトの名無しさん:2012/11/11(日) 02:17:43.01
それは 10 進や 16 進リテラルとして扱われるのとどう違うんですか
255デフォルトの名無しさん:2012/11/11(日) 08:06:36.88
>>250
そういえばアンダースコアのみの識別子ってlexerに許されてたっけ?
111 _ 222 _ 333 _ 4444 と切られて、_がなんかにdefineされてたら、とかちんぷんかんぷんに
256デフォルトの名無しさん:2012/11/11(日) 08:28:42.56
許されてるよ
257デフォルトの名無しさん:2012/11/11(日) 13:49:01.09
ioccc の常套手段
258デフォルトの名無しさん:2012/11/12(月) 18:18:22.75
ねえねえ

int main()
{
 [__func__]{std::cout<<__func__;}();
}

これどうなるべきなの?
259デフォルトの名無しさん:2012/11/12(月) 18:23:12.95
コンパイルエラーになるべき
260デフォルトの名無しさん:2012/11/12(月) 20:53:51.01
なんで?
261デフォルトの名無しさん:2012/11/12(月) 20:57:12.34
__func__は変数じゃないんだからキャプチャできない
262デフォルトの名無しさん:2012/11/12(月) 21:25:35.40
いや __func__ は関数に局所的な変数で、マクロではない
263デフォルトの名無しさん:2012/11/12(月) 21:27:42.10
>>258
実装定義のoperator()を意味する名前が表示されるべき
264デフォルトの名無しさん:2012/11/12(月) 21:30:30.64
いや、__func__ は static const char* の変数だよ。
だからキャプチャされるべきだよ。(gcc はしてくれないけど)

ただし、ラムダ内で暗黙に定義される __func__ と被るから、
ラムダのやつが優先されてしまうけど。
265デフォルトの名無しさん:2012/11/12(月) 21:49:19.40
ポインタじゃなく配列な
266264:2012/11/12(月) 21:49:39.51
違った。

5.1.2 Lambda expressions

10 ... each such lookup shall find a variable with automatic storage duration ...
11 ... its compound statement odr-uses this or a variable with automatic storage duration...

だから、自動変数しかキャプチャできない。
だから static に定義される __func__ はキャプチャできない。

ちなみに gcc 4.8 は、static な変数を = でキャプチャしたら面白い挙動になる。

static int a = 0; [a]{ ++a; }();
267デフォルトの名無しさん:2012/11/15(木) 21:11:56.01
emplace_back()はこんな場合に使うといいのでしょうか
268デフォルトの名無しさん:2012/11/15(木) 21:12:20.80
あ、コード貼り忘れました

class BigArray {
static const int MX = 10000;
double d[MX];
};

const int ITER = 2000;

int main()
{
time_t t1;
std::vector<BigArray> ba;

{
t1 = std::time(0);
for (int i = 0; i < ITER; i++)
ba.push_back(BigArray());
std::cout << "Elapsed time = " << std::time(0) - t1 << std::endl;
}

ba.shrink_to_fit();

{
t1 = std::time(0);
for (int i = 0; i < ITER; i++)
ba.emplace_back();
std::cout << "Elapsed time = " << std::time(0) - t1 << std::endl;
}
}
269デフォルトの名無しさん:2012/11/15(木) 21:39:42.57
270デフォルトの名無しさん:2012/11/15(木) 22:15:00.85
そういうときに使うのは間違ってはいないんだが
その例だとvectorの再確保が起きるたびにBigArrayのコピーが生じるんでやはり効率は悪い
271デフォルトの名無しさん:2012/11/16(金) 05:41:05.77
deque
272デフォルトの名無しさん:2012/11/19(月) 00:49:52.27
なんでthrowって非推奨になったの?
どんな例外が投げられるか分かるようにできたほうが、いいと思うんだけれど
273デフォルトの名無しさん:2012/11/19(月) 01:13:38.64
それ以外の例外を投げたら即死するから
274デフォルトの名無しさん:2012/11/19(月) 01:17:54.69
Javaのthrow()は、それ以外の例外を投げようとするとコンパイル時にエラーが出る
(一部の一般的な例外はスルーされるけど)

C++では実行時にエラーが出るだけで、コンパイル時にチェックしてくれるわけではない
だからあまり書く意味が無い
275デフォルトの名無しさん:2012/11/19(月) 01:47:47.07
さらに中途半端に書いてあると他は飛んでこないと勘違いする害がある。
276デフォルトの名無しさん:2012/11/19(月) 02:17:28.20
>>274みたいなことは不可能じゃないけど無理ゲーってことですね分かります
Javaとは違うのだよJavaとは
277デフォルトの名無しさん:2012/11/19(月) 13:44:50.56
例外、1y でごっそり刷新になって欲しい
ゼロオーバーヘッドじゃない C++ なんて笑い事じゃない
278デフォルトの名無しさん:2012/11/19(月) 14:25:12.94
とりあえず具体的な改善案がなければ据え置きでしょうな
279デフォルトの名無しさん:2012/11/19(月) 20:07:32.70
Windows8のTwitterクライアントが公開停止、API利用制限で
http://engawa.2ch.net/test/read.cgi/poverty/1353315388/
280デフォルトの名無しさん:2012/11/19(月) 23:11:33.83
>>274
コンパイル時にチェックされればいいというわけでもない。
それを採用した Java で得られた結果は悲しいものだった。
http://www.google.co.jp/search?q=checked+exception
281デフォルトの名無しさん:2012/11/19(月) 23:13:03.63
>>277
例外が「ゼロオーバーヘッド」じゃないというのは、どんなオーバーヘッドのことを指して言ってるの?
そのオーバーヘッドはほんとうに規格が強制してしまっているものなの?
282デフォルトの名無しさん:2012/11/19(月) 23:29:54.44
何が飛んでくるかなんてコンパイル時にはわからんし
283デフォルトの名無しさん:2012/11/19(月) 23:37:13.22
例外を使わない関数でも
ロールバック用のコードが何命令か入るとか?
284デフォルトの名無しさん:2012/11/19(月) 23:38:54.88
templateの引数のクラスが実行時に飛ばす例外クラスなんて
templateクラスのインターフェイスに指定できんわな
285デフォルトの名無しさん:2012/11/19(月) 23:44:49.17
>>280
結局制限しないか、例外投げんなよ!投げたら氏ね!しか要らないんだな
286デフォルトの名無しさん:2012/11/19(月) 23:53:57.28
>>281
vector を at 抜きで operator [] だけで使うとがっかりする量のコードがついてくるだろ
throw() と throw(...) のセマンティクスがゼロオーバーヘッドの理想と真逆なんだよ
デフォを throw() にしなかった禿にジャーマンスープレックスかましたい

俺的には longjmp の第2引数が nested_exception で、そこから好きに dynamic_cast しろでいいと思う
287デフォルトの名無しさん:2012/11/20(火) 00:13:34.59
だから反省してnoexceptさんになったんだろ
288デフォルトの名無しさん:2012/11/20(火) 00:13:45.00
時代錯誤すぎてワロタ
289デフォルトの名無しさん:2012/11/20(火) 00:21:57.00
デフォをthrow()にしたら
例外投げただけで死にまくりじゃん
使い物にならないよ
290デフォルトの名無しさん:2012/11/20(火) 00:40:27.27
例外は例外なんだから例外時にだけ投げればよし
throw(...)を書くのもめんどいと感じてしまうとこは例外を投げるべき場所じゃない
291デフォルトの名無しさん:2012/11/20(火) 01:45:02.26
>>289
安全施設 throw() の管理者として
危険物乙4だのBSL4だのスケジュール1だのを
適切に処理するには、それなりの論理がちゃんとある
throw(...) を throw() に握りつぶして外聞上、throw() を通すならいい

だからといって throw() の純潔を通している処女におぞましいプレーはさせちゃいかん
その家系に産まれたばかりに理不尽なことの永久とも思える繰り返し

デフォを throw() にしなかった禿は茹ですぎ逆バンジーの刑だ
292デフォルトの名無しさん:2012/11/20(火) 01:53:34.06
例外は後から付け足したわけだから仕方ないだろう。
デフォルトが今のようになったのも互換性の問題からであると
いろんなところでBS自身が書いてるし。せめてD&Eくらいは読まないと。
293デフォルトの名無しさん:2012/11/20(火) 02:12:51.97
DEは読んでいて、そのうえで意義を持っている
禿の思想も語り口も好きなので著書はことごとく読んでいて耳の質はメリット5のはずだが
例外だけはどうしてもおかしいと個人的には思うんだが…
これは個人的なのか、禿への反駁は教義で禁じられているのか
294デフォルトの名無しさん:2012/11/20(火) 02:46:03.88
> vector を at 抜きで operator [] だけで使うとがっかりする量のコードがついてくるだろ
> throw() と throw(...) のセマンティクスがゼロオーバーヘッドの理想と真逆なんだよ

意味不明なんだけどだれか説明して
295デフォルトの名無しさん:2012/11/20(火) 05:51:20.74
同じく。 >286 さん説明よろしく。
296デフォルトの名無しさん:2012/11/20(火) 06:00:53.31
↓ここらへんへの反論としてわかりやすいやつをたのむ。

http://www.boost.org/community/exception_safety.html
> A good implementation of C++ will not devote a single instruction cycle
> to dealing with exceptions until one is thrown, and then it can be
> handled at a speed comparable with that of calling a function. That
> alone gives programs using exceptions performance equivalent to that of
> a program which ignores the possibility of errors. Using exceptions can
> actually result in faster programs than “traditional” error handling
> methods for other reasons. First, ...
http://boostjp.github.com/more/generic_exception_safety.html
> C++ の優れた実装は、例外が投げられるまでにその例外を扱うひとつの
> 命令サイクルを費やすことはしないで、 例外は関数呼び出しの同じような
> スピードで捕捉可能である。 それだけで、例外を使ったプログラムに、
> エラーの可能性を無視したプログラムと同等のパフォーマンスを提供している。
> 例外を使うと実際は、結果的に別の理由で``伝統的な''エラー捕捉の方法よりも
> 早くなる。まず、 ...
297デフォルトの名無しさん:2012/11/20(火) 06:40:42.04
掴んでる格段の資源解放と
継続るすための巻き戻し処理を例外に全部おっかぶせてるのが
なんかグチャグチャしてて嫌なんだよね
298デフォルトの名無しさん:2012/11/20(火) 06:47:45.29
>297
君にはGCのある言語がお似合いです
299デフォルトの名無しさん:2012/11/20(火) 07:15:47.06
>>297
資源解放はデストラクタの仕事だろ。例外関係なくね?
300デフォルトの名無しさん:2012/11/20(火) 09:17:08.76
>>297
(正常時の)実行速度のためなら他の全てを犠牲にしてもかまわないというCの本性の継承者です
301デフォルトの名無しさん:2012/11/20(火) 10:38:16.81
いやそれは違う。例外起きても必要なことしか行われない。デストラクタに不必要なこと書いてるなんてことは通常ない。
302デフォルトの名無しさん:2012/11/20(火) 18:30:33.90
本の虫の人は不自由なソフトは毛嫌いするのに
なんで邪悪なTwitterは使うの?
303デフォルトの名無しさん:2012/11/20(火) 18:57:24.10
それで、君はどうしたいんだい?
304デフォルトの名無しさん:2012/11/20(火) 18:59:29.01
代わりにApp.net使えよ! と言いたい
305デフォルトの名無しさん:2012/11/20(火) 19:27:15.29
頭が不自由なひとは
twitterを不自由だと思わないみたい
306デフォルトの名無しさん:2012/11/20(火) 21:08:14.63
ヲチスレでやれ
307デフォルトの名無しさん:2012/11/21(水) 22:48:28.67
本の虫はアカごっこしてる暇があったら早く本書いてくれ
308デフォルトの名無しさん:2012/11/24(土) 13:45:46.55
template<class Container>
void foo( Container&amp;&amp; c ) {
... = forward??( c[i] );
}

コンテナが右辺値で破壊していいときだけ、要素をムーブする方法が知りたい。
!is_lvalue_reference<> で適当にメタプログラミングすればいいのは分かるのだけど、
何か推奨される方法ってある?
309デフォルトの名無しさん:2012/11/24(土) 15:58:33.66
>>308
それがまさにstd::forward
310デフォルトの名無しさん:2012/11/24(土) 16:01:06.35
std::forwardでは不足?
311デフォルトの名無しさん:2012/11/24(土) 16:18:10.30
>>309 >>310
コンテナ自身ではなくて、コンテナの「要素」を foward したいんだけど、 std::forward<> で可能なんだっけ?
312デフォルトの名無しさん:2012/11/24(土) 16:56:47.77
ならmove_iterator
313デフォルトの名無しさん:2012/11/24(土) 19:42:16.36
>>312
alrogithm の方の std::move とか move_iterator って、 std::forward<> 相当じゃなくって std::move<> 相当じゃないの?
314デフォルトの名無しさん:2012/11/24(土) 20:34:37.34
forwardとmoveって何が違うの
315デフォルトの名無しさん:2012/11/24(土) 21:07:28.29
forwardは右辺値なら右辺値参照、左辺値なら左辺値参照が返ってくる
moveは右辺値だろうが左辺値だろうが強制的に右辺値参照が返る
316デフォルトの名無しさん:2012/11/24(土) 21:10:43.81
なるほど
分かりやすいわ
317デフォルトの名無しさん:2012/11/24(土) 21:20:58.46
forwardって転送するって意味だよ。
318デフォルトの名無しさん:2012/11/24(土) 21:23:06.10
>>313
仮引数を参照でなく値(コピー)にしてmove_iterator使えばよかろ
319デフォルトの名無しさん:2012/11/24(土) 21:47:22.22
なぜstd::forward_iteratorがなかったし
320デフォルトの名無しさん:2012/11/24(土) 22:02:00.12
だってコンテナの中身って左辺値だろ
コンテナの要素をどうしたいかなんて自分で決めることだろうに
321デフォルトの名無しさん:2012/11/24(土) 22:04:12.23
コンテナ自体が右辺値であればどうだろうか?
322デフォルトの名無しさん:2012/11/24(土) 22:18:04.26
なにが"どう"なんだ
323デフォルトの名無しさん:2012/11/24(土) 22:37:35.05
普通のイテレータこそが forward_iterator なのだな
324デフォルトの名無しさん:2012/11/24(土) 22:39:51.49
>>318
それで問題ない場合もあるとは思うけど、要素を一部しか使わない関数の場合、
rvalue でないコンテナが全部コピーされるのはちょっと。
325デフォルトの名無しさん:2012/12/08(土) 21:30:28.16
objective-CやGoだとPointerへの委譲が
簡単なのにC++03だとメンドイ
C++11で少しは楽にならんのか
326デフォルトの名無しさん:2012/12/08(土) 22:47:49.79
え 何言ってるん ばかなん?

void f(){g->h();}
327デフォルトの名無しさん:2012/12/08(土) 23:06:42.46
Overrideしたいmember関数だけ書いて、
残った関数は全てmember変数へ委譲する
ようなことができないって話だよ。
C++03はpointerを使わない移譲なら実装継承で済むが、
pointerに対する委譲の場合明示的に移譲する
member関数を記述する必要がある。
328デフォルトの名無しさん:2012/12/08(土) 23:43:18.48
動的?静的?
329デフォルトの名無しさん:2012/12/09(日) 00:05:27.76
どっちであろうと出来んだろ
330デフォルトの名無しさん:2012/12/09(日) 01:50:20.47
動的ならvtblいじれば出来る
331デフォルトの名無しさん:2012/12/09(日) 01:55:02.62
Cにできないことはない
332デフォルトの名無しさん:2012/12/09(日) 01:57:51.80
実装依存のものは出来るとはいわんぞ
実装依存に限らず最適化でも死にそうだし

あと仮想関数テーブル弄っても無理だろ
おなじメモリブロックにオブジェクトが
固まってる必要があるから
333デフォルトの名無しさん:2012/12/09(日) 02:04:25.52
>>331
他の言語で出来ることを簡潔には書けん
334デフォルトの名無しさん:2012/12/09(日) 02:34:26.37
手抜きをしようたってそうはいかんぞ
335デフォルトの名無しさん:2012/12/09(日) 02:45:43.50
実装依存とかわけわかんねぇこというなよ。 CPUにできることならだいたいできる。
336デフォルトの名無しさん:2012/12/09(日) 09:06:28.53
>>335
馬鹿はこのスレ来るなよ
337デフォルトの名無しさん:2012/12/09(日) 10:18:07.18
メモリレイアウトとか、言語規定には無いからな。それに依存したコードには移植性がないということだ。
338デフォルトの名無しさん:2012/12/09(日) 11:18:54.34
>>332
そのために実装毎にユニークな定数がdefineされてんだろ
339デフォルトの名無しさん:2012/12/09(日) 11:36:02.20
規格にvtbl書いてないからなあ
他のvirtual関数実現する方法なんて実質的にないのにな
340デフォルトの名無しさん:2012/12/09(日) 11:58:37.46
vtblだって、多重継承やRTTIもあわせると一通りしか無いってことにはならないよ
341デフォルトの名無しさん:2012/12/09(日) 11:59:21.83
はあ?
ポインタ側の拡張できるじゃん
342デフォルトの名無しさん:2012/12/09(日) 12:08:20.79
>>325で言ってるGoやObjective-Cのコードも実装依存だろ?
だったらC++で実装依存のコードを書いて何が悪いんだよ
343デフォルトの名無しさん:2012/12/09(日) 14:44:21.64
君が必要なら書けばいいが、規格のスレでは規格の話をしよう。
344デフォルトの名無しさん:2012/12/09(日) 16:22:00.76
>>342
言語仕様で決まってるから、処理系が存在する
環境でなら必ず動作するよ
345デフォルトの名無しさん:2012/12/09(日) 16:26:21.05
>>339
インタプリターで動く場合は連想配列だったりするし、
コンパイル式でも最適化でvtable消えるから
規格化するのは難しいだろ
346デフォルトの名無しさん:2012/12/09(日) 16:29:20.37
gcc に inheriting ctor が (外野的には) あっさり実装されて、 ChangeLog に特に注意書きもないけど、
なんか色々問題 (新たな ABI が必要とか) あるんじゃなかったの?
347デフォルトの名無しさん:2012/12/09(日) 16:45:59.19
>>342
何故他の言語の事も知らない門外漢が口を挟むのか?
大人の話に背伸びしたガキが口を挟んでも場を乱すだけ
とかいうような話を知らないのか?
348デフォルトの名無しさん:2012/12/09(日) 18:10:24.96
pimplイデオム使ってる時に実装クラスへの委譲コードを
どうにかして楽に実装できないかと考えたが俺の頭では無理だった
349デフォルトの名無しさん:2012/12/09(日) 18:16:37.27
>>344
“標準化されてない”言語仕様だろ?
仕様さえあればいいっていうなら、C++を拡張した独自仕様を書けばいい
そもそもISOの標準と、一企業が開発してる言語を比べるのがおかしい
350デフォルトの名無しさん:2012/12/09(日) 18:23:34.96
話題ずれてってんぞ
そもそも標準化されてないとダメというなら、話題に出せる言語極端に減るしな
351デフォルトの名無しさん:2012/12/09(日) 18:39:07.80
>>349
goは元々Bで知られるケントンプソンが作った言語で
google専属言語ではない。Objective-Cはブランドコックスが
モジュール化の理論を達成するために作った言語で
Apple専属言語ではない。
それぞれGoogleやNeXTが作った処理系とは別の処理系が存在する
352デフォルトの名無しさん:2012/12/09(日) 18:43:33.26
>>349
言語仕様と実装依存と標準規格は別物だろ
それすら判らないなら初心者スレで初心者と遊んでろ
普通は言語仕様の範疇で話ができりゃいいんだよ
353デフォルトの名無しさん:2012/12/09(日) 18:49:49.45
そういう話ではないだろ。それだと言語仕様がない言語を話題にできなくなる
354デフォルトの名無しさん:2012/12/09(日) 18:56:41.77
言語仕様が無い言語は話のしようがなく無いか?
どこまでを言語仕様というのにもよるけど
リファレンス実装とそのマニュアルが仕様という場合もあるしな
少なくとも最適化や実効環境によって使えなくなる
機能は話にならん
355デフォルトの名無しさん:2012/12/09(日) 19:02:17.22
結局Objective-CのようなPointerへの委譲を楽にする
機能がC++11の仕様の範疇で出来るようになるの?
って話はどうなったんですかね?
356デフォルトの名無しさん:2012/12/09(日) 19:02:37.61
RubySpecができるまでのRubyは仕様がなかったけど、随分話題に出てたろ
つーか話逸れすぎ
357デフォルトの名無しさん:2012/12/09(日) 21:56:36.39
何でお前らケンカしてんの?
358デフォルトの名無しさん:2012/12/09(日) 22:13:04.95
君たち、C++の話をしろ
359デフォルトの名無しさん:2012/12/10(月) 02:52:42.85
>>348
めんどうくせぇから実装クラスは変数publicにしてthisの変わりに使ってる。
360デフォルトの名無しさん:2012/12/15(土) 13:13:39.00
C++11まとめた書籍とかでないのかね
361デフォルトの名無しさん:2012/12/15(土) 14:01:01.43
>>348
スクリプトでパパッと生成すりゃいいじゃん
362デフォルトの名無しさん:2012/12/15(土) 18:40:05.25
>>360
スクリプトでパパッと生成すりゃいいじゃん
363デフォルトの名無しさん:2012/12/16(日) 13:43:51.55
>>360
スクリプトでパパッと生成すりゃいいじゃん
364デフォルトの名無しさん:2012/12/16(日) 18:31:31.41
>>361
それをしちゃうとメタプログラミング的に負けなんだよ
そりゃ俺だってPythonあたりで生成すりゃいいと思ったよ
パーサ作るのにSpiritで頑張るより素直にyacc使った方が早かったんじゃねとか思ったよ
365デフォルトの名無しさん:2012/12/16(日) 18:41:54.19
メタプログラミングに勝って人生で負ける
366デフォルトの名無しさん:2012/12/16(日) 18:52:29.61
>>362
それをしちゃうとメタプログラミング的に負けなんだよ
そりゃ俺だってPythonあたりで生成すりゃいいと思ったよ
パーサ作るのにSpiritで頑張るより素直にyacc使った方が早かったんじゃねとか思ったよ
367はちみつ餃子 ◆8X2XSCHEME :2012/12/16(日) 19:33:13.02
言語の外の世界で操作する方がより「メタ」だと思う
368デフォルトの名無しさん:2012/12/16(日) 20:15:11.54
メタって単語をやたら使いたがるヤツは頭悪いってよく聞く
369デフォルトの名無しさん:2012/12/16(日) 20:16:04.27
メメタァ…
370デフォルトの名無しさん:2012/12/17(月) 01:06:33.26
テンプレートを使うだけでコンパイル時間とオブジェクトファイルのサイズが増大するのは現実的な問題なので
解決されない限りは他のエレガントじゃない手法を選択肢に入れるのも止むを得ないということだ
371デフォルトの名無しさん:2012/12/17(月) 01:13:03.17
メタボリックテンプレート
372デフォルトの名無しさん:2012/12/17(月) 01:33:02.55
Qtとかもコード生成してるしな
373デフォルトの名無しさん:2012/12/17(月) 02:52:43.09
コード生成は1回で終わるけど、マクロやテンプレートは毎回だからなぁ。
結果も同じなのに。

プリコンパイルヘッダについては改善の余地があるとおもいますですよ。
374デフォルトの名無しさん:2012/12/18(火) 21:59:44.70
【嫌儲プログラミング部】 C#でネイティブアプリの開発が可能に!ポトペタもできる!C++厨憤死www
http://engawa.2ch.net/test/read.cgi/poverty/1355832436/
375デフォルトの名無しさん:2012/12/18(火) 22:50:38.94
C#でiPhoneアプリ作ってる記事ならだいぶ前にもあったけど
なんで今更
376デフォルトの名無しさん:2012/12/18(火) 23:03:33.03
発作じゃね?
377デフォルトの名無しさん:2012/12/18(火) 23:59:14.88
AppleでClangやってる人の一人が、C++11でconceptやってた人だし…
378デフォルトの名無しさん:2012/12/19(水) 12:09:16.78
ネイティブイメージ吐けても、
.netframeworkとスタティックリンクできないし、
gcなしにもできないから、何も意味ないな。
379デフォルトの名無しさん:2012/12/19(水) 13:56:35.12
っていうかネイティブコンパイラではないだろ?
monoのC#からCocoa呼べるようにしましたってだけだろ?
(XやGtk、Qtなどではない)ネイティブGUIの意味でネイティブって書いてあるんだろ?
380デフォルトの名無しさん:2012/12/19(水) 14:13:08.30
アセンブラ併用でもいいからCに頼らずに、OSをブートさせるところまで書けるようにならないと、
残念ながらネイティブとはいえない。
381デフォルトの名無しさん:2012/12/19(水) 14:34:01.63
まあそこまでいかなくても普通の意味のネイティブは、機械語が吐けてOSのAPIを(余計な動的ディスパッチャ無しで)直接叩けるあたりだろうな
機械語になっても、APIを叩くにはレイヤーが必要な言語とか結構ある
382デフォルトの名無しさん:2012/12/19(水) 19:28:46.86
>>380
今やJavaとかHaskellでも(単独で)OSが書けるんだよな
考えてみればすごい時代だ
383はちみつ餃子 ◆8X2XSCHEME :2012/12/19(水) 20:40:40.69
>>382
単独でといってもそこまでに色々なものを積み重ねているから出来るんだけどな。
ブートストラップ的には複雑になっている。
384デフォルトの名無しさん:2012/12/19(水) 21:14:10.41
別に複雑でもいいじゃん。Cに頼らず(アセンブリのみで)ブートできてるんだから
385デフォルトの名無しさん:2012/12/19(水) 21:37:51.03
Cが入っていないOSってどれ?
386デフォルトの名無しさん:2012/12/19(水) 21:52:55.68
スレチだけどJNodeとか?
387デフォルトの名無しさん:2012/12/19(水) 23:15:17.01
普通にOS書こうと思ってる俺には、はた迷惑でしかないがな
388デフォルトの名無しさん:2012/12/19(水) 23:29:36.18
MS-DOSとかそれ以前のは全部アセンブリじゃね?
389デフォルトの名無しさん:2012/12/19(水) 23:29:43.86
C++11では、クラス内で宣言する自分自身のstaticクラスの初期化がスレッドセーフになり、
Singletonパターンが使い易くなるそうですが、
これって、C++11に対応しているVisualStudio2012でコンパイルするだけで、そのようになるのでしょうか?
390デフォルトの名無しさん:2012/12/19(水) 23:38:45.72
使いまわすならポインタなり参照なりで持っとけばいい話だろう
391デフォルトの名無しさん:2012/12/20(木) 00:03:18.01
既存のソースについていってるよねどう見ても
盛っとけばいいだろとか言われてもあれじゃねえか
392デフォルトの名無しさん:2012/12/20(木) 11:12:56.69
>>389
static データメンバはもともとそんなに気にする必要はない気がする。
関数内の static 変数の初期化↓は、スレッドセーフにならなかった

6.7
4 ... If control enters
the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for
completion of the initialization...

コンパイラのスイッチがあるのかもしれないけど
393デフォルトの名無しさん:2012/12/20(木) 12:02:04.04
>>389
C++11フルサポートとは言ってないでしょ。
MSは規格出来てすぐにフルサポートしたことない。
394デフォルトの名無しさん:2012/12/20(木) 12:37:36.40
昔に比べればずいぶん積極的にサポートしてくるようにはなったと思うけどね
395デフォルトの名無しさん:2012/12/20(木) 14:52:50.46
2ちゃんもひと少なくなったな
396デフォルトの名無しさん:2012/12/20(木) 23:42:30.61
まだVC2002のC++03のレベルだよ
397389:2012/12/21(金) 01:25:05.98
>>392
試してくださってありがとうございます!

>>393
なるほど・・・。
期待しないでおきます。
398デフォルトの名無しさん:2012/12/23(日) 04:42:08.31
(c++)? c: c++;
399デフォルトの名無しさん:2013/01/12(土) 06:09:25.68
未定義動作
400デフォルトの名無しさん:2013/01/12(土) 10:27:45.36
三項演算子だから未定義じゃないだろ
401デフォルトの名無しさん:2013/01/12(土) 10:55:56.13
左右の項の実行順が未定義
402デフォルトの名無しさん:2013/01/12(土) 11:14:43.77
左が確定しないと、右を実行しようが無いから未定義じゃ無いよ。
403デフォルトの名無しさん:2013/01/12(土) 11:25:57.78
評価式の (c++) で true だった場合でも
false 側があらかじめ実行される可能性は?
404デフォルトの名無しさん:2013/01/12(土) 11:28:18.38
お前は
if (true)
c++;
else
c;
これでelse側が実行されるかもしれないって危惧するのか?
405デフォルトの名無しさん:2013/01/12(土) 11:35:49.34
a = (c++) ? c : c++;
a = c++ || c++;
これらは等価?
406デフォルトの名無しさん:2013/01/12(土) 11:36:45.48
問題なのは、
(c++) ? c : c++;
の方であって、
(++c) ? c : ++c;
ではないということだな。
407デフォルトの名無しさん:2013/01/12(土) 11:48:49.92
シーケンスポイント知らんのか。
知らんからやらないというのも正しい態度だけど、他人には強制しないでね。
408デフォルトの名無しさん:2013/01/12(土) 13:07:20.10
>>406
++がどちらであろうが、後ろの処理が先に実行されることはあり得ない。
409デフォルトの名無しさん:2013/01/12(土) 13:35:05.82
(c++)? c: c++;って
cが最初0なら戻り値1、終了後のcの値は2
cが最初1なら戻り値2、終了後のcの値は2
戻り値よりも他にいい言い方があるかもしんないけどそんだけの話じゃないの?
410デフォルトの名無しさん:2013/01/12(土) 13:43:41.72
>cが最初0なら戻り値1、終了後のcの値は2

kwsk
411409:2013/01/12(土) 13:55:34.11
なんか怖くなってコード書いて確かめてしまった…。
環境はVS2008でcはintでやったんだけど、実は話題についていけないのは俺だけで
みなさんC++11特有のお話だったりcはint以外の型だったりするの?
412デフォルトの名無しさん:2013/01/12(土) 14:13:32.53
巧妙なスレ違いあらし
413デフォルトの名無しさん:2013/01/12(土) 15:19:14.76
>>411
未定義動作や未規定の動作、実装依存の動作かどうかは実際に動かしても
確認できないよ。

この件は、1項目の直後にシーケンスポイント(副作用完了点)があるので
その手のには該当しない。(=問題ない)
414デフォルトの名無しさん:2013/01/12(土) 17:12:10.16
しいて C++11 と絡めるなら規格上 sequence point という用語によっては説明されなくなったってくらいかな。
2 つの処理の間に順序がある場合は sequenced before という句によって表現されていて、sequece point という点の前後全てで
分ける形にはならなくなった(恐らく concurrency 絡みで)。
415デフォルトの名無しさん:2013/01/12(土) 17:30:00.98
2ちゃんもひと少なくなったな
416409:2013/01/12(土) 19:01:36.20
>>413-414
ありがとうございます!すっきりしたのとひとつ賢くなったような気がします!
417デフォルトの名無しさん:2013/01/13(日) 00:44:56.98
>>415
禿同、いったい何処に逝ってしまったのか
418デフォルトの名無しさん:2013/01/13(日) 00:49:37.68
atomicやスレッドあたりの説明でよく出てきてたな >sequenced before
419デフォルトの名無しさん:2013/01/14(月) 16:49:50.49
多相ラムダってstd::functionでは保持不能? なにかそこら辺の拡張はないのかな。
420デフォルトの名無しさん:2013/01/15(火) 16:38:41.34
というかなぜ多相ラムダを引数と戻り値の型が固定のstd::functionにいれたいんだ?
std::functionと似ているが、戻り値の型以外自由にするクラスは作れるぞ。
というかstd::functionが意図的に制限していると言うべきか。
421デフォルトの名無しさん:2013/01/15(火) 16:56:26.11
再帰したいってだけ。
422デフォルトの名無しさん:2013/01/15(火) 17:50:11.09
lambda式の再帰はライブラリよりもコア言語側で提供されるべきだろ。
named lambdaが入っていればなぁ。
423デフォルトの名無しさん:2013/01/15(火) 23:59:07.09
>>420
そんなだからお前はHaskellから相手にされないんだぞ
424デフォルトの名無しさん:2013/01/21(月) 07:54:20.79
425デフォルトの名無しさん:2013/01/21(月) 17:11:15.55
compose()はbind()に吸収されたの?
426デフォルトの名無しさん:2013/01/21(月) 23:38:33.22
>>425 うん。昔の Boost の話ね。
427デフォルトの名無しさん:2013/01/22(火) 00:52:25.52
int main()
{
std::vector<double> angles;
std::vector<double> sines;

const double pi = 3.14159265358979323846;

std::transform(std::begin(angles), std::end(angles), std::begin(sines),
std::bind(std::negate<double>(),
std::bind(&std::sin,
std::bind2nd(std::multiplies<double>(), pi / 180,0))));
}

こういうのbindでちゃんとコンパイル出来るようにするにはどう書けばいいんですか?
428デフォルトの名無しさん:2013/01/22(火) 01:24:46.92
bind2ndのパラメータを3つ→2つにする
つかエラーメッセージで小数点がカンマになってますとか出てこんのか……
429デフォルトの名無しさん:2013/01/22(火) 01:37:13.49
>>427
std::transform(std::begin(angles), std::end(angles), std::back_inserter(sines),
std::bind(
std::negate<double>(),
std::bind(
static_cast<double (*)(double)>(&std::sin),
std::bind(
std::multiplies<double>(),
std::placeholders::_1,
pi / 180.0
)
)
)
);

ていうかbindを重ねて使うようならlambda式使ったほうがよかろう
430デフォルトの名無しさん:2013/01/23(水) 17:33:34.69
>>424
なんかつながらなかったからやっと見れた

putfは名前変えたほうがいいと思うんだが
431デフォルトの名無しさん:2013/01/26(土) 21:38:51.60
こんなプログラム保守したくねー!
432デフォルトの名無しさん:2013/01/27(日) 08:49:37.47
どうしてC++って何かしようとするとすぐ黒魔術になっちゃうの?
433デフォルトの名無しさん:2013/01/27(日) 08:51:17.78
たとえば?
434はちみつ餃子 ◆8X2XSCHEME :2013/01/27(日) 10:06:01.16
「黒魔術」という言葉を安易に使いすぎだと思う。
明確な定義がないから個々がどういうイメージで捉えようと勝手ではあるけど、
単に自分が理解できないものを黒魔術と呼んでるだけってことが多々ある。

俺のイメージでは「抽象の壁を壊すもの」っていう感じだな。
例えばテンプレートは代表的な抽象化の道具で、
型に依存しない機能 (ジェネリック) を隠すための壁となるべきものだけど、
何らかの計算をさせるために使ったりするのは黒魔術だと思う。
435デフォルトの名無しさん:2013/01/27(日) 11:27:11.01
436デフォルトの名無しさん:2013/01/27(日) 11:33:57.93
>>435
何をやっているかは極めて明快だと思うが。
ただし実際に自分で書くならlambdaで書く。
437デフォルトの名無しさん:2013/01/27(日) 11:36:11.39
>>436
極めて明快・・・?
ちょととその感覚は矯正した方がいいぞw
438デフォルトの名無しさん:2013/01/27(日) 11:40:44.59
>>437
基本、数学関数の取り回しでしかないから、何をやっているかすぐにわかるだけ。
もちろん、よくわからん(C++の意味での)関数でこれをやられると勘も働かない。
439デフォルトの名無しさん:2013/01/27(日) 12:04:26.94
まあ何をやってるかは分かるけど
このコードに手を加えろと言われたら消して書き直すわ
440デフォルトの名無しさん:2013/01/27(日) 12:04:36.18
boostやらのlambdaの方がよっぽど黒魔術的だろう。
441デフォルトの名無しさん:2013/01/27(日) 12:08:25.36
boost lambda の実装は黒魔術だが
C++11 の lambda は明快だぞ
442デフォルトの名無しさん:2013/01/27(日) 12:19:14.19
bindとかの時点で黒魔術に見えるわ。
443デフォルトの名無しさん:2013/01/27(日) 12:21:36.57
まあ個人の感想レベルだといろいろあるだろ、そりゃ。
444デフォルトの名無しさん:2013/01/27(日) 12:31:54.51
lambdaでbindは要らないし
445デフォルトの名無しさん:2013/01/27(日) 12:41:27.93
>>439
その感覚でいいんじゃね?
lambda自体を使う感覚もそんなもんだし
その場で全てが簡潔に完結してるのがlambda のメリット
446デフォルトの名無しさん:2013/01/27(日) 12:42:57.49
>>441
はげどう
447デフォルトの名無しさん:2013/01/27(日) 12:52:15.20
うん。
多少複雑でも、局所性が維持されるのは非常にありがたい。
lmbda式の存在はデカいと思うよ。
448デフォルトの名無しさん:2013/01/27(日) 13:06:59.81
そのおかげで一つの関数が膨れ上がってるけどいい?
449デフォルトの名無しさん:2013/01/27(日) 13:10:02.41
コードが散らばるよりはそちらを選ぶ。
450デフォルトの名無しさん:2013/01/27(日) 13:11:06.18
>>448
それはlambdaとあまり関係ないのでは…
451デフォルトの名無しさん:2013/01/27(日) 13:27:03.58
ループで書くのとalgorithm+lambdaで書くのとの比較じゃないのか
452デフォルトの名無しさん:2013/01/27(日) 13:57:42.13
C++ は黒魔術じゃなくて黒歴史
453デフォルトの名無しさん:2013/01/27(日) 14:29:50.87
for_eachを使うのが楽しいと感じるようになってきた
454デフォルトの名無しさん:2013/01/27(日) 14:34:16.59
lambda登場まで
for_eachは黒魔術としか思えなかった
455デフォルトの名無しさん:2013/01/27(日) 15:03:56.81
C++は超魔術合体
456デフォルトの名無しさん:2013/01/27(日) 15:30:16.89
C++は10年の遅れをとっているな
C#ではforeachは馬鹿でも使ってた
457はちみつ餃子 ◆8X2XSCHEME :2013/01/27(日) 17:42:59.14
C++ は 27 年の遅れをとっているな。
Scheme では for-each は初心者でも使ってた。
458デフォルトの名無しさん:2013/01/27(日) 18:17:42.20
うせろ雑魚Lisperは
459デフォルトの名無しさん:2013/01/27(日) 19:34:09.04
一度くらい lisper 呼ばわりされたい、e-lisp ですら四苦八苦、理解できる見込みがない‥‥
460デフォルトの名無しさん:2013/01/27(日) 19:39:35.47
C++11だとrange-based forが使えるから
for_eachは要らんな
461デフォルトの名無しさん:2013/01/27(日) 20:40:57.74
C#のやっつけforeachだせえよ。
462デフォルトの名無しさん:2013/01/27(日) 20:43:52.15
conceptはよ
463デフォルトの名無しさん:2013/01/27(日) 20:50:24.07
Ruby の each_with_index に相当するものが欲しい事はよくある
464デフォルトの名無しさん:2013/01/27(日) 21:28:22.42
一回自作すればそれで終わりじゃないか
465デフォルトの名無しさん:2013/01/27(日) 21:31:09.29
それだけのためにlambda渡す関数を作りたくはないわ
466デフォルトの名無しさん:2013/01/27(日) 22:26:16.10
>>463
カウンタ付きのイタレータアダプタ作ればいいだけ。
467デフォルトの名無しさん:2013/01/27(日) 22:34:28.05
インデックスと要素は別変数がいい
468デフォルトの名無しさん:2013/01/27(日) 22:48:39.63
インデックスと要素のpairを要素にしたvectorを返すzipを作ればいいだけ
469デフォルトの名無しさん:2013/01/27(日) 22:56:46.23
だから別変数がいいっつってんだろ
470デフォルトの名無しさん:2013/01/27(日) 23:04:46.38
別変数だろ
itr->first
itr->second
471デフォルトの名無しさん:2013/01/27(日) 23:12:38.93
イテレータ介すのがめんどくさいんだよ
472デフォルトの名無しさん:2013/01/27(日) 23:14:31.91
じゃあC++使うなとしか
473デフォルトの名無しさん:2013/01/27(日) 23:17:55.11
IteratorがいやならRange-based algorithmがいいぞ
474デフォルトの名無しさん:2013/01/27(日) 23:20:07.12
単独なら range-based for でイテレータなしでいけるだろ
475デフォルトの名無しさん:2013/02/13(水) 23:55:44.18
話題なしか
476デフォルトの名無しさん:2013/02/14(木) 00:28:29.53
ねーよ
JITコンパイル言語の出来が良すぎてC++はその役目を終えつつあるような気がする
477デフォルトの名無しさん:2013/02/14(木) 00:38:45.39
それは本当に速度が要求されるプログラム組んだ事無いだけだろ
478デフォルトの名無しさん:2013/02/14(木) 00:41:17.58
happens before だの acquire だの consume だのを日本語で正確に説明してくれる
ウェブサイトはある? 英文読んでも込み入りすぎて意味わからん
479デフォルトの名無しさん:2013/02/14(木) 00:45:48.30
atomic C++11 でググって調べてみたらどうかな
480デフォルトの名無しさん:2013/02/14(木) 00:46:02.39
C#とかキモい。
481デフォルトの名無しさん:2013/02/14(木) 01:53:56.45
>>477
そこまで変わらねーよ
スピードが欲しかったらCPUを新しくした方が安い時代
482デフォルトの名無しさん:2013/02/14(木) 02:53:26.25
失笑を禁じ得ない
483デフォルトの名無しさん:2013/02/14(木) 03:48:29.72
やることなくなると政治に走るのは人間の特性だからな
484デフォルトの名無しさん:2013/02/14(木) 04:28:24.35
実際V8のほうが速い
485デフォルトの名無しさん:2013/02/14(木) 04:42:47.48
std::vector<int> nums = {1,2,3,4,5};
for(auto &n : nums.subrange(2,3)) {
// 3,4,5 が取り出せたら嬉しい。vector をコピーすることなく
}
486デフォルトの名無しさん:2013/02/14(木) 07:26:19.90
>>481
それは本当に速度が要求されるプログラム組んだ事無いだけだろ
C#だけでエンコーダ作ってみろよ
487デフォルトの名無しさん:2013/02/14(木) 07:43:30.20
JITの方が速いなら、llvm使ってC++もJITコンパイルすれば良いのでは?
488デフォルトの名無しさん:2013/02/14(木) 07:46:59.14
advice入んないかなー
489デフォルトの名無しさん:2013/02/14(木) 08:58:23.24
>>486
それは速度のためというより、メモリの効率とかGCとかの関係じゃね?
JITコンパイル言語はメモリを多量に使うしGCが走るのでリアルタイム関係の
仕事をやらせるには都合が悪い

そういう所にしかC/C++の生き残る道はなくなっている
490デフォルトの名無しさん:2013/02/14(木) 09:07:42.29
確かにエンコーダ自体は無理だが
皮はC#でいいよな
491デフォルトの名無しさん:2013/02/14(木) 09:14:35.77
ようやくわかってきた
synchronization operation っつーのは、
 × operation that is synchronized
ではなくて
 ○ operation that is named synchronization
なのね

門外漢は英語の意味とるのも難しい・・・
492デフォルトの名無しさん:2013/02/14(木) 09:15:19.60
雑談スレ行けよ。
493デフォルトの名無しさん:2013/02/14(木) 09:41:48.28
JITとかGCとかゴミ。
IDEが生成したスケルトンプログラムが100M喰うなんて、
いくらメモリが16Gあっても勘弁。
494デフォルトの名無しさん:2013/02/14(木) 09:54:14.35
組み込みとか
科学技術計算とか
ゲームとか

ガワはLLってことも多いけど
495デフォルトの名無しさん:2013/02/14(木) 10:55:56.55
どちらかというと拡張命令の組み込みがあるかどうかと、
インラインアセンブラが使えるかどうかが決定的だろう。
本当に速度が必要なところを徹底的に最適化できるかどうかだ。
496デフォルトの名無しさん:2013/02/14(木) 15:47:10.22
>>482
失禁かと思ったw
497デフォルトの名無しさん:2013/02/14(木) 16:22:51.15
程度の低いスレ違いの話書き込みやがって。
498デフォルトの名無しさん:2013/02/14(木) 18:04:34.99
程度の高い497が居ると聞いて
499デフォルトの名無しさん:2013/02/14(木) 20:00:50.20
誰も>>497を褒めてくれないから>>498のように自作自演で褒めるしかないわけだ
500デフォルトの名無しさん:2013/02/14(木) 21:02:49.90
OSやらLL言語のランタイムがLL言語で
書かれていたら絶望的だろうに。
501デフォルトの名無しさん:2013/02/14(木) 21:15:34.40
マイクロカーネルのコア部分だけバイナリで他部分全部LLっていうOSもあるらしいし
案外いけるのかもしれん
502デフォルトの名無しさん:2013/02/14(木) 21:19:54.58
v8便利だよね
503デフォルトの名無しさん:2013/02/14(木) 22:14:43.12
ここまでD言語の話題なし
504デフォルトの名無しさん:2013/02/14(木) 22:32:49.03
>>455
超合金合体にみえた
505デフォルトの名無しさん:2013/02/14(木) 22:55:18.33
そらDが出たら逆にスレ違いだわ
506デフォルトの名無しさん:2013/02/14(木) 22:56:53.11
>>490
皮はC#でいいけど
エンコーダ自体は無理、という順番で言って頂きたい
507デフォルトの名無しさん:2013/02/15(金) 01:26:56.65
エンコーダも作れるだろ。1分エンコードするのに数日かかるかもしれんが。
508デフォルトの名無しさん:2013/02/15(金) 01:45:35.05
つ[P/Invoke]
509デフォルトの名無しさん:2013/02/15(金) 07:20:25.18
>>507
そういうのを無理って言うんだよw
510デフォルトの名無しさん:2013/02/15(金) 12:02:34.00
ま、せいぜいエンコーダで頑張ってくださいな♪
511デフォルトの名無しさん:2013/02/15(金) 12:08:38.35
>>509
昔はCじゃアセンブラに勝てない、って言われてたのに、
コンパイラの最適化コード生成が進化して、むしろアセンブラより
速いってなったんだから、
いつか、C#でエンコーダも、現実的になる日がくるだろ。



いや、ないな。
512デフォルトの名無しさん:2013/02/15(金) 13:57:18.59
あるVariadic Template構造体に渡されたVariadic Template引数を
取り出して、別のVariadic Template構造体の引数とするには
どうしたら良いですか?

template<typename ...TYPES> struct A{};

template<typename ...TYPES> struct B{};

template<typename T> struct C{
B<Aから取得したTYPES...> b;
};

typedef A<int, char, double> ICD;
C<ICD> c;
//c.bはB<int, char, double>型

環境 VC11
513デフォルトの名無しさん:2013/02/15(金) 14:36:22.70
>>511
いや、MSはどうも.NETの脆弱性修正と称して実はJITコンパイラを更新し続けて
いるらしいぞ

VSから生成されたコード(逆アセンブル)見てみろよ
変わって来てる
インライン展開なんか当たり前だし
514デフォルトの名無しさん:2013/02/15(金) 18:12:27.44
>>511
アセンブラより速いは無いぞ。
原理上アセンブラと同じまではいけるけど。
515デフォルトの名無しさん:2013/02/15(金) 18:20:01.79
>>514
人が普通にアセンブリ言語で書くよりはってことだろ。
516デフォルトの名無しさん:2013/02/15(金) 18:46:43.67
>>512
template <typename...> struct C;
template <template <typename...> class Template, typename... Types> struct C<Template<Types...> > {
B<Types...> b;
};

とか。
517デフォルトの名無しさん:2013/02/15(金) 19:42:53.52
>>513
じゃあC#だけで超高速なエンコーダ作ってみろよ
518デフォルトの名無しさん:2013/02/15(金) 21:14:37.82
>>513
インライン展開が当たり前なのは最初からだ。
どれだけアホなんだよ。
519デフォルトの名無しさん:2013/02/16(土) 00:05:18.77
JIT言語ごときがC++に速度で太刀打ちできる訳ないじゃん
アホ晒すのもいい加減にしとけ
520デフォルトの名無しさん:2013/02/16(土) 00:07:33.64
スレ違いですよ。
521デフォルトの名無しさん:2013/02/16(土) 01:20:27.78
作れないが、高速じゃないにすりかわってるじゃん。

後付でよいならばいくらでも反論可能であるよ。

作れる作れないだけで語れ。
522デフォルトの名無しさん:2013/02/16(土) 01:34:51.36
C#の有用性を説いている人間があまりに無知で話にならない。
絶対に味方にしたくないタイプだ。
523デフォルトの名無しさん:2013/02/16(土) 01:42:17.57
なんかもっと面白い話しようぜ。
お前らの好きなN3499/Digit Separatorsはどうよ?

digit-separator:
 [to be determined]

だぜ。
524デフォルトの名無しさん:2013/02/16(土) 06:07:23.27
>>512
Variadic Templateなクラステンプレートを再帰的に使う。
ということを実装している標準ライブラリがstd::tuple。
525デフォルトの名無しさん:2013/02/16(土) 21:03:59.94
一番ましなのはスペースじゃないの
文字列リテラルは並べたらくっつくんだから、数リテラルもそうだということにすればいい
526デフォルトの名無しさん:2013/02/17(日) 12:05:31.08
アンダーバーかな。
ユーザー定義リテラルさんには泣いてもらおう。
527デフォルトの名無しさん:2013/02/17(日) 13:59:05.57
>>525
それ、16進のとき大丈夫?
0xab cd だと cd がマクロ置換の対象になったりするわけだが。
0xab 0xcd == 0xabcd ってこと?
528デフォルトの名無しさん:2013/02/17(日) 14:30:41.33
意見がまとまらなくてお流れになる予感
529デフォルトの名無しさん:2013/02/17(日) 19:15:20.48
>>527
そうそう、文字列だって
L"Hello" L"World"
とか書かせてるんだし今さらでしょ
530デフォルトの名無しさん:2013/02/17(日) 20:11:28.60
1230123 -> 123 0123 // 10進 + 8進
区切りそれぞれのサフィックスを認識するならこうなるよな
2進リテラルサフィックス 0b も16進中に出現するしあんまりいい予感はしない
531デフォルトの名無しさん:2013/02/17(日) 20:12:57.17
ああ間違えたけど大目にみてくれ
532デフォルトの名無しさん:2013/02/17(日) 20:14:02.68
D言語みたくアンダーバーで区切れればいいのにネ
533デフォルトの名無しさん:2013/02/17(日) 22:19:36.38
アンダースコアはなんか嫌だなあ。
534デフォルトの名無しさん:2013/02/17(日) 22:29:27.19
主要なセパレーター案とその文法上の問題はN3499で網羅してるし、
やろうと思えばどの案でも実装可能だから、
話すといっても、どの文字が一番見やすいかぐらいだろ。
535デフォルトの名無しさん:2013/02/17(日) 22:33:01.90
それより早くRangeをだなぁ...
536デフォルトの名無しさん:2013/02/17(日) 23:45:53.52
Unicode前提でNO-BREAK SPACEで
537デフォルトの名無しさん:2013/02/17(日) 23:48:19.28
0xFF 0xFF 0xFF 0xFF は読み辛いな
0xFF_FF_FF_FF でいいわ
538デフォルトの名無しさん:2013/02/18(月) 01:21:04.00
16進数ならいいけど、10進数だと
1000 0011
みたいになって、8進数と区別つかない
539デフォルトの名無しさん:2013/02/18(月) 01:32:05.97
8進数は0oとかにすりゃいいんじゃね。

8進もういらんだろ?
540デフォルトの名無しさん:2013/02/18(月) 07:33:59.08
8進数はパーミッション指定で必須
541デフォルトの名無しさん:2013/02/18(月) 07:57:39.61
提示案の中に User-defined Bracket みたいなのある?
542デフォルトの名無しさん:2013/02/18(月) 08:10:26.40
x86 オペコードは8進ではじめて意味がわかる
543デフォルトの名無しさん:2013/02/18(月) 14:00:04.40
>>541
どういう用途?
初期化子で色々できるようになったけど。
544デフォルトの名無しさん:2013/02/20(水) 20:55:45.54
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1363.htm
これ何で採用されねぇんだよ。関数一個一個手書きで移譲すんのめんどくせぇだろ。
545デフォルトの名無しさん:2013/02/21(木) 02:06:20.33
>>540
パーミッションのほうを変えろよ
546デフォルトの名無しさん:2013/02/21(木) 06:11:50.18
8進数定数は今更やるには大きすぎる変更だろ
それくらい分かって諦めろ
547デフォルトの名無しさん:2013/02/21(木) 11:03:29.23
0 って書くと 8進数の 0 なんだよね
548デフォルトの名無しさん:2013/02/21(木) 11:04:34.78
それって10進数と16進数の0と違うの?
549デフォルトの名無しさん:2013/02/21(木) 11:08:14.10
値としては同じだね
020 とか 0x10 が 16 と同じになるのと同じ意味
550デフォルトの名無しさん:2013/02/21(木) 11:10:25.33
字句解析→構文解析→意味解析のフローが8進数用の解析器を通過するってことじゃね?
551デフォルトの名無しさん:2013/02/21(木) 19:15:22.33
0xかどうかのチェックもするだろうし、
実質的には8進数とかそういう以前の状態で0と判定されそう
552デフォルトの名無しさん:2013/02/21(木) 19:47:24.28
ワロス
553デフォルトの名無しさん:2013/02/21(木) 21:16:57.19
規格スレなのになぜ誰も提案資料に触れない
554デフォルトの名無しさん:2013/02/21(木) 21:24:12.49
実質的にはって言ったのは
規格がどうであれって意味ね
555デフォルトの名無しさん:2013/02/21(木) 22:05:03.11
>>553
公式の提案に対してここで騒ぐだけじゃなんにもならんのがわかってる人はここで議論はしないから
556デフォルトの名無しさん:2013/02/21(木) 22:14:46.87
提案が破棄された理由ぐらい知ってる人はいるだろうに
557デフォルトの名無しさん:2013/02/21(木) 22:32:27.35
10年前のC++業界なんてよく知らない新参だから触れないでおいた
558デフォルトの名無しさん:2013/02/22(金) 00:21:26.55
デリゲートのことか? GCとセットじゃないと危ないからじゃね?

shared_ptrとweak_ptrを使って自作すればなんぼでも作れる気がするが
559デフォルトの名無しさん:2013/02/22(金) 00:24:42.37
delegateそんなに使いたいならC#いじってろってこった
560デフォルトの名無しさん:2013/02/22(金) 00:52:24.26
>>558
TIGAUこういう事がしたい時につかえるもん。

OldContext *guest = device.CreateContext(); // 新しい描画Contextと互換の無い型
guest->Draw( Text(・・省略・・) );

NewContext *target = new NewContextAdapter( guest ); // 古い型を新しい型用にエミュレートするクラス

// OldContext ( guest ) に委譲される関数 この関数の委譲が明示的に委譲関数を書かなくても委譲される
target->Draw( Text(・・省略・・) );

// NewContextで追加された新しい関数。OldContextで使える
.// 他の関数を組み合わせて動作をエミュレートする。
target->Draw( Video(・・省略・・) );
561デフォルトの名無しさん:2013/02/22(金) 01:42:49.69
提案が良いものというだけでは採用されないって禿がD&Eで言ってた
562デフォルトの名無しさん:2013/02/22(金) 02:15:17.67
暗黙の変換なんか黒魔術だろ。 全部手で書け。
563デフォルトの名無しさん:2013/02/22(金) 21:19:44.53
Hoge*<shared> ph = new Hoge;
みたいに書きたい

いっそのこと
using * = std::shared_ptr
Hoge *ph = new Hoge;
とか書けるようにして欲しい
564デフォルトの名無しさん:2013/02/22(金) 21:25:01.79
なにその魔術
565デフォルトの名無しさん:2013/02/22(金) 21:27:15.85
>>563
気持ち悪い…
566デフォルトの名無しさん:2013/02/22(金) 21:31:21.04
>>563
一晩たったら後悔してそうな案だな
567デフォルトの名無しさん:2013/02/22(金) 21:31:42.84
>>561
採用されないこともあるって話じゃなく、
却下された理由を知りたいんだけど

>>562
暗黙の変換じゃない。基底クラスを実体じゃなく、
ポインターで保持出来るみたいな話だ。
568デフォルトの名無しさん:2013/02/22(金) 21:37:31.79
物乞いするだけならtypeundefやunnamespaceが吐血する程欲しいわ
#include "ベンダーA.hpp" // typdef bool BOOL
#include "ベンダーB.hpp" // typdef int BOOL

どっちも死んでほしい
569デフォルトの名無しさん:2013/02/22(金) 21:54:57.00
570デフォルトの名無しさん:2013/02/22(金) 21:59:25.77
前方宣言でのnamespaceの書き方を変えてほしいな
571デフォルトの名無しさん:2013/02/22(金) 22:30:55.04
>>569
D&EにN1363の事なんて書いてなくね?
572デフォルトの名無しさん:2013/02/22(金) 22:50:56.67
>>565-566
えーなんで何があかんの
今時は生ポインタなんかよりshared_ptrを扱う事の方が圧倒的に多いんだから
簡便な記法があってもいいだろ自転車置き場はともかく
573デフォルトの名無しさん:2013/02/22(金) 22:51:18.73
じゃあC++標準化委員会に入って文句を言うこったな
こんなところでボヤいていても糞の役にも立たない
574デフォルトの名無しさん:2013/02/22(金) 22:55:58.38
糞気持ち悪いわー
C++/CLIみたいに別の記号導入する方がまだマシに見える
575デフォルトの名無しさん:2013/02/22(金) 23:00:42.40
生ポインタと同じシンタックスはイタレータでも使うからなあ。
576デフォルトの名無しさん:2013/02/22(金) 23:01:03.98
生ポインタじゃないのに生ポインタの記法使うのは気持ち悪い
577デフォルトの名無しさん:2013/02/22(金) 23:06:46.67
ブラケットが要らんな *const と同じ表記でいいよ
intresuve_ptr と違って
shared_ptr の deleter引数や unique_ptr の default_delete<T> の扱いをどうキモく無い様にするかとかあるけど
578デフォルトの名無しさん:2013/02/22(金) 23:07:07.73
>>572
あっても良いかもしれないが、あまり意味がないような。
文字数も減らないし、むしろ混乱要素が増えるだろ。
その記法のメリットはどこなの?
579デフォルトの名無しさん:2013/02/22(金) 23:17:08.79
>>576
だってC++でポリモーフィズムをしようとしたらポインタを使う事になるもん
リファレンスでもいいけど関数の引数位でしょ?

この当たりの泥臭さが他のOOP言語を使ってる人から見れば奇っ怪に見えるのかも
580デフォルトの名無しさん:2013/02/22(金) 23:21:31.39
Example &other = mother.NewFather();
delete &other;
581デフォルトの名無しさん:2013/02/22(金) 23:27:19.77
で、Autometed Delegationとやらの不採用理由はどうなったんだ
582デフォルトの名無しさん:2013/02/22(金) 23:33:05.42
>>563

のコードというよりも >>563 さんのセンスがキモイです。

おぇええええええええええええ
583デフォルトの名無しさん:2013/02/22(金) 23:35:07.47
#undefがあるのになんでtypeundefがないんだよぉ
584デフォルトの名無しさん:2013/02/22(金) 23:37:52.73
>>579
リファレンスでもいいけどって生ポインタとリファレンスは用途が違うし
何が言いたいのかよくわからない
585デフォルトの名無しさん:2013/02/22(金) 23:45:31.52
>>578
ソースコードの最初に using * = shared_ptr; って書いておけば幸せになれる
586デフォルトの名無しさん:2013/02/22(金) 23:46:31.12
何でもかんでもshared_ptrになったらむしろ地獄だろ
587デフォルトの名無しさん:2013/02/22(金) 23:47:57.38
関数ポインタ―とかスタックに対するポインターが巻き添え食らうからたまらんわ
588デフォルトの名無しさん:2013/02/22(金) 23:48:15.00
え、天国だろ?

どうしても生ポが使いたかったらN3514のstd::exempt_ptr使えばいいよ
589デフォルトの名無しさん:2013/02/22(金) 23:55:29.92
using * = shared_ptr;

int main(int argc, char **argv)
{
590デフォルトの名無しさん:2013/02/22(金) 23:57:59.15
using * = shared_ptr;

int main(int argc, std::exempt_ptr<std::exempt_ptr<char>> argv)
{

(あ、あかんこれ)
591デフォルトの名無しさん:2013/02/23(土) 00:28:13.46
typedefつかえよハゲ
592デフォルトの名無しさん:2013/02/23(土) 00:31:32.50
そこでtypedef使うくらいならshared_ptrのシンタックスなんていらなくないか
shared_ptrをtypedefしろよハゲとしか
593デフォルトの名無しさん:2013/02/23(土) 00:33:32.41
全部shared_ptrにして循環参照で死ぬ未来が
594デフォルトの名無しさん:2013/02/23(土) 00:47:17.74
>>585
ナマポと混乱するデメリットの方が大きい気がします
595デフォルトの名無しさん:2013/02/23(土) 02:10:11.88
むしろただのポインタをクラステンプレートにするのがboostかなにかで出てた気がする
ptr<int> みたいな
596デフォルトの名無しさん:2013/02/23(土) 12:20:32.50
boostスレに書くべきかも知れないけど、ラムダ式でキャプチャされたthisは
ptr_vectorの場合ポインタではなく参照だと知らなかった

class Animal {
public:
virtual void cry() const = 0;
virtual ~Animal() {}
};
class Dog : public Animal {
void cry() const {
std::cout << "bark" << std::endl;
}
};
class Cat : public Animal {
void cry() const {
std::cout << "mew" << std::endl;
}
};
int main()
{
boost::ptr_vector<Animal> pa;

pa.push_back(new Dog);
pa.push_back(new Cat);

std::for_each(std::begin(pa), std::end(pa), [=](Animal& ra) { ra.cry(); });
}
597デフォルトの名無しさん:2013/02/23(土) 12:35:17.20
見当違いのこといってる自覚がないなら勉強しなおしたほうがいい
598デフォルトの名無しさん:2013/02/23(土) 12:37:23.52
std::for_each(std::begin(pa), std::end(pa), [=](Animal* ra) { ra->cry(); });

これコンパイル通らなかったんだよ
だから気づいた
599デフォルトの名無しさん:2013/02/23(土) 12:55:08.72
>>583
#ifdef に対応する iftypedef も欲しいよね
600デフォルトの名無しさん:2013/02/23(土) 13:05:23.52
>>598
見当違いのこといってる自覚がないなら勉強しなおしたほうがいい

this 通してアクセスしてねーだろ。
601デフォルトの名無しさん:2013/02/23(土) 13:11:20.74
>>596,598
pointer_containerのイテレータの参照外しが何型になると思ってるんだ
 *(pa.begin()); // 何型?
602デフォルトの名無しさん:2013/02/23(土) 13:19:30.33
>>600
じゃあthis通してアクセスする、コンパイルが通るプログラム書いてくださいな

>>601
boostのマニュアルを見て初めて知った
603デフォルトの名無しさん:2013/02/23(土) 13:47:14.51
>>599
それはテンプレートで十分じゃないか?
604デフォルトの名無しさん:2013/02/23(土) 15:15:21.32
template<typename T>
using SP = std::shared_ptr<T>
で->で正しく候補をあげるエディタ(IDE)ってある?
605デフォルトの名無しさん:2013/02/23(土) 15:21:22.45
VisualStudio2012
さっき試してみたがTemplate Aliasesに対応してたんだな
606デフォルトの名無しさん:2013/02/23(土) 16:16:34.50
>>604
VimやEmacsならclangの補完プラグイン入れれば行けると思うぞ
607デフォルトの名無しさん:2013/02/23(土) 18:19:20.74
global::shared_foo = make_shared<foo>();

こんなことしたら初めにglobal::data::fooにあったfooはどうなるんですか?
608デフォルトの名無しさん:2013/02/23(土) 18:51:27.19
global::data::fooは一体どっから出てきたんだ
609デフォルトの名無しさん:2013/02/23(土) 20:09:03.52
エスパー気味に行くと
まずshared_fooが保持していたポインタへの参照カウントが1減り、その結果参照カウントが0になればそのポインタは解放される
その後make_sharedから渡されたshared_ptrの保持するポインタとその参照カウントを共有して保持するようになる
610デフォルトの名無しさん:2013/02/24(日) 05:46:39.71
using (C++)++ = C#;
611デフォルトの名無しさん:2013/02/27(水) 13:37:33.17
Concepts Lite: Constraining Templates with Predicates―Andrew Sutton, Bjarne Stroustrup
  http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s
612デフォルトの名無しさん:2013/02/27(水) 21:15:28.30
ただのstatic_assertもどきになったな
これはいい事なのか
613デフォルトの名無しさん:2013/02/27(水) 21:19:20.24
元からそんな感じじゃなかったの
614デフォルトの名無しさん:2013/02/28(木) 02:14:55.10
overload はできるから、static_assert よりは便利
615デフォルトの名無しさん:2013/02/28(木) 19:12:27.02
C++11で投票したのにはaxiomってあったよ。assertとはぜんぜん違う。
616デフォルトの名無しさん:2013/02/28(木) 21:18:55.68
axiomなんかただのヒントで何の役にも立たないだろ
617デフォルトの名無しさん:2013/03/01(金) 11:02:03.35
最適化に使っていいことになってたよ。
618デフォルトの名無しさん:2013/03/01(金) 19:38:01.22
それを役に立たないという
619デフォルトの名無しさん:2013/03/01(金) 20:30:02.96
詭弁の一つ、強弁ですねw
620デフォルトの名無しさん:2013/03/02(土) 00:07:04.87
axiom-basedはtesting frameworkでも使われていてそれなりに有益だと思うが、
言語レベルで取り込むのは少しC++的でないかもしれない。
621デフォルトの名無しさん:2013/03/02(土) 07:20:53.13
registerだのinlineだの、std::allocator<T>::allocateのhint引数だの
「最適化のため」の機能がまともに役立った試しがあるか?
622デフォルトの名無しさん:2013/03/02(土) 07:33:53.96
最適化のための機能じゃないけどね…
623デフォルトの名無しさん:2013/03/02(土) 10:15:27.79
人間がコンパイラに出すヒントという点でなら同類だな
そしてその時点では有効であっても人間側の判断が進歩したコンパイラの解析に劣るようになると害のほうが多くなっていく
624デフォルトの名無しさん:2013/03/02(土) 10:19:04.92
axiomが害になるような事例があるとも思えないが。だって、axiomだし。
本来不変な条件が足枷になるならもっといろいろと壊れてるよ。
625デフォルトの名無しさん:2013/03/02(土) 12:48:23.06
整備されていないコメントと同じくらいの害はあるだろう
626デフォルトの名無しさん:2013/03/02(土) 13:30:06.27
自分でバリバリ書くものでもないような >axiom
適切に利用することを第一に考えておけばいいんじゃないか
627デフォルトの名無しさん:2013/03/02(土) 13:38:06.31
axiomはsyntax sugarでもあるんだけど。

axiom MulAdd(T y, T x, T a, T b) {
y = a * x + b <=> muladd(y, a, x, b)
}

こういうの。
まあ提案自体が難しいから、
最適化にしか使えないと思う人がいるのも無理はない。
concept関係は読み込んでる人の方が少ないだろうし。
もとからstatic assertレベルだと思う人がいるくらいで。
628デフォルトの名無しさん:2013/03/02(土) 13:50:11.53
なるほど、BLASなんかで自動的に書き換えてくれるなら大いに有用だな、、、
629デフォルトの名無しさん:2013/03/02(土) 14:17:30.07
axiom Associativity( T x, T y, T z ) {
(x + y) + z <=> x + (y + z);
}
これが整備されてないドキュメント以下になることは難しいと思われ
630デフォルトの名無しさん:2013/03/02(土) 14:25:25.48
axiom絡みだと禿も著者の一人の論文で
*p++ <=> { T tmp = *p; ++p; return tmp }
を見た時ちょっと笑ってしまった。そこからかい!
631デフォルトの名無しさん:2013/03/02(土) 15:43:44.51
そりゃ前置インクリメントと後置インクリメントは
まったく無関係にオーバーロードできるからな。
632デフォルトの名無しさん:2013/03/03(日) 05:31:08.52
C++ Grandmaster Certification誰かやってる?
633デフォルトの名無しさん:2013/03/03(日) 13:06:29.24
.pptokenが./pptokenの間違いであることにすぐ気づかないとcppgcは難しい
634デフォルトの名無しさん:2013/03/04(月) 08:59:39.38
興味ない > Grandmaster
C++11を一人で実装しろとか無茶なこと言って何の意味があるの
635デフォルトの名無しさん:2013/03/04(月) 21:27:16.05
まあ、本気でやってもある程度完成する頃には次期規格が出てるよな。












……出てる……よな?
636デフォルトの名無しさん:2013/03/04(月) 23:09:06.09
新言語を作る人なんて大体一人でやってるんじゃないの?
637デフォルトの名無しさん:2013/03/05(火) 06:04:28.45
自分で好き勝手に言語を作るのと
仕様書で1300ページを超えるC++11を実装するのは話が違うから
まともに使えるC++11を一人でサクサク実装できるなら天才だと思うわ
638デフォルトの名無しさん:2013/03/05(火) 10:03:59.41
雛形もtestsuitsもあるから、一人でさくさく作るというのとは違う。
ただ結構筆力がないと目安の週10時間では無理だろう。
639デフォルトの名無しさん:2013/03/05(火) 23:38:22.37
これってCourseraみたく講義の動画はないのか
640デフォルトの名無しさん:2013/03/05(火) 23:46:05.88
最適化とか適切なメッセージとか処理速度とか価値に成る部分をサックリ無視すれば
コンパイラ実装だけならそれほど無理な作業でもない気がするけど

ライブラリ群はムリ絶対ムリ
641デフォルトの名無しさん:2013/03/06(水) 00:47:11.07
C++の規格を議論するなら実装くらいはしたことないと駄目だよね
642デフォルトの名無しさん:2013/03/06(水) 00:49:16.41
大学時代は言語処理系をかじってたけど、
C++11ぐらいになると、もはや人智を超えてる感ある
ロケットみたいなイメージ。巨大すぎて個人で手がけるの無理
643デフォルトの名無しさん:2013/03/06(水) 00:55:29.31
mingw gcc 4.7.2

template<typename ... Args>
void test_func1()
{
}

template<typename ... Args>
void test_func2(Args ... args)
{
}

template<typename ... Args>
void func()
{
auto f1 = test_func1<Args ...>; // OK
auto f2a = test_func2<int, int>; // OK
auto f2b = test_func2<Args ...>; // NG コンパイラ内部エラー: unify 内、位置 cp/pt.c:16978
}

関数のアドレス取ろうと思って、何となく書いてみたら内部エラーが起きた・・・
644デフォルトの名無しさん:2013/03/06(水) 02:32:32.77
リファレンスインプリメンテーションがバイナリで配られて来るんだな。
テスト以外にも、いろいろと自作と結果を比べるために。
配布バイナリいきなり実行か。CPPGMの主催者を信頼していいのだろうか?
645デフォルトの名無しさん:2013/03/06(水) 02:41:30.25
いまどきは仮想環境をカンタンに使えるんだからそんなに心配なら
そっちでやれよw
646デフォルトの名無しさん:2013/03/06(水) 06:40:35.14
闇の軍団ならこんくらい楽勝でしょ
647デフォルトの名無しさん:2013/03/06(水) 12:08:57.47
cppgmってどこがやってるの?
648デフォルトの名無しさん:2013/03/06(水) 17:27:42.90
これ修了するとなんかの組織に入れてくれるらしいよ
649デフォルトの名無しさん:2013/03/06(水) 20:10:58.73
世の中はSTLすら使わない会社があるというのに何ですか?
ここのスレは。物凄いプロ集団か、オタクの世界ですか?
650デフォルトの名無しさん:2013/03/06(水) 20:18:27.47
C/C++を使っているってことが、いまや
キチ、超底辺ドカタ、真性オタクのいずれかです
651デフォルトの名無しさん:2013/03/06(水) 20:57:53.47
C++でバカッ速いコードを書くのが快感だ・・・。
652デフォルトの名無しさん:2013/03/06(水) 21:02:55.12
組み込み関数やインラインアセンブラでSIMDをフル活用する方が快感だよ。
653651:2013/03/06(水) 21:04:00.71
>>652
それそれ!その感じ!
SIMDはドーパミン出るね!
もうHaswellのAVX2が楽しみで夜も眠れない♪
654デフォルトの名無しさん:2013/03/06(水) 21:19:22.75
>>653
AVX2はC++11じゃないと速いコードにならないらしいね
655651:2013/03/06(水) 21:21:02.62
>>654
そうなんだ!
まぁ、VS2012でガンガンC++11の機能を使う予定だから問題なしだね!
あーもう6月までガマンできないよぉ!!
656デフォルトの名無しさん:2013/03/06(水) 21:34:32.98
VSのx64ビルド設定の最適化でSIMD設定できないよね
657デフォルトの名無しさん:2013/03/06(水) 21:35:46.13
boost.simd手伝ってやれよ
658デフォルトの名無しさん:2013/03/06(水) 21:36:14.26
なにかお困りですか?
659デフォルトの名無しさん:2013/03/06(水) 21:41:18.75
VC2012ってすでにAVX2をサポートしているのか?
660デフォルトの名無しさん:2013/03/06(水) 22:00:30.55
>>656
x64だとSSE2が標準になるから指定出来るとすればAVXだけかな。
661デフォルトの名無しさん:2013/03/08(金) 06:54:12.41
>>652
Assembly書くよりvalarray使い回したほうが楽じゃね?
valarrayがSIMDで最適化されるのってIntelの翻訳器だけだっけ?
662デフォルトの名無しさん:2013/03/08(金) 06:55:49.49
>>656
手書きでオプション追加すれば?
663デフォルトの名無しさん:2013/03/11(月) 23:12:09.56
まあ、いつまで不自由なtwitter使ってんだよカスがwwww
664デフォルトの名無しさん:2013/03/12(火) 01:31:42.30
あの人まだ仕事見つかってないの?
665デフォルトの名無しさん:2013/03/12(火) 01:36:18.70
ネットwatch板でやれ
666デフォルトの名無しさん:2013/03/12(火) 02:00:39.14
iOSに関してはアレだけど
macはtwitterほどの不自由さは感じないな
667デフォルトの名無しさん:2013/03/12(火) 04:10:00.85
そりゃ標準化されたPOSIX APIが載ってるもの
668デフォルトの名無しさん:2013/03/12(火) 14:24:52.66
Runtime-Compiled C++ってどう?
669デフォルトの名無しさん:2013/03/12(火) 16:57:09.77
誰かclang解説本書いてよ
670デフォルトの名無しさん:2013/03/12(火) 21:50:59.72
dequeにshrink_to_fitは意味あるの?
671デフォルトの名無しさん:2013/03/12(火) 22:31:04.13
実装による
672デフォルトの名無しさん:2013/03/13(水) 02:37:48.25
つ達人出版
673デフォルトの名無しさん:2013/03/13(水) 20:23:20.41
意味があった
674デフォルトの名無しさん:2013/03/14(木) 16:39:38.98
不自由なgoogle reader使ってたのか
まあ不自由なtwitter使っているんだから不思議ではないわな
675デフォルトの名無しさん:2013/03/14(木) 17:47:04.09
>>674
じゃあ君は何を使ってんだ?
676はちみつ餃子 ◆8X2XSCHEME :2013/03/14(木) 18:09:07.00
不自由なにちゃんねる
677デフォルトの名無しさん:2013/03/14(木) 18:10:21.79
自分は使えるもんは何でも使うよ
Mac、Windows、Linux全部使ってるし
678デフォルトの名無しさん:2013/03/14(木) 18:19:53.18
N88BASIC「」
679デフォルトの名無しさん:2013/03/14(木) 18:32:00.93
>>677
効率悪そうだな
もう少し考えた方がいい
680デフォルトの名無しさん:2013/03/14(木) 18:37:38.42
オープンソースは自由に食べられるうんこみたいなもん
681デフォルトの名無しさん:2013/03/14(木) 19:18:57.10
久しぶりにC++書くことになったけど11に移行すべきか迷ってる
新機能は便利そうだけどほとんどboostにあるわけで、ライブラリの互換性とかコンパイラ間の互換性に引っかかるリスクのほうが怖い
速度に関して03より11にするメリットがあるなら迷わず乗り換えるんだけどどうかな?
682デフォルトの名無しさん:2013/03/14(木) 19:22:03.24
そんなのあんたが使うコンパイラしだいとしか言えんがな
683デフォルトの名無しさん:2013/03/14(木) 19:27:40.48
gccメインだけど最低限VCでもコンパイルできるようにしておきたい
しかしVCはconstexprも実装されて無いという・・・
684デフォルトの名無しさん:2013/03/14(木) 19:30:58.87
去年決まったばかりの新しい仕様を使うかどうかの基準が、まず速度ってのはないだろw
685デフォルトの名無しさん:2013/03/14(木) 19:46:37.41
C++11有効にしてビルドして、ビルド通ったらそのまま移行すればいいだけじゃないの?
686デフォルトの名無しさん:2013/03/14(木) 20:01:28.28
不安なところだけJavaで実装すればええやん
Write once, write anywhereやで
687デフォルトの名無しさん:2013/03/14(木) 20:05:04.63
Write Once, Exploit Everywhereだろw
688デフォルトの名無しさん:2013/03/14(木) 23:26:38.81
Write Once, Debug Anywhere...
689デフォルトの名無しさん:2013/03/15(金) 00:56:12.21
Write once, runaway
690デフォルトの名無しさん:2013/03/15(金) 02:51:40.42
脱google(藁)なんて意識の高いネットユーザーぶってても
検索サービスは使うんでしょ
691デフォルトの名無しさん:2013/03/15(金) 03:18:46.66
クローズドなソフトウェアは開発者が開発を止めても
エミュレーターを使うなど使い続けられる可能性があるが
クローズドなサービスは運営が止めたら一巻の終わり

なぜクローズドなソフトウェアを使うのは嫌なのに
クローズドなサービスは使うのは平気なのか?
692デフォルトの名無しさん:2013/03/15(金) 03:20:58.93
恋文なら直接本人に渡せよ
693デフォルトの名無しさん:2013/03/15(金) 04:01:28.77
平気じゃないけど代わりがない
694デフォルトの名無しさん:2013/03/15(金) 04:19:59.16
googlemailをメインアカウントにするのは怖いな
いつ使えなくなるかわからん
695デフォルトの名無しさん:2013/03/15(金) 04:32:10.18
代わりがないなら作ればいいじゃない
プログラマーなんだもん
696デフォルトの名無しさん:2013/03/15(金) 04:43:15.98
依存できるサービス作るのはソフトウェア作るのとはわけがちがう
697デフォルトの名無しさん:2013/03/15(金) 04:45:29.96
まるでソフトウェアなら作れるかのような言いぶりですな
698デフォルトの名無しさん:2013/03/15(金) 04:46:44.76
google readerくらいならみんな作ってないか?
699デフォルトの名無しさん:2013/03/15(金) 05:25:15.64
RSSアンテナのCGIを置くぐらいは誰でも楽勝だろうが、
ひとつのサーバーで一括してやらないと、F5アタックと変わらんからな
700デフォルトの名無しさん:2013/03/15(金) 05:45:22.38
>>699
ソフトウェア作るのとサービス作るのとの違いはそういうところもあるよな
複数ユーザーからの需要をまとめることで取得先に負荷をかけない配慮もあるし
サービス落としてはいけない堅牢性も求められるし
バグや作業ミスで個人情報が漏れることはあってはいけないし
701デフォルトの名無しさん:2013/03/15(金) 13:56:01.00
クローズドなサービスは採算ベースに乗らなければ
存在さえ許されずこの世から消えさる悲しき存在
クローズドなソフトウェアは開発元がつぶれてもとりあえず使うことはできる
702デフォルトの名無しさん:2013/03/15(金) 15:00:59.65
最近はどこでもデータ吸い上げられるし、狭い意味でクローズドなサービスも珍しいけどな。
703デフォルトの名無しさん:2013/03/16(土) 01:18:20.26
星奈、俺は

俺はまず地元で一通り後輩をナンパし、茶髪で周囲の注目を集めた後
女子高生をひっかけ地元にお持ち帰り、ご近所さんにお披露目をした。
星奈、夜景の綺麗な都会のマンションで結婚式をしよう。またわけのわ
からないダダを捏ねたのだろう。高校を卒業したばかりの星奈にマンシ
ョンを契約させたのだ。
704 忍法帖【Lv=40,xxxPT】(1+0:5) :2013/03/16(土) 04:02:53.49
なぁ、腹減ったな!?
705デフォルトの名無しさん:2013/03/16(土) 07:32:26.13
gccを改造する講座があるみたいだけど
clangを改造する講座はありませんか?
706デフォルトの名無しさん:2013/03/16(土) 09:36:40.27
星奈、エロすぎるだろ・・・
707デフォルトの名無しさん:2013/03/16(土) 11:53:33.23
C++というかVisual.Studioで
Parallel::For使ってる人居るかな?
C#のParallel.Forはいくらでも見かけるけど
C++でこれ使ってる日本語サイトがほとんどみつからない
708デフォルトの名無しさん:2013/03/16(土) 11:55:42.79
スレ違いというか、板違いです。
709デフォルトの名無しさん:2013/03/16(土) 12:55:54.01
なんで?
Parallel.Forってのはラムダ式がないと使えないんだが.
ライブラリを提供するだけで,制御構造である繰り返しルーチンまでも引数として与えられるのがラムダ式
これに正式対応したのが11からだろ.
710デフォルトの名無しさん:2013/03/16(土) 13:08:16.95
.netだろ?C♯もC++/CLRもスレ違い

それとC++のラムダ式は基本的には関数オブジェクト定義の糖衣構文でしかない
711デフォルトの名無しさん:2013/03/16(土) 13:31:27.94
Threading Building Blocksの話かと思った
712デフォルトの名無しさん:2013/03/16(土) 14:26:59.24
C++11の機能が揃ってきたけど
そろそろ新しい魔導書とかでないのか?
713デフォルトの名無しさん:2013/03/16(土) 14:27:34.92
洋書ならいくつか
714デフォルトの名無しさん:2013/03/16(土) 14:39:45.39
英語いやどす
715デフォルトの名無しさん:2013/03/16(土) 14:45:18.74
effectiveの人が出してるよ。
電子出版で。
この前改訂版が出た。
もちろん英語。
716デフォルトの名無しさん:2013/03/16(土) 15:37:33.44
また新たな黒魔術の誕生か・・・
717デフォルトの名無しさん:2013/03/17(日) 00:54:46.12
TC++PL 4th まだかね。
718デフォルトの名無しさん:2013/03/17(日) 11:10:22.83
C++11を勉強し始めたのですが、下の例がokになる実装がいまいち理解できません。

struct s {
 int x;
 explicit s(int x_)
  : x(x_*2)
 {
 }
};
std::vector<s> v;
v.emplace_back(s(2)); // ok
v.emplace_back(3); // ok

これは、どういうからくりでしょうか?
719デフォルトの名無しさん:2013/03/17(日) 11:44:01.52
>>718
emplaceはsのコンストラクタの引数を直接渡す。
つまりemplace_back(int arg)にintを渡して関数中で明示的にsのコンストラクタを呼び出すから問題ない。
720デフォルトの名無しさん:2013/03/17(日) 12:02:29.64
emplace_backの中でplacement newに引数を転送するだけでしょう

new(p_new_element) s(s(2)); // (暗黙定義の)ムーブコンストラクタの呼び出し
new(p_new_element) s(3); // explicit s(int x_)の呼び出し
721デフォルトの名無しさん:2013/03/17(日) 13:10:22.51
vector<s>さん「だってsなのは自明やんか」
722デフォルトの名無しさん:2013/03/17(日) 13:25:20.67
&vector[0] + n == &vector[n]って仕様の欠陥じゃないか?
boolとか番地と値の格納位置が一致しない型だと実装不可能だろう。
勿論boolは例外扱いになって入るが、stringで言うc_strにあたるようなもん用意すりゃ
良かったろうに何がしたいのか判らんな。
723デフォルトの名無しさん:2013/03/17(日) 13:28:04.14
どこが問題になるんだ?
724デフォルトの名無しさん:2013/03/17(日) 13:28:09.15
嫌なら使わなきゃいいのに
725デフォルトの名無しさん:2013/03/17(日) 13:28:20.62
>boolとか番地と値の格納位置が一致しない型
何言ってんだこいつ
726デフォルトの名無しさん:2013/03/17(日) 13:34:12.08
vector.data() + n ならいいと
なにが言いたいんだろうな
727デフォルトの名無しさん:2013/03/17(日) 13:48:25.84
>>722
あのさあ
std::vector<bool>の仕様よく読んでみな
728デフォルトの名無しさん:2013/03/17(日) 15:45:41.15
>>726
その場合だと、dataを呼んだ時だけbool型配列にすればいいでしょ。
普段の実装時は、bit単位で格納すればいいから格納効率があがるじゃん。
そんで、bool以外も、その制限が加わればstd::vector<bool>と他のstd::vector<T>と
の齟齬が無くなる。
729デフォルトの名無しさん:2013/03/17(日) 15:50:30.86
あと、24bit型や、48bit型をboolの様にvectorにつめ込ませて保持させても、
他のstd::vector<T>と矛盾が無くなる。
730デフォルトの名無しさん:2013/03/17(日) 15:57:39.85
使う価値なし
731デフォルトの名無しさん:2013/03/17(日) 16:44:21.95
Cの配列と内部ストレージのメモリイメージが一致しているのと
Cの配列と一致するメモリイメージを返すメンバ関数があるのとでは、
CのAPIを呼ぶ際の親和性に天地の差があるだろう。
732デフォルトの名無しさん:2013/03/17(日) 17:53:00.42
>>728
> その場合だと、dataを呼んだ時だけbool型配列にすればいいでしょ。

そっちの方が意味変わりすぎだろw

24bitや48bitのpackedなvectorは特殊化で書ける。
733デフォルトの名無しさん:2013/03/17(日) 17:57:46.49
というか、そもそも何故Cの配列が
ああいう構造なのかを考えてみた方が良いかも。

std::vector<bool>こそ要らないよね。
STLコンテナですらないとかtemplateの特殊化使った
初期のお遊び的仕様が引きずられている感じ
全く別のクラスとして用意する分には問題ないけど。
734デフォルトの名無しさん:2013/03/17(日) 18:09:25.03
std::vector<boo>さんはstd::bitsetさんみたいなもんだから…
735デフォルトの名無しさん:2013/03/17(日) 18:15:33.65
なんだそのサモハンキンポーの配列みたいな名前は
736デフォルトの名無しさん:2013/03/17(日) 19:13:49.39
vector<bool>なんて使ってる人いないやろwww
737はちみつ餃子 ◆8X2XSCHEME :2013/03/17(日) 19:39:27.62
> いないやろ

なんだその似非関西弁は。
「おらへんで」だろ。
738デフォルトの名無しさん:2013/03/17(日) 19:40:43.68
std::vector<bool> は既に非推奨だからな
bool 配列作りたい時に凄い困ってるわ
739デフォルトの名無しさん:2013/03/17(日) 19:57:09.54
おらんやろ
いーひんやろ

このあたりかな。
740デフォルトの名無しさん:2013/03/17(日) 20:02:40.05
>>737
ガキの使いやあらへんで

>>738
だからbitset使うんだよ
741デフォルトの名無しさん:2013/03/17(日) 20:02:43.11
std::vector<bool>が非推奨な理由については
Effective STL 第18項を参照のこと
742デフォルトの名無しさん:2013/03/17(日) 20:03:08.14
>>738
boost::dynamic_bitsetがあるだろ
743デフォルトの名無しさん:2013/03/17(日) 20:53:07.48
bitの数が静的に決まっているときはどうすりゃええねん
744デフォルトの名無しさん:2013/03/17(日) 21:42:11.79
静的に決まってるならstd::bitsetでいい
745片山博文MZパンク ◆0lBZNi.Q7evd :2013/03/17(日) 22:50:57.70
C++11/C++1yはマルチスレッドをサポートしてますか?
746デフォルトの名無しさん:2013/03/17(日) 22:55:45.72
std::thread があるだろ
747デフォルトの名無しさん:2013/03/17(日) 22:56:25.22
>>733
>STLコンテナですらない
&vector[0] + n == &vector[n]この余計な制約ぐらいだったと思うが具体的には?

>>740
bitsetは代わりにならんだろ
748デフォルトの名無しさん:2013/03/17(日) 23:07:37.78
とりあえず deque<bool> で
749デフォルトの名無しさん:2013/03/17(日) 23:29:34.60
>>746
なんと!
STLでスレッドがサポートされたとな!
これは使ってみよう!
750デフォルトの名無しさん:2013/03/17(日) 23:46:26.92
>>747
&vector[0] + n == &vector[n]
vector 実装に対してこんな制約あるの?
size() が n の vector に対しては vector[n] の時点で未定義動作じゃないの?
751デフォルトの名無しさん:2013/03/18(月) 00:02:07.33
std::vector<T>は確保している要素の連続性を要求しているよ
他にもvector<bool>についてはコンテナとしての要件を満たしていない可能性があるのでbegin(),end()は使ってはいけないなどの制約がある
752デフォルトの名無しさん:2013/03/18(月) 00:31:32.45
>>748
あ・・・そうか、そうだな
頭いいな
753デフォルトの名無しさん:2013/03/18(月) 07:09:42.92
>>751
C++98時点ではそんな制約はなく
vector<bool>はSTLとして問題なかった
754デフォルトの名無しさん:2013/03/18(月) 07:16:22.93
遅くとも03の時には必須になっていたよね。
755デフォルトの名無しさん:2013/03/18(月) 07:22:48.86
Effective STLを読んでない事がまるわかり
756デフォルトの名無しさん:2013/03/18(月) 07:57:45.68
>>717
amazon.com見たら Publication Date が March 20 から June 3 になってたぞ...
757デフォルトの名無しさん:2013/03/18(月) 09:38:48.59
問題が多いから非推奨になったわけで。
758デフォルトの名無しさん:2013/03/18(月) 09:43:39.76
誰も使ってないだろうし特殊化やめちゃってもいいと思うんだけどね
759デフォルトの名無しさん:2013/03/18(月) 15:17:26.35
ここまでdequeなし
760デフォルトの名無しさん:2013/03/18(月) 15:44:55.09
761デフォルトの名無しさん:2013/03/18(月) 16:17:43.14
デック
762デフォルトの名無しさん:2013/03/18(月) 18:19:32.37
vector<bool>ってC++11でもdeprecatedにすらなってなかったと思うんだけど
763デフォルトの名無しさん:2013/03/18(月) 18:33:35.73
仕方ないね
764デフォルトの名無しさん:2013/03/18(月) 21:55:45.52
>>754
だから03で追加した仕様が問題だって話じゃないのか?
765デフォルトの名無しさん:2013/03/18(月) 22:08:49.66
知ってるか?
きゃりーぱみゅぱみゅってCPPって略称なんだぜ
766デフォルトの名無しさん:2013/03/18(月) 22:10:34.46
な、なんだってー!!
767デフォルトの名無しさん:2013/03/18(月) 22:25:33.45
CプリプロセッサもCPPが略だな。
CPPFLAGSはC++へのフラグじゃなくてCプリプロセッサ用。
768デフォルトの名無しさん:2013/03/18(月) 22:41:21.47
cxxとか無理矢理だよな
769デフォルトの名無しさん:2013/03/18(月) 23:50:18.89
知ってるか?
さっき原発の冷却システム壊れたってニュースが
しかも19時から止まってて復旧見込みないって


(´・ω・`)
770デフォルトの名無しさん:2013/03/18(月) 23:56:03.51
知ってるよ
771デフォルトの名無しさん:2013/03/19(火) 00:01:05.55
テレビで何も言わないのがこわいね(´・ω・`)

って書いてたら今頃NHKで言い始めた
772デフォルトの名無しさん:2013/03/19(火) 00:50:55.18
テレビも既にいくつもの局が報じたようだけど
「燃料プールの冷却が止まったままで復旧の目処が立たず」の部分は曖昧に言って
「原子炉の冷却は復旧して問題はない」を強調してるらしいな

つうか、何のスレだよ
773デフォルトの名無しさん:2013/03/19(火) 01:08:31.37
std::vectorの連続性はC++98の最初の仕様書には書いてなくて、
あとから指摘されて追加されたんだよな。
C++ Standard Library Issues Listの69。
それまではオレも一生懸命newしてたさ。

・・・ただし、iteratorはポインタとは限らない。
774デフォルトの名無しさん:2013/03/19(火) 01:33:21.32
爆発したらしいぞ

あちちあち
燃えてるんだ炉が♪
775デフォルトの名無しさん:2013/03/19(火) 04:20:43.96
>>773
VC6のときにvectorのiteratorをポインタ代わりに使っていてVC.NETになったときに喰らったよい思い出
776デフォルトの名無しさん:2013/03/19(火) 06:42:37.38
777デフォルトの名無しさん:2013/03/19(火) 07:27:25.06
>>773
便利にはなったが、&v.front()とか&v[0]は気持ち悪いわぁ
778デフォルトの名無しさん:2013/03/19(火) 07:28:14.53
dataがあるじゃない
779デフォルトの名無しさん:2013/03/19(火) 07:44:37.14
C++11スレでdataを知らぬとな
780デフォルトの名無しさん:2013/03/19(火) 19:18:39.48
気に入らないなら全部コーティングすればいいじゃない
781デフォルトの名無しさん:2013/03/19(火) 19:52:10.61
おまいはマリー・アントワネットかw
782デフォルトの名無しさん:2013/03/19(火) 20:16:36.40
普通はオレオレ実装なんかより世の中のライブラリの方が使いやすいし信頼できるもんだが
C++に限ってはそうでもないな
783デフォルトの名無しさん:2013/03/19(火) 20:17:01.88
コーティングか
コーディングじゃなくて
784デフォルトの名無しさん:2013/03/20(水) 02:12:14.38
785デフォルトの名無しさん:2013/03/20(水) 17:36:15.47
786デフォルトの名無しさん:2013/03/26(火) 21:35:41.46
livedoorメール終了かよ
クローズドなサービス使ってたばちが当たったわ
787デフォルトの名無しさん:2013/03/26(火) 23:08:39.40
本の虫乙
788デフォルトの名無しさん:2013/03/26(火) 23:09:42.99
オープンかどうかとサービスの継続に何の関係があるんだ
789デフォルトの名無しさん:2013/03/26(火) 23:44:45.55
オープンなら最悪自分で鯖立てて継続できるじゃん
790デフォルトの名無しさん:2013/03/26(火) 23:48:23.64
そういうの気にする奴に限って自分で何かアクション起こしてる気配がない
ただ口だけ
791デフォルトの名無しさん:2013/03/26(火) 23:51:29.96
ドメイン譲ってもらうか、転送サービスやってもらわないとどうにもならんだろ? > 継続
メールアドレス別でいいなら、中身は単なるGmailなんだからどこでも行けばいいし。
792デフォルトの名無しさん:2013/03/26(火) 23:51:53.57
メルサバのメンテなんて金もらってもやりたくないが
漢気溢れる誰かがやってくれるんだろう
793デフォルトの名無しさん:2013/03/27(水) 00:12:15.80
>>791
移った先がまた終了するだろ
794デフォルトの名無しさん:2013/03/27(水) 00:19:03.06
先見性の無い馬鹿だなあ
795デフォルトの名無しさん:2013/03/27(水) 00:24:30.47
先見性があればクローズドなサービスなんて使わないわけで
796デフォルトの名無しさん:2013/03/27(水) 19:26:57.77
まさに安かろう悪かろう
どこの馬の骨か判らない他人に依存してる時点で負け
797デフォルトの名無しさん:2013/03/27(水) 20:43:18.28
そしてGmail全面有料化ですね。わかります。
798デフォルトの名無しさん:2013/03/28(木) 07:49:00.09
足るを知る
799デフォルトの名無しさん:2013/03/29(金) 12:30:59.42
1y(14?)の話題があるかと思って来てみれば皆無だった
800デフォルトの名無しさん:2013/03/29(金) 15:41:44.18
swap演算子は結構衝撃的だった
801デフォルトの名無しさん:2013/03/29(金) 16:31:17.08
>>799
提供よろしく
802デフォルトの名無しさん:2013/03/29(金) 16:55:55.53
1yは2019年までに出るのかのう
803デフォルトの名無しさん:2013/03/29(金) 17:51:23.99
swapなんかユーザーコードでそんなに使うかなあ…
わざわざ演算子にまでする意味を感じない
ソートが少し書きやすくなるくらいじゃないの
804デフォルトの名無しさん:2013/03/29(金) 17:56:25.33
いちいちswapフリー関数を多重定義しなくていいし使うときにヘッダをincludeしなくてもいいのは楽だ
805デフォルトの名無しさん:2013/03/29(金) 20:35:34.25
moveがある今となってはswapを別途定義する機会も減ってるだろうに
いまさら演算子追加してもあんまり嬉しくない気がする
806デフォルトの名無しさん:2013/03/29(金) 21:11:50.60
swapは割と使うけど、moveがあればそうは使わないかもしれない

演算子追加するならローテート演算子が欲しい
暗号系でよく使うので
807デフォルトの名無しさん:2013/03/29(金) 21:27:38.66
constexprみたいな場面では便利かもしれない
808デフォルトの名無しさん:2013/03/29(金) 21:35:49.57
UTF8を前提にして
使える記号を増やしてほしい
括弧の種類とか増やしてくれ
809デフォルトの名無しさん:2013/03/29(金) 21:58:56.23
キーボードにないだろ
小さなcore言語+ライブラリで対応していく流れに逆行するのもいい加減にしろ
810デフォルトの名無しさん:2013/03/29(金) 22:16:14.62
キーボードくらい買えばいいだろ
文字の種類が増えれば:=:みたいな見苦しい演算子はいらないし
811デフォルトの名無しさん:2013/03/29(金) 22:22:32.99
典型的な想像力の欠如の例だな
812デフォルトの名無しさん:2013/03/29(金) 22:25:28.58
文字の入力くらいエディタでどうとでもできるだろ
813はちみつ餃子 ◆8X2XSCHEME :2013/03/29(金) 22:37:22.19
ありふれた C++ のコードをデンマーク語の文字コードとして表示させようとするとワヤになる話が D&E にも載ってる。
ラテン文字だけでも何かと問題は多いので UTF-8 を採用する案は悪くないと思う。 実際にはそれほど使わなくても。
だだ、文法と密接な関係がある予約語や記号類に使う文字は限定的にすべきではあると思うぞ。
814デフォルトの名無しさん:2013/03/29(金) 22:37:26.89
>>808
http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3AScheme%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AE%E3%83%AC%E3%83%99%E3%83%AB10
レベル5
仕事でJavaやC++を使っている時にああここでちょいと クロージャを使って再帰すれば、と思うことがある。
救いを求めてファンクタなど使ってみるが、 (), {}, [], <>などという4種類もの括弧にもはや頭がついていかない。 括弧は()で十分だ。
815はちみつ餃子 ◆8X2XSCHEME :2013/03/29(金) 22:43:24.98
>>814
Scheme でも [ ] が括弧として使えるようになったけどな。 意味は ( ) と全く同じだけど。
そんでもってもっと大事なことだが、 Scheme は Unicode を採用した。 変数名に漢字も使えるよ。
816デフォルトの名無しさん:2013/03/29(金) 22:58:30.73
特殊文字を使うのは、古くはAPL、割と最近だとFortressみたいな実験言語で
試みられているアプローチではあるが、大成功したという話を聞いたことはない
817デフォルトの名無しさん:2013/03/29(金) 23:11:27.47
[[]]とか
D言語の!()とか
苦労しているように見えるけどなあ
演算子も数学の演算子が使えた方がいいと思うし
818デフォルトの名無しさん:2013/03/29(金) 23:15:42.53
新しい括弧使えば
頭にいちいちtemplateって書く必要もなくなるし
819デフォルトの名無しさん:2013/03/29(金) 23:21:13.35
このバカなんなの
820デフォルトの名無しさん:2013/03/29(金) 23:26:34.24
今使っている文字が当たり前だと思う方が馬鹿
821デフォルトの名無しさん:2013/03/29(金) 23:35:01.25
独走態勢だね
822デフォルトの名無しさん:2013/03/29(金) 23:36:58.24
馬鹿はずっとASCII文字だけ使ってろ
823デフォルトの名無しさん:2013/03/29(金) 23:37:42.69
孤立無援だね
824デフォルトの名無しさん:2013/03/29(金) 23:38:22.52
>>823
baka ha ascii mozi igai tukauna
825デフォルトの名無しさん:2013/03/29(金) 23:39:47.76
プログラムソースコードにローマ字は禁止した方がいいね。
英語で書けばすむだろって話なんだから。
826デフォルトの名無しさん:2013/03/29(金) 23:52:30.47
ローマ字表記になると読む速度が格段に落ちるんだが、何故だ…
827デフォルトの名無しさん:2013/03/29(金) 23:59:37.50
テキストファイルにASCII文字でプログラミング
なんて通用するのは21世紀まで
828デフォルトの名無しさん:2013/03/30(土) 10:45:56.90
ASCIIの32個の制御文字が半分で、その分 graph が増えてたら色々生産性上がってただろうな。
829デフォルトの名無しさん:2013/03/30(土) 11:07:25.27
他の言語では使ってる@と$ないよね
830デフォルトの名無しさん:2013/03/30(土) 14:54:10.31
@とか$はコードがキモくなるから使いたくない。
831デフォルトの名無しさん:2013/03/30(土) 15:01:25.69
^とかゲロキモイよな
832デフォルトの名無しさん:2013/03/30(土) 15:15:01.02
Perlさんdisってのかコラァ
833デフォルトの名無しさん:2013/03/30(土) 15:40:04.80
Blocksさんに謝れ!
834デフォルトの名無しさん:2013/03/31(日) 09:58:37.20
SCHEMEがUNICODEを使えるというのはべっくらいこいた
835デフォルトの名無しさん:2013/03/31(日) 10:14:27.89
$とかキモい変数名はやめて
全角文字の変数にしようぜ。
ジジイどもは卒倒するだろうが
ぜったいに保守性は上がる。
836デフォルトの名無しさん:2013/03/31(日) 10:49:00.80
それはいえてる、i とか j とかまで全角にする必要はないが、日本人にやさしいプログラムになりそうだ。
しかし問題が一つ、珍奇な概念の持ち主はやはり珍奇な漢語を羅列するだろう。命名規則はどうする?

prologスレにいい感じの奴があるが、あのレベルを皆に徹底するのは大変なのでは?
837デフォルトの名無しさん:2013/03/31(日) 11:04:58.82
プログラムコードは芸術作品だ。
美しく洗練されたコードには陶酔する。

@や$を使うなど、絵画作品にうんこマークを描くようなもんだ。
838デフォルトの名無しさん:2013/03/31(日) 12:04:16.88
レス番コンテナ<レス番整数> 全角文字を変数にしようとするバカのレス番を保存するコンテナ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
全角文字を変数にしようとするバカのレス番を保存するコンテナ >>835;
839デフォルトの名無しさん:2013/03/31(日) 12:14:13.27
>>835
ジジイどもの片割れがあぶり出てきたねえ
>>838
卒倒寸前だねえ、お体をお大事にしてくださいね、この杖でも使って
840デフォルトの名無しさん:2013/03/31(日) 14:00:47.67
コンテナに入れる機能を右シフト演算子に割り当てるとか気持ち悪い
841デフォルトの名無しさん:2013/03/31(日) 15:42:26.23
1y(14?)の話題があるかと思って来てみればswap演算子の話題が数レスだけだった。
842デフォルトの名無しさん:2013/03/31(日) 17:04:25.43
各国の文字列で書かれた変数名がプロジェクトで自由に使われたら大変だな
エディタに単語翻訳プラグインが必須になりそう
843デフォルトの名無しさん:2013/03/31(日) 17:10:44.08
UTF-8でいいじゃん
844デフォルトの名無しさん:2013/03/31(日) 17:16:32.22
|よりは>>,<<使うほうがまし
845デフォルトの名無しさん:2013/03/31(日) 17:25:30.98
>>842
プライムベンダーが使用する文字を
決めればok。
それが読めない奴は仕様書も読めないので問題なし。
846デフォルトの名無しさん:2013/03/31(日) 17:46:25.24
標準化の提案をする気のない主義主張はもういいよ。
847デフォルトの名無しさん:2013/03/31(日) 17:53:56.68
少なくとも「あ」が識別子に使えることは
ISO/IEC 14882:2011で義務付けられてるな
848デフォルトの名無しさん:2013/03/31(日) 18:13:50.48
使えるからってキリルとか連発されても意味わかんねえよ
ってのが>>842だと思うんだけど違うの?
849デフォルトの名無しさん:2013/03/31(日) 18:20:15.83
識別子の多言語化くらいできてほしいわな
850デフォルトの名無しさん:2013/03/31(日) 18:36:01.53
VBAでやってみたことがある
可読性はある程度改善されるけど
タイピングでめんどくさすぎるからやめた
851デフォルトの名無しさん:2013/03/31(日) 19:43:24.34
ゲームのDSLで日本語で変数とか使うスクリプト書いてたことあるけど慣れればどうってことないよ
むしろ名前考えるときに英語脳使わずに済むので楽だった
852デフォルトの名無しさん:2013/03/31(日) 20:15:31.36
変数名がアラビア語やヘブライ語か何かでガシガシ書かれてて、それを読めと言われたら多分泣く
853デフォルトの名無しさん:2013/03/31(日) 20:19:33.93
>>848
メリットがあると主張する人がいる一方で、
「自分が使ったことなく違和感あるからNG
(ダメな根拠無し)」
と言う理屈は通らないでしょ一般的に。
854デフォルトの名無しさん:2013/03/31(日) 20:19:38.46
多言語化すればボタンひとつでアラビア語の変数名が日本語の変数名になる
855デフォルトの名無しさん:2013/03/31(日) 20:25:50.48
問題が起きるケースがある=全否定
これが否定派の論拠
識別子ぐらいでガタガタ言うな
856デフォルトの名無しさん:2013/03/31(日) 20:35:48.41
ソースコードの多言語翻訳に対応したエディタがあれば解決だな
どっかに有りそうだけど
857デフォルトの名無しさん:2013/03/31(日) 20:39:10.16
853,855って人の言ってること聞いてるのか?
858デフォルトの名無しさん:2013/03/31(日) 20:40:12.79
誤変換しやすい単語は地味にめんどかった。
以上 異常 とか両方使ってたから困る。
859デフォルトの名無しさん:2013/03/31(日) 20:41:12.25
どうせ略すんだから翻訳なんてまともに出来るわけねえ
860デフォルトの名無しさん:2013/03/31(日) 20:42:57.18
>>856
何で翻訳とかおかしな方向に走るのよ?
多言語カオスなソースじゃなくて、
仕様書と同じ自然言語の用語ぐらい
使わせてってことだよ。
861デフォルトの名無しさん:2013/03/31(日) 20:58:57.16
>>860
ボタンひとつで〜ってのがあったから、それに反応したんだ

コーディング規約できっちり縛れるならありだと思ってる
運用しやすいかは良く分からん
862デフォルトの名無しさん:2013/03/31(日) 21:22:02.19
規格のスレなんだから可能・不可能で良いだろう。そんなものの是非など、どうでもよい。
863デフォルトの名無しさん:2013/03/31(日) 21:27:39.25
インド人に仕事を取られないうちに
変数名を日本語にしとけ
864デフォルトの名無しさん:2013/03/31(日) 21:43:33.70
全部ひらがなで書けばコードがかわいくなる
865デフォルトの名無しさん:2013/03/31(日) 22:02:56.53
女子高生プログラマの誕生である。
866デフォルトの名無しさん:2013/03/31(日) 22:07:05.60
高校生なのにプロって、おかしくね?
867デフォルトの名無しさん:2013/03/31(日) 23:49:35.57
お前らどうでもいい
868片山博文MZパンク ◆0lBZNi.Q7evd :2013/04/01(月) 13:50:21.53
869デフォルトの名無しさん:2013/04/01(月) 15:58:23.13
What's New in C++11

Presenter:
Jason Merrill
Slides:
http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=jason.pdf
Video:
part 1: http://youtu.be/-eTrk-52Plk
part 2: http://youtu.be/IdinxdLHpTc

The second revision of the C++ language standard, C++ 2011, was
ratified last year, thirteen years after the first one. In this talk,
I will discuss notable additions to the language since C++98/03.

@GNU Tools Cauldron 2012
870デフォルトの名無しさん:2013/04/01(月) 22:01:08.46
>>868
これ、テンプレに加えといて
871デフォルトの名無しさん:2013/04/01(月) 22:28:00.65
今更いらないだろ
872デフォルトの名無しさん:2013/04/01(月) 23:32:01.98
テンプレに入れるべきではないな。
参照してる殆どがドラフトじゃないか。
ハゲの書物は昔から「仕様だと信じたら
標準化に入り損ねたハゲの妄想でした」
が多すぎる。

ただハゲは背景とか考え方を説明
しようとする点は評価できる。
873デフォルトの名無しさん:2013/04/02(火) 01:02:41.69
D&Eが好評な部分は、なぜそうしたのか
設計者として説明しようとしている点にあるとは思う
そういう本はすごく珍しい
874デフォルトの名無しさん:2013/04/02(火) 01:58:11.95
ライブラリにしてもフレームワークにしても、設計思想を教えてくれないと使い方が
判りにくいよな。どういう使い方想定してんのか。

まあ、最近はサンプルつけるのが流行ってるみたいだから、この辺も改善されてきてるか。
875デフォルトの名無しさん:2013/04/02(火) 15:10:29.30
>>873
あのくらいしっかり説明してるのは珍しいな。
しかも本としてまとまっているのは。
Lisp関係もどういうドキュメントは多いけども。

禿はもともとAT&Tの多社乗り入れ電話交換器に
各社アドオンを組み込む機構の設計をしていた。
だから設計の根拠を説明するのが
長年やりこなしてきた業務の一つだったんだろうな。
調整も巧いと思う。安易に反対したり、
思想対決に持ち込まずに、長文の技術論文を書く。
876はちみつ餃子 ◆8X2XSCHEME :2013/04/02(火) 15:30:28.28
プログラミング言語の設計って理想主義的になりがちだけど、プログラマの教育 (のための資料) の充実具合だとか、
開発環境がどの程度追い付いているかとかも見定めて現実と折り合いを付けてきたってところはすごいと思う。
877デフォルトの名無しさん:2013/04/02(火) 15:48:26.17
いきなりの擁護ラッシュこええ
878はちみつ餃子 ◆8X2XSCHEME :2013/04/02(火) 16:27:32.17
この規模の言語がどうにかこうにか受入れられてるのは、
言語そのものの設計だけじゃない色々な点でうまくやったからだということを言ってるのであって、
逆に言えば、言語そのものはグダグダであるという話なんだけど、それって擁護か?
879デフォルトの名無しさん:2013/04/02(火) 16:33:22.36
よくもわるくも高級アセンブラ
今はいろんなもの詰め込みすぎてカオス
880デフォルトの名無しさん:2013/04/02(火) 18:37:20.91
2chは最強装備で完全攻略しないと気が済まない人間が多いから
C++は人気無いよね
881デフォルトの名無しさん:2013/04/02(火) 19:18:37.35
人気なんてどうでもいい
そもそもC++は誰にでも扱える様なものじゃない
882デフォルトの名無しさん:2013/04/02(火) 19:31:16.67
誰でも使いやすいように禿先生たちは日夜頑張っているというのに…
883デフォルトの名無しさん:2013/04/02(火) 19:32:19.25
Haskell以上に保守性のない言語
884デフォルトの名無しさん:2013/04/02(火) 19:34:04.77
>よくもわるくも高級アセンブラ
それはPure Cだろ
C++はカオスもう整形しすぎて崩壊してきてる。
実際大規模プログラミングはPure C で局所的にアセンブラ感覚で
息を止めて慎重にコーディングして速度を稼ぎながら
外枠はC#でいい
Parallel.Foreachで簡単にマルチコアの恩恵を受けられるようになった今
全部C#でほぼ問題なし
>>507
>エンコーダも作れるだろ。1分エンコードするのに数日かかるかもしれんが。

アホかおまえは。
一体どんなコード書いてるんだ。実際 Pure Cと比較しても1.5倍程度で収まる。
885デフォルトの名無しさん:2013/04/02(火) 19:38:20.01
>>485
>それは本当に速度が要求されるプログラム組んだ事無いだけだろ

本当に速度が要求される部分でC++てアホかおまえは。
そういう場面は最低コンパイル後のアセンブリコードがほぼ見えるCで書くか、
直接アセンブラで書くわ。
886デフォルトの名無しさん:2013/04/02(火) 19:39:13.24
> 思想対決に持ち込まずに、長文の技術論文を書く。
技術者の鑑だな。
887デフォルトの名無しさん:2013/04/02(火) 19:43:44.93
SIMD大好き♪
888デフォルトの名無しさん:2013/04/02(火) 20:10:15.07
N3571のstd::simdは無いよりあったほうがいいだろうけど
なんか物足りない
889デフォルトの名無しさん:2013/04/02(火) 20:24:29.46
思想がわかると、使う側もいろいろと判断し易いよね。
890デフォルトの名無しさん:2013/04/02(火) 22:04:41.34
>>835,836
昔Mindとかあった。
まぁあれはForth系だけど。
891デフォルトの名無しさん:2013/04/02(火) 22:07:49.03
C+11で大分初心者には書きやすくなったけど、言語仕様が縮小したわけじゃないからな・・・
892デフォルトの名無しさん:2013/04/02(火) 22:38:52.13
ようやくC++03を完全に理解したのに
もうC++11が出たよ
893デフォルトの名無しさん:2013/04/02(火) 22:57:40.29
今何年だと思ってんだよ。
2003はマイナー変更だから、
実質15年もかかった>>892には無理
894デフォルトの名無しさん:2013/04/02(火) 23:21:22.05
>>890
ひまわりもアイシテ

って今はなでしこか...
895デフォルトの名無しさん:2013/04/03(水) 00:02:43.41
ゴミみたいなイテレータでのループが隠蔽されたのは良かった
896デフォルトの名無しさん:2013/04/03(水) 00:12:23.07
>>893
15年前はまだ生まれてないし
897デフォルトの名無しさん:2013/04/03(水) 00:29:32.26
こんな時間まで起きてる子供はクズ
898デフォルトの名無しさん:2013/04/03(水) 00:49:40.04
本の虫の解説本が出たら本気出す
899デフォルトの名無しさん:2013/04/03(水) 07:30:21.93
一生でないな
900デフォルトの名無しさん:2013/04/03(水) 07:43:59.51
テンプレート回りの強力さとかで、
普通にCで書くより、普通にC++で書いた方が
速いコードにはなりやすいよね。
901デフォルトの名無しさん:2013/04/03(水) 07:50:44.01
等価なアホレス
"普通にアセンブラで書くより、Cで普通に書いた方が
速いコードになりやすいよね。"

おまえのようなアホが書かない限り、C++で書くより
継承なんてもんがないCで書いた方が速いんだよッスカタン
902デフォルトの名無しさん:2013/04/03(水) 07:53:29.90
適当なスクリプト言語や関数型言語を使ってCのコードを生成した方が
C++でテンプレート使うより保守性も高いのであった...
903デフォルトの名無しさん:2013/04/03(水) 07:56:09.54
テンプレはexeサイズも馬鹿でかくなる愚の骨頂
904デフォルトの名無しさん:2013/04/03(水) 08:11:02.33
テンプレートが速いとか、何の冗談か
905デフォルトの名無しさん:2013/04/03(水) 08:14:54.81
何と比べるのか、具体的な条件が明示されていないのに、
速いとか遅いとか言い始める奴はどっちも馬鹿。
906デフォルトの名無しさん:2013/04/03(水) 08:18:53.11
アホしかいねーなこのスレは
907デフォルトの名無しさん:2013/04/03(水) 08:23:50.11
2chはあほが濃縮されてる
908デフォルトの名無しさん:2013/04/03(水) 10:48:47.38
いや以前はずっとマシだった
uyとQが現れてからこの双頭のキチガイによって質が低下している
909デフォルトの名無しさん:2013/04/03(水) 12:39:27.59
本当にCでコンパイル後のアセンブリコードがほぼ見える人間ならC++だって同じだろ?
何を言ってるんだか
910デフォルトの名無しさん:2013/04/03(水) 12:52:26.52
>>908
相手する方が質の低下を加速してあげてる件。
911デフォルトの名無しさん:2013/04/03(水) 13:06:00.48
>>909
C++のコードはiostreamを使っただけで肥大するし、コンテナを使ったら
もうカチャカチャ
それに仮想関数の呼び出しはコードを追い掛けるだけでは一体どこに
ジャンプするか予想しにくく、トレースするしかない
912デフォルトの名無しさん:2013/04/03(水) 13:11:36.03
>>910
あくまでも人のせいにする気か
この二人を消すだけで十分
913デフォルトの名無しさん:2013/04/03(水) 13:12:08.41
>>911
ライブラリの話を言語の違いと混同されても。。。
それに、仮想関数の呼び出しが予想しにくいって?仮想関数の呼び出しメカニズム
(というか仮想関数テーブルのセットアップメカニズム)本当に理解してるか?
914デフォルトの名無しさん:2013/04/03(水) 13:18:44.29
仮想関数がしっくりこない系おじさんか。
915デフォルトの名無しさん:2013/04/03(水) 13:43:48.89
>>913
お前エスパーか?どの仮想関数が呼ばれるかは、ジャンプする場所に来てみないと
分からない
その時にメモリから呼び出すかレジスタの値でオフセットでジャンプテーブルを呼び出すかは
別として、call [rbx] とか書かれててみ
rbxの値が事前に予測出来るとでも?
916デフォルトの名無しさん:2013/04/03(水) 13:53:13.66
それに標準ライブラリの中には継承で作られている物も多い

istream、ostream、ifstream、ofstream、istringstream、ostringstream全部継承だ
つまり内部では仮想関数が使われている

混同ではない
917デフォルトの名無しさん:2013/04/03(水) 14:06:59.15
struct A {
virtual void print() const {
std::cout << "A" << std::endl;
}
virtual ~A() {}
};

struct B : public A {
void print() const {
std::cout << "B" << std::endl;
}
};

int main()
{
boost::ptr_vector<A> vap;

for (int i = 0; i < 100; i++)
vap.push_back((((std::rand() >> 1) % 2) & 1) ? new A : new B);

std::for_each(std::begin(vap), std::end(vap), [&](A& ar) { ar.print(); });
}

たとえばこんな簡単なプログラムでも、事前にAが呼び出されるのかBが呼び出されるのか
簡単に予測出来るか?
ptr_vectorの中身を見るというのは無しで
その気になればコンテナに入れずに呼び出し時にrand()で振り分けるからな
918デフォルトの名無しさん:2013/04/03(水) 14:10:43.71
できました!ありがとう
919デフォルトの名無しさん:2013/04/03(水) 14:16:42.38
誰だ貴様!
920デフォルトの名無しさん:2013/04/03(水) 14:19:43.33
継承=仮想関数とか言ってる時点で。。。
やれやれ
921デフォルトの名無しさん:2013/04/03(水) 14:30:44.74
>全部継承だ
>つまり内部では仮想関数が使われている

晒しage
922デフォルトの名無しさん:2013/04/03(水) 14:40:07.29
>>920
アホ発見

>>921
無知は罪
923デフォルトの名無しさん:2013/04/03(水) 14:47:33.71
迷惑なんで
はやく仮想関数の呼び出しを簡単に予想する作業に戻ってくれませんかね
924デフォルトの名無しさん:2013/04/03(水) 14:48:27.96
デタラメを書かれる事が迷惑なんだが
925デフォルトの名無しさん:2013/04/03(水) 15:21:55.35
どうせJava脳なんだろこの馬鹿は
926デフォルトの名無しさん:2013/04/03(水) 15:55:19.86
あくまでも継承じゃないと言い張るなら、このコードが通る理由をお聞かせ願えますかね

int main()
{
std::iostream* ip;
std::string str;
std::stringstream os(str);

os << "abc" << std::endl;
std::cout << os.str().c_str();
ip = &os; // なぜ通る?
}
927デフォルトの名無しさん:2013/04/03(水) 16:27:32.21
スレ違いなんで相手にしなくていいよ
928デフォルトの名無しさん:2013/04/03(水) 16:46:10.44
あら?継承だと初めて気づいたら「スレ違い」扱いですか
分かりやすいですねww
929デフォルトの名無しさん:2013/04/03(水) 16:57:11.68
int main()
{
std::iostream* ip;
std::string str;
std::stringstream os(str);

os << "abc" << std::endl;
std::cout << str;
ip = &os; // なぜ通る?
}
930デフォルトの名無しさん:2013/04/03(水) 17:19:21.02
kityguy
931デフォルトの名無しさん:2013/04/03(水) 17:34:24.84
とうとう誰も言ってない主張に反論はじめましたよこのキチガイ
932デフォルトの名無しさん:2013/04/03(水) 17:44:29.40
仮想関数と同じ事をCでやろうとした方が
遅くなるし、どういう動きになるか分かり辛い。
933デフォルトの名無しさん:2013/04/03(水) 17:48:20.09
>>921で主張しているのにも気付かないキチガイ
934デフォルトの名無しさん:2013/04/03(水) 17:49:05.63
このスレ、テンプレがシンプルでなにを対象にしているか分かりにくい気がしますね。
自分はC++11とか、それ以降の規格や新機能について議論するスレだと
勝手に思っていたのですが、そういったことは明記されていないですね。

11なんかはスレ番とか思ってる人もいるんではないでしょうか?
あらためて、スレの方向性とか考えてテンプレ考えてみてもいいのでは?

ただ、ネタがないので暇つぶしに相手してあげることをとめたりはしません(2chですし)
935デフォルトの名無しさん:2013/04/03(水) 17:54:16.86
今暴れてるようなやつはテンプレがどうであれ暴れるよ
936デフォルトの名無しさん:2013/04/03(水) 18:54:06.46
stringだって、派生クラスだ!
937デフォルトの名無しさん:2013/04/03(水) 19:20:23.87
俺のせいかよ
938デフォルトの名無しさん:2013/04/03(水) 19:24:31.82
ゴミが無知を指摘されてファビョるスレがあると聞いて
939デフォルトの名無しさん:2013/04/03(水) 19:38:39.24
Rubyとかが出て低年齢層がプログラミングやるようになったせいか
940デフォルトの名無しさん:2013/04/03(水) 19:45:23.99
N-BASICの時代から低年齢層でもプログラミングを楽しんでいましたよ、N-BASICからZ80に一足飛び、というのもすばらしいじゃないですかっ
941デフォルトの名無しさん:2013/04/03(水) 19:55:27.57
継承先生は条件ジャンプをいつ発見するんだろうか?

つーかcall [rbx]とかは分岐予測して投機実行しないの?
最近のプロセッサは分からん…
942デフォルトの名無しさん:2013/04/03(水) 20:05:44.74
どうみても投棄実行です
943デフォルトの名無しさん:2013/04/03(水) 20:17:40.99
すてるのか?
944デフォルトの名無しさん:2013/04/03(水) 20:50:15.26
>>904
クイックソートの例を。

C = 10375ms (Visual C++ 2012)
struct x { int v1; };
int x_comp(void const *lhs, void const *rhs) { return ((struct x const *)lhs)->v1 - ((struct x const *)rhs)->v1; }
qsort(pa, N, sizeof(struct x), x_comp); // Nは1億

C++ = 7730ms (Visual C++ 2012)
struct x { int v1; };
struct x_less { bool operator()(x const &lhs, x const &rhs) { return lhs.v1 - rhs.v1 < 0; } };
std::sort(pa, pa + N, x_less());

v1はstd::srand(1234)で発生させた乱数
945デフォルトの名無しさん:2013/04/03(水) 20:55:39.44
バカvsバカ
946デフォルトの名無しさん:2013/04/03(水) 21:21:09.92
>>944
関数ポインタ経由だと、それだけで、それはそれは遅くなるに決まってるでしょう、インラインで展開される場合にくらべると。
947デフォルトの名無しさん:2013/04/03(水) 21:24:54.91
コンパイル速度の話だったのかな
948デフォルトの名無しさん:2013/04/03(水) 21:26:19.50
qsortにしろstd::sortにしろそのアルゴリズムがクイックソートだなんて決まってないんだし
同じアルゴリズムじゃないと「テンプレートが速い」ことを示す例として不適切だと思うんだが
そのへん検証したの?
949デフォルトの名無しさん:2013/04/03(水) 22:00:35.06
c++は遅いな。コンパイルがw
テンプレは強力にインライン展開されるんだから、
この手の単純な処理はcより速くて当たり前。
950デフォルトの名無しさん:2013/04/03(水) 22:01:53.35
一連の書き込みはエラーとして一旦、ロールバックせよ。
951デフォルトの名無しさん:2013/04/03(水) 22:06:33.13
Pentimu4で一億回関数を呼び出して、測定不能レベルの速度なんだけどね。
952デフォルトの名無しさん:2013/04/03(水) 22:24:59.77
馬鹿相手にするの辞めろよ。
スレ違いな上に、話が想像を絶するくらい下らないのに。
953デフォルトの名無しさん:2013/04/03(水) 22:27:53.50
Cの標準ライブラリはC++のSTLより遅くなる。
で、ゴリゴリ最適化すれば速くなるかもしれないけどそれはC++でも一緒。
そうなると選択肢を狭める意味が見いだせない。
954デフォルトの名無しさん:2013/04/03(水) 22:32:55.02
測定不能ってwinだと10ミリ以下ぐらい?
普通クロックは3GHz程度(0.3ナノ秒)しか無いんだが
関数callが0.1ナノ秒なんて
すごいアーキテクチャーですねw
955デフォルトの名無しさん:2013/04/03(水) 22:32:57.99
C++11のアルゴリズムやコンテナはかなりstd::moveを使って最適化されてるぞ
956デフォルトの名無しさん:2013/04/03(水) 23:14:20.60
お前以外みんな知ってるよ
957デフォルトの名無しさん:2013/04/03(水) 23:23:57.40
なんでそういう風に憎まれ口を叩くんだ?
恨んで欲しいのか?
958デフォルトの名無しさん:2013/04/03(水) 23:28:09.30
たまに伸びてると思ったらコレかよ
concept liteの話とかしろよしてください
959デフォルトの名無しさん:2013/04/03(水) 23:33:31.14
ストリームが継承だと知らなかった馬鹿が暴れてるようなんです
自尊心が傷ついたようで
960デフォルトの名無しさん:2013/04/03(水) 23:43:40.43
ストリームが継承だと知っていたところで自尊心を肥大化させる以上の使い道があるのか?
961デフォルトの名無しさん:2013/04/03(水) 23:48:42.40
継承馬鹿は未だに何が馬鹿なのか気付いてない模様
962デフォルトの名無しさん:2013/04/03(水) 23:52:54.29
もしかして:
仮想関数なら常に間接コールになると勘違いしてる
963デフォルトの名無しさん:2013/04/03(水) 23:55:53.81
>>962
それはお前だけだと思う
964デフォルトの名無しさん:2013/04/03(水) 23:59:14.37
>>960
ストリームをポインタで切り替えて使った事もないのか
965デフォルトの名無しさん:2013/04/04(木) 00:09:28.60
人を自分より馬鹿だと思わないと自分の自尊心を保てない自己愛が肥大した
自己愛性パーソナリティ障害の人が住み着いてるようですねえ
966デフォルトの名無しさん:2013/04/04(木) 00:17:32.55
自己愛性パーソナリティ障害
967デフォルトの名無しさん:2013/04/04(木) 06:34:50.22
飛び先を動的に決めたい人はvirtual付け、
固定にしたい人は「継承してもvirtual付けない」。
さすがに>>911もわかってるだろ。

で、iostreamが前者の設計になっていて
>>911のデバッグ作業に時間がかかって
>>911のお気に召さなかった。
好き嫌いは人それぞれだか問題ない。
968デフォルトの名無しさん:2013/04/04(木) 06:51:04.16
virtual付けない継承なんて。。
話が想像を絶するくらい下らない。
969デフォルトの名無しさん:2013/04/04(木) 07:15:05.21
ジャンプを固定にしたいなら継承するな
これでok
970デフォルトの名無しさん:2013/04/04(木) 09:39:58.33
>>967
妄想乙
お前がそういう目に遭っているから他人もそうだとしか見えないんだろうな
頭おかしいよはっきり言うと
971デフォルトの名無しさん:2013/04/04(木) 10:00:34.25
頭おかしい
972デフォルトの名無しさん:2013/04/04(木) 10:01:24.60
自己紹介
973デフォルトの名無しさん:2013/04/04(木) 10:22:16.26
すぐ反応www

精神科に行った方がいいぞ
974デフォルトの名無しさん:2013/04/04(木) 10:28:22.97
精神科
975デフォルトの名無しさん:2013/04/04(木) 11:54:03.79
いいこと思いついた。
thisを引数にとる関数を用意して
ポリモーフィズムを実装し、
その関数ポインターをメンバーに持てば
コンパイラが裏でやる謎の処理に
惑わされずに自分でキッチリ制御できる。
976デフォルトの名無しさん:2013/04/04(木) 12:06:20.45
お前頭いいな
977デフォルトの名無しさん:2013/04/04(木) 12:24:48.91
pythonの誕生ですねわかります
978デフォルトの名無しさん:2013/04/04(木) 12:27:03.01
大規模プログラミングのために生産性をあげる仕組みはもうC++なんかに必要ない
そんなのはC#でやればいい。
だいたい継承なんて生産性向上のための仕組みでしかない
アセンブラの代わりはCでいい。側はC#
C++はもう居場所がない。
ちなみに組み込みとかC++より未だにCが圧倒的に多いし。
そもそもC++じゃ生産性が上がらないんで全面リニューアルしたのがC#ともいえる
javaやらJ++やら裁判沙汰の経緯を蒸し返すなよ >>all
979デフォルトの名無しさん:2013/04/04(木) 12:28:56.74
何そのヤケクソ
980デフォルトの名無しさん:2013/04/04(木) 15:29:46.87
981デフォルトの名無しさん:2013/04/04(木) 16:14:28.74
最初の20行くらいしか読んでないけど
>>980のリンク先書いてる奴が超絶低能だというだけで
C++固有のことではない非同期処理をここに貼っても釣れないだろ

こんなのが本書いてる状況はアレだと思うが
982デフォルトの名無しさん:2013/04/04(木) 16:34:32.38
C++ではなくてC++/CLIなんだが・・・この著者大丈夫か?
983デフォルトの名無しさん:2013/04/04(木) 17:44:16.70
Task, Parallel.Foreach,lockを駆使して日々並列プログラミングと格闘してるC#ユーザからすると
今更何寝ぼけてる?って記事だな。
C++は未だに粒度の小さいプログラムの並列化に四苦八苦してるからな
984デフォルトの名無しさん:2013/04/04(木) 17:44:39.35
C#はVMありきなJavaの置き換えだろ。
985デフォルトの名無しさん:2013/04/04(木) 17:46:48.87
>>982
C++/CXでは…
986デフォルトの名無しさん:2013/04/04(木) 17:48:17.65
http://itpro.nikkeibp.co.jp/article/Watcher/20130331/467401/?ST=develop&P=4
>C++でWindowsストア アプリを作る場合、非同期メソッドを順次実行させるのは面倒だ。
>Visual Basic(以下VB)とC#では、Async(VBの場合、C#ではasync)と
>Await(VBの場合、C#ではawait)という二つのキーワードを導入したことで、C++よりは簡単に記述できる。

一応認めてるんだな。
実際未だに満足な並列プログラムを書きにくい時点でC++の存在価値は地に落ちた
987デフォルトの名無しさん:2013/04/04(木) 17:53:25.95
別にC++でも並列プログラムぐらい普通に書けるだろ。
どちらかというとMSのAPIが糞ってだけで
それも、並列プログラムが書きにくいというのではなく
並列じゃない処理が書きにくいという意味不明さ
988デフォルトの名無しさん:2013/04/04(木) 17:55:45.01
http://itpro.nikkeibp.co.jp/article/Watcher/20130331/467401/?ST=develop&P=5
>ユーザーインタフェースについては、C++よりもVBやC#で書く方が生産性が高いだろう。一方で、
>記者が今回の経験でC++を使うことの意義を再認識したのも事実だ。

こういうアホっているんだな。
ソフトウェアでそら無理して時間をむだにすりゃなんとかつじつま合わせできるだろ。
数値計算もMathematicaでできるが、
そこは無理せずMatlab使うのがスマートなソリューションであって、
無理して時間かけてもだれも褒めてくれない
適材適所ふさわしいツールを使うのが開発の常識だよ無能ライターくん
989デフォルトの名無しさん:2013/04/04(木) 17:57:54.85
>>987
ほう.じゃ,タスク内のループ処理で各コアに均等にループを割り当てて処理時間かせぐような処理が
C++で簡単にかけるかね?
990デフォルトの名無しさん:2013/04/04(木) 18:01:01.69
案の定よく釣れる餌でしたねっ!
991デフォルトの名無しさん:2013/04/04(木) 18:10:08.82
均等にの条件が良く分からんけど
#pragma omp parallel for
でおわりじゃないの?
992デフォルトの名無しさん:2013/04/04(木) 19:04:32.84
OpenMPでforループバラしたんだけど、
かなり大きな処理量じゃないと、オーバーヘッド(スレッド切り替え?)が大きすぎて
ぜんぜん有難味がなかったガッカリした。
993デフォルトの名無しさん:2013/04/04(木) 19:10:23.49
そりゃそうだろ…
994デフォルトの名無しさん:2013/04/04(木) 19:13:02.24
>>993
何でスレッドの切り替えってこんなに時間かかるの??
995デフォルトの名無しさん:2013/04/04(木) 19:18:53.20
スレッドだと重いんでTPLがあるんじゃねーか
996デフォルトの名無しさん:2013/04/04(木) 19:21:03.59
>>994
TLBフラッシュがネック
997994:2013/04/04(木) 19:25:54.15
>>995
調べてみた。
.NetFrameworkなんだね。
生C++が好きだから使わないかな・・・。
でも、スレッドより軽くて並列処理ってすごいね。

>>996
なんと!
そんなところがネックになっていたとは・・・!!
もう並列処理はGPUにやらせます!
998デフォルトの名無しさん:2013/04/04(木) 19:27:52.69
いや、スレッド切り替えが問題になるような
軽い処理はGPUじゃもっとヤバイだろ。
999994:2013/04/04(木) 19:38:28.79
>>998
あ、その通りでござんすw
そういう処理はSIMDでやってますw
AVXマンセー。
1000デフォルトの名無しさん:2013/04/04(木) 19:42:43.33
次スレは18だから直しといてくれ
俺は無理だった
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。