Inlining gives very good performance benefits.
Some people (performance freaks would disagree with you) see Linux kernel coding style.
But this is other story.
High-performance computing is my job, but whatever.
Mine too :-)
However token_iterator designed to create tokens.
Note, if token iterator was returning a range you wouldn't be able to call
std::string s = *it;
Is that a problem? Why would you want to do such a thing in the first place? You already have the data, why copy it?
Why? Because that what 99% of programmers would actually do if they want specific token.
I see, but sometimes I don't really agree that the interface you suggest simplifies things, sometimes it may but not always.
But this is my point of view.
I don't see how that kind of simplification can be subject to points or view.
Not requiring users to convert to your format is simpler than requiring them to do so, it's a fact.
If I wanted to use your library, it would be ironic if the first thing I had to do is write a wrapper around it. I thought it was a library that aimed at being a wrapper of ICU with a nice C++ interface.
It really depends on your use pattern. See a small sample when I use collation in my real application to display index of topics: // // note std::locale has // bool operator()(std::string const &,std::string const &) const // typedef std::multimap<std::string,std::string,std::locale> mapping_type; mapping_type mapping(context().locale()); cppdb::result r; cppdb::session sql(conn); r=sql<< "SELECT slug,title FROM pages WHERE lang=?" << locale_name; while(r.next()) { std::string slug,t; r >> slug >> t; mapping.insert(std::pair<std::string,std::string>(t,slug)); } How easy and simple, isn't it? How would it look like with ranges API?
You assume that "whatever" facet is stateful, and it is not it is const and stateless, unless I provide some specific state as additional parameter.
No, I assumed it was stateless.
Your sample just took some two generic template pointers that can't be passed to virtual functions that know anything about them unless you use any_iterator or something like that. So at lease how it was written it was wrong.
Your algorithm seems wrong. If the output buffer is too small, simply don't process the data that would require a larger buffer.
If you know that would it size be?
Or you could design the code so that the output buffer is always statically guaranteed to be big enough.
What is the guarantee? Do you have specific suggestions for Case handling where the charset is changed in runtime, locale is changed in runtime and so on?
And don't copy the whole input range to a contiguous buffer (that would need to be heap-allocated), copy it in bits to an automatic buffer.
Some operations require to have entire text and not small part of it, you had written some Unicode algorithms, you know it. Now add a charset know in the run time to make it even more fun.
But this is really "Dikumware STL" problem because other normal libraries do it in big chunks as they should.
If your library requires on codecvt facets to be efficient and the most popular implementation isn't, then it becomes your library's problem.
No, it does not requires, but if current implementation is already bad, how can I do it better? Artyom