Разрешение пользователю взаимодействовать со std :: strings при внутренней реализации связанного списка?

Question

Я создаю текстовое поле для моей игры. Большинство функций, связанных со строками в движке, которые я использую, используют std :: string * или std :: string &.

Вот некоторые из ограничений:

Остальная часть моего графического интерфейса API возвращает std :: string & для функции getText (), поэтому мне нужно иметь возможность вернуть std :: string & для текста.

Я реализовал текстовое поле, используя std :: string и создавая строки из строк. Проблема в том, что он слишком медленный со слишком большим количеством текста, поэтому я вместо этого хочу использовать строку, которая является списком. Я предполагаю, что рендеринг будет медленнее из-за кеширования. Как я могу реализовать строковый класс с быстрой вставкой / удалением, в то же время предоставляя std :: string и, казалось бы, непрерывный поток символов?

Спасибо

Answer 1

К сожалению, вы действительно не можете;класс std::string должен иметь непрерывное хранилище, чтобы функция-член data могла работать правильно.Если вы хотите использовать более быстрое представление строки для буфера редактора, такого как веревка , вам понадобится, чтобы функция возвращала что-то другого типа.

Answer 2

Вы не можете.

Вот почему: std :: string и std :: wstring обрабатываются специально в сторонних библиотеках и приложениях, и компоновщик предпочтет использовать версии MSVCP80 / 90.DLLрутины, а не ваши переопределения.Предоставляя альтернативную реализацию поверх имен typedefs для std :: string и std :: wstring, вы нарушаете правило One Definition.Будет много хаоса.

В идеальном мире вы можете полностью использовать другой тип в своем API, который понимает несмежную структуру вашей 'строки', и этот тип может быть СИНТАКТИЧЕСКИ совместимо с 200+ функциями-членами std :: string.Он может использовать отложенную конструкцию всей непрерывной строки до тех пор, пока .data () или .c_str () не будут вызваны для передачи ее другим функциям API, которые принимают указатели char *.В этом идеальном мире вы могли бы затем перекомпилировать каждый фрагмент кода, в котором есть интерфейс std :: string.

В реальном мире вы можете изменить интерфейс GUI API, чтобы понять ваш список строк.тип.

Answer 3

РЕДАКТИРОВАТЬ: Я недостаточно внимательно прочитал ваш вопрос.Проигнорируйте следующее (извините)

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

В качестве альтернативы, вы можете достичьто же самое с использованием шаблонов и специализаций, а также избежание накладных расходов на виртуальные вызовы.

Короче говоря, вы не можете реально предоставить std :: string, если не создадите строку на лету из метода tostdstring или чего-то еще.

Answer 4

Трудно судить по приведенным подробностям. Я предполагаю, что вы (повторно) создаете слишком много строковых копий, возможно, пропускаете новые объекты снова и снова и т. Д.

Резервирование большего количества места для std::string заранее также может помочь. Это действительно трудно сказать, не зная никакого реального кода.

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