Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > what is the best way

Reply
Thread Tools

what is the best way

 
 
Andre
Guest
Posts: n/a
 
      11-27-2012
to organize source in a multi soucres project.
Is a main.h file with every definition for every sources the best or
a each.h file for each.c file the best.
It's a verry loooong time last I used c.
André
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-27-2012
Andre <(E-Mail Removed)> writes:

| what is the best way
> to organize source in a multi soucres project.
> Is a main.h file with every definition for every sources the best or
> a each.h file for each.c file the best.


The latter is more common and easier to understand later.

Not every .c file will have a .h file (the file defining main, for
example, very often will not define anything that other modules need to
see) and not all .h file will correspond to a .c file (for example a
.. file that contains nothing but macros, types and inline functions).

--
Ben.
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      11-27-2012
On Tuesday, November 27, 2012 3:19:24 PM UTC, Andre wrote:
> to organize source in a multi soucres project.
>
> Is a main.h file with every definition for every sources the best or
> a each.h file for each.c file the best.
>

Arrange the functions logically in modules. Normally you'll only want to
export a subset of the functions in each module, the others won't make
any sense except as subroutines to the other functions.
Put these in a matching .h file. Add #include guards (#ifndef myfile_h
#define myfile_h /* prototypes here */ #endif ).
It's better to make each .h includeable on its own. So it needs to internally
#include any dependencies.

--
Vist Malcolm's website
http://www.malcolmmclean.site11.com/www



 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-27-2012
On 11/27/2012 10:19 AM, Andre wrote:
> to organize source in a multi soucres project.
> Is a main.h file with every definition for every sources the best or
> a each.h file for each.c file the best.
> It's a verry loooong time last I used c.


There's lots of different ways to do this. My own convention has been to
create one header file for each module, which will in general contain
multiple function definitions, but usually only one with external
linkage. The header file will provide declarations for every identifier
with external linkage defined in that module. If there are no such
identifiers (this is often the case for the module which defines
main()), no header is needed. The header will also contain definitions
for every typedef and every struct, union, or enumeration needed by
those declarations. If there are any special values associated with the
arguments or return value of any of the functions it declares, it will
#define macros for those values. Every #define and type definition will
appear explicitly only in one particular header file; they will be
#included into any other header where needed.
For libraries, the headers associated with each module in the library
are used only for compiling those modules. I prepare a special header
for users of the library, declaring only those identifiers with external
linkage that users are intended to access, along with the associated
types and macros.
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      11-27-2012
Andre wrote:
> to organize source in a multi soucres project.
> Is a main.h file with every definition for every sources the best or
> a each.h file for each.c file the best.
> It's a verry loooong time last I used c.
> André



There is no "best". Still:

- Have one header .h per .c file.
- Have all the #includes needed for that .c file #included in the .h
file. That way, if there are 7 c files, "grep "#include" *.c | wc " will
be 7.

- Have this basic structure:

thing.h:

#ifndef _THING_H_
#define _THING_H_ 1
....
#endif

guarding all header files.

- Use "gcc -M *.c > .depend" ( or equivalent ) in your makefile. Then if
you want, use "source .depend" or "include .depend" at the bottom.

- Don't have an "includes" or "headers" directory for .h files unless
you somehow need to.

All IMO.


--
Les Cargill
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-27-2012
James Kuyper wrote:
> On 11/27/2012 10:19 AM, Andre wrote:
>> to organize source in a multi soucres project.
>> Is a main.h file with every definition for every sources the best or
>> a each.h file for each.c file the best.
>> It's a verry loooong time last I used c.

>
> There's lots of different ways to do this. My own convention has been to
> create one header file for each module, which will in general contain
> multiple function definitions, but usually only one with external
> linkage.


Either I'm parsing that wrong, or you've written it wrong. How and why
would you have a function declaration in a (public) header if it doesn't
have external linkage?

--
Ian Collins
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-27-2012
Les Cargill wrote:
> Andre wrote:
>> to organize source in a multi soucres project.
>> Is a main.h file with every definition for every sources the best or
>> a each.h file for each.c file the best.
>> It's a verry loooong time last I used c.
>> André

>
>
> There is no "best". Still:
>
> - Have one header .h per .c file.


That isn't necessarily a good idea. If a header declares the interface
to a module or library, the functions declared in the header are often
defined in more than one C file.

