Migrating XMLChar to char16_t basically means setting in stone and forever that xerces-c is an utf-16 only library so it's going in a radically different direction than I was suggesting, so I'm not very happy to hear about it. I think it can be safely stated that this move actually closes more doors than it opens. While simplifying the code base and test grid is great, as I'm reading in [1], I would have chosen to drop support for wchar_t and int16_t but keep XMLChar for future possibility to support utf8 for internal encoding. Are you really sure you want to pursue this direction?
[1] https://issues.apache.org/jira/browse/XERCESC-2206 On Thu, 16 Jul 2020 at 14:22, Cantor, Scott <canto...@osu.edu> wrote: > > On 7/16/20, 8:07 AM, "Francesco Pretto" <cez...@gmail.com> wrote: > > > Thank you, and thank you for frankness! Probably of the two the utf-8 > > for internal encoding would be more oriented towards c++ modernization > > changes, as you said, but probably a big change touching all the code > > base. > > It's massive. What Roger is doing is making XMLChar work as char16_t. That > eliminates a lot of problems with literals and STL integration, but it > doesn’t change the fact that virtually every other C or older C++ library > still won't integrate well. > > -- Scott > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org > For additional commands, e-mail: c-dev-h...@xerces.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
