Mr. David Beberman is the VP Marketing and Sales for aicas, Inc., the US subsidiary of aicas GmbH and the CSO for aicas GmbH. www.linkedin.com/in/davidbeberman company: www.aicas.com


's contributions
    • Both C and C++ lack automatic memory management, which makes integrating libraries problematic. Both languages are susceptible to "1-off" errors with pointer arithmetic that can subtly corrupt the applications in very difficult to detect ways. Both languages are known for having "ghost" bugs that come and go depending on compilation and linking order. Both languages are extremely difficult to statically analyze. My answer to C or C++ for embedded applications: "Just say NO". For reference: Virtual Machine solutions with realtime automatic memory management have been on the market for more than 10 years now. They deliver performance equivalent to compiled C++. They deliver hard realtime capabilities, identical to, if not much better than, C or C++. They deliver safe multicore, multithreaded support. They are used in safety-critical and mission critical applications from medical devices to weapons systems. This technology works. Its deployed. Its battle-tested. There are NO errant pointers. There are NO memory leaks. There are NO corrupted stacks. There are NO array bounds errors. disclaimer: I work for aicas, which develops and markets hard realtime Java runtimes and language support for embedded and safety-critical systems.

    • "Poor reasons for using C or C++ for embedded systems" I just saw this article in a list with a new post on C and C++. All of the discussion is comparing using C or C++ for embedded software, on the heels of the Toyota case. My title would be as at the top of this: "Poor reasons for using C or C++" or perhaps "Reasons why not to use either C or C++ for embedded systems". Here's my short list: 1: Pointer arithmetic 2: No bounds checking 3: Non-deterministic dynamic memory allocation 4: Manual memory freeing 5: Incompletely specified formal language model 6: Easily corruptible stacks