- More template use, less preprocessor use.
- Removed some of the Visual C++ 6 workarounds.
- Reduced memory use of the main object.
- Split into smaller headers.
[SVN r55878]
anything which depends on the new move library.
------------------------------------------------------------------------
r52746 | danieljames | 2009-05-03 11:12:30 +0100 (Sun, 03 May 2009) | 1 line
Merge latest unordered container changes.
------------------------------------------------------------------------
r52747 | danieljames | 2009-05-03 11:15:35 +0100 (Sun, 03 May 2009) | 4 lines
Put the C++0x emplace implementations before the non-C++0x versions.
I'm going to change the non-C++0x to be macro heavy emulations of the
C++0x versions, so this will put the readable version first.
------------------------------------------------------------------------
r52748 | danieljames | 2009-05-03 11:15:44 +0100 (Sun, 03 May 2009) | 1 line
Refactor the unordered implementation a tad, to make implementing emplace less painful.
------------------------------------------------------------------------
[SVN r52884]
This feels like overkill but it seems to be the most reliable way to ensure
that the length is correct. I obviously can't be trusted to get it right, and
the template hack seems to prevent Boost.Range from working.
[SVN r52711]
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]
As these are extensions and add extra requirements to the container elements,
they shouldn't be part of hash_table_data_* so that they won't get instantiated
if an unordered container is explicitly instantiated.
Merged revisions 46594-46604 via svnmerge from
https://svn.boost.org/svn/boost/branches/unordered/trunk
[SVN r46607]
On some compilers, friend functions are being instantiated when the main class
is explicitly instantiated. This is slightly problematic because the equality
functions (which are an extension) put extra requirements on the types used. So
I'm going to try defining the functions outside of the class, in the hope that
they won't get instantiated. If someone wants non-member functions to be
instantiated, I think it's reasonable to expect them to explicitly instantiate
them, especially as compilers don't seem to be consistent about this.
[SVN r46579]
