FACTORIAL PROGRAM

i wrote the following program to calculate factorial:

#include<stdio.h>
#include<iostream.h>
void main()
{
int i,n;
long int p=1; // or long double p=1; for exponential result which I
don't want.
cout<<"Enter No. ";
cin>>n;
if(n==0)
{
cout<<"1" ;
}
else
{
for(i=n;i>=1;i--)
{
p=p*i ;
}
}
cout<<"Factorial = "<<p;
}

But it works upto factorial 12 to display result as an integer. How
can I improve it so that it can display the result as an INTEGER upto
factorial 100 or more?.

THANK YOU.

re: FACTORIAL PROGRAM

Umesh wrote:
....You will need to use a Multiple Precision Arithmetic Library.

http://gmplib.org/

re: FACTORIAL PROGRAM

Umesh said:
No such header, in either C or C++.
Incorrect declarator for main, in either C or C++.
'don't want.' is a syntax error, in either C or C++.
If you don't take steps to ensure otherwise, cout is undefined - in both
C and C++.
Same for cin.
Really? It won't compile here. Unterminated character constant.
#include <stdio.h>

int main(void)
{
puts("100! =");
printf("933262154439441526816992388562667004907159 6826438162");
printf("146859296389521759999322991560894146397615 65182862536");
printf("979208272237582511852109168640000000000000 00000000000\n");
return 0;
}

Writing your own routines for handling very large integers, or even
using someone else's, can be quite a tricky task for a beginner. I
suggest you focus on re-learning the basics, properly this time, and
save your integer adventures for later.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

re: FACTORIAL PROGRAM

Umesh wrote:
That's not standard C.
That's a well-know not-Standard DON'T DO THAT for C.
That's a syntax error illustrating why // comments are Bad News, Quillan,
in usenet postings.
And that's either an attempt to shift an undeclared integer variable
by a char* amount, which is illegal in C for at least two reasons,
or C++, meaning that you misread the map and turned right, instead
of left, at the last crosscorridors.
Use an integer type that can cope with bigger numbers, such as supplied
by an off-topic-here bignum package.

--
Is it a bird? It is a plane? No, it's: http://hpl.hp.com/conferences/juc2007/
There' no hortage of vowel on Uenet.

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

re: FACTORIAL PROGRAM

