Re: Big String Idea for v2.6
Al Getz wrote:
>
> Hello all,
>
> This could be very, very useful if it was implemented...
>
> Take for example, a C function call:
>
> String="ThisName"
> pString=allocate_string(String)
> retv=c_func(xSetName,{pString})
> free(pString)
>
> Granted we could have saved one line here by not declaring a string
> sequence 'String' but a lot of times calls like this have a string
> that originates outside the block of code that actually calls
> the c function anyway, so this isnt a bad example.
>
> If we take a close look at this, we can see we had to do quite a
> bit of work just to pass the string to the c_func didnt we?
> We had to allocate a string, then free it. This is not only a
> lot of additional work, it took more processor time also.
> All one would need is a simple function that gets the pointer
> to the sequence element and the above code would reduce to something
> like this:
>
> String="ThisName"
> retv=c_func(xSetName,{pointer(String)})
>
> pointer() of course returns the pointer to the first element
> of String, and String would have to be a one dimensional sequence.
> A variant would look like this:
>
> retv=c_func(xSetName,{pointer(String[1])})
>
> indicating the pointer should be the pointer to the first element
> of String.
>
> Of course sub-elements would still be indicated by indexes like:
>
> pointer(MyStrings[3][1])
>
>
> Now i know this brings up a few problems like the fact that
> the sequences are stored as four byte C integers rather than
> single bytes (like a C string) so here is a way around
> that...
>
> pointer4a(String[1])
> would take every 4th element and poke it into memory to create
> a C string. Upon return from the function call, the mem would
> be free'd. This wouldnt take any additional memory if the
> call didnt return right away either...because right now poke's
> do the same thing.
>
> As a side effect, strings could be indexed to suite:
>
> String="C:\\DirA\\Filename.txt"
> c_proc(xSetFilename,{pointer(String[9])})
> c_proc(xSetDirname,{pointer(String[1..8])})
> --done
>
>
> BTW, in the preceeding the name 'pointer' was arbitrary..
> even 'allocate_string' would work as long as the function call
> took note that it had to be free'd upon completion. This
> wouldnt even add any additional keywords to the language.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
Hey, Al.
When we first started discussing this Standard Euphoria Library project, this is
a problem that I wanted to address. While I like the almost-typeless design of
Euphoria there are times when types are needed, especially when interfacing with
C code or OS routines.
I would like to see routines that can make structures, records, packed strings,
unicode strings, fixed-type arrays and lists, etc. Routines to check the
values/formats and make sure they are correct, and routines to allocate memory
and return a pointer to the user.
Fixed arrays and lists could probably use the built-in type system but for
structures and records and other types I would make explicit type-validation
routines.
These new types would be as transparent to the user as possible. That is,
hopefully the object returned would be usable as a normal Euphoria sequence with
expected results.
=====================================
Too many freaks, not enough circuses.
j.
|
Not Categorized, Please Help
|
|
