0

It's well known that new (/delete) and malloc(/free) don't mix. What was the reason to not make them compatible?

I understand that new and delete have two responsibilities: constructing and destructing in addition to allocating and deallocating so to make the question more accurate: Why aren't the ::operator new and ::operator delete functions required to call ::malloc and ::free respectively?

Forcing compatibility would at least allow reallocing of newed arrays of primitive (or rellocatable nonprimitive) types, which can carry noninsignificant performance benefits, and it would make things a little simpler for people who absolutely want to free newed memory (when destruction isn't required).

So what is the reason to break compatibility with malloc here?

Petr Skocik
  • 58,047
  • 6
  • 95
  • 142
  • 1
    They have different purposes. Have you read [this post](https://stackoverflow.com/questions/240212/what-is-the-difference-between-new-delete-and-malloc-free)? – Cory Kramer Mar 19 '16 at 15:55
  • 1
    Maybe one reason was to prevent people doing dangerous things like reallocating an array allocated with `new[]`. Also, calling `free()` on memory allocated with `new` would break the promise that destructors are called. – Jonathan Leffler Mar 19 '16 at 15:55
  • Unless `malloc` does the same thing `new` does I don't see how they can be freely mixed. – Galik Mar 19 '16 at 16:00
  • @JonathanLeffler I don't think the question is a duplicate. And I don't think reallocing new'ed arrays for rellocatable and primitive types would be a bad idea either -- it can offer sometimes significant speedups, and it's perfectly safe it the type is primitive (no dtor needed) or rellocatable (self contained and no absolute pointers to its own members). – Petr Skocik Mar 20 '16 at 13:41

0 Answers0