Comparison and Inheritance -- Andrew Koenig
Comparison and Inheritance
by Andrew Koenig
We continue last week's discussion of comparison functions by thinking about how to compare objects from different parts of an inheritance hierarchy...
March 19-21, Madrid, Spain
April 1-4, Bristol, UK
June 16-21, Sofia, Bulgaria
By Blog Staff | Feb 25, 2013 03:11 PM | Tags: intermediate
Comparison and Inheritance
by Andrew Koenig
We continue last week's discussion of comparison functions by thinking about how to compare objects from different parts of an inheritance hierarchy...
By Blog Staff | Feb 25, 2013 08:55 AM | Tags: basics
People new to C++11 often hear about move semantics, and expect that they have to do work to take advantage of it. That's often not true, and often the cleanest, simplest code that doesn't even mention
move
or &&
anywhere is just what you want -- that's C++11, clean, safe, and faster than ever.
Perhaps the most common case (and question) involves returning values from functions. The new rule for modern C++ style: Just return even big objects by value, and move Just Happens.
It just came up again on StackOverflow:
C++11 rvalues and move semantics confusion
The link skips straight to Howard Hinnant's clear and correct answer.
Sometimes we just try too hard, because we expect efficient programming not to be easy. Welcome to C++11.
By Blog Staff | Feb 24, 2013 12:59 PM | Tags: None
Another step forward in C++ community libraries, joining others including Facebook's and Microsoft's OSS C++ work. This from last.fm last week:
All our tools are belong to you (last.fm)
by Marcus Holland-Moritz
Today we’re releasing moost, a C++ library with all the nice little tools and utilities our MIR team has developed over the past five years. If you’re a C++ developer yourself, you might notice that moost sounds quite similar to boost, and that’s on purpose. moost is the MIR team’s boost, there is hardly a project in our codebase that doesn’t depend on one or more parts of moost.
There are a lot of different things in moost...
By Blog Staff | Feb 24, 2013 07:34 AM | Tags: experimental
During the C++11 standards development cycle, much work was done on a feature called "concepts" which aimed at providing systematic constraints on templates. Concepts was deferred from C++11 for lack of time to complete it, but work has continued.
In January 2012, the results of a major "concepts summit" were published as a 133-page report titled "A Concept Design for the STL" (WG21 paper N3351).
Now, a draft of new paper is available proposing a very useful subset of concepts, dubbed "Concepts Lite", for near-term consideration including at the spring ISO C++ meeting in Bristol, UK, this April. For example, imagine writing this template:
template<Sortable Cont> void sort(Cont& container);
and when you call it like this:
list<int> lst = ...; // oops, bidirectional iterators sort(lst); // today, results in very long "template spew" error message
getting this short and non-cryptic error message:
error: no matching function for call to ‘sort(list<int>&)’ sort(l); ^ note: candidate is: note: template<Sortable T> void sort(T) void sort(T t) { } ^ note: template constraints not satisfied because note: 'T' is not a/an 'Sortable' type [with T = list<int>] since note: 'declval<T>()[n]' is not valid syntax
That's an actual error message from the prototype GCC implementation linked below.
We're very excited about this feature and its continued progress. Here are links to the draft of the new paper:
Concepts Lite: Constraining Templates with Predicates (PDF) (Google Docs)
From the Introduction:
In this paper, we introduce template constraints (a.k.a., “concepts lite”), an extension of C++ that allows the use of predicates to constrain template arguments. The proposed feature is minimal, principled, and uncomplicated. Template constraints are applied to enforce the correctness of template use, not the correctness of template definitions. The design of these features is intended to support easy and incremental adoption by users. More precisely, constraints:
- allow programmers to directly state the requirements of a set of template arguments as part of a template’s interface,
- support function overloading and class template specialization based on constraints,
- fundamentally improve diagnostics by checking template arguments in terms of stated intent at the point of use, and
- do all of this without any runtime overhead or longer compilation times.
This work is implemented as a branch of GCC-4.8 and is available for download at http://concepts.axiomatics.org/~ans/. The implementation includes a compiler and a modified standard library that includes constraints. Note that, as of the time of writing, all major features described in this report have been implemented.
Related links:
By Blog Staff | Feb 24, 2013 07:27 AM | Tags: None
A new publicly readable committee forum is now available on the Forums page:
SG8 : Concepts
Near-term focus is on a convergence between the
static if
proposals and the parameter-type-constraints subset of concepts.
Note that this forum is for standardization of a new feature; do not expect the features mentioned in this forum to be available yet in your own compiler. However, if you're interested in seeing the shape of the feature as it advances to being approved by the committee likely in the near future, this forum is for you.
For information about this and other SGs, see also:
By Blog Staff | Feb 21, 2013 09:25 AM | Tags: intermediate
To accept a functor as a parameter, when should you:
std::function
, which adds an indirection, vs.template<class Func>
and accept a Func
, which can bind directly to whatever is passed?std::function vs template
Thanks to C++11 we received the
std::function
family of functor wrappers. Unfortunately, I keep hearing [...] that they are horribly slow. [... Is the right recommendation] thatfunction
s can be used as de facto standard of passing functors, and in places where high performance is expected templates should be used?
By Blog Staff | Feb 19, 2013 04:39 AM | Tags: basics
Quick A: Using the form of
insert
that takes an rvalue and passing a temporary or a std::move
'd object, or calling emplace
.
Moving an object into a map
The problem with this is that the huge objects will be copied into the maps
Huge huge1(some,args); Huge huge2(some,args); std::map<int,Huge> map1; std::map<Huge,int> map2; map1.insert({0,huge1}); map2.insert({huge2,0});how can I guarantee a move? Will this work or is there more to it?
map1.insert({0,std::move(huge1)}); map2.insert({std::move(huge2),0});
By Blog Staff | Feb 18, 2013 05:32 PM | Tags: intermediate basics
Quick A: Yes. Another way that modern C++ is safer and simpler.
(If you don't know what the safe-bool idiom is, don't worry. It's a workaround that's now obsolete.)
Xeo asked:
Is the safe-bool idiom obsolete in C++11?
This answer of @R. Martinho Fernandes shows, that the safe-bool idiom is apperently deprecated in C++11, as it can be replaced by a simple
explicit operator bool() const;... Is our assumption in the title correct? I hope we didn't overlook any potential drawbacks.
By Blog Staff | Feb 15, 2013 10:38 AM | Tags: intermediate basics
Andrzej continues this month with more interesting thoughts on preconditions.
Preconditions, Part 2
by Andrzej Krzemieński
In this post I will continue sharing my thoughts on preconditions. It will cover some philosophy behind the concept of preconditions (and bugs), and investigate the possibility of employing the compiler to verify some preconditions. Many people provided a useful feedback on my previous post. I will also try to incorporate it into this post.
Note that this article diverges from recommended practice in one way... it hints at the idea of throwing exceptions to report precondition violations. Instead, per C++ Coding Standards and other established guidance, prefer to use assertions to check preconditions: precondition violations are just bugs in the caller's code that should be caught at test time, assertions cause no overhead in production, and assertions fire immediately at the line of code that contains the bug without losing the call stack and other local context. Using assertions is still considered to be a best practice.
By Blog Staff | Feb 14, 2013 09:39 AM | Tags: basics
Learning Modern C++: An Interview with Barbara Moo
by Jeff Martin
The popularity of C++ has varied throughout the years since its introduction in the 1980s. The rise of managed languages like Java and C# along with the emergence of scripting languages like JavaScript, Python, and Ruby has affected C++'s adoption. Yet many supporters like C++ for the control, raw power, and speed that it offers. C++11 promises to bring that power to programmers in a more efficient manner, and the changes it introduces illustrate how much the language has grown in the past 30 years. Programmers looking to learn about C++11 or perhaps sample C++ for the first time would do well to try C++ Primer, 5th Edition by Stanley B. Lippman, Josée Lajoie, and Barbara E. Moo. InfoQ had the opportunity to speak with Ms. Moo about her new book and the C++ language as a whole.