Fog Creek Software
Discussion Board




Deep thought for a Friday evening.

For C++ programmers.

What if a Windows LOGFONT

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_1wmq.asp

were defined as a boost::tuple?

http://www.boost.org/libs/tuple/doc/tuple_users_guide.html

Is this a good application of tuple or bad? 

christopher baus (www.baus.net)
Friday, June 04, 2004

Boost tuples are useful for writing generic functions, but using them just to redefine an existing structure is a little silly.  What would be the purpose?  Yes C++'s type system is a bit screwy, and there are a lot of things that you ought to be able to do with eg: analyzing your structures and such, but unless you've got some particular need in mind, specifying a LOGFONT as a tuple would be overkill (that's not the right time to insist on a more generic type system).


Friday, June 04, 2004

How about to define a structure of the complexity of LOGFONT? 

christopher baus (www.baus.net)
Friday, June 04, 2004

That's not complex... structures of structures of unions would be complex.

Cubist
Saturday, June 05, 2004

It wouldn't be very good. You'd lose the member names.

Tom
Saturday, June 05, 2004

It's not about defining complex structures, it's about generic programming (ie: generating structures).  The LOGFONT structure is fixed, what benefit do you see in representing it as a boost tuple?

template <class E>
tuple<E, E, E> Origin() { return make_tuple<E, E, E>(0, 0, 0); }


Saturday, June 05, 2004

> It wouldn't be very good. You'd lose the member names.

Ahh that's my point.  There is a serious limitation I think in tuples is that the names of the members are lost.  The names are important.  It is self documenting.

I understand it is about generic programming but if a function is defined to take a tuple real data is eventually going to have to be passed to that tuple. 

Maybe tuples make more sense as a return value?

christopher baus (www.baus.net)
Saturday, June 05, 2004

*  Recent Topics

*  Fog Creek Home