0
0

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?

[code:2hv5y0w8]
...
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());
}
[/code:2hv5y0w8]

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

  • You must to post comments
0
0

I guess the 1.03.00 release answers this :)

[quote:1ibn99sz]* 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.[/quote:1ibn99sz]

  • You must to post comments
0
0

[quote="martinrobinson":2ivdhnjx]Juce Arrays copy objects around using the equivalent of memcpy when reordering elements (rather than using assignment).[/quote:2ivdhnjx]

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.

[quote="martinrobinson":2ivdhnjx]Anywa, updating to 1.3 now…[/quote:2ivdhnjx]

Excellent. :)

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.