值得学习C ++吗？

C++是值得学习的——在你的例子中，尤其是Ec++嵌入的C++。虽然好处很可能不是你所期望的：C++肯定不会导致更快或更小的机器代码。如果你不知道某些语言结构的副作用：恰恰相反。C++的源代码方面：启用更多的模块化代码，减少来自不同来源的代码之间的冲突等，以收集一些第一实际的经验，ARDUINO生态系统可能是伟大的：基于+的，更多的EC+++比C++，低成本和非常有能力。

几年前我参加了一个嵌入式系统会议。我参加了一个课堂，讲师指出，C与VC++通用代码生成的汇编代码没有差别。（至少在ARM M3核心上）甚至大多数继承都是编译时间和运行时间。关于代码膨胀的语句通常是错误的，除非使用广泛的多态性（也从不使用异常）。然而，一个糟糕的C++开发人员可以通过创建/销毁开发人员不知道的临时对象来导致代码膨胀/性能问题。一个很差的C开发人员也会导致代码膨胀，所以你的里程会有所不同。一个人可以用C++编译器在C中编写，混合C/C++环境是一个美丽的地方。我最喜欢的设计模式之一是放置新的（）访问器类，用于相同的硬件外围设备。只需实例化一个具有外围设备基地址的新访问器类。n个UART的一个类，或n个SPI类的类，…不使用RAM，因为它在内存映射的外围寄存器上操作，并且共享代码。遗憾的是，Microchip在低级库中不太接受C++，很容易开始学习，但是引擎盖下的细微之处比C更复杂。

在事实上，你可以使用C中的一个结构来做完全相同的指针。

对于C++来说，学习曲线肯定是更陡峭的，但是询问它是否值得学习这个星球上使用最广泛的编程语言之一似乎很傻，即使你决定不在微控制器环境中使用它。

它是一种高级语言，但需要大量的内存。没有C快，但你会使用一个更好的CPU。

我读过关于C++至少二十年的缓慢和资源匮乏的争论，不同的是我们现在的微控制器比我们当时的台式机更强大。问题是程序员，而不是语言。

C++对象代码不会明显慢于或大于C代码执行相同的作业。许多C++特性在编译时被处理，不会导致代码膨胀或过大的减速。

说实话，你可以用C中指向一个结构的指针来做同样的事情，而且在一些公司里这样做会被指责。

在Microchip论坛中发现许多C++诽谤者并不少见，因为Microchip不接受C++。16位行没有编译器，8位也不可行。32位编译器仍然是beta版吗？然而，ARM、MPED、ARDUINO社区已经在相当长的时间内接受了C++。IDE，如免费LPCXPROSO，MCXPRESO，现在免费为STMIC，交叉工程编译器，GNUARM嵌入式工具链，所有支持C++，仅举几例。

博斯克，这是因为C++的成本对更小的更有限的CPU有很大的影响。不是因为微芯片程序员是一群仇恨者。C和VC++是一种选择，ASM和C++是不一样的。项目越大，C++的优势就越大。在小项目中没有那么多。又小又快又便宜，一点也不。ARDUNO是C++类的，它不是C++的完整实现。实际问题是，通过使用PIC32从C到C++，他会得到什么好处。

我在Arduino上的经验唯一的缺点是：当使用“错误”库加上一些“动态性”时，您很容易遇到链接器问题（链接器崩溃）。这肯定与C++的一些副作用有关，比如高动态内存分配/解除分配。这似乎是一个内在的难题（不仅仅是AVR），直到现在还不能完全理解。

