Re: unloading plugins (i.e. shared objects) nearly impossible!
Greg Herlihy wrote:
kanze wrote:
davidbaraff@gmail.com wrote:
[...]
If STL happened to use virtual functions (which it doesn't)
[...]
You don't know this. Stepanov didn't believe in virtual
functions, and most implementations today still derive from his
original implementation. But in a context where memory is
tight, and you can't afford code duplication, a base class
factoring out the common behavior, and using virtual functions
for the type specific parts, could be a very reasonable
implementation. Such an implementation would be perfectly
conformant.
No - although an implementation is free to add its own
non-virtual member functions to a standard library class, it
is emphatically barred from adding any virtual methods of its
own to a standard class (see lib.member.functions in chapter
17).
I'm not sure what the intent of this paragraph is supposed to
be, but it looks like a defect to me. To begin with, it says
that "an implementation can declare additional non-virtual
member functions [...]", but it doesn't ban the implementation
from making an existing function virtuel. It also limits the
additional functions to a closed set of variants of existing
functions (e.g. adding arguments with default values). Taken
literally, no implementation is conforming, because the all of
the implementations do use additional functions, like _M_leak()
(member of std::basic_string in the g++ implementation). This
also seems to contradict ?17.3.2.3, which explicitly says that
"An implementation may define static or non-static class
members, or both, as needed to implement the semantics of the
member functions specified in clauses 18 through 27." I suspect
the intent of ?17.4.4.4 (lib.member.functions) is to be limited
to those functions defined in the standard, e.g. a conforming
implementation cannot define a function std::vector::insert
which is both virtual and does not conform with one of the
signatures defined in the standard. The paragraph definitly
needs clarification, however.
Not that it matters in the current situation. It is most
definitly allowed that e.g. an implementation of
std::basic_string use a non-standard class
std::basic_string::_Rep (again, taken from the g++
implementation, but I'm pretty sure that other implementations
do similar things). And there is certainly nothing in the
standard which says that std::basic_string::_Rep cannot contain
virtual functions.
Therefore, since none of the standard container classes
declare virtual methods, and an implementation is barred from
adding any, it is safe to rely on the fact that the standard
container classes have no virtual methods.
I'm rather certain that there was no intention of banning
anything added to the private section, as long as the name
didn't impinge on the user namespace, if for no other reason
that there is no way a conforming program could tell. And there
is certainly no ban on the implementation using other,
non-standard classes, which can use virtual functions.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]