[libcxx-commits] [libcxx] [libc++] implement std::flat_set (PR #125241)

Louis Dionne via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jan 31 11:07:08 PST 2025


================
@@ -0,0 +1,853 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___FLAT_set_FLAT_SET_H
+#define _LIBCPP___FLAT_set_FLAT_SET_H
+
+#include <__algorithm/lexicographical_compare_three_way.h>
+#include <__algorithm/min.h>
+#include <__algorithm/ranges_adjacent_find.h>
+#include <__algorithm/ranges_equal.h>
+#include <__algorithm/ranges_inplace_merge.h>
+#include <__algorithm/ranges_lower_bound.h>
+#include <__algorithm/ranges_partition_point.h>
+#include <__algorithm/ranges_sort.h>
+#include <__algorithm/ranges_unique.h>
+#include <__algorithm/ranges_upper_bound.h>
+#include <__algorithm/remove_if.h>
+#include <__assert>
+#include <__compare/synth_three_way.h>
+#include <__concepts/swappable.h>
+#include <__config>
+#include <__cstddef/byte.h>
+#include <__cstddef/ptrdiff_t.h>
+#include <__flat_map/sorted_unique.h>
+#include <__functional/invoke.h>
+#include <__functional/is_transparent.h>
+#include <__functional/operations.h>
+#include <__fwd/vector.h>
+#include <__iterator/concepts.h>
+#include <__iterator/distance.h>
+#include <__iterator/iterator_traits.h>
+#include <__iterator/next.h>
+#include <__iterator/ranges_iterator_traits.h>
+#include <__iterator/reverse_iterator.h>
+#include <__memory/allocator_traits.h>
+#include <__memory/uses_allocator.h>
+#include <__memory/uses_allocator_construction.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__ranges/container_compatible_range.h>
+#include <__ranges/drop_view.h>
+#include <__ranges/from_range.h>
+#include <__ranges/ref_view.h>
+#include <__ranges/size.h>
+#include <__ranges/subrange.h>
+#include <__type_traits/conjunction.h>
+#include <__type_traits/container_traits.h>
+#include <__type_traits/invoke.h>
+#include <__type_traits/is_allocator.h>
+#include <__type_traits/is_nothrow_constructible.h>
+#include <__type_traits/is_same.h>
+#include <__utility/exception_guard.h>
+#include <__utility/move.h>
+#include <__utility/pair.h>
+#include <__utility/scope_guard.h>
+#include <__vector/vector.h>
+#include <initializer_list>
+#include <stdexcept>
+#include <type_traits>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_PUSH_MACROS
+#include <__undef_macros>
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+template <class _Key, class _Compare = less<_Key>, class _KeyContainer = vector<_Key>>
+class flat_set {
+  template <class, class, class>
+  friend class flat_set;
+
+  static_assert(is_same_v<_Key, typename _KeyContainer::value_type>);
+  static_assert(!is_same_v<_KeyContainer, std::vector<bool>>, "vector<bool> is not a sequence container");
+
+public:
+  // types
+  using key_type               = _Key;
+  using value_type             = _Key;
+  using key_compare            = __type_identity_t<_Compare>;
+  using value_compare          = _Compare;
+  using reference              = value_type&;
+  using const_reference        = const value_type&;
+  using size_type              = typename _KeyContainer::size_type;
+  using difference_type        = typename _KeyContainer::difference_type;
+  using iterator               = typename _KeyContainer::const_iterator;
----------------
ldionne wrote:

I would like to investigate whether we should really use the underlying container's iterator, or wrap it using our own iterator. One "benefit" of wrapping it would be that e.g. `std::vector<T>::iterator` won't be the same as `flat_set<vector<T>>::iterator` (which proponents of SCARY iterators think is a feature, and I'm not as convinced). Basically, it would give us additional type safety.

It may also allow inserting additional checks in the future. For example, if you have a `flat_set<RawContainer>` where `RawContainer` is a container whose iterators are raw pointers (pretty common, imagine a naive implementation of a vector). In that case, we wouldn't be able to add bounds safety to `flat_set::iterator` without wrapping it into a new type, and our experience with `std::string_view` has shown that people are quick to start relying on the fact that an iterator is a raw pointer when that's truly the case. Using a wrapped iterator immediately closes the door for such Hyrum's law exposition.

https://github.com/llvm/llvm-project/pull/125241


More information about the libcxx-commits mailing list