From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: Any research putting c above ada? Date: 1997/05/21 Message-ID: <338349BA.5FAF@dynamite.com.au>#1/1 X-Deja-AN: 242719996 References: <208C9C61CA05C32B.65D82DC950AAA33A.D68E7B27EB42E98A@library-proxy.airnews.net> <3372D44E.5F44@sprintmail.com> <337813DF.598C@dynamite.com.au> <337D3AE4.28F7@dynamite.com.au> <337E5854.1366@sprintmail.com> <12871CEBFAB00ABE.93483F73373D0261.D1086334F6EF8ED8@library-proxy.airnews.net> <3380F4A5.1EBB@sprintmail.com> Organization: @Home Reply-To: aebrain@dynamite.com.au Newsgroups: comp.lang.ada Date: 1997-05-21T00:00:00+00:00 List-Id: John G. Volan wrote: > Kevin Cline wrote: > > This is one of the biggest blind spots I observed in experienced Ada > > programmers in a shop a few years ago. Ada programmers tend to use arrays > > instead of more dynamic data structures, resulting in inefficient and > > inflexible applications. Agree strongly that Ada programmers tend to use (fixed size) arrays rather than more dynamic data structures. If you know that at some time you're going to need X items, and never will need more than X, then IMHO it's very wise to have a fixed-length table or other data storage area catering for the worst-case. Unless you're dealing with text, strings etc this is true 99% or more of the time (at least in the problem domains I've worked with for 15 years), and means you never have to worry about memory leaks, running out of heap space during run-time in an unpredictable way etc etc. But the "resulting in inefficient and inflexible applications" bit does not, as they say, neccessarily follow. Space innefficient - maybe. There is a case for that. But consider how much space you'll be using putting in all the checks on a dynamic structure, the memory fragmentation, the additional garbage collection load etc, so "it's not that simple". The brain-dead fixed-size array is actually very efficient for small and non-sparse arrays, which is the case most of the time (at least, in the problem domains I'm familiar with). As for inflexible - which is better, changing a single constant (and possibly seeing the resultant program not be loadable because there isn't enough space left) or making no change, no re-compile but having coredumps in whole new places due to memory leaks at run-time, even if there IS enough space? Which is easier to debug? The former. Which is easier to ship? The latter. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM 100026.2014 compuserve o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale See http://www.z-world.com/graphics/z/master/8856.gif for picture