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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,5e53057e86953953
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Question on initialization of packages
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <y4adnXtddsFN7crV4p2dnAA@telenor.com>
 <1pok6brk3yyxf$.ct5gwnf4g97p$.dlg@40tude.net>
 <KredncLZKqYOHcrVRVnzvQA@telenor.com>
Date: Tue, 17 Jun 2008 12:26:08 +0200
Message-ID: <y4z5e4d15092$.amkohfkfjm4v$.dlg@40tude.net>
NNTP-Posting-Date: 17 Jun 2008 12:26:08 CEST
NNTP-Posting-Host: 696148d4.newsspool3.arcor-online.net
X-Trace: 
 DXC=VEN7OlMkA>>nBOkdL^Lo7>McF=Q^Z^V384Fo<]lROoR18kF<OcfhCO;@fB:RIoWcI<[6LHn;2LCV>7enW;^6ZC`4IXm65S@:3>?0cfbaI19\:>
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:737
Date: 2008-06-17T12:26:08+02:00
List-Id: <comp.lang.ada>

On Tue, 17 Jun 2008 11:14:59 +0200, Reinert Korsnes wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 17 Jun 2008 10:07:43 +0200, Reinert Korsnes wrote:
>> 
>>> Question: How can I be sure that "Send_Stack" is empty
>>> at the start of the program execution ?
>> 
>> Hmm, "sure" in which sense? To make it visible for the reader? To specify
>> in the contract of Stack that it is initially empty?
> 
> Yes, yes, to make it visible for the reader.

I.e. you want to allow initially non-empty stacks? This does not look like
a good idea.

Anyway, if stack is non-limited, you could do something like

   type Stack (<>) is private;
       -- The box <> enforces object's initialization
   Empty : constant Stack; -- Initial value of an empty stack
   ...
private
   ...
   Empty : constant Stack := null;

then the user will be forced to do:

   Send_Stack : Stack := Empty;

However, I see no reason to have stack copyable in the first line.

>> As for implementation you posted, the stack is empty, because instances of
>> access types are initialized with null (when not explicitly initialized
> 
> Yes, but I do not like things depend on the particular implementation :-)

But this particular implementation fulfills the stack contract, which reads
"stack is initially empty." I see no problem here.

>>>   procedure Pop(S: in out Stack; X: out Item) is
>>>   begin
>>>     X := S.Value;
>>>     S := S.Next;
>>>   end;
>> 
>> This is a memory leak. If you allocated a stack element on push, you
>> should free it on pop.
> 
> How I free it?  I may not have a deep enough understanding here :-)

Per a call to instantiated Ada.Unchecked_Deallocation.

procedure Pop (S: in out Stack; X: out Item) is
   procedure Free is new Ada.Unchecked_Deallocation (Cell, Stack);
   Top : Stack := S;
begin
   if Top =null then
      raise Empty_Stack_Error;
   else
      X := Top.Value;
      S := Top.Next;
      Free (Top);
   end if;
end Pop;

BTW, you don't need to keep the stack depth in its items. Do it in the
stack object. Increment it on push and decrement on pop.

>> 3. Package initialization cannot help you here, because the package
>> declares an abstract data type of which objects can be created long after
>> the package itself was elaborated (initialized).
> 
> But I would like to make it clear for all that the stack is
> empty at the start of my program!

But your program starts even before package elaboration. At that point
there is no stack at all, whether empty or not...

> (also after that I may
> change the implementation).

Any implementation shall respect the stack contract, and see above...

>> How are you going to maintain this? Do you want to prevent messages from
>> being copied? Then you should reconsider the design of messages allowing
>> their queuing without stacks. Alternatively, do you want to copy messages
>> upon queueing (to marshal them)? Then the queue should deal with
>> unconstrained objects:
>> 
>>    generic
>>       type Message (<>) is private;
>>    package Queue is
>>       ...
> 
> I want to "stack away" messages to be processed later.
> Copied, deleted etc.

That does not define what happens with the message object. Do you stack
*the* message or *a* copy/equivalent/digest of?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de