Re: [boost] N2346 - Defaulted and Deleted Functions emulation

Subject: Re: [boost] N2346 - Defaulted and Deleted Functions emulation
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-03-01 15:28:17

----- Original Message ----- 
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>
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_at_[hidden]> 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