Ok good. So it sounds like my concern isn't justified. To be certain. Because of tuples I prefer this: typedef boost::tuples::tuple some_pair; typedef std::vector some_pairs; to this: struct some_pair { unsigned int i; double d; }; typedef std::vector some_pairs; Is tuples meant to be used like the first example? Thanks, Graham On 7/25/07, Joel de Guzman wrote:

Graham Reitz wrote:

...

I have been finding that the boost::tuple library is so convenient that I am concerned I may be overusing it.

For example, in situations where I might use a struct I am tend to prefer a tuple. Where is a good place to draw the line in situations like this? Or is this the intent to use it as often as possible?

Hah! You've seen nothin' yet :-) :-) If you want to see tuples pushed to the limits, see Boost.Fusion.

Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Richard Dingwall wrote:

On 7/26/07, *Graham Reitz* mailto:graham.cpp@gmail.com> wrote:

Ok good. So it sounds like my concern isn't justified.

To be certain. Because of tuples I prefer this:

typedef boost::tuples::tuple some_pair; typedef std::vector some_pairs;

to this: struct some_pair { unsigned int i; double d; }; typedef std::vector some_pairs;

Is tuples meant to be used like the first example?

Pardon me if it's just a two-dimensional example for simplicity, but why not use std::pair?

The op's intent is to use tuple instead of struct: "in situations where I might use a struct I am tend to prefer a tuple". std::pair is ok if the struct to be replaced has 2 elements. This is not always the case. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Graham Reitz wrote:

Yes, thanks Joel.

I should have used more elements in my example and not called it some_pair.

Oh and BTW, in case you don't know yet, in Fusion, structs and tuples are interchangeable. IOTW, structs *are* tuples. Sample: namespace ns { struct point { int x; int y; }; } BOOST_FUSION_ADAPT_STRUCT( ns::point, (int, x) (int, y) ) /*...*/ ns::point p = {123, 456}; std::cout << at_c<0>(p) << std::endl; std::cout << at_c<1>(p) << std::endl; (those at_c<N> thingies are Fusion's get<N> counterparts. Ala MPL!) It's the same interface as say, for vector: fusion::vector v(123, 456); std::cout << at_c<0>(v) << std::endl; std::cout << at_c<1>(v) << std::endl; Or even a boost::array: boost::array a(123, 456); std::cout << at_c<0>(a) << std::endl; std::cout << at_c<1>(a) << std::endl; Or, of course, a std::pair: std::pair pr(123, 456); std::cout << at_c<0>(pr) << std::endl; std::cout << at_c<1>(pr) << std::endl; Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Zeljko Vrba wrote:

On Thu, Jul 26, 2007 at 11:16:08AM +1200, Richard Dingwall wrote:

...

Pardon me if it's just a two-dimensional example for simplicity, but why not use std::pair?

Orthogonality. Personally, I'd find it very cumbersome to make an exception for pairs and write t.first, t.second when I write t.get<N>() for larger tuples. Plus, if the tuple should grow at some point, you'd have to fix all occurences of .first and .second.

However, I have another question regarding tuples: the debugger expands tuple to tuple [a large list of null_types in the template]. Do these null_types take space in the tuple, and do they slow down passing by value (due to unneccessary copying of null_type)?

No they don't (take space in the tuple, and do they slow down passing by value). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Great discussion! Thanks folks. Also, I didn't know that tuples and struct are interchangeable. Graham On 7/26/07, Jeff Flinn wrote:

Graham Reitz wrote:

...

Ok good. So it sounds like my concern isn't justified.

To be certain. Because of tuples I prefer this:

typedef boost::tuples::tuple some_pair; typedef std::vector some_pairs;

to this: struct some_pair { unsigned int i; double d; }; typedef std::vector some_pairs;

Is tuples meant to be used like the first example?

I use tuples or fusion containers when the names of the data members have no meaning, and you want to iterate over the members in some way. Your example, with it's members i and d, obviously falls into this category. ;)

I've also used tie to get the best of both worlds:

class tire_size { int width; int aspect_ratio; string speed_rating; int wheel_diameter; public:

...

bool operator<( const tire_size& rhs )const { return tie( width , aspect_ratio , speed_rating , wheel_diameter ) < tie( rhs.width, , rhs.aspect_ratio , rhs.speed_rating , rhs.wheel_diameter ); } };

int main() { tire_size summer911turbo(295,30,"Z",18); tire_size winter911rurbo(265,35,"H",18);

bool b = winter911turbo < summer911turbo;

return 0; };

Jeff Flinn

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Joel de Guzman writes:

...

- bind expression with tuple becomes a nightmare

Why? Ah access to the members?

Yes. boost::bind(&tp::get<1>, _1) does not work (something to do with bind's difficulties with overloads and return types?). This can be overcome by using Karlsson's tuple_select.

...

- default initialising of its members is m_member() (while sometimes we reserve -1 for uninitialised)

Dunno what you mean. Please elaborate.

Oh this simple. Let says one has a tuple with handles boost::tuple<HANDLE>; In Win32 an INVALID_HANDLE_VALUE is defined as -1. So if one writes: boost::tuple<HANDLE> tp; If at the moment of definition, the actual values are not known, it should be default intialised with invalid handles (-1) and not with zeros, which can represent valid file handles. This can of course be overcome with an extra intialiser e.g. const boost::tuple<HANDLE> g_tpInvalid(INVALID_HANDLE_VALUE); and then always write: boost::tuple<HANDLE> tp = tpInvalid; but this is an extra step. Using a structure one could handle that in the defualt constructor. Wkr, me