C++相談室 part156

[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

554(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/28(月)00:31 ID:nxXyAxnK(1) AAS
>>553
言語に関係あるという話はしてないよ。

555: 2021/06/28(月)00:34 ID:AdoNh79c(1) AAS
Javaはメモリモデルも明確に決まってたんじゃないかな

556(1): 2021/06/28(月)02:47 ID:DsF+RsPk(1/2) AAS
多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ！

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

558(1): 2021/06/28(月)03:44 ID:QdlxBFRk(1) AAS
別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか

559(1): ◆QZaw55cn4c 2021/06/28(月)07:17 ID:oYDZ1nWa(1) AAS
>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします

560(2): 2021/06/28(月)07:48 ID:cZa6zFVz(1) AAS
>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。

561: 2021/06/28(月)08:30 ID:RYml5aTx(1) AAS
これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい

562: 2021/06/28(月)09:09 ID:XSoi24Ug(1) AAS
僕はノンバイナリーだから読みたくないです

563: 2021/06/28(月)09:56 ID:SQEqm/bz(1) AAS
こんどはバイナリに噛み付いてるキチガイがいるな

564: 2021/06/28(月)11:09 ID:bLKGwGq9(1) AAS
標準ライブラリのみであれば車輪の再発明しか手段がない？

565: 2021/06/28(月)12:52 ID:bIZ7S0Sd(1/2) AAS
MsgPack は json と同じで無駄が多い

566: 2021/06/28(月)12:59 ID:bIZ7S0Sd(2/2) AAS
>>558
温暖化詐欺SDG詐欺と手口が一緒だな

567: 2021/06/28(月)13:35 ID:quG4wdoj(1) AAS
>>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 [インストール済み、自動]

568(1): 2021/06/28(月)13:52 ID:5OdlGlMi(1) AAS
Comparisonて何て読むの？
コンパリソン？

569(1): 2021/06/28(月)14:55 ID:qFu4iqR6(1) AAS
msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット

570: 2021/06/28(月)14:56 ID:R7ScYjSP(1) AAS
>>568 こんｐぇぁりｚん外部ﾘﾝｸ:www.google.com

571: 2021/06/28(月)15:26 ID:JcAv6JCW(1/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

572: 2021/06/28(月)15:26 ID:JcAv6JCW(2/2) AAS
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

573(1): 2021/06/28(月)16:13 ID:dKXkMhte(1) AAS
>>569のお勧めは何？
理由もセットで教えて頂戴。

574: 2021/06/28(月)16:32 ID:uBCftstC(1) AAS
「モジュール」はC++で作られたパッケージを配布しやすくしますか？

575(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:03 ID:OP5z1lEO(1/2) AAS
>>560
そうだよ。その当たり前の話をしてるんだよ……。

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

576(1): 2021/06/29(火)00:15 ID:MxyOwUyS(1/5) AAS
>>575
いつのまにか話ずらしてんな。

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

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

577: はちみつ餃子 ◆8X2XSCHEME 2021/06/29(火)00:20 ID:OP5z1lEO(2/2) AAS
>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。

578(1): 2021/06/29(火)08:12 ID:MxyOwUyS(2/5) AAS
>BE か LE かわかっていない状況

これの意味だが

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

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

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

580(1): 2021/06/29(火)08:38 ID:zFDqDEto(1) AAS
>>579
「他人含めた仕様の強要」という観点が抜けてない？
それに、何回車輪の再開発させるつもりだよ。

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

582: 2021/06/29(火)10:54 ID:c9Dh6S0q(1) AAS
実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない

583: 2021/06/29(火)12:00 ID:gO51uzZW(1) AAS
他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない

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

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

586(1): 2021/06/29(火)14:44 ID:UyxOx+sC(1) AAS
Cというか、それは最早動的型付けか静的型付けかとかの話では

587: 2021/06/29(火)15:11 ID:IWxlvq96(3/4) AAS
>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。

588(1): 2021/06/29(火)15:25 ID:MxyOwUyS(3/5) AAS
pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。

589(1): 2021/06/29(火)15:37 ID:IWxlvq96(4/4) AAS
>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。

590: 2021/06/29(火)18:21 ID:7i3kfcoq(1) AAS
強気なこと書き込む人はだいたい経験浅い

591: 2021/06/29(火)18:35 ID:tM55IFN7(1) AAS
ボカァもうOOPは捨てた！ｗ

592(1): ◆QZaw55cn4c 2021/06/29(火)18:54 ID:qfvhyFdx(1) AAS
>>578
あなたはちょっと残念な人ですね

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

593: 2021/06/29(火)21:05 ID:MxyOwUyS(4/5) AAS
>>592
？
なにか別の話とごっちゃにしてないか？べき論って？？？

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

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

594: 2021/06/29(火)21:08 ID:MxyOwUyS(5/5) AAS
>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。

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

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

595: 2021/06/29(火)23:39 ID:uMLxaJ5z(1) AAS
この話のゴールどこ？

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

上下前次 1-新書関写板覧索設栞歴

あと 349 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.054s