問題タブ [c++20]

で再帰マクロを書くことは合法__VA_OPT__ですか?

GCC と Clang は再帰的に置き換えられないように見えますが、それが意図的なものかどうかはわかりません (__VA_OPT__サポートはごく最近のことです)。

C++ 仕様 (§19.3.1/3: __VA_OPT__):

それ以外の場合、置換は、再スキャンとさらなる置換の前に、現在の関数のようなマクロの置換リストとしてのコンテンツの展開の結果で構成されます

上記の強調表示されたセクションは、再帰が不可能であることを意味しますか?

たとえば、可変長マクロ パラメーターのリストを追加するには、次のようにします。

GCC と Clang はどちらもRECURSE、後処理で生成されます。

注: これが可能であれば、連結などのより複雑な可変個引数マクロをかなり簡単に記述できます。これは、カスタム__VA_NO_OPT__fromを作成できるため__VA_OPT__です。これにより、1 および 2+ パラメータに対して完全に別個のコードを提供できます。

c++17にはアルゴリズムのインデックスベースの並列がないため、それをエミュレートするために と組み合わせて使用​​できるかどうか疑問に思っています。あれは：ranges::view::iotastd::for_each

iota_view適切なタイプ（ [range.iota.iterator] ）のランダムアクセスを提供しているようです：

iota_view<I, Bound>::iterator::iterator_categoryは次のように定義されます。

(1.1) —IモデルAdvanceableの場合、iterator_categoryは ですrandom_access_iterator_tag。

(1.2) — そうではなく、ImodelsDecrementableの場合iterator_categoryは ですbidirectional_iterator_tag。

(1.3) — それ以外の場合、ImodelsIncrementableの場合iterator_categoryは ですforward_iterator_tag。

(1.4) — それ以外の場合iterator_categoryは ですinput_iterator_tag。

上記のコードは正しいですか？iota_viewこの方法を使用すると、パフォーマンスが低下することはありますか?

編集: range-v3、cmcstl2、および Intel のPSTLでいくつかのテストを行いました。

range-v3 を使用すると、上記の例は GCC 8 でのコンパイルに失敗しbeginますend。

cmcstl2 を使用すると、コードはきれいにコンパイルされますが、並列には実行されません。おそらくフォワードイテレータの要件が何らかの形で満たされていないため、順次バージョンにフォールバックしているように思えます( https://godbolt.org/z/yvr-M2 )。

多少関連する PSTL の問題があります ( https://github.com/intel/parallelstl/issues/22 )。

std::default_delete を使用する代わりにカスタムの destroy-function を呼び出すことでstd::unique_ptr、 s が破棄する必要のある型を簡単に管理できるように特化することができます。delete p;

オブジェクトがstd::shared_ptrC++ でa によって管理されていることを確認するには、基本的に 2 つの方法があります。

1. std::make_sharedまたはを使用して、共有ポインタによって管理されるように作成しますstd::allocate_shared。これは、必要な両方のメモリ ブロック (ペイロードと参照カウント) を 1 つに結合するため、推奨される方法です。sしか残っていない場合std::weak_ptrでも、参照カウントが必要なため、必然的にペイロード用のメモリも固定されます。

2. その後、コンストラクターまたはを使用して、管理を共有ポインターに割り当てます.reset()。

2 番目のケースは、カスタムのデリータを提供しない場合に興味深いものです。

具体的には、配列に対してインスタンス化されているかどうかに応じて、delete [] p;またはをそれぞれ使用する、指定されていないタイプの独自のデリータを使用するように定義されています。delete p;std::shared_ptr

n4659 からの引用 (~C++17):

4 Requires:Y完全型でなければならない。式が配列型のdelete[] p場合T、または が配列型でないdelete p場合、T式は明確に定義された動作をし、例外をスローしません。
5 効果:Tが配列型でない場合shared_ptr、ポインタを所有するオブジェクトを構築しますp。それ以外の場合は、shared_ptrを所有するpと、 を呼び出す未指定の型の削除子を構築しますdelete[] p。が配列型でない場合T、 で有効shared_from_thisになりpます。例外がスローされた場合、が配列型でないdelete p場合に呼び出され、それ以外の場合に呼び出されます。 6 事後条件: . […]Tdelete[] p
use_count() == 1 && get() == p

3つの効果： と同等shared_ptr(p).swap(*this)。

私の質問は次のとおりです。

1. std::default_delete代わりに使用するように指定されていない、できれば正当な理由はありますか?
2. 有効な (そして潜在的に有用な) コードは、その変更によって壊れますか?
3. そうする提案はすでにありますか？

だから私はコンセプトを持っていますFooable:

Barそして、型をテンプレート パラメーターとして受け取るクラス テンプレートがあり、次の場合にTのみメンバー関数を有効にしたい:TFooable

概念TSまたはC++2aを備えたC++17で可能ですか?