水文：如何在 Mac 上使用 views::enumerate?

回到家中几乎什么都不想干，荒废了 🥺

起因是一道简单题

3379. 转换数组

在尝试学习 ranges 和 views 的アイラちゃん显然不会放弃“简单题复杂做”的雷霆想法，因此就尝试写出了面条代码：

class Solution {
public:
    vector<int> constructTransformedArray(vector<int> &nums) {
        int n = nums.size();
        return nums | views::enumerate | views::transform([&](auto &&tup) { const auto &[i, num] = tup;
                                   return nums[((i + num) % n + n) % n]; }) | std::ranges::to<std::vector>();
    }
};

可以运行 ^[1] 来查看这个执行的结果。

pipeline 运算符 `|`

我们首先来看 pipeline 运算符的定义：在 C++20 的 ranges 库中有这样的定义：

template<typename _Self, typename _Range>
    requires __is_range_adaptor_closure<_Self>
      && __adaptor_invocable<_Self, _Range>
    constexpr auto
    operator|(_Range&& __r, _Self&& __self)
    { return std::forward<_Self>(__self)(std::forward<_Range>(__r)); }

requires 子句要求_Self 类是一个 range_adaptor_closure 类型，这个类型是一个辅助模板类型，用于定义 RangeAdaptorClosureObject。
- RangeAdaptorClosureObject 其实就构成了 pipeline 运算符 | 的语义，如果我们有一个对象 C 是一个 RangeAdaptorClosureObject，一个 R 是一个 Range，那么我们就有以下的等价语义：^[2]
- C(R) <=> R | C
- 更复杂一点，我们可以将多个闭包串起来：d(c(R)) <=> R | c | d
operator | 将会利用经典的完美转发 std::forward，因此我们实际上将会调用的是 | 右侧的 operator () 的重载。
views::enumerate 将会把 range 转换成一个 tuple (index, elements)，在迭代过程中我们可以获取当前迭代器的下标。

这样我们的例子实际上等效于 ^[3]：

    int n = nums.size();
    std::vector<int> ans = std::ranges::to<std::vector>(
        std::views::transform(
            [&](auto &&tup) {
                const auto &[i, num] = tup;
                return nums[((i + num) % n + n) % n];
            })(
            std::views::enumerate(nums)));

实际上使用的时候不要想的这么复杂。想象 | 就是一根水管。在调用 std::next()，也就是迭代的时候，| 左侧将会有一个迭代器对应的元素，经过 | 右侧的变换，得到新的元素。就像 next 是水阀，每调用一次就会将一个元素送入水管，经过加工后输出新的成品。

在 rust 里这样的写法更加常见。我们可以：

fn construct_transformed_array(nums: Vec<i32>) -> Vec<i32> {
        let n = nums.len();
        let ans:Vec<i32> = nums
            .iter()
            .enumerate()
            .map(|(i, &num)| nums[(((i as i32 + num as i32) % (n as i32) + (n as i32)) % (n as i32)) as usize])
            .collect();
        ans
    }

编译不通过！CMake 尝试混搭 clang+libstdc++

但是问题来了，我们在 Mac 上编译不通过！！！经过查询以后，我们很遗憾地发现 ^[4]：

截屏 2026-02-06 21.12.54|690x199

这又是折腾的一个好机会，我们既不想放弃 LLVM 提供的编译器和 LLDB，也想使用 views::enumerate，但是 LLVM 对应的 libc++ 又没有实现，该怎么办呢？我们就需要在 CMakeLists.txt 里面进行魔改，来在前端和中间端采用 LLVM，后端链接上 libstdc++。

我们还是用 brew 来折腾我们的 mac：

brew install llvm
brew install gcc

这样我们就有了一个 clang 21 和一个 gcc 15.2。

然后我们开始编写 CMakeLists 来魔改我们的后端。首先还是经典起手：

cmake_minimum_required(VERSION 3.26)
project(main)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

接着我们寻找 gcc 的相关路径和头文件，设置我们的 clang 编译器，查找对应的 GCC 及其版本。

# 可以利用 which clang which gcc 来找。
# 一般在 linux brew 上为：/home/linuxbrew/.linuxbrew/opt/xxx
set(LLVM_PREFIX "/opt/homebrew/opt/llvm")
file(GLOB GCC_PREFIX "/opt/homebrew/opt/gcc") 
set(CMAKE_C_COMPILER "${LLVM_PREFIX}/bin/clang")
set(CMAKE_CXX_COMPILER "${LLVM_PREFIX}/bin/clang++")

# 查找 GCC 版本 (我们这里是 15)
file(GLOB GCC_INCLUDE_DIRS "${GCC_PREFIX}/include/c++/*")
list(GET GCC_INCLUDE_DIRS 0 GCC_CPP_PATH)
get_filename_component(GCC_VER "${GCC_CPP_PATH}" NAME) 
message(STATUS "Found GCC Path: ${GCC_PREFIX}")
message(STATUS "Using libstdc++ version: ${GCC_VER}")

禁用相关的 clang 的默认 libc++ 的库，并且 LLVM 生成的调试信息为 gdwarf-5，我们的 Mac 自带的链接器 ld 仅支持 gdwarf-4 的调试信息。因此我们也采用 brew install lld，加上：

add_compile_options("-nostdinc++")
add_link_options("-fuse-ld=lld")

我们需要依照顺序注入 GCC 的头文件，提供给前端的 Clang：

include_directories(SYSTEM "${GCC_CPP_PATH}")
# 这里根据 ls /opt/homebrew/opt/gcc/include/c++/15 中的第一个文件夹就是。这里是重要的根据对应的系统架构的相关配置，供 C++ 的内置函数进行系统调用。
include_directories(SYSTEM "${GCC_CPP_PATH}/aarch64-apple-darwin24")
# 兼容性文件，是一些古老的玩意儿～
include_directories(SYSTEM "${GCC_CPP_PATH}/backward")

最后补充全 clang 的相关配置，防止 stddef.h 之类的文件是丢失的导致编译失败，链接时提示链接器去 GCC 的 lib 中寻找 libstdc++。

execute_process(COMMAND ${CMAKE_CXX_COMPILER} -print-resource-dir
    OUTPUT_VARIABLE CLANG_RESOURCE_DIR
    OUTPUT_STRIP_TRAILING_WHITESPACE
)
include_directories(SYSTEM "${CLANG_RESOURCE_DIR}/include")
add_link_options("-L${GCC_PREFIX}/lib/gcc/${GCC_VER}")
add_link_options("-stdlib=libstdc++") 
# 显示设置 rpath。
add_link_options("-Wl,-rpath,${GCC_PREFIX}/lib/gcc/${GCC_VER}")

最后加上构建目标就可以了。

include_directories(templates)      # 其他文件夹
add_executable(main main.cpp)    # 目标文件

这样我们就完成了利用 clang + libstdc++ 的魔幻搭配。

什么时候使用 range？

接下来其实有一个问题：我们什么时候使用 ranges？什么时候使用 for loop？ranges 的这类 pipe 运算符，以及 Rust 中的 map 都看起来和 for loop 的表现很像，但其实也有很大的区别。

在 C++ 中，ranges 通常比 for loop 慢 ^[5]，而 Rust 的性能相近 ^[6]。原因我还不太清楚。

而在 Rust 中，我们其实有了一点点提示，关于什么时候使用 ranges^[7]：

map() is conceptually similar to a for loop. However, as map() is
lazy, it is best used when you’re already working with other iterators.
If you’re doing some sort of looping for a side effect, it’s considered
more idiomatic to use for than map().

在执行迭代（消费）操作的时候采用 iters，而在拥有外部修改效果（打印，完全遍历 IO）的时候，我们则需要进行 for loop。

アイラちゃん

アイラちゃん

📝 User Blog Posts (1 posts)