Draft: Resolve "Consider implementing option to log a message to a single destination" #120

Open rainman110 opened 10 months ago

In GitLab by @mariusalexander on Sep 20, 2023, 13:48

Closes #55

In GitLab by @mariusalexander on Sep 20, 2023, 14:40

added 1 commit

44dc5185 - implemented macro to log to a single destination

In GitLab by @mariusalexander on Oct 10, 2023, 07:11

@rainman110 How would you implment the following feature:

I want to implement a macro/functionality to log a message to a single destination. I thought about naming it gtLogTo, but how should the signature look like?

gtLogTo(<LEVEL>, <DESTINATION_PTR>)

or

gtLogTo(<LEVEL>, <DESTINATION_ID>)

Similar to the other macros I want to implement another macro that allows to log an ID:

gtLogToId(<LEVEL>, <LOGGING_ID>, <DESTINATION_PTR>)

or

gtLogToId(<LEVEL>, <LOGGING_ID>, <DESTINATION_ID>) <- this is the reason I personally would not favor the signature using the logging id, since now one might confuse both parameters (i.e. one might use the logging id as the destination id and vice versa). What do you think?

In GitLab by @mariusalexander on Oct 10, 2023, 07:25

Commented on src/gt_logging.h line 143

@rainman110 Another question:

I messed up in the last MR, as I forgot a const& for both string parameters. I tought moving the strings would be more fitting, but we don't need moving these:

    void log(Level level,
             std::string const& message,
             std::string const& id = GT_MODULE_ID);

now obviously this would be an ABI change. Then I tought one could implement an overload like this:

    void log(Level level,
             std::string message,
             std::string id = GT_MODULE_ID);

    void log(Level level,
             std::string const& message,
             std::string const& id = GT_MODULE_ID);

But obviously this would be an ambiguous overload, because the compiler does not know which overload to choose.

Then I tought, would it be possible to have both "signatures" in the library, but only "show" the correct one to the user/compiler? After all its an ABI change, because I am essentially deleting the old function signature. Could something like this work (in theory)?

// preprocessor macro that would be active when building the dll but not when "using" it, thus hiding the definition from the compiler and resolving the ambiguous overload
#ifdef BUILDING_GT_LOGGING 
    void log(Level level,
             std::string message,
             std::string id = GT_MODULE_ID);
#endif

    void log(Level level,
             std::string const& message,
             std::string const& id = GT_MODULE_ID);

This is probably very much overkill, but Im just curious (and it bugs me too :joy:)

In GitLab by @rainman110 on Oct 10, 2023, 07:38

I agree that having three kinds of enums / ids can be problematic. On the other hand, using pointers also does not seem to be a good solution.

What about something completely different?:

gtInfo().to(DESTINATION_ID) << "hello"

Would it be possible to implement this?

In GitLab by @rainman110 on Oct 10, 2023, 07:39

But why do you want to steer the destination in the first place?

In GitLab by @mariusalexander on Oct 10, 2023, 07:49

EDIT: An example would look like this:

gtLogTo(Debug, "my_dest_id") << "bla";

and

gtLogToId(Debug, "my_id", "my_dest_id") << "bla";

But why do you want to steer the destination in the first place?

Sometimes one only wants to print a message to a single destination (say to a log file). or would you argue against something like this?

dlr-gtlab / gt-logging

Draft: Resolve "Consider implementing option to log a message to a single destination" #120