Project CAMP - open-source reflection library for C++

[Tank]

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!

[gsaurus]

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 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 ). 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:

[delta224]

I am still somewhat confused on how you would use CAMP with a scripting language such as lua.

[Laurent]

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.

[bullno1]

This looks great.

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]

[delta224]

That makes sense.

When do you think the camp-lua module will be finished.

[Laurent]

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.

[fredouille]

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 ?

[Laurent]

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.

[nulloid]

Just a short question, without reading the whole topic carefully: How did the name come from? Or what does it mean?

[Laurent]

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...

[Nexus]

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!
 
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.

[Laurent]

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.

[Nexus]

I replied in the CAMP forum, here is the corresponding link.

[OniLinkPlus]

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.