Re: Question (about C+, ObjC, ObjC++ ; long)
Re: Question (about C+, ObjC, ObjC++ ; long)
- Subject: Re: Question (about C+, ObjC, ObjC++ ; long)
- From: email@hidden
- Date: Mon, 3 Dec 2001 11:19:20 +0100
Le lundi 3 dicembre 2001, ` 03:43 , Eduardo I. Jiminez a icrit :
Hi. I am not exactly an expert in Cocoa, but I am not a beginner.
Same for me ;-)
Now, I'm trying to develop a very complex application. This application
has a very complex design in terms of classes and relationships (about
150+ classes). Now, my basic problem is the following: this design has
many classes with multiple inheritance. I've tried to think of ways of
dealing with the problem, but I have not found an elegant solution. My
last resort is developing the "model" part of my application in C++,
which offers the features I need to implement this, and then using those
C++ classes from the "Controller" in my Cocoa application. Could someone
brief me in the complexities of doing this?. What kinds of problems can I
run into.
Eduardo Jimenez
I'm more or less in a similar situation. I'm currently developping (ending
;-) a set of classes to parse and evaluate C-like math expressions, and I
use both C++ and Obj-C for that. Let me tell you some ideas/opinions of
mine about C++ and Obj-C, and miwing them together.
First of all I fully agree with Greg Titus that multiple inheritance is
usually not necessary in Obj-C, even when it is really required in C++.
The main reasons is that, in C++, you cannot add a method to a class; once
you have written the closing brace, it is "locked". In Obj-C you can
always add new methods to a class (using a so-called 'category'). This is
VERY useful and a huge advantage of Obj-C. This is really important if you
want a number of classes all answer to the same messages (== methods), to
put them in an array for instance. In C++ you need to define a virtual
classe with only pure methods for that, then derive NEW classes from the
old ones with multiple inheritance of that one (and this is not always
possible, since template classes cannot have virtual methods; this can
also cause problems if the old classes have similarly named methods,
etc.). In Obj-C, you just add the new method through a category (this is
called an 'informal protocol'), or you use a (formal) protocol; you DON'T
define new classes in that case. Obviously the new methods cannot access
directly private members, but that's usually not a problem, since accessor
methods should already exist. You can even add methods to all objects,
using a category to NSObject!
Clearly multiple inheritance is required if you want an object with
members coming from two different base classes. However it is difficult to
find good examples for that; usually it is just a design error to do so,
one of the parent classes should be present only as a member.
On the other hand, you cannot forget efficiency. The true dynamism of
Obj-C has a cost, and sometimes you don't want to pay for that. This is
particularly the case for simple classes representing a small quantity of
data. Then you have to remember that you can use Obj-C++ (you just use the
extension '.mm' for your file). A class like that:
class mySmallData {
int field1, field2;
public:
void set(int f1, int f2) { field1 =f1; field2 = f2; }
void method1(...)...
};
don't use extra memory at all, and is very fast to use (if every method is
inlined). It is essentially a C-struct with more convenient access and
some data protection. It is usually not intended to be derived at all.
This sort of items can benefit from operator overloading and automatic
conversions, too.
It is very useful to mix them with "true" Obj-C object (usually as members
-- in particular you can instantiate the objects themselves, instead of
using pointers), and there is no major drawback except for the obvious
lack of dynamism, and a minor glitch you MUST remember: Obj-C class having
C+-style members CANNOT init them (that is NO constructor at all will be
called for them). Should you have constructors, the compiler will warn you
about that. So it is better to
-- either use classes with no constructor at all (that is, the default
constructor is safe enough);
-- or use constructors but DON'T FORGET to call a method like 'set' in
your [enclosingClass init];
-- or use pointer members as for Obj-C members items.
(I strongly hope this limitation will be removed in the future.)
C++ classes with virtual methods are not so useful. There is an overhead
in memory/speed for virtual methods, so you have to consider carefully if
a plain Obj-C would not better suit your needs. I'm using Obj-C for six
months now, and even though I still dislike the syntax (brackets...), it
is more and more obvious to me that the language itself is much more
efficient for programmers than C++. C++ is just too complicated and
unintuitive, trying to do automagically a lot of things... most of the
time I prefer typing a little bit more and knowing in detail what happens.
There is a lot of complicated things about OOP in C++, much of them don't
exist at all in Obj-C. It is NOT because Obj-C is inferior to C++, it is
just because the different approach on OOP makes them unnecessary in Obj-C.
Among them: multiple inheritance, public-protected derivation, forbiden
access to protected members in derived classes when called on objects of
the parent class, etc.
Now C++ has some very useful features (outside OOP) you may want to use in
Obj-C++ (some of them are or will be in standard C and Obj-C):
- namespaces
- const qualifier (for arguments, not for methods)
- inline functions
- default values for arguments
- declaration everywhere (this one I believe is very important, and is in
C-99; I can't wait to have it in plain Obj-C).
These are really useful even in plain-Cocoa developement.
Additionally, the C++ exception system seems superior to the Obj-C one,
but I didn't experiment a lot. I believe that mixing both could causes
problems, so be careful.
The following are not so useful:
- operator overloading (except when doing math, obviously);
- function overloading (for Obj-C method, it is better to use different
names -- actually you HAVE TO);
- references (use pointers; for Obj-C objects it is completely safe);
- templates (you cannot have virtual methods anyway in template classes);
The following should be avoided if possible:
- new and delete (the retain/release is WAY superior -- something
difficult to understand at first sight);
- STL == the standard libray; what a mess!
- std::string; NSString works better, handle unicode and other encodings,.
..
Now the problem is with the compiler and the debugger. Using C++ or Obj-C+
+ have non-negligible inconvenients:
1/ the compiler is VERY slow for C++ and Obj-C++ (this is partly
unavoidable, since the syntax of C++ is just terrible);
2/ error messages for C++ items are very difficult to understand. Exemple:
non-member function
`exprtree::hasFunction(basic_string<char,string_char_traits<char>,__default_alloc_template<
false,0> >, int)' cannot have `const' method qualifier
(The basic_string<...> thing is just std::string; try to use map<string,
vector<complex<double>>> for true madness!);
3/ sometimes the compiler get lost and produces incorrect error messages,
or just crashes; sometimes you cannot stop it, and it is displaying
hundreds of messages (due to a single typing error...);
4/ the debugger has a lot of problems with C++ objects: it cannot display
them most of the time, has difficulties with inline methods or automatic
conversions, and is just plain lost with exceptions. It crashes frequently,
and then ProjectBuilder is locked/crashed, too.
Obviously this is all my opinion/experience. Hope this helps anyway.
Yours,
Thomas Lachand-Robert
********************** email@hidden
<< Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.
| References: | |
| | >Question (From: "Eduardo I. Jiménez" <email@hidden>) |