One of the things that I miss the most in the C++ is the ability to iterate over every single field in the POD (plain old data) structure. A basic example from the top of my head is when you need to preprocess the data, received with the different byte endianness (big vs little endian).
I was writing an article about adding
constexpr to some legacy code generation function when I found myself explaining one feature so detailed I decided to extract it into the separate article.
UPD: As Shafik Yaghmour has pointed out, the solution below is an undefined behaviour, due to the use of an inactive member of the union. Another solution is using the fact, that we are allowed by the standard to cast pointers to
char (std::int8_t) and
unsigned char (std::uint8_t). So we get rid of pointers, fill an array of bytes, reverse it and copy the data back to the user. Here’s the link to play with.
During the preliminary testing of the MC149.01 receiver, I was curious about checking our receiver against some other NT1065-based device. As far as I know, the most widespread one is the Piksi Multi by Swift Navigation. This is a remarkable ZynQ-based receiver with the best user-software I’ve seen. One of the advantages that we share is the software-defined processing: both the MC149.01 and the Piksi can be further upgraded to process more signals and improve receiver quality.
A lot has been said and done about modern (post-2011) C++. Most of the times it makes your code more expressive, which often leads to better optimizations from the compiler. As you may know, I’m currently working on a triple-band GNSS receiver, which is built upon the BBP2 SoC. This SoC has two NeuroMatrix DSPs and one ARM1176JZF-S core. NeuroMatrix has a very old toolchain, even pre-standardization era (~1995). ARM compiler toolkit is built upon some GCC version with C++11 core language support, but no library support.