Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Modularisation

Reply
Thread Tools

Modularisation

 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-05-2005
"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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?


How would you share an inline function between 2 .c files? Except by having
2 copies of it, only through an .h file. Just like a common macros.

Alex


 
Reply With Quote
 
 
 
 
August Karlstrom
Guest
Posts: n/a
 
      10-05-2005
Eric Sosman wrote:
> August Karlstrom wrote:
>> 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.


Yes, you are right (and I was wrong). However, this is an example of an
irregularity in C -- of the declarations

struct s { int m; };
int n;
void f(void);

`struct s' has file scope, but n and f has global scope (require `static').


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


August Karlstrom wrote On 10/05/05 11:44,:
> Eric Sosman wrote:
>
>>August Karlstrom wrote:
>>
>>>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.

>
>
> Yes, you are right (and I was wrong). However, this is an example of an
> irregularity in C -- of the declarations
>
> struct s { int m; };
> int n;
> void f(void);
>
> `struct s' has file scope, but n and f has global scope (require `static').


Right. Or more precisely, n and f have file scope
but external linkage. Other modules (sorry, "translation
units") can refer to them, but only by re-declaring them;
n and f are not automatically in scope for other modules.

Ever since I first encountered C in the mid-1970's
I've felt that the language took the wrong default for
"undecorated" declarations at file scope. That is, I
think it would have been better if n and f were "implicitly
static" (in today's terms) and that an identifier would have
external linkage only if declared with a keyword like `public'
or `export'. Obviously, dmr did not feel that way -- and
it's not really a huge problem; I just reflexively put
`static' on nearly everything. The habit is so strong that
even when I'm writing tiny little one-file programs the
only externally-linked identifier I declare is main().

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

 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-05-2005

"August Karlstrom" <(E-Mail Removed)> wrote in message
news:4xS0f.35332$(E-Mail Removed)...
> Eric Sosman wrote:
>> August Karlstrom wrote:
>>> 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.

>
> Yes, you are right (and I was wrong). However, this is an example of an
> irregularity in C -- of the declarations
>
> struct s { int m; };
> int n;
> void f(void);
>
> `struct s' has file scope, but n and f has global scope (require
> `static').


I think you need to sort out in your mind the difference between
scope and linkage.

-Mike


 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      10-05-2005
Alexei A. Frounze wrote:
> "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?


Functions that are "exposed to the outer world" (external linkage) have
to be defined somewhere. They're declared in the headers, but they are
generally defined in .c files.

>
> > <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.


Like it or not, this behavior is common for a variety of reasons. If
you're building a library, then nearly all the code looks "unused" from
the linker's point of view.

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

>
> I don't know what you mean.


The semantics of linking against static libraries and object files
differ. Generally speaking, linkers pick and choose from libraries but
include the whole of object files (unless instructed not to). Since
this is very platform-specific (and OT), I'll leave it at that.

<snip>
>
> > > 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.


Files are often linked more than once. This is commonly known as
partial (or relocatable) linking. Mutually referential libraries need
to be repeatedly linked until there are no further unresolved symbols.
That's why your statment "each library and object file is linked only
once" is incorrect.

Understand that in most cases on non-embedded platforms, there will be
_no_ instances of library code in the executable. There will just be
an undefined symbol that is patched up by the dynamic linker/loader at
run time. To use your example, there would be no instances of fread()
in _any_ executable, one instance of fread() in a shared library, and
all executables use the same instance.

Once again, this is OT, so I will stop there.

<snip>
>
> > > 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.


I regularly deal with the internals of compiling and linking
multi-million line codebases, often distributed across farms of
multi-processor machines. Compilation time of large vs. small C files
do not typically differ by more than a second on any post-Pentium III
machine.


Mark F. Haigh
(E-Mail Removed)

 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-06-2005
"Mark F. Haigh" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Alexei A. Frounze wrote:
> > "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?

>
> Functions that are "exposed to the outer world" (external linkage) have
> to be defined somewhere. They're declared in the headers, but they are
> generally defined in .c files.


I don't see where this your statement contradicts mine. I might misused some
word (define vs declare or whatever -- forgive my bad English), but that's
what I meant. But I explicitly wrote "externs" in the list below .h -- see
my previous post.

???

> > > > 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.

>
> Like it or not, this behavior is common for a variety of reasons. If
> you're building a library, then nearly all the code looks "unused" from
> the linker's point of view.


The original poster asked about "modularization of C programs" meaning that
he's making programs, not libraries. Unless you extend programs to cover
libraries too, this is irrelevant. But I do acknowledge your ... let's look
up the dictionary ... punctiliousness. Or pedantry. Pick whichever you like
better

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

> >
> > I don't know what you mean.

>
> The semantics of linking against static libraries and object files
> differ. Generally speaking, linkers pick and choose from libraries but
> include the whole of object files (unless instructed not to). Since
> this is very platform-specific (and OT), I'll leave it at that.


What do you mean by "the whole of object files"? Do you mean *all* files or
whole files (e.g. a file in whole/entire file)? And unless that particular
linker treats a library as something more special that the collection of the
object files it consists of (for what reason would it?), there is no
difference.

> > > > 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.

>
> Files are often linked more than once. This is commonly known as
> partial (or relocatable) linking. Mutually referential libraries need
> to be repeatedly linked until there are no further unresolved symbols.


Right.

> That's why your statment "each library and object file is linked only
> once" is incorrect.


So, with all your pedantry, can you forgive me my English?

> Understand that in most cases on non-embedded platforms, there will be
> _no_ instances of library code in the executable. There will just be
> an undefined symbol that is patched up by the dynamic linker/loader at
> run time. To use your example, there would be no instances of fread()
> in _any_ executable, one instance of fread() in a shared library, and
> all executables use the same instance.


That is all correct.

> Once again, this is OT, so I will stop there.


I've already suggested not covering the DLLs as there was no inquiry to.
And I've just suggested not making the term library subset of the term
program. To lawyers these would probably the same thing, to us there's a
difference.

> > > > 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.

>
> I regularly deal with the internals of compiling and linking
> multi-million line codebases, often distributed across farms of
> multi-processor machines. Compilation time of large vs. small C files
> do not typically differ by more than a second on any post-Pentium III
> machine.


Then I may only tell you that you're a lucky guy to have all that now and as
maybe all the time before.

Since I'm seeing not much of a disagreement between us, just you being
pedantic, maybe we shall finish this thread right here? I guess the original
poster is already satisfied with the details.

Alex


 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      10-06-2005
Alexei A. Frounze wrote:
> "Mark F. Haigh" <(E-Mail Removed)> wrote in message
> > Alexei A. Frounze wrote:
> > > "Mark F. Haigh" <(E-Mail Removed)> wrote in message
> > > > 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?

> >
> > Functions that are "exposed to the outer world" (external linkage) have
> > to be defined somewhere. They're declared in the headers, but they are
> > generally defined in .c files.

>
> I don't see where this your statement contradicts mine. I might misused some
> word (define vs declare or whatever -- forgive my bad English), but that's
> what I meant. But I explicitly wrote "externs" in the list below .h -- see
> my previous post.
>


"Declaration" and "definition" have precise meanings in C. If you
don't understand the difference, look it up.

> ???
>
> > > > > 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.

> >
> > Like it or not, this behavior is common for a variety of reasons. If
> > you're building a library, then nearly all the code looks "unused" from
> > the linker's point of view.

>
> The original poster asked about "modularization of C programs" meaning that
> he's making programs, not libraries. Unless you extend programs to cover
> libraries too, this is irrelevant. But I do acknowledge your ... let's look
> up the dictionary ... punctiliousness. Or pedantry. Pick whichever you like
> better


Hmmm. You post incorrect information with a false air of authority,
then whine "pedantry!" when corrected. While you have the dictionary
open, look up the word "wanker", as you're starting to become one.


>
> > > > or the group of object files are made into a static archive
> > > > before linking.
> > >
> > > I don't know what you mean.

> >
> > The semantics of linking against static libraries and object files
> > differ. Generally speaking, linkers pick and choose from libraries but
> > include the whole of object files (unless instructed not to). Since
> > this is very platform-specific (and OT), I'll leave it at that.

>
> What do you mean by "the whole of object files"? Do you mean *all* files or
> whole files (e.g. a file in whole/entire file)? And unless that particular
> linker treats a library as something more special that the collection of the
> object files it consists of (for what reason would it?), there is no
> difference.


Static libraries _are_ different than the collection of object files it
consists of. If you link against a static library, you will not link
in unused object files. If you link against an object file, you will
include everything, whether it's used or not.

<remainder snipped>


Mark F. Haigh
(E-Mail Removed)

 
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