[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: latest formatting updates
From: |
Werner LEMBERG |
Subject: |
Re: latest formatting updates |
Date: |
Fri, 03 Nov 2000 16:26:24 +0100 (CET) |
> 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