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).