public inbox for
 help / color / mirror / Atom feed
From: "Kenneth Porter" <>
To: "Embedded C++" <>
Subject: Re: biggest deterrant to using C++?
Date: Fri, 14 Aug 1998 16:04:00 -0000	[thread overview]
Message-ID: <> (raw)

On Thu, 13 Aug 1998 09:17:39 +0200, Saffi Hartal wrote:

>1. C++ is very implicit and therefor dangerous.  Programers must (as always)
>know what to do and what to use and more important what not to use
>(overloading of casting, calling polymorphic function in constructors,
>using bad design with overheads not reasonable ). One should be very

This is true of any language, and not limited to C++. Assembler and C
have pitfalls as well. A professional programmer using C++ for embedded
work should be familiar with Meyer's _Effective C++_ books. I've also
found C++ Report to be a good resource for advanced topics.

>2. The main benefit of C++ is in the application side. C++ have many
>benefits that do not come into action if your very near the hardware
>(usually) . such benefit is avoiding sending all those parameters by
>function because the object know them already, it was constructed or
>initialized with the parameters (other way to do that is with annoying
>arrays and passing Id's). when you write drivers you usually do it C style
>and you prefer that  your colleague would not touch C++ and make annoying

The benefit of using C++, like that of any language, is to provide
syntactic constructs that eliminate tedious error-prone busy-work like
boilerplate code. Even assembly language exists to eliminate the
error-prone construction of machine language bit by bit. The Windows
world has hidden some of this boilerplate generation behind "wizards",
which provides yet another layer of tool to help avoid errors.

>3. In Our Embedded project with vxWorks, I use a bit of C++ when it
>convenient, the people around me do not. if there isn't a real benefit it
>should not be used. but I do think that using the compiler with strict type
>check is good. in future when the need to add polymorphic feature will
>arouse we might use much more C++ but very carefully. meanwhile the basic is
>C (I do miss the syntax of calling method in Class).

One of the founding objectives of C++ was that you don't pay for what
you don't use. There's no reason not to use C++ as a C-lite, if all you
want is the simpler syntactic niceties. The thing I miss most when
forced back into C is the requirement of declaring variables at the top
of a block instead of where they're first used. I also miss the ability
to stuff a declaration into the "for" construct.

I think the real objection to using C++ in embedded projects is the
relatively chubby implementations. Development environments primarily
target diskful systems where storage is cheap. There's not much
pressure to create slim binaries that reuse common code sequences and
trim unused code from modules. The embedded world is more subject to
costs of mass production, where squeezing the code footprint down will
result in significant reduction of hardware cost when viewed over many

I don't see speed as a big issue, as one can always profile an app and
recode the bandwidth pigs in hand-tuned assembler. Such code is likely
to be a small part of any application.

>    maybe with good JITs will do it the Java way.

Now there's a whole 'nother can of worms. What issues does C++ share
with Java that make both undesirable for embedded applications? Where
might one use one in favor of the other? (My point is not to start a
language war but to compare tools that could dovetail to serve
different parts of an application's needs.)

Kenneth Porter
Systems Engineer
Kensington Laboratories, Inc.
750 National Court
Richmond, CA 94804-2008
Voice: 510-620-0235
FAX: 510-233-5544

             reply	other threads:[~1998-08-14 16:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-14 16:04 Kenneth Porter [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-08-26 10:38 Michael Bruck
1998-08-25 18:04 Kenneth Porter
1998-08-25 11:57 Michael Bruck
1998-08-24 18:39 Kenneth Porter
1998-08-23 18:37 Michael Bruck
1998-08-17 16:43 Kenneth Porter
1998-08-14 10:18 Saffi Hartal
1998-08-12 10:44 Brendan Kehoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).