Stuff being worked on for C++14

[cire]

Just sharing a link for those that may be interested.

http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting

[MiiNiPaa]

In particular, C++ explicitly not does support the following features from C99 VLAs which C++ feels are not desirable:
* multidimensional arrays, where other than the top level has a runtime bound (in analogy, the array form of new expressions doesn’t support that either)
* sizeof(a) being a runtime-evaluated expression returning the size of a

Shame. I understand, that that way it will be faster, but I was really hoping for sizeof(a)/sizeof(a[0]) working with dynamically allocated arrays.

Also I hope that standard library will not drown in backward compatibility and for example made std::stoi() return optional<int> (With support of operator=(T, optional<T>) it will be both neat and backward compatible)

And I was dissapointed when Concepts were dropped from C++. Now we can have less cryptic error messages.

[Catfish4]

dynamic arrays (an improved version of C99 VLAs)

"Improved" by not supporting all features C99 did, such as sizeof? Okay.

File system library (draft), based on Boost.FileSystem version 3.
Networking library, small at first and regularly extended.

Oh yes! Still hoping for memory mapped files though!

"Concepts Lite" language extensions (draft), to express template constraints and improve template usability and error messages.

Oh no!

One of the smallest additions is actually great in its impact. It’s make_unique:
auto u = make_unique<some_type>( constructor, parameters, here );
With draft C++14, we can say simply: Don’t use owning raw pointers, new, and delete, except rarely when implementing low-level data structures.

That's nice and all, but academia will take one hundred years to catch up.

Thanks for the link, cire.

[JLBorges]

> "Improved" by not supporting all features C99 did, such as sizeof?

C99 style VLAs are anyway no longer a part of portable C. As per the current C standard, a conforming C implementation need not support C99 VLAs. If C was forced to backtrack, clearly there were serious problems with VLAs as envisaged in C99. It is not surprising that C++ wants to drop the "undesirable" features that caused insurmountable problems for C.

Incidentally, many of the fundamental issues with C99 VLAs were pointed out by Dennis Ritchie when he made an impassioned (and eventually futile) plea to the standardization committee not to accept the VLA feature as proposed.

This paper proposes to extend C by allowing pointers to adjustable arrays and arranging that the pointers contain the array bounds necessary to do subscript calculations and compute sizes. In this way, the problem of handling variable-size array references is solved in a way that can be made consistent with the rest of the language. By contrast, the apparently most obvious language generalization (that is, allowing general expressions instead of constants in array bounds) complicates the type structure of the language, causes difficulties with the calculus of datatypes, and causes nonuniformity in discovering the sizes of arrays.
- Dennis M. Ritchie, in 1990 http://cm.bell-labs.com/cm/cs/who/dmr/vararray.html

[Catfish4]

Bump. Don't die on me C++14 thread!

I still think Concepts are a bad concept! Why it is our responsibility to write code such that the compiler can produce a meaningful error message?

Aside from that, an innocent Sortable instead of typename doesn't look so bad. But what happens after? People will want to define their own concepts (ugh that name).

[MiiNiPaa]

But what happens after? People will want to define their own concepts (ugh that name).

And what is bad in it? We already can overload operator+ to behave like assigment of result of binary ^ operator to right hand operand and decrementing left hand operand at the same time. We can create a fishnet of inheritance (created exclusively from diamond inheritance) and season it with obscure overloads and a bunch of gotos. And some people wants and actually do it. Concepts is a tool, like everything in C++ and it is up to programmer to responsibly use it.

C is a razor-sharp tool, with which one can create an elegant and efficient program or a bloody mess.
                                                                                                                                            — Brian Kernigan

Why it is our responsibility to write code such that the compiler can produce a meaningful error message?

1) We are not writing the code if we are not creating our own concept. We merely pointing to constraints on arguments:

template <typename T>
template <Container T>

Was the second line much longer than first?
Does second line gives more information what can and what cannot be passed here?
Also Concepts gives you possibility to choose more efficient overload depending on traits of argument: implement two sorting alghoritm: first with complexivity of n2 and using BidirectionalIterator and second n·log(n) using RandomAccessIterator. Containers which support Random access iterators will use faster algorithm and those who supports bidirectional iterator only will use slower one.
2) Concepts is similat to Interfaces but withoun need to explicitly state that we are supporting one (for example by inheriting from abstract base class like in Java or C++). That give a chance to built-in types to satisfy Concept requirement. Cannot let a pointer to array element to be passed to function requiring RandomAccessIterator otherwise.
3) Concets allows template author to tell not only what do argument lack (operator[] had wrong return type, expected xxx) but why: Type should be Sortable (That means it should have member functions begin() and end() or overloaded functions std::begin and std::end() which returns iterators, which have [] operator, which returns reference to value of type contained inside container). Programmer will know what function will expect and will inspect those areas instead of playing detective and trying to determine what caused that error.

[JLBorges]

> People will want to define their own concepts

ConceptsLite does not add much more than syntactic sugar over type_traits and SFINAE. (Though the design allows axioms to be easily incorporated later, in C++17).

Users of a library typically won't define new concepts; but library writers should be encouraged to define new concepts that are appropriate for the particular domain. Concepts makes it much easier to read, write and convey the intent of generic code:

C++11:

template < typename T, typename U >
typename enable_if< ( is_arithmetic<T>::value && is_arithmetic<U>::value ),
                      typename common_type<T,U>::type >::type
                            do_calcs( T a, U b ) ;

Equivalent C++14:
template < Arithmetic T, Arithmetic U > Common_type<T,U> do_calcs( T a, U b ) ;