What parts of boost are you using?

Started by
150 comments, last by ChaosEngine 18 years, 4 months ago
I'd like to use more of boost, but it seems like in one way or another there's something about one of the libraries that just doesn't work right. I use the shared pointer and signals libraries but that's about it. I've tried the serialization library, but it was too slow. I've tried the Iostreams library which looks cool but it doesn't support non-blocking or async I/O. Taking a look at the new proposal for the logging library and it just looks like somebody's trash. I was wondering what other parts of boost you guys have given your blessing to.
Advertisement
hmmm...

boost::lexical_cast, boost::function, boost::shared_ptr, boost/cstdint.hpp

I also frequently use a number of stl libraries, for example:

std::string, std::vector, std::map
I haven't had problems with any Boost library. Serialization was the closest, because it's too big for me. In my last project I've used:

-assign
-bind
-format
-function
-mpl
-multi_index
-optional
-random
-serialization
-smart_ptr
-thread
-noncopyable
-variant
IO streams isn't supposed to support async, since it doesn't work very well given the IO Streams model. That should be provided if/when the asio library is included (so far, the review has only been requested, but general comments are pretty positive).

And Torjo's logging library was rejected (actually, he withdrew it). Peer review does work :).

As for what I use? Nearly all of it except uBLAS and Boost.Graph, and few of the other little bits. Not all in one project, of course.
Not much, as it's mostly too complex for my litle needs, I also don't feel like using smart pointers ;)
What I do use:
- bind
- lambda
- program_options
- tuple
Nothing. All the functionality I need I have implemented myself in much simplier manner than what's done in boost and I don't want to have dependency to such a library. When I need to extend, fix or optimize functionality I can do it freely with my "custom boost" and everything fits nicely together. Then again, I don't use stl either because of the same reason.
lexical_cast, random, shared_ptr. To tell you the truth I haven't even explored everything thats included.
In various projects I've used;

- bind
- function
- multi_index
- shared_ptr
- thread
- lexical_cast (which i've used so often its crazy)
- IOStreams
- filesystem
- tokenizer
- date_time

And I've got my eye on varient and a few others for later use.

I would appricate it however if someone could explain what on earth the graph library is all about.. i've a feeling it could be usefull if I just understood what for [grin]
boost::graph is probably one of the more academic boost library functions; someone doing research in the area of system design, networks, or parallel/distributed systems would use a graph data structure to do simulations or numerical computations. Graphs provide a unique advantage here as they are easily representable and operated on in software, yet are rigid, formal mathematical structures about which proofs and algorithms can be written.

Most likely, in production software, I wouldn't be suprised if the particular problem being solved was reduced to some specific form instead of using the generic idea of a graph (and code like boost::graph)
Quote:Original post by krum
Taking a look at the new proposal for the logging library and it just looks like somebody's trash.

Of course, it was rejected in fairly short order. So there you go.

I make use of tuples, multi_array, and the smart pointers. Occasionally lambdas, but not often. In the near future, I'm going to rewrite my core libraries to make use of the random number library.

Honestly, I couldn't do without tuple support anymore...I'm learning C# and miss it quite a bit [sad]

CM

This topic is closed to new replies.

Advertisement