Re: Iterating a std::vector vs iterating a std::map?

James Kanze wrote:


  While in certain large projects it's a good idea to abstract
implementation details away as much as possible, in smaller projects
trying to abstract everything away can be more work than it's worth.

  For example, suppose you have some function or member function which
takes, let's say, a std::vector as parameter:

class Something
{
 public:
    void foo(const std::vector<unsigned>& values);
};

  This is very unabstract code. It hard-codes both the data container
and the element type. One would think that it's a good idea to abstract
that away a bit, for example:

class Something
{
 public:
    typedef std::vector<unsigned> ValueContainer;
    void foo(const ValueContainer& values);
};

  Now if all the outside code uses Something::ValueContainer instead of
std::vector<unsigned>, everything is well? Maybe, except that that
typedef doesn't enforce anything. You can still see that what's being
used is really a std::vector<unsigned>, and nothing stops you from using
that type directly and passing instances of it to Something::foo().

  Moreover, even if the outside code would strictly adhere to always
using Something::ValueContainer, exactly which member functions of that
type is it allowed to use? Since it is a std::vector, all of the
std::vector functions are free to be used, making it more difficult to
change the type of ValueContainer later to something else. You quickly
notice that, in fact, you didn't abstract anything away at all with that
typedef. You are just using an alias.

  So if you want to truly abstract the type away you have to do it like:

class Something
{
 public:
    class ValueContainer;
    void foo(const ValueContainer& values);
};

and then you define Something::ValueContainer as a class which contains
the necessary member functions for passing the numerical values to
Something::foo().

  The problem? Now Something::ValueContainer will be way more limited
than std::vector is. For example, the calling code might benefit from
things like random access with that data container, so if ValueContainer
doesn't provide it, it hinders what the code can do.

  Of course this is intentional: By not providing random access you are
more free to change the internal data structure to something else if
needed (eg. std::list). However, by being too careful like this, you are
now hindering the outside code.

  What you could do is to add a way to initialize a
Something::ValueContainer with a set of values (from a container or an
iterator range). However, what you have done now is effectively move the
abstraction problem from Something to Something::ValueContainer,
achieving only little advantage. You could as well have done that with
Something::foo() directly.

  It might also introduce an inefficiency because now values need to be
copied around instead of the calling code just using the same container
for both whatever it needs to do (eg. requiring random access) and
making Something read from it, so the values don't need to be copied
anywhere just for Something::foo() to read them.