This is the mail archive of the c++-embedded@sourceware.cygnus.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: biggest deterrant to using C++?


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

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

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
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]