AutoCAD Mac Update 1

Hello,

Autodesk has just released the first update for AutoCAD Mac 2011.
AutoCAD Mac should warn you when you open it but if it doesn't, get it from the following web page:

AutoCAD Mac Update 1

Regards.

An Introduction to Memory Management in Objective-C pt.2

Hello again!
In this follow-up I will explain the allocators and destructors available on Objective-C.

alloc

alloc allocates memory for an object of a given class, but DOES NOT initialize this object. Usually, alloc comes together with some initializer like initWithString or simply init. For example:

NSString* foo = [[NSString alloc] initWithString:@"foo"];

new

new is a convenience method equivalent to [[Class alloc] init]. This is not documented though, and was subject of a thread on cocoa-dev mailing list back in 2008. Bill Bumgarner, who is an Apple Software Engineer, explained it on the list:

Bill Bumgarner:
I just checked all the way back to 10.1. The implementation was +allocWithZone: NULL followed by -init until Leopard, when it moved to +alloc followed by -init.

copy

This is the keyword for the copy constructor. It allocates memory and initializes an object with the copy of the sender. Example:

NSString* foo = [[NSString alloc] initWithString:@"foo"];
NSString* fooCopy = [foo copy]; // fooCopy == @"foo"

A class must implement the NSCopying Protocol in order to use the copy constructor. This is accomplished by completing 2 steps:
1. Extend NSObject <NSCopying> instead of NSObject, for example.
2. Implement the copyWithZone method.

@interface MyClass : NSObject <NSCopying>
{
    NSString* attribute_string;
}
@property(readwrite,copy) NSString* attribute_string;

- (id) copyWithZone:(NSZone*)zone;

@end

@implementation MyClass

@synthesize attribute_string;

- (id) copyWithZone:(NSZone*)zone {
    MyClass* copy = [super allocWithZone:zone];

    copy.attribute_string = [self attribute_string];

    return copy;
}

Note: The implementation above uses @property and @synthesize just to handle the setters and getters. I am going to write a tutorial about properties later on, but for now just imagine that " copy.attribute_string = " is replaced by copy->setAttributeString(...), and setAttributeString is a public method that deals with the string copying and releasing.

retain

retain is used to get ownership over a reference you didn't allocate yourself. A common usage of retain is to hold references of objects inside collections.

Usually, core collections, like NSArray, NSDictionary and their mutable counterparts, release all objects once the container is released. This can create invalid references, if one needs to retain a reference to an object of the container for longer than the container itself. For example:

NSArray* students = [[NSArray alloc] initWithObjects:@"Alice",
                                                     @"Ben",
                                                     @"Chris", 
                                                     @"David",
                                                     nil];
NSString* studentName = [students objectAtIndex:2]; // @"Chris"
[students release];
NSLog(@"Student no 2: %@", studentName); 
    // Error: studentName is an invalid pointer.

To workaround this, one should retain the studentName reference before releasing the container, like this:

NSString* studentName = [[students objectAtIndex:2] retain];
[students release];
NSLog(@"Student no 2: %@", studentName); 
    // prints "Student no 2: Chris" to console.

[studentName release];

release

release relinquishes ownership of an object. It decrements the reference count to that object and if it gets to 0, then the object gets dealloc'd.

It is important to notice that one should never send a dealloc message directly. Instead, objects should be released and the deallocation will happen automatically either by the OS or the memory management environment.

autorelease

autorelease is a kind of lazy-release. When an object receives the autorelease message, the object ownership is transferred to the last created autorelease pool, thus extending the lifetime of the object and simplifying memory management.

An autorelease pool is a space where all references to objects that received an autorelease message are stored. When the pool is drained (same as deallocated), these references receive a release message and then gets deallocated.

Therefore, there are 2 basic implications of using autorelease:
Either use release or autorelease, and never both.
Always make sure you have an autorelease pool created before you send an autorelease message, or Cocoa will log an error.

