C++相談室 part156

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

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

**デフォルトの名無しさん** · 2021/06/17(木) 12:43:39.21

>>383
また例のオウム返し野郎か
何がおかしいのか説明できないやつがハッタリかますんじゃねえ

**361** · 2021/06/17(木) 20:43:21.47

>>365
俺の>361,364の一体どこをどう読めばそんな解釈ができるのか教えてくれよ
俺が否定してるのはこれ↓
>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これは全然「テンプレートでない関数をプロトタイプと実装に分けただけ」じゃないよ
（藁人形論法ってやつか？これ）

**デフォルトの名無しさん** · 2021/06/18(金) 00:22:44.11

ポインタはchar * const p = q; とでも書かないとpがconstにならないが
char& c = *q; と書いたらそんなリスクを回避できる
革命的前進

**デフォルトの名無しさん** · 2021/06/18(金) 00:25:25.92

>>376
ﾊｱ？
#define C(A, B) A##B
にしないと駄目なんじゃ……

もっともK&Rの頃のCなら
#define C A/**/B
と書くことはできたっぽい

**デフォルトの名無しさん** · 2021/06/18(金) 08:34:36.86

>>372のAとBを連結するなら>>373でいいだろ。括弧でくくった方がいいかもしれんが。
##は用途が違う。

**デフォルトの名無しさん** · 2021/06/18(金) 09:49:26.06

実装も書いてあるヘッダファイルって src に置くの？ include に置くの？

**デフォルトの名無しさん** · 2021/06/18(金) 09:57:10.61

boost のライブラリって、一度入ったら時代遅れになっても取り除かれないんですか？
それとも boost の全貌を把握してる委員会みたいのがあって、ちゃんと選別みたいなことをしてるんですか？

今どきムーブセマンティックに対応してないデカいコンテナクラスを見つけて、そういう疑問を持ちました

**デフォルトの名無しさん** · 2021/06/18(金) 10:08:12.10

>>385
俺は
> 何か所にも同じのを書くのが嫌なら
> テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？
と言ったんだ

二行目だけ切り取ってきて人のこと藁人形とは藁わせてくれるやつだな

**デフォルトの名無しさん** · 2021/06/18(金) 10:17:41.61

>>385
純粋に気になるんだけど、例えば俺が>>366で書いたようにテンプレートの実体化が起きる前に関数、メンバ関数の実装を分けてインクルードすることは出来るけど
実体化が起きる翻訳単位では必ず実装が必要になるよね？(テンプレートの分離コンパイルは出来ないという問題から)

クラステンプレートのポインタや参照しか使わない翻訳単位では、例えばiosfwdみたいに前方宣言しか書いてないヘッダを使うことで、ビルド時間減らせるかもしれんけど

そういう意味ではクラステンプレートの定義書いてるヘッダで、メンバ関数の実装を書いたヘッダをインクルードするのは別におかしくはないと思うんだが

**デフォルトの名無しさん** · 2021/06/18(金) 12:27:14.41

>>389
src に .hpp が置いてあるプロジェクト観たことあるけど
かっこ悪いと思った

**デフォルトの名無しさん** · 2021/06/18(金) 12:47:25.93

include に置いてあるファイルに実装めっちゃ書いてあってももちろん嫌じゃないですか？

**デフォルトの名無しさん** · 2021/06/18(金) 12:54:04.57

いやも何も、テンプレートは明示的実体化して使えるテンプレートパラメータを制限でもしない限り、ヘッダに実装するしかないんだよ
可読性の問題を気にしてるなら拡張子変えればいい
ヘッダだからって.hや.hppじゃなきゃいけないなんて決まりは無いしinclude(フォルダかグループか知らんけど)直下に置かなきゃいかんわけでもない
そのくらい自分で工夫しろ

**デフォルトの名無しさん** · 2021/06/18(金) 13:18:46.12

.obj で分割するメリットって .exe が巨大化しないためってのもあるけど
テンプレ使うと各 .obj 全部に同じバイナリーが増殖しない？

**デフォルトの名無しさん** · 2021/06/18(金) 13:51:38.82

多分だけど、今時の環境だと一度他の翻訳単位で実体化されたものは再利用するんじゃなかったかな

**デフォルトの名無しさん** · 2021/06/18(金) 14:28:08.43

リンク前に判るの？
リンク時に同じ名前で同じ引数ならまとめるの？
怖くない？

**デフォルトの名無しさん** · 2021/06/18(金) 14:31:16.93

lexical phase 9だな

**デフォルトの名無しさん** · 2021/06/18(金) 20:05:16.88

>>391
論旨変わってないだろ、何が切り取りだか
で、お前のその変な疑問がどこから出たのか聞いてるんだけど

>>392
「そういう意味」がどういう意味なのかよくわからない
.hに宣言しか書いてないからコンパイル時間が減るんであって、
.hで定義をincludeしたら減らないよ？

**デフォルトの名無しさん** · 2021/06/18(金) 20:29:54.81

>>400
テンプレートの話やろ？
翻訳単位のどこかに定義(実装)が必ず要るんだぞ
あるソース(翻訳単位)においては不完全型でいいんなら、そこで使うヘッダは前方宣言だけでいい(クラス定義は要らん)って書いたじゃん
クラス定義が要るんならそれは実体化を伴うんだからメンバ関数の実装ヘッダに書いてなきゃリンカエラー出るぞ

**デフォルトの名無しさん** · 2021/06/19(土) 06:14:13.07

>>400
だから１行目を読め
読みたくないなら逃げるのはおまえさんの勝手だが
逃げた事実は消えないぞ

**デフォルトの名無しさん** · 2021/06/19(土) 06:30:02.69

>>390
だめなboostライブラリというのは、そりゃ山ほどある
メンテナという概念は一応あろうが

**デフォルトの名無しさん** · 2021/06/19(土) 07:50:07.39

>>398
YES実際恐ろしい
"a.cpp"に
class Foo { void some_method() const { return 3.0; } };

"b.cpp"に
class Foo { void some_method() const { return 4.5; } };
int main() { Foo x; printf("%f\n", x.some_method()); }

とか書いてリンクして実行したら3.0と表示されることがある
ビルド中に警告とかは無し（於VC++ 2010

というわけでクラス定義は極力ヘッダファイルに書くのが正しいい
二つのFooクラスの定義を同時にincludeしたら確実にビルドエラーになってﾜｶﾙ

どうしても.cppファイル側にクラスの定義を書くときは無名namespaceで囲うべきや
（名前付きnamespaceは名前の重複についてクラス定義ほど検査が厳しくないのであまり解決策にならない

**デフォルトの名無しさん** · 2021/06/19(土) 08:09:04.24

今ｼﾞｯｹｿしたが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どこ行った；；；

**デフォルトの名無しさん** · 2021/06/19(土) 08:55:28.76

初歩的なことかもしれませんが質問させてください。
以下の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);
}

**デフォルトの名無しさん** · 2021/06/19(土) 09:03:50.50

>>406
無理でしたとは？コンパイルエラー？エラーメッセージは？

**デフォルトの名無しさん** · 2021/06/19(土) 11:19:08.00

