Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] native values in objects from c

2 views
Skip to first unread message

Michael Wohlwend

unread,
Aug 29, 2006, 7:59:56 AM8/29/06
to caml...@inria.fr
with that code:

class x = object
val name = "hoho"
end;;

let ho = new x in ...


how do I access the field name form C?

The docu says it should be the third field of the block, but that doesn't work for me (it has Tag 0, not 252 for strings ...)

cheers,
Michael


--


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Jacques Garrigue

unread,
Aug 29, 2006, 9:38:53 AM8/29/06
to mic...@fantasymail.de
From: "Michael Wohlwend" <mic...@fantasymail.de>

> with that code:
>
> class x = object
> val name = "hoho"
> end;;
>
> let ho = new x in ...
>
>
> how do I access the field name form C?
>
> The docu says it should be the third field of the block, but that doesn't work for me (it has Tag 0, not 252 for strings ...)

Well, since fields start at 0, the 3rd field is number 2.

# Obj.size (Obj.repr ho);;
- : int = 3
# Obj.tag (Obj.field (Obj.repr ho) 2);;
- : int = 252

Jacques Garrigue

Michael Wohlwend

unread,
Aug 29, 2006, 10:09:47 AM8/29/06
to Jacques Garrigue

-------- Original-Nachricht --------

>
> Well, since fields start at 0, the 3rd field is number 2.

thanks for helping; actually my fault was to think the elements are linear ordered, even if the class is inherited (I want to get the first value of the base). The values are ordered reverse of definition, whereas the docu says:
"Instance variables are stored in the order in which they appear in the class definition"

In the end I want to hide public methods which give you access the the pointer to the c++ object and hiding an external method is easy.

cheers
Michael

--


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

_______________________________________________

Jacques Garrigue

unread,
Aug 31, 2006, 3:11:52 AM8/31/06
to mic...@fantasymail.de
From: "Michael Wohlwend" <mic...@fantasymail.de>

> > Well, since fields start at 0, the 3rd field is number 2.
>
> thanks for helping; actually my fault was to think the elements are linear ordered, even if the class is inherited (I want to get the first value of the base). The values are ordered reverse of definition, whereas the docu says:
> "Instance variables are stored in the order in which they appear in the class definition"
>
> In the end I want to hide public methods which give you access the the pointer to the c++ object and hiding an external method is easy.

Aargh, you're right. The behaviour changed between 3.08 and 3.09.
In 3.08, fields are still ordered in definition order, including
inherited ones, but in 3.09, due to an optimization, inherited fields
appear after newly defined ones. The trouble is that this being due
to an optimization, this may change again, so it is not a good idea to
depend on it.
Note also that it is pretty easy to define another object, with the
same type as the one you want to interface with C++, but with
completely different fields. I.e., accessing object fields from the C
side is always dangerous.
A better approach it to add a method which returns the field with an
abstract type, this way users cannot break the type system.

Jacques Garrigue

Michael Wohlwend

unread,
Aug 31, 2006, 4:33:22 AM8/31/06
to Jacques Garrigue

-------- Original-Nachricht --------
Datum: Thu, 31 Aug 2006 15:55:12 +0900 (JST)
Von: Jacques Garrigue <garr...@math.nagoya-u.ac.jp>
An: mic...@fantasymail.de
Betreff: Re: [Caml-list] native values in objects from c

> Aargh, you're right. The behaviour changed between 3.08 and 3.09.
> In 3.08, fields are still ordered in definition order, including
> inherited ones, but in 3.09, due to an optimization, inherited fields
> appear after newly defined ones. The trouble is that this being due
> to an optimization, this may change again, so it is not a good idea to
> depend on it.

o.k., accessing the field from c allready seemed hacky to me :-)

> A better approach it to add a method which returns the field with an
> abstract type, this way users cannot break the type system.

o.k., seems indeed the safer way.

thanks,
Michael

--


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

_______________________________________________

0 new messages