Украсьте char * и char const * с помощью указателя: хорошая практика?
Здравствуйте, я хотел бы опросить общественность о моей идее создания строкового класса (например, std::string) это будет иметь возможность работать с буферами, предоставленными клиентом.
Какие опасности вы предвидите? это классический запах? etcaetera
Я имею в виду так:
char ext[64] = {0};
my::string s(ext, my::string::acquire_RW);
size_t len = s.size();
size_t pos = s.find("zboub");
my::string s2(s); // uses true (alloc+)copy semantic here.
Итак, я предвижу 2 стратегии: acquire_RW а также acquire_RO что позволит изменить символы в ext или нет. И в RO случай для любого неконстантного метода, и RW случаи в методах, где буфер должен быть расширен; было бы выделить & копировать только в данный момент.
В некотором смысле, my::string Тип становится декоратором char* тип.
Конечно, будьте осторожны, чтобы не освободить внешний буфер до того, как декоратор будет оставлен как требование к клиенту.
Спасибо, что поделились своими проблемами
Решение
Ответ на «хорошую практику» труден. Я бы сказал, что в целом это не очень хорошая практика, но для некоторых конкретных случаев очень хорошая практика. Все зависит от того, насколько хорошо вы можете доверять клиенту в течение срока службы предоставленной памяти. В общем: доверия нет. В особых случаях: ОК.
Есть одна довольно важная вещь, чтобы рассмотреть производительность:
Планируете ли вы использовать неявный обмен (с копированием при записи и подсчетом ссылок) ваших выделено варианты ваших строк? Или вы планируете использовать семантику значений (всегда копировать, а не ссылаться)?
В многопроцессорных и многопоточных средах семантика значений является предпочтительным способом для строк. Повышение производительности при использовании неявного совместного использования уничтожается необходимой блокировкой в многопоточных средах.
Обратите внимание, что ваше предложение может иметь смысл даже в многопотоковом режиме: вы можете идеально использовать копирование при записи при переходе из внешней памяти в выделенный вариант (без необходимости блокировки) и семантику значений с этого момента (также без блокировки необходимо). Это было бы лучше всего.
Я полагаю, что ваш вариант хорошо работает в очень специфических случаях, когда, например, вы отображали в памяти какой-то файл с большим количеством строк, и вы не хотите хранить копии этих маленьких строк и фрагменты памяти.
Впрочем, в общем случае я бы не волновался и просто использовал std::string,
Другие решения
Я думаю, что это отличная идея, но я бы придерживался только для чтения; std::string идеально подходит для RW, если, конечно, не существует ситуации, когда вы можете сэкономить часть памяти.
Это довольно оптимизация, поэтому, возможно, она не будет стоить усилий, если только вы не знаете, что ваши статические строки вызывают проблемы.