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.
signature.asc
Description: Digital signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
