C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

◆QZaw55cn4c · 2021/06/27(日) 15:44:56.12

>>539
ごめんなさい誤りましたので謝りますからその刑だけは平にご容赦を‥‥

**デフォルトの名無しさん** · 2021/06/27(日) 15:47:12.10

>>535
保証されてるから支障はない。エンディアンが違うデータだって読み書きできる。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 15:54:09.98

>>541
データがリトルエンディアンなのかビッグエンディアンなのかわかっていればね。
C++ が単にメモリ上のデータを書き出したときに、それがどっちなのか、
(言語としては) 保証してないって話をしてるんだよ。

**デフォルトの名無しさん** · 2021/06/27(日) 16:14:20.16

C++20でstd::endianが使えるようになるけど

◆QZaw55cn4c · 2021/06/27(日) 16:39:33.97

シェアの高かった 68 系かインテルザイログ系か、の二分図がここにも残っているのですか
もう UTF-8 のようなエンディアンに依存しないバイナリが優秀だ、という価値観にするべきかと

**デフォルトの名無しさん** · 2021/06/27(日) 17:01:10.06

インターネットのプロトコルはビックエンディアン
USB等のPC系発祥のデバイスはリトルエンディアン
この辺はもう変更しようが無いだろ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 18:13:48.48

>>544
ここでのトピックは >>530 に対しての反論。
メモリ上にあるバイト列には保証がないからなんらかの明確な
データ交換用フォーマットに変換する処理が必要という話で、
出力先のデータ交換用フォーマットが BE か LE かなんていう以前の段階。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 18:17:55.59

ファイルに書き出すにあたって「エンディアンの変換が不要なら」という前提を置きたくねぇなぁという話だな。
パディングとかも入るかもわからんし。

◆QZaw55cn4c · 2021/06/27(日) 19:47:44.56

>>546
であれば、私はどちらかというと >>530 の味方側ですね、>>530 がそう意図しているかどうかは不明ですが、処理系のエンディアンを仮定することなくコードを書くことは可能だったと記憶しています。‥‥①

ただ同時に、確かにパフォーマンスの点で過剰な不利を承知で >>537 を再提示するべきかな
つまり、>>537 みたいな画像フォーマットはありました PPM/PGM/PBM
https://mevius.5ch.net/test/read.cgi/tech/1434079972/73　
このコードは①を検証したものだったかと遠い記憶に残っていますね

あ、罰ゲームは勘弁ね、私だってエロ画像は見たい‥‥https://www.youtube.com/watch?v=TvDWJif1sSI

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 20:29:20.98

>>548
だからそういうコードが書けるかどうかという話じゃなくて
書かなきゃなんない (書くべき) ねという話なんだってば。

◆QZaw55cn4c · 2021/06/27(日) 20:58:56.14

>>549
それは失礼しました

**デフォルトの名無しさん** · 2021/06/27(日) 22:44:17.18

>>542
C++だって読もうとするバイナリデータのエンディアンを事前に知らなきゃならんのは変わらんだろ。
自分で書いたものを読むならエンディアンが一致するのはあたりまえ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 23:46:30.32

>>551
> エンディアンを事前に知らなきゃならんのは

知らなきゃならないがわからん (保証されてない) のだという話をしている。
C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。

言語が何であれデータフォーマットが固定されてないとどうにもならん。

**デフォルトの名無しさん** · 2021/06/27(日) 23:53:27.71

>>552
それは言語関係ない話だろ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/28(月) 00:31:47.85

>>553
言語に関係あるという話はしてないよ。

**デフォルトの名無しさん** · 2021/06/28(月) 00:34:04.32

Javaはメモリモデルも明確に決まってたんじゃないかな

**デフォルトの名無しさん** · 2021/06/28(月) 02:47:25.75

多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ！

**デフォルトの名無しさん** · 2021/06/28(月) 03:12:57.95

どうしてもバイナリファイルが良いという向きは、
パディングとかもfwrite()とfread()で取り扱い得る
といっても単に適当なサイズのバイトの配列として読み書きして
メモリ上でご使用のアーキテクチャーに合わせることになるが
fwrite()とfread()を使わなければもっとﾏｼになるという類の話ではない

**デフォルトの名無しさん** · 2021/06/28(月) 03:44:20.73

別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか

◆QZaw55cn4c · 2021/06/28(月) 07:17:27.29

>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします

**デフォルトの名無しさん** · 2021/06/28(月) 07:48:39.66

>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。

**デフォルトの名無しさん** · 2021/06/28(月) 08:30:45.47

これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい

**デフォルトの名無しさん** · 2021/06/28(月) 09:09:23.58

僕はノンバイナリーだから読みたくないです

**デフォルトの名無しさん** · 2021/06/28(月) 09:56:34.91

こんどはバイナリに噛み付いてるキチガイがいるな

**デフォルトの名無しさん** · 2021/06/28(月) 11:09:48.91

標準ライブラリのみであれば車輪の再発明しか手段がない？

**デフォルトの名無しさん** · 2021/06/28(月) 12:52:58.19

MsgPack は json と同じで無駄が多い

**デフォルトの名無しさん** · 2021/06/28(月) 12:59:22.39

>>558
温暖化詐欺SDG詐欺と手口が一緒だな

**デフォルトの名無しさん** · 2021/06/28(月) 13:35:34.04

>>559
WSL2, Ubuntu 18.04 では、

apt list --installed libxml2

libxml2/bionic-updates,bionic-security,bionic-updates,bionic-security,
now 2.9.4+dfsg1-6.1ubuntu1.4 amd64 [インストール済み、自動]

**デフォルトの名無しさん** · 2021/06/28(月) 13:52:30.89

Comparisonて何て読むの？
コンパリソン？

**デフォルトの名無しさん** · 2021/06/28(月) 14:55:11.19

msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット

**デフォルトの名無しさん** · 2021/06/28(月) 14:56:29.69

>>568 こんｐぇぁりｚん https://www.google.com/search?q=comparison

**デフォルトの名無しさん** · 2021/06/28(月) 15:26:12.03

>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

**デフォルトの名無しさん** · 2021/06/28(月) 15:26:13.01

>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

**デフォルトの名無しさん** · 2021/06/28(月) 16:13:11.20

>>569のお勧めは何？
理由もセットで教えて頂戴。

**デフォルトの名無しさん** · 2021/06/28(月) 16:32:50.30

「モジュール」はC++で作られたパッケージを配布しやすくしますか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/29(火) 00:03:30.47

>>560
そうだよ。その当たり前の話をしてるんだよ……。

互換性の問題というのは内部的なものなら問題が起きたときに修正すればいいが、
外部に出ているデータはそれに皆が合わせなければならない仕様と化すので
特定の C++ 処理系 (実行環境) でなら処理できるけど
出力されたデータフォーマットの詳細はわからんし処理系のバージョンがちょっと変わったら変わるかもしれん
というのでは困るやんというごく普通の話。
(もちろん普通の処理系はちょっとバージョンが更新されたくらいでは
バイナリ互換性をあまり壊さないように配慮するのが普通ではあるけど。)

**デフォルトの名無しさん** · 2021/06/29(火) 00:15:58.47

>>575
いつのまにか話ずらしてんな。

>>535
>読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。

言語上の型とバイナリの対応付けはPerlでもPythonでも保証されてるんだよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/29(火) 00:20:30.40

>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。

**デフォルトの名無しさん** · 2021/06/29(火) 08:12:22.23

>BE か LE かわかっていない状況

これの意味だが

・全く何の情報もない状況
→どんな言語を使おうが正しく読める保証がないし論ずるだけ無駄。

・>>552の「C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。」状況
→「自環境のエンディアン」で読めるのはC++でもPerlでもPythonでも同じ。

**デフォルトの名無しさん** · 2021/06/29(火) 08:29:00.28

