assignment operator for classes with const data

[scroopy]

Is it impossible in C++ to create an assignment operator for classes
with const data? I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

return *this;
}

thanks

[Gavin Deane]

scroopy wrote:

Is it impossible in C++ to create an assignment operator for classes
with const data?

It is not impossible to create an assignment operator for a class with
const data, but it is impossible to assign new values to the const
member(s) within the assignment operator just as it is impossible to
assign new values to any const object at any other time. const is for
situations where an object's value will not change over its entire
lifetime.

I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

Not allowed for obvious reasons I hope.

return *this;
}

Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?

Gavin Deane

[scroopy]

On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:

>
scroopy wrote:

>Is it impossible in C++ to create an assignment operator for classes
with const data?

It is not impossible to create an assignment operator for a class with
const data, but it is impossible to assign new values to the const
member(s) within the assignment operator just as it is impossible to
assign new values to any const object at any other time. const is for
situations where an object's value will not change over its entire
lifetime.

>I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

Not allowed for obvious reasons I hope.

> return *this;
}

Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

>
Gavin Deane

[peter koch]

scroopy wrote:

On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:

scroopy wrote:

Is it impossible in C++ to create an assignment operator for classes
with const data?

It is not impossible to create an assignment operator for a class with
const data, but it is impossible to assign new values to the const
member(s) within the assignment operator just as it is impossible to
assign new values to any const object at any other time. const is for
situations where an object's value will not change over its entire
lifetime.

I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

Not allowed for obvious reasons I hope.

return *this;
}

Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

This is not assignment, but copy construction:

MyClass::MyClass(const MyClass& mc): m_iValue(mc.m_iValue) {...}

This will enable you to write

MyClass c1;
MyClass c2 = c1;

/Peter

>

Gavin Deane

[Gavin Deane]

scroopy wrote:

On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:

scroopy wrote:

<snip>

I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

Not allowed for obvious reasons I hope.

return *this;
}

Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

You seem to be confusing assignment and creation. The assignment
operator never has anything to do with object creation. That's the job
of constructors. Construction of a brand new object and assignment of a
new value to an exisiting object are completely different things. Using
your code above

MyClass object1(3);
will create an object called object1 using the constructor that takes
an int.

MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.

object3 = object4;
assuming object3 and object4 are of type MyClass this code is how you
would assign a new value to object3 if an assignment operator existed
for MyClass.

Gavin Deane

[Frederick Gotham]

scroopy posted:

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

Congratulations on talking absolute gibberish.

If you want an object to be const, yet to be non-const solely within the
assignment operator member function body, then maybe try something like:

class Arb {
private:

int objNC;

public:

int const &obj;

public:

Arb() : obj(objNC) {}

Arb &operator=(Arb const &rhs)
{
objNC = rhs.objNC;
}
};
int main()
{
Arb obj1,obj2;

obj1 = obj2; /* OK */

obj1.obj = 56; /* Compile ERROR */
}
--

Frederick Gotham

[Axter]

Gavin Deane wrote:

scroopy wrote:

On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:

>
>scroopy wrote:

<snip>

>I want to do something like this
>>
>class MyClass
>{
> const int m_iValue;
>>
>public:
>>
> MyClass(int iVal):m_iValue(iVal){}
>>
> MyClass operator=(const MyClass& mc)
> {
> m_iValue = mc.m_iValue; //not allowed
>
>Not allowed for obvious reasons I hope.
>
> return *this;
> }
>
>Your design seems confused. The obvious solution is not to declare
>m_iValue const in the first place if its value is going to change. But
>presumably you had a reason for declaring it const in the first place.
>You can declare it const or you can change its value in the assignment
>operator but you can't do both. Which choice fits your design?

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

You seem to be confusing assignment and creation. The assignment
operator never has anything to do with object creation. That's the job
of constructors. Construction of a brand new object and assignment of a
new value to an exisiting object are completely different things. Using
your code above

MyClass object1(3);
will create an object called object1 using the constructor that takes
an int.

MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.

The second way is actually a call to the assignment operator, and not
the copy constructor.
Many compilers, like VC++, will optimize away the assignment operator
call, so all you get is the copy constructor call.
But not all compilers will do that, and it's not required by the
standard.

[Pete Becker]

Axter wrote:

Gavin Deane wrote:

>>
MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.

The second way is actually a call to the assignment operator, and not
the copy constructor.

No. It constructs object1, then uses it as the argument to the copy
constructor to construct object2. It is initialization, not assignment.

[Gavin Deane]

Axter wrote:

Gavin Deane wrote:

MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.

The second way is actually a call to the assignment operator, and not
the copy constructor.
Many compilers, like VC++, will optimize away the assignment operator
call, so all you get is the copy constructor call.
But not all compilers will do that, and it's not required by the
standard.

Is there some misunderstanding here?

T a = b;

where b is of type T, is copy initialisation of a. It isn't assignment
and does not require an assignment operator to exist for type T.

class T
{
private:
// Make assignment operator inaccessible
T& operator=(const T&);
};

int main()
{
T b;
T a = b;
}

Gavin Deane

[Stuart Golodetz]

"Axter" <go****@axter.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

Gavin Deane wrote:

>scroopy wrote:

On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:
scroopy wrote:

<snip>

>I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

Not allowed for obvious reasons I hope.

return *this;
}

Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?

II want the value to be assigned upon object creation but remain const
throughout the lifetime.

You seem to be confusing assignment and creation. The assignment
operator never has anything to do with object creation. That's the job
of constructors. Construction of a brand new object and assignment of a
new value to an exisiting object are completely different things. Using
your code above

MyClass object1(3);
will create an object called object1 using the constructor that takes
an int.

MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.

The second way is actually a call to the assignment operator, and not
the copy constructor.
Many compilers, like VC++, will optimize away the assignment operator
call, so all you get is the copy constructor call.
But not all compilers will do that, and it's not required by the
standard.

As far as I can tell, you're a tad confused. The relevant bit from the
standard (well, the draft version of it, anyway, which is all I have to
hand - something like this will likely be very similar in the real thing)
reads:

***
(extract from 8.5)

If the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source type is
the same class as, or a derived class of, the class of the destination,
constructors are considered. The applicable constructors are enumerated
(13.3.1.3), and the best one is chosen through overload resolution (13.3).
The constructor so selected is called to initialize the object, with the
initializer expression(s) as its argument(s). If no constructor applies, or
the overload resolution is ambiguous, the initialization is ill-formed.

Otherwise (i.e., for the remaining copy-initialization cases), a temporary
is created. User-defined conversion sequences that can convert from the
source type to the destination type or a derived class thereof are
enumerated (13.3.1.4), and the best one is chosen through overload
resolution (13.3). The user-defined conversion so selected is called to
convert the initializer expression into a temporary, whose type is the type
returned by the call of the user-defined conversion function, with the
cv-qualifiers of the destination type. If the conversion cannot be done or
is ambiguous, the initialization is ill-formed. The object being initialized
is then direct-initialized from the temporary according to the rules
above.87) In certain cases, an implementation is permitted to eliminate the
temporary by initializing the object directly; see 12.2.
***

In other words (i.e. less precisely but hopefully more lucidly):

MyClass object2 = object1;

is an example of copy-initialization where the cv-unqualified version of the
source type (i.e. MyClass) is the same class as the class of the
destination. In this case, as the first paragraph above makes clear,
constructors are considered. In other words, the copy constructor will get
invoked in this instance, *not* the assignment operator.

The second paragraph seems to be the source of your confusion, but note that
even there it talks about the object being *initialized*, not assigned to.

Hope this helps,
Stu

[LR]

scroopy wrote:

Is it impossible in C++ to create an assignment operator for classes
with const data? I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

return *this;
}

thanks

Have you looked into const_cast?

You may also find this of interest: http://www.gotw.ca/gotw/059.htm

LR

[Gavin Deane]

LR wrote:

scroopy wrote:

Is it impossible in C++ to create an assignment operator for classes
with const data? I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

return *this;
}

Have you looked into const_cast?

I don't see how that will help in the OP's case. const_cast can't be
used to change an object that was declared const.

