Combining a couple of emails into one...
| On Tue, Apr 09, 2002 at 01:26:37PM +0200, Lars Gullik Bjønnes wrote: >> I want to use C++ so I prefere the latest compilers that have the >> implementations that conform best to C++. I also want to use the C++ >> standard libraries... The trouble is you don't control what compilers others have. In particular you don't control what users of LyX will be trying to compile with. André did a survey not that long ago that showed most people were using 2.95.x and it didn't seem likely that they'd be upgrading anytime soon. One of the most common complaints we get is about the massive disk space required for compiling LyX. I was talking to a mate of mine about this last night and he suggested we should rewrite LyX in Perl (or Python if we really must) since speed isn't really an issue for most of LyX and we'd have access to all of CPAN and our existing code to speed development. I couldn't convince him to work on reLyX though :( On Tue, 9 Apr 2002, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | On Tue, Apr 09, 2002 at 02:01:48PM +0200, Lars Gullik Bjønnes wrote: > >> | Other people have other goals. Sometimes most goals can be reached if > >> | everybody moves to somewhat less dogmatic point of views... > >> > >> As in "don't use modern C++ features"? > >> and "Don't use templates?" > > > | No. As in "think about what others think". Well, I'm more for thinking about what features cause problems. Compile times have blown out to be nearly ten times longer than they used to be two years ago. It would be interesting to know how much of that is due to the now extensive use of STL, the extensive use of templates in the frontends/, the use of recursive make (we now have many more directories to recurse through than we did then), the use of intermediate linking, the use of Pimpl and other idioms and finally the use of automake (it generates our makefiles after all). There's probably a Masters or a PhD dissertation in the above so I doubt even a fraction of it might get done. I do however hope that such points will be considered in future cleanup work. > | I am in general in favour of modern C++. But it is like 'make it as > | simple as possible, but not simpler'. > > | Use modern C++ if it does not hurt people seriously. A bit of pain is > | probably ok, but not too much. When compile time issues start to put > | people like Juergen off it is bad for everybody. Including you. > > Then we should work at getting faster compiles, not to change the > features used from C++ or its library. At present I feel that using > lyxstring as a cushion to not do anything about the organization of > files/libs/structures(/whatever) since the compile times are ok. I'd > rather force std::string and from there work to get the compile times > down. I don't consider the compile times with lyxstring acceptable either. However, the combination of benefits it brings is useful -- particularly if you don't have that extra 100MB of disk space per tree (and remember you say you usually have three trees -- I tend to have two). You've made some small advances in the compile time and footprint of late and despite the pain they are appreciated. However, they have hardly scratched the surface. I'm sure this experience is what has lead you to your statement above -- fiddling with the linking made little difference so it must be the code (and the recursion) that has made for the longer compile times. > A lot of LyX code is not nice at all, and makes the compile really > slow. (~2000 line functions...) Many of those existed two years ago. Now some of them have been shifted into Pimpls so they don't get compiled everytime something minor gets changed. > | For me it depends on how sloppy this "sloppy" is... > > for me going via char* always when using C++ apis, is pretty > close... Or unfortunate due to the design of the library in use (they tie their stringstream tightly to their string implementation for optimisation reasons only I hope). Allan. (ARRae)
