Hello everyone!
Tonight (Dec 6 2022) we hosted Amir Kirsh from Incredibuild.
Amir went over the various use cases of using std::move, also highlighting std::forward usage, various pitfalls and he provided us with good set of guidelines on when to use and not to use std::move.
Highly recommended!
Here is the recording (can be found in Youtube channel sdcppmu)
Our event link on meetup.com can found here: San Diego C++ Meetup
Today, Monday, November 14, we had our #44 San Diego C++ Meetup.
Unfortunately, there seem to have some issues in the posted link on meetup and many could not attend. Giant apology on this one. Not sure what happened and how but would pay extra attention next time (Dec 2022 here I come …).
Tonight, we discussed few interesting C++ Quiz questions, talked about RxCpp book from packt –
And also talked about Boost.Asio from the excellent Boost book:
here is the recording:
Enjoy!
Kobi
Hello everyone,
Yet another great evening meeting others and discussing C++.
Agenda can be found in the even link here: sdcppmu-event
Recording, in the Youtube channel at sdcppmu:
Great discussion points on const vs non const function – how to avoid duplication of code.
How “deducing this” makes the syntax shorter.
Martin shared the following: volatile: The Multithreaded Programmer’s Best Friend
We also discussed the blog post update: use-case-of-utilizing-stdset-instead-of-stdmap and heterogeneous lookup. See more here:
and cppstories-heterogeneous-lookup-cpp14 , https://www.cppstories.com/2021/heterogeneous-access-cpp20/
Thank you!
Kobi
Yet another fun night in San Diego C++ Meetup (sdcppmu).
Recording can be found in our sdcppmu Youtube channel.
Here is the agenda link:
https://www.meetup.com/san-diego-cpp/events/288596469/
We had quiz, C++ book which is https://www.amazon.com/Template-Metaprogramming-everything-templates-metaprogramming/dp/1803243457
We also discussed life time extension in the context of C++11 range for loop.
One thing that we discovered during the meeting is MSVC non-conformance with binding RValue to a non const reference. See the twitter discussion here: https://twitter.com/kobi_ca/status/1573155334696628224?s=20&t=2LZMv2JdfxLcbE7piQ76tA
Enjoy the recording!
Kobi
UPDATE:
Thank you Peter Sommerlad for pointing out that the non-violation of ODR was and remains the primary purpose of
inline, not the optimization hint. I’m updating the post to reflect this.
Today I want to talk about the C++ keyword inline; what it used to mean prior to C++17 and what it means today. Let’s start with the historical first.
A function declared inline could be defined in a header file (its body present in the .h file), then included in multiple compilation units (.cpp files) and the linker would not complain about seeing multiple definitions of the same symbol. This was a way of stating that ODR was not being violated by the programmer. Without inline one had to provide the signature of a function in a header file, and its implementation in a source file. Alternatively inline function could be defined multiple times across multiple source files and everything would be hunky-dory as long as the definitions were identical, otherwise… undefined behavior.
inline used to also apply to standalone and member functions (class methods declared and defined inside the body of a
class or
struct were implicitly
inline) as a hint to the compiler to inline the function call: instead of outputting assembly code that would push parameters onto the stack and jump to the function’s address the compiler would instead emit the compiled function in place, skipping the jump and stack pushes/pops. This allowed for faster running code, sometimes at the cost of the size of the executable (if the same function’s assembly was emitted in many places across the executable).
Good example of potential performance gain would be inside a tight loop making calls/jumps to a function; the overhead in each iteration of the loop could result in significant impact on performance;
inline helped to mitigate that.
I mentioned earlier that inline was a hint, meaning that declaring a function as inline did not guarantee that it would be assembled in place; compilers had the ultimate say in the matter and were free to ignore inline each and every time. The workaround to this powerlessness over the mighty compiler was to instead #define the function as a macro. Preprocessor macros are evaluated and replaced with actual code prior to compilation, effectively always resulting in a function (macro) call replaced with its body in the source code.
|
1 2 3 4 5 6 |
inline int Add(int x, int y) { return x + y; } #define MUL(x, y) ((x) * (y)) |
The compiler could refuse to inline Add but it had no choice but to compile MUL in-place. Note the parenthesis around x and y in the macro; that’s there in case x and y are complex expressions that need to be fully evaluated before the final multiplication takes place. Without the parenthesis this macro call would be very problematic: MUL(1 + 2, 3 + 4); would expand to 1 + 2 * 3 + 4 which is clearly not what’s expected (due to operator precedence) at the time of the macro call.
Enter the grand inline unification!
Since C++17 the multiple definitions meaning applies equally to both functions and variables (while also being an optimization hint for functions).
If we wanted to have a global variable shared across multiple compilation units (.cpp files) we had to first declare an extern variable in a header file:
extern int x; // Inside .h file
Then define it (and provide storage for it) in a source file:
int x = 98; // Inside .cpp file
A header only workaround prior to C++17 was to use Meyer’s Singleton approach:
|
1 2 3 4 5 6 7 |
// Inside .h file only inline int& Instance() { static int x = 98; return x; } |
Starting with C++17 the same can be accomplish by simply declaring and defining the variable as inline in a header file:
inline int x = 17; // Inside .h file only
Now the header file can be included by many source files and the linker will intelligently, despite seeing multiple symbols, pick only one and disregard all others, guaranteeing the same variable at the same memory location is accessed or modified regardless of which compilation unit it happens in.
The same holds true for static member variables of a class or struct. In the past we had to do the following in a header file:
|
1 2 3 4 5 6 |
// Inside .h file struct S { static int x; }; |
And inside a source file:
int S::x = 98; // Inside .cpp file
C++17 requires only a header file to achieve the same result:
|
1 2 3 4 5 6 |
// Inside .h file only struct S { inline static int x = 17; }; |
Worth noting is that template and constexpr functions as well as constexpr variables are also implicitly inline. You can read more about all the gory details here and here.
I have this habit of buying books. Like tons of books. Ask my wife, she’ll tell you. I think at that point she gave up.
I like to read what others think about the industry, about a specific domain. How do people see programming (especially C++) and technology from their own perspective.
So sometimes, I get to buy some not-so-familiar-books. This time it was “Modern C++ Coding Standards” by Marcus Tomlinson.
In the book, Marcus is saying that he wanted to share a handful of simple guidelines and best practices that he has been using in producing solid C++ projects over the past few years. And I do think he succeeded in this goal.
I’d start off by stating that the book is short. Easy to read in just couple hours. Not a lot of code snippets, so it’s pretty light. Very easy to quickly digest.
The book starts with one of the best features of C++ – RAII – C++ resource management mechanism. It explains the benefits of this important feature, not only in the context of Memory but also in the context of general resource management and cleanups at the end of a scope.
There are total of 3 parts in the book. Each has few chapters.
Part one (Modern C++ Coding Standards), Chapter One talks about how headers should be written. Couple things that I’m kinda disagreeing on, or at least on the fence:
Other than these two, there are plenty of well written points that I’m 100% on board with. I’m not going to list it here since the list is kinda big for a short blog post but I do suggest you go over it and see if you are aligned with each. I believe most of us would be.
Chapter two of the same Part One talks about organizing your cpp files. Again, plenty of good rules that I found very easy to read and digest. I believe most of the readers would find this part useful as well. As in the previous chapter, I have disagreement with one item – organizing the include headers. I’m in the camp of organizing the headers from the more general ones to the more specific ones. For example – your OS headers, then standard lib, 3rd party, your project. I find this order to be less disruptive and pretty solid when it comes to possible errors coming from your own project or 3rdparty headers.
Chapter three talks about Application Sources. Basically where your main() function lives. Lots of good suggestions like using std::future when appropriate, how to use std::async and similar. Just a reminder – the book is not going into details of the “why” but rather stays on the “trust me, you should do what I say/preach”. The bullets on auto, smart pointers and typedef vs “using” vs #define is spot-on.
Part Two is named “Language Agnostic Best Practices”. Chapter Four includes a set of very well written recommendations on how to construct your build system, automating the boring stuff (also great book … on Python), warning levels, static analyzer, version control, formatting etc… I felt like this is a really good list that should be applied to any Software project, regardless the programming language.
Part Three talks about “Templates & Compile-Time Programming”. Chapter five provides a short intro into Templates. I was pleasantly surprised to see C++20 code in this chapter. I.e. seeing concepts described as an advantage when used with Templates. Same warm feeling seeing C++20 related Lambda syntax. Overall, a very good Template introduction squeezed into just a few pages. While there are almost no real recommendations here in terms of coding standards but rather a C++ Class/Function Templates overview, I did find one good recommendation – Avoid specialization function templates and prefer overloading. Good one!
Chapter Six describes Template parameters. Again, not many recommendations but rather a good, concise overview on Template parameters. It covers Type Template parameters and also Non type as well as Template Template Parameters.
Chapter Seven, named “Beyond Templates” explains compile-time programming. It’s a very short chapter that describes the main idea behind constexpr and consteval (again, nice to see C++20 syntax).
The last part of the book provides an excellent summary of the points touched upon in the book. Basically, one can skip the entire first 86 pages and jump directly into the summary and just read, absorb and adapt (modulo the few disagreements that I and maybe others might have).
Overall, an affordably priced book, short (less than 100 pages long) but has good set of recommendations that should work for most, if not all, of us, Modern C++ programmers.
And Marcus – if you are reading this – great job! 🙂
Super fun evening in San Diego, America’s finest city with the finest programming language (C++, if you had any doubts).
We learned tons of stuff and we are ready to Rock’n Roll using C++ at work and … home!
What did we discuss tonight?
1. Goals we would like to achieve in San Diego C++ Meetup. We would like to make sure members learn new fun constructs in C++.
2. C++ Quiz – few fun questions.
3. Template Function specialization (Beginners-Intermediate).
4. Correct way to printf() – Using std::string_view with printf (Beginners).
Yet another fun evening in San Diego, America’s finest city with the finest programming language.
We discussed:
From the Command Line, to Make, to CMake, to Conan By Nick Ristuccia from JFrog!
This session examines the layers of tooling used to produce C/C++ applications and make developers’ lives easier. Surveys say a major pain point facing C/C++ developers is long build times. One way to save time is to only re-build an artifact when a change occurs. Although the command line offers the precision of specifying what to build, doing this and tracking changes manually can quickly become a daunting and error-prone proposition. Make as a build system allows developers to specify and execute command-line statements depending on what file changes are detected. However, these statements may be particular to one compiler or operating system. CMake provides the missing flexibility for a makefile file. One CMake file can generate what’s needed for a variety of build systems, compilers, and operating systems. Another major pain point facing C/C++ developers is managing all the libraries needed by an application. Libraries provide the functionality programs need. But it gets tricky when libraries depend on other libraries that depend on other libraries in a spaghetti-like formation. The goal of Conan as a package manager is to alleviate this burden. ConanCenter, for example, features over 1000 recipes. The promise of a recipe is to untangle the spaghetti and list the dependencies for a given library.
Nick started in the video games industry, developing titles for console and mobile. Disappointed by the oppressive corporate feel of traditional technical training, Nick’s passion is to create more engaging and powerful learning experiences through game-based learning and other playful techniques. As a Curriculum Developer at Oracle, he focused on Java programming and certification. As a Developer Advocate at JFrog, his focus is on C++, Conan, and other JFrog technologies.
Recording:
Meetup session May 24 20212
Six ways for implementing max: a walk through API design, dangling references and C++20 constraints
Abstract:
API design in C++ is harder than in other languages, as the lifetime of the arguments and return value shall be considered carefully. While it gives programmers the full power in expressing their intent, it raises all sorts of concerns that should be considered. In this talk we would analyze a very simple function: max, we would see that selecting the proper API is not as simple as it may seem and discuss several alternatives. The discussion would take us through lvalue, rvalue and forwarding references, the rules of moving from a local, variadic templates design, the differences between returning auto and decltype(auto) and C++20 constraints.
Bio:
Amir Kirsh is a C++ lecturer at the Academic College of Tel-Aviv-Yaffo and Dev Advocate at Incredibuild. He is also the Co-organizer of Core C++ conference and a member of the Israeli ISO C++ NB.
Meeting event: https://www.meetup.com/San-Diego-CPP/events/285561768/
Recording:
Brief bookclub talk I gave at work introducing the visitor design pattern and multiple-dispatch in C++.
Chapter 18 from Hands-On Design Patterns with C++ by Fedor G. Pikus.
Source code:
visitor.cpp
Brief bookclub talk I gave at work introducing the adapter design pattern in C++.
Chapter 17 from Hands-On Design Patterns with C++ by Fedor G. Pikus.
Source code:
adapter.cpp
Brief bookclub talk I gave at work introducing the decorator design pattern in C++.
Chapter 17 from Hands-On Design Patterns with C++ by Fedor G. Pikus.
Source code:
decorator.cpp
From the 37th San Diego C++ Meetup:
Recently I was hosted twice in cppcast podcast with Rob and Jason. I mentioned how using C++17 makes it easy to develop Modern C++ code. I will go over various features that are proven to work well. We built a software with no memory issues, no UBs etc… – the name of the talk is: “My best C++11,14 and 17 features that helped me write a better code”. (Beginners to Intermediate)
Yacob (Kobi) Cohen-Arazi
Brief bookclub talk I gave at work introducing policy-based design in C++.
Chapter 16 from Hands-On Design Patterns with C++ by Fedor G. Pikus.
Brief bookclub talk I gave at work introducing the singleton design pattern in C++.
Chapter 15 from Hands-On Design Patterns with C++ by Fedor G. Pikus.
Source code:
singleton.hpp | singleton.cpp
San Diego C++ Meetup has a Discord server open to the public.
If you’re passionate about C++ and want to meet likeminded people join us: https://discord.gg/rqQTzSxy
As always good times at the SDCPPM (also on Twitter)! Learned something new last night and met great people! Thanks again for organizing this Kobi!
For those new to this Meetup: we meet once a month for few hours to discuss C++ features, techniques, questions asked no the net, and more. Sometimes we have guest speakers give presentations on various topics (Conan Package Manager, C++20 Concepts to name a few). Join us! Join to listen in, chat and exchange your experience coding in C++, or be a speaker and teach us something cool! All backgrounds and experience levels welcome!
