Re: Multiple Inheritance in Ada 9X/Pointers?

Re: Multiple Inheritance in Ada 9X/Pointers?

[ub!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!elephant.cis.ohio-state.e]

In article <1992Jan06.185123.188@microsoft.com> jimad@microsoft.com (Jim ADCOCK
) writes:
>... in C++ pointers remain the greatest
>power and the greatest danger.  Perhaps we should be discussing doing away
>with pointers in C++ -- not MI !?
>
>1/2 ;-)
>

Not a bad idea!  How about discussing this question?  In Ada or C++,
say, it would be hard to do away with pointers without changing the
language :-) but what about a software discipline that says, "Don't
USE pointers."  Anyone else think it's worth discussing?

    -Bruce

Re: Multiple Inheritance in Ada 9X/Pointers?

[agate!tully.CS.Berkeley.EDU!hilfingr]

In article <1992Jan06.185123.188@microsoft.com> jimad@microsoft.com
(Jim ADCOCK) writes:

|> >Perhaps we should be discussing doing away
|> >with pointers in C++ -- not MI !?

to which, in article <1992Jan8.153857.26769@cis.ohio-state.edu>,
weide@elephant.cis.ohio-state.edu (Bruce Weide) responds:

|> Not a bad idea!  ... what about a software discipline that says, "Don't
|> USE pointers."

I don't think that is the right topic.  People often incorrectly
formulate the old structured coding doctrine as "don't use goto's",
whereas it was more properly seen as the POSTIIVE statement "use the
most appropriate control structure (which happens almost never to be
'goto')".  It is fair to say, I think, that use of the goto declined
markedly, even though there are few languages in which it has been
eliminated.

Here, likewise, the more interesting topic is "what dynamic data types
SHOULD we use for applications where we now use pointers?"

A related comment and question: The statement "pointers are a (the
most) dangerous feature in ..." is part of that portion of the folk
wisdom that I most distrust---the plausible but untested (and often
unexamined) broad claims that tend to get chorused by all us
educators.  Can anyone point me at good empirical studies of the
frequency of errors in real code produced by experienced programmers
that are caused by, e.g., using pointers instead of something more
appropriate?  Studies that show that, e.g., X% of errors are pointer-
related or Y% of debugging time is spent tracing pointer-related
errors are useful, but not completely satisfactory, since they lack
controls (where would the errors be using alternative data
structures).
 
-- 

Paul N. Hilfinger, Associate Professor		(510) 642-8401        
Computer Science Division			Hilfinger@CS.Berkeley.EDU
Dept. of Electrical Engineering and Computer Sciences
University of California
Berkeley, CA  94720

Re: Multiple Inheritance in Ada 9X/Pointers?

[micro-heart-of-gold.mit.edu!wupost!zaphod.mps.ohio-state.edu!cis.ohio-sta]

In article <kmmlhbINNmqt@agate.berkeley.edu>
hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
>
> [... stuff about pointers and go-to statements ...]
>
>Here, likewise, the more interesting topic is "what dynamic data types
>SHOULD we use for applications where we now use pointers?"
>


Yes, this is (part of) the question I was proposing for discussion.
Thanks to Paul for phrasing it differently.  Let me try again: "What
abstractions should we use to replace pointers?"

Another part of the question is something like, "What useful
abstractions require direct use of pointers for their (efficient)
implementation?"

Yet another is, "What useful abstractions require CYCLIC pointer
structures for their (efficient) implementation?"  (This variation is
related to the recent questions about the claimed need for garbage
collection in any "real" language.)


To give you an idea of a possible approach to answering Paul's
question, consider a list ADT.  This is an example of a "dynamic data
type" where most people now use pointers.  The problem is not so much
that pointers are involved in the representation of a list, but that
the functional specification of the list ADT usually lets these
pointers "stick out" so the client has to be aware of them.  (This is
true even for list designs in languages that don't inherently involve
pointers; e.g., consider Booch's list package for Ada.)

What I'd argue for is that, if pointers must be used in the
representation of some abstraction, then at least this fact should not
be discernible to the client of that abstraction.  If this is possible
(it is), then the uses of pointers may be buried deep in the bowels of
a software system, where (perhaps) they can be kept under control.
The pointers need not percolate all the way up to higher-level
abstractions.  In fact, they need not percolate up at all unless there
are some useful high-level abstractions that simply cannot be
implemented efficiently without direct use of pointers.  (Notice that
an abstraction whose representation is simply based on a list ADT does
NOT directly use pointers, in this situation.  The code that uses the
list knows nothing about the pointers that are used in the list
representation.)

    -Bruce

Re: Multiple Inheritance in Ada 9X/Pointers?

[Paul Barton-Davis]

In article <1992Jan8.225611.3226@cis.ohio-state.edu> weide@elephant.cis.ohio-st
ate.edu (Bruce Weide) writes:
>In article <kmmlhbINNmqt@agate.berkeley.edu>
>hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
>>
>> [... stuff about pointers and go-to statements ...]
>>
>>Here, likewise, the more interesting topic is "what dynamic data types
>>SHOULD we use for applications where we now use pointers?"
>>
>
> [ ...]
>
>To give you an idea of a possible approach to answering Paul's
>question, consider a list ADT.  This is an example of a "dynamic data
>type" where most people now use pointers.  The problem is not so much
>that pointers are involved in the representation of a list, but that
>the functional specification of the list ADT usually lets these
>pointers "stick out" so the client has to be aware of them.  (This is
>true even for list designs in languages that don't inherently involve
>pointers; e.g., consider Booch's list package for Ada.)
>
>What I'd argue for is that, if pointers must be used in the
>representation of some abstraction, then at least this fact should not
>be discernible to the client of that abstraction.  If this is possible
>(it is), then the uses of pointers may be buried deep in the bowels of
>a software system, where (perhaps) they can be kept under control.

I don't buy this for one moment. This whole concept is grounded in the
notion that you can partition software systems into "internals" and
"externals". Its true that if you choose carefully when you design the
interface to the "internals", you will affect the "externals",
hopefully for the better. However, IMHO it is totally absurd to
suppose that you can divide software into "places that are OK to use
pointers" and "places that are not". 

-- paul



-- 
"Been there, done that
 Been there, don't wanna go back"
				John Cale & Brian Eno, "Wrong Way up"

Re: Multiple Inheritance in Ada 9X/Pointers?

[bu.edu!rpi!zaphod.mps.ohio-state.edu!caen!uvaarpa!software.org!blakemor]

In article <1992Jan8.153857.26769@cis.ohio-state.edu> weide@elephant.cis.ohio-s
tate.edu (Bruce Weide) writes:
>In article <1992Jan06.185123.188@microsoft.com> jimad@microsoft.com (Jim ADCOC
K) writes:
>>... in C++ pointers remain the greatest
>>power and the greatest danger.  Perhaps we should be discussing doing away
>>with pointers in C++ -- not MI !?

> what about a software discipline that says, "Don't
> USE pointers."  Anyone else think it's worth discussing?

no, that would hurt more than it would help.
just dont ABUSE pointers.

P.S. the strong typing in Ada along with the inability to do pointer
arithmetic avoid many of the nastier problems pointers can create
-- 
---------------------------------------------------------------------
Alex Blakemore           blakemore@software.org        (703) 742-7125
Software Productivity Consortium  2214 Rock Hill Rd, Herndon VA 22070

Re: Multiple Inheritance in Ada 9X/Pointers?

[mole-end!mat]

In article <1992Jan8.225611.3226@cis.ohio-state.edu>, weide@elephant.cis.ohio-s
tate.edu (Bruce Weide) writes:
> In article <kmmlhbINNmqt@agate.berkeley.edu>
> hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
. . .
> >Here, likewise, the more interesting topic is "what dynamic data types
> >SHOULD we use for applications where we now use pointers?"
 
> Yes, this is (part of) the question I was proposing ...  Let me try again:
> "What abstractions should we use to replace pointers?"

> Another part of the question is something like, "What useful abstractions
> require direct use of pointers for their (efficient) implementation?"

Another useful question is ``How can we mitigate the whatever danger arises
from pointers?''
 
 . . .

> ... I'd argue ... if pointers must be used in the representation of some
> abstraction, then at least this fact should not be discernible to the
> client of that abstraction.  ...  then the uses of pointers may be buried
> deep in the ... software system, where ... they can be kept under control.
> The pointers need not percolate all the way up to higher-level
> abstractions.  ...

Here's a question: how many uses of pointers (or unchecked array bounds,
which are nearly as dangerous) can be stereotyped?  How many of those can
be written as templates, to be coded once, gotten right, and never coded
again?  Yes, that's what they said about subroutines, but they didn't
realize that the world is made of more than integers.

Other measures are possible: `pointer' types that MUST be initialized,
indexing types whose values can only be created by functions under control
of whoever `owns' the data structure, &c.

It will probably be easier to do these things for the elements of code that
derive from --programming-- technology, not those that derive from features
of the problem or the subject matter.  (But --code-- that derives from
subject matter libraries is a mixture of problem-specific and code-specific
features.)  I can't speak for features that derive from the environment or
resources surrounding the program.

Of course, whomsoever codes the AVL or 2-3 or Lempel-Ziv templates had
better get them right--and whomsoever codes them as anything but templates
is a selfish, shortsighted wastrel, not unlike those who burn rainforest
to get 1-year cropland.  (My opinion, I know, so flame gently please.)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end, Somewhere in Matawan, NJ

Re: Multiple Inheritance in Ada 9X/Pointers?

[Jean-Pierre Rosen]

Two main usages of pointers in computer languages are:
1- to build dynamic structures.
2- to allocate structures whose precise size is not known at compilation time.

In Ada, usage #2 tends to disappear thanks to unconstrained array types and
discriminated records, since dynamically sized structures can now be allocated
on the stack. Usage #1 of course still remains, but it is my *unmeasured* 
feeling that usage #2 was most often the reason for using pointers. You should
therefore expect pointers to be much less frequent in Ada than in other
languages.

Of course, Ada lets you easily hide that a structure is implemented by pointers
into the depth of a package body, provided you distinguish between Abstract
data types with object semantics and those with value semantics. On the other
hand, I can't imagine how you could effectively do that in C/C++: the ultimate
representation "percolates" all the way to the end user. For example: can you
imagine you can explain someone the behaviour of strings in C/C++ without
mentionning that a string is nothing but a pointer to character?

Re: Multiple Inheritance in Ada 9X/Pointers?

[Guido van Rossum]

rosen@cyclope.enst.fr (Jean-Pierre Rosen) writes:
>Of course,Ada lets you easily hide that a structure is implemented by pointers
>into the depth of a package body, provided you distinguish between Abstract
>data types with object semantics and those with value semantics. On the other
>hand, I can't imagine how you could effectively do that in C/C++: the ultimate
>representation "percolates" all the way to the end user. For example: can you
>imagine you can explain someone the behaviour of strings in C/C++ without
>mentionning that a string is nothing but a pointer to character?

True for string meaning "char*", but that's inherently a low-level
concept in C++.  You can easily implement a string class with either
object or value semantics.

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"All right, it's a fair cop, but society is to blame."