C++相談室 part156

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

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

**デフォルトの名無しさん** · 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の用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの

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

意味ワカンネ

1. func が内部でオブジェクトを構築する話
2. func の返り値を変数 hoge に束縛する話
3. func の返り値を後で他の関数に渡す話

全部切り分けて考えろよとしか思えんのだが

そして 2 について言えば>>621に尽きるだろとしか思えんのだが

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

>>640
いやすまん2は確かに間違いでauto hoge = func()はhogeへのmoveで済む

>>639
いやすまん「～できる場合だけ」という限定は間違いやった

ついでに言うとbar(func())でたまたまfunc()がスタック上に作ったreturn valueのアドレスも変えずにそのままbar()に渡せるとき
moveが起きるという主張も間違いだったかも……（アドレスも変わらないのなら何の構築も不要

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

何もかもおかしいよお前
「コピー返し」って結局なんやねん
独特の語法でわけのわからんことを主張するな
「印象」「かもしれない」で物事を主張するな
何がわかってて何がわかってないか知れ
質問と主張をごちゃまぜにするな
本格的に社会に居場所なくなるぞ

「全部取り下げます」とだけ言って去れ
で一から勉強しろ

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

RPGでアイテムを移動させた時に間違ってコピーされてアイテムが増殖する
ムーブしないといけない
アイテムは一個だけ

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

>>642
面倒見よくて草
昔はこの板にもアンタみたいな厳しい先輩いっぱい居たのにな
今はニワカと趣味グラマが何周送れかわからんポエム呟きあってるだけだし
昔からいる人らは完全スルーしてるはず

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

>>642
Callerが（スタック上に）確保したメモリに対してcalleeが構造体を返すという返し方の意味
これについては統一した用語が無いようなのでむしろ知りたいっすね……

>>643
>>623のコードでSにムーブコンが定義されていなかったら増殖を意図しないケースでも
コピコンが呼ばれるのだから>>643はたとえとしてはｲﾏｲﾁ

**はちみつ餃子** ◆8X2XSCHEME · 2021/07/04(日) 15:12:00.11

>>645
要件を満たすとき (返却値が prvalue のとき) は変数の場所に直接にオブジェクトが構築される.。
コピーやムーブを省略できるというのはそういう意味で、
特に C++17 以降ではコピー省略が許されるときにはコピーコンストラクタもムーブコンストラクタも存在しなくてもいい。

https://wandbox.org/permlink/FOndP8P7Ecv5v5sB

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

>>646のコードをVS2019でビルドしたら
>error C2280: 'foo::foo(foo &&)': 削除された関数を参照しようとしています
と言われるorz

ていうか「prvalueならば必ず変数の場所に直接にオブジェクトが構築される」（例外なくそうなる）のだとしたら
これはcallerがcalleeに構築すべき変数のアドレスを渡さねば実現できない芸当だけど
ABIにそんな隠れた第n引数を設けることまでC++の規格で決めちゃって委員会、
とそこはかとなく疑問が……
（funcがメンバ変数だった場合、隠れた第1引数でthisを渡すことになっているのにこれにさらに追加？

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

いいからお前はRVOでぐぐって来い
話はそれからだ

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

>>648
これか
https://blog.kmc.gr.jp/entry/2014/12/20/231430
>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
>そしてそのアドレスの先の上にオブジェクトを構築することで、関数内部での一時オブジェクト
>生成を呼び出し元のオブジェクト生成とみなすことができます。このようにしてRVOは実現されています。

>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
ｍｊｋ、

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

>>649
RVO は、最適化の一種なので、実現方法は色々。
とにかく、コンパイラが、関数の戻り値から左辺へのコピーやムーブを
なるべく減らして、いきなりダイレクトに左辺に書き込むような方法を探し出して
コード化する。
それをどやってやるかは、関数呼び出しの ABI 依存。

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

>>647
エラーになるのは、VS2019のデフォルトがC++14だから。
プロジェクトのプロパティ→構成プロパティ→C/C++→言語の
「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更すれば通る。

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

>>651
確かに「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更したら通った

>>651
>（RVOを）どやってやるかは、関数呼び出しの ABI 依存。
そういうものだと今の今まで思っていたが、
C++17で>>646のコード（コピコンもムーブコンも明示的に削除）がビルドが通るようになるということは、
第2の隠れた引数でcallerがcalleeに構築すべき変数のアドレスを渡すことが
C++17では義務化されるとしか解釈できないのでは……

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

第2の隠れた引数でcallerがcalleeに構築すべき変数のアドレスを渡しているのだとすると
>>627のコードが"default"の次に"copy"になるのはある程度説明がつく
　1. return_S()関数でS構築 --- ここでS:S()が呼ばれ、"default"表示
　2. auto hoge = return_S()では何も起きない（∵1で&hogeにSが構築済み）
　3. take_S(hoge)で呼び出しの引数としてhogeをコピー
　　　--- &hogeにあるSが、スタックの上の方に引数としてコピーされる結果"copy"表示

