Чем `Tcl_Free ()` отличается от `free ()`?

Question

Описания кажутся практически идентичными. Есть ли какие-то нюансы между ними, которые следует отметить? Зачем кому-то использовать один над другим? Этот вопрос может быть задан также для Tcl_Alloc() и malloc().

Answer 1

Они используются, потому что Tcl поддерживает сборку на Windows с одной цепочкой инструментов и загрузку DLL, созданной с помощью другой цепочки инструментов. Ключевой особенностью этого сценария является то, что для разных наборов инструментов довольно распространено иметь собственные реализации библиотеки C, а это означает различные реализации malloc(). Вы должны сопоставить malloc() и free() с одной и той же библиотекой, иначе вы получите действительно странные сбои (сбои, утечки памяти и т. Д. c). Предоставив Tcl_Alloc и Tcl_Free (которые обычно это очень тонкие обертки), позволяющие пользовательскому коду правильно сопоставлять распределения и выпуски.

Answer 2

Обычно это наиболее очевидная причина для этого:

Обычно наиболее понятной причиной использования вашей собственной версии функций выделения памяти является наличие единственного определения, которое позволяет изменять распределитель памяти. для другого распределителя. (отладка, расширение или реализация с параметрами безопасности и т. д. c.)

Предположим, у вас есть следующая реализация:

void *my_malloc(size_t siz)
{
    return malloc(siz);
}

void my_free(void *ptr)
{
    free(ptr);
}

, определенная в allocator_malloc.c

и для специального клиента X вы приобрели лицензию нового распределителя ACME. Для этого клиента вы связываете свой исполняемый файл с файлом allocator_ACME.c, который содержит:

void *my_malloc(size_t siz)
{
    return ACME_malloc(siz);
}

void free(void *ptr)
{
    ACME_free(ptr);
}

Затем, просто связывая свой исполняемый файл с тем или иным файлом, вы генерируете зависимость стандартной библиотеки malloc(), или вам придется предоставить реализацию функции ACME_malloc(). Таким образом, просто изменяя наличие одного из нескольких объектных файлов, изменяет весь набор зависимостей (при условии, что у вас есть определения для my_malloc() и my_free() в исходном файле) в одну из нескольких различных реализаций.

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

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

void *my_malloc(size_t siz)
{
    return GC_malloc(siz);
}

void my_free(void *ptr)
{
    /* empty */
}