#### Archived

This topic is now archived and is closed to further replies.

# Have you noticed?

This topic is 5261 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I would like to share you with my little insight.  class A { . . . }; A obj = A(); // calls ctor only obj = A(); // calls ctor and immediatly after dtor 

##### Share on other sites
not only does it call the ctor and then the dtor, it also calls the assignment operator.

"Sneftel is correct, if rather vulgar." --Flarelocke

##### Share on other sites
To be more precise, the first line may be translated by the compiler to

A obj(A());

which becomes

A obj;

While in the second one obj already exists, so

obj.operator=(A());

is what happens, which causes the construction of an A, then the assigment of of obj to that A, and then the desctruction of the temporary A.

##### Share on other sites
That''s kewl! Thanks for sharing!

##### Share on other sites
quote:
Original post by The C modest god
I would like to share you with my little insight.
A obj = A(); // calls ctor onlyobj = A(); // calls ctor and immediatly after dtor

To clarify what marijnh said, the first line calls obj::A() (the constructor) but the second line calls temp::A() and temp::~A() where temp is some temporary object. It''s not calling obj''s ctor and dtor.

You have just discovered why people say not to use temporary variables -- it''s slower. You''re creating an object and destroying it for no reason. There are two ways around this. Let''s say you have a color class. Instead of setting each color component separately, you can either, obviously, do:
Color.Set( R, G, B );
Or you can write an overloaded parentheses operator, and do:
Color( R, G, B );
This method is more confusing since it looks like a function, but it is less typing.

~CGameProgrammer( );

-- Post screenshots of your projects. There''s already 134 screenshot posts.

##### Share on other sites
I'd like to point out that while temporary object can really be a problem for some classes, for other classes - i.e. one with few data members and trivial constructors and destructors - they are not a problem at all and can be quite convenient. When you look at a class, you can ask yourself "can I happily copy this object? is this efficient?", objects basically fall into three categories:

- Full value semantics - can safely and efficiently be copied. examples: std::auto_ptr, simple 2d vector classes, most implementations of std::string.
- Inefficient value semantics - can be copied without causing problems, but it is not efficient to do so. examples: std::vector and other containers, big but copy-safe classes that you write.
- Does not support value semantics - either disallows copying or causes problems when copied (bad), you might want to write private assignment operator and copy constructor for this or inherit from boost::noncopyable. examples: a class that allocates memory with new, deletes it in the destructor, but does not implement a suitable operator= or copy constructor.

Well, this is quite off-topic, but I felt like writing it.

by the way, brilliant picture, the one useless hacker posted

[edited by - marijnh on February 23, 2004 6:12:59 AM]

1. 1
Rutin
25
2. 2
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 14
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631757
• Total Posts
3002131
×