Re: [boost] Checking interest: reflectable types

Subject: Re: [boost] Checking interest: reflectable types
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-05-02 15:06:58

On 02/05/11 19:04, Noah Roberts wrote:
> On 4/29/2011 11:18 AM, John Bytheway wrote:
<snip>
>> However, my conclusion was that the system was ultimately impractical on
>> the scale I was using it for a few reasons:
>>
>> - Compile times were absolutely horrific; though these could no doubt be
>> improved with attention.
> 
> Yeah, any time you reflect an object you get a compile-time hit.  Just
> using the objects isn't so bad.  So far it's been OK.

Actually, thin king back, it wasn't just compile times but also memory
usage.  You need about 2GB of RAM to compile the program I wrote.  My
netbook didn't have that at the time.

> Another problem I've run into is that the compiler I'm using (VS2010)
> crashes if a boost::signals2::signal is the member of anything that is
> also included with a reflected object, if that signal's containing
> object is included first.  We're probably going to work around this by
> never exposing signals2::signals through public interfaces, using the
> pimpl idiom to hide them.  The connection seems to be OK so far.
> 
> My guess is that this has more to do with the signals2 library than with
> mine.  The compiler crashed in the same areas in earlier versions of the
> compiler but is now labeled as passing.  It could be that it only passes
> if you're not also doing a bunch of other template stuff within the same
> translation unit.
> 
>> - I couldn't see an easy way to get a public/private distinction on
>> fields.
> 
> This could be done with private inheritance probably.

It's going to be tricky.  SFINAE doesn't play nicely with private
members, so I don't see how to do it.

> Also not sure it
> would be completely useful though since you can just make extra variable
> that aren't part of the reflected interface.

That wouldn't be good for my use case because e.g. that extra variable
would then not be serialized.

>> - Understanding how it interacted with inheritance got rather
>> mind-bending.
>> - The syntax to access fields was just a little bit too tiresome.
> 
> It took some work but to access fields in mine it's: get<outer,
> inner,inner,inner>(object)

Hmm.. Yes, that makes sense.

> There's also a build_accessor that constructs a typedef out of an object
> type and a sequence of fields (in an mpl::vector for example).
> 
>>
>> It could be interesting for use on a small scale, and it would be nice
>> if there were an implementation out there which had done the relevant
>> compile-time optimization and ironed out the wrinkles.  However, I would
>> present it as a "Fusion map with extra bells and whistles" rather than a
>> reflection library.
> 
> Yeah, that's probably a more accurate description.  Might be possible to
> merge into fusion somehow actually.
> 
> And yes, would be interesting to see what someone who really knows their
> stuff can do about compilation times...if anything.

Have you found the template profiler?

John Bytheway