woaidongmao

文章均收录自他人博客,但不喜标题前加-[转贴],因其丑陋,见谅!~
随笔 - 1469, 文章 - 0, 评论 - 661, 引用 - 0
数据加载中……

浅析C++ Compile-time Assertion技术

你可能经常需要利用运行时断言技术,它可以方便地测试前提条件。但是,随着Metaprogramming概念的出现,编译时断言技术也已经和runtime assertion一样的普遍了。如何在编译时进行断言呢?其实,方法只有一个,就是让编译器生成一条错误信息,但是编译器生成的错误信息信息性往往有又理想。并且,即使你在一种编译上设计了一种方案,你也很难把它移植到其他的编译器上。我们通过其实现方法的改进和一个Boost中的例子,来看看如何更好的实现这种技术。

例如,你需要一个安全的类型转换机制,它只允许你把个头小的类型转换为个头大的类型。此时,就可以利用Compile-time Assertion解决这个问题。

template <typename To, typename From>

To safe_reinterpret_cast(From from) {

    assert(sizeof(To) >= sizeof(From));

    return reinterrupt_cast (from);

};

而后,就像你使用同样的 C++ 类型转换一样来使用这个 safe_reinterpret_cast

long l = 255;

short s = safe_reinterpret_cast<short>(l);

这样一来,你就可以确保只有在小 à 大的转换才是正确的,如果进行非法的转换,就会在运行时发生断言。

显然,如果能够在编译时给用户指出代码中的问题更为合适一些。如果这个转换只在程序很少被执行到的一个分支上被执行,那么当你把它移植到一个新的编译器上或平台上的时候,你就有可能忘记程序中所有不可移植的部分,例如上面提到的 reinterrupt_cast ,从而给你的程序带来不必要的 bug

其实,上面我们被评估的表达式是一个编译器常量,也就是说你完全有可以让编译器取代运行时代码来进行检查。解决的思路是在表达式为 true 的时候给编译器传递正确的代码,而在表达式为 false 的时候给编译器提供一个语法错误的代码,这样,当被评估的表达式为 0 的时候,编译器就会发出一个错误信号。

最简单的 compile-time assertion 解决方案是 Van Horn 1997 年提出的,它可以在 C C++ 的代码中工作,依赖的条件很简单,数组的长度不能为 0

#define STATIC_CHECK(expr) { char unnamed[(expr ? 1 : 0)]; }

现在,如果你写下下面的代码:

template <typename To, typename From>

To safe_reinterpret_cast(From from) {

    STATIC_CHECK(sizeof(To) >= sizeof(From));

    return reinterpret_cast (from);

};

… …

void * somePointer = 0;

char c = safe_reinterpret_cast<char>(somePointer);

如果 void* 的长度小于 char( 这个并没有在目前的 C++ 标准的规定 ) ,编译器就会告诉你创建了一个长度为 0 的数组。

问题是这个方法提供的错误信息并不是很说明问题。“不能创建长度为0的数组”并不能表示“char类型放不下一个指针”。这种方法很难想用户提供customized message。错误信息的来源并不是因为代码违法了程序设计的意图,而是因为破坏了某些语法规则。

更好的解决方案是依赖一个模板提供一个具有说明性的名字,这样,编译器就会在错误信息中包含这个名字了。

template <bool> struct CompileTimeError;

template <> struct CompileTimeError<true> {};

#define STATIC_CHECK1(expr1) { (CompileTimeError<(expr1) != 0>()); }

CompileTimeError 带有一个非类型参数,并且只有 true 的特化版本,这样,当被评估的表达式不满足条件时,编译器就会抱怨没有 CompileTimeError 的特化版本,这个比刚才的错误多多少少要好一些。

当然,这个设计仍然有很大的扩展空间。因为我们还是没有办法来订制错误消息。一个简单的办法就是在 STATIC_CHECK 中加入一个消息参数,然后让这个消息参数在错误信息中显示。这个方法也有自己的缺点,就是你必须要保证传递给 C++ 的这个错误消息参数一定是合法的。于是我们可以对于上面的 CompileTimeError 做以下的改进:

template <bool> struct CompileTimeChecker {

    CompileTimeChecker(...) {};

};

template <> struct CompileTimeChecker<false> { };

 

