Adding C++ as mandatory dependency?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding C++ as mandatory dependency?

fluid-dev mailing list
The most recent revisal of fluidsynth's sequencer has raised the
question of whether C++98 can become a mandatory dependency for
fluidsynth. Most importantly:

* Can we put C++ code into fluidsynth?
* Is there anybody out there who has any concerns or objections for a
C++ dependency?

A few more question that arise from the above:

* Do we want to port fluidsynth to C++ completely?
* Or should only new code/features be C++, existing C code stays
untouched unless a complete rewrite is required?
* Or do we only want minimal glue code for C++ stdlib features, rest stays C?

Any feedback about that is welcome.

Note that fluidsynth's API is unaffected and stays written in C.

Detailed background information about proposed changes on GitHub:
https://github.com/FluidSynth/fluidsynth/pull/604


**Spoiler:**


Keep in mind that we are only talking about C++98. There is no benefit
in porting fluidsynths entire codebase to C++98 (esp. not in terms of
getting rid of glib). However, for this particular revisal, some
features of the C++ standard library come in handy, allowing a simple
and lightweight implementation.


Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

Reinhold Hoffmann
In general C++ is OK.

I vote to keep existing code stable and not convert it to C++ due to
stability.

From the Microsoft Windows side the key question is
"Which Microsoft Visual Studio version is mandatory for C++98?"  

To me it looks that there is no clear answer when I read their conformance
list at
https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformanc
e?view=vs-2019

Does anybody know the full answer?

Reinhold  

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=[hidden email]]
Im Auftrag von Tom M. via fluid-dev
Gesendet: Freitag, 17. Januar 2020 16:34
An: FluidSynth mailing list
Cc: Tom M.
Betreff: [fluid-dev] Adding C++ as mandatory dependency?

The most recent revisal of fluidsynth's sequencer has raised the
question of whether C++98 can become a mandatory dependency for
fluidsynth. Most importantly:

* Can we put C++ code into fluidsynth?
* Is there anybody out there who has any concerns or objections for a
C++ dependency?

A few more question that arise from the above:

* Do we want to port fluidsynth to C++ completely?
* Or should only new code/features be C++, existing C code stays
untouched unless a complete rewrite is required?
* Or do we only want minimal glue code for C++ stdlib features, rest stays
C?

Any feedback about that is welcome.

Note that fluidsynth's API is unaffected and stays written in C.

Detailed background information about proposed changes on GitHub:
https://github.com/FluidSynth/fluidsynth/pull/604


**Spoiler:**


Keep in mind that we are only talking about C++98. There is no benefit
in porting fluidsynths entire codebase to C++98 (esp. not in terms of
getting rid of glib). However, for this particular revisal, some
features of the C++ standard library come in handy, allowing a simple
and lightweight implementation.


Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev


_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

fluid-dev mailing list
> "Which Microsoft Visual Studio version is mandatory for C++98?"

It's hard to find official documentation for those old products, but
VS2005 (8.0) should be sufficient.


Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

Reinhold Hoffmann
Thanks.

I think that VS2005 is fine.

It is really essential for those who use the fluidsynth code in LGPL
libraries that a very wide range of development environments are supported.


Reinhold

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=[hidden email]]
Im Auftrag von Tom M. via fluid-dev
Gesendet: Freitag, 17. Januar 2020 17:57
An: FluidSynth mailing list
Cc: Tom M.
Betreff: Re: [fluid-dev] Adding C++ as mandatory dependency?

> "Which Microsoft Visual Studio version is mandatory for C++98?"

It's hard to find official documentation for those old products, but
VS2005 (8.0) should be sufficient.


Tom

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev


_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

fluid-dev mailing list
In reply to this post by fluid-dev mailing list
Hello friends and happy new year, although a bit late...
If I can say my opinion, I disagree with the use of C++ code.
From my experience, C++ is not a good idea sometimes, especially when you want to maximize the performance and minimize the memory usage.
You may want to look the code of other important piece of code existing. For example, look the sources of the linux kernel. It is written in pure C and there should be a reason for that.
However, that's just my opionion, I hope that you will find my message useful.

Sincerely.


> Il 17 gennaio 2020 alle 16.34 "Tom M. via fluid-dev" <[hidden email]> ha scritto:
>
>
> The most recent revisal of fluidsynth's sequencer has raised the
> question of whether C++98 can become a mandatory dependency for
> fluidsynth. Most importantly:
>
> * Can we put C++ code into fluidsynth?
> * Is there anybody out there who has any concerns or objections for a
> C++ dependency?
>
> A few more question that arise from the above:
>
> * Do we want to port fluidsynth to C++ completely?
> * Or should only new code/features be C++, existing C code stays
> untouched unless a complete rewrite is required?
> * Or do we only want minimal glue code for C++ stdlib features, rest stays C?
>
> Any feedback about that is welcome.
>
> Note that fluidsynth's API is unaffected and stays written in C.
>
> Detailed background information about proposed changes on GitHub:
> https://github.com/FluidSynth/fluidsynth/pull/604
>
>
> **Spoiler:**
>
>
> Keep in mind that we are only talking about C++98. There is no benefit
> in porting fluidsynths entire codebase to C++98 (esp. not in terms of
> getting rid of glib). However, for this particular revisal, some
> features of the C++ standard library come in handy, allowing a simple
> and lightweight implementation.
>
>
> Tom
>
> _______________________________________________
> fluid-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

Dan Eble
On Jan 21, 2020, at 13:50, Carlo Bramini via fluid-dev <[hidden email]> wrote:
>
> From my experience, C++ is not a good idea sometimes, especially when you want to maximize the performance and minimize the memory usage.

Please don't take offense at this, but demonstrating that it is possible to write a poorly performing program in some language is not the same as demonstrating that programming in that language is a bad idea.  Even granting that a hot spot in a C++ program might be well addressed by a tailored solution, that does not support avoiding C++ in your entire program.

I can provide a counterexample from my own experience.  I worked for 8 years in a company whose main product performed line-rate deep packet inspection and modification in C++.  High availability, high performance, and controlled memory use were all high priorities, and they were achieved—with diligence, but not with great difficulty.  And the developers avoided several classes of bugs that are common in C programs, by contextually appropriate use of features like references instead of pointers, the class system with its ability to restrict operations performed on an object, and RAII techniques (e.g. smart pointers) instead of the old "goto fail and try not to overlook releasing anything" approach.

"C++ is inefficient" and similar statements can also be straw men posed by those who feel that they would be impolite or lose face by saying, "I'm just not interested in investing my spare time in C++ programming."  I don't know anyone here remotely well enough to claim that that is the case here, but there are such people in the world.

Regards,

Dan


_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

fluid-dev mailing list
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Reply | Threaded
Open this post in threaded view
|

Re: Adding C++ as mandatory dependency?

Philippe Simons
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/fluid-dev