steady_clock::now() return gcc 类型无效
steady_clock::now() return type invalid with gcc
我有以下代码:
#include <chrono>
struct SteadyTime : std::chrono::steady_clock::time_point {
using time_point::time_point;
static SteadyTime now() {
return clock::now();
}
};
这适用于 Visual Studio 2019,但对于 gcc 8.3 我收到以下错误:
<source>: In static member function 'static SteadyTime SteadyTime::now()':
<source>:7:24: error: could not convert 'std::chrono::_V2::steady_clock::now()' from 'std::chrono::_V2::steady_clock::time_point' {aka 'std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >'} to 'SteadyTime'
return clock::now();
~~~~~~~~~~^~
Compiler returned: 1
这段代码似乎是标准的,所以有什么问题吗?
您要做的基本上是这样的:
struct Base
{};
Base getBase();
struct Derived : Base
{
static Derived get() { return getBase(); }
};
这行不通,因为编译器不知道如何将 Base
转换为 Derived
。您可以从 Base
添加 Derived
的构造函数来解决此问题。
虽然我会质疑总体设计。继承自 std
设施通常是一种设计 flaw/weakness。更喜欢组合而不是继承(尤其是 如果你打算派生的东西不是多态的)。如果需要,让 SteadyTime
公开一个 time_point
成员,或者手动包装它的接口。在同一个继承层次结构中拥有和使用多个具体(即非抽象)类 很快会导致对象切片和其他 UB 等混乱,以及用户的普遍困惑。
我有以下代码:
#include <chrono>
struct SteadyTime : std::chrono::steady_clock::time_point {
using time_point::time_point;
static SteadyTime now() {
return clock::now();
}
};
这适用于 Visual Studio 2019,但对于 gcc 8.3 我收到以下错误:
<source>: In static member function 'static SteadyTime SteadyTime::now()':
<source>:7:24: error: could not convert 'std::chrono::_V2::steady_clock::now()' from 'std::chrono::_V2::steady_clock::time_point' {aka 'std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >'} to 'SteadyTime'
return clock::now();
~~~~~~~~~~^~
Compiler returned: 1
这段代码似乎是标准的,所以有什么问题吗?
您要做的基本上是这样的:
struct Base
{};
Base getBase();
struct Derived : Base
{
static Derived get() { return getBase(); }
};
这行不通,因为编译器不知道如何将 Base
转换为 Derived
。您可以从 Base
添加 Derived
的构造函数来解决此问题。
虽然我会质疑总体设计。继承自 std
设施通常是一种设计 flaw/weakness。更喜欢组合而不是继承(尤其是 如果你打算派生的东西不是多态的)。如果需要,让 SteadyTime
公开一个 time_point
成员,或者手动包装它的接口。在同一个继承层次结构中拥有和使用多个具体(即非抽象)类 很快会导致对象切片和其他 UB 等混乱,以及用户的普遍困惑。