Sign in to follow this  

C++ how to avoid calling destructor

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

That won't suppress the some_class destructor being called when array is deallocated or otherwise shuffles elements.

I'm not sure that's an issue in this case, as the OP only specified suppressing the destructor of the temp object. One problem with the locally allocated char array is that it may not have the correct alignment for some_class. A similar example from the C++98 standard had to be changed in the C++03 standard to use dynamic allocation of the char array so that alignment requirements were met.

 

Then you can declare the char storage with alignas(some_class) in C++11, or __declspec(align(__alignof(some_class))) in Visual C++.

Share this post


Link to post
Share on other sites

Personally, I always use pointers in container templates. This avoid unnecessary memory copies and constructor/destructor calls.
I'm a bit of a memory nazi though, so I prefer doing the new and delete myself.


Unfortunately your paranoia over copying means that you are pretty much dropping performance all over the place as between the de-referencing and the data misses you are giving the CPU a hard time.

Memory is SLOW, if you can you ALWAYS want to keep things as close together as you can when processing to take advantage of pre-fetching and caching of data. Stalling out the CPU for many cycles while it wanders off to find the data you've just asked for is not a productive use of anyone's time.

Edit: Part of me thinks that everyone should be made to program on a system with limited cache and an in-order arch. just so they can appreciate how many sins an OoO processor covers up... Edited by phantom

Share this post


Link to post
Share on other sites

It should compile, I would be interested in knowing why it doesnt for you.

Well, the obvious one is that new temp() should be new some_class(). It's also missing a right parenthesis. I can't comment on the bind business, I just checked it with a C++11 compiler and simply passed nullFunc instead of binding anything.

 

As for (properly) using smart pointers, once you get this to compile, it works really nicely for C libraries (with the appropriate deleter func added) without needing to wrap loads of stuff in C++ classes. Though the problem in this thread isnt perhaps the best use-case for it.

That might be a neat trick for cleaning up pointers from C APIs, but I hope you're very clear with documentation if you do that because it's not what people really expect with a shared_ptr. Additionally, you could just wrap the thing up in a proper class or struct and do the freeing in the destructor (which is probably more idiomatic). Anyway, the real problem I have with that snippet is that it's encouraging him to leak memory and completely negating the benefits of shared_ptr. I think that might be a useful trick (and thanks for this explanatory paragraph), but you're last sentence is the key. The "job" discussed in this thread requires a hammer, not a screw driver smile.png Telling someone to use a screw driver to nail something in (even if you have good intentions) is just... yeah...

Edited by Cornstalks

Share this post


Link to post
Share on other sites
Making an object static doesn't eliminate the destructor call, it just makes the destructor call happen at some later, indeterminate time.

Share this post


Link to post
Share on other sites

Huge discussion for when he probably just wants something like this:

std::vector<some_class> array;

void pushback_function()
{
    some_class temp;
    array.push_back(std::move(temp));
}

... to avoid an extraneous copy constructor and destructor call, but not eliminate destructors everywhere.

Share this post


Link to post
Share on other sites
That still has an extraneous construction and destruction, nor does it necessarily avoid an expensive copy operation. std::move() isn't magic. It can only move objects that have a properly defined move constructor. If you have std::move() available then you should also have emplace_back() which will avoid the entire temporary object in the first place.

Share this post


Link to post
Share on other sites
Any chance that we can see the real code yet?

I think there's a high probability that the entire problem here is a lack of following the Rule of three. Edited by iMalc

Share this post


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