Hi, 2009/12/14 Dean Michael Berris <[email protected]>
> 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 not a language lawyer but as I understand it PODs have a trivial default constructor, which doesn't apply to `std::string`. But as you explain, maybe you don't need it to be a POD to work. > > > 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 > > IMO, we shouldn't be afraid to break backwards compatibility at this stage in development if the improvements are really valid. Regards, G
------------------------------------------------------------------------------ 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
