Boost logo

Boost :

From: Ivica Siladic (ivica.siladic_at_[hidden])
Date: 2024-10-21 14:38:32


Hi Seth,

> On 20.10.2024., at 23:52, Seth via Boost <boost_at_[hidden]> wrote:
>
> On Sun, Oct 20, 2024, at 9:15 PM, Marcelo Zimbres Silva via Boost wrote:
>
>> This is the approach I took in Boost.Redis:
>> https://www.boost.org/doc/libs/1_86_0/libs/redis/doc/html/classboost_1_1redis_1_1basic__connection.html#ae548b1dd13ca66eb265d3e5115ebe3e5
>
> Oh cool. I played around with Redis the other day and failed to figure this out. Yes, not-logging by default really hurts adoption, at least in my case

Boost.Redis has the cleanest logging approach I've encountered so far, and we will most likely adopt it in Async.MQTT5 as well. The only concern I have is the potential impact on compilation times, which could increase significantly since we would need to templatize almost all existing classes by the logger type. To mitigate this, we might explore using a type-erased logger with the same interface required by Boost.Redis, which could help reduce the compilation overhead. We'll need to experiment and see how it works in practice.

>
>> [upsetting users by logging into a global state.] We have a log library in
>> Boost so why not default to it?
>
> Every single time I try to use Boost Log I run into some permutation of the same three link problems. Boost Log is nice when you need the kitchen sink. I would never want any library to default to it, because it's way too heavy. I would not want to burden any library with the default of Boost Log.
>
> just my usual $0.02
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks,
Ivica Siladic


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk