Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There are two reasons I can think of why the memory allocated by a deque might not get deallocated, assuming a correct implementation of your standard library:</p> <ol> <li><strong>Violently accessing the deque's internals.</strong> Using memset/memcpy or <code>reinterpet_cast</code>/C-style casts might give you access to memory locations where the deque stores its private members, e.g. pointers to allocated memory. If you mess around with those private members in any way, deque might not be able to deallocate its dynamically allocated memory, leading to memleaks. Normally such agressive acts lead to access violations of many kinds, so you would observe rather crashes than just memleaks.</li> <li><strong>Missing deque destructor call.</strong> If for any reason a deque's destructor gets not called, it has no opportunity to "clean up", i.e. deallocate its owned dynamic memory, leading to said memleaks. In Your case, the deque destructor automatically gets called by A's destructor, <em>unless you have a <code>deque*</code> and allocated the deque itself on the free store/heap (see below).</em> Reason for a missing call of A's destructor might be one or more of the following: <ul> <li>Missing delete: delete calls the destructor of an object and releases the memory where the object had been. In that case, you should see another memleak, pointing where the object was allocated and created (in your sample code the new <code>A()</code>)</li> <li>Calling <code>free()</code> instead of delete: free only frees the memory but does not call any destructors. Never match new and free, even better try not to use malloc/free with C++ objects unless you are very careful and know what you do (placement new...)</li> <li>"Jumping" out of code. I you somehow "jump" out of scopes, the compiler might not be able to do the automated destructor calls at the end of the scope blocks. This does not apply for exceptions, because compilers know what to do and how to clean up. This <em>should</em> not apply for <code>goto</code>'s, since most compilers emit errors if you violate object lifetime boundaries with goto. Nevertheless, try not to use <code>goto</code> in C++, as there are other features you can use. The only "jumping" i could emagine here is <code>longjmp</code>, which is a C feature that does not respect scope boundaries and thus ignores the need for destructor calls, amongst others. <em>Never</em> use <code>longjmp</code> in C++ code.</li> </ul></li> </ol> <p>If anybody can think of more reasons for the memleak, missing destructor calls or others, give me a hint, I'll edit this answer :-)</p> <p>PS: I just saw I missed the "see below" part - so what's the deal if you have a <code>deque*</code> in A instead of a <code>deque</code>? In that case, A is responsible for correctly constructing and destructing the deque, meaning - call new whenever you need to create the queue - call delete at least in the destructor - handle especially copy/move assignment and copy/move construction correctly However, if you have a <code>deque*</code> and messed up the pointer handling you should see another memleak, pointing you to any of the <code>new deque</code> calls you will have.</p>
    singulars
    1. This table or related slice is empty.
    1. POCopy from std::set to std::deque- Memory issue
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USArne Mertz
    1. USArne Mertz
    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. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks a lot for very illustrative explanation.
      singulars
      1. PO
      1. USAnupama Pathirage
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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