Hacker News Reader

Comment by eps | Hacker News Reader

One thing to keep in mind is that there are C++ devs who like Boost and there are C++ devs who hate Boost with passion. There are also said to be devs who are merely OK with this abomination but they are more of an urban legend really.

In other words, consider the fact that by throwing Boost in the mix, you rob yourself a good half of the intended audience, if not more.

View on HN

I guess I belong to the "urban legend" category then.

I never introduced Boost into my projects, but when one of the co-developers on an open source project where I am the lead (FlameRobin.org) said it would be useful, and explained what problems it would solve, I just said "ok". IIRC, this was circa 2007.

All those complaining about compile times should learn about PCH (pre-compiled headers). It's fairly simple and makes sure headers are compiled only once (unless they change). AFAIK, all modern compilers support PCH (GCC, MSVC, even Borland's).

Devs who happily use C++ yet balk at spending a day to get a large third party library integrated into their build are a curious bunch.

C++ devs are a curious bunch :-)

Fixing a build can be pretty torturous though. My main thought when I'm looking at using a library in C++ is "oh god I hope this isn't a pain to build"

Why do you think it's only "a day." Also, you are forever introducing a dependency in your build chain, codebase, and executable. EVERY 3rd party dependency should be audited as such (performance, security, usability, etc). Boost is no exception, but for the amount of things it comes with (often), and the strain on the compiler requirements it produces, it is typically included as a last resort.

I should mention, people who talk without much context are a curious bunch too.

Yes there is always a balance of concerns. Build management with 3rd party deps is not trivial but its part of the lifecycle. In my experience boost integration really is "a day" on windows (including stashing the .libs as their own repo and reproducing a fresh 'git clone' build), and 10 minutes on a platform that you can use the package manager to obtain it. You can always excise it from a project later if you dont abuse 'using' statements. FWIW, I only really use variant and ASIO.

If you were adding boost to a project just to do some weird spirit/preprocessor hacks, I'd be wary. But if you told me you were going to write yet another cross platform ASIO wrapper because you couldn't figure out how to compile boost I'd be even more concerned.

I think the strawman here is that people are wary of adding boost because they are afraid of compiling it. Where did you get that idea from?

It has nothing to do with the integration difficulties.

Many ++ devs, me included, come from the C background and the amount of obfuscation Boost adds to the code is simply not worth any benefits it brings along. Yes, you can do a lot with a single line of Boost'ed code, but when it maps onto pages of simpler code, you basically lose a lot of control over the code. It also bloats the binary, which again may not even register as a viable concern with some, but which does have several long-reaching complications.

That's fair. C devs are also a little more used to being tied to specific OS facilities such kqueue/select. For me boost shines as an ASIO implementation. When that becomes stdlib, I'm not sure I would be compelled to use it.

This is along the lines of the traditional abstraction level debates, rather than anything particularly wrong with boost. I think it gets singled out unfairly as being a particularly difficult 3rd party library.

Reply on news.ycombinator.com