Re: Using a macro to simplify implementing non-const methods in terms of const overload
On 25 Aug, 12:41, "Martin T." <0xCDCDC...@gmx.at> wrote:
Hi all.
Implementing a non-const function in terms of it's const overload is an
accepted idea:
Occasionally (maybe in your real class?) but your examples and most
others that I have come across are actually just bad design.
class foo {
public:
std::string & bar() {
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:
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&)" and your use of the const bar()
would nolonger be relevant. Contrariwise, if foo were really intended
to be just a glorified struct then bar_ should be public and you would
have no need for either method.
return const_cast< std::string& >( static_cast<foo
const*>(this)->bar() );
}
const std::string & bar() const {
return bar_;
}
void mooh() {
This method is NEVER necessary - Just delete it and nobody will ever
know the difference.
(Okay I can think of one reason to have it but it's pretty obscure and
I've never seen it needed in practice).
static_cast<foo const*>(this)->mooh();
}
void mooh() const {
// mooh!
}
private:
std::string bar_;
};
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]