Re: [boost] [review] Boost.Fusion

From: João Abecasis (jpabecasis_at_[hidden])
Date: 2006-05-15 23:03:04

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 ;-) ) ?

>> 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.

> 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.

>>> - 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?

Best regards,

João