Subject: Re: [boost] [General] Always treat std::strings as UTF-8
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-01-19 14:19:57
On Wed, 19 Jan 2011 15:16:48 +0000
Alexander Lamaison <awl03_at_[hidden]> wrote:
>>> I meant to mention this: please, no ;) Can we make it .raw()
>>> or .str() or something, anything but an operator overload?
>> operator* has a long history of providing the contents of a variable,
>> even in C, and is a lot less typing to boot. But if you have any
>> technical arguments against it, I'm listening.
> operator* in not about providing the contents of a variable, it is
> about dereferencing something that points to an address, be that a
> real pointer, a C++ iterator, etc.
In C, that's the case. In C++, it isn't; very few iterators are
implemented as raw pointers. Boost.Optional isn't either, and I believe
I've seen other types that have adopted the same idea.
> utf8_t is just a class holding it's internal data as a std::string.
> In a similar way to std::stringstream which gives access to its
> internal string via .str() or std::string which serves up a raw char*
> string via .c_str().
There's certainly room for something like .raw() or .str(), but I'm
partial to keeping operator* too.
> While we're questioning cosmetic details, I'm wondering about the
> choice of utf8_t vs utf8 or utf8_string. What does the _t signify? I
> was under the impression that _t meant typedef; for example wchar_t
> started life as a typedef rather than a primitive data type.
That may have been the original intended meaning, but wchar_t is a true
type of its own nowadays, at least on the compilers I use. I read it as
a shortened form of "_type" now.
-- Chad Nelson Oak Circle Software, Inc. * * *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk