See #550. Now that we use the Vista API for condition variables, the only place where the distinction is still relevant is Windows XP, and it's just not worth it for that one corner case.
This uses SRWLock on Vista and above, and uses a hand-rolled implementation on Windows XP that uses Events (and a spinlock, if this is a multi-core system).
Since SRWLocks aren't recursive, ReMutexWin32Impl has been added to implement recursive mutices, using old-fashioned critical sections.
MutexImpl now has a constexpr constructor on all implementations.
This happens if load_dso fails due to being unable to find the file, but not setting the dlerror flag and therefore causing a misleading error message to be shown.
The main motivation behind this change is to get rid of a
signed integer overflow that sometimes happens in the prime
multiplication step, which is (per the C++ spec) undefined
behavior. However, it's probably for the best to use only
unsigned int when the function is clearly trying to avoid
negative values.
Not that I suspect it matters much, but I have also heavily
tested that the behavior of the function is unchanged (at
least on PC hardware - signed integer overflow doesn't
behave portably) although it may now be slightly faster due
to the fact that I have removed the floating-point math.
This is used similar to matches() but for file paths: it does not match slashes for * characters and has special support for /**/ and ignores // and /./ patterns.
Even a brief error message in the assertion is infinitely more useful to a user who is not at home in the source code, especially for assertions that may reasonably be triggered by honest user mistakes.
It's not really reasonable to expect a user to find every occurrence of a cached resource that might be using an open stream and remove it or crash otherwise.
This is fixed by keeping the multifile stream open as long as any substreams are still pointing to it, using a simplified reference counting (care is taken not to fully make StreamWrapper reference-counted, since it's not in express and existing uses should not be broken).
Fixes#449
Also see #428
While it becomes possible to do this now, it should not become standard practice, and we should deprecate cases where we already do it by renaming either the static method or the property.
Fixes#444
This changes includes so that local includes are consistently
#include "localFile.h"
while system and third-party includes are consistently
#include <systemFile.h>
This commit mostly converts the former to the latter; the two
exceptions are in android_main.cxx and fmodAudioSound.h, where
the reverse was necessary.
rdb
Brian Lach
Sam Edwards