Re: Proper use of templated containers as class members
James Kanze wrote:
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.
No, he didn't. It's a conversion function. Whatever his implementation
uses, the user *can* have it in the form of a 'directory_t' object.
There is nothing "exposed" here. It's the same as having 'asString'
member. My implementation doesn't use a string to represent the value
internally, but you can have the string if you so desire.
};
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.
If that's so, it's a very weak point. The typedef is there for the
user's convenience. Nothing more, nothing less.
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.)
That's unnecessary IMO and IME. The user does not have direct access to
the contained object (well, *if* the user knows that I'm returning a
reference to the contained object, they can do 'const_cast' and fiddle
with the 'map' directly, but that's *not in the contract* expressed in
the class interface).
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask