24 ms·

What do you call "wisdom" that's passed from person to person, so everyone knows it, but it isn't actually true? A huge amount of Boost is nothing but headers.

What do you call "wisdom" that's passed from person to person, so everyone knows it, but it isn't actually true? A huge amount of Boost is nothing but headers. And it's very easy to use those header-only libraries and avoid the rest. Sure, many people have just pulled in the entirety of Boost... but it's really strange to blame Boost for those bad choices. By the way, a lot of what today is standard C++ had its origin in Boost. smart pointers, thread, regex, random, ratio, tuple, etc etc. All came from Boost, and those of us using Boost were happily taking advantage of it, while folks who believe the "wisdom" you just shared were building it yourselves.

andyxor 5y ago
well i've seen it used "enthusiastically" for the lack of better word, i.e. once someone on the team starts using one header, with some relatively well proven and robust feature (like smart pointers), it creates a temptation for them and other team members to use anything else available in that giant library "for free". And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. Since the good parts of Boost are already in STL, i always recommend to just stick with (very minimal set of) STL, don't use what you don't need right now, and avoid the temptation to throw every available library or "neat" feature at a problem (which might save a bit of thinking time short term but open a can of worms long term)
- jcelerier 5y ago
  > And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. how is that better than the usual 2021 project having a package.json with 350 sub-dependencies

andyxor 5y ago

well i've seen it used "enthusiastically" for the lack of better word, i.e. once someone on the team starts using one header, with some relatively well proven and robust feature (like smart pointers), it creates a temptation for them and other team members to use anything else available in that giant library "for free". And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. Since the good parts of Boost are already in STL, i always recommend to just stick with (very minimal set of) STL, don't use what you don't need right now, and avoid the temptation to throw every available library or "neat" feature at a problem (which might save a bit of thinking time short term but open a can of worms long term)

jcelerier 5y ago
> And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. how is that better than the usual 2021 project having a package.json with 350 sub-dependencies