5 ms·

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 atri

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=boost https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

herewego 11y ago
As another data point, I don't find the Boost dependency an issue at all. Boost libs are just so useful...
eigenbom 11y ago
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.
to3m 11y ago
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...
- tacos 11y ago
  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.
  - SamReidHughes 11y ago
    How complicated are these command line apps?
    - tacos 11y ago
      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.
  - enqk 11y ago
    20 seconds is not particularly impressive..
    - tacos 11y ago
      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.
lookbothways 11y ago
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.
BudVVeezer 11y ago
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).
eric_bullington 11y ago
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.
mratzloff 11y ago
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.
chetanahuja 11y ago
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
RotsiserMho 11y ago
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.
rburhum 11y ago
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.

herewego 11y ago

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

eigenbom 11y ago

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.

to3m 11y ago

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

tacos 11y ago
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.
- SamReidHughes 11y ago
  How complicated are these command line apps?
  - tacos 11y ago
    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.
- enqk 11y ago
  20 seconds is not particularly impressive..
  - tacos 11y ago
    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.

lookbothways 11y ago

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.

BudVVeezer 11y ago

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

eric_bullington 11y ago

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.

mratzloff 11y ago

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.

chetanahuja 11y ago

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

RotsiserMho 11y ago

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.

rburhum 11y ago

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.