Re: [cpp-netlib-devel] Dependence on std::string

[<rhy...@gm...>]

Hi, Glyn

I am recently working on a binary protocol oriented network framework
based on ASIO in my project. So I do care more about a binary protocol
oriented message type. so I have once asked Dean a question during a
private communication:

    What's the granularity of the Tag template parameter of
    basic_message<> template? One tag per message type (I means
    text/binary here) or one tag per protocol?

And Dean replied:

    The Tag template parameter is meant to differentiate the message
    types -- for easy extension. That means, to be clear, the message
    tags I envision are:

    tags::unicode
    tags::text (tags::default_)
    tags::binary
    tags::stream
    tags::serializable_text
    tags::serializable_binary
    tags::serializable_xml

    Among many others I haven't thought of yet. :D

    They are tags, because I don't intend to put the overhead of an
    abstract message class as the base class for all the message
    types.  That allows us to implement a basic_message<tags::text>
    and basic_message<tags::binary>, and specialize the
    implementations without having to rely on inheritance and runtime
    polymorphism.

As Dean stated, with such tags, we can specialize different message
types. And I think the message type tags should imply the underlying
storage policy of that type of basic_message. Say, tags::text
(tags::default_) implies an std::string storage facility, while
tags::unicode implies an std::wstring storage facility, and
tags::stream may implies a boost::asio::streambuf storage facility (as
what I've done in my own project). So I suggest we could include a
storage_type in the tags struct:

    struct tags {
        struct default_ {
            typedef std::string storage_type;
        };

        typedef default_::text;

        struct unicode {
            typedef std::wstring storage_type;
        };

        struct stream {
            typedef boost::asio::streambuf storage_type;
        };

        ...
    };

    typedef basic_message<tags::text> message;
    typedef basic_message<tags::unicode> wmessage;
    typedef basic_message<tags::stream> smessage;
    ...

Would this be sane?

Cheers
Cheng


Glyn Matthews wrote:
> Guys,
>
> I've been giving a little thought to something Dean mentioned in his 
> last message about using std::string in the network library.
>
> The first thing I thought of was that Dean stated that "everything is 
> a template".  Apart of course from std::string.  I have created a 
> branch in SVN named gxm) which replaces all references to std::string 
> with an extra template parameter.  Happily, this passes all the 
> original tests (with an additional template specialization so that 
> const char * is converted to a std::string).  However, this creates a 
> problem (certainly with GCC) because the wchar_t typedef is the same 
> as char and its not possible to overload const wchar_t * in the same 
> way.  So the following code will not compile:
>
> wmessage wmsg;
> wmsg << header(L"wide characters");
>
> Another thing I see is that boost filesystem and boost program_options 
> have dealt with a very similar problem to this.  But if we use the 
> same approach (see the file "boost/detail/utf8_codecvt_facet.hpp" )  
> then we'd have to accept the use of a cpp source file, meaning we will 
> no longer have a header only library.
>
> What do others think about this?
>
> G
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>