考虑函数模板的以下两个重载foo:
template <typename T>
void foo(T) requires std::integral<T> {
std::cout << "foo requires integral\n";
}
template <typename T>
int foo(T) requires std::integral<T> && true {
std::cout << "foo requires integral and true\n";
return 0;
}
Run Code Online (Sandbox Code Playgroud)
请注意两个约束之间的区别:第二个约束有一个额外的&& true.
直观地说,true在连词中是多余的(因为X && trueis just X)。然而,它看起来像这使得语义差别,如foo(42)将调用第二个过载。
为什么会这样?具体来说,为什么第二个函数模板是更好的重载?
我的问题与此类似,但略有不同。
假设我有两个翻译单元,exec.cpp和lib.cpp,如下:
// exec.cpp
int foo();
int main() {
return foo();
}
Run Code Online (Sandbox Code Playgroud)
和
// lib.cpp
auto foo() {
return 42;
}
Run Code Online (Sandbox Code Playgroud)
将它们编译和链接在一起是否合法?还是格式错误的 NDR?
注意:g++ 和 clang 都使用命令生成预期的可执行文件(即返回 42) <compiler> exec.cpp lib.cpp -o program
注意:可以说这是一个不好的做法(因为如果实现发生变化,返回类型可能会改变,并破坏代码)。但我还是想知道答案。
我最近正在学习 Vulkan API,但无法理解VK_SUBPASS_EXTERNAL(分配给VkSubpassDependency::srcSubpass或VkSubpassDependency::dstSubpass)的含义。的官方文件的状态:“如果srcSubpass等于VK_SUBPASS_EXTERNAL,第一同步范围包括比所述vkCmdBeginRenderPass用于开始渲染过程实例,在提交顺序更早发生的命令”。
这是否意味着一个子通道可以依赖于其他渲染通道中的另一个子通道?或者别的什么?
所以最近我一直在使用Vulkan-Hpp(Vulkan Api的官方c ++绑定,Github Link)。
查看源代码,我发现它们围绕本机Vulkan结构(例如vk::InstanceCreateInfo环绕VkInstanceCreateInfo)创建包装器类。(注意:环绕而不是源自)
调用本地Vulkan API时,将指向包装类的指针reinterpret_cast编入本地Vulkan结构中。使用示例vk::InstanceCreateInfo:
//definition of vk::InstanceCreateInfo
struct InstanceCreateInfo
{
/* member function omitted */
private:
StructureType sType = StructureType::eInstanceCreateInfo;
public:
const void* pNext = nullptr;
InstanceCreateFlags flags;
const ApplicationInfo* pApplicationInfo;
uint32_t enabledLayerCount;
const char* const* ppEnabledLayerNames;
uint32_t enabledExtensionCount;
const char* const* ppEnabledExtensionNames;
};
//definition of VkInstanceCreateInfo
typedef struct VkInstanceCreateInfo {
VkStructureType sType;
const void* pNext;
VkInstanceCreateFlags flags;
const VkApplicationInfo* pApplicationInfo;
uint32_t enabledLayerCount; …Run Code Online (Sandbox Code Playgroud) 我们知道该概念std::same_as与顺序无关(换句话说,对称):std::same_as<T, U>等同于std::same_as<U, T>(相关问题)。在这个问题中,我想实现一些更通用的方法:template <typename ... Types> concept same_are = ...检查包Types中的类型是否彼此相等。
#include <type_traits>
#include <iostream>
#include <concepts>
template <typename T, typename... Others>
concept same_with_others = (... && std::same_as<T, Others>);
template <typename... Types>
concept are_same = (... && same_with_others<Types, Types...>);
template< class T, class U> requires are_same<T, U>
void foo(T a, U b) {
std::cout << "Not integral" << std::endl;
}
// Note the order <U, T> is …Run Code Online (Sandbox Code Playgroud) template <typename T>
inline constexpr int a = 1;
static_assert(&a<void>, "");
Run Code Online (Sandbox Code Playgroud)
这不会在gcc 9.2上进行编译,但是会在clang和msvc上进行编译。
Gcc抱怨用于的表达式static_assert不是常量表达式。
The code compiles after removing template, removing inline, or removing address-of operator.
Is this a gcc bug?
我正在编写一个 linux 命令行程序,它将返回目录的大小。该程序按预期工作,除非专门处理根目录。我知道根目录中的许多文件没有大小,因为它们是用于表示系统信息(如 /proc/)或 /dev/null/ 之类的特殊文件,所以我std::filesystem::directory_options::skip_permission_denied在 for 循环中使用以跳过权限问题,我使用多个 try/catch 块来捕获异常。
但是,即使这样,仍然会抛出权限被拒绝的异常。请参阅以下代码:
byte_size_and_num_files find_recursive(const std::filesystem::path& path)
{
byte_size_and_num_files bsnf;
std::filesystem::path pa;
try
{
for(const auto& p: std::filesystem::recursive_directory_iterator(path, std::filesystem::directory_options::skip_permission_denied))
{
pa = p.path();
if (std::filesystem::exists(p) && !std::filesystem::is_directory(p))
{
try
{
if(std::filesystem::is_regular_file(pa))
{
bsnf.size += std::filesystem::file_size(p);
bsnf.files++;
}
else
std::cout << "SKIPPED: size is not determinable: " << pa << "\n";
}
catch(std::filesystem::filesystem_error& e)
{
std::cout << "SKIPPED: size is not determinable: " << pa << "\n";
}
catch(std::bad_alloc)
{
std::cout …Run Code Online (Sandbox Code Playgroud) 以下是引用自[bit.cast]下的标准(草案n4861)(强调的是我的)
返回:类型的对象
To。隐式创建嵌套在结果中的对象 (6.7.2)。结果的值表示的每一位都等于 的对象表示中的相应位from。结果的填充位未指定。对于结果和其中创建的每个对象,如果没有与所产生的值表示对应的对象类型的值,则行为是未定义的。如果有多个这样的值,生成哪个值是未指定的。
所以我的问题是,std::bit_cast生成对应于多个不同值的值表示的场景的示例是什么?
c++ ×7
c++20 ×3
c++-concepts ×2
c++17 ×2
vulkan ×2
auto ×1
c++14 ×1
compiler-bug ×1
constexpr ×1
gcc ×1