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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: OO, C++, and something much better! Date: 1997/01/13 Message-ID: #1/1 X-Deja-AN: 209489308 sender: news@syd.csa.com.au x-nntp-posting-host: dev50 references: organization: CSC Australia, Sydney reply-to: donh@syd.csa.com.au newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-13T00:00:00+00:00 List-Id: 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