I am a huge fan of using the language to communicate my intent, especially when it comes to function parameters, I've talked about this before in terms of simple typing (by utilising "using" statements - to give meaning to simple/trivial types) and const correctness.
But being Christmas, I've had a C++ gift or two, and one of them is C++ High Performance by Victor Sehr and Bjorn Andrist, I've only spent a few minutes looking through this book, but one comment did jump out at me as odd... Not overtly wrong, just odd to me, maybe a different way to look at things...
No, I'm not talking about their constant calling back to compare with Java (rolls eyes) I'm talking about the two stanza's at the bottom:
"C++ Arguments passed as references indicates that null values are not allowed"
No, no that's not the point of references, the point is that you do not allocate memory for and copy the values from the passed resource into a local value for use within the function which will have a scope life-time of the function and therefore be de-allocated at the end of the function. A reference, to me, has always primarily been a method of communicating copy semantics, we're referencing the remote value, if the parameter is not constant it maybe modified, thus:
#include <iostream>
#include <string>
int g_value(42);
void Change(int& p_Value)
{
p_Value += 1;
}
int main()
{
std::cout << "Before: " << g_value << "\r\n";
Change(g_value);
std::cout << "After: " << g_value << std::endl;
}
Or not modified, thus:
#include <iostream>
#include <string>
int g_value(42);
void Change(int& p_Value)
{
p_Value += 1;
}
void Print(const std::string& p_Pre, const int& p_Value)
{
std::cout << p_Pre << ": " << p_Value << "\r\n";
}
int main()
{
Print("Before", g_value);
Change(g_value);
Print("After", g_value);
}
If we were to allocate a value as a pointer we could send the reference to these same functions and they would be unaware of subtle problems (without modern runtime checks):
#include <iostream>
#include <string>
int g_value(42);
int *g_PointedToMemory(new int{ 100 });
void Change(int& p_Value)
{
p_Value += 1;
}
void Print(const std::string& p_Pre, const int& p_Value)
{
std::cout << p_Pre << ": " << p_Value << "\r\n";
}
int main()
{
Print("Before", g_value);
Change(g_value);
Print("After", g_value);
std::cout << "--------------\r\n";
Print("Pointed To Before", *g_PointedToMemory);
Change(*g_PointedToMemory);
Print("Pointed To After", *g_PointedToMemory);
}
With modern runtime checks this code would still compile, you are not "defending" from null pointers by using the reference syntax, you're simply stating not to take a separate copy of the thing being passed in. However, if you dereferenced a null pointer (nullptr) int* as the parameter being passed, the code would still compile, but you would receive a runtime access violation, as you're trying to write to nullptr.
#include <iostream>
#include <string>
int g_value(42);
int *g_PointedToMemory(new int{ 100 });
int *g_Unallocated(nullptr);
void Change(int& p_Value)
{
p_Value += 1;
}
void Print(const std::string& p_Pre, const int& p_Value)
{
std::cout << p_Pre << ": " << p_Value << "\r\n";
}
int main()
{
Print("Before", g_value);
Change(g_value);
Print("After", g_value);
std::cout << "--------------\r\n";
Print("Pointed To Before", *g_PointedToMemory);
Change(*g_PointedToMemory);
Print("Pointed To After", *g_PointedToMemory);
std::cout << "--------------\r\n";
Print("Unallocated Before", *g_Unallocated);
Change(*g_PointedToMemory);
Print("Unallocated After", *g_Unallocated);
}
This code is clearly dereferencing an unallocated piece of memory, it builds no problem... This is where my mind skews on the comment in this text, it's a throw away line, but so miss leading to my eyes.
But this code will not run:
This is where I totally take issue with the statement in the text.
Getting this kind of runtime error, because we've followed the advice of this text, we may move onto the next line of the advice:
"C++ arguments passed as pointers indicates that null values are being handled"... EREEEEERGGGGH. No it does not, lets look at that, lets follow Alice down this rabbit hole with a new function, to take our unallocated integer pointer and try to dereference and print it... The text tells us "null" are being handled, we'll be fine, let us update our code:
#include <iostream>
#include <string>
int g_value(42);
int *g_PointedToMemory(new int{ 100 });
int *g_Unallocated(nullptr);
void Change(int& p_Value)
{
p_Value += 1;
}
void Print(const std::string& p_Pre, const int& p_Value)
{
std::cout << p_Pre << ": " << p_Value << "\r\n";
}
void PrintPtr(const std::string& p_Pre, const int* p_Value)
{
std::cout << p_Pre << ": " << *p_Value << "\r\n";
}
int main()
{
Print("Before", g_value);
Change(g_value);
Print("After", g_value);
std::cout << "--------------\r\n";
Print("Pointed To Before", *g_PointedToMemory);
Change(*g_PointedToMemory);
Print("Pointed To After", *g_PointedToMemory);
std::cout << "--------------\r\n";
// The alternative Print
PrintPtr("Unallocated Before as Pointer", g_Unallocated);
std::cout << "--------------\r\n";
Print("Unallocated Before", *g_Unallocated);
Change(*g_PointedToMemory);
Print("Unallocated After", *g_Unallocated);
}
And now lets run the program again...
Yes, it explodes, with the exact same runtime error... yet the text said "null values are being handled". And it is just totally untrue, the truth is that pointers like this simply mean you can pass something which points to the memory you want to use (passing a pointer is like passing a small number of bytes - depending on your architecture - rather than passing a reference to the memory a pointer maybe anywhere in the addressable memory space, and it does not have to necessarily be a pointer from "new" or "make_shared" (etc) it can be any memory...
So, we could make this PrintPtr function print our allocated "g_value" from the earlier pieces of code, by making the call with a dereferencing:
I am going to plug on with this book, I hope to find another hour tomorrow to start going through their advice for speeding up modern C++. Unfortunately, right now, I am surprise and somewhat dismayed with this miss-leading stance, and I have three other pages folded down to follow up on this exact theme, the text taking you slightly off of course or making statements which are not correct C++ nor correct thinking.
No comments:
Post a Comment