C++ Best Practices: A Forkable Standards Document - Jason Turner

By Jason Turner | May 19, 2015 12:11 AM | Tags: community

A forkable coding standards and best practices document for C++.

C++ Best Practices

by Jason Turner

From the book

It (C++ Best Practices) compliments books such as Effective C++ (Meyers) and C++ Coding Standards (Alexandrescu, Sutter). We fill in some of the lower level details that they don't discuss and provide specific stylistic recommendations while also discussing how to ensure overall code quality.

...

This document is based on my personal experiences. You are not supposed to agree with it 100%. It exists as a book on github so that you can fork it for your own uses or submit back proposed changes for everyone to share.

 

Using Monads in C++ to Solve Constraints: 3. The Tale of Two Monads—Bartosz Milewski

By Marco Arena | May 18, 2015 10:33 AM | Tags: intermediate

Bartosz Milewski continues to explain how to use Monads in C++.

Using Monads in C++ to Solve Constraints: 3. The Tale of Two Monads

by Bartosz Milewski

From the article:

The functional solution to our problem involves the combination of the list monad and the state monad. Mashing two monads together is not trivial — in Haskell this is done using monad transformers — but here I’ll show you how to do it manually...

CppCon 2014 Sanitize your C++ code--Kostya Serebryany

By Adrien Hamelin | May 18, 2015 09:55 AM | Tags: advanced

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:

Sanitize your C++ code

by Kostya Serebryany

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

"Sanitizers" is a family of dynamic testing tools built into C++ compilers (Clang and GCC):
AddressSanitizer finds memory errors, such as use-after-free, buffer overflows, and leaks;
ThreadSanitizer finds data races, deadlocks, and other threading bugs;
MemorySanitizer finds uses of uninitialized memory;
UndefinedBehaviorSanitizer finds other kinds of undefined behavior, such as use of incorrect dynamic type, shift by illegal amount and many others.
You will learn how these tools work, how to use them on small programs and how we deploy them in large projects.

CppCon 2014 Large-Scale Refactoring @ Google--Hyrum Wright

By Adrien Hamelin | May 15, 2015 08:00 AM | Tags: c++11 advanced

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:

Large-Scale Refactoring @ Google

by Hyrum Wright

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Many organizations have significant investments in a large existing C++ codebase, and Google is no exception. Our code is intended to survive for decades, but continue to track new language standards as they emerge. To do so, we have developed tools and techniques which provide the ability to automatically refactor code to use new APIs as they become available.

In this talk, I'll discuss some of the reasons for doing migrations that impact hundreds of thousands of files, and how we do them at Google, using tools such as ClangMR. I'll give examples, such as our recent migration to the standardized std::unique_ptr and std::shared_ptr types and lessons we've learned from these experiences. Finally, I'll point out pitfalls others may face in doing similar work, and suggest ways that they can be avoided.

Handling short codes (part I)--Andrzej Krzemieński

By Marco Arena | May 15, 2015 06:02 AM | Tags: performance intermediate

First part of a discussion about designing a type storing character strings of length N (known at compile-time and sufficiently small).

Handling short codes - part I

by Andrzej Krzemieński

From the article:

In my work, we often deal with codes [...] The initial choice was to represent them in programs by type std::string, a general-purpose type for storing sequences of characters. But, as with any general-purpose tools, they fail to take into account the particular usage cases which often offer room for improvements [...] The following is an attempt at the design of a type that would take advantage of the information that we are only storing character strings of length N, where N is sufficiently small (say, no longer than 8)...

Using Monads in C++ to Solve Constraints: 2. The State Monad—Bartosz Milewski

By Marco Arena | May 14, 2015 11:49 PM | Tags: intermediate

Bartosz Milewski continues to explain how to use Monads in C++.

Using Monads in C++ to Solve Constraints: 2. The State Monad

by Bartosz Milewski

From the article:

We all like making plans, but they are often contingent on the state of our finances. Such plans can be described by functions. In general, a financial plan is a function that takes cash and returns the result paired with the new value of cash. It can be described generically using a template...

CppCast Episode 11: Boost 2.0 with Robert Ramey

By robwirving | May 14, 2015 01:07 AM | Tags: podcast community

Episode 11 of CppCast the only podcast by C++ developers for C++ developers. In this episode Rob and Jason are joined by Robert Ramey to talk about the future of the Boost C++ Libraries.

CppCast Episode 11: Boost 2.0 with Robert Ramey

by Rob Irving and Jason Turner

About the interviewee:

Robert Ramey is a freelance Software Developer living in Santa Barbara, California. His long and varied career spans various aspects of software development including business data processing, product, embedded systems, custom software, and C++ library development. Lately, he has been mostly interested in C++ library design and implementation related to Boost. He is the author and maintainer of the Boost Serialization library and Boost library incubator

CppCon 2014 Defensive Programming Done Right, Part II--John Lakos

By Adrien Hamelin | May 13, 2015 08:00 AM | Tags: community advanced

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:

Defensive Programming Done Right, Part II

by John Lakos

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.

Using Monads in C++ to Solve Constraints: 1. The List Monad -- Bartosz Milewski

By Felix Petriconi | May 11, 2015 01:18 PM | Tags: intermediate

Bartosz Milewski starts to explain Monads in his recent article.

Using Monads in C++ to Solve Constraints: 1. The List Monad

by Bartosz Milewski

From the article:

I am sometimes asked by C++ programmers to give an example of a problem that can’t be solved without monads. This is the wrong kind of question — it’s like asking if there is a problem that can’t be solved without for loops. Obviously, if your language supports a goto, you can live without for loops. What monads (and for loops) can do for you is to help you structure your code. The use of loops and if statements lets you convert spaghetti code into structured code. Similarly, the use of monads lets you convert imperative code into declarative code. These are the kind of transformations that make code easier to write, understand, maintain, and generalize.

So here’s a problem that you may get as an interview question. It’s a small problem, so the advantages of various approaches might not be immediately obvious, especially if you’ve been trained all your life in imperative programming, and you are seeing monads for the first time.

CppCon 2014 Defensive Programming Done Right, Part I--John Lakos

By Adrien Hamelin | May 11, 2015 08:00 AM | Tags: community advanced

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:

Defensive Programming Done Right, Part I

by John Lakos

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.