Home » Blog » Categories »

The Case for Optional References--Tristan Brindle

By Adrien Hamelin | Sep 30, 2016 08:59 AM | Tags: intermediate experimental boost

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...

CppCast Episode 72: Boost::Process with Klemens Morgenstern

By robwirving | Sep 30, 2016 08:03 AM | Tags: None

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.

Quick Q: std::ignore for ignoring unused variable

By Adrien Hamelin | Sep 29, 2016 11:52 AM | Tags: intermediate c++11

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::ignore may 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 non­static 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_unused declared variables.

Quick Q: Initializing a std::string with function return value, is there a copy?

By Adrien Hamelin | Sep 29, 2016 11:47 AM | Tags: c++11 basics

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.

CppCon2016: All keynote/plenary sessions are now posted on YouTube

By Blog Staff | Sep 26, 2016 09:38 AM | Tags: None

cppcon2016-plenaries.PNGCppCon 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.