C++相談室 part156

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

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

**デフォルトの名無しさん** · 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
＞コピーコンストラクタとかにコピー以外の副作用入れる方が悪い
規格票のどこに？

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

>>668
規格票持ってるんですか？

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

>>668
コイツたまにトリップ外すの忘れて荒らしみたいなことしてんの最高に滑稽

**はちみつ餃子** ◆8X2XSCHEME · 2021/07/07(水) 05:18:00.78

>>668
副作用がある場合でも省略されるというのは明記されている。

https://timsong-cpp.github.io/cppwp/n3337/class.copy#31
> even if the copy/move constructor and/or destructor for the object have side effects

**デフォルトの名無しさん** · 2021/07/10(土) 14:04:49.30

>>658
3がmoveになったところで何も壊れるものは無くね？
というのと、take_S()に渡される方がぶっ壊されることにはならないので
3がmoveになってもlvalueとして渡されることには変わりは無い

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

>>672
https://cpplover.blogspot.com/2009/11/rvalue-reference_23.html
とりあえずこれとか読んでからお願いします
全体的に何が言いたいかよく分からないですがmoveならrvalueとして渡されるのでそこは理解してください

**デフォルトの名無しさん** · 2021/07/11(日) 00:24:04.38

>全体的に何が言いたいかよく分からないですが
ﾋｴｯ……このスレは荒れる……

**デフォルトの名無しさん** · 2021/07/11(日) 00:27:13.08

>moveならrvalueとして渡されるのでそこは理解してください
rvalueになるのは移動の右辺であり3のケースでは（3がmoveになったとして）移動元のhogeの実体だが
take_S()に渡るのはmoveされた後のhogeなのでtake_S()の中では問題無くlvalue扱い

**デフォルトの名無しさん** · 2021/07/11(日) 00:28:49.03

しつれい、
誤： take_S()に渡るのはmoveされた後のhoge
正： take_S()に渡るのは&hogeからmoveされてきたhogeの「複製」

**デフォルトの名無しさん** · 2021/07/11(日) 00:51:20.33

リンク先読んだ？

**デフォルトの名無しさん** · 2021/07/11(日) 00:53:43.57

もとから読んでるっつーの；；；
>>677はムーブコンストラクタで構築されたオブジェクトがlvalueでないと思っちゃうタイプ？

**デフォルトの名無しさん** · 2021/07/11(日) 00:54:17.11

3.でmoveは発生しません
詳細はさっきのブログ記事に書いてあります
以上

**デフォルトの名無しさん** · 2021/07/11(日) 00:55:29.24

>>679
どこか指摘できずに逃亡；；；

**デフォルトの名無しさん** · 2021/07/11(日) 00:57:15.79

lvalueをmoveせよ

さて、2. はどうしたらいいだろう。moveコンストラクタを実装したものの、コンパイラは2. の場合には、moveコンストラクタを呼び出してくれない。なぜなら、コンパイラは、プログラマの脳内仕様を読んではくれないからだ。tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。

そこで、プログラマが意図を伝えてやらなければならない。

X b( static_cast<X &&>(tmp) ) ;

この様に、rvalueにキャストしてやれば、moveコンストラクタを呼び出すことが出来る。

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

>>679はSのインスタンスhogeを関数void take_S(S) （※void take_S(S&)ではない！）に渡す際に、
take_S()の呼び出し元（この場合main()）が
hogeと同じ値を持つインスタンスをtake_S()の引数用領域に構築する必要がある、というあたりからして理解していないのではないか；；；
で、問題にしているコードはリンク先の
>tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。
には該当しない

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

なぜなら、今回のケースはコードを見たらﾜｶﾙからじゃわ；；；
コンパイラは静的に決定できない、と言っているのは停止性問題を解く万能のアルゴリズムが無いことから来ているが、
特殊なケースでは停止性問題は機械的に解ける
今こそその時、

、というあたりからして>>679はちんぷんかんぷんなのではないか……

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

あーそこがわかってなかったのね
take_Sの仮引数を実引数で初期化する時に同じことが起こるだけですよ？
実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
できなければ（かつlvalue参照として解決できれば）copyで仮引数が初期化される

**デフォルトの名無しさん** · 2021/07/11(日) 01:24:29.28

>>684
藻前の頭が固いだけなんとちゃうか；；；

>実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
この場合（すなわち実引数hogeをtake_S()の仮引数としてコピーした後呼び出し元が実引数hoge()を使わない（ことをコンパイラが機械的に判定できる）ケース）
において、実引数hogeのアドレスをrvalue参照とみなしてはいけないという根拠は？
論理的にはソースコードの意味を変えることなく整合するんだけどそういう最適化はいけないことなの？

**デフォルトの名無しさん** · 2021/07/11(日) 02:58:15.91

んまーとは言ったものの、
【実験1】 >>627のコードをループにしてやって最適化「-O2」にしても"move"にならなんだorz
https://wandbox.org/permlink/2kwbZ4cxyfMDe9VC
結果:
default
--------
copy
0, 1
default
--------
copy
1, 2
...

※ ループにした他、コピコンとムーブコンをそれぞれ「それらしく」実装もしてゐる、

**デフォルトの名無しさん** · 2021/07/11(日) 02:59:10.66

【実験2】もちろんstd::move(hoge)したらmoveになる
（上記リンク先のコードのDO_MOVE定義のコメントアウトを外してを有効化）
結果:
default
--------
move
0, 1
default
--------
move
1, 2
...

【実験3】また、中間変数hogeを使わずtake_S(return_S())するとcopyもmoveも起きない
（上記リンク先のコードのUSE_ITM_VARの定義をコメントアウトして無効化）
結果:
default
0, 1
default
1, 2
...

**デフォルトの名無しさん** · 2021/07/11(日) 03:09:25.47

（言い訳1）
実験3のような最適化が許されるのだから、copyをmoveに読み替える最適化も許されるべきだ
規格に照らしてどうなのかはC++規格の専門家の反応待ち

（言い訳2）
今回のケースでGCC様がcopyをmoveにする最適化を拒むのは、単にhogeの使用箇所の分析をサボっているか
（データフロー解析の一環として論理的には十分take_S()呼び出し後の未使用を機械的判定をやれるはずなのに…
、デストラクタのdefault[] のコストでも気にしている可能性が微ﾚ存

（言い訳3）
>>627のコードでmoveになる、と最初に言い出したのは>>609であって漏れではない
むしろ漏れは「場合によってはcopyが起きる」（>>623）と述べてたのでcopy派である
（C++17のRVOが要請するABIについて誤解していた感じなのでであんま大きな声では言えないが

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

>>685
> 論理的にはソースコードの意味を変えることなく整合するんだけどそういう最適化はいけないことなの？

コピーコンストラクタとムーブコンストラクタのどっちが呼ばれたかわかるようにログ出力とかしてたら動作が変わる。
そういう副作用を含めてコンパイラが動作を変えていいケースは >>671 で挙げられたように明示的に規定されていて、
あなたの言うケースはそうではない。

**はちみつ餃子** ◆8X2XSCHEME · 2021/07/11(日) 18:47:32.64

>>688
Copy になるべき場合と Move になるべき場合は条件がはっきりしている。
どちらでもいい場合は無い。

表層上の動作が仕様通りであればどうコンパイルしても良いのが C/C++ なので、
あえて、あくまでもあえてレアケースを挙げるとすれば
(見かけ上の) 動作が Copy でも Move でも同じだとコンパイラが見ぬくことが出来る場合が
あったなら Copy の場面で Move 相当の機械語が生成されることが絶対にないとは言いきれないけども、
Copy でも Move でも同じだと確信できる場合に限られるので動作からはどうせ観測できない。

意味を変える最適化をしていいという唯一のルールがコピー (またはムーブ) の省略で、
その一部が C++17 では必須化されたわけだね。

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

ある整数がある整数の n 乗であることの判定ってどうするのが良いでしょうか
(n も整数とします)

今までは
x == (int)pow((int)pow(x, 1.0/n), n)
で判定してたんですが、今の自分の環境で x = 4096、n = 6 を渡したら誤判定しました

(int) を round に変えるのを思いつきましたが、コーナーケースがあったら嫌なので、他の良い方法があったら教えてください

**デフォルトの名無しさん** · 2021/07/12(月) 08:17:32.01

>>691
諦めてboostの多倍長整数を使う。

**デフォルトの名無しさん** · 2021/07/12(月) 08:25:49.14

>>691
double y = pow(x,1.0/n);
int iy = (int)y;
iy==y
このほうが多少マシにはなると思うが根本的な解決になってないので
double epsilon = 0.00000001;
y-iy < epsilon;
にするとか

**デフォルトの名無しさん** · 2021/07/12(月) 09:45:03.47

>>691
どこまで高速化したいのかわからんけど頑張ってn乗計算するとか
https://qiita.com/b1ueskydragon/items/0b8e0c382d782423c6d3

**デフォルトの名無しさん** · 2021/07/12(月) 10:01:12.57

>>692
多倍長整数でどうやるんでしょうか？

>>693
確かに、改めて n 乗する意味なかったですね

>>694
後出しですみませんが、遅くて良いから短くて誤判定のないのが望ましいです

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

>>693
y の小数部分が 0.9999999998 とかだと失敗しますよね？
iy = round(y) として abs(y - iy) < 1e-12 で判定しようかなと思います

**デフォルトの名無しさん** · 2021/07/12(月) 10:22:44.45

>>690
最後だけ認識おかしい、唯一ではない