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
