Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Storing C pointers in Eiffel code
Message-ID: <1054@tetrauk.UUCP>
Date: 12 Dec 90 10:05:21 GMT
References: <1039@tetrauk.UUCP> <1990Dec5.171420.22935@bony1.uucp> <1047@tetrauk.UUCP> <18527@rasp.eng.cam.ac.uk>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 84

In article <18527@rasp.eng.cam.ac.uk> nhr@eng.cam.ac.uk (Neil Russell) writes:
>How about using a builtin type ADDRESS (a al Modula-2).  In modula-2
>the type ADDRESS is compatible with any pointer type (analogously
>class type in Eiffel), and in addition to assignment, arithmetic may be
>performed on values of type ADDRESS permitting the construction of
>memory managers.  This latter feature may not be suitable/relevant
>in the Eiffel context, where memory management (garbage collection) is
>hidden from the Eiffel programmer.  Portability considerations aside,
>the attraction of having a specific type (as opposed to integer or
>`bits N') is clarity.

This is essentially what I am proposing, although allowing any arbitrary object
to be attached to an ADDRESS type within Eiffel is dangerous and probably
unnecessary.  As Neil says, memory management is not something to be written in
Eiffel as it is an integral part of the run-time environment, and it is
difficult to imagine any other useful application of arbitrary manipulation of
object addresses.  Of course if you _really_ want to do it, you can have a
trivial C function which returns the address of an Eiffel object argument as an
external ADDRESS (or EXTERN or whatever) type.

My current project involves some extensive interfacing to C subsystems (AT&T's
Tuxedo, which comprises a network database, a TP client/server monitor, and a
message buffer system for starters), which has raised some distinctly
non-trivial problems.  We have solved all these within the current language,
and without resorting to anything nasty.  My only concern is the long-term
portability of Eiffel code which carries external addresses around in variables
which are explicitly integers (and hence C "int"s).

This prompts me to mention something else with external interfaces which is a
little annoying, in that even trivial access to C variables requires a C
_function_ to be written.  A common example is the need to import to Eiffel the
current value of a C global error code (e.g. errno) for error analysis.  This
requires a C function which is simply { return errno; }, and could be achieved
with inline code.  A nice addition would be the ability to specify an external
routine as "inline";  in this instance the inline code would simply be the word
"errno".  How about this:

	external
		c_error: INTEGER inline "errno" language "C" ;

There is in fact a whole load of stuff this simple in the Eiffel run-time
libraries.  All this could be drastically simplified by the introduction of an
inline facility.

A little more thought is required to cover all the possible legitimate uses of
inline code, but one important aspect is the ability to synchronise Eiffel and
C manifest constants in an elegant manner.  It needn't be too complex, anything
extensive should be a function anyway.  This of course assumes that the
compiler target language is C, but using external C functions almost assumes
the same.

>A not totally unrelated defficiency of Eiffel is the inability to
>define formal enumeration types -- entities representing enumerations
>of UNIQUE values must be delared as anonymous integers which makes code
>a lot less clear, and of course error prone.

Eiffel's UNIQUE mechanism is not a substitute for enumerated types, and is not
meant as such.  I have a few grumbles about UNIQUE, in particular, such values
should start at 1 not 0, and the language should specify this - at the moment
it just says that it's implementation dependent.  But UNIQUE declarations are
NOT enumerations.  A true enumeration type will refuse to hold any value other
than those with which it is declared, and Eiffel doesn't support one;  UNIQUE
is just a handy way of declaring a set of unique arbitrary integer constants.
If you want constants with known values you have to declare each one
separately.

A much bigger problem with constants is that you can't declare constants to be
constant expressions, so you can't declare new constants which depend on the
value of existing (maybe inherited) ones.  You also can't use constant
expressions in INSPECT statements, e.g.

	when Base then
		...
	when Base + 1 then	-- not allowed!
		...

There are situations where this is not a trivial problem.

Enough for now!
-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan