“Effective Modern C++” from Scott Meyers Review -- CoderGears Team

By Blog Staff | Nov 27, 2014 03:54 PM | Tags: None

Today on CoderGrears:

“Effective Modern C++” from Scott Meyers Review

by CoderGears Team

From the article:

This month a new book from Scott Meyers become available, it’s the last one of its Effective software development series (More Effective C++, Effective STL   and Effective C++ ) .

In this book Scott Meyers focus on the new C++11 and C++14 standrads, currently few books talk about them. In the other side many resources are available on the web discussing these new standards. Why I need to read this book?

Here’s our feedback...

The Python API and C++ -- Scott Prager

By Blog Staff | Nov 27, 2014 03:49 PM | Tags: None

Some interspecies dating, appropriately on the "multi-paradigm" blog:

The Python API and C++

by Scott Prager

From the article:

Recently, for a job interview task, I was asked to write a Python module with a C or C++ implementation to solve an otherwise simple task. Obviously, I chose C++. While I had never used the Python API before, I found that the existing information on extending Python with C quite sufficient. What surprised me, however, is how little information existed for using C++. A few libraries exist, like Boost.Python, PyCXX, and some utilities that parse C++ to create Python bindings, but I didn't find much in the way of actual information without examining the sources of these libraries. ...

... I have started working on a little utility library (https://github.com/splinterofchaos/py-cxx) for personal use... [The Python C API has] many restrictions and it certainly puts a cramp on C++'s style, but the moral of this store is that just because you need to work with a C API doesn't mean you can't use modern C++ techniques.

Building Portable Games in C++ -- Guy Kogus

By Blog Staff | Nov 26, 2014 01:50 PM | Tags: None

Fresh on Dr. Dobb's:

Building Portable Games in C++

By Guy Kogus

The cocos-2d-x open source framework can be used to build games, apps, and other interactive software in C++. Here's a hands-on guide to using it to write and port games.

From the article:

Our game, Ready Steady Bang, was written using cocos2d-iphone, which we were considering using for our next game, Ready Steady Play. Then I remembered the C++ gaming framework cocos2d-x and its promise of cross-platform compilation.

In this article, I break down how I developed the Ready Steady Play game using cocos2d-x and discuss the porting travails of moving the final code from iOS to Android and Windows Phone 8. I used v2.2.x of cocos-2dx, but most of this text should be applicable for v3.x...

Container Algorithms -- Eric Niebler

By Blog Staff | Nov 25, 2014 07:24 AM | Tags: None

Some more details about the Ranges proposal that was well received by the ISO C++ committee at this month's meeting in Urbana-Champaign:

Container Algorithms

by Eric Niebler

From the article:

... So to sum up, in the world of N4128, we have this:

• Eager algorithms that can mutate but that don’t compose.
• Lazy algorithms that can’t mutate but do compose.

Whoops! Something is missing. If I want to read a bunch of ints, sort them, and make them unique, here’s what that would look like in N4128:

extern std::vector<int> read_ints();
std::vector<int> ints = read_ints();
std::sort(ints);
auto i = std::unique(ints);
ints.erase(i, ints.end());

Blech! A few people noticed this shortcoming of my proposal. A week before the meeting, I was seriously worried that this issue would derail the whole effort. I needed a solution, and quick.

Container Algorithms

The solution I presented in Urbana is container algorithms. These are composable algorithms that operate eagerly on container-like things, mutating them in-place, then forwarding them on for further processing. For instance, the read+sort+unique example looks like this with container algorithms:

std::vector<int> ints =
    read_ints() | cont::sort | cont::unique;

Much nicer. Since the container algorithm executes eagerly, it can take a vector and return a vector. The range views can’t do that...

Updates to my trip report

By H Sutter | Nov 24, 2014 10:49 AM | Tags: None

I wanted to add a few more things to my meeting trip report. I updated the trip report in-place, but for those who want to see the "diffs" I'll also post just the new parts here as a standalone post:

There were 106 experts at this meeting, officially representing 7 nations. This meeting saw a recent-record number of papers, including over 120 in the pre-meeting mailing.

In addition to the other things I mentioned, we also approved several other interesting changes, including the following highlights:

• Adopted N4230, which allows nested namespace definitions like namespace A::B::C { } as a convenient shorthand for namespace A { namespace B { namespace C { } } }.
• Adopted N3922, which fixes the most common pitfall with auto and {}, so that auto x{y}; now deduces the sane and expected thing, namely the type of y. Before this, it deduced initializer_list which was unfortunate and surprising. So, fixed.
• Adopted N4086, which removes trigraphs. Yes, we removed something from C++... and something that was inherited from C! But wait, there's more...
• Adopted N4190, and actually removed (not just deprecated) several archaic things from the C++ standard library, including auto_ptr, bind1st/bind2nd, ptr_fun/mem_fun/mem_fun_ref, random_shuffle, and a few more. Those are now all removed from the draft C++ 17 standard library and will not be part of future portable C++.

We also did work and made progress on a lot of other proposals, including modules. See the pre-meeting mailing for details about papers considered at this meeting.

Can Qt's moc be replaced by C++ reflection? -- Olivier Goffart

By Blog Staff | Nov 24, 2014 01:17 AM | Tags: None

In case you missed it:

Can Qt's moc be replaced by C++ reflection?

by Olivier Goffart

From the article:

The Qt toolkit has often been criticized for extending C++ and requiring a non-standard code generator (moc) to provide introspection.
Now, the C++ standardization committee is looking at how to extend C++ with introspection and reflection. As the current maintainer of Qt's moc I thought I could write a bit about the need of Qt, and even experiment a bit.

In this blog post, I will comment on the current proposal draft, and try to analyze what one would need to be able to get rid of moc.

Trip Report: Fall ISO C++ Meeting

By H Sutter | Nov 22, 2014 04:56 PM | Tags: None

[Updated 11/24 to add a few more details]

The fall ISO C++ meeting was held on November 3-8 in Urbana-Champaign, IL, USA. Many thanks again to Riverbed Technology and the University of Illinois at Urbana-Champaign for hosting us! [ETA: There were 106 experts at this meeting, officially representing 7 nations. This meeting saw a recent-record number of papers, including over 120 in the pre-meeting mailing.]

As usual, we met for six days, starting Monday morning and ending on Saturday afternoon. This week was especially action-packed, and we had working sessions around the clock continuously from 9:00am Monday until 3:00pm Saturday, with the only breaks being short lunch and dinner breaks, and roughly 10pm-8am for sleep and breakfast (though, also as usual, many paper authors whose proposals were making progress opted to spend part of their sleep time updating their papers).

This is the first meeting since C++14 was officially completed, and so this was the first “C++17 era” meeting. We adopted a number of proposals directly into the C++ working draft that will become C++17, and adopted other proposals into other Technical Specifications that are developing independently from the core standard and may be folded into the C++ standard itself in the future.

Sadly, this was the last meeting for retiring long-time U.S. committee chair Steve Clamage who has done a tireless and much-appreciated job herding the cats for the past 20 or so years. Steve is one of the five remaining original members of the ISO C++ committee who had attended the first ISO C++ organizational meeting back in 1989 and has still been attending up to this month's meeting; the others are Pete Becker, Mike Miller, Tom Plum, and Bjarne Stroustrup. Thanks again, Steve, for all your contributions to ISO C++, and happy retirement! The new chair of the U.S. committee is Clark Nelson, who has long served as vice-chair. In turn, the new vice-chair is John Spicer.

Milestones

Four major milestones were achieved that will result in issuing four ISO ballots:

• The Transactional Memory TS was approved to be sent out for its primary comment ballot, known as PDTS ballot. This is the first of two ballot stages for a TS.
• The Parallelism TS was approved to be sent out for its final ballot, known as DTS ballot.
• The Library Fundamentals TS was approved to be sent out for its final DTS ballot.
• Also, in what amounts to a ribbon-cutting ceremony, I was also directed to officially request a New Work Item for the next C++ standard itself, which is expected to be C++17.

We adopted a number of proposals, which are covered in the following isocpp.org posts:

• New core language papers adopted for C++17 (highlights: extended constant evaluation, folding expressions, uncaught_exceptions, forwarding references, u8 character literals)
• New standard library papers adopted for C++17 (highlight: support for contiguous iterators)
• N4275, N4276: New papers adopted for Parallelism TS (highlight: transform reduce algorithm)
• N4270, N4288: New papers adopted for Library Fundamentals TS
• N4257, N4273, N4282: New papers adopted for Library Fundamentals 2 TS (highlights: delimited iterators, uniform container erasure (a.k.a. removing the remove-erase idiom), and the world’s dumbest smart pointer)
• N4265, N4272: Transactional Memory TS wording—Michael Wong, Jens Maurer, et al.

[ETA: We also approved several other interesting changes, including the following highlights:

• Adopted N4230, which allows nested namespace definitions like namespace A::B::C { } as a convenient shorthand for namespace A { namespace B { namespace C { } } }.
• Adopted N3922, which fixes the most common pitfall with auto and {}, so that auto x{y}; now deduces the sane and expected thing, namely the type of y. Before this, it deduced initializer_list which was unfortunate and surprising. So, fixed.
• Adopted N4086, which removes trigraphs. Yes, we removed something from C++... and something that was inherited from C! But wait, there's more...
• Adopted N4190, and actually removed (not just deprecated) several archaic things from the C++ standard library, including auto_ptr, bind1st/bind2nd, ptr_fun/mem_fun/mem_fun_ref, random_shuffle, and a few more. Those are now all removed from the draft C++17 standard library and will not be part of future portable C++.

We also did work and made progress on a lot of other proposals, including modules. See the pre-meeting mailing for details about papers considered at this meeting.]

Happily, at least for me, two of my own proposals were adopted at this meeting.

First, Andrei Alexandrescu inspired me to write and pursue what became adopted via paper N4259, to add the new function int std::uncaught_exceptions() noexcept; to the standard library that returns the number of active exceptions in this thread. This will enable a portable ScopeGuard that can automatically detect success/failure without asking the user to write a manual .Dismiss() or forcing the ScopeGuard implementation to rely on undocumented compiler artifacts (which, ahem, Andrei’s implementation had been doing on GCC, Clang, and MSVC – figuring out where the compilers were already storing this very exception count information and doing the world’s most contorted reinterpret_cast<int*>s to get access to the count. I expect C++ implementations to implement this aggressively – in fact, I believe it was implemented for either libc++ or libstdc++ two days later. Finally, while they were at it, the committee also decided to deprecate the old std::uncaught_exception() which has long been known to be almost-but-not-quite what is wanted.

Second, Scott Meyers inspired and demonstrated the need for a name for T&& references – that is, where T is a template parameter type and the reference could “become” const or non-const, rvalue or lvalue. This is different enough that it, and more importantly its intended usage, needs a name. In the absence of a special name for this provided by the committee, Scott initially called these “universal references.” A number of experts agreed there should be a name, but that “forwarding references” was better, and Scott himself had used that term in the past. The committee agreed, and via N4262 has now added the term “forwarding reference” to the draft standard. As icing on the cake, not only is the term in normative text, but it’s promoted to a formal “term of power” that the draft standard itself now already uses in two places to replace the old longer phrase-that-really-needed-a-name. (We would have been satisfied with a non-normative note; it’s nifty that the committee itself found it useful to have a name for this thing to improve the specification of the standard itself.)

Many thanks again to Scott and Andrei for popularizing and demonstrating the need for these features and the form they could take in the standard.

I also presented my atomic smart pointers proposal, for atomic versions of unique_ptr, shared_ptr, and weak_ptr. These were accepted by the Concurrency subgroup (SG1), approved by the Library Evolution Group, and received initial wording review in the core Library Working Group. Hopefully this paper, or a minor update, will be ready to be adopted into the Concurrency TS at our next meeting in May.

Finally, I had proposed allowing a return statement to be allowed to call explicit constructors, and at our summer meeting in Rapperswil the Evolution Working Group agreed with allowing the syntax “return { /* whatever */ };” to invoke explicit constructors, and I got to final wording in the Core Working Group which is the last stage before it is brought before the full committee for approval. However, because this proved to be controversial in the larger group, I voluntarily withdrew the proposal – at least for the time being, and I don’t currently plan to bring it forward again.

Evening sessions

We had five evening sessions on specific topics of broad interest. Most were attended by a majority of the full committee.

On Monday evening, most of the committee spent three hours on coroutines and fibers. There were three major concurrency proposals related to smaller-than-thread concurrency such as resumable functions. At the end, the group expressed a strong direction to pursue coroutines and fibers (as strawman names) as distinct concurrency primitives, in addition to threads. Broadly, the key distinction is that a fiber enables cooperative scheduling of multiple stacks within a thread – that is, a fiber is a unit of work smaller than a thread but with its own stack, and that can be assigned to run on a thread; whereas a coroutine is an ultra-lightweight unit of work that is smaller still and does not have its own stack.

On Tuesday evening, we spent another three hours on contracts – preconditions, postconditions, and invariants. The group gave some direction on preferred directions and we expect to see updated proposal(s) for our next meeting.

On Wednesday evening, we spent two hours on ranges. Eric Niebler presented a design and prototype implementation for ranges and range-based algorithms, expressed using fully modern C++14 plus the Concepts TS language features, although it could be implemented without language support for Concepts. There was extensive Q&A and palpable excitement and a unianimous vote to encourage the author to return with proposed standardese wording that could be wordsmithed and hopefully adopted at a future meeting.

Thursday evening was devoted to pattern matching. This flexible set of facilities could provide a general framework that would subsume a number of other proposals, ranging from a more flexible form of the ordinary switch statement, possibly all the way to the “static if” style proposals.

Friday evening was devoted to reflection proposals, focusing on compile-time reflection facilities for C++. I left at 9:30, but later heard that the session continued nearly another two hours afterwards.

Next meetings

Our next full WG21 face-to-face meeting will be on May 4 to 9 in Lenexa, Kansas, USA.

In the meantime, over the winter we’ll be having several other smaller face-to-face and telecon meetings on specific topics.

• The Concepts specification working paper will continue to be reviewed in two telecons in December and January, with a three-day face-to-face meeting on January 26-28 in Skillman, New Jersey, USA, at which we hope to approve the document to be sent out for its main comment ballot (PDTS). This meeting is being hosted by Bloomberg and Edison Design Group.
• The Library groups will be holding a full-week face-to-face meeting on February 23-27 in Cologne, Germany to work specifically on the issues lists for the existing standard library at a meeting that is not also considering new features; think of it as a “bug bash” meeting. This meeting is being hosted by Josuttis Eckstein and ParStream.

Many thanks especially to the meeting hosts for graciously volunteering to organize these meetings!

C++14 for Qt programmers -- Olivier Goffart

By Blog Staff | Nov 21, 2014 09:12 AM | Tags: None

For those who know how to pronounce Qt, note that this title is not intended as a beauty judgment:

C++14 for Qt programmers

by Olivier Goffart

From the article:

C++14 is the name of the version of the standard to be released this year. While C++11 has brought many more feature that took time to be implemented by the compilers, C++14 is a much lighter change that is already implemented by compilers such as clang or gcc.

Qt 5 already was adapted in many ways so you can make use of the new features of C++11. You can read about that in my previous article. C++11 in Qt5. This article mention some of the changes in C++14 and the impact on Qt users...

Quick Q: Is it idiomatic to make X objects immutable by making all X member data const? -- SO

By Blog Staff | Nov 21, 2014 04:31 AM | Tags: None

Quick A: Yes.

Recently on SO:

Idiomatic way to declare C++ immutable classes

So I have some pretty extensive functional code where the main data type is immutable structs/classes. The way I have been declaring immutability is "practically immutable" by making member variables and any methods const.

struct RockSolid {
   const float x;
   const float y;
   float MakeHarderConcrete() const { return x + y; }
}

Is this actually the way "we should do it" in C++? Or is there a better way?

Quick Q: Which is more efficient, push_back(move(var)) or emplace_back(var)? -- StackOverflow

By Blog Staff | Nov 20, 2014 04:25 AM | Tags: None

Quick A: 1. Those cases are not equivalent. 2. Emplace is more for when you don't already have a named object of the correct type...

Recently on SO:

Efficiency of C++11 push_back() with std::move versus emplace_back() for already constructed objects

In C++11 emplace_back() is generally preferred (in terms of efficiency) to push_back() as it allows in-place construction, but is this still the case when using push_back(std::move()) with an already-constructed object?

For instance, is emplace_back() still preferred in cases like the following?

std::string mystring("hello world");
std::vector<std::string> myvector;

myvector.emplace_back(mystring);
myvector.push_back(std::move(mystring));
// (of course assuming we don't care about using the value of mystring after)

Additionally, is there any benefit in the above example to instead doing:

myvector.emplace_back(std::move(mystring));

or is the move here entirely redundant, or has no effect?