Since nobody complained, I have added this new configuration macro.
I didn't apply the patches for type_traits and regex (is there a way to
know if Boost cvs contains the current version of a library or if all the
changes will be destroyed the next time the maintainer commits a new
version?).
Following on from that, there seems some overlap between your proposed
asserts and Boost.Test's BOOST_CHECK_() macros. I wonder if it would be
possible to have an assert handler for use in the unit test framework,
and
then I can use SMART_ASSERT() in both main code and in test code and
only have
Why not a generic default validator?
BTW, I know typeid (T).name() doesn't really work, but I'm not sure what
would be better.
If not totally generic, then instead at least all fundamental types could be
handled by a single generic function, using maybe is_pod to dispatch.
namespace boost {
On Fri, 23 May 2003, John Maddock wrote:
I didn't apply the patches for type_traits and regex (is there a way to
know if Boost cvs contains the current version of a library or if all the
changes will be destroyed the next time the maintainer commits a new
version?). They would benefit
Hi Neal,
Neal D. Becker wrote:
Why not a generic default validator?
Good question! I think that I planned to define specialization for common
types, like int and float in library sources, so that client code does
not have to instantinate them. As it is now, there are only specialized
version,
Alexander Terekhov wrote:
2 x Forward Inline
[snip]
There's no COW semantics here. It's rather simple, really. Any
operation that updates the use-count needs to be synchronized
with respect to other readers/writers. The basic thread safety
is pretty much the same stuff as POSIX's memory
