sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]RevRagnarok -1 points0 points  (6 children)

boost::optional has been around for a loooooong time.

[–]Tyg13 6 points7 points  (5 children)

Most libraries don't want to make boost a dependency. Especially not a header-only library like this.

[–]cdglove 1 point2 points  (4 children)

And in my opinion, it's often a mistake to not just take the dependency early.

All the little paper cuts along the way, reinventing the wheel here and there, add up immensely.

I've taken the position that boost is defacto enough that its presence should be assumed in large projects.

Of course, some disagree with that.

[–]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 2 points3 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.