[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
423(1): 2021/06/20(日)09:35 ID:D2z+V4uq(4/5) AAS
_ComplexがC99でstd::complex<T>がC++03
424(1): 2021/06/20(日)09:53 ID:Q4Tfx6ZF(1/3) AAS
>>415
>>406に嘘書いてないか？
425(1): 2021/06/20(日)10:06 ID:vSSpHRy4(1) AAS
std::complex<double> *hoge;
double _Complex *p = (double _Complex *)&hoge[0];
426: 2021/06/20(日)10:06 ID:76n7YcAv(1/2) AAS
>>424
すみません
どこか矛盾しますでしょうか
手元でコンパイルしてみて、そうなりました
427(1): 2021/06/20(日)10:22 ID:Q4Tfx6ZF(2/3) AAS
>>408は試してみた？
428: 2021/06/20(日)10:33 ID:76n7YcAv(2/2) AAS
>>427
はい
>>408様の仰る「fuga の実装を後に書く」というのが、>>406に書いた「下の方にコピペしたら」というのです
そして、それらのことを踏まえて、>>415に書いたような疑問を持ちました
ところで嘘というのはどういうものでしょうか
なにか矛盾しますでしょうか
429: 2021/06/20(日)11:18 ID:Q4Tfx6ZF(3/3) AAS
hogeの実装(関数の中身)を実際は書いてなかったとか、何か事実と違うことがあるんじゃないかと思った
だけ
>>415に書いてある理由なら、同じコンパイラであればどこか妥協するしかない気が
fugaの前方宣言だけはfile1に残して、実装を別のヘッダにして後からインクルードするとかは？(>>408で言ったのはそういうことなんだけど
430(3): 2021/06/20(日)14:29 ID:vxtAtGft(4/7) AAS
>>421-422
今調べたら、C側は実部虚部というメモリレイアウトを保証していて、std::complex 側は C の複素数と同じメモリレイアウトを保証してるようですね
>>423
すみませんCの方が早かったんですね
>>425
ありがとうございます
暗黙のキャストがなぜ許されないのかはまだよく分かっていませんが、キャスト自体は可能なようで、double _Complex (あるいはそのポインタ) をとる C 言語関数に std::complex<double> (あるいはそのポインタ) を適切にキャストして渡すのは問題ないようになってると理解しました
431(3): 2021/06/20(日)15:33 ID:yGlwqyqX(2/2) AAS
>>430
その件について
ISO/IEC 9899でC++という文言に言及するか
ISO/IEC 14882でCという文言に言及しているか？
430に書かれている限りでは「似ている」だけだが
それからC++03は2003年にC++98のバグ修正をしただけだから
C99より古いぞ
432: 2021/06/20(日)15:42 ID:iNrFbyNf(1/3) AAS
良スレ気体age
433(1): 2021/06/20(日)16:06 ID:vxtAtGft(5/7) AAS
>>431
いや、すみません。逆に「似ている」とはどういう意味でしょうか
例えば std::complex については
外部ﾘﾝｸ:eel.is
の記述からしてメモリレイアウトは実部虚部と決まってるわけですが、これはソースとは見なせないんでしたっけ？
434(1): 2021/06/20(日)16:11 ID:vxtAtGft(6/7) AAS
>>431
> それからC++03は2003年にC++98のバグ修正をしただけだから
> C99より古いぞ
ですから、
>>430
> Cの方が早かった
のでは？
あと>>433は「std::complex は C の複素数型と同じことを保証する」という記述は含みませんね
ただ、この場合メモリレイアウトが同じであることの他に要請するべきことってありますっけ？
435: 2021/06/20(日)16:13 ID:vxtAtGft(7/7) AAS
>>431,434
> ですから、
> >>430
> > Cの方が早かった
> のでは？
すみません
間違えました
ごっちゃになってました
これは取り消します
436(1): 2021/06/20(日)17:28 ID:KYXAfitG(1) AAS
外部ﾘﾝｸ:stackoverflow.com
ここを読むとメモリレイアウトは同一みたいなんだよね。むりやりキャストしても問題なさそうな気がするけど
437(1): 2021/06/20(日)17:50 ID:CGp4yDz+(1/2) AAS
本質的なデータはdouble2つ組だし、順序も普通は実部→虚部だろうし、わざわざパディングや別の変なメンバ混ぜることも考えにくいし
たまたまレイアウト一致する可能性は現実的に高いだろうけど
規格が保証してるかどうかはまた別の話かな
438: ◆QZaw55cn4c 2021/06/20(日)17:59 ID:DQg/pXKj(1) AAS
もう C は C89 で止めれ
C++ は C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない
439: 2021/06/20(日)18:02 ID:D2z+V4uq(5/5) AAS
C/C++の複素数の構造体・クラス間の変換関数を規格として用意してもらうしかない
440: 2021/06/20(日)18:23 ID:zi1IwKwq(1/2) AAS
インテルコンパイラの最適化オプションO2とO3で計算結果が変わって、問題を起こしている箇所を見つけようと思ってるんですが、
$ icpc -O3 src.cpp -lhoge
とコンパイルしてる場合、当然 src.cpp に問題があるのであって別でビルドされたライブラリ hoge は無関係と思って良いですよね？
441(1): 2021/06/20(日)18:49 ID:zi1IwKwq(2/2) AAS
ゲェーッ -O3 はダメだけど -fast は期待通りに動きました
あまりにも意味不明なのでこれに手を出すのはやめておきます
失礼しました
442: 2021/06/20(日)18:57 ID:CGp4yDz+(2/2) AAS
やべー未定義動作踏んでそう
443: 2021/06/20(日)19:09 ID:akuykRB/(1) AAS
あるよなぁ。
FortifyやCodeSonarといった静的解析ツールで検出できたらいいが、どこまでできるんだろう。
444: 2021/06/20(日)23:58 ID:iNrFbyNf(2/3) AAS
複素数とか高々数値メンバが2つとかそれぐらいの話なのに
なんでビットコピーできないと発狂するのかｲﾐﾌ
445: 2021/06/20(日)23:59 ID:iNrFbyNf(3/3) AAS
備え付けの手段で実数部と虚数部毎に代入するとか
構築とかしたらええんじゃ
446(1): 2021/06/21(月)01:37 ID:czIvoWKn(1) AAS
>>437
>>436によるとサイズも並びも一致することを規格が暗に示してるようなんだ。1つ目の回答を見てくれ
447: 2021/06/21(月)01:48 ID:0g7/88j3(1) AAS
まだ「暗に」とか言ってんのこのキチガイ
コイツのせいで不必要に大事になった感はあるよね
448: 2021/06/21(月)01:52 ID:Im5VqdJw(1) AAS
>>446
お前のコードで誰にも迷惑かからないなら、もう規格云々はいいから自分の思い込みたいように好きにやれば良いよ
449(2): 2021/06/21(月)09:03 ID:G6bnr+rx(1/3) AAS
T* をとるオーバーロードコンストラクタに const T* x を渡したら、argument do not much だからとエラーになりました。
が、(T*)x を渡したらOKでした。
(T*)をつけてようがつけてなかろうが、x というポインタの const 性は変わりませんよね？
（つまり x を変える挙動があったらプログラムは終了しますよね？）
なぜ引数の型のマッチには (T*) が必要なのでしょうか。
できればキャストしたくないので、こうすれば避けれるとかこう思えば安全というのがあったら教えていただきたいです
450(1): 2021/06/21(月)09:16 ID:yA/sh2j8(1/3) AAS
>>449
const性変わるんじゃない？
const T* xなんだから xはの先にある*xは変えてはいけないという指示をコードかいた人は出していて
そのT*をとるコンストラクタはその中で変更する可能性を言ってるんだから
T*にキャストして渡したらコンストラクタの中で変更され可能性が出るよ
451(1): 2021/06/21(月)09:20 ID:yA/sh2j8(2/3) AAS
>>449
ああ、だから>なぜ引数の型のマッチには (T*) が必要なのでしょうか。
というと
本来ならconst指定されてて変更してはいけない変数を、変更するけどいいのね？というコンパイラからの確認的なもの
452(2): 2021/06/21(月)09:34 ID:G6bnr+rx(2/3) AAS
>>450
> const性変わるんじゃない？
ありがとうございます。
誤解してました。
（というか、そこ変えれるなら何でもありな気が……）
>>451
実は、他人の作ったライブラリとの橋渡しでこういう問題が出ました。
知る限りではそのライブラリは引数のポインタの指してる先を変えないのですが、どうやらキャストはするしかないようですね。
この件で (T*) とは別に const_cast<T*> なるやり方の存在も知って、Cスタイルのキャストよりはこちらの方が良いという説明がいろんなところでされてるのですが、正直全く同じものに見えます。
なぜ const_cast の方がマシなのでしょうか？
453: 2021/06/21(月)09:36 ID:yU7HyP9W(1/3) AAS
うん、マシだね
特にその問題では
454(1): 2021/06/21(月)09:49 ID:yA/sh2j8(3/3) AAS
>>452
Cスタイルキャストは状況に応じてよしなにキャストしてくれるんだが
これがたまに意図しないキャストになる場合があるから、意味を明確にするためにC++のなんちゃらキャストをする
よほどのことがないと変なキャストにはならないとは思うけど一応
455(1): 2021/06/21(月)09:58 ID:yU7HyP9W(2/3) AAS
const_castはint*→char*のように指す先の型は変更できない
だから、そのような変更をしようとしたらエラーになるし
そのような変更を意図していないことも示せる
456: 2021/06/21(月)10:07 ID:5d1ivHhj(1) AAS
>>452
誤解してるようだけど、constってのは基本的にはバグ抑止のためのもので
文法上のルールに過ぎないのよ
実行時にチェックが走ったりするわけではない
で、意図的に破ることも一応出来る。意図的に破るときはそれが見てわかるようにconst_cast使おうね、
Cスタイルのキャストは何でも通しちゃうから避けようねってだけ
457: 2021/06/21(月)10:07 ID:G6bnr+rx(3/3) AAS
>>454-455
なるほど。ありがとうございます
今は const_cast で渡すことにします
458(1): 2021/06/21(月)11:07 ID:JzAz8iJE(1/2) AAS
>>441
この件諦めきれなくて少し調べてみたら、
-O3 はダメだが
-O3 -static -ipo は正常に動く
ことが分かった
更に、icpcでなくg++なら最適化レベルによらず正常に動くことが分かった
この場合陥っていがちな失敗なんてないですかね
ググってもなかなか体系的な知識に出会えなくて、、、
459(1): 2021/06/21(月)15:28 ID:os4CEfZ3(1/2) AAS
諦め切れないくらい気になるなら -S で .asm コード見るべき
460(2): 2021/06/21(月)15:39 ID:s5hePRzy(1) AAS
こんなところでC++が中途半端に出来るだけが自慢の専門卒みたいな連中に尋ねるよりも
大学の先生かチューターの院生に尋ねた方がいいだろう
進みたい研究室があればそこに行って訊くと良い
461(1): 2021/06/21(月)16:20 ID:mdGWC+9J(1) AAS
>>458
たぶん初期化漏れとかの未定義動作
-Wallでコンパイルすれば何かわかるんじゃね
462: 2021/06/21(月)16:27 ID:JzAz8iJE(2/2) AAS
>>459-461
すんませんあざす
asmコードとか未知の領域ですけど勉強になりそうですね
-Wallは一応常につけてて、ワーニング全部潰すようにはしてます
全部のオブジェクトにvolatile付けたり外したりしてみようかな
463: 2021/06/21(月)17:09 ID:os4CEfZ3(2/2) AAS
適当に弄って適当に動いたように観えて
適当に解決したって言い張るやつは成長しない
464: 2021/06/21(月)17:40 ID:uOMSqfSW(1) AAS
短かったり切り出せるようなコードだったらcompiler explorerとかもあるよ
465: はちみつ餃子 ◆8X2XSCHEME 2021/06/21(月)17:44 ID:5bV+3LP7(1) AAS
const ではないオブジェクトについて const 付きにキャストしている場合には
const を剥がしてから書き込みをすることは OK だが、
元々 const なオブジェクトから const を剥がして書き込むのは未定義で、
実際に最適化で壊れることはある。
ちなみに const なオブジェクトから const を剥がしても読むのみなら OK。
LLVM 9.0 で const 領域への書き込みを最適化で削除するする方針になってる。
外部ﾘﾝｸ[html]:releases.llvm.org
466: 2021/06/21(月)20:26 ID:yU7HyP9W(3/3) AAS
>>460
院生ねえ。。。修士の新人は手放しできないんだけどな
レッテルで色眼鏡つかう奴って
情報処理特種とかでもひれ伏すのか？
学生みたいなコード書くアホ知ってるけどｗ
467: 2021/06/21(月)23:06 ID:0VSE6TcG(1) AAS
インテルコンパイラ様ともなれば
プラグマで関数単位で最適化レベルを変えられるんじゃないの
動くパティーンが分かっているのなら二分探索で問題の箇所を見つけるこ
とができうる
468(1): 2021/06/22(火)00:52 ID:JdLoAtTW(1/3) AAS
C++の参照で渡した構造体を
中で別の構造体に実態コピーしたい時ってどうしたらいいんでしょう
void CTest::SetData(Kouzoutai &kozo)
{
if(kozo.judge == 1){
_KozoTmp = kozo;
}else{
//色々する
}
}
省6
469: 2021/06/22(火)01:00 ID:cH2Us/Cy(1/2) AAS
それで普通にコピーされるだろ
なんでされないと思うの？
470: 2021/06/22(火)01:05 ID:JdLoAtTW(2/3) AAS
参照にした時って、ポインタみたいにアドレスコピーにならないの?
471: 2021/06/22(火)01:15 ID:cH2Us/Cy(2/2) AAS
あのさ、_KozoTmpは何だ？Kouzoutai型だろ？Kouzoutai*でもKouzoutai&でもないだろ？
なんでアドレスなんか持てると思うの？
472: 2021/06/22(火)01:21 ID:JdLoAtTW(3/3) AAS
あ、そうなんだ
ありがとうございます
kozoを参照で渡したから
_KotoTmpも無理矢理アドレスになるかと思ってました
473(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/22(火)01:22 ID:Ikkk/uWu(1) AAS
>>468
参照というのはいうなれば別名。
SetData の実引数と kozo は「同じもの」と考えて構わない。 (少なくともその場合は)
474(2): 2021/06/22(火)10:52 ID:2AbGnqy7(1) AAS
copy コンストラクタ と move コンストラクタ ってみんなちゃんと書いてる？
デフォにまかせてる？
475: 2021/06/22(火)11:08 ID:jiZrgPwV(1/2) AAS
ものによる
ポインタやハンドルがあれば書いたり=delete;したり
実体だけなら大抵デフォ
476: 2021/06/22(火)11:38 ID:PhquAAua(1) AAS
=defaultが多い
477(1): 2021/06/22(火)11:45 ID:hpNVAZMN(1) AAS
コピーコンストラクタがあったらムーブ自動生成されないんでしょ？
478: 2021/06/22(火)13:58 ID:jiZrgPwV(2/2) AAS
俺、タイプ量の少なさは美しさの１つだと思ってるから
=default;は本当に必要なときだけ書く
479(1): 2021/06/22(火)14:51 ID:4bX8g7Cj(1/2) AAS
doxygenでドキュメント作成してるけどソースが見づらくてコメント無い方がいいのではと思ってしまう
480(1): 2021/06/22(火)15:03 ID:zJk9T2bQ(1) AAS
>>479
関数ヘッダーだけでええんちゃうん？
481: 2021/06/22(火)16:50 ID:T8maLWCY(1) AAS
>>480
テンプレート系のライブラリなので
482(2): ◆QZaw55cn4c 2021/06/22(火)19:42 ID:9FGytWqi(1/3) AAS
もう C は C89 で止めれ
C++ は C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない
483(1): ◆QZaw55cn4c 2021/06/22(火)19:43 ID:9FGytWqi(2/3) AAS
>>473
反対せざるを得ない意見です…‥
484(2): ◆QZaw55cn4c 2021/06/22(火)19:43 ID:9FGytWqi(3/3) AAS
>>474
コピコンはちゃんと書きますが、ムーブ？何？それ美味しいの？
485(1): 2021/06/22(火)20:42 ID:InXfs1nZ(1) AAS
>>477
あったら使われる(一時オブジェクトの場合に)ってだけだぞ
やること一緒なら書かんでいい、時間の無駄
486: 2021/06/22(火)21:50 ID:7Ks2gqqv(1) AAS
>>474
デフォルトで済まない場合だけ明示的に記述するのが普通じゃないかねぇ。
=defaultにするか暗黙定義にするかは好みがあるだろうけど。
487(1): 2021/06/22(火)22:22 ID:4bX8g7Cj(2/2) AAS
>>484
美味しいとき”も”あるよ
488(1): 2021/06/22(火)22:45 ID:d6n1ZZoB(1) AAS
>>482-484
ロートルはちょっと黙ってて
489(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/23(水)04:03 ID:pZ1DtdbH(1) AAS
>>482
C89 ってことは暗黙の関数宣言とかのウンコ機能も含めて言ってるわけ？
490: 2021/06/23(水)04:16 ID:Vmwdc4hc(1) AAS
>>485
最近デカくて古いコンテナのコピーに悩まされてるから、アドレスを託すみたいな形でムーブしたい
491: 2021/06/23(水)06:19 ID:rIfoeFmJ(1) AAS
コピー回避なんていくらでもどうにでもなるのに
どんなヘボなんだ
492: 2021/06/23(水)08:31 ID:nCHirhrB(1) AAS
いや、だからそれがアドレスを渡すとか参照で渡すってことでしょ
493: ◆QZaw55cn4c 2021/06/24(木)20:04 ID:i6kIKJxB(1/3) AAS
>>488
黙れ、小僧！
お前に C++ の苦しみが分かるのか？
494: ◆QZaw55cn4c 2021/06/24(木)20:10 ID:i6kIKJxB(2/3) AAS
>>489
ウンコ機能はC99の方が多い、という認識です
495(1): ◆QZaw55cn4c 2021/06/24(木)20:11 ID:i6kIKJxB(3/3) AAS
>>487
具体的に
496(1): 2021/06/24(木)21:10 ID:3QBHDC7A(1) AAS
>>495
メモリ確保するようなクラスの場合、メモリ確保の手間省ける。
それ以外でムーブにコピー以上の利点知らない
497: 2021/06/25(金)00:44 ID:+R97TjGx(1/2) AAS
んまー（通常の関数呼び出しと違って）コピコンは放っといても勝手に呼び出しが削減される（副作用がある可能性ガン無視で）からな
昔から
498(1): 2021/06/25(金)00:55 ID:+R97TjGx(2/2) AAS
コピコン呼び出し最適化に頼らねばにっちもさっちも行かないシチュエーションは多々あるから
右辺値参照はﾏｼﾞ不完全
例えば
Foo operator+(const Foo& lhs, const Foo& rhs) {
Foo x(lhs); // 馬鹿正直にやったらコピー1回
x += rhs; // Foo& Foo::operator+=()が定義済みとする
return x; // 馬鹿正直にやったらコピーがもう一回
}
みたいな、
とこの前思いました
省1
499(2): ◆QZaw55cn4c 2021/06/25(金)01:03 ID:pWufOIHg(1) AAS
>>496
要はクラスC のオブジェクトA の中にポインタがあった場合、オブジェクトA を今後一切つかわない前提でオブジェクトA の持つポインタの値をオブジェクトB にコピーするやりかた、ということですよね
言われるほど凄い機能にも革新的な機能にも思えないので来ているのですが、クラスを返すときには、もしかしたら使えるかもしれませんね
でも、すでに RVO があるのでしょう？
500: 2021/06/25(金)01:11 ID:xLwe8284(1) AAS
>>498
それは左辺値参照だよ。
501: はちみつ餃子 ◆8X2XSCHEME 2021/06/25(金)01:12 ID:/YhIejlL(1/2) AAS
>>499
それが出来るということは重要じゃなくて文脈によって勝手に使い分けられるということに意味があるんだよ。
502: 2021/06/25(金)04:23 ID:2CfGrUVh(1) AAS
move対応してないデカいクラスはマジ迷惑だろ
503: 2021/06/25(金)06:23 ID:+QaNJXlp(1/4) AAS
ポインタ、参照、this、スマポ、[&]
いくらでもどうにでもなる
504: 2021/06/25(金)06:38 ID:byKvXpEn(1) AAS
えっ老害？？
505: 2021/06/25(金)06:40 ID:FhN3idtW(1) AAS
>>499
RVOはC++17で保証されたけどNRVOは保証されてない
506(1): 2021/06/25(金)07:44 ID:+QaNJXlp(2/4) AAS
C++03時代を生きてないやつからはそう見えるのか
507: 2021/06/25(金)08:48 ID:z3/X9CIt(1/2) AAS
{a, b, c,...} が a, b, c,... という要素からなるリストを表すとき、
{a, {b, {c, d}, e}, f, g, {h, i},...}
みたいな構造は a, b, c,... が全部同じ型だとしても tuple としてしか表せませんよね？
508(1): 2021/06/25(金)10:23 ID:Wd+wOk9Z(1) AAS
json
yaml
listのtree
なんでも
509: 2021/06/25(金)10:45 ID:z3/X9CIt(2/2) AAS
>>508
ありがとうございます
そうですね。STLとかboostのコンテナに囚われ過ぎてました
510: 2021/06/25(金)10:52 ID:tyTj/nU0(1) AAS
老害はC++スレに書き込むなよ
昔の話ばっかだよおじいちゃん
511: 2021/06/25(金)13:12 ID:+QaNJXlp(3/4) AAS
後から入ってきたくせに図々しいやつだな
先住権てやつでこっちが偉いんだよ
気に入らねえんなら他当たるか自分でサーバー立てな
512: 2021/06/25(金)13:16 ID:cHfQsTpJ(1) AAS
C++03の話なんてもうすんなよ
C++11からはもう別言語やんか
513: 2021/06/25(金)13:27 ID:+QaNJXlp(4/4) AAS
おまえの主観は関係ない
514(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/25(金)13:41 ID:/YhIejlL(2/2) AAS
>>506
C++03 時代を知ってるからそれが (少なくとも C++11 に比べれば) クソだってこともよく知ってるよ。
515: 2021/06/25(金)13:43 ID:ALny3hkX(1/2) AAS
本気で別言語だと思ってるやつって大抵何も作ってないゴミガキだと思うけどなぁ・・
STL的なアルゴリズムや新要素と親和性が高いのは、基本的に標準ライブラリだけなんだが
最近各種コンストラクタ(ムーブ込み)、代入等だけ長々と書いて「実質ほぼ何もしないクラス」を書いてドヤってるアホとかよく見かける
便利になってるのは確かだけどね・・
516: 2021/06/25(金)13:45 ID:ALny3hkX(2/2) AAS
>>514
俺も必要もなく03以前で書きたいとはまず思わんが、クソとか貶すのはやめた方がいいと思うよ
517: 2021/06/25(金)18:07 ID:aibvvCTW(1) AAS
gets()とか好きそう
518: 2021/06/25(金)18:33 ID:xqBptTy/(1) AAS
(σ・∀・)σｹﾞｯﾂ!!
519: 2021/06/26(土)00:08 ID:O9GH5wVp(1) AAS
ゲッツって初めて聞いた
ゲットエスって読んでたんだが
520: 2021/06/26(土)07:06 ID:MV3qzcHy(1) AAS
こことCスレでは古くからあるネッスラだよ
521: 2021/06/26(土)07:21 ID:+MI3rh96(1) AAS
scanf()をスキャンフと呼ぶけどprintf()をプリントエフと呼ぶ感じ
522: 2021/06/26(土)08:05 ID:vR4ZYNRj(1) AAS
プリンテフ
上下前次1-新書関写板覧索設栞歴
あと 480 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.046s