Here comes a very special wish - please do not call me crazy:
Working with many C modules, I prefer to define protected/"dangerous" variables static to one module. Quite often I would like to have a variable global only in a restricted number of modules - typically only in one module and then further the the communication modules (e. g. "comm1.c", "comm2.c").
To achieve this, it would be terrifically nice, if I could create the following code with a special pragma modifier (I made the examples with two modules "comm1.c" and "comm2.c", to keep the examples more general - but in fact I would be perfectly happy, if this would work with restriction to one further module "comm.c"):
#pragma RestrictedGlobal "comm1.c" #pragma RestrictedGlobal "comm2.c" int iRestricted;
(alternatively also like this (but then it would not work in other C compilers):
#pragma allowAccess "comm1.c" #pragma allowAccess "comm2.c" static int iRestricted;
)
In "comm1.c", "comm2.c" then the extern command
extern int iRestricted;
should be allowed - but it any other module it should fail (best would be, if the command itself would be allowed, but if the access to iRestricted would fail in any other module - then it is possible to include the extern declaration in some header file without the danger of failure)
I know that this is not possible in any other C compiler, but I think pragma is not standardized, so C compiler producers can add their own - just I think better use the first of the above alternatives, as then the code will also work in other C compilers not recognizing this pragma.
... I know that this might be quite an effort, as it concerns the very interior of the compiling/linking tables ... so just a polite question ... .
One further point:
If I use a global class in Keil ARM C++, and if this class has a constructor - is there some way to tell the compiler when the constructor should be called? (I mean e. g. somewhere in the assembly-startup function, in the c-startup function, or at the start of the main function?)
A global class? A class is a data type. As expert C++ programmer, I would have expected you to talk about a global object - i.e. an instantiation of a class.
Well - the startup code have to make sure that the constructor is called before the code enters main(). Just as the startup code have to make sure that the interval variables in the C library gets initial values after the startup code have mapped RAM but before you reach main().
If you want the constructor to be called after you enter main(), then you should create the object as an auto object on the stack. That allows main() to contain code that makes decisions before the constructor is called. So you could decide what parameters to send to the constructor.
But this reply is not very precise.
If you say, that the "constructor will be called before main"... You know that in an ARM software quite a bit is happening before main, especially all the core initialisation and the PLL clock startup. Can I be sure, that the compiler will be smart enough to call such global constructors after the basic core initialisation and PLL clock startup code? (how should the compiler recognize this code ...?)
If you put PLL initialization inside main(), then you know the global objects will be constructed before the PLL is initialized.
But an assembler startup file will not initialize any global C++ objects randomly. So you can spend whatever time you want setting up PLL etc before you let the startup script call the functions that initializes variables, constructs objects etc.
You may get an initial copy of a startup file when you create a project. But after that, you own that file. You can do whatever you like with it, before you let it call the finial init function(s) that setups the runtime library, global variables etc before main() is called.