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