Каллок лучше, чем маллок?

Это действительно зависит от ситуации. Практическое правило

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

  Пример: рассмотрим следующий сценарий

  char * pointer = NULL;
  
  //allocation
  
  strcpy(pointer, source);
  

  здесь можно очень хорошо использовать malloc().

• Если есть возможность чтения перед записью с выделенной памятью, выберите calloc(), поскольку он инициализирует память. Таким образом, вы можете избежать проблемы со сценарием чтения перед записью модульной памяти, который вызывает неопределенное поведение.

  Пример:

  char * pointer = NULL;
  
  //allocation
  
  strcat(pointer, source);
  

  Здесь strcat() требуется, чтобы первый аргумент уже был строкой, и использование malloc() для выделения не может этого гарантировать. Поскольку calloc() инициализирует память нулями, она будет служить этой цели, и, таким образом, calloc() - лучший способ для этого случая.

Чтобы разработать второй сценарий, цитируя C11, глава §7.24.3.1 (следуйте моему выделению)

Функция strcat() добавляет копию строки, на которую указывает s2 (включая завершающий нулевой символ), в конец строки, на которую указывает s1. Начальный символ s2 заменяет нулевой символ в конце s1. [....]

Итак, в этом случае указатель назначения должен быть указателем на строку. Распределение через calloc() гарантирует, что при выделении с использованием malloc() не может гарантировать, что, как мы знаем из главы §7.22.3.4

Функция malloc выделяет пространство для объекта, размер которого определяется параметрами size и , значение которого не определено.

РЕДАКТИРОВАТЬ:

Один из возможных сценариев, где malloc() рекомендуется вместо calloc(), - это написание тестовых заглушек, используемых для модульного / интеграционного тестирования. В этом случае использование calloc() может скрыть потенциальные ошибки, которые появляются в случаях, аналогичных предыдущему.

Основное различие между malloc и calloc состоит в том, что calloc инициализирует ваш буфер нулями, а malloc оставит память неинициализированной.

Это приводит к общей программной идиоме «не платите за то, что не используете». Другими словами, зачем обнулять что-то (за что нужно платить), если в этом нет необходимости (пока)?

В качестве побочного примечания, поскольку вы отметили C ++: использование памяти вручную с использованием new/delete не одобряется в современном C ++ (за исключением редких случаев пулов памяти и т. Д.). malloc/free используется еще реже, и его следует использовать очень экономно.

Используйте calloc для распределений с нулевым заполнением, но только тогда, когда заполнение нулями действительно необходимо.

Вы всегда должны использовать calloc(count,size) вместо buff=malloc(total_size); memset(buff,0,total_size).

Призыв к нулю-memset - это ключ. И malloc, и calloc транслируются в вызовы ОС, которые выполняют множество оптимизаций, по возможности используют аппаратные уловки и т. Д. Но ОС мало что может сделать с memset.

С другой стороны, когда вам нужно обнулить выделенную память? Единственное распространенное использование - это элементы произвольной длины с нулевым концом, такие как C-строки. Если это так, конечно, используйте calloc.

Но если вы выделяете структуры, в которых элементы либо фиксированной длины, либо несут с собой длину элементов произвольного размера (например, строки и векторы C ++), заполнение нулями вообще бесполезно, и если вы попытаетесь полагаться на на нем это может привести к хитрым ошибкам.

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

Для целей отладки заполнение нулями обычно тоже не очень хорошо. 0 слишком распространено, вы редко можете написать что-то вроде assert(size);, потому что обычно это действительное значение, вы обрабатываете его с помощью if(!size), а не с помощью утверждений. В отладчике это тоже не бросается в глаза, в памяти обычно везде нули. Лучше всего избегать беззнаковых типов для длин (подписанные длины могут быть полезны для обработки ошибок во время выполнения, а также для некоторых наиболее распространенных проверок переполнения). Итак, хотя buff=malloc(total_size); memset(buff,0,total_size) следует избегать, следующее нормально:

const signed char UNINIT_MEM=MY_SENTINEL_VALUE;
buff=malloc(total_size);
#if DEBUG_MEMORY
memset(buff,UNINIT_MEM,total_size);
#endif

В режиме отладки библиотека времени выполнения или даже ОС иногда делают это за вас, например, проверьте этот отличный пост о специальных дозорных значениях VC ++.

malloc () гораздо чаще встречается в коде C, чем calloc ().

При текстовом поиске "malloc" вызовы calloc () будут пропущены.

Сменные библиотеки часто имеют mymalloc (), myrealloc (), myfree (), но не mycalloc ().

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

calloc () имеет тенденцию скрывать ошибки. Debug malloc обычно устанавливает образец заполнения, такой как DEADBEEF, который оценивается как большое отрицательное число и не похож на настоящие данные. Таким образом, программа быстро вылетает, и с помощью отладчика ошибка стирается.

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