Should this be considered a bug in clang 3.8? Yep. A capture is only needed if [expr.prim.lambda]/12 mandates so: Note in particular the highlighted example. f(x) does not necessitate x to be captured, because it isn’t odr-used (overload resolution selects the overload with the object parameter). The same argumentation applies to your code – [basic.def.odr]/3: … Read more
As a possible drawback, note that passing by copy could not work if the lambda isn’t copyable. If you can get away with it, passing by copy is just fine. As an example: #include<memory> #include<utility> template<typename F> void g(F &&f) { std::forward<F>(f)(); } template<typename F> void h(F f) { f(); } int main() { auto … Read more
The official name is not universal reference, but forwarding reference. The Standard states that only rvalue references to cv-unqualified template parameters fall in this category: 14.8.2.1 Deducing template arguments from a function call [temp.deduct.call] 3 If P is a cv-qualified type, the top level cv-qualifiers of P’s type are ignored for type deduction. If P … Read more
In c++17, with the addition of auto in template arguments (P0127), I think you can now do: template<auto value> struct MyStruct {}; template<typename Class, typename Result, Result Class::* value> struct MyStruct<value> { // add members using Class, Result, and value here using containing_type = Class; }; typename MyStruct<&Something::theotherthing>::containing_type x = Something();
The rule for this situation changed between 2011 and 2014. The compiler should now treat localB as an rvalue. The applicable rule for return statements is found in §12.8 [class.copy]/p32, which reads in C++14 (quoting N3936, emphasis mine): When the criteria for elision of a copy/move operation are met, but not for an exception-declaration, and … Read more
It could be constexpr, but cannot be evaluated as a constant expression, since in this case, for example for compile-time find it is required that: begin/end should be constexpr, the * operator of the iterator should be constexpr, operator == should be constexpr, operator != for the iterator should be constexpr, operator ++ for the … Read more
The rationale that you included is reasonably clear: naturally, virtual functions are meant to be overridden by subclasses, so you as the designer of the base class should make it as easy as possible for people who inherit your class to provide a suitable override. However, if you use auto, figuring out the return type … Read more
Ok, it is indeed an oversight in the standard. There even exists a proposal to fix this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0107r0.pdf [N3598] removed the implicit marking of constexpr member functions as const. However, the member functions of std::array were not revisited after this change, leading to a surprising lack of support for constexpr in std::array’s interface. This paper … Read more
Reading the C++17 draft §3.6.1/2: … and it shall have a declared return type of type int, … So yes I would say it’s forbidden to use deduction. Almost the exact same wording in the last C++14 draft (same section as the C++17 draft): It shall have a declared return type of type int, … … Read more
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior… That being said, the reason why this warning does not appear when using std::unique_ptr is most likely due to the fact that … Read more