Thread: CAMP - new open-source reflection library for C++

Hi

I'd like to introduce a new (and very exciting) library to the C++ community: 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, ...

Another example is boost.python; in fact CAMP is highly inspired from this library (and luabind, which is also inspired from boost.python). So you can declare your classes, functions, properties, enums, etc. in a way very similar to these two libraries, except that the resulting meta-information is available directly as building blocks for something else, you're not limited to using it for the X scripting language.

We recently published a brand new website for the community, with a forum, a wiki, a bug tracker, a file repository, etc. :
CAMP Developer Zone

Don't hesitate to give your feedback, or ask questions if some parts of CAMP are not clear to you

O_o

That's some nice spam.

*shrug*

At least it is open source...

Soma

Sorry if it looks like spam.

I read the forum rules before posting, and there's nothing against posting to talk about an open-source project that may be interesting for the C++ community. And I think it really is interesting. I'm really looking for relevant feedback from experienced C++ developers, I'm not just throwing a link there and never coming back. So please let's start discussing about what you think of this library

Of course if I'm really breaking one of the the forum rules, just delete this topic and sorry for the inconvenience.

I see. But the "Projects and Job Recruitment" looks empty, it's like nobody ever goes there (368 topics vs 42,000 for the C++ forum).

Anyway, I let the moderators do their job.

If not they are probably disinterested in such things anyway.

If by that you mean there is no need for reflection in C++ then, yes, I would agree.

This project was not written by a passionate C++ developer who wanted to write useless templated code, it's written by an industrial company with specific needs.

This could be said of much of the worst code in history.

I wouldn't say that it is useless.

You shouldn't bill your library as providing reflection. From what I can tell from the documentation, it is a long way from such a goal.

That said, a generalized API for binding C++ constructs to and from "dumb strings" isn't useless. I just don't think the protocol you've designed is useful or practical. Of course, the documentation is severely lacking; maybe you should come back when it is better.

Soma

This could be said of much of the worst code in history.

Of course. But that doesn't mean that my code is bad. This doesn't mean anything in fact, except that the library is not useless.

You shouldn't bill your library as providing reflection. From what I can tell from the documentation, it is a long way from such a goal.

I know, that's why most people are confused about CAMP when they first read about it.
But it truly is reflection: you can ask to the system which classes exist, what there name is, what properties they declare, you can manipulate them by their name, get/set them with abstract values, etc. What is it if not reflection?

That said, a generalized API for binding C++ constructs to and from "dumb strings" isn't useless. I just don't think the protocol you've designed is useful or practical.

Can you explain your point of view? Why isn't it practical, and what, in your opinion, would be more useful?

Of course, the documentation is severely lacking; maybe you should come back when it is better.

Can you tell me what's missing - except more examples/explanations for people who don't understand CAMP, and that we'll soon add?

I've given examples, comparisons with existing frameworks, technical and design details, etc. but it's hard to explain clearly because it's an API which is designed to abstract things.

o_O

Then you need to tell people that it is a library designed to simplify and improve the adaptation and binding of C++ constructs for "third-party" API consumption originally targeted at those dealing with embedded language interpreters.

Macros would add even more verbosity because the lack of templates and overloading.

O_o

You should look over my post again... carefully. I never said to drop templates or overloading. You are obviously using both to "guess" the return type and parameters. Dropping either would be foolish. I suggested a layer that would add to the existing API.

CAMP now needs to be enriched with common modules (see below).

Until you have some modules, I suggest you stop using the examples you have used. You come off as claiming features it does not possess.

I also suggest you start with XML.

The philosophy of CAMP could be "bind once, use everywhere".

That's a fine goal, but you first need the one automatic binding.

Soma

Then you need to tell people that it is a library designed to simplify and improve the adaptation and binding of C++ constructs for "third-party" API consumption originally targeted at those dealing with embedded language interpreters.

Thanks for the definition. We're not native english, and finding the right words is sometimes difficult.

You should look over my post again... carefully. I never said to drop templates or overloading. You are obviously using both to "guess" the return type and parameters. Dropping either would be foolish. I suggested a layer that would add to the existing API.

Sorry for misunderstanding.
But how would they make the current API simpler? Please give examples of what you have in mind.

Until you have some modules, I suggest you stop using the examples you have used. You come off as claiming features it does not possess.

But people need these examples to understand what they'll be able to do with CAMP. I'm not claiming that these features are implemented and available, just telling people that they are typical examples of things that can use CAMP.

I also suggest you start with XML.

Seems to be simpler than writing a script module, so it might be the first one, yes.

That's a fine goal, but you first need the one automatic binding.

Definitely.