text: Subject: Re: [boost] Is there any interest in a library which solves C++ class reflection feature just like Java does?
  From: jinhua luo (ljh.home.king_at_[hidden])
  Date: 2011-12-05 23:46:09
  Hi,
  I just have a quick look at the boost::fusion. The declaration syntax is a
  bit similar, but they are completely different things, I think. And the my
  library do not use boost::fusion.
  Also have a quick look at the boost::reflect, and I found it's a different
  style to fulfill the reflection:
  a) my way is non-intrusive, which means it makes no assumption about your
  class, e.g. inheritance, or implements any interfaces. Any public class
  members (member functions) of any type (even the C++ reference) can be
  reflected. But the boost::reflect seems to be focus on the
  interface-oriented reflection.
  b) in my way, you just need to declare your class via dedicated macros, and
  do nothing else, then you can use Java-like reflection API to reflect and
  use your classes at run time. And the API do not need any initialization
  before you begin to use. All the declared classes will be registered
  automatically.
  c) The declaration and reflection is separated. In my example, you can see
  that the declaration resides in the standalone shared library, while the
  reflection API usage resides in any other program, in which program you do
  not need to include any concrete class header file, because that's where
  the reflection magic happens. But the boost::reflect needs to know about
  the interface definition obviously.
  d) when the compiler compiles the declaration, it will raises errors if the
  declaration is invalid, e.g. the prototype doesn't match the class
  definition. So it's type-safe. Moreover, the reflection API will raise
  exceptions if you try to launch some invalid reflection, e.g. non-exist
  method, wrong method prototype.
  e) the declaration is flexible enough. you can place the declaration
  anywhere (and within any namespace), which means you don't have to place it
  into one single source file. in fact, you don't need to care about the ODR
  (One-Definition-Rule) violation, and it will eliminate the duplicated class
  registration, and that's why I said you can place the declaration within
  the header file, which may be included within any compile unit. You can
  even place the same declaration both in the shared library and the
  executable.
  Regards,
  JinHua
  2011/12/6 Julien Nitard <julien.nitard_at_[hidden]>
  > Hi,
  >
  > >In brief, I'd designed and implemented somehow C++ class reflection based
  > on boost libraries.
  >
  > I am interested. Could you detail how it differs from
  > BOOST_*FUSION*_ADAPT_*
  > STRUCT* in boost::fusion ? It seems very similar to me.
  >
  >
  > >It has some unique advantages:
  > >a) it doesn't require code generator
  >
  > Well ... I'd prefer that a code generater be provided: Your syntax is not
  > that lightweight, you can compare with boost::reflect that is a non
  > proposed library (link).
  > If you want to reflect a large number of classes, then your solution is not
  > very maintenable (as all solutions without a code generator).
  >
  > One more thing: your solution is "runtime" reflection, I think in C++ a
  > compile time API would make more sense, though, I must say there are
  > advantages for both.
  >
  > Regards,
  >
  > Julien
  >
  > _______________________________________________
  > Unsubscribe & other changes:
  >
  >
  Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk