Re: C++ / multiple instances / iostreams

[Hans Aberg]

At 16:36 +0200 2004/07/28, Detlef Vollmann wrote:
>> The C++ standard is a bit schizoid, attempting to follow the original C
>> standard, where the underlying implementation is not indicated, not
>> shutting out various hardware architectures. Then it becomes funny when one
>> imposes conditions that in effect forces a type of implementation. And not
>> even C99 could anymore shun away from this path, as one, for example, now
>> can indicate integral types with sizes.
>I have a different opinion on that (of course ;-)
>As you can see from my signature, I'm (also) in the embedded domain.
>And there it is very important that you can potably define fix
>integer sizes.  Potably here means portable across different
>compilers, not (generally) portable across different hardware
>platforms.

It is of course important that one can specify the underlying
implementation, but the schizoid thing with the current C++ standard is
that it on the one hand pretends that one cannot, but on the other hand
imposes implicit conditions in order to in practise fix a specific type of
implementation.

>> There is no particular point in requiring a particular implementation, if
>> there is no way one can take advantage of it. In the case of std::vector,
>> one still has to use the interface, so it makes no difference how it is
>> implemented.
>But that's exactly the point: you can take advantage of it.
>The wording for the contiguous requirement makes it clear
>that you can call a legacy C function that requires a classic
>C array in form of a pointer with &vec.front().

OK. This is a point one could probably discuss forever, and probably has in
comp.std.c++, so I leave it there.

>... for list, you in fact have pretty different runtime complexities.

The motivation for not giving these three the same interfaces is in fact so
that novices should not inadvertently make the wrong choice. But it is a
strange kind of motivation.

>For deque it is guaranteed that references (pointers) to elements
>are not invalidated on insertion.  For some systems it's also
>very important that you don't reallocate (and copy) on growing:
>if you have sequences larger than the avilable physical memory,
>a vector typically causes trashing on growing, while a deque
>that is only sequentially accessed often still performs pretty well.

There are two different discussions mixed up here: Whether one want these
to specify certain types of underlying implementations or merely the
interfaces. Clearly, in C++, there is a tug between groupings.

>> This
>> is just another place in the C++ standard where one has a wishy-washy
>> attitude.
>It might be that the C++ Standard is "wishy-washy" at places, but
>the fact that three different implementations are required under
>clearly specified names is IMHO an important and well thought through
>decision of the C++ committee (apart from the naming itself).

If one now thing these should be names of implementations and not
interfaces with certain types of complexities. The logically most
structured approach is to provide one, single interface (say
std::sequence), with different specializing implementations (array,
single/doubly linked lists, copying/non-copying deque, balanced tree, etc)
where one choose the complexities and other implementation features at need.

This is a bit off from the Bison topic, but nevertheless, it gave me some
ideas in that context, too.

  Hans Aberg