I hope it's ok to answer my own question.
I believe I have found the optimal (without overcomplicating the problem) data structure for my problem. There was at least minor idiocy on my part for not recognising this earlier. The data doesn't need to be accessed by (x,y,z) but instead by (x, y, range of z (say 0 - 3)). This give a C++ struct as follows:
struct node {
struct node *next;
int zGroup;
int z;
50 bytes of misc data };
I can then address this through a 3D dynamic array (vectors):
vector< vector < vector < node* > > > Data;
Any given Data[x][y][zGroup]
points to the first element of a linked list, the entirety of which is needed every time one element of it is needed. No value of this array is NULL, every one contains a linked-list of at least one element.
The third dimension of the array - the zGroup has jagged dimensions, but with dynamic arrays this isn't an issue. Given the data and computations being performed on it, I know that the max x and y values are set when the file is read and do not change, neither does the number of z groups on any given (x,y) line, the actual z-values of nodes may change, but they will remain inside the same z-groups, giving a constant-sized, fully populated array.
With the way that the file is structured it is also easy enough to page it in and out of memory if I am brought to do this with much larger data sets.
At this point in the development of this project or pursuit, is it more feasible to attempt to learn C++ and the methodology of submitting a patch to browser maintainers for the described implementation; that is, to make required changes at browser source code myself?
It really depends on your commitment to this feature. The spec is still in draft, and you could try submitting feedback, however the most recent feedback was presumably from you, and you have not been answered yet. There will probably have to be more discussion about how the feature is described in the spec, and somebody will have to make the modifications (if it's decided to make your suggested change). As you've pointed out others have supposedly asked for this feature and have been rejected.
I don't think the browsers will accept a PR if it doesn't adhere to the current version of the spec draft, so I think the spec is the first step to get browser support.
Even when you get it in the spec draft, it may take a while for the browsers to review a PR from you, can it may take a lot of effort for you to contribute because you don't know C++, and browsers are very complicated software. If it gets into the spec, it may be simpler to just wait for the maintainers of the browser to implement the new features, but if you're determined to see it through, then by all means contribute the PR! You should decide for yourself if learning C++ and understanding the browser code is worth a PR that potentially will never be merged.
Continue to ask for help from authors of Web Speech API at browsers and, or developers at large, towards completion of the described implementation?
It sounds like you've already done what you can to ask for this to be implemented. You can either let it go, or you can keep trying to get your feature included in the spec. This may involve contacting the editors directly ("why hasn't my message on the mailing list been answered?"/"is the speech api draft dead?")-- it will help to show that others want the same feature. While I agree that the feature sounds like a good idea, the editors of the draft may have reasons why it's not a good idea. I found Kevin Ennis' message to the mailing list, it seemed unresolved to me, but the entire mailing list seems basically dead since they haven't answered your message from a month ago. The draft isn't on the W3 track for standardization. It's really up to your determination what you do, but #2 is definitely the first step.
Best Answer
You seem to be confusing a deque (double ended queue) with a circular buffer.
In a circular buffer you are right that when the buffer is full, the 'one past the last' element coincides with the first element. When implementing iterators for a circular buffer, this needs to be taken into account to avoid confusing an empty buffer with a completely filled one.
A deque can best be visualised as a row of elements where you can add elements at either end. This should also make it clear that there is no way for
end()
to equalbegin()
except for an empty queue, because there is no point where the two ends come together again.