So while I'm not the greatest fan of what operator overloading can do to a program I was wondering if there wasn't a role for some moderate use to look after reference counting on assignment and to provide a shorthand for commonly used methods such as [array objectAtIndex:0] or [dict objectForKey:@"KEY"] by overloading the subscript operator.
I've had a go at doing this using a header file and resulting code seems far cleaner and more compact. ObjCpp.h
Can something really be added to Objective-C using it in this way?
So while I'm not the greatest fan of what operator overloading can do to a program I was wondering if there wasn't a role for some moderate use to look after reference counting on assignment and to provide a shorthand for commonly used methods such as [array objectAtIndex:0] or [dict objectForKey:@"KEY"] by overloading the subscript operator.
I've had a go at doing this using a header file and resulting code seems far cleaner and more compact. ObjCpp.h
Can something really be added to Objective-C using it in this way?
John H.
I think you could get the same result with a C macro instead - I know I've seen one for array access before, but I can't find it now.
Now you could write myArray<0> to get object zero from the array.
That one little macro could vastly improve readability of code that does a lot of array operations.
I'm wondering if anyone has written a comprehensive pre-processor for Objective-C/Cocoa to make is less wordy and more expressive?
A complete set of compact array operators would be helpful.
An implementation of even part of Ruby's string-processing features would be incredibly helpful. (Oh, the joy of just being able to concatenate strings with "+"...) With regular-expression support, it would be fantastic!
All it needs to do is parse the higher-level constructs and generate the corresponding incrediblyLongMethodNamesWith:incrediblyLongParame terNames...
I considered C macros, but the problem is you can't assign to them:
x(y) = object; // would not work.
I even considered looking at the gnu compiler itself but the elements are already there in Xcode to introduce array and string operators to Objective-C by using the C++ part of the gnu compiler as a form of preprocesor. By wrapping XCode pointers in a class you can re-define any operator you like:
The same goes for the subscript operator and arrays:
class OOArray {
NSArray *arr;
public:
OOArray( NSArray *anArray ) {
str = [anArray retain];
}
id operator [] ( int index ) {
return [arr objectAtIndex:index];
}
~OOArray() {
[arr release];
}
}
ObjCpp.h ("Objective-C pre-processor" or "Objective-C plus plus") is a little more involved than this but the idea of wrapping the pointer is the same. It also handles recursive indexing, creating arrays along the way as languages such as Perl and Ruby do for data structures:
a[0][1][33] = anObject;
While overuse of operator overloading can obfiscate code, Xcode is at the other extreme at times with their incredibly long method names!
John
Quote:
Originally Posted by jtara
That one little macro could vastly improve readability of code that does a lot of array operations.
I'm wondering if anyone has written a comprehensive pre-processor for Objective-C/Cocoa to make is less wordy and more expressive?
A complete set of compact array operators would be helpful.
An implementation of even part of Ruby's string-processing features would be incredibly helpful. (Oh, the joy of just being able to concatenate strings with "+"...) With regular-expression support, it would be fantastic!
All it needs to do is parse the higher-level constructs and generate the corresponding incrediblyLongMethodNamesWith:incrediblyLongParame terNames...
I even considered looking at the gnu compiler itself but the elements are already there in Xcode to introduce array and string operators to Objective-C by using the C++ part of the gnu compiler as a form of preprocesor. By wrapping XCode pointers in a class you can re-define any operator you like:
The problem with this approach is that operators tend to be used heavily and wrapping them in another layer will make things even slower ( with Objective C not being a speed deamon in the first place.)
In other words, what you could accomplish with an inline method evaluating to 1 or 2 asm intructions in C++ is going to take two calls in Objective C.
Speed shouldn't be an issue as all the operators are written as "inline" functions so it will not slow things down at run time. The code generated is all code the developer would have to write longhand anyway so the net result is just to off-load the programmer slightly.
If you have a need for speed consider using the native C++ OOVector container included as it bypasses NSArray altogether. Its pretty much the same as std::Vector but uses Xcode retain counts to manage correct destruction with scope outside a block of code.
I was concerned about compile time but even on my humble Mac-Mini this doesn't seem to be an issue. As a bonus using Objective-C++ mode to compile in Xcode is also a little stricter than straight Objective-C, for example: writing NSLog( "Hello World" ) rather than NSLog( @"Hello World" ) is an error rather than a warning.
John.
Quote:
Originally Posted by warmi
The problem with this approach is that operators tend to be used heavily and wrapping them in another layer will make things even slower ( with Objective C not being a speed deamon in the first place.)
In other words, what you could accomplish with an inline method evaluating to 1 or 2 asm intructions in C++ is going to take two calls in Objective C.
Speed shouldn't be an issue as all the operators are written as "inline" functions so it will not slow things down at run time. The code generated is all code the developer would have to write longhand anyway so the net result is just to off-load the programmer slightly.
If you have a need for speed consider using the native C++ OOVector container included as it bypasses NSArray altogether. Its pretty much the same as std::Vector but uses Xcode retain counts to manage correct destruction with scope outside a block of code.
I was concerned about compile time but even on my humble Mac-Mini this doesn't seem to be an issue. As a bonus using Objective-C++ mode to compile in Xcode is also a little stricter than straight Objective-C, for example: writing NSLog( "Hello World" ) rather than NSLog( @"Hello World" ) is an error rather than a warning.
John.
I doubt gcc would inline a C++ method which in turn calls another Objective C method ... in any case, I would never use Objective C for anything else but GUI glue code.
Frankly, the prefered approach is to simply wrap API specific stuff in some nice C++ classes and proceed from there ... there is nothing Apple base framework provides that cannot be better accomplished with std or boost.
I doubt gcc would inline a C++ method which in turn calls another Objective C method ... in any case, I would never use Objective C for anything else but GUI glue code.
Frankly, the prefered approach is to simply wrap API specific stuff in some nice C++ classes and proceed from there ... there is nothing Apple base framework provides that cannot be better accomplished with std or boost.
I am new here and to MAC OS X / iPhone / Objective-C (and this is my first post on the board). Last week I received my mac and installed xcode on the weekend. Spent some time with objective-c books and xcode environment. However, I am not new to C++. Have coded in C++ for about 10 years and used the STL and BOOST before they become vogue. Multi-threaded servers, COM, DCOM, and some *nix programs were mostly what I have worked on.
The short time I have spent in investigating directs me to what you are asserting. IMO, once one understands and utilizes the power of C++ with the standard libraries (including STL), and BOOST, everything else is found lacking in some way or another.
As I get some experience under my belt with cocoa touch and using C++ with Objective-C in the environment, I hope to contribute to the forum. In the meantime, I'll be plugging away and happy that someone is using C++ and only Objective-C at the API touch points.
I am new here and to MAC OS X / iPhone / Objective-C (and this is my first post on the board). Last week I received my mac and installed xcode on the weekend. Spent some time with objective-c books and xcode environment. However, I am not new to C++. Have coded in C++ for about 10 years and used the STL and BOOST before they become vogue. Multi-threaded servers, COM, DCOM, and some *nix programs were mostly what I have worked on.
The short time I have spent in investigating directs me to what you are asserting. IMO, once one understands and utilizes the power of C++ with the standard libraries (including STL), and BOOST, everything else is found lacking in some way or another.
As I get some experience under my belt with cocoa touch and using C++ with Objective-C in the environment, I hope to contribute to the forum. In the meantime, I'll be plugging away and happy that someone is using C++ and only Objective-C at the API touch points.
Cheers!
Well, it depends :-)
I am lucky enough not to have to worry about Apple GUI and other classes as I am developing using OpenGL ES which means in my code , given about 100 classes, only 4 or 5 are mixed Objective-C , C++ - everything else is pure C++.
Of course, the price I pay for this is not being able to use any of Apple GUI stuff and handling everything thru OpenGL ( which is pretty much what generally is done when doing games anyway).
If you are planning to use iPhone GUI extensively then you will still most likely need to go heavily into Objective-C and related stuff and then there is no escaping their framework classes because a lot of it is built on top of them ( APIs expecting their custom collections classes as parameters etc.)
I am lucky enough not to have to worry about Apple GUI and other classes as I am developing using OpenGL ES which means in my code , given about 100 classes, only 4 or 5 are mixed Objective-C , C++ - everything else is pure C++.
Of course, the price I pay for this is not being able to use any of Apple GUI stuff and handling everything thru OpenGL ( which is pretty much what generally is done when doing games anyway).
If you are planning to use iPhone GUI extensively then you will still most likely need to go heavily into Objective-C and related stuff and then there is no escaping their framework classes because a lot of it is built on top of them ( APIs expecting their custom collections classes as parameters etc.)
After spending a night with a book, xcode and interface builder I am totally disabused of the erroneous notion that I can minimize objective c.
I did find a great document for people new to objective-c with a strong C++ background. It was written in French and translated to English. Theocacao: Objective-C Guide for C++ Programmers I must say it is a good reference.
The advantages of mixing in a little C++ again as I see it:
Better memory management through object life-cycle management.
Stricter type checking applied during compilation.
More powerful syntax than straight Objective-C.
This isn't an attempt to minimise Objective-C but compilent it wrapping foundation classes to reduce some of the verbiage of Objective-C code. To demonstrate the approach objcpp.h has been extended to include regular expressions, database persistence and xml document parsing along with two example iPhone applications.
Role for C++ in Objective-C development?
Linear Mode
