how to delete void* pointer

Hello,
is it possible to delete a void pointer, without explicitly typecasting it? I know the size of the memory to free, but not the type of the pointer. Example with typecasting:

Code:

---

int main(){
  void* ptr;
  ptr = new int(7);
  delete static_cast<int>(ptr);
}

---

If you don't know the type, you're screwed. There is no valid way of freeing a pointer except through its original type (or a base class if you have a virtual destructor).

Thanks for your answer, although it is not possible.

>I know the size of the memory to free, but not the type of the pointer.
There's more to delete than freeing memory, and the type of the pointer has to be known. If you're only going to be working with raw memory, you might consider using malloc and free instead of new and delete:

Code:

---

#include <cstdlib>

int main()
{
  void *ptr = std::malloc ( 7 * sizeof ( int ) );
 
  //...

  std::free ( ptr );
}

---

I'm 99% sure that you can delete any pointer [although in this case, you should use delete [], as you create an array in the new int[7] call].

The size of the object allocated is held internally in the heap, so there should be on problem with that.

--
Mats

>I'm 99% sure that you can delete any pointer
I'm 100% sure that if the static type of the pointer being deleted is void, you've invoked undefined behavior. ;)

Maybe a better question is, why are you creating a void* pointer to begin with instead of specifying the actual type?

Oh sure, you can delete a void* pointer and on MSVC it generally works fine so long as it's raw memory or built-in types. But when you start deleting void* pointers to classes, you get problems.
I'm kind of betting it's undefined behavior. But in C++ this is very easy to avoid - simple use templates!

Quote:

---

Oh sure, you can delete a void* pointer and on MSVC it generally works fine so long as it's raw memory or built-in types. But when you start deleting void* pointers to classes, you get problems.

---

From the 2003 edition of the C++ Standard, section 5.3.5:

Quote:

---

In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

---

The footnote to the above paragraph reads:

Quote:

---

This implies that an object cannot be deleted using a pointer of type void* because there are no objects of type void.

---

Quote:

---

I'm kind of betting it's undefined behavior.

---

You get nothing from winning the bet since Prelude already stated she was 100% sure of it... not believing Prelude in such things is just plain stupid :p

I feel like throwing a temper tantrum, because I said it first: "no valid way" :p

Wouldn't it be possible to call ::operator delete(), assuming that the memory is POD, or has been properly destroyed before hand?

Quote:

---

Originally Posted by King Mir

Wouldn't it be possible to call ::operator delete(), assuming that the memory is POD, or has been properly destroyed before hand?

---

That would be the same thing as calling delete or delete [] - that is what it does "behind the scenes".

Given that it's "undefined", I would agree with the "use malloc/free" advice given above. Or just use a non-void pointer in the first place - it is really very rare that there is a valid reason to create a void * - you may convert something to a void pointer later, but you need to convert the void pointer to something else ANYWAYS to use it for anything [other than generic memory functions, reading/writing to files etc of course].

This is another case where the original poster probably needs to provide a bit more info about what the actual problem - this is a typical "I need help taking the wheelnuts out", when the actual problem is a punctured tyre [and the "right" solution may even be to squirt in some "gunk" to seal and inflate the tyre, rather than put on a spare wheel].

--
Mats

Quote:

---

Originally Posted by matsp

That would be the same thing as calling delete or delete [] - that is what it does "behind the scenes".

---

