C++相談室 part141

**デフォルトの名無しさん** · 2019/02/22(金) 03:07:43.52

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2019/03/03(日) 00:24:16.88

確実にcppに実体作りたきゃ明示的インスタンス化は個別にしなきゃ駄目だろ

**デフォルトの名無しさん** · 2019/03/03(日) 00:24:32.19

>>121
この場合の特殊化は、どのような記述になるのでしょうか？

>>122
なるほど、やっぱり無理なんですかね？

これ、元となっているのは、

// h /////////////////////////////////////////////////
template<typename T> class cls
{
public:
int func();
private:
T var;
};

// cpp ////////////////////////////////////////////////////
template<typename T> int cls<T>::func(){ return var; }
template class cls<char>;

/////////////////////////////////////////////////////////////

みたいな感じで func() に戻り値の型指定を追加したいな、
って事でやりはじめたんですよね。

綺麗に書くのが無理そうならば、必要な物を全部書いていきます、、、

**デフォルトの名無しさん** · 2019/03/03(日) 00:30:05.53

要求仕様がいまいちよくわかっていないが（ﾏﾃ
(1) 任意の型Tの値cls::varから任意の型Uの値を得たい（一種のconverterクラスを作りたい）
(2) 変換関数cls::func()の実装は隠蔽したい

ということならこんなんでど（ry
ttps://ideone.com/1Fh8sg

**デフォルトの名無しさん** · 2019/03/03(日) 00:38:22.33

>>123
やっぱりそういう物なのですかね

>>125
仕様はそんな感じです
ただ、func() の戻り値をテンプレ使用でなんとかする方法が無いのかな、と
サンプルもありがとうございます

**デフォルトの名無しさん** · 2019/03/03(日) 00:49:52.61

>func() の戻り値をテンプレ使用でなんとかする方法が無いのかな、と
func()の戻り値をテンプレにしつつ実装は「完全に」隠蔽したい（ヘッダファイルに書くわけにいかない）となると
やっぱコアとなる変換関数は、必要なTとUの全組み合わせについて「完全に」「非テンプレートで」書かないといけない希ガス
（なぜなら、テンプレートのままcppに書いたら他のcppから呼べない（現行コンパイラはテンプレートの分割コンパイルに対応していない

(2)の隠蔽の要求を多少緩和して、template<class U> void conv(int src, U& dst)　{ ... } を
ヘッダファイルに書いても良いということならUを返すcls::func()をconv()を1個書いたらできるようにはなる

※ 個人の感想です
※ コードには個人差があります

**デフォルトの名無しさん** · 2019/03/03(日) 00:57:11.45

>>127
となると、現在のやり方でコードを完全隠蔽したいとなると、
全組み合わせをcppに書けって事になりますよね、、、

なるほど、了解いたしました
付き合って頂いた皆様、ありがとうございます

**デフォルトの名無しさん** · 2019/03/03(日) 01:15:53.21

ｽﾏﾝ>>127は言い過ぎたかもしれん…
全組み合わせをcppに書く作業をそのcppの中でテンプレートを定義して省力化することは可能かもしれん
ただし、そのcppの中で定義したのと同じシグネチャ（名前＋引数）でユーザーコードが別のテンプレート関数を定義でもしたら、
ODRに違反することになる（この場合実際に変な挙動になる危険性が大きい）ので全体を無名namespaceで囲う必要がありそう
無名namespaceの中から選択的に関数をエクスポートできるのかは正直知らん
あんまりテンプレート絡みで無茶はやりたくﾅｻｽ

**デフォルトの名無しさん** · 2019/03/03(日) 01:30:06.83

定義は共通でして
template int cls<char>::func<int>();
みたいなのを使う分だけ書けば良い

ただ、今回の場合クラス内テンプレート関数の特殊化しようとすると怒られるからさらに工夫が必要

**デフォルトの名無しさん** · 2019/03/03(日) 01:33:24.30

ああ、確かに
使わない関数テンプレートをcppで定義してそれの明示的インスタンス化を通してやれば省力化できそう
この場合その使わない関数テンプレートを内部リンケージにしても、その中で実体化要求されたテンプレートのリンケージには影響はないはず

**デフォルトの名無しさん** · 2019/03/03(日) 02:24:28.96

Visual Studioで通ってもgccで通らなかったりするからテンプレートの実体化は厄介。

**デフォルトの名無しさん** · 2019/03/03(日) 02:47:42.46

もはやコンパイラありきの言語

**デフォルトの名無しさん** · 2019/03/03(日) 02:53:02.86

VC++がC++擬きの別言語なだけだろ
今ごろになってやっと2 phase lookup対応させた

structとclassが違うとリンクでこけるのも糞

**デフォルトの名無しさん** · 2019/03/03(日) 03:13:19.05

VS2017以降のMSVCは許してあげてほしい・・・

**デフォルトの名無しさん** · 2019/03/03(日) 05:50:17.03

えっ、何か革新的なことをしているの？
C++は今までつかったことがなかったんだが、最近マイコンの開発に使ってから
かなり気に入っている。これならPCでも使えるかもと今考えているところ。

**デフォルトの名無しさん** · 2019/03/03(日) 06:33:00.88

組み込み用途だとC++よりCの方が融通効くと思うんだが
最近の組み込みはひょっとして随分恵まれてるのか

**デフォルトの名無しさん** · 2019/03/03(日) 07:57:12.43

>>137
お前さんの認識が古いだけ
数KBメモリーとモダンなプロセッサならC++で開発は普通にできる

◆QZaw55cn4c · 2019/03/03(日) 10:05:41.46

ふと思ったんですが、Java でデコレーターを記述するのに
BufferedReader br = new BufferedReader(new InpustStreamReader(System.in));
などと、new したオブジェクトのポインタを取っておかず、new したまま放置してしまう書き方がありますが、
スコープ内で new したオブジェクトは、スコープを外れるときに C++翻訳系が自分で delete する、と決め打ちしてしまうと、互換性で問題がでるでしょうか？

**デフォルトの名無しさん** · 2019/03/03(日) 10:18:54.68

そのポインタを別の場所にコピーしてたらどうなる？
頭悪すぎだろ

◆QZaw55cn4c · 2019/03/03(日) 10:23:45.41

>>140
では、あからさまに new したポインタを捨ててしまっている記述に限り自動で delete する、というのはどうですか？
目的は…classpath を共用したいのです、classpath はあらたに c++ で書くとして

**デフォルトの名無しさん** · 2019/03/03(日) 10:26:03.14

>>141
そのポインタは渡した先でどうなってると思う？
頭悪すぎだろ

**デフォルトの名無しさん** · 2019/03/03(日) 10:31:40.12

よくわかんねえけど楽してJavaを移植したいってこと？
Boehm GCでも使ってみたらどうだ

◆QZaw55cn4c · 2019/03/03(日) 10:35:18.92

>>142
new したポインタを捨ててしまっている記述に限り、処理系で delete する、と決めるのですから「ポインタを渡した先」というのは存在しないことになります

>>143
C++ と Java で classpath ライブラリを共用したいのです！

**デフォルトの名無しさん** · 2019/03/03(日) 10:35:19.96

make_uniqueがやりたいってことかね

◆QZaw55cn4c · 2019/03/03(日) 10:41:59.49

>>145
スマートポインタを導入せずとも、ナマポであっても classpath を共用できるようにならないものか
そのためには c++ 処理系にどんな制限or追加を課せばいいか？

◆QZaw55cn4c · 2019/03/03(日) 10:47:25.17

>>142
内容を誤解していました、すみません
あらためて回答します

プログラマが new したポインタ値を変数に取っておく記述をした場合は、delete の責任はプログラマにあるものとし、処理系では何もしないものとします

**デフォルトの名無しさん** · 2019/03/03(日) 10:53:36.82

>>116
遅レスだけど、テンプレートはcppに隠蔽しようとか考えない方がいいと思う
dllとかにしたいなら別だけど・・

**デフォルトの名無しさん** · 2019/03/03(日) 10:59:02.77

