>>Use malloc & free. It works in both C & C++.
>
>
>
> If we do not know the implementation details of the library (e.g.
> precompiled)?

If it's a C library, it's not using new or new[].

In any event, the library's documentation ought to tell you that type of
thing.  Otherwise, how do you know when a function returns a pointer
that it even needs to be deallocated?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") wrote in message news:<c663fu$1vi0$1@ulysses.noc.ntua.gr>...
> ""Marcin 'Qrczak' Kowalczyk"" <qrczak@knm.org.pl> wrote in message
> news:pan.2004.04.21.08.39.46.748697@knm.org.pl...
> >
> > Use malloc & free. It works in both C & C++.
>
>
> If we do not know the implementation details of the library (e.g.
> precompiled)?

If you don't know the implementation details, how can you be sure that
either free() or delete can be safely used? The pointer returned might
point at a static array, or at memory that was malloced internally to
something(), with the intent that a later call to something_else()
would free() it - if you free() it, the same memory would get free()d
twice?

The documentation for something() should tell you whether or not
deallocating the memory pointed at by the return value is your
responsibility. If it is your responsibility, the documentation should
also specify whether you need to use free() or delete, or
something_release() to perform the deallocation. If you you're trying
to use a function and don't have access to the documentation for it,
you're in more trouble than any change to the C++ language
specification can solve.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Proposal: A guarantee in the standard that if you call free() upon objects
created by new/new[] ,and a call of delete/delete[] on objects created by
malloc()/calloc()/realloc() is safe.

I am not talking about the constructors issue where they are not called in
the case of malloc() family, just the interchange ability between free() and
the delete family.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
news:c5pk7v$so3$1@ulysses.noc.ntua.gr...
> Proposal: A guarantee in the standard that if you call free() upon objects
> created by new/new[] ,and a call of delete/delete[] on objects created by
> malloc()/calloc()/realloc() is safe.
>
> I am not talking about the constructors issue where they are not called in
> the case of malloc() family, just the interchange ability between free()
and
> the delete family.



The proposal corrected:

Proposal: A guarantee in the standard that if you call delete/delete[] on
objects created by
malloc()/calloc()/realloc() is safe.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
news:c5pk7v$so3$1@ulysses.noc.ntua.gr...
> Proposal: A guarantee in the standard that if you call free() upon objects
> created by new/new[] ,and a call of delete/delete[] on objects created by
> malloc()/calloc()/realloc() is safe.
>
> I am not talking about the constructors issue where they are not called in
> the case of malloc() family, just the interchange ability between free()
and
> the delete family.



The proposal corrected:

Proposal: A guarantee in the standard that if you call delete/delete[] on
objects created by
malloc()/calloc()/realloc() is safe.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") writes:

> Proposal: A guarantee in the standard that if you call free() upon objects
> created by new/new[] ,and a call of delete/delete[] on objects created by
> malloc()/calloc()/realloc() is safe.
>
> I am not talking about the constructors issue where they are not called in
> the case of malloc() family, just the interchange ability between free() and
> the delete family.

What about the destructors issue?

struct foo
{
  ~foo(){std::cout << "Hi, I am a destructor." << std::endl;}
};

