Re: Using malloc in C++?
On Jun 9, 9:41 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
Old Wolf wrote:
Firstly, new does not have a more strict definition.
malloc(0) has two options:
- return NULL
- return valid pointer
new T[0] has three options:
- throw exception
- return valid pointer
- return NULL, if T has a custom allocator (see 5.3.4/13)
So it seems to me that 'new' is LESS strictly specified than malloc.
I can provide my own malloc library as well that sings dixie (and there
are plenty of malloc alternatives). It seems your statement is
unsupportable.
ISO/IEC 9899:1999 7.20.3.3
[#3] The malloc function returns either a null
pointer or a pointer to the allocated space.
(The text for ISO/IEC 9899:1990, which C++ refers to,
is similar but I do not have an exact copy of it).
Secondly, strict definition doesn't mean more portable.
In fact, C and C++ specifications were deliberately
made as non-strict as possible, to _improve_ portability.
Portablility of what ? If the standard says that malloc(0)
behaves predominantlty like malloc(1) (which it appears it
does not), then the unfortunate case is that code will be
written that will not work on all platforms.
Then that code is non-portable, and the fault lies with
the programmer. I don't see why you treat this any
differently than code like:
try { char *ptr = new x[1000000]; }
catch(...) { explode_nuclear_weapon(); }
Works fine on my platform but someone else might have a
problem with it -- do we blame C++ for allowing the
programmer to write code that will not work on all platforms?
It's no coincidence that C is available on almost every
single platform that has anything other than assembly.
Do you infer here that the portability (or implementability) of the
compiler is somehow related to portability of application code ?
Yes (BTW, I imply, you infer). How portable is an
application that only runs on one platform? (for
example, a Visual Basic program).