From: Glyn M. <gly...@gm...> - 2009-12-14 16:52:52
|
Hi, 2009/12/14 Dean Michael Berris <mik...@gm...> > On Mon, Dec 14, 2009 at 9:16 PM, Glyn Matthews <gly...@gm...> > wrote: > > > > 2009/12/14 Dean Michael Berris <mik...@gm...> > >> > >> > >> 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 |