Re: basic_string ctor

> Which doesn't make it right - C strings are lame at best and we all know
it.

They are not lame - they just have their drawbacks.

But they have their pluses as well. Unless you go to great deal of effort
with allocators and forgetting about small string optimisation, std::string
will be using dynamic memory and in certain instances that could a
performance killer. Under those circumstances I find std::string lame. And
at that point for strings with more than 16 chars and not incredibly
lengthy - they shine.

And the same could be said about std::stringstream.
I find the C++ standard extraordinarily light in terms of std::stringstream
functionality and what is offered.
It is also not cheap when it comes to memory.
And there are no complexity guarantees for growth in stringstream's buffers.
No pubsetbuf() functionality unlike fstream.
So I find std::stringstream lame. For a long time, I would not use them.

And to this day there are certain aspects of sprintf(), sscanf() which are
not duplicated (but could be) for input/output using stream << or >>.
Yes, yes, streams are type safe but I am after speed an so are many.

> But here we're converting from a pointer to an object. The validity of
that
> pointer is entirely up to the object's constructor to decide. I'm sure
10's
> of 1000's of C++ programmers have designed classes that take a pointer
> paramter to their constructor and provide some reasonable default behavior
> if the pointer is null. It's really not that radical an idea.

It is not that radical but who says the default behaviour you provide is
reasonable?
A chat with one of my stringent colleagues and he says he would _NEVER_ pass
a char pointer set to NULL to a std::string constructor and there would be
a pre-condition assert() on such a pointer.
After all you can set the pointer to "" beforehand. In other words - don't
ever write code like this.

> > But if you fold this distinction in std::string's constructor, so
> > NULL will silently construct an empty std::string, then in the
> > situation where the pointer being NULL is an error in the program,
> > this will silently pass over this.
>
> Yep. And in the 1000's of cases where the 0 isn't an error it'll
frustrate
> and confuse the programmer when the seemingly reasonable std::string(0)
> crashes their program.
>
> Neither solution is perfect, and opinions vary as to which is "better" or
> "safer". Most opinions I've encountered agree that C++ would be easier to
> learn and safer for most programmers to use if there was less undefined
> behavior.

Fine, but not at the price that everything is slower because of numerous
checking going on.
C++ is not a "safe" language, nor C its predecessor. The language does not
insulate you from your own stupidities. And starting to change the language
so it wraps the novice programmer in cotton wool throws aways speed is going
down a slippery slope. But this world I described is not bad - most tool
vendors provide excellent warning messages so you can avoid making errors.

While we are here, I will describe something very similar:
I have used a different compiler for years that produces 16-bit DOS
applications - 8086 code.
And for 16-bit code, there is no Intel instruction for dividing 32-bit
integers by 32-bits integers.
So an internal vendor function did this and the results it generated were
consistent with the Intel DIV and IDIV instructions - except in one detail.
The one detail was this:
If you use the Intel DIV or IDIV instruction you get a "divide-by-0"
exception
But with routine you would not, it would return 0.
Now some programmers could argue this is "safer" - at least the program
would not unexpectedly terminate. Is that your opinion in this case? Is this
"better"?

But it is mathematically wrong. The programmer should not be dividing by 0.
You can provide "default behaviour", something reasonable, but it is still
wrong. They certainly would not get silent continuations if the types were 2
16-bit integers, the Intel chip would fault. So the library function
contributed to an incorrect program.

This was changed over time. Now the internal library function was like
DIV/IDIV.
The library function did a DIV and caused a divide-by-0 error.
And it means that the lucky programmer gets to fix his/her progam an running
it through the debugger and deciding what the precondition of 0 would mean.

Stephen Howe






.

Relevant Pages

  • Re: function
    ... The logical operators all return 1 to mean true and 0 to mean false. ... when x is a pointer, ... the two strings were the same. ... the strcpy() that you had above the test, ...
    (comp.lang.c)
  • Re: fast stable sort
    ... rather than isolating it in a separate array. ... It lumps an extra pointer in with the only one ... Building a linked list does not constitute using Oextra space. ... strings and linking the strings into an order. ...
    (comp.programming)
  • Re: Problem with strcat, strcpy,sprintf
    ... rigged question and therefore not worthy of an answer. ... misconceptions about what strings are and deliberately not correcting ... them for the sake of an explanation of what assignment does. ... content of a pointer is an address, not the thing it points to. ...
    (comp.lang.c)
  • Re: GetOpenFilename()
    ... Specifies that the File Name list box allows multiple selections. ... the directory and file name strings are NULL ... You advance the pointer one character more. ...
    (microsoft.public.vc.language)
  • Re: Malcolms new book - Chapter 1 review
    ... user of the library function could decide on some suitable upper ... pointer to the next input line. ... attempt to allocate an arbitrarily large amount of memory. ... lets you specify a limit. ...
    (comp.lang.c)