今天遇到一个编译错误，抽象化后描述为：
The source files "*\A.cpp " and "*\A.cpp " are both configured to produce the output file "*\A.obj ", The project cannot be built
其中A.cpp可以被替换为任何名称的cpp文件，*可被替换成各种路径，当然前后两个路径不相同（否则就是一个文件不会报错了）
其实该问题可以理解为工程中包含了两个同名的cpp文件，而且两个文件都被绑定到同一输出A.obj，编译器无法识别应该编译哪个文件，于是拒绝编译。
当初我没有理解到这一问题的时候一直对此一筹莫展
参考了以下几个链接：
http://topic.csdn.net/t/20060904/08/4995921.htmlhttp://topic.csdn.net/t/20010203/00/64063.html但是这两个链接中都说要去改工程文件的makefile，要不就是让从零开始重新建工程，两个都太麻烦了。我是懒人，马上就犹豫了。
再次编译，又弹出了同样的提示，还是编译不起来。但这次我注意到一个问题
“The source files "*\A.cpp " and "*\A.cpp " are both configured to produce the output file "*\A.obj ", The project cannot be built”
的意思，不就是说，有两个cpp重名，系统无法分辨该编译哪个“正确的”cpp文件么？
突然想到最开始我对项目的野蛮操作了：为了将文件分类，我关闭了工程，并把A.cpp剪切到了一个分类的文件夹里，但并未在工程中删除它。
打开工程后，我直接添加了分类文件夹中的A.cpp
这意味着虽然其中一个cpp文件是不存在的，但仅仅是工程没能加载（load）成功，该文件应该还在工程目录里面。
于是在VC的文件目录浏览器中，我看到了两个A.cpp，在source File栏里面闪闪发光……⊙﹏⊙b汗
手动delete都删掉了，然后重新把分类文件夹上的A.cpp “add to the project”
再次编译，成功。
经测试此类问题应该无需直接修改makeflie（即.dsp文件），如此一来就该问题就简化了。
这也提醒我们，在将工程文件重新分类到自定义文件夹中时，一定要先在工程中“删除”该文件（其实没有删除，只是删除工程中的索引而已，文件还在硬盘上），然后再重新加载，这样就可以有效避免上述问题。