We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
It happened again.
I have many cases of modules with something like #ifdef TYPEA ... many lines #endif #ifdef TYPEB ... many similar lines #endif #ifdef TYPEC ... many similar lines #endif
It happens that I am looking at the type b code trying to figure out something in type a (the codes are VERY similar).
To avoid this, I have tried
blah,blah // comment TYPEA
and that "kind of works"
Now, the ideal would be if for type a I could do the following: #ifdef TYPEA #define ATYPE #define BTYPE // #define CTYPE // #endif
and then just make it ATYPE blah,blah // comment
Of course this does not work. Does anyone have a trick that makes this possible?
Erik
what the optimizer does is irrelevant, that works just fine with #define. The issue is to find a means that, at the beinning of each line, identify the type when looking at it in CodeWright.
so, instead of #ifdef TYPEA aline1 aline2 aline3 ... #endif #ifdef TYPEB bline1 bline2 bline3 .... #endif
it would look like this TYPEA aline1 TYPEA aline2 TYPEA aline3 .... TYPEB bline1 TYPEB bline2 TYPEB bline3 ....
just dreaming, I know, but sometimes a dream can come true :)
If you do it the way you want, you'll confuse CodeWright no end --- it'll lose track of the C syntax of your code. You'll basically lose most of the advantage a programmers' editor has over Notepad.
You may want to reconsider whether you really have to edit the same file that the compiler will get to see. The C preprocessor is not the be-all and end-all of on-the-fly source code manipulation. You could preprocess a single ".cin" file with Perl or similar tools to generate multiple .c files and feed only those to the compiler.
and feed only those to the compiler.
The problem is when I look at the code in the editor, it is almost never clear which group of code I am looking at.
My code generate 47 different builds and maintaining them as separate 'projects' would never work (a fix to the common code implemented in 46 and missed in one)
That much was clear from the beginning.
You don't seem to grasp what I'm suggesting, though. My proposal is to avoid this gotcha by not having the actual C code to look at. And the method of doing that is to provide C source only while it's being fed to the compiler: create a C file for variant A from the common, not-quite-C code file, compile it, and if the compile went well, delete the temp file. Then do the same for variant B.
The benefit is that instead of C preprocessor macros, you can use whatever syntax you like to indicate what platform any file is for, as long as you have a tool that can translate it to C. You could even actually have your "combined C file" look like your original idea. A simple little 'sed' script could decode that. In pseudo-shell syntax:
sed -e '/^TYPE[^A]/d' module.cin' | c51
You don't seem to grasp what I'm suggesting, though. My proposal is to avoid this gotcha by not having the actual C code to look at. And the method of doing that is to provide C source only while it's being fed to the compiler: create a C file for variant A from the common, not-quite-C code file, compile it, and if the compile went well, delete the temp file. Then do the same for variant B through m.
That process is waaaaay to likely to miss one variant, I have, believe me, tried it and failed.
To do so, you have to rely on the so called "testing" and that would be a true disater.
The suggestion, although dismissed, is still appreacited, Thanks
The same would seem to be true with a C-preprocessor-based solution. You still have to compile versions A, B, and C, even to make sure that the syntax is correct given the three #defines. Since you have three images, you really need to test all three to be certain that they all work. You might be able to use knowledge of the variant areas of the code to limit the scope of the variant testing.
But whether you use m4 or the preprocessor or an array of little gnomes to alter a text file, you have three different inputs to the compiler proper.
the problem with "after preprocesor/after compile/after ..."s that you do not "see what you want to modify" (the common source) just "see where you want to modify" which is OK (to some extent) when only one of the variants is to be possible, the problem is that you do not - initially - know if what you are looking for is in a variant of something common. So, according to Murphy, you will use the "after" method and find soemthing you want to see "before" and, again according to Murphy, you will use the "before" method and find soemthing you want to see "after". Oh well, just a faint hope.
Thanks to all,