Boost logo

Boost :

Subject: Re: [boost] [reflect] Introducing Boost.Reflect
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-07-31 04:11:34

Hi Daniel,

On Sat, Jul 30, 2011 at 11:05 PM, Daniel Larimer <dlarimer_at_[hidden]> wrote:
> On Jul 30, 2011, at 4:40 AM, Jose wrote:
>> I hope you propose boost::reflect for review soon and then mature all
>> the other bits in a library that enables other concurrency models and
>> is a good brother for asio.
> I take it as a high complement that you consider boost::reflect worthy to be considered for review soon.  I am willing to submit it if I can can get enough feedback on it.

Your RPC library certainly looks interesting,
but I've a few questions/comments
on the reflection part.

> 1) Does the name describe what it does?

Basically yes, but from a quick glance at the docs
I'm missing a few things (see below).
Generally from my own experience I can say
that a reflection library should not start as
the support tool for a particular task (RPC,
serialization in this case). It should aim to be
as general as possible, as there are other situations
where reflection can be useful.

Mirror (the C++03 and C++11 version)
are the third and fourth reflection
libraries I've written from scratch ;)
The first was begun actually the same way
as Boost.Reflect as a support for RPC and
it worked well for this task but it had two
main problems it was too polymorphic (= too slow)
and too specific (= not usable for other things)

> 2) Does the library fully address the problem within the scope of practicality?

If its goal is only to be the support for RPC then yes.
Have you considered using another more general
reflection library (shameless plug) like Mirror ? :)

In the past I preferred to work on it alone since I had
my ideas about how to do certain things. But now it is
in a state where a second (and preferably third, fourth, ...)
opinion would be very helpful. If your are missing
something in Mirror I'm sure we could get it done.

> 3) Other reflection attempts have not been accepted for one reason or another.
>        - Boost.Reflect vs Boost.Mirror

Here should be probably said that Mirror (and AFAIK)
Boost.Reflection were not submitted for review (yet)
and this is the only reason for them not being accepted.
I don't know about Jeremy but I'm planning to do that
once it is ready.

The compile-time reflection is basically finished (with
a few things that need polishing and a few features
that can be added later).

The two biggest problems I see are that it heavily
depends on C++11 and some quick start guide and
step-by-step tutorials are missing from the docs.

> 4) Would a different name better 'reflect' what the library does?
> 5) Are there any features missing?

I couldn't find things like namespace member traversals,
support for compile-time metaprogramming, reflection
of specifiers (access type, linkage/storage class, etc.)
examining/setting members with getter/setter functions
(with side effects), just to name some, but maybe I just
missed them in the docs.

> 6) What must be done before it can be submitted?
>        - license info, unit tests, etc?
> Would it be more aptly named for its type-erasure, vtable, any_ptr<>, interface than its simple visitor-based reflection?
> The library is ready for informal review now and my goal is to morph it into something that is ready for full review (as quickly as possible),
> so any feedback / direction would be very helpful.



author of the Mirror reflection utilities

Boost list run by bdawes at, gregod at, cpdaniel at, john at