Hi Kim,
On Mon, Oct 13, 2008 at 8:45 PM, Kim Gräsman <kim...@gm...> wrote:
>
> On Mon, Oct 13, 2008 at 14:39, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> So with every template that needs a new tag, but shares traits with
>>> existing classes/templates (typically string, ostringstream, char_),
>>> we have to duplicate these definitions.
>>>
>>
>> Do you really need a new tag?
>
> Nope, I don't think so, I was just wondering whether this was the
> issue. I got confused with the http::message_tag.
>
Okay. :)
>> The reason we have a http::message_tag is because there are traits
>> supported by http::message_tag that don't support the default_ tag.
>> It's also a point of customization intended for extension -- so if you
>> want a different storage mechanism for HTTP Messages (like unordered
>> multi-maps for headers, etc.) then you create your own tag and
>> specialize the traits you want to support explicitly.
>
> Yes. But since that tag will be used throughout the implementation,
> passed on to basic_request, basic_message, etc., I'd have to
> specialize all traits for the new tag, even if I'm only changing one,
> right? I think that's where my ability to picture this breaks :)
>
Actually, not really -- or as far as I recall, not at all.
Consider the example below:
template <class Tag>
struct string {
typedef std::string type;
};
template <>
struct string<tags::wide_default> {
typedef std::wstring type;
};
If you really needed to customize with your own tag, then you can
override the default implementation (unspecialized version). :-D
>> I'd even think we should promote the traits for the message class to a
>> higher traits namespace, to be (re)used throughout the project. ;-)
>
> Right, I think that makes sense, that was my original problem.
>
Okay. In the meantime, I think it's merely a matter of including the
correct traits from network/message/traits and then in the future
doing a more far-reaching refactoring of the source. :-)
>>> Does that even make sense? :)
>>
>> I think I'm still missing details as to why you need a separate tag
>> apart from the default_ tag that's already available.
>
> I don't think there's a reason. I think I'm beginning to see how this
> fits together, but it's still a little blurry :)
>
Okay. I hope the above example helps. :-)
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
|
