Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <006001c23e15$1c9d6e70$a352a518@samsystem>
From: "Samuel" <samuel AT socal DOT rr DOT com>
To: <cygwin AT cygwin DOT com>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020806191106 DOT 0211d4a0 AT pop3 DOT cris DOT com>
Subject: Re: new vs malloc, was BUG - Cygwin to GNU CC compatibility
Date: Wed, 7 Aug 2002 06:19:51 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

He did not say "multiple invocations of "delete""; he just said "delete",
and saying that no "user code should ever use "delete";" is as valid as
saying that you should never exit a program, that when a program is executed
it must remain executing until the entire system is shut down. It is very
wrong to say that "delete" is not for use by user code.

It sure surprises me that I was the only one that said something about the
innacuracy; if such a thing were to be said in the comp.lang.c++ newsgroup
then the remark would get more ridicule than I see people getting in this
list about anything. Again, if you simply leave off the "multiple" (and Ross
did not say "multiple") from what you said, your statement is highly
inaccurate. Am I the only one in this list that knows this? If so then it is
good that I am correcting this error. This is not a "C++ API / data
structure philosophy debate"; it is not a matter of philosophy; it is a
matter of fact. There have been more than one message recently asking C++
questions that were not relevant to CygWin. I have not seen any messages
saying that they were off-topic. So I do not appreciate being told that I
should not post a small correction to a huge inaccuracy. I know that for
sure the C++ experts in the comp.lang.c++ newsgroup often emphasize that for
every "new" there must be one (and only one) "delete" and for every "new []"
there must be one (and only one) "delete []", but that is such a basic thing
that I do not need experts to tell me that.

All C++ questions should be referred to a more appropriate list, newsgroup
or forum, since the advice they get in the CygWin list is dangerous.


----- Original Message -----
From: "Randall R Schulz" <rrschulz AT cris DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Tuesday, August 06, 2002 7:17 PM
Subject: RE: new vs malloc, was BUG - Cygwin to GNU CC compatibility


> Ross, Samuel,
>
> We can agree that regardless of the specific manifestation of multiple
> invocations of "delete" on any given pointer returned by "new," doing so
is
> erroneous. And that is a universal fact of C++ programming.
>
> Perhaps we should avoid a generic C++ API / data structure philosophy
> debate here in the Cygwin list, OK?
>
> Randall Schulz
> Mountain View, CA USA
>
>
> At 18:28 2002-08-06, Ross Smith wrote:
> > > From: Samuel [mailto:samuel AT socal DOT rr DOT com]
> > >
> > > From: "Ross Smith" <rosss AT pharos DOT co DOT nz>
> > > >
> > > > No user code should ever use "delete"; it should only appear in the
> > > > implementation of a container or smart pointer.
> > >
> > > What? I must misunderstand what is meant, since user code
> > > must always use
> > > "delete" for each "new", unless the documentation of a
> > > function clearly
> > > states that it is the function's responsibility to "delete".
> >
> >This is what smart pointers (std::auto_ptr, boost::shared_ptr, etc) are
> >for. Anything allocated by new should always be held by a smart pointer
> >that will handle deletion automatically, never a raw pointer.
> >
> >--
> >Ross Smith
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/