N2346 - Defaulted and Deleted Functions emulation
Hi, is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks. Attached a draft for the default and deleted functions. Only one remark the macors must be used on the public part and without trailing ';', e.g. class X { BOOST_NEW_DELETE(X) Any coments are welcome, Vicente
On Thu, Nov 20, 2008 at 10:49 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks.
Attached a draft for the default and deleted functions.
Only one remark the macors must be used on the public part and without trailing ';', e.g.
class X { BOOST_NEW_DELETE(X)
My concern is that: #define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) inline T(){}; emulates the syntax but not the semantics of #define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) T()=default; The point of using the C++0x T()=default syntax is probably to ensure that the class is a POD. In C++03, the class designer has to make a design tradeoff. If providing a default constructor is more important than making the class a POD, then your emulation is OK. But if the priorities are the other way around, then the macro should just eliminate the default constructor. I'm concerned about hiding that semantic difference inside a macro. --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: <boost@lists.boost.org> Sent: Sunday, March 01, 2009 4:34 PM Subject: Re: [boost] N2346 - Defaulted and Deleted Functions emulation On Thu, Nov 20, 2008 at 10:49 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks.
Attached a draft for the default and deleted functions.
Only one remark the macors must be used on the public part and without trailing ';', e.g.
class X { BOOST_NEW_DELETE(X)
My concern is that: #define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) inline T(){}; emulates the syntax but not the semantics of #define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) T()=default; The point of using the C++0x T()=default syntax is probably to ensure that the class is a POD. In C++03, the class designer has to make a design tradeoff. If providing a default constructor is more important than making the class a POD, then your emulation is OK. But if the priorities are the other way around, then the macro should just eliminate the default constructor. I'm concerned about hiding that semantic difference inside a macro. --Beman _______________________________________________ Hi, if at least the deleted macros works we can start with them, and let the defaulted macros until someone find something else. Vicente
On Sun, Mar 1, 2009 at 3:28 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
...
if at least the deleted macros works we can start with them, and let the defaulted macros until someone find something else.
Makes sense. Do you plan to put such a little utility submission together? Docs, tests, examples, whatever? --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: <boost@lists.boost.org> Sent: Monday, March 02, 2009 2:57 PM Subject: Re: [boost] N2346 - Defaulted and Deleted Functions emulation On Sun, Mar 1, 2009 at 3:28 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
...
if at least the deleted macros works we can start with them, and let the defaulted macros until someone find something else.
Makes sense.
Do you plan to put such a little utility submission together? Docs, tests, examples, whatever?
Hi, I can do a quikdock, and some basic tests. BTW way on which directory this coudl be included, config? Best, Vicente
on Sun Mar 01 2009, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
My concern is that:
#define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) inline T(){};
emulates the syntax but not the semantics of
#define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) T()=default;
The point of using the C++0x T()=default syntax is probably to ensure that the class is a POD.
In C++03, the class designer has to make a design tradeoff. If providing a default constructor is more important than making the class a POD, then your emulation is OK. But if the priorities are the other way around, then the macro should just eliminate the default constructor.
Really the only likely use is to ensure POD-ness, because after all "{}" is a lot easier to type and read than "=default;" One thing we could do in the macro is to BOOST_MPL_ASSERT((boost::is_pod<T>)) Of course, if you know enough about your implementation you can specialize boost::is_pod<YourType> (with the usual caveats if you get it wrong). I'm not sure it'd be worth it though. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Monday, March 02, 2009 3:18 PM Subject: Re: [boost] N2346 - Defaulted and Deleted Functions emulation
on Sun Mar 01 2009, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
My concern is that:
#define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) inline T(){};
emulates the syntax but not the semantics of
#define BOOST_DEFAULT_CONSTRUCTOR_DEFAULT(T) T()=default;
The point of using the C++0x T()=default syntax is probably to ensure that the class is a POD.
In C++03, the class designer has to make a design tradeoff. If providing a default constructor is more important than making the class a POD, then your emulation is OK. But if the priorities are the other way around, then the macro should just eliminate the default constructor.
Really the only likely use is to ensure POD-ness, because after all "{}" is a lot easier to type and read than "=default;"
One thing we could do in the macro is to
BOOST_MPL_ASSERT((boost::is_pod<T>))
Of course, if you know enough about your implementation you can specialize boost::is_pod<YourType> (with the usual caveats if you get it wrong).
I'm not sure it'd be worth it though.
You are right these are little things that the developer could do by himself. I'll however try to introduce yous improvements. Thanks, Vicente
participants (3)
-
Beman Dawes -
David Abrahams -
vicente.botet