Except that ::operator delete takes a void pointer (at least when it's overloaded). A call to ::operator delete() does not pass any information about the type of the pointer to the operation. So the fact that you cannot call "delete voidPtr" does not preclude calling "::delete(voidPtr). Indeed, that often what a class specific overload of delete would do.

Furthermore, operator delete can called outside of a delete call in an implementation of an STL compatible allocator. That allocator again does not pass any type information to ::operator delete().

You have to deallocate with the operation that matches the allocation operation. When you allocate with new, you have to deallocate with delete. You have to match new[] with delete[]. You have to match malloc() with free(). And you have to match operator new with operator delete. Everything else is always undefined behaviour.

In other words: if using ::operator delete() on the void* works on your platform for PODs, delete or delete[] will probably work just as well. Doesn't change the fact that both are undefined behaviour.

The allocator objects used in the STL still follow this guideline. std::allocator uses ::operator new and ::operator delete to allocate and deallocate memory, then uses placement new and explicit destructor calls for construction and destruction.

In any case, if you have a void* pointer and you don't know what type it is, you either shouldn't be the one deleting it, or you should have kept track of the original type.

Agreed. There's really no reason to use void* in C++ since we have templates.

Quote:

---

Originally Posted by CornedBee

You have to deallocate with the operation that matches the allocation operation. When you allocate with new, you have to deallocate with delete. You have to match new[] with delete[]. You have to match malloc() with free(). And you have to match operator new with operator delete. Everything else is always undefined behaviour.

In other words: if using ::operator delete() on the void* works on your platform for PODs, delete or delete[] will probably work just as well. Doesn't change the fact that both are undefined behaviour.

The allocator objects used in the STL still follow this guideline. std::allocator uses ::operator new and ::operator delete to allocate and deallocate memory, then uses placement new and explicit destructor calls for construction and destruction.

---

Ok, so you use ::operator new(size_t x) to allocate, and ::operator delete( void *ptr) to deallocate. There's still no reason to go back to using malloc and free.

Also, I'm curious, do you happen to have a link that will explicitly corroborate the claim that something allocated by new cannot be deleted using a combination of a direct destructor calls and operator delete? Not just something that sais that new must match delete, but something that explicitly mentions direct calls to operators new and delete. Cause from a language design point of view, there is no reason to disallow that kind of behavior.

Quote:

---

Originally Posted by CornedBee

You have to deallocate with the operation that matches the allocation operation.

---

Which is the critical insight on this whole problem. If you could do this:

Code:

---

void *x;
delete x;

---

That would necessarily imply that you had allocated x like this:

Code:

---

x = new void;

---

Which is obviously meaningless.

Quote:

---

Originally Posted by Elysia

Agreed. There's really no reason to use void* in C++ since we have templates.

---

You really like throwing out items from languages that you personally don't use, don't you?

Quote:

---

Originally Posted by King Mir

Ok, so you use ::operator new(size_t x) to allocate, and ::operator delete( void *ptr) to deallocate. There's still no reason to go back to using malloc and free.

---

True. Not that it really matters.

Quote:

---

Also, I'm curious, do you happen to have a link that will explicitly corroborate the claim that something allocated by new cannot be deleted using a combination of a direct destructor calls and operator delete? Not just something that sais that new must match delete, but something that explicitly mentions direct calls to operators new and delete. Cause from a language design point of view, there is no reason to disallow that kind of behavior.

---

Interesting question. I could point out how fragile a design that relies on this is, but that's not the point, is it?

You can't do it without knowing the type, anyway. How would you call the destructor?

I can't find anything that really says you can't do it for single objects. The standard is actually pretty explicit in describing not just the effects, but what is actually done. First, the destructor is called, then the deallocation function is called. Which is ::operator delete for primitives. For non-primitives, it may be a custom deallocation function, so you'd have to be very careful there.

For arrays, I lack the hard evidence to back me up, but I'm quite sure that the trick would fail on MS compilers. The reason is this: the compiler stores the length of the array before its start and overallocates to hold the count. Which means that the address returned by the allocation function (which is the one you must pass to the deallocation function) isn't necessarily the same as the address returned by the new operator (the one you actually have). Because there is no way you can reliably know the implementation-specific offset between those two addresses, you can't portably call the deallocation function yourself.

Quote:

---

Originally Posted by MacGyver

You really like throwing out items from languages that you personally don't use, don't you?

---

I have to admit there's not much use for void* in C++. Even in C, the only benefit of void* was that any pointer type could automatically convert from/to void* without a cast. In C++ this feature has been removed, which renders the whole point of void*, well... "void."

Question.

If a feature has been made void, but there is no such type in C++ as void, does the feature really exist? :D

Quote:

---

Originally Posted by MacGyver

Question.

If a feature has been made void, but there is no such type in C++ as void, does the feature really exist? :D

---

Actually void is a type in C++. It just can't be instantiated or referenced. You can pass void as a template parameter, for example.

Quote:

---

Originally Posted by MacGyver

You really like throwing out items from languages that you personally don't use, don't you?

---

I like to avoid things that usually have little use and usually invokes undefined behavior and removes type safety and checking. Remember, I'm a C++ dev, and I do so loathe C's behavior of allow the most of absurd things like calling a function without a prototype, to pass in a non-pointer where a pointer is required, etc.

It wouldn't surprise me if you could actually dereference or get the type type of a void* pointer.

Quote:

---

Originally Posted by King Mir

Actually void is a type in C++. It just can't be instantiated or referenced. You can pass void as a template parameter, for example.

---

Programmers that pedantically tear apart jokes should be virtually shot with the proverbial C/C++ gun. :D

Quote:

---

Originally Posted by Elysia

I like to avoid things that usually have little use and usually invokes undefined behavior and removes type safety and checking. Remember, I'm a C++ dev, and I do so loathe C's behavior of allow the most of absurd things like calling a function without a prototype, to pass in a non-pointer where a pointer is required, etc.

---

C99 doesn't allow you to use a function without a prototype afaik. I have no idea what you mean by saying that you can "pass in a non-pointer where a pointer is required". For my own amusement, I wish you had provided more details.

Quote:

---

Originally Posted by Elysia

It wouldn't surprise me if you could actually dereference or get the type type of a void* pointer.

---

This is a non-sensical statement if referring to C.

Quote:

---

Originally Posted by MacGyver

C99 doesn't allow you to use a function without a prototype afaik. I have no idea what you mean by saying that you can "pass in a non-pointer where a pointer is required". For my own amusement, I wish you had provided more details.

---

Sure, consider:

Code:

---

void foo(int* n)
{
        *n = 70;
}

int main()
{
        int n = 0;
        foo(n); /* Legal in C! */
        return 0;
}

---

Quote:

---

This is a non-sensical statement if referring to C.

---

I always refer to C with such things - it's illegal in C++, so what else could it be?

Quote:

---

Originally Posted by Elysia

Sure, consider:

Code:

---

void foo(int* n)
{
        *n = 70;
}

int main()
{
        int n = 0;
        foo(n); /* Legal in C! */
        return 0;
}

---

---

Code:

---

: In function `main':
:9: warning: passing arg 1 of `foo' makes pointer from integer without a cast

---

Try again.

Quote:

---

Originally Posted by Elysia

I always refer to C with such things - it's illegal in C++, so what else could it be?

---

This just displays your ignorance of C.

Quote:

---

Originally Posted by MacGyver

Code:

---

: In function `main':
:9: warning: passing arg 1 of `foo' makes pointer from integer without a cast

---

Try again.

---

Yes, that's a WARNING, but not a compile ERROR, is it? Then it compiles fine and runs.

Quote:

---

This just displays your ignorance of C.

---

Well, forgive me for not liking C!

Quote:

---

Originally Posted by Elysia

Yes, that's a WARNING, but not a compile ERROR, is it? Then it compiles fine and runs.

---

Oh my. So everything that generates a warning instead of an error is considered legal C?

OK, so since this doesn't make the compiler barf, I guess it's legal C++ on a 32-bit Windows XP machine.

Code:

---

#include <iostream>

int main(int a, double b, char c)
{
        std::cout << "Hello world!" << std::endl;
        std::cout << "a = " << a << std::endl;
        std::cout << "b = " << b << std::endl;
        std::cout << "c = " << c << std::endl;
       
        return 0;
}

---

Oh, look. It even runs without crashing.

Code:

---

Hello world!
a = 1
b = 1.62266e-307
c =

---

Quote:

---

Originally Posted by Elysia

Well, forgive me for not liking C!

---

This has nothing to do with liking C, and I wouldn't demand it of you. I just hate blatant ignorance mingled with silly statements. Do you really think C allows for undefined behavior in dereferencing void pointers or were you just making it up to emphasize your disdain for the language?

Quote:

---

Originally Posted by MacGyver

Oh my. So everything that generates a warning instead of an error is considered legal C?

---

Technically yes, since most newbies in C tend to ignore those warnings and run the code anyway.

Quote:

---

OK, so since this doesn't make the compiler barf, I guess it's legal C++ on a 32-bit Windows XP machine.

Code:

---

#include <iostream>

int main(int a, double b, char c)
{
        std::cout << "Hello world!" << std::endl;
        std::cout << "a = " << a << std::endl;
        std::cout << "b = " << b << std::endl;
        std::cout << "c = " << c << std::endl;
       
        return 0;
}

---

Oh, look. It even runs without crashing.

Code:

---

Hello world!
a = 1
b = 1.62266e-307
c =

---

---

Sure it's legal, but that doesn't mean it's good.
main doesn't have a prototype and doesn't use one, so you could basically define as whatever you want.

Quote:

---

Do you really think C allows for undefined behavior in dereferencing void pointers or were you just making it up to emphasize your disdain for the language?

---

I wouldn't know if it would allow or not, but since it allows silly things like passing a non-pointer to where a pointer is expected, do you really think I think of C as safe? Passing a non-pointer where a pointer is expected - crash right away and it's so easy to do it, rather than in C++, where you'd get a compile error.

And even though void is undefined, the compiler could just assume you're dereferencing int*, just as it assumes every function returns int if it has no prototype.

I didn't try - no, I admit that, and I also admit that I didn't know, but I wouldn't be surprised if it WAS allowed. Whether it is or not, is an entirely different question.

Quote:

---

Originally Posted by MacGyver

Code:

---

: In function `main':
:9: warning: passing arg 1 of `foo' makes pointer from integer without a cast

---

Try again.

---

Actually, that's just GCC being stupidly compatible with stupid programs. MSVC ought to fail to compile this.

It (MSVC) doesn't. It spits out two warnings, but it compiles nevertheless.

More stupid compilers. :(

I know that it's not valid C without a cast.

Quote:

---

Originally Posted by CornedBee

More stupid compilers. :(

I know that it's not valid C without a cast.

---

And with warnings enabled [or if you use gcc, -Werror] it will complain.

The fact that beginners don't enable warnings, or ignore warnings is for them to learn from - and usually it's VERY obvious when you got it wrong anyways.

Yes, C++ offers more strict type checking, but all decent compilers allow you to get warnings in C when you do that thing [even Turbo C supports a large number of warnings in this area].

If you ignore the warnings, then that's not the fault of language, is it? The language[1] has enough information in place to check types if the code is correctly written, and the compiler is able to tell if it's not got a prototype for a function. If so, it will give a warning.

[1] Assuming we are talking ANSI C, rather than original K&R C.

--
Mats

Just want to throw an FYI out there....

If you want to test a snippet of code using a *very* standards compliant compiler, then check out Comeau's online compiler here: http://www.comeaucomputing.com/tryitout/

gg

Quote:

---

Originally Posted by Codeplug

Just want to throw an FYI out there....

If you want to test a snippet of code using a *very* standards compliant compiler, then check out Comeau's online compiler here: http://www.comeaucomputing.com/tryitout/

gg

---

Wow, what an ugly website!
If they're trying to sell their compiler, they should hire a good web designer to make the site look a little more professional. Otherwise, you see a crappy website and you automatically assume they have a crappy product too. :p

Hehe, nice analogy.

>If they're trying to sell their compiler, they should hire a good
>web designer to make the site look a little more professional.
When your product is as high quality as Comeau, you don't need to "make the sale" with pretty pictures and layouts. Rather, they should make it more convenient to buy the damn thing. :P

Quote:

---

Originally Posted by CornedBee

More stupid compilers. :(

I know that it's not valid C without a cast.

---

There's a lot of "invalid" C out there. If compilers refused to compile it, people would move to other compilers rather than fix their code. Just how it is...

Quote:

---

Originally Posted by brewbuck

There's a lot of "invalid" C out there. If compilers refused to compile it, people would move to other compilers rather than fix their code. Just how it is...

---

This is particularly true if the source code has "lived" for a long time, and portions [quite possibly CRITICAL or major functionality portions] haven't been changed for many, many years - if the code still works, then there's probably no reason for anyone to go through and update it, just because some compiler throws a few warnings.

As hobbyists, we often think of "old code" as easily replacable, but if the code is working, has been tested by you, your QA-team, your customers, and is known to be bug-free and work as the customers want it to work, then there is no good reason for a manager to approve a project of 6 months to rewrite the code to compile without warnings in the latest compiler, with no other benefit - and a risk that the changes actually break something. Have you never rewritten a function just a little bit, and found that for most parts, it works exactly like before, but you missed some subtle part that makes the new function fail or behave differently in some very special case? "If it ain't broke, don't attempt to fix it!"

The company I work for have sold the software to go into many millions of devices. If you change anything, you risk producing a bug - and if that's a "rare" bug, you may end up with a recall of our customers product from their customers, with a HUGE expense of all their customers updating the software. So we only really change things that one of our customers ask us to change!

--
Mats

Quote:

---

Originally Posted by Elysia

Technically yes, since most newbies in C tend to ignore those warnings and run the code anyway.

---

There's no "technically" in here. Newbies don't define a language. The standard defines the language. Warnings are there for a reason, because many C compilers allow you to do all kinds of things against the language standard in order to allow people to cut corners and write programs to utilize non-portable features. Is it smart? I don't think so. I don't like it. I don't think it's a good thing to do. Nevertheless, I know I've seen code in industry that looks like garbage in the sense that it mixes C and C++. Does it "work for them"? Yes. Is it legal? No.

Quote:

---

Originally Posted by Elysia

Sure it's legal, but that doesn't mean it's good.
main doesn't have a prototype and doesn't use one, so you could basically define as whatever you want.

---

Oh really? Let's try void main() in C++ with MinGW:

Code:

---

: error: `main' must return `int'
: error: return type for `main' changed to `int'

---

Guess I can't define main() to anything.

Quote:

---

Originally Posted by Elysia

I wouldn't know if it would allow or not, but since it allows silly things like passing a non-pointer to where a pointer is expected, do you really think I think of C as safe?

---

It does NOT allow passing wrong arguments. The C standard is the C standard. If you violate the C standard and say it's valid C because your compiler allows you to do it, you're an idiot. You're even worse than just being just plain dumb if you ignore the warnings that tell you something is wrong. Just because your compiler allows something ridiculously stupid does not mean it's valid C.

What you appear to be displaying is a "works-for-me" type of mentality which is just begging to run into undefined behavior, regardless of whether you use C or C++.

Quote:

---

Originally Posted by Elysia

Passing a non-pointer where a pointer is expected - crash right away and it's so easy to do it, rather than in C++, where you'd get a compile error.

---

So C++ is a superior language simply because Stroustrup turned up the warning level in the compiler like any good C programmer would? It's something I would do should I ever write a C compiler, tbh. Compliance mode first and foremost by default.

Quote:

---

Originally Posted by Elysia

And even though void is undefined, the compiler could just assume you're dereferencing int*, just as it assumes every function returns int if it has no prototype.

---

Only in your imagination. C doesn't do this.

Quote:

---

Originally Posted by Elysia

I didn't try - no, I admit that, and I also admit that I didn't know, but I wouldn't be surprised if it WAS allowed. Whether it is or not, is an entirely different question.

---

And your lack of surprise at such an event is demonstrative of your blind dislike of C out of your hard-held belief that C++ is the language. You are welcome to any opinion, naturally, and frankly, I'm not so sure I would even want to sway you to the C side. What I would like is for you to stop the needless and ridiculous C bashing, especially for baseless and rather absurd allegations of the sort that you have either directly and indirectly charged in this topic. Kindly refrain from discussing imagined features of C and C++ as a way to further your cause. ;)

Quote:

---

Originally Posted by MacGyver

Kindly refrain from discussing imagined features of C and C++ as a way to further your cause. ;)

---

There's no need... I don't enjoy this sort of arguing.

Quote:

---

Originally Posted by Elysia

There's no need... I don't enjoy this sort of arguing.

---

Don't take this the wrong way [usual way of starting a sentence that will sound somewhat offensive :)], but you do seem to occassionally get into this sort of arguing - whether it's on purpose or not, and whether you enjoy it or not. I chalked that down to "not old and wise enough" Now, I can't use that exceuse, _I_ probably SHOULD know better! ;)

--
Mats

Quote:

---

Originally Posted by matsp

Don't take this the wrong way [usual way of starting a sentence that will sound somewhat offensive :)], but you do seem to occassionally get into this sort of arguing - whether it's on purpose or not, and whether you enjoy it or not. I chalked that down to "not old and wise enough" Now, I can't use that exceuse, _I_ probably SHOULD know better! ;)

--
Mats

---

Sure, it's natural that we get into arguments sometimes.
When it's something I enjoy debating over, of course, I continue.
When I don't enjoy it, I back out.
And when it seems that the arguing is doing more damage than good, I back out.

Quote:

---

Originally Posted by brewbuck

There's a lot of "invalid" C out there. If compilers refused to compile it, people would move to other compilers rather than fix their code. Just how it is...

---

True. The stupid part is where gcc will compile it even under -ansi -pedantic. Ha! I've seen far less serious stuff fail under -pedantic.