After C++11 revision has been approved a new cycle of C++ design has begun:
N3370: The C++ standards committee is soliciting proposals for additional library components. Such proposals can range from small (addition of a single signature to an existing library) to large (something bigger than any current standard library component).
At this stage it's interesting to read papers, as authors try to express ideas rather than to formulate sentences that should go into spec as it lately was.
These are just several papers that we've found interesting:
Those proposals argue about compile time "if statement". The feature can replace #if preprocessor directive, a SFINAE or in some cases template specializations.
#if
A static if declaration can appear wherever a declaration or a statement is legal. Authors also propose to add static if clause to a class and a function declarations to conditionally exclude them from the scope.
static if
Examples:
// Compile time factorial. template <unsigned n> struct factorial { static if (n <= 1) { enum : unsigned { value = 1 }; } else { enum : unsigned { value = factorial<n - 1>::value * n }; } }; // Declare class provided a condition is true. class Internals if (sizeof(void*) == sizeof(int));
Paper presents strong rationale why this addition helps to build better programs, however the questions arise about relations between static if and concepts, static if clause and an error diagnostics.
That's our favorite.
Authors propose an API and a language extensions to make asynchronous programs simpler.
In fact, asynchronous function will look very mush as a regular one but with small additions. It's similar to yield return in C# (a construct that has been available in C# for many years and is well vetted), and to async expression in C# 4.5. Compiler will rewrite such a function into a state machine, thus function can suspend its execution, wait for the data and to resume when data is available.
yield return
async
Example:
// read data asynchronously from an input and write it into an output. int cnt = 0; do { cnt = await streamR.read(512, buf); if (cnt == 0) { break; } cnt = await streamW.write(cnt, buf); } while(cnt > 0);
It's iteresting to see how authors will address yield return: either with aditional keyword, or in terms of resumable functions.
Here authors try to justify rich type-info but mask it under the name "rich pointers". To make things even more obscure they argue about dynamic code generation.
If you want a rich type-info then you should talk about it and not about thousand of other things.
We would better appealed to create a standard API to access post-compile object model, which could be used to produce different type-infos or other source derivatives.
This paper is our outsider. :-)
Here people try to generalize (put you away from) locking, and replace it with other word "transaction".
Seems it's not viable proposition. It's better to teach on functional style of programming with its immutable objects.
Author argues against C style source composition with #include directive, and propose alternative called "modules".
#include
We think that many C++ developers would agree that C pre-processor is a legacy that would never have existed, but for the same reason (for the legacy, and compatibility) it should stay.
In out opinion the current proposition is just immature, at least it's not intuitive. Or in other words there should be something to replace the C pre-processor (and #include as its part), but we don't like this paper from aestetic perspective.
This proposal says no a word about asynchronous nature of file access, while it should be designed around it.
Remember Me
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u