> OK, I've fixed up the insert-menu functions.
>
> I've:
>
> 1) added GetWord(*pos) to lyxparagraph. This returns a pointer to a
> text string of the "current" word. "cuurent" means that it looks for
> the first !Isletter() to the left of pos, and continues
> until the next !Isletter() to the right of that point. THis may be
> past the current point. pos is modified to show where the word ends
This one should be changed to return an LString rather than a
character array.
Also, the implementation should use LString rather than fiddling around
in a fixed-size array.
To build up an LString from characters, do simply this:
int i = pos;
LString word;
while (text[i] != whitespace) {
word += text[i++];
}
The advantages are many: The code is easier to read, and therefor
less bug-prone. Also it works without arbitrary limits, and finally,
it is ready for i18n.
Regarding efficiency: The assymptomatic behaviour of LString concatenation
is the same as (or better than) for char-arrays, so there is no reason not
to do this.
Oh, well, I guess it's time for the good old LString plug again:
The obligatory-every-half-a-year LString plug(tm)
-------------------------------------------------
Consider this aside as a general comment, not something directed at you
in particular.
It is a myth that char-arrays are faster than an encapsulated class.
Consider the task of sorting the characters in a string. In C, you
would define a comparison function and pass that to qsort.
In C++, you'd just use sort from the STL.
The C++ implementation would be a lot faster since it does not need
to perform function calls to compare each character, because the
compiler will know what to compare and inline the direct comparisions
into the code.
I have seen measurements that in situations like this, the C++ code
is seven(!) times faster than the C code.
Also, string-concatenation is faster with LString than with strcat
in C, because in many situations we do not need to allocate more
memory: We have that ready at the end of the string.
String-assignment between two LStrings are constant time, rather than
linear-time with char arrays.
The only time where LStrings are slower than char arrays are when they
are short-lived. In situations where we only use the LString as a
temporary container for a c-array. This happens only if not all data
structures are LString, so the solution is to move to LString, rather
than stay with error-prone C-arrays.
Incidentally, we kept the char-array interface in the painter because
of this reason: The basic data-structure in LyX is still a char-array,
and therefor we would require a new operation for every drawn word on
the screen. This is too expensive, so we kept the char * interface.
However, when the basic datastructure in LyX has moved to STL string,
we should get rid of the char * interface, IMO.
So at the cost of a minimal memory overhead (it's constant space),
we gain safety, speed, portability, readability, and more clean code.
In general, C++ can be faster than C. Have a look at Blitz++, which
is a vector/math library that uses template techniques to do real
fast computing. They are the first to obtain speed that is faster
than Fortran for the same task. This has never been done with real
life examples in C while still having readable code.
Bjarne Stroustrup performed some experiments with skilled C-programmers.
He asked them to write a simple function that did first asked for the
login name of a user, and then the host of a machine. Then, these should
be concatenated to form an e-mail string. The "best" programmer needed
seven iterations to get it completely correct with all memory allocation
and deallocation, error checking and all that fidling. In C++, using STL
string, everybody got it right the first time.
The gcc 2.7.x compiler can't handle the STL properly (compare with exe-
cutables more than 50M). This is the reason we wrote our own LString
class. This class has evolved into a very good string class. However,
since gcc 2.8.x and egcs are out, and they handle the STL well, we want
to use the STL string class, because it is even better than our own
string class. Therefor, we are moving the interface slowly towards the
STL string one, and at some point, LString.[Ch] will be redone using
the STL string.
So, by using LString now, you are taking part in the move to STL.
End of aside.
> 3) INSERT_INDEX now gets the current word and places it into the new
> inset before calling edit. As a result, that word shows up in the
> entry line. I'd prefer it be hilited so that any typing kills it, but
> we can't have everything, i suppose. The inset is put at the current
> cursor position, as before. It could easily be set to go at the end of
> the word, but I suppose someone might want a mid-word entry, so i left
> the behavior unchanged.
Rather than adding a new method Edit(int, int, LString), you should
just pass the index word to the constructor of the inset.
Have a look at some of the other insets that do this. I think maybe
the bibinset does it, try to have a look at that.
Greets,
Asger
