C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

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

前スレ
C++相談室 part145
http://mevius.5ch.net/test/read.cgi/tech/1568362404/

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

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

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

**デフォルトの名無しさん** · 2019/12/14(土) 13:37:51.96

といってもロックレス何ちゃらぐらいの制御であればInterlockedCompareExchange()で済むから
スレッド間の通信なら普通メモリバリアとか直接触る必要は無いが

**デフォルトの名無しさん** · 2019/12/14(土) 13:38:24.93

>>869
迷信

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:11.91

ソースは？

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:40.59

リードキューやコマンドキューにコマンドが入るのはアウトオブオーダープロセスの事後であるため
そのような保証は無い

**デフォルトの名無しさん** · 2019/12/14(土) 13:41:05.07

それのソース

**デフォルトの名無しさん** · 2019/12/14(土) 13:44:15.66

https://github.com/herumi/misc/blob/master/cpp/fence.md

**デフォルトの名無しさん** · 2019/12/14(土) 14:15:12.84

x86系は
シングルコアのマルチスレッドアプリ
の多くがそのまま動くように出来てる

シングルコア時代が長かったから

**デフォルトの名無しさん** · 2019/12/14(土) 14:55:10.15

>>865
＞テンプレートなのは見ればわかるさ
＞だから何なのか
普通に考えて、実体化がまだなのに定義（初期化）を強制される妥当な理由はない、ということ

**デフォルトの名無しさん** · 2019/12/14(土) 14:57:30.67

確かにリンク先のインテルのマニュアルの
>8.2.3.2 Neither Loads Nor Stores Are Reordered with Like Operations
>Example 8-2. Stores Are Not Reordered with Older Loads
に
>Initially x = y = 0r1 = 1 and r2 = 1 is not allowed
と書いてあって>>875と同じことが書いてあるが疑わしい
マニュアルが間違っているのではないか、

ちな
>8byteのデータはアドレスが8の倍数のときにアライメントされている。
から安全に読み書きできるというのはi486みたいな古いプロセッサーだとかえって危険らしい
>8.1.1 Guaranteed Atomic Operations
を見たらﾜｶﾙ、

**デフォルトの名無しさん** · 2019/12/14(土) 15:04:35.33

つか上のインテルのマニュアルには「投機的実行時中のメモリアクセスではメモリアクセス例外は発生しない」
旨が2箇所ぐらいに書かれているが、
ということはつまりアセンブリコード上A→BまたはA→Cというメモリアクセスが条件によってどちら片方だけ実行されることを意図したコードであっても
A→B→Cというメモリアクセス順に成り得ることを意味し、他コアからもそう見えてしまうはずだが、
これをメモリアクセス順がreorderされていないうちに入れてしまうのはどうなのか、、、
マニュアル執筆者の国語の再教育が必要なのではないか

**デフォルトの名無しさん** · 2019/12/14(土) 15:10:49.52

>>877
おまえさん、もしかして
テンプレートの宣言と定義と
オブジェクトの宣言と定義を
ごっちゃにしてないか？

int test;
int test = 5;
これは宣言と定義じゃなく定義の重複だぞ

**デフォルトの名無しさん** · 2019/12/14(土) 15:13:40.23

お前なぁ
x86のこと大して詳しくないのにしゃしゃり出てくるからそういう情けないこと言うはめになるんだよ
x86でstd::atomicのmemory_orderを変えてバリア付きがどういうインストラクションになるか見てみな
storeのseq_cst以外は素のmovだから(コンパイラ依存だから絶対ではない)

**デフォルトの名無しさん** · 2019/12/14(土) 15:20:09.00

そりゃー間違ったマニュアルにしたがって実装したら間違った実装になり得る（ｷﾘ

ていうかアウトオブオーダー実行の影響がマルチコアCPUにおいても透過的だと認めやっても良いが、
>>879の投機的実行の件はどうなんじゃ？
あるコアが投機的実行中に他のコアをストップさせるのでは何のための投機的実行かわからん…

**デフォルトの名無しさん** · 2019/12/14(土) 15:21:14.95

>>877
× 普通に考えて
〇俺の頭の中で

× 妥当な理由はない
〇妥当な理由は思い当たらない

テンプレートなら初期化は不要という主張なら、
constexpr 変数の宣言と定義を分離できないことは納得してるのかな？
そうだとして、それをテンプレートの時だけ可能とすることに意義があると思うの？

特別ルールを設ければコンパイラ実装やプログラムの読み取りにコストがかかるから、
明確が意義がなければ特別ルールは無いのが妥当だと思うよ。

**デフォルトの名無しさん** · 2019/12/14(土) 15:24:42.79

>>880, >>883
マウント取るのが最優先でまともな回答できない（するつもりも無い）んなら黙っててくれ

＞これは宣言と定義じゃなく定義の重複だぞ
externつけたら？

＞それをテンプレートの時だけ可能とすることに意義があると思うの？
テンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる

さて、
＞× 普通に考えて
＞〇俺の頭の中で

＞× 妥当な理由はない
＞〇妥当な理由は思い当たらない
こんなゴミみたいな煽り入れてきたからには逃げるなよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:32:39.86

>>884
おまえさんの元の質問はこうだったな
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;

どこにexternなんて書いてある？
マウントがどうたら気にするあまり後出しなんかしてるのはそっちだぞ
こっちはそんなこと微塵も考えちゃいねえよ失敬な
最初の口調に戻れよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:36:57.55

間違えた
Ｘテンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる
○初期化に使われる定数式の評価を遅らせられる

言い換えれば、宣言と定義を分離できないならconstな変数テンプレートの宣言時には
それに使う定数式内のすべての型が完全型であることを強制されてしまう
＝std::is_integral_v = std::is_integral<T>::valueでいえば
is_integral構造体の方が取り回しがいい、ということ
なんのために変数テンプレートが導入されたのか・・・・

**デフォルトの名無しさん** · 2019/12/14(土) 15:37:56.58

>>885
自分が失敬だからこうなってるとは考えられないんだな
何様だよ、そもそも質問に答えてないだろうが

**デフォルトの名無しさん** · 2019/12/14(土) 15:43:43.09

>>887
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;
を例示しての質問に対して
int test;
int test = 5;
という答えをしているぞ
valueがtestになったのは悪かったが
余計な飾りをとって問題の核心を指摘したんだよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:48:43.77

家事があるんでしばらく離席する

**デフォルトの名無しさん** · 2019/12/14(土) 15:58:10.05

規格でそうなってる（テンプレートゆえの特例は無い）のが”わかってるなら”
最初からそう言ってくれれば済むんじゃないの？
>>854を読み直せよ、テンプレートのことが完全にすっぽぬけた上に失礼な回答だろ

＞コンパイラのバグとまで言う根拠は何だ？
とまで、って・・・・普通にありえるだろ、動作が違うんだから（未定義とかいう屁理屈は無しで）

で、>>883は逃げたの？

**デフォルトの名無しさん** · 2019/12/14(土) 16:55:24.17

>>886
やっぱり constexpr 変数の宣言と定義を分離して何がしたいのか、
何ができるようになるのか、が見えてこない。ごめんね。

宣言だけ見える constexpr 変数への参照やポインタだけはとれるようになるけど、
それだともう constexpr である必要なくて const 変数でよさそうで、それならふつうに
宣言と定義は分けられるし。

ちなみにテンプレート実体化までテンプレート引数依存箇所の評価はされないから、
宣言と定義を分ける話を「評価を遅らせられる」と言い表しているのも何か間違ってそう。
「記述を遅らせられる」の間違い？

**デフォルトの名無しさん** · 2019/12/14(土) 17:16:54.80

だめだこいつ
絶望的に人に者を尋ねる態度がわかってない
「言ってくれれば済む」とか図々しすぎ
技術的な議論がしたいがこいつ相手では
不必要にイラついちまって無理だわ
俺そんなに人間できてない

**デフォルトの名無しさん** · 2019/12/14(土) 17:24:00.92

>>891
すまん、
＞テンプレート実体化までテンプレート引数依存箇所の評価はされない
これ検証してみたらたしかにそうだった
手元のコードで完全型を要求されたから、初期化時に不完全型を使えないと思い込んでた
（おそらくconstexprな変数テンプレートの実体化が、必要な型の実体化より先に来てたっぽい
多分構造体か何かでワンクッション置けば解決できると思う）
これなら確かに分けられなくて問題無いね

