Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!ucsd!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Conformant arrays-- how to?
Message-ID: <10188@smoke.BRL.MIL>
Date: 2 May 89 05:23:22 GMT
References: <4700036@m.cs.uiuc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <4700036@m.cs.uiuc.edu> kenny@m.cs.uiuc.edu writes:
>What are the pitfalls to avoid?  At first glance, it seems trivial to
>implement, but I suspect otherwise, since dmr didn't do it that way ...

I asked Dennis about this many years ago.  We seemed to agree that it
was "doable", but not quite trivial.  Unless you restricted the
facility to pointer parameters, which would seem a pity, the auto
storage allocation scheme would have to accommodate object sizes not
known at compiler time.  That isn't always simple to achieve.

There have been several library packages developed to support arrays
with dimensions determined at run time.  I think a recent C User's
Journal described the details of one such package.  It's not hard to
develop such a package, just a bit awkward to use one.  Similar
things could be said for complex numbers, group representations,
multiple-precision arithmetic, and so on.  C gives you enough hooks
to implement solutions for these needs, but it's often not as nice
as a built-in facility would be.  On the other hand, in contexts
where such applications are irrelevant, the C implementation is not
burdened by the necessity of supporting all the extra baggage.