Re: learner's question on populating vector< pair<int, string>* > as
member
On Apr 29, 1:34 pm, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
On Apr 28, 4:10 am, James Kanze <james.ka...@gmail.com> wrote:
subramanian10...@yahoo.com, India wrote:
#include <cstdlib>
#include <iostream>
#include <vector>
#include <utility>
using namespace std;
class Test
{
public:
Test();
~Test();
typedef pair<int, string> pair_type;
typedef vector<pair_type*> container_type;
void store_pair(const pair_type& arg);
const container_type& container() const { return c; }
I also have a lot of doubts about exposing the implementation
like this. If you're going to do this, you might as well make
the container public, and be done with it.
By saying 'Exposing implementation', are you referring to
"const container_type& container() const { return c; }" ?
If so, I am returning only 'const container_type&'.
Will that create any problem ?
It locks you into the actual container_type. Which should be
(probably) an implementation detail. (Of course, you've
typedef'ed it, so the user code should only count on the
guarantees you've specified for container_type.)
An alternative that I can think of is to make operator<<
a friend because, only in operator<<, container() is needed.
Exactly. And you're the author of operator<<. So there's
absolutely no need to let the client code in on the secret (and
risk having it depend on it).
But Stroustrup has advised to avoid friend functions(except
to avoid global data and public data).
Well, that's just a sort of general advice. You certainly
shouldn't make just any and every function a friend. But in
this case, I'd more or less consider the operator<< as a member
(since you write it as part of the class implementation), but
called with a different syntax. Using friend in such cases
generally increases encapsulation and coherence, which is a good
thing. Anyhow, if the choice is exposing some otherwise
unnecessary detail to client code, or making a function which is
really part of my public interface a friend, I'll go with the
latter every time.
Another possibility---one I actually use a lot---is to provide a
member function print(std::ostream&), and have operator<< call
it. To tell the truth, however, I suspect that in my case, it's
more a case of ingrained habit, than for any good reason. One
of the first places where I used C++ had a coding guideline to
the effect that overloaded operators should always forward to a
named member function (probably to unnecessarily avoid the
friend), and since then, that's the way I do it. (It's a useful
idiom when inheritance is involved. operator<< can't be
virtual, since it can't be a member. Test::print can be.)
--
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