Hacker News Reader

The unicode portion looks reasonable, but why is it necessary for it to include its own flags, file io, file management, and environment classes?

Why is it so many C++ libraries fall into this habit of trying to build one big framework. I'm perfectly happy with gflags -- a unicode library would be nice for my project, but now I won't consider this library.

View on HN

Because the whole point is to handle anything that needs Unicode support. A library that only manipulated Unicode strings would be incomplete if you still couldn't use Unicode in command line options, file names, etc.

I would recommend breaking them off into separate additional libraries. I don't need unicode for flags, so paying for it at compile and link time seems unwise. Or provide adapter classes that can be used over other frameworks. Just a suggestion.

That's what will happen until there's a defacto/standard library for this stuff. Languages like Python and Go have a wider base in the standard library. C++14 still only gives you platform dependent 'wide' strings, UTF-8 string literals, and UTF-8 conversion... which makes things awkward.

Reply on news.ycombinator.com