Jump to content
  • Advertisement


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

The C modest god

Have you noticed?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 this post

Link to post
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


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 this post

Link to post
Share on other sites
Guest Anonymous Poster
That''s kewl! Thanks for sharing!

Share this post

Link to post
Share on other sites
Original post by The C modest god
I would like to share you with my little insight.

A obj = A(); // calls ctor only
obj = 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( );

Screenshots of your games or desktop captures -- Post screenshots of your projects. There''s already 134 screenshot posts.

Share this post

Link to post
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]

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!