unwind segue on navigation pop
I’m making more use of unwind segues to try and get to the point I have ‘go forward’ and ‘go backward’ code in one place in the same class. So during prepareForSegue I set some stuff up, during my unwind segue method I tear it down again. Don’t use it for everything, but for some complex presentations it’s been quite useful. I’ve just changed a piece of navigation to use a standard nav controller, it used to be a modal presentation but a push makes more sense. So now there’s no custom dismiss button like there used to be, you go back with the normal back button on the nav controller. I can’t find a good way to get that back action to trigger my unwind segue. Can’t seem to do it in IB, I don’t want a custom back button because you lose the chevron (or have to fake it) and all the normal uinav behaviour. Best I’ve found so far is to give the segue a custom identifier (ie make it a viewcontroller segue) and performSegue it from ‘viewWillDisappear’, however that has a pretty bad smell about it because that’s not really an unwind, it’s already doing the dismissal by then. Feels like something which is going to break one day. There’s other ways I can do this obviously - change it to a protocol/delegate method called directly from the VC as it goes away, but I was trying to stick with unwind segues if possible. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC [was Protecting against "app nap"]
> On May 12, 2016, at 1:16 AM, Jonathan Taylor > wrote: > > you would definitely recommend ARC then, would you? Totally. As Roland said, I would never go back. > I've been a bit put off by what seems like regular questions on the list(s) > about debugging and fixing edge cases where ARC doesn't work. It happens occasionally, but it’s much less common than debugging and fixing manual ref-count bugs. Also, over time the compiler has gotten better at flagging some of those edge cases, like inadvertent ref-cycles caused by blocks. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem about math library and the standard namespace of Apple Clang
> On May 12, 2016, at 7:00 AM, 军其 胡 wrote:
> Hi, all.
>
> My question is about the convention of the standard namespace in C++.
> firstly, let's read the following classic example in C/C++:
>
> ,-
> | #include
> | #include
> |
> | double fabs(double a)
> | {
> | return -1.0*a;
> | }
> |
> | int main()
> | {
> | double b=fabs(3.0);
> | double c=std::fabs(3.0);
> | printf("%f, %f\n",b,c);
> | }
> `-
>
> The Xcode (or Apple Clang) gives the results with both 3.00. I have
> tried to compile the same code by GCC on Fedora 22 and obtain the opposite
> results with both -3.00. It's ridiculous since fabs and std::fabs are
> lying in different namespaces.
is allowed to declare entities in both namespace std and the global
namespace, and they are permitted to be the same entity. As far as the
compiler is concerned, your declaration of fabs is an attempt to implement the
C standard library's fabs function, which the C++'s library is just an alias
of. That is why both of these calls call your function.
You should not declare functions in the global namespace with the same name as
C library functions unless you really do mean to override them.
John.
> I also compile the following C/C++ codes:
>
> ,---
> | #include
> | #include
> |
> | int abs(int a)
> | {
> | return -1*a;
> | }
> |
> | int main()
> | {
> | int b=abs(3);
> | int c=std::abs(3);
> | printf("%b, %c\n", b, c);
> | }
> `---
>
> in Xcode. Now, it gives me the error about ambiguous calling to std::abs
> function while GCC gives me the right answer. After browsing the hierarchy of
> C/C++ headers
>
> ,--
> | $ cd /Applications/Xcode.app/Contents
> | $ find . -iname 'cmath'
> |
> ./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/c++/4.2.1/cmath
> |
> ./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/c++/4.2.1/tr1/cmath
> |
> ./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/c++/4.2.1/cmath
> |
> ./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/c++/4.2.1/tr1/cmath
> |
> ./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/cmath
> |
> ./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/tr1/cmath
> | ./Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath
> `--
>
> I found out that Apple Clang doesn't offer the newest math library. Anyone
> knows what happened between math library and standard namespace?
>
>
> Best wishes,
>
> Jun-Qi Hu
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rjmccall%40apple.com
>
> This email sent to rjmcc...@apple.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Problem about math library and the standard namespace of Apple Clang
Hi, all.
My question is about the convention of the standard namespace in C++. firstly,
let's read the following classic example in C/C++:
,-
| #include
| #include
|
| double fabs(double a)
| {
| return -1.0*a;
| }
|
| int main()
| {
| double b=fabs(3.0);
| double c=std::fabs(3.0);
| printf("%f, %f\n",b,c);
| }
`-
The Xcode (or Apple Clang) gives the results with both 3.00. I have tried
to compile the same code by GCC on Fedora 22 and obtain the opposite results
with both -3.00. It's ridiculous since fabs and std::fabs are lying in
different namespaces. I also compile the following C/C++ codes:
,---
| #include
| #include
|
| int abs(int a)
| {
| return -1*a;
| }
|
| int main()
| {
| int b=abs(3);
| int c=std::abs(3);
| printf("%b, %c\n", b, c);
| }
`---
in Xcode. Now, it gives me the error about ambiguous calling to std::abs
function while GCC gives me the right answer. After browsing the hierarchy of
C/C++ headers
,--
| $ cd /Applications/Xcode.app/Contents
| $ find . -iname 'cmath'
|
./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/c++/4.2.1/cmath
|
./Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/c++/4.2.1/tr1/cmath
|
./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/c++/4.2.1/cmath
|
./Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/c++/4.2.1/tr1/cmath
|
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/cmath
|
./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/tr1/cmath
| ./Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath
`--
I found out that Apple Clang doesn't offer the newest math library. Anyone
knows what happened between math library and standard namespace?
Best wishes,
Jun-Qi Hu
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC [was Protecting against "app nap"]
I can’t imagine going back to manual retain release. ARC lifted hours of work away from writing code because you just use objects and they stay when they need to stay go away when you’re done with them. I see hardly any questions about ARC at all, there were some at the very start, but they petered off pretty fast, that’s because it basically just works. There are a couple of things you need to know, how to avoid retain cycles with blocks (and the compiler warns you normally and Swift requires explicit selfs and warns you) and the annotation to keep objects alive through a scope which we discussed here the other day. That’s basically it, know those two things and it just works. The tools for debugging retain cycles are very good too, so if you do get one, it’s pretty easy to find it. ARC is 1000x more usable than manual retain release, and now it’s mature, I can’t think of a good reason not to use it. > On 12 May 2016, at 16:16, Jonathan Taylor > wrote: > > Hi Jens, > > Thanks again for your reply. I'm sure this has been done to death over the > years on the list, but... you would definitely recommend ARC then, would you? > I've been a bit put off by what seems like regular questions on the list(s) > about debugging and fixing edge cases where ARC doesn't work. I guess that > only shows the times when it doesn't work, but it's rather left me thinking > that it's just the same, but with less explicit indication of what is going > on. Is that an unfair assessment, in your view? > > Best regards, > Jonny. > > On 11 May 2016, at 16:10, Jens Alfke wrote: > >> >>> On May 11, 2016, at 2:31 AM, Jonathan Taylor >>> wrote: >>> >>> I guess I just found method naming a bit odd (not really referring to an >>> object at all), and might have expected it to have an ‘alloc/new’ naming >>> since I’d have thought the API would be almost exclusively used for >>> activities that continue beyond the calling scope. >> >> The only methods named +alloc or +new are the core methods on NSObject that >> instantiate objects. (There’s also -copy and -mutableCopy.) Regular methods >> don’t use that naming scheme nor return owned references, they just >> consistently return unowned references. That keeps the rules simpler. >> >> (And I really recommend using ARC! It saves trouble and eliminates a lot of >> bugs, like this one.) >> >> —Jens > > ___ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC [was Protecting against "app nap"]
Hi Jens, Thanks again for your reply. I'm sure this has been done to death over the years on the list, but... you would definitely recommend ARC then, would you? I've been a bit put off by what seems like regular questions on the list(s) about debugging and fixing edge cases where ARC doesn't work. I guess that only shows the times when it doesn't work, but it's rather left me thinking that it's just the same, but with less explicit indication of what is going on. Is that an unfair assessment, in your view? Best regards, Jonny. On 11 May 2016, at 16:10, Jens Alfke wrote: > >> On May 11, 2016, at 2:31 AM, Jonathan Taylor >> wrote: >> >> I guess I just found method naming a bit odd (not really referring to an >> object at all), and might have expected it to have an ‘alloc/new’ naming >> since I’d have thought the API would be almost exclusively used for >> activities that continue beyond the calling scope. > > The only methods named +alloc or +new are the core methods on NSObject that > instantiate objects. (There’s also -copy and -mutableCopy.) Regular methods > don’t use that naming scheme nor return owned references, they just > consistently return unowned references. That keeps the rules simpler. > > (And I really recommend using ARC! It saves trouble and eliminates a lot of > bugs, like this one.) > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