Gavin Deane

[LR]

Gavin Deane wrote:

LR wrote:

>>scroopy wrote:

>>>Is it impossible in C++ to create an assignment operator for classes
with const data? I want to do something like this

class MyClass
{
const int m_iValue;

public:

MyClass(int iVal):m_iValue(iVal){}

MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed

return *this;
}

Have you looked into const_cast?

I don't see how that will help in the OP's case. const_cast can't be
used to change an object that was declared const.

You snipped this:
"You may also find this of interest: http://www.gotw.ca/gotw/059.htm "

The OPs assignment operator is a little unusual in that he's not
returning a reference, however, I saw nothing in the OP that suggested
that a copy ctor and swap couldn't be added to this class, and using
form described in the link above...

MyClass &operator=(const MyClass &m) {
MyClass temp(m);
swap(temp);
return *this;
}

Implementing the copy ctor should be easy. MyClass::swap(MyClass &) has
the problem described by the title of the thread, hence my suggestion to
look into const_cast.

However, suppose that the op really does want something like (sorry,
typed in not cut and pasted)

class X {
const int m_;
public:
X operator=(const X &x) {
m_ = x.m_;
}
};

which won't work.

Instead, perhaps
class X {
const int m_;
public:
X operator=(const X &x) {
int &r = const_cast<int&>(m_);
r = x.m_;
}
};

I'm not 100% certain if this complies with the standard, however, it
seems to compile with no errors or warnings with Comeau's try it out,
doesn't get a warning from Gimpel's Blank Slate, except that we're
returning an X instead of a X&, and compiles and runs with the compiler
I normally use. Of course these last three cannot be taken as proof
that it is compliant. And it would certainly deserve some sort of
comment if put into production code.

My compiler will compile this too:

class X {
const int m_;
public:
X operator=(const X &x) {
const_cast<int&>(m_) = x.m_;
}
};

Of course, since what the OP was actually trying for seems to have been
a copy ctor, all of this may be besides the point.

LR

[Gavin Deane]

LR wrote:

Gavin Deane wrote:

LR wrote:

>scroopy wrote:

Is it impossible in C++ to create an assignment operator for classes
with const data?

<snip>

>Have you looked into const_cast?

I don't see how that will help in the OP's case. const_cast can't be
used to change an object that was declared const.

You snipped this:
"You may also find this of interest: http://www.gotw.ca/gotw/059.htm "

I snipped it because, informative though it is, I thought it was an
aside and not directly relevant to your sugestion to look at
const_cast.

The OPs assignment operator is a little unusual in that he's not
returning a reference,

I hadn't picked up on that, but I don't think it's relevant to the
const question.

however, I saw nothing in the OP that suggested
that a copy ctor and swap couldn't be added to this class, and using
form described in the link above...

MyClass &operator=(const MyClass &m) {
MyClass temp(m);
swap(temp);
return *this;
}

Implementing the copy ctor should be easy. MyClass::swap(MyClass &) has
the problem described by the title of the thread, hence my suggestion to
look into const_cast.

MyClass::swap(MyClass &) is no more allowed or able to change the const
data member than the OP's flawed assignment operator is.

However, suppose that the op really does want something like (sorry,
typed in not cut and pasted)

class X {
const int m_;
public:
X operator=(const X &x) {
m_ = x.m_;
}
};

which won't work.

Instead, perhaps
class X {
const int m_;
public:
X operator=(const X &x) {
int &r = const_cast<int&>(m_);
r = x.m_; // BANG!!!!! Undefined behaviour
}
};

I'm not 100% certain if this complies with the standard, however, it
seems to compile with no errors or warnings with Comeau's try it out,

Really? I get two warnings (no errors) from Comeau. One warns that no
constructor is defined that initialises the const member and the other
warns that there is no return statement in the assignment operator. But
compiling isn't the main issue with the code above. I've indicated with
a comment - the code exhibits undefined behaviour when it attempts to
modify the const object m_.

doesn't get a warning from Gimpel's Blank Slate, except that we're
returning an X instead of a X&, and compiles and runs with the compiler
I normally use.

