Re: 64bit support
- Posted by mattlewis (admin) Mar 03, 2009
- 1079 views
It should be possible to do this instead:
struct {
long length;
long fill;
long refcount;
long data[1]; /* trick the compiler: can be more in reality */
} *s;
s->data[i] // i-th element, single indirection
I don't know how hard it would be to change this, though. I don't know if it improves the performance, either.
As Derek mentioned, the actual declaration is:
struct s1 { /* a sequence header block */
object_ptr base; /* pointer to (non-existent) 0th element */
long length; /* number of elements */
long ref; /* reference count */
long postfill; /* number of post-fill objects */
}; /* total 16 bytes */
What's not totally clear from this is that base actually points to the address of postfill, where the data comes after that (which is similar to what you were looking for). So we actually allocate a single, contiguous block of memory.
It's typically pretty easy to see what any piece of euphoria code is doing--from a syntax/language, not algorithmic point of view.
Hm, that is true for assembler too. The algorithmic point of view is IMHO the interesting part of a piece of code. (I don't get your C example here: There is no operator overloading in C.)
Sorry, with respect to operator overloading, I was referring to C. My sentence could have been clearer.
You're right with respect to assembler, but I'm not sure if you're serious. Assembler is so low level, that the algorithmic view is difficult to see. In any case, the algorithmic view is partially dependent on the coder, though certain languages can make this easier by not requiring the reader to spend time just figuring out what certain operations are doing. Perl, for instance, is often referred to as a write only language for just this reason.
I find that euphoria is high level enough, and the language small enough that it doesn't get in the way of getting a higher level understanding of the code than other languages sometimes do.
Yes, it's not a tool suitable for every problem (let us know when you find it, please).
Well, IMHO Python and Lua have fewer problems than Euphoria. Lua is quite fast too and may be faster than Euphoria in some benchmarks.
Yes, they have some nice features, though I haven't used either of them extensively.
But then, I often wish for Euphoria features when coding in those other languages.
I am interested. Could you please give an example?
Sometimes it relates to static typing, or simply the ease of dealing with sequences. And also not needing to worry about pointers or references, or memory management in general (obviously, memory management issues don't apply to languages like Java).
The pass by reference nature of euphoria can cut both ways. If I pass a value to a routine, I know that it won't be modified. Of course, that also means that I can't modify it if I want to.
Matt
