Boost logo

Boost :

Subject: Re: [boost] [log] Review-ready version in the Vault
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-11 04:42:09


----- Original Message -----
From: "Vladimir Batov" <batov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 11, 2009 10:10 AM
Subject: Re: [boost] [log] Review-ready version in the Vault

>
>>>> boost::log log1(name);
>>>> boost::log log2(name); // The same as log1
>>>
>>> I'm curious ti know how do you retrieve the same log by name without
>>> static initialization?
>>
>> This is what my example does, if I understand you correctly. The logger is
>> initialized only when first requested.

Well, this need the library declares a static map.
You should be able to do that, as Sebastian has signaled, with flyweight library.
The question now is do the users need the library provide the way you want to use a log?

> Well, I am under impression that Andrey's solution is somewhat different
> from what I have in mind. Although I must say my implementation is fairly
> conventional -- a logger (like boost::log) is actually a handle/proxy with
> pointer semantics, like
>
> shared_ptr<actual-logger>
>
> Internally, I maintain a name/logger map and, when
>
> boost::log log(name);
>
> is requested, I simply return another reference/handle to the respective
> internal logger implementation (here it seems to differ from Andrey's). If a
> logger with the requested name does not, I create one.

I don't think the solution is different, only complementaty. As far as the library allows to declare a variable of type logger and then configure it you shoulbbe able to get your desired usage.
Could you try to implement how do you want to use a logger with the library from Andrei and the flyweight?

BTW, the flyweight approach has the liability that in order to check if we can log we need to get the logger from the flyweight, which is even if quite efficient (O(N)) on the number of loggers. But this is another history.

Best,
Vicente
Thanks,
Vicente


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