A polymorphic_allocator is intended to let you have an allocator whose behavior is dynamically determined at runtime. The only way to create a polymorphic_allocator is: Default constructed, in which case it uses std::pmr::get_default_resource() return value, which is a memory_resource*. Pass it a memory_resource*. copy from another polymorphic_allocator. So the point of customization for a polymorphic_allocator … Read more
There’s a proposal on the issue titled Forward declarations of nested classes P0289R0. However as you can see from the last Trip Report: C++ Standards Meeting in Jacksonville, February 2016, this proposal was pendent to proposals for which further work is encouraged. I’m quoting the verdict of the committee (Emphasis Mine): This would allow things … Read more
To me it sounds like someone messed up merging the previous standard with the new one. Previously the standard said this: (C++14 N4140, 7.1.6.4.7 [dcl.spec.auto]): When a […] return statement occurs in a function declared with a return type that contains a placeholder type, the deduced return type or variable type is determined from the … Read more
boost::variant will heap allocate in order to have part of itself be recursively defined as itself. (It will also heap allocate in a number of other situations, uncertain how many) std::variant will not. std::variant refuses to heap allocate. There is no way to actually have a structure containing a possible variant of itself without a … Read more
One example of the difference is when you want (for whatever reason) to make an optional containing an optional: #include <optional> #include <type_traits> int main() { auto inner=std::make_optional(325); auto opt2=std::make_optional(inner); // makes std::optional<std::optional<int>> auto opt3=std::optional(inner); // just a copy of inner static_assert(std::is_same_v<decltype(opt2), std::optional<std::optional<int>>>); static_assert(std::is_same_v<decltype(opt3), std::optional<int>>); }
I sent an email to the C++ committee, specifically the Core working group, and provided the above example. CoryKramer It is currently unclear from the standard if attributes applied to virtual functions are inherited. Response: They are not. For them to be inherited, the Standard would have to explicitly say so, and it does not. … Read more
Recursive property of the mutex operates with the term “owner“, which in case of a shared_mutex is not well-defined: several threads may have .lock_shared() called at the same time. Assuming “owner” to be a thread which calls .lock() (not .lock_shared()!), an implementation of the recursive shared mutex can be simply derived from shared_mutex: class shared_recursive_mutex: … Read more
Edit: I actually dig your std::disjunction idea, and it absolutely works. You just have to extract the type list using template specialization. My entire old-school recursive mess becomes simply: template<typename T, typename VARIANT_T> struct isVariantMember; template<typename T, typename… ALL_T> struct isVariantMember<T, std::variant<ALL_T…>> : public std::disjunction<std::is_same<T, ALL_T>…> {}; Original answer: Here’s a simple template that accomplishes … Read more
Magic Enum header-only library provides static reflection for enums (to string, from string, iteration) for C++17. #include <magic_enum.hpp> enum Color { RED = 2, BLUE = 4, GREEN = 8 }; Color color = Color::RED; auto color_name = magic_enum::enum_name(color); // color_name -> “RED” std::string color_name{“GREEN”}; auto color = magic_enum::enum_cast<Color>(color_name) if (color.has_value()) { // color.value() -> … Read more
The short answer is that the element access functions (essentially the operations required by the algorithms on the various arguments; see below for details) used with algorithms using the execution policy std::execution::parallel are not allowed to cause data races or dead-locks. The element access functions used with algorithms using the execution policy std::execution::parallel_unsequenced_policy additionally can’t … Read more