FACTORIAL PROGRAM

[Flash Gordon]

Ai wrote, On 17/04/07 22:58:

#include <iostream>

If you are going to post C++ answers, please drop the cross post to
comp.lang.c

 

[James Kanze]

(e-mail address removed) (Marcus Kwok) writes:

[...]

Personally, I prefer end-of-line comments to /* ... */ comments ("//"
in C++, "--" in Ada, "#" in Perl, etc.) -- but if I'm programming in C
I have to allow for the possibility that they may not be available.

Why? They've been part of the language officially for 8 years
now, and it was doubtlessly clear a year or two before that that
they would be part of the upcoming standard. They're trivial to
implement (not like export in C++). So unless you're using a
compiler that's close to ten years old, it should support them.

 

[James Kanze]

Why bother commenting it out? Just delete it and use your editor's undo
or SCM to get the code back if you want it.

You might have other changes that you don't want to show up in
SCM before you've tested them. And your editor's undo will
typically get lost if the machine crashes in the meantime.

Still, writing the current state to a separate file before
editing it shouldn't be that difficult.

On the other hand, it might be worth commenting out if you
precede the commented out part with something like:

// This doesn't work because...

If the commented out code is significantly simpler than what you
replace it with, you can be sure that in the absence of such a
comment, some maintenance programmer will reinvent it, to
simplify, and whatever bug you just fixed will reappear.

Of course, for this sort of commenting out, you want real
comments, that look like comments, and not #if 0.

 

[Richard Heathfield]

James Kanze said:

(e-mail address removed) (Marcus Kwok) writes:
[...]
Personally, I prefer end-of-line comments to /* ... */ comments ("//"
in C++, "--" in Ada, "#" in Perl, etc.) -- but if I'm programming in
C I have to allow for the possibility that they may not be available.

Why? They've been part of the language officially for 8 years
now, and it was doubtlessly clear a year or two before that that
they would be part of the upcoming standard. They're trivial to
implement (not like export in C++). So unless you're using a
compiler that's close to ten years old, it should support them.

How often must we explain this?

Yes, they're part of standard C99. Yes, we jolly well ought to have
C99-conforming compilers by now. But we don't. So we use C90-conforming
compilers instead. And in C90, // is a syntax error. Now, some
compilers do indeed support it as an extension, yes - BUT to enable
that extension can involve switching off other conformance checks too,
and that's a price too high for me to pay. So, until such time as
C99-conforming compilers are in widespread use, I'll stick to /* */ -
and even then, /* */ still scores over // insofar as it doesn't get
broken by Usenet folding, and that's because it can cover multiple
lines (and is cheaper from the third line onwards).

 

[Ian Collins]

You might have other changes that you don't want to show up in
SCM before you've tested them.

Then your edit/test granularity is too coarse.
grumble grumble....

 

[Kelsey Bjarnason]

[snips]

Since this thread is FUBAR I have to ask this - When commenting code:
what style is "the best" one? (Also: when commenting code: what style
do you use?)

The only "best" - objectively - is correct commenting; that is, the
comments explain what the code does, without being simply a repeat of the
code. "Add 1 to x", as a comment on a line reading x++; doesn't buy
anything. A comment should explain what a function or block (and
sometimes, depending how hairy the code is, line) is doing and, where
necessary, why it is doing it. It should also, at least for
function-level comments, give an indication of what inputs are acceptable
and what happens on errors, success, etc.

As to the *style*... well... that's one of those religious war type
questions. However, I'll suggest that the following are not the best:

/* this is */
/* a multi- */
/* line comment */

/****************
* this is *
* a multi- *
* line comment *
****************/

And other variations on the theme. Simply put, they're a pain in the
proverbials to update - and if they're a pain, chances are they won't be
updated. Contrast that to this:

/*
This is
a multi-
line comment
*/

If you need to add or change a line, you can focus on the "meat"; the
borders and whatnot don't get in your way. If you prefer comments to
really stand out, or have something you really need to draw attention to,
try this:

/*********************
This is an important
comment. Please
read it.
********************/


Stands out, will be found readily by even casual visual inspection of the
code, yet it's still readily editable.

KISS is the guiding principle, IMO. Skip the fancy formatting; that makes
it less editable, less likely to be correctly maintained. Use a format
which a developer busy concentrating on other things can modify the
comment easily and efficiently and he's going to be a lot more likely to
keep those comments current and correct.

 

[Peter Nilsson]

James Kanze said:

Why? [// comments] 've been part of the language officially for
8 years now, and it was doubtlessly clear a year or two before that
that they would be part of the upcoming standard.

2? Try another 10.

How often must we explain this?

Until you finally understand!

Yes, they're part of standard C99. Yes, we jolly well ought to have
C99-conforming compilers by now. But we don't.

No, what we have is a shite load of C90 compilers that support them
as future compatible extensions.

So we use C90-conforming compilers instead.

How many non-trivial C90 programs would be affected by turning on //
recognition? Millions, thousands, hundreds, tens...?

And in C90, // is a syntax error. Now, some
compilers do indeed support it as an extension, yes

Some? How many less than ten years old don't?

- BUT to enable that extension can involve switching off other conformance
checks too,

So consult the vendour. Not only are you not part of the solution to
the
lack of C99 compilers, you're part of the problem.

and that's a price too high for me to pay.

You could always use a C++ compiler and gain a few checks that C
lacks. ;-)

 

[Richard Heathfield]

Peter Nilsson said:

James Kanze said:

Why? [// comments] 've been part of the language officially for
8 years now, and it was doubtlessly clear a year or two before that
that they would be part of the upcoming standard.

2? Try another 10.

How often must we explain this?

Until you finally understand!

But I already do.

No, what we have is a shite load of C90 compilers that support them
as future compatible extensions.

Fine, I have no problem with that, provided those compilers also provide
a way to support them that does not also involve taking down other
conformance checks.

How many non-trivial C90 programs would be affected by turning on //
recognition? Millions, thousands, hundreds, tens...?

Turning on // recognition isn't the issue. Turning OFF other conformance
checks *is*.

Some? How many less than ten years old don't?

I don't know. I do not pretend to be an expert on the entire gamut of C
compilers, but I do know it's safe to say "some", whereas it may not be
safe to say "all".

So consult the vendour.

Fine. So what?

Not only are you not part of the solution to
the
lack of C99 compilers, you're part of the problem.

You seem to think that the lack of C99 compilers is a problem. It isn't.
It's merely a fact. Whilst it remains a fact, I will continue to write
in the common subset of C90 and C99. When C99 is as widely distributed
as C90 (or more so), it will perhaps be worth switching to C99. In the
meantime, if people post code that I can't compile without editing it,
they increase the chance that I won't bother to do the edit and won't
bother to answer their question.

You could always use a C++ compiler and gain a few checks that C
lacks. ;-)

<grin> But that just wouldn't be C!

 

[Peter Nilsson]

Peter Nilsson said:

Yes, [// comments are] part of standard C99. Yes, we jolly well ought to have
C99-conforming compilers by now. But we don't.

No, what we have is a shite load of C90 compilers that support them
as future compatible extensions.

Fine, I have no problem with that, provided those compilers also provide
a way to support them that does not also involve taking down other
conformance checks.

It's interesting that you're talking about checks and not behaviours.
I would
think that a master of C would be more concerned with the latter over
the
former.

But why is it important for the _compiler_ to provide the checks?
What's wrong
with lint style tools? [What's wrong with yourself!] If you're about
to say that lint
isn't a part of the implementation, then I say the implementation is
as much
supplied by the programmer as by some compiler vendour.

For example, the execution environment and program invocation are
controlled
more by the programmer and end user than an implementation. And they
can
both affect conformance.

Using an additional tool to aid compilation fits with the notion of
'as if' in my view.

Turning on // recognition isn't the issue. Turning OFF other conformance
checks *is*.

You have other means for attaining those diagnostics.

Whilst the standard requires some diagnostics, it is still up to the
programmer
to insure conformance of their code, not implementations.
Implementations
can have bugs too. There's also the fact that there are degrees of
quality in
diagnostics across different implementations.

I don't know. I do not pretend to be an expert on the entire gamut of C
compilers, but I do know it's safe to say "some", whereas it may not be
safe to say "all".

The word you're avoiding is 'most'.

You seem to think that the lack of C99 compilers is a problem.

The lack of support for standardised improvements is a problem for the
many
programmers calling for them. We're not talking about wish lists,
we're talking
about standardised constructs.

It isn't.

In the sense that you can still build a house out of straw. Some us
would prefer
to live in more modern accomodation with modern facilities.

It's merely a fact. Whilst it remains a fact, I will continue to write
in the common subset of C90 and C99. When C99 is as widely distributed
as C90 (or more so), it will perhaps be worth switching to C99.

All I can say is thank God that tennis players aren't still using
woden rackets.
You can argue that the modern game isn't what it once was, and I for
one
will agree. But I can only dream of what the greats of the past could
do if
they had the luxury of using more modern technology.

In the meantime, if people post code that I can't compile without editing it,
they increase the chance that I won't bother to do the edit and won't
bother to answer their question.

True, but if you aren't qualified to comment on given code because
you've
chosen to limit your exposure to the newer standard, your absense of
reply
is, if anything, more desirable. ;-)

<grin> But that just wouldn't be C!

Is any subset of C90?

 

[Keith Thompson]

[...]

But why is it important for the _compiler_ to provide the checks?
What's wrong
with lint style tools? [What's wrong with yourself!] If you're about
to say that lint
isn't a part of the implementation, then I say the implementation is
as much
supplied by the programmer as by some compiler vendour.

to this:

But why is it important for the _compiler_ to provide the checks?
What's wrong with lint style tools? [What's wrong with yourself!] If
you're about to say that lint isn't a part of the implementation,
then I say the implementation is as much supplied by the programmer
as by some compiler vendour.

The former is very difficult to read. It looks like you're writing
lines up to about 85 characters, and *something* is reformatting your
text by splitting each line rather than by filling an entire
paragraph.

If you can keep your text columns down to no more than 72 columns and
format them properly, it will be a lot easier to read your articles.
Thanks.

 

[Richard Heathfield]

Peter Nilsson said:

Peter Nilsson said:

Yes, [// comments are] part of standard C99. Yes, we jolly well
ought to have C99-conforming compilers by now. But we don't.

No, what we have is a shite load of C90 compilers that support them
as future compatible extensions.

Fine, I have no problem with that, provided those compilers also
provide a way to support them that does not also involve taking down
other conformance checks.

It's interesting that you're talking about checks and not behaviours.

That's because, for the most part, C99 has not introduced behavioral
changes to C90 code. In fact, I can't think of any C90 code that is
legal C99 but behaves differently (except, appropriately enough, for
the //* thing!).

I would think that a master of C would be more concerned with the
latter over the former.

Let me know when you find one, then.

But why is it important for the _compiler_ to provide the checks?

Because I'm too lazy to do it myself? Because I'm too lazy to use lint?

[The lack of C99] isn't [a problem].

In the sense that you can still build a house out of straw. Some us
would prefer to live in more modern accomodation with modern
facilities.

ROTFLMBO!

You can C99's facilities "modern"?

Oh, come on, Peter. You can call a 1979 rock star "modern" and I will
try not to laugh. You can call a 1989 Ford Escort "modern" and I will
do my best not to grin. But if you call C99 "modern", it will be touch
and go whether I can fend off actual hysterics. Where are the "modern"
facilities of C99? We haven't even got a standardised graphics
interface yet, for pity's sake. This is 2007, not 1967.

You can argue that the modern game isn't what it once was, and I for
one will agree. But I can only dream of what the greats of the past
could do if they had the luxury of using more modern technology.

Like... pixels, for example?

You don't write standard C because you want modern. You write it because
you want portable. The two, unfortunately, appear to be mutually
exclusive.

<snip>

 

[per9000]

[snip]

You don't write standard C because you want modern. You write it because
you want portable. The two, unfortunately, appear to be mutually
exclusive.

[snip]

hear hear

/*
* (or should it be "read read"?)
* []-|--<
*/

--

Per Erik Strandberg
..NET Architect - Optimization
Tomlab Optimization Inc.
http://tomopt.com/tomnet/

 

[Army1987]

Warning: this post is silly. Also: it mixes top- and bottom posting





<snip>

Since this thread is FUBAR I have to ask this - When commenting code:
what style is "the best" one? (Also: when commenting code: what style
do you use?)

/* What
* about
* this
* one? */

 

[Peter Nilsson]

hear hear

.NET Architect

It is just me, or can anyone else spot the irony here?

 

[Richard Heathfield]

Peter Nilsson said:

It is just me, or can anyone else spot the irony here?

I think it's just you, Peter. Someone can be a C programmer one day, a
".NET architect" the next, a C++ programmer on the Wednesday, a Python
programmer on the Thursday, and back to C for a long relaxing weekend.
That one describes themselves as a .NET architect does not necessarily
indicate that they /always/ write slow, non-portable, vendor-locked
code.

 

[per9000]

It is just me, or can anyone else spot the irony here?

<OT>
I guess you already know this but it *is* possible to combine C and
C#. And by doing so you can get applications that are :
* portable (if they compile/run under MONO)
* fast (if time-consuming stuff is written in C)
* OS-integrated (I bet you think that is possible in C also - but not
as elegantly)

Also, I bet you have heard (but perhaps not understood) that different
languages are good at different things (much of this is a function of
built-in-libraries and the difficulty of adding packages). To me using
C for everything is like using Emacs to code, debug, send emails,
browse the internet, wash dirty underwear and so on. Sure: it is
perhaps possible, but I tend to prefer different programs for
different tasks. In a similar way I tend to prefer f.x. Python before
C when it comes to processing text and C# before C when it comes to
sending files to the trashcan (see f.x. http://www.pererikstrandberg.se/projects/totrash/).

Also: I read this/these list/lists because I want to learn more about
C/C++. Not because I already know everything.

I could go on for kilobytes on this topic but I guess you are already
convinced I am just as fubar as this thread anyway so I wont - you
don't have to thank me.
</OT>

/Per

 

[Martin Ambuhl]

<OT>
I guess you already know this but it *is* possible to combine C and
C#. And by doing so you can get applications that are :
* portable (if they compile/run under MONO)

When one asserts that one can have portable applications using a
proprietary language written for one family of proprietary OSs there is
something askew.

 

[per9000]

<OT>

When one asserts that one can have portable applications using a
proprietary language written for one family of proprietary OSs there is
something askew.

In case you did not already know it: C# is no longer limited to MS
Windows.

Quoting http://en.wikipedia.org/wiki/Csharp:
C# [...] is [...] developed by Microsoft [...] and later approved as a
standard by ECMA and ISO. [...]

[...]

The de facto standard implementation of the C# language is Microsoft
C# compiler[...]

Alternative C# compilers are:
* Microsoft's Rotor project [...]
* The Mono project provides a C# compiler [...]
* The Dot GNU project also provides a C# compiler [...]

End quote.
</OT>

HTH,
Per

 

[CBFalconer]

<OT>
I guess you already know this but it *is* possible to combine C and
C#. And by doing so you can get applications that are :
* portable (if they compile/run under MONO)
* fast (if time-consuming stuff is written in C)
* OS-integrated (I bet you think that is possible in C also - but not
as elegantly)

But you are leaving out that C# is specific, or almost so, to
Microsoft systems.

 

[Army1987]

*Off-list-warning*
If you *absolutely* want to use integers in a factorial program - try
a programming language like Python.

Here is a minimal example (with no error checks or anything) that
works for me. "fac" computes the factorial of a number, then I print
the factorials for 0, 10, 20, ... 100.

code:
def fac(n):
for i in range(1,n):
n *= i
return n

[OT]
That computes 0! as 0.

Try:
def fac(n):
if n < 0:
return Infinity # Invalid argument
elif n = 0:
return 1
else:
for i in range(1,n):
n *= i
return n