[UR] Fix some print operators not being exported

[PatKamin]

No description provided.

[igchor]

Why should those operators be exported anyway? They are in the header so it shouldn't matter I think.

[PatKamin]

Why should those operators be exported anyway? They are in the header so it shouldn't matter I think.

They are not visible in the loader's .lib file otherwise. Do we want them to be useful only with the headers?

[igchor]

They are not visible in the loader's .lib file otherwise.

But why is that a problem? Do we expect to need a function pointers to those operators or something like that? If not, what's the benefit of having those operators exported?

[PatKamin]

But why is that a problem? Do we expect to need a function pointers to those operators or something like that? If not, what's the benefit of having those operators exported?

No, there is no need for function pointers to these operators, I suppose. I thought that these operators can't be used by an external binary by merely including the .hpp header and that these functions have to be exported in the library file as well (https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll?view=msvc-170). However, I might understand it wrong and exporting shall be done only for the API functions included in the loader's function pointers table?

Shall all exports in this header be removed then? The exporting policy should be the same for all operators to keep the code clean.

[igchor]

But why is that a problem? Do we expect to need a function pointers to those operators or something like that? If not, what's the benefit of having those operators exported?

No, there is no need for function pointers to these operators, I suppose. I thought that these operators can't be used by an external binary by merely including the .hpp header and that these functions have to be exported in the library file as well (https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll?view=msvc-170). However, I might understand it wrong and exporting shall be done only for the API functions included in the loader's function pointers table?

Shall all exports in this header be removed then? The exporting policy should be the same for all operators to keep the code clean.

I'm also not an expert on that but I found this answer which would suggest that if we don't need to take the address of such functions, exporting them is not necessary: https://stackoverflow.com/a/44183940/5935594 so yes, I would say that we should either remove exports for all functions that are defined in the header as inline or to define those functions in a .cpp file and export them.

Btw, why did we decide to implement those operators as inline in the header in the first place?

[PatKamin]

But why is that a problem? Do we expect to need a function pointers to those operators or something like that? If not, what's the benefit of having those operators exported?

No, there is no need for function pointers to these operators, I suppose. I thought that these operators can't be used by an external binary by merely including the .hpp header and that these functions have to be exported in the library file as well (https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll?view=msvc-170). However, I might understand it wrong and exporting shall be done only for the API functions included in the loader's function pointers table?
Shall all exports in this header be removed then? The exporting policy should be the same for all operators to keep the code clean.

I'm also not an expert on that but I found this answer which would suggest that if we don't need to take the address of such functions, exporting them is not necessary: https://stackoverflow.com/a/44183940/5935594 so yes, I would say that we should either remove exports for all functions that are defined in the header as inline or to define those functions in a .cpp file and export them.

Btw, why did we decide to implement those operators as inline in the header in the first place?

Right, based on these resources we can remove all exports from this file as it is not necessary to provide pointers to the operators. Inlining was introduced so that printing won't hurt performance, I suppose. I think that we want this to remain.

[pbalcer]

But why is that a problem? Do we expect to need a function pointers to those operators or something like that? If not, what's the benefit of having those operators exported?

No, there is no need for function pointers to these operators, I suppose. I thought that these operators can't be used by an external binary by merely including the .hpp header and that these functions have to be exported in the library file as well (https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll?view=msvc-170). However, I might understand it wrong and exporting shall be done only for the API functions included in the loader's function pointers table?
Shall all exports in this header be removed then? The exporting policy should be the same for all operators to keep the code clean.

I'm also not an expert on that but I found this answer which would suggest that if we don't need to take the address of such functions, exporting them is not necessary: https://stackoverflow.com/a/44183940/5935594 so yes, I would say that we should either remove exports for all functions that are defined in the header as inline or to define those functions in a .cpp file and export them.
Btw, why did we decide to implement those operators as inline in the header in the first place?

Right, based on these resources we can remove all exports from this file as it is not necessary to provide pointers to the operators. Inlining was introduced so that printing won't hurt performance, I suppose. I think that we want this to remain.

Agreed. This is header only, so makes complete sense. Please close this PR and open a new one that removes the export markers.

[PatKamin]

Changes in this PR are dropped and replaced with #1115