[lingucomponent-issues] [Issue 93008] hunspell: hashmgr.hxx buil d breaker
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 + 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]
[lingucomponent-issues] [Issue 93008] hunspell: hashmgr.hxx buil d breaker
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=93008 User tl changed the following: What|Old value |New value Assigned to|[EMAIL PROTECTED] |nemeth Target milestone|--- |OOo 3.0.1 --- Additional comments from [EMAIL PROTECTED] Fri Aug 22 06:19:55 + 2008 --- . - 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]
[lingucomponent-issues] [Issue 93008] hunspell: hashmgr.hxx buil d breaker
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=93008
--- Additional comments from [EMAIL PROTECTED] Fri Aug 22 06:31:31 +
2008 ---
Actually the compiler does not always have a choice to warn about a ambiguity.
Example
int f( sal_Int16 n);
and code like
sal_Int8 n1 = 3;
f( n1 )
Here f( n1 ) will call f( sal_Int16 n) from global namespace.
If we now have a header file A.hxx like
namespace A
{
int f( sal_Int8 n)
}
and somehow, maybe just implicitly not even done in our code, the file A.hxx
gets included along with a
using namespace A;
somewhere else then
f( n1 )
will no longer implictly conver the sal_Int8 to sal_Int16 and then call the
original function as before, because now A::f will have an exactly matching
parameter and thus now A::f gets called and likely even without the compiler
giving any notice about it at all...
-
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]
