Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Really good guide for moving from C++ to objective C

J

jmerkow

macrumors newbie
Original poster
Jan 20, 2011
17
0
I know you can use C++ in objective C. But I was looking for a guide that does a comparison of syntax and libraries (the bascis and STL). I looked a bit online and couldn't find a very good cheat sheet. I saw this post here:
https://forums.macrumors.com/threads/338244/

but its not very comprehensive and the some of the links are dead. Any one know of a really good reference for this?

I meant cocoa. I am working in cocoa. trying to develop a mac app.
 
Last edited by a moderator:
Since you know C++, I can mention a few things that Obj-C has or has not.

• Polymorphic bindings only.
• Retain count memory management model.
• Optional garbage collection.
• Convenience directives such as @synthesize to generate getters and setters.
• Obj-C has a more dynamic runtime, which allows for things like Cocoa bindings and so on.
• No initialization inside classes, (alloc, init pattern is used when objects are created)
• No object allocation on the stack.
• No operator overloading
• No complexities such as multiple inheritance or friend relations between classes.

All in all Obj-C is a smaller, less complex language in my opinion. Also, I might have gotten something wrong here, if so just mention it. :D
 
Sydde said:
More precisely, no static allocation: objects can only ever be referenced using a pointer (this applies to the ivar declaration block as well as the stack).
Click to expand...

Not sure if I get you here, in C++ you can do something like this:

Code: 
myObject object;
object.doSomething();

Such an object is created without the new keyword and it's lifetime is restricted to the scope where it's declared, just like regular C data types. The object will be poped of the stack once we leave the scope. No allocation or manual memory management is necessary in such a case.
 
I'm really not sure what the OP is after. The point I'm missing is that Cocoa and STL are very different things. You shouldn't expect there to be a crib sheet to connect them.

STL is more akin to things available in Foundation, but there should be little stopping you from using plain C++/STL for the guts of your code and Cocoa/Objective-C(++) for the Mac interface. Only the bits that are exposed to the UI need to be in both.

I worked on a Visual C++ project many moons ago, and the first step on stabilizing the code was to separate the working bits from the UI. Kind if like a proto-MVC approach.

B
 
subsonix said:
Not sure if I get you here, in C++ you can do something like this:

Code: 
myObject object;
object.doSomething();

Such an object is created without the new keyword and it's lifetime is restricted to the scope where it's declared, just like regular C data types. The object will be poped of the stack once we leave the scope. No allocation or manual memory management is necessary in such a case.
Click to expand...

What you're showing is C++ code. You're correct that it is possible to create instances of C++ classes on the stack or the heap. The post you're responding to was talking about Objective-C though. You cannot create instances of Obj-C classes on the stack, only on the heap.
 
bilboa said:
What you're showing is C++ code. You're correct that it is possible to create instances of C++ classes on the stack or the heap. The post you're responding to was talking about Objective-C though. You cannot create instances of Obj-C classes on the stack, only on the heap.
Click to expand...

Yes? But that is exactly what I said in my first post.

• No object allocation on the stack.

That is to say, objects can not be created on the stack in Obj-C. To this I got a response, no static allocation? I found this confusing, so to clarify what I meant, I made an example from C++ where this is possible by the same mechanisms as in C.
 
Last edited:
subsonix said:
• Polymorphic bindings only.
• Retain count memory management model.
• Optional garbage collection.
• Convenience directives such as @synthesize to generate getters and setters.
• Obj-C has a more dynamic runtime, which allows for things like Cocoa bindings and so on.
• No initialization inside classes, (alloc, init pattern is used when objects are created)
• No object allocation on the stack.
• No operator overloading
• No complexities such as multiple inheritance or friend relations between classes.
Click to expand...

Some of the reasons I think Objective-C is closer to Java than C++. Sure, there are other differences between Java and Obj-C. But Java objects are much more dynamic like Obj-C objects rather than static, compiled in C++ objects.
 
subsonix said:
To this I got a response, no static allocation? I found this confusing, so to clarify what I meant, I made an example from C++ where this is possible by the same mechanisms as in C.
Click to expand...

