Frederick Gotham wrote:
> If one wants to have a non-const member object within a class, but also for
> that object to appear const to the outside world, they might do something
> like:
>
> Example (1):
>
>     template<class T>
>     class Arb {
>     private:
>
>         T obj;
>
>     public:
>
>         T const &Obj() const { return obj; }
>     };
>
> Example (2):
>
>     template<class T>
>     class Arb {
>     private:
>
>         T objNC;
>
>     public:
>
>         T const &obj;
>
>         Arb() : obj(objNC) {}
>     };
>
>
> Maybe it would be nice if we could specify that a member object should be
> non-const within the class, but appear const to the outside world...

The problem is that if the code in "outside world" believes that the
member was declared const, then that code is likely to check its value
only once (since the value of a const member does not change). But
since the data member's value could change (it's not really a const
data member after all) then there is a good chance that any change to
its value would not propagate to the outside world.

Moreover, this problem already has a much better solution: a class
should provide methods to mediate client access to its data members -
while declaring those data members private.

Sometimes standard practice is the best practice.

Greg

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy posted:

> The problem is that if the code in "outside world" believes that the
> member was declared const, then that code is likely to check its value
> only once (since the value of a const member does not change). But
> since the data member's value could change (it's not really a const
> data member after all) then there is a good chance that any change to
> its value would not propagate to the outside world.


They would be treated as volatile by the outside.


> Moreover, this problem already has a much better solution: a class
> should provide methods to mediate client access to its data members -
> while declaring those data members private.


It's unnatural to use a function to access an object.


> Sometimes standard practice is the best practice.


Rarely.

--

Frederick Gotham

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Frederick Gotham wrote:
> > Maybe it would be nice if we could specify that a member object should be
> > non-const within the class, but appear const to the outside world...

Greg Herlihy wrote:
> The problem is that if the code in "outside world" believes that the
> member was declared const, then that code is likely to check its value
> only once (since the value of a const member does not change). But
> since the data member's value could change (it's not really a const
> data member after all) then there is a good chance that any change to
> its value would not propagate to the outside world.

And here we demonstrate that "const" really has two different meanings
inside of C++:

1) The value never changes.
This happens when an object is declared const:

    const int abc = 1;

The compiler can even optimize this, so that

    x += abc;
turns into
    ++x;

2) Client code is not allowed to change the value.
This happens when a reference is const:

    void foo(const int &value) {
        int x = value;
        // ...
        if (x==value) {
            // Cannot optimize this away...
            // Even though foo can't change value,
            // it's still possible for value to change.
        }
        //++value; // But this would be illegal!
    }
Possibly "readonly" would be a better name for this usage?
(This isn't a proposal... much too late to put this in C++, unless
we get "properties"... this is just a "wouldn't it have been nice"...)

I think that Frederick Gotham clearly wanted to express that a member
is "readonly" to clients, as opposed to truely const.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

AllanW posted:

> 2) Client code is not allowed to change the value.
> This happens when a reference is const:
>
>     void foo(const int &value) {
>         int x = value;
>         // ...
>         if (x==value) {
>             // Cannot optimize this away...
>             // Even though foo can't change value,
>             // it's still possible for value to change.
>         }
>         //++value; // But this would be illegal!
>     }
> Possibly "readonly" would be a better name for this usage?


The already have it in C99 -- it's called "restrict":

    int const *const restrict p;

A const pointer to a const object whose value won't change within the
lifetime of "p" -- therefore it can be optimised. In your above snippet,
the "if" statement could have been optimised away if a restrict pointer
were to be used.

I might consider starting to use restrict; I think some compilers may
provide it in anyway (as most C++ compilers are also C compilers). If I
come across a compiler which doesn't support restrict, I can always write:

    #define restrict /* Nothing */


> (This isn't a proposal... much too late to put this in C++, unless
> we get "properties"... this is just a "wouldn't it have been nice"...)
>
> I think that Frederick Gotham clearly wanted to express that a member
> is "readonly" to clients, as opposed to truely const.


Indeed.

--

Frederick Gotham

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> Maybe it would be nice if we could specify that a member object should be
> non-const within the class, but appear const to the outside world...
> perhaps by combining "const" and "export":
>
>     template<class T>
>     class Arb {
>     public:
>
>         T const export obj;
>
>         void Func()
>         {
>             obj = 6; /* No problem */
>         }
>     };
>
>     int main()
>     {
>         Arb obj;
>
>         obj.obj = 6; /* Compile ERROR: const violation */
>     }
>
> Perhaps this could be extended to such elaborate definitions as:
>
>     T const export *const export obj;
>
>     T const export *const obj;
>
>     T *const export obj;
>
>     T const export *obj;
>

Excuse me; But I found it ridiculous...
That's an encapsulation flaw, anyway.
A much better alternative would be to provide an accessor!

And, if you really want to change the language... You'd better propose
properties.
Properties give all the syntaxic sugar you want, and a much better
encapsulation.
And even much more syntaxic sugar.

Though, personally, I think that even properties don't worth the
language change.
I find that.

my_obj.my_field(4);
int i=my_obj.my_field();

Is as good as:

my_obj.my_field=4;
int i=my_obj.my_field;

And, it is even possible to make accessors return a reference to *this

my_color.red(42).green(68).blue(4);

Is more compact, and pretty than:

my_color.red=42;
my_color.green=68;
my_color.blue=4;

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

If one wants to have a non-const member object within a class, but also for
that object to appear const to the outside world, they might do something
like:

Example (1):

    template<class T>
    class Arb {
    private:

        T obj;

    public:

        T const &Obj() const { return obj; }
    };

Example (2):

    template<class T>
    class Arb {
    private:

        T objNC;

    public:

        T const &obj;

        Arb() : obj(objNC) {}
    };


Maybe it would be nice if we could specify that a member object should be
non-const within the class, but appear const to the outside world...
perhaps by combining "const" and "export":

    template<class T>
    class Arb {
    public:

        T const export obj;

        void Func()
        {
            obj = 6; /* No problem */
        }
    };

    int main()
    {
        Arb obj;

        obj.obj = 6; /* Compile ERROR: const violation */
    }

Perhaps this could be extended to such elaborate definitions as:

    T const export *const export obj;

    T const export *const obj;

    T *const export obj;

    T const export *obj;

--

Frederick Gotham

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]