--- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote:
> > On 16 Oct 2006, at 04:13, Sheldon Gill wrote: > > > Further, if the problem is, as you say, "symbol > pollution" why not > > stop the pollution where it really is occurring: > the exports symbol > > table? Its a linker problem, not really a source > code problem. > > To be honest, that simply didn't occur to me, as I > don't know how to > do it (or even that it could be reasonably/portably > done). > What would be involved in this? If we *can* remove > symbols > effectively without breaking the library's internal > use of them or > impairing debugging, it would probably be good to do > so. > this can also be done by using the __attribute__ ((visibility ("hidden"))) function attribute found in the gcc info page.. requires gcc 3.something and not available on all platforms, but,put putting a define in there such as #define GS_HIDDEN "" for those platforms should deter usage because of the threat that most platforms used wont link coupled with the fact that the functions are not declared in any installed header files.. i haven't really looked into whats been done, but find the definition of private a little ambiguous wrt scope e.g. private methods/functions for a classes internal usage i like to keep these as static functions... private methods/functions to be used by other classes in the same library, private methods to be used between libraries like the gui/back backend stuff.. all which imho warrant different solutions... anyhow, toss me in the 'prefers private functions' boat __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev