Simulatneous declare/initialize member variable

Discussion in 'C++' started by Fred Ma, May 31, 2004.

  1. Fred Ma

    Fred Ma Guest

    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
     
    Fred Ma, May 31, 2004
    #1
    1. Advertising

  2. "Fred Ma" <> 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
     
    Victor Bazarov, May 31, 2004
    #2
    1. Advertising

  3. Fred Ma

    Fred Ma Guest

    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
     
    Fred Ma, Jun 1, 2004
    #3
  4. Fred Ma

    qWake Guest

    "Fred Ma" <> wrote in message
    news:...
    > 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.
     
    qWake, Jun 1, 2004
    #4
  5. Fred Ma

    Fred Ma Guest

    qWake wrote:
    >
    > "Fred Ma" <> wrote in message
    > news:...
    > > 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
     
    Fred Ma, Jun 1, 2004
    #5
  6. 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
     
    Victor Bazarov, Jun 1, 2004
    #6
  7. Fred Ma

    qWake Guest

    "Fred Ma" <> wrote in message
    news:...

    > 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.
     
    qWake, Jun 1, 2004
    #7
  8. Fred Ma

    Jerry Coffin Guest

    Fred Ma <> wrote in message news:<>...
    > 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.
     
    Jerry Coffin, Jun 2, 2004
    #8
  9. Fred Ma

    Fred Ma Guest

    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
     
    Fred Ma, Jun 3, 2004
    #9
  10. Fred Ma

    Andy Venikov Guest

    <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.
     
    Andy Venikov, Jun 3, 2004
    #10
  11. Fred Ma

    Fred Ma Guest

    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
     
    Fred Ma, Jun 4, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David T. Ashley
    Replies:
    6
    Views:
    588
    Tim Rentsch
    Dec 5, 2004
  2. BillJosephson
    Replies:
    5
    Views:
    1,671
    Thomas Hawtin
    Dec 14, 2006
  3. Replies:
    3
    Views:
    892
    Peter_Julian
    Oct 10, 2005
  4. Replies:
    4
    Views:
    503
    benben
    May 14, 2006
  5. Replies:
    1
    Views:
    504
    mlimber
    May 9, 2007
Loading...

Share This Page