Some quick lunchtime coding:
http://projecteuler.net/problem=12
It took about 18 minutes to run. The biggest speed fix I could make is to change the divisor counter to only check up to the square root of the number entered. Another one is to not start from scratch every time I want to make a new triangle number. I should store the last result and then add the next number.
I read somewhere to optimize only after things are working since optimizing on the fly can be tricky. Also, I didn't want to spend too long on this since I had a sandwich to focus on, too.
Tuesday, November 29, 2011
Sunday, November 27, 2011
A pointer blunder I made today
Every time I think I'm getting half-decent at recreational-level C programming I do something dumb that knocks me down a few pegs. In my last post I mentioned using malloc() and free() to run some very simple tests. The tests turned out fine but I ran into an error that took me a few minutes to resolve.
This illustrates what I tried to do, and what I actually meant to do:
Basically I tried to alter where ptr was pointing, instead of filling in the reserved space ptr pointed to. The error happened when I tried to free the location of x instead of my malloc() allocated location.
I consider myself pointer-competent but I still make really dumb errors. The difference between now and a year ago is that I'd have had to write a post about how I was stuck on an error I couldn't figure out!
This illustrates what I tried to do, and what I actually meant to do:
Basically I tried to alter where ptr was pointing, instead of filling in the reserved space ptr pointed to. The error happened when I tried to free the location of x instead of my malloc() allocated location.
I consider myself pointer-competent but I still make really dumb errors. The difference between now and a year ago is that I'd have had to write a post about how I was stuck on an error I couldn't figure out!
The trouble for newbs with Objective-C, Cocoa, and XCode
I've been working much more with Objective-C: The Big Nerd Ranch Guide than I have been with Programming in Objective-C (3rd edition) lately. I decided to pop back over to the PiO-C book to see how much the other book had already covered (and see if it didn't cover anything since PiO-C is supposed to be the more in-depth book) and I discovered something I should have noticed before.
At some point XCode started using either a different compiler (Clang/LLVM instead of GCC) or a different way of handling memory allocation called Automatic Reference Counting (ARC). A pretty big change happened in the default way new projects are created that really makes it tough to learn from older books (if August 2011 is considered old!).
What it comes down to for the newbie is basically this:
Old way new projects were generated:
New way new projects are generated:
This wouldn't be a super big deal except that the old way where you explicitly handle the NSAutoreleasePool isn't legit in newly generated projects. Going back and forth requires really mucking with the project settings to get it to not use ARC. If I was brand new at learning programming and decided to use Objective-C with XCode as a first language/environment it wouldn't take long to get exasperated. I'm already pretty irked that a new book I bought is obsolete!
I need to track down a step-by-step guide to editing the project settings to go back and forth from the old way and the new way in case I want to use any examples in the old book to learn something. If there was a way to tell it which to use at the start of the new project then that would be great.
I understand the benefit of the new way on a superficial level (just as superficial as I understood what the old way was doing). Coming from C I'm not afraid of doing my own memory management, but I get that it's something you don't want to mess with once you start working on larger frameworks. Even GDK/GTK did a lot of stuff for you (similar to "new" in C++).
For kicks I threw in a few malloc() and free() assignments inside and outside the @autoreleasepool block and I didn't get any complaints. That's a relief - I take very seriously the claim that you can always revert back to straight C and Obj-C is just a strict superset of features that doesn't change any of the known rules.
I just found a placeholder for the 4th edition (releases in a month or so) of PiO-C on Amazon that specifically mentions in the description coverage of XCode 4.2, ARC, and iOS 5. If TBNRG doesn't cover everything then I'll have to drop $30 on the latest edition of a book I already own. Well... that's the game isn't it?
Maybe in a few weeks I'll follow up this post with instructions on reverting to pre-ARC compiler options, but for now I'll stick with TBNRG.
One big disappointment is that although TBNRG or PiO-C goes into some depth about what NSAutoreleasePool or @autoreleasepool{} are really doing, I don't think it discusses much of when to use it. I've seen snippets of code that have multiple groups of @autoreleasepool{} blocks (and in the older book multiple NSAutoreleasePool allocations) but it's not super obvious when to use them. In comparison malloc() and free() look downright friendly.
It's horribly ironic. I started this journey as an almost spiteful motion to clear up my ignorance of pointers and memory. I got to a certain competence in C and now I'm hitting a roadblock with an entirely new flavor of memory management.
Maybe I should ditch XCode and do some AVR/PIC stuff.
At some point XCode started using either a different compiler (Clang/LLVM instead of GCC) or a different way of handling memory allocation called Automatic Reference Counting (ARC). A pretty big change happened in the default way new projects are created that really makes it tough to learn from older books (if August 2011 is considered old!).
What it comes down to for the newbie is basically this:
Old way new projects were generated:
New way new projects are generated:
This wouldn't be a super big deal except that the old way where you explicitly handle the NSAutoreleasePool isn't legit in newly generated projects. Going back and forth requires really mucking with the project settings to get it to not use ARC. If I was brand new at learning programming and decided to use Objective-C with XCode as a first language/environment it wouldn't take long to get exasperated. I'm already pretty irked that a new book I bought is obsolete!
I need to track down a step-by-step guide to editing the project settings to go back and forth from the old way and the new way in case I want to use any examples in the old book to learn something. If there was a way to tell it which to use at the start of the new project then that would be great.
I understand the benefit of the new way on a superficial level (just as superficial as I understood what the old way was doing). Coming from C I'm not afraid of doing my own memory management, but I get that it's something you don't want to mess with once you start working on larger frameworks. Even GDK/GTK did a lot of stuff for you (similar to "new" in C++).
For kicks I threw in a few malloc() and free() assignments inside and outside the @autoreleasepool block and I didn't get any complaints. That's a relief - I take very seriously the claim that you can always revert back to straight C and Obj-C is just a strict superset of features that doesn't change any of the known rules.
I just found a placeholder for the 4th edition (releases in a month or so) of PiO-C on Amazon that specifically mentions in the description coverage of XCode 4.2, ARC, and iOS 5. If TBNRG doesn't cover everything then I'll have to drop $30 on the latest edition of a book I already own. Well... that's the game isn't it?
Maybe in a few weeks I'll follow up this post with instructions on reverting to pre-ARC compiler options, but for now I'll stick with TBNRG.
One big disappointment is that although TBNRG or PiO-C goes into some depth about what NSAutoreleasePool or @autoreleasepool{} are really doing, I don't think it discusses much of when to use it. I've seen snippets of code that have multiple groups of @autoreleasepool{} blocks (and in the older book multiple NSAutoreleasePool allocations) but it's not super obvious when to use them. In comparison malloc() and free() look downright friendly.
It's horribly ironic. I started this journey as an almost spiteful motion to clear up my ignorance of pointers and memory. I got to a certain competence in C and now I'm hitting a roadblock with an entirely new flavor of memory management.
Maybe I should ditch XCode and do some AVR/PIC stuff.
Friday, November 25, 2011
GitHub for Mac test
I struggled with geting Git and GitHub to be useful on my Windows and Linux machines, but there's a super easy GitHub app for Mac (and XCode uses Git as a source control option).
https://github.com/cheydrick/Project-Euper-9
Unfortunately as a test I pick the PE problem where I misspelled "Euler".
https://github.com/cheydrick/Project-Euper-9
Unfortunately as a test I pick the PE problem where I misspelled "Euler".
Pastebin test
Here's a test to see if I can jump to the "HTML" view to do Pastebin stuff:
Yea, I think that works better.
Yea, I think that works better.
Back on the horse
I'm getting through some more of the Big Nerd Ranch Objective-C book today. It took the free time of the Thanksgiving holiday and some gentle prodding from my wife to do it (she preferes that I indulge my more productive hobbies rather than play Skyrim all day).
It's been a while so I'm having to play catch-up. A quick note to self about Objective-C class organization:
Class header file:
Class implementation (.m) file:
main.m:
The new Blogger interface doesn't take well to the Pastebin inserts. I'm working on it.
It's been a while so I'm having to play catch-up. A quick note to self about Objective-C class organization:
Class header file:
Class implementation (.m) file:
main.m:
The new Blogger interface doesn't take well to the Pastebin inserts. I'm working on it.
Thursday, November 17, 2011
Society for Neuroscience 2011 done
I always get back from SfN with sore feet and wounded pride. It's humbling talking to people that do for a living what I aspire to as a hobby (it's not just neuroscientists that go to these things - lots of engineers and programmers and math whizzes and such).
Instead of being downtrodden I've allowed the bruised ego to fuel my resolve to get back on the programming horse. I have several new project ideas. One of my past larger projects involved reading in data from a known file format. The next logical step is to do something with that data. I need to sit down and think it through once the post-show rush is over.
Instead of being downtrodden I've allowed the bruised ego to fuel my resolve to get back on the programming horse. I have several new project ideas. One of my past larger projects involved reading in data from a known file format. The next logical step is to do something with that data. I need to sit down and think it through once the post-show rush is over.
Subscribe to:
Posts (Atom)