Assuming:
CvHaarClassifierCascade* pCascade;
cv::Ptr < CvHaarClassifierCascade > ptrCascade;
Assuming the xml file has been loaded in both pCascade and ptrCascade. Now we try to release them.
In OpenCV, there is a function cvReleaseHaarClassifierCascade to release pCascade, as directly deleting pCascade will cause a crash.
So how will ptrCascade be released?
It seems cv::Ptr< T > would use delete T* directly.
Or would cvReleaseHaarClassifierCascade be called? If so, how does cv::Ptr know which cvRelease* function should be called?
Documentation of cv::Ptr<T> shows that some types from the OpenCV C API already have a DefaultDeleter specialization that calls the appropriate release function.
Also, try not to use the old C API. Use the newer CascadeClassifier for new projects instead.
Related
We are migrating code to the Clang-based 64-bit compiler in C++Builder 10.2.3.
The linker is complaining about an unresolved external for pow10(), which is in math.h, but apparently we need a lib that isn't being linked.
Does anyone know which one it is?
AFAICT, it is not linked in. I dumped cw64.a and it does not contain that function.
There is an alternative:
double d = pow10l(2);
That will compile and link fine, and give the correct result, 100.0. The result is supposed to be a long double, but that maps to double in Win64, so that works fine.
FWIW, there is also a function _pow10(), but that is for internal use only. It seems to be a helper function for pow10l() and some other functions.
I'm trying to use CoreBluetooth's retrievePeripheral :
- (void)retrievePeripherals:(NSArray *)peripheralUUIDs;
The documentation says peripheralUUIDs should be a NSArray of CFUUIDRef. In the Apple sample project temperatureSensor, it is called as :
[centralManager retrievePeripherals:[NSArray arrayWithObject:(id)uuid]];
(uuid being a CFUUIDRef)
When I use the exact same code in XCode 4.5.1, IOS6, I'm getting a error :
Cast of C pointer type 'CFUUIDRef' (aka 'const struct __CFUUID *') to Objective-C pointer type 'id' requires a bridged cast
I would say (though I'm far from sure) that the reason it works in TemperatureSensor and not in my project is because TemperatureSensor seems not to use ARC whereas my project does.
Xcode suggests 2 ways of solving the problem : adding a __bridge or using CFBridgingRelease(). I tried them both and I'm under the impression that the function does not work [Edit] because the delegate methode didRetrievePeripheral: never gets called [/Edit] (my understanding is that these operation would change the C-style structs into objective-C-objects thus creating a NSUUID, and the method can't use it, but, again I'm really not sure)
So what should I do ? I've been searching on google for examples of retrievePeripherals using ARC, but without success.
In the temperature sensor change this line and run
LeDiscovery.m
-(void) startScanningForUUIDString:(NSString *)uuidString
{
[centralManager scanForPeripheralsWithServices:nil options:0];
}
change the word nil and assume 0.
If you want more check this link.
I hope its useful for you.
Turns out the problem was much simpler than that. I copied/pasted some code from TemperatureSensor, specifically the DidRetrievePeripheral. But it turns out, there's an error in this code (it's DidRetrievePeripheralS), so the delegate method never gets called. I think the bug is already reported.
Thanks/sorry
I'm trying to assign a function to the AURenderCallback inputProc
int setupRemoteIO(audio unit etc){
inProc.inputProc = playerCallback
}
but it says that playerCallback is not declared in this scope although playerCallback is present in the same file and class as setupRemoteIO.
The player callback is like this
static OSStatus playerCallback(void *inRefCon etc)
What could be the problem?
In C, you need to declare a function before its first use, i.e. higher up in the file than the point where you try to use the function. That's why include files are usually clustered at the top of a file; all of the symbols declared in the headers will be available throughout the code in the including file.
In this case, that means the declaration of your callback:
static OSStatus playerCallback(void *inRefCon etc);
must appear before your setupRemoteIO() function so that the compiler knows the function exists when you come to use it.
As you're on iOS, I'll also make the point that in recent compilers this restriction doesn't apply to Objective-C methods. It used to: you could only use method selectors that had already been seen. But in newer versions of Clang an Objective-C method can make use of a selector declared later in the same file without error.
Apologies if this is too vague... this is my first post here and I'm well and truly stumped on this issue!
I've been attempting to transition an iOS Xcode project using Audio Units to ARC, but it appears to have broken the functionality of the audio unit processing class. Some symptoms... When I attempt referencing 'self' in AUProcessor.mm, the AUProcessor class is referred to as 'const*', whereas in the pre-ARC version, there was no 'const*' mentioned.
This pointer to 'self' produces the following error:
callbackStruct.inputProcRefCon = self;
[error] Assigning to 'void *' from incompatible type 'AUProcessor *const __strong'.
I can remove the error by adding (__bridge void*) ahead of self, which allows the project to compile. However, the Audio Unit processor doesn't work in the app.
I can't see anything elsewhere in the code that is significantly different from the pre-ARC version in terms of how the class is referenced.
Let me know if more context is required.
Thanks in advance!!
(BTW, thank you to all contributors to these forums... they are truly a wonderful resource for keen yet inexperienced programmers!)
Typically, (__bridge void*) would be the correct cast here. This means "take a pointer to this object without applying any memory management; I promise I'll hold onto it for as long as it's needed." (That last part is just implied, but if you don't, you'll crash.)
Are you certain that self continues to exist for as long as this audio unit? If nothing has a strong reference to self, then it will disappear and inputProcRefCon will become a dangling pointer.
When you say "doesn't work in the app," what do you mean? Does it crash? Does the callback not happen? When the callback happens, does it not have the right data?
I managed to resolve my issue by excluding the troublesome class from ARC using the compiler flag -fno-objc-arc.
Its not a very satisfying conclusion but at least my app is working again... Looks like I'm going to need to learn more about memory management!
The code below is working for me with the MusicPlayer API. I don't know that it is correct but I am not getting any errors or memory leaks. Hope it helps!
// assign the callback:
MusicSequenceSetUserCallback( sequence, MyEventCallback, (__bridge_retained void *)self );
//the callback method:
void MyEventCallback(void *inClientData,
MusicSequence inSequence,
MusicTrack inTrack,
MusicTimeStamp inEventTime,
const MusicEventUserData *inEventData,
MusicTimeStamp inStartSliceBeat,
MusicTimeStamp inEndSliceBeat)
{
struct MyMusicEventUserData* userEventData = ( MyMusicEventUserData *)inEventData;
[(__bridge MusicPlayerController*)inClientData MIDIEvent:userEventData
eventTime:inEventTime
startSliceBeat:inStartSliceBeat
endSliceBeat:inEndSliceBeat];
}
I followed Claus's post to set up code coverage on Xcode 4.2 with LLVM 3.0. I'm able to see test coverage files, but they're only for my unit test classes, not my actual project classes. I've tried setting Generate Test Coverage Files and Instrument Program Flow to Yes on my main target, but that didn't help, as it failed with the following error:
fopen$UNIX2003 called from function llvm_gcda_start_file
To clarify, I don't think that's even the right approach - I just tried it to see if it would generate code coverage on my project classes.
At this point, I'd be happy to try anything that gets code coverage working on my app. Any suggestions?
You are expecting linker problem, profile_rt library uses fopen$UNIX2003 and fwrite$UNIX2003 functions instead of fopen and fwrite.
All you need is to add the following .c file to your project:
#include <stdio.h>
FILE *fopen$UNIX2003( const char *filename, const char *mode )
{
return fopen(filename, mode);
}
size_t fwrite$UNIX2003( const void *a, size_t b, size_t c, FILE *d )
{
return fwrite(a, b, c, d);
}
This code just remaps the missing functions to standard ones.
Note on $UNIX2003 suffix:
I've found an Apple document saying:
The UNIX™ conformance variants use the $UNIX2003 suffix.
Important: The work for UNIX™ conformance started in Mac OS 10.4, but was not completed until 10.5. Thus, in the 10.4 versions of libSystem.dylib, many of the conforming variant symbols (with the $UNIX2003 suffix) exist. The list is not complete, and the conforming behavior of the variant symbols may not be complete, so they should be avoided.
Because the 64-bit environment has no legacy to maintain, it was created to be UNIX™ conforming from the start, without the use of the $UNIX2003 suffix. So, for example, _fputs$UNIX2003 in 32-bit and _fputs in 64-bit will have the same conforming behavior.
So I expect libprofile_rt to be linked against 10.4 SDK.
I use CoverStory http://code.google.com/p/coverstory/ a GUI for .gcda and .gcno files.
The documentation explains the settings needed to generate these files http://code.google.com/p/coverstory/wiki/UsingCoverstory.