Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147976 > unrolled thread

OT: improve this simple algorithm?

Back to article view | Back to comp.lang.c

Contents

  OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 15:55 -0500
    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-12 21:20 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:28 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:52 +0100
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 10:16 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 16:53 +0100
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:18 +0000
    Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 23:30 +0000
      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:12 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 16:34 +0000
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 10:07 +1300
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 22:25 +0000
              Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 12:02 +1300
                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 23:27 +0000
                  Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 19:06 +1300
                    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 10:45 +0000
                      Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 13:28 +0100
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 12:58 +0000
                          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 15:39 +0100
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 15:04 +0000
                              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:19 -0500
                                Re: OT: improve this simple algorithm? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-15 09:46 -0800
                                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 18:59 +0000
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-16 11:59 +0000
                      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-16 09:02 +1300
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:17 +0100
                  Re: OT: improve this simple algorithm? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-15 21:38 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 11:44 -0500
        Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-14 18:11 +0000
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 13:33 -0500
            Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 01:49 +0000
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 10:38 -0800
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 12:56 -0500
        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 13:50 -0500
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 14:42 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 15:25 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 11:03 -0800
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 16:08 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:30 +0100
              Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 11:17 +0000
                Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:35 -0500
                  Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:39 -0500
                  Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:19 +0000
                    Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 18:53 -0500
                      Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 19:08 -0500
                      Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-16 01:30 +0000
                        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:39 -0500
                  Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:37 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-15 09:46 -0500
              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:38 -0500
                Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:07 +0000
                Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:54 -0800
                  Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-28 20:17 -0500
                    Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-29 06:08 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:45 +0100
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:10 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:19 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:57 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:34 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 23:57 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-13 23:00 -0800
        Re: OT: improve this simple algorithm? Ike Naar <ike@sdf.lonestar.org> - 2019-11-14 07:53 +0000
          Re: OT: improve this simple algorithm? guinness.tony@gmail.com - 2019-11-14 02:34 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:01 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 11:27 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:46 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:01 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:05 +0100
    Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-12 18:34 -0800
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-12 19:01 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 17:08 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 17:06 +0000
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 19:11 +0000
        Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:15 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 18:13 +0000
          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:16 +0100
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 20:03 +0000
              Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 04:51 +0100
        Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:15 -0800
          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:52 +0100
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:57 +0100
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-13 23:23 +1300
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:53 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 14:02 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 13:40 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 17:01 +0100
                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 16:28 +0000
                    Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 22:49 +0100
                      Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 22:38 +0000
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 23:06 +0000
                        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:10 +0100
                          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 10:42 +0000
                            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:53 +0100
                              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:28 +0000
                                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:21 +0100
                                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 14:28 +0000
                                    Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 15:38 +0100
                        Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:37 +0100
                          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:38 +0100
            Re: OT: improve this simple algorithm? Thiago Adams <thiago.adams@gmail.com> - 2019-11-13 05:21 -0800

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#148220

On 13/11/2019 04:01, Keith Thompson wrote:
> Barry Schwarz <schwarzb@delq.com> writes:
> [...]
>> Not many compilers support VLAs.
> [...]
> 
> Is that true?  Visual Studio doesn't, but in my experience most
> (other?)  modern C compilers do.
> 

I thought MSVC was moving, or had moved, to clang for C compiling?
Someone who uses MS tools could tell us.

C99 is 20 years old.  A C compiler can't call itself "modern" if it
doesn't support VLA's.

Even tcc supports VLA's quite happily.

[toc] | [prev] | [next] | [standalone]

#148221

On 13/11/2019 22:57, David Brown wrote:
> On 13/11/2019 04:01, Keith Thompson wrote:
>> Barry Schwarz <schwarzb@delq.com> writes:
>> [...]
>>> Not many compilers support VLAs.
>> [...]
>>
>> Is that true?  Visual Studio doesn't, but in my experience most
>> (other?)  modern C compilers do.
>>
> 
> I thought MSVC was moving, or had moved, to clang for C compiling?
> Someone who uses MS tools could tell us.

The clang++ front end is optional.  Mind you, it is for C++ which 
doesn't have VLAs.

> C99 is 20 years old.  A C compiler can't call itself "modern" if it
> doesn't support VLA's.
> 
> Even tcc supports VLA's quite happily.

In "modern" C compilers, VLAs are optional :)

Microsoft were hist ahead of their time...

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#148223

On 13/11/2019 09:57, David Brown wrote:
> On 13/11/2019 04:01, Keith Thompson wrote:
>> Barry Schwarz <schwarzb@delq.com> writes:
>> [...]
>>> Not many compilers support VLAs.
>> [...]
>>
>> Is that true?  Visual Studio doesn't, but in my experience most
>> (other?)  modern C compilers do.
>>
> 
> I thought MSVC was moving, or had moved, to clang for C compiling?
> Someone who uses MS tools could tell us.
> 
> C99 is 20 years old.  A C compiler can't call itself "modern" if it
> doesn't support VLA's.
> 
> Even tcc supports VLA's quite happily.
> 

I don't support VLAs. For one because I don't agree with the feature 
(imagine using a function like malloc for a memory pool 0.1% of the size 
of what is available to malloc, but with no way to check the result).

But also because it's quite complex to implement. Even though most uses 
of it are straightforward, you have to deal with all the fiddly bits 
that C allows (where a VLA is defined deep inside a type; the expression 
that gives the size changes value, but sizeof() has to return the 
original; and the VLA (or a dozen VLAs with 2-3 dimensions each) is 
repeatedly allocated and deallocated inside a nested block and inside a 
loop, with gotos all over the place).

(I know you think is it straightforward, when it was discussed in depth 
a few years ago on the 'std' group. But then you seem to think 
everything is.)

[toc] | [prev] | [next] | [standalone]

#148227

On 13/11/2019 12:53, Bart wrote:
> On 13/11/2019 09:57, David Brown wrote:
>> On 13/11/2019 04:01, Keith Thompson wrote:
>>> Barry Schwarz <schwarzb@delq.com> writes:
>>> [...]
>>>> Not many compilers support VLAs.
>>> [...]
>>>
>>> Is that true?  Visual Studio doesn't, but in my experience most
>>> (other?)  modern C compilers do.
>>>
>>
>> I thought MSVC was moving, or had moved, to clang for C compiling?
>> Someone who uses MS tools could tell us.
>>
>> C99 is 20 years old.  A C compiler can't call itself "modern" if it
>> doesn't support VLA's.
>>
>> Even tcc supports VLA's quite happily.
>>
> 
> I don't support VLAs. For one because I don't agree with the feature
> (imagine using a function like malloc for a memory pool 0.1% of the size
> of what is available to malloc, but with no way to check the result).

And with 0.1% of the run-time cost of malloc...

(And rounded to the nearest percent, no one checks the success or
failure of malloc and sensibly handles failure smoothly.  In almost any
software on a PC, a malloc failure means a program crash with a more or
less unfriendly error.  A VLA allocation failure will give the same result.)

I know you don't support VLAs.  But you don't claim your compiler is a
full-featured modern C compiler.  It's a specialised compiler handling
the subset of C you want it to handle, and that's fair enough.

> 
> But also because it's quite complex to implement. Even though most uses
> of it are straightforward, you have to deal with all the fiddly bits
> that C allows (where a VLA is defined deep inside a type; the expression
> that gives the size changes value, but sizeof() has to return the
> original; and the VLA (or a dozen VLAs with 2-3 dimensions each) is
> repeatedly allocated and deallocated inside a nested block and inside a
> loop, with gotos all over the place).
> 
> (I know you think is it straightforward, when it was discussed in depth
> a few years ago on the 'std' group. But then you seem to think
> everything is.)
> 

I don't think everything is straightforward, as I have told you
countless times.  But implementing VLA's would be a lot simpler and
easier than many of the things you have already implemented.

I you think implementing VLA's is a problem to implement, I think you
are either mistaken or lying.  I gave you a lot of ideas and suggestions
on how to implement them in that previous conversation.  I simply do not
believe you are smart enough to have implemented the compiler you have,
but not smart enough to get VLA's working in a simple manner.  If you
actively /choose/ not to implement VLA's, because you don't like them,
don't want them, or can't be bothered, then that is absolutely fine.
But stop making excuses about it being "hard" - you could do it fine if
you wanted to.

[toc] | [prev] | [next] | [standalone]

#148229

On 13/11/2019 13:02, David Brown wrote:
> On 13/11/2019 12:53, Bart wrote:

>>
>> I don't support VLAs. For one because I don't agree with the feature
>> (imagine using a function like malloc for a memory pool 0.1% of the size
>> of what is available to malloc, but with no way to check the result).
> 
> And with 0.1% of the run-time cost of malloc...

No, malloc isn't 1000 times as slow. I rigged up DFS's mergesort program 
from 7-11-19 to deliver a measurable time. With VLAs it was 1.1 seconds 
to 1.4 seconds using malloc, unoptimised; with -O3 then using VLAs was 
double the speed.

But the problem reported was that it was crashing above 500K elements, 
because the stack limit was being reached. So heap memory had to be used 
anyway, for the cases that would also take longer to execute.


> 
> (And rounded to the nearest percent, no one checks the success or
> failure of malloc and sensibly handles failure smoothly.  In almost any
> software on a PC, a malloc failure means a program crash with a more or
> less unfriendly error.  A VLA allocation failure will give the same result.)


I've seen malloc failures, which are usually to do with bugs in the 
logic than actually being out of memory.

Take these two functions:

----------------------------------------------------
void* checkedmalloc(long long int n) {
     void* p;
     p = malloc(n);
     if (p == NULL) {
         puts("Malloc failure");
         exit(1);
     }
     return p;
}

void uncheckedvla(long long int n) {
     int A[n];
     memset(A,0,n*sizeof(n));
}
----------------------------------------------------

Call checkedmalloc() with a rogue value of -1, it will fail gracefully. 
Call uncheckedvla(-1), it will crash.

Now call checkedmalloc(100000000), it will most likely work, but if not 
it will fail gracefully. Call uncheckedvla(25000000) (for same number of 
bytes), it will crash. Unless you have an unusually large stack allocated.

(Stack sizes per task tend to be 1-8MB. Total main memory might be 
1000-32000MB. On PCs anyway.)

[toc] | [prev] | [next] | [standalone]

#148236

On 13/11/2019 14:40, Bart wrote:
> On 13/11/2019 13:02, David Brown wrote:
>> On 13/11/2019 12:53, Bart wrote:
> 
>>>
>>> I don't support VLAs. For one because I don't agree with the feature
>>> (imagine using a function like malloc for a memory pool 0.1% of the size
>>> of what is available to malloc, but with no way to check the result).
>>
>> And with 0.1% of the run-time cost of malloc...
> 
> No, malloc isn't 1000 times as slow. I rigged up DFS's mergesort program
> from 7-11-19 to deliver a measurable time. With VLAs it was 1.1 seconds
> to 1.4 seconds using malloc, unoptimised; with -O3 then using VLAs was
> double the speed.
> 
> But the problem reported was that it was crashing above 500K elements,
> because the stack limit was being reached. So heap memory had to be used
> anyway, for the cases that would also take longer to execute.
> 

