Is the new C++11 going to contain any socket library? So that one could do something std::socket-ish?
Seeing as how std::thread will be added, it feels as if sockets should be added as well. C-style sockets are a pain... They feel extremely counter-intuitive.
Anyways: Will there be C++ sockets in C++11 (googled it but couldn't find an answer)? If not, are their any plans on adding this? Why (/ why not)?
No, it is not. As for the near future, the C++ standards committee has created a study group that is developing a networking layer proposal. It looks like they're going for a bottom-up approach, starting with a basic socket layer, then building HTTP/etc support on top of that. They're looking to present the basic socket proposal at the October committee meeting.
As for why they didn't put this into C++11, that is purely speculative.
If you want my opinion on the matter, it's for this reason.
If you are making a program that does something, that has a specific functionality to it, then you can pick libraries for one of two reasons. One reason is because that library does something that is necessary to implement your code. And the other is because it does something that is helpful in implementing code in general.
It is very difficult for a design for a particular program to say, "I absolutely must use a std::vector to hold this list of items!" The design for a program isn't that specific. If you're making a web browser, the idea of a browser doesn't care if it holds its tabs in a std::vector, std::list, or a user-created object. Now, some design can strongly suggest certain data structures. But rarely does the design say explicitly that something low-level like a std::list is utterly essential.
std::list could be used in just about any program. As can std::vector, std::deque, etc.
However, if you're making a web browser, bottled within that design is networking. You must either use a networking library or write a networking layer yourself. It is a fundamental requirement of the idea.
The term I use for the former type, for libraries that could be used in anything, is "utility" libraries.
Threading is a utility library. Design might encourage threading through the need to respond to the user, but there are ways to be responsive without preemptive multithreading. Therefore, in most cases, threading is an implementation choice. Threading is therefore a utility.
Networking is not. You only use networking if your design specifically calls for it. You don't decide to just dump networking into a program. It isn't an implementation detail; it is a design requirement.
It is my opinion that the standard C/C++ library should only implement utilities. It's also why I'm against other heavyweight ideas like XML parsers, etc. It isn't wrong for other libraries to have these things, but for C and C++, these are not good choices.
I think it should, since a lot of other popular languages support socket operations as a part of the language (they don't force the user to use any OS-specific API). If we already have file streams to read/write local files, I don't see why we can't have some method of transferring data with sockets.
There will be no sockets in C++11. The difference between threads and sockets is that threads involves making more guarantees about ordering, if your program involves threads. For a platform with just one core, then C++11 doesn't mandate that your CPU springs an extra core. Sockets, on the other hand, would be... difficult to implement portably and fail gracefully on systems that don't have them.
This is so weird that in 2022, there is still no standard for a basic OS construct as sockets in C++.
The closest I found is kissnet (Apparently exists since 2019).
It's small (~1500 lines), runs on Windows and Linux, uses OpenSSL, and requires C++ 17 (Which is a plus in my book), basically everything I needed.
There will not be in C++0x. There are proposals to add them in a future version.
The amount of new stuff in C++0x had to be limited to give the committee time to deal with it all thoroughly.
The wikipedia page for C++0x is usually pretty up to date and the section on library changes doesn't seem to mention sockets.
Related
** Please people, this question is not meant to begin any flame war. **
I am trying to understand what happens to existing libraries implementing some functionality when the same functionality that was not previously there in the language now comes in as part of the language? For e.g. C++ would soon have std::thread as part of the language standard so what happens to the POSIX or Boost Libraries?
I would also be keen to understand what experiences users of other programming languages might have in this regard.
Adoption of new technology never happens overnight. There will be a lag while compilers implement the new Standard Library versions, and then another lag while those compilers reach developers.
My last two jobs have featured occasional interaction with Visual C++ 6, which is over 10 years old. There is great reluctance to move from working code to a new if improved model.
If old libraries do die, it's through a process of gradual obsolescence rather than sudden mass extinction.
Depending on the library, it's possible that the upcoming standard simply captures a snapshot of current function, and the parent library will continue to evolve as an incubator for C++1x, C++2x and so on.
Sometimes library authors continue to maintain their library because their library does something slightly different than how it is done within the language: either this difference offers a unique advantage or is fundamentally easier to grok. Whatever the case, if there is enough user desire to see it continue or if the author is stubborn it will continue to be maintained. Eventually, though, people just use what comes naturally in a language if the advantage is not great enough.
C++ std::thread is in large parts based on boost threads. So boost threads will never really disappear, they will live on in the standard C++ library.
Additionally, on many platforms boost threads use posix threads as backend, so they will never disappear too.
Such thing hasn't happened yet. C++ has only one implementation so far.
Previously, I used to use MFC collection classes such CArray and CMap. After a while I switched to STL containers and have been using them for a while. Although I find STL much better, I am unable to pin point the exact reasons for it. Some of the reasoning such as :
It requires MFC: does not hold because other parts of my program uses MFC
It is platform dependent: does not hold because I run my application only on windows.(No need for portability)
It is defined in the C++ standard: OK, but MFC containers still work
The only reason I could come up is that I can use algorithms on the containers. Is there any other reason that I am missing here - what makes STL containers better than MFC containers?
Ronald Laeremans, VC++ Product Unit Manager, even said to use STL in June 2006:
And frankly the team will give you the same answer. The MFC collection classes are only there for backwards compatibility. C++ has a standard for collection classes and that is the Standards C++ Library. There is no technical drawback for using any of the standard library in an MFC application.
We do not plan on making significant changes in this area.
Ronald LaeremansActing Product Unit ManagerVisual C++ Team
However, at one point where I was working on some code that ran during the installation phase of Windows, I was not permitted to use STL containers, but was told to use ATL containers instead (actually CString in particular, which I guess isn't really a container). The explanation was that the STL containers had dependecies on runtime bits that might not actually be available at the time the code had to execute, while those problems didn't exist for the ATL collections. This is a rather special scenario that shouldn't affect 99% of the code out there.
STL containers:
Have performance guarantees
Can be used in STL algorithms which also have performance guarantees
Can be leveraged by third-party C++ libraries like Boost
Are standard, and likely to outlive proprietary solutions
Encourage generic programming of algorithms and data structures. If you write new algorithms and data structures that conform to STL you can leverage what STL already provides at no cost.
Compatibility with other libraries (such as boost) in syntax, interoperability, and paradigm. It's a non-trivial benefit.
Using STL will develop a skillset that is more likely to be useful in other contexts. MFC isn't so widely used any more; STL is.
Using STL will develop a mindset that you may (or may not) find useful in code you write yourself.
Using something other than STL isn't inherently wrong though.
STL has more collection types than MFC
Visual Studio (2008+) debugger visualizes STL much better than MFC. (AUTOEXP.DAT magic can fix that - but it is a pain! Nothing like debugging your debugger when you screw it up...)
One good thing with MFC is that there is still a large corpus of MFC code out there. Other answers talk about third-party compatibility. Don't forget third party MFC-based stuff.
I always prefer using more standard/compatible libraries where I can since I may have future projects that I can reuse a portion of the code on. I have no idea what libraries future projects will use, but I have a better chance of making my code reusable if I use standard/compatible stuff.
Also, the more I use a library, I get more comfortable and quicker with it. If I am going to invest the time to learn a library, I want to make sure it's going to stay around and is not tied in with a specific platform or framework.
Of course, I say all of this assuming that my choices are rather similar when it comes to performance, features and ease of use. For instance, if the MFC classes are a significant enough improvement in these areas, I would use them instead.
In fact you can use STL algorithms on some of MFC containers as well. However, STL containers are preferred for another very practical reason: many third-party libraries (Boost, arabica, Crypto++, utf-cpp...) are designed to work with STL, but know nothing about MFC containers.
MFC containers derive from CObject and CObject has the assignment operator made private. I have found this very annoying in practice.
std::vector, unlinke CArray, guarantees that the memory block is contiguous, thus you can interop with C programming interfaces easily:
std::vector<char> buffer;
char* c_buffer = &*buffer.begin();
It is now assumed that C++ developers are at least passingly familiar with the STL. Not so for MFC containers. So if you're adding a new developer to your team, you will have an easier time finding one who know STL than the MFC containers, and thus will be able to contribute immediately.
I think it boils down to a simple question: Who do you trust more? If you trust Microsoft, then continue to use the MFC variants. If you trust the industry, then use STL.
I vote for STL because the code that runs on Windows today might need to be ported to another platform tomorrow. :)
This is a case of whichever tools work for the job you want to do, and 'better' being a subjective term.
If you need to use your containers with other standards-compliant code, or if it is ever going to be code that is shared across platforms, STL containers are probably a better bet.
If you're certain that your code will remain in MFC-land, and MFC containers work for you, why not continue to use them?
STL containers aren't inherently better than MFC containers, however as they are part of the standard they are more useful in a wider range of contexts.
Next to the mentioned aspects: well-supported, standard available, optimized for performance, designed for use with the algorithms, I might add one more aspect: type-safety, and loads of compile-time checks. You can't even imagine drawing a double out of a std::set<int>.
Because a library that uses iterators to combine sequences of any kind with algorithms so that A) all sensible permutations are possible and B) it's universally extensible, is (when you think about your concept of a container library as it was 15 years ago) such a mind-blowingly marvelous idea, that it has pretty much blown out of the water everything else within less than a decade?
Seriously, the STL has its flaws (why not ranges instead of iterators? and that erase-remove idiom is not exactly pretty), but it's based on a brilliant idea and there's very good reasons we don't need to learn a new container/algorithms library every time we start at a new job.
I wouldn't totally dismiss the portability argument. Just because you use MFC today doesn't mean that you always will. And even if you mostly write for MFC, some of your code could be re-used in other applications if it were more generic and standards-based.
I think the other reason to consider STL is that its design and evolution has benefited from libraries that have come before, include MFC and ATL. So many of the solutions are cleaner, more re-usable, and less error prone. (Though I wish they had a better naming convention.)
In trying to get up to speed with C++ (coming from a long experience with C), I am obviously trying to do the right thing, and use as much as is standard as is possible.
However, in my readings on the matter I come accross a lot of criticism for standard things, and praise for non-standard things. For example, even the the (I assume) poorly-thought-of MFC library has features in, for example, its CString class that some folks think useful enough to cause them to continue using it despite the fact that it's (a) non-standard and (b) that it's (I assume, from the wealth of criticism) deficient in many important ways.
My question is twofold, then:
A. What libraries that are poorly-thought-of contain features that nonetheless make it worth continuing to use them, what are those features, and what's so good about them?
B. Are there "adaptor" libraries out there that simplify and/or tighten up the use of such libraries, e.g. providing nice interfaces that abstract resources leaks, adaptors that go from a non-STL library interface to a STL, and so on
As a relative newbie to StackOverflow, I'm not 100% sure that this question is sufficiently on-point, so I apologise up-front if it's too open-ended.
Thanks in advance
My personal grunge is with ACE. It was sort of the other way around - great idea, nothing else was available at the time for cross-platform threaded and network development in C++, wide deployment, books by the library authors, etc. But the implementation was terrible, usage patterns were complicated, almost all the useful features of C++ suppressed (or didn't exist at the time.) I think this library alone is responsible for good chunk of people thinking that C++ is hard and ugly. Very recently Boost collection started catching up with threads, ipc, and networking, so there is at least an alternative. BUT with all that said, I still think it's worth to be familiar with ACE if you are in that space since, again, way too many people use it, the ideas are good, and it can serve as great negative example for library design.
IMO the best thing about MFC is that, historically, it was available before the STL was available, and something was better than nothing.
MFC is still good, if you're writing code to be compatible with an existing MFC code base.
Apart from that there's little merit in MFC, except that it's perhaps still one of the (if not the most) obvious C++ class library for Windows.
On a more general note I think one of the reasons that people stick with old, awkward and perhaps even obsolete libraries is that they have grown used to it and anything new and shiny might do the job better but are harder to grasp/understand initially. And so you stay with what is familiar and keep your productivity.
I think it is a balance between getting the job done and getting the job done "right". Somewhere in between is probably where most of us end up.
CString is non-standard because MFC is not cross-platform, I think. std::string() is standard, but if we use everything standard, then why MS developed MFC?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been working with the Boost C++ Libraries for quite some time. I absolutely love the Boost Asio C++ library for network programming. However I was introduced to two other libraries: POCO and Adaptive Communication Environment (ACE) framework. I would like to know the good and bad of each.
As rdbound said, Boost has a "near STL" status. So if you don't need another library, stick to Boost. However, I use POCO because it has some advantages for my situation. The good things about POCO IMO:
Better thread library, especially a Active Method implementation. I also like the fact that you can set the thread priority.
More comprehensive network library than boost::asio. However boost::asio is also a very good library.
Includes functionality that is not in Boost, like XML and database interface to name a few.
It is more integrated as one library than Boost.
It has clean, modern and understandable C++ code. I find it far easier to understand than most of the Boost libraries (but I am not a template programming expert :)).
It can be used on a lot of platforms.
Some disadvantages of POCO are:
It has limited documentation. This somewhat offset by the fact that the source is easy to understand.
It has a far smaller community and user base than, say, Boost. So if you put a question on Stack Overflow for example, your chances of getting an answer are less than for Boost
It remains to be seen how well it will be integrated with the new C++ standard. You know for sure that it will not be a problem for Boost.
I never used ACE, so I can't really comment on it. From what I've heard, people find POCO more modern and easier to use than ACE.
Some answers to the comments by Rahul:
I don't know about versatile and advanced. The POCO thread library provides some functionality that is not in Boost: ActiveMethod and Activity, and ThreadPool. IMO POCO threads are also easier to use and understand, but this is a subjective matter.
POCO network library also provides support for higher level protocols like HTTP and SSL (possibly also in boost::asio, but I am not sure?).
Fair enough.
Integrated library has the advantage of having consistent coding, documentation and general "look and feel".
Being cross-platform is an important feature of POCO, this is not an advantage in relation to Boost.
Again, you should probably only consider POCO if it provides some functionality you need and that is not in Boost.
I've used all three so here's my $0.02.
I really want to vote for Doug Schmidt and respect all the work he's done, but to be honest I find ACE mildly buggy and hard to use. I think that library needs a reboot. It's hard to say this, but I'd shy away from ACE for now unless there is a compelling reason to use TAO, or you need a single code base to run C++ on both Unix variants and Windows. TAO is fabulous for a number of difficult problems, but the learning curve is intense, and there's a reason CORBA has a number of critics. I guess just do your homework before making a decision to use either.
If you are coding in C++, boost is in my mind a no-brainer. I use a number of the low level libraries and find them essential. A quick grep of my code reveals shared_ptr, program_options, regex, bind, serialization, foreach, property_tree, filesystem, tokenizer, various iterator extensions, alogrithm, and mem_fn. These are mostly low-level functionality that really ought to be in the compiler. Some boost libraries are very generic; it can be work to get them to do what you want, but it's worthwhile.
Poco is a collection of utility classes that provide functionality for some very concrete common tasks. I find the libraries are well-written and intuitive. I don't have to spend much time studying documentation or writing silly test programs. I'm currently using Logger, XML, Zip, and Net/SMTP. I started using Poco when libxml2 irritated me for the last time. There are other classes I could use but haven't tried, e.g. Data::MySQL (I'm happy with mysql++) and Net::HTTP (I'm happy with libCURL). I'll try out the rest of Poco eventually, but that's not a priority at this point.
Many POCO users report using it alongside Boost, so it is obvious that there are incentives for people in both projects. Boost is a collection of high-quality libraries. But it is not a framework. As for ACE, I have used it in the past and did not like the design. Additionally, its support for ancient non-compliant compilers has shaped the code base in an ugly way.
What really distinguishes POCO is a design that scales and an interface with rich library availability reminiscent of those one gets with Java or C#. At this time, the most acutely lacking thing from POCO is asynchronous IO.
I have used ACE for a very high performance data acquisition application with real time constraints. A single thread handles I/O from over thirty TCP/IC socket connections and a serial port. The code runs on both 32 and 64 bit Linux. A few of the many ACE classes I have used are the ACE_Reactor, ACE_Time_Value, ACE_Svc_Handler, ACE_Message_Queue, ACE_Connector. ACE was a key factor to the success of our project. It does take a significant effort to understand how to use the ACE classes. I have all the books written about ACE. Whenever I have had to extend the functionality our system it typically takes some time to study what to do and then the amount of code required is very small. I have found ACE to very reliable. I also use a little bit of code from Boost. I do not see the same functionality in Boost. I would use either or both libraries.
I recently got a new job and work on a project that uses ACE and TAO. Well, what I can tell is, that ACE and TAO work and fully accomplish their tasks. But the overall organisation and design of the libraries are quite daunting...
For example, the main part of ACE consists of hundreds of classes starting with "ACE_". It seems like they've ignored namespaces for decades.
Additionally, many of ACE's class names don't provide useful information either. Or can you guess what classes like ACE_Dev_Poll_Reactor_Notify or ACE_Proactor_Handle_Timeout_Upcall can be used for?
Additonally, the documentation of ACE is really lacking, so unless you want to learn ACE the hard way (it is really hard without any good documentation..), I would NOT recommend using ACE, unless you really need TAO for CORBA, If you don't need CORBA, go ahead and use some modern libraries..
Boost enjoys a "near STL" status due to the number of people on the C++ standards committee who are also Boost developers. Poco and ACE do not enjoy that benefit, and from my anecdotal experience Boost is more widespread.
However, POCO as a whole is more centered around network-type stuff. I stick to Boost so I can't help you there, but the plus for Boost is its (relatively) widespread use.
The ACE socket libraries are solid. If you are trying to port a standard implementation of sockets you can't go wrong. The ACE code sticks to a rigid development paradigm. The higher level contructs are a little confusing to use. The rigid paradigm causes some anomolies with exception handling. There are or used to be situations where string value pairs being passed into an exception with one of the pair being null causes an exception throw in the exception that will boggle you. The depth of the class layering is tedious when debugging. I have never tried the other libraries so can't make an intelligent comment.
Boost is great, I've only heard good things about POCO (but never used) but I don't like ACE and would avoid it in future. Although you will find fans of ACE you will also find many detractors which you don't tend to get with boost or poco (IME), to me that sends a clear signal that ACE is not the best tool (although it does what it says on the tin).
Out of those I've only ever really used ACE. ACE is a great framework for cross-platform enterprise networking applications. It's extremely versatile and scalable and comes with TAO and JAWS for quick, powerful development of ORB and/or Web based applications.
Getting up to speed with it can be somewhat daunting, but there is a lot of literature on it, and commercial support available.
It's somewhat heavy though, so for smaller-scale apps it may be a bit of an overkill. Reading the summary for POCO it sounds like they're aiming for a system that can be run on embedded systems so I'm assuming it can be used in a much lighter way. I may now give it a whirl :P
I think it is really matter of an opinion, there is hardly a right answer.
In my experience with writing portable Win32/Linux server code (15+ years), I personally find boost/ACE unnecessarily bloated and introduces maintenance hazards (otherwise known as "dll hell") for the little advantage they give.
ACE also seems to be horribly outdated, it is a "c++ library" written by "c programmers" in the 90-s and it really shows in my opinion. It so happens, right now I am re-engineering the project written with Pico, it seems to me it completely follows the ACE idea, but in more contemporary terms, not much better at that.
In any case for high performance, efficient, elegant server communications you might be better off not using any of them.
I am involved in a venture that will port some communications, parsing, data handling functionality from Win32 to Linux and both will be supported. The problem domain is very sensitive to throughput and performance.
I have very little experience with performance characteristics of boost and ACE. Specifically we want to understand which library provides the best performance for threading.
Can anyone provide some data -- documented or word-of-mouth or perhaps some links -- about the relative performance between the two?
EDIT
Thanks all. Confirmed our initial thoughts - we'll most likely choose boost for system level cross-platform stuff.
Neither library should really have any overhead compared to using native OS threading facilities. You should be looking at which API is cleaner. In my opinion the boost thread API is significantly easier to use.
ACE tends to be more "classic OO", while boost tends to draw from the design of the C++ standard library. For example, launching a thread in ACE requires creating a new class derived from ACE_Task, and overriding the virtual svc() function which is called when your thread runs. In boost, you create a thread and run whatever function you want, which is significantly less invasive.
Do yourself a favor and steer clear of ACE. It's a horrible, horrible library that should never have been written, if you ask me. I've worked (or rather HAD to work with it) for 3 years and I tell you it's a poorly designed, poorly documented, poorly implemented piece of junk using archaic C++ and built on completely brain-dead design decisions ... calling ACE "C with classes" is actually doing it a favor. If you look into the internal implementations of some of its constructs you'll often have a hard time suppressing your gag reflex.
Also, I can't stress the "poor documentation" aspect enough. Usually, ACE's notion of documenting a function consists of simply printing the function's signature. As to the meaning of its arguments, its return value and its general behavior, well you're usually left to figure that out on your own. I'm sick and tired of having to guess which exceptions a function may throw, which return value denotes success, which arguments I have to pass to make the function do what I need it to do or whether a function / class is thread-safe or not.
Boost on the other hand, is simple to use, modern C++, extremely well documented, and it just WORKS! Boost is the way to go, down with ACE!
Don't worry about the overhead of an OS-abstraction layer on threading and synchronization objects. Threading overhead literally doesn't matter at all (since it only applies to thread creation, which is already enormously slow compared to the overhead of a pimpl-ized pointer indirection). If you find that mutex ops are slowing you down, you're better off looking at atomic operations or rearranging your data access patterns to avoid contention.
Regarding boost vs. ACE, it's a matter of "new-style" vs. "old-style" programming. Boost has a lot of header-only template-based shenanigans (that are beautiful to work with, if you can appreciate it). If, on the other hand, you're used to "C with classes" style of C++, ACE will feel much more natural. I believe it's mostly a matter of personal taste for your team.
I've used ACE for numerous heavy duty production servers. It never failed me. It is rock solid and do the work for many years now. Tried to learn BOOST's ASIO network framework-Couldn't get the hang of it. While BOOST is more "modern" C++, it also harder to use for non trivial tasks - and without a "modern" C++ experience and deep STL knowledge it is difficult to use correctly
Even if ACE is a kind of old school C++, it still has many thread oriented features that boost doesn't provide yet.
At the moment I see no reason to not use both (but for different purposes). Once boost provide a simple mean to implement message queues between tasks, I may consider abandoning ACE.
When it comes to ease-of-use, boost is way better than ACE. boost-asio has a more transparent API, its abstractions are simpler and can easily provide building blocks to your application. The compile-time polymorphism is judiciously used in boost to warn/prevent illegal code. ACE's uses of templates, on the other hand, is limited to generalization and is hardly ever user-centric enough to disallow illegal operations. You're more likely to discover problems at run-time with ACE.
A simple example which I can think of is ACE_Reactor - a fairly scalable and decoupled interface- but you must remember to call its "own" function if you're running its event loop in a thread different from where it was created. I spent hours to figure this out for the first time and could've easily spent days. Ironically enough its object model shows more details than it hides - good for learning but bad for abstraction.
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
Threading is really only a small part of what boost and ACE provide, and the two aren't really comparable overall. I agree that boost is easier to use, as ACE is a pretty heavy framework.
I wouldn't call ACE "C with classes." ACE is not intuitive, but if you take your time and use the framework as intended, you will not regret it.
From what I can tell, after reading Boost's docs, I'd want to use ACE's framework and Boost's container classes.
Use ACE and boost cooperatively. ACE has better communication API, based on OO design patterns, whereas boost has like "modern C++" design and works well with containers for example.
We started to use ACE believing that it would hide the platform differences present between windows and unix in TCP sockets and the select call. Turns out, it does not. Ace's take on select, the reactor pattern, cannot mix sockets and stdin on windows, and the semantic differences between the platforms concerning socket writablility notifications are still present at the ACE level.
By the time we realized this we were already using the thread and process features of ACE (the latter of which again does not hide the platform differences to the extent we would have liked) so that our code is now tied to a huge library that actually prevents the porting of our code to 64 Bit MinGW!
I can't wait for the day when the last ACE usage in our code is finally replaced with something different.
I've been using ACE for many years (8) but I have just started investigating the use of boost again for my next project. I'm considering boost because it has a bigger tool bag (regex, etc) and parts of it are getting absorbed into the C++ standard so long term maintenance should be easier.
That said, boost is going to require some adjustment. Although Greg mentions that the thread support is less invasive as it can run any (C or static) function, if you're used to using thread classes that are more akin to the Java and C# thread classes which is what ACE_Task provides, you have to use a little finesse to get the same with boost.