C++相談室 part151

レス数が900を超えています。1000を超えると表示できなくなるよ。
2020/05/14(木) 11:53:25.59ID:ZPCfyTux
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part150
https://mevius.5ch.net/test/read.cgi/tech/1584975873/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで
2020/07/03(金) 17:43:16.98ID:3KYyPS1e
>>838-839
いや元の質問(>>779)を読めよボンクラ
2020/07/03(金) 17:47:39.31ID:fxIx3skX
>>841
読んだから、高速化のためには、レジスタに乗るかどうかだけで決めるべきじゃないので正確にアドバイスしたが、あなたが理解できないだけだよ。
2020/07/03(金) 17:51:37.27ID:fxIx3skX
>>842
参照を使った場合、参照を介してのメンバアクセスにはコストがかかるので、
むしろ最初にコピーした方が高速になることがあるんだ。
文字列データや、巨大なバッファを持つようなものはコピーしてはいけない。
それは速度だけじゃなく、無駄なメモリー領域の確保まで必要となるため。
もしメモリー効率度外視して、バッファ確保の時間も0だと仮定してよいなら、
大きなデータであっても、参照を介してアクセスするよりもコピーした方が速いことが有る。
ただし、その場合にはキャッシュを超えない程度の場合は、という条件が付くことになる。
2020/07/03(金) 17:58:05.10ID:yyYbA8Zx
引数受け渡しがクリティカルになるような状況ならinline化するかipo最適化するだろ

値だろうがconst参照だろうが、最適化されれば違いはなくなる
845デフォルトの名無しさん
垢版 |
2020/07/03(金) 18:00:47.69ID:36TwtcUk
おまえらは王者の風格が足りない。
偽C++使いめ。
2020/07/03(金) 18:10:53.48ID:fxIx3skX
>>844
>値だろうがconst参照だろうが、最適化されれば違いはなくなる
ダウト
2020/07/03(金) 18:16:59.50ID:3KYyPS1e
>>842
いや安価先をよく見てくださいよ
あなたは僕のリクエスト通りに「大概」の回答をくれたから感謝してます
2020/07/03(金) 18:20:12.77ID:v8523RMt
違いはなくならないこともあるが
普通は無視していい

パフォーマンスが非常に重要なループなら
想像で語らないで実測が基本だし
コンテナのメンバ関数経由でアクセスすることも疑問に思わないと
2020/07/03(金) 18:28:20.50ID:v8523RMt
コピーは非常に時間がかかることもある
構造体やクラスのちょっとした変更で後から増えることもある
参照は極端に速度低下することはない

確実にコピーの方が速い時だけコピーにしておいて
不明な時、判断が面倒な時は参照にしておけばいい

私の中の基本ルールが>>782
最適化が必要なら
参照かコピーかだけにとどまらないもっと大がかりな事まで考える
2択だけなんて事はしない
2020/07/03(金) 18:29:04.81ID:v8523RMt
関数パラメータも同じ
2020/07/03(金) 18:30:44.76ID:33Ox5yaL
アホみたいなチューニングが必要なら、そもそも範囲forを使うのやめたら？
直感と異なるかもしれんが、未だ普通のforのほうが早い。
2020/07/03(金) 18:38:28.00ID:v8523RMt
アホみたいなチューニングってのが意味不明だが
必要ならやらなきゃならん

コンテナ経由ってのがそもそも遅くなる要因
直接ポインタで扱う方が当然速度は期待できる

>>782みたいな基本ルールって
それぞれ自分の中にあると思う
それを外れる最適化がヒツヨウニなるのは極めて稀
稀であったとしても必要な時はある
2020/07/03(金) 18:39:47.81ID:yyYbA8Zx
inline化してたらコピーが速いなんて事象は起こり得ないだろ
854デフォルトの名無しさん
垢版 |
2020/07/03(金) 18:55:06.29ID:36TwtcUk
社内報にアウトライン化による高速化事例が載ってましたが。
2020/07/03(金) 18:58:23.70ID:BB9T+E2r
>>845
うわー、すごい王さまだー。
でもなんで、はだかなの？
2020/07/03(金) 19:23:59.85ID:O03V1sqG
>>840
自称高速化の専門家とやらの妄想は要らんよw
2020/07/03(金) 19:26:52.77ID:O03V1sqG
>>841
自分一人でコード書いてるならテキトーに決めとけ
チームでやってるならコーディング規約に従え
2020/07/03(金) 19:31:01.09ID:C0RVqI6W
高速化の専門家www

じゃあおれも
2020/07/03(金) 19:40:17.44ID:3fEHgumK
他称なら兎も角、自称の専門家って他のことは分かりませんって意味でしかないよね
2020/07/03(金) 19:43:24.17ID:v8523RMt
高速化の基本はアルゴリズム、データ構造
その辺の専門家が参照かコピーかみたいな小さな事を気にするのかな？
どんなコンテナとか無視して
861デフォルトの名無しさん
垢版 |
2020/07/03(金) 20:07:32.86ID:36TwtcUk
他に「夏本番、キラキラ☆コーデ」というのも載ってたけど、関係なさそうだったんで読んでません。
2020/07/03(金) 20:12:17.82ID:v8523RMt
>>854
分岐予測
キャッシュ
関数ポインタ

私がすぐに思い付くのはこのくらい
863デフォルトの名無しさん
垢版 |
2020/07/03(金) 20:13:28.58ID:36TwtcUk
コーディネートではなくコーディングの略ということはもちろんわかっています。

とはいえ、意識の階層が違いすぎて、「あ、これ関係ねーやつだな」って。
2020/07/03(金) 20:14:05.89ID:v8523RMt
インラインの反対はアウトラインなのか
2020/07/03(金) 20:47:01.49ID:ZXpf7qOR
アウトアブライン
out-of-line
866デフォルトの名無しさん
垢版 |
2020/07/03(金) 20:47:30.73ID:36TwtcUk
あ、そういえば。
インライン、アウトラインで思い出したんだけど。

むかしツタヤでDVD探してて、カシラモジ・・・カシラモジ・・・ってカ行探してたんだけど無い。
つぎイ行探しても、あれ？？無いわ？？ってなった。
で、ふとア行見たら・・・アタマモジかよ・・・ありました。
2020/07/03(金) 20:48:50.40ID:oEOxZVHb
陽ライン
2020/07/03(金) 21:33:38.36ID:AnL7VPS4
高速化の専門家って当然ハードわかるよな
わかる、つーか皇帝レベル
869デフォルトの名無しさん
垢版 |
2020/07/03(金) 21:58:20.31ID:36TwtcUk
>>865
オブライアンはアイルランド系の苗字ですね。
2020/07/03(金) 22:43:36.42ID:95N/W1ib
イ行
871デフォルトの名無しさん
垢版 |
2020/07/03(金) 22:53:21.02ID:36TwtcUk
>>870
いろはにほへとです。
無理やりすぎますかね。
872デフォルトの名無しさん
垢版 |
2020/07/03(金) 23:55:09.00ID:2ewiuNjd
>>862
GPU
FPGA
873デフォルトの名無しさん
垢版 |
2020/07/04(土) 00:46:19.57ID:KIBH4SNT
｢慶應卒の学歴なんていらない｣10代起業で成功する子の共通点
https://www.excite.co.jp/news/article/President_35457/
起業で成功するキャリア形成の仕方とは？ 元プロサッカー選手で起業家の鈴木啓祐氏に聞いた
https://sogyotecho.jp/career-development/
【アプリ開発で起業】必要な心得とマネタイズ方法のすべて
https://www.dreamgate.gr.jp/contents/column/application-development
学生起業家が開発、「人を軸に本を探すアプリ」とは？読書通じて「考える力」養って
https://newswitch.jp/p/20168
島田商高生がアプリ考案、発表　ＩＣＴ起業家育成プログラム
https://www.at-s.com/news/article/local/central/730010.html
医師コンビが「治療用アプリ」で起業、禁煙に続き高血圧治療アプリを開発
https://diamond.jp/articles/-/229375
好きが高じて“カレー起業”、キャッシュレス決済アプリ「TOKYO MIX CURRY」の挑戦
https://diamond.jp/articles/-/215868
2020/07/04(土) 09:49:13.31ID:sAcpDZbT
>>828
俺もちょいちょい喧嘩してるけど今回関係ないぞ
2020/07/04(土) 19:16:06.20ID:rNblEJCx
浅はかな推測が外れまくったという
珍しくも何ともない現象だな
2020/07/05(日) 07:47:21.10ID:3TMy8TU+
std::vectorのstd::shared_ptrを返すメソッドGetHoge()があるのですが、
for (auto e : *GetHoge())
でループすると要素があるにも関わらずループしません
auto t = GetHoge();
for (auto e : *t)
とするとループします
これは何か違いがあるのでしょうか？？
MSVCです
2020/07/05(日) 09:34:39.04ID:M7eGAoZB
msvcならeとかtにカーソル合わせればどういう型になってるかかわかるんじゃないの
2020/07/05(日) 10:04:45.65ID:cAnzpYmx
無駄にコストを上げる必要は無いと思う
879デフォルトの名無しさん
垢版 |
2020/07/05(日) 11:12:16.02ID:Sc6x6nbH
イテレータ型にしなきゃいけないんじゃない？
2020/07/05(日) 11:57:29.61ID:cm1+apW3
>>876 さんの質問への直接の答えじゃないけど、
typeid(e)::name() とかで auto の解釈を見れば何か分かるんじゃないかな。

