Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mephisto!ncsuvx!news
From: rcb@ccpv1.ncsu.edu (Randy Buckland)
Newsgroups: comp.lang.c++
Subject: Finding out an object's class (part 2)
Message-ID: <1990Feb16.155259.15135@ncsuvx.ncsu.edu>
Date: 16 Feb 90 15:52:59 GMT
Sender: news@ncsuvx.ncsu.edu (USENET News System)
Distribution: comp
Organization: NCSU Computing Center
Lines: 88


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