Myths

Contents[Show]

As I started working in the embedded environment I was astonished that there was so much prejudice against the usage of C++ in embedded programming. Most are based on a wrong understanding of the programming language C++.

 

 

The Myths

lagerfeuer

First, I have to say a few words about the myths about C++ I often heard. Of course, this post reflects my perception. Examples?

  • Templates inflate the code.
  • Objects must live on the heap
  • Exceptions are expensive.
  • C++ is too slow and needs too much memory.
  • C++ is too dangerous in safety-critical systems.
  • You have to program object-oriented in C++.
  • C++ can only be used for applications.
  • The iostream library is too big; the Standard Template Library to slow.

 

Rainer D 6 P2 540x540Modernes C++ Mentoring

Be part of my mentoring programs:

 

 

 

 

Do you want to stay informed about my mentoring programs: Subscribe via E-Mail.

Or to say it in one statement.

=> C++ is a nice toy, but we are dealing with serious challenges.

The list of (pre)judice is long, consisting partially of half-truth and untruth statements often stated by experienced C programmers. I will only refer to the untruth statements. The half-truth statements are, to a significant extent, questions due to the right usage of C++ and, to a small extent, questions of the implementation of the core and the libraries of C++. 

  • Objects must live on the heap.
    • Objects can be created on the stack or at an arbitrary position with the help of placement new.
  • C++ is too dangerous in safety-critical systems.
    • Of course, it depends on the experience of the developer. But whoever uses C strings instead of C++ strings; uses C arrays instead of C++ arrays; or uses macros instead of constant expressions or templates can not argue that C++ is not well suited for safety-critical systems. Honestly, the contrary holds. C++ has a lot to offer in safety-critical systems. 
  • You have to program object-oriented in C++.
    • C++  is a multi-paradigm language. Therefore, you can solve your problem in an object-oriented, structured, functional, generic, or generative style.
  • C++ can only be used for applications.
    • C++ is, for example, used for fire extinguishers, defibrillators, and cars. ARM maintains the current GCC collection with ARM GCC and the gnu toolchain. Therefore, the current g++ compiler is available. The packages that are very frequently used are maintained by ARM for their processors, which are the default architecture for the embedded world.

What's the reason for the half-truth? I think there are more reasons.

  • Old C++ compilers
    • The knowledge is based on old C++ compilers of the last millennium. They implement the C++98 standard but they have a large potential for optimization.
  • Training deficit
    • On the one hand, many embedded programmers learned only C. On the other hand, there is no time to experiment with new technologies.
  • Loss of expert state
    • You have to be brave to leave your area as a C expert and continue the next day as a C++ novice.
  • Legacy codebase in C
    • The existing code base is in C therefore is the apparent decision to fix a bug or implement a feature in the first place in C.
  • Many C experts
    • There are many C experts. They are training the novices and becoming leaders.
  • Curse of the monoculture
    • I perceive the embedded world often as a monoculture. I worked for 15 years as a consultant in the automobile area and used about ten languages. On the contrary, I used only three languages in the embedded area. 
  • The pressure of the standard
    • There are a lot of standards that you have to fulfill. The courage to use new technologies seems inversely proportional to the pressure of the standards. 
  • Insufficient knowledge of C++
    • Many developers do have insufficient knowledge of classical C++ and no knowledge of modern C++.

     

Maybe, I will polarize with this post. But If it helps to make the great features of modern C++ better known in the embedded world, then I want to do it voluntarily. In the next post, I compare the myths with the facts. In particular, I will write about the Technical Report on C++ Performance.

 

 

 

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, and Rob North.

 

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, and Slavko Radman.

 

 

My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small

 

My special thanks to PVS-Studio PVC Logo

 

My special thanks to Tipi.build tipi.build logo

 

My special thanks to Take Up Code TakeUpCode 450 60

 

Seminars

I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)

German

Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

  • C++ - The Core Language
  • C++ - The Standard Library
  • C++ - Compact
  • C++11 and C++14
  • Concurrency with Modern C++
  • Design Pattern and Architectural Pattern with C++
  • Embedded Programming with Modern C++
  • Generic Programming (Templates) with C++

New

  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,

RainerGrimmDunkelBlauSmall

Tags: Myths

Comments   

0 #1 Maran 2016-10-03 02:10
"indirectly proportional" - perhaps you meant inversely proportional?
Quote
+1 #2 Rainer Grimm 2016-10-03 06:50
Quoting Maran:
"indirectly proportional" - perhaps you meant inversely proportional?

Thanks, you are right. Strange: the opposite of direct is not indirect in English. In German the expression indirekt proportional is fine.
Quote
+1 #3 Shafik Yaghmour 2016-10-12 19:46
Dan Saks's Cppcon 2016 talk “extern c: Talking to C Programmers about C++”: https://www.youtube.com/watch?v=D7Sd8A6_fYU

Very much addresses the issue of how to talk to C programmers, especially in the embedded field about C++.
Quote
0 #4 may xuc do choi 2017-01-05 19:58
I am genuinely grateful to the holder of this web site who has shared this wonderful piece of writing at
here.
Quote

Stay Informed about my Mentoring

 

Mentoring

English Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Course: The All-in-One Guide to C++20

Course: Master Software Design Patterns and Architecture in C++

Subscribe to the newsletter (+ pdf bundle)

All tags

Blog archive

Source Code

Visitors

Today 3886

Yesterday 4344

Week 40764

Month 21010

All 12099219

Currently are 151 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments