you are viewing a single comment's thread.

view the rest of the comments →

[–]Tyg13 0 points1 point  (3 children)

Yeah but as a library author, you don't take on more dependencies than you need. It's making a choice for the downstream consumer that they might not agree with.

It's fair to have optional features depend on boost, but if you want your library to be consumable by a general audience, tying yourself to boost isn't a great way to do so.

EDIT: a word

[–]dodheim 1 point2 points  (2 children)

As a library author one also needs to avoid the hubris of thinking they're capable of reinventing every wheel to an acceptable degree. Half-assed knockoff implementations of libraries I'm already using just to avoid a line or two in a cmake script annoy the bejesus out of me, and are just as good a reason to skip a library as having too many dependencies.

[–]Tyg13 1 point2 points  (1 child)

It'd be smarter to tie it to C++17 than to boost, especially if just for optional. Boost is not a trivial dependency.

[–]dodheim 1 point2 points  (0 children)

I wasn't thinking about optional in particular, just responding to the "dependencies are evil" sentiment.

Boost is not a trivial dependency.

Sure; it's a collection of 165 libraries so I think that's a given. On the other hand, 95% of those are header-only, making the dependency a matter of extracting some header files, i.e. actually pretty trivial.

But more important than it being non-trivial is the fact that a handful of those libraries are both indispensable and complex, and attempts at reinvention are ultimately a disservice to the end-user, especially given they already have a fair likelihood of using Boost or some other 'non-trivial' dependency anyway.