GUID Routine

[MattC]

Hi.

I've been using a GUID (Global Unique Identifier) routine, which came from Wiki.

Code: Select all

      REM Creates Global Unique Identifier name
      DEF FNguid
      LOCAL guid{}, guidw%, guida%
      SYS "LoadLibrary", "OLE32.DLL" TO ole32%
      SYS "GetProcAddress", ole32%, "CoCreateGuid" TO CoCreateGuid%
      SYS "GetProcAddress", ole32%, "StringFromGUID2" TO StringFromGUID2%
      DIM guid{a%, b%, c%, d%}, guidw% 79, guida% 39
      SYS CoCreateGuid%, guid{}
      SYS StringFromGUID2%, guid{}, guidw%, 40
      SYS "WideCharToMultiByte", 0, 0, guidw%, -1, guida%, 40, 0, 0
      = $$guida%

The routine (slightly adapted to return a string from a function) uses the system and produces more than just the simple GUID string. However, the program I'm writing requires a significant amount of GUIDs to be produced. This seems to eat up the memory for some reason, despite the variables being LOCAL. My User Memory is set to around 8MB and the FN produces around 4k returns before it runs out of memory. I produced a very simple (and probably not quite as Unique) GUID function that returns a similar string:

Code: Select all

      DEF FNguidsimple
      LOCAL I%, G$
      G$ = "{"
      FOR I% = 0 TO 7
        G$ += RIGHT$("000" + STR$~(RND(65536)-1), 4)
        IF I% = 1 OR I% = 2 OR I% = 3 OR I% = 4 THEN G$ += "-"
      NEXT
      G$ += "}"
      =G$

This doesn't seem to use up any more memory that a single pass and seem to be considerably faster. Apart from the, understandably, higher chance of repeat (guesses to how often this might be would be useful), is there any significant reason for not using this one? The GUID is used as a temporary file name.

Matt

[DDRM]

Hi Matt,

I know Richard always says "don't make up your own random number generator - it won't be as good as a proper one", and I suspect his comments on trying to reinvent GUIDs would be similar! If you are just making up "random" file names which you need not to be the same, is a better solution to make NON-random ones which you KNOW won't be the same? For example by having a PRIVATE variable and incrementing it by 1 each time you call the routine, then incorporating that into the generated string? Obviously that assumes that "temporary" implies within a single run of the program. If you wanted a longer term solution you could have another temporary file to hold the current value...

In terms of the memory issue, I think the problem is that your DIM statements are reserving GLOBAL space (on the heap), even though you are storing the address in a local variable. If you use something like

DIM A% LOCAL 67 (Copied directly from the manual)

It will take the space from the stack,and free it again when you leave the function. Have a look at the section on DIM in the manual, under "reserving a temporary area of memory".

Hope that's helpful.

D

[MattC]

Thanks DDRM. Yes, that's helpful. I hadn't considered where the variables were being stored, just that I assumed they would be released. That's one of the problems of taking a piece of code and shoving it into a program without carefully looking through.

The GUID is mainly used for an random code within the file, but is used, albeit occasionally, as a file name.

Matt

PS I have asked this before but I didn't get a response: the first digit of the third batch of figures in the GUID is always a 4. Does anyone know why this is?

[DDRM]

>Why is the first digit of the third block always 4: Richard tells me that it is because this digit is the GUID version number, and so this is a version 4 GUID. Obvious when you know...



D