Boost python export singleton - c++

I have a singleton (from boost::serialization):
class LogManager : public boost::serialization::singleton<LogManager> { ... };
And wrapper for getting instance:
inline LogManager &logManager() { return LogManager::get_mutable_instance(); }
What's the right way to bind this into boost.python module?
I tried:
class_< LogManager, boost::serialization::singleton<LogManager> >("LogManager", no_init)
...
;
As a result - a lot of ugly error text in console. What's wrong?

In addition to using bases<...> in the second argument as Autopulated pointed out, I think you also want to specifiy boost::noncopyable as the third template argument, e.g.
bp::class_<LogManager, bp::bases<boost::serialization::singleton<LogManager> >, boost::noncopyable>("LogManager", bp::no_init)
Edit:
Also, you need have a class declaration for any base classes listed, e.g.
bp::class_<boost::serialization::singleton<LogManager>, boost::noncopyable>("Singleton", bp::no_init)
Or, if you don't need access to the base class and won't be exporting any other children of boost::serialization::singleton<LogManager>, then you can omit specifying the base classes in the first place. That is, the following declaration is just fine if all you want to do is expose the LogManager class:
bp::class_<LogManager, boost::noncopyable>("LogManager", bp::no_init)

You want bp::bases< boost::serialization::singleton<LogManager> > as the second template parameter instead.

Related

How can I connect two classes (which don't know eachother) through public interface (C++)

I'm currently working on a project where everything is horribly mixed with everything. Every file include some others etc..
I want to focus a separating part of this spaghetti code into a library which has to be completely independent from the rest of the code.
The current problem is that some functions FunctionInternal of my library use some functions FunctionExternal declared somewhere else, hence my library is including some other files contained in the project, which is not conform with the requirement "independent from the rest of the code".
It goes without saying that I can't move FunctionExternal in my library.
My first idea to tackle this problem was to implement a public interface such as described bellow :
But I can't get it to work. Is my global pattern a way I could implement it or is there another way, if possible, to interface two functions without including one file in another causing an unwanted dependency.
How could I abstract my ExternalClass so my library would still be independent of the rest of my code ?
Edit 1:
External.h
#include "lib/InterfaceInternal.h"
class External : public InterfaceInternal {
private:
void ExternalFunction() {};
public:
virtual void InterfaceInternal_foo() override {
ExternalFunction();
};
};
Internal.h
#pragma once
#include "InterfaceInternal.h"
class Internal {
// how can i received there the InterfaceInternal_foo overrided in External.h ?
};
InterfaceInternal.h
#pragma once
class InterfaceInternal {
public:
virtual void InterfaceInternal_foo() = 0;
};
You can do like you suggested, override the internal interface in your external code. Then
// how can i received there the InterfaceInternal_foo overrided in External.h ?
just pass a pointer/reference to your class External that extends class InterfaceInternal. Of course your class Internal needs to have methods that accept InterfaceInternal*.
Or you can just pass the function to your internal interface as an argument. Something around:
class InterfaceInternal {
public:
void InterfaceInternal_foo(std::function<void()> f);
};
or more generic:
class InterfaceInternal {
public:
template <typename F> // + maybe some SFINAE magic, or C++20 concept to make sure it's actually callable
void InterfaceInternal_foo(F f);
};

Casting inherited template class to parent class

edit: Added the cast-problem.
I have a small C++ problem and hope you can help me with it.
I'm using a library that provides a class GenericHandler. I have to inherit from that class, override stuff and then register my handler with the library to get the magic running. As I need multiple handlers that overlap in some areas, I tried to use templates as follows
template <typename T>
class MyGenericHandler : public GenericHandler
{
// everything used for all handlers goes here
};
class MyIntHandler : public MyGenericHandler<int>
{
};
class MyFloatHandler : public MyGenericHandler<float>
{
};
// in main
std::shared_ptr<MyIntHandler> handler = std::make_shared<MyIntHandler>();
library::HandlerQueue.register(handler);
// error-message: "no viable conversion from shared_ptr<MyIntHandler> to shared_ptr<GenericHandler>.
// Same error if I try it like this:
std::shared_ptr<GenericHandler> handler = std::make_shared<MyIntHandler>();
However, I now can't cast MyIntHandler into the library provided GenericHandler anymore.
It did work before, when I had MyIntHandler : public GenericHandler, so I guess the template somehow broke stuff.
Is there a way to still get it working? Do I need to cast manually, if yes how would I best do that?
Got it fixed by using std::dynamic_pointer_cast it seems; still unsure why #prehistoricpenguin couldn't reproduce it though.

Can use MFC template base class with DECLARE_DYNAMIC()?

I have several views in my app, that are almost the same, so I decided to create a CBaseView class and to not copy the code. So I have something like this:
template <class BASE_T, class BASE_DOC, class BASE_DLG>
class CBaseView : public CListView
{
DECLARE_DYNCREATE(CBaseView<BASE_T, BASE_DOC, BASE_DLG>)
void func1()
{
// GetData() is just another method in CBaseView
BASE_T oData = GetData();
...
}
void func2()
{
BASE_DOC* pDocument = (BASE_DOC*) CView::GetDocumet();
pDocument->DoSomething();
...
}
void func3()
{
...
BASE_DLG oBaseDlg();
oBaseDlg.DoModal();
...
}
}
IMPLEMENT_DYNCREATE(CBaseView<BASE_T, BASE_DOC, BASE_DLG>, CListView)
After that I want to use the CBaseView for the others views:
CMyView : public CBaseView <MyType, MyDocument, MyDlg> {...};
The problem is coming with:
DECLARE_DYNCREATE(CBaseView<BASE_T, BASE_DOC, BASE_DLG>)
and
IMPLEMENT_DYNCREATE(CBaseView<BASE_T, BASE_DOC, BASE_DLG>, CListView)
It gаve me some strange errors. I saw that I can't use this macros with a template class. Also found a similar topic, but I'm quite new in MFC (and in programming like all) and I can't rewrite it so to works for my three template arguments.
I'm worried that I tried everything I could think of and still haven't done it. I really need to find a way to do it or at least an alternative, so guys please help me!
I don't know MFC, but the problem is quite clear: The macros do not accept template instantiations. This is understandable, because macros are expanded first and once you instantiate the template, you wont have CBaseView<BASE_T, BASE_DOC, BASE_DLG> but something like CBaseView<Foo,FooDoc,FooDlG>, ie concrete types for the parameter.
DECLARE_DYNCREATE is to enable creation of instances on the fly at runtime, while templates only exist at compiletime, so at some point you'll need to decide what instantiations of the template you want to use at runtime. You could keep the implementation in the template, but for the types used with the framework you use:
class View1 : public CBaseView<Foo1,FooDoc1,FooDlg1> {
DECLARE_DYNCREATE(View1)
};
IMPLEMENT_DYNCREATE(View1,CListView)
class View2 : public CBaseView<Foo2,FooDoc2,FooDlg2> {
DECLARE_DYNCREATE(View2)
};
IMPLEMENT_DYNCREATE(View2,CListView)

Creating classes to represent different permutations of a type

Suppose I have a class structure like (simplifying the actual classes I have):
class Graph
{
};
class DerivedGraph : public Graph
{
};
class DerivedGraph2 : public Graph
{
};
I want to expand this structure to account for different variations of the same graph. Ideally I would like to be able to do something like:
class Graph
{
};
// Removed
//class DerivedGraph : public Graph
//{
//};
// Removed
//class DerivedGraph2 : public Graph
//{
//};
class DerivedGraph3 : public Graph // really just a mode of DerivedGraph
{
};
class DerivedGraph4 : public Graph // really just a second mode of DerivedGraph
{
};
class DerivedGraph5 : public Graph // really just a mode of DerivedGraph2
{
};
class DerivedGraph6 : public Graph // really just a second mode of DerivedGraph2
{
};
But you can quickly see the problem here -- I am having to create too many classes here. Also, the base class is extremely complex and large (the bottom line is that it just plain sucks) ... so I don't want to make too many structural changes. I want the flexibility of defining things at the level of just the graph itself but at the same time have the flexibility of defining things for a particular mode of one graph type. I would like to be able to use virtual functions such as DoesGraphSupportNormalizedData() or something like that (this is just a simple example). Each class would then override this method.
Another idea I had was to create a separate class structure for the modes themselves (the Graph class would create an instance of it), like:
class BaseMode
{
};
class Mode1 : public BaseMode
{
};
class Mode2 : public BaseMode
{
};
Now the problem is that these mode classes need access to several pieces of data from the Graph class ... and I really don't want to pass all of that information. The mode class would then become just as useless and wouldn't be flexible at all. I just can't think of a clean way to deal with this. The best I could come up with is to have the mode classes do what it can without having to pass all kinds of crap to it but now the interface is just goofy and awkward. Any ideas?
You can either user and interface or use inherited classes from what I can gather from your description.
If you use a base-class and inherit off of it just have the things you don't want derived classes to have just give them the private access modifier and then protected or public for the others (depending on the situation of course). That way your derived classes only take what information they need. You could also have a instance variable that needs to be set in each of lower classes to define things about each derived class. Access modifiers are your friends.
If you use an interface just include everything each graph will need and then when building the individual classes just customize them from there to include the specialties.
If it were up to me, personally, I would go with inheritance over an interface but that's just me.
I ran in this kind of a problem before (and still now and then...)
In this case, you may be taking it the wrong way, what you're looking into is device a specialized function depending on the type of graph and mode. Inheritance is nice, but it has its limits as you mentioned. Especially because the user may want to switch the type of graph, but keep is existing graph object. Inheritance is not helpful in that case.
One way to do something like this is to create functions that get called depending on the current type and mode. Say you have to draw lines and the mode can be set to LINE or DOTS. You could have two functions that draw a line and are specific to a mode or another:
void Graph::draw_line_line(line l)
{
// draw a line
}
void Graph::draw_line_dots(line l)
{
// draw a dots along the line
}
Now you can define a type which represents that type of render functions and a variable member for it:
typedef void (Graph::*draw_line_func)(line l);
draw_line_func m_draw_line;
With that in hands, you can program your set_mode() function, something like this:
void Graph::set_mode(mode_t mode)
{
m_mode = mode; // save for get_mode() to work
switch(mode)
{
case LINE:
m_draw_line = &Draw::draw_line_line;
break;
case DOTS:
m_draw_line = &Draw::draw_line_dots;
break;
...
}
}
Now when you want to render the line, you do call this specialized function and you do not need to know whether it is a LINE or a DOTS...
void Graph::draw_line(line l)
{
this->*m_draw_line(l);
}
This way you create an indirection and make it a lot cleaner in the existing large functions that have large switch or many if() statements without breaking up the existing "powerful" class in many pieces that may become hard to use (because if it's that big it's probably already in use...)

Boost::python - filling a C++ vector of pointer on object of a class in python

Here is my problem. I am supposed to make a python code able to fill a C++ vector of pointer on object of a class of the c++ code. I am using Boost::Python.
It's look as follow:
C++ code:
class A_Base {}
class A_derived_1 {}
...
class A_derived_N {}
class B {
...
setAderivediList(vector<A *> &_AderivedList){}
}
What I need to do in Python:
B.setAderivediList(_AderivedList)
I cannot modified the method in the C++ code, I can only add other objects in-between #ifdef python_interface in order not to impact other developpers work.
At first, I tried to write a converter from what I found on the Internet, but I failed to make it works for my code. Then I tried to add a _AderivedList in class B and a setter which fill the vector. Though it compile in C++, it dosen't work in Python.
New B class:
class B {
...
setAderivediList(vector<A *> &_AderivedList){}
#ifdef myPython_code
public:
vector<A *> * _AderivedListPy;
setAListPy(A * &my_Aderived){ //Actually, I tried without the reference as well
this->_AderivedListPy->push_back(my_Aderived);
};
#endif
}
In python it becomes:
myB = mydll.B()
Ai = mydll.A_derived_i()
myB.setAListPy(Ai) #stopping here
myB.setAderivediList(myB._AderivedListPy)
If I use the reference, it will throw a "python argument types did not match C++ signature" error message at myB.setAListPy(Ai), without the reference, it will stop at the same line without throwing any error message.
Any clue of how I could improve this or any other way to do it?
Thank you in advance.
Actually, I found a solution to my issue.
By filling the vector (including calling setAderivediList) directly in setAListPy.
I just pass an int my_A_derived to setAListPy (actually, along with other arg required by all A_derived class constructors) and use a if condition on my_A_derived.