Re: [boost] [Review] The review of the Boost.Logging library starts today, November 7th

From: John Torjo (john.lists_at_[hidden])
Date: 2005-11-09 08:32:47

Caleb Epstein wrote:
> 
> In which case your object construction will fail in the member initializers
> and not the body. Its the same effect - the caller will get a std::bad_alloc
> and the object will not be created. I don't see how initializing the member
> twice changes this.

Yes, you're right. Done it.

> 
> I just meant that there are older definitions left in the code, commented
> out, above the current definitions. Is this what you want?

Oh, right! Fixed it

> 
>>>boost/log/log_impl.hpp: DEFAULT_INDEX should probably be lower-cased and
>>>possibly renamed. It should probably use BOOST_STATIC_CONSTANT.
>>>
>>>boost/log/log_manager.hpp: DEFAULT_CACHE_LIMIT: See concerns above.
>>>
>>
>>The reason they're uppercased is because they're constants.
> 
> But they're not macros. All-uppercase just screams macro to me.

Yup, I'll fix it.

>>
>>It's because internally, when writing BOOST_LOG(x) you're dealing with
>>a function that returns a static reference.
>>
>>The problem comes when you're using the static reference after it's been
>>destroyed (thus the shared_ptr would be invalid)
> 
> 
> 
> This might be an argument of making the BOOST_LOG* macros work like this
> then:
> 
> BOOST_LOG(logger, msg << to << stream)
> 
> so that the implementation could hold a shared pointer to the logger for the
> lifetime of the call. Just a thought.

I'm not sure how that would help. Could you give an example? Thanks.

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit!
-- http://www.torjo.com/cb/ - Click, Build, Run!