在我看来,人们总是回避,或者更确切地反对在微控制器上使用C++,但我不能为我的生活找出原因.如果您远离大型C++库(例如STL)并且您不尝试使用RTTI或异常处理等复杂功能,那么C与C++之间是否存在明显的差异？虚拟继承是否会对复杂性或占用空间产生巨大影响？我认为这是一个额外的内存,但大多数复杂性将由编译器处理,但我再也不知道很多关于那个黑魔法.我只是不明白为什么人们非常坚持使用C,除了少数几个没有C++编译器的架构(如果有的话).即使你不能使用你的cin或cout,模块化和模板的好处似乎也是明智之举.
我问,因为我正在为一些我想做的爱好项目做一些研究.理想情况下,我希望严格地使用C++来实现很好地模块化的能力,而C语言的"SomeClass_SomeMethod(struct object*this ...)"是"面向对象"的方法.(我更喜欢这些项目的对象Pascal,但是对这种语言的支持并不完全是明星......)我宁愿避免转向功能更强大的微处理器,因为A.对于我正在做的项目,我不需要大量的资源..我不打算写60个状态卡尔曼滤波器或编码1080p视频B.(真正的踢球者)我想使用DIP和QFP封装中提供的处理器.我希望能够在没有焊接或烤制烤箱的任何东西的情况下进行原型设计.
有什么想法吗？
Cli*_*ord 20
在C++中,你基本上只需支付你使用的内容而不是C编译代码,并且一些附加功能是免费的.
一些用于小目标的C++编译器的最大问题是可用C++实现的完整性或C++编译器的可用性.
多年来,EETimes/Embedded.com就此主题撰写了大量文章:
这些文章的大部分内容是,您不一定要在嵌入式系统中使用所有 C++,而是根据内存,速度和各种功能的确定性来衡量或解释成本.您使用的部分取决于应用程序的性质(例如,它是否具有实时约束),以及目标平台的可用资源和性能.
当然它变化很大.
我不会在"小"MCU上使用虚拟继承.我根本不会使用堆.
在该空间中看起来最具吸引力的C++的特征是名称空间(用于在网络MCU的程序之间共享软件组件),模板(例如,通过I/O端口参数化协议),以及一般语义改进,如static_cast粗略的整体提升.
但是,至少在我对专业嵌入式系统的简短尝试中,一个合适的C++编译器根本就不存在,而且可用的糟糕的编译器每年花费数千美元.
GCC是可用于嵌入式平台的功能最强大,最广泛使用的C++编译器.但是,它的平台支持非常不平衡.如果您拥有无限的资源,EDG会宣传他们将为Comeau带来优于"您的"嵌入式平台的支持.
| 归档时间： |
|
| 查看次数： |
4439 次 |
| 最近记录： |