Jeff Garland wrote:
Andy Little wrote:
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it.
Actually I believe the issue is that nobody has proposed a GUI library -- Bjarne has written many times about the desire to see a GUI library. But, its not really a surprise when you consider the huge amount of effort needed to do the design and development of such a proposal -- just to give it away. From the academic side, there isn't much incentive to try and create a C++ GUI library.
Honestly, I like to look at this the other way around. C++ is the only language that has multiple cross-platform GUI libraries -- it's bad for training and consistency, but you're not confined to what a single commercial entity provides.
I tend to agree. As we have discussed in another thread about GUI work, there are really two orthogonal parts to this: 1) Develop a new GUI architecture, based on past experience. 2) Provide a set of C++ APIs that can map (at compile- or run-time) to different backends. Most people who think about developing a GUI API for C++ in the context of boost seem to either think in terms of 1), or at least want to promote very specific programming idioms, which restrict the choice of possible GUI backends. While I have done my own share of 1), I think for boost it would be more appropriate to focus on 2). Still, it isn't clear that this is possible at all, at least in general. As an exercise, take the major GUI libraries that exist across all platforms and try to provide uniform wrappers for them without 1) restricting yourself to the least common denominator and 2) loosing performance due to late binding and many levels of indirection. Regards, Stefan