在使用C++编程时，有时会遇到LNK2001的错误消息主要为：
　　unresolved
&symbol&（不确定的外部&符号&）。
　　如果连接程序不能在所有的库和目标文件内找到所引用的函数、变量或
标签，将产生此错误消息。一般来说，发生错误的原因有两个：一是所引用
的函数、变量不存在、拼写不正确或者使用错误；其次可能使用了不同版本
的连接库。
　　以下是可能产生LNK2001错误的原因：
　　一．由于编码错误导致的LNK2001。
　　1．不相匹配的程序代码或模块定义(.DEF)文件能导致LNK2001。例如,
如果在C＋＋
源文件内声明了一变量&var1&，却试图在另一文件内以变量
&VAR1&访问该变量,将发生该错误。
　　2．如果使用的内联函数是在.CPP文件内定义的，而不是在头文件内定
义将导致LNK2001错误。
　　3．调用函数时如果所用的参数类型同函数声明时的类型不符将会产生
　　4．试图从基类的构造函数或析构函数中调用虚拟函数时将会导致LNK2001。
　　5．要注意函数和变量的可公用性，只有全局变量、函数是可公用的。
　　静态函数和静态变量具有相同的使用范围限制。当试图从文件外部访问
任何没有在该文件内声明的静态变量时将导致编译错误或LNK2001。
　　函数内声明的变量(局部变量)
只能在该函数的范围内使用。
的全局常量只有静态连接性能。这不同于C，如果试图在C＋＋的
多个文件内使用全局变量也会产生LNK2001错误。一种解决的方法是需要时在
头文件中加入该常量的初始化代码，并在.CPP文件中包含该头文件；另一种
方法是使用时给该变量赋以常数。
　　二．由于编译和链接的设置而造成的LNK2001
　　1．如果编译时使用的是/NOD(/NODEFAULTLIB)选项，程序所需要的运行
库和MFC库在连接时由编译器写入目标文件模块，
但除非在文件中明确包含
这些库名，否则这些库不会被链接进工程文件。在这种情况下使用/NOD将导
致错误LNK2001。
　　2．如果没有为wWinMainCRTStartup设定程序入口，在使用Unicode和MFC
时将得到&unresolved
_WinMain@16&的LNK2001错误信息。
　　3．使用/MD选项编译时,既然所有的运行库都被保留在动态链接库之内，
源文件中对&func&的引用，在目标文件里即对&__imp__func&
如果试图使用静态库LIBC.LIB或LIBCMT.LIB进行连接，将在__imp__func上发
生LNK2001；如果不使用/MD选项编译，在使用MSVCxx.LIB连接时也会发生LNK2001。
　　4．使用/ML选项编译时，如用LIBCMT.LIB链接会在_errno上发生LNK2001。
　　5．当编译调试版的应用程序时，如果采用发行版模态库进行连接也会产
生LNK2001；同样，使用调试版模态库连接发行版应用程序时也会产生相同的
　　6．不同版本的库和编译器的混合使用也能产生问题，因为新版的库里可
能包含早先的版本没有的符号和说明。
　　7．在不同的模块使用内联和非内联的编译选项能够导致LNK2001。如果
创建C＋＋库时打开了函数内联（/Ob1或/Ob2)，但是在描述该函数的相应头
文件里却关闭了函数内联（没有inline关键字），这时将得到该错误信息。
为避免该问题的发生，应该在相应的头文件中用inline关键字标志内联函数。
　　8．不正确的/SUBSYSTEM或/ENTRY设置也能导致LNK2001。
　　其实，产生LNK2001的原因还有很多，以上的原因只是一部分而已，对初
学者来说这些就够理解一阵子了。但是，分析错误原因的目的是为了避免错
误的发生。LNK2001错误虽然比较困难，但是只要注意到了上述问题，还是能
够避免和予以解决的。
阅读(...) 评论()为什么 35 岁的 C++ 仍在“真实”开发中占主导
早在1979年，Bjarne Stroustrup设计了C++编程语言，并且C++很快成为了无处不在的通用系统编程语言。现在尽管有Java、Javascript、Python、Go，甚至是苹果的Swift和它竞争，但C++依然处于主导编程世界的地位。
今天在Morgan Stanley的科技访谈会上，InfoWorld的编辑和Stroustrup畅聊了很多关于C++的问题，还谈及了其他的编程语言，包括Google的Go语言和苹果的Swift语言。以下是我们的访谈记录。
InfoWorld：
您是怎么看C++的未来的？现在有很多流行的脚本语言，像Python和Javascript，当然还有很受欢迎的Java，甚至是Google的Go语言，C++如何从这么多编程语言中存活下来，并且发展壮大？
Stroustrup：
这是个很棒的问题。在这 20年时间里，人们一直在预测C++将会灭亡，但是很高兴的是它一直在成长和壮大。如果你进入到嵌入式领域，如果你想做一些复杂的图像处理，如果你需要实 现一些微电子应用，如果你要开发一些金融管理系统，那么C++是你的首选。也许你很少能看到C++的身影，但是在那些应用的底层，C++依然是撑起整个应 用的顶梁柱。比如Google、Amazon、搜索引擎等那些需要高性能的地方，C++就成了不可或缺的重要角色了。
InfoWorld：
Google的Go语言越来越被受到关注，您对Go语言的前景怎么看？
Stroustrup：
当然这些编程语言可以非常优雅地实现一些功能，但是这些编程语言关注的是如何让写代码变得便捷和优雅，却损失不少性能。当然，这些编程语言所做的贡献我们也是有目共睹的。
InfoWorld：
一些脚本语言的宗旨是解放程序员的双手，那么C++是否也会逐渐倾向于这个目标？
Stroustrup：
Oh，当然了。C++主 要是为一些相当底层核心的应用设计的，它也经常会和其他的脚本语言结合使用。一开始的时候，我是用C++来实现任何的应用，然后我就在Unix上使用 shell作为脚本语言设计一些底层应用。C++涵盖了以下优秀的特性：高性能、易伸缩、占用空间小、占用资源少等等。
InfoWorld：
苹果在今年6月份发布了Swift语言，您是否认为由于苹果公司的支持，Swift将越来越受到开发者的关注？
Stroustrup：
我认为是的，之前他们关注Objective-C，这回Swift真正进入了这些开发者的领域了。
InfoWorld：
C++面临两大挑战：一方面要满足开发者实现高性能、可扩展、搞可靠性的应用程序，另一方面又需要能够帮助开发者实现可维护的代码。关于这两个问题您怎么看？
Stroustrup：
我正要解释这两个问题，第一个问题是要尽可能的抽象和更高效地利用硬件资源，而后者则需要能尽可能简化代码的编写过程，从C++ 11到C++ 14，已经具备这样的兼顾能力了。
今年我们会发布一个新的C++版本，它参考了C++ 14的标准。当你在研发大型的产品时，也许C++ 11在某些方面已经无法满足你的需求，但当出现C++ 14时，情况就会完全改变了，C++总是在不停地进步着。
InfoWorld：
关于程序的安全性问题，您怎么看？程序员是否需要关注所有的安全问题？C++是否比其他编程语言安全呢？
Stroustrup：
我非常热衷于解决硬件的安全问题。在编程语言方面，如果你想编写优秀的程序，那么你的代码一定要确保类型安全。你可以在C++中实现这一要求。不要总是围绕着一些低效的功能转，总的来说，安全问题是系统问题。
InfoWorld：
您是否还要探讨关于C++或者软件开发的其他任何问题？
Stroustrup：
我们的目标是让软件开发更加专业化。我们的社会中很多事情都是不能被打破的，其中大部分都需要依赖软件。作为开发者，我们需要整体考虑到我们的系统，编程语言和开发工具只是其中的一部分，我们需要探究如何培养开发者，以及如何将重点放在程序的可靠性上。
原文出处： &&&译文出处：
转载请注明：文章转载自 开源中国社区
本文标题：为什么 35 岁的 C++ 仍在“真实”开发中占主导
本文地址：
做金融管理系统，JAVA应该是首选吧
引用来自“中山野鬼”的评论不可能，确实有不少典型开发场景，用c会累死，用java？？？大家在谈底层开发的工程问题，不是做玩具。哈。一个典型就是界面方面的设计。引用来自“pugwoo”的评论有两个趋势，第一个是世界平均编程水平在不断提高，以前需要C++才能编写的底层，逐渐用C就能handle，c++为什么在90年代如沐春风，因为那时候计算机刚普及，平均编程水平不高。你可以看到更多的程序用C写就可以了。第二个趋势，硬件设备越来越快、越来越便宜，在底层开发用C就搞定，而上层的开发性能已经满足。用java有何不可？相信C和java的结合会构造起未来云平台的基石，5年内会在汇总小企业会大规模普及，让我们拭目以待吧。图形化UI也用java？不靠谱吧。
听说和真正参与的区别是很大的。不是绝对的
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。引用来自“哆啦比猫”的评论编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的 引用来自“jiuyueshouyi”的评论C++不是面向对象的理由是？ 引用来自“khedive”的评论C with object 是 C++ 的前身，但不是C++，尤其是在95年后，Bjarne Stroustrup曾说：“如今再去讨论object是很过时的行为”，他认为object只是C++中一个小特征，算不上重要的特性哈所以说c++不会死。不然一堆无聊的学者专家，怎么把最新的思想绑架到工程上去。。总要拿个语言来折腾吧。
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。引用来自“哆啦比猫”的评论编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的 引用来自“jiuyueshouyi”的评论C++不是面向对象的理由是？ 引用来自“khedive”的评论C with object 是 C++ 的前身，但不是C++，尤其是在95年后，Bjarne Stroustrup曾说：“如今再去讨论object是很过时的行为”，他认为object只是C++中一个小特征，算不上重要的特性我倒是觉得不论它是什么类型的语言，它支持面向对象并鼓励我们去这么做。事实上我们确实能利用它的继承和多态把事情干得更轻松和漂亮。仅仅是产生object确实是不算什么改进，但是支持多态却是用户层面的质的变化
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。引用来自“哆啦比猫”的评论编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的 引用来自“jiuyueshouyi”的评论C++不是面向对象的理由是？ C with object 是 C++ 的前身，但不是C++，尤其是在95年后，Bjarne Stroustrup曾说：“如今再去讨论object是很过时的行为”，他认为object只是C++中一个小特征，算不上重要的特性
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。引用来自“哆啦比猫”的评论编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的 引用来自“jiuyueshouyi”的评论C++不是面向对象的理由是？ c++是多范式的
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。引用来自“哆啦比猫”的评论编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的 C++不是面向对象的理由是？
山顶位，望远镜、收音器已准备，坐等狂喷，我爱c++
引用来自“哆啦比猫”的评论常数的区别比如 c 的 qsort 和 c++ 的 sort/stable_sort(不知道哪个对应于 qsort)，qsort 要传入一个比较函数，这样在比较时会产生函数调用开销，而 sort 由于是模板，编译时就知道比较函数的内容，通常会被内联 引用来自“中山野鬼”的评论没见过比c执行效率上快的c++代码。见过近似的，不过基本也是c的风格。这不是因为我搞c自我贴金。c的设计思想是面向设备，机器特性的。c＋＋是面向对象的。c一样可以内联。再不行，#define ,哈。谈效率，这不是c++优势的地方。编译时编译器看不到函数体如何内联？(编译 qsort 函数时，是不知道比较函数的内容的)而 c++ 由于各种原因(最主要是因为模板吧)，编译器能看到传入 sort 的比较函数，所以会发生内联也就是说，同样的抽象程度上， c++代码发生内联的几率大于 c 的另外 c++不是面向对象的
引用来自“中山野鬼”的评论不可能，确实有不少典型开发场景，用c会累死，用java？？？大家在谈底层开发的工程问题，不是做玩具。哈。一个典型就是界面方面的设计。引用来自“pugwoo”的评论有两个趋势，第一个是世界平均编程水平在不断提高，以前需要C++才能编写的底层，逐渐用C就能handle，c++为什么在90年代如沐春风，因为那时候计算机刚普及，平均编程水平不高。你可以看到更多的程序用C写就可以了。第二个趋势，硬件设备越来越快、越来越便宜，在底层开发用C就搞定，而上层的开发性能已经满足。用java有何不可？相信C和java的结合会构造起未来云平台的基石，5年内会在汇总小企业会大规模普及，让我们拭目以待吧。引用来自“中山野鬼”的评论哈，c++为什么在90年代发展起来的原因，我个人的理解和你到不太一样。我的理解主要是两方面，1、面向对象语音确实能更好的解决某些业务背景的开发任务2、桌面设计的需求逐步起来。。如果说java做云平台，它主要做哪层呢？终端？竞争者众多，业务层？也竞争者众多。哈。现在java的优势我认为就是成熟的东西多，开发速度快，其他都是扯淡，特别是跨平台。。。哈。引用来自“pugwoo”的评论你从业务角度解释c++流行我同意哈，只是下一个业务浪潮来的时候，就不是c++，为什么？分布式系统用c++来做？java在云平台做server端，java要的是规范，c++太乱引用来自“中山野鬼”的评论java做server我没看出有什么优势哦。server端的，系统逻辑相对静态（相对那些靠敏捷和头脑风暴的互联网设计，哈），这块在服务器端折腾出来个虚拟机层，恐怕不好发挥服务器的资源利用吧。云平台，对客户看是云里雾里，对服务器端看，还是个计算设备。哈。云平台里对机器和应用的管理分量很重，这就需要规范。发挥服务器资源利用不应该过度考虑，硬件已经很快了，应该把注意力放到软件的架构和运维上。
引用来自“中山野鬼”的评论不可能，确实有不少典型开发场景，用c会累死，用java？？？大家在谈底层开发的工程问题，不是做玩具。哈。一个典型就是界面方面的设计。引用来自“pugwoo”的评论有两个趋势，第一个是世界平均编程水平在不断提高，以前需要C++才能编写的底层，逐渐用C就能handle，c++为什么在90年代如沐春风，因为那时候计算机刚普及，平均编程水平不高。你可以看到更多的程序用C写就可以了。第二个趋势，硬件设备越来越快、越来越便宜，在底层开发用C就搞定，而上层的开发性能已经满足。用java有何不可？相信C和java的结合会构造起未来云平台的基石，5年内会在汇总小企业会大规模普及，让我们拭目以待吧。引用来自“中山野鬼”的评论哈，c++为什么在90年代发展起来的原因，我个人的理解和你到不太一样。我的理解主要是两方面，1、面向对象语音确实能更好的解决某些业务背景的开发任务2、桌面设计的需求逐步起来。。如果说java做云平台，它主要做哪层呢？终端？竞争者众多，业务层？也竞争者众多。哈。现在java的优势我认为就是成熟的东西多，开发速度快，其他都是扯淡，特别是跨平台。。。哈。引用来自“pugwoo”的评论你从业务角度解释c++流行我同意哈，只是下一个业务浪潮来的时候，就不是c++，为什么？分布式系统用c++来做？java在云平台做server端，java要的是规范，c++太乱java做server我没看出有什么优势哦。server端的，系统逻辑相对静态（相对那些靠敏捷和头脑风暴的互联网设计，哈），这块在服务器端折腾出来个虚拟机层，恐怕不好发挥服务器的资源利用吧。云平台，对客户看是云里雾里，对服务器端看，还是个计算设备。哈。
引用来自“中山野鬼”的评论不可能，确实有不少典型开发场景，用c会累死，用java？？？大家在谈底层开发的工程问题，不是做玩具。哈。一个典型就是界面方面的设计。引用来自“pugwoo”的评论有两个趋势，第一个是世界平均编程水平在不断提高，以前需要C++才能编写的底层，逐渐用C就能handle，c++为什么在90年代如沐春风，因为那时候计算机刚普及，平均编程水平不高。你可以看到更多的程序用C写就可以了。第二个趋势，硬件设备越来越快、越来越便宜，在底层开发用C就搞定，而上层的开发性能已经满足。用java有何不可？相信C和java的结合会构造起未来云平台的基石，5年内会在汇总小企业会大规模普及，让我们拭目以待吧。引用来自“中山野鬼”的评论哈，c++为什么在90年代发展起来的原因，我个人的理解和你到不太一样。我的理解主要是两方面，1、面向对象语音确实能更好的解决某些业务背景的开发任务2、桌面设计的需求逐步起来。。如果说java做云平台，它主要做哪层呢？终端？竞争者众多，业务层？也竞争者众多。哈。现在java的优势我认为就是成熟的东西多，开发速度快，其他都是扯淡，特别是跨平台。。。哈。你从业务角度解释c++流行我同意哈，只是下一个业务浪潮来的时候，就不是c++，为什么？分布式系统用c++来做？java在云平台做server端，java要的是规范，c++太乱
引用来自“中山野鬼”的评论不可能，确实有不少典型开发场景，用c会累死，用java？？？大家在谈底层开发的工程问题，不是做玩具。哈。一个典型就是界面方面的设计。引用来自“pugwoo”的评论有两个趋势，第一个是世界平均编程水平在不断提高，以前需要C++才能编写的底层，逐渐用C就能handle，c++为什么在90年代如沐春风，因为那时候计算机刚普及，平均编程水平不高。你可以看到更多的程序用C写就可以了。第二个趋势，硬件设备越来越快、越来越便宜，在底层开发用C就搞定，而上层的开发性能已经满足。用java有何不可？相信C和java的结合会构造起未来云平台的基石，5年内会在汇总小企业会大规模普及，让我们拭目以待吧。哈，c++为什么在90年代发展起来的原因，我个人的理解和你到不太一样。我的理解主要是两方面，1、面向对象语音确实能更好的解决某些业务背景的开发任务2、桌面设计的需求逐步起来。。如果说java做云平台，它主要做哪层呢？终端？竞争者众多，业务层？也竞争者众多。哈。现在java的优势我认为就是成熟的东西多，开发速度快，其他都是扯淡，特别是跨平台。。。哈。