Autorelease pools can be nested and are stored in a stack. This means that one can't extend the lifetime of an object, using autorelease, more than the last created pool's lifetime. Also, this mean that if you are not sure an autorelease pool was created, you should always create an autorelease pool before using autorelease.

And finally, one should use autorelease when he needs to create an object inside a scope, that will be used outside this scope.

For example:

// arrayFactory.m
@implementation arrayFactory

+ (NSArray*) createArray {
    NSArray* newArray = [[NSArray alloc] 
                            initWithObjects:@"a",@"b",@"c",nil];
    return [newArray autorelease];
}

@end

// main.m
int main(int argc, char *argv[])
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    NSArray* myArray = [arrayFactory createArray];

    // usage of myArray

    [pool drain]; // releases myArray and its content.
    return 0;
}

This is all one needs to know to be confident when dealing with memory management in Objective-C.

I also recommend reading Apple's Developer Docs about Memory Management for some advanced tips regarding performance and memory footprint.

Until next time!

An Introduction to Memory Management in Objective-C pt.1

Hello everyone! This is my first post on this blog and I hope you enjoy it.

On this post I will introduce the concepts behind memory management in Objective-C. This will be the first of a serie of posts about memory management, where I intend to cover everything you need to know to be confident with pointers in Objective-C. :)

Ownership

To understand memory allocation in Objective-C, we must first understand Ownership. Ownership principle states that for each object one creates, one is the only responsible for destroying it. If one doesn't destroy it, then there will be a memory leak. And if someone else destroys it, then there will be bugs, crashes and all sorts of unexpected behaviors due to invalid references being used.

In practice, the Ownership principle states that for each new there should be a delete on a C++ code, for example.

This principle is implemented on compilers via reference counting. For each allocator call, the reference count of an object is incremented and for each destructor call this reference count is decremented. When the reference count reaches 0, the memory space is cleared and set as available for other allocations.

In Objective-C, there are 4 keywords for allocators: alloc, new, copy, retain and 2 for destructors: release and autorelease.

I will explain each one on the next post.

Stay tuned for more!

Lab1 Video

Hello,

This is the first Lab about ObjectARX for Mac programming. In this Lab you will learn how to create a new project inside XCode, how to compile and build it. At the end, you will learn how to debug the application using XCode debug tools.



If you have any problem watching the embedded video try the following link:

YouTube Link

Cheers!
Fernando.

Behind the Scenes: Bringing AutoCAD® to the Mac®

Hello,

Here is a short video with some Autodesk people and some beta users talking about the challenges faced to develop AutoCAD for Mac.

Behind the Scenes: Bringing AutoCAD® to the Mac®

I would like to thank you all Autodesk members for the effort and support helping us (OFCDesk) to accomplish our hard job to port OFCDesk IDC to the Mac platform.

Regards.

ObjectARX® SDK for Mac® available

Hello,

Autodesk has just posted the very first release of ObjectARX for Mac. It can be downloaded from the ObjectARX official website:

ObjectARX®

The SDK is a dmg package which will install the necessary Header and Sample files into your Mac.

It will also create some XCode Project Templates which will create the ARX/DBX application skeleton.

Once you run your XCode and start to create a new Project you will see two new Project templates. One is for a ARX Cocoa module and the other for a DBX module.



The Template will initialize an empty dummy project with a basic command registered and ready to receive your code. On this first release, there are no Project Class wizards like you are used to have inside Visual Studio.

There are also some online documentation available with a Developer Guide and also a Migration Guide:

Developer Documentation

The documentation is posted at Wiki style so it is very interactive with rich content like Videos.





Stay tuned because now I will be able to further explore this technology in details.

For now, make sure your have your AutoCAD for Mac, XCode and ObjectARX for Mac installed into your OSX.

Regards.

AutoCAD® for Mac® Trial available

Hello,

AutoCAD® for Mac® is now available for download as a 30-day Trial.

Download now

I strongly suggest you go ahead and start to playing with it. As soon as the ObjectARX for Mac SDK is made available for downloading I will start to post more articles about AutoCAD for Mac programming.