Umesh wrote:^^^^^^^^^^^
not a C or C++ header
^^^^
not legal in C or C++^^^^1 ^^^^^^^^^^^^2
1)Use of an undefined variable in C.
2)Illegal operand for the shift operator in C
and the result of the shift is just thrown away.
Your post certainly does not belong in comp.lang.c
(and it isn't really C++ either)

[...]
100! takes 532 bits. Until you buy a computer with an integer size >=
532 bits with a compiler that supports it, find one of the many extended
precision or "bignum" packages around and waste your time learning to
use it. It will be a waste because you need to spend that time learning
the programming language your are trying to use. That language appears
to be C++, but your program isn't.

re: FACTORIAL PROGRAM

#include<stdio.h>
#include<iostream.h>
void main()
{
int n;
long double fac(int);
cout<<"Enter No. ";
cin>>n;
cout<<"Factorial = "<<fac(n);
}

long double fac(int n)
{
if(n<=1)
return(1);
else
return(n*fac(n-1));
}

re: FACTORIAL PROGRAM

On Apr 13, 2:29 pm, "Umesh" <fraternitydispo...@gmail.comwrote:If you don't care to read the replies to your post and go on making
same mistakes again why are you wasting yours and ours time?


-Cheers,
Gunvant
~~~~~~~~
No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.

re: FACTORIAL PROGRAM

In comp.lang.c Umesh <fraternitydisposal@gmail.comwrote:

(Followups set.)
<stdio.his an old-style header; prefer

#include <cstdio>

(snip C++ code).

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

re: FACTORIAL PROGRAM

On Apr 13, 11:29 am, "Umesh" <fraternitydispo...@gmail.comwrote:

In what language? The code is cross-posted to both comp.lang.c
and comp.lang.c++. It's legal in neither C nor C++, but in
order to indicate what's right, we have to know which language
you want to use.
Typically, C. But you don't seem to use anything from it, so
there's no reason to include it.
Out of date C++. To be used only when portability to a (very)
old compiler is necessary.
Illegal in C++, requiring a diagnostic from the compiler.
Implementation defined (but possibly illegal) in C.
I don't think many people will approve of a function declaration
inside another function. Formally, it's legal, but more for
historical reasons than anything else.

Some C++ compilers may warn, because in C++, what one might
write intuitively as a data definition ends up being interpreted
as a function declaration.
There's no cout nor cin defined in either C or C++.
Interesting, but it doesn't give the correct results for 100!
either.

As others have pointed out, you need an integer with more
precision. Such things exist, and aren't that hard to use in
C++ (but not as part of the standard language), IF you know the
language.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

On 13 Apr, 10:21, "Umesh" <fraternitydispo...@gmail.comwrote:<snip>
<snip>

As you have been told there is an upper limit for how large integers
can be. Experiment with your factorial programs with f.x. short int,
unsigned short int, long, unsigned long, float and double (if you
don't know what that is search the internet for an explanation). The
results might learn you something - or at least give you funny output.

*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

for i in range(0,101,10):
print i, fac(i)

output:
0 0
10 3628800
20 2432902008176640000

<snip>

100
93326215443944152681699238856266700490715968264381 62146859296389521759999322991560894146397615651828 62536979208272237582511852109168640000000000000000 00000000

HTH,
Per

re: FACTORIAL PROGRAM

Umesh wrote:C++ is another language. Not to be found on c.l.c.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews



--
Posted via a free Usenet account from http://www.teranews.com

re: FACTORIAL PROGRAM

On 13 Apr, 15:33, "per9000" <per9...@gmail.comwrote:

<snip>
<snip>

Or as Gianni said: use built-on-packages to extend the range of
"integers" to stay in C. You are interested in staying in C for
reasons known to readers on this list: "if C and Python were two WWF-
wrestlers then C would beat the crap out of python (if your C program
would pass compilation, and if you did not upset Malloc, and if you
did not misuse the & and/or *, etc.)".
[:)]-|--<

/Per

re: FACTORIAL PROGRAM

"Umesh" wrote:
<snip>You've had several suggestions, and which one is best depends on what your
goal is. If your goal is to become a better programmer, one way is to write
your own routines using char arrays as the fundamental element. Note that
multiplication is repeated addition. Consider unsigned numbers only. For
addition, simulate grade school arithmetic; note that the result of adding
two digits is:

c = a + b + ci
if(c>9)
c = c-10
ci=1 // ci to next digit
else
ci = 0

where
o prodce c = a+b
o a, b and c are individual digits of the larger underlying numbers
o ci stands for carry in and is 0 for the rightmost digit
o using the bastardized C++ meaning for '='.

There may be errors. When you finish you should have a good grasp of the
distinction between binary numbers and character codes. As in ASCII.

If you use arrays instead of vectors, use Stirling's (aka Sterling)
approximation and (porbably) logarithms to determine how many digits are in
the result - so you can size the arrays.

This link may be hellpful.

http://en.wikipedia.org/wiki/Binary-coded_decimal

re: FACTORIAL PROGRAM

"Richard Heathfield" <rjh@see.sig.invalidwrote in message
news:S5udnR3GnOUm3YLbnZ2dnUVZ8q-rnZ2d@bt.com...
Ever heard of word wrapping? That's pretty obviously part of the comment on
the line above. If it was a syntax error, do you think it would have
compiled in the first place?

-Howard

re: FACTORIAL PROGRAM

"Howard" <alicebt@hotmail.comha scritto nel messaggio
news:OEPTh.294754$5j1.55822@bgtnsc04-news.ops.worldnet.att.net...That's why you'd better avoid // comments on Usenet.

re: FACTORIAL PROGRAM

"Army1987" <please.ask@for.itwrote in message
news:evohhn$stt$1@tdi.cu.mi.it...So a person's code shouldn't contain //-style comments, because someday you
might want to copy&paste it into a newsreader? Hmm...

-Howard

re: FACTORIAL PROGRAM

"Howard" <alicebt@hotmail.comha scritto nel messaggio
news:fUQTh.41390$VU4.40003@bgtnsc05-news.ops.worldnet.att.net...Re-read the last two words of my post.
You are certainly free to use // comments (if you have a fully C99
conforming compiler, which I don't believe to be te case, or if you don't
care about not completely conforming any current or former standard, the
latter case being OT here), and to replace them with /* */ comments (or to
leave them unchanged, if they are *very* short, so that the lines which
contain them won't become longer than 67 characters even when preceded by
umpteen quotation marks).

re: FACTORIAL PROGRAM

On Fri, 13 Apr 2007 19:31:23 GMT, "Howard" <alicebt@hotmail.comwrote:
Right. What a powerful "argument" against using //-comments in r e a l
code... ;-)


G.

--

E-mail: info<at>simple-line<Punkt>de

re: FACTORIAL PROGRAM

Gregor H. wrote:Note that this is crossposted to comp.lang.c as well, and C89 does not
recognize // comments.

re: FACTORIAL PROGRAM

"red floyd" <no.spam@here.dudewrote in message
news:RERTh.8172$u03.580@newssvr21.news.prodigy.net ...Ahh, I hadn't noticed that. I just assumed we were talking C++ here.
-H

re: FACTORIAL PROGRAM

Gregor H. <nomail@invalidwrites:Nobody argued against using //-comments in real code (apart from the
issue that C90 doesn't recognize //-comments). The advice was
qualified with the phrase "on Usenet".

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: FACTORIAL PROGRAM

On Apr 13, 10:23 pm, red floyd <no.s...@here.dudewrote:But C90 is no longer the standard, and hasn't been for some
time. And C99 does allow them. (As did B. One sort of wonders
where they went to in the early versions of C.)

(Of course, the original poster's code also used <iostream>,
cout and such, so I think we can conclude that he at least
thought it was C++, and that his posting in comp.lang.c was the
real error.)

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

On Apr 13, 11:54 pm, "James Kanze" <james.ka...@gmail.comwrote:Maybe the excellent designers of C deliberately excluded then from
the language since they felt there was no need for them.
And then after a lot of sloppy programmers used // comments
in their C code since they didn't know the difference between
C and C++, the standard folks decided to add the new
comments to C99. :-)

(It's just a joke, just in case...)

re: FACTORIAL PROGRAM

James Kanze wrote:Maybe they had the foresight to predict the endless futile arguments
they would cause on Usenet and removed them...I see this is broken again.

--
Ian Collins.

re: FACTORIAL PROGRAM

On Apr 14, 12:48 am, Ian Collins <ian-n...@hotmail.comwrote:Who knows? The fact remains that most modern languages support
some form of comment until end of line. Particularly with
comments appended after program text, it's too easy to forget to
close one, and loose a couple of lines of code; if they're not
declarations, it's even possible for the code to compile without
an error.

FWIW: at least one place I worked had a rule that all comments
must be closed at the end of line. So a block comment would
look something like:

/* This is a block comment in C. It has to be */
/* long enough to span several lines, in order */
/* to show the effect. */

I rather like it; it sets the comment off well. But maintaining
the formatting without special tools would be a pain.
(Obviously, the first thing I did was write the special tools.
The original version goes back to around 1988, in C, but there
is a more or less up-to-date version at my site.)
Different machine. It'll probably take a few weeks for me to
work through all of the systems I use, and get it fixed
everywhere.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

On Apr 14, 12:48 am, Ian Collins <ian-n...@hotmail.comwrote:Juwt to make things clear, too. There's not the slightest
problem with // in Usenet, if you know what you're doing. The
problem isn't // comments, it's people who don't know how to use
Usenet.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

On Apr 13, 1:42 pm, Martin Ambuhl <mamb...@earthlink.netwrote:why is void main() not legal?
can u please explain.

re: FACTORIAL PROGRAM

saki said:

<snip>
What makes you think it *is* legal? No reputable C or C++ teacher, book,
or tutorial will claim that it is - except of course in freestanding
implementations (where the entry point need not even be called main),
or - for C99 (and perhaps C++?) - where the implementation specifically
documents it as an extension.

In the normal case, there are exactly two semantic forms of main that
are legal:

int main(void)

int main(int argc, char **argv)

Of course, any exact equivalents of these are also legal, but void
main() is not an exact equivalent of either of them.
Would you be so kind as to write "you" when you mean "you"? Thank you.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

re: FACTORIAL PROGRAM

"saki" <sakethstudies@gmail.comha scritto nel messaggio
news:1176545335.694291.230270@y5g2000hsa.googlegro ups.com...http://c-faq.com/ansi/voidmain.html

re: FACTORIAL PROGRAM

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


On 14 Apr, 11:58, "James Kanze" <james.ka...@gmail.comwrote:

<snip>
<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?)

