Re: Question (about C+, ObjC, ObjC++ ; long)
Re: Question (about C+, ObjC, ObjC++ ; long)
- Subject: Re: Question (about C+, ObjC, ObjC++ ; long)
- From: "Eduardo I. Jiménez" <email@hidden>
- Date: Mon, 3 Dec 2001 21:59:28 -0500
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.).
This is not the best solution. I recommend you read the Effective C++
series from Scott Meyers. Also, templates do support virtual methods
(I've used them for AI game engines before) (actually, you need them if
you plan to write a class that inherits from an instanced template,
which I have done before too).
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!
Well, I could add methods, but how would that help me to reach something
like multiple inheritance with substituablity? (I don't know if I
spelled it right, sorry if I didn't).
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.
Not in this case, and since the flaming in the list has been so bad I
will not elaborate on the matter. Suffice it to say I have multiple
inheritance in my design and it is not a mistake (sure, I could just
copy and paste code, but, come on).
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.
I've never heard of this before. Is there any documentation that would
describe the features of Obj-C++? Does it support templating? Does it
support MI?. Interesting.
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.)
I didn't quite understand the problem with constructors. Most of the
times the default constructor would work. How about destructors
(specially virtual ones, which are on base classes)?.
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.
Sorry, but I disagree (again, don't flame me, all of us have better
things to do, and its my very PERSONAL opinion). C++ is a very good
language. The main problem with C++ is finding the literature that will
open your eyes and make you see the real C++. Again, I recommend
Effective C++ and More Effective C++ from Scott Meyers. You'll see, C++
is not hard at all.
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.
These are definitively the features of C++ one uses less. I agree with
you on that.
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.
I agree with these. I HATE that ObjC does not have namespaces. It
doesn't make any sense. inline functions I understand, but it is a huge
disadvantage in terms of efficiency.
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);
Don't agree. C++ templates are one of the most powerful tools of
flexible design and generic programming. Actually, it is as useful as
inheritance itself. Operator overloading is very good for achieving code
clarity, but it is usually misused as an utility.
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,.
..
I don't know what is wrong with using STL. I did use it successfuly at
the ACM ICPC and it never failed the team. Also used it for game AI and
reached real-time efficiency. And the new and delete issue is minor if
you program your classes right or use autopointers (equivalent of
retain/release, but more elegant since less code is required).
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!);
Je, this is a disadvantage from templates, but your code is surely going
to be less buggy.
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.
The debugger has lots of problems with every object, even ObjC.
Thank you very much. This is one of the very few helpful emails. Don't
take my comments too seriously, I have programmed successfully in C++
for several years and I find most people just don't understand how it
works. I really think you should at least browse Scott Meyers books for
more C++ info. I like ObjC, but I feel I need correctness checking from
the compiler, which I won't get if I don't use multiple inheritance (or
at least relate objects in some inheritance related way).
Thanks a lot again.
Eduardo Jimenez