September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
By Adrien Hamelin | Sep 13, 2016 01:00 PM | Tags: intermediate experimental
The future is already here.
Localizing Code With std::variant
by Cameron DaCamara
From the article:
As we all know, C++17 is on the horizon. With it’s release will comes a new member to the data container family,
std::variant...
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::stringrepresents a sequence of characters in memory. It manages its own memory, and is very intuitive to use. Today we’ll explorestd::stringas defined by the C++ Standard, and also by looking at 4 major implementations.
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...
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&&, ordecltype(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.
By Adrien Hamelin | Sep 9, 2016 12:06 PM | Tags: c++11 basics
Let's review the basics!
Great Expectations
by Glennan Carnie
From the article:
Previously, we’ve looked at the basic concepts of function parameter passing, and we’ve looked at the mechanics of how parameters are passed at the Application Binary Interface (ABI) level.
Far too often we focus on the mechanisms and efficiency of parameter passing, with the goal: if it’s efficient then it’s good; that’s all there is to it. In this article I want to move past simple mechanics and start to explore function parameter design intent – that is, what can I expect (to change) about the objects I use as function arguments; and what can I expect to be able to do with an object as a function implementer.
To that end, we’ll take a look at parameter passing from the perspective of the mutability (ability to be modified) of the parameters from both a caller’s and a function’s (callee’s) point of view...
By onqtam | Sep 8, 2016 11:33 PM | Tags: None
Even cmake is not about C++, it is the most popular platform independend make tool used for C++.
awesome-cmake Released!
by Viktor Kirilov
From the collection:
This curated list contains awesome CMake scripts, modules, examples, and others.
By Adrien Hamelin | Sep 7, 2016 02:37 PM | Tags: c++11 basics
Quick A: It prevents you of being able to move your class.
Recently on SO:
Marking std::unique_ptr class member as const
Because of the nature of a
std::unique_ptr(sole ownership of an object) it's required to have no copy constructor whatsoever. The move constructor(6) only takes non-const rvalue-references which means that if you'd try to make your_childconstand move it you'd get a nice compilation errorEven if a custom
unique_ptrwould take a const rvalue-reference it would be impossible to implement.
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 pointerT*such that:[data(), data() + size())is a valid range, anddata() == addressof(front()).This implies that you can access each element sequentially via the
data()pointer, and so ifTis trivially copyable you can indeed usememcpyto copysizeof(T) * size()bytes to/from an arrayT[size()], since this is equivalent tomemcpying each element individually.However, you cannot use
reinterpret_cast, since that would violate strict aliasing, asdata()is not required to actually be backed by an array - and also, even if you were to guarantee thatstd::arraycontains an array, since C++17 you cannot (even usingreinterpret_cast) cast a pointer to an array to/from a pointer to its first member (you have to usestd::launder).
By Meeting C++ | Sep 1, 2016 12:58 AM | Tags: user group community basics
The monthly overview on upcoming C++ User Group meetings by Meeting C++:
C++ User Group meetings in September
by Jens Weller
From the article:
Another month, another round of User Group Meetings! September has lots of User Groups meeting (32 in total), and offers a highlight of the C++ year: CppCon!
There are 2 new C++ User Groups: Cary, NC and Bangalore (Qt)...
By Adrien Hamelin | Aug 29, 2016 01:08 PM | Tags: c++11 advanced
Following here is an advanced article about the behavior of C++ concerning copy and move operations. A more simple version is provided for a quicker and easier understanding of the best practices. The sum up is, don't declare as deleted a move constructor!
A more user friendly version
by Howard Hinnant
Episode Eleven: To Kill a Move Constructor
by Agustín "K-ballo" Bergé
From the article:
Unlike copy operations, which are provided by the compiler if not user declared, move operations can and often are suppressed such that a class might not have one. Furthermore, it is possible for a class to have a —user declared— move operation which is both defined as deleted, and at the same time ignored by overload resolution, as if it didn't exist...
