Objective-C: the More Flexible C++
September 13th, 2002 by Armin Roehrl and Stefan Schmiedl in
It is a surprising fact that anyone studying GNUstep or the Cocoa Framework will notice they are nearly identical to the NEXTSTEP APIs that were defined ten years ago. A decade is an eternity in the software industry. If the framework (and its programming language--Objective C) came through untouched these past ten years, there must be something special about it. And Objective-C has done more than survive; some famous games including Quake and NuclearStrike were developed using Objective-C.
Objective-C gives you the full power of a true object-oriented language with exactly one syntax addition to C and, unlike C++, about a dozen additional keywords.
Since Apple purchase Next for $400 million and Mac OS X ships with Objective-C, recycling NEXTSTEP (later called OpenStep), as well as the fact that GNUstep is delivering the rock-solid window-manager Window Maker, Objective-C is (rightly) getting more attention because it is more flexible than C++ at the cost of being slower.
In reality, Objective-C is Object C and is as close to Smalltalk as a compiled language can be. This is no surprise as Brad J. Cox added object-oriented, Smalltalk-80-based extensions to the C language.
So objective-C is a hybrid between Smalltalk and C. A string can be represented as a `char *' or as an object, whereas in Smalltalk everything is an object. As with Java (int, double,.. are no objects) this leads to faster performance.
In contrast, C++ traditionally is associated with the Simula 67 school of object-oriented programming. In C++, the static type of an object fixes what messages it can receive. In Objective-C the dynamic type of an object determines what messages it can receive. The Simula 67 format allows problems to be detected at compile time. The Smalltalk approach delays typing until runtime and therefore is more flexible.
A GNU version was written by Dennis Gladding in 1992 and then Richard Stallman took over the development. The current GNU version is derived from the version written by Kresten Thorup when he was a still a university student in 1993. He ported that version to the NeXTcube and joined NeXT.
Apple chose Objective-C for Cocoa, as NEXTSTEP was based on Objective-C. But, even if they had written it from scratch, they might have decided to use Objective-C because it is object-oriented, which is undoubtedly a must for big software projects. It extends the standard ANSI C, so that existing C programs can be adapted to use the frameworks, and programmers can chose when to stick to procedural programming and when to go the object-oriented way. C was intended to be a good language for system programming. C is fine as it allows the programmer to do exactly what she wants, all the way down to the hardware. C also keeps the gold old pointers, which can be used for efficient code.
Objective-C is simple, unambiguous and easy to learn. But most of all, it is the most dynamic language of all object-oriented languages based on C. Its dynamic late binding offers flexibility and power. Messages are not constrained by either the class of the receiver or the method selector, allowing rapid change and offering access to information about running applications.
The following is a short introduction to OOP in Objective-C, starting with the basics. Procedural programs consist of data and operations on data. OOP works at a higher level by grouping data into units, which are called objects. Several objects combined and their interactions form a program.
Abstraction is at the root of all understanding; it helps us capture the bigger image as the details are hidden. Object-Oriented Programming and the Objective-C Language (see Resources) shows the image of a clock cut half-open: what we normally see (the external view) is the interface, and the implementation (the internal workings) is hidden inside.
@interface declares a new class. It indicates the name of the class and its superclass, the protocols adhered to, the layout of the instance variables and declares the methods implemented by this class. Traditionally a class interface is stored in a file called <classname>.h.
Only externally visible methods are listed in the interface section. However, there are visibility keywords for instance variables:
@private: the instance variable is accessible only within the class that declares it.
@protected: the instance variable is accessible within the class that declares it and with the class that inherits it.
@public: the instance variable is accessible everywhere.
@implementation' defines a class. The implementation is a collection of method definitions stored in a file called <classname>.m.
The only way to tell an object to do something is to send it a message. The well known metaphor of objects as active actors can be used. An actor communicates through a message to another to request that she do something. The receiving object is called the "receiver" of that message. The receiver will determine the concrete behavior. It will make a big difference if you send "I love you" to Catherine instead of Katia. Different receivers cause different implementations.
[receiver message]; [receiver message: arg1];
Arguments are used after colon-terminated message selectors.
If a message is declared as -message, it can be sent to objects. A leading plus sign (+) means that the message can be sent to class objects. The default return type for methods is "id". If a method has nothing useful to return, it returns "self", which is a pointer to the object to which the message was sent (similar to "this" in C++).
By implementing the method -doesNotUnderstand:
-doesNotUnderstand: msg { [msg sentTo:delegate]; }
an object can forward messages to another object ("delegate"), including messages that return C structs, doubles, chars and so on.
A class is used to produce similar objects, called instances of the class. Classes are used to encapsulate data and methods that belong together. Methods are the operations that Objective-C applies to data and are identified by their message selectors.
Objective-C supports polymorphism: several classes can have a method with the same name.
Inheritance is used for code reuse. Classes inherit variables and methods from a higher-level class called a super-class. A class that inherits some or all of the methods and variables is a sub-class. In Objective-C, all classes are a sub-class of a primal super-class called Object.
Compile-time and link-time constraints are limiting because they force issues to be decided from information found in the programmer's source code, rather than from information obtained by the running program. Such static languages usually refuse to introduce new modules or new types during runtime. Objective-C makes as many decisions as possible at runtime:
Dynamic typing: waiting until runtime to determine the class of an object.
Dynamic binding: determining at runtime what method to invoke--no need to bother about what is done when. This allows it to change the components of a program incrementally.
Dynamic loading: program segments are not loaded into memory until they are actually used, thereby minimizing the system resources required for an instance of a program.
If your program offers a framework for others to use at runtime, you can discover what they have implemented and load it at runtime as needed.
Objective-C programs are structured through inheritance (how objects relate by type) and the pattern of message passing (explains how program works).
As the name implies, object-oriented programs are built around objects. Objects are the root of the Objective-C family tree.
id is an object identifier that is a distinct data type. It is a pointer to an object (in reality a pointer to an object's data--its instance variables). The actual class of the Object does not matter because Objective-C does runtime binding.
nil is the null object. The id of nil is 0. Other basic types of Objective-C are defined in the header file, objc/Objc.h.
Every object also carries an is an instance variable that identifies the object's class (what kind of object is it?). This allows objects to be typed dynamically at runtime. isa also allows objects to introspect themselves so they can find out what methods they have.
Usually, you create objects with a call to alloc:
id MyRect; myRect=[Rectangle alloc];
alloc allocates and clears memory for the instance variable. Initialization typically follows allocation immediately.
myRect=[[Rectangle alloc] init];
Here is an extended example of the lists.
---List.h----
#import <objc/Object.h>
@interface List : Object
{
int list[100]; // These are instance variables.
int size;
}
/* Public methods */
- free;
- (int) addEntry: (int) num;
- print;
@end
---------List.m---------------
#import "List.h"
@implementation List
+ new
{
self = [super new];
[self resetSize];
return self;
}
- free
{
return [super free];
}
- (int) addEntry: (int) num
{
if (size<100)
list[size++] = num;
return size;
}
- print
{
int i;
printf(" \n");
for (i = 0; i < size; ++i)
printf ("%i ", list[i]);
return self; // Always return self
// if nothing else makes sense.
}
- resetSize
{
size = 0;
return self;
}
------------------------------
List2.h, below, inherits from the above Lists. -doesNotRecognize is the standard method that gets called if a class does not have the required method. magicMethod in main.m does not exist so doesNotRecognize gets called. This allows for an easy way to create Delegatorpatterns or to use Proxy-setups.
------------List2.h-----------
#import <objc/Object.h>
#import "List.h"
@interface List2 : List // List2 is a subclass of List
- free;
- (int) sum;
- doesNotRecognize: msg;
@end
-------------------------------
------------List2m-------------
#import "List2.h"
#import "List.h"
@implementation List2 : List
- (int) sum
{
int i=0;
int sum=0;
for (i=0; i<size; i++)
sum+=list[i];
return sum;
}
-doesNotRecognize: msg
{
printf("no clue!\n");
return self;
}
----------------------------
-----------main.m-----------
import <objc/Object.h>
#import "List.h"
#import "List2.h"
main(int argc, char** argv, char** env)
{
int i;
id list, list2; // id is a general data type for objects.
list = [List new]; // create an instance of class List.
[list addEntry: 5]; // send a message to the object list
[list addEntry: 3];
[list print];
[list free]; // get rid of object
list2 = [List2 new];
[list2 addEntry: 6];
[list2 addEntry: 4];
printf("\nsum: %d\n",[list2 sum]);
[list2 magicMethod];
}
-----------------------
There are four major Objective-C compilers: Stepstone, GNU, Apple and Portable Object Compiler (POC). Stepstone and POC are preprocessors that emit vanilla C code. GNU and Apple are "native" compilers, creating intermediate code for the GNU code generator.
To compile the previous examples, enter:
gcc -Wno-import -c List.m gcc -Wno-import -c List2.m gcc -Wno-import -c main.m gcc -o List -Wno-import List2.o List.o main.o -lobjc -lpthread
Categories compartmentalize a class definition or extend an existing one, possibly at runtime. They denote a set of method definitions that is segregated from the rest of the class definition.
Protocols allow you to organize related methods into groups. Protocol hierarchy is unrelated to class hierarchy. They are used to declare methods that others are expected to implement, declare the interface to an object while concealing its class and capture the similarities among classes that are not hierarchically related.
Protocols address the lack of multiple inheritance. They are equivalent to multiple inheritance for purely "abstract" classes. The closest you can get to multiple inheritance is to create a class with instance variables that are references to other objects. Instances can specifically redirect messages to any combination of the objects of which they are compounded. The Objective-C philosophy is that you do not need multiple inheritance because it creates more problems than benefits. Using protocols, one can have type-checking features without sacrificing dynamic binding. "Any object implementing messages in Protocol X is okay for this use" constrains the functionality and not the implementation or the inheritance.
@protocol Archiving -read: (Stream *) stream; -write: (Stream *) stream; @end
and refer to it with:
/* MyClass inherits from Object and conforms to the Archiving protocol. */ @interface MyClass: Object <Archiving> @end
Example that spots incompatibility changes:
MyClass *obj1 = [MyClass new]; // OK: obj1 conforms to the Archiving protocol. id <Archiving> obj2 = obj1; // Error: obj1 does not conform to the TargetAction protocol. id <TargetAction> obj3 = obj1;
Starting with version 0.9.0, GNUstep's libFoundation comes with two garbage-collecting mechanisms that provide you with the ability to solve memory management problems. libFoundation is a library that provides an almost complete implementation of the OpenStep specification, plus many other extensions that can be found in the newer versions of Rhapsody's (Mac OS X) Foundation.
From Unit-testing Frameworks a là extreme programming (XP) to XML parsers, one can take advantage of a large existing codebase. And if all fails, one can take advantage of the entire existing C code-base, as the GNUstep XML parser has demonstrated. It is an Objective-C wrapper around libxml.
We think that Objective-C is the better C++, which is really worth giving a try. GNUstep is extremely powerful.
An extended comparison of all the compilers discussed in this article can be found on our home page.
developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/ObjC.pdf
Foundation Library, Objective C API
Object-Oriented Programming and the Objective-C Language
www.slip.net/~dekorte/Objective-C/Documentation/2_Comparisons/Comparisons.html
Articles on Objective-C by Brad Cox
Benchmarks for C++, Java and Objective-C by Sven Koehler
Object Oriented Programming in Objective-C
Objective C versus Smalltalk, C++ and Java
Compilers
Books
Object Oriented Programming: An Evolutionary Approach. Brad J. Cox, Andrew J. Novobilski. Addison-Wesley, 1991.
Objective-C: Object Oriented Programming Techniques. Lewis J. Pinson, Richard S. Wiener. Addison-Wesley, 1991.
An Introduction to Object-Oriented Programming. 3rd Edition. Timothy A. Budd. Addison-Wesley, 2002.
Developing Business Applications With Openstep. N. Gervae. Springer Verlag Telos, 1996.
Openstep for Enterprises. Nancy Craighill. John Wiley & Sons, 1996.
Learning Cocoa. Apple Computer Technical Writers. O'Reilly, 2001.
Armin Roehrl (armin@approximity.com) and Stefan Schmiedl (stefan@approximity.com) lead the software company Approximity that optimises big distributed webventures.
Special Magazine Offer -- 2 Free Trial Issues!
Receive 2 free trial issues of Linux Journal as well as instant online access to current and past issues. There's NO RISK and NO OBLIGATION to buy. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Sorry, offer available in the US only. International orders, click here.
Subscribe now!
The Latest
Featured Videos
Linux Journal Live - Oct 9, 2008
October 9th, 2008 by Shawn Powers
The October 9, 2008 edition of Linux Journal Live! Associate Editor, Shawn Powers, and Kyle Rankin, "Hack and /" columnist and author of Knoppix Hacks, Linux Multimedia Hacks, Knoppix Pocket Reference and others, discuss Linux distributions.
Linux Journal Live - Oct 2, 2008
October 3rd, 2008 by Shawn Powers
The October 2, 2008 edition of Linux Journal Live! Associate Editor, Shawn Powers, and Steven Evatt, Online Development manager for The Houston Chronicle discuss surviving disaster with Linux.
Recently Popular
From the Magazine
November 2008, #175
There aren't many numbers that put the US national debt to shame, but here's one: 1,100,000,000,000,000. What's that? That's how many floating-point operations per second the Roadrunner supercomputer at Las Alamos can perform. That's about 100 FLOPS per dollar of US debt (unfortunately, the debt is winning the second derivative race). Read the article about Roadrunner in this month's High Performance Computing issue of LJ.
Along with that, find out how to program the Cell processor and how to use CUDA with your NVIDIA GPU. Also in this issue: Mr HandS (aka Kyle Rankin) gives us a few tips on using Compiz, Chef Marcel shows you how to get blogging off your plate quicker, Mick Bauer talks about Samba security, Dan Sawyer interviews Cory Doctrow and Doc talks about how information technology can affect democracy and fix the national debt (just kidding about that last part). That and more for your reading pleasure in this month's Linux Journal.
Delicious
Digg
Reddit
Newsvine
Technorati








window maker is NOT a GNUstep application.
On May 3rd, 2004 Anonymous says:
Since [ ... ] the fact that GNUstep is delivering the rock-solid window-manager Window Maker, Objective-C is (rightly) getting more attention
window maker has nothing to do with GNUstep except the looks and it being the only window manager that works well with GNUstep currently. hopefully it will soon be replaced by a real GNUstep window manager
Re: Objective-C: the More Flexible C++
On February 15th, 2003 Anonymous says:
What is this "she" crap all about? Can we please stick to programming and not social agendas? We just want to program.
Appreciated the info about Objective-C by the way.
What is this "What is this 'she' crap" crap all about?
On March 4th, 2004 Anonymous says:
Get a life and stop whining / nitpicking about small things like this.
Re: What is this
On June 2nd, 2004 Anonymous says:
He wouldn't have nitpicked about it if the author hadn't.
That's backwards. Having to
On January 6th, 2005 Anonymous (not verified) says:
That's backwards. Having to bend over backwards to say "he/she" every time is more nit-picky than just picking a pronoun and using it.
What possible "social agenda" does one promote by using "she"? (I guess if you're living in the 1950's, the idea that women are doing something outside of the kitchen is pretty radical, but we haven't been living in the 1950's for a couple years now.)
Re: Objective-C: the More Flexible C++
On September 12th, 2003 Anonymous says:
I don't think the author's choice of words took away from the article, but this comment does! If it wasn't for mine and your post all comments would have been about programming. I guess you got to follow your own "social agenda" huh?
Re: Objective-C: the More Flexible C++
On September 23rd, 2002 Anonymous says:
as close to Smalltalk as a compiled language can be.
Uh, Smalltalk is a compiled language. So the closest thing to Smalltalk that is a compiled language is Smalltalk itself!
Re: Objective-C: the More Flexible C++
On March 4th, 2004 Anonymous says:
Uh... check your facts again. Smalltalk is interpreted.
Languages are neither. Imple
On January 6th, 2005 Anonymous (not verified) says:
Languages are neither. Implementations are.
FWIW, most implementations are compiled (to bytecodes).
Re: Objective-C: the More Flexible C++
On September 20th, 2002 Anonymous says:
> some famous games including Quake and NuclearStrike
> were developed using Objective-C.
Quake was not written in Objective-C. Anyone can verify this in two minutes by downloading the source code from Quake.com. Carmack did write a level editor called QuakeEd in Objective-C, but the game itself was not. Please update the article to avoid misleading people into thinking that Carmack would write a game in Objective-C.
> Objective-C is (rightly) getting more attention because
> it is more flexible than C++ at the cost of being slower.
Most of the Objective-C constructs can be implemented in C++ without much difficulty, but the inverse is not true. C++ is more flexible, end of discussion.
> Compile-time and link-time constraints are limiting because
> they force issues to be decided from information found in
> the programmer's source code, rather than from information
> obtained by the running program.
Wrong. See any major API written in C. Let us take Win32 as an example. It is written in C, a statically-typed language, yet I can superclass windows as I please while the API DLL's are running. That is not so odd once you consider that dynamically-typed langauges are implemented using statically-typed languages. Your own explanation of the C underpinnings of Objective-C features confirms my point.
Re: Objective-C: the More Flexible C++
On April 21st, 2003 Anonymous says:
Most of the Objective-C constructs can be implemented in C++ without much difficulty, but the inverse is not true. C++ is more flexible, end of discussion.But C++ is ugly as ***** and confusing as hell. Objective-C is neither of these things. And you will never find a better set of frameworks than OpenStep.
Re: Objective-C: the More Flexible C++
On September 21st, 2002 Anonymous says:
> Most of the Objective-C constructs can be implemented in C++ without
> much difficulty, but the inverse is not true. C++ is more flexible, end
> of discussion.
By this "logic", assembly is the most flexible language.
Re: Objective-C: the More Flexible C++
On September 21st, 2002 Anonymous says:
> By this "logic", assembly is the most flexible language.
No.
Most of Objective-C's "dynamic typing" features hinge around being able to pass messages around via a very simple run-time system. This system can be easily and cleanly wrapped into C++ code that greatly resembles the Objective-C constructs in simplicity and usefulness.
You cannot draw the same comparison between C and C++, between Objective-C and C++, or even between assembly and most other languages. Hence, C++ is more flexible than Objective-C.
Re: All right, I'm curious...
On September 22nd, 2002 Anonymous says:
Would you please give us some examples... I guess they would come up pretty ugly if you truly want to "emulate" Obj-C messages in C++..
How about protocols and "protocols-inheritance"?
If anyone is able to do it cleanly in C++ I would be _extremely_ surprised... so, surprise us!
C++ is more "flexible" when you make C++-oriented programs: Obj-C is different and it does not need much of C++ features (some are nice, I admit, you can use Obj-C++ for them)... If you compare the runtimes Obj-C is a lot more flexible than C++!
Re: All right, I'm curious...
On September 23rd, 2002 Anonymous says:
*yawn* It sure is late! I have already implemented the message inheritance thingamajig already without much trouble, but I will post it sometime tomorrow once I have had a chance to clean up the development cruft.
Here is an example of dynamic dispatch...
On September 24th, 2002 Anonymous says:
// This is the class that makes it all possible:
class id
{
int t;
public:
id (int type) : t (type) {}
virtual id* dispatch (int action)
{
return on_unknown (action);
}
virtual id* on_unknown (int action)
{
throw exceptional::runtime_error ("object does not support this action");
}
int type () const { return t; }
};
// Here we have defined some objects and actions for convenience:
namespace objects {
enum {
nil,
example1,
example2
};
}
namespace actions {
enum {
foo,
bar
};
}
// And here are two example classes:
class example1
: public id
{
typedef id base;
public:
example1 () : base (objects::example1) {}
id* dispatch (int action)
{
switch (action)
{
case actions::foo: return on_foo ();
case actions::bar: return on_bar ();
default: return base::dispatch (action);
}
}
id* on_foo () { cout dispatch (actions::foo);
p->dispatch (actions::bar);
p->dispatch (392075);
}
// And our test main function - play around with it a bit!
int main ()
{
try
{
id* p1 = new example1;
id* p2 = new example2;
dispatch_foo_and_bar (p1);
dispatch_foo_and_bar (p2);
}
catch (runtime_error& e)
{
cout << "runtime error: " << e.what () << endl;
}
}
The basic idea is that we have swapped a whole mess of virtual functions for one virtual function, an integer and a switch statement. When a virtual function is called, the most derived class's dispatch function is called. The class attempts to handle the message, but if it cannot, it invokes its base class's dispatch function with the same action parameter. If the base class cannot handle the action, then it invokes *its* base class's dispatch function.
This process continues until either some base class handles the action or it reaches the root class. Naturally the root class, id, is not designed to handle any actions by itself, so it just throws a runtime error.
Re: Here is an example of dynamic dispatch...
On September 24th, 2002 Anonymous says:
Argh! the script ate my example classes and function. :-P
If you cannot guess the code in on_foo etc., please send an email to null_pointer_us AT yahoo DOT com and I will send you a text file attachment containing the code. I would post it on a public server, but unfortunately I do not have any.
Re: Objective-C: the More Flexible C++
On September 18th, 2002 dankelley (not verified) says:
Some thoughts from a scientist who also dabbles in software creation:
my 2 cents Canadian (not much in othe terms, lately) worth...
Some years ago, I wrote a pretty large (10^4 lines) open-source code
in C. It became apparent that it would help for this code to have
parts that were more object-oriented, and so I read a bit and decided
to convert those parts.
During this work, I learned that objC is quite beautiful. By that, I
mean that the code, and the logic it inspired, was elegant to the eye,
in the way that some mathematics proofs can be.
But one day I realized that none of the folks using this code knew
objective-C, whereas many of them knew C++. Since this was a shared
program, I wanted my users to be able to contribute to the work. And
so I started the process of converting the objective-C into C++. That
was not much fun, partly because the syntax is different and partly
because C++ seems not to inspire the writing of elegant code (or,
better stated, it seems not to inspire the construction of elegant
algorithms).
Why is this, exactly? I'm not sure. At first I thought my distaste
for C++ might be just a love of the old. But, now I've been using C++
for years, and I can read/write it much more easily than objective-C,
and I still feel the same way.
In summary, the advantage of objective-C seems to be that it inspires
an elegance of expression. The disadvantage is that fewer people can
read your code.
Of course, all of this may be moot, since it's my
understanding that many students are learning Java before they learn
any of the C dialects. Maybe I'm getting too old to keep up ... I
just get used to Perl and Python comes along like a knight in shining
armor, and before I learn it, I hear that now Ruby rules!
Dan.
Re: Objective-C: the More Flexible C++
On September 19th, 2002 Anonymous says:
You're right. Obj-C done right is MUCH more elegant than anything else.
Of course, you have to get into the "mood" to do it right. Just applying the "old habits" (C++ etc.) won't work.
Where Objective-C shines is that it leads to truly reusable code. Just comparing the number of classes in a typical C++ library and within Objective-C shows that.
This is not surprising at all: most C++ or Java windowing libraries (like PowerPlant on Mac, MFC on Windows) are anyway just bad copies of the NextStep classes. Their quality only differs how much thought they put into the classes to reassemble the functionality of Objective-C in the choosen language.
so - why not choose the original first?
Learning the syntax is something like 2 days for a C programmer. The tough part is getting the own classes right. But once its understood, there is nothing like it anywhere.
I've written for 10 years in C and C++ and it was always messy and at the end no fun at all. After switching to Obj-C the only thing I regret is not buying a NextStep Station in the 90ies...
Michael
Objective-C---more than just games
On September 18th, 2002 WillAdams (not verified) says:
Macromedia FreeHand (v4) started as Altsys Virtuoso on NeXTstep.
Improv--Although there was an Improv 2 for Windows, it was never quite as nice
as Improv for NeXTstep (which also fell far short of where it ought to've
been), but there's still no widely available spreadsheet available now which
handles 3D data so elegantly AFAIK.
Then, one could compare the programs which are all but without peer, for
example TIFFany (PhotoShop on steroids), or PasteUp.app (developed almost
single-handedly by Glenn Reid in roughly a year). Or, MCI's Friends and Family
database system (they liked it so much, they bought the company!)
NeXTstep is also the premiere platform for using PostScript directly and
interactively---Alan Hoenig praises it in his book _TeX Unbound_
SoftMagic, www.softmagic.co.kr is an incredible product.
And of course, there's WebObjects....
Lastly, Tim Berners-Lee used NeXTstep (he crafted a thing called worldwideweb.app---guess what it
grew into)
William
Re: Objective-C: the More Flexible C++
On September 17th, 2002 Anonymous says:
Hey, you cannot blame C++ for introducing new keywords and propose a language that overloads every special character on the planet :)
I dont want to say that Objective C is bad or something. But don't try to make a thing better by complaining about another thing.
Beside that, C++ is not only "C with Objects". It has many other useful features, like templates or references. Maybe it would be a good idea to think about mixing C++ and Objective C, creating a "Objective C++" that combines Objective C's runtime system with all the C++ features (and the more popular syntax of C++). As you can see, I am not a proponent of the 'make a language as simple as possible' school, but I rather prefer the 'add every single feature that can not be implemented in a lib, because every feature helps the programmer who works 100h a week in the damn language' school...
Re: Objective-C: the More Flexible C++
On September 18th, 2002 Anonymous says:
Objective-C++ already exists! NeXT extended Objective-C in this way to leverage C++ into NeXTSTEP applications (if the solution already exists in C++ why not use that). It turns out that Objective-C++ is probably only useful for that purpose, the features in C++ have a heavy cost in readability and ease of use, so Objective-C++ isn't used much. Objective-C turns out to prove that K&R were right to keep C a small language. :-)
Re: Objective-C: the More Flexible C++
On September 17th, 2002 Anonymous says:
As you can see, I am not a proponent of the 'make a language as simple as possible' school, but I rather prefer the 'add every single feature that can not be implemented in a lib, because every feature helps the programmer who works 100h a week in the damn language' school...
And it is thinking like that to cause C++ compilers to never be able to totally implement the C++ language specifications. The compiler makers have a hard time trying to implement these "features". I always get frustrated to write a program using valid C++ and it compiles and runs fine on one platform and try to compile it on another(VC++) and have either totally rewrite that part of code or do some conditional compilation that makes the code hard to read. I like C++ and wish a few of the very useful features like namespaces would be added to Objective-C. I am totally against templates being added since it is against the philosphy of a dynamic OO language.
A simpler language allows you to move on and start writing code to do some work. I was able to learn Objective-C in a few days and I understand the entire language. I been programming in C++ for 5 years and I still do not know the language.
Re: Objective-C: the More Flexible C++
On September 17th, 2002 Anonymous says:
Objective C++ already "exists"...
Re: Objective-C: the More Flexible C++
On September 16th, 2002 Anonymous says:
And this does not look like C.
No wonder people adopt C++ instead of Objective-C.
Re: Objective-C: the More Flexible C++
On September 17th, 2002 Anonymous says:
In my opinion, part of C++'s problem is that it looks TOO MUCH like C. This, I think, encourages confusion among beginners and the tendency to write C code, not OO code, with C++.
IMHO, a method call is inherently different from a function call - especially in a dynamic system like ObjC, and should have its own notation distinct from that of a function call.
Likewise, an object is inherently different from a structure, and the notation should be different. Etc.
I much prefer ObjC's [foo bar:1 with:me];
syntax, because it is quite clear that this is an OO construct, and different from all the C code that might surround it.
Re: Objective-C is definitely superior to C++
On September 17th, 2002 Anonymous says:
I totally agree with you...
Who does not agree with the title either does not know the language or is a moron (no pun intended)
On the other hand, I believe Objective-C lacks a couple of important features that C++ has (namespaces and templates among them), but I found that it is still an excellent language even without those...
P.S.
You can always mix both languages with Objective-C++
Once I read an article by Tim Sweeney (creator of UT) where he analysed programming languages (or something like that)... he stated that in the future, languages will have features to make class hierarchies "extensible" (I can't remember the exact words)... Obj-C is already capable to do that and with trivial effort (and dynamically: you can "override" any class you find with your own version)
Re: Objective-C: the More Flexible C++
On September 16th, 2002 Anonymous says:
why don't your use [[List alloc] init] to create an object? You used [List new]. But you said:
Usually, you create objects with a call to alloc:
Very confusing.
Re: Objective-C: the More Flexible C++
On September 18th, 2002 Anonymous says:
new is a short cut.
[Object new]
is equivalent to
[[Object alloc] init]
Re: Objective-C: the More Flexible C++
On September 17th, 2002 Anonymous says:
new is just a "shorthand" method used in GNUStep:
- (id) new
{
return [[self alloc] init];
}
Method new might not actually be (not sure) the one above but surely it does the same as above (conceptually)
Post new comment