Home » Blog » Tags » intermediate

intermediate

CppCon: My Proposed Talks (Part 1) -- Herb Sutter

By Blog Staff | May 20, 2014 07:24 AM | Tags: intermediate

cppcon-109.PNGWith the CppCon talk submission deadline upon us, we're starting to get glimpses of the potential CppCon conference program. In today's post, Herb Sutter mentions three of his five talk proposals (note: pending review and selection by the program committee, so this is not final -- they may or may not be selected if there is stronger material).

CppCon: My Proposed Talks (Part 1)

by Herb Sutter

From the post:

Lock-Free Programming – or, How to Juggle Razor Blades (~2 hours)

Example-driven talk on how to design and write lock-free algorithms and data structures using C++ atomic<> – something that can look deceptively simple, but contains very deep topics. (Important note: This is not the same as my "atomic<> Weapons" talk; that talk was about the "what they are and why" of the C++ memory model and atomics, and did not cover how to actually use atomics to implement highly concurrent algorithms and data structures.)

This talk is about the "how to use them successfully" part of atomics, including:

  • Best practices and style for using atomic<>s
  • Three or more examples, including lock-free mail slots and iterations of a lock-free linked list, all in portable Standard C++
  • Defining and applying the different levels of "lock-freedom" (wait-free, lock-free, obstruction-free) to develop highly concurrent algorithms and data structures
  • Explaining and applying key concepts including especially: linearizability; trading off concurrency vs. promptness; and trading off concurrency vs. throughput/utilization
  • Demonstrating and solving the ABA problem, with clean and simple code – that's right, did you know that in C++11 you can solve this without relying on esoterica like double-wide CAS (which isn’t always available) or hazard pointers (which are deeply complex) or garbage collection (which isn’t in the C++ standard... yet)?

Standardization Update: C++14 and the Seven Dwarfs (1 hour)

Standardization has accelerated: By the time we meet at CppCon, C++14 might already be ratified. But that's only one of eight (so far) work items now in flight. In this session, I'll give a brief summary of the new features coming in C++14 itself, and then a tour of the seven (7) near-term separate Technical Specifications already underway – think of these as the "C++14 wave" of deliverables.

The ISO C++ committee has transitioned to a "decoupled" model where updated versions of the standard are published more frequently, while at the same time major pieces of work can progress and be published independently from the Standard itself and delivered asynchronously in the form of Technical Specifications (TS’s) that are separate from the main Standard and can later be incorporated into the Standard. Come to this session to see how this is helping both the standard and C++ compiler implementations near you stay current with the latest in C++.

The topics covered will be:

  • C++14: What’s new in the new standard due this year
  • File System TS: Portable file system access
  • Library Fundamentals TS (small): string_view and optional<>
  • Array Extensions TS: Language and library dynamic arrays
  • Concepts Lite TS: Templates + constraints = ++usability and ++diagnostics
  • Concurrency TS: Nonblocking futures (.then, .when_*), executors, and (maybe) await
  • Parallelism TS: A whole new Parallel STL with both parallel and vector execution support
  • One of:
        – Networking TS (small): IP addresses, URIs, byte ordering
        – Transactional Memory TS: Language and library extensions for transactional memory instead of mutexes for many kinds of concurrency control

This session will present an overview of each set of features, what it looks like and how to use it, and why it’s important for the standard and for your own portable C++ code.

Modern C++ Style: Idioms of C++11/14 (1 to 3 hours)

This session will cover modern and current C++ style, focusing on C++14. It will demonstrate how major features and idioms from C++98 are now entirely replaced or subsumed and should be used no more; how other major features and idioms have been dramatically improved to the point where your code is cleaner and safer and you’ll even think in a different style; and how pervasive styles as common as variable declarations are changed forever, and not just for style but for serious technical safety and efficiency benefits. For one thing, you’ll never look at auto the same way again – and if hearing that makes you worry, worry not, just attend the session to dig deep into the good reasons for the new reality.

