Re: [boost] MPL select question

From: Thomas Witt (witt_at_[hidden])
Date: 2002-07-30 03:49:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aleksey

On Tuesday 30 July 2002 04:15, Aleksey Gurtovoy wrote:
>
> But pairs have only two elements, don't they? :).

I think they do, but I don't have a copy of the standard available right now 
:-).

> 'select1st/2nd' are
> compile counterparts of SGI STL's run-time components of the same names.

As you might have guessed I don't like them either. What I was thinking of was 
a run/compile-time select  that works for pairs/tuples and what there is 
more. I know that this is beyond the scope of MPL, but its not beyond the 
scope of boost. 

> They exist mostly to make STL programmers to feel themselves at home ;).
> They work with pairs only, and they don't need a generalization, because a
> generic way to access an element in more than a 2-element container already
> exists - 'template< typename N, typename Sequence > struct at;'.

I have to admit I missed that one. I kind of dislike the idea of fattening the 
lib with select1st/2nd when there is at, but I think they are needed for 
compilers that do not have partial specialization, aren't they?

>
> On a slightly aside note, may be it would make sense to make a pair a
> full-fledged sequence (so, among other things, you could pass it to 'at');
> at very little cost we would have one more sequence to play with :).

On a practical point of view, what I need is a generic way to access elements 
in tuples, pairs and other sequences at run- and compile time. All these 
slightly different solutions for the same problem are a nuisance. So I would 
be happy if MPL would handle pairs as a sequence.

Just my 2c.

- --Thomas

- -- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE9RlMq0ds/gS3XsBoRAgx3AJj0+T2dEZ01ZoXu0oEMbKQn6qC5AJ0cvRRa
VAcL5MhrPCPAUOdShQECEQ==
=s1ee
-----END PGP SIGNATURE-----