«

[Please do not mail me a copy of your followup]

Johannes Bauer <> spake the secret code
<> thusly:

>Am 29.07.2010 19:08, schrieb Richard:
>> [Please do not mail me a copy of your followup]
>>
>> Johannes Bauer <> spake the secret code
>> <> thusly:
>>
>>> PODObject vectorTable = {
>>> FunctionValue: MyFunctionImpl,
>>> };
>>
>> I don't know what this is, but its not syntactically valid C or C++.
>
>Are you sure?

No. That's why I said I don't know what it is. To me it looks like a
label declaration in the middle of an aggregate initializer, which is
why I didn't think it was syntactically valid C or C++.

I didn't know about designated initializers in C99. I have been using
C++ since 1990 and haven't been following C standardization beyond
that time.

So, it turns out that for (some flavors) of C, its syntactically
valid. However, I don't see anything that indicates its ever
syntactically valid C++.

At any rate, I don't see the value added here.

From looking at other posts and [1], even the syntax used here is
wrong. So its not even syntactically valid C99.

[1]
http://publib.boulder.ibm.com/infoce...esignators.htm
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Jul 29, 6:08 pm, legalize+jee...@mail.xmission.com (Richard) wrote:

> Johannes Bauer <dfnsonfsdu...@gmx.de> spake the secret code
> <8bdq8oFns...@mid.dfncis.de> thusly:

> >PODObject vectorTable = {
> > FunctionValue: MyFunctionImpl,
> >};

> I don't know what this is, but its not syntactically valid C or C++.

It's valid C99. C++ is based on C90 (but the next version
didn't adopt this from C either---I don't know why not).

--
James Kanze

[Please do not mail me a copy of your followup]

James Kanze <> spake the secret code
<54fc6600-1c5e-4dd6-8415-> thusly:

>> >PODObject vectorTable = {
>> > FunctionValue: MyFunctionImpl,
>> >};
>
>> I don't know what this is, but its not syntactically valid C or C++.
>
>It's valid C99.

Apparently not. The syntax is .member = initializer, not
member: initializer.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Am 29.07.2010 19:53, schrieb Andrey Tarasevich:
> Johannes Bauer wrote:
>>
>> Well, actually the point of it all was that not all fields need to be
>> specified. The actual vectorTable contains >150 entries of which only
>> about 10 will be filled usually. The point of the whole construct was so
>> the unused fields can be omitted.
>
> If this is a _maintenance_ issue, then the way to do it portably is to
> define the struct object without any initializer at all and then use
> _assignment_ to set some specific fields.

This is not possible. The code is part of a IVT and therefore needs to
be laid out by the compiler to contain the function addresses of the ISRs.

> If this is a _performance_ issue, the initializers will not help you
> here, since in C (and in similar context in C++), initializing just one
> field of the struct automatically triggers zero-initialization for _all_
> fields of the struct. I.e. if you want to leave all other fields
> uninitialized (for performance reasons), the way to go is again to
> define the struct object without any initializer at all and then use
> assignment to set some specific fields.

No, see above.

>> No, initialized data is fine (viewing initialized data as a subset of
>> uninitialized data). Anything which was omitted may well be set to 0 or
>> 0xffffffff or whatever the compiler likes - if it only would allow me to
>> omit it (like the C compiler does).
>
> Like _C99_ compiler does. If you want your code to be portable across
> C89/90, C99 and C++ you have no other choice but to use either "no
> initializer+assignment" approach or "supply all initializers beginning
> from the first" approach.

Well, that's no real nice solution. The struct has around 150 actual ISR
handlers and I want to set some specific ones without having to know
where they all need to be placed in memory.

Regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

Am 29.07.2010 19:38, schrieb Jonathan Lee:
> On Jul 29, 1:20 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
>> Well, actually the point of it all was that not all fields need to be
>> specified. The actual vectorTable contains >150 entries of which only
>> about 10 will be filled usually.
>
> Ouch. Er... in that case I guess you'd have to declare the variable
> without an initializer (or rely on zero initialization) and then set
> them one by one.
>
> I don't really have a better solution than that. (Other than, you know
> 140+ unused fields sounds like a struct that wants to be rewritten...)

:-/

That seems to suck, is there really no other way? I cannot change the
initializers at runtime as the struct needs to be laid out in advance
and is placed in ROM (actually Flash, but ROM for that purpose).

Maybe I'll just use C-code for that part (with the correct ".foo = bar"
syntax of course) and mix the two languages. I'd really like to have
done it all in C++, though.

Regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

Am 29.07.2010 20:56, schrieb Richard:
> [Please do not mail me a copy of your followup]
>
> James Kanze <> spake the secret code
> <54fc6600-1c5e-4dd6-8415-> thusly:
>
>>>> PODObject vectorTable = {
>>>> FunctionValue: MyFunctionImpl,
>>>> };
>>
>>> I don't know what this is, but its not syntactically valid C or C++.
>>
>> It's valid C99.
>
> Apparently not. The syntax is .member = initializer, not
> member: initializer.

Yes, I used the deprecated variant. Is there anything like this in C++?

Kind regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

