CAMP

[jacmoe]

I've always had this on my long-standing todo list..
A flexible, extensible and declarative, reusable binding library.
Figuring that if I waited long enough, someone would beat me to it.

And, someone did:

CAMP - "Bind once, use everywhere"

Just like LuaBind, but without Lua.
Properties emulation layer for C++.

For things like serialisation, GUI interaction (properties), pluggable components, scripting...

I am really going to dig into this library - and make it a central building block of whatever I am working on!

It's really neat.

Being a lazy SOB, I really like not repeating myself (or reinvent any wheels).

Thoughts?
Ideas?

[madmarx]

yes, this was presented a while ago on the french forum 'developpez'.
I think its the same guy who did SFML who wrote this one (laurent gomila).
I wrote one almost identical before hearing of it, though. I tried also boost.mirror.

I think camp is enough though. There is no reason you got a problem with this lib. Appart from the fact that when you update your class, you got to update also your binding code (grrr!).

The fact that you have to update the your binding code after the code itself was not lazy enough for me. This is a reason why I wrote systems that allowed to do both simultaneously (either in pure C++, or with a preprocessor).

If you want only attributes binding, it seems boost.fusion basically does the conversion between classes and tuples.

Still CAMP is a very good choice.

Pierre

[jacmoe]

I am getting increasingly curious about your creation ...

[Kojack]

Aww, I was hoping this was a proposal for an Ogre camping trip.

[Laurent]

I wrote one almost identical before hearing of it, though. I tried also boost.mirror.

I'd be very insterested to hear about your experience with boost.mirror, and the one you wrote

The fact that you have to update the your binding code after the code itself was not lazy enough for me. This is a reason why I wrote systems that allowed to do both simultaneously (either in pure C++, or with a preprocessor).

The good thing about CAMP is that the minimum required to make it work is standard C++ code, but nothing prevents you from using third-party tools on top of it like a precompiler, to automate the declaration step.
I think that CAMP definitely needs a precompiler, as it seems a lot of people just want to make a 1:1 binding of their classes, and do not care about having control over what's declared. I think we'll soon work on writing one.

[madmarx]

The good thing about CAMP is that the minimum required to make it work is standard C++ code, but nothing prevents you from using third-party tools on top of it like a precompiler, to automate the declaration step.

Yes completely.

I'd be very insterested to hear about your experience with boost.mirror, and the one you wrote

My experience : I needed only the attributes of the classes to be reflected in the projects I used them (no functions/constructors).

boost.mirror : mirror does 'too perfect reflection' IMO. I mean, it's useful if you want to know for each class, its namespace (which might be a good thing if you are into grouping things for a GUI designing system..), and too much informations : there are more lines to write if you want something reflected.
On the other hand, the completely external system is interesting, but its more a curiosity for me.

my system : the first I did was like camp, but with less features : only reflected attributes. It was design to allow fake classes, but I never used this functionnality in the end. The internals were quite like CAMP (from what I have seen of it, which is only a little part). It was template based : there was a class that represent a class, one that represent objects, few functions to complete (eg : get the name of the class as string, get the attributes informations), then you got one main class to register all the classes and their parents in the main.
It worked well, until I had to produce several classes in my projects, with tons of attributes (11 engins!! mocap, graphic, physic...), and made the classes able to talk to each other over the network.
In the first time, I used doxygen (with automatic test/fail compilation) to produce the code, this was unfortunately(!) working so I stuck with a it some times.

I was not happy with all the 'registering system', separates classes and overall performances (creation/destruction of class representing elements etc...). I decided to do my code much more high level and pure C++ (1 declaration only). I did it with macros and that was pretty cool. You can get a glimpse of it here :http://www.ogre3d.org/forums/viewtopic. ... 75#p377757.

Later I decided that it was not easy to maintain, and not has simple to use as I wanted.
But it was definitely more powerful than the first thing, because I could even add many aspects to a class in one word (networkable, serializable, guiable...). I rolled in 2 days a parser with spirit (boost spirit) for a language of my own. That language is used only in the .h, and is closed to java/c++ things. Then generates only .h. Its extremely cool, because very readable, simple to use, and I can add my own caracateristics to attributes, functions and classes very easily. I want to propose something equivalent in my so3dtools project (but before that I have to finish the wiki and a few demos).

Could it be you are the main creator of the camp library?

[betajaen]

I've seriously started to think about Serialisation in NxOgre, after Detritus, Serialisation will be the big feature.

It won't just be saving and loading to a file, but saving partially or whole scenes to others and even sent in updates across networks.

Some parts I've started a little early. For property/descriptor classes, I decided to go an alternative route than CAMP or what the others are doing here, and use the documentation to generate the source code for me. Using Ruby, it generates all the necessary variable, documentation, "save to x", validation functions for me from the class documentation header. It doesn't just create a new file each time, it inserts the code correctly into the source code. I don't have to repeat myself when writing, there is no binding code. I just write in the comment what I want, hit compile and the Ruby script fills in the rest of the class for me.

For example:

Code: Select all

/*! class. BoxDescription
    desc.
         Description to describe a Box shape.
    properties.
      Vec3 mSize -- Size of the Box default: mSize.set(1,1,1)
    validations.
       mSize cannot have negative or zero values -- mSize.isNegative() || mSize.isZero()
    namespace. NxOgre
    from. ShapeDescription
*/
class NxOgrePublicClass BoxDescription : public ShapeDescription
{
 ...
};

It's human readable and computer readable. You can see the results of it here: .h and .cpp.

Although it does go a long way in not repeating yourself like with binding code does, it doesn't solve every problem I have to face. But it helps.

[Laurent]

Yes I'm the main developer of the CAMP project, so thank you for sharing your experiences, this is very interesting stuff to read for me

[madmarx]

@laurent
A little OT, but let me thank you for your 2005 article on developpez "a 3d engine part 1: tools".
I request all my students to read it !

@beta
Very good. The final idea is quite close to my current solution (even if I don't mix 2 languages).

[xadhoom]

laurent,

I tried to register to the camp forum but never received a confirmation mail. I even tried to send myself the password after that. The forum software told me that it sent it to me but I haven´t got an E-Mail. I checked my spam folder.

Can you confirm that the notification system works in general the last few days?

xad

[Laurent]

Yes I think it works, other users have registered successfully recently. I'll test it again, just to make sure.

Anyway, you're properly registered and you should be able to login. Is that ok?

[xadhoom]

Laurent,

Yes, I´m able to login. Thank you.

xad

[Laurent]

I've created a new account on the forum, and I received the confirmation e-mail a few seconds later. I have no idea what could be wrong with you

[Laurent]

An XML module for CAMP is now available:
http://dev.tegesoft.com/projects/camp/wiki/Camp_xml

Don't hesitate to try it and give us your feedback

[xadhoom]

Laurent,

Very useful support! Does this feature allow plugging a custom serialiser?

On the wiki page you are asking for an interest in additional xml librarys. E.g. we prefer RapidXML for these kind of work because its tiny and fast and matured enough that Boost::PropertyTree uses it internally.

xad

[Laurent]

Very useful support! Does this feature allow plugging a custom serialiser?

Yes indeed. If you look at the camp-xml header that implements support for a particular library, you'll see that it simply contains a Proxy class that maps a few XML calls to the library API. To support a new library, just copy and paste the header, and modify the implementation of the proxy functions.

Adding a new library is really fast, if you want I can have a look at the RapidXML library and write its camp-xml proxy

[Laurent]

I've added the RapidXml proxy to camp-xml.

RapidXml is pretty good, it took me 15 min to learn it and write this module

[xadhoom]

[ppClarity]

LGPL 3. Ouch.

Any possibility of relicensing under MIT or BSD?

[Laurent]

Any possibility of relicensing under MIT or BSD?

No. What problem is there with LGPL? It doesn't prevent you from using it for closed-source applications.

[jacmoe]

LGPL 3. Ouch.

Any possibility of relicensing under MIT or BSD?

There wasn't a problem with Ogre being LGPL when it was.

[ppClarity]

There wasn't a problem with Ogre being LGPL when it was.

We've been around this block a few times.

I had thought Ogre used v2.0 which would have been just fine, but it used 2.1 which was murky enough that it would have required a consultation with a lawyer. Ogre also had a commercial license. I'd wager that the commercial license would cost me as much as the consultation. Guess who I'd rather give money to?

I live in the US and I am subject to US laws and regulations. While I think software patents are complete idiocy I still need to deal with the consequences if I run afoul of them.

Under GPL 3, if a person conveys a work under the GPL, all recipients of such work are extended a license to use any patented work necessary to exercise the recipient's rights under the GPL. In essence, GPL 3 carries with it an explicit patent grant, meaning that any contribution of software grants downstream users a license to use any patents applicable to that contributed software.

Full article: http://localtechwire.com/business/local ... y/3439737/

In essence I'd need to either have a redistributable license for all patents affecting any V3 code or I'd have to indemnify anybody that code is distributed to. The former is impossible, the latter would just be suicide. LGPL Version 3 is a complete non-starter.

Any possibility of relicensing under MIT or BSD?

No.

Fair enough, I wish you well.

[jacmoe]

Good luck living in the US, then.

There's a little 'L' in front of that GPL, if you missed it.

IMO, that's a very kosher license for an open source Library.
Although I'd personally would have liked a more permissive license myself, but we're not in a position to choose what license CAMP is released under.

But, if you're addressing the *version* of the license, you probably have a good point.
AFAIK, version 2 is "better" than version 3 for most things.
At least that's what I've gathered from various discussions around the 'net about whether or not people are upgrading from version 2 to 3. Many are not.

But I'd really like this topic to be about CAMP, not license anality.

[jacmoe]

I noticed that camp-xml was not there when I git'ted the source.
But then I realised that it was in the 0-7 branch, so don't forget to switch branch when checking it out.
Just a FYI.

[volca]

I like this - it could be a nice base for object-database-like storage system as well - hmm