On Wednesday 11 February 2015 02:22:45 Thiago Macieira wrote: > > charT do_toupper(charT c) const; > > const charT* do_toupper(charT* low, const charT* high) const; > > > > > > > > Effects: Converts a character or characters to upper case. The second > > form replaces each character *p in the range [low,high) for which a > > corresponding upper-case character exists, with that character. > > > > > > > > Returns: The first form returns the corresponding upper-case character if > > it is known to exist, or its argument if not. The second form returns > > high. > > The above does not deal with string expansion due to uppercasing (the > famous "ß" to "SS" case). The function is flawed by design.
You overlooked "where a corresponding character exists". Either uppercase ß exists (it does, it was found in an old printing, so there's a movement to adopt it, except Unicode doesn't have it), then it's not a problem, or it does (as is the case in Unicode), and the character stays lower-case. The problem might exist in upper-casing i in Turkish@utf-8, though (because i is US-ASCII, but toUpper(i) isn't). > Qt has done this since Qt 2.0 (June 1999), so we're at 15 years ahead and > counting. I would simply not trust something close to two decades behind us > to do something they haven't begun to implement yet. I agree 100% that Qt is light-years ahead of the standard when it comes to all things i18n. But... You can turn this argument 180° and it explains the situation with container classes. For more than 15 years, we have a vector that can use custom allocators and can iterate backwards symmetrically. Yes, vector implementations were lacking on existing platforms as little as 8 years ago, but what if all the man-power that has gone into making sub-standard container classes for Qt had instead gone into contributing to std implementations? What does this mean? It simply means: Pick your battles. There's zero point in trying to re-invent shared_ptr or anything from the STL (except fixing max(), but how do you explain the difference to std::max(), then?). But std::locale, as is universally agreed, not just in the Qt world, is deeply flawed. Here, Qt can contribute. By implementing a better alternative (not that I think current QLocale is _that_ great), but also by helping to move the standard forward. We're seeing how we stall development when things that aren't at the core of Qt's offering are good enough for Qt. Better invest the little time that is spent the Qt containers these days on improving the STL implementations where we find them lacking. That reminds me to start looking into why std::vector::emplace_back expands to 1K of text size more than push_back(T&&) on GCC... Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development