javaでnewしているからってc++でnewするなって
classpath共用が何を意味しているのかは分からんが

**デフォルトの名無しさん** · 2019/03/03(日) 11:02:05.72

・繰り返し構文とgotoの全廃

**デフォルトの名無しさん** · 2019/03/03(日) 11:24:20.63

>>147
だからさあ
newして渡した先では殆どの場合はそれをフィールドに入れてるだろ
殆ど100%のケースでは「何もしない」に該当するんだよ

**デフォルトの名無しさん** · 2019/03/03(日) 11:44:43.82

>>147
そのオレオレC++拡張の仕様を自分で決めて自分で実装して公開してみな。
万に一つもないと思うが、それを有用だと思って喜ぶ人がいるかもよ。

◆QZaw55cn4c · 2019/03/03(日) 11:58:52.90

>>151
んんー、それは c++ 的な扱い（delete はプログラマの責任）でいいかと、私の思考に何が抜けているのかな？もう少し考えて見ます

**デフォルトの名無しさん** · 2019/03/03(日) 12:18:50.69

>>139
規格ではdeleteしないものをdeleteしたら互換性に問題が出る。
自動でdeleteしたかったらスマートポインタ使うべき
独自c++擬き想定しているならc++17使うのも当然okのはず

生のnew使わせるなんて今時のc++ではとんでもない悪手

**デフォルトの名無しさん** · 2019/03/03(日) 13:13:27.54

VS2017は十分な出来なんだがテンプレートの展開中に内部エラーで転けることがあってそこだけは不満

**デフォルトの名無しさん** · 2019/03/03(日) 15:47:18.29

shared_ptr でJavaやC#のガーベージ・コレクションとほぼ同じ役目が期待できるから別にいいのでは。
C++は、shared_ptrが正式採用されたC++11で別の言語になった印象すらあるわ。

**デフォルトの名無しさん** · 2019/03/03(日) 15:57:24.31

循環参照が検出できないからJavaプログラムの参照をそのまま置き換えればオッケーというわけでもない
もちろんナマポよりは遥かにマシだけど

**デフォルトの名無しさん** · 2019/03/03(日) 15:59:19.15

>>155
面倒だとは思うけど、時間あるなら再現するコードと共にバグ報告送ってやってくれ

**デフォルトの名無しさん** · 2019/03/03(日) 16:11:53.27

unique_ptr<hoge> up0(new hoge());
や
shared_ptr<hoge> sp0(new hoge());

と書いたときと

unique_ptr<hoge> up1 = new hoge();
や
shared_ptr<hoge> sp1 = new hoge();

と書いた時で
違いは生じますか？
生じるとしたらどんな違いですか？

**デフォルトの名無しさん** · 2019/03/03(日) 16:19:53.78

副業解禁で激変する若者世代とマネージャー世代のキャリア観
https://www.businessinsider.jp/post-107782
フリーランスの職種20個の仕事内容と平均年収をわかりやすく解説
https://www.proof0309.com/entry/shokushu
時給1万円のバイトも。会社員向きのプチ副業を、“バイト芸人”が教える
https://headlines.yahoo.co.jp/article?a=20190226-00127948-bizspa-bus_all
副業が「会社にバレる人」と「バレない人」の大差
https://headlines.yahoo.co.jp/article?a=20190303-00268007-toyo-bus_all
正社員の10%以上が副業　中には過重労働で体調崩す人も
https://headlines.yahoo.co.jp/hl?a=20190227-00010000-wordleaf-bus_all
「副業で年2000万円稼ぐ男」に学ぶキャリア戦略
https://headlines.yahoo.co.jp/article?a=20190221-00266856-toyo-bus_all
加速する「副業社会」正社員の4割が「副業したい」気になる収入はどれくらい？
https://headlines.yahoo.co.jp/hl?a=20190218-00010001-danro-life
おすすめ副業22選を現役フリーランスが解説【在宅も可能】
https://www.proof0309.com/entry/zaitaku-hukugyou
会社を辞めてフリーランスで働きたいあなたが知っておくべき10のこと
https://www.businessinsider.jp/post-165731
フリーランスと会社員､働き方の根本的な差広がる｢雇用されない働き方｣の課題とは何か
https://toyokeizai.net/articles/-/263055
フリーランス人口は増える！今後は仕事もプロジェクト単位になる!？
https://freelance.mts-career.com/population/

**デフォルトの名無しさん** · 2019/03/03(日) 17:35:34.30

>>159
直接初期化とコピー初期化の違いを説明するとクソややこしい話になるんだけど
結論から言えばその場合はどっちも全く同じ

**デフォルトの名無しさん** · 2019/03/03(日) 17:53:40.63

make_shared使った方が良い？

**デフォルトの名無しさん** · 2019/03/03(日) 19:22:53.95

うん

**デフォルトの名無しさん** · 2019/03/04(月) 04:26:14.48

new 呼び出しが少なければ少ないほど精神衛生に良い。

**デフォルトの名無しさん** · 2019/03/04(月) 06:09:53.20

複数の関数の戻り値を足し合わせる処理で、それぞれの関数の戻り値をチェックしたい場合のすっきりする方法は何かありますか？
std::string result;
result += func1(a);
result += func2(b);
result += func3(c);
の各func1,2,3の戻り値をresultに足す前に空でないかを確認したいのです (1つでも空があった場合はresultも空にしたい)
単純に一時変数を用意して一つずつ判定するしかありませんか？

**デフォルトの名無しさん** · 2019/03/04(月) 06:27:48.33

typename Iterator::container_type::value_type
こんな風に::で三個つなげるのは合法ですかね？？

**デフォルトの名無しさん** · 2019/03/04(月) 06:31:54.66

エイリアス使えば

**デフォルトの名無しさん** · 2019/03/04(月) 06:33:10.80

funcN() を追加する直前の result.size() を記憶しておいて、
足した後に長さが増えてなかったら、今呼んだ funcN() の結果は空だった、
と判定することはできるか。

string から整数になるだけで、一時変数を使うのは変わらない上に、
処理内容が分かりやすくなるわけでもないけど。

**デフォルトの名無しさん** · 2019/03/04(月) 07:56:06.21

>>165
例外

**デフォルトの名無しさん** · 2019/03/04(月) 08:09:41.73

>>166
合法

**デフォルトの名無しさん** · 2019/03/04(月) 15:31:21.38

unique_ptr<int> u(new int[2]{4, 5}); // OK (A) -> int * が作られる u.get()[n] でアクセス可能 *u だめ

unique_ptr<int> u = make_unique<int>(6); // OK -> int * が作られる *u でアクセス可能 u[0] だめ

unique_ptr<int[]> u = make_unique<int[]>(2); // OK (B) -> int [] が作られる u[n] でアクセス可能 *u だめ *u.get() 可能

unique_ptr<int *> u = make_unique<int>(2); // コンパイルエラー (C)

unique_ptr<int *> u = make_unique<int *>(2); // コンパイルエラー (D)

unique_ptr<int *> u(new int *); // ok -> int ** が作られる *u = &hoge あれば **u でアクセス可能

(C)(D)がエラーになる理由と
(B)を(A)の様に同時に初期化したいとき
どう書けば良いか知りたいです

**デフォルトの名無しさん** · 2019/03/04(月) 17:39:35.24

C 型が違う
D int*が2から作れない

**デフォルトの名無しさん** · 2019/03/04(月) 19:03:47.51

>>170
どうもありがとう。

**165** · 2019/03/04(月) 22:26:16.82

>>168
>>169
ありがとうございます

結局こうすることにしてみました
auto addString = [&result] (std::string&& temp){
　if (temp.empty()){
　　throw 0;
　}
　result += temp;
};
try{
　addString(func1(a));
　addString(func2(b));
　・・・
}catch (...){
　return "";
}

**デフォルトの名無しさん** · 2019/03/04(月) 23:05:47.73

void f()
{
　static std::mutex mtx;
　std::lock_guard<std::mutex> lock(mtx);
　//何がしかの処理
}

これっていいの？

**デフォルトの名無しさん** · 2019/03/04(月) 23:25:00.41

C++11以降はセーフ、じゃなかったかな。

**デフォルトの名無しさん** · 2019/03/05(火) 00:17:46.56

セーフなわけがあるか！！１１１１！１１！！！！１！

**デフォルトの名無しさん** · 2019/03/05(火) 00:55:28.26

C++11だろうがなかろうが関係なくセーフだよ。

**KAC** · 2019/03/05(火) 01:01:35.52

人によってセーフの定義が違ってたりしない？

**デフォルトの名無しさん** · 2019/03/05(火) 01:03:06.00

C++11以降はセーフになったらしい（ｷﾘ
ttps://cpprefjp.github.io/lang/cpp11/static_initialization_thread_safely.html

**デフォルトの名無しさん** · 2019/03/05(火) 01:04:55.09

Double Checked Lockingはジャヴァのメモリモデルがうまく対応できてなくて騒ぎになったことがある技法

**デフォルトの名無しさん** · 2019/03/05(火) 01:11:12.97

もし関数内static変数の初期化をDouble Checked Lockingを使わずにスレッドセーフにしようとしたら、
関数に入る度に毎回馬鹿正直にクリティカルセクションに入るために1000クロックぐらい捨てることになってしまうま
スピンロックか何かの黒魔術で若干緩和する実装も有り得るかもしれんが基本は

ジャヴァではなくてC++の処理系がdouble checked lockingする分には
処理系がサポートするネイティブなアーキテクチャのみ考えれば良いから
問題が生じることは無いはずでとりあえずはめでたいと思うが、

**デフォルトの名無しさん** · 2019/03/05(火) 01:34:00.08

グローバルなスタティック変数のように実行前に初期化する仕様にいまさら変えられない事情でもあったか。

**デフォルトの名無しさん** · 2019/03/05(火) 01:38:41.08

リンカにシンボルを渡す手段がｲﾏｲﾁ決め手に欠くｷﾓｽ

**デフォルトの名無しさん** · 2019/03/05(火) 01:40:59.82

あと複数の翻訳単位間ではグローバル変数の初期化順序は保証されない（保証しようが無い）から
そういう混乱を避けるために関数内staticは関数に入ったとき初期化されてﾎｽｲ

個人的には使わないから知らんが

**デフォルトの名無しさん** · 2019/03/05(火) 02:16:13.00

>>171
unique_ptr<int[]> u(new int[2]{6, 7});

**デフォルトの名無しさん** · 2019/03/05(火) 02:54:35.71

std::dynarray ってどこ行ったん？
http://ezoeryou.github.io/boost-benkyokai-sapporo

**デフォルトの名無しさん** · 2019/03/05(火) 03:25:14.57

なんだろう
この違和感

**デフォルトの名無しさん** · 2019/03/05(火) 04:45:14.68

ライブラリを作るときは、hpp にはクラスの定義を、cpp には実装を書く、と理解しています。

クラスのメンバでない関数はどう扱うべきでしょうか。
hpp にプロトタイプ宣言を、cpp に中身を書く、というので合っていますか。

**デフォルトの名無しさん** · 2019/03/05(火) 04:47:10.42

inlineは？

**デフォルトの名無しさん** · 2019/03/05(火) 04:50:23.83

なぜヘッダはクラス限定だとおもったんだ?
それ以前にクラス以外では使用したことがないのか?

**デフォルトの名無しさん** · 2019/03/05(火) 05:01:47.80

宣言（Declaration）と定義（Definition）は用語なんで覚えといた方がいいよ

**デフォルトの名無しさん** · 2019/03/05(火) 05:18:53.19

ヘッダに書くのはクラスだから関数だからとかじゃなくて、複数の翻訳単位(≒cpp)で共通で使うかどうかで決まる
1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ

**デフォルトの名無しさん** · 2019/03/05(火) 05:48:49.52

>>190
inline なので（苦笑

>>191
ハ？
回答の体をなしていない。
> hpp にプロトタイプ宣言を、cpp に中身を書く
というやり方は許容されるという意味か。

>>192
覚えました。それで？

>>193
であれば、今私は複数の cpp ファイルを持つ予定はないので、ヘッダファイルは全く不要ということになります。

**デフォルトの名無しさん** · 2019/03/05(火) 05:55:22.28

ライブラリなんだろ？
自分はcpp1つでも、他の人のcppで使わせるためのクラスや関数があるはずだ
それをヘッダに書け

**デフォルトの名無しさん** · 2019/03/05(火) 05:59:24.21

>>195
その際、「プロトタイプ宣言はヘッダで、中身は cpp ファイルに」というルールかマナーか慣習はありますか

**デフォルトの名無しさん** · 2019/03/05(火) 06:13:55.29

>>196
特にないから適当に他人のマネしとけばいいと思う。

**デフォルトの名無しさん** · 2019/03/05(火) 11:45:31.15

>>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ

staticは付けた方が良いですか？(苦笑

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/05(火) 12:27:38.14

内部リンケージにするには static を付けるよりも
無名の namespace に入れる方が良いやり方
みたいな雰囲気があるんだけど、
インデントが深くなるのがなんか嫌なんだよね。

インデントは文法に影響しないわけだから、
付けないという選択肢もとれるけど、
それはそれでなんだかなぁって感じだし、
結局は static を付けちゃうんよ。

無名 (unnamed) namespace って使う？

**デフォルトの名無しさん** · 2019/03/05(火) 12:35:48.55

関数よりファンクタの方が速いという情報を見たのですが、メンバ関数を入れ子クラスでメンバファンクタ化すると高速化が期待できますか？

**デフォルトの名無しさん** · 2019/03/05(火) 12:41:35.39

コンパイラ次第だろ
実験

**デフォルトの名無しさん** · 2019/03/05(火) 12:50:59.28

VC2017で試したのですがテスト用の関数が単純すぎるのかグローバルのインライン関数、クラスのメンバ関数、クラスのメンバファンクタで差異が見られませんでした・・・

**デフォルトの名無しさん** · 2019/03/05(火) 12:51:22.93

どこに書いてもいいだろ
他人の書いたコードなんてどうせ誰も読まないし
読ませたいならドキュメントしっかりさせたほうがいい

**デフォルトの名無しさん** · 2019/03/05(火) 15:12:40.70

>>202
その「ファンクタの方が速い」ってのは、一般的に関数ポインタを介するのと比較して、だよ
理由はインライン展開できるからであって、その実験で差異が出ないのは当然

**デフォルトの名無しさん** · 2019/03/05(火) 19:05:23.76

ストアドよりインデックスのほうが速いよってスレなかったっけ。

**デフォルトの名無しさん** · 2019/03/05(火) 20:02:38.14

>>204
なるほど
ありがとうございます

**デフォルトの名無しさん** · 2019/03/05(火) 21:56:22.01

>>199
使う理由としてはメンバ関数を内部リンケージにしたらリンク速くなるかもという期待だけだな
実際速くなるか調べたことないけど

明示的にstaticとある方が読みやすいし、無名はデバッガで見たときクソ見辛くなるし

c++はこういうダメ仕様多過ぎてうんざりだわ

**デフォルトの名無しさん** · 2019/03/05(火) 22:06:02.21

腐ったビルド戦略のせいで無駄なオブジェクトコードの重複を生じるのはゼロオーバーヘッド原則に反しないのか？は疑問だな
極一部のマニアしか使わない機能付けてオナニーしてる暇があったら、いいかげん時代錯誤なビルド処理の抜本的な見直しをやってほしい

**デフォルトの名無しさん** · 2019/03/05(火) 22:21:06.27

メンバ関数の数はクラスのオブジェクト生成コストにどれくらい影響しますか？

**デフォルトの名無しさん** · 2019/03/05(火) 22:30:58.04

>>209
まず自分で計測しろ

**デフォルトの名無しさん** · 2019/03/05(火) 23:07:56.79

>>209
数によるコスト差0だよ

>>210
計測したことあんの？

**デフォルトの名無しさん** · 2019/03/05(火) 23:19:26.52

ありがとうございます
というのもメンバ変数がなく多数の関数をまとめただけのクラスがあるのですが、次のどれがいいのか悩んでいまして
(1) 全部static関数にする
(2) クラスをnamespaceにして全部グローバル関数にする
(3) 呼び出す場所で逐次インスタンスを作成する
(4) 呼び出し側クラスでこのクラスのポインタをメンバとして持ち、コンストラクタでインスタンスを受け取るまたは生成する
この場合のベストプラクティスはありますか？

**デフォルトの名無しさん** · 2019/03/06(水) 00:13:14.35

(1)か(2)を好みに応じて

**デフォルトの名無しさん** · 2019/03/06(水) 00:17:08.38

特に何もないなら2

templateと組み合わせるなら1とか3は多用するけど4は無いな

**212** · 2019/03/06(水) 00:21:02.86

ありがとうございます
(2)でやってみることにします

**デフォルトの名無しさん** · 2019/03/06(水) 00:32:13.90

1 は、どうして君はすべての関数を、static 関数にできると思ったの？
static関数と、関数のライブラリ・モジュール化は関係ない

3, 4 は、どうして君は、関数を使うのにインスタンスが必要なの？

インスタンスの関数は、他の言語ではメソッドと言って、
そのインスタンスのメンバ変数を使うものに対して、特別な名称を付けている。
つまり、各インスタンスで値が異なるもの

メソッドは、一般的な関数とは異なる。
メソッドや一般的な関数と、関数のモジュール化は関係ない

例えば、Ruby では、
Math.log2( 8 ) #=> 3.0

このようにインスタンスを作らなくても、呼べる関数をモジュール関数と言って、
各インスタンスから呼ぶ関数を、メソッドと言って区別している

**212** · 2019/03/06(水) 00:42:25.73

そう言われるとそうですね
オブジェクト指向ではmain関数以外全部クラス/構造体で作成するものだという先入観がありました

**デフォルトの名無しさん** · 2019/03/06(水) 01:06:06.33

>>214
無理矢理4にしたいケースを考えると、同じインターフェースを持つ関数群A,Bを場合によって切り替えて使いたい場合に敢えてインスタンスのポインタとすることもあるかな。今回の質問者の場合には当てはまらないだろうけど。

**デフォルトの名無しさん** · 2019/03/06(水) 01:10:14.42

>>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ
名前無しでも何でも良いが、その場合はクラスはnamespaceの中に入れないと危険が危なすぐる…

同じ名前空間に属する同じシグネチャのFoo::func()が異なる関数として複数のcppで定義された場合、
どっちが呼ばれるか定まらない処理系が実在する（VC++2010とか
多分ODR違反で未定義動作なんだと思う

**デフォルトの名無しさん** · 2019/03/06(水) 01:13:13.20

曖昧さは、利点にも欠点にもなりうる。
namespaceのグローバル関数ではなくクラスのスタティック関数にすることで曖昧さがなくなりコンパイルエラーを避けられる場合がある。

**デフォルトの名無しさん** · 2019/03/06(水) 01:14:08.29

>>219訂正
CPPでクラスを定義する場合は無名namespaceに入れないと危険が危なすぐる、
無名namespaceは異なる翻訳単位間では別名として扱われるから安全

一方、名前付きnamespaceでは異なるCPPで偶然
同じ名前空間に属する同じシグネチャのFoo::func()が作られてしまう危険性を排除できない

**デフォルトの名無しさん** · 2019/03/06(水) 01:21:31.24

>>220
そのクラスに非staticなメソッドを設けたとたん、
>>219と同じ話でどのFoo::func()が呼ばれるかわからないという不正な動作をする危険性が生じる

驚くべきことに、VC++2010の場合リンカが何のエラーも警告も出さない
それでいてしっかり変な動作になる（a.cppで定義したFoo::func()を呼んだつもりがb.cppで定義された同じシグネチャの別のFoo:func()が呼ばれる