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.
Unrelated: Where is this "unsignedchar" keyword coming from?
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.
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?"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...
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.
So do this call, and then when its finsihed do this.
I like it.
You should look at it, it makes C++ feel a new language.
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).
http://cpp-netlib.org/0.9.4/index.html
https://code.google.com/p/rapidjson/
I have no recommendations for writing REST services, however.
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.
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.