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?
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.
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.
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.
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.
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
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.
How does header-only versus header+impl file have anything to do with deploying libraries? Versus a separate header + DLL, sure. But having an impl file isn't gonna matter if you link it all in. This sounds more like a source-vs-bin issue. What am I missing?
Worth noting that only the first two points there are relevant here, since these are not single file libraries. Also, the STB libraries work massively differently from C++ header only libs (#define STB_FOO_IMPLEMENTATION, for example).
Also, fwiw Sean Barrett also has gone on record as saying that he's not really a fan of C++ before. I'm struggling to find a specific link, but it's not really a secret.
(As a side note, to anybody who is in the need for what they do, the STB libraries are really absurdly high quality and can do exactly what you want them to 99% of the time. Highly recommend!!)
> Windows doesn't have standard directories where libraries live.
Visual Studio certainly does:
Microsoft Visual Studio 11.0\VC\include
Many people argue don't put libraries there - well then you are back to the original problem. Just as long as you don't overwrite a provided library - there are no issues. And if you do overwrite it - you get a rolled up newspaper and start beating the person who overwrote it.
It's a different directory for every version of Visual Studio (and obviously mingw doesn't use it), ergo it's not a standard directory like /usr/include
His point is that it's arguably simpler to tell people to copy a single source file to their project's source tree, than it is to help them find the include dir for whatever compiler they happen to be using. And that it's probably easier to have to manually update this file when the library is patched, than it is to coordinate manual library updates across an entire team without the use of a package manager.
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.
The novel part here is transducers and the funken package built on top of them, right? What are they used for, in your applications? The documentation is really terse and could use a few examples.
Yep, sorry about the state of the docs... hopefully it will improve over time. As the `status` section highlights, a lot of the stuff here is very green, but we wanted to open-source early and polish it along the way instead of waiting until everything is "done" ("done" doesn't make sense for an OSS project anywayzzz :-)
There will be a tutorial on the transducers stuff coming up at some point. That is the part that is under more active development indeed. We will also talk about that at CppCon next September.
