u/ConnectHat4222

Shared structs and different compiler options

Hello. I am dealing with a largish, legacy code base and I am trying to make some common vocabulary structs that contain data passed between major components. These are the system architecture types for communication, not anything used in intensive computation.
We had a new multi-address space RTOS, so we were starting to use separate address spaces to ensure that our code communicates only using known interfaces (no globals, hidden in singletons or whatever). As it so happens, we are moving back to a single address space RTOS, but I am still making these structs as if they are going to be used by separately compiled components. I plan to make each major component compile into a library that is used by the application.
This is all to setup my question! I have recently learned that I may need to protect against different compiler options being used in different components. We might want to change optimization for a particular component, for example, after we get rid of any old UB in it. I have heard that aggressive optimization might do all kinds of interesting stuff with a struct underlying layout. This might not match what another component's compiler options generate.
It seems like I am fighting the compiler a little bit by adding alignas() in some places and having static_assert() to make sure the struct is how we want, i.e. to undo any optimization for that type. It can also be stated that we are using the binary format as a cheap serialization between components, and so that is why I might be fighting the compiler this way. Compiling things independently and allowing different compiler options is like making different programs and then expecting the raw binary to be the serialization still (like you can inside a program compiled all together).
It feels dumb! What are you people doing in these cases?
Thanks!

reddit.com
u/ConnectHat4222 — 2 days ago

Hello. Basic question here. I have structs like this:

struct Position
{
double x;
double y;
double z;
};

These are occasionally marshalled like this from internal structs in one component and passed around for other components to consume in other threads.

I think I want to support array-like access to for using, say eigen with these too. It could be something like this:

double *data() { return &x; }

That has some UB flavor though, right?
It could be like this too:

double x() { return x; }
// yawn

I feel like there is a conflict between a basic struct with named members and also trying to make some efficiency or convenience considerations for consumers. On the one hand I don't want to cater to efficiency too much at this level, but I also wouldn't mind if there was some nice way to have it all. (I will be using a units library also.)

What do you like to do for situations like this? Thanks!

reddit.com
u/ConnectHat4222 — 18 days ago