std::string as function parameter

Hello,

I have planty of functions which have std::string as parameter
the string value isn't change inside those functions (I send them as a const)

My question is, should I pass the std::string by value like it was int/double etc
or by reference like I do with structs?

I mean

const std::string myString

func1(myString)

should I define func1 like this:
std::string func1(const std::string& myStr)

or

std::string func1(const std::string myStr)


is std::string is a big structure needs using reference?

thanks a lot
avi

Avi,

You should probably send them in as constant references. This avoids copying the input string into the subroutine and results in improved run-time performance.

Sincerely, Chris.

:)

Quote:

---

is std::string is a big structure needs using reference?

---

Well...as dude_1967 already indicated...if a function does not change the contents of a variable you should basically pass them as a constant reference. However, this is only a matter while dealing with structures and/or classes. Simple data types can be still passed by value since passing by reference would only add unnecessary overhead.

In addition, you might want to take a look at this article....

and stl string is for that matter like basic type as int or double
or like a class/struct??

thanks

std::string is a class.

A reason to use const references instead of const pointers is that strings rely on overloaded operators to behave naturally. "str[5]" is certainly much more readable that "(*str)[5]".

Jeff

Well, basically if you consider what has to be done then the answer will be obvious. If you pass by reference, the computer will have to copy the address of the paramter; 4 bytes on the 32bit system. Now if you pass by value, the whole string will have to be copied. So if the string is longer than 4 bytes it will be slower. In fact, since new memory has to be allocated, it will almost always be slower to copy and reference it. This goes for any other type as well, including a structure. If you structure is longer than 4 bytes it will be more effient to pass it by reference.

Additional, const std::string means next to nothing. It creates a copy and doesn't allow you to modify it. That does make any sense, there is no reason you shouldn't be able to modify the copy. You should pass as const std::string&.

if I can't use reference (that's one of the project rules)
should I use a string or a pointer to a string?

thanks

avi123,

The pointer would still be preferable. Just use:

Code:

---


const std::string*

---

and access the class methods with the -> operator.

Sincerely, Chris.

:)

why does it have to do with the length of my string?
no matter what the size of my string is sizeof(std::string) is 28
which is 7 times 4, so I guess I should pass it with pointer...

avi123,

The size of std::string is independent of the length of the string since the internal data are managed as a dynamically allocated pointer to character data. However, all copy operations operating on a given std::string will copy the internal data as well. Thus the run-time of the copy operations depends on the length of the std::string data.

Sincerely, Chris.

:)

P.S. Like Dr. Ruth said, it's not the length of the std::string that matters, but rather how you use it...

Well I just gained new respect for Dr. Ruth. I had no idea she was
C++ programmer

Quote:

---

Originally posted by avi123
if I can't use reference (that's one of the project rules)
should I use a string or a pointer to a string?

thanks

---

One of these stupid assignments - why impose a rule that you can't pass a reference when that is a basic part of C++?

Much of the time if you copy a string it will optimise such that the contents are copied only when one of them are modified.

The purpose of this optimisation so that you can return a string as a return value from a function.

There are still the overheads of creating a new class though - it is a different object, just the strings they point to are in the same memory space.

Quote:

---

Originally posted by avi123
if I can't use reference (that's one of the project rules)
should I use a string or a pointer to a string?

---

If you can't use a reference, this must be an assignment, in which case the small optimization of passing by reference is unimportant.

Pass by value. It will look cleaner.

Jeff

Quote:

---

Originally posted by avi123
why does it have to do with the length of my string?
no matter what the size of my string is sizeof(std::string) is 28
which is 7 times 4, so I guess I should pass it with pointer...

---

When you pass an object by value, the objects copy constructor is called. This makes perfect sense, since if the compiler is going to create a temporary object, it had better construct the object correctly. The only way to do this is to use the copy constructor.

Since std::string's copy constructor copies the string contents from the current string to the newly constructed string, then you may see a performance hit if you pass a std::string that has 1,000,000 bytes of data by value.

I say may see a performance hit, since some std::string implementations use reference-counting, so that copying from one string to another incurs little overhead. However, it doesn't take away from the fact that passing objects by value will incur a copy constructor call by the compiler.

That is why it seems weird to me why it is "project rules" to pass objects by value, and not reference. Are the person(s) there you work with aware that passing everything by value may slow down your app (maybe to a crawl) if what they are passing has expensive (in terms of time) copy constructors? The role of a good C++ programmer is to know what can be passed by reference and by value, not just in terms of "what compiles", but also in terms of efficiency.

Regards,

Paul McKenzie

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?

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.

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...

:)

Graham
what do you mean by saying:

"that accepting a pointer means taking ownership of it"

thanks
avi

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.

PHP Code:

---

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.

PHP Code:

---


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.

Quote:

---

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.

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?

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

What about a function returning std::string?

suppose:

Code:

---

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:

Code:

---

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

---

Quote:

---

Originally Posted by spoulson

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.

Quote:

---

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

---

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

Quote:

---

// 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.

Quote:

---

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

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.

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... :confused: