I think it is better if I explain the situation so this doesn't seem too arcane a question. I want to release some starter code for a project I want some of my students to work on. The project involves scraping through some internet webpages and as such, I want to provide them with a URLStream class that will download the html of an input url and return it as a string to them.
The issue is that I can't seem to find a particularly nice way to deal with networking in a way that will be cross platform (the students have mac/windows/linux machines). I know of libraries like Boost asio and libCurl, but the issue with using these is that I can't enforce all my students download them. So my question is twofold:
Is there any nice way to provide them this cross platform networking code?
If a library is the only way to do this, is there any way to attach the library to the starter project so that students don't have to download it? I know this might be a stupid question but I can't seem to find out if this is possible.
Boost.Asio is really not suitable for your needs as it involves huge Boost and building at least some of its non-header-only libs. You can still consider Asio lib that can be used w/o Boost and is header-only lib, so much less hassle for you and your students. As it's probably the most popular and modern networking C++ lib this exercise can provide some useful experience to the students. Asio examples also have a simple HTTP client.
As a side note, are you bound to C++ for this assignment? It would be much simpler in Python or similar languages that provide networking out of the box.
The Berkeley sockets API is the most common low-level socket API. It is supported on all POSIX platforms which means both Linux and macOS will have it.
Even Windows have it, but with a slight twist since sockets aren't descriptors like they are on POSIX systems.
Using sockets directly will lead to more boiler-plate code, but it is definitely possible to use it to make a simple HTTP client that supports only simple GET requests.
There are many tutorials and references on using sockets. Beej's Guide to Network Programming seems to be a popular tutorial, which should have notes about the tweaks needed for Windows.
cross-platform C++ library for network programming
asio is a cross-platform C++ library for network programming that provides
developers with a consistent asynchronous I/O model using a modern C++
approach. It has recently been accepted into Boost.
I copied that from the info window in Synaptic. If you're using Linux, install the library (and its documentation) thus:
sudo apt-get install libasio-dev libasio-doc
I am looking to write a server application in C++ that is meant to handle tens of thousands of clients simultaneously. It should run under Windows and Linux. I have been looking around for frameworks and libraries and have come across Boost Asio, which seems like a highly mature and widely used alternative. I just have trouble wrapping my head around strands/thread pools, mainly because of the millions of templates. My background is mainly in C, so am not really used to the template mess that Boost in general seems to be full of. I tried to find someone to develop a relatively thin wrapper around Boost Asio that would take care of the threading/synchronization aspect using strands, bind and the like, but have been unable to find someone yet who can do it within my budget (2 or 300 US dollars).
Can any of you recommend any other libraries that scale as well as Boost Asio (e.g. with IOCP on Windows and epoll on Linux etc), or a source where I might find skilled Boost developers looking for smaller freelance jobs?
Thanks very much in advance for any help.
Kind regards,
Philip Bennefall
Best 4 choices i know
I really like zeromq.. but libuv seems interesting.. (libev and libevent are very nice too)
zeromq
libevent (as said)
libev
libuv (Its purpose is to abstract
IOCP on windows and libev on Unix systems and it is node.js network layer)
ACE is the framework you are looking for. Even boost Asio is just an implementation of Proactor pattern, which was introduced by Douglas C. Schmidt. He is best known as the author of POSA Vol.2 and the creator of ACE framework.
The Boost.Asio library offers side-by-side support for synchronous
and asynchronous operations ... based on the Proactor design pattern
[POSA2].
Although it is a cross-platform C++ network framework and uses template,
just simple template is used. (or not at all)
My background is mainly in C, too, and I don't like Boost's massive template-programming style. However, ACE wasn't like that.
Try libevent on for size. Its whole raison d'etre is to address the C10K problem. I'd say it's probably more lightweight than boost.
Try Pulsar Server Framework. Main benefit is it is built over libuv network library (used by node.js) that uses asynchronous I/O based on event loops.
It’s perfectly scalable. You can just go adding servers as your user base increases.
It is designed to work with server farm.
Highly configurable and easy to use
Currently it has been built for Windows x64 server.
I wonder what library would ease the development of a cross-platform service/daemon ? (C/C++)
I'm targeting: Windows, Linux and OS X.
Requirements: network operations and serial port communication.
Also it would be nice to have a basic sample service application.
When it comes to Qt you might try qt-service.
A daemon in Linux is really just a process that runs disconnected from a terminal. In Windows, a service is something that can be controlled using the service management API, but once again is basically just a disconnected process. The disconnection aside, daemons & servers don't have much in common, from task to task. There is no requirement, for example, that they be multi-threaded, be asynchronous or perform network I/O. Given that, it's kind of hard to see what a cross-platform library would do.
You should take a look POCO. Depending on what you are doing it could have facilities to do a large amount of the work for you with a lot less work than Boost.
An obligatory mention for ACE though I don't personally care for it much.
Boost probably has most of what you need in terms of threading and networking I/O.
You may also find Qt a good alternative. It also has threading and networking libraries and has a much easier to use & understand event-driven programming model using a run loop. Qt's signal/slot system is very easy to use and ideal for a network daemon/service (Boost also includes a signal/slot system but it is harder to use and does not include an event loop; you have to roll your own using some event library). As a cross-platform library, Qt can handle many of the issues in bridging the Unix (OS X and Linux) vs. Windows mental model for processes, filesystems, etc.
For unit testing, I've been very happy with Google's C++ unit testing library called googletest (though both Boost and Qt also have built-in unit testing systems). It runs on all the platforms you specify. I've done a lot of work with googletest on cross-platform Qt projects and found it quite satisfactory.
I've found a big library in the non-boost version of ASIO. You don't need all boost library but only this little headers-only and very well documented library http://think-async.com/
As examples, a daytime server-client system is implemented in very few lines of code.
Take a look at it.
(remember to look at the non boost-ized version)
I have a large cross-platform (Linux and Windows) C++ project, for which I want to create a GUI.
I have few very general questions about the basic principles of GUI for such project:
Should the GUI be separated from the application's logic?
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
Is it a good idea to have a browser-based GUI?
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Should the GUI be separated from the application's logic?
Yes, definitely....
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
...but not that much. Sockets would be overkill (exception: see question 5). Usually you split up the classes in GUI and backend parts. The GUI classes then call methods of the backend.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
If so, you would have to integrate the two languages, so I would recommend writing everything in the same language. But to answer your question, you could for example create Python bindings for your backend and write the GUI in Python (with PyGTK, PyQT or wxWidgets).
Is it a good idea to have a browser-based GUI?
That depends on how you want to deploy your application. If it should be installed on each client computer, a web interface doesn't make sense. If you want to host it centrally, then you might opt for a web interface.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
I think this makes sense only if the backend must be some kind of secure (i.e. must not be installed on users' computers) or if you have a thin client-like approach as in question 4. Writing cross-platform GUIs is much easier than writing cross-platform backends (in my opinion), so you should rather do both parts cross-platform. By the way, .NET-based GUIs are not Windows-only - Mono already supports a great subset of Windows Forms, for example (but not WPF, sadly).
EDIT:
Concerning your Mono question: Mono is mostly stable, but not everything is yet implemented. To be sure, you can run The Mono Migration Analyzer (MoMA) to find out if something will not work in Mono. But I think the fact that so many companies are successfully using Mono in production environments means that you should at least consider Mono as an option!
Should the GUI be separated from the application's logic?
It should, because the UI widgets are just types of objects and one of the rules of OO says that each
object should be trusted with the responsabilities that it can fulfill. A dialog doesn't know much about
serialization for example.
If it is separated, how should the logic and the GUI communicate? Are
TCP/IP sockets a good option? What are
other possibilities?
It depends on how much separation you need. I use asynchronous messages for communication, and then I can use
different transport layers without many changes.
TCP/IP would allow you to use the GUI on a separate machine from the core, but it has higher overhead than
passing around window messages for example.
Is it a good idea to have the GUI in a
language different than a C++? If yes
- which language?
Ideally, you should use as few languages as possible unless you really need the technical capabilities of a
certain language. GUIs are more of a library problem than a language problem, so if you can find a very good
C++ UI library (hint: Qt), you should code all your program in C++.
Is it a good idea to have a
browser-based GUI?
It could be, but you should think about requirements and not ideas. Do your customers want to interact with
your program from a browser? Can they afford the extra costs and development time? Do you have the know-how?
Even though the project's core logic
is cross-platform, I can decide that
the GUI will be only Windows-based
(.NET?) and it will communicate with
the logic on the relevant Win/Linux
machine through Socket or similar
method. Is it a good idea to do so?
It could be a good idea, but see the answer to #3. Also consider that you're going to work on a client-server program, which is significantly more complicated than a stand-alone program.
Finally, you need to examine the pros and cons of a .NET dependency over using a C++ UI library: what .NET brings you that you couldn't get with wxWdigets, Qt, gtkmm, etc.
(1) Usually yes, this makes it possible to maintain the business logic and the user interface separately. It also enables you later to have e.g. both a browser-based SaaS user interface as well as a desktop-style local networkless operation mode and still share the whole application logic code.
(2) Not using TCP/IP sockets. Typically the application and the GUI would communicate using event and/or message passing. For example, when the application wants to notify the GUI that something happens, it creates a synthetic event that is then pushed to the event queue of the GUI. If the application is event-based also, the GUI can communicate with it by posting events. For non-blocking, quick operations the GUI can call the application logic code directly, but then the call must be guaranteed to return quickly. For slower operations, you need a separate thread anyway to process them. This thread can be the one that processes the application-side events, or you can spawn it as a worker thread when needed.
Our company's product has a user interface on top of Eclipse IDE, but part of the application logic is written in C++. The two parts communicate over CORBA, i.e. basically asynchronous event mechanism. We have been happy with this solution.
On a smaller scale, GUI applications typically separate UI and application logic using abstractions such as Model-View-Controller (MVC).
(3) It's always a hassle to integrate components written in two different components. I think you should to that only if you have an obvious platform benefit. E.g. we benefit from the Eclipse IDE components, whereas the application benefits from the raw speed of C++.
(4) Browser-based GUIs are great, but the integration with the business logic suffers from latency and the stateless mode of web servers makes the architecture cumbersome if you actually have a desktop-style application. A browser-based GUI is good for software-as-a-service applications because they don't require installation by the user and can be upgraded by the product developer at will, but if you don't plan to offer your product as a software-as-a-service product (a la e.g. Salesforce).
(5) If your application logic is cross-platform, I would try to strive to make the UI cross-platform also. Otherwise for those platforms where you only support the application logic you may need to install two operating systems, one to run the UI and one to run the application logic. There are good cross-platform user interface frameworks, at least
AJAX / browser-based UI
Trolltech/Nokia Qt
Eclipse (SWT)
Java Swing (hmm...)
it is better to use python as your base gui language with QT as gui platform.
if you split gui and base program in separate processes then you can use this mechanisms for communication:
signals and slots from Qt
subprocess module at python
local sockets.
use files [write configs to file and signal other process to refresh]
but it is better to create one process and call your base language directly from python and communicate with native language's data structures. you cat use swig for this purpose. but because you can't call python functions from within C++ you can use pooling at python for some changes in shared data and do something based on this changes. i experienced two way. when i used python for GUI and management, it can be very time saving.
1. Should the GUI be separated from the application's logic?
Yes. However, see answer #2
2. If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
I believe this is a best answered by choosing a GUI framework, MFC, .NET, wxWidgets, Qt, ….
The framework you choose will look after both the separation and the communication for you, as painlessly as possible.
Do not try to re-invent the wheel. The framework designers have put way more thought and testing into their implementations that you could ever afford to do.
Note that question #1 suggests that you are asking about separating the logic in a single application. However, later questions suggest you may be thinking of two separate applications, perhaps even running on separate machines.
I consider that having the GUI in a completely separate application will always result in something that will be slow and inflexible. However, if you do not care about speed and flexibility, and particularly if you already have the core application running with a simple console type interface, then this might be the best way to go.
3. Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
No.
If you are a single-person programming team, then you will be spreading yourself too thin trying to master two languages. If you are a multi-person team, why compound communication problems by setting up two different cultures?
4. Is it a good idea to have a browser-based GUI?
Not if you can avoid it. If you need a browser based GUI, then you will know it. If you do not need one then keep things simple and skip it.
5. Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Same answer as #4
Some users already gave some good answers to your questions that's why I want to give you some tips how I handle my projects.
Q: On which OS should my application run?
Windows and Linux! -> I would use C++ or Java
Q: Is runtime speed important?
Yes! (calculations, graphing, access to system resources...)
-> In view of speed C++ is often faster (not always)
Q: Is a config file required?
A: Yes! I have to set some user and system specific values.
-> Could save config into registry but since we also want to use our application on linux let's use xml (rapidxml would be a good solution for C++)
Q: Is a database required?
A: Yes I have some information/calculations I need to save (local/global).
-> Local: I'd use sqlite
-> If you just have to save comparatively few information please consider a faster way for storing these information (xml?!)
Q: How should I structure my application?
A: ALWAYS keep apart your GUI from the "logic" part -> Makes it easier to change you code later and you'll be able to use your code for other projects as well. + the already mentioned reasons.
Q: How should I structure my GUI?
A: Think about what your application should be used for and what users should be able to do. Ah, and please don't create a too deep hierarchy which means that user shouldn't have to open 10 windows in order to open the window they want to have. Same goes for your code, it's not a wise decision to have too many objects which create a new object.
object->object->object->object->object->object->object->object
Q: Does my application has to communicate with a server application?
A: Yes? You'll have to use sockets! But keep in mind that communications via sockets aren't very fast and secure so don't use them if you don't have to.
Q: I'm not sure how to start (we are a group of developer)
A: When starting a new project I'm thinking about all these points (maybe some more) + In order to see which classes and methods I need, I start by creating a UML-Diagram which will help me to understand where I should start and the diagram will also help me to keep track of my classes and methods and how they are involved with each other. The UML-Diagram will also help your mates or clients to understand how your application will be structured.
For bigger projects I'd use C++ & wxWidgits or maybe Qt. (Just my point of view)
Rgds
Layne
If you want a good example of a cross-platform GUI solution that is free and well written, may I suggest you look at wxWidgets (1). I hope this helps
My answer is very generic as you didn't tell anything about your application.
Should the GUI be separated from the application's logic?
In the code, definitely. Running in a separate process, possibly on a separate machine, might also be a good idea, but this really depends on your requirements.
Reasons to fully separate it:
Running application as a daemon or system service (in the background) while the GUI is not running
Controlling the application remotely over a network
Possibility of multiple independent GUI implementations, using different programming languages (e.g. iPhone?)
Support for automated control (scripting) without GUI
Implementing the separation later, if not initially done, is almost impossible
Reasons why not to separate:
Serialization of all I/O is required, making the implementation harder
Slight performance degration if very large amounts of data are transferred (this really does not affect your typical GUI application in any way)
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
HTTP is a popular choice and it avoids most problems with firewalls and such. In C/C++ you can use libcurl for http/https requests and Boost.CGI (not yet accepted to Boost) or one of the other CGI libraries for the server side.
Other options for IPC include shared memory (Boost.Interprocess), UNIX sockets and other network protocols. However, I would not recommend these unless very large amounts of data are transferred.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
I don't see much benefit from this. Still, separating the GUI allows writing it - possibly even multiple implementations of it - in different languages.
Is it a good idea to have a browser-based GUI?
Definitely. If what you need can be done with HTML5 and JavaScript, do not even consider a traditional GUI, just make it a webapp instead.
The benefits are:
Fully cross-platform
No installation of software on users' machines
All the clients always use the latest version of the GUI
Web GUI frameworks are actually nicer to work with than traditional GUI frameworks are
No need to separate the GUI into a separate process
Still possible to use from scripts (e.g. using the curl program from a shell script)
On the other side, you will get slight performance degradation, but once again it doesn't affect a typical GUI application enough to matter.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
The APIs of cross-platform GUI libraries are somewhat horrible. Qt does pretty good job at looking native nowadays and its API is rather good, even though it has a major impact on your application. Try to restrict any usage of Qt strictly to the GUI. The other option for true native cross-platform GUI is wxWidgets, which integrates better with other C++ code, but has a very nasty and error-prone API.
For web UI, you should definitely consider Wt, which is a high-level C++ AJAX framework, with an interface similar to Qt, but using modern C++ practices instead of taking over your application like Qt does.
http://www.wxwidgets.org/
http://www.webtoolkit.eu/wt
I agree with the commentators who said 'not enough information', but depending on your needs you should give a LOT of consideration to a web browser interface.
If real time streaming data and instant gratification interactivity are not important, the web interface can be fairly straightforward with no AJAX and just trivial form-based CGI and dynamically generated HTML. Keep in mind the part that exists as the browser is being updated for you with other people's money along with any change in Windows, Linux, Mac, or other systems.
Your users already find this familiar. You can find programmers to do the job.
Libraries exist already in almost every major language to embed a web server natively into an app, if needed. Or you can run a centralized server of some sort.
The browser already has a good means of separating content, input (forms), style, and enhancement where it will be easy to find people into the future who can develop or change out the relevant component.
Some people may say that's not good for standalone versions of the app, but I say that's fine for standalone as long as you add some security (run an embedded webserver where requests are only answered if they come from the local computer). The user's life can be made easier by starting the browser from the app or telling the user where to go in the startup message (the URL http://localhost:7654 or whatever, not their eternal destination :-)).
Should the GUI be separated from the application's logic?
Yes.
If it is separated, how should the logic and the GUI communicate? Are
TCP/IP sockets a good option? What are
other possibilities?
TCP/IP is going too far. Separate the application logic and GUI using OOP or any other structured programming approach.
Is it a good idea to have the GUI in a language different than a
C++? If yes - which language?
C++ is good enough as far as cross-platform apps are concerned. Other options are Java and .NET in which case, most of the cross-platform stuff is taken care of... though not with the degree of control that C++ provides.
Is it a good idea to have a browser-based GUI?
The best idea as long as your app does not need too fine a degree of control during user-interaction.
Even though the project's core logic is cross-platform, I can decide
that the GUI will be only
Windows-based (.NET?) and it will
communicate with the logic on the
relevant Win/Linux machine through
Socket or similar method. Is it a good
idea to do so?
IMHO the added complexity of using sockets is not worth it.
SciTE is a pretty good example a simple cross-platform application. The source code should be easy to follow for a Windows programmer. I suggest you download the source and have a look at how two platforms (Windows and GTK) have been handled the same code base.
You've god a lot of good answers, but still I'll write my own
Should the GUI be separated from the application's logic?
I think it's the best. So you can handle it easier when it come to modifications. Also, use a GUI framework that is multiplatform and has bindings for other languages, such as GTK+ or Qt.
If it is separated, how should the logic and the GUI communicate? Are TCP/IP sockets a good option? What are other possibilities?
Sockets are a good choice or via threads if it's local communication.
Is it a good idea to have the GUI in a language different than a C++? If yes - which language?
I think it's not the best option. Use the same language for everything if you can.
Is it a good idea to have a browser-based GUI?
As long as it's not too complex. I think the browser based GUIs are only for collaborative tools or absolute platform-independant (every OS has a browser) as far as you hold the main program in a server. As someone said avobe, if you consider doing a web GUI, consider first to do a webapp instead.
Even though the project's core logic is cross-platform, I can decide that the GUI will be only Windows-based (.NET?) and it will communicate with the logic on the relevant Win/Linux machine through Socket or similar method. Is it a good idea to do so?
Not in my opinion, it adds complexity, usually unnecessary, but if you really have to do that, yes, sockets are the best option.
STL/Boost cover all the low level stuff.
But what about the higher 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?
Something 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 there (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 projects 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 deprecated keyword)) into a nice consolidated whole.
Note: Windows is just a small part of what I am looking for. The Java/C# languages consolidate 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.
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.
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.
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.
Qt might be the only framework complete enough to be what you suggest.
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.
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?
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 !
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).
ACE is great for concurrent communication and networking.
For cross platform windowing, there's wxWidgets. (formerly wxWindows).
Only everybody and his brother, but hardly any of them actually get anywhere.