C++跨平台开发技术指南(赠品)
点击看大图基本信息
- 作者： (美)Syd Logan [作译者介绍]
- 译者： 徐旭铭
- 丛书名： C++设计新思维
- 出版社：机械工业出版社
- ISBN：9787111250821
- 上架时间：2010-9-3
- 出版日期：2009 年1月
- 开本：16开
- 页码：318
- 版次：1-1
- 所属分类：
赠品
内容简介回到顶部↑
《c++跨平台开发技术指南》详细介绍c++语言的跨平台技术，包含的主要内容有：netscape在向数百万win．dows、．macos和linux用户发布浏览器时采用的策略和过程；如何使用基于标志的api，包括posix和st[。；如何避免隐晦的移植性陷阱，相关的如浮点数、char类型、数据序列化，以及c++的类型；如何建立一个有效的跨平台bug报告和跟踪系统等。《c++跨平台开发技术指南》内容详实，实例丰富。适合软件开发技术人员参考。
作译者回到顶部↑
本书提供作译者介绍
Syd Logan，是一位工作生活在南加州的软件工程师，拥有圣地亚哥州立大学的计算机科学学士和硕士学位。Syd曾是Netscape Client Product Development（CPD）团队的一员，在Netscape 6和7的开发过程中，他同时担任了开发和管理的职务。之后，Syd留在AOL并作为AOL Instant Messenger团队的一员实现了VoIP点对点视频的特性。Syd的其他著作还包括《Developing Imaging Applications with XIELib》《Gtk+Programming in C》（Prentice Hall 1997和2001）。他的研究兴趣包括机器学习、操作系统设计、算法，以及任何.. << 查看详细
目录回到顶部↑
“c++设计新思维”丛书前言
译者序
序
前言
引言
第1章 策略与管理
条款1：把所有的平台都放在同样重要的位置
条款2：使用公共的代码
工厂模式在不同平台上的实现
类的实现
平台相关的。processesimpl类
创建实例层次。一
用cvs或svn组织项目
编译代码和makefile
条款3：要求开发人员用不同的编译器编译代码
条款4：要求开发人员在不同的平台上编译代码
条款5：测试所有的平台
条款6：关注编译警告
gn2j标志
译者序回到顶部↑
这是一个Java横行，LAMP肆虐的年代。很多人说C和C++早已落伍了，将在网络大潮中默默隐去，但当你读完本书，便会体会到C和C++的魅力所在。.
本书向读者完整地呈现了C和C++在跨平台领域上的方方面面。从丰富的工具，完善的软件工程，到开发、部署、安装以及系统设计。什么问题应该避免，什么地方需要注意，十几年的经验让本书作者深谙此道。他不用理论来证明自己，而是用作品来展示理论。只有高手才能达到这种境界。
说到本书作者，Syd Logan是一位资深工程师，在C和C++领域耕耘数载。他全程参与了Netscape和Firefox浏览器的开发工作。此外，他还负责为AOL开发VOIP和点对点的视频功能。..
作为本书的译者，我也在翻译过程中获益匪浅。作者展示的是多年来在跨平台开发中的心得体会，即便你开发的不是C和C++的跨平台项目仍可从中受益。毕竟语言只是工具，设计思维才是最宝贵的财富。
无论Internet怎样发展，一切内容都要通过浏览器展示给用户。当年微软正是意识到这一点，才对Netscape发动了浏览器战争。出色的技术和商业成功没有必然联系，Netscape倒下了。然而其中的积淀却借着Mozilla凤凰涅槃。相比IE的不思进取，Firefox 3如火如荼的发布正说明了优秀的作品最终将得到用户的肯定。
我也希望大家能从本书中找到自己想要的知识。
如发现任何纰漏之处，敬请指正。
在此感谢华章图书的陈冀康老师对我的信任和鼓励，还要感谢Lydia和Ada的支持。
徐旭铭...
本书向读者完整地呈现了C和C++在跨平台领域上的方方面面。从丰富的工具，完善的软件工程，到开发、部署、安装以及系统设计。什么问题应该避免，什么地方需要注意，十几年的经验让本书作者深谙此道。他不用理论来证明自己，而是用作品来展示理论。只有高手才能达到这种境界。
说到本书作者，Syd Logan是一位资深工程师，在C和C++领域耕耘数载。他全程参与了Netscape和Firefox浏览器的开发工作。此外，他还负责为AOL开发VOIP和点对点的视频功能。..
作为本书的译者，我也在翻译过程中获益匪浅。作者展示的是多年来在跨平台开发中的心得体会，即便你开发的不是C和C++的跨平台项目仍可从中受益。毕竟语言只是工具，设计思维才是最宝贵的财富。
无论Internet怎样发展，一切内容都要通过浏览器展示给用户。当年微软正是意识到这一点，才对Netscape发动了浏览器战争。出色的技术和商业成功没有必然联系，Netscape倒下了。然而其中的积淀却借着Mozilla凤凰涅槃。相比IE的不思进取，Firefox 3如火如荼的发布正说明了优秀的作品最终将得到用户的肯定。
我也希望大家能从本书中找到自己想要的知识。
如发现任何纰漏之处，敬请指正。
在此感谢华章图书的陈冀康老师对我的信任和鼓励，还要感谢Lydia和Ada的支持。
徐旭铭...
前言回到顶部↑
在1998年加入Netscape前十余年的职业生涯里，我有幸在很多不同的平台上参与了很多不同的项目。我曾在一种很难懂的CPU(TMS34020)上用自己设计的嵌入式内核工作。我从一个编写文件系统驱动程序以支持网络文件系统(Network File System，NFS)的客户端开发Windows NT和Windows 98内核的项目中获得了Windows内核开发的经验。在用户端，我最擅长的是用户界面开发，从最初为UNIX开发Motif(Z-Mail)和OpenWindows程序，到最后在Windows平台上接触Win32以及MFC。我甚至还曾经有机会为Apple的一个在早期MacOS上的项目用Mac Toolbox API编写代码。所有的这些代码都是用C写成，全部都是高度不可移植，只是为了特定的工作和平台编写的代码。.
然后；我作为一名UNIX专家加入了Netscape。刚开始的时候，我的任务是修复Netscape 4.x浏览器上的bug，特别是处理一个移植到IBM AIX平台上的版本的问题。Netscape和IBM签订了一份合同，保证AIX版本的Netscape浏览器上的bug或者IBM认为重要的bug都要在一定的时间内修复。我就是因此而被雇用的。类似的和SGI、HP、Sun或者其他平台签订的合约让Netscape雇用了很多额外的员工。我们有两到三个人专门对付AIX平台上的bug。
在当时，可移植性还没有得到Netscape的重视。虽然Netscape的很多代码都是可移植的，但是项目都还没有一个统一的构建系统，用户界面的代码也完全是平台相关的。很多bug都是由于平台相关的天性所造成(所以需要不同的团队支持不同的平台)。在Windows上完美运行的Netscape在缺乏支持的平台上就跑得一塌糊涂。不是所有的平台都拥有相同的特性，特性在乎台与平台之间的表现也不尽相同。
加入Netscape为AIX修复了一年bug后，我转到了Netscape即时通信工具(Instant Messenger)的团队里，在新的基于开源的Mozilla平台上工作。这个三人团队的工作是把AOL Instant Messenger客户端移植到Netscape浏览器里。NetScape IM团队是在AOL收购Netscape后仓促成立的，目的是为了把基于AOL的功能整合到应用程序里。(另一个整合到Netscape里的关键项目是AOL Mail。)
就像前面提到的，开发中新的Netscape客户端是基于开源的代码库Mozilla。这个代码库在那个时候绝大多数是由位于圣地亚哥和山景城的Netscape工程师开发，由开源社区贡献代码的。(我在此后把这个项目叫做Netscape／Mozilla。)
当时Netscape和微软在浏览器市场上争夺得非常激烈，所以浏览器必须在Windows上工作正常，按时发布。Netscape从Netscape的门户网站上获得了大量的广告收入，当新版本发布的时候点击率是最高的，成千上万的用户都涌入网站下载最新版本的Netscape。不光Windows，在Mac OS和Linux上支持Netscape也促成了高访问量和高收入。所以在：Netscape内部，Linux和Mac OS与Windows拥有同等待遇。不仅仅因为这是“正确”的事情(就像我们大多数人相信的一样)，也因为对公司来说；每个访问都是非常重要的。
Netscape／Mozilla在我看来是一个全新的起点。首先，新版本的Netscape不只是一个浏览器，它是一个包含应用程序的平台。(随etscape发布的主要应用有AIM、邮件／新闻客户端、一个名为Composer的所见即所得的HTML编辑器、Chatzilla IRC客户端和浏览器自身。这就类似于今天Firefox的扩展。)
Netscape／Mozilla采用自己开发的技术来构建图形用户界面而不是用本地平台提供的MFC或者Gtk+等C／C++GUI工具。像HTML描述网页布局一样，用户界面的布局使用静态XML文件来描述。为这个目的而开发的XML叫做XUL。像网页里链接到HTML元素的JavaScript一样，通过attribute链接到XML元素的JavaSeript代码用来响应菜单选择和按钮点击。只要有这个XML和JavaScfipt的组合就能为Netscape／Mozilla构建应用程序。而且因为XML和JavaScript生来就是可移植的，所以采用这两项技术设计出来的用户界面同样是可移植的。如果JavaScript不足以完成某些功能(可能是任何真正的应用程序，就像Netscape和Mozilla发布的那些)，JavaScript代码可以从共享库里去调用C++函数。这些共享库，或者说组件，在Netscape／Mozilla架构里通过两种技术来直接支持：XPConnect和XPCOM。这些技术允许组件开发人员用界面定义语言(Interface Description Language，IDL)来定义未知平台的界面。JavaScript代码可以使用XPCOM和XPConnect来查询一个组件是否存在，然后查询一个特定的界面。如果一切顺利，JavaScript代码会获得一个可以和其他任何对象一样调用的对象(只要它不是用C++写的)，可以做到任何JavaScript程序员能想到的事情。这些界面自身就是高度平台无关的。
老实说，Netscape／Mozilla架构里那些为了支持移植性而做的工作对我来说一开始不是很明显。但是渐渐地，我变得非常感谢这个方法所带来的力量。提出这个架构的决定所带来的积极影响是无可争议的，Netscape不单单向Windows、Mac和Linux，还向SunOS、AIX、HP-UX、SGIIrix和其他许多类UNIX平台的用户提供了千百万份浏览器。针对“tier-1平台(Mac OS、Linux和Windows)的产品基本上是同一时间发布的。这些版本基本上拥有相同的特性，当然，也拥有相同的bug。要在如此大的范围里达到可移植性需要一个非常特殊的架构。这也是本书的目标之一，让你对Netscape／Mozilla架构对代码移植性的直接影响有一个清晰的认识。
不过，让浏览器和相关应用(AIM、Mail、Composer)可移植的不仅仅是Netscape／Mozilla的架构。要想实现这个目标，光有一个可靠的架构是不够的，还需要在一系列的策略和过程中把跨平台开发作为高优先级的考量，以及严格的纪律来保证这些准则得以遵守。Netscape和Mozilla在Tinderbox和Bugzil-la这样的工具上的巨额投资都迅速得到了回报。工程师被强制为其他平台而不仅仅为他们自己的平台考虑问题，如果在日常测试中发现某个平台有问题则可能会导致所有平台上开发的停滞，而不只是那个平台受到影响而已。因为Netscape和Mozilla意识到要真正实现可移植性的惟一途径就是有问题当场解决。本书尽量避免涉及代码而偏向描述准则，就是因为无论架构在支持跨平台上有多出色，如果要最终完成相同质量的产品，你必须在所有要支持的平台上巨细靡遗，倾人相同的关注。
和我们编写的数据结构和算法的程序一样，在我看来，可移植性很大程度上包含了架构和过程。这个信念正是你手上这本书的基石。
本书的组织方式
本书由一系列章节组成。大多数章节都包含一组条款。每个条款涵盖了一个支撑章节主题的特定话题。在书本的开头，你会发现一些小节包含了这样一些条款，它们所介绍的最佳实践必须和整个开发组织沟通，包括管理部门、开发部门和测试部门。之后的章节则覆盖了管理人员应该了解的软件工程，不过它们其实主要是写给那些编写代码的读者看的。在前面的几章里，一共介绍了23条条款。
用户界面的实现在开发跨平台的桌面应用中占有很重要的地位。条款23将会介绍这个主题。最后两章则讨论了跨平台GUI的相关论题。其中的第1章全面介绍了跨平台GUI工具包wxWidgets。你还可以查阅Prentice Hall出版的关于这个主题更详细的书籍，JulianSmart等人所著的《Cross-platform GUI Programming with wxWidgets》。wxWidgets并非惟一可用的跨平台GUI工具包。另一个可选的，同时也十分流行的跨平台GUI工具包是Qt，它不在本书所讨论的范围之内。但是，如果你对Qt有兴趣，市面上有很多介绍其详细细节的书籍，包括最著名的《C++GUI Programming with Qt4》，作者是Jasmin Blan-chette和Mark Summerfield，同样也是由Prentice Hall出版(还可以查阅他们关于Qt3的书)。
本书最后一章第9章“用C++开发跨平台GUI工具包”，从介绍Netscape和Mozilla浏览器套件里的一个重要的跨平台GUI工具包组件XPToolkit开始，详细介绍了我专门为本书创建的一个工具包——Trixul。Trixul具有很多和我们在Netscape用来开发GUI的Netscape／Mozilla XPToolkit相同的属性。比如，允许用XML和JavaScript来描述用户界面；都支持让用户界面调用C／C++写成的共享库的基于组件的模型；高度可移植等。Trixul和Mozilla提供的工具包有两个最大的不同。第一，Trixul是一个桌面的GUI工具包，而XPTootkit应用只在Web浏览器里执行。第二，Trixul的设计(我觉得)比XPToolkit要简单得多，(我确信)这让我在描述工具包的架构和背后的思想时更得心应手。虽然我没有真的希望你为自己的项目设计一个跨平台GUI工具包，但是从观察Trixul是如何设计和实现的过程中，还是有很多东西可以学习的。..
本书的大多数章节都可以按照任意顺序阅读，如果你是技术经理，我推荐你仔细阅读下列各章：
·第1章，“策略与管理”
·第2章，“Build系统和Toolchain”
·第3章，“软件配置管理”
技术经理还至少应该浏览以下章节：
然后；我作为一名UNIX专家加入了Netscape。刚开始的时候，我的任务是修复Netscape 4.x浏览器上的bug，特别是处理一个移植到IBM AIX平台上的版本的问题。Netscape和IBM签订了一份合同，保证AIX版本的Netscape浏览器上的bug或者IBM认为重要的bug都要在一定的时间内修复。我就是因此而被雇用的。类似的和SGI、HP、Sun或者其他平台签订的合约让Netscape雇用了很多额外的员工。我们有两到三个人专门对付AIX平台上的bug。
在当时，可移植性还没有得到Netscape的重视。虽然Netscape的很多代码都是可移植的，但是项目都还没有一个统一的构建系统，用户界面的代码也完全是平台相关的。很多bug都是由于平台相关的天性所造成(所以需要不同的团队支持不同的平台)。在Windows上完美运行的Netscape在缺乏支持的平台上就跑得一塌糊涂。不是所有的平台都拥有相同的特性，特性在乎台与平台之间的表现也不尽相同。
加入Netscape为AIX修复了一年bug后，我转到了Netscape即时通信工具(Instant Messenger)的团队里，在新的基于开源的Mozilla平台上工作。这个三人团队的工作是把AOL Instant Messenger客户端移植到Netscape浏览器里。NetScape IM团队是在AOL收购Netscape后仓促成立的，目的是为了把基于AOL的功能整合到应用程序里。(另一个整合到Netscape里的关键项目是AOL Mail。)
就像前面提到的，开发中新的Netscape客户端是基于开源的代码库Mozilla。这个代码库在那个时候绝大多数是由位于圣地亚哥和山景城的Netscape工程师开发，由开源社区贡献代码的。(我在此后把这个项目叫做Netscape／Mozilla。)
当时Netscape和微软在浏览器市场上争夺得非常激烈，所以浏览器必须在Windows上工作正常，按时发布。Netscape从Netscape的门户网站上获得了大量的广告收入，当新版本发布的时候点击率是最高的，成千上万的用户都涌入网站下载最新版本的Netscape。不光Windows，在Mac OS和Linux上支持Netscape也促成了高访问量和高收入。所以在：Netscape内部，Linux和Mac OS与Windows拥有同等待遇。不仅仅因为这是“正确”的事情(就像我们大多数人相信的一样)，也因为对公司来说；每个访问都是非常重要的。
Netscape／Mozilla在我看来是一个全新的起点。首先，新版本的Netscape不只是一个浏览器，它是一个包含应用程序的平台。(随etscape发布的主要应用有AIM、邮件／新闻客户端、一个名为Composer的所见即所得的HTML编辑器、Chatzilla IRC客户端和浏览器自身。这就类似于今天Firefox的扩展。)
Netscape／Mozilla采用自己开发的技术来构建图形用户界面而不是用本地平台提供的MFC或者Gtk+等C／C++GUI工具。像HTML描述网页布局一样，用户界面的布局使用静态XML文件来描述。为这个目的而开发的XML叫做XUL。像网页里链接到HTML元素的JavaScript一样，通过attribute链接到XML元素的JavaSeript代码用来响应菜单选择和按钮点击。只要有这个XML和JavaScfipt的组合就能为Netscape／Mozilla构建应用程序。而且因为XML和JavaScript生来就是可移植的，所以采用这两项技术设计出来的用户界面同样是可移植的。如果JavaScript不足以完成某些功能(可能是任何真正的应用程序，就像Netscape和Mozilla发布的那些)，JavaScript代码可以从共享库里去调用C++函数。这些共享库，或者说组件，在Netscape／Mozilla架构里通过两种技术来直接支持：XPConnect和XPCOM。这些技术允许组件开发人员用界面定义语言(Interface Description Language，IDL)来定义未知平台的界面。JavaScript代码可以使用XPCOM和XPConnect来查询一个组件是否存在，然后查询一个特定的界面。如果一切顺利，JavaScript代码会获得一个可以和其他任何对象一样调用的对象(只要它不是用C++写的)，可以做到任何JavaScript程序员能想到的事情。这些界面自身就是高度平台无关的。
老实说，Netscape／Mozilla架构里那些为了支持移植性而做的工作对我来说一开始不是很明显。但是渐渐地，我变得非常感谢这个方法所带来的力量。提出这个架构的决定所带来的积极影响是无可争议的，Netscape不单单向Windows、Mac和Linux，还向SunOS、AIX、HP-UX、SGIIrix和其他许多类UNIX平台的用户提供了千百万份浏览器。针对“tier-1平台(Mac OS、Linux和Windows)的产品基本上是同一时间发布的。这些版本基本上拥有相同的特性，当然，也拥有相同的bug。要在如此大的范围里达到可移植性需要一个非常特殊的架构。这也是本书的目标之一，让你对Netscape／Mozilla架构对代码移植性的直接影响有一个清晰的认识。
不过，让浏览器和相关应用(AIM、Mail、Composer)可移植的不仅仅是Netscape／Mozilla的架构。要想实现这个目标，光有一个可靠的架构是不够的，还需要在一系列的策略和过程中把跨平台开发作为高优先级的考量，以及严格的纪律来保证这些准则得以遵守。Netscape和Mozilla在Tinderbox和Bugzil-la这样的工具上的巨额投资都迅速得到了回报。工程师被强制为其他平台而不仅仅为他们自己的平台考虑问题，如果在日常测试中发现某个平台有问题则可能会导致所有平台上开发的停滞，而不只是那个平台受到影响而已。因为Netscape和Mozilla意识到要真正实现可移植性的惟一途径就是有问题当场解决。本书尽量避免涉及代码而偏向描述准则，就是因为无论架构在支持跨平台上有多出色，如果要最终完成相同质量的产品，你必须在所有要支持的平台上巨细靡遗，倾人相同的关注。
和我们编写的数据结构和算法的程序一样，在我看来，可移植性很大程度上包含了架构和过程。这个信念正是你手上这本书的基石。
本书的组织方式
本书由一系列章节组成。大多数章节都包含一组条款。每个条款涵盖了一个支撑章节主题的特定话题。在书本的开头，你会发现一些小节包含了这样一些条款，它们所介绍的最佳实践必须和整个开发组织沟通，包括管理部门、开发部门和测试部门。之后的章节则覆盖了管理人员应该了解的软件工程，不过它们其实主要是写给那些编写代码的读者看的。在前面的几章里，一共介绍了23条条款。
用户界面的实现在开发跨平台的桌面应用中占有很重要的地位。条款23将会介绍这个主题。最后两章则讨论了跨平台GUI的相关论题。其中的第1章全面介绍了跨平台GUI工具包wxWidgets。你还可以查阅Prentice Hall出版的关于这个主题更详细的书籍，JulianSmart等人所著的《Cross-platform GUI Programming with wxWidgets》。wxWidgets并非惟一可用的跨平台GUI工具包。另一个可选的，同时也十分流行的跨平台GUI工具包是Qt，它不在本书所讨论的范围之内。但是，如果你对Qt有兴趣，市面上有很多介绍其详细细节的书籍，包括最著名的《C++GUI Programming with Qt4》，作者是Jasmin Blan-chette和Mark Summerfield，同样也是由Prentice Hall出版(还可以查阅他们关于Qt3的书)。
本书最后一章第9章“用C++开发跨平台GUI工具包”，从介绍Netscape和Mozilla浏览器套件里的一个重要的跨平台GUI工具包组件XPToolkit开始，详细介绍了我专门为本书创建的一个工具包——Trixul。Trixul具有很多和我们在Netscape用来开发GUI的Netscape／Mozilla XPToolkit相同的属性。比如，允许用XML和JavaScript来描述用户界面；都支持让用户界面调用C／C++写成的共享库的基于组件的模型；高度可移植等。Trixul和Mozilla提供的工具包有两个最大的不同。第一，Trixul是一个桌面的GUI工具包，而XPTootkit应用只在Web浏览器里执行。第二，Trixul的设计(我觉得)比XPToolkit要简单得多，(我确信)这让我在描述工具包的架构和背后的思想时更得心应手。虽然我没有真的希望你为自己的项目设计一个跨平台GUI工具包，但是从观察Trixul是如何设计和实现的过程中，还是有很多东西可以学习的。..
本书的大多数章节都可以按照任意顺序阅读，如果你是技术经理，我推荐你仔细阅读下列各章：
·第1章，“策略与管理”
·第2章，“Build系统和Toolchain”
·第3章，“软件配置管理”
技术经理还至少应该浏览以下章节：
序言回到顶部↑
作为Firefox、Mozilla和Netscape浏览器解析和渲染超文本标记语言/可扩展标记语言/层叠样式表（HTML/XML/CSS）的引擎，Gecko是全世界使用最广泛的渲染引擎之一。.
而我身为Netscape的工程师以及后来Mozilla Gecko团队的开发经理，有幸从一开始就参与了Gecko引擎的开发。
Gecko诞生时的愿望是要创建一个跨平台的、小巧快速的、先进的可嵌入Web浏览引擎，而这一点正是我们在“浏览器大战”中争夺优势的砝码。当时笨拙的Netscape 4.x引擎显然已经无法再完全支持CSS2、CSS3和XML Web标准了。所以有人提出只使用原有的引擎的一部分库来重新开发。在Gecko项目的早期，我们曾经讨论过要采用拥有跨平台能力的Java而不是C++。但最后还是觉得只有C++以及它特有的开发过程、工具和设计技术，才能产生最好的解决方案。本书将会把这些过程、工具和设计技术作为最佳实践来逐一描述。
在进入Netscape工作之前，我曾为很多公司开发过跨平台软件。然而，Mozilla项目把这些经历提升到了一个完全不同的高度。我们使用和开发了一系列软件架构、工具和过程来实现大范围内的跨平台开发工作。
我的第一个任务是把Gecko从微软Windows系统上移植到Motif/Xlib上去。写过跨平台软件的人都知道，刚开始的移植工作是最有挑战性的。你会在那时发现软件的移植性到底如何。即使Gecko从设计的时候就是以可移植为目标，然而平台和编译器之间的细微差异还是搞得我们很头疼。这就是为什么需要有一个像Mozilla Tinderbox那样的工具来验证checkin代码的可移植性，并且还需要一个软件开发过程来要求工程师在向代码仓库提交新的源代码之前至少在两个平台上验证过。..
Gecko引擎开发的动机之一，是要在它上面重现Netscape Communicator的用户界面体验。这就要求有一个跨平台的用户界面方案，因为Netscape Communicator就是在多个平台上提供了图形用户界面的环境。所以我就有了这样一个机会来设计一个用户界面策略以解决这个棘手的跨平台问题。我撰写了一份文档，解释了如何在Gecko渲染引擎里把描述用户界面元素的XML元描述（XML meta description）与作为控件和事件逻辑的JavaScript相混合，以达到跨平台用户界面的目的。这份文档后来成为了XUL（XML User Interface Language）的原型。再后来，Firefox的开发人员用XUL和Gecko引擎开发出了小巧快速、广受欢迎的跨平台Web浏览器。第9章描述了如何在XUL上创建你自己的跨平台用户界面。
作为W3C SVG(Scalable Vector Graphics)最早的成员之一，我对Gecko能不断地进化和解决跨平台问题感到非常兴奋。最近添加的对SVG的原生支持则又是Gecko可移植性的一大胜利。
Syd Logan在这里要展示的信息是无数工程师对于那些和创建跨平台软件产品相关的特殊问题的真知灼见。虽然它是以C++为蓝本，不过很多技术都是可以为其他非C++软件项目所借鉴。我希望你能从中发现有用的工具、技术或是过程，从而避免跨平台开发中的陷阱，让你的项目取得巨大成功。
Kevin McCluskey ...
而我身为Netscape的工程师以及后来Mozilla Gecko团队的开发经理，有幸从一开始就参与了Gecko引擎的开发。
Gecko诞生时的愿望是要创建一个跨平台的、小巧快速的、先进的可嵌入Web浏览引擎，而这一点正是我们在“浏览器大战”中争夺优势的砝码。当时笨拙的Netscape 4.x引擎显然已经无法再完全支持CSS2、CSS3和XML Web标准了。所以有人提出只使用原有的引擎的一部分库来重新开发。在Gecko项目的早期，我们曾经讨论过要采用拥有跨平台能力的Java而不是C++。但最后还是觉得只有C++以及它特有的开发过程、工具和设计技术，才能产生最好的解决方案。本书将会把这些过程、工具和设计技术作为最佳实践来逐一描述。
在进入Netscape工作之前，我曾为很多公司开发过跨平台软件。然而，Mozilla项目把这些经历提升到了一个完全不同的高度。我们使用和开发了一系列软件架构、工具和过程来实现大范围内的跨平台开发工作。
我的第一个任务是把Gecko从微软Windows系统上移植到Motif/Xlib上去。写过跨平台软件的人都知道，刚开始的移植工作是最有挑战性的。你会在那时发现软件的移植性到底如何。即使Gecko从设计的时候就是以可移植为目标，然而平台和编译器之间的细微差异还是搞得我们很头疼。这就是为什么需要有一个像Mozilla Tinderbox那样的工具来验证checkin代码的可移植性，并且还需要一个软件开发过程来要求工程师在向代码仓库提交新的源代码之前至少在两个平台上验证过。..
Gecko引擎开发的动机之一，是要在它上面重现Netscape Communicator的用户界面体验。这就要求有一个跨平台的用户界面方案，因为Netscape Communicator就是在多个平台上提供了图形用户界面的环境。所以我就有了这样一个机会来设计一个用户界面策略以解决这个棘手的跨平台问题。我撰写了一份文档，解释了如何在Gecko渲染引擎里把描述用户界面元素的XML元描述（XML meta description）与作为控件和事件逻辑的JavaScript相混合，以达到跨平台用户界面的目的。这份文档后来成为了XUL（XML User Interface Language）的原型。再后来，Firefox的开发人员用XUL和Gecko引擎开发出了小巧快速、广受欢迎的跨平台Web浏览器。第9章描述了如何在XUL上创建你自己的跨平台用户界面。
作为W3C SVG(Scalable Vector Graphics)最早的成员之一，我对Gecko能不断地进化和解决跨平台问题感到非常兴奋。最近添加的对SVG的原生支持则又是Gecko可移植性的一大胜利。
Syd Logan在这里要展示的信息是无数工程师对于那些和创建跨平台软件产品相关的特殊问题的真知灼见。虽然它是以C++为蓝本，不过很多技术都是可以为其他非C++软件项目所借鉴。我希望你能从中发现有用的工具、技术或是过程，从而避免跨平台开发中的陷阱，让你的项目取得巨大成功。
Kevin McCluskey ...
书摘回到顶部↑
第2章Build系统和Toolchain
Toolchain是开发人员用来编写、编译和调试代码软件的总称。主要的组成有编辑器、编译器和调试器。如果你向一个有经验的工程师询问他最喜欢的工具，你一定人得到迅速而又热情的回应。当然各人的偏好不同，而且工程师最爱的配置也不一定在所有项目要支持的平台上都有。
……
Toolchain是开发人员用来编写、编译和调试代码软件的总称。主要的组成有编辑器、编译器和调试器。如果你向一个有经验的工程师询问他最喜欢的工具，你一定人得到迅速而又热情的回应。当然各人的偏好不同，而且工程师最爱的配置也不一定在所有项目要支持的平台上都有。
……
加载中...
