Question on Myers #30

[Marcelo Pinto]

No, they don't.

I have a copy of C++ Coding Standards by Sutter and Alexandrescu and
Scott Meyers is cited in 50 of the 100 items. And I once read one of
the Exceptional books and it said something like "Effective CD is a
good source of information"

 

[Howard]

Were talking about "Avoid member functions that return pointers or
references to
members
less accessible than themselves," right?

Not exactly. The reason I jumped in was that Mr. Meyers' whole point
revolved around the reference being non-const. He was just showing one way
that data that should be private can be exposed via a public interface, and
that such a thing be avoided by using a const reference instead.

This is the same as my example, and I'm arguing that contrary to Meyers,
sometimes it's okay. I've given the argument twice now.

I will certainly concede that sometimes it is appropriate, and maybe even
needed. Mr. Meyers' statement was to "avoid" such a thing, which in my
opinion leaves plenty of room for "sometimes". And I still feel he's
got a valid point, certainly not rubbish, even if it wouldn't make a good
"hard and fast rule". Something to at least consider when designing a class
with private data, certainly. But really, my whole point in being here was
to correct the OP's posting that left off the critical "non-const" part, not
to argue the validity or scope of Mr. Meyers' argument.

-Howard

 

[Master of C++]

Oops ! I just nocited that my library (still !) has the first edition
of Meyer's book. In the first edition, he did not have that "non-const"
modifier in his chapter, but he seems to have corrected it in the
second edition. Even then, I wish he mentioned somewhere that it is ok
to do it in certain situations (esp, containers).

-Vijay.

 

[Jonathan Turkanis]

Not exactly. The reason I jumped in was that Mr. Meyers' whole point
revolved around the reference being non-const.

But I was talking about non-const references.

He was just showing
one way that data that should be private can be exposed via a public
interface, and that such a thing be avoided by using a const
reference instead.



I will certainly concede that sometimes it is appropriate, and maybe
even needed. Mr. Meyers' statement was to "avoid" such a thing,
which in my opinion leaves plenty of room for "sometimes".

True, except that in the desicussion following the heading he says that
violating the rule (or guidline, or rule of thumb, or whatever) doesn't make
sense.

He also says that returning a non-const reference to member data is equivalent
to making it public, which is another thing I was arguing against.

Jonathan

 

[Jonathan Turkanis]

std:air, for example the one returned from map, contains copies of
the elements.

This relates to the design of std::map, not std:air. There's good reason not
to be able to freely modify key in map.

Jonathan

 

[Ioannis Vranos]

This relates to the design of std::map, not std:air. There's good reason not
to be able to freely modify key in map.

Yes. Perhaps I did not understand your point.