Jump to content
  • Advertisement
Sign in to follow this  
Prune

Reload

This topic is 2148 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

Advertisement

That entire thing is ugly, but I think the worst part is where the destructor is explicitly called..and from a macro none-the-less

 

EDIT:

 

That's... awful. Where would this get used?

I hope nowhere!

Edited by ByteTroll

Share this post


Link to post
Share on other sites

The use of a macro and var args to initialize the new object kind of makes me shudder at first, but then again... since the constructor will make sure the parameters are correct, this macro (ugly as it is) is type-safe as well. The fact that Y is used to call the destructor implicitly prevents you from scrapping the object in favour of a different type of object which might have a bigger storage size, too. Actually that is quite ingenious (assuming it's intentional, not by coincidence).

 

Other than being a macro (and thus ugly, and non-obvious), I can actually find very little to complain about. What the macro does is weird, but perfectly legal from what I can tell.

 

Let's just hope that nobody ever calls this with a const object (which would invoke undefined behavior according to §3.8/9).

Share this post


Link to post
Share on other sites

Now that must be the ancestor of the move-assignement operator :D

Foo class(...);
class = std::move(Foo(...)); // pretty much the same as the RELOAD-macro, if operator=(Foo&&) is implemented

Share this post


Link to post
Share on other sites

 

Now that must be the ancestor of the move-assignement operator biggrin.png

Foo class(...);
class = std::move(Foo(...)); // pretty much the same as the RELOAD-macro, if operator=(Foo&&) is implemented

Somewhat similar, but I would say it's rather the opposite. Moving an object means "stealing" a temporary object (without anyone noticing) and assigning that same nameless object to a name.

 

The above macro explicitly ends the lifetime of a named object, then steals its storage, reconstructs another object in-place, and implicitly reassigns it to the same name.

 

For entertainment, I've templatized it:

#include <new>
#include <type_traits>
template<typename T, typename... V> void reuse_inplace(T& obj, V... args)
{
    static_assert(!std::is_const<T>::value, "in-place construction over a const object");
    obj.~T(); new(&obj) T(args...);
};

Not like it's much better, but at least it isn't a macro now, and it can't steal a const object  smile.png

Edited by samoth

Share this post


Link to post
Share on other sites

The fact that Y is used to call the destructor implicitly prevents you from scrapping the object in favour of a different type of object which might have a bigger storage size, too. Actually that is quite ingenious (assuming it's intentional, not by coincidence).

It was intentional, but what I didn't realize was that Y is unnecessary as a parameter:

#define RELOAD(X, ...) { typedef decltype(X) Y; X.~Y(); new (&X) Y(__VA_ARGS__); }

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!