[Simulavr-devel] simulavr and C++

[Theodore A. Roth]

I've read all the recent posts suggesting the use of C++ for simulavr and
instead of replying to them all, I'm going to just post this message.

First off, I'm not a C++ programmer. I've been dabbling with it for nearly
ten years and don't see myself ever really coming to grips with all of C++'s
features. Until someone is paying me to write code in C++, I'm not likely to 
spend my free time learning it. I've already invested a lot of time trying 
to master C and python. I also am going to have to invest time learning 
tcl/expect to work with gdb's test suite and I'm not excited about that, but 
I don't have much choice in that matter.

I'm not saying that any language is better than any other. They all have 
advantages and disadvantages.

I'll admit that uisp is C++ code and I maintain it, but I don't think I do
it justice. I also find it very difficult to work on. On the other hand is
avrdude, which I've found that I can dig through and get up to speed much
quicker since I don't have to think in C++. In the long term, I see uisp as
a dead end and once avrdude is has reached parity feature wise, I'll most
likely give uisp up. Avarice is another project I work on that is compiled
with C++. It doesn't use C++ features at all (except for new and delete as
far as I can tell), so it's really just a C program.

Simulavr's current code isn't perfect, but I understand how it works. I've
also been spotting warts while working on the vdev/memory rewrite and have 
either changed them or noted them (with comments) for future fixing.

Klaus brought up a good point about having design discussions versus just
digging in a writing code and then refactoring. I've tried to start the
discussions with two things in mind: to get my ideas in the open and/or to
motivate someone to write some code with or without using my ideas.  It's
not my intention to discuss the design for ever, but more a chance for
others to say the design is crap before I waste time implementing crap.
Another thing I've noticed is that as more features are added it becomes
increasingly more difficult to refactor out bad design decisions. This may
be a consequence being written in C, but I can't imagine it not being a
factor in C++ too.

So, what does the future hold for simulavr?

There's my C version. Regardless of what happens in public, I will continue 
working with my code. It does what I need for my continued work with gdb. It 
is very important for me to have a 100% understanding of the simulator so 
that I can know when it's a bug in the sim or a bug in gdb.

Then there's Klaus' C++ version. It looks like he has done some very
interesting work there. I'm sorry that he couldn't achieve what he wanted to
without the fork, but the GPL has given him the right to do what he wants
with my code and I am fine with that.

I'm going to leave it to the community to pick the direction they want the
public simulavr to go. Here's the choices:

1: Stick with C. If this is the case, I will continue as developer and 
   maintainer of simulavr on savannah. Of course, in this case, Klaus has 
   every right to continue with his work.

2: Convert to C++. If this is the case, I will give the savannah site over 
   to who ever steps up (be that Klaus or who ever). I will step aside and
   it is very unlikely that I will be involved with C++ development since my 
   C++ skills are not up to par and not likely become so until there is some 
   financial incentive for me to do so. My current job entails C and python 
   programming and I just don't have the time right now to learn C++ to the 
   proper level of proficiency.

3: Fork into public simulavr (in C maintained by me) and public simulavr++ 
   (in C++ and maintained by Klaus and/or others???). I really wish to avoid
   this as it will just confuse users as to which one to use. It would also 
   create some confusion as to where to go for help and/or support. Of 
   course, choice is not a bad thing, but in this case, I think the 
   community is better served with a single focused effort since simulation 
   of all devices with all features with external interfaces is going to be 
   difficult and lots of work. A newbie should only have to think about how
   to get his avr code working, not which simulator to use because one 
   provides feature set X versus Y.

My long term goal is that there will be a single, free, publicly developed,
AVR simulator that will be the better AVR Studio or any proprietary product.
I don't care how that goal is achieved, either 1 or 2. I don't think that 3 
will help that goal.

I'll be more than happy to turn over the simulavr savannah project to other
developers if the community would rather see a C++ simulavr. On the other
hand, I would be very disappointed to turn over the project and see a short
flurry of activity in converting to C++ (or bringing in Klaus' code) and
then have everyone loose interest. Also, note that taking over the project
means taking over the mailing list, the download area, the project admin
duties, the web site, answering user questions, etc. All that takes
someone's time.

Ted Roth