Siemel Naran <sbnaran@localhost.localdomain> wrote:
: On 26 Sep 1998 18:15:29 GMT, Joe Keane <jgk@jgk.org> wrote:

:>C string functions don't allow null pointers either, so i don't see why
:>people should be surprised by the String class behavior.

: Well, you can do "strlen(0)", but you get a segmentation fault
: (ie, a program crash).

Although I agree with both of these comments, there is some difference
between a normal function and a constructor.  I expect constructors
to be very bullet proof.  At least it should throw an exception, but
not be left entirely undefined.  I do not expect that every "function"
in the strings library handle NULL.(or even any function)  Because
functions are called explicitly by the user it is obvious behavior
that it should crash if an unexpected input is applied.

It is not obvious (to all users) that (my real) function crashed in
the typecasting.  At first, I thought that it was the gtk library or
the test code I was applying.  It took a while to track it back
to the constructor in the standard library.

: I guess it's for the efficiency.  If a func has to do a test
: "if (ptr==0) do_something1; else do_something2" you get slighly
: worse performance.  This is exacerbated by the fact that most
: strings are valid -- that is, ptr!=0 is #true -- so having to
: test for null explicitly is wasteful.

I agree as well.  However, constructors are special cases in
they may be called without explicit direction to do so.  Therefore,
they should have higher standards than a regular function.  All
behavior should be defined for a constructor.

: Also, the code looks clumsy when cluttered up with all those 'if'
: statements.

It would be a total of three if's in inline code, and there is
no else involved.

current implementation (gcc):
  basic_string (const charT* s)
    : dat (nilRep.grab ()) { assign (s); }

desired implementation:
  basic_string (const charT* s)
    : dat (nilRep.grab ()) { if (s) assign (s); }


--Karl
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

:     // Add this simple inline adapter function
:     // which calls foo(string) with a valid string
:     inline int foo(const char*text) // Note: Works even if text is NULL
:         { return foo(text ? string(text) : string()); }

This would be unreasonable for the over 60 occurances of
strings in several hundred header files.  I have a kludge
arround it with

class _gtk_string: public string
  {public:
      _gtk_string(const char *c) string(c?c:"") {}
      _gtk_string(const string& s) string(s) {}
  };

however, I wanted to know if there was some reason in
the spec.

--Karl
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6u9217$cj9$1@mark.ucdavis.edu>,
  Karl Nelson <kenelson@ece.ucdavis.edu> wrote:
> Why was is decided not to define a basic_string((char*)NULL) as
> being equivalent to a basic_string();?
>
> Is there any reason why NULL behavior was left undefined by the standard?
>
> Sample code:
>
>   #include <string>
>
>   int foo(const string &bar)
>     { return 1;
>     }

    // Add this simple inline adapter function
    // which calls foo(string) with a valid string
    inline int foo(const char*text) // Note: Works even if text is NULL
        { return foo(text ? string(text) : string()); }

>   main()
>     {char *test=NULL;
>      foo(test);
>     }

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

C string functions don't allow null pointers either, so i don't see why
people should be surprised by the String class behavior.

--
Joe Keane, amateur mathematician


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 26 Sep 1998 18:15:29 GMT, Joe Keane <jgk@jgk.org> wrote:

>C string functions don't allow null pointers either, so i don't see why
>people should be surprised by the String class behavior.

Well, you can do "strlen(0)", but you get a segmentation fault
(ie, a program crash).

I guess it's for the efficiency.  If a func has to do a test
"if (ptr==0) do_something1; else do_something2" you get slighly
worse performance.  This is exacerbated by the fact that most
strings are valid -- that is, ptr!=0 is #true -- so having to
test for null explicitly is wasteful.

Also, the code looks clumsy when cluttered up with all those 'if'
statements.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I am having some problems wrapping some C code with a C++ wrapper
for the Gtk-- project.

Basically in Gtk NULL is a valid reference for a char*; however,
when used to convert to type string in the wrapper, this seg faults.

Ross Smith pointed me to this part of the standard. [lib.string.cons]

  basic_string(const charT* s, size_type n,
               const Allocator& a = Allocator());
  Requires:
    s shall not be a null pointer and n < npos.
  Throws:
    out_of_range if n == npos.
  Effects:
    Constructs an object of class basic_string and determines its
    initial string value from the array of charT of length n whose
    first element is designated by s, as indicated in Table 5:

(which is being used by basic_string(const charT* s);)

Why was is decided not to define a basic_string((char*)NULL) as
being equivalent to a basic_string();?

Is there any reason why NULL behavior was left undefined by the standard?

Sample code:

  #include <string>

  int foo(const string &bar)
    { return 1;
    }

  main()
    {char *test=NULL;
     foo(test);
    }

--Karl
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]