reference-counting

In purely functional languages, data is immutable. With reference counting, creating a reference cycle requires changing already created data. It seems like purely functional languages could use reference counting without worrying about the possibility of cycles. Am is right? If so, why don't they? I understand that reference counting is slower than GC in many cases, but at least it reduces pause times. It would be nice to have the option to use reference counting in cases where pause times are bad. JaredPar Your question is based on a faulty assumption. It's perfectly possible to have

If I have a C++ class, X, which implements the COM interfaces IY and IZ, and I have a pointer y to the IY interface of an object of type X, and I do this: IZ *z = dynamic_cast<IZ *> ( y ); That doesn't bump the object's reference count, does it? I don't have to do a Release() to account for it, right? If it matters, I'm using ATL/COM. I'm guessing the answer is "no it doesn't bump the reference count, and no you don't have to Release()", but I want to make sure. Thanks in advance. Reference counts for COM objects are incremented when someone calls IUnknown::AddRef(). QueryInterface(),

I 'm a novice in multithreading programing and i have still confusion with that. Below is my reference counted class: class Rbuffer { private: char *m_pnData; volatile unsigned int mRefCount; public: Rbuffer(int nLength) : mRefCount(0) { m_pnData = new char[nLength]; } ~Rbuffer(){ delete[] m_pnData; } void decRef() { if(InterlockedDecrement(&mRefCount)==0){ delete (Rbuffer *)this; } } void incRef() { InterlockedIncrement(&mRefCount); } }; is it fully thread safe? Can you exclude this situation: ThreadA ThreadB PointerToRBuffer->incRef();//mRefCount 1 switch-> PointerToRBuffer->incRef();/

I was just writing some exploratory code to solidify my understanding of Objective-C and I came across this example that I don't quite get. I define this method and run the code: - (NSString *)stringMethod { NSString *stringPointer = [[NSString alloc] initWithFormat:@"string inside stringPointer"]; [stringPointer release]; [stringPointer release]; NSLog(@"retain count of stringPointer is %i", [stringPointer retainCount]); return stringPointer; } After running the code and calling this method, I notice a few things: Normally, if I try to access something that's supposedly dealloced after

I got two classes (in my example TObject1 and TObject2) which know each other via interfaces (IObject1, IObject2). As you probably know in Delphi this will lead to a memory leak as both reference counter will always stay above zero. The usual solution is declaring one reference as weak. This works in most cases because you usually know which one will be destroyed first or don't necessarily need the object behind the weak reference once it is destroyed. This said I tried to solve the problem in a manner that both objects stay alive until both aren't referenced anymore: (Delphi 10.1 required as

I have a graph like structure. I don't know exactly when to destroy the objects in traditional Delphi manner, instead I would like to implement something like reference counted objects. I know that I can use something like object.GetReference and object.Release instead of Free, and use a private variable for reference counting, but is there any better way? Thanks If you have problems determining the correct way (place, order and so on) of destroying standard objects in a Delphi program, then using reference counted objects or interfaces instead will not help you at all. I understand that you