kanze@gabi-soft.de (James Kanze) wrote in message news:<d6651fb6.0207310643.5dc4e722@posting.google.com>...
> Michiel.Salters@cmg.nl (Michiel Salters) wrote in message
> news:<cefd6cde.0207300650.43897d0a@posting.google.com>...
> > Erik Steffl <steffl@bigfoot.com> wrote in message
> > news:<3D43A770.FC56148D@bigfoot.com>...
>
> > > why does standard say that charT * in basic_string(const charT*,
> > > Allocator& = Allocator()); cannot be NULL?
>
> > Because the standard doesn't want to force checks on real-world
> > programs that might not need them, and those programs that do need
> > these checks can add them manually. "Don't pay for what you don't
> > use".
>
> > Common forms include std::string("...") where you know the argument
> > isn't NULL.
>
> I don't believe this argument.  The constructor for string is going to
> dynamically allocate memory.  Do you really thing that a check for null
> could make a measurable difference.

Is it? With the small-string optimalization this might not be the case.
What I'd expect is a check for a \0 in the first N characters, usually
followed by a copy of those (cached) characters to the internal buffer
(which is likely on the stack/cached too). If someone told me checking
for a NULL pointer caused a 10% overhead here I'd believe him.

Even so I think we agree on the basics; there are other areas where
having standardese is more help to the users. This just doesn't have
a high priority.

Regards,
--
Michiel Salters

---
[ 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                       ]

Erik Steffl <steffl@bigfoot.com> wrote in message
news:<3D43A770.FC56148D@bigfoot.com>...

> why does standard say that charT * in basic_string(const charT*,
> Allocator& = Allocator()); cannot be NULL?

What should it say?

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Erik Steffl <steffl@bigfoot.com> wrote in message news:<3D43A770.FC56148D@bigfoot.com>...
> why does standard say that charT * in basic_string(const charT*,
> Allocator& = Allocator()); cannot be NULL?

Because the standard doesn't want to force checks on real-world programs
that might not need them, and those programs that do need these checks
can add them manually. "Don't pay for what you don't use".

Common forms include std::string("...") where you know the argument
isn't NULL.

In comparison, delete p; does check because a commmon idiom is
delete m_ptr; m_ptr = 0; inside a class member .close().

These are soft arguments, but programs have been written to rely on the
latter behavior and libraries can handle the first case even though the
standard doesn't tell them how.

Regards,
--
Michiel Salters

---
[ 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                       ]

Michiel.Salters@cmg.nl (Michiel Salters) wrote in message
news:<cefd6cde.0207300650.43897d0a@posting.google.com>...
> Erik Steffl <steffl@bigfoot.com> wrote in message
> news:<3D43A770.FC56148D@bigfoot.com>...

> > why does standard say that charT * in basic_string(const charT*,
> > Allocator& = Allocator()); cannot be NULL?

> Because the standard doesn't want to force checks on real-world
> programs that might not need them, and those programs that do need
> these checks can add them manually. "Don't pay for what you don't
> use".

> Common forms include std::string("...") where you know the argument
> isn't NULL.

I don't believe this argument.  The constructor for string is going to
dynamically allocate memory.  Do you really thing that a check for null
could make a measurable difference.

I repeat my question: what should the constructor do with a NULL
pointer?  A NULL pointer isn't an empty string.  Most of the time you
have a NULL pointer, it is the result of an unchecked error earlier in
the program.  Perhaps you want a defined exception?  Or maybe the string
"(null)" (which is what outputting a null char* gives with g++ 2.95.2)?

Since no one really knows what the behavior should be, leaving it
undefined allows implementations to do what they want.  If some
implementation finds something that creates a concensus, we can always
define it in a later version.

> In comparison, delete p; does check because a commmon idiom is delete
> m_ptr; m_ptr = 0; inside a class member .close().

> These are soft arguments, but programs have been written to rely on
> the latter behavior and libraries can handle the first case even
> though the standard doesn't tell them how.

Maybe the real reason is that C allows a null pointer for free, but not
for the functions in string.h.  And since that seems to work...

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

  why does standard say that charT * in basic_string(const charT*,
Allocator& = Allocator()); cannot be NULL?

 erik

---
[ 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                       ]