Re: Why doesn't CMap have a copy constructor?
On Fri, 30 Jan 2009 10:01:49 +0100, "Giovanni Dicanio"
<giovanniDOTdicanio@REMOVEMEgmail.com> wrote:
While std::map doesnot offer a method to get a list of the contained keys,
there isn't anything to stop you from iterating a map and retrieving all
the keys.
You are right. And also I'm aware that e.g. with STL std::string it is
possible to do something like erase(0, find_first_not_of(" \t\n")) [*] to
trim left spaces, but my point is: why should I write that myself, instead
of having a clear TrimLeft() method available out of the box?
[*] This code was originally posted by David Wi.
Doing this though, does not retrieve the keys in any type of order, they
would be unordered. Perhaps they would be retrieved in the order they
were added? I don't know.
I was not thinking of any particular order. Just getting the collection of
the keys in the map, returned in a simple container like a
std::vector<KeyType> would be good for me.
Of course, I'm aware that I can iterate the map with something like this:
std::vector< KeyType > theKeys;
std::map< KeyType, ValueType >::const_iterator it;
for (it = myMap.begin(); it != myMap.end(); ++it )
theKeys.push_back( (*it).second );
...but again my point was having a richer public interface with some new
methods to do this job out of the box.
See Meyer's article, in particular the section "Minimalness and
Encapsulation":
How Non-Member Functions Improve Encapsulation
http://www.ddj.com/cpp/184401197
Concerning functions like TrimLeft, well, you'll never include enough
functions to please everyone, and as for the keys, maybe it just wasn't
thought of or considered particularly important, etc. Functions that you
consider especially handy can always be written as non-members in some
namespace, which I do believe is the "right way" to extend classes like
std::string. (And this extension technique is the only thing in this
message I feel pretty sure about; I tend to err on the side of "fat" as
opposed to "minimal" when I design classes.) Of course, there is the need
to use a different syntax to call them, there may be multiple
implementations of the same thing in code derived from different sources,
unskilled people may write buggy versions of these functions, etc, and
these are legitimate objections. If you're looking for a reason to use
std::string instead of CString, here's one: It doesn't make you dependent
on MFC. Some people would call that virtuous. :) Practically speaking, it
would be somewhat nuts to drag MFC into code that doesn't otherwise use MFC
just for CString.
--
Doug Harrison
Visual C++ MVP