Re: Proper use of templated containers as class members
On Dec 5, 5:43 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
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.
He's returning a reference, not a value, so he needs a
directory_t object somewhere.
};
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.
I agree, sort of. The implementation is exposed by the function
returning the reference. Not using a typedef, and returning the
fully named type wouldn't change anything.
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).
If you return a reference, it can only be to a "contained
object". Otherwise, how do you manage its lifetime.
--
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