Чому існує стільки класів рядків перед обличчям std :: string?

Мені здається, що багато більших бібліотек C ++ в кінцевому підсумку створюють власний тип рядка. У клієнтському коді вам потрібно використовувати той, який використовується з бібліотеки ( QString, CStringі fbstringт. Д., Я впевнений, що хтось може назвати їх декілька) або продовжувати конвертувати між типовим типом і тим, який використовує бібліотека (що більшість часу передбачає хоча б один примірник).

Отже, чи є певна невдача чи щось не так std::string(як і auto_ptrсемантика була поганою)? Чи змінилося це в C ++ 11?

Більшість цих більших бібліотек C ++ були створені раніше, ніж std::stringбуло стандартизовано. Інші включають додаткові функції, які були стандартизовані пізно або ще не стандартизовані, такі як підтримка UTF-8 та перетворення між кодуванням.

Якби ці бібліотеки були реалізовані сьогодні, вони, ймовірно, вирішили записати функції та ітератори, які працюють над std::stringекземплярами.

Рядок є великим збентеженням C ++.

Протягом перших 15 років ви взагалі не надаєте клас рядків - змушуючи кожного компілятора на кожній платформі та кожного користувача створювати свій власний.

Тоді ви робите щось заплутане в тому, чи повинен це бути повноцінний API маніпуляції з рядком або просто контейнер символів STL, з деякими алгоритмами, які дублюють ті, які знаходяться на std :: Vector, або різні.

Якщо очевидна струнна операція, як заміна () або середина (), передбачає такий безлад ітераторів, що вам потрібно ввести нове ключове слово "авто", щоб укладати вислів на одній сторінці і змушує більшість людей здаватися на всій мові .

І тоді у вас є "підтримка" Unicode і std :: wstring, що просто arghh .....

<rant off> дякую - зараз я відчуваю себе набагато краще.

Насправді ... Є кілька проблем std::string, і так, це стає трохи краще в C ++ 11, але не давайте випереджати себе.

QStringі CStringє частиною старих бібліотек, тому вони існували до стандартизації C ++ (приблизно як SGI STL). Таким чином, їм довелося створити клас.

fbstringвирішити дуже конкретні проблеми щодо ефективності. Стандарт прописує інтерфейс, а алгоритмічна складність гарантує мінімуми, однак це деталі якості впровадження, незалежно від того, швидше це чи ні. fbstringмає специфічні оптимізації (наприклад, пов'язані з зберіганням даних або швидше find).

Інші проблеми, які тут не викликали (en vrac):

• в C ++ 03 не обов'язково зберігання зберігатись безперервно, що робить інтероперабельність із C потенційно складною. C ++ 11 виправляє це.
• std::string кодує невідомо і не має спеціального коду для UTF-8, легко зберігати в ньому рядок UTF-8 і ненавмисно пошкоджувати його
• std::stringінтерфейс роздутий , багато методів могли бути реалізовані як вільні функції, а багато дублюються, щоб відповідати як інтерфейсу на основі індексу, так і інтерфейсу на основі ітератора.

Окрім наведених тут причин, існує ще одна - бінарна сумісність . Письменники бібліотек не контролюють, яку std::stringреалізацію ви використовуєте та чи має вона такий же макет пам'яті, що і їх.

std::stringє шаблоном, тому його реалізація взята з локальних заголовків STL. Тепер уявіть, що ви локально використовуєте оптимізовану для продуктивності версію STL, повністю сумісну зі стандартом. Наприклад, ви, можливо, вибрали втручання статичного буфера в кожен, std::stringщоб зменшити кількість динамічних виділень і пропусків кешу. Як результат, схема пам'яті та / або розмір вашої реалізації відрізняється від бібліотеки.

Якщо лише макет відрізняється, деякі std::stringвиклики функцій учасників для екземплярів, переданих з бібліотеки до клієнта, або навпаки можуть не працювати, залежно від того, які члени були зміщені.

Якщо розмір також різний, всі типи бібліотек, які мають std::stringчлен, виявляться різними розмірами при позначці в бібліотеці та в коді клієнта. У членів даних, які перебувають у наступному std::stringучаснику, також буде змінено зсув, і будь-який прямий доступ / вбудований доступ, викликаний від клієнта, поверне сміття, незважаючи на те, що "виглядає нормально" під час налагодження самої бібліотеки.

Підсумок - якщо бібліотека та код клієнта зібрані у різних std::stringверсіях, вони будуть посилатися чудово, але це може призвести до деяких неприємних, важких для розуміння помилок. Якщо ви зміните свою std::stringреалізацію, всі бібліотеки, що відкривають членів STL, повинні бути перекомпільовані, щоб відповідати std::stringмакеті клієнта . А оскільки програмісти хочуть, щоб їх бібліотеки були надійними, їх рідко можна побачити std::stringбудь-де.

Справедливості це стосується всіх типів STL. IIRC вони не мають стандартизованого розміщення пам'яті.

Відповідей на це питання багато, але ось деякі:

1. Спадщина. Багато бібліотеки рядків і класів були написані ПРІОР до існування std :: string.

2. Для сумісності з кодом у C. Бібліотека std :: string - це C ++, де є інші бібліотеки рядків, які працюють з C і C ++.

3. Щоб уникнути динамічних виділень. Бібліотека std :: string використовує динамічне розподіл і може не підходити для вбудованих систем, коду, що переривається або в режимі реального часу, або для функцій низького рівня.

4. Шаблони. Бібліотека std :: string заснована на шаблонах. Ще зовсім недавно у деяких компіляторах C ++ була недостатньо ефективна або навіть помилкова підтримка шаблонів. На жаль, я працюю в галузі, яка використовує безліч спеціальних інструментів, і один з наших інструментальних ланцюжків від головного гравця в галузі не "офіційно" підтримує 100% C ++ (з баггі, як шаблони та ін.).

Напевно, є й багато поважних причин.

Йдеться переважно про Unicode. Стандартна підтримка Unicode в кращому випадку не відповідає нормам, і кожен має свої потреби в Unicode. Наприклад, ICU підтримує всі функції Unicode, які ви могли хотіти, за самим огидним автоматично створеним з Java інтерфейсом, який ви могли собі уявити, і якщо ви перебуваєте на Unix, що ви застрягли з UTF-16, цілком може бути не ваша ідея гарний час.

Крім того, багатьом людям потрібні різні рівні підтримки Unicode - не всім потрібні складні API компонування тексту та подібні речі. Тож легко зрозуміти, чому існують численні строкові класи - Стандартний досить непоганий, і всі мають різні потреби від нових, при цьому ніхто не встигає створити єдиний клас, який може виконувати безліч кросплатформних платформ Unicode із приємним інтерфейсом.

На мою думку, це здебільшого вина Комітету C ++ у тому, що він не надав належну підтримку Unicode - у 1998 або 2003 роках, можливо, це було зрозуміло, але це не було в C ++ 11. Сподіваємось, в C ++ 17 вони зробляться краще.

Це тому, що кожен програміст має щось довести і відчуває необхідність створити власний дивовижний, швидший клас струн для своєї однієї, приголомшливої ​​функції. Зазвичай це трохи зайве і призводить до різного роду додаткових перетворень на моєму досвіді.