On Mon, Oct 13, 2008 at 8:32 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/10/13 Kim Gräsman <kim...@gm...>
>>
>> I wonder if what Glyn is looking for is something like:
>>
>> template <> char_based_traits<network::tags::default_> {
>> typedef std::string string_type;
>> typedef std::ostringstream ostringstream_type;
>> typedef char char_type;
>> };
>>
>> so that related traits are defined together, and orthogonal traits
>> separately. Just guessing, though. But it doesn't make intuitive sense
>> to me to specialize them separated from each other, when they're all
>> based on the definition of char.
>>
>
> Yes but I want to go further and say why can't we used std::char_traits
> directly? I understand that this prevents us from using our own string
> types that don't use basic_string, but if we're going to use ostringstream
> internally anyway, why do we make it more difficult for ourselves?
>
Okay, the reasons for the additional layer of indirection are:
1. To support non standard string implementations and consequently
string buffer implementations (think MS CString and CStringBuffer (?)
).
2. To be able to customize the ostringstream implementation on a
per-tag basis (for example, a standards conforming but Boost.Pool
based ostringstream implementation, or a Boost.IOStreams based
implementation, etc.) but still uses standard strings for the type.
3. To be able to switch implementations globally eventually through
compiler macro's (for example, in some systems tags::default_ may
specify different types for string, ostringstream, etc. (think MS and
playing with MFC/ATL, or playing with ICU buffers for example, and Qt
strings, etc.)).
So it's not really "making it difficult for ourselves". It's preparing
for future eventualities really. ;-)
Currently, if you look at the http::client code, it makes a lot of
assumptions hard-coded as far as types are concerned. There is no easy
way of currently supporting wide character transfer support over the
wire, for which we'll need to factor out the string types, the string
buffer types, and even the literal caracter types/values. So that work
still needs to be done, and the best way to go about it really is to
make the string buffer, string, and character literal types/values
customizable on a tag.
There will also have to be special conversion handlers because for
example getting raw strings over the wire may require conversion from
7-bit characters to wide characters, and even special transfer
requirements (think compression and proprietary encryption support)
which I am anticipating will come as we go along. ;-)
> Taking the long view and we target eventual inclusion into boost, would it
> be better to use the standard way of doing this? cf. Boost.Filesystem?
>
In this vein, I think it's better we go about traits the correct way
-- which is like how Boost.Type_traits does it, one trait accessor
(type) at a time. :-)
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
|
