Agreed. There's really no reason to use void* in C++ since we have templates.
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.
Last edited by King Mir; 12-20-2007 at 05:45 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
True. Not that it really matters.
Interesting question. I could point out how fragile a design that relies on this is, but that's not the point, is it?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.
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 :perator 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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Question.
If a feature has been made void, but there is no such type in C++ as void, does the feature really exist?
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
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.
Programmers that pedantically tear apart jokes should be virtually shot with the proverbial C/C++ gun.
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.
This is a non-sensical statement if referring to C.
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.
Oh, look. It even runs without crashing.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; }
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?Code:Hello world! a = 1 b = 1.62266e-307 c =
Technically yes, since most newbies in C tend to ignore those warnings and run the code anyway.
Sure it's legal, but that doesn't mean it's good.OK, so since this doesn't make the compiler barf, I guess it's legal C++ on a 32-bit Windows XP machine.
Oh, look. It even runs without crashing.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; }
Code:Hello world! a = 1 b = 1.62266e-307 c =
main doesn't have a prototype and doesn't use one, so you could basically define as whatever you want.
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.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?
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.