How important is Boost to learn for C++ developers? [closed] - c++

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am curious to learn Boost. But I wanted to ask:
How important is it to make the effort to learn Boost?
What prerequisites should one have before jumping on Boost?
Why I am curious to know about Boost is that many people are talking about Boost on IRC's channels and here in StackOverflow.

I think anyone that is seriously considering C++ development as a career should learn Boost, and learn it well. Once you get into serious programming you will realize how beneficial these libraries can be and how much more productive they can make you. Not only are they cross-platform, but once you get into data crunching with large numbers, the math libraries especially will seem like a gift from above.

As a game developer, I've been shocked by how many people don't know about Boost. I've mentioned it to contacts in various game studios and not only is it frequently not used (is licensing or porting it a problem?) but many people haven't even heard of it. This leads me to believe that from a career perspective, it's not actually critical to learn Boost, but from a personal development standpoint, it is definitely vital. :)

Discussed previously: what are the advantages of using the c++ boost libraries.

As for any pre-requisites, you should be familiar with the STL and some experience of templates wouldn't hurt. I'm always amazed at how many C++ programmers don't actually use either the STL or templates.

It's very important, especially as many libraries from Boost are getting into the C++ standard -- by using Boost, you get an early look at how the standard will look like (shared_ptr, anyone?).
Moreover, even if you don't use them, the Boost libraries are very well written and often interesting to look at; they do some really advanced C++.

I feel that boost is such a productivity enhancer that I don't think I would accept a job with a C++ shop not using boost.

A language is a tool. Use it if it helps you accomplish something.
I am so sick of these religions. "Should I use Boost? If I don't use Boost, does that mean I'm not a real C++ programmer? Will other C++ programmers like me?" Please. Any C++ programmer who cares if you use Boost or any other library is a close-minded jerk, and you should have nothing to do with him.
Rather, go find an intelligent, open-minded person who can tell you how Boost and who-knows-what-other library has helped him in his own work. He'll even admit that sometimes you don't need those libraries.
Alternate answer: re-implementing part of Boost or STL yourself is a good way to keep your programming abilities sharp. In other words, a C++ programmer who can't fall back to C because he's without his libraries is a weak programmer.

Boost has rich set of libraries that you get it for free.Get to know what are all the libraries available in boost so that you can use one if there is a need.About learning ,select libraries that are included in c++0X so that you can use it and soon compilers are going to support.About particular library learn it when ever you need.

Judging (scientifically :-) by the huge quantity of questions on SO about C++ which have top-rated answers along the lines of "Use Boost::SomethingOrOther", I would say it's very important.
The thing that drew me from C to Java instead of C++, was the huge quantity of supplied classes in Java. Boost almost manages to convince me to go back, except for the fact that I'm now heavily mired in web services where Java is the lingua franca.

