Например, предположим, что у меня есть буфер под названием char journal_name[25], который я использую для хранения имени журнала. Теперь предположим несколько строк позже в коде, я хочу сохранить имя кого-то в буфер. Должен ли я пойти char person_name[25] или просто повторно использовать journal_name[25]?
Проблема в том, что каждый, кто читает код (и меня тоже через несколько недель), должен понимать, что journal_name теперь фактически person_name.
Но аргумент счетчика состоит в том, что наличие двух буферов увеличивает использование пространства. Так что лучше использовать его.
Что вы думаете об этой проблеме?
Спасибо, Бода Сидо.
Способ решения этой проблемы на C, если вы действительно не хотите тратить память, заключается в использовании блоков для охвата буферов:
int main()
{
{
char journal_name[26];
// use journal name
}
{
char person_name[26];
// use person name
}
}
Компилятор будет использовать одно и то же место памяти для обоих, давая вам совершенно понятное имя.
Как альтернатива, назовите его name и используйте его как для <. <
Здесь действительно порядок. Однако несколько замечаний:
Сохраните идентификатор, выделенный из ваших объектов. Назовите его scratchpad или что-нибудь еще. Кроме того, по внешнему виду этот массив символов не распределяется динамически. Это означает, что вам нужно выделить достаточно большой блокнот, чтобы повторно использовать их.
Еще лучший подход состоит в том, чтобы сделать ваши функции короче: одна функция должна в идеале делать одно за раз. Посмотрите, можете ли вы расстаться и по-прежнему сталкиваться с этой проблемой.
В качестве альтернативы предыдущим (хорошим) ответам, что насчет
char buffer[25];
char* journal_name = buffer;
а затем
char* person_name = buffer;
Было бы хорошо?
Если оба буфера автоматические, почему бы не использовать это? Большинство компиляторов правильно справятся с повторной использованием памяти. Но вы сохраняете читаемость.
{
char journal_name[25];
/*
Your code which uses journal_name..
*/
}
{
char person_name[25];
/*
Your code which uses person_name...
*/
}
Кстати, даже если ваш компилятор глуп, и у вас очень мало памяти, вы можете использовать union, но для чтения читайте разные имена. Использование одной и той же переменной хуже всего.
Используйте person_name[25]. Ни одному телу не нравится читать код. Это не собирается делать много, если что-либо вообще для вашей программы с точки зрения памяти. Пожалуйста, просто сделайте это понятным способом.
Вы должны всегда (ну, если вы не слишком плотно работали в памяти), идите на удобочитаемость и ремонтопригодность при написании кода по той причине, о которой вы говорили в своем вопросе.
25 символов (если это не просто пример) не собирается "ломать банк", но если память стоит премиум-класса, вы можете динамически распределять хранилище для journal_name, а затем освобождать его, когда закончите с ним перед динамическим распределением хранилища для person_name. Хотя есть указатель на указатель на массив.
Другим способом было бы использовать локальное масштабирование массивов:
void myMethod()
{
... some code
{
char journal_name[25];
... some more code
}
... even more code
{
char person_name[25];
... yet more code
}
}
Хотя даже с этим псевдокодом метод довольно длительный и будет полезен для рефакторинга в подпрограммах, которые не будут иметь этой проблемы.
Если вы беспокоитесь о памяти, и я сомневаюсь, что проблема будет в 25 байт, но тогда вы можете просто использовать malloc и free, а затем у вас есть дополнительные 4-8 байтов, которые используются для указателя.
Но, как отмечали другие, читаемость важна, и вы можете захотеть разложить свою функцию так, чтобы два буфера были использованы в функциях, которые фактически дают больше указаний на их использование.
UPDATE:
Теперь у меня есть буфер под названием buffer, который я бы использовал для чтения из файла, например, а затем я использовал бы указатель функции, который был передан, для синтаксического анализа результатов, чтобы функция читала файл, и обрабатывает его надлежащим образом, так что буфер не заполняется, а затем я должен помнить, что он не должен быть перезаписан еще.
Итак, повторное использование буфера может быть полезно при чтении из сокетов или файлов, но вы хотите локализовать использование этого буфера, иначе у вас могут быть условия гонки.