Why C++14? Two reasons: First, it really does "complete C++11" with small but important consistency features like generic lambdas and make_unique that let us teach modern C++ style with fewer “except for” footnotes. Second, C++14 “is” C++ for the next several years and it’s real; it is feature-complete and in the final stages of standardization, and more importantly we are already seeing near-complete conforming implementations becoming widely available around the same time C++14 is expected to be formally published.

C++14 is a small but important improvement on C++11 that really does complete the language. What this means is that we’re going to have a complete and simpler set of idioms and styles to learn and use.
 

Fast Polymorphic Collections with Devirtualization -- Joaquín M López Muñoz

By Blog Staff | May 9, 2014 08:17 AM | Tags: intermediate

munoz.pngStill on the theme of "contiguous enables fast," a followup on the recent "Fast Polymorphic Collections" article:

Fast Polymorphic Collections with Devirtualization

by Joaquín M López Muñoz

From the article:

The poly_collection template class we implemented for fast handling of polymorphic objects can be potentially speeded up in the case where some of the derived classes it manages are known to the compiler at the point of template instantiation...

Allowing for the specification of a list of statically known derived class types as part of a poly_collection instantiation opens up possibilities for internal performance optimizations that do not impact the usage interface of this template class. The actual improvements achieved depend very much on the compiler being used, but in general are greater when passing polymorphic functors (such as generic lambdas) to for_each and qualifying virtual functions as final where possible.

Introducing emplacer -- Tim

By Blog Staff | May 9, 2014 06:44 AM | Tags: intermediate

Another nice way to have a polymorphic collection without sacrificing that performance-precious contiguous memory layout:

Introducing emplacer: allocate subtypes of an abstract base class directly in a container

by Tim

From the article:

So I complained to my friend Jeremy that C++ should be able to do this. This isn't Java, I shouldn't have to do a separate allocation for each object...

As alluded to earlier, you can also use it in containers. Here's an example:

std::vector<ShapeAny> shapes;

shapes.emplace(shapes.end())->emplace<Rect>(3, 4);
shapes.emplace(shapes.end())->emplace<Square>(3);

//emplace returns reference to *this, so you can use it like this too
shapes.push_back(ShapeAny().emplace<Rect>(5, 6));
shapes.push_back(ShapeAny().emplace<Circle>(1));

for (auto shape: shapes) {
  std::cout << shape->area() << std::endl;
}

Fast Polymorphic Collections -- Joaquín M López Muñoz

By Blog Staff | May 5, 2014 04:44 AM | Tags: performance intermediate efficiency

munuz-poly.PNGOn the theme of "contiguous enables fast":

Fast Polymorphic Collections

by Joaquín M López Muñoz

From the article:

poly_collection behaves excellently and is virtually not affected by the size of the container. For n < 105, the differences in performance between poly_collection and a std::vector of std::unique_ptrs are due to worse virtual call branch prediction in the latter case; when n > 105, massive cache misses are added to the first degrading factor.

A C error handling style that plays nice with C++ exceptions

By Stefanus Du Toit | May 4, 2014 07:52 AM | Tags: intermediate

If you've ever wondered why someone might throw an exception from a destructor, this article provides a legitimate example:

A C Error Handling Style that Plays Nice with C++ Exceptions

by Stefanus Du Toit

From the article:

By choosing a particular convention for a C API's error handling, we were able to very conveniently translate errors from the C API to C++ exceptions. ... Every experienced C++ programmer I know has opinions on how errors should be handled. I've found this style to be quite useful when layering C++ on top of C, and I think there's some beauty in the interplay between C and C++ here.

 

noexcept: what for? -- Andrzej Krzemieński

By Blog Staff | Apr 28, 2014 09:51 AM | Tags: intermediate

From the desk of Andrzej:

noexcept -- what for?

by Andrzej Krzemieński

From the article:

In this post I would like to share my observation on where using noexcept really adds value. It is less often than what one might expect, and it does not have that much to do with throwing or not throwing exceptions. The conclusion surprises me a bit, and I hesitate to present it because it is counter to the advice I hear from people I consider authorities on the subject...