469,964 Members | 1,570 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,964 developers. It's quick & easy.

pinvoke -- making byte** more efficient

Hi folks,

I've got an unmanaged routine I'm pinvoking to. It takes a pointer to an
array of 3 pointers to bytes, typed as byte**.

[DllImport("foo.dll")]
public static extern void foo(byte **p3pb);

unsafe {
byte[] pB = new byte[3];
pB[0] = // irrelevent in example
pB[1] = // irrelevent in example
pB[2] = // irrelevent in example

fixed(byte **ppb = pB) {
foo(ppb);
}
}

So this requires an array allocation, a pinning operation, and a pinvoke.

I'm gonna be calling this routine a lot. So I thought maybe I could make
this more efficient by doing this:

[StructLayout(LayoutKind.Sequential)]
unsafe struct pByte3 {
public byte *p0;
public byte *p1;
public byte *p2;
}

pByte3 pB;
pB.p0 = // irrelevent in example
pB.p1 = // irrelevent in example
pB.p2 = // irrelevent in example

foo(&pB.p0);

So this removes the array allocation and the pinning operation. It would
seem to be more efficient -- since the struct is a value type, it's not in
any heap and so the interior pointer can just be used directly.

Can anyone see why this would not work or why it not be a gain in terms of
efficiency?
Nov 15 '05 #1
3 1695
"Ted Miller" <te*@nwlink.com> wrote in
news:vq************@corp.supernews.com:
Hi folks, [...]
Can anyone see why this would not work or why it not be a gain in
terms of efficiency?


byte** != byte[]{byte[],byte[],byte[]} in sequential order.

you could have something like this:

byte** = 0x1000

first byte* = 0x1004
second byte* = 0x5000
third byte* = 0x2000

this would break your sequential order.

--
------ooo---OOO---ooo------

Peter Koen - www.kema.at
MCAD CAI/RS CASE/RS IAT

------ooo---OOO---ooo------
Nov 15 '05 #2
I'm not following you.

The API I'm calling expects that it get a pointer to the 12 bytes that are
interpreted as 3 pointers. What those 3 pointers point to are are not
relevent to the discussion -- although I said they are byte*'s I never said
they were pointing into managed byte arrays.

I was just trying to make sure that when I call the API using my structure,
that the 3 byte*'s in the structure are passed in one block of 12 bytes.

[dllExport("foo.dll")]
public static extern void SomeApi(int *ppi); // expecting a pointer
to 3 integers

If I do this:

struct int3 {
int i0;
int i1;
int i2;
}

int3 i3;
i3.i0 = 1;
i3.i1 = 2;
i3.i2 = 3;

SomeApi(&i3.i0);

does the right thing happen? The compiler allows this, and it seems like it
should work. Also seems like it would be about as efficient as it could be,
since the struct would go on the stack and there's no need to pin anything.
Compare to allocating an array of 3 ints and using a fixed() construct.

int[] i3 = new int[3] { 1,2,3 };

fixed(int *p = i3) {
SomeApi(p);
}

"Peter Koen" <koen-newsreply&snusnu.at> wrote in message
news:uH**************@TK2MSFTNGP09.phx.gbl...
"Ted Miller" <te*@nwlink.com> wrote in
news:vq************@corp.supernews.com:
Hi folks,

[...]

Can anyone see why this would not work or why it not be a gain in
terms of efficiency?


byte** != byte[]{byte[],byte[],byte[]} in sequential order.

you could have something like this:

byte** = 0x1000

first byte* = 0x1004
second byte* = 0x5000
third byte* = 0x2000

this would break your sequential order.

--
------ooo---OOO---ooo------

Peter Koen - www.kema.at
MCAD CAI/RS CASE/RS IAT

------ooo---OOO---ooo------

Nov 15 '05 #3
Ted,
does the right thing happen?


Yes, this should work fine.

Mattias

--
Mattias Sj÷gren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.
Nov 15 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by savage | last post: by
5 posts views Thread by Carlos Guzmßn ┴lvarez | last post: by
4 posts views Thread by TT (Tom Tempelaere) | last post: by
5 posts views Thread by _iycrd | last post: by
45 posts views Thread by Ajay | last post: by
3 posts views Thread by msnews.microsoft.com | last post: by
1 post views Thread by rainxy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.