[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-patch] Fix for PR36766, 36767, 36769 (STL parsing proble ms)
|
Title: Message
Hi
Andrew,
Thanks
for clarification, I was stuck on ctors/dtors/operators, and didn't think about
conversions - I'll try to check this case. Well, I think the patch is
still valid as it should solve the rest of the problems in these PRs (I believe
;)). Case of conversion function can be a separate PR.
/Vic
Hi Victor,
I think that particular operator was meant to
be a conversion function, in which case its mostly correct.
According to the ANSI spec
12.3.2:
A conversion function is
a member function of a class X with a name of the form
conversion-function-id :
operator conversion-type-id
conversion-type-id :
type-specifier-seq conversion-declarator?
conversion-delcaration :
ptr-operator conversion-declarator?
Neither paramter types nor return type can be specified. Classes,
enumerations, and typedef-names shall not be declared in the
type-specifier-seq. The type of a conversion function is "function
taking no parameter, returning conversion-type-id
So the only problem with the test is that op would have
been a class, enumeration or typedef.
A simple example looks like this:
template < class T > class X {
public:
operator int( );
}
template <class T >
X<T>::operator int() { /*...*/}
X < char > x;
int i = int(x); //calls X::operator
int()
-Andrew
victor.mozgin@xxxxxxxxxxxxx Sent by: cdt-patch-admin@xxxxxxxxxxx
06/07/2003 06:34 PM
Please respond
to cdt-patch@xxxxxxxxxxx |
|
To
| cdt-patch@xxxxxxxxxxx
|
cc
|
|
Subject
| RE: [cdt-patch] Fix
for PR36766, 36767, 36769 (STL parsing proble
ms) |
|
Err, missed another one - it
seems that ACEFailedTest.java is redundant also. Tests testBug36766and36769x()
in DOMTests.java cover all these cases already. Testcase in ACEFailedTest
still fails because it contains incorrect operator overloading
declaration:
template <class A, B> cls<A, C>::operator op
&() const {}
There is no return type, so parse naturally fails
(non-existent "op &" operator name is unimportant for CDT parser). If
changed to
template <class A, B> cls<A, C>& cls<A,
C>::operator& () const {}
parse succeeds.
/Vic
-----Original Message-----
From:
victor.mozgin@xxxxxxxxxxxxx [mailto:victor.mozgin@xxxxxxxxxxxxx]
Sent: Saturday, June 07, 2003 1:10 PM
To:
cdt-patch@xxxxxxxxxxx
Subject: [cdt-patch] Fix for PR36766, 36767,
36769 (STL parsing problems)
Here is the patch that should take care of parsing templated
constructor/destructor/operator declarations. By the way, STLFailedTests.java
contains only testBug36805() now, and PR36805 is marked as resolved. Maybe
STLFailedTests.java can be removed?
/Vic