Re: C++ in embedded systems

• Previous message: Joshua Kuo: "Re: modding IDE cable to write-protect compact flash?"
• In reply to: Jimen Ching: "Re: C++ in embedded systems"
• Next in thread: Jimen Ching: "Re: C++ in embedded systems"
• Reply: Jimen Ching: "Re: C++ in embedded systems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 23 Aug 2003 06:35:14 -0400

On Thu, 21 Aug 2003 08:01:38 -0000, Jimen Ching <jching@flex.com>
wrote:

>In comp.arch.embedded George Neuner <gneuner2@comcast.net> wrote:
>
>>Writing purely OO code is impossible in C++ because object support
>> does not extend to the basic data types.
>
>It depends on which object support you are refering to. I must not be
>using that particular support then.

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.

>>perform. Functional and procedural models center on actions and the
>>objects to be acted on. These models are not orthagonal, they are two
>>sides of the same coin.
>
>But you can't look at both sides of the coin at the same time.

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

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

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 response is: you absolutely CAN do this in C. Full C++ inheritence
>>is possible in C as evidenced by the first C++ compilers which
>>compiled C++ code into C. The result is very messy and, IMO,
>>unmaintainable, but it clearly demonstrates that C, in and of itself,
>>does support OO (at least to the same degree that C++ does).
>
>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'.

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.

>>>As for templates, whether those problems are programmer mistakes or not,
>>>depends heavily on the implementation. It is possible to avoid most bloat
>>>caused by templates. So, more likely than not, it is a programmer mistake.
>>
>>How is it a "mistake" to be ignorant of the cost of using a feature?
>
>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.

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.

>>People who write code for GHz processors with virtual memory and RAM
>>to burn largely don't care about the overall efficiency of their
>>compiler or the relative efficiency of language forms (they may pay it
>>lip service, but in the end it doesn't affect their ability to write
>>the program). I'm reading this thread in comp.arch.embedded where
>>most programmers do care.
>
>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.

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.

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

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.

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

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

• Previous message: Joshua Kuo: "Re: modding IDE cable to write-protect compact flash?"
• In reply to: Jimen Ching: "Re: C++ in embedded systems"
• Next in thread: Jimen Ching: "Re: C++ in embedded systems"
• Reply: Jimen Ching: "Re: C++ in embedded systems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]