At 09:29 PM 2/5/2007, you wrote:
I think you will find that one reason RS don't provide pointer info about RB
arrays is that there is no guarantee that the data internally is stored
contiguously. It is in a RB specific format.
Things typically go non-contiguous for example if one is using arrays in a
dynamic fashion using appends inserts or removes. Of course if one only used
RB arrays with prefixed dimensions and never appended or resized - then one
might "assume" that internally such data could be held contiguously and
therefore accessed by a pointer - but we just don't know this - its an
internal implementation and subject to change.
Thanks, but I was just trying to find out IF there was such a
function, not why it's "not possible" if there wasn't.
But on your line of thought, how does VB do it then? Probably the
answer is that the "pointers" we are talking about are not absolute
addresses or unmanaged pointers. The memory manager underneath still
is handling these details.
VB actually uses COM; that is, OLE automation in Windows. These
manage the memory underneath, so everything is "contiguous" and far
as "contiguous" goes.
Actually, I do think that COM in Windows keeps everything contiguous
anyway; when there are changes like resizing or deleting mid-buffer,
a contiguous section is found and data copied to, since in assembler
data can be shoved around quickly. I know this because often when I
need a speed boost in a section of programming, I simply use my handy
C++ DLL, write the code in that, and in VB just throw the pointer up
to it. Once it's in C, memory is assumed contiguous and it works
great. I do the same thing in RB when dealing in memory blocks, but
now I'd like to use Byte Arrays instead of memory blocks because of
the better consistency between VB and RB code.
Remember, even if something is non-contagious, there still needs to
be SOME mechanism that knows the chain and can traverse through it.
THIS is what should be accessible - somehow you can get the pointer
to "x" element (which is calculated via this "chain-reader"), and
then any function reads the chain and accesses it that way.
Speed is gained by finding the best function for the job. Using just
RB code may be good, but who knows what useless overhead is
occurring. What you said earlier about benchmarking is correct. Maybe
looping is OK, but in my experience with RB, looping is suicide.
I understand the RB isn't C, and by design these things should be
hidden from the user in such a hi-level language such as Basic. But
that's HIDDEN, not REMOVED.
>> What about just using a string? and midB?
>
> Again, I wasn't looking for a workaround - I want to use Byte Arrays
> AS a workaround for something else.
>
> I have lots of VB code I want to simply paste into RB, and that uses
> lots of buffers, ALWAYS using byte arrays. In VB, byte arrays are
> very fast used with memcpy-type functions to move things around and
> into other byte arrays.
>
> It's simply the syntax and the pain to hand-edit lots of code to
> switch them to memoryblocks that I'm trying to avoid. Right now I
> have wrapper functions that do the trick of blasting bytes, but they
> use loops and it's likely much slower then a pointer/copy fucntion
> that I'm checking in List-Land (soon to be Forum-Land, sniff) to see
> if there's a pointer function to the inhouse RB arrays.
>
>>>> Actualy sounds to me like you might want to consider using a
>>>> memoryblock instead.
>>>
>>> That's sort of the backdoor. I'm trying to use lots of VB code pasted
>>> to RB, which uses byte arrays, and trying to avoid changing them to
>>> memory blocks. I'm completely used to using Byte Arrays as buffers.
>>>
>>> VB has a way of obtaining the pointer from a byte array; in fact, you
>>> just pass the first (or whatever) element to RtlMoveMemory in the C
>>> runtime, the Declare in VB interprets that as a pointer. Pointers in
>>> VB can be used, you just can't do anything directly to them. You
>>> receive a pointer to pass it. I'm just looking for it in the first place.
>>>
>>> So presently there is no way of getting a pointer to an element in a
>>> Byte Array in RB?
>>>
>>>> Also a simple benchmark might give you the answer.
>>>
>>> True, but I already know the outcome (could be wrong though).
>>>
>>>> I'd be interested to know if memoryblocks and memcpy beats simply
>>>> looping round the byte array in the normal fashion.
>>>
>>> I'll try, at least.
>>>
>>>> You cannot get pointers to an RB array. They are reference based only.
>>>
>>> RB knows them, so somehow they could be exposed?
>>>
>>>> If you want to play with pointers you have to be dealing with
>>> memoryblocks
>>>> and/or ptrs derived from Declares.
>>>
>>> See above.
* * * * * * * * * * * * * * * * * * * * * * * * * * *
| Garth Hjelte |
| Customer Service Representative, President |
| Chicken Systems, Inc, Rubber Chicken Software Co. |
| 714 5th Street SE |
| Willmar, MN 56201 USA |
| |
| 800-8-PRO-EPS Toll Free Order Line (US Only) |
| 320-235-9798 Tech Support, Sampler Questions |
| International Line |
| 360-838-7689 Fax |
| Product Sales: [EMAIL PROTECTED] |
| Product Support: [EMAIL PROTECTED] |
| Sampler Q+A: [EMAIL PROTECTED] |
| Web Page: www.chickensys.com |
* * * * * * * * * * * * * * * * * * * * * * * * * * *
_______________________________________________
Unsubscribe:
<[EMAIL PROTECTED]>
REAL Software has decided to consolidate this mailing list with the online Forums.
On Monday, February 12, 2007, this mailing list will no longer be active. We
encourage you to continue your REALbasic and REAL SQL Server discussions on the
Forums. If you are not presently a member of the forum, please sign up today at
<http://forums.realsoftware.com>.
