Home » Blog » Tags » intermediate

intermediate

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

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.

Exploring std::string--Shahar Mike

By Adrien Hamelin | Sep 13, 2016 12:40 PM | Tags: intermediate community

The insides are revealed:

Exploring std::string

by Shahar Mike

From the article:

Every C++ developer knows that std::string represents a sequence of characters in memory. It manages its own memory, and is very intuitive to use. Today we’ll explore std::string as defined by the C++ Standard, and also by looking at 4 major implementations.

Type annotation in C++--Stoyan Nikolov

By Adrien Hamelin | Sep 12, 2016 01:44 PM | Tags: intermediate efficiency

How do you do it?

Type annotation in C++

by Stoyan Nikolov

From the article:

In systems like game engines and our HTML renderer Hummingbird, developers have to work with objects transformed in different coordinate systems. Using one generic type can lead to confusion on what object is required in a particular situation. Errors are often subtle and hard to track. I tried to mitigate this by using stringent static typing in our software. New types are created by annotating them with metadata...

Auto Type Deduction in Range-Based For Loops--Petr Zemek

By Adrien Hamelin | Sep 9, 2016 12:17 PM | Tags: intermediate c++11

Which one to use?

Auto Type Deduction in Range-Based For Loops

by Petr Zemek

From the article:

Have you ever wondered which of the following variants you should use in range-based for loops and when? auto, const auto, auto&, const auto&, auto&&, const auto&&, or decltype(auto)? This post tries to present rules of thumb that you can use in day-to-day coding. As you will see, only four of these variants are generally useful.

Quick Q: Is the std::array bit compatible with the old C array?

By Adrien Hamelin | Sep 7, 2016 02:28 PM | Tags: intermediate c++11

Quick A: Yes, you can copy bitwisely from one to the other.

Recently on SO:

Is the std::array bit compatible with the old C array?

The requirement on the data() method is that it return a pointer T* such that:

[data(), data() + size()) is a valid range, and data() == addressof(front()).

This implies that you can access each element sequentially via the data() pointer, and so if T is trivially copyable you can indeed use memcpy to copy sizeof(T) * size() bytes to/from an array T[size()], since this is equivalent to memcpying each element individually.

However, you cannot use reinterpret_cast, since that would violate strict aliasing, as data() is not required to actually be backed by an array - and also, even if you were to guarantee that std::array contains an array, since C++17 you cannot (even using reinterpret_cast) cast a pointer to an array to/from a pointer to its first member (you have to use std::launder).