Let me thank you first for making a reasoned argument. My time is not
unlimited, so let me ignore the vast majority of responses and focus
on the ones such as this that rely logical argument -- AND acknowledge
the existence of life outside the newsgroup.
OK, I think the real point was lost somewhere there, but my contention
is that ANSI C being "better" is dependent on the situation, and not
an absolute fact.
Such instances are few and far between in my experience. Equally, my
experience is that writing code to be as portable as possible can often
save you time *BEFORE* you reach the deadline.
A REAL example:
Writing a significant chunk of embedded code. Since the code was as
portable as possible I ended up porting it to a Silicon Graphics
workstation and debugging it there because there were far better tools
available including the ability to read some aircraft attitude data and
the digitised video and overlay a line of the video indicating where my
software believed the horizon was. This saved a significant amount of
time on that particular project.
Right, let me suggest that if you were a manager -- with limited
budget as always -- that training programmers to write ANSI C and
converting old code to ANSI C would often be on your cut list. Also,
Converting pre-ANSI code to ISO C is not required to write any
modifications in ISO C. By making such changes as you deal with the
relevant parts of the code you can gradually ease the burden of
maintenance without a significant bad effect on your immediate
timescales and budgets. I know this through personal experience just as
I know that gradually making the change can expose problems that only
occasionally cause the application to misbehave and allow you to fix
them.
if you were a hiring manager, I would suggest that it is often the
case that one programmer who does not "care" about ANSI C would often
suit your purposes better than another that does.
I would expect and good C programmer to be able to cope with pre-ANSI
code on a legacy project. I know this because I *AM* working on such a
project. I also know that the head of my SW department would far prefer
people who understand and care about standards compliant software than
those who don't care about it.
Also correct, but my contention is that other features fair better in
a cost/benefit analysis than (often speculative) portablity. Other
features cost money as well, but they also generate money. Writing
ANSI C for a single device does not, in general, generate any money.
If you know how to write portable code then my experience is that in
most cases it does not cost more than writing non-portable software.
I think this decision is made fairly often in the business world. But
if you have experience that demonstrates otherwise, I'd be interested
to hear about it.
See my comments above. All are based on real personal experience in the
defence and commercial worlds.
What percentage of programmers do you think are used to doing it?
(Honestly, I am not sure of the answer).
Anyone in the defence industry will have their code peer reviewed so it
only takes a few people for the word to slowly spread. Outside the
defence industry things are different.
Personally I learnt most of my C from K&R2 referring to the manuals for
the compiler when I needed to do something HW specific and *knowing*
that the HW specific stuff I was doing was specific to the
implementation as it was documented as such. This does not mean that I
did not introduce non-portable constructs by mistake in code I
considered to be portable, but it did bring things a long way towards
it.
If you were a hiring
manager, wouldn't this unnecessarily limit your pool of applicants if
you were to insist on it?
As with everything, when recruiting you weigh the cost/benefit. If
someone is good enough and prepared to learn but does not know enough
about portable coding one might consider them just as one would reject
someone who could only write simple portable programs and was not
willing to learn.
I would say that the last 4 virtues you mention are _absolute_
virtues, while the former is a business decision. I completely agree
that we should strive to do better -- but our time is limited, and
focusing on one thing comes at the expense of others. I would much
rather (and my boss would much rather me) learn a new rendering
technique, rather than study the ANSI C standard. I would much rather
write a unit test than make my code ANSI compliant.
Making your code ISO compliant can remove bugs you are not aware of and
your compiler can probably provide a lot of help in doing this and if
not you may be able to run it through gcc with maximal warnings to see
the issues. So you should at least try to see how close you are and
whether there is anything immediately critical that you can resolve as
*part* of your testing. Potentially you look through the optional
warnings s your compiler can generate and enable ones that are most
likely to show up real problems, such as -Wsequence-point on gcc.
You don't have to spend a lot of time/money in one go, 5 minutes per
day would be a start and could remove unexplained crashes that you
can't track down.
I'm not saying you're wrong, but rather I'm objecting to the extremely
narrow focus demonstrated in this newsgroup.
This group is about programming in C and not about implementation
specifics. If you don't like it then use another group. There are plenty
of places for discussing the specifics of any given implementation
where you will find a lot more expertise on that specific
implementation.
The posts come at the
expense of the larger question -- in recent threads the larger
questions being answering an interview question (so as to demonstrate
knowledge), and also helping a newbie learn C.
A lot of helpful information was posted and people I know who *have*
been interviewers would have liked many of the answers.
Many people have
already stated that newbies are welcomed here. In that case, it would
be prudent to address them in a manner that they can understand,
rather than turning them off to the C language with nitpicking.
Accurate answers are given (and inaccurate ones corrected) and if
someone asks for further explanation it will be provided. Many people
*try* to pitch their answers at the apparent level of knowledge of the
person asking the question whilst still doing this.
I
would also contend that learning strict ANSI C is not the first step
for a beginning C programmer. There is enough challenge in getting a
working program together.
It is far easier to get a working program together if you set the
warning level on your compiler as high as possible and try to understand
and *resolve* the warnings (not just cast them away) than if you don't
do this. Such a method also leads you naturally in to producing ISO C
programs.
Also, trying to use libraries outside of those provided by the C
standard means you have *more* to learn and so makes the job harder.
However, we (or I at least) don't object to people new to see using the
simpler external libraries, it is just that we will direct them else
where for help with those libraries.
Completely agree. However, I would say that the line-by-line
deficiencies in code (e.g. non-ANSI code) are completely and utterly
overshadowed by the lack of design knowledge by the average
programmer.
When I started my career I was not expected to do the design. Instead I
would be presented with the design (if there was any significant
complexity) and be asked to code it. Thus I was exposed to good design
at any given level before I was expected to do it, and when doing design
work or coding others would look at my work and provide help and advise
as required. IMHO this is a correct way to tackle the issue and allows
the learning of both good coding in ISO C and good design at the same
time.
I have also been in the position of mentoring fresh graduates and I
would gradually build up the complexity of what they were required to do
making sure they were heading in the right direction before letting them
loose.
Attack the worst of the ills first. And the one that has
the most effect on maintainability and understandability of code is
the fact that your average codebase is filled with faulty
abstractions, or, sadly, none at all.
However, those ills are for other groups such as comp.unix.programmer,
although people do point out design flaws when reviewing code that is
posted here in order to move people in the right direction. Asking for
such help here is off topic, but providing it *whilst* dealing with the
C issues is considered acceptable based on what I've seen.
. and while doing that I have made a