In article ,
Dave Abrahams wrote:
>on Sun Oct 02 2011, nmm1-AT-cam.ac.uk wrote:
>
>> The STL isn't very high quality, anyway, which is another problem :-(
>
>By what measure?
>
>It has its shorcomings, but along many axes, I'd say it is of very high
>quality... a level of quality that easily surpasses that of any library
>with similar intentions when the STL was introduced.
That last may very well be true, and there are indeed several aspects
where I am very impressed indeed with its design. But remember that
I have been involved in this area for 40 years. However, let's just
answer your first question.
It is extremely complicated, largely because there are so many ways
to do the same thing but, despite that, it is not very flexible.
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.
It is extremely under-specified, and seriously ambiguous in a lot
of important (if edge-case) aspects, even more than the C++ language.
So far, I have found relatively few clear unimplementabilities and
inconsistencies. Let's take one example, which is pervasive but
shows up particularly obviously in sorting and other rearrangements.
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? That is particularly important when the
location of an object is constrained or carries information (e.g.
it is commonly used as an equality breaker in sorting).
But it is also important when the object includes certain types of
data, such as locks and memory-mapped arrays. How much extra
complexity does the programmer have to add to defend himself against
what the STL code may do?
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)
|
