Le Vendredi 17 Juin 2005 10:04, Thomas Jarosch a écrit : > > > > I think so, with the global init doing nothing IF an environnement > > > > variable "LIBXMLPP_NO_STATIC_INIT" has been defined. > > > > > > This still requires recompilation and is therefore not ABI compatible, > > > IMHO. > > > > I think I disagree : the current global initialisation is done by > > Init::Init. We can, without breaking the ABI, change its behavior so it > > does nothing when a particular environment variable is set. > > We can add another class, let's say InitNG, which does what you suggested > > for Init. > > This way people who want to do manual initialisation can do it by setting > > this variable. > > Sorry, missed the environment part while reading > as you wrote the french version ;-) Sorry :-) > I would take the the environment variable as last option > because that's not very intuitive for the end user. > (f.e. program crashes because he/she forget to set it) I don't think it's a good solution either. > > Another way I just thought about is not to change Init::Init behavior, > > but adding both another init class and a free function (probably a static > > function of the new init class) which undo what Init have done and forces > > it's destructor not to do anything. > > The advantage is that the proper behavior of the program does not depend > > on a user intervention. > > That would be an option, though it's still messy. A bit messy, but still better than the environment variable solution (it does not rely on the user, so it's reliable), and not breaking the ABI. For now I don't see another way to achieve your goal not breaking the abi and being reliable. The only other way would need a specific compilation of libxml++ for your project, which break the ABI. > Is there a garantuee > from the compiler in which order global objects are created? Unfortunately no. That would be too easy :-) I know that with gcc we can be pretty sure the library global initialisation is done before the main program one. But we can't rely on it, as other compilers will cause problems. Regards, Christophe
Attachment:
pgpLK9LqUMa5H.pgp
Description: PGP signature