История изменений
Исправление shdown, (текущая версия) :
Ну как минимум, чтобы у строки появился метод считающий количество символов придётся создать новый класс наследуя этот самый string_view.
Зачем? Если мы храним байты, то это будет просто функция. Если ты хочешь, чтобы символы изначально хранились в wchar_t, то для этого есть std::wstring_view (aka std::basic_string_view<wchar_t>).
Надо где-то будет хранить кодировку, чтобы считалка работала
Она вообще-то в локали хранится. Той самой, которая меняется с помощью setlocale(). Можешь, конечно, свой велосипед написать, но зачем?
Виртуальный метод понадобится чтобы какой-нибудь sview.symbols() менять в зависимости от кодировки, при смене кодировки может понадобится побольше памяти под строку
Так у нас для каждой кодировки новый дочерний класс или она глобальная и можно организовать её «смену» на ходу?
при смене кодировки может понадобится побольше памяти под строку
Так ты ж говорил, что там просто байты лежат!
придётся аллокатор делать, т.к. у нас ссылка на буфер со стороны, надо следить, когда ему free() сделают, ну и т.п.
Всё, какая-то шизофазия пошла.
Мы ж «строку» делаем, «правильную», а не костыли какие-то недоделанные, не так ли?
Кто «мы»-то, ты один тут какую-то ерунду пишешь.
Исходная версия shdown, :
Ну как минимум, чтобы у строки появился метод считающий количество символов придётся создать новый класс наследуя этот самый string_view.
Зачем? Если мы храним байты, то это будет просто функция. Если ты хочешь, чтобы они изначально хранились в wchar_t, то для этого есть std::wstring_view (aka std::basic_string_view<wchar_t>).
Надо где-то будет хранить кодировку, чтобы считалка работала
Она вообще-то в локали хранится. Той самой, которая меняется с помощью setlocale(). Можешь, конечно, свой велосипед написать, но зачем?
Виртуальный метод понадобится чтобы какой-нибудь sview.symbols() менять в зависимости от кодировки, при смене кодировки может понадобится побольше памяти под строку
Так у нас для каждой кодировки новый дочерний класс или она глобальная и можно организовать её «смену» на ходу?
при смене кодировки может понадобится побольше памяти под строку
Так ты ж говорил, что там просто байты лежат!
придётся аллокатор делать, т.к. у нас ссылка на буфер со стороны, надо следить, когда ему free() сделают, ну и т.п.
Всё, какая-то шизофазия пошла.
Мы ж «строку» делаем, «правильную», а не костыли какие-то недоделанные, не так ли?
Кто «мы»-то, ты один тут какую-то ерунду пишешь.