Updates

I went through and tagged most of my Project Euler related posts. The final code, code that was related (like preliminary prime finder code), any rigorous pre-code discussion was tagged. I didn't tag a lot of the work-in-progress code since it's just unfinished final code that isn't all that useful to review.

The wife wanted me scarce while she studied so I went up to the office and knocked out a lot of Project Euler 13. I should have final code this week. It's a really interesting problem because it deals with adding numbers that can't be stored in even a 128-bit integer, and as a result it's forced me to really hash out what it means to add large numbers in a methodical fashion, which I worked out on paper first.

While going through and tagging my posts I realized that I only started the PE problems in February of this year. I'll probably get through a few more so that would make around 14 problems done this year. That doesn't seem like a lot but it's 14 more than I could have done when I first started learning C so I'll take it as a win.

Note to self on overriding dealloc in Obj-C

I went through the chapter in Obj-C:TBNRG about ARC and retain cycles and got to the end with my head spinning. I understand what's going on but following which instances of what class own who is dizzying. The Objective-C style of having two files per class (one header file one implementation file) makes it hard to follow since you can't see everything at once. Well... maybe having everything in one big file isn't the way to go either.

Anyways, I intend on going through it again for good measure.

Something that had been bothering me is that in the classes you make for the example you override the dealloc method so that you can toss a print statement in to say when it's being deallocated (in an effort to show what actions on the data cause it to deallocate automatically). I realized that the implication would be that the data isn't actually getting deallocated! So, to the internets I go and I find that The Big Nerd Ranch has a forum for its books, wherein I find this:

http://forums.bignerdranch.com/viewtopic.php?f=151&t=3223

Basically: the magic of ARC saves you by somehow knowing to call the dealloc of the parent class (or the parent's parent class which inherits NSObject I think in the example). I don't like magic, but I'll roll with it for now.

Project Euler 12 Solution

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.

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!

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.

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".

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.

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.

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.