Atria: A toolkit for modern C++ development from Ableton

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

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'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...

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).

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.

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.

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

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.

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.

From the popular (in game development circles, at least) stb libraries:

>Why single-file headers?

>Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)

>There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.

>Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)

>Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.

https://github.com/nothings/stb/

The biggest value is that you don't have a link-time dependency, only compile-time. This means that you don't have to concern yourself with a lot of the versioning problems that plague C++ application deployment simply because your dependency is compiled into the binary.