Follow up on this... The only place the warnings need to be suppressed is around the boost includes from qpid/Options.h.
The qpid-1673 branch has the committed files with boost dynamic linking. I'm going to start merging trunk out to qpid-1673, test, then merge back to trunk. -Steve -- Steve Huston, Riverace Corporation Check out my networked programming blog at http://stevehuston.wordpress.com/ > -----Original Message----- > From: Steve Huston [mailto:[email protected]] > Sent: Tuesday, March 10, 2009 11:23 AM > To: [email protected] > Subject: RE: Experiences with qpid-1673 branch? > > > Hi Danushka, > > > > I think I understand the issues the compiler is warning > > against, but I > > > don't have 100% confidence. What rationale did you use for > disabling > > > the warnings? > > > > > Hi Steve, > > > > I am sorry for the late reply in the first place. > > No problem - thanks for your reply. > > > Well ... we do not have any control what so ever on this as > > Boots itself > > possesses these issues. On the other hand as far I can see, this > does > > not lead to any malfunctioning. When I checked on the Boost mailing > > lists, the common knowledge is to disable the warning and proceed. > > Ok, I see, and agree. I still don't feel safe blindly disabling the > warning globally since we really need to know if Qpid has code that > triggers one of these so it can be evaluated. I'm going to try > selectively disabling the warnings around the usage. > > To other devs... This selective disabling involves compiler-specific > ifdefs in the header files... Like: > > #ifdef MSVC > # pragma warning(push) > # pragma warning(disable : 4251 4231 4660) > #endif > > // code here > > #ifdef MSVC > #pragma warning(pop) > #endif > > Unfortunately, this is not the kind of thing that can be placed in a > separate reusable header since the warning numbers may change on a > case-by-case basis. The trade-off here is keeping compiler-specific > things out of the headers vs. only disabling the warning in specific > spots where we believe it to be safe. > > Thoughts? > > Thanks, > -Steve > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
