simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Uniform the code


From: Knut Schwichtenberg
Subject: Re: [Simulavr-devel] Uniform the code
Date: Sat, 11 Apr 2009 23:13:41 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Hi Michael,

Michael N. Moran wrote:
> I write embedded C++ code most days... so I can probably
> help to clarify my choices.
I'm far away from code most days - I did several project management jobs and
currently I have to do with system designs on a high level. So I try to
understand most of the comments and assess them as in a normal project ;-).

>> While M128 is okay M48 should be simplified.
> 
> I'm not sure what you mean by simplify.
Based on the ability of the M128 was the catch all CPU and the M48 is only a
simplified part of the M128 (less abilities).

> As an outgrowth of my background in embedded systems,
> I generally try to avoid the use of dynamic memory
> allocation. In this case it is mostly a matter of
> avoiding common errors:
> 
> 1) The compiler will complain if a member variable
> is not properly initialized. From the compiler's point-
> of-view, pointers do not require initialization, and
> therefore runtime errors can result if the developer
> forgets to initialize the pointer.
> 
> 2) Memory leaks happen if member pointers are not
> explicitly deleted in the class destructor. Again,
> this is another source of run-time error that is
> avoided by using member objects rather than member
> pointers-to-objects.
I understand your comments and they sound very reasonable. When there is a
chance to avoid user errors by a runtime system, I'm your man :-).

> In my defense, I will say that when I submitted this
> code in 2005, it worked nicely. I suppose some kind
> of bit-rot happened between then and the time it was
> finally merged last month. :)
That's not my point, but here are lots of ideas around how to proceed with
scripts and so on and that should be done unique - sorry that's the influence of
business background :-).

> I think this is a bit of an over-reaction.
Ahm, Joel's last problem was a typical copy&paste problem in the way "it worked
in the example - copy it and it works here". Typical human - I'm a specialist
for this too :-).

> My old age (52 years) respectfully disagrees ;)
Touche :-), but YOU are the C++ man not me :-).

> I think this is simply a lack of familiarity with C++
> rather than a matter of good vs evil. While I would agree
> that consistency is a good thing, it is not the *only*
> thing.
Fully agreed, especially if there is a chance to avoid errors.

> Ultimately, this is a matter of style, but I believe
> there are good reasons for my atmega48 choices.

Thank you, for the detailed explanation. Personal I take it as a lesson in
C++... And we are never too old to learn.

Knut




reply via email to

[Prev in Thread] Current Thread [Next in Thread]