函数内部调用
看一下刚刚提出的这个问题:指向静态变量的指针的不便那么这样做会被认为是不好的做法吗?
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是不错的做法,但它很容易造成内存泄漏(调用者必须记住释放内存)。
我喜欢做的一件事是使用命名约定来指示可以分配哪些函数。例如,我将该函数命名为:
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:
在函数内部动态分配内存总是可以的,只要您向外界返回指向该内存的指针,以便其他东西可以释放它,或者您自己在函数内释放它。
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.
嗯,这很危险。我会尽可能避免它。
您的假设是正确的 - 内存不会自动释放。
问题是这里的返回值是在堆上分配的内存,函数的调用者必须记住释放内存。您在这里分配的内存不会(由您)释放。对 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.
这样做很常见。您只需在文档“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.
这不是一个坏习惯。该函数返回一个
malloc
-ed(或calloc
-ed)内存这一事实成为其外部规范的一部分。当不再需要它时,调用者有责任释放
它。虽然这很不优雅。这是不优雅的,因为它 1) 强制使用动态内存,而调用者可能更愿意避免它,并且 2) 强制使用特定种类的动态内存 -
malloc-ed 之一,当调用者可能更喜欢使用自己的分配机制时。
It is not a bad practice. The fact that the function returns a
malloc
-ed (orcalloc
-ed) memory becomes a part of its external specification. It becomes a the caller's responsibility tofree
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.