Re: [ALACPP] const char* NULL to std::string api

[Gavin Doughtie <gavin@xxxxxxxxxxxx>]

Well, the situation is that we have hundreds of legacy C libraries and dozens of legacy C developers, so 
it would be impractical to galactically remove all char* calls.

What I suppose is bothering me most is that I'm at the mercy of the std::string implementation's const 
char* constructor when it comes to NULL pointer handling. gcc2.96 simply segfaults without throwing an 
error, for example.  I'd be perfectly happy if the compiler refused to accept NULL as an argument to 
standard string construction, but it takes it happily and then fails at runtime. Even with the newer gcc 
I have no chance of throwing my own "bad argument" exception -- I have to deal with any number of jokers 
coming up to me and saying "Hey, your library crashed when I called it with a NULL pointer"

I'm seriously considering writing a boost preprocessor macro that generates char* overrides for APIs 
like this so I have a chance to provide less surprising behavior to callers.

On Thu, May 06, 2004 at 08:02:40AM -0700, Arlo Belshee wrote:
> I'd state that even more strongly: the point of passing a ref instead of a ptr
> is to state that NULL is not a valid value. The compiler will help to ensure
> that no-one passes NULL, but it can't do everything. Really, the interface
> change is to tell all of the users that NULL is not a string (although "" is).
> 
> So, I repeat Chris (as is often the case). Make it a string* if NULL is a
> valid value; make it a string& if the only valid values are (possibly empty)
> strings. Thus, if you make it a ref, then you don't need to support NULL - I
> might even write a temporary transition stub that performs a NULL-check and
> throws a logic_error exception or snags interrupt 3. Of course, I'd remove the
> stub as soon as the transition was complete (the caller had also been changed
> as needed).
> 
> Arlo
> 
> > I think I would test for NULL, if it was really neccessary, just because of
> > the lower overhead.  But I agree with Chris that the *point* of passing by
> > reference instead of by pointer is to have the compiler do the null check
> > for you.
> >
> > --Domenic
> >
> >> This would seem like correct behavior to me. Contractually,
> >> "const std::string&" doesn't allow for a null value to be passed, and
> >> logic_error is about the kind of exception I'd expect from that
> >> scenario. This is the kind of thing that I *like* about the "modern"
> >> interface, as it avoids me having to write special case code for null
> >> string pointers.
> >>
> >> If you are hell bent on supporting the old behavior. I'd be tempted to
> >> do something like this:
> >>
> >> //Silly doFoo() guard that swallows the exception
> >> //We could just test for null here, but I'm annoyed
> >> //by the thought of doing it on top of the check
> >> //done int the STL
> >> inline void doFoo(const char* param) {
> >>     try {
> >> doFoo(param);
> >>     } catch (std::logic_error&) {
> >>         //nothing, because for some silly reason we think
> >> //this is okay behavior
> >>     }
> >> }
> >>
> >> void doFoo(const std::string& param);
> >>
> >> > The best I've come up with so far is some nasty boost::preprocessor
> > macro to write the parellel implementation for you. Does anybody have a
> > better idea?
> >>
> >> If null really *is* a valid value, then really the interface should be:
> >>
> >> void doFoo(const std::string* param);
> >>
> >> That will of course mean that all the callers will have to be changed,
> >> but it'd be the right thing to do.
> >>
> >> --
> >> Christopher Smith <x@xxxxxxxx>
> >> _______________________________________________
> >> alacpp mailing list
> >> alacpp@xxxxxxxxxxx
> >> http://lists.ellipsis.cx/mailman/listinfo/alacpp
> >
> > _______________________________________________
> > alacpp mailing list
> > alacpp@xxxxxxxxxxx
> > http://lists.ellipsis.cx/mailman/listinfo/alacpp
> >
> 
> _______________________________________________
> alacpp mailing list
> alacpp@xxxxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/alacpp
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp