c++程序编译常见错误_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
c++程序编译常见错误
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢C++常见编译/链接错误及其解决办法
C++常见编译/链接错误及其解决办法
1. 解决error
LNK2005: ___crtExitProcess 已经在 LIBCMTD.lib(crt0dat.obj)
有的時候, 在 Debug 模式下編譯沒問題, 換到 Release 模式就發生一堆問題.
典型的例子, 就是因為 c++ runtime library 設定不同, 所造成的重複定義連結錯誤.
而另一個常見的例子是 專案與 library 使用不同的字元集合設定
(如: 一個用 Unicode Character Set, 另一個用 Multi-Byte Character
這個錯誤發生原因,
1. 你 link 的 lib 使用 C++ Multi-threaded DLL (/MD)
2. 而你的 source 使用的 C++ runtime library 是 Multi-threaded
導致重複定義
兩個使用相同的 C++ runtime library.例如都使用
static 的 Multi-threaded (/MT).
2. 错误 1error
LNK2005: "private: __thiscall type_info::type_info(class type_info
const &)" ()
已经在 LIBCMT.lib(typinfo.obj) 中定义 MSVCRTD.lib
项目 -& 属性 -& c/C++ -&
代码生成 -& 运行时库 设置为: 多线程调试 DLL (/MDd)
被引用的库和调用的程序编译选项不同，需要改成一致后编译
#ifndef的区别
为了避免同一个文件被include多次
1&& #ifndef方式
2&& #pragma once方式
在能够支持这两种方式的编译器上，二者并没有太大的区别，但是两者仍然还是有一些细微的区别。
#ifndef __SOMEFILE_H__
#define __SOMEFILE_H__
... ... // 一些声明语句
#pragma once
... ... // 一些声明语句
#ifndef的方式依赖于宏名字不能冲突，这不光可以保证同一个文件不会被包含多次，也能保证内容完全相同的两个文件不会被不小心同时包含。当然，缺点就是如果不同头文件的宏名不小心“撞车”，可能就会导致头文件明明存在，编译器却硬说找不到声明的状况
#pragma once则由编译器提供保证：同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件，而不是指内容相同的两个文件。带来的好处是，你不必再费劲想个宏名了，当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝，本方法不能保证他们不被重复包含。当然，相比宏名碰撞引发的“找不到声明”的问题，重复包含更容易被发现并修正。
方式一由语言支持所以移植性好，方式二 可以避免名字冲突
LNK2019: 无法解析的外部符号 __imp__PathCombineW
PathCombine是Shell api 需要引入库#pragma
comment( lib, "shlwapi.lib")
C2662: "MyClass::GetName()”: 不能将“this”指针从“const MyClass”转换为“MyClass
bool MyClass::operator==(const MyClass* n1) const
GetName() == n1-&GetName();}
原因是不能在const函数中调用对象的非const方法，MyClass中的GetName()必须是const的。
6.template
模板声明和定义必须在同一个文件中，而且只有实例话模板类型时才编译模板实例
C2275: “MyClass”: 将此类型用作表达式非法 MyClass.Instance();
原因：Instance是静态方法，用.引用会出错。应该是MyClass::Instance()
LNK2019: 无法解析的外部符号 "public: __thiscall MyClass(void)
原因：只声明了构造函数，MyClass(); ，但未定义。 可以定义空函数，或者直接注释掉，使用默认构造函数。
C2504: “testing”: 未定义基类
class PackToolTest : testing.Test {}
原因：Test是testing命名空间下的一个类，需要用域操作符，testing::Test
还有一个问题，缺少基类继承权限（public、protected、private）
C2864: “MyClass::_nullpack”:
只有静态常量整型数据成员才可以在类中初始化&&
class MyClass {string
_nullpack = "test";}
原因：c++ 中，成员变量不能在声明时初始化，而是在构造函数初始化列表中先初始化
LNK2019: 无法解析的外部符号int
原因：由于创建的是Win32 Project，和Win32 console Project的链接库不同
方法1：在程序最开始的地方加上以下语句
#pragma comment(linker, "/subsystem:console ")
方法2：project & & setting
& & 在link 的project options
中将/subsystem:windows（console）删了
12.类似“已经在
msvcprtd.lib(MSVCP80D.dll) 中定义”问题
vs2005 Debug /Release需要分别配制
分析一下错误来源，会发现：
错误来源主要是重复定义的问题，而且重复定义的基本上都是VC Runtime和Standard C++
Library中的函数
LIBCMT和LIBCPMT为Release下的Lib，本来不应该出现在Debug版本的链接的Lib中
重复定义的问题主要出现在：LIBCMT, LIBCPMT, MSVCPRTD, MSVCRTD
来看看出问题的LIB是那些：
LIBCMT：C Runtime库的多线程静态链接的Release版本
LIBCPMT：C++ Standard Library的多线程静态链接的Release版本
MSVCPRTD：C++ Standard Library的多线程DLL的Debug版本
MSVCRTD：C Runtime Library的多线程DLL的Debug版本
前我们的配置是多线程DLL的Debug版，因此3和4是应该出现在link的列表中的，不属于多余。而后两者则是只是当多线程静态链接Release版
中才会出现。这提示我在项目中加入的ANTLR.LIB可能是造成这个问题的根源，因为静态库的编译选项很容易和主程序发生冲突，并且根据实际信息我们可
以看出ANTLR.LIB应该是用多线程静态链接的Release版本来编译的。
解决方法：
1、首先查看编译项目依赖的其他项目的运行时库是否一致
2、如果不一致，改为同样的运行时库，如在下编译的是：“多线程调试 DLL
(/MDd)”,现在需要把所有的依赖项目的运行时库都改为一致的库，就ＯＫ了。
C2143: 语法错误 : 缺少“;”(在“*”的前面)
原因：产生错误处，某类型未include，可能头文件名拼写错误、头文件名已更改
C2572: “MyClass::Invoke”: 重定义默认参数 : 参数 2
string MyClass::Invoke(const CParam& paraObj,
INVOKETYPE type = ASYN)
原因：默认参数，只需在声明时指定。方法定义的时候无需指定默认参数。
string MyClass::Invoke(const CParam& paraObj,
INVOKETYPE type )
C2558 没有可用的复制构造函数或复制构造函数声明为“explicit”
试图复制其复制构造函数为 private 的类。在大多数情况下，不应复制具有 private 复制构造函数的类。通用编程技术声明
private 复制构造函数以防止直接使用类。该类本身可能无用，或需要另一个类才能正常工作。
尝试复制其复制构造函数为 explicit 的类。用 explicit
声明复制构造函数会阻止将类的对象传递到函数或从函数返回类的对象。
原因： 拷贝构造函数、赋值函数参数必须用const修饰
16.不能创建抽象类对象
原因： 1. 存在虚函数未实现； 2. 由于疏忽重载虚函数格式错误(此问题需要仔细检查才能发现)； 3.
虚函数名称与系统中已有的虚函数重名，导致重载失败（这点很纳闷）。
17.没有找到MSCRV80D.dll
工程属性： 配置类型 由 exe 改成 lib 后生成， 然后再改回来，运行时会出现
“没有找到MSCRV80D.dll” 的异常
解决方法：
工程属性：MFC的使用 由 “使用标准Windows库” 改成 “在静态库中使用MFC“ 生成
，然后再改回来，生成、运行
: fatal error CVT1100: 重复的资源。type:MANIFEST, name:1,
language:0x0409
另一个则提示为：
LINK : fatal error LNK1123: 转换到 COFF 期间失败: 文件无效或损坏
已经到了链接期，应该说，问题就不像编译通不过那么别扭了，而查阅MSDN关于这两个问题的说明，终于找到了解决的方法，现简单的陈述如下：
首先，出现这两个问题的原因都是一个，即文件中的现有资源文件和新资源字符串表 ID
冲突。微软也给出了解决这个问题的方法，但是，在现有的情况下，这个方法是靠不住的，因为，不可能不使用wx.rc资源。所以，一个变通的解决方法就是：
工程属性-&配置属性-&
清单工具-&输入和输出-&嵌入清单，选择[否]，即可。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。求助，C++编译报莫名其妙的语法错误。
[问题点数：40分，结帖人rigous]
求助，C++编译报莫名其妙的语法错误。
[问题点数：40分，结帖人rigous]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2013年1月 C/C++大版内专家分月排行榜第二
2014年 总版技术专家分年内排行榜第二
2013年 总版技术专家分年内排行榜第三
2013年3月 C/C++大版内专家分月排行榜第三
匿名用户不能发表回复！|1630人阅读
一、详解编译、链接
&&&&有些人写C/C++(以下假定为C++)程序，对unresolved external link或者duplicated external simbol的错误信息不知所措（因为这样的错误信息不能定位到某一行）。或者对语言的一些部分不知道为什么要（或者不要）这样那样设计。了解本文之后，或许会有一些答案。
&&&&首先看看我们是如何写一个程序的。如果你在使用某种IDE（Visual Studio，Elicpse，Dev C++等），你可能不会发现程序是如何组织起来的（很多人因此而反对初学者使用IDE）。因为使用IDE，你所做的事情，就是在一个项目里新建一系列的.cpp和.h文件，编写好之后在菜单里点击“编译”，就万事大吉了。但其实以前，程序员写程序不是这样的。他们首先要打开一个编辑器，像编写文本文件一样的写好代码，然后在命令行下敲
cc 1.cpp -o 1.o
cc 2.cpp -o 2.o
cc 3.cpp -o 3.o
&&&&这里cc代表某个C/C++编译器，后面紧跟着要编译的cpp文件，并且以-o指定要输出的文件（请原谅我没有使用任何一个流行编译器作为例子）。这样当前目录下就会出现：
1.o 2.o 3.o文件
最后，程序员还要键入
link 1.o 2.o 3.o -o a.out
&&&&来生成最终的可执行文件a.out。现在的IDE，其实也同样遵照着这个步骤，只不过把一切都自动化了。
&&&&让我们来分析上面的过程，看看能发现什么。
&&&&首先，对源代码进行编译，是对各个cpp文件单独进行的。对于每一次编译，如果排除在cpp文件里include别的cpp文件的情况（这是C++代码编写中极其错误的写法），那么编译器仅仅知道当前要编译的那一个cpp文件，对其他的cpp文件的存在完全不知情。
&&&&其次，每个cpp文件编译后，产生的.o文件，要被一个链接器(link)所读入，才能最终生成可执行文件。
&&&&好了，有了这些感性认识之后，让我们来看看C/C++程序是如何组织的。
首先要知道一些概念：
&&&&编译：：编译器对源代码进行编译，是将以文本形式存在的源代码翻译为机器语言形式的目标文件的过程。
&&&&编译单元：对于C++来说，每一个cpp文件就是一个编译单元。从之前的编译过程的演示可以看出，各个编译单元之间是互相不可知的。
&&&&目标文件：由编译所生成的文件，以机器码的形式包含了编译单元里所有的代码和数据，以及一些其他的信息。
&&&&下面我们具体看看编译的过程。我们跳过语法分析等，直接来到目标文件的生成。假设我们有一个1.cpp文件:
int n = 1;
&&&&它编译出来的目标文件1.o就会有一个区域（假定名称为2进制段），包含了以上数据／函数，其中有n, f，以文件偏移量的形式给出很可能就是：
&&&&注意：这仅仅是猜测，不代表目标文件的真实布局。目标文件的各个数据不一定连续，也不一定按照这个顺序，当然也不一定从0x000开始。
&&&& 现在我们看看从0x004开始f函数的内容（在x86平台下的猜测）：
inc &&&& DWORD PTR [0x000]
0x00? &&&& ret
&&&&注意n++已经被翻译为：inc DWORD PTR [0x000]，也就是把本单元0x000位置上的一个DWORD(4字节)加1。
&&&&下面如果有另一个2.cpp，如下：
extern int
那么它的目标文件2.o的2进制段就应该是：
0x000 &&&&
&&&& 为什么这里没有n的空间（也就是n的定义）？因为n被声明为extern，表明n的定义在别的编译单元里。别忘了编译的时候是不可能知道别的编译单元的情况的，故编译器不知道n究竟在何处，所以这个时候g的二进制代码里没有办法填写inc DWORD PTR [???]中的？？？部分。怎么办呢？这个工作就只能交给后来的链接器去处理。为了让链接器知道哪些地方的地址是没有填好的，所以目标文件还要有一个“未解决符号表”，也就是unresolved symbol table. 同样,提供n的定义的目标文件(也就是1.o)也要提供一个“导出符号表”，export symbol table, 来告诉链接器自己可以提供哪些地址。
&&&& 让我们理一下思路：现在我们知道，每一个目标文件，除了拥有自己的数据和二进制代码之外，还要至少提供2个表：未解决符号表和导出符号表，分别告诉链接器自己需要什么和能够提供什么。下面的问题是，如何在2个表之间建立对应关系。这里就有一个新的概念：符号。在C/C++中，每一个变量和函数都有自己的符号。例如变量n的符号就是“n”。函数的符号要更加复杂，它需要结合函数名及其参数和调用惯例等，得到一个唯一的字符串。f的符号可能就是”_f”（根据不同编译器可以有变化）。
&&&& 所以，1.o的导出符号表就是：
而未解决符号表为空
2.o的导出符号表为
未解决符号表为
&&&& 这里0x001为从0x000开始的inc DWORD PTR [???]的二进制编码中存储???的起始地址(这里假设inc的机器码的第2－5字节为要+1的绝对地址，需要知道确切情况可查手册)。这个表告诉链接器，在本编译单元0x001的位置上有一个地址，该地址值不明，但是具有符号n。
&&&& 链接的时候，链接器在2.o里发现了未解决符号n，那么在查找所有编译单元的时候，在1.o中发现了导出符号n，那么链接器就会将n的地址0x000填写到2.o的0x001的位置上。
&&&& “打住”，可能你就会跳出来指责我了。如果这样做得话，岂不是g的内容就会变成inc DWORD PTR [0x000]，按照之前的理解，这是将本单元的0x000地址的4字节加1，而不是将1.o的对应位置加1。是的，因为每个编译单元的地址都是从0开始的，所以最终拼接起来的时候地址会重复。所以链接器会在拼接的时候对各个单元的地址进行调整。这个例子中，假设2.o的0x地址被定位在可执行文件的0x上，而1.o的0x地址被定位在可执行文件的0x上，那么实际上对链接器来说，1.o 的导出符号表其实是：
0x000 + 0x2000
&&&& &&&& 0x004 + 0x2000
而未解决符号表为空
2.o的导出符号表为
0x000 + 0x1000
未解决符号表为
0x001 + 0x1000
&&&& 所以最终g的代码会变为inc DWORD PTR [0x000 + 0x2000]。
&&&& 最后还有一个漏洞，既然最后n的地址变为0x2000了，那么以前f的代码inc DWORD PTR [0x000]就是错误的了。所以目标文件为此还要提供一个表，叫做地址重定向表即address redirect table。
对于1.o来说，它的重定向表为：
&&&& 这个表不需要符号，当链接器处理这个表的时候，发现地址为0x005的位置上有一个地址需要重定向，那么直接在以0x005开始的4个字节上加上0x2000就可以了。
&&&& 让我们总结一下：编译器把一个cpp编译为目标文件的时候，除了要在目标文件里写入cpp里包含的数据和代码，还要至少提供3个表：未解决符号表，导出符号表和地址重定向表。
&&&& 未解决符号表提供了所有在该编译单元里引用但是定义并不在本编译单元里的符号及其出现的地址。
&&&& 导出符号表提供了本编译单元具有定义，并且愿意提供给其他编译单元使用的符号及其地址。
&&&& 地址重定向表提供了本编译单元所有对自身地址的引用的记录。
&&&& 链接器进行链接的时候，首先决定各个目标文件在最终可执行文件里的位置。然后访问所有目标文件的地址重定向表，对其中记录的地址进行重定向（即加上该编译单元实际在可执行文件里的起始地址）。然后遍历所有目标文件的未解决符号表，并且在所有的导出符号表里查找匹配的符号，并在未解决符号表中所记录的位置上填写实际的地址（也要加上拥有该符号定义的编译单元实际在可执行文件里的起始地址）。最后把所有的目标文件的内容写在各自的位置上，再作一些别的工作，一个可执行文件就出炉了。
&&&& 最终link 1.o 2.o …. 所生成的可执行文件大概是：
&&&& ????（别的一些信息）
inc &&&& DWORD PTR [0x]
//这里是2.o的开始，也就是g的定义
//假设inc为5个字节，这里是g的结尾
//这里是1.o的开始，也是n的定义（初始化为1）
inc &&&& DWORD PTR [0x]
//这里是f的开始
//假设inc为5个字节，这里是f的结尾
&&&& 实际链接的时候更为复杂，因为实际的目标文件里把数据／代码分为好几个区，重定向等要按区进行，但原理是一样的。
二、经典错误：
&&&& 现在我们可以来看看几个经典的链接错误了：
2.1 unresolved external link..
&&&& 这个很显然，是链接器发现一个未解决符号，但是在导出符号表里没有找到对应的項。
&&&& 解决方案么，当然就是在某个编译单元里提供这个符号的定义就行了。（注意，这个符号可以是一个变量，也可以是一个函数），也可以看看是不是有什么该链接的文件没有链接。
2.2 duplicated external simbols…
&&&& 这个则是导出符号表里出现了重复项，因此链接器无法确定应该使用哪一个。这可能是使用了重复的名称，也可能有别的原因。
三、C/C++与变量定义相关的关键字
&&&& 我们再来看看C/C++语言里针对这一些而提供的特性。
3.1 extern
&&&& 这是告诉编译器，这个符号在别的编译单元里定义，也就是要把这个符号放到未解决符号表里去。（外部链接）
3.2 static
&&&& 如果该关键字位于全局函数或者变量的声明的前面，表明该编译单元不导出这个函数／变量的符号。因此无法在别的编译单元里使用。（内部链接）。如果是static局部变量，则该变量的存储方式和全局变量一样，但是仍然不导出符号。
&&&&默认链接属性：对于函数和变量，模认外部链接，对于const变量，默认内部链接。（可以通过添加extern和static改变链接属性）
&&&&外部链接的利弊：外部链接的符号，可以在整个程序范围内使用（因为导出了符号）。但是同时要求其他的编译单元不能导出相同的符号（不然就是duplicated external simbols)
&&&&内部链接的利弊：内部链接的符号，不能在别的编译单元内使用。但是不同的编译单元可以拥有同样名称的内部链接符号。
四、常见疑问答疑
4.1 为什么头文件里一般只可以有声明不能有定义?
&&&&头文件可以被多个编译单元包含，如果头文件里有定义，那么每个包含这个头文件的编译单元就都会对同一个符号进行定义，如果该符号为外部链接，则会导致duplicated external simbols。因此如果头文件里要定义，必须保证定义的符号只能具有内部链接。
4.2 为什么常量默认为内部链接，而变量不是?
&&&&这就是为了能够在头文件里如const int n = 0这样的定义常量。由于常量是只读的，因此即使每个编译单元都拥有一份定义也没有关系。如果一个定义于头文件里的变量拥有内部链接，那么如果出现多个编译单元都定义该变量，则其中一个编译单元对该变量进行修改，不会影响其他单元的同一变量，会产生意想不到的后果。
4.3 为什么函数默认是外部链接?
&&&&虽然函数是只读的，但是和变量不同，函数在代码编写的时候非常容易变化，如果函数默认具有内部链接，则人们会倾向于把函数定义在头文件里，那么一旦函数被修改，所有包含了该头文件的编译单元都要被重新编译。另外，函数里定义的静态局部变量也将被定义在头文件里。
4.4 为什么类的静态变量不可以就地初始化?
&&&&所谓就地初始化就是类似于这样的情况：
static char msg[] = "aha";
&&&&不允许这样做得原因是，由于class的声明通常是在头文件里，如果允许这样做，其实就相当于在头文件里定义了一个非const变量。
4.5 在C++里，头文件定义一个const对象会怎么样?
&&&&一般不会怎么样，这个和C里的在头文件里定义const int一样，每一个包含了这个头文件的编译单元都会定义这个对象。但由于该对象是const的，所以没什么影响。但是：有2种情况可能破坏这个局面：
&&&&&&&&&&&&&1、如果涉及到对这个const对象取地址并且依赖于这个地址的唯一性，那么在不同的编译单元里，取到的地址可以不同。（但一般很少这么做）
&&&&&&&&&&&&2、如果这个对象具有mutable的变量，某个编译单元对其进行修改，则同样不会影响到别的编译单元。
4.6 为什么类的静态常量也不可以就地初始化？
&&&&因为这相当于在头文件里定义了const对象。作为例外，int/char等可以进行就地初始化，是因为这些变量可以直接被优化为立即数，就和宏一样。
内联函数：
&&&&C++里的内联函数由于类似于一个宏，因此不存在链接属性问题。
4.7 为什么公共使用的内联函数要定义于头文件里?
&&&&因为编译时编译单元之间互相不知道，如果内联函数被定义于.cpp文件中，编译其他使用该函数的编译单元的时候没有办法找到函数的定义，因此无法对函数进行展开。所以说如果内联函数定义于.cpp文件里，那么就只有这个cpp文件可以是用这个函数。
头文件里内联函数被拒绝会怎样?
&&&&如果定义于头文件里的内联函数被拒绝，那么编译器会自动在每个包含了该头文件的编译单元里定义这个函数并且不导出符号。
如果被拒绝的内联函数里定义了静态局部变量，这个变量会被定义于何处?
&&&&早期的编译器会在每个编译单元里定义一个，并因此产生错误的结果，较新的编译器会解决这个问题，手段未知。
4.8 为什么export关键字没人实现：
&&&&export要求编译器跨编译单元查找函数定义，使得编译器实现非常困难。
5、头文件包含解决方案
5.1 设计原则：
&&&&一、头文件中尽量少 include, 如果可以简单申明 class clsO 解决，那最好。减少没有必要的 include；
&&&&二、实现文件中也要尽量少 include, 不要 include 没有用到的头文件。
5.2 几种包含情况
1、B类中需要定义A类为其成员
&&&&B类定义时，头文件B.h前加前置声明 class A;
&&&&B中定义A类的指针,A *pA;
&&&&B的实现文件B.cpp 中#include”A.h”;
2、B和A相互为对方成员
&&&&A,B类的.h文件中均使用前置声明：即A.h文件前加class B,即B.h文件前加class A，然后实现文件中包含头文件，即A.cpp中#include”B.h”,B.cpp中#include”A.h”，A,B均使用指针对B，A引用。
代码如下：
3、C类中定义B类，B类中定义A类,类似继承的情况
&&&&如果C类中#include”B.h”,B类中#include”A.h”,则编译时会出现A类重定义，解决方法：在A.h前加#prama once，保证A类只定义一次。
5.3 一些建议：
&&&&1 、如果有共同相关依赖 ( 必须 include) 的类，比如 A,B 都依赖 D 可以放在一起，然后直接 Include “d” 类的使用者只需关心与本类暴露出的相关类型，内部用到的类型不用去管 ( 不用自已去 include d) 。这样 给出的 class ，调用者才更好用 ( 不用去看代码查找，是不是还需要包含其它头文件 ) 。
&&&&2 、如果 A 类依赖 D B 类不依赖 D ，可以把它们分开两个头文件。各自 Include 。这样可避免当 D 发生变化时， 避免不必要重编译。
&&&&3 、类中尽量采用指针或引用方式调用其它类，这样就可以只声明 class xxx 了。并且这也符合资源最优 利用，更利于使用多态。
转载请注明作者和出处：，未经允许请勿用于商业用途}