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.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: A bad counterintuitive behaviour of Ada about OO
Date: Tue, 05 Aug 2014 21:58:41 +0100
Organization: A noiseless patient Spider
Message-ID: <lyiom6psam.fsf@pushface.org>
References: <lrrdm1$u6n$1@speranza.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="c27d95ddf365c2aa748a7ec17a81943e";
	logging-data="7316"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/X2JWYkyc0LjXS5Ka6gj+Q7hWbuEz3Kfw="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:Np74mBLyaSCbP/pC5PUvwZYxroI=
	sha1:wlZQkvqIhi6ws8F2ps3jYXEzOks=
Xref: news.eternal-september.org comp.lang.ada:21462
Date: 2014-08-05T21:58:41+01:00
List-Id: <comp.lang.ada>

Victor Porton <porton@narod.ru> writes:

> http://freesoft.portonvictor.org/binaries/ada-obj-test.tar.gz
>
> contains a tiny Ada program which prints 0 despite intuition suggests that 
> it should print 123, because it just copies (using Adjust) an object holding 
> 123.
>
> In this program Handle_Type models some handle provided by an external API, 
> where 0 is an undefined handle. Base_Object is a tagged record which holds a 
> handle inside itself and can copy or destroy the handle automatically (as 
> Base_Object is a controlled object).
>
> Example_Record is a derived type of Base_Object which imitates a behavior of 
> a simple library which operates over some handles. For example, in this 
> example copying a handle preserves it unchanged.
>
> This tiny program was created by me as a model of my real Ada bindings for 
> Raptor C library, which produces a wrong behavior.
>
> Why Ada behaves in this counter-intuitive way?
>
> What should I do in similar situations when developing real Ada software?

I think what is happening is that in

   function From_Handle(Handle: Handle_Type) return Base_Object is
   begin
      return (Ada.Finalization.Controlled with Handle=>Handle);
   end;

the aggregate is created and copied to the function's result as a
Base_Object, so that when

   procedure Adjust(Object: in out Base_Object) is
   begin
      if Object.Handle /= 0 then
         Object.Handle := Copy_Handle(Base_Object'Class(Object), Object.Handle);
      end if;
   end;

is called during the copy,

   function Copy_Handle(Object: Base_Object; Handle: Handle_Type) return Handle_Type is
   begin
      return 0;
   end;

returns 0, as you've seen.


(1) If all you wanted to do was copy the Handle over, you don't need to
do anything, because that's the default behaviour (i.e., copies the
bits).

(2) Normally, From_Handle wouldn't be inherited, so you'd have had to
write your own; because Example_Object has a null extension, it can be
inherited.