>>573
方法はともかく、普通にビット列かバイト列のレベルで仕様を決めてその通りに読み書きすりゃいいんじゃない
C++プログラマなら生データの扱いは得意でしょ
とはいえ手間がかかるしミスを生じやすいのも事実なので、めんどくせえ今すぐ読み書きしたいってだけならprotobufとかavroとか他にも色々あるよ
msgpackとの大きな違いはスキーマの有無で、スクリプト言語じゃなきゃスキーマはあったほうが便利だし、一般に実装が高速になりやすくデータサイズも小さくできる

**デフォルトの名無しさん** · 2021/06/29(火) 08:38:20.49

>>579
「他人含めた仕様の強要」という観点が抜けてない？
それに、何回車輪の再開発させるつもりだよ。

**デフォルトの名無しさん** · 2021/06/29(火) 08:57:28.61

>>580
強要したいならちゃんと仕様書書いて押し付けるだけの話
実装が面倒ってんならそれこそprotobufのようなスキーマのある汎用フォーマットならスキーマさえ書いとけば大抵の言語でserde用の型の自動生成までやってくれるよ
その点で言えばmsgpackは所詮mapなんで、仕様を強要したいなら別途仕様書が必要になるよ

**デフォルトの名無しさん** · 2021/06/29(火) 10:54:24.87

実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない

**デフォルトの名無しさん** · 2021/06/29(火) 12:00:43.57

他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない

**デフォルトの名無しさん** · 2021/06/29(火) 13:20:29.38

>>560
Perlでバイナリを扱うのは物凄く大変だった。
さまざまな自動変換がかかってしまうので、結局どうなるのかが分からない事が
多かったから。
例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
なってしまったり、物凄く難しかった。
ASCIIコードの数値番号を取得したいと思っても、結果が数値の入った文字列に
なったりとか、よく分からない事が多かった。
何を何に変換しているのか、めちゃくちゃ難しかった。
それがRubyになって、素直な感じになった。

**デフォルトの名無しさん** · 2021/06/29(火) 13:23:14.00

>>584
16進数も複雑だった。
単に表示したいために16進数の文字列に直したら、どこかで勝手に数値として
解釈されていつの間にか思いもよらぬ「もの」に変化したりとか。
それで、バイナリや文字を細かく扱い際には、如何にCが楽であるかを思い知った。

**デフォルトの名無しさん** · 2021/06/29(火) 14:44:15.68

Cというか、それは最早動的型付けか静的型付けかとかの話では

**デフォルトの名無しさん** · 2021/06/29(火) 15:11:46.24

>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。

**デフォルトの名無しさん** · 2021/06/29(火) 15:25:41.01

pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。

**デフォルトの名無しさん** · 2021/06/29(火) 15:37:31.39

>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。

**デフォルトの名無しさん** · 2021/06/29(火) 18:21:23.30

強気なこと書き込む人はだいたい経験浅い

**デフォルトの名無しさん** · 2021/06/29(火) 18:35:19.68

ボカァもうOOPは捨てた！ｗ

◆QZaw55cn4c · 2021/06/29(火) 18:54:36.80

>>578
あなたはちょっと残念な人ですね

実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①
①の証拠は >>548
ことほど左様に、処理系に独立して LE/BE を書き分けることができるのなら「～するべき」とかいう「べき論」は無意味でしょう
多分、はちみつ氏は①を失念していたのでしょう、べき論なんて振り回しても無駄なのに、あいかわらずべき論に拘泥するところなどは「ダメリカ様が守ってくださる！」的な馬鹿左翼並の振る舞いですから、そろそろあきらめるべきでしょうね

**デフォルトの名無しさん** · 2021/06/29(火) 21:05:01.01

>>592
？
なにか別の話とごっちゃにしてないか？べき論って？？？

>実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①

C/C++じゃなくてもPerlやPythonだってLE/BE書き分けられる手段は用意されているって話をしていただけなんだがな。

