In article <rickr-090294090631@rickr.khis.com> rickr@khis.com (Rick Ratliff) writes:
>If some kind soul would like to respond, I would be much obliged.
>
>Yesterday, in a design meeting that got a little too deep into
>implementation, someone asked if a const data member was treated like a
>static data member by the compiler.
>
>It would seem that the compiler could know that since the data member could
>not be changed it is not necessary to allocate space for it in every
>instantiation.

IMHO, it is not the responsibility of the compiler to infer the programmer's
intentions.

If you want the member to be static, you should declare it as being static.

Having been burned (on a number of occasions) by compilers that were just
a wee bit too smart for my own good, I (for one) now prefer implementations
which do not try to jump to too many conclusions regarding what I am trying
to accomplish.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <rickr-090294090631@rickr.khis.com> rickr@khis.com (Rick Ratliff) writes:
>Yesterday, in a design meeting that got a little too deep into
>implementation, someone asked if a const data member was treated like a
>static data member by the compiler.
>
>It would seem that the compiler could know that since the data member could
>not be changed it is not necessary to allocate space for it in every
>instantiation.

In article <rickr-090294090631@rickr.khis.com>,
Rick Ratliff <rickr@khis.com> wrote:
>If some kind soul would like to respond, I would be much obliged.
>
>Yesterday, in a design meeting that got a little too deep into
>implementation, someone asked if a const data member was treated like a
>static data member by the compiler.
>
>It would seem that the compiler could know that since the data member could
>not be changed it is not necessary to allocate space for it in every
>instantiation.
>

 The value that the const data member has in that instance of the class
cannot be changed. That does not mean that different instances of that class
must have the same value for that member.
 -- Pete

In article <rickr-090294090631@rickr.khis.com>,
Rick Ratliff <rickr@khis.com> wrote:
>If some kind soul would like to respond, I would be much obliged.
>
>Yesterday, in a design meeting that got a little too deep into
>implementation, someone asked if a const data member was treated like a
>static data member by the compiler.
>
>It would seem that the compiler could know that since the data member could
>not be changed it is not necessary to allocate space for it in every
>instantiation.
>
>I will be looking in the ARM, in the hopes that I can stumble across the
>answer for myself.
>

const data members are not static... contrary to your statement, it
is necessary to allocate storage for const members for each instance,
since different instances can give this const member a different value.
e.g.

     class Glorp {
       int x;
       const int y;
     public:
       Glorp(int cx, int cy) : x(cx), y(cy) { }
       // etc.
     }

Note how the constructor initializer gives 'y' an initial value each
time this constructor is invoked.

The only thing 'const' means for a nonstatic member is that its value
can't be changed *after* initialization.

--
       ___       _
   | __\_\_o____/_|            ,---------------------------,
   <[___\_\_-----< ------------|          ++don;           |
   |  o'                       `---------------------------'

If some kind soul would like to respond, I would be much obliged.

Yesterday, in a design meeting that got a little too deep into
implementation, someone asked if a const data member was treated like a
static data member by the compiler.

It would seem that the compiler could know that since the data member could
not be changed it is not necessary to allocate space for it in every
instantiation.

I will be looking in the ARM, in the hopes that I can stumble across the
answer for myself.

Rick Ratliff                               | "...if we travel by
Objective Software Solutions, Inc.         | dragonfly" -- Jimi Hendrix
P.O. Box 974, Rowlett, Texas 75030-0974    |
(214) 412-5419                             | Opinions expressed are mine
e-mail: rickr@khis.com                     | and not those of KHIS.
on contract @ Kodak Health Imaging Systems |