Is anybody working on a high level standard library for C++

Question

STL/Boost cover all the low level stuff.

But what about the higer level concepts?

Windows: We have multiple windowing libs

• KDE(Qt)
• Gnome
• Motif(C but written in OO style)
• MS Windows
• etc

But is anybody working on a unified standard for windowing? Somthing that wrapped all the above would be acceptable. (even if it only accessed the common stuff it would be a starting point).

Networking:
There are a couple out ther (including the Boost low level stuff).
But is there anybody working on a Service based network layer?

All the other stuff that Java/C# have in their standard libraries.
The stuff that makes it simpler for a beginner to jump in and say Wow done and it works everywhere (nearly).

Anyway. Here hoping there are some cool projecs out there.

Edit

Maybe there is not one. But if there are a couple that could be bundled together as a starting point (and potentially modified over time (where is that depricated keyword)) into a nice consolidated whole.

Note: Windows is just a small part of what I am looking for. The Java/C# languages cosolodate a lot more under the hood than just the GUI. What would be a good set of libraries to get all the functionality in one place.

Answer 1

For cross platform windowing, there's wxWidgets. (formerly wxWindows).

Answer 2

There are too big differences between platforms to get a definitive C++ standard for GUI programming. I think Qt is about as close as you will get in the forseeable future. wxWidgets is another popular choise, but as I understand it, they are using less modern c++ features.

As for networking, I think you are being kind of vague. If you mean web services over HTTP, I would have a look at Pion.

Answer 3

Qt might be the only framework complete enough to be what you suggest.

Answer 4

I don't think it is achievable to make a really comprehensive portable GUI library. Operating systems are just too different. Can you imagine a GUI library that would cover everything from iPhone to Windows 7 and wouldn't feel wierd on any of them?

Answer 5

A Boost gui library comes up occasionally.
The general opinion seems to be that the problems is too wide (are you targeting cellphones, FPS games or CAD workstations) and that it is too much work - Qt/wxWidgets has taken 10years.

see http://lists.boost.org/Archives/boost/2005/09/94453.php for a discussion.

It would have been nice because GUI usually means cross platform and threads, so all the GUI toolkits have invented their own cross platform,filesystem and thread classes. On the other hand if a standard GUI had been introduced in C++ it would probably look like TK !

Answer 6

Well it is almost 2010 and C++ almost has threads.

I'll probably get slammed for this but C++ moves too slow - to its own detriment and its user base. I readily acknowledge the difficulty of the technical and political issues involved but that's still the dirty reality of it. The language can't build in higher level concepts when it takes 5-10 years to agree on and implement the building blocks.

The reasons for this have endlessly debated but the sad truth is that C++ has relegated itself to a niche language. I like C++ but I look at the progress C#, Java, and even Python and Ruby have made over the last 5 years and I increasingly question whether C++ is worth the effort.

Answer 7

I guess there's some kind of keyword lookup driving the advertising here because I'm seeing a REALbasic ad, which is what I generally use for cross-platform GUI's nowadays.

I have spent a lot of time over the last 15 years working in C++ GUI's including retailing my own portability layer for CodeWarrior PowerPlant and working on the two Macintosh-based GUI code generators, including adding Windows generation to AppMaker. I've worked with wxWidgets, mainly wxPython. So, my opinion on difficulties in cross-platform GUI is fairly well-qualified :-)

Cross-platform GUI frameworks are hard to the point of nearly impossible without significant compromise - the issues come down to subtle matters of behavior which generally bother users at a level where some of them can't quantify but know that the application doesn't feel right. This is a lot harder to fix than just rendering native controls.

I started using REALbasic because their framework does a better job of getting the feel right than anything else I'd tried (I didn't get into Qt because of the expensive commercial license).

The reason it has taken so long for things to evolve is nothing to do with the C++ world moving slowly, it's just an intractable problem. The very best cross-platform Java apps do some stuff conditionally for OS/X and it is still screamingly obvious to an experienced user that they are not a native Mac app, although some are very usable and come pretty close to looking native - Oxygen XML editor and DeltaWalker are two of my favourites.

Answer 8

ACE is great for concurrent communication and networking.

Answer 9

The Poco C++ project aims to deliver all that you ask, except for Windowing:

The POCO C++ Libraries aim to be for network-centric, cross-platform C++ software development what Apple's Cocoa is for Mac development, or Ruby on Rails is for Web development — a powerful, yet easy to use platform to build your applications upon.

Answer 10

Only everybody and his brother, but hardly any of them actually get anywhere.

Answer 11

What's so great about standardization ? Sure, if novice coders want to download one SDK to build portable apps, let them download Qt (or something similar) and forever remain within it's fine walled environment. But it'd be a tragedy if the C++ world revolved around that one library and boost and POCO and wxWidgets and clutter and blitz++ and eigen and and 101 other wonderful things (yes, gtkmm and ACE even) were stifled at birth because the gatekeepers of The Standard Library didn't see fit to admit them.

Diversity is good I think (although when dealing with it, it helps to have a good package manager; I've spent hours setting up build dependencies on Windows which just needed a few seconds of apt-getting on Debian).