Why make a parameter const if you're going to do const_cast?

Question

There was a linked list example where someone was trying to append a node. This is part of the code:

void Append(ListElement<T> const* ptr, T const& datum)
{
    ListElement<T>* temp = const_cast<ListElement<T>*>(ptr);
    // ...
}

What is the point in making ptr a pointer to const if you're going to just cast it away? ptr isn't used anywhere in the function, just temp, so wouldn't it be better to make it a pointer to non-const so people know that the object might be modified?

Is there a reason to make a parameter const and then const_cast'ing it away in the body instead of just making it non-const?

answer: poor design. (The only real reason is to pass temp to a legacy library that doesn't support const but you know for sure that it is const). — IdeaHat, Nov 19 '14 at 17:37

score 7 · Accepted Answer · edited Jun 20 '20 at 09:12

7

What is the point in making ptr a pointer to const if you're going to just cast it away?

None.

It breaks the function contract and is an example of someone getting lost in code design.

To illustrate, it would look like this

A: Hey, you can read from that object, but only read.
B: Okay, give me it, I'm going to only read from it.
B: writes on it

edited Jun 20 '20 at 09:12

Community

1
1

answered Nov 19 '14 at 17:38

Bartek Banachewicz

38,596
7
91
135

1

Are there valid reasons to use `const_cast`? – template boy Nov 19 '14 at 17:42
2

@templateboy That's a whole another question. As @IdeaHat pointed out, you might have a legacy API where you are guaranteed by informal spec that the function won't write on the object, but it's not expressed in the interface. Then your function effectively *becomes* a `const_cast`. [Read more here](http://stackoverflow.com/questions/332030/when-should-static-cast-dynamic-cast-const-cast-and-reinterpret-cast-be-used). – Bartek Banachewicz Nov 19 '14 at 17:43

IdeaHat · Answer 2 · 2014-11-19T17:51:24.943

poor design. If the code is never used, then this is just simply bad practice and you should fire the programmer that did it out of a canon.

The one instance it happens (and why there is a const_cast in the first place) is that if you have a legacy 3rd party library (especially c libraries) that don't define const (or to interface your const correct code with someone's not const correct code). It would still be a terrible design imho to leave that reference around.

 int legacy(int* const_no_really_i_swear);

 int my_new_func(const int* var)
 {
     //way 1 (non-const reference goes out of scope immediately)
     legacy(const_cast<int*>(var));

     //way 2 (non-const reference goes out of scope at end of block
     {
        int* temp = const_cast<int*>(var);
        legacy(temp);
     }
 }

Using this in code it just bad and will most likely lead to undefined behavior, especially around strict aliasing rules.

Edit: I should specify that you can and should only do this if you really know what your doing. You can never make the guarentee that legacy doesn't mess with temp. If you have access to the code it is better to refactor it to be const correct than do this, (this is why some people don't like const as it is infectious, but I look at that as one of its features!)

Why make a parameter const if you're going to do const_cast?

2 Answers2

None.