Public attributes: R/W within class, R/O outside class

[,]

Is there a way to make a class attribute public in a way that it can be read
or written from within its class, but only read from outside the class?

I'm looking for a way other than making it private and accessing via
accessor methods.

Thanks...

 

[Bo Persson]

Is there a way to make a class attribute public in a way that it
can be read or written from within its class, but only read from
outside the class?
I'm looking for a way other than making it private and accessing via
accessor methods.

Thanks...

Why? That is the way to do it.


Bo Persson

 

[Rolf Magnus]

Is there a way to make a class attribute public in a way that it can be
read or written from within its class, but only read from outside the
class?

Maybe something like this:

class Foo
{
public:
Foo(int arg)
: val_(arg),
value(val_)
{}

void func()
{
// ... some code
val_ = 5;
}

const int& value;

private:
int val_;
};

But I would prefer...

I'm looking for a way other than making it private and accessing via
accessor methods.

.... those. What problem do you have with accessors?

 

[Öö Tiib]

Is there a way to make a class attribute public in a way that it can be read
or written from within its class, but only read from outside the class?

I'm looking for a way other than making it private and accessing via
accessor methods.

Thanks...

Declare the member public: const. At rare places where you want to
write it use const_cast. I have done it to private members to signal
myself that changing particular member needs extra caution. Not sure
why you hate accessor methods ... however.

 

[Öö Tiib]

It is undefined behaviour to cast away const and write to something which
has been defined to be const so don't do it.

By reading standard you are correct. In real world since const member
is dynamically initialized in member initializer list and may be
different for each instance there are nothing const about it other
than its declaration. Even better, initialization is mandatory, so you
get compiler errors when you do not initialize such members.

Solve your problem by providing read only (const) getter functions.

I had no problem. Const private members and const_casting them where
needed works fine on all compilers i have seen. Such effect cannot be
achieved with getter anyway. But strictly speaking you are correct
that i violate standard there.

 

[Ian Collins]

By reading standard you are correct. In real world since const member
is dynamically initialized in member initializer list and may be
different for each instance there are nothing const about it other
than its declaration. Even better, initialization is mandatory, so you
get compiler errors when you do not initialize such members.


I had no problem. Const private members and const_casting them where
needed works fine on all compilers i have seen. Such effect cannot be
achieved with getter anyway. But strictly speaking you are correct
that i violate standard there.

Not only that, it's both unnecessary and really really gross!

 

[Öö Tiib]

I would hate to have to maintain your code, you need to learn about proper
const correctness.

Actually my code is always as const correct as possible. Funny thing
is that the very habit i gained because of clueless maintainers.
Classes have sometimes members that should change only under limited
conditions. That often means only in single member function that
arranges the conditions. Simple private is usually enough however.
Then maintainer with green fingers did come and screw it up by adding
setters and modifying it at wrong places. All went boom. Then i was
asked to review the mess. So what else one can to do but to declare it
const private? Like Ian there said: "it looks gross". Gross things
scare away clueless and that is good. So i usually declare critical
members that i do not want someone to change without thinking as
const.

 

[Ian Harvey]

Is there a way to make a class attribute public in a way that it can be read
or written from within its class, but only read from outside the class?

I'm looking for a way other than making it private and accessing via
accessor methods.

If it is the appearance of the accessor methods in client code that is
bothering you (versus the need to write the accessor methods
themselves), then perhaps something like the following?

template<
class T, // Type being wrapped.
class P > // Parent class to be allowed access.
class ReadOnly
{
public:
ReadOnly(const T& param) : value_(param) { }

operator T () const { return value_; }

private:
ReadOnly& operator = (const T& param)
{
value_ = param;
return *this;
}

T value_;
friend typename P;
};

class ParentType
{
public:
ParentType(int param) : my_value(param) { }

/// Object that can be read, but not written outside Parent.
ReadOnly<int, ParentType> my_value;

void OtherFn() { my_value = 2; }
};

#include <iostream>

int main()
{
ParentType a(1);
std::cout << a.my_value << std::endl;
a.OtherFn();
std::cout << a.my_value << std::endl;
//a.my_value = 3; /// Error.
return 0;
}

 

[Jorgen Grahn]

Maybe something like this:

class Foo
{
public:
Foo(int arg)
: val_(arg),
value(val_)
{}

void func()
{
// ... some code
val_ = 5;
}

const int& value;

private:
int val_;
};

I have done that once or twice. But you must forbid copying of Foo,
or you'll get a nasty surprise when foo.value suddenly becomed the
same thing as bar.val_, not foo.val_.

But I would prefer...


... those. What problem do you have with accessors?

Can't speak for him, but I find them ugly when I really want the
outside world to just see something "struct-like but unchangeable".

Not so ugly that I avoid them at all cost, but it would have been
nice if there had been a natural way in the language to say
"public-but-const".

/Jorgen

 

[Jorgen Grahn]

.

Like Ian there said: "it looks gross". Gross things
scare away clueless and that is good.

"Gross" means roughly "very ugly" or "the idea makes me sick", not
"advanced" or "elegant".

Think again. The people with a clue, not the clueless ones, will be
the ones who react most violently to gross code.

So i usually declare critical
members that i do not want someone to change without thinking as
const.

As you express it here, that's a good policy.

/Jorgen