Quantcast
Channel: Bartek's coding blog
Viewing all articles
Browse latest Browse all 325

My Top 5 C++ Proposals for October 2014

$
0
0

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

As it appeared, 10th October 2014 was the deadline for the pre-Urbana mailing. Now the whole list is available here at wg21. From 3rd till 8th 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 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 suggest 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 projects 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 art 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 coexists 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 programs 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


Viewing all articles
Browse latest Browse all 325

Trending Articles