From this code:
int x = 5;
int other = 10;
vector<int*> v_ptr;
v_ptr.push_back(&x);
v_ptr.push_back(&other);
v_ptr.push_back(&x);
Is there anyway I can know who points at x, from the x variable itself, so that I don't have to search inside v_ptr for address of x? Is this possible in C++ or C++0x?
I read that when doing garbage collection, they look at memory and see if anything points at it or not, then make decisions to delete the unused variable, etc.
No. It is like asking a person if they know everyone who knows their address.
No, you can not know what has a reference to x without iterating through the possible places you assigned it(v_ptr)
--Or--
If you must do this, you may want to do some kinda reference tracking(which can be used for garbage collection) like
v_ptr[0]=add_reference(&x,&v_ptr[0]);
where add_reference is some function to have a list of references made to the first argument, with the referrer as the second argument(which may be tricky with STL types)
No it is not possible to know who points at x.
In addition C++ is not garbage collected.
Even if you use shared_pointer's to x, you can find out how many pointers there are to x, but not whom they are.
No, it is not possible to know this with a raw pointer.
Certain types of "smart pointers" (which are actually objects that contain pointers plus other meta-data about the pointer) keep as part of their meta-data a list or count of all references to the pointed-to object from other smart pointers. In garbage collected languages, this mechanism is used to determine if an object is no longer referenced, but it is not a characteristic of a standard C or C++ pointer.
In addition to the other accurate answers here, note that in garbage collected languages (C++.NET, I guess, or any of the normal other ones, Java/C#, etc), one technique for garbage collection is to traverse references, marking everything that is pointed to.
But note that this actually works the other direction. I start from a known set of objects, and follow all of their links to other objects, etc. I generally never am able to say "given this object, let me calculate who points to it or holds references to it".
The answer to your actual question is no, C++ doesn't have a mechanism for figuring out how many references are still active. Nonetheless,while C++ is not garbage collected, if you're interested, you can try one of the gc_classes. Here's a stackoverflow post listing some of them: Garbage collection Libraries in C++
Yes, you can know if--at a given point in execution--there is a pointer to your variable. All you need to do is keep track of the memory allocated to every variable in the process. This means knowing the start and end addresses of the stack and the heap. You can then do a simple sequential search for the location of your variable in those address ranges.
Though iterating over those relatively small portions of memory should not take long, you could optimize the search time at the expense of some additional memory overhead and pointer creation overhead by maintaining a structure that tracks only references. That gives you a smaller list to search.
Related
I am considering a problem and can't come to a conclusive "better" of the two options. It comes down to deciding whether a complex data member (ie, not a primitive) should be a pointer or simply a value. (Note, I have seen many questions about pointer vs reference for data members, but nothing regarding pointer vs value) The biggest things I'm weighing are
Lifespan of the data member (whether it lives the full life of it's owner).
In the case when it does last the full lifespan, reducing memory fragmentation.
Consider the following code:
class PlayerStatistic
{
int m_MaxValue;
int m_CurrentValue;
// And many other things that round out a player statistic
}
class PlayerStatisticManager
{
//While in this case, it may be better to store stats as a list of some kind and
//identify them by a StatId or something, for this example, I'm declaring them
//individually.
PlayerStatistic* m_pHealth;
//OR
PlayerStatistic m_Health;
// And many more statistics.
}
In the above example, every player always has health. Their health statistic is ALWAYS the lifespan of the StatisticManager, which in turn is ALWAYS the lifespan of the player.
If this weren't the case, I would prefer the pointer, so that NULL can be indicative that the object doesn't exist (which might be better for a stat that not all players have).
However, because that's not the case, I think I would rather have it stored as value, in order to make fewer larger memory allocations, rather than many small memory allocations.
Is my thinking sound, or is there something I'm not considering?
Edit - My choice of words ("pointer vs value") was poor. What I meant was what one of the answers clarified:
What you are referring to here is weather it's better to have the
mHealth statically or dynamically allocated;
Moreover, in this case, I know that health's lifespan is the player's lifespan, so my question basically comes down to memory. Is it better memory management to statically allocate data members in the interest of having fewer allocations, and instead doing one big allocation (when Player get newed).
One thing you need to consider is how you are going to use the data. Whether you need it to be changed through various routines or simple monitor it in most processes.
If you indeed need to change it and expose the change to other routines, better pass it by reference in which case pointer would be a better solution.
On the other hand, if it is a simple value to be monitored and not changed often, I would suggest pass by value especially monitoring does not happen frequently.
In your case, the following is my analysis:
1. Player health may change frequently in case of event like a battle. The data is better passed by reference in this case.
2. Player health is monitored by a few processes infrequently when not in battle, like when the user is querying the health value. In this case, data is better passed by value so accidental change to the value would not affect the object instance itself.
Personally, I would use pointer in PlayerStaticManager. This gives the option of passing the value or reference in different scenarios. If you need to pass by reference, pass the pointer along. If you need to pass by value, make a copy of the content, pass it along and forget about the copy.
Hope this helps.
Only use a pointer if the lifetime of the member will be different from the lifetime of the containing object.
I think you got things a little miked up: "by reference" or "by value" refers to how you pass parameters to a function. By pointer, or by value is preferred because in that case only the pointer to a memory location is passed; for structures for example, all the members are copied to the stack - adding overhead.
What you are referring to here is weather it's better to have the mHealth statically or dynamically allocated; and that is a design question and depends on the application. Both ways are fine - but there is no ultimate better solution - it depends....
I'm pretty much a beginner at C++. Just started learning it a few weeks ago. I'm really interested in improving my skills as a programmer, and there's something that's been confusing me in the last few days. It is pointers. Pointers and the reference operator. My question is, what exactly is the functionality of the pointers and reference operator? How will I know when to use them, and what are their purposes and common usages. Any examples consisting of common algorithms using dereference and reference will be greatly appreciated.
how can I use reference and dereference to become a better programmer, and improve my algorithms(and possibly make them simpler)?
Thanks :D
Definitely check this question out, the accepted answer explains pointers and common errors with them in a nice manner.
Update: a few words of my own
Pointers are bunches of bits, like any other kind of variable. We use them so much because they have several very convenient properties:
Their size (in bytes) is fixed, making it trivial to know how many bytes we need to read to get the value of a pointer.
When using other types of variables (e.g. objects), some mechanism needs to be in place so that the compiler knows how large each object is. This introduces various restrictions which vary among languages and compilers. Pointers have no such problems.
Their size is also small (typically 4 or 8 bytes), making it very fast to update their values.
This is very useful when you use the pointer as a token that points to a potentially large amount of information. Consider an example: we have a book with pictures of paintings. You need to describe a painting to me, so I can find it in the book. You can either sit down and paint an exact copy of it, show it to me, and let me search the book for it; or you can tell me "it's in page 25". This would be like using a pointer, and so much faster.
They can be used to implement polymorphism, which is one of the foundations of object-oriented-programming.
So, to find out how to use pointers: find cases where these properties will come in handy. :)
There's some things a programmer needs to understand before diving into pointers and C++ references.
First you must understand how a program works. When you write variables out, when you write statements, you need to understand what's happening at a lower level; it's important to know what happens from a computer stand-point.
Essentially your program becomes data in memory (a process) when you execute it. At this point you must have a simple way to reference spots of data - we call these variables. You can store things and read them, all from memory (the computers memory).
Now imagine having to pass some data to a function - you want this function to manipulate this data - you can either do this by passing the entire set of data, or you can do it by passing its address (the location of the data in memory). All the function really needs is the address of this data, it doesn't need the entire data itself.
So pointers are used exactly for this sort of task - when you need to pass address of data around - pointers in fact are just regular variables that contain an address.
C++ makes things a bit easier with references (int &var) but the concept is the same. It lets you skip the step of creating a pointer to store the address of some data, and it does it all automatically for you when passing data to a function.
This is just a simple introduction of how they work - you should read up on Google to search fo more detailed resources and all the cool things you can do with pointers/references.
Better name of the operator is "Address of" operator. Because it returns the address of the operand.
In C++ you will use pointers (and both reference/dereference operators) when dealing with dynamically allocated memory or when working with pointer arithmetic.
Pointers are also used to break down static bindings since they imply dynamic binding (through the address stored in the pointer, which can change dynamically).
For all other uses, it is usually better to use references instead of pointers.
to be short:
reference are some improvment of pointers that inherited from C to C++
its a bit safer because it helps you avoid using "*" in your functions and that cause you less segmentation faults.
or like my frines say "avoid the starwars"
there is a lot to learn about it !!!!
look for the use of "&" for sending and receiving values by refrence
understand the use of "&" for getting variable adress
its a very very big question, if you can be more specific it will be better.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Common Uses For Pointers?
I am still learning the basics of C++ but I already know enough to do useful little programs.
I understand the concept of pointers and the examples I see in tutorials make sense to me. However, on the practical level, and being a (former) PHP developer, I am not yet confident to actually use them in my programs.
In fact, so far I have not felt the need to use any pointer. I have my classes and functions and I seem to be doing perfectly fine without using any pointer (let alone pointers to pointers). And I can't help feeling a bit proud of my little programs.
Still, I am aware that I am missing on one of C++'s most important feature, a double edged one: pointers and memory management can create havoc, seemingly random crashes, hard to find bugs and security holes... but at the same time, properly used, they must allow for clever and efficient programming.
So: do tell me what I am missing by not using pointers.
What are good scenarios where using pointers is a must?
What do they allow you to do that you couldn't do otherwise?
In which way to they make your programs more efficient?
And what about pointers to pointers???
[Edit: All the various answers are useful. One problem at SO is that we cannot "accept" more than one answer. I often wish I could. Actually, it's all the answers combined that help to understand better the whole picture. Thanks.]
I use pointers when I want to give a class access to an object, without giving it ownership of that object. Even then, I can use a reference, unless I need to be able to change which object I am accessing and/or I need the option of no object, in which case the pointer would be NULL.
This question has been asked on SO before. My answer from there:
I use pointers about once every six lines in the C++ code that I write. Off the top of my head, these are the most common uses:
When I need to dynamically create an object whose lifetime exceeds the scope in which it was created.
When I need to allocate an object whose size is unknown at compile time.
When I need to transfer ownership of an object from one thing to another without actually copying it (like in a linked list/heap/whatever of really big, expensive structs)
When I need to refer to the same object from two different places.
When I need to slice an array without copying it.
When I need to use compiler intrinsics to generate CPU-specific instructions, or work around situations where the compiler emits suboptimal or naive code.
When I need to write directly to a specific region of memory (because it has memory-mapped IO).
Pointers are commonly used in C++. Becoming comfortable with them, will help you understand a broader range of code. That said if you can avoid them that is great, however, in time as your programs become more complex, you will likely need them even if only to interface with other libraries.
Primarily pointers are used to refer to dynamically allocated memory (returned by new).
They allow functions to take arguments that cannot be copied onto the stack either because they are too big or cannot be copied, such as an object returned by a system call. (I think also stack alignment, can be an issue, but too hazy to be confident.)
In embedded programing they are used to refer to things like hardware registers, which require that the code write to a very specific address in memory.
Pointers are also used to access objects through their base class interfaces. That is if I have a class B that is derived from class A class B : public A {}. That is an instance of the object B could be accessed as if it where class A by providing its address to a pointer to class A, ie: A *a = &b_obj;
It is a C idiom to use pointers as iterators on arrays. This may still be common in older C++ code, but is probably considered a poor cousin to the STL iterator objects.
If you need to interface with C code, you will invariable need to handle pointers which are used to refer to dynamically allocated objects, as there are no references. C strings are just pointers to an array of characters terminated by the nul '\0' character.
Once you feel comfortable with pointers, pointers to pointers won't seem so awful. The most obvious example is the argument list to main(). This is typically declared as char *argv[], but I have seen it declared (legally I believe) as char **argv.
The declaration is C style, but it says that I have array of pointers to pointers to char. Which is interpreted as a arbitrary sized array (the size is carried by argc) of C style strings (character arrays terminated by the nul '\0' character).
If you haven't felt a need for pointers, I wouldn't spend a lot of time worrying about them until a need arises.
That said, one of the primary ways pointers can contribute to more efficient programming is by avoiding copies of actual data. For example, let's assume you were writing a network stack. You receive an Ethernet packet to be processed. You successively pass that data up the stack from the "raw" Ethernet driver to the IP driver to the TCP driver to, say, the HTTP driver to something that processes the HTML it contains.
If you're making a new copy of the contents for each of those, you end up making at least four copies of the data before you actually get around to rendering it at all.
Using pointers can avoid a lot of that -- instead of copying the data itself, you just pass around a pointer to the data. Each successive layer of the network stack looks at its own header, and passes a pointer to what it considers the "payload" up to the next higher layer in the stack. That next layer looks at its own header, modifies the pointer to show what it considers the payload, and passes it on up the stack. Instead of four copies of the data, all four layers work with one copy of the real data.
A big use for pointers is dynamic sizing of arrays. When you don't know the size of the array at compile time, you will need to allocate it at run-time.
int *array = new int[dynamicSize];
If your solution to this problem is to use std::vector from the STL, they use dynamic memory allocation behind the scenes.
There are several scenarios where pointers are required:
If you are using Abstract Base Classes with virtual methods. You can hold a std::vector and loop through all these objects and call a virtual method. This REQUIRES pointers.
You can pass a pointer to a buffer to a method reading from a file etc.
You need a lot of memory allocated on the heap.
It's a good thing to care about memory problems right from the start. So if you start using pointers, you might as well take a look at smart pointers, like boost's shared_ptr for example.
What are good scenarios where using pointers is a must?
Interviews. Implement strcpy.
What do they allow you to do that you couldn't do otherwise?
Use of inheritance hierarchy. Data structures like Binary trees.
In which way to they make your programs more efficient?
They give more control to the programmer, for creating and deleting resources at run time.
And what about pointers to pointers???
A frequently asked interview question. How will you create two dimensional array on heap.
A pointer has a special value, NULL, that reference's won't. I use pointers wherever NULL is a valid and useful value.
I just want to say that i rarely use pointers. I use references and stl objects (deque, list, map, etc).
A good idea is when you need to return an object where the calling function should free or when you dont want to return by value.
List<char*>* fileToList(char*filename) { //dont want to pass list by value
ClassName* DataToMyClass(DbConnectionOrSomeType& data) {
//alternatively you can do the below which doesnt require pointers
void DataToMyClass(DbConnectionOrSomeType& data, ClassName& myClass) {
Thats pretty much the only situation i use but i am not thinking that hard. Also if i want a function to modify a variable and cant use the return value (say i need more then one)
bool SetToFiveIfPositive(int**v) {
You can use them for linked lists, trees, etc.
They're very important data structures.
In general, pointers are useful as they can hold the address of a chunk of memory. They are especially useful in some low level drivers where they are efficiently used to operate on a piece of memory byte by byte. They are most powerful invention that C++ inherits from C.
As to pointer to pointer, here is a "hello-world" example showing you how to use it.
#include <iostream>
void main()
{
int i = 1;
int j = 2;
int *pInt = &i; // "pInt" points to "i"
std::cout<<*pInt<<std::endl; // prints: 1
*pInt = 6; // modify i, i = 6
std::cout<<i<<std::endl; // prints: 6
int **ppInt = &pInt; // "ppInt" points to "pInt"
std::cout<<**ppInt<<std::endl; // prints: 6
**ppInt = 8; // modify i, i = 8
std::cout<<i<<std::endl; // prints: 8
*ppInt = &j; // now pInt points to j
*pInt = 10; // modify j, j = 10
std::cout<<j<<std::endl; // prints: 10
}
As we see, "pInt" is a pointer to integer which points to "i" at the beginning. With it, you can modify "i". "ppInt" is a pointer to pointer which points to "pInt". With it, you can modify "pInt" which happens to be an address. As a result, "*ppInt = &j" makes "pInt" points to "j" now. So we have all the results above.
How would you locate an object in memory, lets say that you have a struct defined as:
struct POINT {
int x;
int y;
};
How would I scan the memory region of my app to find instances of this struct so that I can read them out?
Thanks R.
You can't without adding type information to the struct. In memory a struct like that is nothing else than 2 integers so you can't recognize them any better than you could recognize any other object.
You can't. Structs don't store any type information (unless they have virtual member functions), so you can't distinguish them from any other block of sizeof(POINT) bytes.
Why don't you store your points in a vector or something?
You can't. You have to know the layout to know what section of memory have to represent a variable. That's a kind of protocol and that's why we use text based languages instead raw values.
You don't - how would you distinguish two arbitrary integers from random noise?
( but given a Point p; in your source code, you can obtain its address using the address-of operator ... Point* pp = &p;).
Short answer: you can't. Any (appropriately aligned) sequence of 8 bytes could potentially represent a POINT. In fact, an array of ints will be indistinguishable from an array of POINTS. In some cases, you could take advantage of knowledge of the compiler implementation to do better. For instance, if the struct had virtual functions, you could look for the correct vtable pointer - but there could also be false positives.
If you want to keep track of objects, you need to register them in their constructor and unregister them in their destructor (and pay the performance penalty), or give them their own allocator.
There's no way to identify that struct. You need to put the struct somewhere it can be found, on the stack or on the heap.
Sometimes data structures are tagged with identifying information to assist with debugging or memory management. As a means of data organization, it is among the worst possible approaches.
You probably need to a lot of general reading on memory management.
There is no standard way of doing this. The platform may specify some APIs which allow you to access the stack and the free store. Further, even if you did, without any additional information how would you be sure that you are reading a POINT object and not a couple of ints? The compiler/linker can read this because it deals with (albeit virtual) addresses and has some more information (and control) than you do.
You can't. Something like that would probably be possible on some "tagged" architecture that also supported tagging objects of user-defined types. But on a traditional architecture it is absolutely impossible to say for sure what is stored in memory simply by looking at the raw memory content.
You can come closer to achieving what you want by introducing a unique signature into the type, like
struct POINT {
char signature[8];
int x;
int y;
};
and carefully setting it to some fixed and "unique" pattern in each object of POINT type, and then looking for that pattern in memory. If it is your application, you can be sure with good degree of certainty that each instance of the pattern is your POINT object. But in general, of course, there will never be any guarantee that the pattern you found belongs to your object, as opposed to being there purely accidentally.
What everyone else has said is true. In memory, your struct is just a few bytes, there's nothing in particular to distinguish it.
However, if you feel like a little hacking, you can look up the internals of your C library and figure out where memory is stored on the heap and how it appears. For example, this link shows how stuff gets allocated in one particular system.
Armed with this knowledge, you could scan your heap to find allocated blocks that were sizeof(POINT), which would narrow down the search considerably. If you look at the table you'll notice that the file name and line number of the malloc() call are being recorded - if you know where in your source code you're allocating POINTs, you could use this as a reference too.
However, if your struct was allocated on the stack, you're out of luck.
I have an object which implements reference counting mechanism. If the number of references to it becomes zero, the object is deleted.
I found that my object is never deleted, even when I am done with it. This is leading to memory overuse. All I have is the number of references to the object and I want to know the places which reference it so that I can write appropriate cleanup code.
Is there some way to accomplish this without having to grep in the source files? (That would be very cumbersome.)
A huge part of getting reference counting (refcounting) done correctly in C++ is to use Resource Allocation Is Initialization so it's much harder to accidentally leak references. However, this doesn't solve everything with refcounts.
That said, you can implement a debug feature in your refcounting which tracks what is holding references. You can then analyze this information when necessary, and remove it from release builds. (Use a configuration macro similar in purpose to how DEBUG macros are used.)
Exactly how you should implement it is going to depend on all your requirements, but there are two main ways to do this (with a brief overview of differences):
store the information on the referenced object itself
accessible from your debugger
easier to implement
output to a special trace file every time a reference is acquired or released
still available after the program exits (even abnormally)
possible to use while the program is running, without running in your debugger
can be used even in special release builds and sent back to you for analysis
The basic problem, of knowing what is referencing a given object, is hard to solve in general, and will require some work. Compare: can you tell me every person and business that knows your postal address or phone number?
One known weakness of reference counting is that it does not work when there are cyclic references, i.e. (in the simplest case) when one object has a reference to another object which in turn has a reference to the former object. This sounds like a non-issue, but in data structures such as binary trees with back-references to parent nodes, there you are.
If you don't explicitly provide for a list of "reverse" references in the referenced (un-freed) object, I don't see a way to figure out who is referencing it.
In the following suggestions, I assume that you don't want to modify your source, or if so, just a little.
You could of course walk the whole heap / freestore and search for the memory address of your un-freed object, but if its address turns up, it's not guaranteed to actually be a memory address reference; it could just as well be any random floating point number, of anything else. However, if the found value lies inside a block a memory that your application allocated for an object, chances improve a little that it's indeed a pointer to another object.
One possible improvement over this approach would be to modify the memory allocator you use -- e.g. your global operator new -- so that it keeps a list of all allocated memory blocks and their sizes. (In a complete implementation of this, operator delete would have remove the list entry for the freed block of memory.) Now, at the end of your program, you have a clue where to search for the un-freed object's memory address, since you have a list of memory blocks that your program actually used.
The above suggestions don't sound very reliable to me, to be honest; but maybe defining a custom global operator new and operator delete that does some logging / tracing goes in the right direction to solve your problem.
I am assuming you have some class with say addRef() and release() member functions, and you call these when you need to increase and decrease the reference count on each instance, and that the instances that cause problems are on the heap and referred to with raw pointers. The simplest fix may be to replace all pointers to the controlled object with boost::shared_ptr. This is surprisingly easy to do and should enable you to dispense with your own reference counting - you can just make those functions I mentioned do nothing. The main change required in your code is in the signatures of functions that pass or return your pointers. Other places to change are in initializer lists (if you initialize pointers to null) and if()-statements (if you compare pointers with null). The compiler will find all such places after you change the declarations of the pointers.
If you do not want to use the shared_ptr - maybe you want to keep the reference count intrinsic to the class - you can craft your own simple smart pointer just to deal with your class. Then use it to control the lifetime of your class objects. So for example, instead of pointer assignment being done with raw pointers and you "manually" calling addRef(), you just do an assignment of your smart pointer class which includes the addRef() automatically.
I don't think it's possible to do something without code change. With code change you can for example remember the pointers of the objects which increase reference count, and then see what pointer is left and examine it in the debugger. If possible - store more verbose information, such as object name.
I have created one for my needs. You can compare your code with this one and see what's missing. It's not perfect but it should work in most of the cases.
http://sites.google.com/site/grayasm/autopointer
when I use it I do:
util::autopointer<A> aptr=new A();
I never do it like this:
A* ptr = new A();
util::autopointer<A> aptr = ptr;
and later to start fulling around with ptr; That's not allowed.
Further I am using only aptr to refer to this object.
If I am wrong I have now the chance to get corrections. :) See ya!