>>892
＞いいか、constexprは翻訳時定数だぞ
＞それを翻訳段階9まで未解決のままにできると思うか？
＞なんかとんがってんな
＞後出しなんかしてるのはそっちだ
＞余計な飾りをとって問題の核心を指摘したんだよ
さらには
＞最初の口調に戻れよ
の上で
＞技術的な議論がしたいがこいつ相手では
＞不必要にイラついちまって無理だわ
よくそんなセリフが言えたもんだ
自己評価高すぎじゃない？ｗｗｗｗ

**デフォルトの名無しさん** · 2019/12/14(土) 17:52:18.36

意見が合うとか合わないとか以前の問題
根底的なメンタリティに欠陥がある相手とは話にならない

**デフォルトの名無しさん** · 2019/12/14(土) 17:58:45.99

FYI

>>846
Bug 68012: g++ incorrectly accepts forward declaration of constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68012

>>848
One definition rule
https://timsong-cpp.github.io/cppwp/n4659/basic.def.odr#1
> No translation unit shall contain more than one definition of any variable, function, class type, enumeration type, or template.

**デフォルトの名無しさん** · 2019/12/14(土) 18:08:23.02

>>895
わざわざありがとう、やっぱgccのバグだったのね

**デフォルトの名無しさん** · 2019/12/14(土) 19:50:50.54

GCCに踊らされてスレを浪費した

**デフォルトの名無しさん** · 2019/12/14(土) 20:04:04.94

>>837
オーバーロード=多態性じゃないんで…
オーバーライドのことなら当然cで実現できる

**デフォルトの名無しさん** · 2019/12/14(土) 21:11:37.22

>>898
どうやって？
いや、ディスパッチの方法はいろいろあると思うが

**デフォルトの名無しさん** · 2019/12/14(土) 21:15:53.72

禿もそんなことを言いながら
virtualの導入には当初反対から出発したんだよな

**デフォルトの名無しさん** · 2019/12/14(土) 21:26:53.87

>>899
その話題QZ相手にやったばかりなんで自分で調べて

**デフォルトの名無しさん** · 2019/12/15(日) 09:10:03.56

君が忘れた腕時計見つめながら。

**デフォルトの名無しさん** · 2019/12/15(日) 10:29:35.56

>>898
overload は、同じ関数名で仮引数の型が違う関数を作れるという多態性のことですよ。

**デフォルトの名無しさん** · 2019/12/15(日) 10:52:20.53

ツリーのイテレータがあるとして、イテレータが返すのはノードじゃなくて、ノードの持つ値ですよね？
すると、イテレータは立体機動出来ないといけなくなるけど、begin().begin()とか変ですよね？
begin().parent()とか。

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

イテレータが返すじゃなくて、イテレータの逆参照が返すかな。

**デフォルトの名無しさん** · 2019/12/15(日) 11:08:51.65

コレクションとしては子孫ノード全部を列挙できればよくて、ツリー構造に沿った操作が行いたいなら
それに加えて直接の子ノードのみを列挙するイテレータが用意できればいいだろう。

**デフォルトの名無しさん** · 2019/12/15(日) 11:17:54.16

何が子ノードのみを列挙するイテレータを返すかがよくわからない。
ノードの値がイテレータを返すことはできないので、ノードが子ノードを指すイテレータを返すとすると、イテレータの逆参照はノードを返すことになる。
これは意味論的にちょっと違うかなって。
コレクションにおいて位置はイテレータで示されるので、立体的な位置を持つツリーでは、イテレータ自身が立体機動出来て、巡回能力を持つイテレータは、reverse_iteratorのように外部に用意されれば良いのかなと思ったんだけど。
たとえば、レベルオーダーや深さ優先の巡回イテレータがあるとすると、普通に考えるとスタックやキューが内部に必要にある。
というわけでコピーのコストがあるので、これを標準には出来ないんじゃないかなって。

**デフォルトの名無しさん** · 2019/12/15(日) 11:22:50.93

子ノードを指すイテレータの逆参照が子ノードを返すとすると、*node.begin()は子ノードを返す。
**node.begin()は最初の子ノードの値を返すことになるんだけども。
イテレータの逆参照がノードを返す場合、初期化子リストが素直に実装出来てイイんだけども、イテレータの逆参照が値を返さないのが腑に落ちない感じ。

**デフォルトの名無しさん** · 2019/12/15(日) 11:23:28.40

>>903
こらこらoverloadは多態じゃない多重定義だ
多態はpolymorphism間違えるな

**デフォルトの名無しさん** · 2019/12/15(日) 11:27:25.99

イテレータは演算子の実装を求められてるわけではなく、その演算子を呼び出した時の効果を求められてるだけなので、++(int)はスタックをコピーしない方法を考えた。

**デフォルトの名無しさん** · 2019/12/15(日) 11:30:57.88

そこは値じゃなくてノードを返すイテレータでいいんじゃね？
必要ならイテレータ自体を拡張してもいいだろうけど、この場合はあまり応用できそうもないし。

**デフォルトの名無しさん** · 2019/12/15(日) 11:31:53.05

そうなのかな？

**デフォルトの名無しさん** · 2019/12/15(日) 11:37:55.15

まずイテレータで何を抽象化したいかを明確にしなよ
ノードを意識させたいのか？

**デフォルトの名無しさん** · 2019/12/15(日) 11:38:38.78

STL風ツリーって検索しても絶対出てこないし、CIAが絡んでるような気がしてきた。

**デフォルトの名無しさん** · 2019/12/15(日) 11:39:36.48

そこがわかんないんだよねえ。
禿4とか読んでると、イテレータは位置を意味してるように思うんだけど。

**デフォルトの名無しさん** · 2019/12/15(日) 11:45:00.74

ツリー構造
範囲が広すぎて
汎用化すると使い勝手が悪くなるからしない
ってだけかと

**デフォルトの名無しさん** · 2019/12/15(日) 11:56:45.76

recursive_directory_iteratorとかね

**デフォルトの名無しさん** · 2019/12/15(日) 12:06:14.82

なんでdirectory？
treeでいいじゃん

**デフォルトの名無しさん** · 2019/12/15(日) 12:22:05.91

いや立体がどうたら言ってるから
じゃあrecursive_directory_iteratorを使うユーザーのコードは
いちいち多重ループだの再帰だのといった処理になるのかって
思ってさ

**デフォルトの名無しさん** · 2019/12/15(日) 12:24:23.41

ツリーは、あるノードの親が知りたいときもあるはず。

**デフォルトの名無しさん** · 2019/12/15(日) 13:07:24.45

ごちゃごちゃ考える前にイテレータの本分を決めなよ
begin()からend()まで++で走らせた時にどうなってほしいの？
話はそれからだ

**デフォルトの名無しさん** · 2019/12/15(日) 13:09:44.18

一般にtreeの探索順序はアルゴリズムと深く結びついてるし、
そこ凝りだすと沼だぞ。

**デフォルトの名無しさん** · 2019/12/15(日) 13:09:51.26

関数ポインタをシリアライズしてファイルとして保存し、
ファイルからその関数ポインタを利用できる形に復元する方法ってあるのでしょうか？

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

関数だろうが変数だろうがポインタはただの整数値でしょ

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

>>923 環境や「利用」の仕方を具体的に限定すればやりようはあるかもね。

**デフォルトの名無しさん** · 2019/12/15(日) 13:20:48.30

次に(別のプロセスで)ファイルを読み込んだときに、
元の関数を同じ番地で参照できると限らんしな。
関数ポインタの配列のインデクスなら大丈夫だろうだけど。

**デフォルトの名無しさん** · 2019/12/15(日) 13:23:00.95

https://ja.cppreference.com/w/cpp/iterator/reverse_iterator/operator%3D
これconstexprになってるけど、どういうときに定数になるんだろ？
end()の時かな？

**デフォルトの名無しさん** · 2019/12/15(日) 13:39:23.84

C++20以降のvector/stringとか
使われる時にconstexprであることを妨げないようにするために付いてるんだと思う

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

どうもありがとう。

**デフォルトの名無しさん** · 2019/12/15(日) 13:52:49.06

constexpr関数の中で使うため。

**デフォルトの名無しさん** · 2019/12/15(日) 14:30:37.97

デストラクタがデフォルトでvirtualじゃないのは設計不良ではあるまいか

**デフォルトの名無しさん** · 2019/12/15(日) 14:34:47.01

あえてベースの方のメソッドを呼びたいなんてことあるのかね？

**デフォルトの名無しさん** · 2019/12/15(日) 14:38:17.75

>>931 https://isocpp.org/wiki/faq/virtual-functions#virtual-dtor-rationale

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

>>931
C++では基本的にゼロコストでできるところはそうできるようにするポリシーだからvirtualが必要なときだけvirtualを明示的に指定させる、というのをどこかで読んだ気がする

**デフォルトの名無しさん** · 2019/12/15(日) 15:29:48.68

virtualでなかったら継承禁止にしても良かったんじゃないかとは思う

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

そうするとメタプログラミングに色々と支障が出たはずだし
STLも結構継承使ってるから実現出来なかったかコスト増えてるよ

**デフォルトの名無しさん** · 2019/12/15(日) 16:52:10.11

デストラクタをvirtualにする必要があるのは、baseのポインタ経由でdeleteする場合だけ
baseのポインタを使うことすらないようなもの(CRTPなど)までvirtualになるのは
どうなんだろうか

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

unique_ptr使えばvirtualにする必要無いのでは？

**デフォルトの名無しさん** · 2019/12/15(日) 17:16:05.58

>>938 んなこたーない。
shared_ptr<Base>{new Derived} なら virtual デストラクタ不要になるから、間違えて覚えてるだけでは？

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

>>937
>デストラクタをvirtualにする必要があるのは、baseのポインタ経由でdeleteする場合だけ
mjk、

**デフォルトの名無しさん** · 2019/12/15(日) 19:10:50.35

セオリーとして覚えてる人多いけど、何故なのかまで考えてない人が多い例の一つだね
要するにdeleteする基底のポインタからデストラクタを呼ぶ際に末端のデストラクタを呼ぶ方法(vtable)が必要というだけ
末端のデストラクタを呼べれば、そこから基底のデストラクタを呼んでいくのは何が基底かわかりきってるから自動で出来る

**デフォルトの名無しさん** · 2019/12/15(日) 19:29:34.24

>>941
>基底のポインタからデストラクタを呼ぶ際に末端のデストラクタを呼ぶ方法(vtable)が必要というだけ
mjk、

◆QZaw55cn4c · 2019/12/15(日) 19:42:55.10

永遠の初心者です、お願いします
1. 式で if 文を表現したいときは条件演算子（三項演算子 ?: ）が使えますが、同じく式でループ構造を表す方法は C++11 以後にありますでしょうか？
2. 1 の質問の理由としては、C++ は Java とちがって uper() がなく、派生クラスのコンストラクタの基底クラス初期化部分に式しか書けません、ここにループを書くとすれば「コンストラクタ用メンバ関数（メソッド）」を置いていますがいかにも無様だと思っています…
3. ある既存のクラスに皮をかぶせて機能アップを図るとき、もとのクラスの派生クラスとして機能アップ部分を既述することは、よくある定石でしょうか、それともあまりしないことでしょうか？

---
以上3点の質問は以下のプログラムを書いていて感じました
お題は「エラトステネスのふるい」、ただし、当初、まっとうにふるいを書いた後、機能アップ項目として
篩部分に格納する数は 2n + 1 奇数に限定する、あるいは 6n + 1, 6n + 5 の形のみに限定する
等を元の篩に対して派生クラスとして記述しました
https://ideone.com/YPlfsC

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

>>943
ラムダ式の出番かな？
void test(bool flag) { flag ? []{ for(int i = 0; i < 10; ++i) cout << i; } : throw 1; }

**デフォルトの名無しさん** · 2019/12/15(日) 20:05:17.27

エラストテネス
6n+1, 6n+5だけ保持とかってみんな考えるよね

ちなみに
巨大なテーブル作成時のパフォーマンスを上げるなら
キャッシュが効くよう分割処理するのが非常に効果的
スレッド分割の為にいずれにしろ分割処理は作る事になる

**デフォルトの名無しさん** · 2019/12/15(日) 20:07:01.24

エラトステネス

**デフォルトの名無しさん** · 2019/12/15(日) 20:14:20.76

高分子エラストマー

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/15(日) 20:20:59.00

>>943
初期化部分に複雑な処理をベタ書きする方が無様だと思うよ。
初期化リストの中にそんなごちゃごちゃしたこと書きたい？
ワイが思うだけなので世間でどう思われてるかは知らんけどとりあえずひとつの意見として。

**デフォルトの名無しさん** · 2019/12/15(日) 20:54:13.00

>>939

親クラス(Base)のデストラクタに virtual 付けなくても...
{
shared_ptr<Base> obj( new Derived() );
} // ~Derived() called, then ~Base() called.

~Derived() はコールされるんですね... 確認してみて驚きました。
これができる仕組みを誰か教えてください。
スマートポインタのオブジェクトは子クラスの事何も知らないのに
どうして ~Derived() のコールが可能なのでしょうか？

**デフォルトの名無しさん** · 2019/12/15(日) 21:07:41.82

>>949
いわゆるtype erasure
https://blog.cryolite.net/entries/2006/01/08#p1

**デフォルトの名無しさん** · 2019/12/15(日) 21:19:04.13

>>950
まだ仕組みのとこまでですが理解できました。ありがとうございます。

**デフォルトの名無しさん** · 2019/12/15(日) 21:24:07.01

質問ですが構造体Fooの内側に構造体Barが定義されているという入れ子になった構造体において、
Fooの外のコードでFoo::Barのサイズをsizeof()で知りたいとき、以下は正しい？
1. C++だとsizeof(Foo::Bar)と書いたらおk
2. CまたはC++でもC互換構文の範疇で済ます場合、次のどちらかの方法でしか書けない
(1) Foo::Barのインスタンスyが存在するスコープ内で、sizeof(y)と書く
(2) Fooのインスタンスxが存在するスコープ内において、Foo::Bar型のメンバyをFooが持つ
　　　　（Foo::yが定義されている）という条件の下で、sizeof(x.y)と書く

**デフォルトの名無しさん** · 2019/12/15(日) 21:39:08.56

ふとｵﾓﾀがインスタンスの必要性は無くせるかもしれん
Foo::Bar型のメンバFoo::yが定義さえされておれば、Fooのインスタンスが無くても
　sizeof(((Foo*)0)->y)
と書けばC言語で逝けるかもしれん…
ｽｹﾞｰ気持ち悪いコードだが、、、、

**デフォルトの名無しさん** · 2019/12/15(日) 21:46:34.52

>>951
あくまでコンパイル時の型で決まるだけだから要注意
例えば

class A;
class B : public A;

A* p = new B();
std::shared_ptr<A> a(p);

これだとBのデストラクタは呼ばれない

**デフォルトの名無しさん** · 2019/12/15(日) 21:48:17.68

なんでそんな中途半端な機能を
わざわざコストをかけて入れたんだろう

**デフォルトの名無しさん** · 2019/12/15(日) 21:49:32.31

やむを得ず
なんだろうけど

**デフォルトの名無しさん** · 2019/12/15(日) 21:51:55.29

>>953
Linuxカーネルとかそういう感じのマクロ満載だよ
C言語はそういうもん

**デフォルトの名無しさん** · 2019/12/15(日) 22:05:12.60

type erasureと相性悪いんだっけ

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/15(日) 22:15:04.90

>>943
思い出した。
gcc や clang の拡張で良ければ複文が式になる。
だいぶん昔からある機能。

#include <vector>
#include <iostream>

int main() {
std::vector<int> foo(({int i; for(i=0; i<3; i++); i;}));
std::cout << foo.size() << std::endl;
return 0;
}

◆QZaw55cn4c · 2019/12/16(月) 19:39:21.34

>>944,945,948,959
コメントありがとうございます！

>>944,959
まずgcc拡張
＞SieveDerived(int n) : Sieve<T>(({int r; while((r = index(n)) == 0) n--; r;})) { } /* HERE!! */
で問題なく動作しました
すでにgcc拡張で存在するところからみて、私の希望はあながち無謀かつ無稽なものではないことを知りほっとしました
次にラムダ式で定義して即評価する方法がみつかりました
＞SieveDerived(int n) : Sieve<T>([](int n)->int{int r; while ((r = index(n)) == 0) n--; return r;}(n)) { } /* HERE!! */
これがやりたかった！とても満足しています、ありがとうございました！
今までは関数オブジェクトの糖衣構文としてしかみていなかったラムダ式を、自分の希望にあわせて（あるいはねじまげてでも）採用し、表現できるようになったのは一歩理解が深まったかと考えています

>>948
＞初期化リストの中にそんなごちゃごちゃしたこと書きたい？
クラスのメソッド＝メンバ関数には、クラスの提供する機能として独立性の高いもの、少なくとも二箇所で同じような処理がダブっているもの、あるいは主観的には「lemma」として成り立つものを書きたいと考えていました
一箇所でしか使わないものでも lemma 性があるのならば private メソッドとして書くのもありかと思っていますが、今回の場合は、他におなじような処理をおこなっている場所はなく、かといってメソッドとして立てるほどのことでもないので、
複数個所からコールできるメソッドにはしたくなかった、という主観がありました、そういう性質の記述ならば初期化リストにごちゃごちゃ書くのもありかと、読み手には他からコールされ得ないことが自明である点からしても

https://ideone.com/y3ROXS

**デフォルトの名無しさん** · 2019/12/16(月) 20:14:24.13

まあこういう自己満は通過儀礼だよな

**デフォルトの名無しさん** · 2019/12/16(月) 21:46:21.90

lambdaの即時評価はjsだと多用されているイメージ
ブロックスコープないからね

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/17(火) 00:52:53.01

>>960
> すでにgcc拡張で存在するところからみて、私の希望はあながち無謀かつ無稽なものではないことを知りほっとしました

30 年以上の実績があってもなお仕様に入らない程度に駄目なんだよ。

**デフォルトの名無しさん** · 2019/12/17(火) 03:23:09.50

プライベートメンバの単体テストってみんなどうしてるのかな。

**デフォルトの名無しさん** · 2019/12/17(火) 03:30:02.23

#define private public

**デフォルトの名無しさん** · 2019/12/17(火) 03:58:13.47

#if 0
friend test;
#endif

**デフォルトの名無しさん** · 2019/12/17(火) 07:08:07.08

#ifndef NDEBUG
friend struct test;
#endif

**デフォルトの名無しさん** · 2019/12/17(火) 07:46:15.26

闇言語

**デフォルトの名無しさん** · 2019/12/17(火) 11:20:07.09

namespace Method{ namespace Detail {
template<typename ReturnType, typename ... ArgTypes> struct MethodRegister{};
} }
// 文字列で呼び出すための関数を登録するためのマクロ
#define METHOD_REGISTER_WITH_NAME( NAME, FUNC, RETURNTYPE, ... ) \
namespace Method { namespace Detail { \
template<> struct MethodRegister<RETURNTYPE, __VA_ARGS__> { \
using Functional = std::function<RETURNTYPE(__VA_ARGS__)>; \
MethodRegister() { \
MethodContainer::GetInstance().Register<RETURNTYPE, __VA_ARGS__>( #FUNC, Functional( static_cast<RETURNTYPE(*)( __VA_ARGS__ )>( FUNC ) ) ); \
} \
~MethodRegister() { \
MethodContainer::GetInstance().Unregister( #FUNC ); \
} \
}; \
static MethodRegister<RETURNTYPE, __VA_ARGS__> sMethodRegister##FUNC; \
} }
void HOGE(){
std::cout << "Hello World!" << std::endl;
}
void HOGE( std::string text ){
std::cout << text << std::endl;
}
METHOD_REGISTER_METHOD( HOGE, void );
METHOD_REGISTER_METHOD( HOGE, void, std::string );

こういった形で関数を登録する用のクラスを生成し、変数として生成して管理の自動化を行いたいのですが、
関数のオーバーロードを対応しようとした所、クラスの再定義や変数の再定義、管理クラスへの重複登録等
多数の問題が出て詰まってしまいました。
こういった問題を対処するにはどうすればよいのでしょうか？