Knut Petersen <knup...@gmail.com> writes: >> Knut, if you read this message via the mailing list, please try to find >> out why my messages don't reach you. > > T-online.de email addresses seem to become more and more > obsolete. hotmail.com and outlook.com block t-online, you get blocked > by t-online. lkml blocked t-online about 8 years ago. > > I changed my lilydevel subscription to knup...@gmail.com. AFAICS > administrators seem to hesitate to block gmail.com as it is big enough > to be important ;-) > > Yes, cairomm was a bad idea. Using cairo directly (and staying with > c++11) isn't a problem.
The problem with C++ (and also Guile) wrapper libraries is that LilyPond marries C++ and Guile data structures in a rather special way. And pulling more frameworks in can get messy because their design and assumptions can make their modus operandi a bad fit. That's particularly a danger when new language features are being used. The mantra bringing C++ into existence was object orientation and encapsulation while maintaining C's efficiency. The proliferation of the language has clawed onto efficiency, but particularly reuse of code has not turned out to be much of a thing: perhaps the strongest example for code in general use is the STL, and its code base is utter specialist gibberish rather than written in what a standard programmer would come up with: reusable code bases have turned out opaque in more than just the CS sense. In a way that is a reason why after 50+ years numerical libraries in Fortran still have an impact, partly with C++ and other language wrappers around them: Fortran has native multidimensional arrays, and so independent libraries can easily be used, sharing the same data structures, in user programs. "If I've been able to reach far, it's because I've been linking hands with my brethren." And the rather highly efficient numerical code of Fortran libraries is readable (if ugly) and reflects the work of mathematicians rather than code wranglers. For better or worse, existing higher language wrappers (C++ or Guile) tend to result in somewhat awkward fits with the LilyPond code base. I'd say "something's rotten in the state of Denmark", but then Stroustrup has not been a principal driving factor of C++ for quite a while. -- David Kastrup