I wrote some code and got scared that it will not work - so I wrote a prototype:
#include <boost/function.hpp>
#include <boost/bind.hpp>
#include <iostream>
class base {
private:
boost::function<void (int)> action;
protected:
virtual void onDataBaseReady(int i) { std::cout << i << std::endl; }
public:
void call() {
action(10);
}
base() {
action = boost::bind(&base::onDataBaseReady, this, _1);
}
};
class child : public base {
protected:
virtual void onDataBaseReady(int i) { std::cout << i+10 << std::endl; }
};
int main()
{
static child c;
c.call();
std::cin.get();
return 0;
}
that compiles and works. (outputs 20). But Why? Also I tested under VS2010 and wonder if it would work across platforms (say compiled under GCC)?
Mainly action = boost::bind(&base::onDataBaseReady, this, _1); scares me - we say &base::...
A pointer to a virtual method does a virtual function lookup when called.
#include <iostream>
#include <memory>
struct base {
virtual void foo() { std::cout << "base\n"; }
virtual ~base() {}
};
struct derived:base {
void foo() override final { std::cout << "derived\n"; }
};
int main() {
void (base::*mem_ptr)() = &base::foo;
std::unique_ptr<base> d( new derived() );
base* b = d.get();
(b->*mem_ptr)();
}
so, it "just works". The member function pointer (this->*&base::foo)() is not the same as a fully qualified function call this->base::foo(). The first is a way to store the foo part of calling this->foo(), the second is a way to skip virtual method lookup and directly call base::foo.
Mainly action = boost::bind(&base::onDataBaseReady, this, _1); scares me - we say &base::...
It would actually be much more scary if it performed static dispatch, rather than dynamic dispatch. Consider this simple example:
struct base {
virtual void foo() { /* maintain some invariants */ }
};
struct derived : base {
virtual void foo() { /* maintain different invariants */ }
};
And then consider that you bind the function at the parent and call it on the derived object. The implementor of derived knows what invariants apply to the derived type, which might be the same, a subset or completely different than the invariants in the base type.
void apply(base & b) {
std::bind(&base::foo, &b)();
}
If dispatch was resolved at binding time, and the functor was applied to the derived type (of which you might not know the exact type!) then the invariants of the derived type might be broken. In the context of the apply function it is impossible to know what the object really is, or what the invariants of that type are, so what you probably want to do is let dynamic dispatch do its magic.
[That is from a high level design point of view, without even going into the detail that you cannot use a pointer to member to perform static dispatch...]
Related
I've been wondering if it's possible for the client / user to decide what function to run from the class.
For example, Say I have the following function:
std::vector<double> greeks_mesh_pricer(const Greeks& Greek, (function to Run), int mesh_size) {
std::vector<double> result;
for(int i = 0; i < mesh_size; i += mesh_size) {
result.push_back(Greek.(function to run));
}
}
Function to run, is a member function of the Greek class. Greeks here is an interface containing pure virtual functions, so the user is actually passing
in a Derived class of Greeks. So if the client specifies the function Delta(), it returns a vector of Delta() results, etc.
You can do it with pointers to member functions:
#include <iostream>
struct Base {
virtual ~Base() {}
virtual void foo() const = 0;
virtual void bar() const = 0;
};
struct Derived1 : Base {
void foo() const { std::cout << "Derived1::foo\n"; }
void bar() const { std::cout << "Derived1::bar\n"; }
};
struct Derived2 : Base {
void foo() const { std::cout << "Derived2::foo\n"; }
void bar() const { std::cout << "Derived2::bar\n"; }
};
void invoke(const Base &b, void (Base::*func)() const) {
(b.*func)();
}
int main() {
Derived1 d1;
Derived2 d2;
invoke(d1, &Base::foo);
invoke(d2, &Base::foo);
invoke(d1, &Base::bar);
invoke(d2, &Base::bar);
}
Output
Derived1::foo
Derived2::foo
Derived1::bar
Derived2::bar
Windows has implemented that sort of automation with IDispatch, you can implement a similar one if not using Windows. The idea is to specify a function by ID (or translated from a name) and to pass the arguments as VARIANTs.
You might be asking about function pointers in C++. Just like a pointer can be use to reference a variable or object, similarly pointers can be used to reference a function as well and you can also pass a function to a function using these pointers or create an array of pointers where each pointer is actually a function pointer (reference to a function).
Read here : https://www.cprogramming.com/tutorial/function-pointers.html
You can use std::function to represent and store a function. You can also use std::bind and std::placeholder to facilitate the whole thing. Example:
struct A {
int f(int);
int g(int);
};
A instance;
std::function<int(int)> client_fn;
using namespace std::placeholders;
if (...) {
client_fn = std::bind(&A::f, &instance, _1);
} else {
client_fn = std::bind(&A::g, &instance, _1);
}
I have a base interface, declaration like this - IBaseTest.h:
#pragma once
template <class T1>
class IBaseTest
{
public:
virtual ~IBaseTest();
virtual T1 DoSomething() = 0;
};
And two children who overrides DoSomething() CBaseTest1 claass in - BaseTest1.h:
#pragma once
#include "IBaseTest.h"
class CBaseTest1: public IBaseTest<int>
{
public:
virtual int DoSomething();
};
BaseTest1.cpp:
#include "BaseTest1.h"
int CBaseTest1::DoSomething()
{
return -1;
}
And CBaseTest2 in - BaseTest2.h
#pragma once
#include "IBaseTest.h"
class CBaseTest2: public IBaseTest<long long>
{
public:
virtual long long DoSomething();
};
BaseTest2.cpp:
#include "BaseTest2.h"
long long CBaseTest2::DoSomething()
{
return -2;
}
So CBaseTest1::DoSomething() overrides return type to int, and CBaseTest2::DoSomething() to long long. Now, i want to use a pointer to the base interface, to work with those classes, and there i have the problem:
#include "IBaseTest.h"
#include "BaseTest1.h"
#include "BaseTest2.h"
int _tmain(int argc, _TCHAR* argv[])
{
IBaseTest<T1> * pBase = NULL;
pBase = new CBaseTest1();
cout << pBase->DoSomething() << endl;
pBase = new CBaseTest2();
cout << pBase->DoSomething() << endl;
getchar();
return 0;
}
The problem is i cannot declare IBaseTest<T1> * pBase = NULL; T1 is undefined. If declare the template before _tmain like this:
template <class T1>
int _tmain(int argc, _TCHAR* argv[])
{
...
}
I get: error C2988: unrecognizable template declaration/definition
So what do i put here instead of T1?
IBaseTest<??> * pBase = NULL;
The problem is that T1 parameter needs to be known when you instantiate an object of the template class IBaseTest. Technically, IBaseTest<int> and IBaseTest<long long> are two different types without a common base and C++ does not allow you to declare a variable IBaseTest<T1> pBase = NULL; where T1 is determined at runtime. What you are trying to achieve is something that would be possible in a dynamically typed language, but not in C++ because it is statically typed.
However, if you know the expected return type of DoSomething whenever you call that method, you can sort of make your example to work. First, you need to introduce a common base class that is not a template:
#include <typeinfo>
#include <typeindex>
#include <assert.h>
class IDynamicBase {
public:
virtual std::type_index type() const = 0;
virtual void doSomethingVoid(void* output) = 0;
template <typename T>
T doSomething() {
assert(type() == typeid(T));
T result;
doSomethingVoid(&result);
return result;
}
virtual ~IDynamicBase() {}
};
Note that it has a template method called doSomething that takes a type parameter for the return value. This is the method that we will call later.
Now, modify your previous IBaseTest to extend IDynamicBase:
template <class T1>
class IBaseTest : public IDynamicBase
{
public:
std::type_index type() const {return typeid(T1);}
void doSomethingVoid(void* output) {
*(reinterpret_cast<T1*>(output)) = DoSomething();
}
virtual T1 DoSomething() = 0;
virtual ~IBaseTest() {}
};
You don't need to change CBaseTest1 or CBaseTest2.
Finally, you can now write the code in your main function like this:
IDynamicBase* pBase = nullptr;
pBase = new CBaseTest1();
std::cout << pBase->doSomething<int>() << std::endl;
pBase = new CBaseTest2();
std::cout << pBase->doSomething<long long>() << std::endl;
Note that instead of calling pBase->DoSomething(), we now call pBase->doSomething<T>() where T is a type that must be known statically where we call the method and we provide that type at the call site, e.g. pBase->doSomething<int>().
The language does not allows to do directly what you are trying to do. At that point, you should ask yourself if that is the right solution for the problem.
The first approach that might work well assuming that you don't have too much different operations to do for each type would be to simply do the action in the function itself instead of returning type that are not related through inheritance.
class IBaseTest
{
public:
virtual void OutputTo(std::ostream &os) = 0;
};
class CBaseTest1
{
public:
virtual void OutputTo(std::ostream &os) override;
private:
int DoSomething();
};
void CBaseTest1OutputTo(std::ostream &os)
{
os << DoSomething() << std::endl;
}
If you have only a few types but a lot of operation, you might use the visitor pattern instead.
If you mainly have operation that depends on type, you could use:
class IVisitor
{
public:
virtual void Visit(int value) = 0;
virtual void Visit(long value) = 0;
};
Otherwise, use that which is more general
class IVisitor
{
public:
virtual void Visit (CBaseTest1 &test1) = 0;
virtual void Visit (CBaseTest2 &test2) = 0;
};
Then in your classes add an apply function
class IBaseTest
{
public:
virtual void Apply(IVisitor &visitor) = 0;
};
In each derived class, you implement the Apply function:
void CBaseTest1 : public IBaseTest
{
virtual void Apply(IVisitor &visitor) override
{
visitor.Visit(this->DoSomething()); // If you use first IVisitor definition
visitor.Visit(*this); // If you use second definition
};
And for creation purpose, you could have a factory that return the appropriate class from a type tag if you need to create those class from say a file…
One example assuming you want a new object each time:
enum class TypeTag { Integer = 1, LongInteger = 2 };
std::unique_ptr<IBaseTest> MakeObjectForTypeTag(TypeTag typeTag)
{
switch (typeTag)
{
case TypeTag::Integer : return new CBaseTest1();
case TypeTag::LongInteger : return new CBaseTest2();
}
}
So the only time you would do a switch statement is when you are creating an object… You could also use a map or even an array for that...
The right approach depends on your actual problem.
How many CBaseClass* do you have?
Do you expect to add other classes? Often?
How many operations similar to DoSomething() do you have?
How many actions that works on the result of DoSomething do you have?
Do you expect to add other actions? Often?
By responding to those questions, it will be much easier to take the right decision. If the action are stables (and you only have a few one), then specific virtual functions like OutputToabove is more appropriate. But if you have dozen of operation but don't expect much changes to ITestBase class hierarchy, then visitor solution is more appropriate.
And the reason why a given solution is more appropriate in a given context is mainly the maintenance effort when adding classes or actions in the future. You typically want that the most frequent change (adding a class or an action) require les changes everywhere in the code.
The same question exists for C#, but does not apply to C++.
class Base
{
void dispatch()
{
if (newStyleHasBeenOverridden()) //how to find this out?
newStyle(42);
else
oldStyle(1, 2);
}
virtual void oldStyle(int, int) { throw "Implement me!"; }
virtual void newStyle(int) { throw "Implement me!"; }
}
class Derived:public Base
{
void newStyle(int) override
{
std::cout<<"Success!";
}
}
WARNING: This solution is not cross-platform in that it relies on a GCC extension and some undefined behavior.
GCC allows a syntax to grab the pointer to the function from the vtable of this by saying this->*&ClassName::functionName. It is probably not a good idea to actually use this, but here's a demo anyway:
#include <iostream>
class Base {
public:
void foo() {
auto base_bar_addr = reinterpret_cast<void*>(&Base::bar);
auto this_bar_addr = reinterpret_cast<void*>(this->*&Base::bar);
std::cout << (base_bar_addr == this_bar_addr ? "not overridden" : "overridden") << std::endl;
}
virtual void bar() { };
};
class Regular : public Base { };
class Overriding : public Base {
public:
virtual void bar() { };
};
int main() {
Regular r;
r.foo();
Overriding o;
o.foo();
}
And for posterity:
ICC allows the syntax, but it has a different meaning, which is the same as just saying &Base::bar, so you'll always think it isn't being overridden.
Clang and MSVC reject the code outright.
This is a design problem.
However, in the interest of answering the actual question, there are a couple ways you could accomplish this without a redesign (but really, you should redesign it).
One (terrible) option is to call the newstyle method and catch the exception that occurs if it's not overridden.
void dispatch() {
try {
newStyle(42);
} catch (const char *) {
oldStyle(1, 2);
}
}
If newStyle has been overridden, the override will be called. Otherwise, the base implementation will throw, which dispatch will catch and then fall back to oldStyle. This is an abuse of exceptions and it will perform poorly.
Another (slightly less terrible) approach is to make the base implementation of newStyle forward to oldStyle.
void dispatch() {
newStyle(42);
}
virtual void newStyle(int) { oldStyle(1, 2); }
virtual void oldStyle(int, int) { throw "implement me"; }
This at least moves in the direction of a better design. The point of inheritance is to allow high level code to be able to use objects interchangeably, regardless of their specialization. If dispatch has to inspect the actual object type, then you've violated the Liskov Substitution Principle. Dispatch should be able to treat all the objects the same way, and any differences in behavior should arise from the overridden methods themselves (rather than the existence of overrides).
Making things simpler, the dispatch decision is done by the Derived class. Abstract Base class is basically just an "interface" where the Derived class should implement all virtual functions.
The problem too sounded like an XY problem.
I thought this is what you want:
class Base // abstract class
{
virtual void oldStyle(int, int) = 0; // pure virtual functions
virtual void newStyle(int) = 0; // needs to be implemented
};
class Derived:public Base
{
public:
Derived(bool useNewStyle): _useNewStyle(useNewStyle) {}
void newStyle(int) { std::cout << "new style"; }
void oldStyle(int, int) { std::cout << "old style"; }
void dispatch()
{
if (_useNewStyle) {
newStyle(42);
return;
}
oldStyle(1, 2);
return;
}
private:
bool _useNewStyle = false;
};
Derived d(true); // use new style
d.dispatch(); // "new style"
I have a base class Base, with many derived classes (eg. Derived1, Derived2). Base has a pure virtual function fn, which is called many times using a Base pointer. Every time the function is called, I need to do some extra logging and related stuff. In particular, I use BOOST_CURRENT_FUNCTION in the derived-class functions to find out which function was called. Is there a way to know this information before calling the function, so that I do not have to rewrite the bookkeeping code in every derived function?
Edit: I wish to avoid writing __PRETTY_FUNCTION__ in each derived function.
#include <iostream>
using namespace std;
class Base {
public:
virtual void fn() = 0;
};
class Derived1:public Base {
public:
void fn() {
cout<<__PRETTY_FUNCTION__<<endl;
}
};
class Derived2:public Base {
public:
void fn() {
cout<<__PRETTY_FUNCTION__<<endl;
}
};
int main()
{
int choice =0;
Base *ptr1 = nullptr;
cout<<"Choose 0/1: "<<endl;
cin>>choice;
if(choice == 0) {
ptr1 = new Derived1;
}else {
ptr1 = new Derived2;
}
//********CAN I WRITE SOMETHING HERE, TO GIVE THE SAME RESULT?
ptr1->fn();
}
No, it cannot be. C++ does not support this kind of introspection. __PRETTY_FUNCTION__ is all you're gonna get.
From your description it seems you migth have a design issue. Have you considered using the template method design patter? The idea is to have your base class implement the common functionality and through virtual functions implement the specifics in your derived classes.
One idea is to implement the base pure virtual function and call it in each derived override. In the base one you increment a static counter. Something like:
#include <iostream>
#include <memory>
struct Base
{
static size_t counter;
virtual void f() = 0;
virtual ~Base() = default;
};
size_t Base::counter{0};
void Base::f() // IMPLEMENTATION, yes it's possible to implement a pure virtual function
{
++counter;
}
struct Derived1: Base
{
void f() override
{
Base::f(); // increment the counter
std::cout << "Derived1::f()\n";
}
};
struct Derived2: Base
{
void f() override
{
Base::f(); // increment the counter
std::cout << "Derived2::f()\n";
}
};
int main()
{
std::unique_ptr<Base> pBase1{new Derived1};
std::unique_ptr<Base> pBase2{new Derived2};
pBase1->f();
pBase1->f();
pBase2->f();
std::cout << Base::counter << std::endl; // outputs 3
}
Live on Wandbox
If I'm not wrong I believe this is an instance of the Template Method design pattern mentioned by #LordDosias. There is no other intrinsic way of getting this information out from the language, as C++ does not have genuine runtime reflection capabilities.
Well, aside from wrapping your macro in another macro that is smaller/shorter/does more, there is nothing that will provide the name of a function for you.
#define WHERE cout << __PRETTY_FUNCTION__ << endl
...
void fn() {
WHERE;
}
This also means you can turn on/off the tracing trivially:
#if TRACING
#define WHERE cout << __PRETTY_FUNCTION__ << endl
#else
#define WHERE
#endif
(You may want to wrap that in do { ... } while(0) in both sides to avoid problems if you were to put a WHERE inside an if, or some such, and still want it to work correctly when when it's "nothing")
The simplest answer is that, since C++ doesn't have auxiliary methods, you have to split the implementation of fn into a utility wrapper and the virtual function proper:
class Base {
protected:
virtual void fn_impl() = 0;
public:
void fn() { fn_impl(); }
};
class BaseWithLogging: public Base {
public:
void fn(); {
/* do logging */
fn_impl();
}
};
If you want the logs to capture the exact identity of the virtual (function name, file, line number, ...) which is actually, then there is no workaround for that; the boilerplate has to go into the function.
The crusty old preprocessor can be of help. E.g. simple-minded illustration:
#define LOG (cout<<__PRETTY_FUNCTION__<<endl)
and then you just have
LOG;
at the beginning of the function.
Browsing in a code base I found something on the line of:
class Interface{
public:
virtual void func() = 0;
};
class Implementation : public Interface{
protected:
void func() override {};
};
I thought that would have been a compilation error, but it seems it is not. What sense does it make?
In C++:
accessibility is a “static” notion (checked at compile-time), whereas
virtual dispatch is a “dynamic” notion (the implementation to call is chosen at run-time).
We can say that C++ keeps those two notions “orthogonal”.
So with your example, this will compile (not realistic code, just illustration):
Implementation obj;
Interface& ref = obj;
ref.func(); // (will call obj.func())
but this won't:
Implementation obj;
obj.func(); // error: Implementation::func is protected
effectively “forcing” you to only use the interface (which maybe was the intent). — Edit: see Dieter Lücking's answer for a maybe better design.
Freedom. Sometimes it may be kind of useful (for example if you want to hide a member you want to discourage to be used). At least when they access through derived class.
See it as kind of "explicit implementation". Let's say, for example, you have a base interface List like this (very simplified code for illustration purposes):
class List {
public:
virtual void add(std::string item) = 0;
virtual std::string at(int index) = 0;
};
You create your ReadOnlyList concrete class which implements List interface, in this case you would discourage users of your class to call add() method, just change its visibility. Unless they're accessing it through List interface it'll be hidden.
Another example? If you want to provide an interface for some specific tasks but it's an implementation detail and it's not part of class contract. In this case you make them protected or private and they won't be accessible.
That said it's so weak and confusing that I would avoid to do it, besides very few, commented and well controlled exceptions.
What sense does it make?
Yes, it makes sense. If you try to create object of Derived type, you will not be able to call that method. So the idea is to always access the object through it's interface.
The idea is to enforce the Interface segregation principle.
#include <iostream>
#include <vector>
#include <memory>
struct Base
{
public:
virtual ~Base(){}
virtual void foo() = 0;
};
struct Derived1 : Base
{
protected:
virtual void foo(){
std::cout << "foo 1" << std::endl;
}
};
struct Derived2 : Base
{
protected:
virtual void foo(){
std::cout << "foo 2" << std::endl;
}
};
void wouldFail()
{
Derived1 d;
// d.foo(); -- Error! Do not try to call it directly
}
void ok()
{
std::vector< std::shared_ptr< Base > > v;
v.emplace_back( std::make_shared<Derived1>() );
v.emplace_back( std::make_shared<Derived2>() );
for ( auto & it : v )
it->foo();
}
int main()
{
wouldFail();
ok();
}