begin quoting Andrew Lentvorski as of Thu, Dec 13, 2007 at 09:00:57AM -0800:
> Bob La Quey wrote:
> >Do you have some suggestions for "solving the underlying problem of
> >portability."?
> >
> >BobLQ "Does not seem easy to me."
>
> Nobody said it was easy. However, there are quite a few things.
>
> First, you structure your code such that changing API calls are isolated
> in specific files. Generally through a wrapper layer of your own. Most
Yes.
> C programming *should* be wrapped anyway because it is littered with:
>
> retval = APICall(????);
> if (retval == -1) {
> /* Do error checking */
Presumably, that's /* Do error handling */
> }
>
> and that should be wrapped rather than rewritten every single time.
In C, you can't really get to far away from that... you're pretty much
stuck with the <variable> = <api_call>(<arguments>); <errorcheck/handle>
approach. (Unless C99 introduced exceptions... I should get a good C99
book one of these days.)
What you /can/ do is to replace
#ifdef SYSTEM1
retval = APICall( arg );
#endif
#ifdef SYSTEM2
retval = API_Call( arg );
#endif
#ifdef SYSTEM3
retval = api_call( arg.datum, 0, -1 );
#endif
#ifndef SYSTEM3
if ( retval == -1 ) {
#endif
#ifdef SYSTEM3
if ( retval == ERROR_CODE ) {
#endif
/* Do Error Handling */
}
with
retval = my_APICall( arg );
if ( got_error( retval ) ) {
/* Do Error Handling */
}
> Second, if portability is a requirement, this is one of the few
> instances when you need to ask whether it is actually better to write
> your own code for small API routines rather than use the native API
> calls. Especially if you are using both Windows and Unix where the
> library API calls can differ significantly.
This also is a place where one can avoid dependency hell. Do you need
just two "generic" data structures and three functions from $library
(out of fifteen data structures and seventy functions, say)?
> Third, one should be testing for major subsystems rather than tiny API
> functions. Testing for gtk version X.Y is okay. Testing for the file
> <strings.h> for one specific call (strcpy()) is silly. Write that call
> into my_strcpy() and test for Windows, Linux, FreeBSD.
This depends on the fragility of the library, and requires that the
library writers maintain compatibility across versions and releases.
If you're unfortunate enough to be using a library that changes the
API (other than adding new functionality or fixing bugs) every minor
release, you can't get away with testing just the major subsystems.
> Fourth, using *anything* other than configure. The fact that nobody
> regenerates configure scripts from scratch combined with stealing some
> other project's and tacking on a couple of tests is proof that it is far
> too opaque and heavyweight.
There are a few folks who (re)generate configure scripts from scratch,
but I think they're few and far between.
--
I've seen configure scripts for Java programs, go figure.
Stewart Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
