C++相談室 part156

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

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

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 18:42:59.35

>>308
だから「相当する」という語が付いてるんだろ？

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

>>299,305,307
ありがとうございます

**デフォルトの名無しさん** · 2021/06/13(日) 19:00:04.06

C++に関係したフォーラムや掲示板で、一番人が多いとこってどこですか？
海外のサイトでも可です

このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

**デフォルトの名無しさん** · 2021/06/13(日) 19:51:51.12

多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
意味的に一緒かというよりは、実際そういう実装になってるのか知りたいです

かけ算の数が小さくなる工夫みたいのってされてるんですか？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/13(日) 20:00:41.15

>>312
CPUに合わせた最適化はされてるよ。例えばx86 CPUではメモリーアドレッシングという計算が得意。まあ、コンパイラが吐くアセンブリを見るといいよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 20:15:02.56

>>311
質問なら Stackoverflow とか Teratail とか。

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

>>313
ありがとうございます
> 多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
というのは大体どんな処理系でもそうで、
> かけ算の数が小さくなる工夫みたいのってされてるんですか？
ここは処理系による高速化がされてるということですね

つまり、大抵は
> 2*y*z + 3*z + 4
に相当する部分を自分で (書いた関数とかマクロで) 計算して a に加えるよりは、a[2][3][4] とアクセスする方が速いんですかね？
>>272の、多次元配列の添字の入れ替えを in-place でやりたいという話で、こういう疑問に行き当たりました

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 20:44:32.87

>>315
それを自分で判断できない知識レベルならコンパイラに任せたほうが確実に良いよ。

「早すぎる最適化は諸悪の根源」とか「実測せよ」というよく知られた格言がある。
仮にちょっとした書き方で高速になるのだとしてもそれによって全体が読みにくいコードになってたら
改善するのが大変になって結果的にあまりよくないコードになってしまいがち。
処理速度が足りないのなら足を引っ張っているのはどこなのか
完成したプログラムを測定してから問題個所を改良すべきというのが先人の教え。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/13(日) 20:51:49.27

>>315
どうやれば高速化するかは、実際のコードで実測とアセンブリみないと解析できない。掛け算の代わりに足し算で計算できる場合はそうした方が早いかもしれない。
x86 アセンブリの場合、MOD eax, [ecx+ebx*2]のように一語でアドレス参照できる場合がある。
高速化手法には、他にもSIMDもあるし、マルチスレッドもある。

**デフォルトの名無しさん** · 2021/06/13(日) 21:02:57.88

>>297
C++11だとnewでメモリだけ最初に確保しといて、も一回 new で
そのメモリ指してコンストラクタ走らせるってやり方？
ポインタ遮蔽するような template書けば良さそうだけど。

◆QZaw55cn4c · 2021/06/13(日) 21:06:50.91

>>308
イコールとはいいませんが、ニアリーイコール、同じようなものですよ‥‥

**デフォルトの名無しさん** · 2021/06/13(日) 21:08:32.23

>>318
わざわざ自分で書かなくてもvectorがちょうどそんな動作してるよね

**デフォルトの名無しさん** · 2021/06/13(日) 21:43:42.51

>>317
ありがとうございます

in-place だと
○ 作業用メモリが必要ない
○ 全要素の半分だけ一回ずつ訪れれば良い
☓ 要素アクセスは自分で書いた関数なりマクロなりで行う必要がある

out-place だと
☓ 作業用メモリが必要
☓ 作業用領域にコピーして元の配列に戻すので各要素を二回ずつ訪れる必要がある
○ 要素アクセスは高速

て感じなので、やってみてどっちが良いか決めます

**デフォルトの名無しさん** · 2021/06/13(日) 22:27:55.12

俺がC++をこよなく愛する理由のひとつがとにかく長年の積み重ねのおかげで
コンパイラが激烈に賢いことだ
他の、たとえばJavaやらそれから派生したKotlinなんかでコード書いてて
「こんぐらいはコンパイラが最適化してくれるっしょ」とかルーズに書いて
実際に展開されたバイトコード見て絶望したことは数えきれない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 22:41:11.48

Java の場合は JVM の側で最適化したりするからバイトコードはそんなに頑張らないらしいよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/14(月) 02:15:01.87

makefile (GNU Make) の使い方の質問はどのスレで聞いたらよいんですかね？

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

>>297
普通に破門
おまえはポインタを使うなではなくC++を使うな
二度とこの世界に戻ってくるな

**デフォルトの名無しさん** · 2021/06/14(月) 08:03:40.16

CMakeのスレ使えば？

**デフォルトの名無しさん** · 2021/06/14(月) 08:09:35.27

>>297
誰もメリット感じないから実装しないんだろ。
ポインタに対するメリットは？

**デフォルトの名無しさん** · 2021/06/14(月) 08:35:37.07

みなstd::unique_ptrを思いついているが質問の仕方が気に食わないのでわざと回答しない

**デフォルトの名無しさん** · 2021/06/14(月) 08:43:01.39

「これしきのことにポインタ」とか言ってるくらいだから>>297にとってポインタのハードルがものすごく高いんだろう。

**デフォルトの名無しさん** · 2021/06/14(月) 10:09:52.82

ｗ

**デフォルトの名無しさん** · 2021/06/14(月) 10:36:17.05

そうは言っても、コンストラクタでしかプロパティ設定できない不親切なクラスを仕方なく使う羽目になることは結構あるでしょ

**デフォルトの名無しさん** · 2021/06/14(月) 10:44:09.11

RAII分かってるならそもそもコンストラクタ呼び出した後に2phaseでメンバ構築やろうなんて思わないから、質問の意図がわかんねーんだよな

**デフォルトの名無しさん** · 2021/06/14(月) 11:25:21.25

>>290
++

**デフォルトの名無しさん** · 2021/06/14(月) 11:30:58.26

>>311
stackoverflow

**デフォルトの名無しさん** · 2021/06/14(月) 11:33:34.30

> このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

知ってるがお前の態度が気に入らない
というケースならいくつか思い当たるな

**デフォルトの名無しさん** · 2021/06/14(月) 11:36:44.15

>>312
>多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると
> *(a + 2*y*z + 3*z + 4) を

*(a + 4 + (3 + 2*y)*z)
くらいのことはやってるよ

**デフォルトの名無しさん** · 2021/06/14(月) 11:40:50.95

>>315
そういう話ならいちいち掛け算してるかとかその回数がとかよりも
メモリキャッシュに乗ってるかどうかの効率の方が多きい

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/14(月) 17:34:14.74

前後の命令の依存関係によっては多少高コストの演算でもパイプラインに隠れて全体としては
それほど時間がかからないということも有りうる。
命令ひとつの実行コストだけでは評価できないから結局のところやってみてから計測するのが
手っ取り早いって話になる。

**デフォルトの名無しさん** · 2021/06/14(月) 18:10:27.40

>>312
現代の普通のコンパイラであれば当然最適化が行われる

コンパイル時に決定可能な部分はコンパイル時に決定するし、
ループ内で変化がない部分はループの外で計算する
のが普通

a[i][j][k] で一番ループの内側がkであれば
a[i][j]まではループの外で行うし
a[1][2][k] のような固定値であればa[1][2]まではコンパイル時に計算する

メモリアクセス順は非常にパフォーマンス的には重要で
a[i][j][k] を3重ループでアクセスする場合
ループの外側からi,j,kとするべき

言語上のいわゆる配列は最適化されやすいので普通は気にしなくていいが、
vectorやMatなど、外部定義の [] は基本的には遅いと思っていい

コストが小さいとはいっても確実にコストは発生する
速度が非常に重要な場合では
SIMD化、キャッシュ化、ループアンロールなどで最適化すべき
その場合も、データ構造、アクセス順、アルゴリズムなど上位層の最適化が終わってから

**デフォルトの名無しさん** · 2021/06/14(月) 22:36:37.28

vectorの[]だって配列へのアクセスしかしてないけどな。
インライン展開されるし範囲チェックもしてない

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

素人質問ですみません
クラスのメンバ関数は常に外で実装しますか？それとも、短いものはクラス宣言内に書きますか？
混在させて良いものかと迷っています(クラス宣言内に書くとinline指定になる事は知っています

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 00:02:19.94

>>341
どっちでもいいようになっているんだからどっちにするかは個別の判断による。
具体的条件を示してくれたらどちらが好ましいかの意見は言えるよ。

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

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>);
でオーバーロードすることってできますか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:32:07.52

