函数内部调用

发布于 2024-08-21 05:47:11 字数 640 浏览 5 评论 0原文

看一下刚刚提出的这个问题:指向静态变量的指针的不便那么这样做会被认为是不好的做法吗?

char* strpart(char* string, int start, int count)
{
    char* strtemp; 
    int i = 0; int j = 0;
    int strL = strlen(string);

    if ( count == 0 )
    {
        count = strL;
    }

    strtemp = (char*) calloc((count + 1), sizeof(char));
    for ( i = start; i < (start+count); i++ )
    {
        strtemp[j] = string[i];
        j++;
    }
    return strtemp;
}

抱歉,它写得很快,但基本原则是 - 当不在函数内使用静态缓冲区时,在函数内分配内存是一种不好的做法吗?我这么认为是因为它不会被释放,不是吗?我想我应该问一下。

Looking at this question that has just been asked: Inconveniences of pointers to static variables would doing something like this be considered bad practice, then?

char* strpart(char* string, int start, int count)
{
    char* strtemp; 
    int i = 0; int j = 0;
    int strL = strlen(string);

    if ( count == 0 )
    {
        count = strL;
    }

    strtemp = (char*) calloc((count + 1), sizeof(char));
    for ( i = start; i < (start+count); i++ )
    {
        strtemp[j] = string[i];
        j++;
    }
    return strtemp;
}

Sorry it's written quickly, but the basic principle is - when NOT using a static buffer inside a function is it bad practice to assign memory inside a function? I assume so because it wouldn't be freed, would it? Thought I ought to ask though.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

倾城花音 2024-08-28 05:47:11

这是不错的做法,但它很容易造成内存泄漏(调用者必须记住释放内存)。

我喜欢做的一件事是使用命名约定来指示可以分配哪些函数。例如,我将该函数命名为:

char* strpart_alloc(char* string, int start, int count)

It's not bad pratice but it can easily create memory leaks (the callers have to remember to free the memory).

One thing I like to do is use a naming convention to indicate what functions can allocate. For example, I'd name that function:

char* strpart_alloc(char* string, int start, int count)
陌上青苔 2024-08-28 05:47:11

在函数内部动态分配内存总是可以的,只要您向外界返回指向该内存的指针,以便其他东西可以释放它,或者您自己在函数内释放它。

It's always OK practice to allocate memory dynamically inside a function PROVIDED you return a pointer to that memory to the outside world, so that something else can free it, or free it yourself within the function.

━╋う一瞬間旳綻放 2024-08-28 05:47:11

嗯,这很危险。我会尽可能避免它。

您的假设是正确的 - 内存不会自动释放。

问题是这里的返回值是在堆上分配的内存,函数的调用者必须记住释放内存。您在这里分配的内存不会(由您)释放。对 API 的用户施加限制总是一个坏主意。

有时(很少)这是无法避免的,因此如果您这样做,请确保非常清楚地记录下来。

Well, it's dangerous. I'd try to avoid it when possible.

Your assumption is correct - the memory will not get released automatically.

The problem is that the return value here is memory allocated on the heap, the caller of your function has to remember to free. You're allocating memory here that will not (by you) get released. It's always a bad idea to put constraints on the user of your API.

Sometimes (rarely) this can't be avoided, so if you do this, make sure to document it very clearly.

小鸟爱天空丶 2024-08-28 05:47:11

这样做很常见。您只需在文档“API”中明确指出,调用者有责任在完成后释放返回的指针。

It's common to do this. You just have to clearly note in your documentation "API" that it is the caller's responsibility to free the returned pointer when finished.

黯淡〆 2024-08-28 05:47:11

这不是一个坏习惯。该函数返回一个malloc-ed(或calloc-ed)内存这一事实成为其外部规范的一部分。当不再需要它时,调用者有责任释放它。

虽然这很不优雅。这是不优雅的,因为它 1) 强制使用动态内存,而调用者可能更愿意避免它,并且 2) 强制使用特定种类的动态内存 - malloc-ed 之一,当调用者可能更喜欢使用自己的分配机制时。

It is not a bad practice. The fact that the function returns a malloc-ed (or calloc-ed) memory becomes a part of its external specification. It becomes a the caller's responsibility to free it when it is no longer necessary.

It is inelegant though. It is inelegant since it 1) forces the use of dynamic memory, when the caller might prefer to avoid it, and 2) forces the use a specific kind of dynamic memory - the malloc-ed one, when the caller might prefer to use its own allocation mechanism.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文