Re: Another number question
Matt Lewis wrote:
>
> Jason Gade wrote:
> >
> > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this
> > point, the limitation is the fseek() call in the C library, which takes a
> > 32-bit
> > integer, limiting the size of the seek to 4GB.
> >
> > Now, maybe one of these days Kat will have to deal with 18 exabyte files,
> > but
> > that day is not today. If we go with 2^53, then that limits her to only 9
> > petabyte
> > files. Cry me a river.
>
> Hey, not my fault you don't want to do it right. :)
>
> I know I've worked with the windows API for large files. Haven't done the
> same for linux/bsd.
>
> Matt
Well, for me "doing it right" means making it pretty much transparent and
working the way the user expects it to work. That is, the user gives a number and
the pointer seeks to the proper spot in the file, subject only to the
OS/filesystem limitations.
In a way I think this would be transitional as well, as machines do eventually
move more and more to 64-bit.
More research is required, I think. Right now I'm mostly just brainstorming
anyway.
One thought I had this morning, though, was to create a 64-bit integer type
internal to the interpreter, and routines or macros or whatever to convert an
atom to a 64-bit integer.
Then that groundwork will be laid for the future.
Still taking baby steps with the source -- I still haven't gotten set back up
with subversion or anything and I still spend more time elsewhere on the internet
discussing non-programming stuff than I spend doing any programming.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
|
Not Categorized, Please Help
|
|
