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]

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

On Mon, 7 Apr 2008 12:07:03 -0700 (PDT), Jason Doucette
<jd*******@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]

On 2008-04-07 15:19:10 -0400, "Victor Bazarov" <v.********@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]

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]

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]

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]

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

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]

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/arti...bug_codes.html

--
Paul