Re: [boost] Re: Re: Re: partial<> proposal
Sorry for confusion, the reply below obviously belongs to a different thread. Aleksey Gurtovoy wrote: > Andreas Huber wrote: > > P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on > > conforming compilers I'd expect it to "call" mpl::identity) or should I > > #ifdef my way around it? > > Yep, it's intentionally written in the way so that you don't have to #ifdef > in your code. > > Aleksey > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
Andreas Huber wrote: > P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on > conforming compilers I'd expect it to "call" mpl::identity) or should I > #ifdef my way around it? Yep, it's intentionally written in the way so that you don't have to #ifdef in your code. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
"Fernando Cacciola \(Home\)" <[EMAIL PROTECTED]> writes: > optional opt( in_place(point(0,0),point(10,10))); > > here, in_place() is used to forward T's ctor argument to optional<> so that > T is effectively constructed in-place right within the aligned storage. > > Is this what you want? I have to say that I like the idea of using placement-new with an optional<> argument better, since it doesn't get you involved with the const ref/non-const ref/rvalue forwarding problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
- Original Message - From: "Philippe A. Bouchard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 4:29 PM Subject: [boost] Re: Re: Re: partial<> proposal > David Abrahams wrote: > > [...] > > >> Example: > >> optional i; > >> > >> new (i) int(17); > > > > Which copy ctor are you referring to? > > And why do we want to prevent copy ctor usages? > > Because optional<> will be able to handle types without copy constructors > (this was the main purpose of partial<> in fact). I was referring to the > copy constructor of optional<>'s template parameter. > I'm still not sure I understand what are you trying to do, but it looks like you want optional with in-place construction (which bypasses the copy). In this case, I recently explored something which would look like: optional opt( in_place(point(0,0),point(10,10))); here, in_place() is used to forward T's ctor argument to optional<> so that T is effectively constructed in-place right within the aligned storage. Is this what you want? Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > > [...] > >>> Example: >>> optional i; >>> >>> new (i) int(17); >> >> Which copy ctor are you referring to? >> And why do we want to prevent copy ctor usages? > > Because optional<> will be able to handle types without copy constructors > (this was the main purpose of partial<> in fact). I was referring to the > copy constructor of optional<>'s template parameter. I understand now, thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > Yes, exactly. Sorry if I wasn't precise enough. > > The bool type will cancel type_with_alignment<> effects (at least on Intel > compatible platforms); i.e. unique alignment of each optional type. Sounds like you want type_with_alignment::type storage; new ((void*)&storage) T(x, y, z) Can you really do anything to make this cleaner? I guess: aligned_storage storage; new (storage.bytes) T(x, y, z); might be a help. What else are you gaining? And how do you destroy the T? If not explicitly and you don't have a "constructed" flag, you're going to have exception-safety problems. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: partial<> proposal
David Abrahams wrote:
[...]
>> Example:
>> optional i;
>>
>> new (i) int(17);
>
> Which copy ctor are you referring to?
> And why do we want to prevent copy ctor usages?
Because optional<> will be able to handle types without copy constructors
(this was the main purpose of partial<> in fact). I was referring to the
copy constructor of optional<>'s template parameter.
class A
{
A(A const &);
public:
A(int) {}
};
int main()
{
optional o(A(9));
}
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: partial<> proposal
David Abrahams wrote:
[...]
>>> Example:
>>> optional i;
>>>
>>> new (i) int(17);
>>
>>
>> Ex. 1:
>> // Class Widget has a heavy copy constructor
>> optional i;
>>
>> new (i) Widget(this, ...);
>
>
> Soo... what are you demonstrating here? Please spell it out. Normal
> construction of a widget in optional incurs a copy?
Yes, it incurs a copy. Maybe struct A is not a good example, but
TrollTech's QT widgets are.
struct A
{
A(int) { cout << "A(int)" << endl; }
A(A const &) { cout << "A(A const &)" << endl; }
};
int main()
{
optional o(A(9));
}
[...]
> Soo... what are you demonstrating here? Please spell it out. The
> bool in optional that indicates initialization incurs space/alignment
> overhead?
Yes, exactly. Sorry if I wasn't precise enough.
The bool type will cancel type_with_alignment<> effects (at least on Intel
compatible platforms); i.e. unique alignment of each optional type.
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
