By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,820 Members | 1,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,820 IT Pros & Developers. It's quick & easy.

Is an incomplete initializer good form?

P: n/a
It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements to 0.
I have seen the following form, and was wondering is there was any good
reason to avoid it?
int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member and
//zeros the rest in one line.
}

Nov 6 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
VJ
Jake Montgomery wrote:
It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements to 0.
I have seen the following form, and was wondering is there was any good
reason to avoid it?
int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member and
//zeros the rest in one line.
}
I do not know what the standard says, but I would treat those as
undefined, until they are assigned values.

You can make a constructor inside your structure, like this:

struct foo
{
foo( )
: sizeOfThisStruct( 0 ),
x( 0 ),
y( 0 )
{}

int sizeOfThisStruct;
int x;
int y;
};

That way you are sure how your variables are initialized.
Nov 6 '06 #2

P: n/a
To Jake:

VJ wrote:
Jake Montgomery wrote:
>It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements to
0.
That's correct.
I have seen the following form, and was wondering is there was
>any good reason to avoid it?
At least one reply indicates that poor education of your peers might
be a valid reason.
>>

int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member
and //zeros the rest in one line.
}

I do not know what the standard says, but I would treat those as
undefined, until they are assigned values.

You can make a constructor inside your structure, like this:

struct foo
{
foo( )
: sizeOfThisStruct( 0 ),
x( 0 ),
y( 0 )
{}

int sizeOfThisStruct;
int x;
int y;
};

That way you are sure how your variables are initialized.
Two reasons not to do that. First, a user-defined c-tor makes the
struct lose its Plain-Old-Data-ness. Second, if this struct comes
from a library, you have no way of editing it.

The Standard guarantees that the remaining elements are initialised
with 0. Only mistrusting your compiler can make people want to do
what you propose.

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

P: n/a
VJ
Victor Bazarov wrote:
To Jake:

VJ wrote:
>>Jake Montgomery wrote:
>>>It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements to
0.


That's correct.
Regardless what c++ standard says, I do not trust compilers, therefore I
am going to continue initializing my variables before using them
>
>>I have seen the following form, and was wondering is there was
>>>any good reason to avoid it?


At least one reply indicates that poor education of your peers might
be a valid reason.

Why do you think my education is poor?

>>>
int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member
and //zeros the rest in one line.
}

I do not know what the standard says, but I would treat those as
undefined, until they are assigned values.

You can make a constructor inside your structure, like this:

struct foo
{
foo( )
: sizeOfThisStruct( 0 ),
x( 0 ),
y( 0 )
{}

int sizeOfThisStruct;
int x;
int y;
};

That way you are sure how your variables are initialized.


Two reasons not to do that. First, a user-defined c-tor makes the
struct lose its Plain-Old-Data-ness. Second, if this struct comes
from a library, you have no way of editing it.

The Standard guarantees that the remaining elements are initialised
with 0. Only mistrusting your compiler can make people want to do
what you propose.
He did not say the structure is POD, but I must admit I did not think
about it.

And yes, you are correct - I do not trust compilers enough to let them
initialize structures on their own
Nov 6 '06 #4

P: n/a
VJ wrote:
Victor Bazarov wrote:
>To Jake:

VJ wrote:
>>Jake Montgomery wrote:

It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements
to 0.


That's correct.

Regardless what c++ standard says, I do not trust compilers,
therefore I am going to continue initializing my variables before
using them
Whatever floats your boat.
>>I have seen the following form, and was wondering is there was

any good reason to avoid it?


At least one reply indicates that poor education of your peers might
be a valid reason.


Why do you think my education is poor?
I said nothing about *your* education. But the sheer fact that you
don't trust your tools may mean you don't know them enough.
[..]
And yes, you are correct - I do not trust compilers enough to let
them initialize structures on their own
Again, whatever.

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

P: n/a
VJ wrote:
....
Regardless what c++ standard says, I do not trust compilers, therefore I
am going to continue initializing my variables before using them
Not that compilers are infallible, however, betting your compiler is
wrong is a loosing strategy. Besides, initialization of structs has
been defined this way since K&R C days, there would be far more problems
in code than yours if the compiler suddenly stopped initializing the
rest of the elements to zeros.
Nov 6 '06 #6

P: n/a
VJ wrote:

Regardless what c++ standard says, I do not trust compilers,
therefore I am going to continue initializing my variables before
using them

Why do you trust your compiler to do the initializations correctly? You
may be paranoid, but are you paranoid enough?
Seriously, a major deviation from the standard like that wouldn't be
around in most popular compiler sets. It would have been noticed and
complained about many times over.


Brian
Nov 6 '06 #7

P: n/a
Jake Montgomery:
It is my understanding the the c++ standard guarantees that an
incomplete initializer will initialize all the remaining elements to 0.

Correct. Specifically:

When initialising an aggregate, all remaining elements become default-
initialised.

I have seen the following form, and was wondering is there was any good
reason to avoid it?
int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member and
//zeros the rest in one line.
}

For some reason an "int" is used to store a positive integer, but some
people just can't break this habit. Also, there's redundant parentheses
around "foo", but again, some people just can't break this habit. Other
than that though, it looks OK.

--

Frederick Gotham
Nov 6 '06 #8

P: n/a
Frederick Gotham wrote:
Jake Montgomery:
>int main()
{
struct foo {
int sizeOfThisStruct;
int x;
int y;};

foo myfoo = {sizeof(foo)}; // sets the sizeOfThisStruct member
and //zeros the rest in one line.
}


For some reason an "int" is used to store a positive integer, but some
people just can't break this habit. Also, there's redundant
parentheses around "foo", but again, some people just can't break
this habit. Other than that though, it looks OK.
Parentheses around 'foo' are NOT redundant - they are required since
'foo' is a type-id. They woudl be redundant if the initialisation
were

foo myfoo = { sizeof(myfoo) };

because they are not needed around an expression denoting an object.

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

P: n/a
Victor Bazarov:
Parentheses around 'foo' are NOT redundant - they are required since
'foo' is a type-id. They woudl be redundant if the initialisation
were

foo myfoo = { sizeof(myfoo) };

because they are not needed around an expression denoting an object.

Sorry you're right, I'm too accustomed to using lowercase for object names
and uppercase for types, didn't think to check if it was a type.

--

Frederick Gotham
Nov 6 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.