Re: poking around
On Wed, Oct 31, 2007 at 08:59:23AM +0100, Abdelrazak Younes wrote: > Andre Poenitz wrote: >> I wonder how much resistance the (re- ;-)) introduction of a >> 'real' lyx string class would meet. >> Could be as simple as a struct wrapping a std::string >> and delegating all of the work to std::string. >> The main advantages would be 'declarability' (i.e. class DocString; >> would suffice in lots of places where we have #include "docstring.h" >> (and consequently ) nowadays), > > If this is the main reason I am not sure it is really worth the extra work. > But you are free to spend your coding time any way you like ;-) > >> and the possibility of having >> convenience functions (i.e. stuff from lstring, but also things like >> 'ends_with()' or such in the class. > > This I agree would be nice. I don't like all the freestanding functions. > >> There should be no performance penalty as all the delegation would >> quite probably be inlined, i.e. the ninary might be even identical. > > Are you sure about that? I would check, of course. Andre'
Re: poking around
Andre Poenitz wrote: I wonder how much resistance the (re- ;-)) introduction of a 'real' lyx string class would meet. Could be as simple as a struct wrapping a std::string and delegating all of the work to std::string. The main advantages would be 'declarability' (i.e. class DocString; would suffice in lots of places where we have #include "docstring.h" (and consequently ) nowadays), If this is the main reason I am not sure it is really worth the extra work. But you are free to spend your coding time any way you like ;-) and the possibility of having convenience functions (i.e. stuff from lstring, but also things like 'ends_with()' or such in the class. This I agree would be nice. I don't like all the freestanding functions. There should be no performance penalty as all the delegation would quite probably be inlined, i.e. the ninary might be even identical. Are you sure about that? We will need indirections for begin(), end(), iterators, etc. I am also worried about the place where we assume that the element are stored in contiguous memory (things liks &s[0]). These properties are used in a number of places for performance reason. The main problem I see is that some people will not be happy for political rather than technical reasons. I am not interested in politics (anymore) :-) Abdel.
poking around
I wonder how much resistance the (re- ;-)) introduction of a 'real' lyx string class would meet. Could be as simple as a struct wrapping a std::string and delegating all of the work to std::string. The main advantages would be 'declarability' (i.e. class DocString; would suffice in lots of places where we have #include "docstring.h" (and consequently ) nowadays), and the possibility of having convenience functions (i.e. stuff from lstring, but also things like 'ends_with()' or such in the class. There should be no performance penalty as all the delegation would quite probably be inlined, i.e. the ninary might be even identical. The main problem I see is that some people will not be happy for political rather than technical reasons. Andre'