Am 29.07.2010 19:45, schrieb Andrey Tarasevich:
> Johannes Bauer wrote:
>>
>> I know this might be an implementation detail - however I do not
>> understand why the languages C++ and C are different in the following
>> example - I'm quite stunned and am looking for an explanation.
>
> C++ language does not have "designated initializers", neither trivial
> nor non-trivial. The same applies to C89/90 version of C language. If
> you only care to initialize one specific field with an aggregate
> initializer, you have to supply _all_ initializers, beginning form the
> first, until you reach the field in question. The rest of the
> initializers can be omitted (meaning that the rest of the struct will be
> implicitly zero-initialized).
>
>>
>> PODObject vectorTable = {
>> FunctionValue: MyFunctionImpl,
>> };
>
> "Designated initializers" is a feature of C99 version of C language and
> the proper syntax is as follows
>
> PODObject vectorTable = { .FunctionValue = MyFunctionImpl };
>
>> I have three options to make the code compile even when using C++:
>> 1. Comment out the void* declaration of the PODObject
>
> ??? It is not clear what you mean here.

When I leave out the member "PointerValue" from the struct, it works
(since all are initialized then).

>> 2. Change the order or PointerValue and FunctionValue
>
> Well, as a way to make your code shorter, it will work (see below)

Well, it's not possible to change the order in my case (since the layout
of the struct is determined by hardware, not by me).

>> 3. Define PointerValue in the struct definition
>
> ??? It is not clear what you mean here.

If I define PointerValue, like say to 0...

> You have the 4th way: just do it the way it has been done for ages,
> without any "designated initializers". Just supply all preceding
> initializers explicitly
>
> PODObject vectorTable = { 0, MyFunctionImpl };

....like you did here, then it also works. However, I really do not want
to have to use NULL 140 times and know exactly at what positions I need
to fill the proper ISR function pointers.

> Your 2nd approach is just a way to get rid of that explicit leading 0.
>
>> However, none of these options are really applicable in this particular
>> case. Is there a possibility or workaround or completely different
>> approach which lets me do the same thing as C does (i.e. fill the
>> undefined struct values with some random undefined data)?
>
> "Undefined struct values" do not get filled with "random undefined
> data". C language follows all-or-noting approach to initialization. If
> you initialize just some of the struct fields (regardless of whether you
> use designated initializers or not), the rest gets implicitly zero
> initialized for you.

What I meant was: It could even be filled with random data. I do not
rely on it being initialized to anything, as the data is never read
during runtime.

Regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>

On Jul 29, 4:47*pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
> Am 29.07.2010 19:38, schrieb Jonathan Lee:
>
> > Ouch. Er... in that case I guess you'd have to declare the variable
> > without an initializer (or rely on zero initialization) and then set
> > them one by one.
>
> :-/
>
> That seems to suck, is there really no other way? I cannot change the
> initializers at runtime as the struct needs to be laid out in advance
> and is placed in ROM (actually Flash, but ROM for that purpose).

The only other thing I can think of is to simply do this stuff in C
source and build that part of the tree with the C compiler :/

--Jonathan

Johannes Bauer <>, on 29/07/2010 22:46:15, wrote:

> Am 29.07.2010 19:53, schrieb Andrey Tarasevich:
>> Johannes Bauer wrote:
>>> No, initialized data is fine (viewing initialized data as a subset of
>>> uninitialized data). Anything which was omitted may well be set to 0 or
>>> 0xffffffff or whatever the compiler likes - if it only would allow me to
>>> omit it (like the C compiler does).
>>
>> Like _C99_ compiler does. If you want your code to be portable across
>> C89/90, C99 and C++ you have no other choice but to use either "no
>> initializer+assignment" approach or "supply all initializers beginning
>> from the first" approach.
>
> Well, that's no real nice solution. The struct has around 150 actual ISR
> handlers and I want to set some specific ones without having to know
> where they all need to be placed in memory.

What is so ugly with the "no initialized + assignment" approach
suggested by Andrey?

This chunk of code isn't all that hard to type or to review, is valid
everywhere (within the context at hand) and, IIUIC, should also be
faster than the C99 version mentioned in the OP:

//-------
PODObject obj;
obj.FunctionValue = MyFunctionImpl;
//-------


And if one really wants a one-liner, one can always take advantage
(grin) of the preprocessor:

//-------
#define CREATEPOD(obj_name, member_name, value) \
PODObject obj_name; \
obj_name.member_name = value;

typedef void(*FunctionType)();

struct PODObject {
void* PointerValue;
FunctionType FunctionValue;
};

void MyFunctionImpl() {}

int main() {
CREATEPOD(obj, FunctionValue, MyFunctionImpl);
obj.FunctionValue();
}
//-------

For the records, I wouldn't use macros, I would just use the two lines I
mentioned first.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com

Balog Pal <>, on 30/07/2010 00:09:21, wrote:

> "Francesco S. Carta" <>
>>> Well, that's no real nice solution. The struct has around 150 actual ISR
>>> handlers and I want to set some specific ones without having to know
>>> where they all need to be placed in memory.
>>
>> What is so ugly with the "no initialized + assignment" approach
>> suggested by Andrey?
>
> As Johannes stated in the part you cut out, that stuff goes to a const
> segment sitting in ROM, so assignment does not play, only static init.

Sorry, I overlooked that part.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com