Если вы не знаете размер a-priori, у вас нет другого выбора, кроме как создать его динамически, используя malloc (или любой другой эквивалентный механизм на выбранном вами языке).
size_t buffer_size = ...; /* read from a DEFINE or from a config file */
char * buffer = malloc( sizeof( char ) * (buffer_size + 1) );
Создание буфера размером m
, но получение только входной строки размером n
с n < m
- не пустая трата памяти, а технический компромисс.
Если вы создаете буфер с размером, близким к предполагаемому вводу, вы рискуете переполнить буфер много, много раз для тех случаев, когда m >> n
. Как правило, итерации в буфере связаны с операциями ввода-вывода, поэтому теперь вы можете экономить некоторые байты (что на самом деле не имеет значения в современном оборудовании) за счет потенциального увеличения проблем на другом конце. Специально для клиент-серверных приложений. Если бы мы говорили о встроенных системах с ограниченными ресурсами, это было бы другое дело.
Вы должны беспокоиться о том, чтобы ваши алгоритмы были правильными и надежными. Тогда вы беспокоитесь, если можете, о том, чтобы сбрасывать несколько байтов здесь и там.
Для меня я бы предпочел создать буфер, который в 2-10 раз больше, чем средний вход (не самый маленький вход, как в вашем случае, а средний), предполагая, что мой вход имеет медленное стандартное отклонение размер. В противном случае я бы пошел в 20 раз больше или больше (особенно если память дешевая, и это минимизирует попадание на диск или карту NIC.)
При самой базовой установке размер буфера обычно получается в виде элемента конфигурации, считываемого из файла (или передаваемого в качестве аргумента), и по умолчанию равным default compile time value
, если ничего не указано. Затем вы можете настроить размер ваших буферов в соответствии с наблюдаемыми размерами ввода.
Более сложные алгоритмы (скажем, TCP) корректируют размер своих буферов во время выполнения, чтобы лучше приспосабливать ввод, размер которого может / будет меняться со временем.