MicroVision 5.13 和 ARMCC 5.05 上的 C++11答案

【问题标题】：C++11 on MicroVision 5.13 and ARMCC 5.05MicroVision 5.13 和 ARMCC 5.05 上的 C++11
【发布时间】：2015-03-04 09:53:18
【问题描述】：

我有一个适用于 STM32F407 处理器的 uVision 5.13 项目，我也在使用 RTX 操作系统，并且我正在尝试使用一些 C++11 功能，例如作用域枚举，但是当我放置 --cpp11 编译器选项时我从 cmsis 标头之一收到此错误：

compiling RTX_Conf_CM.c...
C:\Keil\ARM\PACK\ARM\CMSIS\4.2.0\CMSIS_RTX\INC\RTX_CM_lib.h(250): error: #390: function "main" may not be called or have its address taken osThreadDef_t os_thread_def_main = {(os_pthread)main, osPriorityNormal, 1, 4*OS_MAINSTKSIZE };
RTE\CMSIS\RTX_Conf_CM.c: 0 warnings, 1 error**

这是在编译相同的源代码，在没有 --cpp11 选项的情况下可以正常工作。

然后，如果我像这样添加受支持的 C++11 功能之一：

namespace TestNamespace
{

enum class Test : std::int16_t
{
  TestValue1 = 0
};

class TestClass
{

//All the class code here

};
}

然后，每次编译包含作用域枚举的头文件时，我都会开始从 Windows 接收消息“ARM C/C++ 编译器已停止工作”。这是 Windows 中的问题签名：

Problem Event Name: APPCRASH
Application Name: ArmCC.exe
Application Version: 5.5.0.106
Application Timestamp: 547650a9
Fault Module Name: ArmCC.exe
Fault Module Version: 5.5.0.106
Fault Module Timestamp: 547650a9
Exception Code: c0000005
Exception Offset: 003f566a
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

那么，我做错了什么或者那些是 ARMCC 错误？？

我的uVision版本是5.13，编译器版本是5.05 update 1 build 106。

【问题讨论】：

标签： c++ c++11 arm keil armcc

【解决方案1】：

第一个错误是绝对正确的，即使在 C++98 中这种做法也被禁止了。

无论您的代码如何，编译器崩溃都是 ARMCC 错误。即使您尝试编译 .mp3 文件，它也不应该崩溃。

【讨论】：

感谢您的回答，我已经发布了我从 ARM 收到的关于这两个问题的回答。我希望他们能在不久的将来解决这两个问题。

【解决方案2】：

为了后代，我向 ARM 提交了一个错误，他们告诉我：

内部错误是由与具有范围枚举有关的已知问题引起的，请浏览选择的信息（--omf_browse 命令行选项，Output->Browse Information 中的 gui)。

CMSIS-RTOS 内核不使用 --cpp11 编译的事实我将在技术上提出团队失误。

我想他们会在未来的版本中解决这两个问题。

【讨论】：

【解决方案3】：

你在 c/c++ 页面的“Misc Controls”中是否说过--cpp11？

您对所有文件说 cpp11 模式。到 .cpp 和到 .c

用 --cpp11 试试 test.c：

//an C file: test.c
#ifdef __cplusplus
#error c++ mode
#endif

或查看 *.obj 以了解损坏的符号

【讨论】：

【解决方案4】：

所以，两年半过去了，他们仍然没有修复它？

看来有两件事要做。

我将我的程序重构为：

int main(void){
    main_rtx();
}

然后在 RTX_CM_lib.h 中，我将第 414 行更改为

extern int main_rtx(void);

修正了“错误地址”

然后在第 72-76 行有四个 extern "C"declarations：

extern "C" OS_TID rt_tsl_self(void);
extern "C" void rt_mut_init(OS_ID mutex);
extern "C" OS_RESULT rt_mut_relase(OS_ID mutex);
extern "C" OS_RESULT rt_mut_wait(OS_ID mutex, int16_t timeout);

以及第 215 行

extern "C" void osTimerThread(void const *argument);

可能还有更多，但如果您遇到有关未解析符号的链接器错误，则可能是由于 extern 声明中缺少“C”。

这是 hack 修复，只是为了让我在 STM32F746 上测试 C11，但有例外。我宁愿放一个

#ifdef __cplusplus
   extern "C" {
#endif

    //external declarations

#ifdef __cplusplus
    } //extern "C"
#endif

围绕所有外部声明。

注意。 int main_rtx(void) 必须使用 cpp 链接声明，即 not 在 extern "C" 组内。

【讨论】：