Re: pointers to variables
- Posted by prickle Aug 01, 2009
- 1245 views
Welcome back to Euphoria. I am sure that many on this forum would see the lack of pointers as a major advantage. Pointers would certainly simplify some applications but have some serious problems, not the least of them being the great possibility for abuse. A high level language like Euphoria isolates the value of a variable from it's physical representation. This allows the interpreter to change either the address of a variable or how it is internally represented. If Euphoria allowed pointers to variables this flexibility would be lost. There is also the possibility that some details of internal representation may change in future versions. This would break any application that used pointers.
I believe that interfacing to C and assembly can, and should be, improved. At present there is no concensus on how this can best be accomplished. But pointers are not the best way to do this.
Do feel free to suggest any other improvements to the language.
Thanks, Larry. Yes of course you are quite right. Pointers in the style of C are nasty things that mainly serve to confuse programs and programmers. Nevertheless, this is what allocate() returns, a pointer to a block of memory. Pointers to variables appeared to complement this scheme and seemed the most direct route to an (elegant? at least in the spirit of what I am trying to do) solution for me, but by no means the best. Have any other mechanisms been suggested to allow this kind of thing?
This is possible. If you're calling your routines via c_func/proc, use the E_* data types when defining them. The parameters will be passed with the 'raw' object values. The original use for this was for calling euphoria translated dlls, but you can use it in other ways. In wxEuphoria, for example, I directly manipulate euphoria objects using C.
Hi Matt. Yes, I did consider such a method, but thought it could be quite complex. Let's see if I understand correctly.
- I would need to allocate a block of memory
- poke in a preamble to set up/access the stack frame? if required.
- poke in my code from the mini-assembler, including (hard)code to access E_* data types.
- poke in more code afterwards to tidy up and return the new E_* object
- feed the address of the block into define_c_func along with parameter info
- cross fingers and use c_func to call the routine
Would it work? what have I forgotten?
This still would not protect me from object implementation changes in new forms of Euphoria as I could not get at the E_* data type declarations from the mini-assembler and any accesses to the type would need hard-coded parameters.
But it occurs to me that this would be the case anyway with a dll/so and therefore hesitantly conclude the E_* data type is a fixed representation of an object that the interpreter probably does not use internally. Please correct me if this is not the case.
Has anybody tried constructing a dll/so in memory like this? It occurs to me this method would be made simpler by using an external assembler like MASM or such to build a proper dll/so from the source, and then simply treat it like any other shared library. This is not what I want, Towing a heavy full-featured macro assembler behind what should be a fast, lightweight include file or requiring it as a dependency is too ugly.
Cheers, Nick
