C++ in embedded systems

My definition of "first class functions" requires that the user be able to create new functions at run time. I can't see any reasonable way to accomplish this in C using the supplied pointers to (const) functions. If you know of a way to do it, can you please share it with me?

Kelly

Stroustrup mentions the 'problem' of template code bloat in his introductionary chapter on templates when he is explaining user defined specialization. He then goes on to develop a example of how to avoid it. Meyers mentions the 'problem' in item 42 of "Effective C++" and gives a solution too. These are perhaps the two most read C++ books around. On top of that the 'issue' is also mentioned again and again in language wars when advocates of other languages compare their language against C++. So this behavior is hardly unknown or unadvertized.

The default template behavior is optimized for speed and you want it optimized for size. Maybe implementers will provide templates with this default behavior when C++ gets popular in the embedded world until then just roll your own.

--
Rob

All of them were very enlightening, even those aparently controversial.

Regards.

Elder.

snipped-for-privacy@visi.com (Grant Edwards) wrote in news:3f3bc814$0$153$ snipped-for-privacy@newsreader.visi.com:

Which, in essence, is exactly what I said in the paragraph preceding the one you quoted, and which you conveniently snipped.

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

snipped-for-privacy@aol.com (Dingo) wrote in news: snipped-for-privacy@posting.google.com:

Personally, I subscribe to the view that EC++ was concocted by compiler vendors in order to create a market for their non-Standard- compliant C++ compilers.

I find many aspects of the rationale downright insulting, making direct or indirect references to embedded system developers' supposed limited ability to comprehend C++.

The removal of templates, exceptions, and RTTI is arguably justified on the grounds of efficiency although, as has been pointed-out elsewhere in this thread, any half-decent C++ compiler will allow the user to disable those anyway.

On the other hand, perhaps someone can explain why "mutable", namespaces, and the C++-style casts were removed, if not to make the compiler- writers' lives easier.

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

Ken Lee wrote: snip

Now I understand you, but the point is at best moot. Don't get me started on tools and Software Engineers.

We may be going round in circles here because I think it was I who expressed that sentiment.

THat's fine and exactly my point. The overall objective is to design a system which functions and performs correctly. OO is just one way this can be done but it is by no means the only one nor in my view the best one for embedded systems.

Ian

It's working now. Fascinating stuff. Just proves that a design is still only as good as the people doing it.

Ian

Agree 100%

Ian

snipped-for-privacy@aol.com (Dingo) wrote

I happen to disagree; that line isn't clearly and cleanly drawn (or could be in general). That "rationale" is pretty old and concerns other than safety in embedded systems (such as the availability of in-house-built C++ compilers) influenced the decisions.

For a different and somewhat contrary view, have a look at the ISO C++ standards committees TR on peformance issues:

- Bjarne Stroustrup,

Bill Pringlemeir wrote in news: snipped-for-privacy@sympatico.ca:

Yes, my point exactly; that's what I meant by "to make compiler- writers' lives easier." But that is not an argument invoked by the EC++ rationale.

There are many other things that could be removed from C++ that would have a much greater impact. What a coincidence that the things that were removed are largely things that were late additions to the C++ Standard and that therefore would have required extra effort to be supported by pre-Standard compilers.

I don't care if vendors want to subset C++ out of desire to sell their sub-Standard compilers to developers. I _do_ care when they spread FUD about C++ in order to do it. These deletions in no way make EC++ better able to "fulfill the particular requirements of embedded systems designs" than full C++.

"mutable" is also indispensible in certain circumstances to allow for const objects, and const objects are very useful in leveraging the C++ type system to assist in making code more reliable.

static_cast, const_cast, and reinterpret_cast have nothing to do with RTTI. Only dynamic_cast is related to RTTI.

On the other hand, static_cast and const_cast do make a program more reliable and more maintainable by working within the compiler's type system, instead of bypassing it, as C-style casts do.

Both C and C++ define numerous different symbol scopes, so I have a really hard time believing that namespaces will slow anything down significantly.

Visual C++, for one, allowed this long before EC++ came along, and I'm sure that others did too.

How does EC++ make this easier than a simple line of text in the description of the library that would state "does not use exceptions or templates"?

MV

--
Do not send e-mail to the above address. I do not read e-mail sent there.

Hi Kelly,

My understanding of "first-class" is that a first class item can be passed as a parameter, returned from a function and stored in a data structure. I've never heard that dynamic creation was a necessary component.

No, C/C++ can't create functions but using function pointers you can construct dynamic chainings of functions. I wouldn't call it "composition" (or anything close) but it suffices for a lot of uses.

George

Bill Pringlemeir wrote in news: snipped-for-privacy@sympatico.ca:

Namespaces are just a formal way of specifying how to decorate 3rd party API's with a vendor's name to avoid collisions. Removing them causes additional code clutter as one is forced to decorate every point of usage (eg. "vendor27_do_something()"). (With namespaces, one uses a using statement at the top of a block to identify which vendor's API's are in force for that block.)

If you use no 3rd party code (including libraries developed by other teams within your organization), namespaces are admittedly superfluous.

--
Kenneth Porter
http://www.sewingwitch.com/ken/

Google found this:

that lists the following conditions for "first class"-ness a) named by a variable b) passed as an argument c) returned as a result d) stored in a data structure e) created in any context

C has problems enough with arrays and structures let alone functions. In general, C forces one to be satisfied with pointers to non-trivial data instead of the data itself. Since I've been drinking the C Kool-Aid for years now I understand that slinging pointers around is both what has to happen deep down anyway on most CPUs and also enhances efficiency. I've been happy to keep arrays of function pointers to use as the basis for my state machines. It's just that C's support for functions is a whole lot less featureful than almost any functional programming language.

The last item describes being able to create new functions within the scope of another. Pascal and its ilk do that quite nicely while C/C++ limits you to global or file scoping.

My attitude is that "sufficing for a lot of uses" lies somewhere down the feature hierarchy from "first class". I'm happy that C provides as much as it does (it beats Fortran all to hell) but it still lacks the features I enjoy from the functional language realm (ML, Haskell, Scheme).

Kelly

My education is obviously dated. I took CS with Mitch Wand (EOPL) and Rick Kelsey but it was more than a few years ago. I don't recall that creation context mattered - what was important ws that that the whatsit be able to be passed around freely.

Nice to see Wellesley is teaching CS with Scheme instead of the language du jour.

No argument there 8-)

True, but Pascal's nested functions have limited visibility - they are not unlimited scope closures in the sense of Scheme et al.

Yeah, the only reason I care a wit about C++ is for business. For my own programming I wouldn't care if I never saw it again.

George

I went to the site and couldn't find any such article.

I think it has more to do with what our definition of 'support' is, rather than our definition of 'functional'. I don't think we disagree on the definition of functional programming.

Yes, and I don't think we can convince each other to change our definitions.

It depends on which object support you are refering to. I must not be using that particular support then.

Stroustrup mentioned in his book that generic programming is only supported statically, not at run-time. I guess from that point of view, C++ can't do full generic programming. Of course C++ does static binding also. This is a theme in C++. If your definition of these paradigms includes support for dynamic use of these constructs, then C++ doesn't support any of these paradigms.

But you can't look at both sides of the coin at the same time. This is my point. The models are views of the problem/solution. Can you combine the views? Sure. But is the resulting combined view the same as the original views by themselves? I don't think so.

It sounds like this is one of those differences in definition problems again. My definition of a paradigm is the philosophy behind a world view. Your definition seems to imply that it is ok to throw in concepts from other paradigms here and there, and it's still the same. I consider the result to be a different paradigm.

What I was doing was extrapolating.

Given C++ can be compiled into C; therefore, C can do anything C++ can do.

Given any language can be compiled into assembly language; therefore, assembly language can do anything any language can do.

Again, this is a result of our differing definitions of 'support'.

If a programmer was asked to produce an implementation, and the result didn't meet the requirements because of his ignorance of a feature, you don't consider this a mistake on the part of the programmer? Call it whatever you want. It's not the fault of the language or the tool, in my opinion.

Are you making an assumption that I'm a desktop programmer? I've been an embedded software engineer for 7 years, and spend all of that time designing and implementing software to be efficient in both memory and CPU usage.

Having said that, I don't totally agree with you about the desktop programmers. I agree that there are still many programmers that don't care about efficiency. But free software projects like GNOME and KDE are learning the hard way that efficiency can't be ignored. Even GCC, our favorite compiler, is feeling the heat. Just take a look at the number of complaints about later versions of GCC on their mailing list concerning compile times.

Of course, this is all off topic. As I've said in my original response, the bloat and performance problems are a myth. I believe Stroustrup himself responded with a pointer to a paper about the subject.

--jc

--
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org

... snip ...

You will get a much more readable page by appending "?print=true" to that URL

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

..snip

The most important optimization is done during DESIGN! Proper choice of algorithms is BY FAR more important than bit twiddling.

I have also been in the business for a while and use many languages (hopefully choosing the right one) and love BOTH C++ and Forth. Properly written C++ is more efficient than C, and Forth can create the smallest ROM image. It depends on what you are trying to optimize!

Todd

...And/or RTTI. You were completely write about all C++ style casts. Only dynamic cast is requiring RTTI support. I believe GCC will automatically warn about this if -fno-rtti is used. I guess this should be implicit.

I think that having the Standard does help to quantify what library facilities are used. Does the average programmer have time to quantify every aspect of the language. Getting the compiler options correct with a binary only distribution can be problematic.

I would be much more likely to buy/use a library that was Embedded 'C++' compatible. Even after reading the working groups paper on C++ performance, I think that exceptions are too expensive for my embedded devices with the compiler that is bundled with the OS. In fact I believe that stack tracing and tables will alway be more expensive in code space than letting a watch dog go. In the WG21 paper sighted, the exit/reset on error conditions didn't seem to be compared to EH overhead. Exit/reset on error are often used for simplicity and safety in embedded systems... at least that has been my experience, but maybe I am some sort of horrible barbarian.

I do think that at some point linkers and compilers will become mature enough ( and host computers will be fast enough) that templates will be useable and beneficial in the embedded space. But I have never seen a compiler that handle templates well enough for my needs.

Of course you can explicitly spell out every condition that a library adheres too, instead of just saying "Embedded C++ compliant". Just like you can do everything in assembly that you can do in C++.

fwiw, Bill Pringlemeir.

--
If I gave a damn, you'd be the first person I'd give it to.