我在PIC32上逐渐做了越来越多的C++（只支持C的XC32）。我在C和VC++中没有发现明显的性能差异，但这确实取决于C++的特性。换句话说，如果你突然开始使用异常（XC32使用旧的，慢的方式使用SETJMP（）和LangJMP（）），很多动态内存分配（即，你）。使用大量的STL容器），以及许多以前在C中没有使用的动态调度，那么可能非常慢。然而，C++对于不为不使用的功能付费（除了可能的例外，但是可以用编译器选项关闭）很好，因此，说C++只是天生的较慢是不公平的。动态调度似乎是C++的SupPOS经常被引用的原因。有时看看Harmony的代码库，你会发现很多地方，上面的层通过指向充满函数指针的结构的指针来访问诸如以太网PHYs、存储设备和图形控制器的驱动程序。这基本上是C中的动态调度，但没有人说C是慢的，因为你可以这样做。还要记住，动态分派需要额外的内存负载才能获得虚拟函数表的地址（或C中指针结构的地址），这对于一个需要100个周期才能从外部DRAM获取的架构来说可能是一个更大的问题，但在具有单周期SRAM的微控制器上发出问题（或者当地址不在高速缓存中时在PIC32MZ上发出几个周期）。我会说，它似乎确实增加了少量的Flash使用量（我想大约15KB的最后一次我检查，但这是很久以前）。但是，您可以通过禁用RTTI和异常来减少这一点。其中的一些差异也可能是因为Microchip购买的DunCuMube C++库附带了自己的一套C库，而不是使用你所得到的C库，如果你只是用C.来构建，如果你想把所有的东西都塞进最小的芯片上，那么也许你需要T。哦，我要提的是，很久以前我们发现，包括流库（iOnStand，SsFrand等）引起了主要代码膨胀——使用了150 KB的Flash！我看过的经验丰富的C++开发人员和我看过的CppCon视频都表明流库基本上是可怕的垃圾堆火灾，所以我们仍然使用Prtff（）和朋友来满足我们的需要。我用C++开发的实际问题更多地是关于M的工具支持。微芯片比什么都重要。Microchip已经声明，他们不打算真正支持C++ 11，尽管XC32的新版本确实使用它很好（编译器支持它），但是在XC32 Prime1.43中使用的库支持是不完整的，并且当使用初始化器列表构造函数之类的东西时，会导致运行时挂起。）和声已经慢慢地变得更好了，但是在PLIB库中还有很多地方需要手工清理，因为它们做了很多隐式转换（在C中是可以的，而不是C++），并且由于错误的外部“C”声明。此外，和声配置器不必添加框架到C++设置的路径，因此必须手动复制C包含路径中的那些（为什么）！？）最后，MPLAX X的支持最好是摇摇欲坠。调试器对类模板的实例进行解码，并在成员函数中向您展示诸如此指针之类的有用内容，但是导航和语法突出显示确实很糟糕。MPLAB X无法识别合格的名称，因此无法找到任何形式的Class::symbol的定义，使得“Go to.”特性完全不可用。

我认为这不是因为C++不能用于更小的CPU，而是主要是因为它们没有真正的C++需要。

如果像AVRs和MSP430S这样的设备可以运行C++，我看不出PIC24S不能使用的真正原因。ARDUINO环境使用普通的AVR G+编译器。

动态内存分配是一个严重的陷阱：例如通过“+”而不是Struts（）来连接字符串。这是C++的一个很好的特性，它对运行时和RAM（堆）的使用有严重影响：检查生成的代码（我知道的任何核心），停止思考为什么你的软件这么慢。

您不必使用C++工具箱中的每一个工具。使用有用的东西，把剩下的放在工具箱里。不过里面有一些不错的工具。在任何情况下，C++都不会消失，所以学习它不会浪费时间。我从PIC32毫米USB好奇板开始，一个空的主程序，并为每一个外设创建了C++'驱动程序——一章一章（USB未完成，虽然我在努力）。我可能没有正确地执行它，并且大多数代码是内联的（或消除的），但至少我喜欢这样一种方式，可以将事情分组到结构/类中，使用重载函数而不是提供更多的函数名，等等。UnRID I后退并将工具放回工具箱中。

很好的平衡视图。只使用Prpff（）GOBLE闪存在一个小PIC上：