C++相談室 part137

1 名前：デフォルトの名無しさん [2018/08/27(月) 16:02:00.94 ID:vY3QDx2y0.net] 次スレを立てる時は本文の1行目に以下を追加して下さい。 !extend:on:vvvvv:1000:512 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part137 https://mevius.5ch.net/test/read.cgi/tech/1531558382/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.103【環境依存OK】 https://mevius.5ch.net/test/read.cgi/tech/1530384293/ ■長いソースを貼るときはここへ。■ 　codepad.org/ 　https://ideone.com/ [C++ FAQ] https://isocpp.org/wiki/faq/ www.bohyoh.com/CandCPP/FAQ/ (日本語) ----- テンプレ ここまで ----- VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 822 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 14:53:59.72 ID:5bmo24w9p.net] 江添で言えばまさにわかりやすくその辺の事情解説してくれてるだろ 今の話で江添より詳しいとかありえねー 823 名前：はちみつ餃子 mailto:sage [2018/09/28(金) 17:00:34.02 ID:7KXXqv1B0.net] >>803 江添氏は C++ を使うプログラマというよりは、 C++ の規格の専門家として C++ の知識を持ってるんだから、 かなり詳しいよ。 824 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 17:18:49.52 ID:hWUH9Sli0.net] >>806 いずれにせよ、気持ちはうれしかったよ。 825 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 17:49:54.67 ID:7VsD45M6M.net] >>805 そのへんの事情って？ >>806 それは本人も自負してるようだけど 826 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 18:34:51.41 ID:2UofBC6a0.net] >>790, >>794あたりの仕様の事情な 827 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:21:09.15 ID:tCflGkAm0.net] もし非テンプレート関数かつ非インライン関数なvoid bar(Foo&& a)に左辺値xを渡してビルドが通る言語規格だとしたら、 　tmp = xのコピー 　barのビルド結果←(tmpのアドレス) ということになってxのコピコンが呼ばれてしまうま つまり右辺値参照がコピコン削減になるかどうかというのは関数を右辺値参照にしただけでは決まらず、 呼び出し元の条件次第なので、bar()を作る人/使う人双方の慢心を避けるためにエラーにするんだろＪＫ 一方テンプレート関数またはインライン展開される関数なら、上のようなへタレコードに一時的になっても すぐさまコピコン削減ができるから実質弊害が無い ただし、そういった関数でも再帰呼び出ししたりアドレスをとったりすると上と同じ議論になるので、 再帰呼び出し/アドレスを取る操作　両方ともありえるインライン関数は>>790の例外の適用外とされ、 テンプレート関数は再帰呼び出しが有り得ないし、アドレスを取る奇特な人間も居ないだろうということで>>790の例外が設けられた 828 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:24:43.89 ID:tCflGkAm0.net] 訂正； △：　すぐさまコピコン削減ができる ○：　コンパイラがすぐさまコピコン呼び出し削減最適化をかけられる コピコン呼び出し削減最適化はこの場合データフロー解析の結果を流用したらできる C++はgotoが使われたとき、コンストラクタが呼ばれずに使われるオブジェクトが生じないか否か確かめるために データフロー解析はもともと必須なので、コピコン呼び出し削減最適化はC++コンパイラ書きなら誰でも出来る（多分 829 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:34:28.86 ID:tCflGkAm0.net] >>794 >const T& に rvalue がマッチするんだった。 それはある意味当然すぐる const T& x = r; // rは右辺値 ... y = x // (*) としたときに、コンパイラは(*)みたいな文が現れるまでは、 xへのアクセスを機械的にrへのアクセスに置き換えれば良いわけでゼロコスト rが所有権を失ったらxのアクセスも不正となるが、これは書き換え可能なオブジェクトを const参照をとってから書き換えた場合も似たようなもの（身からでたサビ なのでコンパイラはやっぱ何もしなくて良い 830 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:36:22.95 ID:tCflGkAm0.net] （30分前にこのスレを読んで初めて右辺値とか右辺値参照といったﾌﾞﾂを知った初心者なので語ってみた 831 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:13:49.14 ID:pgnHcfqPM.net] >>812 y = x の後もxへのアクセスはrへのアクセスで良くないの？ 832 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:40:22.15 ID:5I7m9/jNd.net] どんな文が現れようとずっとrでいいんじゃね？ 833 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:45:46.54 ID:tCflGkAm0.net] >>814 >>815 ﾎﾝﾏや！(；ﾟДﾟ)天才か！ 834 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:50:40.02 ID:pgnHcfqPM.net] >>816 ｳｯｻｲ､ﾁﾈ 835 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 23:48:18.05 ID:AAs3crMS0.net] >>810 再帰だろうがアドレスとろうがオンラインだろうが例外は適用されるだろ。 やっぱ30分で理解するのは無理じゃね？ 836 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 23:50:49.06 ID:HzE5xAmYr.net] auto a = funcA(funcB(funcC(input))); みたいな感じの関数の入れ子ってさ、ある関数が終わる度にその都度インスタンスを作ってコピーして次の関数に渡すということを繰り返すんだよね？ つまり、関数たちの返り値が巨大なオブジェクトだったら、このように書くことで余計に時間がかかるよね？ 837 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 00:09:10.14 ID:UwfF5QN40.net] >>819 いんや。 オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし、戻り値最適化で一切何も起こらない可能性すらある。 て、はちみつが言ってた。 838 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 00:13: ] [ここ壊れてます] 839 名前：53.80 ID:X+ykKtqpr.net mailto: >>820 へぇ > 一切何も起こらない というのは、一切余計なオーバーヘッドがない、ということですか？ [] [ここ壊れてます] 840 名前：デフォルトの名無しさん [2018/09/29(土) 00:22:35.94 ID:4+9Po3M4a.net] 単純なコピーよりは早くなる可能性があるってだけでは？ 841 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 00:30:08.48 ID:UwfF5QN40.net] ちょっと誇張しすぎた。 正しくは「コピーもムーブも起らない可能性すらある」 コピーもムーブも起こらなければ、その分のオーバーヘッドは当然ないよ 842 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 00:36:40.21 ID:X+ykKtqpr.net] へぇ〜〜〜 ありがとうございます まぁそこがボトルネックじゃない限り余計なこと考えない方が身のためなのかもしれませんが 843 名前：はちみつ餃子 mailto:sage [2018/09/29(土) 02:25:18.76 ID:4F2hgYyq0.net] >>819-824 コピーもムーブも省略される可能性ってのは、左辺の場所でオブジェクトを直接に構築するっていう意味。 構築してからそのままコピーしてる (そして元のオブジェクトが一時的である) 場合は実際には直接構築したって同じよねという話。 844 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 14:26:47.44 ID:7XGFV27+0.net] >>820 ＞オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし なんかムーブコンストラクタを魔法か何かと勘違いしてないか？ ムーブコンストラクタの方が重い処理してたら当然重くなるんだぞ 845 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 14:32:22.06 ID:OnnXxjQtM.net] >>826 ええ… コピーより重いムーブコンストラクタの存在を前提に話す必要ある？ 846 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 14:44:27.90 ID:7XGFV27+0.net] むしろムーブで軽くなるのは大抵の場合ムーブによってヒープの確保、解放を 避けられるクラスだけ、だろ ある意味そっちの方が限定して話をしてると思うが 基本をすっ飛ばすからはちみつその他誤解するやつが出てくる 847 名前：デフォルトの名無しさん [2018/09/29(土) 14:49:31.13 ID:IuTgmxg/0.net] この機能が必要になった背景・経緯 ムーブセマンティクスは、C++03でもNRVO（特定の文脈でのコンストラクタの省略）や、 C++11で非推奨となったstd::auto_ptrで実現されていた。 しかし、NRVOがいつでも機能するわけではなかった。 また、std::auto_ptrにはコピーと同じ文法でムーブしていることなど、問題が多かった。 そのため、コピーと区別でき、統一的にムーブを表す文法が言語機能として必要とされた。 つまりこんなあぶなっかしい unique_ptr、shared_ptr、weak_ptrとか使ってるﾔﾂﾗも ｸﾙｸﾙﾊﾟｰしかいない この程度の簡単な制御も自分で簡単に制御しきれないﾜｹだからな 848 名前：デフォルトの名無しさん [2018/09/29(土) 14:56:25.79 ID:IuTgmxg/0.net] しかしｱﾎのあたらしもの好きは半端ない 頭悪いｼﾛﾓﾉでも新しいものができたら使わないといけない病になってるからな ｼﾛｳﾄに多い 849 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 14:58:40.21 ID:7XGFV27+0.net] いや、autoはともかくshared, unique, weakは危なっかしくないと思うが・・ ムーブが使えるようになってからだし あと個人的にはcpprefjpは規格寄り過ぎてユーザー寄りじゃないと思う cppreference.comを使うべき 850 名前：デフォルトの名無しさん [2018/09/29(土) 14:59:08.11 ID:IuTgmxg/0.net] で、こんなしょうもないことより ﾎﾝﾄに理解しないといけない部分がすっぽりと抜けてる 851 名前：はちみつ餃子 mailto:sage [2018/09/29(土) 16:42:03.70 ID:4F2hgYyq0.net] C++ の (というかプログラミング言語の) ほとんどの機能は抽象化の道具。 ムーブもまた、見かけ上は代入っぽい抽象で扱えるものであっても 実態はもうちょっと速いコードにも出来る (可能性がある)。 >>829 そういう簡単な制御すら抽象化層に押し込められない方がよっぽど駄目。 クルクルパーだと思ってるならなおさら、 簡単な制御なら (いつも間違いなく) 出来ると期待すべきでない。 そんでもって大抵の人間はクソザコで、しょうもない間違いをする。 問題は道具で解決すべき。 852 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 17:03:15.96 ID:7XGFV27+0.net] スマポは言語の機能じゃねーよボケ 853 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 18:38:13.57 ID:GD2dD6IB0.net] >>833 >問題は道具で解決すべき。 ネ申は確かＬＬ言語を創造された 854 名前：デフォルトの名無しさん [2018/09/29(土) 18:45:43.26 ID:Dc4laUcM0.net] ムーブはゼロの発見に次ぐ、人類史上における大発見と言われてるけどな。 ノーベル賞候補の一つにもなってるし。 855 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 18:51:41.19 ID:GD2dD6IB0.net] std::auto_ptr<T>はもともとオブジェクトをムーブしたくて生まれたわけでは無いと思う… 確実な解放の実現が先 ムーブする仕様はあと あとstd::auto_ptr<T>（unique_ptr<T>でも良いが）でも使わないとやってられないｼﾁｭがC++には少なくとも1つある 856 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 18:56:52.23 ID:oWn9MzvpM.net] move元のオブジェクトに対するアクセスがコンパイルエラーになるんならわかるけど、そうじゃないんなら 大層な仕組みを入れなくても単に unique_ptr を言語組み込みで実装すれば済む話だったのでは？ 857 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 19:32:03.30 ID:YVfD+mv1M.net] お前ら江添に負けて恥ずかしくないの？ 858 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 20:26:30.14 ID:1/46iTAZM.net] 全然？ 859 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 21:00:53.02 ID:vc6gAAuZd.net] >>838 それ何が嬉しいんだ？ vector とかどうすんだよ 860 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 22:03:09.07 ID:oWn9MzvpM.net] >>841 moveするのが分かってるんなら最初からvectorごとヒープに作って unique_ptr で持てばいいでしょ 中途半端にガワだけスタックに置く意味がない 861 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 23:45:25.50 ID:OLOWa9QF0.net] move後の元オブジェクトを破壊っていうか破棄しようって提案もあったよ。ちょっと早くなるのだとさ。 862 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 00:04:13.06 ID:kBo12DYt0.net] >>842 ポインターならそもそも copy のコスト安いから move 要らないじゃん 863 名前：デフォルトの名無しさん [2018/09/30(日) 00:20:38.65 ID:aYXyCrkn0.net] それだったら最初から普通にﾎﾟｲﾝﾀでかけよ 864 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 00:57:02.37 ID:GfZkWSkk0.net] この3冊が、神の書！ Linux プログラミング・インタフェース、Michael Kerrisk、2012 C++11/14 コア言語、江添 亮、2015 組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006 865 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 01:40:28.47 ID:CKZYWlYLa.net] >>844 だからmoveいらないって話でしょ C++のムーブセマンティクスがああなったのは中途半端にスタックを使うスタイルが定着してしまっていて今更ポインタ使えというのは無理があるからで、 本来は所有権の管理さえ適切に行えるようになってさえいればムーブなんか要らんよ 866 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 06:43:45.01 ID:C9oWPEnUr.net] C++ Coding Standards って新品で買えないけど代わりになる書籍ありますか？ 867 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 06:48:23.20 ID:d4gXl3Bi0.net] >>847 ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが オブジェクトの解放にガベージコレクタが要る言語になった これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い void bar(int n) { 　std::unique_ptr<Foo> a(new Foo()); 　for (int i = 0; i < n; i++) { 　　func1(a, i);　　// func1(a, 0);で所有権がgone　以降のfunc(a, i)はaの不正アクセス 　} } 不正アクセスにならないように、実際にはこのようなfunc1()にはa.get()でポインタを渡す書き方をする するとfunc1()以下の呼び出しは全部>>845になる 人類に逃げ場は無い 868 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 06:53:57.08 ID:d4gXl3Bi0.net] それにポインタ使え思想だと次のようなケースでBaz::m_c[i]のBar:m_b[j]の:Foo::m_aのアクセスに藻前らどんだけ間接参照するんですかと、 class Foo { 　SomeClass m_a; }; class Bar { 　Foo m_b[100]; }; class Baz { 　Bar m_c[100]; }; 869 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 07:13:40.02 ID:d4gXl3Bi0.net] ちな>>850はm_bやm_cが配列であるため、配列アクセス時の添え字が定数なｼﾁｭでもない限り、JITでも間接参照回数を3以下にはできん 870 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 09:10:22.74 ID:3yGUdTqFM.net] >>849 よくわからんな 848の問題はそれmoveでも一緒だよね 単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ スマポ使えば間接参照はどうしても増えるけど、実際>>850のようなケースで特定の要素だけ所有権捨てたりしないでしょ 所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい コーナーケースのために全てを複雑にする必要はない 871 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 09:21:04.80 ID:d4gXl3Bi0.net] >>852 >所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、 有り得ない仮定すぐる… >>849なケースにおいて、オブジェクトaの生成時点というのは、 ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな… 872 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 09:39:54.40 ID:3yGUdTqFM.net] >>853 自分でも分かってて揚げ足取ろうとしてるんだろうけど、コーディング時に、プログラマがオブジェクトを生成することを意図したコードを記述した時点で、な 873 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 09:46:24.24 ID:d4gXl3Bi0.net] >>854 いやｽﾏﾝ言い方がまずかったそういう意味ではない 確かに >所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、 というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話 func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、 func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、 　1. 呼び出し元（func1()を使う人）がaをコピーしてコピーをfunc1()に渡さねばならない 　2. func1()は呼び出しの度に、aを解放する というのが>>849のコードでn回無駄に繰り返される これを避ける方法はあるっていやーあるが、結局func1()以下の呼び出しは全部>>845になる（か、ガベージコレクタの出番となる 人類に逃げ場は無い 874 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 09:52:25.65 ID:CKZYWlYLa.net] >>855 だからそれmoveでも同じことだよね？ ユニバーサル参照のことを言ってるんだとしたら、あれただの型推論だぞ 875 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 10:03:48.10 ID:d4gXl3Bi0.net] >>856 解放が不要なオブジェクトのmoveは話がちげう この場合、単に生ポインタ（オブジェクトのアドレス）をfunc1()に渡すのと変わらん これはライブラリのインターフェースに現れてもコスト的には問題は無い 元レスのアンカー先>>847は>>855のコストが避けられない主張 876 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 10:07:31.97 ID:d4gXl3Bi0.net] いやすまん解放が不要なオブジェクトでも、所有権を移動した場合は>>855の1のコストは避けられないorz ここは訂正 877 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 10:11:13.08 ID:CKZYWlYLa.net] >>857 スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって言ってるんだけど、そんなに難しい話かなあ 878 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 10:45:39.58 ID:d4gXl3Bi0.net] >>859 >>849、>>850は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない 848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、 846の次の思想を実行に移したら>>855のコストが避けられませんよという話 　1. スタックを使うスタイルはやめるべき（全部スマポであるべき） 　2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん 1は現行C++との比較において、間接参照回数に響く 2は現行C++との比較において、現行C++では避けられるコスト（>>855またはガベージコレクション）を無駄に背負い込むことになる 879 名前：はちみつ餃子 mailto:sage [2018/09/30(日) 10:52:02.74 ID:56zUhffF0.net] >>859 本体のムーブも、ムーブ出来るように書いたらカスタムなスマートポインタみたいになるから、 間接参照が入っちゃうので、なおさら同じではあると思う。 でもまあ、ムーブは抽象化の方法であって、 最終的に実行されることが同じだからなくても良いってのは暴論よね。 880 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 11:10:34.99 ID:f0zM7Hcdr.net] アンダースコアとドットをこの順で必ず含む string があったとして、アンダースコアからドットまでの部分文字列を切り出す処理って一行で書ける？ substr と find_first_of と find_last_of を組み合わせる方法を考えたんだが、 アンダースコアの前を削る; ドットの後を削る; という2行に渡るやり方しか思い付かない 881 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 11:15:56.30 ID:d4gXl3Bi0.net] ちな >スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって これは現行C++においても違う違いがﾜｶﾙ男ならﾜｶﾙ func1()からfunc2()にfunc1()の自動変数aをmoveするとして、かつfunc2()はインライン展開されるとすると、 func2()におけるaのメンバへのアクセスはfunc1()呼び出し時点でのスタックポインタ相対で一発でやれる 一方、aがスマポだったりすると、aのメンバへのアクセスの前に、func1()呼び出しの都度1回はスタックポインタ相対でaのアドレスを得なければならない 882 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 11:27:40.54 ID:fM5IaZg4M.net] オブジェクト本体のメモリのコピーにかかるコストを考慮すればどっちもどっち 883 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 11:54:22.15 ID:u5/6mv7u0.net] >>862 substr じゃなくて、コンストラクタ使えばいいんじゃね string t(s.begin() + s.find_first_of('_') + 1, s.begin() + s.find_last_of('.')); 884 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 12:29:37.73 ID:f0zM7Hcdr.net] >>865 なるほど、ためになります 885 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 12:35:17.89 ID:f0zM7Hcdr.net] >>865 ふと気になったのですが、このコンストラクタの挙動って他の名前の関数で実装されてないんでしょうか？ 886 名前：さまよえる蟻人間 mailto:sage [2018/09/30(日) 12:48:58.63 ID:Eso9UeUod.net] >>867 assign 887 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 13:18:31.87 ID:f0zM7Hcdr.net] >>868 何から何までありがとうございます 888 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 14:15:51.90 ID:QSRvujde0.net] 「rustにもあるし俺らも入れなきゃ」くらいの感覚で 今までのシステムとの統合性の難しさなんかほぼ考えないで入れちゃった機能だから。 c++らしいといえばらしい感覚だけど。 889 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 14:22:42.56 ID:d4gXl3Bi0.net] std::basic_string::find()もイテレータを返すように他のコレクションとの統合性を尊重して欲しいよな 890 名前：デフォルトの名無しさん mailto:sage [2018/09/30(日) 22:56:12.57 ID:SdlFi6Ao0.net] findを実行した対象とは別のstringの同じ位置に何かしたいとき イテレータで返されるとちょっとだけ面倒 まあ大した問題でもないんだけど 891 名前：デフォルトの名無しさん [2018/10/01(月) 17:20:37.02 ID:mKeAnbBU0.net] moveセマンテックが必要になった理由を理解してないのが多くて驚くばかりだな 破壊して良い中間オブジェクトとそうじゃないのとを区別するために必要なのだよ ポインタ使えばmove必要ないとかそういう問題じゃない 892 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 17:40:58.61 ID:qsdLJDx40.net] 元はといえば禿が左辺値参照でもconstつければ右辺値を指せるという曲がった話を始めたのが 評判悪くてC++11でやっとやっとやっとやっとメスが入ったのが本当の理由 893 名前：はちみつ餃子 mailto:sage [2018/10/01(月) 18:05:01.87 ID:hbafP85H0.net] >>873 色んな話題が出てるので混乱してるが、ムーブ不要論を出してる側の *元々の* 主張は >>847 の通り 「ちゃんとした所有権の管理 (たぶん Rust みたいなやつのこと？) が有りさえすれば」 であって、でもそれは C++ ではもはや無理でしょということもわかった上だと思う。 894 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:05:54.55 ID:Gge6W+rt0.net] Cにも欲しいわ Cは参照ないから右辺値指示ポインタで 895 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:09:04.02 ID:qsdLJDx40.net] それを言うなら、右辺値の概念を撤廃すべきでしょ どんな値もポインタで指すことができ、 ポインタで指すことでregister指定を解除されるという変更 896 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:12:32.93 ID:UY4lJdAP0.net] テンポラリーオブジェクトなくすと、一回必ず厳密に生成してから仕様になるので、手間増えると思う。 897 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:40:21.84 ID:Gge6W+rt0.net] 右辺値がないと int i = 0; すら書けなくなるんだが 898 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:50:50.76 ID:qsdLJDx40.net] なんで？ int j; j ^= j; int i = j; 左辺値でも問題ないじゃん 899 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 18:54:00.22 ID:xwh6ZD/vM.net] >>880 苦しいねーw 900 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:00:24.21 ID:Yquio+NL0.net] 0 以外はどうすんの。 901 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:02:25.38 ID:Gge6W+rt0.net] > j ^= j; はい未初期化値を使ったから未定義動作で鼻から悪魔 902 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:04:34.50 ID:Yquio+NL0.net] char buf[1]; int i = (int)(buf[10] - buf[0]); で、i = 10 に初期化される。 903 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:05:56.72 ID:xwh6ZD/vM.net] NaNのときはxorは未定義か、そこまで考えなかったな 904 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:06:32.55 ID:uXaVofwo0.net] >>884 間違った。正しくは： char buf[1]; int i = (int)(&buf[10] - &buf[0]); // i = 10 と等価。 905 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:11:01.98 ID:rJND5eoS0.net] そもそも=の無理やりなオーバーロードや引数に対する暗黙的なattainが問題なんだろう。 しかし元々のcのシンタックスを引き継ぎつつ、上記の問題を解決するのは不可能。 906 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:14:47.64 ID:Gge6W+rt0.net] >>886 10 0 &buf[10] &buf[0] &buf[10] - &buf[0] (int)(&buf[10] - &buf[0]) 右辺値だらけ やりなおし 907 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:19:47.07 ID:qsdLJDx40.net] >>882 別に？ int *j; j = &10; int i = *j; てだけじゃん 10が左辺値だったらって話ね char *j; j = "\n"; int i = *j; て話と何か違うの？ 908 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 19:23:45.27 ID:Gge6W+rt0.net] 10が左辺値ならこれ認めるの？ 10 = 42; 909 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 21:57:05.81 ID:92NEoPQV0.net] お前らがC++で作ったことあるものリスト化して 910 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 22:37:33.40 ID:qsdLJDx40.net] >>890 全然かまわん int a = 10; int b = 10; a = 42; こう言っているに過ぎない 911 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 22:42:30.92 ID:qsdLJDx40.net] >>879 そろそろ答えてもらおうか なぜ右辺値がないと int i = 0; が書けないのか 912 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 23:15:35.29 ID:2m3Ms8fl0.net] >>875 ていうか所有権などという中途半端な概念にオブジェクトの解放を担わせるのは危険か無意味かのどっちかにしかならない 最後までオブジェクトを使いたい人と、そのオブジェクトを所有する人を コードに所有権を明示するスタイルで一致させられるケースは少ない 希ガス 913 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 23:21:45.86 ID:2m3Ms8fl0.net] しかしながら右辺値参照を使うとコードを書く人がオブジェクトの所有権を意識せざるを得ない これを抽象化といわれるとかなり違和感 ※ 個人の感想です 914 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 23:31:19.12 ID:rJND5eoS0.net] 結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。 同期と効率と安全性を全て容易にするってのは不可能なんじゃないかね。 915 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 23:41:31.83 ID:2m3Ms8fl0.net] >>896 >結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。 いや？ オブジェクトの所有権は最初のcallerががっちり掴んでオブジェクトを使うcallee以下は生ポでおk 全てが調和する 916 名前：デフォルトの名無しさん [2018/10/01(月) 23:46:11.02 ID:zfKNS/F/0.net] ｱﾎどもはやっと気付いたか。。。 ｺﾀｴ：最初から普通にﾎﾟｲﾝﾀで書きなさい 　　　unique_ptr、shared_ptr、weak_ptrなんか使ってるﾔﾂﾗは 　　　ｸﾙｸﾙﾊﾟｰしかいない 917 名前：デフォルトの名無しさん mailto:sage [2018/10/01(月) 23:49:34.85 ID:aHxMqUX30.net] >>895 右辺値参照周りを抽象化とか言ってるアホははちみつだけだろ 918 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 00:39:52.22 ID:YrRJAaFSa.net] https://ideone.com/BBhHn8 上のコードで教えて欲しい。 templateでデフォルト引数で関数を指定する場合、わざわざテンプレートパラメーターFuncにdecltype(...)しなきゃいけないのは何故？ 919 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 01:21:04.00 ID:HQVsIoxF0.net] https://ideone.com/JKTYpf testは関数名だから型じゃない 920 名前：はちみつ餃子 mailto:sage [2018/10/02(火) 02:10:18.78 ID:wuORmtyC0.net] >>895 ムーブだのなんだの言ってても、 C++ の言語機能として直接的に有るのは rvalue 参照を区別して受け取れるってだけで、 所有権の管理をキッチリやってくれるわけではない C++ の限界なんだよね。 だけど、なるべくクラス・関数の実装の中に区別を押し込めて隠す道具のひとつにはなるって話。 でも、中途半端にやるなら隠さないで見せた方がマシという論はわかる。 921 名前：はちみつ餃子 mailto:sage [2018/10/02(火) 05:46:40.59 ID:wuORmtyC0.net] 受取る関数の側を上手く作っておけば それを使う側では所有権の移動とかそんなに気にしなくない？ rvalue だったら勝手にちょっと効率的になる (こともある) ねってだけで。 使うときに気にしなくて良いように押し込められるならやっぱり抽象化の道具って言えると思うよ。 922 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 06:04:33.19 ID:YrRJAaFSa.net] >>901 ありがとう。 template<typename Func = int (int)> を template<typename Func> にするとエラーになるのは何故？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef