template operator== not working
3DCoderGuy
template<typename T>
class XYZ_POINT
{
private:
T x;
T y;
T z;
public:
XYZ_POINT(void) {};
XYZ_POINT(const T allVals) : x(allVals), y(allVals), z(allVals) {};
bool const operator==(const XYZ_POINT<T> &xyzTest);
}
In my cpp file I have this.
template<typename T>
bool const XYZ_POINT<T>::operator ==(const XYZ_POINT<T> &xyzTest)
{
return ((x == xyzTest.GetX()) &&(y == xyzTest.GetY()) &&(z ==
xyzTest.GetZ()));
}
In the main file I have this
int _tmain(int arc, _TCHAR* argv[])
{
XYZ_POINT<double> dXYZPnt1(1,0,0);
XYZ_POINT<double> dXYZPnt2(3,0,0);
if (dXYZPnt1 == dXYZPnt2)
{
bool b = true;
b = false;
}
}
Doesn't compile with the following error
error LNK2019: unresolved external symbol "public: bool const __thiscall
XYZ_POINT<double>::operator==(class XYZ_POINT<double> const &)"
(??8?$XYZ_POINT@N@@QAE?B_NABV0@@Z) referenced in function _main
If I move the implimentation to the header file it compiles fine.
What am I doing wrong?
The actual implimentation is more complex then I'm demonstrating and I need
to include some header files that I don't want in the declaration.
Thanks
Mark
Alf P. Steinbach
Quite a lot. But to answer directly what you're probably most interested in, see
<http://www.parashift.com/c++-faq-lite/templates.html#faq-35.12>.
It's very often a good idea to check the C++ FAQ before asking.
Now as to other wrongdoings.
The class name XYZ_POINT, in all uppercase, is an invitation to name clashes
with macros, and besides it hurts the eyes and ears (all uppercase is perceived
as shouting and is visually distracting). Preferentially reserve all uppercase
names for macros, and make sure that your own macros are always defined with all
uppercase names. That way you minimize the chance of macro name clashes.
Using 'void' to indicate "no arguments": this is a C-ism, not meaningful in C++.
Declaring and defining a default constructor that does not initialize the
members: they will have arbitrary (formally invalid) values.
Semicolon after closing '}' of function definition.
Defining a copy constructor when the one you get by default is just fine.
Not defining operator<, which is the one you really need for algorithms,
containers etc.
Missing semicolon after closing '}' of class definition.
"int _tmain(int arc, _TCHAR* argv[])". This is something some Microsoft
employee scooped up from drainage system and it smelled so bad that all her
co-workers just loved it, and even though they failed to find any reasonable use
for it they just added it everywhere, luv it luv it. Standard for what you need
here is "int main()".
Style: "if( something ) { assign to boolean }". Instead do "boolean =
something". I'm assuming the intent was not to have the boolean as a local
variable.
> The actual implimentation is more complex then I'm demonstrating and I need
> to include some header files that I don't want in the declaration.
When you fix your "main" the above code does not need any headers.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
David Wilkinson
Mark:
Template function/member definitions must be visible to the caller, so they must
be in the .h file. This has nothing to do with operator ==() in particular.
--
David Wilkinson
Visual C++ MVP
Alexander Grigoriev
bool, which doesn't make sense.
bool operator==(const XYZ_POINT<T> &xyzTest) const;
"3DCoderGuy" <nob...@nospam.com> wrote in message
news:uzopyzJs...@TK2MSFTNGP06.phx.gbl...
3DCoderGuy
news:%23bvicdK...@TK2MSFTNGP06.phx.gbl...
Thanks David,
This is my first go at templates. I was trying to convert some old classes
over since it just made sence.
Thanks again.
3DCoderGuy
news:udZOD8Ls...@TK2MSFTNGP05.phx.gbl...
Thanks Alexander for your reply.
The use of const on the return comes from Scott Meyers' Effective C++ Third
Edition Item 3
"const Rational operator*(const Rational& lhs, const Rational& rhs);
Many programmers squint when they first see this. Why should the result of
operator* be a const object? Because if it weren't, clents would be able to
commit atrocities like this:
Rational a, b, c;
...
(a * b) = c; // invoke operator= on the result of a*b!
..."
You might not see that example as typed but if( a * b = c) ... does occure
because of typing mistakes. The compiler will catch this.
Now this might not apply to the operator== but it is a practice I've picked
up and just haven't changed.
Thanks again
Mark
Ben Voigt [C++ MVP]
> The use of const on the return comes from Scott Meyers' Effective C++
> Third Edition Item 3
> "const Rational operator*(const Rational& lhs, const Rational& rhs);
> Many programmers squint when they first see this. Why should the
> result of operator* be a const object? Because if it weren't, clents
> would be able to commit atrocities like this:
> Rational a, b, c;
> ...
> (a * b) = c; // invoke operator= on the result of a*b!
> ..."
>
> You might not see that example as typed but if( a * b = c) ... does
> occure because of typing mistakes. The compiler will catch this.
>
> Now this might not apply to the operator== but it is a practice I've
> picked up and just haven't changed.
Good enough. It's not that const in the return type is wrong -- it
certainly isn't, and Scott makes a very good argument for including it -- it
just isn't necessary for correct usage of the operator to work. On the
other hand making the function const is necessary, otherwise the compiler
will throw errors when you test for equality with a const reference.
>
> Thanks again
> Mark
3DCoderGuy
news:M7OdndGUCJ4azb_VnZ2dnUVZ_oqhnZ2d@comnet...
It is amazing how you can google for something and get a million hits but
not the right one. I now have a bookmark to the C++ Faq Lite page.
I always make an effort to do my research first and then ask the groups. I
just wasn't finding the answer, which led me to ask the group. I respect
the fact that another developer has to give of their time to read and answer
my question.
That is always greatly appreciated.
One comment on the C-ism of f(void), your right it is a C-ism. At least I
broke my self of f(a,b) int b, int a;{}.
Now I need to decide if I'm on the void *p = NULL; or void *p = 0; camps.
Thanks Alf
Mark
P.S. I even do research on those who reply to me. You are a great
contributor to the groups, thanks.
Alf P. Steinbach
And rightly.
With the current language definition it prevents optimizations like Andrei's
Mojo move semantics.
C++0x is another matter.
> Why should the result of operator* be a const object?
Ideally it shouldn't, but there is no great harm, just a loss of possible
optimization.
> Because if it weren't, clents would be able to
> commit atrocities like this:
> Rational a, b, c;
> ...
> (a * b) = c; // invoke operator= on the result of a*b!
> ..."
>
> You might not see that example as typed but if( a * b = c) ... does occure
> because of typing mistakes. The compiler will catch this.
And why would you want to prevent that?
> Now this might not apply to the operator== but it is a practice I've picked
> up and just haven't changed.
It would be a good idea to change it (see above).
3DCoderGuy
news:%23Y6NdXS...@TK2MSFTNGP03.phx.gbl...
I love the fact that after 20 years of coding I'm still learning every day.
Thanks for that Ben.
Mark
Ben Voigt [C++ MVP]
>> occure because of typing mistakes. The compiler will catch this.
>
> And why would you want to prevent that?
Because the side-effect of the assignment operator is to change a temporary
that is immediately thrown away, obviously not intended.
The programmer meant to use the comparison operator == instead.
3DCoderGuy
...snip...
>>
>> Thanks Alexander for your reply.
>> The use of const on the return comes from Scott Meyers' Effective C++
>> Third Edition Item 3
>> "const Rational operator*(const Rational& lhs, const Rational& rhs);
>> Many programmers squint when they first see this.
>
> And rightly.
>
> With the current language definition it prevents optimizations like
> Andrei's Mojo move semantics.
>
> C++0x is another matter.
>
>> Why should the result of operator* be a const object?
>
> Ideally it shouldn't, but there is no great harm, just a loss of possible
> optimization.
>
>> Because if it weren't, clents would be able to commit atrocities like
>> this:
>> Rational a, b, c;
>> ...
>> (a * b) = c; // invoke operator= on the result of a*b!
>> ..."
>>
>> You might not see that example as typed but if( a * b = c) ... does
>> occure because of typing mistakes. The compiler will catch this.
>
> And why would you want to prevent that?
int a = 2, b = 3, c = 4;
if (a * b = c);
fails to compile as I would expect.
Why would I want my class to allow such a syntax?
>
>> Now this might not apply to the operator== but it is a practice I've
>> picked up and just haven't changed.
>
> It would be a good idea to change it (see above).
>
Hit me with the 2x4, doesn't the example I give above prove why I shouldn't
change.
Mark
Alf P. Steinbach
Did she?
Anyway, the techniques for dealing with inadvertent-assignment-in-condition for
built-in types (namely high warning level for compilation, writing constants on
left side, code inspection, systematic testing, etc.) apply here also.
Fixing that possible problem for e.g. class Rational amounts to nothing compared
to the rest of code, and as mentioned it does have a cost, so, pain but no gain.
Cheers,
Alf P. Steinbach
I already did but you didn't notice. :-) Sorry, I couldn't resist. :-) But
anyways, take a look at e.g. the section titled "Optimizing Returning Values
from Functions" at <url: http://www.ddj.com/database/184403855>, which is Andrei
Alexandrescu's old article on "Move Constructors" (the Mojo framework).
> doesn't the example I give above prove why I shouldn't change.
Nope, it it only shows there is at least one valid reason for const result, when
disregarding the negative effects of doing this.
3DCoderGuy
When you are clubing a guy who is down you could at least say Your Welcome.
Thanks for the link. I'll have to read it another 6 times and see how I can
add some Mojo to my code.
Mark
Ben Voigt [C++ MVP]
> * Ben Voigt [C++ MVP]:
>>>> You might not see that example as typed but if( a * b = c) ... does
>>>> occure because of typing mistakes. The compiler will catch this.
>>> And why would you want to prevent that?
>>
>> Because the side-effect of the assignment operator is to change a
>> temporary that is immediately thrown away, obviously not intended.
>>
>> The programmer meant to use the comparison operator == instead.
>
> Did she?
>
> Anyway, the techniques for dealing with
> inadvertent-assignment-in-condition for built-in types (namely high
> warning level for compilation, writing constants on left side, code
> inspection, systematic testing, etc.) apply here also.
"writing constants on left side"?
That's exactly what is going on here!
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Ben Voigt [C++ MVP]:
>>>>> You might not see that example as typed but if( a * b = c) ... does
>>>>> occure because of typing mistakes. The compiler will catch this.
>>>> And why would you want to prevent that?
>>> Because the side-effect of the assignment operator is to change a
>>> temporary that is immediately thrown away, obviously not intended.
>>>
>>> The programmer meant to use the comparison operator == instead.
>> Did she?
>>
>> Anyway, the techniques for dealing with
>> inadvertent-assignment-in-condition for built-in types (namely high
>> warning level for compilation, writing constants on left side, code
>> inspection, systematic testing, etc.) apply here also.
>
> "writing constants on left side"?
>
> That's exactly what is going on here!
Nope. An expression is not necessarily a constant, and in particular, in C++,
an rvalue is not necessarily a constant. For class types it is in most cases
not constant, e.g. the std::vector<T>().swap(v) idiom for clearing a vector v
relies on this, and the rvalue non-constness is also used in the code below.
Applying my well-known telepathic powers, I think you're perhaps confusing an
expectation about the result of '*' in e.g. mathematics, with operator results
in C++.
The technique of using constants on the lhs has two common cases: literal, or
something named and declared 'const', which for the above and a class Rational
would mean
Rational const product = a*b;
if( product = c ) // Oops.
Unfortunately, in this context, operator= is one of those that can't be defined
as a free-standing function. If it could then the above would not even be
potential problem, because a temporary can't be bound to reference to non-const.
With member operator= you can't directly prohibit assignment to non-const
rvalue (which is generally preferable, especially for optimization).
An alternative is to change the syntax for assignment, so that '=' simply isn't
valid. Examples: 'a.value() = b', or 'a.assignFrom( b )', or 'a ^= b'. The
'^=' syntax on the assumption that exclusive-or assignment isn't useful on its
own for this class.
Example that illustrates all three assignment syntaxes mentioned above (I would
not, however, do this, because I don't think =/== is a real problem):
<code>
template< typename T >
class AssignableRef
{
private:
T* myRef;
public:
AssignableRef( T& v ): myRef( & v ) {}
T& operator=( T const& v ) { return myRef->assignFrom( v ); }
};
class Rational
{
private:
Rational& operator=( Rational const& ); // No such.
public:
Rational( int = 0 ) {}
void swap( Rational& ) {}
Rational& assignFrom( Rational const other )
{
Rational( other ).swap( *this );
return *this;
}
Rational& operator^=( Rational const& other )
{
return assignFrom( other );
}
AssignableRef<Rational> value()
{
return AssignableRef<Rational>( *this );
}
Rational& operator*=( Rational const& ) { return *this; }
bool operator==( Rational const& ) { return true; }
};
Rational operator*( Rational const& a, Rational const& b )
{
return Rational( a ) *= b;
}
int main()
{
Rational a, b, c;
a ^= b; // OK, this is an assignment.
a.assignFrom( b ); // OK, this is also an assignment.
a.value() = b; // OK. this is also an assignment.
if( a*b == c ) {} // OK, this is a comparision.
//if( a*b = c ) {} // Oops, does not compile (which is OK).
}
</code>
The question is though, is the potential error detection really worth the
non-standard notation? If it isn't, then that means the potential error isn't
really that much of a problem in practice. And then the cost of a 'const'
result, in particular prohibiting optimization, is counter-indicated.
There are also other alternatives, such as the extremely dirty trick (formally
UB if you use the standard library) of redefining 'if' so that it /requires/ a
'bool' value. But that extremely dirty trick doesn't help with ?:, nor does it
help with assignment to bool... Another alternative: it might be that the
compiler can produce a warning that can be turned into an error, but this
alternative is compiler-specific. A third is, as mentioned, the convention
always writing something const on the left hand side of '==', although the logic
of that is questionable, for what if you forget, how can you detect that?
Best: simply don't write '=' instead of '==', and test the software so that any
such slip-ups are detected.
If '=' instead of '==' passes all tests, then, after all, it doesn't matter.
>> Fixing that possible problem for e.g. class Rational amounts to
>> nothing compared to the rest of code, and as mentioned it does have a
>> cost, so, pain but no gain.
Cheers, & hth.,
Ben Voigt [C++ MVP]
> * Ben Voigt [C++ MVP]:
>> Alf P. Steinbach wrote:
>>> * Ben Voigt [C++ MVP]:
>>>>>> You might not see that example as typed but if( a * b = c) ...
>>>>>> does occure because of typing mistakes. The compiler will catch
>>>>>> this.
>>>>> And why would you want to prevent that?
>>>> Because the side-effect of the assignment operator is to change a
>>>> temporary that is immediately thrown away, obviously not intended.
>>>>
>>>> The programmer meant to use the comparison operator == instead.
>>> Did she?
>>>
>>> Anyway, the techniques for dealing with
>>> inadvertent-assignment-in-condition for built-in types (namely high
>>> warning level for compilation, writing constants on left side, code
>>> inspection, systematic testing, etc.) apply here also.
>>
>> "writing constants on left side"?
>>
>> That's exactly what is going on here!
>
> Nope. An expression is not necessarily a constant, and in
The OP had declared the return type of his operator as const in order to
make such expressions const.
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Ben Voigt [C++ MVP]:
>>> Alf P. Steinbach wrote:
>>>> * Ben Voigt [C++ MVP]:
>>>>>>> You might not see that example as typed but if( a * b = c) ...
>>>>>>> does occure because of typing mistakes. The compiler will catch
>>>>>>> this.
>>>>>> And why would you want to prevent that?
>>>>> Because the side-effect of the assignment operator is to change a
>>>>> temporary that is immediately thrown away, obviously not intended.
>>>>>
>>>>> The programmer meant to use the comparison operator == instead.
>>>> Did she?
>>>>
>>>> Anyway, the techniques for dealing with
>>>> inadvertent-assignment-in-condition for built-in types (namely high
>>>> warning level for compilation, writing constants on left side, code
>>>> inspection, systematic testing, etc.) apply here also.
>>> "writing constants on left side"?
>>>
>>> That's exactly what is going on here!
>> Nope. An expression is not necessarily a constant, and in
>
> The OP had declared the return type of his operator as const in order to
> make such expressions const.
Perhaps I should rephrase that for clarity then: the techniques that client code
programmers intentionally use for dealing with...
That's not what's going on above.
The client code programmer who writes "if( a*b = c ) ..." is not intentionally
writing a constant expression on the left hand side, because that expression
could very well and would normally be non-constant for class type a, b and c.
As already illustrated, the ensure-constant-lhs technique can be applied to the
above example, and the point you reacted to was the statement that it can.
And then the code looks different. :-)
>> particular, in C++, an rvalue is not necessarily a constant. For
>> class types it is in most cases not constant, e.g. the
>> std::vector<T>().swap(v) idiom for clearing a vector v relies on
>> this, and the rvalue non-constness is also used in the code below.
Cheers, & hth.,
Ben Voigt [C++ MVP]
No it cannot, unless you make assumptions about mathematical equalities
holding for arbitrary class types, the same ones you accused me of several
messages ago.
At least I'm thinking of transforming that into
if (0 == a * b - c)
But that's not necessarily valid for all types. Some types may not even
define operator -.
Alf P. Steinbach
Sorry, but this reminds me of some old sketch where person A maintains it's
impossible to walk trough a door.
Person A demonstrates this by repeatedly missing the door and colliding with the
wall, and after being given an example of walking through door (by person B),
still A denies it's possible, and demonstrates anew how impossible it is (dang,
hit the wall, again!).
I already gave example of ensuring constant lhs, and in fact I already mentioned
that I did, so we're two levels away from that, but again, just for variety:
Rational const c = ...
if( c == a*b ) ... // OK
if( c = a*b ) ... // Typo, won't compile.
Not that I'm promoting this convention.
As I wrote elsewhere, the logic behind it is somewhat lacking, and I might add
now that it also in general reduces readability. =/== is simply not worth it.
>> And then the code looks different. :-)
>>
>>
>>>> particular, in C++, an rvalue is not necessarily a constant. For
>>>> class types it is in most cases not constant, e.g. the
>>>> std::vector<T>().swap(v) idiom for clearing a vector v relies on
>>>> this, and the rvalue non-constness is also used in the code below.
Cheers, & hth.,
- Alf
--
Alexander Grigoriev
like weird designs...
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in message
news:u0jHCtS...@TK2MSFTNGP04.phx.gbl...
Ben Voigt [C++ MVP]
> already mentioned that I did, so we're two levels away from that, but
> again, just for variety:
> Rational const c = ...
> if( c == a*b ) ... // OK
> if( c = a*b ) ... // Typo, won't compile.
You now have an extremely limited example which does not generalize well at
all.
How about comparing a*b to c*d? You have to make the return type of
operator* const to prevent the error in a general way.
Alf P. Steinbach
>> already mentioned that I did, so we're two levels away from that, but
>> again, just for variety:
>> Rational const c = ...
>> if( c == a*b ) ... // OK
>> if( c = a*b ) ... // Typo, won't compile.
>
> You now have an extremely limited example which does not generalize well at
> all.
Yes, that's correct. I think I've already said enough about the const lhs
technique so I shall not elaborate on its many failings.
> How about comparing a*b to c*d?
What about it?
Is the question how to apply const lhs technique to that case?
Not that I recommend it, but it would go like this:
Rational const ab = a*b;
Rational const cd = c*d;
if( ab == cd ) ...
> You have to make the return type of
> operator* const to prevent the error in a general way.
As already shown else-thread, no, writing = for == can be detected at compile
time in other ways, the most effective and (IMHO) least ugly to make '=' for
assignment invalid. That it's possible does not mean it's a good idea, because
the problem it means to avoid is insignificant and will be detected anyway if it
occurs, and the solution has associated costs, namely non-conventional notation,
reducing readability and clarity. Just as it isn't a good idea, in general, to
make rvalues const, because the problem is insignificant and will be detected
anyway, e.g. through testing or via compiler warnings, and the solution has
associated costs, in particular prohibiting an important possible optimization.
Ben Voigt [C++ MVP]
> compile time in other ways, the most effective and (IMHO) least ugly
> to make '=' for assignment invalid. That it's possible does not mean
> it's a good idea, because the problem it means to avoid is
> insignificant and will be detected anyway if it occurs, and the
> solution has associated costs, namely non-conventional notation,
> reducing readability and clarity. Just as it isn't a good idea, in
> general, to make rvalues const, because the problem is insignificant
> and will be detected anyway, e.g. through testing or via compiler
> warnings, and the solution has associated costs, in particular
> prohibiting an important possible optimization.
I'm still going to trust Scott Meyers on this one, especially because he
recommends the const r-values *in a discussion on RVO*:
http://groups.google.com/group/comp.lang.c++.moderated/msg/e60d78d50da3f841
Alf P. Steinbach
RVO is just loosely associated with the earlier discussion in this thread.
const result or not has, as far as I know, no impact on RVO.
Happily Scott Meyers did not advocate const r-values on the basis of efficiency.
He advocated it on the basis of what felt most natural to him. He's made
some fundamental errors in his books (e.g., as I recall, stating that the
compiler would generate operator& for you if you didn't define it), but
confusion about const impact on RVO is, as far as I know, not one of them.
Cheers, & hth.,
- Alf
--
Ben Voigt [C++ MVP]
> * Ben Voigt [C++ MVP]:
>>> As already shown else-thread, no, writing = for == can be detected
>>> at compile time in other ways, the most effective and (IMHO) least
>>> ugly to make '=' for assignment invalid. That it's possible does
>>> not mean it's a good idea, because the problem it means to avoid is
>>> insignificant and will be detected anyway if it occurs, and the
>>> solution has associated costs, namely non-conventional notation,
>>> reducing readability and clarity. Just as it isn't a good idea, in
>>> general, to make rvalues const, because the problem is insignificant
>>> and will be detected anyway, e.g. through testing or via compiler
>>> warnings, and the solution has associated costs, in particular
>>> prohibiting an important possible optimization.
>>
>> I'm still going to trust Scott Meyers on this one, especially
>> because he recommends the const r-values *in a discussion on RVO*:
>> http://groups.google.com/group/comp.lang.c++.moderated/msg/e60d78d50da3f841
>
> RVO is just loosely associated with the earlier discussion in this
> thread.
> const result or not has, as far as I know, no impact on RVO.
Then what "important possible optimization" were you referring to? I'm
lost.
Alf P. Steinbach
>> const result or not has, as far as I know, no impact on RVO.
>
> Then what "important possible optimization" were you referring to? I'm
> lost.
Earlier in this thread, then giving URL to yet earlier reference, <url:
http://groups.google.com/group/microsoft.public.vc.language/msg/7209f10e7eece7d4>.
Just for clarity, this refers to what you the programmer can do, confined by the
rules of the language wrt. const and other things, whereas RVO is an
optimization applied by the compiler, which can do just about anything as long
as it's within the "as if" rule (and the standard explicitly gives it permission
to e.g. remove side-effects from copy constructors in some optimizations).
For the compiler, a little const on a temporary in the middle of a copy chain
that it's going to optimize away, doesn't matter: hey, it's optimized away,
anyway. It's not there, as far as the compiler's optimization circuits are
concerned. For the programmer doing similar optimization where the language
rules apply and must be followed at each step, the const is a showstopper.
Cheers, & hth.,
- Alf
--