Why do you think that is relevant?  What is it about the OP's posts that
suggests he wants to handle such large lists of numbers?  What makes you
think it is better to be able to work with 500 K lists, while still
failing with 500 M lists dues to lack of heap?

The point is, VLA's are perfectly good here.  They are a tool in the
toolbox - use them when they make sense.  As with /every/ tool, they
have limitations, but you don't need to invent problems.

> 
>>
>> (And rounded to the nearest percent, no one checks the success or
>> failure of malloc and sensibly handles failure smoothly.  In almost any
>> software on a PC, a malloc failure means a program crash with a more or
>> less unfriendly error.  A VLA allocation failure will give the same
>> result.)
> 
> 
> I've seen malloc failures, which are usually to do with bugs in the
> logic than actually being out of memory.
> 
> Take these two functions:
> 
> ----------------------------------------------------
> void* checkedmalloc(long long int n) {
>     void* p;
>     p = malloc(n);
>     if (p == NULL) {
>         puts("Malloc failure");
>         exit(1);
>     }
>     return p;
> }
> 
> void uncheckedvla(long long int n) {
>     int A[n];
>     memset(A,0,n*sizeof(n));
> }
> ----------------------------------------------------
> 
> Call checkedmalloc() with a rogue value of -1, it will fail gracefully.
> Call uncheckedvla(-1), it will crash.
> 

So don't do that.  Then your invented problem disappears.

> Now call checkedmalloc(100000000), it will most likely work, but if not
> it will fail gracefully. Call uncheckedvla(25000000) (for same number of
> bytes), it will crash. Unless you have an unusually large stack allocated.
> 

Call checkedmalloc(100000000000) and there is a fair chance it will fail
/ungracefully/ - depending on your OS and your computer, it might
happily allocate all your ram and start chewing up your harddisk for
virtual memory space, with your computer grinding to a crawl and being
so slow it is barely even possible to kill the program.

uncheckedvla with the same parameter would die quickly and harmlessly.


If you do stupid things in your program, bad things happen.  Anyone who
thinks malloc is safer than a VLA because it returns 0 on allocation
failure, is kidding themselves.  They have completely misunderstood how
to write safe and reliable code.

> (Stack sizes per task tend to be 1-8MB. Total main memory might be
> 1000-32000MB. On PCs anyway.)
> 
> 
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#148238

On 13/11/2019 16:01, David Brown wrote:
> On 13/11/2019 14:40, Bart wrote:

> Why do you think that is relevant?  What is it about the OP's posts that
> suggests he wants to handle such large lists of numbers?  What makes you
> think it is better to be able to work with 500 K lists, while still
> failing with 500 M lists dues to lack of heap?
> 
> The point is, VLA's are perfectly good here.  They are a tool in the
> toolbox - use them when they make sense.  As with /every/ tool, they
> have limitations, but you don't need to invent problems.

>> Now call checkedmalloc(100000000), it will most likely work, but if not
>> it will fail gracefully. Call uncheckedvla(25000000) (for same number of
>> bytes), it will crash. Unless you have an unusually large stack allocated.
>>
> 
> Call checkedmalloc(100 000 000 000) and there is a fair chance it will fail
> /ungracefully/ - depending on your OS and your computer,

For malloc, 1B to 1000MB might be a reasonable amount to allocate, while 
100,000MB might be less reasonable given that available RAM is typically 
considerably less. (Actually, allocating 100GB fails immediately on my 
machine with 8GB physical RAM.)

For VLAs, the reasonable range might be 1B to 1MB, some 3 magnitudes 
smaller than malloc. It would be a bad choice for sort implementations 
for data sizes with arbitrary upper limits. (1MB accommodates lists of 
only 128K strings, and merge-sorting may need multiple copies.)

(VLAs implemented via calls to malloc and free might be better; you have 
the more convenient handling, without the limitations of stack memory 
(actually, the approach I use in dynamic implementations.) But I haven't 
seen evidence of that being done by gcc.

What is also possible is to conditionally use either VLA or heap 
allocations depending on size requested.)


  it might
> happily allocate all your ram and start chewing up your harddisk for
> virtual memory space, with your computer grinding to a crawl and being
> so slow it is barely even possible to kill the program.
> 
> uncheckedvla with the same parameter would die quickly and harmlessly.
> 
> 
> If you do stupid things in your program, bad things happen.

I'm talking about things being done inadvertently, or through some 
program bug. It doesn't help that VLAs are generally created silently so 
someone may not be aware that an is a VLA that can blow up with 
different parameters.


> Anyone who
> thinks malloc is safer than a VLA because it returns 0 on allocation
> failure, is kidding themselves.  They have completely misunderstood how
> to write safe and reliable code.

You think just ignoring stack limitations and letting a program crash is 
good way to program? In a larger system, a failure to allocate memory 
can be detected and a /part/ of the program can fail under full control, 
but it still run.

For example, while implementing one user command. Then it can report a 
failure ("Not enough to perform this task") but the data etc is still 
intact. With a VLA, it will just abort the whole thing with loss of data.

[toc] | [prev] | [next] | [standalone]

#148245

