想把VC++6.0后缀cpp文件的程序移植到stm32芯片里面去，需要注意哪些地方？

Posted 2023-05-06

比如一些头文件在VC++里面可以用，在stm32里面用不了。
还比如一些变量的定义。。。。有没有一些资料可以参考？？？

这个大概可以分几类：
1.如果你准备用STM32做嵌入式，并且想移植windows中的GUI函数，那么可以肯定的说，不可以的，除非你用WinCE。而且一般32跑的嵌入式系统是：UCos；
2.如果你只是移植一些简单的计算处理函数等，可以说，直接就可以使用，当然除了一些输入，输出外（C中：printf，scanf）；至于变量定义如：int ，double，char可以不用改变；如果是非负整数的，一般采用STM32自身定义，如：u8 ， u16 ，u32等。
3.STM32开发一般使用的是C/C++语言，由于语言的相通性，所以语言都是通用（if else等），所以是很好移植的，建议可以看看STM32的一些程序。
4，当然，如果你只是做算法，移植是很简单的，但是，如果加上IO口输出，如：算法运行后，输出电压量即：DAC的话，这些你需要操作STM32的一些相关ADC寄存器，才会使计算的结果可以形象地表达出来，建议看看《STM32中文参考手册》追问

比如一些定义 new double，stm32里面识别不了new。。。还有一些错误提示，expected an expression，这是为什么？谢谢

追答

这很正常，因为C++中new类型，肯定在C++编译器中的头文件中有定义；但是，对于STM32的编译器来说，它是没有定义的；什么意思呢？就是，你使用的new是一个C++系统中已经定义好的类型，而STM32对这个类型并不兼容，或者说，没有这个类型，所以你会出错，有两种解决方法：

查看C++系统中new类型，并根据类型，重新定义STM32中的new类型，并添加头文件，便可使用，较复杂。

重新利用double定义一个新变量，替代new doule，较简单。

追问

#include "stdafx.h"这个在stm32里面也识别不了怎么处理？
你的意思是直接double定义也可以？那为什么C++里面是new double

追答

一，注意刚才的第一条：

如果你准备用STM32做嵌入式，并且想移植windows中的GUI函数，那么可以肯定的说，不可以的，除非你用WinCE。而且一般32跑的嵌入式系统是：UCos；

文件："stdafx.h"是：Standard Application Framework Extensions（标准应用程序框架的扩展），这个文件就是GUI函数文件，如果你要移植这个文件，那么是不可能的，所谓的，移植只能是些算法之类的，不能含有GUI函数。

二，C++中使用new double是有它使用的必要，地址指针，有速度快等优点；可是，你得理解语句后面的含义，然后将它转变为：STM32所支持的方式；比如：new double 类型，你可以用double定义个变量，然后和之前的double相等，就可以了，得转换。

追问

既然stm32识别不了#include "stdafx.h，直接删掉行不行？没有这个语句没问题吧

追答

不知道，你具体需要哪些数据，没有你的程序，不好说。

追问

那你能不能帮忙看一下这个程序 ？

参考技术A 重点是你打算移到那个平台追问

arm内核，stm32芯片。.CPP文件里面其实都是一些数学算法，直接复制粘贴肯定不行。需要改哪些地方？

追答

arm 可用平台很多,keil ,linux/android ,windows ce/mobile
改法都不相同

从 VC6 迁移到 VC9 的编译问题

【中文标题】从 VC6 迁移到 VC9 的编译问题

【英文标题】：Compilation issues for Migration from VC6 to VC9

【发布时间】：2010-08-30 08:17:14

【问题描述】：

我正在将旧版 C++ 系统从 VC6 移植到 VC9。

应用程序（<APP A>) 静态链接到内部应用程序 <APP B>（内部开发，但由单独的团队开发）。 来自<APP B> 的头文件的本地副本包含在 CPP 文件中并在 <APP A>. 中编译

目前我们不打算将<APP B> 迁移到 VC9。虽然<APP A> 和<APP B> 都将使用单独的CRT，但预计不会发生冲突。

我们面临的问题是来自 (local copy in) 的包含文件没有被 VC9 编译。

致命错误 C1083：无法打开包含 文件：'iostream.h'：没有这样的文件或 目录

可能的解决方案： 如果我在 <APP A> 的本地副本中进行更改并使用 VC9 进行编译，那么我不确定它是否会在运行时引起一些问题。

有没有其他方法可以让 VC9 用<iostream.h> 而不是<iostream> 编译<APP A> 文件？

【问题讨论】：

"将使用单独的 CRT，但不会发生冲突。"你为什么不期待冲突？如果<APP B>（可能是一个库）在其头文件中引用流对象，并且当您在 A 和 B 之间调用时使用这些流对象的不同定义，那么（从表面上看）您很可能会拥有严重的问题。

APP之间存在数据交换是对的。但是这里没有这样的交换，因此，我认为没有冲突。

【参考方案1】：

抱歉，您遇到了很多问题。

首先是基础知识：<iostream.h> 是一个较旧的 Microsoft 标头，用于定义例如::cout。 <iostream> 是标准标头，并定义例如std::cout。你可以同时使用这两个，但是这个标题 应该不包含在APP.H 中。 <iostream> 没有定义您在声明中使用的类型。大概您依赖于 VC6 实现的工件，即 <iostream.h> 拉入 <istream.h> 和 <ostream.h>。您可能想改用<iosfwd>， 打算在标题中使用。

然而，更大的问题是您假设您可以将“APP A”和“APP B”链接在一起，即使它们是使用 VC6 和 VC9 编译的。这是真的当且仅当它们共享一个extern "C" API。C++ 名称修改（故意）在它们之间是不同的。既然你提到了<iostream.h> 而不是<stdio.h>，我将假设你的共同点真的是 C++。

【参考方案2】：

Michael Feathers http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 有一本关于这类项目的好书。

简短的回答是，如果您有测试，请进行所需的更改和重构，然后重新运行您的测试。对于您的示例，我将使用预处理器指令根据编译器版本选择正确的包含，然后修复任何损坏的测试。

如果没有测试，你会遇到更多麻烦，你要么写它们，要么祈祷你不要破坏任何东西

【参考方案3】：

我怀疑这个编译器错误将是唯一​​的问题。更新编译器几乎总是会引入少量问题。最好解决这些冲突并认真测试结果。我不认为某些“解决方法”会减少麻烦，因为无论如何编译器都是不同的。

在并行使用不同编译器时解决此类问题的唯一方法是条件编译，例如：

#if _MSC_VER >= 1200 
   // Code for VC 6.0 or higher goes here
#endif

请注意，_MSC_VER 的编号与 Visual Studio 版本中的编号不同。 对于 Visual Studio 2010，即 _MSC_VER 定义为 1600。