しかしhogeはその後使っていないのだから、コンパイラ的には3はmoveになる余地があるはず

なお>>641までの漏れのレスは第2の隠れた引数は仮定せず、return_S()（callee）がスタックのトップに
return valueとしてS()を構築して、
それが呼び出し元（caller）が&hogeにcopy（ムーブコンがあればmove）する穏当なモデルを考えていた
実際n3337.pdf（古いが）を読む限りRVOのやり方は全く規定されてないからアリのはず……
何で>>642が怒り狂うのかわからん……

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

>>652
別に実装として「隠れた引数」を使えとは規格上決まっていないよ
処理系は適当な専用のグローバル変数を使うようなコードを出力しても構わない

>>653
なんで>>642が怒り狂うのか？
>>642を読んで分からない分からない？
あなたの一連のレスはあなた自身以外の誰のためにもなっていないんだよね
>>642でするな、って言われていることは、そういう自分のためにしかならないことでスレを私物化する行為に等しいよってことだ

**デフォルトの名無しさん** · 2021/07/05(月) 08:27:16.47

>>653
>>603は調べたんかいな。cpprefjp な。
RVOを含めて調べれば、>>646だということは分かるだろ。
c++標準の扱いはcpprefjpの参照リンクにもある「値のコピー省略の保証について」が良くまとまっている。

検索・調査能力が低いのは今どきのプログラマーとして致命的欠陥だから、日頃から訓練したほうがいい。

**デフォルトの名無しさん** · 2021/07/05(月) 08:31:59.73

補足。
>>653の2はNRVOだからRVOとは別物な。
NRVOは最適化可能だけどコピー省略は保証されていない。

**デフォルトの名無しさん** · 2021/07/05(月) 08:44:01.31

>>656
あ、間違えた。NRVOとは関係ないや。

ついでに。
＞しかしhogeはその後使っていないのだから、コンパイラ的には3はmoveになる余地があるはず

副作用のあるコピーコンストラクタがあったら最適化はやばいんじゃない？
規格上許されていたっけ？

**デフォルトの名無しさん** · 2021/07/05(月) 11:05:56.38

ライフタイムを推論してcopy/moveの振り分けは理論上可能かもしれないが、現行の規格はそんなことは要求しない
lvalueからならcopy、rvalueからならmove
lvalueからmoveしてほしいならstd::moveしなさい
lvalueを渡しているのに勝手にrvalue referenceとして解釈されてぶっ壊されてたまるかよ

**デフォルトの名無しさん** · 2021/07/05(月) 12:24:14.81

template<class T>
class A {
public:
A()=default;
A(T&&);
};
この場合、T==Aになるとmoveとcopyを兼ねる？

**デフォルトの名無しさん** · 2021/07/05(月) 13:59:53.08

C++が出来るとは規格書がちゃんと読めることを言うんだね

**デフォルトの名無しさん** · 2021/07/05(月) 15:27:44.85

Macのclang++でコンパイルしています。
cstdlibをインクルードしなくてもrand()が使えてしまうのですが、これはなぜでしょうか？

**デフォルトの名無しさん** · 2021/07/05(月) 15:36:50.05

規格票には規格書なんて書いてない
俺はちゃんと読めるんだなんて
イキッてるやつはブーメランだな

**デフォルトの名無しさん** · 2021/07/06(火) 00:27:03.56

>>657
許されてるよ
その状況でコピコンやムーコンが呼ばれるかどうかは未規定（呼んでも呼ばなくてもいい）
というかこの「呼ばなくてもいい」っていう規定こそが正に規格がNRVOを認めてる部分そのもの

**デフォルトの名無しさん** · 2021/07/06(火) 03:32:03.53

実際、「move さえ省略してほしい」って思惑で
auto hoge = func();
と書くところを
auto&& hoge = func();
と書いてる人なんているの？

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

いるよ。

**デフォルトの名無しさん** · 2021/07/06(火) 07:45:25.63

>>657
エピステーメーも同じようなこと言ってたけどね
まぁコピーコンストラクタとかにコピー以外の副作用入れる方が悪い、ってことだろ
実際変な副作用など無いことを前提にしなきゃ出来ない最適化他にもあるやろ

**デフォルトの名無しさん** · 2021/07/06(火) 10:03:46.67

>>661
stdlib.hにも定義されているが、他のヘッダをincludeすると、
その中から別のヘッダをincludeしている場合も有り、その中からさらに
別のヘッダをincludeしている場合も有る。
また、標準ではstdlib.hやcstdlibで定義されているとされていても、
その他のヘッダで定義されていないとも限らない。

◆QZaw55cn4c · 2021/07/06(火) 20:25:19.80

>>666
＞コピーコンストラクタとかにコピー以外の副作用入れる方が悪い
規格票のどこに？