«

Hi!

In the following C++0x code I tried to clone an object by using a
clone member function (if it exists) and falling back on a copy
constructor:

#include <type_traits>

struct use_copy_ctor {};
struct prefer_clone_func : use_copy_ctor {};

template<class T>
auto clone(T const* ptr, prefer_clone_func)
-> decltype(ptr->clone())
{ return ptr->clone(); }

template<class T>
auto clone(T const* ptr, use_copy_ctor)
-> decltype(new T(*ptr))
{ return new T(*ptr); }

struct abc {
virtual ~abc() {}
virtual abc* clone() const =0;
};

struct derived : abc
{
derived* clone() const { return new derived(*this); }
};

int main()
{
derived d;
abc* p = &d;
abc* q = clone(p,prefer_clone_func());
delete q;
}

The idea is to use auto...->decltype(expr) to weed out ill-formed
expressions as part of the template argument deduction (SFINAE) and to
resolve a possible ambiguity between both clone function templates via
partial ordering w.r.t. the second function parameter.

Unfortunately, GCC 4.5.1 doesn't accept this program:

test.cpp: In function 'int main()':
test.cpp:30:39: error: cannot allocate an object of abstract type
'abc'
test.cpp:16:12: note: because the following virtual functions are
pure within 'abc':
test.cpp:18:16: note: virtual abc* abc::clone() const
test.cpp:30:39: error: cannot allocate an object of abstract type
'abc'
test.cpp:16:12: note: since type 'abc' has pure virtual functions

Now, the question is, is this a compiler bug or was I wrong to assume
that SFINAE applies here?

Cheers!
SG

On 28 Jan., 11:36, SG wrote:
>
> In the following C++0x code I tried to clone an object by using a
> clone member function (if it exists) and fall back on a copy
> constructor:
>
> [...]
>
> Unfortunately, GCC 4.5.1 doesn't accept this program:
>
> [...]
>
> Now, the question is, is this a compiler bug or was I wrong to assume
> that SFINAE applies here?

I convinced myself that this is another case where GCC ignores the
"NAE" in SFINAE in combination with templates and decltype and filed a
bug report:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47513

Cheers!
SG

SG wrote:

> In the following C++0x code I tried to clone an object by using a
> clone member function (if it exists) and falling back on a copy
> constructor:
>
> #include <type_traits>

What for?

> struct use_copy_ctor {};
> struct prefer_clone_func : use_copy_ctor {};
>
> template<class T>
> auto clone(T const* ptr, prefer_clone_func)
> -> decltype(ptr->clone())
> { return ptr->clone(); }
>
> template<class T>
> auto clone(T const* ptr, use_copy_ctor)
> -> decltype(new T(*ptr))
> { return new T(*ptr); }
>
> struct abc {
> virtual ~abc() {}
> virtual abc* clone() const =0;
> };
>
> struct derived : abc
> {
> derived* clone() const { return new derived(*this); }
> };
>
> int main()
> {
> derived d;
> abc* p = &d;
> abc* q = clone(p,prefer_clone_func());
> delete q;
> }
>
> The idea is to use auto...->decltype(expr) to weed out ill-formed
> expressions as part of the template argument deduction (SFINAE) and to
> resolve a possible ambiguity between both clone function templates via
> partial ordering w.r.t. the second function parameter.
>
> Unfortunately, GCC 4.5.1 doesn't accept this program:

clang++ accepts it. It gained a lot of C++0x features last week, now
it is just missing a library so we can start playing with it... (it
can't handle the C++0x parts of libstdc++ and libc++ only works on
Mac)

On 28 Jan., 15:39, Marc wrote:
> SG *wrote:
> > In the following C++0x code I tried to clone an object by using a
> > clone member function (if it exists) and falling back on a copy
> > constructor:
>
> > * *#include <type_traits>
>
> What for?

Nothing, actually. It's a relict from previous versions. I removed
this line before submitting the bug report. Initially, I used
enable_if in combination with is_constructible<T,T const&>::value but
libstdc++'s current implementation of is_constructible also "chokes"
on abstract class types. I guess this is due to the same SFINAE<-
>decltype issue I ran into (assuming is_constructible was implemented
in terms of SFINAE+decltype).

> clang++ accepts it. It gained a lot of C++0x features last week,

Great!

> now it is just missing a library so we can start playing with it...
> (it can't handle the C++0x parts of libstdc++
> and libc++ only works on Mac)

Huh. I wouldn't have expected that.

Cheers!
SG

On Jan 28, 5:36*am, SG <s.gesem...@gmail.com> wrote:
> Hi!
>
> In the following C++0x code I tried to clone an object by using a
> clone member function (if it exists) and falling back on a copy
> constructor:
>
> * *#include <type_traits>
>
> * *struct use_copy_ctor {};
> * *struct prefer_clone_func : use_copy_ctor {};
>
> * *template<class T>
> * *auto clone(T const* ptr, prefer_clone_func)
> * *-> decltype(ptr->clone())
> * *{ return ptr->clone(); }
>
> * *template<class T>
> * *auto clone(T const* ptr, use_copy_ctor)
> * *-> decltype(new T(*ptr))
> * *{ return new T(*ptr); }
>
> * *struct abc {
> * * *virtual ~abc() {}
> * * *virtual abc* clone() const =0;
> * *};
>
> * *struct derived : abc
> * *{
> * * *derived* clone() const { return new derived(*this); }
> * *};
>
> * *int main()
> * *{
> * * *derived d;
> * * *abc* p = &d;
> * * *abc* q = clone(p,prefer_clone_func());
> * * *delete q;
> * *}
>
> The idea is to use auto...->decltype(expr) to weed out ill-formed
> expressions as part of the template argument deduction (SFINAE) and to
> resolve a possible ambiguity between both clone function templates via
> partial ordering w.r.t. the second function parameter.
>
> Unfortunately, GCC 4.5.1 doesn't accept this program:
>
> test.cpp: In function 'int main()':
> test.cpp:30:39: error: cannot allocate an object of abstract type
> 'abc'
> test.cpp:16:12: note: * because the following virtual functions are
> pure within 'abc':
> test.cpp:18:16: note: * * * *virtual abc* abc::clone() const
> test.cpp:30:39: error: cannot allocate an object of abstract type
> 'abc'
> test.cpp:16:12: note: * since type 'abc' has pure virtual functions
>
> Now, the question is, is this a compiler bug or was I wrong to assume
> that SFINAE applies here?
>
> Cheers!
> SG

VC++ 2010 fails with a *linker* error:

error LNK2019: unresolved external symbol "public: __thiscall
abc::abc(void)" (??0abc@@QAE@XZ) referenced in function "public:
__thiscall derived::derived(void)" (??0derived@@QAE@XZ)

On 28 Jan., 20:19, Dilip wrote:
> On Jan 28, 5:36*am, SG wrote:
>
> > * *struct use_copy_ctor {};
> > * *struct prefer_clone_func : use_copy_ctor {};
> >
> > * *template<class T>
> > * *auto clone(T const* ptr, prefer_clone_func)
> > * *-> decltype(ptr->clone())
> > * *{ return ptr->clone(); }
> >
> > * *template<class T>
> > * *auto clone(T const* ptr, use_copy_ctor)
> > * *-> decltype(new T(*ptr))
> > * *{ return new T(*ptr); }
> >
> > * *struct abc {
> > * * *virtual ~abc() {}
> > * * *virtual abc* clone() const =0;
> > * *};
> >
> > * *struct derived : abc
> > * *{
> > * * *derived* clone() const { return new derived(*this); }
> > * *};
> >
> > * *int main()
> > * *{
> > * * *derived d;
> > * * *abc* p = &d;
> > * * *abc* q = clone(p,prefer_clone_func());
> > * * *delete q;
> > * *}
>
> VC++ 2010 fails with a *linker* error:
>
> error LNK2019: unresolved external symbol "public: __thiscall
> abc::abc(void)" (??0abc@@QAE@XZ) referenced in function "public:
> __thiscall derived::derived(void)" (??0derived@@QAE@XZ)

That's weird. Looks like VC++ forgot to emit the definition of the
"compiler-generated" default constructor of abc.