Is it possible to perform reflection in c++, and instantiate a class given the name of it as a string?
Cheers,
There's no language feature that lets you do this. You can, however, write your own set of factory functions and put those in a string-indexed map.
If you can use MFC, it has a object serialization framework that allows you to do this. This is documented here. Just to clarify, MFC can be used for a UI less application and I have seen it being used in this way quite successfully.
If you can't use MFC, you can consider boost serialization library. But to my knowledge it does not provide a factory function that allows you to create classes given their names. However, it does have the mechanisms to dynamically create classes from their names which you may be able to adapt to your unique needs. The relevant doc is here.
Related
Is it possible to call C++ class library from delphi 2007? What is the way of doing that? I know how to call dll function, but how to deal with class?
There are several ways to do this, but you can't use a C++ class directly. Both useful ways to achieve this require some work and are extensively described here:
Using C++ objects in Delphi (http://rvelthuis.de/articles/articles-cppobjs.html)
Update
OK, I was asked to do an update. The article describes two ways:
Writing and exposing C functions that take the C++ object as (first) parameter (the C++ type is simply passed on as opaque type in Delphi), which simply perform the functionality the class provides by calling the class methods with the right parameters. The C functions can be called from Delphi.
Writing a COM wrapper for the class. The article describes how this can be done in C++.
Details can be found in the article.
You cannot consume C++ classes from Delphi. You will need to wrap them in some other interop friendly manner. For instance:
Wrap the C++ classes with C style functions that expose the functionality.
Expose COM objects that provide the functionality.
I was reading Qt Coding Conventions
and one thing confused me
Things to avoid:
Do not inherit from template/tool classes
What is tool class?
I disagree with Vahid Farahmand answer, a template class is not the same as a tool class.
The documentation for QT tool classes says:
Qt is equipped with a range of capable tool classes, from containers
and iterators to classes for string handling and manipulation. Other
classes provide application infrastructure support, handling plugin
loading and managing configuration files.
These are concrete classes designed to perform a particular function. Template classes provide generic types.
AFAIK it's same. Two names for same thing.
I'm designing (brainstorming) a C++ plugin framework for an extensible architecture.
Each plugin registers an interface, which is implemented by the plugin itself.
Such framework may be running on relatively capable embedded devices (e.g. Atom/ARM) so I can use STL and Boost.
At the moment I've managed to write a similar framework, in which interfaces are known in advance and plugins (loaded from dynamic libraries) register the objects implementing them. Those objects are instantiated as needed by their factory methods, and methods are called correctly.
Now I want to make it more flexible, having plugins register new interfaces (not just implementing the existing ones) thus extending the API available to the framework users.
I thought of using a std::map<std::string, FunctionPtr>, which is also mentioned by several articles and stackoverflow replies I've read. Unfortunately it doesn't seem to capture the case of different method interfaces.
I feel it might have something to do with template metaprogramming, or traits perhaps, but I can't figure out how it should work exactly. Can anyone help?
Try looking at XPCOM which solves these problems for you - by sortof re-implementing COM.
You have the issue of not knowing what interface the plugin provides to your application, so you need a way for the developer to access it, without the compiler knowing what it is (though, if you supply a header file, then suddenly you do know what it is and you can compile it without any need for plugin unknown-interface fanciness)
so, you're going to have to rely on runtime determinism of the interface, that roughly requires you to define the interface in some way so that the framework can call arbitrary methods on it, and I think the only realistic way you can do that is to define each interface as a set of function pointers that are loaded individually and then stored in data for the user to call. And that pretty much means a map of function pointers to names. It also means you can only user compiler niceties (such as overloading) by making the function names unique. The compiler does this for you by 'mangling' all functions to unique, coded names.
Type Traits will help you wrap your imported functions in your framework, so you can inspect them and create classes that work with any imported type, but it isn't going to solve the main problem of importing arbitrary functions.
Possibly one approach that you'll want to read is Metaclasses and Reflection by Vollmann. This was referenced by the C++ standard body, though I don't know if it will become part of a future spec. Alternatively you can look at Boost.Extension
Maybe the first thing you need check is COM.
Anything that can be done with templates, can be done without, though perhaps in a much less convenient way, by writing "template instances" by hand.
If your framework was compiled without seeing a declaration of class MyNewShinyInterface, it cannot store pointers of type MyNewShinyInterface *, and cannot return them to the framework users. No amount of template wizardry can change that. The framework can only store an pass around pointers to some base class. The users will have to do a dynamic_cast to retrieve the correctly typed pointer.
The same is true about function pointers, only functions have no base classes and one will have to do the error-prone reinterpret_cast to retrieve the right type. (This is just another reason to prefer proper objects over function pointers.)
I am looking for recommendation for object serialization/deserialization library in c++? Which one are the most advanced and open-sourced?
Can it handle
Any class that users defined?
Object hierarchy (parent and child classes)?
A Tree of objects? Class A has an attribute of Class B which has an attribute of Class C?
STL containers? Class A has a vector of Class B?
A cyclic of objects? Class A has a pointer pointing to B which has a pointer to A?
I find boost serialization library. I am not sure what is its limitation from http://www.boost.org/doc/libs/1_42_0/libs/serialization/doc/tutorial.html
It really depends what you're looking for. If you're looking for super-fast speed and rapid development within a library, Boost is awesome. If you're looking for super-fast speed, a little more customizability and cross-library binary compatibility, then Qt is a great solution (not saying that Boost can't be made to do this, too). If you're looking for crazy interoperability, then look for a text-based serialization system like JSON (jsoncpp), YAML (yamlcpp) or XML (way too many), each of which have about 8 billion independent libraries.
Protocol buffers is a library developed and used by Google for object serialization that is cross language. It may be a bit different in concept from what you're describing, but it's worth taking a look at.
The Linderdaum Engine Core (iObject, iStaticClass and clLinker objects) provide the custom RTTI for C++.
The idea behind the serialization there is simple: we use an automated source code postprocessor (LSDC) to generate all the save/load code and the registration for all of the metaclassses and properties.
Any object can be serialized to and from the abstract tree-based markup language script. XML and custom JSON-like (we call it XLML) script is supported.
The implementation details are described in this answer: https://stackoverflow.com/a/10332336/1182653
Any class derived from iObject is supported
Object hierarchies are supported
"Trees" of objects are supported
std::vector-like containers (supporting push_back/size semantics) are supported
Well, the properties are defined explicitly and the "pointer fixup" can be performed in a custom iObject::EndLoad() method (redefined in user classes)
I'm working on a C++ project with a large number of classes (150+), each of which has anywhere from 10 to 300 fields or so. I would really like to be able to provide a scripting interface for testing purposes so that I can code callbacks that don't require any re-compilation. I'd like to do this in Lua since I'm more familiar with its C API than I am with Python's, but if it will save headaches I'd be happy to do it in Python.
I've got a solid grasp on how to call Lua functions from my C++ and vice versa, and I know how to pass basic data types back and forth. The question I have is how to share user-specified data types between the two using SWIG.
For example, at some point in my C++, I might want to evaluate a couple of pieces of member data in an object that has 250 fields. I'd like to be able to hand that object off to Lua which could then (hopefully?) use the generated SWIG wrappers to manipulate that object, display certain fields, and then pass the (potentially changed) object back to C++ for continued use.
I would also like to be able to instantiate an instance of the object in Lua using the wrappers and pass it off to C++ to be used as a normal C++ version of the object.
Is this possible? Could somebody point me towards a tutorial or an explicit example?
Thanks for any help you can offer!
As long as you wrap your user-defined types using Swig interfaces (see here for documentation on Swig-Lua API), the interaction should be seamless. The provided Swig wrappers will allow you to instantiate new objects, pass them along to C++ and vice-versa.
I do not believe that Swig-Lua wrapping supports director classes yet, which means that extending existing classes, instantiating them and passing them back to C++ is not possible. Directors are supported for languages such as Python, Java, C# though.
If swig gives you trouble, I've had good luck with the latest version of tolua++, which is for the sole purpose of binding C++ and Lua. It requires a modified .h file as input, which is a bit tedious, but no more so than Swig's modules. I have no reason to prefer one over the other, but it's good to know about both.
You should also check out Luabind. This one implements OOP for Lua and can map classes and data types from Lua back to C++.