[過去ﾛｸﾞ] C++相談室 part156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
323: はちみつ餃子 ◆8X2XSCHEME 2021/06/13(日)22:41 ID:tRZIM+Qs(5/5) AAS
Java の場合は JVM の側で最適化したりするからバイトコードはそんなに頑張らないらしいよ。
324: はちみつ餃子 ◆8X2XSCHEME 2021/06/14(月)02:15 ID:fvxG9/iR(1/2) AAS
makefile (GNU Make) の使い方の質問はどのスレで聞いたらよいんですかね？
325: 2021/06/14(月)07:14 ID:C+gz3c8V(1/3) AAS
>>297
普通に破門
おまえはポインタを使うなではなくC++を使うな
二度とこの世界に戻ってくるな
326: 2021/06/14(月)08:03 ID:nv+G1IlK(1) AAS
CMakeのスレ使えば？
327: 2021/06/14(月)08:09 ID:/kKjPBzj(1) AAS
>>297
誰もメリット感じないから実装しないんだろ。
ポインタに対するメリットは？
328: 2021/06/14(月)08:35 ID:wsn+oRmt(1/2) AAS
みなstd::unique_ptrを思いついているが質問の仕方が気に食わないのでわざと回答しない
329: 2021/06/14(月)08:43 ID:6p9bp5Dj(1) AAS
「これしきのことにポインタ」とか言ってるくらいだから>>297にとってポインタのハードルがものすごく高いんだろう。
330: 2021/06/14(月)10:09 ID:C+gz3c8V(2/3) AAS
ｗ
331: 2021/06/14(月)10:36 ID:wsn+oRmt(2/2) AAS
そうは言っても、コンストラクタでしかプロパティ設定できない不親切なクラスを仕方なく使う羽目になることは結構あるでしょ
332: 2021/06/14(月)10:44 ID:FpnA+nhS(1) AAS
RAII分かってるならそもそもコンストラクタ呼び出した後に2phaseでメンバ構築やろうなんて思わないから、質問の意図がわかんねーんだよな
333: 2021/06/14(月)11:25 ID:LnG83xz5(1/4) AAS
>>290
++
334: 2021/06/14(月)11:30 ID:LnG83xz5(2/4) AAS
>>311
stackoverflow
335: 2021/06/14(月)11:33 ID:C+gz3c8V(3/3) AAS
> このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので
知ってるがお前の態度が気に入らない
というケースならいくつか思い当たるな
336: 2021/06/14(月)11:36 ID:LnG83xz5(3/4) AAS
>>312
>多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると
> *(a + 2*y*z + 3*z + 4) を
*(a + 4 + (3 + 2*y)*z)
くらいのことはやってるよ
337: 2021/06/14(月)11:40 ID:LnG83xz5(4/4) AAS
>>315
そういう話ならいちいち掛け算してるかとかその回数がとかよりも
メモリキャッシュに乗ってるかどうかの効率の方が多きい
338(1): はちみつ餃子 ◆8X2XSCHEME 2021/06/14(月)17:34 ID:fvxG9/iR(2/2) AAS
前後の命令の依存関係によっては多少高コストの演算でもパイプラインに隠れて全体としては
それほど時間がかからないということも有りうる。
命令ひとつの実行コストだけでは評価できないから結局のところやってみてから計測するのが
手っ取り早いって話になる。
339: 2021/06/14(月)18:10 ID:riVdj5/n(1) AAS
>>312
現代の普通のコンパイラであれば当然最適化が行われる
コンパイル時に決定可能な部分はコンパイル時に決定するし、
ループ内で変化がない部分はループの外で計算する
のが普通
a[i][j][k] で一番ループの内側がkであれば
a[i][j]まではループの外で行うし
a[1][2][k] のような固定値であればa[1][2]まではコンパイル時に計算する
メモリアクセス順は非常にパフォーマンス的には重要で
a[i][j][k] を3重ループでアクセスする場合
省7
340: 2021/06/14(月)22:36 ID:VOy4fGQR(1) AAS
vectorの[]だって配列へのアクセスしかしてないけどな。
インライン展開されるし範囲チェックもしてない
341(3): 2021/06/14(月)23:49 ID:4pDx/Jk6(1) AAS
素人質問ですみません
クラスのメンバ関数は常に外で実装しますか？それとも、短いものはクラス宣言内に書きますか？
混在させて良いものかと迷っています(クラス宣言内に書くとinline指定になる事は知っています
342: はちみつ餃子 ◆8X2XSCHEME 2021/06/15(火)00:02 ID:t/bAz/vZ(1/2) AAS
>>341
どっちでもいいようになっているんだからどっちにするかは個別の判断による。
具体的条件を示してくれたらどちらが好ましいかの意見は言えるよ。
343(2): 2021/06/15(火)05:05 ID:UNOhr6//(1/5) AAS
template<class T, size_t N> using myarray = std::array<T, 2*N>;
としたときに、関数 hoge を
template<class T, size_t N> void hoge(myarray<T, N>);
と
template<class T, size_t N> void hoge(array<T, N>);
でオーバーロードすることってできますか？
344: 2021/06/15(火)05:32 ID:d2euf9Bx(1/6) AAS
>>338
高コストという文言の意味がよくわからんが
レイテンシが大きい命令はパイプラインを乱すぞ
345(2): 2021/06/15(火)05:35 ID:d2euf9Bx(2/6) AAS
>>343
２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
だとすると無理だと思うな
std::array<int, 1> a;
hoge(a);
と呼び出したとき、N==2となるべきかN==1となるべきかの根拠がないから
やってみてないけど
つーか、おまえさんはやってみたのか？
346(1): 2021/06/15(火)05:40 ID:UNOhr6//(2/5) AAS
>>345
> ２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
すみません。そうです
まだ試してないです
無理そうだなって思うんですが、昔「オーバーロード関数は機械にとってはそれぞれ別名関数だ」って話を聞いて、じゃあもしかしたら行けるかもと思った次第です
347(1): 2021/06/15(火)07:12 ID:9e5Yrhbb(1/4) AAS
すぐ試せることを自分で試さずに5chで聞くの良くないよ
348: 2021/06/15(火)07:54 ID:rGBATnAZ(1) AAS
>>341
templateのクラス書いてると、長くても中に入れちゃうから、でかいのバーンって
そのままヘッダに入れても抵抗はないけど、templateでない場合でかい関数は普通に外に書くな。
349(1): 2021/06/15(火)08:01 ID:d2euf9Bx(3/6) AAS
>>341
外
templateやstaticのように実装をヘッダファイルに書く場合も
ヘッダファイルの中でプロトタイプと実装に分ける
さらに実装は別ファイルにしてヘッダファイル内で#includeする
宣言だけからなるアウトラインを残したいから
350(2): 2021/06/15(火)08:19 ID:UNOhr6//(3/5) AAS
>>343,345-347
試して無理でした
言い方合ってるかわかりませんが、>>343のやり方ではオーバーロードと関数テンプレートの差がないからでしょうか
コンパイラに myarray を array と別の型だと思ってもらって、hoge をオーバーロードするテクってありますでしょうか
351(2): 2021/06/15(火)09:04 ID:9e5Yrhbb(2/4) AAS
>>350
継承でいけるんじゃね
352: はちみつ餃子 ◆8X2XSCHEME 2021/06/15(火)09:47 ID:t/bAz/vZ(2/2) AAS
>>350
using で作った別名と元の型を区別する方法があるかという意味でなら方法は無い。
using は「別名」を作っているだけであくまでも同じ存在。
オーバーロードできるように型を分ける方法があるかという意味でなら >>351 が提案しているように継承を使うのが簡単な方法。
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> {};
みたいに書いて継承しつつ特になにも付け加えなければ事実上の別名でありつつ異なる型でもある。
353(1): 2021/06/15(火)10:24 ID:d2euf9Bx(4/6) AAS
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> { using std::array::aray; };
コンストラクタも継承しとかないと使いにくくて困るぞ
354(1): 2021/06/15(火)10:25 ID:d2euf9Bx(5/6) AAS
std::array<T, 2*N>::arrayか
この件のみ動作確認しないポリシーなんでやりづれえ
355(1): 2021/06/15(火)15:04 ID:dTl1pSLY(1) AAS
>>349
迷惑なやつだな
356(1): 2021/06/15(火)15:40 ID:UNOhr6//(4/5) AAS
>>351,353-354
なるほど
ありがとうございます
> この件のみ動作確認しないポリシー
てどういういみでしたっけ？
357: 2021/06/15(火)15:43 ID:UNOhr6//(5/5) AAS
コンストラクタさえ継承しとけば、元のクラスとほぼ同じ使用感で使えるんですかね？
試しきれないので未知の困難に直面しそうで結構不安です
358: 2021/06/15(火)15:44 ID:d2euf9Bx(6/6) AAS
>>355
何が？
359: 2021/06/15(火)16:21 ID:9e5Yrhbb(3/4) AAS
>>356
多分、自分で確認もせず書き込むようなやつには同じく動作確認なんかしてやらねーよ、ってことだろ
360: 2021/06/15(火)18:25 ID:yoH1yiay(1) AAS
どうでもいいけど変数テンプレートの四則演算って推論の邪魔するような
361(3): 2021/06/15(火)20:42 ID:GdaBtgkC(1) AAS
>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これはやりすぎだろ
#include先に何書いてるかわからんから結局読まなきゃならん
空行とコメントで上下に分ける方がマシ
362: 2021/06/15(火)21:00 ID:9e5Yrhbb(4/4) AAS
それは非テンプレートなクラスでも一緒だと思うけど
363: 2021/06/16(水)06:00 ID:KGe9Xsu1(1) AAS
>>361
その論法はヘッダファイルそのものを否定する考えだな
364(1): 361 2021/06/16(水)21:17 ID:vMisLWvQ(1) AAS
結局読まなきゃならないのは一緒だよ、当たり前
それでも、何か所にも同じのを書くのが嫌だから#includeなんじゃないの？
俺は一か所からのみ#includeするのを否定してる
365(2): 2021/06/17(木)05:36 ID:qVo1n1YK(1/7) AAS
何か所にも同じのを書くのが嫌なら
テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？
366(1): 2021/06/17(木)10:01 ID:4N0CEvnv(1/4) AAS
まぁヘッダのインクルードの仕方はそれぞれだからなぁ
自作ヘッダ内では一切インクルードしない(それの前に必要なヘッダをすでにインクルードしてる前提)ってのもある
ただその戦略なら、テンプレートがインスタンス化される直前にその実装が書かれたやつインクルードすればいいだけなんだが
367(1): 2021/06/17(木)10:28 ID:fU6donkc(1/3) AAS
多分同じ奴だと思うが、数スレ前から多次元配列を自力でどうこうしようとしてる奴、悪いこと言わんから外部ライブラリ使うとけ
今の時代、行列とかテンソルの計算は並の人間が書いた C/C++ じゃ絶対に Python (NumPy) その他に敵わんと思う
まあ C/C++ の多次元配列ライブラリも群雄割拠で何が何だか全く分からないんだが
STL に多次元配列が中々入らない理由もこれかな
368: 2021/06/17(木)10:29 ID:fU6donkc(2/3) AAS
つーか入ったところで大したもんにはなり得ないか
行列の分解とか掛け算を STL が担うのはあり得んしな
369(2): 2021/06/17(木)10:31 ID:kZP6q6xj(1/2) AAS
>>365
難癖もクソも普通にC/C++の欠点でしょ
フロッピーディスクの時代の遺物よ
370(1): 2021/06/17(木)10:34 ID:qVo1n1YK(2/7) AAS
>>369
別におまえさんにC/C++を使ってくれなんて頼んでない
嫌いなら出てってもらって構わない
371(1): 2021/06/17(木)10:36 ID:kZP6q6xj(2/2) AAS
>>370
誰が嫌いなんて言った？
欠点を差し引いてもメリットがあるから使ってるんだし、欠点は欠点として認めないと進歩しないよ
372(2): 2021/06/17(木)10:48 ID:EQR7Wr8E(1) AAS
質問です
#define A L"xyz"
#define B L"www"
を結合するとき
#define C AB
じゃだめなんですか？
#define D A(B)
ですか？
それとも
#define E A"www"
省1
373(1): 2021/06/17(木)10:51 ID:ADII7SgV(1) AAS
#define C A B
じゃね
374(2): 2021/06/17(木)10:52 ID:qVo1n1YK(3/7) AAS
>>371
欠点は欠点として認めるって具体的にどうしてるんだ？
プロトタイプを一切しない、のような公害か？
375(2): 2021/06/17(木)11:09 ID:4N0CEvnv(2/4) AAS
>>374
いや昔の貧弱な環境でもビルドできるように、って制約が無きゃもうちょっと違う形だったんじゃないの
今みたいにヘッダが肥大化しがちで各ソースごとに同じ解析しなきゃならないのは不自然ではある
IDEやコンパイラが賢いおかげでそこまでビルド時間酷くはならんようだけど
>>367
行列とかに関しては特に、C++のみで限界までチューニングしたってSIMD使ったコードにはまず勝てない(さらに言えばGPGPU使った方が、大きい行列ではもっと速い
それらを汎用化して使いやすくするのは可能だろうけど、そんなハード依存が激しいものを標準に入れるのか、それともハード依存は無いがめっちゃ半端なものを作るかの二択になるからでしょ
376(1): 2021/06/17(木)11:16 ID:Wy62wyA7(1) AAS
>>372
#define C A##B
377: 2021/06/17(木)11:31 ID:qVo1n1YK(4/7) AAS
>>375
具体的にどうしてるんだ？ と聞いてるんだが
答えたくないならいいよ
378: 2021/06/17(木)11:38 ID:4N0CEvnv(3/4) AAS
IDも知らんのかこいつは
379(1): 2021/06/17(木)11:48 ID:qVo1n1YK(5/7) AAS
日本語でおｋ
380(1): 2021/06/17(木)12:15 ID:fU6donkc(3/3) AAS
>>375
はい
そう申しております
381: 2021/06/17(木)12:21 ID:I9fxtS5z(1) AAS
>>379
375「俺は371じゃないから質問に答えろと言われても知らない」
382: 2021/06/17(木)12:33 ID:qVo1n1YK(6/7) AAS
横レスにしても頓珍漢すぎるだろ
今、横レスとして読み直したが俺にアンカー振られている意味がわからない
383(1): 2021/06/17(木)12:36 ID:4N0CEvnv(4/4) AAS
>>369に噛み付いてるんだから欠点じゃないと言いたいんだろ？
頓珍漢はお前だ(>>374でも相当おかしな事言ってるが
>>380
すまん直後の書き込み読んでなかった
384: 2021/06/17(木)12:43 ID:qVo1n1YK(7/7) AAS
>>383
また例のオウム返し野郎か
何がおかしいのか説明できないやつがハッタリかますんじゃねえ
385(2): 361 2021/06/17(木)20:43 ID:3vRllUUS(1) AAS
>>365
俺の>361,364の一体どこをどう読めばそんな解釈ができるのか教えてくれよ
俺が否定してるのはこれ↓
>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これは全然「テンプレートでない関数をプロトタイプと実装に分けただけ」じゃないよ
（藁人形論法ってやつか？これ）
386: 2021/06/18(金)00:22 ID:h1swrzIp(1/2) AAS
ポインタはchar * const p = q; とでも書かないとpがconstにならないが
char& c = *q; と書いたらそんなリスクを回避できる
革命的前進
387: 2021/06/18(金)00:25 ID:h1swrzIp(2/2) AAS
>>376
ﾊｱ？
#define C(A, B) A##B
にしないと駄目なんじゃ……
もっともK&Rの頃のCなら
#define C A/**/B
と書くことはできたっぽい
388: 2021/06/18(金)08:34 ID:R4m5mk7U(1) AAS
>>372のAとBを連結するなら>>373でいいだろ。括弧でくくった方がいいかもしれんが。
##は用途が違う。
389(1): 2021/06/18(金)09:49 ID:24jxp6EK(1/2) AAS
実装も書いてあるヘッダファイルって src に置くの？ include に置くの？
390(1): 2021/06/18(金)09:57 ID:LzkNSM+F(1) AAS
boost のライブラリって、一度入ったら時代遅れになっても取り除かれないんですか？
それとも boost の全貌を把握してる委員会みたいのがあって、ちゃんと選別みたいなことをしてるんですか？
今どきムーブセマンティックに対応してないデカいコンテナクラスを見つけて、そういう疑問を持ちました
391(1): 2021/06/18(金)10:08 ID:kJSePQf1(1/2) AAS
>>385
俺は
> 何か所にも同じのを書くのが嫌なら
> テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？
と言ったんだ
二行目だけ切り取ってきて人のこと藁人形とは藁わせてくれるやつだな
392(1): 2021/06/18(金)10:17 ID:7GC3MWRE(1) AAS
>>385
純粋に気になるんだけど、例えば俺が>>366で書いたようにテンプレートの実体化が起きる前に関数、メンバ関数の実装を分けてインクルードすることは出来るけど
実体化が起きる翻訳単位では必ず実装が必要になるよね？(テンプレートの分離コンパイルは出来ないという問題から)
クラステンプレートのポインタや参照しか使わない翻訳単位では、例えばiosfwdみたいに前方宣言しか書いてないヘッダを使うことで、ビルド時間減らせるかもしれんけど
そういう意味ではクラステンプレートの定義書いてるヘッダで、メンバ関数の実装を書いたヘッダをインクルードするのは別におかしくはないと思うんだが
393: 2021/06/18(金)12:27 ID:7Huy+AZL(1/2) AAS
>>389
src に .hpp が置いてあるプロジェクト観たことあるけど
かっこ悪いと思った
394: 2021/06/18(金)12:47 ID:24jxp6EK(2/2) AAS
include に置いてあるファイルに実装めっちゃ書いてあってももちろん嫌じゃないですか？
395: 2021/06/18(金)12:54 ID:kejK9s3z(1/3) AAS
いやも何も、テンプレートは明示的実体化して使えるテンプレートパラメータを制限でもしない限り、ヘッダに実装するしかないんだよ
可読性の問題を気にしてるなら拡張子変えればいい
ヘッダだからって.hや.hppじゃなきゃいけないなんて決まりは無いしinclude(フォルダかグループか知らんけど)直下に置かなきゃいかんわけでもない
そのくらい自分で工夫しろ
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>変数にセットするしかない
上下前次1-新書関写板覧索設栞歴
あと 580 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.059s