I am currently working my way through C++ Primer Fifth Edition. I have gone through a couple of other C++ books, but they weren't very detailed and were quite complicated.
This book has been helping me a lot with everything that I have missed. I've just hit a wall.
One of the exercises asks me to write a declaration for a function that returns a reference to an array of ten strings, without using trailing return, decltype, or type alias.
I know it only says write a declaration, which I have done, like so:
string (&returnArray()) [10];
I wanted to write a function definition as well, like so:
string (&returnString(int i, string s)) [10]
{
string s1[10];
s1[i] = s;
return s1;
}
In my main function, I have a for loop which passes a string literal through and stores that string inside a pointer to an array of ten strings. It should then output the results to the screen.
The problem I am having is, when I dereference my pointer to an array, once, it will output the address. If I dereference it twice, the program outputs nothing and stops responding.
Here is my main function, I have changed it multiple times, yet can't figure out why it's not outputting properly. I've probably got it all wrong...
int main()
{
string (*s)[10];
for(int i = 0; i != 10; ++i)
{
s = &returnString(i, "Hello");
cout << s[i] << endl;
}
return 0;
}
Your function returns a reference to a local variable – after the call, it’s a dangling reference. You cannot do that.
You can only return references to storage that goes on existing after the end of the function call.
Returning a reference to a temporary local object invokes undefined behavior.
A short fix is making it static:
string (&returnString(int i, string s)) [10]
{
static string s1[10];
^^^^^^
s1[i] = s;
return s1;
}
int main()
{
string(&s)[10] = returnString(0, "Hello");
for (int i = 0; i != 10; ++i)
{
s[i] = "Hello";
cout << s[i] << endl;
}
}
Returning pointers/references to local variables is bad, undefined behavior. You can follow your exercise and not forget that constraint, your exercise tells you to do something but it's not necessarily telling you to do it the wrong way, in fact it's a good one that will lead you to pitfalls and hence make you a better programmer once you figure them out.
So what's left given that constraint of not returning addresses to local variables but still addressing the task given? You have the static fix as M M. already mentioned, or you could think you're creating something useful like a function rotate, for example, that accepts an string(&)[10] and returns itself rotated ;-)
Look that, iostream insertion and extraction operators already work like that, returning references to parameters passed by reference.
Related
So I have been working on a question and this think stumbled upon me. When I declare a variable outside the main function, the program works correctly, that is it reaches the else case of "Friendship is magic" but if the variable is declared inside it returns Chris instead of Friendship statement.
int mis, chr;
int main() {
int a, n, m;
cin >> a;
for (int i = 0; i < a; i++) {
//code here
}
if(mis > chr)
cout << "Mishka";
else if(chr > mis)
cout << "Chris";
else
cout << "Friendship is magic!^^";
}
The input that I am using makes the value of chr and mis equal so it should be evaluating to the else statement but instead it just stops at else if.
"With great power (provided by C++) there must also come great responsibility"
And
"With uninitialized variables comes the undefined behavior"
Variables that are declared at global scope are being initialized by the compiler. However, the variables defined inside any function (i.e, having automatic storage) may contain garbage values (that could be different in each invocation of the program). I recommend always initializing your variables to some value.
int main()
{
int mis = 0, chr = 0;
// ...
return 0;
}
Let's come to your program now:
When I declare a variable outside the main function, the program works correctly, that is it reaches the else case of "Friendship is magic"
It is happening because the variables (on which your if ladder dependent) are being initialized to 0. Since, both variables have same value (0), the else part of the if statement is being executed.
but if the variable is declared inside it returns Chris instead of Friendship statement.
It's a perfect example of undefined behavior. If they are defined inside your function, they will be holding some garbage value and that might not be equal. Hence, what you are observing is an undefined behavior and you might get different results in different machines or even sometimes in a same machine.
I tried your code and it works the same for me in both cases.
So, I would say it changes with editor to editor and always initialize the variable before using it.
Otherwise, we might face the same problem as you face. As it initializes the variables with garbage values.
We are trying to return an array of structures to print the contents in the main. When debugging the code, we get to the line right before the return statement and it shows that it is holding the right contents which is an int and then a string (playerID and name). As soon as the return statement executes the array is returned to the main but only the playerID is held in the array. All of the values for name have been lost. Can someone explain why this would happen and a possible solution? If further clarification is needed please let me know.
#include<iostream>
#include<fstream>
#include<cstring>
#include<string>
#include<math.h>
using namespace std;
struct Player
{
int playerID;
string name;
};
Player *fillPlayers();
int main()
{
Player *myPlayerPointer;
myPlayerPointer = fillPlayers();
return 0;
}
Player * fillPlayers() {
ifstream file1;
Player * fullPlayerPointer = new Player[244];
Player ourPlayers[244];
file1.open("Players.txt");
if (file1.fail()) {
cerr << "file1 did not open";
}
if (file1.is_open()){
while (!file1.eof()){
string size;
getline(file1, size);
for(int i = 0; i < 244; i++){
file1 >> ourPlayers[i].playerID;
file1 >> ourPlayers[i].name;
}
}
file1.close();
}
fullPlayerPointer = &ourPlayers[0];
return fullPlayerPointer;
}
This code looks a lot like C code. In C++ we have fancy RAII containers like std::vector and std::array that will do exactly what you want.
As for the issue, you are not returning an array, instead you are returning a pointer to an int. You should check out What is array decaying?.
http://en.cppreference.com/w/cpp/container/vector
http://en.cppreference.com/w/cpp/container/array (C++ >= 11)
The generally correct answer is use a std::vector as it assists in managing ownership and the lifetime of storage as well as tracking the capacity and resizing itself as needed. But let's take a walk through fillPlayers to explain what is going wrong.
Player * fillPlayers()
{
ifstream file1;
Player * fullPlayerPointer = new Player[244];
Dynamically allocated 244 Players. Dynamic storage has manually controlled lifetime and will remain valid until such time as it is freed. Unfortunately this allocated storage is never used and not put away correctly later with delete[] This allocation will be "leaked". As dire as this sounds, this is the "right" way to allocate the storage, but as we will see, the function uses it incorrectly.
Player ourPlayers[244];
Statically allocated 244 Players as a temporary variable. This variable will only exist inside the innermost set of surrounding curly braces {}. Afterward it will be rendered invalid. This means that references to ourPlayers should not be returned from this function as ourPlayers will be rendered invalid at the return from the function and before the caller can make use of it.
file1.open("Players.txt");
if (file1.fail())
{
cerr << "file1 did not open";
}
Always test before using, so the above is almost right. It is rendered redundant by the next line performing a nearly identical test. This could be a good place to put an else, but the code is more easily read with if (file1.is_open()) followed by an else to print the error message if it is not open.
Why do I say this? Because the programmer's intent with is_open is much easier to discern than with the broader term fail.
if (file1.is_open())
{
while (!file1.eof())
Read Why is iostream::eof inside a loop condition considered wrong? for details on why this is almost always the wrong solution to looping through a file.
{
string size;
getline(file1, size);
Always test a read to ensure it succeeded. In addition, the file size was read and then not converted into an integer to use in the loop that follows.
for (int i = 0; i < 244; i++)
Regardless of how many entries there are in this file 244 will always be read. If the file does not have at least 244 entries, the read will fail and as the reads are not being checked for success, garbage will be stored in the array.
Also note that there is a loop iterating through 244 entries in the file that is surrounded by a loop that will attempt to read again until the EOF flag is set. Most likely you only want one such loop.
{
file1 >> ourPlayers[i].playerID;
file1 >> ourPlayers[i].name;
}
}
file1.close();
}
fullPlayerPointer = &ourPlayers[0];
The pointer to the dynamic allocation made earlier is overwritten by a pointer to the temporary allocation ourPlayers. A reference to long-term storage has been replaced by a reference to storage that is about to go out of scope and become invalid.
It is possible that OP intended this to copy the data in the short term storage to the long term storage, but unfortunately that's not what the compiler was told to do, and it's not really worth doing. It would be much more useful to directly read the file into the long term storage.
return fullPlayerPointer;
Returns from the function and gives an invalid array to the caller.
}
Lot to fix in there.
Here's a very simple approach that fixes all of the above problems but exposes a few more:
Player * fillPlayers()
{
ifstream file1("Players.txt");
Player * players = nullptr;
if (file1.is_open())
{
int size;
if (file1 >> size)
{
players = new Player[size];
int index = 0;
while (file1 >> players[index].playerID >> players[index].name
&& index < size)
{
}
// extra brains needed here to handle premature read failure.
}
file1.close();
}
else
{
cerr << "file1 did not open";
}
return players; // only a pointer to the array was returned. How big the
// array is and how many items are actually in it is lost
}
This is where std::vector really becomes awesome. It knows how big it is and how full it is. An array doesn't.
Now, assuming std::vector is not allowed, and Paul McKenzie has already covered what to do if it isn't, the smart thing to do is make a very simple wrapper around the array to get some modicum of the safety and ease of use vector provides.
class stupidvector
{
Player *players;
size_t capacity; // a typical vector implementation uses a pointer for
// this to make iteration easier
size_t size; // vector uses pointer here, too.
public:
stupidvector();
stupidvector(size_t size);
// correctly copy a stupid vector Rule of Three. In this case, don't
// allow it to be copied.
stupidvector(const stupidvector& src)=delete;
// correctly move a stupid vector Rule of Five
stupidvector(stupidvector && src);
// release storage
~stupidvector();
// add an item to the end
void push(const Player & player);
// how big is it?
size_t getcapacity();
// how full is it?
size_t getsize();
// make it act like an array
Player & operator[](size_t index);
// correctly assign. Rule of Three. again we don't want to copy these,
// but if we did, look at Copy and Swap Idiom for a neat solution
stupidvector& operator=(const stupidvector& src) = delete;
// correctly move
stupidvector& operator=(stupidvector && src);
};
Pay special attention to the Rules of Three and Five
I am working on a piece of structured programming homework that requires that I make a program that allows the user to enter names blah blah blah and so on. What I want to do after putting names into the string array is to print them to the screen. I had hoped to accomplish this by passing the array and the number of names contained therein to a function that would then print them to the screen. I wanted to pass the array and number of names as constants so that it would safeguard them so they couldn't be modified by the function, just read-only. I don't understand why I can't put const before the string array or the number of names though.
void writeNames (const string namelist[], const int number_of_names)
Is this something I just have to accept or is there a way I can pass both of those as read-only to the function? I can complete the homework without this so this is more a question of curiousity than a "help me with my homework" one.
P.S. Vectors seem to be a way of doing a lot more things with strings and such, but we haven't got to them in class yet and therefore I can't use them yet either.
Thanks
Without seeing what you're doing within the function, it's hard to answer the question, but my crystal ball says that you're probably doing something that could potentially modify one of the parameters within your method, so the compiler is complaining because you declared the parameter const.
As an example, something like this works just fine:
void writeNames(const std::string namelist[], const int number_of_names)
{
for(int i = 0; i < number_of_names; i++) {
std::cout << namelist[i] << std::endl;
}
}
However, something like this would cause a compiler error, since you're changing one of the variables:
void writeNames(const std::string namelist[], const int number_of_names)
{
while(number_of_names--) { // <-- We're modifying a const value here
std::cout << namelist[count] << std::endl;
}
}
Incidentally, putting the const modifier on your "number_of_names" parameter is somewhat redundant since you're passing the parameter by value, so changing the value within the function would have no effect on the value of the input parameter in the calling function. A change in any of the strings in the array, however, would be reflected in the calling function, so the const modifier there makes sense. Generally you would use const only on parameters that are either pointers, or being passed in by reference.
I have this code
void split(vector<float> &fvec, string str)
{
int place = 0;
for(int i=0; i<str.length(); i++)
{
if(str.at(i) == ' ')
{
fvec.push_back(atoi(str.substr(place,i-place).c_str()));
place=i+1;
}
}
fvec.push_back(atoi(str.substr(place).c_str()));
}
What im trying to do is pass a reference to a vector into the method so it splits the string i give it into floats without copying the vector... i dont want to copy the vector because it will be containing 1000's of numbers.
is it not possible to pass a vector by reference or am i just making a stupid mistake?
if it helps heres the code im testing it out with
int main (void)
{
vector<float> fvec;
string str = "1 2 2 3.5 1.1";
split(&fvec, str);
cout<<fvec[0];
return 0;
}
It is indeed possible. You're just using the wrong syntax. The correct way to do it is :
split(fvec, str);
What you're doing is wrong because it passes the address of the vector as the intended reference.
If you are using a modern compiler, like gcc/g++, it does named return value optimization for you, so that you don't need to pass the return value by reference or pointer.
See:
http://en.wikipedia.org/wiki/Return_value_optimization/
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
You are passing the address of the vector. (split(&fvec, str);)
The call should be split(fvec, str); without the &.
The obvious thing that leaps out is the split(&fvec, str); in your main function, which means you're not passing a vector but the address of a vector. This is the right thing to do if your vector parameter is a pointer, but not if it's a reference. Use split(fvec, str); instead.
Also, one thing you might consider is building the vector in the function and returning it as normal. This is likely to be optimized out by the compiler. If you're not using a compiler with return value optimization ability, you're likely to get better results by changing compilers than trying to tune your code manually.
And, if you're worried about passing big data structures around, what of the string parameter? Doesn't that get large?
This question already has answers here:
Can a local variable's memory be accessed outside its scope?
(20 answers)
Closed 6 years ago.
Consider the following code where I am returning double& and a string&. It works fine in the case of a double but not in the case of a string. Why does the behavior differ?
In both cases the compiler does not even throw the Warning: returning address of local variable or temporary as I am returning a reference.
#include <iostream>
#include <string>
using namespace std;
double &getDouble(){
double h = 46.5;
double &refD = h;
return refD;
}
string &getString(){
string str = "Devil Jin";
string &refStr = str;
return refStr;
}
int main(){
double d = getDouble();
cout << "Double = " << d << endl;
string str = getString();
cout << "String = " << str.c_str() << endl;
return 0;
}
Output:
$ ./a.exe
Double = 46.5
String =
You should never return a reference to a local variable no matter what the compiler does or does not do. The compiler may be fooled easily. you should not base the correctness of your code on some warning which may not have fired.
The reason it didn't fire here is probably that you're not literally returning a reference to a local variable, you are returning a variable that is a reference to a local variable. The compiler probably doesn't detect this somewhat more complex situation. It only detects things like:
string &getString(){
string str = "Devil Jin";
return str;
}
The case of the double is simpler because it doesn't involve constructing and destructing a complex object so in this situation the flow control analysis of the compiler probably did a better job at detecting the mistake.
The reference to a double refers to a location that is still physically in memory but no longer on the stack. You're only getting away with it because the memory hasn't been overwritten yet. Whereas the double is a primitive, the string is an object and has a destructor that may be clearing the internal string to a zero length when it falls out of scope. The fact that you aren't getting garbage from your call to c_str() seems to support that.
GCC used to have an extension called Named Returns that let you accomplish the same thing, but allocated the space outside the function. Unfortunately it doesn't exist anymore; I'm not sure why they took it out
Classic case of a Dangling reference in respect to C++.The double variable was not on call stack while returning reference was trying to access it invoking the compiler to set the guarding flags. String however has explicit Garbage Collection mechanism which lets your compiler to overlook the scenario.