Re: [boost] [review] Boost.Fusion

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-15 23:21:13

João Abecasis wrote:
> Joel de Guzman wrote:
>> João Abecasis wrote:
>>> On the directory structure used for the headers, I like the modular 
>>> approach but sometimes get the feeling that it's too fragmented. Having 
>>> more top-level reflections of individual components would ease my 
>>> concerns. Another aspect is that this structure diverges from what is 
>>> used in MPL. Given the parallel between the two libraries I think an 
>>> effort should be made to keep the structure similar. In fact, this is 
>>> also part of the user interface. Still, in the end, I recognize that 
>>> they're two independent libraries and must each follow its path.
>> Understood. I'll give this a lot of thinking. At the very least,
>> we'll surely have a flat set of headers that forward to the
>> main headers. Where to place them is a matter to deliberate on.
>> Maybe <boost/fusion/hdr/xxx.hpp> ? or simply <boost/fusion/xxx.hpp>
>> and push the main tree downwards in another directory, say, "main"?
> 
> Why do you need to have them in separate directories? Are there 
> conflicting/overlaping headers when you mix the approaches (or are you 
> just trying to keep everything nice and tidy ;-) ) ?

Haha! Right. I think I am somewhat autistic in that regard--
I like them all lined up and structured perfectly. I like the
thought that someone out there will really read and try to
understand the code. For me, structure is part of the poetry ;)

>>> Fusion is coded with the expectation that the library code will be 
>>> optimized into very tight code, which seems to be a reasonable 
>>> assumption with (any?) modern compilers.
>> I hope g++ will catch up! See Dan's post regarding some Fusion
>> speed tests. g++ produces the fattest and slowest code :(
>> I wish I was using incorrect flags or I haven't found the
>> best compiler switches to use for g++.
> 
> It will catch up :-) On a side note, it seems the tests were run with 
> gcc 3.4. IIRC, gcc 4 and beyond introduced a couple of interesting 
> optimizations so I wonder how far do those go towards narrowing the gap.

I would love to see better numbers for g++.

>> MS VC8.0 produces the tightest and fastest code, so far.
>> (No, I'm not a fan of MS. Those are just the facts.)
> 
> Of course ;-) I like facts! From my limited experience, I've also seen 
> MSVC produce the tightest code.
> 
> Perhaps there should be a way to extract some benchmarks (e.g., code 
> size, performance) from the Boost regression tests, or separate 
> benchmark-tests for the different compilers could be integrated into the 
> system. This could be interesting and useful information for library 
> developers.

Definitely!

>>>> - What is your evaluation of the potential usefulness of the library?
>>> I believe Fusion has great potential as a library building block but 
>>> also as a more application-oriented library. On the library building 
>>> block side, I believe it has the potential to become a fundamental/core 
>>> piece of Boost. For application developers, Fusion takes tuples to a new 
>>> level, allowing one to make the most of information that is available at 
>>> compile-time.
> 
> I wanted to make an additional suggestion that might make Fusion's 
> usefulness more visible, but it slipped my mind at the last minute. 
> While I'm not that familiar with Boost.Serialization it seems to be a 
> fairly popular library with developers of varying technical level.
> 
> My suggestion is that Fusion Sequences be made serializable, using 
> Boost.Serialization. This would go in a separate header (e.g., in 
> fusion/sequence/io/serialization.hpp) and have the requirement that 
> serialization be implemented for individual element types. If possible, 
> the serialization would be generic, i.e., tied to the type sequence and 
> not to the particular Fusion Sequence.
> 
> With serialization in place, Fusion sequences could be used to manage a 
> class's data and its serialization or they could be used as a proxy 
> during serialization:
> 
>      archive & tie(a, b, c);
> 
> Hmm... I see that the Quick Start mentions serialization as an example. 
> Is there a reason for not offering the interface to Boost.Serialization 
> in the library?

Why not! That would be a good direction. Are you volunteering?
Ahem ahem... duck... duck!!! :-)

I also thought about an easy way to make an arbitrary struct a valid
fusion associative sequence (perhaps through macros). I can't start
to imagine what that would bring. Fusionized in-memory relational
database support perhaps?

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net