I tend to like pointer usage personally, but that''s mostly because A) I''m an old-school C freak, and B) I, as a programmer, like to know when I''m passing a pointer into a function as opposed to a copy of the object/data/etc... It lets me know if that thing has a chance of being modified.
Of course, one could note that with good commenting, you''d already know that about any given function that you use... so it''s a toss up.
pointers instead of reference: bad programming?
quote:Original post by Doc
I try to avoid writing functions that manipulate parameters like that.
Agreed. Reference parameters (both C++-style references and pointers) should be avoided whenever possible. And between classes and exceptions, there's not often a good reason to return more than one value at a time.
"Sneftel is correct, if rather vulgar." --Flarelocke
[edited by - sneftel on January 25, 2004 9:33:40 PM]
i never use pass-by-reference, with the possible exception of when i learned it in school.
I almost never pass by non-const reference. If I do, though, I will comment it and make sure it is obvious from the name of the function. I use const references instead of pointers because I don''t like to constantly dereference the pointer, but I still don''t want the copy constructor to be called.
I like pass-by-pointer when you want to pass an optional parameter. If the pointer is null then you obviously don't dereference it. I'll declare the function with null default values for the simple case.
Example:
That gives you the choice of calling the function as say MyObject.GetNearestObject() or MyObject.GetNearestObject(pDistance), depending on what your needs are.
Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy
[edited by - BS-er on January 25, 2004 9:50:20 PM]
Example:
// Declaration in class header:CObject* GetNearestObject(float* pDistance = 0);// Implementation:CObject* CObject::GetNearestObject(float* pDistance){ CObject* pNearestObject; float NearestDistance; .... .... if (pDistance) { *pDistance = NearestDistance; } return pNearestObject;}That gives you the choice of calling the function as say MyObject.GetNearestObject() or MyObject.GetNearestObject(pDistance), depending on what your needs are.
Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy
[edited by - BS-er on January 25, 2004 9:50:20 PM]
quote:Original post by BS-er
I like pass-by-pointer when you want to pass an optional parameter. If the pointer is null then you obviously don''t dereference it. I''ll declare the function with null default values for the simple case.
Example:
// Declaration in class header:CObject* GetNearestObject(float* pDistance = 0);// Implementation:CObject* CObject::GetNearestObject(float* pDistance){ CObject* pNearestObject; float NearestDistance; .... .... if (pDistance) { *pDistance = NearestDistance; } return pNearestObject;}
Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy
[edited by - BS-er on January 25, 2004 9:45:05 PM]
Or you could overload.
As some others here, I always use pointers for data that will, or could be, manipulated within the function.
As for dereferencing, when passing pointers it''s usually to larger structs or classes, and to access their members, the dereferencing then becomes the task of using and ''->'' instead of a ''.''. Again this makes it clearer what is really going on.
However, for functions that only use reference to get, and copy, data, like for initializing members in a constructor, c++ reference is probably a nicer and cleaner way of representing it. It will however be descrete to the user of the class/function, and he will just have to hope and pray you''re not passing his large struct by copy
.. at least he won''t have to be bothered writing ''&''s all over the place
As for dereferencing, when passing pointers it''s usually to larger structs or classes, and to access their members, the dereferencing then becomes the task of using and ''->'' instead of a ''.''. Again this makes it clearer what is really going on.
However, for functions that only use reference to get, and copy, data, like for initializing members in a constructor, c++ reference is probably a nicer and cleaner way of representing it. It will however be descrete to the user of the class/function, and he will just have to hope and pray you''re not passing his large struct by copy
.. at least he won''t have to be bothered writing ''&''s all over the placequote:Original post by SneftelUnless you want to fill in a C-string. But since we already have std::string, it doesn''t matter now.quote:Original post by Doc
I try to avoid writing functions that manipulate parameters like that.
Agreed. Reference parameters (both C++-style references and pointers) should be avoided whenever possible. And between classes and exceptions, there''s not often a good reason to return more than one value at a time.
References were added to C++ to make the syntax of operator overloading feasible:
What is important when using them, is to make certain you are not making ''write only code'' (you only know what it does when you write it). It ought to be obvious from the function name that the parameter is mutated. e.g. We do not expect std::find to change what we pass to it, but we expect std::replace to.
Other than operator overloading, I rarely see non-const references.
struct MyArray { Stuff& operator[](int i); const Stuff& operator[](int i) const; }; What is important when using them, is to make certain you are not making ''write only code'' (you only know what it does when you write it). It ought to be obvious from the function name that the parameter is mutated. e.g. We do not expect std::find to change what we pass to it, but we expect std::replace to.
Other than operator overloading, I rarely see non-const references.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
