* jason.cipriani@gmail.com:
> On Feb 26, 11:12 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> Alf P. Steinbach wrote:
>>> * Christopher:
>>> reset() { *this = B(); }
>> I've never seen that before, but it does seem like a neat idea.
>>
>> It seems like it would be (generally speaking) twice as slow as manual
>> member-by-member initialization, because of (a) the temporary object's
>> constructor, plus (b) the assignment operator.

No. Thinking about that would be premature optimization. Actually a 'reset'
member function indicates of itself premature optimization, the idea of reusing
an object to avoid some imagined micro-inefficiency, thereby complicating the
design.

For optimization, always first measure.


> Just now I managed to get this working using placement new. Is there
> anything bad that can happen with the following code (assuming the
> constructor does not throw any exceptions):
>
> class B {
> public:
> B () { }
> ~B () { }
>
> void Reset () {
> this->~B();
> new (this) B();
> }
>
> };
>
> I've done a good amount of testing on that just now and it seems to
> work fine (even when B has other complex object members, etc.).
> Assuming it's safe,

It isn't safe, in general.

In particular it's problematic if anyone ever derives from B: then you're
constructing the wrong kind of object.

To reuse the constructor logic e.g. in assignment operator, instead add a swap()
member function.


> it doesn't require you to implement an assignment
> operator for complex B's,

Assignment operator or not has nothing to with the above issue.


> and doesn't create any temporaries.

Temporaries are not inefficient. They're not ungood. You should not focus on
avoiding temporaries.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?