Re: Private library symbols...

[Richard Frith-Macdonald]

On 18 Oct 2006, at 11:46, Matt Rice wrote:

> 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..

That's great ... exactly the sort of thing I've been looking for!

I checked various versions of the gcc documentation online, and it  
looks like this was introduced at 3.3 and is still present in 4.1

> 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...

Yes ... functions only used within a single file should always be  
static.
I think private methods should be declared in a private category and  
use an underscore prefix (and be kept to a minimum).

> private methods/functions to be used by other classes
> in the same library,

This is the case that the visibility attribute is perfect for  
(functions), and I suppose private methods should use the same  
conventions as those for internal use within a single file ... the  
only difference would be that the files inside the library need to  
share a common header to declare the library-private categories.   
I've put GSPrivate.h in base/Source for this.

> private methods to be used between libraries like the
> gui/back backend stuff..

I'm not sure we should consider gui/back interaction private ... I  
think we actually want a public API for this, which people can use to  
implement otyher backends.

> all which imho warrant different solutions...
> anyhow, toss me in the 'prefers private functions'
> boat

Well, your suggestion of the visibility attribute removes my biggest  
reason for using methods rather than functions.

 I think remaining reasons are rather a matter of taste ... do we  
want to use ObjC semantics or C semantics generally?
Do we care whether we group functionality in a class, or use a  
collection of functions with a common prefix?
Do we want to use a single style or both functions and methods?

My personal preference (but it's not a strong one) would be to group  
functionality in classes rather than have a lot of methods anyway,  
but to use private (ie visibility hidden) functions where there might  
be a performance issue.