S
Shraddha
Can I stop people by deriving my class?
I mean I don't want my class to be as a base class...
Can I do that?
I mean I don't want my class to be as a base class...
Can I do that?
V
Victor Bazarov
Shraddha said:
Yes. See the FAQ.
V
S
Sarath
Yes you can but you have to do some tweaks with your class's
construction and with inheritance.
class Usable;
class Usable_lock {
friend class Usable;
private:
Usable_lock() {}
Usable_lock(const Usable_lock&) {}
};
class Usable : public virtual Usable_lock {
// ...
public:
Usable();
Usable(char*);
// ...
};
Usable a;
class DD : public Usable { };
DD dd; // error: DD:
D() cannot access// Usable_lock::Usable_lock(): private member
You can check more about it at
http://www.research.att.com/~bs/bs_faq2.html#no-derivation
Regards,
Sarath
http://sarathc.wordpress.com/
J
Jim Langston
Shraddha said:
3 ways, shown in the FAQ:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.11
K
Kai-Uwe Bux
Shraddha said:
Technically, yes. See:
http://www.research.att.com/~bs/bs_faq2.html#no-derivation
A slightly different approach uses a protected constructor:
/*
| This defines the macro
|
| FINAL
|
| to be used to prevent derivation:
|
| struct X : FINAL {};
|
| struct Y : X {}; // declaring variables of this type won't work
*/
// credits:
/*
Found in news.lang.c++.moderated (Gennaro Prota)
see:
http://groups.google.com/group/comp...7136?lnk=gst&q=sealed&rnum=3#f63980680a2f7136
*/
class protected_constructor {
protected:
protected_constructor ( void ) {}
}; // protected_constructor
#define FINAL private virtual protected_constructor
struct X : FINAL {};
struct Y : X {}; //
int main ( void ) {
X x; // fine.
Y y; // compile time error.
}
_However_ (!!!), as explained in Stroustrups FAQ, it is highly doubtfull
that you have a valid reason to do something nasty like this. Keep in mind
that you are probably unable to predict the reasons that clients of your
code have to derive from your classes. Note that C++ supports multiple
programming styles, where different reasons for derivation are considered
valid. I doubt that you have sufficient information to decide for the
client code programmers that derivation is wrong. That is their
responsibility. Trust them; and if they screw up, it's their problem. That
said, there might be cases where you have a valid reason, although I don't
know of any convincing examples.
Best
Kai-Uwe Bux
J
James Kanze
Yes and no. Unless you're in a very strange situation, just
documenting the fact that the class isn't designed to be used as
a base class should be enough. In fact, unless you're in a very
strange situation, just not documenting how to use it as a base
class should be sufficient.
If it's not, you've got a serious problem, no matter what you
do.
G
Gennaro Prota
BTW, to clarify a too common misunderstanding, one may render any
derived class non-instantiable, not preventing derivation itself (or
usage of accessible static members in the derived class).
class final
{
protected:
final();
};
#define FINAL_CLASS private virtual final
// usage:
class my_class : FINAL_CLASS
{};
Why one might want to do that is another story
J
JohnQ
"Yes and no. Unless you're in a very strange situation, just
documenting the fact that the class isn't designed to be used as
a base class should be enough. "
A non-virtual destructor would be telltale "documentation".
John
J
James Kanze
Not always. What about std::exception?
In fact, most of the time, I think the opposite applies. Unless
the class is documented explicitly to be a base class, you
shouldn't derive from it.
J
JohnQ
"Not always. What about std::exception?"
It's destructor is declared virtual in my implementation.
"In fact, most of the time, I think the opposite applies. Unless
the class is documented explicitly to be a base class, you
shouldn't derive from it."
John
K
Kai-Uwe Bux
JohnQ said:
Nonetheless, the standard library has some examples of template classes
designed for derivation that do just fine without virtual destructors.
Think of unary_function<>, binary_function<>, or iterator<>.
Derivation in C++ is a concept orthogonal to the various programming styles
supported by the language. In the context of policy based design,
derivation from classes is often done without the need for virtual
destructors. The slogan that classes to be derived from need virtual
destructors is firmly rooted in the OO style and of somewhat limited scope.
Best
Kai-Uwe Bux
J
James Kanze
Oops. I meant std::iterator.
Z
Zachary Turner
By the same logic, just documenting that a person should not call a
particular method under any circumstances should be enough. Therefore
the "private" and "protected" keywords can safely be removed from the
language.
Declaring the destructor non-virtual is, unfortunately, the best
option we have to ensure people don't derive from classes unless you
want to seriously uglify your code. A keyword similar to
"final" (Java) or "sealed" (C#) would definitely be nice though, and
would probably see considerable use.