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++?
\$\begingroup\$
\$\endgroup\$
8
asked Sep 9, 2012 at 15:12
-
6\$\begingroup\$ Meh. It all boils down to assembly code in the end. \$\endgroup\$– Ignacio Vazquez-AbramsCommented Sep 9, 2012 at 15:29
-
\$\begingroup\$ I liked it more when it was C++0x.. \$\endgroup\$– m.AlinCommented Sep 9, 2012 at 17:53
-
\$\begingroup\$ R-values in C++11 is a total BS. C guys were doing that even before C++ existence. \$\endgroup\$– user8459Commented Sep 9, 2012 at 18:30
-
1\$\begingroup\$ @IgnacioVazquez-Abrams - That is utterly irrelevant. \$\endgroup\$– RocketmagnetCommented Sep 10, 2012 at 9:52
-
\$\begingroup\$ Old-Stlye C++? C++ is old now? I feel very old then, only working with C! \$\endgroup\$– AngryEECommented Sep 10, 2012 at 16:23
|
Show 3 more comments
1 Answer
\$\begingroup\$
\$\endgroup\$
4
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.
answered Sep 9, 2012 at 17:48
-
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\$ Commented Sep 10, 2012 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\$ Commented Sep 10, 2012 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\$ Commented Sep 10, 2012 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\$ Commented Sep 10, 2012 at 12:13