How to manage interface declarations and implementations really depends
on the the complexity of the application and the environment. In most
large projects I've seen or worked on there are a mix of public and
module private headers. OS libraries are a good example of this, there
will be a public header which ends up being part of the end user
distribution and private headers that never leave the private source tree.

> - Have all the #includes needed for that .c file #included in the .h
> file. That way, if there are 7 c files, "grep "#include" *.c | wc " will
> be 7.


This practice often causes more trouble than it is worth.

> - Have this basic structure:
>
> thing.h:
>
> #ifndef _THING_H_
> #define _THING_H_ 1


The 1 is unusual and superfluous.

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-27-2012
On 11/27/2012 02:43 PM, Ian Collins wrote:
> James Kuyper wrote:
>> On 11/27/2012 10:19 AM, Andre wrote:
>>> to organize source in a multi soucres project.
>>> Is a main.h file with every definition for every sources the best or
>>> a each.h file for each.c file the best.
>>> It's a verry loooong time last I used c.

>>
>> There's lots of different ways to do this. My own convention has been to
>> create one header file for each module, which will in general contain
>> multiple function definitions, but usually only one with external
>> linkage.

>
> Either I'm parsing that wrong, or you've written it wrong. How and why
> would you have a function declaration in a (public) header if it doesn't
> have external linkage?


The "which will ..." clause was describing the module, not the header
file. I agree that I should have written that more clearly. How about this:

I generally create modules which may contain multiple function
definitions, but usually only one with external linkage. My convention
has been to create one header file for each module.

Is that better?

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-27-2012
James Kuyper wrote:
> On 11/27/2012 02:43 PM, Ian Collins wrote:
>> James Kuyper wrote:
>>> On 11/27/2012 10:19 AM, Andre wrote:
>>>> to organize source in a multi soucres project.
>>>> Is a main.h file with every definition for every sources the best or
>>>> a each.h file for each.c file the best.
>>>> It's a verry loooong time last I used c.
>>>
>>> There's lots of different ways to do this. My own convention has been to
>>> create one header file for each module, which will in general contain
>>> multiple function definitions, but usually only one with external
>>> linkage.

>>
>> Either I'm parsing that wrong, or you've written it wrong. How and why
>> would you have a function declaration in a (public) header if it doesn't
>> have external linkage?

>
> The "which will ..." clause was describing the module, not the header
> file. I agree that I should have written that more clearly. How about this:
>
> I generally create modules which may contain multiple function
> definitions, but usually only one with external linkage. My convention
> has been to create one header file for each module.
>
> Is that better?


Yes

--
Ian Collins
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      11-27-2012
On Tue, 2012-11-27, Ian Collins wrote:
> Les Cargill wrote:
>> Andre wrote:
>>> to organize source in a multi soucres project.
>>> Is a main.h file with every definition for every sources the best or
>>> a each.h file for each.c file the best.
>>> It's a verry loooong time last I used c.
>>> André

>>
>>
>> There is no "best". Still:
>>
>> - Have one header .h per .c file.

>
> That isn't necessarily a good idea. If a header declares the interface
> to a module or library, the functions declared in the header are often
> defined in more than one C file.


I took it to be more of a rule of thumb.

> How to manage interface declarations and implementations really depends
> on the the complexity of the application and the environment.

....

>> - Have all the #includes needed for that .c file #included in the .h
>> file. That way, if there are 7 c files, "grep "#include" *.c | wc " will
>> be 7.

>
> This practice often causes more trouble than it is worth.


Yes -- that seems highly unusual and impractical. E.g. anyone who
wants to use the interface provided by foo.h will be poisoned by
everything needed to implement foo.c!

Note that this is distinct from the idea of idempotent header files --
the idea that foo.h doesn't have a secret "shopping list" of other
header files which must be included first to make '#include "foo.h"'
compile.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best way to loop through ArrayList and remove elements on the way? Kevin Java 16 01-30-2008 08:54 PM
way way way OT: MCNGP Announcement Neil MCSE 174 04-17-2006 05:55 PM
Any way/Best way to simulate 3:2 mode on an S2 IS? Joe Digital Photography 0 03-09-2006 05:35 PM
AMD Opteron: 1-way, 2-way, ... Up to 8-way. John John Windows 64bit 12 12-27-2005 08:17 AM
What is the best way to make dual-way xml databinding? Stan ASP .Net 3 05-05-2005 02:07 PM



Advertisments