> Andre> Most people want to get their job done. If they get it done in > Andre> 28 instead of 36 minutes they are usually happy... > Hmm... I don't understand why std::string is so much worse. Is it solely because it is a template, and some compilers can't handle those as well as non-templates?
It would seem the ideal place to fix this would be on the compiler side or the standard library side, though that probably won't happen tomorrow. If non-standard-library-provided string must be used, why not take it from some standard library, de-templatize it (search/replace T char, fetch a little stuff the class migth use from other files) and use it as a drop-in replacement for std::string. Using the real std::string is still a compiletime option. Nomatter where the string class comes from, one could add the needed asserts by enheriting from it (or making a wrapper, though that seems to me to be more (potentially bug inducing) work than is necessary). This way, there can be asserts while still using the string class to interact with third party code (provided std::string is chosen at compiletime). If the compile time and size disadvantages are too great, at least the string class that is used has seen extensive use and as such is probably without bugs (I think I saw someone report a bug in lyxstring the other day). If there are any, other people will fix them, or the class could just be taken from another standard library. It is certain that the provided string will work exactly like a std::string would. If at some time, providing a non-template string becomes unnecessary for whatever reason, just remove it and the asserts will still be there. Hmm... I must admit I don't have much experience working with large programs. This seems to me to be an improvement in any case, though. Of course, this is all assuming that the bloat is in fact only caused by std::string being a template. --- Bjarke Roune
