imutate@hotmail.co.uk wrote:
Quote:
Quote:
Not neccessarily, but keep in mind that some compilers will default
initialize an integer, for example, to 0 in debug and leave it
unitialized in release mode.
>
OK, deceptive, but not particularly unusual in computer systems in
general for initialise values to be non 0 or null.
Note that released, optimized code does not initialize at all unless
the ctor does some sort of default construction. Uninitialized objects
are dangerous since the residual bits that are contained in the object
are used if the instance is operated on. That, in essence, is a common
bug.
Doesn't the compiler have to generate a ctor anyway? Same with copy
ctor, d~tor, etc. Why not take control of what the compiler does?
Consider a class that stores a pointer that is left unitialized by
mistake.
What if you wrote the class's ctor to default initialize the pointer to
0 instead?
The moment you, me or an unsuspecting user of the class makes the
mistake of using an instance of P without setting it: the compiler
generates an error that instantly and precisely diagnoses the problem
(null pointer exception). In the long run, its less work cause you
don't have to split your brains looking for the hard to find bugs. Its
safety built-in to the design. And your clients will love you for it.
Quote:
>
Quote:
Besides, why assign it later when you can
do it at construction time?
>
Constructors that assign values make for nice textbook code, but in
practice if you have objects of any complexity you will probably want
to initialise them from disk ( database etc) probably more than once.
So writing constructor code just makes for more work.
The ctor is invoked when reading the data from disk directly. In other
words, when the std::ifstream opens the file: it's contents are
seamlessly used to construct (or even reinitialize) the object or its
elements.
Quote:
Quote:
The std::vector is private. The goal is to prevent the user of the
class from directly accessing the components within. As an example, you
can overload vec::push_back(...) to take 3 integer parameters instead
of a celement. You might choose to provide a vec ctor that takes an
array of celements.
>
OK, but why not make a member to "initialise" the object and then call
that from the constructor, that way I don't have to create a new object
just clear it (if neccessary) and call initialise again.
There is no reason why not. Using some init() member function is
perfectly safe. Which brings us to the core of the issue. The ctor
already supports the init list. I can think of several languages who
would DIE to have the benefits of the init list.
class N
{
int n; // n could be a complex user-type instead
public:
N() : n( initialize() ) { } // perfectly legal
~N() { }
int initialize() const { return 100; } // or whatever is required
};
That way, you can reserve the body of the ctor (and d~tor) for usefull
diagnostics when you are developing the project. as in:
N::N() : n( initialize() ) { std::cout << "N()\n"; }
N::~N() { std::cout << "~N()\n"; }
Which may look trivial at this point but very handy when dealing with
polymorphism and deallocations (you know... memory leaks).
Quote:
>
Thanks, for the example.
Your welcome, and give yourself some credits. You at least showed some
code.
