lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: upgrade to c++11


From: Frédéric Bron
Subject: Re: upgrade to c++11
Date: Sun, 14 Jul 2013 22:41:56 +0200

>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]