Re: Calling inherited primitive operations in Ada

["Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not>]

On 2022-09-05 08:56, Emmanuel Briot wrote:
> 
> I definitely see the same issue. The way my library is trying to workaround that is as follows:
> Those instantiations are only needed for people who want/need to control every aspects of their containers, for instance
> how elements are stored, how/when memory is allocated, what is the growth strategy for vectors, and so on.
> Most users should not have to care about that in practice. So we use code generation at compile time to generate
> high-level packages similar to the Ada containers, with a limited set of formal parameters (in src/generated, to be
> more specific). We can generate bounded/unbounded versions, definite/indefinite versions, and any combination of
> those.

This seems backwards. The user should encounter the forms most likely to be used 
first; if part of the packages are in a subdirectory, those should be the ones 
less likely for the typical user to use.

> Although it is certainly true that using holders works, it is not applicable when designing a containers library that intends to be
> mostly compatible with Ada containers. The latter have chosen, long ago and before Holder was a thing, to have definite and
> indefinite versions. The main benefit to this approach is that users still retrieve directly the type they are interested in (e.g. String)
> rather than a holder-to-string.

Before Ada.Containers existed, I commonly used definite data structures from the 
PragmARCs with Unbounded_String, which is partly a specialized holder for String 
(and partly a specialized Vector for Positive/Character). Generalizing from this 
led to implementing a Holder pkg.

When I said a holder is the only indefinite pkg that is needed, I meant to imply 
that other indefinite structures would be implemented using the definite form + 
holder.

-- 
Jeff Carter
“Bug rates in C++ are running higher even than C ...”
Stephen F. Zeigler
216