~ubuntu-branches/ubuntu/trusty/c++-annotations/trusty

« back to all changes in this revision

Viewing changes to yo/memory/objectp.yo

  • Committer: Package Import Robot
  • Author(s): Frank B. Brokken
  • Date: 2011-09-12 16:08:05 UTC
  • mfrom: (1.1.17 upstream)
  • Revision ID: package-import@ubuntu.com-20110912160805-r9dq68beojgzuien
Tags: 9.0.2-1
New upstream release (editorial changes)

Show diffs side-by-side

added added

removed removed

Lines of Context:
33
33
first object's destructor is called if the tt([]) is omitted.
34
34
 
35
35
    Conversely, if tt(delete[]) is called in a situation where tt(delete)
36
 
should have been called the results are unpredictable, and will most likely
37
 
cause the program to crash. This problematic behavior is caused by the way the
38
 
run-time system stores information about the size of the allocated array
39
 
(usually right em(before) the array's first element). If a single object is
40
 
allocated the array-specific information is not available, but it is
41
 
nevertheless assumed present by tt(delete[]). This latter operator will
42
 
interpret bogus values before the array's first element as size information,
43
 
thus usually causing the program to fail.
 
36
should have been called the results are unpredictable, and the program will
 
37
most likely crash. This problematic behavior is caused by the way the run-time
 
38
system stores information about the size of the allocated array (usually right
 
39
em(before) the array's first element). If a single object is allocated the
 
40
array-specific information is not available, but it is nevertheless assumed
 
41
present by tt(delete[]). Thus this latter operator encounters bogus values in
 
42
the memory locations just before the array's first element. It then dutifully
 
43
inteerprets the value it encounters there as size information, usually causing
 
44
the program to fail.
44
45
 
45
46
    If no destructor is defined, a emi(trivial destructor) is defined by the
46
47
compiler. The trivial destructor ensures that the destructors of composed
47
48
objects (as well as the destructors of em(base classes) if a class is a
48
49
derived class, cf. chapter ref(INHERITANCE)) are called. This has serious
49
 
implications: objects allocating memory will cause a i(memory leak) unless
50
 
precautionary measures are taken (by defining an appropriate
 
50
implications: objects allocating memory create memory leaks hi(memory leak)
 
51
unless precautionary measures are taken (by defining an appropriate
51
52
destructor). Consider the following program:
52
53
        verbinclude(examples/stringstorenodelete.cc)
53
54
    This program produces no output at all. Why is this? The variable tt(ptr)