Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
Fixes#2392.
[SVN r49254]
other than Visual C++.
It turns out that Borland uses Dinkumware but doesn't have the C99 float
overloads, so it only seems realistic to assume their existence on Visual C++.
Refs #2264.
[SVN r48674]
https://svn.boost.org/svn/boost/branches/unordered/trunk
........
r43840 | danieljames | 2008-03-24 17:25:07 +0000 (Mon, 24 Mar 2008) | 1 line
Fix a g++ warning.
........
r43844 | danieljames | 2008-03-24 17:56:28 +0000 (Mon, 24 Mar 2008) | 1 line
It's a new-ish year.
........
r43885 | danieljames | 2008-03-27 20:36:10 +0000 (Thu, 27 Mar 2008) | 1 line
The release script doesn't need to copy images and css - because that's now done in the jamfiles. Also tweak the shell script a tad bit.
........
r43890 | danieljames | 2008-03-27 23:01:40 +0000 (Thu, 27 Mar 2008) | 1 line
Starting to add a docbook bibliography.
........
r43894 | danieljames | 2008-03-27 23:24:18 +0000 (Thu, 27 Mar 2008) | 1 line
Redeclare 'data' in iterator_base to help compilers which have trouble with accessing the nested typedef.
........
[SVN r43895]
- Unordered tests can run lightweight test or Boost.Test (at least
theoretically).
- Workaround Open BSD's incorrect numeric_limits.
- Move the hash extensions in their own file.
- Various small improvements to the unordered docs.
- Fix some unordered examples.
Merged revisions 43117-43837 via svnmerge from
https://svn.boost.org/svn/boost/branches/unordered/trunk
[SVN r43838]
https://svn.boost.org/svn/boost/branches/unordered/trunk
................
r42887 | danieljames | 2008-01-20 21:32:04 +0000 (Sun, 20 Jan 2008) | 10 lines
Merged revisions 42590-42664,42667-42697,42699-42723,42725-42855,42857-42881 via svnmerge from
https://svn.boost.org/svn/boost/trunk
........
r42881 | danieljames | 2008-01-20 17:37:21 +0000 (Sun, 20 Jan 2008) | 1 line
Include <new> to get std::bad_alloc.
........
................
r42892 | danieljames | 2008-01-21 13:03:16 +0000 (Mon, 21 Jan 2008) | 1 line
On some compilers the Rogue Wave/Apache stdcxx library doesn't have the normal std::distance, but instead has a variant that takes the result as the third parameter so it doesn't have to work out the type from the iterator.
................
r42893 | danieljames | 2008-01-21 13:07:58 +0000 (Mon, 21 Jan 2008) | 1 line
Fix a typo in the last commit.
................
r42895 | danieljames | 2008-01-21 13:33:29 +0000 (Mon, 21 Jan 2008) | 1 line
Remove tabs from the last checkin.
................
r42896 | danieljames | 2008-01-21 15:51:40 +0000 (Mon, 21 Jan 2008) | 1 line
Use Boost config to tell when we have a std::distance function. Also, no need for a macro.
................
r42908 | danieljames | 2008-01-21 21:37:04 +0000 (Mon, 21 Jan 2008) | 1 line
Use boost::long_long_type and boost::ulong_long_type.
................
r42921 | danieljames | 2008-01-23 11:43:35 +0000 (Wed, 23 Jan 2008) | 1 line
Remove some tabs.
................
r42922 | danieljames | 2008-01-23 11:46:28 +0000 (Wed, 23 Jan 2008) | 2 lines
Add missing include. Refs #1596
................
r42923 | danieljames | 2008-01-23 11:52:47 +0000 (Wed, 23 Jan 2008) | 2 lines
Always use void const* for the second parameter of allocate. Refs #1596.
................
r42936 | danieljames | 2008-01-23 22:22:16 +0000 (Wed, 23 Jan 2008) | 1 line
Use Boost style library name in the documentation.
................
r42937 | danieljames | 2008-01-23 22:22:32 +0000 (Wed, 23 Jan 2008) | 1 line
More tabs.
................
r42941 | danieljames | 2008-01-23 23:35:01 +0000 (Wed, 23 Jan 2008) | 1 line
Fix all the allocators.
................
[SVN r42943]
I think I was barking up the wrong tree - it could be that when calling
hash_value with a function pointer the compiler was choosing the
hash_value(bool) overload over the hash_value(T*) overload, so instead I'm
trying to call the correct one by giving it a template parameter. Another
alternative would be to calculate the hash function inside boost::hash.
Unfortunately, if I'm right, this means that other calls to hash_value will go
wrong for function pointers.
[SVN r39972]
Also, now only applies the workaround to function pointers, non-function
pointers are treated as before. I might need to apply the special case to
member function pointers as well.
[SVN r39960]
For the first merge with the release branch, I only want to include some of the
changes I've been working on (fixes and some trivial changes), so I'm starting
again from 1.34.1.
[SVN r38873]
extension implementation a little clearer. It also fixes a problem where the
visual C++ include once pragma was preventing the extensions from being loaded
on the second include.
[SVN r35314]
For the record: I removed the overload because it was causing an ambiguity that I was too lazy to work out at the time. It turned out this was because wchar_t was defined as unsigned short - using BOOST_NO_INTRINSIC_WCHAR_T was the right way to deal with this so the overload no longer needs to be disabled.
[SVN r33114]
1. hash_float is no longer dependent on the main hash header.
2. hash_float(0) == 0 which makes it easier to implement hash<complex>(),
although this might lead to users assuming that it can be expected even though
it isn't part of the documented interface.
[SVN r32780]
On Borland add a pointer overload of hash_range to use instead of the array workaround that I checked in earlier today.
Fix the array size calculation for compilers with function template ordering.
[SVN r28228]
instead of function overloading - which disobeys the specification of
the extension (hash_combine is defined in terms of hash_value, but hash_value
doesn't deal with every case now).
[SVN r28078]
Remove Boost.Range support when there are no const volatile specializations, as it currently requires them to compile. Hopefully this will be changed back in the future.
[SVN r27914]