On 13/11/2019 17:28, Bart wrote:
> On 13/11/2019 16:01, David Brown wrote:
>> On 13/11/2019 14:40, Bart wrote:
> 
>> Why do you think that is relevant?  What is it about the OP's posts that
>> suggests he wants to handle such large lists of numbers?  What makes you
>> think it is better to be able to work with 500 K lists, while still
>> failing with 500 M lists dues to lack of heap?
>>
>> The point is, VLA's are perfectly good here.  They are a tool in the
>> toolbox - use them when they make sense.  As with /every/ tool, they
>> have limitations, but you don't need to invent problems.
> 
>>> Now call checkedmalloc(100000000), it will most likely work, but if not
>>> it will fail gracefully. Call uncheckedvla(25000000) (for same number of
>>> bytes), it will crash. Unless you have an unusually large stack 
>>> allocated.
>>>
>>
>> Call checkedmalloc(100 000 000 000) and there is a fair chance it will 
>> fail
>> /ungracefully/ - depending on your OS and your computer,
> 
> For malloc, 1B to 1000MB might be a reasonable amount to allocate, while 
> 100,000MB might be less reasonable given that available RAM is typically 
> considerably less. (Actually, allocating 100GB fails immediately on my 
> machine with 8GB physical RAM.)
> 
> For VLAs, the reasonable range might be 1B to 1MB, some 3 magnitudes 
> smaller than malloc. It would be a bad choice for sort implementations 
> for data sizes with arbitrary upper limits. (1MB accommodates lists of 
> only 128K strings, and merge-sorting may need multiple copies.)
> 
> (VLAs implemented via calls to malloc and free might be better; you have 
> the more convenient handling, without the limitations of stack memory 
> (actually, the approach I use in dynamic implementations.) But I haven't 
> seen evidence of that being done by gcc.

No.  It would be possible to implement this, but fiddly - and it would 
be unexpected.  People use VLA's expecting them to be on the stack, 
avoiding the overhead of malloc and free.

A key part to making VLA's on heap work is to have a destructor to be 
called when the array goes out of scope.  gcc has support for that (even 
in C, as an extension), so the machinery is there.  I guess it is just 
not a feature people have been looking for.

> 
> What is also possible is to conditionally use either VLA or heap 
> allocations depending on size requested.)
> 
> 
>   it might
>> happily allocate all your ram and start chewing up your harddisk for
>> virtual memory space, with your computer grinding to a crawl and being
>> so slow it is barely even possible to kill the program.
>>
>> uncheckedvla with the same parameter would die quickly and harmlessly.
>>
>>
>> If you do stupid things in your program, bad things happen.
> 
> I'm talking about things being done inadvertently, or through some 
> program bug. 

That counts as stupid things.  Doing stupid things doesn't mean the 
programmer is stupid - smart people do stupid things regularly.  They 
just don't do them quite as regularly as stupid people.

I don't expect a programming language or a compiler to give me good 
results when I do something stupid in my code.  I like it when the tool 
tells me I'm being stupid, but I don't expect it to turn my stupid code 
into smart code.

> It doesn't help that VLAs are generally created silently so 
> someone may not be aware that an is a VLA that can blow up with 
> different parameters.
> 

That makes no sense.  If you have a function taking a parameter "n", and 
you declare an array of size "n", how can you not know that it will be 
bigger if "n" is bigger?  People might unknowingly make a VLA (for 
example, if you write "const int n = 10; int x[n];" it is a VLA in C, 
but if you are familiar with C++ you might think it is a normal array). 
But you should know about the array's size.

> 
>> Anyone who
>> thinks malloc is safer than a VLA because it returns 0 on allocation
>> failure, is kidding themselves.  They have completely misunderstood how
>> to write safe and reliable code.
> 
> You think just ignoring stack limitations and letting a program crash is 
> good way to program? 

It is no worse than what people typically do with heap allocations.

But no, I don't think it is a good way to program.  And I can't see how 
you thought that from what I wrote.  The good way to program is to check 
any unknown incoming data for sanity before you do anything with it - 
that includes allocating memory with malloc just as much as it includes 
declaring a VLA.  Calling malloc with a size that depends on unchecked 
outside data is as bad as allocating a VLA with unchecked outside data.

> In a larger system, a failure to allocate memory 
> can be detected and a /part/ of the program can fail under full control, 
> but it still run.
> 
> For example, while implementing one user command. Then it can report a 
> failure ("Not enough to perform this task") but the data etc is still 
> intact. With a VLA, it will just abort the whole thing with loss of data.
> 

Yes, in theory - handling a failed malloc is done properly in a tiny 
fraction of real programs.  And if you have coded well, your mallocs 
will never fail - nor will your VLA allocations.

[toc] | [prev] | [next] | [standalone]

#148246

On 13/11/2019 21:49, David Brown wrote:
> On 13/11/2019 17:28, Bart wrote:

> That makes no sense.  If you have a function taking a parameter "n", and 
> you declare an array of size "n", how can you not know that it will be 
> bigger if "n" is bigger?

It happens. You might not know whether n (or some complex expression 
made of half a dozen terms defined in different parts of a program, or 
conditional on macros) is constant or variable.

I might only find out, when compiling a program unknown to me, because 
bcc says "VLAs not implemented".


>> For example, while implementing one user command. Then it can report a 
>> failure ("Not enough to perform this task") but the data etc is still 
>> intact. With a VLA, it will just abort the whole thing with loss of data.
>>
> 
> Yes, in theory - handling a failed malloc is done properly in a tiny 
> fraction of real programs.  And if you have coded well, your mallocs 
> will never fail - nor will your VLA allocations.

Perhaps you don't have experience of long-running interactive 
user-applications. At every stage you are doing things which allocate 
varying amounts of memory according to user input. Here's an example in 
C that tries out malloc with different numbers entered on the command line:

--------------------
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>
#include <string.h>

int malloctester(long long int n) {
     void *p = malloc(n);

     if (p == NULL) return 0;
//  memset(p,0,n);
     free(p);
     return 1;
}

long long int atoll(char* s) {
     long long int n;
     sscanf(s,"%lld",&n);
     return n;
}

int main(int nparams, char** params) {
     long long int n;

     if (nparams<=1) exit(0);

     for (int i=1; i<nparams; ++i) {
         n = atoll(params[i]);
         if (malloctester(n))
             printf("Successfully allocated/deallocated %lld bytes\n",n);
         else
             printf("*************** Failed to allocate %lld bytes\n",n);
     }
}
--------------------------------

Run as:

   prog 1000000 500000000 100000

etc to allocate each size in turn. (I don't write to the memory to avoid 
destabilising my machine when values are at the limits of physical memory).

On my 8GB machine, this fails on 'prog 1', passes 'prog 11000000000', 
but fails at '12000000000'.

Challenge: modify the program to allocate the memory via a VLA. 
Naturally it will fail on smaller numbers, but it needs to report a 
failure, then proceed to the next value. Not just crash out.

[toc] | [prev] | [next] | [standalone]

#148247

On 13/11/2019 22:38, Bart wrote:

> On my 8GB machine, this fails on 'prog 1'

'prog -1'

[toc] | [prev] | [next] | [standalone]

#148261

On 13/11/2019 23:38, Bart wrote:
> On 13/11/2019 21:49, David Brown wrote:
>> On 13/11/2019 17:28, Bart wrote:
> 
>> That makes no sense.  If you have a function taking a parameter "n",
>> and you declare an array of size "n", how can you not know that it
>> will be bigger if "n" is bigger?
> 
> It happens. You might not know whether n (or some complex expression
> made of half a dozen terms defined in different parts of a program, or
> conditional on macros) is constant or variable.

If you don't know what it is, and don't know its limits and bounds,
don't use it.

> 
> I might only find out, when compiling a program unknown to me, because
> bcc says "VLAs not implemented".
> 

You know my answer here.  You can predict it, I'm sure:

	gcc -Wvla

warns if a VLA is used.

And
	gcc -Wvla-larger-than=10000

warns if a VLA is bigger than 10000 bytes (or might be bigger than
that).  It is useful to have optimisation enabled to let the compiler
work out bounds more accurately.

> 
>>> For example, while implementing one user command. Then it can report
>>> a failure ("Not enough to perform this task") but the data etc is
>>> still intact. With a VLA, it will just abort the whole thing with
>>> loss of data.
>>>
>>
>> Yes, in theory - handling a failed malloc is done properly in a tiny
>> fraction of real programs.  And if you have coded well, your mallocs
>> will never fail - nor will your VLA allocations.
> 
> Perhaps you don't have experience of long-running interactive
> user-applications.

Most of my programs never stop - at least not until power is cut.  But
the user interaction is typically of a different sort than you are
talking about here.

> At every stage you are doing things which allocate
> varying amounts of memory according to user input. Here's an example in
> C that tries out malloc with different numbers entered on the command line:
> 
> --------------------
> #include <stdio.h>
> #include <stdlib.h>
> #include <malloc.h>
> #include <string.h>
> 
> int malloctester(long long int n) {
>     void *p = malloc(n);
> 
>     if (p == NULL) return 0;
> //  memset(p,0,n);
>     free(p);
>     return 1;
> }
> 
> long long int atoll(char* s) {
>     long long int n;
>     sscanf(s,"%lld",&n);
>     return n;
> }
> 
> int main(int nparams, char** params) {
>     long long int n;
> 
>     if (nparams<=1) exit(0);
> 
>     for (int i=1; i<nparams; ++i) {
>         n = atoll(params[i]);

There's your bug.  You are getting unknown input from the outside, and
not checking it for sane values.  That's okay for a quick test program
you are writing for your own use - it is not okay for a program released
into the wild.

>         if (malloctester(n))
>             printf("Successfully allocated/deallocated %lld bytes\n",n);
>         else
>             printf("*************** Failed to allocate %lld bytes\n",n);
>     }
> }
> --------------------------------
> 
> Run as:
> 
>   prog 1000000 500000000 100000
> 
> etc to allocate each size in turn. (I don't write to the memory to avoid
> destabilising my machine when values are at the limits of physical memory).
> 
> On my 8GB machine, this fails on 'prog 1', passes 'prog 11000000000',
> but fails at '12000000000'.
> 
> Challenge: modify the program to allocate the memory via a VLA.
> Naturally it will fail on smaller numbers, but it needs to report a
> failure, then proceed to the next value. Not just crash out.
> 

Challenge - modify the program to bring you a cup of tea every time you
enter the number "42".

What?  Does the challenge not make sense?  Neither does yours.  You
might /think/ it makes sense, but it doesn't.

[toc] | [prev] | [next] | [standalone]

#148265

On 14/11/2019 09:10, David Brown wrote:
> On 13/11/2019 23:38, Bart wrote:

> You know my answer here.  You can predict it, I'm sure:
> 
> 	gcc -Wvla
> 
> warns if a VLA is used.

Sure. Just add another option to every single invocation of gcc on the 
off-chance that VLAs are use, to the other 198 options.

> And
> 	gcc -Wvla-larger-than=10000
> 
> warns if a VLA is bigger than 10000 bytes (or might be bigger than
> that).  It is useful to have optimisation enabled to let the compiler
> work out bounds more accurately.

It seems more like gcc acknowledges that VLAs, or VLAs used with 
excessive sizes, can cause problems. (I couldn't get the second option 
to work; that doesn't inspire much confidence. How does it work as a 
/compile-time/ check anyway if a VLA size is determined at runtime?)


> There's your bug.  You are getting unknown input from the outside, and
> not checking it for sane values.

What /are/ the sane values? This checkedmalloc() will tell you!

And it's not always a single number; OOM can be encountered during a 
long task and you need to abort that task, but not the program.

> Challenge - modify the program to bring you a cup of tea every time you
> enter the number "42".
> 
> What?  Does the challenge not make sense?  Neither does yours.  You
> might /think/ it makes sense, but it doesn't.

It's completely obvious that VLAs can be far more dangerous than malloc 
calls. Yet you are trying to brush the problems under the carpet.

[toc] | [prev] | [next] | [standalone]

#148268

On 14/11/2019 11:42, Bart wrote:
> On 14/11/2019 09:10, David Brown wrote:
>> On 13/11/2019 23:38, Bart wrote:
> 
>> You know my answer here.  You can predict it, I'm sure:
>>
>>     gcc -Wvla
>>
>> warns if a VLA is used.
> 
> Sure. Just add another option to every single invocation of gcc on the
> off-chance that VLAs are use, to the other 198 options.

Most people would rather use an option to a real compiler than your
alternative - use a toy written by "someone off the internet" that
compiles some bits of C.  Oh, I forgot - it does it /really/ fast, and
that is more important than anything else.

> 
>> And
>>     gcc -Wvla-larger-than=10000
>>
>> warns if a VLA is bigger than 10000 bytes (or might be bigger than
>> that).  It is useful to have optimisation enabled to let the compiler
>> work out bounds more accurately.
> 
> It seems more like gcc acknowledges that VLAs, or VLAs used with
> excessive sizes, can cause problems. (I couldn't get the second option
> to work; that doesn't inspire much confidence. How does it work as a
> /compile-time/ check anyway if a VLA size is determined at runtime?)
> 

It seems like gcc acknowledges that some /programmers/ might want this
check.  And yes, some programmers /do/ want it.  gcc acknowledges that
the world does not revolve around Bart and his personal preferences,
prejudices, requirements and pet hates.  Thus it has lots of options to
let people get the features /they/ want.  It is not like "bcc" - a
compiler written specifically for one person to use in one way, that
doesn't need options.

> 
>> There's your bug.  You are getting unknown input from the outside, and
>> not checking it for sane values.
> 
> What /are/ the sane values? This checkedmalloc() will tell you!

The sane values depend on the task in hand, obviously.

> 
> And it's not always a single number; OOM can be encountered during a
> long task and you need to abort that task, but not the program.
> 
>> Challenge - modify the program to bring you a cup of tea every time you
>> enter the number "42".
>>
>> What?  Does the challenge not make sense?  Neither does yours.  You
>> might /think/ it makes sense, but it doesn't.
> 
> It's completely obvious that VLAs can be far more dangerous than malloc
> calls. Yet you are trying to brush the problems under the carpet.
> 

It is obvious that you are failing to understand the issue.  I'm not
sure if it is because you are failing to apply even a modicum of thought
to the process, or just trolling.

[toc] | [prev] | [next] | [standalone]

#148270

On 14/11/2019 11:53, David Brown wrote:
> On 14/11/2019 11:42, Bart wrote:
>> On 14/11/2019 09:10, David Brown wrote:
>>> On 13/11/2019 23:38, Bart wrote:
>>
>>> You know my answer here.  You can predict it, I'm sure:
>>>
>>>      gcc -Wvla
>>>
>>> warns if a VLA is used.
>>
>> Sure. Just add another option to every single invocation of gcc on the
>> off-chance that VLAs are use, to the other 198 options.
> 
> Most people would rather use an option to a real compiler than your
> alternative - use a toy written by "someone off the internet" that
> compiles some bits of C.  Oh, I forgot - it does it /really/ fast, and
> that is more important than anything else.
> 
>>
>>> And
>>>      gcc -Wvla-larger-than=10000
>>>
>>> warns if a VLA is bigger than 10000 bytes (or might be bigger than
>>> that).  It is useful to have optimisation enabled to let the compiler
>>> work out bounds more accurately.
>>
>> It seems more like gcc acknowledges that VLAs, or VLAs used with
>> excessive sizes, can cause problems. (I couldn't get the second option
>> to work; that doesn't inspire much confidence. How does it work as a
>> /compile-time/ check anyway if a VLA size is determined at runtime?)
>>
> 
> It seems like gcc acknowledges that some /programmers/ might want this
> check.  And yes, some programmers /do/ want it.  gcc acknowledges that
> the world does not revolve around Bart and his personal preferences,
> prejudices, requirements and pet hates.  Thus it has lots of options to
> let people get the features /they/ want.  It is not like "bcc" - a
> compiler written specifically for one person to use in one way, that
> doesn't need options.
> 
>>
>>> There's your bug.  You are getting unknown input from the outside, and
>>> not checking it for sane values.
>>
>> What /are/ the sane values? This checkedmalloc() will tell you!
> 
> The sane values depend on the task in hand, obviously.

Not when it depends entirely on available memory. You can't determine 
that (in portable code) with either heap or stack. But with the heap, 
you can make a tentative allocation first. It is just more flexible, 
/plus/ it typically has far higher limits.


>> It's completely obvious that VLAs can be far more dangerous than malloc
>> calls. Yet you are trying to brush the problems under the carpet.
>>
> 
> It is obvious that you are failing to understand the issue.  I'm not
> sure if it is because you are failing to apply even a modicum of thought
> to the process, or just trolling.

