fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>   Is there any good reason
> why C++ needs *two* low-level dynamic memory allocation mechanisms?

Well, malloc/free/realloc exists for compatibility with standard C
libraries; that compatibility being a big reason so many folk are
migrating to C++ instead of (say) Eiffel.

And new/delete can support a runtime feature that is implemented in some
systems:  the allocated memory can include information used to safely
deallocate it.  That is, a header might include things like a pointer to
the destructor and the number of elements in the block of memory.
--
David Brownell                        db@Eng.Sun.COM.
Distributed Object Management

In comp.lang.c++, cpcahil@vti.com (Conor P. Cahill) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>> cleelacj@agedwards.com (Chris Cleeland) writes:
>>
>> >  I have a program which I believe to have some sort of memory leak.
>> >  However, since we are also in C++, malloc() is not always used; as
>> >a matter of fact, the "new" operator is used almost exclusively.  Since
>>
>> How about overriding the definition of operator new and delete to call
>> malloc and free respectively? The language allows you to provide
>
>I haven't seen an implementation of new/delete that didn't use malloc/free
>as the underpinning yet.   This isn't to say that there isn't one,
>just that most vendors don't think it is worth the effort to re-invent
>the wheel that nobody sees.

Yes, this is my experience also. Which raises the question:

What is the rationale behind the prohibition from calling free() on something
allocated with operator new() or calling operator delete() on something
allocated with malloc()? It would be nice if programmers didn't have to
keep track of which method was used to allocate each different piece of
data. Given that all the code works with all known existing implementations,
and that no known compilers actually detect violations of this constraint,
wouldn't it be better if the standard did not include such a constraint?

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!

In article <9319513.17723@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>What is the rationale behind the prohibition from calling free() on something
>allocated with operator new() or calling operator delete() on something
>allocated with malloc()? It would be nice if programmers didn't have to
>keep track of which method was used to allocate each different piece of
>data. Given that all the code works with all known existing implementations,
>and that no known compilers actually detect violations of this constraint,
>wouldn't it be better if the standard did not include such a constraint?
simple...
malloc won't call constructors, delete won't call destructors...

my advice:
Only use new and delete in C++...
Even better advice:
Only use "new object[1]", and "delete []" in C++... (this gets around
the problem of having to keep track of whether the pointer points to a
singleton or an array, and then calling the appropriate delete operator)

Cheers.
Andrew
--
-------------------------------------------------------------------------------
Andrew Walduck, MPR Canada, walduck@mprgate.mpr.ca, My Views...Not MPR's
-------------------------------------------------------------------------------

In article <1993Jul14.045213.21835@mprgate.mpr.ca> walduck@mpr.ca (Andrew Walduck) writes:

 >my advice:
 >Only use new and delete in C++...
 >Even better advice:
 >Only use "new object[1]", and "delete []" in C++... (this gets around
 >the problem of having to keep track of whether the pointer points to a
 >singleton or an array, and then calling the appropriate delete operator)

Except you can't pass arguements to Ctors for array objects.
 Ab.
--
+-------------------------------------+--------------------------+
| Disclaimer:                         | Strange but true:        |
| ``It was not me, it                 | "Virginia Bottomley" is  |
|   was the other three''             | an anagram for:          |
|     --- Rick (The Young Ones: Nasty)| "I'm an evil Tory bigot".|
+-------------------------------------+--------------------------+
| Ab Wilson <naw@planet.bt.co.uk>     | The Object Design Co Ltd |
+-------------------------------------+--------------------------+
GCS/MU d--- p-- c+ l m- s+++/- !g w+++ t r- x++

>Yes, this is my experience also. Which raises the question:
>
>What is the rationale behind the prohibition from calling free() on something
>allocated with operator new() or calling operator delete() on something
>allocated with malloc()?
> ...
>--
>Fergus Henderson                     This .signature virus might be
>fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
>                                     consistently believe it unless you
>Linux: Choice of a GNU Generation    copy it to your own .signature file!

 I think we have to operate under the premise that operator new