Since I actually like to understand the code by reading the comments
alone I tend to like to have neat comments that are understandable.
Also I hate ugly code that does the magic in a one-liner if a two- or
three-liner is equally good but provides more readability.
/*
* A nice comment that is really readable,
* on a few lines.
*/

The above example has a tendency of getting bad indentation - pretty
much like the next example. But still: the above example is how I
comment most C-code. I find it extremely readable.
/*
* An ugly comment that is really still readable,
* on a few lines.
* BEWARE: ugly/bad indentation
*/

I've seen people doing this, but I am not sure I like it:
/*
** More stars - better indentation.
** More stars - less neatness.
**/

Personally I am disgusted by comments like these:
/* A horrible comment that perhaps might be readable,
one a few lines - but here you have to use the
force to see where it ends. */

One-liners are invisible to me - they just disappear
/* I am invisible - weeee! */

In C++ and C# I tend to add an extra line before and after so that the
comments show (for some reason I do not use the /* ... */ style in C++
or C#):

//
// this loop does something to j
//
for (...)
--j;


/Per [:)]-|--<

--

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

re: FACTORIAL PROGRAM

per9000 said:
Or just place the cursor at the end you can see and use a single
keystroke to jump straight to the other end. Easy, if you have the
right editor.
Syntax-colouring.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

re: FACTORIAL PROGRAM

On 16 Apr, 10:13, Richard Heathfield <r...@see.sig.invalidwrote:Indeed - but often I diff files or just dump them on the console with
more/less/cat etc just to look at them. In these cases I find bad
commenting style to be horrible - in particular if I have not written
the code myself.
Colour-blindness.
http://en.wikipedia.org/wiki/Color_Blindness

Bad syntax-colouring can be worse than no syntax colouring -
especially for me and about 6-7% of the male population that have some
form of colour-blindness. (Picking strawberries isn't a walk in the
park either.)


/Per

--

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

re: FACTORIAL PROGRAM

per9000 wrote:
/*
** You have one star too many, on the bottom line.
*/

--
pete

re: FACTORIAL PROGRAM

per9000 wrote, On 16/04/07 10:15:Potentially good reasons, although where it is text it is pretty obvious
it is a comment.
So change the colour scheme. You can't change the colour scheme of
strawberries, but you can change the colour scheme in all the editors
I've used that do syntax highlighting. vim will even do syntax
highlighting in monochrome (using bold, underline etc, although it looks
horrible to me).
--
Flash Gordon

re: FACTORIAL PROGRAM

On Apr 16, 9:57 am, "per9000" <per9...@gmail.comwrote:The one that uses comments to add information not otherwise
available.
Which means that you read one thing, and the compiler reads
another. Two copies to keep in synch. Doesn't sound like a
good idea to me.

Comments are for things that cannot be expressed in code. For
example, given something like:
void f(int* p) ;
in a header, a comment like:

//! \param p
//! a pointer to an int.

is not very useful. Something like:

//! \pre
//! p != NULL

is essential.
Like all writing, a comment should be as long as necessary, but
no longer.
I don't really see any difference. At any rate, I can configure
my editor to do it one way or the other. Of course, in C, I'd
do it something like.

/* A pretty readable comment, which for */
/* whatever reasons requires several lines. */

Depending on context, I might add a header or footer line to it,
to clearly mark it off from the code. (This is probably just an
old habit, though, from the days before syntax coloring.)
No one does, except maybe for special purposes.

And doesn't your editor show comments in a different color than
the code? All of the editors I know do.
In general, it's very, very rare to need a comment within a
function body.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

In comp.lang.c++ per9000 <per9000@gmail.comwrote:One reason for not using the /* ... */ comments is that comments do not
nest (for example, when commenting out a piece of code):

void foo()
{
for (...) {
/* do stuff in here */
}
}

If you wanted to comment out this for-loop:

void foo()
{
/*
for (...) {
/* do stuff in here; the comment ends here, not after the loop */
}
*/
}

Thus the last curly-brace and comment-end do not match with what was
intended.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

re: FACTORIAL PROGRAM

ricecake@gehennom.invalid (Marcus Kwok) writes:If you want to comment out blocks of code, use "#if 0" ... "#endif".

One drawback of this is that if the block of code is too large, it may
not be obvious that it's been commented out. If that's an issue, you
can insert some dummy token at the beginning of each line, and remove
it when you uncomment it:

#if 0
* void foo()
* {
* for (...) {
* /* do stuff in here */
* }
* }
#endif

(Or you can use //-comments *if* you're sure that your implementation
supports them; note that this is cross-posted to comp.lang.c and
comp.lang.c++.)

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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: FACTORIAL PROGRAM

Marcus Kwok wrote: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.

--
Ian Collins.

re: FACTORIAL PROGRAM

Marcus Kwok wrote:
That's not a reason. The correct way to "comment out" a piece of code
is with #if 0/#endif pairs.

re: FACTORIAL PROGRAM

On Apr 13, 4:21 am, "Umesh" <fraternitydispo...@gmail.comwrote:Here you go, hope this helps you.

/*
Factorial App
User will be asked to enter the number
and output will be the factorial of the number entered

Version 1.0
By: Ai
*/

#include <iostream>
#include <cmath>
#include <iomanip>
using namespace std;

long factorial(long); // function prototype

int main()
{
int num;

cout << "Input value for factorial: ";
cin >num;

if (num < 0)
{
cout << "Invalid value." << endl
<< "Please input value again: ";
cin >num;
}

else
{
cout << "\nThe factorial of "
<< num
<< " is "
<< factorial(num) << endl;
}

return 0;
}

long factorial(long a)
{
if (a>1)
return a = (a * factorial(a-1));
else
return (1);
}

Unfortunately, like everyone mentioned,
it can't show big/large amount of numbers.

int and long int are both 4 bytes ranging from -2147483648 to
+2147483648
unsigned int/long int are 4 bytes values ranging from 0 to 4294967295

The only way to calculate it out is using double or long double
where it shows the numbers with exponent e

i.e. 1.7976912314213e+308

Hope this helps you.

re: FACTORIAL PROGRAM

Ai wrote, On 17/04/07 22:58:<snip>
If you are going to post C++ answers, please drop the cross post to
comp.lang.c
--
Flash Gordon

re: FACTORIAL PROGRAM

On Apr 17, 11:09 pm, Keith Thompson <k...@mib.orgwrote:[...]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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

On Apr 17, 11:12 pm, Ian Collins <ian-n...@hotmail.comwrote: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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: FACTORIAL PROGRAM

James Kanze said:
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).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

re: FACTORIAL PROGRAM

James Kanze wrote:Then your edit/test granularity is too coarse.grumble grumble....

--
Ian Collins.

re: FACTORIAL PROGRAM

[snips]

On Mon, 16 Apr 2007 00:57:35 -0700, per9000 wrote:
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.

--
Do not contact me at kbjarnason@ncoldns.com

re: FACTORIAL PROGRAM

Richard Heathfield <r...@see.sig.invalidwrote:2? Try another 10.
Until you finally understand!
No, what we have is a shite load of C90 compilers that support them
as future compatible extensions.
How many non-trivial C90 programs would be affected by turning on //
recognition? Millions, thousands, hundreds, tens...?
Some? How many less than ten years old don't?
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. :-)
You could always use a C++ compiler and gain a few checks that C
lacks. ;-)

--
Peter

re: FACTORIAL PROGRAM

Peter Nilsson said:
But I already do.
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.
Turning on // recognition isn't the issue. Turning OFF other conformance
checks *is*.
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".
Fine. So what?
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.
<grinBut that just wouldn't be C!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

re: FACTORIAL PROGRAM

Richard Heathfield <r...@see.sig.invalidwrote: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.
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.
The word you're avoiding is 'most'.
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.
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.
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.
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. ;-)
Is any subset of C90?

--
Peter

re: FACTORIAL PROGRAM

Peter Nilsson <airia@acay.com.auwrites:
[...]

Peter, something is mangling your paragraphs. Compare this, which
you wrote:
to this:
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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"