Please, keep Glib usage to platform abstraction only, not for fluidsynth logic / algorithm. I have no issues with C++. In the future it could even make the code more maintainable, as alot of the current C functions belongs to one domain object or another.
On Wed, Jan 22, 2020 at 8:04 AM Tom M. via fluid-dev <fluid-dev@nongnu.org> wrote: > Carlo, the reason I would like to use C++ is that I want to maximize > the performance of fluidsynth. Particularly, the sequencers event > queue, which currently blocks rendering for several seconds when > processing a few ten-thousand events (taken from highly polyphonic, > automated MIDI files). See this mail for some real measurements: > > https://lists.nongnu.org/archive/html/fluid-dev/2019-12/msg00003.html > > The performance gain is achieved by using heap sort and std::deque for > fast appending of new elements (i.e. events). Which is exactly the > need provided by C++. > > So, I'm sorry, but your argument does not convince me. > > And, unlike the Linux Kernel, we cannot afford (re-)implementing and > maintaining our own sorting algorithms in C: > > https://github.com/torvalds/linux/blob/master/lib/sort.c > > The alternative to C++ as I learned recently, would be to use GQueue, > provided by gmodule. This does not provide heap sort and (according to > the documentation) is not as smart as std::deque. And it would tighten > the glib dependency even more. All in all, this makes it a worse > solution IMO. > > > Tom > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
