Re: various meanings of static

["Pedro de Medeiros" <pedrovmm+lists@gmail.com>]

On 6/23/07, Glynn Clements <glynn@gclements.plus.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html