> > 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.
ahh, here's why I stopped doing that. I added
#include "lyxparagraph.h"
to lyxfunct.C, and my prototype does seem to be there
smith:/usr/src/lyx0_12/src# grep GetWord lyxparagraph.h
LString GetWord(int * pos);
but it doesn't seem to get recognized:
LString curstring;
curstring = GetWord(&lastpos);
yields
g++ -c -g -O2 -I. -I. -I../images -I/usr/X11R6/include lyxfunc.C
lyxfunc.C: In method `class LString LyXFunc::Dispatch(int, const char * = 0)':
lyxfunc.C:2182: warning: implicit declaration of function `int GetWord(...)'
make: *** [lyxfunc.o] Interrupt
I didn't have this problem when I returned the character array pointer.
I added the include at the end of the other includes, if that makes a
difference.
I have absolutely no idea how to deal with this (other than going back
to char :)
rick
> 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
--
