# Copying Handle sublcasses (e.g., EventInstance)

**URL:** <https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316>\
**Category:** FMOD Studio\
**Created:** [February 27, 2014, 1:31pm UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316 "2014-02-27T13:31:14Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![martinrobinson](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@martinrobinson](https://qa.fmod.com/u/martinrobinson)\
**Post date:** [February 27, 2014, 1:31pm UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316/1 "2014-02-27T13:31:14Z")

</div>

Looking at the fmod\_studio.hpp file, it looks like the FMOD Studio API is using the CRTP technique for Handle objects. And possibly using some kind of ref-counting?

Is it safe to copy these objects by value? Either by passing to a function or storing in other containers?

```auto
  ...
  EventDescription eventDescription;
  //[get the eventDescription from the system via its event ID]
  EventInstance eventInstance;
  ERRCHECK (eventDescription.createInstance (&eventInstance));
  startEventInstance(eventInstance);
}

void startEventInstance(EventInstance eventInstance) // copy here
{
      ERRCHECK(eventInstance->start());
}
```

I know I could a reference or a pointer here but the question is whether its safe to copy (and assign, and use move semantic I suppose in C++11).

The actual problems is that I’m using JUCE and I’m trying to track down a problem storing EventInstance objects in a Juce Array (similar but different from a std::vector).

Martin

---

<div class="post-metadata">

**Author:** ![martinrobinson](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@martinrobinson](https://qa.fmod.com/u/martinrobinson)\
**Post date:** [March 4, 2014, 7:58pm UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316/2 "2014-03-04T19:58:04Z")

</div>

I guess the 1.03.00 release answers this 🙂

> [@](#):
>
> - Studio API - Studio API classes are now all referenced as pointers. This  
> reflects a change in the handle system to make it thread-safe,  
> more performant and match the C and low level interface.

---

<div class="post-metadata">

**Author:** ![graeme](https://avatars.discourse-cdn.com/v4/letter/g/50afbb/32.png) [@graeme](https://qa.fmod.com/u/graeme)\
**Post date:** [March 5, 2014, 8:05am UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316/3 "2014-03-05T08:05:00Z")

</div>

> [@martinrobinson](#):
>
> Juce Arrays copy objects around using the equivalent of memcpy when reordering elements (rather than using assignment).

Ah, that would do it. The 1.2 handles were tracked internally with (intrusive) linked lists. That’s not going to play nice with raw memcpy.

> [@martinrobinson](#):
>
> Anywa, updating to 1.3 now…

Excellent. 🙂

---

<div class="post-metadata">

**Author:** ![graeme](https://avatars.discourse-cdn.com/v4/letter/g/50afbb/32.png) [@graeme](https://qa.fmod.com/u/graeme)\
**Post date:** [March 5, 2014, 12:33am UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316/4 "2014-03-05T00:33:20Z")

</div>

Yes, you are correct. In version 1.3 all Studio API objects are now referenced as pointers, which naturally are safe to copy, compare and pass by value.

Just for reference, even the 1.2 style handles were safe to copy by value. As you guessed, the implementation performed ref-counting internally.

---

<div class="post-metadata">

**Author:** ![martinrobinson](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@martinrobinson](https://qa.fmod.com/u/martinrobinson)\
**Post date:** [March 5, 2014, 7:06am UTC](https://qa.fmod.com/t/copying-handle-sublcasses-e-g-eventinstance/11316/5 "2014-03-05T07:06:00Z")

</div>

Thanks for the clarification. There must have been some other problem. 1.2 style handles were safe to copy by value but I’ve seen differences in some compilers (I don’t remember which versions of GCC and LLVM) in terms of which copy constructor is called if not defined in the Dervied class.

Also (perhaps more likely) Juce Arrays copy objects around using the equivalent of memcpy when reordering elements (rather than using assignment).

Anywa, updating to 1.3 now…

Best  
Martin