Re: A C++ Whishlist

From: Kevin Goodsell (usenet2.spamfree.fusion_at_neverbox.com)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 18:54:51 GMT

Ram Firestone wrote:
> Kevin Goodsell <usenet2.spamfree.fusion@neverbox.com> wrote in message news:<CTr6c.28277$%06.19752@newsread2.news.pas.earthlink.net>...
>
>>Ram Firestone wrote:
>>
>>>Kevin Goodsell <usenet2.spamfree.fusion@neverbox.com> wrote in message news:<YWj6c.27591$%06.991@newsread2.news.pas.earthlink.net>...
>>>
>>>
>>>>Ram Firestone wrote:
>>>>
>>>>
>>>>>As I said elsewhere. What are you going to do when you catch all these
>>>>>null pointers.
>>>>
>>>>Uh... signal an error, maybe?
>>>>
>>>
>>>
>>>Which typically happens for free anyway.
>>>
>>
>>Show me where it says that in the standard.
>>
>
>
> It's not in any standard. It just does.

No, it doesn't. I'm reasonably confident that it doesn't happen on the
vast majority of computers in the world.

>>
>>I don't even need to look. I've programmed systems like that. You'd be
>>surprised (apparently) how many architectures have address 0 as a
>>perfectly valid memory address, and also use it to represent a null
>>pointer (because it's easy, and there may not be a more appropriate
>>address anyway). All the world is not a desktop system.
>>
>
>
> Ok name some. Yeah I would be surprised how many. Let's see not Lunix,
> Windows, IBM workstation, mainframe, HP/UX ..... I'm really curious.

Like I said, all the world's not a desktop system. In fact, most of the
computers in the world aren't. The 8051 is the only processor I'm
familiar enough with to say for sure that it uses 0 as a valid memory
location, and (with certain tool-chains, such as Keil C51) as the null
pointer value. But I'm sure that if you looked you'd find that most
micro-controllers operate this way. And they are *much* more prevalent
than the systems you named.

> And please don't say PDP-8 because it's not exactly modern. In any
> case once you find one you will then have to find a compiler on that
> system that doesn't pass NULL to members in order for your argument to
> have any relevance to this thread.

Not at all. I'm not, nor have I been, talking about your lame idea of
allowing member function calls from null pointers. I have been talking
about this, in which you indicate that you are OK with writing broken code:

>>void func(foo *p)
>>> > > {
>>> > > std::cout << p->a << std::endl;
>>> > > }
>>> > >
>>> > > int main()
>>> > > {
>>> > > foo *f = NULL;
>>> > > func(f);
>>> > > }
>>> > >
>>> > > Is function "func" wrong?
>
>> >
>> > Yes, 'func' is incorrectly written. 'func' should ensure that 'p->a'
>> > is never invoked with p == 0 or, at the very least, document that
>> > calling it with a 0 argument results in undefined behavior (which
>> > means that anything at all could happen).
>> >

> Ok well obviously we have a fundamental coding style difference,
> which we are not going to settle here. I could easily say your code
> is incorrectly written because it wastes CPU time. But what's the
> point these or personal choices.

>
>
> If you want to check every parameter at the cost of speed, be my
> guest. I'm not even going to say it's wrong. What I am going to say is
> unless you also check the this pointer you aren't checking every
> parameter and you can still get a crash which is the whole point.

This is an absolutely stupid argument. Code is not required or expected
to be correct in the face of external errors, nor can it be. My code is
broken if you violate the rules of the language before calling it? Yeah,
well, all the code in the universe is broken if I toss the computer into
molten lava before using it. I guess all those coders forgot to add the
"processor melted" check to their code.

*Your* code, however, is incorrect due to its own error, not an external
error.

>>>
>>>Except your program will fail at the same rate as mine.
>>
>>I doubt that.
>
>
> Just because you check for unrecoverable errors doesn't make them
> happen less. All it means is you may print a better message. But wait
> you aren't checking the this pointer.

See, you missed the point. I was insinuating that you are a lousy coder,
and your programs fail frequently.

And the 'this' pointer is still completely irrelevant.

>
> Sorry but in my experience the user doesn't care about the line or
> file. If he even writes it down you are lucky.

True, but 1) they at least have the option of trying to help solve the
problem, and 2) my program has the option of doing something more useful
with the error message, such as emailing it back to me.

> The frequency of
> crashes is what's going to loose you customers. In my case lack of
> speed will also loose me customers. In any case if he does have a core
> I will be able to find out much more about the crash then you will.

You are still using a very narrow frame of reference. Core files are
generated in the vast minority of cases.

Besides that, you're still ignoring the point that my program has a
chance of recovering, while yours does not.

>
> Checking every member of every parameter for correctness would waste
> huge amounts of time.

Did you time it?

> Why would you stop at just checking for NULL
> pointers? On many architectures you loose the pipelineing when you do
> an if.
>
>
>>But I'd say 98% of the time it's worth it to have the extra checks. I
>>might, for example, set up my program to do whatever it can to save the
>>user's data in the event of an error - even an unrecoverable logic
>>error. Or the exception could abort the current operation (and provide
>>some details about what happened) without killing the whole program. In
>>general, optimizing by removing safeguards is a bad policy, and won't
>>improve performance much.
>
>
> Hey go wild. That isn't the point of this thread. My claim is that
> allowing call though NULL isn't going to change much in the real
> world.

Oh, well, in that case you're just wrong. Nearly every member function
ever written in code that is intended to be standards-compliant and
robust would need to be modified. And every programmer who writes code
with those concerns in mind has to write their code differently.

> In fact with your mentality you would feel you then have to
> check the this pointer which would give you the kind of error checking
> you say you like. As it stands now you are working under the misguided
> perception that the this pointer will never be NULL.

That is not a misguided perception. That is a guarantee provided by the
C++ standard. Of course, you have to add the requirement that undefined
behavior has not previously been invoked, but you need that requirement
for any code to make any sense at all.

My assumption that 'this' is not NULL is every bit as valid as your
assumption that the processor hasn't been melted by molten lava.

>
>
>>I've used too many programs written by people like you. You can write
>>brittle programs that crash without reasonable diagnostics or recovery
>>attempts if you want to. I'll make my programs robust. And avoid yours.
>>
>
>
> In reality test suits make far more difference in program reliability
> than anything we have talked about here. So if you want to make your
> programs robust better have large automated test suits. By the way the
> Mars rover's computer did crash. I'm sure they were so so careful when
> they wrote the software. The problem was it wasn't tested enough. I
> just thank god they were able to fix it.
>
> Also I'll avoid your programs too as I'm sure they run at a snails
> pace. On the other hand maybe they don't do enough to have that
> problem.
>
>
>>By the way, you've yet to answer the point that started this discussion:
>>You were defending a practice of dereferencing pointers without checking
>>for NULL, and *without documenting that the function should not be
>>called with a null pointer*. In other words, your function is broken by
>>definition (it violates its specification), and you seem to be OK with that.
>>
>>-Kevin
>
>
> What started this discussion is my advocating member call through
> NULL. As for documentation, I would document the function to the
> extent that any non-idiot programmer could use it properly.

Then why didn't you say so in the first place? Instead, you indicated
that dereferencing a pointer without documenting that a null pointer
should not be used represented a "fundamental coding style difference".
If you had just said "Oh, well, I would document it of course," then we
could have avoided all (well, most of) this.

There's nothing inherently wrong with *not* checking parameters, as long
as your assumptions are documented. But in my opinion the added safety
is well worth it most of the time, because the only thing it costs you
is a little tiny bit of execution time. And if the program is determined
to be stable enough that the tests are no longer required, you can
remove them (through a build option - I wouldn't remove them
altogether). In some cases these tests can have a very significant
affect on the quality and usefulness of the program.

As an example, the audio editing application Cool Edit doesn't crash
very often, but when it does crash it does an amazing job of saving the
state of your work and restoring it later. This is very significant
because it deals with so much data, and operations on those data are so
time consuming and not always easy to reproduce. A crash that loses your
work could be a major problem. Fortunately, this usually doesn't happen
(based on my limited experience with it crashing - I've only seen it
happen a few times). This level of robustness is what all serious
programs should strive for.

-Kevin 

-- 
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Relevant Pages

  • Re: Youre appointed as Portability Advisor
    ... None of its behaviour is undefined by the Standard. ... to write to member A of a union and then read from member B, ... character type that treats the thing as an array of bytes. ... dereferencing a pointer to one ...
    (comp.lang.c)
  • Re: dereferencing memory location some time after deleting the same one
    ... The Standard says that any program that attempts to dereference ... > a pointer after the pointer has been deleted, ... memory from the kernel VM and manages the allocation of little pieces ... > He could get a crash. ...
    (comp.lang.cpp)
  • Re: Leading padding in unions
    ... Somewhere there is a provision that a pointer to the first ... address of each member. ... One of the defects of the standard is that it fails to guarantee something that almost every C programmer has relied upon frequently, which was probably intended to be guaranteed by the committee: that any conversion of a non-null pointer value from one pointer type to another that does not have undefined behavior, produces a new pointer that points at the same location in memory as the original. ...
    (comp.lang.c)
  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Re: Threading Model = "Both" query
    ... This C++ program also doesn't crash, ... is getting a raw interface pointer, ... the beginning calls through a dangling pointer, ... one MTA in the process the object can still live. ...
    (microsoft.public.vc.atl)