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

wrapping int

P: n/a
Hello!

I'm a little bit worried about type int not being initialized to zero
by default,
which is very unconvenient in large projects.

What is your positive experience in wrapping int to a lightweight and
completely transparent class which elegantly solves this problem?

--
Vladimir

Nov 3 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
> I'm a little bit worried about type int not being initialized to zero
by default,
which is very unconvenient in large projects. The default initialization of a variable is compiler dependent and you
should not depend on it. In a large project, it makes even more sense
to make sure your variables are initialized the way you like it, rather
than depend on what 'might' happen
What is your positive experience in wrapping int to a lightweight and
completely transparent class which elegantly solves this problem?


I usually make sure that the variables are initialized explicitly. If
it a class variable, I do it in the class constructor, else if it is a
local variable I do it along with declaration.
I would not wrap it into a lightweight class personally. If you are
trying to do what java does (have a wrapper class for each primitive
type), think again as the requirement to have a wrapper class in java
is different.

Nov 3 '05 #2

P: n/a
"Vladimir" <vl*********@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I'm a little bit worried about type int not being initialized to zero
by default,
which is very unconvenient in large projects.


Can you give an example that illustrates your concern?
Nov 3 '05 #3

P: n/a
> int not being initialized to zero by default

I suggest you check your compiler's warning flags - it can probably
generate warning on most reads of uninitialised data. Further, there
are tools like Valgrind, purify and insure that such issues, as well as
myriad other issues. This is a more general solution that what you
propose.

More generally, try to define variables when you're ready to initialise
them, and be rigourous with your constructors, and you should be fine.
I understand the superficial appeal of wrapping int in the way you
describe, but it's too quirky and invasive. You'll find minor issues
such as templates being instantiated for both int and your int wrapper
class (minor code bloat), traits classes failing to work (e.g. someone
writes a template that is specialised for int, but you pass it an
Int<>) etc.../

Tony

Nov 3 '05 #4

P: n/a
Vladimir wrote:

Hello!

I'm a little bit worried about type int not being initialized to zero
by default,
which is very unconvenient in large projects.
Not at all.
It is just a matter of habit.
Once you got used to it, you do it automatically.
On the other hand: Why 0? Why not 5?

What is your positive experience in wrapping int to a lightweight and
completely transparent class which elegantly solves this problem?


Can't talk about that. Didn't have the need for it.

--
Karl Heinz Buchegger
kb******@gascad.at
Nov 3 '05 #5

P: n/a
Karl Heinz Buchegger wrote:
On the other hand: Why 0? Why not 5?


Because 0 will be the "right" value far more often than 5 will, so using
it does a better job of hiding errors.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Nov 3 '05 #6

P: n/a
True, 0 most often, but 1 and even -1 will be common. 5 less so,
therefore clearly making the point that 0 isn't universal, without
risking someone seriously thinking Karl liked the idea but thought 1 or
-1 or whatever more useful. - Tony

Nov 3 '05 #7

P: n/a

Andrew Koenig wrote:
I'm a little bit worried about type int not being initialized to zero
by default, which is very unconvenient in large projects.


Can you give an example that illustrates your concern?


Any class that has lots of parameters, most of them should be zero
at start. So, putting like 20 initializations to zero in initialization
list
or in constructor is rather cumbersome and error-prone.
(Restructuring isn't an option, really).

--
Vladimir

Nov 3 '05 #8

P: n/a

Hiding errors? My original question was to prevent errors.
Can you provide an example of your errors?

--
Vladimir

Nov 3 '05 #9

P: n/a
Vladimir wrote:
Hiding errors? My original question was to prevent errors.
Can you provide an example of your errors?


Automatically initializing variables to 0 is only useful if 0 is the
right value for that initialization. Deciding that the default
initialization provides the right value is fine, but forgetting to
initialize a variable is an error, even if the result doesn't happen to
do any harm.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Nov 3 '05 #10

P: n/a
"Sandeep" <sa************@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
I'm a little bit worried about type int not being initialized to zero
by default,
which is very unconvenient in large projects.

The default initialization of a variable is compiler dependent and you
should not depend on it.


The default initialization of any type is well defined by the standard. I
think you are describing the lack of initialization for fundamental types
and PODs; but even then, the values are undefined; not compiler dependent.

Ali

Nov 3 '05 #11

P: n/a
On 3 Nov 2005 12:07:57 -0800, "Vladimir" <vl*********@yahoo.com>
wrote:
Andrew Koenig wrote:
> I'm a little bit worried about type int not being initialized to zero
> by default, which is very unconvenient in large projects.


Can you give an example that illustrates your concern?


Any class that has lots of parameters, most of them should be zero
at start. So, putting like 20 initializations to zero in initialization
list
or in constructor is rather cumbersome and error-prone.
(Restructuring isn't an option, really).


Others have already pointed out that only the designer of the class
can know what the appropriate initialization value should be. It might
not always be zero, so you just have to initialize them properly.

The issue sounds to me like your design has maybe suffered from
feature creep, and as a result the class has grown too large to
handle. You should probably break it down into smaller classes with
well-defined areas of responsibility.

I wonder if you could define a struct or two to hold all of your int
members? That way, you could have just one initialization instead of
20. It might be the easiest/best way to restructure your code, too. 20
sounds like too many for one class, but you never know.

--
Bob Hairgrove
No**********@Home.com
Nov 3 '05 #12

P: n/a
"Vladimir" <vl*********@yahoo.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Andrew Koenig wrote:
> I'm a little bit worried about type int not being initialized to zero
> by default, which is very unconvenient in large projects.


Can you give an example that illustrates your concern?


Any class that has lots of parameters, most of them should be zero
at start. So, putting like 20 initializations to zero in initialization
list
or in constructor is rather cumbersome and error-prone.
(Restructuring isn't an option, really).


Well, you should fight for that refactoring. Those 20 fundamental types can
be grouped as PODs (or maybe even better in your case, as classes).

Then you would initialize only the POD:

class LargeClass
{
TwentyInt_POD twenty_;

public:

LargeClass()
:
twenty_()
{}
};

Now the members of twenty_ are zero-initialized.

Ali

Nov 3 '05 #13

P: n/a

Pete Becker wrote:
Automatically initializing variables to 0 is only useful if 0 is the
right value for that initialization.
Do you really think I'm missing that? :)
The whole point is that if most of the class members are zero
at start (some counters, initial amounts, etc.) then initializing
only non-zero ones reduces code bloat in ctor's init-list
and keeps only significant stuff that matters.
Deciding that the default
initialization provides the right value is fine, but forgetting to
initialize a variable is an error, even if the result doesn't happen to
do any harm.


At least this has well defined behavior and can be quickly spotted
when testing unlike the case with uninitialized data which isn't even
reproducable and finding such a bug can become the most frustrating
experience I can think of for a programmer.

--
Vladimir

Nov 3 '05 #14

P: n/a

Pete Becker wrote:
Automatically initializing variables to 0 is only useful if 0 is the
right value for that initialization.
Do you really think I'm missing that? :)
The whole point is that if most of the class members are zero
at start (some counters, initial amounts, etc.) then initializing
only non-zero ones reduces code bloat in ctor's init-list
and keeps only significant stuff that matters.
Deciding that the default
initialization provides the right value is fine, but forgetting to
initialize a variable is an error, even if the result doesn't happen to
do any harm.


At least this has well defined behavior and can be quickly spotted
when testing unlike the case with uninitialized data which isn't even
reproducable and finding such a bug can become the most frustrating
experience I can think of for a programmer.

--
Vladimir

Nov 3 '05 #15

P: n/a
If you default initialise initialise ints, then compilers and
execution-analysis tools won't even have a chance to warn about a read
from an uninitialised variable, degrading software quality....

Nov 4 '05 #16

P: n/a
> At least this has well defined behavior and can be quickly spotted
when testing unlike the case with uninitialized data which isn't even
reproducable and finding such a bug can become the most frustrating
experience I can think of for a programmer.


An unsound argument. If the values are initialised, and the behaviour
is repeatable, then it may be that the error is masked for the subset
of values used in testing - typically those considered typical + corner
cases. Put it out in the real world where all values are handled, and
the error may manifest. With an undefined value, it may not be
repeatable, but at least you have a greater chance of the error biting
during at least one of the test runs, plus compiler warnings and tools
exist to help diagnose the error.

Tony

Nov 4 '05 #17

P: n/a
Pete Becker wrote:

Automatically initializing variables to 0 is only useful if 0 is the
right value for that initialization. Agree
Deciding that the default initialization provides the right value is fine,
but forgetting to initialize a variable is an error,
even if the result doesn't happen to do any harm.

I'm not sure if it is always an error. I'm thinking at embedded
systems, where you don't want to pay some machine cycles to initialize
some variables (in the default constructor), if you are sure that those
would be always initialized before used.

Anyway, variables can be initialized at the declaration point. It will
be nice if also the class members could be initialized at the
declaration point.
e.g:
class foo
{
static const bool only_const_static_integral = false; //:)
bool flag = false;
char c = 'c';
int i = 0;
int unitialized;
double angle = 3.14;
//and why not:
Vector3d direction = Vector3d( 0, 0, 1);
//....
};
IMHO it looks better than:
//foo.h
class foo
{
static const bool only_const_static_integral = true; //:(
bool flag; //'some state', default false
char c; //default 'c';
int i; //'some id', default 0
int unitialized; //reserved
double angle;
//....
public:
foo();
};
No comment for the 'angle', let's see the cpp:
//foo.cpp
foo::foo():
c('c'),
i(0),
flag(i==0) //ups
{
//forgot the others ;)
}

Best regards,
Bogdan Sintoma

Nov 4 '05 #18

P: n/a
Bogdan Sintoma wrote:
Pete Becker wrote:

Deciding that the default initialization provides the right value is fine,
but forgetting to initialize a variable is an error,
even if the result doesn't happen to do any harm.


I'm not sure if it is always an error. I'm thinking at embedded
systems, where you don't want to pay some machine cycles to initialize
some variables (in the default constructor), if you are sure that those
would be always initialized before used.


That's what I referred to as "deciding that the default initiization
provides the right value." That's okay. Again, it is always an error to
FORGET TO INITIALIZE a variable.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Nov 4 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.