Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > VLA question

Reply
Thread Tools

VLA question

 
 
Ian Collins
Guest
Posts: n/a
 
      06-16-2013
Tim Rentsch wrote:
> Stephen Sprunk <(E-Mail Removed)> writes:
>
>> On 15-Jun-13 15:49, Eric Sosman wrote:
>>> On 6/15/2013 3:49 PM, Stephen Sprunk wrote:
>>>> Without VLAs, array sizes are constrained to "constant integer
>>>> expressions". For some reason, a "const int" is not a "constant
>>>> integer expression", so using one as such would be a constraint
>>>> violation.
>>>> ...
>>>> The C-like subset of C++ does not have this defect, so it's
>>>> puzzling why later revisions of C itself have not fixed it. This
>>>> is simpler, for instance, than introducing VLAs in the first
>>>> place. [...]
>>>
>>> Simpler, well, maybe -- but some complications remain:
>>>
>>> const int n = 1 + rand() % 53; int v[n];
>>>
>>> Just knowing that `n' is `const' is not enough; one must also
>>> remember things about its initializer.

>>
>> Surely the compiler would know whether n's value was known or not. An
>> unknown value would only be allowed if VLAs were supported.
>>
>>> One can write rules to deal with such things -- C++ has such rules --
>>> but the very existence of the rules shows that "simpler" is a bit
>>> more complex than "dead easy."

>>
>> Fair enough. However, I think it's a reasonable to expect this to be
>> fixed by now, especially given the C-like subset of C++ did so long ago.
>> [snip]

>
> This assumes that other people agree that it's a problem, and
> obviously they don't. What are the benefits, and what makes
> them worth the costs? Unless and until someone presents a
> compelling argument on this question, it's unlikely that C
> will adopt such a change. And rightly so.


One could argue that VLAs are the cost of not making this simple and
long overdue change. The archaic kludges (textual substitution, abuse
of enums) used as a work around the lack of proper const are yet another
cost we have to bear.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      06-16-2013
On Sunday, 16 June 2013 23:43:49 UTC+3, Ian Collins wrote:
> Tim Rentsch wrote:
> > Stephen Sprunk <(E-Mail Removed)> writes:
> >> On 15-Jun-13 15:49, Eric Sosman wrote:
> >>> One can write rules to deal with such things -- C++ has such rules --
> >>> but the very existence of the rules shows that "simpler" is a bit
> >>> more complex than "dead easy."
> >>
> >> Fair enough. However, I think it's a reasonable to expect this to be
> >> fixed by now, especially given the C-like subset of C++ did so long ago.
> >> [snip]

> >
> > This assumes that other people agree that it's a problem, and
> > obviously they don't. What are the benefits, and what makes
> > them worth the costs? Unless and until someone presents a
> > compelling argument on this question, it's unlikely that C
> > will adopt such a change. And rightly so.

>
> One could argue that VLAs are the cost of not making this simple and
> long overdue change. The archaic kludges (textual substitution, abuse
> of enums) used as a work around the lack of proper const are yet another
> cost we have to bear.


The dual meaning of 'const' in C++ is sometimes confusing to some.
'constexpr' was introduced to make it possible to differentiate
"compile-time constants" from "immutable objects". C might likely win
if it keeps 'const' like it is (better than in C++ IMO) and loans
'constexpr' to get rid of those enum and preprocessor workarounds.
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      06-16-2013
On 06/16/2013 06:44 PM, william@wilbur.25thandClement.com wrote:
....
> I thought VLAs were part of the package of features for Fortran emigres.
> They don't make much sense outside of that context.


I think that they make handling mult-dimensional arrays with dimensions
that are not compile time constants a lot easier than it was in C90. I
think there's a lot of people other than Fortran emigres who would
appreciate that.
--
James Kuyper
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-17-2013
Ian Collins <(E-Mail Removed)> writes:
[...]
> One could argue that VLAs are the cost of not making this simple and
> long overdue change. The archaic kludges (textual substitution, abuse
> of enums) used as a work around the lack of proper const are yet another
> cost we have to bear.


I don't think one could argue that *persuasively*. VLAs were intended
to make it possible to define arrays whose length is determined at
execution time. The fact that they make

{
const int n = 5;
int vla[n];
}

