Questions tagged «c++17»

C ++ 17是2017年批准的C ++标准的名称。它以以前的C ++ 14标准为基础,改进了核心语言和标准库,并添加了一些新的语言功能。

2
如何使用C ++ 17获得以字节为单位的文件大小
我应该知道,特定操作系统是否存在陷阱? 有很多重复(1,2,3,4,5这个问题),但他们在几十年前进行了解答。在许多这些问题中,投票率很高的答案今天是错误的。 .sx上其他(旧质量检查)的方法 stat.h(wrapper sprintstatf),使用syscall tellg(),根据定义返回一个位置,但不一定返回bytes。返回类型不是int。

6
为什么在C ++ 17中使用std :: make_unique?
据我了解,C ++ 14的引入std::make_unique是因为,由于未指定参数求值顺序,因此这是不安全的: f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A (说明:如果评估首先为原始指针分配内存,然后进行调用,g()并且在std::unique_ptr构造之前引发异常,则内存将泄漏。) 呼叫std::make_unique是一种限制呼叫顺序的方法,从而使事情变得安全: f(std::make_unique<MyClass>(param), g()); // Syntax B 从那时起,C ++ 17阐明了评估顺序,也使语法A变得安全,所以这是我的问题:在C ++ 17中仍然有理由使用std::make_uniqueover std::unique_ptr的构造函数吗?你能举一些例子吗? 到目前为止,我能想象的唯一原因是它只允许键入MyClass一次(假设您不需要依赖于的多态性std::unique_ptr<Base>(new Derived(param)))。但是,这似乎是一个很弱的原因,尤其是当的构造函数std::make_unique不允许指定删除器时std::unique_ptr。 只是要清楚一点,我不主张std::make_unique从标准库中删除(至少保持向后兼容才有意义),而是想知道是否仍然存在强烈推荐使用标准库的情况。std::unique_ptr
96 c++  c++17  unique-ptr 


4
实验性::文件系统链接器错误
我尝试在gcc 6.0的开发中实际使用新的c ++ 1z功能。 如果我尝试这个小例子: #include <iostream> #include <experimental/filesystem> namespace fs = std::experimental::filesystem; int main() { fs::path p1 = "/home/pete/checkit"; std::cout << "p1 = " << p1 << std::endl; } 我有: / opt / linux-gnu_6-20151011 / bin / g ++ --std = c ++ 1z main.cpp -O2 -g -o go …
94 c++  gcc  c++17 

3
什么时候类型信息在C ++中向后流动?
我刚刚看了斯蒂芬·拉瓦维(Stephan T. Lavavej)在CppCon 2018“类模板参数推论”上的讲话,在某个时候他偶然说: 在C ++类型的信息中,信息几乎永远不会倒退…… 我不得不说“几乎”,因为只有一两种情况,可能更多但很少。 尽管试图弄清楚他可能指的是哪种情况,但我什么也没想出来。因此,问题是: 在哪种情况下,C ++ 17标准要求类型信息向后传播?

1
保证复制清除如何工作?
在2016年Oulu ISO C ++标准会议上,标准委员会将名为“通过简化的值类别进行保证的复制省略”的提案投票选为C ++ 17。 保证的复制清除功能如何工作?它是否涵盖了某些已经允许使用复制消除的情况,还是需要更改代码以保证复制消除?

4
现代C ++的实验功能对长期项目是否可靠?
我有一个当前使用C ++ 11/14的项目,但是它需要类似的东西std::filesystem,它仅在C ++ 17中可用,因此我目前没有机会使用它。但是,我看到它在我当前的编译器中可用std::experimental::filesystem。使用实验性功能是否是一个好主意,假设我将来可以添加以下内容: #ifdef CXX17 //if this is C++17 std::filesystem::something ...; #else std::experimental::filesystem::something ...; #endif 我担心的是: 1.是否保证所有兼容的编译器都具有相同的实验功能? 2.实验功能是否容易发生重大变化而使其不可靠? 也许还有更多事情想知道。为什么我应该或不应该使用它们?我为一个新项目感到困惑,不知道该怎么决定。


1
为什么即使我使用[[fallthrough]],GCC也会警告我有关失败的消息?
在下面的代码中,我使用[[fallthrough]]C ++ 1z的standard属性来说明需要进行彻底检查: #include <iostream> int main() { switch (0) { case 0: std::cout << "a\n"; [[fallthrough]] case 1: std::cout << "b\n"; break; } } 使用GCC 7.1,代码可以正确编译。但是,编译器仍然警告我一个失败之处: warning: this statement may fall through [-Wimplicit-fallthrough=] std::cout << "a\n"; ~~~~~~~~~~^~~~~~~~ 为什么?

