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
> 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.
-- 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk