New adopted paper: N3638, Return Type Deduction for Normal Functions -- Jason Merrill

By Blog Staff | Apr 23, 2013 02:22 AM | Tags: None

Note: This paper was adopted into draft C++14 on Saturday at the Bristol UK ISO C++ meeting.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3638

Date: 2013-04-17

Return type deduction for normal functions

by Jason Merrill

Excerpt:

Any C++ user introduced to the C++11 features of auto, lambdas, and trailing return types immediately wonders why they can't just write auto on their function declaration and have the return type deduced. This functionality was proposed previously in N2954, but dropped from C++11 due to time constraints, as the drafting didn't address various questions and concerns that the Core WG had. I have now implemented this functionality in GCC, and propose to add it to C++14. I discuss some of the less obvious aspects of the semantics below.

This proposal also resolves core DRs 975 (lambda return type deduction from multiple return statements), 1048 (inconsistency between auto and lambda return type deduction), and 1588 (deducing cv-qualified auto).

Note that this paper also allows lambdas (not just functions) with multiple return statements to have their return type deduced. Examples in the paper include multiple returns, recursion, and more:

auto iterate(int len)                        // return type is deduced as int
{
  for (int i = 0; i < len; ++i)
    if (search (i))
      return i;
  return -1;
}

auto sum(int i) {
  if (i == 1)
    return i;                                // return type deduced to int
  else
    return sum(i-1)+i;                       // ok to call it recursively now
}

template <class T> auto f(T t) { return t; } // return type deduced at instantiation time

[]()->auto& { return f(); }                  // return a reference

New adopted paper: N3662, C++ Dynamic Arrays (dynarray) -- Lawrence Crowl, Matt Austern

By Blog Staff | Apr 23, 2013 02:10 AM | Tags: None

Note: This paper was adopted into draft C++14 on Saturday at the Bristol UK ISO C++ meeting.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3662

Date: 2013-04-19

C++ Dynamic Arrays

by Lawrence Crowl and Matt Austern

See also related paper N3662, "Runtime-Sized Arrays with Automatic Storage Duration (Revision 5)"

Excerpt:

Instead of adopting C variable-length arrays, we propose to define a new facility for arrays where the number of elements is bound at construction. We call these dynamic arrays, dynarray. In keeping with C++ practice, we wish to make dynarrays usable with more than just automatic variables. But to take advantage of the efficiency stack allocation, we wish to make dynarray optimizable when used as an automatic variable.

 

New adopted paper: N3639, Runtime-Sized Arrays with Automatic Storage Duration (Rev5) -- Jens Maurer

By Blog Staff | Apr 23, 2013 01:06 AM | Tags: None

Note: This paper was adopted into draft C++14 on Saturday at the Bristol UK ISO C++ meeting.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3639

Date: 2013-04-16

Runtime-sized arrays with automatic storage duration (revision 5)

by Jens Maurer

See also related paper N3662, "C++ Dynamic Arrays (dynarray)"

Excerpt:

Sometimes, a user wishes to allocate a local array whose size is not known at compile-time, but at runtime only. Nonetheless, the array's size will remain unchanged during the lifetime of the array.

Examples are

• interfacing with the readv/writev POSIX system calls
• small runtime-sized data structure to apply STL algorithms calls
• ...

This paper proposes to add local runtime-sized arrays with automatic storage duration to C++, for example:

void f(std::size_t n)
{
   int a[n];
   for (std::size_t i = 0; i < n; ++i)
       a[i] = 2*i;
   std::sort(a, a+n);
}

Traditionally, the array bound "n" had to be a constant expression (see 8.3.4 dcl.array). For local arrays with automatic storage duration, this paper proposes to lift that restriction. The syntax is intended to be the same as that used for C99 variable length arrays (VLAs), except that implementation support for VLAs is optional in C11 and aggregate initialization is not supported in C.

As a design guideline, the same rules should apply to "new T[n]" and a local array "T a[n]", except that arrays of zero size are only supported for new.

There is well-established existing practice with gcc, Clang, and Intel C++ all implementing a similar, if not identical feature. In fact, Douglas Gregor reported in c++std-ext-12553 on 2012-01-30: "Users really seem to want this feature. It's a fairly common extension, and when we tried to ban it out of principle (in Clang), our users reacted *very* strongly."

Trip Report: ISO C++ Spring 2013 Meeting

By H Sutter | Apr 20, 2013 12:16 PM | Tags: None

This afternoon in Bristol, UK, the ISO C++ standards committee adopted generic lambdas, dynamic arrays (an improved version of C99 VLAs), variable templates, reader/writer locks, make_unique, optional<T>, standard library user-defined literals, and a number of other language and library improvements -- and approved the result as the feature-complete Committee Draft (CD) of Standard C++14 to be distributed for its primary international review ballot.

In addition to completing the C++14 CD document, the committee also made progress on three additional important parallel specifications that are on track to be published around the same time as C++14:

• File system library (draft), based on Boost.FileSystem version 3.
• Networking library, small at first and regularly extended.
• "Concepts Lite" language extensions (draft), to express template constraints and improve template usability and error messages.

