Re: [boost] If boost::fusion is the hammer, then what's the nail?
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 Christ, Steven Watanabe
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
participants (2)
-
Joel de Guzman -
Steven Watanabe