Board index » cppbuilder » Borland compiler bug? Problem overloading templatized member operator>>

2005-08-19 01:12:52 AM
cppbuilder108
Hi all.
I have found something that may be a compiler bug in BCB 6 and I would
like to hear your oppinions on the matter.
I have run into a problem of overloading a templatized operator>>by a
specialized version of it. In short (complete code below), I have
written a stream class, STR, which defines a templatized operator>>() as
a member that can deal with the built in C types (int, char, float...)
template <class tType>STR& STR::operator>>(tType & t);
I then attempted to add an overloaded version of this to support my own
class, Array3d (a template class), and wrote this as a friend of Array3d as
template <class tType>
STR & operator>>( STR & outf, Array3d<tType>& array ){}
It all compiles, but when I run the program, the line;
str>>array // str is an STR, array is an Array3d<int>
will call STR::operator>><Array3d<int>>, rather than (what I belived
to be) the more specialized operator>>(STR &, Array3d<int>&), thus
resulting in an output from the program of:
----- BCB 6 output ----------------
Operator>>for Array3d
MEMBER ***** STR::operator>>(tType obj)
Operator>>for int
MEMBER ***** STR::operator>>(tType obj)
-------------------------------------
Compiling the same pice of code in Visual Studio.net instead yields the
result I expected:
----- VS-net output ---------------
Operator>>for Array3d
STAND-ALONE **** STR & operator>>(STR & inf, Array3d<tType>& array )
Operator>>for int
MEMBER ***** STR::operator>>(tType obj)
-------------------------------------
If I instead remove the STR::operator>>() and replace it by a friend
function (commented out in the code below) the overloading works as I
wish it to.
This has been posted before in comp.lang.c++, where another poster
tested the program on gcc 4.0.1, which reported an ambiguity of the
function call between the STR member and the Array3d friend operators.
Victor Bazarov also tested the code on Comeau online which indicated
that the VS.net behaves as it should.
Is this a bug in the Borland compiler or is this the correct behaviour?
In either case, do you think that changing the member into a friend
function is a good workaround or may I end up in some other problem?
Best regards
hall
 

hall < XXXX@XXXXX.COM >writes:
program. But your description sounds as if there is indeed a bug int
the Borland compiler.
it didn't circumvent the compiler bug. It's hard to justify this
opinion, but the operation in question seems somewhat more related to
the type of the second argument than to STR.
functions.