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

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Paolo Carlini <pcarlini@unitus.it> writes:

| 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.

I do appreciate your work.  And the fact that you got to the issue
whereas we have an open  PR -- maybe related to that extension --
underlines your fruitful work.

[...]

| 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?

I think we should look at the std::deque issue first, after all we're
at stage 3 and PRs should get high priority.

[...]

| 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.

That sounds good to me.

[...]

| 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...

You mean like missing testcases for valarray<>s? :-)

Thanks,

-- Gaby