C++Now 2016

Digital signal processing is ubiquitous in modern digital technology. Ranging from classical signal transmission, neural networks, image and audio processing, to time series analysis. Flowz is a library that strives for writing digital signal processors in a declarative and composable manner that generate efficient code and integrates well with existing C++ code and frameworks. Flowz is inspired by the Faust language and algebra of flownomials and implements a similar concept within C++. This embedded domain specific language allows to describe network layouts and processing of data flowing through these networks. While the user can focus on the 'what should be processed', flowz will take care of connecting the *wires* between processing boxes and creating the state that is described implicitly by the flowz-expressions and which is needed by the signal processing algorithm.

All essential behavior of our software must be documented, and yet there are important advantages, with respect to development, verification and testing, performance, and stability, for leaving the behavior for some combinations of inputs and initial conditions undefined. What is and is not defined behavior should therefore be readily discernible from the contract, especially when creating contracts that must span classes related by inheritance. In Part I of this talk, we review components, interfaces and contracts in general, and the significance of *narrow* versus *wide* contracts in particular. In Part II, we explore _three_ kinds of inheritance: (1) *Interface* *Inheritance* resulting from pure-virtual functions, (2) *Structural* *Inheritance* resulting from non-virtual functions, and (3) *Implementation* *Inheritance* resulting from non-pure virtual functions. Proper contracts involving each of these distinct forms have different criteria that must be addressed. The three kinds of inheritance are compared, and their relative utility is explained. What's more, several common uses of inheritance that are provably improper are summarily debunked.

All essential behavior of our software must be documented, and yet there are important advantages, with respect to development, verification and testing, performance, and stability, for leaving the behavior for some combinations of inputs and initial conditions undefined. What is and is not defined behavior should therefore be readily discernible from the contract, especially when creating contracts that must span classes related by inheritance. In Part I of this talk, we review components, interfaces and contracts in general, and the significance of *narrow* versus *wide* contracts in particular. In Part II, we explore _three_ kinds of inheritance: (1) *Interface* *Inheritance* resulting from pure-virtual functions, (2) *Structural* *Inheritance* resulting from non-virtual functions, and (3) *Implementation* *Inheritance* resulting from non-pure virtual functions. Proper contracts involving each of these distinct forms have different criteria that must be addressed. The three kinds of inheritance are compared, and their relative utility is explained. What's more, several common uses of inheritance that are provably improper are summarily debunked.

Boost has a great Boost.MSM library. Boost.MSM - eUML is even better because it provides a DSL for creating transition tables. However, it is really hard to use Boost.MSM library on a larger scale due to horrible compilation times and big executable files. Guess what, experimental Boost.MSM-lite is going to change it! During this lecture you will be shown how C++14 was used to achieve the following: - faster compilation times - up to 60x times faster than Boost.MSM - smaller executable size - up to 15x smaller - slightly better performance than Boost.MSM! - smaller memory usage - short error messages After this part you will understand what Meta State Machine is, why it is so useful and how experimental Boost.MSM-lite can achieve the above goals.

RaftLib aims to make authoring performant parallel applications in C++ simple. It utilizes the familiar semantics of stream operators to link multiple parallel actors into a single multi-threaded, streaming application. Stream processing is a compute paradigm that has been around for decades, yet until recently has failed to garner the same attention as other mainstream languages and libraries for parallel processing (e.g., C++, OpenMP, MPI). RaftLib aims to fully exploit the stream processing paradigm, enabling a full spectrum of streaming graph optimizations, while providing a platform for the exploration of integrability with legacy C/C++ code. RaftLib is built as a C++ template library, enabling programmers to utilize the robust C++ standard library, and legacy code, along with RaftLib’s parallelization framework. This session covers what RaftLib is, how it works, how to use it, and lastly we'll have some hands on application building.

This is an information/work session for the C++Now Program Committee.

We will discuss the review the Reviewers' Guide ways to impove our process and product:
https://docs.google.com/document/d/1Z1PXETemPj0FP_i_zqt1YFHK4KiFYAiGTvbpVa2kKE0/edit?usp=sharing

Note: Boost will cater this meeting for attendees that sign up by the end of Wednesday morning's break. 

In this talk we illustrate how to use the Boost.Coroutine library to invert visitor-based control flows. We show this technique by combining Boost.Coroutine with Boost.Graph to step through and resume visitor-based algorithms. In doing so we highlight a different interface to the visitor-based approach that is more readable, more maintainable and highly performant. The audience need not already be familiar with Boost.Coroutine or Boost.Graph.

