Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C vs. C++: non-trivial designated initializers not supported

Reply
Thread Tools

C vs. C++: non-trivial designated initializers not supported

 
 
Balog Pal
Guest
Posts: n/a
 
      07-29-2010
"Francesco S. Carta" <(E-Mail Removed)>
>> 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.

The part I don't get is why providing initializer for all struct members
(either literally, or better yet using a macro) is so painful. Such tables
are routinely created using macros. (For those unfamiliar with embedded,
you start work by including a few hundred kByte header with half content
being #define... so using a few more hardly hurts


 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      07-30-2010
On Thu, 2010-07-29, Johannes Bauer wrote:
> Am 29.07.2010 20:56, schrieb Richard:
>> [Please do not mail me a copy of your followup]
>>
>> James Kanze <(E-Mail Removed)> spake the secret code
>> <(E-Mail Removed)> 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++?


The "deprecated variant" was, as far as I can tell a GCC extension to
the C language, not something that was ever part of the language. The
manual says it's obsolete since GCC 2.5 -- i.e. a really long time
ago.

I seem to recall the Linux kernel using 'FIELDNAME: value' at one point,
later switching to '.FIELDNAME = value'.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Johannes Bauer
Guest
Posts: n/a
 
      07-30-2010
Am 30.07.2010 00:09, schrieb Balog Pal:

> The part I don't get is why providing initializer for all struct members
> (either literally, or better yet using a macro) is so painful.


Image you have 150 ISRs. You occupy only 3 of them, #17, #99 and #130.

This means you have to write

0, (16 times)
FirstISR,
0, (81 times)
SecondISR,
0, (30 times)
ThirdISR,
0, (20 times)

Calculating these numbers by oneself is incredibly error-prone. Even
worse: If you're off-by-one (as I actually was when I first wrote these
lines) you will not get any error, but it will rain crap during runtime.

It is much less error prone to write:

..USART_RXC = FirstISR,
..Ethernet_RXC = SecondISR,
..ExternalIRQ = ThirdISR

and not have to worry about the actual positions.

Furthermore, say you insert one beween #2 and #3 (say at 104). Then you
have to split the "0, (30 times)" up (into 4 + 25) which is even more
error-prone.

> Such
> tables are routinely created using macros. (For those unfamiliar
> with embedded, you start work by including a few hundred kByte header
> with half content being #define... so using a few more hardly hurts


If you knew a way to do this with macros, I'd be fine with it. However
nobody here has come up with a solution to make this problem work with
C++ (either using macros or not). I start to believe there may be no way
to solve that using C++ (which is IMHO, a pity, considering that C can
do it with ease).

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$(E-Mail Removed)>
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      07-30-2010
Johannes Bauer <(E-Mail Removed)>, on 30/07/2010 17:06:48, wrote:

> Am 30.07.2010 00:09, schrieb Balog Pal:
>
>> The part I don't get is why providing initializer for all struct members
>> (either literally, or better yet using a macro) is so painful.

>
> Image you have 150 ISRs. You occupy only 3 of them, #17, #99 and #130.
>
> This means you have to write
>
> 0, (16 times)
> FirstISR,
> 0, (81 times)
> SecondISR,
> 0, (30 times)
> ThirdISR,
> 0, (20 times)
>
> Calculating these numbers by oneself is incredibly error-prone. Even
> worse: If you're off-by-one (as I actually was when I first wrote these
> lines) you will not get any error, but it will rain crap during runtime.
>
> It is much less error prone to write:
>
> .USART_RXC = FirstISR,
> .Ethernet_RXC = SecondISR,
> .ExternalIRQ = ThirdISR
>
> and not have to worry about the actual positions.
>
> Furthermore, say you insert one beween #2 and #3 (say at 104). Then you
> have to split the "0, (30 times)" up (into 4 + 25) which is even more
> error-prone.
>
>> Such
>> tables are routinely created using macros. (For those unfamiliar
>> with embedded, you start work by including a few hundred kByte header
>> with half content being #define... so using a few more hardly hurts

>
> If you knew a way to do this with macros, I'd be fine with it. However
> nobody here has come up with a solution to make this problem work with
> C++ (either using macros or not). I start to believe there may be no way
> to solve that using C++ (which is IMHO, a pity, considering that C can
> do it with ease).


If plain source code size is not a problem, you can do:

PODObject pod = {
0, // #0 member name
0, // #1 member name
0, // #2 member name
// ...
0 // #149 member name
}

And set just what you need wherever you need it, in this way you can be
sure you won't mess up the list.

Otherwise, if you think you can get the number of intervening unused
members right, you can create macros like this:

#define Z_5 0, 0, 0, 0, 0
#define Z_10 Z_5, Z_5
#define Z_20 Z_10, Z_10
#define Z_25 Z_20, Z_5
#define Z_50 Z_25, Z_25
#define Z_100 Z_50, Z_50

and use them like this:

PODObject pod = {
Z_50, Z_20,
42,
Z_10, 0, 0,
78
}

I know, it's ugly and hard to maintain, but it's better than writing and
counting zeroes by hand, and personally I would really use the complete
(commented) initialization list I mentioned above, seen that I found no
better C++ solution in the context at hand.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      07-30-2010
[Please do not mail me a copy of your followup]

Johannes Bauer <(E-Mail Removed)> spake the secret code
<(E-Mail Removed)> thusly:

>If you knew a way to do this with macros, I'd be fine with it.


I don't understand the difficulty here. I'd write a macro that takes
the non-zero elements of the initializer and supplies all the zero
elements. Its really not that hard:

#define INITIALIZE(first_, second_, third_) \
{ \
first_, 0, 0, 0, 0, \
second_, 0, 0, 0, 0, \
third_ \
}

etc.

HugeStruct s = INITIALIZE(10, 20, 30);

I've done this before when initializing structs with huge initializer
lists; its really no big deal.

I believe that any unspecified initializers at the end of the list will
automatically be filled with zero, so there's no need to specify them
explicitly.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-31-2010
On Jul 30, 4:06 pm, Johannes Bauer <(E-Mail Removed)> wrote:
> Am 30.07.2010 00:09, schrieb Balog Pal:


> > The part I don't get is why providing initializer for all struct members
> > (either literally, or better yet using a macro) is so painful.


> Image you have 150 ISRs. You occupy only 3 of them, #17, #99 and #130.


> This means you have to write


> 0, (16 times)
> FirstISR,
> 0, (81 times)
> SecondISR,
> 0, (30 times)
> ThirdISR,
> 0, (20 times)


> Calculating these numbers by oneself is incredibly
> error-prone. Even worse: If you're off-by-one (as I actually
> was when I first wrote these lines) you will not get any
> error, but it will rain crap during runtime.


While I do think that adding the designated initializer syntax
to C++ would have been useful, in this particular case, I don't
see any real problem. It would take less than ten minutes to
write a small script in AWK which generates the full initializer
list, given the structure definition (supposing it is formatted
according to some established convention) and a list of the
concerned elements with their initializer.

--
James Kanze
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why Microsoft doesn't support designated initializers? ericnoonan C Programming 0 11-10-2009 07:56 AM
switches, spanning tree question regarding designated ports and switches alefveld@versatel.nl Cisco 1 12-30-2008 01:24 AM
A problem with designated initializers Ark C Programming 1 09-14-2006 05:41 AM
restrict from designated MAC address fangyong.F@gmail.com Cisco 0 01-12-2006 04:58 AM
Designated struct initializers with Visual C++ Roland Dreier C Programming 3 09-14-2003 09:45 AM



Advertisments