On 6/23/07, Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> wrote:
Darío Mariani wrote:
> > I am thinking of using # define-s to use these four words:
> >
> > local, sticky, classwide, nothis
> >
> > instead of static in my C++ programs to make them more meaningful. I
> > believe that the above four are mutually distinct purposes of the single
> > static keyword and whether a future C++ standard disambiguates these
> > purposes or not (where I prefer it would) I can even now use these new
> > clearer keywords.
>
> IMHO, I think it's not a good idea to add your own keywords to your
> code. This will make it harder for anyone else to read it.
It also makes it harder for software (other than the compiler) to read
it.
It isn't enough that the compiler can understand the code. It also
needs to be understood by text editors, lint, indent, etc. Such
programs invariably use syntax which doesn't exactly match the
definition of the language.
The C preprocessor makes that almost inevitable. Remember, source
files are what goes *in* to the preprocessor, while the syntax of C
(the structured grammar written in BNF in the appendix of any decent C
textbook) describes what comes *out* of the preprocessor.
In practice, most programs (other than the compiler) which attempt to
parse C (e.g. text editors which perform syntax highlighting,
indentation, etc) simply ignore preprocessor directives and assume
that any names are simply variable/function/field/tag names, not macro
names.
If you cause this assumption to fail, someone will get bitten.
The problem is that some people already consider a good practice to
create their own 'decorators' when they use GCC extensions, but they
need to turn them off when the compiler doesn't support such features.
Consider this, for instance:
#ifdef __GNUC__
#define format(si, ftc) __attribute__ ((format(printf(si, ftc)))
#define internal __attribute__ ((visibility("hidden")))
#define public __attribute__ ((visibility("default")))
#define useful __attribute__ ((warn_unused_result))
#else
#define format(si, ftc)
#define internal
#define public
#define useful
#endif
Some of those 'decorators' are valuable assets when detecting code
mistakes, maintaining library encapsulation and whatnot. Not using
#defines is not an option, since other compilers may not support those
GCC extensions. Should we discard them because some highlighting
editors don't know what to do with them?
Cheers,
Pedro.
--
Pedro de Medeiros - Ciência da Computação - Universidade de Brasília
Home Page: http://www.nonseq.net - Linux User No.: 234250
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
