From: doug s. <hig...@ho...> - 2011-05-29 14:29:45
|
> > 1. by source file - easy to do in a single sitting. ie browser.component_networking.something > - Programmer doesn't have to think hard or know the system, yet still preserves some information about the variable namely what source file it came from > > If I had to decide quick, I think #1 is good as something that can be implemented in one shot/one day or weekend because it doesn't require much thinking or research by the programmer. Then refactoring/grooming/code aesthetics/class design could be done in bite size projects afterward. > JOhn, update Sunday 8:25 am I'm not sure yet what to make of it. Technically it's working in small tests (I did 2 source files worth of statics. not checked in. On code checked out Saturday morning.) To get what was originally just initialized it looks like: gglobal()->internal.initialized that gglobal() can work 2 ways/2 configurations: - for lightweight single-instance applications it can get a static global struct - for multi-instance -like multiple ActiveX on a web page- it can do your thread lookup The catch/drawback: there are maybe 600 static variables to do, and if they all have to do a thread lookup table each time, that doesn't sound computer efficient. And the code looks noisy. One idea is to 'perculate up' a bit, so at the top of a big function: tinternal *internal = &gglobal()->internal; then throughout the function: internal.varA = something something = internal.varB And for small functions, the parent/calling function, if bigger, could get the sub-struct and pass it in. And so on so it's perculating up I supposed to where the thread starts, or just inside Daves fwl_ interface. The sub-structs I'm using are just the source file name ie for display.c I use global()->display. But inside a .c there might be more than one implied/natural class so there might be a better way to sub-struct. The perculating and sub-struct refactoring could be done as I make changes/implement, or in subsequent phases. I'll try some more and see if I can find some problems/issues. One I'm anticipating, but haven't felt yet: #include (almostEverythingExceptGlobal.h) #include (global.h) And when you combine those two you get (all.h) Because the global could be holding almost anything, and in one place, all types of data -not just scalars- could be in global, so in general it would need all the #includes above it. And I don't know if there's a zone of code where it's going to be a problem to #include (all.h). -Doug |