CS>Здравствуйте, x905, Вы писали:

X>>не совсем в тему, но предлагаю перейти на "классовые" строки типа QString — проблем будет меньше
CS> Это совсем не в тему.

CS>Слепое использование QString или std::string в тех местах где можно обойтись просто const wchar_t* или slice<wchar_t>
CS>может привести к одной но зело неприятной проблеме — перерасход и/или фрагментация heap.

По моему совет то как раз именно в тему — сишные массивы нужно использовать только когда они действительно необходимы.
И вместо них нужно использовать врапперы (в данном случае std::string) и не только для возврата результата, но и для полей внутри класса.
Преимущества:
— нет проблем с размерами (не нужно заботиться о расширении и выходе за границу массива),
— удобные операции конкатенации, поиска, прохода по контейнеру
Недостатки:
— уже указанная фрагментация кучи процесса и как следствие — тормоза при выделении памяти из кучи.

Отсюда мой вывод — использовать всегда врапперы, пока тесты не начинают показывать что производительность не соответствует требованиям к продукту.
И то в этом случае можно перейти на аллокаторы отдающие память не из кучи а из пула на стеке.
Короче, как говорится:
"
1. сделай чтобы это работало,
2. сделай чтобы это работало правильно
3. и только потом сделай чтобы это работало быстро".

И вообще — берем "Стандарты программирования на C++" Александреску и Саттера и смотрим совет 77 "Вместо массивов используйте vector и string":

Избегайте реализации абстракции массива посредством массивов в стиле C, арифметики указателей и примитивов управления памятью. Использование vector и string не только сделает проще вашу жизнь, но и позволит написать более безопасную и масштабируемую программу.

CS>Если понятие const char* вызывает проблемы то имхо следует уже переходить на .NET/Java. Там во всяком случае не будет фрагментации.
А если:
— плюсы корпоративный стандарт,
— куча кода на C++
— весь third party API — плюсовый
Да и есть ли в .NET/Java такие же удобные алгоритмы и boost как в плюсах?