February 10-15, Hagenberg, Austria
March 19-21, Madrid, Spain
April 1-4, Bristol, UK
June 16-21, Sofia, Bulgaria
By Adrien Hamelin | Jun 8, 2015 09:26 AM | Tags: c++11 basics
static_assert
by Glennan Carnie
From the article:
C’s assert library is a useful tool for catching invalid invariants (conditions that must hold true in order for your system to operate as specified) in your program. The big problem with assert is that it’s a run-time check; in many cases the best you can do to recover from an assert failure is restart the system or put it into a quiescent state...
By Andrey Karpov | Jun 4, 2015 11:48 PM | Tags: errors compilers compiler bugs basics
Many programmers are very fond of blaming the compiler for different errors. Let's talk about it.
The compiler is to blame for everything
by Andrey Karpov
From the article:
When a programmer tells you that the compiler causes an error, it is a lie in 99% of cases. When you start investigating the problem, you usually find out the following reasons:
- an array overrun;
- an uninitialized variable;
- a misprint;
- a synchronization error in a parallel program;
- a non-volatile variable used;
- code leading to undefined behavior;
- etc.
By Adrien Hamelin | May 28, 2015 02:31 PM | Tags: c++11 basics
Quick A: To avoid breaking old code, thanks to context-sensitive keywords.
Recently on SO:
Why are override and final identifiers with special meaning instead of reserved keywords?
Both the override specifier and final specifier were added in C++11. They differ from other specifiers added to C++11 such as constexpr and decltype, in that they are not keywords and so are available for use as identifiers:
int main() { int override = 0 ; // Ok int final = 0 ; // Ok //int constexpr = 0 ; // Error }They are referred to as identifiers with special meaning, which is covered in the draft C++11 standard section 2.11 [lex.name] (emphasis mine):
The identifiers in Table 3 have a special meaning when appearing in a certain context. When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production. any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.
and Table 3 -- Identifiers with special meaning lists both override and final.Why did these two specifiers end up being identifiers with special meaning instead of keywords?
By Adrien Hamelin | May 26, 2015 08:00 AM | Tags: performance basics
The way the STL takes comparators is not the better thing in some cases, like with the following comparator:
[] (const T& a, const T& b) { return expensive_function(a) < expensive_function(b); }
By aleph7 | May 7, 2015 12:08 AM | Tags: community c++14 c++11 basics
This workshop is an introduction to new features and best practices of modern C++. We will delve into the core of C++ and all new features introduced in C++11 and C++14.
Introduction to Modern C++ Workshop happening at Polyglot Unconference 2015 in Vancouver, BC.
by Alejandro Isaza
From the workshop summary:
- Write C++ code using the latest language features while following the best practices
- Use third-party libraries and frameworks
By Adrien Hamelin | May 4, 2015 08:02 AM | Tags: c++14 basics
Binary literals and digit separators
by Marius Bancila
From the article:
The C++14 standard provides two new small features to the language: binary literals and digit separators. They are already available in Clang 3.4 and GCC 4.9 and now Visual Studio 2015 RC has implemented them. They may not be something you can’t leave without, but sometimes it’s convenient to have them. Let’s have a look...
By Adrien Hamelin | Apr 24, 2015 09:02 AM | Tags: basics
A clever comment style
by Andrzej Krzemieński
From the article:
Comments are one of the most useful language features; in practically any programming language. Yet, they can become really a pain...
By Marcin Hoppe | Apr 24, 2015 04:55 AM | Tags: performance efficiency c++11 basics
Explicit C++ describes how to use std::reference_wrapper to create alternative views of data.
Tippet: Use reference_wrapper to create views of data
by Indi
from the article:
When working with objects indirectly, always use references. Only use pointers to indicate optional referencing. But there’s one little hitch: because you can’t rebind references, you can’t simply have a container of references. Enter
std::reference_wrapper.
By Meeting C++ | Apr 24, 2015 01:30 AM | Tags: intermediate gcc experimental c++14 c++11 basics
The release of GCC 5.1 is a highlight, here is an overview on the most important new things:
The C++ highlights of GCC 5.1 and more
by Jens Weller
From the article:
Just recently, GCC 5.0 has been released as GCC5.1, the not only the newest version of GCC, but also bumping up the version number from 4 to 5. This release is a major milestone for GCC, but also for C++, as it brings full C++14 support, but yet not C++11(std=c++11) as the new default...
By Adrien Hamelin | Apr 13, 2015 09:58 AM | Tags: c++11 basics
Quick A: The "= default" keeps the type trivial.
Recently on SO:
How is “=default” different from “{}” for default constructor and destructor?
I originally posted this as a question only about destructors, but now I'm adding consideration of the default constructor. Here's the original question:
If I want to give my class a destructor that is virtual, but is otherwise the same as what the compiler would generate, I can use
=default:class Widget { public: virtual ~Widget() = default; };But it seems that I can get the same effect with less typing using an empty definition:
class Widget { public: virtual ~Widget() {} };Is there any way in which these two definitions behave differently?
Based on the replies posted for this question, the situation for the default constructor seems similar. Given that there is almost no difference in meaning between "
=default" and "{}" for destructors, is there similarly almost no difference in meaning between these options for default constructors? That is, assuming I want to create a type where the objects of that type will be both created and destroyed, why would I want to sayWidget() = default;instead of
Widget() {}?
I apologize if extending this question after its original posting is violating some SO rules. Posting an almost-identical question for default constructors struck me as the less desirable option.