June 8-13, Brno, Czechia
June 17-20, Folkestone, UK
September 12-18, Aurora, CO, USA
November 16-21, Búzios, Rio De Janeiro, Brazil
November 26-28, Berlin, Germany
By Meeting C++ | Oct 31, 2014 03:57 AM | Tags: performance intermediate efficiency c++14 c++11 boost advanced
One of the issues I was thinking about since C++Now: move and move-destruction
C++ and Zombies: a moving question
by Jens Weller
From the article:
This has been on my things to think about since C++Now. At C++Now, I realized, that we've might got zombies in the C++ standard. And that there are two fractions, one of them stating, that it is ok to have well defined zombies, while some people think that you'd better kill them.
By Meeting C++ | Oct 25, 2014 01:59 AM | Tags: intermediate experimental c++17 c++ committee basics advanced
I've started with my series on the proposals for the next C++ Committee Meeting:
Urbana Proposals - C++17 insight?
by Jens Weller
From the article:
A short series to give you an overview over the Papers submitted in the latest mailing for the C++ Committee Meeting in Urbana-Champaign in Illinois. At the beginning of November the C++ Committee will have its 3rd Meeting this year. As C++14 is now finished, the focus is clearly on the upcoming C++17 standard.
By Blog Staff | Oct 5, 2014 09:26 PM | Tags: intermediate
Quick A: Yes.
A classic on SO, just re-asked yesterday:
When to use std::begin and std::end instead of container specific versions
Are there any general preferences or rules that explain when container specific versions of
beginandendshould be used instead of free functionsstd::beginandstd::end?It is my understanding that if the function is a template whereby the container type is a template parameter then
std::beginandstd::endshould be used, i.e.:template<class T> void do_stuff( const T& t ) { std::for_each( std::begin(t), std::end(t), /* some stuff */ ); }What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use
std::begin(cont)andstd::end(cont)or should the container's member functionscont.begin()andcont.end()be preferred?Am I correct in assuming that there is no benefit in performance by calling
cont.end()overstd::end(cont)?
By Meeting C++ | Oct 3, 2014 07:49 AM | Tags: performance intermediate efficiency c++14 c++11 boost basics
I've written down some basic thinking on new and new standards:
Insights into new and C++
by Jens Weller
From the article:
Every now and then, I've been thinking about this. So this blogpost is also a summary of my thoughts on this topic, dynamic memory allocation and C++. Since I wrote the blog entries on smart pointers, and C++14 giving us make_unique, raw new and delete seem to disappear from C++ in our future code...
By Blog Staff | Sep 29, 2014 12:24 AM | Tags: intermediate
Recently on StickyBits, a nice primer on variadics:
Variadic Templates
by feabhas
From the article:
In this article we’re going to look at a new feature of templates in C++11 -- the concept of the variadic template.
Variadic templates allow us to create functions and classes, not only with generic types, but also a variable number of generic types.
If you haven’t been following along with the template articles, I’d suggest you read this article first before continuing.
By Blog Staff | Sep 24, 2014 02:49 AM | Tags: intermediate constexpr
Quick A: Yes, when the string being traversed is itself a constant expression, such as a string literal.
Recently on StackOverflow:
Computing length of a C string at compile time. Is this really a constexpr?
I'm trying to compute the length of a string literal at compile time. To do so I'm using following code:
#include <cstdio> int constexpr length(const char* str) { return *str ? 1 + length(str + 1) : 0; } int main() { printf("%d %d", length("abcd"), length("abcdefgh")); }Everything works as expected, the program prints 4 and 8. The assembly code generated by clang shows that the results are computed at compile time:
0x100000f5e: leaq 0x35(%rip), %rdi ; "%d %d" 0x100000f65: movl $0x4, %esi 0x100000f6a: movl $0x8, %edx 0x100000f6f: xorl %eax, %eax 0x100000f71: callq 0x100000f7a ; symbol stub for: printfMy question: is it guaranteed by the standard that length function will be evaluated compile time?
If this is true the door for compile time string literals computations just opened for me... for example I can compute hashes at compile time and many more...
By Blog Staff | Sep 16, 2014 11:43 AM | Tags: intermediate
Recently on Tales of C++:
When Size Does Matter
by K-ballo
In the C++ lands every object has mass; for any complete type T, sizeof(T) is greater than zero. This keeps array indexing and pointer arithmetics from collapsing, but it also means that empty objects occupy space. Furthermore, when an empty object is placed in a class next to a bigger member, padding may — and in all likeliness will — be added due to alignment requirements, resulting in an empty member taking more than just one byte of storage.
Certainly something has to be done about this...
By Blog Staff | Sep 5, 2014 01:39 PM | Tags: intermediate c++14
A nice complement to the C++14 lambda article we linked to yesterday:
Lambda Over Lambda in C++14: The Convergence of Modern C++ on the Lisp Programming Style, Part II
by Chris Kohlhepp
From the article:
Let us see how that simplifies under C++14 and generic lambdas.
Three observations are striking immediately:
1) The use case for a template has disappeared entirely. We simply have a generic function argument x. This matches Lisp.2) The code is now entirely as brief as Lisp. Where Lisp has a lot of parenthesis, this style of coding develops a lot of “autos.”
3) The mechanics are identical also. Both functions are actually named lambdas...
By Blog Staff | Sep 4, 2014 01:24 PM | Tags: intermediate
"Are you an enum?" "Are you polymorphic?" The answers to these type questions and more are already in your C++11 standard library:
Introduction to Type Traits in the C++ standard library
by Yvonne Ma
From the article:
... As its name suggests, Type Traits exposes different characteristics of types, or simply the “type of type”. In many C++ programming practices, especially these in template metaprogramming, developers may find it difficult to build a template work for all types without knowing the characteristics of a type. That’s the key reason for the emergence of Type Trait...
By Blog Staff | Sep 4, 2014 11:46 AM | Tags: intermediate basics advanced
Here's a recent series that just got a new instalment today: It introduces template basics in a nicely explained and accessible way suitable for a gentle introduction, and then going on to progressively help the reader develop stronger template muscles.
C++ Templates series
by Feabhas
An Introduction to C++ Templates
And today: Template Specialization
From the Introduction:
Templates are a very powerful -- but often very confusing -- mechanism within C++. However, approached in stages, templates can be readily understood (despite their heinous syntax).
The aim of this series of articles is to guide beginners through the syntax and semantics of the foundation concepts in C++ template programming.
