On Mon, Dec 14, 2009 at 9:16 PM, Glyn Matthews <[email protected]> wrote: > > 2009/12/14 Dean Michael Berris <[email protected]> >> >> >> Right. The request_header is definitely just a struct (or a POD). :) > > I think it's not a POD because it contains members that are of type > `std::string`. >
Hmmm... That's odd. GCC 4.4 doesn't complain with the use case. I think this is still valid if it's not a POD because it allows for "static" initialization. I remember std::string can be statically initialized (as in, during compile time) which is why this works. >> >> I'm still thinking about moving the request/response types as nested >> types to the http::basic_client<...> and http::server<...> instead of >> namespace-level types, or merging them to work for both the client and >> the server. At the worst case I would make different specializations >> based on the tag and type-defining them as different types >> server_request/server_response at the namespace level. I find it a >> little ugly in the C++ world of namespaces, but if you have other >> ideas about making the naming convention more consistent I'm all ears. >> :D >> > > Why have http::basic_client and not http::basic_server? > Was still thinking about that. I think I would implement an http::basic_server if I can do something like tag dispatching based on features to be supported by the basic_server specialization. > I think nested classes could be a better approach, they will use the same > tags as the server class anyway. > I agree. However that would break code that's already using http::request for the client -- unless i typedef http::request to be by default http::basic_client<...>::request which is just ugly. That said, I think we can still afford to break backwards compatibility because, well, we're header only -- and breaking changes will cause users to actively upgrade their usage. <insert evil laughter here> :D -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
