On Tue, Dec 15, 2009 at 12:52 AM, Glyn Matthews <[email protected]> wrote: > > 2009/12/14 Dean Michael Berris <[email protected]> >> >> >> 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.
Right. Not a language lawyer here too -- I trust what the compiler and the tests say. Until I get my own copy of the C++ standard, I'll say "if the tests say it's OK, then it should be OK". :) >> >> > 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. > Indeed. :) > Regards, Thanks! :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