I don't think it's me failing to understand the issues. You have to 
write a function that operates on a string like this:

   int stringop(char* s, int length) {
   }

The algorithm involves first making a temporary string of the same 
length as s. Conditions:

* No upper limits are specified as to the length (except as limited by 
the int type).

* The function can return a failure code if something went wrong or it 
couldn't complete

* It needs to run as fast as possible

So, do you use a VLA or the heap, or something else?

[toc] | [prev] | [next] | [standalone]

#148274

On 14/11/2019 13:28, Bart wrote:
> On 14/11/2019 11:53, David Brown wrote:
>> On 14/11/2019 11:42, Bart wrote:
> 
>>> It's completely obvious that VLAs can be far more dangerous than malloc
>>> calls. Yet you are trying to brush the problems under the carpet.
>>>
>>
>> It is obvious that you are failing to understand the issue.  I'm not
>> sure if it is because you are failing to apply even a modicum of thought
>> to the process, or just trolling.
> 
> I don't think it's me failing to understand the issues. You have to
> write a function that operates on a string like this:
> 
>   int stringop(char* s, int length) {
>   }
> 

I'm sorry, I am a programmer.  If someone asks me to write a function
with unlimited sizes, or "as fast as possible", I reject it as poorly
specified.  (Or I give them a better specification - my job often
involves writing requirement specifications because the customer doesn't
really understand what is needed.)

[toc] | [prev] | [next] | [standalone]

#148275

On 14/11/2019 13:21, David Brown wrote:
> On 14/11/2019 13:28, Bart wrote:

>>
>> I don't think it's me failing to understand the issues. You have to
>> write a function that operates on a string like this:
>>
>>    int stringop(char* s, int length) {
>>    }
>>
> 
> I'm sorry, I am a programmer.  If someone asks me to write a function
> with unlimited sizes, or "as fast as possible", I reject it as poorly
> specified.  (Or I give them a better specification - my job often
> involves writing requirement specifications because the customer doesn't
> really understand what is needed.)

'length' may relate to the size of a file; or a string representing a 
bignun; or the size of the output of a code generator. Something that 
can easily be into 7 or 8 figures without there being anything amiss.

I don't call that poorly specified. Let's say the task is to remove 
spaces from a read-only string then pass that new string on to another 
function. So you need a temporary local copy.

It's a general purpose function that can be used for those longer 
strings, or equally for very short strings; why impose a restriction? 
The only one is available memory.

I have anyway limited the size to 2**31-2.

You're refusing to answer the question, so I'm tell you: using VLAs as 
the primary data structure is unsuitable here.

You can use a VLA combined with heap, but equally you can use a fixed 
local array combined with heap.

However a VLA has extra issues: on Windows where gcc uses a function to 
allocate stack frames which are either over 4KB, or which might be over 
4KB (eg. a VLA of size n, even if n is small), that can make things slower.

To conditionally use a VLA, when the size if small, has its own problems 
where the VLA is defined inside a block; you can't use it outside the 
block. And it might not be enough to stop the __chkstk() call.

A solution involving a local array can be done like this:

     char buffer[2048];
     char *t;

     if (length<sizeof(buffer)
         t=buffer;
     else
         t=malloc(length+1);

The downside is that every invocation will involve using 2KB of stack, 
but that is only an issue when heavily recursive. We know that here, 
that is unlikely.

[toc] | [prev] | [next] | [standalone]

#148276

> However a VLA has extra issues: on Windows where gcc uses a function to 
> allocate stack frames which are either over 4KB, or which might be over 
> 4KB (eg. a VLA of size n, even if n is small), that can make things slower.

I've benchmarked alloca(), and VLAs would have a similar performance
-impact. an alloca() takes about 13 clock-cycles including the __chkstk
on my Ryzen. That should be unbeatable by malloc().

#include <iostream>
#include <cstdlib>
#include <random>
#include <chrono>
#if defined(_MSC_VER)
     #include <malloc.h>
#elif defined(__linux__)
     #include <alloca.h>
#endif

using namespace std;
using namespace chrono;

void allocaFn( size_t *sizes, size_t n )
{
     char volatile *p;
     for( size_t i = 0; i != n; ++i )
         p  = (char volatile *)alloca( sizes[i] ),
         *p = '*';
}

int main( int argc, char **argv )
{
     if( argc < 2 )
         return EXIT_FAILURE;
     double                           clocksPerNs = 1.0 / atof( argv[1] );
     size_t const                     ALLOCATIONS_PER_SLICE = 16,
                                      SLICES                = 1024;
     size_t                           sizes[ALLOCATIONS_PER_SLICE * SLICES];
     size_t const                     ROUNDS = 100'000;
     size_t const                     LOWER_LIMIT = 1,
                                      UPPER_KIMIT = 32768;
     random_device                    rd;
     uniform_int_distribution<size_t> sizeGen( LOWER_LIMIT, UPPER_KIMIT );
     for( size_t &s : sizes )
         s = sizeGen( rd );
     time_point<high_resolution_clock> start = high_resolution_clock::now();
     for( size_t round = ROUNDS; round; --round )
         for( size_t slice = 0; slice != SLICES * ALLOCATIONS_PER_SLICE; 
slice += ALLOCATIONS_PER_SLICE )
             allocaFn( sizes + slice, ALLOCATIONS_PER_SLICE );
     double nsPerAllocation = duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count() / ((double)ROUNDS * 
ALLOCATIONS_PER_SLICE * SLICES);
     cout << nsPerAllocation / clocksPerNs << " clock cycles" << endl;
}


>      char buffer[2048];
>      char *t;
>      if (length<sizeof(buffer)
>          t=buffer;
>      else
>          t=malloc(length+1);

That's less convenient as my C++-class:

#pragma once
#include <cstddef>
#include <memory>
#include <vector>
#include <cassert>

template<typename T, std::size_t N, typename Alloc = std::allocator<T>>
struct overflow_array
{
              overflow_array( std::size_t n, Alloc const &alloc = Alloc() );
              ~overflow_array();
     T       &operator []( std::size_t i );
     T       &front();
     T       &back();
     T       *data();
     T       *begin();
     T       *end();
     T const *cbegin() const;
     T const *cend() const;

private:
     union
     {
         T                     m_array[N];
         std::vector<T, Alloc> m_vec;
     };
     T *m_begin,
       *m_end;
};

template<typename T, std::size_t N, typename Alloc>
inline
overflow_array<T, N, Alloc>::overflow_array( std::size_t n, Alloc const 
&alloc )
{
     if( n <= N )
     {
         m_begin = m_array;
         m_end   = m_array + n;
         return;
     }
     new( (void *)&m_vec ) std::vector<T, Alloc>( alloc );
     try
     {
         m_vec.resize( n );
     }
     catch( ... )
     {
         m_vec.~vector();
         throw;
     }
     assert((void *)&*m_vec.begin() != (void *)&m_vec);
     m_begin = &*m_vec.begin();
     m_end   = &*m_vec.end();
}

template<typename T, std::size_t N, typename Alloc>
inline
overflow_array<T, N, Alloc>::~overflow_array()
{
     if( m_begin == m_array )
         return;
     m_vec.~vector();
}

template<typename T, std::size_t N, typename Alloc>
inline
T &overflow_array<T, N, Alloc>::operator []( std::size_t i )
{
     return m_begin[i];
}

template<typename T, std::size_t N, typename Alloc>
inline
T &overflow_array<T, N, Alloc>::front()
{
     return *m_begin;
}

template<typename T, std::size_t N, typename Alloc>
inline
T &overflow_array<T, N, Alloc>::back()
{
     return m_end[-1];
}

template<typename T, std::size_t N, typename Alloc>
inline
T *overflow_array<T, N, Alloc>::data()
{
     return m_begin;
}

template<typename T, std::size_t N, typename Alloc>
inline
T *overflow_array<T, N, Alloc>::begin()
{
     return m_begin;
}

template<typename T, std::size_t N, typename Alloc>
inline
T *overflow_array<T, N, Alloc>::end()
{
     return m_end;
}

template<typename T, std::size_t N, typename Alloc>
inline
T const *overflow_array<T, N, Alloc>::cbegin() const
{
     return m_begin;
}

template<typename T, std::size_t N, typename Alloc>
inline
T const *overflow_array<T, N, Alloc>::cend() const
{
     return m_end;
}

[toc] | [prev] | [next] | [standalone]

#148271

> Challenge: modify the program to allocate the memory via a VLA. 
> Naturally it will fail on smaller numbers, but it needs to report
> a failure, then proceed to the next value. Not just crash out.

That's a stupid experiment. alloa() is used for small allocations
and the success isn't checked just as less as the stack-depth with
recursive functions.

[toc] | [prev] | [next] | [standalone]

#148272

>> Challenge: modify the program to allocate the memory via a VLA. 
>> Naturally it will fail on smaller numbers, but it needs to report
>> a failure, then proceed to the next value. Not just crash out.
> 
> That's a stupid experiment. alloa() is used for small allocations
Eh, VLAs, but that's almost the same issue.
> and the success isn't checked just as less as the stack-depth with
> recursive functions.

[toc] | [prev] | [next] | [standalone]

#148228

On Wednesday, November 13, 2019 at 8:53:19 AM UTC-3, Bart wrote:
> On 13/11/2019 09:57, David Brown wrote:
> > On 13/11/2019 04:01, Keith Thompson wrote:
> >> Barry Schwarz <schwarzb@delq.com> writes:
> >> [...]
> >>> Not many compilers support VLAs.
> >> [...]
> >>
> >> Is that true?  Visual Studio doesn't, but in my experience most
> >> (other?)  modern C compilers do.
> >>
> > 
> > I thought MSVC was moving, or had moved, to clang for C compiling?
> > Someone who uses MS tools could tell us.

It can be used optionally with clang as front end.
(The MS C compiler now supports compound literals at least.)

> > C99 is 20 years old.  A C compiler can't call itself "modern" if it
> > doesn't support VLA's.
> > 
> > Even tcc supports VLA's quite happily.
> > 
> 
> I don't support VLAs. For one because I don't agree with the feature 
> (imagine using a function like malloc for a memory pool 0.1% of the size 
> of what is available to malloc, but with no way to check the result).
> 
> But also because it's quite complex to implement. Even though most uses 
> of it are straightforward, you have to deal with all the fiddly bits 
> that C allows (where a VLA is defined deep inside a type; the expression 
> that gives the size changes value, but sizeof() has to return the 
> original; and the VLA (or a dozen VLAs with 2-3 dimensions each) is 
> repeatedly allocated and deallocated inside a nested block and inside a 
> loop, with gotos all over the place).
> 
> (I know you think is it straightforward, when it was discussed in depth 
> a few years ago on the 'std' group. But then you seem to think 
> everything is.)

If VLA have some fallback for malloc then the C compiler needs
some internal destructor (like C++).

In this case, other features could be added with the same 'cost' for the implementers like adding defer.

Apart of that we also have the behavior of sizeof of and other constrains
that only VLAs impose.

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.c

csiph-web