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<whatever>
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 <string>) 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.
