gpt4 book ai didi

c++ - 借助 static_assert 改进诊断

转载 作者:可可西里 更新时间:2023-11-01 16:38:12 36 4
gpt4 key购买 nike

在模板编程中,static_assert 帮助程序员检查模板参数的约束并在违反约束时生成人类可读错误消息。

考虑这段代码,

template<typename T>
void f(T)
{
static_assert(T(), "first requirement failed to meet.");

static_assert(T::value, "second requirement failed to meet.");

T t = 10; //even this may generate error!
}

我的想法是:如果第一个 static_assert 失败,这意味着 一些 T 的要求不满足,因此编译应该停止,只生成第一个错误消息——因为继续编译只是为了生成越来越多的错误消息没有多大意义,其中大部分经常指向一个单个 违反约束。数百条错误消息,而不是一条,在屏幕上看起来非常可怕 — 我什至会说,它在某种程度上违背了 static_assert目的

例如,如果我将上面的函数模板调用为:

f(std::false_type{});

GCC 4.8 生成以下内容:

main.cpp: In instantiation of 'void f(T) [with T = std::integral_constant<bool, false>]':
main.cpp:16:24: required from here
main.cpp:7:5: error: static assertion failed: first requirement failed to meet.
static_assert(T(), "first requirement failed to meet.");
^
main.cpp:9:5: error: static assertion failed: second requirement failed to meet.
static_assert(T::value, "second requirement failed to meet.");
^
main.cpp:11:11: error: conversion from 'int' to non-scalar type 'std::integral_constant<bool, false>' requested
T t = 10; //even this may generate error!

如您所见 ( online ),错误太多了。如果第一个 static_assert 失败,如果继续编译,很可能其余代码也会失败,那为什么还要继续编译呢?在模板编程中,我敢肯定很多程序员不希望出现这样的级联错误消息!

我试图通过函数拆分成多个函数来解决这个问题,每个函数只检查一个约束,如:

template<typename T>
void f_impl(T); //forward declaration

template<typename T>
void f(T)
{
static_assert(T(), "first requirement failed to meet.");
f_impl(T());
}

template<typename T>
void f_impl(T)
{
static_assert(T::value, "second requirement failed to meet.");
T t = 10;
}

f(std::false_type{}); //call

现在生成这个:

main.cpp: In instantiation of 'void f(T) [with T = std::integral_constant<bool, false>]':
main.cpp:24:24: required from here
main.cpp:10:5: error: static assertion failed: first requirement failed to meet.
static_assert(T(), "first requirement failed to meet.");
^

这是很大的改进——只有一条错误消息更容易阅读和理解(参见 online)。

我的问题是,

  • 为什么编译不会在第一个 static_assert 处停止?
  • 由于拆分函数模板并在每个 function_impl 中检查一个约束, GCC 和 clang 仍然有帮助 generates lots of error ,是否有任何方法可以以更一致的方式改进诊断——适用于所有编译器的方法?

最佳答案

我同意 David Rodríguez 的观点 - dribeas 和为编译器编写者辩护考虑这个例子:

#include <type_traits>

class A {};

// I want the nice error message below in several functions.
// Instead of repeating myself, let's put it in a function.
template <typename U>
void check() {
static_assert(std::is_convertible<U*, const volatile A*>::value,
"U doesn't derive publicly from A "
"(did you forget to include it's header file?)");
}

template <typename U>
void f(U* u) {
// check legality (with a nice error message)
check<U>();
// before trying a failing initialization:
A* p = u;
}

class B; // I forget to include "B.h"

int main() {
B* b = nullptr;
f(b);
}

实例化f<B>时启动编译器(或编译器编写者)可能会想:“嗯......我需要实例化 check<U> 人们总是提示编译模板太慢。所以我会继续,也许下面有问题,我不事件不需要实例化 check。”

我相信上面的推理是有道理的。 (请注意,我不是编译器编写者,所以我只是在这里推测)。

GCC 4.8 和 VS2010 都继续编译 f<B> , 推迟 check<B> 的实例化为以后。然后他们找到失败的初始化并提供他们自己的错误消息。 VS2010 立即停止,我没有收到很好的错误消息! GCC 继续运行并产生我想要的消息(但仅在它自己之后)。

元编程对程序员和编译器来说都是棘手的。 static_assert帮助很多,但它不是 Elixir 。

关于c++ - 借助 static_assert 改进诊断,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20335007/

36 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com