Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at the
top of the mylib.c file, or to create a separate mylib_private.h file?
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
Thanks for any input!
DM
45  1862 
David wrote:
) I've recently started programming C after many years using "the other
) language"... I just wanted to find out the common practice for
) organising source files.
What's "the other language" ? Cobol ?
) Specifically, consider a moderately complicated library module, mylib.c.
) Obviously its "public interface" (i.e. non-static function
) declarations, typedefs, any global variables) need to go in mylib.h.
)
) The question is: what about private (i.e. static) functions and struct
) declarations and typedefs only used in the private implementation?
)
) Is it more usual to put these in the mylib.h file, or to put them at the
) top of the mylib.c file, or to create a separate mylib_private.h file?
My personal prefecernce is to put them at the top of the .c file.
*_private.h files are useful when you have several .c functions that
form a package/module/library.
Also, if you define static functions before you use them, you don't need
to define them, which removes redundant information. IMO, this is a good
thing, but other opinions may differ.
) And a similar question for #includes: let's suppose that one of the
) public functions declared in mylib.h takes a FILE* parameter.
) Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
) the FILE structure defined.
)
) But say in the implementation, in mylib.c, I need to use (for example)
) malloc. Then I need to #include<stdlib.has well. Should I put the
) #include at the top of mylib.h or at the top of mylib.c?
I'd say, at the top of mylib.c.
There are also people who don't include any system libs in a .h file,
but specify that it needs to be included whenever mylib.h is included.
I personally think it's a bad practice but I've seen it done.
Bottom line: keep the .h file to a minimum, but make sure it can stand
alone. This is my personal opinion, of course. It might, or might not
be the "industry standard".
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
David Mearsen wrote:
Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module,
mylib.c. Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at
the top of the mylib.c file, or to create a separate mylib_private.h
file?
IMHO, the last option is the best one.
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
The latter.
Thanks for any input!
DM
David Mearsen wrote:
Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at the
top of the mylib.c file, or to create a separate mylib_private.h file?
"Private parts" don't belong in the public header file,
because they would then cease to be private and would become
part of your published interface. If you can, keep the private
definitions inside the library's .c files. If the library has
several .c files that must share a set of private declarations,
putting them in a mylib_private.h file is about the best you
can do.
A somewhat related matter: It is an excellent idea to
#include "mylib.h" in all the library's source files. That
way, the compiler can alert you if the declarations and the
definitions get out of step.
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
Opinions differ on this one. I am of the "headers should
#include other headers if they need them" persuasion, but there
is also a "nested #includes are evil" party to which some non-
stupid people belong. Choose your allegiance, and thereafter
do not waver.
--
Eric Sosman es*****@ieee-dot-org.invalid
You will also find that in regular linkers, you will find yourself
declaring *one* public function per .c file.
Reason being linkers on unix, in general, are dumb, in a good way, and
try and keep binary compatibility amongst object formats by not
splitting functions themselves.
What this means is that if you have a large library, chances are your
client code will only use a bunch of the functions, and will most
likely appreciate if the static linking only takes place for those
functions that are actually used.
Dynamic linking doesn't impose such restriction, but it is good
practice, in library code development, to place each public function
in separate files anyway to reduce source control and maintenance
headaches.
"David Mearsen" <no************@nospam.comwrote in message
>
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Declare everything you want user to be able to access in "mylib.h". He ought
to be able to get the lot, except maybe FILE *s and the like, by simply
including one file.
Personally I expose most structures (though not in Baby X, my X windows
toolkit) to help debugging or coding round library mistakes, even if
intended to be opaque.
Unfortunately mylib might well depend on something, for instance the highly
general string functions I suggested in the xmalloc string functions post.
Ideally we would like these to be private to mylib.h to avoid creating
complex dependencies. There might also be functions which are uniqure to
mylib.h, but not suitable to call directly, and cannot sensibly be declared
static.
The multiple dependency problem is a very real one. A simple cross-product
routine can suck in "vector.h" and "vector.c" which sucks in a load of
matrix algebra, typedefs for floats, a fast sine library, and a special
memory allocator. There's no real answer in standard C. I'd say it is the
number one weakness of the language.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
David Mearsen wrote:
>
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at the
top of the mylib.c file, or to create a separate mylib_private.h file?
If your idea of a "module" is synonymous with a ".c file", the you don't need an
extra file since you can indeed put all internal declarations at the beginning
of the .c file. I don't see the point of creating an extra include file for
this. The rationale for creating an include file is to be able to include it
into several translation units. This obviously doesn't apply here.
However, I personally find the it is more useful not to restrict a concept of a
"module" to a single implementation file. In that case a three-level file
structure might make sense. There's a single "external interface" include file,
like 'mylib_api.h', which declares the external interface of the module. There's
one or more "internal interface" files, like 'mylib1.h', 'mylib2.h' etc, which
declare interfaces between various implementation files within the module.
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
If you don't need any declarations from <stdlib.hin the .h file, then put it
in .c file. However, obviously, keeping it formally "clean" within this approach
might require a considerable maintenance effort. Let's say eventually you'll
need something declared in <stdlib.hin your .h file. Then you'll have to add
the declaration to your .h and remove it from all of your .c files. And vice
versa. At least with standard headers, it might prove to be more efficient to
always include them into .h files.
Also, sometimes certain compiler features (like pre-compiled header support)
might dictate their own style of header inclusion.
--
Best regards,
Andrey Tarasevich
cr88192 wrote:
>
"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
>Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
there are many "other languages"...
a simple hueristic ranking would look something like this:
1. C++
2. Java
3. VB
4. C#
5. Python
6. Perl
...
I think it's fairly clear that he means C++, which is often jokingly
called "That Other Language" by some C programmers.
<snip>
"cr88192" <cr*****@hotmail.comwrites:
"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
[...]
>Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
also, be careful with terms like "obviously" as well.
if one is wrong, then it can make them look arrogant and/or stupid...
now, not all non-static functions are part of the "public interface"
either (this is especially true once the complexity of a library moves
much past "trivial").
If a function isn't part of the public interface, why would you not
declare it as static?
[...]
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
"cr88192" <cr*****@hotmail.comwrites:
>"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
[...]
>>Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
also, be careful with terms like "obviously" as well.
if one is wrong, then it can make them look arrogant and/or stupid...
now, not all non-static functions are part of the "public interface"
either (this is especially true once the complexity of a library moves
much past "trivial").
If a function isn't part of the public interface, why would you not
declare it as static?
It might be called from a different compilation unit within the library.
--
Ian Collins.
Keith Thompson wrote:
"cr88192" <cr*****@hotmail.comwrites:
>"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
[...]
>>Specifically, consider a moderately complicated library module,
mylib.c. Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
also, be careful with terms like "obviously" as well.
if one is wrong, then it can make them look arrogant and/or stupid...
now, not all non-static functions are part of the "public interface"
either (this is especially true once the complexity of a library
moves much past "trivial").
If a function isn't part of the public interface, why would you not
declare it as static?
Presumably it's used by several source files within the same project,
but is not meant to be used by code from outside the project.
"santosh" <sa*********@gmail.comwrote in message
>
Presumably it's used by several source files within the same project,
but is not meant to be used by code from outside the project.
The other nuisance is when it would make perfect sense for it to be used by
files outside the project, but isn't part of the core fucntionality.
For instance a 3D geometry library in a protein manipulation program. You're
going to call functions like crossproduct() and so on. However the purpose
of the package is to handle proteins, not impose particular 3d geometry
routines on everyone.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean wrote:
"santosh" <sa*********@gmail.comwrote in message
>>
Presumably it's used by several source files within the same project,
but is not meant to be used by code from outside the project.
The other nuisance is when it would make perfect sense for it to be
used by files outside the project, but isn't part of the core
fucntionality. For instance a 3D geometry library in a protein
manipulation program. You're going to call functions like
crossproduct() and so on. However the purpose of the package is to
handle proteins, not impose particular 3d geometry routines on
everyone.
Well then, the obvious solution would be separate it into another
library. Sometimes this might be worth the extra effort and complexity,
sometimes not.
However we are drifting away from C to programming in general.
"santosh" <sa*********@gmail.comwrote in message
Malcolm McLean wrote:
>"santosh" <sa*********@gmail.comwrote in message
>>>
Presumably it's used by several source files within the same project,
but is not meant to be used by code from outside the project.
The other nuisance is when it would make perfect sense for it to be
used by files outside the project, but isn't part of the core
fucntionality. For instance a 3D geometry library in a protein
manipulation program. You're going to call functions like
crossproduct() and so on. However the purpose of the package is to
handle proteins, not impose particular 3d geometry routines on
everyone.
Well then, the obvious solution would be separate it into another
library. Sometimes this might be worth the extra effort and complexity,
sometimes not.
However we are drifting away from C to programming in general.
Then mylib becomes dependent on vector.lib.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...
"cr88192" <cr*****@hotmail.comwrites:
>"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
[...]
>>Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
also, be careful with terms like "obviously" as well.
if one is wrong, then it can make them look arrogant and/or stupid...
now, not all non-static functions are part of the "public interface"
either (this is especially true once the complexity of a library moves
much past "trivial").
If a function isn't part of the public interface, why would you not
declare it as static?
for a trivial library, maybe.
but for probably "most" of us, I would think, our libraries are anywhere
from 10 to 50 kloc, and may involve some number of interdependent source
files.
as a result, different parts of the library will depend on each other, and
thus need to be able to see each others' functions, however, the client for
this library, may have no good reason to see any of these functions (instead
being given a specific public API).
as a result, many non-public functions can't be static either...
as such, 'static' usually ends up being restricted to very narrowly defined
and context-specific functions, that we can be pretty sure will not need to
be called from another source file...
[...]
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Malcolm McLean" <re*******@btinternet.comwrote in message
news:V_******************************@bt.com...
>
"santosh" <sa*********@gmail.comwrote in message
>Malcolm McLean wrote:
>>"santosh" <sa*********@gmail.comwrote in message
Presumably it's used by several source files within the same project,
but is not meant to be used by code from outside the project.
The other nuisance is when it would make perfect sense for it to be
used by files outside the project, but isn't part of the core
fucntionality. For instance a 3D geometry library in a protein
manipulation program. You're going to call functions like
crossproduct() and so on. However the purpose of the package is to
handle proteins, not impose particular 3d geometry routines on
everyone.
Well then, the obvious solution would be separate it into another
library. Sometimes this might be worth the extra effort and complexity,
sometimes not.
However we are drifting away from C to programming in general.
Then mylib becomes dependent on vector.lib.
yes.
this kind of thing is annoyingly common, and will often end up necessitating
duplicating many smaller pieces of code from one place to another.
as a result, we end up with slight variations of cross-product spread
throughout the project...
still, some minor duplication is often somewhat preferable to a dependency.
a duplication, is a matter of a small amount of bloat.
a dependency, OTOH, ends up imposing on the client as well (oh crap, can no
longer use libfoo, because it uses a few trivial string functions from
libbar, and a port of libbar does not exist for the current architecture,
....).
or, at least, it is annoying to want to use one thing, and have to link
"discover" and link in bunches of other things (oh, now WTF lib do I need
for 'function_with_too_damn_many_words_but_no_library_ name'...).
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
I've recently started programming C after many years using "the other
language"
Just out of interest, why did you move to C from that 'other language' (I
guess C++ of something of that ilk)?
--
Bart
On Jan 27, 10:38*am, David Mearsen <no.spam.ple...@nospam.comwrote:
Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at the
top of the mylib.c file, or to create a separate mylib_private.h file?
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
Thanks for any input!
DM
The following article should help with defining a strategy for header
file includes. http://www.eventhelix.com/RealtimeMa...dePatterns.htm
The article is written for C++ but most of the ideas presented here
are applicable to C as well.
--
EventStudio 4.0 - http://www.Eventhelix.com/Eventstudio/
Sequence diagram based systems engineering tool
"cr88192" <cr*****@hotmail.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...
>"cr88192" <cr*****@hotmail.comwrites:
>>"David Mearsen" <no************@nospam.comwrote in message
news:sl*******************@nospam.invalid...
[...]
>>>Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
also, be careful with terms like "obviously" as well.
if one is wrong, then it can make them look arrogant and/or stupid...
now, not all non-static functions are part of the "public interface"
either (this is especially true once the complexity of a library moves
much past "trivial").
If a function isn't part of the public interface, why would you not
declare it as static?
for a trivial library, maybe.
but for probably "most" of us, I would think, our libraries are
anywhere from 10 to 50 kloc, and may involve some number of
interdependent source files.
as a result, different parts of the library will depend on each other,
and thus need to be able to see each others' functions, however, the
client for this library, may have no good reason to see any of these
functions (instead being given a specific public API).
as a result, many non-public functions can't be static either...
as such, 'static' usually ends up being restricted to very narrowly
defined and context-specific functions, that we can be pretty sure
will not need to be called from another source file...
You're right. There are different levels of "publicness"; a function
that shouldn't be visible to clients of a library might well need to
be visible to other source files within the same library. The problem
is that C provides only two levels rather than an arbitrary hierarchy
that might better represent an application's actual requirements. In
practice, it's not too hard to deal with this; it mostly requires some
care in the choice of identifiers so that things that aren't supposed
to be visible don't cause collisions.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
David Mearsen wrote:
Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file, or to put them at the
top of the mylib.c file, or to create a separate mylib_private.h file?
There is no point in placing them in mylib.h. If they are only used in
mylib.c, place them in mylib.c. If they're used on other files which are
part of the library implementation, place them in a separate file.
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter. Obviously,
I'll need to #include<stdio.hat the top of mylib.h to get the FILE
structure defined.
But say in the implementation, in mylib.c, I need to use (for example)
malloc. Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
If there is no reason why every program calling functions from mylib.c
needs the declarations in stdlib.h, there is no point in including it in
the header used for the interface.
--
Army1987 (Replace "NOSPAM" with "email")
David Mearsen wrote:
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter. Obviously,
I'll need to #include<stdio.hat the top of mylib.h to get the FILE
structure defined.
There is a school of thought (see Plan9) that says you should not
include headers within heathers. If your heather file mylib.h depends
on stdlib.h for its declarations, you should only state that
dependency (in a doc file or a comment at the beginning of the header,
or indeed both) and let the user decide which stdlib.h to include.
To this effect the authors of Plan9 (the original authors of unix +
some), recommend not to use header guards.
On Mon, 28 Jan 2008 04:47:27 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>David Mearsen wrote:
>And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter. Obviously,
I'll need to #include<stdio.hat the top of mylib.h to get the FILE
structure defined.
There is a school of thought (see Plan9) that says you should not
include headers within heathers. If your heather file mylib.h depends
on stdlib.h for its declarations, you should only state that
dependency (in a doc file or a comment at the beginning of the header,
or indeed both) and let the user decide which stdlib.h to include.
To this effect the authors of Plan9 (the original authors of unix +
some), recommend not to use header guards.
Really? What's the perceived benefit?
--
Al Balmer
Sun City, AZ
Al Balmer wrote:
On Mon, 28 Jan 2008 04:47:27 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>David Mearsen wrote:
>>And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter. Obviously,
I'll need to #include<stdio.hat the top of mylib.h to get the FILE
structure defined.
There is a school of thought (see Plan9) that says you should not
include headers within heathers. If your heather file mylib.h depends
on stdlib.h for its declarations, you should only state that
dependency (in a doc file or a comment at the beginning of the header,
or indeed both) and let the user decide which stdlib.h to include.
To this effect the authors of Plan9 (the original authors of unix +
some), recommend not to use header guards.
Really? What's the perceived benefit?
I don't see any benefits using this approach.
When you have a header file defining some project specific types and you
use those types in function declarations, people will expect you include
the header file defining them in your header file containing the
function declarations.
Not doing this will make it for most people a lot more difficult to work
and debug.
- Jensen
The above follows from a paper by Rob Pike about headers and header
guards. A quick look on Google should bring up the paper quickly.
On Mon, 28 Jan 2008 08:17:28 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>There is a school of thought (see Plan9) that says you should not
include headers within heathers. If your heather file mylib.h depends
on stdlib.h for its declarations, you should only state that
dependency (in a doc file or a comment at the beginning of the header,
or indeed both) and let the user decide which stdlib.h to include.
>To this effect the authors of Plan9 (the original authors of unix +
some), recommend not to use header guards.
Really? What's the perceived benefit?
<sig block snipped >
>
Flexibility, standards compliant in hosted implementations,
cleanliness of headers, reduce maintenance headache.
Here is an extract from the Plan9 C compiler manual/tutorial:
The given extract does not recommend against using header guards, nor
does it actually recommend not including headers within headers. It
does give one example of not doing so, but no rationale. Perhaps there
are reasons not to change an existing libc.h.
IAC, this is sure to *add* to maintenance headaches, not reduce them,
and the only flexibility it adds is the opportunity to scratch your
head about which headers are missing. Sorry, I don't see the benefit.
--
Al Balmer
Sun City, AZ
My personal rule would be: Any header file should compile fine if it
is included at the top of a source file. And any header file should
compile fine if it is included twice. So
myfile.c:
#include "mylib.h"
and
myfile.c:
#include "mylib.h"
#include "mylib.h"
should both compile without problems. Forward declarations of structs
can help with this, if you don't want to include too many files in
mylib.h. Guards inside the file (#ifndef MYLIB_HEADER_ #define
MYLIB_HEADER_ <real code#endif) help as well.
I'd hope that any preprocessor nowadays should be clever enough not to
actually read header files with guards twice.
David Mearsen wrote:
>
Hi,
I've recently started programming C after many years using "the other
language"... I just wanted to find out the common practice for
organising source files.
Specifically, consider a moderately
complicated library module, mylib.c.
Obviously its "public interface" (i.e. non-static function
declarations, typedefs, any global variables) need to go in mylib.h.
Obviously.
The question is: what about private (i.e. static) functions and struct
declarations and typedefs only used in the private implementation?
Is it more usual to put these in the mylib.h file,
or to put them at the top of the mylib.c file,
or to create a separate mylib_private.h file?
I declare them at the top of the c file,
and define static functions lower down. http://www.mindspring.com/~pfilandr/...les/list_lib.c
And a similar question for #includes: let's suppose that one of the
public functions declared in mylib.h takes a FILE* parameter.
I have an h file like that. http://www.mindspring.com/~pfilandr/...les/list_lib.h
Obviously, I'll need to #include<stdio.hat the top of mylib.h to get
the FILE structure defined.
Obviously.
But say in the implementation, in mylib.c,
I need to use (for example) malloc.
list_lib.c is like that.
Then I need to #include<stdlib.has well. Should I put the
#include at the top of mylib.h or at the top of mylib.c?
I put those kinds of includes, in the c file.
My list_lib.c has
#include <stdlib.h>
#include <string.h>
but my list_lib.h, doesn't.
I have a toy library here: http://www.mindspring.com/~pfilandr/C/library/
I comment lists of which features from the included
c standard headers are being used, in the c files and h files.
--
pete
fnegroni <f.*********@googlemail.comwrote:
I am not a noob
Then you should learn to quote. If your programming style is similar to
your Usenet style, no wonder you want everything as flat as possible.
Richard
On Jan 29, 7:47 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
fnegroni <f.e.negr...@googlemail.comwrote:
I am not a noob
Then you should learn to quote.
And you Richard Bos should learn to quote sentences IN FULL to the
full stop mark, instead of extracting the parts that make what you say
look good.
I said I was not a noob of C programming, what has that got to do with
my usenet style? Nothing.
Granted my usenet style is not as great and devoid of mistakes as
yours, but I *will* improve with time.
fnegroni wrote:
On Jan 29, 7:47 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>fnegroni <f.e.negr...@googlemail.comwrote:
>>I am not a noob
Then you should learn to quote.
And you Richard Bos should learn to quote sentences IN FULL to the
full stop mark,
And you should learn that this is the real world, where people don't
have to quote you in full and your words may be taken out of context.
>instead of extracting the parts that make what you say
look good.
Or making you look foolish.
Granted my usenet style is not as great and devoid of mistakes as
yours, but I *will* improve with time.
Sure. Meanwhile, don't get too worried if people seem to be picking on
you. They're not.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
"cr88192" <cr*****@hotmail.comwrote in message
>
waiting for the preprocessor is not such a big problem anymore (nor are
build times that scarily long...).
I don't even use makefiles any more. Just gcc *.c -lm.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
On Mon, 28 Jan 2008 12:59:17 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>On Jan 28, 6:29*pm, Al Balmer <albal...@att.netwrote:
]The given extract does not recommend against using header guards,
nor
>does it actually recommend not including headers within headers. It
does give one example of not doing so, but no rationale. Perhaps there
are reasons not to change an existing libc.h.
IAC, this is sure to *add* to maintenance headaches, not reduce them,
and the only flexibility it adds is the opportunity to scratch your
head about which headers are missing. Sorry, I don't see the benefit.
That's the opinion of Al Balmer.
Let's see what Rob Pike's opinion is, shall we?
Who is Rob Pike? http://herpolhode.com/rob/
I'm well aware of who Rob Pike is :-) The notes you reference were
written in disagreement of practices espoused by Brian Kernighan and
P. J. Plauger. (I suppose you know who they are?)
While I respect Mr. Pike and the contributions he's made, IMO he's all
wet on this issue. He apparently expects that the programmer read
every header before using it, or at least inspects it for comments
specifying its prerequisites. The only benefit he offers is saving
work for the compiler. Perhaps compilers have gotten better since
1989, but I don't find that a compelling reason to make such a mess.
--
Al Balmer
Sun City, AZ
In article <df********************************@4ax.com>,
Al Balmer <al******@att.netwrote:
>While I respect Mr. Pike and the contributions he's made, IMO he's all
wet on this issue. He apparently expects that the programmer read
every header before using it, or at least inspects it for comments
specifying its prerequisites.
While I don't use this style myself, it makes slightly more sense if
headers correspond directly to libraries. On most systems you're
going to have to find out what the header/library uses anyway, so that
you can specify it to the linker.
-- Richard
--
:wq
On 29 Jan, 15:41, Al Balmer <albal...@att.netwrote:
On Mon, 28 Jan 2008 12:59:17 -0800 (PST), fnegroni
The notes you reference were
written in disagreement of practices espoused by Brian Kernighan and
P. J. Plauger. (I suppose you know who they are?)
So why is it that a standard header never includes another standard
header?
Why should mylib.h, a third party file which I should not have to
modify, include <stdio.hjust because it uses FILE ?
Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h). Why should mylib.h override my
definition of FILE ?
On Tue, 29 Jan 2008 10:10:23 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>Why should mylib.h, a third party file which I should not have to
modify, include <stdio.hjust because it uses FILE ?
Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h).
If you worked here, I would give you a very practical reason. Your
code would be rejected at review, and you would be told to fix it and
not do something like that again.
--
Al Balmer
Sun City, AZ
"fnegroni" <f.*********@googlemail.comwrote in message
>
So why is it that a standard header never includes another standard
header?
Why should mylib.h, a third party file which I should not have to
modify, include <stdio.hjust because it uses FILE ?
Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h). Why should mylib.h override my
definition of FILE ?
Version one of mylib.h does no IO. Someone decides to provide load / saves
for version 2, and the functions take FILE * parameters. So your code could
easily break.
If you start defining your own FILE type I suggest we are very rapidly going
into the woods. However the whole dependency problem is very difficult.
We expect savecomplex() and loadcomplex() to be in complex.h. On the other
hand, we expect the complex routines to be independent of the IO we use.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
In article <f3**********************************@j20g2000hsi. googlegroups.com>,
fnegroni <f.*********@googlemail.comwrote:
>Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h).
Not in standard C you can't.
Why should mylib.h override my definition of FILE ?
If you're not concerned about sticking to the letter of standard C,
you can almost certianly arrange for mylib.h's #include <stdio.h>
to get your version.
-- Richard
--
:wq
On Jan 29, 6:45*pm, Al Balmer <albal...@att.netwrote:
If you worked here, I would give you a very practical reason. Your
code would be rejected at review, and you would be told to fix it and
not do something like that again.
Sure.
Next?
Malcolm McLean wrote:
>
"fnegroni" <f.*********@googlemail.comwrote in message
>>
So why is it that a standard header never includes another standard
header?
Why should mylib.h, a third party file which I should not have to
modify, include <stdio.hjust because it uses FILE ?
Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h). Why should mylib.h override my
definition of FILE ?
Version one of mylib.h does no IO. Someone decides to provide load /
saves for version 2, and the functions take FILE * parameters. So your
code could easily break.
Indeed, imagine the arse ache if mylib.h is included in scores or even
hundreds of files, all of which have to be updated...
--
Ian Collins.
On Tue, 29 Jan 2008 14:52:25 -0800 (PST), fnegroni
<f.*********@googlemail.comwrote:
>On Jan 29, 6:45*pm, Al Balmer <albal...@att.netwrote:
>If you worked here, I would give you a very practical reason. Your
code would be rejected at review, and you would be told to fix it and
not do something like that again.
Sure.
Next?
There wouldn't be a next ;-)
--
Al Balmer
Sun City, AZ
Indeed, imagine the arse ache if mylib.h is included in scores or even
hundreds of files, all of which have to be updated...
--
Ian Collins.
And you would do that manually? Ever heard of sed?
This is a recurring issue even with header files that include other
header files, where your code compiled even if you forgot to include a
file yourself, cause it was included by some other include, and no
warning was flagged up, and then that include file changed, no longer
including the include file you thought you did.
Anyway, it is a matter of opinion, since the standard does not impose
a rule on us, and it is part of what people call "coding practice".
Which is just a custom.
Considering how many wars have been started debating the merits/
demerits of curly bracket positioning and tab alignment or spaces, I
think C programmers tend to believe there is only one way of doing
things, and never move on.
If that was the case, many programs we all know (e.g. linux) would not
exist since they explicitly use some extension of the gcc compiler to
achieve their goals.
I am not posting here to tell *you* what to do (unlike some of you
telling *me* what to do. Heck, if you still are doing code reviews, it
is time to move on in your career).
I am just saying there are people who beg to differ in their opinion,
and those opinions have their merits.
You disagree with me, fine. Just don't tell me to shut up or get a job
somewhere else, because that just sounds to me like you just need a
fix.
On Jan 29, 11:45*pm, fnegroni <f.e.negr...@googlemail.comwrote:
Building our product on a mere quad core xeon with 4GB ram only takes
a mere 2 hours.
But then we compile our code on 26 platforms, some are even slower...
BTW, 2 hours if using incremental linking and ccache.
fnegroni wrote:
>Indeed, imagine the arse ache if mylib.h is included in scores or even
hundreds of files, all of which have to be updated...
*Please* don't quote signatures.
>
And you would do that manually? Ever heard of sed?
It's still a pain in the arse compared with updating one file.
I am just saying there are people who beg to differ in their opinion,
and those opinions have their merits.
People tend to disagree with you because your arguments are based on
decades old issues which have little relevance to contemporary tools and
machines. For example, with many compiles, including all of your
headers in one "umbrella" header will speed up compilation significantly
through the use of precompiled headers.
You disagree with me, fine. Just don't tell me to shut up or get a job
somewhere else, because that just sounds to me like you just need a
fix.
I didn't, I don't care one way or the other, if a client works one way
I'll do as they ask. But if you are going to argue based on anything
other than personal opinion, at least argue valid points.
--
Ian Collins.
On 29 Jan 2008, fnegroni <f.*********@googlemail.comwrote:
On 29 Jan, 15:41, Al Balmer <albal...@att.netwrote:
>On Mon, 28 Jan 2008 12:59:17 -0800 (PST), fnegroni
The notes you reference were
written in disagreement of practices espoused by Brian Kernighan
and P. J. Plauger. (I suppose you know who they are?)
So why is it that a standard header never includes another
standard header?
I don't agree with the no-including-headers-in-headers view, but
this is a good question which I don't see has been answered. It has
always seemed odd to me that, for instance, NULL is defined in more
than one standard header file. Why wasn't it put in, say, stddef.h
with stddef.h then #included in stdio.h, stdlib.h, etc.? (It seems
to violate the DRY principle, which is something *I* never do ;-)
I'll bet this is covered in P.J. Plauger's Standard C Library, but
my copy is at home. Is it just a historical artifact? Anyone care
to explain?
Dave
--
D.a.v.i.d T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m
David Tiktin wrote, On 29/01/08 23:58:
On 29 Jan 2008, fnegroni <f.*********@googlemail.comwrote:
>On 29 Jan, 15:41, Al Balmer <albal...@att.netwrote:
>>On Mon, 28 Jan 2008 12:59:17 -0800 (PST), fnegroni
The notes you reference were
written in disagreement of practices espoused by Brian Kernighan
and P. J. Plauger. (I suppose you know who they are?)
So why is it that a standard header never includes another
standard header?
I don't agree with the no-including-headers-in-headers view, but
this is a good question which I don't see has been answered. It has
always seemed odd to me that, for instance, NULL is defined in more
than one standard header file. Why wasn't it put in, say, stddef.h
with stddef.h then #included in stdio.h, stdlib.h, etc.? (It seems
to violate the DRY principle, which is something *I* never do ;-)
I'll bet this is covered in P.J. Plauger's Standard C Library, but
my copy is at home. Is it just a historical artifact? Anyone care
to explain?
Where I have looked at system headers they include other (often private)
headers. The standard does not say that a system header cannot include
another header, it says that it must behave as if it does not include
any of the other headers defined by the standard.
--
Flash Gordon
On Jan 30, 8:28*am, Flash Gordon <s...@flash-gordon.me.ukwrote:
Where I have looked at system headers they include other (often private)
headers. The standard does not say that a system header cannot include
another header, it says that it must behave as if it does not include
any of the other headers defined by the standard.
But *why?* is the question. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Stuart Turner |
last post by:
Hi Everyone,
I'm working hard trying to get Python 'accepted' in the organisation I work
for. I'm making some good in-roads. One chap sent me the text below on
his views of Python. I wondered...
|
by: Galina |
last post by:
Hello
I recently updated my database applications from MS Access 97 to
Access 2000. I somehow missed that the security file also should have
been updated. All went fine and smooth. The...
|
by: dawn |
last post by:
Hi all,
I am now working on a C program under Unix.
The requirement for the program is that:
A file name is passed to program as a parameter. The program will
Find files under a specified...
|
by: Niggy |
last post by:
I am trying to load a file from a dropdownlist, however I get a error saying
a virtual path is required. An example selected value would be
"../4900/myfile.doc". Any ideas - my code is.
Dim...
|
by: adserte |
last post by:
I have a security related question.
I was wondering how i can set up security so that for a table:
a user can read all data in the table but only update and delete their
own data (there is a...
| | |
by: ben |
last post by:
hello there,
oh dear, oh dear.
here's a non global array of strings:
char *chararray = { "abc", "defgh", "ijklmop" };
how do i do that so chararray is global? what goes in a .h file and...
|
by: phanipep |
last post by:
explain what is a indexed sequential file organisation,also give two advantages of sequential of indexed sequential file organisation ?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
