Re: How to make C look like C++
From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 10/13/03
- Next message: jeffc: "Re: How to make C look like C++"
- Previous message: jeffc: "Re: How to make C look like C++"
- In reply to: Fronsac: "Re: How to make C look like C++"
- Next in thread: Fronsac: "Re: How to make C look like C++"
- Reply: Fronsac: "Re: How to make C look like C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 12 Oct 2003 22:39:51 +0000 (UTC)
Fronsac wrote:
>> The code failed, on to ensure that a resource acquisition request was
>> successful before relying on the availability of the resource. I guess
> some
>> people think that's okay for demo code (unless you're trying to
> demonstrate
>> robust programming practice!), but it's not okay for real code.
>
> You're absolutely right. Personally, I think this kind of practice is OK
> at best for demo code, but it's still bad at the same time because it
> doesn't underline the importance of doing the checks in the first place.
Precisely.
> After all, if the checks were there, maybe people would realize that these
> kind of checks are important and have to be done.
Just a couple of minutes ago, I was helping a guy debug some code in IRC.
He'd said that he intended to put in the robustness checks after he'd got
the code working (it was segfaulting). I spent a few minutes putting in
some robustness checks and, guess what? It stopped segfaulting.
> The problem is, I don't
> remember a teacher penalizing me or anyone for forgetting to check if a
> malloc or new succeeded.
The quality of teaching in the field of programming is not all it could be.
> In fact, you could hand in a semester project
> which didn't test for NULLs after allocation and your grade didn't suffer
> at all. I was even told once that these checks are useless these days and
> shouldn't bother with them!
I was once told the moon is made of green cheese. I believed it, too.
Fortunately, this belief wasn't too difficult to shake in the light of
improved information, and I learned at the same time that I shouldn't
believe everything I'm told.
> So anyway, to make a long story short when I said "errors" in the previous
> post I meant errors in OOP thinking, or some design failure which might
> create problems later when expanding the code. Since I'm no expert on the
> subject I can't really tell.
If you're not an expert in the subject, I again urge you to re-consider
whether applying for a job requiring such expertise is a wise thing to do.
<snip>
> [...] I don't assume as much stuff as I did before. As much as it
> bugs me to write these if(p == NULL) tests, especially since
> malloc almost never NULLed on me, at least I can understand the
> importance of doing these kind of tests and most importantly,
> I think about doing them when I code.
Words of wisdom. It would be nice not to have to check this stuff, but on
the other hand, it's also nice to have full control over what to do if it
/does/ fail. I like to be able to use alternate strategies for achieving my
objective, rather than have the whole program fall over for the want of a
few KB of memory.
-- Richard Heathfield : binary@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
- Next message: jeffc: "Re: How to make C look like C++"
- Previous message: jeffc: "Re: How to make C look like C++"
- In reply to: Fronsac: "Re: How to make C look like C++"
- Next in thread: Fronsac: "Re: How to make C look like C++"
- Reply: Fronsac: "Re: How to make C look like C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
