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

[Laurent]

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.

[OniLinkPlus]

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?

[Laurent]

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.

[Tank]

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:

Code: [Select]


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.

[Laurent]

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.

[Tank]

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.

[Laurent]

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

[Tank]

Should have just read the wiki, thank you very much. This simplifies things a lot!

[Laurent]

A generic XML module is now available:
http://dev.tegesoft.com/projects/camp/wiki/Camp_xml

[kloffy]

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

[Laurent]

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.

[kloffy]

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.

[kaoD]

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?

[kloffy]

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.

[fJerr]

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