Home » Blog » Categories »

CppCon 2016: A modern database interface for C++--Erik Smith

By Adrien Hamelin | Aug 14, 2017 02:44 PM | Tags: community

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

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

A modern database interface for C++

by Erik Smith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++ has historically had many options for database connectivity but has lacked a standard interface that other languages, such as Java, have had for a long time. This talk will present a standards grade interface along with experience with a reference implementation that includes support for at least 6 databases. A key aspect of the design is to show how modern C++ features can be used to achieve a high degree of both efficiency and ease-of-use. Specific features to be covered will include type conversion, connection pooling, I/O binding for scalars and arrays, row sets, direct/polymorphic interfaces, policy based design, the driver interface, and details on the implementation. Forward looking standards proposals, such as ranges and variants, will also be included in the discussion.

CppCon 2016: Turning Particle-Astro-Physicist-Hackers into Software Engineers--Alex Olivas

By Adrien Hamelin | Aug 11, 2017 03:18 PM | Tags: efficiency community

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

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

Turning Particle-Astro-Physicist-Hackers into Software Engineers

by Alex Olivas

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Want to increase software literacy in your organization? In this talk I'll present programs I've developed over the last year to teach C++ software engineering principles to graduate students and postdocs on the IceCube South Pole Neutrino Observatory. I believe similar programs could be beneficial to all types of organizations, from scientific collaborations to professional software shops.

IceCube is a kilometer-scale high energy neutrino observatory located deep in the Antarctic ice at the geographic South Pole. IceCube studies physics in energy regimes ranging from the most energetic processes in the visible universe (several orders of magnitude greater than the collision energies at the Large Hadron Collider), to dark matter detection at the 100 GeV scale. It is a relatively large collaboration, consisting of roughly 300 physicists and engineers from 48 institutions from a dozen different countries. IceCube has been collecting data for over 11 years (going into our 6th season with the fully completed detector) and is expected to run for at least another decade.

Many large scientific projects, which often run for decades, rely on code developed by hackers, who's focus and passion is rarely software engineering. Their primary passion, understandably, is the field for which they found themselves writing code. To make matters worse, the amount of work and focus required to secure a career in their chosen field often leaves little time and energy to devote to honing the skills needed to develop production quality code. Many students and postdocs often have, at best, a cursory understanding of the programming language(s) that comprise the experiment's codebase.

C++ has become the primary programming language for High Energy Physics (HEP) and will likely continue to be for decades to come. Consider, for example, that ROOT, GEANT, and Pythia to name a few critical HEP libraries are written in C++. Over the last year on IceCube, I've developed several comprehensive internal training programs in an attempt to bridge the gap between the scientist-hacker and the professional C++ software engineer. In this session I'd like to present the challenges I've encountered over the last year and my plans for extending these programs to the High Energy Physics community through the HEP Software Foundation.

CppCast Episode 113: Synchronization Primitives with Samy Bahra

By robwirving | Aug 11, 2017 08:17 AM | Tags: None

Episode 113 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Samy Bahra from Backtrace to talk about lesser known synchronization primitives and his work on the Concurrency Kit.

CppCast Episode 113: Synchronization Primitives with Samy Bahra

by Rob Irving and Jason Turner

About the interviewee:

Samy Al Bahra is the cofounder of Backtrace, where he is helping build a modern debugging platform for today’s complex applications. Prior to Backtrace, Samy was a principal engineer at AppNexus, where he played a lead role in the architecture and development of many mission-critical components of the ecosystem. His work at AppNexus was instrumental in scaling the system to 18 billion impressions with orders of magnitude in efficiency improvements. Prior to AppNexus, Samy was behind major performance improvements to the core technology at Message Systems. At the George Washington University High Performance Computing Laboratory, Samy worked on the UPC programming language, heterogeneous computing, and multicore synchronization. Samy is also the founder of the Concurrency Kit project, which several leading technology companies rely on for scalability and performance. Samy serves on the ACM Queue Editorial Board.

Quick Q: Why are static addresses constexpr?

By Adrien Hamelin | Aug 10, 2017 01:28 PM | Tags: intermediate c++11

Quick A: Because it is defined at compile time in a special section.

Recently on SO:

A little confused about constexpr functions

If 'x' is declared static, there are no errors. Why?

This is because there is always exactly one x in the program. It has an address (somewhere in the .data segment under normal conditions).

Confusingly, both static and extern keywords specify the storage duration as static (they differ in linkage)

How is it possible to get a variable address during the compilation process? Aren't they allocated at run-time?
Variables with automatic, dynamic or thread storage durations are allocated at runtime. Static duration variables are allocated by the compiler. (The linker and OS can change the location, but they know how to fix all the references when they do)