2 :
デフォルトの名無しさん :2012/10/04(木) 23:22:19.44
君が死んでからもう1年。 君は今も僕を見守ってくれているのかな? 君は、僕の生まれて初めて出来た彼女だった。 すごく嬉しくて、幸せだったなあ。 突然、白血病だって医者に宣告されてから、君は病室で日に日に弱っていった。 「病院ってひまねえ」って笑う君を見て、僕はいつも泣いていたんだ。 君の為に、僕の小汚いノートパソコンをあげたら、君はすごく喜んでくれたよね。 ネットをするようになった君がいつも見ていたサイト、それが「2チャンネル」だった。 ある日君はいつものように、笑いながら言った。 「ほら、見て今日も2ゲット出来たよ。」 「あまりパソコンばっかいじってると身体に障るよ」 なんて僕が注意すると、「ごめんねえ。 でもね、これ見てよ。 ほら、この3のひと、2げっとぉ!なんて言っちゃってさぁ、ふふ」 僕は黙っていた。君がすごく楽しそうで、僕は何も言えなかった。 「ほらみて、この3のひと、変な絵文字使ってくやしぃ〜!だって。かわいいねえ。 ふふ。」 僕はまだ黙っていた。笑う君を見て、どうしようもなく悲しくなった。 「憶えててくれるかなあ」 君がふと言った。 「…この3のひと、私がいなくなっても、あの時変な奴に2をとられたんだよなーなんて、憶えててくれないかなあ……無理かな……憶えてて、ほしいなぁ……」 それから数ヶ月後、君は家族と僕に見守れながら息を引き取った。 君はもうこの世に居ない、なのに僕は今F5を連続でクリックしている。 君の事を、3のひとが忘れないように、いつまでも、いつまでも忘れないように。 天国にいる君と一緒に、今ここに刻み込む 2 ゲ ッ ト
4 :
デフォルトの名無しさん :2012/10/05(金) 00:04:02.16
前スレ最後の盛り上がりはどこへ?
スレをまたいで引っ張るようなネタか?
C++はオナニー言語。 業務アプリケーション開発には危険過ぎて使えず。 組み込みではCで充分という奴に迫害され、 難解な言語仕様勉強してる俺SUGEEEな 人たちが自分のプライドを保つための 最後の砦。
組み込みでもわりと使われてるけど
難解な言語ではあるが、概念的に高度というわけではなく ただ単にこんがらがっているだけ
プログラム言語Pastaに改名しよう
>>6 C++出来なくても仕事はあるから心配ないよ
12 :
デフォルトの名無しさん :2012/10/05(金) 01:42:50.82
言語仕様よりも、実行環境のほうが何故か重宝される。 VCも.NETがあるけど、.NETじゃコンパイルを実行時に後回しにした…という感じにしか思えない。
14 :
デフォルトの名無しさん :2012/10/06(土) 15:55:00.40
最近11の検討を始めたんだが、すごいな… ラムダは待望だったから嬉しいけどけど、右辺値参照(だっけ?)にはワロタ 確かに使いどころによっては便利かもなとは思ったけど、マニアックすぎる 総じて、痒いところに手が届くのは嬉しいが、これから始める人には辛いかもな ますますオッサン言語化してる気がするよ
というか今まで無かったのがなぞだよな右辺値参照って
代入や引数渡しの所で記述できるように言語でサポートするのは面白いよね。 高レベルのレイヤーでの利用ノウハウが溜まったら、 他の言語でも類似の機能がサポートされたりして。
っていうか右辺値参照みたいなのが必要になるのはオブジェクトが変数に埋めこまれるからで オブジェクトといえばすべて参照経由な主流OOPLでは要らん機能だしなあ 埋めこみオブジェクトなOOPLって、C++以外だと何があるんだ
pre-Portland mailing 見るとまだまだお偉いさん方はC++いじる気満々だなw 新機能実験場というか論文のネタ場というか ちっとは現場でメンテするプログラマのことも考えてほしいぜ
conceptが今後採用されることになれば どうせ大規模な変更になるんだから 小手先のことなんてどうでもいいよ。
boostは完成しないからこそboostであり続ける
>>17 右辺値参照をメモリ管理だけの問題に矮小化しないでください!(怒
束縛と代入の動的な側面をプログラミング可能にし、
新しい意味や文脈を与える野心的な試みなんです。
問題は野心的過ぎることだけです。
全てのプログラミング要素は、最終的には右辺値参照に集約されるんですYO.
pre-Portlandにコンセプト関係の論文1つもないんだけど
pre-Kona で新しいのが提案されてる >concept そのままC++Nowのキーノート・スピーチで解説されてた。
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
右辺値参照、いくら話を聞いても使いドコロが分からない。 でかいコンテナの単なるコピーとかしないし・・・ 英語でもいいから、何かよいリファレンスを教えてください。
使いどころっつったら std::vector<std::unique_ptr<T>> だろ常考
使い所を考えるような物じゃなくて 不必要なコピーを出来るだけ無くしたるわってもんだからな
ムーブのメリットは様々な処理をノースローにできる事
右辺値参照はそれだけの話じゃないよ 今まで非共有スマポをコンテナに入れられなかったのは コピーが不必要ではなく害悪だったから 害悪なコピーを回避するためにも右辺値参照は重要
>>31 って
>>26 のことだよね?
これは分かりやすいけど使わんのだよ。
たとえば
container<T> func() {
container<T> res;
...
return res;
}
みたいな関数をよく書くのですが、
最後の行を
return std::move(res);
にすれば使ってることになる?
書かなくてもそうなる
>>33 なるほど。
でもそれ以外のタイミングでコピーすることはないんだよなぁ。
自分のコーディングスタイルの問題なのかな?
・・・ちょっとスラドの記事よみ直してみます。
以前読んだけどありがたみがわからんかったので。
ぱっと眺めてなんとなく思ったのは、人様のライブラリを作ったことがないからかも。 すべて自分で書くぶんには、でかいオブジェクトのコピーを避けるように意識してるから、 operator=とか使わない習慣ができちゃってるのかも。
>>34 誰もコンテナのコピーの話なんてしてないぞ
要素のコピーの話しかしてない
従来仕様では push_back すら不可能
引数を使って新しい要素をコピーコンストラクトするから
非共有スマポは使えない
これがムーブできるようになったので大丈夫になった
メモリの再確保なんかもそうだな
>>32 container<T>が特殊なリソースを保持するハンドラでコピーはできんけど
func みたいな生成関数を用意したい、てときにマジ便利
しかもそんな特殊なハンドラを標準コンテナにいれても良いンだぜ
38 :
デフォルトの名無しさん :2012/10/13(土) 09:07:35.49
純粋仮想関数の書き方ってC++11でも virtual void func() const = 0; なんですか? =0のかわりに=hoge みたいなのが新しくできてたりしません?
#define hoge 0
40 :
デフォルトの名無しさん :2012/10/13(土) 09:43:18.84
= 0 があったら virtual は省略可にならないかな
#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(...) が呼ばれまくってるのですが、これはハッシュ値の衝突と関係ありますか?
いいえ
質問者です。
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;
}
ここって、unordered_mapの実装について質問するところなのか
まあ確かに相談室のほうに投下するべきだったけど。 上の件は、やはりハッシュ値の衝突が原因でした。 パフォーマンスが2倍変わったよ。
boostみたいにshared_ptrのマルチスレッド対応をOFFにしたいんだけどどうすればできますか?
無い
まじすか… C++の「使わないときにコストかけるな」っていう理念はどこにいったんですか?
atomic_is_lock_free
実装の問題を規格の思想に言われてもな
まあ細かいこといったらC++からしたら「そんな義理は無い」ってことで終わりなんだろうけどさぁ でもその理念を見失ったらC++のアイデンティティを失ったも同義だしほかの言語に全部持ってかれちゃうよ?
どうぞどうぞご勝手に
作るのに1時間もかからんしスレッドアンセーフっていうか無駄な機能最大限省いたSPつくりゃいいよね stdのはライブラリのインターフェースに使ったりとにかく可搬性ある汎用的なコード書きたい場合だけでいい
というかboost::shared_ptrでダメな理由がないんだが std::shared_ptrはboostの劣化バージョンだから乗り換える理由が今のところない
どのあたりが違うの
constexpr boost::shared_ptr<int> p(nullptr); static_assert(noexcept(p.reset()), "boost::shared_ptrでは今のところ無理");
劣化バージョンというあたりを詳しく聞きたい
boost::scoped_ptrはstd::unique_ptrに置き換えても大丈夫かな
劣ってる部分有るか?
業務連絡:gcc-4.8 に inheriting constructors が実装された模様
後でコード追いにくくなる継承より tuple返すメソッドでゴッソリ代入出来る構文を用意し欲しかった
>>58 マルチスレッドをオフにできない
すでにブーストで書かれている過去の資産との親和性が低い
お薬出しておきますね
反論は論理的に 悪口だけのレスは無価値です
>>63 > すでにブーストで書かれている過去の資産との親和性が低い
「ブーストで書かれている」が頭悪そう
このスレかどうか忘れたけど boost::shared_ptrとの相互運用の方法が書かれてたから 親和性はあるんじゃないかな
shared_ptr使ってる時点でコストを気にするもんじゃないと思うが
>>70 だからただでさえやばいコストがさらに膨れ上がるんじゃ使い物にならない
そりゃ相互運用にはコストがかかるもんさ。でも親和性とそれは全く別問題だよね。 少なくとも親和性は低くない、というかこれで相互乗り入れできるんだから親和性は結構高い
でも結局両方使えるならノーコストのboost::shared_ptrが有利だろ? 結局のところstdのほうが無駄が多いことは同じ
boost信者はこれだから困る。 実行時コストなんかどうでもいいんだよ。 標準ライブラリかどうかっていうのは致命的。 機能的に同じことをするなら標準の方法で 実装した方が後でメンテする人に迷惑がかからない。 今から入社してくる後輩に「おじいちゃんブーストって何?」 なんて聞かれたくないだろ。
>>74 どうでもいいは言い過ぎ
…だが、そこ以外には激しく同意
会社では保守性一番
boost使ったら保守性さがるとか驚きだなどんだけ低レベルのPGが集まってるんだ コミュニティに提言したらどうだ?お前んとこのライブラリは糞だってな
std::shared_ptrで作ったライブラリはC++03以前では使えない しかしboost::shared_ptrで作ったライブラリは古いコンパイラでも動く。この差は非常に大きい 仕様策定からまだ間もないし実装が追いついて無いからまだ古いコンパイラ使ってるところのが多いしな だから可搬性ではstdよりはるかにboostのほうが高いしコンパイラのバージョンを気にしなくて良い分だけ「保守性も高い」 今から入社してくる後輩に「先輩このコードぼくのコンパイラだとコンパイルできないんですけどたすけてください」なんて聞かれたくないわなめんどくせぇし stdのが扱いやすいとか言ってる雑魚はまだ現実が見えてないよ stdが今のboostのような便利屋的な立場になるのはおそらく11の次の規格への乗り換えが始まるころだろうな このころになればコンパイラの実装もほぼコンプリートしているからstdに乗り換える理由がようやっと出てくる それまではどこの会社でもこれならboostのほうがええわという結論が出るだろう というか標準のバカどもが気を利かせてboostとの互換性を持たせるように仕様を決めればイイハナシなんだがな boostは次期標準を視野に入れたほとんど公式のライブラリなんだから標準はboostに敬意を払い互換性を持たせるべき
お薬増やしておきますね
ほう。論理的反論は不可能なようだなwww
boostは準標準と見ていいよ stdの仕様決めるC++標準化委員会の人達がboostコミュニティの中心なんだし
どこまで行っても準標準は標準にはなれないけどね 委員会メンバーもそれが分かっててわざわざ規格にブチ込んだわけだし
C++11のスレで、C++03以前の古いコンパイラがどうとか言ってるのは、まあ論外としても まだドキュメントが少なくて利用実績のあまりない現状では、boost::shared_ptrを使うのは普通にアリだと思うよ でも将来は「std::shared_ptrがあるのにわざわざboost::shared_ptrを使う理由が分からない」とか言われるんだろうな 結局ドキュメント類が多いほうが世の中に浸透するんだし、その点でISO標準に勝つのはどうしても難しい (まあ、標準Pascal無視したDelphiとか、標準Basic無視したVBとか、例外はいくらでもあるが)
まあ混在させるよりはどっちかで統一させた方がいいと思う
>>83 となるとすでに使われてるboostなんだよなぁ
完全新規案件ならstd::shared_ptrで ただし、C++11が普及してからな
してないな 少なくともVSが対応してからだな
>>87 だとすると、「完全新規案件なら」というくだりは、まったく無意味な話か
完全新規案件で、かつ、C++11が普及していたら、という条件文だろ どこが無意味なんだ
>>89 現時点では「C++11が普及していたら」が偽なので、少なくとも現時点では他に何が書かれていても無駄になる。
91 :
デフォルトの名無しさん :2012/10/17(水) 01:05:21.91
>>85 何をもって普及したとみなせるのか書いてないから
他人からすれば何も言ってないに等しいな
当人の脳内では自明なんだろうけど
>>90 >現時点では「C++11が普及していたら」が偽
Linux界隈ではVC気にしなくていいから、局所的な見方ができるなら偽と言い切れるものではないな
実際にはC++11でかつLinux案件とかを想定してるんじゃね
もちろん、何を以て普及したと見做すのかは
>>89 に聞かないと分からんけどな
(そしてその答えによっては
>>89 の文章全体が無意味になる)
してからな、って言ってるように、 今はまだ厳しいというイメージで言った
イメージとかそういうのはどうでもいい
95 :
デフォルトの名無しさん :2012/10/17(水) 02:06:51.96
脳内自明なイメージを 表現することなく 十分に書けたつもりに
Macで使えれば十分だよ 今後Mac以外は廃れるから考慮しなくてよい
おう
Macはもうない
今C++11やるならMacかLinux 普通はMacを使う
Mac以外のマシンは滅ぼせ!
Xcodeで使えるのん?
MacPortsが更新遅すぎて(最新から1年遅れとかザラ)使う気にならない。 更新されてもGCCとかソースからコンパイルしよるから、その間なにすればいいの状態w
Fortran77が死なない理由は優秀なライブラリだよね・・・ C++03でそんな事情はないから多分そのうち死んでくれると思う。 それよりCが死んでくれないことが大問題だよ。
104 :
デフォルトの名無しさん :2012/10/18(木) 08:03:03.84
連投スマソ。 C++11で導入された標準ライブラリの速度が出ないんだけど、 そのうち改善されていく見込みはあるんだろうか? 現時点のGCCは成熟度何%くらいだと思ってたらいいか分かる人いる?
Cが死ぬ前にC++が死ぬよ
まぁそんな気がする。 しかしここ数年、言語界のアイディアも枯渇しててC++11でしばらくは行けそうな感じだよな。 すくなくとも逐次計算にかぎれば。 並列計算に特化した言語モデル(でまともなの)が出てくれば死ぬかも。
>>104 11は速度をあきらめて扱いの楽さを優先したから速度でないのは当たり前だよ
今はどうしても速さがほしいならいままでどおりC/C++03を
楽さを求めるならほかの言語をって感じ
110 :
デフォルトの名無しさん :2012/10/18(木) 15:52:08.60
112 :
デフォルトの名無しさん :2012/10/18(木) 16:00:31.15
C++11にしたら速度が出ないという妄想の話?
STLは右辺値参照を使って大幅に書き直されているから速度が上がってるだろ スピードが出ないのはiostreamとかfstreamの話だろ? あれほどstd::ios::sync_with_stdio(false); を実行しとけと言ってるのに それかcstdioだけを使うか
ワロタ もともと最適化あるから右辺値参照ぐらいじゃ大して変わらんよ それよりshared_ptrやスレッドがバカに乱用されてパフォーマンス悪くバグが増えることが問題
結局参照もポインタと同じ道を辿ったな わかりにくく使いづらく扱いを誤れば危険だしパフォーマンスも落とすクソ機能 その分色んなことが出来るからいいんだいという反論があるだろが、 参照はポインタほどの融通も効かないから中途半端
STLで右辺値参照使ってると言っても ムーブが定義されてなきゃ今まで通りなんでしょ? 遅くなるってどういう事だよ
一応、(リンク時にdead code eliminationしなきゃ) 関数の数が増える=実行ファイルサイズが増える=コードがキャッシュに乗る率が減る=遅くなる かもしれない
dead code elimination も何も クラステンプレートは使わないメンバ関数は 実体化しないという仕様だから
ラムダってテンプレート引数使えないんのか struct Func { template <typename T> void operator () (T const & obj) { } }; みたいに、ラムダで template <typename T> [](T && obj) { func(forward<T>(obj)); } 書ければいいのにね つかどうせならC#みたいに省略できればよかったのに
関数内どんだけ肥大化させる気?
関数内でテンプレートってそもそも必要?
引数の型書くのが面倒なんよ そう思わないか? ラムダがあればファンクタ書くのは楽になるが中途半端だ どうせならとことん楽したいやん
template <typename T> と書く手間で typedef decltype(a) T; が書ける
C++1yで多相ラムダが使えるようになるまでの我慢我慢
128 :
デフォルトの名無しさん :2012/10/20(土) 10:24:25.79
>>127 2年くらい前にこのスレで[](auto&){...}使えるといいねって話をしたら
バカにされてあえなく撤退したわw
>128 型が記述位置で一意にならないんじゃね?テンプレートなきゃムリだろ。
別にそれでいいじゃん
>>129 2年前にまったく同じ事を言われた。
コンパイラ作ってる人からすればそうだろうけど、利用者からすればまったく自然な発想。
テンプレートでいいから何とかしてくれ。
sort(v.begin(),v.end(),[](const super_complicated_template_container_type::super_long_named_value_type& x){return x+1;});
とか、アホくさくて耐えられないw
適当に書いたけどsort用のラムダじゃなかったな。 比較関数になるとさらに醜いことになる。
decltype((x)) const & まあoperator()がテンプレートなファンクタはもとからできるので実装上の問題はなく構文をどうするかだろう 一般の関数にまで拡張して void f(auto x) を template<class T> void f(T x) のシンタックスシュガーにするかとかにまで広がるだろうし
ん、xじゃないな
>>135 いいね!
搭載までにどれくらいかかるのか分かりませんが期待してます。
というか一番最初のラムダのペーパーはすげえ短く書けてwktkだったんだがな... まだ[]が<>だったころ だまされたー!
C#と同じ書式にしてしまうのはダメなんかなぁ …ユーザーオブジェクトの扱いが違うからダメか… sort(v.begin(), v.end(), x => x+1);
今C++11何か使ったら理解できないやつが続出して全てが自分に回ってきそうで、取り敢えずようす見ることにしてるわ。
cpp3よりわかりやすいと思うけど? 一回教えれば今より面倒も減ると思う
他にもっといいラムダ式の書式があったのかもしれないが、C++11標準化委員会が 新しいアイデアを待ったけど誰も出してこないのでこういう変な格好に落ち着いたらしい まあタイプ量が少なくて直感的だからいいんじゃね
仮想プロパティはいつになったら使えるようになるねん
143 :
デフォルトの名無しさん :2012/10/23(火) 22:16:53.45
>>139 会社で使う人はそういう悩みもあるのか・・・
11を03のソースに変換するツールとかあれば自分だけ使えてウハウハになれるでしょうか?
マ板行けよ。
C++11難しくないだろ C++03の方がよほど面倒だぞ
C++03より簡単に書ける、のは確かだけれど、 C++11はC++03互換の形式でも書けるようになってるので、結果的に複雑。 難しくない、というのは言い過ぎ
11で切り捨てられる機能って何かある? たとえば副作用のあるラムダは外部に変数定義しないといけないから、 カプセル化を破ってしまう。カプセル化するためには関数オブジェクトが必要。 完全にdeprecateされた言語機能ってそれほどないのでは? アルゴリズム、コンテナ、どちらも増えただけだし・・・。
完全に削除されたexportがあるだろ
折角 export を実装した Comeau C++ が可哀想です
export実装する前にtemplateのネストを実装すればよかったw > Comeau
151 :
デフォルトの名無しさん :2012/11/02(金) 20:39:03.23
やっぱり、これからは並列処理が簡単にできる言語の時代かも
提案にいくつか並列化関係のあるよな TR2に入ったらうれしい
規格の発行から1年以上経ってるんだけど 本の虫の本はまだなの?
さあ C++の仕様は難解かつ膨大で、あれを隅々まで理解して 解説書出すのはかなり難儀な仕事だと思う
禿は出さないのか
すっぽすっぽ先生の解説を翻訳すりゃいいんじゃねーかと思う。
157 :
デフォルトの名無しさん :2012/11/04(日) 20:49:42.94
本の虫の本を買ったら負けだと思っている
すっぽすっぽ大先生は要点は押さえて概説は書けるだろうけど、 規格の隅々に微に入り細に入りしたような詳説は書けないし、また書く時間もないだろうな。
Cの時点でさえCリファレンスマニュアルがないと 細部をあらかた理解するのは難しいのに
世の中のプログラマーの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 にしろって意味だよ
>>163 まぢっすか。オーバーロードしたいときとかどうするんだ。
値渡しでmoveすればという意見もある。 void f(A a, B b) { std::move(a); }
166 :
デフォルトの名無しさん :2012/11/04(日) 22:09:39.46
>>164 そもそもテンプレートがオーバーロードできるし
is_rvalue_referenceまであるやろ
>>166 あんまり意味ない例だけど、
f( vector<int>& );
f( vector<int>&& );
f( deque<int>& );
f( deque<int>&& );
こういうオーバーロードしたいときに、
template<class T> f( T&& );
で同じことをするのは、可能ではあっても面倒だと思うんだけど。
具体的にどういうシーンで162みたいなコードが必要になるの?
169 :
デフォルトの名無しさん :2012/11/04(日) 23:00:55.51
>>167 そのケースで特殊化もアホくせえけど
左辺値参照は黒歴史でいいし
テンプレートテンプレート引数もクールだぜ
>>168 例えば container.push_pair( x, y ); 的な。
>>168 operator+ なんかで頻出。
たとえば A + B はconst参照で済ましたいけど、
A + B + C だと一時オブジェクトができるのでmoveしたい。
左辺値の場合には目を瞑って
>>165 みたいに値渡しとmoveするのが手軽な解決法だと思う
>>172 その程度ならテンプレートでいいじゃん
>>162 みたいなのが要求されてて更に翻訳単位わけないとだめな程度の規模の関数ってなに?
スレ違いだろ、初心者スレ行け。
そろそろ post-Portland mailing の公表の時期ですな。
template <class ...Args> void f(Args&& ...args) { [ /*どうキャプチャしたらいいの?*/ ] { std::printf(args...); }(); } int main(){ f("%s\n", "Hello, world!"); }
>>177 [args...]
ただしGCC4.7ではエラーになって通らない(他のコンパイラ・バーションでは知らない)
可能ならとりあえず引数で代替
[](Args ... args) { std::printf(args ...); }(args ...);
> [args...] そうだよねえ、そんな気がしたんだけど gcc は trunk でもだめだった このラムダを普通のクラステンプレートを使って書き換えようとしたら、 可変個メンバーみたいなのを持たせないといけないから (不可能) そもそも禁止されてるのかもしれないとも思った
N3337だと5.1.2の23に例が載ってるな
>>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!");
}
ほんとだ載ってた コンパイラが悪いのね
悪いっていうか追い付いてない感じ。 もう C++ の拡張はそろそろ限界だろ。
2進リテラル・・・
胸熱
いや、この2進リテラル全然駄目だろ D言語みたいにセパレータを入れられるようにしないと 訳分からなくなるぞ
桁区切りの提案はN3342がある
2進リテラルなんかいる訳ねえだろwwww却下wwwww(2008頃) ↓ せっかくユーザー定義リテラルがあるから2進リテラルライブラリ作ろうぜ(N3402) ↓ こんな小汚いライブラリが標準になるくらいならコア言語でサポートしよう(Portland) なにこれ
C++0xスレ名物だった0b戦争に終止符が打たれるのか
191 :
デフォルトの名無しさん :2012/11/06(火) 18:55:33.35
区切りなしで 48bit とか拷問だろ
concept、インディアナvsテキサスでもっと盛り上がるかと思ったが、 以外にあっさりと収斂しそうな気配だな。テキサス寄りになりそうな気配だが、 基礎的な研究面でのインディアナ大学の貢献が素晴らしすぎる。
>>189 昔は2進リテラル必要はなかったんだよ
まだ8進や16進で十分理解できる頃のC畑のやつらばっかりだったからな
時代が変わったってことだろ
Verilog・VHDLみたいな超低水準を扱う言語だと 2進リテラルは普通にあるから、 ビットを扱うにあたっての必然性は強いと思うけどなあ 処理系の実装が難しいわけでもなさそうだし、何が問題なの? もしくはなぜ歴史的に無かったのかが気になる
>>188 ああ、2進数とは別に案があるのね
>>194 パッと見01がずらっと並んでたら見辛いからとかなのかね
C++標準委員の皆さんはなんでXMLパーサーなどなど実用殿高い有用なライブラリを標準にしないでお遊びみたいな部分ばかり強化してドヤ顔さらしてるんですか?恥ずかしくないんですか?
>>194 昔は8進があればいいという人が主流だったので。
8進が好まれた理由は省スペース、少入力のはず。
昔はパンチカードでコーディングしてたから。
俺も16進あれば問題ない。2進があってもいいが。
>>196 応用は範疇外です。
boostのスレでも暴れてたやつだから触るなよ
2進はあっても使わないな。16進で十分。 あとXMLパーサにはW3C DOMっつー標準仕様があるだろうに。
マイコン用のC++コンパイラに二進数リテラルが実装されていてよく使った覚えがあるけど逆にそういうハードよりのコードじゃないとほぼ出番無いかもね ところで自分はstd::signatureにとても期待しているのだけれどもC++1yでリフレクションのサポートは一体どれくらい進むのだろうか
Serialization Parallel hierarchies Overloading reflection and more perfect forwarding Delegates Getter/Setter generation enum information Capturing default arguments と応用も広いし、何がしか入るんじゃないかな。
>196 そういうのはQtで出来るから標準には要らない
>>202 サードパーティにあるからいらないと言ったら全部いらないだろ
標準でなんでもかんでも詰め込もうとすると Java みたいなことになっちゃうからだめよ
Java便利だよ
>>165 ,
>>173 なるほど。 C++11 なら値渡しもアリなのか。 move が一回増えるのをどう見るかだなー。
>>194 HDLは4値(以上)だからビットで書かざるを得ないけど、
2値だったら無きゃ無いで済むよ。
JavaやPythonみたいに最初から全部入りがいい!って人もいるだろうけどね
何をするにもライブラリ探してこないといけないとか面倒くさいことこの上ない
共通規格を決めてるのに、一過性のファイルフォーマットに過ぎないものを含めるはずがない
一過性でもいいから含めてくれ そんなだからC++は・・・
>>211 お前の思いは分かった。
だが、捨て置く。
捨て置かれるのはC++の方であった
214 :
デフォルトの名無しさん :2012/11/07(水) 22:13:30.27
全部入りってアンチパターンじゃねえかよ
215 :
デフォルトの名無しさん :2012/11/07(水) 22:17:25.03
yutori
216 :
194 :2012/11/07(水) 22:19:47.18
>>195 >>197 >>207 なるほど感謝。バイナリアンの人は8/16進でも読めるから、
わざわざ冗長な2進表記を用意する必要性がないって感じか
全体として消極的反対が目立つのかなあ
最小セットと便利ライブラリに分ければよい
無理に標準化せずに面倒そうなやつは全部 Boost に集約しとけばいいよ。
日本語のちゃんとした解説書、 いつになったら出るの?
XMLはもうboostので十分だろ。
>>219 いつかは出ると思ってるのか。
出ないという展開に100ペリカ
流行()のオープンプロジェクトで翻訳でもすりゃいいんじゃね。 現場で使えるようになるまでは、コンパイラ製作してるやつもあんまいないし需要も供給もそりゃないだろうよ。
Common Lispの分厚い解説書がCLtL2で止まってるのを彷彿とさせる……
>>216 2進に特化したリテラル表現導入なんて本来ANSI Cの領分で、
C++だけでやるならC++的に意味のある形でないと。
翻訳しようにもライセンス的に白な原本あるの?
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 ね
適当でもいいから battery included がいい、って人がなんで C++1y のスレッドにいるんだろう…。 まあでも、 boost みたいにガチガチの設計じゃなくて、もう少し肩の力を抜いたゆるふわライブラリが あってもいいかなーと思うこともある。 Qt とか、 STL, boost に比べるとゆるふわしていて、 モサいなあと思いつつもけっこう便利だったりする。 C++ の面倒さって、ライブラリの設計が一般化とか例外安全とかを頑張りすぎてるのが一つの原因だと 思うのだよな。
>>228 それぞれが背丈に見合ったライブラリを使えばいい。
次期仕様を話すスレで「肩の力を抜いたゆるふわライブラリ」の話なんか出るわけない。
>>229 JISは見れなくなって久しいな
IE8/9、Chromeいずれでも見れない
>>224 www.open-std.org/jtc1/sc22/wg14/の方でも、
整定数の2進表現は議論されてないっぽい。
C++11 で非推奨になった機能一覧みたいなのってある?
234 :
デフォルトの名無しさん :2012/11/08(木) 19:41:11.21
>>233 規格票の巻末にある Annex D がもろにそれ
>>234 ありがと。
deprecated になっている言語仕様って、こんなに少ないんだ。
ライブラリでかくないし、慎重に規格を更新してるのに、 多かったらむしろやばいだろ。
237 :
デフォルトの名無しさん :2012/11/08(木) 23:09:09.54
C++11 の専門書って出てますか?
C++11も解説している洋書なら
EffectiveなメイヤーさんがPDFを売ってるよ。
確か組み込み向けも出してなかったっけ
2進数リテラルなんかまともなプログラマには必要ないし誰も欲しがってない ↓ でもユーザー定義リテラルで独自実装が蔓延し標準ライブラリの提案まで出てきてしまった ↓ 状況が悪化しないように仕方なく2進数リテラルをサポートする事に あれ?全部ユーザー定義リテラルさんのせいじゃね
2進数リテラル採用する前にリテラルの区切りを標準化しる
前じゃないといけないのか? n3472は同時にやるぜ?
マジかよn3472さんマジかっけーな
入れてねえよ。それは他でやってくれって書いてるw
64bitだと16進数でも桁数大杉でワケワカラン
64bitって16桁だろ? 0000,0000,0000,0000〜FFFF,FFFF,FFFF,FFFF セパレータさえあれば、そんなに多くは感じないような
セパレータがないからワケワカランっつってんだ
文字列で書いてパーサに渡せばOK unsigned int n = toInt("0000,0000,...,0000");
Rubyだとアンダースコアを使うな 1111_2222_3333_4444 字句解析器にちょっと手を入れれば実装できそうだが 何かと衝突しそうな気がしないでもない C++は複雑すぎて、何に手を入れると何が起きるのか想像がつかない
文字列をコンパイル時に変換したらあかんのか
invalid な文字列を渡されたとき、エラーが出せなくない?
int a = 0; のときの 0 は 8 進リテラル これ豆な
それは 10 進や 16 進リテラルとして扱われるのとどう違うんですか
>>250 そういえばアンダースコアのみの識別子ってlexerに許されてたっけ?
111 _ 222 _ 333 _ 4444 と切られて、_がなんかにdefineされてたら、とかちんぷんかんぷんに
許されてるよ
257 :
デフォルトの名無しさん :2012/11/11(日) 13:49:01.09
ioccc の常套手段
ねえねえ int main() { [__func__]{std::cout<<__func__;}(); } これどうなるべきなの?
コンパイルエラーになるべき
なんで?
__func__は変数じゃないんだからキャプチャできない
262 :
デフォルトの名無しさん :2012/11/12(月) 21:25:35.40
いや __func__ は関数に局所的な変数で、マクロではない
>>258 実装定義のoperator()を意味する名前が表示されるべき
いや、__func__ は static const char* の変数だよ。 だからキャプチャされるべきだよ。(gcc はしてくれないけど) ただし、ラムダ内で暗黙に定義される __func__ と被るから、 ラムダのやつが優先されてしまうけど。
265 :
デフォルトの名無しさん :2012/11/12(月) 21:49:19.40
ポインタじゃなく配列な
266 :
264 :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; }();
emplace_back()はこんな場合に使うといいのでしょうか
あ、コード貼り忘れました 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; } }
そういうときに使うのは間違ってはいないんだが その例だとvectorの再確保が起きるたびにBigArrayのコピーが生じるんでやはり効率は悪い
deque
なんでthrowって非推奨になったの? どんな例外が投げられるか分かるようにできたほうが、いいと思うんだけれど
それ以外の例外を投げたら即死するから
Javaのthrow()は、それ以外の例外を投げようとするとコンパイル時にエラーが出る (一部の一般的な例外はスルーされるけど) C++では実行時にエラーが出るだけで、コンパイル時にチェックしてくれるわけではない だからあまり書く意味が無い
さらに中途半端に書いてあると他は飛んでこないと勘違いする害がある。
>>274 みたいなことは不可能じゃないけど無理ゲーってことですね分かります
Javaとは違うのだよJavaとは
277 :
デフォルトの名無しさん :2012/11/19(月) 13:44:50.56
例外、1y でごっそり刷新になって欲しい ゼロオーバーヘッドじゃない C++ なんて笑い事じゃない
とりあえず具体的な改善案がなければ据え置きでしょうな
>>277 例外が「ゼロオーバーヘッド」じゃないというのは、どんなオーバーヘッドのことを指して言ってるの?
そのオーバーヘッドはほんとうに規格が強制してしまっているものなの?
何が飛んでくるかなんてコンパイル時にはわからんし
例外を使わない関数でも ロールバック用のコードが何命令か入るとか?
templateの引数のクラスが実行時に飛ばす例外クラスなんて templateクラスのインターフェイスに指定できんわな
>>280 結局制限しないか、例外投げんなよ!投げたら氏ね!しか要らないんだな
286 :
デフォルトの名無しさん :2012/11/19(月) 23:53:57.28
>>281 vector を at 抜きで operator [] だけで使うとがっかりする量のコードがついてくるだろ
throw() と throw(...) のセマンティクスがゼロオーバーヘッドの理想と真逆なんだよ
デフォを throw() にしなかった禿にジャーマンスープレックスかましたい
俺的には longjmp の第2引数が nested_exception で、そこから好きに dynamic_cast しろでいいと思う
だから反省してnoexceptさんになったんだろ
時代錯誤すぎてワロタ
デフォをthrow()にしたら 例外投げただけで死にまくりじゃん 使い物にならないよ
例外は例外なんだから例外時にだけ投げればよし throw(...)を書くのもめんどいと感じてしまうとこは例外を投げるべき場所じゃない
291 :
デフォルトの名無しさん :2012/11/20(火) 01:45:02.26
>>289 安全施設 throw() の管理者として
危険物乙4だのBSL4だのスケジュール1だのを
適切に処理するには、それなりの論理がちゃんとある
throw(...) を throw() に握りつぶして外聞上、throw() を通すならいい
だからといって throw() の純潔を通している処女におぞましいプレーはさせちゃいかん
その家系に産まれたばかりに理不尽なことの永久とも思える繰り返し
デフォを throw() にしなかった禿は茹ですぎ逆バンジーの刑だ
例外は後から付け足したわけだから仕方ないだろう。 デフォルトが今のようになったのも互換性の問題からであると いろんなところでBS自身が書いてるし。せめてD&Eくらいは読まないと。
293 :
デフォルトの名無しさん :2012/11/20(火) 02:12:51.97
DEは読んでいて、そのうえで意義を持っている 禿の思想も語り口も好きなので著書はことごとく読んでいて耳の質はメリット5のはずだが 例外だけはどうしてもおかしいと個人的には思うんだが… これは個人的なのか、禿への反駁は教義で禁じられているのか
> vector を at 抜きで operator [] だけで使うとがっかりする量のコードがついてくるだろ > throw() と throw(...) のセマンティクスがゼロオーバーヘッドの理想と真逆なんだよ 意味不明なんだけどだれか説明して
同じく。 >286 さん説明よろしく。
↓ここらへんへの反論としてわかりやすいやつをたのむ。
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++ の優れた実装は、例外が投げられるまでにその例外を扱うひとつの
> 命令サイクルを費やすことはしないで、 例外は関数呼び出しの同じような
> スピードで捕捉可能である。 それだけで、例外を使ったプログラムに、
> エラーの可能性を無視したプログラムと同等のパフォーマンスを提供している。
> 例外を使うと実際は、結果的に別の理由で``伝統的な''エラー捕捉の方法よりも
> 早くなる。まず、 ...
掴んでる格段の資源解放と 継続るすための巻き戻し処理を例外に全部おっかぶせてるのが なんかグチャグチャしてて嫌なんだよね
298 :
デフォルトの名無しさん :2012/11/20(火) 06:47:45.29
>297 君にはGCのある言語がお似合いです
>>297 資源解放はデストラクタの仕事だろ。例外関係なくね?
>>297 (正常時の)実行速度のためなら他の全てを犠牲にしてもかまわないというCの本性の継承者です
いやそれは違う。例外起きても必要なことしか行われない。デストラクタに不必要なこと書いてるなんてことは通常ない。
本の虫の人は不自由なソフトは毛嫌いするのに なんで邪悪なTwitterは使うの?
それで、君はどうしたいんだい?
代わりにApp.net使えよ! と言いたい
頭が不自由なひとは twitterを不自由だと思わないみたい
ヲチスレでやれ
本の虫はアカごっこしてる暇があったら早く本書いてくれ
template<class Container> void foo( Container&& c ) { ... = forward??( c[i] ); } コンテナが右辺値で破壊していいときだけ、要素をムーブする方法が知りたい。 !is_lvalue_reference<> で適当にメタプログラミングすればいいのは分かるのだけど、 何か推奨される方法ってある?
std::forwardでは不足?
>>309 >>310 コンテナ自身ではなくて、コンテナの「要素」を foward したいんだけど、 std::forward<> で可能なんだっけ?
ならmove_iterator
>>312 alrogithm の方の std::move とか move_iterator って、 std::forward<> 相当じゃなくって std::move<> 相当じゃないの?
forwardとmoveって何が違うの
forwardは右辺値なら右辺値参照、左辺値なら左辺値参照が返ってくる moveは右辺値だろうが左辺値だろうが強制的に右辺値参照が返る
なるほど 分かりやすいわ
forwardって転送するって意味だよ。
>>313 仮引数を参照でなく値(コピー)にしてmove_iterator使えばよかろ
なぜstd::forward_iteratorがなかったし
だってコンテナの中身って左辺値だろ コンテナの要素をどうしたいかなんて自分で決めることだろうに
コンテナ自体が右辺値であればどうだろうか?
なにが"どう"なんだ
普通のイテレータこそが forward_iterator なのだな
>>318 それで問題ない場合もあるとは思うけど、要素を一部しか使わない関数の場合、
rvalue でないコンテナが全部コピーされるのはちょっと。
325 :
デフォルトの名無しさん :2012/12/08(土) 21:30:28.16
objective-CやGoだとPointerへの委譲が 簡単なのにC++03だとメンドイ C++11で少しは楽にならんのか
え 何言ってるん ばかなん? void f(){g->h();}
Overrideしたいmember関数だけ書いて、 残った関数は全てmember変数へ委譲する ようなことができないって話だよ。 C++03はpointerを使わない移譲なら実装継承で済むが、 pointerに対する委譲の場合明示的に移譲する member関数を記述する必要がある。
動的?静的?
どっちであろうと出来んだろ
動的ならvtblいじれば出来る
Cにできないことはない
実装依存のものは出来るとはいわんぞ 実装依存に限らず最適化でも死にそうだし あと仮想関数テーブル弄っても無理だろ おなじメモリブロックにオブジェクトが 固まってる必要があるから
手抜きをしようたってそうはいかんぞ
実装依存とかわけわかんねぇこというなよ。 CPUにできることならだいたいできる。
メモリレイアウトとか、言語規定には無いからな。それに依存したコードには移植性がないということだ。
>>332 そのために実装毎にユニークな定数がdefineされてんだろ
規格にvtbl書いてないからなあ 他のvirtual関数実現する方法なんて実質的にないのにな
vtblだって、多重継承やRTTIもあわせると一通りしか無いってことにはならないよ
はあ? ポインタ側の拡張できるじゃん
>>325 で言ってるGoやObjective-Cのコードも実装依存だろ?
だったらC++で実装依存のコードを書いて何が悪いんだよ
君が必要なら書けばいいが、規格のスレでは規格の話をしよう。
>>342 言語仕様で決まってるから、処理系が存在する
環境でなら必ず動作するよ
>>339 インタプリターで動く場合は連想配列だったりするし、
コンパイル式でも最適化でvtable消えるから
規格化するのは難しいだろ
gcc に inheriting ctor が (外野的には) あっさり実装されて、 ChangeLog に特に注意書きもないけど、 なんか色々問題 (新たな ABI が必要とか) あるんじゃなかったの?
>>342 何故他の言語の事も知らない門外漢が口を挟むのか?
大人の話に背伸びしたガキが口を挟んでも場を乱すだけ
とかいうような話を知らないのか?
pimplイデオム使ってる時に実装クラスへの委譲コードを どうにかして楽に実装できないかと考えたが俺の頭では無理だった
>>344 “標準化されてない”言語仕様だろ?
仕様さえあればいいっていうなら、C++を拡張した独自仕様を書けばいい
そもそもISOの標準と、一企業が開発してる言語を比べるのがおかしい
話題ずれてってんぞ そもそも標準化されてないとダメというなら、話題に出せる言語極端に減るしな
>>349 goは元々Bで知られるケントンプソンが作った言語で
google専属言語ではない。Objective-Cはブランドコックスが
モジュール化の理論を達成するために作った言語で
Apple専属言語ではない。
それぞれGoogleやNeXTが作った処理系とは別の処理系が存在する
>>349 言語仕様と実装依存と標準規格は別物だろ
それすら判らないなら初心者スレで初心者と遊んでろ
普通は言語仕様の範疇で話ができりゃいいんだよ
そういう話ではないだろ。それだと言語仕様がない言語を話題にできなくなる
言語仕様が無い言語は話のしようがなく無いか? どこまでを言語仕様というのにもよるけど リファレンス実装とそのマニュアルが仕様という場合もあるしな 少なくとも最適化や実効環境によって使えなくなる 機能は話にならん
結局Objective-CのようなPointerへの委譲を楽にする 機能がC++11の仕様の範疇で出来るようになるの? って話はどうなったんですかね?
RubySpecができるまでのRubyは仕様がなかったけど、随分話題に出てたろ つーか話逸れすぎ
何でお前らケンカしてんの?
君たち、C++の話をしろ
>>348 めんどうくせぇから実装クラスは変数publicにしてthisの変わりに使ってる。
C++11まとめた書籍とかでないのかね
>>348 スクリプトでパパッと生成すりゃいいじゃん
>>360 スクリプトでパパッと生成すりゃいいじゃん
>>360 スクリプトでパパッと生成すりゃいいじゃん
>>361 それをしちゃうとメタプログラミング的に負けなんだよ
そりゃ俺だってPythonあたりで生成すりゃいいと思ったよ
パーサ作るのにSpiritで頑張るより素直にyacc使った方が早かったんじゃねとか思ったよ
メタプログラミングに勝って人生で負ける
>>362 それをしちゃうとメタプログラミング的に負けなんだよ
そりゃ俺だってPythonあたりで生成すりゃいいと思ったよ
パーサ作るのにSpiritで頑張るより素直にyacc使った方が早かったんじゃねとか思ったよ
言語の外の世界で操作する方がより「メタ」だと思う
メタって単語をやたら使いたがるヤツは頭悪いってよく聞く
メメタァ…
テンプレートを使うだけでコンパイル時間とオブジェクトファイルのサイズが増大するのは現実的な問題なので 解決されない限りは他のエレガントじゃない手法を選択肢に入れるのも止むを得ないということだ
メタボリックテンプレート
Qtとかもコード生成してるしな
コード生成は1回で終わるけど、マクロやテンプレートは毎回だからなぁ。 結果も同じなのに。 プリコンパイルヘッダについては改善の余地があるとおもいますですよ。
374 :
デフォルトの名無しさん :2012/12/18(火) 21:59:44.70
C#でiPhoneアプリ作ってる記事ならだいぶ前にもあったけど なんで今更
発作じゃね?
AppleでClangやってる人の一人が、C++11でconceptやってた人だし…
ネイティブイメージ吐けても、 .netframeworkとスタティックリンクできないし、 gcなしにもできないから、何も意味ないな。
っていうかネイティブコンパイラではないだろ? monoのC#からCocoa呼べるようにしましたってだけだろ? (XやGtk、Qtなどではない)ネイティブGUIの意味でネイティブって書いてあるんだろ?
アセンブラ併用でもいいからCに頼らずに、OSをブートさせるところまで書けるようにならないと、 残念ながらネイティブとはいえない。
まあそこまでいかなくても普通の意味のネイティブは、機械語が吐けてOSのAPIを(余計な動的ディスパッチャ無しで)直接叩けるあたりだろうな 機械語になっても、APIを叩くにはレイヤーが必要な言語とか結構ある
>>380 今やJavaとかHaskellでも(単独で)OSが書けるんだよな
考えてみればすごい時代だ
>>382 単独でといってもそこまでに色々なものを積み重ねているから出来るんだけどな。
ブートストラップ的には複雑になっている。
別に複雑でもいいじゃん。Cに頼らず(アセンブリのみで)ブートできてるんだから
Cが入っていないOSってどれ?
スレチだけどJNodeとか?
普通にOS書こうと思ってる俺には、はた迷惑でしかないがな
MS-DOSとかそれ以前のは全部アセンブリじゃね?
C++11では、クラス内で宣言する自分自身のstaticクラスの初期化がスレッドセーフになり、 Singletonパターンが使い易くなるそうですが、 これって、C++11に対応しているVisualStudio2012でコンパイルするだけで、そのようになるのでしょうか?
使いまわすならポインタなり参照なりで持っとけばいい話だろう
既存のソースについていってるよねどう見ても 盛っとけばいいだろとか言われてもあれじゃねえか
>>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...
コンパイラのスイッチがあるのかもしれないけど
>>389 C++11フルサポートとは言ってないでしょ。
MSは規格出来てすぐにフルサポートしたことない。
昔に比べればずいぶん積極的にサポートしてくるようにはなったと思うけどね
2ちゃんもひと少なくなったな
まだVC2002のC++03のレベルだよ
397 :
389 :2012/12/21(金) 01:25:05.98
>>392 試してくださってありがとうございます!
>>393 なるほど・・・。
期待しないでおきます。
(c++)? c: c++;
未定義動作
三項演算子だから未定義じゃないだろ
左右の項の実行順が未定義
左が確定しないと、右を実行しようが無いから未定義じゃ無いよ。
評価式の (c++) で true だった場合でも false 側があらかじめ実行される可能性は?
お前は if (true) c++; else c; これでelse側が実行されるかもしれないって危惧するのか?
a = (c++) ? c : c++; a = c++ || c++; これらは等価?
問題なのは、 (c++) ? c : c++; の方であって、 (++c) ? c : ++c; ではないということだな。
シーケンスポイント知らんのか。 知らんからやらないというのも正しい態度だけど、他人には強制しないでね。
>>406 ++がどちらであろうが、後ろの処理が先に実行されることはあり得ない。
(c++)? c: c++;って cが最初0なら戻り値1、終了後のcの値は2 cが最初1なら戻り値2、終了後のcの値は2 戻り値よりも他にいい言い方があるかもしんないけどそんだけの話じゃないの?
>cが最初0なら戻り値1、終了後のcの値は2 kwsk
411 :
409 :2013/01/12(土) 13:55:34.11
なんか怖くなってコード書いて確かめてしまった…。 環境はVS2008でcはintでやったんだけど、実は話題についていけないのは俺だけで みなさんC++11特有のお話だったりcはint以外の型だったりするの?
412 :
デフォルトの名無しさん :2013/01/12(土) 14:13:32.53
巧妙なスレ違いあらし
>>411 未定義動作や未規定の動作、実装依存の動作かどうかは実際に動かしても
確認できないよ。
この件は、1項目の直後にシーケンスポイント(副作用完了点)があるので
その手のには該当しない。(=問題ない)
しいて C++11 と絡めるなら規格上 sequence point という用語によっては説明されなくなったってくらいかな。 2 つの処理の間に順序がある場合は sequenced before という句によって表現されていて、sequece point という点の前後全てで 分ける形にはならなくなった(恐らく concurrency 絡みで)。
2ちゃんもひと少なくなったな
416 :
409 :2013/01/12(土) 19:01:36.20
>>413-414 ありがとうございます!すっきりしたのとひとつ賢くなったような気がします!
>>415 禿同、いったい何処に逝ってしまったのか
atomicやスレッドあたりの説明でよく出てきてたな >sequenced before
多相ラムダってstd::functionでは保持不能? なにかそこら辺の拡張はないのかな。
というかなぜ多相ラムダを引数と戻り値の型が固定のstd::functionにいれたいんだ? std::functionと似ているが、戻り値の型以外自由にするクラスは作れるぞ。 というかstd::functionが意図的に制限していると言うべきか。
再帰したいってだけ。
lambda式の再帰はライブラリよりもコア言語側で提供されるべきだろ。 named lambdaが入っていればなぁ。
>>420 そんなだからお前はHaskellから相手にされないんだぞ
compose()はbind()に吸収されたの?
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でちゃんとコンパイル出来るようにするにはどう書けばいいんですか?
bind2ndのパラメータを3つ→2つにする つかエラーメッセージで小数点がカンマになってますとか出てこんのか……
>>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式使ったほうがよかろう
>>424 なんかつながらなかったからやっと見れた
putfは名前変えたほうがいいと思うんだが
こんなプログラム保守したくねー!
どうしてC++って何かしようとするとすぐ黒魔術になっちゃうの?
たとえば?
「黒魔術」という言葉を安易に使いすぎだと思う。 明確な定義がないから個々がどういうイメージで捉えようと勝手ではあるけど、 単に自分が理解できないものを黒魔術と呼んでるだけってことが多々ある。 俺のイメージでは「抽象の壁を壊すもの」っていう感じだな。 例えばテンプレートは代表的な抽象化の道具で、 型に依存しない機能 (ジェネリック) を隠すための壁となるべきものだけど、 何らかの計算をさせるために使ったりするのは黒魔術だと思う。
>>435 何をやっているかは極めて明快だと思うが。
ただし実際に自分で書くならlambdaで書く。
>>436 極めて明快・・・?
ちょととその感覚は矯正した方がいいぞw
>>437 基本、数学関数の取り回しでしかないから、何をやっているかすぐにわかるだけ。
もちろん、よくわからん(C++の意味での)関数でこれをやられると勘も働かない。
まあ何をやってるかは分かるけど このコードに手を加えろと言われたら消して書き直すわ
boostやらのlambdaの方がよっぽど黒魔術的だろう。
boost lambda の実装は黒魔術だが C++11 の lambda は明快だぞ
bindとかの時点で黒魔術に見えるわ。
まあ個人の感想レベルだといろいろあるだろ、そりゃ。
lambdaでbindは要らないし
>>439 その感覚でいいんじゃね?
lambda自体を使う感覚もそんなもんだし
その場で全てが簡潔に完結してるのがlambda のメリット
うん。 多少複雑でも、局所性が維持されるのは非常にありがたい。 lmbda式の存在はデカいと思うよ。
448 :
デフォルトの名無しさん :2013/01/27(日) 13:06:59.81
そのおかげで一つの関数が膨れ上がってるけどいい?
コードが散らばるよりはそちらを選ぶ。
>>448 それはlambdaとあまり関係ないのでは…
ループで書くのとalgorithm+lambdaで書くのとの比較じゃないのか
C++ は黒魔術じゃなくて黒歴史
453 :
デフォルトの名無しさん :2013/01/27(日) 14:29:50.87
for_eachを使うのが楽しいと感じるようになってきた
lambda登場まで for_eachは黒魔術としか思えなかった
C++は超魔術合体
C++は10年の遅れをとっているな C#ではforeachは馬鹿でも使ってた
C++ は 27 年の遅れをとっているな。 Scheme では for-each は初心者でも使ってた。
うせろ雑魚Lisperは
一度くらい lisper 呼ばわりされたい、e-lisp ですら四苦八苦、理解できる見込みがない‥‥
C++11だとrange-based forが使えるから for_eachは要らんな
C#のやっつけforeachだせえよ。
conceptはよ
Ruby の each_with_index に相当するものが欲しい事はよくある
一回自作すればそれで終わりじゃないか
それだけのためにlambda渡す関数を作りたくはないわ
>>463 カウンタ付きのイタレータアダプタ作ればいいだけ。
インデックスと要素は別変数がいい
468 :
デフォルトの名無しさん :2013/01/27(日) 22:48:39.63
インデックスと要素のpairを要素にしたvectorを返すzipを作ればいいだけ
だから別変数がいいっつってんだろ
別変数だろ itr->first itr->second
イテレータ介すのがめんどくさいんだよ
472 :
デフォルトの名無しさん :2013/01/27(日) 23:14:31.91
じゃあC++使うなとしか
IteratorがいやならRange-based algorithmがいいぞ
単独なら range-based for でイテレータなしでいけるだろ
475 :
デフォルトの名無しさん :2013/02/13(水) 23:55:44.18
話題なしか
ねーよ JITコンパイル言語の出来が良すぎてC++はその役目を終えつつあるような気がする
それは本当に速度が要求されるプログラム組んだ事無いだけだろ
happens before だの acquire だの consume だのを日本語で正確に説明してくれる ウェブサイトはある? 英文読んでも込み入りすぎて意味わからん
atomic C++11 でググって調べてみたらどうかな
C#とかキモい。
>>477 そこまで変わらねーよ
スピードが欲しかったらCPUを新しくした方が安い時代
失笑を禁じ得ない
やることなくなると政治に走るのは人間の特性だからな
実際V8のほうが速い
std::vector<int> nums = {1,2,3,4,5}; for(auto &n : nums.subrange(2,3)) { // 3,4,5 が取り出せたら嬉しい。vector をコピーすることなく }
>>481 それは本当に速度が要求されるプログラム組んだ事無いだけだろ
C#だけでエンコーダ作ってみろよ
JITの方が速いなら、llvm使ってC++もJITコンパイルすれば良いのでは?
advice入んないかなー
>>486 それは速度のためというより、メモリの効率とかGCとかの関係じゃね?
JITコンパイル言語はメモリを多量に使うしGCが走るのでリアルタイム関係の
仕事をやらせるには都合が悪い
そういう所にしかC/C++の生き残る道はなくなっている
確かにエンコーダ自体は無理だが 皮はC#でいいよな
ようやくわかってきた synchronization operation っつーのは、 × operation that is synchronized ではなくて ○ operation that is named synchronization なのね 門外漢は英語の意味とるのも難しい・・・
雑談スレ行けよ。
JITとかGCとかゴミ。 IDEが生成したスケルトンプログラムが100M喰うなんて、 いくらメモリが16Gあっても勘弁。
組み込みとか 科学技術計算とか ゲームとか ガワはLLってことも多いけど
どちらかというと拡張命令の組み込みがあるかどうかと、 インラインアセンブラが使えるかどうかが決定的だろう。 本当に速度が必要なところを徹底的に最適化できるかどうかだ。
程度の低いスレ違いの話書き込みやがって。
程度の高い497が居ると聞いて
OSやらLL言語のランタイムがLL言語で 書かれていたら絶望的だろうに。
マイクロカーネルのコア部分だけバイナリで他部分全部LLっていうOSもあるらしいし 案外いけるのかもしれん
502 :
デフォルトの名無しさん :2013/02/14(木) 21:19:54.58
v8便利だよね
ここまでD言語の話題なし
そらDが出たら逆にスレ違いだわ
>>490 皮はC#でいいけど
エンコーダ自体は無理、という順番で言って頂きたい
エンコーダも作れるだろ。1分エンコードするのに数日かかるかもしれんが。
つ[P/Invoke]
ま、せいぜいエンコーダで頑張ってくださいな♪
>>509 昔はCじゃアセンブラに勝てない、って言われてたのに、
コンパイラの最適化コード生成が進化して、むしろアセンブラより
速いってなったんだから、
いつか、C#でエンコーダも、現実的になる日がくるだろ。
いや、ないな。
ある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
>>511 いや、MSはどうも.NETの脆弱性修正と称して実はJITコンパイラを更新し続けて
いるらしいぞ
VSから生成されたコード(逆アセンブル)見てみろよ
変わって来てる
インライン展開なんか当たり前だし
>>511 アセンブラより速いは無いぞ。
原理上アセンブラと同じまではいけるけど。
>>514 人が普通にアセンブリ言語で書くよりはってことだろ。
>>512 template <typename...> struct C;
template <template <typename...> class Template, typename... Types> struct C<Template<Types...> > {
B<Types...> b;
};
とか。
>>513 じゃあC#だけで超高速なエンコーダ作ってみろよ
>>513 インライン展開が当たり前なのは最初からだ。
どれだけアホなんだよ。
JIT言語ごときがC++に速度で太刀打ちできる訳ないじゃん アホ晒すのもいい加減にしとけ
スレ違いですよ。
作れないが、高速じゃないにすりかわってるじゃん。 後付でよいならばいくらでも反論可能であるよ。 作れる作れないだけで語れ。
C#の有用性を説いている人間があまりに無知で話にならない。 絶対に味方にしたくないタイプだ。
なんかもっと面白い話しようぜ。 お前らの好きなN3499/Digit Separatorsはどうよ? digit-separator: [to be determined] だぜ。
>>512 Variadic Templateなクラステンプレートを再帰的に使う。
ということを実装している標準ライブラリがstd::tuple。
一番ましなのはスペースじゃないの 文字列リテラルは並べたらくっつくんだから、数リテラルもそうだということにすればいい
アンダーバーかな。 ユーザー定義リテラルさんには泣いてもらおう。
>>525 それ、16進のとき大丈夫?
0xab cd だと cd がマクロ置換の対象になったりするわけだが。
0xab 0xcd == 0xabcd ってこと?
意見がまとまらなくてお流れになる予感
>>527 そうそう、文字列だって
L"Hello" L"World"
とか書かせてるんだし今さらでしょ
1230123 -> 123 0123 // 10進 + 8進 区切りそれぞれのサフィックスを認識するならこうなるよな 2進リテラルサフィックス 0b も16進中に出現するしあんまりいい予感はしない
ああ間違えたけど大目にみてくれ
D言語みたくアンダーバーで区切れればいいのにネ
アンダースコアはなんか嫌だなあ。
主要なセパレーター案とその文法上の問題はN3499で網羅してるし、 やろうと思えばどの案でも実装可能だから、 話すといっても、どの文字が一番見やすいかぐらいだろ。
それより早くRangeをだなぁ...
Unicode前提でNO-BREAK SPACEで
0xFF 0xFF 0xFF 0xFF は読み辛いな 0xFF_FF_FF_FF でいいわ
16進数ならいいけど、10進数だと 1000 0011 みたいになって、8進数と区別つかない
8進数は0oとかにすりゃいいんじゃね。 8進もういらんだろ?
8進数はパーミッション指定で必須
提示案の中に User-defined Bracket みたいなのある?
x86 オペコードは8進ではじめて意味がわかる
>>541 どういう用途?
初期化子で色々できるようになったけど。
544 :
デフォルトの名無しさん :2013/02/20(水) 20:55:45.54
8進数定数は今更やるには大きすぎる変更だろ それくらい分かって諦めろ
0 って書くと 8進数の 0 なんだよね
それって10進数と16進数の0と違うの?
値としては同じだね 020 とか 0x10 が 16 と同じになるのと同じ意味
字句解析→構文解析→意味解析のフローが8進数用の解析器を通過するってことじゃね?
0xかどうかのチェックもするだろうし、 実質的には8進数とかそういう以前の状態で0と判定されそう
ワロス
規格スレなのになぜ誰も提案資料に触れない
実質的にはって言ったのは 規格がどうであれって意味ね
>>553 公式の提案に対してここで騒ぐだけじゃなんにもならんのがわかってる人はここで議論はしないから
提案が破棄された理由ぐらい知ってる人はいるだろうに
10年前のC++業界なんてよく知らない新参だから触れないでおいた
デリゲートのことか? GCとセットじゃないと危ないからじゃね? shared_ptrとweak_ptrを使って自作すればなんぼでも作れる気がするが
delegateそんなに使いたいならC#いじってろってこった
>>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(・・省略・・) );
提案が良いものというだけでは採用されないって禿がD&Eで言ってた
暗黙の変換なんか黒魔術だろ。 全部手で書け。
Hoge*<shared> ph = new Hoge; みたいに書きたい いっそのこと using * = std::shared_ptr Hoge *ph = new Hoge; とか書けるようにして欲しい
なにその魔術
>>561 採用されないこともあるって話じゃなく、
却下された理由を知りたいんだけど
>>562 暗黙の変換じゃない。基底クラスを実体じゃなく、
ポインターで保持出来るみたいな話だ。
物乞いするだけならtypeundefやunnamespaceが吐血する程欲しいわ #include "ベンダーA.hpp" // typdef bool BOOL #include "ベンダーB.hpp" // typdef int BOOL どっちも死んでほしい
前方宣言でのnamespaceの書き方を変えてほしいな
>>569 D&EにN1363の事なんて書いてなくね?
>>565-566 えーなんで何があかんの
今時は生ポインタなんかよりshared_ptrを扱う事の方が圧倒的に多いんだから
簡便な記法があってもいいだろ自転車置き場はともかく
じゃあC++標準化委員会に入って文句を言うこったな こんなところでボヤいていても糞の役にも立たない
糞気持ち悪いわー C++/CLIみたいに別の記号導入する方がまだマシに見える
生ポインタと同じシンタックスはイタレータでも使うからなあ。
生ポインタじゃないのに生ポインタの記法使うのは気持ち悪い
ブラケットが要らんな *const と同じ表記でいいよ intresuve_ptr と違って shared_ptr の deleter引数や unique_ptr の default_delete<T> の扱いをどうキモく無い様にするかとかあるけど
>>572 あっても良いかもしれないが、あまり意味がないような。
文字数も減らないし、むしろ混乱要素が増えるだろ。
その記法のメリットはどこなの?
>>576 だってC++でポリモーフィズムをしようとしたらポインタを使う事になるもん
リファレンスでもいいけど関数の引数位でしょ?
この当たりの泥臭さが他のOOP言語を使ってる人から見れば奇っ怪に見えるのかも
Example &other = mother.NewFather(); delete &other;
で、Autometed Delegationとやらの不採用理由はどうなったんだ
582 :
デフォルトの名無しさん :2013/02/22(金) 23:33:05.42
>>563 のコードというよりも
>>563 さんのセンスがキモイです。
おぇええええええええええええ
#undefがあるのになんでtypeundefがないんだよぉ
>>579 リファレンスでもいいけどって生ポインタとリファレンスは用途が違うし
何が言いたいのかよくわからない
>>578 ソースコードの最初に using * = shared_ptr; って書いておけば幸せになれる
何でもかんでもshared_ptrになったらむしろ地獄だろ
関数ポインタ―とかスタックに対するポインターが巻き添え食らうからたまらんわ
え、天国だろ? どうしても生ポが使いたかったらN3514のstd::exempt_ptr使えばいいよ
using * = shared_ptr; int main(int argc, char **argv) {
using * = shared_ptr; int main(int argc, std::exempt_ptr<std::exempt_ptr<char>> argv) { (あ、あかんこれ)
typedefつかえよハゲ
そこでtypedef使うくらいならshared_ptrのシンタックスなんていらなくないか shared_ptrをtypedefしろよハゲとしか
全部shared_ptrにして循環参照で死ぬ未来が
>>585 ナマポと混乱するデメリットの方が大きい気がします
むしろただのポインタをクラステンプレートにするのがboostかなにかで出てた気がする ptr<int> みたいな
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(); }); }
見当違いのこといってる自覚がないなら勉強しなおしたほうがいい
std::for_each(std::begin(pa), std::end(pa), [=](Animal* ra) { ra->cry(); }); これコンパイル通らなかったんだよ だから気づいた
>>583 #ifdef に対応する iftypedef も欲しいよね
>>598 見当違いのこといってる自覚がないなら勉強しなおしたほうがいい
this 通してアクセスしてねーだろ。
>>596 ,598
pointer_containerのイテレータの参照外しが何型になると思ってるんだ
*(pa.begin()); // 何型?
>>600 じゃあthis通してアクセスする、コンパイルが通るプログラム書いてくださいな
>>601 boostのマニュアルを見て初めて知った
template<typename T> using SP = std::shared_ptr<T> で->で正しく候補をあげるエディタ(IDE)ってある?
VisualStudio2012 さっき試してみたがTemplate Aliasesに対応してたんだな
>>604 VimやEmacsならclangの補完プラグイン入れれば行けると思うぞ
global::shared_foo = make_shared<foo>(); こんなことしたら初めにglobal::data::fooにあったfooはどうなるんですか?
global::data::fooは一体どっから出てきたんだ
エスパー気味に行くと まずshared_fooが保持していたポインタへの参照カウントが1減り、その結果参照カウントが0になればそのポインタは解放される その後make_sharedから渡されたshared_ptrの保持するポインタとその参照カウントを共有して保持するようになる
using (C++)++ = C#;
ただのstatic_assertもどきになったな これはいい事なのか
元からそんな感じじゃなかったの
overload はできるから、static_assert よりは便利
C++11で投票したのにはaxiomってあったよ。assertとはぜんぜん違う。
axiomなんかただのヒントで何の役にも立たないだろ
最適化に使っていいことになってたよ。
それを役に立たないという
詭弁の一つ、強弁ですねw
axiom-basedはtesting frameworkでも使われていてそれなりに有益だと思うが、 言語レベルで取り込むのは少しC++的でないかもしれない。
registerだのinlineだの、std::allocator<T>::allocateのhint引数だの 「最適化のため」の機能がまともに役立った試しがあるか?
最適化のための機能じゃないけどね…
人間がコンパイラに出すヒントという点でなら同類だな そしてその時点では有効であっても人間側の判断が進歩したコンパイラの解析に劣るようになると害のほうが多くなっていく
axiomが害になるような事例があるとも思えないが。だって、axiomだし。 本来不変な条件が足枷になるならもっといろいろと壊れてるよ。
整備されていないコメントと同じくらいの害はあるだろう
自分でバリバリ書くものでもないような >axiom 適切に利用することを第一に考えておけばいいんじゃないか
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レベルだと思う人がいるくらいで。
なるほど、BLASなんかで自動的に書き換えてくれるなら大いに有用だな、、、
axiom Associativity( T x, T y, T z ) { (x + y) + z <=> x + (y + z); } これが整備されてないドキュメント以下になることは難しいと思われ
axiom絡みだと禿も著者の一人の論文で *p++ <=> { T tmp = *p; ++p; return tmp } を見た時ちょっと笑ってしまった。そこからかい!
そりゃ前置インクリメントと後置インクリメントは まったく無関係にオーバーロードできるからな。
C++ Grandmaster Certification誰かやってる?
.pptokenが./pptokenの間違いであることにすぐ気づかないとcppgcは難しい
興味ない > Grandmaster C++11を一人で実装しろとか無茶なこと言って何の意味があるの
まあ、本気でやってもある程度完成する頃には次期規格が出てるよな。 ……出てる……よな?
新言語を作る人なんて大体一人でやってるんじゃないの?
自分で好き勝手に言語を作るのと 仕様書で1300ページを超えるC++11を実装するのは話が違うから まともに使えるC++11を一人でサクサク実装できるなら天才だと思うわ
雛形もtestsuitsもあるから、一人でさくさく作るというのとは違う。 ただ結構筆力がないと目安の週10時間では無理だろう。
これってCourseraみたく講義の動画はないのか
最適化とか適切なメッセージとか処理速度とか価値に成る部分をサックリ無視すれば コンパイラ実装だけならそれほど無理な作業でもない気がするけど ライブラリ群はムリ絶対ムリ
C++の規格を議論するなら実装くらいはしたことないと駄目だよね
大学時代は言語処理系をかじってたけど、 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 } 関数のアドレス取ろうと思って、何となく書いてみたら内部エラーが起きた・・・
リファレンスインプリメンテーションがバイナリで配られて来るんだな。 テスト以外にも、いろいろと自作と結果を比べるために。 配布バイナリいきなり実行か。CPPGMの主催者を信頼していいのだろうか?
いまどきは仮想環境をカンタンに使えるんだからそんなに心配なら そっちでやれよw
闇の軍団ならこんくらい楽勝でしょ
cppgmってどこがやってるの?
これ修了するとなんかの組織に入れてくれるらしいよ
649 :
デフォルトの名無しさん :2013/03/06(水) 20:10:58.73
世の中はSTLすら使わない会社があるというのに何ですか? ここのスレは。物凄いプロ集団か、オタクの世界ですか?
C/C++を使っているってことが、いまや キチ、超底辺ドカタ、真性オタクのいずれかです
C++でバカッ速いコードを書くのが快感だ・・・。
組み込み関数やインラインアセンブラでSIMDをフル活用する方が快感だよ。
653 :
651 :2013/03/06(水) 21:04:00.71
>>652 それそれ!その感じ!
SIMDはドーパミン出るね!
もうHaswellのAVX2が楽しみで夜も眠れない♪
>>653 AVX2はC++11じゃないと速いコードにならないらしいね
655 :
651 :2013/03/06(水) 21:21:02.62
>>654 そうなんだ!
まぁ、VS2012でガンガンC++11の機能を使う予定だから問題なしだね!
あーもう6月までガマンできないよぉ!!
VSのx64ビルド設定の最適化でSIMD設定できないよね
boost.simd手伝ってやれよ
なにかお困りですか?
VC2012ってすでにAVX2をサポートしているのか?
>>656 x64だとSSE2が標準になるから指定出来るとすればAVXだけかな。
>>652 Assembly書くよりvalarray使い回したほうが楽じゃね?
valarrayがSIMDで最適化されるのってIntelの翻訳器だけだっけ?
まあ、いつまで不自由なtwitter使ってんだよカスがwwww
あの人まだ仕事見つかってないの?
ネットwatch板でやれ
iOSに関してはアレだけど macはtwitterほどの不自由さは感じないな
そりゃ標準化されたPOSIX APIが載ってるもの
Runtime-Compiled C++ってどう?
誰かclang解説本書いてよ
dequeにshrink_to_fitは意味あるの?
実装による
つ達人出版
意味があった
不自由なgoogle reader使ってたのか まあ不自由なtwitter使っているんだから不思議ではないわな
不自由なにちゃんねる
自分は使えるもんは何でも使うよ Mac、Windows、Linux全部使ってるし
N88BASIC「」
679 :
デフォルトの名無しさん :2013/03/14(木) 18:32:00.93
>>677 効率悪そうだな
もう少し考えた方がいい
オープンソースは自由に食べられるうんこみたいなもん
久しぶりにC++書くことになったけど11に移行すべきか迷ってる 新機能は便利そうだけどほとんどboostにあるわけで、ライブラリの互換性とかコンパイラ間の互換性に引っかかるリスクのほうが怖い 速度に関して03より11にするメリットがあるなら迷わず乗り換えるんだけどどうかな?
そんなのあんたが使うコンパイラしだいとしか言えんがな
gccメインだけど最低限VCでもコンパイルできるようにしておきたい しかしVCはconstexprも実装されて無いという・・・
去年決まったばかりの新しい仕様を使うかどうかの基準が、まず速度ってのはないだろw
C++11有効にしてビルドして、ビルド通ったらそのまま移行すればいいだけじゃないの?
不安なところだけJavaで実装すればええやん Write once, write anywhereやで
Write Once, Exploit Everywhereだろw
Write Once, Debug Anywhere...
Write once, runaway
脱google(藁)なんて意識の高いネットユーザーぶってても 検索サービスは使うんでしょ
クローズドなソフトウェアは開発者が開発を止めても エミュレーターを使うなど使い続けられる可能性があるが クローズドなサービスは運営が止めたら一巻の終わり なぜクローズドなソフトウェアを使うのは嫌なのに クローズドなサービスは使うのは平気なのか?
恋文なら直接本人に渡せよ
平気じゃないけど代わりがない
googlemailをメインアカウントにするのは怖いな いつ使えなくなるかわからん
代わりがないなら作ればいいじゃない プログラマーなんだもん
依存できるサービス作るのはソフトウェア作るのとはわけがちがう
まるでソフトウェアなら作れるかのような言いぶりですな
google readerくらいならみんな作ってないか?
RSSアンテナのCGIを置くぐらいは誰でも楽勝だろうが、 ひとつのサーバーで一括してやらないと、F5アタックと変わらんからな
>>699 ソフトウェア作るのとサービス作るのとの違いはそういうところもあるよな
複数ユーザーからの需要をまとめることで取得先に負荷をかけない配慮もあるし
サービス落としてはいけない堅牢性も求められるし
バグや作業ミスで個人情報が漏れることはあってはいけないし
クローズドなサービスは採算ベースに乗らなければ 存在さえ許されずこの世から消えさる悲しき存在 クローズドなソフトウェアは開発元がつぶれてもとりあえず使うことはできる
最近はどこでもデータ吸い上げられるし、狭い意味でクローズドなサービスも珍しいけどな。
703 :
デフォルトの名無しさん :2013/03/16(土) 01:18:20.26
星奈、俺は 俺はまず地元で一通り後輩をナンパし、茶髪で周囲の注目を集めた後 女子高生をひっかけ地元にお持ち帰り、ご近所さんにお披露目をした。 星奈、夜景の綺麗な都会のマンションで結婚式をしよう。またわけのわ からないダダを捏ねたのだろう。高校を卒業したばかりの星奈にマンシ ョンを契約させたのだ。
なぁ、腹減ったな!?
gccを改造する講座があるみたいだけど clangを改造する講座はありませんか?
706 :
デフォルトの名無しさん :2013/03/16(土) 09:36:40.27
星奈、エロすぎるだろ・・・
C++というかVisual.Studioで Parallel::For使ってる人居るかな? C#のParallel.Forはいくらでも見かけるけど C++でこれ使ってる日本語サイトがほとんどみつからない
スレ違いというか、板違いです。
なんで? Parallel.Forってのはラムダ式がないと使えないんだが. ライブラリを提供するだけで,制御構造である繰り返しルーチンまでも引数として与えられるのがラムダ式 これに正式対応したのが11からだろ.
.netだろ?C♯もC++/CLRもスレ違い それとC++のラムダ式は基本的には関数オブジェクト定義の糖衣構文でしかない
Threading Building Blocksの話かと思った
C++11の機能が揃ってきたけど そろそろ新しい魔導書とかでないのか?
洋書ならいくつか
英語いやどす
effectiveの人が出してるよ。 電子出版で。 この前改訂版が出た。 もちろん英語。
また新たな黒魔術の誕生か・・・
TC++PL 4th まだかね。
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 これは、どういうからくりでしょうか?
>>718 emplaceはsのコンストラクタの引数を直接渡す。
つまりemplace_back(int arg)にintを渡して関数中で明示的にsのコンストラクタを呼び出すから問題ない。
emplace_backの中でplacement newに引数を転送するだけでしょう new(p_new_element) s(s(2)); // (暗黙定義の)ムーブコンストラクタの呼び出し new(p_new_element) s(3); // explicit s(int x_)の呼び出し
vector<s>さん「だってsなのは自明やんか」
&vector[0] + n == &vector[n]って仕様の欠陥じゃないか? boolとか番地と値の格納位置が一致しない型だと実装不可能だろう。 勿論boolは例外扱いになって入るが、stringで言うc_strにあたるようなもん用意すりゃ 良かったろうに何がしたいのか判らんな。
どこが問題になるんだ?
嫌なら使わなきゃいいのに
>boolとか番地と値の格納位置が一致しない型 何言ってんだこいつ
vector.data() + n ならいいと なにが言いたいんだろうな
>>722 あのさあ
std::vector<bool>の仕様よく読んでみな
>>726 その場合だと、dataを呼んだ時だけbool型配列にすればいいでしょ。
普段の実装時は、bit単位で格納すればいいから格納効率があがるじゃん。
そんで、bool以外も、その制限が加わればstd::vector<bool>と他のstd::vector<T>と
の齟齬が無くなる。
あと、24bit型や、48bit型をboolの様にvectorにつめ込ませて保持させても、 他のstd::vector<T>と矛盾が無くなる。
使う価値なし
Cの配列と内部ストレージのメモリイメージが一致しているのと Cの配列と一致するメモリイメージを返すメンバ関数があるのとでは、 CのAPIを呼ぶ際の親和性に天地の差があるだろう。
>>728 > その場合だと、dataを呼んだ時だけbool型配列にすればいいでしょ。
そっちの方が意味変わりすぎだろw
24bitや48bitのpackedなvectorは特殊化で書ける。
というか、そもそも何故Cの配列が ああいう構造なのかを考えてみた方が良いかも。 std::vector<bool>こそ要らないよね。 STLコンテナですらないとかtemplateの特殊化使った 初期のお遊び的仕様が引きずられている感じ 全く別のクラスとして用意する分には問題ないけど。
std::vector<boo>さんはstd::bitsetさんみたいなもんだから…
なんだそのサモハンキンポーの配列みたいな名前は
vector<bool>なんて使ってる人いないやろwww
> いないやろ なんだその似非関西弁は。 「おらへんで」だろ。
std::vector<bool> は既に非推奨だからな bool 配列作りたい時に凄い困ってるわ
おらんやろ いーひんやろ このあたりかな。
std::vector<bool>が非推奨な理由については Effective STL 第18項を参照のこと
>>738 boost::dynamic_bitsetがあるだろ
bitの数が静的に決まっているときはどうすりゃええねん
静的に決まってるならstd::bitsetでいい
745 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/03/17(日) 22:50:57.70
C++11/C++1yはマルチスレッドをサポートしてますか?
std::thread があるだろ
>>733 >STLコンテナですらない
&vector[0] + n == &vector[n]この余計な制約ぐらいだったと思うが具体的には?
>>740 bitsetは代わりにならんだろ
とりあえず deque<bool> で
>>746 なんと!
STLでスレッドがサポートされたとな!
これは使ってみよう!
>>747 &vector[0] + n == &vector[n]
vector 実装に対してこんな制約あるの?
size() が n の vector に対しては vector[n] の時点で未定義動作じゃないの?
std::vector<T>は確保している要素の連続性を要求しているよ 他にもvector<bool>についてはコンテナとしての要件を満たしていない可能性があるのでbegin(),end()は使ってはいけないなどの制約がある
>>751 C++98時点ではそんな制約はなく
vector<bool>はSTLとして問題なかった
遅くとも03の時には必須になっていたよね。
Effective STLを読んでない事がまるわかり
>>717 amazon.com見たら Publication Date が March 20 から June 3 になってたぞ...
問題が多いから非推奨になったわけで。
誰も使ってないだろうし特殊化やめちゃってもいいと思うんだけどね
ここまでdequeなし
デック
vector<bool>ってC++11でもdeprecatedにすらなってなかったと思うんだけど
仕方ないね
>>754 だから03で追加した仕様が問題だって話じゃないのか?
知ってるか? きゃりーぱみゅぱみゅってCPPって略称なんだぜ
な、なんだってー!!
CプリプロセッサもCPPが略だな。 CPPFLAGSはC++へのフラグじゃなくてCプリプロセッサ用。
cxxとか無理矢理だよな
知ってるか? さっき原発の冷却システム壊れたってニュースが しかも19時から止まってて復旧見込みないって (´・ω・`)
知ってるよ
テレビで何も言わないのがこわいね(´・ω・`) って書いてたら今頃NHKで言い始めた
テレビも既にいくつもの局が報じたようだけど 「燃料プールの冷却が止まったままで復旧の目処が立たず」の部分は曖昧に言って 「原子炉の冷却は復旧して問題はない」を強調してるらしいな つうか、何のスレだよ
std::vectorの連続性はC++98の最初の仕様書には書いてなくて、 あとから指摘されて追加されたんだよな。 C++ Standard Library Issues Listの69。 それまではオレも一生懸命newしてたさ。 ・・・ただし、iteratorはポインタとは限らない。
爆発したらしいぞ あちちあち 燃えてるんだ炉が♪
>>773 VC6のときにvectorのiteratorをポインタ代わりに使っていてVC.NETになったときに喰らったよい思い出
>>773 便利にはなったが、&v.front()とか&v[0]は気持ち悪いわぁ
dataがあるじゃない
C++11スレでdataを知らぬとな
気に入らないなら全部コーティングすればいいじゃない
おまいはマリー・アントワネットかw
普通はオレオレ実装なんかより世の中のライブラリの方が使いやすいし信頼できるもんだが C++に限ってはそうでもないな
コーティングか コーディングじゃなくて
livedoorメール終了かよ クローズドなサービス使ってたばちが当たったわ
本の虫乙
オープンかどうかとサービスの継続に何の関係があるんだ
オープンなら最悪自分で鯖立てて継続できるじゃん
そういうの気にする奴に限って自分で何かアクション起こしてる気配がない ただ口だけ
ドメイン譲ってもらうか、転送サービスやってもらわないとどうにもならんだろ? > 継続 メールアドレス別でいいなら、中身は単なるGmailなんだからどこでも行けばいいし。
メルサバのメンテなんて金もらってもやりたくないが 漢気溢れる誰かがやってくれるんだろう
先見性の無い馬鹿だなあ
先見性があればクローズドなサービスなんて使わないわけで
まさに安かろう悪かろう どこの馬の骨か判らない他人に依存してる時点で負け
そしてGmail全面有料化ですね。わかります。
足るを知る
1y(14?)の話題があるかと思って来てみれば皆無だった
swap演算子は結構衝撃的だった
1yは2019年までに出るのかのう
swapなんかユーザーコードでそんなに使うかなあ… わざわざ演算子にまでする意味を感じない ソートが少し書きやすくなるくらいじゃないの
いちいちswapフリー関数を多重定義しなくていいし使うときにヘッダをincludeしなくてもいいのは楽だ
moveがある今となってはswapを別途定義する機会も減ってるだろうに いまさら演算子追加してもあんまり嬉しくない気がする
swapは割と使うけど、moveがあればそうは使わないかもしれない 演算子追加するならローテート演算子が欲しい 暗号系でよく使うので
constexprみたいな場面では便利かもしれない
UTF8を前提にして 使える記号を増やしてほしい 括弧の種類とか増やしてくれ
キーボードにないだろ 小さなcore言語+ライブラリで対応していく流れに逆行するのもいい加減にしろ
キーボードくらい買えばいいだろ 文字の種類が増えれば:=:みたいな見苦しい演算子はいらないし
典型的な想像力の欠如の例だな
文字の入力くらいエディタでどうとでもできるだろ
ありふれた C++ のコードをデンマーク語の文字コードとして表示させようとするとワヤになる話が D&E にも載ってる。 ラテン文字だけでも何かと問題は多いので UTF-8 を採用する案は悪くないと思う。 実際にはそれほど使わなくても。 だだ、文法と密接な関係がある予約語や記号類に使う文字は限定的にすべきではあると思うぞ。
>>814 Scheme でも [ ] が括弧として使えるようになったけどな。 意味は ( ) と全く同じだけど。
そんでもってもっと大事なことだが、 Scheme は Unicode を採用した。 変数名に漢字も使えるよ。
特殊文字を使うのは、古くはAPL、割と最近だとFortressみたいな実験言語で 試みられているアプローチではあるが、大成功したという話を聞いたことはない
[[]]とか D言語の!()とか 苦労しているように見えるけどなあ 演算子も数学の演算子が使えた方がいいと思うし
新しい括弧使えば 頭にいちいちtemplateって書く必要もなくなるし
このバカなんなの
今使っている文字が当たり前だと思う方が馬鹿
独走態勢だね
馬鹿はずっとASCII文字だけ使ってろ
孤立無援だね
>>823 baka ha ascii mozi igai tukauna
プログラムソースコードにローマ字は禁止した方がいいね。 英語で書けばすむだろって話なんだから。
ローマ字表記になると読む速度が格段に落ちるんだが、何故だ…
テキストファイルにASCII文字でプログラミング なんて通用するのは21世紀まで
ASCIIの32個の制御文字が半分で、その分 graph が増えてたら色々生産性上がってただろうな。
他の言語では使ってる@と$ないよね
@とか$はコードがキモくなるから使いたくない。
^とかゲロキモイよな
Perlさんdisってのかコラァ
Blocksさんに謝れ!
SCHEMEがUNICODEを使えるというのはべっくらいこいた
$とかキモい変数名はやめて 全角文字の変数にしようぜ。 ジジイどもは卒倒するだろうが ぜったいに保守性は上がる。
それはいえてる、i とか j とかまで全角にする必要はないが、日本人にやさしいプログラムになりそうだ。 しかし問題が一つ、珍奇な概念の持ち主はやはり珍奇な漢語を羅列するだろう。命名規則はどうする? prologスレにいい感じの奴があるが、あのレベルを皆に徹底するのは大変なのでは?
プログラムコードは芸術作品だ。 美しく洗練されたコードには陶酔する。 @や$を使うなど、絵画作品にうんこマークを描くようなもんだ。
レス番コンテナ<レス番整数> 全角文字を変数にしようとするバカのレス番を保存するコンテナ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
全角文字を変数にしようとするバカのレス番を保存するコンテナ
>>835 ;
>>835 ジジイどもの片割れがあぶり出てきたねえ
>>838 卒倒寸前だねえ、お体をお大事にしてくださいね、この杖でも使って
コンテナに入れる機能を右シフト演算子に割り当てるとか気持ち悪い
1y(14?)の話題があるかと思って来てみればswap演算子の話題が数レスだけだった。
各国の文字列で書かれた変数名がプロジェクトで自由に使われたら大変だな エディタに単語翻訳プラグインが必須になりそう
UTF-8でいいじゃん
|よりは>>,<<使うほうがまし
>>842 プライムベンダーが使用する文字を
決めればok。
それが読めない奴は仕様書も読めないので問題なし。
標準化の提案をする気のない主義主張はもういいよ。
少なくとも「あ」が識別子に使えることは ISO/IEC 14882:2011で義務付けられてるな
使えるからってキリルとか連発されても意味わかんねえよ
ってのが
>>842 だと思うんだけど違うの?
識別子の多言語化くらいできてほしいわな
VBAでやってみたことがある 可読性はある程度改善されるけど タイピングでめんどくさすぎるからやめた
ゲームのDSLで日本語で変数とか使うスクリプト書いてたことあるけど慣れればどうってことないよ むしろ名前考えるときに英語脳使わずに済むので楽だった
変数名がアラビア語やヘブライ語か何かでガシガシ書かれてて、それを読めと言われたら多分泣く
>>848 メリットがあると主張する人がいる一方で、
「自分が使ったことなく違和感あるからNG
(ダメな根拠無し)」
と言う理屈は通らないでしょ一般的に。
多言語化すればボタンひとつでアラビア語の変数名が日本語の変数名になる
問題が起きるケースがある=全否定 これが否定派の論拠 識別子ぐらいでガタガタ言うな
ソースコードの多言語翻訳に対応したエディタがあれば解決だな どっかに有りそうだけど
853,855って人の言ってること聞いてるのか?
誤変換しやすい単語は地味にめんどかった。 以上 異常 とか両方使ってたから困る。
どうせ略すんだから翻訳なんてまともに出来るわけねえ
>>856 何で翻訳とかおかしな方向に走るのよ?
多言語カオスなソースじゃなくて、
仕様書と同じ自然言語の用語ぐらい
使わせてってことだよ。
>>860 ボタンひとつで〜ってのがあったから、それに反応したんだ
コーディング規約できっちり縛れるならありだと思ってる
運用しやすいかは良く分からん
規格のスレなんだから可能・不可能で良いだろう。そんなものの是非など、どうでもよい。
インド人に仕事を取られないうちに 変数名を日本語にしとけ
全部ひらがなで書けばコードがかわいくなる
女子高生プログラマの誕生である。
高校生なのにプロって、おかしくね?
お前らどうでもいい
868 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/04/01(月) 13:50:21.53
今更いらないだろ
テンプレに入れるべきではないな。 参照してる殆どがドラフトじゃないか。 ハゲの書物は昔から「仕様だと信じたら 標準化に入り損ねたハゲの妄想でした」 が多すぎる。 ただハゲは背景とか考え方を説明 しようとする点は評価できる。
D&Eが好評な部分は、なぜそうしたのか 設計者として説明しようとしている点にあるとは思う そういう本はすごく珍しい
ライブラリにしてもフレームワークにしても、設計思想を教えてくれないと使い方が 判りにくいよな。どういう使い方想定してんのか。 まあ、最近はサンプルつけるのが流行ってるみたいだから、この辺も改善されてきてるか。
>>873 あのくらいしっかり説明してるのは珍しいな。
しかも本としてまとまっているのは。
Lisp関係もどういうドキュメントは多いけども。
禿はもともとAT&Tの多社乗り入れ電話交換器に
各社アドオンを組み込む機構の設計をしていた。
だから設計の根拠を説明するのが
長年やりこなしてきた業務の一つだったんだろうな。
調整も巧いと思う。安易に反対したり、
思想対決に持ち込まずに、長文の技術論文を書く。
プログラミング言語の設計って理想主義的になりがちだけど、プログラマの教育 (のための資料) の充実具合だとか、 開発環境がどの程度追い付いているかとかも見定めて現実と折り合いを付けてきたってところはすごいと思う。
いきなりの擁護ラッシュこええ
この規模の言語がどうにかこうにか受入れられてるのは、 言語そのものの設計だけじゃない色々な点でうまくやったからだということを言ってるのであって、 逆に言えば、言語そのものはグダグダであるという話なんだけど、それって擁護か?
よくもわるくも高級アセンブラ 今はいろんなもの詰め込みすぎてカオス
2chは最強装備で完全攻略しないと気が済まない人間が多いから C++は人気無いよね
人気なんてどうでもいい そもそもC++は誰にでも扱える様なものじゃない
誰でも使いやすいように禿先生たちは日夜頑張っているというのに…
Haskell以上に保守性のない言語
>よくもわるくも高級アセンブラ
それはPure Cだろ
C++はカオスもう整形しすぎて崩壊してきてる。
実際大規模プログラミングはPure C で局所的にアセンブラ感覚で
息を止めて慎重にコーディングして速度を稼ぎながら
外枠はC#でいい
Parallel.Foreachで簡単にマルチコアの恩恵を受けられるようになった今
全部C#でほぼ問題なし
>>507 >エンコーダも作れるだろ。1分エンコードするのに数日かかるかもしれんが。
アホかおまえは。
一体どんなコード書いてるんだ。実際 Pure Cと比較しても1.5倍程度で収まる。
>>485 >それは本当に速度が要求されるプログラム組んだ事無いだけだろ
本当に速度が要求される部分でC++てアホかおまえは。
そういう場面は最低コンパイル後のアセンブリコードがほぼ見えるCで書くか、
直接アセンブラで書くわ。
> 思想対決に持ち込まずに、長文の技術論文を書く。 技術者の鑑だな。
SIMD大好き♪
N3571のstd::simdは無いよりあったほうがいいだろうけど なんか物足りない
思想がわかると、使う側もいろいろと判断し易いよね。
>>835 ,836
昔Mindとかあった。
まぁあれはForth系だけど。
C+11で大分初心者には書きやすくなったけど、言語仕様が縮小したわけじゃないからな・・・
ようやくC++03を完全に理解したのに もうC++11が出たよ
今何年だと思ってんだよ。
2003はマイナー変更だから、
実質15年もかかった
>>892 には無理
>>890 ひまわりもアイシテ
って今はなでしこか...
ゴミみたいなイテレータでのループが隠蔽されたのは良かった
こんな時間まで起きてる子供はクズ
本の虫の解説本が出たら本気出す
一生でないな
テンプレート回りの強力さとかで、 普通にCで書くより、普通にC++で書いた方が 速いコードにはなりやすいよね。
等価なアホレス "普通にアセンブラで書くより、Cで普通に書いた方が 速いコードになりやすいよね。" おまえのようなアホが書かない限り、C++で書くより 継承なんてもんがないCで書いた方が速いんだよッスカタン
適当なスクリプト言語や関数型言語を使ってCのコードを生成した方が C++でテンプレート使うより保守性も高いのであった...
903 :
デフォルトの名無しさん :2013/04/03(水) 07:56:09.54
テンプレはexeサイズも馬鹿でかくなる愚の骨頂
テンプレートが速いとか、何の冗談か
何と比べるのか、具体的な条件が明示されていないのに、 速いとか遅いとか言い始める奴はどっちも馬鹿。
アホしかいねーなこのスレは
907 :
デフォルトの名無しさん :2013/04/03(水) 08:23:50.11
2chはあほが濃縮されてる
いや以前はずっとマシだった uyとQが現れてからこの双頭のキチガイによって質が低下している
本当にCでコンパイル後のアセンブリコードがほぼ見える人間ならC++だって同じだろ? 何を言ってるんだか
>>908 相手する方が質の低下を加速してあげてる件。
>>909 C++のコードはiostreamを使っただけで肥大するし、コンテナを使ったら
もうカチャカチャ
それに仮想関数の呼び出しはコードを追い掛けるだけでは一体どこに
ジャンプするか予想しにくく、トレースするしかない
>>910 あくまでも人のせいにする気か
この二人を消すだけで十分
>>911 ライブラリの話を言語の違いと混同されても。。。
それに、仮想関数の呼び出しが予想しにくいって?仮想関数の呼び出しメカニズム
(というか仮想関数テーブルのセットアップメカニズム)本当に理解してるか?
仮想関数がしっくりこない系おじさんか。
>>913 お前エスパーか?どの仮想関数が呼ばれるかは、ジャンプする場所に来てみないと
分からない
その時にメモリから呼び出すかレジスタの値でオフセットでジャンプテーブルを呼び出すかは
別として、call [rbx] とか書かれててみ
rbxの値が事前に予測出来るとでも?
それに標準ライブラリの中には継承で作られている物も多い istream、ostream、ifstream、ofstream、istringstream、ostringstream全部継承だ つまり内部では仮想関数が使われている 混同ではない
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()で振り分けるからな
できました!ありがとう
誰だ貴様!
継承=仮想関数とか言ってる時点で。。。 やれやれ
921 :
デフォルトの名無しさん :2013/04/03(水) 14:30:44.74
>全部継承だ >つまり内部では仮想関数が使われている 晒しage
迷惑なんで はやく仮想関数の呼び出しを簡単に予想する作業に戻ってくれませんかね
デタラメを書かれる事が迷惑なんだが
925 :
デフォルトの名無しさん :2013/04/03(水) 15:21:55.35
どうせJava脳なんだろこの馬鹿は
あくまでも継承じゃないと言い張るなら、このコードが通る理由をお聞かせ願えますかね int main() { std::iostream* ip; std::string str; std::stringstream os(str); os << "abc" << std::endl; std::cout << os.str().c_str(); ip = &os; // なぜ通る? }
スレ違いなんで相手にしなくていいよ
あら?継承だと初めて気づいたら「スレ違い」扱いですか 分かりやすいですねww
int main() { std::iostream* ip; std::string str; std::stringstream os(str); os << "abc" << std::endl; std::cout << str; ip = &os; // なぜ通る? }
kityguy
931 :
デフォルトの名無しさん :2013/04/03(水) 17:34:24.84
とうとう誰も言ってない主張に反論はじめましたよこのキチガイ
仮想関数と同じ事をCでやろうとした方が 遅くなるし、どういう動きになるか分かり辛い。
このスレ、テンプレがシンプルでなにを対象にしているか分かりにくい気がしますね。 自分はC++11とか、それ以降の規格や新機能について議論するスレだと 勝手に思っていたのですが、そういったことは明記されていないですね。 11なんかはスレ番とか思ってる人もいるんではないでしょうか? あらためて、スレの方向性とか考えてテンプレ考えてみてもいいのでは? ただ、ネタがないので暇つぶしに相手してあげることをとめたりはしません(2chですし)
今暴れてるようなやつはテンプレがどうであれ暴れるよ
stringだって、派生クラスだ!
俺のせいかよ
ゴミが無知を指摘されてファビョるスレがあると聞いて
Rubyとかが出て低年齢層がプログラミングやるようになったせいか
N-BASICの時代から低年齢層でもプログラミングを楽しんでいましたよ、N-BASICからZ80に一足飛び、というのもすばらしいじゃないですかっ
継承先生は条件ジャンプをいつ発見するんだろうか? つーかcall [rbx]とかは分岐予測して投機実行しないの? 最近のプロセッサは分からん…
どうみても投棄実行です
すてるのか?
>>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)で発生させた乱数
バカvsバカ
>>944 関数ポインタ経由だと、それだけで、それはそれは遅くなるに決まってるでしょう、インラインで展開される場合にくらべると。
コンパイル速度の話だったのかな
qsortにしろstd::sortにしろそのアルゴリズムがクイックソートだなんて決まってないんだし 同じアルゴリズムじゃないと「テンプレートが速い」ことを示す例として不適切だと思うんだが そのへん検証したの?
c++は遅いな。コンパイルがw テンプレは強力にインライン展開されるんだから、 この手の単純な処理はcより速くて当たり前。
一連の書き込みはエラーとして一旦、ロールバックせよ。
Pentimu4で一億回関数を呼び出して、測定不能レベルの速度なんだけどね。
馬鹿相手にするの辞めろよ。 スレ違いな上に、話が想像を絶するくらい下らないのに。
Cの標準ライブラリはC++のSTLより遅くなる。 で、ゴリゴリ最適化すれば速くなるかもしれないけどそれはC++でも一緒。 そうなると選択肢を狭める意味が見いだせない。
測定不能ってwinだと10ミリ以下ぐらい? 普通クロックは3GHz程度(0.3ナノ秒)しか無いんだが 関数callが0.1ナノ秒なんて すごいアーキテクチャーですねw
C++11のアルゴリズムやコンテナはかなりstd::moveを使って最適化されてるぞ
お前以外みんな知ってるよ
なんでそういう風に憎まれ口を叩くんだ? 恨んで欲しいのか?
たまに伸びてると思ったらコレかよ concept liteの話とかしろよしてください
ストリームが継承だと知らなかった馬鹿が暴れてるようなんです 自尊心が傷ついたようで
ストリームが継承だと知っていたところで自尊心を肥大化させる以上の使い道があるのか?
継承馬鹿は未だに何が馬鹿なのか気付いてない模様
もしかして: 仮想関数なら常に間接コールになると勘違いしてる
>>960 ストリームをポインタで切り替えて使った事もないのか
人を自分より馬鹿だと思わないと自分の自尊心を保てない自己愛が肥大した 自己愛性パーソナリティ障害の人が住み着いてるようですねえ
自己愛性パーソナリティ障害
飛び先を動的に決めたい人はvirtual付け、
固定にしたい人は「継承してもvirtual付けない」。
さすがに
>>911 もわかってるだろ。
で、iostreamが前者の設計になっていて
>>911 のデバッグ作業に時間がかかって
>>911 のお気に召さなかった。
好き嫌いは人それぞれだか問題ない。
virtual付けない継承なんて。。 話が想像を絶するくらい下らない。
ジャンプを固定にしたいなら継承するな これでok
>>967 妄想乙
お前がそういう目に遭っているから他人もそうだとしか見えないんだろうな
頭おかしいよはっきり言うと
頭おかしい
自己紹介
すぐ反応www 精神科に行った方がいいぞ
精神科
いいこと思いついた。 thisを引数にとる関数を用意して ポリモーフィズムを実装し、 その関数ポインターをメンバーに持てば コンパイラが裏でやる謎の処理に 惑わされずに自分でキッチリ制御できる。
お前頭いいな
pythonの誕生ですねわかります
大規模プログラミングのために生産性をあげる仕組みはもうC++なんかに必要ない そんなのはC#でやればいい。 だいたい継承なんて生産性向上のための仕組みでしかない アセンブラの代わりはCでいい。側はC# C++はもう居場所がない。 ちなみに組み込みとかC++より未だにCが圧倒的に多いし。 そもそもC++じゃ生産性が上がらないんで全面リニューアルしたのがC#ともいえる javaやらJ++やら裁判沙汰の経緯を蒸し返すなよ >>all
何そのヤケクソ
最初の20行くらいしか読んでないけど
>>980 のリンク先書いてる奴が超絶低能だというだけで
C++固有のことではない非同期処理をここに貼っても釣れないだろ
こんなのが本書いてる状況はアレだと思うが
C++ではなくてC++/CLIなんだが・・・この著者大丈夫か?
Task, Parallel.Foreach,lockを駆使して日々並列プログラミングと格闘してるC#ユーザからすると 今更何寝ぼけてる?って記事だな。 C++は未だに粒度の小さいプログラムの並列化に四苦八苦してるからな
C#はVMありきなJavaの置き換えだろ。
別にC++でも並列プログラムぐらい普通に書けるだろ。 どちらかというとMSのAPIが糞ってだけで それも、並列プログラムが書きにくいというのではなく 並列じゃない処理が書きにくいという意味不明さ
>>987 ほう.じゃ,タスク内のループ処理で各コアに均等にループを割り当てて処理時間かせぐような処理が
C++で簡単にかけるかね?
案の定よく釣れる餌でしたねっ!
均等にの条件が良く分からんけど #pragma omp parallel for でおわりじゃないの?
OpenMPでforループバラしたんだけど、 かなり大きな処理量じゃないと、オーバーヘッド(スレッド切り替え?)が大きすぎて ぜんぜん有難味がなかったガッカリした。
そりゃそうだろ…
>>993 何でスレッドの切り替えってこんなに時間かかるの??
スレッドだと重いんでTPLがあるんじゃねーか
997 :
994 :2013/04/04(木) 19:25:54.15
>>995 調べてみた。
.NetFrameworkなんだね。
生C++が好きだから使わないかな・・・。
でも、スレッドより軽くて並列処理ってすごいね。
>>996 なんと!
そんなところがネックになっていたとは・・・!!
もう並列処理はGPUにやらせます!
いや、スレッド切り替えが問題になるような 軽い処理はGPUじゃもっとヤバイだろ。
999 :
994 :2013/04/04(木) 19:38:28.79
>>998 あ、その通りでござんすw
そういう処理はSIMDでやってますw
AVXマンセー。
次スレは18だから直しといてくれ 俺は無理だった
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。