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!