Home » Blog » 2016 » September

September 2016

C++ in Competitive Programming: compromises--Marco Arena

By Marco Arena | Sep 30, 2016 10:27 AM | Tags: intermediate

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

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.