R
Richard Heathfield
Roose said:
Since no implementation is required by the Standard to accept a void main
program, it would be folly to write such a program (freestanding
implementations notwithstanding).
Since no implementation is required by the Standard to accept a void main
program, it would be folly to write such a program (freestanding
implementations notwithstanding).
B
Ben Pfaff
We (meaning the regulars) discuss things other than C very little
here. Someone (Chris Torek?) once formulated it along the lines
of "Every time you make an on-topic post, that's like depositing
one cent ($0.01). Every time you make an off-topic post, that's
like withdrawing a dollar ($1.00). Try to keep your balance
positive."
R
Richard Heathfield
Yes, correct. But notice this: you will never (okay, never say never, but
you know what I mean) see a regular contributor /begin/ a thread with an
off-topic article. Topicality is important to this newsgroup, and we do
strive to remain topical. Nevertheless, sometimes the conversation drifts
off-topic, but as long as it remains interesting to the group, it can
survive. When regular contributors start to complain about the topicality
of a drifting thread, it isn't long before the regular contributors stop
posting to that thread. In any event, as Kaz once said, posting clueful,
well-thought-out contributions to topical discussions here is like putting
pennies in the bank, and posting off-topic articles is like taking out
dollars. The trick is not to get overdrawn (although I must admit I
wouldn't insist on a 100-1 ratio).
I don't, but I'll gladly qualify what I said. Yes, we do sometimes get into
interesting side-tracks. That doesn't mean we are prepared to throw the
doors wide open and see this newsgroup go down the same spiral into chaos
that nearly sank comp.lang.c++ a few years ago.
C has to be the start point, though.
G
Guest
(oh dear...I'm top-posting..)
Hey, Roose, isn't it fun to catch these people in a blatant lie which
was designed to attack and vilify and then watch them wiggle and squirm
to get out of it?
I find it fascinating that Richard begins his defense of one lie with
another:
"you will never see a regular contributor /begin/ a thread with
an off-topic article."
Of course, he does try to explain away this one with his lame 'never say
never' comment...but if he really meant this, he would have said
something like:
You will almost never see a regular contributor begin a thread with
an off-topic article.
or
You will rarely see a regular contributor begin a thread with
an off-topic article.
or nearly an infinite number of other possible, and truthful, wordings.
Various regulars have, of course, started totally off-topic threads in
the past...it's rare, but it does occur, and, as Richard admits, without
the vilification that they will heap onto others outside their little
circle.
--
Hey, Roose, isn't it fun to catch these people in a blatant lie which
was designed to attack and vilify and then watch them wiggle and squirm
to get out of it?
I find it fascinating that Richard begins his defense of one lie with
another:
"you will never see a regular contributor /begin/ a thread with
an off-topic article."
Of course, he does try to explain away this one with his lame 'never say
never' comment...but if he really meant this, he would have said
something like:
You will almost never see a regular contributor begin a thread with
an off-topic article.
or
You will rarely see a regular contributor begin a thread with
an off-topic article.
or nearly an infinite number of other possible, and truthful, wordings.
Various regulars have, of course, started totally off-topic threads in
the past...it's rare, but it does occur, and, as Richard admits, without
the vilification that they will heap onto others outside their little
circle.
Richard Heathfield said:
--
R
Richard Heathfield
It's unfortunate that you choose the word "lie" to describe a poor choice of
wording, but c'est la vie.
I will cheerfully accept the alternative wording, but do you have an actual
example of an OT comp.lang.c thread started by a regular contributor?
Example, please.
I would hope that (in the general case) those who innocently start OT
threads are not vilified, but merely redirected. It is unfortunately the
case that some people are rather aggressive in their defence of topicality,
and I don't deny that I have been guilty of this myself in the past. I try,
nowadays, to be less vehement when dealing with ignorance (as opposed to
wilful dontgiveadamnness). I think I have succeeded.
R
Randy Howard
To me, that is the primary value of this newsgroup. If you need
to know if a particular construct is portable across a wide range
of platforms, you need not bother ask that question in one of
the OS, H/W platform or compiler specific newsgroups. Come here.
The range of knowledge, across an incredibly wide range of
development environments is staggering. If you want to know
how to get a far pointer to the video adapter memory under DOS
using MSVC 1.52, go elsewhere.
Neat little stories about how Roose could manage to take standard
ISO C and turn it into something platform-dependent so he won't
get fired by his off should be left for something like
alt.folklore.computers instead.
R
rihad
Richard said:
Okay, who was it: Kaz Kylheku OR Chris Torek?
D
Dave Vandervies
rihad said:Okay, who was it: Kaz Kylheku OR Chris Torek?
Quoth Google:
http://groups.google.com/[email protected]
So it looks like it was Kaz.
dave
P
pete
Roose said:
Your example makes no sense.
A conforming compiler is allowed to accept void main().
A confroming compiler is allowed to reject void main().
The standard says neither compiler is wrong.
On the other hand, and to the point,
the standard says that all conforming compilers must accept
int main(void).
int main(void) is portable code.
int main(void) will work on your compiler, regardless
of whether your compiler accepts void main() or not.
Your void main() code is not portable. The problem is your code.
Like I said:
M
Mark McIntyre
Ian Woods is someone else who you might we well advised to do a
websearch for, before dismissing his arguments.
M
Mark McIntyre
On Tue, 4 Nov 2003 15:03:34 -0500, in comp.lang.c ,
Yeah., whatever. Welcome to the bitbucket,
Fuckwit.
Yeah., whatever. Welcome to the bitbucket,
Fuckwit.
M
Mark McIntyre
This is a stupid statement. In the Real World, which you seem not to
inhabit, computer programs interact with their surroundings. This
interaction is by definition Implementation Specific, and consequently
not part of the C language. Naturally there are parts of what we all
write that are not C. So what?
The C language is defined by ANSI (more accurately ISO). so your
statement is meaningless. But to interpret it as you probably meant,
the answer is simple - you want to discuss gcc. pop over to the gcc
group. You want to discuss MSVC, you know where the microsoft gruops
are.
Bye now.
S
Steve Summit
Roose said:
Sure, but none of us -- you, I, or Ian -- is talking to or about
that earlier programmer. We're talking about us -- you, me, and
anyone else who happens to be listening, who we'd like to convince
to do better than the earlier programmer.
If I cared about the long-term maintainability of the company's
code base, and if my programmers were insufficiently competent to
so maintain it, I might schedule some time for those programmers
to learn the necessary skills.
The same can be said about any feature, meaning that the way to
save the most money is presumably not to try to write the code at
all.
If the short-term costs of coding portably truly don't promise
any long-term benefits, or if you're trapped by deadline
pressures under which you don't have time to do things right
(though you might have time to do them again), you might decide
you can't afford the portability.
But for those of us who are used to doing it, the short-term cost
of the kinds of portability we're talking about here is zero.
The nicely portable code flows out of our fingers as easily
as the nonportable code, that you seem to be trying to condone,
fumbles out of the fingers of those hypothetical earlier
programmers. The question is -- which kind of programming are
we trying to encourage? And if we constantly give everyone carte
blanche to write code which falls down on the various software
virtues -- portability, maintainability, correctness, repeatability,
predictability, efficiency -- if every day we let them get away
with that which is merely expedient, when will we collectively
ever learn to do better?
The expediency you seem to be condoning is responsible for many
of the ills in software development. I understand that you're
willing to make tradeoffs in favor of expediency at the expense
of other virtues, but what always puzzles me is why you and so
many posters before you keep coming in here and insisting that
the rest of us are wrong for making, or advocating, a different
set of tradeoffs.
Software engineering is still a pretty flimsy discipline.
For the most part, we're all slogging along through the mud,
often waist deep, often falling on our faces in it. Yet when one
of the sloggers dares to suggest that we invent paved roads, and
wheeled vehicles to move swiftly and easily on them, someone else
derides this vision as an ivory-tower fantasy, ungrounded in the
real world. 'Tis sad.
Steve Summit
(e-mail address removed)
S
Steve Summit
Roose said:
Please don't tar everyone with the same brush. I don't know all
the "regulars" here and I don't speak for them any more then they
speak for me, but when *I* advocate portable programming practices,
or the other practices I believe in, I can assure you I'm not
"whacking off". The practices I advocate are the ones I try to
use myself, and where I use them is not in some dusty ivory
tower, but rather in the rough-and-tumble world of real-life
software development, where the people I work for are pleased
that I do not trouble them with design decisions like "how
portably should I write this?" (which are arguably mine as an
engineer to make), but rather deliver code that works, on time,
and that adapts well to its changing requirements, and that
doesn't need lots of hands-on maintenance later.
The practice of focusing rather zealously on portability and
correctness, which I'm pleased to say I learned in large part
from the people who were regulars back when comp.lang.c was
called net.lang.c, is very much *not* an end in itself.
It's a practice which brings so many real benefits to the
programs I write that I can't even remember them all just now.
What's more, plenty of them are benefits which I can enjoy right
away, i.e., I don't even have to wait patiently for some far-off
long-term benefit.
You'll probably say, "Wait a minute, where did correctness come
in, no argument there, we were talking about portability."
But to me, programming portably is so important (and comes so
easily) that it's actually become part of correctness. I don't
"port" code any more; what I do (if anything) while recompiling
code in a different environment is to fix the portability bugs
it had all along but which I have only just now discovered.
Steve Summit
(e-mail address removed)
S
Steve Summit
Roose said:
If you stop to think about it, this is a pretty meaningless
statement. Take out the words "truly standard C as valued by the
regulars in this newsgroup" and replace them by any positive
attribute of code you can think of:
Writing functional code is time-consuming if you're not experienced.
Writing maintainable code is time-consuming if you're not experienced.
Writing compact code is time-consuming if you're not experienced.
Writing efficient code is time-consuming if you're not experienced.
Writing correct code is time-consuming if you're not experienced.
Are all of these, then, "not considered good practice" in the
business world?
The obvious solution here is to work on gaining some good
experience, so that good code (by any metric) doesn't have to be
so time-consuming to write.
And this is a very tricky set of ideas to think properly about.
Yes, sometimes when you overengineer something you're wasting
resources which could be better spent elsewhere, no question.
But other times, a certain level of overengineering is not just
good practice, it's mandatory. In the real world, for example,
it's not "overengineering" to build a structure to withstand a
severe storm. To build a house that can withstand exactly the
weather conditions you're experiencing today, but which falls
down during the first rain or windstorm, would be folly.
I don't think anyone here is advocating always writing code which
tries to be portable to machines with 9 bit bytes. (Personally,
I don't even know how to.) Your other examples are even more
absurd, since no C program (let alone a portable one) can even
tell how many stacks there might be.
You keep saying, "is considered". Is considered by *who*?
By you? By the managers at the software companies that foist upon
the world laughably insecure, virus-infested operating systems,
and word processors that perform functions that no sane person
would require of them and ("Ford added savagely") go beep to tell
you when they've done it? They can have their opinions of what
"is considered" good practice, thank you; me, I think I'll use my own.
Programmers who let executives tell them how to write their code
are jointly responsible for the unmaintainable failures they go on
to create.
Steve Summit
(e-mail address removed)
J
Jack Klein
I personally write few completely 100% strictly conforming programs on
the job. When the opportunity presents itself, I do, which occurs a
surprisingly large fraction of the time.
Your "real world" is most certainly not the same as my "real world".
One of the world's most used C compilers, gcc, has a command line
switch to compile FORTRAN. That's a "real world" use of a C compiler.
But it has nothing to do with the C language, which has one and only
one definition.
Amazingly enough, I manage to write code that is non-standard
conforming that works as expected on multiple platforms. Because I
know enough about the C language and its implementation-defined
aspects.
For a current product I designed a communications protocol for an
internal CAN network. And I wrote code to implement that protocol.
That code is most certainly not 100% strictly conforming standard C.
But that somewhat non-standard code compiles and runs correctly on
four different processor types that interface to that bus:
1. An 8-bit big-endian microcontroller (8051 architecture). Chars
have 8 bits and plain char is signed.
2. A 16-bit big-endian microcontroller (Motorola HC11 architecture).
Chars have 8 bits and plain char is signed.
3. A 16/32 bit little endian DSP (Texas Instruments 28xx
architecture). Chars have 16 bits and plain char is signed.
4. A 32 bit little-endian RISC processor (ARM9). Chars have 8 bits
and plain char is unsigned.
Now I won't say there wasn't a little debugging involved, but I knew
when I wrote it that the entire code for protocol, including parse
tables, parameter packing and unpacking from CAN packet octet streams,
and all the rest, would work on all four of these architectures when I
wrote it.
The routine that converts between individual octets and 8, 16, and 32
bit signed or unsigned variables runs unchanged on all four platforms,
even the DSP which actually can't address memory in less than 16 bit
chunks.
You entirely miss the point. What percentage of all trivial and
non-trivial C program, no matter how platform specific they are, could
be written in completely standard C? I doubt if you would ever find a
non-trivial program where this figure is less than 50%. Even in many
large programs with loads of extensions, if is frequently above 90%.
Again you have it wrong. The question is not what fraction of
programs are nothing but 100% strictly conforming C. The question is
the average part of all programs that is, or could be, standard C.
And that fraction is very high indeed.
One who is not sufficiently experienced in writing C programs properly
should not be employed to do so, except perhaps as an apprentice, and
should not claim to be a professional C programmer.
Yes, the biggest problem with software in general is not C or C++ or
Pascal or Visual Basic or any other programming language. It is
programmers who believe like you, that business is served by shoddy
guesses and half-baked efforts.
Would you want to fly on an airliner engineered by aviation engineers
who had their attitude about learning their discipline and doing
design work that you express toward writing software?
Would you want to be operated on by a surgeon who decided that
performing quality surgery is too time-consuming to learn, and
couldn't be bothered to take the time to accumulate the knowledge
necessary, because "it is not considered good practice, since time =
money".
There is a field of study that is called "software engineering", and
there is extensive research, much of it headed up by the US government
funded Software Engineering Institute at Carnegie-Melon University.
Engineering is a discipline, and there is sadly far too little
discipline in software development. The field is too new, the growth
too fast.
[snip]
This is very far afield from the main thrust of your post, however.
You think there is value in diluting comp.lang.c to throw in
discussions about anything anyone is trying to do with any C compiler
anywhere. I, and many of other the regulars, disagree.
It makes no difference whether you are writing C for a PIC
microcontroller, a Cray supercomputer, a game console, or an
"ordinary" Windows or Macintosh PC. A large percentage of the code
should be or at least could be perfectly standard legal C. And aside
from platform-specific issues that have nothing to do with the topic
of this group, that is the C language, a certain percentage of the
problems in even the most platform-specific program will be C language
issues.
Usenet groups that can't stay focused on a topic die. Our "sister"
group comp.lang.c++ nearly had that experience about five years ago,
where swarms of MFC and Windows specific newbies caused many of the
most knowledgeable regulars to leave. Fortunately, a group of
determined regulars turned back the tide barely in time, and
comp.lang.c++ is a valuable resource for C++ programmers today.
In point of fact, some of the regulars in comp.lang.c are among the
most knowledgeable C programmers in the world, at least among those
who chose to offer aid and advice publicly for free. Destroy the
topicality of the group, and you drive away that expertise.
So if you want to discuss platform-specific aspects of your code, take
it to the appropriate platform-specific support group. But when you
have a truly complex C language issue, be glad this group is here for
you to post it, because if it is really difficult you have a better
chance of correct help here than anywhere else on Earth.
And keeping this group on-topic is the best way to ensure that this
resource remains available.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
J
Jack Klein
I have to disagree with your parenthetical comment.
"int main()" works, and "void main()" may or may not, on a conforming
hosted environment, because the behavior of calling a function is
undefined if the signature, which includes both arguments and return
type, does not match between caller and callee.
There happen to be quite a few compilers for embedded systems which
come under the category of free-standing implementations. It is not
uncommon for such implementations to specify that the user-written
start-up function signature should be "void main()", generally "void
main(void)", as there are never anything like command line arguments
in such environments.
If such a compiler specifies that user programs should start with
"void main()", then starting one with "int main()" is just as much
incorrect as using "void main()" instead of "int main()" in a hosted
environment.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
R
Richard Heathfield
Jack said:
Well, you might just be disagreeing with the word "notwithstanding", which
-as a quick check of the dictionary reveals - doesn't mean quite what I
thought it meant. :-% I intended it to mean "not being included in my
sweeping generalisation". English was never my strong point.
Yes, and I was /trying/ to exclude such implementations from my more
sweeping comment. That is, I believe that we...
....no, I am now /sure/ that we are in agreement.
J
Jack Klein
You Brits never could write (or speak) no good 'Nited States!
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
R
Roose
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.
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, 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.
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.
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.
What percentage of programmers do you think are used to doing it?
(Honestly, I am not sure of the answer). If you were a hiring manager,
wouldn't this unnecessarily limit your pool of applicants if you were to
insist on it?
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.
I'm not saying you're wrong, but rather I'm objecting to the extremely
narrow focus demonstrated in this newsgroup. 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. 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. 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.
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. 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.
Roose
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.
Steve Summit said:
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.
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, 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.
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.
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.
What percentage of programmers do you think are used to doing it?
(Honestly, I am not sure of the answer). If you were a hiring manager,
wouldn't this unnecessarily limit your pool of applicants if you were to
insist on it?
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.
I'm not saying you're wrong, but rather I'm objecting to the extremely
narrow focus demonstrated in this newsgroup. 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. 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. 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.
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. 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.
Roose