Re: [boost] If boost::fusion is the hammer, then what's the nail?

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-12-14 18:04:30

Steven Watanabe wrote:
> AMDG
> 
> Weapon Liu wrote:
>> I think this is the right place to ask this question.
>> As cool as boost::fusion is, there's still one question that bothers me, 
>> that is, if boost::fusion is the hammer, then what's the nail?
>>
>> I sure know that it's generic( more so than boost::tuple) and it's 
>> complete( with a bundle of algorithms and cool utilities), and it seems 
>> that it "solves" some problem quite well( when I read the documents).
>>
>> However, I found it bothering that the documents didn't even mention one 
>> real-world application( boost libs aside).
>>
>> Based on my experience, the most frequent scenarios where 
>> boost::tuple/fusion is useful are those where one needs a 
>> generated-on-the-fly struct for holding return values bundle, or where 
>> one needs to return multiple values transparently( well, nearly so), 
>> just like those lua does.
>>
>> Other than that, I can't really imagine a scenario where this kinda 
>> stuff kicks butts. The biggest disadvantage of boost::fusion, I think, 
>> is that the size of it is known and fixed at compile time, which renders 
>> it not so qualified as a truly heterogeneous container.
>>
>> And by the bye, that it can be used to build a handy pseudo-struct  that 
>> enables full introspection really is a good and fancy feature. However, 
>> there's something fundamentally irremediable of it, that is, it can't be 
>> used to build a full-fledged class( rather than a POD-struct), which, I 
>> think, will too reduce its usefulness w.r.t. this kinda situations.
>>
>> I personally very like this fancy facility, and that's why I present 
>> these mumbles here to annoy you guys( if so, my apologies go here:-))
>> Any comments?
>>
>>   
> 
> I needed basically the functionality of fusion::map to implement a table 
> of function
> pointers.  I can't use fusion for this though because I rely on POD 
> initialization.

In cases like that, you can write your own "fusion-savy" container.
Case in point: proto trees in xpressive. Then, you can take advantage
of fusion interoperability, its algorithms, etc.

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