??? 12/05/07 16:32 Read: times |
#147911 - I may take issue with this one... Responding to: ???'s previous message |
Also, because I usually split the project into small modules I have a bunch of extern declarations here..
It sounds a bit like you have some externs defined system wide. Normally I only have "public" variables available in the .h file on a module by module basis, so that the variables are not "exposed" to modules that don't need them. It's not a horribly dangerous situation, but it's tidier I think. Even better is to use Get() and Set() functions on the module and not expose the variable at all. That kind of depends on having the CPU resources to do it. Of course most good programming practice has a cost. |
Topic | Author | Date |
How to write portable code | 01/01/70 00:00 | |
C is a language - not a compiler | 01/01/70 00:00 | |
PL/M | 01/01/70 00:00 | |
Have you considered PLM2C? | 01/01/70 00:00 | |
A good point - often missed | 01/01/70 00:00 | |
So what's the downside? | 01/01/70 00:00 | |
Complex code - Libraries | 01/01/70 00:00 | |
COTS libraries versus inhouse libraries | 01/01/70 00:00 | |
Hence portability is not such a big issue! | 01/01/70 00:00 | |
There are downsides | 01/01/70 00:00 | |
Portability vs. Readability/Maintainability. | 01/01/70 00:00 | |
who gives a hoot about portability | 01/01/70 00:00 | |
Portable by BIOS | 01/01/70 00:00 | |
I give a hoot about portability | 01/01/70 00:00 | |
I am definitely not arguing against "code reuse" | 01/01/70 00:00 | |
HAL | 01/01/70 00:00 | |
Small and easy things that may make Your day | 01/01/70 00:00 | |
The developer is probably the biggest factor | 01/01/70 00:00 | |
I may take issue with this one... | 01/01/70 00:00 | |
general re 'portable code' | 01/01/70 00:00 |