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,efe03f20164a417b X-Google-Attributes: gid103376,public From: bill@valiant.gmrc.gecm.com (R.A.L Williams) Subject: An observation of Ada (may offend) Date: 1995/03/29 Message-ID: <3lbkpv$iqv@miranda.gmrc.gecm.com>#1/1 X-Deja-AN: 100540703 organization: GEC-Marconi Research Centre newsgroups: comp.lang.ada Date: 1995-03-29T00:00:00+00:00 List-Id: In article <1995Mar17.144930@lglsun.epfl.ch> Robb Nebbe wrote: : In article <3kbkm1$41o@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com (R.A.L Williams) writes: : ... : |> b. No bit level manipulation (fixed in Ada95 but only for unsigned : |> ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL. : It is trivial to write a generic package providing bit manipulation on : arbitrary integer types in Ada 83. What do you mean? One approach is to hack something together, ie. shift implemented as multiply/divide, and implemented as something very complex involving subtraction etc. (unpleasant) The other approach is to define BIT a derived type of INTEGER, WORD as an array of BIT's and use a representation clause to try to force this down to one bit per 'bit'. The trouble with this is that there is no natural coversion to/from integer. Another problem may be that not all compilers (at least the last time I used Ada 83) actually *implement* representation clauses. They're all meant to check them syntactically, but this is an implementation dependent feature. Have I forgotten something? Is there another approach? : I would expect that it would usually be more appropriate to check if : a value was < 0 rather than checking the sign bit but I'll assume you : had a good reason. No, that was just an example - I don't dee many situations where I'd do that. : |> : |> h. And a special one for Ada95: poor encapsulation of objects. I can : |> define a 'member function' for a class by including the class in the : |> parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code, : |> even a nested function hidden somewhere seemingly 'irrelevant'. Whereas : |> other features of Ada go out of their way to force the programmer to : |> follow 'good practice' (sometimes a matter of opinion), this seems : |> very lax. : If you declare a private type then the only place you can see the : implementation is from inside the package where the type is declared : (or a child package). You can declare subprograms that have parameters : of this type elsewhere but that certainly doesn't qualify as a 'member : function'. : The idea you are looking for is 'primitive operations' which a : explained in the LRM. Yes, mea culpa. I got this entirely wrong. I must RTFM before activating fingers in the future! : Robb Nebbe Bill Williams