4
\$\begingroup\$

I wonder if the new C++ (which called C++11) works well with the embedded electronics and programming them. Do the new features fit well if working with uC? Like R-Values and so on? Or should be restricted with the traditional and old-style C++?

\$\endgroup\$
  • 6
    \$\begingroup\$ Meh. It all boils down to assembly code in the end. \$\endgroup\$ – Ignacio Vazquez-Abrams Sep 9 '12 at 15:29
  • \$\begingroup\$ I liked it more when it was C++0x.. \$\endgroup\$ – m.Alin Sep 9 '12 at 17:53
  • \$\begingroup\$ R-values in C++11 is a total BS. C guys were doing that even before C++ existence. \$\endgroup\$ – user8459 Sep 9 '12 at 18:30
  • 1
    \$\begingroup\$ @IgnacioVazquez-Abrams - That is utterly irrelevant. \$\endgroup\$ – Rocketmagnet Sep 10 '12 at 9:52
  • \$\begingroup\$ Old-Stlye C++? C++ is old now? I feel very old then, only working with C! \$\endgroup\$ – AngryEE Sep 10 '12 at 16:23
1
\$\begingroup\$

It is not C++11 or old-style-C++, just like it is not C-only or C++-using-all-its-features. I love to use C++, but I hate specific aspects of it. (This is not C++ specific, although there are languages that I hate without exception.) Take the good bits (after checking that they are decently implemented), leave the rest for others or for later.

I have not used C++11 specifics yet (my lessons for this quarter are C++ on NDS using devkitPro, which has an old gcc). But one simple feature that I look forward to is the auto typed variable. Suppose you want to construct different types of objects (all subclasses of one base class), depending on the types of the 'constructor' parameters. You can't overload constructors of different classes, but you can overload various functions that return different types of classes. But to store the results, you must either remember the exact type they return (which spoils the factory pattern IMO) or have them all return a pointer to the base class type (which pulls heap management into your application, which I try to avoid). With the auto feature you can do

a_very_long_and_difficult_to_remember_class f( int x );
an_equaly_difficult_to_remember_class f( char *p );

auto x = f( 12 );
auto y = f( "hello" );

To me this means that an attractive pattern is suddenly very easy to use.

\$\endgroup\$
  • 5
    \$\begingroup\$ I don't see how this addresses the OP's question, which is about the suitability of C++11 for embedded systems. \$\endgroup\$ – Rocketmagnet Sep 10 '12 at 9:52
  • \$\begingroup\$ In the first paragraph I argue that "whether to C++11 or not" is a non-question, just like "to C++ or to C". When you can use a C++11-enabled toolchain go check which features are helpfull to you. The feature I show makes using the factory pattern easy while still 'banning' dynamic memory use (which is or should be a concern in a resource-constrained application). PS I aree that IVA's comment is irrelevant. \$\endgroup\$ – Wouter van Ooijen Sep 10 '12 at 11:28
  • 1
    \$\begingroup\$ That was not at all clear from the post. IVA's comment is bad because it suggests that any tool which generates assembler is equivalent. One could happily use the features of C++ which are most inappropriate for an MCU, while saying to themselves "It's all assembler in the end". I have seen this happen. \$\endgroup\$ – Rocketmagnet Sep 10 '12 at 11:51
  • \$\begingroup\$ In that case he is at least a bit sloppy, because he says "assembly code", which for me implies coding in assembly language. For other meaning he should say something like 'machine instructions', which is totally correct but equally pointless. \$\endgroup\$ – Wouter van Ooijen Sep 10 '12 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.