Modify const variable in const member bad pratice or UB?

Question

Is the code below bad practice or undefined behavior? Essentially i am calling a const func to modify a member which is not marked as mutable. Link to demo

Credits to Mehrdad for inspiring this question (his question Does this code subvert the C++ type system?) and david for minor demo improvements.

#include <iostream>
using namespace std;

struct BreakConst
{
    int v;
    int *p;
    BreakConst() { v = 0; p = &v; } 
    void break_stuff() const { ++*p; }
};
void f(const BreakConst& bc) {
    bc.break_stuff();
}

Original Version that most answers are based on:

Answered by David Rodríguez, jpalecek, Mehrdad
Yes: This is "Undefined behavior"

int main()
{
    const BreakConst bc;
    cout << bc.v << endl;   // 0
    bc.break_stuff();       // O:)
    cout << bc.v << endl;   // 1

    return 0;
}

New Alternative Question:

Answered by Mehrdad
No: This is not "Undefined behavior"

int main()
{
    BreakConst bc;
    cout << bc.v << endl;   // 0
    f(bc);                  // O:)
    cout << bc.v << endl;   // 1

    return 0;
}

Result:

0
1

Answer 1

In this case, I'd say it's undefined behaviour. bc is a const object, so are all its subobjects (less mutables)¹, therefore bc.v should be, too and modifying a const object, however achieved, is UB².

[1] C++03 3.9.3/3:

Each non-static, non-mutable, non-reference data member of a const-qualified class object is const- qualified...

[2] C++03 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.

EDIT responding to the edit of the question: No, the modified version of the code does not cause undefined behavior. It may be bad practice, but actually may be useful at times. You can eg. use it to implement iterators to your classes via const-iterators (DRY):

class const_iterator
{
public:
  const T& dereference() const; // complicated
};

class iterator : public const_iterator
{
public:
  T& dereference() const { return const_cast<T&>(const_iterator::dereference()); }
};

Of course that relies on the fact that iterators can only be made from mutable containers, that the const and non-const versions do not differ (no COW and such) etc., but that is fairly common.

Answer 2

In your particular case it is undefined behavior as the object is const, not just the reference. It would be bad practice (and dangerously close to Undefined Behavior) in the following case:

void f( const BreakConst& b ) {
   bc.break_stuff();
}
int main() {
   BreakConst b;
   f( b );
}

The difference is that in this case the actual object is not const, even if the reference at the level of f is. The dangerously close to Undefined Behavior comes from the fact that the member function casting away const-ness cannot possibly know whether the object on which it has been called is const or not, so you have lost all control.

Answer 3

After your edit:

No, it's not undefined. You're allowed to modify a mutable object through a const reference; it's completely allowed and legal.

---

Before your edit:

Yes, it must be undefined, because the standard (I'm looking at the draft here) clearly says:

§7.1.6.1.4

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

So yes -- since the member isn't mutable, modifying it is obviously undefined behavior.

I don't know why the rule is that way, whether this is intentional, whether it is indeed a loophole, whether it's also violating another rule, how you're supposed to tell just by looking at it, etc... but regarding the question of whether it's UB: yes, it's undefined according to the standard.