Почему в каждой платформе C ++ есть разные строковые классы?

IMO, std :: string недостаточно стара, чтобы получить широкое распространение (Qt и wxWidgets старше, чем STL, или, по крайней мере, старше широко доступных стабильных и рабочих STL). Кроме того, std :: string, к сожалению, не лучший строковый класс для всех, и у других фреймворков есть другие потребности.

Примечание! Приведенный ниже абзац немного некорректен, но оставлен для понимания комментариев.

Например, C ++ STL очень ограничен в ресурсах, тогда как строковый класс Qt предлагает множество преимуществ, с которыми коммит никогда не согласится, особенно потому, что некоторые хотят, чтобы его можно было легко реализовать во встроенных системах и т.п.

Одна разумная причина (по сравнению с необоснованными причинами вроде «Я не хочу изучать стандартную библиотеку») заключается в том, что некоторые библиотеки хотят сохранить контроль над двоичной компоновкой для достижения определенных видов совместимости (например, двоичная совместимость версий). Примером этого является _bstr_t в библиотеках VC ++; Для целей COM важно, чтобы _bstr_t был представлен как BSTR (поскольку это то, что нужно COM), поэтому оболочка, построенная поверх BSTR, представляет ценность для разработчиков COM.

IIRC Бьярн Страуструп намеренно исключил класс String из C ++, считая его «обрядом перехода». Ожидалось, что все, кто изучал C ++, напишут свои собственные. Конечно, в начале C ++ не было стандартных библиотек, и я помню версии от AT&T (которая была препроцессором для C) и классы NIH от очень новаторской группы в Национальном институте здравоохранения в США (которые также включали классы раннего сбора ).

std :: string отлично ... О,

Один из клиентов C ++: «Вы не платите за то, что вам не нужно». Это означает, что не обязательно должен быть универсальный строковый класс, который ДОЛЖЕН знать каждый программист на C ++ и (что более важно) ИСПОЛЬЗОВАТЬ. Возможно, вашему проекту требуются потокобезопасные строки. Вы можете свернуть свой собственный класс. И у вас всегда есть возможность использовать существующий std :: string.

Так уж получилось, что в большинстве случаев std :: string достаточно хорош. Но когда это не так, разве вы не рады, что не заперты в этом. Попробуйте применить свой собственный класс String в Java и посмотрите, сколько времени потребуется, чтобы вытащить волосы.

Что касается вашего второго пункта, если вы собираетесь бороться с библиотекой, которую вы добавили в свой проект, почему вы вообще добавили библиотеку в свой проект? Частью решения об использовании wxWidgets или QT является признание того, что вы должны включить его строковый класс в свой проект (или, по крайней мере, значительную часть этого проекта). Точно так же, как решение в пользу библиотеки "C" означает мириться с буферами char * и параметрами размера для всех функций.

Итак, да, изучите альтернативный строковый класс. Если вы используете библиотеку (и хотите научиться с ней разбираться), вы не можете решить игнорировать часть библиотеки только потому, что «это другой строковый класс». В этом нет никакого смысла.

Итак, да, изучите альтернативный строковый класс. Если вы используете библиотеку (и хотите научиться с ней разбираться), вы не можете решить игнорировать часть библиотеки только потому, что «это другой строковый класс». В этом нет никакого смысла.

Итак, да, изучите альтернативный строковый класс. Если вы используете библиотеку (и желаете научиться с ней разбираться), вы не можете решить игнорировать часть библиотеки только потому, что «это другой строковый класс». В этом нет смысла.

Одной из основных проблем с std :: string является отсутствие поддержки Unicode. Даже с std :: wstring вы получаете только контейнер для кодовых точек Unicode, но все равно должны реализовать функции, поддерживающие Unicode.

Кроме того, QString , например, " неявно поделился ". Это упрощает эффективную передачу строк в коде. Фактически они копируются только при записи.