Re: Help Required: Operator overloaded function template and Friend
From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 02/13/05
- Next message: Victor Bazarov: "Re: Duffers question (revision in MFC)"
- Previous message: Shezan Baig: "Re: Conversion operators and ambiguity"
- In reply to: CoolPint: "Re: Help Required: Operator overloaded function template and Friend"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 13 Feb 2005 11:49:52 -0500
"CoolPint" <coolpint@yahoo.co.uk> wrote...
> [...]
> I hope to get more insight to the problem by asking following
> questions if you don't mind. I apologise in advance if this is not the
> right group for this kind of questions.
It's the right newsgroup.
> 1. It used to work with gcc 3.2.3 but not with 3.4.2 anymore. What is
> the correct behaviour according to the standard?
AFAIK, the inability to deduce T is the correct behaviour. What may have
happened is that g++ provided deduction in some cases (where it didn't have
to) and in other, similar, cases it could not deduce arguments or did it
incorrectly. That would certainly be a bug and to fix it they decided to
follow the Standard requirements precisely.
To know more about the differences between 3.2.3 and 3.4.2, please visit
their web site or post to gnu.g++.help.
> What is the rule
> governing "deducible contexts" that I should study?
The rules are defined in the C++ Standard document. It's not a very good
studying tool though. You should probably get a copy of "C++ Templates"
by Vandevoorde and Josuttis.
> I also wonder what
> other compilers do with this situation since I have only gcc.
Comeau refuses to compile stating the same reason, essentially. I leave
it to others to test more compilers.
> 2. If it's correct not to be able to deduce T in this case according
> to the standard, then any function template which accepts a nested
> type of a class template whose type parameter needs to be deduced from
> the funtion call arguments would never work, would it? Am I
> understanding correctly?
Yes, AFAICT. The reason is that the "nested" type is _dependent_ on
the template argument.
> Can some experts kindly provide answers to my questions above?
I am sure they will, in addition to my feeble attempt.
> Thank
> you very much in advance.
And I'd like to ask for a favour. Please don't top-post next time.
Thanks!
>
>> I think you've run into one of those "non-deducible contexts". The T is
>> too deeply entrenched into the 'a' and 'b' arguments here for the
>> compiler
>> to figure out from real arguments (operands) you give it.
>>
>> > [..]
>> > #include <iostream>
>> > int main()
>> > {
>> > Obj<int>::Sub a(10),b(10);
>> > if ( a == b )
>> > std::cout << "OK" ;
>> > }
>>
>> There are probably several ways to fix it and one would be to make your
>> operator== a member:
>>
>> template <typename T>
>> class Obj<T>::Sub {
>> public:
>> Sub(int i):n(i) { }
>> bool operator==(const Obj<T>::Sub &b) const
>> {
>> return n == b.n;
>> }
>> private:
>> int n;
>> };
>>
>> Another way is to call the operator function using the functional
>> notation
>> with the template argument explicit:
>>
>> ...
>> if (operator==<int>(a,b))
>> ...
V
- Next message: Victor Bazarov: "Re: Duffers question (revision in MFC)"
- Previous message: Shezan Baig: "Re: Conversion operators and ambiguity"
- In reply to: CoolPint: "Re: Help Required: Operator overloaded function template and Friend"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
