Re: latest formatting updates

[Werner LEMBERG]

> Can you guarantee me that we will never use more than the currently
> available LOCAL_FUNC_X, etc.?  What are we going to do if people
> start complaining that the source code doesn't compile with their
> C++ compiler?  Tell them that the macros are only for Sun C++ and a
> few others, or hack the code further?

I'm rather sure that no macros will follow.  I had really long
discussions with Martin Buchholz about the macros -- without them, a
C++ compiler will produce code which doesn't work due to different
naming conventions between C++ and C.  This is not related to a
specific C++ compiler -- the tricky stuff with function pointers makes
it necessary.

> > >     - finally, what would you think about a few renaming in the
> > >       configuration macros, to make things clearer:
> > >
> > >         FT_LOCAL_DEF   => FT_LOCAL
> > >         FT_LOCAL_FUNC  => FT_LOCAL_DEF
> > 
> > I'm not happy with this.  What about
> > 
> >   *_DEF  -> FT_*_DECL   (for declarations)
> >   *_FUNC -> FT_*_DEF    (for definitions)
> > 
> > in general?
> > 
> 
> Frankly, I think that FT_EXPORT is sufficiently explicit and doesn't
> need a "_DECL", it'd be interesting to see what other people think
> about it on the developer's list..

But what about `BASE_DEF'?  Just using `BASE` looks strange to me.  I
prefer orthogonality over brevity to simplify things.

> > >         FT_VARLOCAL / FT_VARLOCAL_DEF  for constant static data
> > 
> > Example please.
> > 
>   hummm...:
> 
> #ifdef __cplusplus
> #  define  FT_VARLOCAL      extern "C"
> #  define  FT_VARLOCALDEF   extern "C"
> #else
> #  ifdef FT_MAKE_OPTION_SINGLE_OBJECT
> #    define  FT_VARLOCAL      static
> #    define  FT_VARLOCALDEF   static
> #  else
> #    define  FT_VARLOCAL      extern
> #    define  FT_VARLOCALDEF   extern
> #  endif
> #endif
> 
>   FT_VARLOCAL  const FT_Module_Class   xxxxx_module_class;
> 
>   ....
> 
>   FT_VARLOCALDEF const FT_Module_Class   xxxxx_module_class =
>   {
>     ...
>   };
> 
> we may also include the "const" within the macro, but I think
> it's better to make it explicit. Or we can also use better names
> like:
> 
>   FT_LOCAL_CONST
>   FT_LOCAL_CONST_DEF
> 
> which wouldn't be too bad..

Looks OK (but I have to actually test with a C++ compiler :-) -- this
would replace my FT_CALLBACK_STRUCT_xxx macros.  Your name suggestion
stresses the locality, while my names emphasize the functionality.
Choose whatever you prefer, but please find a good name for the
current FT_LOCAL_X also...

> By the way, a final point regarding formatting.  It's related to the
> location of the "*" in function signatures.
>
> [...]

I've actually completely ignored it, but I'll do that from now on.


    Werner