C stdlib .h's on C++ and malloc/realloc

Question

I was really bothered by the inclusion of C stdlib functions on the global namespace and ended up writing things like ::snprintf or ::errno or struct ::stat, etc, to differentiate from some of my own functions in the enclosing namespace where those c stdlib functions were used.

Then I discovered that there is a way to declare every C stdlib function in the std namespace (as STL): just include < c(lib) > instead of < (lib).h > so I've edited my code the use those new "c for c++" includes.

On Debian/GCC 4.3.4 I had to 2 problems:

1) #error This file requires compiler and library support for the upcoming \ ISO C++ standard, C++0x. This support is currently experimental, and must be \ enabled with the -std=c++0x or -std=gnu++0x compiler options.

2) using -std=c++0x my program compiles just fine, but I have not modified ::snprintf or ::time, etc.. every C stdlib function is still on the global namespace =(! (no, I'm not using namespace std not even once)

Any thoughts?

For example.. how to stop the c stdlib from invading my global namespace? < c(lib) > is an experimental feature of the next C++ standard or could be used safely right now?

Then I've another doubt that perhaps deserves a new question.. there is no cmalloc. I know the whole history about new replacing malloc and why. but for simple plain byte buffers there is no c++ equivalent of realloc. I know that memory blocks and reallocation are implementation/so specific, but when there are contiguous free blocks of memory realloc works better than a new buffer allocation and memory copy.

Thanks =)!

Answer 1

For your first question, it depends on which headers you are trying to include. Most of the C headers are available in the c(lib) form in the existing version of C++. A few aren't, and may be added in C++0x. So if you tried to include any of those, you might have gotten that error.

Second, all the headers of this form guarantee that the functions will be made available in the std namespace. But they do not promise to leave the global namespace alone. Often, they put the symbols in both namespaces.

I'm not sure why ::snprintf bothers you more than std::snprintf though. You have to specify a prefix in both cases.

As for realloc, a C++ equivalent doesn't exist, probably because it's more trouble than it's worth, especially with C++'s more complicated semantics for copying objects. (In particular, if you try to use it, don't store any non-POD objects in the buffer, as realloc will just memcpy them to a newly allocated buffer if necessary, which will break non-POD objects.)

Of course, you can still use the old realloc from C by including its header. But I'd say you're probably better off using new/delete, and simply figuring out a sensible buffer allocation strategy.

Answer 2

c<lib>, which roughly encloses <lib>.h in a namespace std { }, is a standard feature of C++. See §17.4.1.2 if you have access to either standard.

This is not an experimental feature at all -- what header file is giving you the compatibility problems?

Using malloc et al. is fine, but be sure never to mix them with new/delete. (e.g. don't delete a malloc()'ed buffer.)

Answer 3

There are some of the standard C <lib.h> headers which are not yet transfered to <clib>. Probably you used <cstdint> or the like somewhere.

With the current standard you have the c libraries listed here. Note that <cstdint> is not part of it.

I didn't find a reference describing if and when <cstdint> will be part of c++, but if I try to include it, I also get an error message telling me I should use -std=c++0x, so I assume it is planned to be included in the next c++ standard.

Answer 4

The malloc() function, in standard C is not declared in the "<malloc.h>" header. It is declared in <stdlib.h>. Same for realloc() and free().

I don't know about C++, but instead of

#include <cmalloc>

try

#include <cstdlib>