programming in C++ ?

  • You can use .mm for all your stuff and it will be fine. That's what I
    do.
    The only reasons that people use .m are:
    - somewhat faster compile times, since the C++ compiler is slower
    than the C compiler
    - the same reason people use .c files; they don't want C++ features
    or their code predates widespread C++ adoption

    On Jan 30, 2008, at 3:17 PM, Cor wrote:

    > I'm very new to Cocoa, so I'm sorry if this is more or less a
    > stupid question.
    >
    > I want to make an application that uses the QTKit and some IOKit
    > things.
    > For QTKit I seem te need to write in Objective-C.
    > For the IOKit I need to write in C++.
    >
    > I'm a experienced C++ programmer, so I prefer to program in C++,
    > but how do I interface to QTKit?
    >
    > I did read something about .mm files.
    > If I understand correctly then .mm files may contain Object-C and C+
    > + mix.
    > But if this is so, why are not all files .mm (why are .m files
    > needed?).
    >
    > And how do I call the Object-C functions?
    >
    > Does it hurt when I only use .mm files?
    > Does it makes sense to write Cocoa applications in C++?
    >
    > Thanks.
  • I'm very new to Cocoa, so I'm sorry if this is more or less a stupid question.

    I want to make an application that uses the QTKit and some IOKit things.
    For QTKit I seem te need to write in Objective-C.
    For the IOKit I need to write in C++.

    I'm a experienced C++ programmer, so I prefer to program in C++, but how do I interface to QTKit?

    I did read something about .mm files.
    If I understand correctly then .mm files may contain Object-C and C++ mix.
    But if this is so, why are not all files .mm (why are .m files needed?).

    And how do I call the Object-C functions?

    Does it hurt when I only use .mm files?
    Does it makes sense to write Cocoa applications in C++?

    Thanks.
  • Objective-C is only an extension to C or C++.
    So from within your objective-c code, you can call C or C++ function,
    you can intermix the two.

    Q: If I understand correctly then .mm files may contain Object-C and C++
    mix.
    A: Yes, the ".m" files can contain ObjC and C. The ".mm" files can
    contain ObjC and C++

    Q: But if this is so, why are not all files .mm (why are .m files needed?).
    A: Think of it as C and C++. In C we use .c as extension and in C++ we
    use .cpp as the file extension.

    Q: And how do I call the Object-C functions?
    A: You call them by sending message to objects. I strongly recommend you
    get the book "Cocoa programming for mac os x". It will tell you Obj-C as
    well as Cocoa.

    Q: Does it hurt when I only use .mm files?
    A: It depends on what you want to do.

    Q: Does it makes sense to write Cocoa applications in C++?
    A: Yes it does.

    Cor wrote:
    > I'm very new to Cocoa, so I'm sorry if this is more or less a stupid question.
    >
    > I want to make an application that uses the QTKit and some IOKit things.
    > For QTKit I seem te need to write in Objective-C.
    > For the IOKit I need to write in C++.
    >
    > I'm a experienced C++ programmer, so I prefer to program in C++, but how do I interface to QTKit?
    >
    > I did read something about .mm files.
    > If I understand correctly then .mm files may contain Object-C and C++ mix.
    > But if this is so, why are not all files .mm (why are .m files needed?).
    >
    > And how do I call the Object-C functions?
    >
    > Does it hurt when I only use .mm files?
    > Does it makes sense to write Cocoa applications in C++?
    >
    > Thanks.
    >
  • On 31.01.2008, at 00:17, Cor wrote:
    > I'm a experienced C++ programmer, so I prefer to program in C++, but
    > how do I interface to QTKit?
    >
    > I did read something about .mm files.
    > If I understand correctly then .mm files may contain Object-C and C+
    > + mix.
    > But if this is so, why are not all files .mm (why are .m files
    > needed?).

      C++ is not a subset of C, it has some behavioural differences. If
    you specify .mm, regular C code gets compiled as C++ code, which can
    cause existing C code to no longer work correctly. These are generally
    edge cases, but they exist.

      Also, the ObjC++ compiler is not the fastest compiler (C++ is more
    complicated to parse correctly than C, and if you add Objective C on
    top of that, it doesn't get faster, though Objective C is a fairly
    lightweight and un-ambiguous language when it comes to parsing it).

    > And how do I call the Object-C functions?

      What ObjectiveC++ effectively does is that it allows you to mix ObjC
    and C++ on the operand level. That means that Objective C stays
    Objective C, and C++ stays C++, and particularly C++ objects are
    distinct from Objective C objects, but you can mix them in one
    expression. However, apart from the mixing, each language is used the
    same way it always has been used.

      ObjC++ simply means that the parts of ObjC that are identical to C
    can be swapped out for C++ constructs.

      Since both languages stay distinct, you have to be careful, though.
    You generally want to keep the language boundaries clean, and you
    don't want to throw C++ exceptions through ObjC methods or vice versa
    (i.e. if you make a C++ call inside an ObjC method, wrap it in a try
    block and same for the other way round). You'll also have to create
    some Objective C objects that forward calls to your C++ code and back,
    because most of the Cocoa frameworks expect to be handed ObjC objects
    to send their messages to.

    > Does it hurt when I only use .mm files?

      It can add up, compile-time wise. Where I work, we generally keep
    stuff segregated as much as possible, so only the classes that are at
    the boundaries between C++ and ObjC will be in .mm files. Of course,
    you'll have the same issues as you have when interfacing C and C++
    when interfacing between ObjC and C++, i.e. you need to have your
    'extern "C"' statements in there to be able to call C functions from C+
    + without link errors, but in general the shorter compile times and
    the clearer segregation of the different layers are worth it, and will
    actually benefit code readability.

    > Does it makes sense to write Cocoa applications in C++?

      I don't think that's the question you wanted to ask, but to answer
    it, it is not *possible* to write a Cocoa application in C++, as Cocoa
    is a framework that relies heavily on ObjC objects, selectors and
    similar features. Of course, in theory you could use objc_msgSend()
    and the likes to fake all that in C++, but only someone who has fun
    mucking with runtime data structures directly, or a madman who likes
    to poke his open, bleeding heart would do that ;-)

      It does make perfect sense, however, to write parts of your
    application in C++. Every language has its strengths. You do not want
    to be without Cocoa's great standard view classes ("View" as in the
    "Model-View-Controller" pattern - this includes NSView, but also
    NSWindow, NSMenu and others), and there are some controllers that go
    with them. However, if it makes sense for your project, you can write
    the model of your application (data management and storage) in C++,
    plus any controllers that don't need to directly interact with the
    views.

      However, it will generally be easier to stick to pure Objective C
    where you can. I think most of IOKit is actually straight C, and only
    a few parts (Kernel extensions, for example) are C++. So what I would
    recommend is you write those parts that must necessarily be C++ in
    that language, and at a natural boundary, put the transition from ObjC
    to C++. So, e.g. write your kext in C++, use CoreFoundation to store
    preferences on disk that needs to be accessible from Objective C, and
    take advantage of toll-free-bridging to use the CoreFoundation objects
    as native objects in ObjC.

      Of course, if you already have existing C++ libraries, there may be
    more C++, or if you want to keep code portable to other platforms, but
    since UI generally ports badly to other platforms, you'd want to just
    wrap the whole view layer to talk to a few C++ classes and that's it.

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • Just a minor/pedantic correction, but if you use the new ObjC 2.0
    runtime in 64-bit mode, C++ and ObjC exceptions are actually
    semi-compatible; they use the same underlying mechanism and don't
    completely break when you mix and match them.

    Other than that, Uli's explanation was totally on-target, though some of
    it is really a matter of opinion… language preference wars aren't really
    fun though, and they're certainly OT for this list :)

    Uli Kusterer wrote:
    > you don't want to throw C++ exceptions through ObjC methods or vice
    > versa (i.e. if you make a C++ call inside an ObjC method, wrap it in a
    > try block and same for the other way round).
  • On 31.01.2008, at 00:17, Cor wrote:

    > For QTKit I seem te need to write in Objective-C.
    > For the IOKit I need to write in C++.
    >
    > I'm a experienced C++ programmer, so I prefer to program in C++, but
    > how do I interface to QTKit?
    >
    > I did read something about .mm files.
    > If I understand correctly then .mm files may contain Object-C and C+
    > + mix.
    > But if this is so, why are not all files .mm (why are .m files
    > needed?).

    [...]

    > Does it hurt when I only use .mm files?

    Yes. Significantly higher compile times and as others stated,
    different parsing, in this case: stronger type checking.
    While the Obj-C compiler does not complain in a number of places where
    you assign the 'id' you get back from [anArray objectAtIndex:i] to
    e.g. an NSString *, the C++ compiler does.
    So basically, to silence the compiler, quite some casts are required,
    which is IMHO fundamentally against the spirit of C++.
    OTOH, for many Cocoa runtime errors you get at least a compiler
    warning, so you probably don't want noise on your compiler warnings.

    Another sidenote: IOKit uses AFAIK an exception- and template-less
    subset of C++, so the mix with Objective-C is far smoother.
    (IMO, the maior PITA for CORRECT code are the different exception
    handling mechanisms).

    > Does it makes sense to write Cocoa applications in C++?

    No. But it makes partially sense to write it in Objective-C++ ;-).

    Regards,
    Tom_E
  • Like you I used to be a primarily c++ coder,and using objective-c++
    enabled an easier transition for me to obj-c.

    It does give you some nice features like the ability to declare
    variables anywhere in your code, not just at the top, and the ability
    to fall back on STL classes when needed.

    That said, however, I just finished converting all that code over to
    straight obj-c for a lot of the reasons already given. Also, some of
    the newer Xcode features like refactoring etc dont work with obj-c++,
    so if you want to get the most out of Xcode, you may want to use obj-c.

    Some things to make your life easier if you do:

    - enable C99 which enables declaring variables anywhere etc
    - you can mix .m .mm and .cc files to your hearts content even in the
    same project with no effort at all. Use this to interface with
    whatever libs you need.

    --
    Jiva DeVoe
    http://www.random-ideas.net

    On Jan 31, 2008, at 1:22 AM, Thomas Engelmeier <te-work-list...>
    > wrote:

    >
    > On 31.01.2008, at 00:17, Cor wrote:
    >
    >> For QTKit I seem te need to write in Objective-C.
    >> For the IOKit I need to write in C++.
    >>
    >> I'm a experienced C++ programmer, so I prefer to program in C++,
    >> but how do I interface to QTKit?
    >>
    >> I did read something about .mm files.
    >> If I understand correctly then .mm files may contain Object-C and C+
    >> + mix.
    >> But if this is so, why are not all files .mm (why are .m files
    >> needed?).
    >
    > [...]
    >
    >> Does it hurt when I only use .mm files?
    >
    > Yes. Significantly higher compile times and as others stated,
    > different parsing, in this case: stronger type checking.
    > While the Obj-C compiler does not complain in a number of places
    > where you assign the 'id' you get back from [anArray
    > objectAtIndex:i] to e.g. an NSString *, the C++ compiler does.
    > So basically, to silence the compiler, quite some casts are
    > required, which is IMHO fundamentally against the spirit of C++.
    > OTOH, for many Cocoa runtime errors you get at least a compiler
    > warning, so you probably don't want noise on your compiler warnings.
    >
    > Another sidenote: IOKit uses AFAIK an exception- and template-less
    > subset of C++, so the mix with Objective-C is far smoother.
    > (IMO, the maior PITA for CORRECT code are the different exception
    > handling mechanisms).
    >
    >> Does it makes sense to write Cocoa applications in C++?
    >
    > No. But it makes partially sense to write it in Objective-C++ ;-).
    >
    > Regards,
    > Tom_E
    >
  • On Jan 31, 2008 7:17 AM, Jiva DeVoe <jiva...> wrote:
    > Like you I used to be a primarily c++ coder,and using objective-c++
    > enabled an easier transition for me to obj-c.
    >
    > It does give you some nice features like the ability to declare
    > variables anywhere in your code, not just at the top,

    Using C99 would give you that same freedom without incurring C++
    compiler overhead.

    -Shawn
  • On Jan 31, 2008 8:39 AM, Shawn Erickson <shawnce...> wrote:
    > On Jan 31, 2008 7:17 AM, Jiva DeVoe <jiva...> wrote:
    >> Like you I used to be a primarily c++ coder,and using objective-c++
    >> enabled an easier transition for me to obj-c.
    >>
    >> It does give you some nice features like the ability to declare
    >> variables anywhere in your code, not just at the top,
    >
    > Using C99 would give you that same freedom without incurring C++
    > compiler overhead.

    Doh missed the bottom part of your message (didn't scroll down on my
    iPhone far enough).

    -Shawn
  • I've used a lot of ObjC++ and I haven't had any problems with assigning
    ids. It seems to work just like you would expect.

    Thomas Engelmeier wrote:
    >
    > On 31.01.2008, at 00:17, Cor wrote:
    >
    >> For QTKit I seem te need to write in Objective-C.
    >> For the IOKit I need to write in C++.
    >>
    >> I'm a experienced C++ programmer, so I prefer to program in C++, but
    >> how do I interface to QTKit?
    >>
    >> I did read something about .mm files.
    >> If I understand correctly then .mm files may contain Object-C and C++
    >> mix.
    >> But if this is so, why are not all files .mm (why are .m files needed?).
    >
    > [...]
    >
    >> Does it hurt when I only use .mm files?
    >
    > Yes. Significantly higher compile times and as others stated,
    > different parsing, in this case: stronger type checking.
    > While the Obj-C compiler does not complain in a number of places where
    > you assign the 'id' you get back from [anArray objectAtIndex:i] to
    > e.g. an NSString *, the C++ compiler does.
    > So basically, to silence the compiler, quite some casts are required,
    > which is IMHO fundamentally against the spirit of C++.
    > OTOH, for many Cocoa runtime errors you get at least a compiler
    > warning, so you probably don't want noise on your compiler warnings.
    >
    > Another sidenote: IOKit uses AFAIK an exception- and template-less
    > subset of C++, so the mix with Objective-C is far smoother.
    > (IMO, the maior PITA for CORRECT code are the different exception
    > handling mechanisms).
    >
    >> Does it makes sense to write Cocoa applications in C++?
    >
    > No. But it makes partially sense to write it in Objective-C++ ;-).
    >
    > Regards,
    > Tom_E
  • On Jan 30, 2008, at 3:17 PM, Cor wrote:

    > I'm very new to Cocoa, so I'm sorry if this is more or less a stupid
    > question.
    >
    > I want to make an application that uses the QTKit and some IOKit
    > things.
    > For QTKit I seem te need to write in Objective-C.
    > For the IOKit I need to write in C++.
    >
    > I'm a experienced C++ programmer, so I prefer to program in C++, but
    > how do I interface to QTKit?

    Just to point something obvious out, but why to you think you need C++
    for IOKIt?  Inside the kernel, IOKit is quasi-C++, but in user space
    (where you'd be mixing with QTKit), it's a straight C API.  You can
    use C++ if you'd like, but nothing in IOKit needs/requires it...
  • On the general topic of mixing Cocoa/Objective-C and C++, I might
    knock on wood and report a modest success story:

    I have an application -- a Scheme-programming-language interpreter
    (Wraith Scheme) -- designed in the model/view/controller pattern.
    The model is essentially all straight C++ -- all ".c++" files and
    associated headers -- and when I use it in a standard Macintosh
    application, it runs in its own thread.  The view and controller are
    in that case mostly Objective-C, with occasional references to things
    to get the model's thread going and keep in touch with it; they use
    all either ".m" or ".mm" files, with associated headers, and with
    lots of Cocoa calls.

    I set the application up this way because I originally got the
    application going with the model running with two additional,
    different, view/controller combinations:  The same C++ code for the
    model can run with a straight Unix-shell view/controller -- as a text-
    oriented line-at-a-time process in a "Terminal" window -- or with an
    "ncurses" view/controller, also running in a Terminal window.  I
    followed that development path to port the program to Tiger from a
    much older Mac application, dating from pre-Carbon Mac-Toolbox days.
    I was a newcomer to Cocoa at the time of the port, so I did it that
    way in order to deal with upgrading the model separately from coming
    up to speed on Cocoa.  I use #ifdefs on symbols defined by compile-
    time flags to control which build to create and to control how the
    model communicates with its view/controller -- the Cocoa version is
    built with XCode (2.4.1, on Tiger), the Unix versions with
    conventional make files.  There are also, of course, different source
    files used for the different view/controller combinations.

    This mix of languages, libraries, and build mechanisms has worked
    seamlessly so far (and this is where I knocked on wood).  My suite of
    regression tests automatically builds and tests all of these
    versions, and there have been few maintenance problems associated
    with the differences between them.  I suspect (another knock on wood)
    that it would be straightforward to adapt the Unix versions of the
    application to (heresy!) other Unix versions and other hardware
    platforms.

    --  Jay Reynolds Freeman
    ---------------------
    <Jay_Reynolds_Freeman...>
    http://web.mac.com/jay_reynolds_freeman (personal web site)
  • On 31.01.2008, at 18:25, John Stiles wrote:

    > I've used a lot of ObjC++ and I haven't had any problems with
    > assigning ids. It seems to work just like you would expect.

    Jepp. In contrary to my brain with a lack of caffeine, apparently.
    When I recently .mm-iefied an Objective-C (sample code) file I had to
    add tons of casts for the assignments of (void *) malloc result to
    char pointers, but not for id to NSAnything assignments...

    Sorry for the noise..

    Regards,
    Tom_E
  • Well, most C++ code should be using new and not malloc() anyway.
    malloc() is a holdover from the Bad Untyped Days of C.

    Thomas Engelmeier wrote:
    >
    > On 31.01.2008, at 18:25, John Stiles wrote:
    >
    >> I've used a lot of ObjC++ and I haven't had any problems with
    >> assigning ids. It seems to work just like you would expect.
    >
    > Jepp. In contrary to my brain with a lack of caffeine, apparently.
    > When I recently .mm-iefied an Objective-C (sample code) file I had to
    > add tons of casts for the assignments of (void *) malloc result to
    > char pointers, but not for id to NSAnything assignments...
    >
    > Sorry for the noise..
    >
    > Regards,
    > Tom_E
    >
  • On 01.02.2008, at 18:35, John Stiles wrote:

    > Well, most C++ code should be using new and not malloc() anyway.
    > malloc() is a holdover from the Bad Untyped Days of C.

    That particular API has some semantics that proliverate bad
    programming practice, anyway - structs with trailing variable length
    data buffers. A lot of C casts, offsetof and whatever.

    Regards,
    Tom_E
  • On 3 Feb 2008, at 16:44, Thomas Engelmeier wrote:

    > On 01.02.2008, at 18:35, John Stiles wrote:
    >
    >> Well, most C++ code should be using new and not malloc() anyway.
    >> malloc() is a holdover from the Bad Untyped Days of C.
    >
    > That particular API has some semantics that proliverate bad
    > programming practice, anyway - structs with trailing variable length
    > data buffers. A lot of C casts, offsetof and whatever.

    Structs with variable length data buffers are not "bad programming
    practice".

    You may not *like* them, but that's different from them being
    inherently bad, even if it's a sentiment shared by many others.  In
    some circumstances they are the best way to solve a problem.  This is
    primarily the case where the overhead from keeping the variable length
    data separate would be too high; a straightforward example is with
    strings, which are *often* represented with a struct with variable-
    length trailing data.  (Indeed, I think NS/CFString does exactly this
    in some cases.)

    Put another way, eschewing malloc() or variable length structs in all
    situations is not pragmatic---it's dogmatic, and that's never a good
    way to make a decision.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today