Блог

При проектировании структур, содержащих текстовые данные, я использовал два основных подхода, проиллюстрированных ниже:

 typedef struct {
    STRING address1;
    STRING address2;
    STRING city;
    STRING state;
    STRING zip;
} ADDRESS;

typedef struct {
    STRING* address1;
    STRING* address2;
    STRING* city;
    STRING* state;
    STRING* zip;
} ADDRESS;
 

где STRING — это некоторый тип хранения строк переменной длины. Преимущество версии с указателем заключается в том, что я могу хранить значение NULL, указывающее на отсутствие данных. Например, address2 может быть не предоставлен для некоторых адресов. В типе со встроенными строками я должен использовать «пустую» строку, то есть строку, имеющую длину 0.

С указателями (возможно) больше нагрузки на код, потому что я должен проверять каждый элемент на наличие NULL перед использованием. Однако преимущество не так велико, потому что обычно встроенная версия тоже должна быть проверена. Например, если я печатаю адрес, я должен проверить наличие строки нулевой длины и пропустить эту строку. С помощью указателей пользователь может фактически указать, что ему нужно «пустое» вместо отсутствующего значения, хотя трудно увидеть применение для этого.

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

Обратите внимание, что использование памяти является проблемой, но она довольно незначительна. Версия указателя занимает немного больше памяти, потому что я храню указатели на структуры в дополнение к структурам. Но каждая строковая структура занимает в среднем, может быть, 40 байт, поэтому, если я храню 4-байтовые указатели, то версия указателя стоит, возможно, на 10% больше памяти, что не является значительным. Наличие возможных нулевых указателей не экономит значительную память, поскольку большинство полей заполнены.

Вопрос об АДРЕСЕ, а не О СТРОКЕ

Некоторые респонденты, похоже, сбиты с толку и думают, что я спрашиваю о глобальных компромиссах, например, о том, как свести к минимуму мой общий объем работы. Это не тот случай. Я спрашиваю о том, как создать АДРЕС, а не СТРОКУ. Члены address могут иметь фиксированные массивы, а в других случаях нет. Для целей моего вопроса меня не беспокоят последствия для контейнера.

Я уже заявлял, что единственная проблема, которую я вижу, заключается в том, что использование указателей требует больше времени, но я получаю преимущество от возможности хранить значение NULL. Однако, как я уже сказал, это преимущество не кажется значительным, но, возможно, это по какой-то причине. В этом суть моего вопроса: есть ли какая-то скрытая выгода от такой гибкости, которую я не вижу и хотел бы иметь позже.

Если вы не понимаете вопроса, пожалуйста, прочтите предварительный ответ, который я написал сам ниже (после некоторых дополнительных размышлений), чтобы увидеть, какой ответ я ищу.

Компромиссы по использованию памяти и сокращению mallocs

Похоже, что компромиссы сосредоточены вокруг двух вопросов: 1) Насколько ценна память? и 2) Имеет ли значение, что для строк выделяется фиксированный объем памяти, ограничивающий длины, которые будут храниться в каждом поле?

Если память важнее всего остального, то версия указателя, вероятно, выигрывает. Если предпочтительна предсказуемость использования хранилища и предотвращение mallocs, а ограничение длины имен некоторой фиксированной величиной приемлемо, тогда версия с фиксированной длиной может быть победителем.

Одна из проблем со встроенным стилем заключается в том, что СТРОКА должна быть определена как что-то вроде char[MAX_CHAR 1] where MAX_CHAR — пессимистическая максимальная длина для заданных полей. Стиль указателя позволяет выделить правильный объем памяти. Недостатком, как вы упомянули, является гораздо более высокая когнитивная нагрузка на управление вашей структурой.

Я рассматривал это более глубоко, и я думаю, что в большинстве случаев указатели необходимы, потому что важно различать пустое и отсутствующее. Причина этого заключается в том, что недостающие данные необходимы, когда входные данные неверны, повреждены или пропущены. Например, давайте представим, что при чтении из файла файл поврежден, поэтому поле, такое как почтовый индекс, нечитаемо. В этом случае данные «отсутствуют», а указатель должен быть нулевым. С другой стороны, давайте представим, что у места нет почтового индекса, тогда оно «пустое». Таким образом, NULL означает, что пользователь еще не предоставил информацию, но blank означает, что пользователь предоставил информацию, и нет ни одного типа, о котором идет речь.

Итак, чтобы еще раз проиллюстрировать важность использования указателя, представьте, что сложная структура заполняется с течением времени разными асинхронными шагами. Здесь нам нужно знать, какие поля были прочитаны, а какие нет. Если мы не используем указатели (или не добавляем дополнительные метаданные), у нас нет способа определить разницу между полем, на которое был дан ответ, и полем, для которого ответ «нет». Представьте себе, что система запрашивает пользователя: «Какой почтовый индекс?». Пользователь говорит: «У этого места нет почтового индекса». Затем через 5 минут система снова спрашивает: «Какой почтовый индекс?». Этот вариант использования ясно показывает, что в большинстве случаев нам нужны указатели.

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