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