问题标签 [c++14]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - 如何在 c++1y 的返回类型推导中保留 cv 限定符或引用?
首先,我构造了四个结构,每个结构都返回值、左值引用、常量左值引用、右值引用。我在包装器(B
或C
)中使用它们,在func()
这些包装器的方法中,我想保留 of 的引用和 cvfunc()
限定符 A
。
在 c++11 中,我使用了尾随返回类型。但是随着 c++14 中正常返回类型推导的到来,我猜我可以跳过尾随部分,但只有使用auto
,返回类型会像普通一样忽略限定符和引用auto
。
然后,我的问题是在 c++14 中实现它的最佳方法是什么,它的行为就像B
下面的类?有时写尾随部分(通常是 decltype(return expression))是微不足道的。
请注意,此程序在带有 -std=c++1y 选项的 gcc 4.8 中编译没有问题。
c++ - 在 C++14 中,可恢复函数将在什么情况下执行?
C++14 的提议之一是Resumable Functions,它为 C++ 提供了当今 C# 中可用的异步/等待机制。基本思想是可以在等待异步操作完成时暂停函数。当异步操作完成时,函数可以在暂停的地方恢复。这是以非阻塞方式完成的,因此调用可恢复函数的线程不会被阻塞。
对我来说,函数将在哪个上下文(线程)中恢复并不明显。它会由暂停函数的线程恢复(据我了解,这是在 C# 中完成的)还是使用另一个线程?
如果它被暂停的线程恢复,线程是否必须处于某种特殊状态,或者调度程序会处理这个?
c++ - SFINAE:static_assert 与 std::enable_if
以下(建议!)语法有什么缺点吗?
而不是 SFINAE(看起来像拐杖):
甚至更糟:
禁止使用auto
结果类型的推导。
c++ - g++/libstdc++中std::optional的实现状态?
由于我正在开发一个将于 2014 年左右公开发布的 C++ 库,因此我目前需要做出设计选择。将与 C++14 一起发布的非常有用的工具之一是std::optional
. 我想知道g++/libstdc++
我可以使用哪个版本的-std=c++1y
.
c++ - 自动返回类型扣除是否适用于 main?
我能否对 C++1y (C++14) 中的主要功能执行以下操作:
那么int
即使我们不需要使用显式,返回类型是否会自动出现return 0;
?
c++ - 模板函数与具有自动参数的命名 lambda
之间有什么区别
以及使用带有自动参数的 lambda 的 C++14 替代方案?
应该首选哪一个?
c++ - 为什么 auto 不能用于重载函数?
我知道 usingtemplates
是一种受欢迎的重载方式,但我想知道为什么auto
不能用于函数参数类型推导从而帮助函数重载?
N3690
在 7.6.1.4/3 中说 lambda 表达式可以使用 auto 进行泛型,提供这个例子
(注意:N3485中没有提到这个)
1).为什么我不能为正常功能做类似的事情,例如
这给出了错误error : parameters declared auto
。
从 N3690 7.1.6.4/4
使用 auto 或 decltype(auto) 声明的变量的类型是从其初始化程序推导出来的。在块 (6.3)、命名空间范围 (3.3.6) 和 for-init-statement (6.5.3) 中声明变量时,允许使用此用法。[...]
我是否错误地假设param1
andparam2
属于块范围并因此有资格自动扣除?
2)。如果允许这样的功能,会有什么陷阱?
我正在使用 gcc 4.8.1。
谢谢
c++ - 通用 lambda 在 C++14 中如何工作?
通用 lambda 在 C++14 标准中如何工作(auto
关键字作为参数类型)?
它是基于 C++ 模板,其中为每个不同的参数类型编译器生成一个具有相同主体但替换类型的新函数(编译时多态性)还是更类似于 Java 的泛型(类型擦除)?
代码示例:
c++ - clang 3.3 和 GCC 4.7 const v 的 constexpr
我刚刚尝试在 Ubuntu 13.04 上使用 clang 3.3 和 GCC 4.7.3 标准库头文件编译相当大的代码体。这一切都很顺利,除了一个问题。这段代码已经在这台机器上用标准的 Ubuntu clang 3.2 包编译,所以我假设这是 clang 3.3 编译器的一些变化。与使用复杂标头的 const 和 constexpr 有关的问题。特别是复杂类型具有以下代码块
在我的编译中,我输入了第一个代码块,因此编译器看到
这会导致 clang 产生一个错误,即真正的成员函数不是 const 并具有以下内容
我已经阅读了以下文章`constexpr` 和 `const` 之间的区别以及其他一些类似文档,但我仍然不清楚这是 GCC 头问题还是 clang 编译器问题。我的感觉是标记为 constexpr 的成员函数应该被编译器视为 const 在这种情况下clang是错误的。