owensd
You cannot make that claim at all. What if function() created a thread that delayed execution of the code that used the pointer to the struct? What's the value of s.x when the code in the thread executes?

owensd
The only way to guarantee that s.x = 123 in your example is to pass by value so that the struct is actually copied.

owensd
The const keyword is really only good for defining the semantics of how your code should work; it really makes no claim about how your code does work.

5sw

owensd
You cannot make that claim at all. What if function() created a thread that delayed execution of the code that used the pointer to the struct? What's the value of s.x when the code in the thread executes?

Who knows. const doesn't add any guarantees to that. And I never claimed anything about this. const doesn't mean "nobody can change this value", it means "I won't change this value". Big difference.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

struct Data {
    int value;
};


void foo(const Data *d) {
    // d->value = 10;       // compiler error as it should
    
    Data *md = (Data *)d;
    md->value = 10;
}


int main(int argc, const char * argv[]) {
    
    Data d;
    d.value = 123;
    
    printf("value: %d\n", d.value);  // prints 123
    foo(&d);
    printf("value: %d\n", d.value);  // prints 10
    
    return 0;
}

5sw

owensd
The only way to guarantee that s.x = 123 in your example is to pass by value so that the struct is actually copied.

No, the const pointer does guarantee that.

5sw
After function() returned s.x has not changed, if function played by the rules and honored the constness of the pointer.

5sw
...(because the compiler assumed s.x == 123 after function() returned).

owensd

5sw

owensd
You cannot make that claim at all. What if function() created a thread that delayed execution of the code that used the pointer to the struct? What's the value of s.x when the code in the thread executes?

Who knows. const doesn't add any guarantees to that. And I never claimed anything about this. const doesn't mean "nobody can change this value", it means "I won't change this value". Big difference.

No, it says, the function "shouldn't" change this value. The function declaration cannot actually enforce the "I will not change this value."

Here's an illustration that the compiler cannot actually make that guarantee.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

