Stephan Pfletschinger <[EMAIL PROTECTED]> writes:
> we are using Ptolemy 0.7 on Solaris 2.6 with gcc version 2.7.2.2, and
> Ptolemy 0.7.1 on Linux with gcc version egcs-2.90.27 980315 (egcs-1.0.2
> release).
> The offending line is the following (in the go-routine):
> F[m] = Complex(input%0);
> While this compiles in Ptolemy 0.7 without problems, Ptolemy 0.7.1
> produces the following error:
> Loader: errors in compilation
> SDFSparafile.pl In method 'void SDFSparafile::go()'
> SDFSparafile.pl:137: call of overloaded 'Complex(Particle &)' is ambiguous
> /users/ptolemy-0.7.1 p1-3/src/kernel/ComplexSubset.h:54: candidates are:
> Complex::Complex(double, double)
> /users/ptolemy-0.7.1 p1-3/src/kernel/ComplexSubset.h:55:
> Complex::Complex(const Complex &)
I believe this has nothing to do with 0.7 vs 0.7.1, but is a compiler
problem. Furthermore I would claim that egcs 1.0.2 is buggy. It is
missing the first-level interpretation of the expression (apply
Particle's operator Complex()) and is complaining because the
second-level interpretation is not unique. If the compiler tries to
handle the expression by inserting an implicit conversion then indeed
there are two possible interpretations: apply Particle's operator
double() and then use Complex's constructor taking a double (with the
second double defaulting to 0), or apply Particle's operator Complex()
and then use Complex's copy constructor. However, that's irrelevant
because the expression is valid with *no* implied conversions, and the
compiler should have used that interpretation first. This is just plain
a bug in egcs. Please report it to the egcs maintainers, or see if there
is a newer egcs version to update to.
> There is an operator Complex defined in the class Particle, although we
> are not sure if it is Standard C++ to define operators others than those
> already specified in C++.
operator T() for any type name T is valid C++, and has been at least
since Stroustrup's second edition --- see r.12.3.2 there.
> Also, the shortest version
> F[m] = input%0;
> seems to work, but I am reluctant to assign a variable of one class to
> another without an explicit typecast
The compiler is probably doing the right thing with this case.
Using explicit conversions when reading Particles is a habit that the
Ptolemy group acquired a long time ago to work around problems in much
older C++ compilers (which had a tendency to choose an unexpected
implicit conversion). It shouldn't really be necessary --- though I
share your concern, particularly given this evidence of bugs in this
same area in the compiler you are using.
IIRC there was discussion of similar conversion problems with Complex on
the Ptolemy mailing list, probably last winter sometime. It'd be worth
your while to scan the list archives (available at the Ptolemy website).
I'm not sure whether those reports were also from users of egcs 1.0.2.
regards, tom lane
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
