On Mon, 19 Nov 2001, Dan Sugalski wrote:
> At 03:17 PM 11/16/2001 -0500, Andy Dougherty wrote:
> >I like the idea of splitting out some things (such as dynaloading) into
> >separate directories, instead of a single monolithic platform.c file.
> >Whether *every* non-portable function needs its own directory is a
> >different question. I suspect not, but it's clearly a matter of taste and
> >balance just where to draw the line.
>
> That's a good point. The big things (async I/O, dynaloading, and subprocess
> creation and communication come to mind as biggies) can be taken as
> separate things rather than treating platforms separately.
>
> We'd end up with a mix of per-platform and per-style code, though, so I'm
> not sure if it'd be a win.
At least for the Unix-like systems, I think it will be. For example,
HP/UX is like most other Unix systems (e.g. sleep, gettimeofday, SysV IPC,
sockets, etc.) but has a different dynamic loading scheme. For less Unixy
systems, it's less obvious, but I think it will still be a win.
However, let's continue to try to think of these files as "feature" files,
not "platform" files. Thus, it's not whether you're on Linux or OpenBSD
or Solaris or Cygwin that matters, it's whether you have a gettimeofday()
function.
Even for dynaloading, it's still a feature file. It's just that the
natural names for the features may include a platform name, e.g.
"dlopen()-style" or "HP/UX-style" or "AIX-style" dynamic loading.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