Stay tuned!

XCode 3 versus 4

Hello,

One of disadvantages from those who are migrating from Windows environment to Mac OSX is the new compiler tool. XCode is really good but Visual Studio has been the best IDE for a long time.

XCode 3.2 IDE

Apple just released a Preview version of XCode 4 which presents several new tools and benefits but one of them captured my attention: "XCode Workspace". Yes, the current version does not provide an integrated environment equivalent to Visual Studio Solution.


For those who create simple applications with one or two modules it is not a big deal but for those who have to deal with 5 or 10 projects at once with dependencies among them it would be a pain!


Actually XCode 3 provides a special window called "Organizer" which allow you to kind of have all projects placed together but with a not well clear working behavior.

XCode 3.2 Organizer

I think XCode 4 with this specific Workspace feature plus all the other major improvements will really make the difference for those coming from Visual Studio and will make their lives much easier.


Autodesk didn't confirm yet if ObjectARX for Mac will be compatible with XCode 4 neither if it will be capable of generating compatible binaries.


More information about XCode 4 Preview can be found here: 


XCode 4 Preview


On the next post I will talk more about Targets and how they can make your life easier.


Stay tuned.

A word about OSX bundles

Hello,

One of the new concepts you will need to understand to work with applications inside OSX is how they can be organized. Inside Microsoft Windows we are used to have a host aplication executable and several other modules spreaded out into system known folders. Further, if we consider also .NET framework, we need to also consider the GAC.

In other hand, most of OSX applications are organized as bundles. A more detailed description of these structures (actually folders) is available here:

"Under NEXTSTEP, Mac OS X and GNUstep, a bundle is a directory (or file) that allows related resources such as software code to be grouped together. They were introduced into the Macintosh world as packages in Mac OS 9 and are similar in concept to the Application Directories used in RISC OS, on the ROX Desktop, as integrative technology into Ubuntu and Debian Linux with SpatialBundle, and on Super OS (RUNZ bundles)." - Wikipedia

Basically the concept is pretty simple, the bundle is the host and all its modules, resources, control files, etc. should be placed inside it. You can have as many sub-folders you want and organize your files as you wish. This self contained environment is firstly very good to keep your application isolated and avoid unwanted modifications from third party applications. Of course OSX also support shared components like frameworks placed into other folders.

If you get a typical OSX application, go to it using your Finder, right click and select "Show Package Contents" you will be able to see all its components (don't mess with them so your application may stop to work). So you may think bundles are folders with special behavior.

This is why most of OSX applications can be uninstalled by just deleting the main application bundle. It will carry all components to the Trash.

Ok, I don't want to go deeper than this but keep in mind that you will need to use bundle modules to organize your applications inside OSX.

Cheers!!!

AutoCAD for Mac Announced

Hello,

Welcome to my new Blog dedicated exclusively to AutoCAD Mac ObjectARX programming. For those who are used with my current Blog "ObjectARX & Dummies" I plan a slightly different approach here once we are dealing with a different platform.

Meanwhile, I would recommend some news about AutoCAD Mac along with some teaser videos about it.

AutoCAD for Mac was announced to be released this Fall:

http://www.youtube.com/watch?v=Lt12QkM_FSQ

http://www.autodesk.com/autocadformac

The event was last August 31st at Autodesk Gallery in San Francisco. I was there to present our company's (OFCDesk) product ported to AutoCAD Mac which will be made available also this Fall right after AutoCAD Mac starts to ship.

Some interesting videos about it can be found here at AutoCAD Exchange Youtube channel:

http://www.youtube.com/watch?v=3qyB_e8e3Zg

http://www.youtube.com/watch?v=e2Vl9rUnC6g

http://www.youtube.com/watch?v=hapdsyw8Ngs

Stay tuned on this Blog because I plan to cover all details about it in regards to API, how to create ObjectARX applications for it and how to port your current AutoCAD Windows applications to Mac.

In advance, I would recommend a deep study on XCode compiler and Cocoa language.

Cheers!