Things you shouldn't do: Two pointers in one field.
en.wikipedia.org
Things you shouldn't do: Two pointers in one field.
1–10 of 21 posts
Re: Things you shouldn't do: Two pointers in one field.
#2Haha, XOR'd pointers to compress a doubly-linked-list to use a single pointer for both previous and next references.
Brilliant and deadly. Gotta love it.
Re: Things you shouldn't do: Two pointers in one field.
#3Another reason not to do it is that in the modern era, computed pointers tend to stall pipelines.
Re: Things you shouldn't do: Two pointers in one field.
#4Someday you might have to program in an actual resource-constrained environment, and you'd understand why sometimes you have to do stupid things to meet your constraints.
Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit.
But maybe you should stick with the Ruby. I hear there's money in that.
Re: Things you shouldn't do: Two pointers in one field.
#5Someday you might have to program in an actual resource-constrained environment, and you'd understand why sometimes you have to do stupid things to meet your constraints. Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit. But maybe you should stick with the Ruby. I hear there's money in that.
Last time I actually needed to do this, I allocated memory in larger chunks instead, and made a linked list of those chunks.
The number of situations where this particular solution is the best solution is really small!
Re: Things you shouldn't do: Two pointers in one field.
#6Someday you might have to program in an actual resource-constrained environment, and you'd understand why sometimes you have to do stupid things to meet your constraints. Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit. But maybe you should stick with the Ruby. I hear there's money in that.
Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit.
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.)
Re: Things you shouldn't do: Two pointers in one field.
#7Someday you might have to program in an actual resource-constrained environment, and you'd understand why sometimes you have to do stupid things to meet your constraints. Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit. But maybe you should stick with the Ruby. I hear there's money in that.
One of the trickiest 'resource constrained' code I ever did was an index across 100,000 hotels in 64K of RAM on a whole bunch of criteria, 100's of them. From swimming pool presence to dog walking service (and pets permitted or not) and so on.
Obviously, you can't really do it so I first pre-sorted the hotels with some common criteria in large chunks, then sampled random bits from the rest of the criteria to fill the memory based portion of the index. When a query would come in a mask was made for the various criteria in the same way as during the indexing, and this mask was then used to get the indices of hotels that might be right, candidates so to speak. Then the candidates would be loaded from disk and checked against all the criteria and an answer would be returned to the caller. It worked pretty good, the disk block caching mechanism really saved the day.
This was on a QnX system before they had a 32 bit/large model version...
That's when programming is fun!
Of course 64K is still not really 'constrained' ;)
Re: Things you shouldn't do: Two pointers in one field.
#8Another reason not to do it is that in the modern era, computed pointers tend to stall pipelines.
If you're programming for an embedded system with severe memory constraints and a simple pipeline, this could be worth doing.
Re: Things you shouldn't do: Two pointers in one field.
#9Let's just hope somebody doesn't try to get sneaky and make a circular XOR linked list. It'd be hard to start a traversal from head = )
Re: Things you shouldn't do: Two pointers in one field.
#10Someday you might have to program in an actual resource-constrained environment, and you'd understand why sometimes you have to do stupid things to meet your constraints. Use half the memory -> buy a smaller memory chip per unit -> spend less per unit -> profit more per unit. But maybe you should stick with the Ruby. I hear there's money in that.
Last time I actually needed to do this, I allocated memory in larger chunks instead, and made a linked list of those chunks. The number of situations where this particular solution is the best solution is really small!
The name for this is an "Unrolled linked list," in the same semantic fashion as an unrolled loop. Congratulations!