"Pascal Obry" 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.