C++ : Default parameters in a pure virtual method

Started by
6 comments, last by Fruny 17 years, 6 months ago
My compiler is complaining about me trying to define a default parameter for a pure virtual method. Is this normal or am I missing something? Kind regards, Mark
Advertisement
The C++ standard only says this:

Quote:A virtual function call uses the default arguments in the declaration of the virtual function determined by the static type of the pointer or reference denoting the object. An overriding function in a derived class does not acquire default arguments from the function it overrides.


Do you have more information? What compiler? What version? What code?
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
I don't know of any reason the compiler would complain about default parameters in a pure virtul function. Can you give an example of the problem?

Skizz
Fruny,

Apologies, I made a mistake lower in the code, my mistake. It is interesting to learn that derived methods do not inherit the default behaviour though!

Kind regards,

Mark
Quote:Original post by mrmrcoleman
Apologies, I made a mistake lower in the code, my mistake. It is interesting to learn that derived methods do not inherit the default behaviour though!


It makes sense, though, since at the point of call the compiler knows only the static type of the object, not its dynamic type. In other words.
  class PureVirtualBase  {  public:    virtual createWindow(int width = 640, int height = 480) = 0;  };  PureVirtualBase* pObject = factoryFunction("DirectX9");  pObject->createWindow();

will work just like you expect it to, despite the fact that the concrete class of the object returned by the factory function has different default values for the parameters to createWindow(), because at compile time at the calling point there's no way to know what that concrete class is.

Stephen M. Webb
Professional Free Software Developer

If you want to achieve this behavior, you can go about it a different way. For example:

instead of:

class Base
{
public:
virtual void myMethod(int x = 3, int y = 4) = 0;
};

class Derived : public Base
{
public:
virtual void myMethod(int x, int y); // didn't keep defaults
};

You could do:

// Base.hpp:

class Base
{
public:
virtual void myMethod(int x, int y) = 0;
virtual void myMethod(int x);
virtual void myMethod();
};

// Base.cpp:

void Base::myMethod(int x)
{
myMethod(x, 4);
}

void Base::myMethod()
{
myMethod(3, 4);
}

class Derived : public Base
{
public:
virtual void myMethod(int x, int y); // didn't keep defaults
virtual void myMethod();
};

// Derived.cpp:

void Derived::myMethod(int x, int y)
{
...
}

void Derived::myMethod()
{
this->myMethod(9,10);
}

// main.cpp:

Derived derived;
Base& base = derived;

base.myMethod(); // x = 9, y = 10, as desired


That will enforce the default parameter behavior you desire and also allow you to override it. Just a thought.

P.S.: You should probably make constants instead of "magic" numbers.

[Edited by - Rydinare on October 18, 2006 9:51:42 AM]
I personnaly find that mixing default parameters and virtual-ness is dangerous:
struct Base{    virtual void Output(int x = 10) { std::cout << "In BASE class:" << x; }};struct Derived : public Base{    virtual void Output(int x = 5) { std::cout << "In DERIVED class:" << x; }}void main(){    Base* pBase = new Derived;    pBase->Output();}


I let you discover what the output will be (provided I didnt make trivial syntax error of course). IMHO this is a bit confusing and error prone.
Quote:Original post by janta
I let you discover what the output will be (provided I didnt make trivial syntax error of course). IMHO this is a bit confusing and error prone.


And is exactly covered by the exerpt of the standard I quoted. [smile]

Even though *pBase really is a Derived object and thus Derived::Output gets called, pBase is a Base* and thus the default arguments from Base will be used.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

This topic is closed to new replies.

Advertisement