Targeting Android with the C++ REST SDK -- Steven Gates

Fresh on vcblog:

Targeting Android with the C++ REST SDK

by Steven Gates

From the article:

Right before the holidays we put together a new release, version 2.4.0, of the C++ REST SDK. One of the new features added in the library is support for targeting Android using the Visual Studio 2015 cross platform mobile development, as well as the x86 Android emulator. In this post I’m going to walk through showing how to create an Android Native Activity that utilizes the C++ REST SDK...

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

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!

JSON for Modern C++ -- Niels Lohmann

A new GitHub project With a very readable README:

JSON for Modern C++

by Niels Lohmann

From the README:

... You can create an object (deserialization) by appending _json to a string literal:

// create object from string literal
json j = "{ \"pi\": 3.141, \"happy\": true }"_json;

[Note: Or perhaps auto j = R"({ "pi": 3.141, "happy": true })"_json; --Ed.]

You can also get a string representation (serialize):

// explicit conversion to string
std::string s = j.to_string();

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

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

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

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

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

Monads in Chains - Ivan Cukic @meetingcpp 2014

Ivan Cukic gave a very good talk on monads at Meeting C++ 2014:

Monads in Chains

by Ivan Cukic

From the talk description:

Monads are scary, and monads are evil. But they are still useful.

In the recent years, the abuse of multi-threading has become apparent and more and more systems started being developed in the reactive, or event-processing style. It allows lowering the number of threads to match the system cores instead of items that are being processed by using non-blocking asynchronous APIs.

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

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

 

EDG C++ front end 4.10 released, adds more C++14 support

Announced today, just in time for the new year:

EDG C++ front end 4.10 released

Version 4.10 of the EDG C++ Front End has been released.

This version provides the following new features:

1) This version provides the following new C++14 features:

Lambdas can specify expressions, not just local variables, to be captured. For example:

       auto l = [x = 42]{ return x + 1; };

Generic lambdas are accepted, allowing auto parameters to define a call operator template.  For example:

        auto l = [](auto p) { return p*2; };

Binary literals and apostrophes as digit separators in numeric literals are accepted.

        int i = 0b0110;
        long l = 123'456'789; // Equivalent to 123456789

2) __cpluplus in C++14 modes:

The standard for C++14 has now been approved and specifies the value of the __cplusplus predefined macro as 201402L.  The front end uses that value when --c++14 mode is specified, except that in Microsoft and GNU    modes it adopts the value set by those compilers.  See the Changes file for more details.

3) GNU statement expressions with class type results:

Version 4.9 of the front end enabled the ability to have destructible entities in GNU statement expressions (GSEs), but with the restriction that the result expression of a GSE cannot be of a class type requiring nontrivial copy construction or nontrivial destruction.  This restriction has been removed.  For example:

     struct D { D(D const&); };
     D g(D d) {
       return ({ d; });  // Now accepted.
    }

4) Performance improvements:

As part of what will be an ongoing effort, a number of changes were made to improve the overall speed of the front end.  This has generally resulted in an improvement between 1 and 6 percent in our testing, but can be significantly more for some IA-64 mangling cases.

As usual, we have fixed bugs, added many minor features, and continued to improve our various compatibility modes.