[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wrapping C functions
From: |
Martin Kalbfuß |
Subject: |
Re: Wrapping C functions |
Date: |
Thu, 6 Aug 2009 16:34:05 -0700 (PDT) |
I have to correct myself. I need to use load to call SDL_init because it has
to be called before any subsystem is initialized. If I add SDL_init into the
initialize function someone could create an instance of the video subsystem
ore something similar before he creates an instance of the Oh class. I
thought about adding factory functions to the Oh class initializing the
subsystems and returning an instance of these systems. But then the user
could still create an instance directly from the subsystem class which would
be unusable. Maybe I miss the point. I'm still a Objective-C noob.
David Chisnall wrote:
>
> On 6 Aug 2009, at 22:13, Martin Kalbfuß wrote:
>
>>
>> OK. I understand that a global and load isn't needed when using a
>> singleton.
>> The atexit cleanup is mainly for calling SDL_Quit;
>> I followed an example of apple for a singleton. Now my
>> implementation looks
>> like:
>>
>> static Oh *sharedOhMangager = nil;
>>
>> @implementation Oh
>>
>> +( Oh * )sharedMangager
>> {
>> @synchronized(self)
>> {
>> if ( sharedOhInstance == nil )
>> {
>> [ [ self alloc ] init ];
>> }
>> }
>>
>> return sharedOhManager;
>> }
>
> This is ugly. @synchronized is very slow and not required if you use
> +initialize to create the singleton.
>
>> + ( id )allocWithZone:( NSZone * )zone
>> {
>> @synchronized( self )
>> {
>> if ( sharedOhManager == nil )
>> {
>> SDL_Init();
>>
>> sharedOhManager = [ super allocWithZone: zone ];
>>
>> return sharedOhManager;
>> }
>> }
>>
>> return nil;
>> }
>
> Put the SDL_Init() code in +initialize. If you create the singleton
> in +initialize then you don't need the synchronization code here
> either. Anything in +initialize is guaranteed to only be called by
> one thread; the runtime handles synchronization. Replace these two
> with:
>
> + (Oh*)sharedMangager
> {
> return sharedOhManager;
> }
>
> + (id)allocWithZone:( NSZone * )zone
> {
> if (nil == sharedOhManager)
> {
> return [super allocWithZone: zone];
> }
> return nil;
> }
>
> + (void)initialize
> {
> if ([Oh class] != self) { return; }
> SDL_Init();
> sharedOhManager = [self new];
> }
>
> This is less code, simpler, and will be faster. The implementation of
> @synchronized() in GNUstep is horrible (there's a slightly better one
> in Étoilé's ObjectiveC2 framework) and means that every time you use
> an @synchronized() directive in code that is reached, it makes all
> other @synchronized() directive's slightly cheaper.
>
>> - ( id )copyWithZone:( NSZone * )zone
>> {
>> return self;
>> }
>>
>> - ( unsigned ) retainCount
>> {
>> return UINT_MAX;
>> }
>>
>> - ( void )release
>> {
>> }
>>
>> - ( id )autorelease
>> {
>> return self;
>> }
>
> This all looks sensible.
>
>>
>> @end
>>
>> But what I don't understand is where the objects memory is going to be
>> freed. They don't tell. They only say it's for memory-managed code.
>> Release
>> and autorelease are overwritten. Should I or the user call dealloc
>> somwhere?
>
> Singletons aren't freed, they persist for the lifespan of the program.
>
> The documentation for SDL_Quit() implies that it actually needs to be
> called, which is a bit strange; the OS should be able to reclaim any
> resources when the program exits. The best way of doing this is by
> registering for aNSApplicationWillTerminateNotification notification
> from NSApp. If NSApp doesn't exist, then you need to make sure that
> your application calls a method in the object that calls SDL_quit().
>
> David
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>
--
View this message in context:
http://www.nabble.com/Wrapping-C-functions-tp24850281p24856439.html
Sent from the GNUstep - General mailing list archive at Nabble.com.
- Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions, David Chisnall, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions, David Chisnall, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions, David Chisnall, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions, David Chisnall, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions,
Martin Kalbfuß <=
- Re: Wrapping C functions, David Chisnall, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/06
- Re: Wrapping C functions, Martin Kalbfuß, 2009/08/07