Ask the STL Creator about Generic Programming

By Jon Kalb | Jan 8, 2015 04:14 PM | Tags: None

An online (Slashdot) interview of Alexander Stepanov and Daniel Rose, authors of "From Mathematics to Generic Programming" is now soliciting questions.

Add a reply to this Slashdot announcement to pose a questions. Ask as many questions as you'd like, but only one question per reply please:

Interview: Ask Alexander Stepanov and Daniel E. Rose a Question

An anonymous reader writes:

"Alexander Stepanov studied mathematics at Moscow State University and has been programming since 1972. His work on foundations of programming has been supported by GE, Brooklyn Polytechnic, AT&T, HP, SGI, and, since 2002, Adobe. In 1995 he received the Dr. Dobb's Journal Excellence in Programming Award for the design of the C++ Standard Template Library. Currently, he is the Senior Principal Engineer at A9.com. Daniel E. Roseis a programmer and research scientist who has held management positions at Apple, AltaVista, Xigo, Yahoo, and is the Chief Scientist for Search at A9.com. His research focuses on all aspects of search technology, ranging from low-level algorithms for index compression to human-computer interaction issues in web search. Rose led the team at Apple that created desktop search for the Macintosh. In addition to working together, the pair have recently written a book, From Mathematics to Generic Programming. Alexander and Daniel have agreed to answer any questions you may have about their book, their work, or programming in general. As usual, ask as many as you'd like, but please, one per post."

Quick Q: Why does trying to use a std::move'd object try to copy? -- StackOverflow

By Blog Staff | Jan 7, 2015 06:08 PM | Tags: None

Quick A: Think of move is (mostly) an optimization of copy, and copy as the "slow" fallback when you can't actually move.

Fresh on SO:

Why does calling std::move on a const object call the copy constructor when passed to another object?

Specifically, the code

#include <iostream>

struct Foo {
    Foo() = default;
    Foo(Foo && x) { std::cout << "Move" << std::endl; }
    Foo(Foo const & x) = delete;
};

int main() {
    Foo const x; Foo y(std::move(x));
}

fails to compile with the message:

g++ -std=c++14 test07.cpp -o test07
test07.cpp: In function 'int main()':
test07.cpp:10:36: error: use of deleted function 'Foo::Foo(const Foo&)'
     Foo const x; Foo y(std::move(x));
                                    ^
test07.cpp:6:5: note: declared here
     Foo(Foo const & x) = delete;
     ^
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 1

Certainly, I expect it to fail because we can't move a const value. At the same time, I don't understand the route that the code takes before it tries to call the copy constructor. Meaning, I know that std::move converts the element to an x-value, but I don't know how things proceed after that with respect to const.

C++ Status at the end of 2014 -- Bartlomiej Filipek

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!

Quick Q: Why do unique_ptr and shared_ptr treat deleters differently? -- StackOverflow

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. 

C++ User Group Meetings in January

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

The Rule of The Big Four (and a half) – Move Semantics and Resource Management -- Glennan Carnie

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)”

Interlude: C++’s Strides in 2014--K-ballo

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...

How to implement classic sorting algorithms in modern C++? -- TemplateRex

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 std::sort algorithm (and its cousins std::partial_sort and std::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.

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.

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).

 

Quick Q: Can recompiling C++98 code as modern C++ get you performance for free? -- StackOverflow

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)

Two fundamental implementations for one conceptual task

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.