C++相談室 part164

2023/05/09(火) 11:50:52.06

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/06/14(水) 08:49:33.85

/proc/self/stat というファイルを覗きに行くか、
getrusage というシステムコールで取得することになるかな

2023/06/14(水) 09:19:31.16

>>182
そのために shrink_to_fit がある。
詳細は実装依存なので何もしない関数であっても仕様に反しないけど
常識的には各実行環境で効率的に動くように実装されるので
まずは試してみても損はないと思う。

アロケータを自作してもあまり制御できないんよね。
アロケーションが必要になったらコンテナからアロケータが呼ばれるという
受動的な構造なのでコンテナによるメモリ管理戦略にそれほど関与できるわけではない。

本当にどうしても標準ライブラリの挙動の詳細が不満なら
自分で同等のものを実装する (または望ましいものをどこかから見つける) しかないよ。

2023/06/14(水) 10:15:22.04

>>182
new で造って delete (または delete []) で解放

2023/06/14(水) 12:28:17.37

更にいうと、deleteはgccでは推奨されないのでptrを使うよりはstaticもしくはvirtualを使いましょうね。

2023/06/14(水) 12:29:45.65

>>182
>>185とほとんど同じだけどunique ptrで管理。
ヒープの確保時間が問題になるならアロケーター使ってヒープを予約する。

2023/06/14(水) 13:12:37.90

>>182
vector<空にしたいオブジェの要素の型>().swap(空にしたいオブジェ)

2023/06/14(水) 13:33:02.07

>>188
vector<空にしたいオブジェの要素の型> hoge;
が既にあったとしたら
vector<空にしたいオブジェの要素の型>(hoge).swap(hoge);
で良いらしいけど副作用の心配無い？

2023/06/14(水) 14:03:16.39

>>183
ありがとうございます
> getrusage
を試してみようと思います

>>185-187
STL コンテナを使うとしても自作クラスを使うとしても、オブジェクトを unique_ptr で持つことにして要らなくなったら reset() すれば確保していた分のメモリを捨てられるということでしょうか
依存関係が絡み合っていて簡単に小さいスコープに分割できないときは試してみようと思います

2023/06/14(水) 14:16:54.18

reset()は違うと思う

2023/06/14(水) 14:26:34.51

>>189
その場合はメモリアクセス領域が変わるのでswapする前に取得済みだったイテレータは再取得する必要あり

2023/06/14(水) 15:52:59.34

>186 が何を言ってるのか意味不明でこわい。

2023/06/14(水) 15:54:13.97

>>191
「reset() すれば確保していた分のメモリを捨てられる」で間違いないでしょ。

2023/06/14(水) 18:26:24.05

>>190
resetする必要は無いよ。

コンテナから普通に要素を削除すれば、後はコンテナクラスがよろしくやってくれる。効率は実装次第だけど。

2023/06/14(水) 18:51:34.14

>>195
コンテナクラスがよろしくやってくれるのに任せるのであれば、スマートポインタで持たずに単にコンテナとして持つのと変わらないように思うのですが、違うのでしょうか。
ちゃんと理解していなかったら申し訳ありません。

2023/06/14(水) 18:58:01.98

vectorを信頼するなら単にclear()してshrink_to_fit()すればいい
信用できないならスマポで持っといていらなくなったら手動でブチ消せばいい
それすら信用できないならイチから自分で作れ
お前がどれだけ心配消化による

2023/06/14(水) 19:18:20.42

>>196
どのコンテナを使うかによる。

vectorとかdequeはまだ確保していない要素用の領域をしばしば予約するから、>>182のような状況を回避するのは面倒臭い。

listとかmapは(これも実装次第だけど)まだ確保していない要素のための領域を予約したりしないから、他のデメリットを許容するなら>>182対策の選択肢になる可能性はある。

いずれにしても、そこまで気にするならまずベンチマークを取って実態を調査すべきだし、そもそも巨大なメモリを頻繁に確保・解放するのは設計に問題があることが多いから、メモリを解放しないで済む方法を検討してみる。

2023/06/15(木) 03:20:48.20

>>198
そもそもvectorのスマートポインタ (あるいはより一般的にサイズが動的なクラスのスマートポインタ) を作り、そのvectorやクラスのサイズを変えたときって確保されてる領域のサイズも変わるんでしたっけ？
手動で変えなきゃいけないと思っていました
(また、vectorのポインタとvectorの先頭要素のポインタは意味が違うのでよりわけが分からなくなりました)

2023/06/15(木) 06:50:20.05

std::vectorはshrink_to_fit()呼ばない限り勝手にcapacity縮めたりしないはずだけど

2023/06/15(木) 08:48:34.83

>>199
コンテナ内のポインタの予約は避けられないよ。

ただ、ポインタのサイズを気にするようなシビアな状況なら、そもそもc++じゃなくてcで実装することを検討すべき。

2023/06/15(木) 09:00:49.34

シビアな状況でC++が使えないやつがCならOKなはずはない

2023/06/15(木) 10:11:47.24

>>199
何が判ってないのかが判ってないパターンだな
まともな解答もらってても何が正しいのか(なぜ正しいのか)
すら判断出来なさそうなレベル
解答者に失礼

2023/06/15(木) 10:56:55.78

他所スレで同じ様な流れが

>742
質問の仕方が悪いだけwww
欲しい情報を引き出すには一定以上の質問能力が必要

>743
質問の仕方が重要なのはその通りだけど
ここで問題にしてるのは自分が詳しくない領域では質問の仕方が悪かったかどうかも分からないってことでしょうよ

>744
>>742
質問のしかたさえ良ければ正確な情報が手に入ると思ってるのは素人だけだぞ？w

2023/06/15(木) 12:02:49.40

>>201
いや、ポインタのサイズなんて全く気にしてない。
質問は、メモリの解放をコンテナに任せるならわざわざスマポで持つ意味ないよね？ってこと。
で、コンテナに任せるというのは元の質問(>>182)への回答に全くなってないよね？ってこと。
(その理由は>>184,200様の書いてくださってる通り)
つーかお前が何も分かってないのは>>195でreset()しなくて良いとかほざいてる時点でお察し。

>>203-204
笑
>>203は>>191で「reset()しなくても良い」とかほざいてて>>195と同レベ。

>>183-185,194,197,200様
ご丁寧な回答をくださりどうもありがとうございました。
勉強になります。

2023/06/15(木) 12:29:34.24

>>205
コンテナのsmart ptrの扱いは調べた？
コンテナの要素とポインタの参照先の違いについて根本的な誤解がありそう。

vectorはまだ構築していないインスタンス用のメモリ領域を予約するけど、smart ptrはそんなことしないよ。
vector<smart ptr>もsmart ptr の予約はするけど、smart ptrの参照先インスタンスの予約はしない。

2023/06/15(木) 13:15:56.80

>>206
だから、結局任意のコンテナ、クラスに対してスコープ内でメモリを解放する方法は？
new で生ポを持って delete するか、スマポを持って reset するかだろ？

> vectorはまだ構築していないインスタンス用のメモリ領域を予約するけど、smart ptrはそんなことしないよ。
そりゃそう。
ゆえに、メモリを間違いなくリリースしたいなら reset すればよいのですねと>>190で述べている。
それで終わりなのにお前と来たら reset は不要だの元のコンテナの挙動に任せるだの、論旨を全く理解してないとんでもレスばっかり。

> vector<smart ptr>も……
論外。
誰もスマポのvectorの話なんてしてねえ。

2023/06/15(木) 14:56:16.78

186でも言ってるがstaticもしくはvirtualでデストラクタ使えよ
それがシンプルで高速で1行も無駄のない設計な

2023/06/15(木) 15:01:28.21

182の
>最も簡単なやり方は関数とか局所的なスコープとして切り出すことかと思いますが
がコンストラクタで確保してデストラクタで消す話というのはわかってる上で

>他に、オブジェクトに割り当てられているメモリを手動で解放する方法があったら教えてください。
なんじゃないの？

そんなものは無いっていう答えもあるにはあるけどサ

2023/06/15(木) 18:41:07.51

最近IPP触り始めたんですが全部飽和演算で面食らってます
Modulo関数は無いんですか？

2023/06/15(木) 21:00:11.51

>>207
ああ、ごめん。めっちゃデカイインスタンスのvectorじゃなくて、めっちゃデカイvectorね。
それなら実装依存だけど>184か、>192とか参照無効化の制限とかコピーコストとかあるけど>189。189はsmart ptrにしとけば実用上問題ないかね。vectorのイテレーターは保存するものじゃないし。

2023/06/15(木) 21:28:08.23

実際の所、vectorならclear()→shrink_to_fit()でメモリが開放されないこってありうるの？

2023/06/15(木) 22:10:40.95

規格上はshrink_to_fit()にメモリ解放する義務はないし、実装定義で何やっても自由（capacityを増やすような真似だけは禁止）
shrink_to_fit()がなんにもしない実装でも一応規格準拠になる
そんな糞みたいな実装が実在するかは知らない

**デフォルトの名無しさん** (US 0H0b-q0yD) · 2023/06/16(金) 02:13:28.00

>>211
はい結局一人だけ違う話してた
ハァァ～～～～～（クソデカため息）

2023/06/16(金) 11:31:25.61

>>212
基本的には効率的に実装されるものだと信じて良いと思うが
どういう実装が効率的であるかは実行環境の事情による。

たとえばメモリ管理がページ単位というのは普通のことだし
その場合にページ単位より細かく確保したり解放したりしても非効率になる。

常に何もしないというような実装はあまりないと思うけど
解放するほうが非効率だと考えられる状況では
shrink_to_fit を呼んでも解放しなかったり部分的にだけ解放する
ということはそれなりにあり得そうだと思うよ。

2023/06/16(金) 12:08:14.46

capacityと OS側からみた空きメモリはまた別かもしれんわけで
アロケーターがOSからじかに要求してる場合もあれば
OSへの要求回数を減らして内部でプールしてやりくりしてるのもあるし
制御したいレイヤーによっては全部自前でやるしかない　という落ちにも

2023/06/16(金) 12:26:43.83

>>215
まぁ、細かい単位のメモリだったら、実際に開放されているかどうかなんて、ほとんど動作に影響しないとも言えるしね
（未初期化変数の不具合が発覚しづらい、くらいか）
とりあえずshrink_to_fitを呼んでおいて、細かいことは気にしないのが一番かもしれないw

2023/06/16(金) 12:46:08.57

「STLコンテナ以外にも」という文言が読めてない文盲さんたちがvectorの話ばっかしててワロ

2023/06/16(金) 15:41:25.79

「STLコンテナ以外にも」はSTLコンテナも含むということ
STLコンテナの話をしても何もおかしくない

2023/06/16(金) 15:43:23.81

いつものことだが
ほんの最初の数レスで終わってるのに
どうでも良い脱線ほど盛り上がってgdgdレスでスレが延びる

2023/06/16(金) 15:46:42.75

ほんそれ
回答終了してんのにちんこかゆい

**デフォルトの名無しさん** (ｽﾌｯ Sd33-pDI4) · 2023/06/16(金) 15:49:19.69

>>182 良く読むと
>STL コンテナ以外にも、大きいメモリが割り当てられてるオブジェクトを使用後に破棄したいというケースがよくあります。
>最も簡単なやり方は関数とか局所的なスコープとして切り出すことかと思いますが

いやいやそもそも「関数とか局所的なスコープ(つまりautoだろ？stackだろ？)で大きいメモリ確保しようなんて思うな」って話なんだよな

2023/06/16(金) 16:09:01.10

ローカルなvectorを置けばヒープ確保されるので「つまりautoだろ？stackだろ？」は
また何か誤解してる人が来たなとしか。

2023/06/16(金) 16:49:22.15

