Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Reference vs Expanded variables

Reference vs Expanded variables

Reference vs Expanded variables

Here's another grade A question

Is there ant way in Eiffel to check whether a generic object (variable) is a reference to the object or an expanded object?

To be more specific.. i'm working with generic class let's say GRAPH[G] and upon inserting a node into a graph i want to make a copy of an object G passed to the GRAPH and store it in the structure. But if i use clone() procedure on expanded objects (s.a. INTEGER or CHARACTER) all goes to hell. clone() returns a reference to the INTEGER instead of INTEGER. Is there any way around it?  

Thanks a bunch.

RE: Reference vs Expanded variables

References to expanded objects are forbidden :
class C feature

class D feature
  x: C
  y: expanded C

  test is
     do x := y end -- forbidden

So the only way to attach a reference to an expanded object is to clone the source :
  x := clone (y)

As far as I know there is no way to test if a formal generic parameter is an expanded type.
Anyway, I don't think this a problem, supposing you have the class :
class NODE[G] feature
   item: G
Later, a client do:

  Then item is an object, not a reference, because INTEGER is an expanded type, so all entities of type INTEGER are expanded. So you don't have to consider if an entity is a reference or an object. All basic features(:=, =, copy, etc.) apply indifferently.
An exception to this, is that you can't do:
  item := Void
If item is an expanded object, this will raise an exception. But :
   item = Void will always be false.


RE: Reference vs Expanded variables

Thanks for the elaborate answer, i apreciated it.
But the problem i'm facing the following. Suppose i have a class NODE[G] feature
   item: G
   insert(n: G)

What i ultimately want to do when insert is called is to make a copy of the passed n and attached to internal item. For expanded types it would just be:

item := n

but for reference types i would need to do something like:

item := clone(n)

Isn't it so?
So i'm looking for a way to combine these too statements in one which would work equivalently for both types of just put an "if" statement and have two different paths of execution.

I suppose i could try to do some test on it and then if exception is generated i could recover in "rescue" clause, but that seems ugly to me. There's got to be more elegant way of doing it.
Any ideas?

RE: Reference vs Expanded variables

>For expanded types it would just be:
>item := n
>but for reference types i would need to do something like:
>item := clone(n)
>Isn't it so?

You can do something uniform, why do you clone objects in case of references?
You could do item := n if both cases. Or if you really want NODE to hold its own data, you might clone in both cases item := clone (n)
They are the means to combine the 2 statements.


RE: Reference vs Expanded variables

You are right, i have to make a correction. The problem only araises if you try to clone primitive types (CHARACTER, INTEGER, BOOLEAN, REAL). Cloning CHARACTER and BOOLEAN produces CHARACTER_REF and BOOLEAN_REF respectively instead of just CHARACTER and BOOLEAN. When i tried to clone INTEGER and REAL program just crashed!!! That i didn't expect to see at all.
At this point i'm just a little frustrated. I probably end up just doing a simple assignment operation ( item := n). But this is very interesting behavior of Eiffel. I didn't expect any of it.

Thanks for all your suggestions. If you have any idea why what i described above happens i'd love to hear it. Thanks again.
Or maybe just try this code and see what you get.

test is
    c, c1: REAL        
    c := 5.3
    c1 := clone(c)

Try it for all 4 primitive types.

RE: Reference vs Expanded variables

Here is the first code I tried with Eiffel Studio v5.2 :

test is
    -- First test, using REAL_REF
    a: REAL
    c: REAL_REF
    a := 5.3
    c := clone (a)
    check c.is_equal (a) end

I get no errors, everything is ok.
Then I executed the following code:

test is
    -- Second test using only REAL class.
    a, b: REAL
    a := 5.3
    b := clone (a)
    check b.item = a end

I got no crash, no assertion violation. Of course check assertion was enabled. With Eiffel Studio your code works fine. REAL class inherits from REAL_REF class, and then correct behaviour for cloning is ensured.
What eiffel compiler do you use? SmartEiffel? VisualEiffel? Eiffel Studio? In that case I can't understand why you get a crash.


RE: Reference vs Expanded variables

Hi all!

I have a very similar problem... I still don't know how to work it around.

Check if this tips helps you:
* INTERNAL class
* same_type (of ANY) and check with "common" expanded classes (INTEGER, REAL, etc.)

Let me know if you find a solution.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close