Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Dynamic multidimensional arrays Message-ID: <8099@brl-smoke.ARPA> Date: 16 Jun 88 08:13:46 GMT References: <10655@agate.BERKELEY.EDU> <1857@hubcap.UUCP> <10023@ames.arc.nasa.gov> <10032@ames.arc.nasa.gov> <59@cubsun.BIO.COLUMBIA.EDU> <4556@haddock.ISC.COM> <3365@ut-emx.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 In article <3365@ut-emx.UUCP> jjr@ut-emx.UUCP (Jeff Rodriguez) writes: >In article <4556@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >>If you allocate the entire array (including space for the pointers as well as >>the contents) in a single chunk, then you don't need all those free_array() >>routines -- the standard free() will work. I've written it this way. > >Quite true. Another benefit is that the one can use one call to fread() >to read a binary image from a file directly into one of these arrays. >If each row is allocated with a separate call to malloc(), then the >resulting array must be filled one row at a time. Karl's point is that the "row vector" can be contiguous with the MxN data area. That is indeed a nice idea, and I think I'll change some of our applications to do this. fread() can fill the data area, but then people like me who've been allocating separate row vector and MxN data areas could have done that anyway. Separate allocations for each row really would be pretty dumb, unless several rows might be unneeded (I have an application like that, too).