C++菜鸟学习笔记系列（10）

本期主题：数组、数组与指针之间的关系

我们在学习C语言时对于数组一定有很多的了解。数组在C以及C#中都很常见，但是对于C++语言我们更喜欢用和而不是数组和下标。
数组与我前面介绍的类型相比非常类似，它们都是可以存放相同对象的元素，且都可以通过其所在位置进行访问。但是与vector相比数组的大小确定不变，不能随意向数组中添加元素，缺少了一部分灵活性。（也正是数组的大小固定导致我们在C++中更喜欢用vector而不是数组）

（如果你有一定的C语言基础，可以直接跳过第一部分内容，直接读后面关于数组的使用及其与指针之间的关系就可以了。）

1.定义及初始化内置数组

数组是一种复合类型。数组的声明类似于a[d]的形式，其中a是数组的名字，d是数组的维度。维度说明了数组中元素的个数，因此必须大于0。数组中元素的个数也属于数组类型的一部分，编译的时候维度应该是已知的。即维度必须是一个常量或者是一个常量表达式。
下面我们来看一下具体怎么定义数组：

在上述代码中我们可以通过字面值或者一个常量值来作为数组的维度值，但是一个变量不能作为数组的维度值。

我们可以对数组的元素进行列表初始化，此时允许忽略数组的维度。如果在声明时没有指明维度，编译器会根据初始值的数量计算并推测出来；相反的，如果我们指明了维度，那么在列表初始化的时候初始值的总数量不能超出指定的大小。如果维度比提供的初始值数量大，则用提供的初始值初始化靠前的元素，剩余的元素则默认初始化。
下面我们来看一下显式初始化数组的例子：

上述代码中的数组初始化方式适合大多数据类型数组的声明，但是对于字符数组仍然存在一些特殊性。
字符数组有一种额外的初始化方式，即我们可以使用字符串的字面值对此类数组进行初始化。当使用这种方式时初始化字符数组时一定要注意字符串字面值的结尾处还有一个空字符，这个空字符也会像字符串的其他形式一样被拷贝到字符数组中去。

注意：不能把数组的内容拷贝给其他数组作为其初始值，也不能使用数组为其他数组赋值。

与标准库类型vector和string一样，数组的元素也是能够使用范围for语句或者下标运算符来访问。
数组除了大小固定这一特点外其余用法和vector基本类似，它们都可以使用下标运算符，但是仍存在一个不太明显的区别是数组中的下标运算符是由C++语言直接定义的，而vector中的下标运算符是库模板vector定义的，只能用于vector类型的运算对象。
下面我们来看一个使用数组下标的小例子：

注意：与标准库类型vector和string类似的，检查数组的下标是否在正确的区间内也是我们对代码检验正确性的一个重要内容，但是除了谨慎小心和进行彻底测试之外我们并没有更好的办法去避免这一类问题的出现。

3.指针和数组之间的联系

在C++语言中指针与数组之间有非常密切的联系，使用数组时，编译器常常把它转换为指针。
我们在中曾经有过介绍使用取址符&可以获得某个对象的指针，取址符可以用于任何对象。数组的元素也是对象，对数组使用下标运算符得到该数组中某个位置的元素然后再通过取址符就可以获得指向该元素的指针。例如：

当我们省略下标直接对数组的名字使用取地址符时：

编译器会默认将其替换为一个指向数组首元素的指针，等价于string *p = &arr[0];
由此我们还可以对数组的下标有这样的理解，即我们可以认为：arr[3]等价于在编译器中先找到arr[0]的位置，然后再往后移动3个元素得到arr[3]，类似于

从上述的介绍中我们可以意识到尽管我们肯定可以通过计算得到数组最后一个元素的指针，但是这样是非常繁琐而且极易出现错误。为了让指针的使用更加简单、安全，C++ 11标准中引入了begin 和 end两个函数，类似于迭代器中的成员函数begin()、end()，不同的是在这里数组是作为begin 和 end两个函数的参数。
下面我们来看一个使用的小例子：

如上所示我们改写了第一个例子中的代码，实现了相同的功能，通过begin 和 end两个函数来确定数组的头和尾，然后通过指针的移动获得数组中的所有元素。

好了这次我们就介绍到这里了。

注：虽然这篇博客的内容十分简单，但是大家若有转载还请标明出处！

还有大家若对博客中的内容有任何问题可以随时联系我提问。

在两部分的文章。我会介绍Team Foundation Server一些核心功能，着重于产品的日常应用是如何将这些功能结合使用。

作为一个软件开发。在我的职业生涯，。我常常用于支持软件开发过程中大量的开发工具，版本控制工具如、包、生成脚本语言、单元測试框架和需求分析工具等等。在.NET平台上，大量的支持工具可以非常好地独立工作，可是。为了使得各种工具之间都够互相协作，还是常常须要一些手动工作。

这并非由于该产品包括的各种新增特性一定是最好的。关键因素是它的集成性。

Team Foundation Server(TFS)是这样一种server产品，它须要部署到软件开发环境中。这样开发者就能够使用它提供的各种服务。

由于TFS是设计用于大规模团队，因而有两种拓扑结构供选择：双server和单server。

双server部署将SQL Server 2005 的数据库引擎和分析服务组件分开安装在不同的机器上。这样就能够实现可扩展性（通过增大用于大量用户注冊操作的空间以及将处理负载的不同数据仓库安装在不同的机器上实现。这样的机器最大可达64位。）

在开发团队能够使用Team Foundation Server之前，必须先创建一个团队项目，团队项目代表了一个全部团队活动都在这里发生的管理单元。

右键单击树状视图中的server节点，TFS管理员就能够选择“新建团队项目”。其实，这个选项一般是隐藏的。可见须要新建一个团队项目的情况是非常少的。绝大部分情况下。一个软件开发团队在一个大型软件的生命周期中仅有一个团队项目。

创建团队项目时。开发小组须要做的第一件事情是决定使用那个开发模型。

Team Foundation Server同意开发小组选择他们想要使用的不论什么特定软件开发方法。以下的列表中提供了两种开发模型：

• 能力成熟度集成模型软件开发

每一个开发模型都有一组特有的定制特性，包含定义工作项（要做的事情、要确定的事情、需求等等），过程管理和报告。

下表显示了两个默认的开发模型中不同工作项的分解：

在这样的情况下即使工作项的数目和名称存在差异，也应该指明使用这两种开发模型通用方法，而不是开发小组来猜測他们该怎样使用这些工作项类型，开发模型能够包括一些可选的过程管理页面。

假设对话框中的模型不适合你的详细要求，能够订制它们以满足你的要求。

创建了团队项目后，开发小组须要做的第一件事是分解已经创建的初始工作项集。

这些工作项帮助开发者完毕一系列能够使得软件项目成功開始的活动。而且根据不同的开发模型选择不同的工作项。通过展开团队项目节点，就能够看到工作项目录，继续展开然后打开查询目录可看到所有或部分工作项。

最后须要书写一个新的工作项查询列表。新定义的查询能够放在“团队查询”和“我的查询”这两个目录的不论什么一个。团队查询是一个可被项目小组中的全部开发者訪问的全局可訪问容器。我的查询是一个由每一个程序开发员全部的私有查询集。

我常常使用的一个实用的查询是Recycle Bin query，这个查询可用于打开近期关闭又须要又一次打开的工作项（偶然关闭工作项的情况时有发生）。第一步是从工作项节点的背景菜单中选择“加入查询”。

在查询编辑器打开后，简单的用户接口就能够基于某些简单的表达式从工作项列表中过滤出须要的项目。在上面的情况中。查询设置为返回当前状态为关闭的团队项目中的全部工作项。

訪问了工作项。就能够应用Team Foundation Server中的版本号控制。像TFS中的其他特征一样，版本号控制功能位于SQL Server 2005之上，用于提供良好的性能和可扩展性（实际上。宿主在TFS中的版本号控制存储器的大小预计有千兆字节。

开发小组可能遇到的第一个与版本号控制相关的工作项是迁移已经存在的源码，这个工作项提供了在迁移源码是须要做什么的具体视图。

在程序猿将文件加入到版本号控制存储器之前，须要将版本号控制存储器的逻辑结构映射到本地机器上的文件系统。Team Foundation Server 引入了工作区的概念。工作区是物理位置和文件系统间的一组映射，一个文件系统与一个特殊用户和计算机组合相匹配。

在文件上进行工作的程序猿，他们是逻辑的进出工作区。为了建立一个工作区，程序猿须要双击Team Explorer中的源代码控制图标，到工作区下拉菜单。

我发现将整个源码树的根映射到本地驱动器上的一个详细位置并将其作为唯一映射是最简单的方法。我自己的方法是在我的数据驱动器的根文件夹上创建一个“沙盒”文件夹，在它的下级有一个子文件夹，将其命名为我连接到的TFSserver的名字。

（我连接到了多个TFSserver。因此一定要注意避免混淆）。

建立了映射之后，浏览源码控制浏览器将会列出源码树上逻辑位置的本地路径。至此你就能够加入源码到这个容器中。

程序猿面对的一个局限是他们不能将文件加入到版本号控制存储器的根中（$/），且全部以及目录都直接和某个特定团队项目相关。这里面的逻辑是。一个Team Foundation Server可用于大量项目，每一个项目应该在它们自己的区域内工作。

在Team Foundation Server中安排源码有无数的方式。你为什么选用这样的而不用还有一种。具体的原因说明超出本文的范围。以下选择的方式仅是一个用于示例。特别的地方是，我选择加入了三个字目录：Trunk, Branches 和Releases，例如以下图。

目录加入到版本号控制系统后。其它的程序猿并不会马上看到，他们必须像文件一样进行注冊。在本例中。在注冊前我将加入一组解决方式和项目文件到这个容器中，然后一起注冊。

除了增强了性能和扩展性外，TFS将其版本号控制系统安装在SQL Server 2005上，这意味着，进行原子提交和注冊的方法是可能的。

也就是说，要么所有注冊成功，要么所有失败。注冊能够在源码控制浏览器或解决方式浏览器上运行（或者在强制改变工具窗体中进行）

版本号控制系统和工作项存储器在注冊时集成在一起。当注冊时。能够将其与一个或多个工作项关联。比如，由于这是刚引入源码。所以我能够浏览注冊对话框中的工作项视图。选择工作项3387和它关联。注意当关联工作项时不管默认的选择怎样都要将注冊行为设定为 “解决”，这样做的目的是防止任务关闭工作项，因此较早建立十分实用的Recycle Bin 查询。

建立一个注冊，就叫做一个改变集，一个源码容器只是是一系列不断彼此堆积起来的改变集。由于在数据库中改变集是一个能够区分的实体。因此能够将数据和它关联在一起，所以上面建立的改变集和工作项3387的关系能够在改变集中浏览或者在工作项中浏览。以下的屏幕截图显示了连到工作项的改变集。

和Team Foundation Server中的版本号控制相关的一个新概念是搁置集。搁置集的思想是程序猿在过周末歇息时。能够将在工作日做的改变放在某个安全的地方。建立一个搁置集相当简单，首先，程序猿在解决方式浏览器中的背景菜单中选择“搁置必要的改变”，然后出现以下的对话框。

程序猿能够给搁置集一个名字，以便以后能够查找和恢复它，和注冊对话框一样，搁置集也能够加入评论和关联工作项。

搁置集仅包括改动过的文件。由于改变集版本号是从版本号控制存储器引出的，所以创建他们的相当简单。

为了恢复搁置集，能够选择背景菜单中的“解冻必要改变”选项。程序猿能够查找由他们或其它程序猿建立的搁置集。

其实搁置集能够共享，这意味着它们能够非常好的运行代码预览，增强单注冊点策略，这对一个特别项目在封装时可能非常十分实用。

在本文的下一部分，我将具体介绍搁置集，TFS中完好的分支支持，TFS是怎样支持自己主动生成的并介绍一下报告功能提供的功能。

功能介绍一：微软最新配置管理工具

在当今的环境下。公司业务越来越复杂，软件开发复杂度也越来越高，此时发如今众多项目中时有这种现象发生：文档散落在不同地方，代码缺失，代码和文档不一致，同一系统多个版本号，各项目採用不同配置管理工具、无统一的规范。随着时间推移我们的项目管理风险不断上升、项目实施难度不断添加、项目实施质量难以掌控。怎样可以高速地构造出高质量的应用系统来满足不断变化的业务增长所带来的需求？我们急须要建立一套完好的配置管理体系。来提高生产效率。提高产品质量。终于实现企业效益最大化。现阶段配置管理面临的挑战是：

l 更好的组织性，更高的开发管理水平

l 保护投资 ：企业级的过程历史数据、经验、数字化资产

l 建立标准的开发环境

l 实现并行开发，缩短产品面市时间

l 为创造性的工作释放很多其它的时间

Server（TFS）实施软件配置管理可以有效解决这些问题，比如可以集中管理各项目的文档、代码。对项目中的文档、代码等的变化进行有效管理，可以方便地重现某个文件的历史版本号，可以又一次编译某个历史版本号。使文档维护工作变得easy、可以使多团队并行开发成为现实。同一时候实行统一的配置管理流程可提高项目组间人员流动时的工作效率。也是对工作成果的一种有效保护。

功能介绍二：外包管理工具

l 开发出来的系统不能满足用户或者业务需求

l 开发过程不透明。非常难监控开发的进展情况

l 无法有效的控制项目的变更，添加了项目的风险

l 无法有效实现多地的协同开发。添加外包开发成本（场地，差旅费）

l 软件复用率低下，减少了企业的投资回报率

l 无法开展规范化的測试工作，非常多问题要到验收阶段才会暴露出来

l 缺乏软件开发历史数据的积累，无法准确估算项目成本

l 缺乏必要的版本号管理工具，系统在构建和公布时产生问题

l 缺乏对应的文档。添加了维护和升级的难度