My Top 5 C++ Proposals for October 2014

Several days ago, at isocpp.org, there were tons of different C++ proposals' updates. Each day, there were several posts describing each application. What was the reason of it?

As it appeared, 10^th October 2014 was the deadline for the pre-Urbana mailing. Now the whole list is available here at wg21. From 3^rd till 8^th November, there will be WG21 meeting in Urbana-Champaign, IL.

Below, you can find a list of my top 5 interesting proposals.

1. Unified Call Syntax

[PDF] Unified Call Syntax

And here is the reddit discussion thread

Summary:

Give possibility to call non-member functions like member ones.

void func(MyClass test, int a, int b);

could be called:

test.func(0, 1);

What's even better, it could be used for C libraries:

FILE* file = ... ;
file->fseek(0, SEEK_BEG); 

What are the advantages?

• Unification (as the name suggests :)). Single style for members and non member functions.
• Discoverability. It is usually faster to put object first, wait for IDE's autocomplete and then discover what methods/functions are available for the object.
• Nonmember nonfriends increase encapsulation as Scott Meyers wrote.
• The proposal suggests that the "this" parameter might be in any place of the param lists - not only in the first place.

2. Ranges

Ranges for the Standard Library: Revision 1

And the corresponding blog post from E. Neibler

Very practical and easy to use concept:

std::vector v = ...;
std::sort(v);
// not: std::sort(std::begin(v), std::end(v)); !!

So, rather than taking two iterators: begin and end, you would take a single, lightweight object: a range.

A range is an object that refers to a sequence of elements, conceptually similar to a pair of iterators

• Adapted from boost range and Adobe ASL libraries. Additionally, taking ideas from D Standard Library Ranges
• Reduces the possibility to mismatch iterators - should be less error prone
• Simplifies the code
• Adds possibility to introduce range adapters: filtering a ranges
  • For instance: auto rng = v | view::reverse (v is a container)
• A range does not own elements from underlying container

3. Modules

[PDF] A Module System for C++ (Revision 2)

C++ from the beginning has been using C style of building the code (around 40 year-old method!). It basically compiles independent CPP modules and then links them together. Every header file's content is copied into a corresponding translation unit. You all know it... for a huge project, such way of building creates a huge problem and the build time is dramatically long, especially when we add templates.

All we want is to be able to write:

import std.vector; 
import std.string; 
import std.iostream;

instead of:

#include <vector>
#include <string>
#include <iostream>

What's the main problem, why we are still forced to use headers? Mainly because, header files might contain a lot of macros and implementation code. So each translation unit might get a bit different result from preprocessor. That means, for each translation, unit header files must be compiled/processed separately. In short: a lot of processing (usually) of the same code over and over.

The proposal:

• Modules will coexist with the current method. We cannot easily replace preprocessor.
• Direct language support for modules (a module and export keyword)
• A module unit should be immune to macros and any preprocessor directives. Also, the order of consecutive import declarations should be irrelevant.

4. Multidimensional Bounds, Index and array_view

Multidimensional bounds, index and array_view, revision 4

And Lukasz's presentation from CppCon 2014 about the idea @github and @youtube

The proposal addresses the problem of using a contiguous data. We would like to have one way of handling different array concepts:

int old_skool_array[1000];
std::array<int, 1000> std_array;
std::vector<int> vec(1000);
std::dynarray<int> dyn(1000); 

Maybe, there is something better than old school C way:

int raw(int* ptr, size_t size) 

The proposal:

• Add `std::arrayview', similar to experimental std::stringview
• Extensible to support multidimensional arrays: array_view<int, 3>
• Easy to use with multidimensional arrays: bounds, indexes and iterators, slicing, sections.
• Possibility to use it with Parallelism concept

5. Resumable Functions

[PDF] Resumable Functions v.2

And the reddit discussion thread and here

Resumable functions means stackless coroutines. In other words, it is a routine that supports suspend and resume operations and it has no call stack. Or: a small lightweight program inside your code.

Stackless option gives the possibility to have millions of concurrent couroutines. Each stack is 1MB on Windows and 2MB on Linux, so if a couroutine has one, it would quickly exhaust available system memory.

The proposal adds two keywords await and yield.

await is used to suspend the coroutine and wait for another task to finish.

yield can be used to implement Generator concept (like C# IEnumerable ):

generator<int> test(int n)    {
    while (n-- > 0) {
        yield n;
    }
}
int main() {
    for (auto v : test(35)) {
        std::cout << v << std::endl;
    }
}

Your Turn

What are your types? What else should be included in the list?

Links

• The C++ Standards Committee
• The Committee: WG21
• The C++ Programming Language, 4th - Reference book from Bjarne Stroustrup
• C++ Standardization
• Urbana Proposals - C++17 insight? - Concurrency - from Meeting C++

CodeProject