简体   繁体   English

没有使用CPPUnit的模板专业化

[英]template specialization for CPPUnit isn't being used

If you've used CPPUnit before, you are probably aware of its assertion_traits class that is templatized to handle arbitrary types. 如果以前使用过CPPUnit,则可能知道它的assertion_traits类已被模板化以处理任意类型。 This is what allows it to print the "actual" and "expected" values for non-string types when test cases fail. 这就是在测试用例失败时可以打印非字符串类型的“实际”和“预期”值的原因。 I have used this with success several times, but for one specific type it isn't working for me. 我已经成功使用了几次,但是对于一种特定的类型,它对我不起作用。 Here is a partial declaration for my class, its parent's class, and some non-member operators (the whole thing is huge, plus my company won't let me post it): 这是我的班级,其父班级和一些非成员运算符的部分声明(整个事情非常大,加上我的公司不允许我发布它):

class _declspec(dllexport) HWDBDateTime
{
public:
    HWDBDateTime();
    HWDBDateTime(const HWDBDateTime& other);

    HWDBDateTime& operator=(const HWDBDateTime& other);

    RWCString asString() const;
    RWCString asString(const char *format, const boost::local_time::time_zone_ptr pZone = STimeZone::GetServerTimeZone()) const;
};

bool _declspec(dllexport) operator==(const HWDBDateTime& dt1, const HWDBDateTime& dt2);
bool _declspec(dllexport) operator!=(const HWDBDateTime& dt1, const HWDBDateTime& dt2);
bool _declspec(dllexport) operator< (const HWDBDateTime& dt1, const HWDBDateTime& dt2);
bool _declspec(dllexport) operator<=(const HWDBDateTime& dt1, const HWDBDateTime& dt2);
bool _declspec(dllexport) operator> (const HWDBDateTime& dt1, const HWDBDateTime& dt2);
bool _declspec(dllexport) operator>=(const HWDBDateTime& dt1, const HWDBDateTime& dt2);

class _declspec(dllexport) STimeStamp : public HWDBDateTime
{
public:

    STimeStamp();

    STimeStamp(const STimeStamp& other);

    STimeStamp(const HWDBDateTime& other);

    explicit STimeStamp(double d);

    STimeStamp& operator=(double d);

    operator double() const;
};

And here is my attempt at specializing the CPPUnit assertions class: 这是我尝试专门化CPPUnit断言类的尝试:

template <>
struct CppUnit::assertion_traits<STimeStamp>
{  
    static bool equal( STimeStamp x, STimeStamp y )
    {
        return x == y;
    }

    static std::string toString( STimeStamp x )
    {
        return (const char *)x.asString();
    }
};

I've tried it passing by value, as seen above, also passing const references, I've tried casting the values inside the functions to HWDBDateTime (since that's where the operators and asString() methods are defined), nothing seems to help. 我已经尝试过按值传递值,如上所示,也传递了const引用,我尝试将函数内部的值强制转换为HWDBDateTime (因为已定义了operator和asString()方法的位置),似乎没有任何帮助。 I've put it at the top of my test suite's CPP file, and I've put it into a master header file that contains project-wide assertion_traits specializations, such as one for RWCString that works flawlessly. 我将其放在测试套件的CPP文件的顶部,并将其放入一个主标头文件,该标头文件包含项目范围内的assertion_traits专长,例如RWCString可以完美运行。 Somehow, whenever a test case fails, it insists on printing out my time as a floating-point value (presumably a double; a specialization for double is built in to CPPUnit) -- this is why I made sure to include my to/from double conversion operators in the minimized code above. 不知何故,每当一个测试用例失败时,它都会坚持将我的时间打印为浮点值(大概是double值; CPPUnit内置了double的特殊化)-这就是为什么我确保将to / from包括在内以上最小化代码中的double转换运算符。

Is there something inherently wrong with what I'm doing? 我在做什么,天生就有问题吗? Does the specialization need to be present at a certain point in the compilation process, and maybe I just haven't found that point? 专业化是否需要在编译过程中的某个时刻出现,也许我还没有找到? Would this mythical point be per-translation-unit or per-project? 这个神话要点是每个翻译单位还是每个项目? I'm using VS2008. 我正在使用VS2008。

C++ type matching is the issue here. C ++类型匹配是这里的问题。

The original type is probably const STimeStamp& . 原始类型可能是const STimeStamp& When coming from const T& most compilers prefers the implicit cast operators (in your case double ) over creating a copy T . 当来自const T&大多数编译器都倾向于使用隐式强制转换运算符(在您的情况下为double )而不是创建副本T

This may be compiler specific... 这可能是特定于编译器的...

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM