Re: [Simulavr-devel] SimulAVR + simulated hardware

[Bill]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russell Shaw wrote:

| <snip> I find the complexity of the C++ language woeful, even tho i
| fully understand it. I find that applications are made more modular
| and easier to understand and maintain if the lower level detail
| parts that need speed and efficiency are done in C, and these
| modules are glued together at a higher level for the application in
| tcl. This also makes it easy for the application to be scriptable
| if required. For pure objectiveness, the higher level app can be
| done in python and the various modules done in C. Any gui interface
| can be done in Tk too.
|
I know I should follow other's good lead and not respond to this, but
I guess I'm still young and foolish:

I agree C++ is complex. At the risk nit-picking a particular choice of
words, I find it highly doubtful that anyone "fully understands C++".
It does, after all, support at least 3 different "languages" rolled
into one(core C++, STL-programming, generic programming and template
metaprogramming). And yes, I know that can be seen as a detrimental
factor that TR is right to consider in staying with C. And finally,
no, C is not more efficient than C++ in any meaningful way. C++ is
almost a superset of C. Any useful technique in C works in C++. Things
that should not be done in C (suspicous pointer conversion anyone?)
are prohibited in C++, for example. These are good for error detection.

This debate could go on  ad nauseum back and forth....at work I
develop real-time safety critical software as well as tools to support
the development of that software. I use C++ in many places. Our
software has become complex enough to benefit greatly from an OO
approach, which C++ supports. (C, Ada and of course assembly are the
other primary languages we use) I can make much stronger claims about
the nature of our software in C++ than I can C code because the
compiler allows more design decisions to be represented in the code.
Then we go further with even stronger static checking via PC-Lint and
similar tools (and verification/validation steps, etc.) Incidentally,
we use template classes to represent memory mapped ports, and another
template class to represent individual or groups of bits within those
ports. The resulting code is what you would write by hand in assembly,
but with a proper class interface to prevent incorrect usage of the
ports (or bits within the port) and making it easy to use the bits
within the ports directly. No more messy macros or explicit masking.

But this is of course an easily debatable topic that I happen to have
strong opinions on. As with any language, it is also easy to abuse C++
and not gain the benefits that are possible...if you know/like C
better than C++, you will likely write better C than C++...I have no
problems with that. It is also useful to note that there is no need to
throw away C code to begin down the C++ path. C++ was carefully
designed to allow incrementally transition to C++ or begin using C++
features.

Now, I am also a newcomer to simulavr and see that TR has been very
gracious on these topics. I don't have a good answer to his question
of "what does the future hold for simulavr".  Being a newcomer, my
vote probably should not carry that much weight here, but my vote
would likely be status quo until the stability of a developer
community behind the C++ version of Simulavr is established. The
codebase is still small enough that this should not be too hard to
swallow later on, if one is merged/abandoned for another. In the
meantime, it would be nice if the two inter-operated in some
way....perhaps sharing an API to simulated hardware attached to a
simulated avr...I'm sure there are some other API's that might be
interesting/useful to agree on.

Unfortunately, voting for a status-quo means that there will be a need
for some way of collaborating on the C++ code if the community becomes
strong enough, leading to the problems TR pointed out of potential
confusion/dilution of resources. I'm not to concerned about that yet.
I like Klaus' goals, though I have some reservation about his
expectations of a complete rewrite down the road (and there are many
ugly, rough edges in the code which Klaus is aware of and has made
conscious decisions to accept in the laudable interest of
progress).....which is another reason I believe giving what amounts to
a fork a chance to prove itself.

Thanks to all who have given consideration to these topics.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAD1EmuZBxYuVmoeoRAraHAKCcedf9jE7udVgdO8jfmXrz+b/FggCbB5vK
MwjDM++ZJAYEBAslU6qLTU4=
=W74N
-----END PGP SIGNATURE-----