Microsoft releases C++ REST SDK ("Casablanca")

From the announcement:

The C++ REST SDK (codename "Casablanca") has officially been released as an open source project on CodePlex...

We first announced Casablanca as an incubation project on Microsoft's DevLabs back in April of 2012. Since then we have had several releases and have seen library quickly evolve. As we added new features and received feedback from customers, it was evident that two separate entities were beginning to form. As a result, the "Casablanca" project on DevLabs has been separated into 2 different SDKs: the C++ REST SDK and the Azure SDK for C++.

The first of the two SDKs being released is the C++ REST SDK. It includes tools to quickly write modern, asynchronous C++ code that connects with REST services. We take advantage of the power and productivity offered in C++11 while providing a cross-platform solution. We currently support Windows 7, Windows 8 (Windows store and desktop applications), and Linux.

The main features in this SDK include:

  • Ability to create a connection to a server via a HTTP Client, send requests and handle response.
  • Support for construction and use of Uniform Resource Identifiers (URI).
  • Constructing, parsing and serializing JSON values.
  • Asynchronously reading/writing bytes to/from an underlying medium via Streams and Stream Buffers.

Continue reading...

No, really, moving a return value is easy -- StackOverflow

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.

last.fm releases moost -- a Boost-like library for music

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

Continue reading...

Concepts Lite: Constraining Templates with Predicates -- Andrew Sutton, Bjarne Stroustrup

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:

New forum active: SG8 (Concepts)

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:

 

Quick Q: When should I use std::function vs. make my function a template? -- StackOverflow

To accept a functor as a parameter, when should you:

  • accept a std::function, which adds an indirection, vs.
  • make your function a 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] that functions can be used as de facto standard of passing functors, and in places where high performance is expected templates should be used?

Quick Q: How do I move an expensive object into a map? -- StackOverflow

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});

Quick Q: Is the safe-bool idiom obsolete in C++11? -- StackOverflow

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.