Re: [Simulavr-devel] SimulAVR + simulated hardware

[Bruce R'. Miller]

On Sunday 04 January 2004 04:58, Klaus Rudolph wrote:
> Hi list,
>
> A happy new year to all members and thanks for the work in the past.
>
> Again I read here that there is a need for a more completed simulator.
> As I wrote a long time ago (last summer I think) I have reimplemented
> the
> simulavr in c++ and added some functionality which is actually requested
> in this thread here. So I offer my work again here and give you a actual
> state
> of my work, if the team is interested in :-)

Klaus,

When i first used Simulavr a while back there were a number of features that I 
wanted to implement.  Unfortunately the code is writen in the ancient C 
language and every time I went to make a change I had to figure out how to 
work around the deficiencies in the language.  I have become spoiled by C++.  
Don't get me wrong here; I'm no candy-assed Java programmer.  I've spent most 
of my career writting in assembler, BLISS-32 and C.  I've spent the last 
three years working in C++ on embedded systems.  It permits me to do a lot of 
things that C is simply not expressive enough to do in a reaasonably small 
amount of space.  Every time I thought of something to change I was stymied 
by C.  Not that it couldn't be done in C.  It just didn't seem to be worth 
the effort to change half a dozen files when I would only need to make one 
change in a single C++ module.  This sort of project (large, modular, many 
contributors) simply screams for C++.  You can see where Ted is simulating a 
virtual object system.  Why not just do it in C++ and get the benefit of the 
compiler's syntax checking?  A lot of people seem to have the mistaken 
impression that C++ is bloated and inefficient.  They must be thinking of 
Java.  C++ is more efficient than C in that it is more expressive and this 
allows the optimizer to do a better job.  Some people argue that C++ has 
extra overheaad for virtual function calls.  Sure, if you use them; you don't 
have to.  If you try to simulate them in C you will be even less efficient.

I appreciate that Ted wants to stick with C because so many programmers are 
familiar with it.  I just wanted to throw in my vote, along with yours, for 
C++.

-b