replicating default constructor's "non-initializing state"

[Jason Doucette]

Situation:
I have a simple struct that, say, holds a color (R, G, and B). I
created my own constructors to ease its creation. As a result, I lose
the default constructor. I dislike this, but it's easy to solve: I
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. Thus, 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?

Thanks for your time,
Jason

P.S. My default constructor could initialize the variable to all 0's,
but this has two unwanted effects: 1. It slows down code in which
this initialization needn't occur. 2. It potentially hides bugs that
would show up if it were left uninitialized as it should be. (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).

[Victor Bazarov]

Re: replicating default constructor's "non-initializing state"

Jason Doucette wrote:

Situation:
I have a simple struct that, say, holds a color (R, G, and B). I
created my own constructors to ease its creation. As a result, I lose
the default constructor. I dislike this, but it's easy to solve: I
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. Thus, when I declare and use it before initializing it, the
compiler no longer warns me.

That's your choice, isn't it? You've chosen to implement your c-tor
(which is supposed to initialise the members) in such a way that does
*not* do what it promises to do. So, why are you complaining? It is
not a problem, or at least it's very easy to solve, isn't it?

>
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?

Not that I know of.

>
Thanks for your time,
Jason
>
P.S. My default constructor could initialize the variable to all 0's,
but this has two unwanted effects: 1. It slows down code in which
this initialization needn't occur.

Can you share the numbers, how much *does* it actually "slow down
the code"?

2. It potentially hides bugs that
would show up if it were left uninitialized as it should be.

Written *correctly* it _prevents_ bugs, not hides them.

(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).

Not similar at all. When in the "debug" build variables are given
some values whereas in the "non-debug" they are not, you have a very
big problem if your code ever depends on this. When your default
c-tor initialises member variables (to 0 or whatever) *always*, there
is no randomness, and you can *rely* on the initialisation happening.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Doug Harrison [MVP]]

Re: replicating default constructor's "non-initializing state"

On Mon, 7 Apr 2008 12:07:03 -0700 (PDT), Jason Doucette
<jdoucette@gmai l.comwrote:

>Situation:
>I have a simple struct that, say, holds a color (R, G, and B). I
>created my own constructors to ease its creation. As a result, I lose
>the default constructor. I dislike this, but it's easy to solve: I
>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. Thus, 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?

No.

>P.S. My default constructor could initialize the variable to all 0's,
>but this has two unwanted effects: 1. It slows down code in which
>this initialization needn't occur.

Almost certainly by an imperceptible degree.

>2. It potentially hides bugs that
>would show up if it were left uninitialized as it should be. (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).

The debugger doesn't do that, and AFAIK, never has. (I've been hearing this
for many years, and I still don't know how this rumor got started.) When
certain debug options are in effect, the compiler will initialize locals to
certain non-zero patterns.

--
Doug Harrison
Visual C++ MVP

[Pete Becker]

Re: replicating default constructor's &quot;non-initializing state&quot;

On 2008-04-07 15:19:10 -0400, "Victor Bazarov" <v.Abazarov@com Acast.netsaid:

Jason Doucette wrote:

>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?

>
Not that I know of.

For the future, though, C++0x will let you do this:

struct S
{
S() = default;
S(int);
};

with the effect that the compiler will generate that default
constructor as if you hadn't declared the other one.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Jason Doucette]

Re: replicating default constructor's &quot;non-initializing state&quot;

P.S.  My default constructor could initialize the variable to all 0's,

but this has two unwanted effects:  1. It slows down code in which
this initialization needn't occur.

>
Almost certainly by an imperceptible degree.

Agreed.

2. It potentially hides bugs that
would show up if it were left uninitialized as it should be.  (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).

>
The debugger doesn't do that, and AFAIK, never has. (I've been hearing this
for many years, and I still don't know how this rumor got started.) When
certain debug options are in effect, the compiler will initialize locals to
certain non-zero patterns.

You are quite right. MSVC++ sets them all to C's in hex, so you can
easily see that they are uninitialized in the debugger window. I
already knew this, as I tested it with a function I made to show the
bits of any data type, so I don't know why I keep thinking they are
set to 0.

Jason

[Jason Doucette]

Re: replicating default constructor's &quot;non-initializing state&quot;

For the future, though, C++0x will let you do this:

>
struct S
{
S() = default;
S(int);
};
>
with the effect that the compiler will generate that default
constructor as if you hadn't declared the other one.

Wow, Pete, that's cool. C++0x is the planned new C++ standard, so, I
guess I'm not the only one who wants this functionality.

Jason

[red floyd]

Re: replicating default constructor's &quot;non-initializing state&quot;

Jason Doucette wrote:

>>P.S. My default constructor could initialize the variable to all 0's,
>>but this has two unwanted effects: 1. It slows down code in which
>>this initialization needn't occur.

>Almost certainly by an imperceptible degree.

>
Agreed.
>
>

>>2. It potentially hides bugs that
>>would show up if it were left uninitialized as it should be. (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).

>The debugger doesn't do that, and AFAIK, never has. (I've been hearing this
>for many years, and I still don't know how this rumor got started.) When
>certain debug options are in effect, the compiler will initialize locals to
>certain non-zero patterns.

>
You are quite right. MSVC++ sets them all to C's in hex, so you can
easily see that they are uninitialized in the debugger window. I
already knew this, as I tested it with a function I made to show the
bits of any data type, so I don't know why I keep thinking they are
set to 0.

The reason that MSVC sets them to all 0xcc is not for easy visibility
(though that's a nice side-benefit). It's because 0xcc is the INT3
opcode in x86, which breaks to the debugger.

[Jason Doucette]

Re: replicating default constructor's &quot;non-initializing state&quot;

The reason that MSVC sets them to all 0xcc is not for easy visibility

(though that's a nice side-benefit).  It's because 0xcc is the INT3
opcode in x86, which breaks to the debugger.

Ah! Thanks! :)

Jason

[Ben Voigt [C++ MVP]]

Re: replicating default constructor's &quot;non-initializing state&quot;

red floyd wrote:

Jason Doucette wrote:

>>>P.S. My default constructor could initialize the variable to all
>>>0's, but this has two unwanted effects: 1. It slows down code in
>>>which this initialization needn't occur.
>>Almost certainly by an imperceptible degree.

>>
>Agreed.
>>
>>

>>>2. It potentially hides bugs that
>>>would show up if it were left uninitialized as it should be. (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).
>>The debugger doesn't do that, and AFAIK, never has. (I've been
>>hearing this for many years, and I still don't know how this rumor
>>got started.) When certain debug options are in effect, the
>>compiler will initialize locals to certain non-zero patterns.

>>
>You are quite right. MSVC++ sets them all to C's in hex, so you can
>easily see that they are uninitialized in the debugger window. I
>already knew this, as I tested it with a function I made to show the
>bits of any data type, so I don't know why I keep thinking they are
>set to 0.

>
The reason that MSVC sets them to all 0xcc is not for easy visibility
(though that's a nice side-benefit). It's because 0xcc is the INT3
opcode in x86, which breaks to the debugger.

As well as being an invalid pointer (it's in the top 1GB of address space
which is reserved for the kernel, attempts to access it from user-mode will
cause an access violation).

[Paul Carter]

Re: replicating default constructor's &quot;non-initializing state&quot;

On Apr 8, 3:04 pm, red floyd <no.s...@here.d udewrote:

Jason Doucette wrote:

>P.S. My default constructor could initialize the variable to all 0's,
>but this has two unwanted effects: 1. It slows down code in which
>this initialization needn't occur.
Almost certainly by an imperceptible degree.

>

Agreed.

>

>2. It potentially hides bugs that
>would show up if it were left uninitialized as it should be. (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).
The debugger doesn't do that, and AFAIK, never has. (I've been hearing this
for many years, and I still don't know how this rumor got started.) When
certain debug options are in effect, the compiler will initialize locals to
certain non-zero patterns.

>

You are quite right. MSVC++ sets them all to C's in hex, so you can
easily see that they are uninitialized in the debugger window. I
already knew this, as I tested it with a function I made to show the
bits of any data type, so I don't know why I keep thinking they are
set to 0.

>
The reason that MSVC sets them to all 0xcc is not for easy visibility
(though that's a nice side-benefit). It's because 0xcc is the INT3
opcode in x86, which breaks to the debugger.

Since this is usually stack or heap memory, why would INT 3 be
significant? It's not likely to be executed. Deleted memory is set to
0xdd in memory and I've also seen 0xcd used for other states. Here's a
link:

http://www.docsultant.com/site2/articles%5Cdebug_codes.html

--
Paul

[Jason Doucette]

Re: replicating default constructor's &quot;non-initializing state&quot;

As well as being an invalid pointer (it's in the top 1GB of address space

which is reserved for the kernel, attempts to access it from user-mode will
cause an access violation).

Very true! I remember hearing about this some time ago...

Thanks for all your replies, Ben Voigt!

Jason