特定の場合に auto はどのような型を生成するか、っていう
一般的な情報って言うか規則もどこかで見られるのかも知れんけど。
2020/07/05(日) 13:00:13.16ID:S3hYTv6M
>>876
範囲for文の中ではauto&&の参照で範囲オブジェクトを束縛してくれるんだけど
上の場合は束縛されるのは*GetHoge() （＝中身のvector）であって、GetHoge()の戻り値そのもの（＝shared_ptr）は束縛されない
なのでshared_ptrはループに入る前に破壊されてしまって、参照カウントが0になると中身も破壊されてしまう

下の場合は戻り値のshared_ptrをtで確保してるから大丈夫ってこと
882デフォルトの名無しさん
垢版 |
2020/07/05(日) 13:03:35.81ID:NbYPgepr
>>881
なるほど
2020/07/05(日) 13:16:51.38ID:wYW3xnyi
C++はますます書いてあることと動作の関係を掴み難くなりつつ
あるな！
2020/07/05(日) 15:02:20.05ID:G8wpw7EE
>>876
最初の書き方の場合、GetHoge() の戻り値は、一時オブジェクト。
一時オブジェクトの生存期間は、その部分式を含んだ完全式の終わりまでとされている。
GetHoge()が書いてある場所は、for ブロックの開始時に、最初に一度だけ評価されるが、
完全式としては、その時点で終わっている。
だから、関数戻り値の一時オブジェクトの生存期間は、forブロックに入る直前に終わってしまう。
戻り値の型は、shared_ptr<vector<T>>で、この中身を参照している shared_ptrが全て
消失した時点で中身まで deleteされる。
そのため、forブロックの中では、もはや、vector<T>が削除されてしまっているということらしいね。

2番目の書き方の場合は、shared_ptr が変数 t にコピーされているので、参照カウンタが1つ分残っている。
そのため、それが指している vector<T> のメモリブロックも削除されずに残っている。

というわけで、ループしているのに結果がおかしいというのは分かるが、全くループしない理由は余り分からない。
2020/07/05(日) 15:10:48.51ID:0KU/lBNo
>>883
バカ用じゃないってだけ
2020/07/05(日) 15:37:26.46ID:OSntWRwy
というか>>881の指摘通りの場合、GetHogeで初めてvectorを生成してるか
自身を元に新たなshared_ptrを作って返してることになるんだが
だいぶおかしな設計じゃね？
887デフォルトの名無しさん
垢版 |
2020/07/05(日) 16:19:00.25ID:NbYPgepr
痛レータ
2020/07/05(日) 16:52:53.28ID:/j2YKhHE
>>883
ｸｰﾙﾊﾟﾙﾙﾊﾟｸﾙﾘﾝﾊﾟ();　　←関数
2020/07/05(日) 17:09:54.17ID:S3hYTv6M
>>884
ちょっと間違ってる
範囲for文はここで書いてるように「同等な書き換え」がされて、範囲オブジェクトはここの例で言うauto&& __rangeに束縛される
https://en.cppreference.com/w/cpp/language/range-for
そして、__rangeに束縛されたものが一時オブジェクトであれば、参照束縛による寿命の延長でforブロックの終了まで生存する

だからこういうのは問題ないのよ
for(auto a: std::vector<int>{1,2,3})

あと最後に関しては破壊されたvectorを使っちゃってるから未定義動作で何が起きても文句は言えない
メチャメチャな値を取り出そうと、全くループしなかろうとその時の気まぐれよ

>>886
同意。Getという名前は不適切だな
2020/07/05(日) 17:14:11.09ID:G8wpw7EE
>>89
こんな機能があったとは:

Temporary range expression

If range_expression returns a temporary, its lifetime is extended until the end of the loop, as indicated by binding to the forwarding reference __range, but beware that the lifetime of any temporary within range_expression is not extended.
2020/07/05(日) 18:01:59.74ID:LGYlGSYG
昔はC++は複雑怪奇、C#はシンプルで分かりやすいって感じだったけれど、
今はC#の方が仕様拡張で複雑になってきて相対的に大差なくなって来てる気がする
892デフォルトの名無しさん
垢版 |
2020/07/05(日) 18:04:58.41ID:Sc6x6nbH
いろいろ考えたらC++にあるアレが必要になったんだよ
アレだよアレ
わかるだろ
2020/07/05(日) 18:20:14.04ID:/j2YKhHE
本来標準ライブラリーで済むものまで言語仕様に入ってやがる
それというのも標準ライブラリーがしょぼくてかつ改善が入らん
あっちはだれがやってるんだ
2020/07/05(日) 18:31:21.12ID:wYW3xnyi
非バカの>>885や>>888は当然コード見た瞬間最初から全部わかってたんですねわかります、
2020/07/05(日) 19:22:37.86ID:3TMy8TU+
皆さんはありがとう御座います
GetHogeは実際はEnumHogeで内部でstd::shared_ptr<std::vector>を生成して返すメソッドです

一時的なオブジェクトで書き方の違いで結果が変わるなんて知りませんでした
とりあえず、変数に代入します
2020/07/05(日) 19:59:22.90ID:G8wpw7EE
>>889
>参照束縛による寿命の延長
これは、ranged for 以外でも、一般的に働く機能ですか？
C++ 11から有りましたか？
それとも最近入りましたか？
2020/07/05(日) 20:33:35.81ID:jWvpOogX
>>896
C++03 以前から有ったよ。
2020/07/05(日) 21:12:13.70ID:wYW3xnyi
ていうか
>>889
>あと最後に関しては破壊されたvectorを使っちゃってるから未定義動作で何が起きても文句は言えない
>メチャメチャな値を取り出そうと、全くループしなかろうとその時の気まぐれよ
mjd？！
{
　auto t = GetHoge();
　for (auto e : *t) {
　　...　　　// (A)
　}
　// (B)
}
ならt（GetHoge()が返したshared_ptr<vector<T> >は(B)になるまで生存するから
(A)において*tの要素を参照する（auto &&）することは全く問題無いんじゃ…
2020/07/05(日) 21:15:51.36ID:wYW3xnyi
訂正orz,
誤： (B)になるまで生存する
正： 少なくとも(B)になるまでは生存する（参照カウンタが0より大の状態を保つ）
2020/07/05(日) 21:20:48.10ID:0KU/lBNo
>>894
イヤミになってない
2020/07/05(日) 21:24:12.71ID:wYW3xnyi
ていうか>>889の「最後に関しては」は実は
>というわけで、ループしているのに結果がおかしいというのは分かるが、全くループしない理由は余り分からない。 (>>884)
を指していたりする？　だとしたらｻｰｾﾝ；。n_

