Re: move/copy constructors, variadic constructors, and private inheritance, is this a compiler bug?
Am 12.07.2013 10:11, schrieb fmatthew5876:
{ Please include the code in question in your article instead of
linking to it -mod }
I'm designing an allocator interface and came across a strange bug in
C++11
http://bit.ly/156Uahn
This code fails to compile on both gcc 4.7.1 and clang 3.2.
If I comment out the
template <typename... Args>
Allocator(Args&&... args) : A(std::forward<Args>(args)...) {}
constructor it compiles just fine.
Shouldn't the compiler choose Allocator(const Allocator&) and
Allocator(Allocator&&) over the more generic variadic one?
Only if the matches are deemed equally good non-templates will be
prefered. You ran into a situation where the template gives a perfect
match while the other constructors don't. You can further reduce the
example to:
struct base {};
struct derived : base {};
template<class T>
void foo(T&&); // #1
void foo(base const&); // #2
void foo(base &&); // #3
int main() {
derived const x = {};
base const y = {};
base z = {};
foo(x); // #1 with T=const derived& (the only perfect match)
foo(y); // #2 template vs non-template tie breaking rule
foo(z); // #1 with T=derived& (the only perfect match)
}
In all cases the template would be the perfect match, but only in the
second case #2 is a perfect match which is then preferred because it's
not a template.
Is this the correct behavior or a compiler bug?
Correct behaviour.
If this behavior is correct, how can I forward the move/copy
constructors correctly while still retaining the variadic one?
Easy fix in your case:
template <typename T, typename ALLOC = DefaultAllocator>
class Container : private ALLOC {
public:
Container();
Container(const Container<T,ALLOC>& c)
: ALLOC(static_cast<const ALLOC&>(c))
{}
Container(Container<T,ALLOC>&& c)
: ALLOC(static_cast<ALLOC&&>(c))
{}
};
But I would prefer to fix the base class in that the base class' perfect
forwarding constructor is properly constrained or alternativly augmented
with a tag:
enum forwarding_ctor_tag { forwarding_ctor };
:::
template <typename... Args>
Allocator(forwarding_ctor_tag, Args&&... args)
: A(std::forward<Args>(args)...) {}
:::
so that you have to specifically request this constructor via
"forwarding_ctor" as its first argument.
If you go for constraining, you could do it like this:
:::
template <class Arg1, class...Args
,class=typename std::enable_if<
!std::is_convertible<Arg1,const Allocator&>::value
>::type
>
Allocator(Arg1&& a1, Args&&... args)
:::
I did not test this, but I think it should work and disable the
constructor from being considered if the first argument could be used to
initialze the copy constructor's parameter. The trick is an anonymous
default template parameter which can only be determined if the condition
within enable_if is met. In other cases, this template will be silently
ignored (SFINAE). Since there is no return type for a constructor and
the constructor is variadic, I see no other way of exploiting the SFINAE
rule.
If possible, prefer the tagged constructor version. It comes with less
surprizes and does not require this kind of heavy meta-lifting.
Sometimes things should not be overloaded. This tag is kind of a way to
give a constructor a special name.
Cheers!
Sebastian
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]