Re: [fusion] Proposal for deprecating fusion.tuple.

Lee,
>>> For C++11 `fusion::tuple` I noticed that if the assignment from
>>> fusion sequences was removed (its constructor currently does not
>>> allow conversion from sequences and `std::tuple` has no such
>>> requirement), then the headers automatically included could be
>>> reduced. So `fusion::tuple` _could_ be a faster compiling sequence
>>> for when the conversion properties of `fusion::vector` was not
>>> needed.  
>> Good point. Implicit conversion is one of cause why I proposed.  Since
>> `fusion::tuple` uses `fusion::vector`, if this goes on, it can't be
>> faster than `fusion::vector`. OK, re-implement `fusion::tuple` without
>> any other sequence? Perhaps it has no (or few) difference between
>> `fusion::vector` about performance.
>>
>> However, no conversion performing guarantee is safer and meaningful
>> option for some user.
> C++11 `fusion::tuple` inherits from `fusion::vector`. This complicates
> the `fusion::vector` implementation because its interface must be
> "compatible" with whatever `fusion::tuple` is doing. So if the problem
> is the C++11 `fusion::tuple`, I think the short-term solution is to
> change its base class to `detail::vector_data`. What happens to
> `fusion::tuple` after that is another discussion.
>
> I "injected" the discussion of performance because during my last
> patch to fix some bugs posted to the ML, I intentionally re-worked
> `vector_data` to be a bit faster and hopefully allow for
> `fusion::tuple` to inherit from it directly. I did this because I
> noticed if `fusion::tuple` were then made _more_ standard conforming
> (by potentially breaking some existing code), headers for interacting
> with sequences and `at_c` (via `boost::fusion::get`) could be removed
> which should cut down on compile time for people only needing basic
> operations. Otherwise (as you noticed), its not exactly clear
> when I would use `fusion::tuple` over `fusion::vector` except for
> undocumented differences on constructor behavior (assignment is
> identical currently!).
Fair enough. Changing base to `detail::vector_data` is good solution at
this time.
Fortunately, no official document describes `fusion::tuple`
convertibility to `fusion::vector`, so we can make a change in next
release, doesn't it?

Kohei

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJZ0OViAAoJEGGyPxPRp/zo9lYP/jez8Fq71bZ4yHxbuW7DnLXc
+P+VjPrR172w6ZBv5uBTlqURWBCqzfe2EpZ0fBGl/Q6BS3vRgrAZqNJhBzX9yzsj
HFGwiGOzDTddFmOuVDMTtCSddSD5Tk87HauikSosnmUiBCg0IdhRC2bRgABxOhwX
ez6CboKFDX8AAksPeJFx1DGUYQENoGgXmWkhRh6jtNgQ9WKUPvupYRBku/Xik0Fx
33z7Z32Ru0cCjc8FzbeigIVi5NbzPURmIIJEhZ//c0QnRSMI2GbwkAu17HS/I6Zv
V0bjbynjXgDGRlCYvpW7XUfuzwO8NWoSpGMUNlHPavFfQrWxTGuguzoAaWf0LPEO
3DobIJIpeDB4YxuhRjkhw/oRE2eqkR9XmDBGhARSngjLxw93P1sGza0XOsvhUkr9
+5L1/ryLnYoxpLFOUIzKKSky+dH6qlZPYZGPXUa2n5onTyFvsiK+ofMUanfhe8hV
Bj7ce3Slsp90Wuhb/sBOsKJ88C1+hmHZWhuL/kzq54iWYEJDtO/OJn2L8D5IeZFg
yLXvTxeGTUCI2RYPEX4L7SnvgyNjWjpavieutWUpaSQ1dzRTgF0sYZgfuz8451uH
zAiB0A1pjiOu1cgqd+YwhXbKGU43G3b0LC30P0OX8Cnzms3zYfTq2VH6FT6wEbex
IHJATCYNlSMt9q9TLeWt
=eX7J
-----END PGP SIGNATURE-----