std::string as function parameter

[avi123]

well, the house rules are that when not passing by value
use pointers and not references... (sad isn't?)
if I'm not mistakem passing pointers is as efficent as passing reference, just look ugly....

so I guess that if passing std::string by value might be expensive that I will use pointers

what do you think Paul?

[Graham]

Sounds to me like whoever made that rule didn't understand references. Personally, I would try to challenge it with whoever is in charge of the rules. There is a big difference in usability (or "neatness" if you prefer) between pointers and references if the class has operators defined. We use a general rule (one that cannot always be adhered to) that accepting a pointer means taking ownership of it, otherwise take a reference. If, for some reason, you have to take a pointer but don't take ownership (e.g. you may need to reseat it), then that fact has to be clearly documented.

[dude_1967]

I agree with Graham,

I would also suggest to try to modify the rule within the development group.

It sounds like the rule stems from a time when compilers were not mature or perhaps the rule has been motivated by a compiler which had faulty treatment of references. In either case, good modern compilers will properly deal with references and it is definitely possible to lay down a consistent set of guidelines for the proper handling of references.

Sincerely, Chris.

Rattle the cage...

[avi123]

Graham
what do you mean by saying:

"that accepting a pointer means taking ownership of it"

thanks
avi

[NMTop40]

There are two fundamental differences between references and pointers:

1. A reference cannot point to nothing.
2. A reference can only point to one object during its lifetime.

int a = 2;
int b = 3;

int * x = &a;
x = &b;

std::cout << "a = " << a << std::endl; 

a should still be 2. The pointer x is pointing to b.

int a = 2;
int b = 3;

int & x = a;
x = b;

std::cout << "a = " << a << std::endl; 

and you should find that a is now 3.

[Graham]

Originally posted by avi123
Graham
what do you mean by saying:

"that accepting a pointer means taking ownership of it"

thanks
avi

Basically, that you take responsibility for deleteing it.

[mwilliamson]

Just out of curiosity, why don't you ask your co-workers how do it? Should you been doing it the way your company wants to and not the way we want to?

[spoulson]

I'm resurrecting this thread to ask one other thing about passing std::string.

What about a function returning std::string?

suppose:

std::string test(std::string &str) {
   std:string s;
   s = str;
   s.append("This is a string.");
   return(s);
}

std::string str1, str2;
str1 = "Data...";

// Does this call the operator= method and copy the returned data?
// Or does it merely memcpy the data structure?
// When does the returned std::string get deleted?
// Is this even safe?  Memory leaks?
str2 = test(str1);

// Could I even do this?
str2 = test(string("More data..."));

Is there a safe way to return STL containers from a function, or should I always use an output variable like:

void test(std::string &ret) {
   ret = "This is a string.";
}

[Paul McKenzie]

I'm resurrecting this thread to ask one other thing about passing std::string.

What about a function returning std::string?


// Does this call the operator= method and copy the returned data?
// Or does it merely memcpy the data structure?

The operator = is called. Also, forget that memcpy() exists -- that's the easiest way to explain what happens.

// When does the returned std::string get deleted?

When it goes out of scope, just like any other object.

// Is this even safe? Memory leaks?
str2 = test(str1);

If it weren't safe, no one would be using std::string, except for toy programs.

The bottom line is that for all the classes in the standard library (and for your own classes), it is imperative that the class behaves just like a built-in type when it comes to assignment, copying, and destruction. If not, we would have the some of the most buggiest programs to maintain and fix.

Is there a safe way to return STL containers from a function,

This is not an STL issue. Any class, whether it is an STL class or whether it's one that you wrote, must be properly assignable and copyable. Again, if this is not the case, the class is buggy. If we return an STL object or your own object from a function, it better have correct copy semantics. So the answer to your question is yes, there is absolutely nothing wrong in terms of memory leaks when returning an STL container.

Regards,

Paul McKenzie

[spoulson]

Good answer.

So, let me ask, when exactly does a returned type go out of scope? I was afraid that it would go out of scope before getting assigned to the return variable or something like that.

[Luchin_plusplus]

As far as I know, a returned type goes out of scope when the function ends (yes, that simply). But the copying of the returned object into a temporary occurs before the function ends. Then when re-assumming the previous scope the object in the temproary adress is copied into the destination adress (the object being assigned to). And in certain cases where the returned object is constructed while returning, it is considered to be the temporary object and it is worked outside the function scope.

But I'm not an expert :-D, I just debug a lot...