Forum > Windows

Questions about GUID declarations magic

(1/4) > >>

440bx:
Hello,

It looks like declaring GUIDs follow a different set of rules than declaring any other record type. 

Consider the following code:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- {$define USE_DATA_TYPE_IDENTICAL_TO_GUID} program _GUID_Declarations; uses  Windows,  ActiveX  ;  type  { EXACT copy of TGUID definition                                            }   TDATA_TYPE = packed record     case integer of        1 : (             Data1 : DWord;             Data2 : word;             Data3 : word;             Data4 : array[0..7] of byte;            );        2 : (             D1 : DWord;             D2 : word;             D3 : word;             D4 : array[0..7] of byte;            );        3 : ( { uuid fields according to RFC4122 }             time_low : dword;                  // The low field of the timestamp             time_mid : word;                      // The middle field of the timestamp             time_hi_and_version : word;           // The high field of the timestamp multiplexed with the version number             clock_seq_hi_and_reserved : byte;     // The high field of the clock sequence multiplexed with the variant             clock_seq_low : byte;                 // The low field of the clock sequence             node : array[0..5] of byte;           // The spatially unique node identifier            );  end; type  TDATA_TYPE2 = TGUID;  const  { this compiles                                                             }   SOMEGUID  : TGUID        = '{00000114-0000-0000-C000-000000000046}'; const  { this also compiles                                                        }   SOMEGUID2 : TDATA_TYPE2  = '{00000114-0000-0000-C000-000000000046}';  {$ifdef USE_DATA_TYPE_IDENTICAL_TO_GUID}const  { this does NOT compile ... why ??? - TDATA_TYPE is identical to TGUID      }   SOMEGUID2 : TDATA_TYPE = '{00000114-0000-0000-C000-000000000046}';{$endif}  // in activex.pp//// IID_IOleWindow : TGUID = '{00000114-0000-0000-C000-000000000046}';//// IOleWindow = interface(IUnknown)//    ['{00000114-0000-0000-C000-000000000046}']      { <- duplicated value   }////    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^////    this duplicated value opens the door to errors  const  { define IID as plain - untyped - constant                                  }   IID_IOleWindow = '{00000114-0000-0000-C000-000000000046}'; type  { _IOleWindow                                                               }   IOleWindow = interface(IUnknown) [IID_IOleWindow]  { <- use the plain constant }      { methods here }   end; begin   readln;end.                           On line 15, there is an EXACT copy of the definition of TGUID (copy/pasted.) if I try to declare a value using the copy of TGUID's definition (line 58), the compiler rejects it, that's in spite of the fact that other than the data type name being different, the definition is identical to the one in lines 46 and 51 which are both accepted.


Now a different question altogether....

In activex.pp, just about every interface id is declared as a typed constant (line 64) and then restated in full in the interface declaration (line 67.)  The concern here is possible errors due to incorrect duplication of the interface id.

The compiler accepts declaring the constants without type (which as a bonus saves data storage) (line 77) and use that constant as the interface id in the interface declaration (line 82)

There are several advantages to that method, one is that no storage in the data section is necessary, it is impossible to modify the interface id since it is not stored and lastly, there is no interface id duplication.

My only concern is, does doing the way shown in lines 77 and 82 have the potential to cause problems that the other way does not ?

Thank you for your help.

Attached to the post is the code presented above.  Comment/uncomment the define to see the different behavior.

Thaddy:
GUIDs are indeed parsed differently for COM, otherwise you won't come away with its string representation in the code. It makes it a special kind of record. I am not sure if CORBA interfaces are parsed differently, though:
Many people use GUIDS for CORBA interfaces (allowed) but there the GUID is a direct string representation and not really a GUID in the COM sense. CORBA just needs a string identifier and you can misuse a guid for that. In CORBA, for whatever the reason, you can replace the GUID by 'Elephant' or something.
And a string is NOT a GUID for COM.
In COM a GUID is a binary format whereas in CORBA it is interpreted as a string.
So, given that, a COM GUID needs to be parsed differently.
(Even if you use a variant record).
IOW the compiler needs to resolve the binary signature for COM but not for CORBA where it is a string.

marcov:
I think the problem is that TGUIDs can't be true constants because they are too large.

I'm not sure how much identity Corba actually supports.

Thaddy:

--- Quote from: marcov on July 09, 2025, 01:09:48 pm ---I think the problem is that TGUIDs can't be true constants because they are too large.

I'm not sure how much identity Corba actually supports.

--- End quote ---
They can be if you followed my advice and patch activex.pp to compile the typed constants in {$J-} state.
Then they end up in rodata and are by definition immutable.
Maybe you did not read that thread yet? It contains a patch.
I respect that you can not read everything and can reprovide the patch again.

marcov:
I'm not really interested in Corba, but what thread exactly ? There is no in your post.

Navigation

[0] Message Index

[#] Next page

Go to full version