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

Discussion in 'Mac Programming' started by jmerkow, Jan 26, 2011.

  1. jmerkow, Jan 26, 2011
    Last edited by a moderator: Jan 26, 2011

    jmerkow macrumors newbie

    Joined:
    Jan 20, 2011
    #1
    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:
    http://forums.macrumors.com/showthread.php?t=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.
     
  2. subsonix macrumors 68040

    Joined:
    Feb 2, 2008
    #3
    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
     
  3. subsonix macrumors 68040

    Joined:
    Feb 2, 2008
    #4
  4. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #5
    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).
     
  5. subsonix macrumors 68040

    Joined:
    Feb 2, 2008
    #6
    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.
     
  6. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #7
    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
     
  7. bilboa macrumors regular

    Joined:
    Jan 16, 2008
    #8
    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.
     
  8. subsonix, Jan 26, 2011
    Last edited: Jan 26, 2011

    subsonix macrumors 68040

    Joined:
    Feb 2, 2008
    #9
    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.
     
  9. mfram macrumors 65816

    Joined:
    Jan 23, 2010
    Location:
    San Diego, CA USA
    #10
    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.
     
  10. Sander, Jan 27, 2011
    Last edited: Jan 27, 2011

    Sander macrumors 6502

    Joined:
    Apr 24, 2008
    #11
  11. ncl macrumors member

    Joined:
    Aug 16, 2008
    #12
    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:
    #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
     
  12. Sydde, Jan 27, 2011
    Last edited: Jan 27, 2011

    Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #13
    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.
     
  13. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #14
    Quibble - Objective-C requires a runtime environment. It need not be part of the OS.
     
  14. subsonix, Jan 27, 2011
    Last edited: Jan 27, 2011

    subsonix macrumors 68040

    Joined:
    Feb 2, 2008
    #15
     
  15. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #16
    I bow to you, sir, you have outpedanticed me! ;)
     
  16. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #17
    Sorry, no offense meant. Just trying to make sure the information was accurate.
     
  17. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #18
    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.
     
  18. Sander macrumors 6502

    Joined:
    Apr 24, 2008
    #19
    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.
     
  19. afiglee macrumors newbie

    Joined:
    Dec 1, 2010
    #20
    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
     
  20. ncl macrumors member

    Joined:
    Aug 16, 2008
    #21
    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.
    Never said it wasn't bad hacking :D But the object is allocated on the stack.
    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.
    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.
     
  21. afiglee, Jan 28, 2011
    Last edited: Jan 28, 2011

    afiglee macrumors newbie

    Joined:
    Dec 1, 2010
    #22
    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.
     
  22. ncl macrumors member

    Joined:
    Aug 16, 2008
    #23
    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:
    From the C standard:
    So, you can use 0 instead of NULL. It is perfectly standard compliant.
     
  23. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #24
    Given that the OP hasn't been seen around these parts since starting this thread, I'm not sure where the rails are in the first place. :p

    B
     
  24. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #25
    Ah, but if you look at his statistics page you'll see he was here reading the replies just this afternoon!
     

Share This Page