You're talking about compile time and issues with your IDE. It is unfair to call it "Not high quality". We can think about this from an end-user standpoint that it bloats the IDE and impacts usability. Fine. Your IDE/compile times may be different than others.

Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose. Please don't conflate your minor development environment gripes with the excellence of Boost. It is really not fair.

I don't think it's an unfair complaint. Developers interface with the language using compilers and IDEs, and until recently (with libclang getting more popular) that interface has been terrible. In a lot of cases it's still terrible. It's a real inconvenience, and there's no benefit coming with the cost.

> Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose.

I've used Boost for over a decade now, and IMO "extremely high quality" is a stretch. Some modules are better than others, but there's no getting around the fact that many of them are only necessary because the C++ standard library is so bad.

I am having a hard time conciling compile times as a complaint. That is a compiler problem. Or an inevitable problem as the project grows.

I don’t understand how that is a problem with Boost.

Same thing with the IDE. If you add an external library such as Boost, it is natural that your intellisense or whatever IDE feature may get slower.

Both of these are undisputably an issue with the environment as a whole. How on the earth is it a quality problem with Boost!? Please explain.

Not OP but - Boost is a large library that can be tricky to extract only the portions you want from, leading to instances where you compile a lot of unwanted code, leading to ballooning compile times in exchange for only a little bit of extra functionality that you want. In my experience boost typically ends up being all or nothing, and very hard to remove once integrated.

Has been terrible? IMHO (eclipse and clion user) for C++ big projects the IDE experience is terrible! Vim isn't better as you need to spend a lot of time configuring it plus ctags and multiple tabs doesn't work well together..

Your viewpoint is valid.

But so is the viewpoint that one of the major problems with C++ culture is the misconception that developer experience and high quality tooling are afterthoughts and orthogonal to "quality". In this viewpoint, readability in a editor or IDE at least as important as readability in a browser or email.

I agree that C++ is a big mess.

Complaining about an external third party library that is trying to fix the issues for its compile time and how fast it loads IDE is very obtuse and unfair. Boost is a bandaid. Don't complain about the bandaid, complain about what causes the wound. Overall, I agree with you that C++ has poor user-experience - don't blame Boost for it!

To be fair, it is very common to hear "well, why don't you just use Boost?" in response to the criticism of the C++ standard library. It may be an external third party library in name, but in practice it has long since became stdlib++ for idiomatic C++, and a testing ground for new libraries to be eventually adopted into the standard.

> There's no consistent feeling to the library

Well that's because it is really a collection of mostly unrelated libraries by a large number of different authors.

There is some general theme (emphasis on value based generic programming in the stl style as opposed to more traditional Oop), but that's about it.

Finally! It's not just me.

But...I will say some good ideas made it into the standard thanks to a first implementation in boost, though what ended up being standardized is typically much cleaner and more orthogonal.

Then again this is how we got the standard containers and so much more standard library goodness -- via Stepanov stepping up and writing the STL.

The best way to think of boost as the npm.

> boost is not high quality

This is just false.

You could be right. But this is not a convincing rebuttal.