3
自C ++ 17起,具有正确地址和类型的指针仍然始终是有效的指针吗?
(参考此问答)。 在C ++ 17标准之前,[basic.compound] / 3中包含以下句子: 如果类型T的对象位于地址A,则将其值为地址A的cv T *类型的指针指向该对象,而不管如何获取该值。 但是从C ++ 17开始,此句子已删除。 例如,我相信这句话使此示例代码已定义,并且由于C ++ 17,这是未定义的行为: alignas(int) unsigned char buffer[2*sizeof(int)]; auto p1=new(buffer) int{}; auto p2=new(p1+1) int{}; *(p1+1)=10; 在C ++ 17之前,p1+1持有的地址*p2并具有正确的类型,因此*(p1+1)是的指针*p2。在C ++ 17p1+1中,指针是一个end-the-end,因此它不是指向对象的指针,并且我相信它是不可引用的。 是对标准权利的这种修改的解释,还是有其他规则可以补偿所引用句子的删除?

2
std :: ignore与结构化绑定?
序幕: std::tuple<int, int, int> f(); std::tuple<int, int, float, int> g(); C ++ 1z将引入结构化绑定的语法,这将使编写代替 int a, b, c; std::tie(a, b, c) = f(); 就像是 auto [a, b, c] = f(); 但是,std::tie还允许指定std::ignore忽略某些组件,例如: std::tie(a, b, std::ignore, c) = g(); 使用新的结构化绑定语法是否可以做类似的事情?如何运作?

6
在“ if”语句中初始化变量
我读到在C ++ 17中我们可以在这样的if语句中初始化变量 if (int length = 2; length == 2) //execute something 代替 int length = 2; if (length == 2) //do something 即使它更短,它也会影响代码的可读性(特别是对于不了解此新功能的人而言),我认为这对于大型软件开发而言是一种不良的编码实践。 除了使代码更短之外,使用此功能还有什么好处?
80 c++  c++17 

3
了解std :: hardware_destructive_interference_size和std :: hardware_constructive_interference_size
添加了C ++ 17std::hardware_destructive_interference_size和std::hardware_constructive_interference_size。首先,我认为这只是获得L1缓存行大小的一种可移植的方法,但这过于简单了。 问题: 这些常量与L1缓存行大小有何关系? 有没有一个很好的例子来说明他们的用例? 两者都被定义static constexpr。如果生成二进制文件并在具有不同缓存行大小的其他计算机上执行二进制文件,这不是问题吗?当您不确定代码将在哪台计算机上运行时,如何在这种情况下防止错误共享?

6
允许编译器优化掉局部volatile变量吗?
是否允许编译器对此进行优化(根据C ++ 17标准): int fn() { volatile int x = 0; return x; } 对此吗? int fn() { return 0; } 如果是,为什么?如果没有,为什么不呢? 关于此主题的一些思考:当前的编译器将其编译fn()为放置在堆栈中的局部变量,然后将其返回。例如,在x86-64上,gcc创建以下代码: mov DWORD PTR [rsp-0x4],0x0 // this is x mov eax,DWORD PTR [rsp-0x4] // eax is the return register ret 现在,据我所知,标准并没有说应该将局部volatile变量放入堆栈中。因此,此版本同样不错: mov edx,0x0 // this is x mov …

3
如何有效地为std :: string的子字符串获取`string_view`
使用http://en.cppreference.com/w/cpp/string/basic_string_view作为参考,我认为没有办法更优雅地做到这一点: std::string s = "hello world!"; std::string_view v = s; v = v.substr(6, 5); // "world" 更糟糕的是,幼稚的方法是一个陷阱,并留下v了对临时对象的悬挂: std::string s = "hello world!"; std::string_view v(s.substr(6, 5)); // OOPS! 我似乎记得类似的东西,可能在标准库中添加了一个将子字符串作为视图返回的内容: auto v(s.substr_view(6, 5)); 我可以想到以下解决方法: std::string_view(s).substr(6, 5); std::string_view(s.data()+6, 5); // or even "worse": std::string_view(s).remove_prefix(6).remove_suffix(1); 坦白说,我认为这些都不是很好。现在,我能想到的最好的事情就是使用别名来使事情变得不再那么冗长。 using sv = std::string_view; sv(s).substr(6, 5);
76 c++  view  c++17  stdstring 

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.