探索Boost C++元编程库：实用工具与未来扩展基础

需积分: 3 135 浏览量更新于2024-07-23 收藏 125KB PDF 举报

标题："The Boost C++ Meta-programming Library" 描述：这篇文章详细介绍了Boost C++元编程库（MPL），这是一个可扩展的编译时框架，包含算法、序列和元函数类，旨在将泛型编程和函数式编程的重要抽象融合在一起，使之成为在现实世界环境中实用的模板元编程工具。作者Aleksey Gurtovoy和David Abrahams来自Meta Communications和Boost Consulting，他们强调MPL深受C++标准库中的标准模板库（STL）的影响，STL是C++标准库的一部分。 MPL的设计理念是提供一个开放的概念和实现框架，可以作为未来领域贡献的基础。与STL相似，它帮助开发者专注于问题的解决方案，而无需陷入解决特定元编程问题的各种随意方法的海洋。即使不直接使用MPL代码，其核心概念和设计模式也能指导用户编写高效且可维护的代码。该库的主要功能包括： 1. **算法和数据结构**：MPL提供了丰富的编译时操作，如元函数（metafunctions）用于计算或转换类型，以及各种编译时构建的容器和算法，如迭代器和算法模板，但这些是在编译时而非运行时执行。 2. **元编程支持**：MPL允许程序员在编译时处理类型和表达式，从而进行诸如类型检查、类型转换、类型参数化等操作，提高了代码的灵活性和适应性。 3. **模块化和扩展性**：MPL设计为可插拔的，使得用户可以根据需求添加或修改元编程功能，同时也便于其他开发者在此基础上进行创新。 4. **易用性和一致性**：通过遵循一定的设计原则和idioms（如元对象系统和元编程模式），MPL降低了元编程的复杂性，使得实际开发变得更加直观和容易上手。 5. **与C++标准的兼容性**：尽管MPL是在C++标准之外开发的，但它受到STL的启发，并努力与标准库保持一致，以确保代码的可移植性和可维护性。 The Boost C++ Meta-programming Library是一套强大的工具集，它简化了模板元编程的过程，使得C++程序员能够在处理复杂类型和高级抽象时更加高效，同时保持代码的清晰和可读性。对于任何从事C++开发并且需要处理编译时逻辑的开发者来说，理解和掌握MPL都是提升编程能力的重要一步。

The Boost C++ Metaprogramming Library

1.3. Why metaprogramming?

It's worth asking why anyone would want to do this. After all, even a simple toy example like the factorial

metafunction is somewhat esoteric. To show how the type computation can be put to work, let's examine a simple

example. The following code produces an array containing all possible permutations of another array:

// can't return an array in C++, so we need this wrapper

template< typename T >

struct wrapper

{

T x;

};

// return an array of the N! permutations of 'in'

template< typename T >

wrapper< typename permutation_holder<T>::type >

all_permutations(T const& in)

{

wrapper<typename permutation_holder<T>::type> result;

// copy the unpermutated array to the first result element

unsigned const N = sizeof(T) / sizeof(**result.x);

std::copy(&*in, &*in + N, result.x[0]);

// enumerate the permutations

unsigned const result_size = sizeof(result.x) / sizeof(T);

for (T* dst = result.x + 1; dst != result.x + result_size; ++dst)

{

T* src = dst - 1;

std::copy(*src, *src + N, *dst);

std::next_permutation(*dst, *dst + N);

}

return result;

}

The runtime definition of factorial would be useless in all_permutations above, since in C++ the sizes

of array members must be computed at compile-time. However, there are alternative approaches; how could we

avoid metaprogramming, and what would the consequences be?

1. We could write programs to interpret the metadata directly. In our factorial example, the array size could

have been a runtime quantity; then we'd have been able to use the straightforward factorial function.

However, that would imply the use of dynamic allocation, which is often expensive.

To carry this further, YACC might be rewritten to accept a pointer-to-function returning tokens from the

stream to be parsed, and a string containing the grammar description. This approach, however, would impose

unacceptable runtime costs for most applications: either the parser would have to treat the grammar

nondeterministically, exploring the grammar for each parse, or it would have to begin by replicating at

http://www.mywikinet.com/mpl/paper/mpl_paper.html (7 of 39)28/2/2005 15:11:48

The Boost C++ Metaprogramming Library

runtime the substantial table-generation and optimization work of the existing YACC for each input

grammar.

2. We could replace the compile-time computation with our own analysis. After all, the size of arrays passed to

all_permutations are always known at compile-time, and thus can be known to its user. We could ask

the user to supply the result type explicitly:

template< typename Result, typename T >

Result all_permutations(T const& input);

The costs to this approach are obvious: we give up expressivity (by requiring the user to explicitly specify

implementation details), and correctness (by allowing the user to specify them incorrectly). Anyone who has

had to write parser tables by hand will tell you that the impracticality of this approach is the very reason of

YACC's existence.

In a language such as C++, where the metadata can be expressed in the same language as the rest of the

user's program, expressivity is further enhanced: the user can invoke metaprograms directly, without learning

a foreign syntax or interrupting the flow of her code.

So, the motivation for metaprogramming comes down to the combination of three factors: efficiency, expressivity,

and correctness. While in classical programming there is always a tension between expressivity and correctness on

one hand and efficiency on the other, in the metaprogramming world we wield new power: we can move the

computation required for expressivity from runtime to compile-time.

1.4. Why a metaprogramming library?

One might just as well ask why we need any generic library:

● Quality. Code that is appropriate for a general-purpose library is usually incidental to the purpose of its users.

To a library developer, it is the central mission. On average, the containers and algorithms provided by any

given C++ standard library implementation are more-flexible and better-implemented than the project-

specific implementations which abound, because library development was treated as an end in itself rather

than a task incidental to the development of some other application. With a centralized implementation for

any given function, optimizations and improvements are more likely to have been applied.

● Re-use. More important even than the re-use of code which all libraries provide, a well-designed generic

library establishes a framework of concepts and idioms which establishes a reusable mental model for

approaching problems. Just as the C++ Standard Template Library gave us iterator concepts and a function

object protocol, the Boost Metaprogramming Library provides type-iterators and metafunction class

protocol. A well-considered framework of idioms saves the metaprogrammer from considering irrelevant

implementation details and allows her to concentrate on the problem at hand.

● Portability. A good library can smooth over the ugly realities of platform differences. While in theory a

metaprogramming library is fully generic and shouldn't be concerned with these issues, in practice support

for templates remains inconsistent even four years after standardization. This should perhaps not be

surprising: C++ templates are the language's furthest-reaching and most complicated feature, which largely

http://www.mywikinet.com/mpl/paper/mpl_paper.html (8 of 39)28/2/2005 15:11:48

剩余38页未读，继续阅读

梦境_ling

粉丝: 7
资源: 94

探索Boost C++元编程库：实用工具与未来扩展基础

THE BOOST C++ METAPROGRAMMING LIBRARY

Boost C++ 库文档合集

graph-tool-2.27.tar.bz2

python的自引用

std::void_t

c++11 auto

C➕➕ python爱心代码高级

C++中如何实现对多种不同类型的条件是否满足的判断，尽量减少使用if else且不适用linq

Constant expression required

python高级技巧

最新资源