NEWS 8.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193
  1. == 12 October 2015 ==
  2. Various small fixes to ensure compilation on modern compilers and operating
  3. systems. Tagged as 2.0.3
  4. == 23 February 2012 ==
  5. A backwards incompatibility arose from flattening the include headers
  6. structure for the <google> folder.
  7. This is now fixed in 2.0.2. You only need to upgrade if you had previously
  8. included files from the <google/sparsehash> folder.
  9. == 1 February 2012 ==
  10. A minor bug related to the namespace switch from google to sparsehash
  11. stopped the build from working when perftools is also installed.
  12. This is now fixed in 2.0.1. You only need to upgrade if you have perftools
  13. installed.
  14. == 31 January 2012 ==
  15. I've just released sparsehash 2.0.
  16. The `google-sparsehash` project has been renamed to `sparsehash`. I
  17. (csilvers) am stepping down as maintainer, to be replaced by the team
  18. of Donovan Hide and Geoff Pike. Welcome to the team, Donovan and
  19. Geoff! Donovan has been an active contributor to sparsehash bug
  20. reports and discussions in the past, and Geoff has been closely
  21. involved with sparsehash inside Google (in addition to writing the
  22. [http://code.google.com/p/cityhash CityHash hash function]). The two
  23. of them together should be a formidable force. For good.
  24. I bumped the major version number up to 2 to reflect the new community
  25. ownership of the project. All the
  26. [http://sparsehash.googlecode.com/svn/tags/sparsehash-2.0/ChangeLog changes]
  27. are related to the renaming.
  28. The only functional change from sparsehash 1.12 is that I've renamed
  29. the `google/` include-directory to be `sparsehash/` instead. New code
  30. should `#include <sparsehash/sparse_hash_map>`/etc. I've kept the old
  31. names around as forwarding headers to the new, so `#include
  32. <google/sparse_hash_map>` will continue to work.
  33. Note that the classes and functions remain in the `google` C++
  34. namespace (I didn't change that to `sparsehash` as well); I think
  35. that's a trickier transition, and can happen in a future release.
  36. === 18 January 2011 ===
  37. The `google-sparsehash` Google Code page has been renamed to
  38. `sparsehash`, in preparation for the project being renamed to
  39. `sparsehash`. In the coming weeks, I'll be stepping down as
  40. maintainer for the sparsehash project, and as part of that Google is
  41. relinquishing ownership of the project; it will now be entirely
  42. community run. The name change reflects that shift.
  43. === 20 December 2011 ===
  44. I've just released sparsehash 1.12. This release features improved
  45. I/O (serialization) support. Support is finally added to serialize
  46. and unserialize `dense_hash_map`/`set`, paralleling the existing code
  47. for `sparse_hash_map`/`set`. In addition, the serialization API has
  48. gotten simpler, with a single `serialize()` method to write to disk,
  49. and an `unserialize()` method to read from disk. Finally, support has
  50. gotten more generic, with built-in support for both C `FILE*`s and C++
  51. streams, and an extension mechanism to support arbitrary sources and
  52. sinks.
  53. There are also more minor changes, including minor bugfixes, an
  54. improved deleted-key test, and a minor addition to the `sparsetable`
  55. API. See the [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.12/ChangeLog ChangeLog]
  56. for full details.
  57. === 23 June 2011 ===
  58. I've just released sparsehash 1.11. The major user-visible change is
  59. that the default behavior is improved -- using the hash_map/set is
  60. faster -- for hashtables where the key is a pointer. We now notice
  61. that case and ignore the low 2-3 bits (which are almost always 0 for
  62. pointers) when hashing.
  63. Another user-visible change is we've removed the tests for whether the
  64. STL (vector, pair, etc) is defined in the 'std' namespace. gcc 2.95
  65. is the most recent compiler I know of to put STL types and functions
  66. in the global namespace. If you need to use such an old compiler, do
  67. not update to the latest sparsehash release.
  68. We've also changed the internal tools we use to integrate
  69. Googler-supplied patches to sparsehash into the opensource release.
  70. These new tools should result in more frequent updates with better
  71. change descriptions. They will also result in future ChangeLog
  72. entries being much more verbose (for better or for worse).
  73. A full list of changes is described in
  74. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.11/ChangeLog ChangeLog].
  75. === 21 January 2011 ===
  76. I've just released sparsehash 1.10. This fixes a performance
  77. regression in sparsehash 1.8, where sparse_hash_map would copy
  78. hashtable keys by value even when the key was explicitly a reference.
  79. It also fixes compiler warnings from MSVC 10, which uses some c++0x
  80. features that did not interact well with sparsehash.
  81. There is no reason to upgrade unless you use references for your
  82. hashtable keys, or compile with MSVC 10. A full list of changes is
  83. described in
  84. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.10/ChangeLog ChangeLog].
  85. === 24 September 2010 ===
  86. I've just released sparsehash 1.9. This fixes a size regression in
  87. sparsehash 1.8, where the new allocator would take up space in
  88. `sparse_hash_map`, doubling the sparse_hash_map overhead (from 1-2
  89. bits per bucket to 3 or so). All users are encouraged to upgrade.
  90. This change also marks enums as being Plain Old Data, which can speed
  91. up hashtables with enum keys and/or values. A full list of changes is
  92. described in
  93. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.9/ChangeLog ChangeLog].
  94. === 29 July 2010 ===
  95. I've just released sparsehash 1.8. This includes improved support for
  96. `Allocator`, including supporting the allocator constructor arg and
  97. `get_allocator()` access method.
  98. To work around a bug in gcc 4.0.x, I've renamed the static variables
  99. `HT_OCCUPANCY_FLT` and `HT_SHRINK_FLT` to `HT_OCCUPANCY_PCT` and
  100. `HT_SHRINK_PCT`, and changed their type from float to int. This
  101. should not be a user-visible change, since these variables are only
  102. used in the internal hashtable classes (sparsehash clients should use
  103. `max_load_factor()` and `min_load_factor()` instead of modifying these
  104. static variables), but if you do access these constants, you will need
  105. to change your code.
  106. Internally, the biggest change is a revamp of the test suite. It now
  107. has more complete coverage, and a more capable timing tester. There
  108. are other, more minor changes as well. A full list of changes is
  109. described in the
  110. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.8/ChangeLog ChangeLog].
  111. === 31 March 2010 ===
  112. I've just released sparsehash 1.7. The major news here is the
  113. addition of `Allocator` support. Previously, these hashtable classes
  114. would just ignore the `Allocator` template parameter. They now
  115. respect it, and even inherit `size_type`, `pointer`, etc. from the
  116. allocator class. By default, they use a special allocator we provide
  117. that uses libc `malloc` and `free` to allocate. The hash classes
  118. notice when this special allocator is being used, and use `realloc`
  119. when it can. This means that the default allocator is significantly
  120. faster than custom allocators are likely to be (since realloc-like
  121. functionality is not supported by STL allocators).
  122. There are a few more minor changes as well. A full list of changes is
  123. described in the
  124. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.7/ChangeLog ChangeLog].
  125. === 11 January 2010 ===
  126. I've just released sparsehash 1.6. The API has widened a bit with the
  127. addition of `deleted_key()` and `empty_key()`, which let you query
  128. what values these keys have. A few rather obscure bugs have been
  129. fixed (such as an error when copying one hashtable into another when
  130. the empty_keys differ). A full list of changes is described in the
  131. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.6/ChangeLog ChangeLog].
  132. === 9 May 2009 ===
  133. I've just released sparsehash 1.5.1. Hot on the heels of sparsehash
  134. 1.5, this release fixes a longstanding bug in the sparsehash code,
  135. where `equal_range` would always return an empty range. It now works
  136. as documented. All sparsehash users are encouraged to upgrade.
  137. === 7 May 2009 ===
  138. I've just released sparsehash 1.5. This release introduces tr1
  139. compatibility: I've added `rehash`, `begin(i)`, and other methods that
  140. are expected to be part of the `unordered_map` API once `tr1` in
  141. introduced. This allows `sparse_hash_map`, `dense_hash_map`,
  142. `sparse_hash_set`, and `dense_hash_set` to be (almost) drop-in
  143. replacements for `unordered_map` and `unordered_set`.
  144. There is no need to upgrade unless you need this functionality, or
  145. need one of the other, more minor, changes described in the
  146. [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.5/ChangeLog ChangeLog].