🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2178

Re: Proposal for a new access specifier

#2178
From: Mike McCormick
Date: Thu, 12 Oct 1995 14:55
62 lines
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!clamage
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>

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