Simulatneous declare/initialize member variable

[Fred Ma]

Are there any reasons that would make it bad for C++ to
allow simultaneous declaration and initilization of member data?

Current way:
------------

class DerivedClass : BaseClass {
{
enum { lengthSV=16 }; // Length of SomeVector
vector<double> SomeVector;

DerivedClass( void ) : BaseClass( SomeArgument ), SomeVector(lengthSV,0.0)
{
// Construction of Derived Class
};
};

Better/Worse way?
-----------------

class DerivedClass : BaseClass {
{
enum { lengthSV=16 }; // Length of SomeVector
vector<double> SomeVector(lengthSV);

DerivedClass( void ) : BaseClass( SomeArgument )
{
// Construction of Derived Class
};
};
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

[Victor Bazarov]

"Fred Ma" <fm*@doe.carleton.ca> wrote...

Are there any reasons that would make it bad for C++ to
allow simultaneous declaration and initilization of member data?

Current way:
------------

class DerivedClass : BaseClass {
{
enum { lengthSV=16 }; // Length of SomeVector
vector<double> SomeVector;

DerivedClass( void ) : BaseClass( SomeArgument ), SomeVector(lengthSV,0.0) {
// Construction of Derived Class
};
};

Better/Worse way?
-----------------

class DerivedClass : BaseClass {
{
enum { lengthSV=16 }; // Length of SomeVector
vector<double> SomeVector(lengthSV);
This is not "better" or "worse". This is simply not allowed.

DerivedClass( void ) : BaseClass( SomeArgument )
{
// Construction of Derived Class
};
};

Victor

[Fred Ma]

Victor Bazarov wrote:

This is not "better" or "worse". This is simply not allowed.

Yes, I know it's not allowed. Wouldn't the code be clearer and
more compact if it was allowed? Perhpas there are some reasons
that it isn't allowed.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

[qWake]

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@doe.carleton.ca...

Are there any reasons that would make it bad for C++ to
allow simultaneous declaration and initilization of member data?

Your question is not specific to vectors, it holds for all data members.
For example you can have an "int i;" declaration as a class member, so your
question would also be: what problem could exist with using "int i(-3);"
instead of having to set the value in a constructor?

I think one answer may be that different constructors will initialize data
members differently, so a single declaration (of the type you refer to)
would need to be over-ridden by a constructor that needs something
different. Constructors that are fine with the default value would just
leave it alone. But this would make the code less coherent as readers would
have to refer to more than just the constructor to determine what values are
given to all members. Instead of having everything in a single location,
now you need to look at both the constructor and the data declaration to
find out what values are given to all members.

Maybe the question boils down to what is truly needed against what may be
nice to have but is not essential.

[Fred Ma]

qWake wrote:

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@doe.carleton.ca...

Are there any reasons that would make it bad for C++ to
allow simultaneous declaration and initilization of member data?

Your question is not specific to vectors, it holds for all data members.
For example you can have an "int i;" declaration as a class member, so your
question would also be: what problem could exist with using "int i(-3);"
instead of having to set the value in a constructor?

I think one answer may be that different constructors will initialize data
members differently, so a single declaration (of the type you refer to)
would need to be over-ridden by a constructor that needs something
different. Constructors that are fine with the default value would just
leave it alone. But this would make the code less coherent as readers would
have to refer to more than just the constructor to determine what values are
given to all members. Instead of having everything in a single location,
now you need to look at both the constructor and the data declaration to
find out what values are given to all members.

Maybe the question boils down to what is truly needed against what may be
nice to have but is not essential.

Definitely, it's not essential (few things are). I was just wondering why
it is necessary to move such a simple initialization to the derived class's
constructor (specifically, to form an initialization list). A person then
has to look at the declaration to see the data member, the the appropriate constructor to see the initialization. Right now, the initialization lists
that follow the different constructors override the default value of member
anyway. That is, if the member variable is not specified in an initializer
list, it is left alone. Otherwise, the initialization list takes precedence.
At the moment, I can't recall if the member variables becomes zero if it
doesn't show up in the initialization list, but that is immaterial. It is
left alone regardless. So it is no less confusing to allow the user to
specify the default initialization for a data member in the case that it
doesn't show up in an initialization list. In the current case, where it
isn't allowed, you must still keep in mind either the zero default or the
simply unknown value default.

The reason this comes to mind is because C++ has enough bells and whistles
and a myriad of nuances to keep in mind already. Different details specified
at various places. The more streamline the code, the better. The above
change wouldn't detract from any functionality. If it doesn't collide with
any other syntatic requirements, it would certainly help in managing all
the features and details.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

[Victor Bazarov]

Fred Ma wrote:

Victor Bazarov wrote:

This is not "better" or "worse". This is simply not allowed.

Yes, I know it's not allowed. Wouldn't the code be clearer and
more compact if it was allowed? Perhpas there are some reasons
that it isn't allowed.

Perhaps. I am not going to speculate about it. Please ask in
comp.std.c++, they discuss the "why it's so in the Standard".

V

[qWake]

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@doe.carleton.ca...

That is, if the member variable is not specified in an initializer
list, it is left alone.

I think instances that are not explicitly initialized hold garbage unless
they have a default constructor. Your idea has the merit that simple types
could behave within a class as if they also had a default constructor.
Perhaps you should ask the question in comp.std.c++ for a more informed
reply.

[Jerry Coffin]

Fred Ma <fm*@doe.carleton.ca> wrote in message news:<40***************@doe.carleton.ca>...

Are there any reasons that would make it bad for C++ to
allow simultaneous declaration and initilization of member data?

Yes, more or less. Difference ctors might need to initialize a
variable differently. As-is, the rule is consistent: non-static
members are initialized on the ctor. I doubt that the rules could be
kept nearly this consistent otherwise. Just for example, if you had
something like:

class X {
int x=0;
public:
X() : x(1) {}
};

how would you deal with it? Consider it ill-formed (keeping in mind
that the class definition will often be visible in places that the
ctor isn't)? Start with 0 and then assign 1? Start with 1 and then
assign 0? What would you do if (for example) instead of an int, this
was an instance of some other class that only supported initialization
and NOT assignment?

Ultimately, I suspect each of these questions _could_ be answered, but
doing so would probably lead to quite a few more. In the end, all the
questions might have answers, but I doubt anybody has gone to the
trouble of figuring out for sure -- most of the people on the
committee are pretty busy to start with, so in general, committee work
gets prioritized, and something that adds a lot of questions but
little or no new utility is likely to get quite a low priority.
--
Later,
Jerry.

The universe is a figment of its own imagination.

[Fred Ma]

Jerry Coffin wrote:

Difference ctors might need to initialize a
variable differently. As-is, the rule is consistent: non-static
members are initialized on the ctor. I doubt that the rules could be
kept nearly this consistent otherwise. Just for example, if you had
something like:

class X {
int x=0;
public:
X() : x(1) {}
};

how would you deal with it? Consider it ill-formed (keeping in mind
that the class definition will often be visible in places that the
ctor isn't)? Start with 0 and then assign 1? Start with 1 and then
assign 0? What would you do if (for example) instead of an int, this
was an instance of some other class that only supported initialization
and NOT assignment?

Ultimately, I suspect each of these questions _could_ be answered, but
doing so would probably lead to quite a few more. In the end, all the
questions might have answers, but I doubt anybody has gone to the
trouble of figuring out for sure -- most of the people on the
committee are pretty busy to start with, so in general, committee work
gets prioritized, and something that adds a lot of questions but
little or no new utility is likely to get quite a low priority.

Admittedly, this could be naive, but it seems to me to be
straightforward to avoid ambiguity without much to consider. The
compiler will flag an error if initialization is specified at both the
declaration and an initialization list. Hence, programmers can use
simultaneous declaration/initialization only for parameters for which
it makes sense (i.e. for variables which the author intended to be
unchangable). It seems preferable to having a static member, since
the value is right at the same location as the declaration.

If the data member wasn't an int, and didn't have an assignment
operator, just initialize it in the way that you would any object at
declaration:

class X
{
int x(0);
// ...
};

This is not to suggest that this idea will be welcome or noticed by
any significant number of people (or any at all), especially
overworked standards committe people. Just to say that there don't
seem to be any real difficulties with it.

Some might think it less clear to have the initialization value
separate from the constructor, but there are some parameters
for which it just makes sense for value to be readily apparent
when the variables declaration is seen. Mostly constants, or
near-constants. If the class definition is seen as a "table of
contents", or "map", of the class structure, it makes sense to have
those values right up front. Easier to look up compared to tucking it
away in constructors somewhere. And it simplifies the constructor's
initialization list.

Fred

[Andy Venikov]

<snip>

Some might think it less clear to have the initialization value
separate from the constructor, but there are some parameters
for which it just makes sense for value to be readily apparent
when the variables declaration is seen. Mostly constants, or
near-constants. If the class definition is seen as a "table of
contents", or "map", of the class structure, it makes sense to have
those values right up front. Easier to look up compared to tucking it
away in constructors somewhere. And it simplifies the constructor's
initialization list.

Fred

From the description of your needs it looks like what you're talking about is
something that is already allowed. Per-class constants. If you have a
static const member variable of an integral type you can initialize it
right in the class definition.

class A
{
static const int nClassID = 100;
};

Of course, you could always use enums.

Andy.

[Fred Ma]

Andy Venikov wrote:

<snip>

Some might think it less clear to have the initialization value
separate from the constructor, but there are some parameters
for which it just makes sense for value to be readily apparent
when the variables declaration is seen. Mostly constants, or
near-constants. If the class definition is seen as a "table of
contents", or "map", of the class structure, it makes sense to have
those values right up front. Easier to look up compared to tucking it
away in constructors somewhere. And it simplifies the constructor's
initialization list.

Fred

From the description of your needs it looks like what you're talking about is
something that is already allowed. Per-class constants. If you have a
static const member variable of an integral type you can initialize it
right in the class definition.

class A
{
static const int nClassID = 100;
};

Of course, you could always use enums.

For integers, yes. Unless there is the odd occassion when you
want to instantiate an object without the predefined value.
Then neither enum or static const would work. As well, when
using static const for non-ints, you have to define the physical
variable somewhere. Allowing simultaneous declaration/initialization
streamlines the code, prunes the sometimes lengthy initializer list,
and makes it simpler to look up the default value, which the user
can set differently (either by making it public, or through some
access member function -- both of these methods are available even
in the case of initializing the variable in constructor initialization
lists).

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada