macOS C/C++ vs Obj-C/Obj-C++

[slooksterPSV]

What are some of the pros. and cons between C/C++ and Obj-C/Obj-C++? I bought and Objective-C Programming book and so far, from what I've read, this seems to be too good to be true when working with classes as far as ease of use, etc.

After I read this book I'm going to get a Cocoa programming book, so I can develop apps for Mac OS X.

 

[bousozoku]

From a simplistic point of view, it's easier to get a correctly-designed object-oriented application up and running with Objective-C because it's more of a pure langugage, borrowing heavily on Smalltalk.

C++ is a hybrid language. You don't have to use any object-oriented features to create an application. A lot of people I've seen create sloppy object-oriented designs because they don't understand it and, when things don't work properly, they insert procedural code to handle the shortcomings. With a properly-designed application C++ can be quite nice, though.

 

[slooksterPSV]

From a simplistic point of view, it's easier to get a correctly-designed object-oriented application up and running with Objective-C because it's more of a pure langugage, borrowing heavily on Smalltalk.

C++ is a hybrid language. You don't have to use any object-oriented features to create an application. A lot of people I've seen create sloppy object-oriented designs because they don't understand it and, when things don't work properly, they insert procedural code to handle the shortcomings. With a properly-designed application C++ can be quite nice, though.

That makes sense. Obj-C is awesome, I don't know why I haven't learned it in the first place. Is there a version of java that is Obj wise? E.g. Obj-Java? I need to learn Java too, but I'll get to that later.

 

[mduser63]

Java is already object-oriented. Anyway, glad to hear that you're learning Objective-C. I finished Programming in Objective-C by Stephen Kochan recently, and I'm about halfway through Cocoa Programming for Mac OS X by Aaron Hillegass now. I've just started on my first Cocoa application. I started on it yesterday, and I've already got something that works. Of course, I've got a long way to go to add all the features I want, but the core functionality is already in place which is really amazing to me. Core Data and Cocoa Bindings are incredibly cool.

Another thing that might be good to note is that because Objective-C is a strict superset of C, you can use any C syntax in an Objective-C application.

 

[bousozoku]

That makes sense. Obj-C is awesome, I don't know why I haven't learned it in the first place. Is there a version of java that is Obj wise? E.g. Obj-Java? I need to learn Java too, but I'll get to that later.

Java shares a lot of its idealism with Objective-C because of Smalltalk but it looks more like C++.

 

[slooksterPSV]

Java shares a lot of its idealism with Objective-C because of Smalltalk but it looks more like C++.

I've heard about automatic garbage collection, but to be honest, the way that Obj-C is looking to me right now, I wish Java had more of the looks of it (Obj-C). C++ is awesome don't get me wrong, but this Objective-C is just way cooler and simpler (to me at least). I'm going to google Smalltalk and look at that. I want to learn Cocoa now, maybe the pay day after next I'll buy a Cocoa book off the internet.

EDIT: mduser63 - Thanks for the comment, I knew Java was OO, but yeah I worded my sentence wrong, looks wise for Objective-C is what I was going after. And bousozoku answered it, thanks you two.

 

[Soulstorm]

In objective C, you will love the Foundation framework. The matter with objective C is that you won't need to get stuck into stupid programmatic problems, and you will only get involved with the solution of your problem. C++ can suffer from some very annoying simple problems, sometimes, which cannot be work-arounded easily.

But there are 2 things in C++ that really make things easier for me: The memory management handling (and the way deconstructors are made in classes), and the operator overloading (the entire STL is based upon it) which is the foundation for very elegant classes. C++ has more low-level flexibility than Objective C, but Objective C is quicker to design, and more productive.

That said, I think Objective-C's way of handling memory is brilliant, but difficult for beginners.

Finally, I should say that a professional program can be built with ObjC or C++, and still have the same functionality, and the same features, and the same performance, so the choice of language will only be based upon the preference of the programmer alone. However, you should note that ObjC support in windows frameworks and in Windows in general, is nearly non-existent.

 

[slooksterPSV]

In objective C, you will love the Foundation framework. The matter with objective C is that you won't need to get stuck into stupid programmatic problems, and you will only get involved with the solution of your problem. C++ can suffer from some very annoying simple problems, sometimes, which cannot be work-arounded easily.

But there are 2 things in C++ that really make things easier for me: The memory management handling (and the way deconstructors are made in classes), and the operator overloading (the entire STL is based upon it) which is the foundation for very elegant classes. C++ has more low-level flexibility than Objective C, but Objective C is quicker to design, and more productive.

That said, I think Objective-C's way of handling memory is brilliant, but difficult for beginners.

Finally, I should say that a professional program can be built with ObjC or C++, and still have the same functionality, and the same features, and the same performance, so the choice of language will only be based upon the preference of the programmer alone. However, you should note that ObjC support in windows frameworks and in Windows in general, is nearly non-existent.

Memory management in C and C++ is what's killed me when working with any program (I have tried to use malloc, calloc, realloc, ZeroMemory, etc., but it just doesn't work right most of the time). It's the main reason I'm loving Objective-C then I had someone else tell me that there are mutable arrays, so I don't need to know the size, i can resize it on the go, which is awesome. - I want to make some nifty apps for Mac OS X. REALBasic is easy, but it doesn't have level of programming I need/want.

I did play with Interface Builder and OMG, building an app is like SNAP! Windows it takes forever compared to OS X. I just need to learn how to program in Cocoa so I can make functionable programs. But that'll come after I learn Obj-C.

 

[GeeYouEye]

I had a much easier time getting into Objective-C and it's memory management than C++. Syntax is nicer too*. Foundation wipes the floor with the STL. The one thing I wish Objective-C had was non-alpha_numeric method names, so as to be able to have operator messages, but I don't even really miss that, except in when I think str = [str +:anotherStr]; would be better than str = [str stringByAppendingString:anotherStr];

*I will say, however, that I have found one language with a better one, if you leave out some/all of the syntactic sugar it provides: Io.

 

[slooksterPSV]

I had a much easier time getting into Objective-C and it's memory management than C++. Syntax is nicer too*. Foundation wipes the floor with the STL. The one thing I wish Objective-C had was non-alpha_numeric method names, so as to be able to have operator messages, but I don't even really miss that, except in when I think str = [str +:anotherStr]; would be better than str = [str stringByAppendingString:anotherStr];

*I will say, however, that I have found one language with a better one, if you leave out some/all of the syntactic sugar it provides: Io.

You can always combine C, C++ and Obj-C/++ to help you accomplish stuff like that. Can't you use the operator function with Obj-C to create a function where it acts like stringByAppendingString? E.g.

-(NSString *) operator+: (NSString *)string
{
return [NSString stringByAppendingString:string];
}

 

[robbieduncan]

You can always combine C, C++ and Obj-C/++ to help you accomplish stuff like that. Can't you use the operator function with Obj-C to create a function where it acts like stringByAppendingString? E.g.

-(NSString *) operator+: (NSString *)string
{
return [NSString stringByAppendingString:string];
}

I don't think so, at least not in any way that would make sense. You can only use C++ syntax in C++ classes. So NSString would have to be a C++ class I think.

 

[slooksterPSV]

I don't think so, at least not in any way that would make sense. You can only use C++ syntax in C++ classes. So NSString would have to be a C++ class I think.

Hmm... I'm still learning Objective-C so I'm not sure.

 

[bousozoku]

If you're using Objective-C++, you need to pass data in C-compatible types. The languages are not inter-operable from anything that I've seen. They work on a logical line-by-line basis.

 

[Soulstorm]

You can read this to solve your problems and to answer your questions about Objective C++

 

[darkwing]

