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

Larry Evans <[email protected]>
Newsgroups gmane.comp.parsers.spirit.general
Message-ID <[email protected]>
On 09/29/2017 08:23 PM, Kohei Takahashi wrote:
> Hi Lee,
> 
>> How does `fusion::tuple` make `fusion::vector` implementation more
>> complex? Are you referring to the C++03 or C++11 version?
> C++11 is.
[snip]
>> I would like to point out that recent tweaks to
>> `fusion::vector` have [improved performance over libstdc++ `std::tuple`
>> in construction][0][1].
> Interesting. I'll try to benchmark simpler impl.
Kohei, the benchmark [0] mentioned by Lee for fusion::vector is here:

https://github.com/ldionne/metabench/blob/master/benchmark/hetero/make/fusion.vector.cpp.erb

AFAICT, it only makes the vector, it doesn't access any elements.
I would think having to access the elements would affect the
compile time since that would require instantiating member functions
and I'd assume that would take some more compile time.  Is that
assumption wrong?  If not, then maybe a better benchmark would
exercise some of the more important member functions.

> 
>> Anyway, the bigger issue with deprecation will be on users of Boost.
>> Hopefully the fix would be easy - just change to another sequence type.
>> I'm not aware of an situations where this is _not true_ (i.e. where
>> deprecation would cause major code re-write for Boost users).
> Yes, I think so too. I'll post this proposal to devel/users ML and ask
> who uses `fusion::tuple` in production code.
If by devel ML you mean:

   [email protected]

then be prepared to wait for a reply.  The last post I made to that ML
was sent 9/24 at around 6pm Chicago time.  It's now 9/30 and it hasn't
shown up yet :(
[snip]
> Thanks,
> Kohei
> 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.