Concat undefined number of strings

[dj51_Shura]

Thanks for your replyis, but, I always want a simply and fast function. Not buffers and not pointers. Just the strings you want to concatenate, that's all.

For example:

Code: Select all

FILE *tempfd;
tempfd = fopen(concat(path, ".temp", NULL), "w");
fclose(tempfd);

If the function needs buffers, yes, it can be more clear, but, not useful.

I really need to free the allocated memory before returning, because, if I don't do that, then a lot of memory will be wasted each time I call concat().

If somebody creates a function that detects the number of arguments in variable-arity-functions (something like va_num()...), all would be easier.

Codestation wrote:
(take strdup by example)

I have seen strdup()... it uses malloc or something like that? As I readed here, I also need to use free if I call strdup().

Well, thank you a lot for your suggestions and quick answers. I'm still thinking at it... xD

Advertising

[m0skit0]

Sorry for lateness...

It depends, one will need to calculate the lenght of all those strings beforehand everytime you need to call the function to allocate the required buffer or use one big enough to hold all of it. Also i din't see a problem with a function that does allocations by itself if it states clearly that the returned buffer must be freed (take strdup by example).

You're right. I guess it depends on taste then. But strdup is an exception: most C string manipulation function do need a buffer and they don't malloc() inside it. There'd be a reason why this is like this, don't you think? IMHO doing the malloc() and the free() on the same code entity avoid bugs and make the code clearer (e.g. you don't see a free() and go searching which function does the malloc() inside...). Also one should not be afraid of using malloc(), it's C coding style after all (that's why C is sometimes called high-level assembly xD).

Just calling snprintf(buffer, BUFFER_SIZE, "%s%s%s%s%s", str1, str2, str3, str4, str5); for doing multiple concats is more simpler when you think of it

And you do need a buffer, don't you?

I always want a simply and fast function. Not buffers and not pointers.

Pointers are actually faster and maybe they look complicated for you, but definitely they're not complicated, they're quite simple in fact.

If the function needs buffers, yes, it can be more clear, but, not useful.

That function need no buffers since you're just opening a file. Also the value returned is length-fixed. But fread() for example does need a buffer because you have to read an unknown size of data. Also a function can only return one value.

I really need to free the allocated memory before returning, because, if I don't do that, then a lot of memory will be wasted each time I call concat().

You cannot free the memory before returning because that would make you lose the string data. That's why I'm telling you you have to pass a buffer you allocated outside the function

Advertising