From: Mike (mike.dev_at_[hidden])
Date: 2019-11-02 16:07:48
I have been meaning to have a closer look at that library for weeks
but unfortunately I don't sem to find the time to do so. So I'm just
down some thoughts:
First of all, I hihgly support the inclusion of this
library into boost (assuming there aren't any major design problems).
C++ needs unicode support easy text processing - the former being a
for the latter. The only way we get those things into the standard is
different approaches get battle tested in anger, in real-life projects.
What the average programmer like me (who is not working on a text
editor) imho needs is the ability to read text from one interface, do
input validation, normalize it, (potentially) split it up and or parse
parts of it,
store other parts through a different interface, retrieve all of that
send it on through a different text based interface. During all that I
to have to worry too much about whethernon-asccii text got broken in
betweeen. And in particular I should not have to worry about the
of how unicode works to o that.
For that, I think it is much more important to have encoding aware
types and easy to use transcoding functions than a full set of unicode
text processing algorithms. Not that I'm not happy when they are there,
but at least for the standard, lets please focus on what standards are
Facilitate and enable components from different 3rd pary vendors to
I'm also very happy to see that the library focuses on the 90% cases
of trying to be flexible enough to be usable for every possible use
under every possible circumstance.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk