Re: Proper use of templated containers as class members
On Dec 4, 5:46 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Maxim Yegorushkin wrote:
On Dec 4, 4:29 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Maxim Yegorushkin wrote:
On Dec 4, 3:15 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Per wrote:
class Foo
{
public:
typedef std::map<std::string, int> direcory_t;
...
I think you've cut an essential element:
directory_t const& directory() const ;
The typedef is public, and is used in the public interface.
Typedef or not, you've actually exposed the fact that your
implementation uses std::map.
};
The question is what is your opinion on typedefing like this.
I use this approach everywhere. It's an abstraction.
More often such an approach is called abstraction leak.
The interface of directory_t "abstraction" is that of
std::map<>. You can only change the type of directory_t to
something that supports the full interface of std::map<>,
otherwise you break the client code
The public typedef for the otherwise private type is worth
having [...], not because it limits potential uses of the
type, but because it serves to identify them.
My point was that it was not an abstraction, because it
abstracts away nothing but the name of the type. Rather a
convenience typedef to make code less fragile.
"Nothing but?" Abstracting the name of the type is a big
deal. When I write Java code, typedef is the single feature I
miss most, for exactly this reason. When I write
std::vector<int>::iterator, it's not just convenient; it's
because I really don't know what the underlying type is.
That's abstraction at its best.
I think Max's point was related to the fact that the typedef was
being used to expose the fact that you use an std::map in the
implementation.
It's not always obvious what the correct solution should be. If
you use the typedef, then you're pretty much committed to not
changing this aspect of the implementation, since client code
will end up depending on it. In more than a few cases, I've
ended up "wrapping" std::vector<>::const_iterator with a class
of my own, because I didn't want to expose the fact that I was
using std::vector<>, but needed to provide an iterator. Most of
the time, the wrapper class was not a random_access_iterator,
but only a forward_iterator. Just to keep my options open.
Similarly, with std::map, I won't provide access to the map per
se; I'll hoist the necessary functionality into my interface,
using real types. (In the case of std::map, I'll often change
the interface in doing so---provide a const operator[], for
example, if that makes sense, etc.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34