Apparently in Boost 1.57 with Xcode 6, the combination of Boost.Lambda and
Boost.Function is broken -- Trac ticket 10864:
https://svn.boost.org/trac/boost/ticket/10864
However, Boost.Phoenix provides an acceptable replacement.
The new TUT library build eliminates the ambiguity about ensure_equals(const
char*, ...) versus ensure_equals(const std::string&, ...). Now it's all based
on const std::string&. Remove pointless const char* overloads and ambiguous
forwarding templates.
With clang in Xcode 6, any new datatypes we intend to use with ensure_equals()
must have operator<<(std::ostream&, datatype) declared BEFORE lltut.h
#includes tut.hpp. Reorder code in certain test source files to guarantee that
visibility.
lltut.h declares a number of ensure_equals() overloads for various data types,
notably the types supported by LLSD. We expect these to be called by tut code.
But the tut code in question is in a template in tut.hpp -- which was
#included BEFORE the overloads were declared. Previous C++ compilers have
evidently made multiple passes, collecting the relevant overloads before
attempting to compile the template bodies. clang does not, complaining that
the overloads must be declared before the tut.hpp template code that
references them. Reordering parts of lltut.h seems to address that problem.
For similar reasons, test programs that use StringVec.h and its operator<<()
must #include StringVec.h before lltut.h.
Add ensure_equals(const std::string&, const LLSD::Binary&, const LLSD::Binary&)
overload. The sloppy mix of (const char*, ...) and (const std::string&, ...)
overloads bothers me, since for many of those ... types we seem to have to
duplicate them.
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
Somehow viewer-cat acquired a lot of source lines (in several different files)
of the form:
(void)somevar;
where ?somevar? was not declared. Apparently someone introduced an unused
declaration of ?somevar?, encountered unused-variable warnings, introduced the
(void) casts to suppress those warnings, then deleted the declarations --
without deleting the (void) casts. It seems worth noting that the resulting
code should not have compiled successfully on any platform.
Oz Linden