Re: GNAT for MS Visual Studio

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5624 bytes --]

"Pascal Obry" <pascal@obry.net> wrote in message
news:47088904.1090201@obry.net...
> Randy Brukardt a �crit :
> > If you want dangerously unsafe containers, you are welcome to write them
> > yourself. But they don't belong in the standard (surely not as the sole
> > example of containers).
>
> I love those nonsense ! How can something that is only read be unsafe!!!
> And please between "dangerously unsafe containers" and "concurrent read
> access containers" I think there is some room. Why always having such
> strong and extreme position????

You have to consider the whole of the containers, not individual operations.
There are so many operations that having special rules for each one would be
a nightmare.

In any case, one size of container does not fit all. Having safe containers
that have write operations (whether they are used or not) requires having
checking, and that checkings needs to do bookkeeping. That means that safe
containers with multi-read access are going to require locks somewhere;
that's enough of a performance hit that it's dubious that it should be
required for the "base" containers.

If you are willing to have unsafe containers, then you don't need locks.
That's all I was talking about, and there is nothing extreme about that
position. The only thing that could be potentially called extreme is the
insistence on the possibility of safe containers. But is anyone really
against safety?

> Look it is not that unusual to have a container populated for a
> simulation that after initialization point does not need to be updated
> but only *read*. I have many concurrent simulations like this. I would
> have expected to be able to use the containers in this case.

The containers are only expected to be useful in 80% of the cases. The plan
is that there will be additional famiilies of containers to cover other
common use cases (particularly task-safe uses). We simply didn't have time
to expend effort on those additional families for the Amendment.

The standard rule in Ada, for *any* subprogram (in the absense of
documentation to the contrary), is that it must be called with
non-overlapping actual parameters if used from multiple tasks (or some
synchronization be used). You must never expect concurrent read to work
unless it is in the contract. It's most consistent to apply that to all of
the "base" library routines. (And yes, I think all user-written code should
either work when called by multiple tasks (for different objects) or be
documented that it doesn't work.)

> The recurrent saying "if you don't like this, do it yourself" in
> comp.lang.ada is just a big mistake for Ada as a whole. This decision is
> just counter intuitive for anybody having done a bit of computer science
:(

I don't buy this. Expecting that everything that you might want to do is
already done for you is a mark of a newbie. If it was that easy to program,
there would be no need for software professionals (or computer science).
There's a heck of a lot more to programming than just making a bunch of
subprogram calls.  The whole point is to know when it is better to do it
yourself, by knowing what the requirements of your application and whatever
is available.

In the specific case of the containers, there is no possibility of the
standard defining every possible combination of performance/memory
management/concurrency control (and I've probably forgotten some
properties). If you have strong needs in one of those areas, then you will
probably need to write something yourself. It is folly to expect the
predefined library to do everything for you. (Moreover, most of the time, it
is just premature optimization anyway; the predefined containers will be
fine.)

If you need concurrent access, then you should use the protected containers.
It's legitimate to gripe that they don't exist yet - it is annoying that the
standard for the protected containers isn't progressing faster, because it
is obvious that there is a need for such things. (It's tied up with the
bounded containers and various other forms. And so far as I know, no one has
tried to define in RM language what it means for a container to be
protected.)

> Anyway I had to say that :)
>
> Now maybe some operations could be made safe, like those not using
> cursors. For example, in Ada.Containers.Vectors:
>
>    function Element
>      (Container : Vector;
>       Index     : Index_Type) return Element_Type;
>
> Why this could not be made safe ?

It could, so long as you don't allow it to be combined with any other
container operation. Trying to define that in RM wording seems difficult to
me (all resource sharing issues are very hard to define in proper standards
language). Witness the thread on the meaning of 9.10.

Moreover, as I previously mentioned, it would be inconsistent with the
"normal" usage of Ada routines. It's a lot easier to remember to never
concurrently access a "basic" container than to try to remember the specific
cases where concurrent access is allowed. I personally think that such a
rule would lead to more (not less) container misuses, and quite likely
pressure on vendors to go beyond the standard in this area.

It would be easier to correctly use "protected" (task-safe) containers in
concurrent uses than ones that only allowed a small amount of concurrency.
Not everyone is an expert in concurrency, after all.

In any case, there is a master plan here; the problem is mostly a lack of
resources to execute that plan. (Sigh, I sound like a broken record on that
topic -- it applies equally to Ada itself and to Janus/Ada.)

                                  Randy.