Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You got some nasty comments to your question. Now I don't think they are deserved although there may be better ways to do what you want. I understand where you are coming from but actually you are using the destructor the same way you would use the reset function you refuse to write. Actually you gain nothing from calling a destructor since calling a distructor has nothing to do with actually deleting or resetting anything unless you actually write the code to do it within the destructor. </p> <p>As to your question about the placement new:</p> <p>As you may know already the placement new doesn't allocate any memory so calling it will just create the object in the same place. I understand that is exactly what you want but it's just not ncessary. Since you don't call delete on your object just destroy, you can set destroyed to true without initializing the class.</p> <p>To sum it up:</p> <ol> <li>If you use the destructor as a regular virtual function you gain nothing. Don't do it since you can get into trouble if a destructor is called twice</li> <li>A call to a placement new will not allocate memory and just perform needless initialization. You can just set destroyed to true.</li> </ol> <p>To do what you want to do correctly and gain the benefits of destructors, you should overload the new and delete operators of your classes and use the normal destruction mechanism. You can then opt not to release the memory but mark it as invalid or maybe release most of the memory but leave the pointer pointing to some flags.</p> <p><strong>EDIT</strong></p> <p>Following the comments I decided to sum up all the risks I see and the risks that others have pointed out:</p> <ol> <li>Accessing invalid pointer in a multi-threaded environment: Using your method a class may be accessed after the destructor has run but before the destroyed flag is set (As to your question in one of the comments - shared_ptr is for most purposes thread safe)</li> <li>Relaying on a behavior you don't totally control: Your method relies on the way destructors auto call the destructors of other members which are not dynamically allocated: This means that you still have to release dynamically allocates memory specifically, You have no control on how exactly this is implemented, You have no control on the order in which other destructors are called.</li> <li>Relaying on a behavior you don't totally control (Point 2): You are relaying on the way a compiler implements the part of the destructor which calls other destructors you have no way in telling whether your code will be portable or even how will it handle calling it twice.</li> <li>Destructors may be called twice: Depending on your implementation this may cause memory leaks or heap corruption unless you guard against releasing the same memory twice. You claim you guard against that case by calling the placement new - However in a multi-threading environment this is not guaranteed further more you assume that all memory allocations are done by the default constructor - depending on your specific implementation this may or may not be true.</li> <li>You are going against the better judgment of everyone that answered your question or commented on it - You may be onto something genius but most probably you are just shooting yourself in the leg by limiting your implementation to a small subset of situations where it will work correctly. It is like when you use the wrong screwdriver you will eventually end up damaging the screw. In the same way using a language construct in a way it was not intended to be used may end up with a buggy program - Destructors are intended to be called from delete and from the code generated by the compiler to clear the stack. Using it directly is not wise.</li> </ol> <p>And I repeat my suggestion - overload delete and new for what you want</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. CO"Actually you gain nothing from calling a destructor since calling a distructor has nothing to do with actually deleting or reseting anything unless you actually write the code to do it within the destructor." -- Note that a destructor automatically calls the destructors of all the class members. Using the destructor over implementing `reset()` myself saves me the trouble of iterating over all the members and calling `reset()` myself (provided the members have such function).
      singulars
    2. CO@CygnusX1 You are right but automatic destruction is only for class variables that are not allocated dynamically. Your approach is very risky in my opinion - You rely on automatic behavior that is correct only for part of your class data. Also since for those variables nothing is released there is little gain. However I see how this maight help you - Just remember to guard against double calls to destructors or trying to release already released memory.
      singulars
    3. COGood points. However, I don't see (yet) any additional risk of double-destructing or double-releasing when using the above construct (except for multi-threading hazards). Even if `destroy()` is called twice, it should still work fine, I think? This is because when I destroy an object manually I immediately create a new one in its place. Only calling `delete` twice at the same pointer could lead to an error, but that would be wrong even without the above construct.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload