C++ in embedded systems

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

Reply to
Everett M. Greene
Loading thread data ...

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
Reply to
Jimen Ching

... 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.
 Click to see the full signature
Reply to
CBFalconer

..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

Reply to
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.
Reply to
Bill Pringlemeir

I'm referring to being able to derive from and change the behavior of the "basic" types (int,float, etc.). This is possible in, e.g., Smalltallk because *everything* is an object.

C++ makes a clear distinction between them. So does Java for that matter, but at least Java provides [separate] object versions of the basic types.

Sure you can ... just hold it at the end of your nose 8-)

You clipped a lot of what I said. As I stated before, I believe a good designer naturally uses both models because our thinking processes naturally do. Trying to rigorously apply just one design method is, IMO, a mistake which leads to convoluted solutions and therefore directly to buggy software. I believe the problem should be solved in the most natural way of thinking about it - sometimes that is OO and sometimes it is functional.

My definition of support is that the language can express the abstraction within its syntax and using its semantics. BASIC's constructs cannot model OO abstractions ... C's can. Assembler can model any abstraction and is not relevent to this discussion.

I will agree that the problem is a confluence, but I don't believe the statement that it is solely a mistake of the programmer. In order to be a "mistake", the programmer must have been aware of the problem and still chosen to use the problematic feature.

I'm had no preconceptions about what you do. I also use C++, instead of C or asm, for embedded programming whenever possible. But I recognize its limitations and don't try to hammer screws with it. I also recognize the difference between language and implementation, however the implementation is what ultimately matters.

I'm a big fan of interpreted (or incrementally compiled) languages that can be compiled to produce the final application. Development of complicated code is, IMO, made much easier when you can test your idea immediately upon coding it. Having to wait out the typical compile and link cycle to test something too easily breaks the train of thought (the phone rings, someone knocks on the door, etc.). Embedded programming adds "download to target/simulator" and makes the process even longer. I believe writing correct software is easier when you can focus on solving one problem at a time rather than trying to cover several (or several dozen) issues in a single build because the turnaround on a new build is so long.

I don't get to actually write code that way ... but I can dream.

I am concerned by long compile times (which seem to get longer with every new compiler release). But in the end I am far more concerned about the performance of the resulting executable than I am about how long it took to produce it. To that end, I want all the analysis and optimization the compiler can deliver.

The topic was "C++ in embedded systems".

Who mentioned performance problems? Anyway I agree that C++ has equivalent performance to C for most programs. I also agree that a problem that is a good fit to the OO model can have a smaller code footprint using C++ than using C. However I think this saving is partly illusory - the runtime data footprint is larger with C++ and I believe equivalent programs use approximately the same resources in total. YMMV.

George

Reply to
George Neuner

I never said C++'s lack of OO purity prevents using it effectively - I said that it was obvious that C++ was not designed to *be* OO, but rather to *add* OO to a procedural base language.

Absolutely. The very issue Andras Tantos and I were discussing previously: parametric dispatch on object parameters.

Anytime you have a base class pointer (or reference) and must pass the object to a function based on the runtime type, you have to do it manually. Code such as the following (abbreviated) cannot select the right overload of F() based on the runtime type of the object and the call to G() won't compile.

: class A; class B : public A; void F( A &a ); void F( B &b); void G( B &b ); : A *pA = new B; F( *pA ); // calls F(A) not F(B) G( *pA ); // error ... argument is not a reference to B :

Whenever you need code such as this, you must test for the actual runtime type, construct a new pointer or reference with the appropriate static type and manually dispatch the call - in effect manually doing everything objects are supposed to do automatically.

I'm sure if I looked back at C++ code I've written over the years I can find other really annoying examples. The parametric dispatch issue just happened to be at hand.

George

Reply to
George Neuner

This is one of those misconceptions I was talking about. This is not OOP at all. This is just function overloading. Which has nothing to do with OOP. What you really want to do is use polymorphism.

--jc

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

You're missing the point ...

It is not a misconception about OO at all ... it is a case where objects in C++ don't behave as objects, but instead behave as raw data, forcing the programmer to explicitly code the desired object polymorphic behavior.

I know the difference between object polymorphism and parametric polymorphism. My point is that C++ purports to provide both and manages to accomplish neither when the two concepts are used simultaneously.

George

Reply to
George Neuner

Do you have a source where it states that function overloading is supposed to provide polymorphic behavior?

Object polymorphism implies inheretance and member functions, but your example contain neither. Parametric polymorphism implies templates, but your example doesn't use this either. Your assertions would be a lot more powerful, if they were backed up with concrete examples that actually contain the semantics you're discussing.

--jc

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

Polymorphism is the quality of being able to assume different forms.

Do you know of a reason to allow differently parametered functions to have the same name apart from wanting the name to mean different things?

I'm unclear as to whether you mean "template" mathematically as a generic specification of function or whether you mean a C++ template. I'm going to assume the mathematical usage as the other makes very little sense in this discussion.

WRT programming models, object polymorphism is just a restrictive, special case of parametric polymorphism obfuscated by syntactic sugar. I'm not going to debate the merits of reasoning with the "special" object model vs. the general functional one - we can continue that discussion in comp.lang.whatever ... it's several parsecs further OT than we already are now.

ISO/IEC 14882 sections 3 [basics] and 10 [classes] state that name lookup may associate more than one declaration with a name if the name is found to be a function, and the set of declarations forms a set of overloaded functions. Section 13 [overloading] spells out the resolution of overloaded functions. A function containing an implicit object parameter, ie. a member function, is determined statically at compile time from the (positional) static types of the function parameters excluding the implicit object parameter. The actual function is determined at run time by the actual type of the implicit object parameter.

C++ implements a half baked scheme of statically resolved parametric polymorphism which disallows most uses of object parameters and uses a special case to allow one particular syntactic form to be handled at run time while disallowing all other equivalent syntactic forms.

In simple terms: C++ implements object polymorphism as lobotimized parametric polymorphism.

You asked me in what situation(s) C++'s distinction between objects and other data types mattered. I answered that question and provided a simple example. The issue you missed entirely is this:

"Objects in C++ don't always behave as objects."

George

Reply to
George Neuner

I guess I wasn't clear in my response to this assertion. So let me state it explicitly.

"No one cares! Most people can still do OOP in C++ just fine."

--jc

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

Well, your first statement is obviously false. As to the second, I defer to one wiser than myself, who once wrote: "It is clearly possible to write good code in C++. It's just that no one does."

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

I guess I should have chosen better words.

Yes, I totally agree. Considering this sub-thread is based on misconceptions of C++, this observation would be implied...

--jc

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

To know that "no one does" needs omniscience, not mere wisdom. So your source was not a particularly wise person, then! In fact, I've seen quite a lot of "good" C++ code, though there's a lot more bad code about - in all languages. C++ is certainly not foolproof; the answer is not to put it in the hands of fools (or, at least not to accept the output of such people as viable code).

Peter.

Reply to
Peter Bushell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.