This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++14 implementation status


On 06/08/2013 12:16 PM, Jonathan Wakely wrote:
We should add a C++14 status table to the manual but in the meantime
here's a quick summary of the library status.

These are done:

N3669 Fixing constexpr member functions without const
N3668 exchange() utility function
N3670 Wording for Addressing Tuples by Type
N3656 make_unique
N3462 std::result_of and SFINAE
N3545 An Incremental Improvement to integral_constant
N3642 User-defined Literals for Standard Library Types
N3671 Making non-modifying sequence operations more robust
N3654 Quoted Strings Library Proposal (when Ed commits it)

I think these are already done, but need to check:

N3471 Constexpr Library Additions: utilities
N3469 Constexpr Library Additions: chrono
N3470 Constexpr Library Additions: containers

I've implemented these but need to write tests:

N3658 Compile-time integer sequences
N3659 Shared Locking in C++

I'm working on:

N3421 Making Operator Functors greater<>
N3657 Adding heterogeneous comparison lookup to associative containers

These ones are missing:

N3672 A proposal to add a utility class to represent optional objects
N3655 TransformationTraits Redux
N3662 C++ Dynamic Arrays
N3644 Null Forward Iterators

The traits one is simple but a bit tedious and the iterators one
probably only affects debug mode, but the other two are substantial
pieces of work.  Is anyone planning on working on <optional> or
<dynarray> yet?

There are also some LWG issues from the last couple of meetings,
including vector<bool>::emplace, std::cbegin/std::cend,
allocator_traits::max_size(), which I have fixes for in my Git tree.

I'm looking at both optional and dynarray but I'm not too far on either - I won't/can't claim them. I might have work taking a lot of my time as well.

Generally I look at everything because I'm ADD. It doesn't bother me in the least to be 'scooped'. I figure either way, I've learned something.

The real pickle for dynarray is that, AFAICT, if you really want to support arrays on the stack you would need to intercept construction of dynarray in the front end and have the front end pass an appropriately sized VLA pointer to dynarray basically. (The VLA/alloca'd array must be built in the calling stack frame not the ctor frame). Dynarray would not manage memory in that case. OTOH, if the user wanted a really huge dynarray we would roll over to the free-store implementation indicated in the paper n3662 - dynarray would then manage the memory of course.

Ed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]