それ多分特殊化じゃなくてオーバーロード？(違ってたらすまん
hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる

myclass版の前方宣言をfile1.hpp(fugaより前)に書くか、fugaの実装をfile2.hppのインクルードより後にすればいける、と思う

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/19(土) 14:35:39.56

>>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 だとかなり古いバージョンでも特に問題なくコンパイルできてる。

**デフォルトの名無しさん** · 2021/06/19(土) 15:55:55.01

>>405
リンクする順番変えたら 4.5 になったり 3.0 になったりするかもしれないししないかもしれない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/19(土) 16:47:38.21

>>396
古典的なツールチェインでは同一のものがそれぞれの翻訳単位に作られる。
その上でリンク時に同じものは同じに統合される。

それが嫌だという場合にはテンプレートには明示的実体化という仕組みがあって、
暗黙的な実体化を抑制する仕組み (extern template) とセットで使うことで
テンプレートの実体をひとつの翻訳単位にまとめることは出来る。

当然だが個別に指定するのはめんどいし、
いまどきの処理系は賢いので、あまり使われてないと思う。

**デフォルトの名無しさん** · 2021/06/19(土) 18:01:09.17

>>406,>>408
うろ覚えだったのでスマンコ
というか自分がその手の順序依存を経験したのはVC2008-2015あたりまでだった気がする
最近のだとC++標準への準拠の設定(コンパイルオプション/Zc:twoPhaseとか)も影響するはず

**デフォルトの名無しさん** · 2021/06/19(土) 18:07:00.49

間違えた、>>406,>>409
2017あたりまで標準への準拠のオプション(名前不明)は指定しないと有効にならなかった気がする、2019では既定

**デフォルトの名無しさん** · 2021/06/19(土) 18:48:12.63

/permissive-
やった(VS2017
2015以前なら>>408のような対策するしかないと思う

**デフォルトの名無しさん** · 2021/06/20(日) 04:37:05.08

>>407
失礼しました
短縮して書くと
undefined reference to 'void hoge<myclass<int, 10>>(myclass<int, 10>)'
というメッセージが出ます

コンパイラは g++ 11.1.0 です

用語の使い方が正しいか自信がありませんが、
file1.hpp 内で hoge の宣言と hoge を呼ぶためのユーティリティ関数 fuga の実装をしておいて、後から必要に応じて具体的な型について hoge の実装を書ける、という方がすわりが良いのですが、こういう考え方は間違っていますか
fuga は型によらず hoge を呼ぶための関数なのでその実装を後に回したくない、という思いもあります

**デフォルトの名無しさん** · 2021/06/20(日) 07:43:07.12

C言語の double _Complex と C++ の std::complex<double> って実部虚部の並び方とか一緒ですよね？
ヘッダファイル aaa.h で宣言されてる double _Complex * をとる関数に std::complex<double> * を渡したいのですが、やり方がわかりません。

#define 〇〇 std::complex<double>
#include<aaa.h>
みたいにできると想像してるのですが、合っているでしょうか？

**デフォルトの名無しさん** · 2021/06/20(日) 08:46:26.25

>>416
_Complexはただのdouble型変数なのでstd::complex<double>と互換性なし

**デフォルトの名無しさん** · 2021/06/20(日) 08:59:29.33

>>417
メモリレイアウトから違うのですか？
では、double _Complex * をとる関数に std::complex<double> * を渡すことはできないということですか？

**デフォルトの名無しさん** · 2021/06/20(日) 09:04:23.23

はい

**デフォルトの名無しさん** · 2021/06/20(日) 09:11:24.89

エ！？
_Complex って std::complex の後にできたんじゃありませんでしたか
なぜ、実部と虚部がメモリ上に連続で置かれているという設計にしなかったのでしょうか……

**デフォルトの名無しさん** · 2021/06/20(日) 09:29:15.86

作りが似ている、ということと
互換性が保証されている、ということは同じじゃないぞ

保証があるか否かは規格票で確認することで主観が入る余地はない
俺が見た範囲では保証するとは書いてなかった

**デフォルトの名無しさん** · 2021/06/20(日) 09:29:35.37

_Comolex変数の実部と虚部をそれぞれcreal(), cimag()で取得してstd::complex<double>変数にセットするしかない

**デフォルトの名無しさん** · 2021/06/20(日) 09:35:42.79

_ComplexがC99でstd::complex<T>がC++03

**デフォルトの名無しさん** · 2021/06/20(日) 09:53:39.49

>>415
>>406に嘘書いてないか？

**デフォルトの名無しさん** · 2021/06/20(日) 10:06:25.46

std::complex<double> *hoge;
double _Complex *p = (double _Complex *)&hoge[0];

**デフォルトの名無しさん** · 2021/06/20(日) 10:06:45.88

>>424
すみません
どこか矛盾しますでしょうか
手元でコンパイルしてみて、そうなりました

**デフォルトの名無しさん** · 2021/06/20(日) 10:22:51.51

>>408は試してみた？

**デフォルトの名無しさん** · 2021/06/20(日) 10:33:37.36

>>427
はい
>>408様の仰る「fuga の実装を後に書く」というのが、>>406に書いた「下の方にコピペしたら」というのです
そして、それらのことを踏まえて、>>415に書いたような疑問を持ちました

ところで嘘というのはどういうものでしょうか
なにか矛盾しますでしょうか

**デフォルトの名無しさん** · 2021/06/20(日) 11:18:41.97

hogeの実装(関数の中身)を実際は書いてなかったとか、何か事実と違うことがあるんじゃないかと思った
だけ

>>415に書いてある理由なら、同じコンパイラであればどこか妥協するしかない気が
fugaの前方宣言だけはfile1に残して、実装を別のヘッダにして後からインクルードするとかは？(>>408で言ったのはそういうことなんだけど

**デフォルトの名無しさん** · 2021/06/20(日) 14:29:11.44

>>421-422
今調べたら、C側は実部虚部というメモリレイアウトを保証していて、std::complex 側は C の複素数と同じメモリレイアウトを保証してるようですね

>>423
すみませんCの方が早かったんですね

>>425
ありがとうございます
暗黙のキャストがなぜ許されないのかはまだよく分かっていませんが、キャスト自体は可能なようで、double _Complex (あるいはそのポインタ) をとる C 言語関数に std::complex<double> (あるいはそのポインタ) を適切にキャストして渡すのは問題ないようになってると理解しました

**デフォルトの名無しさん** · 2021/06/20(日) 15:33:53.67

>>430
その件について
ISO/IEC 9899でC++という文言に言及するか
ISO/IEC 14882でCという文言に言及しているか？
430に書かれている限りでは「似ている」だけだが

それからC++03は2003年にC++98のバグ修正をしただけだから
C99より古いぞ

**デフォルトの名無しさん** · 2021/06/20(日) 15:42:44.16

良スレ気体age

**デフォルトの名無しさん** · 2021/06/20(日) 16:06:01.76

>>431
いや、すみません。逆に「似ている」とはどういう意味でしょうか

例えば std::complex については
http://eel.is/c++draft/complex.numbers
の記述からしてメモリレイアウトは実部虚部と決まってるわけですが、これはソースとは見なせないんでしたっけ？

**デフォルトの名無しさん** · 2021/06/20(日) 16:11:41.02

>>431
> それからC++03は2003年にC++98のバグ修正をしただけだから
> C99より古いぞ
ですから、
>>430
> Cの方が早かった
のでは？

あと>>433は「std::complex は C の複素数型と同じことを保証する」という記述は含みませんね
ただ、この場合メモリレイアウトが同じであることの他に要請するべきことってありますっけ？

**デフォルトの名無しさん** · 2021/06/20(日) 16:13:04.04

>>431,434
> ですから、
> >>430
> > Cの方が早かった
> のでは？

すみません
間違えました
ごっちゃになってました
これは取り消します

**デフォルトの名無しさん** · 2021/06/20(日) 17:28:56.50

https://stackoverflow.com/questions/55563217/do-complex-types-in-c99-behave-like-stdcomplex-in-c
ここを読むとメモリレイアウトは同一みたいなんだよね。むりやりキャストしても問題なさそうな気がするけど

**デフォルトの名無しさん** · 2021/06/20(日) 17:50:06.69

本質的なデータはdouble2つ組だし、順序も普通は実部→虚部だろうし、わざわざパディングや別の変なメンバ混ぜることも考えにくいし
たまたまレイアウト一致する可能性は現実的に高いだろうけど
規格が保証してるかどうかはまた別の話かな

◆QZaw55cn4c · 2021/06/20(日) 17:59:57.69

もう C は C89 で止めれ
C++ は　C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない

**デフォルトの名無しさん** · 2021/06/20(日) 18:02:34.31

C/C++の複素数の構造体・クラス間の変換関数を規格として用意してもらうしかない

**デフォルトの名無しさん** · 2021/06/20(日) 18:23:00.50

インテルコンパイラの最適化オプションO2とO3で計算結果が変わって、問題を起こしている箇所を見つけようと思ってるんですが、
$ icpc -O3 src.cpp -lhoge
とコンパイルしてる場合、当然 src.cpp に問題があるのであって別でビルドされたライブラリ hoge は無関係と思って良いですよね？

**デフォルトの名無しさん** · 2021/06/20(日) 18:49:17.01

ゲェーッ -O3 はダメだけど -fast は期待通りに動きました
あまりにも意味不明なのでこれに手を出すのはやめておきます
失礼しました

**デフォルトの名無しさん** · 2021/06/20(日) 18:57:42.79

やべー未定義動作踏んでそう

**デフォルトの名無しさん** · 2021/06/20(日) 19:09:16.56

あるよなぁ。
FortifyやCodeSonarといった静的解析ツールで検出できたらいいが、どこまでできるんだろう。

**デフォルトの名無しさん** · 2021/06/20(日) 23:58:43.73

複素数とか高々数値メンバが2つとかそれぐらいの話なのに
なんでビットコピーできないと発狂するのかｲﾐﾌ

**デフォルトの名無しさん** · 2021/06/20(日) 23:59:56.38

備え付けの手段で実数部と虚数部毎に代入するとか
構築とかしたらええんじゃ

**デフォルトの名無しさん** · 2021/06/21(月) 01:37:57.43

>>437
>>436によるとサイズも並びも一致することを規格が暗に示してるようなんだ。1つ目の回答を見てくれ

**デフォルトの名無しさん** · 2021/06/21(月) 01:48:21.79

まだ「暗に」とか言ってんのこのキチガイ
コイツのせいで不必要に大事になった感はあるよね

**デフォルトの名無しさん** · 2021/06/21(月) 01:52:02.85

>>446
お前のコードで誰にも迷惑かからないなら、もう規格云々はいいから自分の思い込みたいように好きにやれば良いよ

**デフォルトの名無しさん** · 2021/06/21(月) 09:03:02.99

T* をとるオーバーロードコンストラクタに const T* x を渡したら、argument do not much だからとエラーになりました。
が、(T*)x を渡したらOKでした。
(T*)をつけてようがつけてなかろうが、x というポインタの const 性は変わりませんよね？
（つまり x を変える挙動があったらプログラムは終了しますよね？）
なぜ引数の型のマッチには (T*) が必要なのでしょうか。

できればキャストしたくないので、こうすれば避けれるとかこう思えば安全というのがあったら教えていただきたいです

**デフォルトの名無しさん** · 2021/06/21(月) 09:16:37.40

>>449
const性変わるんじゃない？

const T* xなんだから xはの先にある*xは変えてはいけないという指示をコードかいた人は出していて
そのT*をとるコンストラクタはその中で変更する可能性を言ってるんだから
T*にキャストして渡したらコンストラクタの中で変更され可能性が出るよ

**デフォルトの名無しさん** · 2021/06/21(月) 09:20:07.55

>>449
ああ、だから>なぜ引数の型のマッチには (T*) が必要なのでしょうか。
というと
本来ならconst指定されてて変更してはいけない変数を、変更するけどいいのね？というコンパイラからの確認的なもの

**デフォルトの名無しさん** · 2021/06/21(月) 09:34:04.75

>>450
> const性変わるんじゃない？
ありがとうございます。
誤解してました。
（というか、そこ変えれるなら何でもありな気が……）

>>451
実は、他人の作ったライブラリとの橋渡しでこういう問題が出ました。
知る限りではそのライブラリは引数のポインタの指してる先を変えないのですが、どうやらキャストはするしかないようですね。
この件で (T*) とは別に const_cast<T*> なるやり方の存在も知って、Cスタイルのキャストよりはこちらの方が良いという説明がいろんなところでされてるのですが、正直全く同じものに見えます。
なぜ const_cast の方がマシなのでしょうか？

**デフォルトの名無しさん** · 2021/06/21(月) 09:36:14.94

うん、マシだね
特にその問題では

**デフォルトの名無しさん** · 2021/06/21(月) 09:49:17.82

>>452
Cスタイルキャストは状況に応じてよしなにキャストしてくれるんだが
これがたまに意図しないキャストになる場合があるから、意味を明確にするためにC++のなんちゃらキャストをする
よほどのことがないと変なキャストにはならないとは思うけど一応

**デフォルトの名無しさん** · 2021/06/21(月) 09:58:36.45

const_castはint*→char*のように指す先の型は変更できない
だから、そのような変更をしようとしたらエラーになるし
そのような変更を意図していないことも示せる

**デフォルトの名無しさん** · 2021/06/21(月) 10:07:37.10

>>452
誤解してるようだけど、constってのは基本的にはバグ抑止のためのもので
文法上のルールに過ぎないのよ
実行時にチェックが走ったりするわけではない
で、意図的に破ることも一応出来る。意図的に破るときはそれが見てわかるようにconst_cast使おうね、
Cスタイルのキャストは何でも通しちゃうから避けようねってだけ

**デフォルトの名無しさん** · 2021/06/21(月) 10:07:43.43

>>454-455
なるほど。ありがとうございます
今は const_cast で渡すことにします

**デフォルトの名無しさん** · 2021/06/21(月) 11:07:11.82

>>441
この件諦めきれなくて少し調べてみたら、
-O3 はダメだが
-O3 -static -ipo は正常に動く
ことが分かった
更に、icpcでなくg++なら最適化レベルによらず正常に動くことが分かった

この場合陥っていがちな失敗なんてないですかね
ググってもなかなか体系的な知識に出会えなくて、、、

**デフォルトの名無しさん** · 2021/06/21(月) 15:28:43.32

諦め切れないくらい気になるなら -S で .asm コード見るべき

**デフォルトの名無しさん** · 2021/06/21(月) 15:39:13.82

こんなところでC++が中途半端に出来るだけが自慢の専門卒みたいな連中に尋ねるよりも
大学の先生かチューターの院生に尋ねた方がいいだろう
進みたい研究室があればそこに行って訊くと良い

**デフォルトの名無しさん** · 2021/06/21(月) 16:20:08.51

>>458
たぶん初期化漏れとかの未定義動作
-Wallでコンパイルすれば何かわかるんじゃね

**デフォルトの名無しさん** · 2021/06/21(月) 16:27:39.69

>>459-461
すんませんあざす
asmコードとか未知の領域ですけど勉強になりそうですね

-Wallは一応常につけてて、ワーニング全部潰すようにはしてます
全部のオブジェクトにvolatile付けたり外したりしてみようかな

**デフォルトの名無しさん** · 2021/06/21(月) 17:09:40.79

適当に弄って適当に動いたように観えて
適当に解決したって言い張るやつは成長しない

**デフォルトの名無しさん** · 2021/06/21(月) 17:40:48.54

短かったり切り出せるようなコードだったらcompiler explorerとかもあるよ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/21(月) 17:44:51.49

const ではないオブジェクトについて const 付きにキャストしている場合には
const を剥がしてから書き込みをすることは OK だが、
元々 const なオブジェクトから const を剥がして書き込むのは未定義で、
実際に最適化で壊れることはある。
ちなみに const なオブジェクトから const を剥がしても読むのみなら OK。

LLVM 9.0 で const 領域への書き込みを最適化で削除するする方針になってる。
https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#noteworthy-optimizations

**デフォルトの名無しさん** · 2021/06/21(月) 20:26:42.47

>>460
院生ねえ。。。修士の新人は手放しできないんだけどな
レッテルで色眼鏡つかう奴って
情報処理特種とかでもひれ伏すのか？
学生みたいなコード書くアホ知ってるけどｗ

**デフォルトの名無しさん** · 2021/06/21(月) 23:06:59.47

インテルコンパイラ様ともなれば
プラグマで関数単位で最適化レベルを変えられるんじゃないの
動くパティーンが分かっているのなら二分探索で問題の箇所を見つけるこ
とができうる

**デフォルトの名無しさん** · 2021/06/22(火) 00:52:42.42

C++の参照で渡した構造体を
中で別の構造体に実態コピーしたい時ってどうしたらいいんでしょう

void CTest::SetData(Kouzoutai &kozo)
{
if(kozo.judge == 1){
_KozoTmp = kozo;
}else{
//色々する
}
}

とすると、_KozoTmpってkozoと同じアドレスになっちゃって、
_KozoTmp.judge = 10とかしちゃうともとのkozo.judgeも変わっちゃいますよね
ポインタだったら
_KozoTmp = *kozo;
とかやればいいんでしょうけど
参照で渡した時ってどう書けばいいんでしょう

**デフォルトの名無しさん** · 2021/06/22(火) 01:00:09.80

それで普通にコピーされるだろ
なんでされないと思うの？

**デフォルトの名無しさん** · 2021/06/22(火) 01:05:17.48

参照にした時って、ポインタみたいにアドレスコピーにならないの?

**デフォルトの名無しさん** · 2021/06/22(火) 01:15:12.93

あのさ、_KozoTmpは何だ？Kouzoutai型だろ？Kouzoutai*でもKouzoutai&でもないだろ？
なんでアドレスなんか持てると思うの？

**デフォルトの名無しさん** · 2021/06/22(火) 01:21:47.48

あ、そうなんだ
ありがとうございます
kozoを参照で渡したから
_KotoTmpも無理矢理アドレスになるかと思ってました

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/22(火) 01:22:19.02

>>468
参照というのはいうなれば別名。
SetData の実引数と kozo は「同じもの」と考えて構わない。 (少なくともその場合は)

**デフォルトの名無しさん** · 2021/06/22(火) 10:52:00.08

copy コンストラクタと move コンストラクタってみんなちゃんと書いてる？
デフォにまかせてる？

**デフォルトの名無しさん** · 2021/06/22(火) 11:08:19.79

ものによる
ポインタやハンドルがあれば書いたり=delete;したり
実体だけなら大抵デフォ

**デフォルトの名無しさん** · 2021/06/22(火) 11:38:53.75

=defaultが多い

**デフォルトの名無しさん** · 2021/06/22(火) 11:45:11.84

コピーコンストラクタがあったらムーブ自動生成されないんでしょ？

**デフォルトの名無しさん** · 2021/06/22(火) 13:58:37.72

俺、タイプ量の少なさは美しさの１つだと思ってるから
=default;は本当に必要なときだけ書く

**デフォルトの名無しさん** · 2021/06/22(火) 14:51:15.52

doxygenでドキュメント作成してるけどソースが見づらくてコメント無い方がいいのではと思ってしまう

**デフォルトの名無しさん** · 2021/06/22(火) 15:03:38.14

>>479
関数ヘッダーだけでええんちゃうん？

**デフォルトの名無しさん** · 2021/06/22(火) 16:50:07.47

>>480
テンプレート系のライブラリなので

◆QZaw55cn4c · 2021/06/22(火) 19:42:13.49

もう C は C89 で止めれ
C++ は　C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない

◆QZaw55cn4c · 2021/06/22(火) 19:43:07.45

>>473
反対せざるを得ない意見です…‥