C or C++

I have stumbled into the issue of C vs C++ with pystencils. 99% we generate C code. We even would like to use the restrict keyword, which is only available in C, not in C++ (although many compilers do support it).

I am not sure if we misuse C/C++ at this point. Generally C only would be beneficial, so we can include our kernels in pretty much any language, since any relevant language has a c-ffi.

What would we miss, if we would restrict ourselves on C only? So far I have found some C++ allocations (#24 (closed)), and std::cout usage.

C++ allocations (#24 (closed))

Actually, C11 is sufficient as well, C++ is not required for this.

What would we miss, if we would restrict ourselves on C only?

We would mainly need to modify some of the hand-written header files. Full list of files with C++ usage:

• pystencils/backends/cbackend.py: replace std::cout with printf and the <iostream> header inclusion with <stdio.h>.
• pystencils/include/PyStencilsField.h: remove file, obsolete since !55 (merged).
• pystencils/include/cuda_complex.hpp: CUDA compiler always operates in C++. So leave this file as is.
• pystencils/include/philox_rand.h: uses <cstdint>, replace with <stdint.h>. Has some function overloads, change to unique function names.
• pystencils/include/aesni_rand.h: uses <cstdint>, replace with <stdint.h>. Has some function overloads, change to unique function names (be consistent with philox_rand.h). Uses std::array and std::map, which would be ugly to remove.
• pystencils/kerncraft_coupling/templates/benchmark.c: replace std::malloc/std::free with malloc/free.

So the only thing that cannot easily be converted is the AES random-number generator. So when that is used, we will need to continue using the C++ compiler, but if you decorate the generated kernel with extern "C" it will be callable via c-ffi nonetheless.

We will need CI jobs that test with C and C++ compilers separately. If we switch to C for use from within pystencils, we still want to have valid C++ code for use from Walberla.

assigned to @hoenig

changed due date to November 30, 2021

removed due date

Can't we use extern "C" for Walberla as well?

Also, this should probably be mainly tested in pystencils_walberla.

added ongoing label

I have thought more about this issue. In essence, I'd wish for C's ABI. So @kuron is completely right. We just need c-ffi. Inside the kernel, we can unleash C++ as we wish.

This would make #55 way easier, since we can reuse the old implementation with lambdas.

mentioned in issue #55

assigned to @holzer and unassigned @hoenig

mentioned in merge request !387 (merged)