From 2515283362141831313 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5ca55e7ece19bbaa X-Google-Attributes: gidf78e5,public X-Google-Thread: fc772,5ca55e7ece19bbaa X-Google-Attributes: gidfc772,public X-Google-ArrivalTime: 2001-06-23 11:42:06 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsxfer.eecs.umich.edu!uwm.edu!rpi!not-for-mail From: marco@technoboredom.net (Marco Manfredini) Newsgroups: comp.lang.c++.moderated,comp.std.c++ Subject: Re: standardize C++ behavior regarding dlopen()/dlclose()? Date: 23 Jun 2001 14:42:06 -0400 Organization: Runciter Associates Lines: 52 Sender: cppmods@netlab.cs.rpi.edu Approved: kuehl@fmi.uni-konstanz.de Message-ID: References: <6faaf36e.0106212009.afe2d51@posting.google.com> NNTP-Posting-Host: netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAOzRPvOEDnX0m9pzZAQErbgF/c1JzVdL2/aMSkOGLgVQdpKA0t5h/jzGh rxN3LWFRRWhxhq+4mZa0wnYKkciTTGom =roaG X-Approved-For-Group: Fergus Henderson comp.std.c++ X-Original-Date: 23 Jun 01 08:13:44 GMT X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAOzTi90HMCo9UcraBAQE6fwH7Bh27zsllvufBlmiOfRgbYqnN5qZIUgAO pnWuuuOrZ8Y3oF8UX+ZyHEnSufI75aaby+PZ2SCp4gq5tciOLRv+aw== =lfnf Xref: archiver1.google.com comp.lang.c++.moderated:21036 comp.std.c++:6264 bgreen@nas.nasa.gov (Bryan Green) wrote in news:6faaf36e.0106212009.afe2d51@posting.google.com: > 1) Use of static objects in a plugin. I agree. The lifetime of a static should bounded by the lifetime of the code/data object that contains the static. The Standard says a "Program" consists of one or more translation that are linked together. I'd say this is true for a shared object file, that does not have to be -linked- with the loading process (that's the important restriction here) > 2) RTTI > If two plugins share an abstract class by which they communicate, > say class T, shouldn't each module have a comparable definition of > 'typeid(T)'? (assuming T has implementation details in a shared > library they each link against, or it is purely abstract and lives > only in a header file.) > That is, if one plugin passes a pointer 'p' of type T to a second > plugin, the second plugin should be able to successfully perform > the test > 'typeid(*p) == typeid(T)'. typeid() returns a reference to a type_info. If this has to work with a dynamic module, a run-time linker would have to merge the type_info's from the module with the loader (which he isn't allowed to do, for the sake of the statics, see above) . Now suppose the module and the loader both define a class Floxi with -different- interfaces. Either a) because they used different interface specifications or b) by a simple naming accident (or for example both link to a helper library, for internal purposes, but with different versions) etc.. Not good. To precent accidents like that, one could advise, that the compiler generates a md5 of a type's full signature which could be part of the mangled name...etc..but I don't think that this is going into the right direction. C++ is very delicate about what happens -outside- of the linkage: changing a virtual member function in some base class can break the binary compatibility of a derived class etc..In any case it would turn out that C++ had to define a standard ABI binary interoperability, which I don't see, since there are already Corba & other Middleware Standards, that define General Plugin Frameworks. -- Marco --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.research.att.com/~austern/csc/faq.html ]