From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-29 18:22:40
> > > > Getting back to what was origonally said - if one platform
> > > > implements something that another platform doesn't, how can a
> > > > cross platform library not re-invent the the wheel for that
> > > > crummy platform?
> > >
> > > That's not reinventing the wheel for that "crummy platform," it's
> > > implementing it. What's reinvention is ignoring the existing
> > > implementation on the other platforms.
> > I do agree mostly, except that Boost is meant to be
> > cross-platform, which means shipping the Boost source code with
> > the platform abstraction layer.
> > And shipping the resultant library to conatin that code as well
> > - think win32 running on win98 vs win32 running on win2k.
> The extra code would be part of the sources, sure, but it only
> needs to be compiled into the executable when needed.
> > There would need to be runtime detection of the available
> > functionaly (for only some functions - but the problem does
> > exist).
> Runtime? Surely we can get the required information as to the
> available feature set from a compile-time version number, can't
> we? In the worst case, I could imagine a discovery tool run by
> Boost Build that computes the available feature set and generates
> a configuration header that the rest of the library relies upon.
Not on win32 - actually you are correct that you _could do that_. However, your executable would then not be portable between various flavours of win32 - which in itself is no different from most Unix's - but is not really want you want to do for win32.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk