> What we have here is some basic point for generic > libraries. Resources > are ram, flash, stack and cpu cycles. Which one is the most > important? > I guess the one you run out of first.
I fully agree here. And more, cpu cycles can be important in some cases, but it is the only problem that can be solved by waiting. If you're out of memory, the program won't run at all. My suggestion to change (or add another) print.jal was made to reduce on *all* of the named resources. I did not succeed (yet) in reducing flash and stack for dwords, however. > I think there is litte problem with a dword that takes > 500ms if you > only print it once a day... Agreed! :-) > > Maybe a documentation header for every function inside > libraries can > > help actual and future developers about readability. > I do not object to more complex algorithms if the result is > better. My > point is complex algorithms are more likely to catch a bug > when > implemented. And on average, 60% of each bugfix also > introduces a new > bug. So I disagree with the view that code is only read > once and > clarity is not an issue. It is important and gets even more > important > if complexity increases. Also right. My suggested algorithm is not really complex, it merely lacks the elegance of the current version ;-) And, concerning the print library, it handles a finite set. It will take weeks or so, but we can try every one of the 6.442.450.944 numbers it can process and check if the result is correct. Of course, in general I agree with your points. Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
