用户定义的文字给 C++ 添加了哪些新功能？

Question

C++11 引入用户定义的文字 这将允许基于现有文字引入新的文字语法（< code>int、hex、string、float），以便任何类型都能够进行文字表示。

示例：

// imaginary numbers
std::complex<long double> operator "" _i(long double d) // cooked form
{ 
    return std::complex<long double>(0, d); 
}
auto val = 3.14_i; // val = complex<long double>(0, 3.14)

// binary values
int operator "" _B(const char*); // raw form
int answer = 101010_B; // answer = 42

// std::string
std::string operator "" _s(const char* str, size_t /*length*/) 
{ 
    return std::string(str); 
}

auto hi = "hello"_s + " world"; // + works, "hello"_s is a string not a pointer

// units
assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

乍一看这看起来很酷，但当我尝试考虑使用后缀 _AD 和 _BC< 时，我想知道它到底有多适用/code> 创建日期 我发现由于操作员顺序而出现问题。 1974/01/06_AD 将首先评估 1974/01（作为普通 int），然后才评估 06_AD （更不用说八月和九月由于八进制原因而必须不写0）。 可以通过将语法设置为 1974-1/6_AD 来解决此问题，以便运算符评估顺序可以工作，但很笨重。

所以我的问题归结为这个，你觉得这个功能会证明自己是合理的吗？ 您还想定义哪些其他文字来使您的 C++ 代码更具可读性？

---

更新语法以适应 2011 年 6 月的最终草案

Answer 1

乍一看，这似乎是简单的语法糖。

但当深入研究时，我们发现它不仅仅是语法糖，因为它扩展了 C++ 用户的选项来创建与不同内置类型完全相同的用户定义类型。在这一点上，这个小小的“奖励” “是对 C++ 的一个非常有趣的 C++11 补充。

在 C++ 中我们真的需要它吗？

我在过去几年编写的代码中看到很少的用途，但仅仅因为我没有在 C++ 中使用它并不意味着它对另一个 C++ 开发人员不感兴趣。

我们在 C++ 中（我猜在 C 中）使用了编译器定义的文字，将整数键入为短整型或长整型，将实数键入为浮点型或双精度型（甚至长双精度型），将字符串键入为普通字符或宽字符。

在 C++ 中，我们可以创建自己的类型（即类），并且可能没有开销（内联等）。 我们可以将运算符添加到它们的类型中，让它们表现得像类似的内置类型，这使得 C++ 开发人员能够像将矩阵和复数添加到语言本身一样自然地使用矩阵和复数。 我们甚至可以添加强制转换运算符（这通常是一个坏主意，但有时，这正是正确的解决方案）。

我们仍然错过了让用户类型表现为内置类型的一件事：用户定义的文字。

因此，我想这是语言的自然演变，但要尽可能完整：“ 如果你想创建一个类型，并且希望它尽可能像内置类型那样工作，这里有一些工具......”

我猜这与 .NET 的决定非常相似使每个基元成为一个结构体，包括布尔值、整数等，并且所有结构体都派生自 Object。 仅这一决定就使 .NET 在处理原语时远远超出了 Java 的能力范围，无论 Java 将在其规范中添加多少装箱/拆箱技巧。

在 C++ 中你真的需要它吗？

这个问题需要你来回答。 不是比亚恩·斯特鲁斯特鲁普。 不是赫伯·萨特。 不是 C++ 标准委员会的任何成员。 这就是为什么您可以选择 C++，并且它们不会将有用的表示法仅限于内置类型。

如果您需要它，那么这是一个受欢迎的补充。 如果你不这样做，那么...不要使用它。 这不会花费你任何费用。

欢迎使用 C++，这种语言的功能是可选的。

肿了？？？ 让我看看你的情结！！！

臃肿和复杂（双关语）之间是有区别的。

就像 Niels 在 用户定义的文字为 C++ 添加了哪些新功能？，能够编写复数是“最近”添加到 C 和 C++ 的两个功能之一：

// C89:
MyComplex z1 = { 1, 2 } ;

// C99: You'll note I is a macro, which can lead
// to very interesting situations...
double complex z1 = 1 + 2*I;

// C++:
std::complex<double> z1(1, 2) ;

// C++11: You'll note that "i" won't ever bother
// you elsewhere
std::complex<double> z1 = 1 + 2_i ;

现在，C99 都“双精度” “complex”类型和 C++“std::complex”类型可以使用运算符重载进行乘法、加法、减法等操作。

但在 C99 中，他们只是添加了另一种类型作为内置类型，以及内置运算符重载支持。 他们还添加了另一个内置的文字功能。

在C++中，他们只是使用了该语言的现有功能，看到文字功能是该语言的自然演变，因此添加了它。

在 C 语言中，如果您需要对另一种类型进行相同的符号增强，那么您就很不幸，直到您游说将您的量子波函数（或 3D 点，或您在工作领域中使用的任何基本类型）添加到C 标准作为内置类型取得了成功。

在C++11中，你自己就可以了：

Point p = 25_x + 13_y + 3_z ; // 3D point

是不是很臃肿？ 不，需求是存在的，正如 C 和 C++ 复合体都需要一种方法来表示其字面复数值所示。

是设计错误吗？ 不，它的设计与所有其他 C++ 功能一样，都考虑到了可扩展性。

仅用于符号目的吗？ 不，因为它甚至可以为您的代码添加类型安全性。

例如，让我们想象一个面向 CSS 的代码：

css::Font::Size p0 = 12_pt ;       // Ok
css::Font::Size p1 = 50_percent ;  // Ok
css::Font::Size p2 = 15_px ;       // Ok
css::Font::Size p3 = 10_em ;       // Ok
css::Font::Size p4 = 15 ;         // ERROR : Won't compile !

然后很容易对值的分配强制执行强类型。

有危险吗？

好问题。 这些函数可以命名空间吗？ 如果是的话，那么大奖！

不管怎样，就像所有事情一样，如果工具使用不当，你可能会自杀。 C威力强大，用错C枪就能打爆你的头。 C++ 不仅有 C 枪，还有手术刀、泰瑟枪以及您在工具包中可以找到的任何其他工具。 您可能会误用手术刀而失血过多而死。 或者您可以构建非常优雅和健壮的代码。

那么，就像所有 C++ 功能一样，您真的需要它吗？ 这是在 C++ 中使用它之前必须回答的问题。 如果您不这样做，您将无需付出任何代价。 但如果您确实需要它，至少该语言不会让您失望。

日期示例？

在我看来，你的错误在于你混合了运算符：

1974/01/06AD
    ^  ^  ^

这是无法避免的，因为 / 作为一个运算符，编译器必须解释它。 而且，据我所知，这是一件好事。

为了找到问题的解决方案，我会用其他方式编写文字。 例如：就

"1974-01-06"_AD ;   // ISO-like notation
"06/01/1974"_AD ;   // french-date-like notation
"jan 06 1974"_AD ;  // US-date-like notation
19740106_AD ;       // integer-date-like notation

个人而言，我会选择整数和 ISO 日期，但这取决于您的需求。 这就是让用户定义自己的文字名称的全部意义所在。

Answer 2

在这种情况下，使用用户定义的文字而不是构造函数调用有一个优点：

#include <bitset>
#include <iostream>

template<char... Bits>
  struct checkbits
  {
    static const bool valid = false;
  };

template<char High, char... Bits>
  struct checkbits<High, Bits...>
  {
    static const bool valid = (High == '0' || High == '1')
                   && checkbits<Bits...>::valid;
  };

template<char High>
  struct checkbits<High>
  {
    static const bool valid = (High == '0' || High == '1');
  };

template<char... Bits>
  inline constexpr std::bitset<sizeof...(Bits)>
  operator"" _bits() noexcept
  {
    static_assert(checkbits<Bits...>::valid, "invalid digit in binary string");
    return std::bitset<sizeof...(Bits)>((char []){Bits..., '\0'});
  }

int
main()
{
  auto bits = 0101010101010101010101010101010101010101010101010101010101010101_bits;
  std::cout << bits << std::endl;
  std::cout << "size = " << bits.size() << std::endl;
  std::cout << "count = " << bits.count() << std::endl;
  std::cout << "value = " << bits.to_ullong() << std::endl;

  //  This triggers the static_assert at compile time.
  auto badbits = 2101010101010101010101010101010101010101010101010101010101010101_bits;

  //  This throws at run time.
  std::bitset<64> badbits2("2101010101010101010101010101010101010101010101010101010101010101_bits");
}

优点是运行时异常会转换为编译时错误。
您无法将静态断言添加到采用字符串的位集构造器中（至少不能在没有字符串模板参数的情况下）。

Answer 3

这对于数学代码来说非常好。 我突然想到了以下运算符的用途：

deg 表示度数。 这使得书写绝对角度更加直观。

double operator ""_deg(long double d)
{ 
    // returns radians
    return d*M_PI/180; 
}

它还可用于各种定点表示（仍在 DSP 和图形领域使用）。

int operator ""_fix(long double d)
{ 
    // returns d as a 1.15.16 fixed point number
    return (int)(d*65536.0f); 
}

这些看起来像是如何使用它的很好的例子。 它们有助于使代码中的常量更具可读性。 它也是使代码变得不可读的另一种工具，但我们已经有太多工具被滥用，再多一个也不会造成太大影响。

Answer 4

UDL 是命名空间的（并且可以通过使用声明/指令导入，但您不能显式命名像 3.14std::i 这样的文字），这意味着（希望）不会有大量冲突。

事实上，它们实际上可以被模板化（和 constexpr'd），这意味着您可以使用 UDL 做一些非常强大的事情。 Bigint 作者会非常高兴，因为他们最终可以拥有任意大的常量，在编译时计算（通过 constexpr 或模板）。

我只是感到遗憾的是，我们不会在标准中看到一些有用的文字（从外观上看），例如 s 代表 std::string 和 >i 为虚数单位。

UDL 节省的编码时间实际上并没有那么高，但可读性将大大提高，并且越来越多的计算可以转移到编译时以加快执行速度。

Answer 5

Bjarne Stroustrup 在这个 C++11 演讲中谈论 UDL ，第一部分关于类型丰富的界面，大约 20 分钟。

他对 UDL 的基本论证采用三段论的形式：

1. “琐碎”类型，即内置原始类型，只能捕获琐碎的类型错误。 具有更丰富类型的接口允许类型系统捕获更多类型的错误。

2. 丰富类型代码可以捕获的类型错误类型会对实际代码产生影响。 （他举了火星气候轨道飞行器的例子，该飞行器因重要常量的尺寸错误而臭名昭著地失败了）。

3. 在实际代码中，很少使用单位。 人们不使用它们，因为创建丰富类型所需的运行时计算或内存开销成本太高，而且使用预先存在的 C++ 模板化单元代码在名义上非常丑陋，以至于没有人使用它。 （根据经验，没有人使用它，尽管这些库已经存在了十年）。

4. 因此，为了让工程师在实际代码中使用单元，我们需要一种设备，该设备 (1) 不会产生运行时开销，并且 (2) 在符号上是可以接受的。

Answer 6

让我添加一些背景信息。 对于我们的工作来说，非常需要用户定义的文字。 我们致力于 MDE（模型驱动工程）。 我们想要用 C++ 定义模型和元模型。 我们实际上实现了从 Ecore 到 C++ 的映射 (EMF4CPP)。

当能够将模型元素定义为 C++ 中的类时，问题就出现了。 我们正在采取将元模型（Ecore）转换为带有参数的模板的方法。 模板的参数是类型和类的结构特征。 例如，具有两个 int 属性的类将类似于：

typedef ::ecore::Class< Attribute<int>, Attribute<int> > MyClass;

然而，事实证明，模型或元模型中的每个元素通常都有一个名称。 我们想写：

typedef ::ecore::Class< "MyClass", Attribute< "x", int>, Attribute<"y", int> > MyClass;

但是，C++ 和 C++0x 都不允许这样做，因为字符串被禁止作为模板的参数。 您可以逐个字符地编写名称，但这无疑是一团糟。 使用正确的用户定义文字，我们可以编写类似的内容。 假设我们使用“_n”来标识模型元素名称（我不使用确切的语法，只是为了提出一个想法）：

typedef ::ecore::Class< MyClass_n, Attribute< x_n, int>, Attribute<y_n, int> > MyClass;

最后，将这些定义作为模板可以帮助我们设计用于遍历模型元素、模型转换的算法等等，这确实很高效，因为类型信息、标识、转换等都是由编译器在编译时确定的。

Answer 7

支持编译时维度检查是唯一需要的理由。

auto force = 2_N; 
auto dx = 2_m; 
auto energy = force * dx; 

assert(energy == 4_J); 

例如，请参阅 PhysUnits-CT-Cpp11，这是一个小型 C++11、C++14 头文件库用于编译时维度分析以及单位/数量操作和转换。 比 Boost.Units 简单，支持 单位符号文字，例如 m、g、s、公制前缀，例如 m、k、M，仅取决于标准 C++ 库、仅 SI、维度的整数幂。

