Re: Header for operator<<(std::ostream&, NSObject*) et al.

On 08/12/2013 09:09 AM, Boris Dušek wrote:
> I want to submit implementation of Objective-C-related operators <<, like:
>
> std::ostream &operator<<(std::ostream &o, NSString *s)
> std::ostream &operator<<(std::ostream &o, NSObject *obj)
> std::ostream &operator<<(std::ostream &o, NSPoint point)
>
> etc., motivation is for easy logging with SAL_INFO, SAL_WARN, SAL_DEBUG
>
> I was wondering what would be the best header for that? I am asking the list because also other 
> platforms could use some more special logging of their types (I was thinking stuff like GObject * 
> etc.), so some coordination is needed.
>
> One option is to put all of this stuff e.g. into include/sal/system-type-logging.hxx and there by 
> #ifdef's check what is the current platform and define the appropriate operators for that platform 
> in the respective #ifdef section. So the header would contain stuff for all platforms.
>
> Do you think that is acceptable, or do you suggest a better approach?

Would you suggest to explicitly #include that header where needed, or 
have it implicitly available everywhere via inclusion into some 
strategic header that is virtually always included?

Since that header would likely in turn include quite some 
platform-specific headers, having it included ~always could have 
negative impacts on compile time, and if it were included via some other 
URE header, it would need to be wrapped in #ifdef LIBO_INTERNAL_ONLY to 
make sure it does not impose new build requirements on external code.

My suggestion would be to go with an (explicitly included) header in 
include/vcl/ first (as most of the platform-specific code that would 
want to use it should probably be in vcl) and see how that works out.

Stephan