我对编程非常适合嵌入式编程的语言很感兴趣。 特别是：
是否可以用C ++编写嵌入式系统？ 或者使用纯C更好？ 或者，只有当语言的某些功能（例如RTTI，例外和模板）被排除在外时，C ++才行吗？
这个领域的Java怎么样？
感谢。
答案 0 :(得分：26)
是否可以编程嵌入式 C ++中的系统？
是的，当然，即使是8位系统。 C ++只有比C稍微不同的运行时初始化要求，即在调用main（）之前必须调用任何静态对象的构造函数。开销（不包括你控制范围内的构造函数本身）很小，但你必须要小心，因为没有定义构造顺序。
使用C ++，您只需为您使用的内容付费（而且许多有用的内容可能是免费的）。也就是说，例如，一块也是C ++可编译的C代码通常不需要更多内存，并且在编译为C ++时执行速度不比编译为C时慢。有些C ++元素可能需要小心有，但许多最有用的功能来自很少或没有成本，并有很大的好处。
或者使用起来更好 纯C？
在某些情况下可能。一些较小的8位甚至16位目标没有C ++编译器（或者至少没有任何一种代表），使用C代码可以提供更大的可移植性。此外，对于应用程序较少的资源严重受限的目标，C ++可以带来的优势很小。 C ++中的额外功能（主要是那些支持OOP的功能）使其适用于相对较大和复杂的软件构建。
或者C ++只有在某些情况下才行 语言的特征（例如RTTI， 例外和模板） 排除？
可接受的语言功能完全取决于目标和应用程序。如果您受内存限制，您可能会避免使用昂贵的功能或库，即使这样，也可能取决于它是您缺少的代码还是数据空间（在这些是独立的目标上）。如果应用程序是hard real-time，您将避免使用那些不确定的功能和库类。
一般情况下，我建议如果你的目标是32位，那么总是使用C ++而不是C，然后削减你的C ++以适应内存和性能限制。对于较小的部分，在选择C ++时要稍微谨慎一点，尽管不要完全打折;它可以让生活更轻松。
如果您确实选择使用C ++，请确保您具有可识别C ++的适当调试器硬件/软件。使用C ++构建复杂软件相对容易，使得一个体面的调试器更有价值。并非所有嵌入式领域的工具都具有C ++知识或能力。
我总是建议在Embedded.com上搜索任何嵌入主题的档案，它有很多文章，包括一些这样的问题，包括：
关于Java，我不是专家，但它有很大的运行时要求，使其不适合资源受限的系统。您可能会使用Java将自己限制在相对昂贵的硬件上。它的主要优点是平台独立性，但是这种可移植性并没有扩展到不能支持Java的平台（其中有很多），因此它可以说比具有抽象硬件接口的精心设计的C或C ++实现更不便携。
[edit] 我刚刚在TechOnline时事通讯中收到了这封信：Using C++ Efficiently in Embedded Applications
答案 1 :(得分：9)
在嵌入式系统中，您编程的语言通常取决于实际可用的编译器 如果您的硬件只有C编译器，那就是您要使用的。如果它有一个像样的C ++编译器，那么实际上没有理由偏爱C而不是C ++ 我敢说Java在嵌入式系统中不是一个非常受欢迎的选择。
答案 2 :(得分：9)
嵌入式编程目前涵盖了大量应用程序 粗略地说，它从传感器/交换机到完整的安全系统 您的语言应该以复杂性和硬件资源为基础 它是HW（CPU，...），操作系统，协议，......之后的选择之一 可能的选择：
答案 3 :(得分：6)
或者，只有当语言的某些功能（例如RTTI，例外和模板）被排除在外时，C ++才行吗？
按照这些思路思考是件好事。编译时复杂性并不是一件大事，但运行时复杂性会产生资源成本。
C ++促进类/命名空间模块化（例如，在多个上下文中的方法foo()）和实例模块化（属于多个对象的成员字段bar），这两者都是一个很大的优势软件设计。还有const，引用，静态强制转换和模板等功能，这些功能可以帮助实施约束并且几乎没有运行成本。
我不排除模板。它们考虑起来很复杂，你需要一个能够很好地处理它们的编译器，但是资源成本几乎都是编译时间 - 每次使用具有不同类参数的模板时，“花费”的事实是什么您生成一组新的代码来实例化成员函数。但是，如果没有模板，你几乎肯定要做同样的事情。此外，模板允许您在一般情况下设计和测试库，这些文件在编译时而不是链接时实例化。只是为了澄清：模板允许你有一个你测试的文件A.h.然后将它与文件B.h或B.c一起使用，以便在编译时实例化它。 （一个库将被链接而不是被编译，这使它变得不那么灵活 - 模板方法可以被优化掉，因此它们不会产生函数调用。）我在嵌入式系统中使用模板来实现CRC代码并修复 - 点数学：我可以测试通用代码，将其放在版本控制中，然后通过编写一个派生自模板的简单类或具有模板成员字段来重复使用它。当然，典型的例子是STL。
RTTI和例外：这些会增加运行时复杂性。我不太了解资源成本，但我希望RTTI相当简单（只需添加一个类型标记，花费额外的空间），而异常可能是野蛮的，涉及堆栈展开。
虚函数：由于内存+执行时间成本（最小但仍然存在），以及调试的复杂性，我过去常常将它们排除在外，但它们允许您从每个函数中解耦对象其他。如果你不使用虚函数，当一个类的实例（例如Foo）需要执行与另一个类的实例（例如Bar）相关联的代码时，那么第一个类需要知道关于第二个类的所有内容（编译Foo）你需要与Bar中的所有方法建立静态链接 - 这会增加很多紧耦合。
动态内存分配：这是另一件大事（也就是在C中），我们就像我公司的瘟疫一样避免 - 不仅会出现各种各样的错误，但是大的运行时成本是分配器/解除分配器，你必须愿意并且能够知道成本是多少并接受它。
编辑我会喜欢在嵌入式世界中使用Java而不是C ++。不幸的是我的选择是有限的，并且我工作的空间中的运行时资源成本（代码大小，内存大小，垃圾收集时间限制）太高。我使用Java的原因是因为它的运行时好处而且更多用于事实上，它的软件设计更清晰，而且工具更好（OMG！重构！哇哇！）......我的关键似乎在于两件事情，这使得C / C ++相比之下感觉非常笨重：
所有东西都是一个对象，所有方法都是虚拟的，所以你可以在很大程度上依赖于接口的抽象。
Java中的接口/实现分离不是这个笨拙丑陋的.c/.h文件分裂的东西，它使编译器变得如此之慢。相比之下，我在Eclipse中使用Java，它在编辑时自动编译代码。这太棒了！我立即发现了大部分错误。在C / C ++中，我必须等待整个编译周期。
总有一天，我希望C / C ++和Java之间会有一种语言能够为软件开发提供Java的优势，而不需要让Java对桌面/服务器应用程序具有吸引力但在大多数嵌入式应用程序中没有吸引力的花俏。世界。
答案 4 :(得分：3)
C和C ++都可以在嵌入式系统上使用。如果你确实限制了你使用的C ++的功能，那么它将使用与C大致相同的速度和空间。至于使用这些附加功能，它实际上取决于你的约束。例如，如果您正在制作实时系统，那么异常可能不是一个好主意，仅仅因为考虑异常的传播时间以及异常可能传播的所有路径都会使硬实时保证变得非常困难（尽管如此，ACE / Tao实时CORBA实现再次使用异常）。虽然模板和RTTI可以导致更大的程序，但嵌入式系统存在很多变化，因此根据您的资源限制，这可能是完全正常的或不可接受的。 Java也是如此。 Java（在技术上，Java编程语言和Java API的子集）在Android上运行，例如，使用Dalvik VM。 J2ME可在各种嵌入式设备上运行。它是否适用于您的应用程序取决于您的特定约束。
答案 5 :(得分：2)
c是嵌入式系统中最常用的语言。
但是，我认为C ++的未来在于嵌入式系统领域。我认为C ++ 0x标准将有助于该研究。所以我不会惊讶地看到C ++在这个领域中使用了更多。
答案 6 :(得分：2)
我认为克利福德已经有了一个很好的答案，但我会把它的经验添加到它。正如所指出的，嵌入式系统的类型是主要驱动因素。在国防/航空航天领域，C和Ada是我遇到的最流行的嵌入式语言。虽然随着时间的推移，我看到更多的C ++，因为基于模型的开发变得越来越受Rhapsody等工具的欢迎。在职位列表中，看到面向对象设计体验的要求也让我相信市场正在慢慢转变以跟随主流发展的趋势。
如果您真的对嵌入式开发感兴趣，我会从C开始。它非常普遍。几乎所有操作系统，包括Integrity，Nucleus，VxWorks和嵌入式Linux等实时操作系统，都有一个编译器和工具。你将学习关于指针，内存管理等的东西......至少会在嵌入式世界中很好地转化为C ++开发。
对于Java，如果您对智能手机等移动平台的开发感兴趣，这是一个可靠的选择（Android会浮现在脑海中）。但在实时操作系统领域，我还没有看到它。
就此而言，这让我想到了最后一点和建议。如果我想进入嵌入式编程（我在4年前做过），我将专注于从低层次的角度学习C，如上所述。然后，我还将了解是什么让实时编程如此困难/不同。我发现下面这本书非常擅长教你像嵌入式程序员和应用程序开发人员一样思考。祝你好运！
答案 7 :(得分：1)
它实际上归结为您正在运行的硬件平台，因此您可以使用哪些软件平台。对于很多最近的嵌入式套件 - 围绕片上系统，兆字节或两个RAM，一些设备而设计 - 您真的需要一个小型操作系统来管理低级硬件，同时专注于您的应用程序。您选择的操作系统会限制您的可用语言集。
在嵌入式空间中使用C ++当然是可能的，但该语言的完整功能集需要大量工作才能正确移植。例如，eCos以C和你可能称之为C ++的结构方面的混合实现;免费版本中缺少对RTTI，异常和STL的支持，尽管有人正在为此工作（以及可用的商业端口）。
同样，可以使用Java - 我知道，我已经将JVM移植到嵌入式环境中;它并不好玩 - 尽管你通常会得到一种简化的Java语言配置，通常是基于J2ME的。