Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Modularisation

Reply
Thread Tools

Modularisation

 
 
Steffen Loringer
Guest
Posts: n/a
 
      10-05-2005
Hi,

can anyone recommend a good wbeppage concerning modularisation of C
programs into different files?

Thanks to all of you
Steffen

 
Reply With Quote
 
 
 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-05-2005
"Steffen Loringer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> can anyone recommend a good wbeppage concerning modularisation of C
> programs into different files?


But what is the problem? Normally this is done by separating more or less
independent portions of the code into separate files. Just that. Of course
that may involve quite some coding, not just copy'n'pasting...
But as far as C goes, what's the problem?

Alex


 
Reply With Quote
 
 
 
 
Steffen Loringer
Guest
Posts: n/a
 
      10-05-2005
There is no real problem. But there may be rules for good coding etc...
I separated my functions "by function part of the program" into header
*.h and source *.c files.
I have to include many libraries for each *.h and *.c, does this make my
executable bigger at the end??

Thanks for your reply, Alexei!

Alexei A. Frounze schrieb:

> "Steffen Loringer" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>can anyone recommend a good wbeppage concerning modularisation of C
>>programs into different files?

>
>
> But what is the problem? Normally this is done by separating more or less
> independent portions of the code into separate files. Just that. Of course
> that may involve quite some coding, not just copy'n'pasting...
> But as far as C goes, what's the problem?
>
> Alex
>
>


 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-05-2005
*.h should contain public info that's intended for use by the caller, e.g.:
- macros
- type definitions
- inline functinos (you may need to declare them as "static inline" --
depends on the compiler I guess)
- externs
*.c should contain everything else that's internal and not to be exposed to
the outer world.
This is as far as the .h vs .c goes.
But then you also should separate the code semantically, put in different .?
files the code for different things, e.g.:
- input/output management (better to make an abstract API for portability)
- system layer (synchronization primitives, interprocess communication and
everything else that's system-specific -- better to make an abstract API for
portability)
- general purpose data structure management (e.g. searching, sorting, lists,
trees, hashtables, etc)
- task-oriented data processing (can be anything, ranging from text
processing and conversion to signal processing (audio, video, whatever),
data compression/encryption, various computation tasks -- every distinct set
of operations deserves its own file (or set of a few files))
- auxiliary/miscellaneous/helper functions of small importance and maybe
frequent use

I'm not sure what libraries you're talking about, but separating the code
into several compilaion units must not make it any bigger. Actually, it can
make it smaller (if you put the code that may not be used at all into a
separate .c file -- its object code won't be linked in unless necessary).
Each library and object file is linked only once unless your tools are
broken or allow some degree of misuse.

Mind you, separation of the code into distinct units, better as much
independednt as possible, allows for simpler maintainance, testing and
debugging. That's the primary reason to do such a thing. And don't forget
that recompilation of a single huge .c file will take longer than
recompilation of a small one.

Alex
P.S. please don't top post.
A: Yep, Alice in the Wonderland had first to serve the cake out to a few
persons and only then cut it in parts.
Q: Really? I don't get it. Could you give me an example?
A: Because it makes the flow of events complicated
Q: Why top posting is bad?

"Steffen Loringer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> There is no real problem. But there may be rules for good coding etc...
> I separated my functions "by function part of the program" into header
> *.h and source *.c files.
> I have to include many libraries for each *.h and *.c, does this make my
> executable bigger at the end??
>
> Thanks for your reply, Alexei!
>
> Alexei A. Frounze schrieb:
>
> > "Steffen Loringer" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >
> >>can anyone recommend a good wbeppage concerning modularisation of C
> >>programs into different files?

> >
> >
> > But what is the problem? Normally this is done by separating more or

less
> > independent portions of the code into separate files. Just that. Of

course
> > that may involve quite some coding, not just copy'n'pasting...
> > But as far as C goes, what's the problem?
> >
> > Alex
> >
> >

>



 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      10-05-2005
Alexei A. Frounze wrote:
<snip>

> *.c should contain everything else that's internal and not to be exposed to
> the outer world.


Oh really? Then where are funcations with external linkage defined?

<snip>
>
> I'm not sure what libraries you're talking about, but separating the code
> into several compilaion units must not make it any bigger. Actually, it can
> make it smaller (if you put the code that may not be used at all into a
> separate .c file -- its object code won't be linked in unless necessary).


Misleading at best. This will generally *not* occur unless the linker
is told to, or the group of object files are made into a static archive
before linking.

Also, for a discussion about executable sizes to be meaningful, you
have to consider the effect of shared libraries if the system in
question uses them.

> Each library and object file is linked only once unless your tools are
> broken or allow some degree of misuse.


Again, misleading. Depends on the circumstance, and how your linker
handles mutually referential libraries.

>
> Mind you, separation of the code into distinct units, better as much
> independednt as possible, allows for simpler maintainance, testing and
> debugging. That's the primary reason to do such a thing.


Agreed.

> And don't forget
> that recompilation of a single huge .c file will take longer than
> recompilation of a small one.


Not by too much, on today's systems.


Mark F. Haigh
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      10-05-2005
Alexei A. Frounze wrote:
> "Steffen Loringer" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>can anyone recommend a good wbeppage concerning modularisation of C
>>programs into different files?

>
>
> But what is the problem? Normally this is done by separating more or less
> independent portions of the code into separate files. Just that. Of course
> that may involve quite some coding, not just copy'n'pasting...
> But as far as C goes, what's the problem?


Since modularization is one of the weakest points of C you need some
good rules for how to do it. Still, even with an appropriate
modularization technique there is no way to declare types or (true)
constants with file scope (compare with Modula and Oberon).


August
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      10-05-2005
August Karlstrom wrote:

> Alexei A. Frounze wrote:
>
>> "Steffen Loringer" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>
>>> can anyone recommend a good wbeppage concerning modularisation of C
>>> programs into different files?

>>
>> But what is the problem? Normally this is done by separating more or less
>> independent portions of the code into separate files. Just that. Of
>> course
>> that may involve quite some coding, not just copy'n'pasting...
>> But as far as C goes, what's the problem?

>
> Since modularization is one of the weakest points of C you need some
> good rules for how to do it. Still, even with an appropriate
> modularization technique there is no way to declare types or (true)
> constants with file scope (compare with Modula and Oberon).


It's easy to declare types with file scope in C: Just Do It.

/*** foo.c ***/
struct s { int this; double that; }
struct s instance = { 42, 3.14 };
int getThis(struct s *sptr) {
return s->this;
}
/* More code using the `struct s' type freely */

/*** bar.c ***/
struct s anotherinstance = { -1, 98.6 };
/* sorry; won't compile: this code is outside the
scope of the `struct s' type declaration */

Constants are, I admit, harder to do. There's #define, but
prior to C99 it couldn't really declare a "constant" of compound
type other than string. There are enum identifiers, but they're
limited to integer constants. However, I don't see what these
peculiarities have to do with modularization.

--
Eric Sosman
(E-Mail Removed)lid


 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      10-05-2005
Alexei A. Frounze wrote:
>
> *.h should contain public info that's intended for use by the caller, e.g.:
> - macros
> - type definitions
> - inline functinos (you may need to declare them as "static inline" --
> depends on the compiler I guess)


Why put inline functions in the .h file?

--
pete
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      10-05-2005
Mark F. Haigh wrote:
>
> Alexei A. Frounze wrote:
> <snip>
>
> > *.c should contain everything else
> > that's internal and not to be exposed to
> > the outer world.

>
> Oh really? Then where are funcations with external linkage defined?


All function definitions and object definitions
belong in the .c files, regardless of linkage,
as far as I know.

--
pete
 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-05-2005
"Mark F. Haigh" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Alexei A. Frounze wrote:
> <snip>
>
> > *.c should contain everything else that's internal and not to be exposed

to
> > the outer world.

>
> Oh really? Then where are funcations with external linkage defined?


Exactly what do you mean?

> <snip>
> >
> > I'm not sure what libraries you're talking about, but separating the

code
> > into several compilaion units must not make it any bigger. Actually, it

can
> > make it smaller (if you put the code that may not be used at all into a
> > separate .c file -- its object code won't be linked in unless

necessary).
>
> Misleading at best. This will generally *not* occur unless the linker
> is told to,


It shouldn't be told to. Why linking a module into executable if out of this
module nothing is referenced, neither code nor data? I'd say misleading is
gluing in unuseful code and data.

> or the group of object files are made into a static archive
> before linking.


I don't know what you mean.

> Also, for a discussion about executable sizes to be meaningful, you
> have to consider the effect of shared libraries if the system in
> question uses them.


Indeed, I did not consider shared libraries in the response, so thank's for
the addition. The original poster didn't mention them, though...

> > Each library and object file is linked only once unless your tools are
> > broken or allow some degree of misuse.

>
> Again, misleading. Depends on the circumstance, and how your linker
> handles mutually referential libraries.


I don't know if misleading is one of your favorite self-and-all-explanatory
words... So what if lib1 references lib2 and that one references lib1 back?
Should I get 2 copies of the same code or data (from either lib)? Is that's
what you're saying? I was replying from the size standpoint when saying
*linked once*, I meant getting one instance of say fread() in the executable
and not two or more. I don't know how exactly I should interpret this your
comment, whether you're just uncomfortable with my meaning of "linked once"
and want to tell that the linker will have to go back and forth to resolve
the undefined references in the crossreferencing libraries or want to say
something else but don't say that... If it's the former, then that's
entirely different thing here and to me it has nothing to do with the size
of the code. If it's the latter, then please explain or I'm starting to feel
that your comment is misleading at best too.

> > Mind you, separation of the code into distinct units, better as much
> > independednt as possible, allows for simpler maintainance, testing and
> > debugging. That's the primary reason to do such a thing.

>
> Agreed.


Strange. I thought there would be not a single point of agreement.

> > And don't forget
> > that recompilation of a single huge .c file will take longer than
> > recompilation of a small one.

>
> Not by too much, on today's systems.


Which means you've never been involved in projects whose size and complexity
required more horsepower for compilation than was available. Or you think
everyone's got a today's super computer. Either way this your assertion is
very doubtful.

Alex


 
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




Advertisments