Resolve "Forward time and logging id to Logging Destination" - [merged] #97

Closed rainman110 closed 10 months ago

In GitLab by @mariusalexander on Nov 17, 2022, 13:56

Merges 34-forward-time-and-logging-id-to-logging-destination -> master

Closes #34

In GitLab by @rainman110 on Nov 22, 2022, 12:46

I am unsure. It would be probably best, if we can provide some default implementations. I am not sure, whether we can use some forward declarations of e.g. vector and map etc. Another option would be, to create a separate log_stl_types header (or similar), that only includes what is needed when needed.

In GitLab by @mariusalexander on Nov 22, 2022, 14:52

added 2 commits

47fd238f - added support for different stl classes
870c5a47 - cleanup

Compare with previous version

In GitLab by @mariusalexander on Nov 22, 2022, 15:06

added 1 commit

6d93fc41 - fix nodiscard attribute

Compare with previous version

In GitLab by @mariusalexander on Nov 22, 2022, 15:09

I have moved the operator<< for the stl stuff into multiple, separate header files. They are grouped however in gt_logging/stl_bindings.h. Alternatively they may be included by defining GT_LOG_USE_EXTENDD_STL_BINDINGS

In GitLab by @mariusalexander on Nov 22, 2022, 15:14

Commented on src/gt_logdestfile.h line 182

I agree, there has to be a shared ptr if the destinations should be accessed in any way. As far as I can see there are two scenarios:

There is the write method, that could be used by the user directly.
Also in case of the FormattedDestinaton one may want to set the filter and the format functor afterwards

Comes the question if we should allow this or if the user should remove the old destination and replace it by the "updated" one, if you can follow me?

In GitLab by @mariusalexander on Nov 22, 2022, 15:17

Commented on src/gt_logdest.h line 60

I think this type method is not really useful nor necessary. We have the id, which we assign to a destination, so the type method is obsolete in this regard. So I'll probably remove it

In GitLab by @mariusalexander on Nov 22, 2022, 15:39

Commented on src/gt_logdest.h line 60

changed this line in version 17 of the diff

In GitLab by @mariusalexander on Nov 22, 2022, 15:39

added 1 commit

65612465 - removed type functions

Compare with previous version

In GitLab by @mariusalexander on Nov 22, 2022, 16:11

added 1 commit

d49a15c7 - fix

Compare with previous version

In GitLab by @mariusalexander on Nov 23, 2022, 08:57

added 1 commit

d051095e - fix for win build

Compare with previous version

In GitLab by @rainman110 on Nov 24, 2022, 08:36

Commented on src/gt_logdest.h line 60

If we don't use it, remove it. I don't see any use for it.

In GitLab by @rainman110 on Nov 24, 2022, 08:39

Commented on src/gt_logdestfile.h line 182

We can provide a getter that returns a reference or a raw pointer to an internally stored destination. you can also keep the pointer (managed by the unique_ptr) as is will remain valid.

Whether to use a shared_ptr or unique_ptr is simply a question of ownership, not accessibility.

In GitLab by @rainman110 on Nov 24, 2022, 08:41

Commented on src/gt_logdestfile.h line 182

There might still be good reasons to use a shared ownership though. I don't have big problems if we keep a shared_ptr, if this enables more flexibility for us. We just should keep in mind, that I also has its performance penalties, in particular in parallelized code.

In GitLab by @mariusalexander on Nov 24, 2022, 08:56

Commented on src/gt_logdestfile.h line 182

I like this, however I will remove the functionality of unnamed destinations (i.e. destionations without an id)

In GitLab by @mariusalexander on Nov 24, 2022, 09:23

added 1 commit

75a6c4a2 - using unique ptr nstead of shared. Some cleanup

Compare with previous version

In GitLab by @mariusalexander on Nov 24, 2022, 10:35

Commented on src/gt_logdestfile.h line 182

I have used unique ptr. What do you think? Also I have rearranged the logging fromatting to <level> [<time>] [<id>] <message>. That way level and time are always aligned

In GitLab by @rainman110 on Nov 24, 2022, 14:31

@mariusalexander can this be merged?

In GitLab by @mariusalexander on Nov 24, 2022, 14:32

marked this merge request as ready

In GitLab by @mariusalexander on Nov 24, 2022, 14:32

@rainman110 yes. please approve

In GitLab by @rainman110 on Nov 24, 2022, 14:43

approved this merge request

In GitLab by @rainman110 on Nov 24, 2022, 14:43

mentioned in commit 32e18f9adb7e50b88e4de4ebffe46d1a08e79197

dlr-gtlab / gt-logging

Resolve "Forward time and logging id to Logging Destination" - [merged] #97