I am trying to convert this to Arc:
- (BOOL)doSomethingWithSelector: (SEL)aSelector
{
[...]
NSNumber *status = [ self performSelector: aSelector withObject: a
withObject: b ];
[...]
}
Xcode 5.0 complains: PerformSelector may cause a leak because its selector is
You can tell it to ignore the warning like this:
#pragma clang diagnostic push
#pragma clang diagnostic ignored -Warc-performSelector-leaks
NSNumber *status = [ self performSelector: aSelector withObject: a
withObject: b ];
#pragma clang diagnostic pop
Hope that helps.
Gideon
On
On 22 Oct 2013, at 13:48, Gideon King gid...@novamind.com wrote:
You can tell it to ignore the warning like this:
#pragma clang diagnostic push
#pragma clang diagnostic ignored -Warc-performSelector-leaks
NSNumber *status = [ self performSelector: aSelector withObject: a
This certainly helps: at least I get a clean compile.
But telling the compiler about the type of selector to expect would be even
better.
Can this be done?
You might want to look into using NSInvocation instead.
Best,
Elland
___
Cocoa-dev mailing
Converting to Arc (Xcode 5.0).
This works fine without Arc (regardless whether TRIGGER_ERROR is defined or
not):
NSMutableString *mus = [ NSMutableString string ];
NSString *word = @abc;
switch( self.colourType )
{
case colour_link:
[ mus
Just put a set of braces after every case: and it should be okay. A set of
braces here actually sets up a mini stack frame that makes ARC work.
Sent from my iPhone
On 2013年10月22日, at 15:41, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
Converting to Arc (Xcode 5.0).
This works fine
I suggest against NSInvocation. I will just throw in a direct call to
objc_msgSend.
Sent from my iPhone
On 2013年10月22日, at 15:33, Igor Elland igor.ell...@me.com wrote:
This certainly helps: at least I get a clean compile.
But telling the compiler about the type of selector to expect would be
I suggest against NSInvocation. I will just throw in a direct call to
objc_msgSend.
Care to elaborate?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the
This problem comes from C variable scopes regarding braces. For most cases it
is just fine but for switch() all cases are in the same scope, jumping around.
ARC inserts code at beginning and end of scopes (mini stack frames here) so if
a new ARC variable is defined in switch() it gets confused.
On 22 Oct 2013, at 14:48, ChanMaxthon xcvi...@me.com wrote:
Just put a set of braces after every case: and it should be okay. A set of
braces here actually sets up a mini stack frame that makes ARC work.
非常感谢
Works perfectly now.
(I still would like to know whether my code was faulty, or
Giving a mini performance boost. NSInvocation is utterly slow (multiple memory
allocations asking for syscalls, and a chain of function calls including at
least two objc_msgSends to invoke a method.) but good for IMP caching
performSelector methods are slightly slower than direct calls since
Compiler issue. All cases in a switch statement shares a same scope, and ARC
works by inserting code into beginning and end of scopes. switch() statement
jumps around, making code path very unpredictable, confusing ARC.
Sent from my iPhone
On 2013年10月22日, at 16:02, Gerriet M. Denkmann
On 22/10/2013, at 9:02 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
(I still would like to know whether my code was faulty, or whether this is a
compiler bug
Your code was faulty, at least according to the rules of C (which could be
argued about, but not fruitfully). If you insert
Hi,
On 2013-10-22 09:41, Gerriet M. Denkmann wrote:
Converting to Arc (Xcode 5.0).
This works fine without Arc (regardless whether TRIGGER_ERROR is
defined or not):
NSMutableString *mus = [ NSMutableString string ];
NSString *word = @abc;
switch( self.colourType )
{
case colour_link:
Hi,
On 2013-10-22 10:06, ChanMaxthon wrote:
Compiler issue. All cases in a switch statement shares a same scope,
and ARC works by inserting code into beginning and end of scopes.
switch() statement jumps around, making code path very unpredictable,
confusing ARC.
It is a compiler issue. But
Dear list,
After I updated to Mavericks GM, I can not use man command to find the manuals
of the C api.
Can anyone tell me how to solve this problem?
Regards,
Li Shunnian.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
Well you need Xcode and maybe the Command Line Tools package.
On Oct 22, 2013, at 16:56, li shunnian sonofsky2...@gmail.com wrote:
Dear list,
After I updated to Mavericks GM, I can not use man command to find the
manuals of the C api.
Can anyone tell me how to solve this problem?
In my document app I prompt users to save when switching views via:
NSDocument -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo
I can call this once successfully after which I receive a sheet saying:
This document’s file has been changed by another application since you opened
or
Hi,
Thanks for the reply.
I tried the code sample you suggested but can't get it to work.
When running the default highlighting is being layered on top of this custom
highlighting (I can see part of the custom highlighting where the rects are not
quite overlapping). Do you know how I prevent
Hi,
Thanks for the reply.
I tried the code sample you suggested but can't get it to work.
When running the default highlighting is being layered on top of this custom
highlighting (I can see part of the custom highlighting where the rects are not
quite overlapping). Do you know how I prevent
On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
Was the old (non-arc) code faulty (but the compiler did not notice
this)?
Why is the arc-version (with TRIGGER_ERROR defined) wrong?
It is wrong in the non-arc world, too. (ISO/IEC 9899:2011 AKA C11,
6.8.6.1: A goto statement shall not
On Oct 22, 2013, at 9:50 AM, Sean McBride s...@rogue-research.com wrote:
I don't think you can quote the Standard about 'goto' and just wave your
hands and say it applies to 'switch' also. :) The Standard's description of
'switch' should contain the answer
Switch is just a pile of goto,
On Oct 22, 2013, at 2:19 AM, Maxthon Chan xcvi...@me.com wrote:
Well you need Xcode and maybe the Command Line Tools package.
Yes, when I installed to Mavericks GM and put on the latest Xcode, a lot of my
man pages for C APIs went away. There is a discussion on this about 2 weeks ago
in the
Mavericks is still under NDA. Can’t you all wait (most likely) a few hours? ;-)
--Kyle Sluder
On Oct 22, 2013, at 9:25 AM, Todd Heberlein todd_heberl...@mac.com wrote:
On Oct 22, 2013, at 2:19 AM, Maxthon Chan xcvi...@me.com wrote:
Well you need Xcode and maybe the Command Line Tools
On Oct 22, 2013, at 08:50, Sean McBride s...@rogue-research.com wrote:
On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
Was the old (non-arc) code faulty (but the compiler did not notice
this)?
Why is the arc-version (with TRIGGER_ERROR defined) wrong?
It is wrong in the non-arc
On Oct 22, 2013, at 09:16, Scott Ribe scott_r...@elevated-dev.com wrote:
On Oct 22, 2013, at 9:50 AM, Sean McBride s...@rogue-research.com wrote:
I don't think you can quote the Standard about 'goto' and just wave your
hands and say it applies to 'switch' also. :) The Standard's
As I said, either ARC or C++ objects with constructors and destructors requires
compiler to insert code into the beginning and ending of the current scope (For
C++, it is calls to constructors and destructors; for Objective-C ARC, it is
ARC release/autorelease function calls.). As a rule of
Mavericks deeds can be implied from iOS 7, I think. :-P
On Oct 23, 2013, at 0:31, Kyle Sluder k...@ksluder.com wrote:
Mavericks is still under NDA. Can’t you all wait (most likely) a few hours?
;-)
--Kyle Sluder
On Oct 22, 2013, at 9:25 AM, Todd Heberlein todd_heberl...@mac.com wrote:
On Oct 22, 2013, at 10:46 AM, Maxthon Chan xcvi...@me.com wrote:
As I said, either ARC or C++ objects with constructors and destructors
requires compiler to insert code into the beginning and ending of the current
scope
For C++, the constructor is inserted at the call point, not at the
ARC have more insertion points - beginning of scope retaining all passed-in
arguments or used objects, call point creating objects, and end of scope
(auto)releasing objects. A missed retain causes race issues, a missed
(auto)release leaks objects and an extra release makes dangling pointers,
On Oct 22, 2013, at 11:08 AM, ChanMaxthon xcvi...@me.com wrote:
ARC have more insertion points - beginning of scope retaining all passed-in
arguments or used objects, call point creating objects, and end of scope
(auto)releasing objects.
OK, and it's the ones at call points that cause
Hi,
On 2013-10-22 17:50, Sean McBride wrote:
On Tue, 22 Oct 2013 10:31:01 +0200, Daniel Höpfl said:
Was the old (non-arc) code faulty (but the compiler did not notice
this)?
Why is the arc-version (with TRIGGER_ERROR defined) wrong?
It is wrong in the non-arc world, too. (ISO/IEC 9899:2011
Both call points and end of scope, not counting bigger troublemakers like
fall-throughs and use of variables defined in a previous case, which is
strangely valid in C.
Sent from my iPhone
On 2013年10月23日, at 1:14, Scott Ribe scott_r...@elevated-dev.com wrote:
On Oct 22, 2013, at 11:08 AM,
Until OS X Mavericks becomes available to everyone via the App Store, it's
still under NDA. Once it's available it can be discussed here, until then it
can't.
-- Chris, Cocoa-Dev co-mod
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
If I do a search on the MAS, it lists it (I signed out first to verify):
https://itunes.apple.com/us/app/os-x-mavericks/id675248567?mt=12
On Tue, Oct 22, 2013 at 11:56 AM, Chris Hanson c...@me.com wrote:
Until OS X Mavericks becomes available to everyone via the App Store, it's
still under
On Oct 22, 2013, at 1:56 PM, Chris Hanson c...@me.com wrote:
Until OS X Mavericks becomes available to everyone via the App Store, it's
still under NDA. Once it's available it can be discussed here, until then it
can't.
Isn't it available on the App Store now? It's showing up for me:
Actually, it sounds like it's available from the app store now.
Jean
On Oct 22, 2013, at 20:56 , Chris Hanson c...@me.com wrote:
Until OS X Mavericks becomes available to everyone via the App Store, it's
still under NDA. Once it's available it can be discussed here, until then it
can't.
Can someone who’s installed the public release of Mavericks reply with the
build number (e.g. from the About This Mac panel)? I’m running the GM seed,
13A598, and I’d like to make sure it’s the same as the actual release. Thanks.
—Jens
___
Cocoa-dev
13A603 is the last GM seed I downloaded…
On Oct 22, 2013, at 3:21 PM, Jens Alfke j...@mooseyard.com wrote:
Can someone who’s installed the public release of Mavericks reply with the
build number (e.g. from the About This Mac panel)? I’m running the GM seed,
13A598, and I’d like to make
On Oct 22, 2013, at 5:36 AM, Darren Wheatley dar...@tenjinconsulting.co.uk
wrote:
Hi,
Thanks for the reply.
I tried the code sample you suggested but can't get it to work.
When running the default highlighting is being layered on top of this custom
highlighting (I can see part of
OS X Mavericks is available on the App Store now.
-- Chris, cocoa-dev co-mod
-- who would like to point out the timestamp when he posted the original
message
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin
Timestamp only shows delivery time, even in the extended headers - which is a
general Apple mailing list complaint; sometimes it's seriously laggy.
On Oct 22, 2013, at 1:06 PM, Chris Hanson wrote:
OS X Mavericks is available on the App Store now.
-- Chris, cocoa-dev co-mod
-- who would
I just finished installing it. It's 13A603, the same as the update to the GM
release a couple of days ago.
On Oct 22, 2013, at 3:21 PM, Jens Alfke j...@mooseyard.com wrote:
Can someone who’s installed the public release of Mavericks reply with the
build number (e.g. from the About This Mac
On Oct 21, 2013, at 10:14 PM, Jens Alfke j...@mooseyard.com wrote:
As for autorelease: This has come up once before for me, and I was able to
work around it by making the cache-owner object call -autorelease instead of
-release on the NSCache, to defer the call to the cache’s dealloc. But I’m
On Oct 22, 2013, at 11:17 AM, Daniel Höpfl ap...@hoepfl.de wrote:
OK ... but as you say, the standard should contain the answer. Next try:
Well, there's some evolution there, and this new Objective-C feature which kind
of falls in between different versions of traditional C, ANSI C, C++.
--
Despite ARC banned retain/release/autorelease functions, there are still
alternatives there in the form of C functions:
From CoreFoundation CoreFoundation/CoreFoundation.h:
CFRetain() = retain
CFRelease() = release
CGBridgingRelease() = autorelease
From LLVM’s requirements to runtime for ARC to
46 matches
Mail list logo
