June 16-21, Sofia, Bulgaria
September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 16-21, Kona, HI, USA
By Adrien Hamelin | Nov 28, 2018 11:58 AM | Tags: intermediate experimental
Do you like span?
RangeOf: A better span
by Corentin Jabot
From the article:
I don’t like span.
Since that article was posted, the committee improved span quite a bit by removing operator== and making it’s size() consistent with that of vector after a lot of discussions. And I mean a lot...
By Adrien Hamelin | Nov 28, 2018 11:55 AM | Tags: community
Were you there?
Meeting C++ and Meeting Embedded trip report
by Conan C/C++ Package Manager
From the article:
On Wednesday, before Meeting C++, we attended and presented a talk at Meeting Embedded, a new conference about many topics related to embedded systems. C++ and C had a relevant role in this conference, obviously (accordingly to Dan Saks statistics around 60% in embedded code is C, then around 20% is C++, followed by assembly), but where other topics presented, like Rust, protocols for embedded (MQTT), academic and professional education, real-time systems.
We did our own talk Continuous Integration of C/C++ for embedded and IoT with Jenkins, Docker and Conan, which went quite well, especially considering that we were running a real demo, live updating the embedded code in a Raspberry PI, that was built with Docker in Jenkins, using cross-compiled (from Windows) packages, and uploaded to Artifactory, all of that done in the live demo...
By Adrien Hamelin | Nov 27, 2018 02:10 PM | Tags: basics
Quick A: The returned variable can be modified.
Recently on SO:
What does it mean to return a reference?
It means you return by reference, which is, at least in this case, probably not desired. It basically means the returned value is an alias to whatever you returned from the function. Unless it's a persistent object it's illegal.
For example:
int& foo () { static int x = 0; return x; } //... int main() { foo() = 2; cout << foo(); }would be legal and print out 2, because foo() = 2 modifies the actual value returned by foo.
However:
int& doit () { int x = 0; return x; }would be illegal (well, accessing the returned value would), because x is destroyed when the method exits, so you'd be left with a dangling reference.
Returning by reference isn't common for free functions, but it is for methods returning members. For example, in the std, the operator [] for common containers return by reference. For example, accessing a vector's elements with [i] returns an actual reference to that element, so v[i] = x actually changes that element.
Also, I hope that "is essentially equal to this code" means that they're semantically sort of (but not really) similar. Nothing more.
By Adrien Hamelin | Nov 27, 2018 01:58 PM | Tags: c++11 advanced
Obscure feature? Not for long.
Inline Namespaces 101
by Jonathan Müller
From the article:
Almost three years ago — wow, how time flies — I blogged about namespace aliases and called them one of C++ most underrated features (which probably was a bit of a click bait).
Let’s talk about some other namespace feature, that is, well, not quite underrated, but relatively obscure: inline namespace. They are namespaces that don’t really introduce a scope, except when they do.
So what can you do with them?
By Adrien Hamelin | Nov 27, 2018 01:53 PM | Tags: community
Do you have a way?
How to teach C++
by Marius Elvert
From the article:
In the closing Keynote of this year’s Meeting C++, Nicolai Josuttis remarked how hard it can be to teach C++ with its ever expanding complexity. His example was teaching rookies about initialization in C++, i.e. whether to use assignment =, parens () or curly braces {}. He also asked for more application-level programmers to participate.
Well, I am an application programmer, and I also have experience with teaching C++. Last year I held a C++ introductory course for experienced C programmers who mostly had never used C++ before. From my experience, I can completely agree with what Nico had to say about teaching C++. The language and its subtlety can be truly overwhelming.
Most of the complexity in C++ boils down to tuning your code for optimal performance. We cannot just leave that out, can we? After all, the sole reason to use C++ is performance, right?
By Anastasia Kazakova | Nov 27, 2018 12:20 PM | Tags: None
CLion has just got a huge update!!
CLion 2018.3 released: remote development, CPU profilers, C++17, clangd-based navigation, and VCS and editor improvements
by Anastasia Kazakova
From the article:
This year we’ve focused on two areas to enhance CLion. The first is better C++ language support and general IDE performance improvements. As a result, we’ve added a clangd-based experimental complementary language engine, and a massive amount of work was done which, although invisible at first glance, has helped eliminate dozens of UI freezes in the editor.
The second area is the endless world of remote configurations. Starting with Windows Subsystem for Linux (WSL), by the end of the year it has evolved into full remote development support.
Other update highlights include:
- CPU Profilers integration on Linux (Perf) and macOS (DTrace)
- Better C++17 support: fold expressions and deduction guides
- Clangd-based navigation and search actions
- New Build menu, Run Anything, and Search Everywhere
- VCS enhancements: Git Submodules and GitHub pull requests
By Adrien Hamelin | Nov 26, 2018 02:30 PM | Tags: intermediate community
Readability is important.
How to Design Function Parameters That Make Interfaces Easier to Use (1/3)
by Jonathan Boccara
From the article:
When you look at an function in an interface, 3 prominent things give you indications about how to use it: its name, its parameters and its return type. And when you look at a piece of code calling that function, it’s just its name and its function parameters.
We’ve already covered in details how to give good names to the components of your code. Now we’re going to examine how to design function parameters in a way that both your interfaces and the code that calls them are as expressive as can be.
Summed up in one sentence, you want to make the decision of what arguments to pass to your functions a no-brainer.
There are a lot of things to say about how to achieve this. So much so that you will find the contents broken down into 3 articles in order to make it easier to digest:
- Part 1: interface-level parameters, one-parameter functions, const parameters,
- Part 2: calling contexts, strong types, parameters order,
- Part 3: packing parameters, processes, levels of abstraction.
To support this series I’ve taken many examples from interfaces I’ve worked on, except that I’ve stripped out all domain aspects to make them both simpler and disclosable...
By Adrien Hamelin | Nov 26, 2018 02:16 PM | Tags: community
An interesting point of view.
Treating symptoms instead of the cause
by Andrzej Krzemieński
From the article:
Compiler warnings can sometimes help us find bugs before we even build our program, but it only works provided that we can make use of the warnings. Especially, when we are aware that warnings detect only symptoms of the bugs rather than bugs themselves...
By Adrien Hamelin | Nov 26, 2018 02:12 PM | Tags: performance
Safe and performant?
A zero cost abstraction?
by Josh Peterson
From the article:
Recently Joachim (CTO at Unity) has been talking about “performance by default”, the mantra that software should be as fast as possible from the outset. This is driving the pretty cool stuff many at Unity are doing around things like ECS, the C# job system, and Burst (find lots more about that here).
One question Joachim has asked internally of Unity developers is (I’m paraphrasing here): “What is the absolute lower bound of time this code could use?” This strikes me as a really useful way to think about performance. The question changes from “How fast is this?” to “How fast could this be?”. If the answers to those two questions are not the same, the next question is “Do we really need the additional overhead?”
Another way to think about this is to consider the zero-cost abstraction, a concept much discussed in the C++ and Rust communities. Programmers are always building abstractions, and those abstractions often lead to the difference between “how fast it is” and “how fast it could be”. We want to provide useful abstractions that don’t hurt performance...
By Andrey Karpov | Nov 21, 2018 02:00 AM | Tags: static code analysis pvs-studio c++ bugs
The PVS-Studio analyzer is gradually becoming more complicated but these changes can be hardly described in a Release-history. For example, this year we have consistently implemented symbolic computations in the analyzer. This is why it was agreed to write a note on algorithms and technologies, which PVS-Studio now uses to search for errors and potential vulnerabilities.
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities
by Andrey Karpov
From the article:
Here a mixture of technologies is working: data flow analysis, symbolic execution, and automatic method annotation (we will cover this technology in the next section). The analyzer sees that X variable is used in the Div function as a divisor. On this basis, a special annotation is built for the Div function. Further it is taken into account that in the function a range of values [0..4] is passed as the X argument. The analyzer comes to a conclusion that a division by 0 has to occur.