flat_map doc misleading complexity #125
Comments
|
Many thanks for the report! |
igaztanaga
added a commit
that referenced
this issue
Jul 17, 2020
This reverts commit 06417de. Revert "Fixed #128 ("moved from small_vector and static_vector calls destructor on elements in static part")" This reverts commit 2d9d28b. Revert "Fixes #126 ("flat_set.hpp and set.hpp in pmr have the same header guard")" This reverts commit 069351a. Revert "Fixes #149: ("InitializeCriticalSectionEx returns "BOOL" (int)")" This reverts commit 98b59db. Revert "Fixes #151 ("Buffer overflow in monotonic_buffer_resource::do_allocate")." This reverts commit 90de953. Revert "Enable user warnings in tests to be able to fix them." This reverts commit 4f37a02. Revert "Fix initializer_list contructor allocation count" This reverts commit 5d8e008. Revert "Update changelog for 1.74, no fixes were released in 1.73" This reverts commit 4070edd.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
the documentation of some flat_map operations has a misleading complexity guarantee. For instance,
operator[]orinsert_or_assignsay "logarithmic", but while the number of comparisons is logarithmic, the number of move/copy can be linear.emplacekind of acknowledges this ("Logarithmic search time plus linear insertion to the elements with bigger keys than x"), although it is still wrong if the capacity is exceeded.The text was updated successfully, but these errors were encountered: