[SG16-Unicode] Replacement for codecvt

Niall Douglas s_sourceforge at nedprod.com
Mon Sep 2 13:02:20 CEST 2019


>     >> If you presented a modified C compiler with reasonably designed
>     built-in
>     >> string object to the current C committee, I think you'd have a
>     very high
>     >> chance of success. Everybody recognises that strings need doing
>     right,
>     >> and a native built-in object is widely seen as the correct approach.
> 
> I would say C is a non issue - we could, arguably just not care, and C++
> has enough to deal with a sized string type ( even without changing
> existing literals, strlen is _for all intent and purposes_ constexpr in
> all implementations)

I spoke only of the technical considerations, but there are many more
favourable *political* considerations if going via WG14 for a decent
native string object/view:

1. C needs it more than C++. A lot more. And C is small, so strings
"look bigger" relative to the whole.

2. C gets a lot more flak from the vulnerability guys, and a sizeable
chunk of the regular attendees come from vulnerability-related roles. So
unlike in WG21, a majority of WG14 thinks this stuff very important and
urgent.

3. You get the entire committee in a single room. To say that improves
speed of turnaround would be putting it mildly. You can get a very large
amount of very high quality feedback in a single presentation. You also
get much more collaboration, and counter proposal papers. They're
basically very helpful because they have the free time to be so, in a
way WG21 is not.

4. Whatever WG14 does usually gets pulled into WG21. It's a perfectly
valid alternative track for WG21 standardisation.

> The real problem is system apis (both posix and win32 and all existing C
> code) - null termination in C++ exist for compatibility with that and it
> seems unlikely that we would manage to convince win32 or posix people
> to add (pointer size) functions everywhere - it's a lot of functions

POSIX folk would just *love* to replace null terminated strings.

But everyone over at the Austin Working Group insist that C needs
formally agreed standards support for an alternative first, because this
would be a big breaking change, and they'd like to do it exactly once ever.

This is very doable. Somebody just needs to champion it through.

Niall


More information about the Unicode mailing list