×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

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

Jobs

Reference vs Expanded variables

Reference vs Expanded variables

Reference vs Expanded variables

(OP)
Hi,
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
   ...
end

class D feature
  x: C
  y: expanded C

  test is
     do x := y end -- forbidden
end

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
   ...
end
Later, a client do:
  n: NODE[INTEGER]

  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.

--
Globos

RE: Reference vs Expanded variables

(OP)
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)
end

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.

--
Globos

RE: Reference vs Expanded variables

(OP)
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
local
    c, c1: REAL        
do
    c := 5.3
    c1 := clone(c)
end

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
local
    a: REAL
    c: REAL_REF
do    
    a := 5.3
    c := clone (a)
    check c.is_equal (a) end
end

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

test is
    -- Second test using only REAL class.
local
    a, b: REAL
do    
    a := 5.3
    b := clone (a)
    check b.item = a end
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.

--
Globos

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.
Rose.

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