reset要らないとか言ってる奴らは結局何なん

2023/06/16(金) 19:32:47.80

>>224
結論は>211にまとめといた。
resetは要らん。

2023/06/17(土) 08:56:51.34

>>223
「STLコンテナ以外にも」という文言が読めてない文盲さんたちがvectorの話ばっかしててωωω

2023/06/17(土) 10:36:04.78

>>226
「大きいメモリが割り当てられてるオブジェクトを使用後に破棄したい」なら
>185か>187。
>187はunique ptrの置き場所と解放タイミングによって解放の仕方が違って、自動変数にして関数やスコープから抜けるタイミングで解放するなら手動操作不要、vectorなどのヒープに置くとかスコープの終わり前に解放したいとかならreset()とかvectorの要素削除とかで手動解放。

いずれにしても、自動変数に巨大インスタンスを考え無しに置くのは悪手で、そのオブジェクトがスタックに巨大データを置かない(ヒープ等に置く)ことを確認してからにしたほうがいい。

2023/06/17(土) 15:30:36.02

>>216
vectorのcapacityはそのvectorが氏ぬかcapacity縮小アクションが生じない限りvector固有に占有されるから
capacity（のうちsize()を超える分）と OS側からみた空きメモリはまた別でｹﾃｰｲ……
一方malloc()がOSからｹﾞｯﾄしたメモリをOSに返さずにいるのはOS側からみた空きメモリではないにしろ
同一プロセス内の他のオブジェクトの構築に使えるのだから空きメモリのうち
これすらもOSに返したいということならこの流れの中で現状答えがでていないｷﾓﾇ

2023/06/17(土) 15:31:34.82

まあしいて言えばプロセスを一旦exitして再立ち上げ？

2023/06/17(土) 15:45:09.56

普通に作ったら（コードで明示的に直接OSのAPIでメモリを分捕って解放とかしない限りは
プロセスのprivate bytesはプロセスが氏ぬまで増えることはあっても減ることは無いという印象、

2023/06/17(土) 16:27:35.20

>>225
スマンまじで理解できないのだけど、なぜvectorに限った話をしてるの？

2023/06/17(土) 19:22:00.09

>>231
巨大インスタンスは>227

2023/06/17(土) 19:29:36.10

回答者のレベル低いな～～～
こんだけダラダラ続けて、結局質問者>>182が>>190で早々に結論づけてることをリピートしてるだけｗ

2023/06/17(土) 19:54:50.95

アロケータ気に入らないなら自作くらいしろよポンコツ
なにもかもSTLに頼りやがってそれでPGやってるつもりになるなよ

2023/06/17(土) 20:19:47.36

人類には早すぎた話題また……

2023/06/17(土) 23:14:07.63

次世代の人は便利に使いこなしてるかより簡素になった仕組みを使うのだろう

2023/06/18(日) 03:00:55.26

>>231
コンテナの種類を問わない一般的な方法なんてものはないからじゃないですかね

2023/06/18(日) 21:04:45.70

以下のコードでaccumulateのとこでコンパイルエラーが起こります
何故か分かります?
#include <iostream>
#include <array>
#include <deque>
#include <exception>
#include <numeric>
using Vector = std::array <double, 3>;
using Vector_Container = std::deque <Vector>;
Vector &operator += (Vector &lhs, const Vector &rhs) {
const auto size {lhs.size ()};
if (size != rhs.size ()) throw std::runtime_error ("Sizes are different.");
for (size_t i {0}; i < size; ++ i) lhs [i] += rhs [i];
return lhs;
}
Vector operator + (const Vector &lhs, const Vector &rhs) {
Vector result {lhs};
result += rhs;
return result;
}
int main () {
Vector v0 {0, 1, 2}, v1 {10, 11, 12};
Vector_Container c0 {v0, v1};
accumulate (c0.begin (), c0.end (), Vector {}); // コンパイルエラー
return 0;
}

2023/06/18(日) 21:45:44.90

>>238 エラーメッセージ見ればたぶん分かる。

