Re: latest formatting updates

[David Turner]

Hi Werner,

> 
> >     - please do not format the cache yet, it still in alpha
> >       phase (through __very__ near beta), I still need to
> >       change a few things in the internal class layout..
> 
> Too late :-)  Hopefully, you can use my formatted code as the basis to
> the next changes.
>
Well, actually, your changes created too many conflicts with mine, so I
had to scrap them on my machine, but I'll try to re-code them in.. :-)

> >     - I'd like to have more information on the FT_CPLUSPLUS
> >       and FT_LOCAL_FUNC_X macros?
> >
> >       To me, it seems that these macros are only useful
> >       when _compiling_ the library with a C++ compiler. Am I
> >       right?
> 
> Yes.
> 
> > Do we really need these?
> 
> I think so.  Maybe I'm paranoid -- but I'm not the only one!  For
> example, Martin Buchholz, one of the maintainers of XEmacs, regularly
> compiles XEmacs with Sun's picky C++ compiler...  And I have access to
> that compiler luckily.
> 
> BTW, there are *no* warnings if the highest warning level is
> activated...
>
That doesn't mean you'll get no warning with another C++ compiler, believe
me :-) And I don't want to lose time on "fixing" the warnings for another
picky or brain-dead C++ compiler with yet another bag of clever macros..

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

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

the "DEF" is really there to make a distinction..

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

> >         FT_CALLBACK / FT_CALLBACK_DEF  for "call-back" functions
> >                                        (replaces FT_CPLUSPLUS)
> 
> Just for clarification:
> 
>   LOCAL_FUNC_X is used for (local) functions which are intended to be
>   assigned to a function pointer in an external structure.  Since the
>   structure is `extern "C"', the function must be the same.
> 
>   LOCAL_VAR is needed for structure declarations (in header files)
>   which contain function pointers.  The pendant in source files for
>   structure definitions is FT_CPLUSPLUS.
> 
> I suggest the following name changes:
> 
>   LOCAL_FUNC_X -> FT_CALLBACK_DEF
>   LOCAL_VAR    -> FT_CALLBACK_STRUCT_DECL
>   FT_CPLUSPLUS -> FT_CALLBACK_STRUCT_DEF
>

Seems good, even though I personnaly prefer to get rid of "DECL" :-)

By the way, a final point regarding formatting. It's related to the
location of the "*" in function signatures. The rules are:

  - the "*" is normally part of the type, and should be put on
    the left in a parameter or variable declaration, as in:

        foobar*     foo;

  - however, when declaring/defining an "out" parameter (or "inout" one),
    one "*" must be placed on the right in order to denote this, as in:

        FT_New_Face( FT_Library     library,
                     FT_Face       *aface );

    where the "*" is used to indicate that "aface" is returned.

It seems you didn't use this convention in your latest updates, so I
just wanted to be sure you had it in mind..

Ok, I'll reformat the new macros myself this afternoon. Thanks for all :-)

- David


>     Werner