for文のイテレータがvectorを指しているのに対して、vectorを保持するshared_ptrの破棄タイミングは確かに
forの前でも後でも有り得るﾖｶﾝ、
2020/07/05(日) 21:30:37.86ID:kFjTOHVy
C++は局所的に動作を想像できない場合が多いのがなぁ。
バカじゃなけりゃマクロ使いまくったCコードも理解できるかというとそうじゃないだろうと。
2020/07/05(日) 21:36:58.75ID:wYW3xnyi
もっとも
>for (auto e : *GetHoge()) { ... }
このコードで動作が不定（未定義動作）になるのはGetHoge()が返したshared_ptrの参照カウンタがきっかり1だった場合であって、
2以上だったらきちんと回るんｼﾞｬﾏｲｶ、
そう考えるとなかなか>>876のお題は味わい深い…

>>900どう？
2020/07/05(日) 21:37:43.23ID:Bskedq4a
腐った代入オペレータかかれるだけで悲惨なことになる
2020/07/05(日) 21:42:04.47ID:wYW3xnyi
（上の話に限って言えばvector<T>のTに間してどれだけ腐った代入オペレータが定義されていようとも）
別に
2020/07/05(日) 22:06:13.63ID:0KU/lBNo
>>903
おまえ頭悪いなって
俺が何の下支えもなく言う場合と同じだ

俺は瞬間でもないが落ち着いて追えるケースでしかない
おまえさんは絶望感でも持ったのか？
2020/07/05(日) 22:08:49.40ID:0KU/lBNo
しかしまあ歳は取りたくないと思ったな
全盛時の俺にはありえんことが相次いで起きている一例だった
2020/07/05(日) 22:35:02.11ID:S3hYTv6M
>>901
そうだよ
2020/07/05(日) 23:23:07.13ID:7RTbKb77
C++のラムダって、Javaとかみたいに1文だけの場合にreturn省略できないんですかね？
[](auto a, auto b){ return a + b; } → [](auto a, auto b) { a + b } みたいな感じで。
2020/07/05(日) 23:59:55.29ID:S3hYTv6M
今はムリ
検討はされてるから将来的に出来るようになるかもしれない
2020/07/06(月) 00:06:22.43ID:J5KuSvPS
>>907
この程度のことが落ち着いて追わねば分からないというのは
藻前は衰えたのだ
2020/07/06(月) 00:08:16.95ID:Cb7lpAWE
>>909-910
https://mevius.5ch.net/test/read.cgi/tech/1584975873/864
がいよいよ公認されるってわけですか…微妙な文法ですね
2020/07/06(月) 05:27:19.13ID:Js6m+wFY
Rust に慣れてくると C++ で return を書くのを忘れることもある。
2020/07/06(月) 07:02:55.73ID:oajwJTo1
>>910
ありがとうございます。C++23ぐらいを期待します
2020/07/06(月) 07:29:08.62ID:hCVItazY
>>895
てか結果を返すだけなのにスマポに入れるとか、
呼ばれる関数が結果をどのように管理するかにまで口出しするのはどうかと思うけどね
2020/07/06(月) 07:43:23.12ID:tvsN32eC
>>911
my powers are weak old man.
2020/07/06(月) 21:29:07.26ID:J5KuSvPS
非バカの要件にコード見た瞬間最初から全部ﾜｶﾙというのが入るということは
>>894で宣言して合ったのに対し別段オブジェクションをつけるでもなく
>俺は瞬間でもないが落ち着いて追えるケースでしかない
とだけ言ったのだから彼は自ら非バカではないと告白したのである
漏れの有り様の批判に繋げられても困る
2020/07/06(月) 21:39:04.45ID:Edtf8jlD
>>895です
>>915
でも、スマポに入れないで返す場合、例えば、受け取った側で他で色々使いまわすから受け取った側でいちいちスマポ作る
ってことでしょうか？？
というか、一般的なライブラリ作る場合どうすればいいんでしょうか？？
std::shared_ptr<std::vector<YYY>>XXX::EnumYYY()
とりあえず、スマポでくるんで返してあげれば受け取り側でいかようにもできるからいいのかなと思ってるのですが。
2020/07/06(月) 22:16:12.21ID:Edtf8jlD
std::vector<YYY>で返して
std::vector<YYY> XXX::EnumYYY ()
で、受け取った方で他でスマポにしようということで
auto yyy = x.EnumYYY();
auto ptr = std::make_shared<std::vector<YYY>>(std::move(yyy));

とかやればオーバーヘッド少なくスマポ作れるんです?
2020/07/06(月) 22:36:37.36ID:J5KuSvPS
記憶管理という本来隠すべき実装の詳細（と多くの人が考える事柄）を
使う人が意識せねばならな続けるのは嫌すぐる、
2020/07/06(月) 23:09:10.15ID:J5KuSvPS
getterがshared_ptr<T> pを返したとたん、pの寿命と*(p.get())の寿命の二重管理の責務が利用者に行く
>>876の真の原因はこれ

getterがオブジェクトのディープコピーを返したらそんな二重管理は生じないで済む

getterが仮にオブジェクトXの参照を返す仕様だとしても、Xの実体を保持するオブジェクトのY寿命と
getterを呼ぶタイミングの二重管理以上の手間にはならない

結局shared_ptr<T>を返すインターフェースは不恰好さだけが残る
2020/07/07(火) 02:12:04.06ID:bKZU32Ct
>>921
*(p.get()) の寿命は p の寿命と同じかそれ以上という関係であって別で管理できるものではなく「二重管理」にはならないでしょ。
この関係がある状態で *(p.get()) の寿命を期待しているところで p の寿命を保持していないのが >>876 の間違い。
本当に所有権の共有が必要ならあり得るインターフェースだよ。

でも >>919 を見る限り所有権の共有は必要なかったみたいなので、素直に std::vector を返せばいいよ。
2020/07/07(火) 05:32:28.01ID:Njz9GOYM
>>922
2行目で述べている、利用者がしくれば危険性が生じるという事実と
1行目の「「二重管理」にはならないでしょ」という主張は矛盾してねえが、

本当に所有権の共有が必要ならshared_ptr<T>を使うのはアリだが、shared_ptr<T>が保持する
Tの実体のみに興味がある利用者に対してはshared_ptr<T>を使っていることを
クラスUで隠蔽する方が良い
Tが持っている演算を全てクラスUからTに委譲し、UをT同然に使えるようにするのがbest
そこまでやる手間が嫌という理由でUにTを返すメソッドU::get()を備えさせる簡易手段に訴えたとしても、
Uの定義だけ見れば循環参照にならないことをUの提供者が保証できるから
（Tがジェネリックな型だった場合の）Uの利用者やプログラム全体のメンテナーに地雷原を歩かせずに済むメリットがある
2020/07/07(火) 06:29:56.58ID:Njz9GOYM
ちゅか明白すぎて激しく書き忘れたが、オブジェクトTのグローバルな所有権の共有が必要な場合、
shared_ptr<T>が保持するTの実体へのアクセスの排他制御を行わねばならないが
shared_ptr<T>はこの点なんのサポートもしてくれない（せいぜい自身が使う参照カウンタの排他を行うだけ
なので、Tの排他はshared_ptr<T>をwrapしたクラスUが行う必要があり、かつ行えば十分
この点一つとってもクラスUを設けずshared_ptr<T>をTの利用者に直接返す設計のﾀﾞﾒさ加減がﾜｶﾙ
gdgdだ、
2020/07/07(火) 06:31:29.19ID:Tvc5gvFF
>>921の通り