2023/06/18(日) 21:48:16.43

>>239
レス有難うございます
まず訂正
-accumulate
+std::accumulate
全部は貼れないですけど大事そうなところ

In file included from /usr/include/c++/12/numeric:62,
from test1.cpp:18:
/usr/include/c++/12/bits/stl_numeric.h: In instantiation of ‘constexpr _Tp std::accumulate(_InputIterator, _InputIterator, _Tp) [with _InputIterator = _Deque_iterator<array<double, 3>, array<double, 3>&, array<double, 3>*>; _Tp = array<double, 3>]’:
test1.cpp:22:14: required from here
/usr/include/c++/12/bits/stl_numeric.h:141:46: error: no match for ‘operator+’ (operand types are ‘std::remove_reference<std::array<double, 3>&>::type’ {aka ‘std::array<double, 3>’} and ‘std::array<double, 3>’)
141 | __init = _GLIBCXX_MOVE_IF_20(__init) + *__first;

2023/06/18(日) 23:15:51.41

ADLでoperator+が見つからないからかな?
struct Vector : std::array <double, 3> {};
みたいに定義したらいけるのでは

2023/06/18(日) 23:20:13.62

>>241
>struct Vector : std::array <double, 3> {};
>みたいに定義したらいけるのでは
通りますね
どういうこと?

2023/06/18(日) 23:24:52.33

std::accumulateが14行目で定義したoperator+を見つけれてないのが原因っぽい。

std::accumulateの第4引数に
[](const Vector& v1, const Vector& v2){ return v1+v2;}
を追加してやるとコンパイルは通る。

14行目のoperator+をstd名前空間に入れてやれば動くにゃ動くけど色々マズいので(調査する分にはいいけど)最終的な解答にはならないかな

2023/06/18(日) 23:29:04.68

>>242
たぶんC++コンパイラはoperator+の候補を検索するときに
Vector( = std::array<double, 3>)と同じ名前空間にあるものしか検索しない

Vectorのクラス定義そのものがグローバル名前空間にあるなら14行目のoperator+を見つけられるけど、
今はVectorの正体はstd::array<...>なのでstd名前空間しか検索しないんだと思う

2023/06/18(日) 23:39:19.50

>>243,244
なるほど解説頂きまして有難うございます
グローバルスコープはどっからでも見えて良さそうなものの
何でグローバルスコープの関数を探さないですかね?

2023/06/18(日) 23:48:03.44

独自のメンバ変数を持たないのなら継承してしまうのも手ではある(ただしコンストラクタやarrayを受け取るキャスト用コンストラクタとか書く必要が出ると思うけど)
ただ、そもそもカスタマイズしたり自分の用途に本当に使いやすいものを作りたいなら、ちゃんと自分で全部書いた方がいいと思うよ

2023/06/19(月) 00:42:02.49

>>245
std::accumlateの定義内からだと、その下の方（ユーザーコード）で定義されてるoperator+は見えてないので、グローバル名前空間の探索では見つからない

2023/06/19(月) 00:52:39.28

>>247
std::accumlateが定義されているnumericをincludeする前に
以下のようにグローバルスコープにプロトタイプを置いても
同じようにoperator+が見えてないとエラーが出ます
using Vector = std::array <double, 3>;
Vector operator + (const Vector &lhs, const Vector &rhs);
#include <numeric>

2023/06/19(月) 03:40:46.00

accumlateは関数テンプレートだから実体化される時点でoperator+が見えてりゃOKのはず
言われてる通りADLで対象外なのが問題

2023/06/19(月) 05:38:23.58

>>237
(スマート)ポインタで持って要らなくなったら明示的にリリースする方法はあらゆるコンテナに対して使えるよね？笑

2023/06/19(月) 08:48:03.43

>>250
>>223

2023/06/19(月) 09:20:16.57

>>249
有難うございます
グローバルスコープに定義した関数が見えないのは
どうしてなんでしょうかね?
それでは全然グローバルじゃないような気がするのですが
規格を決めるときに何か意図があったのでしょうかね?

