[Bug libstdc++/48848] New: [C++0x] std::valarray<T> functions missing

[Bug libstdc++/48848] New: [C++0x] std::valarray<T> functions missing

[ssameer+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

           Summary: [C++0x] std::valarray<T> functions missing
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ssameer+gcc@gmail.com


std::valarray<T> move constructor, move assignment operator and swap() function
are missing in the standard header <valarray> These new functions are quite
important for efficient numeric code as they prevent temporary copies. See
section 26.6.2.1, 26.6.2.2, 26.6.2.7 in the draft N3092.

The status document
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/libstdc++/manual/manual/status.html
claims that support for valarray is complete except for range access. Actually
range access (begin() and end() functions) are implemented, while the above 3
functions are missing.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[ssameer+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #1 from ssameer+gcc at gmail dot com 2011-05-02 22:37:36 UTC ---
These functions are present in the standard library that comes with Visual C++
2010.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot
                   |                            |com

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-02 23:18:38 UTC ---
The documentation is likely wrong. Otherwise, we don't make promises about
these specific bits of <valarray>, frankly, the priority isn't very high,
compared to other areas of C++0x. Jon, can you have a look to the docs?

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.05.02 23:34:28
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-02 23:34:28 UTC ---
I'll do the <valarray> bits for 4.7.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-02 23:46:28 UTC ---
Author: redi
Date: Mon May  2 23:46:24 2011
New Revision: 173278

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173278
Log:
2011-05-03  Jonathan Wakely  <jwakely.gcc@gmail.com>

    PR libstdc++/48848
    * doc/xml/manual/status_cxx200x.xml: Update valarray status.
    * doc/html/*: Regenerate.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/doc/html/api.html
    trunk/libstdc++-v3/doc/html/faq.html
    trunk/libstdc++-v3/doc/html/manual/abi.html
    trunk/libstdc++-v3/doc/html/manual/algorithms.html
    trunk/libstdc++-v3/doc/html/manual/api.html
    trunk/libstdc++-v3/doc/html/manual/appendix_contributing.html
    trunk/libstdc++-v3/doc/html/manual/appendix_free.html
    trunk/libstdc++-v3/doc/html/manual/appendix_gpl.html
    trunk/libstdc++-v3/doc/html/manual/appendix_porting.html
    trunk/libstdc++-v3/doc/html/manual/atomics.html
    trunk/libstdc++-v3/doc/html/manual/backwards.html
    trunk/libstdc++-v3/doc/html/manual/bitmap_allocator.html
    trunk/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html
    trunk/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html
    trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html
    trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html
    trunk/libstdc++-v3/doc/html/manual/bk01pt03pr01.html
    trunk/libstdc++-v3/doc/html/manual/concurrency.html
    trunk/libstdc++-v3/doc/html/manual/containers.html
    trunk/libstdc++-v3/doc/html/manual/diagnostics.html
    trunk/libstdc++-v3/doc/html/manual/documentation_hacking.html
    trunk/libstdc++-v3/doc/html/manual/extensions.html
    trunk/libstdc++-v3/doc/html/manual/facets.html
    trunk/libstdc++-v3/doc/html/manual/intro.html
    trunk/libstdc++-v3/doc/html/manual/io.html
    trunk/libstdc++-v3/doc/html/manual/iterators.html
    trunk/libstdc++-v3/doc/html/manual/localization.html
    trunk/libstdc++-v3/doc/html/manual/memory.html
    trunk/libstdc++-v3/doc/html/manual/numerics.html
    trunk/libstdc++-v3/doc/html/manual/parallel_mode.html
    trunk/libstdc++-v3/doc/html/manual/profile_mode.html
    trunk/libstdc++-v3/doc/html/manual/spine.html
    trunk/libstdc++-v3/doc/html/manual/status.html
    trunk/libstdc++-v3/doc/html/manual/strings.html
    trunk/libstdc++-v3/doc/html/manual/support.html
    trunk/libstdc++-v3/doc/html/manual/test.html
    trunk/libstdc++-v3/doc/html/manual/using.html
    trunk/libstdc++-v3/doc/html/manual/using_exceptions.html
    trunk/libstdc++-v3/doc/html/manual/using_headers.html
    trunk/libstdc++-v3/doc/html/manual/utilities.html
    trunk/libstdc++-v3/doc/xml/manual/status_cxx200x.xml

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-02 23:50:03 UTC ---
The status table is right on trunk now, I'll update it again when move and swap
operations are added.

I should backport the updated status table to the 4.6 branch, as the C++0x
status of trunk and 4.6 is almost identical and many users are probably more
interested in the status in the current release rather than trunk.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-02 23:50:50 UTC ---
Thanks Jon!

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[ssameer+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #7 from ssameer+gcc at gmail dot com 2011-05-03 00:01:05 UTC ---
Thanks guys ! I'll look forward to the changes in gcc 4.7.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 00:52:11 UTC ---
And I think that in the FDIS we have a defect for the move assignment operator:
it is supposed to be both noexcept and constant complexity and I don't see how
those can be achieved given the "as if by calling resize(v.size())" semantics.
Then, even assuming we "ignore" the "as if", as some sort of pasto, and proceed
with plain swaps of the data members, we are still not completely happy,
because, from at least the QoI point of view, we would like to ensure for
valarray too the resolution of LWG 675 for containers, thus we want to destroy
first all the existing elements, the complexity is again in principle
non-constant.

Jon, do you have an opinion about this? I'm thinking of just swapping for now,
but also raise the issue on the reflector.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-03 09:03:22 UTC ---
Good point.  I think the requirement for constant complexity should have been
removed by LWG 675.  Pending clarification from the committee I think I would
implement it with the usual swap with temporary, giving linear complexity.
  valarray(std::move(v)).swap(*this);

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 09:27:24 UTC ---
Agreed, thanks for the feedback, let's implement it like this, for now.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-03 09:55:45 UTC ---
It would be possible to make it constant complexity, by delaying
destruction+deallocation of the old elements of *this until its destructor runs
(at which point "an implementation may return all allocated memory") but that
would require keeping a collection of previous arrays to be freed on
destruction.
That collection would not be part of the object's value so wouldn't need to be
copied or moved, but I don't think we want to take that approach.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 10:11:48 UTC ---
I think I see what you mean, but actually, I'm not sure that this kind of
sophistication would be consistent with the rationale of LWG 675: if I
understand it correctly, we really want the move-assigned-to object to behave
similarly to the copy-assigned-to object, thus destruct and release
immediately, no? We want the moral equivalent of this->clear() &
this->swap(__other).

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 10:25:12 UTC ---
I'm wondering if, waiting for some possible feedback from the Committee, we
shouldn't instead simply swap the data members and disregard LWG 675 for now.
Arguably, for std::valarray, where performance is everything, the constant
complexity and total nothrow guarantee that two POD swaps achieve has the
preference to any other nice feature...

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 10:44:41 UTC ---
I'm also thinking that in terms of complexity, in this entire discussion we are
just shuffling work around in time. In LWG 675 it is established that clearing
first increases the complexity from constant to linear because the destructors
are called immediately, but sooner or later those destructors would have run
anyway, eh! On the other hand, calling the destructors immediately has the
advantage that we know all the resources owned by *this are released *now*. I'm
not sure we have an exact equivalent of that for valarray, outside resize(0) or
just some user-invisible implementation details. I'm coming to the conclusion
that, barring a clarification from the Committee, the straightforward thing to
do is just swapping the data members, the destructors of the temporarie will
run when they want, the move-assignment itself is certainly fast and nothrow,
as the FDIS wants.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-03 11:18:28 UTC ---
(In reply to comment #12)
> I think I see what you mean, but actually, I'm not sure that this kind of
> sophistication would be consistent with the rationale of LWG 675: if I

It definitely wouldn't - but do the general container requirements apply to
valarray? if not, 675 is irrelevant
(I think it is relevant and 675 should have removed the constant complexity
requirement for valarray's move assignment op)

> understand it correctly, we really want the move-assigned-to object to behave
> similarly to the copy-assigned-to object, thus destruct and release
> immediately, no? We want the moral equivalent of this->clear() &
> this->swap(__other).

I agree that makes sense.

My suggestion about delaying deallocation only makes sense if we want to
implement the letter of the FDIS and have constant complexity for valarray move
assignment (in contrast with other containers) - but let's get clarification on
whether 675 should have been applied to valarray too

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 11:50:22 UTC ---
I sent a message to the reflector. Let's suspend this for now.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 14:13:37 UTC ---
I'm under the impression that later today we can resolve this: Howard and
Daniel agree on the reflector that we want something similar to the clear() +
swap semantics we have in the containers, essentially. And noexcept can stay.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW

--- Comment #18 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 22:13:29 UTC ---
On it.

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

--- Comment #19 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> 2011-05-03 22:25:28 UTC ---
Author: paolo
Date: Tue May  3 22:25:24 2011
New Revision: 173344

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173344
Log:
2011-05-03  Paolo Carlini  <paolo.carlini@oracle.com>

    PR libstdc++/48848
    * include/std/valarray (valarray<>::valarray(valarray&&),
    valarray<>::operator=(valarray&&), valarray<>::swap): Add.
    * doc/xml/manual/status_cxx200x.xml: Update.
    * testsuite/26_numerics/valarray/moveable.cc: New.
    * testsuite/26_numerics/valarray/swap.cc: Likewise.

Added:
    trunk/libstdc++-v3/testsuite/26_numerics/valarray/moveable.cc
    trunk/libstdc++-v3/testsuite/26_numerics/valarray/swap.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/doc/xml/manual/status_cxx200x.xml
    trunk/libstdc++-v3/include/std/valarray

[Bug libstdc++/48848] [C++0x] std::valarray<T> functions missing

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #20 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-03 22:35:13 UTC ---
Done.