long double so
the hash function perform poorly for values out of the range
of double or if they differ at a greater precision
that double is capable of representing.
ios::internal
flag.
long double so
the hash function perform poorly for values out of the range
of double or if they differ at a greater precision
that double is capable of representing.
This library has never worked [on Borland 5.5.1 and 5.6.4], and the only tests that 'pass' are compile-fail tests failing for the wrong reasons!
These compilers are too antiquated for this library.
These compilers don't quite have the necessary support for this library, it's possible that they could be made to work if someone cares enough.
This is a compiler bug: it sometimes creates an illegal temporary object. The following code illustrates the bug:
#include <cassert>
const int global_i = 0;
struct TestingReferenceBinding
{
TestingReferenceBinding(const int& ii)
{
assert(&ii == &global_i);
}
};
int main()
{
TestingReferenceBinding ttt = global_i;
}
This failure is caused by a compiler bug, and as far as we can tell, can't be worked around in the library, although we think the library might be made safer with respect to this bug.
Specifics: the following simple test fails when it should succeed.
#include <cassert>
int const x = 0;
struct A
{
A(int const& y)
{
assert(&x == &y);
}
};
int main()
{
A a(x); // direct initialization works fine
A b = x; // copy initialization causes x to be copied before it is bound
}
The possible safety enhancement would be to cause the constructor
in question to be explicit for optional<T const&>; that
would prevent copy initialization.
Historically, Spirit supported a lot of compilers, including (to some extent) poorly conforming compilers such as VC6. Spirit v1.6.x will be the last release that will support older poorly conforming compilers. Starting from Spirit v1.8.0, ill conforming compilers will not be supported. If you are still using one of these older compilers, you can still use Spirit v1.6.x.
The reason why Spirit v1.6.x worked on old non-conforming compilers is that the authors laboriously took the trouble of searching for workarounds to make these compilers happy. The process takes a lot of time and energy, especially when one encounters the dreaded ICE or "Internal Compiler Error". Sometimes searching for a single workaround takes days or even weeks. Sometimes, there are no known workarounds. This stifles progress a lot. And, as the library gets more progressive and takes on more advanced C++ techniques, the difficulty is escalated to even new heights.
Spirit v1.6.x will still be supported. Maintenance and bug fixes will still be applied. There will still be active development for the back- porting of new features introduced in Spirit v1.8.0 (and Spirit 1.9.0) to lesser able compilers; hopefully, fueled by contributions from the community. For instance, there is already a working AST tree back-port for VC6 and VC7 by Peder Holt.
is_convertible<T,U>::value may be true for unrelated
iterators T and U
(including many of the Boost specialized adaptors) which use
enable_if_convertible to restrict the applicability
of converting constructors, even when T is not
convertible to U because instantiating the
conversion will cause a compilation failure.
T* and T& that should
have been T const* and T const&.
std::exp (long
double) on this platform.
float and double. If the test
fails, interval<float> and
interval<double> should not be used
on this compiler/platform since there will be no
numerical guarantee.
insert(iterator,range)
is not available due to partial ordering errors (the core library remains usable).
For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable).
insert(iterator,range)
is not available due to partial ordering errors (the core library remains usable).
For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable).
insert(iterator,range)
is not available due to partial ordering errors (the core library remains usable).
For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable).
transfer(range,ptr_map)
is not available due to partial ordering errors (the core library remains usable).
For codewarrior the problem is not known so please submit a patch.
transfer(range,ptr_map) and
insert(range)code>
is not available due to partial ordering errors (the core library remains usable).
For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable)..
This compiler seems to be having trouble digesting Boost.Tuple. Until it can handle Boost.Tuple there's little chance it will handle Boost.Python
.attr(name)
or expr[item],
where expr
is-a boost::python::object. We've been
unable to find a workaround.
strol symbol in the
compiler's static runtime library (libcprts.a) to
something else is known to resolve the issue.
so, etc.
std::internal flag in the iostreams implementation of the
standard library used on that compiler/platform combo. Apart from that,
the format library works as expected.