2023/06/19(月) 10:39:37.41

そもそもが名前空間内(よその演算子と混ざらないように)にある演算子オーバーロードを、外部からでも引数が合えば使えるように(std::operator+(a, b)とか書かないでいいように)するためのルールらしいから
外部の演算子見に行くのは目的に合わんのじゃね

std名前空間内のarrayに外部から勝手に動作を追加しようとしてるんだから、あまりよろしくないやり方しようとしてると考えた方がいい
(だから>>246のように書いた、継承したら一応arrayではなくちゃんとVectorクラスに対する演算子だから通る)

2023/06/19(月) 11:53:54.08

>>253
>std名前空間内のarrayに外部から勝手に動作を追加しようとしてるんだから、
>あまりよろしくないやり方しようとしてると考えた方がいい
なるほど
たぶんこういう考え方なんでしょうね

2023/06/19(月) 12:20:34.90

つまりvector<int>を使いなさいということ

2023/06/19(月) 12:21:25.69

>>251
安価ミス

2023/06/20(火) 00:04:57.81

実引数依存の名前探索、Argument-Dependent Lookup (ADL)は、
Koenig lookup とも言う

「Cプログラミングの落とし穴」の著者、
Koenigが、C++ に入れる事を推奨した

ADLを知っているなら、かなりのプロと言える

2023/06/20(火) 00:18:46.72

勉強になります

2023/06/20(火) 02:12:24.83

演算子のオーバーロードなら、フレンド関数とか？

非メンバの演算子オーバーロード | Programming Place Plus　C++編【言語解説】　第３５章

https://programming-place.net/ppp/contents/cpp/language/035.html

2023/06/20(火) 10:05:39.77

状況を簡略化するとこう。

namespace ns {
struct foo {};
template <class T>
void bar(const T&) {
T() + T();
} };

ns::foo operator+(const ns::foo& x, const ns::foo& y) { return ns::foo(); }

int main() { bar(ns::foo()); }

ADL は「通常の探索に加えて」関連する名前空間も探索対象にするルールなのでグローバル名前空間も探索対象になるが、通常の探索では後ろで宣言 (定義) されているものは見つけることができない。この場合はエラーとして検出されるけど、可視な宣言と実際の定義の集合に食い違いは未定義という解釈でいいと思う。 (ちょっと自信はない……。)
だから順序を変えれば通る。

namespace ns {
struct foo{};
};

ns::foo operator+(const ns::foo& x, const ns::foo& y) { return ns::foo(); }

namespace ns {
template <class T>
void bar(const T&) {
T() + T();
} };

int main() { bar(ns::foo()); }

当然ながら std の (というかそれに限らず既存のライブラリの) 宣言の順序をどうこうするわけにもいかないので無理にカスタムしようとするのは筋が悪いということになる。

2023/06/20(火) 10:53:08.18

>>260
>だから順序を変えれば通る。
最近手元のg++を更新しまして10.2.1 -> 12.2.0になったんですが
前者のケースが通らなくなりまして疑問に思っていたところでした
10.2.1は寛容で両方とも通るけどC++的には後者のみ通るのが正しい?

2023/06/20(火) 11:41:30.21

>>261
前者はたぶん未定義かつ診断不要な状況なのでエラーを検出せずに通すのも正しい挙動で
プログラマがそういう状況を作ってしまうのが仕様に反する (というか結果が保証されない) という解釈になると思う。

2023/06/20(火) 13:36:04.44

なるほどー
有難うございます

**デフォルトの名無しさん** (JP 0H91-FhUT) · 2023/06/20(火) 21:39:35.82

template<typename Callback>
void func(Callback cb)
{
//cb(1); // A
//cb(1,2);// B
}

void f1(int){}
void f2(int,int){}

int main(){func(f1);}

AとBをコンパイル時に呼び分けたいんですけど
どのように記述すればよいか教えていただけませんか？

2023/06/20(火) 22:18:37.18

is_invocableでおｋ

