I'm coming to C++ from a .Net background. Knowing how to use the Standard C++ Libraries, and all the syntax, I've never ventured further. Now I'm looking learning a bit more, such as what libraries are commonly used? I want to start getting into Threading but have no idea to start. Is there a library (similar to how .net has System.Threading) out there that will make it a bit easier? I'm specifically looking to do Linux based network programming.
For C++, Boost is your everything. Threading and networking are among the things it offers. But there's much more:
Smart pointers
Useful containers not found in the STL, such as fixed-size arrays and hashtables
Closures
Date/time classes
A foreach construct
Min/max functions
Command line option parsing
Regular expressions
As the others have said, Boost is great. It implements the C++ Technical Report 1 in addition to tons of other stuff, including some mind-blowing template metaprogramming tricks.
For other cross-platform features not provided by Boost, I've had very good luck with a library called Poco. I've worked on commercial projects that incorporated its simple HTTP server, for instance, and it treated us quite well.
lots of boost suggestions, but Qt is another good option. It's got great support for threading and networking along with pretty much everything else.
http://qt.nokia.com/products
If you are looking into network programming and are not interested into GUI, I suggest Boost libraries: in particular, Asio.
There's no standard multithreading library, but the boost library includes a platform-independent multithreading abstraction that works very well.
Related
I am thinking of creating a multi-platform portable C++ server-client application. Is it even possible while using only standard libraries? If no, what other libraries are there?
Are there any improvements in this direction in C++11x? Like for threads, now we have std::threads.
To make it more clear.. I want something like boost::thread, which provides multiplatform portable multithreading, for networking.
And why C++ doesn't have libraries(standard) for such basic things like networking?
Update: Comparing to Python, which has everything (almost) built in to it... why not in C++?
There is Boost Asio. It has existed for "only" a small number of years...long ago we had ACE, but it feels dated now.
There is no standard portable option in C++11.
However the portable boost::asio is one of the best networking API's. It is based on the proactor pattern which is very efficient.
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio.html
There have been many attempts to provide such a cross-platform library for networking over the years. The Berkeley socket library comes pretty close (and probably comes with your OS), but there are still platform-specific differences. Qt has network socket classes that attempt to be cross-platform within the subset of platforms that Qt normally supports. You can probably find lots of others.
There is no language standard networking library for C or C++ analogous to std::thread.
I'm mainly a java programmer and I'm getting started with C++.
I wonder if you could help me finding a java-like object-oriented library.
Thanks and regards
I would rather suggest you to not use java-like libraries. If you want to learn C++ first dig into the standard library. Try to understand the concepts used there (iterator, allocators, templates, ...)
I found this a good source of information related to the STL.
C++ as language is far more complex than java so the learning curve is straight, but after you got the basics you can write fancier, cleaner and achieve more with less code.
Well designed libraries
Boost Multiple purpose (Networking, Threading, Smart Pointers, ...)
QT UI library, multiple purpose
I learned C# before I had to write C++, so I understand your issue. Try not to write everything object oriented. You just don't in C++.
Ice for communications.
Multipurpose Boost library.
My advice would be to get used to the C++ languages and the standard library. This is how you will learn C++.
I don't know if there is a good answer to your question, unfortunately. But if you like you could always interface from Java to C using JNI.
My advice: write a 10-20 console applications in pure ะก++. Then try to use templates. Then communication through network. And then, IF you feel comfortable with syntax and commonly used libraries like STL and BOOST, you can try GUI toolkits like wxWidgets, QT, GTK.
Trying to write GUI applications from the begining seems to me a bad practice.
What is the most basic way to go to a webpage and download its contents? the webpage i wish to get only has text, most of which is in tables.
is there a std library that does it (like urllib in python)?
There's no official C++ network library, no. There are many different APIs available, though. Which is best for you would depend on what platform(s) you were targeting and what framework(s) you might already be using.
That said, cpp-netlib is a platform-neutral API that follows C++ idioms nicely. I've used it and it works.
A large number of tasks that are not covered by the C++ standard library can be done using boost, the collection of peer-reviewed portable libraries, which are used by pretty much every C++ project today. For networking, we use boost.asio.
Their tutorials include HTTP clients: http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/http/client/sync_client.cpp and http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/http/client/async_client.cpp
However, although this is highly portable and may end up becoming part of the C++ standard library in future, it is a bit too low-level for your task. libCURL is the today's default library for HTTP downloads.
I am a student, and new to C++. I am searching for a standard C++ API that is as comprehensive as the Java API. So far I have been using cplusplus.com, and cppreference.com.
Please any help would be greatly appreciated.
C++ and Java have very different standard libraries because they make very different assumptions about what they are going to be used for.
Java assumes that applications or applets will be running on a host with a full featured OS, with a defined way of doing most normal things.
There's a lot of content in that, for instance, in java, the output will be an application or applet. C++ does not make that assumption, because C++ can be used for building OS Kernels and drivers for kernels, it can be used for programming full stack real time applications on microcontrollers, or processing blocks in supercomputers.
C++ can be used for implementing the very operating system on which it will run.
For these reasons, the standard library assumes almost nothing about what it will have available, and so the standard library doesn't make any dependencies on those features.
The only exception is with files and streaming, because almost any operating system like stack has something that looks like a file stream if it has anything like files at all.
If you want a richer set of OS Specific api's you need to look at something non-standard. A great choice is the Qt framework, which provides many tools similar to what is found in the Java libraries, is cross platform, and works well with native C++ idioms.
C++ has a standard library.
You can try reading the "The C++ Standard Library: A Tutorial and Reference". While I don't own it myself, it's on our book list (which I recommend you check out), so it shouldn't be bad.
Note C++ isn't Java, so the libraries don't necessarily have the same functionality. Another resource you'll want to look at is Boost, which serves as a source for well-written C++ libraries for things the standard library lacks.
GNU C++ Standard library documentation is the one I refer to most often.
Java is a virtual machine language and as such attempts to have a comprehensive api to provide a platform independent method of drawing/wrtinging to files / anything. IN the guts of JRE they are taking these generic inputs and using them to do platform specific things. In C++ you are the one that does that work. Many c++ libraries are platform specific see MFC, ATL or code that is written for XWindows it your job to decide how you want to implement a feature and see if that is a platform specific feature or can be done in a platform independent manner.
If you are writing on windows or unix I can assure that the OS API is very complete and will allow you to do what ever your trying to accomplish. Also take a look at cross platfom libraries like lib qt.
Java's standard library is aimed at providing ready-to-use functionality, while the C++ standard library is aimed at providing building blocks that aren't defined by the core language. The Boost library has mainly the same orientation as the standard library (with a few exceptions such as image processing). I think the closest you can get to something like Java's standard library is the Poco library.
However, when I tried on the Poco library I found that it was a bit too C-oriented for my taste.
That is, it's not "modern". You get that impression straight away without even looking at the APIs, because the online docs uses 1990's frames. :-) However, it may fill your needs.
If you mean the c++ standard library I'd look at www.cplusplus.com. It covers the current standards. After familiarizing yourself with that, you could try looking at boost.
There are a number of changes in the upcoming c++0x standard. Wikipedia has info on a number of these as does SO.
The number one book, IMO, for c++ is Effective C++ by Scott Meyers.
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.