Re: [Freeglut-developer] State-aware callbacks

[John T. <nu...@me...>]

On Thu, Dec 25, 2014 at 01:43:43PM +0800, Diederick C. Niehorster wrote:
> Hi John,
> 
> On Thu, Dec 25, 2014 at 4:26 AM, John Tsiombikas <nu...@me...> wrote:
> >
> > Wait... are we seriously discussing merging C++ code to the official
> > FreeGLUT source?! I thought you where just asking for testers for your
> > branch!
> >
> > This is a horrible idea, and I will veto it to death as long as I'm
> > around ... Even optionally compiling-in the C++ bits is absurd. This
> > feature is ONLY reasonable as a wrapper.
> 
> Looking to understand your position better, why is it horrible? The
> fact that the C code happens to compile now as C++ with minor hacks
> doesn't preclude nightmares later, nor the possibility that some
> things don't quite work as they should?

I wasn't objecting so much on making the code compilable as C++
(although that still is quite pointless in my opinion), but rather on
adding (even as a compile-time option) the C++ std::function callback
interface in the main freeglut library.

There are many reasons why this is a bad idea. Some of which that come
to mind at the moment are the following:

1) C++ APIs in reusable libraries are "a bad thing" because different
compilers produce incompatible name manglings, so there is no way to
install a single library system-wide and allow it to be used by simply
linking against it regardless of the compiler, or even compiler version,
like C libraries.

2) Building with C++ would immediately make the particular C++ standard
library currently linked, a hard dependency. The C++ standard library is
not immune from point 1 above. Different versions of GNU libstdc++ are
notorious for being binary incompatible with each other, and there are
even more than one standard C++ libraries in common use at the moment,
piling on the incompatibilities (clang's libc++, mozilla's
what's-it's-name, etc).

3) Some users would have the C++ build installed, while others would
have the C build installed, making tracking down issues even more
problematic. A C++ program linked with the C build would be running fine on
the development system, and fail to run correctly when moved over to a system
with the C++ build installed if it happens to use a different version of
the C++ compiler, different C++ compiler, different version of the C++
standard library, or different C++ standard library.

4) It's an architectural mistake. This feature belongs in a wrapper.


Even if I don't object so much to just making the code simply compilable
as C++, I still find it pointless, and potentially problematic in some
corner cases. For instance, C++ doesn't convert void* to other types of
pointers automatically, forcing us to cast the result of all malloc
calls. Casting the result of malloc, will hide the very dangerous
mistake of forgetting to include stdlib.h, which would make the malloc
call expect an int return value implictly when compiling as C.

> Perhaps your proposal is safer to go with then, even if it involves
> adding a lot of functions. Would it also work for calling C++11
> lambdas and such?

Sure, with a bit of glue code in between (the freeglut C++ wrapper).
Lambdas are just std::functions too.

Btw, the alternative callbacks with closures, are not just useful for
the C++ wrapper. They are quite useful for C programs as well.

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/