**デフォルトの名無しさん** · 2021/06/29(火) 21:08:28.05

>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。

>例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
>文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
>なってしまったり、物凄く難しかった。

これなんかまさにそうだな。

**デフォルトの名無しさん** · 2021/06/29(火) 23:39:33.94

この話のゴールどこ？

**デフォルトの名無しさん** · 2021/06/29(火) 23:59:54.04

pack/unpack使え

**デフォルトの名無しさん** · 2021/06/30(水) 00:03:10.10

use strict
use warnings;;
use Carp;
use utf8;
#use Encode; # ウィンドーズのパスを使う場合必須
our $os_enc = 'cp932';
binmode STDIN, ":encoding($os_enc)";
binmode STDOUT, "encoding(%os_enc)";

でエラーかどうかは
(エラー出ない条件) or croak "*** ERR ***"; 　# 改行は付けない

にしてpack/unpackを使ったら何も起きない

**デフォルトの名無しさん** · 2021/06/30(水) 00:07:43.06

Encodeは日本語入りのパスとか$ARGV[]とかをutf8にしたり戻したりするのに使う
コマンドプロンプトの文字をutf8にしたら実はEncode要らんかもしれんがそこまでは知らん

**デフォルトの名無しさん** · 2021/06/30(水) 00:40:50.04

Perlの特定の某なんか出されても知らんがな……

**デフォルトの名無しさん** · 2021/06/30(水) 03:10:15.08

Perl Python PHP Java C# EcmaScript TypeScript Javaくらいは流石に教養だろうさ。

**デフォルトの名無しさん** · 2021/06/30(水) 07:38:15.64

func の返り値を変数 hoge に受けるときって
auto hoge = func();
auto& hoge = func();
auto&& hoge = func();
のいずれにおいてもオブジェクトの再構築 (コピー) は行われないって思って良いんですよね？

**デフォルトの名無しさん** · 2021/06/30(水) 10:58:31.75

**デフォルトの名無しさん** · 2021/06/30(水) 11:13:43.85

>>601
c++17：値のコピー省略を保証、て奴かね。

戻り値が右辺値かどうかで変わるんじゃない？

**デフォルトの名無しさん** · 2021/06/30(水) 12:11:32.93

関数の戻り値は必ず右辺値のはずだが。

**デフォルトの名無しさん** · 2021/06/30(水) 12:19:35.40

んなこたーない

**デフォルトの名無しさん** · 2021/06/30(水) 12:29:48.99

参照返し……と思ったけど、
参照て右辺値だっけ？左辺値だっけ？

**デフォルトの名無しさん** · 2021/06/30(水) 13:29:54.24

関数の戻り値は、戻り値の型が左辺値参照で有る場合だけは左辺値で、
それ以外は右辺値らしい。

**デフォルトの名無しさん** · 2021/06/30(水) 13:34:03.56

>>606
戻り値の型が右辺値参照の場合、関数呼び出しの結果は、xvalueだが、分類上は、右辺値でもあり、glvalueでもある。
戻り値の型が左辺値参照の場合、関数呼び出しの結果は、左辺値。
戻り値の型が参照型でない場合、関数呼び出しの結果は、prvalueで、右辺値。

prvalue = 純粋右辺値。
glvalue = 一般化左辺値。
xvalue = 消えかかっている値。謎の値とも言われる。

**デフォルトの名無しさん** · 2021/06/30(水) 13:39:20.73

>>601
一番上の書き方だと、少なくとも move になる。
下の二つは、moveもcopyも行われないで、アドレスだけが参照型変数に
入るのだと思う。

**デフォルトの名無しさん** · 2021/06/30(水) 14:18:47.26

>>609
funcの戻り値型が左辺値参照の場合moveにはならんのでは？

**デフォルトの名無しさん** · 2021/06/30(水) 14:56:49.27

>>610
その通りで、コピーコンストラクタが呼び出される気がする。
「少なくとも」と書いたのは、効率面で最低でも move が生じる
という意味で書いたつもりだった。

