Gennadiy Rozental wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:elskhd$b32$2@sea.gmane.org...
Gennadiy Rozental wrote:
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:006401c71f85$12d1a8b0$20570252@fuji...
Weapon Liu wrote:
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 can give you one use I have for tuples:
I have a piece of boilerplate code that accepts a tuple (of any size) and prints out either a csv file or a boost::array C++ code conaining the data passed.
It allows me to output data for graphing, or matrixes of test data very quickly just by creating a short function that returns a tuple, and then passing that function to my boilerplate. If I want more columns of data I just increase the size of tuple by 1.
I suppose I could have used a vector instead, but it's less elegant somehow. How the std::vector<boost::variant> is less elegant?
1. It's could be implemented in cpp file. Your tuple based solution is in header right? 2. It allows dynamically sized entries, so you could skip some of the default values 3. It's as fast of could be even faster since we don't need to pass big structures around
The only drawback is that you need to know set of types ahead of time. But this is minor IMO and it's quite easy to add an extra type whether a need arise. Another drawback of std::vector<boost::variant> is speed, of course.
This is not clear cut. I do not see in theory why any boost::variant based algorithm couldn't be optimized to almost the same code (module type switching). On the other hand excessive usage of tuples will cause appropriate code bloat, eventually leading to code slow down.
Test it; profile it. You'll see what I mean :) Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net