4

I am almost sure this has been asked before. Unfortunately, my C++ has become so rusty that I don't even know what to search for.

Is there an easy-to-remember rule of thumb that would tell me which qualifiers (inline, virtual, override, const, mutable, etc.) must appear (a) only in the declaration, (b) only in the definition, (c) both in the declaration and definition when I define a member function out-of-line?

Example:

struct Geometry {
    …
    virtual Geometry* clone() const = 0;
};

struct Point2 : public Geometry {
    …
    virtual Point2* clone() const override { … }
};

If I wanted to define Point2::clone out-of-line, trial and error leads me to believe that this would be the correct code:

struct Point2 : public Geometry {
    …
    virtual Point2* clone() const override;
};

Point2* Point2::clone() const { … }
  • The virtual and override qualifiers may appear only in the declaration.
  • const must appear in both the declaration and definition.

I would not want to rely on trial and error forever. But I want to be explicit about qualifiers (i.e. repeat them even if e.g. they are implied by a base class.) Is there a general rule which qualifier has to go exactly where, or are the rules different for each of them?

stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268

3 Answers3

2

General rule is that when removing a qualifier produces a different function overload, that qualifier must appear in both places. All other qualifiers stay in the declaration.

The three qualifiers that must appear in both places are const and the two kinds of reference qualifiers, which appear in the C++11 standard:

void foo() const;
void foo() &;
void foo() &&;

All other qualifiers stay in the declaration.

stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Thank you. To compare your answer with that by Sam Varshavnik: If changing qualifiers produces a different function overload, that implies that the function signatures before & after the change do not match, right? – stakx - no longer contributing Aug 03 '16 at 11:28
1

The best way to know which modifiers (or "specifiers") have to be used in which instance is to understand what each one of them means, and what they do.

const is a part of the method's "signature". A signature consists of what the function returns, the types of its parameters, and whether it is a constant method (the const part). That cannot be changed, and must remain as is.

Everything else, virtual, and override in your list, is related to the method's declaration. It's not a part of the method's signature, and can only appear in the method's declaration.

The only rule of thumb, if there is one, is that anything that's a part of the method's signature must be unchanged, when the method is not defined inline. And if it's not, it must be a part of the declaration, only (but, as with every rule of thumb, there's always an exception, the inline keyword).

Note that default parameter values are not considered to be a part of the method's signature. Default parameter values must be specified in the declaration only. But, if the method is defined inline, the default parameter values wind up as part of the method's definition!

Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
1

I will take another approach: My rule of thumb: put them in both places and then do what the compiler says. It implements the standard rules and it will make you follow them.

The problem with any rule of thumb is that you can't be sure it's ok for a particular example, so why not check from the start by default.

If you seldom use C++, there is no point in learning some rules that you can't 100% rely on them anyway. If you (start to) use C++ often, then after several times the compiler tells you what to do, you will get the gist yourself.

Because this post is not in the same tone with the others, I will go the rogue way all the way and give you this extremely unused with a dark corner case example: constexpr in an explicit instantiation 

template <class T>
constexpr auto foo(T)
{
}

template constexpr auto foo(int);
//       ^
// 6 : error: explicit instantiation shall not use 'constexpr' specifier

It's not what you asked about, but is goes to show that you can apply this strategy to a broader set of similar problems, where you would otherwise need other rules of thumbs

bolov
  • 72,283
  • 15
  • 145
  • 224