**デフォルトの名無しさん** · 2021/07/03(土) 19:40:59.20

くっそ素朴な疑問だけど
「operator>>」
って声に出して読むときどうしてる？

独学/個人開発なので他の人から聞く機会がない

**デフォルトの名無しさん** · 2021/07/03(土) 19:42:38.50

右シフト記号？

**デフォルトの名無しさん** · 2021/07/03(土) 20:04:04.63

入力オーバーライドとか？　うーん・・・ダブルGT！

**デフォルトの名無しさん** · 2021/07/03(土) 20:04:56.30

個人的には「おぺれーたーだいなりだいなり」だな
他人には言ったことないけど

**デフォルトの名無しさん** · 2021/07/03(土) 20:18:12.60

自分のレス読んで気づいたけど他の人に声出し読むう機会も無いからどうでもいいな

**デフォルトの名無しさん** · 2021/07/03(土) 20:23:06.99

おぺれーたーぐれぐれ

**デフォルトの名無しさん** · 2021/07/03(土) 21:03:34.16

オペレータ・イン

<<は当然オペレータ・アウト

**デフォルトの名無しさん** · 2021/07/03(土) 21:05:23.40

朗読問題は根深くて、古くは漢文の読み下しからあり、
座右の書たるC言語を256倍使うための本にもちゃんと発音方法が載ってる

**デフォルトの名無しさん** · 2021/07/03(土) 21:29:09.42

>> みぎみぎ
<< ひだりひだり

**デフォルトの名無しさん** · 2021/07/03(土) 21:41:24.77

>>603-611
ありがとうございます
func の返り値が左辺値参照である場合を除けば、コピーは起こらないでFAですね

で、func の返り値は左辺値参照でない限りは右辺値だとすると、auto& じゃ受けれないから auto&& で受けるべきということですね

**デフォルトの名無しさん** · 2021/07/03(土) 22:59:31.74

オペレーター、クィっ、クィっ

**デフォルトの名無しさん** · 2021/07/04(日) 03:21:06.85

auto hoge = func()
は場合によってはコピーが起きる
という印象、

なぜなら戻り値をスタックのどこに積むかをfunc()の側で指定できないから
hogeの実体ドンピシャにfunc()内で構築できる保証が無い
コピーが省略され得るのは
　auto hoge = func();
　bar(hoge);
みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの

**デフォルトの名無しさん** · 2021/07/04(日) 07:20:46.94

ISO/IEC 14882に準じて
おぺれーたーらいとしふと

**デフォルトの名無しさん** · 2021/07/04(日) 08:34:51.74

>>623
？？？
最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
アホか全然レイヤの違う話だよ
右辺値左辺値の概念全く理解しとらんのか (何十年前のプログラマだ)
「印象」でものを語るな

**デフォルトの名無しさん** · 2021/07/04(日) 10:01:09.26

それはそうと、こんなスレでも右辺値と左辺値よくわかってない (概念としてはわかっててもある場合のある値がどっちか判然としない) 人が多いのは、C++のムーブセマンティクスが洗練されてる証拠かもな
つまり、プログラマの預かり知らぬところで自動でコピーとムーブが仕分けされているという

**デフォルトの名無しさん** · 2021/07/04(日) 10:11:22.75

>>623
https://wandbox.org/permlink/FOkFiS1EumCHBr0F
そんなことないよな？と思いつつやってみた
まあ、そんなことないよな

ただ実験してて一個だけ気になったのが
take_S(S());
ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
C++11/14でも-fno-elide-constructorsを付けない限りmoveだけ
これってなんで？

**デフォルトの名無しさん** · 2021/07/04(日) 10:44:02.96

>>619
万葉集は読み下しですらないからな

**デフォルトの名無しさん** · 2021/07/04(日) 11:45:10.82

>>627
解説ｷﾎﾞﾃｨｰﾇ
"copy"と表示されているわけだが

**デフォルトの名無しさん** · 2021/07/04(日) 11:56:43.39

つかそれを除けば>>623の通りなんじゃないの

>take_S(S());
>ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
これは呼び出し元がS()の戻り値の実体をtake_S()の引数の実体と合一（スタック上の同一アドレス）にできた例
defaultコンが呼ばれなかったのはstruct Sがメンバを持たないから最適化でデフォルトコンストラが削除された例

通常の関数呼び出しでcoutする処理が削除されたらそればバグだが、
コンストラクタの呼び出し削減の最適化はコンストラクタ内で副作用のある処理を行っている可能性を
無視して行われることが規格のどっかで認められているはず……

**デフォルトの名無しさん** · 2021/07/04(日) 12:12:47.00

>最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
微妙にちげう　func()がオブジェクトをコピー返しする関数である以上、その場合だけムーブにする余地があると言ってゐる
実際は
　auto hoge = func()
　bar(hoge)
　（この後hogeを使う人は居ない）
と分けて書いたら"move"になりそうなケースなのに"copy"になったらしいが（>>627のリンク先

>アホか全然レイヤの違う話だよ
ムーブにできるのは参照の付け替えとみなせるケースなので上の話（コピーをムーブと読み替え得る条件）が別レイヤの話とは認められない

**デフォルトの名無しさん** · 2021/07/04(日) 12:32:59.30

>>629
表示されたってことは省略されてないよね？

**デフォルトの名無しさん** · 2021/07/04(日) 12:34:44.04

実験の部分を同時に話題にするべきではなかったな

**デフォルトの名無しさん** · 2021/07/04(日) 12:54:00.52

>>632
"move"にならずに"copy"になったのは謎だと>>631に書いてある

とわいえ、>>623の主張を整理すると、
　(1) func()が定義上オブジェクトをコピー返しする関数である場合、auto hoge = func() がムーブになるとは限らず、場合によってはコピーが起きる
　(2) ただし、bar(func()) というケースでは、func()の戻り値をbar()に渡す際に、コピーではなくムーブが選択される余地がある
というものであって、bar(func())に類似のケース（>>627のリンク先）でムーブにならずコピーになったからといって>>623が否定されたことにはならない
（∵ムーブが選択される「余地がある」と言っただけであってムーブにする義務があると言ったわけではない

**デフォルトの名無しさん** · 2021/07/04(日) 13:00:30.08

ここで「func()が定義上オブジェクトをコピー返しする関数である」のに何でコピーが削除されてムーブに成り得るのか？
という疑問を抱く向きもあるかもしれないが、
これについては構造体やオブジェクトをコピー返しするような関数func()が実際には
return valueの置き場所にデフォルト構築するだけのコードに落ちることがあるのを見たらﾜｶﾙ

**デフォルトの名無しさん** · 2021/07/04(日) 13:13:36.22

>>634
もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ

ていうか実験の部分は自己解決しました
C++17で必須になったっていうだけで、それまでも（C++98ですらも）省略されることが許されるというのは明記されていたんですね

**デフォルトの名無しさん** · 2021/07/04(日) 13:25:14.33

「コピー返し」ってなんぞ？

**デフォルトの名無しさん** · 2021/07/04(日) 13:29:00.70

>>636
>もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ
別に

言っているのは
1. オブジェクトの構築はfunc()内のどこかしらで行われる
2. 1の方法によっては、func()がreturn valueをreturnする際のコピーは省略される（func()がそういうコードになる
3. func()がスタック上に返したreturn valueを呼び出し元が自動変数hogeのエリアにコピーする代わりにbar()の引数エリアにmoveする
　ことがある（>>601が言うように常にmoveになる、というわけではない
と言う簡単な主張

**デフォルトの名無しさん** · 2021/07/04(日) 13:49:07.73

>>638
じゃあ結局>>623のこの部分は間違いってことでいいの？

> コピーが省略され得るのは
> 　auto hoge = func();
> 　bar(hoge);
> みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの