Article View: comp.std.c++
Article #2178Re: Proposal for a new access specifier
From: Mike McCormick
Date: Thu, 12 Oct 1995 14:55
Date: Thu, 12 Oct 1995 14:55
62 lines
2856 bytes
2856 bytes
>From: schuenem@informatik.tu-muenchen.de (Ulf Schuenemann)
>Subject: Re: Proposal for a new access specifier
>Date: 10 Oct 1995 18:49:35 GMT
>Mike McCormick) writes:
>|> However, there is an alternative to changing the standard which I have
>|>not seen mentioned here yet. That is, public const pointers:
>|> class Thing :
>|> pReadOnly(&readOnly)
> ^^^^^^^^^^^^^^^^^^^^ - you mixed class and ctor.
>|> [snip]
Oops! The correct rendition would be:
class Thing:
{
private:
int readOnly;
public:
const int* const pReadOnly;
Thing();
};
Thing::Thing() : pReadOnly(&readOnly) {};
>Unfortunately, now every instance gets an additional pointer.
>If one could declare, that every ctor of Thing initializes
>pReadOnly the same way so that for every instance pReadOnly
>points to the same attribute, then pReadOnly could be optimized
>away (like global const).
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.
>This is an example where it would be usefull to be able to initialize
>not only static but also nonstatic datamembers inside the class defn.
> 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?
------------------------------------------------------------------
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. ]
Technical Details
Message-ID:
<MTM4.1250.01029391@rsvl.unisys.com>Path:
arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamageReferences:
<199509221547.JAA10782@ncar.ucar.EDU> <MATT.95Sep24112332@Austern> <44spqj$j37@nn.fast.net> <MTM4.1214.010BD7A3@rsvl.unisys.com> <45e5v6$3ac@sunsystem5.informatik.tu-muenchen.de>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews2.Eng.Sun.COM!taumet!clamage From: MTM4@rsvl.unisys.com (Mike McCormick) Newsgroups: comp.std.c++ Subject: Re: Proposal for a new access specifier Date: 12 Oct 1995 14:55:02 GMT Organization: Unisys Sender: news@rsvl.unisys.com (News Admin) Approved: clamage@eng.sun.com (comp.std.c++) Message-ID: <MTM4.1250.01029391@rsvl.unisys.com> References: <199509221547.JAA10782@ncar.ucar.EDU> <MATT.95Sep24112332@Austern> <44spqj$j37@nn.fast.net> <MTM4.1214.010BD7A3@rsvl.unisys.com> <45e5v6$3ac@sunsystem5.informatik.tu-muenchen.de> NNTP-Posting-Host: taumet.eng.sun.com Content-Type: text X-Nntp-Posting-Host: mtm4 X-Newsreader: Trumpet for Windows [Version 1.0 Rev B] Content-Length: 1821 X-Lines: 58 Originator: clamage@taumet