On Fri, Oct 11, 2013 at 3:06 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Fri, 11 Oct 2013 00:03:00 +0000 Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> said:
>
>> Hello,
>>
>> Currently, writing modules for enlightenment using C++ is not possible
>> without modifying headers from enlightenment.
>>
>> How is the policy for these headers w.r.t C++ compatibility?
>>
>> The most common problems are:
>> * Lack of extern "C";
>
> you can always:
>
> extern "C" {
> #include "e.h"
> }
> in your c++ module.Yes. I can. However, EFL already does this in its headers. Is this unwanted for enlightenment? I can provide a patch. > beware. you MUST also ensure your module symbols for init/shutdown etc. are > not > mangled. > >> * The use of C++ keywords, e.g., class (replaced for klass); > > like above. you can split your module into the c++ and c sections, having the > c > sections wrap/access e and expose to the c++ section. :) the c++ section never > sees e includes. :) Yes I can. But then I would be writing a wrapper in C for C-without-C++-keywords, which doesn't add much benefit. I can't really make the wrapper be much different from the E API since most user code would be in C++ anyway. For example, using e_box from C++ through a C wrapper, the C wrapper couldn't add any value or abstraction. However, these modifications aren't hard at all to do and mantain in the E headers, without requiring the C++ user to make lots of redundant C headers. >> * Functions and macros defined in the header with implicit conversion >> from unrelated pointer types; >> * Typedefs before definition or declaration of the typedef'ed UDT. > > as above. you can split. create a c interface shim to e that doesnt expose > these things and exposes a c++ friendly interface... and you need to do this > split anyway to ensure the module init/shutdown etc. apis are not mangled... I would rather send patches to make it compatible if there are no objections. Most keywords can be easily replaced (class/klass) in headers and inline functions can just use the necessary casts. Not that hard. And the typedef thing isn't even allowed in C99, it is a GNU extension. Though I understand these modifications won't matter if it isn't constantly tested and maintained, but I wouldn't mind taking this responsibility. > so... why would you want a c++ module? (like ALL of it entirely in c++?) RAII, templates, better type-checking. :). The most important part to have in C++ is actually at the borders, interacting with C, so the rest of the C++ code could have some level of RAII, so not being able to #include the C headers makes using C++ *much harder* because it would involve repeating the C API in code without a few idiosyncrasies and maintaining these as E evolves. >> Regards, >> -- >> Felipe Magno de Almeida Regards, -- Felipe Magno de Almeida ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
