From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 19 Dec 1992 19:41:56 GMT

In article <1992Dec16.215251.1382@netcom.com> erc@netcom.com (Eric Smith) writes:
>In article <1992Dec16.145444.2130@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
>>In article <1992Dec15.172057.6793@borland.com> pete@borland.com (Pete Becker) writes:
>>
>>By coincidence, I am working on a list-management module, that includes
>>Lists, Queues, Stacks, and several other types.
>>
>>I am using a linked-list as the base structure, with auxiliary pointers to
>>allow circular access, size limits, etc.  To make the list a Stack, I
>>simply do this:
>>
>>#define Push(list,element) AddElementToEnd(list,element)
>>#define Pop(list) RemoveElementFromEnd(list)

	Naughty.

>>
>>where AddElement... and RemoveElement... are generic linked-list functions.

	Why not just have List::AddElement(T element, int position)?
Then you can insert in the middle of the list too.

>>
>>For a Queue, I do this:
>>
>>#define Enqueue(list,element) AddElementToEnd(list,element)
>>#define Dequeue(list) RemoveElementFromFront(list)
>>
>>Thus, they have the 'same' interface, in the generic functions, using the same
>>data structure(s), and if I decide that the program need a queue instead of
>>a stack, all I need to do is change the Push() calls to Enqueue() calls, and
>>so on.
>>
>>If I need a fixed-size container, mimicking an array, I have functions to
>>treat a linked-list as a fixed length container, with all the same data
>>structures, and minimal changes need to be made to the surrounding code
>>to dal with the possible error conditions that a fixed size container will
>>cause over a dynamic one.
>>
>There are two major problems with doing it that way.  First, it uses
>more memory than it needs to, and in some cases that can be very
>costly.  

>unidirectional linked list.  The 2nd problem is when you use a linked
>list to mimick an array.  One important use for arrays is random
>access.  You can't do random access in a linked list.  (By random
>access I mean the speed of accessing an element can't depend on which
>element it is.)  

	Wrong. You can do it, I do, and I use *singly* linked lists.
(Well, there's just a little bit added to them to make it fast :-)

>need it on getting data out of the container.  For those applications,
>you can use an array that reallocates itself when it needs to grow.

	This is horribly inefficient too sometimes. (I do this
for my string class though)

>But if you need bidirectional random access, you have to allocate the
>entire maximum size in advance.

	There are NO 'you have to .. ' cases surely, even if
I give some myself now and then :-) And allocating fixed maximums
is one of the things we want to avoid completely except in truly
extreme cases.

>
>container classes for widely varied high quality software.  Instead,
>the container classes should use different implementations for
>different purposes, 

	Yes. The Borland BIDS classes are an at least
half-way reasonable example of this.

But I think you missed the most important problem, and that
was the very naughty use of #define. This is NOT the nice
way to create a new abstraction, since it doesnt
restrict one from Dequeing an object from a Stack.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc