Importing #define FOO (bar) in C

[fwoolz]

It seems that define statements with parentheses are imported as methods rather than attributes when C files are imported. For example,

Code: [Select]

#define MIN_CA_ENGINE_RPM    (700)
winds up being imported as

Code: [Select]

void MIN_CA_ENGINE_RPM(700)
with a tagged value define = true!

All #define statements should be imported as attributes (if that option is turned on for code generation).

Bug report is being filed...

Cheers,
Fred W

[Eve]

That's certainly an error, but I disagree that all #defines should be imported as attributes.

What about this one?

Code: [Select]

#define min(X, Y)  ((X) < (Y) ? (X) : (Y))

[fwoolz]

Point taken, but that raises another point: how would EA import the example you noted? Does it import it as an operation and then use the "define" tag to know it's really a macro so that it can round-trip the code successfully? If so, the error I noted wouldn't be a problem if code generation is all you care about. But some of us (like me) also use EA to generate documentation of existing software for clients, and identifying a #define with a constant "argument" in parentheses as a C function is, as you noted, an error. And EA doesn't do this with all such #defines - the following example is not imported as an operation:

Code: [Select]

#define TCU_IN_TORQUE_INVERTER_1_FEEDBACK_LDTNDX        ( TCU_BASE_LDTNDX +  16 )
This imports as an attribute, i.e.

Code: [Select]

static const <no type> TCU_IN_TORQUE_INVERTER_1_FEEDBACK_LDTNDX = ( TCU_BASE_LDTNDX +  16 )
Why the inconsistency?

If attributes were allowed to have "illegal" names (for #define only, perhaps - but why not for everything?), then there's no reason why you couldn't have an attribute

Code: [Select]

static const <no type> MIN(X, Y) = ((X) < (Y) ? (X) : (Y))
There's an option for ignoring spaces (and other illegal characters) in class names; why not a similar option for class member names?

To sum up, importing a #define like

Code: [Select]

#define MIN(X, Y)    ((X) < (Y) ? (X) : (Y))
as an operation may work as a trick for code round-tripping, but it's bad news for code documentation. The resulting model is just wrong.

Cheers,
Fred W

[Eve]

The reason for the difference is that your original example matches the pattern for being treated as an operation.  The second doesn't because of the more complicated expression.

EA would import it exactly as your sample was imported.  As a function.  But I don't think this is a trick for code round-tripping.  As far as I'm concerned it is an operation although it's implemented differently.  It still meets my definition of an operation. If I was designing the C importer (or had a time machine and no qualms about using it) I would have gave it a stereotype of define instead of a tagged value to reflect the fundamental difference.

[fwoolz]

Whereas I would consider #defines to be attributes, since they are most frequently (in the code I encounter, at least) used to define constants, not macro equivalents of inline functions. Additionally, the EA dialog for C code import settings refers to imported #define constants as "attributes" (and says nothing about operations, although I do take note of the word "constants"). In the same sense that

Code: [Select]

const int a = 1 means you can substitute 1 for a everywhere it occurs (within scope),

Code: [Select]

#define min(X, Y)  ((X) < (Y) ? (X) : (Y)) means "substitute the RHS wherever you see the LHS" (albeit with the function-like addition of macro parameter substitution).

I guess the real problem is that macros don't fit neatly into the object-oriented paradigm... and I agree that a stereotype would be better than an often-invisible tagged value.

In the meantime, it would be good to have #define FOO (700) imported as static const <int?> FOO = 700.

Cheers,
Fred W

[Eve]

In the meantime, it would be good to have #define FOO (700) imported as static const <int?> FOO = 700.

Absolutely, I consider it a bug that it isn't.

[fwoolz]

Top man!