is this possible

I would strongly recommend putting this stuff in three different files instead.

If you really want to keep on putting all these in a single file, you'll have to encapsulate statements, not blocks or lines:

--- a.c ---
#define TYPE_A(x) x
#define TYPE_B(x) /* nothing */
#define TYPE_C(x) /* nothing */
#include "abc.c"

You know that CodeWright can hide code that's inactivated by #if...?

I would strongly recommend putting this stuff in three different files instead
Already done where practical.

Erik

You know that CodeWright can hide code that's inactivated by #if...?

I do, but never figured out how to make it work when the file with #define TYPEA is in the same subdirectory as the file with #define TYPEB and neither #defines are in the file being looked at.

Erik

you'll have to encapsulate statements, not blocks or lines:

--- a.c ---
#define TYPE_A(x) x
#define TYPE_B(x) /* nothing */
#define TYPE_C(x) /* nothing */

That one I do not understand

How about something like:

#if ATYPE
#define ATYPE
#define BTYPE  if (0)
#define CTYPE  if (0)
#endif


ATYPE
    {
    code;
    goes;
    here;
    }

BTYPE
    {
    other;
    code;
    here;
    }

CTYPE
    {
    less;
    code;
    }

The optimizer should take out the dead code. The brackets help make it very clear where the extent of the variant code lies. You can also nest blocks inside of them without worries about comment styles.

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 :)

Erik

That one I do not understand

Strange, given it does exactly what you tried to achieve, just differently enough to get it to work. You wanted to write

TYPEA  code for a;
TYPEB  code for variant b;
TYPEC  code vor variant c;

The macros I've shown allow to do that, but you'll have to spell it a bit differently:

TYPEA(code for a);
TYPEB(code for variant b);
TYPEC(code vor variant c);

and this syntax will pose some constraints on what you can write as "code for ...".

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.

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.

I guess the extra parentheses would be confoosing, i will write a few lines and judge

thanx

Erik

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)

"I would strongly recommend putting this stuff in three different files instead"

"Already done where practical." One idea I have depends on why the separate files are impractical. Could you elaborate, please?

"Already done where practical." One idea I have depends on why the separate files are impractical. Could you elaborate, please?

I have modules that are, say, 80% different fron group a to groupb to groupn and those are in separate modules that the .bat make select based on which of the 47 versions is to be build.

for modules that are, say, 20% different and have very many flavors, maintaining the common code in that many modules would be extremely impractical.

To the greatest extent possible where the difference is, say, a function, that function have been separated out.

The issues where the original query relate are where you have, say a function that is 93% the same, but in minor details is different.

This all relates to a) an inherited project which was a total mess, but now with some use of macros etc i quite a bit cleaner and b) to my new design wher the 'mess' is geatly reduced, but everything can be improved on.

Thanks for the interest

Erik

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.

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

Erik