Closed GoogleCodeExporter closed 9 years ago
I think I know where is the problem.
Original comment by krustev....@gmail.com
on 9 Apr 2012 at 11:58
There are 3 problems with this actually.
1. The parser should not allow overloading of functions with different types.
As in the examples
real xy(...)
int xy(...)
should not be allowed. This is perhaps written in somewhere in the
documentation, but the parser doesn't have a check whatsoever. Suppose we
forget about it, then there are two more problems
2. First with the "fail" case - when xy(real, real) comes first, when the
parser is checking whether xy(int, int) already exists, the check returns
"exists" because of the build-in conversion int->real. So in this case, the
first declaration is simply replaced by the second one - hence can never be
called. (you can see the warning in the log)
3. When xy(int,int) comes first and the parser checks whether xy(real,real)
already exists - the check returns properly "not existing", so the new
definition is added. The funny part in this case however is when xy(int,int) is
called. As it is now the parser could call any of the definitions (again
because of the build-in conversion int-real). It is up to the underlying
implementation of std::multimap<> that (on my platform) xy(int,int) pops up
first. If xy(real,real) is found first - then the int version will be
overshadowed and will never be called.
All the above is to say that the fix requires serious checks and a bit of a
discussion. I would postpone the fix and will do it after the 0.9.8 release.
Original comment by krustev....@gmail.com
on 14 Apr 2012 at 2:12
The bulk if the issue fixed in r2147 - r2148. Needs further validation
Original comment by krustev....@gmail.com
on 6 May 2012 at 12:52
The updates listed above appears to be stable.
Original comment by krustev....@gmail.com
on 12 May 2012 at 1:30
Original comment by krustev....@gmail.com
on 13 May 2012 at 8:16
Original issue reported on code.google.com by
analogc...@gmx.net
on 7 Apr 2012 at 7:46Attachments: