[ Seminars ] [ Seminars on CD ROM ] [ Consulting ]
Chapter 4 made a significant
improvement in library
use by taking all
the scattered components of a typical
C
library and encapsulating them into a structure (an abstract data type
called a
class from now on).
This not only provides a single unified
point of entry into a library component
but it also hides the names of the
functions within the class name. In Chapter 5
access control (implementation
hiding) was introduced. This gives the class designer a way to establish clear
boundaries for determining what the client programmer is allowed to manipulate
and what is off limits. It means the internal mechanisms of a data type’s
operation are under the control and discretion of the class designer
and
it’s clear to client programmers what members they can and should pay
attention to.
Together
encapsulation and access
control make a significant step in improving the ease of library use. The
concept of “new data type” they provide is better in some ways than
the existing built-in data types from C. The C++ compiler can now provide
type-checking guarantees for that data type and thus ensure a level of safety
when that data type is being used.
When it comes to safety
however
there’s a lot more the compiler can do for us than C provides. In this and
future chapters
you’ll see additional features that have been engineered
into C++ that make the bugs in your program almost leap out and grab you
sometimes before you even compile the program
but usually in the form of
compiler warnings and errors. For this reason
you will soon get used to the
unlikely-sounding scenario that a C++ program that compiles often runs right the
first time.
Two of these safety issues are
initialization and cleanup. A large segment of C bugs occur when the programmer
forgets to initialize or clean up a variable. This is especially true with C
libraries
when client programmers don’t know how to initialize a
struct
or even that they must. (Libraries often do not include an
initialization function
so the client programmer is forced to initialize the
struct by hand.) Cleanup is a special problem because C programmers are
comfortable with forgetting about variables once they are finished
so any
cleaning up that may be necessary for a library’s struct is often
missed.
In C++
the concept of initialization and
cleanup is essential for easy library use and to eliminate the many subtle bugs
that occur when the client programmer forgets to perform these activities. This
chapter examines the features in C++ that help guarantee proper initialization
and
cleanup.
Both the Stash and Stack
classes defined previously have a function called initialize( )
which hints by its name that it should be called before using the object in any
other way. Unfortunately
this means the client programmer must ensure proper
initialization. Client programmers are prone to miss details like initialization
in their headlong rush to make your amazing library solve their problem. In C++
initialization is too important to leave to the client programmer. The class
designer can guarantee initialization of every object by providing a special
function called the
constructor. If a class
has a constructor
the compiler automatically calls that constructor at the
point an object is created
before client programmers can get their hands on the
object. The constructor call isn’t even an option for the client
programmer; it is performed by the compiler at the point the object
is defined.
The next challenge is what to name this
function. There are two issues. The first is that any name you use is something
that can potentially clash with a name you might like to use as a member in the
class. The second is that because the compiler is responsible for calling the
constructor
it must always know which function to call. The solution Stroustrup
chose seems the easiest and most logical: the name of
the constructor is the same as the name of the class. It
makes sense that such a function will be called automatically on
initialization.
Here’s a simple class with a
constructor:
class X {
int i;
public:
X(); // Constructor
}; Now
when an object is
defined
void f() {
X a;
// ...
} the same thing happens as if a
were an int: storage is allocated for the object. But when the program
reaches the sequence point
(point of execution) where
a is defined
the constructor is called automatically. That is
the
compiler quietly inserts the call to X::X( ) for the object a
at the point of definition. Like any member function
the first (secret)
argument to the constructor is the
this pointer – the
address of the object for which it is being called. In the case of the
constructor
however
this is pointing to an un-initialized block of
memory
and it’s the job of the constructor to initialize this memory
properly.
Like any function
the constructor can
have arguments to allow you to
specify how an object is created
give it initialization values
and so on.
Constructor arguments provide you with a way to guarantee that all parts of your
object are initialized to appropriate values. For example
if a class
Tree has a constructor that takes a single integer argument denoting the
height of the tree
then you must create a tree object like
this:
Tree t(12); // 12-foot tree
If Tree(int) is your only
constructor
the compiler won’t let you create an object any other way.
(We’ll look at multiple constructors and different ways to call
constructors in the next chapter.)
That’s really all there is to a
constructor; it’s a specially named function that is called automatically
by the compiler for every object at the point of that object’s creation.
Despite it’s simplicity
it is exceptionally valuable because it
eliminates a large class of problems and makes the code easier to write and
read. In the preceding code fragment
for example
you don’t see an
explicit function call to some initialize( ) function that is
conceptually separate from definition. In C++
definition and initialization are
unified concepts – you can’t have one without the
other.
Both the constructor and destructor are
very unusual types of functions: they have no return
value. This is distinctly
different from a void return value
in which the function returns nothing
but you still have the option to make it something else. Constructors and
destructors return nothing and you don’t have an option. The acts of
bringing an object into and out of the program are special
like birth and
death
and the compiler always makes the function calls itself
to make sure
they happen. If there were a return value
and if you could select your own
the
compiler would somehow have to know what to do with the return value
or the
client programmer would have to explicitly call constructors and destructors
which would eliminate their
safety.
As a C programmer
you often think about
the importance of initialization
but it’s rarer to think about cleanup.
After all
what do you need to do to clean up an int? Just forget about
it. However
with libraries
just “letting go” of an object once
you’re done with it is not so safe. What if it modifies some piece of
hardware
or puts something on the screen
or allocates storage on the heap? If
you just forget about it
your object never achieves closure upon its exit from
this world. In C++
cleanup is as important as initialization and is therefore
guaranteed with the
destructor.
The syntax for the destructor is similar
to that for the constructor: the class name is used for the name of the
function. However
the destructor is distinguished from the constructor by a
leading tilde (~). In addition
the destructor never has any arguments
because destruction never needs any options.
Here’s the declaration for a destructor:
class Y {
public:
~Y();
}; The destructor is called automatically by
the compiler when the object goes out of
scope. You can see where the
constructor gets called by the point of definition of the object
but the only
evidence for a destructor call is the closing brace of the scope that surrounds
the object. Yet the destructor is still called
even when you use
goto to jump out of a
scope. (goto still exists in C++ for backward compatibility with C and
for the times when it comes in handy.) You should note that a nonlocal
goto
implemented by the
Standard C library functions setjmp( ) and
longjmp( )
doesn’t cause destructors
to be called. (This is the specification
even if your compiler doesn’t
implement it that way. Relying on a feature that isn’t in the
specification means your code is nonportable.)
Here’s an example demonstrating the
features of constructors and destructors you’ve seen so
far:
//: C06:Constructor1.cpp
// Constructors & destructors
#include <iostream>
using namespace std;
class Tree {
int height;
public:
Tree(int initialHeight); // Constructor
~Tree(); // Destructor
void grow(int years);
void printsize();
};
Tree::Tree(int initialHeight) {
height = initialHeight;
}
Tree::~Tree() {
cout << "inside Tree destructor" << endl;
printsize();
}
void Tree::grow(int years) {
height += years;
}
void Tree::printsize() {
cout << "Tree height is " << height << endl;
}
int main() {
cout << "before opening brace" << endl;
{
Tree t(12);
cout << "after Tree creation" << endl;
t.printsize();
t.grow(4);
cout << "before closing brace" << endl;
}
cout << "after closing brace" << endl;
} ///:~Here’s the output of the above
program:
before opening brace after Tree creation Tree height is 12 before closing brace inside Tree destructor Tree height is 16 after closing brace
You can see that the destructor is
automatically called at the closing brace of the scope that encloses
it.
In C
you must
always define all the variables at the beginning of a block
after the opening
brace. This is not an uncommon requirement in programming languages
and the
reason given has often been that it’s “good programming
style.” On this point
I have my suspicions. It has always seemed
inconvenient to me
as a programmer
to pop back to the beginning of a block
every time I need a new variable. I also find code more readable when the
variable definition is close to its point of
use.
Perhaps these arguments are stylistic. In
C++
however
there’s a significant problem in being forced to define all
objects at the beginning of a scope. If a constructor exists
it must be called
when the object is created. However
if the constructor takes one or more
initialization arguments
how do you know you will have that initialization
information at the beginning of a scope? In the general programming situation
you won’t. Because C has no concept of private
this separation of
definition and initialization is no problem. However
C++ guarantees that when
an object is created
it is simultaneously initialized. This ensures that you
will have no uninitialized objects running around in your system. C
doesn’t care; in fact
C encourages this practice by requiring you
to define variables at the beginning of a block before you necessarily have the
initialization
information[38].
In general
C++ will not allow you to
create an object before you have the initialization information for the
constructor. Because of this
the language wouldn’t be feasible if you had
to define variables at the beginning of a scope. In fact
the style of the
language seems to encourage the definition of an object as close to its point of
use as possible. In C++
any rule that applies to an “object”
automatically refers to an object of a built-in type as well. This means that
any class object or variable of a built-in type can also be defined at any point
in a scope. It also means that you can wait until you have the information for a
variable before defining it
so you can always
define and initialize at the
same time:
//: C06:DefineInitialize.cpp
// Defining variables anywhere
#include "../require.h"
#include <iostream>
#include <string>
using namespace std;
class G {
int i;
public:
G(int ii);
};
G::G(int ii) { i = ii; }
int main() {
cout << "initialization value? ";
int retval = 0;
cin >> retval;
require(retval != 0);
int y = retval + 3;
G g(y);
} ///:~You can see that some code is executed
then retval is defined
initialized
and used to capture user input
and
then y and g are defined. C
on the other hand
does not allow a
variable to be defined anywhere except at the beginning of the
scope.
In general
you should define variables
as close to their point of use as possible
and always initialize them when they
are defined. (This is a stylistic suggestion for built-in types
where
initialization is optional.) This is a safety issue. By reducing the duration of
the variable’s availability within the scope
you are reducing the chance
it will be misused in some other part of the scope. In addition
readability is
improved because the reader doesn’t have to jump back and forth to the
beginning of the scope to know the type of a
variable.
for(int j = 0; j < 100; j++) {
cout << "j = " << j << endl;
}
for(int i = 0; i < 100; i++)
cout << "i = " << i << endl;The statements above are important
special cases
which cause confusion to new C++ programmers.
The variables i and j are
defined directly inside the for expression (which you cannot do in C).
They are then available for use in the for loop. It’s a very
convenient syntax because the context removes all question about the purpose of
i and j
so you don’t need to use such ungainly names as
i_loop_counter for clarity.
However
some confusion may result if you
expect the lifetimes of the variables i and j to extend beyond the
scope of the for loop – they do
not[39].
Chapter 3 points out that while
and switch statements also allow the definition of objects in their
control expressions
although this usage seems far less important than with the
for loop.
Watch out for local variables that
hide
variables from the enclosing scope. In general
using the same name for a nested
variable and a variable that is global to that scope is confusing and error
prone[40].
I find small scopes an indicator of good
design. If you have several pages for a single function
perhaps you’re
trying to do too much with that function. More granular functions are not only
more useful
but it’s also easier to find
bugs.
A variable can now be defined at any
point in a scope
so it might seem that the storage for a variable may not be
defined until its point of definition. It’s actually more likely that the
compiler will follow the practice in C of allocating all the storage for a scope
at the opening brace of that scope. It doesn’t matter because
as a
programmer
you can’t access the storage (a.k.a. the object) until it has
been defined[41].
Although the storage is
allocated at the beginning of
the block
the constructor call doesn’t happen
until the sequence point where the object is defined because the identifier
isn’t available until then. The compiler even checks to make sure that you
don’t put the object definition (and thus the constructor call) where the
sequence point only
conditionally passes through it
such as in a
switch statement or
somewhere a goto can jump
past it. Uncommenting the statements in the following code will generate a
warning or an error:
//: C06:Nojump.cpp
// Can't jump past constructors
class X {
public:
X();
};
X::X() {}
void f(int i) {
if(i < 10) {
//! goto jump1; // Error: goto bypasses init
}
X x1; // Constructor called here
jump1:
switch(i) {
case 1 :
X x2; // Constructor called here
break;
//! case 2 : // Error: case bypasses init
X x3; // Constructor called here
break;
}
}
int main() {
f(9);
f(11);
}///:~ In the code above
both the goto
and the switch can potentially jump past the sequence point where a
constructor is called. That object will then be in scope even if the constructor
hasn’t been called
so the compiler gives an error message. This once
again guarantees that an object
cannot be created unless it is also initialized.
All the storage allocation discussed here
happens
of course
on the stack. The storage is
allocated by the compiler by moving the stack pointer “down” (a
relative term
which may indicate an increase or decrease of the actual stack
pointer value
depending on your machine). Objects can
also be allocated on the heap using new
which is something we’ll
explore further in Chapter
13.
The examples from previous chapters have
obvious functions that map to constructors and destructors:
initialize( ) and cleanup( ). Here’s the
Stash header using constructors and destructors:
//: C06:Stash2.h
// With constructors & destructors
#ifndef STASH2_H
#define STASH2_H
class Stash {
int size; // Size of each space
int quantity; // Number of storage spaces
int next; // Next empty space
// Dynamically allocated array of bytes:
unsigned char* storage;
void inflate(int increase);
public:
Stash(int size);
~Stash();
int add(void* element);
void* fetch(int index);
int count();
};
#endif // STASH2_H ///:~The only member function definitions that
are changed are initialize( ) and cleanup( )
which have
been replaced with a constructor and destructor:
//: C06:Stash2.cpp {O}
// Constructors & destructors
#include "Stash2.h"
#include "../require.h"
#include <iostream>
#include <cassert>
using namespace std;
const int increment = 100;
Stash::Stash(int sz) {
size = sz;
quantity = 0;
storage = 0;
next = 0;
}
int Stash::add(void* element) {
if(next >= quantity) // Enough space left?
inflate(increment);
// Copy element into storage
// starting at next empty space:
int startBytes = next * size;
unsigned char* e = (unsigned char*)element;
for(int i = 0; i < size; i++)
storage[startBytes + i] = e[i];
next++;
return(next - 1); // Index number
}
void* Stash::fetch(int index) {
require(0 <= index
"Stash::fetch (-)index");
if(index >= next)
return 0; // To indicate the end
// Produce pointer to desired element:
return &(storage[index * size]);
}
int Stash::count() {
return next; // Number of elements in CStash
}
void Stash::inflate(int increase) {
require(increase > 0
"Stash::inflate zero or negative increase");
int newQuantity = quantity + increase;
int newBytes = newQuantity * size;
int oldBytes = quantity * size;
unsigned char* b = new unsigned char[newBytes];
for(int i = 0; i < oldBytes; i++)
b[i] = storage[i]; // Copy old to new
delete [](storage); // Old storage
storage = b; // Point to new memory
quantity = newQuantity;
}
Stash::~Stash() {
if(storage != 0) {
cout << "freeing storage" << endl;
delete []storage;
}
} ///:~You can see that the require.h
functions are being used to watch for programmer errors
instead of
assert( ). The output of a failed assert( ) is not as
useful as that of the require.h functions (which will be shown later in
the book).
Because inflate( ) is
private
the only way a require( ) could fail is if one of the other
member functions accidentally passed an incorrect value to
inflate( ). If you are certain this can’t happen
you could
consider removing the require( )
but you might keep in mind that
until the class is stable
there’s always the possibility that new code
might be added to the class that could cause errors. The cost of the
require( ) is low (and could be automatically removed using the
preprocessor) and the value of code robustness is high.
Notice in the following test program how
the definitions for Stash objects appear right before they are needed
and how the initialization appears as part of the definition
in the constructor
argument list:
//: C06:Stash2Test.cpp
//{L} Stash2
// Constructors & destructors
#include "Stash2.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;
int main() {
Stash intStash(sizeof(int));
for(int i = 0; i < 100; i++)
intStash.add(&i);
for(int j = 0; j < intStash.count(); j++)
cout << "intStash.fetch(" << j << ") = "
<< *(int*)intStash.fetch(j)
<< endl;
const int bufsize = 80;
Stash stringStash(sizeof(char) * bufsize);
ifstream in("Stash2Test.cpp");
assure(in
" Stash2Test.cpp");
string line;
while(getline(in
line))
stringStash.add((char*)line.c_str());
int k = 0;
char* cp;
while((cp = (char*)stringStash.fetch(k++))!=0)
cout << "stringStash.fetch(" << k << ") = "
<< cp << endl;
} ///:~Also notice how the
cleanup( ) calls have been eliminated
but the
destructors are still automatically
called when intStash and stringStash go
out of scope.
One thing to be aware of in the
Stash examples: I’m being very careful to use only built-in types;
that is
those without destructors. If you were to try to copy class objects
into the Stash
you’d run into all kinds of problems and it
wouldn’t work right. The Standard C++ Library can actually make correct
copies of objects into its containers
but this is a rather messy and
complicated process. In the following Stack example
you’ll see
that pointers are used to sidestep this issue
and in a later chapter the
Stash will be converted so that it uses
pointers.
Reimplementing the linked list
(inside Stack)
with constructors and destructors shows how neatly constructors and
destructors work with new and delete. Here’s the modified
header file:
//: C06:Stack3.h
// With constructors/destructors
#ifndef STACK3_H
#define STACK3_H
class Stack {
struct Link {
void* data;
Link* next;
Link(void* dat
Link* nxt);
~Link();
}* head;
public:
Stack();
~Stack();
void push(void* dat);
void* peek();
void* pop();
};
#endif // STACK3_H ///:~Not only does Stack have a
constructor and destructor
but so does the nested class
struct Link:
//: C06:Stack3.cpp {O}
// Constructors/destructors
#include "Stack3.h"
#include "../require.h"
using namespace std;
Stack::Link::Link(void* dat
Link* nxt) {
data = dat;
next = nxt;
}
Stack::Link::~Link() { }
Stack::Stack() { head = 0; }
void Stack::push(void* dat) {
head = new Link(dat
head);
}
void* Stack::peek() {
require(head != 0
"Stack empty");
return head->data;
}
void* Stack::pop() {
if(head == 0) return 0;
void* result = head->data;
Link* oldHead = head;
head = head->next;
delete oldHead;
return result;
}
Stack::~Stack() {
require(head == 0
"Stack not empty");
} ///:~The Link::Link( ) constructor
simply initializes the data and next pointers
so in
Stack::push( ) the line
head = new Link(dat head);
not only allocates a new link (using
dynamic object creation with the keyword new
introduced in Chapter 4)
but it also neatly initializes the pointers for that link.
You may wonder why the destructor for
Link doesn’t do anything – in particular
why doesn’t
it delete the data pointer? There are two problems. In Chapter 4
where the Stack was introduced
it was pointed out that you cannot
properly delete a void pointer if it points to an object (an
assertion that will be proven in Chapter 13). But in addition
if the
Link destructor deleted the data pointer
pop( ) would
end up returning a pointer to a deleted object
which would definitely be a bug.
This is sometimes referred to as the issue of
ownership: the Link and thus the
Stack only holds the pointers
but is not responsible for cleaning them
up. This means that you must be very careful that you know who is
responsible. For example
if you don’t pop( ) and
delete all the pointers on the Stack
they won’t get cleaned
up automatically by the Stack’s destructor. This can be a sticky
issue and leads to memory leaks
so knowing who is responsible for cleaning up an object can make the difference
between a successful program and a buggy one – that’s why
Stack::~Stack( ) prints an error message if the Stack object
isn’t empty upon destruction.
Because the allocation and cleanup of the
Link objects are hidden within Stack – it’s part of
the underlying implementation – you don’t see it happening in the
test program
although you are responsible for deleting the pointers that
come back from pop( ):
//: C06:Stack3Test.cpp
//{L} Stack3
//{T} Stack3Test.cpp
// Constructors/destructors
#include "Stack3.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;
int main(int argc
char* argv[]) {
requireArgs(argc
1); // File name is argument
ifstream in(argv[1]);
assure(in
argv[1]);
Stack textlines;
string line;
// Read file and store lines in the stack:
while(getline(in
line))
textlines.push(new string(line));
// Pop the lines from the stack and print them:
string* s;
while((s = (string*)textlines.pop()) != 0) {
cout << *s << endl;
delete s;
}
} ///:~In this case
all the lines in
textlines are popped and deleted
but if they weren’t
you’d
get a require( ) message that would mean there was a memory
leak.
An aggregate is just what it
sounds like: a bunch of things clumped together. This definition includes
aggregates of mixed types
like structs and classes. An array is
an aggregate of a single type.
Initializing aggregates can be
error-prone and tedious. C++ aggregate
initialization makes it much
safer. When you create an object that’s an aggregate
all you must do is
make an assignment
and the initialization will be taken care of by the
compiler. This assignment comes in several flavors
depending on the type of aggregate you’re dealing with
but in all cases
the elements in the assignment must be surrounded by curly braces. For an array
of built-in types this is quite simple:
int a[5] = { 1
2
3
4
5 };If you try to give more initializers
than there are array elements
the compiler gives an
error message. But what happens if you give fewer initializers? For
example:
int b[6] = {0};Here
the compiler will use the first
initializer for the first array element
and then use zero for all the elements
without initializers. Notice this initialization behavior doesn’t occur if
you define an array without a list of initializers. So the expression above is a
succinct way to initialize an array to
zero
without using a for loop
and without any
possibility of an off-by-one error
(Depending
on the compiler
it may also be more efficient than the for
loop.)
A second shorthand for arrays is
automatic
counting
in which you let the compiler determine the size of the array based on the
number of initializers:
int c[] = { 1
2
3
4 };Now if you decide to add another element
to the array
you simply add another initializer. If you can set your code up so
it needs to be changed in only one spot
you reduce the chance of errors during
modification. But how do you determine the size of the array? The expression
sizeof c / sizeof *c (size of the entire array
divided by the size of the first element) does the trick in a way that
doesn’t need to be changed if the array size
changes[42]:
for(int i = 0; i < sizeof c / sizeof *c; i++) c[i]++;
Because structures are also aggregates
they can be initialized in a similar fashion. Because a C-style struct
has all of its members public
they can be assigned
directly:
struct X {
int i;
float f;
char c;
};
X x1 = { 1
2.2
'c' };If
you have an array of such objects
you can initialize them by using a nested set
of curly braces for each object:
X x2[3] = { {1
1.1
'a'}
{2
2.2
'b'} };Here
the third object is initialized to
zero.
If any of the data members are
private (which is typically the case for a well-designed class in C++)
or even if everything’s public but there’s a constructor
things are different. In the examples above
the initializers are assigned
directly to the elements of the aggregate
but constructors are a way of forcing
initialization to occur through a formal interface. Here
the constructors must
be called to perform the initialization. So if you have a struct that
looks like this
struct Y {
float f;
int i;
Y(int a);
}; You must indicate constructor calls. The
best approach is the explicit one as follows:
Y y1[] = { Y(1)
Y(2)
Y(3) };You get three objects and three
constructor calls. Any time you have a constructor
whether it’s a
struct with all members public or a class with
private data members
all the initialization must go through the
constructor
even if you’re using aggregate
initialization.
Here’s a second example showing
multiple constructor arguments:
//: C06:Multiarg.cpp
// Multiple constructor arguments
// with aggregate initialization
#include <iostream>
using namespace std;
class Z {
int i
j;
public:
Z(int ii
int jj);
void print();
};
Z::Z(int ii
int jj) {
i = ii;
j = jj;
}
void Z::print() {
cout << "i = " << i << "
j = " << j << endl;
}
int main() {
Z zz[] = { Z(1
2)
Z(3
4)
Z(5
6)
Z(7
8) };
for(int i = 0; i < sizeof zz / sizeof *zz; i++)
zz[i].print();
} ///:~A default constructor
is one that can be called with
no arguments. A default constructor is used to create a “vanilla
object
” but it’s also important when the compiler is told to create
an object but isn’t given any details. For example
if you take the
struct Y defined previously and use it in a definition like
this
Y y2[2] = { Y(1) };the compiler will complain that it cannot
find a default constructor. The second object in the array wants to be created
with no arguments
and that’s where the compiler looks for a default
constructor. In fact
if you simply define an array of Y
objects
Y y3[7];
the compiler will complain because it
must have a default constructor to initialize every object in the array.
The same problem occurs if you create an
individual object like this:
Y y4;
Remember
if you have a constructor
the
compiler ensures that construction always happens
regardless of the
situation.
The default constructor is so important
that if (and only if) there are no constructors
for a structure (struct or class)
the
compiler will automatically create one for you. So this
works:
//: C06:AutoDefaultConstructor.cpp
// Automatically-generated default constructor
class V {
int i; // private
}; // No constructor
int main() {
V v
v2[10];
} ///:~If any constructors are defined
however
and there’s no default constructor
the instances of V above will
generate compile-time errors.
You might think that the
compiler-synthesized constructor should do some
intelligent initialization
like setting all the memory for the object to zero.
But it doesn’t – that would add extra overhead but be out of the
programmer’s control. If you want the memory to be initialized to zero
you must do it yourself by writing the default constructor
explicitly.
Although the compiler will create a
default constructor for you
the behavior of the compiler-synthesized
constructor is rarely what you want. You should treat this feature as a safety
net
but use it sparingly. In general
you should define your constructors
explicitly and not allow the compiler to do it for
you.
The seemingly elaborate mechanisms
provided by C++ should give you a strong hint about the critical importance
placed on initialization and cleanup in the language. As Stroustrup was
designing C++
one of the first observations he made about productivity in C was
that a significant portion of programming problems are caused by improper
initialization of variables. These kinds of bugs are hard to find
and similar
issues apply to improper cleanup. Because constructors and destructors allow you
to guarantee proper initialization and cleanup (the compiler will not
allow an object to be created and destroyed without the proper constructor and
destructor calls)
you get complete control and safety.
Aggregate initialization is included in a
similar vein – it prevents you from making typical initialization mistakes
with aggregates of built-in types and makes your code more
succinct.
Safety during coding is a big issue in
C++. Initialization and cleanup are an important part of this
but you’ll
also see other safety issues as the book
progresses.
Solutions to selected exercises
can be found in the electronic document The Thinking in C++ Annotated
Solution Guide
available for a small fee from
www.BruceEckel.com.
[38]
C99
The updated version of Standard C
allows variables to be defined at any
point in a scope
like C++.
[39]
An earlier iteration of the C++ draft standard said the variable lifetime
extended to the end of the scope that enclosed the for loop. Some
compilers still implement that
but it is not correct so your code will only be
portable if you limit the scope to the for loop.
[40]
The Java language considers this such a bad idea that it flags such code as an
error.
[41]
OK
you probably could by fooling around with pointers
but you’d be very
very bad.
[42]
In Volume 2 of this book (freely available at www.BruceEckel.com)
you’ll
see a more succinct calculation of an array size using
templates.