>> I see that boost is not used. Is it deliberate? These are c++03 >> libraries and most of them have been the source of the new standard. > > "source of standard" means that they are liable to change particularly > in the course of becoming part of a standard.
I use boost every day for my professional work. It really saves me a lot of time because of not reinventing the wheel and because the libraries are really high quality. I have my-self contributed to an extension of the type traits library to operators and I can share my experience: the final library after the review process was really much better than what I submitted first. The fact that many boost libraries are now part of the standard is really the sign it is high standard. And they really target to be cross-platform. For example, would you want to make lilypond use multi-core CPU, just use boost::thread, it will work on all platforms and when you are ready to switch to c++11, just replace boost::thread by std::thread. Of course, you are right in saying that adding a new dependency means tracking compatibility issues when the dependencies are updated. For example, boost::filesystem which is not part of the new standard had a new version a few years ago and this meant for me changing my code in several places. But is this worse than maintaining what is done elsewhere? Some examples of why boost could be useful: - I see for example that lilypond uses std::map. Do all those map objects need to be sorted by their key? If not, we could use boost::unordered_map part of the new standard which is implemented as a hash table with more efficient access. - I see also some set<Grob *>. I do not imagine that we need to keep these sets sorted by Grob address? Again boost::unorderded_set could maybe match better with performance gain. - I find lexical_cast very useful (conversion between numeric and string types in both directions) example: int k=boost::lexical_cast<int>(mystring); - I find string algorithms very useful (trimming, finding, replacing) example: boost::algorithm::replace_all(mystring, search, replace); boost::algorithm::trim_copy(string_with_spaces); - I find regex (part of the new standard) very useful, you know what regex are - I use boost::thread (very easy multithreading) >> They are pretty well supported by distributions and work on windows, >> mac, linux. > > They are also humongous, which means a quite larger amount of work for > GUB. Personnaly, I build code at work for windows and linux with the same source using boost. I do not know for other distributions but on Fedora, boost comes also for mingw32 and mingw64. But I do not know at all GUB and I am sure things are not easy to change (I have the same issue of maintaining a build tool chain for multiple targets) so I understand you point. > I had taken a look previously at CGAL <URL:http://www.cgal.org/> since > the kind of stuff we are doing with skylines would benefit from > ready-made code like > <URL:http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Envelope_2/Chapter_main.html> > and frankly, doing things like computational geometry tasks is > a) a resource drain > b) a source for problems It seems that cgal makes more than boost::geometry that cannot compute convex hull of curves. > We have very few high-quality developers with significant resources for > working on LilyPond, and minimal peer review. As a result, any > particularly complex task is very likely to be implemented in a quite > suboptimal and underdocumented manner and with code paths that rarely > receive proper attentation before they make things blow up. The > probability that some envelope-finding code dropped into LilyPond by a > typical LilyPond contributor is close to the quality of somebody who > wrote a Phd thesis focused around the topic is slim. I understand that using external libraries would then help the maintenance? Frédéric _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
