SFML community forums
General => General discussions => Topic started by: Laurent on June 15, 2010, 12:55:39 pm
-
Hi
This time I'm not going to talk about SFML, but rather about another project that I'm working on: CAMP.
CAMP is an open-source library (under the LGPL license) that allows to emulate reflection features in C++, like you can find in Java, .Net, etc. In short, reflection allows to manipulate classes, functions, properties and objects dynamically without having to know about (at compile time) their existence, their name or even their prototype.
So what can you do with CAMP? Well, for those who know Qt and its QObjects with abstract signals, slots and properties, you can basically do the same thing with CAMP. But it's not limited to that, we can also imagine a variety of applications based on meta-information: automatic serialization in XML or other format, a generic object editor, writing bindings to script languages in a few lines of code, ...
For example, I think about all the GUI libraries based on CAMP that are being written: they could potentially use CAMP to handle their signals, slots and properties and use them to write XML import/export of widgets, or a designer with a widget editor, etc.
We recently published a brand new website for the community, with a forum, a wiki, a bug tracker, a file repository, etc. :
http://dev.tegesoft.com/projects/camp
Don't hesitate to give me your feedback, and to ask questions if you don't understand everything of CAMP :)
-
Hi, CAMP sounds great. I remember doing serialization in Java many, many years ago.
I believe I used it for networking/file transfer.
I'm curious though, what are the advantages over using a script binding like AngelScript (I was thinking of using that for my GUI setup)?
I assume it would also be good for saving complex game states (which could be reused for netowrking or playback)?
Any other ideas you might have for games/SFML apps?
Maybe a history/undo system?
-
I'm curious though, what are the advantages over using a script binding like AngelScript (I was thinking of using that for my GUI setup)?
I guess that the AngelScript binding allows you to use your classes only in AngelScript :)
CAMP is an abstract binding library, once your classes are declared you can use the binding for anything, not just for the X script language.
I assume it would also be good for saving complex game states (which could be reused for netowrking or playback)?
Absolutely.
Any other ideas you might have for games/SFML apps?
In the game studio where I worked before, we used intensively a similar library of our own in 3 main areas:
- binding the game entities to script (we used GameMonkey)
- automatic import/export to XML
- editing game objects in the level editor
It was really powerful because all that we, the developers, had to write, is the abstract interface of the new classes. Then the game designers would automatically see the new class in their scripts, in the level editor and in the configuration files. And all these three things use the same, unified interface (class, functions and properties names).
It was really a huge time saver!
-
In the game studio where I worked before, we used intensively a similar library of our own in 3 main areas:
- binding the game entities to script (we used GameMonkey)
- automatic import/export to XML
- editing game objects in the level editor
It was really powerful because all that we, the developers, had to write, is the abstract interface of the new classes. Then the game designers would automatically see the new class in their scripts, in the level editor and in the configuration files. And all these three things use the same, unified interface (class, functions and properties names).
It was really a huge time saver!
It looks great from what you say. May be of good help for me since I plan to use Lua, make editors, save/load states etc. However this is quite new for me and I'm not getting how it would effectively help. I know this abstraction level from other languages but I never made big use of it and I never imagined it with C++.
I looked at the CAMP page and its tutorials, but I still don't know how it can ease things, I might need a concrete example of application, an example with CAMP to bind a class to Lua or in a simplistic GUI editor, or to store objects in binary files for example. That may be something to be added on the CAMP wiki tutorials.
What would make someone opt by CAMP instead of luabind to bind classes to Lua? Or to use CAMP to modify objects in a level editor instead of doing the same using the classes themselves? (I'm imagining a class Level witch is a matrix where you add and remove entities, each entity with an integer field energy for instance)
How does the CAMP abstraction surpass the abstraction gained from interfaces (abstract C++ classes), witch already hide modules implementations and enables to modify/change the implementations keeping the same interfaces for scripts/gui editor/storage?
-
I looked at the CAMP page and its tutorials, but I still don't know how it can ease things, I might need a concrete example of application, an example with CAMP to bind a class to Lua or in a simplistic GUI editor, or to store objects in binary files for example. That may be something to be added on the CAMP wiki tutorials.
We're currently working on adding more examples to the wiki :)
But for what you're talking about, which are real-life examples, we'll even write the corresponding generic modules, so that users can directly use them without writing a single line of Python / Lua / XML / GUI / whatever code.
What would make someone opt by CAMP instead of luabind?
Using Luabind would be very similar to using CAMP, but then what? You have a nice binding of all your C++ types so that you can use them in Lua, but nowhere else. If you want to write a Python binding you will have to duplicate the exact same code with boost.python, and do this step over and over for each module that you write.
Declaring a meta-class with its functions and properties is a generic step, it shouldn't be tied to a script language or whetever. That's what CAMP allows. "Bind once, use everywhere".
Or to use CAMP to modify objects in a level editor instead of doing the same using the classes themselves?
This is the other side of the problem. You write some code that allows you to edit objects of class X in an editor, fine. But then you want to edit objects of class Y in the same kind of editor, so what do you do? You have to write the same code, again and again for every class that you want to be able to edit.
Using CAMP, you write the code once using the CAMP abstraction, and badaboum it works for all your classes.
In other words:
Without CAMP
- You say "this class is named X in Lua, it contains ... properties and ... functions in Lua"
- Then you use these declarations in Lua
- You say "this class is named X in Python, it contains ... properties and ... functions in Python"
- Then you use these declarations in Python
- You say "this class is named X in XML, it contains ... properties and ... functions in XML"
- Then you use these declarations in XML
With CAMP
- You say "this class is named X, it contains ... properties and ... functions"
- Then you use these common declarations in Lua, Python, XML, etc.
-
We're currently working on adding more examples to the wiki :)
But for what you're talking about, which are real-life examples, we'll even write the corresponding generic modules, so that users can directly use them without writing a single line of Python / Lua / XML / GUI / whatever code.
I think that the entire concept will be much clearer once this as done. The existing wiki content does a fairly good job explaining how to bind to CAMP, but doesn't really explain how that relates to any other language bindings.
I'm looking forward to further developments with CAMP. Generic handling of language bindings within the compiler itself is a very appealing idea to me.
-
we'll even write the corresponding generic modules, so that users can directly use them without writing a single line of Python / Lua / XML / GUI / whatever code.
Great! :)
"Bind once, use everywhere".
Ok got it about the scripting :wink:
You write some code that allows you to edit objects of class X in an editor, fine. But then you want to edit objects of class Y in the same kind of editor, so what do you do? You have to write the same code, again and again for every class that you want ot be able to edit.
Using CAMP, you write the code once using the CAMP abstraction, and badaboum it worls for all your classes.
What about interfaces? X and Y extends the same abstract C++ interface and so the code remains the same for all classes of same type, what's the advantage of CAMP over that?
(Sorry I may have edited my post while you was answering)
-
What about interfaces? X and Y extends the same abstract C++ interface and so the code remains the same for all classes of same type, what's the advantage of CAMP over that?
But you still have a lot of different interfaces, so a lot of duplicated code. With CAMP, the code remains the same for all your classes (even the ones that you've not written yet).
And interfaces don't allow derived classes to have their own specific members. CAMP does.
-
Hm, I don't know if that convinces me.
And interfaces don't allow derived classes to have their own specific members. CAMP does.
I didn't get it. With CAMP you assume that some functions and properties exists on whatever object you're manipulating. Those objects may have a lot of other things, but they respect the meta-class functions and properties. They can have different names or even be declared in different classes, but the structure of functions and properties is well defined. If you modify the meta class, you have to modify the code that use those objects, right? Same as with interfaces, classes can have a lot of other things inside but from outside you only use what you're expecting (witch is defined on the interface).
I'm not seeing much difference between a meta class and an interface. An interface defines the structure of derived classes, so it's somehow a meta class too. The lack of own members "binded" as public members may be bypassed with getters/setters, no?
-
Ah, I see why you're not convinced, there's something that you haven't figured out yet :)
With CAMP you assume that some functions and properties exists on whatever object you're manipulating
...
they respect the meta-class functions and properties
...
the structure of functions and properties is well defined
...
If you modify the meta class, you have to modify the code that use those objects, right?
This is what you get with a C++ base class, yes. But with CAMP this is no longer true. You're not relying on a fixed, known interface: you ask CAMP what classes exist, and what functions and properties they declare. The code contains nothing hard-coded such as a name or a prototype, everything is abstracted and manipulated dynamically.
This is what reflection is: you ask the class what members it has, you no longer have to know it statically.
-
Hm, well I know.. I think my problem is that I'm not used to deal with dynamic structure :wink:, I'm not seeing where/what dynamic variety can I add to my code that I can't do statically with abstract classes.
Instead of doing "object.call("func");" we can do "object.call(somethingRealisedInRuntime)", and this is the main difference to static interfaces. But I can't imagine how the code that handles those calls can deal with such variety. Whatever the calls are and whatever they do behind, the caller is usually expecting some kind of return value (to handle after the call for example). The caller code is at least partially static, perhaps it can route the results of a dynamic call into another dynamic object, but there's still some "static" communication mechanism inherent.
I see that it gives more flexibility, maybe I'm just not realising how and in what I could use it for my editor tools, what kind of functions would work with that witch can't be or is substantially harder to do with abstract classes. I can't imagine two objects with different interfaces being threatened by the same code, if they are threatened the same way, that's already a defined abstract way of threatening them (then a common interface).
But as for the bindings for XYZ I think it's great. Reminds me of this (http://www.swig.org/), but better as it's a very dynamic approach.
-
Maybe I should give you an example
QWidget* createObjectEditor(const camp::UserObject& object)
{
ObjectEditor* objectEditor = new ObjectEditor;
const camp::Class& metaclass = object.getClass();
for (std::size_t i = 0; i < metaclass.propertyCount(); ++i)
{
const camp::Property& property = metaclass.property(i);
QWidget* memberEditor;
switch (property.type())
{
case camp::boolType :
memberEditor = new BoolEditor(property, object);
break;
case camp::intType :
memberEditor = new IntEditor(property, object);
break;
case camp::realType :
memberEditor = new RealEditor(property, object);
break;
case camp::stringType :
memberEditor = new StringEditor(property, object);
break;
}
objectEditor->addItem(property.name(), memberEditor);
}
return objectEditor;
}
int main()
{
A x1;
std::string x2;
MyFunkyClass x3;
QWidget* editor1 = createObjectEditor(x1);
QWidget* editor2 = createObjectEditor(x2);
QWidget* editor3 = createObjectEditor(x3);
return 0;
}
Don't look in depth into this code, it's crappy and written from scratch :)
But what's important here is that I've written a generic object editor that can work on any class, as long as the class is declared to CAMP. Thanks to CAMP I can dynamically retrieve all the class' properties, and create editor widgets according to their type and name. How can you do that with a C++ base class (one that doesn't provide the features of CAMP from scratch, of course ;))?
But as for the bindings for XYZ I think it's great. Reminds me of this, but better as it's a very dynamic approach.
It's not really the same purpose. SWIG will parse your source files to generate the source code of a module for the script language of your choice. The module is then compiled and loaded directly into the script language, it doesn't interact with your C++ program.
But as for the bindings for XYZ I think it's great.
Then it's great for anything else: accessing your C++ data structures through a script is the same as accessing them through an XML description or from an interactive GUI editor. These are just different ways of manipulating the same layer of abstraction.
-
I see.
How can you do that with a C++ base class (one that doesn't provide the features of CAMP from scratch, of course ;))?
A base class ValueType with methods getType() and getValue(). From this we derive the classes Bool, Int, Real, String (whatever else). Each object that is passed to the editor function may derive from a class with an array of ValueType objects. And the switch does basically the same.
A little bit simplified by no extra code&encapsulations about metaclass based programming (bindings etc). On the class implementations it's not great having such classes for those primitive types (not very annoying anyway, reminds me of java Integer, Boolean etc).
I don't feel secure enough with meta-class programming, the dynamic behaviours are harder to track, I'm not sure.. I don't feel enough control over such abstract variations, a function, a property can be anything. Maybe I'll get used one day and find it really useful and simpler (for codding and code reading) over abstract classes. :roll:
The bindings for scripting/XML/Binary etc, are simpler because we don't have to bind tons of user defined types anymore, they are "translated" to your unified types, which can easily be translated to whatever else. Code the translation CAMP -> XYZ once and everything bound to CAMP will be bound to XYZ, that's how I see it (am I wrong?). As extra advantage, it is used the same way on languages that has this kind of features rooted, making the inter-programming easier.
But if to use within C++ applications only I don't see (yet) many advantages other than the serialization.
-
Kinda obstinate eh..
Well I can see one other simple example : with an UI designer, to connect callback functions.
Imagine an UI designer where you save the function name to be called when an action occurs.
With CAMP you would tell which controller object is to be used when loading the UI, and then the GUI would just have to find the method with that name and call it through CAMP.
Without CAMP, how can you define a dynamic link between a function name and your code ? Unless the UI designer produces source code containing a static class of course (as QTCreator does).
-
Kinda obstinate eh..
Well I can see one other simple example : with an UI designer, to connect callback functions.
Imagine an UI designer where you save the function name to be called when an action occurs.
With CAMP you would tell which controller object is to be used when loading the UI, and then the GUI would just have to find the method with that name and call it through CAMP.
Without CAMP, how can you define a dynamic link between a function name and your code ? Unless the UI designer produces source code containing a static class of course (as QTCreator does).
Ah, if I'm not mistaken I do this a lot in javscript when creating DHTML interfaces and it's very useful (especially since you want the least code possible for compression). Wow, this sounds like CAMP allows a lot the javascript tricks for dynamically generating/using code so you write less overall.
I need to do some experiments later.
The only thing I"m really concerned about is speed/resource overhead.
-
Using CAMP, you write the code once using the CAMP abstraction, and badaboum it works for all your classes.
Haha, this definitely made my day, thanks. ;)
Anyways, like said before, CAMP looks very promising and I'm already testing it out in a separate development branch for SFGUI. Could save me a lot of time and frustration by writing all those switches/extra interfaces just to separate between object types.
Good stuff!
-
Eheh, for callbacks there's always function pointers. An annoying switch can nicely be replaced by indexing a function directly in an array of function pointers (or an hashmap if the key is something like a string).
Those functions has to be added ("registered") to that array/hashmap, so that they can be indexed dynamically. Not even close to CAMP, but it's simple and good enough for a couple of situations.
I though on the functions array/collection for things like what to do when a specific animation of an object ends. Instead of statically checking case by case, I would index the array with the animationID to call the right function.
Anyway, don't take me wrong :P I think the CAMP is a great project because it really brings something new to C++. I may don't feel secure to use it yet probably because of bad experiences with scripting. I really didn't like the lack of structure of some scripting languages, too much dynamism and freeness always brought problems to my code (trying to build up good javascript inheritance was particularly annoying, but that has nothing to do with this :P). Also at univ professors always said that using instanceof in java is bad programming style (but I understand why :lol:). In some contexts reflection is definitely useful, but should be used carefully I think.
I'll probably give CAMP a try sometime, and maybe change my mind :wink:
-
I am still somewhat confused on how you would use CAMP with a scripting language such as lua.
-
I am still somewhat confused on how you would use CAMP with a scripting language such as lua.
It's simple: you write the same stuff as you would with luabind (but using CAMP's API - which is almost the same), you plug the camp-lua module (which is being written) and you can access your classes in Lua scripts for free.
-
This looks great. :D
Thanks for another great library. At first, I thought "No, not another code parser" but I was wrong.
This is nothing new, other scripting engines have done it before but CAMP does it nicely and in a more generic way.
I am still somewhat confused on how you would use CAMP with a scripting language such as lua.
CAMP acts as a bridge between C++ and lua. Of course, you still have to write some glue code.
It can be used like this:
For example if your lua scripts call a function like "shootMonster()".
You bind a generic C++ function to that.
The generic function looks up all registered C++ functions in CAMP and finds whether there is a function named "shootMonster". If there is, it is called, if not, an error is returned.
Hm, well I know.. I think my problem is that I'm not used to deal with dynamic structure Wink, I'm not seeing where/what dynamic variety can I add to my code that I can't do statically with abstract classes
When you bind anything static to something dynamic like a string or number, you just did a bit of reflection. Just think about how a game editor is implemented:
When you select an object in an editor, the editor must call a method like "queryProperties" which returns a set of properties that object has so that it can populate the property panel.
The return value is something like a list of properties:
1) HP , set it with method setHP, at address ..., get it with method getHP at address ...
2) Mana = 20, set it with ... etc
The editor will store these properties name in a hash table and map it with its respective getter/setter... so that it knows what method to call
In the end, this is what CAMP does. Instead of doing it before hand, you do it "on-the-fly".
And how do you implement the "queryProperties()" method?
Mapping a list of getter/setter pointers to the string name of the properites??? Isn't it reflection? Isnt it what CAMP does? :wink: [/quote]
-
That makes sense.
When do you think the camp-lua module will be finished.
-
When do you think the camp-lua module will be finished.
It's hard to tell, there are so many things to do :)
But it's probably a matter of weeks, or a few months in worst case.
-
That makes sense.
When do you think the camp-lua module will be finished.
I understand the question... we are all getting excited about that stuff :-)
Maybe some guys could help Laurent and his team to get things done faster ?
Laurent, would you welcome any help ? how would we proceed ?
-
Maybe some guys could help Laurent and his team to get things done faster ?
Laurent, would you welcome any help ? how would we proceed ?
Sure! We somehow rely on the community to make the CAMP modules repository grow quickly. The cool thing is that whenever someone writes a CAMP-based piece of code, it can most likely be generic enough to be used by others. Reusability is the keyword here.
So go ahead, you can follow your inspiration and write whatever you like based on CAMP :)
You can then use the wiki and/or forum to expose your work to the other users, and get feedback and improvements.
-
Just a short question, without reading the whole topic carefully: How did the name come from? Or what does it mean?
-
How did the name come from? Or what does it mean?
Ah ah, I was waiting for this question :lol:
The meaning of CAMP is mystic, nobody really knows what it stands for, even among the core developers. It's a remake of an old project named CAMP, so we simply decided to keep the same name.
At Tegesoft we have our own idea of what it could mean, but let's keep some secret about it... ;)
-
Laurent, I have installed your library and experimented a little bit... And I have to say CAMP offers very interesting concepts which I haven't seen in C++ before. Actually, I'm not quite used to reflection, but I'm sure there is a huge field of application. Already the ability to easily serialize and to interact with script languages looks very promising. You have to know, I'm quite interested in the C++ language itsself, and it's always amazing for me if someone shows me completely new designs and possibilities. Great work! :D
I also have some questions regarding your library. First of all, is there a type for global functions that are not related to classes? I have only seen ClassBuilder::function() and therefore meta-functions forming a class's interface. Or can we use the Function class to declare own functions?
Second, can we expand the meta-declaration of a class after the first invocation of Class::declare()? The only way I see is to pass the ClassBuilder around, or is there a possibility to augment the declaration only by knowing the name (and C++ type)? Probably, this is disallowed by design... I could imagine use cases when free functions are not immediately in the header file of the class definition provided. But if it is possible to declare functions independently, this point becomes less relevant.
And it's a little pity that the compilation time is so high (not only using tricky things like meta-declarations, already including the CAMP headers requires a lot of time). I think there are many templates which can't be moved into separate modules. Do you know some parts which are particularly expensive? I guess, Boost which isn't known for its "templatelessness" and short compile time, also contributes its part. ;)
However, it's acceptable when one can use precompiled headers.
-
Thanks for your feedback.
Actually, I'm not quite used to reflection, but I'm sure there is a huge field of application
People are usually confused when thinkg about CAMP in terms of reflection. A better definition would be that CAMP allows to expose your C++ data types to third-party dynamic modules based on string input. In other words, CAMP can be useful everywhere you want to manipulate an object outside the C++ code itself (config file, script, GUI editor, network, database, ...).
I also have some questions regarding your library. First of all, is there a type for global functions that are not related to classes? I have only seen ClassBuilder::function() and therefore meta-functions forming a class's interface. Or can we use the Function class to declare own functions?
There's currently no support for "global scope" functions and properties. Someone already asked this same question on the official forum, and it's something that may be interesting so we'll think about it for a future release.
By the way, don't hesitate to visit the official forum and ask any additional questions there, so that other CAMP users can see the answers ;)
Second, can we expand the meta-declaration of a class after the first invocation of Class::declare()? The only way I see is to pass the ClassBuilder around, or is there a possibility to augment the declaration only by knowing the name (and C++ type)? Probably, this is disallowed by design... I could imagine use cases when free functions are not immediately in the header file of the class definition provided. But if it is possible to declare functions independently, this point becomes less relevant.
This is possible if you keep the ClassBuilder, but it's not the expected usage. It is a design choice that the interface of a meta-class is static, because it binds static stuff (C++ members). All camp entry points to meta-classes return a const camp::Class&, only the ClassBuilder has a write access to them.
I can't see any reason why someone would have to bind a new member at runtime, do you have an example?
And it's a little pity that the compile time is so high (not only using tricky things like meta-declarations, already including the CAMP headers requires a lot of time). I think there are many templates which can't be moved into separate modules. Do you know some parts which are particularly expensive?
CAMP itself is very cheap to compile, so I'm a little surprised that you found that including headers already takes some time. We designed it so that only the meta-classes declarations are expensive for the compiler, and that's why we recommend to put them in separate cpp files. But the rest of the API shouldn't be long to compile.
-
I replied in the CAMP forum, here (http://dev.tegesoft.com/projects/camp/forum/viewtopic.php?f=6&t=5) is the corresponding link.
-
I've read over the website and parts of the wiki, but I'm having trouble understanding exactly what this does. Could I use it for, say, storing a string in a text file, then creating an instance of a class with that exact name at runtime? If so, this may be just what I have been looking for for the last several months.
-
Could I use it for, say, storing a string in a text file, then creating an instance of a class with that exact name at runtime?
Yes you can. Although it's a little bit overkill, if it's all that you need maybe you should "simply" use a factory.
-
Could I use it for, say, storing a string in a text file, then creating an instance of a class with that exact name at runtime?
Yes you can. Although it's a little bit overkill, if it's all that you need maybe you should "simply" use a factory.
See, the problem is that I'm writing an engine that will have the people that use the engine make their own object classes, and I need the game to be able to create these objects on the fly, so a factory would probably not work. What I want to do is just have them call a macro to add the object to a list of usable objects that are stored as strings. I'm assuming this is the best option?
-
CAMP wouldn't make things easier for users of your engine. Registering a new class to a factory can be done with one line of code. Declaring a new CAMP meta-class requires a little more.
-
Line 86 of the file include/camp/value.inl has an extra ';' at the end. G++ complains about that with -Wfatal-errors.
Also, in your "quick example" you state the following:
CAMP_TYPE( Person );
The ';' at that position throws an "extra ';'" error message, too. That definitely has something to do with my restrictive warnings and errors settings, however they can be simply avoided. :)
-
Line 86 of the file include/camp/value.inl has an extra ';' at the end
Fixed.
The ';' at that position throws an "extra ';'" error message, too. That definitely has something to do with my restrictive warnings and errors settings, however they can be simply avoided.
Ah, you're right. I never remember which macros must be ended with a ";" and which mustn't (even the ones that I write), so I always put one. I didn't know that g++ would complain about it. I'll fix the examples, thanks.
-
I didn't know that g++ would complain about it. I'll fix the examples, thanks.
It won't without the proper flags. But I always compile in the highest level possible, that's why those came up.
Thanks for fixing.
Edit:
Another question: Is it possible to somehow get rid of the initialization (binding) functions? I'm currently playing around with it in SFGUI and I don't like the fact very much that there has to be a function "InitCAMPWrappers()" or similar to initialize all the bindings.
That alone wouldn't be a problem, but when users are extending the GUI with own widgets and distribute them, then developers who use them have to take care of calling the foreign initialization functions.
I'm already thinking about code to automatically accomplish this, but couldn't get to a solution yet (one was to provide a Widget::InitImpl, that gets automatically called when an object of a widget type is constructed, but the time this is called could be much too late, for example when widgets are going to be deserialized).
Edit²:
Wait.. Initialization doesn't really take place in a free function, right? I mean, you create an object of type camp::Class::declare<..>, right? That'd mean that this can take place directly in the widget's source file.
Edit³:
Just tried that out. Since members are directly called, this can't be done in global scope. :(
-
What you need is CAMP_AUTO_TYPE instead of CAMP_TYPE.
PS: you should come to the official forum if you have more questions about CAMP, don't forget that we're still on the SFML forum here ;)
-
Should have just read the wiki, thank you very much. This simplifies things a lot!
-
A generic XML module is now available:
http://dev.tegesoft.com/projects/camp/wiki/Camp_xml
-
Oh, wow, this library looks awesome. Just what I was looking for! At last I wont have this bad feeling that I'm doing a bunch of redundant work when I need serialization and scripting in my application. Please don't tell me the project is dead (no updates since 6 months?).
-
Please don't tell me the project is dead (no updates since 6 months?).
Well, our company had to switch to other projects and nobody currently works on it. I'd like to maintain it on my free time, but I can't. However, anybody can contribute.
-
Well, our company had to switch to other projects and nobody currently works on it. I'd like to maintain it on my free time, but I can't. However, anybody can contribute.
Sad to hear that it is currently unmaintained! I believe there is a lot of potential for such a project. C++ is definitely lagging behind other languages when it comes to reflection.
I guess the good news is that the project already looks pretty solid. Hopefully I will soon have some time to take a detailed look at it and try it out in a simple application.
-
Took a brief look. It's exactly what I needed!
I had some projects in mind that needed scripting, but the more I thought about it, the more complex it looked, and I complicated it even more because I didn't want to limit myself to just one scripting language. I thought about implementing a whole wrapper with abstract factories around many scripting engines but gave up on the idea.
I suppose the automatic binding with scripting languages is still in development or will be a module to CAMP, right?
-
I suppose the automatic binding with scripting languages is still in development or will be a module to CAMP, right?
Well, since Laurent mentioned that the project is unmaintained I wouldn't hold my breath. But I really hope that the community can provide functionality like this. The great thing about CAMP is that only one user needs to write a module that can generate bindings based on CAMP reflection and everybody having classes exposed through CAMP could use it. So if someone writes a module for Lua and someone else writes one for Python - *bam* you already have two scripting languages supported. If the modules are tested and high enough quality, I'm sure there would be a chance of getting accepted into the CAMP codebase.
-
Hello, Laurent.
Sorry for this necroposting, I know, that CAMP is discontinued, but I wonder if it's sources are still available somewhere? Old link to dev.tegesoft.com seems dead :(
-
CAMP is hosted on github: https://github.com/tegesoft/camp
Check the forks, someone has worked hard on CAMP after we stopped.
-
Oh, many thanks! :)
-
CAMP is hosted on github: https://github.com/tegesoft/camp
Check the forks, someone has worked hard on CAMP after we stopped.
Hi Laurent, I am looking for more information on CAMP and I am currently having trouble accessing the tegesoft forums, e.g. this link: http://dev.tegesoft.com/projects/camp/forum/viewtopic.php?f=6&t=5
Do you know if the forums are offline or if they have moved somewhere? I am finding many different options for so-called "reflection" in C++, and I think that CAMP is the most promising one in terms of having a minimal set of powerful capabilities. My doubts are with regard to how "future proof" it is since I will be trying to work it into my environment which is iOS development with C++11.
-
There's no more support for CAMP from Tegesoft. We stopped working on it more than 2 years ago.