[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
396(1): 2021/06/18(金)13:18 ID:7Huy+AZL(2/2) AAS
.obj で分割するメリットって .exe が巨大化しないためってのもあるけど
テンプレ使うと各 .obj 全部に同じバイナリーが増殖しない？
397: 2021/06/18(金)13:51 ID:kejK9s3z(2/3) AAS
多分だけど、今時の環境だと一度他の翻訳単位で実体化されたものは再利用するんじゃなかったかな
398(1): 2021/06/18(金)14:28 ID:ru+U9KL5(1) AAS
リンク前に判るの？
リンク時に同じ名前で同じ引数ならまとめるの？
怖くない？
399: 2021/06/18(金)14:31 ID:kJSePQf1(2/2) AAS
lexical phase 9だな
400(2): 2021/06/18(金)20:05 ID:Ipfg6SU0(1) AAS
>>391
論旨変わってないだろ、何が切り取りだか
で、お前のその変な疑問がどこから出たのか聞いてるんだけど
>>392
「そういう意味」がどういう意味なのかよくわからない
.hに宣言しか書いてないからコンパイル時間が減るんであって、
.hで定義をincludeしたら減らないよ？
401: 2021/06/18(金)20:29 ID:kejK9s3z(3/3) AAS
>>400
テンプレートの話やろ？
翻訳単位のどこかに定義(実装)が必ず要るんだぞ
あるソース(翻訳単位)においては不完全型でいいんなら、そこで使うヘッダは前方宣言だけでいい(クラス定義は要らん)って書いたじゃん
クラス定義が要るんならそれは実体化を伴うんだからメンバ関数の実装ヘッダに書いてなきゃリンカエラー出るぞ
402: 2021/06/19(土)06:14 ID:BH9bYKW9(1) AAS
>>400
だから１行目を読め
読みたくないなら逃げるのはおまえさんの勝手だが
逃げた事実は消えないぞ
403: 2021/06/19(土)06:30 ID:o72o+RiW(1) AAS
>>390
だめなboostライブラリというのは、そりゃ山ほどある
メンテナという概念は一応あろうが
404: 2021/06/19(土)07:50 ID:do8R3N0p(1/2) AAS
>>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
というわけでクラス定義は極力ヘッダファイルに書くのが正しいい
省3
405(1): 2021/06/19(土)08:09 ID:do8R3N0p(2/2) AAS
今ｼﾞｯｹｿしたが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()); }
省4
406(6): 2021/06/19(土)08:55 ID:MSAvpN3e(1) AAS
初歩的なことかもしれませんが質問させてください。
以下の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);
}
省12
407(1): 2021/06/19(土)09:03 ID:N/imZiDN(1) AAS
>>406
無理でしたとは？コンパイルエラー？エラーメッセージは？
408(6): 2021/06/19(土)11:19 ID:xVp2TfT/(1/4) AAS
それ多分特殊化じゃなくてオーバーロード？(違ってたらすまん
hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる
myclass版の前方宣言をfile1.hpp(fugaより前)に書くか、fugaの実装をfile2.hppのインクルードより後にすればいける、と思う
409(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/19(土)14:35 ID:/f53/cxR(1/2) AAS
>>406
それは >>408 が指摘する通りオーバーロードになってる。
オーバーロードの解決方法は複雑なんで私もちょっと自信はないんだけど、
オーバーロードの候補の内で実引数の型と完全に同一 (または実引数の型に cv 修飾したもの) のものがあれば、
それの優先度はテンプレート引数のマッチより高いので曖昧さは生じずに解決できるのが正しい。
そんで >>408 がいう
> hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる
というのはたぶん関係ないと思う。
Two phase name lookup のルールが適用されるはずだから fuga 内での hoge の呼出しは
その時点では解決を試みられず、 main 内での fuga の呼出しが有った時に
省7
410: 2021/06/19(土)15:55 ID:zDrgWeBe(1) AAS
>>405
リンクする順番変えたら 4.5 になったり 3.0 になったりするかもしれないししないかもしれない
411: はちみつ餃子 ◆8X2XSCHEME 2021/06/19(土)16:47 ID:/f53/cxR(2/2) AAS
>>396
古典的なツールチェインでは同一のものがそれぞれの翻訳単位に作られる。
その上でリンク時に同じものは同じに統合される。
それが嫌だという場合にはテンプレートには明示的実体化という仕組みがあって、
暗黙的な実体化を抑制する仕組み (extern template) とセットで使うことで
テンプレートの実体をひとつの翻訳単位にまとめることは出来る。
当然だが個別に指定するのはめんどいし、
いまどきの処理系は賢いので、あまり使われてないと思う。
412: 2021/06/19(土)18:01 ID:xVp2TfT/(2/4) AAS
>>406>>408
うろ覚えだったのでスマンコ
というか自分がその手の順序依存を経験したのはVC2008-2015あたりまでだった気がする
最近のだとC++標準への準拠の設定(コンパイルオプション/Zc:twoPhaseとか)も影響するはず
413: 2021/06/19(土)18:07 ID:xVp2TfT/(3/4) AAS
間違えた、>>406>>409
2017あたりまで標準への準拠のオプション(名前不明)は指定しないと有効にならなかった気がする、2019では既定
414: 2021/06/19(土)18:48 ID:xVp2TfT/(4/4) AAS
/permissive-
やった(VS2017
2015以前なら>>408のような対策するしかないと思う
415(3): 2021/06/20(日)04:37 ID:aJXir9C9(1) AAS
>>407
失礼しました
短縮して書くと
undefined reference to 'void hoge<myclass<int, 10>>(myclass<int, 10>)'
というメッセージが出ます
コンパイラは g++ 11.1.0 です
用語の使い方が正しいか自信がありませんが、
file1.hpp 内で hoge の宣言と hoge を呼ぶためのユーティリティ関数 fuga の実装をしておいて、後から必要に応じて具体的な型について hoge の実装を書ける、という方がすわりが良いのですが、こういう考え方は間違っていますか
fuga は型によらず hoge を呼ぶための関数なのでその実装を後に回したくない、という思いもあります
416(1): 2021/06/20(日)07:43 ID:vxtAtGft(1/7) AAS
C言語の double _Complex と C++ の std::complex<double> って実部虚部の並び方とか一緒ですよね？
ヘッダファイル aaa.h で宣言されてる double _Complex * をとる関数に std::complex<double> * を渡したいのですが、やり方がわかりません。
#define 〇〇 std::complex<double>
#include<aaa.h>
みたいにできると想像してるのですが、合っているでしょうか？
417(1): 2021/06/20(日)08:46 ID:D2z+V4uq(1/5) AAS
>>416
_Complexはただのdouble型変数なのでstd::complex<double>と互換性なし
418: 2021/06/20(日)08:59 ID:vxtAtGft(2/7) AAS
>>417
メモリレイアウトから違うのですか？
では、double _Complex * をとる関数に std::complex<double> * を渡すことはできないということですか？
419: 2021/06/20(日)09:04 ID:D2z+V4uq(2/5) AAS
はい
420: 2021/06/20(日)09:11 ID:vxtAtGft(3/7) AAS
エ！？
_Complex って std::complex の後にできたんじゃありませんでしたか
なぜ、実部と虚部がメモリ上に連続で置かれているという設計にしなかったのでしょうか……
421(1): 2021/06/20(日)09:29 ID:yGlwqyqX(1/2) AAS
作りが似ている、ということと
互換性が保証されている、ということは同じじゃないぞ
保証があるか否かは規格票で確認することで主観が入る余地はない
俺が見た範囲では保証するとは書いてなかった
422(1): 2021/06/20(日)09:29 ID:D2z+V4uq(3/5) AAS
_Comolex変数の実部と虚部をそれぞれcreal(), cimag()で取得してstd::complex<double>変数にセットするしかない
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
具体的に
上下前次1-新書関写板覧索設栞歴
あと 507 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.160s*