struct Data { int value; }; void foo(const Data *d) { // d->value = 10; // compiler error as it should Data *md = (Data *)d; md->value = 10; } int main(int argc, const char * argv[]) { Data d; d.value = 123; printf("value: %d\n", d.value); // prints 123 foo(&d); printf("value: %d\n", d.value); // prints 10 return 0; }

owensd

5sw

owensd
The only way to guarantee that s.x = 123 in your example is to pass by value so that the struct is actually copied.

No, the const pointer does guarantee that.

You just said above that "const doesn't add any guarantees", and now you're saying that it does...

1
2
3
4
5
6
7
8

int value = 42;
const int *ptr = &value;

// *ptr == 42;

value = 0;

// *ptr == 0;

1
2
3
4
5
6
7
8

int value = 42;
const int *ptr = &value;

// value == 42

function(ptr);

// value == 42

owensd

5sw
After function() returned s.x has not changed, if function played by the rules and honored the constness of the pointer.

That's a big if, and the compiler cannot guarantee it. The const keyword is helping _you_ (e.g. the one programming the code) protect yourself from inadvertently modifying data; it's not doing anything else.

owensd

5sw
...(because the compiler assumed s.x == 123 after function() returned).

Ok... you also have a big misunderstanding here. The function is taking a pointer to the struct; it knows nothing about the contents of the struct at this time. If you wanted the function to know the contents of the struct at call time, you'd have to pass the data in by value.

owensd


When the line of code in your function gets to: s->x, that is the only time the value is read. At that point in time, there is absolutely no guarantee as to what value will be.

You can argue that in this example it's clearly 123, but this is trivial code. If we set the value of s->x (or d.value from the example above) to a random number, then maybe it becomes more clear that the compiler really doesn't know what the value is because that value is determined at runtime. Thus the compiler has to generate code that follows the pointer in memory to retrieve the contents out of the struct.

3
EXAMPLE The following pair of declarations demonstrates the difference between a ‘‘variable pointer to a constant value’’ and a ‘‘constant pointer to a variable value’’.

const int *ptr_to_constant;
int *const constant_ptr;

The contents of any object pointed to by ptr_to_constant shall not be modified through that pointer, but ptr_to_constant itself may be changed to point to another object. Similarly, the contents of the int pointed to by constant_ptr may be modified, but constant_ptr itself shall always point to the same location.

7.20.3.4 The realloc function

#2 The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. The contents of the new object shall be the same as that of the old object prior to deallocation, up to the lesser of the new and old sizes. Any bytes in the new object beyond the size of the old object have indeterminate values.

owensd
6.7.5.1 Pointer declarators (source: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf)

3
EXAMPLE The following pair of declarations demonstrates the difference between a ‘‘variable pointer to a constant value’’ and a ‘‘constant pointer to a variable value’’.

const int *ptr_to_constant;
int *const constant_ptr;

The contents of any object pointed to by ptr_to_constant shall not be modified through that pointer, but ptr_to_constant itself may be changed to point to another object. Similarly, the contents of the int pointed to by constant_ptr may be modified, but constant_ptr itself shall always point to the same location.

The spec says that contents of ptr_to_constant shall not be modified through that pointer. The important part of this clause is the latter half. This means that I can create a different pointer and change that contents of that object. That is to spec. Do you have a different place in the spec where you think this says otherwise?

If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

This applies to those objects that behave as if they were defined with qualified types, even if they are never actually defined as objects in the program

owensd

If your compiler output 123 in both before and after the function call by simply using the value from before and not retrieving it again, it would be a bug. Again, if you have a pointer to the spec there const pointer parameters are treated differently, let me know.

Your argument about the being "crap" is completely irrelevant; it's allowable by the language and thus must be handled properly by compilers. Failure to do so is a compiler bug.

5sw
Yes, you can write that. But you are not allowed to. This is undefined behavior, the compiler can do anything at all with that.

5sw

Yes, you can create a different pointer to change that value. But you are not allowed to make that different pointer by casting the const away. This counts as modifying the value through the const pointer.

Lets see what the standard says to this:

If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

1
2
3
4
5
6
7
8

S s;
s.x = 123;

const S cs = s;

foo(&cs);

printf("cs.x = %d\n", cs.x);

5sw
I always interpreted the standard in a way that casting the const away and writing through that pointer was undefined behavior. Maybe I am wrong about that.

1
2
3
4
5
6

extern RtToken RiDeclare(char *name, char *declaration);

extern RtVoid RiSubdivisionMesh(RtToken mask, RtInt nf, RtInt nverts[],
                          RtInt verts[],
                          RtInt ntags, RtToken tags[], RtInt numargs[],
                          RtInt intargs[], RtFloat floatargs[], ...);

5sw
Someone said here const made the code too rigid. How so? Ok, if you want to change from const to non-const you will have to go up the call-graph and make more changes. But that's just a little bit of busy work. Then comes the real work of finding all the places that depend on the called function not changing the values and rewriting it so they can deal with that change.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

class Foo
{
public:
    Foo()
    : m_i(0)
    {
    }

    Foo(int i)
    : m_i(i)
    {
    }

    int GetInt() const
    {
        return m_i;
    }

private:
    int m_i;
};

1
2
3
4

Foo f(54321);
const Foo *p = &f;

printf("%d\n", p->GetInt());

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

class Foo
{
public:
    Foo()
        : m_i(0)
    {
    }

    Foo(int i)
        : m_i(i)
    {
    }

    int GetInt() const
    {
        return m_i;
    }

private:
    int m_i;
};

class Entity
{
public:
    Entity()
        : m_name()
        , m_health(0)
        , m_foo(NULL)
    {
    }

    void InitEntity(const char *name, int health, const Foo *foo)
    {
        snprintf(m_name, sizeof(m_name), "%s", name);
        m_health = health;
        m_foo = foo;
    }

    void UpdateAndPrint()
    {
        --m_health;

        if (m_foo)
	{
            printf("%s has %d health and Foo %p -> %d\n", m_name, m_health, m_foo, m_foo->GetInt());
	}
    }

private:
    char m_name[16];
    int m_health;
    const Foo *m_foo;
};

DaleKim

[...]
Going back to the "sample" code, if I did in fact change the code to remove the const qualifiers so I can modify Foo from Entity (and also added a setter for m_i) then what have I accomplished? I just typed a bunch of code for utterly no reason and then removed it later because it was imposing a restriction on me that's absolutely not helpful.
[...]

ChrisG0x20
Just because I didn't see it yet on the thread. Here is an example of const helping the compiler generate better code:

http://herbsutter.com/2008/01/01/...ate-for-the-most-important-const/