2023/06/20(火) 22:21:49.81

>>264
渡されたコールバック関数の引数の数によって区別するってこと？
素朴な方法だとオーバーロードするのが手っ取り早いと思う。

void func(void (*cb)(int)) {
cb(1);
}

void func(void (*cb)(int, int)) {
cb(1, 2);
}

void f1(int) {}
void f2(int, int) {}

int main() {
func(f1);
func(f2);
}

2023/06/20(火) 22:27:55.14

>>264
template<typename Callback> void func(Callback cb);
template <> void func(void (*cb) (int))
{
(*cb)(1); // A
}
template <> void func(void (*cb) (int, int))
{
(*cb)(1,2);// B
}
void f1(int){}
void f2(int,int){}
int main(){func(f1);}

2023/06/20(火) 22:29:12.98

templateが意味ないね

2023/06/20(火) 22:39:00.27

265が言うようにis_invocable使うとこんな感じ？

template<typename Callback>
void func(Callback cb)
{
if constexpr (std::is_invocable_v<Callback, int>) {
cb(1);
} else if constexpr (std::is_invocable_v<Callback, int, int>) {
cb(1,2);
}
}

2023/06/20(火) 22:41:37.75

>>269
これって関係ないif節はコンパイル時に消えるの?

2023/06/20(火) 22:43:20.79

>>270
消えるよ。

**デフォルトの名無しさん** (JP 0H91-FhUT) · 2023/06/20(火) 22:44:14.18

>>269
ありがとうございます。
gcc 13.1.0 でc++17でうまくいきました。

後出しで申し訳ありませんが、C++14でかけませんか？

2023/06/20(火) 22:47:27.45

>>269,271
これは知らんかった
勉強になるなぁ

**デフォルトの名無しさん** (JP 0H91-FhUT) · 2023/06/20(火) 22:48:18.64

>>269
まさにこれをやりたかったです。

template<typename Callback>
void func(Callback cb)
{
// こことか

if constexpr (std::is_invocable_v<Callback, int>) {
cb(1);
} else if constexpr (std::is_invocable_v<Callback, int, int>) {
cb(1,2);
}

// ここをどうしようか悩んでいました
}

2023/06/20(火) 22:59:00.24

>>272, >>274
ひとつの関数テンプレート中でやりたいってこと？
if constexpr が導入される前だとオーバーロードなり特殊化なりで
別の関数として分離しないと書けないと思う。

is_invocable に相当するものは自分で書こうと思えば書けるが
if constexpr は言語のコアの機能だからどうにもならんし……。

**デフォルトの名無しさん** (JP 0H91-FhUT) · 2023/06/20(火) 23:14:31.48

>>275
情報ありがとうございます

ご掲示いただいたコードで勉強になりました。

2023/06/20(火) 23:42:05.71

>>273
ザッツcostexprマジック

2023/06/20(火) 23:43:57.61

n抜けてたwコストがかかる演算なのは確かだけどw
constexprマジック！マジック！

2023/06/21(水) 00:07:10.76

C++11のSFIANE地獄へようこそ
https://wandbox.org/permlink/2sfUVeEBrErqvI2R

template関数の実体化が1つだけ成功して、
他が失敗するように仕掛ければ呼び分けは可能。

ただ見ての通り相当面倒なことを書かなきゃならない。

2023/06/21(水) 00:28:02.40

>>279
>>266と本質的に何が違うのか分からない
解説よろしく
（templateでやってることは無駄なのでは?）

2023/06/21(水) 00:41:42.51

>>280
いや、 >>279 のほうがちょっと柔軟で使いやすい。
たとえば

void f3(long int, long int) {}

みたいなのを渡したとき >>266 ではエラーになる。
引数として int を渡せる (int から暗黙に変換可能な仮引数を持っている) というのと
厳密に int そのものでなければならないというのとでは制約の厳しさが違う。

2023/06/21(水) 00:42:09.27

templateでやるのは質問者の与えた要件だな
宿題なんじゃね、しらんけど