Re: glib.h: defining functions in header file

[Scott Michel <scottm CS UCLA EDU>]

> On Tue, 29 Jun 1999, Scott Michel wrote:
> > Arguably, including glib.h and glibconfig.h without expecting to
> > link glib is a bad programming practice, since they make internal
> > calls to glib anyway.  :-)
> 
> Which is exactly what I am complaining about. I suggest that header files
> should not make calls to functions; they should declare functions and
> preprocessor macros. Perhaps I am mistaken, but I believe that declaring a
> function or pre-processor macro is not considered "calling" a function.

Actually, you kinda missed the point (but then again, I should have
articulated it better): Would you still use those header files if
the macros were really externs?

Like the previous message said, copy the macros you like but don't
include the header file.

> I guess the situation that would be ideal for my case would be to have the
> macros (basically everything covered under "GLib Fundamentals" in the
> reference manual) defined in a separate header file. So projects which
> just wanted to use glib's portability and convenience macros could include
> only this header file.

By using Glib, you've bought into a framework. Now you're saying
that you wish the framework was slightly different so that it could
be used outside the original framework. Sounds like the beginning
of a holy war...

Perhaps the functions you want to use could be better modularized
so that you might be able to link with fewer dependent libs, but
the functions and macros rely on the Glib headers and library. There's
no way to get around that, per se, other than abandoning Glib as
your app's framework.


-scooter
-- 
Scott Michel                        | No research ideal ever survives
UCLA Computer Science		    | contact with implementation.
PhD Graduate Student                |