Does it make sense to pass a static object to a constructor defined in a different source file?

Previously, I clarified that any instantiations inside the main would get overriden since the scheduler resets the MSP. Now that I have that in mind, I have the following simple problem:
I have a uart instance that I’d need to pass as a parameter to another object. I set uart as static because…global variables are discouraged? but static instance itself implies the object is limited to the translation unit it’s defined in…which is main.cpp. Assuming that, does it even make sense to pass a static uart instance?

// main.cpp
static Uart uart;

int main(void) 
  SystemTask task(&uart);
// systemTask.cpp
SystemTask:::SystemTask(Uart *uart)
   // ...


Don’t think too complicated. Globals may be discouraged, but they are not inherently evil or prohibited. In your application, it makes perfect sense to make your UARTs global. If you wanted to be a little bit more modular, you could make them global static in an encapsulated file.

What you are thinking of would work, but you replace one complication with the other.

static implies that the object visibility is limited to the compilation unit/source file.
The objects storage and lifetime is equal to a global variable or object.
That means you can use it wherever you want if given as pointer/reference argument to another object…

static implies that the object visibility is limited to the compilation unit/source file.

exactly, so technically if you have a static variable defined in main.cpp, you wouldn’t have access to it in file.cpp, isn’t it? If that’s the case, does it make sense to have a static variable in main.cpp. and pass it into a function that’s residing in file.cpp?

define “makes sense.” If you think about it logically, it does NOT make sense because the static keyword implies that only main.cpp should be able to “see” the variable, not any other file including file.cpp, so by passing a pointer, you breach your own contract.

Then again, these things happen more often than not. There are arguments for or against it. On certain forums, a question like this may inflame a debate that goes on for months. C allows for a lot of variations on a theme, and you can justify most of them one way or the other.

C keyword static is well defined. See e.g. C++ keywords: static - for its meaning if unsure. Visibility means visibility of the variable for the compiler. Of course you can pass around pointers to variables if needed.
You should try to get more familiar with C/C++ language. That will save you a lot of time and helps to avoid mistakes.

I am mostly aware of what static means. Sorry for the confusion. Looks like either I didn’t understand your full point or you didn’t. Or maybe I didn’t write it clearly.

I was just trying to make sense of passing around a static variable to a different TU given it has an internal linkage

In C, static (on a global) affect the scope of the NAME of that variable. Only things inside the translation unit can use that name to access the variable. If something in that TU takes the address and passes it to somebody else, they can access the object through that pointer, just not via the name.

Just like if you call a function passing the address of a local scope buffer, it can access the buffer through that pointer, but not by the name of the buffer in the caller.

Thanks Richard. Surely you can access a local variable or static variable outside the current TU but my main concern was whether one would really want to access a static variable outside its TU be it through functions…which @RAc pointed out as well

The only way code in file.cpp can access a static file-scope variable uart in main.cpp is if main.cpp deliberately passes the address of uart to file.cpp (there could be layers of parameter passing, so might not be direct).
This is really common usage. You create a string “here” and pass it to be printed “there”.