Fun with pointers in C++
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
X| A possibly better (and much clearer) implementation would be to have GetA() and GetB() return references. You could then write the code without the idirection.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
In two hours you can have a great lunch, jogging, some fun with your partner, some nice song listening/playing and also a shower. All that cannot be done because the language is cryptic: that's why I hate C/C++! Good post, though...
-
X| A possibly better (and much clearer) implementation would be to have GetA() and GetB() return references. You could then write the code without the idirection.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
That's even worse:
GetA() = GetB();
And due to if statement we must assume that A and B can be nulls. GetA and GetB should return
constpointers. -
X| A possibly better (and much clearer) implementation would be to have GetA() and GetB() return references. You could then write the code without the idirection.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
-
A good example of why you should use const: const int* GetA() const { return &m_a; } *GetA() = *GetB(); // compile error - use the Set function you numpty
totally agree with you. But always use const can cause some other problems. I personally try to avoid "pointer-getter-functions" but when i have to use, i do something like this:
class Foo
{
private:
int m_nA;public:
int* GetAPtr() { return &m_nA; }
const int& GetA() const { return m_nA; }
void SetA(int nA) { ASSERT(IsValid(nA)); m_nA = nA; }
};And if i have to use the pointer-getter i have to write
Ptrexplicit. So i see extremly fast that*GetAPtr() = *GetBPtr();
is nonesense, and if you try to do
GetA() = GetB();
you get a compiler-error Maybe my way overshot the mark a litte bit. ;P :-\
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
My only problem with that is that GetA and GetB are being called twice each. There is, of course, no guarantee that the second call to either will return the same value as the first. Further, there is not guarantee that either isn't an expensive operation. I would probably go for the much clearer: A* pa = GetA(); B* pb = GetB(); if (pa != NULL && pb!= NULL) *pa = *pb; Unfortunately, this method would always call GetB once, while the original would never call GetB if the first call to GetA returned NULL, so determining which is more efficient depends of how expensive the call to GetB is, and the likelihood than GetA returns null. Which would give us this: A* pa = GetA(); if (pa != NULL) { B* pb = GetB(); if (pb != NULL) *pa = *pb; } Which, despite being the most keystrokes, would be the best method in terms of speed efficiency, memory efficiency (fewest assembly instructions), and code clarity. In other words, just freakin' learn to type.
Truth, James
-
My only problem with that is that GetA and GetB are being called twice each. There is, of course, no guarantee that the second call to either will return the same value as the first. Further, there is not guarantee that either isn't an expensive operation. I would probably go for the much clearer: A* pa = GetA(); B* pb = GetB(); if (pa != NULL && pb!= NULL) *pa = *pb; Unfortunately, this method would always call GetB once, while the original would never call GetB if the first call to GetA returned NULL, so determining which is more efficient depends of how expensive the call to GetB is, and the likelihood than GetA returns null. Which would give us this: A* pa = GetA(); if (pa != NULL) { B* pb = GetB(); if (pb != NULL) *pa = *pb; } Which, despite being the most keystrokes, would be the best method in terms of speed efficiency, memory efficiency (fewest assembly instructions), and code clarity. In other words, just freakin' learn to type.
Truth, James
Amen Brother! Was saying something similar this morning. Our Java guys have all these layers Spock, Groovy, Gradle, etc on top of the Java code to make life "simpler" and "easier". They spent the same, if not more, amount of time learning about those things as they would have just doing whatever it was by hand. But code in Delphi mainly so what do I know? Back when I was coding in C I was smart, now it doesn't feel like it so much because the languages take care of too much stuff for you and you don't have to think about it.
-
Sorry, that's not my code, an i cant change it. I just saw it in some code and where surprised what's that :D Returning references would make it much harder to read:
GetA() = GetB()
looks like What the hell? Assignment to a Function? :omg: :wtf:
C3D1 wrote:
Returning references would make it much harder to read
We'll just have to agree to disagree on that. IMO, this is a quite useful C++ paradigm.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
That's even worse:
GetA() = GetB();
And due to if statement we must assume that A and B can be nulls. GetA and GetB should return
constpointers.My bad; I missed the if statement. IMO, if code needs such a test, it probably has a poor architecture to begin with. It is much better to have a special dummy instance of a type to represent 'not present', and reserve the null pointer for truly bad situations that crash the program. Reasonable people may differ on this. :)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
In two hours you can have a great lunch, jogging, some fun with your partner, some nice song listening/playing and also a shower. All that cannot be done because the language is cryptic: that's why I hate C/C++! Good post, though...
That's my issue with the language too. I once spent a day trying to understand a piece of code from a heavily modified Diku-based MUD when I was in college after a friend begged for help to fix some issues on his MUD.
-
Amen Brother! Was saying something similar this morning. Our Java guys have all these layers Spock, Groovy, Gradle, etc on top of the Java code to make life "simpler" and "easier". They spent the same, if not more, amount of time learning about those things as they would have just doing whatever it was by hand. But code in Delphi mainly so what do I know? Back when I was coding in C I was smart, now it doesn't feel like it so much because the languages take care of too much stuff for you and you don't have to think about it.
Ah Delphi, the evolution of my first true love. Where nothing is left to chance for knowing the types and how things are evaluated... I miss Delphi. I loath Fortran even F2003. Such is the life of maintaining aerospace code.
-
Amen Brother! Was saying something similar this morning. Our Java guys have all these layers Spock, Groovy, Gradle, etc on top of the Java code to make life "simpler" and "easier". They spent the same, if not more, amount of time learning about those things as they would have just doing whatever it was by hand. But code in Delphi mainly so what do I know? Back when I was coding in C I was smart, now it doesn't feel like it so much because the languages take care of too much stuff for you and you don't have to think about it.
That's why I prefer to code in Java rather than C++. Though I have written small apps in C++, I prefer to focus on the logic of data flow instead of the detailed memory structure of the RAM. Indeed, this is why I prefer Java to C#, though again I have used the latter quite a lot. This might be because I write a lot of mathematical apps where the logic of data flow is hard enough without extra overheads. Java just seems relatively effortless for coding such applications. That said, I do occasionally code in C++, and even assembly language, simply because I like to be reminded how computers work for my own academic satisfaction. However, I do miss the days of C64 POKE and PEEK - one really felt as if one was in control of the computer in those days.
-
Today i come across this two lines of code (i changed the naming of the functions):
// ...
if(GetA() && GetB())
*GetA() = *GetB();
// ...took me nearly two hours of figuring out WHY DOES THIS CODE WORK, since i realised that
GetA()returns a Pointer and Pointers are IValue... Looked deeper inside the code, i found aSetA(int)-Method... Why to use something like*GetA() = *GetB()
if you could use
SetA(*GetB())
-
Sorry, that's not my code, an i cant change it. I just saw it in some code and where surprised what's that :D Returning references would make it much harder to read:
GetA() = GetB()
looks like What the hell? Assignment to a Function? :omg: :wtf:
Learn to read code. Assignment to a function would be
GetA = GetB()
which would mean GetB() returns a function pointer rather than an int* and GetA is function pointer rather than a function. Learn to read code.
#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
-
Your code will be correct if both GetA and GetB return pointer on GLOBAL or STATIC variable same type ofcorse. It is possible to code on C++ without C-knowledge, but not to programm :cool:
It would also be correct within the context of the code for a class where the functions are returning pointers to data members.
#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
-
My only problem with that is that GetA and GetB are being called twice each. There is, of course, no guarantee that the second call to either will return the same value as the first. Further, there is not guarantee that either isn't an expensive operation. I would probably go for the much clearer: A* pa = GetA(); B* pb = GetB(); if (pa != NULL && pb!= NULL) *pa = *pb; Unfortunately, this method would always call GetB once, while the original would never call GetB if the first call to GetA returned NULL, so determining which is more efficient depends of how expensive the call to GetB is, and the likelihood than GetA returns null. Which would give us this: A* pa = GetA(); if (pa != NULL) { B* pb = GetB(); if (pb != NULL) *pa = *pb; } Which, despite being the most keystrokes, would be the best method in terms of speed efficiency, memory efficiency (fewest assembly instructions), and code clarity. In other words, just freakin' learn to type.
Truth, James
what about:
int* a;
int* b;
if ((a = GetA()) && (b = GetB()))
{
*a = *b;
}#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
-
what about:
int* a;
int* b;
if ((a = GetA()) && (b = GetB()))
{
*a = *b;
}#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
That does work, but
if (a = GetA()) ...
is too easy to mistake for
if (a == GetA()) ...
Which is why I never leave the comparison implied, so we get:
if ((a = GetA()) != NULL && (b = GetB()) != NULL)
which is rather unwieldy. And for what purpose? The longer version I posted will produce the exact same object code.
Truth, James
-
That does work, but
if (a = GetA()) ...
is too easy to mistake for
if (a == GetA()) ...
Which is why I never leave the comparison implied, so we get:
if ((a = GetA()) != NULL && (b = GetB()) != NULL)
which is rather unwieldy. And for what purpose? The longer version I posted will produce the exact same object code.
Truth, James
James Curran wrote:
The longer version I posted will produce the exact same object code.
Will it? The version you and I just discussed has the advantage of short-circuiting, where the first version you posted does not. Which is a "limitation" you pointed-out.
#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein