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.
C++ Delegate initialization in IncludeOS - the simpler way -- Andreas Åkesson
C++ delegates were a hot topic at CppCon this year. Andreas Åkesson shows a simpler way to use them in IncludeOS.
Delegate initialization - the simpler way
By Andreas Åkesson
From the article:
After the presentation it hit me, “Why can’t we deduce the class type from the object passed as argument? Let’s make a helper function!”
Announcing diversity tickets for Meeting C++ 2016
Shortly before CppCon started, I was able to offer diversity tickets for Meeting C++:
Announcing diversity tickets for Meeting C++ 2016
by Jens Weller
From the article:
This is something new for Meeting C++, I am finally able to offer diversity tickets for this years conference...
C++ Weekly Episode 30: C++17’s [[nodiscard]] Attribute—Jason Turner
Episode 30 of C++ Weekly.
C++17's [[nodiscard]] Attribute
by Jason Turner
About the show:
Wrapping up C++ Weekly's C++17 attribute coverage with possibly the most interesting yet: [[nodiscard]].
CppCon2016: All keynote/plenary sessions are now posted on YouTube
CppCon just concluded on Friday, and all five keynote/plenary sessions are now posted. Again, all the sessions, panels, and lightning talks have been professionally recorded and will be available online -- but it takes time to process over 100 talks, so expect it to take a few weeks to get them all up.
We already linked to Stroustrup's opening keynote and the Grill the Committee Panel. Here are the links to the rest of the keynote/plenary sessions -- you won't want to miss them.
extern "C": Talking to C Programmers About C++ (Dan Saks)
Our summary: A wonderful talk on communication skills and efficiency facts vs. perceptions, while staying well grounded in technical substance and empirical measurement throughout.
Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17 (Jason Turner)
Our summary: A tour de force on what "zero overhead" really means, and how and why C++ delivers it, with live demonstration of "what this code actually compiles down to" throughout. You'll be linking to this video for a long time when someone asks whether C++ really compiles to clean-and-lean object code.
Developing Blockchain Software (David Schwartz)
Our summary: One of the world's leading experts in an economically important software field shows what "demanding software" entails and how C++ works well to meet the efficiency and security challenges of Bitcoin and Ripple.
Leak-Freedom in C++... By Default (Herb Sutter)
Our summary: A "Part 2" of last year's talk about preventing dangling "non-owner" pointers and iterators, this year's talk deals with the complementary topic of how to manage "owner" abstractions so that unused objects are cleaned up promptly, without resorting to "delete" and dealing with real issues like bounded stacks and cycles.
Here are the longer abstracts below. We hope you enjoy the talks.
extern "C": Talking to C Programmers About C++ (Dan Saks)
Most of us have heard this story. We’ve even told it ourselves…
C++ is nearly all of C, plus a whole lot more. Migrating code from C to C++ is pretty easy. Moreover, the migration itself can yield immediate benefits by exposing questionable type conversions that can be sources of latent bugs. After migration, the code performs as well in C++ as in the original C. And now that it’s C++, you have ready access to a wealth of advanced features you can (but don’t have to) use to implement enhancements.
Who wouldn’t want that? Legions of C programmers, apparently.
Despite the success of C++ in numerous application domains, C remains considerably more popular, especially in embedded, automotive, and aerospace applications. In many cases, projects resist C++ because their managers think the risks outweigh the benefits. In other cases, the resistance comes from programmers who persist in believing bad things about C++, even when those things aren’t true.
What can the C++ community do to overcome this resistance? Drawing on lessons from cognitive science, linguistics and psychology, and (of course) computer science, this talk offers suggestions about how to make the case for C++ more persuasive to C programmers.
Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17 (Jason Turner)
The Commodore 64 was released in 1982 and is the best selling computer model of all time. At 34 years old, even the most simple embedded processor today outperforms it. Join me on an exploration of how C++17 techniques can be utilized to write expressive, high performance, high level code for simple computers. Together we will create a game for this aging system.
You'll leave the talk with a better understanding of what your compiler is capable of and be able to apply these ideas to create better code on modern systems.
Developing Blockchain Software (David Schwartz)
This talk will explain what public blockchain systems like Bitcoin and Ripple are, the unique challenges of developing software for them, and how C++ helps to meet these challenges.
Security issues are paramount. Blockchain systems are open source, have large attack surfaces, and can cause significant financial damage if they have exploitable defects. Performance and scalability are also major concerns.
C++ provides a unique balance that helps meet these challenges. The language's design makes it possible to catch bugs at compile time, write modular code that can be tested, develop flexible data structures and manage resources. Yet, where performance is critical, it does not obscure what your code is making the computer actually do.
The primary purpose of the talk is to explain what blockchains are, increase understanding of the unusual challenges developers of blockchain software experience, and to demonstrate why C++ is a good choice to address them.
Leak-Freedom in C++... By Default (Herb Sutter)
Lifetime safety means writing code that, by construction, is guaranteed to eliminate two things: (a) use of null/dangling pointers (including pointerlike things such as references, iterators, views, and ranges), and (b) leaks (including the rare 1% case where we’re tempted to admit the possibility of an ownership cycle or need to support lock-free concurrent data structures).
Last year, my CppCon 2015 talk “Writing Good C++14… By Default” focused on (a), null/dangling, because it's the more difficult and usually more serious problem. I gave an overview of a new approach of using static analysis rules to eliminate use of null and dangling in C++. That work continues and we’re in the process of writing down the formal rules for the approach that I showed last year.
This year, the focus will be on (b), leaks: The talk aims to begin with a set of simple rules, the “5-minute talk” to demonstrate that a handful of rules can be taught broadly to programmers of all levels, and results in code that is clean and free of leak bugs by construction.
But, since we’ll still have 85 minutes left, we can use the time to spelunk through a series of “Appendix” code examples, in which we'll demonstrate "why and how" to apply those rules to a series of increasingly complex/difficult situations, and that are aimed at increasingly advanced and “clever” (note: not always a good thing) programs and programmers. We’ll address questions such as: How should we represent Pimpl types? How should we represent trees – what should the child and parent pointer types be, and (when) should they be unique and when shared? How should we deal with “intra-module” or “encapsulated” cycles when you control all the objects in the cycle, such as all the nodes within a Graph? And what about “inter-module” or “compositional” cycles when you don’t know in advance about all the objects that could be in the cycle, such as when combining libraries written by different people in a way that may or may not respect proper layering (notoriously, using callbacks can violate layering)? The answers focus on cases where we have solid guidance, and then move toward some more experimental approaches for potentially addressing the ~1% of cases that aren’t yet well covered by unique_ptr, shared_ptr, and weak_ptr.
CppCast Episode 71: CppCon 2016 with Chandler Carruth
Episode 71 of CppCast the only podcast for C++ developers by C++ developers. In this special CppCon episode Rob and Jason interview a group of Lightning Talk speakers and Chandler Carruth. Chandler discusses the topics of his two CppCon talks and using Modules at Google.
CppCast Episode 71: CppCon 2016 with Chandler Carruth
by Rob Irving and Jason Turner
About the interviewee:
Chandler Carruth leads the Clang team at Google, building better diagnostics, tools, and more. Previously, he worked on several pieces of Google’s distributed build system. He makes guest appearances helping to maintain a few core C++ libraries across Google’s codebase, and is active in the LLVM and Clang open source communities. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. He is regularly found drinking Cherry Coke Zero in the daytime and pontificating over a single malt scotch in the evening.
Chobo Single-Header Libraries Released
Chobo SHL is a collection of five small single-header libraries with no external dependencies by Chobolabs.
Chobo SHL Released
by Chobolabs
From the release:
The list of libraries is:
- optional - A value wrapper with an optional invalid state (similar to
boost::optional)- static_vector - A std::vector-like class with fixed capacity (similar to boost::static_vector)
- flat_map - A std::map-like class with linear storage and optional storage container (similar to boost::flat_map)
- vector_ptr - A non-owning std::vector pointer to be used in generic code
- vector_view - A view of a std::vector<T> which makes it look as a vector of another type
doctest—the lightest feature rich C++ single header testing framework released! -- Viktor Kirilov
The lightest feature--rich C++ single--header testing framework for unit tests and TDD
doctest 1.1.0 released!
by Viktor Kirilov
From the release:
- huge improvements in compile times of asserts -- 70--95% faster than the first release!
- many minor fixes -- see the changelog
- improved documentation -- and the much requested differences with Catch section in the FAQ
The reddit thread might be of interest as well.
The project is looking for sponsors and publicity!