Re: C++ in embedded systems

From: George Neuner (gneuner2_at_comcast.net)
Date: 08/19/03 

Date: Mon, 18 Aug 2003 18:57:44 -0400

On Mon, 18 Aug 2003 05:58:46 -0000, Jimen Ching <jching@flex.com>
wrote:

>In comp.arch.embedded George Neuner <gneuner2@comcast.net> wrote:
>>On Sat, 16 Aug 2003 21:26:54 -0000, Jimen Ching <jching@flex.com>
>>wrote:
>>>C++ supports three different programming paradigms; procedural, object
>>>oriented and generic.
>>
>>Four ... you forgot functional. However, C++ is primarily a
>>procedural language with support for OOP. IMO, its support for both
>>functional and generic programming is poor and its support for
>>modularity is effectively nonexistent.
>
>Well, the question then is--does C++ really support functional and generic
>programming? I left functional programming out because I'm pretty sure the
>C++ designers didn't explicitly plan to support this programming paradigm.
>At least I don't think it's a commonly accepted capability of C++.

This depends on what your definition of "functional" is. Most people
hold it to be first class functions and some include higher order
functions. Immutable data structures are not strictly necessary -
every recognized functional language allows destructive update in some
form.

C has first class functions (via function pointers) and C++ inherited
that from C. That makes functional programming possible if not
necessarily easy.

You are correct that it is not recognized ... it is there nonetheless.

>Note, when I said C++ supports these programming paradigms, I meant C++ was
>specifically designed with these programming paradigms in mind. Thus,
>specific capabilities were added to the language for programmers to use. I
>mentioned that most languages can simulate features of most other languages.
>But this, in my opinion, doesn't mean that language A supports functional
>programming because it can simulate features of language B which was designed
>specifically for functional programming. In other words, 'support' means
>more than just being able to simulate capabilities needed for that paradigm.
>The language must explicitly provide those capabilities. I believe this
>is very important in a language.

You have a different definition of "support". By my definition,
"support" for something in a language means that something can be
accomplished within the scope of the language's syntax and semantics.
To that end, assembler supports all possible paradigms - BASIC, for
example, does not.

I believe C++ was designed to add OO concepts to a procedural base
language. Clearly it was not designed to *be* OO because objects are
not central to coding nor even necessary. Writing purely OO code is
impossible in C++ because object support does not extend to the basic
data types. However, writing purely procedural code is easy.

C++'s support for generics is no more than a kludge - a compiler
trick. True generics allow functions to be written without regard to
data types. That is impossible in C++. Templates allow code to be
more easily "specialized" for a particular concrete type but they are
a far cry from generics.

>>> For those who have ported your C software to C++ and declare you're
>>> doing object oriented programming, ask yourself this question:
>>> did I perform a paradigm shift? If the answer is no, then you
>>> aren't doing object orient programming.
>>
>>I don't think people misunderstand this at all. All of programming is
>>about defining the data to be manipulated and the functions which
>>manipulate it.
>
>By programming, do you mean implementation only? Or do you mean design _and_
>implementation? If the former, I can see where you're coming from. But I
>don't agree 100 percent. But if you mean design also, I have to disagree.
>The reason why people identify the different programming paradigms is because
>they are different, not just in implementation, but also in how one looks
>at the problem domain.

I mean design.

All the paradigms we are discussing are thought exercises. OO centers
on abstracting the "world" in terms of actors and actions they
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.

I believe good designers bounce back and forth between these modes of
thinking constantly. Our thought processes naturally deconstruct
problems in a certain way ... some problems are more actor oriented
and some are more action oriented. Procedural thinking makes solving
an actor oriented problem clumsy - OO thinking does the same for an
action oriented problem.

Implementation issues are secondary to the thought process. Any
Turing complete language can simulate any other (with varying degrees
of effort). The extent to which any particular language helps in
implementing the program model is relevent only to expediency. As all
program solutions involve some aspects from each of the models, the
choice of implementation language is less critical than the solution
itself.

I firmly believe the language wars arise, in part, because programmers
forget that their chosen language facilitates a model of thinking that
they find comfortable, and it is not the language they are defending
but their model of thinking.

>>You can implement full C++ inheritence in C ... it is just very messy.
>
>>From the point of view of GCC (the GNU Compiler Collection), all languages
>ultimately becomes assembly language. Whether you want to use this as
>proof that assembly language can be used for all programming paradigms is
>your personal world view. I personally don't see it that way.

I wasn't referring to that aspect. I was responding to your assertion
that C++ inheritence is impossible to achieve in C. You said:

"Rudimentary inheritance can be achieved with nested structures in
C. This is a mistake people often make with object oriented
programming. First of all, nested structures in C is equivalent to
C++ data composition. This is not inheritance. Second, inheritance
involves more than just inheriting data variables, it also involves
inheriting interfaces. You can't do this in C. When people talk
about C++ inheritance, they are often talking about the latter. "

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

>>Bloat is a valid (though manageable) criticism. Most C++ compilers
>>link in all of a class's methods whether or not they are actually
>>referenced in the application. Heavy use of templates creates many
>>nearly identical copies of code and interacts badly with the method
>>linkage problem because most templates are used to create new classes.
>>Not everybody knows that intrinsics are inlined.
>>
>>Is it a programmer mistake? I don't think so.
>
>Yes and no. You've lumped a lot of examples together.
>
>In the case of poor compiler behavior, no that's not a programmer mistake.
>Though choosing the compiler might be. ;-) No, just kidding. C++ compilers
>are not yet at the same maturity level as C compilers. This is in part the
>language's fault. C++ is large, and complex. I don't think anyone is going
>to disagree with that. But, in C++'s defence, it's only been ratified since
>1998. The language itself is quite different from the original definition
>back in the 80's. Why don't we see the state of the technology when C++
>is 10 years old? I'm sure it would be as mature as C compilers are now,
>which is based on a language that is over 10 years old (since becoming a
>standard, not since it was developed/used).
>
>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?
Particularly when the cost is either not known or not advertised. As
I said before, most of these issues were found by frustrated
developers looking at the compiler's output. The documentation for
your compiler rarely tells the gory details of the implementation of
language forms.

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.

George

Relevant Pages

  • C language now truly universal
    ... C language now truly universal ... a C compiler for z/VSE (an ... IBM mainframe operating system), and would like to ... Has a documented programming API. ...
    (comp.lang.c)
  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: Learning C++?
    ... >> abide such rules or there are people who don't know the rules. ... > programming is excellent, and its object-oriented support is quite ... code, like Java or Ada or what else, but no language can prevent the ... This is also something the compiler should be ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Beyond CL?
    ... around in the internals of the language. ... as the programmable programming language; ... Eventually a bank of many users' optimizations could be ... approach the fabled "sufficiently smart compiler". ...
    (comp.lang.lisp)
  • Re: Error message about my user defined type
    ... write a compiler that allow a true VB7 to run on the .Net platform ... > COM programming all day long. ... > wide available to any programming language who wants to use them. ... > other than using the CLR and the MSIL. ...
    (microsoft.public.vb.general.discussion)