|
Boost : |
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
now,
but unfortunately I don't sem to find the time to do so. So I'm just
writing
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
prerequisite
for the latter. The only way we get those things into the standard is
if the
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
some basic
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
later and
send it on through a different text based interface. During all that I
don't want
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
particularities
of how unicode works to o that.
For that, I think it is much more important to have encoding aware
interface
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
for:
Facilitate and enable components from different 3rd pary vendors to
work
seemlessly together!
I'm also very happy to see that the library focuses on the 90% cases
instead
of trying to be flexible enough to be usable for every possible use
case and
under every possible circumstance.
Best
Mike
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk