Re: programming in C++ ?
Re: programming in C++ ?
- Subject: Re: programming in C++ ?
- From: Uli Kusterer <email@hidden>
- Date: Thu, 31 Jan 2008 00:53:11 +0100
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden