Последствия кеширования длины строки в нативном классе C ++?

Question

Итак, у нас есть собственный класс строк, который просто оборачивает базовую строку C: char * или wchar_t *. Единственный член данных нашего пользовательского строкового класса - это указатель. В любом случае, здесь на работе мы обсуждаем добавление еще одного члена, который кэширует длину внутреннего массива char. Так что вместо

MyString :: Count {return _tcslen (foo); }

мы могли бы просто написать:

MyString :: Count {return m_count; } * +1010 *

Но я уверен, что есть особый гоч, который укусил бы нас, если бы мы сделали это. Вы знаете, какой-то особый способ взломать такую ​​реализацию широко открытыми. Итак, мой вопрос: каковы недостатки кэширования длины?

Answer 1

Что если кто-то изменит содержимое строки без вызова специальной функции "счетчик обновлений"? В этот момент ваш сохраненный счетчик и сама строка не синхронизированы, что может привести к всевозможным проблемам, включая сбои.

Answer 2

Первое: не делайте этого, если у вас нет данных профилирования, показывающих, что это действительно узкое место .Если у вас этого нет, вы все тратили время на споры об этом ИМО.Сначала исправьте код, а затем атакуйте важные узкие места.

Если вы кешируете его, убедитесь, что все пути, которые могут изменить внутреннюю строку, также соответствующим образом обновят m_count.

ЕслиВаша оболочка передает неконстантную ссылку или указатель на данные, не кэшируйте их - вы не можете быть уверены, что значение останется фиксированным.

Answer 3

Нет реальных недостатков в кэшировании длины.Класс std :: string делает то же самое.Это также позволяет вам хранить NUL-символы в ваших данных, если вы решите.

Просто убедитесь, что ваши данные и кэшированное значение всегда синхронизируются через средства доступа и, возможно, защищенные элементы данных.