Which cast style is better and why?

Question

Imagine in C++ two classes one named derived and another named base that is a base class of the first. If I had the following code, which is preferred:

base *b = init_value_here;
const derived *d = static_cast<derived *>(b);

or

base *b = init_value_here;
const derived *d = static_cast<const derived *>(b);

In other words, is it better to exclude const in the static cast when not required since the compiler can promote to constness, or is it better to include it to loosen the restrictions on b such that it could be made const in the future more readily?

Mark B · Answer 1 · 2011-06-17T18:29:40.623

8

Neither one if possible. Design your class so that the base class defines a fully useful interface and use only the base class pointer.

Sometimes however you're stuck with legacy code, in which case I would explicitly spell out that you're casting it to const.

EDIT: I should make it clear that there are occasionally cases where a non-polymorphic situation arises and a solution using a cast would be appropriate. Generally speaking downcasting may be a design smell but it doesn't always indicate that something is definitely wrong.

edited Jun 17 '11 at 18:29

answered Jun 17 '11 at 18:08

Mark B

95,107
10
109
188

1

+1 for reminding the OP that this sort of scenario should be avoided wherever possible. – Jonathan Grynspan Jun 17 '11 at 18:11
1

+1 for the right answer. -1 for implying that polymorphism should always be employed... which is of course simply not true. – Lightness Races in Orbit Jun 17 '11 at 18:14

Jonathan Grynspan · Answer 2 · 2011-06-17T18:15:52.387

3

Well, to be clear, they do the same thing.

Now, if you were converting from a const base * to a const derived *, only the latter would be valid, and the former would require a const_cast as well. If you were converting from a base * to a derived *, only the former would be valid, since otherwise you'd need to cast away the const-ness that your cast just added.

My preference would be to avoid using const modifiers in a cast unless explicitly needed. Keep the code as simple as the compiler allows, in other words.

Of course, you should be using dynamic_cast<> rather than static_cast<> in this scenario, if b could be an instance of another derived class.

edited Jun 17 '11 at 18:15

answered Jun 17 '11 at 18:10

Jonathan Grynspan

43,286
8
74
104

1

Do remember that `dynamic_cast` *does* require the classes to be polymorphic. – Mark B Jun 17 '11 at 18:14
2

Replace "since" with "if" in the last paragraph. – Lightness Races in Orbit Jun 17 '11 at 18:14

score 3 · Answer 3 · answered Jun 17 '11 at 18:19

For just a line of code I wouldn't worry about it much. If you do change b to const base* in future then the compiler will tell you exactly what line is problematic and what to change. So the benefits are pretty minimal either way - one of them makes the line shorter, the other one might save you a few seconds' work in future on an occasion when you're already in that same function changing the code. I'd put the const in if it occurred to me to do so, since it slightly reduces the reliance of one line of code on the details of another line. But I wouldn't go out of my way to change it if the code was already written.

If you're designing an API, then you'd put const where you can, because changing an API might be painful. I don't think this potential future change is painful.

score 3 · Accepted Answer · answered Jun 17 '11 at 18:25

I strive to do the least number of explicit casts possible, and everything else implicit, if possible.

So I would use the former (i.e not including const in the cast).

But this is only my opinion. You may be of the opinion to write the const there too, as it fits your taste.

Which cast style is better and why?

4 Answers4