Boost logo

Boost :

Subject: Re: [boost] [boost.log] set_open_handler() and set_close_handler() for text_multifile_backend?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-11-10 12:12:27


On 11/10/2010 04:35 AM, Jamie Allsop wrote:
> Andrey Semashev wrote:
>> On 11/09/2010 04:57 AM, Jamie Allsop wrote:
>>> Jamie Allsop wrote:
>>
>> I'm not sure I understand. Do you need a way to customize the logic of
>> detection when to rotate the log file? What is the 'id' then?
>
> I'm saying that you allow a predicate to be specified that determines
> when a file rotation occurs for the text_file_backend. You can specify
> this predicate on construction (keywords::time_based_rotation) or by
> calling set_time_based_rotation(). I'm saying that you obfuscate this
> somewhat by calling it 'time_based_rotation' since, from what I can see
> it is a simple predicate based rotation. In other words I could supply
> any 'trigger' function that would cause a rotation. The name hid the
> general capability from me. I'm suggesting you rename this to something
> more general like, 'predicate_based_rotation' or 'rotation_trigger' or
> 'rotation_predicate'. Of course you can go on to show how you provide
> some out-of-the-box time based predicates.

I see. Yes, the suggestion seems reasonable. I guess, it was naive of me
to assume that the predicate could only implement some time-based
rotation criteria.

> In my use case I have a number of test cases (conceptually at least) and
> as I move to a new test case (a new test case 'id') I want the results
> to be logged to a separate file. I'd therefore want to provide a
> predicate that knew when the 'id' changes and cause the file to rotate.
> From what I understand this is pretty easy for me to do using a
> time_based_rotation predicate? The name however really should be more
> general to reflect more accurately how it can be used.

Yes, that should be possible, given that the predicate should have its
means to discover the current test case id.


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