🚀 go-pugleaf

In article <60377@eerie.acsu.Buffalo.EDU> summers@acsu.buffalo.edu (Michael Summers) writes:
>Why would I want to use Objective C ? Can any one give me a
>short description of the pros and cons of the two
>languages?
>
>There is a lot of support for C++ in terms of PD software
>and vendors but hardly any for Objective C. Perhaps this
>will change when the new g++ come out. This lack of broad
>support is a definite limitation to Objective C whatever its
>attributes. What is so superior about Objective C that would
>induce me to abandon this support?
>

Contrasting Objective-C and C++ in this way doesn't make sense. Obj-C
and C++ are designed for very different purposes. The languages should
not be competing.

C++ is a systems language. It's very low level, very fast, etc. It's 
optimized towards very low level programming. It's not very good
at abstraction. It's completely impossible to implement a class in
a way where a user cannot change the private parts of the class, or
alter the class declaration. C++ is almost completely statically bound;
dynamic binding only comes into play when you start using virtual
function, and only functions tagged virtual can be rewritten in your
subclasses.

Objective-C is an applications language. It's higher level than C++. It's
not quite as fast, but in exchange for the (minor) loss in speed, you gain
a much more dynamic language. All object method calls are dynamically
bound, unless specifically forced to be static. (Sort of the opposite of
C++. C++ is static unless forced dynamic; Obj-C is dynamic unless forced
static.) All member functions can be reimplemented in subclasses. Also, in
C++, it is possible to distribute object-code for classes, without the
corresponding source. You can present objects which the user can make
full use of, but cannot alter without implementing a subclass. The private
parts of one of these classes can NEVER be changed by their users.

In summary: Objective-C is NOT superiour to C++; C++ is NOT superior to 
Objective-C. They are different languages with completely different aims.

	<MC>

-- 
---------------------- Mark Craig Carroll:  <MC> ------------------------
------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------
-- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu --
---------------------- Shalom Achshav - Peace NOW! ----------------------

In article <44957@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:

> ... stuff deleted

> C++ is a systems language. It's very low level, very fast, etc. It's 
> optimized towards very low level programming. It's not very good
> at abstraction. It's completely impossible to implement a class in
> a way where a user cannot change the private parts of the class, or
> alter the class declaration. ............

How so ?? C++ gives you member access control private (default), public, and
protected. A user has no direct access to private members, i.e private
members can only be changed thru the public interface of a class.
[ Of course these rules can always be violated in any language that supports
  access to raw memory ...]

> C++ is almost completely statically bound;
> dynamic binding only comes into play when you start using virtual
> function, and only functions tagged virtual can be rewritten in your
> subclasses.

I'm not exactely sure what you mean by "rewritten", but of course something like

class foo
    {
	int a;
    public:
	foo(int aa=1)	{ a = aa;}
	int geta()	{ return a;}
    };

class bar: public foo
    {
	int b;
    public:
	bar(int bb=2)	{ b =bb; }
	int geta()	{ return b;}
    };

is perfectly legal in C++ [note: no "virtual" here].

> .. stuff deleted
> ..................... Also, in
> C++, it is possible to distribute object-code for classes, without the
> corresponding source. You can present objects which the user can make
> full use of, but cannot alter without implementing a subclass. The private
> parts of one of these classes can NEVER be changed by their users.

This seems to be a contradiction to your first point.

-- dan

-------------------------------------------------------------------------------
Dan A. Burkhard				Internet:	dxb@genrad.com
GenRad, Inc				UUCP:		...!genrad!animal!dxb
300 Baker Ave				Phone:		(508) 369-4400 X3304
Concord, MA 01742		
------------------------------------------------------------------------------

In article <40804@genrad.UUCP> dxb@genrad.com (Daniel A. Burkhard) writes:
>In article <44957@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:
]
]] ... stuff deleted
]
]] C++ is a systems language. It's very low level, very fast, etc. It's 
]] optimized towards very low level programming. It's not very good
]] at abstraction. It's completely impossible to implement a class in
]] a way where a user cannot change the private parts of the class, or
]] alter the class declaration. ............
]
]How so ?? C++ gives you member access control private (default), public, and
]protected. A user has no direct access to private members, i.e private
]members can only be changed thru the public interface of a class.
][ Of course these rules can always be violated in any language that supports
]  access to raw memory ...]
]

I'm not talking about during execution; what I mean is that the .h
file declaring the class MUST be accessible to and alterable by the
user. A user can muck about inside of the declarations of any class
which he is permitted to use. In Objective-C, that can be prevented.
(The private declarations are not necessary to use a class.)

]] C++ is almost completely statically bound;
]] dynamic binding only comes into play when you start using virtual
]] function, and only functions tagged virtual can be rewritten in your
]] subclasses.
]
]I'm not exactely sure what you mean by "rewritten", but of course something 
]like
]
]class foo
]    {
]	int a;
]    public:
]	foo(int aa=1)	{ a = aa;}
]	int geta()	{ return a;}
]    };
]
]class bar: public foo
]    {
]	int b;
]    public:
]	bar(int bb=2)	{ b =bb; }
]	int geta()	{ return b;}
]    };
]
]is perfectly legal in C++ [note: no "virtual" here].
]


True. But if I pass an instance of class bar to a function expecting an
instance of class foo, and inside the function, I call the geta(), I'll
get foo's geta(), not bar's. If the only OO background you have is C++,
you'll just say, "Oh. But that's where you use virtual functions". But 
in "traditional" object-oriented design, ALL functions are "virtual". I
should be able to reimplement ANY function in a subclass, and have it
always get called correctly, whether the original author thought that I'd
want to or not.

C++ makes the assumption that the original author is fully aware of
EVERYTHING that the users of a class might want to do with it in
the future; that's an acceptable assumption, since it's so easy to
go in, and change the class declarations if he was wrong. In Objective-C,
no such assumption is made, and it is not necessary to ever alter the
class declarations in order to be able to make use of the class.

]] .. stuff deleted
]] ..................... Also, in
]] C++, it is possible to distribute object-code for classes, without the
]] corresponding source. You can present objects which the user can make
]] full use of, but cannot alter without implementing a subclass. The private
]] parts of one of these classes can NEVER be changed by their users.
]
]This seems to be a contradiction to your first point.

Sorry. Typo. ^C++^Objective-C.

]-- dan

	<MC>
-- 
---------------------- Mark Craig Carroll:  <MC> ------------------------
------ U of Del. Grad Student in CIS ------ EE/CIS LabStaff Hacker ------
-- Resident Wierdo @ 105 E Cleveland Ave, Newark DE - carroll@udel.edu --
---------------------- Shalom Achshav - Peace NOW! ----------------------

In article <45238@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:
] In article <40804@genrad.UUCP> dxb@genrad.com (Daniel A. Burkhard) writes:
] ]In article <44957@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:
] ]
> ]] ... stuff deleted
] ]
] ]] at abstraction. It's completely impossible to implement a class in
] ]] a way where a user cannot change the private parts of the class, or
] ]] alter the class declaration. ............
] ]
] ]How so ?? C++ gives you member access control private (default), public, and
] ]protected. A user has no direct access to private members, i.e private
] ].....
] 
] I'm not talking about during execution; what I mean is that the .h
] file declaring the class MUST be accessible to and alterable by the
] user. A user can muck about inside of the declarations of any class
] which he is permitted to use. In Objective-C, that can be prevented.
] (The private declarations are not necessary to use a class.)

Accessible yes. I assume you think that .h files must be alterable for
reasons you list below --

] 
] ]] C++ is almost completely statically bound;
] ]] dynamic binding only comes into play when you start using virtual
] ]] function, and only functions tagged virtual can be rewritten in your
] ]] subclasses.
] ]
] ]I'm not exactly sure what you mean by "rewritten", but of course something 
] ]like
] ]....[some example redefining some method]
] ]is perfectly legal in C++ [note: no "virtual" here].
] ]
] 
] 
] True. But if I pass an instance of class bar to a function expecting an
] instance of class foo, and inside the function, I call the geta(), I'll
] get foo's geta(), not bar's. If the only OO background you have is C++,
] you'll just say, "Oh. But that's where you use virtual functions". But 
] in "traditional" object-oriented design, ALL functions are "virtual". I
] should be able to reimplement ANY function in a subclass, and have it
] always get called correctly, whether the original author thought that I'd
] want to or not.
] 
] C++ makes the assumption that the original author is fully aware of
] EVERYTHING that the users of a class might want to do with it in
] the future; that's an acceptable assumption, since it's so easy to
] go in, and change the class declarations if he was wrong. In Objective-C,
] no such assumption is made, and it is not necessary to ever alter the
] class declarations in order to be able to make use of the class.

You give the impression that all you had to do is change the .h-file, but
just changing class declarations is not sufficient (is that why you claim that you
need alterable .h files ?) -- you will most likely need to recompile implementations
also; this may be unacceptable in some situations.

The whole issue on whether or not the default for member functions should
be virtual has been discussed to some length in comp.lang.c++. I don't intend
to repeat these arguments here.

This really is not a language issue. The issue is whether or not you believe
that member functions should be virtual; so now it becomes a criteria when
you select components for reuse. Other people may be more concerned with performance,
therefore may have a different set of criteria. But given the code you reuse
satisfies your criteria, you will not need to alter anything. Again, not a language
but an implementation issue.

--dan

-------------------------------------------------------------------------------
Dan A. Burkhard				Internet:	dxb@genrad.com
GenRad, Inc				UUCP:		...!genrad!animal!dxb
300 Baker Ave				Phone:		(508) 369-4400 X3304
Concord, MA 01742		
------------------------------------------------------------------------------

In article <60377@eerie.acsu.Buffalo.EDU>, summers@acsu.buffalo.edu (Michael Summers) writes:
|> Why would I want to use Objective C ? Can any one give me a
|> short description of the pros and cons of the two
|> languages?
|> 
|> There is a lot of support for C++ in terms of PD software
|> and vendors but hardly any for Objective C.

Things seem to change as I read an announcement of IBM in the Feb 91 version of the UNIX magazine:
"Objective-C instead of C++". They are supporting Objective-C on their IBM RISC System/6000
Technology.

In addition, we should also consider all the owners of NeXT machines. Although they have the choice
between C++ and Objective-C, the greater support for a user interface (NextStep) is provided only
for Objective-C.

|> What is so superior about Objective C that would
|> induce me to abandon this support?

You can handle real Objects (in the sense of Smalltalk). E.g. you can write a container (e.g. a
array) that can contain **any** object **and** that provides functionality like "send a message
to each object contained on behalf of a user.

Thomas Oeser


****** DISCLAIMER: All opinions stated here are strictly my own *********
-------------------------------------------------------------------------
Internet:	thomas%apgraph%ap542@ztivax.siemens.com
Europe:		thomas%apgraph@ap542.UUCP
Phone:		+ 49 89 636 47537
Fax:		+ 49 89 636 45522
Postal Mail:	Siemens Nixdorf Information Systems AG, AP 153,
                Carl-Wery-Str. 22, D-8000 Munich 83, West Germany
-------------------------------------------------------------------------

   The owners of NeXT machines don't have  any choice if programming for
the Graphical User Interface kit of objects.   It is Objective-C, period.

   However, for Classes that don't need the GUI, we also have C++ on 
every machine that has the compiler.   In fact, we have Objective-C++ in
that our code that seems to be Objective-C can message  C++ classes.
That is, from Objective-C code we  can issue function calls to 
C++ classes, thus I call the new NeXT compiler an Objective-C++ compiler.

   Brad Cox, of Objective-C fame, visited me about a year ago.    At the
lunch we had together, we talked about the differences between C++ and
Objective-C.   After lunch, I concluded and said to Brad that what the
world needed is Objective-C++.  Today we have it. 

   Since the NeXT compiler is based on GNU software, NeXT must submit its 
modifications to GNU.  The next release of gcc, as I understand it, will
contain NeXT's modifications to make it an Objective-C compiler.  I can
only assume that the release after that will make gcc a Objective-C++
compiler.

In article <60377@eerie.acsu.Buffalo.EDU> summers@acsu.buffalo.edu (Michael Summers) writes:
|Why would I want to use Objective C ? Can any one give me a
|short description of the pros and cons of the two
|languages?

Please follow up to comp.object, or to the original author directly.

Long-time readers of comp.lang.c++ / comp.lang.objective-c can
remember a dozen times already where this comparison has degenerated
into notes wars.  Therefore, we ask that language comparisons take 
place in a neutral forum such as comp.object.  Please leave comp.lang.c++
open to answer the questions of C++ users.  Please leave comp.lang.objective-c
open to answer the questions of Objective-C users.

Comp.object is a more reasonable forum for comparing language features --
but even there, I suspect readers are beginning to tire of language
"comparisons."

Programmers can and do disagree what languages and language features best
meet their individual programming needs.  Programmers can and do disagree
on performance comparisons.  Caveat emptor.