What is the right choice between NSDecimal, NSDecimalNumber, CFNumber?

If you are dealing with financial computations, you really should use base-10 arithmetic to avoid the rounding errors that can occur with the standard base-2 floating point types. So it's either NSDecimal or NSDecimalNumber. And since you're writing object-oriented code, NSDecimalNumber is the right choice for you.

To answer your questions: only testing of your code can reveal whether the memory overhead and performance loss are acceptable to you. I haven't really worked much with NSDecimalNumber but I'd wager that Apple's implementation is quite efficient and will be more than adequate for most people's needs.

Unfortunately, you won't be able to avoid the likes of decimalNumberByAdding: since Objective-C does not support operator overloading like C++ does. I agree that it makes your code somewhat less elegant.

One comment on the code you posted: r = [obj performSelector:NSSelectorFromString(@"capitalizedAmount")]; is rather unelegant. Either

r = [obj performSelector:@selector(capitalizedAmount)];

or even the simple

r = [obj capitalizedAmount];

would be better unless you require the NSSelectorFromString syntax for some other reason.

Ole is correct, in that you should be using NSDecimal or NSDecimalNumber to avoid floating point math errors when doing financial calculations. However, my suggestion would be to use NSDecimal and its C functions, rather than NSDecimalNumber. NSDecimal calculations can be much faster, and since they avoid creating a lot of autoreleased objects, much better on memory usage.

As an example, I benchmarked math operations for the two types on my MacBook Air:

NSDecimalAdditions per second: 3355476.75Subtractions per second: 3866671.27Multiplications per second: 3458770.51Divisions per second: 276242.32NSDecimalNumberAdditions per second: 676901.32Subtractions per second: 671474.6Multiplications per second: 720310.63Divisions per second: 190249.33

Divisions were the only operation that didn't experience a roughly fivefold increase in performance when using NSDecimal vs. NSDecimalNumber. Similar performance improvements occur on the iPhone. This, along with the memory savings, were why we recently switched Core Plot over to using NSDecimal.

The only difficulty you'll run into is in getting values into and out of the NSDecimal types. Going directly to and from float and integer values might require using NSDecimalNumber as a bridge. Also, if you use Core Data, you'll be storing your values as NSDecimalNumbers, not NSDecimals.

I want to access these methods and setters with their names as strings, since I plan to have a lot of other classes like this one, and I am only keeping a list of field to do key value coding.

r = [obj performSelector:NSSelectorFromString(@"capitalizedAmount")];

KVC is not simply sending messages to objects using strings. See the Key-Value Coding Programming Guide.

Should I get float values from NSDecimalNumber, then do the computations and returns the result wrapped in an NSDecimalNumber?

No. Conversion to binary floating-point (float/double) from decimal floating-point (NSDecimal/NSDecimalNumber) is lossy. Your result will be incorrect for some calculations if you do them that way.