>>338
高コストという文言の意味がよくわからんが
レイテンシが大きい命令はパイプラインを乱すぞ

**デフォルトの名無しさん** · 2021/06/15(火) 05:35:15.36

>>343
２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
だとすると無理だと思うな

std::array<int, 1> a;
hoge(a);
と呼び出したとき、N==2となるべきかN==1となるべきかの根拠がないから

やってみてないけど
つーか、おまえさんはやってみたのか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:40:17.26

>>345
> ２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
すみません。そうです

まだ試してないです
無理そうだなって思うんですが、昔「オーバーロード関数は機械にとってはそれぞれ別名関数だ」って話を聞いて、じゃあもしかしたら行けるかもと思った次第です

**デフォルトの名無しさん** · 2021/06/15(火) 07:12:05.86

すぐ試せることを自分で試さずに5chで聞くの良くないよ

**デフォルトの名無しさん** · 2021/06/15(火) 07:54:52.19

>>341
templateのクラス書いてると、長くても中に入れちゃうから、でかいのバーンって
そのままヘッダに入れても抵抗はないけど、templateでない場合でかい関数は普通に外に書くな。

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

>>341
外

templateやstaticのように実装をヘッダファイルに書く場合も
ヘッダファイルの中でプロトタイプと実装に分ける
さらに実装は別ファイルにしてヘッダファイル内で#includeする

宣言だけからなるアウトラインを残したいから

**デフォルトの名無しさん** · 2021/06/15(火) 08:19:37.29

>>343,345-347
試して無理でした
言い方合ってるかわかりませんが、>>343のやり方ではオーバーロードと関数テンプレートの差がないからでしょうか

コンパイラに myarray を array と別の型だと思ってもらって、hoge をオーバーロードするテクってありますでしょうか

**デフォルトの名無しさん** · 2021/06/15(火) 09:04:05.70

>>350
継承でいけるんじゃね

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 09:47:07.09

>>350
using で作った別名と元の型を区別する方法があるかという意味でなら方法は無い。
using は「別名」を作っているだけであくまでも同じ存在。

オーバーロードできるように型を分ける方法があるかという意味でなら >>351 が提案しているように継承を使うのが簡単な方法。
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> {};
みたいに書いて継承しつつ特になにも付け加えなければ事実上の別名でありつつ異なる型でもある。

**デフォルトの名無しさん** · 2021/06/15(火) 10:24:24.93

template<class T, std::size_t N> class myarray : public std::array<T, 2*N> { using std::array::aray; };
コンストラクタも継承しとかないと使いにくくて困るぞ

**デフォルトの名無しさん** · 2021/06/15(火) 10:25:47.44

std::array<T, 2*N>::arrayか
この件のみ動作確認しないポリシーなんでやりづれえ

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

>>349
迷惑なやつだな

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

>>351,353-354
なるほど
ありがとうございます

> この件のみ動作確認しないポリシー
てどういういみでしたっけ？

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

コンストラクタさえ継承しとけば、元のクラスとほぼ同じ使用感で使えるんですかね？
試しきれないので未知の困難に直面しそうで結構不安です

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

>>355
何が？

**デフォルトの名無しさん** · 2021/06/15(火) 16:21:53.57

>>356
多分、自分で確認もせず書き込むようなやつには同じく動作確認なんかしてやらねーよ、ってことだろ

**デフォルトの名無しさん** · 2021/06/15(火) 18:25:24.86

どうでもいいけど変数テンプレートの四則演算って推論の邪魔するような

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

>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これはやりすぎだろ
#include先に何書いてるかわからんから結局読まなきゃならん
空行とコメントで上下に分ける方がマシ

**デフォルトの名無しさん** · 2021/06/15(火) 21:00:10.82

それは非テンプレートなクラスでも一緒だと思うけど

**デフォルトの名無しさん** · 2021/06/16(水) 06:00:46.73

>>361
その論法はヘッダファイルそのものを否定する考えだな

**361** · 2021/06/16(水) 21:17:19.71

結局読まなきゃならないのは一緒だよ、当たり前
それでも、何か所にも同じのを書くのが嫌だから#includeなんじゃないの？
俺は一か所からのみ#includeするのを否定してる

**デフォルトの名無しさん** · 2021/06/17(木) 05:36:20.94

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

**デフォルトの名無しさん** · 2021/06/17(木) 10:01:25.56

まぁヘッダのインクルードの仕方はそれぞれだからなぁ
自作ヘッダ内では一切インクルードしない(それの前に必要なヘッダをすでにインクルードしてる前提)ってのもある

ただその戦略なら、テンプレートがインスタンス化される直前にその実装が書かれたやつインクルードすればいいだけなんだが

**デフォルトの名無しさん** · 2021/06/17(木) 10:28:32.50

多分同じ奴だと思うが、数スレ前から多次元配列を自力でどうこうしようとしてる奴、悪いこと言わんから外部ライブラリ使うとけ
今の時代、行列とかテンソルの計算は並の人間が書いた C/C++ じゃ絶対に Python (NumPy) その他に敵わんと思う

まあ C/C++ の多次元配列ライブラリも群雄割拠で何が何だか全く分からないんだが
STL に多次元配列が中々入らない理由もこれかな

**デフォルトの名無しさん** · 2021/06/17(木) 10:29:56.26

つーか入ったところで大したもんにはなり得ないか
行列の分解とか掛け算を STL が担うのはあり得んしな

**デフォルトの名無しさん** · 2021/06/17(木) 10:31:47.16

>>365
難癖もクソも普通にC/C++の欠点でしょ
フロッピーディスクの時代の遺物よ

**デフォルトの名無しさん** · 2021/06/17(木) 10:34:24.84

>>369
別におまえさんにC/C++を使ってくれなんて頼んでない
嫌いなら出てってもらって構わない

**デフォルトの名無しさん** · 2021/06/17(木) 10:36:52.42

>>370
誰が嫌いなんて言った？
欠点を差し引いてもメリットがあるから使ってるんだし、欠点は欠点として認めないと進歩しないよ

**デフォルトの名無しさん** · 2021/06/17(木) 10:48:03.95

質問です
#define A L"xyz"
#define B L"www"
を結合するとき
#define C AB
じゃだめなんですか？
#define D A(B)
ですか？
それとも
#define E A"www"
ですか？

**デフォルトの名無しさん** · 2021/06/17(木) 10:51:16.93

#define C A B
じゃね

**デフォルトの名無しさん** · 2021/06/17(木) 10:52:13.35

>>371
欠点は欠点として認めるって具体的にどうしてるんだ？
プロトタイプを一切しない、のような公害か？

**デフォルトの名無しさん** · 2021/06/17(木) 11:09:25.36

>>374
いや昔の貧弱な環境でもビルドできるように、って制約が無きゃもうちょっと違う形だったんじゃないの
今みたいにヘッダが肥大化しがちで各ソースごとに同じ解析しなきゃならないのは不自然ではある
IDEやコンパイラが賢いおかげでそこまでビルド時間酷くはならんようだけど

>>367
行列とかに関しては特に、C++のみで限界までチューニングしたってSIMD使ったコードにはまず勝てない(さらに言えばGPGPU使った方が、大きい行列ではもっと速い
それらを汎用化して使いやすくするのは可能だろうけど、そんなハード依存が激しいものを標準に入れるのか、それともハード依存は無いがめっちゃ半端なものを作るかの二択になるからでしょ

**デフォルトの名無しさん** · 2021/06/17(木) 11:16:45.59

>>372
#define C A##B

**デフォルトの名無しさん** · 2021/06/17(木) 11:31:03.61

>>375
具体的にどうしてるんだ？　と聞いてるんだが
答えたくないならいいよ

**デフォルトの名無しさん** · 2021/06/17(木) 11:38:23.32

IDも知らんのかこいつは

**デフォルトの名無しさん** · 2021/06/17(木) 11:48:01.35

日本語でおｋ

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

>>375
はい
そう申しております

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

>>379
375「俺は371じゃないから質問に答えろと言われても知らない」

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

横レスにしても頓珍漢すぎるだろ
今、横レスとして読み直したが俺にアンカー振られている意味がわからない

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

>>369に噛み付いてるんだから欠点じゃないと言いたいんだろ？
頓珍漢はお前だ(>>374でも相当おかしな事言ってるが

>>380
すまん直後の書き込み読んでなかった

**デフォルトの名無しさん** · 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のインクルードより後にすればいける、と思う