RE: [Devel] 2.1.0 branch created

[Boris Letocha]

> >So the question really boils down to:
> >
> >  A - is there enough interest in a C++ version of the library
> >      (and more especially a C++ native API)
> >
> >  B - would doing so drastically reduce our development time
> >      (man-years ??)
> >

In our project we are using more libraries
(zlib,png,jpg,tiff,freetype,ICU,...), all have C API which we
encapsulate in our C++ object model. Even from ICU we don't use C++ API
as it is available. C++ API is usually C API encapsulation which slows
down things. So from that point C API as it is now is completely
sufficient.

1.) So your first solution C++ without STL doen't give you too much
things better except "exceptions" which helps you to make library easily
any leak safe ... ( unfortunately exceptions in MSVC++ are painfuly slow
)

2.) Next is usage of MLib. I think (I am not sure) that usage of longjmp
is not as portable as C code without longjmp. Also IMHO if you use
longjmp in C++ you will not get C++ stack cleaning. So cooperation of
MLib and C++ code should be tested - f.e. C calls C++ that calls C code
and which longjmp to upper C code (this is callback in C++ example) if
it really cleans stack, if yes then I don't have any problem with MLib
in new FreeType.

3.) And leave it in "plain" C - for us it is no problem, but for you I
think it is pain and really lost of time. Programing in C++ with
templates and inheritance is so much easier and productive.

Boris Letocha

PS: Thanks for your time to write such good and unique library.
PPS: Sorry for my English ...