21/06/19 08:09:04.24 do8R3N0p.net
今ｼﾞｯｹｿしたがVC++ 2019でも同じだぬ、
"a.cpp"
#include <stdio.h>
class Foo { public: double some_method() const { return 3.0; } };
double get_Foo() { Foo y; return y.some_method(); }
"b.cpp"
#include <stdio.h>
extern double get_Foo();
class Foo { public: double some_method() const { return 4.5; } };
int main() { printf("%f\n", get_Foo()); Foo x; printf("%f\n", x.some_method()); }
実行結果:
3.000000
3.000000
4.5どこ行った；；；
414:デフォルトの名無しさん
21/06/19 08:55:28.76 MSAvpN3e.net
初歩的なことかもしれませんが質問させてください。
以下の3ファイルがあるとして、src.cpp をコンパイルしようとすると失敗します。
hoge の myclass に対する特殊化を file2.hpp でしてるだけだから OK だと思ったのですが、無理でした。
一方で、file1.hpp の中身を file2.hpp の下の方にコピペしたらコンパイルできます。
この、hoge の特殊化を file2.hpp でしてるという考え方はどう間違ってるのでしょうか。
// file1.hpp
template<class T> void hoge(T);
template<class T> void fuga(T x){
hoge(x);
}
// file2.hpp
#include"file1.hpp"
#include"myclass.hpp"
template<class T, int N> void hoge(myclass<T, N> x){
...
}
// src.cpp
#include"file2.hpp"
int main(){
myclass<int, 10> x;
fuga(x);
}
415:デフォルトの名無しさん
21/06/19 09:03:50.50 N/imZiDN.net
>>406
無理でしたとは？コンパイルエラー？エラーメッセージは？
416:デフォルトの名無しさん
21/06/19 11:19:08.00 xVp2TfT/.net
それ多分特殊化じゃなくてオーバーロード？(違ってたらすまん
hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる
myclass版の前方宣言をfile1.hpp(fugaより前)に書くか、fugaの実装をfile2.hppのインクルードより後にすればいける、と思う
417:はちみつ餃子
21/06/19 14:35:39.56 /f53/cxR.net
>>406
それは >>408 が指摘する通りオーバーロードになってる。
オーバーロードの解決方法は複雑なんで私もちょっと自信はないんだけど、
オーバーロードの候補の内で実引数の型と完全に同一 (または実引数の型に cv 修飾したもの) のものがあれば、
それの優先度はテンプレート引数のマッチより高いので曖昧さは生じずに解決できるのが正しい。
そんで >>408 がいう
> hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる
というのはたぶん関係ないと思う。
Two phase name lookup のルールが適用されるはずだから fuga 内での hoge の呼出しは
その時点では解決を試みられず、 main 内での fuga の呼出しが有った時に
fuga の実体化が起こってそのときに hoge も実体化されるので
宣言の順序にかかわらずどちらの hoge も候補になるはず。
なので include がどうこうというのとは関係なく
file2.hpp のほうの hoge が問題なく呼び出されるべきで、 >>406 に間違いはないと思う。
手元に入れてないから動作確認できないんだけど古い MSVC は Two phase lookup の実装が
おかしかったとか聞くからそのへんで何か問題が起こってるんじゃないか？
GCC や Clang だとかなり古いバージョンでも特に問題なくコンパイルできてる。
418:デフォルトの名無しさん
21/06/19 15:55:55.01 zDrgWeBe.net
>>405
リンクする順番変えたら 4.5 になったり 3.0 になったりするかもしれないししないかもしれない
419:はちみつ餃子
21/06/19 16:47:38.21 /f53/cxR.net
>>396
古典的なツールチェインでは同一のものがそれぞれの翻訳単位に作られる。
その上でリンク時に同じものは同じに統合される。
それが嫌だという場合にはテンプレートには明示的実体化という仕組みがあって、
暗黙的な実体化を抑制する仕組み (extern template) とセットで使うことで
テンプレートの実体をひとつの翻訳単位にまとめることは出来る。
当然だが個別に指定するのはめんどいし、
いまどきの処理系は賢いので、あまり使われてないと思う。
420:デフォルトの名無しさん
21/06/19 18:01:09.17 xVp2TfT/.net
>>406,>>408
うろ覚えだったのでスマンコ
というか自分がその手の順序依存を経験したのはVC2008-2015あたりまでだった気がする
最近のだとC++標準への準拠の設定(コンパイルオプション/Zc:twoPhaseとか)も影響するはず
421:デフォルトの名無しさん
21/06/19 18:07:00.49 xVp2TfT/.net
間違えた、>>406,>>409
2017あたりまで標準への準拠のオプション(名前不明)は指定しないと有効にならなかった気がする、2019では既定
422:デフォルトの名無しさん
21/06/19 18:48:12.63 xVp2TfT/.net
/permissive-
やった(VS2017
2015以前なら>>408のような対策するしかないと思う
423:デフォルトの名無しさん
21/06/20 04:37:05.08 aJXir9C9.net
>>407
失礼しました
短縮して書くと
undefined reference to 'void hoge<myclass<int, 10>>(myclass<int, 10>)'
というメッセージが出ます
コンパイラは g++ 11.1.0 です
用語の使い方が正しいか自信がありませんが、
file1.hpp 内で hoge の宣言と hoge を呼ぶためのユーティリティ関数 fuga の実装をしておいて、後から必要に応じて具体的な型について hoge の実装を書ける、という方がすわりが良いのですが、こういう考え方は間違っていますか
fuga は型によらず hoge を呼ぶための関数なのでその実装を後に回したくない、という思いもあります
424:デフォルトの名無しさん
21/06/20 07:43:07.12 vxtAtGft.net
C言語の double _Complex と C++ の std::complex<double> って実部虚部の並び方とか一緒ですよね？
ヘッダファイル aaa.h で宣言されてる double _Complex * をとる関数に std::complex<double> * を渡したいのですが、やり方がわかりません。
#define 〇〇 std::complex<double>
#include<aaa.h>
みたいにできると想像してるのですが、合っているでしょうか？
425:デフォルトの名無しさん
21/06/20 08:46:26.25 D2z+V4uq.net
>>416
_Complexはただのdouble型変数なのでstd::complex<double>と互換性なし
426:デフォルトの名無しさん
21/06/20 08:59:29.33 vxtAtGft.net
>>417
メモリレイアウトから違うのですか？
では、double _Complex * をとる関数に std::complex<double> * を渡すことはできないということですか？
427:デフォルトの名無しさん
21/06/20 09:04:23.23 D2z+V4uq.net
はい
428:デフォルトの名無しさん
21/06/20 09:11:24.89 vxtAtGft.net
エ！？
_Complex って std::complex の後にできたんじゃありませんでしたか
なぜ、実部と虚部がメモリ上に連続で置かれているという設計にしなかったのでしょうか……
429:デフォルトの名無しさん
21/06/20 09:29:15.86 yGlwqyqX.net
作りが似ている、ということと
互換性が保証されている、ということは同じじゃないぞ
保証があるか否かは規格票で確認することで主観が入る余地はない
俺が見た範囲では保証するとは書いてなかった
430:デフォルトの名無しさん
21/06/20 09:29:35.37 D2z+V4uq.net
_Comolex変数の実部と虚部をそれぞれcreal(), cimag()で取得してstd::complex<double>変数にセットするしかない
431:デフォルトの名無しさん
21/06/20 09:35:42.79 D2z+V4uq.net
_ComplexがC99でstd::complex<T>がC++03
432:デフォルトの名無しさん
21/06/20 09:53:39.49 Q4Tfx6ZF.net
>>415
>>406に嘘書いてないか？
433:デフォルトの名無しさん
21/06/20 10:06:25.46 vSSpHRy4.net
std::complex<double> *hoge;
double _Complex *p = (double _Complex *)&hoge[0];
434:デフォルトの名無しさん
21/06/20 10:06:45.88 76n7YcAv.net
>>424
すみません
どこか矛盾しますでしょうか
手元でコンパイルしてみて、そうなりました
435:デフォルトの名無しさん
21/06/20 10:22:51.51 Q4Tfx6ZF.net
>>408は試してみた？
436:デフォルトの名無しさん
21/06/20 10:33:37.36 76n7YcAv.net
>>427
はい
>>408様の仰る「fuga の実装を後に書く」というのが、>>406に書いた「下の方にコピペしたら」というのです
そして、それらのことを踏まえて、>>415に書いたような疑問を持ちました
ところで嘘というのはどういうものでしょうか
なにか矛盾しますでしょうか
437:デフォルトの名無しさん
21/06/20 11:18:41.97 Q4Tfx6ZF.net
hogeの実装(関数の中身)を実際は書いてなかったとか、何か事実と違うことがあるんじゃないかと思った
だけ
>>415に書いてある理由なら、同じコンパイラであればどこか妥協するしかない気が
fugaの前方宣言だけはfile1に残して、実装を別のヘッダにして後からインクルードするとかは？(>>408で言ったのはそういうことなんだけど
438:デフォルトの名無しさん
21/06/20 14:29:11.44 vxtAtGft.net
>>421-422
今調べたら、C側は実部虚部というメモリレイアウトを保証していて、std::complex 側は C の複素数と同じメモリレイアウトを保証してるようですね
>>423
すみませんCの方が早かったんですね
>>425
ありがとうございます
暗黙のキャストがなぜ許されないのかはまだよく分かっていませんが、キャスト自体は可能なようで、double _Complex (あるいはそのポインタ) をとる C 言語関数に std::complex<double> (あるいはそのポインタ) を適切にキャストして渡すのは問題ないようになってると理解しました
439:デフォルトの名無しさん
21/06/20 15:33:53.67 yGlwqyqX.net
>>430
その件について
ISO/IEC 9899でC++という文言に言及するか
ISO/IEC 14882でCという文言に言及しているか？
430に書かれている限りでは「似ている」だけだが
それからC++03は2003年にC++98のバグ修正をしただけだから
C99より古いぞ
440:デフォルトの名無しさん
21/06/20 15:42:44.16 iNrFbyNf.net
良スレ気体age
441:デフォルトの名無しさん
21/06/20 16:06:01.76 vxtAtGft.net
>>431
いや、すみません。逆に「似ている」とはどういう意味でしょうか
例えば std::complex については
URLﾘﾝｸ(eel.is)
の記述からしてメモリレイアウトは実部虚部と決まってるわけですが、これはソースとは見なせないんでしたっけ？
442:デフォルトの名無しさん
21/06/20 16:11:41.02 vxtAtGft.net
>>431
> それからC++03は2003年にC++98のバグ修正をしただけだから
> C99より古いぞ
ですから、
>>430
> Cの方が早かった
のでは？
あと>>433は「std::complex は C の複素数型と同じことを保証する」という記述は含みませんね
ただ、この場合メモリレイアウトが同じであることの他に要請するべきことってありますっけ？
443:デフォルトの名無しさん
21/06/20 16:13:04.04 vxtAtGft.net
>>431,434
> ですから、
> >>430
> > Cの方が早かった
> のでは？
すみません
間違えました
ごっちゃになってました
これは取り消します
444:デフォルトの名無しさん
21/06/20 17:28:56.50 KYXAfitG.net
URLﾘﾝｸ(stackoverflow.com)
ここを読むとメモリレイアウトは同一みたいなんだよね。むりやりキャストしても問題なさそうな気がするけど
445:デフォルトの名無しさん
21/06/20 17:50:06.69 CGp4yDz+.net
本質的なデータはdouble2つ組だし、順序も普通は実部→虚部だろうし、わざわざパディングや別の変なメンバ混ぜることも考えにくいし
たまたまレイアウト一致する可能性は現実的に高いだろうけど
規格が保証してるかどうかはまた別の話かな
446:
21/06/20 17:59:57.69 DQg/pXKj.net
もう C は C89 で止めれ
C++ は C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない
447:デフォルトの名無しさん
21/06/20 18:02:34.31 D2z+V4uq.net
C/C++の複素数の構造体・クラス間の変換関数を規格として用意してもらうしかない
448:デフォルトの名無しさん
21/06/20 18:23:00.50 zi1IwKwq.net
インテルコンパイラの最適化オプションO2とO3で計算結果が変わって、問題を起こしている箇所を見つけようと思ってるんですが、
$ icpc -O3 src.cpp -lhoge
とコンパイルしてる場合、当然 src.cpp に問題があるのであって別でビルドされたライブラリ hoge は無関係と思って良いですよね？
449:デフォルトの名無しさん
21/06/20 18:49:17.01 zi1IwKwq.net
ゲェーッ -O3 はダメだけど -fast は期待通りに動きました
あまりにも意味不明なのでこれに手を出すのはやめておきます
失礼しました
450:デフォルトの名無しさん
21/06/20 18:57:42.79 CGp4yDz+.net
やべー未定義動作踏んでそう
451:デフォルトの名無しさん
21/06/20 19:09:16.56 akuykRB/.net
あるよなぁ。
FortifyやCodeSonarといった静的解析ツールで検出できたらいいが、どこまでできるんだろう。
452:デフォルトの名無しさん
21/06/20 23:58:43.73 iNrFbyNf.net
複素数とか高々数値メンバが2つとかそれぐらいの話なのに
なんでビットコピーできないと発狂するのかｲﾐﾌ
453:デフォルトの名無しさん
21/06/20 23:59:56.38 iNrFbyNf.net
備え付けの手段で実数部と虚数部毎に代入するとか
構築とかしたらええんじゃ
454:デフォルトの名無しさん
21/06/21 01:37:57.43 czIvoWKn.net
>>437
>>436によるとサイズも並びも一致することを規格が暗に示してるようなんだ。1つ目の回答を見てくれ
455:デフォルトの名無しさん
21/06/21 01:48:21.79 0g7/88j3.net
まだ「暗に」とか言ってんのこのキチガイ
コイツのせいで不必要に大事になった感はあるよね
456:デフォルトの名無しさん
21/06/21 01:52:02.85 Im5VqdJw.net
>>446
お前のコードで誰にも迷惑かからないなら、もう規格云々はいいから自分の思い込みたいように好きにやれば良いよ
457:デフォルトの名無しさん
21/06/21 09:03:02.99 G6bnr+rx.net
T* をとるオーバーロードコンストラクタに const T* x を渡したら、argument do not much だからとエラーになりました。
が、(T*)x を渡したらOKでした。
(T*)をつけてようがつけてなかろうが、x というポインタの const 性は変わりませんよね？
（つまり x を変える挙動があったらプログラムは終了しますよね？）
なぜ引数の型のマッチには (T*) が必要なのでしょうか。
できればキャストしたくないので、こうすれば避けれるとかこう思えば安全というのがあったら教えていただきたいです
458:デフォルトの名無しさん
21/06/21 09:16:37.40 yA/sh2j8.net
>>449
const性変わるんじゃない？
const T* xなんだから xはの先にある*xは変えてはいけないという指示をコードかいた人は出していて
そのT*をとるコンストラクタはその中で変更する可能性を言ってるんだから
T*にキャストして渡したらコンストラクタの中で変更され可能性が出るよ
459:デフォルトの名無しさん
21/06/21 09:20:07.55 yA/sh2j8.net
>>449
ああ、だから>なぜ引数の型のマッチには (T*) が必要なのでしょうか。
というと
本来ならconst指定されてて変更してはいけない変数を、変更するけどいいのね？というコンパイラからの確認的なもの
460:デフォルトの名無しさん
21/06/21 09:34:04.75 G6bnr+rx.net
>>450
> const性変わるんじゃない？
ありがとうございます。
誤解してました。
（というか、そこ変えれるなら何でもありな気が……）
>>451
実は、他人の作ったライブラリとの橋渡しでこういう問題が出ました。
知る限りではそのライブラリは引数のポインタの指してる先を変えないのですが、どうやらキャストはするしかないようですね。
この件で (T*) とは別に const_cast<T*> なるやり方の存在も知って、Cスタイルのキャストよりはこちらの方が良いという説明がいろんなところでされてるのですが、正直全く同じものに見えます。
なぜ const_cast の方がマシなのでしょうか？
461:デフォルトの名無しさん
21/06/21 09:36:14.94 yU7HyP9W.net
うん、マシだね
特にその問題では
462:デフォルトの名無しさん
21/06/21 09:49:17.82 yA/sh2j8.net
>>452
Cスタイルキャストは状況に応じてよしなにキャストしてくれるんだが
これがたまに意図しないキャストになる場合があるから、意味を明確にするためにC++のなんちゃらキャストをする
よほどのことがないと変なキャストにはならないとは思うけど一応
463:デフォルトの名無しさん
21/06/21 09:58:36.45 yU7HyP9W.net
const_castはint*→char*のように指す先の型は変更できない
だから、そのような変更をしようとしたらエラーになるし
そのような変更を意図していないことも示せる
464:デフォルトの名無しさん
21/06/21 10:07:37.10 5d1ivHhj.net
>>452
誤解してるようだけど、constってのは基本的にはバグ抑止のためのもので
文法上のルールに過ぎないのよ
実行時にチェックが走ったりするわけではない
で、意図的に破ることも一応出来る。意図的に破るときはそれが見てわかるようにconst_cast使おうね、
Cスタイルのキャストは何でも通しちゃうから避けようねってだけ
465:デフォルトの名無しさん
21/06/21 10:07:43.43 G6bnr+rx.net
>>454-455
なるほど。ありがとうございます
今は const_cast で渡すことにします
466:デフォルトの名無しさん
21/06/21 11:07:11.82 JzAz8iJE.net
>>441
この件諦めきれなくて少し調べてみたら、
-O3 はダメだが
-O3 -static -ipo は正常に動く
ことが分かった
更に、icpcでなくg++なら最適化レベルによらず正常に動くことが分かった
この場合陥っていがちな失敗なんてないですかね
ググってもなかなか体系的な知識に出会えなくて、、、
467:デフォルトの名無しさん
21/06/21 15:28:43.32 os4CEfZ3.net
諦め切れないくらい気になるなら -S で .asm コード見るべき
468:デフォルトの名無しさん
21/06/21 15:39:13.82 s5hePRzy.net
こんなところでC++が中途半端に出来るだけが自慢の専門卒みたいな連中に尋ねるよりも
大学の先生かチューターの院生に尋ねた方がいいだろう
進みたい研究室があればそこに行って訊くと良い
469:デフォルトの名無しさん
21/06/21 16:20:08.51 mdGWC+9J.net
>>458
たぶん初期化漏れとかの未定義動作
-Wallでコンパイルすれば何かわかるんじゃね
470:デフォルトの名無しさん
21/06/21 16:27:39.69 JzAz8iJE.net
>>459-461
すんませんあざす
asmコードとか未知の領域ですけど勉強になりそうですね
-Wallは一応常につけてて、ワーニング全部潰すようにはしてます
全部のオブジェクトにvolatile付けたり外したりしてみようかな
471:デフォルトの名無しさん
21/06/21 17:09:40.79 os4CEfZ3.net
適当に弄って適当に動いたように観えて
適当に解決したって言い張るやつは成長しない
472:デフォルトの名無しさん
21/06/21 17:40:48.54 uOMSqfSW.net
短かったり切り出せるようなコードだったらcompiler explorerとかもあるよ
473:はちみつ餃子
21/06/21 17:44:51.49 5bV+3LP7.net
const ではないオブジェクトについて const 付きにキャストしている場合には
const を剥がしてから書き込みをすることは OK だが、
元々 const なオブジェクトから const を剥がして書き込むのは未定義で、
実際に最適化で壊れることはある。
ちなみに const なオブジェクトから const を剥がしても読むのみなら OK。
LLVM 9.0 で const 領域への書き込みを最適化で削除するする方針になってる。
URLﾘﾝｸ(releases.llvm.org)
474:デフォルトの名無しさん
21/06/21 20:26:42.47 yU7HyP9W.net
>>460
院生ねえ。。。修士の新人は手放しできないんだけどな
レッテルで色眼鏡つかう奴って
情報処理特種とかでもひれ伏すのか？
学生みたいなコード書くアホ知ってるけどｗ
475:デフォルトの名無しさん
21/06/21 23:06:59.47 0VSE6TcG.net
インテルコンパイラ様ともなれば
プラグマで関数単位で最適化レベルを変えられるんじゃないの
動くパティーンが分かっているのなら二分探索で問題の箇所を見つけるこ
とができうる
476:デフォルトの名無しさん
21/06/22 00:52:42.42 JdLoAtTW.net
C++の参照で渡した構造体を
中で別の構造体に実態コピーしたい時ってどうしたらいいんでしょう
void CTest::SetData(Kouzoutai &kozo)
{
if(kozo.judge == 1){
_KozoTmp = kozo;
}else{
//色々する
}
}
とすると、_KozoTmpってkozoと同じアドレスになっちゃって、
_KozoTmp.judge = 10とかしちゃうともとのkozo.judgeも変わっちゃいますよね
ポインタだったら
_KozoTmp = *kozo;
とかやればいいんでしょうけど
参照で渡した時ってどう書けばいいんでしょう
477:デフォルトの名無しさん
21/06/22 01:00:09.80 cH2Us/Cy.net
それで普通にコピーされるだろ
なんでされないと思うの？
478:デフォルトの名無しさん
21/06/22 01:05:17.48 JdLoAtTW.net
参照にした時って、ポインタみたいにアドレスコピーにならないの?
479:デフォルトの名無しさん
21/06/22 01:15:12.93 cH2Us/Cy.net
あのさ、_KozoTmpは何だ？Kouzoutai型だろ？Kouzoutai*でもKouzoutai&でもないだろ？
なんでアドレスなんか持てると思うの？
480:デフォルトの名無しさん
21/06/22 01:21:47.48 JdLoAtTW.net
あ、そうなんだ
ありがとうございます
kozoを参照で渡したから
_KotoTmpも無理矢理アドレスになるかと思ってました
481:はちみつ餃子
21/06/22 01:22:19.02 Ikkk/uWu.net
>>468
参照というのはいうなれば別名。
SetData の実引数と kozo は「同じもの」と考えて構わない。 (少なくともその場合は)
482:デフォルトの名無しさん
21/06/22 10:52:00.08 2AbGnqy7.net
copy コンストラクタ と move コンストラクタ ってみんなちゃんと書いてる？
デフォにまかせてる？
483:デフォルトの名無しさん
21/06/22 11:08:19.79 jiZrgPwV.net
ものによる
ポインタやハンドルがあれば書いたり=delete;したり
実体だけなら大抵デフォ
484:デフォルトの名無しさん
21/06/22 11:38:53.75 PhquAAua.net
=defaultが多い
485:デフォルトの名無しさん
21/06/22 11:45:11.84 hpNVAZMN.net
コピーコンストラクタがあったらムーブ自動生成されないんでしょ？
486:デフォルトの名無しさん
21/06/22 13:58:37.72 jiZrgPwV.net
俺、タイプ量の少なさは美しさの１つだと思ってるから
=default;は本当に必要なときだけ書く
487:デフォルトの名無しさん
21/06/22 14:51:15.52 4bX8g7Cj.net
doxygenでドキュメント作成してるけどソースが見づらくてコメント無い方がいいのではと思ってしまう
488:デフォルトの名無しさん
21/06/22 15:03:38.14 zJk9T2bQ.net
>>479
関数ヘッダーだけでええんちゃうん？
489:デフォルトの名無しさん
21/06/22 16:50:07.47 T8maLWCY.net
>>480
テンプレート系のライブラリなので
490:
21/06/22 19:42:13.49 9FGytWqi.net
もう C は C89 で止めれ
C++ は C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない
491:
21/06/22 19:43:07.45 9FGytWqi.net
>>473
反対せざるを得ない意見です…‥
492:
21/06/22 19:43:53.44 9FGytWqi.net
>>474
コピコンはちゃんと書きますが、ムーブ？何？それ美味しいの？
493:デフォルトの名無しさん
21/06/22 20:42:23.52 InXfs1nZ.net
>>4
494:77 あったら使われる(一時オブジェクトの場合に)ってだけだぞ やること一緒なら書かんでいい、時間の無駄
495:デフォルトの名無しさん
21/06/22 21:50:49.86 7Ks2gqqv.net
>>474
デフォルトで済まない場合だけ明示的に記述するのが普通じゃないかねぇ。
=defaultにするか暗黙定義にするかは好みがあるだろうけど。
496:デフォルトの名無しさん
21/06/22 22:22:06.65 4bX8g7Cj.net
>>484
美味しいとき”も”あるよ
497:デフォルトの名無しさん
21/06/22 22:45:00.81 d6n1ZZoB.net
>>482-484
ロートルはちょっと黙ってて
498:はちみつ餃子
21/06/23 04:03:41.13 pZ1DtdbH.net
>>482
C89 ってことは暗黙の関数宣言とかのウンコ機能も含めて言ってるわけ？
499:デフォルトの名無しさん
21/06/23 04:16:44.74 Vmwdc4hc.net
>>485
最近デカくて古いコンテナのコピーに悩まされてるから、アドレスを託すみたいな形でムーブしたい
500:デフォルトの名無しさん
21/06/23 06:19:12.12 rIfoeFmJ.net
コピー回避なんていくらでもどうにでもなるのに
どんなヘボなんだ
501:デフォルトの名無しさん
21/06/23 08:31:09.62 nCHirhrB.net
いや、だからそれがアドレスを渡すとか参照で渡すってことでしょ
502:
21/06/24 20:04:48.26 i6kIKJxB.net
>>488
黙れ、小僧！
お前に C++ の苦しみ
503:が分かるのか？
504:
21/06/24 20:10:35.44 i6kIKJxB.net
>>489
ウンコ機能はC99の方が多い、という認識です
505:
21/06/24 20:11:16.37 i6kIKJxB.net
>>487
具体的に
506:デフォルトの名無しさん
21/06/24 21:10:55.26 3QBHDC7A.net
>>495
メモリ確保するようなクラスの場合、メモリ確保の手間省ける。
それ以外でムーブにコピー以上の利点知らない
507:デフォルトの名無しさん
21/06/25 00:44:09.12 +R97TjGx.net
んまー（通常の関数呼び出しと違って）コピコンは放っといても勝手に呼び出しが削減される（副作用がある可能性ガン無視で）からな
昔から
508:デフォルトの名無しさん
21/06/25 00:55:10.74 +R97TjGx.net
コピコン呼び出し最適化に頼らねばにっちもさっちも行かないシチュエーションは多々あるから
右辺値参照はﾏｼﾞ不完全
例えば
Foo operator+(const Foo& lhs, const Foo& rhs) {
Foo x(lhs); // 馬鹿正直にやったらコピー1回
x += rhs; // Foo& Foo::operator+=()が定義済みとする
return x; // 馬鹿正直にやったらコピーがもう一回
}
みたいな、
とこの前思いました
※ 個人の感想です
509:
21/06/25 01:03:22.61 pWufOIHg.net
>>496
要はクラスC のオブジェクトA の中にポインタがあった場合、オブジェクトA を今後一切つかわない前提でオブジェクトA の持つポインタの値をオブジェクトB にコピーするやりかた、ということですよね
言われるほど凄い機能にも革新的な機能にも思えないので来ているのですが、クラスを返すときには、もしかしたら使えるかもしれませんね
でも、すでに RVO があるのでしょう？
510:デフォルトの名無しさん
21/06/25 01:11:32.66 xLwe8284.net
>>498
それは左辺値参照だよ。
511:はちみつ餃子
21/06/25 01:12:27.64 /YhIejlL.net
>>499
それが出来るということは重要じゃなくて文脈によって勝手に使い分けられるということに意味があるんだよ。
512:デフォルトの名無しさん
21/06/25 04:23:14.07 2CfGrUVh.net
move対応してないデカいクラスはマジ迷惑だろ
513:デフォルトの名無しさん
21/06/25 06:23:42.07 +QaNJXlp.net
ポインタ、参照、this、スマポ、[&]
いくらでもどうにでもなる
514:デフォルトの名無しさん
21/06/25 06:38:22.69 byKvXpEn.net
えっ老害？？
515:デフォルトの名無しさん
21/06/25 06:40:16.50 FhN3idtW.net
>>499
RVOはC++17で保証されたけどNRVOは保証されてない
516:デフォルトの名無しさん
21/06/25 07:44:44.86 +QaNJXlp.net
C++03時代を生きてないやつからはそう見えるのか
517:デフォルトの名無しさん
21/06/25 08:48:57.50 z3/X9CIt.net
{a, b, c,...} が a, b, c,... という要素からなるリストを表すとき、
{a, {b, {c, d}, e}, f, g, {h, i},...}
みたいな構造は a, b, c,... が全部同じ型だとしても tuple としてしか表せませんよね？
518:デフォルトの名無しさん
21/06/25 10:23:01.70 Wd+wOk9Z.net
json
yaml
listのtree
なんでも
519:デフォルトの名無しさん
21/06/25 10:45:58.24 z3/X9CIt.net
>>508
ありがとうございます
そうですね。STLとかboostのコンテナに囚われ過ぎてました
520:デフォルトの名無しさん
21/06/25 10:52:18.80 tyTj/nU0.net
老害はC++スレに書き込むなよ
昔の話ばっかだよおじいちゃん
521:デフォルトの名無しさん
21/06/25 13:12:18.39 +QaNJXlp.net
後から入ってきたくせに図々しいやつだな
先住権てやつでこっちが偉いんだよ
気に入らねえんなら他当たるか自分でサーバー立てな
522:デフォルトの名無しさん
21/06/25 13:16:46.30 cHfQsTpJ.net
C++03の話なんてもうすんなよ
C++11からはもう別言語やんか
523:デフォルトの名無しさん
21/06/25 13:27:35.28 +QaNJXlp.net
おまえの主観は関係ない
524:はちみつ餃子
21/06/25 13:41:54.77 /YhIejlL.net
>>506
C++03 時代を知ってるからそれが (少なくとも C++11 に比べれば) クソだってこともよく知ってるよ。
525:デフォルトの名無しさん
21/06/25 13:43:28.90 ALny3hkX.net
本気で別言語だと思ってるやつって大抵何も作ってないゴミガキだと思うけどなぁ・・
STL的なアルゴリズムや新要素と親和性が高いのは、基本的に標準ライブラリだけなんだが
最近各種コンストラクタ(ムーブ込み)、代入等だけ長々と書いて「実質ほぼ何もしないクラス」を書いてドヤってるアホとかよく見かける
便利になってるのは確かだけどね・・
526:デフォルトの名無しさん
21/06/25 13:45:10.88 ALny3hkX.net
>>514
俺も必要もなく03以前で書きたいとはまず思わんが、クソとか貶すのはやめた方がいいと思うよ
527:デフォルトの名無しさん
21/06/25 18:07:04.42 aibvvCTW.net
gets()とか好きそう
528:デフォルトの名無しさん
21/06/25 18:33:58.19 xqBptTy/.net
(σ・∀・)σｹﾞｯﾂ!!
529:デフォルトの名無しさん
21/06/26 00:08:46.09 O9GH5wVp.net
ゲッツって初めて聞いた
ゲットエスって読んでたんだが
530:デフォルトの名無しさん
21/06/26 07:06:09.54 MV3qzcHy.net
こことCスレでは古くからあるネッスラだよ
531:デフォルトの名無しさん
21/06/26 07:21:39.68 +MI3rh96.net
scanf()をスキャンフと呼ぶけどprintf()をプリントエフと呼ぶ感じ
532:デフォルトの名無しさん
21/06/26 08:05:40.57 vR4ZYNRj.net
プリンテフ
533:デフォルトの名無しさん
21/06/26 08:08:29.30 EcYCTODA.net
ifndef イフンデフ
534:デフォルトの名無しさん
21/06/26 11:51:24.28 7nyRjnb4.net
アとイ
535:デフォルトの名無しさん
21/06/26 13:16:45.08 l0P5IISj.net
C++20でもバイナリファイルからdoubleとかの値を読み出す時って未だにreinterpret_cast使う感じ？
536:デフォルトの名無しさん
21/06/26 16:37:39.40 qjgQHw2b.net
HTML★ふとまる
537:デフォルトの名無しさん
21/06/27 10:16:13.68 0fbyaJPK.net
basic_istream::readの引数がvoid*なら何も悩まずに済むのにな
538:デフォルトの名無しさん
21/06/27 11:20:36.11 hddKqCef.net
ファイルに書いている時点でアラインメントの保証が難しいから結局memcpyになる気がする
539:デフォルトの名無しさん
21/06/27 12:53:25.35 CJK40NDs.net
アライメントの問題はファイル関係なくね↑？
540:デフォルトの名無しさん
21/06/27 13:14:05.28 CJK40NDs.net
エンディアン変換が関係しない場合
C++20でもバイナリファイルからdoubleとかの値を読み出す時はfread()
書き込むときはfwrite()
何の問題も無いし速い……
541:デフォルトの名無しさん
21/06/27 13:16:25.37 CJK40NDs.net
ていうかエンディアン変換が関係する場合でも
fread()してからメモリ上でエンディアン変換しても良いし
メモリ上でエンディアン変換してからfwrite()したら良い
特にファイル内容全体がメモリ上に収まるケースとかは上記だけでほとんど何も考えなくてもよい
542:デフォルトの名無しさん
21/06/27 13:48:27.15 NNV++T6E.net
P言語、Ruby、Java、C#などでファイルを読んだり書いたりしなければならなくなることを想定したファイル仕様にしたほうがいいと思うけどどうかな
543:はちみつ餃子
21/06/27 13:55:06.53 +5rTVQj/.net
スタンダードレイアウトな型はバイナリレベルでコピーしてかまわないし
結果的に fwrite して fread できることは保証されるが、
具体的なレイアウトについての保証はない (他の処理系では同じレイアウトにならないかもしれない)
ということも合わせて考えると適当なシリアライザは挟んだほうが良いな。
多言語を意識しつつ高速なバイナリフォーマットというと MessagePack あたりかな？
544:デフォルトの名無しさん
21/06/27 13:57:17.27 mY5L/v8k.net
PerlやPythonでバイナリ読み書きするのに何の支障もないだろ。
545:はちみつ餃子
21/06/27 14:00:08.24 +5rTVQj/.net
>>534
読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。
546:デフォルトの名無しさん
21/06/27 14:16:00.40 U1pSP8r9.net
バイナリなんだからどう扱おうが自由だろ
言語のせいにするのは本人の技術が無いから
言い訳するな
547:
21/06/27 14:25:54.48 I46qTe+f.net
今時数値をバイナリで読み書きするとか、あり得ないのでは？
548:デフォルトの名無しさん
21/06/27 14:30:38.43 NNV++T6E.net
Comparison of data-serialization formats - Wikipedia
URLﾘﾝｸ(en.wikipedia.org)
549:デフォルトの名無しさん
21/06/27 15:19:43.80 o9peEwic.net
>>537
バイナリでないと実用的でないデータなんていくらでもあるし。画像、動画、アーカイブ、db、ip...
qzはもうエロ画像見るなよ。
550:
21/06/27 15:44:56.12 I46qTe+f.net
>>539
ごめんなさい誤りましたので謝りますからその刑だけは平にご容赦を‥‥
551:デフォルトの名無しさん
21/06/27 15:47:12.10 mY5L/v8k.net
>>535
保証されてるから支障はない。エンディアンが違うデータだって読み書きできる。
552:はちみつ餃子
21/06/27 15:54:09.98 +5rTVQj/.net
>>541
データがリトルエンディアンなのかビッグエンディアンなのかわかっていればね。
C++ が単にメモリ上のデータを書き出したときに、それがどっちなのか、
(言語としては) 保証してないって話をしてるんだよ。
553:デフォルトの名無しさん
21/06/27 16:14:20.16 jKhjPg/S.net
C++20でstd::endianが使えるようになるけど
554:
21/06/27 16:39:33.97 I46qTe+f.net
シェアの高かった 68 系かインテルザイログ系か、の二分図がここにも残っているのですか
もう UTF-8 のようなエンディアンに依存しないバイナリが優秀だ、という価値観にするべきかと
555:デフォルトの名無しさん
21/06/27 17:01:10.06 CxF0bT8t.net
インターネットのプロトコルはビックエンディアン
USB等のPC系発祥のデバイスはリトルエンディアン
この辺はもう変更しようが無いだろ
556:はちみつ餃子
21/06/27 18:13:48.48 +5rTVQj/.net
>>544
ここでのトピックは >>530 に対しての反論。
メモリ上にあるバイト列には保証がないからなんらかの明確な
データ交換用フォーマットに変換する処理が必要という話で、
出力先のデータ交換用フォーマットが BE か LE かなんていう以前の段階。
557:はちみつ餃子
21/06/27 18:17:55.59 +5rTVQj/.net
ファイルに書き出すにあたって「エンディアンの変換が不要なら」という前提を置きたくねぇなぁという話だな。
パディングとかも入るかもわからんし。
558:
21/06/27 19:47:44.56 igNiq52h.net
>>546
であれば、私はどちらかというと >>530 の味方側ですね、>>530 がそう意図しているかどうかは不明ですが、処理系のエンディアンを仮定することなくコードを書くことは可能だったと記憶しています。‥‥①
ただ同時に、確かにパフォーマンスの点で過剰な不利を承知で >>537 を再提示するべきかな
つまり、>>537 みたいな画像フォーマットはありました PPM/PGM/PBM
ｽﾚﾘﾝｸ(tech板:73番)
このコードは①を検証したものだったかと遠い記憶に残っていますね
あ、罰ゲームは勘弁ね、私だってエロ画像は見たい‥‥URLﾘﾝｸ(www.youtube.com)
559:はちみつ餃子
21/06/27 20:29:20.98 +5rTVQj/.net
>>548
だからそういうコードが書けるかどうかという話じゃなくて
書かなきゃなんない (書くべき) ねという話なんだってば。
560:
21/06/27 20:58:56.14 2wFMzLzL.net
>>549
それは失礼しました
561:デフォルトの名無しさん
21/06/27 22:44:17.18 mY5L/v8k.net
>>542
C++だって読もうとするバイナリデータのエンディアンを事前に知らなきゃならんのは変わらんだろ。
自分で書いたものを読むならエンディアンが一致するのはあたりまえ。
562:はちみつ餃子
21/06/27 23:46:30.32 +5rTVQj/.net
>>551
> エンディアンを事前に知らなきゃならんのは
知らなきゃならないがわからん (保証されてない) のだという話をしている。
C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。
言語が何であれデータフォーマットが固定されてないとどうにもならん。
563:デフォルトの名無しさん
21/06/27 23:53:27.71 mY5L/v8k.net
>>552
それは言語関係ない話だろ。
564:はちみつ餃子
21/06/28 00:31:47.85 nxXyAxnK.net
>>553
言語に関係あるという話はしてないよ。
565:デフォルトの名無しさん
21/06/28 00:34:04.32 AdoNh79c.net
Javaはメモリモデルも明確に決まってたんじゃないかな
566:デフォルトの名無しさん
21/06/28 02:47:25.75 DsF+RsPk.net
多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ！
567:デフォルトの名無しさん
21/06/28 03:12:57.95 DsF+RsPk.net
どうしてもバイナリファイルが良いという向きは、
パディングとかもfwrite()とfread()で取り扱い得る
といっても単に適当なサイズのバイトの配列として読み書きして
メモリ上でご使用のアーキテクチャーに合わせることになるが
fwrite()とfread()を使わなければもっとﾏｼになるという類の話ではない
568:デフォルトの名無しさん
21/06/28 03:44:20.73 QdlxBFRk.net
別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか
569:
21/06/28 07:17:27.29 oYDZ1nWa.net
>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします
570:デフォルトの名無しさん
21/06/28 07:48:39.66 cZa6zFVz.net
>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。
571:デフォルトの名無しさん
21/06/28 08:30:45.47 RYml5aTx.net
これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい
572:デフォルトの名無しさん
21/06/28 09:09:23.58 XSoi24Ug.net
僕はノンバイナリーだから読みたくないです
573:デフォルトの名無しさん
21/06/28 09:56:34.91 SQEqm/bz.net
こんどはバイナリに噛み付いてるキチガイがいるな
574:デフォルトの名無しさん
21/06/28 11:09:48.91 bLKGwGq9.net
標準ライブラリのみであれば車輪の再発明しか手段がない？
575:デフォルトの名無しさん
21/06/28 12:52:58.19 bIZ7S0Sd.net
MsgPack は json と同じで無駄が多い
576:デフォルトの名無しさん
21/06/28 12:59:22.39 bIZ7S0Sd.net
>>558
温暖化詐欺SDG詐欺と手口が一緒だな
577:デフォルトの名無しさん
21/06/28 13:35:34.04 quG4wdoj.net
>>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 [インストール済み、自動]
578:デフォルトの名無しさん
21/06/28 13:52:30.89 5OdlGlMi.net
Comparisonて何て読むの？
コンパリソン？
579:デフォルトの名無しさん
21/06/28 14:55:11.19 qFu4iqR6.net
msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット
580:デフォルトの名無しさん
21/06/28 14:56:29.69 R7ScYjSP.net
>>568 こんｐぇぁりｚん URLﾘﾝｸ(www.google.com)
581:デフォルトの名無しさん
21/06/28 15:26:12.03 JcAv6JCW.net
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合
この表現すき💛
582:デフォルトの名無しさん
21/06/28 15:26:13.01 JcAv6JCW.net
>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合
この表現すき💛
583:デフォルトの名無しさん
21/06/28 16:13:11.20 dKXkMhte.net
>>569のお勧めは何？
理由もセットで教えて頂戴。
584:デフォルトの名無しさん
21/06/28 16:32:50.30 uBCftstC.net
「モジュール」はC++で作られたパッケージを配布しやすくしますか？
585:はちみつ餃子
21/06/29 00:03:30.47 OP5z1lEO.net
>>560
そうだよ。 その当たり前の話をしてるんだよ……。
互換性の問題というのは内部的なものなら問題が起きたときに修正すればいいが、
外部に出ているデータはそれに皆が合わせなければならない仕様と化すので
特定の C++ 処理系 (実行環境) でなら処理できるけど
出力されたデータフォーマットの詳細はわからんし処理系のバージョンがちょっと変わったら変わるかもしれん
というのでは困るやんというごく普通の話。
(もちろん普通の処理系はちょっとバージョンが更新されたくらいでは
バイナリ互換性をあまり壊さないように配慮するのが普通ではあるけど。)
586:デフォルトの名無しさん
21/06/29 00:15:58.47 MxyOwUyS.net
>>575
いつのまにか話ずらしてんな。
>>535
>読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。
言語上の型とバイナリの対応付けはPerlでもPythonでも保証されてるんだよ。
587:はちみつ餃子
21/06/29 00:20:30.40 OP5z1lEO.net
>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。
588:デフォルトの名無しさん
21/06/29 08:12:22.23 MxyOwUyS.net
>BE か LE かわかっていない状況
これの意味だが
・全く何の情報もない状況
→どんな言語を使おうが正しく読める保証がないし論ずるだけ無駄。
・>>552の「C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。」状況
→「自環境のエンディアン」で読めるのはC++でもPerlでもPythonでも同じ。
589:デフォルトの名無しさん
21/06/29 08:29:00.28 qbDSHPwG.net
>>573
方法はともかく、普通にビット列かバイト列のレベルで仕様を決めてその通りに読み書きすりゃいいんじゃない
C++プログラマなら生データの扱いは得意でしょ
とはいえ手間がかかるしミスを生じやすいのも事実なので、めんどくせえ今すぐ読み書きしたいってだけならprotobufとかavroとか他にも色々あるよ
msgpackとの大きな違いはスキーマの有無で、スクリプト言語じゃなきゃスキーマはあったほうが便利だし、一般に実装が高速になりやすくデータサイズも小さくできる
590:デフォルトの名無しさん
21/06/29 08:38:20.49 zFDqDEto.net
>>579
「他人含めた仕様の強要」という観点が抜けてない？
それに、何回車輪の再開発させるつもりだよ。
591:デフォルトの名無しさん
21/06/29 08:57:28.61 bpKPj1F0.net
>>580
強要したいならちゃんと仕様書書いて押し付けるだけの話
実装が面倒ってんならそれこそprotobufのようなスキーマのある汎用フォーマットならスキーマさえ書いとけば大抵の言語でserde用の型の自動生成までやってくれるよ
その点で言えばmsgpackは所詮mapなんで、仕様を強要したいなら別途仕様書が必要になるよ
592:デフォルトの名無しさん
21/06/29 10:54:24.87 c9Dh6S0q.net
実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない
593:デフォルトの名無しさん
21/06/29 12:00:43.57 gO51uzZW.net
他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない
594:デフォルトの名無しさん
21/06/29 13:20:29.38 IWxlvq96.net
>>560
Perlでバイナリを扱うのは物凄く大変だった。
さまざまな自動変換がかかってしまうので、結局どうなるのかが分からない事が
多かったから。
例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
なってしまったり、物凄く難しかった。
ASCIIコードの数値番号を取得したいと思っても、結果が数値の入った文字列に
なったりとか、よく分からない事が多かった。
何を何に変換しているのか、めちゃくちゃ難しかった。
それがRubyになって、素直な感じになった。
595:デフォルトの名無しさん
21/06/29 13:23:14.00 IWxlvq96.net
>>584
16進数も複雑だった。
単に表示したいために16進数の文字列に直したら、どこかで勝手に数値として
解釈されていつの間にか思いもよらぬ「もの」に変化したりとか。
それで、バイナリや文字を細かく扱い際には、如何にCが楽であるかを思い知った。
596:デフォルトの名無しさん
21/06/29 14:44:15.68 UyxOx+sC.net
Cというか、それは最早動的型付けか静的型付けかとかの話では
597:デフォルトの名無しさん
21/06/29 15:11:46.24 IWxlvq96.net
>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。
598:デフォルトの名無しさん
21/06/29 15:25:41.01 MxyOwUyS.net
pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。
599:デフォルトの名無しさん
21/06/29 15:37:31.39 IWxlvq96.net
>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。
600:デフォルトの名無しさん
21/06/29 18:21:23.30 7i3kfcoq.net
強気なこと書き込む人はだいたい経験浅い
601:デフォルトの名無しさん
21/06/29 18:35:19.68 tM55IFN7.net
ボカァもうOOPは捨てた！ｗ
602:
21/06/29 18:54:36.80 qfvhyFdx.net
>>578
あなたはちょっと残念な人ですね
実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①
①の証拠は >>548
ことほど左様に、処理系に独立して LE/BE を書き分けることができるのなら「～するべき」とかいう「べき論」は無意味でしょう
多分、はちみつ氏は①を失念していたのでしょう、べき論なんて振り回しても無駄なのに、あいかわらずべき論に拘泥するところなどは「ダメリカ様が守ってくださる！」的な馬鹿左翼並の振る舞いですから、そろそろあきらめるべきでしょうね
603:デフォルトの名無しさん
21/06/29 21:05:01.01 MxyOwUyS.net
>>592
？
なにか別の話とごっちゃにしてないか？べき論って？？？
>実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①
C/C++じゃなくてもPerlやPythonだってLE/BE書き分けられる手段は用意されているって話をしていただけなんだがな。
604:デフォルトの名無しさん
21/06/29 21:08:28.05 MxyOwUyS.net
>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。
>例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
>文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
>なってしまったり、物凄く難しかった。
これなんかまさにそうだな。
605:デフォルトの名無しさん
21/06/29 23:39:33.94 uMLxaJ5z.net
この話のゴールどこ？
606:デフォルトの名無しさん
21/06/29 23:59:54.04 yAVMK7JX.net
pack/unpack使え
607:デフォルトの名無しさん
21/06/30 00:03:10.10 6riO4yVW.net
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を使ったら何も起きない
608:デフォルトの名無しさん
21/06/30 00:07:43.06 d2kdzRUr.net
Encodeは日本語入りのパスとか$ARGV[]とかをutf8にしたり戻したりするのに使う
コマンドプロンプトの文字をutf8にしたら実はEncode要らんかもしれんがそこまでは知らん
609:デフォルトの名無しさん
21/06/30 00:40:50.04 uW/S3RKL.net
Perlの特定の某なんか出されても知らんがな……
610:デフォルトの名無しさん
21/06/30 03:10:15.08 vkj6zKzF.net
Perl Python PHP Java C# EcmaScript TypeScript Javaくらいは流石に教養だろうさ。
611:デフォルトの名無しさん
21/06/30 07:38:15.64 F9CAzHJ+.net
func の返り値を変数 hoge に受けるときって
auto hoge = func();
auto& hoge = func();
auto&& hoge = func();
のいずれにおいてもオブジェクトの再構築 (コピー) は行われないって思って良いんですよね？
612:デフォルトの名無しさん
21/06/30 10:58:31.75 x9tVpfG6.net
no
613:デフォルトの名無しさん
21/06/30 11:13:43.85 EDSlPJC8.net
>>601
c++17：値のコピー省略を保証、て奴かね。
戻り値が右辺値かどうかで変わるんじゃない？
614:デフォルトの名無しさん
21/06/30 12:11:32.93 2LaR0NZ5.net
関数の戻り値は必ず右辺値のはずだが。
615:デフォルトの名無しさん
21/06/30 12:19:35.40 8KWEqHlz.net
んなこたーない
616:デフォルトの名無しさん
21/06/30 12:29:48.99 sL9lkuh+.net
参照返し……と思ったけど、
参照て右辺値だっけ？左辺値だっけ？
617:デフォルトの名無しさん
21/06/30 13:29:54.24 2LaR0NZ5.net
関数の戻り値は、戻り値の型が左辺値参照で有る場合だけは左辺値で、
それ以外は右辺値らしい。
618:デフォルトの名無しさん
21/06/30 13:34:03.56 2LaR0NZ5.net
>>606
戻り値の型が右辺値参照の場合、関数呼び出しの結果は、xvalueだが、分類上は、右辺値でもあり、glvalueでもある。
戻り値の型が左辺値参照の場合、関数呼び出しの結果は、左辺値。
戻り値の型が参照型でない場合、関数呼び出しの結果は、prvalueで、右辺値。
prvalue = 純粋右辺値。
glvalue = 一般化左辺値。
xvalue = 消えかかっている値。謎の値とも言われる。
619:デフォルトの名無しさん
21/06/30 13:39:20.73 2LaR0NZ5.net
>>601
一番上の書き方だと、少なくとも move になる。
下の二つは、moveもcopyも行われないで、アドレスだけが参照型変数に
入るのだと思う。
620:デフォルトの名無しさん
21/06/30 14:18:47.26 DhAhW4Ik.net
>>609
funcの戻り値型が左辺値参照の場合moveにはならんのでは？
621:デフォルトの名無しさん
21/06/30 14:56:49.27 2LaR0NZ5.net
>>610
その通りで、コピーコンストラクタが呼び出される気がする。
「少なくとも」と書いたのは、効率面で最低でも move が生じる
という意味で書いたつもりだった。
622:デフォルトの名無しさん
21/07/03 19:40:59.20 Ju/axMXt.net
くっそ素朴な疑問だけど
「operator>>」
って声に出して読むときどうしてる？
独学/個人開発なので他の人から聞く機会がない
623:デフォルトの名無しさん
21/07/03 19:42:38.50 dunp4iC4.net
右シフト記号？
624:デフォルトの名無しさん
21/07/03 20:04:04.63 ApVtA7Dx.net
入力オーバーライドとか？ うーん・・・ダブルGT！
625:デフォルトの名無しさん
21/07/03 20:04:56.30 Y97o1UBK.net
個人的には「おぺれーたーだいなりだいなり」だな
他人には言ったことないけど
626:デフォルトの名無しさん
21/07/03 20:18:12.60 Ju/axMXt.net
自分のレス読んで気づいたけど他の人に声出し読むう機会も無いからどうでもいいな
627:デフォルトの名無しさん
21/07/03 20:23:06.99 A2f3M294.net
おぺれーたーぐれぐれ
628:デフォルトの名無しさん
21/07/03 21:03:34.16 WO4lFPcp.net
オペレータ・イン
<<は当然オペレータ・アウト
629:デフォルトの名無しさん
21/07/03 21:05:23.40 WO4lFPcp.net
朗読問題は根深くて、古くは漢文の読み下しからあり、
座右の書たるC言語を256倍使うための本にもちゃんと発音方法が載ってる
630:デフォルトの名無しさん
21/07/03 21:29:09.42 iUoBj2xP.net
>> みぎみぎ
<< ひだりひだり
631:デフォルトの名無しさん
2021/07/03(
632:土) 21:41:24.77 ID:iArH0hMS.net
633:デフォルトの名無しさん
21/07/03 22:59:31.74 5pcVeoYl.net
オペレーター、クィっ、クィっ
634:デフォルトの名無しさん
21/07/04 03:21:06.85 WJcubPcO.net
auto hoge = func()
は場合によってはコピーが起きる
という印象、
なぜなら戻り値をスタックのどこに積むかをfunc()の側で指定できないから
hogeの実体ドンピシャにfunc()内で構築できる保証が無い
コピーが省略され得るのは
auto hoge = func();
bar(hoge);
みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの
635:デフォルトの名無しさん
21/07/04 07:20:46.94 kv3QS/1l.net
ISO/IEC 14882に準じて
おぺれーたーらいとしふと
636:デフォルトの名無しさん
21/07/04 08:34:51.74 mLloSLib.net
>>623
？？？
最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
アホか全然レイヤの違う話だよ
右辺値左辺値の概念全く理解しとらんのか (何十年前のプログラマだ)
「印象」でものを語るな
637:デフォルトの名無しさん
21/07/04 10:01:09.26 mLloSLib.net
それはそうと、こんなスレでも右辺値と左辺値よくわかってない (概念としてはわかっててもある場合のある値がどっちか判然としない) 人が多いのは、C++のムーブセマンティクスが洗練されてる証拠かもな
つまり、プログラマの預かり知らぬところで自動でコピーとムーブが仕分けされているという
638:デフォルトの名無しさん
21/07/04 10:11:22.75 dMFRzHLQ.net
>>623
URLﾘﾝｸ(wandbox.org)
そんなことないよな？ と思いつつやってみた
まあ、そんなことないよな
ただ実験してて一個だけ気になったのが
take_S(S());
ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
C++11/14でも-fno-elide-constructorsを付けない限りmoveだけ
これってなんで？
639:デフォルトの名無しさん
21/07/04 10:44:02.96 pili1Lz/.net
>>619
万葉集は読み下しですらないからな
640:デフォルトの名無しさん
21/07/04 11:45:10.82 WJcubPcO.net
>>627
解説ｷﾎﾞﾃｨｰﾇ
"copy"と表示されているわけだが
641:デフォルトの名無しさん
21/07/04 11:56:43.39 WJcubPcO.net
つかそれを除けば>>623の通りなんじゃないの
>take_S(S());
>ってやった場合、default→moveじゃなくて単にmoveとしか表示されなかった
これは呼び出し元がS()の戻り値の実体をtake_S()の引数の実体と合一（スタック上の同一アドレス）にできた例
defaultコンが呼ばれなかったのはstruct Sがメンバを持たないから最適化でデフォルトコンストラが削除された例
通常の関数呼び出しでcoutする処理が削除されたらそればバグだが、
コンストラクタの呼び出し削減の最適化はコンストラクタ内で副作用のある処理を行っている可能性を
無視して行われることが規格のどっかで認められているはず……
642:デフォルトの名無しさん
21/07/04 12:12:47.00 WJcubPcO.net
>最適化されて bar(func()) になるときだけオブジェクトの構築が省略されるって言いたいの？
微妙にちげう func()がオブジェクトをコピー返しする関数である以上、その場合だけムーブにする余地があると言って�
643:薰� 実際は auto hoge = func() bar(hoge) （この後hogeを使う人は居ない） と分けて書いたら"move"になりそうなケースなのに"copy"になったらしいが（>>627のリンク先 >アホか全然レイヤの違う話だよ ムーブにできるのは参照の付け替えとみなせるケースなので上の話（コピーをムーブと読み替え得る条件）が別レイヤの話とは認められない
644:デフォルトの名無しさん
21/07/04 12:32:59.30 dMFRzHLQ.net
>>629
表示されたってことは省略されてないよね？
645:デフォルトの名無しさん
21/07/04 12:34:44.04 dMFRzHLQ.net
実験の部分を同時に話題にするべきではなかったな
646:デフォルトの名無しさん
21/07/04 12:54:00.52 WJcubPcO.net
>>632
"move"にならずに"copy"になったのは謎だと>>631に書いてある
とわいえ、>>623の主張を整理すると、
(1) func()が定義上オブジェクトをコピー返しする関数である場合、auto hoge = func() がムーブになるとは限らず、場合によってはコピーが起きる
(2) ただし、bar(func()) というケースでは、func()の戻り値をbar()に渡す際に、コピーではなくムーブが選択される余地がある
というものであって、bar(func())に類似のケース（>>627のリンク先）でムーブにならずコピーになったからといって>>623が否定されたことにはならない
（∵ムーブが選択される「余地がある」と言っただけであってムーブにする義務があると言ったわけではない
647:デフォルトの名無しさん
21/07/04 13:00:30.08 WJcubPcO.net
ここで「func()が定義上オブジェクトをコピー返しする関数である」のに何でコピーが削除されてムーブに成り得るのか？
という疑問を抱く向きもあるかもしれないが、
これについては構造体やオブジェクトをコピー返しするような関数func()が実際には
return valueの置き場所にデフォルト構築するだけのコードに落ちることがあるのを見たらﾜｶﾙ
648:デフォルトの名無しさん
21/07/04 13:13:36.22 dMFRzHLQ.net
>>634
もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ
ていうか実験の部分は自己解決しました
C++17で必須になったっていうだけで、それまでも（C++98ですらも）省略されることが許されるというのは明記されていたんですね
649:デフォルトの名無しさん
21/07/04 13:25:14.33 bouvqZmG.net
「コピー返し」ってなんぞ？
650:デフォルトの名無しさん
21/07/04 13:29:00.70 WJcubPcO.net
>>636
>もしかして、コピーの代わりにムーブでオブジェクトが構築されることを「コピー省略」だと思ってる？だとしたら違うよ
別に
言っているのは
1. オブジェクトの構築はfunc()内のどこかしらで行われる
2. 1の方法によっては、func()がreturn valueをreturnする際のコピーは省略される（func()がそういうコードになる
3. func()がスタック上に返したreturn valueを呼び出し元が自動変数hogeのエリアにコピーする代わりにbar()の引数エリアにmoveする
ことがある（>>601が言うように常にmoveになる、というわけではない
と言う簡単な主張
651:デフォルトの名無しさん
21/07/04 13:49:07.73 dMFRzHLQ.net
>>638
じゃあ結局>>623のこの部分は間違いってことでいいの？
> コピーが省略され得るのは
> auto hoge = func();
> bar(hoge);
> みたいな呼び出し元がhogeの用の一時的領域を次の関数呼び出しの引数としてやりくりできる場合だけなんじゃないの
652:デフォルトの名無しさん
21/07/04 14:05:29.04 bouvqZmG.net
意味ワカンネ
1. func が内部でオブジェクトを構築する話
2. func の返り値を変数 hoge に束縛する話
3. func の返り値を後で他の関数に渡す話
全部切り分けて考えろよとしか思えんのだが
そして 2 について言えば>>621に尽きるだろとしか思えんのだが
653:デフォルトの名無しさん
21/07/04 14:15:48.87 WJcubPcO.net
>>640
いやすまん2は確かに間違いでauto hoge = func()はhogeへのmoveで済む
>>639
いやすまん「～できる場合だけ」という限定は間違いやった
ついでに言うとbar(func())でたまたまfunc()がスタック上に作ったreturn valueのアドレスも変えずにそのままbar()に渡せるとき
moveが起きるという主張も間違いだったかも……（アドレスも変わらないのなら何の構築も不要
654:デフォルトの名無しさん
21/07/04 14:27:18.68 bouvqZmG.net
何もかもおかしいよお前
「コピー返し」って結局なんやねん
独特の語法でわけのわからんことを主張するな
「印象」「かもしれない」で物事を主張するな
何がわかってて何がわかってないか知れ
質問と主張をごちゃまぜにするな
本格的に社会に居場所なくなるぞ
「全部取り下げます」とだけ言って去れ
で一から勉強しろ
655:デフォルトの名無しさん
21/07/04 14:32:24.17 2p3tbjy0.net
RPGでアイテムを移動させた時に間違ってコピーされてアイテムが増殖する
ムーブしないといけない
アイテムは一個だけ
656:デフォルトの名無しさん
21/07/04 14:37:46.88 HHbHqtlq.net
>>642
面倒見よくて草
昔はこの板にもアンタみたいな厳しい先輩いっぱい居たのにな
今はニワカと趣味グラマが何周送れかわからんポエム呟きあってるだけだし
昔からいる人らは完全スルーしてるはず
657:デフォルトの名無しさん
21/07/04 14:52:36.20 WJcubPcO.net
>>642
Callerが（スタック上に）確保したメモリに対してcalleeが構造体を返すという返し方の意味
これについては統一した用語が無いようなのでむしろ知りたいっすね……
>>643
>>623のコードでSにムーブコンが定義されていなかったら増殖を意図しないケースでも
コピコンが呼ばれるのだから>>643はたとえとしてはｲﾏｲﾁ
658:はちみつ餃子
21/07/04 15:12:00.11 7/Zaj2J4.net
>>645
要件を満たすとき (返却値が prvalue のとき) は変数の場所に直接にオブジェクトが構築される.。
コピーやムーブを省略できるというのはそういう意味で、
特に C++17 以降ではコピー省略が許されるときにはコピーコンストラクタもムーブコンストラクタも存在しなくてもいい。
URLﾘﾝｸ(wandbox.org)
659:デフォルトの名無しさん
21/07/04 15:50:43.27 WJcubPcO.net
>>646のコードをVS2019でビルドしたら
>error C2280: 'foo::foo(foo &&)': 削除された関数を参照しようとしています
と言われるorz
ていうか「prvalueならば必ず変数の場所に直接にオブジェクトが構築される」（例外なくそうなる）のだとしたら
これはcallerがcalleeに構築すべき変数のアドレスを渡さねば実現できない芸当だけど
ABIにそんな隠れた第n引数を設けることまでC++の規格で決めちゃって委員会、
とそこはかとなく疑問が……
（funcがメンバ変数だった場合、隠れた第1引数でthisを渡すことになっているのにこれにさらに追加？
660:デフォルトの名無しさん
21/07/04 15:56:31.25 xLbwwiyt.net
いいからお前はRVOでぐぐって来い
話はそれからだ
661:デフォルトの名無しさん
21/07/04 16:02:57.96 WJcubPcO.net
>>648
これか
URLﾘﾝｸ(blog.kmc.gr.jp)
>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
>そしてそのアドレスの先の上にオブジェクトを構築することで、関数内部での一時オブジェクト
>生成を呼び出し元のオブジェクト生成とみなすことができます。 このようにしてRVOは実現されています。
>まるでメンバ関数における暗黙のthisポインタのように、関数の引数に戻り値を格納する先の変数へのアドレスを渡します。
ｍｊｋ、
662:デフォルトの名無しさん
21/07/04 16:18:10.24 2qJME2iB.net
>>649
RVO は、最適化の一種なので、実現方法は色々。
とにかく、コンパイラが、関数の戻り値から左辺へのコピーやムーブを
なるべく減らして、いきなりダイレクトに左辺に書き込むような方法を探し出して
コード化する。
それをどやってやるかは、関数呼び出しの ABI 依存。
663:デフォルトの名無しさん
21/07/04 16:52:18.97 VOtERW9V.net
>>647
エラーになるのは、VS2019のデフォルトがC++14だから。
プロジェクトのプロパティ→構成プロパティ→C/C++→言語 の
「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更すれば通る。
664:デフォルトの名無しさん
21/07/04 18:28:13.63 WJcubPcO.net
>>651
確かに「C++言語標準」を「ISO C++17標準(/std:c++17)」に変更したら通った
>>651
>（RVOを）どやってやるかは、関数呼び出しの ABI 依存。
そういうものだと今の今まで思っていたが、
C++17で>>646のコード（コピコンもムーブコンも明示的に削除）がビルドが通るようになるということは、
第2の隠れた引数でcallerがcalleeに構築すべき変数のアドレスを渡すことが
C++17では義務化されるとしか解釈できないのでは……
665:デフォルトの名無しさん
21/07/04 20:21:13.81 WJcubPcO.net
第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が怒り狂うのかわからん……
666:デフォルトの名無しさん
21/07/04 22:02:15.33 dMFRzHLQ.net
>>652
別に実装として「隠れた引数」を使えとは規格上決まっていないよ
処理系は適当な専用のグローバル変数を使うようなコードを出力しても構わない
>>653
なんで>>642が怒り狂うのか？
>>642を読んで分からない分からない？
あなたの一連のレスはあなた自身以外の誰のためにもなっていないんだよね
>>642でするな、って言われていることは、そういう自分のためにしかならないことでスレを私物化する行為に等しいよってことだ
667:デフォルトの名無しさん
21/07/05 08:27:16.47 4kBMhQOc.net
>>653
>>603は調べたんかいな。cpprefjp な。
RVOを含めて調べれば、>>646だということは分かるだろ。
c++標準の扱いはcpprefjpの参照リンクにもある「値のコピー省略の保証について」が良くまとまっている。
検索・調査能力が低いのは今どきのプログラマーとして致命的欠陥だから、日頃から訓練したほうがいい。
668:デフォルトの名無しさん
21/07/05 08:31:59.73 4kBMhQOc.net
補足。
>>653の2はNRVOだからRVOとは別物な。
NRVOは最適化可能だけどコピー省略は保証されていない。
669:デフォルトの名無しさん
21/07/05 08:44:01.31 4kBMhQOc.net
>>656
あ、間違えた。NRVOとは関係ないや。
ついでに。
＞しかしhogeはその後使っていないのだから、コンパイラ的には3はmoveになる余地があるはず
副作用のあるコピーコンストラクタがあったら最適化はやばいんじゃない？
規格上許されていたっけ？
670:デフォルトの名無しさん
21/07/05 11:05:56.38 w3Zb0u1p.net
ライフタイムを推論してcopy/moveの振り分けは理論上可能かもしれないが、現行の規格はそんなことは要求しない
lvalueからならcopy、rvalueからならmove
lvalueからmoveしてほしいならstd::moveしなさい
lvalueを渡しているのに勝手にrvalue referenceとして解釈されてぶっ壊されてたまるかよ
671:デフォルトの名無しさん
21/07/05 12:24:14.81 M+MHtMKE.net
template<class T>
class A {
public:
A()=default;
A(T&&);
};
この場合、T==Aになるとmoveとcopyを兼ねる？
672:デフォルトの名無しさん
21/07/05 13:59:53.08 MxHqaq3M.net
C++が出来るとは規格書がちゃんと読めることを言うんだね
673:デフォルトの名無しさん
21/07/05 15:27:44.85 NDiogwds.net
Macのclang++でコンパイルしています。
cstdlibをインクルードしなくてもrand()が使えてしまうのですが、これはなぜでしょうか？
674:デフォルトの名無しさん
21/07/05 15:36:50.05 M+MHtMKE.net
規格票には規格書なんて書いてない
俺はちゃんと読めるんだなんて
イキッてるやつはブーメランだな
675:デフォルトの名無しさん
21/07/06 00:27:03.56 86XKd96p.net
>>657
許されてるよ
その状況でコピコンやムーコンが呼ばれるかどうかは未規定（呼んでも呼ばなくてもいい）
というかこの「呼ばなくてもいい」っていう規定こそが正に規格がNRVOを認めてる部分そのもの
676:デフォルトの名無しさん
21/07/06 03:32:03.53 PiE4/OQH.net
実際、「move さえ省略してほしい」って思惑で
auto hoge = func();
と書くところを
auto&& hoge = func();
と書いてる人なんているの？
677:デフォルトの名無しさん
21/07/06 07:29:15.81 6WiwYssU.net
いるよ。
678:デフォルトの名無しさん
21/07/06 07:45:25.63 FcxtUR1g.net
>>657
エピステーメーも同じようなこと言ってたけどね
まぁコピーコンストラクタとかにコピー以外の副作用入れる方が悪い、ってことだろ
実際変な副作用など無いことを前提にしなきゃ出来ない最適化他にもあるやろ
679:デフォルトの名無しさん
21/07/06 10:03:46.67 t2+Z62DR.net
>>661
stdlib.hにも定義されているが、他のヘッダをincludeすると、
その中から別のヘッダをincludeしている場合も有り、その中からさらに
別のヘッダをincludeしている場合も有る。
また、標準ではstdlib.hやcstdlibで定義されているとされていても、
その他のヘッダで定義されていないとも限らない。
680:
21/07/06 20:25:19.80 /lKUoH39.net
>>666
＞コピーコンストラクタとかにコピー以外の副作用入れる方が悪い
規格票のどこに？
681:デフォルトの名無しさん
21/07/06 23:17:37.91 2d1Iatqp.net
>>668
規格票持ってるんですか？
682:デフォルトの名無しさん
21/07/07 00:20:29.64 ACi5C/C8.net
>>668
コイツたまにトリップ外すの忘れて荒らしみたいなことしてんの最高に滑稽
683:はちみつ餃子
21/07/07 05:18:00.78 BiM5c4gH.net
>>668
副作用がある場合でも省略されるというのは明記されている。
URLﾘﾝｸ(timsong-cpp.github.io)
> even if the copy/move constructor and/or destructor for the object have side effects
684:デフォルトの名無しさん
21/07/10 14:04:49.30 yQTcABkI.net
>>658
3がmoveになったところで何も壊れるものは無くね？
というのと、take_S()に渡される方がぶっ壊されることにはならないので
3がmoveになってもlvalueとして渡されることには変わりは無い
685:デフォルトの名無しさん
21/07/11 00:07:46.98 5nx6GB9W.net
>>672
URLﾘﾝｸ(cpplover.blogspot.com)
とりあえずこれとか読んでからお願いします
全体的に何が言いたいかよく分からないですがmoveならrvalueとして渡されるのでそこは理解してください
686:デフォルトの名無しさん
21/07/11 00:24:04.38 YJk6tGcw.net
>全体的に何が言いたいかよく分からないですが
ﾋｴｯ……このスレは荒れる……
687:デフォルトの名無しさん
21/07/11 00:27:13.08 YJk6tGcw.net
>moveならrvalueとして渡されるのでそこは理解してください
rvalueになるのは移動の右辺であり3のケースでは（3がmoveになったとして）移動元のhogeの実体だが
take_S()に渡るのはmoveされた後のhogeなのでtake_S()の中では問題無くlvalue扱い
688:デフォルトの名無しさん
21/07/11 00:28:49.03 YJk6tGcw.net
しつれい、
誤： take_S()に渡るのはmoveされた後のhoge
正： take_S()に渡るのは&hogeからmoveされてきたhogeの「複製」
689:デフォルトの名無しさん
21/07/11 00:51:20.33 5nx6GB9W.net
リンク先読んだ？
690:デフォルトの名無しさん
21/07/11 00:53:43.57 YJk6tGcw.net
もとから読んでるっつーの；；；
>>677はムーブコンストラクタで構築されたオブジェクトがlvalueでないと思っちゃうタイプ？
691:デフォルトの名無しさん
21/07/11 00:54:17.11 5nx6GB9W.net
3.でmoveは発生しません
詳細はさっきのブログ記事に書いてあります
以上
692:デフォルトの名無しさん
21/07/11 00:55:29.24 YJk6tGcw.net
>>679
どこか指摘できずに逃亡；；；
693:デフォルトの名無しさん
21/07/11 00:57:15.79 5nx6GB9W.net
lvalueをmoveせよ
さて、2. はどうしたらいいだろう。moveコンストラクタを実装したものの、コンパイラは2. の場合には、moveコンストラクタを呼び出してくれない。なぜなら、コンパイラは、プログラマの脳内仕様を読んではくれないからだ。tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。
そこで、プログラマが意図を伝えてやらなければならない。
X b( static_cast<X &&>(tmp) ) ;
この様に、rvalueにキャストしてやれば、moveコンストラクタを呼び出すことが出来る。
694:デフォルトの名無しさん
21/07/11 01:01:18.54 YJk6tGcw.net
>>679はSのインスタンスhogeを関数void take_S(S) （※void take_S(S&)ではない！）に渡す際に、
take_S()の呼び出し元（この場合main()）が
hogeと同じ値を持つインスタンスをtake_S()の引数用領域に構築する必要がある、というあたりからして理解していないのではないか；；；
で、問題にしているコードはリンク先の
>tmpが、その後に使われていないかどうかは、コンパイラは静的に決定できないのである。
には該当しない
695:デフォルトの名無しさん
21/07/11 01:04:39.70 YJk6tGcw.net
なぜなら、今回のケースはコードを見たらﾜｶﾙからじゃわ；；；
コンパイラは静的に決定できない、と言っているのは停止性問題を解く万能のアルゴリズムが無いことから来ているが、
特殊なケースでは停止性問題は機械的に解ける
今こそその時、
、というあたりからして>>679はちんぷんかんぷんなのではないか……
696:デフォルトの名無しさん
21/07/11 01:11:23.21 5nx6GB9W.net
あーそこがわかってなかったのね
take_Sの仮引数を実引数で初期化する時に同じことが起こるだけですよ？
実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
できなければ（かつlvalue参照として解決できれば）copyで仮引数が初期化される
697:デフォルトの名無しさん
21/07/11 01:24:29.28 YJk6tGcw.net
>>684
藻前の頭が固いだけなんとちゃうか；；；
>実引数をrvalue参照とみなしてオーバーロード解決できればmoveで仮引数が初期化される
この場合（すなわち実引数hogeをtake_S()の仮引数としてコピーした後呼び出し元が実引数hoge()を使わない（ことをコンパイラが機械的に判定できる）ケース）
において、実引数hogeのアドレスをrvalue参照とみなしてはいけないという根拠は？
論理的にはソースコードの意味を変えることなく整合するんだけどそういう最適化はいけないことなの？
698:デフォルトの名無しさん
21/07/11 02:58:15.91 YJk6tGcw.net
んまーとは言ったものの、
【実験1】 >>627のコードをループにしてやって最適化「-O2」にしても"move"にならなんだorz
URLﾘﾝｸ(wandbox.org)
結果:
default
--------
copy
0, 1
default
--------
copy
1, 2
...
※ ループにした他、コピコンとムーブコンをそれぞれ「それらしく」実装もしてゐる、
699:デフォルトの名無しさん
21/07/11 02:59:10.66 YJk6tGcw.net
【実験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
...