Re: Just how dangerous is it to delete a void* ?
On May 31, 1:00 am, Bob Hairgrove <inva...@bigfoot.com> wrote:
{ Edits: double-spacing removed. -mod }
On Wed, 30 May 2007 14:49:01 CST, a...@student.open.ac.uk wrote:
I realise that to do a delete on a void pointer is to invite the
spectre of undefined behaviour (UB) into your program but just how
dangerous is it really?
Silly question ... UB is ALWAYS dangerous!
Heh... just because behavior isn't defined by ANSI c++, doesn't mean
it isn't defined. There aren't that many useful programs that don't
use compiler extensions of some sort. For that matter there are plenty
of c++ features that have been ratified by standards comities up the
ying yang for years and years that aren't implemented in most or any
compilers. Have you ever heard of the export keyword? Have you ever
tried using exception specifications in MSVC?
I think the original poster is essentially asking how malloc and new
are implemented on common compilers (effectively MSVC, and gcc).
The delete and delete[] operators do lots more than freeing the
allocated memory. In particular, the size of the element's type as
well as the number of allocated elements needs to be known when
invoking array delete;
nope.
char *ch = new char[50];
delete[] ch;
the number of elements isn't passed to delete... the underlying memory
management mechanism keeps track of that bit of bookkeeping.
Remember, free() *takes* a void *. You don't actually think there are
separate heaps for c++ andc memory allocation do you? The standard
*allows* for it, but common, that would cause a lot of complexity and
problems while gaining nothing. It ain't gonna happen.
For the most part, new wraps malloc. I'd check with your specific
compiler of course! But some googling suggests that most versions of
msvc and gcc do that.
all that information is lost when demoting a
pointer to void*. At the very least, one should cast the void* back
to the appropriate type before invoking delete[].
Again, I don't see the logic behind this. It sure looks a lot
prettier, and it's more standards compliant, but you aren't giving the
memory management implementation any more information...
It is generally accepted best practice to use std::vector<char>
instead of arrays of char; then there is never any issue with new and
delete.
no, std::vector<char> solves the dynamic sizing issue well... it
doesn't help if you fundamentally need to allocate some memory that's
going to outlive the current stack frame. At that point you need new,
or malloc.
What the original poster was really getting at, was whether a static
down cast would change the value of the returned pointer (which they
do in some cases). However, as far as I know the *only* instance where
this happens is in cases where multiple inheritance is involved.
Correct me if I'm wrong, but I don't think it even happens for single
inheritance. Maybe someone who knows the layout of the vtable in MSVC
and gcc (is there a different vtable layout in elf and mach-o btw?)
better than I could comment?
But, anyway, yeah, go ahead and leave it if it works and you don't
have to worry about types with multiple inheritance. But, it does look
ugly, and it will potentially refuse to compile if you try to port to
a compiler with different extensions/stricter standards compliance.
Heh, although the first is more likely than the latter.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]