various meanings of static

various meanings of static

[Shriramana Sharma]

Hello.

To my thinking, the keyword static is used for four different purposes 
in C++. I will explain this and I request your comments on that:

1. "static" is used in the declarations at file scope of variables and 
functions to make them "local" -- i.e. visible only within that file.

2. "static" is used in the declarations of variables inside functions to 
make them "sticky" -- i.e. not get destroyed when the function is exit. 
They "stick" around.

3. "static" is used in the declarations of variables inside classes to 
make them "classwide" -- i.e. common to all instances of that class, in 
contrast with other member variables which are unique to each instance.

4. "static" is used in the declarations of functions inside classes to 
make them "nothis" -- i.e. not take/require a silent "this" pointer to 
be passed, and hence be able to be called without an instance of that 
class to exist.

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.

Are there any other meanings to static? Or are there any objections to 
the above classification?

Thank you.

Shriramana Sharma.

Re: various meanings of static

[Darío Mariani]

On 6/23/07, Shriramana Sharma <samjnaa@gmail.com> wrote:
> Hello.
>
> ...
>
> 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.
Darío
-
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

Re: various meanings of static

[Glynn Clements]

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.

-- 
Glynn Clements <glynn@gclements.plus.com>
-
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

Re: various meanings of static

[Pedro de Medeiros]

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

Re: various meanings of static

[Glynn Clements]

Pedro de Medeiros wrote:

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

The usual solution is to use __attribute__ directly, and redefine that
for non-gcc compilers, e.g.:

	#if !defined __GNUC__ || __GNUC__ < 2
	#undef __attribute__
	#define __attribute__(x)
	#endif

> Should we discard them because some highlighting
> editors don't know what to do with them?

In the specific case of defining macros for gcc attributes, the impact
upon human-readability is the main factor against using them. In terms
of machine-readability, the macros are no worse than explicit
__attribute__ declarations.

Using the preprocessor to create a project-specific language is seldom
as good an idea as it may seem at the time, as you tend to end up with
code which only the author understands.

In general, to be able to work on a C source file should only require
knowledge of C along with the types, variables and functions used by
that particular file. Having to be familiar with a large number of
project-specific conventions and idioms before you can touch anything
tends to result in code which is hard to maintain.

E.g. one of the coding conventions for the Linux kernel is that
typedefs aren't used for structure or pointer types, so that variables
which contain structures or pointers can be readily identified from
their declaration alone.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: various meanings of static

[Pedro de Medeiros]

On 6/25/07, Glynn Clements <glynn@gclements.plus.com> wrote:
>
> Using the preprocessor to create a project-specific language is seldom
> as good an idea as it may seem at the time, as you tend to end up with
> code which only the author understands.
>
> In general, to be able to work on a C source file should only require
> knowledge of C along with the types, variables and functions used by
> that particular file. Having to be familiar with a large number of
> project-specific conventions and idioms before you can touch anything
> tends to result in code which is hard to maintain.

Yes, now I agree.

Well, if macros are not worse than __attribute__ declarations for
machine-readability and if you acknowledge their usefulness, then
maybe you should have given the reason above in the first place. ;-)

Cheers,
Pedro.