Supplementary material is available at: https://github.com/daniel-j-h/cppnow2016

An alternative to deep inheritance trees for game and application architecture design is "composition". Separating data from logic allows the code to be more reusable and more efficient, alongside additional benefits. Using modern C++14 features and heavy metaprogramming, it is possible to design an efficient and user-friendly compile-time multithreaded component-based entity system library, striving for intuitive syntax and cost-free abstractions. By leveraging the compile-time knowledge regarding components and systems, the implementation can figure out what computations can run in parallel and how to efficiently store and manage components.

Developers often complain that there is no practical usage for some design patterns like Dependency Injection. This tutorial will prove them wrong. It will show them how to use the whole potential of Dependency Injection/Meta State Machine/MSVC to make a game/app quickly with minimal maintenance as well as testing support. During this tutorial we are going to create a match-3 game for the WEB using only C++14 features, Emscripten and mentioned experimental Boost.DI/Boost.MSM-lite libraries. After this tutorial you will have more knowledge about Dependency Injection/Meta State Machine and how they fit together. On top of that you will see how to use Emscripten and C++14 in order to create cross-platform games/apps. Experimental Boost.DI Although Dependency Injection is a popular concept in Java and C# it's not a first class citizen in C++. The reasons behind this are mostly related to the missing C++ features like reflection and popular believing that Dependency Injection will slow down the execution. Well, that could have been true a few years ago, however experimental Boost.DI is going to change this belief! During this lecture you will be exposed to main features of experimental Boost.DI, such as: - how it is possible to create objects without macros and reflection support? - how there is no performance overhead when using experimental Boost.DI? - how experimental Boost.DI provides a compile time guarantee when creating objects? - how experimental Boost.DI compiles so fast? - how experimental Boost.DI gives short error messages without using concepts? After this part you would have a better understanding of the Dependency Injection and how C++14 made it possible. Experimental Boost.MSM-lite Boost has a great Boost.MSM library. Boost.MSM - eUML is even better because it provides a DSL for creating transition tables. However, it is really hard to use Boost.MSM library on a larger scale due to horrible compilation times and big executable files. Guess what, experimental Boost.MSM-lite is going to change it! During this lecture you will be shown how C++14 was used to achieve the following: - faster compilation times - up to 60x times faster than Boost.MSM - smaller executable size - up to 15x smaller - slightly better performance than Boost.MSM! - smaller memory usage - short error messages After this part you will understand what Meta State Machine is, why it is so useful and how experimental Boost.MSM-lite can achieve the above goals.

IoC++ is a library for doing dependency injection in C++. It is designed to allow configuration of object graphs at runtime via code or configuration files, with high flexibility in the creation and lifetime management of objects. The library was developed in-house at the Symena branch of TEOCO, but is in the process of being open-sourced and will, if sufficient interest is generated, be proposed for inclusion in Boost. The concepts and workings of the library will be explained, and the library will be compared to similar ones in the field such as the proposed Boost.DI.

The Effective Structured Data Marshalling/Demarshalling Through Boost.Fusion Introspection In A High Performance Web Service The Yandex company is the one of the biggest internet companies in Russia. We provide various users' network interactive services, such as: web-search, e-mail, maps, photohosting and so on. Our team is developing e-mail backend. Message receiving, handling, sending are most typical tasks in backend service. At C++Now 2014 we talked about the optimization of a Boost.Asio-based networking server. Now we want to talk about effective data marshalling and demarshalling which is taking a significant part of our internal web services workload. In this talk we are looking for generic solution of effective marshalling and demarshalling of a structured data like instances of structures, STL containers, classes and so on. We start from the simple implementation which is based on the Boost.Fusion framework, discuss the problems and limitations of this solution. Then we propose different workarounds and optimisations of the solution to achive the performance. We propose solutions based on following key points: * minimization of data copying in order to decrease CPU and memory usage; * elimination of hidden synchronization and locks to provide maximum parallelism and independed work of the solution in different threads; * asynchronous interfaces to use callbacks and/or coroutines for the IO events handling; * stream-like raw data and structured objects processing. For each of these points we provide overview on how it affects total performance.

The current trend of large scientific computing problems is to to align as much as possible to Single Programming Multiple Data (or SPMD) scheme when the application's algorithms are conducive to vectorization. This reduces the complexity of code because the processors or (computation nodes) perform the same instructions, and allows for better performance as algorithms work on local data sets instead of transferring the data from one node to another. However, certain problems such as, stencils problems, demonstrate the need to move data to or from remote localities. It involves an additional degree of complexity, if only to know with which locality to interact to send/receive a given data. To solve both these two issues, Fortran has extended its scalar element indexing approach for distributed structures of elements. In this extension, a structure of element is attributed a "co-index" and lives in a specific locality. A co-index provides the application with enough information to retrieve the corresponding data reference. In C++, containers present themselves as a "smarter" alternative of Fortran arrays but there are still no corresponding features similar to the Fortran co-indexing approach. In this paper, we present an implementation of such features in HPX, a general purpose C++ runtime system for applications of any scale. We describe how the combination of the HPX concepts and new features from C ++ language makes it easy to define a high performance API similar to coarray FORTRAN.

At C++Now 2015 I introduced build2, a new C++ build system. A year later, a lot has happened. Most significantly, there is now a package manager (bpkg), a repository web interface (brep), and a public repository of open source C++ packages, cppget.org. Also, the build system has seen a lot of development. But in this talk I don't want to give you a run down of the new features. Ok, maybe just a short introduction, to set the context. Instead, I would like to talk about interesting problems in the cross-platform C++ building and distribution process, how we decided to tackle them in build2 (and then, I am sure, someone from the audience will tell me why it's all wrong ;-)). What are the interesting problems? Cross-compilation (something is wrong with your build system if it's harder to cross-compile than build natively on Windows), in/out-of-source builds, interaction of generated source code with automatic dependency extraction, or high fidelity builds (what if I changed my compiler options), just to name a few. Seemingly benign decisions, such as relative vs absolute paths, can open (or close) doors to really powerful features, like updating multiple, unrelated projects or even multiple configuration of the same project with a single build tool invocation. A C++ build system also rarely handles just building. There is testing, installation (do we really have to run the whole process as sudo?), and preparation of distributions (no, shipping your .gitignore files is not cool). When it comes to packaging, how do we capture requirements (like C++11 or Linux-only) and conditional dependencies? How do we ensure package authenticity? And what should the submission policies and procedures be for a package repository like cppget.org?

Boost.Build is the build system used by the Boost C++ libraries. A basic understanding of this tool is a must for anyone who intends to submit a library to Boost. In this session, I will discuss basic usage, advanced usage, and troubleshooting.

This is an information/work session for Boost.

Open to anyone interested in exploring the use of CMake in addition to Boost Build.

Note: Jeff Garland will be cooking chicken and burgers from the picnic.

The concept of executors, introduced by proposal N4406, has created a possibility for a flexible and dynamic choice of execution platform for STL algorithms. HPX implements executors to support serial and parallel execution of algorithms on CPUs. However, current solutions do not utilize the power of GPUs. The support for GPGPU frameworks has become a standard in modern graphic processors, but the usage of computing power provided is still far from common. The most frequent reasons include: less intuitive programming model, more complex architecture of both memory and streaming processors, and the host-device paradigm which enforces manual data transmission and synchronization. There is a need for parallelization including not only CPUs which can be easily introduced into applications, even by programmers who are not experienced in neither architecture nor programming languages of GPUs. We have been working on bringing GPU parallelization into HPX implementation of parallel STL. For this task, we have chosen two industrial standards for automatic parallelization of C++ into the device code: C++AMP, an open standard proposed by Microsoft, and SYCL, which has been recently introduced by the Khronos Group. Our approach is based on code generated for OpenCL which makes it fully portable and platform independent. Our solution includes the extension of existing implementation with both synchronous and asynchronous GPU executors. This approach allows for minimizing developer’s work, who is not forced to write code responsible for data transfers. Templated design of algorithms encapsulates all buffering and synchronization which is necessary for execution on GPU. An additional configuration allows the optimization of performance by choosing a block size for a GPU thread. HPX has been integrated and tested with the latest and still developed Clang-based compilers, open source Kalmar, which implements AMP standard, and commercial ComputeCpp providing support for Khronos SYCL. Although both compilers are not bug-free and ready for release, the results of our project prove that these standards can be integrated with an existing, complex and mature C++ project.

When we read a function declaration, what expectations do we have of the function? What requirements and limitations do we take for granted? Our unspoken assumptions about function interfaces present an obstacle to precise reasoning about programs. 

Here, I will delve into the nitty-gritty procedural logic of function calls in C++, with particular emphasis on the things that often go without saying. I will present some suggestions about how we can make these implicit expectations precise, and how we can express deviation from these expectations in current and future versions of C++. 

This presentation will be a companion to my C++Now 2015 session, "How we reason about procedural programs," but no knowledge of that material will be necessary.