I understand that when I'm make casting like: <object> p, where p is PyObject* reference counter is increased. Is it possible to cast PyObject* to object without increasing reference counter?
In short: no. Variables typed as Python objects always use reference counters. However depending on what you actually want to do there might be various ways to avoid reference counting. For example if you only need the cast temporarily for accessing a single property you can simply use (<Foo>p).myProperty which does not increase reference counters as far as I've understood (source). This whole thread in the cython-users group also gives some more insights into how to avoid reference counting.
Related
Consider the below example where I create the local variable specialNumber in main(), and pass it by reference to a new thread, as well as another function (please disregard the lack of a lock/mutex):
#include <iostream>
#include <thread>
void threadRun(int& number) {
while(true) {
std::this_thread::sleep_for(std::chrono::seconds(2));
std::cout << number << std::endl;
number += 1;
}
}
int main() {
int specialNumber = 5;
std::thread newThread(threadRun, std::ref(specialNumber));
otherFunction(specialNumber);
newThread.join();
}
void otherFunction(int& number) {
// does something with number
}
I am aware that passing references to local variables around should generally be avoided, as once that function terminates the variable will be out of scope and the reference will be invalid.
However, since the variable is local to main(), and that function won't terminate until the whole program terminates, is there anything wrong with this practice?
My specific use-case would be storing a small object here (mainly consisting of pointers to heap objects along with helper functions), which would be used by multiple threads and/or functions, and passing around a reference to it. I'm aware an alternative is storing it in the heap with a smart pointer such as shared_ptr, but storing such a small object this way seems inefficient to me.
I apologize if any of my terminology is incorrect, I am quite new to C++. Please do correct me!
Your assumption
I am aware that passing references to local variables around should generally be avoided
seems unfounded.
There is nothing wrong with passing references to functions. However, a function that takes a reference to an object should not take ownership of that object. The function should not assume that the referenced object continues to live after it exits.
This is different from returning references to local variables, which is always wrong.
I see no problem (missing synchronization aside) with passing references to threads and this generally preferable to the alternative of using global variables.
Smart pointers, such as std::shared_ptr, are only required if the functions are supposed to take (shared) ownership of the object, e.g. if threadRun wants to keep a reference/pointer to the object after it exits.
As long as the main thread is living you shouldn't see a problem occurring since the lifetime of specialNumber is controlled by it.
However I want to elaborate on the use of std::ref(). One of the uses of std::ref() is precisely the scenario you are coding.
When you use std::ref() you are actually returning a std::reference_wrapper which can be copied. Reference wrappers can be stored in containers whereas plain references cannot.
Passing objects by reference to the constructor of a thread is one of the ways in which a reference wrapper comes in useful and std::ref() returns a reference wrapper.
Had you passed a simple reference you would see different behavior.
Read more about std::ref() and std::reference_wrapper
This thread How is tr1::reference_wrapper useful? is also helpful.
I have the address of an object. Is there any way I can find all references to that address?
I'm working with vala and have a references counting problem. So I'm trying to find where I have a reference to the object that is sticking around.
Not directly, but you can set a break point on the appropriate reference function for you object. Each object has foo_ref and foo_unref that are called to change the reference count. If you set break points on these, you can trace the reference counting.
I've been tossing around ComPtrs in my code because I need them here and there but I've been doing it like so:
HRESULT Material::Initialize(aiMaterial* pMaterial,
Microsoft::WRL::ComPtr<ID3D11Device1> & d3dDevice,
Microsoft::WRL::ComPtr<ID3D11DeviceContext1> & d3dContext)
Is this completely negating the ref counting benefit of a ComPtr? Should I just do a pass by value (no &) instead?
Thanks you for reading
It's perfectly okay and preferred to pass it around as const&.
Pass by value is acceptable from semantics standpoint, not that much from performance, as passing so causes bumping the refcount up and down, and both are "interlocked" operations with serious consequences. And we gain nothing in return.
The benefit of ComPtr is that it allows proper matching of Release calls, that is all too easy to mess up, and even if it was easy the mess of the code it takes is unpleasant.
No, you're doing the right thing. The callee doesn't have to modify the reference count unless it needs to hold onto the interface for access after the call. Incrementing and decrementing the reference count is not free - it's a virtual call plus an interlocked increment or decrement - so you get better performance anyway. You should use a const reference though - or even just pass down a raw pointer.
Yep in my DirectX code, I arrange my engine to make it clear which object have the authority to manage the lifetime of a DirectX COM object. Then I pass it as raw pointer to methods that need them (I avoid to keep member variables track DX objects as much as possible).
What exactly is reference counting? In particular, what is it for C++? What are the problems we can face if we don't handle them? Do all languages require reference counting?
What exactly is reference counting? In particular, what is it for C++?
In simple words, Reference counting means counting the references to an object.
Typically, C++ employs the technique of RAII. Wherein, the ability to manage the deallocation of an type object is tied up within the type object itself. It means that the user does not have to explicitly manage the lifetime of the object and its deallocation explicitly, The functionality to do this management is built in the object itself.
This functionality means that the object should exist and remain valid untill there are stakeholders who refer to the object, and this is achieved by reference counting. Everytime the object is shared(copied) the reference count(typically a member inside the class type) is incremented and each time the destructor is called the count is decremented, when the count reaches 0, the object is not being reffered by anyone and it marks the end of its lifetime and hence it is destructed.
What are the problems we can face if we don't handle them?
It would mean no more RAII, and endless and often faulty manual resource management.
In short programming nightmares.
Do all languages require reference counting?
Languages don't require reference counting but employing the technique provides very easy usage and less efforts for users of the language, So most languages prefer to use it to provide these advantages to their users.
Reference counting is a simple but not complete approach for garbage detection.
When the counter reaches zero, you could release that object.
BUT if there are no more used objects which referencing each other cyclic, they will never be released
Consider a references b, b references a, but nothing else reference a or b.
The reference count on a and b will be still 1 (= in use)
Reference-count garbage collection is a powerful technique for managing memory that helps prevent objects from being deleted accidentally or more than once. The technique is not limited to C++ code and, despite its name, is unrelated to the C++ concept of reference variables. Rather, the term means that we maintain a count of all ``owning references'' to an object and delete the object when this count becomes zero.
Reference counting - lets use a metaphor.
You have an ear. You want it back at some point.
You get a group of people pointing at your ear. You count them as soon as they point.
When the number goes to zero - it is just yours and you can do with it as you wish.
I.e. take it out of the equation (free it back to memory).
BTW. Circular stuff is tricky to spot.
I've been programming C, mainly in an embedded environment, for years now and have a perfectly good mental model of pointers - I don't have to explicitly think about how to use them, am 100% comfortable with pointer arithmetic, arrays of pointers, pointers-to-pointers etc.
I've written very little C++ and really don't have a good way of thinking about references. I've been advised in the past to "think of them as pointers that can't be NULL" but this question shows that that is far from the full story.
So for more experienced C++ programmers - how do you think of references? Do you think of them as a special sort of pointer, or as their own thing entirely? What's a good way for a C programmer to get their head round the concept?
I've get used to think about references as an alias for main object.
EDIT(Due to request in comments):
I used to think about reference as kind of aliasing is because it behaves in the exact same way as the original variable without any need to make an extra manipulation in order to affect the variable referenced.
For me, when I see a pointer in code (as a local variable in a function or a member on a class), I have to think about
Is the pointer null, or is it valid
Who created the object it points to (is it me?, have I done it yet?)
Who is responsible for deleting the
object
Does it always point to the same
object
I don't have to think about any of that stuff if it's a reference, it's somebody else's problem (i.e. think of a reference as an SEP Field for a pointer)
P.S. Yes, it's probably still my problem, just not right now
I'm not all too fond of the "ever-valid" view, as references can become invalid, e.g.
int* p = new int(100);
int& ref = *p;
delete p; // oops - ref now references garbage
So, I think of references as non-rebindable (that is, you can't change the target of a reference once it's initialized) pointers with syntactic sugar to help me get rid of the "->" pointer syntax.
In general you just don't think about references. You use references in every function unless you have a specific need for calling by value or pointer magic.
References are essentially pointers that always point to the same thing. A reference doesn't need to be dereferenced, and can instead be accessed as a normal variable. That's pretty much all that there is to it. You use pointers when you need to do pointer arithmetic or change what the pointer points to, and references for just about everything else.
References are pointer-consts with different syntax. ie. the reference
T&
is pretty much
T * const
as in, the pointer cannot be changed. The content of both is identical - a memory address of a T - and neither can be changed.
Then apart from that pretty much the only difference is the syntax: . for references and -> and * for pointer.
That's it really - references ARE pointers, just with different syntax (and they're const).
How about "pointers that can't be NULL and can't be changed after initialisation". Also, they have no size by themselves (because they have no identity of themselves).
I think of the reference as being the object it refers to. You access the object using . symantecs (as opposed to ->), re-enforcing this idea for me.
I think your mental model of pointers, and then a list of all the edge cases you've encountered, is the best way.
Those who don't get pointers are going to fare far worse.
Incidentally, they can be NULL or any other non-accessible memory location (it just takes effort):
char* test = "aha";
char& ok = *test;
test = NULL;
char& bad = *test;
One way to think about them is as importing another name for an object from a possibly different scope.
For instance : Obj o; Obj& r = o;
There is really little difference between semantics of o and r.
The major one seems that the compiler watches the scope of o for calling the destructor.
I think of it as a pointer container.
If you use linux, you can think of references as hard links and pointers as symbolic links (symlinks).
Hard link is just another name for a file. The file gets "deleted" when all hard links to this file are removed.
Same about references. Just substitue "hard link" with "reference" and "file" with "value" (or probably "memory location"?).
A variable gets destroyed when all references are gone out of scope.
You can't create a hard link to a nonexistent file. Similary, it's not possible to create a reference to nothing.
However you can create a symlink to a nonexistent file. Much like an uninitialized pointer. Actually uninitialized pointers do point to some random locations (correct me if I'm wrong). But what I mean is that you are not supposed to use them :)
From a syntactic POV, a reference is an alias for an existing object. From a semantic POV, a reference behaves like a pointer with a few problems (invalidation, ownership etc.) removed and an object-like syntax added. From a practical POV, prefer references unless you have the need to say "no object". (Resource ownership isn't a reason to prefer pointers, as this should be done using smart pointers.)
Update: Here's one additional difference between references and pointers which I forgot about: A temporary object (an rvalue) bound to a const reference will have its life-time extended to the life of the reference:
const std::string& result = function_returning_a_string();
Here, the temporary returned by the function is bound to result and will not cease to exist at the end of the expression, but will exist until result dies. This is nice, because in the absence of rvalue references and overloading based on them (as in C++11), this allows you to get rid of one unnecessary copy in the above example.
This is a rule introduced especially for const references and there's no way to achieve this with pointers.