CppCast Episode 182: Trivially Relocatable with Arthur O'Dwyer

Episode 182 of CppCast the first podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Arthur O'Dwyer to discuss board games, his 3 ISO C++ papers and much more.

CppCast Episode 182: Trivially Relocatable with Arthur O'Dwyer

by Rob Irving and Jason Turner

About the interviewee:

Arthur O'Dwyer started his career writing pre-C++11 compilers for Green Hills Software; he currently writes C++14 for Akamai Technologies. Arthur is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He is occasionally active on the C++ Standards Committee and has a blog mostly about C++.

First videos from Meeting C++ 2018 are online!

Right now its the lightning talks which are being uploaded, followed by the first keynote tomorrow!

Meeting C++ 2018 Videos

by Jens Weller

The talks will follow in the coming weeks. Over the weekend the keynotes and lightning talks should be online.

Quick Q: How to use auto keyword to assign a variable of type uint32_t or uint64_t in C++

Quick A: Write the type!

Recently on SO:

How to use auto keyword to assign a variable of type uint32_t or uint64_t in C++

I'm assuming you're working with the AAA style suggested by Herb Sutter.

In that case, a nice solution is to simply write:

auto variable_name = uint64_t{ 5000000000 };

This is clear, consistent, and explicitly typed with no nasty C-preprocessor necessary.

Swapping the Contents of n Variables -- Paul Keir

Swapping arguments using a fold expression.

Swapping the Contents of n Variables

by Paul Keir

From the article:

C++11's std::swap is a binary function template which exchanges the contents of its two reference arguments. In C++20 std::swap will likely also permit execution at compile-time. In this post we consider a version which can swap the contents of an arbitrary number of arguments using a C++17 fold-expression...

 

Developer Ecosystem 2019 survey by JetBrains

In JetBrains we feel it is important to keep monitoring the changing patterns and trends going on in the Software Development industry. That's why we run this survey yearly, trying to better understand the evolving world of development.

Developer Ecosystem 2019 Survey by JetBrains

by Anastasia Kazakova

About the survey:

In 2017, when we first started, the numbers of C/C++ developers in the survey were quite low:

  • total number of C developers in the survey is 1174, number of developers who use C as a primary dev language is 166
  • total number of C++ developers in the survey is 1713, number of developers who use C++ as a primary dev language is 348

A year after we got more impressive numbers:

  • total number of C developers in the survey is 3371, number of developers who use C as a primary dev language is 1254
  • total number of C++ developers in the survey is 4763, number of developers who use C++ as a primary dev language is 2036

We've learned a lot about language standard usage, compilers, build systems, unit testing frameworks, and other important aspects of C/C++ development from these surveys. Help us make it again this year!

Functional Programming Is Not a Silver Bullet--Jonathan Boccara

Nothing is perfect.

Functional Programming Is Not a Silver Bullet

by Jonathan Boccara

From the article:

The past few years have seen a boost in popularity of the functional programming paradigm. Languages that were used mostly in academic circles for decades are now in broader use amongst programmers. And every couple of months, another functional language hits the news and gets its trail of followers.

Why is that? Functional programming allow for safer and more robust code, in part due to one of its core principles: values are not mutable. A consequence of this is that there is no side effects. We can apply this principle in any language, including in C++, by coding with the least side effects possible.

While it certainly helps putting together a better design of code, it’s important to realize that it’s not the panacea, that this principle doesn’t solve in itself all design issues. Nothing is the panacea anyway, but in this time of gold rush towards functional programming, we could be tricked into thinking it will automatically lead to good design.

Functional programming is known to reduce coupling in code. We’ll briefly go over what coupling is, what sort of coupling functional programming prevents, and how some other dangerous forms of coupling can still sneak in even with functional programming. You want to pay attention to those to preserve the design of your code...