Read only data members can be written by member functions but can only
be read by clients.

I can think of two methods to implement it. A conventional one is to
get a `get' function to get the value of a private data
member. Another one is to leave the data member in the public, but
`const' and member functions need to un`const' it when assigning a new
value to it.

In some simulations there are lots of read only data members and both
methods are not satisfactory. Does the new standard of c++ supports
a more convenient way to express read only data members?

Thanks in advance,

Kingsum
--
// #include <standard_disclaimer>
//--------------------------------------
// Kingsum Chow (kingsum@ichips.intel.com)
// MRL JF3-359 (pole: JF3-3H9)
---
[ 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 <KINGSUM.96Oct11132152@mrl001.intel.com>, kingsum@mrl001.intel.com
says...

>I can think of two methods to implement it. A conventional one is to
>get a `get' function to get the value of a private data
>member. Another one is to leave the data member in the public, but
>`const' and member functions need to un`const' it when assigning a new
>value to it.

>In some simulations there are lots of read only data members and both
>methods are not satisfactory. Does the new standard of c++ supports
>a more convenient way to express read only data members?

Technically (inline) member functions are *very* satisfactory, IMHO.
If you are referring to the additional typing work, well, that's
basically not a language problem, is it? I can for example imagine
an editor macro generating selector member functions.

Regards,
Stefan
--
Stefan H. Holek <shh@iv.telecom.at>



























[ 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                             ]

Kingsum Chow wrote:
>
> Read only data members can be written by member functions but can only
> be read by clients.

A specific case of a "virtual object", a library that I'm working on...

> I can think of two methods to implement it. A conventional one is to
> get a `get' function to get the value of a private data
> member. Another one is to leave the data member in the public, but
> `const' and member functions need to un`const' it when assigning a new
> value to it.

This won't work with the upcoming standard that has mutable. const
members can't be modified legally. If they were declared mutable, then
users would be able to modify them too.

> In some simulations there are lots of read only data members and both
> methods are not satisfactory. Does the new standard of c++ supports
> a more convenient way to express read only data members?

The current standard supports it. The read-only case is very easy to
implement:

    class Person {
        string m_name;
    public:

        // normal functional-style
        string get_name() const { return m_name; }

        // "property"-style implemented on functional-style
        struct
        {
            const Person* owner;

            // should have private ctor, copy ctor, assignment
            // op, address-of, etc. Be sure copying of Person
            // sets owner correctly (i.e. not to the source)!

            operator string () const { return person->get_name(); }

        } name;

        Person() { name.owner = this; }
    };

I'm working on a library that allows read-only, write-only, or
read/write virtual objects that can be members of objects, or static,
easily declarable, efficient and portable, low-overhead, natural to use,
etc. So far, all of the above is implemented, using macros and
templates. I'm not sure how well it fits in with the language, but it
sure would seem to be clearer than a function call. I don't have enough
actual experience with using them to know what kind of issues will come
up. Time will tell...
--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ 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
]