It's just one of those things where one day you'll be sitting in front of a problem, and it'll suddenly be obvious you need a negative index.
God, I hope not.
God, I hope not.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS XCode3/Xcode4
- Thread starter farmerdoug
- Start date
- Sort by reaction score
You hope that not ? Why not ? If I were sitting in front of a problem, and the obvious solution was to use a language feature, I'd sure as hell hope my language has an implementation of that feature, no matter what it is.
I'm being somewhat factious. Of course, the more tools and options the better. But most of my real problems are in algorithm development not necessarily in coding and as a somewhat (alright very) sloppy programmer, the less esoteric tools I have to resort to the better.
It's been a while, but I once used negative indexes when processing audio samples (or any time-series of samples, actually). The most natural way to express it was as t[-1], t[0], t[1] for some position of t. That's not the only way to do it, but it was the clearest in that case.
I've also used negative indexes to refer to the previous char in a string buffer, with the advancing ptr indexed by -1.
ptr[-1] is the same expression as *(ptr-1).
I've also used negative indexes to refer to the previous char in a string buffer, with the advancing ptr indexed by -1.
ptr[-1] is the same expression as *(ptr-1).
I don't know about your latter example but you get an A+ for the former. I don't foresee needing it anytime in the near future. (My far future doesn't exist) but I'm going to try to use a few of my remaining brain cells to store that example.
This is common in graphics, video and image processing as well. The usual way to do this was to allocate enough extra rows of pixel padding around the image so that all negative 2D indexes were still within valid memory.
Well, my day job involves a lot of imaging processing. Would coding in that manner speed things up?
You won't know until you benchmark your particular code. Removing branches (x+i < 0, etc.) might help the compiler unroll more loops.
Yeah, if you want to learn x86 or x64 assembly language, it can be quite useful. ;-)
----------
LZ77/LZ78-based algorithms like deflate in zlib (used in PNG and Apples zlib compressed .dmg files and .xar (.pkg PackageMaker) files (Software Updates)) require "negative" indices. Or if you want to apply a filter to a CG-image. Many applications...
----------
Unroll your loops, and let the compiler recognize, which loops are "over-optimized". ;-)