Hi,

I'll try to write a faster parser/compiler, which also supports UTF8.

Martin

Hi, I'll try to write a faster parser/compiler, which also supports UTF8.

Are you sure that you want to write a parser? Because that is the part that does the semantics and handles all the statements and does not known about UTF8.

What is wrong with the current scanner?

Peter

Michael Van Canneyt wrote

I think Martin means the parser/scanner in the FCL, not the compiler parser/scanner. The one in the FCL can use some speed updates and improvements.

I mean the parser/scanner in the compiler directory.

Martin

Which compiler version did you look at?

the one used for Lazarus on Linux.

.., otherwise there is a huge risk that code won't be accepted.

that will then be your choice.

Martin

Lazarus can be compiled with both 1.0.x and 1.9.x.

>.., otherwise there is a huge risk that code >won't be accepted. > that will then be your choice.

Why didn't you answer the other questions in mail?

Peter

Hi,

I wrote a Red-Black tree, which seems to be faster than TDictionary, even without spreading items into multible slots.

The Algorithm for rearanging the nodes is faster as for an AVL tree. The disadvantage to a normal search tree is that every node requires an additional Color field, also inserting and deleting is slightly slower because nodes are then rearranged to ensure a N log N search behaviour.

Would the additional space for the Color field in the TNamedIndexItem be a problem,
if the Red-Black Algorithm would be used in Tdictionary ?

Martin

No problem. Go ahead :-)

Peter

Memory hungry people implement red/black in the alignment bits of the pointers:-)