Kaya Memisoglu <k.memisoglu@xxxxxxxx> wrote: > I think there is another really important reason for the keyword 'export' > '_EXPORT' > or whatever. The keyword 'static' makes a symbol local within one source file > / object > file. Not within one dll. The other object files will know nothing about a > static function. > And this effect might not be the one you are seeking for. On the other hand, > the keyword > _EXPORT or whatever it is called will make a symbol public to the outside of > the whole dll. > You see the difference? 'static' is meant for local symbols within one > *object* file, whereas > '_EXPORT' is meant for global symbols of a *dll* file, which may consist out > of many object files. yep, i surely see the difference, but a) i also see the difference _export imposes on dynamic libraries vs. static libraries: a dll build of a given library would either export a different set of symbols or would not allow a static library build at all. and that most deffinitely is an effect _not_ sought for, as i want to be able to build dynamic or static _identical_ libraries on the expence of a single cc setting change. b) the very semantics of the c/c++ language encourages high level of inter-module visibility (AAMOF anything not explicitly 'hidden' is exported), and for good or for bad the language does not distinguish between 'source/obj' modules, 'static library' modules and 'dynamic library' modules. a good c/++ compiler should comply to the language specs. even despite the drawback of c++ not having any means for making a class hidden within its source file! the whole dllexport thing was invented to narrow down the pool of exported symbols so given the early/crippled ld's it would not take forever to load a dynamically-linked image. > At least I suspect that the linker will handle the stuff this way. In my > opinion '_EXPORT' might be a good thing (although i am currently not > participating in working for OBOS). On the other hand, one could cope with > the exportation > of all symbols in ELF by carefully using namespaces or declaration within > classes in order to avoid name conflicts. IMO, too, _export is a good thing -- in the context of obos, as it allows ppc builds. regards blu