On Sat, Mar 01, 2014 at 09:00:07AM -0500, Karl Dahlke wrote:
> Well the tags are built in a growing linked list as the page is parsed,
> but at the end of parse I plop them all into an array,
> so it is easy to grab tag 243 (example), just index the array,
> because the text in your buffer actually has encoded
> 
> tag 243 {go to this link}
> 
> You don't see tag code 243 but it's there,
> and it is accessed when you go to that link.
> 
> If we want tags to continue to grow after page parse,
> new tags because of javascript creating html structures etc,
> then we want something with the dynamic power of a linked list or a tree
> but also an easy way to index like an array.
> Not sure if C++ list has this much power, or vector,
> but in C there wasn't anything, which is why I made the compromise I did.
> Anyways we might be able to forget the array and stay with the c++ list,
> and use its power to move forward.
> Create tags whenever javascript tells us to,
> and they can have parent links inside them to define the tree structure
> of forms and tables and so  on.

Yeah, I know vectors will do this for us,
with the allocation policy being implementation dependant,
but usually not too bad I think. In C I'd implement this manually using realloc
but as we're using c++ for the js stuff we can probably put the tags in a vector.
The index into the tag vector for creating the tree structure sounds kind of
nice and prevents a lot of pointers being passed around.

What this means in terms of changes I think is that we stop using the list
class (is this ok to do) and change tagarray from an array to a vector<htmlTag>
(not sure of capitalisation off the top of my head),
then use tagArray.push_back to add tags.
The parent links in the tags would be size_t variables,
and each tag would also need to maintain a vector of indices to its children
(of type vector<size_t> I think). This is a little messy,
but I'm not sure of a better implementation right now as efficient tree
traversal requires an easy way to work out what a tag's children are.
This implementation would allow that whilst keeping the efficient indexing
required for normal browsing.

The reason I'm using size_t for the parent "links"
is that they'll be indices into the tag vector which means that,
if in a realloc the whole lot gets moved,
pointers don't suddenly become invalid etc.

Cheers,
Adam.