Re: [boost] Re: Java style GUI in C++

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.

Mathew