> 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 meth
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 ""
fo
On 18 Oct 2006, at 01:10, Sheldon Gill wrote:
Well, you actually are relying on conventions anyway. You've
called the class _GSPrivate using the underscore convention to
indicate privacy.
Sure ... as I said, I used a variety of mechanisms ... to be as safe
as possible.
Also, these a
--- 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
Richard Frith-Macdonald wrote:
On 16 Oct 2006, at 04:13, Sheldon Gill wrote:
Hi Richard,
You've made some recent changes to base with the idea of making
private functions in base more obviously private and less accessible.
Yes ... as obviously private as possible.
It seems to be that the
On 16 Oct 2006, at 04:13, Sheldon Gill wrote:
Hi Richard,
You've made some recent changes to base with the idea of making
private functions in base more obviously private and less accessible.
Yes ... as obviously private as possible.
It seems to be that there is really only one goal with
Hi Richard,
You've made some recent changes to base with the idea of making private
functions in base more obviously private and less accessible.
It seems to be that there is really only one goal with these changes:
applications/tools shouldn't be using private functions in base
Is there a