Followers 0

# C++ how to avoid calling destructor

## 32 posts in this topic

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++.

0

##### 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  Telling someone to use a screw driver to nail something in (even if you have good intentions) is just... yeah...

Edited by Cornstalks
2

##### Share on other sites

I think eighter creating a pointer or a static member would solve your issue

-2

##### 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.
2

##### 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.

0

##### 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.
1

##### 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
1

## Create an account

Register a new account