int main()
{
  foo* f= new foo;
  free(f); //Should foo::~foo() be called here?
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
> Proposal: A guarantee in the standard that if you call free() upon
> objects created by new/new[] ,and a call of delete/delete[] on
> objects created by malloc()/calloc()/realloc() is safe.
>
> I am not talking about the constructors issue where they are not
> called in the case of malloc() family, just the interchange ability
> between free() and the delete family.

I immediately see two problems, apart from the constructor/destructor
problem:

1. The program may have its own user-defined versions of operator new
and operator delete, and these don't have to use malloc/free.  So the
proposed guarantee can't apply when user-defined versions of the
operators are used.  But when writing code that uses new and delete,
there is no way to force the standard versions of operator new and
operator delete to be used, so there is no way to know for sure that the
guarantee applies.

2. A "new" expression that allocates an array is allowed to allocate
some extra space at the front of the array.  This is usually done to
store the number of items in the array so delete[] will call the
destructor the correct number of times.  A delete[] expression knows
about this and knows how to correctly adjust the pointer that it passes
to operator delete[].  So, assuming that operator new[] calls operator
new, which calls malloc, and given the following code:
 T *x = new T[10];
 free((void*)x);
The address returned by malloc (within operator new) might not be the
address that is passed to free.  So therefore the guarantee can't apply
to new[] and delete[].

--
David Olsen
qg4h9ykc5m@yahoo.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 17 Apr 2004 03:12:04 +0000 (UTC), ivr@guesswh.at.emails.ru
("Ioannis Vranos") wrote in comp.std.c++:

> ""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
> news:c5pk7v$so3$1@ulysses.noc.ntua.gr...
> > Proposal: A guarantee in the standard that if you call free() upon objects
> > created by new/new[] ,and a call of delete/delete[] on objects created by
> > malloc()/calloc()/realloc() is safe.
> >
> > I am not talking about the constructors issue where they are not called in
> > the case of malloc() family, just the interchange ability between free()
> and
> > the delete family.
>
>
>
> The proposal corrected:
>
> Proposal: A guarantee in the standard that if you call delete/delete[] on
> objects created by
> malloc()/calloc()/realloc() is safe.

What is the purpose of making a proposal without supplying any reason
why you think it is needed?  What benefit would programmers derive
from the effort of the standards committee and compiler and library
implementers to make this change?

Why do you think you need this?  If you think you need to use both C
and C++ memory management routines in a C++ program, why can't you
keep track of which is which, and release the memory accordingly?

There is somewhat of an uneasy relationship between C and C++ memory
management functions.  The C functions in a C++ implementation are
specifically prohibited from using the C++ operators.  The reverse is
not true, as in many implementations the standard operator new uses
the underlying C routines to obtain and release raw memory.

Again, though, what problem do you think this would solve, or what
benefit would it provide?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:56918018qlgi7pium562mel08eeoh9vjeb@4ax.com...
>
> > The proposal corrected:
> >
> > Proposal: A guarantee in the standard that if you call delete/delete[]
on
> > objects created by
> > malloc()/calloc()/realloc() is safe.
>
> What is the purpose of making a proposal without supplying any reason
> why you think it is needed?  What benefit would programmers derive
> from the effort of the standards committee and compiler and library
> implementers to make this change?


Yes you are right. It is just more language coherence. And if someone just
moved to C++ and wants to use his old libraries allocating things with
malloc()/calloc()/realloc() to be able to use delete in his new environment.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") wrote in message news:<c5po2d$1582$1@ulysses.noc.ntua.gr>...
> ""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
> news:c5pk7v$so3$1@ulysses.noc.ntua.gr...
> > Proposal: A guarantee in the standard that if you call free() upon objects
> > created by new/new[] ,and a call of delete/delete[] on objects created by
> > malloc()/calloc()/realloc() is safe.
> >
> > I am not talking about the constructors issue where they are not called in
> > the case of malloc() family, just the interchange ability between free()
>  and
> > the delete family.
>
>
>
> The proposal corrected:
>
> Proposal: A guarantee in the standard that if you call delete/delete[] on
> objects created by
> malloc()/calloc()/realloc() is safe.

The whole point of the new/delete feature of C++ is to maintain a
tight connection between the lifetime of an object, and the validity
of it's contents, even when that object is dynamically allocated. A
successfull new-expression creates an object, filled in by a
constructor with valid values. A successful delete of that same object
undoes whatever needs to be undone, to bookend the code in the
constructor, and then releases the memory. People deliverately and
correctly design objects so that if you don't execute constructors and
destructors as bookend code, things go wrong.
Therefore, in order to make it possible to free() an object created
with new, free() would to run the corresponding destructor. In that
case, why bother? Why not delete it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0404190833.18bdf219@posting.google.com...
>
> > The proposal corrected:
> >
> > Proposal: A guarantee in the standard that if you call delete/delete[]
on
> > objects created by
> > malloc()/calloc()/realloc() is safe.
>
> The whole point of the new/delete feature of C++ is to maintain a
> tight connection between the lifetime of an object, and the validity
> of it's contents, even when that object is dynamically allocated. A
> successfull new-expression creates an object, filled in by a
> constructor with valid values. A successful delete of that same object
> undoes whatever needs to be undone, to bookend the code in the
> constructor, and then releases the memory. People deliverately and
> correctly design objects so that if you don't execute constructors and
> destructors as bookend code, things go wrong.
> Therefore, in order to make it possible to free() an object created
> with new, free() would to run the corresponding destructor. In that
> case, why bother? Why not delete it?


Please read more carefully the corrected version of my proposal above.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") wrote in message news:<c61bqe$2k5u$1@ulysses.noc.ntua.gr>...
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:8b42afac.0404190833.18bdf219@posting.google.com...
> >
> > > The proposal corrected:
> > >
> > > Proposal: A guarantee in the standard that if you call delete/delete[]
>  on
> > > objects created by
> > > malloc()/calloc()/realloc() is safe.
> >
> > The whole point of the new/delete feature of C++ is to maintain a
> > tight connection between the lifetime of an object, and the validity
> > of it's contents, even when that object is dynamically allocated. A
> > successfull new-expression creates an object, filled in by a
> > constructor with valid values. A successful delete of that same object
> > undoes whatever needs to be undone, to bookend the code in the
> > constructor, and then releases the memory. People deliverately and
> > correctly design objects so that if you don't execute constructors and
> > destructors as bookend code, things go wrong.
> > Therefore, in order to make it possible to free() an object created
> > with new, free() would to run the corresponding destructor. In that
> > case, why bother? Why not delete it?
>
>
> Please read more carefully the corrected version of my proposal above.


> Proposal: A guarantee in the standard that if you call delete/delete[] on
> objects created by
> malloc()/calloc()/realloc() is safe.

malloc()/free() is the bookend pair you use when you want to seperate
dynamic allocation of memory from construction and destruction of
objects in that memory. new/delete is the bookend pair you use when
you want to tie allocation/deallocation closely together with
construction/destruction. Who's responsible for deallocation when you
use malloc()/delete?

If delete always calls the destructor, than it would have to be an
error to delete malloc()d memory unless an object of the appropriate
type has been constructed in-place in that memory. If delete is
supposed to call the destructor for objects allocated with new, and
not for objects allocated with malloc(), how is it supposed to know
which is which? It wouldn't be impossible to implement that, but it
would require a lot of changes.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") wrote in message news:<c5s2ff$7oc$1@ulysses.noc.ntua.gr>...
..
> Yes you are right. It is just more language coherence. And if someone just
> moved to C++ and wants to use his old libraries allocating things with
> malloc()/calloc()/realloc() to be able to use delete in his new environment.

Why would he want to change his free() calls to delete, without
replacing his malloc()/calloc() calls to new-expressions?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0404200952.1d7f10cf@posting.google.com...
>
> Why would he want to change his free() calls to delete, without
> replacing his malloc()/calloc() calls to new-expressions?


What about a library for use both in C & C++? For example:


C code:

#include <whatever.h>


char *p=something();

/* ... */

free(p);


C++ code:

#include <whatever.h>


string s=something();

delete p[];

// ...






Ioannis Vranos


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0404200949.74388665@posting.google.com...
>
> malloc()/free() is the bookend pair you use when you want to seperate
> dynamic allocation of memory from construction and destruction of
> objects in that memory. new/delete is the bookend pair you use when
> you want to tie allocation/deallocation closely together with
> construction/destruction. Who's responsible for deallocation when you
> use malloc()/delete?
>
> If delete always calls the destructor, than it would have to be an
> error to delete malloc()d memory unless an object of the appropriate
> type has been constructed in-place in that memory. If delete is
> supposed to call the destructor for objects allocated with new, and
> not for objects allocated with malloc(), how is it supposed to know
> which is which? It wouldn't be impossible to implement that, but it
> would require a lot of changes.


My proposal is aimed towards POD types which i forgot to mention.






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Ioannis Vranos"" <ivr@guesswh.at.emails.ru> wrote in message
news:c64bjo$i73$1@ulysses.noc.ntua.gr...
>
>
> What about a library for use both in C & C++? For example:
>
>
> C code:
>
> #include <whatever.h>
>
>
> char *p=something();
>
> /* ... */
>
> free(p);
>
>
> C++ code:

 #include <whatever.h>


char *p=something();


string s=p;


> delete p[];
>
> // ...
>






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 21 Apr 2004 06:15:23 +0000, Ioannis Vranos wrote:

>> Why would he want to change his free() calls to delete, without
>> replacing his malloc()/calloc() calls to new-expressions?
>
> What about a library for use both in C & C++?

Use malloc & free. It works in both C & C++.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> My proposal is aimed towards POD types which i forgot to mention.

Then I suggest you work at your proposals a little harder. Don't just post
here proposals where you have put a few seconds thought into it and expect
the newsgroup to pick at obvious holes in your  proposal; holes that you
should have thought of and countered.

There is a chapter in Stroustrups Design and Evolution of C++ where he talks
about design considerations for candidate proposals. You should look at
these and before submitting a proposal here, you spend time considering

To me, your proposal does not look well considered. My points:

1) delete is designed to dispose of single objects created by new
delete[] is designed to dispose of an array of objects created by new[]

And that means somehow with new[], the system has to keep track of how many
objects were created so that when delete[] is called, the correct number of
destructors is called.
One of the ways that may be done by a vendor is that new[] may allocate a
bit more memory to keep track of the number of objects created.

In your proposal, how will free() know that it is dealing with a single
object allocated by new compared to an array of objects allocated by new[] ?
One way would be to make new equivalent to doing new[1] but by so doing,
that means new is now wasteful and inefficient.
Further, it seems to me, that the compiler & library will have to do some
pointer thunking
because free() only knows how to deal with block of memory allocated by
malloc() etc and therefore, pointers allocated by new/new[] will have to be
adjusted to be same as what malloc() would return before free() is called

2) AFAIK, the standard is such that new/delete/delete[] maybe implemented on
the back of malloc()/calloc()/realloc()/free() but the vendor is free to
choose differently. Your proposal would mean that the vendor has less
freedom of implementation. The vendor before could supply an optimised
version of new/new[]/delete/delete[] that is independent of malloc() etc.
Now they cannot.

You should have thought of 1) and 2) objections and made sure that the
answers were in your original proposal.

Here is an ill-thought proposal that I could make here:

Alter the standard so that setjmp() and longjmp() work and that if you
longjmp() back to previous valid setjmp() position, all local objects
destructors are correctly called.

