>In article <2.2.32.19970617212410.002fe4cc@central.beasys.com>,
>david.tribble@central.beasys.com says...
>> Antonio Vieiro Varela <favieiro@uscmail.usc.es> wrote:
>> > ...
>> > I would like to propose the inclusion of a "public-const" feature.
>> > This could consist of a declaration of a public-member which
>> > could only be changed from inside a class' member functions.
>> > [example elided]
>>
>> What the 'public const private mutable' declaration does for you is
>> to allow your class to modify the member variable as it sees fit and
>> also allow clients of the class to read (but not modify) the member
>> variable.

danm@ziplink.net (Dan Muller) responded:
> Here's an easy way to do this using current language features:
>
> class foo
> {
> public:
>         foo();
>         const int& exposed_const;
> private:
>         int hidden_mutable;
> };
>
> foo::foo() : exposed_const(hidden_mutable)
> {
> }

Yes, that solution has been presented before and is what prompted the
discussion.  But what we want is something that doesn't require any extra
overhead; the solution above adds another word (a reference) to the class
size.  (Also, I don't trust references in general.)

The whole argument isn't about whether there's already is a way to do it or
not, but rather it's about adding a feature to the language to allow more
complicated but explicit access to member variables.  It's also, to a lesser
extent, a question of efficiency.

(The notion can be extended, of course, to other combinations such as
'public const protected mutable' and 'protected const private mutable'.)

--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk emailer@qlink2info.com
 simrem@answerme.com office@canma.dyn.ml.org markdan3@earthlink.net
 markdan@wans.net markdan@gte.net r_denterprise@hotmail.com
teamwork@1stfamily.com
 lvck1@hotmail.com peterson@dragonindustries.com bubbac@webconnect.com
 clover@earthfriends.com abuse@cyberpromo.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                             ]

In article <2.2.32.19970813004203.002c84d4@central.beasys.com>,
david.tribble@central.beasys.com says...
> >In article <2.2.32.19970617212410.002fe4cc@central.beasys.com>,
> >david.tribble@central.beasys.com says...
> >> Antonio Vieiro Varela <favieiro@uscmail.usc.es> wrote:
> >> > ...
> >> > I would like to propose the inclusion of a "public-const" feature.
> >> > This could consist of a declaration of a public-member which
> >> > could only be changed from inside a class' member functions.
> >> > [example elided]
> >>
> danm@ziplink.net (Dan Muller) responded:
> > Here's an easy way to do this using current language features:
> >
> > class foo
> > {
> > public:
> >         foo();
> >         const int& exposed_const;
> > private:
> >         int hidden_mutable;
> > };
> >
> > foo::foo() : exposed_const(hidden_mutable)
> > {
> > }
>
> Yes, that solution has been presented before and is what prompted the
> discussion.

Sorry, came in late.

>  But what we want is something that doesn't require any extra
> overhead; the solution above adds another word (a reference) to the class
> size.  (Also, I don't trust references in general.)

Strictly speaking, whether there is additional overhead or not is up to
the compiler. References don't in general require it, but in practice the
example would probably incur it.

What don't you trust about references? I use them frequently, and haven't
run into anything particularly tricky about their application.

> The whole argument isn't about whether there's already is a way to do it or
> not, but rather it's about adding a feature to the language to allow more
> complicated but explicit access to member variables.  It's also, to a lesser
> extent, a question of efficiency.

But your goals are easily achieved using current language features and
only slight modification to programming practice. A no-overhead solution
is to use inline accessor member functions. I very rarely expose any data
members, having become accustomed to using accessors. This is really very
little bother once you're used to it, and it is more flexible; values
returned by accessors can be actual data members, or computed values.
During the lifetime of a class, this implementation detail may even
change without disturbing client code.

Since I came into this conversation late, I apologize if I'm rehashing
old themes.

> (The notion can be extended, of course, to other combinations such as
> 'public const protected mutable' and 'protected const private mutable'.)

Quite do-able with accessor member functions.

--
Dan Muller   danm@ziplink.net
http://www.ziplink.net/~danm
---
[ 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 <2.2.32.19970617212410.002fe4cc@central.beasys.com>,
david.tribble@central.beasys.com says...
> Antonio Vieiro Varela <favieiro@uscmail.usc.es> wrote:
> > ...
> > I would like to propose the inclusion of a "public-const" feature.
> > This could consist of a declaration of a public-member which
> > could only be changed from inside a class' member functions.
> > [example elided]
>
> What the 'public const private mutable' declaration does for you is
> to allow your class to modify the member variable as it sees fit and
> also allow clients of the class to read (but not modify) the member
> variable.
>

Here's an easy way to do this using current language features:

class foo
{
public:
 foo();
 const int& exposed_const;
private:
 int hidden_mutable;
};

foo::foo() : exposed_const(hidden_mutable)
{
}


--
Dan Muller   danm@ziplink.net
http://www.ziplink.net/~danm
---
[ 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 <2.2.32.19970617212410.002fe4cc@central.beasys.com>, David R
Tribble <david.tribble@central.beasys.com> wrote:
>There are those of us, however,
>who abhor the idea of placing code in header files.

I also prefer not to put code in a header.  But I can live with
        int X(){ return x};

>Some of us don't
>like the idea of declaring private class members in header file

I share your distaste for declaring private members in the header file, but
I don't see how your proposal solves this problem.  You are still declaring
the variable in the header file.

>Eiffel and Java prove that you don't have to declare things
>in one place (a header file) and define them in another place (the
>implementation file).  True data hiding means that your private data
>really is hidden from the clients of your classes; they should see only
>the public interface for your class and nothing else.

For Mr. Stoustrup's thoughts on this topic, see THE DESIGN AND EVOLUTION OF
C++, sections 2.5 and 13.2

>Having to resort to functions to do this appears like a work-around of a
>language deficiency, if you ask me.

I look at it the other way around:  why add a new feature when the same
thing can be done with an existing feature?  That seems to be a guiding
philosiphy among C++'s authors.  Inline member functions give the same
benefits (and more) as your proposal, with the only cost being placing a
single line of code into a header file.  It seems to me that adding a whole
new language feature, just to avoid the distastefulness of putting a one
line function into a header file, is overkill.
---
[ 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                             ]

Antonio Vieiro Varela <favieiro@uscmail.usc.es> wrote:
> ...
> I would like to propose the inclusion of a "public-const" feature.
> This could consist of a declaration of a public-member which
> could only be changed from inside a class' member functions.
> It could be something like this
>
> class AClass
> {
>   public: "public-const" int amember;
>   public: AClass( int X ):amember(X) {};
>   public: void change(int X) {amember=X;}; // Ok. Changing
>                                            // from inside class
> };
>
> Or maybe there's a more elegant way to do this?

What the 'public const private mutable' declaration does for you is
to allow your class to modify the member variable as it sees fit and
also allow clients of the class to read (but not modify) the member
variable.

I thought of this very same idea about two years ago and bounced the
idea off a few people.  I got at best a lukewarm reception to the idea.

There are two sides of this issue (based on the responses I got when I
discussed the idea with other programmers way back when).  One side,
the purists, say that the only correct way to access a member variable
is to use a (public) member 'accessor' function, and that having public
member variables is a bad thing.  The other side (the side I'm on) says
that that's fine, but it's equivalent to having read-only public member
variables in most cases.

In fact, in languages like Eiffel, an accessor function taking no args
and a member variable both have the same syntax, with the empty function
parentheses being optional (the expression 'object.attrib' is the same
whether 'attrib' is a variable or a function with no args).  One of the
advantages to this is that if you change the variable to an accessor
function, none of the client source code needs to be changed.  (I believe
that allowing optional parentheses on zero-arg funcs was actually
discussed for C++ some time ago.)

The purists also argue that providing efficient member accessor functions
is easily done using inline functions.  There are those of us, however,
who abhor the idea of placing code in header files.  Some of us don't
like the idea of declaring private class members in header files, leaving
them in full view of clients who have no business seeing the private
parts of our classes.  And some of us even think that having header files
is a bad idea; Eiffel and Java prove that you don't have to declare things
in one place (a header file) and define them in another place (the
implementation file).  True data hiding means that your private data
really is hidden from the clients of your classes; they should see only
the public interface for your class and nothing else.

And that's all accessor functions try to do, is to limit access to private
data.  But why use functions when you could enhance the language to
enforce 'public const private mutable' access to member variables?
In this case, you're purposely allowing the clients to have access
(albeit read-only access) to and knowledge of one or more member variables.
Having to resort to functions to do this appears like a work-around of a
language deficiency, if you ask me.

--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
---
[ 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
]