C++ Weekly Episode 31: IncludeOS—Jason Turner
Episode 31 of C++ Weekly.
IncludeOS
by Jason Turner
About the show:
Jason explores what IncludeOS is and how you might use it for OS experimentation.
build2 0.4.0 released
build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. There is also cppget.org, a public repository of open source C++ packages.
build2 0.4.0Release Notes
From the announcement:
This release includes a number of major new features in the build system (support for Windows/MSVC, C compilation, pkg-config integration, library versioning and export model, as well as the uninstall operation) and packag manager (support for repository authentication and system packages).
This version has been tested on Windows, Linux, Mac OS, and FreeBSD with GCC, Clang (both vanilla and Apple's), MinGW GCC, MSVC, and Intel icc.
Metashell 3.0.0 is available
Metashell provides a compile-time debugger for debugging template instantiations and macro usage.
Metashell 3.0.0 is available
From the website:
Some of the major new features in 3.0.0:
- Profiling template instantiations
- Debugging template instantiations in expressions involving SFINAE
- Displaying preprocessed expressions
Commands for exploring the available headers (similar to the which and ls commands).
The full list of changes can be found here.An online demo can be found at http://metashell.org/about/demo/
Installers can be downloaded from http://metashell.org/getting_metashell/installers#version-300
C++ in Competitive Programming: compromises--Marco Arena
In this installment I'll explain what I consider the essence of Competitive Programming:
C++ in Competitive Programming: compromises
by Marco Arena
From the article:
Crafting software is about balancing competing trade-offs. It’s impossible to optimize every factor of a system, as speed, usability, accuracy, etc at the same time. Moreover, solutions of today impact decisions and solutions of tomorrow. On the other hand, in Competitive Programming, the best solution is one that just makes each test-case pass...
The Case for Optional References--Tristan Brindle
And why not simply use a pointer?
The Case for Optional References
by Tristan Brindle
From the article:
I have a confession to make. Whenever I’ve come across code that looks like this:
struct example { example() = default; example(std::string& s) : str_{s} {} private: boost::optional<std::string&> str_{}; };there is a little voice inside my head that whispers “why didn’t you just use a pointer?”. Like so, for instance:
struct example { example() = default; example(std::string& s) : str_{&s} {} private: std::string* str_ = nullptr; };This is equivalent to the first example, except that it’s slightly less typing, it doesn’t have any dependencies, and feels in some sense “cleaner”. I personally have always preferred it.
Except, I was wrong. After attending Bjarne Stroustrup’s keynote and this excellent talk at Cppcon this morning, I’m persuaded that optional references are a good thing. In this post I hope to be able to convince you of the same...
Universal vs Forwarding References in C++--Petr Zemek
Do you know the difference?
Universal vs Forwarding References in C++
by Petr Zemek
From the article:
When talking about
T&&in C++, you may have heard about universal references and forwarding references. This may get you wonder. Why there are two names for an apparently same concept? Is there any difference between them? Which one should I use? Lets find out...
CppCast Episode 72: Boost::Process with Klemens Morgenstern
Episode 72 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Klemens Morgenstern to discuss his experimental changes in boost::dll and his proposed boost::process library.
CppCast Episode 72: Boost::Process with Klemens Morgenstern
by Rob Irving and Jason Turner
About the interviewee:
Born in 1988 in Dresden, I have a Bachelors in Electrical Engineering and Master's Degree in Microsystems & Microelectronics. Fell in Love with C++ while working with embedded systems. Klemens was working full time as a C++-Developer from 2013 until early 2016, and is now starting his own consulting company, trying to bring C++ to C-Programmers.
Boost Version 1.62.0
A new version is available!
Version 1.62.0
With quite a few changes.
Quick Q: std::ignore for ignoring unused variable
Quick A: While in theory possible, it is not the intended usage and other solutions exist.
Recently on SO:
std::ignore for ignoring unused variable
std::ignoremay work but it is intended to be used for tuples. So you need to include the tuple header and who knows what operations are done for the assignment. This also may break in another c++ version because it was never documented to be used that way.A better way for this is the C++17 attribute
[[maybe_unused]]void func([[maybe_unused]] int i) { }It places the declaration right at the variable declaration, so you don't have to declare it in an extra line/statement.
The same can be used for local (and local-static) variables
... [[maybe_unused]] static int a = something(); ...And also for many more:
Appears in the declaration of a class, a typedef, a variable, a nonstatic data member, a function, an enumeration, or an enumerator. If the compiler issues warnings on unused entities, that warning is suppressed for any entity declared maybe_unused.See http://en.cppreference.com/w/cpp/language/attributes
As for the people concerned that you can still use the variables after you declare them unused:
Yes, this is possible but (at least with clang) you will get warnings in case you use
maybe_unuseddeclared variables.
Quick Q: Initializing a std::string with function return value, is there a copy?
Quick A: No, at worse it will be a move.
Recently on SO:
Initializing a std::string with function return value, is there a copy?
In general, if the std::string is constructed in the call and then returned most modern compilers with apply the return value optimization (a special case of copy elision). Your case in particular is the Named RVO (thanks @NathanOliver for pointing this out), if you want to look up the precise rules. From C++17 on this optimization is guaranteed through the standard.
Whether or not the optimization is applied is hard to tell, however if it is not, then in C++11 and above it is very likely that the std::string object in the scope of the function will be moved from and that the return value will be moved to. You could theoretically call std::move on the return value, but thereby you would also prevent any RVO from happening. While move may be efficient, RVO typically yields faster code, because nothing is moved or copied at all, but the object is constructed in place, so I would advise against doing it, and in favor of relying on your compiler.