C++ Annotated: March – May 2016--Anastasia Kazakova
An overview of the recent C++ world:
C++ Annotated: March – May 2016
by Anastasia Kazakova
From the article:
In this edition:
- Conferences
- News & Stories
- Webinars
- Releases
Articles & Books
VoidParam Puzzle -- Alex Marmer
Alex Marmer has openend a puzzle.
VoidParam Puzzle
From the article:
How to handle 'void' parameter passed in a macro. He provides a solution as well.
In case that you have other or better solutions, don't hesitate to use the comment option on this site.
Compile Time Constants Part 1: Why We Need Them--Arne Mertz
The title says it all:
Compile Time Constants Part 1: Why We Need Them
by Arne Mertz
From the article:
Compile time constants are an important part of C++. They contribute to program correctness and allow the optimizer to do a better job. Today I will deal with what is possible in terms of compile time constants and compile time calculations in C++03.
Quick Q: If nullptr_t isn't a keyword, why are char16_t and char32_t?
Quick A: To allow overloading with the underlying types of uint_least16_t and uint_least32_t
Recently on SO:
If nullptr_t isn't a keyword, why are char16_t and char32_t?
The proposal itself explains why: to allow overloading with the underlying types of
uint_least16_tanduint_least32_t. If they were typedefed this wouldn't be possible.DefineAs for why they aren't in the std namespace, this is for compatibility with the original C proposal. C++ prohibits the C definitions from appearing in its own version ofchar16_tto be a distinct new type, that has the same size and representation asuint_least16_t. Likewise, definechar32_tto be a distinct new type, that has the same size and representation asuint_least32_t.[N1040 defined
char16_tandchar32_tas typedefs touint_least16_tanduint_least32_t, which make overloading on these characters impossible.]<cuchar>[c.strings] / 3
The headers shall not define the typesThe types then would need to be global typedefs, which carries its own set of issues such aschar16_t,char32_t, andwchar_t(2.11).typedef decltype(u'q') char16_t; namespace foo { typedef int char16_t; }The reason for
std::nullptr_tnot being a keyword can be found in the question you linkedWe do not expect to see much direct use ofmakingnullptr_tin real programs.nullptr_tthe real exception here.
C++ for Games: Performance, Allocations and Data Locality -- Sergey Ignatchenko
Well-illustrated, and well-illustrated, gems:
C++ for Games: Performance, Allocations and Data Locality
by Sergey Ignatchenko
From the draft chapter:
One further thing to keep in mind with regards to 90-10 (or 70-30) rule is that even if only performance of 10% of the code matters, the rest of the code can still affect performance of critical 10% in a Pretty Bad Way :-( ...
C++ Performance: Common Wisdoms and Common "Wisdoms" -- Sergey Ignatchenko
Sergey is writing a book and making draft chapters available for review. Here are s
Some tried-and-true, well-illustrated and entertaining tips:
C++ Performance: Common Wisdoms and Common "Wisdoms"
by Sergey Ignatchenko
From the draft chapter intro:
The opposite of a fact is falsehood, but the opposite of one profound truth may very well be another profound truth. — Niels Bohr
There are quite a few common wisdoms when it comes to C++ and games. As it always the case when facing a bunch of common wisdoms, some of them have their merits, some are obsolete-beyond-belief, and some are just taken from a very different context and are not really applicable. Let’s take a look at the most popular ones...
Quick Q: Is final used for optimization in C++?
Quick A: Possibly.
Recently on SO:
Is final used for optimization in C++?
It can be.
An optimisation along these lines would relate to the "de-virtualization" of the virtual calls. This is not always immediately affected by the
finalof the class nor method. Albeit they offer help to determine this, the normal rules of the virtual functions and class hierarchy apply.If the compiler can determine that at runtime a particular method will always be called (e.g. given the OP example, with an automatic object), it could apply such an optimisation anyway, irrespective of whether the method is
finalor not.Optimisations fall under the as-if rule, that allow the compiler to apply any transformation so long as the observable behaviour is as-if the original code had been executed.
CppCon 2015 What's New in Visual C++ 2015 and Future Directions--Steve Carroll • Ayman Shoukry
Have you registered for CppCon 2016 in September? Don’t delay – Early Bird registration is open now.
While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:
What's New in Visual C++ 2015 and Future Directions
by Steve Carroll • Ayman Shoukry
Summary of the talk:
In this talk, we'll discuss new features, optimizations, and scenarios in Visual Studio 2015. We'll cover new backend optimizations, improved build throughput, new productivity and diagnostics features, and give a detailed update on our conformance progress, as well as talk about cool new c++1y features that we are shipping from await to modules.
Visual Studio isn't just for Microsoft platform developers. We'll also demonstrate our latest cross platform C++ development features for Android and iOS. We'll also give a sneak peak at our work on combining the Clang frontend with our existing backend to bring Clang support for Windows to Visual Studio.
Quick Q: was raw-pointer constructor of shared_ptr a mistake?
Quick A: No, its usage is well defined.
Recently on SO:
was raw-pointer constructor of shared_ptr a mistake?
In hindsight, given make_shared, would shared_ptr have a constructor that takes a raw pointer had it been introduced with C++11?
What if you don't control the allocation of the object? What if you need to use a custom deleter? What if you need list-initialization instead of parens?None of these cases is handled by
make_shared.Additionally, if you're using
weak_ptr, ashared_ptrallocated viamake_sharedwon't free any memory until all theweak_ptrs are destroyed as well. So even if you have a normal shared pointer where none of the above apply, it's possible that you may still prefer the raw pointer constructor.Yet another situation would be if your type provides overloads for operator
newand operatordelete. These may make it ill-suited formake_shared, since those overloads will not be called - and presumably they exist for a reason.
Quick Q: What makes moving objects faster than copying?
Quick A: it allows to steal ressources instead of creating new ones.
Recently on SO:
What makes moving objects faster than copying?
It's all about implementation. Consider simple
stringclass:class my_string { char* ptr; size_t capacity; size_t length; };Semantics of copy requires us to make a full copy of string including allocation of another array in dynamic memory and copying
*ptrcontents there, which is expensive.Semantics of move requires us only to transfer the value of pointer itself to new object without duplicating contents of
string.If, of course, class doesn't use dynamic memory or system resources, then there is no difference between moving and copying in terms of performance.