Age | Commit message (Collapse) | Author |
|
It's very irritating that Visual Studio produces a warning for unrecognized
#pragmas, which we then merrily turn into an error -- #pragma is inherently
compiler-specific!
|
|
in: 'cout << a() << b()' the order of evaluation of a() and b() is undefined.
|
|
|
|
|
|
now - operator << issues on clang
|
|
trigger clang warnings
|
|
|
|
error reporting that is not properly cleaned up.
|
|
reporting that is not properly cleaned up.
|
|
bounces once per second
SH-4346 FIX: Interesting: some integer Statistics are displayed as floating point after crossing region boundary
made llerrs/infos/etc properly variadic wrt tags
LL_INFOS("A", "B", "C") works, for example
fixed unit tests
remove llsimplestat
|
|
|
|
That is, when the underlying LLError::Settings object is destroyed -- possibly
at termination, possibly on LLError::restoreSettings() -- the passed Recorder*
is deleted.
There was much existing code that seemed as unaware of this alarming fact as I
was myself. Passing to addRecorder() a pointer to a stack object, or to a
member of some other object, is just Bad. It might be preferable to make
addRecorder() accept std::auto_ptr<Recorder> to make the ownership transfer
more explicit -- or even boost::shared_ptr<Recorder> instead, which would
allow the caller to either forget or retain the passed Recorder.
This preliminary pass retains the Recorder* dumb pointer API, but documents
the ownership issue, and eliminates known instances of passing pointers to
anything but a standalone heap Recorder subclass object.
|
|
|
|
|
|
This makes logs look less scary on Linux, in-line with other platforms.
|
|
|
|
|
|
|
|
|