Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!howland.erols.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!syd.csa.com.au!news
From: donh@syd.csa.com.au (Don Harrison)
Subject: Re: OO, C++, and something much better!
X-Nntp-Posting-Host: dev50
Message-ID: <E3xqqp.4uA@syd.csa.com.au>
Sender: news@syd.csa.com.au
Reply-To: donh@syd.csa.com.au
Organization: CSC Australia, Sydney
References: <dewar.852851538@merv>
Date: Mon, 13 Jan 1997 07:13:37 GMT
Lines: 51
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:239992 comp.lang.smalltalk:48987 comp.lang.eiffel:17317 comp.lang.ada:55937 comp.object:59732 comp.software-eng:52462

Robert Dewar writes:

:I have been trying to think of a safe way of doing this sort of thing but
:thus far haven't thought of any. :)"
:
:
:Well there obviously is no safe way of doing something whose entire purpose
:is to allow unsafe operations!

Yes, these mechanisms are inherently unsafe but their purpose is to allow 
different views of the same data. There are different ways of acheiving 
that and some ways are safer than others. For example, UNCHECKED_CONVERSION 
is safer than overlaying because the data is copied thus protecting the 
original object.

As you suggest, there's no completely safe scheme of allowing alternate
views.

:Still I would not characterize these as "type casting" in Ada. Rather I 
:would think of them as loopholes, equivalent to calling a C or assembly
:routine. Any formal analysis or discussion of the type system of Ada
:has to ignore these features, and of course any real language to be used
:for low level systems programming needs such features, but I don't think
:it is a useful excercise to include these features in the type analysis.
:
:If you like, consider Ada *minus* these two features as the interesting
:language to be analyzed. Then understand that in real life programs can
:break the bounds of this analysis to the extent they need to.

Agree.

:Note that it is not actually the unchecked conversion that is nasty, since
:the fundamental conversion can be modeled as simply a random mapping between
:values of one type to values of another type. It is that these operations
:can generate abnormal values. 
:
:This may still not be a problem, given that uninitialized values can also
:be abnormal, thus:
:
:  a := nasty_unchecked_conversion (b);
:
:is no worse that not assigning to a at all if a is uninitialized.

True.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au


