Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93934 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2016-09-23 10:45 +0100 |
| Last post | 2016-09-23 11:37 -0400 |
| Articles | 10 on this page of 70 — 16 participants |
Back to article view | Back to comp.lang.c
To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-23 10:45 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 12:43 +0200
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-23 12:17 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:32 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 14:57 +0200
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-24 20:34 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 23:55 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 01:43 +0100
Re: To include or not to include Ian Collins <ian-news@hotmail.com> - 2016-09-25 14:38 +1300
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:42 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 11:58 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-25 14:06 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 15:15 +0100
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:33 +0800
Re: To include or not to include Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-25 10:04 -0600
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-26 00:21 +0800
Re: To include or not to include "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 13:17 -0400
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-26 00:18 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-26 17:55 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-26 20:07 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-26 12:13 -0700
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-27 01:25 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-26 18:05 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 14:27 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 14:49 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:15 +0100
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 07:42 -0700
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 09:30 -0700
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 10:06 -0700
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 08:12 -0700
Re: To include or not to include Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:46 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 17:55 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 10:19 -0700
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 11:42 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 19:57 +0100
Re: To include or not to include Keith Thompson <kst-u@mib.org> - 2016-09-27 12:38 -0700
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-27 21:00 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-28 01:50 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-28 10:55 +0100
Re: To include or not to include Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 13:33 -0700
Re: To include or not to include Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:13 +0000
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 12:38 -0700
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-27 20:57 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-27 07:25 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-28 00:28 +0100
Re: To include or not to include supercat@casperkitty.com - 2016-09-30 07:53 -0700
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 16:06 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:53 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-30 19:46 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 20:27 +0100
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:27 +0800
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 11:38 -0400
Re: To include or not to include Reinhardt Behm <rbehm@hushmail.com> - 2016-09-25 23:40 +0800
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 15:06 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 11:49 -0400
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 18:05 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 16:42 -0400
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 21:53 +0100
Re: To include or not to include Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 17:57 -0400
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 21:20 +0100
Re: To include or not to include BartC <bc@freeuk.com> - 2016-09-25 21:49 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-26 00:40 +0100
Re: To include or not to include David Brown <david.brown@hesbynett.no> - 2016-09-23 14:56 +0200
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 13:31 +0100
Re: To include or not to include James Harris <james.harris.1@gmail.com> - 2016-09-23 13:52 +0100
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 14:35 +0100
Re: To include or not to include Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 18:55 +0100
Re: To include or not to include Richard Heathfield <rjh@cpax.org.uk> - 2016-09-23 20:33 +0100
Re: To include or not to include Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-23 08:22 -0600
Re: To include or not to include Richard Damon <Richard@Damon-Family.org> - 2016-09-23 11:37 -0400
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-25 21:49 +0100 |
| Message-ID | <ns9d96$hgp$1@dont-email.me> |
| In reply to | #94046 |
On 25/09/2016 21:20, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> But global functions, global typedefs, global struct tags, global enum >> names, global #defines and global #includes (ie. module names) are >> still acceptable? It could get tricky otherwise. > > I'm not sure I know what all these are. I think you do. They're just names of entities that are visible across multiple modules in an application. Look at a header such as windows.h (and its nested includes). Names declared or defined there will be visible in every module that includes windows.h. > I used the term "global" > because I wanted to relate C to the developments in programming style > that have been evolving for 60 years or so. And I used scare quotes > because "global" is not properly defined in C. Ill-defined is the better term. It's not even clear what 'extern' is supposed to mean. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-26 00:40 +0100 |
| Message-ID | <87a8eveef9.fsf@bsb.me.uk> |
| In reply to | #94049 |
BartC <bc@freeuk.com> writes: > On 25/09/2016 21:20, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> But global functions, global typedefs, global struct tags, global enum >>> names, global #defines and global #includes (ie. module names) are >>> still acceptable? It could get tricky otherwise. >> >> I'm not sure I know what all these are. > > I think you do. Ah. Then I hope you know my answer too. That will save us both some time. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-23 14:56 +0200 |
| Message-ID | <ns38p8$5u6$1@dont-email.me> |
| In reply to | #93937 |
On 23/09/16 13:17, BartC wrote: > On 23/09/2016 11:43, David Brown wrote: >> On 23/09/16 11:45, James Harris wrote: >>> I often have at the top of a C source file, which I'll call F, an >>> include for its corresponding header: >>> >>> #include "F.h" >>> >>> After that come the various includes I need for the .c code that >>> follows. >>> >>> In many cases the .c and the .h include some of the same files. They >>> might both pull in stdio.h or string.h, for example. >>> >>> Of course, I could omit from F.c at least some of the headers which F.h >>> includes. But I tend to take the approach of including in the .c all >>> those the .c code needs. >>> >>> Assuming either approach is just as valid, which is the best style or is >>> one more idiomatic than the other? >>> >>> >>> As an aside, in F.c I include F.h so that the compiler can check that >>> function definitions (in F.c) match function declarations (in F.h). So, >>> if it's relevant, I guess I tend to use includes as a policy rather than >>> as a mechanism for managing other includes. >>> >> >> I prefer the following rules for includes: >> >> 1. F.c should include F.h, to make sure that function definitions in F.c >> and function declarations in F.h match. >> >> 2. I make sure that any functions or file-level variables in F.c are >> either defined "static" in F.c, or they are declared "extern" in F.h and >> have matching definitions in F.c. >> >> 3. Header F.h should include all the headers it needs in order to be >> complete. If G.c includes F.h, it should not have to include anything >> else before or after it. So if F.h declares a function that takes a >> uint32_t, then F.h must include stdint.h. > > My rules would be a little different (using example module A): > > * A.h should only contain declarations for A.c that will be exported to > or shared with other modules I should have included that in my rule 2. I suppose I thought it was obvious that the header only declares things that need to be exported, but some people seem to think it is a good idea to put all sorts of stuff in their headers, and fail to use "static" in their C files. > > * A.h should not contain any includes that are not needed for A.h > itself. Only includes that are necessary for A.h to compile as a > standalone file. (For example, including a header that contains > macros and typedefs used by A.h's declarations) That could also be added to my rule 3. A.h should have all the includes it needs, but /only/ the includes that it needs.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-23 13:31 +0100 |
| Message-ID | <ns37a8$jj$1@dont-email.me> |
| In reply to | #93934 |
On 23/09/16 10:45, James Harris wrote:
> I often have at the top of a C source file, which I'll call F, an
> include for its corresponding header:
>
> #include "F.h"
>
> After that come the various includes I need for the .c code that follows.
>
> In many cases the .c and the .h include some of the same files. They
> might both pull in stdio.h or string.h, for example.
>
> Of course, I could omit from F.c at least some of the headers which F.h
> includes. But I tend to take the approach of including in the .c all
> those the .c code needs.
So do I.
> Assuming either approach is just as valid, which is the best style or is
> one more idiomatic than the other?
If all the relevant headers are idempotent, then there is no technical
reason not to include all the headers the source needs, in an explicit
way. Thus, if we have:
/* f.h */
#ifndef F_H__
#define F_H__ 1
#include <stddef.h>
typedef size_t SIZE;
void *firstzerobyte(const void *vp, SIZE len);
#endif
/* end of f.h */
/* f.c */
#include "f.h"
#include <stddef.h> /* whether to include this is the point at issue */
void *firstzerobyte(const void *vp, SIZE len)
{
SIZE i = 0;
unsigned char *p = vp;
if(vp != NULL)
{
while(i < len && p[i] != '\0')
{
++i;
++p;
}
}
return p;
}
/* end of f.c */
then I would argue that it's better explicitly to include <stddef.h> in
f.c even though it's included in f.h. It adds a microscopic amount to
the runtime of the pre-processor phase ("#ifndef - hmm, it's defined, so
skip lightly through to the #endif'), and nothing to the runtime of the
program itself, so where's the harm? And the benefit is that, if you
later rip out the SIZE stuff, you don't have to stick back in all the
includes you left out because f.h included them.
And if the relevant headers are /not/ idempotent, then why the hell not?
(There is an exception: <assert.h> - but it's only an exception in
exceptional circumstances, and not something I'd lose any sleep over.)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-09-23 13:52 +0100 |
| Message-ID | <ns38hm$54o$1@dont-email.me> |
| In reply to | #93938 |
On 23/09/2016 13:31, Richard Heathfield wrote:
> On 23/09/16 10:45, James Harris wrote:
>> I often have at the top of a C source file, which I'll call F, an
>> include for its corresponding header:
>>
>> #include "F.h"
>>
>> After that come the various includes I need for the .c code that follows.
>>
>> In many cases the .c and the .h include some of the same files. They
>> might both pull in stdio.h or string.h, for example.
>>
>> Of course, I could omit from F.c at least some of the headers which F.h
>> includes. But I tend to take the approach of including in the .c all
>> those the .c code needs.
>
> So do I.
That's good enough for me.
>> Assuming either approach is just as valid, which is the best style or is
>> one more idiomatic than the other?
>
> If all the relevant headers are idempotent, then there is no technical
> reason not to include all the headers the source needs, in an explicit
> way. Thus, if we have:
>
> /* f.h */
> #ifndef F_H__
> #define F_H__ 1
> #include <stddef.h>
> typedef size_t SIZE;
> void *firstzerobyte(const void *vp, SIZE len);
> #endif
> /* end of f.h */
>
> /* f.c */
> #include "f.h"
> #include <stddef.h> /* whether to include this is the point at issue */
>
> void *firstzerobyte(const void *vp, SIZE len)
> {
> SIZE i = 0;
> unsigned char *p = vp;
> if(vp != NULL)
> {
> while(i < len && p[i] != '\0')
> {
> ++i;
> ++p;
> }
> }
> return p;
> }
> /* end of f.c */
>
> then I would argue that it's better explicitly to include <stddef.h> in
> f.c even though it's included in f.h. It adds a microscopic amount to
> the runtime of the pre-processor phase ("#ifndef - hmm, it's defined, so
> skip lightly through to the #endif'), and nothing to the runtime of the
> program itself, so where's the harm? And the benefit is that, if you
> later rip out the SIZE stuff, you don't have to stick back in all the
> includes you left out because f.h included them.
You've even gone beyond my original question! I have to say that, apart
from your use of NULL - for which I think stddef.h would be appropriate
- if the .c did not use size_t or anything else from stddef.h I would be
inclined not to include stddef.h in the .c file. ISTM that SIZE from f.h
would be enough. I am happy to be told that that is wrong but I cannot
see a reason to include that header if the code to follow did not make
any reference to anything defined therein.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-23 14:35 +0100 |
| Message-ID | <ns3b35$de8$1@dont-email.me> |
| In reply to | #93941 |
On 23/09/16 13:52, James Harris wrote: <snip> > > You've even gone beyond my original question! I have to say that, apart > from your use of NULL - for which I think stddef.h would be appropriate > - if the .c did not use size_t or anything else from stddef.h I would be > inclined not to include stddef.h in the .c file. That was *precisely* why I included NULL in the example. It shows that there may be dependencies in the source that are not in the (custom) header. I think it's better to deal with this by explicit inclusion than by relying on an interface that could easily change in the future. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-23 18:55 +0100 |
| Message-ID | <87oa3eh55v.fsf@bsb.me.uk> |
| In reply to | #93938 |
Richard Heathfield <rjh@cpax.org.uk> writes: <snip> > If all the relevant headers are idempotent, then there is no technical > reason not to include all the headers the source needs, in an explicit > way. Thus, if we have: > > /* f.h */ > #ifndef F_H__ > #define F_H__ 1 I tiny point... I like to put the H first, something like #ifndef H_F__ Any pattern that starts with the (capitalised) file name will run into problems with some file names, but no reserved macros happen to start with an H so one can safely make a rule that will not need any exceptions. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-23 20:33 +0100 |
| Message-ID | <ns401u$t1u$1@dont-email.me> |
| In reply to | #93959 |
On 23/09/16 18:55, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: <snip> >> If all the relevant headers are idempotent, then there is no >> technical reason not to include all the headers the source needs, >> in an explicit way. Thus, if we have: >> >> /* f.h */ #ifndef F_H__ #define F_H__ 1 > > I tiny point... I like to put the H first, something like > > #ifndef H_F__ Curious, because /so do I/. I have no idea why I put it last on this occasion. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-09-23 08:22 -0600 |
| Message-ID | <1bfuoqlmq8.fsf@pfeifferfamily.net> |
| In reply to | #93934 |
James Harris <james.harris.1@gmail.com> writes: > I often have at the top of a C source file, which I'll call F, an > include for its corresponding header: > > #include "F.h" > > After that come the various includes I need for the .c code that follows. > > In many cases the .c and the .h include some of the same files. They > might both pull in stdio.h or string.h, for example. > > Of course, I could omit from F.c at least some of the headers which > F.h includes. But I tend to take the approach of including in the .c > all those the .c code needs. > > Assuming either approach is just as valid, which is the best style or > is one more idiomatic than the other? > > > As an aside, in F.c I include F.h so that the compiler can check that > function definitions (in F.c) match function declarations (in > F.h). So, if it's relevant, I guess I tend to use includes as a policy > rather than as a mechanism for managing other includes. I like to have each of my files include all the .h files it depends on, so yes, I'd typically include them in redundant places. If they're properly protected from multiple inclusion it won't cause any harm, and it's fewer other places to look to figure out my own code years later.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-09-23 11:37 -0400 |
| Message-ID | <3%bFz.4947$Q_5.2737@fx15.iad> |
| In reply to | #93934 |
On 9/23/16 5:45 AM, James Harris wrote: > I often have at the top of a C source file, which I'll call F, an > include for its corresponding header: > > #include "F.h" > > After that come the various includes I need for the .c code that follows. > > In many cases the .c and the .h include some of the same files. They > might both pull in stdio.h or string.h, for example. > > Of course, I could omit from F.c at least some of the headers which F.h > includes. But I tend to take the approach of including in the .c all > those the .c code needs. > > Assuming either approach is just as valid, which is the best style or is > one more idiomatic than the other? > > > As an aside, in F.c I include F.h so that the compiler can check that > function definitions (in F.c) match function declarations (in F.h). So, > if it's relevant, I guess I tend to use includes as a policy rather than > as a mechanism for managing other includes. > My rules are: Except under EXTREME conditions (which shall be documented at point of declaration) no .c file will declare an external declaration for something not in the file, but will get the declaration from a header file. The external declarations for foo.c shall be in foo.h and foo.c will include foo.h as its first functional line of code (after file comments). In special cases which should be documented, it is possible to split the API for a file foo.c into foo1.h, foo2.h ... or to implement the API declared in foo.h in files foo1.c, foo2.c, ... (the names of the files don't need to be numeric additions, but can be a base name followed by some sort of modifier). All header files will have proper include guards on them based on the name of the file and in the user namespace to allow for multiple inclusions. All header files will include all needed headers to allow the header to be properly parsed without needing something else included before it. All .c files should include the header files for every API that they use, even if another header they include just happens to include it. The exception can be made if the other header by definition must include it (this happens more for C++, where the header for a derived class MUST include the header for the base class).
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web