Boost logo

Boost :

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-25 01:49:52

> > > I agree. You point out two major failing of most C++ frameworks: lack of
> > > modern C++ use and lack of exception safety. I see the rest of this thread
> > > talking a lot about C++ techniques, but there seems to be one major
> > > component that everyone is overlooking: producing a good user experience.
> > >
> > > Perhaps as a Mac developer I am more aware to the importance of a good user
> > > experience; one of the major failings of every cross-platform C++ framework
> > > on Mac OS is a poor user experience -- usually due to reinventing
> > > OS-provided UI wheels, and thus often making the UI subtly inconsistent
> > > with the rest of the OS. This kind of subtle (or less subtle) inconsistency
> > > is what makes users (entirely justifiably) bitch and moan and shoddy ports,
> > > and give bad product reviews.
> >
> > umm... which part of "cross-platform" and "use native functionality" is more
> > important?
> You are falsely presenting them as mutually exclusive choices.
> > If you have some functionality provided by one OS, while another doesn't
> > provide it... what do you do?
> That case is actually almost completely irrelevant to my point. My point has to
> do with "reinventing OS-provided wheels", which is completely different from
> providing additional functionality on a particular OS.

case in point:

FreeBSD doesn't provide the "lround()" C99 function - yet Linux does.

If I need to round a double to a long, what function do I call that will be portable?

The only real choice I have is to re-implement the lround() function so that at minimum, it gets enabled on FreeBSD.

Given that I have had to implement a non-OS based version of a function, I then ask myself, "Why bother #ifdef'ing around the custom function - why dont I just use the one that I am providing?"

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?

In fact, Boost already does this - at configure/compile time bjam detects the available platform functionality - any missing bits are often provided by supplemental code.

Yes I am presenting them as mutually exclusive - and I do realise that the world shouldn't be that way - but in reality, it is.


Boost list run by bdawes at, gregod at, cpdaniel at, john at