aboutsummaryrefslogtreecommitdiffhomepage
path: root/AUTHORS
diff options
context:
space:
mode:
authorGravatar Carl Worth <cworth@cworth.org>2009-10-21 23:01:17 -0700
committerGravatar Carl Worth <cworth@cworth.org>2009-10-21 23:20:18 -0700
commit2ce552b5f783b6c761f473990df9ce93ef03dcf0 (patch)
tree586394d4842560eb19da5751a48d45c1c3b2cf16 /AUTHORS
parent8ad4350fef132b016bbab5eeb1c4a713e51035c6 (diff)
Fix lifetime-maintenance bug with std::string and c_str()
Here's more evidence that C++ is a nightmare to program---or that I'm smart enough to realize that C++ is more clever than I will ever be. Most of my issues with C++ have to do with it hiding things from me that I'd really like to and expect to be aware of as a C programmer. For example, the specific problem here is that there's a short-lived std::string, from which I just want to copy the C string. I try to do that on the next line, but before I can, C++ has already called the destructor on the std::string. Now, C++ isn't alone in doing garbage collecting like this. But in a *real* garbage-collecting system, everything would work that way. For example, here, I'm still holding a pointer to the C string contents, so if the garbage collector were aware of that reference, then it might clean up the std::string container and leave the data I'm still using. But that's not what we get with C++. Instead, some things are reference counted and collected, (like the std::string), and some things just aren't (like the C string it contains). The end result is that it's very fragile. It forces me to be aware of the timing of hidden functions. In a "real" system I wouldn't have to be aware of that timing, and in C the function just wouldn't be hidden.
Diffstat (limited to 'AUTHORS')
0 files changed, 0 insertions, 0 deletions