[Edbrowse-dev] tags[] encapsulation

[Edbrowse-dev] tags[] encapsulation

[Karl Dahlke]

With Chris' patch in hand, he has passed it back to me, and I am working on it,
but from a slighly different angle.
My first push, now in the system, is strictly for encapsulation purposes.
It moves the tags array into js state, so that I can, in the future,
make it a c++ class if I wish.
Instead of putting all the tags on htmlStack,
then copying them over to the tags array, I might skip the middle step
and put them straight into the tags array,
which is already tied to the current window.
In that case I would want tags to be the c++ construct,
and now it can be, because it is part of that world
that is only seen by the cpp files.

Chris used the list class, but I'm thinking more about the vector class.
Once the tags are built by the browse command, more tags are rarely
if ever generated.
Resizing doesn't happen.
But random indexing into the array happens all the time.
Every hyperlink, every field in a form,
every click of a button, I jump to tags[n] where n is
a number hidden behind that less than sign.
So I think it would be perfect.
It's not much different from Chris code, still an iterator to loop through,
so mostly the same just easier random access.
Well I'm not going to start that right away, I want to play with
what I've done so far and make sure I didn't break anything.

I also fixed a bug that was there before, that I ran into.
The state field in jsrt for example, type

i=mic

You get question mark but the error is some meaningless error message,
instead of what it should be,

multiple options contain the string mic

Course I thought I caused this bug with my work,
but no, it was there before, so an easy one line fix.

Karl Dahlke

Re: [Edbrowse-dev] tags[] encapsulation

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> Chris used the list class, but I'm thinking more about the vector class.

Sounds like the way to go.  I hadn't realized that vector completely
removes the need for that temporary data structure!
Also, don't worry about pushing elements onto the end.  It's very
efficient (constant time), and it doesn't call realloc on every push.
It doubles the capacity with each realloc, though I'm sure that's an
implementation detail of GNU's STL.

-- Chris