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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d17561d7e5eba62c X-Google-Attributes: gid103376,public From: claveman@inetworld.net (Charles H. Sampson) Subject: Re: An alternative to Unchecked Conversion Date: 1999/12/20 Message-ID: <1e33lub.2zcr15jx4fayN%claveman@inetworld.net>#1/1 X-Deja-AN: 563001693 References: <38596575_4@news1.prserv.net> <3859701a@rsl2.rslnet.net> X-Trace: newsfeed.slurp.net 945699839 209.132.125.155 (Mon, 20 Dec 1999 08:23:59 CDT) User-Agent: MacSOUP/2.4.2 NNTP-Posting-Date: Mon, 20 Dec 1999 08:23:59 CDT Newsgroups: comp.lang.ada Date: 1999-12-20T00:00:00+00:00 List-Id: Tom Hargraves wrote: > Oops. Excuse my English. I meant to express the opinion that > Unchecked_Conversion _need_ rarely if ever be used, in 'normal' programming > practice. So I think we are in agreement here. Why disable one of the best > features of Ada if you don't need to :-) > > I welcome comments re. the technical merits of address mapping vs. > unchecked_conversion. For me address mapping worked fine, whereas > unchecked_conversion did a lot of additional data copying. So that's why I > didn't use it. What did I loose? I missed the beginning of this thread, although I was participating in the other one. Coming to in a few day late, I'm surprised to see that no one has mentioned what I consider the primary shortcoming of overlaying, the shortcoming that puts it into my personal list of for- bidden features. Overlaying is one of those features that is very easy to write and to get working "just as wanted" with little difficulty. The problem with it comes during maintenance and that problem is that modification of one of the participants changes the values of the others. It takes very little time after the overlay has been created for even the creator to forget about it and the maintenance programmer doesn't even have the luxury of forgetting. All he knows is that for some reason the value of a variable is wrong and, as he reads the code, he can't see where the incorrect value is being assigned. Of course, there are some techniques that reduce this problem. If a maintainer's environment supports a "find all references" capability, then one of those references will be any overlay statements, leaving him with the job of running down all modifications of the other partici- pants. Some debugging environments allow monitoring, to catch vari- ables the moment they change. Unfortunately, unless you have a hardware assist, monitoring can immensely slow down execution--not very useful in a real-time program in particular. Because of this, because of the amount of time I've spent over a long career running down problems caused by overlaying, I'll not use it unless absolutely necessary. I'll use UC in preference, even in the rare cases when memory copying is involved, unless it can be shown that this causes an unacceptable execution penalty. On the other hand, I would be against forbidding overlaying in a programming standard. My preference would be to allow use only after justification and approval. Charlie To get my correct email address, replace the "claveman" by "csampson" in my fake (anti-spam) address.