I have issues with Cocoa. When using the malloc debugger, I notice that the number of certain types of objects I have open increases. A good example of this are working with tables. I make some NSTableColumns and put them in a table, but I don't autorelease them because if I do, it crashes. If I don't, they leak. (I'm going off memory here from something I did a year ago.) Cocoa should come with a rule that says whenever you "add" something, it's retained. This should always be followed in the class hierarchy. It's quirks like this that cause it to piss me off.

Of course, C++ has its weirdnesses with its limited built in classes. Take the STL... if you use a vector or a deque, then when you remove something from it the destructor called may not be the one called for the object you remove. If you use a list, this problem goes away. Try it. Make a class that wraps an int, and prints that int in its destructor. Insert 10 of them (0-9) into a deque, and then remove #5. Then, iterate through the deque and print what's left.Weird.

 

[slooksterPSV]

I have issues with Cocoa. When using the malloc debugger, I notice that the number of certain types of objects I have open increases. A good example of this are working with tables. I make some NSTableColumns and put them in a table, but I don't autorelease them because if I do, it crashes. If I don't, they leak. (I'm going off memory here from something I did a year ago.) Cocoa should come with a rule that says whenever you "add" something, it's retained. This should always be followed in the class hierarchy. It's quirks like this that cause it to piss me off.

Of course, C++ has its weirdnesses with its limited built in classes. Take the STL... if you use a vector or a deque, then when you remove something from it the destructor called may not be the one called for the object you remove. If you use a list, this problem goes away. Try it. Make a class that wraps an int, and prints that int in its destructor. Insert 10 of them (0-9) into a deque, and then remove #5. Then, iterate through the deque and print what's left.Weird.

For that type of situation, wouldn't it be easier to allocate and initialize your own NSTableColumns --throw it into an array and release the array to release the entire columns?-- and then release it when you are done with it instead of relying on NSAutoreleasePool to do the grunt work? --I'm no expert by any means; I'm just throwing ideas out there.

 

[Fukui]

For that type of situation, wouldn't it be easier to allocate and initialize your own NSTableColumns --throw it into an array and release the array to release the entire columns?-- and then release it when you are done with it instead of relying on NSAutoreleasePool to do the grunt work? --I'm no expert by any means; I'm just throwing ideas out there.

I would say thats probably either a documentation bug (they should state NSTableView does not retain the columns added) or a genuine bug. What you could do, is subclass NSTableView to retain columns added with addTableColumn: and in dealloc, release them. You could file a bug report, and include the fixed class in a working project with the bug report.

 

[AlmostThere]

Of course, C++ has its weirdnesses with its limited built in classes. Take the STL... if you use a vector or a deque, then when you remove something from it the destructor called may not be the one called for the object you remove. If you use a list, this problem goes away. Try it. Make a class that wraps an int, and prints that int in its destructor. Insert 10 of them (0-9) into a deque, and then remove #5. Then, iterate through the deque and print what's left.Weird.

What's weird about that?

If it confuses you, try putting a print statement in the assignment operator. A vector is required to use contiguous memory, so think about what would happen if you destroy the object in the middle - and compare this with the behaviour you observed in the list, which is not bound by such constraints.

 

[Gil Bates]

Objective-C is a hybrid of C and Smalltalk, and C++ is an OO extension to C (that's why it is called C++, not D).

The most important difference is, IMHO, C++ (and Java) uses function calls to invoke methods, whereas Objective-C uses message passing. With message passing, you can do things like message forwarding and delayed execution.

Other differeces that I can think of are:
1) In Objective-C (and Java), classes are objects (class objects), but not in C++. You can get the properties of a class from its class object, but there's not much you can do in C++. C++ doesn't leave much class info in compiled code. I think this is by design.
2) C++ is probably much more complex (because everyone says so). It includes features like operator overloading and templates.
3) The primary memory management method in C++ is explicit "new" and "delete". In Cocoa, it is reference counting. I'm not sure if it is a part of Ojbective-C. There is nothing precluding you from using reference counting in C++. (In Java, it is garbage collection.)

In Objective-C++, you can mix both. You can use C++ libraries quite easily. You may choose to write a large part of your code in C++ and keep it "cross-platform", and use Objective-C only in the UI and Mac specific area. The syntax borrowed from Smalltalk is so foreign to C, there aren't many conflicts or ambiguities between C++ and Objective-C.

 

[slooksterPSV]

Objective-C is a hybrid of C and Smalltalk, and C++ is an OO extension to C (that's why it is called C++, not D).

The most important difference is, IMHO, C++ (and Java) uses function calls to invoke methods, whereas Objective-C uses message passing. With message passing, you can do things like message forwarding and delayed execution.

Other differeces that I can think of are:
1) In Objective-C (and Java), classes are objects (class objects), but not in C++. You can get the properties of a class from its class object, but there's not much you can do in C++. C++ doesn't leave much class info in compiled code. I think this is by design.
2) C++ is probably much more complex (because everyone says so). It includes features like operator overloading and templates.
3) The primary memory management method in C++ is explicit "new" and "delete". In Cocoa, it is reference counting. I'm not sure if it is a part of Ojbective-C. There is nothing precluding you from using reference counting in C++. (In Java, it is garbage collection.)

In Objective-C++, you can mix both. You can use C++ libraries quite easily. You may choose to write a large part of your code in C++ and keep it "cross-platform", and use Objective-C only in the UI and Mac specific area. The syntax borrowed from Smalltalk is so foreign to C, there aren't many conflicts or ambiguities between C++ and Objective-C.

Operator overloading is awesome. its a very cool feature. Thankx for all the info. I'm on chapter what.. 16 - Files - in Obj-C and its the best language i've learned.

Here's the thing I love. Array's in C/C++ are only data types. In Obj-C they are Objects, how frikken cool is that. Objects in arrays! That's what you need to load in an array if you have multiple objects. Other wise you have to make a struct to contain what information you want, then make an array of those structs, whether you use the specifics in it or not is a different story. Memory wastage there as far as I know + you have to release the memory yourself instead of having an AutoreleasePool . E.g.

struct myData {
char* name;
char* date;
char* fileName;
FILE *filePtr;
int x, y, z;
vector *a, *b, *c;
CBig *cB1; //cBig is a class
};

struct *myData[100];

Will you use all those? No, is it taking up memory? Yes, an alternative is:

char* name[100];
char* date[100];
char* fileName[100];
FILE *filePtr[100];
int x[100], y[100], z[100];
vector *a[100], *b[100], *c[100];
CBig *cB1[100]; //cBig is a class