C++Now 2014

It was a simpler time. A period in which every college student and learn-C++-in-a-weekend duffer could write a class with the assuredness that it would behave as desired when assigned and copied. There was a check list. Complete the checklist, add some domain specific behaviour, bake in the regression oven, and you were done.

Enter C++11 with its fancy new use of the delete keyword, additional applications of explicit, rvalue references, and some perfect forwarding. How are you to write a “simple” class? Should you include a swap? What does movable mean and are there expected semantics? When is the noexcept specifier used?

During this 90-minute session we will explore the boilerplate of a C++11 class. The session will touch on rvalue references, move semantics, perfect forwarding, explicit, noexcept, initializer lists, and more as it applies to producing the desired semantics for our classes and structs.

This hands-on graphics session will explore compile-time synthesis of n-dimensional geometries and spaces using a lightweight C++11 library called Versor, a case study in the strength of template meta-programming for generating combinatoric complexity.  Templates for constructing geometries (affine, projective, conformal, or experimental) are delineated at compile time through nimble use of variadic template programming and constant expressions.  In particular, we propose novel techniques for listing, sorting, and evaluating geometric algebras during compilation as part of a unique optimization strategy and a potentially new Boost library for n-dimensional computing.  

Discussion will be encouraged to help develop these techniques as we explore basic C++11 features to illustrate the logic of geometric algebra.   Both interactive and visual, we will examine the marriage of generic programming techniques with generic spatial computing, allowing for a dimensional fluidity of expression.  From 2D through to 4D and above, efficient implementations of concepts from group theory, vector, matrix, tensor and lie algebras can be tied to specific idioms of C++11. These function spaces have a wide range of applications in a diverse set of fields, from material science to quantum computation.  An example of videos created with this approach can be seen at vimeo.com/wolftype.  More information about Versor is available at versor.mat.ucsb.edu.

Integer arithmetic in C-derived languages is notoriously dangerous. Signed overflow is undefined behavior; unsigned overflow silently wraps around; comparing a signed and unsigned integer implicitly promotes to unsigned, causing a signed -1 to be greater than an unsigned 12; even the guaranteed size of "int" is less than most people expect and require. Most attempts to remedy the situation add in run-time overhead to all integer operations, making them non-starters for many projects.

This talk presents the bounded::integer library (https://bitbucket.org/davidstone/bounded_integer). bounded::integer is a C++14 library that has the following goals:

1. Never perform a run-time check when a compile-time check would work instead.
2. Never allow a conversion that is definitely wrong.
3. Allow conversions that might be wrong (such as assigning a value between 1 and 10 to a value between 5 and 20), but
only when explicitly requested.
4. Allow implicit conversions to larger types.
5. Have no space or time overhead, assuming basic compiler optimizations like inlining, so that bounded::integer can be used on very large data sets or systems with hard real-time requirements.

bounded::integer provides these guarantees by requiring static bounds on the integer types. A typical declaration might look something like `bounded::integer<1, 10> x(5)` to create a type that is always between 1 and 10. Arithmetic expressions automatically adjust the bounds to keep the result in range. In other words, the result of `x + x` is given the type `bounded::integer<2, 20>`. Thanks to type deduction with auto and templates, the user can specify only the types that they care about and be guaranteed (at compile time) that all intermediate calculations will be correct. Even better, because the compiler knows exact bounds of all integers, the library allows space and time optimizations that actually allow code to run faster than the default "use int everywhere to avoid surprises" strategy.

 This talk will include proposed idioms for using the library; prior work, such as boost::constrained_value, integer types in Ada, and the As-if Infinitely Ranged integer model; and limitations / design trade offs of the library.

The Boost C++ libraries have a well deserved reputation for excellence, and the prospect of contributing to them can be a bit overwhelming. My talk will focus on demystifying the process of porting a preexisting library to Boost through illustrative examples of my experiences preparing AFIO, the first C++11-only Boost Library to enter peer review, during 2013's Google Summer of Code. Because AFIO’s pre-Boost codebase was entirely C++11, many of these examples should highlight issues facing developers wanting to backport modern C++, and also show one possible set of solutions to those issues. From internal compiler errors to tackling the Boost build system, the process will be revealed, and hopefully become less daunting as the problems I encountered and their solutions are presented.

This talk has two distinct but related goals. The first is to present a survey of C++11 template metaprogramming techniques, along with benchmarks and case studies, in an attempt to spot improvements over C++03. This will provide an objective basis upon which the future of the current Boost.MPL can be discussed. The second is to present a general purpose C++11 template metaprogramming library which I hope to propose for inclusion into Boost, perhaps as a successor to the current Boost.MPL (github.com/ldionne/mpl11). I will introduce the core concepts of the library, explain some design choices and perform an objective comparison with the current Boost.MPL.

The talk is intended for people with a good knowledge of TMP and functional programming. People making extensive use of TMP and those interested in FP should benefit most from the presentation.

This is the first of two presentations on the new features of C++11/14. It covers most of the smaller aspects of the language:

• C++ Timeline


• Goals for C++11/14


• The Simpler Core Language Features


• auto, decltype, trailing return types


• Non-member begin/end


• nullptr


• Range for


• >> in template specializations


• static_assert


• extern template


• noexcept


• Variadic templates


• constexpr functions and data


• Template alias


• New character literal types


• Raw string literals


• Literal strings and const

There's also brief coverage of scoped enums, long long, alignas/of, attributes, inline namespaces, generalized unions/PODs, garbage collection ABI, and user-defined literals.

This is the second of two presentations on the new features of C++11/14. It covers the meatier features added to the language:

• Class design features: default and deleted generated functions, delegating and inheriting constructors, new flexibility for in-class initializers, and explicit conversion operators


• Initialization: initializer lists, uniform initialization, and narrowing prevention


• Lambdas


• Rvalue references: lvalues and rvalues (the modern view), move semantics, universal references, perfect forwarding

This talk will help to answer common questions related to writing and building cross-platform software.  How can software be built natively on Windows and Linux, given their radically different tool chains?  How can the various programming and deployment differences between Linux and FreeBSD be managed?  How can the cross-tool, cross-platform editing problems be solved?  How can the dramatic maintenance cost increase be prevented?  This talk also addresses the non-obvious, indirect benefits of supporting multi-platform development.

Developing metaprograms is hard and painful. Templight (http://plc.inf.elte.hu/templight/) supports the development and debugging of template metaprograms, but the code has to be recompiled after every minor change and tricks are needed to retrieve useful information about the result.

A number of languages (Python, Haskell, Erlang, etc) provide an interactive shell for trying code out and displaying the results immediately. For example adding a new element to a list and displaying the result in a Python shell is an easy thing to do:

> l = [2, 3, 4]
> l.insert(0, 1)
> l
[1, 2, 3, 4]

The shell can display the result immediately. The developer does not need to compile his code and start up a debugger to see the result of an expression.

This talk presents Metashell, which is an interactive shell for template metaprogramming. It provides a testing and development environment for template metaprogramming which is as easy to use as a Python shell. For example one can do the following:

> #include <boost/mpl/vector.hpp>
> #include <boost/mpl/push_front.hpp>
> #include <metashell/formatter.hpp>
> using namespace boost::mpl;

> push_front<vector<int, char>, double>::type
boost_::mpl::vector<double, int, char>

The shell displays the result of a template metafunction.

Metashell is available here: https://github.com/sabel83/metashell. One can try it online in a browser as well: http://abel.web.elte.hu/shell. Metashell is based on the libClang library.

smile the senses
action/reaction, cause/effect
what are these symbols?

This is possibly a talk about UI. Probably about Aesthetics. Definitely about C++. Hopefully pertinent to both newer programmers and seasoned developers. A bit philosophical, but applicable to daily code.

Definitely not about lockfree programming, for a change. :-)

C++ — with the help of newly adopted, fast evolving, development cycles — has become the assembly language of the current generation. C++11, by itself, can provide the necessary building blocks to develop a brand new, domain independent language that supports native parallelism.

Doppl is a programming language which features cache efficiency, high concurrency, data oriented design, and non-blocking logic as language constructs. It is built on top of C++11 and its latest stable standard library implementations.

In this talk, we will focus on using tools from <thread> as well as new constructs inherited from functional programming, and introduced first in C++11, to achieve Doppl's features. Doppl code samples will only be shown as references for the audience to visualize these high level structures.

Refactoring tools for C++ have lagged behind those available in other languages. We've all heard the excuses about how C++ is too hard to parse and too hard to reason about. Well, get ready to have your socks blown off by the tooling infrastructure provided with clang. It makes writing refactoring tools simple and easy.

In this talk, I will incrementally develop a refactoring tool with clang that transforms a "(void)" function argument list to an empty argument list: "()".  This will give you a concrete example of how to apply the tooling library from clang: exploring the parsed abstract syntax tree (AST), writing code that matches elements of the AST, and operating on the matched nodes to create source code transformations that are applied by the tooling library.

If time is available, we'll look at some other examples of refactoring tools and discuss how they operate.

One of the most powerful features of C++ is deterministic, scope based object lifetimes. Used properly, this can help ensure that your code is does not leak resources and is exception-safe. In this talk, I will show examples and discuss techniques that you can use to make your code simpler, easier to read, and more obviously correct. 

We'll start with the basics of construction/destruction, move on to RAII and smart_pointers, then discuss exception safety, and finish up with a discussion about ownership when passing parameters. 

Along the way, I will discuss the changes in C++11 and C+14 that make this style of programming easier.

The Expected library is based on the Expected class introduced by A. Alexandrescu in 2012. It is a new way to handle errors in C++, lying somewhere between the classic error-code returns and exceptions. Expected is fully compatible with exception-throwing code and helps to design exception-free interfaces. This open the door to novel techniques enforcing error handling safety while keeping code clean through the use of monads, which are borrowed from functional languages like Haskell. No prior knowledge of monads is needed, however.

The talk will start with a presentation of the existing techniques for handling errors. We will compare the return error code and the exception systems and then we will introduce expected in this context. The std::future and the std::experimental::optional classes are similar utility classes and we will speak about the conceptual differences among these classes.

The core of the Expected library will be presented next using an example to show the different features and semantics of the expected class. We will discuss how the expected class can be used to define exception-free interfaces using any user defined error type.

The monad error methods next and recover will be presented then through several examples. They enable programming techniques that help to distinguish the error-handling layer from the normal code flow. Moreover, they help the programmer to handle errors in a non-invasive way while being visible if forgotten. We will briefly talk about monads in functional languages and why expected can be seen as a monad.

The rest of the talk will discuss the possibility of using a similar interface for other potential monad classes such as std::experimental::optional and std::future.

As for Haskell monads, some syntactic sugar could make the code more readable. We will present how the use of a new expect expression, similar to the await expression presented in N3858 Resumable functions,  could make the code as readable as if the function could throw an exception.

Note: This library has not been proposed yet to the C++ standard, but should be by the time of the conference.

In this talk, we will cover various popular methods of defining ownership of an object: automatic variables ("stack based"), raw pointers, and smart pointers. We also put forth a minor improvement to the collection of smart pointers available in the C++ standard library. 

Most treatments of the ownership topic in C++ briefly mention performance (if at all), with most of the focus being on simply convincing people to use (or not use) them. This talk, however, will have a significant component dedicated to how to effectively optimize time and memory usage while retaining correctness. 

The focus of this talk will be on ownership as it relates to memory. We will briefly touch on important principles such as RAII, but only in the context of memory management, not general resource management. 

OpenCL, CUDA, C++ AMP, OpenACC, RenderScript, Thrust, Bolst, Vexcl, Boost.Compute, ViennaCL, MTL4, NT2, Arrayfire — the list of tools, environments, frameworks and libraries for accelerator programming is long. This talk will give an overview of a number of these tools and map them to different cases of accelerator use. How do they compare in terms of developer productivity, generality, and performance?

With all these tools at our disposal, the problem of accelerator programming is far from solved. There must be a better way to describe data parallelism and concurrency in C++. Maybe the functional programming community can come to our rescue? Or, as Bret Victor put it so appropriately, we must simply "forget everything we think we know about computers. Forget that we think we know what a computer is" to find a good solution. Comments from the audience are welcome for this second part of the talk.

C++ 98/03 already has a reputation for overwhelming complexity compared to other programming languages. The raft of new features in C++ 11/14 suggests that the complexity in the next generation of C++ code bases will overwhelm still further. The planned C++ 17 will probably worsen matters in ways difficult to imagine presently.

Countervailing against this rise in software complexity is the hard de-exponentialisation of computer hardware capacity growth expected no later than 2020, and which will have even harder to imagine consequences on all computer software. WG21 C++ 17 study groups SG2 (Modules), SG7 (Reflection), SG8 (Concepts), and to a lesser extent SG10 (Feature Test) and SG12 (Undefined Behaviour), are all fundamentally about significantly improving complexity management in C++ 17, yet WG21's significant work on improving C++ complexity management is rarely mentioned explicitly.

This presentation pitches a novel implementation solution for some of these complexity scaling problems, tying together SG2 and SG7 with parts of SG3 (Filesystem): a standardised, but very lightweight, transactional graph database based on Boost.ASIO, Boost.AFIO and Boost.Graph at the very core of the C++ runtime, making future C++ codebases considerably more tractable and affordable to all users of C++.

Position Paper (Right click and save as.) 

...