I am working on a project and I am facing a little bit strange code which I cannot understand why and how can this happen !
I have a class Foo and Baz, and Foo has a non-static method that is called from Baz class without instantiating Foo:
class Foo {
public:
void qux(int a, int b);
};
class Baz {
public:
void bar(void);
};
void Baz::bar(void){
Foo::qux(2,3); // This should not happen as qux is not a static method !!
}
The only way that would work is if Baz was derived from Foo at some level.
Or, of course, Foo bears a different meaning in that scope (via a using, typedef, define or other).
If neither apply, your compiler is seriously broken.
This can happen in case of Baz is inherited from Foo.
In this case you can call method of the base class directly in the form that you mentioned:
void Baz::bar(void){
Foo::qux(2,3);
}
Related
Let's say I have a nice looking base class called base:
class base
{
public:
virtual void foo() const = 0;
};
Now, I have a class named foo that I would like to inherit from base and override base::foo:
class foo : public base
{
public:
virtual void foo() const override;
};
This is illegal in C++, as you are not allowed to name a method the same thing as the class (C++ greedily believes methods with the same name as the class are constructors, which are not allowed to have return types). Is there any way around this that doesn't involve changing the name of the class or method? I want external users to be able to create foo classes without the knowledge that there is a method base::foo called by someone else (imagine foo can be both a noun and a verb).
Is there any way around this that doesn't involve changing the name of the class or method?
No, there isn't.
All methods named foo are special in class foo -- they are constructors. Hence, they cannot be overridden virtual member functions.
I'll take a wild guess and just say NO.
You can have a lot of ambiguities in C++ (that sometimes have to be explicitly disambiguated), but I don't even see a way how a compiler or programmer could disambiguate this situation. Well, A programmer can (a function with a return type is obviously not a constructor), but C++ can't.
In C++, the only method that can have the class' name is its constructor.
So, no. You can't.
Okay, here's my (slightly evil) solution...
// Create an intermediate class which actually implements the foo method:
class foo_intermediate : public base
{
public:
virtual void foo() const override;
};
// Derive from that class and forward the constructor along
class foo : public foo_intermediate
{
public:
using foo_intermediate::foo_intermediate;
private:
friend class foo_intermediate;
// Actual implementation for the foo function goes here
void foo_impl() const;
};
// In some CPP file:
void foo_intermediate::foo() const
{
// Need to access the typename foo via namespace (global here)
static_cast<const ::foo*>(this)->foo_impl();
}
Actually calling foo is a bit funny, since this can't work:
void bar()
{
foo x;
x.foo(); // <- illegal attempt to access to the foo constructor
}
You must access through an alias:
void baz()
{
foo x;
base& rx = x;
rx.foo(); // legal
}
As an alternative, you can use a typedef:
class foo_impl : public base
{
public:
virtual void foo() const override;
};
using foo = foo_impl;
This gets around the issue of calling x.foo(), since it no longer appears as a constructor access.
I made a Gist so others could play with the two solutions if they are so inclined.
I'm getting this strange problem which I don't know why happens. The first and second of the following code snippets compile, while the third does not:
Compiles:
class Foo {
public:
Foo() { Bar(); }
private:
class Bar {};
};
Compiles:
class Foo {
class Bar {}; // Or only forward declare here and define later
public:
Foo(Bar) {}
}
Does not compile:
class Foo {
public:
Foo(Bar) {}
private:
class Bar {};
};
What makes the third fail to compile while the first can?
Normally, in C++, you can only reference declarations that were previously made in the translation unit. However, within a class definition, the definition of member functions are allowed to reference declarations which are made later in the class. Basically, the compiler restructures your in-class definitions so that they work as though they were written just after the class.
But this is only true of the function definitions. The declaration of the function (including parameter types) isn't allowed to do this. They can only reference declarations that have already been made in file order.
So you can do this:
class Test
{
public:
void Func(int x) {Inner foo;}
private:
class Inner {};
};
But not this:
class Test
{
public:
void Func(Inner x) {}
private:
class Inner {};
};
First example does not expose anything about private Bar to the outside, while third does.
Third example is pretty much saying, that there exist some class Foo, which has constructor with single argument of type Bar. But Bar is unknown to the outside. Imagine calling such constructor.
Foo f{Foo::Bar{}};
Will result probably in something like Foo::Bar is inaccessible.
The more I program, the more I like the snake_case and the less the CamelCase. There is one particular inconvenience irritating me a bit: I do not like getters start from the get_ prefix, but that is not always possible without some extra work when using the snake_case. Consider, for instance, a getter for a member of enum type defined inside a class,
class bar
{
public:
enum class foo { a, b };
foo foo() const { return m_foo; }
void set_foo(foo new_foo) { m_foo = new_foo; }
private:
foo m_foo;
};
This won't compile since (if I understand correctly) enum foo is hidden in both the setter new_foo parameter type and the private m_foo member declaration by the prior foo() getter declaration. The obvious fix is to name the getter as get_foo, but as I said, I don't like it.
When I compile with Clang it suggests another "workaround":
error: must use 'enum' tag to refer to type 'foo' in this scope
void set_foo(foo new_foo) { m_foo = new_foo; }
^
enum
and the same for m_foo member. The following code indeed compiles fine
class bar
{
public:
enum class foo { a, b };
foo foo() const { return m_foo; }
void set_foo(enum foo new_foo) { m_foo = new_foo; }
private:
enum foo m_foo;
};
It looks like the elaborated type specifiers are even supposed to solve such kind of problems:
Elaborated type specifiers may be used to refer to a
previously-declared class name (class, struct, or union) or to a
previously-declared enum name even if the name was hidden by a
non-type declaration.
But is not that a misuse of a language feature? Have you ever seen anything like that in libraries that use snake_case, such as, for instance, the Standard Library or Boost, or write it yourself?
Suppose I have a class Foo
class Foo{
public:
bool virtual bar(){return false;}
};
And class FooFoo inheriting Foo. bar() is not overriden in class FooFoo. I cannot change the headers of Foo or FooFoo. Is it then at all possible to override the default implementation of bar() in FooFoo?
This is impossible; you can't modify a class without modifying it, as it were.
Your best option is probably to publicly inherit from FooFoo and override in the derived class.
Is it then at all possible to override the default implementation of
bar() in FooFoo?
No, but you could derive another class, and use that class "polymorphically" via the base. This should have the same effect, given that the original client of Foo does his work through the interface of Foo, as he should
Therefore:
//In Foo.h - may not be modified
struct Foo
{
virtual bool bar(){ return true;}
};
//In FooFoo.h - may not be modified, hence no override...
struct FooFoo: public Foo
{
virtual bool bar(){/**/}
};
//FooFoo_2 - The new class - may be implemented in terms of FooFoo
struct FooFoo_2: public Foo
{
virtual bool bar() override{/*new implementation*/}
};
void fooUser( Foo& foo )
{
bool result = foo.bar();
if (result ){} //etc
}
int main()
{
FooFoo_2 theNewImplementation;
fooUser( theNewImplementation );
return 0;
}
Note also that "override" is not required, but if added, one would get a compiler error if the signature of bar changes in base (which would cause derived to not be virtual anymore) - something that one would want to be aware of.
Regards
No. You can only override a function by declaring the override within the derived class's definition.
In C++ language no. In particular implementation it is technically possible to manually modify vtable for class FooFoo and replace pointer to Foo::bar() to something else. Of course this would be an ugly hack and neither recommended practice in any sense nor guaranteed to work even when something changes (for example compilation flags).
No. You'll need to declare the override in the FooFoo class definition, which you said you cannot do. If you tried to define the overriden function in FooFoo, outside of the class, you'd run into errors, since it was not previously declared to be overriden in FooFoo.
Also note, in C++11 and later, you should use the override attribute. Example:
struct FooFoo : Foo
{
bool bar() override { return true; }
};
I know that I can forward declare a class as follows:
class Foo;
// ... now I can use Foo*
However, can I do something like this:
class Bar {
public:
virtual void someFunc();
};
// ... somehow forward declare Class Foo as : public Bar here
someFunc(Foo* foo) {
foo -> someFunc();
}
class Foo: public Bar {
}
?
Thanks!
You can forward declare Bar as class Bar; and change the signature of someFunc to take a Bar* as parameter. Since someFunc() is a virtual method in the base class, it should work.
After your forward declaration Foo becomes an incomplete type and it will remain incomplete until you provide the definition of Foo.
While the Foo is incomplete any attempt to dereference a pointer to Foo is ill-formed. So to write
foo->someFunc();
you need to provide Foo's definition.