[Gtkradiant] Str and string_t
Sat, 17 May 2003 17:09:21 +0100
This addresses http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=815
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
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
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.