21

As per Scott Meyers, to prevent repetition of code in the const version of a getter and the non-const version of a getter, call the const version of the method from the non-const version: static_cast<const A&>(*this).Methodology(); however, in accidental usage due to an overzealous Visual Assist X Intellisense I typed: const_cast<const A&>(*this).Methodology(); and it worked just fine.

What are any and all differences in this case with using a particular cast?

IDE in use: Visual Studio 2010.

Casey
  • 10,297
  • 11
  • 59
  • 88
  • 1
    I wonder why Scott promotes using static_cast while const_cast seems like a more suitable choice here, also more clearly expressing the intent? Or are you not using it exactly in the way he meant? – stijn Jun 20 '12 at 20:36
  • @stijn: I've wondered the same thing too. `const_cast` feels slightly more natural to me even for the safer direction of adding `const`. – CB Bailey Jun 20 '12 at 21:04
  • @CharlesBailey: see my answer to potentially see why he didn't promote one over the other. – Casey Jun 20 '12 at 21:51
  • @stijn: see my answer to potentially see why he didn't promote one over the other. – Casey Jun 20 '12 at 21:51
  • @Casey: `const_cast` is required for removing `const`. I didn't get from your answer why `static_cast` should be prefered over `const_cast` for adding `const`. Did I misunderstand? – CB Bailey Jun 20 '12 at 22:02
  • @CharlesBailey: The answer is neither. I was saying why he *doesn't* promote one over the other. – Casey Jun 20 '12 at 22:16
  • 2
    @Casey: That's not true. In the item to which you refer he specifically chooses `static_cast` over `const_cast` for _adding_ `const` to a reference type. I thought that this was at the heart of what you were asking. – CB Bailey Jun 21 '12 at 05:59
  • Related: [1](https://stackoverflow.com/q/3402318/23715), [2](https://stackoverflow.com/q/5853833/23715) – Alex Che Jun 29 '21 at 13:50

2 Answers2

9

Assuming that the type of this is A*, there is no difference.

In general const_cast can cast aways the const specifier (from any level of indirection or template parameter)

static_cast<> can cast a type to another if the target type is in the source's type hierarchy.

They cannot do each other's work.

The reason they both worked in your case is because you have introduced const-ness, as opposed to having taken it away (calling from the non-const version of the function the type of this is A*, no const). You could just as well have written

const A& tmp = *this;
tmp.Methodology();

and it would have worked without the need for any casting. The casting is used for convenience and terseness to not have to introduce a new variable.

Note: you can use static_cast<> here as you know that you are casting to the right type. In other cases (when you cannot be sure) you need to use dynamic_cast<> that does a runtime type check to ensure the conversion is valid

metamorphosis
  • 1,972
  • 16
  • 25
Attila
  • 28,265
  • 3
  • 46
  • 55
  • `A` is a class type, `this` defaults to `const * A`. – Casey Jun 20 '12 at 20:32
  • 1
    @Casey - I figured that much; the point was that it is the class where you are doing this, not for example a subclass (in which case the `const_cast<>` would have failed) – Attila Jun 20 '12 at 20:37
  • 2
    @Casey - the type of `this` is `const A*` (more precisely `const A* const`) if you are in a `const` member function, otherwise it is `A*` (more precisely `A* const`) – Attila Jun 20 '12 at 20:41
  • 1
    @Attila `this` itself is a scalar rvalue and hence never `const`. – fredoverflow Jun 20 '12 at 21:06
  • @FredOverflow - good to know :) I thought it was const so you cannto modify it, but rvalue makes sense too – Attila Jun 20 '12 at 21:13
6

After re-reading Item 3 from Effective C++ 3rd Ed. I realize that he was actually advocating using both. Add const to call the const version, then cast away the const-ness of the return value (if there is one). In my particular case, there is no const return value, just a const-function so the wrapped-by-const_cast<> version is not needed and in effect causes there to be no difference between the two calls in question

(p. 13) Item 3: Use const whenever possible

...

(p. 23) Avoiding Duplication in const and Non- const Member Functions

...What you really want to do is implement operator[] functionality once and use it twice. That is, you want to have one version of operator[] call the other one. And that brings us to casting away constness.

...Casting away the const on the return value is safe, in this case, because whoever called the non-const operator[] must have had a non-const object in the first place....So having the non-const operator[] call the const version is a safe way to avoid code duplication, even though it requires a cast...

class TextBlock {
public:

...

    const char& operator[](std::size_t position) const      //same as before
    {
        ...
        ...
        ...
        return text[position];
    }

    char& operator[](std::size_t position)        //now just calls const op[]
    {
        //cast away const on op[]'s return type;
        //add const to *this's type;
        //call const version of op[].
        return const_cast<char&>(static_cast<const TextBlock&>(*this)[position]);
    }
...
};

As you can see, the code has two casts, not one. We want the non-const operator[] ... To avoid infinite recursion, we have to specify that we want to call the const operator[], but there's no direct way to do that. Instead, we cast *this from its native type of TextBlock& to const TextBlock&. Yes, we use cast to add const! So we have two casts: one to add const to *this (so that our call to operator[] will call the const version), the second to remove the const from the *const operator[]'s return value.

Casey
  • 10,297
  • 11
  • 59
  • 88