#define STATIC_CHECK2(expr2, msg) {\

    class ERROR_##msg {}; \

    sizeof((CompileTimeChecker<(expr2!=0)>((ERROR_##msg()))));\

}

template <typename To, typename From>

To safe_reinterpret_cast(From from) {

    STATIC_CHECK2((sizeof(To) >= sizeof(From)),

Destination_Type_To_Narrow);

    return reinterpret_cast (from);

};

这样,当你仍旧使用刚才的代码时:

void * somePointer = 0;

char c = safe_reinterpret_cast<char>(somePointer);

由于 CompileTimeChecker 可以接受任意参数,而特化的 CompileTimeChecker 并没有这样的构造函数,这样,当被评估的表达式为 0 的时候,就会出现编译时错误

cannot convert

from

'safe_reinterpret_cast::ERROR_Destination_Type_To_Narrow'

to

'CompileTimeChecker'

这次的错误信息变的比较有提示性了。

现实中的应用——BOOST_STATIC_ASSERT & boost::checked_delete

BOOST_STATIC_ASSERT

boost/static_assert.hpp中定义了一个宏BOOST_STATIC_ASSERT,用于完成编译时静态检查。其实现方式了我们的第2种方式很类似,利用了模板的特化技术

#define BOOST_STATIC_ASSERT( B ) \

   typedef ::boost::static_assert_test<\

      sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >)>\

         BOOST_JOIN(boost_static_assert_typedef_, __COUNTER__)

其中:

template <int x> struct static_assert_test{};

#define BOOST_JOIN( X, Y ) X##Y

template <bool x> struct STATIC_ASSERTION_FAILURE;

template <> struct STATIC_ASSERTION_FAILURE<true> { enum { value = 1 }; };

这里,只为 true 类型进行了特化,这样,当我们尝试声明一个 STATIC_ASSERTION_FAILURE<false> 的时候就会引发编译时错误。

这样,整个宏的含义就是做了一个 typedef:

typedef ::boost::static_assert_test<evaluate condition> boost_static_assert_typedef___COUNTER__

而只有当evaluate conditiontrue的时候,这样的typedef才是正确的,从而实现了编译时断言(上面的代码只是msvc的实现,对不同的编译器实现略有不同,但是思想是类似的)。

例子:确保一个模板参数的类型只能是整数

template <typename T> class only_compatible_with_integral_types {

    BOOST_STATIC_ASSERT(boost::is_integral::value);

};

之后,如果你使用下面的定义:

only_compatible_with_integral_types<double> test2;

就会引发编译错误:

use of undefined type 'boost::STATIC_ASSERTION_FAILURE

boost::checked_delete

当我们利用指针删除一个对象的时候,对象类型是否完整决定了对象是否能够被正确删除。但是,如果你用 delete 去删除一个类型并不完整的对象的指针,编译器并不会给你提供任何错误信息,但是这样做的结果却是对象的析构函数根本就没有被调用。

checked-delete 定义在 boost/checkd_delete.hpp 中,它可以保证在你摧毁一个对象的时候,必须对该对象的类型有完全的了解。先来看个例子:

#include

class some_class;

some_class* create() {

  return (some_class*)0;

}

int main() {

  some_class* p=create();

  boost::checked_delete(p2);

}

编译器就会抱怨 some_calss 是一个不完整的类型。在我们进一步去了解解决方案之前,我们先来看一个由于不完整类型带来的 memory leak 的例子:

// in deleter.h

class to_be_deleted;

class deleter {

public :

    void delete_it(to_be_deleted* p);

};

// in deleter.cpp

#include "deleter.h"

 

void deleter::delete_it(to_be_deleted* p) {

    delete p; // !!!memory leak here

}

// in to_be_deleted.h

#include

 

class to_be_deleted {

    class test {

    public:

       test() {};

       ~test() { std::cout<<"I'm destructed correctly!"<

    };

    test* p;

public :

    to_be_deleted() { p = new test(); };

    ~to_be_deleted() {

       delete p;

       std::cout<<"I've important things to say!"<

    }

};

之后用下面的测试代码:

#include "deleter.h"

#include "to_be_deleted.h"

int main() {

    to_be_deleted* p = new to_be_deleted();

    deleter d;

    d.delete_it(p);

    return 0;

}

你会发现, to_be_deleted 的析构函数并没有被调用,原因在于 deleter.cpp 中,并没有包含 to_be_deleted.h ,这样, delete 对于齐要删除的指针一无所知,导致了析构函数并没有真正被调用。

解决的方法也很简单,利用 boost::checked_delete 进行删除。

#include

#include "deleter.h"

void deleter::delete_it(to_be_deleted* p) {

    //delete p; // memory leak here

    boost::checked_delete(p);

}

这时,编译器便会抱怨说 to_be_deleted 是未知的类型。其实 ,checked_delete 的实现原理是非常简单的,只是说对于未知类型,使用 sizeof 运算符会返回 0 ,而 C++ 并不允许创建长度为 0 的数组。如下所示:

template <class T> inlinevoid checked_delete(T * x)

{

    // intentionally complex - simplification causes regressions

    typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];

    (void) sizeof(type_must_be_complete);

    delete x;

}

posted on 2008-09-15 13:39 肥仔 阅读(607) 评论(0)  编辑 收藏 引用 所属分类: C++ 模板


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理