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

[I'm posting my reply to the list as I'm sure others are following the
general discussion. Also, please set your mail program to limit line
lengths to 72 columns.]

On Sun, 16 Aug 1998 18:17:17 +0200, Saffi Hartal wrote:

>Kenneth I might be mistaken in some of the things i write but it is the best of my
>knowledge without looking up and checking ... .
>C has it's pitfalls also, but the people i work with know already to avoid them but they don't know with C++.
>the books you write about I'm not familiar with (I'm not really familiar with any books except Dr. Dobb's which i read sometimes), if you have a recommended file\FAQ or link to a sight I'll be happy.

As I said before, look at Meyers' books and C++ Report. When I need a
quick answer to an advanced question, I use
news:comp.lang.c++.moderated . And, of course, if it's related to
embedded systems, there's this list.

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

>What is boilerplate ?! .

The tedious stuff that one writes over and over.

> i understand the fun and ease of use with constructors instead of calling initialization functions. i made a log.h log.c modules that each module automatically register and  hid log level is controlled from the outside (if you want tell me it's nice and easy a bit of macro stuff and a little semaphore for avoiding multiprocess  text become garbage on the screen ). the C++ ability  to call function at variable initialization (like constructor) from outside function scope made the automated registration of modules possible. 

>For me Assembly is not a language, it's a torment. and i hate wizards. i know a bit about MFC work and it's efficient but it's not very clean (many people like it, i don't though i appreciate the code the protects the New and Delete from overrun and such, if you don't have one on your platform i have found one called Fortify it's Ansi and it looks great).

>As i wrote, i use C++ in my code, but my fellowmen which i work with don't,
>the interface between modules is C. it is a bit annoying. so I as you do declare what i want where i want.
>I think that if they would have used C++ we would have encountered a major delay in  the Project. (which is the worst thing that could happen).

There's no point to using a tool you don't understand. One approach
here is to use a C++ compiler but establish coding standards for your
novices that disallow the advanced features until they've been
qualified to use them. Sort of like keeping an apprentice machinist
away from the CNC machines. ;-)

>I haven't noticed  a big buildup of the code in C++ yet, but i look in the future for emerging problems from that direction. We have 2M flash memory and i want to have a lot of code... .

In some situations one is very memory-limited, and it's easy for a
language that's heap-oriented (C++, Java) to quickly consume all
available memory. A poor template implementation can also eat ROM

I'm working on a DSP-based project and DSPs typically get some of their
bandwidth by getting code and data from limited on-chip memory. It's in
such tight environments that a space-efficient compiler is critical.

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

>a C++ routine call has overhead of 1 because it first get the value from the lookup table (get the correct function from the right father ) and then calls the function.

Unless you use multiple inheritance, a virtual method lookup should
take just a couple extra instructions (load vtable pointer, load method
pointer, call indirect), and that should be insignificant unless it's
in a critical loop. Indirect function calls are not uncommon in C, so I
see C++ virtual methods as just a nicer syntax for something I'm
already doing.

>(one of the big pitfalls of C++, is calling a routine virtual in parent overloaded by child from constructor actually calls the father function instead of the child function)

I think we've all been bitten by that one. Have your newbies keep an
eye on the C++ newsgroups and you can watch other newbies make the
mistakes first. ;-)

>I wish we could have Java too, maybe it's just a dream, for sure for embedded a lot of code would have to be entered into the JVM (specific drivers), maybe there we will steal have to have the C++ (or C).

That will depend on the specific application. I think Java is
well-suited for GUI, and possibly for non-time-critical control flow.
It also carries a lot of networking boilerplate, making TCP/IP apps
simpler to code. For example, Java would be good for an instrument that
has to return its results over the Internet (such as a remote weather

For realtime apps, the Java garbage collector is the most scary thing,
as it's likely to be non-deterministic in time. I don't see Java being
used in an engine controller, for example.

Java also lacks C++ destructor semantics that force a resource to be
freed at the end of an object's scope. In Java one must explicitly free
resources, which leaves yet another task for the programmer to forget
to do.

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-17 16:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-17 16:43 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-14 16:04 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).