ITypeInfo.GetIdOfNames definition problem

[440bx]

Hello,

In activex.pp, in the ITypeInfo interface, the method GetIdOfNames is defined as:

Code: Pascal  [Select][+][-]

1.       Function  GetIDsOfNames(CONST rgszNames: pOleStr; cNames: UINT; OUT pMemId: MEMBERID):HResult;StdCall;
2.  

In that definition the first parameter is a pointer to an OleStr (note that in this case "const" does not cause a pointer to that pointer to be passed as the first parameter, IOW, in this case, "const" has no functional effect.)

The C definition of that method is:

Code: C  [Select][+][-]

1. HRESULT GetIDsOfNames(
2.   [in]  LPOLESTR *rgszNames,
3.   [in]  UINT     cNames,
4.   [out] MEMBERID *pMemId
5. );
6.  

The first parameter is a pointer to an array of pointers to arrays of wide characters.

In Pascal that would be ^^OLESTR or ^POLESTR or PPOLESTR.

The current Pascal definition declares a pointer to a widechar array instead of a pointer to an array of pointers to widechar arrays.

Note that using "var" or "constref" to a pwidechar in this case does not declare that it is an array of pointers which complicates matters if/when the method needs to be used.

HTH.

[gues1]

In activex.pp, in the ITypeInfo interface, the method GetIdOfNames is defined as:

Code: Pascal  [Select][+][-]

1.       Function  GetIDsOfNames(CONST rgszNames: pOleStr; cNames: UINT; OUT pMemId: MEMBERID):HResult;StdCall;
2.  

May be this will be the correct definitiion ?

Code: Pascal  [Select][+][-]

1.       Function  GetIDsOfNames(rgszNames: pOleStrLIST; cNames: UINT; OUT pMemId: MEMBERID):HResult;StdCall;
2.       //pOleStrList is definied in the head of unit:
3.      POleStrList = ^TOleStrList;
4.      TOleStrList = array[0..65535] of POleStr;
5.  

[440bx]

That would work but, it doesn't follow the pattern in existing correct definitions of arguments that are arrays.

The argument should be a pointer to the first array element.  Pointer arithmetic automatically makes that pointer be a pointer to any size array.  This makes the separate declarations of ...LIST unnecessary.

Basically, in C, C++ and FPC, a pointer to a <type> is also a pointer to an array of <type>.  This often makes the declaration of array types unnecessary since the pointer implicitly defines an array of <type>.

for instance, p : ^integer;  makes p not only a pointer to an integer but also a pointer to an array of integers.

[gues1]

The argument should be a pointer to the first array element.  Pointer arithmetic automatically makes that pointer be a pointer to any size array.  This makes the separate declarations of ...LIST unnecessary.
Basically, in C, C++ and FPC, a pointer to a <type> is also a pointer to an array of <type>.  This often makes the declaration of array types unnecessary since the pointer implicitly defines an array of <type>.
for instance, p : ^integer;  makes p not only a pointer to an integer but also a pointer to an array of integers.

This is something I don't like. Not at all.
The fact that you can behave like in C is an absolute plus for performance, but for stability and possible bugs... I would say we are definitely not there.
I know of course that it can be done but I think that something like this should be absolutely avoided (at most I can understand it limited to RTL or RTTI).