In the case of threading libraries, Boost.Thread was written by Anthony Williams, who literally wrote the book (and many parts of the Standard) on C++11 threading. I don't think many people can write parallel code themselves better than he canmar wrote:But quite the contrary! It's actually a HUGE win.Rein Halbersma wrote:But the Do It Yourself attitude will lose in the long run.
Those libraries you talk about were written by someone and that someone did it himself (themselves).
Well about the entire world of GitHub / SourceForge etc., you are absolutely right. But there are some high-quality libraries (Boost, POCO, Folly) that will be much better than I could ever write myself. And furthermore, because these libraries are so popular, they get tested extremely intensively, so that any remaining bugs are found and fixed much quicker than in your own code.How many times did you get a buggy new library version here and there (being afraid and reverting to old version), tons of warnings, how long did it take you to seamlessly integrate some third-party library?
Wait it won't compile on that platform, I have to wait for a new version...
Or they just completely revamped the whole interface, nice
So in the end you spend more time twiddling with third party code than writing your own.
If you ever ran into problems with third-party libraries (like zlib reading uninitialized memory etc. - but hey it's ok, they say, it's for performance reasons , you know what I'm talking about.
Re: depencies. I decided very early on in my draughts project to treat Boost as a kind of pre-Standard Library. So I feel free to use almost everything from Boost (apart from the really scary stuff that I don't understand 100%, such as Proto, Fusion, Xpressive, Spirt etc.).I'm not talking about writing your own operating system or compiler (I'm not that crazy - but there are people out there who could do that).
I'm talking about thinking carefully about how much dependencies you drag into your (very small if it's a chess engine) project.
The actual Boost dependencies are quite small, however. I just did a check and it's mostly Iterator, Range and Operators to get nice classes and algorithms quickly, a little bit of MPL / TTI (used to much more, with C++14 constexpr there are better alternatives) to do some compile-time magic, and a lot of Test for my unit testing.
At the application level, I use Boost.Accumulators which is a real nice way of collecting search statistics without having to write your own boilerplate. I'm experimenting with Log, FileSystem and Asio (which are both likely to be standardized in C++17) to add logging, file I/O for tablebases and networking.
This is a matter of taste of course, and I respect yours I actually appreciate high-quality low-level stuff as well, but I prefer to code at the domain-level, to put in AI knowledge and think about the general structure of algorithms, and to let libraries give me the high-quality implementation of those ideas.Last thing, what do you enjoy more? Programming or gluing third-party/middleware stuff together? I prefer the former.
E.g., I really hate the current std::thread low-levelness, and I would much prefer to just express the potential parallelism of an algorithm such as with the Cilk-style spawn keyword. Such a declarative programming style is only possible with a taks-based concurrency library that will take care of load-balancing and work-stealing behind my back. They are coming in C++17 hopefully. It's my private theory that algorithms like DTS are just a very low-level and intricate way of reimplementing optimal load-balancing schedulers that can be much easier created with work-stealing library frameworks like Cilk.