Re: Using a macro to simplify implementing non-const methods in terms of const overload
"Nick Hounsome"
Occasionally (maybe in your real class?) but your examples and most
others that I have come across are actually just bad design.
....
This is a bad example because it exposes the implementation of foo
(foo MUST contain a std::string).
Even worse it allows a client to maintain a reference to the guts of a
foo after the object has been destroyed:
....
Yeah, there are guidelines to avoid this when possible -- but for the rest
of the cases it is good and natural. For classes that are just
holders/collections/aggregations.
Is std::vector 'bad design' for having const and non-const accessors?
Sure, pointers and refs come with lifetime issues attached, but it shall be
pretty common for any C/C++ user, and whoever can't cope with the thing (in
general) is just not fit as a programmer.
foo* fp = new foo;
std::string& s( fp->bar() );
delete fp;
s.length(); // ooops! Undefined behaviour.
To keep the implementation hidden you must instead have something like
"void setbar(const std::string&)"
You mean
void setbar(std::string)
that actually prevents aliasing and a possible storing of the address or
binding to a ref... As long as we're addicted to 'efficiency' so
sacrificing the separation, the point is kinda moot.
The set() interface looks good as long as the argument is simple enough, but
what if it is a map<string, vector< > > and we'd just want to change a
single item in it?
Exposing the internal type is a problem only if it will actually change --
and the cure of abstraction and writing forwarders may be deals worse than
the disease. :)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]