Together these mark the C++ committee’s main planned deliverables for 2014. Updated papers and an updated working draft will be available soon.

Meeting Highlights

Bristol saw a recent-record number of technical papers (160), attendees (over 100), parallel technical sessions (typically six or more subgroups meeting at once), and many overlapping evening sessions – including formal sessions that ran past midnight at least twice to resume again at 08:30.

C++14: Bug Fixes + Minor Update

C++14 is primarily a bug-fix release, but also includes new features that were ready including a number that developers have been asking for the standard to support. With the CD document contents now set to be balloted this summer, we for the first time know the shape and feature set of C++14.

To provide just a sampling, here are a few quick examples of some of the newly added features.

make_unique

One of the smallest additions is actually great in its impact. It's make_unique:

auto u = make_unique<some_type>( constructor, parameters, here );

The reason make_unique has important impact is that now we can teach C++ developers to mostly never use explicit new again. In C++11 we already could teach to never use owning raw pointers and explicit delete again, except in rare cases that are hidden inside a class in order to do something like implement a low-level data structure. However, we could not teach to never write new because although make_shared was provided to create a shared_ptr, new was still needed to create a unique_ptr. Now, instead of “new”, write make_unique or make_shared.

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. Allocate with make_unique or make_shared, use weak_ptr where appropriate to break cycles, and don't worry about dangling pointers in C++ again.

Generic lambdas

Lambdas will now support auto as a type name. This is convenient when the type is tedious to spell out, and is especially nice in generic code where you want the same lambda object to be usable with a variety of types. For example:

vector<int> v;
vector<shared_ptr<some_type>> index;   // stores pointers to objects

// C++11:
//
for_each( begin(v), end(v), []( decltype(*begin(v))& x ) { cout << x; } );

sort( begin(index), end(index), []( shared_ptr<some_type> const& p1, shared_ptr<some_type> const& p2 ) { return *p1 < * p2; } );

auto get_size = []( unordered_multimap<wstring, list<string>> const& m ) { return m.size(); };

// C++14 draft:
//
for_each( begin(v), end(v), []( auto& x ) { cout << x; } );

sort( begin(index), end(index), []( auto const& p1, auto const& p2 ) { return *p1 < * p2; } );

auto get_size = []( auto const& m ) { return m.size(); };
  // bonus: this now works with any container that supports .size()

Lambda generalized capture

Lambdas will now be able to capture by move, and define new local variables in the lambda object. For example:

auto u = make_unique<some_type>( some, parameters );  // a unique_ptr is move-only

go.run( [ u{move(u)} ] { do_something_with( u ); } ); // move the unique_ptr into the lambda

Variable templates

These can perhaps be best illustrated with an example taken right from the draft standard text (comments added).

// Write pi once for every possible type
template<typename T>
constexpr T pi = T(3.1415926535897932385);

// Sample use
template<typename T>
T circular_area(T r) {
    return pi<T> * r * r;
}

Dynamic Arrays

Draft C++14 now has fixed- but runtime-sized arrays of two kinds: in the language, and as a dynarray<T> library.

In the language, draft C++14 now allows stack-based arrays to have a size determined at run time:

void f(std::size_t n)
{
   int a[n];

   ...

}

Note that this is not the same as C99 variable length arrays (VLAs), and that the C11 standard has made VLAs conditionally-supported so that they are no longer part of portable C required in a conforming C compiler. 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)
• modifications to the function declarator syntax
• sizeof(a) being a runtime-evaluated expression returning the size of a
• typedef int a[n]; evaluating n and passing that through the typedef

In addition to stack-based runtime-sized arrays, we now also have a dynarray<T> container in the standard library. The two features are similar, but with a few key differences: Both permit efficient allocation on the stack or on the heap, at the discretion of the implementation, but dynarray<T> can additionally be used as a non-stack variable and in those cases will use the heap, it is inspectable with decltype, and it supports zero-sized arrays.

optional<T>

To highlight just one more of the new features and changes, we have an evolution of Boost’s optional type. An example tells most of the story:

    cin >> s;
    optional<int> o = str2int(s); // 'o' may or may not contain an int
    if (o) {                      // does optional contain a value?
      return *o;                  // use the value
    }

On Deck: Also Targeting the '14 Timeframe

And let's end with a template checking with Concepts Lite teaser... if you write this today, what do you get?

template<typename Cont>
void sort(Cont& c);

list<int> lst = { 1, 3, 2, 4 };
sort(lst);                        // ???

Impenetrable template diagnostics. At considerable length.

What we want:

template<Sortable Cont>
void sort(Cont& c);

list<int> lst = { 1, 3, 2, 4 };   
sort(lst);                        // "error: lst is not Sortable"

An implementation of the above, with about that error message, already exists.

Beyond that, consider even a "terse syntax" that would be especially helpful with generic lambdas:

void sort(Sortable& s);           // possible syntax: implicit function template

int main() {                      // and now that we have generic lambdas in the language...
    auto mysorter = [](Sortable& s){ /*...*/ }; // possible syntax
                                  // ... we'll surely want to constrain those too
}

