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