lozinski@argon.uucp (Chris Lozinski) (08/02/90)
INTRODUCTION
After trying Basic, Fortran, Scheme, C, APL, and Objective-C, I
became firmly convinced that Objective-C was the best language
choice for the manufacturing applications that I work with. Then
when C++ became a common language, I carefully researched the
language, read the manuals, talked to people and generally tried to
make a wise long term decision. This article summarizes the
reasons behind my growing conviction that Objective-C is a
preferable language to C++ for manufacturing application.
EVOLUTIONARY DIFFERENCES
Objective-C has evolved from Smalltalk where the emphasis is on
programmer productivity. C++ has evolved from C where the emphasis
is on speed and memory requirements. With the falling prices of
workstations, and rising costs of software development, the
tradeoffs need to be carefully considered. I.M.H.O. Objective-C is
the better choice in manufacturing applications.
ORGANIZATIONAL DIFFERENCES
C++ is the computer scientists language where the focus is on
technical aspects of the language. Objective-C is the
businessman's language, where the emphasis is on organizing large
groups of people into cooperating communities assembling components
into final applications. Technically this is caused by the default
structures of the objective-C language where the target class of a
message does not need to be known at compile time. In contrast the
default in C++ is that the target class does need to be known at
compile time.
BUSINESS DIFFERENCES
Stepstone is tightly focussed on creating tools for software
developers. AT&T by contrast is not in the market of selling
software tools, and therefore cannot be expected to react as
quickly to market requirements.
TECHNICAL DIFFERENCES
1) The key feature that distinguishes Objective-C from C++ is
the maintenance of symbol tables. Here I must agree with jsweet of
Nasa. Objective-C allows the user to issue the following command
[anObject perform: "aMessage"];
or alternatively
aSelector = convertToSelector("aMessage");
[nObject perform aSelector];
This command means send the message "aMessage" to the object called
anObject. This ability is critical for simplifying interprocess
communication, either between objects on different operating
systems, or between a person and the computer. I highly recommend
that people take a close look at the design of the NextStep user
interface which profits from this approach. As for distributed
processing, time alone will demonstrate the power of this approach.
2) The key feature that distinguishes C++ from Objective-C is
operator overloading. This allows the user to deal with structures
such as vectors scalars and matrices in a very natural fashion.
float aScalar;
vector aVector;
matrix aMatrix, anotherMatrix;
aVector = aScalar * aVector;
anotherMatrix = aVector * aMatrix;
In manufacturing applications the more powerful Objective-C
messaging is more valuable to me than the operator overloading of
C++.
EASE OF USE
C++ supports and encourages the use of pointers to data
structures. The type of the data structure is known at run time.
Pointers, and dereferencing dominate the minds of the users and
invariably confuse the beginners. In contrast Objective-C supports
and encourages the use of sending messages to objects, and
historically discourages the manual navigation of pointers. My
experience has been that the concept of sending messages to objects
proves much easier to understand (and debug) than the whole issue
of navigating pointers and dereferencing locations.
DEVELOPMENT TIME.
Both of the people I have known who have extensive development
experience in both C++ and Objective-C claimed that software could
be developed in Objective-C faster. As a professional software
developer, my primary cost is software development time, so this is
a critical advantages.
PLENTIFUL TOOLS
There is a growing list of Objective-C tools. Here is my
current list.
StepStone Compiler
Stepstone Foundation Library
Stepstone User Interface Library
StepStone Browser
GNU debugger
GNU compiler
CNS Microsoft Windows Bindings.
CNS Browser for DOS
CNS Application code streamliner
CNS Objective-C make utility
NeXTStep libraries for NeXT and IBM machines.
GEMSTONE INTERFACE (rumored)
CONCLUSION
The choice of language is totally driven by the application's
needs. My area of expertise is distributed customized
manufacturing applications, where the emphasis is on speed of
development, a powerful user interface paradigm and flexibility of
the tools. For these needs Objective-C is wonderfully suited.
I highly recommend the language to everyone in this field.
NON-STANDARD DISCLAIMER
My enthusiasm for the language is so strong that I have chosen
to base my product on it. This makes me a biased observer.jbuck@galileo.berkeley.edu (Joe Buck) (08/03/90)
In article <26686@pasteur.Berkeley.EDU>, lozinski@argon.uucp (Chris Lozinski) writes: |> [ check out his article, I'm not going to quote it all here ] Chris, it may indeed be true that Objective-C is the best language for your problem. I'm puzzled by a lot of your assertions though. For example: |> C++ is the computer scientists language where the focus is on |> technical aspects of the language. I don't see how Objective-C is any less a "computer scientist's language". !> Objective-C is the |> businessman's language, where the emphasis is on organizing large |> groups of people into cooperating communities assembling components |> into final applications. Both languages have this goal. I can't say who does the better job. Technically this is caused by the default |> structures of the objective-C language where the target class of a |> message does not need to be known at compile time. In contrast the |> default in C++ is that the target class does need to be known at |> compile time. To override this default, you simply specify one additional word in one place -- you insert the keyword "virtual" at the base of your class hierarchy. Voila -- the target class does not need to be known at compile time. |> Stepstone is tightly focussed on creating tools for software |> developers. AT&T by contrast is not in the market of selling |> software tools, and therefore cannot be expected to react as |> quickly to market requirements. C++ has an official standards body now, which is independent of AT&T. The users of the language will make sure it meets their requirements. Similarly, as Objective-C increases in popularity, Stepstone will lose control of their language as well. I don't see how your speculations on the competence of the two companies matter, except to the extent that Objective-C users are currently more dependent on StepStone than C++ users are on AT&T (this will change in the future). |> 1) The key feature that distinguishes Objective-C from C++ is |> the maintenance of symbol tables. Here I must agree with jsweet of |> Nasa. Objective-C allows the user to issue the following command |> |> [anObject perform: "aMessage"]; |> or alternatively |> |> aSelector = convertToSelector("aMessage"); |> [nObject perform aSelector]; This is a big advantage for Objective-C in some applications. Still, similar capabilities can be provided in a C++ program; I've done it, in a digital signal processing simulation environment. It would have been nice if I could have just used the built-in facilities of the language, but then my digital signal processing would run substantially slower because I'd get this symbol table overhead even when I don't want it. It's a tradeoff; for particular problems in business as well as science, different languages may have an advantage. I'll accept your judgment that Objective-C works better for you in your particular application. But all "business applications"? I doubt it. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
muller@src.umd.edu (Christophe Muller) (08/03/90)
In article <26686@pasteur.Berkeley.EDU> lozinski@argon.uucp (Chris Lozinski) writes: > From: lozinski@argon.uucp (Chris Lozinski) > Newsgroups: comp.object,comp.lang.c++ > Date: 2 Aug 90 16:01:03 GMT > INTRODUCTION > After trying Basic, Fortran, Scheme, C, APL, and Objective-C, I > became firmly convinced that Objective-C was the best language > choice for the manufacturing applications that I work with. Then > when C++ became a common language, I carefully researched the > language, read the manuals, talked to people and generally tried to > make a wise long term decision. This article summarizes the > reasons behind my growing conviction that Objective-C is a > preferable language to C++ for manufacturing application. > [...Languages review deleted...] Thanks for this article. What about Eiffel ? Does anybody have an experience of projects with *both* Eiffel and Objective-C (or Eiffel and C++) ? and care to comment about it. Cheers, Christophe. = Got thirteen channels of shit on the T.V. to choose from ...to choose from =
lgm@cbnewsc.att.com (lawrence.g.mayka) (08/03/90)
In article <37938@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >In article <26686@pasteur.Berkeley.EDU>, lozinski@argon.uucp (Chris >Lozinski) writes: >!> Objective-C is the >|> businessman's language, where the emphasis is on organizing large >|> groups of people into cooperating communities assembling components >|> into final applications. > >Both languages have this goal. I can't say who does the better job. On page 4 of "The C++ Programming Language," by Bjarne Stroustrup: "C++ was primarily designed so that the author and his friends would not have to program in assembler, C, or various modern high-level languages. Its main purpose is to make writing good programs easier and more pleasant for the individual programmer." Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
shapiro@sor.inria.fr (Marc Shapiro) (08/03/90)
In article <MULLER.90Aug2161540@molecule.src.umd.edu>, muller@src.umd.edu (Christophe Muller) writes: |>What about Eiffel ? Does anybody have an experience of |> projects with *both* Eiffel and Objective-C (or Eiffel and C++) ? and care to |> comment about it. What about Modula-3 ? A friend who did a *very* large piece of operating system software in C++ (including handling device drivers, network protocols, virtual memory, and the like) tried to convince me that Modula-3 is better: much cleaner and just as powerful as C++. Does anybody have something to say about this? Marc Shapiro INRIA, B.P. 105, 78153 Rocquencourt Cedex, France. Tel.: +33 (1) 39-63-53-25; fax: +33 (1) 39-63-53-30; e-mail: shapiro@sor.inria.fr
cox@stpstn.UUCP (Brad Cox) (08/04/90)
In article <37938@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >In article <26686@pasteur.Berkeley.EDU>, lozinski@argon.uucp (Chris >|> C++ is the computer scientists language where the focus is on >|> technical aspects of the language. > >I don't see how Objective-C is any less a "computer scientist's language". Although I appreciate the attempt on both sides to clarify this cloudy issue, I cringe whenever Objective-C and C++ are compared as *languages*. My reason for building Objective-C was actually quite the opposite, in that I've always viewed the Objective-C front end as more philosophically aligned with yacc and lex (C attachments, rather than something that competes directly with C). Objective-C, the language, is the tiniest component of the much larger enterprise that has always been my main objective (if you doubt this, reread my book)...the Objective-C System-building Environment...a collection of ready-to-use commercially supported components (Software-ICs)_ and support tools such as browsers. Concentrating on the miniscule language component of the OC environment is like concentrating on the language component of Smalltalk...it misses the real significance of the two; as environments, not languages. >!> Objective-C is the >|> businessman's language, where the emphasis is on organizing large >|> groups of people into cooperating communities assembling components >|> into final applications. I suggest a different and possibly less pegorative slant on this issue, which is presented in my IEEE (Nov 1990) and Byte (Oct 1990) papers. Fabrik and Metaphor are *card* level OO technologies, Objective-C (and Smalltalk) are *chip* level OO technologies, and Ada and C++ are gate/block level OO technologies. Each of these operate at different levels, and therefore draw different congingencies in the same way that some people can barely plug cards into their Macs without getting electrocuted, whereas others have the skills and interests to work with chips to build cards, and even fewer to build chips from gates/blocks. >|> Stepstone is tightly focussed on creating tools for software >|> developers. AT&T by contrast is not in the market of selling >|> software tools, and therefore cannot be expected to react as >|> quickly to market requirements. > >C++ has an official standards body now, which is independent of AT&T. >The users of the language will make sure it meets their requirements. >Similarly, as Objective-C increases in popularity, Stepstone will lose >control of their language as well. I don't see how your speculations >on the competence of the two companies matter, except to the extent >that Objective-C users are currently more dependent on StepStone than >C++ users are on AT&T (this will change in the future). Although I don't quibble with your analysis, I quail everytime I hear that the software community has revved up another language standardization hoo ha. We have *got* to be the only group in the universe that standardizes our *processes* (languages, methodologies) but never gets around to standardizing the *products* of those processes (Stacks, Queues, etc). Its as if the hardware community standardized their wave solder machines expecting to avoid the need for standard bus structures. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
jimad@microsoft.UUCP (Jim ADCOCK) (08/07/90)
In article <26686@pasteur.Berkeley.EDU> lozinski@argon.UUCP (Chris Lozinski) writes: > > >INTRODUCTION > > After trying Basic, Fortran, Scheme, C, APL, and Objective-C, I >became firmly convinced that Objective-C was the best language >choice for the manufacturing applications that I work with. .... Once or twice a month, year after year, comparisons such as this show up in comp.lang.c++, or other language specific notes strings. This means that people who read comp.lang.c++ for some time have been exposed to tens, if not hundreds of such comparisons. Reading, and possibly responding, to such postings becomes tedious in the extreme. Further, in the past, such postings have resulted in unproductive notes wars, tying up notes bandwidth, and in some cases preventing some c++ notes users from being able to use comp.lang.c++ at all -- because everything they posted caused long-winded rebuttals from people in other language camps. I believe people who want to use c++ should have a forum for discussing c++, free from such hindrances, just as people using other languages [such as Ada] should be free to discuss their language free from hindrance. In order that people have a free forum for discussing their own favorite language, please post inter-language comparisons to neutral forums only. Please do not trash the note strings of other people's languages, lest they trash your language's notes strings.
tonyw@microsoft.UUCP (Tony WILLIAMS) (08/07/90)
This is just a comment, not a response or rebuttal. In article <26686@pasteur.Berkeley.EDU> lozinski@argon.UUCP (Chris Lozinski) writes: > >into final applications. Technically this is caused by the default >structures of the objective-C language where the target class of a >message does not need to be known at compile time. In contrast the >default in C++ is that the target class does need to be known at >compile time. > I am not sure what is meant by "default" here, but the last sentence above seems to be a common misconception. In C++, it is not necessary to know the class of the object whose member function is being invoked. It is necessary to know the (probably abstract) base class that introduces that member function. It is required that the class of the object be derived from the known base. This is not the same as saying the class of the object must be known. Tony
kearns@cs.columbia.edu (Steve Kearns) (08/07/90)
Brad Cox, paraphrased: > "dont worry so much about the language... environment is even more > important" In that case, why doesn't Stepstone produce software ICs for both Objective C and C++? -steve
jmd@swbatl.sbc.com (Jim Doherty 5-0804 11-Y-03) (08/07/90)
In article <5427@stpstn.UUCP> you write: >In article <37938@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >>In article <26686@pasteur.Berkeley.EDU>, lozinski@argon.uucp (Chris >>|> C++ is the computer scientists language where the focus is on >>|> technical aspects of the language. >> >>I don't see how Objective-C is any less a "computer scientist's language". > >Although I appreciate the attempt on both sides to clarify this cloudy >issue, I cringe whenever Objective-C and C++ are compared as *languages*. >My reason for building Objective-C was actually quite the opposite, in that >I've always viewed the Objective-C front end as more philosophically >aligned with yacc and lex (C attachments, rather than something that >competes directly with C). Since I have experience with both languages at a fairly detailed level (we have used both to drive switches) the real importance from our perspective is involved with how can we extend these languages to the next level of OOP. Today both languages do a good job of allowing you to send messages between objects in the same process space. However nether allows a messaging across process boundaries, yes I know this some may argue should not be part of the language, however since our goal is to create a commercial environment which allows both reusability and the capability to respond to market needs in a timely fashion we need to push the OOP paradigm across the entire environment. My work for the last three years has looked at this issues and we have come to some of the following conclusions. 1. OS changes are slow. 2. There is an extreme lack of software fault tolerance in the industry. 3. In order for large systems (ie switching) to be developed in a timely manner we need to build larger distributed systems. 4. The OOP paradigm provides the methodology to do this. We have recognized that the emergance of an OO Operating System will be some time in coming, (meaning commercial acceptance), in light of this we wanted to look at what capabilities are available today to do major distributed systems. (ie the telephone network is distributed) We then began looking at languages, ie (OOP) mainly for all the same reasons that many of you have are using languages. We came down to two languages Objective-C and c++. After doing some major implementations in both we have found they both hav there place and each does certain things extremely well. (we us both) I must tell you that our implementations of c++ tend to follow the smalltalk model rather closely. All objects in our systems inherit from an object called Adam (for biblical reasons). So when I discuss things later on keep this in mind. c++ because it could take liberty with the language itself, on aspect of c++ we have found extremely useful in certain aspects is that of operator overloading, a colleague of mine Stan Rishel has developed an OO interface to a relational data base that overloads the -> operator, this works quite naturally for the developer because the -> is what does the db call. Stan has also developed a scheme to store objects in the relational model which works quite naturally for us. (its real fast) Objective-C because it follows the smalltalk model of messaging is easily extendable across process spaces, for instance: when in OBJC you code [xxx xxx xx] this gets translated to a call to a routine called _msg(xxx xxx xx) this routine then looks in some hash tables to find the object and method you want to execute gets the addr of the function, then he removes the address of _msg from the stack and then begins execution of the desired code. Then when you return from the requested method you will return to the line just below the [xxx xxx xx]. Since Objective-C follow this model and provides you the source to the message kernel we made some modifications to the message kernel to add interprocess communications of objects. This we did without the knowledge of the developer. The basic methodology was as follows: 1. We let the message kernel determine if the method was internal to this process.(the normal mode) 2. if this failed (a normal runtime error) we intercepted the error and did a call to our external Object name server which all objects register with at initialization time. 3. we then returned the foreign address+site+incarnation as a handle to the requesting method, which now allowed the code in the original process to have a handle to t/w the other object. This is the handle method, which works quite well in medium to low traffic situations, and seems to be the only method to use when there is the possibility for updates. In read only type operations the copy method(ie you send a copy of the object) in a message to the requesting process space. The requesting proces space then can handle high volumes of traffic. 4. if this fails we then return the normal Objective-C runtime error with some additional information of ours. One item I have not mentioned yet is that in order to to accomplish the programs must be multi threaded, ie able to give up control in light of an external event (a message). to accomplish this we used a unique trick in the _msg code we also put in an accept_events() function call which in reality makes the program(object) multi threaded with out the programmer having knowledge of this. We also linked in a LWP lib (light weight process) in the linkage section. Now I hope this gives you some food for thought, because of the way Brad implemented Objective-C (i don't know if you thought of this at the time brad) adding interprocess communication can be done in a quite seamless manner. In c++ since messages do not flow through a common place implementation of this leads one to develop surrogate and possible a pre-processor to generate them. In conclusion both languages have certain things they allow the developer to do quite nicely, our specific focus is quasi real time distributed applications. I would be interested in hearing from any of you on c++ porting issues, (another task we have to undertake soon). This article is not religious, and i hope it is not taken that way, however if it is I would be glad to share my faith in Jesus Christ with you. -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727
r91400@memqa.uucp (Michael C. Grant) (08/08/90)
In article <26686@pasteur.Berkeley.EDU> lozinski@argon.UUCP (Chris Lozinski) writes: > > Technically this is caused by the default >structures of the objective-C language where the target class of a >message does not need to be known at compile time. In contrast the >default in C++ is that the target class does need to be known at >compile time. No, that is not necessarily true. If you define a 'base' or 'mother' class for all classes with common methods, then any program statement that needs to call that common method need not know the target class at all. As a simple example, I have a base class 'BaseObject' that I use a lot. Its only instance variable is 'NumRefs', which gives a count of how many lists the object is contained in (so I don't ~X it more than once!) But, it also contains a 'PrintOut' method which I then override in every other class I define. So, if I call I_Dont_Know_What_Class_This_Is->PrintOut(), it will work for any object use. This line of code could be in a procedure call that accept any BaseObject subclass. Defining a mother class like this could really help the organization of the program, anyway. Michael C. Grant
lerman@stpstn.UUCP (Ken Lerman) (08/08/90)
In article <1990Aug7.143106.27683@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes:
->Brad Cox, paraphrased:
->> "dont worry so much about the language... environment is even more
->> important"
->
->In that case, why doesn't Stepstone produce software ICs for both
->Objective C and C++?
->
->-steve
With the usual disclaimer, perhaps it is because:
Quoting Bjarne Stroustrup in "On Language Wars", (I'm missing the full
reference):
it is easier to design "standard libraries" in a dynamically
typed language
The article is worth reading because it emphasizes the different goals
(of Smalltalk and C++). I believe that Cox and Stroustrup would agree
on the importance of the choice of the right language (and
environment). (I'm sure I'll hear about it if I'm wrong.)
Kencox@stpstn.UUCP (Brad Cox) (08/09/90)
In article <1990Aug7.143106.27683@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes: >Brad Cox, paraphrased: >> "dont worry so much about the language... environment is even more >> important" > >In that case, why doesn't Stepstone produce software ICs for both >Objective C and C++? > Why not indeed? For that matter, why not for Pascal, and Ada, and Cobol too? In the preface to my book, I described exactly that as the ideal of which Objective-C was only the initial instantiation. I also went into considerable detail as to the nature of the binding mechanisms that would make this possible, and how these mechanisms can be added to nearly any language, Cobol being the most difficult and C or C++ the least. So why not indeed? Only non-technical issues, like market size and the likelihood of the target market to embrace reusable components once produced. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
tma@osc.COM (Tim Atkins) (08/09/90)
There seems to be some confusion on the differences in binding strategies employed in C++ (and other strongly typed languages) as compared to those employed by Objective-C (and other untyped or less strongly typed languages). In C++ the type of all objects must be known at compile time. In the case of a pointer to the object the actual type of the object at run-time may be any subclass of the specified type. The virtual method of binding starts with the assumption of a known base. The actual code generated takes advantage of this knowledge to do a relative lookup of the function to invoke in relation to this type information and the actual type (indirectly speaking) of the object. The "indirectly" is due to C++ not really keeping run-time type info at all but only building indirection tables in fixed locations of the object layout to accomplish the binding. In Objective-C and Smalltalk the binding occurs by looking in tables maintained by the class structure/object corresponding to the object. Every object contains a pointer to its class. Thus type information is available at run-time and the lookup of a method is based solely on the run-time type and the message selector. This difference is a two-edged sword. Objective-C makes possible the "message not understood" form of error at run-time although code checks can be put in to ameliorate any problems due to this possibility. Having type information at run-time is a separate issue but I have personally found it useful to add this to C++ environments as have many other users. The true dynamic binding ability of Objective-C makes possible much more flexible reuse of software as less of the future scope of the need for such reuse had to be known and prepared for ahead of time. This form of binding technology allows a much higher degree of polymorphism. It also makes possible very powerful techniques such as the perform: method allowing any message, even one composed at run-time, to be sent to any object. In its current incarnation I know of no way to do such a thing in a tractable fashion using C++. This capability is of more than academic interest as it is extremely useful for building "proxy" objects that forward messages to the real object which may be on disk or another machine at the time. While there are ways to do proxy-like classes in C++ they are not nearly as general or clean. I personally believe that C++ would be a more robust language if it included this type of late binding as an option.
cox@stpstn.UUCP (Brad Cox) (08/10/90)
In article <3228@osc.COM> tma@osc.UUCP (Tim Atkins) writes: >I personally believe that C++ would be a more robust language if it included >this type of late binding as an option. That's exactly the flaw with C that caused me to develop OOPC and then Objective-C. Dare I suggest that the solution for C++ (and Ada, Cobol, Pascal, etc, precisely as I described in my book) might be almost identical to the solution we used with C? I.e. the addition of a separate binding possibility, messaging to anonymous objects, *in addition to* (never replacing) the diverse binding possibilities already in C++. Naaah, never mind, forget I said that. Totally unrealistic. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
burke@netcom.UUCP (Jim Burke) (08/14/90)
In article <1990Aug7.165255.5174@swbatl.sbc.com> jmd@swbatl.sbc.com (Jim Doherty 5-0804 11-Y-03) writes: > > Objective-C because it follows the smalltalk model of messaging is easily >extendable across process spaces, for instance: > > > > One item I have not mentioned yet is that in order to to accomplish >the programs must be multi threaded, ie able to give up control in light of >an external event (a message). to accomplish this we used a unique trick in >the _msg code we also put in an accept_events() function call which in >reality makes the program(object) multi threaded with out the programmer >having knowledge of this. We also linked in a LWP lib (light weight process) >in the linkage section. There is a fairly simple alternative to forcing programs to be multi-threaded in order to accomplish interprocess messaging of objects. I was heavily involved in a project development effort in which we solved that problem by considering process spaces to be purely generic. Any object could process it's messages in any process space. Objects were divorced from the concept of a process space by giving them existence external to the process in the form of persistence in a database, residence in shared memory, or even residence on another node. The OO message kernal software handled the routing of the messages and the mapping of the object into a generic process space for processing. A dirty flag was set for persistent objects for rewritting back to the database, if that was where the object lived. The only local objects to the process were the actual object management objects, not application objects. It was a very slick concept, and one I wish others would explore and extend... -- **************************************************************************** * Jim Burke James Burke & Associates, Inc. * and yes, I do San Jose, CA 95129 * speak for the company (408) 255-6565 ****************************************************************************
chip@tct.uucp (Chip Salzenberg) (08/15/90)
According to r91400@memqa.uucp (Michael C. Grant): >If you define a 'base' or 'mother' >class for all classes with common methods, then any program statement >that needs to call that common method need not know the target class at all. The original poster *was* correct; virtual functions are *not* the default in C++. They are, however, a standard part of the language, and in this discussion, the relevance of default behavior (as opposed to available features) seems small to me. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>