Interestingly, that last example shows some nice, type-checked, robust and fully generic template code, with nary a <> in sight.

All of this is grist for the Concepts Lite Technical Specification, currently targeted for completion and publication next year.

Wrapping Up

Updated papers for these and other features, as well as an updated working draft, are expected to be available in the next two or three weeks.

Thanks again to the many committee members who worked tirelessly in preparation for this meeting, and around the clock all this past week, to achieve this milestone!

Clang reaches 100%: Fully compliant compiler expected this summer

By Blog Staff | Apr 20, 2013 04:34 AM | Tags: None

Reported via Twitter by ISO C++ project editor Stefanus Du Toit:

Clang is C++11 feature complete as of *just now*! Here's the final commit by Richard Smith: http://llvm.org/viewvc/llvm-project?view=revision&revision=179858 … #llvm #cxx11

With Richard Smith's commit to finish thread_local support, Clang is now believed to be code-complete for full C++11 support.

As Clang usually releases twice a year, industry observers expect this means we will see at least one fully C++11-conforming commercial compiler available in the marketplace by this summer.

Congratulations, Clang development team!

Quick Q: What Is the Difference Between set and unordered_set in C++? -- StackOverflow

By Blog Staff | Apr 19, 2013 08:03 AM | Tags: basics

A common Q with a nice concise A:

What is the difference between set and unordered_set in C++?

Came across this good question, which is similar but not at all same since it talks about Java, which has different implementation of hash-tables, [...] So what is the difference in C++ implementation of set and unordered_set? This question can be ofcourse extended to map vs unordered_map and so on for other C++ containers.

Here is my initial assessment...

The Bristol Papers and the State of C++

By Blog Staff | Apr 18, 2013 08:10 AM | Tags: None

One observer's commentary on the standards meeting in process this week, based on the mailing papers and interviewing some delegates by telephone:

The Bristol Papers and the State of C++

[This is] a follow up on the series about the papers for the Bristol Meeting. I'll try to give a little look at C++14, it is slowly taking shape. But as the [Bristol standards] meeting is still going on, there are a lot of pending details missing to put up the facts for C++14. Maybe we have to wait till Chicago for C++14 clearly taking shape. Also I want to cover some of the feedback, and write a little bit about my own view on C++, now after reading all the papers.

Quick Q: Why Doesn't C++ Support typeof? -- StackOverflow

By Blog Staff | Apr 18, 2013 07:55 AM | Tags: intermediate basics

Quick A: Ah, but it does...

From StackOverflow:

Why C++ doesn't allow me to use typeof?

I'm using following code with C++11 and getting a error that I'm not allowed to use typeof!

What is the problem and how to fix this ?

The error :

Error   10  error C2923: 'typeof' is not a valid template type argument for parameter 'C'

Here is my code: ...

A Look at C++14 and Beyond: Papers Part 4 -- Meeting C++

By Blog Staff | Apr 14, 2013 04:11 PM | Tags: None

And the final part 4:

A look at C++14 and beyond: Papers Part 4

This is the 4th and last part about the Pre-Bristol mailing and its papers. This series has given me a good overview, what is up in the future in C++. Still, some things are missing, not all will come to shine in this series. I have no papers with actual proposals skipped, but a few papers are only to find in the January mailing, and not in this one. One of them is for example a paper on filesystem, which should make it into C++14. However, there will be a follow up to this series. At the next meeting of my local C++ User Group we are going to have a video call with Michael Wong and other attendees of the meeting. This will be an interesting chat for sure, and help me refine my view on C++14 and C++17 Standards. I'll write this down in the follow up, featuring also some of the feedback that has come.

Before I start with the last 23 Papers, I'll want to shortly mention where this idea has come from. Last fall I saw two blog entries about the Portland Meeting, each naming a few favorite papers and a short summary of them. One was Japanese, and one was Korean, as far as I remember. I had never seen anything like this in the west, no blog, no site brought anything about the papers. Organizing Meeting C++ did not give me the time, to do something similar back then. The decision to cover all papers came, as I wanted to read through most papers any way, and most papers are worth reading. I'm not yet sure if I do something similar for the Chicago Meeting, as this is very time consuming, and therefore would like to state, that I do look for possible Sponsors helping me doing this.

But, lets get started on some papers...

New paper: N3621, Minutes, WG21 Teleconference 2013-03-29 -- Kyle Kloepper

By Blog Staff | Apr 12, 2013 08:32 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3621

Date: 2013-03-29

Minutes, WG21 Teleconference 2013-03-29

by Kyle Kloepper

Excerpt:

Meredith asks if core is in a good place to vote out C++14 in Bristol. Miller confirms that CWG is ready for a CD. Holes in C++11 have been plugged. CWG is in a better place than FDIS for C++11.

[...] tentative schedule for evening [sessions at the Bristol meeting]:

• (Mon) OpenMP
• (Tue) Alisdair: C++11 allocator best practices
• (Wed) Concepts Lite update
• (Thu) TM [Transactional Memory]

​[Ed.: And likely also: (Fri) C/C++ compatibility. This is a record number of evening sessions.]