1. 2 Questions
- Posted by Kendra Zerby <kendra at WWWEBMASTERS.COM>
May 11, 1998
-
Last edited May 12, 1998
The actual image part of a bitmap is a sequence of sequences. Are these
arranged continguously in memory, in such a way that I could ememcopy()
them around (and to the screen)? From what I see of the documentation, and my
understanding of sequences, this is possible, but not something that
could be guarenteed.
Secondly, I really find that breaking a program up into a lot of little
files makes it a lot easier to manage. Are there any overhead, and/or
performance issues that will result from this?
2. Re: 2 Questions
Kendra Zerby (related to Ryan?) writes:
> The actual image part of a bitmap is a sequence of
> sequences. Are these arranged continguously in memory,
> in such a way that I could ememcopy() them around
> (and to the screen)?
There's no way for a Euphoria program to get the
memory address of a sequence (or an atom), and I
want to keep it that way. If I give people the address
of Euphoria variables a Pandora's Box of dirty, buggy
code will be unleashed and garbage collection and many
optimizations will be severely constrained. To use
ememcopy() you will have to allocate() a block of memory
and transfer data to/from it using poke()/peek().
> Secondly, I really find that breaking a program up into a
> lot of little files makes it a lot easier to manage. Are there
> any overhead, and/or performance issues that will result
> from this?
No there aren't. (There's a limit of 255 included files).
I suppose it could take a few milliseconds longer for ex/exw
to read your program if more files have to be opened,
but even that would disappear if you bind or shroud the program.
Regards,
Rob Craig
Rapid Deployment Software
