C++14 implementation status

[Ed Smith-Rowland]

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