encapsulates malloc() and free(). Under that premise, we don't know what
really happens, what functionality 'operator new' contains or what
additional information it may keep. If we call free() on an instance
created through 'new', we break that 'encapsulation' and may leave some
loose ends that will haunt us later. I have not seen any 'operator new'
code do this, but I believe the potential is there.

--
Michael Aichlmayr
Department of {chaos != anarchy ? order : entropy}, Genasys II, Inc.

< From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
<
< In comp.lang.c++, cpcahil@vti.com (Conor P. Cahill) writes:
<< I haven't seen an implementation of new/delete that didn't use
<< malloc/free as the underpinning yet.   This isn't to say that there isn't
<< one, just that most vendors don't think it is worth the effort to
<< re-invent the wheel that nobody sees.

That doesn't mean that they don't exist. I have seen several such
implementations.

< Yes, this is my experience also. Which raises the question:
<
< What is the rationale behind the prohibition from calling free() on
< something allocated with operator new() or calling operator delete() on
< something allocated with malloc()? It would be nice if programmers didn't
< have to keep track of which method was used to allocate each different
< piece of data. Given that all the code works with all known existing
< implementations, and that no known compilers actually detect violations of
< this constraint, wouldn't it be better if the standard did not include
< such a constraint?

A couple of problems with this; there are certainly others as well.

    o Calling free() won't invoke the destructor.

    o Calling

     class X { ... };
     x = new X[10];
     free(x);

 will dump core or its moral equivalent with several existing compilers.

     Tony Hansen
       hansen@pegasus.att.com, tony@attmail.com
    att!pegasus!hansen, attmail!tony

In article <CA6M1p.n39@cbnewsk.cb.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes:

 >< What is the rationale behind the prohibition from calling free() on
 >< something allocated with operator new() or calling operator delete() on
 >< something allocated with malloc()? It would be nice if programmers didn't
 >< have to keep track of which method was used to allocate each different
 >< piece of data. Given that all the code works with all known existing
 >< implementations, and that no known compilers actually detect violations of
 >< this constraint, wouldn't it be better if the standard did not include
 >< such a constraint?

Wouldn't it be better if you only used new/delete and then you
wouldn't have to remeber which method you used to get the storage in
the first place.
 Ab.
--
+-------------------------------------+--------------------------+
| Disclaimer:                         | Strange but true:        |
| ``It was not me, it                 | "Virginia Bottomley" is  |
|   was the other three''             | an anagram for:          |
|     --- Rick (The Young Ones: Nasty)| "I'm an evil Tory bigot".|
+-------------------------------------+--------------------------+
| Ab Wilson <naw@planet.bt.co.uk>     | The Object Design Co Ltd |
+-------------------------------------+--------------------------+
GCS/MU d--- p-- c+ l m- s+++/- !g w+++ t r- x++

hansen@pegasus.att.com (Tony L. Hansen) writes:

>< From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
><
>< In comp.lang.c++, cpcahil@vti.com (Conor P. Cahill) writes:
><< I haven't seen an implementation of new/delete that didn't use
><< malloc/free as the underpinning yet.   This isn't to say that there isn't
><< one, just that most vendors don't think it is worth the effort to
><< re-invent the wheel that nobody sees.
>
>That doesn't mean that they don't exist. I have seen several such
>implementations.

In what way were they different? Did they provide additional functionality?
Or were they just a different implementation of essentially the same
functionality? (And if so, what was the purpose of re-inventing the wheel?)

>< Yes, this is my experience also. Which raises the question:
><
>< What is the rationale behind the prohibition from calling free() on
>< something allocated with operator new() or calling operator delete() on
>< something allocated with malloc()? It would be nice if programmers didn't
>< have to keep track of which method was used to allocate each different
>< piece of data. Given that all the code works with all known existing
>< implementations, and that no known compilers actually detect violations of
>< this constraint, wouldn't it be better if the standard did not include
>< such a constraint?
>
>A couple of problems with this; there are certainly others as well.
>
>    o Calling free() won't invoke the destructor.

Sorry, I should have made it more clear that I meant the _functions_
operator new() and operator delete(), not the new and delete _operators_.
Calling the _function_ operator delete() won't invoke the destructor either.

>    o Calling
>
>     class X { ... };
>     x = new X[10];
>     free(x);
>
> will dump core or its moral equivalent with several existing compilers.

Again, so will calling
     class X { ... };
     x = new X[10];
     operator delete(x);

There's a clear difference between the new/delete operators and malloc()/free(),
but there does not seem to be much difference between the operator new()/
operator delete() functions and malloc()/free(). Is there any good reason
why C++ needs *two* low-level dynamic memory allocation mechanisms?

(I'm not really suggesting that the language be changed, I'm just trying to
get a better understanding of it.)

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!

naw@planet.bt.co.uk (Ab Wilson) writes:

>In article <CA6M1p.n39@cbnewsk.cb.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes:
>
> >< What is the rationale behind the prohibition from calling free() on
> >< something allocated with operator new() or calling operator delete() on
> >< something allocated with malloc()? It would be nice if programmers didn't
> >< have to keep track of which method was used to allocate each different
> >< piece of data. Given that all the code works with all known existing
> >< implementations, and that no known compilers actually detect violations of
> >< this constraint, wouldn't it be better if the standard did not include
> >< such a constraint?

Actually the above words were mine, not Tony L. Hansen's.

>Wouldn't it be better if you only used new/delete and then you
>wouldn't have to remeber which method you used to get the storage in
>the first place.

Two problems:
 * Sometimes you have to interface with C code, which means that
   you have to use malloc()/free().
 * Sometimes you want to use realloc()

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!

In article <9319709.1208@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>...
>There's a clear difference between the new/delete operators and malloc()/free(),
>but there does not seem to be much difference between the operator new()/
>operator delete() functions and malloc()/free(). Is there any good reason
>why C++ needs *two* low-level dynamic memory allocation mechanisms?
>
>(I'm not really suggesting that the language be changed, I'm just trying to
>get a better understanding of it.)

 I think it's safe to say that the idea is to avoid malloc()/free() in
favor of oper new()/del() in c++ as the aformentioned functions are part
of stdio and therefore provided for compatibility to c only. new()/del()
may eventually if not already in some cases contain some additional
functionality over the former.
 There does seem to be a problem when interfacing to existing c code with
regard to keeping track of how "things" had been created (if it even really
matters in my/your/anybodies implementation), something that I hadn't
really considered as I made a clean break (not something everyone can
do)...

>
>--
>Fergus Henderson                     This .signature virus might be
>fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
>                                     consistently believe it unless you
>Linux: Choice of a GNU Generation    copy it to your own .signature file!

In article <9319513.17723@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|What is the rationale behind the prohibition from calling free() on something
|allocated with operator new() or calling operator delete() on something
|allocated with malloc()?

One rationale is that even if malloc/free didn't exist you would still
have to make sure you only delete'd things such that the delete matches
a corresponding new.  In general there can be a plethora of differing
new's and the end programmer must take responsibility for getting
the correct delete called.  Malloc/Free are a small nuisance by comparison,
and further represent nothing different in C++.  You always got the get
the deallocation lined up with the matching allocator.  There is very
weak language support for this issue.

|It would be nice if programmers didn't have to
|keep track of which method was used to allocate each different piece of
|data. Given that all the code works with all known existing implementations,
|and that no known compilers actually detect violations of this constraint,
|wouldn't it be better if the standard did not include such a constraint?

I don't think so.  I'd argue that malloc/free must remain compatible
with C malloc/free, or you'd really have a hellish time keeping things
straight.  In turn, some of the ANSI-C committee members are making noises
about wanting to further extend ANSI-C.  Tying C++ allocation/deallocation
to C allocation/deallocation then would put a big part of C++'s fate back
in the hands of the ANSI C committee, which would seem most foolish to me.
The ANSI/ISO-C++ committee has plenty enough problems of their own.
Besides I would claim the C allocation/deallocations tend to be larger
and less frequent the C++ allocations, meaning that their respective
allocators should be tuned to differing requirements.