Hacker News Reader

Comment by arximboldi | Hacker News Reader

Interesting...

There are not many parts depending on boost and we could make it entirely optional [1] (it would be still be nice for people wanting to use atria::variant::match in combo with boost::variant, optionally).

Could you elaborate on why boost is a total no-go for you?

https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

View on HN

I'm not the same person, but I don't use boost, and I avoid projects that depend on it, because every time I've used boost in the past it's always done dreadful things to the build time.

Anything that uses boost always seems to compile at a glacial pace and then takes aeons to link. It's also not much fun in the debugger, should you happen upon it in a call stack or see one of its types in the watch window - but build times are the more serious problem. C++ projects always seem to suffer from appalling iteration times, but boost just seems to make things worse...

You have to be careful with what you pull in. But with precompiled headers I'm building a suite of 25 command line apps, all dependent on boost, in 22 seconds on a 2012 MacBook Air. gcc on Windows is similar.

Microsoft doesn't even let you share precompiled headers across projects, but it's still building in under 20 seconds.

There's a LOT of really idiotic C++ build scripts out there. I really don't know what some people are thinking.

How complicated are these command line apps?

400-600k with symbols stripped.

I'm using boost/any, boost/iostreams/stream & tee, and boost/property_tree/json_parser. So obviously I'm not going nuts with things. But wanted to provide the data point.

20 seconds is not particularly impressive..

Neither is the hardware. The point is that I'm doing a clean build of an entire app in under a second. Which means the "boost tax" is also under a second.

You can certainly make a mess of things if you're not careful. Most people seem to.

Most C and C++ programmers I know hate dragging in large dependencies (increase in build and runtime complexity, code size, "can I debug this if I have a problem," etc), and would consider a library depending on Boost to be a red flag at best, or a deal breaker at worst.

Boost is a very large project with varying degrees of API quality, and so when you say it depends on boost, I wonder "the good parts (any, variant, stuff that usually gets looked at for standardization)" or "the bad parts (Spirit, etc)". Also, as others have said, it's a huge dependency that generally raise a red flag (for performance and compile time).

Your library looks pretty neat, but I have an aversion to boost too. I love that c++ is slowly absorbing the best bits so I can detach myself from it -- it's a great library but is just so monolithic. And whenever I need a non-header-only library from it I always seem to struggle through the windows b2/bjam/whatever process to build them.

Minor: there are a few mistakes on the landing page: 'welcome', 'implementation', etc.

I have used boost for several big projects with an extended code base and it always creates various issues with the build. If you use it extensively, you will realize that certain parts are not header only; you will need to link it with libraries (think threads or filesystem libraries).

I use C++ for portability accross several platforms and boost always seems to have a completely different naming convention in each platform. Upgrading between versions e.g. 1.48 to 1.51 will very likely require code changes since it is not uncommon to break API contracts across versions.

I have amazing C++ developers with decades of experience that would quit on the spot if I forced them to use boost - and I wouldnt blame them.

I can rant forever.

New versions of C++ have things that used to make boost essential, but now that later C++ standards support lots of those concepts, I am happily boost-free. Boost is a huge negative, so you would need to be really amazing for me to even consider bringing back a dependency that has only brought me so much pain in the past.

In my opinion, Boost should only ever be a dependency for end-user applications, never libraries, unless the library is specifically aimed at Boost users.

I would just like to say that I love boost. I believe it leads credibility to a project such as this to know that the wheel wasn't reinvented. I seriously don't understand why there's such an aversion to it. Most of it is header-only and the especially useful bits are tiny.

As another data point, I don't find the Boost dependency an issue at all. Boost libs are just so useful...

I think making Boost optional would be a big win for you and your project. For one, given the aversion of so many C++ devs to Boost, removing Boost would probably result in more contributors. But most importantly, it would make life much easier for anyone who wanted to use the toolkit.

Adding my vote to the anti-boost camp. The library is huge and is pretty much an all or nothing affair. The gp's point about header-only and depending on boost being complete polar opposite characteristics is on point

Reply on news.ycombinator.com