Re: Solving the config.h nightmare ?

[Bob Friesenhahn]

On Sun, 23 Apr 2006, Daniel Reed wrote:

> > Your example seems to assume that the client app will not be manipulating 
> > 'framebuffer directly'.
>
> That can be done through an API call, to do whatever is necessary to get the 
> buffer from the ncurses WINDOW, GLX Window, or the dummy .framebuffer.

Gaining access to a buffer is not hard.  Updating the buffer reliably 
is more difficult.

> > If it does (for performance reasons), then it needs to know that 
> > framebuffer is an array of uint32_t with a particular size.
>
> Is your issue that the buffer might be a uint32_t array sometimes and 
> something else other times, and that needs to be communicated, or that the 
> API uses the type uint32_t but that type (under that name) isn't guaranteed 
> to always be usable?

The former.

> When is the format for the buffer set, at GraphicsMagick ship time, 
> GraphicsMagick build time, dependent program ship time, dependent program 
> build time, or dependent program run time?

In this case, at GraphicsMagick build time.  Certainly the design can 
be improved, but my point was that sometimes it is useful for the 
dependent application to share access with the library to a data with 
a pre-arranged format.  Other design approaches add abstraction, but 
they usually add a bit of run-time overhead as well.  Some 
configuration options do need to be remembered by the installed header 
files.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/