home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!casey!gaboon!seltd!lerman
- From: lerman@seltd.UUCP (Kenneth Lerman)
- Newsgroups: comp.lang.objective-c
- Subject: Re: Objective-C vs. C++
- Message-ID: <20@seltd.UUCP>
- Date: 29 Aug 92 14:42:36 GMT
- References: <rmartin.714926059@thor> <1992Aug28.182704.10020@cs.mcgill.ca>
- Reply-To: lerman@seltd.UUCP (Kenneth Lerman)
- Organization: Systems Essentials Limited
- Lines: 43
-
- In article <1992Aug28.182704.10020@cs.mcgill.ca> samurai@uriel.cs.mgill.ca writes:
- ...referring to type checking...
- >Isn't ANSI C pretty strong about this? I know gcc2.2.2 drives me
- >WILD with warnings :-). And Objective C (well, NeXT's anyway)
- >is ANSI.
- ...
-
- Recall that Stepstone's compiler is a precompiler which generates C
- code as output.
-
- Stepstone's Objective-C compiler accepts ANSI C and generates ANSI or
- K&R variants depending on whether it is used with ANSI or K&R
- compilers. It will do type checking of messages to objects whose
- types are statically defined, e.g.:
-
- Foo *aFoo;
- ...
- [aFoo blech];
-
- will verify that objects of type Foo respond to the blech message. A
- diagnostic will be generated if it does not.
-
- One objection to runtime dispatching of messages which is often made
- by the C++ advocates is that you may get "doesNotRecognize" errors
- during runtime if your code is not statically checked by the compiler.
- My answer to this is:
- You mean you don't test your code?
-
- It has been my experience that doesNotRecognize errors are generally
- easy to find and fix.
-
- That is in contrast to the correction of memory leaks and messages to
- freed objects. The former is easy to detect and often very hard to
- understand and fix. The latter is usually easily detected by the
- Objective-C runtime, but is sometimes very hard to detect and may take
- days to understand and fix.
-
-
- --
- Kenneth Lerman ...!uunet!casey!gaboon!seltd!lerman
- Systems Essentials Limited (203)426-4430
- 55 Main Street
- Newtown, CT 06470
-