C++0x 6 - 暇つぶし2ch

C++0x 6 ..

697:デフォルトの名無しさん
09/09/04 12:59:12
>>695は今すぐExceptional C++を穴が空くほど読むべき

698:デフォルトの名無しさん
09/09/04 13:10:16
pimplしたくないからprivateメンバをヘッダ以外に追い出せる別な方法が欲しいって話なんだけどなぁ。

699:デフォルトの名無しさん
09/09/04 13:15:19
>>698
別の方法と言うなら、空のインターフェースクラスと実装クラスに分ける方法があるじゃないか。

700:デフォルトの名無しさん
09/09/04 13:28:30
>>698
>>673 >>676は追い出せてないじゃんw

701:デフォルトの名無しさん
09/09/04 13:31:36
ヘッダの問題はModules in C++がTRとして出て解決する予定になっている。
だから、同じ問題を解決するものは
意味論的にModuleより優れていない限り、考慮する価値も無い。
よってこのネタは終了。

702:デフォルトの名無しさん
09/09/04 13:51:16
>>673 >>676で追い出せると思ってる理由が分からんｗ

703:デフォルトの名無しさん
09/09/04 14:04:05
>>702
いや、技術的にこれで追い出せる～みたいな話じゃなく、
こんな書き方で追い出せるようにならないかなって妄想でｗ

704:デフォルトの名無しさん
09/09/04 14:04:56
>>701
ヘッダ問題解決する予定があるなら、本当にどうでもいい話でした

705:デフォルトの名無しさん
09/09/04 14:34:43
クラスを丸ごとpimpl化するのは面倒なので、クラス内に包含する一部のオブジェクトのメンバ変数をshared_ptr<>にしてる。
そうすれば一部だけでもヘッダーをcppに移せるからそこそこ効果がある。

706:デフォルトの名無しさん
09/09/04 14:37:26
>>705 は中途半端。
対処としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。

ｽﾚﾘﾝｸ(tech板:182番)
これ思い出した。

707:デフォルトの名無しさん
09/09/04 14:48:47
>>705
pimplじゃん

708:デフォルトの名無しさん
09/09/04 14:55:31
やけくそ頻繁に参照されるメンバがあって、そこだけpimplから外に出したりすることはある

709:デフォルトの名無しさん
09/09/04 14:59:32
>>707うん、メンバすべて丸ごとじゃなくて一部のメンバにpimpを適用。
すべてのメンバ関数で間接呼び出しさせる必要がない。.演算子を->にするだけでいい。

>>706中途半端なのはそうだけど、手間と効果の兼ね合いかな。

710:デフォルトの名無しさん
09/09/04 15:08:23
初心者スレかよ。

711:デフォルトの名無しさん
09/09/04 15:42:25
>>673から一気にアホな流れになったな

712:デフォルトの名無しさん
09/09/04 16:02:28
汚染してしまってすまん

713:デフォルトの名無しさん
09/09/04 16:06:46
これでもまだマシ、っていうのが世間におけるC++のレベルなんだろうな。

C++0xの言語側の実装状況は
URLﾘﾝｸ(wiki.apache.org)
みたいの見ればすぐ分かるし、ネタにもよくあがるけど、
ライブラリの方はどの程度ついてきているのだろう。
URLﾘﾝｸ(gcc.gnu.org)
見ると、constexprが無いのが結構響いてるっぽいなあ。

右辺値参照(というかMove Semantics)のライブラリ側の対応も大体済んだみたいだし、
そろそろ実用面でのベンチマークを見てみたいね。

714:デフォルトの名無しさん
09/09/04 16:24:24
URLﾘﾝｸ(gcc.gnu.org)
によると、constexprの実装はGCC-4.5で入るのかな？

715:デフォルトの名無しさん
09/09/04 16:24:32
ベンチマーク必要な変更はない。

716:デフォルトの名無しさん
09/09/04 16:45:04
必要か不要かじゃなくてどの程度かを知りたいって話だろ・・・

717:デフォルトの名無しさん
09/09/04 17:22:30
標準コンテナをvalue semanticsで使っているようなプログラムは
g++のコンパイラオプションに-std=c++0xを入れるだけでかなり早くなるかもしらんが、
そんなプログラムはあまり無いだろうなあ。
使っているとしてもstd::stringくらいか。

718:デフォルトの名無しさん
09/09/04 17:50:15
コンテナにshared_ptrを突っ込んで使ってる人は自動的に速くなるだろうな。
アトミックオペレーションのコストって高いからなあ

719:デフォルトの名無しさん
09/09/04 18:28:50
constexprて実装側で無く利用側で指定するようには出来なかったのかね

720:デフォルトの名無しさん
09/09/04 18:33:54
>>719
例えばどんなメリットがあるん？

721:デフォルトの名無しさん
09/09/04 19:05:21
デメリットや実装難度を見たいって話なんだから
メリットが判らん様な低脳は黙ってればいいと思うよ

722:デフォルトの名無しさん
09/09/04 19:22:34
decludeと同じく何を意図しているのか分からんが、
案を出すなら構文と意味論の例を提示しろと。

定義は1回なのに対し、利用するところは無数にある。
その全ての箇所で指定するなんて、現実的じゃない。
明らかに、定義時に指定する方が合理的。

指定しないでもコンパイラがコンパイル時に判断すれば良いって？
D使えば良いんじゃない？

723:デフォルトの名無しさん
09/09/04 19:39:06
>>719利用者側で指定するとはどういう意味かわからん
実装時にconstexprによってコンパイル時の評価が可能で且つ同じ引数に対して同じ定数が戻ることが
保証できるわけだろ。それで十分だと思われる。

724:デフォルトの名無しさん
09/09/04 19:50:39
>>708
よけくそ頻繁ってどこの方言？
純粋に興味で知りたい

725:デフォルトの名無しさん
09/09/04 19:56:32
やけくそ　と書いたところで頻繁の方が良いカナと思ったが、
どっちが良いかは全文を書いてから決めることにして、取り合えず
両方残したままにしたのが裏目にでて、消すのを忘れてたと読む。

726:デフォルトの名無しさん
09/09/04 19:59:39
>>721
態度は悪いが良い指針
で、メリット何？

727:デフォルトの名無しさん
09/09/04 20:06:55
constexprはコンパイル時定数として自然に使えることを目的としているんだから、
使用時に何か指定が要るっていう時点で問題外だろ……

「ぼくのかんがえたC++0xはスレ違い」の文言をテンプレに追加するべきだ
あと、「papers嫁」もだな

728:デフォルトの名無しさん
09/09/04 21:27:25
URLﾘﾝｸ(d.hatena.ne.jp)
> この点をふまえて考えると、 std::list::size() でリンクをたどって
> 数える処理は「コンテナ内のオブジェクトに対する操作」ではないので、
> 計算量の要件が仮に定数時間とされても、実装を変更する必要は無いと
> 言えてしまいそうだったりします。

これ、どうなの？
これがほんとなら N2923 をまじめに考えてた委員会の人とかみんな
この点を見落としてるってこと？

729:デフォルトの名無しさん
09/09/04 21:29:43
>>697
そんな本読む必要なし。
だから、その手の本を日本人がかけないんだよ。

730:デフォルトの名無しさん
09/09/04 21:42:29
>>728 emptyが有れば十分たい

731:デフォルトの名無しさん
09/09/04 21:44:46
連結リストに対してsize()なんかが必要になる時点で設計おかしいよな

732:デフォルトの名無しさん
09/09/04 21:48:17
えー誰得？

733:デフォルトの名無しさん
09/09/04 21:50:48
>>731
それを断言できるスキルがうらやましいです＾＾；；
もっと精進せねば＾＾

734:デフォルトの名無しさん
09/09/04 22:17:56
>>728
そのコメントは嘘。

URLﾘﾝｸ(gcc.gnu.org)
で問題にしているのはamortized constant timeかconstant timeかの違い。
GCCでの実装がamortized constant timeなのにStandardではconstant timeと
書いてあるから、これはGCCのバグだよね、と言うのが論旨。

結局、Standardで
URLﾘﾝｸ(anubis.dkuug.dk)
と修正されているので、amortized constant time操作であるstd::deque::push_back()
はStandard通りの振る舞いということ。

735:デフォルトの名無しさん
09/09/04 22:36:49
>>734
その解釈には無理が無いか？

もしそのとおりであれば、 gcc のバグ報告に対して 23.1/2 をあげる必要が
無かったはず。

それに、 defect 139 を挙げてるのは、報告者が vector の push_back に
言及してたからでしょ。 deque の push_back については最新のドラフトでも
constant time が要求されてるよ。

736:デフォルトの名無しさん
09/09/04 22:59:02
>>735
無い。無理があるのは

You are talking about complexity in terms of the number of operations
performed on pointers to the contained objects.

の方だと思うぞ。そもそも、Standardでは

23.1.1
All of the complexity requirements in this Clause are stated solely in terms
of the number of operations on the contained objects. [ Example: the copy
constructor of type vector <vector<int> > has linear complexity, even though
the complexity of copying each contained vector<int> is itself linear. end
example ]

とわざわざ例を挙げて言っているように、ポインタ経由でアクセスしているか否かを
問題にしているわけではない。
最新のドラフトでは確かに"should have constant complexity"と書いてあるが、
そもそもDefect 139は "Status: TC Submitter: Andrew Koenig Date: 30 Mar 1999"
とあるように、確実に当時のStandardに反映されている。その後complexityに対する
委員会の見解が変わったか、エンバグしたかのどちらかだろう。

737:デフォルトの名無しさん
09/09/04 23:16:42
>>736
誰もポインタ経由でアクセスしているか否かなんて問題にしてないよ。

問題なのはコンテナ内の要素に対する操作か否か。
list の size で要素を数え上げる処理は明らかに違うでしょ。

あと、 deque の push_back の要件は defect 139 で修正された
Optional sequence operations じゃなくて、 23.2.1.3 [lib.deque.modifiers] に
別途記載されている。最新のドラフトだと 23.3.2.3 ね。
> Inserting a single element either at the beginning or end of a deque always
> takes constant time and causes a single call to a constructor of T.

やっぱりおかしいよ。

738:デフォルトの名無しさん
09/09/04 23:31:13
>>736
"should have constant complexity" って、どこ見てるの？

defect 139 で修正された Optional sequence operations についての記述では
2003 の時点でも最新のドラフトでも
"shall implement them so as to take amortized constant time" って書いてあるよ。

まぁ、もう元の話とは関係ないんだけどね。

739:デフォルトの名無しさん
09/09/05 00:38:32
>>737
そもそもGCCのバグ報告を持ち出したのは、ポインタ経由での要素へのアクセスは
オブジェクトへのアクセスでは無いからcomplexityに影響しないということだと
思うが。

> 問題なのはコンテナ内の要素に対する操作か否か。
> list の size で要素を数え上げる処理は明らかに違うでしょ。
その認識が合っているとは思えない。list::reverse()のcomplexityはlinear time
だとStandardにあるが、これはlist::size()同様にリンクポインタをいじることで
実現可能。もしリストのリンクを辿ることが"operations on the contained objects"
でないのなら、list::reverse()のcomplexityも当然constant timeと書くと思うが。

こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
誤解をしているとも思えない。

740:デフォルトの名無しさん
09/09/05 00:46:04
>>738
> "should have constant complexity" って、どこ見てるの？
これは間違いだった。General container requirementsのsize()について見ていた。

> defect 139 で修正された Optional sequence operations についての記述では
> 2003 の時点でも最新のドラフトでも
> "shall implement them so as to take amortized constant time" って書いてあるよ
見落としていたが、確認した。

741:デフォルトの名無しさん
09/09/05 00:57:07
>>739
gcc のバグ報告ちゃんと読んでる？
ポインタ経由での要素へのアクセスなんてどこにもでてきてないはずなんだけど。
問題になってるのは deque 内に持ってるポインタ配列の再確保とコピーね。

> こんな矛盾を委員会が放置しているとは思えないし、そもそも>>728が言うような
> 誤解をしているとも思えない。

みんなそう思ってるんだけど、事実は矛盾が発生しているようだという話ね。

list のリンク操作は "operations on the contained objects" であって
deque のポインタ配列操作はそうではない、というのはおかしい。

元々の意図はそうなんだろうとは思うけど、それが 23.1/2 の記述が甘いせいで
おかしくなっている、と。

742:デフォルトの名無しさん
09/09/05 01:09:31
>>741
正しくはポインタへのアクセスだったな。まあそのくらい補完してくれよ。

で、お前さんの立場は何なの？
list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
書くべきだという意見？

自分は、こんな大事に気づかずに放置するわけが無くて、deque::push_back()の
complexityをamortized O(1)と書くべきという意見。
amortized complexityを良く理解していない人は結構多い上に、defect 139に
あるように実際同様のバグがあったこと、こちらの方が可能性が高いと考える。

743:デフォルトの名無しさん
09/09/05 01:09:40
調べてみると、こんなのが出てきた。
URLﾘﾝｸ(www.open-std.org)
ここの Issue Number 20-036 で問題の 23.1 p2 の追加が行われている。

これが "10 July 1996" とあるので、おそらく list の計算量要求なんかはそれ以前から
あったもので、操作全体の時間について言っていたのがそのままになってる可能性が高い。

N2923 も含めて、 list のリンク操作はあきらかに計算量に含まれる想定で書かれている
ので、 23.1 p2 の文面を現状に合うように修正するべきなんじゃないかと思う。

そうすると、 deque の push_back に対する要求は amortized constant に合わせて修正
しないといけなくなりそう。ただし、これは制限を緩めるものなので、現状の実装を変更する
必要は生じないはず。

744:デフォルトの名無しさん
09/09/05 01:29:39
>>742
> で、お前さんの立場は何なの？
> list::size()やlist::reverse()はO(1)（面倒だからO表記を使う）とStandardに
> 書くべきだという意見？

そうするか、 >>743 のとおり 23.1/2 のほうを直すか、とにかく矛盾を直すべき
だとは思う。

>>743 のほうが自然だし、楽だね。

745:デフォルトの名無しさん
09/09/05 01:32:24
>>743
なるほど。確かにそういう事になるだろうな。そうすれば>>728や>>735 >>737
のようなおかしな解釈をする輩がいなくなる。

そもそもコンテナ内の要素数に依存するような操作をしているのにポインタへの
アクセスは関係ない、なんて言い出したらcomplexityを明示することが無意味に
なってしまう。

746:デフォルトの名無しさん
09/09/05 02:15:43
どちらかというと「標準委員会が矛盾に気づかないわけがない」なんて
思い込んでるほうがおかしいだろ。

747:デフォルトの名無しさん
09/09/05 02:48:46
>>746
見苦しいぞ

748:746
09/09/05 03:01:16
へ？なんで？意味がわからない。

749:デフォルトの名無しさん
09/09/05 09:28:43
>>746
おまいは>>728から100回読み直してこい

750:デフォルトの名無しさん
09/09/05 13:05:38
どっちがおかしいよかよくわかってない美少女中学生もお忘れなく

751:デフォルトの名無しさん
09/09/05 15:48:55
規格の文面をまじめに読むと、どっちの解釈が「おかしい」とも言い切れない状態に
なってるのが問題。

752:デフォルトの名無しさん
09/09/05 15:56:27
ここでいう「どっち」は >>728 と >>743 の２つね。（ >>745-746 は敢えてスルー）
728 は deque::push_back の（計算量）要求は正しくて list::size() の要求は無意味。
743 は list::size() の要求には意味があって deque::push_back の要求は間違ってる。

753:デフォルトの名無しさん
09/09/06 12:29:21
23.1.1 の記述を問題にしてる人は、具体的にどう直せば厳密になると思う？

俺はまともに書き下せる気がしないので、
「今の文面を、常識的に考えて意図したいであろう意味と解釈して読め」
が現実的だと思うんだけど。

754:デフォルトの名無しさん
09/09/06 13:04:37
計算量とか「実装の質」で切り捨てたらあかんの？
なんか言語の規格で決める事じゃないような気がする

755:デフォルトの名無しさん
09/09/06 13:13:12
>>754
それはさすがに認識のレベルが出発点にすら立ってない