On Sun, Oct 24, 2010 at 11:01:53PM +0200, Vincent van Ravesteijn wrote: > > I took a look and this looks good so far and a bit simpler than what I > > thought would be necessary but I haven't tried to test it yet. > > > > Please test if you have time. It was a long time ago for me too that I > worked on that code. > > > I do remember that someone commented that they didn't like the use of > > > > boost::uint32_t > > > > and that (IIRC) just using an unsigned int with an assertion about its size > > should be fine. > > Yes, I read that Andre mentioned this as a personal preference. Well, > if he still feels this should be changed, he will shout again ;). > > Besides we use boost::uint32_t in more places in the code, so if > anyone changes this, please change it everywhere. Besides that, we use > more datatypes from boost: boost::int32_t, boost::crc_32_type. I think > there are people that want to get rid of boost in the end, but then > all these datatypes should be replaced.
The quest to keep LyX compile times and dependencies reasonable and to reduce the level of overengineering was some major sink of time in the past and I think that any further activity in that direction (including writing this mail here...) just makes it worse. I don't have problems with using boost in the implementation _if and only if_ it provides actual benefits over less intrusive alternatives. I do have a problem with needlessly sprinkling 'boost::' over interfaces, especially if it does not add any value. Given that there seems to be an unconditional "typedef unsigned int quint32;" in qglobal.h I don't think there's any platform supported by current LyX that could not use 'unsigned int' (and an static assert in some implementation file for the unlikely case some ILP64 zombie raises its ugly head again. And if that happens, using <cstdint> would still be a better choice...) Anyway, I don't think I should have a say on such issues anymore. Andre'
