Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: local arrays and stack |
| Date | 2015-03-25 16:07 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <meumeh$3pd$1@dont-email.me> (permalink) |
| References | (13 earlier) <46c41165-11a3-4c8e-8097-6747e5177442@googlegroups.com> <meq3lh$tju$1@dont-email.me> <meran6$epa$1@dont-email.me> <merf4a$uam$1@dont-email.me> <merksa$ko5$1@dont-email.me> |
On 24/03/2015 12:22, David Brown wrote: > On 24/03/15 11:44, Bartc wrote: >> Suddenly, heap-allocated VLAs don't seem such a bad option! > > Yes, they /are/ a bad option unless they are what the /user/ asks for in > their source code. > > Of course, it is generally considered good programming practice to > allocate large objects on the heap rather than the stack, but it should > be the programmer who decides. No. The programmer just writes this: int array[N]; without needing to know where the space is going to come from. That might be from the main hardware stack, from the main heap, or some combination as I suggest below. >> And because of the problem of crashing, VLAs can't be too big. In which >> case, just allocate a generous /fixed/ array. > > VLAs do not take any more or less space than a fixed-size array of the > same size, and they go in the same area (stack, heap, or static memory > according to how they are defined in the source code). With a fixed-size array imposing an upper limit, the behaviour of a bit of code is going to be more predictable. But you will have to think about that happens if you actually need a considerably larger size. Suppose a function has input consisting two strings of given lengths M and N, and it needs to concatenate them into a composite work string of length M+N before any further processing, then that composite string is discarded. It sounds very appealing to just define: char workstring[M+N+1]; except that M could be a million or a billion. (For this, I might use a 256- or 1024-char workstring when M+N is small enough, and use the heap for bigger strings. Most strings are going to be small. But the occasional massive one won't now crash the application. Well, unless it's really massive, but typically heap sizes are far bigger than stack sizes. Even then, there will be an opportunity to fail gracefully, or just to return an error code and continue.) >> It's one C feature I wouldn't bother with in a parallel language (and I >> haven't). >> > > I can't say I have had any real use of VLA's either. C++ does not > support them, and I don't think anyone feels the lack very strongly. I didn't know that C++ doesn't do C-style VLAs. However C++ allows you to apply custom construct/destruct handlers to certain kinds of objects, which presumably can also include allocating and deallocating space from a heap. In other words, just the sort of scheme I stated *could* be used to do C VLAs too, ie. the ones that no-one seems to use but go to some pains to point out how easy and efficient they would be if somebody did use them! And anyway the choice needn't simply be between putting a flat, packed array directly on the stack, or allocating it using malloc(). If the pattern of allocation is a nested style as it is for VLAs, then there's no reason why a fast stack-like allocator can't be used, implemented on heap memory. Then some of the inefficiences of malloc/free can be eliminated. But it wouldn't be /quite/ as crude as direct stack VLAs, because you will want to take advantage of the better out-of-memory handling that is now possible, and the easier possibility of expanding the available space as needed. -- Bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-22 01:51 -0700
local arrays and stack asetofsymbols@gmail.com - 2015-03-22 02:23 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:22 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:55 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-22 15:07 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:50 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 04:26 -0500
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 06:53 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 07:29 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:34 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:57 -0500
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:01 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:37 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:04 +0100
Re: local arrays and stack glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 17:29 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 20:01 +0100
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 08:24 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:42 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:07 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:15 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 09:16 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:34 +0000
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:12 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 17:44 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 11:47 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 12:06 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 20:25 +0000
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 14:10 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 22:22 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 23:57 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:28 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-24 10:44 +0000
Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 06:38 -0500
Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 09:57 -0500
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:22 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 16:07 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:42 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 19:06 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 12:26 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:20 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:28 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:45 +0100
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:50 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 22:33 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 23:57 +0100
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:42 +0100
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 09:55 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:36 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:04 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:52 +0100
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 15:18 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-26 00:02 +0100
Re: local arrays and stack Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:47 +0100
Re: local arrays and stack Mel <mel@zzzzz.com> - 2015-03-24 14:58 +0100
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-24 06:58 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 14:34 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:16 +0100
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 09:55 +0100
Re: local arrays and stack Noob <root@127.0.0.1> - 2015-03-24 10:23 +0100
Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:18 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-24 13:42 -0700
Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:47 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 09:32 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:57 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 10:37 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:49 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 12:48 -0700
Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 22:29 +0000
Re: local arrays and stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 19:03 -0400
Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 23:36 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 02:17 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 11:56 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 20:00 -0500
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:39 +0100
csiph-web