[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
596: 2021/06/29(火)23:59 ID:yAVMK7JX(1) AAS
pack/unpack使え
597: 2021/06/30(水)00:03 ID:6riO4yVW(1) AAS
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 ***"; # 改行は付けない
省1
598: 2021/06/30(水)00:07 ID:d2kdzRUr(1) AAS
Encodeは日本語入りのパスとか$ARGV[]とかをutf8にしたり戻したりするのに使う
コマンドプロンプトの文字をutf8にしたら実はEncode要らんかもしれんがそこまでは知らん
599: 2021/06/30(水)00:40 ID:uW/S3RKL(1) AAS
Perlの特定の某なんか出されても知らんがな……
600: 2021/06/30(水)03:10 ID:vkj6zKzF(1) AAS
Perl Python PHP Java C# EcmaScript TypeScript Javaくらいは流石に教養だろうさ。
601(4): 2021/06/30(水)07:38 ID:F9CAzHJ+(1) AAS
func の返り値を変数 hoge に受けるときって
auto hoge = func();
auto& hoge = func();
auto&& hoge = func();
のいずれにおいてもオブジェクトの再構築 (コピー) は行われないって思って良いんですよね？
602: 2021/06/30(水)10:58 ID:x9tVpfG6(1) AAS
no
603(1): 2021/06/30(水)11:13 ID:EDSlPJC8(1) AAS
>>601
c++17：値のコピー省略を保証、て奴かね。
戻り値が右辺値かどうかで変わるんじゃない？
604: 2021/06/30(水)12:11 ID:2LaR0NZ5(1/5) AAS
関数の戻り値は必ず右辺値のはずだが。
605: 2021/06/30(水)12:19 ID:8KWEqHlz(1) AAS
んなこたーない
606(1): 2021/06/30(水)12:29 ID:sL9lkuh+(1) AAS
参照返し……と思ったけど、
参照て右辺値だっけ？左辺値だっけ？
607: 2021/06/30(水)13:29 ID:2LaR0NZ5(2/5) AAS
関数の戻り値は、戻り値の型が左辺値参照で有る場合だけは左辺値で、
それ以外は右辺値らしい。
608: 2021/06/30(水)13:34 ID:2LaR0NZ5(3/5) AAS
>>606
戻り値の型が右辺値参照の場合、関数呼び出しの結果は、xvalueだが、分類上は、右辺値でもあり、glvalueでもある。
戻り値の型が左辺値参照の場合、関数呼び出しの結果は、左辺値。
戻り値の型が参照型でない場合、関数呼び出しの結果は、prvalueで、右辺値。
prvalue = 純粋右辺値。
glvalue = 一般化左辺値。
xvalue = 消えかかっている値。謎の値とも言われる。
609(3): 2021/06/30(水)13:39 ID:2LaR0NZ5(4/5) AAS
>>601
一番上の書き方だと、少なくとも move になる。
下の二つは、moveもcopyも行われないで、アドレスだけが参照型変数に
入るのだと思う。
610(1): 2021/06/30(水)14:18 ID:DhAhW4Ik(1) AAS
>>609
funcの戻り値型が左辺値参照の場合moveにはならんのでは？
611: 2021/06/30(水)14:56 ID:2LaR0NZ5(5/5) AAS
>>610
その通りで、コピーコンストラクタが呼び出される気がする。
「少なくとも」と書いたのは、効率面で最低でも move が生じる
という意味で書いたつもりだった。
612: 2021/07/03(土)19:40 ID:Ju/axMXt(1/2) AAS
くっそ素朴な疑問だけど
「operator>>」
って声に出して読むときどうしてる？
独学/個人開発なので他の人から聞く機会がない
613: 2021/07/03(土)19:42 ID:dunp4iC4(1) AAS
右シフト記号？
614: 2021/07/03(土)20:04 ID:ApVtA7Dx(1) AAS
入力オーバーライドとか？ うーん・・・ダブルGT！
615: 2021/07/03(土)20:04 ID:Y97o1UBK(1) AAS
個人的には「おぺれーたーだいなりだいなり」だな
他人には言ったことないけど
616: 2021/07/03(土)20:18 ID:Ju/axMXt(2/2) AAS
自分のレス読んで気づいたけど他の人に声出し読むう機会も無いからどうでもいいな
617: 2021/07/03(土)20:23 ID:A2f3M294(1) AAS
おぺれーたーぐれぐれ
618: 2021/07/03(土)21:03 ID:WO4lFPcp(1/2) AAS
オペレータ・イン
<<は当然オペレータ・アウト
619(1): 2021/07/03(土)21:05 ID:WO4lFPcp(2/2) AAS
朗読問題は根深くて、古くは漢文の読み下しからあり、
座右の書たるC言語を256倍使うための本にもちゃんと発音方法が載ってる
620: 2021/07/03(土)21:29 ID:iUoBj2xP(1) AAS
>> みぎみぎ
<< ひだりひだり
621(1): 2021/07/03(土)21:41 ID:iArH0hMS(1) AAS
>>603-611
ありがとうございます
func の返り値が左辺値参照である場合を除けば、コピーは起こらないでFAですね
で、func の返り値は左辺値参照でない限りは右辺値だとすると、auto& じゃ受けれないから auto&& で受けるべきということですね
622: 2021/07/03(土)22:59 ID:5pcVeoYl(1) AAS
オペレーター、クィっ、クィっ
623(7): 2021/07/04(日)03:21 ID:WJcubPcO(1/13) AAS
auto hoge = func()
は場合によってはコピーが起きる
という印象、
なぜなら戻り値をスタックのどこに積むかをfunc()の側で指定できないから
hogeの実体ドンピシャにfunc()内で構築できる保証が無い
コピーが省略され得るのは
auto hoge = func();
bar(hoge);
みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの
624: 2021/07/04(日)07:20 ID:kv3QS/1l(1) AAS
ISO/IEC 14882に準じて
おぺれーたーらいとしふと
625: 2021/07/04(日)08:34 ID:mLloSLib(1/2) AAS
>>623
？？？
最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
アホか全然レイヤの違う話だよ
右辺値左辺値の概念全く理解しとらんのか (何十年前のプログラマだ)
「印象」でものを語るな
626: 2021/07/04(日)10:01 ID:mLloSLib(2/2) AAS
それはそうと、こんなスレでも右辺値と左辺値よくわかってない (概念としてはわかっててもある場合のある値がどっちか判然としない) 人が多いのは、C++のムーブセマンティクスが洗練されてる証拠かもな
つまり、プログラマの預かり知らぬところで自動でコピーとムーブが仕分けされているという
627(6): 2021/07/04(日)10:11 ID:dMFRzHLQ(1/6) AAS
>>623
外部ﾘﾝｸ:wandbox.org
そんなことないよな？ と思いつつやってみた
まあ、そんなことないよな
ただ実験してて一個だけ気になったのが
take_S(S());
ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
C++11/14でも-fno-elide-constructorsを付けない限りmoveだけ
これってなんで？
628: 2021/07/04(日)10:44 ID:pili1Lz/(1) AAS
>>619
万葉集は読み下しですらないからな
629(1): 2021/07/04(日)11:45 ID:WJcubPcO(2/13) AAS
>>627
解説ｷﾎﾞﾃｨｰﾇ
"copy"と表示されているわけだが
630: 2021/07/04(日)11:56 ID:WJcubPcO(3/13) AAS
つかそれを除けば>>623の通りなんじゃないの
>take_S(S());
>ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
これは呼び出し元がS()の戻り値の実体をtake_S()の引数の実体と合一（スタック上の同一アドレス）にできた例
defaultコンが呼ばれなかったのはstruct Sがメンバを持たないから最適化でデフォルトコンストラが削除された例
通常の関数呼び出しでcoutする処理が削除されたらそればバグだが、
コンストラクタの呼び出し削減の最適化はコンストラクタ内で副作用のある処理を行っている可能性を
無視して行われることが規格のどっかで認められているはず……
631(1): 2021/07/04(日)12:12 ID:WJcubPcO(4/13) AAS
>最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
微妙にちげう func()がオブジェクトをコピー返しする関数である以上、その場合だけムーブにする余地があると言ってゐる
実際は
auto hoge = func()
bar(hoge)
（この後hogeを使う人は居ない）
と分けて書いたら"move"になりそうなケースなのに"copy"になったらしいが（>>627のリンク先
>アホか全然レイヤの違う話だよ
ムーブにできるのは参照の付け替えとみなせるケースなので上の話（コピーをムーブと読み替え得る条件）が別レイヤの話とは認められない
632(1): 2021/07/04(日)12:32 ID:dMFRzHLQ(2/6) AAS
>>629
表示されたってことは省略されてないよね？
633: 2021/07/04(日)12:34 ID:dMFRzHLQ(3/6) AAS
実験の部分を同時に話題にするべきではなかったな
634(1): 2021/07/04(日)12:54 ID:WJcubPcO(5/13) AAS
>>632
"move"にならずに"copy"になったのは謎だと>>631に書いてある
とわいえ、>>623の主張を整理すると、
(1) func()が定義上オブジェクトをコピー返しする関数である場合、auto hoge = func() がムーブになるとは限らず、場合によってはコピーが起きる
(2) ただし、bar(func()) というケースでは、func()の戻り値をbar()に渡す際に、コピーではなくムーブが選択される余地がある
というものであって、bar(func())に類似のケース（>>627のリンク先）でムーブにならずコピーになったからといって>>623が否定されたことにはならない
（∵ムーブが選択される「余地がある」と言っただけであってムーブにする義務があると言ったわけではない
635: 2021/07/04(日)13:00 ID:WJcubPcO(6/13) AAS
ここで「func()が定義上オブジェクトをコピー返しする関数である」のに何でコピーが削除されてムーブに成り得るのか？
という疑問を抱く向きもあるかもしれないが、
これについては構造体やオブジェクトをコピー返しするような関数func()が実際には
return valueの置き場所にデフォルト構築するだけのコードに落ちることがあるのを見たらﾜｶﾙ
636(1): 2021/07/04(日)13:13 ID:dMFRzHLQ(4/6) AAS
>>634
もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ
ていうか実験の部分は自己解決しました
C++17で必須になったっていうだけで、それまでも（C++98ですらも）省略されることが許されるというのは明記されていたんですね
637: 2021/07/04(日)13:25 ID:bouvqZmG(1/3) AAS
「コピー返し」ってなんぞ？
638(1): 2021/07/04(日)13:29 ID:WJcubPcO(7/13) AAS
>>636
>もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ
別に
言っているのは
1. オブジェクトの構築はfunc()内のどこかしらで行われる
2. 1の方法によっては、func()がreturn valueをreturnする際のコピーは省略される（func()がそういうコードになる
3. func()がスタック上に返したreturn valueを呼び出し元が自動変数hogeのエリアにコピーする代わりにbar()の引数エリアにmoveする
ことがある（>>601が言うように常にmoveになる、というわけではない
と言う簡単な主張
639(1): 2021/07/04(日)13:49 ID:dMFRzHLQ(5/6) AAS
>>638
じゃあ結局>>623のこの部分は間違いってことでいいの？
> コピーが省略され得るのは
> auto hoge = func();
> bar(hoge);
> みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの
640(1): 2021/07/04(日)14:05 ID:bouvqZmG(2/3) AAS
意味ワカンネ
1. func が内部でオブジェクトを構築する話
2. func の返り値を変数 hoge に束縛する話
3. func の返り値を後で他の関数に渡す話
全部切り分けて考えろよとしか思えんのだが
そして 2 について言えば>>621に尽きるだろとしか思えんのだが
641(1): 2021/07/04(日)14:15 ID:WJcubPcO(8/13) AAS
>>640
いやすまん2は確かに間違いでauto hoge = func()はhogeへのmoveで済む
>>639
いやすまん「〜できる場合だけ」という限定は間違いやった
ついでに言うとbar(func())でたまたまfunc()がスタック上に作ったreturn valueのアドレスも変えずにそのままbar()に渡せるとき
moveが起きるという主張も間違いだったかも……（アドレスも変わらないのなら何の構築も不要
642(4): 2021/07/04(日)14:27 ID:bouvqZmG(3/3) AAS
何もかもおかしいよお前
「コピー返し」って結局なんやねん
独特の語法でわけのわからんことを主張するな
「印象」「かもしれない」で物事を主張するな
何がわかってて何がわかってないか知れ
質問と主張をごちゃまぜにするな
本格的に社会に居場所なくなるぞ
「全部取り下げます」とだけ言って去れ
で一から勉強しろ
643(1): 2021/07/04(日)14:32 ID:2p3tbjy0(1) AAS
RPGでアイテムを移動させた時に間違ってコピーされてアイテムが増殖する
ムーブしないといけない
アイテムは一個だけ
644: 2021/07/04(日)14:37 ID:HHbHqtlq(1) AAS
>>642
面倒見よくて草
昔はこの板にもアンタみたいな厳しい先輩いっぱい居たのにな
今はニワカと趣味グラマが何周送れかわからんポエム呟きあってるだけだし
昔からいる人らは完全スルーしてるはず
645(1): 2021/07/04(日)14:52 ID:WJcubPcO(9/13) AAS
>>642
Callerが（スタック上に）確保したメモリに対してcalleeが構造体を返すという返し方の意味
これについては統一した用語が無いようなのでむしろ知りたいっすね……
>>643
>>623のコードでSにムーブコンが定義されていなかったら増殖を意図しないケースでも
コピコンが呼ばれるのだから>>643はたとえとしてはｲﾏｲﾁ
646(3): はちみつ餃子 ◆8X2XSCHEME 2021/07/04(日)15:12 ID:7/Zaj2J4(1) AAS
>>645
要件を満たすとき (返却値が prvalue のとき) は変数の場所に直接にオブジェクトが構築される.。
コピーやムーブを省略できるというのはそういう意味で、
特に C++17 以降ではコピー省略が許されるときにはコピーコンストラクタもムーブコンストラクタも存在しなくてもいい。
外部ﾘﾝｸ:wandbox.org
647(1): 2021/07/04(日)15:50 ID:WJcubPcO(10/13) AAS
>>646のコードをVS2019でビルドしたら
>error C2280: 'foo::foo(foo &&)': 削除された関数を参照しようとしています
と言われるorz
ていうか「prvalueならば必ず変数の場所に直接にオブジェクトが構築される」（例外なくそうなる）のだとしたら
これはcallerがcalleeに構築すべき変数のアドレスを渡さねば実現できない芸当だけど
ABIにそんな隠れた第n引数を設けることまでC++の規格で決めちゃって委員会、
とそこはかとなく疑問が……
（funcがメンバ変数だった場合、隠れた第1引数でthisを渡すことになっているのにこれにさらに追加？
648(1): 2021/07/04(日)15:56 ID:xLbwwiyt(1) AAS
いいからお前はRVOでぐぐって来い
話はそれからだ
649(1): 2021/07/04(日)16:02 ID:WJcubPcO(11/13) AAS
>>648
これか
外部ﾘﾝｸ:blog.kmc.gr.jp
>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
>そしてそのアドレスの先の上にオブジェクトを構築することで、関数内部での一時オブジェクト
>生成を呼び出し元のオブジェクト生成とみなすことができます。 このようにしてRVOは実現されています。
>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
ｍｊｋ、
650: 2021/07/04(日)16:18 ID:2qJME2iB(1) AAS
>>649
RVO は、最適化の一種なので、実現方法は色々。
とにかく、コンパイラが、関数の戻り値から左辺へのコピーやムーブを
なるべく減らして、いきなりダイレクトに左辺に書き込むような方法を探し出して
コード化する。
それをどやってやるかは、関数呼び出しの ABI 依存。
651(1): 2021/07/04(日)16:52 ID:VOtERW9V(1) AAS
>>647
エラーになるのは、VS2019のデフォルトがC++14だから。
プロジェクトのプロパティ→構成プロパティ→C/C++→言語 の
「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更すれば通る。
652(1): 2021/07/04(日)18:28 ID:WJcubPcO(12/13) AAS
>>651
確かに「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更したら通った
>>651
>（RVOを）どやってやるかは、関数呼び出しの ABI 依存。
そういうものだと今の今まで思っていたが、
C++17で>>646のコード（コピコンもムーブコンも明示的に削除）がビルドが通るようになるということは、
第2の隠れた引数でcallerがcalleeに構築すべき変数のアドレスを渡すことが
C++17では義務化されるとしか解釈できないのでは……
653(3): 2021/07/04(日)20:21 ID:WJcubPcO(13/13) AAS
第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）する穏当なモデルを考えていた
省2
654: 2021/07/04(日)22:02 ID:dMFRzHLQ(6/6) AAS
>>652
別に実装として「隠れた引数」を使えとは規格上決まっていないよ
処理系は適当な専用のグローバル変数を使うようなコードを出力しても構わない
>>653
なんで>>642が怒り狂うのか？
>>642を読んで分からない分からない？
あなたの一連のレスはあなた自身以外の誰のためにもなっていないんだよね
>>642でするな、って言われていることは、そういう自分のためにしかならないことでスレを私物化する行為に等しいよってことだ
655: 2021/07/05(月)08:27 ID:4kBMhQOc(1/3) AAS
>>653
>>603は調べたんかいな。cpprefjp な。
RVOを含めて調べれば、>>646だということは分かるだろ。
c++標準の扱いはcpprefjpの参照リンクにもある「値のコピー省略の保証について」が良くまとまっている。
検索・調査能力が低いのは今どきのプログラマーとして致命的欠陥だから、日頃から訓練したほうがいい。
656(1): 2021/07/05(月)08:31 ID:4kBMhQOc(2/3) AAS
補足。
>>653の2はNRVOだからRVOとは別物な。
NRVOは最適化可能だけどコピー省略は保証されていない。
657(2): 2021/07/05(月)08:44 ID:4kBMhQOc(3/3) AAS
>>656
あ、間違えた。NRVOとは関係ないや。
ついでに。
＞しかしhogeはその後使っていないのだから、コンパイラ的には3はmoveになる余地があるはず
副作用のあるコピーコンストラクタがあったら最適化はやばいんじゃない？
規格上許されていたっけ？
658(1): 2021/07/05(月)11:05 ID:w3Zb0u1p(1) AAS
ライフタイムを推論してcopy/moveの振り分けは理論上可能かもしれないが、現行の規格はそんなことは要求しない
lvalueからならcopy、rvalueからならmove
lvalueからmoveしてほしいならstd::moveしなさい
lvalueを渡しているのに勝手にrvalue referenceとして解釈されてぶっ壊されてたまるかよ
659: 2021/07/05(月)12:24 ID:M+MHtMKE(1/2) AAS
template<class T>
class A {
public:
A()=default;
A(T&&);
};
この場合、T==Aになるとmoveとcopyを兼ねる？
660: 2021/07/05(月)13:59 ID:MxHqaq3M(1) AAS
C++が出来るとは規格書がちゃんと読めることを言うんだね
661(1): 2021/07/05(月)15:27 ID:NDiogwds(1) AAS
Macのclang++でコンパイルしています。
cstdlibをインクルードしなくてもrand()が使えてしまうのですが、これはなぜでしょうか？
662: 2021/07/05(月)15:36 ID:M+MHtMKE(2/2) AAS
規格票には規格書なんて書いてない
俺はちゃんと読めるんだなんて
イキッてるやつはブーメランだな
663: 2021/07/06(火)00:27 ID:86XKd96p(1) AAS
>>657
許されてるよ
その状況でコピコンやムーコンが呼ばれるかどうかは未規定（呼んでも呼ばなくてもいい）
というかこの「呼ばなくてもいい」っていう規定こそが正に規格がNRVOを認めてる部分そのもの
664: 2021/07/06(火)03:32 ID:PiE4/OQH(1) AAS
実際、「move さえ省略してほしい」って思惑で
auto hoge = func();
と書くところを
auto&& hoge = func();
と書いてる人なんているの？
665: 2021/07/06(火)07:29 ID:6WiwYssU(1) AAS
いるよ。
666(1): 2021/07/06(火)07:45 ID:FcxtUR1g(1) AAS
>>657
エピステーメーも同じようなこと言ってたけどね
まぁコピーコンストラクタとかにコピー以外の副作用入れる方が悪い、ってことだろ
実際変な副作用など無いことを前提にしなきゃ出来ない最適化他にもあるやろ
667: 2021/07/06(火)10:03 ID:t2+Z62DR(1) AAS
>>661
stdlib.hにも定義されているが、他のヘッダをincludeすると、
その中から別のヘッダをincludeしている場合も有り、その中からさらに
別のヘッダをincludeしている場合も有る。
また、標準ではstdlib.hやcstdlibで定義されているとされていても、
その他のヘッダで定義されていないとも限らない。
668(6): ◆QZaw55cn4c 2021/07/06(火)20:25 ID:/lKUoH39(1) AAS
>>666
＞コピーコンストラクタとかにコピー以外の副作用入れる方が悪い
規格票のどこに？
669: 2021/07/06(火)23:17 ID:2d1Iatqp(1) AAS
>>668
規格票持ってるんですか？
670: 2021/07/07(水)00:20 ID:ACi5C/C8(1) AAS
>>668
コイツたまにトリップ外すの忘れて荒らしみたいなことしてんの最高に滑稽
671(1): はちみつ餃子 ◆8X2XSCHEME 2021/07/07(水)05:18 ID:BiM5c4gH(1) AAS
>>668
副作用がある場合でも省略されるというのは明記されている。
外部ﾘﾝｸ[copy]:timsong-cpp.github.io
> even if the copy/move constructor and/or destructor for the object have side effects
672(1): 2021/07/10(土)14:04 ID:yQTcABkI(1) AAS
>>658
3がmoveになったところで何も壊れるものは無くね？
というのと、take_S()に渡される方がぶっ壊されることにはならないので
3がmoveになってもlvalueとして渡されることには変わりは無い
673: 2021/07/11(日)00:07 ID:5nx6GB9W(1/5) AAS
>>672
外部ﾘﾝｸ[html]:cpplover.blogspot.com
とりあえずこれとか読んでからお願いします
全体的に何が言いたいかよく分からないですがmoveならrvalueとして渡されるのでそこは理解してください
674: 2021/07/11(日)00:24 ID:YJk6tGcw(1/11) AAS
>全体的に何が言いたいかよく分からないですが
ﾋｴｯ……このスレは荒れる……
675: 2021/07/11(日)00:27 ID:YJk6tGcw(2/11) AAS
>moveならrvalueとして渡されるのでそこは理解してください
rvalueになるのは移動の右辺であり3のケースでは（3がmoveになったとして）移動元のhogeの実体だが
take_S()に渡るのはmoveされた後のhogeなのでtake_S()の中では問題無くlvalue扱い
676: 2021/07/11(日)00:28 ID:YJk6tGcw(3/11) AAS
しつれい、
誤： take_S()に渡るのはmoveされた後のhoge
正： take_S()に渡るのは&hogeからmoveされてきたhogeの「複製」
677(1): 2021/07/11(日)00:51 ID:5nx6GB9W(2/5) AAS
リンク先読んだ？
678: 2021/07/11(日)00:53 ID:YJk6tGcw(4/11) AAS
もとから読んでるっつーの；；；
>>677はムーブコンストラクタで構築されたオブジェクトがlvalueでないと思っちゃうタイプ？
679(3): 2021/07/11(日)00:54 ID:5nx6GB9W(3/5) AAS
3.でmoveは発生しません
詳細はさっきのブログ記事に書いてあります
以上
680: 2021/07/11(日)00:55 ID:YJk6tGcw(5/11) AAS
>>679
どこか指摘できずに逃亡；；；
681: 2021/07/11(日)00:57 ID:5nx6GB9W(4/5) AAS
lvalueをmoveせよ
さて、2. はどうしたらいいだろう。moveコンストラクタを実装したものの、コンパイラは2. の場合には、moveコンストラクタを呼び出してくれない。なぜなら、コンパイラは、プログラマの脳内仕様を読んではくれないからだ。tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。
そこで、プログラマが意図を伝えてやらなければならない。
X b( static_cast<X &&>(tmp) ) ;
この様に、rvalueにキャストしてやれば、moveコンストラクタを呼び出すことが出来る。
682: 2021/07/11(日)01:01 ID:YJk6tGcw(6/11) AAS
>>679はSのインスタンスhogeを関数void take_S(S) （※void take_S(S&)ではない！）に渡す際に、
take_S()の呼び出し元（この場合main()）が
hogeと同じ値を持つインスタンスをtake_S()の引数用領域に構築する必要がある、というあたりからして理解していないのではないか；；；
で、問題にしているコードはリンク先の
>tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。
には該当しない
683: 2021/07/11(日)01:04 ID:YJk6tGcw(7/11) AAS
なぜなら、今回のケースはコードを見たらﾜｶﾙからじゃわ；；；
コンパイラは静的に決定できない、と言っているのは停止性問題を解く万能のアルゴリズムが無いことから来ているが、
特殊なケースでは停止性問題は機械的に解ける
今こそその時、
、というあたりからして>>679はちんぷんかんぷんなのではないか……
684(1): 2021/07/11(日)01:11 ID:5nx6GB9W(5/5) AAS
あーそこがわかってなかったのね
take_Sの仮引数を実引数で初期化する時に同じことが起こるだけですよ？
実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
できなければ（かつlvalue参照として解決できれば）copyで仮引数が初期化される
685(1): 2021/07/11(日)01:24 ID:YJk6tGcw(8/11) AAS
>>684
藻前の頭が固いだけなんとちゃうか；；；
>実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
この場合（すなわち実引数hogeをtake_S()の仮引数としてコピーした後呼び出し元が実引数hoge()を使わない（ことをコンパイラが機械的に判定できる）ケース）
において、実引数hogeのアドレスをrvalue参照とみなしてはいけないという根拠は？
論理的にはソースコードの意味を変えることなく整合するんだけどそういう最適化はいけないことなの？
686: 2021/07/11(日)02:58 ID:YJk6tGcw(9/11) AAS
んまーとは言ったものの、
【実験1】 >>627のコードをループにしてやって最適化「-O2」にしても"move"にならなんだorz
外部ﾘﾝｸ:wandbox.org
結果:
default
--------
copy
0, 1
default
--------
省4
687: 2021/07/11(日)02:59 ID:YJk6tGcw(10/11) AAS
【実験2】 もちろんstd::move(hoge)したらmoveになる
（上記リンク先のコードのDO_MOVE定義のコメントアウトを外してを有効化）
結果:
default
--------
move
0, 1
default
--------
move
省10
688(1): 2021/07/11(日)03:09 ID:YJk6tGcw(11/11) AAS
（言い訳1）
実験3のような最適化が許されるのだから、copyをmoveに読み替える最適化も許されるべきだ
規格に照らしてどうなのかはC++規格の専門家の反応待ち
（言い訳2）
今回のケースでGCC様がcopyをmoveにする最適化を拒むのは、単にhogeの使用箇所の分析をサボっているか
（データフロー解析の一環として論理的には十分take_S()呼び出し後の未使用を機械的判定をやれるはずなのに…
、デストラクタのdefault[] のコストでも気にしている可能性が微ﾚ存
（言い訳3）
>>627のコードでmoveになる、と最初に言い出したのは>>609であって漏れではない
むしろ漏れは「場合によってはcopyが起きる」（>>623）と述べてたのでcopy派である
省1
689: 2021/07/11(日)13:04 ID:G2C/uXds(1) AAS
>>685
> 論理的にはソースコードの意味を変えることなく整合するんだけどそういう最適化はいけないことなの？
コピーコンストラクタとムーブコンストラクタのどっちが呼ばれたかわかるようにログ出力とかしてたら動作が変わる。
そういう副作用を含めてコンパイラが動作を変えていいケースは >>671 で挙げられたように明示的に規定されていて、
あなたの言うケースはそうではない。
690(1): はちみつ餃子 ◆8X2XSCHEME 2021/07/11(日)18:47 ID:8K44AFaV(1) AAS
>>688
Copy になるべき場合と Move になるべき場合は条件がはっきりしている。
どちらでもいい場合は無い。
表層上の動作が仕様通りであればどうコンパイルしても良いのが C/C++ なので、
あえて、あくまでもあえてレアケースを挙げるとすれば
(見かけ上の) 動作が Copy でも Move でも同じだとコンパイラが見ぬくことが出来る場合が
あったなら Copy の場面で Move 相当の機械語が生成されることが絶対にないとは言いきれないけども、
Copy でも Move でも同じだと確信できる場合に限られるので動作からはどうせ観測できない。
意味を変える最適化をしていいという唯一のルールがコピー (またはムーブ) の省略で、
その一部が C++17 では必須化されたわけだね。
691(9): 2021/07/12(月)07:46 ID:5HFqt1x5(1/3) AAS
ある整数がある整数の n 乗であることの判定ってどうするのが良いでしょうか
(n も整数とします)
今までは
x == (int)pow((int)pow(x, 1.0/n), n)
で判定してたんですが、今の自分の環境で x = 4096、n = 6 を渡したら誤判定しました
(int) を round に変えるのを思いつきましたが、コーナーケースがあったら嫌なので、他の良い方法があったら教えてください
692(2): 2021/07/12(月)08:17 ID:K0Wntvol(1) AAS
>>691
諦めてboostの多倍長整数を使う。
693(4): 2021/07/12(月)08:25 ID:Vv9VoiuP(1) AAS
>>691
double y = pow(x,1.0/n);
int iy = (int)y;
iy==y
このほうが多少マシにはなると思うが根本的な解決になってないので
double epsilon = 0.00000001;
y-iy < epsilon;
にするとか
694(2): 2021/07/12(月)09:45 ID:Q0n0f8DA(1) AAS
>>691
どこまで高速化したいのかわからんけど頑張ってn乗計算するとか
外部ﾘﾝｸ:qiita.com
695(4): 2021/07/12(月)10:01 ID:5HFqt1x5(2/3) AAS
>>692
多倍長整数でどうやるんでしょうか？
>>693
確かに、改めて n 乗する意味なかったですね
>>694
後出しですみませんが、遅くて良いから短くて誤判定のないのが望ましいです
上下前次1-新書関写板覧索設栞歴
あと 307 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s