copy from keys from multimap into the vector

[James Kanze]

Re: copy from keys from multimap into the vector

On Oct 30, 12:15 am, Juha Nieminen <nos...@thanks. invalidwrote:

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

But it isn't kool, or in:-).

A lot depends on context. If you often have code which can use
the standard algorithms, provided you can map to only the key or
the mapped type, then it's worth writing functional objects
which do this mapping, and using boost::transfor m_iterator as
arguments to the constructor. For a one of use, on the other
hand, it's really a question of why be simple, when you can be
complicated. Unless, of course, your goal is mainly to show
off.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: copy from keys from multimap into the vector

On Oct 30, 3:40 am, puzzlecracker <ironsel2...@gm ail.comwrote:

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

That's exactly my point. Guys, do you see how this solution
is verbose, cluttered, and not particularly expressive over my
traditional solution? Meyers allegedly encourages to use
transforms, copy and other algorithms in the STL library. And
I am confident that for this problem, he would still pick a
stl-like solution. However, using transform, in this case,
doesn't telegraph your intent

It doesn't. You're transforming the values of a map into
strings (or whatever).

This merits a half a :-). I actually agree with you. But
mainly because despite the contortions of the standard library;
a map conceptually isn't a "container" of objects, but has keys
and values. And you don't want to transform the keys, just copy
them. If you think of a map as a container of key-value pairs,
which is how the standard library views it, then you are
transforming a key-value pair into a key.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[gpderetta]

Re: copy from keys from multimap into the vector

On Oct 30, 12:23 pm, James Kanze <james.ka...@gm ail.comwrote:

On Oct 30, 3:40 am, puzzlecracker <ironsel2...@gm ail.comwrote:
>

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

That's exactly my point.  Guys, do you see how this solution
is verbose, cluttered, and not particularly expressive over my
traditional solution?  Meyers allegedly encourages to use
transforms, copy and other algorithms in the STL library. And
I am confident that for this problem, he would still pick a
stl-like solution. However, using transform, in this case,
doesn't telegraph your intent

>
It doesn't.  You're transforming the values of a map into
strings (or whatever).
>
This merits a half a :-).  I actually agree with you.  But
mainly because despite the contortions of the standard library;
a map conceptually isn't a "container" of objects, but has keys
and values.  And you don't want to transform the keys, just copy
them.  If you think of a map as a container of key-value pairs,
which is how the standard library views it, then you are
transforming a key-value pair into a key.
>

You can also think of an std::map as relation (in the relational
algebra sense). In this model transform is equivalent to the
projection operation. Boost.Multimap makes the model more explicit,
but it also works well for standard associative containers.

--
gpd

[puzzlecracker]

Re: copy from keys from multimap into the vector

On Oct 30, 7:23 am, James Kanze <james.ka...@gm ail.comwrote:

On Oct 30, 3:40 am, puzzlecracker <ironsel2...@gm ail.comwrote:
>

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

That's exactly my point.  Guys, do you see how this solution
is verbose, cluttered, and not particularly expressive over my
traditional solution?  Meyers allegedly encourages to use
transforms, copy and other algorithms in the STL library. And
I am confident that for this problem, he would still pick a
stl-like solution. However, using transform, in this case,
doesn't telegraph your intent

>
It doesn't.  You're transforming the values of a map into
strings (or whatever).
>
This merits a half a :-).  I actually agree with you.  But
mainly because despite the contortions of the standard library;
a map conceptually isn't a "container" of objects, but has keys
and values.  And you don't want to transform the keys, just copy
them.  If you think of a map as a container of key-value pairs,
which is how the standard library views it, then you are
transforming a key-value pair into a key.
>
--
James Kanze (GABI Software)             email:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James, you're essentially supporting my asserting not only in regard
to my example, but STL in general. Even though STL solves a lot of
computational problems, but it does in fact has a tendency to
introduce maintenance and readability nightmare.

Boost, ah, we don't use it in our shop.

Is there a list of companies who use Boost ?

Thanks

[puzzlecracker]

Re: copy from keys from multimap into the vector

On Oct 30, 7:23 am, James Kanze <james.ka...@gm ail.comwrote:

On Oct 30, 3:40 am, puzzlecracker <ironsel2...@gm ail.comwrote:
>

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

That's exactly my point.  Guys, do you see how this solution
is verbose, cluttered, and not particularly expressive over my
traditional solution?  Meyers allegedly encourages to use
transforms, copy and other algorithms in the STL library. And
I am confident that for this problem, he would still pick a
stl-like solution. However, using transform, in this case,
doesn't telegraph your intent

>
It doesn't.  You're transforming the values of a map into
strings (or whatever).
>
This merits a half a :-).  I actually agree with you.  But
mainly because despite the contortions of the standard library;
a map conceptually isn't a "container" of objects, but has keys
and values.  And you don't want to transform the keys, just copy
them.  If you think of a map as a container of key-value pairs,
which is how the standard library views it, then you are
transforming a key-value pair into a key.
>
--
James Kanze (GABI Software)             email:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James, you're essentially supporting the claim not only in regard
to my example, but STL in general. Even though STL solves a lot of
computational problems, it does in fact has a tendency to
introduce maintenance and readability nightmare.

Boost, ah, we don't use it in our shop.

Is there a list of companies who use Boost ?

Thanks

[puzzlecracker]

Re: copy from keys from multimap into the vector

On Oct 30, 7:23 am, James Kanze <james.ka...@gm ail.comwrote:

On Oct 30, 3:40 am, puzzlecracker <ironsel2...@gm ail.comwrote:
>

Given that the while loop solution only requires 2 lines of
code, I think it's the easier solution... ;)

That's exactly my point.  Guys, do you see how this solution
is verbose, cluttered, and not particularly expressive over my
traditional solution?  Meyers allegedly encourages to use
transforms, copy and other algorithms in the STL library. And
I am confident that for this problem, he would still pick a
stl-like solution. However, using transform, in this case,
doesn't telegraph your intent

>
It doesn't.  You're transforming the values of a map into
strings (or whatever).
>
This merits a half a :-).  I actually agree with you.  But
mainly because despite the contortions of the standard library;
a map conceptually isn't a "container" of objects, but has keys
and values.  And you don't want to transform the keys, just copy
them.  If you think of a map as a container of key-value pairs,
which is how the standard library views it, then you are
transforming a key-value pair into a key.
>
--
James Kanze (GABI Software)             email:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James, you're essentially supporting the claim not only in regard
to my example, but STL in general. Even though STL solves a lot of
computational problems, it does in fact have a tendency to
introduce maintenance and readability nightmare.

Boost, ah, we don't use it in our shop.

Is there a list of companies who use Boost ?

Thanks