Apparently eof() in older versions of libc++ returns true if the last character has just been read, whereas the proper behavior is only to return true when attempting to read past the end of the stream. Since failbit is reliably set in all cases when reading past the length of the stream, we should only trust the result of eof() if fail() also returns true.
Adds ability to register "obsolete" names for certain types under older .bam versions, so that we are still able to write out old .bam files.
Fixes#347
This makes it possible to use BillboardEffect to specify a fixed distance to the camera, in order to keep them at a fixed apparent size.
This also enables serialization to .bam of the reference NodePaths of BillboardEffect and CompassEffect.
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.
This is useful because these types are created at static init time, and giving them a constexpr constructor and trivial destructor lets them be created during constant initialization, which helps to prevent static init ordering issues.
There is a bug in clang versions before 3.2 (including the one shipped with Xcode) that makes it give a "conflicting types" compile error when there is a static constexpr function defined outside the class. The way to work around this is either to remove one of the "static" or "constexpr" keywords, or to simply put the definition inline.
See: https://stackoverflow.com/a/17494592/2135754
I would try and upgrade Xcode to version 5 to see if the problem is fixed, but the buildbot still runs OS X Lion (10.7) and the last version of Xcode that works on Lion is 4.6.3, so it seems easier to just apply these workarounds for now.
This renames acquire/release to lock/unlock in order to be compatible with std::lock_guard and std::unique_lock (which will eventually replace the *MutexHolder classes). It will also allow us to typedef MutexImpl to std::mutex later on.
To access a WeakPointerTo in a thread-safe way, use something like this:
if (auto ptr = weak_ptr.lock()) {
..use ptr as regular PointerTo
}
The new implementation no longer needs a reference to be stored to all weak pointers on the WeakReferenceList; a mere count of weak pointers is sufficient. Therefore, callbacks theoretically no longer require a WeakPointerTo to be constructed.
The WeakPointerTo class is not actually atomic; it could be made so, but I don't believe it's worth it at this time.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
The GCC documentation states that, as of GCC 2.7.2, these aren't
necessary for proper program behavior. The documentation further
discourages their use because they don't suppress unnecessary code
duplication.
The Panda codebase these days uses "extern template class" instead,
which tells the compiler not to perform implicit template expansion
because an explicit template expansion is available for linking
elsewhere in the program. This is a more compiler-neutral way of
achieving the same thing as '#pragma interface', making
'#pragma interface' not only redundant, it could also mask problems
in the "extern template class" machinery.
This new loop is better in two ways:
1) It reads straight into the Datagram's internal buffer,
saving the trouble of allocating an intermediate buffer
and wasting CPU time to copy out of it.
2) It's more cautious in the face of large (>4MB) lengths,
which are more likely to be due to corruption than the
datagram *actually* being that large.
rdb
Sam Edwards