Re: ANSI C compliance
From: Ian Woods (newspub2_at_wuggyNOCAPS.org)
Date: 11/04/03
- Next message: Richard Bos: "Re: ANSI C compliance"
- Previous message: nobody: "Re: ANSI C compliance"
- In reply to: Roose: "Re: ANSI C compliance"
- Next in thread: Alan Balmer: "Re: ANSI C compliance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 4 Nov 2003 09:17:52 +0000 (UTC)
"Roose" <nospam@nospam.nospam> wrote in
news:LoJpb.13669$uC.12195@newssvr14.news.prodigy.com:
> I'm going to respond to this as a serious answer, even though you are
> trying to refute my arguments with a game popularized by Richard --
> pretend that the only thing that exists is what this newsgroup
> discusses. My article was about things outside ANSI C, so to reason
> about it correctly, you must not play that game.
Most of the time I skip through comp.lang.c and only really read the most
recent threads and threads to which I've previously contributed. This is
the case here. I wasn't aware that I'd stumbled into a game being played
between yourself and Mr. Heathfield.
With regards to what this newsgroup discusses, that's covered in the FAQ.
Even outside of the FAQ and this newsgroup, however, how do you define C?
For me that question is easy to answer: I have a document which defines
C. When people speak of C I look to the most authoritative definition of
C which I know about.
> "Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
> news:Xns94294FC6D5EC9newspubwuggyorg@217.32.252.50...
>> "Roose" <nospam@nospam.nospam> wrote in
>> news:3ZGpb.13633$TH6.7380@newssvr14.news.prodigy.com:
<snip>
> I'm not talking about "you" or "I". I'm talking about a real
> development team, that makes a real product. On such a team, _as a
> fact_, you will encounter old code, code written by someone other than
> yourself. Old code that is likely not written in ANSI C.
Here I'm using you not to refer to 'Roose' but as an impersonal pronoun
(though, rereading that's not completely clear). Usually, I don't use the
term 'one' because it sounds pretentious. But, I shall rewrite my
paragraph as it was meant and bugger the pretentiousness:
"If one's intention is to learn C, then do so. That is what is typically
discussed here. If one wanted to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too."
I hope that clears up the meaning.
>> <snip>
>> >This
>> > is shorthand for overengineering -- architecting a general system
>> > when a specific one will do.
>>
>> I don't see how writing in C is overengineering compared to writing
>> in 'a C like language provided by some vendor'. It takes me no longer
>> to write in C than it does to write in almost-C for an implimentation
>> I'm familiar with.
>
> Again, I'm not talking about "you". I'm talking about the average
> programmer who you might be working with. If you were a project
> manager, if such a programmer was not very familiar with ANSI C --
> what would you do? Would you schedule extra time for him to make his
> code ANSI compliant, or would you schedule just enough time for him to
> get it into a nice readable state, suitable for further modification?
Assuming he was hired as a C programmer, I'd expect him to be familiar
with C. If he were hired as a programmer of some particular
implimentations not-C I wouldn't have that expectation. In either case, I
would have ensured that original job description was accurate, and if
not, then I'd like to know why not and how that could be corrected. The
correction may very well involve some retraining time for the
accidentally mis-hired programmer. I certainly wouldn't, as a manager,
knowingly hire someone as a C programmer who wasn't one.
I have, on and off, worked on projects in C with people who are only
familiar with a particularly implimentation, and typically not the one
which the project is using. In these cases I do my best to vet their
code, and usually in a few weeks, no more than casual vetting is
required. It's rare that this makes projects overrun since there's
usually time for such code reviews already set aside.
>> > Writing 100% ANSI C when you are not in a special circumstance
>> > (like the one I listed above) is considered speculative generality.
>> > Portability is a feature of code. Thinking about portability to
>> > machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
>> > waste of time (at least business time, your personal time is free
>> > to be spent however you like), when you have no forseeable need for
>> > it.
<snip>
>> Indeed, it's a waste of time thinking about the portability issues
>> involved in making code work on such an array of systems. That's why
>> we leave it to C compiler programmers to do it for us. They worry
>> about that stuff, and I can just code in C secure in the knowledge
>> that my program will do what I intended it to do.
>
> Point taken, but I still contend that portability is a feature. It
> costs extra to make code ANSI compliant.
Yes, it would cost extra if you (or one) were to make code C after it
were written. I don't see how it costs extra if the code is written in C
in the first place. The handful of people who I've 'mentored' whilst they
were learning C didn't (at least as far as I saw) find their learning any
harder than a specific vendors C implimentation. The 'portability' they
effectively get without having to go out of their way thinking about it
because they naturally code the way they do.
<snip>
Ian Woods
- Next message: Richard Bos: "Re: ANSI C compliance"
- Previous message: nobody: "Re: ANSI C compliance"
- In reply to: Roose: "Re: ANSI C compliance"
- Next in thread: Alan Balmer: "Re: ANSI C compliance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
