advanced

CppCon 2014 Generic Programming with Concepts Lite, Part II—Andrew Sutton

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Generic Programming with Concepts Lite, Part II

by Andrew Sutton

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

In this talk, I will give an overview of the Concepts Lite language extension for C++ and present examples of its use in design and implementation of real-world generic libraries. Concepts Lite provides the ability for programmers to directly state constraints on template arguments as part of the template declaration. These constraints are predicates which determine whether or not a template argument can be used with that template. Constraints are checked by the compiler at the point of use, meaning that that effectively constrained generic libraries will not suffer from the usual problems of insane diagnostics. Libraries written using concepts will be far more readable and maintainable than the status quo. This talk will focus on generic programming, proposed language features, and their use in building real-world libraries.

Concepts Lite is a forthcoming ISO Technical Specification (TS) aimed at publication alongside C++14. Concepts Lite is implemented in a branch of GCC, which will be made available to the audience for experiments and experience.

CppCon 2014 Generic Programming with Concepts Lite, Part I—Andrew Sutton

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Generic Programming with Concepts Lite, Part I

by Andrew Sutton

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

In this talk, I will give an overview of the Concepts Lite language extension for C++ and present examples of its use in design and implementation of real-world generic libraries. Concepts Lite provides the ability for programmers to directly state constraints on template arguments as part of the template declaration. These constraints are predicates which determine whether or not a template argument can be used with that template. Constraints are checked by the compiler at the point of use, meaning that that effectively constrained generic libraries will not suffer from the usual problems of insane diagnostics. Libraries written using concepts will be far more readable and maintainable than the status quo. This talk will focus on generic programming, proposed language features, and their use in building real-world libraries.

Concepts Lite is a forthcoming ISO Technical Specification (TS) aimed at publication alongside C++14. Concepts Lite is implemented in a branch of GCC, which will be made available to the audience for experiments and experience.

Range comprehensions with C++ lazy generators—Paolo Severini

From a totally unnecessary blog (we beg to differ):

Range comprehensions with C++ lazy generators

by Paolo Severini

From the article:

Lazy evaluation is a powerful tool and a pillar of functional programming; it gives the ability to construct potentially infinite data structures, and increases the performance by avoiding needless calculations ...

... Functional languages like Haskell have the concept of list comprehensions ... In C#, of course, we have LINQ ... It would be nice to have something similar in an eager language like C++ ... now the lazy, resumable generators proposed by N4286 seem perfect for this purpose ... We can use the VS2015 CTP prototype to experiment with this idea ...

Iterators++, Part 3—Eric Niebler

Eric Niebler concludes his series about proxy iterators with:

Iterators++, Part 3

by Eric Niebler

From the article:

This is the forth and final post in a series about proxy iterators, the limitations of the existing STL iterator concept hierarchy, and what could be done about it. The first three posts describe the problems of proxy iterators, the way to swap and move their elements, and how to rigorously define what an Iterator is.

This time around I’ll be focusing on the final problem: how to properly constrain the higher-order algorithms so that they work with proxy iterators.

A conditional copy constructor—Andrzej KrzemieĊ„ski

Andrzej writes in his recent blog about an issue library writers have to take care of.

A conditional copy constructor

by Andrzej Krzemieński

From the article:

In this post we will try to define a ‘wrapper’ class template that does or does not have a copy constructor depending on whether the wrapped class has it. This will be a good opportunity to explore in depth a couple of advanced C++ features. Note that this is a rather advanced topic and, unless you are writing or maintaining a generic library, you will probably never need this knowledge.

SFINAE std::result_of? Yeah, right!—Scott Prager

On the matter of having a useful error message:

SFINAE std::result_of? Yeah, right!

by Scott Prager

From the article:

Return type deduction pre-decltype and auto could really make one mad. Back then, if you wanted a function object, you had to make it "adaptable", meaning it had to inherit from std::unary_ or binary_function and define its first_argument_type, second_argument_type, and result_type. There had been no concept of "transparent functors" allowing us to pass polymorphic functions to higher order functions (like std::plus<> to std::accumulate). For an example of programming in these dark ages, check out the FC++ FAQ.

 

CppCon 2014 Using C++ on Mission and Safety Critical Platforms—Bill Emshoff

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Using C++ on Mission and Safety Critical Platforms

by Bill Emshoff

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

The Joint Strike Fighter (JSF) is the first major DOD aircraft program to use C++. Much of this software is either safety critical or mission critical and so must be written in such a way as to be clear, readable, unambiguous, testable, and maintainable. We discuss the driving requirements behind the standard and its evolution. We give a quick overview of our standard and discuss how it differs from later standards such as MISRA C++. We discuss lessons learned over our nine year history of applying the standard to a large embedded software program. We also address ambiguities in rules and difficulties with automated checking of conformance with the standard.

CppCon 2014 Type Deduction and Why You Care—Scott Meyers

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Type Deduction and Why You Care

by Scott Meyers

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++98 had template type deduction, and it worked so intuitively, there was little need to understand what took place under the covers. C++11 extends type deduction to include universal references, applies it to auto variables and lambda expressions, then throws in a special auto-only deduction rule. C++14 pushes the boundary further, adding two forms of function return type deduction (auto and decltype(auto)) for arbitrary functions and offering auto parameters for lambdas. The result is that what could be treated as a black box in C++98 has become a topic that practicing C++ developers really need to understand. This talk will give you the information you need to do that.

Iterators++, Part 2—Eric Niebler

Eric Niebler goes deeper into Iterator details in his new blog post

 

Iterators++, Pat 2

by Eric Niebler

From the article:

This is the third in a series about proxy iterators, the limitations of the existing STL iterator concept hierarchy, and what could be done about it. In the first post I explained what proxy iterators are (an iterator like vector<bool>‘s that, when dereferenced, returns a proxy object rather than a real reference) and three specific difficulties they cause in today’s STL:

  1. What, if anything, can we say in general about the relationship between an iterator’s value type and its reference type?
  2. How do we constrain higher-order algorithms like for_each and find_if that take functions that operate on a sequence’s elements?
  3. How do we implement algorithms that must swap and move elements around, like sort and reverse?