rcb@ccpv1.ncsu.edu (Randy Buckland) (02/16/90)
The following is one of many responses I got to my previous posting wanting to know how to find an object's class (in which I also complained that Eiffel is sufficiently buggy that I did not find is useful). I am reposting this to clarify my request on what I think is a limitation of C++. I will address each point in more detail: >You don't need to "find the object's class" at run time. If you are >throwing in "if" statements to do this kind of checking you are >defeating the goal of using OO methods. You should just be writing >your application in plain-old C. Dynamic binding and inheritance are >the "proper" tools to use in this case. > >class foo { > virtual code (); >} >class foo_a : public foo { > ... >} >foo_a::code () >{ > /* do one thing */ >} >class bar : public foo { > ... >} >bar::code() >{ > /* do foo thing + extra stuff */ >} > In the C++ problem, I am writing code that will maintain a database of elements of our network for programs to use that need to know the network's topology. The main database object will contain a list of all items in the network (nodes, nets, routers, etc.) I can exect to have programs that may want to use a function, that exists for all types of nodes (like print it's name), only on a subset of these nodes (all nodes on a segment, all nodes on token-ring, all routers, etc.). The last case is the one in which I want to find an objects class. The other cases will require code to see if each object meets a certain match criteria. It is possible for the match criteria to coincide with the class structure such that knowing an object's class will determine if the object matches the desired subset of objects. >As for your problems with Eiffel: Why haven't we heard about them before >now? And why did I have to read them in comp.lang.c++? Might I suggest >that in the future you ask for help in the appropriate places. You can >contact Interactive directly at eiffel@eiffel.com or indirectly through >comp.lang.eiffel, which we read religiously. > Last semester I took a class on Object Oriented Programming that covered a number of languages (SmallTalk, C++, Eiffel, and others). I liked the SmallTalk power, but the speed made it almost unusable and some aspects of the language I did not like (limited interface to other languages, no good system for my vaxstation, can't create a standalone executable to run on a system without smalltalk, etc.). We had one assignment in Eiffel on a MicroVax and this assignment caused more problems than anything else inthe course. The assignment was to write a version of the MATRIX classes as described in Meyer's book with certain modifications. The first version of the assignment would have been for a fairly general matrix package, but bugs were found in the handling of generics of Eiffel 2.2 that made the problem impossible. The professor was communicating with the Eiffel people to fix these. We finally had to reduce to scope of the assignment 2 times until it was doable with the known bugs in the system. Even with the simple assignment, the Eiffel system caused many problems (all reported by various people). For example, I was working with about 6 files that each had a class definition. At times, when I would change something in one file and recompile, the compiler would give all kinds of strange error messages and refuse to compile the file. If I deleted all the "*.E" directories where I was working and recompiled, the same file would compile correctly. The problem was not related to dependancies since the "es" command was being used and it was trying to build things in the right order. Most people in the class finally took to deleting the "*.E" directories before each compile just to get it to work (lots of needless recompiles!). Randy Buckland rcb@ncsuvx.ncsu.edu