Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What all the answers given so far boil down to is this: <em>avoid having to call <code>delete</code></em>. </p> <p>Any time the programmer has to call <code>delete</code>, you have a potential memory leak. Instead, make the <code>delete</code> call happen automatically. C++ guarantees that local objects have their destructors called when they go out of scope. Use that guarantee to ensure your memory allocations are automatically deleted.</p> <p>At its most general, this technique means that every memory allocation should be wrapped inside a simple class, whose constructor allocates the necessary memory, and destructor releases it.</p> <p>Because this is such a commonly-used and widely applicable technique, smart pointer classes have been created that reduce the amount of boilerplate code. Rather than allocating memory, their constructors take a pointer to the memory allocation already made, and stores that. When the smart pointer goes out of scope, it is able to delete the allocation.</p> <p>Of course, depending on usage, different semantics may be called for. Do you just need the simple case, where the allocation should last exactly as long as the wrapper class lives? Then use <code>boost::scoped_ptr</code> or, if you can't use boost, <code>std::auto_ptr</code>. Do you have an unknown number of objects referencing the allocation with no knowledge of how long each of them will live? Then the reference-counted <code>boost::shared_ptr</code> is a good solution.</p> <p>But you don't have to use smart pointers. The standard library containers do the trick too. They internally allocate the memory required to store copies of the objects you put into them, and they release the memory again when they're deleted. So the user doesn't have to call either <code>new</code> or <code>delete</code>.</p> <p>There are countless variations of this technique, changing whose responsibility it is to create the initial memory allocation, or when the deallocation should be performed.</p> <p>But what they all have in common is the answer to your question: The <strong>RAII</strong> idiom: Resource Acquisition Is Initialization. Memory allocations are a kind of resource. Resources should be acquired when an object is initialized, and released by the object itslef, when it is destroyed.</p> <p>Make the C++ scope and lifetime rules do your work for you. Never ever call <code>delete</code> outside of a RAII object, whether it is a container class, a smart pointer or some ad-hoc wrapper for a single allocation. Let the object handle the resource assigned to it.</p> <p>If all <code>delete</code> calls happen automatically, there's no way you can forget them. And then there's no way you can leak memory.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to guard against memory leaks?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USjalf
    1. USjalf
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to guard against memory leaks?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 - As George C. would say: What else ?
      singulars
      1. PO
      1. USpaercebal
    2. CONote that it could lead to awkward interview sessions with humourless interviewers : "How do you avoid memory leaks ?" ... "Avoid writing delete !"...
      singulars
      1. PO
      1. USpaercebal
    3. COall the more reason to say it ;)
      singulars
      1. PO
      1. USjalf
 

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