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

This is a discussion on CAMP - new open-source reflection library for C++ within the Projects and Job Recruitment forums, part of the Community Boards category; Again. If you know this, why not be clear about what your work is and is not capable of? I ...

  1. #16
    Registered User
    Join Date
    Jun 2010
    Posts
    10
    Again. If you know this, why not be clear about what your work is and is not capable of?
    I try to. 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. And the abstraction itself is meaningless without modules, and there is no module right now (I'll talk more about this below). So you have to use your imagination, or simply give your opinion about the examples that I've already given, which are clear enough I think.

    The protocol you've developed is not practical because the additional burden on the developer. You need to alleviate this burden if you want this to be widely acknowledged. As much as I hate implementation macros, I feel this protocol could be improved with additional macro facilities to reduce repetition and the initial burden.
    Macros would add even more verbosity because the lack of templates and overloading. If you look at boost.mirror, which is entirely based on macros, it's kind of ugly actually.
    The only thing that would ease the work of the developer is a precompiler, which is not incompatible with CAMP like I said before.

    I'm not even sure how this library alleviates the issue. As far as I can tell, it only supports a few trivial primitives ("dumb string"). You'd still need to code the necessary compatibility layer the API for the embedded language interpreter expects. I suppose, in the fullness of time, new primitives for popular projects may be available.
    Indeed. CAMP now needs to be enriched with common modules (see below).

    I imagine that also applies to other facilities that "vanish" like operators, function overloads, and variable argument functions?
    It depends. It's currently not supported but it could be. It would be limited to script languages, but it could be useful.

    About the modules

    This is the main problem in my opinion. Right now we only provide the core API so that developers can declare metadata, but there's nothing that you can do with it without some extra work.
    But now that the core library is stable enough, and that the website and the forum are ready, we'll focus on writing such modules:
    - a CAMP-specific precompiler
    - a GUI object editor
    - a Python module
    - a Lua module
    - a XML module
    - anything that people might find useful
    - ... plus all other modules written and shared by the community
    The philosophy of CAMP could be "bind once, use everywhere".

    So you'll soon be able to get all these features for free if you use CAMP. And with the precompiler it is even more free.

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,409
    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

  3. #18
    Registered User
    Join Date
    Jun 2010
    Posts
    10
    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.

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,579
    Quote Originally Posted by Laurent Gomila View Post
    I noticed that you didn't answer to my previous post, where I talk about all the Qt modules that are based on their meta-object system. Would you say that those modules implement "obscure, rarely seen" features?
    I would say those modules implement features that can be dealt with without reflection.

    Quote Originally Posted by phantomotap View Post
    *shrug*

    I'm not even sure how this library alleviates the issue.
    It doesn't and that's my point. It complicates matters to its user as we both agree. I'd prefer to write two or more script language bindings, than to use this. The work load must be on the library writer. Not on the user of the library. Why would I want to use a library that puts all the work on me? Or, to put it in another way, why should I write a library that puts all the work on the my users?

    Besides with C++ the tendency is exactly to write multiple bindings. It's not that we see reflection all around the place. Library/framework writers prefer to write one or more bindings for inter-language dependency. And not apply reflection.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #20
    Registered User
    Join Date
    Jun 2010
    Posts
    10
    I would say those modules implement features that can be dealt with without reflection.
    How could they? They are not supposed to know what user classes and properties will have to be available.
    You must admit that those Qt modules are rather powerful, and they are because they use the Qt meta-object system. If not, please explain your point of view more in depth.

    It complicates matters to its user as we both agree. I'd prefer to write two or more script language bindings, than to use this. The work load must be on the library writer. Not on the user of the library. Why would I want to use a library that puts all the work on me? Or, to put it in another way, why should I write a library that puts all the work on the my users?
    I don't understand why you think that writing multiple bindings is less work for the user than writing a single one.
    Let's say that you want to support both Lua and Python in your application. Using boost.python and luabind, you're going to write twice the binding of each class, and they will nearly be identical (because luabind is inspired from boost.python).
    How is that simpler than writing a single CAMP binding (which will also be identical because CAMP is inspired from luabind)?
    Please explain what you mean, don't just say "it is simpler ... it is more work ...". Tell me what would be simpler and less work.

  6. #21
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Binding to Lua is not really a benefit here since there are several libraries available that do this in a much better fashion. Also the more you bind your code to Lua the more your code depends on Lua and vice versa. You should design Lua script so that it has dependencies on the engine but the engine does not depend on the Lua script. When you bind like this you might as well use hard-coded C++ b/c all you have done is move the C++ to C++ dependency into a C++ to Lua dependency. The whole point of Lua is so that you could theoretically change the Lua script, not alter the engine code, and obtain different behavior without recompiling or rebuilding anything.

    It is my opinion that if Lua has intimate knowledge of a C++ class (breaks OOP) then something is wrong. It is also my opinion that if C++ has intimate knowledge of the Lua script then something is wrong b/c now you force a dependency of the C++ on the Lua. The best approach, in my opinion, is through the use of interfaces. If the C++ only sees the Lua through an interface and the Lua simply implements said interface then the impl can change all day long and the interface doesn't which means you do not have to rebuild and you can swap new scripts in and out almost at run-time. I've seen a lot of Lua examples where the C++ is so closely bound to the Lua that the class will not work without some type of Lua binding. I think there is a much better way and have implemented this in my own projects and it works just fine. Both Lua and C++ objects should see each other as other C++ objects see other C++ objects: through interfaces.
    Last edited by VirtualAce; 06-17-2010 at 06:26 PM.

  7. #22
    Registered User
    Join Date
    Jun 2010
    Posts
    10
    This is an interesting point of view, to which I agree, but how is that related to CAMP? We're not talking about what to bind, but how to bind it, whether it is interfaces or concrete classes.

    Basically, what I'm interested in is to know if you consider the well known boost.python and luabind as useless as CAMP.

  8. #23
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I'm illustrating that binding to Lua is not a benefit of your system. Many other APIs allow this. The fact that yours can bind to internal data in Lua is of no benefit to me since I don't do that anyways b/c I feel it is a bad design. Therefore.....your CAMP offers nothing for me.

  9. #24
    Registered User
    Join Date
    Nov 2010
    Posts
    1
    I've been working on a project where I've developed a C++ plugin api for adding user interface components and so on to an interface builder application. I think this project could be very useful for me... I already have a mechanism for exposing variables and attaching actions to components, but one piece that I've been missing has been a way for plugin components to expose signals and/or slots and to let users make connections at run-time. Since this has to be done at runtime, a template based approach to signals/slots won't work. I like what the creators of Qt have done, but I don't think it would be easy to rip out their moc preprocessor and to retool it for my own purposes... So, I'm going to take a look at what you've done and try to get my head around it...

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Why Open Source?
    By sarah22 in forum General Discussions
    Replies: 17
    Last Post: 03-22-2010, 04:48 PM
  2. Joining an open source project
    By Poincare in forum C Programming
    Replies: 5
    Last Post: 11-27-2009, 03:44 PM
  3. iterate through types in a library (reflection)
    By bling in forum C++ Programming
    Replies: 1
    Last Post: 10-29-2008, 06:15 PM
  4. Source code of the standard library functions...
    By Nutshell in forum C Programming
    Replies: 2
    Last Post: 01-21-2002, 12:35 PM
  5. OpenGL Open Source
    By gnu-ehacks in forum Game Programming
    Replies: 2
    Last Post: 11-29-2001, 12:50 AM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21