Re: [C++0x]: non-public defaulted copy c-tor
2009/11/26 Piotr Wyderski:
Clean, simple and GCC used to happily accept that.
Only with the experimental C++0x mode, which is a moving target and
you shouldn't really complain if it changes.
But now it is illegal because of 3 draft violations:
Base() shall be public, but is not
~Base() shall be public, but is not
~Base() shall not be virtual, but it is
IMHO this severely cripples defaulted functions,
making them almost useless -- the set of allowed
cases is too narrow. Is there any chance to fix the DR?
It's under discussion, but relax, notice it says If it is explicitly
defaulted on its first declaration,
Have you tried:
class Base {
protected:
Base();
virtual ~Base();
};
inline Base::Base() = default;
inline Base::~Base() = default;
This still lets you use defaulted functions, but the base is not
trivially copyable. (I haven't tested this with GCC, but I believe it
should work.)
Re: [C++0x]: non-public defaulted copy c-tor
2009/11/26 Jonathan Wakely: This still lets you use defaulted functions, but the base is not trivially copyable. Oops, I meant the base is not a trivial class ... but then it can't be anyway as you have a virtual function.
Re: [C++0x]: non-public defaulted copy c-tor
Jonathan Wakely wrote:
It's under discussion
That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:
a) = default works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports so many ICEs it is almost
useless;
c) it seems to have problems with overload resolution.
I wanted lambdas, but it can wait -- the top of my
wish list, i.e. constructor inheritance/delegation is
not implemented yet anyway.
but relax, notice it says If it is explicitly
defaulted on its first declaration,
[...]
inline Base::Base() = default;
inline Base::~Base() = default;
Of course, I tried that and it works to some
extent, as on 20090604 defaulted virtual
destructors are not DLL-exported for some
reasons, but their {} counterparts are).
The point is that the only reason to have
defaulted functions is to provide comprehensive
syntax for obvious things. However:
inline Base::Base() {};
inline Base::~Base() {};
is even shorter than the defaulted version, not to mention:
class Base {
protected:
Base() {};
virtual ~Base() {};
};
which is the reason I dare to say the crippled version is useless.
What is the point of doing simple things in a complex way?
Best regards
Piotr Wyderski
[C++0x]: non-public defaulted copy c-tor
After upgrade to trunk-20091124:
class C {
protected:
C(const C) = default;
};
main.cpp:1506:23: error: 'C::C(const C)' declared with non-public access cannot
be defaulted in the class body
But I can't find anything about it in the N3000 draft.
Should I file a GCC bug report or adjust my code?
Best regards
Piotr Wyderski
Re: [C++0x]: non-public defaulted copy c-tor
2009/11/25 Piotr Wyderski:
After upgrade to trunk-20091124:
class C {
protected:
C(const C) = default;
};
main.cpp:1506:23: error: 'C::C(const C)' declared with non-public access
cannot
be defaulted in the class body
But I can't find anything about it in the N3000 draft.
Should I file a GCC bug report or adjust my code?
This is DR906
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906
Note it shall be public
Re: [C++0x]: non-public defaulted copy c-tor
Jonathan Wakely wrote:
This is DR906
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906
Thanks.
Note it shall be public
And what's the reason for such restrictions?
I've used the following construction as a very
useful idiom to create an abstract class:
class Base {
protected:
Base() = default;
virtual ~Base() = default;
};
class Derived : public Base {
public:
Derived() { ... }
virtual ~Derived() { ... }
};
Clean, simple and GCC used to happily accept that.
But now it is illegal because of 3 draft violations:
Base() shall be public, but is not
~Base() shall be public, but is not
~Base() shall not be virtual, but it is
IMHO this severely cripples defaulted functions,
making them almost useless -- the set of allowed
cases is too narrow. Is there any chance to fix the DR?
Best regards
Piotr Wyderski
