At GoingNative in February, I emphasized the need for more modern and portable C++ libraries, including for things like RESTful web/cloud services, HTTP, JSON, and more. The goal is to find or develop modern C++ libraries that leverage C++11 features, and then submit the best for standardization.
Microsoft wants to do its part, and here’s a step in that direction.
Today I’m pleased to see Soma’s post about “C++, Cloud Services, and You” announcing the DevLabs release of Casablanca, a set of C++ libraries for Visual C++ users that start to bring the same modern conveniences already enjoyed by .NET and Node.js and Erlang users also to C++ developers on our local and cloud platforms, including modern C++ libraries for REST, HTTP, and JSON. From Soma’s announcement, adding my own emphasis and minor code edits:
Historically, we’ve lacked such simple tools for developers using C++. While there are multiple relevant native networking APIs (e.g. WinINet, WinHTTP, IXMLHttpRequest2, HTTP Server API), these are not optimized from a productivity perspective for consuming and implementing RESTful cloud services using modern C++. They don’t compose particularly well with code based on the standard C++ libraries, and they don’t take advantage of modern C++ language features and practices in their programming models.
This is where “Casablanca” comes in. “Casablanca” is a set of libraries for C++ developers, taking advantage of some recent standard language features already available through Visual Studio.
“Casablanca” aims to make it significantly easier for C++ coders to consume and implement RESTful services. It builds on lessons from .NET, from Node.js, from Erlang, and from other influencers to create a modern model that is meant to be easy to program while still being scalable, composable, and flexible.
As an example, here’s a snippet that uses the client HTTP library to search Bing for my name and output the results to the console:
http_client bing( L"http://www.bing.com/search" ); bing.request( methods::GET, L"?q=S.Somasegar" ) .then( []( http_response response ) { cout << "HTML SOURCE:" << endl << response.to_string() << endl; }) .wait();and here’s a simple web listener hosted in a console application:
listener::create( argv[1], []( http_request req ) { req.reply( status_codes::OK, "Namaste!" ); }) .listen( []{ fgetc( stdin ); } ) .wait();For those of you looking to build Azure services in C++, “Casablanca” comes with a Visual Studio wizard to set up everything up correctly. You can target both Web and Worker roles, and you can access Azure storage using the built-in C++ library bindings. […] Taking C++ to the cloud with “Casablanca” is another exciting step in that journey.
Today’s Casablanca release is as a DevLabs project, to get usability feedback and to eventually support these features in the full Visual C++ product. If you’re interested in using C++ to consume and implement cloud services, and sharing what kind of support you want and whether you think Casablanca is on the right track, please let us know in the forums.
Looking beyond Visual C++, one piece of Casablanca is already being proposed for standardization, namely the “future.then” nonblocking continuations that are required to be able to write highly responsive composable libraries – you really want all async libraries to talk about their work using the same type, and std::future already gives half of what we need (blocking synchronization) and just needs the non-blocking part too. Also being proposed as an optional layer on top of “future.then” is an “await” style of language support to make the async operations as easy to express and use in C++ as in any of the best languages in the world.
Note that there are other C++ libraries too for several of these facilities. Repeating what I said at GoingNative, we (Microsoft) don’t care whose libraries get standardized – whether ones we contribute or someone else’s. We care most that there be standard C++ libraries for these modern uses, starting with the most basic “future.then” support, and to encourage all companies and groups who have libraries in these important spaces to contribute them and take the best and make them available to C++ developers on all platforms. This is a small step in that process.
Sutter’s Mill 
@Glen. I see your point and agree that initially the lambda chaining and call back styles are hard to parse. However, I suspect that is largely because they are different. If one were to come to }); from scratch, with no pre-existing expectation, one would not need to get used to it. As someone who programs in very many languages all the time – I find there is a lot of benefit in learning to parse new and different constructs and embrace the cognitive challenge that involves.
@alexander turner. I for one, definitely find this call chaining style very hard to read. I am 100% certain we need an improved syntax to make this call back style more accessible and natural. I think this is an issue separate from concurrency but would benefit both areas.
@Herb, is the committee open to syntax changes to C++ Next to make the callback process nicer?
As much as I like the lamda capture mechanism and don’t wish to be critical there, the whole f( [] ( X& a ) { called_back_with( a ); } ); syntax hurts and makes for inside out code. I don’t think I’ll ever get used to the } ); syntax even, let alone the inside out coding pattern it seems to induce.
I’d love to see more ideas to improve this.
Thanks
Good things. Now if it got SOAP and HTTPS support I would have much use for it. (gSoap, and most other C++ alternatives, makes my eyes bleed)
The restful web-service stuff looks interesting. However, the call chaining is much more significant.It will be interesting to see how the C++ community warms to this style of programming. In my view it is a very powerful technique indeed with implications far beyond futures. In general – call chaining makes it possible to write non imperative code without excessive boiler plate. http://nerds-central.blogspot.com/2011/12/is-curry-saviour-of-java.html in the Java community it is starting to take hold but is still resisted by may people who say the style is hard to read.
@Jeffrey: fair enough, especially when worded that way.
On the other hand, I love python dearly. Not for the language, but for the library they have given me.
I welcome many more additions to the C++ standard library for useful programming tasks, though yes, I do think there is a line at some point.
Another option that Herb alluded to was to create a new de-facto standard library that has faster turnaround times for updates (much like boost), though I don’t think boost was mentioned as a potential target (for whatever reason). I don’t want to put words in Herb’s mouth, so please clarify if I misunderstood.
I’m a bit confused as to what’s being hopefully-standardized. I see that the futures stuff might be a worthwhile addition to the standard library, but a “RESTful services library” seems fit for Boost instead.
I don’t want the C++ standard library to turn into the Java standard library kudzu, where 25% is solely for XML processing.
Herb,
It looks like the C++ teams over at Microsoft are creating some serious product demand here :)
Good job, thumbs up! (but also: give us the code please.)
Re whether this will be open source: See http://social.msdn.microsoft.com/Forums/en-US/casablanca/thread/82f5d4a2-91a6-4abc-8509-5bb48a277ab7 . Short answer: That’s the intent, though for this very early to-get-feedback drop it’s more platform-specific.
Curious to know/hear how OS independent (from OS as well as open source) this would be. Completely agree on the fact that such is needed and certainly standardization would be nice, but can someone on Linux leverage it?
Will this SDK be released as source + headers too (next to the MSI package) at some point so I can play around with this on Mac OS X with Clang?
yes, yes, YES!
Herb, I have been waiting patiently since GoingNative to see some steps towards the dream of having a more “batteries included” C++ standard[-esque] library.
I’ve recently been teaching C++ to my younger brother, and this experience has opened my eyes to how the language feels to a novice. Yes, some of the syntax is rough to grasp (why do you need a semicolon after a class?), but it was the standard library that proved the real problem. It is both difficult and extremely limiting when trying to just “hack up something fun” while incrementally learning the language.
Access to GUI/canvas proved impractical (we are using different compilers/os). Networking was difficult (and more c than c++). Keyboard/mouse event handling.. we just gave up.
Unless we were doing academic exercises like writing algorithms already in the standard library, nearly all of our practical time was spent in c++/system dependent drudgery instead of building, and left a foul taste in his mouth, and frankly a bit of shame in mine.
Sure: use the right tool for the job — maybe hoping for easy access to a ui canvas was a bit optimistic — but networking? This should be c++ bread and butter.
I am going to give this new library a shot, and while I don’t usually use visual studio, this gives me some good motivation (does microsoft release these libraries under some kind of permissive license that may allow for porting?).
Thanks, and looking forward to more!
Excellent addition to the toolset along with WWS. Bookmarking it now.