legal is just a side effect, and probably an unintended one.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-21-2013
Ian Collins <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
>> Stephen Sprunk <(E-Mail Removed)> writes:
>>
>>> On 15-Jun-13 15:49, Eric Sosman wrote:
>>>> On 6/15/2013 3:49 PM, Stephen Sprunk wrote:
>>>>> Without VLAs, array sizes are constrained to "constant integer
>>>>> expressions". For some reason, a "const int" is not a "constant
>>>>> integer expression", so using one as such would be a constraint
>>>>> violation.
>>>>> ...
>>>>> The C-like subset of C++ does not have this defect, so it's
>>>>> puzzling why later revisions of C itself have not fixed it.
>>>>> This is simpler, for instance, than introducing VLAs in the
>>>>> first place. [...]
>>>>
>>>> Simpler, well, maybe -- but some complications remain:
>>>>
>>>> const int n = 1 + rand() % 53; int v[n];
>>>>
>>>> Just knowing that `n' is `const' is not enough; one must also
>>>> remember things about its initializer.
>>>
>>> Surely the compiler would know whether n's value was known or not.
>>> An unknown value would only be allowed if VLAs were supported.
>>>
>>>> One can write rules to deal with such things -- C++ has such
>>>> rules -- but the very existence of the rules shows that "simpler"
>>>> is a bit more complex than "dead easy."
>>>
>>> Fair enough. However, I think it's a reasonable to expect this to
>>> be fixed by now, especially given the C-like subset of C++ did so
>>> long ago. [snip]

>>
>> This assumes that other people agree that it's a problem, and
>> obviously they don't. What are the benefits, and what makes
>> them worth the costs? Unless and until someone presents a
>> compelling argument on this question, it's unlikely that C
>> will adopt such a change. And rightly so.

>
> One could argue that VLAs are the cost of not making this simple and
> long overdue change. The archaic kludges (textual substitution,
> abuse of enums) used as a work around the lack of proper const are
> yet another cost we have to bear.


If having VLAs is one of the consequences of not adopting the C++
rule allowing constant-expression-defined-variables in other
constant expressions, then IMO that consequence alone makes it
worth not including the C++ feature, even if there were no other
reasons favoring excluding it.

Ignoring that aspect (which I think was given not completely
seriously anyway), let's draw up a list of consequences, or
attributes, for each of the three approaches. This turns out to
be a bigger list than I was expecting:

#define enum 'const' variables
-------------------- -------------------- ---------------------
textual binding lexical binding lexical binding
no scoping regular scoping regular scoping
(or, scope may be
limited w/ #undef)

no reference as a no reference as a may be referenced
variable variable as a variable,
eg, address taken

uses preprocessor
works easily w/ -D=

arithmetic types only type int arithmetic types
(address values pointer types?
allowed, but using
textual binding)

individual values sets of values individual values
(allowing enhanced
type checking)

K&R C C90 (or before?) would need additional
language definition
(for C)

textual + semantic syntactic (ie, name semantic (ie, to know
(ie, whether value defined always may whether a variable can
may be used in a be used in constant be used as a constant,
constant expression expression) some semantic analysis
depends on both needed)
textual analysis and
semantic analysis)

no change to other no change to other interacts with other
language aspects language aspects language aspects
(based on my perhaps
flawed understanding
of the C++ feature)

same in C and C++ same in C and C++ present in C++,
(slightly different not present in C
semantics in the
two languages?)


Now on to (my own) subjective reactions.

Comparing #define and 'const' variables, the main plusses for
using #define are also its main minuses: it uses a simple,
long-known and well-understood mechanism, with all of the usual
warts associated with the preprocessor. Some people depolore
using the preprocessor on general principles and try to avoid it
pretty much at all costs, but I'm not in that camp. I know the
preprocessor has warts, but really they aren't that bad here for
just #define of simple constant expressions. Lack of lexically
scoped definitions is a drawback for #define; this is partially
fixable with #undef, which works sort of okay but definitely has
a high wart factor.

Looking at the flip side, 'const' variables don't have the warts
that using #define does: analysis is easier, and lexical scoping
is a plus. I'm not sure how important the scoping issue is; I
would want to look at a variety of code bases before assigning a
particular weight to that aspect. The big drawback of 'const'
variables is that adding them to C would mean a larger and more
complicated language definition. It's easy to underestimate the
impact of "little" changes like this. I recently went through
the exercise of reading the C++ language definition document (ie,
the C++ Standard, although not the most recently approved one).
Until doing that I didn't really appreciate just how large and
complicated C++ has become. How did it get that way? As the
saying goes, one feature at a time...

Another consideration: not having 'const' variables in C
increases the semantic gap between C and C++. I'm not sure if
the weight for this should be positive or negative, but in any
case the absolute value is small IMO.

Comparing using 'enum' and const variables is more interesting.
Relative to const variables, the biggest downside of defining
constants using 'enum' is that they are limited to values of type
int. (I know the syntac form is unappealing to some but to me
this seems like a minor issue.) Now look at the positives: we
know something defined in an enum can be used in a constant
expression; enum lets us define several related values that can
be identified together, eg, for checking the cases of 'switch()'
statements; a value defined in an enum is identified with a
particular type, which facilitates improved typed checking should
we want to do that.

Besides offering a larger range of types, const variables are
part of "ordinary" C, ie, the definitions look just like
executable C code. I don't think this is a big plus. In fact it
may not be a plus at all - compile time and execution time are
fundamentally different regimes, and making them look the same
may be more confusing than helpful. Using 'const' to define
compile time variables may be seen as a very limited form of
metaprogramming. It certainly isn't obvious that lowering
the boundary between programming and metaprogramming leads to
better programs. Clearly it is possible make them look the
same, but that doesn't mean it's desirable.

Bottom line: I stand by my original assessment -- until and
unless someone presents a compelling argument for introducing a
new language feature (for C) in this area, the language is better
left as is. (Note: for such an argument to be compelling, it
should include a statement of what use cases it means to address,
along with some sort of evidence that those use cases are
significant and substantial.) Furthermore, even assuming that
adopting a new language feature seems advisable, extending enums
in some way that would allow for greater type variability looks
like a better bet than adopting the const variable feature.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      06-21-2013
On Thursday 20 June 2013 20:00, in comp.lang.c, (E-Mail Removed)
wrote:
[snip]
> #define enum 'const' variables
> -------------------- -------------------- ---------------------

[snip]
>
> K&R C C90 (or before?) would need additional
> language definition
> (for C)


enum was documented in Nov 15, 1978 in an addendum to the K&R C manual,
entitled "Recent Changes to C".

While not strictly "K&R" C (i.e., not stated in "The C Programming Language"
(c) 197, it /did/ appear (along with K&R Appendix A "C Reference Manual")
in the Seventh Edition, Volume 2 Unix Programmers Manual (c) 1983, 1979.

So, enum /does/ predate C90, and postdates K&R by only a few months.

[snip]
--
Lew Pitcher
"In Skills, We Trust"
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      06-25-2013
On 20-Jun-13 19:00, Tim Rentsch wrote:
> Ignoring that aspect (which I think was given not completely
> seriously anyway), let's draw up a list of consequences, or
> attributes, for each of the three approaches. This turns out to
> be a bigger list than I was expecting:
> ...


A thorough and thoughtful analysis; I'm not sure I agree with you on
every point, but most of my disagreement would probably fall into how
each is weighted anyway.

> Bottom line: I stand by my original assessment -- until and
> unless someone presents a compelling argument for introducing a
> new language feature (for C) in this area, the language is better
> left as is.


I come at this from a rather different angle. Looking at the C-like
subset of C++ (no classes, templates, namespaces, and overloading), I
find it to be a superior version of C than C itself. That gap has been
narrowing over time, eg. adopting // comments, so what I propose is to
merely complete that task all at once. The individual changes could
probably not be justified on their own, but as a group, IMHO they are.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      06-26-2013
On Tuesday, June 25, 2013 4:30:43 PM UTC+1, Stephen Sprunk wrote:
> On 20-Jun-13 19:00, Tim Rentsch wrote:
>
> I come at this from a rather different angle. Looking at the C-like
> subset of C++ (no classes, templates, namespaces, and overloading), I
> find it to be a superior version of C than C itself. That gap has been
> narrowing over time, eg. adopting // comments, so what I propose is to
> merely complete that task all at once. The individual changes could
> probably not be justified on their own, but as a group, IMHO they are.
>

Quirks such as sizeof('x') giving different values in C and C++, and
int *x = malloc(10 * sizeof(int)) being a type incompatible error in
C++ but not C are best ironed out, I agree. // comments have been widely
accepted, but I have been bitten by compilers rejecting them. Whilst
you can usually set a flag, this often isn't acceptable, user needs to
be able to compile with a simple " C_compiler compile code.c " command.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-26-2013
On 06/26/2013 08:50 AM, Malcolm McLean wrote:
....
> you can usually set a flag, this often isn't acceptable, user needs to
> be able to compile with a simple " C_compiler compile code.c " command.


Few compilers are fully conforming in their default mode, and the ways
in which they fail to conform are different for different compilers. Do
you really want to insist on code being compilable in every compiler's
default mode?

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      06-26-2013
On Wednesday, June 26, 2013 3:25:17 PM UTC+1, James Kuyper wrote:
> On 06/26/2013 08:50 AM, Malcolm McLean wrote:
>
> Few compilers are fully conforming in their default mode, and the ways
> in which they fail to conform are different for different compilers. Do
> you really want to insist on code being compilable in every compiler's
> default mode?
>

Ideally yes.
Whilst it's possible to artificially construct legal, defined ANSI C programs
which will break on various compilers in default mode, usually you do that
either by artificially using little-used constructs

e.g.

x = y //*ha ha two fingers to you */z;

or, more forgiveably, you use identifiers like min which are often defined
by the environment.

There are a few areas where things are difficult, e.g. handling PI and nan().


 
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
Routing Between Two VLA Ns Bob Simon Cisco 5 02-06-2007 01:15 AM
VLA Question pemo C Programming 8 02-24-2006 01:04 PM
support of C99 VLA in compilers Ben Hinkle C Programming 6 12-15-2005 02:08 PM
Compound literals and VLA's William Ahern C Programming 6 08-24-2005 05:40 AM
[C99] local VLA with dimension given by a global var? MackS C Programming 15 02-21-2005 07:59 PM



Advertisments