getで実体を返すのが一番
これを管理方法はgetする側が決めれば良い

コストが重要で
オブジェクト内部のvectorの参照やポインタを返す場合はその寿命はオブジェクトと同じで良い
2020/07/07(火) 06:48:05.06ID:hl3O6vw8
>>917
おまえさんはまだこっちの質問に答えてないぞ
絶望感でも感じたのか？

shared_ptrを使ってるのにディープコピーとか言い出してて
相当テンパっている様子は窺えるのだが
2020/07/07(火) 07:19:57.60ID:Njz9GOYM
漏れの心の内面がC++の規格に反映されているわけでないのだから
聞くだけ無駄くね？
2020/07/07(火) 08:11:38.64ID:GpjZMZK2
>>926
ようわからんが、>>921がディープコピー云々言ってるのは、ようするに実体を返せってことでないの？

てか俺が管理云々言い出してややこしくさせたかもしれんけど
俺もこの場合vectorそのものを返すべきだと思う、実体を返して解放忘れでリーク、とか有り得ないんだし(何のためのスマポなのかをよく考えるべき

スマポ大好きで何もかもスマポで扱いたいんなら別だがw
2020/07/07(火) 08:43:44.25ID:kKeNsU/l
なんか……

戻り値をどうするかは戻り値の所有権&管理責任がどちらにあるのかを表しているんだから、「必ず実体を戻すべき」とかいうのは考え足りないだろ。
>>918ならshared ptrかunique ptr(所有権を譲渡する場合)で返すのは普通にありえる。

>>924みたいなのはshared ptrの所有権を侵して実体を破壊しているわけだから、そのコードを書いたやつをぶん殴るべき案件。
そもそも規格的に未定義じゃないの？
930928
垢版 |
2020/07/07(火) 09:14:32.95ID:D+WevL4Y
>>929
>「必ず実体を戻すべき」
俺はそんなこと言ってないけども
shared_ptrのshared_ptrの(無限ループ)でも返せというのか
>>885を読み直せ、結果を返してるだけなんだぞ？
しかもそれで参照カウントがゼロになるって言ってるんだがw
意味わかるよな？
2020/07/07(火) 12:07:28.86ID:/8q6WRwj
参照カウンタがゼロになることから
getのたびにvectorを作成しており
その管理を呼び手に委ねてることがわかる

こんなものは素直に実体を返せば良い
呼び手がスマポで管理することも出来るし
特に管理せずスコープを抜けた段階で自動で破棄することも出来る
2020/07/07(火) 12:43:21.61ID:D+WevL4Y
あ、すまん>>885じゃなくて>>895だった
2020/07/07(火) 20:34:36.65ID:fHFPpwji
内部で管理してるオブジェクトの見せ方は色々あって難しいけど
今回の場合は新しく作ったvectorでしょ？そんなもんそのまま呼んだ奴にくれてやれよ
無駄な包装紙付けられたり、後からやっぱ俺のものとか言い出されたらウザいだろ？いらん未練残すな
2020/07/08(水) 07:03:23.04ID:SF9V14yC
vector自体がムブコン持ってるんだから
2020/07/08(水) 08:37:14.85ID:qWtjrxlX
この場合ムーブじゃなくてRVOな
2020/07/08(水) 09:04:46.82ID:eJ60/BI8
>>935
「この場合」って、実装見ないとわからない話では？どっかで実装の話出てたっけ？
2020/07/08(水) 09:11:01.56ID:qWtjrxlX
>>936
>>876
2020/07/08(水) 10:07:11.80ID:SF9V14yC
>>935
？？？　最適化は関係ねえだろ
2020/07/08(水) 10:18:43.63ID:eJ60/BI8
>>937 呼び出し元しか書いてないやん。
2020/07/08(水) 10:20:00.04ID:qWtjrxlX
あー、調べてみたらNRVOは未だに保証は無いのな
まぁ何にせよスマポにする理由は無い
レス数が900を超えています。1000を超えると表示できなくなるよ。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況