> Terje Slettebų <[EMAIL PROTECTED]> writes: > > >>From: "David A. Greene" <[EMAIL PROTECTED]> > >> > >> Rozental, Gennadiy wrote: > >> >>Which example is that? Is inherit_linearly documented somewhere? > >> >> > >> > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/ > >> > inherit_linearly.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup > >> > >> Well, that's not creating a boost::tuple. :) I could certainly use > >> mpl::fold or some similar algorithm to create boost::tuple<int, > >> boost::tuple<...> > > > but I'm not sure that "really" a boost::tuple > >> either. cons<int, cons<...> > > > might be closer. > > Yes, in fact, the cons< ... > structure satisfies all the requirements > for a tuple. boost::tuple is just a friendly wrapper which presents > an easy interface. > > > Here's one way. This handles tuples of up to three elements, but can easily > > be extended. > > > > It requires partial specialisation, but it could also be rewritten without > > it. In fact, I wrote a more complex version without it first, using > > compile-time if-else, but then realised I could use specialisations for > > this. > > <snip> > > Oof! > > The version using fold<> is sure to be shorter and more-general!
Well, he asked for a boost::tuple, and this gave a boost::tuple, with the exact same type. The reason I provided it was that he seemed to not be satisfied with a type that behaves the same way as boost::tuple, but don't have the same type. This could be for example if you use boost::tuple in an interface, that is being called. Your fold-solution won't work then, will it? Then it's a question of which version is more general... In short, this depends on the requirements for the solution, so don't be so quick to write it off, before you know what they are. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
