Related
I come from a java background but am now working on large C++ code bases. I often see this pattern:
void function(int value, int& result);
And above method is called like so:
int result = 0;
function(42, result);
std::cout << "Result is " << result << std::endl;
In java, the following would be more common:
int result = function(42);
Although the above is perfectly possible in C++, how come the former appears more common (in the codebase I'm working on at least)? Is it stylistic or something more?
First, this used to be an established technique to have more than one output of a function. E.g. in this signature,
int computeNumberButMightFail(int& error_code);
you would have both the payload int as the return value, and a reference to some error variable that is set from within the function to signal an error. It is clear these days that there are better techniques, e.g. std::optional<T> is a good return value, there might be a more flexible std::expected<T, ...>, and with newer C++ standards, we can return multiple values with std::make_tuple and destructure them at the call side with structured bindings. For exceptional error scenarios, the usual approach is to use... well... exceptions.
Second, this is an optimization technique from the days in which (N)RVO wasn't widely available: if the output of a function is an object that is expensive to copy, you wanted to make sure no unnecessary copies are made:
void fillThisHugeBuffer(std::vector<LargeType>& output);
means we pass a reference to the data in order to avoid an unnessecary copy when returning it by value. However, this is outdated, too, and returning large objects by value is usually considered the more idiomatic approach, because C++17 guarantees something called materialization of temporaries and (name) return value optimization is implemented by all major compilers.
See also the core guidelines:
F.20 - "For “out” output values, prefer return values to output parameters".
as far as I know, this case is not common in C++ at least not with primitive data types as return values. There are a few cases to consider:
If you working with plain C or in a very restricted context, where C++ exceptions are not allowed (like realtime applications). Then the return value of a function is often used to indicate the success of a function. An in C could be:
#include <stdio.h>
#include <errno.h>
int func(int arg, int* res) {
if(arg > 10) {
return EINVAL; //this is an error code from errnoe
}
... //do stuff
*res = my_result;
}
This is sometimes used in C++ as well and so the result must by assigned by reference/pointer.
When your result is struct or object which exists before the call of your function and the purpose of your function is to modify attributes inside the struct or object. This is a common pattern because you have to pass the argument by reference (to avoid a copy) anyway. So it is not necessary to return the same object as you pass to the function. An example in C++ could be:
#include <iostream>
struct Point {
int x = 0;
int y = 0;
};
void fill_point(Point& p, int x, int y) {
p.x = x;
p.y = y;
}
int main() {
Point p();
fill_point(p);
return EXIT_SUCCESS;
}
However, this is a trivial and there are better solutions like defining the fill-function as a method in the object. But sometimes with regard to the single-responsible paradigm of objects this pattern is common under more complex circumstances.
In Java you can't control your heap. Every object you define is on the heap and automatically passed by reference to a function. In C++ you have the choice where you wan't your object stored (heap or stack) and how to pass the object to a function. It is important to keep in mind that a pass by value of an object copies it and returning an object from a function by value also copies the object. For returning an object by reference you have to ensure that its lifecycle exceeds the scope of your function by placing it on the heap or by passing it to the function by reference.
Modifiable parameters that receive values as a side effect of a function call are called out parameters. They are generally accepted as a bit archaic, and have fallen somewhat out of fashion as better techniques are available in C++. As you suggested, returning computed values from functions is the ideal.
But real-world constraints sometimes drive people toward out parameters:
returning objects by value is too expensive due to the cost of copying large objects or those with non-trivial copy constructors
returning multiple values, and creating a tuple or struct to contain them is awkward, expensive, or not possible.
When objects cannot be copied (possible private or deleted copy constructor) but must be created "in place"
Most of these issues face legacy code, because C++11 gained "move semantics" and C++17 gained "guaranteed copy elision" which obviate most of these cases.
In any new code, it's usually considered bad style or a code smell to use out parameters, and most likely an acquired habit that carried over from the past (when this was a more relevant technique.) It's not wrong, but one of those things we try to avoid if it's not strictly necessary.
There are several reasons why an out parameter might be used in a C++ codebase.
For example:
You have multiple outputs:
void compute(int a, int b, int &x, int &y) { x=a+b; y=a-b; }
You need the return value for something else: For example, in PEG parsing you might find something like this:
if (parseSymbol(pos,symbolName) && parseToken(pos,"=") && parseExpression(pos,exprNode)) {...}
where the parse functions look like
bool parseSymbol(int &pos, string &symbolName);
bool parseToken(int &pos, const char *token);
and so on.
To avoid object copies.
Programmer didn't knew better.
But basically I think, any answer is opinion based, because it's matter of style and coding policies if and how out-parameters are used or not.
This question already has answers here:
Why should I use reference variables at all? [closed]
(8 answers)
Closed 5 years ago.
I am brand new to C++. We have recently begun exploring reference variables in class, and I am very confused about them. Not necessarily how to do them, as I understand that they switch variable values, but more along the lines of WHY a developer would want to do such a thing? What do they accomplish? Do they save memory? Do they avoid having to return information?
Here is part of the project we are working on. We need to include at least one reference variable. I can see how I would write the program without the reference variable, but I don't see where a reference variable would be useful or necessary.
"The user may wish to get an estimate for one to many rooms. The rates are based on the square footage of the walls and/or ceiling. The company estimates that it takes 2.5 hours to paint 200 SF of wall space and 3.2 hours to paint the same area on a ceiling. The labor rate is $40 per hour. If the job for painting WALLS totals more than 1400 SF of space, then the customer receives a 15% discount for all square footage above 1400 square feet. There is no discount for painting ceilings.
The program shall print out a final report of the estimated costs in a professional format.
The program shall ask the user if they want to make more calculations before exiting."
I'm not looking for you guys to do my homework for me, and for reference, we have only just finished with learning functions. I'm pretty good, but there are a LOT of things reading through these sites that I do not understand.
And, essentially, studentID would be set to 21654. Am I understanding this correctly?
Let us try this again:
I have reviewed this suggested duplication. While it does cover the basics of the pros/cons of using reference variables instead of pointers and discusses multitudes of reasons for using both, I am still questioning the basic idea of when (when is is appropriate vs. not necessary) and why (why is appropriate in certain circumstances, what advantages does it give to the program?)
I should use such variables as well as how (the actual syntax and placement). Almost everyone here has been great, and I have learned so much on the subject through my interactions with you. Even as much of this is repetitive and irritating to seasoned coders, it is all new to me, and I needed to be involved in the conversation as much as I needed the information. I have used Stack Overflow for many projects, learning about Java's newString.equalsIgnoreCase(), for instance, and I admire your knowledge. I can only tell you the truth, if that is not good enough then it is what it is.
Alright, let me review my understanding so far:
Reference variables tend to cut down on unwanted modification of variables within a function and/or program.
Reference variables are used to modify existing variables within functions
This is useful as it "moves" values around while minimizing copying of those values.
Reference variables modify existing variables within functions/programs
I don't know if you guys can still read this or not since it has been flagged a duplicate. I've been playing with a few of the mini-programs you guys have given me, re-read portions of my book, done further research, etc., and I think I understand on a rudimentary level. These reference variables allow you to alter and/or use other variables within your code without pulling them directly into your code. I can't remember which user was using the foo(hubble, bubble) example, but it was his/her code that finally made it click. Instead of just using the value, you are actually using and/or reassigning the variable.
A reference variable is nothing but an alias name of the variable. You would use it when you wanted to just pass the value around instead of copying the same variable into memory at a different location. So, using reference, copy can be avoidable which saves the memory.
According to Bjarne Stroustrup's FAQ:
C++ inherited pointers from C, so I couldn't remove them without
causing serious compatibility problems. References are useful for
several things, but the direct reason I introduced them in C++ was to
support operator overloading. For example:
void f1(const complex* x, const complex* y) // without references
{
complex z = *x+*y; // ugly
// ...
}
void f2(const complex& x, const complex& y) // with references
{
complex z = x+y; // better
// ...
}
More generally, if you want to have both the functionality of pointers
and the functionality of references, you need either two different
types (as in C++) or two different sets of operations on a single
type. For example, with a single type you need both an operation to
assign to the object referred to and an operation to assign to the
reference/pointer. This can be done using separate operators (as in
Simula). For example:
Ref<My_type> r :- new My_type;
r := 7; // assign to object
r :- new My_type; // assign to reference
Alternatively, you could rely on type checking (overloading). For
example:
Ref<My_type> r = new My_type;
r = 7; // assign to object
r = new My_type; // assign to reference
Also, read this Stack Overflow question about the differences between a pointer variable and a reference variable.
I will give three reasons, but there are many more.
Avoiding unnecessary copies.
Suppose you write a function like so:
double price(std::vector<Room> rooms)
{
...
}
Now, every time you call it, the vector of Room will be copied. If you only compute the prices of a few rooms that's fine, but if you want to compute the cost of repainting the entirety of the offices of the Empire State Building, you will start to copy huge objects, and this takes time.
It is better in this case to use a constant reference that provides read-only access to the data:
double price(const std::vector<Room>& rooms) { ... }
Using polymorphism
Suppose you now have different types of rooms, perhaps a CubicRoom and a CylindricalRoom, that both inherit from the same base class, Room.
It is not possible to write:
double price(Room room) { ... }
and then call
price(CylindricalRoom());
//or
price(CubicRoom());
but you can if you define price as follows:
double price(Room& room);
Everything then works the same as if you passed by value.
Avoiding returns
Suppose that each time you compute a price, you want to add a formatted quote to a report. In C++ you can only return a single object from a function, so you can not write:
return price, fmtQuote
However, you can do:
double price(Room room, std::vector<std::string>& quotes)
{
...
quotes.push_back(fmtQuote);
return price
}
Obviously, you could return a pair of objects std::pair<double, std::string>, but this means that the caller has to unpack the result. If you intend to call often the above function, this will quickly become ugly. In this case, this ties in to the first point: the log of all quotes will grow, and you do not want to copy it for each call.
This is a typical access pattern for shared resources: you want a few functions/objects to get a handle on a resource, not a copy of that resource.
You're mixing up two completely separate things here. Three examples to show how the two things work, individually and then together...
A function can take a parameter passed by value, and return a value.
double foo (double y)
{
y = y + 200.0;
return y;
}
void main(void)
{
double hubble = 50.0;
double bubble = 100.0;
hubble = foo(bubble);
std::cout << "hubble=" << hubble << ", bubble=" << bubble << std::endl;
}
Note that because this is passed by value, even though foo() changes y, bubble does not change. hubble is set to the value returned by foo().
Then you get
hubble=300, bubble=100
A function can take a parameter passed by reference, and modify that parameter.
void foo (double& y)
{
y = y + 200.0;
}
void main(void)
{
double hubble = 50.0;
double bubble = 100.0;
foo(bubble);
std::cout << "hubble=" << hubble << ", bubble=" << bubble << std::endl;
}
Then you get
hubble=50, bubble=300
Of course hubble hasn't changed. But because bubble was passed by reference, the change to y inside foo() changes bubble, because that change is happening on the actual variable passed and not on a copied value.
Note that you do not have a "return" statement here. The function does not return anything - it simply modifies the variable which is passed to it.
And of course you can use both together.
double foo (double& y)
{
y = y + 200.0;
return y + 400.0;
}
void main(void)
{
double hubble = 50.0;
double bubble = 100.0;
hubble = foo(bubble);
std::cout << "hubble=" << hubble << ", bubble=" << bubble << std::endl;
}
Then you get
hubble=700, bubble=300
As before, changing y inside foo() changes bubble. But now the function is returning a value as well, which sets hubble.
Why would you choose to return a value, or to modify the value passed in, or to do both? That entirely depends on how you write your code.
I agree with you that you don't have to use a pass-by-reference here. Myself, I'd probably just return a value. But this is a learning exercise, and you've been told to do it that way, so you've got to. Suppose your pass-by-reference is the discount? So a function "void discount(double& value)" takes the value passed and multiplies it by 0.85. It's a bit artificial, but it would demonstrate the principle.
Reference variables are a safer alternative to pointers. Usually, when dealing with pointers you don't really care about the pointer (ptr) so much as what it points to (*ptr); and yet, all the time programmers screw up and manipulate ptr instead of *ptr and so on. Consider this code:
void zeroize_by_pointer(int* p)
{
p = 0; // this compiles, but doesn't do what you want
}
Compare to the reference version,
void zeroize_by_reference(int& p)
{
p = 0; // works fine
}
There are many other reasons why references are a good idea, but for someone starting out in C++ I'd suggest focusing on this one: it makes it slightly harder to shoot yourself in the foot. Whenever you deal with pointers you're going to be dealing on some level with the machine's memory model, and that's a good thing to avoid when possible.
There is another, more general advantage of references that pointers do not provide. References by their very nature allow you to express through the function signature that the object referred to must exist at the time the function is called No nulls allowed.
The caller cannot reasonably expect a function that takes a reference to check the validity of that reference..
Pointers, on the other hand, may validly be null. If I write a function that accepts a pointer...
void increment(int* val)
{
(*val)++;
}
...and the caller supplies null, my program is probably going to crash. I can write all the documentation I want stating that the pointer must not be null but the fact is it's pretty easy for someone to pass it in accidentally. So if I want to be safe, I must check for it.
But write this function with a reference and the intent is clear. No nulls allowed.
References were introduced primarily to support operator overloading. Using pointers for "passing via reference" would give you unacceptable syntax according to Bjarne Stroustrup. They also allow aliasing.
In addition, they allow object-oriented programming with a nicer syntax than using pointer explicitly. If you are using classes you must pass references to avoid object slicing.
In summary, you should always prefer using references over bare pointers.
You could almost always use reference variables (instead of ever passing by value): for example ...
// this function creates an estimate
// input parameter is the Rooms to be painted
// passed as a const reference because this function doesn't modify the rooms
// return value is the estimated monetary cost
Money createEstimate(const Rooms& rooms)
{
...
}
// this function adds paint to the rooms
// input parameter is the Rooms to be painted
// passed as a non-const reference because this function modifies the rooms
void paintRooms(Rooms& rooms)
{
...
}
When you pass-by-value instead of pass-by-reference then you implicitly create and pass a copy of the thing ...
// creates and passes a copy of the Rooms to the createEstimate function
Money createEstimate(Rooms rooms)
{
...
}
... which (creating a copy) is (often, slightly) slower than passing by reference (furthermore, creating a copy may have side-effects).
As a possible slight performance optimization, and by convention (because people don't care), it's common to pass-by-value instead of pass-be-reference when the type is small and simple (a.k.a. a "primitive" type), for example:
// passes a copy of the x and y values
// returns the sum
int add(int x, int y)
{
...
}
... instead of ...
// passes a reference to x and y
// returns the sum
int add(const int& x, const int& y)
{
...
}
See also Passing a modifiable parameter to c++ function as well as Why have pointer parameters?
There are also different kinds of references. We have lvalue and rvalue references, designated by & and &&, respectively. Generally, a reference tells us something about the lifetime of the object it references, a pointer does not. Compare
void foo(int* i);
void foo(int& i);
void foo(int&& i);
In the first case, i might point to an object we can assign to, but more importantly, it may also be a nullptr or point to one-past-the-end of an array. Thus, dereferencing it may lead to undefined behaviour. Checking for a nullptr is easy enough, the other check is not.
The the second case and third case, i must always reference an valid int we can assign too.
The difference between rvalue and lvalue references is that rvalue/&& references convey the meaning that the referenced value is not needed by anyone else and as such, allows for optimizations. Read up on std::move and move constructors to see what I mean.
To summarize: references tell us something about the object's lifetime. Sure, this could be stated in the documentation, but with pointers, violations of that contract might be hard to catch. References enforce the contract (to a high degree) at compile time and as such provide documentation to the code implicitly. This allows for some quick, uncomplicated optimizations by using e.g. move constructors or perfect forwarding in some cases.
Reference arguments are more used when you pass an object as argument. That way you don't copy the whole variable; usually they come with a const modifier like:
void printDescription(const Person& person) { ... }
That way you don't copy the object.
Sometime the return type is also set as a reference. That way you are returning the same object (and not a copy of it). Have a look at the << operator of ostream. ostream& operator<< (streambuf* sb );.
With variables you can think about the case where you can swap values.
void swap(int & a, int & b) {
int aux = a;
int a = b;
int b = aux;
}
This case in Java, for example, has to be done in a more complex way.
Reference variables are pointers without a * and practically without pointer arithmetics.
They are not needed from the C++, they are only syntactic sugar around them.
The initial idea of the creators was probably to make C++ code better comprehensible, although they reached its exact opposite.
My opinion is that a C++ program is better if it entirely misses reference variables and it uses only pointers.
Your function in the form
double foo (double studentID* y)
{
*y = 21654;
return *y;
}
...would do exactly the same, but it would be actually better comprehensible.
I am trying to find out using the below code with sort an array in asscending order. And I find method 1,2,3,4 all get the same result:1234.
Which method is the best?
And when and why should should I use pointer /reference? Thanks you.
Using & to call, and * in function parameter
Just used * in function parameter
Just used & in function parameter
nothing:
#include <iostream>
using namespace std;
void swap(int a,int b){
int t;
t=a;
a=b;
b=t;
}
void main(){
int a[]={1,2,3,4};
for (int i=1; i<3; i++)
for (int j=3; j>i;j--)
if(a[j]<a[j-1])
swap(a[j],a[j-1]);
cout << a[0] <<a[1]<<a[2]<<a[3];
}
Your first two versions are identical. They both explicitly pass a pointer in to the function.
Your third version has the same semantics, but different syntax. References can be seen as pointers with nicer syntax.
Your fourth version doesn't actually swap the variables you pass in because you pass by value, so they are copied.
I would prefer the third version as it is clearer.
Generally, references are more of a convenience thing. They allow the programmer to pass objects by reference without explicitly saying they want to do so
For example, this code
// C-style pointers
some_func(int* x, int* y)
{
(*x)++;
(*y)++;
}
...
int x = 5, y = 8;
some_func(&x, &y);
// x == 6 and y == 9
Is effectively equal to this code
// C++-style references
some_func(int& x, int& y)
{
x++;
y++;
}
...
int x = 5, y = 8;
some_func(x, y);
// x == 6 and y == 9
Both achieve the same result.
Also, in the case with classes/structs, references allow you to have direct access to class/struct members without having to type that stupid arrow (->):
class Example
{
public:
Example();
int x;
int y;
}
...
void do_something(Example& ex)
{
ex.x++;
ex.y++;
}
instead of
class Example
{
public:
Example();
int x;
int y;
}
...
void do_something(Example* ex)
{
ex->x++;
ex->y++;
}
Please note that references used in this manner are a C++ feature only (there is no support for this in C). In C++ you have the choice of using either pointers or references, but IMHO references look 'cleaner' and require less typing (thus reducing the risk of RSI).
I don't see a difference between 1. and 2.. But in general:
Passing pointers is passing an address to a variable. Then you modify something under this address using dereference i.e. *a.
Same.
Is passing via reference, it is basically equivalent of passing pointers with nicer syntax. There are of course some "minor" (from a beginner's point of view) differences, such as, you cannot make an empty reference (nullptr).
Is passing by value, which does not operate on original operands but on their copies. At the function call, temporary copies of arguments are made. This means, you won't see changes to the argument outside of the function.
The general order of preference is:
Use references, or const references.
If you need to make a copy of the object anyways, pass by value.
Smart pointers.
Pointers. Normal user should almost never need to resort to this.
Using references is preferred, because c++ prefers value-semantics. In other words, treating things like variables, i.e. not handlers/pointers. So when you pass a variable to a function, you type it naturally, even if you want to change it. You want to use the object, you pass the object. You don't care that under the hood it uses handlers.
Pointers are generally reserved for operations which deal with ownership of objects.
Separating pointers and references in such way makes it possible to express separate semantics with separate syntax. This makes code more readable.
First of all, I would like to point out that you shouldn't have used
int a[]={1,2,3,4};
in your code, because your program will always display 1234 even if your swap function does not work well. Therefore, you should use something like
int a[]={2,4,1,3};
Secondly, method 1 and method 2 are exactly same. There's no difference at all.
Thirdly, method 4 does not work properly, because the data in the array 'a' hasn't been modified. This happens because you have passed the variables 'by value' rather than 'by reference'. You are getting 1234 as output because that's what you have assigned to the array.
Finally, the only choice you have is between 'method 1' and 'method 3'.
I would suggest 'method 3' because it is simpler to use and less prone to confusion (and errors) as compared to 'method 1'.
In some cases, passing by reference allows the compiler to keep a register based variable in that same register in the called function (as opposed to storing the value in local memory and passing an address to that local memory to the called function).
I need a once-and-for-all clarification on passing by value/pointer/reference.
If I have a variable such as
int SomeInt = 10;
And I want to pass it to a function like
void DoSomething(int Integer)
{
Integer = 1;
}
In my current scenario when passing SomeInt to DoSomething() I want SomeInt's value to be updated based on whatever we do to it inside of DoSomething() as well as be most efficient on memory and performance so I'm not copying the variable around?. That being said which of the following prototypes would accomplish this task?
void DoSomething(int* Integer);
void DoSomething(int& Integer);
How would I actually pass the variable into the function? What is the difference between the previous two prototypes?
Finally if using a function within a class
class SomeClass
{
int MyInteger;
public:
void ChangeValue(int& NewValue)
{
MyInteger = NewValue;
}
};
If I pass an integer into ChangeValue, when the integer I passed in get's deleted will that mean when I try to use MyInteger from within the class it will no longer be useable?
Thank you all for your time, I know this is kind of a basic question but the explanations I keep running into confuse me further.
Functionally, all three of these work:
pass an int and change the return type to int so you can return the new value, usage: x = f(x);
when you plan to set the value without needing to read the initial value, it's much better to use a function like int DoSomething(); so the caller can just say int x = f(); without having to create x on an earlier line and wondering/worrying whether it needs to be initialised to anything before the call.
pass an int& and set it inside the function, usage: int x; x = ? /* if an input */; f(x);
pass an int* and set the pointed-to int inside the function, usage: int x; x = ?; f(&x);
most efficient on memory and performance so I'm not copying the variable around
Given the C++ Standard doesn't dictate how references should be implemented by the compiler, it's a bit dubious trying to reason about their characteristics - if you care compile your code to assembly or machine code and see how it works out on your particular compiler (for specific compiler commandline options etc.). If you need a rule of thumb, assume that references have identical performance characteristics to pointers unless profiling or generated-code inspection suggests otherwise.
For an int you can expect the first version above to be no slower than the pointer version, and possibly be faster, because the int parameter can be passed and returned in a register without ever needing a memory address.
If/when/where the by-pointer version is inlined there's more chance that the potentially slow "needing a memory address so we can pass a pointer" / "having to dereference a pointer to access/update the value" aspect of the pass-by-pointer version can be optimised out (if you've asked the compiler to try), leaving both versions with identical performance....
Still, if you need to ask a question like this I can't imagine you're writing code where these are the important optimisation choices, so a better aim is to do what gives you the cleanest, most intuitive and robust usage for the client code... now - whether that's x = f(x); (where you might forget the leading x =), or f(x) where you might not realise x could be modified, or f(&x) (where some caller might think they can pass nullptr is a reasonable question in its own right, but separate from your performance concerns. FWIW, the C++ FAQ Lite recommends references over pointers for this kind of situation, but I personally reject its reasoning and conclusions - it all boils down to familiarity with either convention, and how often you need to pass const pointer values, or pointer values where nullptr is a valid sentinel, that could be confused with the you-may-modify-me implication hoped for in your scenario... that depends a lot on your coding style, libraries you use, problem domain etc..
Both of your examples
void DoSomething(int* Integer);
void DoSomething(int& Integer);
will accomplish the task. In the first case - with pointer - you need to call the function with DoSomething(&SomeInt);, in the second case - with reference - simpler as DoSomething(SomeInt);
The recommended way is to use references whenever they are sufficient, and pointers only if they are necessary.
You can use either. Function call for first prototype would be
DoSomething(&SomeInt);
and for second prototype
DoSomething(SomeInt);
As was already said before, you can use both. The advantage of the
void DoSomething(int* Integer)
{
*Integer=0xDEADBEEF;
}
DoSomething(&myvariable);
pattern is that it becomes obvious from the call that myvariable is subject to change.
The advantage of the
void DoSomething(int& Integer)
{
Integer=0xDEADBEEF;
}
DoSomething(myvariable);
pattern is that the code in DoSomething is a bit cleaner, DoSomething has a harder time to mess with memory in bad ways and that you might get better code out of it. Disadvantage is that it isn't immediately obvious from reading the call that myvariable might get changed.
Take this code:
struct mystruct
{
int var;
mystruct() : var(0) {}
};
int main()
{
mystruct ins;
int* p = &ins.var;
*p = 1;
}
So what are some concrete really good examples of uses for the class member pointer?
int X::*p = &X::data; /* p contains offset */
X object;
X *objptr = new X;
int i = object.*p;
int j = objptr->*p;
It seems the your question is about pointers of pointer-to-data-member type. In C++ there are also pointers of pointer-to-member-function type. The two have something in common at some abstract level, but otherwise they are different.
Pointer of pointer-to-data-member type is applicable to any instance of the class. An ordinary pointer always points to a member of a specific instance of the class. Pointer of pointer-to-data-member type is a higher level implementation of the idea of "run-time offset" from the beginning of a class object. It is a relative pointer. In that way it is completely different thing from ordinary pointers, which are absolute pointers.
To illustrate that with an example, let's say you have an array of classes with three members of the same type x, y and z
struct Point { int x, y, z; };
Point point_array[N];
and you need to set all members with the same name to 0 in the entire array, without changing any other members. Here's how you can do it using a pointer of pointer-to-data-member type
void zero_members(Point points[], int n, int Point::*m) {
for (int i = 0; i < n; ++i)
points[i].*m = 0;
}
Now, by using this function you can do
zero_members(point_array, N, &Point::x);
to set all xs to zero. Or you can do
zero_members(point_array, N, &Point::y);
to set all ys to zero. You do can all this with a single function, and what's also important, the member selection is performed by a run-time parameter (as opposed to a compile-time one).
You cannot do something like this with ordinary pointers. In fact, you can't do it in any other way.
So that you can access the member on multiple instances.
Uhm, this is akin to asking for good examples of using goto... ;-) Okay, it's there, and sometimes it can be handy, but any example of "good" use of goto is likely to be disputed. And so also for member pointers, they're pretty low-level.
For member function pointers one common usage is in event-driven systems. Package a member function pointer together with a pointer to an object of the relevant class, and you have something very much like a C# delegate. You can then pass this little functor package around, and someone else's code, e.g. a GUI framework, can call back on your object without even knowing about it.
The Boost library provides some support for that, e.g. boost::function and boost::bind, and so does TR1 and the upcoming C++0x standard library (essentially a subset of the Boost functionality).
I can't offhand think of any common usage of data member pointers, though.
Regarding "low level", member pointers follow special rules which let you inadvertently bypass a protected access restriction.
Cheers & hth.,
– Alf