(Question and description rephrased so as to be S.O. compatible)
It is strange that C++ has no widely-adopted, peer-reviewed actor model library yet (on the order of BOOST and STD). I see Theron, but it looks like a man and his code: no matter how good it is, it is not something I would want production code to rely on.
Thus, how do I do Actor Model programming in C++ without having to use unproven libraries? Which BOOST classes should I use?
Note: I am asking this in the face of one or two previous questions on S.O. that show up when one searches for "actor C++" because they had little or no traction. For SEE SHARP, there is this thread But for C++, even the one question that got medium traction this guy, a question from FIVE YEARS AGO was answered with a pointer to a dead link!
libcppa can be a good choice. Looks better than Theron (which seems to be dead -- the author didn't respond to my email about a bug I've found). Also, there's a "fork" of libcppa named Boost.Actor from the same author here. So hopefully in a couple of years we'll have a proper well-tested peer-reviewed actor implementation in Boost :)
The lack of an answer by now seems to imply that there is as of 2014 no strongly peer-reviewed Actor system in platform-independent C++.
If you're using Microsoft VS, you can use the Microsoft Asynchronous Agents library
There is also the Intel TBB FlowGraph library, but global availability seems questionable, so it is unclear as to how well it would work on Android/Exynos/Snapdragon/etc or iOS/armv systems. See this question.
libcppa is not peer reviewed (yet), but it's being developed by the iNET working group at the Hamburg University of Applied Sciences. There are publications surrounding its development, it includes a Benchmark Suite, and it is currently in the preliminary submission process for Boost under the name Boost.Actor. If you want to have a peer reviewed actor system in the future, please go ahead and join the discussion on the Boost Mailing List or give Boost.Actor a (short) review in the brand new Boost Library Incubator.
I agree that code should be peer reviewed, and that there is a need for such a library for C++. I have based my code on Theron, which I find quite complete and very efficient, and with a proper C++ API (much better than libcppa). Ashton has also always responded quickly to all of my requests. Let us hope that it will be released for other committers soon!
The downside with Theron is that its mechanism for distributed communication is broken since it was based on XS a dead variant of ZeroMQ. I am in the process of redesigning the communication mechanism and intend to release this back to Theron by May 2015 with a complete support for ZeroMQ. Thus, Theron is at least properly peer reviewed by me...
I would not recommend building your own Actor mechanism - it will then just be "another man with his code" as you stated. It would be better if we could have a proper release of Theron that we could all work on.
I'm just starting to use boost for my embedded C++ programming. Lambda looked interesting so I was reading up on it. When I tried using stl algorithms with lambdas on containers of shared_ptrs I ran into some problems. Doing some searching here on SO led me to a post that indicated Lambda was deprecated and Phoenix was to be used for all new code. As I try to learn more of boost I would like to avoid learning the deprecated parts. Where is this type of thing documented?
In general, the boost documentation will warn you of deprecated features. However, this information sometimes "leaks" out before the docs are updated, which is what seems to have happened in this case. You could always subscribe to one of the developer mailing lists if you really want to be at the cutting-edge, otherwise you should be just fine sticking to the official docs.
well the docs on boost's thread lib isn't as good as the asio lib...
And after reading this: http://www.boost.org/doc/libs/1_44_0/doc/html/thread/synchronization.html I got the main idea but there is no codes and examples, that I could find, using that.
I would be happy for a link or explanations on how using that..
These two tutorials might help as they have code examples.
this has a section on multithreading which gives an intro to synchronization objects
Another one from Dr. Dobb's has an intro.
I'd like to do some network socket programming in C++ and have found the C++ Sockets library.
First, is this a good way to go in C++? Normally in C, I'd use some of the stuff beej describes in his tutorial.
Second, how do I compile the examples given on the site? I can't figure it out from their installation/configuration guide. So I download the tar.gz to my Linux box, then what?
To have a specific example, how do I compile and run the DisplaySocket example?
Thanks.
EDIT: Thank you for the quick answers. A comment though. I'm not really looking into "understanding" network programming as I think I do that well enough already. I want to know if there's anything in particular to take advantage of in C++, and - if "the C++ Sockets Library" is a good choice - how to use it.
That's not "the" C++ sockets library, it's "a" C++ sockets library. Boost.asio has another (http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio.html).
(Community Wiki since I can't actually help you with your question - I've never compiled the code you ask about, so I don't know at what point you might have tripped over a problem).
Network programming would be better understood by using basic socket api (BSD or WinSock) rather than a socket library which hides most of the intricacies about sockets and their behaviour.
I would second the vote for boost::asio since it encapsulates the inversion of control model that is the current, preferred model, and appears to be standard-bound. To learn what the documentation doesn't tell you, google Douglas Schmidt and his books.
I like to use the ACE networking library when I write networking code in C++. I think it does a nice job abstracting some of the intricate details away that make network coding painful but doesn't do it to the point where it hides what is going on under the hood. It also has facilities for threading and messaging which usually are needed for any project.
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.