Re: Where to find Ravenscar compatible ADT Containers (List, Vector, stack)

["Randy Brukardt" <randy@rrsoftware.com>]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:69e04c61-8ea3-40e2-bb9d-e5a128247df3@googlegroups.com...
> On Tuesday, August 28, 2018 at 8:24:23 PM UTC-4, Randy Brukardt wrote:
...
> I have a question about this as it has always bothered me.  The
> section that specifies that is under Implementation Advice, which
> doesn't sound binding.

Correct.

> That sounds more like it is a suggestion
> to the vendor rather than a requirement.  Is Implementation
> Advice such that a conforming Ada compiler must follow it
> (so not really advice at that point)?

No, but a conforming compiler needs to document any advice that they don't 
follow. The only problem with that is that I'm not aware of any compilers 
that actually do that (at least in an easy-to-use-form). Ada 83 compilers 
used to be required to have an annex F for validation purposes (note: it's 
Annex M in Ada 95 and later), but that requirement was dropped decades ago.

I once tried to do this documentation, but that that time there was no 
listing of Implementation Advice and as such I ended up abandoning it almost 
immediately. (We've since corrected that oversight in the Standard.) One of 
the major problems is that for a lot of these things, it would require a lot 
of compiler spelunking to figure it out what actually happens. (You would 
need to keep track of them as things are implemented to even have a chance.) 
It's easier to answer specific questions than to track down several hundred 
obscure issues that no one may ever care about.

> I've intentionally avoided
> bounded containers in situations where I want portability for
> some of my embedded targets that don't use heap because it
> doesn't sound guaranteed that it will not use heap, even
> if my current compiler implements it that way now.

In theory, you compiler vendor is supposed to tell you if they do any such 
things. In practice, it would be bizarre to support Ravenscar and then not 
let any containers work with it. Only a crazy vendor would do that on 
purpose, and surely any sane ones would take a priority change request on 
such things. (Janus/Ada doesn't support Ravenscar, and it's nearly 
impossible to write a generic that doesn't use the heap, but no one is going 
to expect to use Janus/Ada in such an environment anyway. But even so, we 
don't plan to use any explicit heap in the bounded containers -- whatever 
implicit stuff the compiler does is not really under the control of a 
programmer.)

In practice, I would be surprised if a vendor suddenly started using heap 
intentionally in one of these containers. Most likely, if they are 
targetting no-heap applications, they're well aware that bounded containers 
are supposed to be used in such scenarios, and would intend to keep that the 
case.

Note that there never is a guarantee of anything with a new compiler 
version: a new bug could cause your code to not compile or malfunction; new 
enforcement of a previously missed rule could cause your code to be 
rejected, and so on. Some care is always required.

                                                         Randy.