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,FREEMAIL_FROM
	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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: Victor Porton <porton@narod.ru>
Newsgroups: comp.lang.ada
Subject: Re: A bad counterintuitive behaviour of Ada about OO
Date: Wed, 06 Aug 2014 00:06:10 +0300
Organization: Aioe.org NNTP Server
Message-ID: <lrrgvu$6mh$1@speranza.aioe.org>
References: <lrrdm1$u6n$1@speranza.aioe.org> <lyiom6psam.fsf@pushface.org>
NNTP-Posting-Host: AnnUDmZwVERVUXyHDyOl5A.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: abuse@aioe.org
User-Agent: KNode/4.12.4
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:21465
Date: 2014-08-06T00:06:10+03:00
List-Id: <comp.lang.ada>

Simon Wright wrote:

> 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.

I've added in example_record.ads:

   function From_Handle(Handle: Handle_Type) return Example_Object;

and in example_record.adb:

   function From_Handle(Handle: Handle_Type) return Example_Object is
   begin
      return (Base_Object'(From_Handle(Handle)) with null record);
   end;

It prints "0" not as it was before.

So this does not help.

What to do? I write a real software project and need to make a decision what 
to do in this situation.

Please help.

-- 
Victor Porton - http://portonvictor.org