Re: [PATCH] Move stl_uninitialized.h extensions to <ext/memory>

[Paolo Carlini <pcarlini at unitus dot it>]

Gabriel Dos Reis wrote:

> Paolo Carlini <pcarlini@unitus.it> writes:
>
> | Hi,
> |
> | this one moves some extensions present in stl_uninitialized.h to ext/memory. I
> | followed the very same approach used for stl_algo.h.
> |
> | A small surprise came from discovering that the implementation of deque in fact
> | uses such extensions! (I learned that by grepping, since we are not currently
> | testing much deque... :-(
>
> Thanks Paolo.
>
> Before your patch goes in, we should study, understand and make
> surgery on std::deque, as there is no point in moving extensions away
> if we were to bring them back.

Hi Gaby, Phil, Benjamin, all

first let me point out this: I stumbled on this deque-issue *by chance*, only when
checking, to be sure, if perhaps something else was using those HP/SGI estensions
present in stl_uninitialized.h. The real reason why today I became interested in the
latter is that some of the extensions already inside include/ext (which I'm moving
to __gnu_cxx) use for the implementation 'uninitialized_copy_n" (to wit, ropeimpl.h
and stl_rope.h). This is, by itself, not troublesome, I think: something properly
belonging to __gnu_cxx using something else properly belonging to __gnu_cxx.

While I was at it (the patch for the extensions already in include/ext is now ready,
finally, I can post it immediately) I decided to clean up stl_uninitialized.h
itself, instead of temporarily calling std::uninitialized_copy_n from ropeimpl.h and
stl_rope.h sure that sooner it would be moved to __gnu_cxx::uninitialized_copy_n. At
that point I noticed that stl_deque.h was using some of those stl_uninitialized.h
extensions!

So, at this point, what should we really do?

As a matter of fact, the presence of extensions in stl_uninitialized.h used by
stl_deque.h is blocking *all* the cleanups for the extensions already present in
include/ext. Honestly, at this point, I don't think it is an option trying to make
quickly surgery to stl_deque.h eliminating with a sleight of hand the use of
__uninitialized_copy_fill, __uninitialized_fill_copy, __uninitialized_copy_copy. We
should alter not trivially the code and either replace those calls with something
else, duplicate them inside namespace std, or something else I cannot foresee right
now...

The patch for stl_uninitialized I have just proposed uses as a sort of *temporary*
hack some bits of ext/memory in stl_deque.h but only in the form of 4 *calls* (no
namespace pollution!). This would allow me to clean-up momentarily all the remaining
stuff alreasy inside include/ext, as I said above. I would rather prefer proceeding
in this way, and then work with Phil in cleaning up stl_deque.h, -possibly- (only
possibly) removing completely the reference to those ext/memory bits.

Alternatively I could propose leaving for the moment stl_uninitializes.h and
stl_deque.h as they are (i.e., forget about the present patch) and call
std::uninitialized_copy_n from ropeimpl.h and stl_rope.h. Then, in a second pass,
work on the former two, clean them, and consequently adjust those call to
__gnu_cxx::uninitialized_copy_n.

I see only the preceding two possibilities if we don't want to block the cleanup of
include/ext (that is, rope, slist, hash_map, hash_set) in the hope that we can
definitely eliminate references to __uninitialized_copy_fill,
__uninitialized_fill_copy, __uninitialized_copy_copy from stl_deque.h.

What do you think?

As regards the necessity of some testcases for the extensions I will of course work
on them ASAP... By the way, as you probably know better then me, many library
features sadly are still untested, not only the extensions...

Cheers,
Paolo.