summers@acsu.buffalo.edu (Michael Summers) (02/18/91)
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? As I understand it Stepstone does not support an interpretive environment for the current version of the language. Is there any product comparable to Saber-C++ available for Objective C? Any information will be greatly appreciated. Thanks
carroll@cis.udel.edu (Mark Carroll) (02/19/91)
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! ----------------------
carroll@cis.udel.edu (Mark Carroll) (02/20/91)
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! ----------------------
dxb@genrad.com (Daniel A. Burkhard) (02/21/91)
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 ------------------------------------------------------------------------------
dxb@genrad.com (Daniel A. Burkhard) (02/22/91)
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 ------------------------------------------------------------------------------
tomnews%apgraph@ap542.UUCP (Thomas Oeser (SNI AP 153)) (02/22/91)
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 -------------------------------------------------------------------------
pfkeb@ebnextk.SLAC.Stanford.EDU (Paul Kunz) (02/23/91)
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.
jimad@microsoft.UUCP (Jim ADCOCK) (02/26/91)
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.