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.
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
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.
----- Rom
-----Original Message-----
From: Oliver Bock [mailto:[email protected]]
Sent: Friday, January 11, 2013 10:47 AM
To: Rom Walton
Cc: [email protected]
Subject: Re: [boinc_dev] Regression in f72fef8
On 1/11/13 16:36 , Rom Walton wrote:
> I've committed:
> 4b5698372d0ac1a2281565ca624bd88a1e6a3f62
>
> This should resolve the build problem with boinc_opencl.cpp.
Yep, test build already underway...
Honestly, I don't think it's good style to not include required headers
where they're needed. In that sense your commit seems more like a
workaround than a fix since the original problem in lib/win_util.h still
persists. Is there a reason for this approach I might have overlooked?
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.
