Improvement in STSW-ST25RFAL 4.0 source

[CanRF]

Hi

I Reported this for Improvement in STSW-ST25RFAL 3.0 source before.

Now STSW-ST25RFAL 4.0 is available but the following problems are not changed.

1) Add to rfal_analogConfig.h, rfal_crc.h, rfal_iso15693_2.h header files.

#if defined( __cplusplus )
extern "C" {
#endif

otherwise this file makes it difficult with C++

2) Add to rfal_analogConfig.h header files.

#if !defined( __cplusplus )
typedef struct {
  uint8_t id[sizeof(rfalAnalogConfigId)]; 
  rfalAnalogConfigNum num; 
  rfalAnalogConfigRegAddrMaskVal regSet[];

} rfalAnalogConfig;

#else

struct rfalAnalogConfig;

#endif

C++ can't handle an empty array regSet[] in a struct

[Ulysses HERNIOSUS]

Hi CanRF,

actually we have not concluded that it really is a good idea to spread these macros. IMO they don't hinder you from using the sources as you could 

1. compile the RFAL using C++ compiler - using C++ name mangling - not needing any "extern "C""
2. compile the RFAL using C-compiler and in your C++ compiled codes include all the RFAL sources using 

   extern "C" {
   #include "rfal_rf.h"
   }​

Spreading the proposed #defined(__cplusplus) would prevent the first use case.

BR, Ulysses

[CanRF]

Hi

1)
Every serious library owner adds this to every header file.
See STCube, CMSIS, C-Library, ...
So please add this too

2)
The problem with empty array in a struct is not solved with

extern "C" {
#include "rfal_analogConfig.h"
}

[Ulysses HERNIOSUS]

Hi,

just because some people do it this way does not necessarily mean they are right. 

I tend to agree to e.g. this discussion here:

https://github.com/micropython/micropython/issues/3488
with more meat:
https://www.microforum.cc/blogs/entry/34-using-extern-c/ 

https://arne-mertz.de/2018/10/calling-cpp-code-from-c-with-extern-c/  

Please explain your second point.

BR, Ulysses

[CanRF]

Hi,

1)

From

https://github.com/micropython/micropython/issues/3488

OTOH, having these wrappers in C headers is very common and does make C++ integration easier. It requires updating not only py/.h files but also lib/.h and extmod/*.h. We can do this if there's enough interest from the community.

So You update the Header once. Otherwise ever C++ project do it again.

From

https://www.microforum.cc/blogs/entry/34-using-extern-c/ 

Is a discussion about PIC16 code where a C++ compiler is not available and so  extern "C" not necessary. 

But for STM32 a C++ Compiler is available and used from us and other developer.

It is not useful to compile all source file as C++. They are not tested as C++. 

So C File should compile as C and CPP File should compile as C++.

But on the Interface the C++ Compiler should not add name-mangling. 

So it would be helpful when ST Code has got always the same coding style.

2)

typedef struct {
  uint8_t id[sizeof(rfalAnalogConfigId)]; 
  rfalAnalogConfigNum num; 
  rfalAnalogConfigRegAddrMaskVal regSet[];

} rfalAnalogConfig;

Results with C++ in an error because C++ does not support empty array[] at the end of a struct.

GC++ does support this but not ANSI C++.

Inside the header only the pointer to rfalAnalogConfig is used. 

So C/C++ supports a forward deceleration with

struct rfalAnalogConfig;

But the C Module also need the details about the struct.

So my solution is to define a forward declaration for C++ use (extern) and a C compatible declaration for C use.

[Ulysses HERNIOSUS]

Hi,

ad 1)

I better understand now the point of it being more convenient in a mixed C/C++ environment. If implementing such we would need to also enforce this for all our files/test it. We will keep it on our consideration list but spreading a few <"extern "C" {}> in C++ I don't consider blocking.

ad 2)

This will likely require using one of the flexible array workarounds - putting a 0 or 1 into the square brackets for rfalAnalogConfigRegAddrMaskVal regSet[] - also ANYSIZE_ARRAY (MS discussion) might be used - offloading to rfal_platform. Again here we will consider but don't expect soon an action.

Sorry, Ulysses