If I remember correctly, the original function prototypes just used string instead of std::string. Using string in combination with the 'using std' namespace directive is dangerous in a header file if there is another string class being used by a project.
When I moved stuff from util.h to win_util.h I cleaned that up. Including headers by category usually avoids the issue altogether. System Headers->Framework Headers->Project Headers Besides the windows.h is a tricky header anyway, premature inclusion could cause developers other issue. Espically if they are attempting to limit the API set they are supporting with their app by use of the API defines like: #define WINVER 0x0500 #define _WIN32_WINNT 0x0500 #define _WIN32_WINDOWS 0x0500 By including windows.h in a header, you might accidently allow the inclusion of an API into the namespace that would otherwise fail to compile. When the app goes to run on an older version of Windows that doesn't support the API the app blows up. ----- Rom -----Original Message----- From: Oliver Bock [mailto:[email protected]] Sent: Friday, January 11, 2013 12:04 PM To: Rom Walton Cc: [email protected] Subject: Re: [boinc_dev] Regression in f72fef8 On 1/11/13 16:58 , Rom Walton wrote: > Two reasons actually: > 1. The explicit declaration of which string class is used in the > header file reduces the chance of a namespace collision in case a > project is using more than one string class. Sorry, I don't quite understand this one: reducing the chance for collisions should be a good thing, shouldn't it? I guess you mean implicit, right? > 2. Minimal inclusion principle as defined by David: > > CODING STYLE LAW (minimal inclusion principle): > If foo.cpp requires <blah.h>, > #include <blah.h> in foo.cpp, NOT foo.h That's correct and I agree with that. However, this is the header which requires the symbols, not the implementation. > Granted the pre-compiled header file boinc_win.h breaks #2, but the > perf gain and the fact that OS and tool chain headers rarely change is > usually enough to justify their use. Ok, fair enough. Update: the commit fixed the build. Thanks, Oliver _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
