James Kanze wrote:
>
> brahms@mindspring.com (Stan Brown) writes:
>
> |>  I think you mean C89 rather than C90[...]
>
> The ANSI version first appeared in 1989, but the ISO standard is C90.
>
And ANSI uses the 1990 date.  While C90 isn't a standard term, it
would seem accurate.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3AAF8B7A.D49CCA3A@spamcop.net>,
Ron Natalie  <ron@spamcop.net> wrote:
>James Kanze wrote:
>> brahms@mindspring.com (Stan Brown) writes:
>> |>  I think you mean C89 rather than C90[...]
>>
>> The ANSI version first appeared in 1989, but the ISO standard is C90.
>>
>And ANSI uses the 1990 date.  While C90 isn't a standard term, it
>would seem accurate.

He doesn't negate that after C89, ANSI also used the 1990 date.
As an aside re trivia: C89 and C90 with Amendment 1 was sometimes
referred more informally as C95, and even more informally
TC1 and TC1 has C names to them too.  As well, C90 did not have
a rationale as far as I recall though C89 does (though of course
the rationale is formally not part of the standard).
--
Greg Comeau                   Comeau C/C++ 4.2.45 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45.2 during March!        NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.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.research.att.com/~austern/csc/faq.html                ]

Calling free with an argument equal to the null pointer results in
undefined behavior. So, if you are worried about null pointers
then it's your responsibility to check for them and incur the cost
of checking.

Calling delete with an argument equal to the null pointer has no
effect. So even if you don't expect null pointers, you still have
to incur the cost of checking for null pointers since delete
automatically does it for you.

Doesn't delete's automatic checking conflict with the idea in C++
that those who don't need a new feature won't be penalized by its
presence? Is it recommended that everyone just go back to using
free() to avoid these checks?



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US wrote:
>
> Calling free with an argument equal to the null pointer results in
> undefined behavior. ...

I'm curious - what led you to that conclusion? The C++ standard doesn't
define this behavior, delegating that to the C90 standard, which it
incorporates by reference. I don't have a copy of the C90 standard, but
the C99 standard says "If ptr is a null pointer, no action occurs.", and
I don't think that's something that changed from C90. The only
differences between the C++ std::free() and C90 free() are the use of
the std:: namespace, and the fact that the C++ std::free() is prohibited
from calling ::operator delete().

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

[cc'd to previous poster for speed]

Quoth James Kuyper Jr. <kuyper@wizard.net> in comp.std.c++:
>I'm curious - what led you to that conclusion? The C++ standard doesn't
>define this behavior, delegating that to the C90 standard, which it
>incorporates by reference. I don't have a copy of the C90 standard, but
>the C99 standard says "If ptr is a null pointer, no action occurs.", and
>I don't think that's something that changed from C90.

I think you mean C89 rather than C90, but you're right: the exact
same words occur in section 4.10.3.2 of the 1989 ANSI standard
(subclause 7.10.3.2 of the ISO standard).

C++ simply carried that behavior forward.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
                                  http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US wrote:
>
> Calling free with an argument equal to the null pointer results in
> undefined behavior. So, if you are worried about null pointers
> then it's your responsibility to check for them and incur the cost
> of checking.

UNTRUE.  Calling free() with a null pointer is a no-op as well.

> Doesn't delete's automatic checking conflict with the idea in C++
> that those who don't need a new feature won't be penalized by its
> presence? Is it recommended that everyone just go back to using
> free() to avoid these checks?

You're not penalized, if you don't want all the features that
new provides (proper initialization of objects and type safety)
go back to using malloc.  However, you won't be saving any time on
free.

7.10.3.2 of the C90 spec (the one that applies to C++, but it's
no different in C99):

The free function causes the space pointed to by ptr to be deallocated.
that is, made available for further allocation. If ptr is a null pointer,
no action occurs.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US <uunet!lots!spamme@ncar.UCAR.EDU> wrote:

> Calling free with an argument equal to the null pointer results in
> undefined behavior. So, if you are worried about null pointers
> then it's your responsibility to check for them and incur the cost
> of checking.
>
> Calling delete with an argument equal to the null pointer has no
> effect. So even if you don't expect null pointers, you still have
> to incur the cost of checking for null pointers since delete
> automatically does it for you.
>
> Doesn't delete's automatic checking conflict with the idea in C++
> that those who don't need a new feature won't be penalized by its
> presence? Is it recommended that everyone just go back to using
> free() to avoid these checks?

    I don't see how one would "go back to free()". There is no way to
delete an object allocated with new without using delete, and there's no
way to allocate an object (and have the constructor called) without
using new.


--
http://www.whereismyhead.com/clark/
Clark S. Cox, III
clarkcox3@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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US wrote:
>
> Calling free with an argument equal to the null pointer results in
> undefined behavior.

No, I believe it is a no-op.

> So, if you are worried about null pointers
> then it's your responsibility to check for them and incur the cost
> of checking.
>
> Calling delete with an argument equal to the null pointer has no
> effect. So even if you don't expect null pointers, you still have
> to incur the cost of checking for null pointers since delete
> automatically does it for you.
>
> Doesn't delete's automatic checking conflict with the idea in C++
> that those who don't need a new feature won't be penalized by its
> presence? Is it recommended that everyone just go back to using
> free() to avoid these checks?

Delete and free are the same in this respect.  The cost of a check
for null compared to the cost of freeing a block of memory is tiny,
and the peril so great, that this seems like a sensible decision.

-- James Dennett

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kuyper Jr. <kuyper@wizard.net> wrote in message
news:3AA826CE.B6A0197F@wizard.net...
> ALL YOUR BASE ARE BELONG TO US wrote:
> >
> > Calling free with an argument equal to the null pointer results in
> > undefined behavior. ...
>
> I'm curious - what led you to that conclusion?

All I know is that 90% of the compilers I've have used over the years
have crashed when calling free( 0 ). The benefit of this crashing free()
is that it's faster than the one that has to check for 0's.



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3aa7deab_1@news.nwlink.com>, ALL YOUR BASE ARE BELONG TO US
<uunet!lots!spamme@ncar.UCAR.EDU> writes
>Calling free with an argument equal to the null pointer results in
>undefined behavior. So, if you are worried about null pointers
>then it's your responsibility to check for them and incur the cost
>of checking.

Why do you believe this (quote chapter and verse, sorry clause and sub-
clause, please). C++, to the best of my knowledge inherits its behaviour
for free from C where 'free 0' is required to have no effect.


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3aa7deab_1@news.nwlink.com>,
ALL YOUR BASE ARE BELONG TO US <uunet!lots!spamme@ncar.UCAR.EDU> wrote:
>Calling free with an argument equal to the null pointer results in
>undefined behavior. So, if you are worried about null pointers
>then it's your responsibility to check for them and incur the cost
>of checking.

This seems to be a cornerstone of your argument,
yet, it is false for C90 and for C99.

>Calling delete with an argument equal to the null pointer has no
>effect.

Correct.

>So even if you don't expect null pointers, you still have
>to incur the cost of checking for null pointers since delete
>automatically does it for you.

Maybe.

>Doesn't delete's automatic checking conflict with the idea in C++
>that those who don't need a new feature won't be penalized by its
>presence?  Is it recommended that everyone just go back to using
>free() to avoid these checks?

As mentioned above, free() is supposed to handle a null pointer too.
Also, this last question ignores that free()ing memory and destroying
objects can be two different things.
--
Greg Comeau                   Comeau C/C++ 4.2.45 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45.2 during March!        NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US wrote:
>
> Calling free with an argument equal to the null pointer results in
> undefined behavior.

On the contrary. It is guaranteed to do nothing. That is the case
in C90 (section 7.10.3.2), included by reference in the C++ standard.
(C99 says the same thing.)

>
> Calling delete with an argument equal to the null pointer has no
> effect. So even if you don't expect null pointers, you still have
> to incur the cost of checking for null pointers since delete
> automatically does it for you.

The cost of checking for the null pointer is 1 to 4 orders of
magnitude less than the cost of an actual memory deallocation.
(The deallocation might be as simple as adding the address to a
free list, or as complex as coalescing adjacent free blocks and
returning a block of memory to the OS.)

The only time you would be able to measure the cost of the
unnecessary check would be when the delete operation does not
actually deallocate anything. In that case, you could avoid
the null-pointer check by calling the destructor explicitly
instead using delete.

--
Steve Clamage, stephen.clamage@sun.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

ALL YOUR BASE ARE BELONG TO US wrote:
...
> All I know is that 90% of the compilers I've have used over the years
> have crashed when calling free( 0 ). The benefit of this crashing free()

Have you actually checked that? I'd imagine, if you thought it was
dangerous, that you wouldn't do it very often. That being the case, you
might have been reacting to one (or two) defective implementations, and
not noticed when you started using a correct implementation.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"ALL YOUR BASE ARE BELONG TO US" <spamme@lots.UCAR.EDU> wrote

> All I know is that 90% of the compilers I've have used over the years
> have crashed when calling free( 0 ). The benefit of this crashing free()
> is that it's faster than the one that has to check for 0's.

Those of us who are faint at heart will stick to the other 10%.  The benefit
of compilers that do nothing is that it's faster than actually compiling the
code ;-)


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"ALL YOUR BASE ARE BELONG TO US" <spamme@lots.UCAR.EDU> wrote in
<3aa83cee_1@news.nwlink.com>:

>
>James Kuyper Jr. <kuyper@wizard.net> wrote in message
>news:3AA826CE.B6A0197F@wizard.net...
>> ALL YOUR BASE ARE BELONG TO US wrote:
>> >
>> > Calling free with an argument equal to the null pointer results in
>> > undefined behavior. ...
>>
>> I'm curious - what led you to that conclusion?
>
>All I know is that 90% of the compilers I've have used over the years
>have crashed when calling free( 0 ). The benefit of this crashing free()
>is that it's faster than the one that has to check for 0's.
>

Then 90% of the compilers you have been using were seriously broken (well
their RTL was). I never saw a compiler get this one wrong. I seriously
think there is some other issue here as I just cannot believe what you said
is true.

HTH,
M4

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3aa83cee_1@news.nwlink.com>,
ALL YOUR BASE ARE BELONG TO US <spamme@lots.UCAR.EDU> wrote:
>James Kuyper Jr. <kuyper@wizard.net> wrote in message
>news:3AA826CE.B6A0197F@wizard.net...
>> ALL YOUR BASE ARE BELONG TO US wrote:
>> > Calling free with an argument equal to the null pointer results in
>> > undefined behavior. ...
>>
>> I'm curious - what led you to that conclusion?
>
>All I know is that 90% of the compilers I've have used over the years
>have crashed when calling free( 0 ).

So long as it's just the compiler which is crashing, and not your
code, then you should be ok, right? :)

Seriously, I've used compilers where free(0) does not work.
However, I can't imagine any compiler written in the past decade
that claims to function as a Standard hosted compiler where this
would be so.  This either means:
1) You're using old compilers
2) You're coding to freestanding environments
3) The code is question is broken, and the free(0); crashing
   was just an illusions and the real bug was elsewhere.

>The benefit of this crashing free()
>is that it's faster than the one that has to check for 0's.

There is no such guarantee, and therefore, saying that is misleading.
I bet you won't think it's so fast when the embedded device you're
connected to in a hospital malfunctions because the free(0) crashed it
and the nurses and doctors don't know what to do, assuming then can
even detect that it was so.

Anyway, do you feel comfortable with delete now?
--
Greg Comeau                   Comeau C/C++ 4.2.45 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45.2 during March!        NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.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.research.att.com/~austern/csc/faq.html                ]

>     I don't see how one would "go back to free()". There is no way to
> delete an object allocated with new without using delete, and there's no
> way to allocate an object (and have the constructor called) without
> using new.

"going back to free" is possible if you also "go back to malloc". Doing such a
thing is IMHO plain nonsense. That said you are wrong when you say it is not
possible.

There are many overloaded new/delete pairs. Specifically the placement new
operator can be used to construct an object on preallocated memory. The STL does
this all the time!!

--

Andrea Ferro

---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556



---
[ 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.research.att.com/~austern/csc/faq.html                ]

brahms@mindspring.com (Stan Brown) writes:

|>  I think you mean C89 rather than C90[...]

The ANSI version first appeared in 1989, but the ISO standard is C90.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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.research.att.com/~austern/csc/faq.html                ]