FACTORIAL PROGRAM

[Keith Thompson]

Right. What a powerful "argument" against using //-comments in r e a l
code... ;-)

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".

 

[James Kanze]

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

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.)

 

[banansol]

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.)

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...)

 

[Ian Collins]

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.)

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.

 

[James Kanze]

James Kanze wrote:

Maybe they had the foresight to predict the endless futile arguments
they would cause on Usenet and removed them...

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.)

I see this is broken again.

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]

James Kanze wrote:

Maybe they had the foresight to predict the endless futile
arguments they would cause on Usenet and removed them...

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.

 

[saki]

i wrote the following program to calculate factorial:

#include<stdio.h>
#include<iostream.h>

^^^^^^^^^^^
not a C or C++ header

void main()

^^^^
not legal in C or C++> {

int i,n;
long int p=1; // or long double p=1; for exponential result which I
don't want.
cout<<"Enter No. ";

^^^^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)

[...]

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?.

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.

why is void main() not legal?
can u please explain.

 

[Richard Heathfield]

saki said:

why is void main() not legal?

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.

can u please explain.

Would you be so kind as to write "you" when you mean "you"? Thank you.

 

[Army1987]

why is void main() not legal?
can u please explain.

http://c-faq.com/ansi/voidmain.html

 

[per9000]

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

/* 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; ...

<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/

 

[Richard Heathfield]

per9000 said:

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. */

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.

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

Syntax-colouring.

 

[per9000]

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.

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.

Syntax-colouring.

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/

 

[pete]

per9000 wrote:

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

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

 

[Flash Gordon]

per9000 wrote, On 16/04/07 10:15:

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.

Potentially good reasons, although where it is text it is pretty obvious
it is a comment.

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.)

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).

 

[James Kanze]

Since this thread is FUBAR I have to ask this - When commenting code:
what style is "the best" one?

The one that uses comments to add information not otherwise
available.

(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.

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.

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.
*/

Like all writing, a comment should be as long as necessary, but
no longer.

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 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.)

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#):

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.

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

In general, it's very, very rare to need a comment within a
function body.

 

[Marcus Kwok]

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;

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.

 

[Keith Thompson]

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.

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.

 

[Ian Collins]

One reason for not using the /* ... */ comments is that comments do not
nest (for example, when commenting out a piece of code):

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.

 

[Martin Ambuhl]

One reason for not using the /* ... */ comments is that comments do not
nest (for example, when commenting out a piece of code):

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

 

[Ai]

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.

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.