Re: [Jack-Devel] The Situation(s) With JACK

PrevNext  Index
DateWed, 14 Dec 2011 11:25:42 +0100
From Stéphane Letz <[hidden] at grame dot fr>
To"Tim E. Real" <[hidden] at rogers dot com>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToTim E. Real Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpPaul Davis Re: [Jack-Devel] The Situation(s) With JACK
>> 
>> This is a mix of real inheritance base C++ code (for backend/driver),
>> clients... and sometimes use of C++ typing system with a compilation time
>> choice of what actual class has to be used (for server/client communication
>> channels, synchronization primitives....). This is the result of gradual
>> evolution over time, and choice between what C++ virtual method mecanism is
>> helpful for or possibly "removes"  (like some speed in some precise
>> cases..)
>> 
>> But yes, not pure C++.
>> 
>> But the question is still always the same: does the the jack-dev community
>> think the "C code base" can be used to continue development, or the "C++
>> code base" (even will all it's imperfections that we can discuss and
>> comment forever....., but that we can also gradually improve).
>> 
>> This choice has to be done now.
>> 
>> Stéphane
>> 
> 
> Thanks for explaining, I was about to ask why hesitation to fully embrace C++?
> Technical?
> Would it say, cause embedded HW code to grow, eating up space?
> Or some third party possibly legacy code to break?

Well it was more historical: first version in 2005 was more C++ like (with base class and virtual methods and so on....). This was changed later one in some parts were virtual methods were not so useful.  But anyway this is not so important. 

> 
> It's neat that both versions 1 + 2 API currently 'just work' - for now, but 
> is it a luxury which can't last much longer?

The point is that is 'just work' .... almost.
> 
> 
> Anyway modern C++ gets my ++.
> Watching the threads, thanks. Tim.
> 

And one way to improve the situation is to make a clear choice or the reference code base.

Stéphane 
PrevNext  Index

1323858339.27306_0.ltw:2,a <E559AC63-9E70-40F4-A059-1E9FEEB27821 at grame dot fr>