I'm fairly sure that whatever integer type you use to hold a pointer,
it's going to get converted to a vol at the C interface anyway - inside
a conversion are functions to convert from/to vols. Also, the supplied
conversions for integer types work with IntInf.int, e.g.
> LONG : IntInf.int Conversion;
val it = ?: int Conversion
so IntInf.int will be involved too, which may not be optimized out.
Probably most efficient to use vol for a pointer and the conversion
POINTER. This would avoid the creation of a new vol when passing a
pointer to a C function whereas passing an ML integer may require a new
vol to be created each time.
04/10/14 18:19, m...@beroal.in.ua wrote:
The interface is generated from C prototypes, and every pointer is
wrapped in an ML type for every C "typedef", so safety is not of concern
here. As I said, the library requires to free objects explicitly.
BTW,
$ uname -a
Linux [skipped] 3.16.1-1-ARCH #1 SMP PREEMPT [skipped] x86_64 GNU/Linux
> SysWord.wordSize;
val it = 64: int
Appears that this changed in 5.5.1:
Poly/ML 5.5.0 Release
> SysWord.wordSize;
val it = 126: int
Poly/ML 5.5.1 Release
> SysWord.wordSize;
val it = 64: int
On 04.10.14 16:14, Phil Clayton wrote:
I would suggest that you don't actually want an ML integer type to
hold your C pointers. The main reason is that you would lose some
type-safety because type checking would not detect accidental use of
an integer as a pointer (and vice-versa).
What you should want in ML is an abstract type for a pointer, say,
Pointer.t that has the required operations. Creating a simple
signature/structure to provide a pointer type (defined internally as a
vol) would go some way to removing the confusion about using vol
directly.
In ML, the types SysWord.word and IntInf.int would be wide enough to
hold pointer types. With Poly/ML, I'm sure it would be much more
efficient to use a vol. (On my x86_64 system, SysWord.wordSize =
126.) Also, if you're going to use the garbage collector to free
memory when a pointer is no longer referenced, your pointer types must
be based on a vol.
Phil
26/09/14 09:59, m...@beroal.in.ua wrote:
Hello.
As I can see, there is no address type. The suggested conversion for C
pointers (POINTER : vol Conversion) converts a C pointer to "vol".
As follows from
http://www.polyml.org/docs/CInterface.html#17%20Volatile%20Implementation
, "vol" contains an address of a heap object. If its boolean field
"owns" is true, it garbage-collects its heap object.
If a C library requires that freeing a heap object be done explicitely,
managing an address to that heap object by "vol" is inefficient and
confusing. A "vol" value contains an index of the element of the "vols"
array which contains an address of a memory block which contains an
address of the heap object. What I really need is an ML integer type
that is wide enough to hold a C pointer; I called it "address type".
I'm trying to create a binding to the XCB library (
http://xcb.freedesktop.org/ ). Some functions from XCB don't manage
memory (so the Poly/ML garbage collector may be used); some functions
are allocating objects, and those objects must be freed by the function
"free" or "xcb_disconnect".
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
