Using malloc in C++?

[desktop]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of new
does not give the same result.

 

[Jim Langston]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one should
instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of new
does not give the same result.

(Untested code)

class Foo
{
int MyInt;
std::string MyString;
};

int main()
{
Foo* Bar = new Foo;
Foo* Screwed = malloc( sizeof( Foo ) );
}

New will call the constructor for the std::string. malloc won't.

 

[Anonymous]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.

But why is that a problem?

The problem comes when you deal with object allocation, in C++, where
new not only allocates memory but also takes the constructor in hand.

I cannot see why using malloc instead of new
does not give the same result.

For better understanding go through this link :
http://wiki.answers.com/Q/What_is_the_difference_between_malloc_and_new_other_than_syntax


Regards,
ar

"There are things known and things unknown, in between are The Doors."

 

[Ian Collins]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of new
does not give the same result.

For a bucket of bytes or a C style struct, using malloc/free or
new/delete makes little or no difference. For objects with constructors
and/or destructors you have to use new/delete, so you may as well use
the same for all allocations.

 

[Torsten Mueller]

I have read in Bjarne Stroustrup that using malloc and free should
be avoided in C++ because they deal with uninitialized memory and
one should instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of
new does not give the same result.

This is a minor problem. The memory returned by new is also
uninitialized in a lot of cases.

Sure, new calls constructors and delete calls destructors while malloc
and free do not.

But there's another major reason for using new and delete: they are
much more portable while malloc/calloc/alloca/realloc/... are not. You
will normally never get a problem using new and delete, also on
different plattforms with different processors, because they
encapsulate all calls to the native malloc functions safely. These
operators belong to the language itself, not to the runtime library.
So you will normally not find includes of different headers and calls
to different allocation functions (both handled by conditional
compilation) and complicated casts for heap objects in strict C++
programs.

T.M.

 

[Gianni Mariani]

Jim Langston wrote:
....

class Foo
{
int MyInt;
std::string MyString;
};

int main()
{
Foo* Bar = new Foo;
Foo* Screwed = malloc( sizeof( Foo ) );
}

New will call the constructor for the std::string. malloc won't.

MyInt is still not initialized tho.

 

[Ian Collins]

But there's another major reason for using new and delete: they are
much more portable while malloc/calloc/alloca/realloc/... are not. You
will normally never get a problem using new and delete, also on
different plattforms with different processors, because they
encapsulate all calls to the native malloc functions safely. These
operators belong to the language itself, not to the runtime library.
So you will normally not find includes of different headers and calls
to different allocation functions (both handled by conditional
compilation) and complicated casts for heap objects in strict C++
programs.

I don't follow that paragraph, what isn't portable about the malloc
family of standard library functions?

 

[Gianni Mariani]

Ian Collins wrote:
....

I don't follow that paragraph, what isn't portable about the malloc
family of standard library functions?

I don't know if they have been fixed but the following usually caused
problems with different behaviour on different platforms.

free(0)
malloc(0)

 

[Ian Collins]

Ian Collins wrote:
....

I don't know if they have been fixed but the following usually caused
problems with different behaviour on different platforms.

free(0)

Specified as a NOP.

malloc(0)

Specified as far as you will either get a pointer to a block of >0 bytes
or NULL, just like any other size.

 

[Gianni Mariani]

Ian Collins wrote:
....

Specified as far as you will either get a pointer to a block of >0 bytes
or NULL, just like any other size.

That would be a problem then.

 

[Ian Collins]

Ian Collins wrote:
....

That would be a problem then.

Why? What ever you get from malloc, you can pass to free.

 

[Gianni Mariani]

Why? What ever you get from malloc, you can pass to free.

Different behaviour on different systems. If I write code that assumes
malloc(0) returns unique values and it returns 0 on some, it will break.

I'm not sure if that's the only one but it is a source of inconsistency
between platforms.

 

[Dizzy]

(Untested code)

class Foo
{
int MyInt;
std::string MyString;
};

int main()
{
Foo* Bar = new Foo;
Foo* Screwed = malloc( sizeof( Foo ) );
}

I know the code is untested but for the OP I will add that another problem I
have with malloc vs new is that malloc requires casting. You see in C++ you
don't have the C feature of void* implicitely casts to any* (only the
reverse still exists). Thus the code above doesn't compile and to make it
compile you actually need to make something like
Foo* Screwed = static_cast<Foo*>(malloc(sizeof(Foo)));

Clearly this is painful so better use "new". Not to mention malloc is error
prone because you may mistake the size of allocated memory (especially when
working on some other's people code) and you may allocate for another size
than the one for the type you need. While with new you have the "syntax
sugar" to just say I want an object of type T and everything is done
automatically (allocated memory to hold a sizeof(T), and returns a
converted T*).

 

[Andre Kostur]

Different behaviour on different systems. If I write code that
assumes malloc(0) returns unique values and it returns 0 on some, it
will break.

I'm not sure if that's the only one but it is a source of
inconsistency between platforms.

You need to check for the 0 anyway as that represents a failure to allocate
the memory. However you do end up with the indeterminate behaviour of "did
the memory allocation of 0 succeed, and I can continue to some sort of loop
(which will execute 0 times) and then free the pointer, or did it fail and
we need to do some sort of memory exhaustion error handling?", since the
malloc(0) could appear to be either case.

 

[Default User]

Different behaviour on different systems. If I write code that
assumes malloc(0) returns unique values and it returns 0 on some, it
will break.

I'm not sure if that's the only one but it is a source of
inconsistency between platforms.

It's ALWAYS possible that malloc() could return a null pointer.




Brian

 

[Default User]

I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.

But why is that a problem? I cannot see why using malloc instead of
new does not give the same result.

As the others have pointed out, new invokes the constructor for types
that have one. Reasons to always use new:

1. Somewhat friendlier syntax, as malloc() requires a cast unless the
results are assigned to a void*, and you usually do some arithmetic in
the size calculation. Examples:

int* arr = static_cast<int*>(malloc(5 * sizeof *arr));

int* arr = new int[5];

2. It gives a more consistent allocating scheme, so that you don't have
a mix of new and malloc(). Of course, one of the pitfalls of C++ is the
difference between new and new[], requiring delete or delete[]. There
is only one deallocation for malloc().

3. If you change your mind on a previously POD-type struct, you won't
have to find and change the malloc() calls.




Brian

 

[noone]

I don't follow that paragraph, what isn't portable about the malloc
family of standard library functions?

Time for me to open mouth...Insert foot...Yep, it fits...

But, if my assumption is correct, that new and delete can be
reimplemented (I think I read that somewhere), then yes, malloc and free
would seem less portable in a class hierarchy since they only work on
heap memory. Suppose new and delete are reimplemented to do weird stuff
like using a non-standard memory pool. Granted, I've never had a reason to
do such an esoteric mess but what then?

 

[Ian Collins]

Time for me to open mouth...Insert foot...Yep, it fits...

But, if my assumption is correct, that new and delete can be
reimplemented (I think I read that somewhere), then yes, malloc and free
would seem less portable in a class hierarchy since they only work on
heap memory. Suppose new and delete are reimplemented to do weird stuff
like using a non-standard memory pool. Granted, I've never had a reason to
do such an esoteric mess but what then?

Then the application that uses this non-standard memory pool isn't portable.

 

[Gianni Mariani]

Gianni Mariani wrote: ....
....

It's ALWAYS possible that malloc() could return a null pointer.

Yes. The inference being my code will now magically work ?

How does this not break code that assumes a non-failure case returns
non-null ?

 

[Default User]

Yes. The inference being my code will now magically work ?

How does this not break code that assumes a non-failure case returns
non-null ?

I don't understand the question. What results would you expect from
malloc(0)? Why would the implementation-defined nature make a
difference? Even when malloc(0) "succeeds", that is returns a non-null
pointer, you can't access the allocated memory. All you can do is
compare the pointer for equality or pass it to free().




Brian