various meanings of static
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.
Quoted 6 lines · Shriramana Sharma
Hello.
...
I am thinking of using # define-s to use these four words:
Quoted 7 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Darío Mariani
Quoted 4 lines
I am thinking of using # define-s to use these four words:
local, sticky, classwide, nothis
Quoted 8 lines
Quoted 5 lines
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.
Signature · 5 lines
Glynn Clements <[email protected]> - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 29 lines · Glynn Clements
Quoted 4 lines · Darío Mariani
Quoted 4 lines
I am thinking of using # define-s to use these four words:
local, sticky, classwide, nothis
Quoted 8 lines
Quoted 5 lines
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.
Quoted 7 lines
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.
Signature · 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 17 lines · Pedro de Medeiros
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__
#defineformat(si, ftc)__attribute__((format(printf(si, ftc))) #define internal__attribute__((visibility("hidden"))) #define public__attribute__((visibility("default"))) #define useful__attribute__((warn_unused_result)) #else
#defineformat(si, ftc)
#define internal
#define public
#define useful
#endif
Quoted 4 lines
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
Quoted 2 lines
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.
Signature · 1 line
Glynn Clements <[email protected]>
Quoted 10 lines · Glynn Clements
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.