Re:Things you shouldn't do: Two pointers in one field.
by xilun666 on Monday May 17, 2010 @03:40AM
(#1353815)
You seems to think most computers are complicated, with huge amount of memory needing dedicated and scalable components.
This is not the case. Most computers are tiny; the kind of "you've only got 1kB built-in and non-expandable memory" tiny (yet only if you're lucky). And most of those computers are indeed programmed correctly, despite using a number of classical trick like xor linked-lists (the program is small, so really checking it, even if it contains tricks, is doable).
Re:Things you shouldn't do: Two pointers in one field.
by babycakes on Monday May 17, 2010 @02:20AM
(#1353711)
> buy a bigger memory chip per unit, adding one dollar to the cost -> charge $1 extra for your $300 unit
Devices containing little enough memory where techniques like this are useful rarely cost $300 per unit.
Re:Things you shouldn't do: Two pointers in one field.
by alextingle on Monday May 17, 2010 @03:15AM
(#1353782)
There's no reason code using this technique needs to be buggy. You've got a list of things to test for right there.
Or: use twice the memory -> buy a bigger memory chip per unit, adding one dollar to the cost -> charge $1 extra for your $300 unit -> spend less money defusing "your product sucks because it crashes all the time" support calls -> profit more per unit.
But maybe you should stick to hand-rolled assembly. I hear there's geek cred in that.
(But actually, there is a middle ground -- something like Atom: http://hackage.haskell.org/package/atom. You get type safety guarantees at compile time, and you get a minimal runtime, lowering hardware requirements.)