community

CppCon 2014 cppreference.com: documenting C++ one edit at a time--Nate Kohl

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

cppreference.com: documenting C++ one edit at a time

by Nate Kohl

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

How do you convert hundreds of pages of C++ standardese into a resource that is accessible to software engineers around the world? This talk will describe the process of building a community-run website that documents all of the nooks and dark corners of the C++ programming language. I'll look back at the history of how C++ was defined, cover the current state of documentation, examine the pros and cons of running a fairly high-profile publicly-editable wiki, and try to guess at what the future holds.

C++ User Group Meetings in July

The monthly overview on upcoming C++ User Group Meetings, this time its 18 User Groups who are meeting during summer!

C++ User Group Meetings in July

by Jens Weller

The list of meetings:

7.7 C++ UG Chicago - Memory Management in C++14 and Beyond
8.7 C++ UG San Francisco/ Bay area - HPX, C++ parallel programming framework
8.7 C++ UG Bristol - The Anatomy of Exceptional Engineers
9.7 C++ UG New York - July C++ Meetup
9.7 C++ UG Amsterdam - Hot C++, Part 2
9.7 C++ UG Dresden - Lazy generating non-integral values in range-based for loops
15.7 C++ UG Utah - Embedded Scripting with ChaiScript
15.7 C++ UG Bristol - Save the date
15.7 C++ UG Washington, DC - Q & A / Info Sharing
15.7 C++ UG Düsseldorf - Traveling for C++, a trip report
21.7 C++ UG Berlin - Ingo Josopait - Introducing the Goopax compiler for GPUs and Barb
21.7 C++ UG Portland - PDXCPP July Meeting-- feat. Jon Kalb
22.7 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
23.7 C++ UG Rhein-Neckar - Presenting for Geeks
28.7 C++ UG Cologne - Monthly meeting
29.7 C++ UG Washington, DC - Q & A / Info Sharing
29.7 C++ UG Hamburg - Protocol Buffers
30.7 C++ UG Bremen - C++ Testframeworks

CppCon 2014 What the committee did next!--Alisdair Meredith

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

What the committee did next!

by Alisdair Meredith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Now that C++14 is done, what is the standard committee working on next?

After inking 8 years to produce the C++11 standard (arguably 13) there was a feeling we should be able to produce new work faster, more incrementally. With the renewed interest in C++, we have more participation on the committee, and have looked to harness that enthusiasm in new ways. In the last 3 years we have spun up at least a dozen new study groups, and have 8 or mode Technical Specifications in various stages of development that we hope to ship over the next 12-24 months. So what are all these new groups and specifications about? Come to this session and get a vision of where C++ is headed in the immediate and short-term future.

Standardizing Variant: Difficult Decisions -- Anthony Williams

Techincal discussion information while standardizing N4542.

Standardizing Variant: Difficult Decisions

by Anthony Williams

From the article:

One of the papers proposed for the next version of the C++ Standard is N4542: Variant: a type safe union (v4). As you might guess from the (v4) in the title, this paper has been discussed several times by the committee, and revised in the light of discussions.

Boost has had a variant type for a long time, so it only seems natural to standardize it. However, there are a couple of design decisions made for boost::variant which members of the committee were uncomfortable with, so the current paper has a couple of differences from boost::variant. The most notable of these is that boost::variant has a "never empty" guarantee, whereas N4542 proposes a variant that can be empty.

CppCon 2014 Founding C++ User Groups--Jon Kalb & Jens Weller

Have you registered for CppCon 2015 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2014 for you to enjoy. Here is today’s feature:

Founding C++ User Groups

by Jon Kalb & Jens Weller

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Jens and Jon will share their experiences starting and working with local user groups and C++ conferences. They share some history and pointers on what has worked for them.

If you'd like to start or be active in a local tech group this session will be a good place to start.

CppCast Episode 12: Modern C++ for the Windows Runtime with Kenny Kerr

Episode 12 of CppCast the only podcast by C++ developers for C++ developers. In this episode Rob and Jason are joined by Kenny Kerr to talk about Modern C++ for the Windows Runtime. Kenny also shares his thoughts on printf and tells us about his new Pluralsight course.

CppCast Episode 12: Modern C++ for the Windows Runtime with Kenny Kerr

by Rob Irving and Jason Turner

About the interviewee:

Kenny Kerr is a computer programmer and recognized expert in Windows operating system development and programming languages. Kenny has published numerous articles about the Windows operating system, network security, and C++ for MSDN Magazine as well as other publications. Microsoft has recognized Kenny’s expertise in network and operating system security with the Microsoft MVP Award for security. He has also held the Microsoft MVP Award since 2007 for his contributions to the C++ development community.

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

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.

 

CppCast Episode 11: Boost 2.0 with Robert Ramey

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

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.

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

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.