Question C++: template friend operator definition

[martins]

Here's a question that has me stumped at the moment: I am trying to define a humble operator+ in a templated vector class, but the syntax seems to be extremely compiler-dependent. The operator is defined as a friend, because the first operand is not of the class type (I am trying to define a vector = scalar+vector operation). This is what I've got at the moment:

template<class VT> class TVector;

template<class VT>
TVector<VT> operator+ (const VT &s, const TVector<VT> &v);

template<class VT> class TVector {
public:
    ...
#if (defined(WIN32)||defined(WIN64))
    template <class VT> friend MATHLIB TVector<VT> operator+ (const VT &s,
        const TVector<VT> &v);
#elif (GCC_VERSION < 30404) // old-style definitions
    friend TVector<VT> operator+ <> (const VT &s, const TVector<VT> &v);
#else
    friend TVector<VT> (::operator+ <>) (const VT &s, const TVector<VT> &v);
#endif
    ...
};

Ok, so it's ugly, but this was the only way to make it work with all the compilers I've had in use so far. No single syntax seems to agree with all of them.

However, now I also need to compile the code for CUDA, and the nvcc compiler doesn't seem to understand any of the above definitions. I'm stuck. Anybody came across this problem before, or has a suggestion for a workaround? What is the "official" syntax for this kind of definition? (So far I've simply been experimenting until a compiler swallowed the syntax I've offered).

 

[Moach]

whoa, gnarly

now, that can't be right... isn't the c++ syntax supposed to be standardized? seems weird that such a workaround should be needed

i did some snooping around on the mmatter... found this -- it drew my attention that this guy is always using reference types for return values - and, he's got all the operators marked "inline"


still seems weird... uncle Bjarne would not be happy about this :lol:


hope this helps at all....


EDIT: found another... seems you're not the only one encountering troubles there...

on the bottom this "Jerry" guy says:

removed the std::complex inheritance
from MoreComplex<T>, and instead made it a base class, and instead added to
it a member called "value" of type complex<T>. Also, I removed the "friend"
declaration so that the overloaded operator = is now simply a "loose"
operator (not in the class, not even a friend).

I don't quite understand it all yet, but it compiles and links.

something's not quite too intuitive about how this should go

 

[martins]

still seems weird... uncle Bjarne would not be happy about this :lol:

I'm not sure if Bjarne has thought his language through to the last detail (of course he might have - what do I know), but I think there is still enough grey area to be filled in by the various steering committees or indeed compiler writers. In my experience, compilers start out with a readable and inconsistent interpretation of the language, and slowly move towards a consistent and incomprehensible form. In its final Zen level of consistency, we'll probably need a compiler to translate code from a human-readable format to C++.

I hope the next Big Language will be one that learns from its users, rather than the other way round.

 

[Urwumpe]

The problem is rather, that many cooks created templates and syntax already before it became standardized. C and C++ have historically the problem that both had to keep the big compilers compatible to the next standard, instead of complaining that the compiler writers don't want to wait for a decade for the next version of the standard. And of course, some compiler writers still think the standard is rather a coarse guideline - Visual C++ still has some deviations from the standard in its STL.

I doubt you can have this better in any language without making it closed, like for example Java.