difference between component_definition.guid and SUComponentDefinitionGetGuid (SUComponentDefinitionRef comp_def, SUStringRef *guid_ref)

[kengey]

String representations of guids are not the same in ruby as in c. In ruby they are hex guids, in c they appear to be base64 encoded. They also do not seem to be the same bytewise

For example 0AYSk22fqbIQMGaS9XUgk$ is the c guid for Marc while 0a89cb82-0a9d-2549-a590-91c2617aabbf is the guid reported by ruby for the same component definition Marc. It looks like the c variant uses an IFC-specific base64 encoding ($ is not a valid base64 character (https://www.lifewire.com/base64-encoding-overview-1166412), but it is for ifc-specific base64 (https://technical.buildingsmart.org/resources/ifcimplementationguidance/ifc-guid/)

EDIT: they might be the same bytewise however, I did not notice IFCBASE64 0 is 0 while normal base64 0 is A..

EDIT2: when I map the characters reported by c using the following map:

static std::map<char, char> IfcToBase64
{
    {'0', 'A'}, {'1', 'B'}, {'2', 'C'}, {'3', 'D' }, {'4', 'E'}, {'5', 'F'}, {'6', 'G'}, {'7', 'H'}, {'8', 'I'}, {'9', 'J'}, {'A', 'K'}, {'B', 'L'}, {'C', 'M'},
    {'D', 'N'}, {'E', 'O'}, {'F', 'P'}, {'G', 'Q'}, {'H', 'R'}, {'I', 'S'}, {'J', 'T'}, {'K', 'U'}, {'L', 'V'}, {'M', 'W'}, {'N', 'X'}, {'O', 'Y'}, {'P', 'Z'},
    {'Q', 'a'}, {'R', 'b'}, {'S', 'c'}, {'T', 'd'}, {'U','e'} , {'V', 'f'}, {'W', 'g'}, {'X','h'} , {'Y','i'} , {'Z', 'j'}, {'a','k'} , {'b', 'l'}, {'c', 'm'},
    {'d','n'} , {'e','o'} , {'f', 'p'} , {'g', 'q'} , {'h','r'} , {'i', 's'}, {'j', 't'} , {'k', 'u'} , {'l', 'v'} , {'m', 'w'} , {'n', 'x'}, {'o', 'y'}, {'p','z'} ,
    {'q','0'} , {'r', '1'}, {'s', '2'} , {'t', '3'}, {'u', '4'}, {'v', '5'}, {'w', '6'}, {'x', '7'}, {'y', '8'}, {'z', '9'}, {'_', '+'}, {'$', '/'}
};

I get AKicuCCp0lSaWQkcJhequ/ instead of 0AYSk22fqbIQMGaS9XUgk$. Still not valid base64, but getting close.

[thomthom]

hmm... wasn't aware the API returned different format....

Are you trying to convert the C API GUID to the format Ruby API returns?

[kengey]

I was, but I decided to use the name of the definition to make comparisons.

[DanRathbun]

Ref persistent IDs not yet implemented for definitions ... (always returns 0.)

Issue: https://github.com/SketchUp/api-issue-tracker/issues/187 - UPDATE: Implemented at release 2020.1

[sketchupbot]

Logged as: SKOR-13727

[Eneroth3]

@thomthom what would be the expected behavior here? If developers are storing the GUIDs somewhere a change in how they are formatted could be a breaking change. Do we add a new C API function that matches that of Ruby and deprecate the old one?

[thomthom]

Yea, at this point we'd have to add a new function. Too bad we didn't catch this.

[DanRathbun]

What about a macro to do the conversion instead ?