[Gtkradiant] Str and string_t

[Timothee Besset]

Why not putting that on the bug item.

SmallPileofGibs wrote:

>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
>
>- 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.
>
>
>_______________________________________________
>Gtkradiant mailing list
>Gtkradiant@zerowing.idsoftware.com
>http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
>
>
>  
>