2 posts • joined Monday 28th May 2007 16:45 GMT
Nice try, but...
your arguments are not very robust. I think the bigger message you are trying to send is "pay more attention to what you are doing." Your main point of avoiding code bloat is sort of a side-note. Why? Very simply because most of the code your process will be executing WILL NOT BE YOUR OWN! Between the objC runtime and Cocoa frameworks, there is enough code bloat for everyone. Nit-picking a high level language's output in assembly does little to make your point, as you detailed yourself. That's compiler territory, and it is no secret that gcc doesn't offer up the tightest code.
Finally, an extra 100 bytes here or there or everywhere will make a small change in the overall memory footprint of your program when you're looking at it from the standpoint of total number of pages required.
I think the focus of the article should be more on pointing out obvious things not to do in objC code (and perhaps some reasons why), but shying away from the "this costs an extra 80 bytes!!" argument.
- Product Round-up Smartwatch face off: Pebble, MetaWatch and new hi-tech timepieces
- Geek's Guide to Britain The bunker at the end of the world - in Essex
- FLABBER-JASTED: It's 'jif', NOT '.gif', says man who should know
- If you've bought DRM'd film files from Acetrax, here's the bad news
- VIDEO Herschel Space Observatory spots galaxies merging