C 的智能指针/安全内存管理？

Question

我和我认为许多其他人已经使用智能指针在 C++ 中包装不安全的内存操作，使用诸如 RAII 之类的东西取得了巨大的成功。 但是，当您有析构函数、类、运算符重载等时，包装内存管理更容易实现。

对于使用原始 C99 编写的人，您可以指出哪里（没有双关语意）来帮助安全内存管理？

谢谢。

Answer 1

这个问题有点老了，但我想我会花时间链接到我的 GNU 编译器（GCC、Clang、ICC、MinGW 等）的智能指针库。

这个实现依赖于清理变量属性，一个 GNU 扩展，在超出范围时自动释放内存，因此，不是ISO C99，而是带有 GNU 扩展的 C99。

例子：

简单1.c：

#include <stdio.h>
#include <csptr/smart_ptr.h>

int main(void) {
    smart int *some_int = unique_ptr(int, 1);

    printf("%p = %d\n", some_int, *some_int);

    // some_int is destroyed here
    return 0;
}

编译和 Valgrind 会话：

$ gcc -std=gnu99 -o simple1 simple1.c -lcsptr
$ valgrind ./simple1
==3407== Memcheck, a memory error detector
==3407== Copyright (C) 2002-2013, and GNU GPL\'d, by Julian Seward et al.
==3407== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==3407== Command: ./simple1 
==3407==
0x53db068 = 1
==3407==
==3407== HEAP SUMMARY:
==3407==     in use at exit: 0 bytes in 0 blocks
==3407==   total heap usage: 1 allocs, 1 frees, 48 bytes allocated
==3407==
==3407== All heap blocks were freed -- no leaks are possible
==3407==
==3407== For counts of detected and suppressed errors, rerun with: -v
==3407== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Answer 2

在原始 C 中处理智能指针很困难，因为您没有支持使用的语言语法。 我见过的大多数尝试都没有真正奏效，因为当对象离开作用域时，您没有析构函数运行的优势，而这正是智能指针起作用的真正原因。

如果您真的很担心这一点，您可能只想考虑直接使用垃圾收集器，并完全绕过智能指针要求。

Answer 3

您可能要考虑的另一种方法是Apache 使用的池化内存方法。 如果您有与请求或其他短期对象相关联的动态内存使用情况，这将非常有效。 您可以在请求结构中创建一个池，并确保始终从池中分配内存，然后在处理完请求后释放池。 一旦你使用过它，它听起来就没有那么强大了。 它几乎和 RAII 一样好。

Answer 4

你不能在 C 中做智能指针，因为它没有提供必要的语法，但你可以通过练习避免泄漏。 分配后立即编写资源释放代码。 因此，无论何时编写malloc ，都应立即在清理部分中编写相应的free 。

在 CI 中经常看到“GOTO 清理”模式：

int foo()
{
    int *resource = malloc(1000);
    int retVal = 0;
    //...
    if (time_to_exit())
    {
        retVal = 123;
        goto cleanup;
    }
cleanup:
    free(resource);
    return retVal;
}

在 C 中，我们也使用了很多分配内容的上下文，同样的规则也可以应用于：

int initializeStuff(Stuff *stuff)
{
    stuff->resource = malloc(sizeof(Resource));
    if (!stuff->resource) 
    {
        return -1; ///< Fail.
    }
    return 0; ///< Success.
}

void cleanupStuff(Stuff *stuff)
{
    free(stuff->resource);
}

这类似于对象构造函数和析构函数。 只要您不将分配的资源分配给其他对象，它就不会泄漏，指针也不会悬垂。

编写一个自定义分配器来跟踪分配并写入泄漏块atexit并不困难。

如果您需要放弃指向已分配资源的指针，您可以为其创建包装上下文，并且每个对象拥有一个包装上下文而不是资源。 这些包装器共享资源和一个计数器对象，该对象跟踪使用情况并在没有人使用时释放对象。 这就是 C++11 的shared_ptr和weak_ptr工作原理。 这里有更详细的描述： weak_ptr 是如何工作的？

Answer 5

像夹板或Gimpel PC-Lint 这样的静态代码分析工具在这里可能会有所帮助——您甚至可以通过将它们连接到您的自动“连续集成”样式构建服务器来使它们具有适度的“预防性”。 （你确实有其中之一，对吧？:grin:)

这个主题还有其他（一些更昂贵的）变体......

Answer 6

您可以定义宏，例如 BEGIN 和 END，用于代替大括号并触发退出其作用域的资源的自动销毁。 这要求所有这些资源都由智能指针指向，智能指针也包含指向对象析构函数的指针。 在我的实现中，我在堆内存中保留了一堆智能指针，在进入范围时记住堆栈指针，并在范围退出（END 或宏替换返回）时调用内存堆栈指针上方的所有资源的析构函数。 即使使用了 setjmp/longjmp 异常机制，这也能很好地工作，并清理 catch 块和抛出异常的范围之间的所有中间范围。 有关实现，请参阅https://github.com/psevon/exceptions-and-raii-in-c.git 。

Answer 7

好的，这是您的选择。 理想情况下，您将它们结合起来以获得更好的结果。 在 C 的情况下，偏执是好的。

编译时间：

1. 在 GCC 中使用清理变量属性。 之后你必须坚持使用 GCC。 这限制了代码的可移植性，因为您只能针对存在 GCC 的平台。
2. 在 Windows 上使用 SEH（结构化异常处理）。 这进一步限制了您的可移植性，因为您必须使用 Microsoft 编译器。 如果您的目标是专门的 Windows，那么它将为您工作。
3. 使用静态代码分析工具揭示潜在的内存泄漏。 不能完美地工作，但可以帮助找到微不足道的泄漏。 不影响你的便携性。

运行：

4. 使用调试内存分配库，它用自己的实现替换 malloc/free 并跟踪内存使用情况。 通过这种方式，您可以看到已分配但从未释放的块。 我在 Solaris 上取得了成功（我会尽量记住它的名字）。
5. 使用垃圾收集器。 在修复我没有源代码的非常泄漏的 C 应用程序时，我对Hans-Boehm GC有积极的体验。 我可以看到内存消耗是如何攀升的，然后在 GC 完成工作时它急剧下降。

Answer 8

如果您在 Win32 中编码，您也许能够使用结构化异常处理来完成类似的事情。 你可以这样做：

foo() {
    myType pFoo = 0;
    __try
    {
        pFoo = malloc(sizeof myType);
        // do some stuff
    }
    __finally
    {
        free pFoo;
    }
}

虽然不像 RAII 那样容易，但您可以在一个地方收集所有清理代码并保证它被执行。

Answer 9

Sometimes i use this approach and it seems good :)

Object *construct(type arg, ...){

    Object *__local = malloc(sizeof(Object));
    if(!__local)
        return NULL;
    __local->prop_a = arg;
    /* blah blah */


} // constructor

void destruct(Object *__this){

   if(__this->prop_a)free(this->prop_a);
   if(__this->prop_b)free(this->prop_b);

} // destructor

Object *o = __construct(200);
if(o != NULL)
   ;;

// use

destruct(o);

/*
  done !
*/