In article ,
Dave Abrahams wrote:
>
>> Most seriously, it is not a very good basis as a starting point for
>> more advanced containers and algorithms, as this thread has shown for
>> multi-dimensional arrays.
>
>I don't see how that thread showed it. I saw some people claim it.
>I've successfully used it as a basis for constructing multi-dimensional
>arrays and I don't remember being frustrated by its design. The
>iterator concepts need to be extended (i.e. refined) in order to deal
>effectively with sparse matrices, but concept refinement is built into
>the design of the STL so I don't see why that should be a problem.
That's a different assertion.
Nobody claimed that it was difficult to use for that. The evidence
was that nobody other than you had found it very useful - after all,
pretty well ALL it provides over basic C++ arrays is more control
over allocation, and that's a negligible part of a serious multi-
dimensional array class.
>> It is extremely under-specified, and seriously ambiguous in a lot
>> of important (if edge-case) aspects, even more than the C++ language.
>
>I think you are mistaken. There are areas where C++03's library is
>underspecified, but they're not the areas you're pointing at.
Grrk. While it's a hell of a lot better than C, POSIX or OpenMP, a
lot of my queries "Is this practice explicitly defined or definitely
unsupported" end up with the answer "Neither". See below.
>> It is unclear about exactly which constructors etc. container and
>> other operations are allowed to use. In particular, when may they
>> create a temporary copy?
>
>In exactly those circumstances where copyability is a concept
>requirement on the element type. This is not unclear at all to me, and
>if you point at a specific operation I'll give you the specific answer,
>based entirely on the standard text.
>
>In the case of containers, in C++03, copyability is always required of a
>container's element type, and therefore any container operation is
>allowed to make a copy.
Even constant queries? Oh, come now! Though I do accept that there is
nothing that forbids those from doing that .... That issue is serious
enough in itself (see below about locks and RDMA). I will expand my
previous examples, as I am not sure they were clear enough.
The sorting example relates to whether an argument passed to the
comparison function may be a copy, not whether copying is used for
the actual rearrangement. I don't particular care whether it can be
or can't be - all I am saying is that it isn't specified, and does
matter in practical programs.
The lock and RDMA issue is that an object containing such a thing may be
copied only at times the lock or memory is not in use. Very obviously
to someone with suitable implementation experience, there are some
operations that should never be called if they are in use, but there
are lots of others where there is no obvious reason why not. Let's
say element 42 is in use, and I want to swap elements 13 and 69, which
are not. Legal, illegal, or well, eagle?
>It depends what you're worried about. If you're worried that your
>objects may be copied, and you're using a component that requires your
>object to be copyable, and you're not willing to trust your vendor's QOI
>to avoid unnecessary copies, you'd better not use the standard library
>at all.
These issues matter for scientific computing, a good half of which has
used parallelism for a decade, and the proportion is increasing - even
simple MPI-1 non-blocking transfers bring in the RDMA issue. But it's
very serious even for non-scientific programming in C++11, because
any clean threaded code is likely to want to use containers across
threads, with synchronised rearrangement but unsynchronised access.
So where does the boundary lie?
Regards,
Nick Maclaren.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
