Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-15 16:13:03

Hi,

allow me to jump to this discusion.

----- Original Message ----- 
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 15, 2010 7:10 PM
Subject: Re: [boost] [log] Comments

>> Record identifiers proved to be very useful in communication, 
>> surrounding the piece of log. It's much easier to write "see, there's 
>> that error in line 2764" than to go for lengthy explanations of how to 
>> find it in the file.
> 
> What other libraries use this record id by default?

I find useful a record identifier. it allows to sort the log using different criteria and preserving order at the same time (see bellow). Whether the record_id should be in the trivial loggin by default is another issue. 

IMO the trivial log shouldn't provide any attributes. The library could provide other out of the box logs that take care of some usual configurations.
 
>> > Also, it prints the thread "number",
>> > on my system a hex string. I am not sure thread id should be part of trivial
>> > logging.
>> 
>> Why not? Why can't a multithreaded application use trivial logging?
> 
> Because hex string, in a log, is completely useless. It is of any use if you
> are attached to a still-running application, and can actually figure what
> a thread id means in your program.

I don't agre here. The thread_id, independently of its hexadecimal or a string form, serves to identify the logs of the same thread. I use to work with record_id + thread_id. Then ordering by thread_id and then record_id , gives me a clear sequence by thread. A simple grep of a specific thread_id allows to extract all the log of a thread. Of course, a user defined name for a thread will be more useful. Shouldn't this namming feature be associated to the thread library?
 
<snip>

> It's not like maintainer of Boost.Thread left on a space mission to outer
> space and is not coming back ;-) Could you just propose this for inclusion?
> We have too many bits hidden in detail namespace of various libraries.

I agree that it is good to request new features to Boost.Thread, but there are already very old features request for Boost.Thread, and I'm not sure Anthony will have the time to take care of all of them. Maybe someone could help Anthony to integrate the simple features.
 
Best,
Vicente