- alloca()-support - 22 Updates
- Best book to learn C++11 and C++14? - 3 Updates
| David Brown <david.brown@hesbynett.no>: Sep 30 04:56PM +0200 On 30/09/2019 16:33, Anton Shepelev wrote: >> the program to function as required. > Reliance on compiler features puts the same fetters on free > and commerical code. The great majority of C and C++ programs are dependent on features that are limited to specific target processors, compilers, and/or OS's. Some programs are written in a way to minimise these dependencies, or at least to isolate them in a small number of files. For many other programs, it really doesn't matter - the code will only be used with one compiler or on one target. And some features are non-standard but found on many compilers - alloca() is one of these. If you are using a serious compiler, it will support alloca(). Your alloca() code might not work on a tiny microcontroller, or on a toy compiler like TCC, but it is highly likely that a lot more of the code will have trouble there too. > You misunderstood my usage of "no longer". I meant that > once you start using alloca() your program is no longer > standard C. It is, I believe, extremely unlikely that use of alloca() will be the deciding factor for which compilers can be used with the code. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Sep 30 03:29PM > `alloca(I)' worth it? Is not there a reasonably simple > solution within standard C, such as an array, a variable- > length array, or a pre-allocated memory block on the heap? VLA elliminates need for alloca... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bo Persson <bo@bo-persson.se>: Sep 30 05:29PM +0200 On 2019-09-30 at 16:09, Bonita Montero wrote: >> I'm curious, can you give an example of where you'd use this? > At a point where I did know I needed only a small variable sized array > of pointers. If it is a *very* small number, you might of course always allocate the upper limit (like 10), and just use the 5-7 needed by a specific invocation. If the upper limit is significantly larger, the stack usage might make alloca() less than 100% portable anyway. Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 05:31PM +0200 Am 30.09.2019 um 17:29 schrieb Melzzzzz: >> solution within standard C, such as an array, a variable- >> length array, or a pre-allocated memory block on the heap? > VLA elliminates need for alloca... C++ hasn't VLAs. I only want to discuss this issue in both groups as this is a special compiler-specific problem. A compiler that supports C++ also usually compiles C-code. And if it supports alloca() it supports it in both languages. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 05:33PM +0200 > If it is a *very* small number, you might of course always allocate > the upper limit (like 10), and just use the 5-7 needed by a specific > invocation. No, the limit is higher, at most about 100 pointers. > If the upper limit is significantly larger, the stack usage might > make alloca() less than 100% portable anyway. The code I write is not for Arduinos. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 06:04PM +0200 I just came across another issue: With my primary compiler theres's an internal function called __chkstk called when I do alloca. This function is usually called when there are more than a page full of variables in the stack-frame. That's because Windows recognizes the need for more stack space only through touching the next unmapepd page down the stack. So why hasn't MS so be so clever as to design Windows that it would also recoginize noncontignous acces- ses to the stack-pages? Are these pages handled are like being over- comitted? |
| gazelle@shell.xmission.com (Kenny McCormack): Sep 30 04:26PM In article <e2720f0b-ca77-4e65-be10-8179a49f9cbc@googlegroups.com>, >> ming-language. But I use it for performance-reasons. Can anyone name >> compilers that don't support alloca()? >I'm curious, can you give an example of where you'd use this? I think "man alloca" covers this well enough. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Infallibility |
| Anton Shepelev <anton.txt@g{oogle}mail.com>: Sep 30 05:30PM +0300 Bonita Montero: >Depending on the set of compilers that support `alloca()' >this doesn't count. I disagree. It is a difference between standard code and compiler-dependent code. You are forcing users to use specific compilers, regardless of how large a subset it is. >And usually you have dependencies on functions becond those >of standard-C/C++ anyway. Those dependencies are available as C code or libraries, whereas `alloca()' is not and cannot be. >>Are the benefits of `alloca(I)' worth it? >Yes, alloca() is fast. I didn't say it wasn't, but suggested that you consider a fast solution in standard C. By the way, have you made certain that dynamic memory allocation would be the bottleneck of your algorithm? >>C, such as an array, a variable-length array, or a pre- >>allocated memory block on the heap? >VLAs aren't part of C++ -> You have written to comp.lang.c too. >-> and heap-allocations haver a magnitude higher cost. I proposed to reuse the same heap block in many invocations of your functions. Sometimes it is possibe. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| scott@slp53.sl.home (Scott Lurndal): Sep 30 02:30PM >`alloca()' is no longer starndard C and depends on specific >compilers, which harms the freedom of the users of your code >to compile it with *any* C compiler. Good grief. 90% of all C code isn't open source and the programmer is free to use whatever features necessary for the program to function as required. And, FWIW, alloca() has never been "starndard" C. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 06:48PM +0200 On 30/09/2019 14:02, Bonita Montero wrote: > ming-language. But I use it for performance-reasons. Can > anyone name > compilers that don't support alloca()? sorry, mine is not an answer but a related question Since when (if at any time) was variable size automatic array supported ? I mean a temporary array local to a function whose size becomes known only at runtime (seems to me a generalization of variadic functions, which, too, does not know at compile time how much stack space will consume). If implemented, It seems equivalent to alloca () ... is it there some limitation then in ORDER of automatic variable creations ? I mean, im my simple mind I'd guess such variable size should follow all "sure" (known sized) variabiles and not to exceed one single dynamic sized variable (or at least to avoid strange and heavy overhead in access, not just _ESP, _EBP) a single variable array on stack with no further variables does not seem that difficult to implement, or am I wrong ? -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 06:51PM +0200 > Since when (if at any time) was variable size automatic array supported ? Since C99. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 06:55PM +0200 On 30/09/2019 18:51, Bonita Montero wrote: >> Since when (if at any time) was variable size automatic >> array supported ? > Since C99. for curiosity, this feature has one or more of the limitations I feared ... or even none of them ? -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 06:58PM +0200 >> Since C99. > for curiosity, this feature has one or more of the limitations I feared > ... or even none of them ? Yes, you could run out of stack-space, maybe hitting a guard-page in the best case so that you wouldn't corrupt any other data. |
| Philipp Klaus Krause <pkk@spth.de>: Sep 30 07:14PM +0200 Am 30.09.19 um 18:51 schrieb Bonita Montero: >> Since when (if at any time) was variable size automatic array supported ? > Since C99. And C99 is the only version where support for them is mandatory. As of C11, they are optional. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 07:16PM +0200 >> Since C99. > And C99 is the only version where support for them is mandatory. > As of C11, they are optional. And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs are not supported. |
| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Sep 30 11:20AM -0600 > consume). > If implemented, It seems equivalent to alloca () ... is it there some > limitation then in ORDER of automatic variable creations ? There is no such limitation on your C program. The VLA can be first, last, or in the middle. And you can have more than one of them. Where in the activation record a compiler chooses to put it is, AFAIK, not specified. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 07:42PM +0200 >> limitation then in ORDER of automatic variable creations ? > There is no such limitation on your C program. The VLA can be first, > last, or in the middle. And you can have more than one of them. alloca() can be called at almost any point in a function (with some compilers not within a function-call). |
| scott@slp53.sl.home (Scott Lurndal): Sep 30 05:52PM >> Since when (if at any time) was variable size automatic array supported ? >Since C99. Albeit available pre-C99 standardization in several compilers. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 07:53PM +0200 On 30/09/2019 18:58, Bonita Montero wrote: > Yes, you could run out of stack-space, maybe hitting a > guard-page > in the best case so that you wouldn't corrupt any other data. uhm, I didn't mean THAT kind of risk (unavoidable), but the possible difficulties in defining variables beyond the point of declaration of the variable-size array. I can't figure out how the compiler would reference them in standard efficient ways (use of registers). Anyway, the difference with alloca () would be in a safer management of possible collisions and running out of stack space ? (compared with the plain declarations) ? -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 07:54PM +0200 On 30/09/2019 19:20, Joe Pfeiffer wrote: > last, or in the middle. And you can have more than one of them. > Where in the activation record a compiler chooses to put it is, AFAIK, > not specified. ah ! So you are suggestion sort of internal reordering on the stack (like : all known types before, then the var-sized) ? -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 08:01PM +0200 On 30/09/2019 19:20, Joe Pfeiffer wrote: > last, or in the middle. And you can have more than one of them. > Where in the activation record a compiler chooses to put it is, AFAIK, > not specified. I have QT that does not supports them, but, if sb would be so kind to copy a minimal asm generated code for some int Funz (int A, int B) { int C = 3; int Buf [A]; int D = 2; Buf [A-1] = B; return (A + B * D - C); } int main (void) { return Funz (4, 3); } I'd like to examine the assembler generated in order to figure out how Buf (and D, beyond it apparently) are addressed ah, if not to annoying, TURNING OFF most if not all optimizationz (maybe the example is too minimal to be sort of resolved at compile time :\) tnx in advance -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Sep 30 08:02PM +0200 On 30/09/2019 19:42, Bonita Montero wrote: > alloca() can be called at almost any point in a function > (with some > compilers not within a function-call). I've not clear what differences there are in alloca () usage vs plain declaration, then .... -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 03:06PM +0200 >> Thanks! I found it online. > It's funny how casually people just admit to their illegal piracy of > intellectual property. https://www.google.com/search?client=firefox-b-d&q=%22Effective+Modern+C%2B%2B%22+doctype%3Apdf ;-) |
| David Brown <david.brown@hesbynett.no>: Sep 30 03:30PM +0200 On 30/09/2019 14:32, Frederick Gotham wrote: >> It's funny how casually people just admit to their illegal piracy of >> intellectual property. > Is piracy theft? Is it stealing? Yes, piracy is theft (and therefore stealing). But copyright abuse is not piracy, nor is any unlicensed use of intellectual property. (To be "theft", you have to take something away from the rightful owner, so making a copy is not theft.) However, accurate terms such as "unlicensed copyright abuse" do not sound as dramatic as "piracy". Not that there was any suggestion of copyright abuse here - Queequeg (presumably) found a legitimate website selling the book. |
| queequeg@trust.no1 (Queequeg): Sep 30 02:47PM >> It's funny how casually people just admit to their illegal piracy of >> intellectual property. > Is piracy theft? Is it stealing? Fun fact: in my jurisdiction, downloading music, movies or ebooks is completely legal. Only sharing (therefore, downloading with torrents qualify) is not. For some reason it's different only with computer programs and games. -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment