Header questions

[wdh3rd]

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right? So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

Many thanks for any help anyone can give me. :)

[Lew Pitcher]

On Apr 3, 10:48 am, [e-mail] wrote:

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right? So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

This is somewhat a matter of choice, and of planning. You don't have
to put function prototypes in the header file at all (for that matter,
you don't even have to have a header file). There are several reasons
for having a header file, including
- uncluttering your code file (i.e. putting stuff specific to one code
source file into the header, just to keep the code file from getting
too wordy), and
- providing some public knowledge about a set of functions or
constants

In your case, it seems that you are concerned about the latter reason.
In which case, yes, you only need to put into the header file those
elements that /should/ be shared between code files, such as function
prototypes and common macros. Function prototypes and macros that are /
not/ to be shared should (in this case) /not/ be placed in the common
header file.

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

If factorial() is (by requirement) not a public function, then making
it's prototype available in a public header file will not gain any
advantage because the function cannot be referenced outside of the
scope of the code file that it is defined in.

BTW, in C, there are no such things as "methods", "private" or
otherwise.

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

It is a matter of convenience and laziness. With the proper
protections (which stdio.h usually implements), there is little danger
in including stdio.h in both a header and a source file. However, it
is not recommended practice, as the order of the #includes can
influence the ultimate resolution of macros. It may be that there is a
conditional macro that will resolve differently if preceeded by the
inclusion of stdio.h. So long as this result is intended /and
documented/, then there is no real problem. However, if the result is
unintended, or intended /but not documented/, then there is a risk
that the compilation will produce a result different from what the
programmer intended.

(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

Have you looked at the declaration of pow()?
double pow(double, double);
It sounds like you are calling double(), passing it two integers. Of
course, the compiler is going to warn you that it had to do an
implicit cast to double; your arguments are integers, and pow() wants
doubles.

Perhaps you want
double doublesomething;
int intsomething1, intsomething2;

doublesomething = pow((double)intsomething1, (double)intsomething2);

Many thanks for any help anyone can give me. :)

[Kenneth Brody]

wd****@gmail.com wrote:

>
Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

That depends. Are the factorial functions identical? (ie: as
opposed to one taking int and another taking double, for example.)

If so, why not create a factorial.c and factorial.h pair, and put
the factorial function there?

[...]

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

I assume that "per instructions" means this is related to an assignment
of some sort? In that case, you should follow the directions, and not
create a separate factorial.c module as I mentioned above. (Even though
I feel it makes more sense to do so.)

Also, by "private", I assume you mean by making the functions "static"?

My opinion is that it doesn't make sense to put prototypes for "private"
functions (and variables) in a header, since the functions (and
variables) are not visible outside the specific source module. My
preference is to place such things at the top of the source file.

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

Every compiler I've used in recent years handles the situation of a
standard header file being included twice. However, that hasn't
always been the case, and I don't believe that the standard says that
an implementation must handle it properly.

My preference is that the header shouldn't #include <stdio.hwithout
some compelling reason. (And I can't think of any such reason.) The
closest I can think of is a header file which references things
defined in <stdio.h>, but which may be included from a file which
has no such need. (And in that case, simply document that you need
to #include <stdio.hbefore including your header.)

Speaking of double-includes, you may want to make sure that your header
files handle that case. I usually do this by starting each header file
with:

#ifndef __HEADER_FILE_NAME
#define __HEADER_FILE_NAME
... header file here ...
#endif /* __HEADER_FILE_NAME */

(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

Is the warning on the parameters being passed to pow() or on the
return value? Have you included the necessary header file for
pow()'s prototype?

Many thanks for any help anyone can give me. :)

If this is, in fact, a homework assignment, thank you for posting
thoughtful questions. Many times, students post messages which
are basically "can you do my for for me?"

Unless these questions are the actual homework, in which case you
have hidden the "do my homework for me" aspect quite well. :-)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Stephen Sprunk]

<wd****@gmail.comwrote in message
news:11*********************@q75g2000hsh.googlegro ups.com...

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be
made are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve
their problems, factorial is supposed to be in both perm.c and
combo.c, and declared private.

Supposed to be? That's one option, but it's bad form to duplicate code
without good reason. If perm.c and combo.c both need a factorial function,
I'd create a separate factorial.c/h and put the function there. Of course,
that would expose it to any other modules being linked in, which may not be
desirable.

Also, "private" is a C++ism; a private function would be "static" in C.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right? So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

The way I've seen such things arranged is that the non-static functions
defined in a .c file are declared in the corresponding .h file. For
instance:

/* start perm.h */
extern int perm(int n, int r);
/* end perm.h */

/* start perm.c */
#include "perm.h"

static int factorial(int n) {
/* your implementation here */
}

int perm(int n, int r) {
/* your implementation here */
}
/* end perm.c */

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

If you don't want others to be able to see/use an internal helper function,
don't put it in the header.

Also, "method" is a C++ism; C only has functions.

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

Generally, you should have no reason to #include <stdio.hin your own
header files. The main exception would be if you needed to declare your own
function that took, e.g., a FILE* as an argument, and some purists would say
those who #include your header should be required to #include <stdio.h>
first. It's debatable.

Header files should have what are commonly called "header guards" so that
#include'ing them multiple times has no effect; Kenneth provided an example.
I can't recall, however, if C90/99 requires that the standard headers have
such; every implementation I've used has had them.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Flash Gordon]

Kenneth Brody wrote, On 03/04/07 17:35:

wd****@gmail.com wrote:

>Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

That depends. Are the factorial functions identical? (ie: as
opposed to one taking int and another taking double, for example.)

If so, why not create a factorial.c and factorial.h pair, and put
the factorial function there?

Because his instructor told him to only create those 4 files?

<snip>

>(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

Every compiler I've used in recent years handles the situation of a
standard header file being included twice. However, that hasn't
always been the case, and I don't believe that the standard says that
an implementation must handle it properly.

The standard has required that it be handled properly since the first
standard in 1989.

My preference is that the header shouldn't #include <stdio.hwithout
some compelling reason. (And I can't think of any such reason.)

Declaring a function that takes a FILE* as a parameter would be a good
reason.

The
closest I can think of is a header file which references things
defined in <stdio.h>, but which may be included from a file which
has no such need. (And in that case, simply document that you need
to #include <stdio.hbefore including your header.)

That, IMHO, is horrible. You should always be able to include a header
without having to worry about its dependencies. However, it is a matter
of style, so I'm just expressing my opinion not saying you are actually
wrong.

Speaking of double-includes, you may want to make sure that your header
files handle that case. I usually do this by starting each header file
with:

#ifndef __HEADER_FILE_NAME

Why do you needlessly invade the implementations name space? Names
starting with two underscores are always reserved, even names starting
with one underscore are reserved in a lot of situation (especially if
followed by an upper case letter). It is therefore best to avoid leading
underscores at all times rather than use them in the few situations you
can (which this was not).

<snip>

>Many thanks for any help anyone can give me. :)

If this is, in fact, a homework assignment, thank you for posting
thoughtful questions. Many times, students post messages which
are basically "can you do my for for me?"

Unless these questions are the actual homework, in which case you
have hidden the "do my homework for me" aspect quite well. :-)

Be fair, he has asked C questions not asked us to write code for him. :-)
--
Flash Gordon

[Francine.Neary]

On Apr 3, 6:58 pm, "Stephen Sprunk" <[e-mail]:

<[e-mail] in message

news:11*********************@q75g2000hsh.googlegro ups.com...

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be
made are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve
their problems, factorial is supposed to be in both perm.c and
combo.c, and declared private.

Supposed to be? That's one option, but it's bad form to duplicate code
without good reason. If perm.c and combo.c both need a factorial function,
I'd create a separate factorial.c/h and put the function there. Of course,
that would expose it to any other modules being linked in, which may not be
desirable.

Also, "private" is a C++ism; a private function would be "static" in C.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right? So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

The way I've seen such things arranged is that the non-static functions
defined in a .c file are declared in the corresponding .h file. For
instance:

/* start perm.h */
extern int perm(int n, int r);

I believe extern is redundant here.

/* end perm.h */

/* start perm.c */
#include "perm.h"

static int factorial(int n) {
/* your implementation here */

}

int perm(int n, int r) {
/* your implementation here */}

/* end perm.c */

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

If you don't want others to be able to see/use an internal helper function,
don't put it in the header.

It could still be useful to include prototypes for static functions at
the top of the .c file.

Also, "method" is a C++ism; C only has functions.

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

Generally, you should have no reason to #include <stdio.hin your own
header files. The main exception would be if you needed to declare your own
function that took, e.g., a FILE* as an argument, and some purists would say
those who #include your header should be required to #include <stdio.h>
first. It's debatable.

Header files should have what are commonly called "header guards" so that
#include'ing them multiple times has no effect; Kenneth provided an example.
I can't recall, however, if C90/99 requires that the standard headers have
such; every implementation I've used has had them.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

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

[Keith Thompson]

"Lew Pitcher" <lp******@sympatico.cawrites:

On Apr 3, 10:48 am, [e-mail] wrote:

[...]

>(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

Have you looked at the declaration of pow()?
double pow(double, double);
It sounds like you are calling double(), passing it two integers. Of
course, the compiler is going to warn you that it had to do an
implicit cast to double; your arguments are integers, and pow() wants
doubles.

You mean implicit conversion, not implicit cast (a cast is an explicit
conversion).

Arguments are automatically converted to the expected parameter type
(if possible); I wouldn't expect a compiler to warn about it. It's
likely that the compiler thinks that the pow() function returns an
int, because the OP forgot the required "#include <math.h>".

To the OP: What exactly are you trying to do? Show us some code.

--
Keith Thompson (The_Other_Keith) ks***@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"

[Al Balmer]

On Tue, 03 Apr 2007 12:35:04 -0400, Kenneth Brody
<ke******@spamcop.netwrote:

>Every compiler I've used in recent years handles the situation of a
standard header file being included twice. However, that hasn't
always been the case, and I don't believe that the standard says that
an implementation must handle it properly.

Yes, it does.

>My preference is that the header shouldn't #include <stdio.hwithout
some compelling reason. (And I can't think of any such reason.) The
closest I can think of is a header file which references things
defined in <stdio.h>,

That *is* a compelling reason.

but which may be included from a file which
has no such need.

(And in that case, simply document that you need
to #include <stdio.hbefore including your header.)

Ugly, error-prone, and unnecessary. The header file which needs
stdio.h should include it. What reason is there not to?

--
Al Balmer
Sun City, AZ

[wdh3rd]

This is somewhat a matter of choice, and of planning. You don't have
to put function prototypes in the header file at all (for that matter,
you don't even have to have a header file). There are several reasons
for having a header file, including
- uncluttering your code file (i.e. putting stuff specific to one code
source file into the header, just to keep the code file from getting
too wordy), and
- providing some public knowledge about a set of functions or
constants

In your case, it seems that you are concerned about the latter reason.
In which case, yes, you only need to put into the header file those
elements that /should/ be shared between code files, such as function
prototypes and common macros. Function prototypes and macros that are /
not/ to be shared should (in this case) /not/ be placed in the common
header file.

Thanks for all your help!

I think a lot of my problem with this assignment has been that it
could have been designed better to teach about headers since no two
files will share any common methods that aren't private. Both perm.c
and combo.c use factorial, but since it's to be made private in each
file, factorial shouldn't be in the header. As it is, the headers,
perm.h and combo.h, only have prototypes for their respective .c
files. Maybe I'm doing things incorrectly from how they're supposed to
for the assignment, but (1) perm.h and combo.h are supposed to be
there (2) factorial has to be private , and , (3) something has to go
in that .h mama-jamma.

Have you looked at the declaration of pow()?
double pow(double, double);
It sounds like you are calling double(), passing it two integers. Of
course, the compiler is going to warn you that it had to do an
implicit cast to double; your arguments are integers, and pow() wants
doubles.

Perhaps you want
double doublesomething;
int intsomething1, intsomething2;

doublesomething = pow((double)intsomething1, (double)intsomething2);

I think I was having temporary tardness on the pow thing. I just cast
it to an int and everything is good.

Thanks again for such a thorough answer!!

[wdh3rd]

That depends. Are the factorial functions identical? (ie: as
opposed to one taking int and another taking double, for example.)

If so, why not create a factorial.c and factorial.h pair, and put
the factorial function there?

[...]

The professor specified the files he wanted, so I have to follow along
with that.

I assume that "per instructions" means this is related to an assignment
of some sort? In that case, you should follow the directions, and not
create a separate factorial.c module as I mentioned above. (Even though
I feel it makes more sense to do so.)

Also, by "private", I assume you mean by making the functions "static"?

My opinion is that it doesn't make sense to put prototypes for "private"
functions (and variables) in a header, since the functions (and
variables) are not visible outside the specific source module. My
preference is to place such things at the top of the source file.

Prototypes for "private" functions in a header does seem odd. I've put
them
at the top of the source file.

My preference is that the header shouldn't #include <stdio.hwithout
some compelling reason. (And I can't think of any such reason.) The
closest I can think of is a header file which references things
defined in <stdio.h>, but which may be included from a file which
has no such need. (And in that case, simply document that you need
to #include <stdio.hbefore including your header.)

There was a double includes of <stdio.hin our class slides, so that
got me
confused because it seems like that's not the usual way of doing
things.

Speaking of double-includes, you may want to make sure that your header
files handle that case. I usually do this by starting each header file
with:

#ifndef __HEADER_FILE_NAME
#define __HEADER_FILE_NAME
... header file here ...
#endif /* __HEADER_FILE_NAME */

I was avoiding doing that because I thought it would shield me from
any mistakes
I'd made in doing the .c and .h files properly, where if I'd performed
a double-
includes, I wouldn't be able to know because the #indef would hide
that fact. I think
I'm saying the process right, but I'm not sure.

If this is, in fact, a homework assignment, thank you for posting
thoughtful questions. Many times, students post messages which
are basically "can you do my for for me?"

Unless these questions are the actual homework, in which case you
have hidden the "do my homework for me" aspect quite well. :-)

This isn't the actual homework, just the roadblocks I've run into
while trying
to get that homework to do what it's supposed to do (at least the way
the
professor wants). I wouldn't want to post actual homework since I
wouldn't really
learn anything if I didn't have to trudge through the code. 8^}
Big thanks for all your help!!!

[CBFalconer]

Kenneth Brody wrote:

>

.... snip ...

>
Speaking of double-includes, you may want to make sure that your
header files handle that case. I usually do this by starting each
header file with:

#ifndef __HEADER_FILE_NAME
#define __HEADER_FILE_NAME
... header file here ...
#endif /* __HEADER_FILE_NAME */

Replace the '__' with 'H_' to avoid invading implementation
namespace.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[CBFalconer]

wd****@gmail.com wrote:

>

>That depends. Are the factorial functions identical? (ie: as
opposed to one taking int and another taking double, for example.)

If so, why not create a factorial.c and factorial.h pair, and put
the factorial function there?

[...]

The professor specified the files he wanted, so I have to follow
along with that.

So satisfy him for the purpose of marks, and learn better here.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[user923005]

On Apr 3, 7:48 am, [e-mail] wrote:

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right?

Wrong. If I thought the function in the file was potentially
generally useful and encapsulated enough for external use, I would
create a header file for it.
In fact, I do exactly that on a frequent basis.

So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

Not sure if I follow this. You can have all prototypes for a thousand
files in a single file, or you can have an individual file for every
prototype or anything in between.

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....

That depends. Could your permutation or combination functions ever
have use for some other project? If the answer is 'yes' then a header
file for future external references is a good thing.

Is this a problem since factorial (per instructions) is
supposed to be declared private??

C has no 'private' -- that's C++.

I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

It is (usually) a bad idea. Why are we creating a private function?
So our function name will not collide with another symbol in the same
(external) name space.
Hence, by creation of a prototype, we have circumvented our purpose.
Now, we will prevent someone else from creation of a function with the
same name and static scope but with a different set of parameters.

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right??

It's OK if the file is idempotent, which is the case with any decent
implementation. To make something idempotent you do this:

#ifndef MY_HEADER_FILE_INCLUDED /* Notice that there are NOT any
leading underscores here. */
#define MY_HEADER_FILE_INCLUDED
/* Body of the header file goes here */
#endif /* MY_HEADER_FILE_INCLUDED */

I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

What a header file does is discussed in section 6.10 of ISO/IEC
9899:1999 (E) which is the current ANSI/ISO C standard.

(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

With a cast (among other things). Probably better is to use the
correct data type in the first place.

Many thanks for any help anyone can give me. :)

[Bill Pursell]

On Apr 3, 10:37 pm, [e-mail] wrote:
(but snipped the attribution, so I don't know who
is resposible for the lines)

>

Speaking of double-includes, you may want to make sure that your header
files handle that case. I usually do this by starting each header file
with:

#ifndef __HEADER_FILE_NAME
#define __HEADER_FILE_NAME
... header file here ...
#endif /* __HEADER_FILE_NAME */

I was avoiding doing that because I thought it would shield me from
any mistakes
I'd made in doing the .c and .h files properly, where if I'd performed
a double-
includes, I wouldn't be able to know because the #indef would hide
that fact.

In fact, I usually do one further and write:
#ifdef ABC_HDR
#error Private header file.
#else
#define ABC_HDR
....

I use this for "internal" headers that are intended
for use only inside my project. Hopefully, they
are never seen by anyone outside the project, and
if they are this would be a flag that something
odd is happening. And it helps me keep by own
build environment consistent.

[John Smith]

wd****@gmail.com wrote:

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

(1) You wouldn't ever put a prototype in a header if that function was
only in one file...right? So, any function unique to perm.c, e.g.----
int permr(int n, int r) ---- should be a prototype in its file only(in
perm.c, not in combo.c), and not the header.

(2) The only prototype that makes sense to put in the header is
factorial ---- int factorial(n) --- since it's used by both perm.c and
combo.c....Is this a problem since factorial (per instructions) is
supposed to be declared private?? I'm declaring it private by making
it static. Is it kosher to put prototypes of private methods in
headers??

(3) I've seen in at least one place where <stdio.his in both the
header and the source file. This is okay, right?? I'm assuming that
without every file having the <stdio.h>, there'd be no way to read the
header, so it's needed there, and the header needs it to output it's
stuff. Is that a correct reading...that it's okay to have <stdio.hin
the header and source??

(4) When trying to do an exponential, using pow(n,r), I get a warning
that I'm converting to 'int' from 'double' even though I'm only using
ints and multiplying them. How can I multiply two ints and make that a
double??

Many thanks for any help anyone can give me. :)

[OT] Just to satisfy my idle curiosity, at what level and
institution are you being offered a course in C programming?

JS

[Al Balmer]

On 3 Apr 2007 21:22:59 -0700, "Bill Pursell" <bi**********@gmail.com>
wrote:

>On Apr 3, 10:37 pm, [e-mail] wrote:
(but snipped the attribution, so I don't know who
is resposible for the lines)

>>

Speaking of double-includes, you may want to make sure that your header
files handle that case. I usually do this by starting each header file
with:

#ifndef __HEADER_FILE_NAME
#define __HEADER_FILE_NAME
... header file here ...
#endif /* __HEADER_FILE_NAME */

I was avoiding doing that because I thought it would shield me from
any mistakes
I'd made in doing the .c and .h files properly, where if I'd performed
a double-
includes, I wouldn't be able to know because the #indef would hide
that fact.

In fact, I usually do one further and write:
#ifdef ABC_HDR
#error Private header file.
#else
#define ABC_HDR
...

I use this for "internal" headers that are intended
for use only inside my project. Hopefully, they
are never seen by anyone outside the project, and
if they are this would be a flag that something
odd is happening. And it helps me keep by own
build environment consistent.

But it doesn't meet the goal of safely allowing multiple inclusion.

--
Al Balmer
Sun City, AZ

[Army1987]

<wd****@gmail.comha scritto nel messaggio
news:11*********************@q75g2000hsh.googlegro ups.com...

Hi everyone. I'm new to C and I have a few questions:

I am making files for permutations and combinations. Files to be made
are perm.c, perm.h, combo.c, and combo.h.

Since both combinations and permutations use factorial to solve their
problems, factorial is supposed to be in both perm.c and combo.c, and
declared private.

Consider using some other way to do that. The factorial of 21 doesn't even
fit in a 64-bit unsigned long long int.
You can directly use the formula n * (n-1) * (n-2) * ... * (n-k+1), which
will never overflow if the final result fits in the type you're using.