June 16-21, Sofia, Bulgaria
September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 16-21, Kona, HI, USA
By Blog Staff | Jan 5, 2015 06:54 AM | Tags: None
A turn-of-the-year retrospective:
C++ Status at the end of 2014
by Bartlomiej Filipek
From the article:
This was a good year for C++!
Short summary (language features):
- Clang supports C++14
- GCC supports C++11 and most of C++14 (Full support in upcoming GCC 5.0)
- Intel 15.0 supports C++11 (some features on Linux/OSX only)
- Visual Studio tries to catch up with C++11, but it also introduces C++14 features as well... and it become (almost) free!
By Blog Staff | Jan 5, 2015 06:39 AM | Tags: None
Quick A: Because unique_ptr is designed to be zero-overhead, whereas shared_ptr already allocates space and can easily store the type-erased deleter.
Recently on SO:
Deleter type in unique_ptr vs. shared_ptr
I thought it is very curious when I discovered that the standard defines std::unique_ptr and std::shared_ptr in two totally different ways regarding a Deleter that the pointer may own.
By Meeting C++ | Jan 2, 2015 06:07 AM | Tags: user groups intermediate community c++ basics
A new year, and many more user groups? In January there are already 18 planned meetings:
C++ User Group Meetings in January 2015
by Jens Weller
The Meeting List:
7.1 C++ UG Saint Louis - Deep Dive - Part 1
7.1 C++ UG Santa Barbara - Boost Units
8.1 C++ UG NRW/Aachen - Open Source mit Schwerpunkt C++
8.1 C++ UG Dresden - OpenFoam
14.1 C++ UG Utah - Group Exercism.io in C++
14.1 C++ UG San Francisco/ Bay area - Presentation and Q&A
15.1 C++ UG Madrid - De 0 a 100 (Taller)
15.1 C++ UG Hamburg - Mandelbrot mit MPI
19.1 C++ UG Denver - Denver Tech Center C++ Developers
19.1 C++ UG Austin - North Austin Monthly C/C++ Pub Social
19.1 C++ UG Juce - JUCE C++ Meetup San Francisco
20.1 C++ UG Chicago - CUDA
20.1 C++ UG Juce - JUCE C++ Meetup Los Angeles
21.1 C++ UG Bristol - Save the date
21.1 C++ UG Düsseldorf - Treffen der C++ User Gruppe NRW
22.1 C++ UG Rhein-Neckar - Summary of Meeting C++ Conference and Coding Dojo
22.1 C++ UG Munich - Expression Templates Revisited
28.1 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
By Mantosh Kumar | Jan 1, 2015 09:20 PM | Tags: None
In this article author discusses the cost of copying and how move semantics help to manage the resources in an efficent manner.
Move Semantics and Resource Management
In the previous article we looked at the issues of resource management in C++ and introduced “The Rule of The Big Three (and a half)”. In this article we’ll extend this concept by looking at the idea of move semantics, a feature introduced in C++11. Move semantics mean we’ll have to extend our rule to “The Rule of The Big Five” or, perhaps more correctly, “The Rule of The Big Four (and a half)”
By Adrien Hamelin | Jan 1, 2015 08:28 AM | Tags: intermediate c++14
K-ballo’s look at the achievements of C++ completed in 2014 and coming up in 2017, with an overview of draft C++17 features.
Interlude
by K-ballo
From the article:
One year down the road, 2014 has gone by but not without modifications to the C++ lands. C++14 was completed, and Clang has already reached full conformance! But it's not the end of the road, while the Technical Specification (TS) documents continue to move forward, work has started on what it is intended to be C++17...
By Blog Staff | Dec 31, 2014 12:13 PM | Tags: None
Back in the summer we had this SO question:
How to implement classic sorting algorithms in modern C++?
by TemplateRex
From the article:
How to implement classic sorting algorithms in modern C++?
The
There are many questions here and on sister sites such as http://codereview.stackexchange.com/ related to bugs, complexity and other aspects of implementations of these classic sorting algorithms. Most of the offered implementations consist of raw loops, use index manipulation and concrete types, and are generally non-trivial to analyze in terms of correctness and efficiency.std::sortalgorithm (and its cousinsstd::partial_sortandstd::nth_element) from the C++ Standard Library is in most implementations a complicated and hybrid amalgation of more elementary sorting algorithms, such as selection sort, instertion sort, quick sort, merge sort, or heap sort.Question: how can the above mentioned classic sorting algorithms be implemented using modern C++?
- no raw loops, but combining the Standard Library’s algorithmic building blocks from <algorithm>
- iterator interface and use of templates instead of index manipulation and concrete types
- C++14 style, including the full Standard Library, as well as syntactic noise reducers such as auto, template aliases, transparant comparators and polymorphic lambdas
...
Testing
Here are four Live Examples (C++14, C++11, C++98 and Boost, C++98) testing all five algorithms on a variety of inputs (not meant to be exhaustive or rigorous). Just note the huge differences in the LOC: C++11/C++14 need around 120 LOC, C++98 and Boost 180 (+50%) and C++98 more than +100% (note that heap sort could not even be done in terms of standard algorithms).
By Blog Staff | Dec 30, 2014 10:42 AM | Tags: None
Quick A: Yup.
Just before Christmas on StackOverflow:
Can modern C++ get you performance for free?
It is sometimes claimed that C++11/14 can get you a performance boost even when merely compiling C++98 code. The justification is usually along the lines of move semantics, as in some cases the rvalue constructors are automatically generated or now part of the STL. Now I'm wondering whether these cases were previously actually already handled by RVO or similar compiler optimizations.
My question then is if you could give me an actual example of a piece of C++98 code that, without modification, runs faster using a compiler supporting the new language features. I do understand that a standard conforming compiler is not required to do the copy elision and just by that reason move semantics might bring about speed, but I'd like to see a less pathological case, if you will.
EDIT: Just to be clear, I am not asking whether new compilers are faster than old compilers, but rather if there is code whereby adding -std=c++14 to my compiler flags it would run faster (avoid copies, but if you can come up with anything else besides move semantics, I'd be interested, too)
By Mark | Dec 30, 2014 09:18 AM | Tags: intermediate
From the Modern Maintainable Code blog:
Two fundamental implementations for one conceptual task
by Mark Isaacson
Summary:
This is the second article of a series on code reuse. This article provides a discussion of how to approach the problem of having multiple implementations of a single idea and how to programmatically select between them based on patterns in the type information of the parameters.
Out in the real world, functions like
use the same techniques discussed to leverage std::memcpy internally when it's safe to do so.
<span 1;"="">You can find the previous article of the series here, and the prelude to the next, which looks at solving the same problem for structs instead of functions, here.
By Blog Staff | Dec 29, 2014 11:39 AM | Tags: None
Earlier this month, Bjarne Stroustrup posted his new "Five Popular Myths about C++" paper here on isocpp.org in three parts: part 1, part 2, and part 3.
He has now posted the complete paper on his publications page, including typo fixes and some additional comments at the end.
Five Popular Myths about C++
by Bjarne Stroustrup
From the article:
Here, I will explore, and debunk, five popular myths about C++:
- “To understand C++, you must first learn C”
- “C++ is an Object-Oriented Language”
- “For reliable software, you need Garbage Collection”
- “For efficiency, you must write low-level code”
- “C++ is for large, complicated, programs only”
If you believe in any of these myths, or have colleagues who perpetuate them, this short article is for you...
...
Postscript
The 10 sections of this article was posted on isocpp.org in three installments and reposted widely. It attracted a quite varied set of comments. I have now fixed a few typos that were reported. Thanks.
This postscript is my observations on some of the comments posted.
The comments prove – yet again – that the “Myths” paper was needed. People keep repeating the old hairy rationalizations. Unfortunately, many programmers don’t read long papers and dismiss short ones for being incomplete. The unwillingness of many programmers to read a long paper was the reason I released this paper in three separate parts.
This paper is not a research paper carefully outlining every alternative and carefully documenting every detail. I said that right up front:
Each myth requires a long paper or even a book to completely debunk, but my aim here is simply to raise the issues and to briefly state my reasons.
However, many seems to confuse the examples used to illustrate a point with the point itself. Many tried to “debunk the debunking” by changing examples, by changing the constraints on the examples, or by deeming the examples trivial. The examples are small – they have to be to fit into a short paper – but they are not unrepresentative of code found as part of real-world programs.
Many commenters quickly did a shift from the C++11/C++14 that I base my arguments on to some older version. C++14 is not the C++ of the 1980s. It is not what most people were first taught. It is not the C++ that people is presented with in most beginning C++ courses today. It is not what most people see when they look at a large code base. I want to change that. Not being able to do some example that I present in an antique version of C++ or with an outdated compiler is unfortunate, but better versions of the major compiler ship (typically for free) today. I showed no examples of “bleeding edge” code.
The problem of code in older styles is one that every successful programming language must face, so please don’t judge C++ exclusively based on 20-year-old techniques and 10-year old compilers. Look at modern C++ and find ways of getting it into use – many has already. You almost certainly used a program today that was written using C++11. There are C++11 in many steps of the chain between the computer on which I write this and the computer on which you read it.
Quite a few comments were along the lines of “Language X has a feature that does exactly that” and “Library Y in language X does exactly that.” Obviously, if you have a language that provides a simpler solution to the best you can do in C++, with acceptable performance, portability, and tool-chain constraints for what you want to do, use it. However, no language and library is perfect for everything and everybody.
I present examples of general problems and general techniques. Matching a single example in some way is not necessarily significant. My points are general and the examples only simple illustrations. Given a sufficiently good library, just about any programming task can be simple and pleasant. Given a sufficiently constrained task, we can always design a specialized language to be more elegant than a general-purpose one. For example, the asio library I used in §6.1 is a flexible, efficient, general-purpose networking library. For any one task, I could wrap it in a far simpler function (or small set of functions) to make that task significantly more convenient. The code I showed would then be the implementation. My key point in §6.2 is that the C++ library development community could do many programmers a favor by spending a little more tome making simple things simple. For example 99% of the time I prefer
sort(v)tosort(v.begin(),v.end()).Performance
My comments about performance caused quite a stir in places. Many people tried to dismiss them with arguments or mere counter-assertions. I don’t accept performance arguments unsupported by measurements. My comments have been validated by real performance measures in many contexts over years. Many can be found in the literature. My main performance points hold over a wide range of similar examples and scale.
Please note that I assume a modern, standards-conforming C++ implementation. For example, when I talk about the performance of the short-string optimization, I don’t mean a pre-C++11 standard library without that optimization. Also, I take no notice of comments to the effect that C++ facilities such as
std::sort()orstd::stringare slow if you don’t use an optimizer – of course they are, but talking about performance of unoptimized code is silly. If you use GCC or Clang use –O2; for Microsoft, use release mode.C
I know C and its standard library pretty well. I wrote considerable amounts of C before many of today’s students were even born and contributed significantly to the C language: function prototypes,
const,inline, declarations infor-statement, declarations as statements, and more came from my work. I have followed its development and the evolution programming styles in C.Yes, the C versions of
compose()fails to checkmalloc()’s return value. I did ask if you thought I got it right. I did not present production-quality code, and I knew that. Failing to check results is a major source of errors, so my “mistake” failing to check the result ofmalloc()was deliberate illustrates a real problem. As in this case, exceptions can often help.Yes, you could write the C version of
compose()differently using less well known standard-library functions, and yes, you can avoid the use of free store if you let the caller supply a buffer allocated on the stack and let the caller deal with the problem of string arguments that would overflow the buffer. However, such alternatives completely miss the point: it is harder to write such code than the C++ version, and far harder to get it right. Novices get the C++ version right the first time, but not any of the C versions, especially not the C versions that rely on standard-library function not commonly taught to novices.C++ use
C++ has been used for demanding embedded systems and critical systems for years, examples are The Mars Rovers (scene analysis and autonomous operations), The F-35s and F-16s (flight controls), and many, many more: http://www.stroustrup.com/applications.html. And, yes, the Orion space capsule is programmed in C++.
Libraries
Yes, libraries vary in quality and it can be extremely hard to choose from the large selection of libraries beyond the standard. This is a major problem. However, such libraries exist and researching them is often more productive than simply barging ahead and reinventing yet-another wheel.
Unfortunately, C++ Libraries are often not designed for interoperability with other libraries.
Unfortunately, there is not a single place to go to look for C++ Libraries.
Teaching
I have observed students being taught by the “C first” approach for many years and seen the programs written by such students for decades. I have taught C++ as the first programming language to thousands of students over several years. My claims about the teachability of C++ are based on significant experience, rather than introspection.
C++ is easier to teach to beginners than C because of a better type system and more notational support. There are also fewer tricks and workarounds to learn. Just imagine how you would teach the styles of programming you use in C using C++; C++’s support for those is better.
I would never dream of giving a beginner’s C++ course that
- didn’t include a thorough grounding in memory management, pointers, etc.
- didn’t give the students a look at “plain C”’ and some idea of how to use it
- didn’t present a rationale for the major features
- tried to teach all of C++ and every C++ technique
Similarly, good C teachers do not try to teach all of C and all C techniques to beginners.
http://www.stroustrup.com/programming.html is my answer to the question “How would you teach C++ to beginners?” It works.
For a rather old paper comparing aspects of teachability of C and C++, see B. Stroustrup: Learning Standard C++ as a New Language. C/C++ Users Journal. pp 43-54. May 1999 (www.stroustrup.com/papers.html). Today, I could write the C version a bit better and the C++ version quite a bit better. The examples reflect common styles of the time (and were reviewed by expert C and C++ programmers).
C++ today is ISO Standard C++14, rather than what I described 30 years ago or what your teacher may have taught you 20 years ago. Learn C++11/C++14 as supported by current mainstream compilers and get used to it. It is a far better tool than earlier versions of C++. Similarly, C today is ISO Standard C11, rather than K&R C (though I am not sure if the C compilers today are as close to C11 as the C++ compilers are close to C++14).
I am appalled by much that is taught as “good C++.”
C++ is not (and never were meant to be) an “OOP” language. It is a language that supports OOP, other programming techniques, and combinations of such techniques.
If you are an experienced programmer, I recommend A Tour of C++ [12] as a quick overview of modern C++.
By Mark | Dec 24, 2014 08:38 AM | Tags: intermediate
From the Modern Maintainable Code Blog:
A corollary on overloading
by Mark Isaacson
Summary from the article:
1) You can extend or adapt other people's code with overloading.
2) It's easy to accidentally eliminate overloads from overload resolution (the set of overloads the compiler considers when calling a function), especially when doing the above. We'll discuss a simple technique to ensure that you don't leave your users in an unfortunate position by accidentally being too specific.
We'll also discuss a few other things along the way, like one reason why non-member functions are more flexible than member functions. We'll highlight why the modern C++11 guideline: 'prefer using the non-member std::begin, std::end, and std::swap functions' exists and why things like non-member std::size are in our near future.