Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should I become proficient with STL libraries before learning BOOST alternatives?

Tags:

c++

stl

boost

Does it make sense to restrict yourself to the STL libraries when learning C++ and then tackle boost and its additions after you have become fairly proficient with vanilla C++?

Or should you dive right into BOOST while learning C++?

like image 412
KingNestor Avatar asked Feb 14 '09 08:02

KingNestor


People also ask

Is Boost better than STL?

Ultimately, you should learn both. But STL can be learned in isolation, whereas boost won't make much sense until you understand the STL, since that's what Boost is modeled on, and designed to extend. So learn to use the STL as part of learning c++.

Is Boost library still useful?

After 20 years of active Boost development, it's now recognized as a very powerful C++ library, for each major version many C++ libraries from the community were added. The Boost reviewers have an advanced C++ skills and their contributions guarantee a high quality for many years.

Is using STL good?

No, just that there doesn't exist a data structure/algorithm in the STL to correctly solve every problem you can come up with. If your problem is such that you can't find a way to couch it in terms of the STL, writing your own code might be the only option.


2 Answers

The STL has some core concepts to it. Boost builds on and expands on them. If you understand them, then moving right on to Boost may be of use to you. If not, I would start with the STL.

  • The distinction between the various container types (sequences like vector, list and deque, and associations like map, set and their multi* and unordered_* varieties). Sometimes you can swap one for the other -- sometimes you can't. Know their strengths and their limits.
  • The role of iterators, and how they provide a bridge between containers and algorithms. (This one I find I use over and over).
  • Why there are standard algorithms: they are often tiny amounts of code, so it may not be obvious why they exist. Learn which containers they work with, and how to specialize them for particular cases (for example see how generic copy differs from copy specialized for const char *).
  • How and when traits classes are used.
  • How to use binders (bind1st, ptr_fun and mem_fun): the syntax can obscure their utility.
  • How to use string -- and when not to use it. (All string classes have tradeoffs: learning the pros and cons of the standard one is educational).
  • The difference between streams and streambufs: how to use the former to do formatted I/O (try reading a string from a stream: it's not as straightforward as it should be), and the latter to do low-level fast I/O.

The principles used to design the STL are built upon and expanded on by the Boost libraries. If you get them, Boost is manageable. If you don't, and Boost ends up hard to follow, you can go back to the STL to get your bearings.

(In general Boost really pushes the boundaries of the language. If you decide you want to really push your own knowledge of C++, and test if you really know what you think you know then it can provide an interesting challenge. I've used C++ for more than a dozen years, have taught other people how to use it, have acquired proficiency in many more high-level languages since then and Boost still surprises me. It's very useful, but its not trivial).

like image 154
quark Avatar answered Oct 08 '22 11:10

quark


I'd suggest getting a clear handle on STL, before looking at Boost. Boost is meant to build on top of STL and many of the libraries are slated to become part of the standard library eventually. Boost libraries are generally less mature and less standard than STL. Also, many boost libraries go too far, in my opinion, adding "features" that don't natively exist in C++ (leading to really insane syntax). In many cases there are more sane C++ idioms available for solving most programming problems without using these arcane Boost libraries.

like image 43
postfuturist Avatar answered Oct 08 '22 12:10

postfuturist