Prototype should appear as below, or else custom implementations of create() have to do backflips to maintain reference counts:
juce_Image.cpp
virtual ReferenceCountedObjectPtr <ImagePixelData> ImageType::create (...
Prototype should appear as below, or else custom implementations of create() have to do backflips to maintain reference counts:
juce_Image.cpp
virtual ReferenceCountedObjectPtr <ImagePixelData> ImageType::create (...
I don’t understand why you’d have a problem with that? Any sensible code should work just fine, e.g.
Image im (type->create (...));
ReferenceCountedObjectPtr <ImagePixelData> data (type->create (..));
If you write your own ImageType and try to construct a temporary Image from the ImagePixelData in order to do some manipulations before returning it, then the ImagePixelData will get freed unless you manually manage the reference counts:
ImagePixelData* MyImageType::create (...)
{
ImagePixelData* myData = new MyImagePixelData (...);
Image temp (myData);
return myData; // crash, myData has been freed
}
Now if you try to use ReferenceCountedObjectPtr as a local, you still crash:
ImagePixelData* MyImageType::create (...)
{
ReferenceCountedObjectPtr <ImagePixelData> myData = new MyImagePixelData (...);
Image temp (myData);
return myData; // caller will crash, myData has been freed
}
The only current solution is manual management of reference count:
ImagePixelData* MyImageType::create (...)
{
ReferenceCountedObjectPtr <ImagePixelData> myData = new MyImagePixelData (...);
Image temp (myData);
myData->incReferenceCount (); // for the caller
return myData; // okay
}
Or, if we just change the return type nothing else should break and we don’t need manual reference count management:
ReferenceCountedObjectPtr <ImagePixelData> MyImageType::create (...)
{
ReferenceCountedObjectPtr <ImagePixelData> myData = new MyImagePixelData (...);
Image temp (myData);
return myData; // good
}
You yourself point out that raw pointers are best avoided…the pointer return of ImageType::create() is a legacy holdover that should be fixed (and it shouldn’t break anything either since the callers use ReferenceCountedObjectPtr anyway).
This comes up because I have implemented a custom image type that presents individual channels of an existing ARGB Image, as a SingleChannel image pointing to the same data, to make compositing operations and manipulating masks easier.
Ah, I see. Ok, fair point, I’ll update that.