Talk:C++ Programming/Operators/Operator Overloading

overloading operators through friend functions
This article isn't very structured and it lacks some basic info like overloading operators through friend functions. It would be nice if there was something written about that. Mecanismo 14:58, 22 August 2007 (UTC)


 * This appears to have been addressed. See Overloadable Operators: Bitwise operators. Kmote (talk) 16:39, 14 November 2008 (UTC)

Overloadable Operators: Bitwise operators (typo)
There is a typo in item #1 describing the shift operators. I'd fix it myself, but I can't quite figure out what it's trying to say. Kmote (talk) 16:39, 14 November 2008 (UTC)

m_ThreadReceiver.compare(name)
0 == An unregistered user is having difficulties understanding why this solution when dealing with const char *name is superior. I have attempted to explain that since in this method we are dealing with two different types of variables the use of the std:string.compare guarantees that the code will perform for every possible value. --Panic (discuss • contribs) 19:47, 19 March 2011 (UTC)
 * That doesn't make sense. What is "perform for every possible value"? (Do you think it would work for some values and not others? I have the most trouble understanding this part of your statement, because in C++, for an operator involving a class, it either doesn't compile at all, or if it does, then somebody explicitly implemented an operator overload, in which case they designed it to always work.) And what does this have to do with the fact that they are two different types? In the preceding  method, that takes a , why are you willing to use   and not   instead? Why the inconsistency? Perhaps you are just familiar with some string operators and not others. If that is the case, let me inform you: all the relational operators work the same for two  , as it does for a   and a C string. --98.210.210.193 (discuss) 20:08, 19 March 2011 (UTC)
 * Did you try to pass a char* name = NULL as an argument using simply the m_ThreadReceiver == name as I indicated ? It breaks the method doesn't it? So it becomes evident that by using the m_ThreadReceiver.compare(name)==0 you guarantee type safety without any specific cost, and so it is a superior solution.
 * Your proposed change would work most of the time and depending on the implementation and guarantees you could happily live with that limitation, but as teaching material we should aim to provide the best option and permit clear understanding. Consistency is important but in this particular situation it doesn't apply since the method is target to a specific and different input. --Panic (discuss • contribs) 20:27, 19 March 2011 (UTC)
 * m_ThreadReceiver.compare(name) equally does not work if name is NULL --67.180.77.119 (discuss) 23:49, 19 March 2011 (UTC)
 * Hic, you are correct. I had done a test and gotten the idea that it would perform differently... --Panic (discuss • contribs) 04:21, 20 March 2011 (UTC)