Как вы справляетесь с проблемами подписанного char -> int в стандартной библиотеке?

Это действительно давняя проблема в моей работе, и я понимаю, что у меня все еще нет хорошего решения для ...

C наивно определил все свои функции проверки символов для an int:

int isspace(int ch);

Но символы char часто подписываются, и полный символ часто не помещается в int или в какую-либо отдельную единицу хранения, которая используется для строк ******.

И эти функции были логическим шаблоном для текущих функций и методов C ++ и заложили основу для текущей стандартной библиотеки. Фактически, они все еще поддерживаются, afaict.

Таким образом, если вы передадите isspace (* pchar), вы можете столкнуться с проблемами расширения знака. Их трудно увидеть, и, судя по моему опыту, от них трудно защититься.

Точно так же, поскольку isspace () и ему подобные все принимают целые числа, и поскольку фактическая ширина символа часто неизвестна без строкового анализа - это означает, что любая современная библиотека символов никогда не должна перемещаться вокруг char или wchar_t, но только указатели / итераторы, поскольку, только проанализировав поток символов, можно узнать, какая часть из него составляет один логический символ, я немного не понимаю, как лучше всего подойти к проблеме?

Я продолжаю ожидать искреннего надежная библиотека, основанная на абстрагировании фактора размера любого символа и работе только со строками (предоставляя такие вещи, как isspace и т. д.), но либо я его пропустил, либо есть другое более простое решение, которое смотрит мне в лицо, что все из вас (кто знает, что вы делаете) используете ...

** Эти проблемы не возникают для кодировок символов фиксированного размера, которые могут полностью содержать полный символ - UTF-32, по-видимому, является единственным вариантом, имеющим эти характеристики (или специализированными средами, которые ограничиваются ASCII или некоторые такие).

Итак, мой вопрос:

«Как вы проверяете наличие пробелов, пригодности для печати и т. Д. Таким образом, чтобы не было двух проблем:

1) расширение знака и
{ {1}} 2) Проблемы с символами переменной ширины

В конце концов, большинство кодировок символов имеют переменную ширину: UTF-7, UTF-8, UTF-16, а также более старые стандарты, такие как Shift-JIS. Даже расширенный ASCII может иметь простую проблему с расширением знака, если компилятор рассматривает char как 8-битную единицу со знаком.

Обратите внимание:

Независимо от размера вашего char_type, это неверно для большинства кодировок символов. схемы.

Эта проблема есть в стандартной библиотеке C, а также в стандартных библиотеках C ++, которые по-прежнему пытаются передавать char и wchar_t, а не строковые итераторы в различных реализациях isspace, isprint и т. д.

На самом деле, это именно те функции, которые нарушают универсальность std :: string. Если бы он работал только в модулях хранения и не пытался делать вид, что понимаете значение std :: string. orage-units в виде логических символов (например, isspace), тогда абстракция была бы намного более честной и заставила бы нас, программистов, искать правильные решения где-нибудь в другом месте ...

Спасибо

Всем, кто участвовал. Между этим обсуждением и WChars, Encodings, Standards and Portability я гораздо лучше разбираюсь в проблемах.Хотя нет простых ответов, помогает каждое понимание.