# A shared, java-like, referenced Pointer **URL:** \ **Category:** General JUCE discussion\ **Created:** [August 10, 2010, 10:06am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550 "2010-08-10T10:06:06Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [August 10, 2010, 10:06am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/1 "2010-08-10T10:06:06Z")
I know there is ReferenceCountedObjectPtr, but it would be easier to have an template (like ScopedPointer) for an pointer which automatically deletes its object when there are 0 references to the same adress. The advantage is to use existing classes with it, no need for subclass it with ReferenceCountedObject, and easily porting Java to C++ and backwards. The address could be stored in a global singleton array which stores all addresses in a process. ReferencedPointer a = new MyClass(); ReferencedPointer b = a; a=0; b=0; // delete ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 10, 2010, 10:42am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/2 "2010-08-10T10:42:57Z")
It’s called boost::shared\_ptr [http://www.boost.org/doc/libs/1\_43\_0/libs/smart\_ptr/smart\_ptr.htm](http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smart_ptr.htm) ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 10, 2010, 12:34pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/3 "2010-08-10T12:34:43Z")
It’s a common technique, though you have to be careful when you use shared\_ptr. With a ReferenceCountedObject, you can create multiple ReferenceCountedObjectPtrs from the same raw object pointer and it’ll all work fine, but with shared\_ptr, if you accidentally dereference the object and then create a new shared\_ptr from the raw object, you’ll end up with multiple ref counts and multiple deletions. ---
**Author:** ![tomswirly](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tomswirly/32/236_2.png) [@tomswirly](https://forum.juce.com/u/tomswirly)\ **Post date:** [August 12, 2010, 12:47am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/4 "2010-08-12T00:47:25Z")
Also, if you’re doing digital audio or anything which involves multiple threads, you need to be careful, because shared\_ptr is not thread-safe, and this can cause hard-to-understand thread bugs in apparently thread-safe code if the destructor sometimes goes off in one thread and sometimes in another. The last company I worked at, which had pretty serious C++ coding standards, prohibited all reference-counted C++ shared pointers unless you could prove there was no simpler, more obvious way to do it. I only remember seeing one case. Inevitably, removing this idea makes the code smaller and clearer. People who grep up with Java use far too many pointers in their C++. Many times, passing small or medium things by value is just what you want, faster, smaller and with no memory management issues. If you start that way - making sure of course that your classes are copiable - you can then use pointers at the very end in the unlikely case that these tiny copies are a bottleneck. This doesn’t work for non-copiable objects like e.g. database cursors or large items like samples. If you really must use pointers, what are these objects? Why do they have such amorphous ownership? Isn’t there some single place that they can all live? If these are static items that aren’t deleted and recreated, do you even need to delete them at all? Can they just be static and never deleted? ---
**Author:** ![OBO](https://avatars.discourse-cdn.com/v4/letter/o/ba8739/32.png) [@OBO](https://forum.juce.com/u/OBO)\ **Post date:** [August 12, 2010, 10:22am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/5 "2010-08-12T10:22:50Z")
[quote=“TomSwirly”]Also, if you’re doing digital audio or anything which involves multiple threads, you need to be careful, because shared\_ptr is not thread-safe, and this can cause hard-to-understand thread bugs in apparently thread-safe code if the destructor sometimes goes off in one thread and sometimes in another. [/quote] Tom, good points. I’m putting out an opposing view here in hope that somebody will enlighten me if i’m wrong… I’m under the impression that assignment and reset of a shared\_ptr is atomic. This makes it very useful for sharing objects between threads and many uses of CriticalSections can be avoided with code like this: ```auto shared_ptr sharedProcessor; MainThread: int x = 0; while (true) { if ((x++)%2 == 0) sharedProcessor = new MyAudioProcessor(); else sharedProcessor.reset(); } AudioThread: shared_ptr p = sharedProcessor; if (p) { // regardless of whether MainThread resets or assigns a new 'sharedProcessor' - its still available here as 'p' ... process some audio with 'p' } ``` ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [August 17, 2010, 11:09am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/6 "2010-08-17T11:09:04Z")
Tom, good points! OBO, even when shared\_ptr is atomic, you have tu use critical sections, to be sure that .reset and processing won’t be called at the same time ---
**Author:** ![OBO](https://avatars.discourse-cdn.com/v4/letter/o/ba8739/32.png) [@OBO](https://forum.juce.com/u/OBO)\ **Post date:** [August 17, 2010, 10:09pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/7 "2010-08-17T22:09:24Z")
> [@chkn](#): > > OBO, even when shared\_ptr is atomic, you have tu use critical sections, to be sure that .reset and processing won’t be called at the same time I disagree. Please argue why you think so. Anything that happens to the shared\_ptr (reset and assignment) in the example is atomic. Either the p variable gets the value of a processor or it gets an empty pointer. In either case there are no race conditions. Whatever the main thread does, will not affect the audio thread beyond the assignment of p. And p is always either a valid pointer or a null pointer. ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [August 18, 2010, 8:02am UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/8 "2010-08-18T08:02:02Z")
MainThread: > [@](#): > > sharedProcessor.reset(); AudioThread: > [@](#): > > … process some audio with ‘p’ this can happen paralell while p == sharedProcessor ---
**Author:** ![tomswirly](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/tomswirly/32/236_2.png) [@tomswirly](https://forum.juce.com/u/tomswirly)\ **Post date:** [September 7, 2010, 5:46pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/9 "2010-09-07T17:46:10Z")
(Coming back to this a bit later…) chkn appears to be correct. share\_ptr has some thread-safety as detailed [here](http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety) - but that only handles either simultaneous reading, or simultaneous writing. If you’re trying to read and write at the same time from different threads, all bets are off. Note also that this limited “thread safety” you get for free in shared\_ptr does not work on absolutely every C++ platform, though it does work on the most common ones you’re likely to encounter - see the link for the details. I have to say that I never trust the “automatic” thread safety I get this way - partly because I need to lock in my code anyway and it’s distracting to my mind to realize that some of the items I’m locking have their own limited thread safety. Better IMHO to have the locking be as explicit as possible, at the highest possible level, and for the shortest possible time, and simply ignore the thread\_safety that my components might have. Which is why I think Java’s locking for its Vector and Juce’s for its Array - which I know is mercifully optional 😃 - is such a silly idea. I never want my nuts and bolts to be locking. I want to have as few locks (in Juce, CriticalSections) as I possibly can and know exactly what they’re doing. In particular, I really want to avoid thrashing my locks by dipping in and out of some locked component in, say, a loop, when I know that everything is locked already. (Locking the component before starting the loop does mostly fix that but it’s an extra piece that’s easy to forget…) ---
**Author:** ![OBO](https://avatars.discourse-cdn.com/v4/letter/o/ba8739/32.png) [@OBO](https://forum.juce.com/u/OBO)\ **Post date:** [September 7, 2010, 8:52pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/10 "2010-09-07T20:52:17Z")
Yes, i also have finallly realized that chkn is right. Meanwhile i think that JUCE’s own intrusive ReferenceCountedObject has the thread safety properties i was looking for above: [http://rawmaterialsoftware.com/viewtopic.php?f=2&t=5831](http://rawmaterialsoftware.com/viewtopic.php?f=2&t=5831) ---
**Author:** ![symfonysid](https://avatars.discourse-cdn.com/v4/letter/s/82dd89/32.png) [@symfonysid](https://forum.juce.com/u/symfonysid)\ **Post date:** [November 6, 2010, 7:11pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/11 "2010-11-06T19:11:06Z")
I know this discussion ended a while ago, but I just wanted to say that I’ve been wishing for a while that Juce supported the use of std::tr1::shared\_ptrs. They come built into the g++ and VisualStudio compiler, and I use them frequently when it’s not obvious whether the caller or recipient of an object should be responsible for deleting it. For a long time I didn’t fully trust them, and I used a logging deleter to keep track if they were working correctly. But I’ve never had any problems with them, and it gives me a lot of piece of mind using them and knowing that my objects are going to be properly deallocated without me having to worry about it. Maybe, I’m doing something wrong, but when I’m working with Juce, it bugs me a little that I can’t always define the way an object is going to be cleaned up when I’m allocating it. When I subclass a component and add more components to it, I have to remember to put deleteAllChildren() in my subclasses destructor or they’ll leak. When I swap out the look and feel, I have to remember to delete the look and feel ago at application shutdown. And so on… I’d much rather give a component over a shared\_ptr and not have to go checking over my code again at the end of the day to make sure I didn’t forget to clean up my objects… ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [November 7, 2010, 5:55pm UTC](https://forum.juce.com/t/a-shared-java-like-referenced-pointer/5550/12 "2010-11-07T17:55:50Z")
There’s nothing wrong with shared\_ptrs, and there’s nothing stopping you mixing them up with juce stuff… They’re not massively efficient though, and can be dangerous if not used carefully, so wherever I needed a ref-counted pointer, I’ve used ReferenceCountedObjectPointer class, which is a better option than shared\_ptr in cases where you can make it inherit from the extra base class. There’s certainly a good argument in favour of making look and feel objects ref-counted… but personally, I always tend to define them as part of my application object or a main window class, so that there’s no need to worry about allocation or cleanup, e.g. [code]class MyApp { …etc ``` void initialise() { LookAndFeel::setLookAndFeel (&myLook); } void shutdown() { LookAndFeel::setLookAndFeel (0); } MyLookAndFeel myLook; ``` };[/code] …that feels much neater to me. (In fact, what I should do is to make sure that when the current default l+f is deleted, it calls setDefaultLookAndFeel (0), and then you wouldn’t even need to worry about doing anything in the shutdown code).