Pointer Declaration & Allocation

[Lamblion]

If I declare a global char pointer, like so:

char* szINIData;

and then want to allocate memory for it in a function, do I do it like this:

*szINIData=(char*)malloc( iLength );

or do I do it like this:

szINIData=(char*)malloc( iLength );

That is, with or without the star, i.e. pointer?

[modoran]

szINIData=(char*)malloc( iLength );

[Lamblion]

Much obliged.

[S G H]

You should use new and delete, instead of malloc and free:

/* Where first it was:
 char * szIniData = (char *)(malloc(iLength));
 free(szIniData);
 Now it is:
*/
 char * szIniData = new char[iLength];
 delete[] szIniData;

[Lamblion]

I'm willing to be corrected if I'm wrong, but it is my understanding that "new" actually calls "malloc()" and therefore accessing "malloc()" directly is a nanosecond faster.

I've never really understood why most everybody counsels to use "new", but I'm sure there's a reason.

[S G H]

We use new because it calls the correct constructor/destructor for the specified type.

Once you learn to use classes you will understand the problems that malloc/free will cause, mostly:
Non-initialized variables and Memory Leaks everywhere.

[freddie1]

Once you learn to use classes you will understand the problems that malloc/free will cause, mostly: Non-initialized variables and Memory Leaks everywhere.

Are you saying EssGeEich that the proper use of malloc() and free() on only non - class types like ints and char pointers will cause this? I can't say I've ever heard that before. If your point is though that one should not attempt to use these C Runtime functions on C++ classes I'd agree with that. Just asking???

[S G H]

Not exactly on built-in variables, but on classes, most times (if not all) you will suffer from memory leaks and uninitialized variables (thus eventual bad memory access) if you use something like std::string or std::vector or std::list.
Their presence in a class allocated with new is correct.
If their class is allocated with malloc, they will fail 99% of times.

But it's better to begin to get used to write new/delete instead of malloc/free even with builtin variables. Being consistent is a good thing.

[kbw]

Just say no, don't use malloc/free in C++.

http://www.cplusplus.com/forum/general/88709/#msg476135

EDIT: And try to avoid global variables too.

[freddie1]

OK. Not disagreeing. Just wanted further clarification. Your original statement could easily have been interpreted to mean malloc/free in the C Runtime Library was broken.

[Disch]

+1 @ kbw. malloc/free have no place in C++, unless you're handing off ownership of allocated memory to a C library (in which case I recommend finding a library that doesn't require passing ownership of memory back and forth).

[kbw]

Just wanted further clarification.

I meant, don't it at all; really.

C++ provides language support for a number of really useful constructs. The language can guarantee initialisation/cleanup of abstract data types, do deep copies of complicated data structures, you can create your own types that are first class types and integrate with I/O, other types ... pretty much all the stuff the I longed for in C, but needed practices to make sure they were done.

C++ can help you, but it has ways of doing things, and you need to appreciate how it does it's thing to really use it effectively. In the end, you're just helping yourself and your users.