Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #1415 > unrolled thread
| Started by | John Nagle <nagle@animats.com> |
|---|---|
| First post | 2012-08-13 11:39 -0700 |
| Last post | 2012-08-17 15:33 -0700 |
| Articles | 5 on this page of 105 — 13 participants |
Back to article view | Back to comp.std.c
Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 11:39 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-13 23:23 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 17:04 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 20:08 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 22:23 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 11:20 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 14:54 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:09 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:00 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:08 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 23:05 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 06:48 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 11:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 15:13 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 13:00 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:52 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 17:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:20 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:40 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:04 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:35 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:47 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:52 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 14:41 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 12:39 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 09:57 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:28 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 23:52 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 18:56 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 19:23 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-15 21:47 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 20:28 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 15:05 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 21:09 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 13:24 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:39 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 15:23 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:58 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 00:37 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:42 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:57 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:02 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 14:59 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 15:35 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 00:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:43 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:31 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:58 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:45 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:51 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 07:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:15 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:28 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:36 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:54 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 15:08 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:50 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 23:22 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 14:38 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 00:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 16:32 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 09:05 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 20:29 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:36 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 16:09 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:47 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:33 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:38 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:46 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 22:28 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:34 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:12 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 13:09 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 16:21 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 14:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 15:28 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 19:49 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 08:56 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 06:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 12:42 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 09:43 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 19:52 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:03 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:39 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-14 08:26 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-13 22:44 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 18:05 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:00 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Marc <marc.glisse@gmail.com> - 2012-08-14 21:18 +0000
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 23:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 09:40 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-17 21:00 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 13:30 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-17 23:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 01:07 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-19 23:14 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Ike Naar <ike@sverige.freeshell.org> - 2012-08-20 07:16 +0000
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-20 00:25 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-20 11:49 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-20 22:40 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-20 23:08 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-17 15:33 -0700
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-20 00:25 -0700 |
| Message-ID | <k0soq2$7f5$1@dont-email.me> |
| In reply to | #1560 |
On 8/20/2012 12:16 AM, Ike Naar wrote:
> On 2012-08-20, John Nagle <nagle@animats.com> wrote:
>> The way this ought to work is that, in this
>> example
>>
>> void fn4(int a1[100])
>> { int a2[100];
>> }
>>
>> a1 and a2 should have similar semantics. They
>> don't.
>>
>> a1++; // error, not a lhs
>> a2++; // allowed
>> sizeof(a1); // equals sizeof int
>> sizeof(a2); // equals 100 * sizeof int
>
> One would expect that a1++ is allowed, a2++ is in error,
> and that sizeof(a1) equals sizeof pointer-to-int.
>
You're right; I got those backwards during editing.
John Nagle
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-20 11:49 +0200 |
| Message-ID | <5032080E.3050405@loria.fr> |
| In reply to | #1559 |
Hello,
Am 20.08.2012 08:14, schrieb John Nagle:
> What semantics could we give VLA parameters that would
> keep all the size information around but not break anything
> important?
sorry but I am not able to understand this phrase
(linguistically). Could you rephrase, please?
> Worse, how can fixed-length arrays be given similar semantics.
> VLAs are rare, but fixed-length array parameters are not.
>
> One option is to distinguish between fully-dimensioned arrays
> and arrays where some dimension is unspecified. That is,
>
> void fn1(size_t n, char s[]);
>
> has an unspecified dimension, but
>
> void fn2(size_t n, int[n]);
> void fn3(int [100]);
>
> are fully specified.
>
> The unspecified case is a classic pointer. The
> fully specified case could potentially be handled
> differently.
>
> The way this ought to work is that, in this
> example
>
> void fn4(int a1[100])
> { int a2[100];
> }
>
> a1 and a2 should have similar semantics. They
> don't.
No on the side of the called function, they will never have similar
semantics. If you changed that it, it wouldn't be C anymore :(
> How about this?
>
> 1. Support the "pass by reference" described in the paper.
> Example:
> void fn5(int (&a1)[100]);
> Then
> sizeof(a1) // equals 100 * sizeof(int)
>
> Arrays passed by reference must be fully dimensioned.
>
> 2. Permit, but deprecate, C99 style VLA parameters,
> if the implementation supports them at all.
Not much in favor. How about this:
1. use existing utilities to pass size information in the second (an
further dimensions)
Example:
void fn5p(int (*const a1p)[100]);
Then inside the function
sizeof(*a1p) // equals 100 * sizeof(int)
this works already, no need to re-invent the wheel.
Nobody will want to manually write such dereffed pointers, so:
2. introduce references such that
void fn5(int (&a1)[100]);
is a "short cut" for a "raw" interface
void fn5p(int (*const a1p)[100]);
(i.e is ABI compatible with that) and such that inside the definition
of fn5 the identifier "a1" has the meaning of "(*aip)" that is it
evaluates to the lvalue to which "aip" would evaluate in the "raw"
interface. sizeof(a1) is then all naturally what you expect it to be,
namely sizeof(int[100]).
I think this are basically how references in C++ initially worked, no?
With that the caller of such a function can check the expected
"sizeof" that the called function will evaluate, and on the inside of
the function all size information is available through sizeof.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2012-08-20 22:40 +0200 |
| Message-ID | <a9flmjF9siU1@mid.dfncis.de> |
| In reply to | #1559 |
On 20.08.2012 08:14, John Nagle wrote:
> What semantics could we give VLA parameters that would
> keep all the size information around but not break anything
> important?
None, because there _are_ no VLA parameters. What you need is new
_syntax_ to actually introduce array parameters to the language in the
first place. Then you can start thinking about semantics.
> Worse, how can fixed-length arrays be given similar semantics.
You're still chasing the red herring. Forget about VLAs for the moment.
They may come up at some point down the road, but right now, they're
only distracting you.
> One option is to distinguish between fully-dimensioned arrays
> and arrays where some dimension is unspecified.
No, that is not an option. Not unless you're looking for way to
sabotage your own proposal, that is. There is essentially no way you'll
be allowed to introduce new meaning to existing syntax that has meant
the same thing for over 20 years.
> The unspecified case is a classic pointer. The
> fully specified case could potentially be handled
> differently.
That potential is effectively identical to zero. Forget it.
> The way this ought to work is that, in this
> example
>
> void fn4(int a1[100])
> { int a2[100];
> }
>
> a1 and a2 should have similar semantics. They
> don't.
Exactly. And you will not change that. No way. You will not break a
sizable portion of all existing C code for this.
So please do everybody including yourself a favour and stop thinking in
that direction --- you would only be wasting your time.
> a1++; // error, not a lhs
Wrong. Allowed.
> a2++; // allowed
Wrong. Error, not a lhs.
> sizeof(a1); // equals sizeof int
Wrong. That equals sizeof(int *)
> How about this?
>
> 1. Support the "pass by reference" described in the paper.
> Example:
> void fn5(int (&a1)[100]);
There's no particularly strong need for that. We already have a
perfectly usable
void fn5(int (*a1)[100]);
"Pass by reference" has meant "pass by pointer" since the beginning of
C. Reference arguments (the ones with a &) are really just syntactic
sugar on top of that. For the purposes of your proposal, they're not
really much more than another distraction off the actual issue.
And I for one am rather less than convinced that this reference syntax
is a good candidate for the new syntax you'll need for actually passing
arrays into a C --- because that syntax already means something else in
C++, where it has a much broader use.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-08-20 23:08 +0200 |
| Message-ID | <k0u8vd$235$1@speranza.aioe.org> |
| In reply to | #1571 |
Le 20/08/12 22:40, Hans-Bernhard Bröker a écrit :
> What you need is new _syntax_ to actually introduce array parameters to
> the language in the first place. Then you can start thinking about
> semantics.
Using operator overloading you can keep the same syntax but give it a
new meaning.
New syntax:
typedef struct tagMyArray {
size_t size;
double data[];
} MyArray;
double operator[](MyArray tab,int idx)
{
if (idx < 0 || idx > tab.size)
RaiseError(INDEXERROR);
return tab->data[idx];
}
This is new but all *other* syntax is the same.
int calc(MyArray data)
{
double sum=0;
for (int i=0; i<data.size; i++) {
sum += data[i];
}
return sum;
}
WHY nobody answers here when I propose this?
It is working in the lcc-win compiler since 10 years or so.
I repeat: this is the only workable solution that will accept OLD code
with new semantics with almost no modifications.
old code:
int calc(size_t n,double * data)
{
double sum=0;
for (size_t i=0; i<n; i++) {
sum += data[i];
}
return sum;
}
You see? All access remain the same, it is just that they now pass
through an overloaded operator!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-17 15:33 -0700 |
| Message-ID | <lnk3wxno7d.fsf@nuthaus.mib.org> |
| In reply to | #1515 |
John Nagle <nagle@animats.com> writes:
> OK, now that this has been discussed for a while, a recap
> of what we've learned is in order.
>
> - Variable length arrays were in the C99 standard, but implementation
> was not widespread.
I'm not aware of any C compiler that has implemented a substantial
portion of C99 without implementing VLAs. Microsoft doesn't count,
since they very nearly don't support C99 at all -- not even mixed
declarations and statements within a block, a feature that C++
does have. (Perhaps their latest C compiler does support that;
I tested it with the 2010 "Express" version.)
(Which makes me wonder just why VLAs were made optional in C11.
I'll post a separate article asking that.)
> - VLAs have been made an optional feature in the latest C
> standard draft.
> (Ref: n1570.pdf: §6.7.6.2p4: "Variable length arrays are a
> conditional feature that implementations need not support")
Yes.
> - Microsoft explicitly declined to support VLAs as incompatible
> with C++.
> (ref:
> http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/6099f453-db2c-49c3-b59a-b799c379cebb)
Yes, but see above.
[...]
> - VLAs have been criticized on other grounds:
> - Some implementations of threads do not well accommodate
> large stack growth. This causes a problem when a large local
> VLA is allocated.
The same problem would occur with a large fixed-size local array.
But yes, VLAs do tend to *encourage* larger arrays.
> - There is no way to recover from allocation failure of a VLA.
Yes, when used directly. But there is an alternative:
#include <stdlib.h>
#include <stdio.h>
int main(void) {
int rows = 10;
int columns = 20;
typedef double vla[rows][columns];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
fprintf(stderr, "malloc failed\n");
exit(EXIT_FAILURE);
}
else {
printf("sizeof *ptr = %zu\n", sizeof *ptr);
printf("sizeof (*ptr)[0] = %zu\n", sizeof (*ptr)[0]);
printf("sizeof (*ptr)[0][0] = %zu\n", sizeof (*ptr)[0][0]);
}
return 0;
}
This admittedly loses some of the advantages of VLAs, particularly
automatic deallocation, but it still lets you index a contiguously
allocated multidimensional array without having to do your own
indexing calculations. This would be difficult to do without VLAs
(unless some other feature such as operator overloading were added to
the language).
> - The behavior of "sizeof" for VLA function parameters differs from
> behavior on local VLAs.
No, because there is no such thing (in C as it's currently defined) as a
"VLA function parameter". More generally, C does not have parameters of
array type.
[snip]
> So, with C99 VLAs on the way out, it's appropriate to propose
> alternatives. Any alternative should potentially be portable
> to C++.
I don't agree that VLAs are on the way out. For example, gcc
supports them, and it's likely there's a significant amount of code
compiled with gcc that depends on them.
Any new feature that breaks VLAs would not be accepted.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.std.c
csiph-web