Re: Solving the config.h nightmare ?

[Daniel Reed]

On Sun, 23 Apr 2006, Bob Friesenhahn wrote:
> Agreed.  The other issue is that with an abstracted interface, performance 
> can really suck.

Abstraction needn't necessarily have any impact on performance at all. You 
may be able to get by with something as simple as using a forwarded-only 
struct pointer in your API that is simply typedefined to be some 
build-environment-dependent type internally.


nscreen.h:
struct nscreen_window_t;

struct nscreen_window_t *nscreen_create_window(void);
int     nscreen_window_width(struct nscreen_window_t *win);


nscreen.c:
#if defined(USE_NCURSES)
# include <ncurses.h>

typedef WINDOW nscreen_window_t;

#elif defined(USE_GLX)
# include <GL/glx.h>

typedef Window nscreen_window_t;

#else

typedef struct nscreen_window_t {
        uint32_t framebuffer[1024][768];
        int     x, y;
} nscreen_window_t;

#endif


0 API change or ABI breakage if you build a client (that has only seen 
nscreen.h) against a libnscreen compiled to use ncurses and later run it 
against a libnscreen compiled to use GLX or simulate having a screen 
internally.

--
Daniel Reed <address@hidden>      http://shell.n.ml.org/n/        
http://naim.n.ml.org/
There go my people. I must find out where they are going so I can lead
them. -- Alexandre Ledru-Rollin