模板元程序(六)



2.2 元函数

如果到此为止,你已经注意到 traits 模板与普通函数的相似性那就太好了。traits 模板参数与内嵌类型所扮演的角色是运行时函数的参数与返回值。第一章中的二进制模板因此就如函数一样。 如果 iterator_traits 所进行的“类型计算”尽管我们也理解其过于简单而无法与函数相提并论。但在后面的部分,我保证会很快变得越来越有趣。

traits 模板吃进去的是类型参数,而返回的也是类型参数,这种特性向我们揭示了两个普通函数所没有的特性:
一是特化。我们可以非入侵式地改变 traits 模板针对特定“值”(类型)所返回的结果。这就是通过添加一个特化来达到的。我们甚至通过偏特化可以改变其针对整个值范围(如,所有的指针)的计算结果。如果你将特化能运用到普通函数中,那将非常奇特。想像一下,如果能够针对 std::abs 这个函数写一个重载版本只接收奇数!

多个返回值。当普通函数将其参数只对应到一个值,traits 常常会有多于一个的结果。例如, std::iterator_traits 包含了五个内嵌类型:value_type, reference, pointer, difference_type, and iterator_category,甚至很少能发现 traits 模板包含内嵌常数或者静态成员。std::char_traits 可能是标准库中唯一一个这样的组件了。


但是,类模板与函数也有相当多的相似之处,因此我们可以从推理之外得到一些严肃的结论。为了抓住“做为函数的类型模板”的中心思想,我们使用“元函数”这个术语。元函数是 MPL 的主要抽象,使其形式化是 MPL 功能的关键。我们将在第三章中深入讨论元函数,但是我们先讨论一下元函数与经典 traits 之间的重要差别。


traits 模板在标准库中所有都遵循“多返回值”这样的模型。我们将这样的 traits 模板称为 “blob”,因为它就是将许多互相关联很少而分散的与元函数相关的元素通通揉合在一起。我们将尽量避免这样的手法,因为这会带来一个主要的问题。


首先,会有一个性能问题:把我们第一次使用 iterator_traits 的 ::value_type 的时候,模板就需要被实例化。这就意味着编译器需要很多事情要做,但是对我们重要的事情是在编译器需要在这些地方确定模板体内每个依赖于模板参数声明的含意。在 iterator_traits 这个例子里,也就是不仅要计算 value_type,也要计算其他四个相关联的类型,就算我们不需要使用他们。这些多余的计算随着程序的增长也会增加,使得编译时间拉长。还记得我们说过类型计算更有趣不?“更有趣”也就意味着你的编译器需要做更多的工作,这样你也就不得不用手指敲打桌面来等待你的程序的运行。


其次,也更为重要的时,“blob”这样的方式也干扰了我们编写使用其他元函数做为参数的元函数的能力。为了让你明白这一点,考虑下面接收两个两个参数的函数小例子:

    template <class X, class UnaryOp1, class UnaryOp2>
    X apply_fg(X x, UnaryOp1 f, UnaryOp2 g)
    {
        return f(g(x));
    }

这并不是我们设计 apply_fg 的唯一方式,假设我们将 f 与 g 变成单参数,也就是 blob 方式,像下面这样:

    template <class X, class Blob>
    X apply_fg(X x, Blob blob)
    {
        return blob.f(blob.g(x));
    }

调用 f 与 g 的协议有点像我们访问 traits blob 一样,为了取得函数的结果,你需要访问其中一个成员。问题是并没有一个单一的方式来取得调用这些 blob 的结果。每一个像 aaply_fg 这样的函数都会使用自己的函数名集合,为了能将 f 或者 g 传递给另一个这样的函数,我们需要用新的名字将其打包(译注:即重新写一个 blob 来将 f,g
的调用转成实际函数的调用)。


“blob” 是一个“反模式”(一种应该避免的惯用法),因为其降低了程序的总体交互性,或者组件之间平滑合作的能力。第一种接收参数方式的 apply_fg 函数是一种相对较好的方式,因为其提高了可交互性。

当使用同一种协议传递可调用的参数给  apply_fg,我们就很容易地交换他们:

    #include <functional>
    float log2(float);

    int a = apply_fg(5.Of,    std::negate<float>(), log2);
    int b = apply_fg(3.14f,   log2, std::negate<float>());

这种可以使得不同的参数类型能够相互交换的能力叫做多态。在字面上的意思是说:使用多种形式的能力。
   
为了在元函数中取得多态性,我们需要一种单一的方式来调用它们。Boost 中所使用的惯例如下:

    metafunction-name<type-arguments...>::type
   
从现在开始,当我们提及元函数,我们就是指可以通过这种语法“调用”的模板。

 


多态

在 C++ 中,有两种类型的多态,动态多态使得我们通过一个基础类型的指针或者引用来操作多个派生类型的对象。而我们这一章所讨论的静态多态,则使得不同类型的对象 以同一种方式进行操作,只要它们支持相同语法。动态与静态也表示对象的相应的实际类型是在运行时确定的还是编译时确定的。动态多态伴随着“延迟绑定”或者 是“运行时分发”(通过虚拟函数来提供),是面向对象编程语言的关键的特点。静态多态(也称为参数性多态)则是泛泛型编译的本质。

数据中心机房是现代信息技术的核心设施,它承载着企业的重要数据和服务,因此,其基础设计与规划至关重要。在制定这样的方案时,需要考虑的因素繁多,包括但不限于以下几点: 1. **容量规划**:必须根据业务需求预测未来几年的数据处理和存储需求,合理规划机房的规模和设备容量。这涉及到服务器的数量、存储设备的容量以及网络带宽的需求等。 2. **电力供应**:数据中心是能源消耗大户,因此电力供应设计是关键。要考虑不间断电源(UPS)、备用发电机的容量,以及高效节能的电力分配系统,确保电力的稳定供应并降低能耗。 3. **冷却系统**:由于设备密集运行,散热问题不容忽视。合理的空调布局和冷却系统设计可以有效控制机房温度,避免设备过热引发故障。 4. **物理安全**:包括防火、防盗、防震、防潮等措施。需要设计防火分区、安装烟雾探测和自动灭火系统,设置访问控制系统,确保只有授权人员能进入。 5. **网络架构**:规划高速、稳定、冗余的网络架构,考虑使用光纤、以太网等技术,构建层次化网络,保证数据传输的高效性和安全性。 6. **运维管理**:设计易于管理和维护的IT基础设施,例如模块化设计便于扩展,集中监控系统可以实时查看设备状态,及时发现并解决问题。 7. **绿色数据中心**:随着环保意识的提升,绿色数据中心成为趋势。采用节能设备,利用自然冷源,以及优化能源管理策略,实现低能耗和低碳排放。 8. **灾难恢复**:考虑备份和恢复策略,建立异地灾备中心,确保在主数据中心发生故障时,业务能够快速恢复。 9. **法规遵从**:需遵循国家和地区的相关法律法规,如信息安全、数据保护和环境保护等,确保数据中心的合法运营。 10. **扩展性**:设计时应考虑到未来的业务发展和技术进步,保证机房有充足的扩展空间和升级能力。 技术创新在数据中心机房基础设计及规划方案中扮演了重要角色。例如,采用虚拟化技术可以提高硬件资源利用率,软件定义网络(SDN)提供更灵活的网络管理,人工智能和机器学习则有助于优化能源管理和故障预测。 总结来说,一个完整且高效的数据中心机房设计及规划方案,不仅需要满足当前的技术需求和业务目标,还需要具备前瞻性和可持续性,以适应快速变化的IT环境和未来可能的技术革新。同时,也要注重经济效益,平衡投资成本与长期运营成本,实现数据中心的高效、安全和绿色运行。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值