Why are there so many nested definitions

[fl]

Hi,

I once read someone's code. That experienced programmer used a nested definition of simple integer. Now, I obtain a source code from Matlab Simulink Coder, see below please. It is in the same fashion.

For the integer "Out", why they define a struct here?

Could you explain it to me? Thanks.



...............
typedef struct {
int32_T Out; /* '<Root>/Out' */
} ExternalOutputs_Hcic1;

 

[Andrew Cooper]

Hi,

I once read someone's code. That experienced programmer used a nested definition of simple integer. Now, I obtain a source code from Matlab Simulink Coder, see below please. It is in the same fashion.

For the integer "Out", why they define a struct here?

Could you explain it to me? Thanks.



..............
typedef struct {
int32_T Out; /* '<Root>/Out' */
} ExternalOutputs_Hcic1;

I cant really explain what the above is trying to do, but we the same
technique for memory management code in Xen.

With page table management, and guests VMs with different memory
management models[1], it is very easy to get one "type" of unsigned long
mixed up with a different "type" of unsigned long.

As a result, we have hidden one of the many types of memory address in a
structure like this, and provided token accesser methods.

The result is more work for the compiler (although identical compiled
output), and a helpful error from the compiler when you accidentally mix
one type with another, as opposed to a subtle memory corruption bug.

[1] Depending on your type of guest, you can choose between PV,
Autotranslate, HAP (EPT/NPT), Shadow and now nested HAP). It leads to
interesting code internally.

~Andrew

 

[Ben Bacarisse]

For the integer "Out", why they define a struct here?

Could you explain it to me? Thanks.

typedef struct {
int32_T Out; /* '<Root>/Out' */
} ExternalOutputs_Hcic1;

It's almost certainly to get some more type checking form the compiler.

Arithmetic types freely convert from one to another in C, so you can
assign a float to a char, or pass long double to function that expects
an int. But every struct is different (It's is a little more complex
than for structs in separate compilation units, but let's put that to
one side for now) so even if ExternalInputs_Hcic1 were to be declared to
contain only one int32_t, you would get an error trying to pass one to a
function that expected an ExternalOutputs_Hcic1.

 

[Heikki Kallasjoki]

It's almost certainly to get some more type checking form the compiler.

Given the situation -- C code automatically generated from a Simulink
model, which can have multiple outputs -- I'd think the major reason is
likely to be simple consistency: all the outputs of the model are
grouped in one structure type, no matter whether there were one or
several of them.

 

[Ben Bacarisse]

Given the situation -- C code automatically generated from a Simulink
model, which can have multiple outputs -- I'd think the major reason is
likely to be simple consistency: all the outputs of the model are
grouped in one structure type, no matter whether there were one or
several of them.

Yes, that sound quite probable. I did not know that the code was
generated -- the reference to an "experienced programmer" led me astray.

 

[Jorgen Grahn]

Yes, that sound quite probable. I did not know that the code was
generated -- the reference to an "experienced programmer" led me astray.

Not quite astray -- the OP seemed to mention two times he had seen
this (in code from "an experienced programmer" and in generated code)
and asked a general question.

FWIW, when you see it in /my/ code it's like BB says: to get better
type safety -- so an ExternalOutputs_Hcic1 cannot be confused with
random integer variables.

Part of the reason I do it is my C++ background. This wrapping is
even *more* useful there.

/Jorgen