Array of pointers
in [Visual Basic]
|
From: Eduardo on 13 Oct 2009 08:40 Schmidt escribi�: > Private Function GetStrFromStrPtr(ByVal nStrPtr As Long) As String > Dim iLength As Long > > If nStrPtr = 0 Then Exit Function > > CopyMemory iLength, ByVal nStrPtr - 4&, 4& > > 'now with only one allocation and one Copy-Over > GetStrFromStrPtr = Space$(iLength \ 2) > CopyMemory ByVal StrPtr(GetStrFromStrPtr), ByVal nStrPtr, iLength > End Function > > Private Function GetStrFromVarPtr(ByVal nVarPtr As Long) As String > Dim iStrPtr As Long > > If nVarPtr = 0 Then Exit Function > > CopyMemory iStrPtr, ByVal nVarPtr, 4& 'only the dereferencing... > > GetStrFromVarPtr = GetStrFromStrPtr(iStrPtr) '...and the delegation > End Function Thanks Olaf. One thing: I've read somewhere (I think it was Ken Halter who said that here in the NG) that working with the return value in a function was dangerous because it could cause problems. Even when I never had problems with it, I begun to use temp variables and assigning the result just before exiting the function. Do you (or anybody else) know anything about this issue?
From: dpb on 13 Oct 2009 09:14 Eduardo wrote: .... > One thing: I've read somewhere (I think it was Ken Halter who said that > here in the NG) that working with the return value in a function was > dangerous because it could cause problems. > Even when I never had problems with it, I begun to use temp variables > and assigning the result just before exiting the function. > Do you (or anybody else) know anything about this issue? AFAIK it would be a bug in the compiler if it did; not that that can't happen, but it shouldn't. At least at the moment I can't think of a reason or place where it is prohibited by language syntax to not use the function name for the return value instead of a temporary. That said, I can believe you could write complex expressions or find usage that would break that might work in a temporary local variable. --
From: Eduardo on 13 Oct 2009 10:43 dpb escribi�: > Eduardo wrote: > ... > >> One thing: I've read somewhere (I think it was Ken Halter who said >> that here in the NG) that working with the return value in a function >> was dangerous because it could cause problems. >> Even when I never had problems with it, I begun to use temp variables >> and assigning the result just before exiting the function. >> Do you (or anybody else) know anything about this issue? > > AFAIK it would be a bug in the compiler if it did; So I understood it. > not that that can't > happen, but it shouldn't. Agree. > > At least at the moment I can't think of a reason or place where it is > prohibited by language syntax to not use the function name for the > return value instead of a temporary. AFAIK it's not prohibited. > That said, I can believe you could write complex expressions or find > usage that would break that might work in a temporary local variable. I don't know. If there were no bugs, the return (variable) value should be the same as any other variable of the same type. May be later I'll try to find that post.
From: Eduardo on 13 Oct 2009 10:45 dpb escribi�: > Eduardo wrote: > ... > >> One thing: I've read somewhere (I think it was Ken Halter who said >> that here in the NG) that working with the return value in a function >> was dangerous because it could cause problems. >> Even when I never had problems with it, I begun to use temp variables >> and assigning the result just before exiting the function. >> Do you (or anybody else) know anything about this issue? > > AFAIK it would be a bug in the compiler if it did; So I understood it. > not that that can't > happen, but it shouldn't. Agree. > > At least at the moment I can't think of a reason or place where it is > prohibited by language syntax to not use the function name for the > return value instead of a temporary. AFAIK it's not prohibited. > That said, I can believe you could write complex expressions or find > usage that would break that might work in a temporary local variable. I don't know. If there were no bugs, the return (variable) value should be the same as any other variable of the same type. May be later I'll try to find that post.
From: dpb on 13 Oct 2009 10:50
Eduardo wrote: .... > I don't know. If there were no bugs, the return (variable) value should > be the same as any other variable of the same type. .... Yes, my point was I can imagine you could find or create a complex-enough situation to confuse the compiler w/ a function name that a local wouldn't. Most likely it would be a parsing problem or a stack allocation problem but it would indeed be a bug. There's no functional compiler that is 100% bug free and I don't know of a particular instance or way to break VB in this regard; I'm just saying I can imagine one can find ways if creative enough (or lucky/unlucky depending on your pov :) perhaps in what might appear very simply). It's possible Ken or someone else did find a case that you're recalling. As for a general style, it's a choice -- I find I don't have a consistent preference; it depends on the complexity of the function more than anything. Sometimes it seems right one way, other times not... I don't recall VB ever barfing or returning wrong/unexpected results in my usage. -- |