🚀 go-pugleaf

In article <pu7n2almo7.fsf@themroc.colibri.de> hf@colibri.de (Harald Fuchs) writes:

>MTM4@rsvl.unisys.com (Mike McCormick) writes:
>> I probably misunderstand, but this sounds like an issue only if
>> readOnly is static.  Since it is not, every Thing instance has its
>> own readOnly, so every instance must have pReadOnly also.

>No, assuming pReadOnly always points to this->readOnly.  Since in this
>case the offset from "this" is fixed, and since every object has a
>(different) "this" anyway, you could treat pReadOnly as "this+offset"
>and thus optimize it away.

Okay, now I understand.  I must say however that I am uncomfortable with using 
static pointers to volatile members and relying on the compiler to always put 
things at the same offset within every instance.  OTOH I suppose the 
standard requires C++ compilers to do that?

>>> class Thing {>>> private:
>>> int readOnly;
>>> public:
>>> const int* const pReadOnly =&readOnly; // ILLEGAL
>>> };

>> Just supposing this *were* legal syntax, how is it an improvement over the 
>> constructor initializer syntax?

>A class might have _lots_ of different constructors.  It's "tedious and
>error-prone" (as Bjarne would say :-) to repeat thie initialization in
>all of them.

True.  This argument gets me partway toward overcoming my distaste for the 
static pointer to a volatile member too.  Thanks....

------------------------------------------------------------------
 Mike McCormick
 mtm4@rsvl.unisys.com
 m.mccormick2@genie.geis.com
------------------------------------------------------------------
 While you're out surfing the internet...
 I'm back on the beach blowing my little lifeguard whistle.
------------------------------------------------------------------

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]