Weird thinking and delete operator

Hello all,

I have to admit, that the idea that occurred to me recently is weird.
It was somehow inspired by the huge response on the "delete operator"
thread, but goes into a somewhat different direction.

From my understanding there are 2 "ways" of handling memory:
-- one (from C) is the malloc/realloc/free set of API functions
-- the other one (from C++) is the new/new[]/delete/delete[] set of
API functions.

However, since C++ is somewhat based on C (though not exactly C with
object orientation), you can use both in a C++ program. Right?

Now, since the above mentioned thread circled very much on the
question whether I can delete an array with or without brackets (usind
delete or delete[]) it came to my mind, that one might accidentally or
intentedly mix up new and free. Since free always tries to free the
entire memory block pointed to by it's parameter, it might actually do
what was intended with delete[], though probably missing out on
calling the appropriate destructors, which delete[] would have done.
(thus highly inappropriate when pointing to complex classes,
containing types that require destructors to be deallocated
appropriately)

My point is, that I might at some point end up somewhere, where I do
not know wheter my pointer is pointing to an array or a simple type
(e.g. if a function accepts void pointers to different types). Well,
if I use free to free up the used memory, it doesn't matter. Right?

In my concrete situation, I have a void pointer pointing to either a
long, a double or a TCHAR (other datatypes might be added later).
Unfortunately, this pointer is allocated down in a library of mine and
thus I need to provide a library-function to free this
pointer.(Haven't yet figured out how to have memory allocated in a DLL
free-able in the application using the DLL - maybe someone can answer
this question on the side.). In my first attempt, I've started
allocating memory with "pvValue = new long" (for example) and used
"delete pvValue;" in my other library-function (for deallocating the
memory). I think that this way I might fail to properly handle the
memory in case I am pointing to a TCHAR!
Thus I'm currently thinking about falling back to malloc/free set of
functions and along that path came to the thought of mixing up new and
free.

Does anybody know what would happen?

Alas, I'm afraid this topic got me a bit confused. However any input
of yours is highly appreciated!

Bye,
regards,
Carsten.

"Pelle" <pelle1911@gmx.de> wrote in message news:2c2c85c5.0309180637.4d6a41bf@posting.google.c om...
[color=blue]
> Thus I'm currently thinking about falling back to malloc/free set of
> functions and along that path came to the thought of mixing up new and
> free.
>
> Does anybody know what would happen?
>[/color]
Freeing stuff not Malloc'd and deleting stuff not new'd is undefined behavior.
Don't do that.

malloc has a number of problems for C++ (which is why new exists). It
doesn't properly construct the object. It's not type safe.
[color=blue]
> In my concrete situation, I have a void pointer pointing to either a
> long, a double or a TCHAR (other datatypes might be added later).[/color]

This sounds like a rather bogus C++ design. You sould always simulate
malloc with:
void* FakeMalloc(size_t n) { return new char[n]; }
void FakeFree(void* p) { delete (char*) p; }

As for DLL's, that's really machine specific. But the answer to that issue
is probably the same to the real answer to your problem. Provide a function
in your library that's complementary to what allocates the poihnter to delete
it. Nice and symetrical.