我在boost.hana邮件列表中看到了以下示例,该示例无法编译:
#include <boost/hana.hpp>
#include <string>
namespace hana = boost::hana;
int main(int argc, char **argv) {
constexpr auto m1 = hana::make_map(
hana::make_pair("key1"_s, hana::type_c<std::string>),
hana::make_pair("key2"_s, hana::type_c<std::string>)
);
}
我在GCC 7.3.0 -std = c ++ 14上收到以下错误:
error: unable to find string literal operator ‘operator""_s’ with ‘const char [5]’, ‘long unsigned int’ arguments
hana::make_pair("key1"_s, hana::type_c<std::string>),
^~~~~~~~
顺便说一下,字符串文字的__s后缀是什么?
答案 0 :(得分:2)
Boost.Hana的_s
使用的编译时字符串文字运算符是gcc扩展,必须通过定义BOOST_HANA_CONFIG_ENABLE_STRING_UDL
来启用。
还必须将操作符从boost::hana::literals
导入到当前名称空间中。
或者,可以使用宏BOOST_HANA_STRING
,但是它使用lambda,并且不能在C ++ 14中进行constexpr。
尽管尚未最终确定,但C ++ 20可能会将此运算符以及字符串文字用作模板参数,这很令人兴奋。 (here)
这是一个完整的示例:
#define BOOST_HANA_CONFIG_ENABLE_STRING_UDL
#include <boost/hana.hpp>
namespace hana = boost::hana;
using namespace hana::literals;
int main() {
constexpr auto m1 = hana::make_map(
hana::make_pair("key1"_s, hana::type_c<void>),
hana::make_pair("key2"_s, hana::type_c<void>)
);
constexpr auto m3 = hana::make_map(
hana::make_pair(hana::string<'k','e','y','1'>{}, hana::type_c<void>),
hana::make_pair(hana::string<'k','e','y','2'>{}, hana::type_c<void>)
);
// not constexpr until C++17
auto m2 = hana::make_map(
hana::make_pair(BOOST_HANA_STRING("key1"), hana::type_c<void>),
hana::make_pair(BOOST_HANA_STRING("key2"), hana::type_c<void>)
);
}
答案 1 :(得分:0)
未编译的原因实际上是«_s»后缀。解决方案:使用-DBOOST_HANA_CONFIG_ENABLE_STRING_UDL
进行编译。
或者用hana::string_c<'k', 'e', 'y', '1'>
代替"key1"_s
,用hana::string_c<'k', 'e', 'y', '2'>
代替"key2"_s
)
此后缀是Hana对名为“字符串文字运算符模板”的非标准C ++扩展的一种接受。它仅在GCC和Clang编译器上可用,因为默认情况下Hana对它的支持是禁用的。
此扩展名尚未达到标准(经过多次尝试),因为它以最不高效的方式(逐个字符)构造字符串类型。将其包含在标准中会鼓励其使用,并且会导致编译时间大大增加。
没有其他选择,除了boost::mpl::string
所采用的技巧外,它使用4字节unicode字符文字代替单字节字符文字,这将使编译时间减少四倍(但是仅限ASCII字符串)。