-
December 9th, 2003, 02:07 AM
#16
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?
-
December 9th, 2003, 04:30 AM
#17
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.
Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
-- Sutter and Alexandrescu, C++ Coding Standards
Programs must be written for people to read, and only incidentally for machines to execute.
-- Harold Abelson and Gerald Jay Sussman
The cheapest, fastest and most reliable components of a computer system are those that aren't there.
-- Gordon Bell
-
December 9th, 2003, 06:52 AM
#18
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...
You're gonna go blind staring into that box all day.
-
December 9th, 2003, 07:20 AM
#19
Graham
what do you mean by saying:
"that accepting a pointer means taking ownership of it"
thanks
avi
-
December 9th, 2003, 08:20 AM
#20
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.
-
December 9th, 2003, 09:03 AM
#21
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.
Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
-- Sutter and Alexandrescu, C++ Coding Standards
Programs must be written for people to read, and only incidentally for machines to execute.
-- Harold Abelson and Gerald Jay Sussman
The cheapest, fastest and most reliable components of a computer system are those that aren't there.
-- Gordon Bell
-
December 9th, 2003, 11:07 PM
#22
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?
-
October 14th, 2004, 05:38 PM
#23
Re: std::string as function parameter
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.";
}
-
October 14th, 2004, 05:49 PM
#24
Re: std::string as function parameter
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.
// 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
-
October 14th, 2004, 05:56 PM
#25
Re: std::string as function parameter
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.
-
October 15th, 2004, 07:43 AM
#26
Re: std::string as function parameter
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...
You're not watching "24"?
Well... you should.
24
Jack IS back...
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|