Thread: string reference

Hi,
I have the following function:

Code:

string &find (string &name);

It returns a concatenated string of name and another string. But if the specified name doesn't exist, the function has to indicate this. I could just figure out one solution: throwing an exception. But I think this is not very useful in this case. Can you imagine another solution (like returning iterator::end (), but for strings).

Thanks
matott

This protptype won't work very well.
You're trying to return a reference to what ? ( shouldn't be a local variable )
I'd try something like this

Code:

string find( string & name );

and return an empty string in case of name not found.
Kurt

Oh yes, its wrong. Else it would be some kind of dangling reference.

I thought about the empty string solution, but can you imagine another solution - maybe by changing the function prototype?

matott

Originally Posted by laserlight

It depends on what this function is used for. Do you have any usage examples?

It generates a list from directory entries, searches for the name in this list and returns the name and a version string which is generated from the filename.

Code:

name#version

Ah, then what happens if the name is not in the list?

The programme reports to the user that it's not an the list.

I agree, having an empty string does not help, unless you use "empty string" as an error condition to mean "file not found".

It would be something like NULL in this case, but avoiding this solutions seems to be quite difficult.

You could return a bool and have the user pass in a string to be modified. You could also return a pair<string, bool> that holds the string value and a true/false for whether it succeeded. I didn't look at your problem closely enough to see whether I think either of those options are actually more appropriate.

being a classical example of a source function, what would be wrong with

Code:

auto_ptr<string> find(const string& name)

?

auto_ptr's are not copyable, so you can't return them like that. A Boost smart pointer would work though.

In fact, they are copyable, and this is a perfect example of how and when you would want to copy them.

The auto_ptr copy semantics are different than normal copy semantics in that they transfer ownership, thereby modifying the source of the target. In this case, that's what you want since the source of the copy will be a local auto_ptr inside the function. After the copy takes place, the local auto_ptr will be destroyed but that won't affect the internal pointer because it will no longer have ownership. The target of the copy will own the pointer, and it can do whatever it likes with the string and when it goes out of scope the internal pointer and the string will be properly destroyed (assuming no other ownership transfer has occurred in the meantime).

I think this might also be an example of when C++0x's move semantics will make the situation easier and it won't require dynamic memory.

Well I'll be...
I just re-read the auto_ptr references in "Effective STL" & "C++ Coding Standards" and looked at the auto_ptr source code, and it looks like you're right. When the books said you can't store auto_ptr's in STL containers because of their copy semantics, I thought that meant all copying was out of the question.
I'd still feel safer using a reference counted smart pointer though.

while returning a auto_ptr every programmer knows: "that function allocates memory on the heap and returns a handle to it."

Well nobody can really know that for sure, they just assume it. But the developer who wrote the function might not understand all the implications of using an auto_ptr and might save the auto_ptr in their class before returning it and thereby invalidating their own copy... I've seen some developers that I used to work with do some scary things with auto_ptr's (like store char* arrays in them).
Also, what if the function starts out written correctly & returning an auto_ptr, but later as the code evolves, someone decides that they want to keep a local copy of the pointer before returning it. The proper thing to do would be to switch to smart_ptr's, but then that would change the function signature and require all calling code to be changed also...

Using auto_ptr is "unsafe" in that situation only if users are unfamiliar with it. That is probably pretty common, though, so the point is certainly something to consider. If you're not familiar with auto_ptr, it would be better to use one of the other mentioned solutions while you learn and gain a bit of experience with it.