To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=93008 Issue #|93008 Summary|hunspell: hashmgr.hxx build breaker Component|lingucomponent Version|DEV300m29 Platform|All URL| OS/Version|All Status|NEW Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P2 Subcomponent|spell checking Assigned to|[EMAIL PROTECTED] Reported by|tl
------- Additional comments from [EMAIL PROTECTED] Fri Aug 22 06:19:09 +0000 2008 ------- The file hashmgr.hxx has a declartion using namespace std; This is way bad because having any using declaration in a exported header file (that is a header file included by other projects) is always a hidden bomb. At best it will be a build breaker and at worst (if the compiler does not warn properly or if those warnings are ignored) it is a source of uncontrollable and unexpected behavior. Taking the case from yesterday as example: Somehow the chain of includes when building sspellimp.cxx in lingucomponent had changed (as sometimes happens usually with good reason) and now math.h was one of those includes along with hashmgr.hxx. Further part of the problem is that sspellimp.cxx uses STL container like from <list> or <vector> and those implementation are in the namespace std. What happened now is that math.h has a "struct exception" in global namespace and stl has a "class exception" in the std namespace. By having the line using namespace std; in hashmgr.hxx it became ambiguous to the compiler and the build broke. It took us quite a while to find the source of the problem. But still we were lucky since the compiler stopped when it encountered the problem. Consider the problem not being about a struct and a class but of two function with same signature but different implementation. If the compiler had not stopped the build and had chosen to resolve the ambiguity on it's own and maybe by choosing the wrong function for the current context then we would have been way worse since we would have end up with a different and potentially hard to track and maybe hard to notice problem. Thus don't ever have a 'using' declaration in public (exported) header files! Also since when code does live long, sometimes header files gets moved (which also recently happened to the hunspell core and it's headers!) even previously non-public headers may suddenly end up being public. Thus better never ever make use of 'using' declarations in header files. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