And what does the code _do_ when it runs? The behaviour is undefined so
anything is possible. Change the compiler settings, change to a
different compiler, change to a different version of the same compiler,
change the phase of the moon and the behaviour could change. If you
happened to see the behaviour you expected you were just unlucky.

Of course these last three cannot be taken as proof
that it is compliant. And it would certainly deserve some sort of
comment if put into production code.

Code that invokes undefined behaviour should not be allowed in
production code.

My compiler will compile this too:

class X {
const int m_;
public:
X operator=(const X &x) {
const_cast<int&>(m_) = x.m_;

Exactly the same problem. m_ is const. No amount of casting to overrule
the compiler makes it possible to modify it's value in a defined way.

}
};

Gavin Deane

[LR]

Gavin Deane wrote:

LR wrote:

>>Gavin Deane wrote:

>>>LR wrote:
scroopy wrote:
>Is it impossible in C++ to create an assignment operator for classes
>with const data?

<snip>

>>>>Have you looked into const_cast?

I don't see how that will help in the OP's case. const_cast can't be
used to change an object that was declared const.

You snipped this:
"You may also find this of interest: http://www.gotw.ca/gotw/059.htm "

I snipped it because, informative though it is, I thought it was an
aside and not directly relevant to your sugestion to look at
const_cast.

>>The OPs assignment operator is a little unusual in that he's not
returning a reference,

I hadn't picked up on that, but I don't think it's relevant to the
const question.

>>however, I saw nothing in the OP that suggested
that a copy ctor and swap couldn't be added to this class, and using
form described in the link above...

MyClass &operator=(const MyClass &m) {
MyClass temp(m);
swap(temp);
return *this;
}

Implementing the copy ctor should be easy. MyClass::swap(MyClass &) has
the problem described by the title of the thread, hence my suggestion to
look into const_cast.

MyClass::swap(MyClass &) is no more allowed or able to change the const
data member than the OP's flawed assignment operator is.

You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you please
point me to where it says this?

>

>>However, suppose that the op really does want something like (sorry,
typed in not cut and pasted)

class X {
const int m_;
public:
X operator=(const X &x) {
m_ = x.m_;
}
};

which won't work.

Instead, perhaps
class X {
const int m_;
public:
X operator=(const X &x) {
int &r = const_cast<int&>(m_);
r = x.m_; // BANG!!!!! Undefined behaviour
}
};

I'm not 100% certain if this complies with the standard, however, it
seems to compile with no errors or warnings with Comeau's try it out,

Really? I get two warnings (no errors) from Comeau. One warns that no
constructor is defined that initialises the const member and the other
warns that there is no return statement in the assignment operator. But
compiling isn't the main issue with the code above. I've indicated with
a comment - the code exhibits undefined behaviour when it attempts to
modify the const object m_.

Oops, that's what I get for typing and cutting and pasting, but
nonetheless, you don't describe an error for using const_cast in the above.

Again, I haven't found in the standard where it says this isn't defined,
can you please point it out to me? TIA.

>

>>doesn't get a warning from Gimpel's Blank Slate, except that we're
returning an X instead of a X&, and compiles and runs with the compiler
I normally use.

And what does the code _do_ when it runs? The behaviour is undefined so
anything is possible. Change the compiler settings, change to a
different compiler, change to a different version of the same compiler,
change the phase of the moon and the behaviour could change. If you
happened to see the behaviour you expected you were just unlucky.

If it's undefined of course, but again, can you please point out where
the standard says this is undefined?

>

>>Of course these last three cannot be taken as proof
that it is compliant. And it would certainly deserve some sort of
comment if put into production code.

Code that invokes undefined behaviour should not be allowed in
production code.

I reiterate my request.

>

>>My compiler will compile this too:

class X {
const int m_;
public:
X operator=(const X &x) {
const_cast<int&>(m_) = x.m_;

Exactly the same problem. m_ is const. No amount of casting to overrule
the compiler makes it possible to modify it's value in a defined way.

I admit that I have trouble reading the standard, so perhaps I'm badly
mistaken, but reading 5.2.11 doesn't make that clear to me. Can you
please point out my mistake?

>

>> }
};

