小脚印微控制器上的C ++ [英] C++ on Small-Footprint Microcontrollers

问题描述

在我看来，人们一直在逃避，或者强烈地反对在微控制器上使用C ++，但是我无法为我的生活找出原因。如果您远离大型C ++库（例如STL），并且不尝试使用诸如RTTI或异常处理等复杂功能，C与C ++之间是否存在明显的区别？虚拟继承对复杂性或占用空间有巨大的影响吗？我会认为这将是一个额外的内存，但大部分的复杂性将由编译器处理，但是再一次我不太了解这个黑魔法。我只是不明白为什么人们非常坚持使用C，除了可能没有C ++编译器（如果有的话）的少数架构。似乎模块化和模板的好处将是一个没有脑子，即使你不能使用你的cin或cout。

It seems to me people consistently shy away from, or rather vehemently oppose the use of, C++ on microcontrollers, but I can't for the life of me figure out why. If you stay away from large C++ libraries (e.g. STL) and you don't try to use complicated features like RTTI or exception handling, is there really any noticeable difference between C vs C++? Does virtual inheritance have a huge impact on complexity or footprint? I would think it'd be a little extra memory, but most of the complexity would be handled by the compiler, but then again I don't know a lot about that dark magic. I just don't understand why people are pretty adamant about using C, except maybe for the few architectures for which there aren't C++ compilers (if there are any). It seems the benefits of modularization and templates would be a no-brainer, even if you couldn't use your cin or cout.

我问，因为我正在做一些研究一些我希望工作的爱好项目。理想情况下，我想要使用C ++严格的功能来很好地模块化事物，而不是C的SomeClass_SomeMethod（struct object * this ...）方法来实现面向对象。 （我更喜欢这些项目的对象Pascal，但是对这种语言的支持并不是很好）...我宁愿避免移动到更有能力的微处理器，因为A.对于我在做的项目，我不需要大量的资源..我不打算写60状态卡尔曼滤波器或编码1080p视频B.（真正的踢球者）我想使用DIP和QFP包中提供的处理器。我希望能够在我的烤箱中焊接或烘烤任何东西，而不用焊接或烘烤任何东西。

I ask because I'm doing some research for some hobby projects I'd like to work on. Ideally, I'd like to work with C++ strictly for the capability to nicely modularize things, vs. C's "SomeClass_SomeMethod( struct object* this ... )" approach to "object orientedness". (I'd much prefer object Pascal for these projects, but alas support for that language isn't exactly stellar...) I would rather avoid moving to a much more capable microprocessor because A. for the projects I'm doing, I don't need tons of resources.. I'm not planning on writing 60 state Kalman filters or encoding 1080p video B. (the real kicker) I'd like to use processors available in DIP and QFP packages. I'd like the ability to prototype without soldering or baking anything in my toaster oven.

任何想法？

推荐答案

在C ++中，您基本上只支付您使用的超过或多于C的可编译代码，另外一些额外的费用是免费的。

In C++ you essentially only pay for what you use over and above what would otherwise be C compilable code, and some of the extras are cost free.

一些用于小目标的C ++编译器的最大问题是可用C ++实现的完整性或完全可用的C ++编译器。

The biggest issue with some C++ compilers for small targets is the completeness of available C++ implementations or the availability of a C++ compiler at all.

EETimes / Embedded.com多年来一直在关于这个问题的文章：

EETimes/Embedded.com has run a number of articles on the subject over the years:

• 甚至在最低级别 - Dan Saks


• 嵌入式C ++产生更小的代码 - John Carbone


• 为什么C ++是C的可行替代方法嵌入式系统设计 - Fergus Bolger


• 拒绝C ++的糟糕原因 - Dan Saks


• 高效使用C ++在嵌入式应用程序中 - 导师图形/ Cesar A. Quiroz


• C ++的低效率，事实还是小说？ - IAR Systems / Anders Lundgren

• Better even at the lowest levels - Dan Saks
• Embedded C++ Yields Faster Smaller Code - John Carbone
• Why C++ is a viable alternative to C in embedded systems design - Fergus Bolger
• Poor reasons for rejecting C++ - Dan Saks
• Using C++ Efficiently in Embedded Applications - Mentor Graphics/Cesar A. Quiroz
• The Inefficiency of C++ , Fact or Fiction? - IAR Systems/Anders Lundgren

这些文章中的大部分内容是您不一定使用所有的C ++在嵌入式系统中，它们测量或解释了各种功能的内存，速度和决定性方面的成本。您使用的部分将取决于您的应用程序的性质（例如是否具有实时限制），以及目标平台的可用资源和性能。

The point most of these articles make is that you should not necessarily use all of C++ in an embedded system and they measure or explain the cost in terms of memory, speed, and determinism of various features. What parts you use will depend on the nature of your application (whether it has real-time constraints for example), and the available resources and performance of your target platform.

这篇关于小脚印微控制器上的C ++的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！