Solved

std::string pointer

Posted on 2014-01-15
3
360 Views
Last Modified: 2014-01-15
std::string *str1;
int main (int argc, char* argv[]) {

        process();
        printf("String = %s\n", str1->c_str());  // THIS SUCCEEDED 

}

void process() {
        std::string str;
        std::set<uint64_t> vals;
        vals.insert(12);
        vals.insert(14);
        for(std::set<uint64_t>::iterator it = vals.begin(); it != vals.end(); ++it) {
                str += boost::lexical_cast<std::string>(*it);
                str += ":";
        }

        str1 = &(str);
}

Open in new window


Why does the printf in the main() does not seg faults and prints correct value 12:14:

Shouldn't it seg fault as it is trying to access memory which is out of scope. I mean the variable str inside process() function goes out of scope once the control returns from the function
0
Comment
Question by:perlperl
3 Comments
 
LVL 31

Accepted Solution

by:
Zoppo earned 500 total points
ID: 39782164
Hi perlperl,

IMO it depends on how the string class is implemented and what code the compiler creates. Of course it's errornous but this doesn't mean it has to crash in every case. If i.e. the string destructor doesn't reset some values (i.e. the pointer to the allocated memory) and if deallocating the memory in string destructor doesn't overwrite the content and there's coincidentally a terminating 0 char the printf can work without problems anyway.

BTW: I tested the same in Windows with Visual Studio, there it either crashs or outputs some trash.

ZOPPO
0
 

Author Comment

by:perlperl
ID: 39782249
I see.  I tried several times on my linux machine and it fails sometimes, so it all depends on if the memory was cleared during runtime or not.

Thanks
0
 
LVL 40

Expert Comment

by:evilrix
ID: 39782426
This is an example of what the C++ standard would defined as "undefined behaviour". This means that anything can happen. It might work, it might not - it all depends on the platform and the compiler and which way the wind is blowing at the time. Sufficed to say, this type of code is always considered defective.

The standard also defines "unspecified behaviour", which is also platform and compiler dependent; however, this will always behave exactly the same for a given compiler and platform. This type of code is not considered defective; however, it is considered bad practice to rely on such code.

You can read more on my blog: http://evilrix.com/2013/05/09/doubt-and-uncertainty/
0

Featured Post

Best Practices: Disaster Recovery Testing

Besides backup, any IT division should have a disaster recovery plan. You will find a few tips below relating to the development of such a plan and to what issues one should pay special attention in the course of backup planning.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

In days of old, returning something by value from a function in C++ was necessarily avoided because it would, invariably, involve one or even two copies of the object being created and potentially costly calls to a copy-constructor and destructor. A…
Many modern programming languages support the concept of a property -- a class member that combines characteristics of both a data member and a method.  These are sometimes called "smart fields" because you can add logic that is applied automaticall‚Ķ
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

832 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question