What Sydde meant (I think) is that you can't write:
Code: 
@interface Object {
    Object2 member;
}
@end
Even if an instance of Object is dynamically allocated (and therefore, member will be created on the heap), you can't do this. You have to declare member as a Object2*.
Thus, saying no static allocations is more complete.

bilboa said:
You cannot create instances of Obj-C classes on the stack, only on the heap.
Click to expand...
Code: 
#define JOIN2(a, b) a ## b 
#define JOIN(a, b) JOIN2(a, b)
#define stack_create(var, class_name) \
    unsigned char JOIN(dummy_array, __LINE__)[sizeof(class_name)] = {0}; \
    id var = (id)&JOIN(dummy_array, __LINE__)[0]; \
    *((Class*)var) = [class_name class];

int main() {   
    stack_create(obj, NSObject);
    [obj init];
    NSLog(@"%@", [obj class]);
    return 0;
}
There. NSObject created on the stack :p
 
subsonix said:
Not sure if I get you here, in C++ you can do something like this:

Code: 
myObject object;
object.doSomething();

Such an object is created without the new keyword and it's lifetime is restricted to the scope where it's declared, just like regular C data types. The object will be poped of the stack once we leave the scope. No allocation or manual memory management is necessary in such a case.
Click to expand...

Your list looked to me like a description of Objective-C as seen from a C++ perspective - in other words, focussed on Objective-C's characteristics.

In Objective-C, an object is a pointer. The compiler will spit up on you if you try to declare an object that is not a pointer (static allocation). The stack is not the only place you might declare an object. If it is a global, or an instance variable in a class definition, a pointer is what is expected.

I am not particularly familiar with C++, but from what I understand, an object is not significantly different from the struct that defines its instance. Objective-C attempts to apply opacity to its methodology. You are not supposed to be able to "reach inside" an NSObject from "outside" it. From what I understand of C++, if your code has the definition of a given object's instance struct, it can directly manipulate the instance content, whereas in Objective-C your code is expected to rely on a given object's methods to access and/or manipulate its content. You can work around these Objective-C constraints, but in that case, why not just use plain C in the first place?

Objective-C is a thing, whereas C++ is not. For a program to work in Objective-C, the operating system must support it; AFAICT, C++ is one way to produce stand-alone object code that does not require any additional support from the OS.
 
Last edited:
Sydde said:
Objective-C is a thing, whereas C++ is not. For a program to work in Objective-C, the operating system must support it; AFAICT, C++ is one way to produce stand-alone object code that does not require any additional support from the OS.
Click to expand...

Quibble - Objective-C requires a runtime environment. It need not be part of the OS.
 
ncl said:
What Sydde meant (I think) is that you can't write:
Code: 
@interface Object {
    Object2 member;
}
@end
Even if an instance of Object is dynamically allocated (and therefore, member will be created on the heap), you can't do this. You have to declare member as a Object2*.
Thus, saying no static allocations is more complete.

Code: 
[/QUOTE]

I see, I did not think of it that way.

[quote="Sydde, post: 11799466"]Your list looked to me like a description of Objective-C as seen from a C++ perspective - in other words, focussed on Objective-C's characteristics.

In Objective-C, an object is a pointer. The compiler will spit up on you if you try to declare an object that is not a pointer (static allocation). The stack is not the only place you might declare an object. If it is a global, or an instance variable in a class definition, a pointer is what is expected.[/QUOTE]

Yes, but again that is the point I was making. The same is true in C++ and in C. You need to create a pointer, which will point to the object allocated on the heap. 

[quote="Sydde, post: 11799466"]
I am not particularly familiar with C++, but from what I understand, an object is not significantly different from the struct that defines its instance. Objective-C attempts to apply opacity to its methodology. You are not supposed to be able to "reach inside" an NSObject from "outside" it. From what I understand of C++, if your code has the definition of a given object's instance struct, it can directly manipulate the instance content, whereas in Objective-C your code is expected to rely on a given object's methods to access and/or manipulate its content. You can work around these Objective-C constraints, but in that case, why not just use plain C in the first place?
[/QUOTE]

That is exactly the same in these languages (and OOP in general), an object is nothing but a glorified struct that has function pointers and a this/self pointer available on the inside. The other significant difference is that a struct has public members by default but in a class they are private by default.

You could imitate a class in C like this, except the this/self pointer.

[CODE]
struct Object {
    int iVar;
    void (*setValue)(int);
    int (*getValue)();
};

BTW, you can get the function lookup to appear at run time in C++ by declaring a function as virtual.
Click to expand...
 
Last edited:
lloyddean said:
Sorry, no offense meant. Just trying to make sure the information was accurate.
Click to expand...

I will go out on a limb and guess that your computer behaves a little like mine: mine is a stickler for detail, you get one tiny little thing wrong, one mis-spelling, one improperly placed subscripting, and your program will just not work right. Many clumps of hair later, followed by a bright red palm print on your forehead and you can go on to the next bug. Therefore, pedantry, though it may be annoying in other circumstances, is often warranted when dealing computer related matters.

Or: no apology necessary.
 
ncl said:
...
skipped..

There. NSObject created on the stack :p
Click to expand...
No, bad hacking in my opinion.
No call to alloc. What alloc does between other things - initializes memeber variables to 0.
So, when you call init - there is no guarantee it will be 0.
Secondly, does not message class returns class whereas you need an instance?
class is a singleton and message[method] alloc used to allocate instances.
Only class messages - declared with plus sign may work on class, and class CANNOT have member variables.

So, your code I would think, completely unacceptable.
Even if it would work it proves nothing as contradicts Objective-C principles

Correct me, if I'm wrong
 
Sander said:
That looks rather dangerous to me. The object's dealloc isn't called, so if the object allocates anything in its init, this stuff will leak.
Click to expand...
Of course it is dangerous :p And indeed you need to call dealloc manually (kinda like in C++ with placement new where you have to call the destructor manually).
But honestly, I think that's the least of the problems with this thing.
afiglee said:
No, bad hacking in my opinion.
Click to expand...
Never said it wasn't bad hacking :D But the object is allocated on the stack.
No call to alloc. What alloc does between other things - initializes memeber variables to 0.
Click to expand...
Huh ? I thought in C, declaring an array with "= {0}" initializes all its elements to 0. Anyway, if I'm wrong, just add a memset() call and problem solved.
Secondly, does not message class returns class whereas you need an instance?
Click to expand...
No, I'm setting the value of the isa pointer, therefore I need the class.
Even if it would work it proves nothing as contradicts Objective-C principles
Click to expand...
It was just a joke (hence the :p) replying to "You cannot create instances of Obj-C classes on the stack, only on the heap." There I did. And it works, even with more complex objects than NSObject.
Of course nobody would ever want to use anything like that seriously.
 
ncl said:
No, I'm setting the value of the isa pointer, therefore I need the class.

It was just a joke (hence the :p) replying to "You cannot create instances of Obj-C classes on the stack, only on the heap." There I did. And it works, even with more complex objects than NSObject.
Of course nobody would ever want to use anything like that seriously.
Click to expand...

Eh, so it was phrased "you cannot create instances of the class".
What you did effectively is a runtime class, not an instance.

Being pedantic - essentially what you are proving - if it is possible, "it is possible in a particular implementation".
Just like replacing "NULL" with 0 in plain C.
It would be possible in most cases, but generally, NULL is not 0.
 
Last edited:
afiglee said:
Eh, so it was phrased "you cannot create instances of the class".
What you did effectively is a runtime class, not an instance.
Click to expand...
Err, no. It is creating an instance of NSObject. And it would work in any sane implementation. In Objective-C, an instance of a class is only a bunch of bytes with the first sizeof(Class) bytes being a pointer to the instance's class object. And that's exactly what the code I posted creates. Seriously, it does the exact same thing than the Objective-C runtime when you call +alloc, except that instead of mallocing the memory, it reserves it on the stack. Example for the gnustep implementation of NSObject:
http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Source/NSObject.m?revision=31847&view=markup
The only thing they added is stuff for the GC, which I never use anyway so I don't care about that.

Anyway, as I said, it was more a joke than anything else. I didn't think it would derail the thread like that :eek:
Just like replacing "NULL" with 0 in plain C.
It would be possible in most cases, but generally, NULL is not 0.
Click to expand...
From the C standard:
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. 55)
...
55) The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.
Click to expand...
So, you can use 0 instead of NULL. It is perfectly standard compliant.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back