Answer 8

嗯...我还没有想过这个功能。 您的样本经过深思熟虑，而且确实很有趣。 C++ 和现在一样非常强大，但不幸的是，您阅读的代码片段中使用的语法有时过于复杂。 可读性即使不是全部，也至少是很多。 这样的功能将是为了提高可读性。 如果我举你的最后一个例子

assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

……我想知道你今天会如何表达。 你有一个 KG 和一个 LB 类，并且你可以比较隐式对象：

assert(KG(1.0f) == LB(2.2f));

这样也可以。 对于名称较长的类型或您不希望在不编写适配器的情况下拥有如此好的构造函数的类型，它可能是动态隐式对象创建和初始化的一个很好的补充。 另一方面，您也可以使用方法创建和初始化对象。

但我同意尼尔斯关于数学的观点。 例如，C 和 C++ 三角函数需要以弧度输入。 我认为以度为单位，所以像 Nils 发布的非常短的隐式转换非常好。

最终，它将成为语法糖，但会对可读性产生轻微影响。 写一些表达式可能也会更容易（sin(180.0deg)比sin(deg(180.0))更容易写。然后就会有人滥用这个概念。但是，滥用语言的人应该使用限制性很强的语言，而不是像 C++ 这样富有表现力的语言。

啊，我的帖子基本上什么也没说，除了：没关系，影响不会太大:-)。

Answer 9

我从来没有需要或想要这个功能（但这可能是 Blub 效果）。 我的本能反应是它很蹩脚，并且可能会吸引那些认为对任何可以远程解释为添加的操作重载operator+很酷的人。

Answer 10

C++ 通常对使用的语法非常严格 - 除了预处理器之外，没有太多可以用来定义自定义语法/语法的东西。 例如，我们可以重载现有的操作符，但我们不能定义新的操作符 - IMO，这非常符合 C++ 的精神。

我不介意一些更定制的源代码的方法 - 但选择的点对我来说似乎非常孤立，这最让我困惑。

即使是预期的用途也可能会使阅读源代码变得更加困难：单个字母可能会产生巨大的副作用，而这些副作用是无法从上下文中识别出来的。 由于 u、l 和 f 对称，大多数开发人员会选择单个字母。

这也可能会将范围界定变成一个问题，在全局命名空间中使用单个字母可能会被认为是不好的做法，而被认为更容易混合库的工具（命名空间和描述性标识符）可能会达不到其目的。

我看到与“auto”结合的一些优点，也与诸如 增强单位，但不足以值得添加此内容。

然而，我想知道我们想出了什么聪明的主意。

Answer 11

我将用户文字用于二进制字符串，如下所示：

 "asd\0\0\0\1"_b

使用 std::string(str, n) 构造函数，以便 \0 不会将字符串切成两半。 （该项目对各种文件格式进行了大量工作。）

当我放弃 std::string 而转而使用 std::vector 的包装器时，这也很有帮助。

Answer 12

那东西里的线路噪音很大。 读起来也很可怕。

让我知道，他们是否通过任何示例推断了新语法的添加？ 例如，他们是否有几个已经使用 C++0x 的程序？

对我来说，这部分：

auto val = 3.14_i

不能证明这部分合理：

std::complex<double> operator ""_i(long double d) // cooked form
{ 
    return std::complex(0, d);
}

即使您也在其他 1000 行中使用 i 语法也是如此。 如果你写作，你可能还会写 10000 行其他内容。 特别是当你仍然可能在大多数地方写下这个：

std::complex<double> val = 3.14i

'auto' - 关键字可能是合理的，但只是也许。 但我们只看 C++，因为它在这方面比 C++0x 更好。

std::complex<double> val = std::complex(0, 3.14);

就好像……就这么简单。 即使你在任何地方都使用它，所有的 std 和尖括号都是蹩脚的。 我不会开始猜测 C++0x 中用于将 std::complex 转换为复杂的语法。

complex = std::complex<double>;

这也许是很简单的事情，但我不认为在 C++0x 中那么简单。

typedef std::complex<double> complex;

complex val = std::complex(0, 3.14);

也许？ >:)

无论如何，重点是：写 3.14i 而不是 std::complex(0, 3.14); 除了少数超级特殊情况外，总体而言并不会为您节省太多时间。