LR

[Noah Roberts]

LR wrote:

Gavin Deane wrote:

MyClass::swap(MyClass &) is no more allowed or able to change the const
data member than the OP's flawed assignment operator is.

You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you please
point me to where it says this?

Actually, he is saying that modification of a const object results in
undefined behavior.

17.1.5.1/5 contains the following example:

const int * ciq = new const int (3); // initialized as required
int * iq = const_cast<int>(ciq); // cast required
*iq = 4 // undefined: modifies a const object

17.1.5.1/4 states:

"Except that any class member declared mutable (7.1.1) can be modified,
any attempt to modify a const object during its lifetime (3.8) results
in undefined behavior."

>My compiler will compile this too:

class X {
const int m_;
public:
X operator=(const X &x) {
const_cast<int&>(m_) = x.m_;

Exactly the same problem. m_ is const. No amount of casting to overrule
the compiler makes it possible to modify it's value in a defined way.

I admit that I have trouble reading the standard, so perhaps I'm badly
mistaken, but reading 5.2.11 doesn't make that clear to me. Can you
please point out my mistake?

5.2.11 does not address modification. The cast is defined, the
assignment is not.

[Ron Natalie]

>
You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you please
point me to where it says this?

7.1.5.1 The cv-qualifiers.

5 Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during its lifetime (3.8)
results in undefined behavior.

[Kai-Uwe Bux]

LR wrote:

Gavin Deane wrote:

>LR wrote:

>>>Gavin Deane wrote:

LR wrote:
>scroopy wrote:
>
>
>>Is it impossible in C++ to create an assignment operator for classes
>>with const data?

<snip>

>>>>>Have you looked into const_cast?

I don't see how that will help in the OP's case. const_cast can't be
used to change an object that was declared const.

You snipped this:
"You may also find this of interest: http://www.gotw.ca/gotw/059.htm "

I snipped it because, informative though it is, I thought it was an
aside and not directly relevant to your sugestion to look at
const_cast.

>>>The OPs assignment operator is a little unusual in that he's not
returning a reference,

I hadn't picked up on that, but I don't think it's relevant to the
const question.

>>>however, I saw nothing in the OP that suggested
that a copy ctor and swap couldn't be added to this class, and using
form described in the link above...

MyClass &operator=(const MyClass &m) {
MyClass temp(m);
swap(temp);
return *this;
}

Implementing the copy ctor should be easy. MyClass::swap(MyClass &) has
the problem described by the title of the thread, hence my suggestion to
look into const_cast.

MyClass::swap(MyClass &) is no more allowed or able to change the const
data member than the OP's flawed assignment operator is.

You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you please
point me to where it says this?

[7.1.5.1/4-5]

Except that any class member declared mutable (7.1.1) can be modified, any
attempt to modify a const object during its lifetime (3.8) results in
undefined behavior.

Example:
const int ci = 3; // cv-qualified (initialized as required)
ci = 4; // ill-formed: attempt to modify const
int i = 2; // not cv-qualified
const int* cip; // pointer to const int
cip = &i; // OK: cv-qualified access path to unqualified
*cip = 4; // ill-formed: attempt to modify through ptr to const
int* ip;
ip = const_cast<int*>(cip); // cast needed to convert const int* to int*
*ip = 4; // defined: *ip points to i, a non-const object
const int* ciq = new const int (3); // initialized as required
int* iq = const_cast<int*>(ciq); // cast required
*iq = 4; // undefined: modifies a const object>
[snip]
Best

Kai-Uwe Bux

[Pete Becker]

LR wrote:

>
You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you please
point me to where it says this?

7.1.5.1/4: Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during
its lifetime (3.8) results in undefined behavior.

[LR]

Pete Becker wrote:

LR wrote:

>>
You seem to be saying that a const member cannot have it's const cast
away. I haven't been able to find this in the standard. Can you
please point me to where it says this?

7.1.5.1/4: Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during
its lifetime (3.8) results in undefined behavior.

Ok, thanks, got it.

And thanks to everyone else who responded too.

LR