Ross Smith <ross.smith@nz.eds.com> writes:

|>  Steve Clamage wrote:
|>  >
|>  > An exception to this principle was made recently for static const
|>  > data members of integral or enum type. There is exactly one instance
|>  > of such a data member, and its value cannot vary during the run of the
|>  > program (without invoking undefined behavior). Allowing member const
|>  > values seemed useful enough to justify bending the semantics a bit.
|>  > Example:
|>  >         class myClass {
|>  >                 static const int size = 100;
|>  >                 int arr[size];
|>  >         public:
|>  >                 ...
|>  >         };
|>  > Getting this useful effect required odd workarounds before the language
|>  > change.
|>  > NB: You still have to provide a definition of the static member in one
|>  > place in your program:
|>  >         const int myClass::size; // without an initializer
|>
|>  Hang on -- Why bother with the new syntax then?
|>
|>  I thought the whole point of this change was to make it possible to put
|>  static constants in "header only" classes without making a separate
|>  source file necessary. If you still can't do that, what advantage is the
|>  new syntax supposed to give?

Not at all.  The whole point is to allow such constants to be used in
"integral constant expressions".  Integral constant expressions are
required in several places, like the dimensions of an array.

|>  (And it's still a complete mystery to me why it was restricted to
|>  integers.)

Because other types cannot occur in "integral constant expressions".

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

<< It allows you to both declare and use the value of the constant
within the class declaration. >>

That is in itself useful. Anyway, I think it is clearer having the value
in the header file.

However, I would still agree with the basic thrust of Ross's post. If it
is possible to define the value in the class header, why cannot the
actual definition of the object be implied as well? Something of the
sort is possible for template code, so why not simple static constants?

Dominic
Bruxelles, Fri, 07 Feb 1997 08:09 +0100
also cis:106136,2400
using Virtual Access 3.52 build 159c (32-bit)
on WinNT build 1057 (3.51)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Given the following simple example,

#include <iostream.h>

class Test {
private:
                int counter_ = 314;  // Not legal in ANSI C++
public:
                char choice_ = '!';  // Not legal in ANSI C++

                void displayInfo();
};

inline void Test::displayInfo() {
                cout << "counter_ = " << counter_ << endl;
                cout << "choice_  = " << choice_ << endl;
}

Test o1;

int main() {
                o1.displayInfo();
                return 0;
}

and the following warnings/errors:

talk[18]% g++ objPrivPubInit.cc
objPrivPubInit.cc:5: warning: ANSI C++ forbids initialization
of member `counter_'
objPrivPubInit.cc:7: warning: ANSI C++ forbids initialization
of member `choice_'
OUTPUT:
talk[22]% a.out
counter_ = 314
choice_  = !


talk[20]% CC objPrivPubInit.cc
"objPrivPubInit.cc", line 5: Error: A member cannot be
initialized except in a constructor.
"objPrivPubInit.cc", line 6: Error: Use ";" to terminate declarations.
"objPrivPubInit.cc", line 7: Error: A member cannot be
initialized except in a constructor.
"objPrivPubInit.cc", line 9: Error: Use ";" to terminate declarations.
4 Error(s) detected.

what is the reason for ANSI C++ not letting us initialize variables
in the declaration?
Is it 1)  Since a class is a declaration (i.e., it doesn't take up any
memory), we cannot initialize variables (i.e., storing variables in non
allocated memory), or
2) make C++ standardized to handle virtual functions, templates in a
generic fashion (wild guess).

Any insight would be greatly appreciated,
 Thorsten

Ps: I understand that a constructor is the correct way to go.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 41C67EA6@cs.nmsu.edu, SANDGREN <tsandgre@cs.nmsu.edu> writes:
>Given the following simple example,
>
>class Test {
>private:
>                int counter_ = 314;  // Not legal in ANSI C++
> ...
>
>what is the reason for ANSI C++ not letting us initialize variables
>in the declaration?
>
>Ps: I understand that a constructor is the correct way to go.

In the example, "counter_" is not a variable (object). It is a
component of a type. At the point where you try to write
 int counter_ = 314;
there is no object "counter_" to initialize. Indeed, the declaration
does not specify any object of any kind, but only a type. (In C++,
types are not objects, although other languages differ.)

When you create a Test object, you can specify initial values for
its components via constructors.

An exception to this principle was made recently for static const
data members of integral or enum type. There is exactly one instance
of such a data member, and its value cannot vary during the run of the
program (without invoking undefined behavior). Allowing member const
values seemed useful enough to justify bending the semantics a bit.
Example:
 class myClass {
  static const int size = 100;
  int arr[size];
 public:
  ...
 };
Getting this useful effect required odd workarounds before the language
change.
NB: You still have to provide a definition of the static member in one
place in your program:
 const int myClass::size; // without an initializer

Allowing the same for non-const or non-static data members would
introduce opportunities for inconsistent code with little advantage.
---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
>
> An exception to this principle was made recently for static const
> data members of integral or enum type. There is exactly one instance
> of such a data member, and its value cannot vary during the run of the
> program (without invoking undefined behavior). Allowing member const
> values seemed useful enough to justify bending the semantics a bit.
> Example:
>         class myClass {
>                 static const int size = 100;
>                 int arr[size];
>         public:
>                 ...
>         };
> Getting this useful effect required odd workarounds before the language
> change.
> NB: You still have to provide a definition of the static member in one
> place in your program:
>         const int myClass::size; // without an initializer

Hang on -- Why bother with the new syntax then?

I thought the whole point of this change was to make it possible to put
static constants in "header only" classes without making a separate
source file necessary. If you still can't do that, what advantage is the
new syntax supposed to give?

(And it's still a complete mystery to me why it was restricted to
integers.)

--
Ross Smith .................................... Wellington, New Zealand
Webmaster, EDS (New Zealand) Ltd ....... <mailto:ross.smith@nz.eds.com>
     "I'm as interested as anybody else in all the things no decent
     person would be interested in."          -- Ashleigh Brilliant
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <199702050419.RAA05587@gonzo.lab.nz.eds.com>, Ross Smith
<ross.smith@nz.eds.com> wrote:
>Steve Clamage wrote:
>> NB: You still have to provide a definition of the static member in one
>> place in your program:
>Hang on -- Why bother with the new syntax then?

It allows you to both declare and use the value of the constant within
the class declaration.  For example, you can use it to declare the size
of an array within the class.  Before this change, if you wanted to use
an identifier to specify the size of a member array, you had to either

a) Declare the identifier outside the class.  For example

        static const int size = 100;
        class myClass {
                int arr[size];
        public:
                 ...
        };

b) Use an enumerator constant.  For example

        class myClass {
                enum { size =100 );
                int arr[size];
        public:
                 ...
        };

The new syntax allows you to keep the constant visible only within the class,
without resorting to using an enum to imitate a const int
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]