Re: [cc65] Library headers

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-05-30 22:08:47


Hi!

On Thu, May 30, 2002 at 09:13:09AM -0700, Shawn Jefferson wrote:
> When designing a library for cc65 is it better to have one big header file,
> or split them into several smaller header files, or does it not matter to the
> final size of your executable?

Since a header file does usually not contain any code or data, the size of the
header file has no relation to the size of the executable.

The size of the .c files is a different matter, especially in combination with
libraries: If there is at least one reference into an object file, the linker
will add this object file to the exutable. So if your library contains several
functions that do not depend on each other, it is better to place these
functions in separate .c files. Here is an example:

Say you have two functions, a() and b() which do not call each other, but both
access a data array named c[]. It is possible for a user of the library to
call a() but not b() and vice versa.

If you place a(), b() and c[] into one .c file, a program that calls a() but
not b() will nevertheless contain the complete code of b(), because the linker
will not divide the object file - either it gets linked in, or not.

A smarter solution would be to place a() and b() into two .c files. However,
since both use common data (c[]), you have a problem: If you place c[]
together with a() into one file, a program just calling b() will get both
object files linked in, because b() uses c[], which is in the same file as
a(). The solution is of course to use three files: One that contains a(), one
that contains b(), and a third one that contains the shared data c[].

The example shows another problem when designing a library: Because a() and
b() share c[], but c[] is in a separate file, the external identifier "c" is
visible to any program using the library. So if you use a common name (like
"c"), there is a high probability that this identifier will clash with an
external identifier in the user program having the same name. There are
languages that are able to resolve name collisions like this (C++ has a
feature called "name spaces" for example), but in C it is up to the library
designer and individual programmer to handle this problem. A common approach
is to use a short prefix for each name exported from the library.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2002-05-30 22:08:57 CEST