在以下领域，C++有着根本性的优势：低级系统程序设计、高级系统程序设计、嵌入式程序设计、数值科学计算、通用程序设计以及混合系统设计等等。让我们略微展开描述一下：
1. 低级系统程序设计：C++是迄今为止最好的低级程序设计语言。
2. 高级系统程序设计：包括操作系统核心、网络管理系统、编译系统、电子邮件系统、文字排版系统、图像和声音的编排系统、通讯系统、用户界面、数据库系统等等。
3. 嵌入式系统：包括照相机、汽车、火箭、电话交换机、汽车等等。
4. 数值/科学计算：包括仿真、实时数据获取和数据库访问等等。
Bjarne的个人主页上，有一页applications，那儿列出了一些（全部或大部分）使用C++编写的系统、应用程序和库。下面是一些例子：
1. Adobe Systems：所有主要应用程序都使用C++开发而成，比如Photoshop & ImageReady、Illustrator和Acrobat等。
2. Maya：知道“蜘蛛人”、“指环王”的电脑特技是使用什么软件做出来的吗？没错，就是Maya。
3. Amazon.com：使用C++开发大型电子商务软件。
4. Apple：部分重要“零件”采用C++编写而成。
5. AT&T：美国最大的电讯技术提供商，主要产品采用C++开发。
6. Google：Web搜索引擎采用C++编写。
7. IBM：OS/400。
8. Microsoft：以下产品主要采用C++（Visual C++）编写：
- Windows XP
- Windows NT：NT4、2000
- Windows 9x：95、98、Me
- Microsoft Office：Word、Excel、Access、PowerPoint、Outlook
- Internet Explorer，包括Outlook Express
- Visual Studio：Visual C++、Visual Basic、Visual FoxPro
- .NET Framework类库采用C#编写，但C#编译器自身则使用C++编写而成。
- Exchange
- SQL Server
- FrontPage
- Project
- 所有游戏
- ......
9. KDE：K Desktop Environment（Linux）。
10. Symbian OS：最流行的蜂窝电话OS之一。
我通常使用C++进行高端程序开发。
“通常”一词没什么好说的，有时只是出于公司文化或个人爱好方面的原因，选用了别的语言而不是C++，或者相反。我所说的“高端”是指：关键业务处理，效率要求极高，实时性要求高等等。
我看见几乎所有严肃的工控系统软件和实时数据采集、处理和表现（主要是图形）软件，都是采用C++（或C，少部分采用Java）编写而成的。
据我的了解，我原先所在的研究院几乎每一个研究所都在不同程度地使用C++（以及一些别的语言）。
想想看，迄今为止，现代Unix操作系统的各种变体上，最常使用的是什么样的开发语言？（C/C++）
C++语言
C++语言是灵活，但首先要看看使用者能不能发挥它的灵活性；C++语言够强大，但要看看使用者有没有本事发挥它的强大功能。
使用C++语言和编译器编写一个快速的程序，并不难，不过编写一个强健而高效的大型程序，就不是那么容易了。
语言之间的区别，绝非只是大括号和begin、end或Sub、End Sub之间的区别。选择了一种语言，你就选择了一种思维方式，一种程序设计思想。要想跳出语言的束缚，首先要对语言有着深刻的认识和透彻的把握。世界上一些大师级的人物，也常常毫不掩饰自己对某种语言（我并没有专指C++）的偏爱。一些人对语言尚一知半解，就大谈要跳出语言的束缚了 — 你无需跳出，因为你根本不曾深入。
纯粹的技术性（学术性）研究，总能给人带来纯粹的快乐。C++语言复杂至极，可研究性极强，但一般来说，没有3~5年的持续学习、思考、使用，是不可能真正掌握C++的。
我不是唯语言论或唯工具论者，但我反对抹杀不同语言、不同开发工具之间的区别。抱持这种观点的人，若非无知，即是别有用心。这就好比杂牌笔记本电脑厂商最喜欢叫嚷“笔记本电脑已经进入同质时代”一样，杂牌机怎么能和IBM相比？
选择C++或选择Java，要看你个人爱好和对将来的打算。虽然只是语言上的差别，但由此决定的就业领域的确不一样。
不管你走什么样的技术路线，不管你用不用它做开发，学习C++总会带来长远的好处。一名熟悉C++的开发人员，假如他不是一个偏执狂的话，再学习Java或C#，都要容易得多。
C++不过是一门编程语言，我们总是要用它来解决实际问题，所以要学习开发工具（比如Visual C++），了解操作系统（比如API），熟悉领域知识（比如电力系统），掌握其他软件技术（比如数据库），等等。编写真正的代码，解决实际问题的能力，才是衡量一名程序员是否有真水平的唯一标准。
设计模式和统一建模语言
设计模式（Design Patterns）和统一建模语言（Unified Modeling Language，UML）是两个不同的概念。前者主要目标在于提供可重用的面向对象软件设计方案，后者则是一种描绘软件蓝图的标准语言。
当然了，可以使用UML来描述设计模式的结构。
UML所描述的模型可以映射成C++、C#、Java等语言代码，甚至可以映射到关系型数据库。映射过程可以是双向的，一般都有相应的软件工具（或插件）支持。
不同的语言，特性有所差别，这多少会影响设计模式在该语言中的实现（方式、难易）。比方说，假如使用C语言来描述设计模式，那么，继承、封装和多态等特性就变成了需要研究的设计模式，但在任何一门面向对象的语言中，这都纯属多余。
现在市面上还没有看到象样的以C#为手段讲述设计模式的书（我没有看到），但这并不打紧，倘若有兴趣，完全可以读一读《Design Patterns: Elements of Reusable Object-Oriented Software》（中文版名《设计模式》机械工业出版社）这本书，尽管它主要以C++和Smalltalk语言为讲解手段。
设计模式本身无所谓好坏，根据你要解决的目标问题，选择适当的设计模式。
系统架构
在企业级软件开发中，架构第一重要。架构有缺陷，系统就存在硬伤。优秀的架构来自于优秀的设计。这一点毋庸置疑。
任何成功的软件，即使它没有明确地使用建模思想、架构方法，但在骨子里、潜意识中，大都具有良好的设计思想和架构。
只有写过好多好多代码以后，只有做过一些够份量的企业级项目之后，才可能对软件架构形成清晰的认识。很难想像一个连几行像样的代码都没有写过的人，对程序思想和架构却有着深刻的认识。这种人，十有八九属于纸上谈兵之辈。
我们时不时会看到这种情况，软件的设计也不算太差，但程序员要么不知道怎么写实现代码，要么是代码写得缺乏效率，或不够强健，甚至有时连“架构师”自己对此都一筹莫展。
我们也常常听到一些声音，不要太拘泥于语言（技术）细节了，要从大处着眼，要有大局观，架构怎么怎么重要，这些都是大实话。不过现实情况往往是，很多程序员不是太拘泥于语言（技术）细节了，而是对语言（技术）细节掌握得还远远不够。
书本知识的重要性毋庸置疑，但绝不要以为读了两本书，自己就成了牛气的架构师、设计师或者什么建模专家。
从前的软件开发埋头实践而缺乏必要的理论指导。现在越来越走向另外一个极端：设计文稿越来越图文并茂，琳琅满目，但开发出来的软件却比以前差很多。这种表面文章，意义何在？
数据库
大多数软件都要和数据库打交道，并非只有MIS类软件如此，数据库知识几乎是非掌握不可的，无非使用深度和广度有别而已。迄今为止，我编写的每一个项目软件，都要访问数据库，有一个程序甚至同时要跟两个数据库打交道（Oracle和SQL Server）。
如果你上过任何一门数据库基础理论方面的课，或认真看过任何一本数据库基础理论方面的书，或许都不必再买更多的（类似的）书。二十多年以来，关系式数据库理论之稳定，远远超过C++语言的稳定。