Group: comp.lang.c++
From: peter koch
Date: Monday, April 07, 2008 3:37 PM
Subject: Re: replicating default constructor's "non-initializing state"

On 7 Apr., 21:07, Jason Doucette wrote:
> Situation:
> I have a simple struct that, say, holds a color (R, G, and B). =A0I
> created my own constructors to ease its creation. =A0As a result, I lose
> the default constructor. =A0I dislike this, but it's easy to solve: =A0I
> just make my own default constructor.
>
> Problem:
> My own default constructor is considered to be *initializing the
> variable* (even though it doesn't), whereas the original one does
> not. =A0Thus, when I declare and use it before initializing it, the
> compiler no longer warns me.
>
> Question:
> Are there any compiler settings (even compiler specific ones; I am
> using MSVC++) that state MY default constructor behaves exactly like
> the regular default constructor?

I don't believe so.

>
> Thanks for your time,
> Jason
>
> P.S. =A0My default constructor could initialize the variable to all 0's,
> but this has two unwanted effects: =A01. It slows down code in which
> this initialization needn't occur. =A0
How likely is this to happen? In correctly written code, most
creat=EDons will have a sensible value available. I doubt that not
having a proper initialisation will slow down your program in a
measurable way.
But if you do have such a beast hanging around, you could do something
aka:
struct uninitialised_t
{
};

class rgb
{
...
rgb( uninitialised_t ) {}
...
};

> 2. It potentially hides bugs that
> would show up if it were left uninitialized as it should be.
Hmmm... having a value of all zeroes does not look that stupid to me.

>=A0(This is
> similar to how MSVC++'s debugger initializes all variables to 0, which
> is silly, since it should initialize them to randomness -- as will
> happen in the release build -- to make bugs appear as quickly as
> possible).
No: randomness is most often not a good solution. But I agree that a
value different from 0 might enable you to spot those errors sooner.
But why so many uninitialised variables in the first place? My
experience is that uninitialised variables always are output
parameters and in that case, they are typically filled in the very
first statement after their definition.

/Peter