lcc.niket@UCLA-LOCUS.ARPA (Niket K. Patwardhan) (07/18/85)
Date: Mon, 15 Jul 85 12:33:31 PDT From: Niket K. Patwardhan <niket> To: info-c Subject: C standard on initialization. I would like this to get transferred to the C standards group as well as see comments on this proposal. It has always seemed to me extremely lame that C has no way of specifying that a particular value is to be repeated N times, without actually typing out the value N times. Although the draft standard permits initialization of sub-aggregates via some pretty fancy grouping, it still says nothing about duplicated values. The only practical way of initializing a large data structure to something other than all NULLs is to actually write some code to do it. What I would like to see is this <initializer> ::= <assignment-expression> { <initializer-list> } <constant-expression> { <initializer-list> } { <initializer-list>, } If the grammar is too hard to parse, or too unnatural, the constant expression can follow the initializer list in braces. The semantics is as follows: constant-expression has to evaluate to a positive integer. <constant-expression> { <initializer-list> } is equivalent to { <initializer-list> } , { <initializer-list> } , ...... the right number of times. or { <initializer-list>, <initializer-list>,....... } or some variation thereof. On second thought the post-fix constant seems more natural, it having been often used in documentation with the constant being a superscript. I would consider a scheme that allowed a single constant to be repeated insufficient. It is necessary that patterns can be specified as occurring N times.
ALMQUIST@SU-SCORE.ARPA (Philip Almquist) (07/19/85)
An alternative which would accomplish the end would be to
add a repetition construct to the preprocessor. An example, using
one possible syntax, is:
int foobar[FOOSIZE] = {
1,
2,
3
# repeat FOOSIZE - 3
,27
# endrepeat
}
I believe that such a preprocessor directive would have the following
advantages over the (very reasonable) scheme that you proposed:
- It also handles repetition in other cases where it can be useful,
such as loop unrolling.
- Macro processors tend to be easier to change than compilers.
- Although I didn't think about it hard enough to be sure, I think
that there are cases in your syntax where the accidental insertion
or deletion of a comma could change the meaning of the initializer
radically without causing any sort of compile-time error. Since
commas naturally abound in initializers such an error might be
hard to spot. Although such pitfalls abound in C it would be
nice to avoid adding another one.
Philip Almquist
-------
bright@dataio.UUCP (Walter Bright) (07/22/85)
In article <5@brl-tgr.ARPA> ALMQUIST@SU-SCORE.ARPA (Philip Almquist) writes: > An alternative which would accomplish the end would be to >add a repetition construct to the preprocessor. An example, using >one possible syntax, is: > int foobar[FOOSIZE] = {1,2,3 > # repeat FOOSIZE - 3 > ,27 > # endrepeat > } A good idea. But I would rather see the syntax be: int foobar[FOOSIZE] = {1,2,3 #repeat (FOOSIZE - 3) ,27 }; Most C preprocessors are already set up to handle text on the current line, not text on n lines. My scheme would be much easier to implement. The repeat count would have to be enclosed in parentheses in order to differentiate it from the repeated text. Large amounts of repeat text can be handled with a \ continuation character, just like in #defines.