On 24 January 2011 08:20, Dean Michael Berris <mikhailberis@gmail.com>wrote:
On Mon, Jan 24, 2011 at 9:51 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
On Mon, Jan 24, 2011 at 7:50 PM, Artyom <artyomtnk@yahoo.com> wrote:
From: Dave Abrahams <dave@boostpro.com>
Who says we need a c_str()?
Almost everybody who uses any kind of API that does not has direct uses of this string and this is as almost every API around...
Right, but what's keeping that person from creating an std::string from this hypothetical `boost::string` if they really need a c_str()?
Do you mean besides poorer performance and greater complexity of use?
Isn't it too early to discuss optimization tricks, before the interface has started to take form? I looked at the string_proposal, and if Boost is going for a distinct utf8 type (in whatever form), I think it should be built on something not directly tied to utf8. namespace boost { template<class Encoding> class string { public: typedef some_iterator_base<Encoding> char/code_point/character_iterator // Disclaimer: I'm not familiar enough with unicode terminology to know what kind of iterators needed, and how they relate // to properties of the encoding. template<class Iterator, class OtherEncoding> string(Iterator first, Iterator last, OtherEncoding); // Add other convenience constructors from ranges here, taking the encoding as separate parameter.. template<class OtherEncoding> string(string<OtherEncoding> const&); string& operator=(string& const) // Only allow assignment of same encoding allowed. template<class Iterator, class OtherEncoding> void assign(Iterator first, Iterator last, OtherEncoding); template<class OtherEncoding> std::string to_string(OtherEncoding const&) const; } } usage: namespace encoding = boost::string_encoding; // Or something cleaner namespace boost::string<encoding::utf8> s_utf("Hello world", encoding::latin1())); boost::string<encoding::latin1> s_latin1(s_utf8); FILE* f = boost::fopen(boost::string<boost::string_encoding::utf8> const&); Boost could have as policy that interfaces should take boost::utf8 and not bother with implementing any other encoding (but still support updating the Encoding concept, so that other encodings can be expressed). In future, a theoretical layer built upon proposed Boost.Locale could expose more encodings to use with boost::string. /me also ducks and covers (: - Christian