Please remember boost is just a set of libraries which can be used to improve productivity (stop reinventing the wheel).
They are, by all accounts, well written and use techniques that you might not (i.e. defintely won't) think up by yourself. If your intention is to look through the source to learn advanced c++ techniques then knock yourself out but I think I'd buy a good book instead.
On the other hand, if you just want to use some library functions to improve your productivity consider your options. What are you developing and so what sort of libraries do you need?
Our company has cross platform products that use boost extensively but we also have windows only products that use some boost but, for the most part, rely on microsoft's libraries. MS libraries are good quality and have (imo) excellent documentation (part of MS success lies in making windows as easy to program as possible for third party developers). I mention MS specifically as they offer a broad range of libraries for many purposes like boost. We also use numerous other more focused 3rd party libraries (i.e. libraries that provide functionality in one area such as cryptography).

Related

Why do people seem to insinuate I would rather not use Boost? [closed]

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 7 years ago.
Improve this question
Very often here on SO I see notes about boost such as
If you are fine with using Boost...
or
If you can use Boost...
And I wonder, what's that all about? What should I be weary of? When can't I use boost? What are the reasons not to use boost? In my opinion boost is a great extension to STL; sometimes very heavyweight and clumsy, but great nevertheless.
I am not really asking for opinions about boost as such. I am rather looking for some concrete examples when should I think twice before using boost.
When I can't use boost? In my opinion boost is great extension to STL,
sometimes very heavyweight and clumsy, but great nevertheless.
Boost is not a library but a collection of largely independent libraries of individual quality. With this in mind, and also taking into account that I'm personally a big fan of most of Boost, here are some reasons I can think of for not using certain Boost libraries:
Some Boost libraries are redundant since C++11.
Some libraries are not widely used and thus require expert knowledge in your project which might be expensive to replace when an employee leaves the company.
Company guidelines which developers have to obey more for political than for technical reasons.
You have no guarantee that any Boost library will be continued to be maintained in the future. Standard C++ code written for some compiler today will very likely continue to work fine with a newer compiler by the same vendor 10 years from now, for simple commercial reasons. With Boost, you have to hope that enough competent people will have any interest in long-term maintenance.
No Boost library is documented as extensively, with so much material in countless books and on the internet, as the C++ standard library. Who will support you if you have some really exotic problem with a particular library? Surely with standard C++ your chances of finding people with the same problem (and existing solutions for the problem) are much higher.
Debugging some Boost code can be more difficult than debugging code that uses the standard library.
Because it's not an extension to the C++ Standard Library (nor to the STL, naturally).
It is a third-party distribution, that you must download and install, locally and (for some Boost libraries, if you dynamically link) on the target system. You must manage and document the dependency.
I shan't enumerate all the scenarios in which this is not feasible, but it should be self-evident that you cannot always use non-standard code. Not everybody is working on a platform on which you can simply write yum install boost-devel, write your code and move on. The world of computers goes far beyond commodity desktop PCs.
That being said, most arguments for avoiding Boost are incredibly weak, due to its extreme portability, and the fact that the majority of Boost libraries are header-only (which reduces the packaging overhead significantly).
Seems like a lot of fuzz for nothing
I don't think writing the phrase "if you can use Boost" can be honestly described as "a lot of [fuss]".
Maintenance mostly.
Once you add boost, you have to maintain it. Either get updates (and maintain any changes mandating changes in your code), or freeze the version and fix bugs yourself.
Both are expensive and backloaded costs. For a project with a lifespan measured in decades, such costs are highly important.
In addition to #LightnessRacesInOrbit's point, I'd say there are a few reasons:
Boost has a lot of code in .h and .hpp files, which you need to include in every translation unit (which uses the relevant parts of Boost), and those files are laden with complex and recursive macro use and smart - but again, complex - use of templates. The combination makes your compilation a w-h-o-l-e lot slower.
Boost isn't installed everywhere by default, so it's not always available to you just because C++ and the standard C++ library is.
(A new reason actually) A sizeable fraction of Boost functionality has made it into C++11 (more is in C++14, and still more in C++17). So, by now, there are alternatives in the standard library or even the language itself for part of what Boost offers.

Boost library acceptance in industry

I have seen lots of people suggesting the Boost library on Stack Overflow, so I am also thinking of learning it. But today I came across this link: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Boost
I wanted to know about its acceptance in industry at a broader level. My current company also doesn't allow me to use this so I am confused whether to look into this or not.
Parts of Boost library is currently being accepted into the Standard library for C++0x and it is regarded as one of the top libs with a high industry acceptance. I'm actually unaware of any other library getting accepted into the C++ Standard Library on such a large scale.
"Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2."
You should definately look into this. Don't go by Google or any other large institution. They generally have to work to a subset of any complex language like C++. Hence, they'll have restrictions on which parts they can use so that it's easier to hire and train engineers to use the code base.
Additionally, Boost leverages many aspects of the higher forms of functionality within C++, case in point template meta-programming. Boost provides for a safer, though bulkier, form of functions as first class objects. They add in a more powerful "bind" which works so well with the standard library that I'd be lost without it. Finally, they have in place tuples and hash tables, both fundamental datatypes in modern development libraries.
In short, I really can't name one reason why you wouldn't want to look at Boost, even just to learn something. It's peer reviewed and largely platform independent. The source code is a treasure trove of information and more advanced programming techniques.
I think the who is using boost web page speaks for itself. Notably: Adobe, McAfee, and Real Networks probably qualify as industry.
My current company also does not allow me
to use [boost]. So I am confused whether
to look into it or not.
You might want to dig a little further and find out why. As others have said, Boost is a fantastically useful set of open source and peer reviewed libraries of extremely high quality. Look at their development LOC chart for an idea how long and how much $$ it would cost your company to reinvent the wheel.

C++ for the C# Programmer [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have a good understanding of OO from java and C# and I'm lucky in my engineering courses to have been exposed to the evils of both assembler and C (pointers are my playground :D ).
However, I've tried looking into C++ and the thing that gets me is the library code. There are so many nice examples of how to perform the bread and butter tasks in java and C#, but I've not been able to find a good explanation of how to do these things in C++.
I'd love to expand my knowledge into C++ to add to my skillset but I've not had a chance to be exposed to people and communities that are keen on these things.
Could anyone here recommend some good open source projects or tutorials which are useful. Bonus marks if they involve coming from java or C# into this environment.
I'd suggest that you work your way through the excellent Andrew Koenig and Barbara Moo book "Accelerated C++" (sanitised Amazon link). This book teaches you C++ rather than assume that you know C and then look at the C++ bits bolted on.
In fact, you dive in and are using STL containers in the early chapters.
Highly recommended.
As well as the other answers here, I think you should take a look at the QT toolkit. Not only does it have GUI widgets, it also has libraries to work with things like databases, multithreading and sockets.
A combination of BOOST and QT, IMHO, provides you with the tools to address in C++ any problem you might be faced with.
I don't have any such resources for you, unfortunately, as I took the long way of slowly discovering things piece by piece.
I do have a caveat for you, though: keep in mind that in the C++ world, the standard library has been very slow at providing useful services. Basically, you'll find a few algorithms, data structures, a few string-related classes and some basic I/O-related ones. Unlike Java or .Net, there is not an extended library of classes for all kinds of purposes (networking, file system services, cryptography, concurrency, etc) - the closest to that is probably Boost, which looks and feels like an extension to the standard library, but which is still external (although some parts of it are leaking back to the standard library).
It's worth bearing in mind that C++ is primarily a systems programming language. Thus its main emphasis is not on performing bread & butter tasks but on writing the tools that are used to perform those tasks. For example, rather than supplying database access libraries out of the box, C++ is intended to be used for writing the database engine itself.
Assuming you already have some knowledge of the C++ syntax, and have good Object Oriented experience I'd go for Effective c++ series.
It's a collection of "tips and tricks" explaining how c++ works under the hood. Which are the common misunderstandings from people coming from other languages and why c++ works this way.
It depends what platform you are programming on. C++ itself doesn't have the same sort of library that Java or C# have. That sort of functionality is traditionally supplied by the operating system. I suggest you learn C++ from a book (I like C++ Primer by Lippman but it may be a bit slow as its aimed at beginners) and then head to MSDN if you are programming on Windows. There are APIs for networking, XML parsing, encryption, just about everything you need. They are just tied to the OS instead of the language itself.
I don't know the equivalent resources for Linux or the Mac but I'm sure someone can supply them.

ACE vs Boost vs POCO [closed]

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.

What are the advantages of using the C++ Boost libraries? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
So, I've been reading through and it appears that the Boost libraries get used a lot in practice (not at my shop, though). Why is this? and what makes it so wonderful?
Boost is used so extensively because:
It is open-source and peer-reviewed.
It provides a wide range of platform agnostic functionality that STL missed.
It is a complement to STL rather than a replacement.
Many of Boost developers are on the C++ standard committee. In fact, many parts of Boost is considered to be included in the next C++ standard library.
It is documented nicely.
Its license allows inclusion in open-source and closed-source projects.
Its features are not usually dependent on each other so you can link only the parts you require. [Luc Hermitte's comment]
From the home page:
"...one of the most highly regarded and expertly designed C++ library projects in the world."
— Herb Sutter and Andrei Alexandrescu, C++ Coding Standards
"Item 55: Familiarize yourself with Boost."
— Scott Meyers, Effective C++, 3rd Ed.
"The obvious solution for most programmers is to use a library that provides an elegant and efficient platform independent to needed services. Examples are BOOST..."
— Bjarne Stroustrup, Abstraction, libraries, and efficiency in C++
So, it's a range of widely used and accepted libraries, but why would you need it?
If you need:
regex
function binding
lambda functions
unit tests
smart pointers
noncopyable, optional
serialization
generic dates
portable filesystem
circular buffers
config utils
generic image library
TR1
threads
uBLAS
and more when you code in C++, have a look at Boost.
Because they add many missing things to the standard library, so much so some of them are getting included in the standard.
Boost people are not lying:
Why should an organization use Boost?
In a word, Productivity. Use of
high-quality libraries like Boost
speeds initial development, results in
fewer bugs, reduces
reinvention-of-the-wheel, and cuts
long-term maintenance costs. And since
Boost libraries tend to become de
facto or de jure standards, many
programmers are already familiar with
them.
Ten of the Boost libraries are
included in the C++ Standard Library's
TR1, and so are slated for later full
standardization. More Boost libraries
are in the pipeline for TR2. Using
Boost libraries gives an organization
a head-start in adopting new
technologies.
Many organization already use programs
implemented with Boost, like Adobe
Acrobat Reader 7.0.
A few Boost classes are very useful (shared_ptr), but I think they went a bit nuts with traits and concepts in Boost. Compile times and huge binary sizes are completely insane with Boost, as is the case with any template-heavy code. There has to be a balance. I'm not sure if Boost has found it.
It adds libraries that allow for a more modern approach to C++ programming.
In my experience many C++ programmers are really the early 1990s C++ programmers, pretty much writing C++ classes, not a lot of use of generics. The more modern approach uses generics to compose software together in manner thats more like dynamic languages, yet you still get type checking / performance in the end. It is a little bit ugly to look at. But once you get over the syntax issues it really is quite nice. Boost gives you a lot of the tools you need to compose stuff easily. smart pointers, functions, lambdas, bindings, etc. Then there are boost libraries which exploit this newer way of writing C++ to provide things like networking, regex, etc etc...
if you are writing lots of for loops, or hand rolling function objects, or doing memory management, then you definitely should check boost out.
BOOST's a collection of libraries filling needs common to many C++ projects. Generally, they do prioritise correctness, reusability, portability, run-time performance, and space-efficiency over readability of BOOST implementation code, or sometimes compile times. They tend not to cover complete high-level functional requirements (e.g. application frameworks), and instead (thankfully) offer building blocks that can be more freely combined without dictating or dominating the application design.
The important reasons to consider using BOOST include:
most libraries are pretty well tested and designed: they generally get a reasonably sound review by some excellent programmers, compared to by people with home-brew solutions in the same problem space, and widely used enough to gather extensive real-world feedback
it's already written and your solution probably isn't
it's pretty portable (but that varies per library)
more people in the C++ community will have a head-start in helping you with your code
BOOST is often a proving ground for introduction to the C++ Standard, so you'll have less work to do in rewriting your code to be compatible with future Standards sans BOOST
due to the community demand, compiler vendors are more likely to test and react to issues of correctness with BOOST usage
familiarity with boost libraries will help you do similar work on other projects, possibly in other companies, where whatever code you might write now might not be available for reuse
The libraries are described in a line or two here: http://www.boost.org/doc/libs/.
Because the C++ standard library isn't all that complete.
Boost basically the synopsis of what the Standard will become, besides with all the peer review and usage that Boost gets you can be pretty sure your getting quite a good deal for your dependencies.
However most shops don't use Boost, because its an External Dependency. And in reality reducing External dependencies is very important as well.
Anything with Kevlin Henney's involvement should be taken note of.
Boost is to C++ sort of like .NET Framework is to C#, but maybe on a smaller scale.
I use the filesystem library quit a bit, and the boost::shared_ptr is pretty nifty. I hear it does other things too.