Looks marvelous does it not? Great for newbie programmers as well - they can
longjmp() away without worrying about local objects on stacks being
correctly destroyed - the standard will guarantee that they will be.

But what is the price of such a guarantee?  The price is that function like
longjmp() is reasonably simple under the hood - it just restores enough of
the environment context to continue at the point where setjmp(). Now it has
the additional burden of making sure that all the local objects destructors
are called as it wanders up the stack back to where setjmp() is called.

And there is a perfectly reasonable alternative for C++ programmers to use,
namely try-catch.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ivr@guesswh.at.emails.ru ("Ioannis Vranos") wrote in message news:<c64bjo$i73$1@ulysses.noc.ntua.gr>...
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:8b42afac.0404200952.1d7f10cf@posting.google.com...
> >
> > Why would he want to change his free() calls to delete, without
> > replacing his malloc()/calloc() calls to new-expressions?
>
>
> What about a library for use both in C & C++? For example:
>
>
> C code:
>
> #include <whatever.h>
>
>
> char *p=something();
>
> /* ... */
>
> free(p);
>
>
> C++ code:
>
> #include <whatever.h>
>
>
> string s=something();
>
> delete p[];

In the C++ code, what is 'p'? My guess is that what you meant is
something like:

        char *p = something();
        string s(p);

If so, why does the programmer want to delete p? Why not free(p)
instead? If he does want to delete(p), why not use a new-expression
inside the definition of something()?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Marcin 'Qrczak' Kowalczyk"" <qrczak@knm.org.pl> wrote in message
news:pan.2004.04.21.08.39.46.748697@knm.org.pl...
>
> Use malloc & free. It works in both C & C++.


If we do not know the implementation details of the library (e.g.
precompiled)?






Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]