[Gtkradiant] [Bug 815] remove dupe and useless string_t from include/qertypes.h

[gtkradiant@zerowing.idsoftware.com]

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=815





------- Additional Comments From spog@planetquake.com  2003-05-17 12:11 -------
I wrote string_t a while ago for use in my own projects which use stl
heavily. Below are the reasons for including it in radiant..


Issues with Str

- dependencies
printf method is bloat, either requires glib or is limited to 1024 chars (with 
no buffer-overrun check)

- bloated public interface not documented and non-standard (inherited from MFC 
CString?)
TrimLeft, TrimRight, Left, Right?
algorithms like Find can be implemented with iterators and non-member functions
does not provide useful STL stuff like a constructor to create a string from a 
range of chars

- questionable implementation
written procedurally (everything in one function), not functionally (private 
helper methods to do common stuff), causing unnecessary duplicated code
m_bIgnoreCase can be pushed outside the class
g_pStrWork is completely pointless


Issues with string_t

- name does not obey coding convention
- should not be in qertypes.h


Good things about string_t

- provides interface compatible with std::string (ie. code that uses string_t 
can use typedef std::string string_t)
- completely STL-container-safe (ie. can be copied safely)
- functionality is clearly limited to preserve performance (ie. does not 
provide operator+=)
- clean, simple, functional-style implementation


Conclusion

string_t provides a very simple implementation of part of std::string's 
interface, it does not replace Str.
string_t and Str should both be cleaned up and grouped in the same library, so 
they can share parts of their implementation.