help / color / mirror / Atom feed
From: Rod Kay <>
Subject: Re: Is this a compiler bug ?
Date: Mon, 20 Mar 2023 13:24:40 +1100	[thread overview]
Message-ID: <tv8g59$38oos$> (raw)
In-Reply-To: <tv6oee$2ujem$>

On 19/3/23 21:33, Jeffrey R.Carter wrote:
> On 2023-03-19 07:17, Rod Kay wrote:
>>     In the 'to_Stack' function, the Capacity is reserved correctly but 
>> in the test program when the stack is created and assigned to a 
>> variable, the capacity is 0.
> I think this is acceptable behavior. See ARM A.18.2 (147.19/3, 147.20/3, 
> & 147.b/3) 
> ( 
> The first two sections define the behavior of procedure Assign, while 
> the last states "Assign(A, B) and A := B behave identically".
> Assign (A, B) only changes the capacity of A if A.Capacity < B.Length.
> So if the compiler does not use build-in-place for the initialization of 
> the variable, then the assignment of the function result should not 
> change the capacity of the variable from its (apparent) default of zero 
> (there is, of course, no requirement for the capacity of a 
> default-initialized vector).
> The discussion of capacities for vectors is only meaningful for a subset 
> of possible implementations, so messing with capacities may have no 
> meaningful effect at all.
> For an unbounded stack based on a linked list (with no concept of 
> capacity) you could use 
> PragmARC.Data_Structures.Stacks.Unbounded.Unprotected 
> (

    Thank you, Jeffrey, for the detailed reply.

    I'm now using a limited record with an extended return for 
'build-in-place' initialisation and am getting the behavior I desired.


      reply	other threads:[~2023-03-20  2:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-19  6:17 Is this a compiler bug ? Rod Kay
2023-03-19 10:33 ` Jeffrey R.Carter
2023-03-20  2:24   ` Rod Kay [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox