Microsoft open sources C++ REST SDK "Casablanca" | Hacker News Reader

Microsoft open sources C++ REST SDK "Casablanca"

blogs.msdn.com

47 pointsRooki44 comments

Disappointed to see the continued use of wide strings in new projects.

As long as the Win32 API continues to not support UTF-8, using wide strings will remain the least bad option on Windows.

I don't know what you're talking about, Win32 supports UTF-8. I can pass CP_UTF8 into WideCharToMultiByte() just fine. :-)

Kidding aside, I don't really see the issue. Do you get upset about in-memory representation of strings often? How about when using Java or Python? Is this not why there is an entire programming practice called "serialization"? Windows started supporting UCS-2 before UTF-8 existed, and so the internal representation on Windows remains 16 bits per char.

Python supports full Unicode on all platforms now (x). Who cares about in-memory representation as long as the user doesn't have to suffer from surrogates and all that horror.

(x) pre-PEP393 there was a build option to use the limited 16-bit Unicode, was unfortunately popular on Windows

Hm. I picked Python because I knew it was an outlier, but I don't know all the details. Does Python still suffer from the horrors of comparison between diacritics made up of combining characters and the same glyph as a pre-composed character? Seems like even if you expose strings as UTF-32 you'd still have that issue.

Afaik the combining character problem hasn't changed, you still have to use unicodedata.normalize() for that. But at least you can pass through Unicode strings cleanly.

Are there other languages that handle this better?

It's not really clear to me what "handle better" would be, which is why I asked if Python did anything, as your post suggested it hides some ugliness of Unicode (a claim like this I am always skeptical of, although reading PEP393 it seems kind of clever in that "why don't more libraries do this" kind of way).

I suppose one form of "handle better" would be to always normalize all the time, but then, there are those times when you want payload to be bit-identical after a round-trip. I suspect it's just rooted in Unicode sucking (even if it sucks less than the encodings it replaced); it's funny how Unicode is supposed to make things simpler, but carries its own baggage and complexity and nonsense to worry about. Every time I read about these details in Unicode it seems to suck more than I remembered the last time.

Other than the great UCS-2 cockup most of the issues with Unicode are either due to that human languages are a pain or are unpleasant backwards compatiblity things. Only having the fully normalized forms would make things designed around Unicode a lot simpler, but the denormalized forms let things not designed for Unicode mostly work, which was key for getting people to actually use Unicode.

Oh, I totally understand the reasons. Doesn't mean it still doesn't suck. It's one of those "sucks less" type of scenarios.

The same problem occurs in Ruby, at least when dealing with the Mac OS X file system (which uses decomposed strings internally), you may receive NFC or NFD and don't know which you're getting.

But this isn't using the Win32 API. At least not directly, and certainly not on Linux.

Unrelated: Where is this "unsignedchar" keyword coming from?

It does use both the Win32 API and WinRT (which also wants wide strings) directly. It appears to use narrow strings on Linux.

The "unsignedchar" appears to be a bug in the syntax highlighter. It was parsed as two tokens, so either it's insane enough to split tokens or it dropped the space.

By "this" I meant the example code.

On the whole I hate to nitpick, it looks like a darn good piece of work.

Windows chooses to use UTF-16 rather than UTF-8, but is it really that much of a concern?

It makes writing portable code a pain; either you have to use different string types on different platforms or do a bunch of converting between utf-8 and utf-16. Many libraries support only narrow strings, so even in a Windows-only application you often end up having to convert between utf-8 and utf-16 quite a bit.

Has Microsoft given any indication of planning to abandon two byte strings in their future Windows C/C++ frameworks? That design seems pretty baked into their platform at this point, and would be presumably hard to change.

You can't abandon them if you want to have fast code.

It is possible to write code in a portable fashion, accepting utf-8 as a standard string encoding, but this will then require converting to/from utf-16 for virtually every Windows API call that takes in a string variable. Not hard to do (MultiByteToWideChar), but there's a non-negligible performance penalty.

Completely off topic, but was anyone as disoriented as I was to realize they were browsing an Apache-licensed git archive on a Microsoft site? It wasn't even awful (not github, or really even gitorious, but not bad).

Microsoft has been supporting git on Codeplex (their Open Source hosting site) for a while and they announced git integration in Visual Studio last month.

I don't know what license they tend to use for Open Source stuff but Apache is a good choice (we don't need yet another license).

Microsoft has already given the world the "Microsoft Public License" and "Microsoft Reciprocal License".

Sure, and I knew all that (or at least remembered hearing about it). But there's a big difference between the abstract knowledge that MS isn't completely hostile to open source and actually finding yourself browsing source code on their site. I'm a crufty old cynic, but I was still shocked.

I really like that they used the new C++11 features like lambdas etc. Will download and dig through the source code, seems to be one of the first OS projects by a major company which feature C++11.

From what I understand this is a REST client library for making HTTP requests and dealing with JSON. Can anyone recommend a good C++ framework for writing REST services and simple HTTP servers.

For HTTP clients and servers, I've not had too much trouble with cpp-netlib. It's heavily boost-based, and it uses Boost::Asio for concurrency and SSL handling, but if you're familiar with Boost, you can be up and running in no time. IIRC, this library is considered for official inclusion to Boost as well. I use cpp-netlib + RapidJSON for my REST API handling needs.

http://cpp-netlib.org/0.9.4/index.html

https://code.google.com/p/rapidjson/

I have no recommendations for writing REST services, however.

Looking at the source, it looks like this lib uses boost:asio on non windows platforms.

What are some good web frameworks in C/C++ to implement REST API?

I currently use Fastcgi++ and manage the headers and JSON with some custom libraries. The resulting application just runs through any FastCGI compatible web server.

It's good to see the code using K&R naming convention (sans the class names starting with _).

On the other hand, it's written in a C++ dialect that's incompatible with the one we are using. It also has quite a few unnecessary tie-ins into the native API and MSVC compiler specifics (#pragma endregion), so as nice of a gesture this is, it's not fit well for inclusion into other projects.

  file_stream<unsignedchar>::open_istream(L"myfile.txt").then([](basic_istream<unsignedchar> fileStream)

I don't think I've ever seen this C++ idiom before (either the ".then" method or the use of anonymous brackets like that.) Is this common everywhere or just in Windows circles?

.then() is just a method. The "anonymous brackets" is a c++11 lambda function. I don't think chaining it like that is common anywhere, yet.

The .then() method appears to be something on concurrency::task, which is part of the Microsoft's Parallel Pattern Library. This article says:

"we've started a new project called Casablanca to build a modern C++ library for cloud-based client-server communication, in which all concurrent operations are exposed as PPL tasks."

http://www.drdobbs.com/parallel/improving-futures-and-callba...

Link to Microsoft's C++ committee proposal (N3327): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n332...

I've used that style of programming in some of my hobby projects (mixed with other obvious sequencing operations like wait_until(predicate) and delay(time)) for doing timeline scripting. In my experience, it tended to become a mess when I needed things more complex than linear action sequences (e.g. conditionals, loops, etc. are better suited to a real interpreter).

As far as common uses of chaining for sequencing in C++, the only common use that comes to mind is iostreams operator <<, but that predates lambdas.

That looks like Microsoft's new "async everywhere" approach to API design. It's probably a pretty good idea in concept, but I hope they don't expect C++ developers to actually write those awful nested lambda .then() blocks for what are conceptually sequential actions.

I expect you can define named functions for your "conceptually sequential actions" if you prefer.

Sure, but is that much better? It reminds me of having to create named struct classes to simulate closures prior to C++11 lambdas. The language syntax just doesn't support that style of programming.

So how many languages actually do support this style directly?

The C# async keyword looks pretty clean, just give C++ a decade or so to catch up.

Is there a better approach available in C++? In other languages you'd use monads or other special compiler forms that can rewrite sequential looking code into the horrible multi-nested callback/error handling code it needs to be.

Boost Coroutines perhaps? http://www.boost.org/doc/libs/1_53_0/libs/coroutine/doc/html...

I think the use of then() makes sense as this is an async call and not serial. So the function passed to then() is a completion handler, i.e. it is run when the call is complete.

So do this call, and then when its finsihed do this.

I like it.

This is C++11 code.

You should look at it, it makes C++ feel a new language.

Back in the day (~4 yrs ago) there was a project called "Casablanca" at Microsoft which was supposed to be the native (C/C++) version of the Windows Communication Foundation. Is this the same "Casablanca"?

Is this Windows/VisualC++ only or is it portable?

FTA: We currently support Windows 7, Windows 8 (Windows store and desktop applications), and Linux.

From the FAQ:

Can I use Casablanca on iOS, Linux, Android, or other platforms?

The API surface of Casablanca is platform-agnostic, however in this release we are only supporting Windows and Linux. Our goal for future versions is to enable true cross-platform portability of Casablanca-based code.

Reply on news.ycombinator.com