139 lines
6.9 KiB
Text
139 lines
6.9 KiB
Text
Transition to C++11
|
|
===================
|
|
|
|
_this page is a notepad for topics and issues related to the new C++ standard_
|
|
|
|
.the state of affairs
|
|
In Lumiera, we used a contemporary coding style right from start -- whenever the actual
|
|
language and compiler support wasn't ready for what we consider _state of the craft_, we
|
|
amended deficiencies by rolling our own helper facilities, with a little help from Boost.
|
|
Thus there was no urge for us to adopt the new language standard; we could simply wait for
|
|
the compiler support to mature. In spring 2014, finally, we were able to switch our codebase
|
|
to C++11 with minimal effort. Following this switch, we're now able to reap the benefits of
|
|
this approach; we may now gradually replace our sometimes clunky helpers and workarounds
|
|
with the smooth syntax of the ``new language'' -- without being forced to learn or adopt
|
|
an entirely new coding style, since that style isn't exactly new for us.
|
|
|
|
Conceptual Changes
|
|
------------------
|
|
At some places we'll have to face modest conceptual changes though.
|
|
|
|
Automatic Type Conversions
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
The notion of a type conversion is more precise and streamlined now. With the new standard,
|
|
we have to distinguish between
|
|
|
|
. type relations, like being the same type (e.g. in case of a template instantiation) or a subtype.
|
|
. the ability to convert to a target type
|
|
. the ability to construct an instance of the target type
|
|
|
|
The conversion really requires help from the source type to be performed automatically: it needs
|
|
to expose an explicit conversion operator. This is now clearly distinguished from the construction
|
|
of a new value, instance or copy with the target type. This _ability to construct_ is a way weaker
|
|
condition than the _ability to convert_, since construction never happens out of the blue. Rather
|
|
it happens in a situation, where the _usage context_ prompts to create a new value with the target
|
|
type. For example, we invoke a function with value arguments of the new type, but provide a value
|
|
or reference of the source type.
|
|
|
|
Please recall, C++ always had, and still has that characteristic ``fixation'' on the act
|
|
of copying things. Maybe, 20 years ago that was an oddity -- yet today this approach is highly
|
|
adequate, given the increasing parallelism of modern hardware. If in doubt, we should always
|
|
prefer to work on a private copy. Pointers aren't as ``inherently efficient'' as they were
|
|
20 years ago.
|
|
|
|
[source,c]
|
|
--------------------------------------------------------------------------
|
|
#include <type_traits>
|
|
#include <functional>
|
|
#include <iostream>
|
|
|
|
using std::function;
|
|
|
|
using std::string;
|
|
using std::cout;
|
|
using std::endl;
|
|
|
|
|
|
uint
|
|
funny (char c)
|
|
{
|
|
return c;
|
|
}
|
|
|
|
using Funky = function<uint(char)>; // <1>
|
|
|
|
int
|
|
main (int, char**)
|
|
{
|
|
Funky fun(funny); // <2>
|
|
Funky empty; // <3>
|
|
|
|
cout << "ASCII 'A' = " << fun('A');
|
|
cout << " defined: " << bool(fun) // <4>
|
|
<< " undefd; " << bool(empty)
|
|
<< " bool-convertible: " << std::is_convertible<Funky, bool>::value // <5>
|
|
<< " can build bool: " << std::is_constructible<bool,Funky>::value // <6>
|
|
<< " bool from string: " << std::is_constructible<bool,string>::value; // <7>
|
|
--------------------------------------------------------------------------
|
|
<1> a new-style type definition (type alias)
|
|
<2> a function object can be _constructed_ from `funny`, which is a reference
|
|
to the C++ language function entity
|
|
<3> a default constructed function object is in unbound (invalid) state
|
|
<4> we can explicitly _convert_ any function object to `bool` by _constructing_ a Bool value.
|
|
This is idiomatic C usage to check for the validity of an object. In this case, the _bound_
|
|
function object yields `true`, while the _unbound_ function object yields `false`
|
|
<5> but the function object is _not automatically convertible_ to bool
|
|
<6> yet it is possible to _construct_ a `bool` from a funktor (we just did that)
|
|
<7> while it is not possible to _construct_ a bool from a string (we'd need to interpret and
|
|
parse the string, which mustn't be confused with a conversion)
|
|
|
|
This example prints the following output: +
|
|
----
|
|
ASCII 'A' = 65 defined: 1 undefd; 0 bool-convertible: 0 can build bool: 1 bool from string: 0
|
|
----
|
|
|
|
|
|
|
|
Known bugs and tricky situations
|
|
--------------------------------
|
|
Summer 2014::
|
|
the basic switch to C++11 compilation is done by now, but we have yet to deal with
|
|
some ``ripple effects''.
|
|
September 2014::
|
|
and those problems turn out to be somewhat insidious: our _reference system_ is still Debian/stable,
|
|
which means we're using *GCC-4.7* and *CLang 3.0*. While these compilers both provide a roughly complete
|
|
C++11 support, a lot of fine points were discovered in the follow-up versions of the compilers and standard
|
|
library -- current versions being GCC-3.9 and CLang 3.4
|
|
|
|
* GCC-4.7 was too liberal and sloppy at some points, where 4.8 rightfully spotted conceptual problems
|
|
* CLang 3.0 turns out to be really immature and even segfaults on some combinations of new language features
|
|
* Thus we've got some kind of a _situation:_ We need to hold back further modernisation and just hope that
|
|
GCC-4.7 doesn't blow up; CLang is even worse, Version 3.0 us unusable after our C++11 transition.
|
|
We're forced to check our builds on Debian/testing, and we should consider to _raise our general
|
|
requirement level_ soon.
|
|
|
|
Perfect forwarding
|
|
~~~~~~~~~~~~~~~~~~
|
|
The ``perfect forwarding'' technique in conjunction with variadic templates promises to obsolete a lot of
|
|
template trickery when it comes to implementing custom containers, allocators or similar kinds of managing wrappers.
|
|
Unfortunately, we ran into nasty problems with both GCC-4.7 and CLang 3.0 here, when chaining several forwarding calls.
|
|
|
|
- the new _reference collapsing rules_ seem to be unreliably still. Note that even the standard library uses an
|
|
overload to implement `std::forward`, while in theory, a single definition should work for every case.
|
|
- in one case, the executable generated by GCC passed a reference to an temporary, where it should have
|
|
passed a rvalue reference (i.e. it should have _moved_ the temporary, instead of referring to the
|
|
location on stack)
|
|
- CLang is unable to pass a plain-flat rvalue through a chain of templated functions with rvalue references.
|
|
We get the inspiring error message ``binding of reference to type `std::basic_string<char>` to a value of
|
|
type `std::basic_string<char>` drops qualifiers''
|
|
|
|
Thus -- as of 9/2014 -- the _rules of the game_ are as folows
|
|
|
|
- it is OK to take arguments by rvalue reference, when the type is explicit
|
|
- it is OK to use std::forward _once_ to pass-trough a templated argument
|
|
- but the _time is not yet ready_ to get rid of intermediary copies
|
|
- we still prefer returning by value (eligible for RVO) and copy-initialisation
|
|
- we refrain from switching our metaprogramming code from Loki-Typelists and hand-written specialisations
|
|
to variadic templates and `std::tuple`
|
|
|
|
|